전문가들로 가득한 방에서 리드하는 방법

• 여러 분야의 전문가들이 모인 환경에서 리더는 기술적 세부 지식보다 문제를 연결하고 해결 방향을 잡는 역할을 담당함
• 리더십은 단순한 기술 지식보다 번역 능력과 사회적 기술이 중요하며, 갈등 상황을 조율하고 공통 목표를 강조해야 함
• 중요한 것은 각자의 깊은 전문성보다 실제 문제 정의와 해결 방향을 명확히 하고, 논의가 사용자의 요구와 결과로 이어지게 만드는 것임
• 효과적인 리더는 모든 것을 아는 척하지 않고 “모른다”라고 말할 용기를 가지며, 전문가들이 주도적으로 기여할 수 있는 장을 마련함
• 리더의 진정한 가치는 관점 번역, 문제 맥락 제공, 협업 공간 조성에 있으며, 이는 최고의 성과를 이끌어내는 핵심 요소임

---

최근 깨달은 점

• 한 회의실에서 다양한 분야의 전문가 개발자와 제품팀과 함께함
• 나는 특정 기술에 최고의 전문성은 없지만 리드 개발자 역할을 맡는 중임
• 전문가들 사이에서 리더로서 내 역할은 모든 해답을 아는 것이 아니라, 답을 찾아내어 연결하는 능력임

Technical Leadership

• 리더는 기술적 지식의 깊이보다, 팀 간의 의사소통을 활성화하는 효과적인 번역가 역할을 수행함
• 백엔드 개발팀의 일정 설명이나, 제품팀의 요구사항을 각각의 관점에서 통역하여 팀의 협업을 이끌어냄

Leading is a Social Skill

• 기술적 신뢰성만으로는 충분하지 않고, 사회적 기술이 진정한 생산성을 만들어냄
• 개발자들 사이의 논의를 읽고 언제 논쟁을 중재하거나 진행시킬지 판단하는 능력이 필요함
• 효과적인 커뮤니케이션은 문서만이 아니라 적극적인 대화를 통해 이루어짐

Leading is Remembering the Goal

• 전문가일수록 세부 기술에 몰입하는 경향이 있으나, 리더는 전체적인 목표에 집중해야 함
• 기술적 논의가 아닌, 사용자 경험의 본질적 문제와 비즈니스 목적을 명확히 정의하는 역할이 중요함
• 문제의 본질을 명확하게 규정하지 않으면, 팀원들은 각자의 분석 방식에 따라 진짜 이슈를 놓칠 수 있음
• 리더는 팀이 문제를 제대로 이해하고 같은 목표를 보도록 번역하는 책임이 있음

Leading is Saying "I Don't Know"

• 모든 해답을 아는 척하기보다 "모르겠다, 함께 알아보자"는 자세가 신뢰와 열린 문화를 만듦
• 이 태도는 전문가들에게 의문과 논의를 허용하며, 각자 역량을 발휘할 기회를 제공함
• 리더는 주제별 전문가에게 결정권과 발언권을 주고, 논의의 생산적 방향성을 제시함
• 두 명의 전문가가 구현 방식에 이견을 보일 때, 리더의 역할은 "정답"을 고르는 것이 아니라, 트레이드오프와 사용자 영향 관점에서 프레임을 제공하는 것임

The Translation Challenge

• 리더는 개발자 언어, 제품 언어, 경영진 언어를 각 상황에 맞추어 번역할 수 있어야 함
  • 개발자: "인증 서비스에 적절한 서킷 브레이커가 없으면 부하 상태에서 연쇄 장애가 발생할 수 있음"
  • 제품팀: "로그인 시스템 문제 시 전체 앱에 영향을 줄 수 있어 보호 장치 도입이 필요하며, 일정이 일주일 늘어남"
  • 경영진: "이번 스프린트에서는 시스템 안정성을 우선하여 비즈니스 리스크를 줄임"
• 전문가에게 타 부서의 언어까지 학습하게 할 필요는 없으며, 리더가 그 간극을 메우는 다리 역할을 해야함

Beyond "Because, that's why!"

• "내가 리드니까 이렇게 해"라는 결정 방식은 신뢰와 협업 문화를 해치고 팀 생산성을 떨어뜨림
• 성인으로서 팀을 대우하고, 결정의 이유와 맥락을 분명히 설명하는 것이 중요함
  • "보수적 접근을 택하는 이유는 잘못됐을 때의 비용이 높기 때문, 이후 반복적으로 개선할 수 있음"
  • "추가 작업처럼 느껴질 수 있지만, 아키텍처 목표에 부합해서 다음 기능 개발에 도움이 됨"
  • "이 방식이 가장 우아한 해법은 아니지만 정해진 일정 내에 자신 있게 배포할 수 있음"
