A-ADM SERIES · CORE METHODOLOGY

AI-Driven Application
Development Methodology

어떤 AI 도구를 써도 동일한 품질과 추적성을 보장하는
도구 독립적 방법론 코어

5
설계 원칙
5
SDLC 단계
3
계약 파일
7
필수 스킬
Claude Code Cursor Copilot 도구 무관

전통 SDLC → AI-Driven 개발

핵심 차이는 하나입니다. 지식이 사람에게 귀속되는가, 계약 파일에 귀속되는가.

⚠ 전통 SDLC — 지식이 사람에게 귀속

요구사항 (문서)
  ↓ 개발자가 읽고 해석
설계 (UML, 위키)
  ↓ 개발자가 기억하며 구현
구현 (IDE)
  ↓ 개발자가 판단하여 테스트
테스트 (수동 매핑)

⚠ 단계 전환마다 해석/기억/판단 개입
⚠ 사람이 바뀌면 지식이 소실

✅ A-ADM — 지식이 계약 파일에 귀속

요구사항 (UC명세서 + .feature)
  ↓
domain-context.md [계약 1]
  ↓
arch-decisions.md [계약 2]
  ↓ AI가 파싱, 추론 없음
코드 스켈레톤 + 구현
  ↓
테스트 스위트 (Gherkin 1:1)

✅ 파일 기반 전환 — 해석 불필요
✅ 세션/사람 교체에도 동일 결과

5대 설계 원칙

A-ADM의 모든 결정은 다음 다섯 원칙에서 파생됩니다.

① PRINCIPLE

Lean over Comprehensive

스킬과 템플릿은 실제 스택과 사용 사례에 정확히 스코핑됩니다. 판단 기준: "이 규칙이 없으면 AI가 잘못된 결정을 내리는가?" — 그렇지 않으면 제거합니다.

② PRINCIPLE

Traceability as First Principle

UC Step N = 서비스 메서드 N = 테스트 케이스 N
Gherkin Scenario 1개 = @Test 1개
이 직접 매핑이 추론과 재작업을 원천 차단합니다.

③ PRINCIPLE

Contract-File Architecture

스킬들이 서로를 직접 호출하지 않고 명확한 형식의 계약 파일을 매개로 연결됩니다. 계약이 파이프라인의 신뢰성을 보장합니다.

④ PRINCIPLE

Convergence over Completeness

UC명세 스킬과 DDD 모델링 스킬은 병렬 실행 후 수렴 조건을 통과해야만 다음 단계로 진행합니다. 산출물 양보다 정합성이 기준입니다.

⑤ PRINCIPLE

Scale via Decomposition

대규모 프로젝트는 스킬을 복잡하게 만드는 대신, 1 프로젝트 ≈ 1~2 Bounded Context로 분해합니다. 멀티 BC는 bc-plan.md의 Wave 위상 정렬로 오케스트레이션합니다.

5단계 워크플로

각 단계는 명확한 입력 · 산출물 · 게이트를 가집니다.

1
요구사항 분석
입력: 도메인 설명 → 산출: UC명세서 + .feature + domain-context.md

두 스킬을 병렬로 실행한 뒤 수렴 게이트를 통과해야 합니다.

[스킬 A] UC명세 + SBE 시나리오  →  UC명세서.md, *.feature
[스킬 B] DDD 도메인 모델링      →  domain-context.md 초안

         ← 병렬 실행 →

수렴 게이트:
  UL 용어 ↔ Gherkin 용어 일치
  Aggregate 상태 ↔ Given/When/Then 정합
2
아키텍처 설계
입력: domain-context.md → 산출: arch-decisions.md
[스킬 C] 아키텍처 설계
         → arch-decisions.md
           (모듈 구조, BC 간 통신, 기술 스택, 공유 커널)

[스킬 D] 비기능 요구사항 명세 (선택)
         → arch-decisions.md의 ## NFR 섹션 보완

게이트

☐ 모든 BC가 arch-decisions.md에 포함 ☐ BC 간 통신 방식 확정 (동기 ACL / 비동기 Event)
3
스켈레톤 생성
입력: domain-context.md + arch-decisions.md → 산출: 코드 골격
[스킬 E] 추론 없는 1:1 매핑
         domain-context.md 식별자 → 코드 식별자 (변환 없음)
         레이어 구조: arch-decisions.md 준수

게이트

☐ 컴파일 통과 ☐ 모든 BC에 스켈레톤 존재
4
구현
입력: 스켈레톤 + 계약 파일 → 산출: BC별 구현 코드
[스킬 F] BC별 구현 — 레이어 순서 강제
         domain → application → adapter

규칙:
  BC 간 직접 의존 금지 (IoC 런타임 주입만 허용)
  OutputPort: 호출 BC의 application 레이어에 선언
  구현체: 구현 BC의 adapter 레이어에 위치
  bc-plan.md의 Wave 순서대로 구현
5
테스트
입력: *.feature + 구현 코드 → 산출: 테스트 스위트
[스킬 G] Gherkin 1:1 추적성 강제
         Gherkin Scenario 1개 = @Test 1개
         @Test 메서드명 = 시나리오 제목 (snake_case)
         주석 필수: // Scenario: UC01-S01

