TRENDSHIFT DEEP-DIVE · 2026.05.21 · awslabs/aidlc-workflows

AWS AI-DLC —
AI 코딩 에이전트를 "방법론"으로 길들이는 룰셋

AWS Labs가 만든 "AI-Driven Development Life Cycle" 메서드론. Kiro·Amazon Q·Cursor·Cline·Claude Code·GitHub Copilot·Codex 7개 코딩 에이전트에 같은 워크플로우를 강제한다. Inception → Construction → Operations 3단계 + Adaptive 분기. 코드가 거의 없는데 트렌딩 9위까지 올라온 이유.

0먼저, "메서드론 룰셋"이 뭔가

코드 한 줄 없는 레포가 어떻게 개발을 바꾸나.

AI-DLC는 코드 라이브러리도, 도구도 아니다. 마크다운 파일 한 묶음이다. 그런데 그 파일들을 — Cursor·Claude Code·GitHub Copilot 같은 AI 코딩 에이전트의 "프로젝트 룰" 위치에 놓으면, 그 에이전트가 갑자기 다르게 일한다.

구체적으로 — 평소엔 "이 기능 만들어 줘" 라고 하면 바로 코드를 쓰던 AI가, AI-DLC 룰을 받은 뒤로는 — "먼저 요구사항을 명확히 합시다. 다음 4가지 중 어느 시나리오가 맞나요?"부터 묻는다. 그 다음 디자인 단계, 그 다음 리스크 평가, 그 다음 코드. 사람을 매 단계마다 끼워 넣어 승인을 받는다.

한마디로 AI-DLC는 "AI 코딩 에이전트가 따라야 할 표준 운영 절차(SOP)"다. AWS가 자기 내부에서 굴리던 베스트 프랙티스를 오픈소스로 푼 셈.

용어
SDLC (Software Development Life Cycle, 소프트웨어 개발 생명주기)
전통적인 소프트웨어 개발 단계 — 요구사항 → 설계 → 구현 → 테스트 → 배포 → 유지보수. 1970년대부터 정립된 표준. AI-DLC는 이 SDLC를 AI 코딩 에이전트 시대에 맞춰 재설계한 버전. Inception → Construction → Operations 3단계로 압축하고, AI가 일을 맡는 단계와 사람이 승인하는 단계를 명시.
용어
Project Rules (프로젝트 룰)
AI 코딩 에이전트의 모든 응답에 자동 적용되는 지시문 파일. 도구마다 위치가 다름 — Cursor는 .cursor/rules/, Claude Code는 CLAUDE.md, GitHub Copilot은 .github/copilot-instructions.md, Codex는 AGENTS.md, Amazon Q는 .amazonq/rules/. AI-DLC는 한 마크다운 파일을 7개 위치 중 적절한 곳에 복사하면 적용된다.
용어
Steering File (조향 파일)
Kiro의 프로젝트 룰 이름. "AI를 어떤 방향으로 안내(steer)할지" 정의한다는 뜻. .kiro/steering/에 마크다운으로 두면 자동 로드. Cursor의 Rules, Claude Code의 CLAUDE.md와 본질적으로 같은 개념인데 — 코딩 에이전트마다 부르는 이름이 다르다.

1한 줄 요약

전체 글의 핵심 메시지.

핵심 메시지

"AI에게 코드를 더 잘 짜라고 시키지 말고,
일하는 절차 자체를 가르쳐라."

좋은 코드를 한 번 잘 짜는 것보다, 요구사항을 명확히 → 디자인을 검증 → 단계별로 사람 승인 → 그 다음 코드의 절차를 따르게 만드는 게 결과 품질을 훨씬 끌어올린다. AWS의 사내 프랙티스를 마크다운 한 묶음으로 응축한 결과가 AI-DLC.

그리고 7개 코딩 에이전트(Kiro·Q·Cursor·Cline·Claude Code·Copilot·Codex)에 같은 룰을 적용해서, 팀이 어떤 도구를 쓰든 같은 산출물·같은 품질을 얻을 수 있게 만든다.

2왜 지금 주목받는가

AWS Labs 레포가 트렌딩에 오른 이유.

2025~2026년 AI 코딩 에이전트가 폭증했다. 그런데 채택의 가장 큰 장애물은 — "AI가 자유롭게 코드를 짜면 품질·일관성이 떨어진다"는 두려움이다. 특히 큰 조직일수록 이 우려가 크다. AI-DLC는 그 답으로 등장.

