OpenAI Agents SDK와 Google ADK: 구성과 운영 범위

Python으로 도구 호출과 전문 에이전트 인계를 빠르게 구성하는 팀이라면 OpenAI Agents SDK가 유력하다. OpenAI Agents SDK 빠른 시작은 Agent에 도구와 인계 대상을 붙이고 Runner로 실행한 뒤 Trace viewer에서 흐름을 살피는 경로를 보여준다. 이 구성의 장점은 개발팀이 먼저 익혀야 할 핵심 개념이 적다는 데 있다.

여러 언어로 개발하거나 실행 경로와 배포 환경을 함께 설계해야 한다면 Google ADK가 더 넓은 선택지를 제공한다. Google ADK 공식 문서는 Python·TypeScript·Go·Java·Kotlin 지원과 그래프 워크플로, Cloud Run·GKE 배포 경로를 제시한다. 다만 제품 전체의 언어 목록을 개별 기능의 지원 범위로 읽으면 설계 단계에서 선택을 잘못할 수 있다.

언어보다 먼저 코드의 소유 팀을 정한다

에이전트 로직을 Python 팀이 끝까지 소유한다면 OpenAI Agents SDK의 작은 실행 단위가 자연스럽다. Agent는 지시와 도구를 담고 Runner가 실행을 맡는다. 도구가 Python 함수로 이미 구현돼 있다면 새 워크플로 계층을 먼저 설계할 필요 없이 호출과 인계의 동작을 코드에서 파악할 수 있다.

프런트엔드, 백엔드, 플랫폼 팀이 서로 다른 언어를 사용한다면 ADK의 다언어 지원이 더 실질적인 조건이 된다. 언어별 개발 경로가 있다는 사실은 해당 팀이 자기 코드베이스에서 에이전트 구성을 맡을 여지를 준다. 그러나 지원 언어가 많아도 기능별 지원 범위와 운영 도구가 같다고 가정해서는 안 된다. 프로젝트가 요구하는 그래프, 세션, 추적 기능을 선택한 언어에서 각각 확인해야 한다.

예를 들어 Python 팀이 시연용 에이전트를 만들고 Java 서비스 팀이 장기 운영을 맡는다고 가정해 보자. Python에서 짧게 작성한 코드가 곧 운영 인수의 간결함을 뜻하지는 않는다. 도구 입력값의 검증, 호출 실패의 처리, 응답 형식의 변경을 어느 팀이 수정할지까지 정해져야 언어 선택이 운영 비용의 판단으로 이어진다.

같은 도구 호출도 인계와 분기의 기준은 다르다

비교 조건을 동일하게 놓으면 차이가 분명해진다. 사용자의 요청을 분류하고, 조회 도구로 필요한 정보를 가져온 뒤, 담당 전문 에이전트가 답하는 흐름을 가정해 보자. OpenAI Agents SDK에서는 분류 역할의 Agent에 도구와 handoff 대상을 등록하고 Runner가 실행을 진행한다. 전문 에이전트가 대화를 넘겨받는 방식과 분류 에이전트가 전문가를 도구처럼 호출해 답변 소유권을 유지하는 방식도 구별할 수 있다.

업무 규칙이 정해진 경로를 요구하면 ADK 그래프가 더 직접적이다. ADK 그래프 워크플로 문서는 노드와 간선으로 경로를 정의하고 에이전트 판단, 도구, 일반 코드를 결합하는 방법을 설명하며, 이 기능의 지원 범위를 Python·TypeScript·Go로 명시한다. Java와 Kotlin을 사용하는 팀은 ADK 자체를 사용할 수 있어도 같은 그래프 API를 전제로 작업 계획을 세워서는 안 된다.

앞의 가정에서 조회 결과가 비어 있으면 재시도하고, 특정 값이 나오면 사람의 승인을 받은 다음 응답하도록 업무 규칙을 추가해 보자. 그 규칙이 서비스의 핵심 계약이라면 분기와 순서를 명시한 그래프가 검토하기 쉽다. 반대로 전문 분야가 달라질 때 모델의 인계 판단을 활용하는 흐름이 중심이라면 간결한 에이전트 구성으로 충분할 수 있다. 핵심 차이는 도구 호출 가능 여부가 아니라 경로의 책임을 모델과 코드 중 어디에 둘지다.

대화 상태와 추적은 따로 설계해야 한다

도구를 호출한 뒤 다음 사용자 메시지에서도 맥락을 이어야 한다면 실행 사이의 상태 저장 방식을 정해야 한다. OpenAI Agents SDK는 앞선 실행 결과를 다음 입력으로 넘기는 방식, SDK 세션, OpenAI 서버에서 관리하는 연속 상태를 제공한다. 앞선 입력을 직접 관리하면 기록의 범위를 애플리케이션이 통제하지만 저장과 재전달도 맡아야 한다. 세션을 사용하면 그 반복 작업을 SDK에 맡길 수 있다.

ADK에도 세션과 상태를 다루는 구성요소가 있다. 그러나 대화 기록을 보존하는 요구와 중단된 업무 단계를 재개하는 요구는 다르다. 다음 단계가 이전 도구의 결과를 읽어야 하는지, 사용자별 맥락을 어느 기간 유지할지, 승인 대기 중 어디에 데이터를 둘지를 먼저 나누면 상태 기능을 비교하기 쉬워진다. 상태를 지원한다는 체크 표시만으로 저장 책임이나 장애 복구 방식이 정해지지는 않는다.

