본문으로 건너뛰기

AIDLC Common Rules

📅 작성일: 2026-04-18 | ⏱️ 읽는 시간: 약 18분

AWS Labs AIDLC Workflows 의 aws-aidlc-rule-details/common/ 디렉터리는 모든 stage 가 공통으로 준수해야 하는 11개 규칙을 정의합니다. 이 규칙들은 Inception → Construction → Operations 전 단계에서 AI 에이전트와 사람이 협업하는 방식을 규정하며, 결과물의 재현성·감사 가능성·안전성을 담보합니다.

본 문서는 각 규칙을 "무엇(What) / 왜(Why) / 어떻게(How)" 3단 구조로 해설하고, 엔터프라이즈 환경에서의 적용 팁을 덧붙입니다.

1. 개요: 11개 Common Rules​

#규칙범주핵심 가치
1Question Format상호작용구조화된 질문·답변 포맷 강제
2Content Validation품질요구사항·응답 검증
3Error Handling품질예외 상황 표준 처리
4Overconfidence Prevention상호작용AI 확신도 제어
5Session Continuity거버넌스세션 간 컨텍스트 보존
6Workflow Changes상호작용워크플로 변경 명시적 승인
7Checkpoint Approval거버넌스Stage 전환 게이트
8Audit Logging거버넌스ISO 8601 타임스탬프 감사 로그
9No Duplication품질단일 진실 원천(SSOT)
10Methodology First품질도구 독립성
11Reproducible품질모델 간 결과 일관성
왜 Common Rules 가 중요한가

AIDLC 는 Kiro · Q Developer · Cursor · Cline · Claude Code · GitHub Copilot · AGENTS.md 7개 플랫폼에서 동일하게 동작해야 합니다. Common Rules 는 이 플랫폼·모델 차이에도 불구하고 같은 입력에 대해 같은 품질의 산출물을 보장하는 공통 계약입니다.

2. 규칙 1: Question Format​

무엇​

AI 에이전트가 사람에게 질문할 때 항상 A-E 5지선다 + [Answer]: 태그 포맷을 강제합니다.

왜​

  • 재현성: 자유 형식 답변은 모델별·세션별로 해석이 달라짐. 5지선다는 해석 모호성 제거
  • 속도: 사람이 긴 자유 응답을 작성할 필요 없음. 한 글자 선택으로 진행
  • 감사: 질문·답변 쌍이 구조화되어 감사 로그·재실행에 활용 가능

어떻게​

질문 템플릿:

Q1. Payment Service 의 인증 방식을 어떻게 설정하시겠습니까?

A. OAuth2 + JWT (Refresh Token 포함)
B. API Key (헤더 기반)
C. mTLS (서비스 간 인증)
D. AWS IAM + SigV4
E. Other (please specify)

[Answer]:

사람이 작성하는 응답:

[Answer]: A

또는 자유 기술이 필요한 경우:

[Answer]: E - Cognito User Pool + JWT (기존 조직 표준 준수)

엔터프라이즈 적용 팁​

  • 질문당 5개 이하 옵션 유지. 너무 많으면 의사결정 피로 유발
  • 옵션 D 는 "가장 일반적인 기본값", 옵션 E 는 "Other" 로 표준화
  • PR 본문·Slack 채널에 질문 블록을 복사해 팀 합의 후 [Answer]: 작성하는 패턴 권장

3. 규칙 2: Content Validation​

무엇​

AI 가 생성한 모든 산출물(Requirements Document, Design Document, Code 등)에 대해 자체 검증 체크리스트를 실행하고, 실패 항목이 있으면 사람에게 명시적으로 보고합니다.

왜​

  • AI 는 종종 누락·모순·hallucination 을 생성함
  • 사람이 모든 산출물을 전수 검토하기엔 시간 부족
  • AI 자체 검증을 1차 필터로 두면 사람 리뷰 부담 감소

어떻게​

자체 검증 체크리스트 예시 (Requirements Document):

## Content Validation Report

