AI-DLC를 활용한 업무용 툴 개발기

 2026년 2월 현재, AI-DLC에 대해 들어본 개발자는 많지 않을 것이라고 생각한다. 나의 경우 우연한 기회로 AI-DLC에 대해 접할 수 있었고 이를 활용하여 업무에 도움이 되는 툴을 만들어 보았다.

 먼저 밝히고 싶은 점은, AI-DLC는 최신 개발 방법론이며 아직 정보가 많지 않다는 것이다. 따라서 내가 이해한 내용 중 일부는 오해가 있을 수도 있다. 이 글은 정답이라기보다는 체험 사례 중 하나로 봐주면 좋겠다.
 

 👾 AI-DLC(AI-Driven Development Lifecycle)

• AI-DLC는 AI-Driven Development Lifecycle의 줄임말로, AI를 중심에 두는 개발 방법론이다.
• AI를 단순한 보조 도구가 아니라, 설계부터 개발까지의 흐름을 주도하는 핵심 주체로 둔다.
• 이미 AI 에이전트와 함께 개발해 본 사람이라면 이런 의문이 들 수도 있다.

 

“이거 그냥 AI 잘 쓰는 거랑 뭐가 다른 거야?”

 
 
기존의 AI 활용 개발 방식을 떠올려보면 대개 이렇다.

• 인간이 질문을 던진다
• AI가 답변하거나 코드 예시를 제시한다
• 인간이 판단해 일부를 반영한다

 
즉, 주도권은 언제나 인간에게 있고 AI는 도구에 가깝다.
여기서 질문 하나를 던져보자.
 

당신은 AI를 단순한 ‘보조 도구’라고 생각하는가, ‘함께 사고를 확장해 나가는 파트너’로 대하고 있는가?

 
 
AI-DLC의 핵심은 바로 이 관계 설정의 변화에 있다.
의존성 역전 원칙(DIP)이 구현 세부사항이 아닌 추상과 정책을 중심으로 설계를 재구성했듯이, AI-DLC는 인간의 즉각적인 판단과 손작업 중심 흐름에서 벗어나, 사고와 설계의 구조를 AI에게 위임한다. 다만 여기서 중요한 점은, 결정과 책임까지 AI에게 넘긴다는 의미는 아니라는 것이다.
 
AI-DLC에서 AI는 지시를 기다리는 수동적인 도구가 아니라 문제를 분해하고 선택지를 제시하며 판단이 필요한 지점을 명확히 드러내는 사고 보조자이자 질문을 던지는 동료에 가깝다.
 
인간은 그 질문에 답하고, 방향을 선택하며, 최종 책임을 진다. 말이 조금 추상적으로 느껴질 수 있으니, 이제 이를 실제 개발 흐름에서 어떻게 체감할 수 있는지 좀 더 구체적으로 살펴보자.

🫥 핵심 키워드

• AI-DLC는 AI가 중심이기 때문에, 기존의 인간 중심 개발 방식과는 여러 면에서 다르다.
• 대표적인 차이점은 속도와 반복 주기다.
• 주 단위 스프린트 대신, 시간 또는 일 단위의 초고속 반복을 지향한다.
• AI가 대부분의 작업을 처리하고, 인간은 전략적 승인과 검증에 집중하기 때문이다.

 

키워드	정의 및 특징
Intent (의도)	개발의 시작점이 되는 고수준의 비즈니스 목표나 기술적 요구사항
Unit (단위)	의도(Intent)에서 파생된 독립적이고 응집력 있는 작업 요소
Bolt (볼트)	AI-DLC의 최소 반복 단위. 기존의 '스프린트'를 대체하며, 시간 또는 일 단위의 초고속 사이클을 의미함.

 

🎃 AI-DLC 기반 개발 프로세스 (예시)

이 방법론을 통해 실제 서비스를 개발한다면 다음과 같은 흐름으로 진행된다.

Inception (기획 및 설계)

• AI가 인간에게 질문을 던진다
  • “추천 대상은 누구인가요?”
  • “어떤 데이터 소스를 사용하나요?”
• 인간의 답변을 바탕으로 AI가 의도를 구체화한다
• AI가 유저 스토리와 초기 설계를 생성한다
• DDD 원칙에 따라 시스템을 독립적인 Unit으로 분해한다

Construction (구축)

• AI가 각 Unit의 핵심 엔티티를 모델링한다
• 트레이드오프를 제안한다
  • 🤖 : "확장성을 위해 Lambda를 쓰되, 성능을 위해 DynamoDB를 추천합니다"
• 승인 즉시 실행 가능한 코드와 테스트 코드를 생성한다

Operations (운영)

