To OO님,

주니어, 시니어를 거쳐 언젠가는 조직의 리드 엔지니어가 될테니 리드 엔지니어의 역할과 중요하게 여겨야 할 것들에 대해 얘기해 줄게.

리드 엔지니어의 역할

리드 엔지니어의 역할은 크게 3가지로 요약할 수 있어.

기술 리드

  • 조직의 미션 기반으로 엔지니어링 팀의 기술 목표를 세우고 효율적인 목표 달성을 위해 로드맵을 수립합니다.

  • 조직의 기술 스택을 결정하고 적용하는 과정을 리드합니다.

  • 프로덕트 아키텍처를 만들고 발전시켜야 합니다.

기술 코치

  • 팀이 기술적으로 성장할 수 있는 환경을 만들고 적극적으로 코치해야 합니다.

  • 팀의 기술적 목표를 높게 유지할 수 있도록 해야 합니다.

  • 일하는 방식에 대해서도 팀원이 우선순위 기반으로 자신의 일정을 계획하며 관리할 수 있게 코치해야 합니다.

팀 매니징

  • 조직의 방향성과 비전을 엔지니어들에게 이해시키고 같은 방향을 바라보게 개선합니다.

  • 인재의 채용과 유지

    • 팀에 맞는 최적의 엔지니어를 찾기 위해 노력합니다.

    • 인재들을 주기적으로 면담하여 문제가 있는지 파악하고 해결합니다.

  • 팀원의 실수에 대해서 반복되지 않게 조직 또는 시스템 관점에서의 프로세스 개선을 주도합니다.

  • 비효율적인 업무 프로세스가 있다면 개선합니다.

역할과 더불어 리드 엔지니어가 중요하게 여겨야 할 것들에 대해 설명할게.

리드 엔지니어가 중요하게 여겨야 할 것

엔지니어 리소스

엔지니어 리소스는 엔지니어의 시간, 노력, 에너지를 의미해. 조직에서 특히 엔지니어의 리소스가 중요하고 귀한 이유는 실제 프로덕트가 엔지니어에 의해 구현되기 때문이고 그렇기 때문에 무엇보다도 프로덕트의 주요 비즈니스 로직을 구현하는데 엔지니어 리소스를 집중해야해. 그렇기 때문에 문제를 해결 과정에서 첫번째 단계는 프로덕트가 필요한가 부터 시작해야해. 정책이나 프로세스의 변경으로도 문제를 해결할 수 있는 경우가 있기 때문이야. 특히, 프로덕트 중심의 팀에서는 모든 문제를 프로덕트로 해결하려하는데 이런 접근을 조심해야 해. 첫번째 단계에서 프로덕트로 해결할 수 밖에 없다란 결론을 얻었다면 다음 두번째 단계는 솔루션이나 툴로 해결할 수는 없는가? 직접 구현해야만 하는가?의 고민을 해야해. 요즘은 좋은 솔루션과 툴이 많아서 직접 구현하는 것 보다 더 쉽고 빠르게 해결할 수 있는 경우가 많아. 예를 들어, 단어로 상품 검색시 결과의 정확도가 낮은 문제가 있고 이를 해결하기 위해 검색엔진이 필요한 상황이라면 Algolia라는 검색 솔루션을 쓸지 Elastic Search를 도입해서 직접 구현해야할지에 대해 선택할 수 있어. 다른 예로, 사용자가 특정 기능을 사용한 후 피드백을 받을 수 있는 설문 조사 기능이 필요하다고 한다면, Typeform 이라는 설문조사 툴을 쓸지 직접 구현할지 선택할 수 있어. 이 때 한 가지 더 고민해야 할 점은 직접 구현하게 되면 ‘검색 기술’ 또는 ‘설문 기능’을 보유하게 되는데 이것이 조직의 목표와 미션에 기여하는지도 고민해야 해. 예를 들어, 프로덕트가 크라우드펀딩 플랫폼이라면 사용자들이 자금의 모금을 빠르고 편하게 하기 위한 결제 기술을 보유하는 것이 목표에 기여할 수 있는 것이기 때문에 엔지니어 리소스는 검색 기술보다는 결제 기술에 집중해야 한다는 것이야. 이런 치열한 고민을 하고 나서야 이 해결 방법은 스토리가 될 수 있고 엔지니어가 스프린트에서 구현하게 되는거야. 또한 데이터 추출 등 반복되는 단순한 업무, 시간이 소요되는 업무는 자동화할 수 있도록 끊임없이 고민해야 엔지니어 리소스를 잘 활용할 수 있어.

엔지니어의 성장

