자바 개발자 면접에서 RESTful API로 빛나는 법

자바 개발자 면접에서 RESTful API로 빛나는 법

• RESTful API란? 개념을 넘어서
• RESTful 설계 원칙, 면접을 위한 해석
• 면접관이 좋아하는 RESTful 질문 5가지
• 나쁜 API 설계, 어디서 실수할까?
• Spring Boot에서 RESTful 적용 방법
• JSON, HTTP, 상태코드와의 연결고리
• 내가 겪은 RESTful 면접 실전 사례
• REST 이후는? GraphQL, gRPC까지

 

RESTful API란? 개념을 넘어서

햇살이 머무는 오후, 나는 조용히 노트북을 열었다. 반복된 공부에도 머리 한켠이 불안했다. 'RESTful API'라는 단어는 익숙하지만, 정말 제대로 이해하고 있는 걸까? 자바 개발자 면접을 준비하면서 가장 자주 마주친 질문 중 하나가 바로 이 주제였다. 단순한 정의나 기능 설명을 넘어, 그 철학과 배경까지 꿰뚫어봐야 면접관의 마음을 움직일 수 있다는 걸 깨달은 건 그리 오래되지 않았다.

REST는 Roy Fielding이 자신의 논문에서 소개한 개념으로, 웹의 아키텍처 스타일에서 영감을 받아 탄생했다. '자원의 표현(Representation)'을 HTTP의 다양한 메서드로 주고받는 방식은, 정보 중심의 웹 시대에 딱 맞는 설계 모델이었다. 중요한 건 이 API가 단지 데이터를 전달하는 기술이 아니라, '자원 중심'이라는 명확한 철학을 가지고 있다는 점이다. 모든 URI는 자원(resource)을 나타내며, 클라이언트는 그 자원에 대해 CRUD(Create, Read, Update, Delete)를 HTTP 메서드로 요청한다.

예를 들어, `/users`는 사용자라는 자원을 의미한다. `GET /users`는 모든 사용자를 조회하고, `POST /users`는 새로운 사용자를 추가한다. 이처럼 RESTful API는 의미 있는 URI 구조와 일관된 HTTP 메서드 사용을 통해 누구나 직관적으로 이해할 수 있는 API를 설계하게 해준다.

“REST는 기술이 아니라 철학이다. 웹을 닮은 시스템을 설계하는 방법이다.”

면접에서 RESTful API를 묻는 질문은 단순한 정의를 원하는 것이 아니다. 얼마나 명확하게 이해하고 있는지, 그리고 그 개념을 실무와 연결지을 수 있는지를 테스트한다. 이 질문을 마주했을 때, 머뭇거리는 대신 URI 설계 경험, HTTP 상태코드 분기, 클라이언트 서버 간 분리 원칙을 스토리처럼 설명할 수 있어야 한다. 그것이 자바 개발자로서의 깊이를 보여주는 첫 관문이다.

 

RESTful 설계 원칙, 면접을 위한 해석

면접을 준비하며 가장 많이 오해한 부분 중 하나는 'RESTful 설계 원칙'의 수동적 암기였다. 면접관은 6가지 원칙을 줄줄이 외우는 걸 듣고 싶지 않다. 오히려 그것이 실제 API 설계에 어떤 식으로 적용되고, 어떤 장점과 단점을 낳는지에 관심이 있다.

첫 번째 원칙은 '클라이언트-서버 구조'다. 이 구조는 시스템을 유연하게 만든다. 프론트엔드와 백엔드가 명확히 분리되기 때문에, 개발과 배포가 독립적으로 가능하다. 두 번째는 '무상태성(Stateless)'이다. 서버는 요청 간에 클라이언트 상태를 저장하지 않으며, 모든 요청은 자체적으로 완결성을 가져야 한다. 이를 통해 확장성과 안정성을 확보할 수 있지만, 반대로 로그인 세션 관리와 같은 기능에는 불편함이 따른다.

“REST의 무상태성은 확장성과 보안의 열쇠이자, 세션 관리의 고민이기도 하다.”

세 번째는 '캐시 처리 가능(Cacheable)'이다. 자원의 응답은 캐시될 수 있어야 하고, 이는 시스템 부하를 줄이는데 결정적 역할을 한다. 네 번째는 '계층화된 시스템(Layered System)'이다. 클라이언트는 중간 서버나 프록시 서버를 구분하지 않으며, 이를 통해 보안 강화와 로드밸런싱이 가능해진다.

