4.74.2 노하우 은닉을 유발하는 잘못된 성과 보상 및 평가 시스템(Performance Review System)

조직 내에서 구성원이 자신의 노하우(Know-how)와 암묵지(Tacit Knowledge)를 숨기고 독점하는 행위는 흔히 개인의 이기적인 성향이나 인성 탓으로 치부되기 쉽다. 그러나 경영학적 관점과 조직 행동론(Organizational Behavior) 측면에서 지식 은닉(Knowledge Hiding) 현상의 근본적 원인을 추적해 보면, 대부분 그 기저에 ’잘못 설계된 성과 보상 및 평가 시스템(Performance Review System)’이 존재한다. 직원은 조직이 측정하고 보상하는 기준에 정확히 비례하여 자신의 행동을 동기화(Behavioral Alignment)하기 때문이다.

경영진(CEO)과 연구 개발 책임자(CTO)는 현재의 성과 평가 제도가 선량한 구성원들조차 침묵하게 만들고 지식을 사유화할 수밖에 없도록 강제하고 있지는 않은지 냉철하게 시스템 관점에서 점검해야 한다.

1. 개인지상주의적 평가 시스템의 치명적 함정

팀의 공동 목표 달성이나 소프트웨어의 중장기적 안정성보다, 오직 개인 단위의 단기적이고 가시적인 성과(Individual Visible Performance)만을 측정하는 시스템은 필연적으로 부서 내에 짙은 지식 사일로(Silo)를 낳는다.

1.1 극단적 상대평가(Relative Grading)와 제로섬(Zero-Sum) 게임 기조

제한된 재원과 승진 티켓(Quota)을 한정하여 구성원을 등수대로 줄 세우는 강제 배분식 상대평가 시스템은 동료를 협업의 대상이 아닌 완벽한 ’경쟁자’로 규정한다. 이러한 살벌한 제로섬 게임 환경에서 동료에게 나의 핵심 기술적 지식이나 트러블슈팅(Troubleshooting) 노하우를 상세히 전수해 주는 행위는, 나의 상대적 대체 불가능성(Irreplaceability)을 깎아내려 내 연봉과 스톡옵션을 타인에게 양보하는 ’순진한 자해 행위’와 다름없다. 즉, 현행 평가 체계 자체가 지식을 꽁꽁 숨기고 가르쳐 주지 않는 것을 가장 영리하고 합리적인 생존 전략(Survival Strategy)으로 보상하고 있는 모순에 빠진 것이다.

1.2 “해결사 맹신(Hero-worshipping)” 보상 문화

평소에는 아무도 모르게 주요 로직 코드를 블랙박스(Black Box)화 해두었다가, 프로덕션 환경에서 치명적인 시스템 장애(SPOF 타격)나 크리티컬 버그(Critical Bug)가 발생했을 때 혼자 나서서 문제를 뚝딱 해결해 내는 이른바 ‘소방수(Firefighter)’ 엔지니어에게 파격적인 성과급이나 최고 등급의 고과 점수를 몰아주는 문화가 지식 은닉을 극대화한다. 이러한 영웅주의적 보상 체계는, 애초에 상세한 사전 문서화(Documentation)를 통해 장애를 미연에 방지하거나 동료들과 원만하게 교차 코드 리뷰(Cross Code Review)를 촘촘히 수행하는 타 조직원들의 ’보이지 않는 예방적 헌신’을 철저히 모독하고 무시한다. 결과적으로 조직의 모든 구성원이 장애를 묵인하거나 레거시 코드를 은닉하다가 결정적인 타이밍에만 해결책을 제시하여 성과를 가로채는 마키아벨리안(Machiavellian)으로 변질되도록 유도한다.

2. 지식 자산화(Documentation & Mentoring)에 대한 보상 부재

지식은 문서화나 교육(Knowledge Transfer)이라는 지루하고 상당한 인지적 비용(Cost)을 치러야만 개인의 암묵지에서 조직의 형식지(Explicit Knowledge)로 온전히 변환될 수 있다.

2.1 MBO(목표 관리) 및 KPI에서의 지식 공유 지표 원천 누락

