이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학교 프로젝트에서 여러 팀이 공통으로 쓰는 공용 인증 모듈을 개발하면서 내부 라이브러리 설계의 어려움을 처음 느꼈습니다. 사용하는 팀마다 요구사항이 달랐고, 모든 요구를 수용하면 모듈이 복잡해지고 아무것도 수용하지 않으면 활용도가 낮아지는 딜레마가 있었습니다. 각 팀 담당자와 초기에 사용 시나리오 목록을 함께 작성하고 공통 부분만 공용 모듈에 넣는 방식으로 범위를 정했습니다.
공용 서비스에서 가장 중요한 건 변경 시 하위 호환성을 지키는 것이었는데, 인터페이스를 바꾸면 사용하는 모든 팀에 영향이 생기기 때문에 버전 관리 방식을 미리 합의했습니다. 지금도 공통 모듈을 설계할 때 확장 가능성보다 인터페이스 안정성을 우선하는 방향을 따릅니다.
인턴 프로젝트에서 공용 인증 모듈을 여러 팀이 함께 쓰도록 만드는 작업을 맡았는데, 각 팀의 요구사항이 달라 충돌이 많았습니다. A팀은 세션 기반, B팀은 JWT를 원했고, C팀은 외부 OAuth를 써야 했습니다. 처음에는 세 요구를 모두 담으려다 모듈이 복잡해졌습니다. 팀들과 회의를 열어 공용 모듈이 담아야 할 것과 각 팀이 직접 구현해야 할 것의 경계를 먼저 합의했습니다. 인증 결과를 전달하는 표준 인터페이스만 공용으로 정하고, 내부 인증 방식은 각 팀이 선택하도록 분리하자 충돌이 사라졌습니다. 공용 서비스는 기능보다 경계를 먼저 합의해야 한다는 걸 이 경험으로 배웠습니다.
인턴 프로젝트에서 공용 유틸 함수에 파라미터를 추가했는데, 이미 쓰고 있던 세 팀에서 빌드 오류가 났습니다. 작은 수정이라 사전 공유 없이 배포했는데, 공용 모듈은 의존 팀 수만큼 영향 범위가 넓다는 걸 그때 처음 실감했습니다. 이후 공용 모듈 변경 시 영향을 받는 팀 목록을 먼저 정리하고, 최소 이틀 전에 변경 내용을 공유해 의견을 받는 절차를 만들었습니다. 하위 호환을 유지하기 어려운 경우에는 버전을 올려 기존 버전을 그대로 두는 방식도 도입했습니다. 공용 서비스를 관리하는 건 코드 수정보다 팀 간 소통이 더 많은 작업이라는 걸 이 경험으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 111퍼센트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.