• 전문성을 내려놓을수록 진정한 리더십 발휘가 가능함

리더가 팀에 제공해야 하는 가치

• 명확한 문제 정의 제공
• 결정 맥락에 대한 충분한 설명
• 팀 간 관점 차이 번역
• 불필요한 복잡성으로부터 보호
• 최고의 결과를 위한 환경 조성

결론

• 전문가 조직의 기술 리더십은 명령과 통제를 넘어 연결과 맥락 제공에 초점이 있음
• 리더는 직접 악기를 연주하는 연주자가 아니라, 오케스트라가 한 곡을 완성하도록 돕는 지휘자와 같음
• 이는 그저 방에서 가장 똑똑한 사람이 되는 것보다 훨씬 더 흥미로운 도전임

[GN⁺]

Hacker News 의견

• 나는 팀의 리더로서, "나는 리드이고, 이렇게 하기로 결정함"이라는 식의 결정을 최대한 피하는 편이지만, 필요하다면 주저하지 않고 사용해야 함을 강조함. 모두의 의견을 듣고 신중히 결정하는 데 시간을 들이지만, 팀이 본질적이지 않은 세부사항으로 끝없는 논쟁에 빠질 때는 리더로서 질서를 세워야 함을 깨달았음. 스티브 잡스가 “모두를 행복하게 하고 싶으면 리더 말고 아이스크림이나 팔라"고 했다는 말을 곱씹음. 이런 상황이 지나간 후에는 반드시 신뢰를 다시 구축하고 왜 그렇게 행동할 수밖에 없었는지 팀원들에게 설명해주는 것이 중요함

  • 나 역시 이 교훈을 고생하며 배웠음. 처음 매니저가 되었을 때는 항상 모두의 합의를 이끌어내고 자연스럽게 팀이 하나로 모일 거라 순진하게 생각함. 훌륭한 팀에서는 처음엔 통했지만, 이후 다른 팀의 25년 전 방식만 고집하는 엔지니어들과 함께하게 되자 합의점을 기다리며 너무 많은 시간을 낭비함. 결국, 팀원들이 입장을 충분히 밝힌 뒤에는 리더가 방향을 정하고 결단해야 할 순간이 온다는 사실을 깨달았음

  • 내 경험에서, 몇 년간 F50에서 일하며 비슷한 상황을 겪음. 3명의 핵심 인력이 있는 도메인에서 A안이 겉보기엔 좋아 보여도 실제로는 문제가 많음을 우리만 알았고, 설명해도 팀을 설득하지 못해서 결국 투표를 무시하고 상사와 이야기한 끝에 제대로 결정할 수 있었음. 이 과정에서, 실제로 결과를 직접 다루게 되는 사람이 원하는 방향(C안)이 아닌, 다수의 의견(A안)에 따라가면 프로젝트에 계속 문제와 지연이 발생한다는 점을 깊이 깨달았음. 중요한 점은, 책임과 결과를 직접 감수하는 사람들은 인기투표가 아닌 '거부권'을 가져야 프로젝트에 추진력이 생긴다는 것이며, 대형 프로젝트에서는 여러 리드가 도메인마다 의사결정을 하고, 교착상태일 때만 상사가 명확히 결정을 내려야 한다는 것임. 리더가 결단을 회피하면 모두가 불만만 토로하게 되어 팀 사기도 심각하게 저하된 짜증나는 경험을 함

  • Steve Jobs가 팀을 한 방에 가둬놓고 공통의 비전을 찾을 때까지 토의시킨 에피소드도 떠오름. 모두를 한 방향으로 이끄는 일이 어렵지만, 실패하면 실행력이 크게 떨어짐. 또한, 팀원의 의견을 무시하면 무시당하는 느낌을 받게 되니, 결과가 중요해도 오래 지속할 수 있는 방식은 아님

  • “모두의 목소리를 듣는다"와 “모두에게 거부권을 준다"는 전혀 다르다는 점이 인상적임. 리더로서 교착상황을 끊어내는 것은 필수적인 역할이라고 생각함. 물론 모든 이슈에서 리더가 결정해야 한다면, 관리 문제나 동기부여, 혹은 팀에서 전략을 이해하지 못하고 있다는 신호임

  • 내가 선호하는 방식은 “네가 직접 담당이라면 결정이 뭔지 나에게 알려달라"고 말하는 것임. 리더의 임무는 항상 결정을 직접 내리는 것이 아니라, 반드시 결정을 나오게 하는 것임

