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

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

메타 시니어 개발자가 8개월 전에 만든 AI 서비스 ‘그로스 노트’는 영상 시점에 약 50명의 활성 사용자가 쓰는 무료 서비스로 운영되며, 상품별 손익 분석과 에이전트 연결을 개선하고 있다.

📌 핵심 요점

1. 흩어진 정산 자료를 실제 이익으로 바꾼다. 쿠팡 로켓그로스의 여덟 종류 정산 엑셀에 상품별 원가·광고비·고정비를 결합한다. 세금계산서 기준 수치와 실제 영업이익을 분리하고, 상품별 흑자와 적자를 확인하도록 만들었다.
2. 초기 출시를 넘어 운영 단계에 들어섰다. 2월 MVP 제작, 4월 초 출시 이후 개발자가 약 6개월째 혼자 운영하고 있다. 적극적인 마케팅 없이 활성 사용자는 약 50명으로 파악했으며, 서비스는 무료다. 미네님은 분석을 5분 안에 끝낼 수 있다고 설명했다.
3. 핵심 병목은 도메인 이해와 숫자 검증이었다. 클로드 코드로 구현했지만 쿠팡 정산 규칙을 이해하고 틀린 수치의 원인을 찾는 데 시간이 들었다. 요구사항 원문과 실제 파일을 전달하고, 검증할 숫자를 명확히 정한 브라우저 엔드투엔드 테스트를 마련한 뒤 기능이 깨지는 일이 줄었다고 한다.
4. 사람과 외부 에이전트가 모두 사용할 수 있게 확장했다. MCP로 클로드·코덱스 등의 접근을 지원하고, 서비스 내부에는 대화형 업로드 도우미를 넣었다. 데이터 저장을 꺼리는 사용자를 위해 일회성 임시 분석을 제공하며, 저장 데이터에는 마스킹과 접근 권한 제어 등을 적용했다고 설명했다.
5. 출시 후 개선은 측정과 사업 맥락을 중심으로 진행한다. 가입 전환, 업로드 성공률, AI 분석 실패를 커스텀 텔레메트리로 확인한다. 일반 AI 분석과 차별화하기 위해 셀러의 사업 맥락을 실행 계획에 반영하고, 모델 발전에 맞춘 UI 개편과 에이전트 중심 설계를 검토하고 있다.

🧩 배경과 문제 정의

• 쿠팡 로켓그로스는 포장·배송·반품·고객 응대를 대신하지만, 셀러가 실제로 얼마를 벌었는지 계산하는 정산 분석은 수동으로 남아 있었다.
• 정산 자료가 여러 종류의 엑셀로 흩어져 있어 분석 가능 여부와 소요 시간이 셀러의 엑셀 실력에 좌우됐다. 상품별 손익을 모르면 재고와 광고를 조정할 근거도 부족해진다.
• 그로스 노트는 온라인 사업 경험을 가진 미네님의 기획과 개발자의 클로드 코드 활용으로 출발했다. 정산 파일과 원가·비용 정보를 결합해 실제 영업이익을 계산하고, 사업에 필요한 실행안을 제공하는 것이 목표다.

🕒 시간순 섹션별 상세정리

1. 정산 마스터 시트에서 출발한 그로스 노트

• 그로스 노트는 쿠팡 로켓그로스 셀러가 정산 엑셀을 올리면 상품별로 남는 금액과 이번 달에 확인할 사항을 보여주는 서비스다. 미네님의 사업 경험을 바탕으로 기획하고 클로드 코드를 활용해 개발했다 [01:10]
• 1월에 공유받은 정산 마스터 시트를 바탕으로 2월에 MVP를 만들었다. 4월 초 출시 이후에는 개발자가 약 6개월째 혼자 운영하고 있다 [01:24]

2. 물류 자동화 이후에도 남은 실제 이익 계산

• 로켓그로스는 셀러가 물건을 쿠팡 창고에 넣으면 포장·배송·반품·고객 응대를 대신한다. 미네님은 매달 약 한 시간 동안 필요한 수량을 고민해 보내면 쿠팡이 한 달 동안 판매해 주는 방식으로 설명했다 [02:23]
• 판매 이후 실제로 남은 이익은 별도로 계산해야 한다. 정산 자료가 한 장으로 나오지 않고 여덟 종류, 실제 파일 수로는 약 30~40개의 엑셀로 나뉘어 있어 계산이 어렵다 [03:12]

3. 엑셀 실력에 따라 갈리는 사업 판단과 분석 시간