• AI가 자동으로 배포한다
• 운영 중 이상을 감지해 해결책을 제안한다
• 인간은 역시 승인 여부만 판단한다

 

🧐 바이브 코딩과의 차이점?

AI-DLC를 설명하다 보면 자연스럽게 바이브 코딩(Vibe Coding)과 비교하게 된다. 먼저 분명히 하고 싶은 점은 둘 중 어느 게 낫다는 이야기를 하는 게 아니다. 바이브 코딩은 개인 생산성을 극대화하거나, 아이디어를 빠르게 탐색하는 초기 단계에서는 매우 합리적인 접근이라고 생각한다. AI-DLC는 바이브 코딩을 대체하기 위한 개념이라기보다는, 적용되는 문제의 스케일과 복잡도가 다르다고 보는 편이 더 정확할 것 같다.
 

구분	바이브 코딩 (Vibe Coding)	AI-DLC
주된 목적	빠른 구현, 아이디어 탐색, 개인 생산성	복잡한 문제의 구조화, 지속 가능한 개발
대화 주체	인간이 주도 (사람이 질문하고 AI가 답변)	AI가 주도 (AI가 질문하고 사람이 승인)
설계 기법	즉흥적이거나 필요에 따라 점진적 설계	설계 원칙을 초기부터 구조에 포함
적용 대상	1인 개발, 프로토타입, 단순한 웹/앱	대규모 복잡한 시스템, 엔터프라이즈
반복 주기	정해진 주기 없음 (될 때까지 반복)	Bolt라 불리는 시간 단위의 사이클

 

💻 AI-DLC를 활용한 사내 툴 개발기

• 이번에 만든 툴의 이름은 바쁘군이다.
• 간단히 말해, Backlog API로 현재 처리 중인 티켓 수를 조회하고, 그 결과를 바탕으로 Slack API를 통해 업무 처리 예상 속도를 이모지🤡로 시각화해 표시해주는 툴이다.
  
  • Backlog는 JIRA와 비슷한 프로젝트 관리 툴이다.

• 여담으로 아이콘은 야무치로 했다.(피곤에 찌든 우리 모습..)

 

요건 상정

대부분 회사에서의 업무는 일반적으로 아래와 같이 나뉘지 않나 싶다.

• 팀 내 기본 업무
• 팀 외부에서 오는 문의, 요청 등

팀 내 업무는 회의를 통해 팀원 간에 어느 정도 가시성이 확보될 것이다.
반면, 팀 외부에서 들어오는 요청은 개인의 현재 업무량과는 상관없이 발생한다.

이로 인해 다음과 같은 문제가 생긴다.

• 이미 업무가 몰린 상황에서 외부 요청이 갑자기 집중되면 대응 시간이 길어진다.
• 외부에 요청을 보낼 때, 상대방의 업무 상태를 알 수 없어 응답까지 걸릴 시간을 예측하기 어렵다.

이런 상황에서 “누구든 상대방이 지금 얼마나 바쁜지 한눈에 알 수 있는 기능이 있으면 좋겠다”는 생각이 들어 개발하게 됐다.
 

🪏 재구성 해보기

이 툴은 AI-DLC의 개념을 바탕으로 개발했고 그 과정을 재구성해보았다.

Inception (기획 및 설계) (예시)

# Role Senior PM
당신은 경험많고 숙련된 PM입니다. 
지금부터 요구사항을 바탕으로 시스템 설계를 리드하시고 유저스토리를 만드세요.

...

# Project Intent: "바쁘군"
- 배경: 팀 내/외 업무 가시성 부족으로 발생하는 협업 병목 현상 해결
- 핵심 아이디어: 구성원들이 자신의 현재 업무 상태(바쁨 정도)를 실시간으로 어필하고 공유하는 시스템
- Backlog API에서 현재 자신에게 할당된 여러 프로젝트의 티켓 개수를 가져오는 API를 사용해 활성화된 티켓 수를 확보
- 이후 해당 티켓 수와 유저가 커스텀하게 설정한 임계값에 따라 슬랙 이모지가 변경이 됨
  - 예시 : 처리중인 티켓 수 3개 이하 바쁘지 않음, 4 - 5 바쁨, 5 이상 매우바쁨 이모지)
- 백로그 티켓이 자동으로 업데이트 되어야 하며 이를 위해 서버 기능이 필요(아이디어 제시해주세요)
...
- 모든 결정에 있어 상의가 필요하면 Question을 만들고 Answer를 확정 지을 수 있도록 작성하세요.

# Your Mission (AI-DLC Protocol):
- Backlog API 사용 권한 및 범위 파악
- Slcak API 사용 권한 및 범위 파악
- 티켓 수 파악 및 슬랙 이모지 변경을 위한 이벤트 트리거 아이디어 제시
- 문제점 등 제시
...

