이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 Spring MVC 기반 커뮤니티 서비스를 만들었습니다. 사용자 수가 늘어날 것을 가정하고 Controller-Service-Repository 계층을 명확히 분리해서 설계했습니다. 초반에 Controller에 비즈니스 로직이 섞이기 시작했는데, 테스트 코드를 짜면서 의존성이 얽혀 있다는 걸 발견하고 리팩토링했습니다. 이후부터는 Service 계층에서만 트랜잭션을 처리하는 원칙을 팀 내에서 합의했고, 코드 리뷰에서도 그 기준으로 피드백을 줬습니다. 규모가 커질수록 계층 경계를 지키는 게 얼마나 중요한지를 직접 체감한 프로젝트였습니다.
계층 경계를 지키지 않으면 테스트가 먼저 어려워진다는 걸 직접 경험했고, 코드 구조가 테스트 가능성을 결정한다는 원칙이 이 프로젝트에서 자리 잡았습니다.
MVC 기반 서비스 설계에서 대규모 트래픽을 가정하면 Controller가 너무 많은 역할을 가지는 것이 첫 번째 병목이 됩니다. 팀 프로젝트에서 처음에 Controller가 비즈니스 로직까지 처리하다 보니, 테스트가 어렵고 변경 시 영향 범위가 컸습니다.
Controller는 요청 검증과 라우팅만 담당하고, 핵심 로직은 Service 레이어로 분리했더니 각 계층을 독립적으로 테스트할 수 있었습니다. 또한 자주 조회되는 데이터는 Service 레이어에서 캐싱을 적용해 DB 부하를 줄였습니다. 계층 분리가 확장성과 테스트 가능성을 동시에 높입니다. Controller 분리가 유지보수성을 만듭니다.
캐싱이 DB 병목을 흡수합니다. 계층이 명확하면 변경 영향이 줄어듭니다.
MVC 프로젝트에서 처음에는 View를 서버에서 렌더링하는 구조였는데, 모바일 클라이언트도 지원해야 하는 요건이 추가됐습니다. 동일한 비즈니스 로직을 HTML 응답과 JSON API 응답으로 각각 만드는 것이 비효율적이었습니다. Service 레이어는 그대로 유지하면서 Controller를 API 전용과 View 전용으로 분리하는 방식으로 구조를 재편했습니다. 이후 모바일 클라이언트가 API Controller를 사용하고, 웹 브라우저는 View Controller를 사용하는 방식이 됐습니다.
비즈니스 로직은 공유하면서 인터페이스만 분리하는 방향입니다. 인터페이스 분리가 다중 클라이언트를 지원합니다. Service 재사용이 중복 로직을 막습니다. 구조 분리가 확장성을 만듭니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.