• 나는 이 분야에서 약간의 전문성이 있다고 생각함. 과거에 이전에 세 번이나 실패했던 프로젝트의 리더로 임명되어, 각 팀에서 최고의 엔지니어 6명과 함께 일함. 모두 의견이 뚜렷하고 이유도 확고했으나, “실수하는 적을 방해하지 마라"라는 말처럼, “친구가 훌륭한 것을 하고 있을 때는 방해하지 마라”라는 태도를 가지려고 함. “네가 맡지 않은 부분이라면 네가 잘할 수 있는 무언가 다른 것을 만들어라”는 자세였음. 자연스럽게 역할을 분배하고, 서로 부드럽게 영향력을 주고받으며, 덜 중요한 부분은 완벽하지 않아도 받아들이는 등 유연하게 접근함. 결과적으로 성공적이었고, 여러 재능 있는 사람이 모인 팀에서 서로 배우고, 진짜 토론이 필요한 부분에만 집중하는 구조가 만들어진 것이 매우 자랑스러움

  • 당신 경험이 Servant Leadership(관련 위키 링크)이라고 부르는 리더십과 비슷하다고 생각함. 내가 좋아하는 리더십 방식이기도 함

  • 뛰어난 엔지니어들에게 지나친 개입 없이 그들이 주도적으로 자신의 아이디어를 펼치게 하는 데에는 리더로서 진정한 신뢰와 자제력, 그리고 자신감이 필요하다고 생각함

• 제품팀이 “간단한” 기능을 요청할 때마다, 내 머릿속에는 최소 3개 팀이 필요하고 각각의 마이크로서비스를 업데이트해야 한다는 점이 떠오름. 그런 점에서 가끔은 현대 웹 시스템이 정말 싫어짐

  • 여기서 문제는 현대 웹 그 자체라기보단, “간단한” 기능 하나가 마이크로서비스 3곳에 나뉘어 의존성이 분산된 아키텍처 때문이라고 생각함. 결국 시스템 설계 실패가 더 큰 원인임

  • 그렇다면 다른 대안은 무엇일지 궁금함

• 내 경험상, “내가 리드다"라는 발언은 자신감 부족처럼 보일 수 있기 때문에 피함이 좋고, 오히려 모든 정보를 수집하고 결정을 내렸을 때 “자, 이제 우리가 이렇게 하자” 또는 “이렇게 해줬으면 한다”고 자신 있게 말할 수 있어야 함

• 문제의 핵심은 오해가 아닌, 서로에 대한 신뢰 부족임. 한 팀이 어떤 일에 2주 걸린다고 하면, 다른 팀은 하루면 될 일이라 생각하며 신뢰하지 않음. 서로 충분히 신뢰한다면, 상대팀이 더 전문적이라는 점을 받아들일 수 있는데, 현실에선 일정 산정이 진짜 필요한 작업량이 아니라 여유를 확보하려는 셈법일 수도 있다고 의심하게 됨. 이럴 때 충분한 설명과 근거를 공유하면 신뢰를 높이는 데 도움이 됨

• 최근 리드 개발자로 승진한 지 1년쯤 됨. 내 역할과 책임이 뭔지 혼란스러웠지만, 원글에 나온 내용들과 비슷한 생각을 가지고 일해온 것 같아 안도감을 느낌. 며칠 전 “비개발자 관점에서 튜토리얼을 읽는 법"이라는 글을 접하며 공감하였는데, 내가 옳은 방향으로 가고 있는 듯함

