AWS AI-DLC 기반 라포랩스 사내 배포 플랫폼 Raploy 구축 사례

​”비개발 직군도 자기 손으로 배포까지 해내는 환경을 어떻게 만들 수 있을까요?”​

라포랩스 AX팀은 AWS AI-DLC(AI-Driven Development Life Cycle) 방법론을 활용하여 사내 배포 플랫폼 Raploy를 구축했습니다. 2026년 2월 말 AWS와 함께 진행한 3일간의 AI-DLC 워크숍에서 Raploy의 뼈대를 만들었고, 이후 약 한 달간의 고도화를 거쳐 2026년 3월 중순 사내 서비스로 오픈했습니다.​

이 글에서는 라포랩스가 왜 AI-DLC를 선택했는지, 3일간의 워크숍에서 실제로 무엇을 경험했는지, 그리고 AI-DLC가 실제 프로젝트에서 어떤 효과를 가져왔는지를 공유합니다.​

라포랩스와 AX팀 소개

라포랩스는 4050 라이프스타일에 집중하는 커머스 기업입니다. 멋진 어른들의 라이프스타일링샵 퀸잇과 전국팔도 제철먹거리 장보기앱 팔도감을 운영하고 있으며, 두 서비스의 누적 다운로드는 1,400만 건, MAU는 280만 명을 넘습니다. 약 300명의 구성원이 라포랩스에서 함께 일하고 있으며, 그중 AX(AI Transformation)팀은 전사 AI 전환을 전담하는 조직입니다.​

AX팀의 미션은 구성원들의 모든 업무에 AI를 자연스럽게 녹여내는 것, 즉 단순히 기술을 도입하는 것이 아니라 일하는 방식 자체를 전환하는 것입니다. 이를 위해 AX팀은 실습 중심의 AI 교육, AI 에이전트 및 플랫폼 제공, 그리고 전사 파급이 큰 프로젝트에 대한 직접적인 빌드 서포트를 수행하고 있습니다.​

라포랩스 AX팀이 풀고 싶었던 문제

전사 AI 전환의 성과, 그리고 한계

​라포랩스 AX팀은 구성원이 AI를 바로 업무에 쓸 수 있는 환경을 만드는 데 집중해왔습니다. 복잡한 환경 세팅 없이 바로 시작할 수 있는 Google Apps Script를 전사에 적극 권장하고, 사내 어드민 인증과 LLM 호출을 위한 공용 라이브러리를 직접 개발하여 제공한 결과, 비개발 직군이 직접 업무 자동화를 수행하는 사례가 빠르게 축적되었습니다.​​

이 외에도 여러 사업팀이 자신의 도메인에 맞는 도구를 직접 만들어 사용하고 있습니다. 또한 AX팀은 슬랙 기반 AI 에이전트를 자체 개발하여 전사에 제공하는 등, AI 에이전트의 개발과 운영 경험을 축적해온 팀이기도 합니다.

그러나 이러한 성과가 빠르게 쌓이면서 세 가지 구조적 문제가 드러났습니다.

세 가지 벽

​Apps Script의 한계 실행 시간 6분 제한, 외부 API 호출 제약, 빈약한 라이브러리 생태계, 그리고 버전 관리와 협업의 부재로 인해 코드 추적이 불가능했습니다. AX팀 슬랙에는 “알 수 없는 오류”, “권한 오류”, “할당량 초과” 같은 문의가 지속적으로 인입되었습니다.​

난개발 PRD 없이 AI에 의존한 바이브 코딩이 누적되면서, 같은 구성원이 작성한 코드조차 매일 다른 패턴으로 생성되었습니다. AI 대화창에 코드를 복붙하며 작업하다 보니 매번 백지 상태에서 시작하는 셈이었고, 한 달 뒤 코드를 다시 열면 작성자 본인조차 이해하기 어려운 유지보수 불가능한 상태가 반복되었습니다.​

