AI로 풀어보는 AI-DLC: Unit 해석 방법

본 기사의 위치 — 본 기사는 awslabs/aidlc-workflows 리포지토리의 규칙군을 소재로 하여, 필자가 AI를 활용해 읽어내고 정리한 해석입니다. AWS가 공식적으로 발표한 방법론이 아니며, 1차 자료의 번역이나 요약도 아닙니다.

시리즈 — 본 기사는 AI로 풀어보는 AI-DLC 시리즈의 일부입니다.

참조한 버전 — 2026년 5월 시점에서 공개되어 있는 v0.1.8 (2026년 4월 20일 릴리스)의 aidlc-rules/를 참조하고 있습니다. OSS 구현은 업데이트가 계속되고 있으므로, 최신 상태는 공식 리포지토리를 확인해 주시기 바랍니다.

1. 서론

AI-DLC의 워크플로우(Workflow)를 구동하다 보면, Unit이라는 단어를 몇 번이고 마주하게 됩니다. Inception 페이즈(Phase)의 Units Generation 스테이지에서 "Unit of Work"로서 등장하고, Construction 페이즈에 들어가면 "per-unit", "Per-Unit Loop", "{unit-name}"과 같은 형태로 곳곳에 나타나며, 마지막 Build and Test에서는 "Unit tests", "Build All Units"라는 별개의 문맥으로 다시 보게 됩니다.

같은 단어가 장면마다 다른 대상을 가리키는 경우도 있고, 관련 개념의 다른 측면을 강조하는 경우도 있습니다. 따라서 처음 접했을 때는 당혹스러울 수 있습니다. 하지만 용어가 혼란스러운 것이 아니라, 각 스테이지의 규칙이 다루는 관심 영역에 따라 Unit이 가리키는 대상도 변하는 것입니다. 본 기사에서는 각 스테이지의 규칙 기술로부터 Unit의 의미를 읽어내어, 독자가 문맥에 따라 적절한 의미를 선택할 수 있도록 정리합니다.

본 기사에서 사용하는 주요 용어

Unit: 본 기사의 주제. AI-DLC의 규칙 파일 내에서 "unit"이라고 표기되는 개발·설계·구현·검증의 단위
Unit of Work: Units Generation 스테이지에서 정의되는, 계획 페이즈 문맥에서의 Unit의 정식 호칭
Per-Unit Loop: Construction 페이즈에서 각 Unit이 설계부터 구현까지 한 바퀴 도는 반복 구조
per-unit 스테이지: Functional Design / NFR Requirements / NFR Design / Infrastructure Design / Code Generation과 같이 Unit별로 실행되는 구성 요소
{unit-name}: 규칙 본문 및 결과물 경로에 나타나는 플레이스홀더(Placeholder)로, 구체적인 Unit의 이름으로 대체됨

loaded rules: 각 스테이지에서 AI 에이전트가 실행 시에 읽어들이는 규칙 파일군 (aidlc-rules/aws-aidlc-rule-details/ 하위)
결과물: 각 스테이지가 생성하는 Markdown 파일군 (aidlc-docs/ 하위)

먼저 §2에서 Units Generation의 Unit of Work를 읽습니다. 다음으로 §3에서 Construction 페이즈의 반복과 {unit-name}을 차례로 따라갑니다. §4에서는 Build and Test에서 출처가 다른 두 계통의 Unit이 공존하는 장면을 구분하여 읽습니다. 여기까지의 3개 장은 각 스테이지에서 Unit이 어떻게 사용되는지를 순차적으로 따라가는 구성입니다. §5에서는 관점을 바꾸어, 스테이지를 종단하며 "규칙은 무엇을 정하고, 무엇을 사용자 요구사항에 맡기는가"를 정리합니다. 마지막으로 §6에서 문맥에 따른 구분 방법을 정리합니다.

2. Units Generation에서의 Unit: Unit of Work

Units Generation은 Inception 페이즈(계획 페이즈에 해당)의 후반부에 위치하는 스테이지로, Unit이라는 단어가 처음으로 정식 정의되는 곳입니다. 로드되는 inception/units-generation.md의 서두에 스테이지의 목적이 기재되어 있습니다.

This stage decomposes the system into manageable units of work through two integrated parts:

이 스테이지는 시스템을 관리 가능한 Unit of Work로 분해하는 것으로, 두 부분으로 구성된다

