셀트리온제약의 AI-DLC 방법론과 Kiro를 활용한 OMS 서비스 구축하기

셀트리온제약은 케미컬의약품과 바이오의약품을 국내외 시장에 공급하는 대한민국 대표 제약기업입니다. 셀트리온제약은 의약품 위탁 생산(Contract Manufacturing Organization, CMO)을 위한 관리, 공급망, 계약 업무를 하나로 연결하는 핵심 시스템인 OMS(Order Management System)를 새롭게 구축해야 했습니다. 프로젝트 착수 시점에 개발팀이 마주한 현실은 다음 한 문장에 압축되어 있습니다.

“3개월 안에 OMS를 출시해야 합니다. 외주를 주기엔 도메인 전달에만 시간이 걸리고, 내부에서 개발하기엔 Legacy 시스템 운영 업무와 동시에 신규 프로젝트로 OMS를 기획하고, 사용자와 협업하기엔 무리가 있어요.
더군다나, 프로젝트를 주도할 시니어 개발자도 부족합니다.”

일정은 촉박하고, 도메인은 복잡하며, 시니어 개발 리소스는 부족합니다. 동시에 구축할 제품은 내부 보안 감사 준수와 향후 발생할 수 있는 취약점까지 함께 고려해야 합니다.
이 상황에서 셀트리온제약 개발팀은 AWS가 제안한 AI 주도 개발 방법론인 AI-Driven Development Life Cycle(AI-DLC)를 적용하여 1일 파일럿과 3일 본 워크숍으로 OMS의 핵심 산출물을 만들어냈습니다. 대메뉴 5개, 서브메뉴 포함 16개 페이지, 46개 DB 테이블 규모의 제품을 기획, 개발, 현업이 한 테이블에 앉아 동시에 정의하고 설계했습니다.

이 글에서는 셀트리온제약이 왜 AI-DLC를 선택했는지, 3일간의 본 워크숍에서 실제로 무엇이 달라졌는지, 그리고 AI-DLC가 엔터프라이즈 제품 개발에서 어떤 효과를 가져왔는지를 공유합니다.

OMS 프로젝트의 제약 조건

프로젝트에는 다음과 같은 제약 조건이 있었습니다.

제약 조건	내용
일정	3개월 이내 개발과 출시
인력	시니어 개발자 부족, 내부 개발 리소스 제한
도메인	업무 전문성이 높아 외부 인력 투입 시 온보딩 부담이 큼
품질	엔터프라이즈 수준의 아키텍처와 디자인 요구
보안	내부 보안 감사 준수 및 향후 취약점 대응 고려

이 조건들은 서로 다른 방향에서 팀을 압박했습니다.
도메인 전문성이 높은 프로젝트를 외주로 진행하면 의약품 CMO 비즈니스 흐름과 정책을 외부에 전달하는 작업 자체가 또 하나의 프로젝트가 되고, 내부에서 진행하면 요구사항 명세 정리와 기획 분석에 많은 시간이 필요합니다. 기획 문서를 해석하고 확인하는 과정에서 커뮤니케이션 비용도 함께 발생합니다. 여기에 시니어 개발자가 부족한 상황에서 아키텍처와 디자인 품질을 확보해야 한다는 과제, 그리고 내부 보안 감사 기준과 출시 이후의 취약점 대응까지 설계 단계에서 고려해야 한다는 부담이 더해졌습니다.
이 문제들을 풀지 못하면 3개월이라는 기한은 품질과 보안을 타협해야 하는 선택으로 이어질 수 있었습니다.

AI-DLC, 왜 주목했나

AI-DLC는 AWS가 제안한 AI 주도 개발 방법론입니다. AI를 단순한 코드 보조 도구가 아니라 소프트웨어 개발 생명주기(Software Development Life Cycle, SDLC) 전 주기의 핵심 협업자로 위치시키고, awslabs/aidlc-workflows 저장소로 공개된 룰 파일과 단계별 산출물 템플릿을 통해 요구사항 분석부터 구현까지 일관된 흐름으로 연결합니다.

