메타 시니어 개발자가 8개월전에 만든 AI 서비스, 지금은 어떨까?

한 줄 핵심

쿠팡 로켓그로스 셀러의 정산 수동 작업을 AI SaaS로 자동화한 뒤 8개월간 운영하며, 컨설팅·MCP·보안·텔레메트리까지 포함한 실전 제품 개발과 운영의 교훈을 정리한 영상이다.

시간별 요약

1. 0:00
   8개월 전 만든 앱, 지금은? 클로드 코드로 처음 제대로 만든 서비스가 8개월 뒤 실제 운영 단계에서 어떤 모습이 되었는지 소개한다. 단순 데모가 아니라 컨설팅, 개발, 런칭, 운영까지 이어진 사례라는 점이 핵심이다.
2. 0:14
   미네님 인터뷰 온라인 사업 경험을 바탕으로 문제를 정의했고, Claude Code로 빠르게 개발해 그로스 노트를 만들었다고 정리한다. 한 달치 상품별 정산 분석에 5분만 걸리도록 만든 서비스라는 점이 강조된다.
3. 0:36
   그로스노트는 어떤 서비스인가 쿠팡 로켓그로스 셀러가 정산 엑셀을 올리면 상품별 손익과 이번 달에 확인할 항목을 보여주는 SaaS로 설명한다. 1월에 문제를 공유받아 2월에 MVP를 만들고 4월에 런칭한 뒤 혼자 운영해 왔다.
4. 2:04
   문제 — 로켓그로스 셀러에게 남은 수동 작업, 정산 쿠팡이 물류·포장·배송·반품·CS를 자동화해 주지만, 셀러는 여전히 여러 정산 엑셀을 보고 실제 수익을 계산해야 한다. 정산 파일이 8종류, 엑셀 개수는 30~40개에 달해 계산 자체가 큰 부담이 된다.
5. 3:50
   엑셀 실력이 분석을 갈랐다 엑셀을 못 다루면 분석을 포기하고, 잘 다루는 사람도 한 달에 10~20시간을 쓰는 반면 고수는 수식 템플릿으로 1~2시간에 끝낸다. 그로스 노트는 이 격차를 5분으로 줄여, 셀러가 숫자를 근거로 재고와 상품 전략을 정할 수 있게 한다.
6. 5:36
   빈칸을 채우는 네 가지 핵심 기능은 파일 업로드, 원가·고정비 저장, 두 기준으로 나눈 손익 계산, 상품별 이익 확인이다. 특히 세금계산서 기준과 원가·비용 기준을 분리해 실질 영업이익을 보여 주는 점이 킬러 기능으로 제시된다.
7. 7:02
   실제 화면 — 홈과 UI 시안 홈 화면과 여러 UI 시안을 비교하며 현재 디자인에 대한 만족도와 아쉬움을 공유한다. 매뉴얼 다운로드가 가능하고, 실제 사용성을 높이기 위해 UI/UX를 계속 개선하려는 방향이 드러난다.
8. 9:01
   엑셀 업로드와 일회성 임시 업로드 여러 종류의 많은 엑셀을 업로드할 수 있으며, 업로드가 느린 문제가 초기 최적화의 관건이었다. 데이터 저장이 불안한 사용자를 위해 DB에 영구 저장하지 않는 일회성 임시 분석 기능도 제공한다.
9. 10:32
   대시보드 — Red Box와 Blue Box Red Box는 쿠팡 데이터와 일치하는지 검증하는 영역이고, Blue Box는 원가와 비용을 반영한 실질 영업이익을 보여 주는 영역이다. 제품별 손익 탭도 있어 흑자·적자 상품을 구분해 볼 수 있다.
10. 11:50
    AI 인사이트와 액션 플랜 AI가 분석 결과만 보여 주는 것이 아니라, 광고비 조정·마진 옵션 재분배·보관비 최적화·입력 자료 점검 같은 실행 계획까지 제안한다. 유료화 시 크레딧 기반으로 운영될 수 있으며, 고급 모델로 인사이트 품질을 확보하는 것이 중요하다고 본다.
11. 14:48
    MCP — 에이전트가 못 쓰면 없는 서비스 에이전트가 사용할 수 없는 서비스는 사실상 없는 서비스와 같다는 관점에서 MCP의 중요성을 강조한다. 클로드나 Codex 같은 에이전트가 정산 엑셀과 손익 요약을 바로 다루도록 연결하는 구조가 필수라고 본다.
12. 16:13
    서비스 안의 AI 도우미 에이전트를 잘 못 쓰는 사용자를 위해 서비스 내부에 AI 도우미를 두어 업로드와 사용 흐름을 자연스럽게 연결한다. 이 도우미는 MCP와 서비스 사이의 중간다리 역할을 하며, 사용 진입 장벽을 크게 낮춘다.
