REST API 무한 호출지옥에서 벗어나는 법 - 시니어들이 실제로 쓰는 API 설계 전략
하나의 화면, 6번의 API 호출
얼마 전 동료가 만든 대시보드를 보다가 개발자 도구를 열어봤습니다. 사용자 프로필 화면 하나를 렌더링하는데 REST API 호출이 6번 발생하더라고요. 프로필 정보, 권한, 최근 활동, 알림 설정, 구독 상태, 통계 데이터... 각각 따로따로요.
개별 API는 모두 200ms 안에 응답했지만, 전체 화면이 완성되기까지는 1.5초가 걸렸습니다. 일부 데이터는 다른 API 응답에 의존적이어서 순차 실행될 수밖에 없었거든요.
이게 바로 2015년식 REST API 설계의 전형적인 함정입니다.
REST가 만들어낸 착각
REST가 인기를 끌면서 많은 팀들이 착각에 빠졌습니다. '리소스 중심 설계'가 곧 '좋은 API 설계'라고 생각하게 된 거죠.
새로운 요구사항이 생기면 새로운 엔드포인트를 추가하고, 특별한 케이스가 생기면 컨트롤러를 하나 더 만들고, 클라이언트가 달라지면 응답 형태를 또 추가하고...
코드 리뷰에서는 문제없어 보였지만, 실제 제품에서는 뭔가 항상 무거운 느낌이었습니다.
문제는 우리가 시스템 설계와 엔드포인트 증가를 혼동했다는 점입니다. 클라이언트가 백엔드의 내부 구조를 너무 많이 알아야 하는 상황이 만들어진 거죠.
진짜 문제는 '접합 부분'
제가 경험한 가장 답답한 상황은 이런 거였습니다:
- 각 서비스의 모니터링 지표는 정상
- 개별 API 응답 시간도 합격점
- 하지만 사용자는 "앱이 느리다"고 불평
개별 부품은 멀쩡한데 전체 경험이 엉망인 상황이죠.
한 서비스가 다른 서비스보다 살짝 느리거나, 네트워크 상태가 조금만 불안해져도 전체 화면 로딩이 크게 지연됩니다. 프런트엔드는 화면을 그리는 게 아니라 백엔드 서비스들과 협상하느라 바쁘고요.
시니어들의 다른 접근법
시니어 엔지니어들은 이런 패턴을 일찍 알아차립니다. 그리고 질문 자체를 바꿔버리죠.
"다음 리소스를 어떻게 노출할까?" ❌
"사용자가 실제로 무엇을 하려고 하는가?" ✅
이 변화가 사소해 보이지만, 대화의 전체 방향을 바꿉니다. 목적지가 아닌 흐름 관점에서 생각하게 되는 거죠.
경험 중심 API 설계
결과적으로 이런 구조가 나옵니다:
클라이언트
↓
사용자 액션 하나 → 요청 하나
↓
경험 API (BFF/GraphQL/통합 API)
↓
프로필 서비스, 권한 서비스, 활동 서비스...
↓
화면에 맞춰 구성된 하나의 응답
이 모델의 장점은 단순히 호출 횟수를 줄이는 것 이상입니다:
- 오케스트레이션을 제어 가능한 위치로 이동: 재시도, fallback, 캐싱, 부분 오류 처리가 모두 서버에서 처리됩니다
- 관찰 가능성 향상: 사용자 여정이 하나의 통합된 경로로 나타납니다
- 클라이언트 복잡성 감소: 앱은 비즈니스 로직 대신 UI에 집중할 수 있습니다
도구는 도구일 뿐
시니어들이 사용하는 구체적인 기술 스택을 보면:
| 상황 | 선택하는 기술 | 이유 |
|---|---|---|
| 고정된 화면, 예측 가능한 데이터 | BFF (Backend for Frontend) | 성능 최적화와 캐싱에 유리 |
| 화면이 자주 바뀌고 유연한 쿼리 필요 | GraphQL | 클라이언트가 필요한 데이터만 요청 가능 |
| 서비스 간 통신, 엄격한 계약 | gRPC | 타입 안정성과 성능 |
| 실시간 업데이트 | WebSocket/Server-Sent Events | 폴링은 2026년에 어울리지 않음 |
핵심은 특정 기술에 대한 충성심이 아닙니다. 사용자가 백엔드의 파편화 문제를 직접 해결하도록 강요하지 않는 것이 목표죠.
제가 저질렀던 실수들
솔직히 말하면, 저도 이런 실수를 여러 번 했습니다.
"엔드포인트 하나 더 추가하는 게 빠르고 간단하네?"라고 생각했던 적이 많거든요. 당장은 효율적으로 느껴졌지만, 실제로는 복잡성을 클라이언트에게 떠넘긴 것이었습니다.
비용은 이런 순서로 발생했어요:
- 사용자가 먼저 부담 (느린 로딩)
- 제품팀이 부담 (사용자 불만)
- 몇 달 후 엔지니어링 팀이 부담 (리팩토링)
2026년의 현실적인 접근
제가 최근에 본 최고의 백엔드 팀들은 REST, GraphQL, gRPC를 "종교"처럼 숭배하지 않습니다. 도구로 보지, 정체성으로 보지 않아요.
그들이 중요하게 생각하는 기준:
- 조정 비용 최소화
- 왕복 횟수 감소
- 비즈니스 로직을 오류 관리가 쉬운 곳에 배치
경험이 쌓이면서 깨닫게 되는 건, 좋은 API 설계란 모든 것을 깔끔하게 드러내는 게 아니라, 제품이 단순하게 느껴지도록 적절한 복잡성을 숨기는 것이라는 점입니다.
마무리
사용자는 서비스가 몇 개인지, 데이터베이스 테이블이 어떻게 나뉘어 있는지 관심 없습니다. 화면이 빠르고 안정적으로 작동하는지만 신경 쓸 뿐이죠.
만약 여러분의 주요 기능이 아직도 "클라이언트가 순서를 신중하게 정해야 하는 일련의 REST 호출"에 의존한다면, 문제는 언제 만들어졌느냐가 아닙니다.
문제는 시스템이 내부의 혼란을 아키텍처라고 부르며 외부로 내보내고 있다는 점이에요.