단계	목적	AI 역할	사람 역할
Inception	무엇을 왜 만드는지 정의	요구사항 분석, 명확화 질문, User Story 생성, Unit 분해	검증, 우선순위 결정, 최종 승인
Construction	어떻게 만들지 결정하고 구현	기능 설계, 코드와 테스트 생성	기술적 판단, 코드 리뷰, 품질 책임
Operation	운영 및 지속적 개선	배포 자동화, 모니터링 반영	운영 결정

셀트리온제약이 AI-DLC에 주목한 이유는 세 가지였습니다.

1. 즉시 시작 가능성: aidlc-workflows 저장소의 룰 파일을 프로젝트에 적용하는 것만으로 워크플로우가 활성화되어, 방법론을 배우는 데 드는 시간이 최소화됩니다.

2. 산출물의 템플릿화: 각 단계마다 명확한 산출물이 정의되어 있어, 비개발자도 지금 어디에 있고 무엇이 완성되어야 다음으로 넘어갈 수 있는지를 파악할 수 있습니다.

3. 세 역할의 자연스러운 협업: Inception 단계에서 기획, 개발, 현업이 한 테이블에 모여 맥락을 공유하게 됩니다. 별도 확인과 교차 확인으로 흩어지던 협의가 구조화된 대화로 바뀝니다.

Solution Overview

이번 프로젝트에서 AI-DLC는 OMS 전체 범위에 적용되었습니다.
대상은 대메뉴 5개와 서브메뉴를 포함한 16개 페이지, 46개 DB 테이블입니다. 도구는 AI 기반 IDE(통합 개발 환경)인 Kiro에 aidlc-workflows 룰 파일을 적용해 사용했습니다. 전체 범위는 관리 가능한 Unit 단위로 분해하고, 팀이 우선순위에 따라 진행 순서를 결정하는 방식으로 다뤄졌습니다.

Figure 1. Construction 단계에서 생성된 OMS Backend 아키텍처 문서 화면

워크숍은 두 번에 나눠 진행되었습니다. 먼저 1일 파일럿으로 방법론의 적합성을 검증하고, 2주 뒤 3일 본 워크숍에서 전체 범위를 다뤘습니다.

1일 파일럿: 가능성 검증

본 워크숍에 앞서 셀트리온제약은 1일 AI-DLC 파일럿을 먼저 진행했습니다. OMS 제품의 일부 기능(대시보드, 관리, 계약서 관리)을 대상으로 AI-DLC가 어떤 단계로 진행되는지를 실습한 것입니다.
이 하루는 단순한 맛보기가 아니라, 제한된 기간 안에 높은 품질의 제품을 만들 수 있는가라는 질문에 답을 얻는 자리였습니다. AI가 대화를 이어가며 산출물을 만들어내는 과정을 확인한 뒤, 팀은 3개월이라는 일정과 엔터프라이즈 품질을 동시에 달성할 수 있는 현실적인 경로로 AI-DLC를 선택했습니다.

3일 본 워크숍: 16개 페이지, 46개 테이블 규모의 제품을 한자리에서

워크숍에는 개발팀장, 개발 실무자, 그리고 사업 요청을 기획한 공급망관리팀 담당자까지 세 명이 한 팀으로 참여했습니다. 사업팀이 도메인 맥락을 제공하고, 개발팀장이 PO(Product Owner) 관점에서 판단을 내리고, 실무 개발자가 구현 가능성을 검토하는 구조가 AI의 질문과 답변 사이클 안에서 자연스럽게 만들어졌습니다.

Figure 2.워크숍 진행

Inception: 같은 테이블에서 함께 정렬해 간 요구사항

첫날의 주제는 “무엇을, 왜 만드는가”입니다. Inception 단계는 첫째 날 전체와 둘째 날 오전까지 약 1.5일에 걸쳐 진행되었습니다. AI는 PRD(Product Requirements Document, 제품 요구사항 문서)를 분석한 뒤 모호한 부분에 대해 구조화된 질문을 던졌고, 팀은 답하면서 요구사항을 구체화했습니다.

이때 AI의 질문은 개방형이 아니라 선택지 형태로 왔습니다. 예를 들어 User Story 분류 방식을 정할 때 AI는 Epic 기반, 페르소나 기반, 사용자 여정 기반이라는 세 가지 선택지를 예시와 함께 제시했고, 팀은 이를 비교해 Epic 기반을 선택했습니다. 권한 그룹 유형을 묻는 질문에는 “B이지만, 입력과 수정 권한만 분리되면 돼”처럼 짧은 답으로 방향을 확정할 수 있었습니다. 선택지에 답하며 진행하는 이 패턴 덕분에 AI 협업 경험이 없는 참가자도 세션의 흐름을 따라갈 수 있었습니다.