주의 사항
절대 독단적으로 설계를 확정하지 마십시오.
보안사항에 문제가 되는 코드나 텍스트를 멋대로 기록하지 마세요.
...

• 먼저 AI에게 문제 상황과 배경을 설명하고, 이를 바탕으로 유저 스토리와 기획안을 작성하도록 한다.
• 이 단계에서 가장 중요한 것은 프롬프트 설계다.
• 단순히 결과물을 요청하는 것이 아니라, AI에게 명확한 역할을 부여하고 하나의 팀원처럼 개발을 주도하도록 설계하는 것이 핵심이다.
  • 이를 위해 프롬프트에는 다음과 같은 원칙을 명시했다.
    AI가 독단적으로 결정을 내리지 않도록 하고, 인간의 판단이 필요한 부분은 반드시 Question 형태로 정리하여 인간과 논의할 수 있도록 한다.
  • 또한 체크박스 등을 활용해 어떤 선택이 확정되었는지를 문서로 남기도록 요구했다. 이 과정을 통해 기획 단계에서의 의사결정 흐름과 맥락이 자연스럽게 기록된다. 이 문서는 향후 AI가 프로젝트를 이해할 때 지속적으로 사용된다.
• 이렇게 생성된 기획서의 Question 섹션에는, 내가 미처 고려하지 못했던 요소나 추가 조사가 필요한 항목들이 정리되어 있었다.
  • 예를 들어, 별도의 서버를 운영하지 않으면서도 스케줄러나 이벤트 트리거를 활용해 API 요청을 처리할 수 있는 방법을 제시해 달라고 요청했는데, 크롬 확장 프로그램을 활용하는 방안을 제시해줬다.
• 브라우저가 실행 중이어야 한다는 제약은 있었지만, 추가 비용 없이 요구사항을 충족할 수 있는 현실적인 대안이었다.
• 또한 Backlog의 티켓 수를 기준으로 Slack 상태를 업데이트하기 위한 이벤트 트리거 방식에 대해서도 세 가지 선택지를 제시받았고 모두 채택했다.
  • 버튼 클릭을 통한 수동 업데이트
  • 백로그 과제 상태 변경 시 API 호출을 감지하고 실시간 업데이트
  • 크롬 브라우저가 스케줄러 역할을 수행하여 일정 주기로 업데이트

크롬 확장 프로그램은 브라우저 실행이 전제되지만, 업무 중 브라우저를 띄우지 않는 경우는 드물기 때문에 실제 사용성에는 큰 문제가 되지 않았다.

Construction (구축) (예시)

# Role: Senior Software Architect & Engineer
당신은 아키텍처를 설계하는 전문가이자 숙련된 시니어 개발자입니다. 
'바쁘군'의 Intent와 기술적 결정사항(크롬 확장 프로그램 기반)을 바탕으로 유닛별로 `xxx_unit_plan.md`을 작성하세요.

# Project Intent: "바쁘군"
- 목적: 백로그 티켓 수에 따른 슬랙 상태(이모지) 자동 업데이트
- 기술 스택: Chrome Extension (Manifest V3), Service Worker, Backlog API, Slack API
- 특이사항: 별도 서버 없이 브라우저 스케줄러(chrome.alarms)를 서버 역할로 활용
...

# xxx_unit_plan.md 작성 규칙
1. **독립성:** 각 Unit은 서로 느슨하게 결합되어 독립적으로 빌드 및 테스트가 가능해야 합니다.
2. **응집도:** 하나의 Unit은 하나의 명확한 비즈니스 로직(예: 외부 API 통신, UI 설정 등)만 담당합니다.
3. **체크박스:** 단계별 진행 상황을 추적할 수 있도록 마크다운 체크박스 형식으로 작성하세요.
4. **결정 보류:** 보안 방식이나 상세 트리거 주기 등 모호한 부분은 'Question'으로 남겨 나의 승인을 받으세요.

# Unit 별 정의
- Unit 1: [Core] Backlog & Slack Connector (Service Worker 기반 API 브릿지)
- Unit 2: [UI] Configuration Manager (팝업 UI 및 임계값 저장 로직)

# Output 요구사항:
먼저 `unit_plan.md` 파일을 작성하고, 이 계획을 실행하기 위해 내가 결정해줘야 하는 질문을 
각 실행 단계 하단에 리스트업 하세요. 질문에 대한 내 답변이 있어야만 다음 단계로 진행할 수 있습니다.
절대 독단적으로 설계를 확정하지 마십시오.
보안사항에 문제가 되는 코드나 텍스트를 멋대로 기록하지 마세요.