• 미네님이 셀러 단체 대화방에서 알아본 바로는 엑셀을 못하는 사람들은 분석을 포기하기도 한다. 실제 수익과 상품별 손실을 모르면 다음 달에도 비슷한 재고를 넣게 되고, 무엇을 늘리거나 줄일지 결정할 근거가 부족해진다 [04:04]
• 엑셀을 어느 정도 다루는 셀러도 월 10~20시간을 분석에 쓰며, 수식으로 템플릿을 만든 숙련자는 월 한두 시간 정도를 쓴다고 한다 [04:47]

4. 파일 업로드와 비용 저장, 두 가지 손익 기준

• 여덟 종류의 정산 파일을 올리고 상품별 원가와 고정비를 저장해 반복 입력을 줄이도록 요구사항을 정했다. 다운로드하는 엑셀 수가 많게는 100개에 이르는 사용자도 고려했다 [05:36]
• 세금계산서 기준과 원가·비용을 뺀 실제 영업이익 기준을 분리했다. 쿠팡이 제공하는 세금계산서 기준만으로는 파악하기 어려운 실제 영업이익을 계산하는 것이 핵심 기능이다 [06:03]

5. UI 개선 후보와 대량 업로드의 사용성

• 홈 화면은 여러 AI 모델로 만든 시안을 비교했으며, 개발자는 파란색 계열의 깔끔한 화면을 선호했다. 현재 UI에 아쉬움이 있어 사용자 의견과 투표를 받아 수정하려는 상태다 [07:13]
• 매뉴얼 다운로드와 엑셀 업로드 기능을 제공하고, 여덟 종류의 파일을 확인하는 업로드 체크 매트릭스를 마련했다. 초기에는 엑셀 업로드가 오래 걸려 성능 최적화가 중요한 과제였다 [08:49]

6. 쿠팡 정산 대조에서 상품별 손익 확인까지

• 매입 단가·광고비 등의 비용을 입력할 수 있으며, 대시보드는 전체 판매를 요약한다. 세금계산서 기준의 수치가 쿠팡 데이터와 일치하는지 확인하는 것이 첫 번째 검증 목표였다 [10:11]
• 백엔드에서 원가와 비용을 반영한 영업이익을 계산해 보여준다. 단순히 쿠팡 정산 수치를 재현하는 데서 나아가 실제로 남은 이익을 확인하는 데 서비스의 가치가 있다 [10:54]

7. AI 인사이트를 실행 계획으로 연결하는 방식

• AI 분석은 자료와 범위를 바꿔 실행할 수 있다. 현재 서비스는 무료이며, 유료화한다면 분석 한 번에 100크레딧을 쓰거나 분석 기간에 따라 크레딧을 늘리는 방식을 고려한다 [11:51]
• 시연 자료는 테스트 데이터다. 예시 실행안에는 광고비를 월 800만 원으로 제한하고 고마진 옵션에 재분배하기, 보관비 줄이기, 매입 단가가 입력되지 않은 여덟 항목 점검하기가 포함되며 예상 효과와 근거 수치도 함께 제공한다 [12:33]

8. 외부 에이전트가 사용할 수 있는 MCP 연결

• 에이전트 시대에는 서비스가 에이전트의 접근과 사용을 지원하는지가 경쟁력에 큰 영향을 준다는 관점에서 MCP를 만들었다 [14:44]
• 연결 페이지에서 토큰과 연결용 프롬프트를 제공한다. 사용자는 프롬프트를 복사해 클로드나 코덱스에 전달하거나 MCP를 직접 연결할 수 있다 [15:18]

9. 대화형 도우미와 사업 맥락으로 만드는 차별화

• 외부 에이전트를 쓰기 어려운 사용자를 위해 서비스 안에 대화형 도우미를 마련했다. 정산 엑셀을 올리고 싶다고 요청하면 대화창에 업로드 카드를 띄워 바로 파일을 올릴 수 있게 해 사용 부담을 줄인다 [16:25]
• 도우미는 크레딧 확인 등의 기능도 제공하며, 챗봇 방식에 익숙한 사용자가 대화로 서비스를 이용할 수 있게 한다 [17:07]

10. 가입·업로드·AI 분석의 실패를 찾는 텔레메트리

• 관리자 대시보드는 업로드 사용자와 파일 수, 성공·실패, 업로드 성공률 등을 집계한다. AI 인사이트 생성 실패와 첫 방문에서 가입까지의 전환도 확인할 수 있다 [18:19]
• 로그인 화면에서 사용자가 많이 멈추거나, 업로드 실패의 주요 원인이 쿠팡 정산 파일이 아닌 자료인 점을 파악해 수정 과제로 연결한다. 사용자 데이터는 마스킹해 DB에 저장하도록 구성했다고 한다 [18:43]

11. 계산과 파일 처리를 중심으로 구성한 아키텍처

