커리어 초반 몇 년 동안 나는 테크 회사에서 훌륭한 일을 어떻게 하는지 전혀 알지 못했다. 함께 일한 시니어와 스태프 엔지니어들은 마치 마법사 같았다. 내가 이해할 수조차 없는 문제들을 아무런 어려움 없이 해결해 냈다. 내가 데이터베이스에 무언가를 저장하는 방법을 배우고 있을 때, 그들은 회사 전체가 의존하는 스케일링과 설계 작업에 골몰하고 있었다. 나는 그 엔지니어들을 감동시키는 그런 일을 하고 싶었다.
지금 나는 스태프 엔지니어다. 신입 엔지니어들이 이해하기 힘들어 하는 문제들을 나는 자연스럽게 해결한다. 나는 중요한 스케일링과 설계 작업에 관여한다. 회사 전체를 지키는 수준은 아니지만, 매년 수백만 달러의 매출이 걸려 있는 일이다. 내 커리어 위치에 만족한다. 하지만 승진할수록 인상을 줘야 할 대상이 바뀌는데, 이 변화는 쉽지 않은 전환점일 수 있다.
커리어가 성장한다는 것은 존경하지 않는 사람들에게 인상을 남겨야 한다는 뜻이기도 하다
소프트웨어 엔지니어가 되기 전, 나는 시를 썼다. 어린 시절에는 키플링(Kipling)과 콜리지(Coleridge)의 시에 큰 감명을 받아 시를 쓰기 시작했고, 성인이 된 후에는 밀턴(Milton)과 오든(Auden)의 시에 깊이 매료되어 그들이 감동할 만한 시를 쓰고자 했다. 하지만 시를 출판하려면, 밀턴이나 오든처럼 쓰면 안 된다. 잡지와 문예지에 실리는 그런 스타일로 써야 한다는 뜻이다. 즉, 이미 세상을 떠난 유명 시인들의 영혼을 감동시키려 노력하는 대신, 시 잡지를 편집하는 사람들을 감동시키는 쪽으로 방향을 바꿔야 한다는 말이다.
나는 그렇게 몇 편의 시를 출판할 수 있었다. 하지만 그다지 잘하지 못했고, 그 경험은 나에게 씁쓸한 기억으로 남았다. 시 잡지 편집자들을 나쁘게 생각하는 것은 아니지만, 적어도 밀턴을 존경하는 만큼 그들을 존경하지는 않는다. 존경하지 않는 사람들에게 인상적이라고 생각되려 노력하면서 창작 활동을 하는 것은 영혼을 갉아먹는 일이다.
Product Manager에게 인정받으려다 생기는 위험
많은 소프트웨어 엔지니어들이 주니어에서 시니어로 성장할 때 이런 전환을 겪게 된다. 주니어에서 미드레벨 엔지니어로 승진하려면, 팀 내 시니어 엔지니어들에게 인정받으면 충분하다. 왜냐하면 매니저는 주로 시니어 엔지니어들의 평가를 참고해 주니어의 성장 여부를 파악하기 때문이다. 하지만 시니어, 스태프(Staff), 혹은 그 이상으로 승진하려면 완전히 다른 부류의 사람들에게 인정받아야 한다. 이제는 매니저, Product Manager, 디렉터, VP, 그리고 심지어 C레벨 임원들까지 감동시켜야 한다.
주니어 시절, 시니어 동료에게 인정받기 위해 동기부여를 받던 사람이라면, 이제는 매니저나 Product Manager(프로덕트 매니저) 등 임원진을 감동시키기 위해 일하는 방식 자체를 바꿔야 할 수도 있다. 이들은 조직 내에서 영향력은 크지만, 시니어 엔지니어들처럼 눈에 띄게 어려운 기술적 문제를 해결하지는 않는다.
엔지니어와 매니저/프로덕트 매니저(Product Manager)가 감동받는 일의 유형도 다르다. 나는 누군가가 아주 까다로운 버그나, 잡기 힘든 특이한 운영 이슈를 파고들어 끝내 해결하는 모습을 보고 가장 감탄한다. 하지만 내 경험상 매니저나 Product Manager는 속도에 더 감동한다. 예를 들어, 문제를 굉장히 빠르게 고치거나, UI를 예정보다 앞당겨 배포하는 것에 감명을 받는다. 물론 빠른 속도나 디버깅 모두 기술적 역량이 필요하다. 하지만 오직 첫 번째(깊은 기술적 분석)에만 집중해왔다면, Product Manager가 당신의 기술적 문제 해결에 마냥 감탄해주길 기대한다면 실망만 할 수도 있다.
그렇지만 매니저(Manager)나 프로덕트 매니저(Product Manager)는 사실상 감동시키기 더 쉽기도 하다. 내 말은, 이들은 일을 잘 끝내는 엔지니어에게 대체로 긍정적인 피드백을 많이 준다는 것이다. 오히려 시니어 엔지니어라면, “여기는 좀 더 이렇게 할 수도 있었을 텐데”처럼 구체적이고 기술적인 보완점을 섞어서 평가해주지만, 매니저나 프로덕트 매니저는 결과 중심의 칭찬을 더 많이 돌려준다. 그래서 “뛰어난 엔지니어 동료를 감동시키는 것”에서 “친근한 프로덕트 매니저를 감동시키는 것”으로 전환하는 과정이 상대적으로 부드럽게 느껴진다. 프로덕트 매니저가 중요하게 여기는 일에 집중해 성과를 내면, 즉각적이고 긍정적인 피드백과 장기적인 커리어 성장까지 함께 얻을 수 있으니까.
하지만 이런 긍정 피드백은 일종의 ‘공허한 칼로리(empty calories)’에 가깝다. 칭찬을 받고 커리어가 성장하는 것 자체는 기분이 좋지만, 정작 역량 있는 동료로부터 “이건 정말 잘했다”는 인정을 받고 싶은 갈증은 해소되지 않는다. 아무리 기술에 해박한 프로덕트 매니저라도, 그들은 엔지니어가 아니기 때문에 개발 관점에서 무엇이 인상적인지 혹은 그냥 평범한 것인지 제대로 판단할 수 없다. 사실, 이런 기술적인 평가는 당신에게서 기대하는 부분이기도 하다! 제품 관점에서 엄청난 가치를 지닌 일이 실제 구현은 너무 쉬울 수도 있고, 반대로 구현은 정말 어렵지만 제품 가치로 이어지지 않을 수도 있다. 결국 그들이 주는 피드백은 ‘제품에 얼마나 기여했느냐’에만 반응한다.
엔지니어 동료의 감탄은 더 오래 남는다. 내 경험상, 매니저나 프로덕트 매니저는 정말 친절하고 프로페셔널하지만 함께 일하는 동안에만 관심을 보일 뿐, 당신이 더 이상 도움이 되지 않는 순간 그 관심을 바로 거둬가는 경우가 아주 많다(2). 꾸준히 평판을 쌓아가고 있다고 믿었던 미드레벨 엔지니어에게는 꽤 실망스러운 현실일 수도 있다. 하지만 어쩔 수 없다. 맡은 역할이 서로 다를 뿐이고, 매니저나 프로덕트 매니저는 당신이 어떤 기술적 문제를 어떻게 해결했는지 깊이 이해하지 못하기 때문에 사실상 그 일 자체에 개인적인 관심을 가질 수 없는 것이다(3).
다른 사람에게 인정을 받고 싶지 않다면?
엔지니어들이 이 문제를 풀기 위해 선택하는 방식은 크게 세 가지로 나뉜다.
첫째, 매니저나 Product Manager에게 인정받는 데 전적으로 몰두하면서, 정서적으로 가장 만족스러운 방식—즉, 기술적 동료로부터 진짜 실력을 인정받는 방식—의 검증은 포기하는 것이다. 나는 이 방법을 추천하지 않는다. 빠르게 번아웃으로 치닫게 될 위험이 크기 때문이다.
둘째, 아예 커리어 성장의 경주에서 빠져나오는 것이다. “비엔지니어의 인정을 받아야 승진할 수 있다면, 나는 지금 위치에 남겠다”라고 스스로 결정하는 것이다. 이런 “기술에만 집중하는(Graybeard)” 엔지니어들은 모든 회사에 있다. 프로젝트의 유행이나 승진에 연연하지 않고 자신만의 기술적 판단에 따라 일한다. 나는 이런 엔지니어들을 존중하지만, 결과에 따르는 책임 역시 기꺼이 받아들일 각오가 전제되어야 한다.
셋째, 남을 감동(impress)시키는 데서 얻는 만족 대신, 다른 종류의 보람을 스스로 찾는 것이다. 낙관적으로는 사용자에게 구체적인 가치를 주는 성과(프로덕트 출시 등)에서, 냉소적으로는 부(wealth), 조직 내 권력(power), 영향력(impact)을 쌓는 데서 만족을 추구하는 사람이 많다. 사실 부, 권력, 임팩트는 그 자체로도 충분히 만족감을 준다! 대체로, 나 역시 이런 길을 택해왔고 지금까지는 아주 괜찮았다(4).
결론
모든 엔지니어가 동료를 감동시키는 데에서 동기부여를 받는 건 아니다. 사람마다 복잡하게 얽힌 다양한 동기가 있기 마련이고, 위에서 말한 내용이 전혀 공감이 안 된다면 그 역시 전혀 이상한 일이 아니다. 하지만 나는 분명히 그런 타입이었다. 나는 승진이라는 게 결국 새로운 사람들을 감동시켜야 하는 과정이며, 그 과정이 어떠한 경험인지를 이야기하고 싶었다.
지금 내 방식에 꽤 만족하고 있다. 이 블로그에도 관련 고민을 정말 충분히 써왔으니까. 그렇다고 해도, 가끔은 예전처럼 그저 온 힘을 다해 더 뛰어난 선배 엔지니어들이 ‘오, 쟤 잘하네’라고 생각할 만한 성과를 내려고 열심히 달렸던 시절이 그리울 때가 있다.
- 이런 얘기를 하면 거만하게 들릴 수도 있는데, 제 경험상 같은 시스템이나 기술을 충분히 오래 다루면 자연스럽게 저절로 익숙해진다. 다시 말해, 뛰어난 재능이라기보다는 ‘익숙함’의 문제인 경우가 대부분이다.
- 물론 몇몇 예외적인 경우도 있긴 하다.
- 가장 문제가 되는 경우는 ‘predator 프로덕트 매니저’ 유형이다. 이들은 순진한 엔지니어에게 아낌없이 칭찬을 퍼부으며 일을 더 열심히 하게 만들지만, 뒤에서는 그 엔지니어의 평판을 올려주지 않거나 심지어 깎아내리는 경우도 있다.
- 직접 겪어본 적은 없지만, 아마도 존재할 것으로 생각되는 네 번째 방법이 있다. 바로 직장 밖에서 전문적인 네트워크를 꾸려 가는 것이다. 과거 함께 일한 다른 엔지니어들과 승패를 공유하는 긴밀한 모임을 유지하면, 이런 갈증과 욕구를 어느 정도 해소할 수 있을 것이다. 다만 현실적으로 지금 당장 같이 일하지 않는 사람들과는 소식을 계속 주고받기 어려운 점이 큰 어려움이다.
원문: Trying to impress people you may not respect
blog by ash에서 더 알아보기
구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.