- [x] 모든 기능 요구사항에 Acceptance Criteria 포함
- [x] 비기능 요구사항(NFR)에 측정 가능한 지표 명시 (P99 latency, 가용성 등)
- [ ] **FAIL**: FR-004 의 에러 처리 경로가 명시되지 않음
- [x] 용어가 온톨로지/Ubiquitous Language 와 일치
- [x] 외부 의존성(DB, SQS 등) 명시
- [ ] **FAIL**: NFR-002 에서 "충분히 빠름" 이라는 모호한 표현 발견

**Failed Checks**: 2
**Action Required**: 사용자 확인 후 재작성 필요

엔터프라이즈 적용 팁​

  • 각 산출물 유형별 검증 체크리스트를 온톨로지 또는 조직 확장(extensions) 에 저장
  • CI 파이프라인에 aidlc-validate 단계 추가해 리포트를 PR 코멘트로 자동 게시
  • 실패 항목은 GitHub Issue 자동 생성 후 해결 전까지 Checkpoint Approval 차단

4. 규칙 3: Error Handling​

무엇​

AIDLC 실행 중 발생한 모든 예외(파일 누락, 도구 오류, 사용자 응답 없음 등)를 구조화된 에러 리포트로 기록하고, 재시도 또는 사용자 개입 여부를 명시적으로 결정합니다.

왜​

  • Silent failure 는 감사 추적을 불가능하게 만듦
  • 에러 발생 시점에 따라 자동 재시도 / 사용자 개입 / 세션 종료 중 적절한 대응 필요
  • 에러 패턴 분석으로 AIDLC 자체를 개선

어떻게​

에러 리포트 포맷:

error:
  id: ERR-2026-04-18-001
  timestamp: 2026-04-18T10:23:45Z
  stage: inception.requirements_analysis
  type: missing_context
  message: "Workspace Detection 결과가 세션에 없음"
  severity: medium
  recovery:
    auto_retry: false
    user_action_required: true
    suggested_fix: "Workspace Detection stage 를 먼저 실행하세요"
  context:
    session_id: sess-20260418-abc123
    prior_stage: workspace_detection

에러 분류:

Severity예시대응
Low옵션 응답 외 자유 기술AI 가 자동 해석 후 확인 질문
Medium필수 선행 stage 미실행사용자에게 stage 역순 실행 안내
High도구 호출 실패 (MCP 서버 다운 등)세션 일시 중지, 로그 수집
Critical온톨로지 계약 위반 (예: 허용되지 않은 도메인 용어 사용)즉시 중단, 사람 개입

엔터프라이즈 적용 팁​

  • 에러 리포트를 CloudWatch Logs Insights 로 전송해 패턴 분석
  • High/Critical 에러는 PagerDuty 연동
  • 월 1회 에러 리뷰 미팅으로 AIDLC 자체 개선

5. 규칙 4: Overconfidence Prevention​

무엇​

AI 응답에 확신도(confidence) 를 명시하고, 확신도가 낮은 경우 사용자에게 추가 컨텍스트를 요청하도록 강제합니다.

왜​

  • LLM 은 종종 잘못된 답을 매우 자신 있는 어조로 생성함 (hallucination)
  • 확신도 표기는 사용자가 어디를 집중 검토할지 판단하는 신호
  • 조직 내 AI 의사결정 신뢰 수준을 투명하게 관리

어떻게​

확신도 표기:

## 제안: Payment Service 인증 아키텍처

**Confidence**: High (90%)

Cognito User Pool + JWT 를 권장합니다. 이유는...

---

## 제안: DynamoDB 테이블 설계

**Confidence**: Medium (60%)
**Reason for lower confidence**: Payment 도메인의 읽기/쓰기 비율 정보가 없어 
GSI 설계가 최적이 아닐 수 있습니다.

**Additional Context Needed**:
- 일일 트랜잭션 수?
- 조회 패턴 (사용자별? 시간대별?)

[Answer]:

엔터프라이즈 적용 팁​

  • Low confidence (< 50%) 응답은 자동으로 Checkpoint Approval 게이트에서 일시 중지
  • Confidence 분포를 통계로 관리해 AI 개선 우선순위 식별
  • 금융·의료 등 규제 산업은 High confidence 만 자동 채택, Medium/Low 는 사람 승인 필수

6. 규칙 5: Session Continuity​