• Inception 단계에서 의도와 주요 기술적 방향이 합의되었다면, 다음 단계는 이를 실제 구현 단위로 분해하고 구축하는 단계다.
  • Construction 단계에서도 핵심은 인간은 승인과 선택에만 집중하는 구조를 유지하는 것이다.
• 이 단계에서 AI에게 부여한 역할은 단순한 코드 생성기가 아니라, 시니어 아키텍트이자 개발자였다.
• 프롬프트를 통해 AI에게 명확한 책임과 제약을 부여했다.
  • AI는 ‘바쁘군’의 Intent와 이미 합의된 기술적 결정 사항(크롬 확장 프로그램 기반, 서버 미사용)을 바탕으로, 전체 시스템을 여러 개의 Unit으로 분해하고 이를 문서(xxx_unit_plan.md)로 정리하도록 요청받았다.
• 이때 명시한 핵심 원칙은 다음과 같다.
  • 각 Unit은 서로 느슨하게 결합되어 독립적으로 개발·테스트 가능해야 한다.
  • 하나의 Unit은 하나의 명확한 비즈니스 책임만을 가진다.
  • 진행 상황과 결정 내역을 추적할 수 있도록 마크다운 체크박스를 활용한다.
  • 인간의 개입이 필요한 요소는 설계에 포함하지 말고 반드시 Question으로 남긴다.
• 이를 바탕으로 시스템을 다음과 같은 단위로 분해했다.
  • Core Unit: Service Worker를 중심으로 Backlog API와 Slack API를 중계하는 핵심 로직
  • UI Unit: 크롬 확장 팝업을 통한 임계값 설정 및 사용자 설정 관리

 
중요한 점은, 이 단계에서도 AI가 스스로 설계를 확정하지 않았다는 것이다. 각 Unit 설계 하단에는 반드시 인간의 판단이 필요한 질문이 함께 정리되었고, 그에 대한 답변이 확정되어야만 다음 단계로 진행할 수 있도록 했다. 이를 통해 AI가 설계부터 개발까지 주도하되, 결정과 책임은 인간에게 남겨두는 구조를 유지했다.
 
 이후에는 각 Unit별로 세부 구현 계획을 나누어 진행했다. Unit 단위로 작업을 쪼개면서, 코드와 테스트 역시 각 Unit에 대응해 생성되었고, 덕분에 전체 시스템을 한 번에 구현하는 것이 아니라 작고 검증 가능한 단위로 빠르게 반복할 수 있었다.
 
Operation은 툴 특성상 자동 배포나 운영 자동화가 필요하지 않아 생략했다.
 

😮 단 2일 만에 완성

• 크롬 확장 프로그램 경험 없음
• Backlog / Slack API 사용 경험 없음
• 타입스크립트 / 리액트 경험 부족

그럼에도 이틀 만에 완성할 수 있었다.
심지어 MVP에 포함되지 않았던 기능까지 추가했다.

• 초록(안 바쁨), 노랑(바쁨) , 빨강(매우 바쁨)을 표현하는 이모지를 디자인 후 슬랙 이모지로 등록하여 사용
• 휴식 모드 쉬고싶군 추가
  • 원버튼으로 자동 업데이트 기능 정지 및 슬랙에 휴식 및 부재중 이모지로 변경

 

😌 후기

AI-DLC를 도입했을 때는

• 사고와 제안은 AI가 한다
• 결정은 인간이 한다

 이 구조 덕분에 개인적으로는 속도와 안정성을 동시에 확보할 수 있었다. 문제를 만나도 선택지가 필요한 지점을 Question 형태로 명확히 제시해 주었고, 그에 대해 AI와 논의하고 판단하는 흐름이 자연스럽게 유지되었다. 특히 “아, 이건 그냥 내가 직접 다 처리하는 게 빠르겠다”라는 피로감이 상대적으로 줄어들었다. 조금 과장하면, 아이언맨의 토니 스타크가 자비스와 함께 개발하는 느낌에 가까웠다.
 
 이번 경험을 통해 AI-DLC와 같은 방식이 앞으로 우리가 마주하게 될 개발의 새로운 패러다임이 될 수 있겠다는 생각이 들었다. AI-DLC는 감각적 접근만으로는 통제하기 어려운 복잡하고 규모 있는 작업에서 특히 효과를 발휘할 수 있는 방법론이라고 생각한다.
 
사이드 프로젝트라도 좋으니, 한 번쯤은 AI-DLC 방식으로 개발해 보길 권한다. 막무가내로 “만들어줘”라고 부탁하는 것보다 훨씬 효율적이고, 배울 수 있는 것도 많을 것이다.
 
 
 

참고
https://prod.d13rzhkk8cj2z0.amplifyapp.com/
https://aws.amazon.com/ko/blogs/tech/ai-driven-development-life-cycle/