성장을 위한 학습 지원이나 컨퍼런스 참가 지원도 좋지만 더 중요한 것은 프로덕트를 구현하는 과정, 팀에서 협업을 하는 과정에서 성장할 수 있도록 프로세스를 만들어 가야해. 예를 들면, 아래와 같은 프로세스

  • 구현(코딩)은 스토리를 분석하고 설계 문서를 작성한 후 팀원들과 리뷰를 한 이후에 가능하다.

  • 배포는 팀원들과 코드 리뷰를 한 이후에 가능하다.

이러한 협업을 통한 프로세스를 통해서 성장할 수 있는 환경을 만들어야 해. 특히 시니어 엔지니어는 mini CTO라 일컬을 만큼 중요한데 이런 프로세스를 통해 주니어들을 잘 이끌어서 성장할 수 있도록 리드해야 해. 특히, 문제를 빠르고 효율적으로 해결하기 위해선 풀스택 관점에서의 접근이 필요한 만큼 팀에서 풀스택을 지향하는 분위기를 만들고 서서히 풀스택을 경험할 수 있게 직군간 기술 세미나, 온보딩 체험 등을 도입하는 것도 좋아. 특히 사용자 경험 관점에서 기능의 동작을 처음부터 끝까지 코드 레벨로 이해하는 과정은 풀스택을 부담없이 시작해 볼 수 있는 . 이렇게 엔지니어들이 프로덕트 구성 전반 기술에 관심을 갖고 알아가게 만드는 것이 중요해. 그리고 피드백을 잘 활용해야 해. 주니어는 지금하고 있는 업무가 성장에 어떻게 기여하고 있는지에 대해 스스로 알기가 어렵거든. 가능한 짧은 주기(2, 3주 정도)로 1:1 시간을 정해서 피드백을 주는 것이 필요해. 업무 뿐만 아니라 회사 생활 전반에 걸쳐 어려운 점이나 도움이 필요한 점이 있는지 물어보고 체크해야해. 기억해야할 것은 개선 사항이나 요청한 점에 대해서는 결과에 상관없이 가능한 빨리 피드백을 주는 것이 중요해. 이게 잘 되지 않으면 팀원 입장에서는 피드백 시간이 무의미하고 시간 낭비라고 느낄 수 있어. 가능하다면 팀원과의 1:1 시에 주고 받은 피드백을 노션 등의 사내 문서에 비공개로 남기고 각자의 1:1에만 접근가능하도록 한다면 팀원들은 언제든 자신의 피드백을 참고하면서 성장에 활용할 수 있을거라 생각해. 이를 통해 팀원들은 리드가 자신들의 의견을 중요시한다는 것을 알게 되고 더 적극적으로 1:1을 활용하고 기대하게 될거야.

EX(Engineer eXperience, 엔지니어 경험)

프로덕트의 좋은 UX(사용자 경험)는 좋은 EX(엔지니어 경험)에서 시작된다고 생각해. EX는 기술 선택, 정책, 문화, 솔루션 또는 협업 툴 도입, 코드 완성도를 보장하는 활동(Design Doc, 코드 리뷰, 코드 품질/테스트 커버러지) 등을 포함하고 팀에 대한 만족도에 크게 기여하기 때문에 꾸준하게 개선할 필요가 있어. 특히, 완성도를 높히는 작업(코드 리팩토링, 성능 개선 등)과 구현시 퍼포먼스를 올리는 작업(레거시 코드 제거, 신규 플랫폼 도입)을 할 수 있는 고도화 시간을 확보해서 지속적인 신규 기능 구현으로 인해 쌓일 수 밖에 없는 기술부채에 대한 부담을 덜어줘야 해. 우리 팀의 경우는 엔지니어 리소스를 7:3으로 나눠서 7은 프로덕트 구현에 3은 고도화에 사용하고 있어.

반응력이 높은 팀 만들기

결국 엔지니어 리소스, 성장, EX를 중요하게 여기는 이유는 프로덕트 팀은 높은 반응력(Reflection)을 갖어야 하기 때문이야.

‘반응력이 높다’란 의미는 고객의 피드백이 적절한 주기로 꾸준하게 제품에 반영되고 있다란 뜻이야.

프로덕트 중심으로 일하는 팀의 목표인 주기적으로 프로덕트를 고객에게 전달하여 가설을 검증하여 임팩트를 주기위해 엔지니어들이 프로덕트에 기여하면서 성장할 수 있게 하는 것. 이것이 리드 엔지니어의 역할이야.

From. 앞으로 존경받는 리드 엔지니어가 되길 바라며 Rock