Codex로 “처음에는 만들 수 없다”던 수억 원 규모 서비스의 뼈대를 세웠다

Codex로 수억 원 규모 서비스의 뼈대를 세우다

한줄 요약

모든 매출·지출·원가 데이터를 연결해 외식업 사장의 의사결정을 돕는 거대한 서비스를, 비개발자인 제가 AI와 함께 실제 매장 데이터부터 기능 하나씩 나누어 만들기 시작했습니다. 3박 4일 워케이션 중 23시간 4분을 투입해 데이터 통합, 사람 검수형 AI 분류, 메뉴 원가 구조, ERD, 실제 매출 분석 화면까지 연결했습니다.

바쁘시면 이것만 읽어도 돼요:

• 작은 홈페이지가 아니라, 기존 방식으로 전체 범위를 외주 개발하면 수억 원 규모까지 커질 수 있는 제품에 도전했습니다.

• 전문가도 모든 데이터의 자동 수집과 모든 의사결정을 첫 MVP에 담는 것은 불가능하다고 진단했습니다.

• AI에게 제품 전체를 한 번에 맡기지 않고 비전 → 문서 → 데이터 → 기능 → 검증 순서로 쪼갰습니다.

• 실제 매장 데이터를 연결한 매출 상세·캘린더·메뉴 순위·카테고리 분석 화면을 만들었습니다.

• AI의 지출 분류를 무조건 믿지 않고 확정·추천·보류·사람 확인으로 나누었습니다.

• 프론트엔드 회귀 검사 65개와 집계 도메인 검사 12개가 통과했습니다.

• 가장 큰 결과는 비개발자인 제가 제품의 구조를 이해하고 다음 기능을 계속 만들어갈 수 있게 된 것입니다.

이런 분들께 도움돼요

• AI로 홈페이지나 단순 자동화를 넘어 실제 서비스를 만들고 싶은 비개발자

• 외주 개발을 맡기기 전에 자신의 제품을 직접 검증하고 싶은 창업자

• 실제 업무 데이터가 복잡해서 어디서부터 시작해야 할지 막막한 사람

• AI가 만든 결과를 믿어도 되는지 고민하는 실무자

문제 상황: 내가 만들고 싶었던 것은 작은 앱이 아니었다

지난 8월, 외주 개발과 개발 교육을 함께 하는 회사의 CTO와 팀 앞에서 제가 만들고 싶은 서비스 ‘남는 장사’를 설명했습니다.

식자재 거래명세서를 사진으로 찍으면 매입 데이터가 자동으로 정리됩니다. 포스 매출과 메뉴별 원가, 지출 내역도 연결됩니다. 사장님은 오늘 얼마나 팔았는지만 보는 것이 아니라 실제로 얼마가 남았는지, 어떤 메뉴를 계속 팔아야 하는지, 무엇을 바꿔야 하는지까지 안내받습니다.

작은 홈페이지나 간단한 자동화 도구가 아니었습니다. 흩어진 경영 데이터를 모으고, 기준이 다른 데이터를 정규화하고, AI가 거래를 분류하고, 원가와 손익을 계산하고, 그 결과로 의사결정을 돕는 서비스였습니다. 기존 방식으로 전체 범위를 외주 개발한다면 수억 원 규모까지 커질 수 있는 프로젝트였습니다.

전문가들의 진단은 냉정했습니다.

“모든 의사결정을 다 하게 하는 서비스는 사실 처음에는 만들 수 없다.”

모든 데이터를 자동으로 끌어오는 구상도 지금 당장은 불가능할 만큼 어렵고, 별도의 로드맵으로 분리해야 한다는 의견이 이어졌습니다.

제가 상상한 제품은 외식업을 넘어 모든 사업자의 매출과 비용을 모아 판단까지 돕는, 말 그대로 ‘사장님들의 꿈 같은 서비스’였습니다. 문제는 데이터였습니다.

