다른 사람들은 묻지 않는 엔지니어링 리더가 묻는 질문

Source: Dev.to

번역을 진행하려면 번역하고자 하는 전체 텍스트를 제공해 주시겠어요? 텍스트를 주시면 요청하신 대로 한국어로 번역해 드리겠습니다.

소개

저는 선임 직함을 가지고 있었지만 팀을 이끌지는 않은 엔지니어들과 일한 적이 있습니다. 또한, 반 팀을 멘토링하던 주니어 엔지니어와도 함께 일해 본 적이 있죠. 차이는 이들의 이력서나 기술 깊이에 있던 것이 아니라, 일에 접근하는 방식, 성장에 대한 태도, 그리고 타인에 대한 책임감에 있었습니다.

소프트웨어 개발에서의 리더십과 멘토링은 조직도에 의해 부여되는 것이 아닙니다. 그것은 시간이 지나면서 누적되는 행동 양식에서 자연스럽게 나타납니다. 이러한 특성을 드러내는 질문들을 아래에 제시합니다.

Experience vs. Growth

10년의 경험과 1년의 경험을 10번 반복한 것 사이에는 차이가 있습니다. 경험을 반복한다는 것은 매년 같은 일을 하면서 근속 연수를 측정하는 것이지, 성장을 측정하는 것이 아닙니다. 특정 domain을 마스터한 뒤 그곳에 머무르는 것이죠. 이전에 해결했던 문제들이라서 작업이 편안하게 느껴집니다.

경험을 축적한다는 것은 새로운 역량을 구축하고, 더 넓은 책임을 맡으며, 자신과 팀을 위한 feedback loops를 구축하는 것을 의미합니다. 특정 domain을 마스터한 뒤 인접한 도전 과제로 확장합니다. 불편함은 학습의 신호입니다.

리더는 두 의미 모두에서 builder입니다. 그들은 다른 사람들을 위한 기회를 창출하면서 동시에 자신의 기술을 향상시킵니다. 기술적인 작업에 깊이 몰두하더라도, 지식을 공유하고, 의사결정을 투명하게 하며, 전문성을 전이시킴으로써 팀의 성장을 가능하게 합니다.

책임감과 품질

모두는 “깨지지 않으니 작동한다”는 생각으로 시작합니다. 많은 개발자들은 생산 사고가 없다는 것만으로 성공을 측정하며 그 상태에 머무릅니다. 하지만 리더들은 이 기준을 넘어섭니다.

전환은 배포 후 코드 품질에 대한 책임을 지기 시작할 때 일어납니다. 코드가 배포되고, 테스트가 통과했으며, 불평하는 사람도 없습니다. 대부분의 개발자는 여기서 멈춥니다. 리더는 모든 것이 괜찮아 보여도 “이게 좋은가?”라고 계속 묻습니다.

이는 완벽주의나 과잉 설계가 아닙니다. 품질은 불만이 없는 것이 아니라 기준이 존재하는 것입니다. 운영 안정성은 필요하지만 충분하지 않습니다. 리더는 유지보수성, 명확성, 성능 특성을 평가합니다. 그들은 코드가 시작할 때의 이해가 아니라 현재 팀의 이해를 반영하고 있는지를 묻습니다.

Source: …

올바른 질문을 던지는 법

개발자가 자신이 이미 알고 있는 것에만 의존해 작업을 평가하던 단계에서 벗어나면 성숙도가 바뀝니다. 경력 초기에 여러분은 지식 격차를 메우기 위해 질문합니다: “이 기능을 어떻게 구현하나요?” 혹은 “여기서 맞는 패턴은 무엇인가요?” 이런 질문도 중요하지만, 이미 이해하고 있는 범위 안에 한정됩니다.

리더는 다른 직감을 갖게 됩니다. 아직 생각조차 하지 못한 중요한 질문들이 존재한다는 가정을 합니다. 자신의 가정을 뒤흔들 수 있는 관점을 찾아 나섭니다. 가장 위험한 격차는 알려진 미지(known unknown)가 아니라 알려지지 않은 미지(unknown unknown)라는 점을 인식합니다.

