05B. 코딩형 AI를 위한 4종 문서 생성 단계 (Specification Phase)

`ARCHITECTURE.md` 생성

ARCHITECTURE.md Generation

생성 대상

ARCHITECTURE.md

시스템 컴포넌트 구조, 모듈 간 관계, 데이터 흐름 및 라우팅 설계를 정의한 ARCHITECTURE.md 파일을 생성합니다.

🎯 프롬프트 목적

제품 명세를 실제로 동작하는 내부 기술 구조와 모듈 간 상호작용 체계로 변환합니다.

이 단계는 새로운 기능을 발굴하는 것이 아니라, 이미 정해진 기능 요구사항을 안정적으로 지원할 모듈 경계, 데이터 흐름, 불변 규칙(Invariants)을 설계하는 것이 목적입니다.

📦 생성 산출물

ARCHITECTURE.md

💡 사용 방법 & 대화 가이드

사전 준비: PRODUCT_SPEC.md 및 TECH_STACK.md 작성이 끝난 후 사용하세요.
모듈 경계 명확화: AI가 시스템 내 구성 요소의 책임, 입출력, 데이터 흐름을 추상적이지 않고 구체적으로 나누어 정리하도록 유도합니다.

🤖 AI 프롬프트 원문

아래 프롬프트를 복사하여 AI 대화창에 그대로 전달해 보세요.

Generate ARCHITECTURE.md.

Assume PRODUCT_SPEC.md and TECH_STACK.md already exist and are correct.

Read TECH_STACK.md only to avoid conflicts with it.
Do not restate, summarize, or reference any technology, version, folder rule, or convention from it.
ARCHITECTURE.md must remain valid even if TECH_STACK.md changes.

If PRODUCT_SPEC.md and TECH_STACK.md conflict, or if a required component
cannot be reconciled with the constraints in TECH_STACK.md, stop and report the conflict.
Do not resolve it silently.

Do not create any other document.

The purpose of ARCHITECTURE.md is to define:

How the product works internally.
How responsibilities are separated.
How information flows through the system.
Which invariants must always remain true.

Do not describe implementation technologies.

Do not describe tech stacks.

Do not describe programming languages.

Do not describe libraries.

Do not describe deployment.

Do not describe coding conventions.

Do not describe folder structure.

Architecture must remain technology-agnostic.

The document must include:

- Purpose
- Core Concepts
- System Flow
- Components
- Component Responsibilities
- Responsibility Boundaries
- Data Flow
- Architectural Rules
- Failure Boundaries
- Non-Goals
- Architectural Invariants
- Resolved Decisions

Every component must have:

- Responsibilities
- Inputs
- Outputs
- Explicit ownership boundaries

Identify:

- missing responsibilities
- conflicting responsibilities
- ambiguous flows

Resolve them before generating the document.

If a resolution requires interpreting PRODUCT_SPEC.md in a way
that is not explicitly stated there, ask before deciding.
Record every resolution you make in "Resolved Decisions"
(what was ambiguous, what you decided, why).

Non-Goals must contain only architectural non-goals
(structures or responsibilities this architecture deliberately does not provide).
Do not copy non-goals from PRODUCT_SPEC.md.

Prefer clear ownership over abstraction.

Optimize for implementation certainty.

The document is intended for AI implementation, not human documentation.