옵저버빌리티의 부재 Apps Script로 운영 중인 자동화가 실패해도 감지할 방법이 없었습니다. MD팀의 일일 패널티 알림 스크립트가 3일간 중단된 사실을 뒤늦게 발견한 사례, 카카오 오디언스 업로드 자동화가 4일간 실패한 사례가 발생했습니다. 로그 확인은 직접 들어가서 보는 수밖에 없는, “한 번 만들고 기도하는” 구조였습니다.​

정리하면, 비개발 직군의 소프트웨어가 빠르게 늘어나는데 이를 안정적으로 운영하고 관리할 체계가 없다는 것이 핵심 문제였습니다. 이를 해결하려면 배포 플랫폼으로 인프라 문제를, 하네스 엔지니어링으로 코드 품질 문제를 함께 해결해야 했습니다.​

AI-DLC, 왜 주목했나

하네스 엔지니어링이라는 개념

​2026년 초 하네스 엔지니어링(Harness Engineering) 이라는 개념이 주목받기 시작했습니다. AI 에이전트가 안정적으로 동작하도록 제약·피드백·인프라를 체계적으로 설계하는 것을 의미하며, 크게 세 가지 축으로 구성됩니다.​

Context Engineering — CLAUDE.md, 아키텍처 문서, API 스펙 등 에이전트가 참조할 컨텍스트를 코드베이스 안에 체계적으로 정리

Architectural Constraints — 결정론적 커스텀 린터·구조적 테스트로 아키텍처 경계를 기계적으로 강제하여, 에이전트가 규칙을 벗어나는 코드를 생성하지 못하도록 통제

Entropy Management — 시간이 지나면서 발생하는 문서 불일치·아키텍처 제약 위반을 주기적으로 탐지하여 코드 품질을 지속적으로 유지​라포랩스 AX팀이 마주한 “코드 일관성 부재”와 “옵저버빌리티 부재”는 하네스 엔지니어링이 해결하려는 영역과 겹쳤습니다.

다만 필요하다는 걸 아는 것과 실제로 시작하는 것은 다른 얘기였습니다.​

AI-DLC라는 출발점

​이때 발견한 것이 AWS가 공개한 오픈소스 개발 방법론 AI-DLC(AI-Driven Development Life Cycle) 입니다. AI-DLC는 AI 에이전트가 소프트웨어 개발의 전 라이프사이클을 수행할 수 있도록 설계된 프레임워크입니다. 기존의 바이브 코딩이 개발자의 직관과 단편적인 프롬프트에 의존한다면, AI-DLC는 구조화된 요구사항 정의와 룰 파일 기반의 일관된 코드 생성을 지원합니다.​

AI-DLC는 세 단계로 구성됩니다.​​

라포랩스가 AI-DLC를 선택한 가장 큰 이유는 재사용 가능한 룰 파일 세트와 단계별 산출물 가이드가 이미 패키지로 제공된다는 점이었습니다. awslabs/aidlc-workflows 저장소에서 룰 파일을 프로젝트에 적용하는 것만으로 AI-DLC 워크플로가 즉시 활성화됩니다. PRD 문서와 함께 AI 에이전트에게 요청하면, AI가 Inception부터 시작하여 질문 → 산출물 생성 → 검증의 사이클을 각 단계별로 순차적으로 진행합니다.​

AI-DLC는 하네스 엔지니어링의 세 가지 축을 그대로 실천할 수 있는 프레임워크이기도 합니다. Inception의 구조화된 문서가 Context Engineering을, Construction의 룰 파일이 Architectural Constraints를, Operations의 피드백 루프가 Entropy Management를 각각 담당합니다.

3일간의 AI-DLC 워크숍

​라포랩스 AX팀은 2026년 2월 23일부터 25일까지 3일간 AWS와 함께 AI-DLC 워크숍을 진행했습니다. 사내에서 이미 활용 중인 Claude Code를 사용했으며, 실습 대상으로는 앞서 정의한 “쉬운 배포 + 코드 일관성 + 옵저버빌리티” 문제를 해결할 사내 배포 플랫폼 Raploy를 선택했습니다. Raploy의 목표는 “배포를 몰라도 배포할 수 있다“ — 프로젝트 설정만 하면 자동으로 빌드·배포·모니터링이 이루어지고, 코드가 아닌 직관적인 화면에서 관리할 수 있는 환경을 만드는 것이었습니다.

