Taxonomy of agentic primitives in Amazon Quick

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Quick은 에이전트 작업을 ‘언제·무엇을·누가·어떻게’로 나누고, 트리거·에이전트·역량과 학습을 조합해 사용자가 요구하는 신뢰 수준에 맞추는 분류 체계를 제시한다.

📌 핵심 요약

• Amazon Quick은 같은 개념이 서로 다른 이름으로 반복 구현되면서 생긴 혼란을 줄이기 위해, 트리거가 ‘언제·무엇을’, 에이전트가 ‘누가’, 도구·스킬·워크플로로 구성된 역량이 ‘어떻게’를 담당하는 체계를 정리했다.
• 트리거는 작업을 시작하면서 지시도 전달하며, 사람이 시작하는 요청·에이전트의 위임·예약 실행·외부 이벤트로 구분된다. 불확실할 때 예약 작업은 보수적으로 행동하고 대화형 요청은 질문하는 등 실행 방식도 달라질 수 있다.
• 에이전트는 지속적으로 존재하며 학습하는 행위자로, 지침·역량·학습된 맥락으로 구성된다. 기반 대규모 언어 모델은 교체 가능한 매개변수이고 대화 기록은 세션 상태이며, Slack을 매일 요약하는 요청은 대개 기존 에이전트에 트리거를 추가하는 문제다.
• 도구는 정형화된 스키마를 가진 단일 작업, 스킬은 판단의 여지를 남기는 지침과 자료 묶음, 워크플로는 코드가 순서·분기·오류 처리를 정하는 조정 방식이다. 이 선택은 에이전트의 재량과 사용자가 미리 고정할 범위에 관한 ‘신뢰 계약’을 나타낸다.
• 저자들은 모델이 개선돼도 스킬의 조직 전문지식 보존·공유 가치와 워크플로의 감사 가능성·단계별 가시성이 남는다고 주장한다. 학습에 따라 스킬과 워크플로는 서로 전환될 수 있으며, 사용자의 신뢰 요구를 충족하는 가장 단순한 구성에서 출발하는 설계를 권한다.

🧩 주요 포인트

1. 작업 시작 조건과 수행 주체의 분리 → 예약 실행이나 Slack 요약 요구가 생길 때마다 새 에이전트를 만들 필요가 줄고, 하나의 행위자가 대화와 예약 작업을 함께 맡을 수 있다.
2. 스킬과 워크플로의 순서 결정 주체 차이 → 상황에 맞춘 판단이 필요한지, 고정된 절차와 감사 가능성이 필요한지에 따라 에이전트의 재량 범위를 선택할 수 있다.
3. 학습된 맥락의 누적과 구성 방식의 전환 → 지침을 매번 수작업으로 바꾸지 않아도 실행을 개선하고, 필요에 따라 스킬을 워크플로로 구체화하거나 다시 유연하게 바꿀 수 있다.

🧠 상세 정리

1. 반복 구현과 용어 혼란에서 출발한 분류 체계

Amazon Quick을 개발하는 동안 에이전트는 질문에 답하는 수준에서 회의 예약, 조사 수행, 보고서 생성처럼 행동하는 수준으로 확장됐다. 그 과정에서 작업을 수행하는 행위자, 시작 신호, 묶음 절차, 경험을 이어 가는 기억이 서로 다른 이름으로 반복 구현됐고, 이 혼란이 제품 설계와 사용자 경험에도 드러났다. 예를 들어 Slack 채널을 지켜보다 매일 요약을 보내 달라는 요청이 새 에이전트인지, 기존 에이전트의 예약 지시인지, 워크플로인지, 스킬인지 구분하기 어려웠다. 저자들은 이를 ‘언제·무엇을·누가·어떻게’라는 네 질문으로 분해하고, 트리거·에이전트·역량의 관계로 정리했다. 이 공통 어휘는 개발자가 시스템을 이해하도록 돕되, 대부분의 구조는 사용자에게 보이지 않도록 설계한다.

2. 트리거는 시작 시점과 작업 내용을 함께 전달

트리거는 작업을 활성화하는 장치인 동시에 수행할 지시를 담으므로 ‘언제’와 ‘무엇을’을 함께 담당한다. 사람이 대화를 열어 요청하는 경우는 상호작용과 동기적 대화가 중심이며, 작업 중인 에이전트가 다른 에이전트에 하위 문제를 맡기는 위임은 프로그램 방식으로 조합되거나 재귀적으로 이어질 수 있다. 예약 트리거는 매주 월요일 오전 9시에 재무 조사를 수행하는 것처럼 정해진 시각마다 같은 상시 지시를 적용한다. 이벤트 기반 트리거는 새 이메일, Slack 멘션, 파일 변경, 웹훅 같은 외부 신호에서 시작된다. 트리거의 종류는 실행 태도에도 영향을 주며, 원문은 불확실할 때 예약된 백그라운드 작업은 아무것도 하지 않는 보수적 대응을, 사람이 시작한 요청은 멈추기보다 질문하는 대응을 예로 든다.

3. 에이전트는 지침 자체가 아닌 학습하는 행위자

원문은 에이전트를 지속적으로 존재하며 학습하는 행위자로 정의하고, 실행에서 ‘누가’를 담당하며 학습이 축적되는 기준점으로 본다. 에이전트는 역할과 운영 원칙을 정하는 지침, 동적으로 바뀌는 도구·스킬·워크플로·하위 에이전트 등의 역량, 사용 과정에서 쌓이는 학습된 맥락으로 구성된다. 따라서 같은 입력을 받아도 각자의 지침과 역량, 경험이 다르면 결과가 달라질 수 있으며, 에이전트는 지침을 해석하는 주체이지 지침 자체가 아니다. 반면 기반 대규모 언어 모델은 교체 가능한 매개변수이고, 대화 기록은 세션별 상태이며, 트리거는 플랫폼에 속한다. 이 정의에 따르면 매일 아침 Slack 요약을 보내 달라는 요구는 대개 기존 에이전트에 트리거를 더하는 것으로 충족되며, 하나의 행위자가 대화·예약 실행·과거 작업 점검을 함께 맡을 수 있다.