Figure 3. AI의 Clarifying Questions 화면

Inception의 User Story 검토 과정에서는 그동안 경험하지 못했던 협업의 장면이 나타났습니다. 기획과 실무 사이에서 미처 합의되지 못했던 지점들이 자연스럽게 드러난 것입니다.
예를 들어, 특정 페이지의 접근 권한이 다른 페이지의 업무 흐름과 연결되는 방식이나, 계약 관련 상태 전환 규칙과 공급망 처리 규칙 사이의 경계가 AI와의 질문과 답변 과정뿐 아니라 사업 기획자와 개발자가 한자리에서 함께 논의하며 풀어내는 과정을 통해 정리되었습니다. 이전에는 별도 확인 요청을 주고받으며 파편적으로 진행되던 대화가, AI-DLC 안에서는 같은 문서를 보며 실시간으로 정렬되었습니다.

생성된 User Story는 98개에 달했습니다.

다음은 그중 하나의 실제 예시입니다.

-	US-SYS-001: 사용자 로그인 (JWT)          
-	우선순위: Must
As a    User/Admin, I want  아이디와 비밀번호로 로그인하여 JWT 토큰을 발급받고 싶다
So that 인증된 상태로 OMS 시스템의 기능을 이용할 수 있다.
-	Acceptance Criteria (Given-When-Then 형식): 
Given 사용자가 로그인 페이지에 접속한 상태이다 (이하 생략)

이를 하나하나 검토하는 과정은 결코 가볍지 않았습니다. 해야 할 기능 자체가 많았고, 각 스토리의 수용 기준을 꼼꼼히 살피려면 상당한 시간이 필요했습니다. 팀은 이 구간을 힘들게 지나가면서도 품질을 위한 꼼꼼한 검토라는 점에서 의미를 찾았습니다. 이 단계에서 쌓인 디테일은 이후 구축 단계에서 하나의 맥락으로 다시 모이며 더 정교한 산출물로 이어졌습니다.

Figure 4.Inception 산출물 예시 (OMS Personas 문서, OMS User Stories 문서)

현업 담당자(공급망관리팀)의 회고는 이 변화를 잘 보여줍니다.

“사업팀처럼 개발 배경이 없는 저도 AI를 활용해 한글로 원하는 기능을 표현하고 실시간으로 결과를 확인하면서 개발 과정에 직접 참여할 수 있다는 점이 인상적이었습니다.”

개발팀장 역시 현업과의 소통 기회를 가장 큰 장점으로 꼽았습니다.

“평소 현업 담당자들과 이렇게 깊이 있게 대화할 기회가 많지 않은데, AI-DLC는 개발 과정에서 자연스럽게 협업하게 만드는 구조라서 굉장히 좋았습니다.”

실무 개발자는 의외의 부수 효과를 경험했습니다.

“개발자 입장에서 도메인 이해도가 약한데, Inception 과정을 지나면서 도메인 이해도가 높아진 느낌이 들었습니다.”

물론 한계도 있었습니다. User Story를 정의하다 보면 디테일에 몰입하게 되고, 과도한 엣지 케이스 고민으로 Inception이 길어지는 경향이 있었습니다. 적절한 수준에서 끊고 다음 단계로 넘어가는 판단이 중요하다는 것이 팀의 공통된 인식이었습니다.

Construction: 파편이 하나로 모이다

둘째 날 오후부터는 “어떻게 만들 것인가”로 초점이 이동했습니다. Inception에서 분해한 Unit별로 기능 설계, 도메인 모델, ERD(Entity-Relationship Diagram), API 스펙, 코드가 순차적으로 생성되었습니다.

개발팀장은 산출물의 품질에 놀라움을 표했습니다.

“산출물이 자동으로 생성되는 것이 좋고, 생각보다 굉장히 똑똑합니다. ERD 만드는 것도 그렇고, 분명히 스토리를 꼼꼼히 작성했지만 그래도 놓치는 부분이 있을 것이라 생각했는데, 출력되는 산출물의 품질이 놀라웠습니다.”

Figure 5. Construction 산출물 예시 (생성된 ERD 일부)

동시에 개선 포인트도 명확해졌습니다. AI-DLC는 진행 과정에서 30여 개에 달하는 markdown 파일이 산출물로 생성되는데, 이 많은 파일 안에서 AI가 추가로 역제안하는 내용과 사용자의 원래 요청사항이 섞여 있어 구분이 어렵다는 지적이 있었습니다. 이는 AI-DLC를 실무에 적용하려는 팀에게 좋은 피드백이 되었습니다.

실무 개발자는 AI-DLC 설계 자체에 대한 인상적인 통찰을 남겼습니다.

“어제 유저 스토리에 대해서 너무 많이 얘기하다 보니 기억이 흐려지고, 유닛 작성하면서 더 잊혀졌습니다. 그런데 기능 설계 단계에서 다시 기억들이 모아지는 게 좋았습니다. 끝으로 갈수록 파편된 기억의 퍼즐이 점점 모아지는 설계가 인상적이었습니다.”

이는 AI-DLC의 핵심 설계 철학을 정확히 짚어낸 관찰입니다. 각 단계가 다음 단계를 위한 맥락(context)을 누적하기 때문에, 뒷단계로 갈수록 산출물은 더 정교해집니다. Day 1에서 길고 힘들게 느껴졌던 User Story 검토가 Construction 단계에서 하나의 정합적인 설계로 수렴되는 경험이었습니다. 공급망관리팀은 Construction 단계에서도 사람의 역할이 여전히 결정적임을 체감했다고 회고했습니다. 스토리와 기능 설계 단계에서 역시 사람이 필요하다는 것입니다. 이는 AI가 실행하되 사람이 감독한다는 AI-DLC의 핵심 철학 그 자체입니다.

회고: 협업 역량의 재정의

마지막 날 팀은 AI와의 협업 자체가 새로운 역량이라는 점을 인식하게 되었습니다.

“Kiro에게 프롬프트를 던질 때 어떻게 가이딩을 줘야 할지, 세션은 어떻게 운영할지, 질문은 어떤 식으로 해야 할지 등 AI와 효과적으로 협업하기 위한 고민들이 필요하다는 것을 깨달았습니다. 그럼에도 불구하고 AI-DLC는 완전히 실무에 사용할 만한 수준입니다.” (개발 실무)

이 평가는 앞서 언급한 한계를 전제로 한 것입니다. Inception의 길이를 조절하는 판단과 산출물을 검토하는 부담은 여전히 사람의 몫으로 남으며, AI와의 협업 역량이 뒷받침될 때 방법론의 효과가 온전히 나타납니다.

개발팀장의 3일 차 회고는 이번 워크숍의 성과를 가장 잘 압축합니다.

“만들어야 할 제품의 완성도가 약 70%는 완성된 것 같습니다. 눈에 보이는 산출물뿐만 아니라 눈에 보이지 않는 공수 결과물들(예: 설계 문서, 아키텍처 다이어그램 등)이 심리적으로 든든합니다. Runbook 등 회사에서 요구하는 내용들도 이미 포함되어 있어, 이제 돌아가서 잘 마무리하면 좋은 결과가 있을 것 같습니다.”

이처럼 고객 팀은 3일간의 결과물을 제품 완성도 약 70% 수준으로 평가했고, 설계 문서, 아키텍처 다이어그램, Runbook(운영 절차 문서)까지 함께 확보했습니다. 3개월 일정과 품질에 대한 갈증을 동시에 풀 수 있겠다는 자신감을 팀에게 준 결과였습니다.

Figure 1. 워크숍 이후 실제로 구축된 OMS 서비스 화면

이번 워크숍에서 확인한 3가지 핵심 효과

첫째, 기획, 개발, 현업의 정렬이 워크플로우 안에서 이뤄집니다.
기존에는 기획 문서를 개발자가 해석하고 필요할 때마다 별도로 확인하는 방식이어서 커뮤니케이션 비용이 발생했습니다. AI-DLC의 Inception 단계는 세 역할이 같은 산출물을 보며 같은 질문에 답하는 구조를 만들어냅니다.