기존 도입의 함정 1
"AI가 알아서 잘하겠지" 식 자유방임

아무 지침 없이 AI에게 "이 기능 만들어 줘" 하면 — 매번 다른 디자인, 다른 코딩 스타일, 다른 테스트 전략이 나온다. 코드베이스가 빠르게 누더기가 된다.

AI-DLC의 해결
3단계 구조화된 워크플로우

모든 작업이 Inception(요구사항) → Construction(구현) → Operations(운영) 단계를 거치도록 강제. 각 단계의 산출물 형식·승인 절차가 정해져 있어서, 어떤 작업이든 비교 가능한 형태로 끝난다.

기존 도입의 함정 2
"도구마다 다른 룰" 분산

팀에서 누구는 Cursor, 누구는 Claude Code, 누구는 Copilot을 쓴다. 각자 자기 도구의 룰만 알고 있어서 — 산출물·작업 방식이 사람마다 다르다.

AI-DLC의 해결
7개 에이전트에 같은 룰 일괄 적용

Kiro·Amazon Q·Cursor·Cline·Claude Code·GitHub Copilot·Codex 7개에 같은 core-workflow.md 마크다운 파일을 복사해 두기만 하면 끝. 도구가 달라도 결과는 같다.

기존 도입의 함정 3
"무조건 모든 단계" 오버킬

SDLC를 빡빡하게 적용하면 — 단순한 typo 수정에도 요구사항 분석·디자인 문서·리스크 평가를 요구한다. 개발 속도가 죽는다.

AI-DLC의 해결
Adaptive — 복잡도에 따라 단계 가감

AI가 작업 복잡도를 먼저 평가해서 — 단순 작업은 Inception 짧게 + Construction 바로, 복잡한 작업은 모든 단계 + 추가 검증. "적응형(Adaptive)"이 이름에 들어간 이유.

3기술 스택 — 마크다운이 전부인 레포

코드가 없는 레포의 "스택" 보는 법.

AI-DLC의 본체는 마크다운 파일 한 묶음이다. 그래도 그 마크다운이 어떻게 구성됐는지 — 그게 이 레포의 "스택"이다.

3.1 룰 구조

레이어 1

core-workflow.md — 메인 워크플로우

Inception/Construction/Operations 3단계와 각 단계의 절차를 정의한 마크다운 한 장. 이게 코딩 에이전트의 두뇌에 직접 로드되는 핵심 파일. 도구가 무엇이든 — 이 한 파일이 같은 방식으로 동작한다.

레이어 2

aws-aidlc-rule-details/ — 상세 규칙 (참조 자료)

core-workflow.md가 그때그때 필요할 때만 부르는 상세 규칙. common/(공통), inception/(요구사항 단계), construction/(구현 단계), extensions/(확장), operations/(운영) 5개 하위 폴더로 분리. Progressive Disclosure 패턴 — 메인 룰은 짧게, 깊은 디테일은 따로.

레이어 3

extensions/ — 옵트인 확장

핵심 워크플로우 위에 얹는 추가 규칙. 예: security/baseline/security-baseline.md(보안 베이스라인), testing/property-based/property-based-testing.md(속성 기반 테스트), resiliency/baseline/(탄력성 베이스라인). 각 확장에는 .opt-in.md 파일이 함께 있어 — Requirements Analysis 단계에서 사용자에게 "이 확장 켜겠습니까?"를 물어본다.

3.2 통합 지원 7개 에이전트

| 에이전트 | 룰 위치 | | ---------------- | -------------------------------------- | | Kiro | .kiro/steering/aws-aidlc-rules/ | | Amazon Q | .amazonq/rules/aws-aidlc-rules/ | | Cursor IDE | .cursor/rules/ai-dlc-workflow.mdc | | Cline | .clinerules/core-workflow.md | | Claude Code | CLAUDE.md (or .claude/CLAUDE.md) | | GitHub Copilot | .github/copilot-instructions.md | | OpenAI Codex | AGENTS.md |

각 에이전트마다 룰 파일의 위치 + 포맷이 약간씩 다르지만 — 본질은 같은 마크다운 파일을 다른 이름으로 복사하는 것뿐. README의 50% 이상이 7개 에이전트별 "어디에 복사하라"는 설명이다.