다섯 번째 원칙은 '일관된 인터페이스(Uniform Interface)'다. 이는 REST의 가장 핵심적인 철학이다. URI는 자원 자체를 표현하고, 행위는 HTTP 메서드로 구분된다. 여섯 번째는 'Code on Demand(선택 사항)'이다. 서버가 실행 가능한 코드를 클라이언트에 전달할 수 있다는 개념이지만, 이는 실무에서 거의 사용되지 않는다.

TIP

면접에서는 6가지 원칙을 단순히 나열하기보다, 각각이 실무에서 어떤 문제를 해결하고 어떤 제약을 주는지를 본인의 경험과 함께 말하는 것이 효과적입니다.

 

면접관이 좋아하는 RESTful 질문 5가지

자바 개발자 면접에서 RESTful API 관련 질문은 빠지지 않는 단골 메뉴다. 하지만 단순히 “RESTful API란 무엇인가요?” 같은 정의 문제로 끝나지 않는다. 실제로는 그 개념을 응용할 수 있는 능력, 그리고 코드 수준에서 어떻게 구현하는지를 보는 질문이 뒤따른다. 그 중에서도 자주 등장하는 다섯 가지를 꼽아보자.

첫 번째 질문은 “RESTful API에서 URI는 어떻게 설계하시나요?”이다. 이 질문은 단순한 문법 문제가 아니다. 면접관은 응답자의 정보 설계 능력, 자원 식별 방식, 명확성과 일관성을 본다. `/users/{id}/posts` 같은 계층적 구조나, 복수형을 사용해야 하는 이유 등을 본인의 경험으로 설명할 수 있어야 한다.

두 번째는 “HTTP 상태 코드를 어떻게 사용하시나요?”다. 여기서 응시자는 단순히 `200`, `404`, `500`을 외우는 데 그쳐선 안 된다. 예를 들어, 자원이 없을 때 `404 Not Found`, 서버 오류는 `500 Internal Server Error`, 잘못된 요청은 `400 Bad Request`, 인증 실패는 `401 Unauthorized` 등 구체적인 예시와 함께 설명할 수 있어야 한다.

“정답보다 중요한 건, 맥락에 맞게 설계하고 설명하는 능력이다.”

세 번째는 “RESTful 방식의 단점은 무엇이라고 생각하나요?”이다. 많은 지원자가 이 질문에서 멈칫한다. 예를 들어, REST는 무상태성을 추구하지만 그로 인해 사용자 맞춤형 경험에 한계가 있고, URI 길이에 따라 제한이 발생할 수 있으며, 복잡한 쿼리 구조를 표현하기가 어려울 수 있다는 점 등을 지적할 수 있다.

네 번째는 “RESTful API를 설계하며 고려한 보안 요소는?”이다. JWT, OAuth, HTTPS 적용, 데이터 검증, Rate Limiting 등 다양한 요소가 여기 포함된다. 마지막으로 자주 나오는 질문은 “REST와 SOAP의 차이는?”이다. 이때는 REST의 경량성, 확장성, JSON 중심 구조와 SOAP의 복잡한 XML 구조, 고정된 계약 방식 등을 비교하면 효과적이다.

TIP

실제 면접 상황을 가정해보고, 예상 질문에 대해 자신만의 언어로 스크립트를 작성해보세요. 외운 문장보다, 체화된 설명이 면접관의 신뢰를 끕니다.

 

나쁜 API 설계, 어디서 실수할까?

우리는 보통 성공적인 설계만을 공부하지만, 면접에서는 실패 사례나 나쁜 예시를 논리적으로 설명하는 것이 더 깊은 이해를 보여준다. 실제로 RESTful API 설계에서 흔히 저지르는 실수들이 있다. 그것들을 면접에서 잘 짚어낸다면, 단순한 이론가가 아닌 실무형 개발자로 보일 것이다.

대표적인 예는 HTTP 메서드를 무시한 URI 설계다. 예를 들어, `GET /deleteUser?id=5` 같은 URI는 RESTful하지 않다. 자원 삭제는 `DELETE /users/5`처럼 HTTP 메서드로 표현해야 한다. 또 다른 오류는 URI에 동사를 넣는 경우다. `/getAllUsers`, `/createUser`처럼 행위를 URI에 담으면 REST의 자원 중심 철학과 어긋난다.

