KIRO GA: 터미널(CLI)부터 엔터프라이즈 관리까지, 직접 해본 후기

작성자 송 상민 작성일 1월 21, 2026 조회수 77

KIRO GA: 터미널(CLI)부터 엔터프라이즈 관리까지, 직접 해본 후기

TL;DR

Kiro가 12월 reinvent를 기점으로 정식 출시(General Availability, GA)했습니다. 주요 핵심 기능은 아래와 같습니다.

1. Property-based Testing 
2. 새로운 체크포인트(Checkpoint) 시스템
3. Kiro CLI
4. Team Plans

1. 들어가며: Kiro GA 출시 소식

Kiro로 경험하는 Spec-driven Development: IDE, CLI와 엔터프라이즈 관리

좋은 기회로 Kiro(Amazon Q Developer) 글로벌 총괄 담당자와 이야기를 나눌 기회가 있었습니다. 당시 담당자는 영화 <아이언맨>의 자비스(Jarvis)에 비유하며 KIRO의 발전 방향을 이야기했습니다. 초기 아이언맨의 AI가 단순히 사용자의 자연어 명령을 입력받아 수행하는 데 그쳤다면, 후속작으로 갈수록 AI는 토니 스타크와 끊임없이 소통하고 논의하며 최적의 선택을 함께 도출해 내는 ‘파트너’로 진화합니다.

Kiro가 지향하는 바도 이와 같습니다. 단순한 코드 생성 도구를 넘어, 개발자와의 상호작용을 통해 의도를 명확히 하고 최적의 결과를 설계하는 AI 파트너이자 동료로 발전하고 있습니다. 

기존 코딩 프로젝트와 마찬가지로, 여러 AI 에이전트와 협업에서 만족할 만한 산출물을 위해선, 역시 ‘철저한 기획’에 있다는 것에 공감하실 겁니다. 많은 코딩 툴 또한 이러한 접근 방향으로 발전하고 있으며, 특히 Kiro는 이를 구체적인 ‘Spec(명세)’ 기능으로 가능케 했습니다. 이러한 Kiro가 12월 reinvent를 기점으로 GA가 되었는데요. 이어서 직접 경험해본 주요 기능에 대한 후기 등을 이야기 하겠습니다.

2. 바이브(Vibe)를 넘어, 이제는 설계(Design)로

‘Coding by Vibes’의 한계: 느낌만으로는 완성할 수 없다

최근 AI 코딩 씬에서는 일명 ‘Coding by Vibes’라는 말이 유행했습니다. 명확한 논리보다는 채팅창에 몇 마디 던져보고, AI가 그럴듯한 결과물을 내놓으면 “어? 되네?” 하고 넘어가는 개발 방식을 꼬집는 말입니다. 하지만 이런 ‘바이브’에 의존한 개발은 금세 한계에 부딪힙니다. 초기 프로토타입은 빠를지 몰라도, 요구사항이 복잡해지고 수정 사항이 쌓이면 AI는 맥락을 잃고 엉뚱한 코드를 뱉어내기 시작합니다. 개발자는 AI의 ‘운’을 바라는 기도 메타에 빠지게 되고, 결국엔 불확실한 결과물을 수습하느라 더 많은 시간을 쓰게 됩니다.

Spec-driven development

Kiro는 이제 “바이브(느낌)”가 아니라 “설계”를 주장합니다. Spec-driven Development는 개발자가 프로젝트의 큰 계획을 명확히 정의하고, AI는 그 규격에 맞춰 개발하는 구조입니다. 주요 장점은 아래와 같이 정리할 수 있습니다.

• 자연어로 된 막연한 요청을 구조화된 명세(Spec)로 변환하여 AI가 오해할 여지를 없앱니다.
• 대화가 길어져도 AI는 채팅 기록이 아닌, 불변의 ‘Spec’을 기준으로 코드를 작성하므로 일관성이 유지됩니다.

3. 직접 사용해본 추가 핵심 기능 4가지

3.1 Spec 정확성을 검증하는 Property-based Testing

AI가 작성한 코드가 정말 ‘내 의도’대로 작동할까요?

기존의 유닛 테스트는 작성자(사람 혹은 AI)가 생각할 수 있는 특정 시나리오에 국한된다는 한계가 있습니다. 작성자의 편향에 갇혀 엣지 케이스를 놓치기 쉽고, 기존 AI 모델은 종종 테스트를 통과하기 위해 코드를 고치는 대신 테스트 코드 자체를 조작하거나 무한 루프에 빠지기도 합니다.

Kiro는 이 문제를 해결하기 위해 Property-based Testing(속성 기반 테스트, PBT)을 도입했습니다.

특정 ‘예시’가 아닌, 불변의 ‘속성’을 테스트하다