워크숍에는 프론트엔드, 서버, QA, DevOps, AX팀 등 다양한 역할의 구성원이 참여했으며, 코드 생성은 대부분 AI 에이전트가 수행했습니다.​

Day 1 — Inception: 45개 질문을 통한 요구사항 구체화

​Inception 단계에서는 awslabs/aidlc-workflows 룰 파일과 Raploy PRD 초안만을 입력으로 시작했습니다. AI 에이전트는 PRD를 자동으로 분석한 뒤, 모호한 부분에 대해 구조화된 질문을 반복적으로 생성했습니다.​​

Inception 단계의 핵심 효과는 AI의 질문에 답하는 과정에서 요구사항의 모호성이 자연스럽게 제거된다는 점이었습니다. PRD 작성 시 명시적으로 고려하지 못했던 항목이 AI 질문을 통해 드러났고, 이 과정에서 User Stories와 유닛 구조까지 함께 확정되었습니다.

실제 대화에서 인상적이었던 장면 몇 가지를 공유합니다.

장면 1 — 서로 파고드는 질문

​ AI — “규모 예상치는 어떻게 되나요?”
사용자 — “예상치가 왜 중요한지 먼저 설명해주세요.”
AI — (이유 설명)
사용자 — “그런데 DB가 필요하다고 생각한 이유가 궁금합니다.”
​AI가 질문하면 사람이 역질문하고, AI가 설명하면 사람이 또 파고드는 양방향 대화가 이어지면서 요구사항이 점점 구체화되었습니다.​

장면 2 — 질문의 범위 자체를 되묻기

​AI — “환경변수 관리 도구가 있나요?”
사용자 — “이 시스템 자체의 환경변수를 말씀하시는 건가요, 아니면 Raploy에서 배포될 서비스의 환경변수를 말씀하시는 건가요?”​
AI가 답변 범위를 명확히 하도록 사용자가 먼저 개입한 순간입니다.​

장면 3 — 모르는 것은 AI에게 위임

​AI — “Ingress Controller는 어떤 것을 사용하시나요?”
사용자 — “잘 모르겠습니다. 관련 레포지토리를 읽고 파악해주세요.”​
실제로 AI는 레포 URL을 받아 코드를 직접 읽고 인프라 구조를 파악한 뒤 후속 질문을 생성했습니다.​

장면 4 — 일괄 수정과 일관성 검증

​사용자 — “Admin 기능을 없애주세요”
AI — Glossary · 요구사항 · User Story · Key Decisions 등 문서 7곳을 일괄 수정​
여기에 더해 6라운드 크로스 검증에서는 AI가 9개 문서의 불일치 11건을 스스로 발견·수정했습니다. Inception의 일관성 검증 효과를 보여주는 대표적인 사례입니다.​
동시에 한계도 드러났습니다. Inception이 예상보다 긴 시간을 요구하고, 결과물이 나오기 전까지는 진행 상황을 가시화하기 어렵다는 점입니다. 이 피드백은 이후 AX팀이 AI-DLC를 내재화하는 과정에서 개선 과제로 이어졌습니다.​

Day 2 — Construction: 3 Unit, 307개 테스트 케이스

​Construction 단계에서는 Inception에서 분해한 유닛별로 다음 4단계 사이클을 반복했습니다.​

Functional Design — 도메인 엔티티, 비즈니스 규칙, 로직 모델 확정
NFR Requirements — 성능·보안·확장성 기준 결정 및 기술 스택 의사결정 문서화
TDD Code Generation — 테스트 우선 설계, 룰 파일 기반 코드 생성
Build & Test — 전체 빌드와 테스트 통과, 사용자 직접 리뷰 및 UAT

​Raploy는 총 3개 유닛, 307개 테스트 케이스로 Construction을 진행했습니다.​​

