Correctness
자연어 요구사항에서 자동으로 추출한 Property-based test로, AI가 만든 구현이 실제 명세와 일치하는지 검증합니다.
왜 Property-based testing인가
AI가 코드를 빠르게 만들어 내는 시대에 가장 중요한 질문은 "이 구현이 정말 명세대로 동작하는가"입니다. 예시 기반 단위 테스트는 작성자의 직관이 미친 범위만 검증할 수 있다는 한계가 있습니다. Kiro의 Property-based testing(PBT)은 특정 예시가 아니라 시스템이 항상 만족해야 하는 보편적 성질(property)을 다양한 입력 조합으로 자동 검증합니다. 이 과정은 자연어 명세를 실행 가능한 속성으로 바꾸어, 요구사항과 검증 테스트 사이의 추적성도 유지해 줍니다.
Property란 무엇인가
Property는 "시스템이 어떻게 동작해야 하는지"에 대한 보편적 진술이며, 항상 참이어야 하는 불변식(invariant)이나 계약(contract)을 표현합니다. 일반적인 형태는 다음과 같습니다.
전제 조건을 만족하는 임의의 입력에 대해, 기대하는 결과가 성립합니다.
이는 EARS 형식의 요구사항과 자연스럽게 매핑됩니다. 예를 들어 "인증된 사용자라면 누구든지 활성 상태의 매물을 조회할 수 있어야 한다" 같은 규칙을 그대로 property로 옮길 수 있습니다.
예시 기반 테스트와의 차이
중고차 매물 앱을 예로 들면:
- 전통적 단위 테스트: 특정 사용자 A가 Car #5를 즐겨찾기에 추가하면, 즐겨찾기 목록에 Car #5가 보인다.
- Property-based test: "For any user and any car, WHEN the user adds the car to favorites, THE System SHALL display it in their list."
PBT는 이 한 줄의 진술을 수백~수천 가지 사용자/매물 조합으로 자동 실행하여, 이름에 특수문자가 들어가거나 매물 상태가 비정상인 경우 같은 엣지 케이스를 발견합니다. 위반 사례가 잡히면 Kiro는 입력을 단순화하는 shrinking 기법으로 가장 작은 반례를 찾아 보여줍니다. 마치 레드팀이 코드를 무너뜨리려 시도하는 것과 비슷한 방식입니다.
Spec 워크플로에 녹아든 PBT
Kiro는 요구사항 수집 단계부터 구현 검증까지 전 과정에 PBT를 자연스럽게 끼워 넣습니다. EARS 형식 요구사항에서 논리적으로 테스트 가능한 속성을 추출하고, 필요할 때 다량의 무작위 테스트 케이스를 즉석에서 생성합니다.
Design 단계
설계 시점에 Kiro가 요구사항을 분석해 검증 가능한 property를 식별하고, 그에 대응하는 테스트 케이스를 만들어 둡니다. 추출된 항목 위에 마우스를 올리면 출처가 된 원본 요구사항과 연결된 task로 바로 이동할 수 있습니다.
Task 실행 단계
- 구현 task를 실행하면 Kiro가 생성된 PBT 케이스들을 코드에 대해 돌립니다.
- 실행 후에는 어떤 코드가 만들어졌는지 reference를 통해 즉시 확인할 수 있습니다.
- 실패가 발생하면 Kiro가 깨진 시나리오를 식별해 검토 대상으로 표시합니다.
실패 분석과 후속 조치
실패가 발생하면 Kiro와 대화하면서 원인을 좁혀 갈 수 있습니다. 보통 세 가지 갈래의 선택지가 주어집니다.
- 구현이 잘못되었다면 코드를 수정합니다.
- property 자체가 부정확하다면 테스트를 다듬습니다.
- 요구사항 자체가 모호하거나 누락된 조건이 있다면 spec을 보강합니다.