또한 응답 구조가 일관되지 않은 경우도 많다. 예를 들어, 일부 API는 성공 시 단순한 문자열을 반환하고, 실패 시에는 복잡한 JSON 오류 메시지를 반환하는 경우가 있다. 이런 경우는 API 사용자에게 큰 혼란을 준다. 성공이든 실패든, 응답 포맷은 일관돼야 한다.

“RESTful API는 직관적이지만, 설계자의 철학이 흔들리면 가장 비직관적인 구조가 된다.”

면접관은 단순히 당신이 REST를 알고 있는지를 넘어, 나쁜 설계를 식별하고 개선할 수 있는 능력이 있는지를 본다. 그래서 본인이 참여한 프로젝트에서 실제로 겪었던 API 설계의 문제점과 그것을 개선해나간 과정을 이야기하면 설득력 있는 답변이 된다.

이처럼 나쁜 사례를 기반으로 한 자기 성찰은 지식의 깊이를 드러낸다. 또한, 본인이 이전에 잘못 설계했던 경험이 있다면, 그것을 숨기지 말고 오히려 어떻게 극복했는지를 공유하라. 그것이 바로 성장의 언어다.

 

Spring Boot에서 RESTful 적용 방법

자바 개발자 면접에서 RESTful API를 물을 때, 면접관은 종종 “Spring Boot에서는 어떻게 적용하시나요?”라고 묻는다. 이 질문에는 단순한 이론을 넘어 실무 역량을 묻는 숨은 의도가 있다. 실제로 많은 자바 프로젝트는 Spring Boot를 기반으로 개발되며, RESTful API 설계 또한 이 프레임워크 위에서 구현된다.

Spring Boot에서 RESTful API를 구현하는 핵심은 `@RestController`, `@RequestMapping`, `@GetMapping`, `@PostMapping` 등의 어노테이션이다. 예를 들어, 다음과 같은 방식으로 `/users` URI에 대한 요청을 처리할 수 있다:

@RestController
@RequestMapping("/users")
public class UserController {
  @GetMapping("/{id}")
  public ResponseEntity getUser(@PathVariable Long id) {
    return ResponseEntity.ok(userService.findById(id));
  }
}

이처럼 각 HTTP 메서드에 맞는 어노테이션을 활용하고, `ResponseEntity`를 통해 명확한 상태코드와 메시지를 반환하는 것이 RESTful한 방식이다. 또한 `@Valid`, `@RequestBody` 등을 활용한 입력값 검증, 예외처리 핸들러(`@ExceptionHandler`) 등을 통해 API의 품질을 높일 수 있다.

“RESTful은 코드 스타일이 아니라, 의도를 명확히 드러내는 약속이다.”

Spring Boot의 강점은 복잡한 설정 없이도 REST API를 신속히 만들 수 있다는 데 있다. 하지만 그만큼 개발자의 기본 철학이 설계에 고스란히 반영되기 때문에, 잘못된 이해로 접근하면 오히려 혼란스러운 API가 될 수 있다. 면접에서 이 부분을 강조하면 깊은 통찰을 보여줄 수 있다.

 

JSON, HTTP, 상태코드와의 연결고리

RESTful API를 설명하면서 JSON과 HTTP 상태 코드에 대해 구체적으로 언급하는 개발자는 면접에서 더욱 신뢰를 얻는다. 이는 단순히 기술을 나열하는 것이 아니라, API 설계가 어떻게 웹의 본질과 연결되는지를 이해하고 있다는 뜻이기 때문이다.

JSON은 RESTful API에서 가장 흔히 쓰이는 데이터 형식이다. 그 이유는 가볍고, 사람이 읽기 쉬우며, 자바스크립트와의 호환성이 뛰어나기 때문이다. Spring Boot에서는 `@ResponseBody` 혹은 `@RestController`를 통해 객체를 자동으로 JSON으로 직렬화해 반환할 수 있다.