여기서 말하는 Unit은 개발을 진행하기 쉽도록 시스템을 분해한 결과물 중 하나하나의 덩어리입니다. 이어서 파일 전체에서 유일하게 "DEFINITION"이라고 명시된 정의가 나타납니다.

DEFINITION: 작업 단위 (Unit of work)란 개발 목적을 위해 스토리(stories)를 논리적으로 그룹화한 것입니다. 마이크로서비스 (microservices)의 경우, 각 단위는 독립적으로 배포 가능한 서비스 (service)가 됩니다. 모놀리스 (monoliths)의 경우, 단일 단위가 논리적 모듈 (logical modules)을 포함하는 애플리케이션 전체를 나타냅니다.

DEFINITION: Unit of Work란 개발 편의를 위해 스토리를 논리적으로 하나로 묶은 것입니다. 마이크로서비스를 채택한 경우, 각 Unit이 그대로 독립하여 배포 가능한 Service가 됩니다. 모놀리스를 채택한 경우, 단일 Unit이 애플리케이션 전체를 나타내며 그 내부에 논리적 모듈이 포함됩니다.

이 한 문장에는 Unit에 관한 두 가지 요점이 포함되어 있습니다.

첫째, Unit이란 '스토리의 논리적 그룹화 (logical grouping)'라는 점입니다. 요구사항이나 사용자 스토리 (User Stories) 단계에서 식별된 개별 스토리들이 Unit에 의해 하나로 묶입니다. 이는 기술적인 분해(코드의 모듈 구조 등)가 아니라, 어디까지나 개발을 진행하기 위한 논리적인 묶음입니다.

둘째, Unit과 Service의 관계는 아키텍처 (architecture)에 따라 달라집니다. 마이크로서비스를 채택한 경우에는 하나의 Unit이 독립적으로 배포 가능한 하나의 Service에 대응합니다. 모놀리스를 채택한 경우에는 단일 Unit이 애플리케이션 전체를 나타냅니다. 동일한 Unit이라는 용어가 아키텍처 선언에 따라 서로 다른 입도 (granularity)를 갖게 됩니다.

이 정의에 이어, Unit과 유사한 의미로 사용되는 'Unit of Work', 'unit', 'service', 'module' 중 계획 단계 (planning phase)의 문맥에서 어떤 호칭을 사용할지가 명시됩니다.

Terminology: 독립적으로 배포 가능한 구성 요소에는 "Service", Service 내의 논리적 그룹화에는 "Module", 계획 단계의 문맥에서는 "Unit of Work"를 사용합니다.

용어: 독립적으로 배포 가능한 구성 요소에는 "Service", Service 내의 논리적인 묶음에는 "Module", 계획 단계의 문맥에서는 "Unit of Work"를 사용한다.

여기서부터 계획 단계의 문맥에서 Unit의 호칭이 **"Unit of Work"**임을 알 수 있습니다. 배포 단위를 말할 때는 Service, Service 내의 논리적 그룹을 말할 때는 Module, 그리고 이제부터 설계·구현할 작업 단위로 말할 때는 Unit of Work라고 하는 세 가지 호칭의 구분 사용이 선언되어 있습니다.

실제로 Units Generation의 생성 결과물은 모두 "unit of work"라는 이름을 가진 파일군입니다.

Generate

aidlc-docs/inception/application-design/unit-of-work.md

Unit의 정의와 책임을 포함하여 생성

aidlc-docs/inception/application-design/unit-of-work-dependency.md

의존성 매트릭스 (dependency matrix)를 포함하여 생성

aidlc-docs/inception/application-design/unit-of-work-story-map.md

스토리를 Unit에 매핑하여 생성

「Unit의 정의」, 「Unit 간의 의존」, 「스토리에서 Unit으로의 매핑」이라는 세 가지 관점이 각각 별도의 문서로 분리되어 있습니다. 여기서 생성되는 unit-of-work.md가 후속 단계에서 Unit을 참조할 때의 기본 자료가 됩니다.

또한, 이 단계의 전제 조건에는 Application Design 단계가 필수 사항으로 언급되어 있습니다.

Application Design stage REQUIRED (determines components, methods, and services)

Application Design 단계는 필수(Component·Method·Service를 결정함)

Application Design에서 식별된 Component나 Service의 정보가, Units Generation에서 Unit의 경계를 나눌 때의 소재로서 참조되는 관계입니다. Unit은 처음부터 정의되는 것이 아니라, Component나 Service의 구조를 소재로 하여 "어디에서 선을 그어 개발 단위로 삼을 것인가"를 다시 결정하는 단계라고 해석할 수 있습니다.

