[2025 SUMMER DEV] 등산객 안전을 위한 스마트 산행 서비스 ‘산결’, 4!팀

프로젝트 소개

산결은 등산객들이 즐거운 산행이 될 수 있도록 돕고, 안전 사고 시 빠른 신고와 대처가 가능하게끔 돕는 산행 서비스 입니다.

팀원 소개

FE    건규	BE    정빈	BE    우재	INFRA    의찬

인터뷰

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

A. 산행 사고가 매년 10,000건 이상 발생한다는 사실을 아시나요? 산결은 등산객들의 안전한 산행을 위한 웹 애플리케이션입니다. 산행 코스 검색, 실시간 위치 추적, 안전 매뉴얼 제공 등 다양한 기능을 통해 등산의 안전성을 높이고 비상 상황에 대비할 수 있도록 도와줍니다!

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

A. 건규(FE): 앱 개발을 처음 시도하면서 빠른 실험과 변경사항 반영을 위해 웹뷰 기술을 선택했습니다. 하지만 웹과 앱 간 통신에서 예상치 못한 문제들을 마주했습니다. 기본 웹뷰 통신은 단방향 이벤트 기반으로, 메시지 형식 정의의 어려움, 웹이 준비되지 않은 상태에서의 앱의 송신 메시지 손실, 전달 성공 여부 확인 불가능 등의 한계가 있었습니다. 이를 해결하기 위해 TCP 프로토콜을 참고하여 메시지 ID 기반의 요청-응답 매칭 시스템과 3-way handshake 방식의 연결 확인 로직을 구현했습니다. WebviewBridge 클래스를 통해 양방향 통신을 추상화하고, 콜백 기반의 비동기 처리로 신뢰성 있는 웹-앱 간 통신 환경을 구축할 수 있었습니다. 이를 통해 안정적인 웹뷰 기반 하이브리드 앱 서비스를 제공할 수 있게 되었습니다

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

A. 정빈(BE): “문제를 푸는 방법은 꼭 복잡할 필요는 없다. 때론 가장 단순한 방법이 최고의 해답이 된다.” 프로젝트를 시작하기 전과 끝난 지금을 돌아보면, 가장 크게 달라진 점은 ‘문제를 해결할 수 있는 경험’이 쌓였다는 것입니다. 어느 개발자 선배에게 “개발자에게 경험은 곧 자산”이라는 말을 들은 적이 있습니다. 100번 책을 읽는 것보다, 단 한 줄의 코드를 실행하며 오류를 해결해 나가는 과정이 훨씬 값진 경험이라는 뜻이겠죠. 이번 프로젝트는 그 말을 온몸으로실감하게 만든 시간들이었습니다. 운영 환경에서만 발생하는 예외적인 오류, 인프라와의 협업에서 생긴 설정 충돌, 배포 후 백엔드만 자주 롤백되던 현상까지. OAuth, JWT Interceptor, CI/CD 배포 과정에서 반복되는 에러를 해결하며 저 스스로도 조금씩 단단해졌고, 이전보다 프로젝트를 바라보는 시야도 넓어졌습니다. 그중에서도 가장 기억에 남는 이슈는 Mountain 이라는 엔티티명 때문에 데이터 삽입이 되지 않았던 문제였습니다. 로컬환경에서는 문제없이 동작하던 코드가, 배포 환경인 AWS RDS(MySQL)에서는 insert가 되지 않았습니다. 이유는 단순했습니다. RDS에서 대소문자 구분 설정이 활성화되어 있어, 실제 테이블명은 mountain 이었는데 코드에서는 Mountain으로 참조하고 있었던 것이죠. 이 경험을 통해 운영 환경의 설정 하나가 서비스 동작에 얼마나 큰 영향을 미칠 수 있는지 몸소 느낄 수 있었습니다. 또한, 환경별 차이를 고려한 사전 점검의 중요성도 함께 배웠습니다. 그리고 또 하나, 메서드명과 내부 로직이 어긋나 생긴 코드 품질 이슈도 있었습니다. 처음엔 복잡하게 로직을 손보려 했지만, 메서드명을 명확하게 바꾸는 것만으로도 문제를 해결할 수 있었습니다. 이처럼 문제를 해결하는 방법은 반드시 복잡할 필요는 없으며, 때로는 단순하고 명확한 시각이 더 효과적일 수 있다는 점도 배울 수 있었습니다.

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