초기 스타트업이나 기술 문화가 성숙하지 않은 곳에서 개발자의 KPI(Key Performance Indicator)를 들여다보면, ’신규 피처(Feature) 배포 건수’나 ‘스프린트(Sprint) 마감 기한 준수율’ 등 단기적인 코드 산출물 자체만이 100% 반영되어 있는 경우가 많다. 이 상황에서 위키(Wiki) 공간에 상세한 시스템 가이드를 작성수정하거나 신규 주니어 엔지니어를 붙잡고 짝 프로그래밍(Pair Programming)으로 멘토링하는 시간은, 오롯이 개인의 목표(KPI) 달성 및 퇴근 시간을 늦추는 명백한 마이너스 요인이다. “바빠서 문서를 남길 시간이 도저히 없다“는 개발자들의 항변 저변에는 “문서를 백날 써봤자 내 인센티브나 고과에 단 1점도 반영되지 않는다“는 차갑고 정확한 손익 계산이 깔려 있다.

2.2 비가시적 성과(Invisible Performance) 측정 권한 및 로직의 부재

경영진이나 과제 관리자(PM), 인사 담당자가 기술적 깊이나 코드의 퀄리티를 식별할 역량이 부족할 경우, 단순하게 깃허브(Github)의 커밋(Commit) 수나 지라(Jira) 티켓 해결 개수 등 정량화하여 엑셀로 뽑기 쉬운 피상적인 데이터만으로 엔지니어의 퍼포먼스를 서열화하려는 유혹에 쉽게 빠진다. 이는 기존 코드의 복잡한 아키텍처를 뒤에서 묵묵히 정비(Refactoring)하거나, 타인의 난해한 코드를 리뷰하여 잠재적인 대형 버그를 예방하고 팀 전반의 생산성을 끌어올리는 ’고부가가치의 비가시적 성과’를 평가 기준에서 완벽히 소외시키는 측정 집착(Metric Fixation)의 전형적인 부작용을 낳는다.

3. 평가 체계와 지식 사일로의 인과 관계 구조 도식

수치와 경쟁 중심의 잘못된 평가 시스템이 기술 조직의 지식 생태계를 어떻게 갉아먹는지 시스템 다이내믹스(System Dynamics) 인과 지도(Causal Diagram)로 나타내면 다음과 같다.

graph TD
    A[극단적인 상대평가 및 단기 산출물 중심의 정량적 KPI 채택] -->|평가 환경 압박| B[동료를 협업자가 아닌 잠재적 경쟁자로 인식]
    B -->|방어적 행동| C[자발적 멘토링 기피, 문서화 회피 및 핵심 코드 노하우 은닉]
    C -->|보상 체계의 헛점| D[시스템 장애 발생 시 단독 '해결사'로 등장하여 영웅 취급 및 초과 보상 획득]
    A -->|영향| E[지식 전수 및 코드 리뷰 등 이타적 행위에 대한 노력적·시간적 무보상]
    E --> C
    D -->|침묵의 강화 피드백| A

4. 지식 생태계 복원을 위한 평가 체계 재설계 제언

노하우 은닉의 지독한 고리를 끊어내기 위해서는 경영진이 개입하여 조직의 지식 생태계를 복원하는 상생의 방향으로 평가 및 보상 체계를 전면 재설계(Redesign)해야만 한다.

지식 협업 지표(Knowledge Collaboration Metric)의 핵심 KPI 편입: 조직 내 공유 위키(Confluence, Notion 등) 작성 건수와 피드백, 아키텍처 결정 기록(ADR) 작성 수준, 코드 리뷰(PR) 과정에서의 품질적 기여도, 사내 테크 세미나 발표 실적 등 지식 자산화 기여도를 개인 성과 평가의 20~30% 이상 필수적인 가중치로 강제 반영해야 한다.
절대평가(Absolute Grading) 또는 팀 기반 OKR의 도입: 한정된 파이(Pie)를 놓고 뺏기 다툼을 벌이는 비율 할당식 제로섬 평가를 점진적으로 폐지해야 한다. 팀과 조직의 공동 목표에 얼마나 유기적으로 기여했는지를 절대적인 기준으로 측정하는 성과 관리 체계(예: OKR)로 전환하여, ’동료의 피처 성공과 기술적 성장이 곧 나의 성과표 달성률 상승’으로 온전히 직결되도록 구조를 엮어야 한다.
영웅주의 타파 및 블레임리스(Blameless) Post-mortem 보상: 장애를 단독으로 해결한 일회성 성과보다, 장애가 팀 전체의 집단 지성으로 투명하게 공유되고 영구적인 시스템 로직 개선(Blameless Post-mortem)으로 이어진 구체적 사례에 개인이 아닌 팀 전체 단위의 더 높은 조직적 보상(Team Reward)을 제공함으로써, 지식의 투명한 공론화가 곧 가장 안전하고 확실한 수익(조직 인정)임을 깨닫게 해야 한다.