올해부터 엔지니어링 팀을 맡으면서, 성과 평가가 “받는 것"에서 “제가 운영해야 하는 것"으로 바뀌었습니다. 이 글은 제 생각을 정리하는 목적도 있으니, 정답이라기보다는 아직 배워가는 사람의 메모로 읽어주시면 좋겠습니다.
애초에 평가를 왜 하는가#
직급이 무엇이든, 목적은 결국 두 가지입니다. 계속 배울 수 있게 하는 것, 그리고 역할의 기대치를 넘어서는 사람이 제대로 보상받게 하는 것.
“평가할 시간도 여력도 없다"는 작은 회사가 많습니다. 그런 회사는 결국 근속 연수 하나만 보고 누가 시니어가 될 준비가 됐는지 정하게 되죠. 저는 이게 실수라고 생각합니다. 근속이 게으른 지표라서만이 아닙니다. 평가를 생략하면 회사와 직원 사이의 양방향 채널이 사라지고, 일하는 관계 자체가 상하기 때문입니다.
이건 양쪽 모두에 해당합니다. 본인은 회사를 위해 최선이라고 진심으로 믿는 방식으로 일하고 있어도, 습관이나 방법론, 커뮤니케이션 스타일이 안 좋은 쪽으로 흘러갈 수 있습니다. 피드백이 없으면 아무도 그걸 잡아주지 못합니다. 반대로 구조화된 자리에서 직원들의 이야기를 듣지 않는 회사는, 직원들이 회사를 어떻게 생각하는지 모른 채 편안하게 지내게 됩니다.
서로 무엇을 기대하고 들어와야 하나#
직원 입장에서 기대할 것은 복잡하지 않습니다. 내 일이 팀 목표와 어떻게 연결되는지, 뭘 잘하고 있고 어딜 고쳐야 하는지 알고 싶어 합니다. 그것도 “커뮤니케이션을 더 잘하세요"가 아니라 구체적으로요. 기여를 인정받고 싶고, 커리어와 교육에 대한 진짜 대화를 원하고, 사내 정치가 아니라 일 자체에 기반한 공정한 프로세스를 원합니다.
매니저인 제 입장에서는, 우선 자기 평가를 준비해 오길 기대합니다. 뭐가 잘됐고 뭐가 아쉬웠는지 본인의 시각을 듣고 싶거든요. 변호인의 모두진술이 아니라 피드백에 열린 자세를 바라고, 앞으로의 목표에 대한 진솔한 논의, 그리고 팀 안에서 본인이 어떻게 맞물려 있다고 느끼는지에 대한 솔직한 이야기를 기대합니다. 평가는 제 계획의 시간이기도 합니다. 팀 구성, 승진 후보, 누구에게 어떤 성장 기회가 필요한지.
하나의 틀이 모든 엔지니어에게 맞지는 않는다#
엔지니어링 팀에는 문화적 배경도, 연차도, 전문 분야도 다른 사람들이 모여 있습니다. 같은 대본이 모두에게 통할 리 없죠. “똑같이 대하는 것"과 “공정하게 대하는 것"은 다른 얘기고, 방식은 각자의 필요, 커리어 단계, 기여에 맞춰 구부러져야 합니다. 기본은 각 엔지니어의 역할과 책임이 명확하고, 그것이 보상과 실제로 맞아떨어지게 하는 것입니다.
제일 꼬이기 쉬운 지점이 직급과 연봉입니다. 타이틀이 애매하다고 느끼거나 승진할 준비가 됐다고 생각하는 사람에게, 두루뭉술한 격려는 독입니다. 통하는 건 구체성입니다. 다음 직급의 기준이 될 구체적인 도전 과제나 프로젝트 목표에 합의해서, 승진이 ‘분위기’가 아니라 객관적 기준이 되게 하는 것. 보상도 마찬가지입니다. 연봉이 낮다고 느끼거나 더 큰 책임을 원하는 사람에게는, 다음 평가 전까지 무엇을 달성해야 그 변화가 정당화되는지 측정 가능한 목표를 플랜에 적어 넣습니다. 그리고 다음 평가에서는 양쪽 모두 그 약속 앞에 정직해져야 합니다.
개선 피드백도 같은 원칙입니다. 특정한 갭을 겨냥한 특정 교육 프로그램, 워크숍, 프로젝트는 도움이 됩니다. “계속 역량을 키우세요"는 도움이 안 됩니다.
기준선은 첫 미팅에서 시작된다#
새 팀원과의 첫 평가 미팅은 거의 기준선을 잡는 시간입니다. 역할이 실제로 무엇을 포함하는지, 그게 팀과 회사 목표에 어떻게 이어지는지 같이 확인하고, 성과를 판단할 측정 가능한 결과에 합의하고, 단기와 장기 목표를 세웁니다. 컬처와 기대되는 행동, 피드백이 언제 어떻게 오는지, 쓸 수 있는 리소스와 멘토링, 그 자리에서 보이는 커리어 패스를 이야기하기에도 좋은 타이밍입니다. 어느 것도 짜릿하진 않지만, 이걸 해두면 이후의 모든 평가가 쉬워집니다.
그 이후에 쓰는 아젠다#
- 스몰토크. 사소해 보여도 이걸로 긴장이 풀리고, 이후 대화가 훨씬 솔직해집니다.
- 아젠다 훑기. 어느 쪽도 주제에 기습당하지 않도록.
- 지난 평가 이후의 성장. 발전은 명시적으로 짚어줍니다. 본인은 의외로 모르거든요.
- 현재 성과. 강점부터.
- 개선할 부분. 각각 구체적이고 현실적인 목표를 붙여서.
- 커리어 계획. 지금 하는 일이 실제로 그 방향을 향하고 있는지도 함께.
- 다음 평가까지의 타깃, 목표, 액션 아이템.
KPI는 개인 맞춤이어야 작동한다#
프로덕트 팀 엔지니어의 KPI는 팀 목표와 개인 양쪽에 맞아야 합니다. 프론트엔드, 백엔드, 풀스택의 역할이 다르고, 주니어와 시니어의 차이는 더 큽니다. 커밋 수는 주니어 개발자에 대해 뭔가 말해줄 수 있을지 몰라도, 주요 산출물이 아키텍처 의사결정인 시니어 엔지니어에 대해서는 아무것도 말해주지 않습니다. 그래서 KPI는 템플릿을 복사하는 게 아니라 대화 속에서 정하는 겁니다.
제가 보는 영역은 이렇습니다.
- 코드 품질: 에러율, 코딩 표준 준수, 버그 수정이 필요해지는 빈도
- 프로젝트 딜리버리: 마일스톤과 마감 준수
- 혁신과 문제 해결: 효율 개선, 어려운 문제를 실제로 풀어냈는지
- 협업: 피어 리뷰, 팀 목표와 논의에 대한 기여
- 자기 계발: 학습 목표 달성, 자격증, 새로 익힌 기술
- 고객 임팩트: 사용자 피드백, 출시한 기능의 사용 지표
측정 가능한 지표 쪽에서는 요즘 유닛 테스트에 관심이 갑니다. InfoQ의 이 글은 유닛 테스트를 성과 평가에 녹이는 방법을 다루는데, 실무적인 구현과 팀 문화에 미치는 영향을 함께 짚습니다. 코드 건강도를 정성·정량 양쪽으로 보자는 주장이라, 엔지니어를 코드 줄 수로 환원하지 않는 KPI를 찾고 있다면 읽어볼 만합니다.
무엇을 고르든 평가나 1:1에서 함께 합의하고, 역할과 프로젝트와 기술이 바뀌는 만큼 다시 들여다봐야 합니다. 아무도 합의하지 않은 KPI는 그냥 몽둥이일 뿐입니다.
기록으로 남기기#
미팅이 끝나면 요약을 씁니다. 논의한 핵심, 제기된 이슈, 액션 아이템, 서로 합의한 목표. 관료적으로 들리지만, 이 기록이 있어야 여섯 달 뒤의 “그런 약속 한 적 없는데요” 대화를 막을 수 있습니다. 문서화된 이슈는 증발하지 않고 추적되고, 액션 아이템은 다음 평가의 첫 아젠다가 되고, 문서에 적힌 목표는 훨씬 진지하게 다뤄집니다.
결국 시스템의 전부는 이겁니다. 첫날부터 기대치를 명확히 하고, KPI는 사람에 맞춰 만들고, 전부 기록하고, 모든 액션 아이템을 팔로업하는 것. 양방향 대화와 측정 가능한 결과가 없는 평가는 체크박스 놀음이고, 엔지니어들은 캘린더 초대만 봐도 체크박스 놀음 냄새를 맡습니다.