애플리케이션 딜리버리의 분류와 발전 과정
지난 20년 가까이 제 글을 따라오셨다면 애플리케이션 아키텍처가 애플리케이션 제공에 깊은 영향을 미친다는 걸 이미 아실 겁니다. 앱이 단지 어떻게 만들어지는지가 아니라, 어떻게 작동하고, 확장되며, 장애가 발생하는지, 그리고 가장 중요한 건 우리가 구축한 인프라를 통해 어떻게 이동하는지가 핵심입니다. 그리고 에이전트 아키텍처가 그 모든 것을 완전히 바꾸고 있습니다.
이번 변화를 위해서는 단순한 프로토콜 지원이나 보안 기능을 넘어서는 조치가 필요합니다. 분류 작업이 반드시 필요합니다.
업계는 오랫동안 트래픽을 분류해왔지만, 주로 차단하는 데 Focus 해왔습니다. 여러분도 아시다시피 분류를 통해 봇을 막고, 위협을 걸러내며, 악성 페이로드에 WAF 정책을 적용해왔죠. 이건 기본 중의 기본입니다. 보통 트래픽 분류는 보안 목적에 국한돼 왔습니다.
AI가 트래픽과 그 처리를 위한 자원을 완전히 바꾸고 있습니다. 에이전트 아키텍처는 어떨까요? 에이전트 아키텍처는 단순히 게임의 규칙을 바꾸는 수준이 아니라, 게임 자체를 근본적으로 변화시킵니다.
AI 도입 속도는 과거 어떤 기술보다 빠르며, 상담원도 이미 기업 현장에 진입했습니다.
모든 POST는 요청일 수도, 목표일 수도, 혹은 스택을 분석하는 AI 에이전트일 수도 있습니다. 오케스트레이션을 시작하고, 재귀적인 워크플로를 트리거하거나, 200토큰 프롬프트가 20,000토큰으로 확장되어 백엔드를 마비시킬 수도 있습니다. 인프라는요? 아직도 모든 POST를 똑같이 취급하고 있습니다.
그게 바로 문제입니다.
현대 트래픽은 단순한 데이터가 아니라 하나의 작업이자 결정입니다. 라우팅하기 전에 트래픽을 분류하는 능력이 앱의 반응성, 가용성, 그리고 무엇보다 보안을 책임집니다.
1. 연결 기반 라우팅(기존 방식)
익숙한 것부터 시작하겠습니다. 4계층(L4) 라우팅에 기반한 기존 트래픽 관리 모델이 여전히 인터넷의 많은 부분을 지탱합니다. 이 방식은 기본적인 매개변수에 의존합니다:
- L4 라우팅: IP 주소와 포트 번호 같은 전송 계층 정보를 토대로 판단합니다.
- 경로 기반 라우팅: 일반적으로 애플리케이션 계층(7계층)에서 URL 경로를 제한적으로 검사합니다.
- 균일한 풀: 백엔드 서버를 전문 기능과 관계없이 동일하게 운영합니다.
- 부하 분산: 서버 과부하를 막기 위해 연결을 고르게 분배합니다.
문제는 무엇일까요? 이 모델은 요청의 의미를 제대로 인식하지 못합니다. 트래픽을 다양한 요구가 담긴 여러 작업이 아닌, 동일한 패킷으로만 간주합니다. 생성 AI, 내장된 대형 언어 모델(LLM), 에이전트 기반 시스템이 중요한 오늘날, 모든 트래픽이 같지 않다는 점에서 이러한 인지 부재는 점점 더 큰 문제입니다.
두 가지 HTTP POST 요청을 살펴보겠습니다.
- 사용자 프로필을 업데이트하는 것처럼 간단한 CRUD(생성, 조회, 수정, 삭제) 작업일 수 있습니다.
- 또 다른 방법으로 AI 기반 추론 루프를 실행해 다섯 개의 후속 도구를 호출하고, 데이터베이스에 기록하며, 장시간 진행되는 텍스트 요약 작업을 시작하는 복잡한 다중 에이전트 워크플로를 실행할 수 있습니다.
인프라가 이러한 요청을 똑같이 처리하고 동일한 라우팅 규칙, 타임아웃, 백엔드 서버를 사용한다면 문제가 발생할 수 있습니다. 리소스를 많이 소모하는 AI 작업을 가벼운 데이터베이스 쿼리처럼 처리하면 병목 현상, 장애, 성능 저하로 이어집니다. 현대 트래픽은 더 똑똑한 관리를 요구합니다.
2. 분류 기반 라우팅(현행/전환기)
우리는 수년 동안 L7 라우팅을 수행해 왔습니다. 경로를 매칭하고, 페이로드를 검사하며, 헤더를 분석해 어느 풀로 트래픽을 보낼지 결정합니다. 이것이 바로 콘텐츠 기반 라우팅입니다. 효과적입니다. 하지만 요청에 무엇이 포함됐는지만 알 수 있을 뿐, 왜 요청이 발생했는지는 알 수 없습니다.
우리가 앞으로 나아가려면 상황에 맞는 분류가 필요합니다.
- L7 이상에서 작동하며, 단순한 페이로드 검사를 뛰어넘습니다.
- 트래픽을 의도, 복잡성, 비용 기준으로 분류합니다.
- 요약 작업인가요, 아니면 사용자 로그인인가요?
- 재귀적이거나 AI 생성인지, 지연에 민감한가요?
- 풀을 구분하는 기준은 단순한 용량이 아니라 기능입니다.
- 라우팅 결정은 단순한 형식이 아니라 목적을 중심으로 이루어집니다.
우리는 트래픽을 '제공할 콘텐츠'가 아닌 '처리할 작업'으로 전환하는 방법을 제시합니다. 요청을 어디로 보내야 할지, 어떻게 우선순위를 정할지, 그리고 요청이 달성하려는 목표에 따라 어떤 정책을 적용할지 실시간으로 판단할 수 있습니다. 이를 의도 기반이라고 합니다. 문맥 인식이라 부르셔도 됩니다. 이름이 무엇이든 중요한 건 변화가 현실이라는 점입니다. 요청은 더 이상 단순한 거래가 아닙니다. 요청은 이제 호출이 됩니다. 트리거가 됩니다. HTTP에 담긴 목표가 됩니다.
이 모든 것은 애플리케이션 전달 상위 10위 중 #4(트래픽 제어), #5(트래픽 스티어링), 그리고 #6(지연 관리)에 바로 연결됩니다. 맥락 없이 통제하거나 조정하거나 최적화할 수 없기 때문입니다.
3. 업무 기반 라우팅(신흥)
특히 에이전트 시스템과 재귀적 플래너가 본격적으로 도입되면서 우리가 나아가는 길이 확실해졌습니다. 우리는 단순히 콘텐츠를 제공하는 것을 넘어서고 있습니다. 우리는 목표를 직접 관리합니다. 이것이 모든 것을 근본적으로 바꿉니다.
이 모델에서는 하나의 요청이 항상 하나의 응답과 연결되진 않습니다. 대신 여러 개의 작은 작업이 차례로 시작될 수 있습니다. 그중 일부 작업은 동시에 진행됩니다. 또 다른 작업은 선행 작업이 완료되어야 합니다. 단순히 트래픽을 전달하는 것이 아니라 작업을 조율하는 겁니다.
파이프라인보다는 워크플로로 생각하세요. 성과를 만드는 여러 단계를 체크리스트로 관리하는 겁니다. 어떤 단계는 바로 진행할 수 있지만, 다른 단계는 차례를 기다려야 합니다. 모든 과정은 역량, 정책, 현재 부하를 기준으로 조정, 관찰, 조종해야 합니다.
그 시점부터 기존 라우팅 방식은 한계를 드러냅니다. 모든 요청이 여러 단계와 여러 주체를 거치는 과정을 거칠 때, 고정 경로나 일률적인 정책으로는 해결할 수 없습니다. 패킷 전송 위치뿐 아니라 작업의 본질, 필요 요소, 적합한 처리 주체까지 파악하는 시스템이 필요합니다.
중요한 점은 분류 없이는 아무것도 할 수 없다는 사실입니다. 인프라가 요청의 목적을 정확히 파악하지 못하면 지능적인 라우팅이 불가능합니다. 이제는 가까운 미래가 아니라, 현실로 다가오고 있습니다. 분류가 바로 요청 라우팅을 실제 조정으로 연결하는 다리 역할을 합니다.
중요한 이유
분명히 말씀드리겠습니다: 더 많은 메타데이터를 추가하거나 복잡한 라우팅 테이블을 만드는 것이 아닙니다. 이미 제공되는 트래픽을 바라보는 방식을 전환하는 것입니다.
분류는 재귀적 에이전트 루프를 정적 자산 조회와 동일하게 처리함으로써, 라우팅하거나 확장하거나 중단하기 전에 요청을 이해하도록 돕는 과정입니다.
더 이상 보안만을 위한 것이 아닙니다. 요청 에 무엇이 들어 있는지만이 중요한 것은 아닙니다. 중요한 것은 요청이 무엇을 의미하는지 , 무엇을 하려고 하는지, 얼마나 중요한지, 하류에서 무엇에 영향을 미치는지에 대한 것입니다.
그래서 분류는 단순한 최신 유행이 아닙니다. 필수 조건입니다. 우리가 만들어가고 있는 세상을 처리하기 위해 트래픽 관리를 진화시키는 중요한 단계입니다. 에이전트, 작업, 워크플로우, 실시간 오케스트레이션이 예외가 아니라 널리 활용되는 환경인 거죠.
이해하지 않으면 관리할 수 없습니다. 분류는 이해를 시작하는 방법입니다.