3.3 지원 도구 (scripts/)

도구 1

aidlc-evaluator

AI-DLC 워크플로우 변경의 자동 테스트·평가 프레임워크. Golden test cases + Semantic 평가(AI 기반 정확성 평가) + Code 평가(린팅·보안·중복) + NFR 평가(토큰·실행시간)까지 자동화. AI-DLC 자체를 개선할 때 회귀 테스트로 사용. Python + uv 기반.

도구 2

aidlc-designreview (실험적)

AWS Bedrock의 Claude 모델로 디자인 산출물을 자동 리뷰. 3개 전문 에이전트(Critique, Alternatives, Gap Analysis)가 각자 다른 관점으로 평가 + 가중 심각도 점수. CLI 모드(CI/CD 통합) 또는 Claude Code Hook(개발 중 실시간) 모드.

3.4 5대 원칙 (Tenets)

이 5대 원칙이 AI-DLC의 정체성을 만든다. "AWS가 만들었지만 AWS 종속이 없는, 도구 무관한 방법론"이라는 포지셔닝이 채택을 끌어올린다.

4아키텍처 — 3-Phase Adaptive Workflow

전체 그림과 각 단계의 역할.

4.1 워크플로우 전체 (ASCII)

사용자: "Using AI-DLC, 새로운 결제 API 추가해 줘" │ ▼ ┌─────────────────────┐ │ 복잡도 평가 (Adaptive)│ │ 단순? 중간? 복잡? │ └──────────┬──────────┘ │ ┌──────────────┴───────────────┐ │ │ ▼ ▼ [단순 경로] [복잡 경로] 1~2 단계만 전체 3단계 + 확장 🔵 INCEPTION (WHAT/WHY) ┌──────────────────────────────────────┐ │ • 요구사항 분석 + 검증 │ │ • 사용자 스토리 작성 (필요 시) │ │ • 애플리케이션 디자인 │ │ • 병렬 작업 단위 분할 │ │ • 리스크·복잡도 평가 │ └────────────┬─────────────────────────┘ ▼ 사람 승인 ↓ 🟢 CONSTRUCTION (HOW) ┌──────────────────────────────────────┐ │ • 컴포넌트 상세 디자인 │ │ • 코드 생성 + 구현 │ │ • 빌드 설정 + 테스트 전략 │ │ • QA + 검증 │ └────────────┬─────────────────────────┘ ▼ 사람 승인 ↓ 🟡 OPERATIONS (Deploy/Monitor — 향후) ┌──────────────────────────────────────┐ │ • 배포 자동화 + 인프라 │ │ • 모니터링·관측성 설정 │ │ • 프로덕션 준비 검증 │ └──────────────────────────────────────┘ ▼ 산출물: aidlc-docs/ 디렉토리

핵심 — "각 Phase 사이에 사람 승인 체크포인트"가 강제로 들어간다. AI가 알아서 끝까지 가지 않는다.

4.2 핵심 설계 패턴 5가지

패턴 1

Adaptive Workflow — 복잡도 기반 분기

AI가 첫 단계에 작업의 복잡도를 평가한다. 단순한 작업(타이포·간단 리팩토링)은 짧은 경로, 복잡한 작업(새 API·아키텍처 변경)은 전체 단계 + 확장 적용. 모든 작업에 같은 무거운 절차를 강제하지 않아 개발 속도 보존.

패턴 2

Question-Driven (구조화된 선택지)

요구사항 분석 단계에서 — 자유 텍스트 질문이 아니라 "다음 4가지 중 어느 것에 해당하나요?" 형식의 객관식 질문을 한다. 채팅이 아니라 파일에 결과를 남기게 해서 — 의사결정이 문서로 추적된다.

패턴 3

aidlc-docs/ 디렉토리 — 산출물 표준화

모든 산출물(요구사항·디자인·테스트 계획·구현 노트)이 aidlc-docs/라는 정해진 위치에 정해진 형식으로 떨어진다. 다른 사람이 프로젝트를 받았을 때도 같은 위치에서 같은 형식의 산출물을 찾을 수 있다. 팀 일관성.

패턴 4

Extension System — 옵트인 확장 룰