HTTP 상태 코드는 클라이언트와의 약속이자 소통의 언어다. `200 OK`는 성공, `201 Created`는 자원 생성, `204 No Content`는 성공했지만 응답 데이터가 없음을 의미한다. 반면, `400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, `404 Not Found`, `500 Internal Server Error` 등은 오류의 종류를 명확히 전달한다.

TIP

면접에서 HTTP 상태 코드를 설명할 땐, 단순히 외우기보다 자신이 어떤 기준으로 어떤 상황에 어떤 코드를 선택했는지를 이야기하세요. 이 과정은 실무 감각을 증명하는 중요한 포인트입니다.

예를 들어, 유저 로그인 실패 시 어떤 상태 코드를 쓸 것인지 물었을 때, 단순히 401이라고 답하기보다 “JWT 기반 인증을 사용할 경우, 토큰 만료 시엔 401을, 권한 부족 시엔 403을 구분해서 반환한다”고 설명한다면 큰 인상을 줄 수 있다.

 

내가 겪은 RESTful 면접 실전 사례

그날의 대화는, 지금도 마음 깊이 남아 있다. 서울 강남의 한 스타트업 면접장에서, 나는 RESTful API에 대한 예상치 못한 질문을 받았다. “RESTful하게 설계했다고 하셨는데, 어떤 기준으로 URI를 나누셨나요?”라는 질문이었다. 평소 연습하던 정의나 메서드 종류로는 이 질문에 충분히 답할 수 없었다.

내가 참여했던 프로젝트는 여행 상품을 검색하고 예약하는 시스템이었다. 나는 `/packages`, `/packages/{id}` 같은 자원 중심 URI를 설계했고, 필터링은 `GET /packages?region=제주&theme=힐링` 방식으로 구현했다. 나는 면접관에게 이 구조가 사용자 입장에서 얼마나 직관적이고, API 문서를 읽지 않아도 어떤 요청을 할지 감이 오는 방식이라는 점을 설명했다.

또한, 예약 확정을 위한 API에 대해선 `POST /bookings`를 사용하고, 중복 예약 방지 및 트랜잭션 처리를 어떻게 구현했는지를 함께 설명했다. 나는 이 경험을 통해 단지 RESTful이 기술적 용어가 아니라, 사용자 경험과 소통을 위한 방식임을 말하고 싶었다.

“기술은 결국 사람을 향한다. RESTful은 사용자를 위한 배려의 설계다.”

그 면접은 나에게 하나의 전환점이 되었다. 단순히 이론을 외우는 개발자에서, 사용자와 서버, 클라이언트 간의 흐름을 이해하고 설계하는 개발자로 조금은 나아갈 수 있었기 때문이다. 이후 어떤 면접에서도 나는 RESTful에 대한 질문을 두려워하지 않게 되었다. 오히려 내가 자신 있는 영역이 되었다.

 

REST 이후는? GraphQL, gRPC까지

기술은 멈추지 않는다. RESTful API는 여전히 가장 널리 쓰이는 웹 API 구조이지만, 최근 몇 년 사이 GraphQL, gRPC와 같은 새로운 기술들이 등장하며 그 자리를 조금씩 나누어 갖고 있다. 특히 실시간 데이터, 복잡한 요청 응답 구조를 처리해야 하는 시스템에서는 REST만으로는 한계가 있는 것도 사실이다.

GraphQL은 페이스북이 만든 API 질의 언어로, 클라이언트가 필요한 데이터만 정확히 요청할 수 있는 장점이 있다. REST는 자원 단위로 설계되기 때문에 여러 개의 요청이 필요한 경우가 많지만, GraphQL은 한 번의 요청으로 원하는 데이터 트리 전체를 가져올 수 있다. 이로 인해 모바일 환경이나 프론트엔드 성능 최적화 측면에서 큰 장점을 가진다.

반면 gRPC는 구글이 만든 RPC(Remote Procedure Call) 기반 프레임워크로, 바이너리 프로토콜을 사용해 속도가 빠르다. 특히 마이크로서비스 아키텍처(MSA)에서 서비스 간 통신에 효과적이다. 단점은 가독성과 디버깅이 REST보다 어렵다는 점이다.

“REST는 익숙함이고, GraphQL은 유연함이며, gRPC는 속도다. 선택은 목적에 따라 달라진다.”

자바 개발자 면접에서도 이런 기술 트렌드를 아는 것이 경쟁력을 높여준다. “RESTful만 사용해보셨나요?”라는 질문에 “실무에서는 REST를 주로 썼지만, 최근에는 GraphQL 구조도 테스트해보고 있습니다”라는 한마디는 당신을 기술에 열려있는 사람으로 만들어준다.

RESTful API는 여전히 강력하고 유효한 구조다. 하지만 기술은 흐름이고, 면접은 그 흐름에 올라탈 수 있는 사람을 찾는 자리다. RESTful의 본질을 이해하면서도, 새로운 기술에 대해 열려 있는 태도. 그것이 진짜 자바 개발자가 면접에서 빛나는 법이다.