# OpenAI의 에이전트 구축을 위한 실용 가이드 > Clean Markdown view of GeekNews topic #27459. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27459](https://news.hada.io/topic?id=27459) - GeekNews Markdown: [https://news.hada.io/topic/27459.md](https://news.hada.io/topic/27459.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-13T14:02:02+09:00 - Updated: 2026-03-13T14:02:02+09:00 - Original source: [openai.com](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/) - Points: 38 - Comments: 0 ## Summary LLM의 추론력과 도구 활용 능력이 발전하면서, 사용자를 대신해 **독립적으로 워크플로를 수행하는 ‘에이전트’** 가 새로운 시스템 범주로 자리 잡고 있습니다. 에이전트는 모델·도구·지침의 세 축으로 구성되어 복잡한 의사결정이나 **비정형 데이터 처리**가 필요한 업무를 자동화하며, 가드레일을 통해 데이터 프라이버시와 브랜드 일관성을 보호합니다. 단일 에이전트로 시작해 실제 사용자 검증을 거쳐 점진적으로 확장하는 **반복적 구축 방식**이 안정적 배포의 핵심입니다. ## Topic Body - 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 애플리케이션과 달리 에이전트는 **엔드투엔드 워크플로를 실행**하여 복잡한 의사결정, 비정형 데이터, 취약한 규칙 기반 시스템에 적합 - 신뢰할 수 있는 에이전트 구축을 위해: 유능한 모델과 잘 정의된 도구, 명확하고 구조화된 지침을 결합하고, 복잡도에 맞는 오케스트레이션 패턴을 사용하되 **단일 에이전트에서 시작해 필요할 때만 다중 에이전트로 확장** - 가드레일은 입력 필터링부터 도구 사용, 사람 개입까지 모든 단계에서 중요하며, 에이전트가 프로덕션에서 안전하고 예측 가능하게 운영되도록 보장 - 성공적 배포는 전부 아니면 전무가 아닌, **작게 시작해 실제 사용자와 검증하고 시간이 지나며 역량을 성장**시키는 반복적 접근 방식 * [PDF 로도 제공됨](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf) ## Comments _No public comments on this page._