AWS Kiro로 AI 에이전트 개발하기: 멀티 에이전트 설계와 Harness Engineering 완벽 가이드(1편)
- 2일 전
- 6분 분량
최종 수정일: 1일 전
AWS Kiro로 AI 에이전트 개발하기: 멀티 에이전트 설계와 Harness Engineering 완벽 가이드(1편)
Written by Eunmin Jeon
목차
들어가며
지난 AWS 유니콘데이에서 주목할 만한 세션이 진행되었습니다. 제목은 "Kiro × Strands Agents × AgentCore로 Production-Ready 음성 비서 만들기"로, 키로를 활용한 실습 세션이었습니다.
특히 이번 AWS 유니콘데이에서 가장 많이 언급된 키워드 중 하나가 바로 Kiro였는데요. 이번 세션은 그 흐름을 가장 구체적으로 보여준 사례였습니다.
세션은 두 파트로 나뉘어 진행되었습니다.
Kiro + Strands Agents로 에이전트 개발 환경 구성
AgentCore로 프로덕션 배포
1편에서는 첫 번째 파트인 개발 환경 구성을 중심으로 다룰 예정입니다. 개념 중심으로 설명하되, 실습 흐름도 함께 담았는데요. 직접 구현해 보시려면 해당 발표자료와 공식 문서 링크를 참고하시기 바랍니다.
1. AI 개발 패러다임 변화: 왜 이제는 “에이전트 중심 개발”인가?
세션은 현재 개발 방식 변화를 나타내는 문장과 함께 시작되었습니다.
Human Steers, Agent execute 사람은 방향을 제시하고, 에이전트가 실제 동작을 실행합니다.
여기서 ‘Steer’는 단순한 지시가 아니라, 무엇을 해야 하는지, 어떤 방향으로 진행할지를 설계하는 역할을 의미합니다.
반면 ‘Execute’는 실제 작업을 수행하는 단계로, 코드 작성, 테스트, 검증과 같은 실행 과정이 에이전트에 의해 이루어집니다.
기존 방식 | 현재 방식 |
사람이 직접 코드 작성 | 에이전트가 코드 실행 |
프롬프트 하나로 해결 시도 | 구조 설계 중심으로 전환 |
결과물을 직접 수정 | 에이전트 환경을 다시 설계 |
[개발 방식 변화]
이는 단순히 "AI가 코드를 대신 작성해준다"는 이야기가 아닙니다. 개발 패러다임 자체가 전환되고 있다는 의미인데요. 과거에는 개발자가 직접 코드를 작성하는 것이 중심이었다면, 현재는 구조를 설계하고 에이전트를 운영하는 방식으로 전환되고 있습니다.
즉, 사람은 ‘어떻게 할 것인가’를 정의하고, 에이전트는 ‘실제로 수행하는 것’을 담당하는 구조인 것이죠. 이는 단순한 역할 분담을 넘어, 개발의 중심이 실행에서 설계로 이동하고 있음을 보여줍니다.
2. Harness Engineering이란? — 에이전트 시스템 설계의 핵심
에이전트가 잘못된 결과를 냈을 때, 어떻게 대응해야 할까요? 일반적으로는 결과물을 수정하거나 프롬프트를 다시 작성하는 방식으로 접근합니다.
하지만 발표자는 이 접근 방식 자체를 바꿔야 한다고 말했습니다.
"결과가 잘못됐다면, 그 결과를 수정하는 것이 아니라 에이전트를 다시 설계하고 환경을 다시 만들어주는 것이 지금 집중해야 하는 엔지니어링 영역입니다."
이를 Harness Engineering이라고 부릅니다. Harness Engineering은 LLM 모델을 단순히 사용하는 것을 넘어, 모델이 제대로 작동할 수 있도록 실행 구조를 만들고 스스로 개선할 수 있는 루프를 설계하는 엔지니어링입니다.
Harness Engineering의 3가지 핵심 구성 요소
구성 요소 | 목적 |
Steering | 에이전트가 어떤 기준으로 판단하고 행동할지 가이드라인을 제공 |
Context Injection | 에이전트가 필요한 정보를 적절한 시점에 받을 수 있도록 설계 |
Scaffolding | 에이전트가 자율적으로 컨텍스트를 탐색하고 기능을 수행할 수 있는 구조적 실행 기반 제공 |
여기서 컨텍스트(Context)란, 에이전트가 올바른 결과를 내기 위해 필요한 배경 정보를 의미합니다. 예를 들어 "로그인 기능을 만들어줘"라고만 하면 에이전트는 어떤 언어로, 어떤 보안 정책에 맞게 만들어야 하는지 알 수 없습니다. 프로젝트의 기술 스택, 코딩 규칙, 관련 문서 등이 모두 컨텍스트에 해당합니다.
스캐폴딩(Scaffolding)은 건축에서 건물을 지을 때 임시로 세우는 비계(발판)에서 나온 용어입니다. AI에서는 에이전트가 작업을 잘 수행할 수 있도록 주변에 만들어주는 지원 구조를 의미합니다.
3. AWS Kiro란? AI 에이전트 개발을 위한 통합 환경
Kiro는 AWS에서 개발한 AI 통합 개발 환경으로, IDE와 CLI 두 가지 형태로 제공됩니다. VS Code 기반으로 만들어져 기존에 사용하던 익스텐션, 테마, 단축키를 그대로 쓸 수 있습니다. 프로토타입부터 프로덕션 개발까지 실제 개발 전 과정을 지원합니다.
Kiro는 Vibe Coding의 장점인 빠른 개발 속도는 유지하면서, 복잡한 태스크에서 발생하는 컨텍스트 오해나 의사결정 추적 부재 같은 단점을 보완하기 위해 설계되었습니다. Kiro는 한마디로 "바이브 코딩의 재미는 살리되, 프로덕션에서도 쓸 수 있게"가 목표입니다.
Kiro의 핵심 기능
이번 세션에서 소개된 Kiro의 핵심 기능은 다음 5가지입니다.
기능 | 역할 |
Spec-Driven Development | 요구사항 → 설계 → 실행 계획을 문서로 자동 생성 |
Context Management | Steering 파일로 에이전트 행동 기준 설정 |
MCP 연동 | 외부 도구 및 문서를 에이전트와 연결 |
Power | MCP·Steering·Hooks를 패키지로 묶은 확장 기능 |
Hooks | 파일 저장 등 이벤트 발생 시 자동 검증 실행 |
이를 통해 Kiro의 핵심은 단순한 개발 도구가 아니라 에이전트가 일관된 방식으로 동작하도록 구조를 설계하는 플랫폼라는 것을 알 수 있습니다.
구제적인 내용은 키로 공식 문서에서 확인해보세요. 📎 Kiro 공식 사이트: https://kiro.dev
4. Spec-Driven Development: 에이전트 개발 방식의 새로운 기준
Spec이란?
Kiro의 핵심 기능은 Spec-Driven Development, 즉 스펙 기반 개발입니다. 여기서 말하는 '스펙'은 단순한 기획 문서가 아닙니다. 모든 작업의 기준이 되는 Single Source of Truth(진실의 원천), 즉, 에이전트가 실제로 참고하고 실행하는 기준입니다. 한 번 작성하고 끝나는 문서가 아니라, 프로젝트가 성장하면서 함께 업데이트되는 살아있는 문서(Living Document)로 관리되어야 합니다.
3단계 스펙 워크플로우
Kiro는 채팅창을 통해 스펙 문서를 자동으로 생성해 줍니다. 프롬프트를 입력하면 Kiro가 먼저 유형을 확인하고, 그에 맞게 세 단계로 문서를 생성합니다.
Requirements (requirements.md) — 요구사항 및 수용 기준 정의
Design (design.md) — 기술 아키텍처 및 설계
Tasks (tasks.md) — 순서가 있는 실행 계획
이 중 design.md와 tasks.md는 참고 문서가 아닙니다. 에이전트가 실제 구현할 때 기준이 되는 문서(SSoT)로 활용됩니다.
Spec 3가지 유형
Kiro는 채팅창에서 스펙을 클릭 후, 프롬프트를 입력하면 먼저 이렇게 물어봅니다.
"새로운 기능을 만드는 거야, 아니면 버그를 고치는 거야?"
그 대답에 따라 세 가지 유형 중 하나로 자동으로 안내됩니다.
Requirements-first Specs는 가장 일반적인 방식입니다. 시스템의 동작(behavior)을 요구사항으로 먼저 정의하고, 거기서 기술 설계와 구현 태스크를 도출합니다. 고객 피드백 기반 기능 개발, 그린필드 프로젝트, 아키텍처가 유연한 제품 주도 조직에 적합합니다.
Design-first Specs는 기술 설계(아키텍처, 의사코드)를 먼저 작성하고, 거기서 실현 가능한 요구사항과 구현 태스크를 도출하는 방식입니다. 비기능 요구사항이 엄격하거나, 기술적 실현 가능성을 먼저 검증해야 하는 설계 주도 프로젝트에 적합합니다.
Bugfix Specs는 단순히 버그를 고치는 것을 넘어, 숙련된 개발자의 버그 수정 방식을 모델링한 유형입니다. 근본 원인 분석 → 수정 설계 → 회귀 방지 순서로 진행되며, 현재 동작(결함), 기대 동작(수정), 변경하지 않을 동작(회귀 방지)을 명시해서 에이전트가 "고칠 것"과 "건드리지 말 것"을 정확히 구분하도록 합니다. 복잡한 버그, 크리티컬 코드 경로, 이전 수정이 회귀를 일으킨 경험이 있는 상황에 적합합니다.
유형 | 사용 시기 |
Requirements-first | 일반적인 신규 기능 개발 시 |
Design-first | 비기능 요건이나 기술적 제약이 중요한 경우 |
Bug Fix | 기존 코드 개선 또는 회귀 버그 방지 목적 |
[유형별 사용 시기]
5. 컨텍스트 관리 전략: AI 에이전트 성능을 결정하는 요소
좋은 스펙은 좋은 컨텍스트에서 나옵니다. 에이전트가 좋은 결과를 내려면, 적절한 컨텍스트를 적절한 시점에 받아야 하는데요.
흔히 하는 실수가 있습니다. "많이 넣으면 더 잘 알겠지"라는 생각으로 처음부터 모든 정보를 에이전트에게 쏟아붓는 방식입니다. 하지만 에이전트는 정작 중요한 정보를 찾지 못하고 불필요한 내용에 혼란을 겪습니다. 사람도 처음 만나는 자리에서 모든 업무 히스토리를 한꺼번에 들으면 정리가 안 되는 것과 같은 이치입니다.
따라서 모든 정보를 미리 주입하는 것이 아니라 필요한 순간에 필요한 정보만 제공하는 구조가 중요합니다.
Kiro에서는 MCP + Powers + Steering 세 가지를 조합해서 컨텍스트를 관리합니다.
① MCP — 외부 도구와 문서를 에이전트에 연결
에이전트가 필요한 외부 정보를 가져오는 것은 물론, 외부 도구를 사용해 액션을 수행할 수 있도록 연결하는 역할입니다. Context 7 MCP를 통해 문서 맥락을 파악하고, AWS Knowledge MCP로 사내 지식을 검색하며, 필요하다면 직접 GitHub나 DB 등에 접근해 작업을 처리합니다. MCP를 통해 에이전트의 참고 소스와 실행 능력을 확장할 수 있습니다.
② Power — 필요한 순간에 활성화되는 기능 패키지
MCP, Steering, Hooks를 하나로 묶은 워크플로우 패키지입니다. Power의 핵심은 에이전트에게 모든 기능을 상시 노출하는 대신, 필요한 순간에만 관련 도구와 규칙을 활성화하여 에이전트의 혼란을 줄이고 컨텍스트 비용을 획기적으로 절약하는 것입니다. 예를 들어 Strands SDK Power를 설치하면, 에이전트가 시작할 때 모든 문서를 한꺼번에 불러오는 대신 작업에 필요한 순간에 문서와 MCP 도구만 그때그때 동적으로 주입받습니다.
③ Steering — 반복 실수를 방지하는 가이드라인
에이전트가 매 세션마다 같은 실수를 반복하거나 일관성 없이 동작하는 문제를 방지하기 위한 행동 지침입니다. "테스트 코드를 항상 먼저 작성할 것", "이전 세션에서 발생한 오류 목록" 같은 내용을 Steering 파일에 담아두면 에이전트는 이 기준을 참고해 동작합니다. 또한 Hooks와 조합하면 스펙 파일이 수정될 때마다 자동으로 일관성을 점검하는 루프도 구성할 수 있습니다.
결국 Kiro에서 컨텍스트 관리의 핵심은 "많이"가 아니라 "정확한 시점에, 필요한 만큼만"입니다.
6. 실습: Kiro로 멀티 에이전트 설계하기
스펙은 Kiro IDE로 생성하고, 실제 구현은 CLI로 진행했습니다.
왜 여러 에이전트를 만들었나?
에이전트 하나에 모든 걸 맡기면 어떻게 될까요? 코드를 짜다가 검증도 하고, 문서도 관리하고, 컨텍스트도 찾아야 합니다. 사람도 마찬가지지만, 한 사람이 모든 역할을 동시에 잘 하기는 어렵습니다. 에이전트도 같습니다.
그래서 발표자는 Manager Pattern(Agents as tools) 방식으로 역할을 명확히 나눈 5개의 에이전트를 만들었습니다. 각 에이전트는 메시지를 통해 서로 통신하며, 이 메시지는 하나의 목적만을 가지는 JSON 단일 객체로 구성됩니다. 덕분에 에이전트 간 역할이 명확히 분리되고, 각자의 책임 범위 안에서만 동작하게 됩니다.
Manager — 전체 작업을 분해하고, 각 에이전트에게 일을 배분하며, 완료 여부를 판단합니다.
Builder — Spec 문서를 기준으로 실제 코드를 구현합니다.
Reviewer — Builder가 만든 코드의 정확성, 회귀 위험, 유지보수성을 검토합니다.
Tester — 테스트를 추가하고 실행해서 pass/fail을 객관적으로 판단합니다.
Librarian — 구현에 필요한 컨텍스트를 수집하고, Spec 문서를 살아있는 문서로 유지합니다.
특히 구현(Builder)과 검증(Reviewer·Tester)을 분리한 것이 핵심입니다. 구현한 사람이 스스로 "다 됐다"고 판단하면 놓치는 문제가 생깁니다. 별도의 검증자가 있어야 객관적인 판단이 가능합니다.
실행 흐름
실제로 이 에이전트들이 어떻게 협력하는지 흐름을 보면 이렇습니다.
1. Manager가 Spec을 분석해 Task를 병렬로 분할
2. Librarian이 각 Task에 필요한 컨텍스트 수집
3. Manager가 Builder에게 컨텍스트 포함해서 작업 전달
4. Builder가 코드 작성
5. Reviewer · Tester가 동시에 검증 수행
6. Manager가 최종 완료 처리
7. Librarian이 커밋 + Spec 문서 업데이트
또 하나 중요한 원칙이 있습니다. 각 에이전트는 자신의 역할에 필요한 도구만 가져야 합니다. Librarian은 코드 구현 도구가 필요 없고, Builder는 문서 탐색 도구가 필요 없습니다. Manager가 이미 필요한 컨텍스트를 주입해주기 때문입니다. 불필요한 도구를 줄일수록 에이전트는 자신의 역할에 더 집중할 수 있습니다.
이 구조 덕분에 또 다른 장점이 생깁니다. 문제가 생겼을 때 어느 에이전트를 수정해야 할지 바로 특정할 수 있다는 점입니다. 에이전트 전체를 다시 만들 필요 없이, 문제가 생긴 역할의 에이전트만 개선하면 됩니다.
이 구조로 음성 비서 코드 구현이 30분도 채 걸리지 않았다고 합니다.
결론 : AI 에이전트 개발의 핵심은 “지식”이 아니라 “설계”다
이번 편에서는 Harness Engineering의 개념부터 Kiro를 활용한 에이전트 설계와 구현까지 살펴보았습니다.
핵심을 한 문장으로 정리하면 이렇습니다.
"에이전트에게 지식을 전달하는 것이 아니라, 생각하는 방법을 전달해야 합니다."
2편에서는 이렇게 만든 에이전트를 실제 프로덕션 환경에 배포하는 방법, Amazon Bedrock AgentCore를 다루겠습니다.
AI 에이전트 도입 또는 AWS 기반 아키텍처 설계에 대해 궁금한 점이 있으시다면 스마일샤크로 문의해 주시기 바랍니다.
문의: [전문가 상담 받아보기]
