728x90

2026-07-28 사양 변경 이후 대두된 다단계 작업 내 상태 관리와 API의 경계

업무용 노션 페이지에 흩어진 회의록을 읽고 스프레드시트에 주요 결정 사항을 정리하는 다단계 작업을 지시한다고 가정해 보겠습니다. 2026년 7월 28일 자로 변경된 사양이 적용되면서, 이제 에이전트는 각 단계를 넘어갈 때마다 스스로 필요한 상태를 유지하며 애플리케이션 실행을 이어가야 합니다. 오픈에이아이(OpenAI)의 에이전트 소프트웨어 개발 키트(SDK) 빠른 시작 가이드에 명시된 작업 순서를 보면, 개발자는 먼저 하나의 에이전트를 정의하여 실행한 뒤 목적에 맞는 다음 기능을 덧붙이게 됩니다. 에이전트가 직접 계획을 세우고 전문가들 사이에서 협업하며 여러 단계의 일을 마칠 수 있도록 상태를 보존하는 작동 방식은, 매번 독립적인 응답만 주고받는 기존 방식과 뚜렷한 차이를 만듭니다.

관련 영상 시연에서는 사양 배포 이후 모델이 외부 도구를 호출할 때 일어나는 구조적인 변화를 엿볼 수 있습니다. 사용자의 요청과 도구의 설명을 바탕으로 클로드(Claude)가 호출 시점을 결정하면, 곧바로 동작을 수행하는 대신 정형화된 호출 정보를 반환하여 클라이언트 측 애플리케이션이나 서버가 실행하도록 넘기는 방식으로 작동합니다. 통제권이 분리된 환경에서 개발자는 모델의 결과물이 지정한 스타일과 내용 기준을 제대로 충족하는지 검증해야 합니다. 평가 애플리케이션 프로그래밍 인터페이스(Evals API)를 활용해 프로그래밍 방식으로 기준을 설정하면, 시스템을 업그레이드하거나 새 모델을 도입할 때 나타날 수 있는 실패 사례를 미리 찾아내고 의도한 대로 작동하는지 확인할 수 있습니다.

 

사용자 요청 분석부터 구조화된 호출을 거쳐 클라이언트 및 서버 도구를 실행하는 흐름

사용자가 사내 메신저에 들어온 고객 문의를 분석해 환불 처리 도구를 호출해 달라고 입력하면, 인공지능은 이 문장을 읽고 어떤 기능을 쓸지 결정합니다. 클로드(Claude) 공식 문서의 도구 사용 기능을 보면, 모델은 사용자의 요청 내용과 미리 정의된 도구의 설명을 바탕으로 언제 도구를 호출할지 스스로 판단합니다. 모델이 직접 환불 서버에 접속해 데이터를 고치는 것이 아니라, 사용자의 의도에 맞춰 어떤 값을 넣어 도구를 실행해야 하는지 구조화된 호출 형태로 행동을 제안하는 데까지만 관여합니다. 우리가 화면에서 확인하는 결과물은 모델이 직접 수행한 최종 동작이 아니라, 애플리케이션에 건네주기 위해 작성한 상세한 실행 계획표와 같습니다.

모델이 전달한 구조화된 호출을 실제로 실행하는 주체는 두 가지로 나뉩니다. 여러분이 만든 애플리케이션 내부에서 코드를 돌리는 클라이언트 도구가 있고, 앤스로픽(Anthropic) 같은 모델 제공자가 대신 실행해 주는 서버 도구로 실행 경계가 엄격하게 구분됩니다. 오픈에이아이(OpenAI) 가이드에서는 에이전트를 여러 단계를 거쳐 작업을 완수하도록 상태를 유지하며 도구를 호출하는 애플리케이션으로 정의합니다. 모델은 행동을 제안할 뿐 최종 코드 실행은 애플리케이션 몫이므로, 평가(Evals) API를 연결해 모델의 출력값이 지정한 기준을 충족하는지 프로그래밍 방식으로 검증하는 과정을 거칠 수 있습니다. 이를 바탕으로 사용자는 화면에서 도구 호출 내역을 미리 확인하고 실제 코드 실행을 통제하는 안전한 구조를 만듭니다.

 

Agents SDK를 활용한 단일 에이전트 구동과 후속 기능 선택 판단 과정

