누구나 바이브 코딩(Vibe coding)으로 앱을 만드는 시대가 됐습니다.
만드는 속도가 빨라졌지만, 만들어진 앱이 실제로 쓰이는 것은 다른 문제였습니다. 오늘의집에서도 데이터에 붙지 못해 한 번 만들어진 뒤 폐기되거나, 인증과 권한을 풀지 못해 끝내 사내에 올리지 못하는 서비스가 생겼습니다. 비슷한 어려움이 수십 명이 만든 수십 개 앱에서 되풀이되고 있었습니다.
“비슷한 시도와 실패가 계속 발생하는데 어떻게 해야 할까?”
“모두가 바닥부터 새로이 만들 필요가 있을까?”
우리는 모두가 바닥부터 더 잘 만드는 방법이 아니라, 아무도 바닥부터 만들지 않아도 되는 환경을 만들기로 했습니다. 반복되는 시도는 플랫폼이 맡고, 사람들은 각자의 문제를 푸는 데 집중할 수 있게 하기로 했습니다.
바이브 코딩을 위한 오늘의집의 공용 플랫폼, Data Playground를 소개합니다.
어디에 배포하지?
많은 분들이 보통 노트북을 들고 오셔서 이런 질문을 합니다.
“이런 화면을 만들었는데 어디에 배포하죠? 왜 회사 데이터랑 연결이 안 될까요?”
구성원들의 바이브 코딩 과정을 살펴보니, 넘어야 할 산이 크게 두 가지로 보였습니다.
1. 배포하는 일. 배포를 어디에 해야 하나.
AI와 함께 화면을 만들긴 했는데, 이걸 어디에 올려서 팀에게 보여줄 것인가. 사내에 서비스 하나를 띄우려면 GitHub 권한, 배포 환경 세팅, 도메인, 인증 연동까지 넘어야 할 게 많았습니다. 결국 Lovable 같은 상용 솔루션을 시도하거나, 정적 파일로 캡처해 공유하는 선에서 끝났습니다.
2. 데이터와 연동하는 일. 배포는 했는데 왜 아무것도 안 보이나.
어렵게 배포까지 했다고 해도, 정작 사내 데이터에는 닿지 못했습니다. Lovable이나 Vercel같이 AI로 앱을 만들어 주는 도구는 많습니다. 이런 도구들은 공개 웹까지는 빠르게 데려가주지만, 사내망과 사내 인증 안쪽으로는 들어오지 못합니다. Athena에 쌓인 실제 데이터, A/B 실험 플랫폼 XPC의 실험 결과, 사내 Google Sheets 등 정작 업무에 필요한 건 전부 그 안쪽에 있기 때문입니다.
데이터에 붙지 못한 화면은 정적인 스크린샷과 본질적으로 크게 다르지 않았습니다. 만든 것이 UI에서 끝나지 않도록. 데이터와 연동되지 못한 앱이 데이터와 만나 빛을 발하도록 플랫폼을 만들기로 했습니다.
발명이 아니라 조립
무언가를 만드는 일의 대부분은, 있는 블록을 가져다 조립하는 일입니다.
업무용 도구를 만들 때 사람들이 실제로 원하는 건 ‘새로운 것을 발명하는 경험’이 아니라, 당장 필요한 결과물입니다. 캠페인 대시보드를 만들려는 마케터에게 필요한 건 FastAPI의 라우팅 설계나 Docker 멀티스테이지 빌드가 아니라, 어제 집행한 캠페인의 매출과 전환율이 화면에 뜨는 것입니다. 그 사이에 있는 모든 것은 조립되어야 할 블록이지, 매번 처음부터 만들 대상이 아닙니다.
기업 안에는 이미 좋은 블록이 많습니다. Athena에는 전사 데이터가 있고, XPC(실험 플랫폼)에는 실험 결과가 있고, Slack으로는 알림을 보낼 수 있고, Airflow로는 배치 작업을 돌릴 수 있습니다. 이 자산들은 따로 떨어져 있을 때보다 서로 연동될 때 훨씬 큰 시너지를 냅니다. 문제는 그 연동 자체가 어렵다는 데 있었습니다. 모두가 바닥부터 인증을 붙이고 커넥터를 짜야 했으니까요.
그래서 Data Playground가 택한 방향은 단순합니다. ‘블록을 미리 깔아두고, 사용자는 조합만 하게 한다’
Athena 쿼리, LLM 호출, Google Sheets 읽기·쓰기, Slack 봇과 Airflow 트리거, 사내 인증 등등. Data Playground 안에는 이러한 커넥터들이 모두 공용 모듈로 들어 있습니다. 구성원이 만드는 앱은 한 줄로 사내 데이터에 연결됩니다. 인증도, 네트워크 경로도, 자격 증명도 각 앱이 직접 다룰 필요가 없습니다. 이 요소들이 플랫폼 내부의 공용 계층으로 캡슐화되어 있기 때문입니다.
블록을 깔아두는 것으로는 부족했습니다. 블록이 끼워지는 틀, 그러니까 기술 스택 자체도 하나로 고정했습니다.
Data Playground에서 만드는 앱은 전부 같은 기술 스택을 씁니다. 백엔드는 Python과 FastAPI, 프론트엔드는 HTMX와 Jinja2입니다. HTMX는 HTML 속성만으로 동적인 상호작용을 처리하는 라이브러리입니다. 아주 복잡한 클라이언트 상태 관리는 어렵지만, 지금까지 만들어진 사내 도구의 대부분은 이 정도 표현력으로 충분했습니다.
이 플랫폼은 새로운 프레임워크가 아닙니다. 이미 있는 사내 자산을 조립 가능한 블록으로 정리하고, 그 조립을 쉽게 만든 레이어일 뿐입니다. 사용자가 직접 짜는 코드는 어떤 데이터를 가져올지 정하는 백엔드 쿼리와, 그걸 어떻게 보여줄지 정하는 프론트엔드 템플릿입니다. 사용자가 신경 쓸 것은 도메인 지식의 영역뿐이고, 그 바깥은 플랫폼과 AI에게 맡기면 됩니다.
Python조차 필요 없게
대시보드 같은 단순한 애플리케이션 제작에 있어서는 Python조차 필요 없게 인터페이스를 설계했습니다. HTML 템플릿 안에서 `athena.widget()`으로 사내 데이터를 쿼리하고, 그 결과에 `ai.widget()`으로 해석 한 문단을 붙이면 됩니다.
{# Athena 쿼리 결과를 표로 렌더링하고, 결과 행을 rows로 넘겨 줍니다 #}
{{ athena.widget("sales", "SELECT date, revenue FROM mart.daily_sales WHERE date >= :start") }}
{# 그 rows를 그대로 LLM에 넘겨 해석을 한 문단 붙입니다 #}
{{ ai.widget("insight", user="이 매출 추이를 세 줄로 요약해줘: " + rows|tojson) }}
위젯은 페이지가 먼저 뜬 뒤 각각 채워집니다. 의존이 없는 위젯끼리는 병렬로 돌고, 하나가 실패해도 나머지는 영향이 없으며, 쿼리 캐시가 자동으로 사용됩니다. Athena가 뱉는 SQL 에러조차 “테이블을 찾을 수 없습니다” 같은 사용자 친화적인 한국어 안내로 바뀌어 나옵니다. 살아 있는 사내 데이터 대시보드 하나가 코드가 아닌 템플릿 몇 줄이 됩니다.
이 인터페이스의 가치는 도메인 로직과 운영 복잡성을 분리하는 데 있습니다. 사용자는 어떤 데이터를 가져와 어떻게 보여줄지만 템플릿에 적습니다. 실행 방식과 캐시, 오류 처리는 플랫폼의 공통 계층에서 일관되게 관리됩니다. 공통 계층이 개선될 때마다 이를 사용하는 모든 앱에 같은 개선이 반영됩니다. 도메인 지식은 각 앱에 담기고, 운영 품질은 플랫폼에 축적됩니다.
AI가 가장 잘하는 일을, 더 잘하게
"지난달 대비 증감이 보이게 매출 대시보드 만들어줘."
이 한 문장 안에 데이터 연결, 차트 구성, 비교 로직이 들어 있습니다. 이것을 동작하는 앱으로 만들려면 코드를 쓰고, 배포하고, 피드백을 받아 다시 고쳐야 합니다. 무언가를 만든다는 일은 결국 Build, Ship, Feedback의 반복이고, 만드는 일의 대부분이 이 패턴 안에서 반복됩니다.
AI에게 줄 수 있는 최고의 컨텍스트는 ‘제약’이었습니다. 빈 바닥에서 AI는 프로젝트 구조를 상상하고, 라이브러리를 고르고, 인증을 어떻게 붙일지 추측합니다. 추측이 많아질수록 시행착오가 늘어납니다. Data Playground는 각 단계에서 그 추측의 여지를 없앴습니다.
Data Playground Harness
Build: 한 줄의 문장으로 동작하는 앱이 만들어집니다.
"매출 대시보드 만들어줘." 프롬프트에 따라서 /new-dashboard와 /new-app Skill이 수행됩니다. Skill에는 어떤 골격에서 시작할지, 커넥터를 어떤 패턴으로 붙일지, 무엇을 확인해야 할지 정해져 있고, AI는 그 규칙을 따라 코드를 생성합니다. 확신이 없으면 추측하는 대신 역질문을 수행합니다. "매출은 orders 기준일까요, payments 기준일까요?" 미리보기가 뜨면 사용자는 말로 고칩니다. "금액 컬럼도 보여줘."
Ship: 통과하면 서버로 배포합니다
고칠 것이 없어지면 AI가 린트, 테스트, 로컬 기동 확인을 돌립니다. 하나라도 실패하면 바로잡고 다시 돌립니다. 전부 통과하면 dataplay publish가 서버에 커밋을 대행하고, 몇 분 뒤 사내 URL이 나옵니다.
Feedback: 배포 뒤에도 같은 루프
"요약 페이지도 하나 만들어줘"라고 말하면 /add-page가, "배포됐어?"라고 물으면 /deploy가, "왜 안 돼?" 하면 /troubleshoot가 동작합니다. /dashboard-polish는 완성된 대시보드에서 개선점을 찾습니다. AI가 혼자 해결할 수 없는 문제는 전체 맥락을 담아 Data Playground를 담당하는 Data Platform팀에 이슈로 보냅니다.
세 단계 모두에서 AI는 미리 놓인 것들을 참조합니다. 앱은 늘 같은 디렉토리 구조로 시작하고, 빈 폴더가 아니라 이미 동작하는 골격에서 출발하며, Athena 연결이나 승인 플로우 같은 공용 모듈 패턴이 코드 예시와 함께 문서로 정리되어 있습니다. 처음부터 끝까지 사용자가 한 일은 자기 업무를 설명한 것뿐입니다.
이런 사이클이 갖춰지면, 프롬프트는 점점 복잡해질 수 있습니다.
"한 달 넘게 구매가 없는 고객을 추려서 재구매 캠페인을 Braze를 통해서 보내고, 결과는 정리해서 Slack으로 알려주고 발송 기록도 Database에 남겨줘."
고객 추출, 캠페인 발송, 결과 보고, 데이터 저장. 네 개의 시스템을 가로지르는 요청이지만, 사용자가 보낸 지시는 한 문장뿐입니다.
개발자의 프로세스, 몰라도 됩니다
바이브 코딩을 시도하는 대부분의 구성원은 Commit, Pull, Push, Branch, Docker, Pull request가 무엇인지 알고 싶어 하지 않습니다. 알 필요도 없어야 합니다. 재무 담당자가 결산 도구를 만들면서 Git rebase 충돌을 해결하는 법을 배워야 한다면, 그건 설계가 실패한 것입니다.
플랫폼이 생겼으니, 처음부터 끝까지 쉬워야 합니다.
그래서 폴더 하나가 서버가 됩니다.
apps/ 아래에 디렉토리를 하나 만들고 코드를 넣으면, 그 폴더가 사내 URL을 가진 서버가 됩니다. 안쪽에서는 앱마다 독립된 컨테이너로 배포되고, Gateway가 요청을 라우팅하고, 새 디렉토리가 생기면 배포 파이프라인이 자동으로 인식합니다. 사용자 입장에서 보이는 건 폴더와 URL뿐이고, 그 사이의 Kubernetes, 이미지 빌드, 배포 파이프라인은 감춰져 있습니다.
속도도 이 DX(Developer Experience)의 일부입니다. 코드를 고치면 수십 초 안에 실행 중인 서버에 반영되고, 이미지 재빌드는 약 3분 안에 뒤따릅니다. ‘직접 만들고 고친다’는 감각이 끊기지 않아야, 사용자가 포기하지 않고 계속 고칠 수 있습니다.
만드는 경로도 하나로 강요하지 않습니다. 사람마다 익숙한 환경이 다르기 때문에, 세 가지 길을 열어 두었습니다.
- CLI: Dataplay 커맨드라인 도구. Dataplay new로 스캐폴드하고, Dataplay preview로 로컬에서 미리 보고, Dataplay publish 한 번으로 배포합니다. Git을 전혀 모르는 사용자를 위해, 서버가 사용자를 대신해 Commit을 수행합니다. 비개발자에게 가장 인기 있는 경로입니다.
- GitHub: Make new-app으로 스캐폴드하고 직접 commit·push하는, 개발자에게 익숙한 경로입니다.
- Web: 브라우저에서 파일을 올리고 편집하는, 로컬 환경 세팅조차 부담스러운 사용자를 위한 경로입니다.
어느 경로를 만들었든, 결과물은 같은 Data Playground라는 플랫폼 위에서 같은 방식으로 배포되고 운영됩니다. Data Playground를 쓰는 사람은 기존의 복잡한 개발·배포 절차를 직접 다루지 않아도 됩니다.
우리는 Data Playground 위에서 DX와 SDLC를 재정의하고 추상화해야 했습니다. 개발자든, 개발자가 아니든, Git을 알든 모르든, Git에 권한이 있든 없든 간에 누구나 이해할 수 있는 개발 경험을 고민하고, 제공했습니다.
누구나 만들 수 있게 하면서 안전을 지키는 것이 가장 어려웠습니다. 만드는 사람이 늘어날수록 인증을 빠뜨리거나, 권한 밖의 데이터를 노출하거나, 감사 추적이 빠질 가능성도 늘어납니다. 그래서 안전은 사용자가 신경 쓰는 것이 아니라, 플랫폼이 구조적으로 보장하는 것이어야 했습니다.
Data Playground 안에서 앱을 만드는 사람은 인증 코드를 한 줄도 작성하지 않습니다. Gateway가 BFF(Backend for Frontend)로서 모든 요청의 인증, 접근 제어, 감사 로그를 앱 코드가 실행되기 전에 처리합니다. 앱을 플랫폼에 등록하는 순간, 이 모든 것이 자동으로 붙습니다. 특히 팀 리더가 권한 관리 화면에서 ‘이 앱은 우리 팀만’이라고 설정하면, 해당 팀 소속이 아닌 사람은 해당 앱에 접근할 수 없어 안전합니다.
데이터 조회도 같은 원칙입니다. 모든 쿼리는 사내 쿼리 서비스를 경유하고, 사용자 식별 정보가 요청마다 함께 전달됩니다. 하지만 재무, 인사 데이터처럼 민감한 영역은 별도 자격 증명이 필요한 전용 워크그룹으로 격리했습니다. Data Playground가 생겼다고 해서, 원래 못 보던 데이터가 새로 열리지는 않습니다.
자유도를 제한하되, 그 안에서는 무슨 일이든 할 수 있어야 합니다. 말 그대로 Playground입니다.
그렇게 이뤄낸 일들
두 명이 만든 플랫폼 위에서, 100여 명의 사용자가 272개의 앱을 만들었고, 전사 구성원의 75% 이상이 월마다 접속하고 있습니다. 단순히 만든 것에서 끝나는 게 아니라 실제 업무에 계속 사용할 수 있는 페이지나 서비스로 활용되고 있는 것입니다.
"결산 마감 진행 상황이랑 예측 성과를 팀이 함께 볼 수 있게 만들어줘.”
FP&A(Financial Planning & Analysis)팀이 만든 결산 허브입니다. 38단계 체크리스트, 예측 변동 자동 감지, Slack 알림까지 한 곳에서 운영합니다. 담당팀이 적극적으로 개선하고 자주 업데이트하면서 매일 사용하는 앱 중 하나입니다.
"마케팅팀이 배너, 카드, 프로모션 이미지를 만들고 저장할 수 있는 빌더를 한 곳에 모아줘."
마케팅 디자인팀이 만든 캠페인 에셋 빌더 4종입니다. 단순 작업을 자동화한 것이 아니라 마케터가 유연하게 이미지를 제작할 수 있는 툴을 직접 만들어 배포했습니다. 카카오톡 캐러셀, 라이브 배너, 프로모션 빌더가 하나의 앱 안에 있고, AI 카피 추천과 배경 제거까지 붙어 있습니다.
"CS 민원을 Slack에서 접수하면 자동으로 쌓이고, 상태를 추적할 수 있는 칸반을 만들어줘."
Logistics팀이 만든 CS 접수 시스템입니다. Slack 워크플로에서 쌓이던 민원이 자동 저장되고, 칸반 보드에서 접수부터 완료까지 관리합니다.
"상품 매출, 이익, 인기 상품, 재고를 한 화면에서 보고 싶어."
커머스기획 팀이 Power BI에서 이관한 직매입(1P) 사업 성과 대시보드입니다. 매출 추이, 사업부별 이익, 상위 상품, SCM 재고 현황을 실시간으로 모니터링할 수 있습니다.
일하는 구조의 전환
과거 무언가를 만드는 일은 수많은 손을 거쳐가는 일이었습니다. 각 단계마다 사람이 바뀌고, 사람이 바뀔 때마다 대기가 발생합니다. 이 구조의 문제는 각 단계의 느린 속도가 아닙니다. 핸드오프(Handoff)라는 구조 자체입니다.
먼저, 사람이 병목이 됩니다. 한 명이 여러 팀의 요청을 받으면, 그 사람의 일정이 곧 모든 요청의 일정이 됩니다. 요청의 상당수는 컬럼 추가나 필터 변경 수준이지만, 대기열을 한 번 거치면 10분짜리 변경에 며칠이 걸립니다. 우선순위에서 밀리면 아예 만들어지지도 않습니다.
또한, 일을 주고받는 과정에서 맥락이 유실됩니다. 도메인을 가장 잘 아는 사람은 요청서를 쓰고, 실제 만드는 사람은 그 도메인을 덜 알고 있습니다. 검수에서 어긋남이 발견되고, 수정을 요청하고, 수정본을 다시 검수합니다. 일을 주고받는 왕복에 며칠이 소모됩니다.
우리는 이 구조를 재정의하고 핸드오프를 없앴습니다. 이제는 생각한 사람이 생각을 제품으로 만들어내고, 필요한 것을 만들어 사용합니다. 현업이 AI와 함께 직접 만들고, 그날 배포합니다. 플랫폼이 데이터 연결, 배포, 인증을 대신 처리하므로 사용자는 도메인 지식만 가져오면 됩니다. 요청서도, 대기 줄도, 핸드오프도 없습니다.
위에서 보여드린 사례 외에도 팀 내 많은 변화가 일어나고 있습니다. 검색 팀에서는 팀원이 검색 결과 비교 도구를 직접 만들어 사내에 올립니다. 커머스기획 팀은 Power BI에서 관리하던 대시보드를 이관하고 있습니다. 광고 팀에서는 운영자가 매체별 성과 대시보드를 만들고 API 토큰 주입만 요청했습니다.
각 팀은 도구를 만들 뿐 아니라, 도메인 지식을 플랫폼에 넣습니다. 한 팀이 올린 정책이나 기준이 블록이 되면, 다음 사람은 그 위에서 시작합니다. 많은 사람이 뛰어놀수록 더 단단해지는 기반, 이렇듯 Data Playground는 오늘의집의 수많은 팀이 일하는 방식을 바꿔가고 있습니다.
우리는 AI Enabler입니다
시대가 정말로 변했습니다. 그 변화가 각 조직에서 실제로 일어나고 있습니다.
본질은 데이터입니다. AI는 코드를 쓰고 화면을 그리지만, 어떤 데이터가 어디에 있고 누가 무엇을 볼 수 있고 무엇이 진실인지를 정하는 것은 데이터입니다. 데이터가 정돈되어 있지 않으면 AI는 빈 바닥에서 추측할 뿐입니다.
데이터 플랫폼은 오랫동안 그 길목에 있었습니다. 원천 데이터, 카탈로그, 쿼리 서비스, 인증. 사람들이 데이터로 무언가를 만들려면 결국 거쳐야 하는 것들입니다. 구성원이 너무 많은 길목에서 헤매지 않도록, 우리는 쿼리를 직접 짤 필요가 없도록 위젯 하나로 데이터를 연결하고, 배포를 몰라도 되도록 폴더 하나가 서버가 되게 하며, 인증을 신경 쓰지 않아도 되도록 플랫폼이 대신하는 데 집중했습니다.
5개월 동안 18개 팀에서 100여 명의 사용자가 272개의 앱을 만들었고, 커밋은 10,230회를 넘었습니다.
대부분 개발자가 아닌 사람들이 만든 것입니다.
우리는 AI를 통해 조직이 데이터를 다루는 방식을 바꾸는 팀이고, 실제 변화로 이어질 수 있는 기반을 만듭니다. 이제, 더 많은 팀이 더 복잡한 문제까지 직접 풀 수 있도록 그 기반을 넓혀가려 합니다.
