바이브 코딩 앱은 왜 폐기되는가 — 오늘의집 Data Playground가 추측을 없애는 세 겹

바이브 코딩으로 만든 사내 앱은 왜 폐기될까요. 코드가 안 돌아서가 아니에요. 오늘의집이 관찰한 실패는 두 종류였어요. 데이터에 붙지 못해 한 번 만들어진 뒤 버려지거나, 인증과 권한을 풀지 못해 끝내 사내에 올리지 못하거나. 노트북을 들고 와서 "이런 화면을 만들었는데 어디에 배포하죠? 왜 회사 데이터랑 연결이 안 될까요?"라고 묻는 사람들이 수십 명이었고, 같은 실패가 수십 개 앱에서 되풀이됐어요. Lovable이나 Vercel 같은 도구는 공개 웹까지는 빠르게 데려가지만 사내망과 사내 인증 안쪽으로는 못 들어오고, 정작 필요한 Athena 데이터와 실험 플랫폼 XPC의 결과와 사내 Google Sheets는 전부 그 안쪽에 있으니까요. 데이터에 붙지 못한 화면은 스크린샷과 다를 게 없다는 게 이 팀의 진단이에요.

이 팀이 만든 Data Playground를 저는 기능 목록으로 읽지 않았어요. 원리 하나로 읽었어요. AI가 추측할 여지를 구조적으로 없앤다. 원문의 표현으로는 "AI에게 줄 수 있는 최고의 컨텍스트는 제약"이에요. 빈 바닥에서 AI는 프로젝트 구조를 상상하고 라이브러리를 고르고 인증을 어떻게 붙일지 추측하는데, 그 추측이 늘어날수록 시행착오가 늘어요. 그래서 이 플랫폼은 추측이 생기는 자리를 세 겹으로 막아요. 블록, 틀, 문. 하나씩 풀어볼게요.

첫 번째 겹, 블록 — 미리 깔아둔 연결

업무용 도구를 만들 때 사람이 원하는 건 발명이 아니라 결과물이에요. 캠페인 대시보드를 만들려는 마케터에게 필요한 건 FastAPI 라우팅 설계나 Docker 멀티스테이지 빌드가 아니라 어제 집행한 캠페인의 매출과 전환율이 화면에 뜨는 것. 그 사이의 모든 것은 조립될 블록이지 매번 만들 대상이 아니라는 게 이 팀의 생각이에요.

그래서 Athena 쿼리, LLM 호출, Google Sheets 읽기·쓰기, Slack 봇, Airflow 트리거, 사내 인증 같은 커넥터를 전부 공용 모듈로 깔아뒀어요. 구성원이 만드는 앱은 한 줄로 사내 데이터에 연결되고, 인증도 네트워크 경로도 자격 증명도 각 앱이 다루지 않아요. 대시보드처럼 단순한 앱은 Python조차 필요 없어요. HTML 템플릿 안에서 `athena.widget()`으로 데이터를 쿼리하고 그 결과에 `ai.widget()`으로 해석 한 문단을 붙이면 끝이고, 위젯은 페이지가 뜬 뒤 각각 채워지며 의존 없는 위젯끼리는 병렬로 돌고 하나가 실패해도 나머지는 영향이 없고 쿼리 캐시가 자동으로 붙어요. Athena가 뱉는 SQL 에러는 "테이블을 찾을 수 없습니다" 같은 한국어 안내로 바뀌고요.

이 겹이 하는 일은 AI가 "어떻게 연결하지"를 추측하지 않게 만드는 거예요. 연결 방법이 하나뿐이면 추측할 게 없거든요. 그리고 부수 효과가 하나 있어요. 실행 방식과 캐시와 오류 처리가 공통 계층에 있으니, 공통 계층을 고치면 그 위의 모든 앱이 같이 좋아져요. 도메인 지식은 앱에 담기고 운영 품질은 플랫폼에 쌓이는 분리인데, 저는 이게 이 플랫폼에서 가장 잘한 설계 결정이라고 봐요.

두 번째 겹, 틀 — 고정된 스택과 골격

블록만으로는 부족했어요. 블록이 끼워지는 틀, 즉 기술 스택 자체를 하나로 고정했어요. 백엔드는 Python과 FastAPI, 프론트엔드는 HTMX와 Jinja2. HTMX는 HTML 속성만으로 동적 상호작용을 처리하는 라이브러리라 복잡한 클라이언트 상태 관리는 어렵지만, 지금까지 만들어진 사내 도구 대부분은 그 표현력으로 충분했다는 거예요. 사용자가 직접 짜는 코드는 어떤 데이터를 가져올지 정하는 백엔드 쿼리와 그걸 어떻게 보여줄지 정하는 템플릿, 둘뿐이에요.

