AI로 풀어보는 AI-DLC: Component를 이해하는 방법

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

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

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

1. 서론

AI-DLC의 워크플로우를 실행하다 보면, Component라는 동일한 용어가 여러 스테이지에서 서로 다른 것을 가리키고 있다는 사실을 깨닫게 됩니다. 규칙 파일에는 components.md, frontend-components.md, logical-components.md와 같이 「Component」라는 이름이 붙은 결과물이 여러 개 나열되어 있으며, 각각 별개의 관심 영역을 다루고 있습니다.

동일한 용어가 상황에 따라 다른 것을 가리키는 것 자체는 소프트웨어 개발 현장에서 드문 일이 아닙니다. 다만 AI-DLC에서는 규칙 파일에 적힌 지시 그 자체가 「Component」를 별개의 계통 카테고리로 나열하고 있기 때문에, 각 스테이지에서 무엇을 생성하고 있는지를 의식하지 않으면 혼란스러워지기 쉬운 구조로 되어 있습니다.

본 기사에서는 스테이지별로 Component가 어떻게 다뤄지는지를 loaded rules부터 차례대로 읽어 내려가겠습니다. Application Design, Functional Design, NFR Design, Infrastructure Design / Code Generation 순으로 각 스테이지를 확인하고 (§2~§5), 공통되는 구조를 §6에서 정리한 후, §7에서 독자가 현장에서 Component라는 용어를 만났을 때의 관점을 정리합니다.

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

• Component: 본 기사의 주제. AI-DLC의 규칙 파일 내에서 「component」라고 표기되는 설계 대상. 스테이지마다 무엇을 가리키는지가 다르며, 그 차이를 읽어내는 것이 본 기사의 목적입니다.
• Application Design의 Component: §2에서 다루는, 특정 책임을 가진 기능 단위. 본 기사에서는 이 호칭으로 통일합니다.
• frontend Component: §3에서 다루는, 화면을 구성하는 UI 부품 (props나 state를 가진 단위).
• logical Component: §4에서 다루는, 비기능 요구사항(NFR)으로부터 도출되는 논리적인 구성 요소 (큐, 캐시, 서킷 브레이커 등).
• loaded rules: 각 스테이지에서 AI 에이전트가 실행 시에 읽어들이는 규칙 파일군 (aidlc-rules/aws-aidlc-rule-details/ 하위).
• 결과물: 각 스테이지가 생성하는 Markdown 파일군 (aidlc-docs/ 하위).

참고로 본 기사에서는 Service라는 용어도 언급하지만, Component를 이해하는 데 필요한 범위로 한정합니다. Service의 취급 자체는 본 기사의 대상이 아닙니다.

2. Application Design에서의 Component

Component가 처음 등장하는 곳은 Inception 페이즈의 Application Design 스테이지입니다. inception/application-design.md의 서두에는 이 스테이지의 목적이 다음과 같이 적혀 있습니다.

High-level component identification and service layer design
고수준에서의 Component 식별 및 Service 계층 설계

Identifying main functional components and their responsibilities
주요 기능을 담당하는 Component와 그 책임을 식별

Defining component interfaces (not detailed business logic)
Component의 인터페이스를 정의 (상세한 비즈니스 로직이 아님)

여기서 Component는 특정한 책임을 가진 기능 단위로 위치 지어집니다. 클래스(Class)보다 크고 시스템 전체보다는 작은 중간 입도(medium-grained)의 덩어리라고 이미지화하면 이해하기 쉬울 것입니다.

스테이지의 실행 절차를 보면, Component에 대해 물어야 할 항목들이 나열되어 있습니다.

Component Identification- Ask about component boundaries, organization, and grouping strategies

Component Identification— Component의 경계, 구성, 그룹화(Grouping) 방침에 대해 질문한다

질문되고 있는 것은 "경계를 어디에 그을 것인가", "어떻게 구성하고 어떻게 그룹화할 것인가"라는 설계상의 판단입니다. 규칙은 이것들을 질문 항목으로 나열하는 형태를 취하고 있습니다.

최종적으로 이 스테이지에서 생성되는 components.md에는 다음 내용이 포함됩니다.

Create

aidlc-docs/inception/application-design/components.md

with:

• Component name and purpose
• Component responsibilities
• Component interfaces

다음 내용을 포함하여

aidlc-docs/inception/application-design/components.md를 작성한다:

• Component의 이름과 목적
• Component의 책무 (Responsibilities)
• Component의 인터페이스 (Interfaces)

