▲

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

 (openai.com)
15P by GN⁺ 15시간전 | ★ favorite | 댓글과 토론
  • 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): 차단 목록, 입력 길이 제한, 정규식 필터 등 단순 결정론적 조치로 금지 용어나 SQL 인젝션 같은 알려진 위협 방지
    • 출력 검증(Output validation): 프롬프트 엔지니어링과 콘텐츠 검사를 통해 응답이 브랜드 가치에 부합하는지 확인

  • 가드레일 구축 접근법

    • 이미 식별된 리스크에 대한 가드레일부터 설정하고 새로운 취약점 발견 시 추가 계층화
    • 효과적 휴리스틱:
      • 데이터 프라이버시와 콘텐츠 안전에 집중
      • 실제 엣지 케이스와 실패 사례를 기반으로 새 가드레일 추가
      • 보안과 사용자 경험을 모두 최적화하며 에이전트 진화에 따라 가드레일 조정
    • Agents SDK에서는 가드레일을 일급 객체(first-class concept) 로 취급하며, 기본적으로 낙관적 실행(optimistic execution) 방식 사용 — 기본 에이전트가 선제적으로 출력을 생성하면서 가드레일이 동시에 실행되고, 제약 위반 시 예외를 트리거

  • 사람 개입 계획

    • 사람 개입은 사용자 경험을 해치지 않으면서 에이전트의 실제 성능을 개선할 수 있는 핵심 안전장치
    • 배포 초기에 특히 중요하며, 실패 식별, 엣지 케이스 발견, 견고한 평가 사이클 확립에 기여
    • 사람 개입이 필요한 두 가지 주요 트리거:
      • 실패 임계값 초과: 에이전트 재시도나 행동에 제한을 설정하고, 초과 시(예: 여러 시도 후에도 고객 의도 파악 실패) 사람에게 에스컬레이션
      • 고위험 행동: 민감하거나 되돌릴 수 없거나 높은 이해관계가 걸린 행동(예: 사용자 주문 취소, 대규모 환불 승인, 결제 처리)은 에이전트 신뢰도가 높아질 때까지 사람의 감독 필요

결론

  • 에이전트는 모호성을 추론하고, 도구를 통해 행동을 취하며, 다단계 작업을 높은 자율성으로 처리하는 워크플로 자동화의 새로운 시대
  • 단순 LLM 애플리케이션과 달리 에이전트는 엔드투엔드 워크플로를 실행하여 복잡한 의사결정, 비정형 데이터, 취약한 규칙 기반 시스템에 적합
  • 신뢰할 수 있는 에이전트 구축을 위해: 유능한 모델과 잘 정의된 도구, 명확하고 구조화된 지침을 결합하고, 복잡도에 맞는 오케스트레이션 패턴을 사용하되 단일 에이전트에서 시작해 필요할 때만 다중 에이전트로 확장
  • 가드레일은 입력 필터링부터 도구 사용, 사람 개입까지 모든 단계에서 중요하며, 에이전트가 프로덕션에서 안전하고 예측 가능하게 운영되도록 보장
  • 성공적 배포는 전부 아니면 전무가 아닌, 작게 시작해 실제 사용자와 검증하고 시간이 지나며 역량을 성장시키는 반복적 접근 방식