실행을 관찰하는 방식도 다르다. OpenAI Agents SDK의 빠른 시작 경로에서는 OpenAI Dashboard의 Trace viewer에서 에이전트 실행을 살펴볼 수 있다. ADK 추적 문서는 모델·도구·에이전트 실행을 계층적 span으로 기록하고 OTLP 형식으로 내보내는 방식을 설명하며, 해당 추적 기능의 지원 언어를 Python·Go·Kotlin으로 표시한다. 기존에 OpenTelemetry 기반 관측 시스템을 운영한다면 내보내기 경로가 편리할 수 있지만, 실제 연결 설정과 수집 범위는 선택한 언어에 맞춰 정해야 한다.

추적 화면에서 무엇을 보고 싶은지도 선택에 영향을 준다. 도구 호출이 실패한 지점만 개발 중 빠르게 찾는 것이 목적이라면 기본 뷰어가 출발점이 된다. 여러 서비스에 걸친 요청의 지연과 오류를 한 흐름에서 보려면 에이전트 추적을 기존 분산 추적과 연결하는 일이 중요해진다. 추적 데이터에 입력과 출력 내용이 포함되는 범위는 팀의 보관 정책과 함께 정해야 한다.

배포 환경이 정해졌다면 운영 경로가 선택을 좁힌다

Cloud Run이나 GKE에서 실행할 계획이라면 ADK에 문서화된 배포 경로가 있다. 개발 중 만든 에이전트를 어떤 서비스로 노출하고 관찰할지 같은 제품의 문서 체계 안에서 검토할 수 있다. 컨테이너 환경에서 운영하는 경로도 제시되므로 Google Cloud만을 전제하는 선택은 아니다. 배포 옵션의 존재와 실제 서비스의 인증·비밀 정보·권한 설계는 별개의 일이다.

기존 Python 서비스에 에이전트 실행을 포함할 계획이라면 OpenAI Agents SDK의 장점은 새로운 배포 방식을 택하지 않고 현재 애플리케이션의 운영 책임 안에서 다룰 수 있다는 데 있다. 여기서 판단할 것은 프레임워크의 배포 가능 여부보다 장애 대응과 변경 승인을 누가 맡는가다. 같은 도구 호출 코드라도 독립 서비스로 분리하면 네트워크 권한, 상태 저장 위치, 추적 연결 지점이 달라진다.

배포 환경이 미정인 프로젝트에서는 기능 목록의 길이보다 운영상 바꾸기 어려운 조건을 먼저 보는 편이 낫다. 외부 도구가 접근할 데이터, 세션 저장소의 위치, 요청별 자원 한도는 개발 초기의 간단한 시연에서 잘 드러나지 않는다. 이런 조건을 나중에 바꾸면 에이전트 코드뿐 아니라 기존 서비스의 접근 정책까지 손볼 수 있다.

연구의 성공률과 비용은 선택표의 경고선이다

ADK Arena 연구는 코딩 에이전트가 Python 에이전트 개발 프레임워크 51개로 코드를 생성하고 검증한 평가에서 생성 성공률 57%, 프레임워크 간 생성 비용 최대 5.6배 차이, 에이전트당 0.6~3.4달러의 비용 범위를 보고한다. 이는 사람이 작성한 서비스의 운영비가 아니라 코딩 에이전트가 각 프레임워크의 API를 익히고 코드를 만들며 수정하는 과정의 비용이다. 또한 전체 프레임워크 집합의 결과이므로 두 제품 사이의 직접적인 승률이나 가격 차이로 옮길 수 없다.

연구는 프레임워크 이름 하나로 개발 성과가 결정되지 않는다는 점을 보여준다. 같은 코딩 에이전트를 쓰더라도 프레임워크별로 코드를 완성하기 위한 노력이 달랐다. 팀에서 작성하려는 도구 계약과 상태 처리 방식이 연구의 과제와 다르면 성공률도 달라질 수 있다. 그래서 이 수치는 구매 결론보다 기능 체크리스트에 없는 구현 난도를 선택표에 넣어야 한다는 근거로 유용하다.

팀의 병목별로 결론이 달라진다

소규모 Python 팀: 요청 분류, 도구 호출, 전문 에이전트 인계가 주된 요구이고 배포 책임이 기존 Python 서비스에 있다면 OpenAI Agents SDK가 먼저 검토할 선택지다. Agent와 Runner 중심으로 동작을 구성하고 기본 추적 화면으로 실행 흐름을 확인할 수 있다.
여러 언어를 쓰는 팀: 에이전트 로직의 장기 소유자가 Python 팀 밖에도 있다면 ADK의 언어별 구현 경로가 유용하다. 다만 필요한 기능을 언어별로 대조해야 하므로 그래프를 요구하는 Java·Kotlin 팀과 추적을 요구하는 TypeScript 팀은 전체 지원 목록만으로 설계를 확정할 수 없다.
고정된 업무 경로를 운영하는 팀: 분기와 단계 사이의 데이터 계약이 핵심이고 Cloud Run·GKE 배포 또는 기존 분산 추적과의 연결을 계획한다면 ADK의 그래프·배포·추적 구성이 더 직접적인 출발점이다. 실행 경로가 자주 바뀌는지, 변경을 누가 승인하는지도 함께 결정해야 한다.

최종 선택은 같은 조건의 작은 구현에서 가장 분명해진다. 조건부 예시의 조회 도구, 인계 규칙, 상태 보존 요구를 두 후보에 똑같이 적용하면 코드를 수정해야 하는 위치와 추적에서 확인할 수 있는 범위가 드러난다. 구현에 드는 노력과 실제 운영 책임을 따로 기록하면 빠른 시작의 이점과 넓은 운영 범위 중 어느 쪽이 팀의 병목을 줄이는지 판단할 수 있다.

함께 읽기: