AI의 역할이 단순 코드 생성을 넘어 요구사항 분석, 설계, 테스트까지 개발 라이프사이클 전반으로 빠르게 확장되고 있습니다. 올리브영 개발 조직 역시 AI를 개인의 생산성 도구가 아닌, 소프트웨어 개발 프로세스 전반에 녹이는 방법을 고민하고 있었습니다.

개발자가 AI를 선도적으로 잘 쓰는 것도 중요하지만, 팀 단위 또는 조직 전체가 AI와 체계적으로 협업하는 것은 전혀 다른 문제였습니다. 프로젝트마다 쌓이는 컨텍스트를 어떻게 구조화하여 축적할 수 있을지, 팀 간 사일로 없이 긴밀하게 협업하려면 어떤 프로세스가 필요한지, 무엇을 자동화할 것이고 어디까지 사람이 개입할 것인지, 엔터프라이즈급 품질을 보장할 수 있는 검증된 방법론은 없는지와 같은 질문은 나날이 늘어만 갔지만 구체적인 해답은 아직 없었습니다.

그래서 2026년 3월, AWS의 AI-DLC(AI-Driven Development Lifecycle) 방법론을 도입한 3일간의 집중 워크숍, Unicorn Gym에 도전해 보기로 했습니다.

Unicorn Gym이란, AWS가 고객사와 함께 특정 기술 주제를 단기간에 집중적으로 실습하는 몰입형 워크숍 프로그램입니다.

올리브영은 왜 AI-DLC에 주목했는가?

AI-DLC는 생성형 AI를 소프트웨어 개발 생명주기(SDLC) 전체에 통합한 방법론입니다. 저희는 올리브영 담당 AWS SA분들과의 미팅에서 자세한 내용을 접했는데요, 각 단계마다 AI와 사람의 역할이 명확히 정의되어 있고, 구조화된 산출물이 다음 단계의 입력으로 이어지는 체계적인 워크플로우였습니다. 특히 AWS 자체적으로 크고 작은 프로젝트를 통해 실험하고 검증한 결과 초기 설계 오류를 조기에 발견해 재작업하는 비중을 50% 가까이 줄였다는 점이 인상적이었고, 비즈니스가 급격히 커지면서 효율적인 프로덕션 출시 문화를 고민하던 저희 니즈와도 맞아떨어졌습니다.

AI-DLC 핵심 특징

• Inception Phase: 요구사항 분석, 사용자 스토리 작성, 애플리케이션 설계를 AI와 함께 수행
• Construction Phase: 기능 설계, NFR(Non-Functional Requirements) 분석, 인프라 설계, 코드 생성까지 AI가 지원
• Adaptive Workflow: 프로젝트 특성에 따라 필요한 단계만 선택적으로 실행
• Human-in-the-Loop: 중요한 의사결정 지점마다 사람의 승인을 거치는 안전장치

무엇보다 모호한 기능/비기능 요구사항을 정제하고, 구조화된 설계 문서를 기반으로 코드를 생성하는 일관된 워크플로우가 갖춰져 있다는 점이 가장 매력적이었습니다. 개발 경험에 관계없이 같은 품질의 출발선에 설 수 있겠다는 기대가 있었거든요.

AI-DLC에 대해 더 알고 싶으시다면, AWS Tech Blog에 공개된 AI-DLC 백서를 참고해 보셔도 좋겠습니다. 참고로 AI-DLC는 현재 Kiro 외에도 Amazon Q Developer IDE Plugin, Cursor, Cline, Claude Code, GitHub Copilot 등 다양한 AI 코딩 도구를 공식 지원하고 있습니다.

어떤 실무 과제를 선정하고, 어떤 의도로 실험했는가?

저희는 효과적인 워크숍을 위해 올리브영의 실제 비즈니스 과제 20여 건 중 5개를 사전 선정했습니다. 스탭 엔지니어와 DevRel 담당자가 AWS SA분들과 함께 고민한 끝에, 아래 기준으로 과제를 골랐습니다.

AI-DLC 워크숍 참여 과제 선정 기준

• AI-DLC 포맷과의 적합성: AI-DLC의 전 단계를 온전히 경험할 수 있는 과제
• 비즈니스 임팩트 및 생산성 향상 가능성: 워크숍 이후 실무에 연결될 수 있는 과제
• AI-DLC 특성상 효과가 제한적인 유형은 제외: 수만 라인 분석 시 컨텍스트 한계가 존재하는 PL/SQL 기반 대규모 레거시 분석 과제, 외부 디자인 도구와의 긴밀한 연동이 필요한 과제 등

최종적으로 Greenfield(신규 개발)와 Brownfield(기존 시스템 개선) 프로젝트를 모두 배치하여 다양한 시나리오를 실험할 수 있도록 했습니다. 그중 Brownfield 과제는 레거시 시스템의 현대화라는 올리브영 개발 조직의 실제 고민을 반영한 선택이었습니다. 단순히 레거시 코드를 새 스택으로 옮기는 것이 아니라, 레거시를 다루는 팀의 접근 방식 자체를 AI와 함께 바꿀 수 있는지를 실험하고 싶었습니다. AI-DLC의 Reverse Engineering 단계가 기존 코드베이스 분석에 얼마나 효과적인지 검증하려는 의도도 있었습니다.

과제	도메인	유형	내용
대화형 커머스 경험을 위한 AI 검색 엔진 고도화	커머스/검색	Greenfield	Inception에서 정의한 검색 의도 분류 체계를 기반으로, 3일 만에 동작하는 대화형 검색 프로토타입까지 도달
멀티모달 AI 기반 파트너 채널 자동 검증 시스템	마케팅/파트너	Greenfield	AI가 Inception 과정에서 서버리스 기반 순차 처리 아키텍처를 제안하여, 수작업으로 처리하던 검수 프로세스의 자동화 구조를 빠르게 설계
차세대 물류 운영 최적화를 위한 지능형 시뮬레이션 플랫폼	물류/SCM	Greenfield	도메인 전문가와 AI가 함께 시뮬레이터의 입출력 모델을 구조화한 것이 3일 내 작동하는 시뮬레이터 구축의 핵심 요인
장애 대응 및 보상 프로세스 자동화를 위한 AI 오케스트레이션	CS/운영	Greenfield	Inception에서 현행 프로세스의 AS-IS를 먼저 문서화하고 TO-BE 자동화 범위를 명확히 구분한 것이 4단계 자동화 파이프라인 구현으로 이어짐
Modern Stack 기반의 엔터프라이즈 관리 시스템 현대화 PoC	백오피스/레거시 전환	Brownfield	화면 난이도를 단계별로 분류하고 대표 화면을 AI 파이프라인으로 전환하며, 수작업 대비 전환 효율의 가능성을 검증

Unicorn Gym, 3일간의 여정은 어땠을까?

역삼 센터필드 EAST에 위치한 AWS Korea 교육장에 30여 명의 개발자, 데이터 엔지니어, 스탭 엔지니어, QA 엔지니어가 모였습니다. 참가자들은 과제의 성격을 고려해 자발적으로 팀을 선택했고, 워크숍에서는 Kiro를 AI 코딩 어시스턴트로 사용했습니다.

오프닝은 이번 워크숍의 방향성을 짚는 메시지로 시작되었습니다. AI를 활용한 개인의 코딩은 '경험'과 '이해'의 영역이지만, 조직이 진정한 생산성을 얻으려면 각자가 '빌더'로서 팀 단위의 협업 방식을 설계해야 한다는 것. 그리고 기술을 만드는 것 못지않게 어떻게 사용하고 내재화할 것인가가 중요해졌다는 것. 특히 코딩 단계에서 절약한 시간이 요구사항 분석이나 설계, 통합 등 SDLC의 다른 단계에서 오히려 낭비될 수 있다는 'AI 생산성 패러독스'와 같은 문제의식은 참가자들의 공감을 얻었고, AI-DLC를 3일간 집중적으로 경험해보자는 워크숍의 출발점이기도 했습니다.

Day 1: AI-DLC 방법론 이해와 Inception Phase

첫날은 AI-DLC의 전체 구조를 이해하고 Inception Phase에 집중하는 시간이었습니다. 오전에는 AI-DLC 방법론 소개와 함께 Kiro의 Steering 파일을 팀별로 세팅했습니다. Steering은 쉽게 말해 "AI에게 우리 팀의 일하는 방식을 알려주는 설정 파일"입니다. 여기에 AI-DLC 워크플로우 규칙을 등록하면, AI가 요구사항 분석부터 설계, 코드 생성까지의 단계를 일관된 프로세스로 따라갈 수 있게 됩니다. 나중에 돌이켜 보니, 이 세팅 시간이 이후 3일의 방향과 속도를 사실상 결정지었습니다.

오후부터는 본격적으로 Inception에 돌입했습니다. 각 팀은 자신의 프로젝트가 Greenfield인지 Brownfield인지 판단하고, 그에 맞는 워크플로우를 선택했습니다. Brownfield 과제 팀은 Reverse Engineering 단계를 추가로 수행하면서 기존 코드베이스를 AI가 자동으로 분석하고 문서화하는 과정을 거쳤습니다.

이어서 Requirements Analysis를 진행했습니다. 각 팀이 작성한 requirements.md 파일을 AI가 분석하고, 명확하지 않은 부분에 대해 질문을 던졌습니다. AI가 꼼꼼하게 질문을 던지는 방식은 참가자들에게 익숙하면서도 신선한 경험이었습니다. 미처 생각하지 못한 요구사항이나 실무적 제약사항을 AI가 상당히 많이 짚어주었거든요.

User Stories 작성에서는 AI가 요구사항을 바탕으로 초안을 생성하면, 팀원들이 비즈니스 로직을 반영해 수정하는 흐름으로 진행됐습니다. Application Design 단계에서는 컴포넌트 구조, 서비스 레이어, 의존성 관계를 AI가 제안하고 팀원들이 조정했습니다.

Day 2: Construction Phase와 실전 코딩

둘째 날은 본격적인 개발 단계였습니다. 그런데 막상 Construction Phase에 진입하려던 5개 팀 중 2개 팀은 Inception Phase를 다시 수행해야 했습니다. 전날 작성한 요구사항이 충분히 정제되지 않은 상태에서 설계로 넘어가니, AI가 생성하는 산출물의 방향이 의도와 어긋났기 때문입니다. 좋은 코드는 좋은 설계로부터, 좋은 설계는 요구사항의 이해에서부터 시작된다는 말처럼 Inception의 완성도가 이후 모든 단계의 품질을 좌우한다는 것을 몸소 체험한 순간이었습니다.

이후 Functional Design에서 데이터 모델, 비즈니스 로직, API 인터페이스를 정의하고, NFR Requirements 단계에서는 성능, 보안, 확장성 등 비기능 요구사항을 체계적으로 분석했습니다. 평소에는 "레이턴시 최소화", "수평 확장 가능한 구조" 같은 방향성 수준에서 지시를 끝내기 쉬운 부분인데, AI가 구체적인 지표와 목표치를 제안해주어 목표가 명확해졌습니다.

Infrastructure Design에서는 AWS 리소스 구성을 설계하고, 마지막 Code Generation 단계에서 실제 애플리케이션 코드를 생성했습니다. 이렇게 AI-DLC 덕분에 설계와 구현이 동시에 진행되는 경험을 할 수 있었는데, 단계별 통합 리뷰 프로세스를 통해 최소 품질 기준도 기대 이상으로 높아졌습니다.

Day 3: 통합 테스트와 회고

마지막 날 오전에는 Build & Test 단계를 거쳐 실제 동작하는 MVP를 완성했습니다. 완성도는 팀별로 차이가 있었지만 5개 팀 모두 AI-DLC의 전체 단계를 끝까지 경험했고, 오후에는 팀별로 간단한 결과 발표와 전체 회고 시간을 가지며 3일간의 워크숍을 마무리했습니다.

데모데이: 워크숍 이후 본격적인 검증

워크숍이 끝난 뒤에도 각 팀은 회사로 돌아와 유관관계자들과 결과물을 다듬는 작업을 이어갔습니다. 이후 동료들을 대상으로 데모데이를 개최하여 최종 결과물을 공유하고, 실제 동작하는 시스템을 시연했습니다. 발표 후에는 각 유닛과 팀의 리더들이 결과물의 프로덕션 적용 가능성과 기술적 방향에 대해 질의하고 피드백을 주고받았으며, AI-DLC를 실제 개발 프로세스에 어떻게 접목할 것인지에 대한 조직 차원의 논의가 이어졌습니다.

무엇을 확인했고, 어떠한 레슨런이 있었나

AI는 실행 도구가 아닌 사고의 파트너

