OpenAI의 에이전트 구축을 위한 실용 가이드

- LLM의 추론, 멀티모달, 도구 사용 능력이 향상되면서 사용자를 대신해 독립적으로 워크플로를 수행하는 새로운 시스템 범주인 에이전트가 등장 - 에이전트는 모델(LLM), 도구(API/외부 함수), 지침(가이드라인)의 세 가지 핵심 구성요소로 이루어지며, 단일 에이전트 또는 다중 에이전트 시스템으로 오케스트레이션 가능 - 복잡한 의사결정, 유지보수 어려운 규칙 시스템, 비정형 데이터 처리가 필요한 워크플로에서 에이전트 도입이 적합 - 가드레일은 데이터 프라이버시, 콘텐츠 안전, 브랜드 일관성을 보호하는 다계층 방어 메커니즘으로 에이전트 배포의 필수 요소 - 단일 에이전트부터 시작해 실제 사용자 검증을 거쳐 점진적으로 확장하는 반복적 접근 방식이 성공적 배포의 핵심 에이전트의 정의 - 에이전트는 사용자를 대신해 독립적으로 작업을 수행하는 시스템으로, 고객 서비스 문제 해결, 레스토랑 예약, 코드 변경 커밋, 보고서 생성 등의 워크플로를 처리 - LLM을 통합하지만 워크플로 실행을 제어하지 않는 애플리케이션(단순 챗봇, 단일 턴 LLM, 감정 분류기 등)은 에이전트가 아님 - 에이전트의 핵심 특성: - LLM을 활용해 워크플로 실행을 관리하고 의사결정을 수행하며, 워크플로 완료 시점을 인식하고 필요시 선제적으로 행동을 수정 - 실패 시 실행을 중단하고 사용자에게 제어권을 반환 - 다양한 도구에 접근해 외부 시스템과 상호작용하며, 워크플로의 현재 상태에 따라 적절한 도구를 동적으로 선택하되 명확한 가드레일 내에서 운영 에이전트를 구축해야 하는 시점 - 기존 자동화와 달리 에이전트는 전통적인 결정론적·규칙 기반 접근 방식이 한계에 부딪히는 워크플로에 적합 - 결제 사기 분석 예시: 전통적 규칙 엔진은 사전 설정 기준에 따라 거래를 플래그하는 체크리스트 방식인 반면, LLM 에이전트는 맥락을 평가하고 미묘한 패턴을 고려하며 명확한 규칙 위반 없이도 의심스러운 활동을 식별하는 숙련된 조사관 역할 수행 - 에이전트 도입이 가치를 더하는 세 가지 유형: - 복잡한 의사결정: 미묘한 판단, 예외, 맥락에 민감한 결정이 필요한 워크플로(예: 고객 서비스의 환불 승인) - 유지보수 어려운 규칙: 방대하고 복잡한 규칙셋으로 업데이트가 비용 많이 들거나 오류가 발생하기 쉬운 시스템(예: 벤더 보안 리뷰) - 비정형 데이터 의존도 높은 시나리오: 자연어 해석, 문서에서 의미 추출, 대화형 사용자 상호작용(예: 주택 보험 청구 처리) - 이 기준을 명확히 충족하지 못하면 결정론적 솔루션으로 충분할 수 있음 에이전트 설계 기초 - 세 가지 핵심 구성요소 - 모델(Model): 에이전트의 추론과 의사결정을 구동하는 LLM - 도구(Tools): 에이전트가 행동을 취하기 위해 사용하는 외부 함수 또는 API - 지침(Instructions): 에이전트의 행동 방식을 정의하는 명시적 가이드라인과 가드레일 - 모델 선택 - 모든 작업에 가장 강력한 모델이 필요하지는 않음 — 단순한 검색이나 의도 분류는 작고 빠른 모델로 처리 가능하고, 환불 승인 결정 같은 어려운 작업은 더 강력한 모델이 유리 - 프로토타입 단계에서 가장 강력한 모델로 성능 기준선을 설정한 후, 더 작은 모델로 교체하며 수용 가능한 결과가 나오는지 확인하는 접근 방식이 효과적 - 모델 선택 원칙: - 평가(eval)를 설정해 성능 기준선 확립 - 최고 모델로 정확도 목표 달성에 집중 - 가능한 곳에서 더 작은 모델로 교체해 비용과 지연 시간 최적화 - 도구 정의 - 도구는 기반 애플리케이션이나 시스템의 API를 사용해 에이전트의 역량을 확장 - 레거시 시스템에서 API가 없는 경우, computer-use 모델을 활용해 웹 및 애플리케이션 UI를 통해 직접 상호작용 가능 - 각 도구는 표준화된 정의를 가져야 하며, 도구와 에이전트 간 유연한 다대다 관계 지원 - 잘 문서화되고 철저히 테스트된 재사용 가능한 도구가 발견 가능성 향상, 버전 관리 단순화, 중복 정의 방지에 기여 - 에이전트에 필요한 세 가지 도구 유형: - 데이터(Data): 워크플로 실행에 필요한 맥락과 정보를 검색(예: 트랜잭션 DB 쿼리, CRM 시스템, PDF 읽기, 웹 검색) - 액션(Action): 시스템과 상호작용해 DB에 정보 추가, 레코드 업데이트, 메시지 전송 등의 행동 수행(예: 이메일/문자 전송, CRM 레코드 업데이트, 고객 서비스 티켓을 사람에게 이관) - 오케스트레이션(Orchestration): 에이전트 자체가 다른 에이전트의 도구 역할 수행(예: 환불 에이전트, 리서치 에이전트, 작성 에이전트) - 지침 구성 - 고품질 지침은 모든 LLM 기반 앱에 필수적이지만, 에이전트에서 특히 중요 - 명확한 지침이 모호성을 줄이고 에이전트 의사결정을 개선하여 더 원활한 워크플로 실행과 더 적은 오류로 이어짐 - 에이전트 지침 모범 사례: - 기존 문서 활용: 기존 운영 절차, 지원 스크립트, 정책 문서를 사용해 LLM 친화적 루틴 생성(고객 서비스에서는 루틴이 지식 베이스의 개별 문서에 대략 매핑) - 작업 분해 프롬프트: 밀도 높은 리소스에서 더 작고 명확한 단계를 제공해 모호성 최소화 - 명확한 액션 정의: 루틴의 모든 단계가 특정 액션이나 출력에 대응하도록 명시(예: 주문 번호 요청, API 호출로 계정 세부 정보 검색) - 엣지 케이스 포착: 사용자가 불완전한 정보를 제공하거나 예상치 못한 질문을 하는 경우 등 일반적 변형을 예상하고 조건부 단계나 분기로 처리 방법 포함 - o1이나 o3‑mini 같은 고급 모델을 사용해 기존 문서에서 자동으로 지침을 생성하는 것도 가능 오케스트레이션 - 단일 에이전트 시스템 - 단일 에이전트가 도구를 점진적으로 추가하며 많은 작업을 처리할 수 있어 복잡성 관리와 평가·유지보수가 단순화 - 모든 오케스트레이션 접근 방식에는 'run' 개념이 필요하며, 일반적으로 종료 조건에 도달할 때까지 에이전트가 작동하는 루프로 구현 - 일반적 종료 조건: 도구 호출, 특정 구조화된 출력, 오류, 최대 턴 수 도달 - Agents SDK에서는 Agents.run() 메서드로 에이전트를 시작하며, 최종 출력 도구 호출 또는 도구 호출 없는 모델 응답 시 루프 종료 - 프롬프트 템플릿 전략: 다수의 개별 프롬프트 대신 정책 변수를 받는 단일 유연한 기본 프롬프트를 사용해 다양한 맥락에 적응, 유지보수와 평가를 크게 단순화 - 다중 에이전트 시스템으로 전환 시점 - 일반적 권장 사항은 단일 에이전트의 역량을 먼저 최대화하는 것 - 더 많은 에이전트가 직관적 개념 분리를 제공하지만 추가 복잡성과 오버헤드를 수반하므로, 종종 도구를 갖춘 단일 에이전트로 충분 - 에이전트 분할 실무 지침: - 복잡한 로직: 프롬프트에 다수의 조건문(if-then-else 분기)이 포함되고 프롬프트 템플릿이 확장하기 어려울 때 각 논리 세그먼트를 별도 에이전트로 분리 - 도구 과부하: 문제는 도구 수가 아닌 유사성이나 중복에 있음 — 15개 이상의 명확히 구분된 도구를 성공적으로 관리하는 구현이 있는 반면, 10개 미만의 중복 도구로도 어려움을 겪는 경우 존재 - 매니저 패턴 (에이전트를 도구로 사용) - 중앙 LLM인 "매니저" 가 도구 호출을 통해 전문화된 에이전트 네트워크를 오케스트레이션 - 매니저가 맥락이나 제어를 잃지 않으면서 적절한 에이전트에 적시에 작업을 위임하고 결과를 통합된 상호작용으로 합성 - 하나의 에이전트만 워크플로 실행을 제어하고 사용자에 접근해야 하는 워크플로에 적합 - 예시: 번역 에이전트가 스페인어, 프랑스어, 이탈리아어 에이전트를 도구로 호출 - 탈중앙화 패턴 (에이전트 간 핸드오프) - 에이전트가 워크플로 실행을 다른 에이전트에게 '핸드오프' 하는 단방향 전환 방식 - Agents SDK에서 핸드오프는 도구 또는 함수의 일종으로, 핸드오프 함수 호출 시 최신 대화 상태를 전달하며 새 에이전트에서 즉시 실행 시작 - 단일 에이전트가 중앙 제어나 합성을 유지할 필요 없이 각 에이전트가 실행을 인계받아 사용자와 직접 상호작용하는 방식에 최적 - 예시: 트리아지 에이전트가 사용자 쿼리를 평가하고 기술 지원, 영업, 주문 관리 에이전트로 라우팅 - 선언적 vs 비선언적 그래프 - 일부 프레임워크는 선언적(declarative) 방식으로 모든 분기, 루프, 조건을 노드(에이전트)와 엣지(핸드오프)로 구성된 그래프로 사전 정의해야 함 — 시각적 명확성은 있지만 워크플로가 동적이고 복잡해지면 번거로워지고 도메인 특화 언어 학습이 필요 - Agents SDK는 코드 우선(code-first) 접근 방식을 채택해 익숙한 프로그래밍 구조로 워크플로 로직을 직접 표현, 전체 그래프를 사전 정의할 필요 없이 더 동적이고 적응 가능한 에이전트 오케스트레이션 가능 가드레일 - 가드레일의 역할 - 데이터 프라이버시 리스크(예: 시스템 프롬프트 유출 방지)와 평판 리스크(예: 브랜드에 부합하는 모델 행동 강제) 관리에 기여 - 단일 가드레일로는 충분한 보호가 어려우며, 다수의 전문화된 가드레일을 함께 사용해 더 회복력 있는 에이전트 구축 필요 - 가드레일은 중요한 구성요소이지만, 강력한 인증·권한 부여 프로토콜, 엄격한 접근 제어, 표준 소프트웨어 보안 조치와 결합해야 함 - 가드레일 유형 - 관련성 분류기(Relevance classifier): 에이전트 응답이 의도된 범위 내에 있는지 확인하고 주제 외 쿼리를 플래그(예: "엠파이어 스테이트 빌딩 높이는?"은 주제 외로 플래그) - 안전성 분류기(Safety classifier): 시스템 취약점을 악용하려는 탈옥이나 프롬프트 인젝션 등 안전하지 않은 입력 탐지 - PII 필터: 모델 출력에서 개인 식별 정보(PII)의 불필요한 노출 방지 - 모더레이션(Moderation): 혐오 발언, 괴롭힘, 폭력 등 유해하거나 부적절한 입력을 플래그 - 도구 세이프가드(Tool safeguards): 각 도구에 읽기 전용 vs 쓰기 접근, 가역성, 필요한 계정 권한, 재정적 영향 등을 기반으로 저/중/고 위험 등급을 부여하고, 높은 위험 기능 실행 전 가드레일 검사 일시 정지나 사람에게 에스컬레이션 등 자동화된 액션 트리거 - 규칙 기반 보호(Rules-based protections): 차단 목록, 입력 길이 제한, 정