PBT는 개별적인 예시를 테스트하는 대신, 시스템이 보편적으로 가져야 할 ‘속성(Property)’을 검증합니다. 작동원리는 아래와 같습니다.

• 작동 원리: KIRO는 사용자가 EARS(Easy Approach to Requirements Syntax) 포맷으로 작성한 명세를 분석합니다. 여기서 테스트 가능한 속성을 추출한 뒤, 수백에서 수천 개의 랜덤 테스트 케이스를 생성하여 코드를 검증합니다.*

출처 : Kiro: 프로토타입에서 프로덕션 레벨까지 지원하는 스펙 기반 Agentic IDE 출시

Kiro 기반의 사례 비교: 

기능을 확인해보시기 위해서 아래와 같이 은행 입출금 사례를 가정하고 실험해봤습니다. Kiro의 스팩 주도형 개발은 개발에 필요한 디자인을 직접 작성할 필요 없이 Kiro와 대화를 통해 디자인을 설계할 수 있습니다. 아래와 같이 Kiro IDE에서 대화 패널의 [Spec]을 통해 Design에 Property까지 생성해보았습니다.

생성 요청 후에 진행되는 상황 또한 같은 세션의 대화 패널에서 확인할 수 있습니다.

Kiro가 설계해준 디자인을 확인해봅니다. 적절한 속성을 만들어 주었습니다.

앞서 만들어진 디자인을 기반으로 task에서 단계별로 구현이 됩니다. 이때 사용자가 입력한 속성을 만족하기 위해 여러번의 시행을 거칩니다.

직접 실행 해본 결과, 기존 유닛 테스트와 Kiro의 PBT와의 차이는 아래 예시와 같습니다.

• 기존 유닛 테스트: “1,000원에서 500원을 인출하면 500원이 남는지 확인” (특정 값 검증)
• Kiro의 PBT: ” ‘임의의(Any)’ 잔액과 인출액에 대해, [인출 후 잔액 = 인출 전 잔액 – 인출액]이라는 규칙이 항상 성립하는지 확인” (수백 개의 무작위 케이스 자동 검증)

추가적으로 프로젝트에서 작업할 때 일관된 가이드라인 혹은 가드레일과 컨텍스트를 제공는 steering도 Kiro IDE의 대화 패널에서 생성 및 적용 가능합니다. 

3.2 Kiro Checkpoint: 작업 상태 저장과 복원

코드 복구를 넘어, ‘맥락(Context)’을 되감는 타임머신

AI기반의 코딩툴을 사용하신 누구나 한 번쯤 겪어봤을 상황입니다. AI 에이전트와 순조롭게 기능을 구현하며 파일을 수정하고 리팩토링하던 중, 갑자기 엉뚱한 방향으로 코드가 변경되는 순간이 있습니다. 

이때 진짜 문제는 꼬여버린 코드와 더불어 ‘대화의 맥락’을 찾기위해 Checkpoint-Restore를 클릭해주면 돌아갈 수 있습니다. 언제든 ‘Restore(복원)’ 버튼을 누르면, 에이전트가 변경한 모든 파일은 물론 대화 히스토리까지 해당 시점으로 완벽하게 돌아갑니다. 이러한 Kiro의 체크포인트 시스템은 사용자가 따로 설정하지 않아도 언제든지 사용할 수 있습니다.

다만 실수로 생성된 파일이 비가역적(Irreversible)으로 지워질수있기때문에 조심해야합니다.

3.3 Kiro CLI: 터미널로 들어온 에이전트

터미널에서도 KIRO의 모든것을

이제 Kiro의 강력한 AI 에이전트를 IDE뿐만아니라 터미널에서 이용할 수 있습니다. Kiro CLI는 IDE와 비슷한 환경(Steering files, MCP 설정)을 제공하여, 터미널 창 안에서도 기능 구현부터 버그 추적, 워크플로우 자동화까지 끊김 없는 인터랙티브 루프를 만들수 있습니다.

로컬 환경과 클라우드를 잇는 강력한 연동

Kiro CLI는 단순한 채팅 봇이 아닙니다. 로컬 터미널의 권한을 활용하여 실제 작업을 수행합니다. 특히 AWS aws-login이나 로컬 자격 증명(Credentials)을 통해 에이전트가 사용자의 클라우드 리소스에 직접 접근할 수 있다는 점은 강력한 무기입니다. 에이전트에게 “현재 AWS 배포 상태를 체크해줘”라고 명령하거나, 클라우드 리소스를 조회하고 관리하는 인프라 작업을 터미널에서 즉시 수행할 수 있습니다.

특정 업무에 최적화된 ‘Custom Agents’

