이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 위치 기반 맛집 추천 앱을 만들면서 위치 권한 정책과 공용 위치 유틸 레이어를 직접 설계했습니다. 가장 어려웠던 것은 iOS와 Android의 위치 권한 모델이 달라서 공통 정책을 만드는 것이었습니다. iOS는 "항상 허용·앱 사용 중만·허용 안 함" 세 단계가 있고, Android는 버전에 따라 Foreground/Background 권한이 분리됩니다.
두 플랫폼 모두에서 작동하는 공용 인터페이스를 만들어 플랫폼 분기를 상위 레이어에서 숨겼습니다. 두 번째 어려움은 정확도와 배터리 소모의 트레이드오프였습니다. 고정밀 GPS는 배터리 소모가 크고, 낮은 정밀도는 사용성을 떨어뜨렸는데 사용자 활동 상태(이동 중/정지)를 감지해 정밀도를 동적으로 조정하는 방식으로 타협점을 찾았습니다. 이 과정에서 공용 프레임워크는 사용자가 구현 세부사항을 몰라도 쓸 수 있도록 인터페이스를 설계하는 것이 핵심이라는 것을 배웠습니다.
위치 기반 서비스의 공용 API를 설계할 때 가장 어려웠던 것은 좌표 정밀도와 개인정보 보호 사이의 균형이었습니다. 정확한 위치를 그대로 저장하면 사용자 이동 패턴이 그대로 노출되어, 위치를 격자 단위로 양자화(geohash)하는 방식을 채택해 정밀도를 조절하면서 노출을 줄였습니다. 두 번째 어려움은 레이턴시였습니다. 반경 내 데이터를 조회하는 쿼리가 일반 RDB에서 느렸고, PostGIS 공간 인덱스를 도입한 뒤 평균 응답 시간이 1.2초에서 120ms로 줄었습니다. 팀 협업은 정책 문서를 위키에 먼저 올리고, 동의한 팀원만 코드 리뷰에 참여하는 방식을 제안했습니다. 정책 논쟁이 코드 리뷰로 번지는 걸 막기 위해서였습니다. 결과적으로 세 개 서비스가 같은 위치 레이어를 공유하게 됐고, 중복 구현이 없어졌습니다.
위치 기반 공용 프레임워크를 팀 내에서 처음 만들었을 때 가장 큰 어려움은 팀마다 위치 데이터를 사용하는 방식이 달랐다는 점이었습니다. 어떤 팀은 현재 위치만 필요했고, 어떤 팀은 경로 추적이 필요했는데 하나의 인터페이스로 두 요구를 수용해야 했습니다.
전략 패턴을 적용해 위치 수집 모드를 런타임에 교체할 수 있도록 설계하면서 이 문제를 해결했습니다. 또 다른 어려움은 백그라운드 위치 수집에 대한 OS 정책이 버전마다 달라지는 것이었습니다. 정책 변경을 추상화 레이어에서 흡수하도록 설계해 각 서비스팀이 OS 정책을 직접 추적하지 않아도 되게 만들었습니다. 팀과의 협업은 주간 API 리뷰 미팅으로 맞췄고, 각 팀의 요청을 큐에 올리고 우선순위를 함께 결정하는 방식을 유지했습니다. 배포 이후 공용 레이어의 버그 한 건이 전체 서비스에 영향을 줄 수 있다는 점에서 테스트 커버리지를 높이는 게 중요한 교훈이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.