틀은 AI 쪽에서 더 크게 작동해요. 앱은 늘 같은 디렉토리 구조로 시작하고, 빈 폴더가 아니라 이미 동작하는 골격에서 출발하고, Athena 연결이나 승인 플로우 같은 공용 모듈 패턴이 코드 예시와 함께 문서로 정리돼 있어요. "매출 대시보드 만들어줘"라고 하면 /new-dashboard 스킬이 어떤 골격에서 시작할지, 커넥터를 어떤 패턴으로 붙일지, 무엇을 확인할지 정해진 규칙대로 코드를 만들고, 확신이 없으면 추측하는 대신 "매출은 orders 기준일까요, payments 기준일까요?"라고 되물어요. 고칠 게 없어지면 린트와 테스트와 로컬 기동 확인을 돌리고, 전부 통과하면 dataplay publish가 서버에 커밋을 대행해서 몇 분 뒤 사내 URL이 나와요. 배포 뒤에는 /add-page, /deploy, /troubleshoot가 같은 루프를 이어가고, /dashboard-polish는 완성된 대시보드에서 개선점을 찾고, AI가 혼자 못 푸는 문제는 맥락을 담아 Data Platform 팀에 이슈로 가요. 무언가를 만드는 일은 결국 Build, Ship, Feedback의 반복이고 만드는 일의 대부분이 이 패턴 안에서 되풀이된다는 게 이 팀의 전제인데, 그 반복의 매 단계에 AI가 참조할 것이 미리 놓여 있다는 점이 하네스의 실체예요. 처음부터 끝까지 사용자가 한 일은 자기 업무를 설명한 것뿐이라는 문장이 과장이 아닌 이유죠.

HTMX를 고른 것도 이 겹의 일부라고 봐요. AI가 잘 짜는 것과 사람이 읽고 검토할 수 있는 것을 동시에 만족하는 스택이거든요. 프론트엔드 프레임워크를 자유롭게 두면 AI는 매번 다른 걸 고르고, 검토하는 사람은 매번 다른 걸 읽어야 해요. 틀을 고정하면 그 비용이 0이 돼요.

배포도 틀에 들어가요. apps/ 아래에 디렉토리 하나를 만들고 코드를 넣으면 그 폴더가 사내 URL을 가진 서버가 돼요. 안쪽에서는 앱마다 독립된 컨테이너로 배포되고 Gateway가 요청을 라우팅하고 새 디렉토리가 생기면 파이프라인이 자동으로 인식하지만, 사용자에게 보이는 건 폴더와 URL뿐이에요. 코드를 고치면 수십 초 안에 반영되고 이미지 재빌드는 약 3분. 재무 담당자가 결산 도구를 만들면서 Git rebase 충돌을 해결해야 한다면 설계가 실패한 거라는 문장이 이 팀의 기준이고, 그래서 CLI 경로에서는 서버가 사용자 대신 커밋까지 해요. 비개발자에게 가장 인기 있는 경로가 그거고요. 경로는 세 개를 열어뒀어요. Dataplay new로 스캐폴드하고 preview로 미리 보고 publish 한 번으로 배포하는 CLI, new-app으로 스캐폴드한 뒤 직접 commit과 push를 하는 개발자용 GitHub 경로, 로컬 세팅조차 부담스러운 사람을 위해 브라우저에서 파일을 올리고 편집하는 Web 경로. 어느 길로 만들었든 같은 플랫폼 위에서 같은 방식으로 배포되고 운영돼요.

틀이 갖춰지면 프롬프트가 복잡해질 수 있어요. 원문이 든 예가 이거예요. "한 달 넘게 구매가 없는 고객을 추려서 재구매 캠페인을 Braze를 통해서 보내고, 결과는 정리해서 Slack으로 알려주고 발송 기록도 Database에 남겨줘." 고객 추출, 캠페인 발송, 결과 보고, 데이터 저장. 시스템 네 개를 가로지르는 요청인데 사용자가 보낸 지시는 한 문장이에요. 이게 가능한 건 AI가 똑똑해서가 아니라 네 시스템으로 가는 길이 전부 블록으로 깔려 있고 골격이 정해져 있어서예요. 추측할 자리가 없으니 긴 지시도 틀리지 않는 거죠.

세 번째 겹, 문 — 앱 밖으로 나간 인증

누구나 만들 수 있게 하면서 안전을 지키는 게 가장 어려웠다고 이 팀은 써요. 만드는 사람이 늘수록 인증을 빠뜨리거나 권한 밖의 데이터를 노출하거나 감사 추적이 빠질 가능성도 늘어나니까요. 답은 안전을 사용자가 신경 쓰는 게 아니라 플랫폼이 구조적으로 보장하는 것으로 만드는 거였어요. Data Playground 안에서 앱을 만드는 사람은 인증 코드를 한 줄도 쓰지 않아요. Gateway가 BFF로서 모든 요청의 인증과 접근 제어와 감사 로그를 앱 코드가 실행되기 전에 처리하고, 팀 리더가 권한 화면에서 "이 앱은 우리 팀만"이라고 설정하면 그 팀 밖의 사람은 접근이 막혀요. 모든 쿼리는 사내 쿼리 서비스를 경유하면서 사용자 식별 정보가 요청마다 함께 가고, 재무나 인사처럼 민감한 데이터는 별도 자격 증명이 필요한 전용 워크그룹으로 격리했어요. 플랫폼이 생겼다고 원래 못 보던 데이터가 새로 열리지는 않는다는 원칙이에요.