• 포스 외에도 여러 배달 플랫폼의 매출이 따로 존재했습니다.

• 비용은 계좌·카드·식자재 거래명세서·공과금에 흩어져 있었습니다.

• 데이터 몇 개만 빠져도 전체 손익이 왜곡될 수 있었습니다.

• 같은 계좌에도 재료비·직원 정산·개인 거래·환불 같은 예외가 뒤섞였습니다.

• 아직 제품의 생각이 바뀌는 단계라 외주 후 기능을 고칠 때마다 비용과 시간이 커질 수 있었습니다.

그날 저는 ‘불가능하다’는 말을 포기하라는 뜻으로 받아들이지 않았습니다.

완성품 전체를 한 번에 만드는 것은 불가능하지만, 문제를 작게 나누면 한 걸음씩 만들 수 있다는 뜻으로 바꿔 들었습니다.

사용한 도구

• Codex Desktop·GPT 계열 모델: 데이터 구조 파악, 문서화, 파일 통합, 서비스 구현, 테스트

• Google Sheets의 Gemini: 지출 계정 항목 자동 분류 실험

• Google Sheets·Excel·CSV: 실제 매장 매출·주문·결제·지출·원가 데이터 정리

• React·Firebase: 실제 데이터가 연결되는 웹서비스 화면과 서버 기능 구현

• Markdown·Obsidian Canvas: PRD, 설계 문서, ERD와 전체 데이터 흐름 관리

전환점: 홈페이지 만드는 법이 아니라 제품 설계하는 법부터 배웠다

처음에는 AI에게 “이런 대시보드를 만들어줘”라고 말하고 결과 화면을 계속 고쳤습니다. 보기 좋은 시제품은 빠르게 나왔지만, 규모가 커질수록 AI가 앞의 맥락을 잊고 서로 다른 기준으로 기능을 덧붙였습니다. 화면은 있어도 왜 그렇게 만들어졌는지 설명하기 어려웠고, 다음 기능을 붙이면 어디가 무너질지도 알 수 없었습니다.

AI 과외에서 배운 핵심은 코딩 명령어가 아니었습니다.

비전과 아이디어를 PRD로 만들고, PRD를 데이터 모델과 API, 프론트엔드·백엔드 설계로 구체화한 뒤, 그 문서를 기준으로 구현하는 순서였습니다. AI는 정답이 정해진 구현에는 강하지만 “무엇을 만들어야 하는가”라는 정답 없는 문제를 대신 결정해주지는 못했습니다.

그래서 저는 AI에게 제품 전체를 한 번에 만들어 달라고 하지 않았습니다.

1. 사장님이 내려야 할 의사결정을 먼저 정한다.

2. 그 결정에 꼭 필요한 데이터만 고른다.

3. 실제 매장 데이터로 작은 단위부터 정리한다.

4. AI가 만든 결과를 사람이 검수하고 오류 유형을 규칙에 반영한다.

5. 검증된 시트 구조를 데이터베이스와 서비스 화면으로 옮긴다.

6. 기능마다 테스트하고 다음 단계로 넘어간다.

이 순서가 제가 수억 원짜리 문제에 접근할 수 있게 해준 사다리였습니다.

작업 과정: 3박 4일 동안 28개 작업 구간을 연결했다

워케이션에서 직접 기록한 순수 작업 시간은 총 23시간 4분이었습니다. 오래 앉아 있었다는 사실보다 중요한 것은 작업의 순서였습니다.

1일 차 — 흩어진 실제 데이터를 하나의 언어로 바꾸기

먼저 마인드맵으로 문제·데이터·결과물을 펼쳤습니다. 기능 목록부터 만들지 않고 “사장님은 어떤 질문에 답을 얻어야 하는가”를 적었습니다. 그다음 실제 매장의 일자별 매출, 상품 분석, 주문·결제 자료를 모았습니다.

처음 요청은 단순했습니다.