핵심 워크플로우 위에 추가 룰을 얹을 수 있다. .opt-in.md 파일이 있으면 — 요구사항 분석 단계에서 "이 확장 켤까요?" 객관식 질문. 사용자가 켜면 그 확장의 규칙이 모든 다음 단계에 강제 적용. 보안·컴플라이언스·테스트 같은 횡단 관심사에 적합.

패턴 5

Rule Verification — 차단형 검증

확장 룰은 blocking constraint로 작동. 각 단계에서 AI가 자기 산출물이 룰을 통과하는지 검증 → 통과 못 하면 그 단계가 진행되지 않는다. 린팅보다 강한 강제력. 보안 베이스라인 확장의 예 — "이 코드에 secret이 하드코딩됐는지", "입력 검증이 있는지" 같은 항목들이 자동 체크.

5레포 구조 해부

실제 파일 트리.

aidlc-workflows/ ├── README.md ← 메인 (7개 에이전트 설치 가이드) ├── CONTRIBUTING.md ├── CODE_OF_CONDUCT.md ├── LICENSE (MIT-0) ├── assets/ │ └── images/ ← 스크린샷 (각 에이전트 적용 화면) ├── docs/ │ ├── WORKING-WITH-AIDLC.md ← 사용 패턴 + 팁 │ └── GENERATED_DOCS_REFERENCE.md ← aidlc-docs/ 형식 레퍼런스 ├── aidlc-rules/ ← 레포 루트 폴더 (릴리스 ZIP과 구조 동일) │ ├── aws-aidlc-rules/ ← 핵심 워크플로우 룰 │ │ └── core-workflow.md ← 메인 룰 파일 (이게 핵심) │ └── aws-aidlc-rule-details/ ← 상세 규칙들 (참조용) │ ├── common/ │ ├── inception/ │ ├── construction/ │ ├── extensions/ │ │ ├── security/baseline/ │ │ ├── testing/property-based/ │ │ └── resiliency/baseline/ │ └── operations/ └── scripts/ ├── aidlc-evaluator/ ← 자동 평가 프레임워크 (Python) └── aidlc-designreview/ ← 디자인 리뷰 도구 (Bedrock + Claude)
파일 1

aws-aidlc-rules/core-workflow.md

레포의 심장. 이 한 파일이 7개 에이전트의 룰 위치에 복사된다. Inception/Construction/Operations 3단계 + Adaptive 분기 + 사람 승인 체크포인트 모두 여기 적혀 있다.

파일 2

aws-aidlc-rule-details/ — 상세 규칙 5개 폴더

common/(공통 룰), inception/(요구사항·디자인 규칙), construction/(코드·테스트 규칙), extensions/(보안·테스팅 확장), operations/(배포·모니터링 — 미래). core-workflow.md가 필요할 때만 부른다.

파일 3

scripts/aidlc-evaluator/

AI-DLC 자체를 자동 평가하는 프레임워크. "룰을 바꿨을 때 결과가 더 좋아졌는가?"를 회귀 테스트로 검증. 메타 레벨 도구 — AI-DLC를 개선하는 사람들이 쓴다.

파일 4

scripts/aidlc-designreview/

AWS Bedrock의 Claude 모델로 디자인 산출물을 자동 리뷰하는 도구. Critique/Alternatives/Gap Analysis 3개 에이전트 동시 실행 후 통합 리포트. 실험적이지만 흥미로운 패턴.

6학습 포인트 — 이 레포에서 뭘 배울 수 있나

팀에 AI 에이전트를 도입하는 방법론.

교훈 1

"AI 코딩의 진짜 자산은 룰 파일이다"

좋은 모델·좋은 도구도 중요하지만 — 팀에서 같은 룰 파일을 공유하면 누가 어떤 도구를 쓰든 결과가 비슷해진다. "우리 팀 룰 파일"이 팀의 코딩 표준만큼 중요한 자산. AI-DLC를 출발점 삼아 자기 팀 버전을 만들어 운영.

교훈 2

"Adaptive — 무거운 절차는 무거운 작업에만"

SDLC가 외면받았던 이유는 모든 작업에 같은 무게를 강제했기 때문. AI-DLC는 첫 단계에서 복잡도 평가 → 가벼운 작업은 가볍게, 무거운 작업은 무겁게. 이 패턴은 다른 워크플로우 설계에도 그대로 적용 가능.

교훈 3

"Question-Driven — 객관식이 자유 텍스트보다 좋다"