무엇​

AIDLC 세션이 중단·재개되더라도 이전 컨텍스트(질문·답변·산출물)를 완전히 복원할 수 있도록 상태를 영속화합니다.

왜​

  • 엔터프라이즈 프로젝트는 여러 날·여러 팀에 걸쳐 실행됨
  • 세션 종료 시 컨텍스트 유실 = 중복 질문 · 재작업 · 정보 손실
  • 팀원 간 핸드오프 시 "어디까지 했지?" 파악 가능해야 함

어떻게​

세션 상태 파일 (.aidlc/session.md):

# AIDLC Session State

**Session ID**: sess-20260418-payment-service
**Started**: 2026-04-17T09:00:00Z
**Last Active**: 2026-04-18T10:30:00Z
**Owner**: yjeong@example.com

## Progress

| Stage | Status | Artifacts | Approved By | Approved At |
|-------|--------|-----------|-------------|-------------|
| workspace_detection | complete | `.aidlc/workspace.md` | yjeong | 2026-04-17T09:15:00Z |
| requirements_analysis | complete | `requirements.md` | yjeong | 2026-04-17T11:00:00Z |
| user_stories | complete | `user-stories.md` | yjeong | 2026-04-17T14:00:00Z |
| workflow_planning | in_progress | - | - | - |

## Pending Questions

Q3. Authentication 방식 (A-E) — 2026-04-18T10:30:00Z 에 질문, 답변 대기 중

엔터프라이즈 적용 팁​

  • 세션 상태는 Git 으로 버전 관리 (PR 기반 협업 가능)
  • S3 + Versioning 으로 세션 상태 백업 (감사용)
  • 30일 이상 비활성 세션은 자동 아카이브

7. 규칙 6: Workflow Changes​

무엇​

AI 가 워크플로 순서를 임의로 추가·건너뛰기·수정하지 못하도록 합니다. 변경은 반드시 사용자의 명시적 승인 을 거쳐야 합니다.

왜​

  • AI 가 "효율적이라고 판단해" stage 를 건너뛰면 감사 추적 붕괴
  • 조직 규제(예: 금융 감독 규정)는 특정 stage 의무 실행 요구
  • 워크플로 변경 이력은 조직 학습 자산

어떻게​

워크플로 변경 요청 템플릿:

## Workflow Change Request

**Current Workflow**: workspace_detection → requirements_analysis → user_stories → workflow_planning

**Proposed Change**: user_stories 를 건너뛰고 바로 workflow_planning 으로 진행

**Reason**: 이미 `user-stories.md` 가 존재하며, 재검토 불필요

**Impact**:
- Session 소요 시간 1시간 단축
- 단, 최신 요구사항 변경 반영 누락 리스크

**Approval Required**: A. 승인 / B. 거부 / C. 조건부 승인 (추가 검토 후)

[Answer]:

엔터프라이즈 적용 팁​

  • Skip 불가 stage 목록 을 조직 확장(extensions)에 정의 (예: 금융은 security-review 건너뛰기 금지)
  • 변경 이력을 월별 거버넌스 리뷰에서 검토
  • "이례적 변경(outlier)" 패턴은 워크플로 개선 시그널

8. 규칙 7: Checkpoint Approval​

무엇​

각 stage 전환(예: requirements_analysis → user_stories) 시점에 사람의 명시적 승인 을 요구합니다.

왜​

  • Stage 전환 후에는 이전 산출물로 되돌리기 어려움 (비가역적)
  • 승인은 품질 게이트 + 거버넌스 증거 로 동시에 기능
  • Human in the loop 원칙의 구체적 구현

어떻게​

승인 템플릿:

## Checkpoint Approval Gate

**Completing Stage**: requirements_analysis
**Next Stage**: user_stories

**Artifacts Produced**:
- `requirements.md` (1,234 lines)
- `.aidlc/validation-report.md` (Content Validation 통과)
- `.aidlc/audit/stage-requirements-analysis.md`

**Review Checklist**:
- [x] 모든 비즈니스 요구사항 포함
- [x] NFR 측정 가능
- [x] 이해관계자 리뷰 완료