게이트

☐ 모든 시나리오에 @Test 존재 ☐ 전체 테스트 통과 ☐ 추적성 체인 검증 완료

계약 파일 체계

스킬들이 서로를 직접 호출하지 않고 계약 파일을 통해 연결됩니다.

파일생성 주체소비 주체수정 주체
UC명세서.mdUC명세 스킬SBE 스킬, DDD 스킬개발자
*.featureSBE 스킬DDD 스킬, 테스트 스킬개발자
domain-context.mdDDD 스킬arch-design, uc-to-skeleton개발자 (MAJOR 변경 시 재생성)
arch-decisions.mdarch-design 스킬implement-bc, uc-to-skeleton개발자
bc-plan.md개발자 직접 작성
(자동 생성 지원)
implement-bc, uc-to-skeleton개발자 (자동생성: implement-bc --check-plan)
erd.mmdgen-schema 스킬개발자 참조gen-schema --update (MAJOR/MINOR 변경 시)
schema.sqlgen-schema 스킬Flyway / Liquibase마이그레이션 파일로 분리 관리

계약 파일 스키마

어댑터는 이 스키마를 준수해야 합니다. 스키마 위반 시 다음 스킬이 중단합니다.

## Meta
schema-version: 2.0
content-version: 1.0.0          # MAJOR.MINOR.PATCH
generated-by: ddd-modeling
change-type: minor               # major | minor | patch
consumers:
  arch-design: "1.0.0"
  uc-to-skeleton: "1.0.0"

## Bounded Contexts
bounded-contexts:
  - name: Order
    responsibility: "주문 생성, 수정, 취소"
    type: core                   # core | supporting | generic

## Aggregates
aggregates:
  - name: Order
    bc: Order
    root: true
    invariants:
      - "총액은 0보다 커야 한다"
    states: [PENDING, CONFIRMED, CANCELLED]

## Commands
commands:
  - id: CMD-001
    name: PlaceOrder
    bc: Order
    aggregate: Order
    emits: [OrderPlaced]

## Events
events:
  - id: EVT-001
    name: OrderPlaced
    bc: Order
    payload: [orderId, customerId, totalAmount]

## Ubiquitous Language
ubiquitous-language:
  - term: "주문"
    en: "Order"
    definition: "고객이 상품 구매를 위해 생성하는 요청 단위"

## Context Map
context-map:
  - from: Order
    to: Notification
    integration: async-event     # sync-acl | async-event | shared-kernel
## Meta
schema-version: 1.0
content-version: 1.0.0
domain-context-version: "1.0.0"

## Stack
stack:
  language: java                  # java | go | typescript
  framework: spring-boot-3x
  build: maven

## Architecture Style
architecture:
  style: hexagonal
  layer-order: [domain, application, adapter]

## Modules
modules:
  - name: order-service
    bcs: [Order]
    type: service

## BC Communication
bc-communication:
  - from: Order
    to: Notification
    style: async-event
    technology: kafka

## Shared Kernel
shared-kernel:
  location: common-module
  contents: [Money, AuditInfo, DomainEvent]

## Persistence
persistence:
  command-side: jpa               # jpa | jdbc  — Aggregate 쓰기 전략
  query-side: jooq                # none | jooq — 복잡한 조인/집계 읽기 전략
                                  # none: JPA Projection 사용
                                  # jooq: schema.sql → codegen → DSL Query
  cqrs: true                      # query-side != none 이면 true
  migration: flyway               # flyway | liquibase | none
  databases:
    - bc: Order
      datasource: order_db
      tables:
        - name: orders
          aggregate: Order
          mapping: entity         # entity(JPA) | jdbc-row(JDBC)
        - name: order_items
          aggregate: OrderItem
          mapping: entity
    - bc: Catalog
      datasource: catalog_db
      tables:
        - name: products
          aggregate: Product
          mapping: entity
  shared-tables: []               # BC 간 공유 테이블 (원칙상 금지, 예외 명시용)
  erd: erd.mmd                    # Mermaid ERD 파일 경로 (선택)

## NFR (선택)
nfr:
  - id: NFR-001
    category: performance
    requirement: "주문 API p99 < 200ms"
    implementation: AUTO          # AUTO | TODO | MANUAL
## Meta
domain-context-version: "1.0.0"
arch-decisions-version: "1.0.0"

## Wave Plan
waves:
  - wave: 0
    bcs: [common-module, Catalog]
    reason: "외부 의존 없음"

  - wave: 1
    bcs: [Order]
    depends-on: [Catalog]
    communication: sync-acl

  - wave: 2
    bcs: [Notification]
    depends-on: [Order]
    communication: async-event
    trigger-event: OrderPlaced

## Cycle Check
cycle-detected: false

## Wave Gate Conditions
wave-gate:
  - compile-pass: true
  - port-binding: true
  - domain-test-pass: true
  - no-cycle: true
