내가 미워했던 매니저와 그가 가르쳐준 교훈

1. 코드 리뷰에서 시작된 이야기

나는 소프트웨어 엔지니어로 일하던 시절이었다.
며칠 동안 복잡한 기능을 개발하며 수백 줄의 코드를 작성했고, 모든 예외 상황을 고려하며 성능 최적화까지 마쳤다. 스스로도 꽤 자랑스러웠다. 그래서 자신 있게 "Pull Request 생성" 버튼을 눌렀다.

그런데 돌아온 피드백은 예상과 완전히 달랐다.

"과도하게 설계됨. 너무 많은 움직이는 부품이 있음. 리팩토링 필요."

그게 전부였다.
"잘했어"도 없고, "좋은 시도였어" 같은 말도 없었다. 그냥 단호한 거절이었다.
나는 속으로 분노하며 생각했다. "이 사람, 사람들 기 죽이는 걸 즐기는 건가?"

하지만 이건 시작에 불과했다.

2. 그는 다른 리더들과 달랐다

그는 내가 이전에 만났던 리더들과는 완전히 달랐다.

중간 과정에서 손을 잡아주지 않았다.
불완전한 아이디어는 단호하게 거절했다.
복잡함을 위한 복잡함을 싫어했다.
그가 중요하게 여긴 건 단 하나였다: 깨끗하고, 유지보수 가능하며, 효율적인 코드.

스프린트 회고에서도 그는 돌려 말하지 않았다.
마감 기한을 놓쳤을 때는 이렇게 말했다.

"우리가 범위를 잘못 설정했어. 고치자."

확장성이 없는 무언가를 만들었을 때는 이렇게 말했다.

"이건 기술 부채야. 우리가 감당할 수 없어."

처음에는 그가 단순히 "악명 높은 매니저"라고 생각했다. 엔지니어들을 괴롭히는 그런 사람 말이다. 하지만 시간이 지나면서 그가 단순히 까다로운 사람이 아니라는 걸 깨달았다.

3. 결정적인 순간: 스프린트 리뷰

스프린트 리뷰에서 나는 자신만만하게 새로운 기능을 시연했다. 이번에는 그를 감동시킬 수 있을 거라 확신했다.
그런데 그는 시연 도중 나를 끊었다.

"이건 취약해. 부하가 걸리면 어떻게 될 건데? 롤백 계획은 뭐야?"

나는 당황해서 대답을 더듬었지만, 제대로 된 답을 내놓지 못했다.
그는 잠시 멈추더니 이렇게 말했다.

"너는 지금 코더처럼 생각하고 있어. 엔지니어처럼 생각해야 해. 실패를 견딜 수 있는 걸 만들어야지."

그 순간은 나에게 정말 뼈아팠다.
그날 밤 내내 그의 말을 곱씹었다. 처음에는 화가 났지만, 시간이 지날수록 그가 옳았다는 걸 깨달았다. 나는 너무 "똑똑한" 솔루션에만 집착했고, 탄탄하고 견고한 코드를 만드는 데 소홀했다.

4. 변화의 시작

그날 이후로 나는 내 작업 방식을 완전히 바꾸기 시작했다.

"똑똑한" 코드를 쓰는 대신, 읽기 쉬운 코드를 쓰기 시작했다.
실패 시나리오를 고려하며 설계했다.
나 자신을 위해 코딩하는 대신, 내 코드를 이어받을 다음 사람을 위해 코딩했다.

그리고 놀라운 일이 벌어졌다.
그가 내 Pull Request를 리뷰할 때, 피드백이 훨씬 줄어들었다.
그가 부드러워진 게 아니었다. 내가 드디어 수준을 끌어올린 것이었다.

5. 매니저가 된 후, 그 경험을 떠올리다

내가 엔지니어링 매니저가 되었을 때, 그 경험을 자주 떠올렸다.
나는 사람들이 미워하는 리더가 되고 싶지 않았다. 하지만 그렇다고 너무 부드러운 리더가 되고 싶지도 않았다.

그래서 그의 방식 중 효과적이었던 부분만 가져왔다.

단호한 정직함, 하지만 맥락을 제공하기.

"이건 별로야" 대신, "이건 숨겨진 기술 부채를 만들어. 이유는 이거야."
시스템 사고를 강조하기.
엔지니어들에게 단순히 티켓을 처리하는 데 그치지 말고, 자신의 코드가 전체 시스템에 어떻게 기여하는지 생각하게 했다.
높은 기준, 하지만 인간적인 피드백.
단순히 문제를 지적하는 데 그치지 않고, 해결 방안을 함께 제시했다.

6. 리더십의 본질

리더십은 복잡하다.
자존심, 자부심, 마감 기한, 압박감이 얽혀 있다.
하지만 좋은 매니저는 그 모든 혼란 속에서도 핵심을 짚어낸다.

그들은 당신에게 이렇게 가르친다:

확장성을 생각하라. 단순히 기능만 구현하지 말고.
유지보수 가능한 코드를 작성하라. 단순히 똑똑한 코드가 아니라.
예외 상황과 실패를 대비하라. 왜냐하면 실패는 반드시 일어나기 때문이다.

이런 매니저들은 당신의 기분보다는 코드가 실제 환경에서 살아남을 수 있는지를 더 중요하게 여긴다. 그리고 그건 나쁜 일이 아니다.

7. 현재의 당신에게 주는 조언

만약 지금 당신이 까다로운 매니저 밑에서 일하고 있다면, 이렇게 해보자:

개인적으로 받아들이지 말자. 피드백이 코드에 대한 것이지, 당신 자체에 대한 것이 아니다.
피드백 뒤에 숨은 이유를 물어보자. 대부분의 까다로운 매니저는 호기심을 존중한다.
그들이 지적하기 전에 실패 지점을 예상하라. 그들의 사고방식을 배우기 시작하자.

만약 당신이 매니저라면:

높은 기준을 세우되, 그 이유를 설명하라. 엔지니어들은 기준이 중요한 이유를 알면 더 잘 받아들인다.
구체적으로 피드백하라. 모호한 비판은 사람들을 좌절시킨다.
성공뿐만 아니라 성장도 축하하라. 누군가 당신보다 먼저 문제를 발견했을 때, 그걸 칭찬하라.

8. 마지막 교훈

돌아보면, 그 혹독했던 Pull Request는 내 커리어에서 가장 큰 전환점 중 하나였다.
그 경험 덕분에 나는 코딩을 단순히 개인적인 예술 프로젝트로 대하지 않고, 시스템 빌더로서 생각하기 시작했다.

까다로운 매니저는 당신을 기분 좋게 만들지는 않을 것이다. 하지만 그들은 당신을 더 나은 엔지니어로 만들어줄 것이다.
그리고 당신이 자존심을 내려놓고 그들의 가르침을 받아들인다면, 그 교훈은 당신의 커리어 내내 남을 것이다.

"때로는 거절당한 Pull Request가 가장 큰 성장을 가져다준다." 🌱