13. 18:19
    관리자 대시보드와 텔레메트리 업로드 성공률, 실패 사유, 가입 전환, 로그인 이탈 지점 등을 보는 텔레메트리가 운영에 중요하다고 정리한다. 사용자 데이터는 마스킹돼 있어 개인 정보가 직접 드러나지 않도록 관리한다.
14. 19:27
    아키텍처 — Vercel · Next.js · FastAPI · Supabase 프론트는 Vercel과 Next.js, 계산이 무거운 로직은 FastAPI, 인증과 데이터베이스는 Supabase로 구성했다. 엑셀 파싱과 메모리 최적화, MCP 연동, 다양한 에이전트와의 테스트가 핵심 구조였다.
15. 20:38
    보안 — 임시 업로드, 두 겹 마스킹, RLS 민감한 정산 데이터를 다루기 때문에 임시 업로드, 두 겹 마스킹, RLS 같은 기본 보안 통제가 필수였다. 데이터를 저장하고 싶지 않은 사용자를 위해 분석만 하고 끝나는 경로도 마련했다.
16. 22:17
    검증 — End-to-end 테스팅 브라우저 기반 서비스에서는 End-to-end 테스팅이 검증과 디버깅의 핵심이라고 본다. 초기 Claude 환경에서는 브라우저 테스팅이 약했기 때문에 Playwright MCP 같은 도구를 활용해 검증 체계를 갖췄다.
17. 23:02
    배운 것 ① 컨설팅 — 의도 파악과 도메인 외주·컨설팅에서는 상대의 의도를 정확히 파악하고, 도메인 지식이 부족하면 요구사항을 놓치기 쉽다. 미팅 로그, 기획 시트, 정산 파일을 통째로 컨텍스트로 넘기고, 설계와 화면 구조는 직접 결정해야 했다.
18. 25:03
    병목은 코드가 아니라 사람이었다 개발 병목은 코드보다 숫자의 정합성을 판단할 도메인 지식과 검증 시간이었고, 시차도 큰 장애물이 됐다. 컨텍스트를 쌓고, 단계별로 쪼개고, 엔드투엔드 테스트를 세팅한 뒤에야 시행착오가 줄어들었다.
19. 27:32
    리뱀프 — 유기적인 서비스의 시대 모델이 좋아질수록 서비스도 함께 바뀌며, UI와 기능을 유기적으로 계속 고칠 수 있는 시대가 왔다고 본다. 사용자가 원하는 대로 대시보드 구성을 바꾸는 식의 동적인 서비스 경험이 중요해지고 있다.
20. 29:25
    텔레메트리는 직접 만들기 Google Analytics보다 서비스에 맞는 커스텀 텔레메트리가 훨씬 유용했고, 원하는 유저 플로우와 전환 지표를 바로 볼 수 있었다. 기존 도구를 쓰되, 핵심 지표는 직접 만드는 편이 더 빠르고 유연할 수 있다.
21. 30:20
    다시 만든다면, 에이전트를 위해 처음부터 다시 만든다면 사용자뿐 아니라 에이전트가 쉽게 쓰는 구조를 우선 설계해야 한다고 결론짓는다. MCP와 플러그인 생태계, 그리고 사람과 에이전트 사이를 잇는 인터페이스가 제품 경쟁력을 좌우한다.
22. 31:55
    세 문장 정리 컨설팅에서는 의도와 도메인 파악이 중요하고, 개발에서는 모델 진화에 맞춰 유기적으로 서비스를 바꾸는 것이 핵심이며, 런칭 후에는 텔레메트리로 측정해야 한다는 세 가지 교훈으로 정리한다.
23. 32:29
    마무리 미네님의 사업 운영 사례와 풀 인터뷰를 다시 연결하며, 반복 업무 자동화 주제가 있으면 댓글로 알려 달라고 마무리한다. 앞으로도 협업 콘텐츠를 이어가겠다는 의지도 전한다.

실무 인사이트

• AI SaaS의 경쟁력은 모델 성능만이 아니라, 사용자의 도메인 데이터를 얼마나 잘 구조화해 실행 가능한 인사이트로 바꾸느냐에 달려 있다.
• 에이전트 시대의 제품은 사람용 UI만 설계해서는 부족하고, MCP와 내부 도우미처럼 에이전트와 사람을 모두 고려한 진입 경로가 필요하다.
• 운영 단계에서는 기능 추가보다 텔레메트리, 보안, End-to-end 테스트가 먼저 갖춰져야 실제 사용과 개선이 빠르게 선순환한다.