4. 도구·스킬·워크플로가 나누는 실행 재량

역량은 에이전트가 ‘어떻게’ 행동하는지를 정하며, 자율적 판단에서 결정적인 실행까지 이어지는 범위를 이룬다. 도구는 이메일 전송이나 데이터베이스 조회처럼 정형화된 스키마를 가진 단일 작업으로, 로컬 함수든 MCP 서버든 프로토콜 경계 너머의 다른 에이전트든 호출자는 이름·설명·매개변수·결과라는 같은 형태의 인터페이스를 본다. 스킬은 템플릿·스크립트·예시 등을 지침과 묶어 접근법을 제시하면서 판단의 여지를 남기고, 처음에는 이름과 짧은 설명만 공개한 뒤 관련성이 생기면 전체 지침을 읽는 점진적 공개 방식을 쓴다. 워크플로는 단계·제어 흐름·분기·오류 처리를 선언하고 코드가 순서를 정하지만, 각 단계 안의 판단은 여전히 에이전트가 맡을 수 있다. 이 차이는 에이전트가 유지할 재량과 사용자가 사전에 고정할 범위를 정하는 ‘신뢰 계약’으로 설명된다.

5. 모델 개선 이후에도 남는 가치와 상호 전환

저자들은 모델 성능이 계속 좋아지면 스킬과 워크플로가 불필요해지는 것 아니냐는 반론을 제기한 뒤, 두 방식에는 모델 능력과 독립적인 가치가 있다고 답한다. 스킬은 조직의 전문지식을 포착하고 버전을 관리하며 공유하는 단위이고, 워크플로는 감사 가능성, 단계별 가시성, 여러 서비스에 걸친 결정적인 조정을 제공한다는 설명이다. 다만 이 구분은 고정돼 있지 않아, 충분히 이해된 스킬은 절차가 엄격한 워크플로로 굳어지는 결정화 과정을 거칠 수 있다. 반대로 예외 상황에 계속 부딪히는 워크플로는 판단의 여지를 넓힌 스킬로 돌아가는 용해 과정을 거칠 수 있다. 원문은 Quick의 지속 학습 프레임워크가 이러한 전환을 수행한다고 설명하지만, 구체적인 작동 방식은 후속 글에서 다룰 대상으로 남긴다.

6. 같은 요청을 신뢰 요구에 맞게 조합하는 설계

Slack 채널의 일일 요약이라는 같은 요청도 한 줄 지시를 담은 예약 작업, 형식 규칙과 채널 우선순위를 명시한 스킬, 결정적인 단계와 오류 처리를 갖춘 워크플로로 각각 구현할 수 있다. 결과의 공통점은 정해진 일정에 요약을 제공한다는 것이고, 차이는 사용자가 에이전트를 얼마나 신뢰하며 일관성과 절차 통제를 얼마나 요구하는지에 있다. 원문은 에이전트를 신뢰하는 사용자, 일관성 부족을 경험한 사용자, 규정 준수에 민감한 프로세스를 운영하는 사용자를 각 선택의 예로 든다. 또한 긴급 이메일 확인처럼 한 문장으로 시작한 작업도 효과적인 질의, 선호 형식, 중요한 발신자에 관한 학습을 축적해 수작업으로 지침을 바꾸지 않고 개선될 수 있다고 설명한다. 저자들이 권하는 방향은 신뢰 요구를 충족하는 가장 단순한 구성에서 시작하고 자율 학습을 통해 발전할 여지를 두는 것이며, 사용자는 원하는 일만 말하고 시스템이 적절한 기본 요소를 조합하도록 하는 것이다.

🧾 핵심 주장 / 시사점

• 에이전트의 정체성을 기반 모델이나 개별 세션과 분리하면, 모델을 교체하거나 실행 계기를 바꾸더라도 학습이 축적되는 주체를 일관되게 설명할 수 있다.
• 스킬과 워크플로의 선택은 모델 성능만의 문제가 아니라 조직 지식의 공유, 실행 재량, 절차의 가시성과 감사 가능성에 관한 설계 판단이다.
• 공통 분류 체계의 목적은 사용자에게 새 용어를 학습시키는 데 있지 않고, 시스템이 요청과 신뢰 요구에 맞는 구성을 선택해 복잡성을 감추는 데 있다.

✅ 액션 아이템

• Slack 일일 요약 요청을 기존 에이전트에 트리거를 추가하는 방식으로 충족할 수 있는지 검토.
• 사용자의 신뢰 요구와 감사 가능성 필요에 따라 한 줄 지시·스킬·워크플로 중 가장 단순한 구성을 선택.
• 학습된 맥락에 따른 실행 개선과 스킬·워크플로 간 전환 필요성을 평가.

❓ 열린 질문

• Slack 일일 요약 요청은 기존 에이전트에 트리거를 추가하는 것으로 충분한가?
• 사용자의 신뢰 요구를 충족하려면 스킬의 판단 재량과 워크플로의 고정 절차 중 어느 쪽이 필요한가?
• 학습된 맥락이 누적될 때 스킬을 워크플로로 구체화하거나 다시 유연하게 바꿀 시점은 무엇을 기준으로 판단할 수 있는가?