출세한 익룡님의 면접 결과

핵심 차이를 정확하게 짚으셨습니다. `@ResponseBody`가 반환 객체를 직렬화해 HTTP 응답 바디에 담는 역할을 하고, `ResponseEntity`가 상태 코드·헤더·바디를 통합적으로 제어할 수 있다는 점을 명확히 구분하셨습니다. 한 단계 더 나아가자면, `ResponseEntity` 자체가 내부적으로 `@ResponseBody`의 동작을 포함하고 있어 두 방식이 상호 배타적이지 않다는 점, 그리고 `@ResponseBody`만 사용할 경우 상태 코드를 변경하려면 `@ResponseStatus` 어노테이션에 의존해야 한다는 트레이드오프도 함께 언급하면 더욱 완성도 높은 답변이 됩니다. 예를 들어 "리소스 생성 API에서 201 Created와 Location 헤더를 함께 반환해야 할 때 `ResponseEntity`를 선택하는 것이 적합하다"처럼 실제 사용 맥락과 연결해 설명하면 실무 이해도를 잘 보여줄 수 있습니다.

실무와 연결된 구체적인 예시(상품 등록 시 중복 여부에 따른 HTTP 상태 코드 분기)를 통해 ResponseEntity의 핵심 사용 이유를 정확히 짚어주셨습니다. 여기서 한 단계 더 나아가면, 중복 상품의 경우 409 Conflict, 정상 등록의 경우 201 Created처럼 의미론적으로 적절한 상태 코드를 선택하는 이유까지 설명할 수 있다면 더욱 완성도 높은 답변이 될 것입니다. 추가로 ResponseEntity에서 Location 헤더를 함께 반환하는 패턴(예: 생성된 리소스의 URI를 Location에 담아 반환)도 REST API 설계 관점에서 자주 활용되므로, 헤더 제어 측면도 함께 숙지해두시면 좋겠습니다.

파일 다운로드 시나리오를 정확히 짚으셨고, "브라우저에게 렌더링 대신 저장하라고 알려줄 방법이 헤더밖에 없다"는 핵심 이유를 자기 언어로 잘 설명하셨습니다. 다만 한 단계 더 나아가 실제로 어떤 헤더를 어떤 값으로 설정하는지까지 언급하셨다면 더욱 완성도 높은 답변이 됐을 것입니다. 예를 들어 "Content-Disposition: attachment; filename=\"orders.csv\"를 헤더에 세팅한다"처럼 구체적인 헤더 이름과 값을 함께 제시하면 면접관에게 실무 경험이 명확히 전달됩니다. 다음 면접에서는 ResponseEntity 사용 시 설정한 헤더의 키·값까지 바로 말할 수 있도록 준비해두시면 좋겠습니다.