둘째, 템플릿화된 산출물이 진행 상황을 가시화합니다.
각 단계마다 명확한 산출물이 생성되기 때문에, 비개발자도 현재 팀이 어느 지점에 있고 무엇이 완성되어야 다음으로 넘어갈 수 있는지를 알 수 있습니다.

셋째, 눈에 보이지 않는 산출물이 심리적 안정감을 만듭니다.
코드뿐 아니라 설계 문서, ERD, 아키텍처 다이어그램, Runbook, NFR(Non-Functional Requirements, 비기능 요구사항) 정의 등 엔터프라이즈가 요구하는 부속 산출물이 함께 생성됩니다. 고객 팀은 이 문서들이 내부 보안 감사 대응에 필요한 문서 기반을 마련해 준다고 평가했습니다. 보안 요구사항이 별도 작업이 아니라 설계 단계의 산출물로 함께 다뤄진다는 점이 이 평가의 배경입니다.

배움: AI-DLC를 더 잘 쓰기 위해 필요한 것

셀트리온제약 팀의 회고는 AI-DLC를 실제로 도입하려는 조직에게 구체적인 힌트를 줍니다.

1. PO 역할에 대한 명확한 가이드가 필요합니다.
방법론의 각 단계가 얼마나 남았는지, 어느 수준까지 디테일하게 진행해야 하는지 판단하기 어려웠다는 피드백이 있었습니다. 단계별로 참가자가 무엇을 해야 하는지 안내하는 가이드가 보강되어야 합니다.

2. Inception의 길이를 통제하려면 그린필드와 브라운필드를 분리해 접근하는 방법이 있습니다.
98개의 User Story를 한 번에 다루다 보니 Inception이 길어지고 팀의 체력이 빠르게 소모되었습니다. 핵심 기능 일부를 먼저 그린필드(greenfield, 기존 시스템 없이 새로 시작하는 방식)로 진행해 제품의 뼈대를 만들고, 이후 나머지 기능을 브라운필드(brownfield, 기존 시스템 위에 확장하는 방식)로 더해 나갔다면 호흡을 더 잘 조절할 수 있었을 것입니다.

3. AI 협업 역량은 별도의 스킬입니다.
프롬프트 가이딩, 세션 운영, 질문 방식 등 AI와 효과적으로 협업하기 위한 고민이 축적되어야 AI-DLC의 효과가 극대화됩니다. 이번 워크숍에서는 앞서 소개한 것처럼 AI가 제시하는 선택지에 짧고 명확하게 답하며 방향을 확정하는 방식이 효과적이었습니다.

4. 산출물 구성의 가독성도 중요합니다.
30여 개에 달하는 markdown 파일 안에서 AI의 역제안과 원래 요청이 섞이는 지점, 여러 문서 사이를 오가는 탐색 피로는 도구와 워크플로우 양쪽에서 꾸준히 개선될 영역입니다.

맺으며

셀트리온제약은 AI-DLC를 통해 3개월이라는 일정, 엔터프라이즈 품질, 보안 감사 준수라는 세 목표 사이의 간극을 좁혔습니다. 1일 파일럿과 3일 본 워크숍만으로 고객 팀 스스로 완성도를 약 70%로 평가하는 수준의 결과물과 설계 문서, 아키텍처 산출물까지 확보했습니다.

더 중요한 것은 팀이 얻은 것입니다. 기획자와 개발자가 한 테이블에서 같은 언어로 이야기할 수 있게 되었고, 도메인 이해도가 낮았던 개발자가 자연스럽게 업무 흐름을 학습했으며, 개발 배경이 없는 현업 담당자가 직접 개발 과정에 참여할 수 있게 되었습니다. AI-DLC가 만든 것은 산출물뿐 아니라 팀의 새로운 협업 방식이었습니다.

짧은 일정 안에 엔터프라이즈 제품을 출시해야 한다면 AI-DLC를 출발점으로 삼아보시길 권합니다. awslabs/aidlc-workflows 저장소의 룰 파일을 내려받고, PRD 한 장과 함께 시작하면 됩니다. 그리고 기획자, 개발자, 현업 담당자가 같은 자리에 앉을 수 있도록 일정을 맞춰보세요. 셀트리온제약의 경험이 보여주듯, 가장 큰 변화는 같은 테이블에 앉는 것에서 시작됩니다.

참고자료

참고 자료

AWS 기술 블로그