예시 답변 1
약 90초
REST API 클라이언트-서버 학습 결
REST API의 클라이언트-서버 모델은 상태를 서버가 아닌 클라이언트가 관리한다는 점에서 처음 개념을 잡을 때 혼란스러웠습니다. 실제로 API를 직접 만들어보면서 HTTP 메서드와 상태 코드의 의미를 익혔고, 특히 GET/POST/PUT/PATCH/DELETE의 멱등성 차이를 이해하게 됐습니다. 팀 프로젝트에서 API 설계 리뷰를 진행했을 때, 같은 리소스에 대해 팀원마다 다른 URI 구조를 제안해 기준을 맞추는 과정이 좋은 학습이 됐습니다.
RESTful 설계의 핵심은 URI가 리소스를 표현하고, 행위는 메서드로만 구분하는 것이라는 원칙을 이 경험으로 체득했습니다. 인증 처리에서 JWT 토큰을 헤더에 담는 방식도 직접 구현해보면서, 토큰 만료 처리와 갱신 로직이 클라이언트 쪽 상태 관리와 어떻게 연결되는지 이해했습니다. REST는 표준이 아닌 아키텍처 스타일이어서 팀마다 해석이 다르다는 결을 프로젝트를 거치며 배웠습니다.
이 결의 특징
HTTP 메서드와 상태 코드의 멱등성 차이를 직접 API를 만들며 익히고, 팀원마다 다른 URI 구조 제안을 리뷰에서 조율하며 리소스와 메서드 구분 원칙을 체득한 흔적이 있습니다.
이 결이 통하는 자리
팀 리뷰에서의 구체 조율 과정이 살아 있을 때 통합니다. REST가 표준이 아닌 아키텍처 스타일이라는 결론으로 닫힌 자리에서 면접관이 이해 깊이를 읽는 결이 보입니다.