<div id="readability-page-1" class="page"><article id="post-web-why-reduce-api-requests" class="page" role="article"><header><p><span> <time datetime="2025-11-09T00:00:00+00:00">09 Nov 2025</time> in <a href="/web/">Web</a> </span></p><p> AWS 환경에서 클라이언트(web) → 서버(VPC 내부) 호출 시, Internet Gateway(IGW)를 통한 첫 진입은 내부 통신보다 훨씬 비싸다. 요청 수를 줄이는 것은 단순한 최적화가 아니라, 가장 비싼 네트워크 경계를 덜 넘는 설계의 문제다.</p></header><hr><ul id="markdown-toc"><li><a href="#1-서론-요청-수를-줄이는-이유를-다시-생각해본다" id="markdown-toc-1-서론-요청-수를-줄이는-이유를-다시-생각해본다">1. 서론: 요청 수를 줄이는 이유를 다시 생각해본다</a></li><li><a href="#2-aws-네트워크-구조-어디서-비용이-발생하는가" id="markdown-toc-2-aws-네트워크-구조-어디서-비용이-발생하는가">2. AWS 네트워크 구조: 어디서 비용이 발생하는가?</a><ul><li><a href="#21-igwinternet-gateway의-역할" id="markdown-toc-21-igwinternet-gateway의-역할">2.1 IGW(Internet Gateway)의 역할</a></li><li><a href="#22-내부-통신vpc--vpc은-왜-저렴한가" id="markdown-toc-22-내부-통신vpc--vpc은-왜-저렴한가">2.2 내부 통신(VPC → VPC)은 왜 저렴한가</a></li></ul></li><li><a href="#3-igw가-가장-비싼-이유" id="markdown-toc-3-igw가-가장-비싼-이유">3. IGW가 가장 비싼 이유</a><ul><li><a href="#31-경로가-길고-hop이-많다" id="markdown-toc-31-경로가-길고-hop이-많다">3.1 경로가 길고 hop이 많다</a></li></ul></li><li><a href="#32-매-요청마다-세션-초기화가-반복된다" id="markdown-toc-32-매-요청마다-세션-초기화가-반복된다">3.2 매 요청마다 세션 초기화가 반복된다</a></li><li><a href="#33-관리형-gateway-계층의-per-request-오버헤드" id="markdown-toc-33-관리형-gateway-계층의-per-request-오버헤드">3.3 관리형 Gateway 계층의 per-request 오버헤드</a></li><li><a href="#4-bulk-api로-경계-횟수를-줄이기" id="markdown-toc-4-bulk-api로-경계-횟수를-줄이기">4. Bulk API로 경계 횟수를 줄이기</a><ul><li><a href="#41-before-n번의-igw-진입" id="markdown-toc-41-before-n번의-igw-진입">4.1 Before: N번의 IGW 진입</a></li><li><a href="#42-after-한-번의-igw-진입으로-묶기" id="markdown-toc-42-after-한-번의-igw-진입으로-묶기">4.2 After: 한 번의 IGW 진입으로 묶기</a></li></ul></li><li><a href="#5-결론-요청-수가-아니라-경계-횟수가-비용을-결정한다" id="markdown-toc-5-결론-요청-수가-아니라-경계-횟수가-비용을-결정한다">5. 결론: 요청 수가 아니라 ‘경계 횟수’가 비용을 결정한다</a></li><li><a href="#참고자료" id="markdown-toc-참고자료">참고자료</a></li></ul><hr><h2 id="1-서론-요청-수를-줄이는-이유를-다시-생각해본다">1. 서론: 요청 수를 줄이는 이유를 다시 생각해본다</h2><p>필자는 최근 클라이언트에서 서버로 동일한 API를 여러 번 호출하던 구조를 한 개의 Bulk API 요청으로 통합하는 작업을 맡았다. 처음에는 아래와 같이 생각했다.</p><blockquote><p>어차피 “N번 요청하든 한 번에 N개의 데이터를 받든, 전송되는 데이터(Response)의 양은 비슷하지 않은가?”</p></blockquote><p>하지만 작업을 진행하며 알아보니, 단순히 데이터 크기의 문제가 아니었다. 요청을 여러번 보낼수록 VPC에 진입하는 횟수, 즉 Internet Gateway(IGW)를 통과하는 횟수 자체가 늘어난다는 사실을 알게 되었다.</p><h2 id="2-aws-네트워크-구조-어디서-비용이-발생하는가">2. AWS 네트워크 구조: 어디서 비용이 발생하는가?</h2><p>대다수의 웹 서비스는 AWS와 같은 클라우드 환경 위에서 동작한다. 따라서 ‘요청 수를 줄인다’는 문제를 논의할 때도 결국 그 기반이 되는 클라우드 네트워크 구조를 이해하는 것이 출발점이 된다.</p><p>AWS 네트워크는 아래와 같이 물리적으로 세 구간으로 나뉜다.</p><div><pre><code>[Public Internet] → [Internet Gateway(IGW)] → [VPC 내부(Private Subnet)]
</code></pre></div><p>이 중 <strong>Internet Gateway(IGW)</strong> 는 외부 요청이 VPC로 들어오는 유일한 관문이다. 모든 클라이언트 요청은 이 지점을 통과해야 하며, 이 구간에서 가장 큰 오버헤드가 발생한다.</p><h3 id="21-igwinternet-gateway의-역할">2.1 IGW(Internet Gateway)의 역할</h3><table><thead><tr><th>기능</th><th>설명</th></tr></thead><tbody><tr><td><strong>라우팅</strong></td><td>공용 IP ↔ 사설 IP 주소 변환</td></tr><tr><td><strong>보안 검증</strong></td><td>Security Group, NACL 규칙 확인</td></tr><tr><td><strong>트래픽 전달</strong></td><td>ALB, NAT, API Gateway로 전송</td></tr><tr><td><strong>TLS 처리</strong></td><td>ALB 단에서 연결 종료(Termination) 수행</td></tr></tbody></table><p>이 모든 과정은 요청 단위로 수행된다. 따라서 요청이 많을수록 IGW 구간의 고정 오버헤드가 누적된다.</p><h3 id="22-내부-통신vpc--vpc은-왜-저렴한가">2.2 내부 통신(VPC → VPC)은 왜 저렴한가</h3><p>VPC 내부 통신은 AWS Backbone Network 위에서 이루어진다. 이는 AWS 리전 내 전용망으로, AWS 리전 내 데이터센터(Availability Zone) 간을 직접 연결하는 물리적 전용 광섬유망으로 구성되어 있다. 이로 인해 트래픽이 인터넷의 라우팅 경로를 통과하지 않고, 오직 AWS 내부 스위치·라우터만 거치기 때문에, hop 수가 적고 전송이 빠르다.</p><table><thead><tr><th>구간</th><th>설명</th><th>지연 수준</th></tr></thead><tbody><tr><td>Pod ↔ Pod (동일 Node)</td><td>veth 인터페이스 통신</td><td>sub-ms</td></tr><tr><td>EC2 ↔ EC2 (동일 AZ)</td><td>ENI 기반 통신</td><td>sub-ms</td></tr><tr><td>AZ 간 통신</td><td>리전 내 전송</td><td>수 ms</td></tr><tr><td><strong>Internet ↔ IGW</strong></td><td>공용망 → 사설망 전환</td><td><strong>수 ms~수십 ms</strong></td></tr></tbody></table><p>즉, IGW는 논리적·물리적 hop이 가장 많은 계층이다.</p><p>그림 ① — 외부 요청 vs 내부 통신 경로</p><pre><code>graph LR
A[Web Client] --&gt;|Internet| B[IGW]
B --&gt;|VPC 내부| C[EC2/Pod]
C --&gt; D[Database]

