AWS의 AIRE 팀이 Kiro의 1주년 기념 주간(#KiroTurns1)을 맞아 발행했습니다.

1년 전 Kiro가 출시되었을 때, 우리 팀은 이것이 성공할지 지켜보며 기다리지 않았습니다. 우리는 바로 Kiro IDE를 열고 구축을 시작했습니다.

그 1년의 결과물로 탄생한 것이 바로 Neo입니다. Neo는 AWS 솔루션 아키텍트 (Solutions Architects)를 위한 에이전트형 AI (agentic AI) 팀원입니다. Neo는 이메일을 분류하고, 고객 미팅을 준비하며, 계정을 조사하고, 현장 인사이트 (field insights) 초안을 작성하며, 운영상의 번거로운 작업들을 자동화합니다. 이를 통해 아키텍트들이 브라우저 탭과 씨름하는 대신 고객에게 더 많은 시간을 할애할 수 있도록 돕습니다. Neo는 단일 Kiro CLI 에이전트로 시작되었으며, 오늘날에는 우리 현장 조직 전반에 걸쳐 약 천 명의 사람들에게 서비스를 제공하고 있습니다.

이 포스트는 이번 주 LinkedIn에 공유했던 이야기의 긴 버전입니다. 이것은 제품 발표가 아닙니다 — Neo는 내부 도구입니다. 이는 밑바닥에서 끊임없이 진화하는 플랫폼 위에서 프로덕션급 에이전트 시스템 (production agentic system)을 구축한다는 것이 어떤 것인지, 그리고 왜 그것이 결과적으로 가장 좋았던 점이었는지에 대한 빌더의 회고록입니다.

한 문장 요약

다른 것은 잊더라도 이것만은 기억하세요: 에이전트형 AI (agentic AI)에서의 지속 가능한 우위는 모델 (model)이 아니라, 모델을 둘러싼 하네스 (harness)에 있습니다. 루프 (loops), 메모리 (memory), 검증 게이트 (validation gates), 그리고 인터페이스 (surfaces) 말입니다. 모델이 헤드라인을 장식한다면, 하네스는 실제 업무를 완수합니다. Kiro의 첫 1년이 우리에게 중요했던 이유는 하네스 프리미티브 (harness primitives)를 지속적으로 출시했기 때문이며, 그 각각의 요소가 출시된 바로 그 주에 보통 실질적인 무언가를 가능하게 했기 때문입니다.

Neo의 실체

회고에 앞서 간단한 투어를 진행하겠습니다 — 왜냐하면 아키텍처 (architecture)가 곧 이야기이기 때문입니다.

Figure 1 — The Neo ecosystem: a lightweight router dispatches to subagents, persists to local memory, and reaches work systems through typed CLIs first, MCP servers as fallback.

Neo는 핵심적으로 의도적으로 지루하게 설계되었습니다. 즉, **경량 라우터 에이전트 (lightweight router agent)**입니다. 모든 것에 대해 똑똑해지려고 노력하지 않습니다. Neo의 유일한 임무는 각 요청을 세 가지 대상 중 하나—타입이 지정된 CLI 호출 (typed CLI call), 특화된 서브에이전트 (specialized subagent), 또는 패키징된 워크플로우 (packaged workflow)—로 해결한 다음, 이를 실행하고, 결과를 병합하여 사용자가 실제로 머무는 곳(이메일, 채팅, 로컬 대시보드)으로 전달하는 것입니다.

그 라우터 주변에는 네 가지 요소가 자리 잡고 있습니다:

• 10개의 특화된 서브에이전트 (specialized subagents): 각 에이전트는 고유의 좁은 도구 세트를 보유합니다: 이메일 분류 (email triage), 회의 준비 (meeting prep), 계정 조사 (account research), 티켓 분류 (ticket triage), 문서 및 다이어그램 (documentation and diagrams), 심층 전문가 Q&A (deep-expert Q&A), 요청 초안 작성 (request drafting), 지식 검색 (knowledge search), 여행 조회 (travel lookups), 그리고 일반적인 폴백 (general fallback).
• 로컬 메모리 시스템 (local memory system): 사용자의 기기에 있는 SQLite를 사용하며, 네임스페이스 (namespaces), 전문 검색 (full-text search) 및 시맨틱 검색 (semantic search), 그리고 에이전트가 학습한 내용을 컴파일, 인덱싱 및 정리(prune)하는 야간 자동화 기능을 갖추고 있습니다. 가공되지 않은 컨텍스트 (raw context)는 줄이고, 구조화된 회상 (structured recall)은 늘렸습니다.
• 타입이 지정된 CLI (typed CLIs) 군단: 작업 시스템에 접근하기 위한 선호되는 액세스 계층이며, MCP 서버를 폴백으로 사용합니다. 백엔드와 인증은 동일하지만, 복합적인 CLI 호출이 다섯 번의 도구 왕복 (tool round-trips)을 대체하여 토큰 사용량을 10배가량 줄여주며, 대화가 불가능한 크론 잡 (cron jobs)이나 스크립트에서도 작동합니다.
• 로컬 브라우저 대시보드 (local browser dashboard): 작업 큐 (task queues), 검토 워크플로우 (review workflows), 그리고 예약된 자동화 (scheduled automations)를 위한 용도입니다.

모든 것은 **로컬 우선 (local-first)**입니다. 에이전트의 메모리, 사용자의 데이터, 실행 환경 — 이 모든 것이 사용자의 기기 위에 있습니다. 이는 미적인 선택이 아닙니다. 고객 데이터를 새로운 서비스로 이동시키지 않고도 내부 AI 팀원을 배포할 수 있게 만드는 핵심 요소입니다.

네 가지 기본 요소(primitives)를 통해 본 1년

지난 1년 동안 우리에게 남은 것은 다음과 같습니다. 단 하나의 기능이 아니라, 바로 그 리듬(cadence)입니다. Kiro가 새로운 기본 요소 (primitive)를 출시할 때마다, 보통 며칠 내로 Neo에서 실질적인 무언가가 해금되었습니다.

Figure 3 — Four platform primitives, four unlocks: agent format → subagent fleet; delegation → parallel fan-out; ACP → new hosts with zero new agent code; multi-runtime → one spec, many surfaces.

1. 에이전트 형식 (agent format): 하나의 라우터에서 군단으로

초기 Neo는 매우 긴 프롬프트(prompt)와 너무 많은 도구(tools)를 가진 단일 에이전트였습니다. 데모가 작동하는 방식처럼, 일단 작동은 했습니다.

Kiro가 제대로 된 에이전트 형식 (agent format) — 에이전트의 프롬프트, 도구, 권한을 정의하는 선언적 명세(declarative spec) — 을 출시했을 때, 설계의 압박은 반전되었습니다. 모든 것을 아는 하나의 에이전트 대신, 각각 한 가지를 아는 10개의 작은 에이전트와, 그들 사이에서 선택하는 것만이 유일한 기술인 라우터(router)를 정의할 수 있게 되었습니다.

이러한 분해(decomposition)가 Neo를 유지 관리 가능하게 만들었습니다. 5개의 도구와 하나의 작업만을 가진 하위 에이전트(subagent)는 테스트가 가능합니다. 50개의 도구를 가진 모놀리스(monolith)는 기도(prayer)에 가깝습니다.

Figure 2 — The router fans out to ten specialized subagents, then merges their results.

2. 하위 에이전트(Subagents) + 신뢰할 수 있는 위임(trusted delegation): 45분이 30초로

두 번째 돌파구는 위임 (delegation) 이었습니다. 즉, 라우터가 하위 에이전트를 생성하고, 인간이 모든 도구 호출(tool call)을 승인하지 않아도 이들을 신뢰하여 실행하게 하는 것입니다.

대표적인 워크플로우는 모닝 브리핑(morning briefing)입니다. 네 개의 하위 에이전트가 병렬로 팬아웃(fan out)됩니다 — 편지함 스캔, 일정 및 참석자 조사, 계정 확인, 보류 중인 요청 상태 확인 — 그리고 라우터는 이 결과들을 하나의 이메일로 병합(merge)합니다. 과거에 6개의 시스템을 오가며 탭을 전환하며 45분이 걸리던 작업이, 실제 에이전트 구동 시간(wall-clock agent time) 기준 약 30초로 단축되었습니다.

엔지니어링 측면의 교훈은 다음과 같습니다: 병렬 팬아웃(parallel fan-out)은 병합(merge) 단계가 주관적(opinionated)일 때만 유용합니다. 라우터는 단순히 네 개의 보고서를 이어 붙이는 것이 아닙니다. 도메인 전반에 걸쳐 상위 항목의 우선순위를 정하고, 이들을 연결하며(

출시된 날, 하나의 통합(integration)을 통해 라우터(router), 서브에이전트(subagents), 메모리(memory)를 포함한 전체 Neo 스택이 완전히 새로운 호스트 애플리케이션 내부에서 나타났습니다. 새로운 에이전트 코드는 전혀 필요하지 않았습니다. 오늘날 우리의 로컬 대시보드는 ACP를 통해 Neo를 구동합니다. 작업 큐(task queues), 예약된 자동화(scheduled automations), 검토 워크플로(review workflows)가 모두 터미널에서도 답변하는 것과 동일한 에이전트와 하나의 프로토콜로 통신합니다.

그때 우리는 Kiro 위에 앱을 만들고 있는 것이 아니라는 사실을 깨달았습니다. 우리는 플랫폼 위에서 구축하고 있었던 것입니다. 에이전트는 지속 가능한 자산(durable asset)이며, 인터페이스(surface)는 교체 가능한 것입니다.

4. 멀티 런타임(Multi-runtime): 하나의 에이전트 명세, 다양한 인터페이스

ACP 통찰의 논리적 종착점은 다음과 같습니다. Neo의 페르소나(persona)는 특정 런타임(runtime)의 설정 형식(config format)이 아니라 에이전트 명세(agent specs), 기술(skills), 컨텍스트 파일(context files)에 존재하기 때문에, 동일한 두뇌가 이제 여러 하네스(harnesses)에서 실행됩니다. Kiro CLI는 원래의, 그리고 여전히 주요한 런타임으로서 베이스캠트로 남았지만, 동일한 명세가 다른 에이전트 호스트로 배포되며 모든 인터페이스는 동일한 로컬 메모리를 공유합니다.

1년이 지난 지금, "어떤 런타임에 베팅해야 하는가?"라는 질문은 잘못된 질문이었음이 드러났습니다. 올바른 질문은 "런타임 변경 시에도 살아남을 수 있는 가장 작은 페르소나 패키지는 무엇인가?"였습니다. Kiro의 프리미티브(primitives)가 우리가 그 질문에 답할 수 있게 해주었습니다.

프로덕션에서의 다섯 가지 교훈 (데모에서는 가르쳐주지 않는 부분)

1. 키워드가 아닌 범위(scope)로 라우팅하세요. Neo는 세 가지 별도의 컨텍스트 계층을 유지합니다. 개인의 프라이빗 메모리(private memory), 협업 팀과 공유된 지식(knowledge), 그리고 더 넓은 조직적 컨텍스트(organizational context)입니다. 초기 버전은 "공유(shared)"나 "팀(team)"과 같은 표면적인 단어로 라우팅을 시도하여 오류를 범했습니다. 프로덕션 라우팅 규칙은 어휘가 아니라 _범위(scope)와 대상(audience)_을 지정해야 합니다.

2. 생성자(Generator)가 검증자(Validator)가 되어서는 안 됩니다. Neo에서 중요한 모든 쓰기(Write) 작업은 모델이 제어하지 않는 관문을 통과합니다. 필드 인사이트(Field insights)는 CRM에 반영되기 전에 반드시 인간 검토 대기열(Human review queue)을 거쳐야 하며, 회사 외부로 발송되는 모든 아웃바운드 이메일은 항상 '초안 작성 후 확인(Draft-and-confirm)' 방식을 따릅니다. 즉, 에이전트가 전체 초안과 결정된 수신자를 보여준 뒤 멈추는 것입니다. 에이전트가 "답장 초안 작성"을 "전송"과 혼동했던 사건 이후, 우리는 이 가드레일(Guardrail)을 추가했습니다. 한 번의 사고, 하나의 영구적인 규칙, 그리고 하나의 회귀 테스트(Regression test)가 만들어낸 결과입니다.

3. 에이전트를 소프트웨어처럼 회귀 테스트(Regression-test)하십시오. 에이전트는 소프트웨어이기 때문입니다. Neo는 두 부분으로 구성된 하네스(Harness)와 함께 출시됩니다. 라우터의 지식을 검증하는 프로토콜 수준의 테스트(라우터가 자신의 하위 에이전트(Subagents)를 알고 있는가? 받은 편지함 요청을 올바르게 라우팅하는가? '초안 작성 후 확인' 규칙을 명시하는가?)와 실제 도구 경로를 엔드 투 엔드(End-to-end)로 실행하는 비대화형 테스트(Non-interactive tests)가 그것입니다. 프롬프트(Prompt), 라우팅 규칙, 또는 스킬(Skill)에 가해지는 모든 변경 사항은 배포 전 전체 테스트 스위트(Suite)를 실행합니다. 프롬프트는 드리프트(Drift)하지만, 어설션(Assertion, 단언)은 변하지 않습니다.

4. 메모리는 부가적인 기능이 아니라 핵심 프리미티브(Primitive)입니다. Neo의 메모리는 네임스페이스(Namespaces), 보유 정책(Retention policies), 원시 엔트리(Raw entries)를 내러티브(Narratives)로 변환하는 야간 컴파일(Nightly compilation), 그리고 7일 후 에피소드 데이터(Episodic data)를 정리하는 가지치기(Pruning) 기능을 갖추고 있습니다. 목표는 더 많은 컨텍스트(Context)를 제공하는 것이 아니라, 더 나은 컨텍스트를 제공하는 것입니다. 우리가 측정한 모든 지표에서 구조화된 회상(Structured recall)은 단순한 원시 컨텍스트 주입(Raw context stuffing)보다 우수했습니다.

5. 복합적인 작업에는 타입이 지정된 CLI(Typed CLIs)를 선호하고, 도구 호출(Tool calls)은 대화용으로 남겨두십시오. 계정 데이터, 팀 정보, 오픈된 기회(Opportunities)를 결합하는 단일 복합 CLI 명령은 5번의 대화형 도구 호출을 대체합니다. 이는 토큰과 지연 시간(Latency)을 획기적으로 줄여줄 뿐만 아니라, 오프라인 및 크론(Cron) 작업도 가능하게 합니다. 지난 1년 동안 살아남은 패턴은 다음과 같습니다: 단일 조회에는 대화형 도구를, 복합적이거나 스크립트 작성이 가능하거나 예약된 모든 작업에는 타입이 지정된 CLI를 사용하는 것입니다.

생일을 맞이하며 얻은 교훈

Kiro에서의 1년 과정을 한 단락으로 압축하자면 다음과 같습니다: 디스패치(dispatch)가 가능한 가장 작은 라우터(router)로 시작할 것; 프롬프트가 두 가지 일을 수행하는 즉시 서브에이전트(subagents)로 분해할 것; 메모리(memory)를 일급 시스템(first-class system)으로 만들 것; 중요한 모든 쓰기(write) 작업 앞에 모델이 우회할 수 없는 검증 게이트(validation gates)를 둘 것; 그리고 당신의 아키텍처가 이를 계속 흡수할 수 있을 만큼 프리미티브(primitives)를 빠르게 출시하는 플랫폼을 선택할 것.

데모는 쉽습니다. 프로덕션(Production)은 어렵습니다. Kiro는 프로덕션을 가능하게 하는 프리미티브들을 계속해서 출시해 왔고, 우리는 그것들이 출시된 그 주에 바로 그 위에서 계속해서 구축해 나갔습니다.

Kiro의 첫 번째 생일을 축하합니다. 다음 1년도 기대하겠습니다. 🎂

AWS의 AIRE (AI Readiness and Engagement) 팀에서 제작되었습니다. Neo는 AWS 현장 팀을 위한 내부 도구이며 공개 제품이 아닙니다.

#TeamKiro #KiroTurns1 #1YearOfKiro #BuildWithKiro