Unit 1 완료 후, Unit 2와 Unit 3은 병렬로 개발되었습니다. Inception 단계에서 유닛 경계가 명확히 설계된 덕분에 병합 과정의 부담이 크게 줄었습니다. 다만 유닛 간 크기 불균형이나 스펙 누락(예: 크론 표현식의 자연어 허용 요구가 테크 스펙에 충분히 반영되지 않은 사례) 같은 이슈가 관찰되었으며, 이는 이후 보완되었습니다. 이 단계에서 라포랩스 AX팀이 체감한 핵심 교훈은 “AI-DLC는 빠르게 시작할 수 있지만, 100% 완성을 위해서는 보완 루프가 반드시 필요하다“ 는 점이었습니다.

Day 3 — 기존 프로젝트에 적용 가능한가: 브라운필드 검증

​Day 1-2에서 AI-DLC의 가능성을 확인한 뒤, Day 3에서는 “라포랩스의 기존 제품 프로젝트에도 AI-DLC를 적용할 수 있는가?” 를 검증하는 데 집중했습니다. 참여 구성원도 확대하여, 라포랩스 제품팀의 AD Squad(AX 전환 파일럿 스쿼드) 구성원이 이 날부터 합류했습니다.​

실습 대상은 기존 제품 코드베이스로, AI 에이전트가 코드를 읽고 구조·언어·의존성을 복원하는 브라운필드 리버스 엔지니어링을 진행했습니다. 기술적 사실 추출의 정확도는 높았지만, 도메인 히스토리와 과거 의사결정 맥락을 복원하는 데는 한계가 있음을 확인했습니다. 기존 코드에 요약 주석과 참조 문서를 보강하면 정확도가 올라간다는 것도 함께 확인했습니다.

​이를 통해 AI-DLC가 신규 프로젝트(그린필드)뿐 아니라 기존 코드베이스(브라운필드)에도 적용 가능함을 검증했습니다. Day 3은 AD Squad가 자체 제품 코드베이스에 AI-DLC를 적용하기 시작한 출발점이기도 합니다.​

Raploy 아키텍처

​3일간의 워크숍과 이후 약 한 달의 고도화를 거쳐 완성된 Raploy는, 비개발 직군이 프로젝트 설정만 하면 자동으로 빌드·배포·모니터링이 이루어지도록 설계되었습니다. 수작업을 플랫폼이 대신 처리하여 실수할 여지를 줄이는 것이 설계 원칙입니다.​

전체 흐름은 단순합니다. 사용자가 GitHub 저장소에 코드를 푸시하면 GitHub Actions가 컨테이너 이미지를 빌드하여 Amazon ECR에 업로드합니다. 이어서 Raploy는 배포에 필요한 설정(이미지 태그, 환경변수, 스케일 정보 등)을 raploy-config라는 별도의 GitOps 저장소에 기록합니다. 이 저장소가 “지금 어떤 서비스가 어떤 상태로 돌아가야 하는가”에 대한 단일 진실 공급원(single source of truth) 역할을 합니다.​

실제 실행 환경은 Amazon EKS 위에 구성되어 있고, ArgoCD가 raploy-config의 변경을 감지하여 EKS 클러스터에 자동으로 반영합니다. 별도의 배포 스크립트를 사람이 돌릴 필요가 없고, “저장소에 기록된 상태 = 클러스터의 실제 상태”가 플랫폼 차원에서 보장됩니다.​

운영 중에는 Grafana가 Raploy UI 안에 임베딩되어, 각 서비스의 로그와 메트릭을 배포 페이지에서 바로 확인할 수 있습니다. 장애나 배포 실패가 감지되면 Slack 채널로 즉시 알림이 전달되어, 앞서 문제로 지적했던 “한 번 만들고 기도하는” 구조가 해소됩니다.​

Day 3 이후: 더 잘 쓰게 하기 위해 한 것들

​워크숍 3일 차가 끝났을 때 Raploy는 “작동하는 골격”까지 도달한 상태였습니다. 이후 약 한 달간의 고도화를 거쳐 사내 서비스로 오픈했고, 오픈 이후 약 4주 동안 Raploy는 라포랩스 구성원들이 실제로 자기 도구를 올리는 플랫폼으로 자리잡았습니다.​​

사내 여러 팀에서 15개가 넘는 서비스가 Raploy 위에서 실제로 돌고 있고, 이들을 배포·운영하는 구성원의 절반 이상은 비개발 직군이거나 개발 이력이 많지 않은 담당자입니다.

