개발
이제 막 핵심 인재로 올라선 엔지니어들에게 주는 조언
10분
3시간 전374
에디터가 직접 고른 실무 인사이트
매주 목요일에 만나요.
0명 뉴스레터 구독 중
0명 뉴스레터 구독 중본문은 유진 얀(Eugene Yan)의 글 <Advice for New Principal Tech ICs (i.e., Notes to Myself)>을 번역한 글입니다. 유진 얀은 아마존의 수석 응용 과학자(Principal Applied Scientist)로, 고객을 위한 대규모 추천 시스템과 AI 경험 관련 내용을 개발하고 있습니다. 필자에게 허락받고 번역과 게재를 진행했습니다.
[일러두기] 이 글은 아마존을 비롯한 글로벌 빅테크의 수석 엔지니어(Principal Engineer) 역할을 염두에 두고 쓰였습니다. 이들은 높은 수준의 능력을 갖춘 개발자로 팀장이 아닌 개인 기여자(IC)로 활동하며 폭넓고 다양한 역할을 수행합니다. 비록 직무 명은 다르지만, 조직의 핵심 인재로 활동하는 국내 개발자에 역시 유용한 조언이 많아 글을 옮겨왔습니다. 그에 따라 국내 상황에 맞춘 의역을 추가했습니다. 이를테면, 원문에는 수석 엔지니어를 비롯해 scientist나 principal tech IC 같은 표현이 등장하지만, 모두 ‘수석 엔지니어’로 통일했습니다.
수석 엔지니어는 어떻게 성과를 낼까요? 이글은 제가 롤 모델로 여긴 엔지니어들을 관찰하며 얻은 지식을 요약한 것으로 일부는 그들의 조언을 인용했습니다. 저의 직장인 아마존 중심으로 관점이 형성되었지만, 이 아이디어들은 수석 엔지니어 역할에 보편적으로 적용될 것입니다. 당연한 말이지만, 이 조언이 여러분과 상황에 맞는지는 스스로 평가하며 최선의 판단을 하세요.
어떤 사람은 특정 분야에 깊이 파고들고, 어떤 사람은 동료나 타 부서와의 협력에서 영향력을 발휘하는 데 탁월합니다. 어떤 이는 기술적 선구자라 방법을 보여주고, 다른 이는 복잡성을 명확히 하며 앞으로 나아갈 길을 밝힙니다. 또 다른 이는 여러 조직을 하나의 비전으로 정렬시키는 데 능숙합니다. 어느 스타일이 더 중요하다고 할 수 없습니다. 자신의 강점에 맞는 스타일을 찾아야 합니다.
아마존은 수석 엔지니어가 직접 코드를 작성하기를 원합니다. 장기간 동안 코딩 작업에 직접 참여하지 않는 사람은 실패를 자초할 가능성이 큽니다(짧은 기간은 괜찮습니다).
*기울임체로 표기한 영역은 본문의 인용으로, 저자가 밝힌 바와 같이 그가 롤 모델로 여긴 엔지니어들의 조언이나 강조할 표현으로 보면 좋습니다.
수석 엔지니어 역할을 수행할 때는 직접 코드를 작성하는 것만이 능사가 아닙니다. 물론 코딩 감각을 유지하기 위해 여전히 코드를 작성해야 하지만, 이제는 기술 비전, 설계 피드백, 후원, 비즈니스, 제품, 기술 컨텍스트 제공, 문제 발견, 연결 고리 만들기 같은 일이 핵심적인 역할입니다.
L7 이상 역할*에서는 흔히 듣는 말입니다. 코딩 시간을 줄이라는 뜻이 아니라, 80% 시간을 여전히 코딩에 할애한다고 해도 모두가 더 효과적으로 일하도록 하는 것이 가장 영향력을 끼칠 수 있는 방법입니다. 한 프로젝트만 보고 코딩만 파고들거나 혼자 완벽하게 다듬는 데 집중하던 사고방식이 바뀝니다. 이제 모든 개발자가 여러 프로젝트에서 더 잘 만들 수 있도록 영향을 주는 쪽으로요. 저장소에 고품질 코드로 기여해 읽기 좋은 코드로 소통을 원활하게 하거나, 설계 제안 피드백, 기술 가이드 작성, 장기 비전 추진과 같이 분명하게 더 효과적인 활동을 할 수도 있습니다.
*L7(Level 7) 이상 역할: 주로 대형 IT 기업이나 테크 기업에서 사용하는 직급 체계의 ‘L7 이상’에 해당하는 고위급 기술 개인 기여자(Technical IC) 또는 관리자급 역할을 의미합니다.
더 정확히 말하면, 제품, 디자인, 엔지니어링, 과학, 품질 보증, 채용, 금융, 문화와 같은 모든 분야를 고루 다뤄야 한다는 의미에서 파트타임 PM과 같습니다. 이들 가운데 당신 일이 아닌 것은 없습니다. 뛰어난 판단력으로 자신의 전문 범위를 넘어서 활동할 수 있습니다.
여러분이 맡을 프로젝트는 범위가 넓고, 이사급, 부사장급을 넘나드는 팀들이 관여합니다. 이런 종류의 프로젝트는 효과적인 업무 조정과 협력이 없으면 성공할 수 없습니다. 또한, 고객에게 조직 구조에 따른 업무의 차이를 그대로 보여주지 않도록 주의를 기울여야 합니다.
다른 사람을 설득하고, 그들이 움직일 만큼 관심을 갖게 해야 합니다. 추진력을 만드는 법, 아이디어를 후원할 사람, 마무리하는 방식을 찾아야 합니다.
때로는 프로젝트를 시작하고 가치를 보여주어야 이런 것들을 얻을 수 있습니다. 수석이 솔선하여 모범을 보이고, 사람들이 결정을 기다리는 대신 능동적으로 문제 해결에 나서길 지원합니다.
수석은 결정권을 쥔 자리라고 말할 수 있습니다. 누구를 기다리나요 :)
여러분이 상대할 사람들은 임원부터 현장의 실무 개발자까지 다양합니다. 가장 어려운 작업인 동시에 실패하기 쉽지만, 미래를 볼 수 있는 넓은 시각을 가진 사람으로서 해야 할 일입니다. 제 멘토는 “자신이 제안한 10개의 문서 중 3개 정도만 실행돼도 좋은 결과”라고 말했습니다.
일상적 업무가 많고 팀 단위로 일하며, 즉각적 과제에 더 집중하는 개인 개발자와 달리, L7 이상 역할은 한발 물러나 회사의 더 넓고 장기적인 관점을 볼 여유가 있습니다. 그래서 보다 객관적으로 영향력을 판단할 수 있는 수준에서 기여하는 것이 가장 큰 가치를 만듭니다. 수석 없이 그러한 일들이 일어날 수는 없습니다.
보통 당신이 정말 특별히 중요하게 취급해야 할 교차점이 있습니다. 빠른 프로토타입 제작 같은 일, 새로운 고객 경험을 전파하는데 리더십을 발휘하는 일, 그리고 조직과 조직 사이 또는 업계 실무자 사이에 다리를 놓는 일, 또는 3개년 비전 수립 등 일입니다. 이런 종류의 일에 집중하세요. 경력이 쌓이면 당신만이 할 수 있는 일이 점점 깊고 좁아질 것입니다.
여기에는 어떤 일을 새로 해보려는 팀을 그 일을 해본 팀과 연결시켜서 코드를 재사용하거나 경험을 나눌 수 있게 하는 것도 포함됩니다. 또한 그 일을 할 수 있거나 성장할 수 있는 적합한 사람을 찾는 것도 마찬가지입니다.
일부 업무 시간을 다른 사람들을 코칭하고 멘토링하여 효과를 내는 데 쓰는 것이 조직에 더 유익합니다. 매주 몇 시간씩 멘토링 시간을 갖거나 육성하려는 사람들과 정기적으로 소통할 시간을 마련하세요. 한두 명의 실무 개발자를 육성 대상으로 정하고 그들을 돕기 위한 목표를 세우세요.
핵심은 위임을 통해 조직을 성장시키는 것입니다. 조직 자체가 수석 엔지니어와 같은 결정을 내린다면 수석 엔지니어는 성공한 것이라 할 수 있습니다. 그렇게 되면 수석 엔지니어는 다른 모호한 문제에 나설 테고, 이것이 조직 문화로 자리한다면 올바른 결과에 이를 수 있습니다.
모든 사람을 돕고 싶겠지만, 장기적으로 당신 자리를 대신할 수 있는 사람을 키우는 데 에너지를 집중해야 합니다. 모두가 그런 능력이 있는 건 아니므로, 잠재력 있는 사람에게 시간을 집중적으로 투자하고, 그들이 다시 잠재력이 낮은 사람을 돕도록 하는 식입니다.
자신의 성장 경로에 큰 공헌을 한 일을 누군가에게 맡겨 성장 기회로 삼고, 그들이 성공할 수 있도록 지원하세요. 자신의 일이 사라질까 걱정하지 않아도 좋습니다. 고객을 위한 중요한 문제와 흥미로운 기회는 끊임없이 쌓여 있습니다.
사람들과 주 1~2시간을 함께 보내며, 선임 소프트웨어 개발자*가 당신의 통찰 아래 40시간의 가치를 낼 수 있게 하는 것이 수석 엔지니어의 진정한 확장 역량이라고 말합니다.
*원문에는 Sr. SDE로 표현된 직급입니다. 아마존, 마이크로소프트 같은 글로벌 기업에서 SDE(Level 4~6) 직급 체계 중 L6에 해당하는 주니어를 넘는 시니어급 개발자가 Sr SDE이며, 팀 내에서 기술 리더 역할을 수행하고 복잡한 문제를 다룹니다.
맥락을 짚어 주고 지침은 줄 수 있지만, 최종적인 향방은 수행할 사람 스스로 정해야 합니다. 당신이 선택하지 않을 방식을 그들이 택해도 이를 내버려두는 것 역시 포함됩니다. 결과가 좋지 않아도 그걸 통해 배우고 나아갈 수 있다면 그것으로부터 당신도 배웁니다. 물론 돌이킬 수 없는 잘못된 결정으로 높은 위험에 빠지게 될 때는 개입이 필요합니다.
때때로 모두가 가장 고참에게 의견을 묻는데, 당신은 고참이 아닌 사람들에게 질문을 던져 발언 기회를 줄 수 있습니다. 또한, 논의에 참여하지 않는 사람이 있으면, 그 사람의 강점에 맞는 주제로 부드럽게 끌어들이세요. 때로 논의에 꼭 있어야 할 사람이 빠졌다면 다음 회의에 반드시 초대하세요.
제가 만난 가장 효과적인 수석 중에는 회의 내내 조용히 있거나 문서 검토 과정에서 거의 코멘트를 남기지 않는 이들도 있습니다. 팀에서 논의가 잘 돌아가면, 한 걸음 물러서서 다른 곳에 집중해도 괜찮다는 의미입니다.
하지만, 자리에 참석한 다음 침묵하고 있으면 암묵적 승인으로 보일 수 있으니 주의하세요. 한 번에 여러 가지 일을 다룰 때면 주의하세요. 당신의 존재가 무엇을 의미하는지 잘 생각해야 합니다.
임원들이 주제에 관심을 보이고, 의미 있는 질문을 하며, 그들만이 할 수 있는 의사결정을 내리거나 장애물을 제거해 줄 수 있다면 그것만으로 좋은 회의입니다.
리뷰, 상향 보고, 이메일, 도움 요청 같은 일들이 업무로 들어옵니다. ‘1순위 연락처’가 되는 것이야 좋은 일이지만, 근무 기간이 길어질 정도면 상황이 심각해집니다. 결과적으로 모든 회의에 필수 참석자가 될 수 있으니 시간을 아끼고 거절하는 법을 배워야 진짜 중요한 아이디어에 집중할 시간이 생깁니다. 모든 회의에 출석하거나 모든 아이디어에 의견 낼 필요 없이, 중요한 것에만 집중하세요.
특히 제 멘토가 알려준 중요한 한 가지는 생각할 시간이 필요하다는 것입니다. 끊임없이 회의에서 회의로 옮겨 다니면 생각을 정리하거나 앞을 내다볼 수 없습니다. 회의에서 떨어져 충분히 생각할 시간을 마련해야 다음에 주목받을 주요 이슈를 찾을 수 있습니다.
이를 위해서는 위임하는 법을 배워야 합니다. 누군가를 지정해서 당신의 시간을 확보하고, 그 사람에게 성장을 위한 기회를 주는 게 좋습니다.
이것은 다른 중요한 역할에도 적용될 수 있습니다.
핵심 개발자라는 직함은 조직 내 특권을 부여해 더 많은 관계와 상황에 대한 접근을 가능하게 합니다. 이러한 지위가 경험과 합쳐지면 앞을 더 잘 내다볼 수 있게 합니다. 그렇게 적은 노력으로 프로젝트 성공과 결과를 현저히 개선할 수 있습니다. 높은 투자 대비 수익이 나는 일므로, 이런 기회를 발견하면 행동으로 옮기세요.
낯선 사람은 당신이 툭 던진 말도 과대 해석할 수 있습니다. 그래서 당신이 무심히 한 말 하나 때문에 누군가 많은 일을 해야할 수 있습니다. 그들이 시간과 노력을 낭비할 수 있으니, 알고 있는 것과 모르는 것, 요청하는 것과 단순 의견인 것을 명확히 하세요.
더 나은 결정에 도움이 됩니다. “모 수석이 이렇게 말했으니 따라야 한다”라며 다른 이들이 이유도 모르고, 그대로 따라 하는 걸 줄입니다.
L7 수준의 의견이 필요한 문제는 보통 상당히 불확실한 일에 대한 의사결정이 필요합니다. 이때 가장 중요하지만 어려운 것은 당신의 사고방식을 설명하는 것입니다. 어떻게 불완전한 정보만으로 새로운 판단에 도달했는지, 왜 특정 지식이 다른 데이터보다 중요한지 설명하는 일입니다.
디자인 리뷰, 주간 데모, 근처에 앉아 듣기, 함께 점심 먹기, 복도에서 하는 가벼운 대화 같은 것이 될 수 있습니다. 조직의 현황과 주요 문제/기회를 파악하는 데 도움이 됩니다.
실무진이 일상에 몰두하다 보면 장기적 문제와 기회를 놓치고 눈앞의 일에만 갇힐 수 있습니다. 당신이 보는 맥락을 팀원들에게 상기시켜야 합니다.
세부 사항은 실무진과 상의하고 의견을 경청하세요. 그들이 현장의 전문가입니다.
전체 행동을 충분히 보지 못한 상태에서 부실한 의견을 주기보다는 거절하는 것도 괜찮습니다.
초기 점검, 데모데이 참석처럼 인턴 기간 개발자와의 몇 차례 만남은 무언가 큰 변화를 만들지도 모릅니다. 또 단순 인턴십을 넘어 누군가 프로젝트를 이어갈 수 있는 산출물을 만들도록 멘토, 인턴과 협력하세요. 산출물은 작동하는 소프트웨어는 물론 제품 요약 보고서나 기술 문서가 될 수 있습니다.
이전에 ‘1순위 연락처’였다면 이제는 주변에서 지원하는 역할로 전환해야 합니다. 조직은 점점 당신에게서 이익을 얻게 되지만, 당신 없이도 작동하는 상태가 되어야 합니다. 당신이 했던 기여를 다른 사람이 할 수 있도록 힘을 실어주는 방법을 고민하세요.
프로젝트의 핵심 영역에 개입하는 것에 유의하세요. 다른 우선순위에 집중이 빼앗길 수 있습니다. 핵심 역할을 맡고 있다면 엄격히 관리해야 합니다.
보통 1년 이상 그에 준하는 일을 해 온 것입니다. 직함에 따른 기대를 걱정하지 마세요. 지금 하던 대로 계속 유지하고, 다른 직급들과 소통하며, 자신만의 스타일을 찾고, 직속 상사와 함께 집중할 분야를 정하세요.
무엇을 할지 자율권이 생기지만 책임과 영향력을 기대받습니다. 자유란 원하는 것을 하는 것이 아니라, 가장 영향력 큰 문제를 찾아 해결하는 주인의식을 말합니다. 지시받거나 안내받길 기대하지 마세요. 조직이 집중할 일을 스스로 찾아야 합니다.
한 가지 방법은 일을 ①컨설턴트 ②후원자 ③책임자 관점으로 나누는 것입니다.
컨설턴트는 리뷰에 참여하고 가이드를 제공하며, 시스템이나 제품의 의도를 고수준에서 이해합니다. 후원자는 여기에 더해 아이디어를 조직의 우선순위로 만들고 정렬하며 의사결정을 주도할뿐더러 이해관계자와 소통합니다. 마지막으로 책임자는 위 모두에 더해 시스템 전문가이자 연락처 1순위이며, 설계, 실행, 성공에 집착 수준의 관심을 둡니다. 저는 1~2개 프로젝트를 주로 책임지고(50% 이상), 2~3개를 후원하며(약 20%), 나머지 시간에는 컨설팅합니다.
모든 팀의 일원이면서도 어느 팀에도 완전히 속하지 않은 상태입니다. 자유롭게 대화할 수 있는 동료 네트워크를 만드세요. 같은 회사나 분야인지 여부는 크게 중요하지 않습니다.
학습, 성장, 웰빙을 지원하는 프로젝트에 시간과 공간을 마련하세요. 그때 잠시는 이기적으로 느껴질 수 있으나, 번아웃 되는 것보단 훨씬 낫습니다. 건강하고 행복하게 성장할 수 있는 일을 찾으면 조직도 혜택을 볼 만큼 영향력을 유지하기도 쉽습니다. 관리자와 이 균형을 맞추는 법을 상의하세요.
아무것도 배우지 못하거나 일과 관련 없는 일만 한다면 퇴보하는 것입니다. 때로는 그런 일을 맡는 것이 불가피하지만, 그런 프로젝트는 기간을 제한하세요. 또 배움이 반드시 직장 내에서만 올 필요는 없습니다. 저는 주말에 논문이나 기술 서적 읽고 프로토타입을 만들며 신기술과 아이디어를 이해하는 수석 엔지니어들을 잘 압니다.
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.