Skip to content

1_PRD.md

Latest commit

 

History

History
125 lines (86 loc) · 4.68 KB

1_PRD.md

File metadata and controls

125 lines (86 loc) · 4.68 KB
Raw

1. Oh My CodeReview — PRD

1.1 문제 정의

현재 AI 코드 리뷰의 핵심 문제는 단일 LLM의 시야 한계다.

하나의 LLM에 코드 리뷰를 맡기면 해당 모델의 훈련 데이터와 추론 패턴에 의존하게 된다. 보안 취약점에 강한 모델이 성능 이슈를 놓치고, React에 특화된 모델이 아키텍처 문제를 간과하는 식이다. 개발자가 직접 리뷰할 시간은 부족하고, 단일 AI 리뷰는 신뢰하기 어렵다.

구체적 문제:

  • 단일 LLM은 자신이 모르는 영역의 이슈를 "문제 없음"으로 넘긴다 (false negative)
  • 모델마다 강점이 다른데, 하나만 쓰면 다양성이 없다
  • AI 리뷰 결과에 대한 신뢰 검증 수단이 없다
  • 고성능 모델(Claude, GPT-4)만 쓰면 비용이 높다

1.2 해결 방향

여러 저비용 LLM이 독립적으로 리뷰 → 의견 충돌 시 토론 → 고성능 모델이 최종 판단. 이 구조는 학술 논문의 피어리뷰, 법원의 합의제 판결과 동일한 원리다.

핵심 가설: 저비용 모델 5개의 독립 리뷰 + 조건부 토론이, 고성능 모델 1개의 단독 리뷰보다 더 정확하고 더 저렴하다.

1.3 타겟 사용자

1차 타겟: 본인 (황준혁)

  • Jagalchi 프로젝트 6인 팀의 PR 리뷰 자동화
  • FSD 아키텍처 + React/Next.js 코드베이스
  • 리뷰어 인력 부족 문제 해결

2차 타겟: 소규모 개발팀 (2~10인)

  • 전담 리뷰어가 없는 팀
  • AI 리뷰를 보조 도구로 활용하고 싶은 팀
  • 비용에 민감한 학생/인디 개발자 팀

3차 타겟 (향후): 오픈소스 커뮤니티

  • GitHub Action으로 배포하여 누구나 PR에 붙일 수 있도록

1.4 유저 스토리

기본 플로우:

  1. 개발자가 PR을 올린다
  2. GitHub Action이 트리거되어 파이프라인이 시작된다
  3. 설정된 리뷰어 모델들이 병렬로 코드를 리뷰한다
  4. 의견 충돌이 있으면 자동으로 토론이 진행된다
  5. 최종 리뷰 결과가 PR에 inline comment로 달린다
  6. 필요하면 데스크톱 앱에서 리뷰 진행 상황과 토론 기록을 확인한다
  7. 개발자는 리뷰 결과를 보고 코드를 수정한다

세부 시나리오:

시나리오 A — 단순 PR (minor 이슈만):

  • 리뷰어 5개가 각각 minor 이슈 몇 개를 지적
  • 토론 없이 바로 종합
  • 30초 내 PR에 코멘트 게시
  • 비용: ~$0.02

시나리오 B — 복잡한 PR (의견 충돌):

  • 리뷰어 간 severity 의견 차이 발생
  • 자동 토론 2라운드 진행
  • Codex가 실제 코드 실행으로 검증
  • 헤드 에이전트가 최종 판정
  • 60초 내 완료
  • 비용: ~$0.05

시나리오 C — 위험한 PR (critical 이슈):

  • 보안 취약점 또는 데이터 손실 가능성 감지
  • 데스크톱 앱의 로컬 알림으로 개발자에게 즉시 알림
  • 인간 판단 요청
  • 개발자가 PR 결과와 데스크톱 세션 상세를 보고 직접 판단

1.5 MVP 스코프 (Phase 1)

포함:

  • config 기반 리뷰어 모델 설정
  • OpenCode CLI를 통한 병렬 리뷰 실행
  • JS 파서로 자연어 → JSON 변환
  • 토론 진입 조건 판정
  • Claude Code 기반 최종 종합
  • 터미널 출력 (Markdown 리포트)

제외 (Phase 2 이후):

  • GitHub PR inline comment 자동 게시
  • 데스크톱 앱 기반 세션/토론 시각화
  • 토론 라운드 실행
  • GitHub Action 통합
  • 피드백 루프
  • 리뷰 대시보드

1.6 성공 지표

정량 지표:

  • 리뷰 정확도: 인간 리뷰어 대비 70% 이상 이슈 탐지율 (Phase 1 목표)
  • 응답 시간: PR당 평균 60초 이내
  • 비용: PR당 $0.07 이하
  • 파싱 성공률: 리뷰어 응답의 90% 이상 JSON 변환 성공

정성 지표:

  • 리뷰 결과가 실제로 코드 품질 향상에 기여하는가
  • 개발자가 리뷰 결과를 신뢰하고 참고하는가
  • false positive (불필요한 지적) 비율이 낮은가

1.7 제약 조건

  • 예산: 학생 프로젝트이므로 월 $10 이내 운영 가능해야 함
  • 인프라: self-hosted 서버 없음. 로컬 실행 + GitHub Actions 무료 티어 활용
  • 모델 접근성: 무료/저비용 API만 사용 (DeepSeek, Qwen 등 무료 티어 활용)
  • 개발 인력: 1인 개발 (본인)
  • 일정: 2025년 상반기 내 MVP 완성 목표

1.8 리스크

  • 리뷰어 모델 API 변경/중단: config 기반이라 모델 교체로 대응
  • 파싱 실패율이 높을 경우: 프롬프트 구조를 더 엄격하게 조정하거나 LLM 기반 변환 레이어 추가
  • 토론이 오히려 품질을 낮출 경우: 토론 비활성화 옵션 제공, A/B 비교 테스트
  • 비용 초과: 리뷰어 수 줄이기, diff 크기별 리뷰어 수 동적 조절