터미널 창을 열고 빈 프로젝트 폴더에 진입해 곧바로 코드를 작성하여 첫 에이전트 애플리케이션을 실행해 봅니다. 공식 문서의 빠른 시작 가이드를 따라 Agents SDK를 설치한 뒤, 하나의 에이전트를 정의해 구동하는 것이 다단계 작업을 자동화하는 출발점입니다. 에이전트는 독립적으로 움직이는 프로그램으로, 사용자의 요청과 미리 정의된 도구의 설명을 비교하여 언제 어떤 기능을 호출할지 스스로 판단합니다. 계획된 행동을 바탕으로 전체 작업 흐름을 짜고, 여러 단계를 거쳐 목표를 완료할 때까지 문맥과 상태를 잃지 않고 유지하며 작동합니다. 언어 모델은 사용자가 남긴 지시를 분석해 도구가 필요한 순간을 포착하면 구조화된 호출 데이터를 반환하며, 이를 통해 개발자가 의도한 시점에 정확히 외부 기능이 동작하게 됩니다.

단일 에이전트가 정상적으로 작동하는 것을 확인했다면, 그다음에는 구축 중인 애플리케이션에 어떤 후속 기능을 덧붙일지 선택해야 합니다. 반환된 도구 호출 데이터를 애플리케이션 내부에서 직접 처리할지, 아니면 서버 측에서 실행할지에 따라 도구의 동작 경계가 나뉘게 됩니다. 새로운 기능을 추가하거나 모델을 교체하는 과정에서는 모델의 결과물이 사전에 정의한 문체와 내용 기준을 충족하는지 검증하는 단계가 뒤따릅니다. 평가 API를 코드 레벨에서 프로그래밍 방식으로 구성하여 테스트를 진행하면, 에이전트가 예기치 않은 방향으로 행동하는지 파악할 수 있습니다. 영상 시연에서는 최근 변경된 사양과 아키텍처의 설계 측면을 다루는 모습이 등장하는데, 실무 현장에서도 도구의 실행 주체를 명확히 가르고 자동화된 평가 기준으로 결과물을 확인하며 서비스를 완성합니다.

 

모델 업그레이드 시 발생하는 출력 기준 미달 위험과 Evals API를 이용한 프로그래밍적 검증

새로운 인공지능 모델이 출시되었다는 소식에 기대감을 안고 애플리케이션 코드를 수정해 실행해 보면, 기존에 완벽하게 작동하던 결과물이 엉뚱한 형태로 깨지는 당황스러운 상황을 겪게 됩니다. 클로드(Claude)와 같은 모델은 사용자의 요청과 도구 설명을 바탕으로 언제 외부 기능을 호출할지 스스로 결정하고 구조화된 호출값을 반환합니다. 하지만 모델 버전을 교체할 때는 이 출력값이 우리가 지정한 형식과 내용 기준에 미달할 위험이 항상 존재합니다. 따라서 신뢰할 수 없는 외부 페이지 입력값이 곧바로 시스템에 반영되지 않도록, 본 서버와 분리된 격리 환경에서 도구가 먼저 실행되도록 안전망을 두어야 합니다.

모델을 교체하거나 새로운 기능을 시험할 때 발생하는 오류를 잡으려면 오픈에이아이(OpenAI)의 평가 API를 활용해 프로그래밍 방식으로 산출물을 검사하는 과정이 필요합니다. 개발자는 이 도구를 통해 산출물이 기대치에 맞게 작동하는지, 지정된 스타일과 내용 기준을 충족하는지 자동으로 테스트할 수 있습니다. 엠씨피(MCP) 아키텍처를 다루는 영상 시연에서는 브라우저가 특정 오디오 요소를 지원하지 않아 재생이 준비된 음원을 출력하지 못하는 제한 조건이 등장합니다. 이처럼 예기치 않은 실패 사례를 사전에 찾아내는 것이 평가의 목적입니다. 자동화된 평가를 통과한 결과물이라도 최종적으로 서비스에 반영하기 전에는 반드시 담당자가 눈으로 확인하고 결정하는 사람 승인 절차를 거쳐야 안전한 작동을 보장할 수 있습니다.

 

외부 함수 호출을 위임하기 전 애플리케이션의 상태 보존 능력 점검

