01 · PRODUCT회사 개발 환경 안에서 바이브코딩으로
프로덕션 레벨 제품을 구축했습니다.
실제 배포를 전제로 한 B2B 물류 매칭 서비스입니다.
사용자 서비스와 운영 어드민, API와 DB까지 AI 에이전트 제품팀으로 함께 만들고 있습니다.
펼치면 볼 수 있어요 · 에이전트 제품팀 · 검수 구조 · 실제 화면 6장
- 회사 서비스의 실제 사용자·운영자 업무를 제품으로 구현
- 화주 요청–파트너 제안–운영 승인·노출을 한 데이터 흐름으로 연결
- 9개 전담 Agent와 프로젝트 Skill, 공통 개발 Skill을 작업에 맞게 조합
- 회사 개발 가이드·권한·보안·물류 정책을 시스템에 반영
사용자 서비스 + 어드민견적·입찰부터 운영 승인·제재까지API + DB35개 데이터 모델과 실제 업무 규칙 연결사내 개발 환경권한·개인정보·감사로그까지 반영
회사 개발 환경 안에서 바이브코딩으로
프로덕션 레벨 제품을 구축했습니다.
실제 배포를 전제로 한 B2B 물류 매칭 서비스입니다.
사용자 서비스와 운영 어드민, API와 DB까지 AI 에이전트 제품팀으로 함께 만들고 있습니다.
펼치면 볼 수 있어요 · 에이전트 제품팀 · 검수 구조 · 실제 화면 6장
- 회사 서비스의 실제 사용자·운영자 업무를 제품으로 구현
- 화주 요청–파트너 제안–운영 승인·노출을 한 데이터 흐름으로 연결
- 9개 전담 Agent와 프로젝트 Skill, 공통 개발 Skill을 작업에 맞게 조합
- 회사 개발 가이드·권한·보안·물류 정책을 시스템에 반영
처음에는 저와 Claude Code 한 세션으로 시작했습니다.
그런데 실제 회사 제품은 화면만 그려서는 끝나지 않았습니다. 물류 정책 하나를 바꾸면 견적 화면, 어드민, DB, 권한과 안내 문구가 같이 바뀌었습니다. 놓치는 일이 생길 때마다 담당 역할과 검수 순서를 하나씩 붙였고, 지금의 에이전트 제품팀이 됐습니다.
Agent = 담당자
독립된 맥락에서 맡은 역할만 수행합니다. Planner는 정책을, 물류 전문가는 실무를, QA는 전체 연결을 판단합니다.
Skill = 작업 매뉴얼
담당자가 반드시 따라야 하는 순서와 체크리스트입니다. Agent가 바뀌어도 작업 품질과 산출물 형식이 유지됩니다.
기획부터 오픈 전 검수까지 이 순서로 움직입니다.
Spec·영향도정책·DB·연관 화면
실무 검증P0이면 구현 차단
Backend페이지·API·DB
QA·Compliance병렬 리뷰팀
결과 보고Build·잔여 이슈
프로젝트 안의 제품팀과, 필요할 때 붙이는 공통 개발 루틴
프로젝트 안에는 기획·물류·프론트엔드·백엔드·디자인·UX 문구·QA·그래픽·컴플라이언스를 맡는 9개 Agent와 10개 전용 Skill이 있습니다. 작업을 끝낼 때는 테스트와 빌드, 독립 PR 리뷰, 변경 내용 랩업처럼 프로젝트 밖의 공통 개발 루틴도 이어 붙입니다. 숫자를 크게 보이게 만드는 것보다, 어떤 변경에 누구를 부를지가 더 중요했습니다.
spec-writing화면 정책, 사용자 분기, 관련 DB와 연관 화면 영향도logistics-review5개 물류 서비스 유형, 견적 항목, 실무 엣지케이스 검증page-implementationNext.js 페이지와 컴포넌트 구현, 반응형·인터랙션backend-apiPrisma 스키마, API, mock→DB, 비즈니스 규칙design-review디자인 토큰, 간격, 타이포, 시각 일관성copy-review톤, 용어, 버튼·에러·빈 상태 문구quality-check빌드, 반응형, 화면 경계와 전체 흐름 종합 검증compliance-review권한·PII·암호화·감사로그, 개인정보 수집·보유·파기와 약관 검토3d-illustration서비스 디자인 규칙에 맞는 이미지 생성과 파일 관리폴더를 이렇게 나눈 데에도 이유가 있습니다.
new-matching/
├── CLAUDE.md # 프로젝트 규칙과 호출 기준
├── .claude/
│ ├── agents/ # 9개 제품 역할
│ │ ├── planner.md # 정책·영향도
│ │ ├── logistics-expert.md # 물류 실무 검증
│ │ ├── frontend-dev.md # 사용자·어드민 화면
│ │ ├── backend-dev.md # API·DB
│ │ ├── designer.md / ux-writer.md
│ │ ├── qa.md / graphic-designer.md
│ │ └── compliance-expert.md # 권한·개인정보·법무
│ └── skills/ # 10개 프로젝트 전용 절차
│ ├── page-orchestrator/ # 전체 순서와 차단 조건
│ ├── spec-writing/ # 정책·DB·연관 화면 영향도
│ ├── logistics-review/ # 물류 P0 검증
│ ├── page-implementation/ # Next.js 화면 구현
│ ├── backend-api/ # Prisma·API Route
│ ├── design-review/ / copy-review/
│ ├── quality-check/ # typecheck·test·build
│ ├── compliance-review/ # 배포 전 점검
│ └── 3d-illustration/
├── docs/ # 제품 판단의 원본
│ ├── SPEC.md / POLICY.md
│ ├── DATABASE.md / DESIGN.md / COPYWRITING.md
│ ├── ADMIN-SERVICE-INTEGRATION.md
│ ├── DB-WIRING-CHECKLIST.md
│ └── specs/ # 화면·권한·상태별 상세 정책
│ ├── quote-request.md / logistics.md
│ ├── account-partner-lifecycle.md
│ ├── admin-membership.md / admin-credits.md
│ └── admin-moderation.md / admin-ops.md
├── app/
│ ├── src/app/ # 사용자 서비스와 운영 어드민
│ │ ├── quote/ / logistics/ / partner/ / credits/
│ │ ├── qna/ / promotion/ / messages/
│ │ ├── admin/(console)/ # 회원·파트너·거래·콘텐츠·감사
│ │ └── api/ # 인증·견적·입찰·크레딧 API
│ ├── src/components/ / src/lib/
│ └── prisma/ # schema·migration·seed
└── _workspace*/ # 기능 단위 Agent 인수인계 기록
├── 01_planner_spec_draft.md
├── 01.5_logistics_review.md
├── 01.6_compliance_review.md
├── 02_frontend-dev_implementation.md
├── 03_designer_review.md / 03_ux-writer_review.md
├── 03_qa_report.md
└── 04_fixes.md / 05_qa_recheck.md다음 Agent에게는 말 대신 파일을 넘깁니다.
각 단계가 결과를 정해진 파일로 남깁니다. 덕분에 실패한 단계만 다시 실행할 수 있고, 무엇을 근거로 결정했는지 추적할 수 있습니다.
01_planner_spec_draft.md01.5_logistics_review.md02_frontend-dev_implementation.md03_qa_report.md05_qa_recheck.md빌드와 재검증까지 끝나야 작업이 완료됩니다.
물류 전문가가 P0 이슈를 발견하면 Planner가 Spec을 고치고 재검증하기 전까지 구현할 수 없습니다.
로그인, 권한, 개인정보, 파일, 외부 API, 어드민을 건드리면 Compliance Agent가 검토에 들어갑니다.
커밋 전 맥락 없는 리뷰어가 diff를 검토하고, 원래 세션이 제품 맥락에 따라 반영 여부와 이유를 기록합니다.
비개발 오너가 변경을 이해할 수 있도록 직관적인 설명과 이해 확인을 거친 뒤 커밋합니다.
DB가 바뀌면 Migration, Prisma Client, ERD, 데이터 사전, 검토 문서를 한 순서로 갱신합니다.
리뷰 이슈를 수정한 뒤 Build와 해당 항목을 다시 확인하고, 남은 이슈까지 보고합니다.
사용자가 남긴 요청은 운영 어드민까지 같은 흐름으로 이어집니다.
메인 화면만 만든 것이 아니라 요청 작성, 견적 탐색, 운영자의 매칭 관리와 알림 이력까지 한 제품 안에서 연결했습니다.
사용자는 필요한 물류 서비스를 찾고, 조건을 입력합니다.
처음 온 사용자도 서비스 선택부터 물류 조건 입력까지 순서대로 진행할 수 있게 만들었습니다.


사용자의 견적 요청과 운영자의 매칭 현황이 같은 데이터로 움직입니다.
사용자에게 보이는 견적 카드와 운영자가 관리하는 상태·입찰·마감 정보를 따로 만들지 않고 연결했습니다.


어드민은 매칭뿐 아니라 서비스 운영 전체를 다룹니다.
운영자는 대시보드에서 병목과 처리 대상을 확인하고, 시스템이 보낸 알림과 이력을 다시 추적할 수 있습니다.