이번 워크숍에서 가장 크게 확인한 것은 AI의 역할에 대한 재정의였습니다. AI가 단순히 코드를 생성하는 실행 도구가 아니라, 요구사항을 정제하고 설계 대안을 제시하며 놓친 부분을 짚어주는 사고의 파트너로 기능했습니다. 에이전트는 도구이고, 설계는 사람의 몫이라는 점이 참가자들의 회고에서도 두드러졌습니다. 한 참가자는 "구현뿐 아니라 설계도 AI가 정말 잘해줘서 놀랐고, 오히려 역으로 AI의 사고 흐름을 배워야겠다고 생각했다"고 회고했습니다.

바이브 코딩을 넘어 스펙 코딩으로

워크숍 전에는 "무조건 빠르게 AI한테 묻고 시키면 되지"라는 바이브 코딩 접근이 익숙했던 참가자들도 있었습니다. 하지만 AI-DLC를 거치면서, 요구사항 스펙을 먼저 정의하고 그 스펙에 기반해 AI와 협업하는 방식, 이른바 '스펙 코딩'의 가치를 체감했습니다. 요구사항 정의서부터 도메인 엔티티, 비즈니스 규칙, NFR 문서까지 코드와 동시에 생성되니, 설계 문서가 코드의 맥락을 설명해주는 탄탄한 구조가 만들어졌습니다. 한 참가자는 "이제는 결과에 대한 피드백보다, 과정에 대한 피드백을 통해 더 좋은 프롬프트를 만들어가는 게 중요하다는 걸 알았다"는 인사이트를 남기기도 했습니다.

구조화된 프로세스를 통한 역량 상향 평준화

AI-DLC의 단계별 프로세스를 따라가면, 경험이 적은 멤버도 일정 수준 이상의 설계 산출물을 만들어낼 수 있었습니다. 개인의 역량 편차와 무관하게 누구나 같은 프로세스로 협업할 수 있다는 것은 조직 차원에서 의미 있는 발견이었습니다. TPM 직무의 한 참가자는 "Inception 단계나 User story 작성법이 AI-DLC에 아주 정석 포맷으로 들어가 있어서, 올리브영 도입 시 전반적인 일 문화 성숙도 평균이 올라갈 것 같다"고 평가하기도 했습니다.

더 나아가 일부 팀은 표준 AI-DLC 워크플로우를 자신의 과제에 맞게 변형하여, 멀티 에이전트 파이프라인이나 커스텀 스킬 체인을 자체적으로 구축하기도 했습니다. Kiro의 Custom Agent 기능으로 설계용, 개발용, 문서 조회용 등 역할별 에이전트를 만들어 팀원끼리 공유한 팀도 있었습니다. 같은 에이전트를 쓰니 사람에 따른 산출물 편차가 줄어드는 효과가 있었습니다. 같은 방법론을 기반으로 하되, 프로젝트 특성에 따라 유연하게 적용할 수 있다는 점도 확인한 셈입니다.

Brownfield 프로젝트의 현대화 가능성 확인

Brownfield 과제로 선정한 엔터프라이즈 관리 시스템 현대화 PoC는 워크숍 기획 단계에서 가장 난이도가 높을 것으로 예상했고, 실제로도 가장 많은 시간과 리소스를 투입한 실험 과제였습니다. 이 팀은 단일 접근법이 아닌 여러 전환 방식을 병행 실험하며, 개선해야 할 시스템을 난이도별로 분류하고 기존과 동일한 테스트 결과가 도출되는지를 성공 기준으로 삼아 검증했습니다. AI-DLC의 Reverse Engineering 단계는 레거시 코드베이스를 자동으로 분석하고 문서화해주어, 레거시 이해에 드는 초기 비용을 크게 줄여주었습니다. 무엇보다 사람이 수동으로 전환하는 것 대비 AI 파이프라인을 활용한 마이그레이션이 유의미한 공수 절감 가능성을 보여준 것이 가장 큰 수확이었습니다. (정량적 검증은 후속 과제로 계속 실험하며 이어가고 있습니다.)

풀어야 할 숙제도 명확했다

워크숍이 모든 기대를 충족시킨 것은 아닙니다. 3일간의 집중 실험을 통해 저희가 해결해야 할 과제도 선명하게 드러났습니다.

AI 생성 문서의 관리

