내가 싫어했던 매니저가 나에게 가르쳐준 교훈
(blog4ems.com)- 지금은 엔지니어링 매니저가 되었지만 내가 소프트웨어 엔지니어로 일하던 시절, 복잡한 기능을 며칠간 작업해 PR를 올렸음
- 피드백은 단호하고 냉정했음 “오버 엔지니어링임. 복잡함. 리팩토링하시오”는 간단한 문장이 전부였음
- 칭찬 한마디 없이 비판만 받은 경험에 분노했으나, 그 매니저와의 일화는 단지 시작에 불과했음
감정을 배려하지 않는 리더 스타일
- 이 매니저는 기존에 알고 있던 리더들과 달랐음
- 손을 잡아주지도, 부드러운 말도 하지 않음
- 다음과 같은 특징이 있었음
- 설익은 아이디어는 바로 거절함
- 복잡함을 위한 복잡함을 싫어함
- 깔끔하고 유지 보수 가능한 효율적인 코드만 중요시함
- 회고에서도 돌려 말하지 않고 문제를 직접 지적함
- 처음에는 냉혹한 성격이라 생각했지만, 그 이면에는 다른 철학이 있었음
자존심을 흔든 피드백의 전환점
- 스프린트 리뷰에서 자신 있는 기능을 시연했지만 매니저는 중간에 끊고 물음
“이건 취약해. 부하 상황에선 어떻게 돼? 롤백 계획은?”
- 대답을 제대로 하지 못하자 매니저는 말함:
“지금 넌 코더처럼 생각하고 있어. 엔지니어처럼 생각해야 해”
- 처음엔 화났지만, 결국 스스로의 코드 스타일이 회복력보다는 영리함에 치중했다는 걸 자각하게 됨
진짜 교훈: 그 매니저는 나를 개인적으로 공격한 게 아니었음
- 사고방식에 큰 변화가 생김
- “똑똑한” 코드 대신 읽기 쉬운 코드를 작성함
- 실패 상황을 대비한 설계에 집중함
- 본인을 위한 코드가 아니라 후속 개발자를 위한 코드를 작성함
- 이후 그 매니저의 코드 리뷰는 거침없이 통과됨
- 매니저가 달라진 게 아니라, 나 자신이 성장했기 때문임
내 리더십 스타일에 남긴 영향
- 엔지니어링 매니저가 된 후 그 경험을 많이 떠올렸음
- 사람들이 싫어하는 리더는 되고 싶지 않았지만, 부드럽기만 한 리더도 되고 싶지 않았음
- 다음과 같은 방식으로 스타일을 정립함
- 배경 설명이 있는 직설적인 피드백을 줌
- 시스템적 사고를 강조함
- 높은 기준은 유지하되 인간적인 피드백을 제공함
- 엔지니어들은 도전받는 걸 원하지만 무시당하는 느낌은 싫어함
단호한 매니저가 필요할 때
- 리더십에는 자존심, 마감, 압박이 얽혀 있어 혼란스러움
- 단호한 매니저는 다음을 통해 이 혼란을 걷어냄
- 기능이 아닌 확장성을 생각하게 함
- 영리한 코드보다 유지 가능한 코드를 쓰게 함
- 실패와 예외 상황을 미리 대비하게 함
- 감정보다 코드의 생존 가능성을 더 중요하게 여김
단호한 매니저 아래에서 생존하고 성장하는 방법
- 숨 막히는 리더 아래에 있다면 다음과 같이 대처할 수 있음
- 개인적인 공격으로 받아들이지 말 것: 피드백은 코드에 대한 것
- 피드백 이후 “왜?”를 물어볼 것: 대부분 단호한 리더는 호기심을 존중함
- 실패 지점을 스스로 먼저 생각해 볼 것: 매니저처럼 사고하기 시작해야 함
- 리더라면 다음을 실천해야 함
- 높은 기준을 제시하되, 그 기준이 중요한 이유를 설명할 것
- 모호한 피드백 대신 구체적으로 말할 것
- 성공보다 성장을 축하할 것: 개발자가 매니저보다 먼저 문제를 포착했다면 칭찬할 것
거절된 Pull Request가 준 최고의 선물
- 처음엔 자존심이 상했지만, 지금 돌아보면 그 거절된 PR은 인생 최고의 기회였음
- 코딩을 개인 프로젝트가 아닌 시스템 구축으로 보게 되는 계기였음
- 단호한 매니저는 기분을 좋게 해주진 않지만, 개발자로서 성장하게 함
- 진정한 성장은 PR이 통과될 때가 아니라, 거절될 때 시작됨
개인적인 공격이 되지 않기 위해서는 라포 형성을 잘 해놔야 하는 거 같습니다. (특히 한국 사회의 맥락에서는요)
저는 개인적으로 주어 사용에 유의합니다. "이 코드가" 오버엔지니어링 인거지 "상대방이" 잘못된 것이 아니니까요.
전문가 머릿속에서는 대체 무슨 일이 벌어지고 있을까글이 생각나네요. “오버 엔지니어링임. 복잡함. 리팩토링하시오”, “이건 취약해. 부하 상황에선 어떻게 돼? 롤백 계획은?”라는 리뷰를 받았을 때 왜 그렇게 생각했는지, 어떤 문제를 예상하는지, 어떤 방향의 개선을 생각하는지 물어보는 것도 좋겠습니다. (글쓴이가 그렇게 안했다기 보단 저런 상황에서 어떻게 하면 더 많은 효용을 얻을 수 있었을까 생각이 들어서요)
듣기 좋은 말이, 좋은 말인 것은 아니죠. 저도 "Nasty Code" 라는 단어 두개로 들어있던 코드리뷰가 인생에서 가장 도움이 되었다고 생각합니다.
글의 함의는 좋은에 그 매니저가 뛰어났다기보다는 본인이 잘 한 것으로 느껴지네요. (저자가 어떤 피드백을 받아도 성장하는 유형의 사람 아닐까)
(맥락이 부족한) 부정적 피드백을 받았을 때 행동이 기대와 반대로 변화할 가능성이 높다는 연구를 본 기억이 있습니다.
작업물에 대한 피드백은 개인 비난이 아닌것을 깨닳아야합니다.
매니저가 더 좋은 사람이였다면 더 좋을 수도 있지만 회사는 학교가 아니기 때문에.. 우린 pro이기 때문에.. 피드백에 대해 알아서 학습해야합니다.
모르면 모른다고 말 할 수 있는 용기도 필요합니다.
저와는 꽤 다른 관점에 계신 듯합니다. 제 경력이 얕아서인지 명료하지 않은 피드백, 지칭어가 모호한 피드백은 도리어 역효과를 낳는 것만을 많이 봐서요...
맞춤법이 잘못 되었습니다.
"비난이 아닌것을 깨닳아야합니다." -> "비난이 아닌 것을 깨달아야 합니다"라고 쓰셔야 합니다.
개인적인 비난이 아닌 걸 아실테지만, 보자마자 제 지적에 화가 나셨을거라고 생각합니다. 누구는 조삼모사라고 하지만, 조삼모사와 조사모삼을 다르게 받아 드리는 게 사람인거 같긴 하더라고요.
ps. 저도 맞춤법 틀리신거 몰랐는데, 예시를 찾고 싶어서 맞춤법 검사기에 넣고 나서야 잘못 쓰신 걸 찾았습니다.
스트레스 받는일도 해결할 수 있는 것이 프로라고 생각합니다.
스트레스 받게 하는걸 정당화 하려는건 아닙니다. 프로로 일을 하다보면 화나는 일도 생길텐데, 그걸 슬기롭게 해결하는것이 프로라고 생각해요.
댓글에 정말 동의합니다. 받아들이는 사람의 실력과 마음가짐이 뛰어났던 것이라고 생각합니다. 저 매니저는 철학은 뚜렷했으나 자기 철학을 팀에 전파하기 위해 좋은 접근을 할 줄은 몰랐다고 생각합니다.
"시스템적 사고" 라는 것이 뭔가 고민을 해봤는데, 글의 맥락에서는 무언가
어플리케이션의 동작 관점에서의 사고라고 느껴지네요. 근데 정말 중요한 관점이라고 생각됩니다.