**Approver**: yjeong@example.com
**Approval Decision**:

A. Approve (다음 stage 진행)
B. Reject (현재 stage 재작업 필요)
C. Approve with comments

[Answer]:

엔터프라이즈 적용 팁​

  • 다중 승인자 패턴: 아키텍트 + 보안 + PM 3인 승인 필수인 경우 멀티시그 게이트 구현
  • 승인 기록은 감사 로그(규칙 8) 와 자동 연동
  • 승인 없이 다음 stage 실행 시도 시 에러 발생 (규칙 3 에 의해 처리)

9. 규칙 8: Audit Logging​

무엇​

AIDLC 실행 중 발생한 모든 이벤트(질문, 답변, 승인, 에러)를 ISO 8601 타임스탬프 + 원본 텍스트 보존 형식으로 감사 로그에 기록합니다.

왜​

  • 금융·의료 등 규제 산업은 의사결정 근거의 완전한 재현 가능성 요구
  • 사고 발생 시 원인 분석
  • AIDLC 자체 개선을 위한 데이터 축적

어떻게​

감사 로그 포맷 (audit.md):

## Event: Checkpoint Approval Granted

**Event ID**: evt-2026-04-18-042
**Timestamp**: 2026-04-18T10:45:12.345Z
**Session**: sess-20260418-payment-service
**Actor**: yjeong@example.com
**Stage Transition**: requirements_analysis → user_stories

**Original User Response** (원본 보존):

**AI Interpretation**: Approve (다음 stage 진행)

**Artifacts Hash**:
- requirements.md: sha256:abc123...
- validation-report.md: sha256:def456...

---

## Event: Question Asked

**Event ID**: evt-2026-04-18-041
**Timestamp**: 2026-04-18T10:42:00.000Z
**Session**: sess-20260418-payment-service
**Stage**: requirements_analysis
**Question Text** (원본 보존):

Q15. Payment Service 의 데이터 저장소로 무엇을 선택하시겠습니까? A. DynamoDB B. Aurora PostgreSQL ...

감사 로그 원칙:

  1. Append-only: 기존 로그는 절대 수정 불가
  2. 원본 보존: AI 의 해석/요약이 아닌 사용자·AI 의 원본 텍스트 저장
  3. ISO 8601 타임스탬프: 밀리초 precision + UTC 표기
  4. Artifact Hashing: 산출물 SHA-256 로 무결성 검증

엔터프라이즈 적용 팁​

  • 감사 로그는 S3 + Object Lock (WORM) 로 저장해 변조 방지
  • 금융권은 최소 7년, 의료는 10년 보관 정책 적용
  • 상세 규격은 Audit & Governance Logging 참조

10. 규칙 9: No Duplication​

무엇​

AIDLC 산출물 간에 동일 정보를 중복 생성하지 않습니다. 한 곳(Single Source of Truth, SSOT)에만 정보를 두고, 다른 곳에서는 참조합니다.

왜​

  • 중복은 불일치로 이어짐 (한쪽만 업데이트되면 산출물 간 모순 발생)
  • AI 에이전트가 중복된 정보를 학습하면 환각 증가
  • 유지보수 비용 폭증

어떻게​

중복 예시 (잘못된 패턴):

# requirements.md
- API latency P99 < 200ms

# design.md
- API latency P99 < 200ms
- 추가로 P95 < 100ms 필요

# nfr.md
- API P99 latency < 150ms  ← 불일치!

올바른 패턴 (SSOT):

# nfr.md (SSOT)
- PAY-NFR-001: API latency P99 < 200ms, P95 < 100ms

# requirements.md
- 성능 요구사항: PAY-NFR-001 참조

# design.md
- 성능 목표: PAY-NFR-001 참조, HPA 임계값은 이 목표에서 역산

엔터프라이즈 적용 팁​

  • 모든 요구사항·NFR·결정에 고유 ID 부여 (PAY-NFR-001)
  • 산출물 간 참조는 ID 기반 링크 만 허용
  • CI 에서 중복 문자열 검출 (>20 단어 동일 문장 발견 시 경고)

11. 규칙 10: Methodology First​

무엇​