AI-DLC의 각 단계를 거치는 과정에서 방대한 양의 설계 문서가 생성되었습니다. 이 산출물들에 올리브영 특유의 비즈니스 규칙이나 도메인 지식을 이식하고 체계적으로 관리하며, 여러 프로젝트 및 조직의 코드 컨벤션과 일관성을 유지하는 방법에 대해 의견이 분분해 아직은 사내 기술 커미티의 아젠다로 오르내리며 최적의 방안을 모색 중입니다.

설계의 적정 깊이

과제마다 AI가 생성하는 설계의 적정 깊이를 조직 차원에서 어떻게 판단할 것인가도 과제였습니다. MVP 수준에서 AI가 멀티 리전 배포 전략까지 제안하는 경우처럼, 현재 필요한 수준과 AI가 제안하는 수준 사이의 갭을 조율하는 것은 결국 사람의 판단이 필요한데 아직 프로젝트 단계별 적정 깊이에 대한 가이드라인이 정립되지 않은 상태입니다. 이에 실무 적용 과정에서 함께 만들어가야 할 부분으로 인식하고 있습니다.

컨텍스트 관리의 기술

AI와 협업할 때 무엇을, 얼마나, 어떤 순서로 전달하느냐에 따라 산출물의 품질이 크게 달라졌습니다. 한 참가자는 "컨텍스트를 다 써보는 건 처음이었는데, 너무 긴 프롬프트가 좋지만은 않다는 것을 깨달았다"며 중간중간 압축하고 정리하는 것이 토큰 관리만큼 중요하다고 강조했습니다. 개인 차원에서는 시행착오로 터득할 수 있는 부분이지만, 조직 차원에서는 컨텍스트를 구조화하고 축적하는 방식 자체가 표준화되어야 팀 간 협업에서도 AI의 품질이 일정하게 유지됩니다. 어떤 정보를 requirements에 담고, 어떤 정보를 설계 문서에 분리하며, 언제 컨텍스트를 압축할 것인지 등의 판단 기준을 조직 공통의 가이드로 만들어가는 것이 다음 과제입니다.

그래서, 앞으로의 방향성은?

3일간의 워크숍은 끝났지만, 결과물을 실제 프로덕션에 적용하기 위한 논의는 계속되고 있습니다. 우선 별도의 AI 샌드박스를 신설했습니다. AI 활용 과제와 자체 스킬, 운영 디플로이 전의 결과물들을 사내 구성원들과 더 쉽고 안전하게 공유할 수 있는 공간으로 활용 중입니다. 이와 함께 사내 AI 프런티어 프로그램도 론칭 예정입니다. AI를 활용해 조직의 생산성과 일하는 방식에 실질적인 변화를 만들어내는 구성원을 인정하고 장려하는 제도입니다. 워크숍에서 경험한 AI 협업 문화가 일회성 이벤트에 그치지 않고 지속적인 동기 부여와 함께 조직에 뿌리내리길 기대하고 있습니다.

더 나아가, 워크숍의 대상을 개발자에서 PM으로 확대하는 후속 워크숍도 준비하고 있습니다. AI-DLC의 Inception Phase는 PM의 업무 영역과 직접 맞닿아 있기 때문입니다. 엔지니어뿐 아니라 모든 프로덕트 메이커가 AI와 진정한 협업을 할 수 있을 때, 비로소 조직 전체의 AI 내재화라고 부를 수 있을 것입니다. AI에 다소 보수적이었던 한 참가자가 "이번 경험을 통해 고정관념이 많이 깨졌다"고 회고한 것처럼, 변화는 이미 시작되었습니다.

그리고 AI 도구는 계속 진화할 것입니다. 하지만 AI-DLC와 같은 워크플로우가 조직 내부에 자리 잡기 시작하면, 팀과 역할의 경계를 넘어 하나의 프로세스로 협업하는 것이 정말로 가능해질 것이라 생각합니다. 올리브영은 AI와 함께 일하는 문화를 실험하고 조직에 뿌리내리는 첫걸음을 내딛은 상태입니다. 한 참가자의 말처럼 "물고기보다 낚시하는 법을 배운 셈"입니다. 상세한 AX 경험담과 기술적 디테일은 앞으로도 공유해 나아갈 예정이니 많은 관심 부탁드립니다. 감사합니다.