내가 싫어했던 매니저가 나에게 가르쳐준 교훈

• 지금은 엔지니어링 매니저가 되었지만 내가 소프트웨어 엔지니어로 일하던 시절, 복잡한 기능을 며칠간 작업해 PR를 올렸음
• 피드백은 단호하고 냉정했음 “오버 엔지니어링임. 복잡함. 리팩토링하시오”는 간단한 문장이 전부였음
• 칭찬 한마디 없이 비판만 받은 경험에 분노했으나, 그 매니저와의 일화는 단지 시작에 불과했음

감정을 배려하지 않는 리더 스타일

• 이 매니저는 기존에 알고 있던 리더들과 달랐음
• 손을 잡아주지도, 부드러운 말도 하지 않음
• 다음과 같은 특징이 있었음
  • 설익은 아이디어는 바로 거절함
  • 복잡함을 위한 복잡함을 싫어함
  • 깔끔하고 유지 보수 가능한 효율적인 코드만 중요시함
• 회고에서도 돌려 말하지 않고 문제를 직접 지적함
• 처음에는 냉혹한 성격이라 생각했지만, 그 이면에는 다른 철학이 있었음

자존심을 흔든 피드백의 전환점

• 스프린트 리뷰에서 자신 있는 기능을 시연했지만 매니저는 중간에 끊고 물음

  “이건 취약해. 부하 상황에선 어떻게 돼? 롤백 계획은?”

• 대답을 제대로 하지 못하자 매니저는 말함:

  “지금 넌 코더처럼 생각하고 있어. 엔지니어처럼 생각해야 해”

• 처음엔 화났지만, 결국 스스로의 코드 스타일이 회복력보다는 영리함에 치중했다는 걸 자각하게 됨

진짜 교훈: 그 매니저는 나를 개인적으로 공격한 게 아니었음

• 사고방식에 큰 변화가 생김
  • “똑똑한” 코드 대신 읽기 쉬운 코드를 작성함
  • 실패 상황을 대비한 설계에 집중함
  • 본인을 위한 코드가 아니라 후속 개발자를 위한 코드를 작성함
• 이후 그 매니저의 코드 리뷰는 거침없이 통과됨
• 매니저가 달라진 게 아니라, 나 자신이 성장했기 때문임

내 리더십 스타일에 남긴 영향

• 엔지니어링 매니저가 된 후 그 경험을 많이 떠올렸음
• 사람들이 싫어하는 리더는 되고 싶지 않았지만, 부드럽기만 한 리더도 되고 싶지 않았음
• 다음과 같은 방식으로 스타일을 정립함
  • 배경 설명이 있는 직설적인 피드백을 줌
  • 시스템적 사고를 강조함
  • 높은 기준은 유지하되 인간적인 피드백을 제공함
• 엔지니어들은 도전받는 걸 원하지만 무시당하는 느낌은 싫어함

단호한 매니저가 필요할 때

• 리더십에는 자존심, 마감, 압박이 얽혀 있어 혼란스러움
• 단호한 매니저는 다음을 통해 이 혼란을 걷어냄
  • 기능이 아닌 확장성을 생각하게 함
  • 영리한 코드보다 유지 가능한 코드를 쓰게 함
  • 실패와 예외 상황을 미리 대비하게 함
• 감정보다 코드의 생존 가능성을 더 중요하게 여김

단호한 매니저 아래에서 생존하고 성장하는 방법

• 숨 막히는 리더 아래에 있다면 다음과 같이 대처할 수 있음
  • 개인적인 공격으로 받아들이지 말 것: 피드백은 코드에 대한 것
  • 피드백 이후 “왜?”를 물어볼 것: 대부분 단호한 리더는 호기심을 존중함
  • 실패 지점을 스스로 먼저 생각해 볼 것: 매니저처럼 사고하기 시작해야 함
• 리더라면 다음을 실천해야 함
  • 높은 기준을 제시하되, 그 기준이 중요한 이유를 설명할 것
  • 모호한 피드백 대신 구체적으로 말할 것
  • 성공보다 성장을 축하할 것: 개발자가 매니저보다 먼저 문제를 포착했다면 칭찬할 것

거절된 Pull Request가 준 최고의 선물

• 처음엔 자존심이 상했지만, 지금 돌아보면 그 거절된 PR은 인생 최고의 기회였음
• 코딩을 개인 프로젝트가 아닌 시스템 구축으로 보게 되는 계기였음
• 단호한 매니저는 기분을 좋게 해주진 않지만, 개발자로서 성장하게 함
• 진정한 성장은 PR이 통과될 때가 아니라, 거절될 때 시작됨