awslabs/aidlc-workflows는 AWS Labs가 조용히 공개한 레포지만, 92★/day가 붙은 데에는 이유가 있다. 이름은 'AI-Driven Life Cycle(AI-DLC)' — 즉 코딩 에이전트가 따라야 할 소프트웨어 라이프사이클을 명시적으로 정의해놓은 steering rules 모음이다. README의 한 줄 설명은 'adaptive workflow steering rules for AI coding agents'. 짧지만 정확하다. 코드가 아니라 LLM이 읽을 .md 룰셋 묶음이고, 그 룰이 에이전트의 다음 한 수를 결정한다.
구조를 까보면 단계가 또렷하다. 사용자의 모호한 요청을 명시적 의도로 환원하는 intent capture, 비기능 요구와 제약을 못 박는 requirements, 옵션과 trade-off를 정리하고 사람의 승인을 받는 architecture decision, 그 결정에서 이탈하면 자동으로 위 단계로 되돌아가는 implementation, 마지막으로 Well-Architected 렌즈를 빌려온 validation. 흥미로운 점은 '적응형'이라는 단어가 단순 수식어가 아니라는 것이다. 작은 패치성 변경이면 게이트가 압축되고, 신규 시스템이면 전 게이트가 펼쳐진다. 룰셋 자체가 프로젝트 리스크에 따라 모양을 바꾼다.
이 레포가 의미 있는 이유는 비교 대상이 명확하기 때문이다. Cursor Rules나 Claude의 `.claude` 디렉토리는 코드 스타일과 금지어 위주라 라이프사이클 개념이 없다. Spec-driven dev 도구들은 스펙→코드의 한 방향에 머문다. 사내 RFC 템플릿은 사람을 위해 쓰여서 LLM 컨텍스트에 그대로 넣기엔 너무 길다. AI-DLC는 그 사이의 빈자리를 정확히 노린다 — LLM이 한 번의 컨텍스트에서 읽을 수 있는 길이로, 단계 분할과 승인 게이트가 박힌 워킹 카피.
물론 한계도 분명하다. AWS의 향이 짙어서 IAM·CloudFormation·Well-Architected가 곳곳에 전제돼 있고, 다른 클라우드로 옮기려면 룰을 상당 부분 다시 써야 한다. 게이트를 에이전트가 우회하지 않는다는 보장은 결국 모델의 instruction-following 성능에 의존한다. 그럼에도 사내에서 AI 코딩 표준을 처음 세우려는 팀이라면, 백지에서 시작하지 말고 이 레포의 단계 구분과 게이트 구조를 가져다 자사 리뷰 프로세스에 맞춰 가지치는 편이 훨씬 빠르다. 진짜 가치는 코드가 아니라, 에이전트에게 SDLC를 설명하는 한 가지 작동하는 방식이라는 데 있다.