API 게이트웨이
API Gateway
API 게이트웨이란?
- 모든 요청이 거치는 '정문'
- 인증·라우팅·제한을 한곳에서
- 마이크로서비스 앞단
API 게이트웨이를 앞단에 세우면 클라이언트가 기억해야 할 주소가 하나로 줄어듭니다. 모바일 앱이 주문·재고·정산 서비스의 도메인을 각각 들고 있을 필요가 없고, 내부에서 서비스를 쪼개거나 서버를 옮겨도 앱을 새로 배포하고 심사를 기다릴 일이 사라집니다. 달라지는 것은 호출 횟수가 아니라 변경이 바깥으로 새어 나가는 범위입니다. 내부 구조와 외부에 약속한 인터페이스를 분리해 두는 장치로 이해하는 편이 정확합니다.
비슷해 보이는 것들과 경계를 그어 두면 설계가 쉬워집니다. 로드밸런서는 같은 서비스의 여러 대에 트래픽을 고르게 나누는 일에 집중하고, 서비스 메시는 서비스끼리 주고받는 내부 통신을 다루며, 게이트웨이는 외부에서 들어오는 남북(north-south) 트래픽을 맡습니다. 설정값도 꽤 구체적입니다. 제휴사 키는 분당 60회, 내부 관리자 도구는 분당 600회처럼 발급 키별로 한도를 나누고, 응답 타임아웃은 보통 3~10초로 잡으며, 한 단을 더 거치며 붙는 지연은 수 밀리초에서 수십 밀리초 수준입니다. 클라이언트 종류마다 응답 모양을 다르게 조립해야 한다면 그것은 게이트웨이가 아니라 BFF(Backend For Frontend)의 몫입니다.
현장에서 가장 자주 어긋나는 지점은 게이트웨이에 업무 로직이 쌓이는 것입니다. 할인 계산이나 회원 등급 분기를 "여기서 한 번에 처리하면 편하다"며 넣기 시작하면, 어느 팀이 배포하든 전 서비스가 함께 멈추는 새로운 단일 장애점으로 변합니다. 이중화를 미뤄 두었다가 게이트웨이 한 대가 죽는 바람에 멀쩡한 서비스 열 개가 통째로 먹통이 되는 사고도 흔합니다. 인증을 정문에서 했으니 내부는 무방비로 둬도 된다는 생각 역시 위험합니다. 내부망이 뚫리는 순간 전 서비스가 열리므로, 내부 서비스에도 최소한의 토큰 검증은 남겨 두어야 합니다.
마이크로서비스 아키텍처의 확산과 함께, 여러 서비스 앞단의 단일 진입점 패턴으로 정착했습니다.
가상의 사례로 살펴보겠습니다. 임직원 320명 규모의 온라인 식품유통 A사는 자사 앱과 웹, 제휴몰 6곳이 내부 서비스 11개를 각자 직접 호출하는 구조였습니다. 인증 코드가 클라이언트마다 조금씩 달라 토큰 만료 정책 한 줄 바꾸는 데 2주가 걸렸고, 제휴몰 한 곳의 재고 조회 폭주로 주문 서비스까지 12분간 멈춘 적도 있었습니다.
- 플랫폼팀 리더가 3주치 호출 로그를 뽑아보니 전체 요청의 41%가 재고 조회였고, 그중 절반이 제휴몰 한 곳에서 나왔습니다. "막을 자리 자체가 없는 게 문제"라는 말이 회의에서 나왔습니다.
- 관리형 게이트웨이를 정문으로 세우고 제휴몰 API부터 옮겼습니다. 백엔드 담당 과장은 기존 도메인을 3개월간 열어 둔 채 트래픽을 10%→50%→100%로 단계 이전하는 방식을 택했습니다.
- 토큰 검증을 게이트웨이 한곳으로 모으고 제휴사 키별 한도를 분당 60회로 걸었습니다. 초과분은 429로 돌려보내되 재시도 간격을 응답 헤더에 담아 제휴사 개발자에게 안내했습니다.
- "등급별 할인 계산도 게이트웨이에서 하자"는 제안이 나왔지만 CTO가 업무 로직은 각 서비스에 둔다는 원칙으로 반려했습니다. 게이트웨이는 인증·라우팅·제한·로깅 네 가지만 담당하도록 못 박았습니다.
- 가용 영역 2곳에 게이트웨이를 이중화하고 5초 헬스체크와 장애 시 자동 전환을 붙였습니다. 인프라 담당자가 한 대를 강제로 내리는 훈련을 분기마다 돌리기로 했습니다.
- 6개월 뒤 토큰 정책 변경 작업은 2주에서 반나절로 줄었고, 제휴몰발 장애는 같은 기간 4건에서 0건이 됐습니다. 평균 응답 지연은 9ms 늘었지만 장애로 날린 주문 손실이 사라져 현업도 수긍했습니다.