요구사항 정리 시 "어떻게 만들고 싶으세요?" 같은 자유 텍스트는 사용자가 답하기 어렵고 결과도 들쭉날쭉. 4지선다 객관식 + 파일에 답 저장이 결과 품질과 추적성을 모두 잡는다.

교훈 4

"Extension System — 점진적 확장의 모델"

핵심 워크플로우는 가볍게 유지하고, 횡단 관심사(보안·테스트·컴플라이언스)는 옵트인 확장으로. .opt-in.md 파일 패턴은 — 자기 팀 룰에도 그대로 적용 가능. "필수 규칙은 짧게, 선택 규칙은 풍부하게".

교훈 5

"룰 자체를 회귀 테스트하기"

aidlc-evaluator의 발상이 보석. "AI 코딩 룰을 개선할 때 새 룰이 옛 룰보다 좋아졌는지 자동 검증". 자기 팀 룰을 운영할 때도 골든 케이스 + 자동 평가를 도입하면, 룰 개선이 추측이 아니라 측정 기반이 된다.

7시스템 요구사항 & 설치

설치할 게 거의 없다.

필수 1

지원 코딩 에이전트 중 하나

Kiro(IDE/CLI 모드 통합), Amazon Q Developer, Cursor IDE, Cline VS Code Extension, Claude Code CLI, GitHub Copilot, OpenAI Codex 중 하나. README에 각 도구별 설치 링크.

설치

Release zip 다운로드 + 복사

1. Releases 페이지에서 ai-dlc-rules-v0.X.X.zip 다운로드 2. 압축 풀기 (~/Downloads/aidlc-rules/) 3. 자기 에이전트의 룰 위치로 복사 (예: Claude Code면 CLAUDE.md로 복사)

총 5분. 별도 패키지·런타임 설치 없음.

선택 도구

aidlc-evaluator 사용 시

Python + uv 필요. cd scripts/aidlc-evaluator && uv sync && uv run python run.py test로 골든 테스트 실행. AI-DLC를 개선·커스터마이즈할 때만 필요.

8직접 해볼 수 있는 실습 과제

난이도 ★~★★★★★.

과제 1 · ★

AI-DLC 설치 + 작은 작업으로 체험

자기 메인 코딩 에이전트(Cursor·Claude Code·Copilot 중 하나)에 AI-DLC 설치. 작은 작업(예: "User 모델에 created_at 컬럼 추가")을 "Using AI-DLC, ..."로 시작. 일반 AI 응답과 비교해서 어떻게 다르게 일하는지 체험.

과제 2 · ★★

Security baseline 확장 켜고 비교

같은 작업을 — security baseline 확장 OFF, ON 두 번 돌려 본다. 산출물 차이가 어떻게 나는지 본다. 입력 검증, secret 처리, 권한 체크 같은 항목이 자동으로 들어가는지 확인.

과제 3 · ★★★

자기 팀 확장 만들기

자기 팀의 특수 규칙(예: "모든 API에 audit log 남기기", "모든 함수에 doc string", "DB 변경은 마이그레이션 파일로만")을 — AI-DLC extension 포맷에 맞춰 마크다운 파일 작성. extensions/에 놓고 .opt-in.md도 함께. 다음 작업부터 그 규칙이 자동 적용되는지 확인.

과제 4 · ★★★★

aidlc-designreview를 자기 코드베이스에 돌리기

AWS Bedrock 자격증명 설정 후 design-reviewer --aidlc-docs /path/to/docs로 자기 디자인 산출물을 자동 리뷰. 3개 에이전트가 무엇을 잡아내는지 확인. "멀티 에이전트 자동 리뷰" 패턴의 실전 적용.

과제 5 · ★★★★★

자기 팀용 메서드론 분리·운영

AI-DLC를 fork해서 — 자기 팀 도메인(예: 핀테크, 헬스케어, e-커머스)에 맞춘 메서드론 룰 파일을 만들고 사내 사용. evaluator로 골든 테스트 케이스를 만들어 — 룰 변경 시 회귀 검증. "우리 팀만의 코딩 표준"을 AI 시대에 새로 만드는 작업.

9관련 기술 심화 학습 로드맵

4주 코스.

1주차

AI-DLC 일상 사용 + 핵심 워크플로우 이해

core-workflow.md 정독. 3-Phase 흐름·복잡도 평가·Question-Driven 패턴을 실전 사용으로 익히기. AWS의 메서드론 정의 페이퍼와 블로그도.