일자별 매출 폴더에 있는 데이터들을 전체 통합본으로 만들어줘.

AI와 함께 파일마다 다른 열과 날짜 형식을 맞췄습니다. 이어 주문·상품·결제 정보를 분석 가능한 구조로 나누고, 메뉴를 함께 주문하는 패턴과 가격대별 추가 제안을 분석할 수 있도록 정규화했습니다.

주문·결제 내역을 통합해줘.
메뉴를 같이 주문하는 패턴이나 가격대별 추가 제안 같은 인사이트를 내려면
데이터를 어떻게 정규화해야 할까?
지금 가지고 있는 것만으로 정규화를 진행해줘.

이름 없는 상품과 0원 상품도 임의로 버리지 않았습니다. 현실의 데이터에는 깔끔한 정답만 있지 않기 때문입니다.

2일 차 — AI의 오답을 없애는 대신 사람이 고칠 수 있게 만들기

지출 내역을 AI가 자동으로 계정 항목에 분류하게 했지만 첫 결과는 그대로 사용할 수 없었습니다. 거래처명만 보고 확정하면 잘못 분류되는 사례가 생겼고, 개인 거래나 환불처럼 AI가 판단하기 어려운 예외도 있었습니다.

처음에는 더 좋은 모델을 쓰면 해결될 거라고 생각했습니다. 하지만 실제로 필요했던 것은 더 강한 모델이 아니라 판단 규칙과 검수 구조였습니다.

어떤 AI 모델이 작업하더라도 사람이 검수한 수준에 가깝게 분류할 수 있는
계정 항목 자동 분류 가이드를 만들어줘.
불명확한 거래는 틀리게 자동 확정하지 말고,
사람이 검수할 수 있게 표시해줘.

목표를 ‘100% 자동 분류’에서 ‘잘못된 자동 확정을 줄이는 분류’로 바꿨습니다. 사람이 검수한 과거 결과를 기준으로 삼고 AI의 판단을 확정·추천·보류·사람 확인으로 나눴습니다. 오전과 오후에 결과를 반복해서 비교하며 오류 유형을 다시 가이드에 넣었습니다.

AI에게 모든 판단을 맡긴 것이 아니라, AI가 할 일과 사람이 책임질 일을 구분한 것입니다.

3일 차 — 매출과 지출을 넘어 메뉴 원가 연결하기

매출과 지출만으로는 “왜 안 남는지”를 설명할 수 없었습니다. 그래서 입고 내역, 월별 평균단가, 최신 적용단가, 레시피를 연결하는 메뉴 원가 구조를 만들었습니다.

메뉴 원가 계산 시트를 다시 정리해줘.
식자재 단가표의 자체제작은 Prep_자체제작으로 바꾸고,
식자재를 공산품·신선·농산·수산·육류·유제품·소스로 세분화해줘.

생크림 단가가 빠진 것을 발견했을 때 AI에게 적당한 값을 채우게 하지 않았습니다. 원본 입고 내역과 품목 매핑까지 거슬러 올라가 누락 원인을 찾았습니다. 자동 계산 칸과 사람이 입력해야 할 칸도 구분했습니다.

이때 중요한 사실을 하나 발견했습니다. 설계한 저조차 전체 시트의 사용 순서를 한눈에 설명하기 어려웠습니다.

이걸 전체 어떻게 써야 할지 설계한 나도 모르겠어.
중학생도 이해할 수 있는 수준으로 도식화를 포함한 안내 시트를
가장 앞에 만들어줘.

AI는 처음 사용하는 사람이 어디서 입력을 시작하고, 어떤 값이 자동으로 계산되며, 결과를 어디서 확인해야 하는지 안내하는 첫 화면을 만들었습니다. 제품은 기능이 많은 것보다 사용자가 길을 잃지 않는 것이 중요하다는 점도 배웠습니다.

마지막 단계 — 시트를 실제 서비스의 뼈대로 바꾸기

