Commitary

코드리뷰와 함께 개발자의 커밋을 정리하는 다이어리

Timeline

2025.08

Role

Product manager, Front-end

Leveraged

서비스 기획, RAG 시스템 설계, UI/UX 디자인

Problems & Solution

개발자의 성장과 평가

개발자의 커밋에는 배움과 실행의 흔적이 남지만, 그 기록은 쉽게 흩어져 사라집니다. 개발자는 자신의 성장을 증명하느라 시간을 쓰고, 평가자는 이를 분석하느라 시간을 씁니다.

Commitary는 커밋 → 코드리뷰 → 리포트로 이어지는 단일 플로우를 통해 이 두 병목을 하나의 데이터 파이프로 통합합니다. 리뷰 과정에서 생성된 피드백과 개선 내역을 자동으로 정리해, 개발자의 커밋이 곧 성과 데이터로 전환되도록 설계했습니다.

Code review

PR을 넘어, 개인에게 집중한 코드리뷰

코드리뷰는 개발자의 사고력과 역량을 가장 정밀하게 드러내는 기술이라 판단했습니다. 이를 검증하기 위해 기존 코드리뷰 서비스를 분석하다 재밌는 부분을 발견했습니다. 대부분 PR 중심 구조로, 협업과 배포 효율을 극대화하는 데 초점이 맞춰져 있다는 것입니다.

그러나 Commitary의 목표는 팀 생산성이 아니라, 개인 개발자의 성장 궤적에 집중하는 것입니다. 따라서 PR 단위가 아닌 개인 커밋 단위로 로그를 수집하고, 이를 일별 다이어리화합니다. 이 과정에서 리뷰는 협업의 산물이 아니라, 자기 성장의 피드백 루프로 변환됩니다.

또한, Notion, Linear, Jira 등 외부 툴과 GitHub의 연동 수요를 확인했습니다. 이 통합은 단순한 코드리뷰 도구를 넘어, 개발자의 업무 전반을 연결하는 확장형 DX 인프라로 진화할 기반이 됩니다. 장기적으로는 이를 바탕으로 한국형 코드리뷰 인텔리전스 모델로 고도화할 수 있습니다.

User flow

개발자의 하루가 곧 파이프라인

Commitary의 사용자는 별도의 리소스를 쓰지 않습니다. GitHub 연동만으로 커밋 → 코드리뷰 → 리포트가 자동 연결됩니다. 매주 월요일마다 리포지토리가 스냅샷되고, 개발 활동은 자연어로 요약되어 다이어리처럼 축적됩니다. 이 플로우는 개발자의 일상적 업무 패턴을 바꾸지 않으면서도 자동 기록화와 인사이트 생성을 가능하게 합니다.

GitHub OAuth

OAuth 인증은 Next.js에서 처리하고, 인증 후의 GraphQL 요청은 서버에서 안전하게 실행합니다.

리포지토리 연동

내 GitHub 계정과 연동된 리포지토리 중, 일별 다이어리로 기록할 리포지토리를 선택합니다.

일별 작업 조회

오늘 내가 한 커밋과 변경(diff)을 날짜별로 시각화해 한눈에 확인할 수 있습니다.

AI Insight

AI가 작업을 요약(Summary), 코드 단위 분석(Detail), 피드백(Code Review)의 세 섹션으로 나누어 제공합니다.

오늘 작업 내보내기

오늘의 결과를 Markdown 복사, .md 파일, .json 파일 형태로 내보낼 수 있습니다.

RAG system

코드베이스 임베딩과 MECE 기반 RAG 설계

Commitary는 사용자의 일별 개발 활동을 코드 레벨에서 이해하기 위해, 전체 리포지토리를 컨텍스트로 활용하는 RAG 시스템을 설계했습니다. 단순히 변경된 코드(diff)를 분석하는 것만으로는 “왜 이 코드를 작성했는가”를 파악할 수 없었기 때문입니다.

따라서 전체 코드베이스를 주 단위로 스냅샷하고, 일별 커밋 변경사항을 쿼리로 사용하여 관련 코드를 검색합니다. 이로써 작업의 의도와 영향 범위를 시스템 전체 맥락에서 해석할 수 있습니다.

# 각 코드 조각은 6개 차원으로 식별됩니다
metadata = {
    "commitary_user": commitary_id,      # 누구의 코드인가
    "repo_id": repo_id,                  # 어떤 저장소인가
    "target_branch": branch,             # 어떤 브랜치인가
    "lastModifiedTime": file.last_modified_at,  # 언제 시점인가
    "filepath": file.path,               # 어떤 파일인가
    "chunk_id": f"{repo_id}_{branch}_{file.path}_{i}&quot;  # 몇 번째 조각인가
}

브랜치별 독립 컨텍스트와 MECE 원칙

전체 코드베이스를 컨텍스트로 삼으면 풍부한 정보를 얻을 수 있지만, 여러 브랜치가 동시에 개발 중일 경우 교차 참조로 인한 오분석이 발생합니다.

Commitary는 이를 MECE(Mutually Exclusive & Collectively Exhaustive) 원칙으로 해결했습니다. 각 브랜치를 독립된 코드베이스로 취급하여, 분석 시 해당 브랜치의 스냅샷만 참조하도록 데이터 레벨에서 격리했습니다.

주간 재사용 전략으로 비용 최적화

브랜치별 스냅샷은 이론상 비용이 급증할 수 있습니다. Commitary는 이를 주간 재사용 + On-Demand 생성 전략으로 해결했습니다.

스냅샷 주기를 일 단위에서 주 단위(월요일 기준)로 정규화 → 같은 주의 모든 분석은 동일 베이스라인을 참조
존재 여부 사전 검사로 중복 생성 방지
사용자가 명시한 브랜치만 분석하여 비활성 브랜치의 불필요한 저장 방지
LLM 입력 길이 제한(파일 2K, 전체 8K)로 자동 생성 코드나 대규모 리팩토링 비용 제어

# 이미 이번 주 스냅샷이 있는지 확인합니다
monday_date = today - timedelta(days=today.weekday())

cur.execute("""
    SELECT 1 FROM vector_data
    WHERE repo_id = %s
    AND target_branch = %s
    AND lastModifiedTime = %s
""", (repo_id, branch, monday_date))

if cur.fetchone():
    # 이미 있으면 재사용
    snapshot_exists = True

결과적으로, 중규모 리포지토리(50파일, 10,000줄) 기준 3개 브랜치 사용 시
월간 비용은 약 40원 수준이며, 일일 저장 대비 86% 비용 절감을 달성했습니다.

If I had more time...

다음 실행할 단계

Response 쪼개기

LLM 응답을 .json 형태로 파싱하고, 각 리뷰를 컴포넌트 단위로 조작 가능하도록 구조화합니다.

관리 퍼널 고도화

시니어·HR 관점의 대시보드와 퍼널을 설계하여, 개인의 데이터와 조직적 인사이트를 연결합니다.

User Testing & Feedback Integration

A/B 테스트를 통한 여정 데이터 수집과 피드백 루프 통합으로 제품의 개선 사이클을 완성합니다.

Back