사용자가 보낸 요청과 도구의 설명을 바탕으로 언어 모델이 외부 함수를 호출할 때, 그 결괏값을 화면에서 바로 확인하는 작업부터 자동화를 시도해 볼 수 있습니다. 앤스로픽(Anthropic) 클로드의 도구 사용 기능을 보면, 모델은 어떤 도구를 부를지 결정해 구조화된 호출 형태를 반환하고, 실제 애플리케이션을 실행하는 주체는 여러분의 클라이언트 환경이 되거나 앤스로픽 서버가 됩니다. 다단계 작업을 마치려면 중간 과정의 데이터를 잃지 않고 상태를 유지하는 능력이 필요합니다. 오픈AI(OpenAI) 에이전트 SDK 빠른 시작을 통해 에이전트를 하나 정의하고 실행해 보면, 에이전트가 전문가 간 협업이나 계획 수립을 수행하면서 다단계 작업이 끝날 때까지 충분한 상태를 보존하는 방식을 관찰할 수 있습니다. 한 번에 모든 과정을 위임하기보다, 애플리케이션이 실행되는 과정마다 상태가 안전하게 넘어가는지 점검하는 것이 첫 번째 검증 단위입니다.

작은 단위의 검증이 끝났다면 모델이 내놓은 결과물이 지정한 스타일과 내용 기준에 맞는지 평가(Evaluations)를 구성할 차례입니다. 오픈AI의 평가 가이드에 따르면, 평가 API를 프로그래밍 방식으로 설정해 애플리케이션이 기대치에 맞게 동작하는지 테스트할 수 있습니다. 특히 새로운 모델을 시도하거나 기능을 업그레이드할 때 신뢰할 수 있는 애플리케이션을 구축하는 데 필요한 요소입니다. 인포큐(InfoQ)의 영상 시연에서는 MCP 2026-07-28 사양 배포 이후 상태 비저장(Stateless) 방식으로 변경된 아키텍처를 다루며, 도구 호출이 API 형태로 넘어가는 과정을 보여줍니다. 상태를 직접 보존하지 않는 외부 도구와 통신할 때는, 모델의 호출 결과가 시스템 경계를 넘어가기 전에 사람 승인 단계를 두어 의도치 않은 함수 실행을 막는 것이 안전합니다.

 

바로 써볼 체크리스트

 

시작 전에 확인할 것

도입 전후로 아래 항목만 확인해도, 자동화가 예상 밖으로 움직일 가능성을 크게 줄일 수 있습니다.

  • 에이전트가 외부 도구를 호출하기 전 사용자의 요청과 도구의 설명을 바탕으로 생성된 구조화된 호출의 입력값이 올바른 형태인지 검증하고 예상치 못한 기형적인 입력에 대해 안전하게 처리하는지 확인한다.
  • 클라이언트 애플리케이션에서 실행되는 도구와 서버 측에서 실행되는 도구 간의 권한 경계가 명확하게 분리되어 있는지 확인하고 최소 권한 원칙에 따라 인가되지 않은 외부 시스템 접근을 철저히 차단하는지 점검한다.
  • 에이전트를 실제 환경에 배포하기 전에 Evals API와 같은 프로그래매틱 평가 도구를 활용하여 모델의 출력 결과가 사전에 정의된 스타일 및 콘텐츠 기준을 엄격하게 충족하는지 신뢰성 평가를 수행하고 결과를 확인한다.
  • 다단계 작업을 완료하기 위해 애플리케이션이 유지하는 상태 정보와 에이전트의 모든 도구 호출 과정을 빠짐없이 기록하여 문제 발생 시 전체 실행 경로를 명확히 역추적하고 디버깅할 수 있는 로그 시스템이 구축되었는지 확인한다.
  • 에이전트의 다단계 작업 중 특정 도구 호출이 실패하거나 애플리케이션이 예상치 못한 비정상적인 결과를 반환할 경우 즉각적으로 전체 작업을 중단하고 시스템 상태를 이전으로 안전하게 되돌릴 수 있는 롤백 메커니즘을 테스트한다.
  • 에이전트 애플리케이션이 외부 시스템의 상태를 영구적으로 변경하거나 권한이 필요한 민감한 작업을 수행하는 도구를 호출하기 전에 반드시 실제 담당자의 명시적인 검토 및 승인 절차를 거치도록 사람 개입 프로세스를 점검한다.

참고 자료

728x90
반응형
저작자표시 비영리 변경금지 (새창열림)

+ Recent posts

티스토리툴바