subgraph VPC 내부
C
D
end
</code></pre><h2 id="3-igw가-가장-비싼-이유">3. IGW가 가장 비싼 이유</h2><h3 id="31-경로가-길고-hop이-많다">3.1 경로가 길고 hop이 많다</h3><p>외부에서 들어오는 요청은 다음 단계를 거친다.</p><pre><code>sequenceDiagram
Client-&gt;&gt;Internet: 공용망 전송
Internet-&gt;&gt;AWS Edge: Routing
AWS Edge-&gt;&gt;IGW: NAT + 정책 검사
IGW-&gt;&gt;ALB: TLS termination
ALB-&gt;&gt;Server: 내부 포워딩
</code></pre><p>이 중 IGW~ALB 구간은 관리형 계층이 여러 겹 존재하며 각 hop마다 수 ms 단위의 오버헤드가 누적된다.</p><h2 id="32-매-요청마다-세션-초기화가-반복된다">3.2 매 요청마다 세션 초기화가 반복된다</h2><p>HTTP 요청은 HTTPS 기반으로, 매번 <strong>TCP 3-way handshake + TLS handshake</strong>를 수행한다. IGW~ALB 구간에서 이 연결 초기화가 반복되며 요청이 많을수록 지연이 누적된다.</p><h2 id="33-관리형-gateway-계층의-per-request-오버헤드">3.3 관리형 Gateway 계층의 per-request 오버헤드</h2><table><thead><tr><th>계층</th><th>역할</th><th>비용 단위</th></tr></thead><tbody><tr><td>Internet Gateway</td><td>외부 진입</td><td>free (단, NAT/라우팅 포함)</td></tr><tr><td>NAT Gateway</td><td>outbound 트래픽</td><td>$0.045/GB</td></tr><tr><td>ALB</td><td>요청 라우팅 및 TLS 처리</td><td>$0.008/LCU + latency 수 ms</td></tr><tr><td>API Gateway</td><td>고수준 API 관리</td><td>요청당 $3.50/백만건</td></tr></tbody></table><p>즉, IGW 자체보다도 IGW를 통과하며 활성화되는 다층 관리형 서비스(NAT Gateway, ALB, API Gateway)의 조합이 비싼 것이다.</p><h2 id="4-bulk-api로-경계-횟수를-줄이기">4. Bulk API로 경계 횟수를 줄이기</h2><h3 id="41-before-n번의-igw-진입">4.1 Before: N번의 IGW 진입</h3><pre><code>graph TD
W[Web Browser]
S1[Server API /users]
S2[Server API /orders]
S3[Server API /recommendations]

