면접에서 진짜 자주 나오는 자바 질문 - 섹션 6. 스프링 MVC & REST API 설계
1. 스프링 MVC 구조에 대해 설명하시오
스프링 MVC는 Model-View-Controller 디자인 패턴을 기반으로 한 웹 프레임워크이다. 각 구성요소는 다음과 같은 역할을 수행한다:
- Controller: 요청 처리, 서비스 호출, 뷰 이름 반환
- Service: 비즈니스 로직 수행
- Repository (DAO): 데이터 접근 계층 (JPA, JDBC 등)
- Model: 응답 데이터 또는 뷰에 전달할 데이터
- View: 사용자에게 보여줄 화면 (HTML, JSON 등)
이러한 구성은 역할과 책임을 명확히 분리하여 유지보수성과 테스트 용이성을 높이는 데 기여한다.
2. RESTful API란 무엇이며, 설계 시 지켜야 할 원칙은?
REST는 자원의 표현(Representation)을 통해 상태(State)를 전달하는 아키텍처 스타일이며, HTTP 프로토콜을 기반으로 한다.
RESTful API를 설계할 때는 다음과 같은 원칙을 따른다:
- 자원(Resource)은 URI로 표현 (예: /users, /orders/1)
- 행위는 HTTP 메서드로 표현:
- GET: 조회
- POST: 생성
- PUT/PATCH: 수정
- DELETE: 삭제
- 상태 코드를 명확히 반환 (200, 201, 400, 404, 500 등)
- 무상태성(stateless): 서버는 요청 간 클라이언트 상태를 저장하지 않음
- HATEOAS, 캐시 처리, 버전 관리(v1, v2) 등의 고려도 가능
REST는 단순한 API 형태를 넘어서, 표현과 의미를 일관성 있게 설계하는 것이 핵심이다.
3. @RequestMapping, @GetMapping 등의 차이점은?
스프링에서 컨트롤러 메서드와 HTTP 요청을 매핑할 때 사용되는 어노테이션은 다음과 같다
| 어노테이션 | 설명 |
| @RequestMapping | 모든 HTTP 메서드 지원, 다양한 속성 설정 가능 |
| @GetMapping | HTTP GET 전용 축약형 |
| @PostMapping | HTTP POST 전용 |
| @PutMapping | HTTP PUT 전용 |
| @DeleteMapping | HTTP DELETE 전용 |
실무에서는 **명시적인 매핑 어노테이션(@GetMapping 등)**을 사용하는 것이 가독성과 유지보수 측면에서 유리하다.
4. DTO를 사용하는 이유는 무엇인가?
DTO(Data Transfer Object)는 클라이언트와 서버 간 데이터 전달을 위한 객체로, 주로 다음과 같은 이유로 사용된다:
- 엔티티(도메인 객체) 보호: 외부 노출로부터 내부 모델을 분리
- 요청/응답 구조 커스터마이징: 필요한 필드만 전달
- 입력 검증 처리: @Valid, @NotBlank 등의 어노테이션 활용 가능
- 계층 간 의존성 분리: 프레젠테이션 계층과 도메인 계층의 분리
면접에서는 "왜 엔티티를 직접 리턴하면 안 되는가?"라는 질문과 함께 DTO 분리 설계에 대한 판단 기준을 자주 묻는다.
면접 질문 예시
Q. "왜 엔티티(Entity)를 직접 클라이언트에게 반환하지 않고 DTO를 사용하는 것이 바람직한가요?"
답변 예시
엔티티를 직접 반환할 경우 다음과 같은 문제점이 발생할 수 있습니다:
- 캡슐화 위반 및 보안 리스크
엔티티에는 시스템 내부 로직에 필요한 민감한 필드(예: 권한, 패스워드 해시 등)가 포함될 수 있으며, 이를 그대로 노출하면 보안 취약점이 될 수 있습니다.- 계층 간 의존도 증가
프레젠테이션 계층(Controller)이 도메인 계층(Entity)에 직접 의존하게 되면, 도메인 모델 변경 시 API 응답 구조도 함께 변경될 가능성이 생기고 유지보수성이 크게 떨어집니다.- 데이터 형식 및 이름 제어 불가
엔티티는 DB 테이블 구조와 밀접하게 연결되어 있어, 프론트엔드에서 원하는 포맷으로 데이터 구조를 커스터마이징하기 어렵습니다.- 불필요한 Lazy 로딩 이슈
엔티티를 반환하면 지연 로딩된 연관 객체들이 Jackson(ObjectMapper)에 의해 순환 참조되거나, LazyInitializationException이 발생할 수 있습니다.
판단 기준
DTO를 사용할지 말지를 판단할 때 고려해야 할 기준은 다음과 같습니다:
- 클라이언트에 전달되는 데이터가 도메인 모델과 1:1로 일치하지 않는 경우
- 보안상 민감한 정보의 은닉이 필요한 경우
- 데이터 응답 구조를 명확히 통제해야 하는 경우 (필드명, 포맷 등)
- 대규모 API 시스템에서 일관된 응답 포맷과 유효성 검증을 통합 관리할 필요가 있는 경우
따라서, 실무에서는 대부분 DTO를 사용하는 방향으로 설계하며, 엔티티를 직접 반환하는 것은 간단한 테스트용 API 정도에서만 제한적으로 활용됩니다.
5. REST API 설계 시 유효성 검증과 예외 처리 전략은?
REST API는 클라이언트로부터 전달되는 데이터에 대한 유효성 검증이 중요하다. 주요 전략은 다음과 같다:
- 검증: @Valid, @Validated, @NotNull, @Email 등으로 처리
- 예외 처리:
- 전역 예외 처리(@ControllerAdvice)
- MethodArgumentNotValidException, HttpMessageNotReadableException 등 처리
- 응답 포맷 통일:
- 에러 코드, 메시지, 필드 정보 등을 포함한 JSON 구조 반환
- 로깅과 모니터링 연계:
- 오류 발생 시 로그 기록 및 추적 시스템과 연계
예외와 유효성 검증을 일관되게 처리하는 구조는 대규모 시스템에서 매우 중요한 품질 요소로 평가된다.
마무리
스프링 MVC와 RESTful API 설계는 단순 기능 구현을 넘어서, 아키텍처적 판단과 설계 기준을 묻는 대표적인 면접 영역이다. 실무 사례 중심의 설명, API 설계 원칙에 대한 명확한 이해, 일관성 있는 응답 구조 설계가 중요한 평가 포인트가 된다.