AI 에이전트가 너무 빨리 코드부터 짜는 문제
요즘 Claude Code, Cursor, Kiro 같은 AI 코딩 에이전트를 써보셨다면 이런 경험이 한 번쯤 있을 거예요. '회원가입 기능 만들어줘'라고 한 줄 보냈더니, 에이전트가 질문 하나 없이 파일을 열 개쯤 만들어 버리는 거죠. 언뜻 보면 그럴듯한데, 막상 열어보면 우리 팀 인증 방식이랑 안 맞거나 필요 없는 기능까지 잔뜩 들어가 있거든요.
AWS Labs가 공개한 aidlc-workflows는 바로 이 문제를 겨냥한 프로젝트예요. AI-DLC는 'AI-Driven Development Life Cycle'의 줄임말이에요. AWS가 제안해 온 AI 중심 개발 방법론을 실제 코딩 에이전트가 따를 수 있도록 규칙 파일(steering rules) 형태로 정리했어요.
스티어링 룰이 뭐냐면
AI 에이전트에게 주는 '업무 매뉴얼'이라고 생각하시면 돼요. 신입 사원이 들어오면 '코드 짜기 전에 요구사항부터 확인하고, 설계 리뷰 받고, 그다음에 구현하세요'라고 알려주잖아요. 스티어링 룰은 그 내용을 마크다운 파일로 써 두고 에이전트가 매번 읽게 하는 방식이에요. Kiro의 steering 폴더, Amazon Q Developer의 rules 폴더, Cursor의 rules, Claude Code의 CLAUDE.md가 모두 같은 개념이에요.
aidlc-workflows는 이런 규칙 파일 묶음을 제공해요. 에이전트가 이걸 읽으면 바로 코드를 짜는 대신 정해진 단계를 차례로 밟아가며 일하게 되는 거죠.
어떻게 동작하나요
큰 흐름은 세 단계로 나뉘어요.
- Inception(시작 단계): 무엇을 만들지 정하는 단계예요. 요구사항을 정리하고, 필요하면 사용자 스토리를 쓰고, 작업을 적당한 크기로 쪼개요.
- Construction(구축 단계): 어떻게 만들지 정하고 실제로 만드는 단계예요. 세부 설계, 성능·보안 같은 비기능 요구사항 검토, 코드 생성, 빌드와 테스트까지 이어져요.
- Operations(운영 단계): 배포와 모니터링 영역인데, 아직은 앞으로 채워질 부분이 많은 단계로 보시면 돼요.
또 하나 중요한 특징은 사람의 승인 지점이에요. 에이전트는 단계마다 질문을 던지고 계획을 문서로 남긴 뒤, 사람이 확인해야 다음 단계로 넘어가요. 산출물은 프로젝트 안의 별도 문서 폴더에 쌓이기 때문에, 나중에 '왜 이렇게 설계했지?'를 추적하기도 쉬워요. 대화 기록은 사라져도 문서는 남으니까요.
업계 흐름에서 보면
사실 이 방향은 AWS만의 이야기가 아니에요. GitHub의 Spec Kit, Kiro의 스펙 기반 개발(spec-driven development), 커뮤니티에서 공유되는 각종 CLAUDE.md 템플릿까지 최근 흐름은 모두 같은 쪽을 향하고 있거든요. '프롬프트 한 줄로 끝내기'에서 '명세를 먼저 쓰고 AI가 그걸 따르게 하기'로 옮겨가는 중이에요.
하나씩 비교해 보면 Spec Kit은 명세, 계획, 작업 순서로 사용자가 명령어를 직접 호출하는 성격이 강하고, Kiro의 스펙 기능은 IDE에 통합된 경험을 제공해요. 반면 aidlc-workflows는 특정 도구에 묶이지 않는 규칙 파일 묶음이라는 게 특징이에요. 마크다운이라 다른 에이전트로 옮기기 비교적 쉽고, 팀 상황에 맞게 고쳐 쓰기도 편하죠. 대신 규칙을 얼마나 충실히 따르는지는 결국 에이전트와 모델 성능에 달려 있다는 한계도 있어요.
한국 개발자에게 주는 시사점
첫째, 당장 써볼 수 있어요. 오픈소스 규칙 파일이라 지금 쓰는 에이전트의 규칙 폴더에 넣기만 하면 돼요. 사이드 프로젝트에서 작은 기능 하나를 이 흐름으로 만들어 보면 감이 금방 와요.
둘째, 팀 단위로 AI를 도입할 때 가이드로 참고할 만해요. 'AI 써도 되는데, 어떻게 써야 하는지 기준은 없다'는 팀이 꽤 많잖아요. 이 저장소의 단계 구성과 승인 지점 설계는 우리 팀만의 AI 사용 규칙을 만들 때 좋은 뼈대가 돼요.
셋째, 결국 중요한 건 요구사항을 잘 정의하는 능력이에요. AI가 코드를 빨리 짜줄수록 무엇을 만들어야 하는지 명확히 말하는 능력, 그리고 결과물을 검토하는 능력의 가치가 더 커지거든요. 주니어라면 이 규칙 파일을 '좋은 개발 프로세스 교과서'처럼 읽어보는 것도 추천해요.
주의할 점도 있어요. 단계가 많아지면 토큰 사용량과 대기 시간이 늘어나고, 승인 지점마다 사람이 답해야 하니 번거롭게 느껴질 수 있어요. 처음부터 전부 적용하기보다는 팀에 필요한 단계만 골라 쓰는 게 현실적이에요.
마무리
한 줄로 정리하면, aidlc-workflows는 AI 에이전트에게 '바로 코드부터 짜지 말고, 일의 크기에 맞게 생각하고 확인받으면서 일하라'고 가르치는 규칙 모음이에요.
여러분은 AI 코딩 에이전트를 쓸 때 어떤 규칙을 정해 두고 계신가요? 명세를 먼저 쓰는 방식이 실제로 품질을 높여줬는지, 아니면 속도만 늦췄는지 경험을 나눠주세요!
🔗 출처: Hacker News