개발자 성과 평가 코멘트: 커밋 수 대신 PR·리뷰로 쓰는 예시

개발자 성과 평가에 커밋 수·PR 수를 쓰면 안 되는 이유는 무엇인가요?

활동량은 일이 많았다는 것만 알려 주고, 그 일이 잘된 일인지는 알려 주지 않습니다. 같은 커밋 수가 좋은 설계에서 나올 수도, 잘못된 계획을 몸으로 메운 결과일 수도 있습니다.

개발자 생산성 연구를 정리한 SPACE 프레임워크 논문은 이 점을 직접 다룹니다. 활동이 많아 보이는 이유는 나쁜 시스템이나 부족한 계획을 오래 일해서 메우는 경우일 수도, 도구와 협업이 좋아진 경우일 수도 있는데, 활동 지표만으로는 어느 쪽인지 알 수 없습니다. 그래서 논문은 활동 지표만 따로 떼어 개발자 보상이나 불이익에 써서는 안 된다고 정리했습니다. PR 수, 커밋 수, 리뷰 수 같은 단순한 숫자도 데이터 누락과 측정 오류가 있고, 페어 프로그래밍이나 함께 아이디어를 낸 협업은 이런 숫자에 잡히지 않는다고 봤습니다.^[1]

숫자를 목표로 거는 일의 위험은 팀 단위 지표에서도 지적됩니다. 구글 클라우드의 DORA 가이드는 배포 빈도 같은 팀의 소프트웨어 전달 지표를 다루면서, 지표를 목표로 정하면 팀이 지표를 맞추려 들 가능성이 커진다고 경고합니다(굿하트의 법칙). 이 가이드는 개인 평가를 직접 다루지 않지만, 지표를 서비스 단위로 적용하라고 안내합니다.^[2] 개인 커밋 수를 평가에 걸면 커밋을 잘게 쪼개는 식으로 숫자만 늘어나는 장면을 떠올려 볼 수 있습니다.

최근 한 인터뷰에서 오픈소스 메인테이너 한 사람은 AI로 코드를 한 번에 만들 수 있게 되면서, 그 코드를 처음 비판적으로 따져 보는 일이 검토하는 사람 몫으로 넘어오기도 한다고 말했습니다.^[4] AI 도구로 코드를 쓰는 팀이라면 코드 양보다 PR 설명과 리뷰에 남은 판단을 근거로 보세요.

SPACE 논문은 개인 평가 방법을 다루지 않고, 개발자 프라이버시를 지키려면 결과를 팀·그룹 단위의 익명 집계로만 보고하라고 권합니다.^[1] 다만 숫자만으로는 무엇이 잘됐는지 알 수 없다는 결론은 개인 코멘트에도 그대로 적용됩니다.

반년치 기록에서 근거는 어떻게 찾나요?

팀원 한 사람씩 PR·리뷰·이슈·장애 기록·문서를 차례로 검색하고, 찾은 기록을 회사의 평가 기준별로 나눕니다. 기억이 아니라 기록에서 출발하면 평가 기간 앞쪽의 설계 판단과 출시 전에 막아 낸 버그까지 다시 확인할 수 있어요.

사람 한 명당 찾는 순서 (평가 기간이 6월~11월인 경우)

