[2026 Winter DEV] 제주도 게스트하우스 통합 플랫폼 ‘게하르방’, Brains팀

프로젝트 소개

BRAINS팀은 게스트하우스의 불법 숙박업소 문제와 게스트하우스 정보의 파편화를 해결하기 위해 게스트하우스 통합 플랫폼 게하르방을 제작하였습니다.

팀원 소개

BRAINS팀은 FE 인식님, FE 은서님, FE 승현님, BE 경환님, BE 우재님, PM 성준님으로 구성되어 있습니다!

인터뷰

Q. 프로젝트를 소개해주세요!

A. 성준(PM): 저희 ‘게하르방’ 서비스는 이름에서 알 수 있듯이 게스트 하우스 통합 플랫폼입니다. 게스트 하우스 시장은 날로 커져가지만, 게스트 하우스 정보 공유와 스탭 구인은 주로 네이버 카페에서 제한적으로 이루어지고 있습니다. 체계화 되지 않은 구인 프로세스와 불법 숙박 업소 문제, 게스트 하우스만의 독특한 문화를 기존 숙박 어플은 담아내지 못하는 문제를 해결하고자 합법 인증과 표준화된 정보 제공을 하는 게스트 하우스 통합 플랫폼을 만들었습니다.

Q. 프로젝트 하면서 어떤 문제를 겪었나요?

A. 우재(BE): 프로젝트 초반에 스프린트가 끝나기 며칠전에 몰아서 개발을 하는 문제가 있었습니다. 이로 인해 충분한 고민을 하고 이유를 가진 채 개발을 하는 것이 아닌 결과물을 내놓기 위한 흔한 방법으로 개발을 하였습니다. 이를 해결하고자 저희 팀은 데일리 스크럼으로 적은 양이라도 매일 개발을 할 수 있도록 환경을 조성하였습니다. 그 결과 좋은 코드를 위한 고민 시간을 확보할 수 있었고 이는 자연스레 더 나은 코드와 유지보수성이 좋은 코드를 작성할 수 있었습니다.

Q. 프로젝트 하기 전후 달라진 점이 있다면?

A. 경환(BE): 이전 프로젝트에서는 단순히 기능을 구현하는 데에 익숙해져 있었습니다. 하지만 코드 리뷰와 서로 간의 네트워킹으로 더 좋은 코드는 무엇인지, 가독성이 좋은 코드는 무엇인지에 대해서 배울 수 있었습니다. 또한 좋은 기획을 하기 위해 사용자 경험을 향상시키기 위해 다같이 고민하면서 근본적인 문제를 찾고, 이를 해결하는 능력을 기를 수 있었습니다.

Q. 프로젝트를 시작하는 팀에게 전해줄 꿀팁을 말해주세요!

A. 승현(FE): 데일리 스크럼을 꼭 하시는 걸 추천드립니다. 개발자의 성장은 소통에서 시작한다고 생각합니다. ‘왜 이렇게 해야되지?’, ‘더 좋은 방법은 없을까?’ 와 같이 사소한 것에서 고민을 하고 서로 간에 나누는 과정을 통해 많은 성장을 할 수 있습니다. 그렇기에 데일리 스크럼으로 진행 상황을 공유하고, 문제가 발생하면 다 같이 얘기를 나누다보면 점차 성장하고 있는 자신을 확인할 수 있을 겁니다. 사소한 것이라도 좋습니다. 거창하게 생각하지 않아도 됩니다. 소통을 통해 성장하려고 노력하면 빠르게 성장할 수 있습니다.

Q. 기획자로서 프로젝트 초기에 어떤 역할을 수행하였고, 프로젝트 진행 중에 어떤 어려움을 겪었나요?

A. 성준(PM): 저는 PM으로서 프로젝트 초기에는 문제 정의와 서비스 방향을 정리하고, 핵심 사용자와 MVP 범위를 설정하는 역할을 맡았습니다 또한 기능 흐름과 기획 기준을 정리하여 저희 팀이 같은 방향을 바라볼 수 있도록 조율하였습니다 하지만 처음 맡은 PM 역할이다 보니, 프로젝트 초반에는 무엇을 시작해야 할지 막막했고, 디자인까지 함께 해야하는 상황에서 시행착오를 많이 겪었습니다 그래서 초기 방향을 잡는 데 시간이 걸리기도 했습니다. 그래도 프로젝트 진행되면서 익숙해지고 구조가 점차 정리되자, 스피드가 올라가면서 PM으로서 무엇을 해야하는지가 명확해졌고 그 과정 속에서 PM은 단순히 정리하는 역할이 아니라 도메인을 이해하고 전체 흐름과 방향을 지속적으로 고민하는 역할이라는 것을 깨닫게 되었습니다

Q. Winter Dev 프로젝트에서 개발자로 참여한 경험을 설명해 주세요. 어떤 역할을 맡았고, 주요 기술 스택은 어떻게 구성되었나요?

A. 경환(BE): 안녕하세요 저는 이번 게하르방 프로젝트에서 BE를 맡았고 주요 기술 스택은 spring, mysql, nginx 입니다. 이전에는 혼자서 BE를 맡아서 개발을 했지만 이번엔 같은 백엔드 팀원이 있어 같이 의견을 나누고 고민하는 시간이 있어 좋았습니다. api 명세서 설계나 erd 설계를 같이하면서 여러 관점과 방법에 대해 고민할수 있었고 코드리뷰를 통해 놓쳤던 부분을 다시 알게되는 부분도 있어 재미있게 개발을 하게되어 좋았습니다!