마지막으로 매출·주문·결제·지출·원가가 어떤 관계로 연결되는지 ERD를 만들었습니다.

통합 시트와 개별 DB의 관계를 파악해서
업무 파악, 개념적 데이터 모델링, 논리적 데이터 모델링, ERD를 만들어줘.

Google Sheets에서 검증한 업무 구조를 Firebase와 React 기반 웹서비스로 옮겼습니다. 실제 매장의 2026년 8월 1일 매출 3,136,000원을 기준으로, 그날 어떤 메뉴가 팔려 이 매출이 만들어졌는지 확인하는 상세 화면을 구현했습니다.

매출 캘린더, 메뉴별 매출 순위, 카테고리별 분석, 결제·환불 흐름도 연결했습니다. 기간과 데이터 버전, 카테고리 필터가 화면을 이동해도 유지되게 했고, 이름 없는 상품·0원 상품·환불·자료 누락을 마음대로 보정하지 않는 집계 규칙도 넣었습니다.

결과: 설명용 목업에서 실제 데이터가 움직이는 제품으로

Before vs After

아직 모든 기능을 갖춘 상용 서비스가 완성된 것은 아닙니다. 하지만 발표용 화면만 있는 시제품도 아닙니다. 실제 매장 데이터가 들어가고, 매출의 구성과 원가·지출 구조를 따라가며 다음 의사결정을 준비할 수 있는 작동하는 핵심을 만들었습니다.

가장 큰 결과는 코드가 아니었습니다.

예전에는 제가 만든 것은 설명용 시제품이고 진짜 제품은 언젠가 개발사가 다시 만들어야 한다고 생각했습니다. 지금은 실제 데이터를 고르고, 데이터 구조를 검토하고, AI의 오류 기준을 정하고, 화면과 서버가 주고받을 약속을 문서화하고, 테스트 결과를 보며 다음 기능을 결정할 수 있게 됐습니다.

외주를 주지 않겠다는 이야기가 아닙니다. 무엇을 왜 만들지 모르는 상태에서 전체를 넘기는 대신, 창업자인 제가 제품의 핵심 구조를 이해하고 AI로 검증한 뒤 필요한 부분에 전문가의 자문과 개발 역량을 투입할 수 있게 됐다는 뜻입니다.

이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 기능이 아니라 의사결정에서 시작하기 “무엇을 보여줄까?”보다 “이 화면을 보고 사장님이 무엇을 결정해야 할까?”를 먼저 정했습니다.

2. 실제 데이터로 가장 작은 단위부터 검증하기 전체 자동화를 시도하지 않고 일자별 매출부터 시작해 주문·결제, 지출, 원가로 넓혔습니다.

3. 오답을 다음 규칙의 재료로 사용하기 분류 오류와 단가 누락을 지우는 데서 끝내지 않고, 같은 문제가 반복되지 않도록 가이드와 구조에 반영했습니다.

4. AI가 모르면 사람이 검수하도록 남겨두기 억지로 모든 칸을 채우게 하지 않고 추천·보류·사람 확인 상태를 만들었습니다.

5. 코드보다 상위 문서를 먼저 고치기 기능이 바뀌면 관련 PRD와 데이터 구조를 먼저 정리한 뒤 구현했습니다.

이렇게 하면 안 돼요

1. “전체 서비스를 만들어줘”라고 한 번에 요청하지 않기 처음에는 빨라 보여도 기능이 늘어날수록 기준이 충돌하고 유지보수가 어려워집니다.

2. AI가 채운 숫자를 정답으로 간주하지 않기 실제 데이터가 누락됐을 때는 값을 추정하지 말고 원본과 연결 규칙을 확인해야 합니다.

3. 예쁜 화면을 제품 완성으로 착각하지 않기 화면 뒤의 데이터 관계와 예외 처리, 검증 기준이 있어야 실제 업무에 사용할 수 있습니다.

다른 업무에 적용한다면?