1. 본인이 올린 PR: GitHub 검색창에 org:조직아이디 is:pr author:아이디 created:2026-06-01..2026-11-30. 제목만 보지 말고 PR 설명에 ‘왜 이렇게 했는지’를 쓴 것을 골라 둡니다
2. 본인이 남긴 리뷰: org:조직아이디 is:pr reviewed-by:아이디 created:2026-06-01..2026-11-30. created:는 리뷰한 날이 아니라 PR을 만든 날 기준이라, 기간 직전에 열린 PR은 날짜를 조금 앞당겨 찾습니다. 승인만 누른 것은 건너뛰고, 버그·설계·대안을 짚은 코멘트가 있는 PR만 남깁니다
3. 이슈 트래커: Jira라면 assignee was "이름" AND resolved >= "2026-06-01"(이름 자리에는 이름 또는 계정 ID). 범위를 줄이거나 우선순위를 바꾼 코멘트가 있는 이슈를 고릅니다
4. 장애 기록: 장애 채널의 타임라인과 포스트모템 문서에서 그 사람이 원인을 찾거나 재발 방지를 맡은 부분
5. 설계 문서·위키: 작성자나 댓글 작성자로 그 사람이 들어간 문서
6. 고른 기록을 기준별로 나눔: 기준마다 가장 분명한 기록 한두 건. 기준에 맞는 기록이 없으면 빈칸으로 둡니다

여기까지 하면 팀원 한 사람의 근거 목록이 생깁니다. 문제는 이 일을 팀원 수만큼 반복해야 한다는 점입니다. 팀원이 열두 명이면 다섯 곳을 열두 번 검색하고, 찾은 기록을 열두 명분 기준별로 나눠야 합니다.

CoSprint People은 이 검색과 분류를 대신합니다. GitHub·GitLab·Jira·Linear 같은 개발 도구와 설계 문서·팀 채널을 연결하면 평가 기간 전체의 PR·리뷰 코멘트·이슈·문서에서 회사 기준마다 근거를 찾아 원문을 인용하고, 커밋 수 같은 활동량은 점수에 쓰지 않습니다.

기준마다 어떤 기록이 근거가 되나요?

기준마다 그 사람의 판단이 글로 남는 곳이 따로 있습니다. 회사의 레벨 정의나 평가 기준표가 있다면 아래 표의 기준 이름을 그 항목으로 바꿔 쓰세요.

코드 리뷰 행은 특히 건수가 아니라 내용으로 봐야 합니다. 2013년 Microsoft 여러 팀의 리뷰 관행을 관찰하고 리뷰 코멘트 수백 건을 분류한 연구에서, 결함 발견은 여전히 리뷰의 주된 동기였습니다. 다만 실제 리뷰에서 결함이 차지하는 비중은 기대보다 작았고, 지식 전달, 팀의 상황 공유, 다른 해법 제시 같은 이점이 함께 나타났습니다.^[3] 한 회사의 10여 년 전 관행을 본 연구라는 한계가 있습니다. 이 글은 이 결과를 근거로, 리뷰 코멘트를 코드 리뷰 기준뿐 아니라 지식 공유 기준의 근거로도 읽기를 권합니다.

SPACE 논문도 사기를 북돋우고, 멘토링하고, 지식을 나누는 일이 생산적인 환경을 받치지만 흔히 측정되지 않는 ‘보이지 않는 일’이라고 짚었습니다.^[1] 숫자로는 안 보이지만 문서와 리뷰 스레드에는 글로 남습니다. CoSprint People도 이 표의 가운데 열처럼 판단이 글로 남은 기록(설계 문서, 이슈 코멘트, 장애 회고 등)을 기준별 근거로 인용합니다.

코멘트 한 문장은 어떤 순서로 쓰나요?

기준, 장면(언제·무엇을), 결과, 다음 기간의 기대 순서로 씁니다. 장면에는 찾아 둔 기록의 이름을 그대로 적습니다. 비개발자인 대표나 인사 담당자가 읽어도 무엇을 판단했는지 알 수 있게, 기술 용어 뒤에 그 판단이 왜 중요했는지 한 구절을 붙입니다.

막연한 코멘트와 근거가 붙은 코멘트

기준별 코멘트 예시

예시의 숫자와 날짜는 형식을 보여 주는 가상 값입니다. 실제 코멘트에는 찾아 둔 기록에 있는 사실만 씁니다. 평가 등급을 정하는 표 양식이 필요하다면 근거 칸이 있는 인사고과 평가표 양식을 함께 쓸 수 있어요.

