에이전트는 어떻게 설계할까요? OpenAI가 설명한 모델·도구·지시
OpenAI의 에이전트 설계 가이드를 바탕으로 모델 선택, 도구 구성, 업무 지시, 단일·다중 에이전트, 가드레일을 어떤 순서로 결정하는지 정리했습니다.
최재현 · 2026.10.02
자료 기준일: 주 자료인 OpenAI 「A practical guide to building agents」는 문서에 발행일이 표시되지 않습니다(PDF 메타데이터상 생성일 2025-04-07). 함께 인용한 Anthropic 글은 2024-12-19 공개입니다. 2026-10-03에 원문을 다시 확인했으며, 최근 발표를 다루지 않습니다.
AI-Native와 Agent-Native는 편리한 표현이지만, 이 이름만으로 시스템이 어떻게 일하는지는 알 수 없습니다. 같은 생성형 AI를 써도 한쪽은 문서에서 답을 찾고, 다른 쪽은 데이터베이스를 수정하거나 메시지를 보냅니다. 필요한 모델도 다르고, 실패했을 때 멈추는 방법도 달라집니다. OpenAI의 공식 가이드는 에이전트를 모델, 도구, 지시로 나누고, 이 조합을 어떻게 구성할지부터 설명합니다.
OpenAI 가이드의 에이전트 구성과 실행 통제. 구성 요소를 일방적인 도입 순서로 보지 않습니다. 도식 크게 보기
모델은 가장 싼 것부터 고르지 않습니다
OpenAI는 모델마다 복잡한 판단 능력, 지연 시간, 비용이 다르다고 봅니다. 단순 검색이나 의도 분류는 작고 빠른 모델로 처리할 수 있지만, 환불 승인처럼 맥락과 예외를 판단하는 일은 더 강한 모델이 필요할 수 있습니다. 권하는 순서도 분명합니다. 처음에는 가장 성능이 좋은 모델로 기준 성능을 만들고, 평가 자료를 마련한 다음, 작은 모델로 바꿔도 허용 정확도를 유지하는 구간을 찾습니다.
처음부터 저렴한 모델을 배치하면 실패 원인이 모델 능력인지, 도구 설명인지, 지시문인지 구분하기 어렵습니다. 반대로 모든 단계에 큰 모델을 계속 쓰면 품질은 확보할 수 있어도 비용과 응답 시간이 불필요하게 늘어날 수 있습니다. 평가 결과를 보고 모델을 역할별로 조정합니다.
도구는 읽기·행동·오케스트레이션으로 구분합니다
OpenAI는 에이전트 도구를 데이터, 행동, 오케스트레이션으로 설명합니다. 데이터 도구는 거래 시스템을 조회하고 PDF를 읽거나 웹을 검색합니다. 행동 도구는 데이터베이스에 정보를 추가하고, 기록을 수정하고, 메시지를 보냅니다. 오케스트레이션 도구는 다른 전문 에이전트를 호출합니다.
이 구분이 필요한 이유는 도구마다 실패의 결과가 다르기 때문입니다. 검색이 틀리면 답을 다시 만들 수 있지만, 잘못 보낸 메일이나 변경된 주문은 되돌리기 어려울 수 있습니다. OpenAI는 도구 위험도를 읽기 전용인지 쓰기 권한인지, 되돌릴 수 있는지, 필요한 계정 권한과 금전 영향이 무엇인지에 따라 낮음·중간·높음으로 평가하라고 제안합니다. 위험도가 높은 작업은 실행을 보류하고 사람이 검토하도록 합니다.
도구가 많다는 이유만으로 에이전트를 여러 개 만들 필요는 없습니다. OpenAI가 든 사례에서는 서로 잘 구분된 도구 15개 이상을 한 에이전트가 다루기도 했고, 기능이 겹치는 도구는 10개보다 적어도 선택에 실패했습니다. 문제는 수량보다 이름과 설명, 매개변수의 중복입니다. 도구 설명을 고쳐도 계속 잘못 선택할 때 역할 분리를 검토합니다.
지시는 업무 문서를 실행 가능한 절차로 바꿉니다
OpenAI는 기존 운영 절차, 지원 스크립트, 정책 문서를 에이전트가 따를 수 있는 절차로 바꾸라고 합니다. 긴 규정은 더 작은 단계로 나누고, 각 단계가 질문·API 호출·출력처럼 확인 가능한 행동과 연결되어야 합니다. 정보가 빠졌거나 예상하지 못한 요청이 들어온 경우도 조건문으로 적습니다.
예를 들어 “문서를 검토하라”보다 “외주업체 변경 절차를 찾고 문서명과 항을 적는다. 근거가 없으면 문서에 없음으로 표시한다. 등록 전에 담당자가 원문을 확인한다”가 실행 지시에 가깝습니다. 제조 AX 문서·회의 실습에서 이 방식으로 연습합니다. 문서 검색, 근거 표시, 누락 처리, 사람의 확인이 각각 관찰 가능한 결과로 남습니다.
단일 에이전트에서 먼저 한계를 확인합니다
OpenAI는 복잡한 구조부터 만들지 말고 단일 에이전트의 능력을 먼저 늘리라고 권합니다. 단일 에이전트에 도구와 지시를 추가하면 평가와 유지보수가 비교적 단순합니다. 실행은 반복 구조로 이어지며, 최종 출력 도구가 호출되거나 모델이 더 이상 도구를 부르지 않을 때 끝낼 수 있습니다. 오류나 최대 실행 횟수도 종료 조건으로 둘 수 있습니다.
여러 에이전트는 조건문이 계속 늘어 지시문을 관리하기 어렵거나, 겹치는 도구를 반복해서 잘못 고를 때 검토합니다. 중앙 관리자가 전문 에이전트를 도구처럼 호출하고 결과를 합치는 매니저 방식이 있고, 분류 담당이 주문 담당에게 제어권을 넘기듯 전문 에이전트끼리 사용자 대화를 넘기는 핸드오프 방식이 있습니다. 사용자가 하나의 창구와 대화해야 하면 매니저 방식이 맞고, 전문 담당이 대화를 이어받아야 하면 핸드오프 방식이 맞습니다. “다중 에이전트가 더 발전된 형태”라는 이유만으로 선택할 수는 없습니다.
Anthropic도 같은 방향을 보입니다. 고정된 하위 작업은 워크플로우가 예측 가능하고, 필요한 단계 수를 미리 알 수 없는 열린 문제는 에이전트가 맞다고 설명합니다. 시스템이 복잡해질수록 성능뿐 아니라 비용, 대기 시간, 오류 누적도 함께 증가합니다. 다만 이 Anthropic 글 첫머리에는 2024년 12월 이후 도구 환경이 많이 바뀌었으니 현재 방식은 Claude Managed Agents 구축기(2026-04-08)를 보라는 안내가 붙어 있습니다(2026-10-03 확인).
가드레일은 모델 바깥의 통제까지 포함합니다
OpenAI는 관련성 분류, 프롬프트 공격 탐지, 개인정보 필터, 유해성 검사, 도구별 안전장치, 규칙 기반 차단, 출력 검증을 함께 제시합니다. 한 번의 검사로 모두 막는 방식이 아니라 여러 전문 검사를 겹칩니다. 다만 가드레일이 인증, 권한 관리, 접근 통제, 일반적인 소프트웨어 보안을 대신하지는 않습니다.
사람에게 넘기는 조건도 미리 정합니다. 실패 횟수를 넘었거나, 취소·고액 환불·결제처럼 민감하고 되돌리기 어려운 행동을 하려면 사람이 확인합니다. 제조 AX 리더 검토 실습의 교육용 보고서에서는 AI가 월 640분을 줄였다는 계산을 400분으로 고치고, 자료에 없는 원인과 미래 수치를 삭제합니다. 가드레일을 추상적인 안전 구호로 두지 않고, 계산 대조와 근거 확인처럼 실제 검사로 바꾸는 예입니다.
AI-Native라는 이름을 붙이는 것보다 먼저 답할 질문은 구체적입니다. 어느 모델이 어느 정확도를 내는지, 어떤 도구가 데이터를 읽고 바꾸는지, 지시가 예외를 어떻게 처리하는지, 단일 에이전트가 어디서 실패하는지, 어떤 행동에서 사람이 제어권을 가져오는지 확인해야 합니다.