Kiro가 정식 출시된 지 8개월이 지난 지금, 오래 살아남은 아이디어는 스펙이었고, 가장 오래 살아남지 못한 부분은 IDE였다. Kiro는 에이전틱 IDE로 출시되었고, 그 세일즈 포인트는 명세 수준에서 작업하고 구현은 에이전트에게 맡긴다는 것이었다. 살아남은 부분은 그 아티팩트다. 코드가 존재하기 전에 사람이 검토하는, 글로 쓰인 의도 진술서 말이다. 조용히 진 부분은 이 일이 벌어지는 곳이 에디터라는 전제였다. Kiro는 GA와 함께 CLI를 출시했고, 헤드리스 모드를 추가했으며, 흥미로운 사용 사례들은 터미널로 옮겨갔다.

Kiro의 GA에 대해서는 작년 말 AWS Monthly (Dec '25): The Kiro Era Begins에서 거리를 두기보다는 열정이 앞선 채로 다룬 적이 있다. 8개월이면 그중 어느 부분이 유효했는지 말하기에 충분한 시간이다.

실제로 출시된 것

Kiro는 2025년 7월 프리뷰로 시작해 2025년 11월 17일 정식 출시(GA)에 도달했다. GA는 안정성 릴리스가 아니라 범위 릴리스였다. 스펙의 인수 기준에서 테스트 케이스를 도출하는 속성 기반 테스트, 에이전트의 변경 사항을 되돌릴 수 있는 체크포인팅, 멀티 루트 워크스페이스 지원, AWS IAM Identity Center를 통해 중앙에서 관리되는 팀 플랜, 그리고 에이전트를 터미널로 옮겨놓은 Kiro CLI.

그 이후로 궤적은 일관되고 화려하지 않았다. Kiro CLI는 2026년 4월에 헤드리스 모드를 추가했고, 그로써 에이전트가 사람 옆이 아니라 파이프라인 안에서 돌아가게 되었다. 2026년 1월의 CLI 릴리스는 에이전트가 가져올 수 있는 URL에 대한 허용 목록과 차단 목록, 커스텀 에이전트를 위한 키보드 단축키, 더 나은 diff에 관한 것이었다. 이것은 데모를 좇는 로드맵이 아니다. 도구가 프로덕션에 맞춰지고 있는 것이며, 그 맞춰지는 모양이 사람들이 실제로 이것으로 무엇을 하고 있는지를 말해준다.

스펙이 좋은 아이디어였다

Kiro의 진짜 기여는 명세를 파일로 만들었다는 것이다. 요구사항, 설계, 작업 항목이 저장소 안에서 버전 관리되고, 검토 가능하고, diff로 비교 가능해졌다. "AI가 당신의 코드를 작성한다"는 것 옆에 두면 사소해 보이지만, 이것이 내가 아무 조건 없이 옹호할 유일한 부분이다.

이유는 이것이 검토를 어디로 옮기는가에 있다. 통제되지 않은 에이전틱 코딩은 큰 diff를 만들어내고 사람에게 사후에 그것을 평가하라고 요구하는데, 이것은 최악의 시점이다. 작업은 이미 끝났고, 작성자는 자신의 추론을 기억하지 못하는 기계이며, 거부한다는 것은 완성되어 보이는 무언가를 버린다는 뜻이다. 스펙을 검토하는 것은 이것을 뒤집는다. 당신은 의도를 읽는 중이며, 그것을 바꾸는 비용이 문장 하나에 불과한 시점에 있다. "아니, 그런 식은 아니야"라는 말의 경제성은 구현 전과 후가 완전히 다르다.

이 속성은 AI와 아무 관련이 없으며, 바로 그렇기 때문에 살아남았다. 이것은 피드백 루프가 짧은 설계 검토일 뿐이며, 구현자가 에이전트든, 계약직 개발자든, 다음 주 화요일의 당신이든 똑같이 성립한다.

유효하지 않았던 부분

솔직한 실패 세 가지가 있고, 실제 업무에서 사용해본 사람이라면 누구에게나 초기부터 눈에 보였다.

스펙은 표류한다

요구사항과 설계는 초반에 생성되고, 구현 과정에서 설계가 틀렸다는 것이 드러나도 스스로 업데이트되지 않는다. 팀들은 정확히 예상 가능한 역학을 보고한다. 코드는 움직이고 스펙은 움직이지 않으며, 몇 주 안에 스펙은 더 이상 존재하지 않는 시스템을 묘사하는 문서가 되어버린다. 이것은 AI의 실패가 아니라 소프트웨어 문서화에서 가장 오래된 실패이며, 문서 작성은 저렴하게 만들고 유지보수는 조금도 저렴하게 만들지 못한 도구에 의해 다시 등장한 것뿐이다. 쓰기는 저렴하고 진실하게 유지하기는 비싼 것, 이 특정한 조합이 낡은 아티팩트를 만들어낸다.

오버헤드가 작은 작업에는 맞지 않는다

작은 버그 수정에 이것을 써본 사람들의 직설적인 표현을 빌리면, 스펙 워크플로는 견과류를 깨는 데 대형 망치를 쓰는 격이다. 검증 규칙 하나를 바꾸기 위해 요구사항, 설계, 작업 분해를 거치는 것은 그냥 검증 규칙을 바꾸는 것보다 못하다. 이 절차는 아무것에도 비례하지 않으며, 대부분의 엔지니어링 작업은 작다.

경직성은 진짜다

스펙 우선주의는 시작하기 전에 원하는 것을 알고 있다고 전제한다. 많은 소프트웨어는 사람들이 글을 쓰면서 자신이 무엇을 원하는지 알아가는 방식으로 만들어진다. 탐색적인 작업에서는 명세를 미리 앞당기는 것이 규율이 아니라, 얻지 못한 권위를 지금 갖게 된 문서로 굳어진 추측일 뿐이다. 스펙 중심 개발이 워터폴 역학을 다시 들여온다는 비판은 완전히 공정하지는 않지만 완전히 틀린 것도 아니며, 그 차이는 당신의 팀이 스펙을 계약서로 대하는지 초안으로 대하는지에 달려 있다.

그렇다면 누구를 위한 것인가

드러난 패턴은 세일즈 포인트보다 좁지만 더 방어 가능하다. 스펙은 요구사항이 모호할 때, 관련된 사람들이 공통된 이해를 전제할 수 없을 만큼 분산되어 있을 때, 또는 추적 가능성이 있으면 좋은 것이 아니라 의무일 때 그 오버헤드를 벌어들인다. 규제가 있는 맥락에서는 "여기 검토된 스펙이 있고, 여기 그것을 구현한 diff가 있다"는 오버헤드가 아니다. 어차피 만들어야 했을 감사 아티팩트가 부산물로 만들어지는 것이다.

잘 이해된 코드베이스에서 일하는 작은 팀에게는 이 오버헤드가 대체로 비용에 불과하다. 이것은 Kiro에 대한 비판이 아니다. 마케팅이 절대로 하지 않을 범위 설정 진술이다.

AI IDE가 실제로 바꾼 것

여기 회고적인 주장이 있고, 나는 이것을 느슨하게 붙잡고 있다.

바뀐 것은 AI가 코드를 작성한다는 사실이 아니다. 그것은 이미 일어났고, 정말로 유용하며, 이제는 그것을 두고 논쟁하는 것이 지루할 만큼 평범한 일이 되었다. 바뀐 것은 인간 검토의 단위가 상류로 이동했다는 것, diff에서 의도로 이동했다는 것이다. Kiro의 스펙은 하나의 구현체다. AGENTS.md와 스티어링 파일은 또 다른 구현체다. 패턴은 같다. 인간이 제약을 작성하고 의도를 검토하며, 에이전트가 구현을 만들어내고, 사람들이 논쟁하는 아티팩트는 더 이상 코드가 아니다.

두 번째 변화는 IDE가 올바른 컨테이너가 아니었다는 것으로 드러났다는 점이다. Kiro 자신의 CLI와 헤드리스 모드가 어떤 비평가보다도 이 지점을 잘 보여준다. 각 변경 사항이 반영될 때마다 사람이 그것을 읽지 않는다면, 에디터는 더 이상 UI가 필요하지 않은 무언가를 위한 UI인 것이고, 에이전트는 당신의 다른 자동화가 사는 곳에 속한다. IDE는 목적지가 아니라 진입로였다.

핵심 정리

GA 8개월 후, Kiro가 남긴 지속적인 기여는 검토 가능하고 버전 관리되는 파일로서의 명세이며, 이는 인간의 판단을 가장 저렴하게 적용할 수 있는 지점으로 옮겨놓았다. 비용은 실재하고 구체적이다. 스펙은 표류한다. 생성은 저렴하고 유지보수는 그렇지 않기 때문이다. 그리고 그 절차는 작거나 탐색적인 작업에는 맞지 않는다. 모호성이나 추적 가능성이 오버헤드를 정당화하는 곳에서는 사용하고, 그렇지 않은 곳에서는 건너뛰어라. 그리고 이 에이전틱 IDE에서 가장 유용했던 산출물이 CLI였다는 사실을 눈여겨보라. 이것이 업계가 이 흐름이 어디로 가는지 말해주는 방식이다.

다음으로 읽을 글

CI에서 에이전트를 실행하는 파이프라인 쪽, 즉 러너, 자격 증명, 폭발 반경은 ercan.cloud의 필드 노트에 있다. 허브는 ercanermis.com이다.