소개
2024년 3월에 소프트웨어 엔지니어로 일한지 4년째가 지났어요. 그 때는 구글에서 일하고 있었고 많은 코드를 작성했지만 제 커리어에서 막힌 느낌을 받았어요.
그래서 저는 어떻게 하면 시니어 엔지니어가 될 수 있는지 매니저에게 물어보았는데, 매니저는 '나루토'를 본 적이 있는지 물어보더라구요.
"너가 처음에 아이가 정말 외롭다고 나오는 그 쇼 알지?"
모든 다른 소프트웨어 엔지니어처럼 들립니다만, 이것이 승진과 연관이 있는지 듣고 싶어졌어요.
나루토는 시작할 때 서로 잘 지내지도 않는 사람들과 함께 팀에서 여정을 시작합니다. 하지만 그는 그들에게 가까워지고 결국 함께 일하는 법을 배웁니다.
그러다 그는 같은 마을 팀들과 만납니다. 그들은 경쟁자가 아니지만, 함께 일하는 법을 배우는 데 시간이 좀 걸립니다.
쇼의 끝에서 나루토는 세상에서 가장 외로운 아이에서 "온 마을"의 지지를 받는 사람으로 변모합니다.
그래서 고급 엔지니어들과 무슨 관련이 있는 건가요?
그는 말합니다.
자신만으로는 아니라 모두와 협력하여 성장할 수 있어요.
반성
나에게 주어진 가장 중요한 조언 중 하나였어요.
그리고 조금 놀라운 건데, 소프트웨어 개발자로서 더 나아지기를 생각할 때, 사람들은 버그를 눈으로 바라만 봐도 고칠 수 있는 신이 나 프로그래머를 상상하곤 해요.
학교에서 수년 동안 코딩을 배워온 것에 대해 말하기는 이상한 일일수도 있지만, 더 많이 코딩하는 것이 당신의 커리어에 도움이 되지는 않을 거에요.
코딩 홍보의 오류
"더 많은 코드는 더 많은 승진을 의미하지 않습니다"
코딩은 당신의 일이며 누군가가 하는 것에 감탄하지 않습니다.
코드를 변경하는 것은 진전을 느끼게 해주고, 더 많이 해서 승진할 수 있을 것이라고 생각했습니다. 그러나 코드를 아는 것만으로는 특별한 사람이 되지 못합니다. 주변 사람들도 다 코드를 알기 때문이죠.
한 번 저에게 어느 시니어 엔지니어가 말한 글귀를 나누고 싶어요:
따라서 더 많은 책임을 질 수 있는 일을 해야 합니다. 그 전에 사람들과 신뢰를 쌓아야 하는데, 그것은 코딩을 통해 신뢰를 쌓는 것이 쉽지 않을 거예요.
시청자 수 제한
코딩의 문제는 코드를 검토하는 1~2명의 사람에게만 가시성이 제한된다는 점입니다. 더 나빠진 점은 동일한 두 명에게 계속해서 코드를 검토해 달라고 요청한다는 것입니다.
이렇게 되면 네트워크가 확장되지 않습니다. 이미 당신이 무엇을 할 수 있는지 알고 있는 사람들을 감탄시키는 것뿐이며, 당신의 작업을 검토하는 사람 이외에는 아무도 당신의 작업을 알지 못합니다.
또 다른 점은 사람들이 코드 변경 사항을 공유하지 않는다는 것입니다. 가끔씩 일어나긴 하지만, 모든 코드 변경 사항 중에 다른 사람과 연결되는 경우는 거의 없을 것입니다.
이제 실제로 주니어 개발 이상으로 커리어를 발전시키는 방법이 있어요.
도움 요청하기.
"하지만 나는 무서워."
도움을 요청하는 것은 어렵습니다. 도움을 요청해야 한다는 건 독립적일 방법을 모른다는 느낌이 듭니다. 그룹 채팅에서 코드 오류에 대해 질문했던 기억이 있습니다. 그 때 시니어 엔지니어가 나에게 구글 링크를 DM으로 보내주었죠.
물론 그때는 부끄럽고 창피했습니다.
하지만 동시에, 나루토처럼 외로운 상태로 머물러있다면 많은 어려움에 부딪힐 수 있습니다.
도움을 요청하는 올바른 방법.
도움을 요청해야 할 때는 조금이라도 직접 해결해보는 것이 올바른 방법입니다.
문서를 직접 확인하면 재미있는 도전이 될 수 있고 그 과정에서 무언가 배울 수도 있습니다.
하지만 2시간 동안 고민해도 해결되지 않는다면 시간을 절약하고 누군가에게 도움을 요청해야 합니다.
다른 사람이 15분 안에 해결책을 설명해 줄 수 있다면 문제에 하루를 허비할 시간은 없습니다. 이것이 당신의 경력에 해를 끼칠 뿐만 아니라 진행 중인 프로젝트를 늦출 수 있습니다.
만약 두려운 감정을 느낀다면, 다른 사람들이 도움을 주도록 하는 비밀을 공유해 드릴게요. 그것은 다른 사람들에게 가능한 쉽게 도와줄 수 있도록 만드는 것이에요.
이를 위해
- 문제가 무엇인지 설명하고
- 그 문제를 해결하려는 이유와
- 문제를 해결하기 위해 시도해 본 것을 설명하는 걸로 시작해보세요.
예를 들어, 버그를 해결하여 API 호출 속도를 빠르게 하고 싶다면, 참고한 스택 오버플로 및 깃헙 이슈 링크를 언급할 수 있어요.
도움을 요청하는 것은 여러분을 더 나은 소프트웨어 엔지니어로 만들어 줄 것입니다. 하지만 현재 역할에서 진정으로 효율적이지 않다면 승진할 수 없을 거예요.
능숙해지세요.
"당연한 것처럼 보입니다"
능숙도가 중요한 이유
다음 단계로 가는 가장 빠른 방법은 현재 수준에서 신속하게 능숙해지는 것입니다. (놀랍지 않죠!)
왜냐하면 현재 역할에서 매우 능숙해지면, 다음 역할을 위해 승진시켜 줄 일을 할 시간이 생깁니다.
사람들을 놀라게 하는 것은 무언가 미친 듯이 1000시간 일하는 것과 같은 행동으로 평균을 넘어설 수는 없다는 것입니다.
해볼 수 있어요! 대부분의 사람들이 이렇게 하면 평균 이상이 됩니다:
- 평균이 되세요. 다른 사람들이 하는 대로 하세요.
- 그 이상을 조금만 하세요.
바로 '평균 이상'이란 건 이런 의미예요. 평균 이상으로 노력하는 거죠.
이러한 마인드셋 변화를 갖게 되면, 일에서 훨씬 더 잘 할 수 있을 거예요.
일할 때는 도구에 익숙해지고 디버깅 전략을 개선하며 사용하는 프로그래밍 언어에 익숙해지는 것을 의미합니다
결국 코딩에 능숙해질수록 당신을 제약하게 될 것입니다.
코딩을 멈추고 더 많이 글을 쓰세요.
"누구도 나에게 어떻게 글을 써야 하는지 가르쳐주지 않았다"
어떤 엔지니어도 코딩 이외의 다른 일을 하면서 경력을 키워나가는 것입니다.
가장 중요한 것은 무엇이든 적어두는 것입니다.
사람들은 코드 변경이 아닌 문서를 공유합니다. 작은 코드 조각보다 문서를 통해 더 중요한 사람들과의 미팅과 토론이 항상 더 많을 것입니다.
여러분이 작성한 문서는 몇 달 후에도 여전히 순환됩니다. 여러분의 업무 영향에 대해 상사에게 이야기할 때 사용하거나 신입사원들은 문서를 역사적 맥락을 이해하기 위해 읽을 수 있습니다.
문서를 작성하는 것은 여러분이 엔지니어로서 얼마나 많은 것을 알고 있는지 보여주어 가시성을 얻는 데 도움이 됩니다.
무서워 보일 수 있지만, 코드 변경 또는 시스템 설계 문서를 제안하는 방법은 직무 교육 시 배우는 것이기 때문입니다.
시스템 설계 문서 작성
줄거리: 가장 중요한 내용을 먼저 전달해주세요.
다음 순서로 문서의 첫 단락에 모든 내용을 작성해주세요:
- 문제에 대한 간단한 설명 써주세요.
- 영향이나 중요성을 써주세요.
- 결과를 써주세요.
이 순서로 써주세요. 대부분의 사람들이 문서 전체를 처음부터 끝까지 읽지 않을 거예요. 보통은 처음 부분을 조금 읽은 다음 넘어가게 될 거에요.
언젠가는 많은 문서를 작성하게 되어 사람들이 해당 분야의 전문가로 알아보게 될 거에요.
하지만 그와 동시에 모든 것을 문서화할 필요는 없어요. 엔지니어로서 받아들이기 어려운 점 중 하나는 모든 문제를 해결할 필요가 없다는 것이에요.
그리고 일을 선택하는 데 알았더라면 좋았을 것들에 대해 이야기해볼게요.
협업하여 일하기.
"일부 작업은 다른 것보다 더 중요합니다."
모든 작업이 동등하게 중요한 것은 아닙니다. 모든 문제를 해결해야 하는 것도 아닙니다.
만약 당신이 일상 생활 영상을 본 적이 있다면, 구글과 같은 기업들이 많은 과자를 갖고 있다는 것을 알 것입니다. 그러나 사람들이 많이 언급하지 않는 것은, 일부 사람들이 너무 많은 과자를 훔쳐가거나 다회보관한다는 것입니다.
모든 사람이 이 일이 일어난다는 것을 알고 있고, 모든 것을 자동판매기에 넣으면 문제가 해결될 수 있다고 생각하지만, 그것은 그다지 중요한 문제가 아닙니다.
내년에 승진할지 3년 후에 승진할지를 결정하는 것은 가져야 할 일을 알고 있는 것입니다.
일을 빠르게 처리하려면, 레버리지된 일을 선택하세요.
이 모든 것은 노력 대비 영향력과 가시성이 더 큰 일을 선택하는 것을 의미합니다.
노력
이 노력은 이 문제를 해결하는 데 많은 시간과 조정이 필요한지를 물어보는 것입니다.
몇 일이나 몇 주 안에 해결할 수 있나요? 혼자 하실 건가요 아니면 여러 사람과 함께 할 건가요?
가시성
가시성은 회사 내 다른 사람들에게 영향을 미치는지 여부와 관련이 있어요. 만약 다른 사람들도 이 문제를 인지한다면 그것은 가시성이 있습니다.
영향
영향은 단순히 숫자를 사용하여 고객 또는 회사 외부 사람들에게 어떤 영향을 미치는지를 측정하는 것을 의미해요.
노력이 적고, 영향력이 크며, 가시성이 높은 작업을 선택하세요.
사내 정치
레버리지된 일에 대해 흥미로운 점은 다른 사람들이 그것이 문제임을 알기 때문에 눈에 띈다는 것입니다. 그 말은 다른 누군가가 일을 맡아서 대신 인정을 받을 수도 있다는 뜻이에요.
저는 정말 사내 정치를 싫어하지만, 일을 요구하기 위해 사람들이 한 전략을 보았어요. 그들은 처음 페이지를 쓰는 것이었어요. 그들은 문제에 대한 1페이지 제안서를 30분 동안 쓰고 다른 사람들에게 자신이 그 일을 하고 있음을 알리곤 했어요.
일부 기술 회사들에서 이런 것을 다루는 것은 귀찮을 수 있어요.
하지만 정말 눈에 띄고 싶다면 모두가 당신의 작품에 대해 알도록 해야 해요.
모두에게 알려주세요.
"자랑이 아니에요"
이 얘기는 커피 한 잔 마시면서 만난 테크 리드에게 영감을 받았어요. 나는 그에게 승진하는 방법을 물었고, 그는 5단계 프로세스를 설명해 주었어요.
단계 1. 먼저 시스템을 철저히 이해하세요.
단계 2. 모두에게 당신이 시스템을 철저히 이해한다는 것을 알리세요.
단계 3. 시스템에 대한 훌륭한 기여를 만들어 보세요.
-
시스템에 멋진 기여를 한 것을 모두에게 알리세요.
-
수익 창출. $$$
많은 시간을 들여 무언가를 작업했다면, 많은 사람들이 알 수 있도록 인정받는 것이 가치가 있습니다.
자랑스러운 느낌일 수 있지만, 사실 그렇지 않습니다.
당신이 그 분야의 전문가라는 것을 모두에게 알리는 중요한 역할을 하는 것이에요. 문제가 발생하면 당신에게 연락해야 할 것을 알게 될 거에요.
당신이 해결하면, 모두가 인상받고 당신의 작업을 인정할 거에요.
당신이 하는 일을 사람들에게 알리는 작은 방법들은 다음과 같아요:
- 매일 15분 동안 스탠드 업 중에.
- 모두가 볼 수 있는 그룹 채팅에서.
- 뉴스를 공유하기 위해 이메일 스레드를 작성하는 것.
- 새로운 지식에 대한 기술 강연을 시작하는 것.
당신이 하는 일에 대해 인정받아야 해요. 누구도 당신을 대변해 주지 않을 거에요.
하지만 그게 다른 사람을 대변하지 못한다는 걸 의미하지는 않아요.
누군가를 도와주세요.
“나는 아무것도 기여할 수 없는 주니어 엔지니어를 만난 적이 없어요"
과거에는 자신이 다른 사람을 도와주지 않을 것이라고 생각했었어요. 왜냐하면 아무도 나를 도와주지 않았거나, 제가 내 일에 집중하고 누군가를 돕을 시간이 없다고 생각했거든요.
하지만 나루토가 얼마나 많은 지지를 받았는지 기억하면, 다른 사람을 도와주는 것이 여러분의 목표를 이루는 데 도움이 될지도 모릅니다.
어떤 이유든간에, 아담 그란트의 책인 'Give and Take'를 통해 다른 사람을 돕는 두 가지 사상을 구분할 수 있었어요.
친절한 이유
누군가를 도와주는 것은 착한 성품을 가진 사람이라는 뜻이에요. 누군가를 도와주는 것은 일대일로 이어지는 것이 아니에요.
새로운 도구를 배우면, 다른 사람들에게 그 도구를 가르쳐줄 수 있어요. 팀 전체를 위한 문서를 작성하면, 팀 전체가 더 잘 할 수 있도록 돕는 거예요.
만약 모두가 이렇게 한다면, 스트레스를 받는 엔지니어들이 훨씬 줄어들 것이에요.
거래적 이유
동전의 또 다른 면은 거래적 이유로 사람들을 돕는 데 도움을 줍니다. 이들은 다른 사람을 돕는 것을 투자로 여기며 시간이 지남에 따라 승진과 같은 일에 나중에 그들을 도와줄 것입니다.
다른 사람 돕기 자체가 좋습니다.
당신이 무슨 이유로 하든, 누군가를 돕는 것은 모든 사람에게 좋은 결과입니다. 도움을 요청하는 것이 이미 무서운 일이라는 걸 알지만, 사람들에게 그것을 쉽게 만드는 것은 실제로 꽤 단순합니다.
이 동료들과 시간을 보내세요. 사무실에 가서 점심을 함께 하세요. 그들을 알아가세요.
그들이 무엇을 하고 있는지 알아보고, 그들이 모르는 것을 알고 있다면 생각해 보세요.
내 경험을 공유하고 싶은 이유가 여기에 있습니다.
떠나기 전에
- 박수 카운터가 50까지 올라간다는 거 알고 계셨나요?
- 유튜브 영상과 동일한 조언입니다.