이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
지도 기반 웹 앱 프로젝트에서 마커·팝업·경로 레이어가 여러 화면에서 반복 사용되면서 코드 중복이 심해졌습니다. 저는 공통 요소를 훅과 컴포넌트로 분리해서 맵 인스턴스를 외부에서 주입받는 구조로 만들었습니다. 처음엔 추상화가 과도하다는 의견도 있었지만, 세 번 이상 쓰이는 패턴을 기준으로 분리했더니 이후 화면을 추가할 때 코드가 절반 이하로 줄었습니다. 가장 어려웠던 건 좌표계 변환과 줌 레벨 의존성을 어떻게 인터페이스로 감출지였는데, 내부에서 처리하고 외부에는 단순 API만 노출하는 방식으로 해결했습니다. 이 경험으로 재사용 가능한 패턴은 완성된 기능이 아니라 안정적인 경계를 설계하는 것이라는 걸 배웠습니다. 재사용 패턴은 일찍 만들수록 유지비가 낮아진다는 걸 이 경험에서 배웠습니다.
경계를 명확히 설계하는 것이 패턴의 핵심이고, 구현보다 인터페이스 정의에 더 시간을 써야 한다고 생각합니다.
지도 기반 프로젝트에서 레이어 표시·숨김 상태를 명령형으로 직접 조작하는 방식이 버그 원인이 된 경험이 있습니다. 지도 인스턴스를 직접 참조해서 레이어를 on/off 하다 보니, 여러 컴포넌트에서 같은 레이어를 동시에 제어하면 충돌이 발생했습니다. 상태를 한 곳에서 관리하고 지도는 그 상태를 구독하는 구조로 바꿨더니 충돌이 사라졌습니다. 렌더링 결과가 예측 가능해진 것이 가장 큰 변화였습니다.
선언적 관리 구조는 지도 레이어에서도 동일하게 작동했습니다. 상태 단일 출처가 충돌을 막습니다. 선언이 명령보다 예측 가능합니다. 상태 중앙화가 지도 컴포넌트 안정성을 높입니다.
지도 서비스 교체 가능성을 고려해 추상화 레이어를 설계한 경험이 있습니다. 처음에는 특정 지도 API를 직접 호출하는 방식이었는데, 서비스 이전 요건이 생겼을 때 전체 코드를 수정해야 하는 상황이 됐습니다. 지도 관련 인터페이스를 공통 어댑터로 추상화하고, 각 지도 API 구현체가 그 인터페이스를 따르도록 구조를 바꿨습니다. 이후 다른 지도 API로 교체할 때 어댑터 구현만 추가하면 됐습니다.
외부 서비스 의존을 인터페이스로 분리하면 교체 비용이 낮아집니다. 어댑터가 교체 비용을 낮춥니다. 인터페이스가 외부 의존을 가립니다. 추상화 설계가 유연성을 만듭니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.