예시 답변 1
약 65초
REST 타임아웃·재시도 + gRPC 타입 안전성 + 에러 응답 파싱 + 명세 vs 실동작 간극 경험
팀 프로젝트에서 외부 결제 API와 처음으로 연동하는 작업을 담당했습니다. REST API 통신에서 가장 먼저 배운 건 응답 코드만 보는 게 아니라 에러 응답의 상세 메시지도 파싱해서 처리해야 한다는 것이었습니다. 타임아웃과 재시도 처리가 빠진 첫 구현에서는 외부 서버가 느려지면 우리 서비스도 같이 멈추는 문제가 생겼습니다. 이후에는 연결 타임아웃과 읽기 타임아웃을 분리해서 설정하고 일시적 실패는 지수 백오프로 재시도하는 방식을 배웠습니다. 다른 프로토콜 경험으로는 gRPC를 써보면서 스키마 정의와 타입 안전성이 REST보다 강하게 보장되는 경험을 했습니다. API 연동에서는 명세 문서와 실제 동작이 다른 경우가 생각보다 많아서 직접 테스트해보는 과정이 중요하다는 걸 배웠습니다.
API를 통한 시스템 연동은 내 코드보다 상대 시스템의 장애 시나리오를 어떻게 처리하느냐가 핵심이라는 걸 배웠습니다.
이 결의 특징
외부 결제 API 연동에서 응답 코드만 확인하다 에러 메시지 파싱을 놓쳐 부분 실패를 감지하지 못했던 경험이 기반입니다. 타임아웃 처리 누락으로 외부 서버 지연이 곧 자신의 서비스 정지로 이어지는 의존성 문제도 겪었습니다. 이후 연결·읽기 타임아웃을 분리하고 지수 백오프 재시도를 적용한 구체적 개선 과정이 남아 있습니다.
이 결이 통하는 자리
REST와 gRPC 두 프로토콜을 모두 써보며 문서와 실제 동작 간 차이를 직접 테스트하는 과정의 필요성을 배운 경험이 통합니다. 상대 시스템의 장애 시나리오를 먼저 설계하는 방어적 접근과 API 버전 관리(v1→v2 전환)에서 필드 추가는 무해하지만 제거는 즉시 장애가 되는 비대칭적 영향을 이해할 때 살아 있습니다.