문서부터 시작해 버려진 대시보드를 재구축했다 — 쿠마치 백오피스
출처: Dev.to
이 프로젝트는 GitHub Finish‑Up‑A‑Thon 챌린지에 제출된 작품입니다.
Kumachi Back Office는 나의 창작 및 업무 세계를 운영하는 개인 전용 운영 체제입니다. 이는 창업자를 위한 커맨드 센터로, CRM도, 작업 관리도, 분석 대시보드도 아니며, 모든 것을 한데 모으는 조종석입니다.
Kumachi의 네 가지 공개 코어를 관리합니다:
- eSerunkuma — 개인 브랜드, 컨설팅, 글쓰기, 권위 레이어
- Kumachi Studio — 에이전시: 클라이언트 서비스, 웹사이트, 자동화, 마케팅
- Kumachi Prints — 아트 커머스 코어: 프린트, 제품, 디지털 다운로드
- Kumachi Gallery — 문화 코어: 스토리, 이벤트, 투어, 경험
매일 아침, 이 대시보드는 내가 실제로 필요로 하는 질문에 답합니다:
- 오늘은 무엇을 해야 할까?
- 현재 가장 가까운 수익은 어디에 있을까?
- 어느 코어가 주의를 필요로 할까?
- 어떤 리드가 팔로업이 필요할까?
- 다음에 무엇을 출판·완성·판매해야 할까?
대시보드는 Next.js 16, Supabase (Postgres + Auth + RLS), TypeScript, Tailwind CSS, shadcn/ui 로 구축되었으며 Vercel에 배포되었습니다. 이는 궁극적으로 완전 자동화된 AI 기반 에이전시 운영 체제가 될 첫 번째 작동 릴리스입니다.
이전(버려진 첫 번째 버전):
- 저장소:
github.com/kumachistudio/kumachi-dashboard - 영상:
youtu.be/BO54kmJxDU4
이후(이번 제출):
- 라이브:
kumachi-back-office.vercel.app— 로그인:demo@kumachi.test/demopass123 - 영상:
youtu.be/JTWnwCFtdBM - GitHub:
github.com/serunkuma/kumachi-dashboard-polished
복귀 스토리
이 프로젝트는 이전 Notion MCP 챌린지를 고민하던 중 시작되었습니다. 그 챌린지는 AI 기반 워크플로우와 솔로 창업자가 사고·행동·실행을 돕는 시스템을 갖는 것이 어떤 의미인지 깊이 생각하게 만들었습니다.
첫 번째 버전의 Kumachi Dashboard는 한 번에 모든 것을 하려 했습니다:
- 마케팅 분석
- 소셜 리스닝
- 캠페인 연동
- 보고서 생성
- 스크래핑 워크플로우
- 아이젠하워식 커맨드 보드
- AI 브리핑 시스템
아이디어는 강했지만 시스템은 그렇지 못했습니다. Flask 백엔드와 Next.js 프론트엔드, 계속 확장되는 로드맵이 있었지만, 실제로 사용할 수 있는 도구라기보다 내가 원하는 모든 것의 지도에 가까웠습니다. 결국 포기하게 되었습니다.
몇 달 뒤, 도구를 직접 만들 때의 사고 방식을 바꿔줄 무언가를 발견했습니다. Ubuntu Engineering이 문서‑주도 개발(documentation‑driven development)에 대해 썼습니다. 이는 코드를 작성하기 전에 무엇을 만들지 문서화하는 방식으로, 단순 README를 넘어 제품 정의(목적, 사용자, 데이터 모델, 아키텍처, 경계, 명시적으로 아닌 것 등)를 작성하는 것입니다. 문서가 권위가 되고, 코드는 그 문서를 따릅니다.
GitHub도 spec‑kit이라는 도구를 통해 같은 원칙을 구현하고 있습니다. 구현 전에 작성된 명세가 구현 후 역설계된 명세보다 더 나은 소프트웨어를 만든다는 아이디어입니다.
저에게는 “내가 무엇을 만들고 있는지 모른 채 코딩을 시작했다”는 깨달음이었습니다. 매 세션이 코드로 시작해 답보다 질문이 더 많아졌죠. 문서‑주도 개발은 그 순서를 뒤집어 줍니다.
그래서 저는 Kumachi Dashboard를 이 접근법으로 다시 시작했습니다.
에디터에 손을 대기 전에 이틀 동안 문서를 작성했습니다. 다음을 정리했습니다:
- Kumachi가 무엇이며 명시적으로 아닌 것
- 네 개 비즈니스 코어와 그 수익 모델
- 운영 루프: 계획 → 출판 → 유입 → 확보 → 판매 → 전달 → 학습 → 반복
- 데이터 엔티티와 관계
- 기술 아키텍처와 이유
- 통합 로드맵
- 버려진 첫 번째 버전에서 얻은 교훈
- 최종 목표 지도(꿈 지도)
이 원본 문서들은 저장소의 /sources 폴더에 보관되며 절대 수정되지 않고 참조만 됩니다. 이후 /docs 폴더에 구조화된 문서로 변환하고, 그때 비로소 코드를 작성했습니다.
이전 상황
- Flask + Next.js 분리 설정
- 광범위한 마케팅 분석 범위
- 미완성된 통합 다수
- 불명확한 일일 워크플로우
- 프로젝트가 끝낼 수 없을 것처럼 느껴짐
이후 상황
- Next.js 16 App Router
- Supabase Auth, Postgres, RLS
- 창업자 전용 보호 대시보드
- 오늘 페이지(작업 및 일일 리뷰)
- 네 코어 대시보드
- 수익 센터
- 리드 CRM
- 오퍼·작업 흐름
- 향후 모듈용 플레이스홀더 페이지
- 다음 단계에 대한 Docs‑driven 로드맵
가장 의미 있는 부분은 새 앱이 내가 실제로 일하는 방식에 더 가깝다는 점입니다. Kumachi는 단순 소프트웨어 아이디어가 아니라, 나의 글쓰기·예술·서비스·제품·문화 활동·그리고 장기적으로 구축하고자 하는 것과 연결돼 있습니다.
GitHub Copilot이 가장 유용했던 점은 코드를 작성해 준 것이 아니라 맥락을 이해하고 추론해 준 것이었습니다.
원본 문서가 있었기에 매 세션이 공유된 이해에서 시작되었습니다. 예를 들어, “AGENTS.md에 정의된 네 코어 아키텍처와 데이터 스키마에 있는 리드 엔티티 정의를 바탕으로 새로운 리드를 생성하는 서버 액션을 만들어줘.”라고 말하면 Copilot은 참고할 것이 있었고, 결과물은 제품 비전과 일치했습니다.
구버전은 문서 없이 배를 병 속에 만들었다는 교훈을 줬습니다— 겉은 멋져 보이지만 내부 유지가 불가능하죠. 문서가 있으면 Copilot은 단순 코드 완성 도구가 아니라 진정한 구현 파트너가 됩니다.
프로세스 흐름은 다음과 같습니다:
- 이전 프로젝트에서 난잡한 아이디어와 교훈을 수집
- 이를 깔끔한 원본 문서로 정리
- 원본을 구조화된 문서(개념, 스키마, 시스템 설계, 단계 계획)로 변환
- Copilot을 이용해 문서에 기반한 MVP 구현 생성
- 스캐폴드를 문서와 대조— 일치하는 부분, 누락된 부분 확인
- 라우트·검증·빌드 오류·시드 데이터·미들웨어 등을 반복적으로 수정
- 공개 전/후 제출을 위한 프로젝트 준비
각 단계마다 문서가 권위였으며, 코드는 반드시 문서와 일치해야 했습니다.
Copilot은 제품 정의 단계에서도 더 좋은 질문을 하도록 도와줬습니다:
- 이것은 공개 웹사이트인가, 아니면 사내 백오피스인가?
- 이것은 트레이딩 대시보드인가? 아니요.
- 이것은 일반 CRM인가? 아니요.
- 내일 아침에 실제로 도움이 될 가장 작은 것은 무엇인가?
- 미래에만 남겨둘 것은? 지금 당장 필요한 것은?
이 질문들이 프로젝트를 바꿨습니다. 구버전은 꿈 지도였고, 새 버전은 운영 체제의 시작점입니다.
Kumachi Back Office는 완성하고 넘어갈 프로젝트가 아닙니다. 나는 비행기를 타고 만들면서 날아다니는 셈이죠. 매주 에이전시를 운영하면서 대시보드가 더 잘할 수 있는 점을 발견합니다. 놓친 클라이언트 건강 플래그, 자동으로 초안이 작성돼야 할 제안서, 일정 잡는 걸 잊어버려 미출판된 콘텐츠 등…
문서‑주도 접근법 덕분에 이러한 개선 사항이 정확히 어디에 들어가야 하는지 알 수 있습니다— 단계 문서, 로드맵, 백로그에 기록되니 사라지지 않으며 현재 스프린트를 부풀리지도 않습니다.
이 저장소의 공개 버전은 제가 구축하고 있는 시스템의 오픈소스 기반(청사진)이며, 비공개로 진행 중인 전체 시스템은 다음을 포함합니다:
- 시장 인텔리전스: 경쟁사 광고 모니터링, 일일 AI 브리핑, 산업 트렌드 추적
- 인바운드 엔진: SEO 격차 탐지, 자동 콘텐츠 브리프, 리드 스코어링
- AI 커맨드 브레인: 실시간 데이터에 대한 자연어 질의, 음성‑작업 변환, 아침 우선순위 브리핑
- 광고 전쟁실: 캠페인 이상 알림, 예산 재배분 AI, 자동 클라이언트 보고서
- 소셜 리스닝: 브랜드 언급, 감성 추적, 경쟁사 대화 모니터링
전체 비전인 God Dashboard의 아홉 영역은 이 저장소의 `docs/research/northstar