MCP 세션리스 전환이 로드밸런싱과 확장 전략에 미치는 변화

세션 식별자가 빠진 뒤의 MCP 요청 경로

SEP-2567은 Mcp-Session-Id 헤더와 프로토콜 수준 세션을 제거한다. SEP-2575의 핸드셰이크 제거와 맞물리면서, 특정 요청을 특정 서버 인스턴스에 고정해야 할 이유도 사라진다.

이제 원격 MCP 서버는 일반 라운드로빈 로드밸런서 뒤에 둘 수 있다. 스티키 세션, 쿠키 삽입, 공유 세션 저장소, 게이트웨이의 심층 패킷 검사처럼 세션 유지를 위해 붙었던 구성이 필요 없어지는 변화다. 게이트웨이는 본문을 해석하지 않고 메서드 기반 헤더만으로 레이트리밋과 권한 정책을 적용할 수 있다.

운영상 가장 직접적인 변화는 스케일인과 배포다. 세션 유실을 걱정하지 않아도 되므로 인스턴스 축소 정책을 더 적극적으로 설정할 수 있고, 롤링 배포의 드레이닝 시간도 줄일 수 있다. 다만 세션이 맡고 있던 대화 맥락과 인증 컨텍스트를 어디에 둘지는 별도로 결정해야 한다.

상태가 남아 있으면 무차별 라우팅은 성립하지 않는다

세션리스 로드밸런싱은 라운드로빈이나 최소 연결 같은 표준 알고리즘을 그대로 쓴다. 인스턴스 어피니티와 세션 테이블이 없어지고, 인스턴스를 늘렸을 때 새 인스턴스도 바로 부하를 나눠 받는다. 어피니티가 남아 있으면 신규 인스턴스가 오래 유휴 상태에 머물 수 있다.

전제는 각 인스턴스가 로컬 상태에 의존하지 않는다는 점이다. 캐시는 성능 최적화 용도로만 두고, 정확성을 좌우하게 해서는 안 된다. 예를 들어 진행 상태가 특정 인스턴스의 로컬 캐시에만 있다면, 요청이 다른 인스턴스로 갈 때 무작위 실패가 생긴다.

대화 맥락이나 작업 진행 상태는 외부 저장소에 보관하고 요청에 포함된 키로 참조할 수 있다. 저장소는 접근 지연, 영속성 요구, 크기 한계, 만료 정책을 기준으로 선택한다. 짧은 맥락은 캐시에, 장기 이력은 데이터베이스에 두는 이원화도 가능하다.

소량의 상태라면 서명된 토큰으로 요청과 함께 전달할 수 있다. 저장소 왕복이 없어 지연은 낮지만, 크기 제한과 발급 후 취소하기 어렵다는 문제가 있다. 민감 정보를 담으면 로그 노출 위험도 커진다.

⤢✕

어피니티를 끄기 전에 확인할 조건

스티키 세션 제거는 애플리케이션 무상태화, 컨텍스트 외부화 검증, 어피니티 해제, 부하 분산 확인, 축소 정책 완화의 순서로 진행한다. 어피니티를 먼저 제거하면 상태 의존 코드가 남아 있는 요청이 임의의 인스턴스로 전달되어 실패한다.

외부 상태 저장소는 P99 조회 지연, 가용성 목표, 만료 관리 기능, 크기 한계, 운영 부담을 기준으로 검토한다. 저장소가 새로운 단일 장애점이 될 수 있으므로 이중화와 함께, 저장소 장애 시 상태 없이 제한 기능을 제공하는 축퇴 운전 경로도 필요하다.

컨텍스트 크기의 상한 역시 명시해야 한다. 토큰 전달에는 헤더 크기 제한이 있고, 저장소 조회에는 지연이 따른다. 상한을 넘었을 때 요약·절단·거부 중 어떤 동작을 할지 정하지 않으면 특정 대화가 조용히 실패할 수 있다.

세션 드레이닝 제약이 없어졌다고 모든 축소 정책을 공격적으로 바꿀 수 있는 것은 아니다. 콜드스타트가 긴 서버라면 축소를 보수적으로 유지해야 한다. 제약이 없어진 것이 아니라, 제약의 중심이 세션에서 콜드스타트로 옮겨간다.

롤링 배포에서는 드레이닝 시간을 줄이고 배치 크기를 키워 배포 시간을 단축할 수 있다. 부하 시험에는 배포 중 트래픽, 인스턴스의 급격한 증가·감소, 외부 저장소 지연 상승을 포함해야 한다.