Kiro CLI에서는 범용적인 AI 대신, 내 프로젝트에 딱 맞는 Custom Agents 기능을 통해 특정 작업에 특화된 에이전트를 지원합니다. macOS 및 Linux를 지원하며, 기존 Kiro IDE 구독 계정과 크레딧이 완벽하게 공유됩니다.

만약 SA입장에서 혹은 Infra 담당자 입장에서 보고싶은 관점이 있을 겁니다. 이때마다 항상 프롬프트에 ‘난 SA야 ….(중략) ….’와 같은 프롬프트를 매번 넣는 것은 비효율적이며, 상관없는 MCP tool 호출이 된다면 비교적으로 느린 답변 속도와 원하지 않는 결과까지 나올 수 있습니다.

이와 같은 상황을, agent를 미리 정의하여 해결할 수 있습니다. 간단히 kiro-cli 명령문을 통한 Kiro 실행 후, 왼쪽 이미지의 명령문을 입력하면 agent 생성 과정을 시작할 수 있습니다.

이후에 아래와 같이 접속 하기 위한 agent name과 agent에 대한 설명부터 사전에 정의된 MCP까지 순서대로 정보를 입력해주면 빠르게 Task별로 custom-agent 설정이 가능합니다.

최종적으로 아래와 같이 생성 및 저장이 완료되었다는 문구가 화면에 나타나면, 해당 파일은 ~/.kiro/agents/AWS_AI_Engineer(지정에이전트명)에서 확인할 수 있습니다.

앞서 작성한 agent description를 기반하여 자동으로 아래와 같이 적절한 system prompt도 만들어줍니다.

Custom Agent 생성시 설정한 AgentScope에 따라 아래와 같은 경로에서 확인할 수 있습니다.
Project(Local) 경로는 현재 워킹 디렉토리 기반으로 생성되니 참고 부탁드립니다.

앞서 생성한 agent에 MCP를 추가해 주고 테스트를 해보니 Kiro CLI의 foundation 모델인 Claude 자체의 학습 데이터에 근거한 것이 아니라 호출된 툴이 산출한 외부 데이터로부터 답변을 내놓습니다.

직접 확인해보니 실제 re:invent 2025 세션 번호와 일치 합니다.

보여드린 예시 외에도 내가 관리하는 계정 혹은 나의 포지션에 적합한 에이전트를 만들면 업무에 적용한다면, 정말 큰 도움이 될 거로 생각합니다.

3.4 엔터프라이즈 팀 플랜: 조직을 위한 확장성과 제어

AWS IAM 기반의 중앙 관리

Kiro는 이제 개인 도구를 넘어 기업 표준 개발 환경으로 확장됩니다. 팀 플랜은 기존 Q developer와 동일하게 AWS IAM Identity Center(IIC)와 통합되어, 별도의 복잡한 회원가입 절차 없이 기존 조직 아이덴티티로 즉시 로그인이 가능합니다. 더불어 구독 관리도 IIC를 통해 진행되기 때문에, 불필요한 관리 포인트를 만들지 않을 수 있어 좋았습니다.

익숙한 AWS Management Console 내에서 팀원들의 접근 권한을 제어하고, 각 구성원의 역할에 맞춰 Pro, Pro+, Power 등의 구독 등급을 할당할 수 있습니다. 

또한 아래와 같이 기본 제공 대시보드에서 활성 사용자 및 플랫폼당 사용량을 한 눈으로 체크할 수 있습니다.

하지만 아직까진 대시보드에서 사용자 개인별로 크레딧 및 프롬프트 등을 확인할 수는 없었습니다. 대신, Kiro usage dashboard 사용량 대시보드 활성화를 통해 개발자가 서비스를 어떻게 사용하는지 지표를 지정된 S3에 CSV로 제공받을 수 있습니다. 이를 third party를 통한 시각화를 진행하여, 매월 이용 현황을 모니터링에 이용할 수 있습니다.

참고하면 좋을 사례를 공유 드립니다. [AWS Blog : 사람인의 Amazon Q Developer 도입기]

4. 마치며: 단순 바이브를 넘어, 에이전트의 미래로

이제 Kiro는 개인 개발자의 로컬 터미널부터 엔터프라이즈의 클라우드 환경까지, 모든 규모의 개발 조직이 사용할 수 있는 플랫폼으로 확장되었습니다. AWS 통합을 통한 엔터프라이즈급 관리 기능과 CLI의 유연성은 기업 및 클라우드 기반 인프라 환경에서의 초기 진입 장벽을 허물었습니다.

글 서두에서 언급했던 Kiro 담당자의 비전처럼, 내 의도를 완벽히 이해하고 실행해 주는 나만의 ‘자비스’와의 협업은 더 이상 먼 영화속의 이야기가 아닙니다. 여러분도 전체 개발 여정에서 Kiro와 함께 아이언맨이자 히어로가 되길 바랍니다.