텃세 부리는 엔지니어에게 매니저가 제시하는 성과 기준
개발 조직을 이끌다 보면 특정 코드베이스나 도메인을 오랜 시간 도맡아 온 엔지니어가 새로 합류한 동료를 배척하는 광경을 심심찮게 목격합니다. 자신이 수년간 묵묵히 레거시 시스템을 지켜왔다는 자부심은 때로 "이 영역은 내 허락 없이 건드리지 마라"는 배타적인 텃세로 변질되곤 합니다. 더 뼈아픈 현실은 이런 태도를 보이는 엔지니어의 실제 업무 성과가 조직의 기대치에 비해 평범한 수준에 머물러 있는 경우가 많다는 점입니다.
매니저의 시선에서는 분명히 보입니다. 징계나 권고사직을 고려할 정도로 치명적인 결격 사유가 있는 것은 아니지만, 더 큰 프로젝트의 아키텍처를 총괄하거나 상위 직급으로 승진시키기에는 기술적 깊이와 문제 해결 속도가 부족합니다. 하지만 당사자는 자신이 부당하게 평가절하당하고 있으며, 회사가 자신에게 더 큰 권한과 보상을 주지 않는다고 억울해합니다. 새로 영입된 실력파 엔지니어가 자신의 영역에 들어와 더 효율적인 설계를 내놓을 때, 이를 기술적으로 넘어서기보다 정치적으로 방어하려는 모습을 보이기도 합니다.
이러한 불일치는 조직 내에 만성적인 불평과 갈등을 만들어냅니다. 매니저가 이 문제를 단순히 성격 차이나 일시적인 불만으로 치부하고 방치하면, 새로 합류한 뛰어난 엔지니어는 지쳐서 이탈하고 기존 팀원은 피해의식에 갇히는 악순환이 발생합니다. 엔지니어링 매니저는 이 괴리를 어떻게 해석하고 어떤 언어로 풀어내야 할지 명확한 기준을 세워야 합니다.
도메인 독점과 불평 뒤에 숨은 방어기제의 본질
커리어 상담 매체인 Ask a Manager에 소개된 한 관리자의 사연은 개발 현장에서도 정확히 반복됩니다. 해당 사연 속 매니저는 팀원으로 승진했을 때 특정 직원이 부당한 대우를 받는다고 생각했으나, 직접 매니징을 맡아보니 그 직원의 실제 역량이 조직 기준에서 평범한 수준에 불과했다는 사실을 깨달았습니다. 그 직원은 자신의 영역에 새로 들어온 숙련된 동료를 배척하며 자신에게 권한을 넘기라고 요구하지만, 냉정하게 보았을 때 신규 입사자가 비즈니스 요구사항을 훨씬 빠르고 효율적으로 해결하고 있었습니다.
엔지니어링 조직에서 벌어지는 영역주의(Territoriality) 역시 대부분 기술적 불안감에서 출발합니다. 특정 모듈의 히스토리를 혼자만 알고 있다는 사실은 실력이 정체된 엔지니어에게 가장 강력한 방패가 됩니다. 복잡하게 얽힌 결제 로직이나 문서화되지 않은 배치 파이프라인을 쥐고 있으면서, 다른 엔지니어가 해당 코드를 리팩터링하거나 구조를 개선하려 할 때 "도메인 맥락을 모른 채 건드리면 장애가 난다"며 리뷰 단계에서 가로막는 행태가 대표적입니다.
하지만 비즈니스는 도메인 지식을 암기하고 있는 사람보다, 그 지식을 빠르게 시스템화하고 확장성 있는 구조로 풀어내는 엔지니어를 필요로 합니다. 객관적으로 더 뛰어난 엔지니어가 들어와 며칠 만에 수동 작업을 자동화하고 테스트 커버리지를 비약적으로 높여버리면, 기존에 '도메인 수호자'를 자처하던 엔지니어는 자신의 입지가 위협받는다고 느낍니다. 그 결과 나타나는 반응이 바로 영역을 침범하지 말라는 요구와 조직에 대한 지속적인 불평입니다.
매니저는 이 현상을 감정 싸움으로 보아서는 안 됩니다. 이는 엔지니어가 자신의 시장 가치와 조직 내 위치를 객관적으로 직시하지 못해 발생하는 시스템적 마찰입니다. 묵묵히 자리를 지켰다는 사실 자체가 고성과를 보장하지는 않는다는 점을 명확히 인지시키는 것이 엔지니어링 매니지먼트의 첫 단추입니다.
평범한 성과와 높은 기대치 사이의 괴리를 다루는 기준
많은 초임 매니저들이 저지르는 실수는 팀원에게 "당신의 실력은 평범하다"거나 "기대에 못 미친다"는 식의 낙인을 직접적으로 전달하려는 시도입니다. Ask a Manager의 조언처럼, 상대방에게 '평범한 직원'이라는 평가를 전달하는 데 집중하기보다 그들이 원하는 결과(승진, 대형 프로젝트 리드, 권한 확대)를 얻기 위해 구체적으로 무엇을 다르게 증명해야 하는지에 초점을 맞춰야 합니다.
"당신은 아직 테크 리드를 맡을 실력이 아닙니다"라고 말하는 것은 반발과 방어기제만 불러일으킵니다. 대신 기대치의 기준을 명확한 엔지니어링 지표와 마일스톤으로 제시해야 합니다. 예를 들어 대규모 트래픽 분산 아키텍처를 주도하고 싶어 하는 엔지니어에게는 다음과 같은 구체적 조건을 부여하는 식입니다. 단순한 기능 구현을 넘어 해당 모듈의 지연 시간을 구조적으로 개선해 낸 이력, 동료들이 신뢰할 수 있는 기술 설계 문서(RFC)를 작성해 피드백을 수렴한 경험, 그리고 팀 전체의 배포 안정성을 높인 구체적인 실적이 뒷받침되어야 승진 심사 테이블에 올릴 수 있음을 명시해야 합니다.
실력이 뛰어난 신규 입사자와의 협업 문제도 마찬가지입니다. 신규 입사자에게 자리를 양보하라고 명령하거나 반대로 기존 팀원의 텃세를 무조건 억누르는 방식은 실패합니다. 두 엔지니어의 역할을 시스템 관점에서 분리하고 재정의해야 합니다. 신규 입사자가 뛰어난 설계 역량을 발휘할 수 있도록 아키텍처 개선을 주도하게 하되, 기존 엔지니어에게는 도메인 규칙을 명문화하고 테스트 시나리오를 설계하는 역할을 부여하여 두 사람이 경쟁이 아닌 협업을 하도록 구조를 짜야 합니다.
만약 기존 엔지니어가 이러한 역할 분담을 거부하고 여전히 "내 영역이니 손대지 마라"는 태도를 고수한다면, 매니저는 단호해져야 합니다. 코드베이스의 소유권은 개인이 아닌 조직에 있으며, 다른 팀원의 접근을 차단하는 행위 자체가 성과 평가에서 중대한 감점 요인이 된다는 사실을 1대1 미팅에서 분명히 경고해야 합니다.
변하지 않는 환경 앞에서 팀원의 불평 루프를 끊어내는 대화법
조직에 대한 만성적인 불만은 전염성이 매우 강합니다. Ask a Manager가 다룬 또 다른 사례처럼, 이미 회사의 방침이나 팀의 구조가 확정되었음에도 불구하고 1년이 넘도록 같은 문제로 불평을 쏟아내는 동료나 팀원이 존재합니다. 자신이 입사할 때 기대했던 조건과 현실이 다르다는 이유로 끊임없이 냉소를 퍼뜨리는 것은 팀의 사기를 저하시키고 협업의 에너지를 고갈시킵니다.
매니저는 팀원의 불만을 경청하는 것과 불평의 배출구가 되어주는 것을 엄격히 구분해야 합니다. 초반에는 공감과 지지가 필요하지만, 회사의 비즈니스 방향이나 기술 스택 결정처럼 단기간에 바뀔 수 없는 현실에 대해 지속적으로 불만을 제기한다면 명확한 한계를 설정해야 합니다.
이때 매니저가 취해야 할 가장 솔직하고 건강한 태도는 현실을 있는 그대로 인정하게 만드는 것입니다. "상황이 당신의 기대와 다르게 흘러갔고 그것이 답답하다는 점은 충분히 이해합니다. 하지만 현재 조직의 우선순위와 비즈니스 구조는 당분간 바뀌지 않습니다. 이제는 결정을 내려야 합니다. 이 조건과 환경을 받아들이고 그 안에서 성과를 낼 것인지, 아니면 당신의 기대를 충족할 수 있는 다른 기회를 찾아 떠날 것인지 선택해야 합니다."
이 질문은 냉정해 보이지만 사실 팀원을 진정으로 존중하는 방식입니다. 변하지 않을 환경에 갇혀 불평만 반복하는 상태는 엔지니어 개인의 커리어에도 치명적인 독이 됩니다. 기술적 성장 없이 피해의식만 쌓이다 보면 시장에서의 경쟁력마저 잃게 되기 때문입니다. 수용하고 몰입하든, 준비해서 떠나든 불행한 정체 상태에서 벗어나도록 강제하는 것이 매니저의 책무입니다.
영역 지키기를 넘어 시스템 기여로 유도하는 엔지니어링 코칭
엔지니어가 텃세를 부리고 불만을 갖는 근본적인 이유는 조직 안에서 자신의 가치가 하락하고 있다는 불안감 때문입니다. 이 불안을 해소하는 유일한 방법은 과거의 도메인 지식에 의존하는 상태에서 벗어나, 조직이 실제로 높게 평가하는 새로운 역량을 습득하도록 유도하는 것입니다.
내일부터 당장 진행하는 1대1 미팅에서 팀원의 요구사항을 역량 개발 목표로 치환해 보시기 바랍니다. 더 큰 프로젝트를 맡고 싶어 하거나 승진을 요구하는 팀원이 있다면, 감정적인 평가를 배제하고 다음 분기 동안 달성해야 할 구체적인 기술적 목표 3가지를 함께 정의해야 합니다. 타 부서와의 의존성을 해결하는 인터페이스 설계, 팀 내 병목이 되는 배포 프로세스의 자동화, 주니어 엔지니어를 온보딩시키기 위한 문서화 및 코드 리뷰 기여도처럼 객관적으로 측정 가능한 기준을 제시하십시오.
도메인은 개인이 지키는 성벽이 아니라 팀 전체가 공유해야 하는 자산입니다. 자신의 영역을 후배들에게 투명하게 넘겨주고, 더 높은 난이도의 엔지니어링 문제로 시선을 돌리는 엔지니어만이 시니어라는 직함에 걸맞은 대우를 받을 수 있습니다.
팀원이 과거의 성벽 안에 머물며 불평하도록 내버려 두지 마십시오. 현실적인 기대치를 명확히 제시하고, 그것을 넘어설 수 있는 성장 궤도로 이끄는 것이야말로 엔지니어링 매니저가 팀과 팀원 모두를 지키는 가장 확실한 방법입니다.
이 글과 함께 읽으면 좋은 인사이트
댓글 0