이 문이 있어서 앞의 두 겹이 성립해요. 인증이 앱 안에 있으면 AI는 매번 인증을 추측해야 하고, 그 추측이 틀리면 사고예요. 인증을 앱 밖으로 빼는 순간 AI가 만드는 코드에서 가장 위험한 부분이 사라져요. 사내 도구의 인증이 있어야 할 자리는 여기 하나뿐이라고 저는 봐요.

핸드오프가 사라지면 무엇이 달라지나

세 겹이 갖춰지면 사람이 하는 일이 바뀌어요. 예전에는 도메인을 가장 잘 아는 사람이 요청서를 쓰고, 도메인을 덜 아는 사람이 만들고, 검수에서 어긋남이 발견되고, 수정을 요청하고, 다시 검수했어요. 컬럼 하나 추가하는 10분짜리 변경이 대기열을 거치면 며칠이 걸리고, 우선순위에서 밀리면 아예 안 만들어졌고요. 이 팀은 그 구조의 문제가 각 단계의 속도가 아니라 핸드오프 자체라고 봤어요.

결과는 숫자로 나와 있어요. 두 명이 만든 플랫폼 위에서 5개월 동안 18개 팀의 100여 명이 272개의 앱을 만들었고, 커밋은 10,230회를 넘었고, 전사 구성원의 75% 이상이 매달 접속해요. 대부분 개발자가 아닌 사람이 만들었고요. FP&A 팀의 결산 허브는 38단계 체크리스트와 예측 변동 자동 감지와 Slack 알림을 한곳에서 돌리고, 마케팅 디자인팀은 카카오톡 캐러셀과 라이브 배너와 프로모션 빌더를 AI 카피 추천과 배경 제거까지 붙여서 만들었고, Logistics 팀은 Slack에서 접수되는 CS 민원을 칸반으로 관리하고, 커머스기획 팀은 Power BI에 있던 직매입 사업 대시보드를 옮겨왔어요. 광고 팀 운영자는 매체별 성과 대시보드를 직접 만들고 API 토큰 주입만 요청했고요. 검색 팀에서는 팀원이 검색 결과 비교 도구를 직접 만들어 사내에 올렸어요.

여기에 이 팀이 말한 복리 구조가 하나 있어요. 각 팀이 도구만 만드는 게 아니라 도메인 지식을 플랫폼에 넣는다는 것. 한 팀이 올린 정책이나 기준이 블록이 되면 다음 사람은 그 위에서 시작해요. 블록이 늘수록 다음 앱의 추측할 자리가 더 줄어드는 구조라, 많은 사람이 뛰어놀수록 기반이 단단해진다는 말이 수사가 아니에요. 자유도를 제한하되 그 안에서는 무슨 일이든 할 수 있어야 한다는 게 이 팀의 Playground 정의고요.

그래서 다음 문제는 272개의 수명이다

이 플랫폼이 되는 조건은 글 안에 있어요. 사내 도구라는 것. 고객 대면 서비스였다면 이 안전 모델을 그대로 못 써요. 데이터 계층이 이미 정돈돼 있다는 것. 원문 스스로 "본질은 데이터"라고 했고, Athena와 XPC와 쿼리 서비스가 없었다면 블록을 깔 자리도 없었어요. 그리고 플랫폼 팀이 최종 장애 접수처를 감당한다는 것. /troubleshoot가 못 푸는 문제는 두 명이 만든 팀으로 가요.

제가 보기에 다음 문제는 여기서 나와요. 공통 계층은 플랫폼이 개선하지만 앱 안의 SQL은 만든 사람 거예요. 만든 사람이 팀을 옮기거나 테이블 정의가 바뀌었을 때, 그 대시보드의 숫자가 여전히 맞는지는 누가 보증하나요. 75%가 매달 본다는 건 그만큼 많은 결정이 그 숫자 위에서 내려진다는 뜻이고, 272개 중 몇 개가 살아 있고 몇 개가 조용히 틀린 숫자를 보여주고 있는지는 글에 없어요. 세 겹으로 만드는 문제는 풀었으니, 다음 겹은 만들어진 것의 수명이에요. 그게 없으면 핸드오프를 없앤 자리에 검증되지 않은 대시보드가 쌓여요.

바이브 코딩이 사내에서 실패하는 팀이라면 이 글을 도구 소개가 아니라 진단표로 쓰면 돼요. 우리 실패는 블록에서 막혔나, 틀에서 막혔나, 문에서 막혔나. 그 셋 중 하나라도 개인이 풀고 있다면 거기가 플랫폼이 시작될 자리예요.