Day 3 이후 라포랩스에서는 두 갈래의 작업이 나란히 진행되었습니다. 하나는 AX팀이 맡은 Raploy 자체를 사용자에게 더 매끄럽게 연결하는 일이었고, 다른 하나는 AD Squad가 맡은 AI-DLC를 라포랩스 맥락에 더 잘 맞는 방법론으로 발전시키는 일이었습니다.

Raploy를 발전시키기

​한 단계를 풀 때마다 다음 병목이 드러났고, 그 병목을 없애기 위한 작업이 순서대로 붙었습니다. 방향을 한 문장으로 정리하면 “Raploy를 사람이 혼자 쓰는 플랫폼에서, AI 에이전트가 사람을 대신해 쓰는 플랫폼으로 만들자“ 는 것이었습니다.​

1. 배포를 AI에게 맡기기 — 사내 AI 플랫폼에서 바로 Raploy 까지

​Raploy를 사내에 오픈하자마자 Apps Script 자동화를 Raploy로 이전하고 싶다는 요청이 빠르게 쌓였습니다. 그런데 “UI를 열고 레포를 연결하고 환경변수를 일일이 채운다”는 흐름 자체가 여전히 허들이었습니다. 배포 경험이 없는 사용자에게는 “어떤 값을 어디에 넣어야 하는지”부터 막막한 단계였고, AX팀은 같은 질문을 반복해서 받게 되었습니다.​

그래서 Raploy의 REST API를 먼저 정비하고, 이 API를 래핑하는 MCP 서버와 배포 플로우를 하나의 루틴으로 묶은 Claude 스킬(raploy-cronjob, raploy-nextjs)을 만들어 라쿠라는 라포랩스 사내 AI 플랫폼에 연결했습니다. Slack에서든 웹에서든 AI에게 “이 레포 배포해줘”라고 말하면, AI 플랫폼이 레포 코드를 분석해 프로젝트 타입·환경변수·크론 스케줄을 자동으로 추출하고 Raploy에 프로젝트를 생성한 뒤 Configuration 링크를 돌려줍니다.​

다만 AI 플랫폼의 웹은 사내 SSO를, Raploy는 워크숍 시점 그대로 Keycloak을 쓰고 있어서 AI가 건네준 링크를 열면 다시 로그인을 해야 하는 단절이 있었습니다. 그래서 Raploy의 인증 레이어를 better-auth로 교체해 AI 플랫폼 웹과 동일한 세션을 공유하도록 통합했고, 사용자는 별도 로그인 없이 AI와의 대화 흐름에서 바로 Raploy 배포·모니터링 UI로 이어지게 되었습니다.

​이 전환은 단순한 편의 기능이 아니라, 플랫폼의 주 사용자가 “사람“에서 “AI 에이전트“로 바뀌는 설계 변경이었습니다.​

2. 허들을 없애기 — Google OAuth Auth Broker

​AI 플랫폼에서 Raploy까지 흐름은 매끄러워졌지만, 막상 배포된 앱이 돌기 시작하자 또 다른 허들이 드러났습니다. 라포랩스의 비개발 직군 자동화는 대부분 Google Sheets·Drive·Gmail 같은 Google Workspace API에 의존하는데, Apps Script에서는 자동으로 처리되던 Google 인증이 Raploy로 이전하는 순간 “각 앱이 직접 OAuth 클라이언트를 만들고 토큰을 관리해야 하는” 숙제로 바뀌었기 때문입니다. 실제로 이 단계에서 이전 작업을 멈추고 AX팀에 도움을 요청하는 케이스가 반복적으로 발생했습니다.​

그래서 Raploy 플랫폼 차원의 Google OAuth Auth Broker를 도입하고, 배포된 애플리케이션이 몇 줄의 코드로 인증된 Google API 클라이언트를 받아 쓸 수 있는 @raploy/app-auth SDK를 제공했습니다. 사용자는 크레덴셜·토큰 갱신·권한 범위를 의식하지 않고, Raploy가 위임받은 Google 세션을 그대로 사용하여 Sheets를 읽거나 Drive에 파일을 올릴 수 있습니다. Apps Script에서 운영하던 자동화를 Raploy로 이전하는 작업이, 이제 “Google 인증을 어떻게 풀 것인가“라는 질문 없이 시작할 수 있게 되었습니다.​