W --&gt; S1
W --&gt; S2
W --&gt; S3
</code></pre><p>각 요청마다 IGW, ALB, TLS handshake를 반복하며, 결과적으로 동일한 데이터를 가져오기 위해 N배의 경계 비용을 지불하게 된다.</p><h3 id="42-after-한-번의-igw-진입으로-묶기">4.2 After: 한 번의 IGW 진입으로 묶기</h3><pre><code>graph TD
W[Web Browser]
B[Server API /bulk]
I1[\/users, /orders, /recommendations/]

W --&gt; B --&gt; I1
</code></pre><p>Bulk API를 사용하면 클라이언트는 IGW를 한 번만 통과하고, 서버 내부에서 필요한 요청들을 병렬 처리한 뒤 결과를 합쳐 응답한다.</p><p>이 방식은 요청 수를 줄이는 것이 아니라, 가장 비싼 경계(IGW) 통과 횟수를 줄이는 것에 초점이 있다.</p><h2 id="5-결론-요청-수가-아니라-경계-횟수가-비용을-결정한다">5. 결론: 요청 수가 아니라 ‘경계 횟수’가 비용을 결정한다</h2><p>요청 수를 줄이는 이유는 단순한 코드 최적화나 서버 부하 감소가 아니다. 그 핵심은 가장 비싼 네트워크 경계, <strong>Internet Gateway(IGW)</strong>를 가능한 한 적게 통과하게 만드는 데 있다.</p><p>요청이 많을수록 IGW를 여러 번 지나며 라우팅, 보안 검증, TLS handshake가 반복된다. 따라서 Bulk API로 요청을 묶는 것은 단순한 리팩토링이 아니라, IGW 진입 횟수를 줄여 고정 오버헤드를 제거하는 아키텍처적 설계다. 이 원리는 AWS뿐 아니라, 모든 클라우드 환경의 네트워크 경계 설계에도 동일하게 적용된다고 생각한다.</p><h2 id="참고자료">참고자료</h2><ul><li><a href="https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html">AWS Networking Fundamentals – 공식 문서</a></li><li><a href="https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer">AWS Data Transfer Pricing</a></li><li><a href="https://www.youtube.com/watch?v=cRdDCkbE4es">AWS re:Invent 2023 - Advanced VPC designs and new capabilities (NET306)</a></li><li><a href="https://www.infoq.com/presentations/netflix-api-graphql-federation">How Netflix Scales Its API with GraphQL Federation</a></li></ul></article></div>