components.md는 단독으로 존재하는 것이 아니라, services.md, component-methods.md, component-dependency.md와 같은 산출물과 세트로 생성됩니다 (Service 등 본 기사의 주제에서 벗어나는 부분은 다른 기회에 다루겠습니다).

Application Design 스테이지에서 Component가 다뤄질 때, 그것은 "책무·인터페이스·의존 관계를 가진 기능 단위"라는 것이 이 스테이지의 규칙이 정하고 있는 성질입니다.

상세한 비즈니스 로직은 Functional Design으로 넘겨지며, 거기서부터 다시 별도의 계통을 가진 Component가 등장합니다.

3. Functional Design에서의 frontend Component

Construction 페이즈에 진입하여 Functional Design 스테이지로 진행하면, frontend-components.md라는 새로운 산출물이 등장합니다.

If unit includes frontend/UI: Create

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

• Component hierarchy and structure
• Props and state definitions for each component
• User interaction flows
• Form validation rules
• API integration points (which backend endpoints each component uses)

유닛이 프론트엔드(Frontend)나 UI를 포함하는 경우,

aidlc-docs/construction/{unit-name}/functional-design/frontend-components.md를 작성한다.

• Component의 계층 구조 (Hierarchy)
• 각 Component의 Props와 State 정의
• 사용자 상호작용 (User interaction) 흐름
• 폼 검증 (Form validation) 규칙
• API 연동 포인트 (각 Component가 어떤 백엔드 엔드포인트(Endpoint)를 사용하는지)

여기서 다뤄지는 Component는 Props나 State를 가지며 화면의 일부를 구성하는 단위, 이른바 "UI 부품"의 의미입니다. React나 Vue와 같은 UI 프레임워크가 채택하고 있는 사고방식을 이미지화하면 이해하기 쉬울 것입니다. 계층 구조, Props, State, 사용자 상호작용 흐름 모두 UI 영역의 어휘입니다.

Application Design의 Component와 용어는 같지만, 다루는 대상이 다릅니다. Application Design의 Component가 기능 단위로서 책임(Responsibility)과 인터페이스(Interface)를 갖는 것에 반해, frontend Component는 화면을 구성하는 부품으로서 props와 state를 가지며, 사용자 조작과 API 호출을 연결합니다.

Application Design의 Component와 frontend Component가 공존함

여기서 한 가지 짚고 넘어가야 할 점이 있습니다. Functional Design 단계는 Application Design에서 정의된 Component(§2에서 본 기능 단위의 Component)의 상세한 비즈니스 로직을 기술하는 곳이기도 하므로, Application Design의 Component와 frontend Component가 모두 동일한 단계 안에 나란히 놓이게 됩니다. 같은 용어가 동일한 단계에서 두 가지 서로 다른 대상을 가리키는 구조입니다.

질문 항목 목록에도 frontend Component가 독립된 항목으로 등장합니다.

Frontend Components(if applicable) - Ask about UI component structure, user interactions, state management, and form handling

Frontend Components(해당하는 경우) — UI Component의 구조, 사용자 상호작용, 상태 관리(State Management), 폼 처리(Form Handling)에 대해 질문함

이 항목이 독립적으로 존재한다는 사실 자체에서, frontend Component를 Application Design의 Component와 병렬로 다루는 구조임을 알 수 있습니다.

4. NFR Design에서의 logical Component

Functional Design 다음에 오는 NFR Design에서는 또 다른 Component가 등장합니다. logical-components.md라는 결과물입니다.

Create

aidlc-docs/construction/{unit-name}/nfr-design/logical-components.md를 생성함

무엇이 기술되는지는 질문 항목 목록을 통해 알 수 있습니다.

Logical Components- Ask about infrastructure components (queues, caches, circuit breakers, etc.) and their integration patterns

Logical Components — 인프라 요소가 되는 Component(큐, 캐시, 서킷 브레이커 등)와 그 통합 패턴(Integration Patterns)에 대해 질문함

여기서 언급된 것은 큐, 캐시, 서킷 브레이커이며, 이들은 모두 비기능 요구사항(NFR: Scalability, Availability, Resilience)을 충족하기 위해 도입되는 논리적인 구성 요소입니다. Application Design의 기능 단위나 Functional Design의 UI 부품과는 또 다른 계통입니다.

NFR Design 단계의 목적은 다음과 같이 기술되어 있습니다.

Overview