CoSprint People도 근거마다 무엇을 판단했는지 풀어 써서, 비개발자 평가자도 읽을 수 있게 정리합니다.

근거가 없거나 한쪽으로 쏠렸을 때는 어떻게 하나요?

근거가 없는 기준은 빈칸으로 두고 면담 질문으로 넘깁니다. 기억으로 한 줄을 채우기보다, 그 기준에서 무엇을 했는지 면담에서 직접 묻는 편을 권합니다.

기록이 한쪽으로 쏠리는 경우도 미리 점검합니다.

• 휴직·휴가가 낀 기간: SPACE 논문은 1년 단위로 지표를 보면 육아휴직을 쓴 사람에게 불리하게 기운다고 짚었습니다.^[1] 근거의 개수가 아니라 일한 기간 안에서 판단의 수준을 봅니다
• 기록이 남지 않는 일을 맡은 사람: 페어 프로그래밍, 구두로 끝난 설계 논의, 다른 팀 지원은 PR에 덜 남습니다. 빈칸이 많다면 그 사람의 역할부터 확인합니다
• 팀 과제의 결과: 결과는 팀의 것으로 적고, 그 안에서 그 사람이 맡은 결정만 그 사람의 근거로 씁니다
• 최근 일에 쏠린 근거: 고른 기록이 평가 기간 마지막 두 달에 몰려 있다면 앞쪽 기간을 다시 검색합니다

CoSprint People은 마지막 몇 주가 아니라 평가 기간 전체의 기록을 같은 방식으로 읽고, 근거를 찾지 못한 기준은 빈칸으로 두어 면담 질문으로 넘깁니다.

팀장마다 근거를 고르는 기준이 다르면 팀 사이 비교가 어려워집니다. 연말 보정 회의를 앞두고 있다면 인사평가 캘리브레이션 회의 운영법에서 근거 시트를 같은 형식으로 맞추는 방법을 참고하세요.

코멘트를 다 쓴 뒤에는 무엇을 확인하나요?

제출 전에 팀원 전체의 코멘트를 한 표에 놓고 세 가지를 확인합니다. 한 사람씩 쓸 때는 보이지 않던 차이가 여기서 드러납니다.

세 가지를 손으로 맞추려면, 코멘트를 쓰기 전에 평가 기간 전체의 기록을 여러 도구에서 사람마다 같은 형식으로 모아 둬야 합니다.

CoSprint People은 개발팀 연말평가에서 무엇을 대신하나요?

CoSprint People은 GitHub·GitLab·Jira·Linear와 설계 문서·팀 채널을 관리자 승인 한 번으로 연결하고, 레벨 정의나 기술 문서로 회사의 엔지니어링 기준을 만든 뒤 그 기준으로 평가 초안을 만듭니다. 평가 기간 전체의 기록에서 기준마다 근거를 찾아 원문을 인용합니다. 메시지 수·커밋 수·접속 시간 같은 활동량은 점수에 쓰지 않습니다.

근거를 찾지 못한 기준은 추측하지 않고 빈칸으로 두고, 기록에서 막힌 지점과 함께 면담 질문으로 정리합니다. 코드 저장소·이슈·문서·팀 채널처럼 회사가 연결하기로 정한 도구만 읽고, DM 등 개인 간 대화는 가져오지 않습니다. 최종 등급과 보상은 평가권자가 정합니다. 개발 조직에서 쓰는 방식은 개발 조직 리더용 소개에서 볼 수 있어요.

모든 개발 조직에 맞지는 않습니다. 설계 논의와 리뷰가 대부분 말로 끝나고 PR 설명이나 문서에 남지 않는 팀이라면 모을 근거가 적습니다. 이런 팀은 위의 검색 순서와 코멘트 표로 먼저 운영하면서, 판단을 PR 설명과 설계 문서에 남기는 습관부터 만드는 편이 맞습니다.