두 단계의 공통된 효과는 “Raploy를 쓰기 위해 새로 배워야 하는 것을 최소화“ 하는 것이었습니다. AI 플랫폼은 이미 쓰고 있고, 세션은 공유되며, Google 인증은 Raploy가 대신 처리합니다. 배포라는 행위가 “AI에게 부탁하기”로 축약되면서, 워크숍에서 정의했던 “배포를 몰라도 배포할 수 있다“ 는 목표가 실제 일상으로 내려오기 시작했습니다.​

AI-DLC를 더 잘 쓰기 위해

​Raploy 구축에서 AI-DLC의 효과를 확인한 뒤, AI-DLC를 라포랩스 내부에서 더 폭넓게 쓰기 위한 후속 작업이 이어졌습니다.​

오픈소스 기여 — 문서 구조 개선 PR

​AI-DLC를 실제 프로젝트에 적용하는 과정에서 awslabs/aidlc-workflows 레포의 error-handling.md 파일에서 문서 구조상의 오류를 발견하여 수정 PR(#96)을 제출했고, AWS 오픈소스 메인테이너의 리뷰를 거쳐 머지되었습니다. AI-DLC를 사용하며 발견한 개선점을 다시 오픈소스로 돌려보낸 사례입니다.​

RAPID — 라포랩스 내부 구조에 맞춘 하네스

​AI-DLC의 룰 파일은 범용으로 설계되어 있어, 라포랩스의 실제 도메인·기존 코드베이스 구조·내부 개발 관습에 그대로 적용하기에는 간극이 있었습니다. 이 간극을 좁히기 위해 AD Squad는 RAPID라는 이름의 내부 하네스를 구축하고 있습니다. AI-DLC의 철학은 유지하되, 라포랩스의 기존 구조와 개발 관습에 더 잘 맞는 룰 파일·문서 구조·사이클로 재설계하고, 이를 AD Squad의 일상 개발 루틴에 녹이는 작업입니다.​

맺으며

​라포랩스는 AI-DLC를 통해 Raploy를 만들었고, 그 경험 위에서 사내 AI 플랫폼과의 통합, 그리고 라포랩스 맥락에 맞춘 RAPID 하네스 설계로 이어졌습니다. 한 번의 워크숍이 아니라 그 뒤로 이어진 수개월의 보완 루프가 실제 서비스 수준의 결과를 만들었다는 점이 가장 큰 배움이었습니다.​라포랩스 AX팀이 추구하는 다음 방향은 AI 에이전트의 자율성을 점진적으로 높여가는 것입니다.​​

현재 라포랩스는 Level 2에서 Level 3으로 이동하는 과정에 있습니다. AI-DLC의 Inception이 명확한 스펙을, Construction의 룰 파일이 테스트 경계를 제공하기 때문에, AI-DLC를 반복적으로 적용하며 하네스를 강화해가는 것이 Level 3에 도달하기 위한 라포랩스의 전략입니다.

AI-DLC가 한 번에 완성된 결과물을 만들어주지는 않습니다. 라포랩스의 경험에서도 워크숍 3일 만에 완성된 것이 아니라, 약 한 달간의 보완 루프를 거쳐 실제 서비스 수준에 도달했습니다. 하지만 “언제부터, 무엇을 기반으로 시작하면 될지” 에 대한 구체적인 출발점을 제공한다는 점에서, AI-DLC는 라포랩스에게 가장 실용적인 출발점이었습니다.

비슷한 고민을 하고 계신 팀이 있다면, awslabs/aidlc-workflows 레포에서 AI-DLC 룰 파일을 내려받아 PRD 한 장과 함께 시작해보시길 권합니다.

참고자료

• AI-Driven Development Life Cycle: Reimagining Software Engineering | AWS DevOps Blog
• awslabs/aidlc-workflows (GitHub)