이러한 태도는 리뷰, 설계 토론, 회고에서 드러납니다. 자신의 선택을 변호하기보다 놓쳤을 수도 있는 부분을 탐색합니다.

• “내가 놓치고 있는 것이 무엇인가?” 혹은 “문제가 보이시나요?” 라고 질문합니까?
  한 질문은 발견을 유도하고, 다른 질문은 검증을 유도합니다.

아무도 여러분의 코드를 지적하지 않았다고 해서 그것이 품질 좋은 작업이라는 뜻은 아닙니다. 배포되었다고 해서 그것이 옳다는 뜻도 아닙니다.

리더는 외부 검증과 무관하게 기준을 유지합니다. 스스로 작업을 비판하고 개선 기회를 찾으며, 단순히 완료되는 것보다 품질을 보상하는 시스템을 구축합니다. 승인 절차는 실수를 잡아내기 위한 것이지 품질을 정의하기 위한 것이 아닙니다. 여러분의 코드가 좋은 이유가 리뷰어가 거절하지 않았기 때문이라면, 책임을 외부에 위임하고 있는 것입니다.

멘토십과 복리 성장

가장 효과적인 기술 리더들은 근본적인 사실을 이해합니다: 우리는 가르침을 통해 배웁니다. 경험이 적은 개발자를 멘토링할 때, 단순히 시간을 관대하게 내는 것이 아니라 자신의 성장 조건을 만들고 있는 것입니다.

이것이 복리 성장으로 이어집니다. 주니어 개발자들이 오늘 당신이 하는 일을 처리하게 되면, 리더들이 직면한 도전을 다룰 여유가 생깁니다. 그들이 성장하면 당신도 성장합니다. 시간을 절약하기 위해 위임하는 것이 아니라, 조직의 역량을 구축하면서 동시에 자신의 역량을 향상시키는 것입니다.

훌륭한 엔지니어는 어려운 문제를 해결하고, 훌륭한 리더는 어려운 문제를 해결할 수 있는 엔지니어를 만들어냅니다. 전자는 당신의 개인적인 역량에 따라 선형적으로 확장되고, 후자는 팀의 역량에 따라 확장됩니다. 멘토십은 여유가 있을 때 하는 부수적인 활동이 아니라, 코드 작성과 시스템 구축, 혼자 일하는 것과 영향력 증폭 사이를 결정짓는 핵심 책임입니다.

결론

소프트웨어 개발에서의 리더십은 직함이나 조직도에 의해 부여되는 것이 아닙니다. 그것은 여러분이 업무에 접근하는 방식과 타인과의 관계에서 나타납니다. 팀을 고양시키는 엔지니어들은 공통된 패턴을 가지고 있습니다:

• 그들은 경험을 반복하기보다 축적합니다.
• 그들은 외부 검증에 의존하지 않고 품질 기준을 유지합니다.
• 그들은 자신의 이해에 대한 공백을 적극적으로 찾습니다.
• 그들은 시스템을 구축하면서 사람도 성장시킵니다.

이러한 특성은 시간이 지남에 따라 누적됩니다. 주니어 개발자를 멘토링하는 엔지니어는 자신의 성장 공간을 만듭니다. 자신의 가정을 질문하는 엔지니어는 문제를 더 일찍 포착합니다. 배포 후 품질에 대한 책임을 지는 엔지니어는 보다 견고한 시스템을 구축합니다.

결과는 단순히 더 나은 코드가 아니라, 더 강한 팀과 건강한 조직입니다. 이것을 위해 허가가 필요하지 않습니다. 멘토링을 하거나, 더 좋은 질문을 하거나, 더 높은 기준을 스스로에게 적용하기 위해 승진이 필요하지 않습니다. 리더십은 매일 업무에 어떻게 나타나는가에서 시작됩니다.