팀원 평가 작성법: 팀장이 반년을 기록에서 되짚는 순서

개발팀 팀원이 12명이면 연말평가는 12명분의 반년을 다시 꺼내는 일입니다. 마감 주에 한 사람씩 떠올리며 쓰다 보면, 칸을 채운 일이 대부분 최근 몇 주의 일이거나 팀장이 직접 본 일일 때가 있습니다. 막히는 곳은 문장보다 그 앞, 반년치 일을 다시 모으는 단계입니다. 개발팀이라면 그 반년의 일은 이슈 트래커, 코드 저장소, 문서, 팀 채널에 나뉘어 남아 있습니다.

팀원 평가를 기억으로 쓰면 무엇이 빠지나요?

빠질 수 있는 것은 세 가지입니다. 평가 기간 앞쪽의 일, 팀장이 직접 보지 못한 일, 조용히 끝나서 이야기되지 않은 일입니다. 11월에 6월 일을 떠올리려다 지난주 배포 이야기만 칸에 적고 있는 장면을 떠올려 보세요.

기억을 정리하는 방법이 평가를 바꾼다는 현장 연구가 있습니다. 두 조직에서 평가자에게 정해진 틀에 맞춰 일지를 쓰게 하거나, 정해진 틀로 기억을 되짚게 한 실험입니다. 이 방법을 쓴 뒤 평가자들은 성과 정보를 더 잘 떠올렸고, 점수가 덜 부풀려졌으며, 사람 사이와 한 사람 안의 강약을 더 잘 구분했습니다. 평가 과정에 대한 반응도 더 긍정적이었습니다.^[1]

1996년 두 조직의 결과이고, 저자도 현장에서 평가의 정확도를 재는 기준이 마땅치 않다는 한계를 함께 적었습니다. 이 글은 이 결과를 근거로, 기억을 떠올리기 전에 기록을 같은 틀로 먼저 모으는 순서를 권합니다.

팀원 N명의 반년은 어떤 순서로 되짚나요?

사람별이 아니라 도구별로 훑습니다. 한 사람씩 다섯 개 도구를 검색하면 12명이면 60번이지만, 도구 하나를 열어 팀 전체를 한 번에 보면 다섯 번이면 됩니다. 찾은 기록은 사람과 기준이 만나는 칸에 링크로 붙입니다.

1. 기준과 기간을 확정합니다. 회사 평가 기준표의 항목과 평가 기간(예: 6월~11월)을 표의 가로·세로 머리에 적습니다. 가로는 팀원, 세로는 기준입니다
2. 팀 전체의 월별 타임라인을 만듭니다. 내 캘린더, 회의록, 출시 기록을 보며 달마다 출시·장애·조직 변화를 한 줄씩 적습니다. 6월의 일이 기억에서 다시 살아나는 단계입니다
3. 도구를 하나씩 훑으며 칸에 링크를 붙입니다. 이슈 트래커, 문서, 팀 채널, 코드 저장소, 장애 기록 순서로 하루에 한두 개씩 엽니다. 장면이 분명한 기록만 골라 링크와 날짜를 붙입니다
4. 사람별로 칸을 내려 읽고 빈칸을 표시합니다. 기준마다 가장 분명한 기록 한두 건만 남기고, 기록이 없는 칸은 빈칸으로 둡니다. 기록이 마지막 두 달에 몰린 사람은 앞쪽 기간을 다시 찾습니다
5. 코멘트를 씁니다. 칸에 붙은 기록을 보며 기준, 장면, 결과 순서로 씁니다. 문장 형식이 필요하면 인사평가 코멘트 예시 50개의 막연한 문장과 고친 문장 표를 옆에 두세요

도구별로 훑으면 검색 횟수는 줄지만, 12명의 반년치 기록을 읽고 기준별로 나누는 일은 그대로 팀장에게 남습니다. 평가 시즌마다 같은 도구를 처음부터 다시 여는 일이기도 합니다.

CoSprint People은 이 수집과 분류를 대신합니다. 회사가 연결하기로 정한 업무 도구의 기록을 평가 기간 전체에서 읽고, 팀원마다 회사 기준별 근거를 원문 인용과 함께 모아 초안을 만듭니다.

평가 마감 2주 전부터 시간은 어떻게 나누나요?

앞 절반은 기록 모으기, 뒤 절반은 빈칸 확인과 코멘트 쓰기에 씁니다. 쓰는 시간보다 모으는 시간을 먼저 확보해 두면, 마지막 날 쓴 사람의 코멘트만 짧아지는 일을 막을 수 있어요.

팀원 12명, 마감일을 D로 둔 예시 일정입니다. 팀 규모와 회사 일정에 맞게 날짜를 옮겨 쓰세요.

하루에 쓸 사람 수를 정해 두면 마지막 날 몰아 쓰는 사람이 줄어듭니다.

D-1 점검에서는 기록 날짜와 도구가 한쪽에 몰리지 않았는지, 빈칸을 형용사로 채운 곳은 없는지 봅니다.

기록은 도구마다 어디를 보면 되나요?

도구마다 남는 일이 다릅니다. 평가 근거로 인용할 기록은 면담에서 팀원과 함께 다시 열어 볼 수 있는 곳에서 고릅니다. DM 등 개인 간 대화는 근거로 인용하지 않는 편이 맞습니다.