세션리스와 세션 고정의 트레이드오프

구분	세션리스 분산	스티키 세션 고정
확장성	인스턴스 추가 즉시 분담	신규 인스턴스 저활용
장애 내성	인스턴스 손실 무영향	세션 유실
인프라 구성	표준 로드밸런서	어피니티·세션 저장소
요청당 오버헤드	상태 조회·전달 추가	없음
배포 유연성	드레이닝 최소	드레이닝 필요
적합 상황	수평 확장 중심	장기 연결·대용량 세션

세션리스 방식은 새 인스턴스가 곧바로 트래픽을 분담하고, 개별 인스턴스 손실이 사용자 세션 손실로 이어지지 않는다. 반면 스티키 세션은 요청당 상태 조회·전달 비용이 없지만, 기존 세션이 새 인스턴스로 이동하지 않아 스케일아웃 효과가 늦고 장애가 세션 유실로 연결된다. 트래픽 변동이 크고 배포가 잦은 환경에서는 세션리스 구조의 장점이 크다.

외부 스토어에 컨텍스트를 두는 방식은 크기 제한이 사실상 없고 즉시 무효화할 수 있지만, 요청마다 네트워크 왕복이 추가된다. 요청 내 전달은 저장소 의존이 없고 지연이 가장 낮지만 헤더 크기 한계와 취소 불가 문제가 있다. 인증 상태처럼 취소 가능성이 중요한 정보는 스토어에, 짧은 라우팅 힌트는 요청 안에 두는 편이 적합하다.

적극적인 오토스케일은 유휴 비용을 줄이는 대신 콜드스타트와 스케일 지연이 꼬리 지연으로 나타날 수 있다. 고정 인스턴스 운영은 지연이 안정적이지만 피크 기준 자원을 계속 유지하므로 평균 활용률이 낮다.

관측성과 가용성의 책임이 옮겨가는 곳

세션 ID가 사라지면 로그에서 관련 요청을 묶던 자연스러운 기준도 없어진다. 대화 ID나 추적 ID 같은 대체 상관관계 키를 애플리케이션 수준에서 만들고, 표준 헤더 규약으로 전 구간에 전파해야 한다. 이 규약이 빠지면 장애 분석 능력도 함께 약해진다.

모니터링에서는 인스턴스별 요청 분산 균등도, 외부 저장소 조회 지연, 상관관계 키 누락률, 배포 중 오류율을 확인한다. 상관관계 키 규약은 문서에만 남기지 않고 표준으로 관리하며, 미준수 서비스는 점검 대상에 포함해야 추적성을 유지할 수 있다.

상태 없는 서비스는 수평 확장의 전제이며, 세션 제거는 이를 프로토콜 수준에서 강제한 사례다. 인스턴스 단위 장애가 사용자 세션 손실로 이어지지 않는 구조는 가용성 설계에 유리하다. 대신 외부 상태 저장소가 새로운 임계 경로가 되므로 저장소 장애 시 축퇴 운전 시나리오가 필요하다.

표준 로드밸런서와 일반 HTTP 인프라만으로 운영할 수 있게 되면 특수 구성에 대한 예외 승인 절차도 줄어든다. 그만큼 상태 저장소, 추적 키, 정책 적용 지점에 대한 거버넌스를 분명히 해야 한다.

세션리스 MCP에서 남는 운영 과제

세션리스 설계는 원격 도구 서버의 기본 전제로 자리잡고, 스티키 세션을 요구하는 구현은 배포 제약 사항으로 분류되는 흐름이다. SDK가 컨텍스트 외부화 계층을 기본 제공하면 구현 부담은 저장소 선택으로 이동한다.

게이트웨이 정책은 메서드 단위로 세분화되어 도구별 레이트리밋과 권한 제어를 인프라 계층에서 처리하는 방향으로 갈 수 있다. 오토스케일 축소 정책의 실질 제약은 세션보다 콜드스타트가 되며, 프리워밍과 최소 인스턴스 관리가 튜닝 주제로 부상한다.

SEP-2567의 변화는 단순히 헤더 하나를 제거하는 일이 아니다. 로드밸런서의 어피니티 설정, 오토스케일의 세션 드레이닝 제약, 배포 과정의 세션 유실 위험이 함께 사라진다. 전환의 핵심은 상태를 없애는 것이 아니라 상태의 위치와 추적 방식을 명시적으로 다시 설계하는 데 있다.