AIDLC 는 특정 도구·플랫폼에 종속되지 않는 방법론으로 동작해야 합니다. 같은 산출물이 Kiro, Claude Code, Cursor 등 어디서든 생성 가능해야 합니다.

왜​

  • 도구 lock-in 은 조직의 민첩성을 저해
  • 방법론 > 도구 순서여야 장기적 자산화 가능
  • 산업 표준화(7개 지원 플랫폼)의 기반

어떻게​

도구 독립적 설계 원칙:

  1. 산출물은 평문 Markdown + YAML 만 사용
  2. 특정 IDE 기능(예: Kiro 의 Spec 파일) 의존 금지 — Generic 템플릿 제공
  3. MCP 서버 등 도구별 통합은 별도 확장으로 분리

Bad (도구 종속):

# design.md
Kiro 의 `.kiro/spec/design.md` 참조

Good (도구 독립):

# design.md
자세한 MCP 통합은 본 저장소의 `extensions/kiro-mcp/` 참조 (Kiro 사용 시에만)

엔터프라이즈 적용 팁​

  • 조직 표준 템플릿은 모든 플랫폼에서 동작 하도록 검증 (최소 2개 플랫폼 테스트)
  • 팀별 도구 선호도 차이를 허용하되, 산출물 포맷은 통일
  • 플랫폼 교체 시 산출물 마이그레이션이 단순 파일 복사 수준이어야 함

12. 규칙 11: Reproducible​

무엇​

동일한 입력(Workspace 상태 · Requirements · 질문 응답)에 대해, 동일 모델 + 동일 프롬프트라면 거의 동일한 산출물을 생성해야 합니다.

왜​

  • 재현 불가능한 시스템은 감사·디버깅·개선 불가
  • 팀 간 지식 전수 (같은 입력을 주면 같은 결과) 가능
  • AIDLC 자체를 신뢰 가능한 프로세스로 만듦

어떻게​

재현성 확보 메커니즘:

  1. 구조화된 질문 포맷 (규칙 1) — 답변 해석 일관성
  2. Temperature 0 또는 낮은 값 — LLM 출력 안정화
  3. Frozen model version — claude-opus-4-7 처럼 명시적 버전 고정
  4. Seed 고정 (지원 모델) — 동일 seed 시 동일 출력

재현성 테스트:

# 동일 입력으로 3회 실행 후 산출물 diff
aidlc run --input requirements.md --session test-1
aidlc run --input requirements.md --session test-2
aidlc run --input requirements.md --session test-3

diff .aidlc/test-1/requirements.md .aidlc/test-2/requirements.md
# 기대: 90% 이상 동일

엔터프라이즈 적용 팁​

  • 모델 업그레이드 시 재현성 회귀 테스트 필수 (골든 입력 세트 유지)
  • 모델 교체로 인한 산출물 drift > 20% 시 롤백
  • 규제 산업은 모델 버전을 3-5년 고정 유지 (NIST SP 800-218A 권장)

13. 엔터프라이즈 적용 통합 가이드​

13.1 Common Rules → 거버넌스 매핑​

규칙ISO 27001 관련SOC 2 관련한국 ISMS-P 관련
Checkpoint Approval (7)A.5.15 Access ControlCC6.22.8.3 변경관리
Audit Logging (8)A.8.15 LoggingCC7.22.9.4 로그관리
Content Validation (2)A.8.29 Security TestingCC8.12.11.2 소프트웨어 검증
Error Handling (3)A.5.24 Incident ManagementCC7.32.10.4 침해사고 대응

13.2 적용 로드맵​

13.3 도구·플랫폼별 구현 상태 (2026.04 기준)​

플랫폼규칙 1-4규칙 5-8규칙 9-11비고
KiroFullFullFullSpec-Driven 기본 탑재
Claude CodeFullFullPartialreproducibility 는 seed 미지원
CursorPartialPartialPartial확장 필요
Q DeveloperFullFullFullAWS 통합 우수
ClinePartialPartialFullCLI 중심
CopilotPartialLimitedLimited상호작용 제한
AGENTS.mdFullFullFull문서 기반

14. 참고 자료​

공식 저장소​

관련 문서​

규제 매핑​