2주차

다른 룰셋·메서드론 비교

같은 시기 트렌딩에 올라온 다른 룰셋 레포들(luongnv89/claude-howto, shanraisshan/claude-code-best-practice, awesome-claude-code 등)과 AI-DLC를 비교. 각각의 디자인 트레이드오프 파악.

3주차

자기 도메인 확장 작성 + 검증

자기 도메인의 횡단 관심사(보안·테스트·로깅·모니터링)를 AI-DLC extension 포맷으로 작성. 동료에게 리뷰 요청. 실전 작업에 적용해서 효과 측정.

4주차

aidlc-evaluator로 회귀 테스트 설계

자기 룰셋의 골든 테스트 케이스 5~10개 작성. evaluator로 자동 평가 파이프라인 구성. "우리 룰이 좋아지고 있는가"를 측정 가능한 지표로 만들기가 마지막 단계.

10핵심 키워드 사전

짧은 정의 모음.

키워드
AI-DLC (AI-Driven Development Life Cycle)
AWS Labs가 정의한 AI 코딩 에이전트를 위한 SDLC. Inception → Construction → Operations 3-Phase + Adaptive + 사람 승인 체크포인트가 핵심.
키워드
Inception Phase
"WHAT/WHY"를 결정하는 단계. 요구사항 분석·사용자 스토리·디자인·리스크 평가. AI가 사용자에게 객관식 질문을 던져 요구사항을 명확화하는 단계.
키워드
Construction Phase
"HOW"를 결정하는 단계. 컴포넌트 설계·코드 구현·테스트 전략. Inception 산출물을 받아 실제 코드를 만든다.
키워드
Operations Phase
배포·모니터링 단계 (향후). 배포 자동화·인프라·관측성. 2026년 5월 기준 부분 구현.
키워드
Adaptive Workflow
작업 복잡도에 따라 단계 수를 동적으로 조정. 단순 작업은 짧게, 복잡 작업은 풀세트. SDLC의 무거움을 피하는 핵심 장치.
키워드
Steering / Rules / Instructions
코딩 에이전트가 자동으로 로드하는 지시문 파일. Kiro는 steering, Cursor는 rules, Claude Code는 CLAUDE.md, Copilot은 instructions — 이름만 다르고 본질은 같다.
키워드
Extension Opt-in
.opt-in.md 파일로 사용자에게 "이 확장 켜시겠어요?" 객관식 질문. 켜면 그 확장의 규칙이 모든 다음 단계에 강제 적용. 보안·테스트 같은 횡단 관심사에 적합.
키워드
Golden Test Case
aidlc-evaluator가 사용하는 정답 사례. "이 작업을 AI-DLC로 처리하면 이런 산출물이 나와야 한다"의 기준. 룰을 바꿨을 때 회귀 검증의 기반.

11참고 링크

레포·논문·블로그.

실용 가이드

오늘 바로 시도해볼 만한 것들

  1. 30분 설치 + 첫 시도. Release zip 받아 자기 코딩 에이전트에 복사. "Using AI-DLC, ..."로 작은 작업 한 번 돌려 본다. 일반 AI 응답과의 차이를 체험.
  2. core-workflow.md 정독. 100% 마크다운이라 30분이면 읽힌다. AI-DLC가 어떤 절차를 강제하는지 내부 구조를 알면 자기 팀에 맞게 변형할 발판이 생긴다.
  3. 한 번이라도 객관식 질문 패턴 도입. 자기가 만드는 다른 도구·문서에서도 "자유 답" 대신 "객관식 + 파일에 저장" 패턴을 시도. 결과 일관성이 눈에 띄게 올라간다.
  4. 팀 룰 파일을 자산으로 인식. CLAUDE.md, .cursor/rules, AGENTS.md 같은 파일들을 코드와 동급으로 버전 관리. 팀 코딩 표준 문서의 AI 시대 버전.
  5. "메서드론 우선" 사고방식 학습. AI-DLC가 강조하는 5대 원칙(특히 Methodology first, Human in the loop)을 자기 도구 설계에도 적용. 도구는 메서드론을 따르고, 사람 승인은 비싸지만 필수.
원문 · awslabs/aidlc-workflows, 2026.05.21 · github.com/awslabs/aidlc-workflows · TrendShift 9위 기준