현직 개발자가 바이브코딩으로 ERP 만드는 방송

한 줄 핵심

ERP를 화면 중심으로 만들지 말고, 도메인 스토리텔링으로 업무를 먼저 정리한 뒤 MCP 서버와 문서 기반 컨텍스트를 붙여 에이전트가 처리하게 만드는 것이 AI 네이티브한 구현 방식이다.

시간별 요약

1. 3:00
   ERP를 다시 정의하기 ERP를 복잡한 화면 제품이 아니라 회사의 인사·총무·급여·재무 업무를 다루는 장부로 재해석한다. 화면을 직접 만드는 대신 에이전트가 쓸 MCP와 서버를 중심으로 설계를 시작한다.
2. 6:00
   화면 대신 MCP를 두는 구조 기존에는 사람이 ERP 화면을 직접 사용했지만, 여기서는 사람이 에이전트에 요청하고 에이전트가 MCP를 호출하는 구조로 바꾼다. 화면 유지보수에 묶이지 않기 위해 UI를 최소화하고 서버와 로직에 집중한다.
3. 13:01
   급여 지급 도메인 인터뷰 급여 지급 기능을 만들기 전에 도메인 스토리텔링 워크숍으로 업무 흐름, 예외, 세무사 역할, 프리랜서 지급 방식, 엑셀 전달 시점까지 세세하게 인터뷰한다. 이 과정을 통해 요구사항이 PRD보다 더 구체적인 문서로 정리된다.
4. 28:02
   업무의 미래 흐름 확정 현재 업무 방식만 묻는 것이 아니라 시스템이 완성된 뒤 어떻게 일할지도 함께 정리한다. 급여 명세, 세무사 처리, 프리랜서 정정 알림, 인증·권한 같은 운영 기준이 이 단계에서 함께 고정된다.
5. 44:00
   설계 원칙과 저장 구조 맥락형 정보는 마크다운 문서로, 구조화된 데이터는 SQLite로 분리하고, MCP 도구는 서버 안의 절차로 정리한다. 컨텍스트 문서와 MCP 사용법을 함께 관리해 에이전트가 필요한 맥락을 스스로 찾게 만든다.
6. 1:03:16
   작게 시작하는 구현 전략 처음부터 ERP 전체를 만들지 말고 급여 지급 같은 단일 업무만 먼저 대응한 뒤 점진적으로 확장한다. 작은 단위로 검증하며 가는 방식이 소프트웨어 프로젝트의 실패 확률을 줄인다.
7. 1:08:01
   프레임워크와 테스트의 역할 서버 구현은 NestJS처럼 구조를 강제하는 프레임워크를 쓰는 편이 안정적이며, 검토는 실행 결과와 테스트로 확인한다. 큰 코드베이스일수록 아키텍처와 테스트가 유지보수 비용을 크게 낮춘다.
8. 1:22:01
   컨텍스트를 경제적으로 쓰는 법 도메인 스토리텔링으로 범위를 좁혀 나가면 컨텍스트 소모량이 크게 줄고, 불필요한 토큰 낭비를 막을 수 있다. 100만 토큰이 모자라는 상황은 대체로 설계와 문서화가 잘못된 신호로 본다.
9. 1:35:00
   UI 외주보다 AI와 라이브러리 디자인 외주는 제품 이해, 커뮤니케이션, 일정 관리 비용까지 커지므로 작은 SaaS나 내부 도구는 AI와 UI 라이브러리로 먼저 해결하는 편이 효율적이다. 필요한 경우 shadcn, DaisyUI 같은 컴포넌트를 활용해 빠르게 품질을 끌어올린다.
10. 1:43:00
    남길 문서와 지울 문서 구분 보고서성 스냅샷은 현재 시점의 기록일 뿐이라 자주 정리하고, 장기적으로 유효한 설계 원칙만 문서로 남긴다. 과거 코드를 주석으로 쌓아두기보다 지우고 Git으로 추적하는 편이 에이전트 작업에도 더 유리하다.
11. 1:52:00
    검토의 기준과 범위 검토는 인프라, 애플리케이션, 레이어, 모듈 순으로 큰 범주부터 보고 모듈 내부는 에이전트에게 맡기는 방식이 적절하다. 사람이 설계해야 하는 영역과 자동화에 맡길 영역을 나누는 것이 협업 품질을 좌우한다.

실무 인사이트

• ERP를 만들 때는 화면 설계보다 먼저 도메인 인터뷰 문서를 만들어야 하며, 이 문서가 곧 요구사항과 테스트의 기준이 된다.
• 컨텍스트 문서와 MCP 설계를 분리하지 말고 함께 관리하면, 에이전트가 업무 맥락을 스스로 찾는 헤드리스 ERP 구조를 만들 수 있다.
• 초기에는 한 업무만 끝까지 구현하고 검증한 뒤 확장해야 하며, 큰 기능 묶음을 한 번에 추진하면 프로젝트가 쉽게 무너진다.