Units Generation의 마지막에는 생성된 Unit 군이 후속 단계로 전달되는 것이 완료 조건으로 기재되어 있습니다.

Units verified and ready for per-unit design stages

Unit이 검증되어 per-unit 설계 단계의 준비가 완료됨

여기서 「per-unit design stages」라는 용어가 처음 등장합니다. Units Generation을 통과한 Unit이 다음으로는 per-unit이라는 단위로 반복되는 설계 단계로 보내진다는 흐름이 나타납니다.

3. Construction 페이즈에서의 Unit: 반복과 {unit-name}

Construction 페이즈에 진입하면, Unit은 다른 역할을 맡기 시작합니다. 계획 페이즈의 문맥에서 "스토리의 논리적 그룹"이라고 언급되었던 Unit이, 여기서는 설계와 구현을 반복하기 위한 단위로 모습을 바꿉니다. aws-aidlc-rules/core-workflow.md에는 페이즈 전체의 구조가 명시되어 있습니다.

Stages in CONSTRUCTION PHASE:

• Per-Unit Loop (executes for each unit):

• Functional Design (CONDITIONAL, per-unit)

• NFR Requirements (CONDITIONAL, per-unit)

• NFR Design (CONDITIONAL, per-unit)

• Infrastructure Design (CONDITIONAL, per-unit)

• Code Generation (ALWAYS, per-unit)

• Build and Test (ALWAYS - after all units complete)

Note: Each unit is completed fully (design + code) before moving to the next unit.

CONSTRUCTION 페이즈의 단계:

• Per-Unit Loop (각 Unit마다 실행):

• Functional Design (CONDITIONAL, per-unit)

• NFR Requirements (CONDITIONAL, per-unit)

• NFR Design (CONDITIONAL, per-unit)

• Infrastructure Design (CONDITIONAL, per-unit)

• Code Generation (ALWAYS, per-unit)

• Build and Test (ALWAYS - 모든 Unit 완료 후 실행)

참고: 각 Unit은 완전히 완료된(설계 + 코드) 후에 다음 Unit으로 넘어갑니다.

여기서의 Unit은 Inception에서 정의된 Unit of Work의 각 요소를 가리킵니다. 실체는 동일하지만, Construction 페이즈에서는 "설계→구현의 한 주기를 돌리는 대상"으로 취급됩니다. Per-Unit Loop라는 이름 자체가 Unit이 반복의 단위로서 기능하고 있음을 보여줍니다.

반복의 단위라는 점을 다른 각도에서 설명하는 것이 이어지는 본문의 지시 사항입니다.

Per-Unit Loop (각 Unit마다 실행)

각 작업 단위(Unit of Work)에 대해, 다음 스테이지를 순차적으로 실행합니다:

Per-Unit Loop 안에는 5개의 스테이지가 순서대로 나열되어 있습니다. Functional Design, NFR Requirements, NFR Design, Infrastructure Design, Code Generation입니다. 이것들은 시스템 전체가 아니라, 특정 Unit에 한정된 범위를 다룹니다.

로드되는 common/process-overview.md에는 워크플로(Workflow) 전체 흐름 속에서 각 스테이지가 per-unit으로서 다뤄지고 있음이 스테이지 설명의 형태로 나타나 있습니다.

Functional Design: Unit별 상세 비즈니스 로직 설계 (CONDITIONAL, per-unit)

NFR Requirements: NFR 결정 및 기술 스택(Tech Stack) 선택 (CONDITIONAL, per-unit)

NFR Design: NFR 패턴 및 논리적 컴포넌트(Logical Components) 통합 (CONDITIONAL, per-unit)

Infrastructure Design: 실제 인프라 서비스로 매핑 (CONDITIONAL, per-unit)

Code Generation: Part 1 - Planning, Part 2 - Generation을 통한 코드 생성 (ALWAYS, per-unit)

5개의 스테이지 모두에 「per-unit」 태그가 붙어 있습니다. 여기서 Unit은 각 스테이지의 실행 범위(Scope)를 정하는 틀로서 작동합니다. Functional Design은 「이 Unit의 비즈니스 로직」을 다루고, NFR Design은 「이 Unit의 비기능 설계」를 다루며, Code Generation은 「이 Unit의 코드」를 생성합니다. 각 스테이지의 관심 영역은 Unit이라는 틀로 구분되어 다뤄집니다.