Incorporate NFR requirements into unit design using patterns and logical components.

개요

비기능 요구사항(NFR)을 패턴과 논리 Component를 사용하여 유닛 설계에 통합함

'패턴'과 '논리 Component'가 나란히 언급되어 있는 것이 특징입니다. 규칙 내에서는 패턴으로서 Resilience / Scalability / Performance / Security의 네 가지가 언급되어 있으며(예를 들어 서킷 브레이커와 같은 결함 허용(Fault Tolerance) 패턴이 Resilience에 해당합니다), 이것들과 논리적인 구성 요소(큐, 캐시 등)가 이 단계에서 도입됩니다.

logical Component (논리적 구성 요소)는 Application Design (애플리케이션 설계)의 Component (구성 요소)와 용어는 같지만, 유래와 성격이 다릅니다. 기능 요구사항 (Functional Requirements)에서 도출되는 것이 아니라, 비기능 요구사항 (Non-functional Requirements)에서 도출되며, 시스템에 어떤 성질을 부여하고 싶은지(내결함성, 응답 성능, 확장 특성)에 따라 개수와 종류가 달라집니다.

5. Infrastructure Design / Code Generation에서의 Component

지금까지 Component의 세 가지 계통이 모두 나왔습니다: Application Design의 Component (기능 단위), Functional Design의 frontend Component (UI 부품), NFR Design의 logical Component (비기능 요소). Construction (구축)의 후반부로 진행하면, 이것들이 물리적 리소스 및 코드와 대응됩니다.

Infrastructure Design: 물리 리소스에 대한 매핑

Infrastructure Design (인프라 설계) 단계의 목적은 logical Component를 실제 인프라 선택지로 매핑하는 것입니다.

Overview

Map logical software components to actual infrastructure choices for deployment environments.

개요

논리적인 소프트웨어 Component를 데플로이 (Deployment, 배포) 환경을 위한 실제 인프라 선택지에 매핑한다.

여기서 "logical Component" (규칙 본문에서는 logical software components, 일본어 번역에서는 "논리적인 소프트웨어 Component"라고도 함)라는 표현이 나타내는 것은, Functional Design (기능 설계)이나 NFR Design (비기능 설계) 단계까지 설계된 Component가 아직 물리적인 실체를 갖지 않은 논리적인 존재라는 점입니다. Infrastructure Design에서는 이것들을 어떤 컴퓨팅 서비스, 어떤 스토리지, 어떤 메시징 기반 위에 올릴지를 결정해 나갑니다 (예를 들어 Lambda, ECS, EC2, 컨테이너와 같은 선택지 중에서 요구사항에 맞는 것을 고르는 이미지입니다).

여기서 다루어지는 Component의 단위는, 그때까지 설계된 것들을 물리적 리소스에 할당할 때의 단위로서 재해석됩니다. 할당 방식에는 여러 가지 패턴이 있을 수 있습니다.

• 하나의 기능 Component가 하나의 Lambda 함수가 된다
• 여러 개의 Component가 동일한 컨테이너에 공존한다
• logical Component (큐나 캐시 등)가 독립된 매니지드 서비스 (Managed Service)가 된다

논리에서 물리로의 대응 관계는 이 단계에서 처음으로 확정됩니다.

Code Generation: 코드로서의 실체화

Code Generation (코드 생성) 단계에서는 지금까지 설계된 Component가 구현 파일로서 구체화됩니다. 코드 생성 플랜 안에서 Component와 Service는 다른 유닛/서비스에 대한 의존성이나 경계/책임으로서 나란히 나타납니다.

Dependencies on other units/services

다른 유닛이나 Service에 대한 의존성

Service boundaries and responsibilities

Service의 경계와 책임

그 위에서, Component는 이 단계에서 처음으로 코드상의 파일 (클래스, 함수, 패키지, 모듈)로서 실체를 얻습니다. 구현 형식은 영역마다 다릅니다.

• 프론트엔드 측: React Component 또는 Vue Component
• 백엔드 측: 서비스 클래스 또는 리포지토리 (Repository) 클래스
• logical Component: SQS 큐나 Redis 캐시와 같은 인프라 정의

이러한 구현 단위로의 변환이 Code Generation 단계에서 이루어집니다. 구체적인 형식은 채택하는 언어, 프레임워크, 런타임 (Runtime)에 따라 달라집니다.

