개발자라면 누구나 고민합니다. "이 API에 데이터를 다 몰아넣을까(Fat), 아니면 기능별로 잘게 쪼개서 호출하게 할까(Lean)?"
이 고민의 핵심은 결합도(Coupling)와 응집도(Cohesion), 그리고 사용자 경험(UX) 사이의 균형 잡기입니다.
1. '네이버'급 대규모 서비스: Decoupling(디커플링)이 생명
네이버 같은 MSA(마이크로서비스 아키텍처) 환경에서는 Atomic API(원자적 API) 설계를 지향합니다.
- Loose Coupling (낮은 결합도): "쇼핑 API"와 "리뷰 API"가 서로 남남이어야 합니다. 그래야 리뷰 서버가 터져도 쇼핑은 돌아갑니다. 이걸 'Fault Tolerance(결함 허용)'라고 부르죠.
- Scalability (확장성): 특정 API만 트래픽이 튈 때 해당 서버만 'Scale-out(서버 증설)' 하기 위해서 철저히 분리합니다.
- Single Responsibility (단일 책임): 한 API는 딱 한 가지 일만 잘해야 합니다. 그래야 유지보수가 편하거든요.
2. 우리의 소중한 MVP / Admin: Productivity(생산성)가 깡패
반대로 이제 막 시작하거나, 내부 관리용 대시보드라면 Coarse-grained(굵은 입도 - 그냥 '뭉치기'라고 하죠) 설계가 정답입니다.
- BFF(Backend For Frontend) 패턴: 화면(View) 하나를 위해 필요한 데이터를 백엔드에서 미리 싹 '말아서' 주는 방식입니다.
- Reduced Round-trip (네트워크 왕복 감소): 모바일이나 대시보드에서 API를 5~6번 찔러서 데이터 합치는 것보다, 한 번에 쏘는 게 로딩 속도(TTI: Time To Interactive) 면에서 훨씬 유리합니다.
- Data Consistency (데이터 정합성): 한 쿼리로 긁어오면 통계 숫자와 목록 데이터가 어긋날 일이 없습니다.
실무 API 설계 "국룰" 구조 (Dashboard 예시)
대시보드처럼 통계 + 리스트가 한 세트인 화면은 'Aggregation(집계) API' 형태로 가는 게 실무 국룰입니다.
API Response 예시
{
"summary": { "avgAge": 27.7, "totalCount": 150 },
"items": [ { "id": 1, "name": "재원" }, ... ]
}
백엔드 성능 최적화: SQL Aggregate
백엔드 단에서 for문 돌리면서 계산하는 건 초보나 하는 짓이죠. DB의 **Aggregate Function(집계 함수)**이나 Window Function을 써서 한 방에 가져오는 게 성능상 압도적입니다.
/* 실무에서 자주 쓰는 단일 쿼리 집계 */
SELECT
COUNT(*) OVER() as total_count, -- 전체 카운트와 목록을 동시에!
AVG(age) OVER() as global_avg,
u.*
FROM users u
LIMIT 10;
요약: 그래서 언제 뭘 써?
- "나중에 네이버처럼 클 건데요?" → 일단 모놀리식(Monolithic)으로 시작해서 Domain만 잘 나눠두세요. 처음부터 쪼개면 개발 속도 안 나와서 서비스 망합니다.
- "화면 로딩이 너무 느려요" → API 호출 횟수를 줄이세요. 데이터를 백엔드에서 Aggregate(집계)해서 한 번에 내려주는 게 장땡입니다.
반응형
