AWS Kiro Requirements Analysis: AI 코딩 전 스펙을 점검하는 방식

AI 코딩 도구의 경쟁이 “누가 더 빨리 코드를 쓰느냐”에 쏠려 있었다면, AWS Kiro의 이번 업데이트는 질문을 조금 바꾼다. AI가 코드를 쓰기 전에, 애초에 만들라고 지시한 요구사항이 서로 맞는가?

AWS가 Kiro에 추가한 핵심 기능은 Requirements Analysis다. 보도에 따르면 이 기능은 구현이 시작되기 전 소프트웨어 요구사항에 모순이나 빈틈이 있는지 확인하도록 설계됐다. 같은 업데이트에는 개발 흐름의 병목을 줄이기 위한 Parallel Task Execution과 Quick Plan도 포함됐다.

무엇이 새로 추가됐나

Requirements Analysis: 코드보다 먼저 스펙을 의심한다

Requirements Analysis는 이번 업데이트의 품질 관리 축에 가깝다. GeekWire는 AWS가 이 기능을 Kiro에 추가해, 코드가 작성되기 전에 소프트웨어 요구사항에 모순과 공백이 없는지 수학적으로 증명하려 한다고 전했다. SiliconAngle도 이를 “한 줄의 코드가 작성되기 전에” 문제를 잡기 위한 엔진으로 설명했다.

이 차이는 중요하다. AI 코딩 도구가 잘못된 요구사항을 그대로 받아들이면, 생성되는 코드와 테스트, 설계 결정까지 모두 같은 잘못된 전제를 확대할 수 있다. Requirements Analysis는 오류 탐지를 구현 이후가 아니라 요구사항 단계로 앞당기려는 시도다.

Parallel Task Execution: 실행 속도를 높이는 쪽

Parallel Task Execution은 같은 업데이트에 포함된 워크플로 개선 기능이다. SiliconAngle는 AWS가 Kiro에서 아키텍처 계획과 코드 실행 사이의 병목을 줄이려 하고 있으며, 개발자가 더 빠르게 움직일 수 있도록 Parallel Task Execution을 포함한 기능을 내놓고 있다고 보도했다.

다만 제공된 자료만으로는 Kiro 내부에서 작업 병렬화가 정확히 어떻게 스케줄링되는지까지 확인하기 어렵다. 따라서 이 기능은 정확성 검증 장치라기보다, 계획이 정리된 뒤 실행 속도를 높이는 개선으로 보는 편이 안전하다.

Quick Plan: 계획에서 실행까지의 진입 장벽 낮추기

Quick Plan 역시 Kiro 업데이트와 함께 언급된 간소화된 워크플로 기능이다. 목표는 개발자가 계획 단계에서 실행 단계로 더 빠르게 넘어가도록 돕는 것이다. Requirements Analysis가 “계획이 맞는가”를 보는 기능이라면, Quick Plan과 Parallel Task Execution은 “맞는 계획을 더 빨리 실행하는가”에 초점을 둔다고 정리할 수 있다.

Kiro가 원래 추구하던 방식: 명세 주도 개발

Kiro는 AWS가 설명하는 agentic coding service, 즉 개발자와 함께 작업하는 에이전트형 코딩 서비스다. AWS 문서는 Kiro가 프롬프트를 상세한 스펙으로 바꾸고, 다시 동작하는 코드·문서·테스트로 이어지게 한다고 설명한다.

Kiro의 스펙 문서도 같은 방향을 보여준다. Kiro에서 스펙은 기능 개발이나 버그 수정을 구조화하는 산출물이며, 높은 수준의 아이디어를 추적 가능하고 책임 소재가 분명한 구현 계획으로 바꾸는 역할을 한다.

이 스펙은 요구사항을 사용자 스토리와 수락 기준으로 나누고, 설계 문서를 만들며, 구현 진행 상황을 작업 단위로 추적하는 데 쓰인다. Kiro 제품 페이지는 자연어 프롬프트를 EARS 표기법의 요구사항과 수락 기준으로 변환해 개발자의 의도와 제약을 명시한다고 설명한다.

따라서 Requirements Analysis는 Kiro의 기존 방향과 잘 맞는다. Kiro는 이미 프롬프트와 코드 사이에 “명세”라는 층을 두고 있었고, 새 기능은 그 명세 자체가 서로 충돌하거나 비어 있지 않은지 확인하는 역할을 강화한다.

‘뉴로심볼릭’ 접근은 어디까지 확인됐나

현재 확인되는 설명은 고수준이다. AWS 문서에 따르면 Kiro는 Amazon Bedrock 위에 구축됐고, 여러 파운데이션 모델을 사용해 작업을 수행한다. GeekWire는 Requirements Analysis가 대규모 언어 모델과 추가 검증 장치를 결합한다고 보도했으며, 한 사용자 생성 기술 해설은 이를 뉴로심볼릭 AI—언어 모델의 자연어 처리 능력과 형식 논리의 검증 능력을 결합하는 방식—로 설명했다.

