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