
PM이 마음 놓고 커밋하는 리포지토리는 어떻게 만들까?
두줄요약
PM이 페르소나·프롬프트를 직접 수정하고 커밋할 수 있는 가상 유저 패널 리포지토리 구조를 소개했습니다.\n레이어 린트와 테스트·CI, LLM 기반 검증으로 변경 범위와 리뷰 책임을 분리했습니다.
문제 상황
- 기획 문서를 개발 요건으로 재가공하는 반복 과정과 PM의 제한된 개발 참여 범위
- 리서치 자료 분산으로 시안·아이디어 단계에서 유저 반응을 빠르게 검증하기 어려운 상황
구조와 흐름
- 리서치 기반 페르소나 캐논 JSON과 프롬프트를 서비스 코드 밖 PM 전용 폴더에 분리
- 웹 UI·CLI·MCP 서버가 adapters를 통해 동일한 캐논·프롬프트 원본 사용
- 모노레포의 shared·entities·usecases·adapters·frameworks 레이어와 단방향 의존 구조
해결 방법
- ESLint flat config와 eslint-plugin-boundaries로 레이어별 import·외부 패키지 사용 제한
- 캐논 무결성·분포·용어 대응·프롬프트 버전 기록을 테스트와 CI로 검증
- 골든셋 기반 LLM-as-a-Judge로 이슈 재현율·점수 일관성·답변 일관성 평가
성능/운영 포인트
- 자동 검사는 규칙 준수 확인, 개발자 리뷰는 규칙 변경의 적절성과 실제 동작 검증에 집중
- PM 변경 PR에도 린트·타입 검사·테스트·UI 스모크 테스트 적용
- PM 관리 파일 분리, 의존 규칙 린트화, 필수 조건 테스트화부터 시작하는 적용 순서



