이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 프로젝트에서 공통 로깅 라이브러리 설계를 맡았습니다. 여러 서비스가 각자 다른 방식으로 로그를 남기고 있어서 장애 때 장애 추적이 어려웠습니다. 공통 로그 포맷(타임스탬프·서비스명·트레이스 ID·레벨)을 정의하고, 각 서비스에서 최소한의 코드 변경으로 붙일 수 있도록 래퍼 클래스 형태로 설계했습니다. 초안을 팀에 공유했더니 '커스텀 필드를 추가하기 어렵다'는 피드백이 있었고, 빌더 패턴으로 선택적 필드를 확장할 수 있게 수정했습니다. 이 경험으로 공통 라이브러리는 최소한의 강제 포맷과 자유로운 확장점을 균형 있게 가져가는 것이 실제 채택률을 높인다는 것을 배웠습니다.
공통 로깅 라이브러리를 출시한 뒤 실제로 팀 내 채택률을 측정하는 것이 가장 중요한 검증이었습니다. 처음 한 달 동안은 3개 서비스 중 1개만 전환했고, 나머지 팀원들이 붙이기 불편하다는 피드백을 줬습니다. 온보딩 가이드와 README 예시 코드를 보강한 뒤 두 달째에는 전체 서비스가 전환을 완료했습니다. 이전에는 장애 발생 시 서비스마다 로그 포맷이 달라 원인 추적에 평균 40분 이상 걸렸는데, 공통 포맷 도입 후 트레이스 ID 한 줄로 흐름을 따라가는 시간이 크게 줄었습니다. 공통 라이브러리의 성공 여부는 기술적 완성도보다 실제 팀 내 채택 속도로 판단해야 한다는 걸 이때 배웠습니다.
공통 라이브러리를 처음 배포한 뒤 가장 어려웠던 부분은 기존 사용자를 깨지 않고 버전을 올리는 것이었습니다. 인턴 프로젝트가 끝난 뒤 후임 팀원이 라이브러리를 수정하면서 기존 필수 파라미터 위치를 바꾸는 변경이 들어왔고, 라이브러리를 이미 쓰던 서비스들이 런타임 오류를 냈습니다. 이후엔 CHANGELOG를 반드시 작성하고, 파괴적 변경은 메이저 버전 번호를 올려 명시적으로 구분하는 규칙을 팀에 공유했습니다.
하위 호환성을 유지하려면 선택적 파라미터는 항상 맨 뒤에 두는 컨벤션을 처음부터 설계에 넣었어야 한다는 점을 배웠습니다. 공통 라이브러리는 배포 이후에도 유지보수 비용이 계속 발생하는 제품이라는 시각이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.