Q. 프로젝트 팀 내에서 코드 리뷰 및 테스트 프로세스는 어떻게 이루어졌나요? 코드 품질과 안정성을 유지하기 위해 어떤 노력을 기울였나요?

A. 우재(BE): 저희 팀에서는 기능 단위로 이슈를 파서 작업을 진행하였으며, PR을 올리게 되면 자동으로 디스코드 채널로 알림이 오게하여 빠른 리뷰가 가능하게끔 환경을 구축하였습니다. PR에는 어떤 기능을 어떻게 구현하였는지, 고민 사항은 어떤 것이 있었는지, 리뷰어에게 집중적으로 바라는 점은 무엇인지 적도록 하여 같이 고민할 수 있게끔 프로세스를 갖췄습니다. 또한 사소한 것에도 가벼이 넘기지 않고, 질문이 오갈 수 있는 환경을 만들어 한번 더 고민하고, 이를 통해 더 좋은 코드가 되도록 실천하였습니다. 테스트의 경우 백엔드에서 PR을 생성한 후에, 머지가 되기 전에 미리 test 브랜치를 만들어 배포를 진행하였습니다. 이를 통해 머지가 되야 테스트를 할 수 있는 것이 아닌 머지가 되지 않아도 정상적으로 통신이 잘 되는 지 확인하여 빠른 개발을 하도록 노력하였습니다.

Q. 프로젝트 개발 중 어려움을 겪은 경험이 있나요? 어떻게 해결했으며, 그 과정에서 얻은 교훈은 무엇인가요?

A. 은서(FE): 프로젝트 개발 과정에서 가장 어려웠던 점은 컴포넌트를 구현할 때, 이를 공통 컴포넌트로 분리할지 혹은 도메인 로직을 포함한 컴포넌트로 구현할지를 결정하는 과정이었습니다. 초기에는 빠른 구현에 집중하고 싶었지만, 추후 유지보수와 확장성을 고려했을 때 어떤 구조가 더 적합한지 지속적으로 고민하며 개발을 진행했습니다. 특히 프론트엔드 팀이 3명으로 구성되어 있었기 때문에, 누구나 쉽게 이해하고 재사용할 수 있는 컴포넌트 구조를 만드는 것을 목표로 삼았습니다. 이를 위해 컴포넌트의 역할과 책임을 명확히 구분하고, 공통으로 쓰이는 부분들은 다른 컴포넌트에서도 쉽게 가져다 쓸 수 있게 만들려고 노력했습니다. 이러한 경험을 통해 단순히 기능을 구현하는 데 그치지 않고, 유지보수성과 협업을 고려한 코드 구조의 중요성을 깊이 이해하게 되었습니다. 그 결과, 개발자로서 코드의 품질과 구조를 함께 고민할 수 있는 한 단계 성장한 계기가 되었다고 생각합니다

Q. 문제에 대한 개선 방향은 어떤 것이 있을까요?

A. 인식(FE):게하르방에는 게하등록, 스텝공고등록, 지원서 등록 등 퍼널형식의 기능이 많습니다. 각각의 페이지를 따로 만들어 관리하고 전역상태 라이브러리로 상태를 다루고 있지만 결국에는 한개의 만들기 기능인데 많은 페이지와 분리된 역할들이 문제라고 생각을 했습니다. 이를 해결하기 위해 useFunnel 같은 라이브러리를 도입해 핵심 기능들을 조금 더 선언적으로 관리해 나갈 예정입니다.

Q. 개발자로서의 역량 향상을 위해 어떤 노력을 기울였으며, 이 프로젝트를 통해 어떤 기술적 성장을 이루었나요?

A. 승현(FE): 계속해서 생각하고자 했습니다. 예를 들면 컴포넌트의 재사용성을 높이기 위해 재사용의 범위를 정의했습니다. 그리고 애매하다 싶으면 여러 래퍼런스를 참고하여, 저의 생각과 결부시켰습니다. 또한 초반 디렉터리 구조를 생각해서 프론트 아키텍쳐를 설계하였고, 최대한 해당 구조에 맞춰서 파일과 폴더를 정의했습니다. 결과적으로 그냥 참고하여 프로젝트에 적용하기 보다, 저의 생각과 연결하여 프로젝트를 설계하니 의도를 명확히 할 수 있었고, 저의 성장을 도모할 수 있었습니다. 그리고 리액트 네이티브라는 새로운 기술을 도입하여 해당 기술을 공부하면서 앱에 대한 이해도를 높일 수 있었습니다. 또한 개발 뿐만 아니라, 빌드하는 과정에서 환경 설정, 플랫폼별 차이를 알아가면서, iOS/Android 각각의 빌드 방식과 설정 파일의 역할을 파악할 수 있었습니다.

지금까지 게스트하우스의 불법 숙박업소 문제와 게스트하우스 정보들의 파편화를 해결하기 위해 게스트하우스 통합플랫폼 “게하르방”을 기획한 팀 Brains 이였습니다