이드의 HR 커피챗 시리즈
※ 내가 쓰는 글들은 개인적인 경험과 고민을 바탕으로 한 지극히 개인적인 의견이다. 특정 누군가를 비판하는 것도, 정답을 말하는 것도 아니니 가볍게 읽어주면 좋겠다. (문의 : AI 클론 채팅, 자문/컨설팅 문의 )
조직에서 성과를 이야기할 때, 우리는 보통 보이는 것부터 본다. 전환율, 계약 건수, 릴리즈 횟수, 응대 시간. 대시보드에 올라오는 숫자들. 이 숫자가 높으면 잘한 거고, 낮으면 못한 거다. 단순하고 명쾌하다. 그런데 조직에서 일을 좀 해본 사람이라면, 이 단순함이 때때로 잔인하다는 걸 안다.
분명히 기여한 것 같은데 평가에는 남지 않는 사람. 묵묵히 팀의 허리를 잡고 있었는데 숫자에는 안 잡히는 사람. 단기 성과를 포기하고 장기 구조에 투자했는데, 정작 그 분기 평가에서는 하위권이 되는 사람. 한 번쯤은 봤을 거다. 어쩌면 본인이 그 사람이었을 수도 있다.
이건 그 사람이 일을 못한 게 아니다. 성과가 없었던 것도 아니다. 다만 그 성과가 보이지 않았을 뿐이다. 정확히 말하면, 읽히지 않았다. 숫자로 측정되는 성과는 전체의 일부다. 그 숫자 뒤에는 판단이 있고, 선택이 있고, 조율이 있고, 때로는 의도적인 포기도 있다. 이걸 읽어내지 못하면, 조직은 엉뚱한 사람을 저평가하고, 진짜 기여는 묻히고, 결국 사람들은 안전한 숫자에만 매달리게 된다.
대부분의 평가는 최종 결과물을 기준으로 한다. 전환율 몇 퍼센트, 계약 몇 건, 릴리즈 몇 회. 이게 나쁜 건 아니다. 다만 이것만 보면, 그 숫자 뒤에서 어떤 판단과 선택이 있었는지가 완전히 사라진다.
콘텐츠 마케터가 분기 평가에서 하위권이었다. 유입 수가 팀 내 최하위였다. 리더도 솔직히 할 말이 없었다고 했다. 숫자가 그러니까. 그런데 이 마케터의 작업 이력을 하나씩 뜯어보니 그림이 달랐다. 당시 이 사람은 기존 콘텐츠의 SEO 구조가 근본적으로 잘못돼 있다는 걸 파악하고, 다음 분기를 겨냥해서 카테고리 체계와 내부 링크 구조를 전면 재설계하고 있었다. 당장 유입을 끌어올릴 신규 콘텐츠 제작은 의도적으로 줄인 거다. 단기 숫자를 포기하고 장기 지표에 베팅한 셈이었다.
리더에게 왜 이런 선택을 했는지 공유했느냐고 물었더니, 중간에 한 번 말했는데 그때 리더가 바빠서 깊이 듣지 못했다고 했다. 그리고 평가 시즌이 오니까, 남아 있는 건 숫자뿐이었다. 결과는 2개월 뒤에 나왔다. 재설계한 구조 위에 새 콘텐츠가 올라가면서 전환율이 1.8배 올랐고, 오가닉 유입도 전 분기 대비 2배 이상 늘었다. 그제야 리더가 말했다. 그때 그 작업이 이걸 만든 거였구나. 그런데 그 인식은 이미 평가가 끝난 뒤에 왔다.
문제는 이 사람이 하위 평가를 받은 그 분기에는, 왜 유입이 낮은지를 제대로 묻는 사람이 아무도 없었다는 거다. 숫자가 낮으면 낮은 대로 정리가 끝났다. 이 사람이 어떤 판단을 했고, 왜 그런 선택을 했고, 그게 조직에 어떤 의미인지를 읽어내는 구조가 없었던 거다.
이런 걸 읽어내려면, 리뷰할 때 숫자 옆에 맥락을 붙여야 한다.
이번 분기에 가장 어려웠던 판단은 뭐였는지
그 판단을 왜 그렇게 내렸는지
결과가 안 나왔다면, 그 과정에서 뭘 시도했고 뭘 배웠는지
그 시도가 조직에 어떤 영향을 줬는지 (당장이 아니더라도)
특히 결과가 안 좋을수록 이 질문이 더 중요하다. 성과가 잘 나온 사람한테는 숫자가 알아서 말해주지만, 성과가 안 나온 사람의 기여는 물어보지 않으면 영영 안 보이기 때문이다.
기여를 읽겠다고 해놓고, 평가 시즌에 기억을 더듬으면서 반기 전 일을 복기하는 건 무리다. 리더도 다 기억 못하고, 본인도 다 기억 못한다. 그래서 중요한 건, 일하는 과정에서 자연스럽게 흔적이 남는 구조를 만드는 것이다.
기획자가 신제품 론칭 일정을 2주 지연시켰다. 평가에서 낮은 등급을 받았다. 마감을 못 지켰으니, 수치상으로는 당연한 결과였다. 그런데 이 사람이 왜 일정을 밀었는지를 아는 사람은 같이 일한 개발팀뿐이었다. 개발 진행 중에 기술적 리스크가 발견됐고, 이 기획자가 그걸 먼저 감지했다. 일정대로 밀어붙이면 출시 후 대규모 장애가 날 수 있다는 판단이었다. 그래서 개발팀과 긴급으로 방향을 맞추고, 어디서 문제가 생겼고 앞으로 뭘 바꿔야 하는지를 정리한 회고 리포트를 직접 만들어서 공유했다.
나중에 보니, 이 리포트가 같은 제품군의 다른 프로젝트에서 사전 체크리스트로 쓰이고 있었다. 한 사람의 판단이 조직 전체의 실수를 줄이는 자산이 된 거다. 그런데 정작 이 기획자의 평가서에는 론칭 2주 지연이라는 한 줄만 남아 있었다. 회고 리포트를 만든 것도, 그게 다른 팀에 쓰인 것도, 기록으로 연결되지 않았으니까. 이 기획자가 특별히 겸손해서 기록을 안 남긴 게 아니다. 기록을 남길 구조가 없었던 거다. 프로젝트가 끝나면 다음 프로젝트로 바로 넘어갔고, 중간에 뭘 했는지를 정리하는 시간이나 형식이 없었다.
이걸 해결하는 방법은 거창할 필요가 없다.
프로젝트 회고를 습관화한다. 분기마다 한 번이 아니라, 프로젝트가 끝날 때마다 짧게라도 돌아본다. 뭐가 잘됐고, 뭐가 막혔고, 누가 어떤 역할을 했는지. 이게 쌓이면 평가 시즌에 기억을 더듬을 필요가 없다.
협업 툴에 판단의 이유를 한두 줄 남기는 습관을 잡는다. Jira 티켓이든 Notion 문서든, 왜 이 방향으로 갔는지를 짧게라도 적어두는 것. 이게 모이면 그 사람이 어떤 판단을 해왔는지가 자연스럽게 보인다.
각 포지션에서 기대하는 결과물과 기대하는 일하는 방식을 따로 정리한다. 결과만 놓고 보면 안 보이는 기여가, 일하는 방식 쪽에서 드러나는 경우가 많다. 이 둘을 분리해서 둘 다 보겠다는 합의만 있어도, 평가의 공정성이 확 달라진다.
평가를 바꾸는 것도 중요하지만, 그전에 일하면서 자연스럽게 기여의 흔적이 쌓이는 환경을 만드는 게 먼저다. 기록이 없으면 해석도 없다.
모든 평가에는 정보 비대칭이 있다. 실행한 사람은 내부 사정을 가장 잘 알지만, 평가하는 사람은 숫자와 일부 결과물만 볼 수 있다. 리더가 아무리 꼼꼼해도, 팀원이 하루하루 어떤 맥락에서 어떤 선택을 했는지를 다 파악하긴 어렵다.
개발팀에서 분기 평가를 하는데, 특정 백엔드 개발자의 평가가 중간 정도였다. 본인이 맡은 기능의 출시는 일정대로 됐지만, 특별히 눈에 띄는 성과는 없었다. 리더 리뷰도 무난했고, 셀프 리뷰도 담백했다. 딱히 올릴 이유도, 내릴 이유도 없는 평범한 평가였다.
그런데 그 분기에 처음으로 동료 피드백을 시범 운영했는데, 여기서 전혀 다른 이야기가 나왔다. 프론트엔드 개발자 두 명이 공통적으로, 이 사람 덕분에 API 연동에서 막히는 일이 거의 없었다고 썼다. 다른 백엔드 개발자와 작업할 때는 문서가 부실해서 매번 슬랙으로 물어봐야 했는데, 이 사람은 API 명세를 항상 선제적으로 정리해뒀고, 변경사항이 생기면 프론트 쪽에 바로 공유했다는 거다. 덕분에 프론트엔드 쪽 작업이 체감상 훨씬 빨라졌다고.
이건 리더도 몰랐다. 백엔드 코드가 잘 나오고 있으니 문제없다고 봤을 뿐, 그 사람이 협업 상대방의 업무 효율까지 높이고 있었다는 건 파악하지 못했다. 본인도 당연한 거라고 생각해서 셀프 리뷰에 안 썼다. 동료 피드백이 없었으면 그냥 중간 평가로 묻혔을 기여다.
이 간극을 좁히려면 보는 눈을 늘려야 한다.
셀프 리뷰: 본인이 어떤 상황에서 어떤 선택을 했는지를 직접 쓴다
리더 리뷰: 결과뿐 아니라, 관찰한 행동과 기여를 기록한다
동료 피드백: 같이 일한 사람이 체감한 기여를 한두 줄이라도 남긴다
이 세 가지를 나란히 놓고 읽으면, 숫자만으로는 보이지 않던 그림이 생긴다. 특히 성과가 낮은 사람일수록 이 병렬 구조가 중요하다. 결과가 좋은 사람은 숫자가 알아서 말해주지만, 결과가 안 나온 사람의 진짜 기여는 여러 시선이 모여야 비로소 보이기 때문이다.
다만 동료 피드백은 도입할 때 주의할 게 있다. 그냥 "동료 평가해주세요"라고 하면, 친한 사람끼리 좋은 말 써주는 것으로 끝나기 쉽다. 실제로 효과를 보려면 몇 가지 장치가 필요하다.
질문을 구체적으로 잡는다. "이 사람 어땠어요?"가 아니라 "이 프로젝트에서 이 사람이 팀에 가장 도움이 된 행동은 뭐였나요?"처럼
점수가 아니라 서술형으로 받는다. 5점 만점 몇 점 같은 건 의미 없다
피드백 대상을 랜덤이 아니라, 실제로 같이 일한 사람으로 지정한다
피드백 결과를 평가 점수에 직접 반영하기보다, 리더가 맥락을 읽는 참고 자료로 쓴다
이렇게 하면 동료 피드백이 인기투표가 아니라, 실제 협업 기여를 읽는 도구가 된다. 리뷰 문항도 살짝 바꾸면 좋다. 이번에 뭘 했나요가 아니라, 이번에 가장 어려운 상황에서 어떤 선택을 했나요로. 결과를 묻는 게 아니라, 판단을 묻는 것. 이 한 끗 차이가 평가의 질을 완전히 바꾼다.
여기까지 읽고 나면, 당장 뭔가 바꿔보고 싶어진다. 그런데 실제로 조직에서 이런 변화를 시도할 때, 거의 예외 없이 반복되는 실패 패턴이 있다. 미리 알아두면 같은 구덩이에 빠지지 않을 수 있다.
가장 흔한 케이스다. 리뷰 양식에 맥락을 묻는 항목을 추가하고, 셀프 리뷰 칸을 넣고, 동료 피드백 섹션을 만든다. 여기까지는 좋다. 그런데 정작 그 양식을 채우는 사람들한테 왜 이걸 쓰는지, 이게 어떻게 반영되는지를 설명하지 않는다. 그러면 리뷰가 그냥 숙제가 된다. 셀프 리뷰에는 이번 분기 열심히 했습니다가 적히고, 동료 피드백에는 잘했습니다 화이팅이 적힌다. 양식은 바뀌었는데 내용은 그대로인 거다.
양식을 바꾸기 전에, 이 리뷰가 실제로 어디에 어떻게 쓰이는지를 먼저 공유해야 한다. 이걸 쓰면 평가에 이렇게 반영된다, 리더가 이런 맥락으로 읽는다, 그래서 이렇게 써야 의미가 있다. 이 설명이 빠지면, 아무리 좋은 양식도 빈 껍데기가 된다.
보는 기준도 바꾸고, 기록 구조도 바꾸고, 동료 피드백도 도입하고, 리뷰 문항도 손보겠다. 의욕은 좋지만, 이걸 한 분기에 다 하면 현장이 터진다. 사람들은 갑자기 쓸 게 3배로 늘어나고, 리더는 읽을 게 3배로 늘어나고, HR은 정리할 게 3배로 늘어난다. 첫 분기에 과부하가 걸리면, 다음 분기에 다들 슬쩍 안 하기 시작한다. 그러면 원래대로 돌아간다.
작게 시작하는 게 낫다. 이번 분기에는 셀프 리뷰 문항 하나만 바꿔보겠다. 다음 분기에는 프로젝트 회고를 한 팀에서만 시범 운영해보겠다. 그다음에 동료 피드백을 붙여보겠다. 이렇게 한 바퀴 돌리면서 뭐가 되고 뭐가 안 되는지를 보는 게, 한 번에 전사 도입하는 것보다 훨씬 현실적이다.
이게 가장 근본적인 함정이다. 평가 방식을 아무리 정교하게 바꿔도, 일하는 구조가 그대로면 보이는 게 달라지지 않는다. 회의가 하루 6개인 조직에서 몰입 시간이 있었는지를 리뷰에서 물어봤자, 없었다는 답만 나온다. 브리핑이 모호한 구조에서 디자이너의 기여를 추적하겠다고 해도, 추적할 만한 기여가 구조적으로 만들어지지 않는다.
평가를 바꾸는 건 읽는 방식을 바꾸는 것이고, 구조를 바꾸는 건 읽을 거리 자체를 만드는 것이다. 순서가 반대가 되면, 좋은 평가 체계 위에 읽을 게 없는 상황이 된다. 평가 양식 손보기 전에, 일하는 구조에서 기여가 자연스럽게 드러날 수 있는 환경인지를 먼저 점검해야 한다.
생산성이라는 단어가 조직 안에서 너무 쉽게 쓰이고 있고, 그 쉬움이 착각을 만들고, 착각이 엉뚱한 사람을 몰아세우고, 진짜 문제인 구조는 그대로 남는다는 것. 숫자만 보면 사람이 안 보인다. 사람만 보면 구조가 안 보인다. 직무와 산업을 무시하면 기준 자체가 틀어진다. 그리고 리뷰 양식만 손보면, 일하는 방식은 그대로인 채 서류만 두꺼워진다.
결국 생산성을 제대로 다루려면, 숫자를 해석하는 눈, 구조를 읽는 시야, 사람의 판단과 기여를 놓치지 않는 장치. 이 세 가지가 함께 있어야 한다. 그리고 그걸 바꾸겠다면, 양식부터 손대지 말고 구조부터 봐야 하고, 한 번에 다 하려 하지 말고 작게 시작해야 한다.
HR이 조직에서 생산성 이야기를 꺼낼 때, 가장 먼저 할 일은 대시보드를 여는 게 아니다. 이 숫자가 정말 우리가 보고 싶은 걸 보여주고 있는가를 묻는 것이다. 그 질문을 던질 수 있는 사람이 조직에 있느냐 없느냐가, 생산성이라는 말이 무기가 되느냐 거울이 되느냐를 가른다. 측정은 누구나 한다. 해석은 아무나 못한다. 그리고 그 해석을 조직이 움직이는 언어로 바꾸는 건, HR이 해야 할 가장 어렵고 가장 중요한 일이다.