• 나도 소프트웨어 인접 제품 개발팀에서 리드가 강압적으로 리딩했던 사례를 3번 경험했는데, 매번 좋지 않은 결과였음. 몇 번 팀 리드를 직접 해보니, 나는 ‘지휘관’이 아니라 ‘허브와 중재자’ 역할이어야 한다는 점을 깨달았음. 팀원 간 충돌이 있을 때 갈등을 풀어주고, 질문이 있으면 불안을 덜어주며, 아이디어가 나오면 실현 가능성과 가치를 평가하고, 리소스가 필요하다면 필요한 사람이 누구든 찾아가도록 돕는 일을 함. 문제가 생기면 책임을 지고, 문제 해결에 팀원을 독려함. 이 모든 것을 배우는 데 10년이 넘게 걸렸음. 나는 최고도 아니고, 내 이름도 대부분의 사람에게는 알려지지 않았지만, 팀의 ‘일원’으로서 일할 때 결과도 더 좋고 인재 이탈도 줄었음. 그리고 리더로서 “나도 잘 모르겠지만 우리가 같이 답을 찾아보자”라고 말하는 게 정말 중요하다고 느낌. 전문가에게 불확실함을 허락해주고, 방어적으로 되지 않게 하며, 혼자가 아니라는 느낌까지 주기 때문임. 예전 리더들에게서 소외감이나 교체 가능한 부품처럼 느껴본 적 있는 사람들은 위로받길 바라며, 리더가 팀원을 오래 잘 이끌고 싶다면 기계처럼 생각 말고, 꼭 서로를 돌보는 자세가 필요함을 느꼈음

  • 당신 말이 정말 핵심을 찔렀다고 생각함. 소프트웨어가 아니더라도 모든 전문 환경에서의 기술 리더십은 “명령-통제”가 아닌 “연결-맥락 제공"이 중요함. 지휘자가 모든 악기를 연주하는 게 아니라, 오케스트라 전체가 어떤 곡을 함께 연주하는지 이해하게 돕는 것과 같음. 회사를 음악 조직에 비유하는 사업가도 많은데, 내 경험도 같음. 조직은 완벽할 수 없고, 리더가 부족한 부분을 메워주려는 노력이 필수임. 리더의 능력에 의심이 생길 때 성과를 인정받고, 리더가 실제로 자신의 영역에서 어느 정도 탁월함을 보여줘야 결국 존경을 얻고, 팀이 리더의 실수도 용인하게 되는 순환이 생긴다는 사실을 음악 조직 경험과 연결해서 이야기함. 실력을 갖춘 리더가 자신의 영역을 조금이라도 실무로 보여줬을 때, 그것만으로도 신뢰가 크게 높아지는 경험이 있었음. 그래서 실력 없는 리더는 금방 들키고, 존경받는 리더는 동료들의 기대에 부응할 책임이 있음. 결국, 하드락 밴드든 클래식 오케스트라든, 리더가 같은 집단의 ‘고양이’여야 고양이들을 이끌 수 있다는 비유까지 덧붙이고 싶음

• 저자가 직접 본문 오디오를 녹음했다는 것에 감탄함

  • 멋진데, 이런 식으로 진짜 사람이 읽은 오디오라는 점을 사이트에서 적극적으로 강조하면 좋겠음. 대부분의 “Listen to this article” 기능은 AI가 읽어서 자연스럽지 않기에 평소엔 관심도 주지 않았음

• “It's because that's why”라는 문구를 좋아한다고 밝히며, 이 분야에 관심 있다면 Vanessa Van Edwards의 책들이 상황에 맞는 온기와 전문성 신호를 주는 방법을 배울 수 있어 많이 도움 받았다고 소개함. 한 명이 모든 답을 주긴 어렵지만, 여러 긍정적인 경험이 있었음

  • “사소한 논쟁거리(bikeshed)"라 말하는 편이 더 효율적이라고 생각함. 언제나 정답이 있는 것은 아니지만 결론은 필요하다는 점을 강조함

• 결정을 내리는 데에 대해 “결정이 반드시 내려지게 하는 것” 이상도, 이하도 있음을 느낌. 첫째, 가능하면 다른 사람이 직접 결정을 내리도록 하길 추천함. Apple 시절 Jean-Louis Gassee가 분쟁을 가져온 매니저들에게 둘 다 싫어할 만한 결정을 내려주곤 했고, 그러면 둘이 알아서 합의할 수 있는 대안을 찾아오곤 했다는 일화를 들려줌. 둘째, 모든 구성원이 진정으로 결정에 동의하게 만들 필요가 있으며, 본인부터 먼저 그렇게 해야 함. 이것이 바람을 따라 움직이는 매니저에겐 엄청 어렵다고 덧붙임. 법대생은 늘 조심스럽고 분석적으로 생각하지만, 변호사는 단호하게 주장해야 하며, 모두를 설득하는 태도를 갖추어야만 한다는 점을 비유로 듦. 항상 이상적으로 합의가 이루어지지 않으니, 고객이나 결과 목표 같은 구체적인 지점을 설정하면 결정을 추진하고 이행을 끌어낼 수 있다는 팁도 공유함