Code Generation 시점에서는, 그때까지의 단계에서 정해져 온 Component의 성질 (책임, UI 부품, 비기능 요소)이 각각의 영역에 적합한 구현 형식으로 변환되어 간다고 정리할 수 있습니다.

6. 각 단계에서의 Component 단위 확정

지금까지 Application Design, Functional Design, NFR Design, Infrastructure Design, Code Generation의 각 스테이지에서 Component가 무엇을 의미하는지 살펴보았습니다. 이를 나란히 놓고 보면, 규칙 파일(Rule file)이 정의하고 있는 것은 Component의 성질이나 역할이지, 구체적인 단위 그 자체는 아니다라는 점이 드러납니다.

Application Design의 components.md를 예로 들면, 규칙은 "Component란 특정 책임을 가진 기능 단위다", "이름과 목적, 책임, 인터페이스(Interface)를 작성하라"라고 지시하지만, "몇 개로 나누어라"라거나 "어디에 경계를 그어라"라고 쓰지는 않습니다. §2에서 보았듯이, 경계·구성·그룹화(Grouping)는 질문 항목으로 나열되어 있으며, 답은 사용자로부터 이끌어냅니다 (참조: application-design.md:49).

실행 플래닝(Execution planning) 규칙에서도 Application Design 스테이지를 실행할지 여부에 대한 판단은 사용자 측의 요구사항을 따르는 형태가 되어 있습니다.

New components or services needed

새로운 Component 또는 Service가 필요

Service layer design required

Service 계층(Layer) 설계 필요

새로운 Component나 Service가 필요한지, Service 계층의 설계가 필요한지 등의 판단은 대상 시스템의 요구사항에 의존합니다. 규칙이 Component를 몇 개 생성할지를 미리 결정해 주는 것이 아닙니다.

스테이지별로 규칙이 정하는 것과 단위를 확정 짓는 요구사항을 정리하면 다음과 같습니다.

스테이지	규칙이 정하는 것	단위를 확정 짓는 요구사항
Application Design	특정 책임을 가진 기능 단위라는 성질, 그리고 경계·구성·그룹화를 묻는 질문 항목	채택하는 도메인 모델(Domain model), 요구사항의 복잡성
...

각 스테이지의 규칙은 Component가 어떤 성질을 가져야 하는가를 제시합니다. 그 성질을 만족하는 구체적인 단위(경계, 개수, 구조)를 결정하는 것은 사용자가 가져오는 요구사항과 판단입니다.

이 구조는 규칙이 정답을 가지고 있지 않거나, 혹은 말하지 않고 있다는 뜻이 아닙니다. Component의 성질이나 역할을 제대로 정의한 뒤, 실제 단위는 요구사항에 따라 결정해야 할 사항으로 남겨두었다고 해석하는 것이 자연스럽습니다.

7. 마치며

Component라는 용어는 AI-DLC의 스테이지마다 서로 다른 관심 영역을 담당하고 있습니다. 용어가 서로 다른 것을 가리킨다기보다, 관심 영역에 따라 별도의 Component를 다루고 있다고 파악하는 것이 적절합니다.

실무적으로 가져갈 수 있는 두 가지 관점을 제시하며 마치겠습니다.

첫 번째는, "지금 나는 어느 스테이지의 어느 관심 영역을 다루고 있는가"를 기점으로 용어를 해석하는 습관입니다. components.md를 보고 있다면 기능 단위, frontend-components.md를 보고 있다면 UI 부품, logical-components.md를 보고 있다면 비기능 요소라는 식으로, 보고 있는 파일명이나 스테이지명이 큰 단서가 됩니다. Component라는 단어가 나왔을 때 반사적으로 어떤 의미인지 좁혀 나가는 것, 이 작은 노력이 팀의 오해를 줄여줍니다.

두 번째는, 규칙에 "단위 그 자체"를 물어도 답은 돌아오지 않는다는 점을 명심하는 것입니다. §6에서 보았듯이, 규칙은 Component의 성질이나 역할을 제시하는 데 그칩니다. "Component를 몇 개로 나누어야 하는가", "어디에 경계를 그어야 하는가"를 확정하는 것은 우리가 가져오는 요구사항과 판단입니다. 리뷰나 토론의 자리에서 규칙의 정의와 우리의 판단을 분리하여 다룰 수 있다면, 합의 형성이 원활해질 것입니다.

관련 기사

이전 기사: Service를 읽어내는 방법

다음 기사: 규칙의 원칙과 구조

목차: AI로 풀어보는 AI-DLC