Kiro: 소프트웨어 요구사항 표기법 - EARS

 

 

개요

AWS에서 Kiro AI IDE를 내어 놓았다.

Kiro는 만들고자 하는 제품이나 기능에 대해 프롬프트만 넣으면 유저 스토리(user story)들을 만들어 주는데, 각각의 유저 스토리는 EARS(Easy Approach to Requirements Syntax) 형식의 엣지 케이스를 포함한 수용기준을 담고 있다. 웹페이지 본문의 소개는 다음과 같다.

Kiro unpacks requirements from a single prompt—type "Add a review system for products" and it generates user stories for viewing, creating, filtering, and rating reviews. Each user story includes EARS (Easy Approach to Requirements Syntax) notation acceptance criteria covering edge cases developers typically handle when building from basic user stories. This makes your prompt assumptions explicit, so you know Kiro is building what you want.

 

한글

Kiro는 하나의 프롬프트로부터 요구사항을 체계적으로 분해한다. 예를 들어 "상품에 리뷰 시스템을 추가해줘"라고 입력하면, Kiro는 리뷰를 조회, 작성, 필터링, 평가하는 사용자 스토리를 생성한다. 각 사용자 스토리에는 EARS(Easy Approach to Requirements Syntax) 형식의 엣지 케이스까지 포함한 수용 기준(acceptance criteria)이 포함되어 있어, 기본적인 사용자 스토리만 가지고 개발자가 직접 처리해야 하는 예외 상황들까지 자동으로 고려된다. 이를 통해 프롬프트에 담긴 암묵적인 가정들이 명시적으로 드러나기 때문에, Kiro가 사용자가 원하는 정확한 기능을 개발하고 있다는 확신을 가질 수 있다.

목표

EARS의 핵심 개념을 이해하고, Kiro에서 이를 어떻게 활용하는지 알아본다.

EARS 알아보기

EARS란 무엇인가?

EARS(Easy Approach to Requirements Syntax)를 한글로 풀어쓰면 “요구사항을 작성하는 쉬운 접근법” 정도가 되겠다. 경청한다는 뜻의 “All ears”도 연상되는데 고객의 요구사항을 잘 듣고 정리해야 한다는 의미도 담지 않았을까 싶다(뇌피셜)

엄격하게 정의해 보자면 EARS는 요구사항을 명확하고 이해하기 쉽게 작성하도록 구조화할 수 있도록 설계된 문장 형식이다. 복잡하고 모호한 요구사항을 표준화된 문장 형태로 변환하여 개발자와 기획자 모두에게 명확한 가이드라인을 제공한다.

EARS의 주요 문장 패턴

EARS는 총 6가지의 기본 문장 패턴을 제공하며, 요구사항이 어떤 조건과 상황에 적용되는지에 따라 선택적으로 사용할 수 있다.

유형 문장 템플릿 (영문) 한글 해석 (국문)

Ubiquitous (일반형)	The [system] shall [response]	[시스템]은 [행동]해야 한다.
Event-driven (사건 유발형)	When [trigger], the [system] shall [response]	[트리거]되면, [시스템]은 [행동]해야 한다.
State-driven (상태 기반형)	While [in state], the [system] shall [response]	[상태]인 동안, [시스템]은 [행동]해야 한다.
Optional (선택적 기능형)	Where [feature is installed], the [system] shall [response]	[기능이 활성화된 경우], [시스템]은 [행동]해야 한다.
Complex (복합형)	When [trigger], while [in state], the [system] shall [response]	[트리거]되면, [상태]인 동안 [시스템]은 [행동]해야 한다.
Unwanted (비정상 대응형)	If [undesired condition], then the [system] shall [response]	만약 [원하지 않는 상황]이면, [시스템]은 [대응]해야 한다.

EARS의 실질적 활용 예시 (전자레인지)

각 유형에 따른 실제 요구사항 예시를 통해 EARS를 쉽게 이해할 수 있다.

EARS 유형 요구사항 예시

Ubiquitous (일반형)	The microwave shall heat the food. 전자레인지는 음식을 데워야 한다.
Event-driven (사건 유발형)	When the door is closed, the microwave shall start heating. 문이 닫히면 전자레인지는 데우기를 시작해야 한다.
State-driven (상태 기반형)	While in preheat mode, the microwave shall display a warning. 예열 모드 중에는 전자레인지는 경고 메시지를 표시해야 한다.
Optional (선택적 기능형)	Where child lock is enabled, the microwave shall disable the start button. 차일드락 기능이 활성화된 경우 전자레인지는 시작 버튼을 비활성화해야 한다.
Complex (복합형)	When the door is opened, while heating, the microwave shall stop heating. 가열 중 문이 열리면 전자레인지는 가열을 멈춰야 한다.
Unwanted (비정상 대응형)	If overheating occurs, the microwave shall shut down and emit a beep. 과열이 발생하면 전자레인지는 동작을 중지하고 삐 소리를 내야 한다.