• 프런트엔드는 Next.js와 Vercel을 사용하고, FastAPI에서 계산 로직을 처리한다. 계산량이 많은 서비스여서 엑셀 파싱과 메모리 최적화, 업로드·분석·AI 인사이트 제공 속도가 핵심 과제였다 [19:32]
• MCP를 통해 클로드 코드와 코덱스 등 여러 에이전트의 연결을 시험했으며, Supabase로 데이터베이스와 인증을 구성했다 [20:02]

12. 데이터 축적의 이점과 업로드 불안을 함께 다루는 보안

• 여러 달의 판매 이력이 쌓이면 사용자의 사업 맥락을 더 많이 확보해 AI 인사이트를 개선할 수 있다는 구조다. 저장되는 데이터와 인사이트는 마스킹해 운영자도 읽을 수 없도록 구성했다고 보여준다 [20:39]
• 데이터를 남기는 것이 꺼려지는 사용자는 일회성 임시 업로드로 분석할 수 있으며, 이 방식에서도 AI 인사이트를 이용할 수 있도록 했다 [21:18]

13. 브라우저 엔드투엔드 테스트가 줄인 검증 부담

• 개발 당시인 1~2월에는 AI의 브라우저 테스트 능력이 약해 Playwright MCP를 활용하는 과정이 어려웠다. 브라우저 엔드투엔드 테스트를 구축하는 일이 중요한 검증 과제였다 [22:16]
• 테스트를 잘 마련하면 검증 속도를 높이고 애플리케이션 디버깅을 쉽게 할 수 있었다. 현재는 당시보다 브라우저 테스트 도구를 활용하기 쉬워졌다고 평가한다 [22:37]

14. 요구사항 원문 보존과 도메인 지식의 병목

• 익숙하지 않은 사업 분야에서는 미팅 내용을 직접 요약하면 무엇을 빠뜨렸는지 알아차리기 어렵다. 요구사항을 녹음해 원문으로 보존하고 미팅 로그·기획 시트·실제 정산 파일을 통째로 에이전트에 전달했다 [23:29]
• 상세한 프런트엔드·백엔드 기획과 데이터 정의 시트를 받았어도 화면 구조와 데이터 모델의 최종 결정은 개발자의 몫이었다 [24:15]

15. 자료 전달과 병렬 개발에서 겪은 시행착오

• 초기에는 AI가 구글 슬라이드를 잘 읽지 못해 기획 화면을 캡처하고 시트의 셀을 복사해 전달했다. 자료가 꼼꼼히 준비돼 있어도 이를 AI가 활용할 맥락으로 구성하는 과정에서 시행착오가 많았다 [25:23]
• 병렬 작업 중에는 머지 충돌과 서로의 수정 내용을 다시 고치는 문제가 발생했다. 이후 드라이브 폴더 전체를 제공하고 MCP로 읽게 하면서 자료 전달이 쉬워졌다 [26:12]

16. 초기 AI의 구현 한계와 기존 사용자에 대한 UI 변경 부담

• 1~2월의 AI는 주니어 엔지니어 정도로 평가했다. 설계와 구현이 그럴듯해 보여도 수정할 부분과 버그가 많았고, 개발자의 도메인 지식 부족까지 겹쳐 검증에 시간이 많이 들었다 [26:59]
• 검증할 숫자를 명확히 정해 엔드투엔드 테스트를 구성한 뒤에는 기능이 깨지는 일이 줄었다고 한다 [27:25]

17. 모델 발전에 따라 계속 바뀌는 서비스와 동적 UI

• 모델과 에이전트의 성능이 좋아지면서 서비스 자체를 크게 바꿀 수 있는 여지도 커졌다고 본다. 과거에는 전면적인 UI 개편이 드물었지만 이제는 서비스를 더 자주 개선할 수 있다는 경험이다 [28:01]
• 사용자가 대시보드의 위치뿐 아니라 구성 방식까지 원하는 대로 바꾸는 동적 UI 시대가 왔다고 평가한다. 고정된 화면보다 사용자 요구에 맞춰 변하는 서비스가 확산될 것이라는 관점을 제시한다 [28:37]

18. 필요한 사용자 흐름을 직접 측정하는 커스텀 텔레메트리

• 처음에는 구글 애널리틱스를 사용했지만 한계를 느껴 커스텀 텔레메트리를 만들었고, 자신의 운영 목적에 더 잘 맞는 결과를 얻었다고 평가한다 [29:24]
• 기존 분석 도구로 시작할 수 있지만, 에이전트의 개발 능력이 좋아진 상황에서는 필요한 기능을 직접 만드는 편이 더 나을 수도 있다. 원하는 인사이트와 사용자 전환·이용 흐름을 확인하고 그때그때 피드백을 반영할 수 있다는 점을 장점으로 본다 [29:38]

19. 맞춤형 개발의 선택과 에이전트를 위한 서비스 설계

