지난 1년 동안 Amazon Quick을 개발하면서 우리의 에이전트들은 질문에 답하는 수준에서 행동을 수행하는 수준으로 발전했습니다: 회의 일정 잡기, 조사 수행, 보고서 생성 등이 그 예입니다. 시스템이 진화함에 따라 한 가지 문제가 계속되었습니다. 바로 에이전트 작업의 기반이 되는 기본 구성요소에 대한 공유된 정의가 없다는 점이었습니다. 몇 가지 동일한 아이디어들이 서로 다른 이름으로 계속 재구축되었습니다. 즉, 작업을 수행하는 행위자, 작업을 시작하는 신호, 패키지화된 절차, 교훈을 앞으로 전달하는 메모리가 그것입니다. 이러한 반복은 제품 설계로 스며들어 사용자에게까지 영향을 미쳤습니다.
예를 들어 사용자가 다음과 같이 말한다고 가정해 보겠습니다. “내 Slack 채널을 모니터링하고 매일 요약본을 보내줘”. 이것이 새로운 에이전트인가요, 기존 에이전트에 대한 예약된 지시인가요, 워크플로우인가요, 아니면 스킬인가요? 이것들은 서로 다른 질문이지만, 공유된 용어 체계가 없으면 하나의 혼란스러운 선택지로 뭉뚱그려집니다.
이 게시물에서는 우리가 최종적으로 정착시킨 분류체계를 공유합니다. 즉, 에이전트 작업을 네 가지 단순한 질문으로 분해하여 도출한 하나의 기본 구성요소 세트입니다: 언제(When)?, 무엇을(What)?, 누가(Who)?와 어떻게(How)? 이 프레임워크의 대부분은 설계상 최종 사용자에게 보이지 않지만, 공유된 용어 체계는 그 아래에서 개발하는 모든 사람이 시스템을 더 쉽게 이해할 수 있게 해줍니다.
프레임워크 한눈에 보기
그림 1: 트리거, 에이전트, 역량이 서로 어떻게 연관되어 있으며, 세션 런타임에서 학습이 피드백되는 방식
A trigger (트리거)는 작업을 시작하고 작업 내용을 전달하며(When 과 What), an agent (에이전트)가 이를 맡아(Who) 자신의 capabilities (역량 — 도구, 스킬, 워크플로우)를 사용하여 작업을 수행합니다(How). 이 게시물에서는 이러한 기본 구성요소들과 그 상호 관계를 설명합니다. 이것은 시리즈의 첫 번째 게시물이며, 이후 게시물에서는 우리의 에이전트 운영 체제, 백그라운드 학습, 능동적 피드 등을 다룰 예정입니다.
트리거: 작업 시작의 원인이 되는 것
트리거(trigger)는 작업을 수행하기 위한 활성화 메커니즘이지만, 동시에 지시사항도 담고 있습니다: 사람의 메시지는 활성화의 순간이자 무엇을 할지에 대한 설명입니다. 트리거는 작업의 언제? 와 무엇을? 을 모두 담당합니다.
- 사람이 시작함: 사람이 대화를 열고 에이전트에게 무언가를 하도록 요청합니다. 대화형, 동기식, 대화 중심입니다.
- 에이전트가 위임함: 한 에이전트가 작업 중에 다른 에이전트를 호출하여 하위 문제를 처리하게 합니다. 프로그래밍 방식, 조합 가능, 잠재적으로 재귀적입니다.
- 예약됨: 시간 기반 활성화입니다. 예를 들어 “매주 월요일 오전 9시에 금융 리서치 실행”과 같습니다. 결정론적이며, 동일한 상시 지시사항이 각 실행에 걸쳐 적용됩니다.
- 이벤트 기반: 새 이메일, Slack 멘션, 파일 변경, 웹훅(webhook) 같은 외부 시스템의 신호입니다.
트리거의 유형은 실행 방식을 조건화합니다: 예약된 백그라운드 작업은 보수적으로 유지할 수 있고(예: 불확실하면 아무것도 하지 않음), 사람이 시작한 작업은 대응적일 수 있습니다(예: 중단하기보다 묻기).
에이전트
우리는 에이전트를 지속적이고 학습하는 행위자로 정의합니다. 에이전트는 모든 실행에서의 누가? 이며, 학습이 축적되는 기준점입니다. 동일한 입력을 받은 두 에이전트는 서로 다른 지시사항, 역량, 이력을 가지고 있기 때문에 달라질 수 있습니다. 에이전트는 자신이 따르는 지시사항이 아니라, 그 지시사항을 해석하는 개체입니다. 에이전트는 세 가지로 구성됩니다:
- 지시사항: 페르소나, 역할, 컨텍스트 파일, 운영 원칙을 정의하는 상시 지침입니다. 금융 에이전트가 일반 어시스턴트와 다르게 행동하는 것은 주로 이 때문입니다.
- 역량: 사용 가능한 도구, 스킬, 워크플로, 하위 에이전트로, 동적으로 업데이트됩니다. 차트 라이브러리는 한 세션에서 추가되었다가 다음 세션에서 제거될 수 있습니다.
- 학습된 컨텍스트: 사용을 통해 축적되는 기억입니다: 도구에 대해 잘 작동하는 쿼리, 사용자가 선호하는 형식, 사용자가 신경 쓰는 엣지 케이스 등입니다. 이것이 누구도 지시사항을 바꾸지 않고도 열 번째 실행이 첫 번째 실행보다 나은 이유입니다.
그 외의 모든 것은 외재적입니다: 에이전트의 기반이 되는 대규모 언어 모델(LLM)은 교체 가능한 모델 파라미터이고, 대화 이력은 세션별 상태이며, 트리거는 플랫폼에 속합니다.
이 정의의 한 가지 결과는, 사용자의 요청 “매일 아침 요약본을 보내주는 내 Slack 모니터링 에이전트가 필요해”가 대개 새로운 에이전트나 워크플로가 아니라 기존 에이전트에 추가된 트리거라는 점입니다. 이 관점을 통해, 우리는 채팅, 예약, “자율” 에이전트를 하나의 행위자로 통합할 수 있습니다. 즉, 대화할 수 있고, 예약할 수 있으며, 자신의 과거 작업을 조율하고 검토할 수 있는 행위자로 말입니다.
역량
역량이란 에이전트가 어떻게 행동하는가를 말하며, 완전한 에이전트형에서 완전한 결정론적 방식까지의 스펙트럼에 걸쳐 있습니다. 이 축은 본질적으로 신뢰 계약입니다. 즉, 에이전트가 어느 정도까지 재량을 유지하는지, 그리고 사용자가 사전에 어느 정도까지 고정하는지를 나타냅니다.
도구 는 타입이 지정된 스키마를 갖는 원자적 연산입니다. 이메일 보내기, 데이터베이스 조회, 파일 읽기 등이 그 예입니다. 로컬 함수, Model Context Protocol (MCP) 서버, 또는 프로토콜 경계 너머의 다른 에이전트든 관계없이 호출자에게는 동일한 인터페이스가 보입니다. 이름, 설명, 매개변수, 결과입니다.
스킬 은 판단의 여지를 남겨두는 구조화된 안내입니다. 접근 방식을 설명하되 엄격한 순서는 아닌, 리소스(템플릿, 스크립트, 예제)와 함께 번들로 제공되는 지침입니다. 스킬은 점진적 공개를 통해 로드되므로, 에이전트는 관련성이 생기기 전까지는 이름과 짧은 설명만 보다가, 관련성이 생기면 전체 지침을 읽어들입니다. 따라서 스킬은 상시 비용 없이 임의의 깊이의 전문 지식을 번들로 담을 수 있습니다.
워크플로우 는 결정론적 조정입니다: 선언된 단계, 제어 흐름, 분기 및 오류 처리가 고정된 순서로 실행되며, 의사 결정 로직은 모델 추론이 아닌 코드에 있습니다. 구매 승인 경로를 생각해 보십시오: 예산 확인, 관리자 서명, 그 후 재무팀, 각 단계가 기록됩니다. 경로는 고정되어 있지만, 단계 내부의 판단은 여전히 에이전트의 몫입니다.
그림 2: 스킬과 워크플로우의 비교. 단계 순서를 에이전트가 결정하는지 코드가 결정하는지가 다릅니다
스킬과 워크플로우가 모델 발전보다 오래 지속되는 이유
자연스러운 의문이 생깁니다: 모델이 계속 개선된다면 스킬과 워크플로우는 불필요해지지 않을까요? 우리는 그렇지 않다고 생각합니다. 각각이 모델 능력과 무관하게 독립적인 가치를 지니기 때문입니다. 스킬은 조직의 전문 지식을 포착하고, 버전을 관리하고, 공유하는 단위이며, 워크플로우는 감사 가능성, 단계별 가시성, 그리고 결정론적인 다중 서비스 조정을 제공합니다. 또한 이들은 고정되어 있지 않습니다: 잘 이해된 스킬은 워크플로우로 강화될 수 있고(결정화), 경계 사례를 계속 맞닥뜨리는 워크플로우는 다시 스킬로 완화될 수 있습니다(해체). 이는 Quick의 지속적 학습 프레임워크를 통해 수행되며, 이는 이후 게시물에서 설명할 예정입니다.
실무에서 이것이 의미하는 바
“내 Slack 채널을 모니터링하고 매일 요약본을 보내줘”로 돌아가 보겠습니다. 이러한 프리미티브는 조합 가능하기 때문에, 동일한 요청을 여러 가지 유효한 방식으로 충족할 수 있습니다:
- 한 줄 지시문이 담긴 예약 작업으로, 나머지는 에이전트가 알아서 처리하도록 하는 방식.
- 명시적인 서식 규칙과 채널 우선순위를 갖춘 스킬로 뒷받침되는 동일한 작업.
- 결정론적 단계와 오류 처리를 갖춘 워크플로우를 호출하는 동일한 작업.
세 가지 모두 일정에 따라 매일 요약본을 생성합니다. 달라지는 것은 신뢰 계약입니다. 에이전트를 신뢰하는 사용자는 첫 번째를, 일관성 부족으로 한 번 상처 입은 사용자는 두 번째를, 규정 준수에 민감한 프로세스를 운영하는 사용자는 세 번째를 원합니다.
학습은 시간이 지남에 따라 그 궤적을 바꿉니다. 한 문장으로 시작하는 작업(“내 이메일에서 긴급 항목 확인해 줘”)은 도메인에 묶인 학습을 축적합니다: 효과적인 쿼리, 선호하는 서식, 그리고 어떤 발신자가 중요한지 등. 누군가 손으로 직접 작성하지 않아도 열 번째 실행은 눈에 띄게 더 좋아집니다. 올바른 설계는 사용자의 신뢰 요구 사항을 충족하는 가장 단순한 옵션이며, 더 많은 것이 필요할 때 자율 학습을 통해 단계적으로 발전할 수 있는 경로를 제공하는 것입니다.
결론
이 에이전틱 프리미티브 분류법의 가치는 네 가지 평범한 질문, 언제, 무엇을, 누가그리고 어떻게, 만으로 한 줄 채팅 요청부터 예약된 규정 준수 등급의 프로세스에 이르기까지 어떤 에이전틱 작업이든 분류할 수 있다는 점입니다. 하나의 어휘를 공유하면 빌더는 시스템에 대해 추론할 수 있고 제품은 복잡성을 숨길 수 있습니다. 무엇보다 좋은 점은 사용자가 이들 중 어떤 것도 배울 필요가 없다는 것입니다. 사용자는 원하는 것을 말하기만 하면, 시스템이 그 작업을 수행할 적절한 프리미티브를 조립합니다.
시리즈 다음 편: 이러한 프리미티브를 기반으로 구축되어 Amazon Quick을 구동하는 에이전틱 운영 체제.
계속 탐색하기
- 시작할 준비가 되셨나요? 다음으로 시작해 보세요: Amazon Quick 시작 가이드.