EARS를 사용하는 장점

• 모호한 표현을 최소화하고 요구사항을 명확히 표현할 수 있다.
• 요구사항의 누락 및 모순을 방지할 수 있다.
• 개발자와 기획자, 이해관계자 간 소통과 협업을 용이하게 한다.
• 자동화 도구 및 테스트 케이스 작성과의 연계가 용이하다.

Kiro 에서의 EARS

Kiro의 요구사항 문서에 대한 안내를 다시 보자. EARS는 수용 기준을 명시하는데 사용되며, 엣지 케이스까지도 EARS를 이용하여 명시한다. 이렇게 엣지 케이스까지 명시해줌으로써 AI에게 구현해야할 기능에 대한 명확한 그림을 보여주는 것이다.

Kiro는 하나의 프롬프트로부터 요구사항을 체계적으로 분해한다. 예를 들어 "상품에 리뷰 시스템을 추가해줘"라고 입력하면, Kiro는 리뷰를 조회, 작성, 필터링, 평가하는 사용자 스토리를 생성한다. 각 사용자 스토리에는 EARS(Easy Approach to Requirements Syntax) 형식의 엣지 케이스까지 포함한 수용 기준(acceptance criteria)이 포함되어 있어, 기본적인 사용자 스토리만 가지고 개발자가 직접 처리해야 하는 예외 상황들까지 자동으로 고려된다. 이를 통해 프롬프트에 담긴 암묵적인 가정들이 명시적으로 드러나기 때문에, Kiro가 사용자가 원하는 정확한 기능을 개발하고 있다는 확신을 가질 수 있다.

실제 생성 예시

다음은 실제로 Krio를 이용해 만든 requirements.md 문서의 앞부분이다. 실제로는 Requirement 7까지 만들어졌다. 수용기준(Acceptance Criteria)의 각 항목이 말하는 것은 AI가 만들어주는 기능이 다음을 만족해야 구현을 완료한 것으로 받아들이겠다는 것이다.

예시의 수용 기준을 보자.

• 버튼을 누르면 화면을 표시하고, 저장을 누르면 데이터베이스에 저장해야 한다는 기본적인 기능도 명시하지만
• 명언 텍스트가 비어있는데 저장하려 하면 오류메시지와 함께 저장을 거부해야 한다는 엣지 케이스도 명시한 것이다.

# Requirements Document

## Introduction

플러터로 개발되는 명언 관리 앱으로, 사용자가 명언을 추가, 수정, 삭제할 수 있으며, 정기적인 알림을 통해 명언을 제공하는 기능을 포함합니다. 사용자는 명언 목록을 탐색하고, 개별 명언 페이지에서 스와이프를 통해 다른 명언으로 이동할 수 있습니다.

## Requirements

### Requirement 1

**User Story:** 사용자로서, 새로운 명언을 추가할 수 있어야 하므로, 개인적으로 의미 있는 명언들을 수집할 수 있다.

#### Acceptance Criteria

1. WHEN 사용자가 명언 추가 버튼을 누르면 THEN 시스템은 명언 입력 화면을 표시해야 한다
2. WHEN 사용자가 명언 텍스트와 작가명을 입력하고 저장 버튼을 누르면 THEN 시스템은 새로운 명언을 데이터베이스에 저장해야 한다
3. IF 명언 텍스트가 비어있다면 THEN 시스템은 오류 메시지를 표시하고 저장을 거부해야 한다
4. WHEN 명언이 성공적으로 저장되면 THEN 시스템은 명언 목록 화면으로 돌아가야 한다

마무리

기존에는 task-master-ai 를 이용하거나 직접 프롬트르로 요구하여 PRD(Product Requirements Document)형식의 작성부터 해보았었는데 방법론적으로는 납득이 되면서도 실제 구현에서는 잘 작동하지 않는 경우가 많았다.

Kiro에서 제안하는 requirements.md → designs.md → tasks.md 순서로 생성한 파일들로 클로드 코드에게 플러터 앱 생성을 요청하여 한 번에 성공하였다. 프로세스가 제대로 작동한 데에는 requirements.md속의 EARS의 역할도 있었겠다 싶다. 인간에게 명확한 것은 AI에게도 명확하게 보일 것이다.