• 기존 도구를 가져다 쓰면 시간을 아끼고 새로 만든 기능을 유지보수할 필요도 줄어든다. 반면 맞춤형 개발이 쉬워지면서 직접 만드는 편이 더 좋은 경우도 많아졌으며, 이때는 유지보수 비용을 함께 고려해야 한다. [30:18]
• 서비스를 처음부터 다시 만든다면 에이전트를 위해 설계하겠다는 판단이다. 기존에는 그로스 셀러 사용자를 중심으로 만들었지만, 이제는 에이전트가 서비스를 사용하는 시대라고 본다. 플러그인 스토어에 없는 서비스는 에이전트에게도 없는 것과 같다는 관점에서, MCP를 통해 에이전트가 쉽게 사용할 수 있도록 해야 한다. [31:15]

20. 의도·품질·측정 중심의 운영 원칙과 후속 협업

• 컨설팅에서는 사용자의 의도와 도메인을 파악중요하다. 개발에서는 모델 성능 향상으로 유기적인 서비스를 만들 수 있게 되었으며, 많이 만드는 것보다 잘 만드는 것이 중요하다. [32:11]
• 출시 후에는 텔레메트리를 붙여 감이 아닌 측정 데이터로 판단해야 한다. 이러한 측정은 개발자뿐 아니라 에이전트를 위해서도 필요하며, 에이전트가 사용할 수 있는 서비스를 만드는 방향과 연결된다. [32:27]

🧾 결론

• 그로스 노트는 정산 수치를 보여주는 데서 나아가, 비용을 반영한 상품별 손익과 재고·광고 조정에 필요한 실행안을 제공하는 서비스로 발전했다.
• AI가 구현을 도와도 요구사항 해석, 데이터 모델 결정, 계산 정확성 검증과 운영 책임은 개발자의 중요한 역할로 남았다.
• 이 사례에서 지속적인 개선의 기반은 사업 맥락, 명확한 검증 기준, 실제 이용 흐름을 보여주는 측정 데이터였다.

📈 투자·시사 포인트

• 유료화 가능성은 아직 검증할 부분이다. 약 50명의 활성 사용자와 무료 운영은 초기 사용 현황을 보여주지만, 지불 의사나 매출·수익성을 입증하지는 않는다. 크레딧 기반 과금은 검토 단계로 설명됐다.
• 업무에 특화된 맥락이 차별화의 후보가 된다. 쿠팡 정산 규칙과 셀러의 비용·판매 이력을 반영한 실행안이 일반 AI보다 유용한지 확인하는 것이 서비스 가치 판단의 핵심이다.
• 에이전트 접근성이 새로운 이용 경로가 될 수 있다. 개발자는 MCP를 통한 연결을 경쟁력으로 봤다. 실제 효과는 연결 이후 이용 빈도와 분석 완료율 등으로 확인필요가 있다.
• 맞춤형 개발에는 유지보수 비용이 따른다. AI로 필요한 기능을 직접 만들기 쉬워져도 계산 검증, 파일 처리 성능, 보안, 기존 사용자의 UI 적응 부담을 함께 고려해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 제목의 ‘8개월 전’과 본문의 ‘출시 후 약 6개월 운영’은 기준 시점이 다르다. 제공 자료만으로 정확한 촬영일이나 현재 운영 상태를 확정할 수 없다.
• 활성 사용자 약 50명의 집계 기간과 정의는 제시되지 않았다. 분석 시간 5분 이내 역시 미네님의 설명이며, 파일 규모별 비교 측정 결과는 없다.
• 광고비 월 800만 원 제한 등 시연 실행안은 테스트 데이터에 기반한다. 제시된 예상 효과를 실제 고객의 수익 개선 성과로 해석할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 동일 기간의 실제 정산 파일과 원가·비용을 준비해 세금계산서 기준 수치를 쿠팡 자료와 대조하고, 상품별 영업이익 계산도 별도로 검증한다.
• 원가 누락 항목과 적자 상품을 먼저 확인한 뒤, AI가 제안한 광고·재고 조정안의 근거 수치를 점검한다.
• 파일 수와 분석 범위를 기록하며 업로드·계산·AI 분석 시간을 측정해 실제 시간 절감 효과를 확인한다.
• 저장형 분석과 일회성 임시 분석의 차이, 데이터 보관 범위, 에이전트 접근 권한을 확인하고 사용 방식을 선택한다.

❓ 열린 질문

• 무료 사용자 중 얼마나 많은 사람이 반복적으로 분석하며, 어떤 실행안에 비용을 지불할 의사가 있을까?
• 판매 이력이 쌓일수록 AI 실행안의 정확성과 실제 사업 성과가 얼마나 개선될까?
• MCP 연결과 내부 대화형 도우미 중 어떤 경로가 사용자의 분석 완료와 재이용에 더 크게 기여할까?