AI 주도 개발 라이프 사이클(AI-DLC) 정의하기
AI 주도 개발 시대, 당신의 스프린트는 아직도 2주입니까
2주 스프린트가 '애자일'이라는 착각
AWS 블로그에 올라온 AI-DLC(AI 주도 개발 라이프사이클) 글을 읽다가 뒤통수를 맞은 기분이 들었다.우리 팀은 2주 단위 스프린트를 짜면서 스스로 '애자일'하게 일한다고 믿어 왔다. 매주 스탠드업 미팅을 하고, 회고를 하고, 백로그를 관리하면서. 그런데 문득 이런 생각이 들었다.AI는 초 단위로 코드를 생성하는데, 우리는 여전히 주 단위로 회의하고 있지 않은가?이건 마치 페라리를 사놓고 1단 기어로만 달리는 것과 다를 바가 없다.
더 빠른 마차가 아니라, 자동차가 필요하다
AI-DLC 백서에서 가장 인상 깊었던 비유가 있다.
기존 SDLC에 AI를 적용하는 것은 더 빠른 말을 만드는 것과 같다.
우리에게 필요한 것은 자동차다.
기존의 SDLC나 스크럼은 사람이 주도하는 장기 실행 프로세스를 위해 설계됐다. 프로덕트 오너, 개발자, 아키텍트 모두 계획 회의, 스탠드업, 회고 같은 '의례적 활동'에 상당한 시간을 쏟는다. 이런 구조에 AI를 끼워 넣으면 어떻게 될까?
마차에 제트 엔진을 묶는 꼴이다. 마차 프레임은 그 속도를 견딜 수 없고, 결국 공중분해된다.
문제는 더 심각하다. AI를 기존 방식에 맞추면 AI의 능력이 제약될 뿐만 아니라, 기존의 비효율적인 관행까지 그대로 답습하게 된다. 우리는 이미 가지고 있는 강력한 도구를 스스로 무력화시키고 있는 셈이다.
2022년 미국에서만 소프트웨어 품질 문제로 인한 비용이 2조 4,100억 달러에 달했다고 한다. 기존 방법론이 얼마나 구멍 투성이인지 보여주는 숫자다. 그런데 거기에 AI를 끼워 넣으면 뭐가 달라질까? 구멍 난 배에 더 강력한 엔진을 달아봤자 더 빨리 가라앉을 뿐이다.
AI-DLC의 핵심 전환: 대화의 방향을 뒤집어라
AI-DLC가 제안하는 가장 근본적인 변화는 대화의 방향 전환이다.
[기존 방식]
"AI야, 이 함수 작성해줘" → "AI야, 이 버그 고쳐줘" → "AI야, 테스트 코드 만들어줘"
인간이 작업을 정의하고, AI에게 명령한다. AI는 그저 똑똑한 타자기일 뿐이다.
[AI-DLC 방식]
AI: "이 기능을 구현하려면 세 가지 접근법이 있어. 첫 번째는... 어떤 방식으로 진행할까?"
→ 인간: "두 번째 방식으로 가되, 보안 요구사항을 추가해"
→ AI: "반영했어. 다음 단계로 도메인 모델을 설계할까?"
AI가 계획을 세우고 제안하며, 인간은 검증하고 승인한다.
마치 구글맵처럼 인간은 목적지(Intent)를 설정하면, AI가 최적의 경로를 제안한다. 인간은 그저 '검증'하고 '승인'할 뿐이다. 내비게이션이 안내하지만, 핸들은 여전히 인간이 잡고 있다.
목적지만 찍으면 알아서 최적 경로를 찾아주는데,
왜 굳이 그렇게 쓰고 있었을까?
스프린트는 마라톤이었다. 이제는 볼트(Bolt)로 질주할 때다
스크럼의 스프린트는 보통 2-4주다. AI 이전 시대에는 이것이 '빠른 반복'이었다. 하지만 AI가 몇 초 만에 코드를 생성하고, 몇 분 만에 테스트를 작성하는 시대에 2주는 영겁과 같다.
AI-DLC는 볼트(Bolt)라는 새로운 작업 단위를 도입한다.
Intent (의도) 달성해야 할 높은 수준의 목표다. "교차 판매를 위한 추천 엔진 개발"처럼 비즈니스 목표를 명확히 정의한다. 여기서 중요한 건, 이게 기술 명세가 아니라 비즈니스 의도라는 점이다.
Unit (유닛) Intent를 독립적으로 배포 가능한 응집력 있는 작업 블록으로 분해한 것이다. DDD의 서브도메인이나 스크럼의 에픽과 유사하지만, 더 느슨하게 결합되어 병렬 개발이 가능하다. '사용자 데이터 수집', '추천 알고리즘 선택', 'API 통합' 같은 식으로 쪼개진다.
Bolt (볼트) 스프린트의 진화형이다. 주 단위가 아닌 시간 또는 일 단위로 측정되는 초고속 반복 주기다. 스프린트가 마라톤이었다면, 볼트는 100m 질주다.
의도적인 인지 전환이다. '스프린트'라는 단어를 들으면 우리 뇌는 자동으로 2주, 스탠드업, 회고를 떠올린다. '볼트'는 그 선입견을 깨고, 완전히 다른 속도감을 요구한다.
인간의 감독이 '손실 함수'가 된다
AI-DLC에서 인간의 역할은 손실 함수(Loss Function)다. 머신러닝에서 손실 함수가 모델의 오류를 측정하고 교정하듯이, 인간은 AI가 생성한 산출물을 각 단계마다 검증하여 오류가 눈덩이처럼 커지기 전에 조기에 잡아낸다. 백서에서는 이걸 "낭비적인 다운스트림 노력이 발생하기 전에 이를 식별하고 제거"한다고 표현한다.
쉽게 말하면 손실 함수로서의 인간의 역할은 "삽질하기 전에 미리 막는"거다.
사일로의 파괴: 모든 개발자(+기획자)는 풀스택 그 이상이 된다
인프라 엔지니어, 백엔드 개발자, 프론트엔드 개발자, DevOps 엔지니어...
이 모든 역할의 경계가 AI에 의해 허물어진다. 백서의 표현을 빌리면, 개발자의 역할은 인프라, 백엔드, 프론트엔드를 아우르도록 확장되고, 여러 전문 역할의 필요성이 줄어들어 프로세스가 간소화된다. 하지만 제품 소유자와 개발자는 여전히 감독, 검증, 전략적 의사 결정에 대한 핵심 책임을 유지한다.
개발자의 새로운 역할은 "비즈니스 가치를 코드와 인프라로 즉시 치환하는 프로덕트 오너형 엔지니어"다. 특정 기술의 전문가가 아니라, AI를 지휘하여 비즈니스 문제를 해결하는 오케스트레이터가 되는 것이다.
기획자도 마찬가지다. AI-DLC에서 핵심은 코딩 실력이 아니라 "비즈니스 의도를 명확히 정의하고, AI의 제안을 검증하며, 전략적 결정을 내리는 능력"인데, 이건 원래 기획자가 매일 하던 일이다. 개발자가 프로덕트 오너형으로 진화한다면, 기획자는 거꾸로 "엔지니어형 프로덕트 오너"로 진화할 수 있다. 비즈니스 가치를 가장 잘 아는 사람이 AI를 직접 지휘해서 제품을 만드는 것. 더 이상 중간에 번역가를 끼울 필요가 없다.
개발자는 프로덕트 오너형 엔지니어로, 기획자는 엔지니어형 프로덕트 오너로
기획자도 무조건 빌더가 되어야 하는 시대
솔직히 AI-DLC를 읽으면서 가장 많이 생각한 건 개발자가 아니라 기획자였다.
AI가 코드를 생성하고, 인프라를 구성하고, 테스트를 만든다면... 비즈니스 의도를 가장 잘 이해하는 사람이 직접 빌더가 되는 게 가장 효율적이지 않을까?
수천만 원의 외주 예산, 개발팀과의 끝없는 커뮤니케이션, 요구사항 문서 작성에 쏟는 시간... 이 모든 것이 (우리 문과생들의 꿈이었던) "내가 직접 만들면 되는데"로 바뀔 수 있다.
AI-DLC 환경에서 기획자는 선택이 아닌 필수로 빌더가 되어야 한다. 비즈니스 가치를 가장 잘 아는 사람이 AI를 지휘하여 직접 제품을 만드는 것. 이것이 AI 시대의 새로운 역할 정의다.
이론은 충분하다. 문제는 "그래서 어떻게?"다.
마침 이런 고민을 하던 차에, 새 출발하게 된 태재 AI 아카데미에서 딱 맞는 과정을 준비했다.
수천 만 원의 외주 예산 대신 내부 직원을 서비스 빌더로 변화시킨 실제 케이스에서 출발한 바이브코딩 아카데미다. (해당 케이스를 만든 비개발자 출신으로 에어비앤비와 X(트위터)에서 엔지니어로 활약했던 강사분을 모셨다). 개발 지식이 전혀 없던 분들도 직접 서비스를 기획하고, 개발하고, 관리까지 해내게 된 그 경험을 5주 과정으로 압축했다.
관심 있는 분들은 다음 정보를 참고하시라.
태재 바이브코딩 아카데미: https://taejae.ai/vibecoding
*신청 시 이름란에 "VIBE2026"을 적으면 10% 할인 적용된다 (예: 김말랑 VIBE2026). 임직원 단체 수강도 가능하니 편하게 연락 달라.
