뛰어난 개발자에게서 공통적으로 보인 세 가지

넷플릭스, 우버, 유튜브를 거친 PM의 통찰

이 글은 Pragmatic Engineer 팟캐스트〈How to Work Better with Product, as an Engineer – with Ebi Atawodi〉편을 바탕으로 작성되었습니다.
기술보다 사람과 구조, 그리고 팀 안에서 우리가 함께 설계해야 할 '신뢰'에 대해, 다양한 사례를 통해 실무자의 시선으로 다시 들여다봅니다.

진짜 뛰어난 소프트웨어 엔지니어는 세 가지 특징이 있습니다.
첫째, 배움을 멈추지 않아요.
둘째, 손을 더럽히는 것을 두려워하지 않죠.
셋째, 강한 신념을 가지고 있지만 틀릴 수도 있다는 것을 압니다.

Pragmatic Engineer 팟캐스트에서 유튜브 제품 디렉터 Ebi Atawodi는 이렇게 말했습니다.

저는 이 말이 유독 마음에 남았습니다.
우리는 개발자로서 스킬셋을 쌓는 데 몰두하지만,

정작 중요한 것은 어떻게 일하고, 누구와 함께 일하느냐일지도 모릅니다.

계속 배우는 사람들

넷플릭스, 우버, 구글, 유튜브라는 각기 다른 기업에서 Ebi가 본 뛰어난 개발자들은 공통적으로 학생처럼 배우고 있었다고 합니다.

단순히 기술 트렌드를 쫓는 게 아니라,

직접 사이드 프로젝트를 하거나,

모델을 만져보거나,

심지어는 서비스의 사용자로서 다시 경험해보기도 합니다.

실제로 어떤 엔지니어링 디렉터는 리코딩 문제를 푸는 게 일상이라고도 했고,

어떤 VP는 모델 학습 과정을 직접 손으로 테스트해보며 신뢰를 쌓았다고 합니다.

이 말을 듣고 나서, 문득 나 자신에게 물었습니다.
요즘 나는 무엇을 배우고 있는가?
단지 '아는 것'을 유지하는 데 급급하지 않았는가?

이야기를 듣다 보면, ‘배우는 자세’라는 말이 얼마나 흔하게 소비되고 있는지 깨닫게 됩니다.

하지만 여기서 말하는 배움은 단순한 열정이 아니라, 업무의 일환으로 배움을 택하는 태도에 가깝습니다.
상황이 바뀌면 다시 익히고, 모르면 실험하며, 실패하면 기록하는 태도 말이죠.

손을 더럽히는 사람들

두 번째 특징은 '코드를 직접 짜는 것'입니다.
Ebi는 PM임에도 Figma로 직접 디자인을 해보고, PRD를 대신 써주고,

다른 팀이 바빠서 못하는 일을 몰래 부트스트랩해 실행한 경험을 여러 번 말했습니다.

결국, 뛰어난 엔지니어는 단지 '좋은 아이디어'를 말하는 사람이 아니라,
"직접 해봤는데 생각보다 쉬워요",
"여기까진 해봤고, 이 이상은 도와주세요"라고 말할 수 있는 사람입니다.

이게 단순히 생산성의 문제일까요?

저는 ‘관여도’의 문제라고 생각합니다.
서비스가 돌아가는 방식, 코드가 동작하는 흐름, 팀이 놓인 제약을 직접 겪어보지 않고는

진짜 의미 있는 의사결정을 내릴 수 없습니다.

신념을 갖되, 유연한 사람들

세 번째는 모순처럼 보이지만, 실제로 가장 어려운 능력입니다.
'나는 이렇게 생각한다'는 의견을 분명히 가지되,
틀렸을 때는 빠르게 물러날 수 있는 사람.

이들은 단호하게 말합니다.
“이건 이 방향으로 가야 해요.”
하지만 동시에 이렇게 말할 수 있습니다.
“아, 당신 말이 맞네요. 제가 틀렸어요.”

이 태도가 가능한 이유는 '에고를 내려놓기' 때문이죠.
이기는 것이 아니라 더 나은 결론을 향해 가는 데 초점이 맞춰져 있습니다.

실제로 Ebi는 자신이 유튜브에서 맡았던 한 프로젝트에서 VP와 의견이 달랐지만,
모든 단계마다 수치를 공유하며 의견을 맞춰갔고, 결국은 팀이 옳았다는 것을 보여줍니다.

‘지금 내 팀’은 어떤가?

이 이야기가 인상 깊었던 이유는, 단지 뛰어난 엔지니어의 조건을 나열했기 때문이 아닙니다.
이 팀은 그렇게 일했고, 그렇게 만들어졌다는 점입니다.

제품 리뷰가 팀에게 어떤 영향을 주는지 함께 공유하고,

팀원들의 생일, 고충, 변화들을 알고 있었으며,

개인적인 관계를 바탕으로 갈등을 기회로 바꾸는 문화를 만들었죠.

그리고 무엇보다, 수치와 지표를 팀의 언어로 바꾸는 데 집중했습니다.

이런 팀에서는, 누구 하나가 떠난다고 해서 시스템이 무너지지 않습니다.
스스로 책임지고, 함께 결정하고, 팀 전체가 ‘하나의 제품 팀’으로 일하는 구조가 있기 때문입니다.

그래서, 나는 무엇을 바꿔야 할까?

이 대화를 들으며 이런 질문이 생겼습니다.

지금 내 팀에서 나는 얼마나 배우고 있는가?

나는 ‘코드를 짜는 일’에 손을 충분히 더럽히고 있는가?

혹은, 다른 팀의 문제를 이해하기 위해 충분히 가까이 가봤는가?

나는 어떤 이슈에서 단호할 수 있고, 또 유연할 수 있는가?

그리고 무엇보다, 나는 내 팀의 사람들을 얼마나 알고 있는가?

생일을 알고 있는가? 고민을 나눈 적이 있는가?

우리가 팀에서 바꿔야 하는 건 결국 시스템이 아니라,
이 시스템을 어떻게 ‘사람’과 ‘관계’ 중심으로 운용할 것인가입니다.

우리는 모두, 역할이 아니라 관계로 일합니다.
그리고 그 관계를 움직이는 힘은, 결국 ‘관심’과 ‘신뢰’입니다.