개발팀이라면 코드 저장소 행에 시간이 가장 많이 듭니다. 개발자 성과 평가 코멘트의 GitHub 검색식에서 author:아이디를 빼고 org:조직아이디 is:pr created:기간으로 팀 전체 PR을 한 번에 연 뒤 작성자별로 칸에 나누면, 이 글의 도구별 순서와 같아집니다. 기준별로 어떤 PR·리뷰가 근거가 되는지도 그 글에 정리해 두었습니다.

CoSprint People도 이 표의 이슈 트래커, 문서, 팀 채널, 코드 저장소를 도구마다 관리자 계정 하나로 연결해 같은 곳을 읽습니다. DM 등 개인 간 대화는 가져오지 않고, 메시지 수·커밋 수 같은 활동량은 점수에 쓰지 않습니다.

근거가 비는 팀원은 어떻게 쓰나요?

빈칸은 빈칸으로 두고 평가 면담 질문으로 넘깁니다. 기억으로 한 줄을 채우면 면담에서 그 문장의 근거를 물었을 때 답할 기록이 없습니다.

빈칸이 많은 사람은 먼저 이유를 나눠 봅니다.

• 기록이 덜 남는 일을 맡았거나 일한 기간이 짧은 사람: 구두 논의·페어 작업이 많거나 휴직·중간 합류가 있었다면, 역할과 일한 기간부터 확인합니다
• 팀장이 다른 일에 몰려 덜 본 사람: 기록이 정말 없는지, 그 사람이 주로 일한 채널이나 저장소를 3단계에서 열지 않았는지 먼저 확인합니다. 다른 팀 요청 채널처럼 평소 보지 않던 곳에 남아 있기도 합니다

면담 질문은 빈칸 하나에 하나씩, 장면을 묻는 형태로 씁니다. 예를 들어 ‘새 입사자의 적응을 돕는다’ 기준이 비었다면 “이번 기간에 새로 온 사람이 막혔을 때 어떻게 도왔나요? 남은 문서나 스레드가 있나요?”처럼 묻습니다.

CoSprint People도 근거를 찾지 못한 기준은 수준을 매기지 않고 빈칸으로 두고, 조직장용 면담 질문으로 정리합니다.

다음 시즌에 쓸 메모는 평소에 무엇을 남기나요?

장면이 생긴 날 한 줄을 남깁니다. 날짜, 사람, 무슨 일이 있었는지, 그 기록이 있는 곳의 링크입니다. 반년 뒤에 필요한 것은 그날의 인상보다 장면이 있던 곳입니다. 메모에는 판단 대신 링크를 남깁니다.

메모할 때를 정해 두면 놓치는 날이 줄어듭니다.

1. 출시나 큰 결정이 끝난 날
2. 장애가 닫힌 날
3. 범위나 우선순위가 바뀐 날
4. 다른 팀이 팀원을 찾아온 날
5. 팀원이 막혀서 도움을 요청한 날

메모에는 성격을 단정하는 말을 쓰지 않습니다. “꼼꼼함” 대신 “9/3 회고 문서 작성”처럼 일과 날짜를 적으면, 반년 뒤 평가 면담에서 팀원과 같은 기록을 보며 이야기할 수 있어요. 앞의 현장 연구에서도 정해진 틀로 일지를 쓰거나 기억을 되짚게 한 뒤, 평가자들이 성과 정보를 더 잘 떠올렸습니다.^[1]

출시와 장애가 몰린 달에 메모가 비어 있다면, 평가할 장면이 가장 많은 달이 비어 있는 셈입니다. 그 달을 채우려면 그 달의 도구를 다시 훑어야 합니다.

CoSprint People은 팀장의 평가 시즌에서 무엇을 대신하나요?

CoSprint People은 이 글에서 팀장이 손으로 한 일 가운데 모으기와 나누기를 대신합니다. 이슈 트래커, 문서, 팀 채널, 코드 저장소를 도구마다 관리자 계정 하나로 연결하면 평가 기간 전체의 기록을 읽고, 회사 기준마다 근거 원문 한 줄과 원문으로 가는 링크를 붙여 팀원별 평가 초안을 만듭니다. 마감 주에 도구를 다시 훑지 않아도 6월의 일이 6월 자리에 남아 있습니다.

근거를 찾지 못한 기준은 추측하지 않고 빈칸으로 두고, 평가 면담에서 물을 질문과 다음 분기에 합의할 방향을 조직장용 자료로 정리합니다. 근거마다 원문 링크가 있어 면담에서 함께 열어 볼 수 있고, PDF로 내보내 면담 자료로 씁니다. 면담에서 합의한 방향은 다음 리뷰의 ‘지난 리뷰의 개선할 점’으로 이어집니다. 최종 등급과 보상은 평가권자가 정합니다.

직원이 따로 쓸 것은 없습니다. 반기 대신 분기마다, 원하면 매달 평가할 수도 있어요. 평소 메모가 끊긴 달도 기록에서 다시 채워집니다.

모든 팀에 맞지는 않습니다. 팀원이 서너 명이라 팀장이 매주 모든 일을 직접 보고 있거나, 일이 대부분 말과 현장에서 끝나 업무 도구에 남지 않는 팀이라면 모을 기록이 적습니다. 이런 팀은 위의 타임라인, 2주 일정, 메모 한 줄 형식으로 먼저 운영하는 편이 맞습니다.