A. 우재(BE): 의사소통을 열심히, 그리고 새로운 기술적인 도전 3가지를 하라는 말씀을 드리고 싶습니다. 저희 팀은 매일 데일리 스크럼이라는 자신의 업무 진행 상황을 공유하고, 사담을 나누는 시간을 가지고 있습니다. 처음에는 이게 효율적일까 싶었지만, 프로젝트를 하면서 내 동료가 무슨 일을 현재 하고 있고, 어떤 문제점을 마주하고 있는 지 즉각적으로 알기가 힘들었습니다. 이런 내용들을 데일리 스크럼을 통해 공유하다보니 내가 모르던 사실을 알게되는 것은 물론이고, 동료가 마주하고 있는 문제점에 대해서 새로운 해결방안을 제시할 수 있어서 협업의 능률이 올라가는 것 같습니다! 개인적으로 개발자란 본인의 존재감을 끊임없이 어필 해야한다고 생각하기에 새로 시작하는 팀들도 데일리 스크럼을 가져보시는 걸 추천드립니다! 그리고 프로젝트를 하다보면 이전에 했던 프로젝트와 비슷한 코드를 작성하는 경우가 많이 있습니다. 새로 시작하는 프로젝트가 이전 프로젝트와 비교해서 본인에게 기술적인 도전이 없었다면 사실 의미있는 프로젝트라고 생각하지 않습니다. 그렇기에 새로운 기술적인 도전 3가지를 해보라고 말씀드리고 싶습니다. 레퍼런스를 찾아보고, 선배들의 레포를 찾아보면서 딱 3가지만 새로운 기술을 제대로 공부하고 프로젝트에 적용시키면 그것만으로도 충분히 성장이 많이 될 것입니다! 그래서 다들 겁먹지 마시고 최소한 3가지 기술적인 도전을 하시는 걸 추천드립니다!

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

A. 의찬(BE): 저는 엔지니어 역할을 맡았습니다. 개발자가 코드를 아무리 잘 작성하더라도 실행시킬 환경이 없으면 서버는 돌아가지 않는데요. 저는 4!팀에서 개발자들이 작성한 코드가 잘 돌아갈 수 있도록 운영 및 유지보수하였습니다. 저희 프로젝트 상황에 맞는 실행 환경을 선택하고 개발자는 비지니스 코드만 작성할 수 있도록 하는게 목표였습니다. 조금 더 설명하면 저희 프로젝트는 AWS의 ECS에서 실행되었는데 이 환경을 세팅하고, 환경변수같은 위험한 키값을 안전하게 관리하기, 깃허브에 새로운 버전의 코드가 올라오면 자동으로 업데이트 되게 하기 (CICD 파이프라인), 코드로 인프라를 관리하기(IaC), 모니터링 대시보드 구축 등을 맡았습니다. 직접 비지니스 코드를 작성하진 않았지만 프론트, 백엔드와 상호작용을 하였는데요, 프론트 개발자와 함께 Next js의 standalone 모드를 적용해서, Docker 이미지 최적화 하기, 백엔드 개발자와 함께 로그를 분석하고 장애가 난 지점을 찾아내는 등 흥미로운 경험을 많이 했던거 같네요. 주요 기술 스택으로는 AWS, Docker, Terraform을 사용했습니다. (프론트엔드: nextjs, 백엔드: springboot, 인프라: AWS, Docker, Terraform)

Q. 프로젝트의 기술적인 도전 과제나 혁신적인 부분은 무엇이었나요?

A. 건규(FE): 이번 앱 개발에서 가장 큰 도전 중 하나는 웹의 ‘툭툭 끊기는’ 네비게이션을 앱처럼 부드럽게 만드는 것이었습니다. 일반적인 웹은 페이지 이동 시 로딩 화면, 흰 화면, 점진적 콘텐츠 로딩으로 인해 앱과 같은 매끄러운 사용자 경험을 제공하기 어려웠습니다. 초기에는 스크린마다 웹뷰를 두고 앱이 네비게이션을 담당하도록 했지만, 이는 TanStack Query의 캐싱 장점을 활용할 수 없고 저장소 공유 문제, 복잡도 증가 등의 한계가 존재하였습니다. 이를 해결하기 위해 웹에서 네비게이션을 처리하되 앱처럼 동작하도록 구연하도록 했습니다. 화면 밖에 다음 페이지를 미리 렌더링하여 그려두고, Next.js의 prefetch를 활용해 성능을 최적화했습니다. 페이지 이동 시에는 미리 그려진 화면을 슬라이딩 애니메이션으로 전환하여 자연스럽게 다음 화면이 보이도록 하였습니다.결과적으로 웹의 캐싱 장점과 앱의 부드러운 UX를 모두 확보할 수 있었습니다!

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