개발자 이진우

Jinwoo Lee

1. 서론: 요청 수를 줄이는 이유를 다시 생각해본다
2. AWS 네트워크 구조: 어디서 비용이 발생하는가?    
2.1 IGW(Internet Gateway)의 역할
2.2 내부 통신(VPC → VPC)은 왜 저렴한가
3. IGW가 가장 비싼 이유    
3.1 경로가 길고 hop이 많다
3.2 매 요청마다 세션 초기화가 반복된다
3.3 관리형 Gateway 계층의 per-request 오버헤드
4. Bulk API로 경계 횟수를 줄이기    
4.1 Before: N번의 IGW 진입
4.2 After: 한 번의 IGW 진입으로 묶기
5. 결론: 요청 수가 아니라 ‘경계 횟수’가 비용을 결정한다
참고자료
1. 서론: 요청 수를 줄이는 이유를 다시 생각해본다
필자는 최근 클라이언트에서 서버로 동일한 API를 여러 번 호출하던 구조를 한 개의 Bulk API 요청으로 통합하는 작업을 맡았다.
처음에는 아래와 같이 생각했다.
어차피 “N번 요청하든 한 번에 N개의 데이터를 받든, 전송되는 데이터(Response)의 양은 비슷하지 않은가?”
하지만 작업을 진행하며 알아보니, 단순히 데이터 크기의 문제가 아니었다.
요청을 여러번 보낼수록 VPC에 진입하는 횟수, 즉 Internet Gateway(IGW)를 통과하는 횟수 자체가 늘어난다는 사실을 알게 되었다.
2. AWS 네트워크 구조: 어디서 비용이 발생하는가?
대다수의 웹 서비스는 AWS와 같은 클라우드 환경 위에서 동작한다.
따라서 ‘요청 수를 줄인다’는 문제를 논의할 때도 결국 그 기반이 되는 클라우드 네트워크 구조를 이해하는 것이 출발점이 된다.
AWS 네트워크는 아래와 같이 물리적으로 세 구간으로 나뉜다.
[Public Internet] → [Internet Gateway(IGW)] → [VPC 내부(Private Subnet)]
이 중 Internet Gateway(IGW) 는 외부 요청이 VPC로 들어오는 유일한 관문이다.
모든 클라이언트 요청은 이 지점을 통과해야 하며, 이 구간에서 가장 큰 오버헤드가 발생한다.
2.1 IGW(Internet Gateway)의 역할
기능
      설명
    
라우팅
      공용 IP ↔ 사설 IP 주소 변환
    
보안 검증
      Security Group, NACL 규칙 확인
    
트래픽 전달
      ALB, NAT, API Gateway로 전송
    
TLS 처리
      ALB 단에서 연결 종료(Termination) 수행
    
이 모든 과정은 요청 단위로 수행된다.
따라서 요청이 많을수록 IGW 구간의 고정 오버헤드가 누적된다.
2.2 내부 통신(VPC → VPC)은 왜 저렴한가
VPC 내부 통신은 AWS Backbone Network 위에서 이루어진다.
이는 AWS 리전 내 전용망으로, AWS 리전 내 데이터센터(Availability Zone) 간을 직접 연결하는 물리적 전용 광섬유망으로 구성되어 있다.
이로 인해 트래픽이 인터넷의 라우팅 경로를 통과하지 않고, 오직 AWS 내부 스위치·라우터만 거치기 때문에, hop 수가 적고 전송이 빠르다.
구간
      설명
      지연 수준
    
Pod ↔ Pod (동일 Node)
      veth 인터페이스 통신
      sub-ms
    
EC2 ↔ EC2 (동일 AZ)
      ENI 기반 통신
      sub-ms
    