이 방법은 외식업에만 적용되지 않습니다. 여러 시스템의 데이터를 모아 사람이 판단해야 하는 업무라면 같은 순서를 사용할 수 있습니다.

• 여러 채널의 영업 데이터를 통합하는 매출 관리

• 거래 내역을 검수하는 회계·정산 업무

• 재고와 발주량을 연결하는 구매 업무

• 고객 문의를 분류하되 애매한 건을 상담원에게 넘기는 고객 지원

• 여러 문서의 상태를 모아 다음 행동을 제안하는 프로젝트 관리

핵심은 AI에게 최종 결정을 통째로 맡기는 것이 아닙니다. 판단 과정을 작은 단계로 나누고, 확실한 것은 자동화하고, 애매한 것은 사람이 확인하도록 설계하는 것입니다.

앞으로의 계획

워케이션이 끝나면 실제 매장에서 같은 구조로 매출·지출·원가 데이터를 계속 쌓을 예정입니다.

• 매일 들어오는 데이터를 같은 형식으로 축적하기

• 메뉴별 실제 원가 변화를 추적하기

• 매출은 높지만 이익이 낮은 메뉴 찾기

• AI 분류가 틀린 사례를 규칙에 다시 반영하기

• 사장님이 실제로 내린 결정과 결과 기록하기

한 매장에서 검증한 흐름을 다음 매장으로 복제하면서, 수동 입력으로 충분한 부분과 반드시 자동화해야 하는 부분을 구분해 나가려고 합니다.

재사용 가능한 프롬프트

프롬프트 1 — 큰 서비스의 첫 단위 찾기

나는 [대상 사용자]가 [해결하고 싶은 큰 문제]를 해결하도록 돕는 서비스를 만들고 싶어. 전체 기능을 한 번에 설계하지 말고, 사용자가 가장 먼저 내려야 할 의사결정 3개를 찾아줘. 각 의사결정에 꼭 필요한 최소 데이터, 없어도 되는 데이터, 사람이 직접 확인해야 하는 예외를 구분해줘. 그중 실제 데이터로 가장 빨리 검증할 수 있는 한 가지를 첫 MVP로 추천해줘.

프롬프트 2 — AI 판단과 사람 검수 나누기

[업무 데이터]를 AI로 자동 분류하려고 해. 모든 항목을 억지로 확정하지 말고 자동 확정 / 추천 / 보류 / 사람 확인으로 나눠줘. 각 상태의 판단 근거와 신뢰 기준을 정의하고, 잘못 확정했을 때 위험이 큰 사례는 반드시 사람 확인으로 보내줘. 사람이 수정한 결과를 다음 분류 규칙에 반영하는 절차도 만들어줘.

프롬프트 3 — 시트에서 서비스 구조로 옮기기

현재 [시트 또는 업무 문서]에는 [데이터 종류]가 들어 있어. 먼저 실제 업무 흐름을 설명하고, 각 데이터가 어떤 관계인지 비개발자도 이해할 수 있게 정리해줘. 그다음 중복·누락·예외를 확인하고, 데이터베이스로 옮길 때 필요한 개념 구조와 화면별 최소 데이터를 제안해줘. 임의로 값을 만들지 말고 확인이 필요한 부분은 질문 목록으로 남겨줘.

마치며

AI가 수억 원짜리 프로젝트를 버튼 한 번으로 만들어준 것은 아닙니다.

대신 전에는 엄두도 내지 못했던 프로젝트를 비개발자인 제가 이해하고 설계하고 검증하면서, 실제로 작동하는 제품을 한 걸음씩 만들 수 있게 해주었습니다.

“처음에는 만들 수 없습니다”라는 말은 틀리지 않았습니다.

다만 이제 저는 그 문장 뒤에 한 줄을 덧붙일 수 있습니다.

“한 번에는 만들 수 없지만, 오늘 만들 수 있는 한 걸음은 분명히 있다.”