AI-DLC 워크샵 - AI 주도 개발 주기 방법론 학습 노트

2026-084 minai-dlcai-agentkiroclaude-codemob-programming

배경

AI-DLC(AI-Driven Development Life Cycle) 워크샵에 참가했다. 요구사항 분석부터 설계, 구현, 검증, 운영 준비까지 개발 주기 전체를 AI와 사람이 나눠 맡는 방향으로 도구가 바뀌고 있다는 설명이었다.

AI-DLC는 그 역할 분담을 절차와 산출물로 정리한 방법론이다. AI는 계획 수립, 작업 분해, 아키텍처 제안, 코드 생성을 지원하고, 사람은 요구사항 확인, 의사결정, 리뷰와 승인을 책임진다.

학습 내용

AI 개발 도구의 변화

워크샵에서는 도구 변화를 연도별로 정리했다.

2023년: 다음 몇 줄을 예측하는 자동완성
2024년: 더 큰 코드 조각을 만들고 질문에 답하는 어시스턴트
2025년: 도구를 골라 쓰는 에이전트
2026년: 역할이 나뉜 여러 에이전트가 함께 일하는 멀티 에이전트

AI 개발의 현실과 한계

자료에서는 도구만 쓸 때의 이득을 약 10~15%로 보았고, 숙련 개발자가 AI를 쓰면 작업이 오히려 길어질 수 있다는 연구도 소개했다.

이유는 두 가지다.

코딩이 빨라져도 설계, 분석, 테스트, 검증, 소통이 개발 시간의 큰 부분을 차지해서 전체 속도는 잘 바뀌지 않는다.
AI에 넣는 컨텍스트가 빈약하면 스펙에 없는 부분을 추측하게 된다. 보안·성능·확장성 같은 비기능 요구사항이나 도메인 모델, 에러 처리, 로깅이 빠질 수 있다.

AI-DLC의 구성

AI-DLC는 AI의 속도와 사람의 판단을 함께 쓰는 협업 방식이고, 코드 생성을 포함한 개발 프로세스 전체를 이 전제로 다시 짠다.

단계는 세 개다.

Inception: 프로젝트 범위, 요구사항, 사용자 스토리, 고수준 구조를 정한다.
Construction: 유닛별 상세 설계, 코드 생성, 인프라 설계, 빌드와 테스트를 한다.
Operations: 배포, 모니터링, 장애 대응을 다룬다.

산출물 중심의 흐름

단계마다 산출물을 남기고, 그것을 다음 단계의 입력으로 쓴다. 요구사항 정의서, 사용자 스토리, 도메인 모델, API 스펙, 아키텍처 의사결정 기록(ADR), 애플리케이션 코드, IaC 코드, 테스트 코드, 운영 문서가 그 예다.

AI가 질문과 검증으로 컨텍스트를 쌓고, 사람의 리뷰와 승인을 거친 뒤에 다음 단계로 넘어간다.

실습

실습은 AI-DLC를 실제 프로젝트에 적용하는 순서를 따랐다. 요구사항 분석, 사용자 스토리 작성, 시스템 설계, 도메인·비즈니스 로직 설계, 코드 생성, IaC 생성과 배포, 통합 검증 순이다.

진행은 Mob Programming 방식이었다. 팀 전체가 같은 시간, 같은 자리에서 같은 작업을 하며 문제를 함께 보고, AI가 만든 결과물을 함께 검토한 뒤 결정을 내린다.

Kiro IDE와 Kiro CLI

각자 노트북에 Kiro IDE와 Kiro CLI를 설치해 실습했다. 이번 실습만 놓고 보면 Kiro가 Cursor나 Claude Code와 완전히 다른 사용 경험이라고 보기는 어려웠다. 세 도구 모두 자율성을 어디까지 줄지, 컨텍스트를 어떻게 유지할지를 다루고, Kiro는 그것을 Autopilot/Supervised 모드와 Steering으로 비교적 단순하게 보여 준다.

Kiro CLI는 사용 중 retry가 자주 발생해 흐름이 끊겼고, 실습 후반은 Claude Code로 이어서 진행했다. Kiro CLI의 차별성이나 안정성은 충분히 검증하지 못했다. 실제 프로젝트에 적용하기 전에는 Steering 유지 비용, Cursor Rules·CLAUDE.md와의 중복 여부, 자율 실행 모드의 안전성, CLI 실행 안정성을 함께 비교해 볼 필요가 있다.

배운 점

코딩 보조로만 쓰면 생산성 이득이 제한적이다. 요구사항 분석, 설계, 검증까지 프로세스 단위로 봐야 한다.
AI 결과는 컨텍스트 품질에 좌우된다. 질문으로 요구사항을 좁히고 단계마다 산출물을 남기는 이유가 여기 있다.
사람은 검증과 의사결정을 맡는다.
보안, 성능, 확장성, 운영성 같은 비기능 요구사항은 초기에 적어 두고 설계와 구현 내내 따라가야 한다.
팀에 적용한다면 팀별 개발 방식과 승인 절차에 맞춰 규칙 파일과 산출물 템플릿을 먼저 맞춰 두는 편이 낫다.
방법론을 통째로 이식하기보다 Inception, Construction, Operations 순서로 산출물을 남기는 방식부터 시험해 볼 만하다.