{unit-name}이라는 물리 디렉토리

Per-Unit Loop가 반복 구조라면, {unit-name}이라는 플레이스홀더(Placeholder)는 Unit을 물리적인 장소로 실체화하는 메커니즘입니다. per-unit 스테이지의 규칙을 차례로 살펴보면, 모두 {unit-name}을 포함하는 출력 경로를 가지고 있습니다.

Functional Design에서는 Unit을 식별한 후, 해당 Unit 전용 디렉토리에 결과물을 작성합니다.

Step 1: Analyze Unit Context

• aidlc-docs/inception/application-design/unit-of-work.md에서 Unit 정의를 읽습니다.

• aidlc-docs/inception/application-design/unit-of-work-story-map.md에서 할당된 스토리(Stories)를 읽습니다.

• Unit의 책임과 경계 이해하기

Step 1: Unit의 컨텍스트를 분석하기

aidlc-docs/inception/application-design/unit-of-work.md에서 Unit 정의를 읽어옵니다.

aidlc-docs/inception/application-design/unit-of-work-story-map.md에서 할당된 스토리(Stories)를 읽어옵니다.

• Unit의 책임과 경계 이해하기

Create

aidlc-docs/construction/{unit-name}/functional-design/business-logic-model.md

Create

aidlc-docs/construction/{unit-name}/functional-design/business-rules.md

Create

aidlc-docs/construction/{unit-name}/functional-design/domain-entities.md

Unit에 frontend/UI가 포함되는 경우: Create

aidlc-docs/construction/{unit-name}/functional-design/frontend-components.md

aidlc-docs/construction/{unit-name}/functional-design/business-logic-model.md를 생성합니다.

aidlc-docs/construction/{unit-name}/functional-design/business-rules.md를 생성합니다.

aidlc-docs/construction/{unit-name}/functional-design/domain-entities.md를 생성합니다.

Unit에 frontend / UI가 포함되는 경우:

aidlc-docs/construction/{unit-name}/functional-design/frontend-components.md를 생성합니다.

동일한 패턴이 NFR Requirements, NFR Design, Infrastructure Design, Code Generation에서도 반복됩니다. 각 스테이지(Stage)의 규칙이 지정하는 출력 경로(Output Path)는 모두 aidlc-docs/construction/{unit-name}/...를 기점으로 합니다.

스테이지	출력 경로 예시
Functional Design	aidlc-docs/construction/{unit-name}/functional-design/business-logic-model.md
...

Code Generation에서는 계획 파일명에도 {unit-name}이 삽입되어 있으며, Unit이 산출물의 경로뿐만 아니라 계획 단계의 파일 명명(Naming)까지 규정하고 있음을 알 수 있습니다.

여기서 Unit은 문서를 나열하는 물리적인 디렉토리(Directory) 이름 및 파일 이름의 일부로 나타납니다. {unit-name}의 내용은 Inception의 unit-of-work.md에서 정의된 Unit 명으로 대체됩니다. Inception에서 논리적으로 정의된 Unit은 Construction에서 aidlc-docs/construction/ 하위의 폴더 계층으로서 실체화되어 갑니다.

§2에서 본 「Unit of Work」와 본 절의 「Per-Unit Loop의 Unit」이 동일한 실체를 기점으로 하고 있다는 점은, functional-design.md의 Step 1 (Read unit definition from ...unit-of-work.md)을 통해 뒷받침됩니다. 계획 단계에서는 논리적인 덩어리로 이야기되었던 대상이, 실행 단계에서는 반복의 단위나 디렉토리의 기점으로 이야기되고 있을 뿐입니다.

4. Build and Test에서의 Unit: 두 가지 읽기가 나란히 놓이는 장소

Construction フェーズ의 마지막에 위치하는 Build and Test에서는 Unit이라는 단어의 사용법이 조금 달라집니다. 지금까지 살펴본 Unit of Work에 더해, 소프트웨어 테스트에서 친숙한 「unit tests (단위 테스트)」라는 별개의 계통의 Unit이 등장합니다. 빌드 대상으로서의 Unit of Work와 코드 입도(granularity)의 테스트 대상으로서의 Unit이 동일한 스테이지에 공존하는 것입니다.

먼저 스테이지의 목적에 두 가지 Unit이 한 줄에 공존하고 있습니다.