제공된 자료에 근거해 조심스럽게 정리하면 흐름은 다음과 같다.

1. 자연어 입력이 구조화된 요구사항이 된다. Kiro는 자연어 프롬프트를 스펙, 요구사항, 수락 기준으로 바꾸는 방식으로 출발한다.
2. EARS 표기법이 표현을 더 엄격하게 만든다. Kiro는 EARS 표기법을 사용해 의도와 제약을 명확하게 만든다고 설명한다. 느슨한 자연어를 더 일정한 요구사항 형식으로 바꾸는 데 도움이 되는 지점이다.
3. 형식 검증을 하려면 논리 제약으로 바꿔야 한다. 일반적인 형식 검증 구조에서는 구조화된 요구사항을 solver가 읽을 수 있는 표현으로 변환해야 한다. SMT-LIB는 SMT solver와 상호작용하기 위한 표준 언어로, 논리 제약 문제와 소프트웨어 추론에 쓰인다.
4. SMT solver는 충족 가능성을 검사한다. SMT solver는 SMT-LIB 벤치마크가 충족 가능한지, 또는 충족 불가능한지 판단할 수 있다. 이를 요구사항에 적용해 보면, 형식화된 제약 집합이 충족 불가능하다는 결과는 인코딩된 요구사항들이 동시에 참일 수 없다는 뜻이 된다.
5. 애매함 검출은 가장 덜 문서화된 부분이다. 제공된 자료는 Requirements Analysis가 모순과 빈틈을 잡으려는 기능이라는 점, 그리고 Kiro가 EARS 표기법을 쓴다는 점은 뒷받침한다. 하지만 AWS가 제품 문서에서 ‘semantic entropy’를 공식적인 모호성 신호로 사용한다고 단계별로 확인해 준 자료는 없다. 따라서 이 부분은 확정된 제품 사양이라기보다 보도·해설 또는 추론된 메커니즘으로 봐야 한다.

이 기능이 증명할 수 있는 것과 없는 것

중요한 한계가 있다. 형식 분석은 표현된 요구사항을 검사한다. 자연어 요구사항이 형식 제약으로 잘못 번역됐거나, 중요한 조건이 모델링에서 빠졌다면 solver의 결과가 실제 문제를 놓칠 수 있다.

모순 검사는 비교적 설명이 쉽다. 두 요구사항이 동시에 성립할 수 없도록 인코딩됐다면 제약 집합은 충족 불가능해질 수 있다.

반대로 불완전성, 즉 빠진 경우를 찾는 일은 더 까다롭다. 누락은 도메인, 가능한 상태, 반드시 다뤄야 하는 조건이 충분히 모델링돼 있어야 드러난다. 모호성도 마찬가지다. EARS 표기법은 의도와 제약을 명확히 하며 애매한 표현을 줄이는 데 도움을 줄 수 있지만, 제공된 근거만으로는 AWS가 모든 모호한 요구사항을 공식적으로 검출한다고 말할 수 없다.

개발자 워크플로는 어떻게 달라지나

실무 관점에서 가장 큰 변화는 작업이 더 앞단으로 몰린다는 점이다. Kiro는 AI 에이전트에게 곧장 코드를 쓰게 하기보다, 요구사항·수락 기준·설계·작업 목록을 먼저 정리한 뒤 코드로 넘어가는 흐름을 강조한다.

Requirements Analysis는 이 앞단에 검증 단계를 추가한다. Parallel Task Execution과 Quick Plan은 계획이 마련된 뒤 실행으로 넘어가는 과정을 빠르게 만드는 쪽에 가깝다.

즉 AWS가 Kiro에서 밀고 있는 방향은 “더 빨리 코드 생성”만이 아니다. 먼저 스펙이 일관적인지 확인하고, 그다음 구현 단계를 덜 막히게 하려는 조합이다.

확인된 사실과 아직 불분명한 부분

확인된 부분은 비교적 명확하다. Kiro는 명세 주도형 에이전트 코딩 서비스이고, 프롬프트를 스펙과 구현 산출물로 이어지게 하며, 요구사항과 수락 기준에 EARS 표기법을 사용한다. 이번 업데이트에는 Requirements Analysis, Parallel Task Execution, Quick Plan이 포함됐다.

아직 불분명한 부분은 Requirements Analysis의 정확한 내부 구조다. 제공된 자료는 뉴로심볼릭 접근과 형식 추론이라는 큰 방향은 뒷받침하지만, LLM, EARS 표기법, SMT-LIB 형식화, semantic entropy, 특정 SMT solver 구현이 AWS 내부에서 어떤 순서와 방식으로 묶이는지를 공식 기술 사양 수준으로 설명하지는 않는다.

따라서 현재로서는 Requirements Analysis를 “요구사항을 코드 생성 전에 검증하려는 형식 추론 지향 기능”으로 이해하는 것이 가장 안전하다. 구체적인 내부 메커니즘은 AWS가 더 상세한 문서를 공개하기 전까지는 일부만 확인된 상태다.