AZ 간 통신
      리전 내 전송
      수 ms
    
Internet ↔ IGW
      공용망 → 사설망 전환
      수 ms~수십 ms
    
즉, IGW는 논리적·물리적 hop이 가장 많은 계층이다.
그림 ① — 외부 요청 vs 내부 통신 경로
graph LR
A[Web Client] -->|Internet| B[IGW]
B -->|VPC 내부| C[EC2/Pod]
C --> D[Database]
subgraph VPC 내부
C
D
end
3. IGW가 가장 비싼 이유
3.1 경로가 길고 hop이 많다
외부에서 들어오는 요청은 다음 단계를 거친다.
sequenceDiagram
Client->>Internet: 공용망 전송
Internet->>AWS Edge: Routing
AWS Edge->>IGW: NAT + 정책 검사
IGW->>ALB: TLS termination
ALB->>Server: 내부 포워딩
이 중 IGW~ALB 구간은 관리형 계층이 여러 겹 존재하며 각 hop마다 수 ms 단위의 오버헤드가 누적된다.
3.2 매 요청마다 세션 초기화가 반복된다
HTTP 요청은 HTTPS 기반으로, 매번 TCP 3-way handshake + TLS handshake를 수행한다.
IGW~ALB 구간에서 이 연결 초기화가 반복되며 요청이 많을수록 지연이 누적된다.
3.3 관리형 Gateway 계층의 per-request 오버헤드
계층
      역할
      비용 단위
    
Internet Gateway
      외부 진입
      free (단, NAT/라우팅 포함)
    
NAT Gateway
      outbound 트래픽
      $0.045/GB
    
ALB
      요청 라우팅 및 TLS 처리
      $0.008/LCU + latency 수 ms
    
API Gateway
      고수준 API 관리
      요청당 $3.50/백만건
    
즉, IGW 자체보다도 IGW를 통과하며 활성화되는 다층 관리형 서비스(NAT Gateway, ALB, API Gateway)의 조합이 비싼 것이다.
4. Bulk API로 경계 횟수를 줄이기
4.1 Before: N번의 IGW 진입
graph TD
W[Web Browser]
S1[Server API /users]
S2[Server API /orders]
S3[Server API /recommendations]
W --> S1
W --> S2
W --> S3
각 요청마다 IGW, ALB, TLS handshake를 반복하며, 결과적으로 동일한 데이터를 가져오기 위해 N배의 경계 비용을 지불하게 된다.
4.2 After: 한 번의 IGW 진입으로 묶기
graph TD
W[Web Browser]
B[Server API /bulk]
I1[\/users, /orders, /recommendations/]
W --> B --> I1
Bulk API를 사용하면 클라이언트는 IGW를 한 번만 통과하고, 서버 내부에서 필요한 요청들을 병렬 처리한 뒤 결과를 합쳐 응답한다.
이 방식은 요청 수를 줄이는 것이 아니라, 가장 비싼 경계(IGW) 통과 횟수를 줄이는 것에 초점이 있다.
5. 결론: 요청 수가 아니라 ‘경계 횟수’가 비용을 결정한다
요청 수를 줄이는 이유는 단순한 코드 최적화나 서버 부하 감소가 아니다.
그 핵심은 가장 비싼 네트워크 경계, Internet Gateway(IGW)를  가능한 한 적게 통과하게 만드는 데 있다.
요청이 많을수록 IGW를 여러 번 지나며 라우팅, 보안 검증, TLS handshake가 반복된다.
따라서 Bulk API로 요청을 묶는 것은 단순한 리팩토링이 아니라, IGW 진입 횟수를 줄여 고정 오버헤드를 제거하는 아키텍처적 설계다.
이 원리는 AWS뿐 아니라, 모든 클라우드 환경의 네트워크 경계 설계에도 동일하게 적용된다고 생각한다.
참고자료
AWS Networking Fundamentals – 공식 문서
AWS Data Transfer Pricing
AWS re:Invent 2023 - Advanced VPC designs and new capabilities (NET306)
How Netflix Scales Its API with GraphQL Federation

왜 API 요청 수를 줄여야 할까?

댓글