Purpose: Build all units and execute comprehensive testing strategy

목적: 모든 Unit을 빌드하고, 포괄적인 테스트 전략을 실행한다

「Build all units」라고 적힌 이 Unit은 Inception에서 정의된 Unit of Work의 각 요소를 가리킵니다. 이어서 테스트 전략의 개요에도 또 다른 읽기 방식이 나타납니다.

Analyze the project to determine appropriate testing strategy:

Unit tests: Already generated per unit during code generation
Integration tests: Test interactions between units/services
Performance tests: Load, stress, and scalability testing
End-to-end tests: Complete user workflows
Contract tests: API contract validation between services
Security tests: Vulnerability scanning, penetration testing

프로젝트를 분석하여 적절한 테스트 전략을 판정한다:

Unit tests: Code Generation 과정 중 per unit으로 이미 생성됨
Integration tests: Unit / Service 간의 상호작용을 테스트함
Performance tests: 부하, 스트레스, 스케일러빌리티(scalability) 테스트
End-to-end tests: 완전한 사용자 워크플로우 테스트
Contract tests: Service 간 API 컨트랙트(contract) 검증
Security tests: 취약점 스캔, 침투 테스트

여기서 흥미로운 점은, Unit tests: Already generated per unit during code generation이라는 한 문장에 두 가지 서로 다른 Unit이 공존하고 있다는 것입니다.

문장의 전반부인 「Unit tests」는 소프트웨어 테스트 분류의 용어입니다. 함수나 클래스와 같은 「코드로서 보았을 때의 단위」에 대한 테스트를 가리킵니다. xUnit 계열 프레임워크 문화에서 유래한 용법으로, 여기서의 Unit은 구현상의 작은 코드 조각을 의미합니다.

문장 후반부인 「per unit during code generation」의 per unit은 본 기사에서 살펴본 Unit of Work의 Unit입니다. Code Generation 스테이지가 각 Unit of Work를 순차적으로 순회하는 과정에서, 해당 Unit에 속하는 코드와 함께 테스트가 생성되었다는 관계를 나타냅니다.

즉, 이 문장은 「외부에서 Unit of Work별로 Code Generation이 돌아가고, 그 내부에서 각 Unit tests가 생성된다」는 이중 구조를 한 줄로 압축하고 있습니다. 구조적으로는 다음과 같은 중첩(nesting) 형태입니다.

for each unit-of-work in units: # 외부: Unit of Work
  generate code for this unit
  generate unit tests for this unit # 내부: 코드 입도의 unit

이를 해석할 때는 어떤 Unit이 화제가 되고 있는지를 장면마다 전환하며 파악해야 합니다.

unit-test-instructions.md의 생성 절차를 보면, 이 Unit은 테스트 입도 쪽에 가깝습니다.

Step 3: Generate Unit Test Execution Instructions

Create

aidlc-docs/construction/build-and-test/unit-test-instructions.md

# Unit Test 실행 ## Unit Test 실행 ### 1. 모든 Unit Test 실행 ```bash [모든 Unit Test를 실행하는 명령] # 예: mvn test, npm test, pytest tests/unit

Step 3: Unit 테스트 실행 절차를 생성한다

...
```bash [모든 Unit Test를 실행하는 명령] # 예: mvn test, npm test, pytest tests/unit`

mvn test

또는 npm test

와 같은 명령 예시에서 알 수 있듯이, 여기서의 Unit은 메서드(Method)나 클래스(Class), 함수(Function)와 같은 코드상의 작은 단위를 가리킵니다. 테스트 러너(Test runner)가 "unit"이라고 부르는 단위입니다. Unit of Work과는 입도(Granularity)와 성격이 다른 별개의 것입니다.

반면, Integration tests(통합 테스트)에 대한 설명에서는 Unit of Work의 Unit이 명확하게 나타납니다.

Test interactions between units/services to ensure they work together correctly.

Unit / Service 간의 상호작용을 테스트하여 이들이 올바르게 협력하는지 확인한다.

여기서의 "units"는 Inception에서 식별된 Unit of Work의 요소를 가리킵니다. Unit 간의 연계를 검증하는 것이 Integration tests의 역할이며, 이는 Unit 내부의 작은 단위를 다루는 Unit tests와는 레이어(Layer)가 다릅니다.

빌드(Build) 측면에서도 Unit of Work의 Unit이 등장합니다.