erDiagram
  %% A-ADM: arch-decisions.md ## Persistence 섹션을 기반으로 /gen-schema 스킬이 자동 생성
  %% schema-version: 1.0 | domain-context-version: "1.0.0"

  customers ||--o{ orders : places
  orders    ||--o{ order_items : contains
  products  ||--o{ order_items : included_in

  customers {
    uuid   id          PK
    string email       "UNIQUE NOT NULL"
    string name        "NOT NULL"
    string phone
    timestamptz created_at
  }

  orders {
    uuid        id          PK
    uuid        customer_id FK
    varchar20   status      "PENDING|CONFIRMED|CANCELLED"
    numeric12_2 total_amount
    timestamptz placed_at
  }

  order_items {
    uuid        id         PK
    uuid        order_id   FK
    uuid        product_id FK
    integer     quantity   "NOT NULL CHECK > 0"
    numeric12_2 unit_price
  }

  products {
    uuid        id    PK
    string      name  "NOT NULL"
    numeric12_2 price
    boolean     active
  }
사용 규칙
arch-decisions.md ## Persistence 작성 후 /gen-schema 실행
② 생성된 erd.mmd를 프로젝트 루트에 저장 — GitHub/GitLab에서 바로 렌더링됨
schema.sql은 Flyway/Liquibase 마이그레이션 파일로 분리 관리
④ domain model 변경(MAJOR/MINOR) 시 /gen-schema --update로 ERD 재생성

추적성 규칙

A-ADM의 핵심 품질 보증 메커니즘. 이 체인이 끊기면 AI 재작업이 발생합니다.

Level 1
UC → Feature
UC명세서의 기본 흐름 ID → *.feature 파일의 시나리오 태그
예: UC01 → @UC01 태그 필수
Level 2
Feature → Code
Gherkin 시나리오 제목 → 서비스 메서드명 (snake_case 변환)
Gherkin Step 순서 = 메서드 내부 로직 순서
Level 3
Feature → Test
Gherkin Scenario 1개 = @Test 메서드 1개
주석 필수: // Scenario: UC01-S01

멀티 BC 오케스트레이션

Wave 토폴로지로 BC 간 의존성을 관리합니다. DFS 사이클 감지 필수.

Wave 0
common-module Catalog 외부 의존 없음
Wave 1
Order ← Catalog (sync-acl)
Wave 2
Notification ← Order (async-event: OrderPlaced)
동기 ACL
  • 즉각적 일관성 필요 시
  • OutputPort: 호출 BC application 레이어
  • 구현체: 구현 BC adapter 레이어
  • BC 간 직접 의존 금지 (IoC 주입)
비동기 Domain Event
  • 결과적 일관성으로 충분 시
  • 발행 BC → Domain Event 발행
  • 수신 BC → ACL Translator로 변환
  • 느슨한 결합 보장

도메인 컨텍스트 버저닝

domain-context.md 변경이 어떤 산출물에 영향을 주는지 정확히 추적합니다.

변경 내용 유형 arch-design uc-to-skeleton implement-bc gen-test
BC 추가/삭제 MAJOR 전면 재실행 전체 BC bc-plan 재검토 전체 재생성
Aggregate Root 이름 변경 MAJOR 불필요 해당 BC 전체 domain 레이어 해당 BC 전체
Command/Event 추가 MINOR 불필요 해당 BC application application 레이어 해당 시나리오
VO 추가 MINOR 불필요 해당 BC domain domain 레이어 해당 시나리오
UL 문구 수정, 불변식 설명 PATCH 불필요 불필요 불필요 @DisplayName 패치
테이블/컬럼 추가 (신규 Aggregate 대응) MINOR 불필요 해당 BC adapter JpaEntity / JdbcRow 불필요
테이블 삭제 / FK 변경 (Aggregate 재설계) MAJOR Persistence 섹션 재작성 해당 BC 전체 adapter 레이어 전체 해당 BC 전체

도구 구현 어댑터 가이드

A-ADM 코어를 특정 AI 도구에 이식할 때 반드시 준수해야 할 계약입니다.

Claude Code SKILL.md × 7

  • 슬래시 커맨드로 스킬 트리거
  • CLAUDE.md에 고정 스택 선언
  • SKILL.md 오케스트레이터 패턴

Cursor .cursor/rules

  • *.mdc 파일로 규칙 정의
  • @파일 참조로 계약 파일 주입
  • 채팅 기반 스킬 호출

Copilot copilot-instructions.md

  • .github 디렉토리에 지시 파일
  • 자연어 요청으로 스킬 호출
  • 계약 파일 수동 첨부 필요

도구 무관 prompts/*.md

  • 마크다운 프롬프트 복사·붙여넣기
  • 어떤 LLM에도 적용 가능
  • 계약 파일 수동 관리

어댑터 A-ADM 호환 검증 체크리스트

domain-context.md 생성 시 schema-version: 2.0 준수
arch-decisions.md 생성 시 schema-version: 1.0 준수
스켈레톤 생성 시 domain-context.md 식별자를 변환 없이 그대로 사용
테스트 생성 시 Gherkin 시나리오와 1:1 대응 (@Test 메서드 1:1 매핑)
BC 구현 시 bc-plan.md의 Wave 순서 강제
BC 간 직접 의존 없음 (IoC 런타임 주입만 허용)