A. 우재(BE): 저희 팀의 코드 리뷰 프로세스는 이슈 생성 -> PR 및 리뷰 요청 -> 리뷰 진행 -> 피드백 반영 후 리뷰 다시 요청 -> Merge 순서로 이뤄졌습니다. 정빈님과 저는 리뷰를 진행하면서 서로간에 몰랐던 지식을 열정적으로 가르쳐주고, 동료가 남긴 리뷰를 허투루 보내지 않고 진지하게 받아들이는 태도로 임했습니다. 남이 본인의 코드를 보고 생각을 적어준다는 것이 쉬운 것이 아니기에 동료가 나를 위해서 소비해준 시간을 의미있게 보내고자 노력했습니다. 그리고 저희가 지향하는 코드는 최대한 알기 쉬게끔, 즉 가독성이 좋은 코드를 작성하고자 노력했습니다. 결국 프로그래밍도 하나의 언어로 문서를 작성해나가는 것이다보니, 가독성을 우선시하게 되었습니다. 메소드나 변수명을 알아보기 쉽게끔 작성을 하고, 최대한 메소드는 한 가지의 기능만 하도록 쪼개는 등 동료가 코드를 읽을 때 어려움이 없게끔 작성하도록 노력하였습니다. 이러한 노력이 동료가 더욱 좋은 리뷰를 주고 받는 결과를 만들어내어 협업이 잘 될 수 있는 환경이 되었습니다. 혹시나 코드리뷰에 대해서 고민하고 있는 팀이 있다면, 동료가 봤을 때 코드를 읽기 어려운 건 아닌지 고민해 보시는 걸 추천드립니다!

Q. 팀 내 협업에서 문제는 없었는지 궁금합니다!

A. 정빈(BE): 우리가 한 것은 애자일이 아니었다. “애자일의 핵심은 빠른 개발이 아니라 유연한 개발이었다.” 이번 프로젝트에서 우리 팀은 외부 협력업체의 기획과 함께 개발을 진행했습니다. 그러나 기획은 예상보다 자주 바뀌었고, 초기에는 어떻게 대응해야 할지 몰라 한동안 개발에 제대로 착수하지 못했습니다. 계속 변경되는 와이어프레임과 정리되지 않은 정책들로 인해 혼란을 겪었고, 자연스럽게 팀 내부에는 불만이 쌓이기 시작했습니다. 당시 우리는 ‘애자일 방법론’을 도입하고 스프린트를 계획했지만, 돌이켜보면 그것은 애자일의 겉모습만 흉내낸 것이었습니다. 빠르게 개발하는 데에만 집중했지, 변화에 유연하게 대처하려는 마음가짐은 부족했습니다. 하지만 시행착오를 겪으며 점차 방향을 잡기 시작했습니다. 기획이 완전히 확정되기를 기다리기보다는, 변경 가능성을 염두에 두고 확장성과 유연성을 고려한 코드 구조를 설계하기 시작했습니다. 또, 초기에는 API 명세나 ERD 설계를 할 때 스프린트 범위를 넘어서 과도하게 미리 설계하려는 경향이 있었는데, 이는 오히려 기획 변경 시 리스크를 키우는 원인이 되었습니다. 이후에는 매 스프린트의 범위 안에서만 설계하고 구현하는 방식으로 전환하면서 훨씬 안정적인 흐름을 만들 수 있었습니다. 이 경험을 통해 진정한 애자일은 단순히 ‘빠른 개발’이 아니라, 변화에 유연하게 대처하고, 그 속에서 지속적으로 개선해 나가는 과정임을 배웠습니다. 그리고 그 유연함은 결국 소통으로부터 비롯된다는 것도 크게 깨달았습니다.

지금까지 등산객의 안전을 책임지는 스마트 산행 서비스 ‘산결’을 개발한 4!팀의 이야기를 전해드렸습니다. 실시간 위치 추적부터 긴급 상황 대응까지, 기술을 통해 안전한 산행 문화를 만들어가려는 노력이 무척 인상적이었는데요. 앞으로도 산결이 더 많은 사람들에게 도움이 되는 서비스로 성장하길 기대하겠습니다! 🏔️