<div id="readability-page-1" class="page"><div><div><h2 id="26bc" data-testid="storyTitle">(번역) 전문가들로 가득한 방에서 리드하는 법</h2><div tabindex="-1" role="tooltip"><a rel="noopener follow" href="/?source=post_page---byline--340fed4a0979---------------------------------------" data-discover="true"><div><p><img alt="한정(Han Jung)" src="https://miro.medium.com/v2/resize:fill:64:64/1*tQfG8hfW5vM4hbRVZucMrg.png" width="32" height="32" loading="lazy" data-testid="authorPhoto"></p></div></a></div></div><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure><blockquote><p id="9cc3"><em>원문: </em><a href="https://idiallo.com/blog/how-to-lead-in-a-room-full-of-experts" rel="noopener ugc nofollow" target="_blank"><em>https://idiallo.com/blog/how-to-lead-in-a-room-full-of-experts</em></a></p></blockquote><p id="9320">최근에 깨달은 점이 있습니다. 저는 똑똑한 사람들로 가득 찬 방에 앉아 있습니다. 한쪽에는 우리 마이크로서비스 아키텍처의 세세한 부분까지 이해하는 개발자들이 있습니다. 다른 한쪽에는 잠결에도 리액트를 디버깅할 수 있는 프런트엔드 개발자들이 있습니다. 제 앞에는 우리 웹사이트에 존재하는 모든 가능한 사용자 경로를 외운 프로덕트 팀이 있습니다. 그리고 저, 리드 개발자가 있습니다. 저는 어떤 단일 기술에 대해서도 가장 깊은 전문성을 가지고 있지 않습니다.</p><p id="42b0">그렇다면 전문가들에 둘러싸여 있을 때 제 역할은 정확히 무엇일까요? 글쎄요, 간단합니다. 저는 모든 답을 가지고 있습니다.</p><h2 id="f265">기술적 리더십</h2><p id="82d5">좋습니다. 엄밀히 말하면 저는 모든 답을 가지고 있는건 아닙니다. 하지만 저는 답을 어디서 찾고 파편을 어떻게 하나로 만드는지 정확히 알고 있습니다.</p><p id="47f1">백엔드 팀이 새로운 인증 서비스를 구축하는 데 왜 3주가 걸리는지 설명할 때, 저는 OAuth 플로우나 JWT 토큰 검증에 대해 생각하지 않습니다. 대신 “이번 주 중에” 완료되기를 기대하는 프로덕트 팀에게 이 내용을 어떻게 전달할 수 있을지 생각합니다. 프로덕트 팀이 “간단한” 기능을 요청할 때, 저는 필요한 마이크로서비스를 업데이트하기 위해 관여해야 하는 3개 팀에 대해 생각합니다.</p><p id="8a91">기술 환경에서의 리더십은 방에서 가장 똑똑한 사람이 되는 것이 아닙니다. 가장 효과적인 통역사가 되는 것입니다.</p><h3 id="c3f4">리딩은 사회 기술(Social Skill)입니다</h3><p id="6b8a">개발자들에게 이렇게 말하면 종종 못마땅해합니다. 사실만으로는 누구도 설득할 수 없습니다. 전문가들로 가득 찬 방에서 당신의 기술적 신뢰성은 회의에 참여할 자격을 줍니다. 하지만 실제로 생산적인 결과를 만들어내는 것은 당신의 사회 기술입니다.</p><p id="577d">모두가 읽고 이해할 수 있는 문서를 제공하는것이 이상적이지만, 현실에서는 사람들이 이해하도록 만들기 위해 대화를 해야 합니다. 사람들은 자신이 사용하는 도구에 대해 열정적이 될 수 있습니다. 데이터베이스 팀과 API 팀이 응답 시간에 대해 서로 다른 얘기를 하고 있을 때, 당신의 역할은 사실을 제시하는 것이 아닙니다. 대신 분위기를 읽고 기술적 제약과 불명확한 요구사항을 해결할 방법을 찾는 것입니다. 이는 기술 토론이 생산적일 때와 감정적 충돌로 변질되었을 때를 구분하고, 후자의 경우 적절히 개입할 줄 아는 것을 의미합니다.</p><h3 id="c42a">리딩은 목표를 기억하는 것입니다</h3><p id="6a2d">당신이 자신의 분야에서 전문가일 때는 깊이 파고들기를 좋아합니다. 그것이 당신을 전문가로 만들 겁니다. 그러나 모두가 나무를 살펴보는 동안 누군가는 숲 전체를 주시해야 합니다.</p><p id="7d36">저는 엔지니어들이 다양한 캐싱 전략의 장점에 대해 토론하는 수많은 회의에 참석했지만, 실제 문제는 사용자 경험을 위해 “충분히 빠르다”는 것이 무엇을 의미하는지 명확하게 정의하지 않았다는 것이었습니다. 기술적 토론은 흥미로웠지만, 우리를 출시를 향해 나아가게 하지 못했습니다.</p><p id="faf1">리더로서 당신의 일은 정교한 기술적 의견을 갖는 것이 아닙니다. 이 “토론”이 우리의 실제 문제를 해결하는 데 어떻게 더 가까워질 수 있는지 묻는 것입니다.</p><p id="f0e1">문제를 이해하고 전문가들로 가득 찬 방이 있다면, 해결책은 종종 토론에서 나옵니다. 하지만 누군가는 우리가 실제로 해결하려는 문제가 무엇인지 명확하게 설명해야 합니다.</p><p id="e7e0">프로덕트 팀이 고객들이 앱이 너무 느리다고 보고한다고 말할 때, 그것은 명확한 문제가 아닙니다. 그것은 증상입니다. 사용자들이 장바구니가 로드되는 것을 알아차리지 못하거나, 적절한 시점에 트리거 되지 않는 이벤트가 있거나, 피크 시간대에 앱이 느리게 느껴지는 것일 수 있습니다. 이러한 문제들 각각은 다른 해결책, 다른 우선순위, 다른 트레이드오프를 가집니다. 각 전문가는 자신의 시각으로 문제를 보고 있을 수 있으며, 실제 근본 문제를 놓칠 수 있습니다.</p><p id="2dbc">리더로서 당신의 역할은 팀원들이 문제를 명확하게 이해할 수 있는 방식으로 문제를 전달 하는 것입니다.</p><h3 id="c955">리딩은 “저는 모르겠습니다”라고 말하는 것입니다</h3><p id="7396">정의상 리딩은 나아갈 길을 아는 것입니다. 하지만 현실에서 전문가들로 가득 찬 방에서 모든 것을 아는 척하는 것은 당신을 바보처럼 보이게 만듭니다.</p><p id="41f0">대신 “모르겠습니다, 하지만 함께 알아봅시다”가 슈퍼파워가 됩니다. 이 말은 당신의 전문가들이 불확실성을 자유롭게 드러낼 수 있도록 해 줍니다. 지적 겸손을 모델링합니다. 그리고 자아를 방어하는 것보다 앞으로 나아가는 데 집중하게 합니다. 또한 당신의 전문가들이 빛날 수 있는 기회이기도 합니다.</p><p id="78f5">모든 대화에서 <a href="https://idiallo.com/blog/when-the-manager-gets-all-the-credit" rel="noopener ugc nofollow" target="_blank">가장 똑똑한 사람이 되어야 하는 리드</a>만큼 짜증 나는 것은 없습니다. 당신의 데이터베이스 전문가는 쿼리를 최적화하는 방법을 배우는 데 수년을 보냈습니다. 성능 문제가 발생할 때 그들이 영웅이 되도록 하세요. 당신의 보안 전문가는 당신보다 위협 모델을 더 잘 알고 있습니다. 아키텍처 결정을 논의할 때 그들에게 발언권을 주세요.</p><p id="2308">생산적인 토론을 위한 공간을 만드세요. 두 명의 전문가가 구현 접근 방식에 대해 의견이 다를 때, 당신의 일은 “올바른” 답을 고르는 것이 아닙니다. 트레이드오프, 일정, 사용자 영향의 관점에서 결정을 재구성 하는 것을 돕는 것입니다.</p><p id="9de0">당신의 가치는 모든 전문성을 갖는 것이 아닙니다. 언제 어떤 전문성이 필요한지 인식하고, 적절한 사람들이 최고의 작업을 기여할 수 있는 공간을 만드는 것입니다.</p><h3 id="e89f">통역 챌린지</h3><p id="a18f">최근에 읽은 재미있는 블로그 포스트가 있었습니다. 개발자가 아닌 사람들이 <a href="https://anniemueller.com/posts/how-i-a-non-developer-read-the-tutorial-you-a-developer-wrote-for-me-a-beginner" rel="noopener ugc nofollow" target="_blank">개발자가 작성한 튜토리얼을 어떻게 읽는지에 대한 것</a>이었습니다. 당신에게 자연스럽게 들리는 것이 다른 사람에게는 완전히 알아들을 수 없는 말일 수 있습니다. 리드로서 당신은 끊임없이 청중에 대해 생각해야 합니다. 같은 것을 전달하기 위해 여러 언어를 배워야 합니다.</p><p id="0221">개발자 언어: “인증 서비스는 사용자 서비스에 의존성(dependency)이 있고, 적절한 서킷 브레이커(circuit breaker)를 구현하지 않으면 높은 부하 시 연쇄 장애(cascading failure)가 발생할 것입니다.”</p><p id="d712">프로덕트 언어: “로그인 시스템이 다운되면 전체 앱을 함께 다운시킬 수 있습니다. 몇 가지 안전장치를 구축해야 하는데, 이것은 일정에 약 일주일을 추가하지만 잠재적인 중단을 방지합니다.”</p><p id="e76e">임원 언어: “이번 스프린트에서는 기능 속도보다 시스템 안정성을 우선시하고 있습니다. 이것은 매출에 영향을 줄 수 있는 사용자 대상 서비스의 중단 위험을 줄입니다.”</p><p id="66fd">세 가지 진술 모두 같은 기술적 결정을 설명하지만, 각각은 청중을 위해 만들어졌습니다. 당신의 전문가들은 프로덕트 언어를 배울 필요가 없어야 하고, 당신의 프로덕트 팀은 서킷 브레이커 패턴을 이해할 필요가 없어야 합니다. 하지만 누군가는 그 격차를 메워야 합니다.</p><h2 id="cbb0">“그냥 그런거야!”를 넘어서</h2><figure></figure><p id="4ef1">“제가 리드니, 우리는 이런 식으로 할 겁니다.” 그것은 아마도 결정을 내리는 최악의 방법일 것입니다. 그것은 단기적으로는 효과가 있을 수 있지만, 신뢰를 무너뜨리고 전문가 팀을 번영하게 만드는 협력 문화를 죽입니다.</p><p id="4911">대신, 팀을 신뢰하고 결정의 이유를 전달하세요.</p><ul><li id="f55d">“우리는 더 보수적인 접근 방식을 선택합니다. 왜냐하면 틀렸을 때의 비용이 높고, 나중에 반복할 수 있기 때문입니다.”</li><li id="3b18">“이것이 추가 작업처럼 느껴지는 것을 알지만, 우리의 아키텍처 목표와 일치하며 다음 세 가지 기능에서 시간을 절약할 것입니다.”</li><li id="5bea">“이것은 가장 우아한 해결책은 아니지만, 우리 일정 내에서 자신 있게 출시할 수 있는 해결책입니다.”</li></ul><p id="7575">전문가가 아니라는 것에 더 편안해질수록, 리더로서 더 효과적이 됩니다.</p><p id="b0c0">전문가들을 능가하려고 하는 것을 멈추면, 전문가 팀이 실제로 필요로 하는 것에 집중할 수 있습니다.</p><ul><li id="4227">명확한 문제 정의</li><li id="2dca">의사결정을 위한 맥락</li><li id="d9f1">다양한 관점 간의 해석</li><li id="dfc8">불필요한 복잡성으로부터의 보호</li><li id="0694">최고의 작업을 할 수 있는 공간</li></ul><p id="eeed">당신의 역할은 모든 답을 갖는 것이 아닙니다. 올바른 질문이 제기되고, 올바른 사람들의 의견이 들리고, 올바른 결정이 올바른 이유로 이루어지도록 하는 것입니다.</p><p id="f4a1">전문가 환경에서의 기술적 리더십은 명령과 통제에 관한 것이 아니라 연결과 맥락에 관한 것입니다. 당신은 모든 악기를 직접 연주하려는 지휘자가 아닙니다. 당신은 오케스트라가 함께 연주하는 곡이 무엇인지 이해하도록 돕는 사람입니다.</p><p id="3db3">그것은 방에서 가장 똑똑한 사람이 되려고 하는 것보다 훨씬 더 흥미로운 도전일 겁니다.</p></div></div>

Stories by Jung Han on Medium

한정

원문: https://idiallo.com/blog/how-to-lead-in-a-room-full-of-experts
최근에 깨달은 점이 있습니다. 저는 똑똑한 사람들로 가득 찬 방에 앉아 있습니다. 한쪽에는 우리 마이크로서비스 아키텍처의 세세한 부분까지 이해하는 개발자들이 있습니다. 다른 한쪽에는 잠결에도 리액트를 디버깅할 수 있는 프런트엔드 개발자들이 있습니다. 제 앞에는 우리 웹사이트에 존재하는 모든 가능한 사용자 경로를 외운 프로덕트 팀이 있습니다. 그리고 저, 리드 개발자가 있습니다. 저는 어떤 단일 기술에 대해서도 가장 깊은 전문성을 가지고 있지 않습니다.
그렇다면 전문가들에 둘러싸여 있을 때 제 역할은 정확히 무엇일까요? 글쎄요, 간단합니다. 저는 모든 답을 가지고 있습니다.
기술적 리더십
좋습니다. 엄밀히 말하면 저는 모든 답을 가지고 있는건 아닙니다. 하지만 저는 답을 어디서 찾고 파편을 어떻게 하나로 만드는지 정확히 알고 있습니다.
백엔드 팀이 새로운 인증 서비스를 구축하는 데 왜 3주가 걸리는지 설명할 때, 저는 OAuth 플로우나 JWT 토큰 검증에 대해 생각하지 않습니다. 대신 “이번 주 중에” 완료되기를 기대하는 프로덕트 팀에게 이 내용을 어떻게 전달할 수 있을지 생각합니다. 프로덕트 팀이 “간단한” 기능을 요청할 때, 저는 필요한 마이크로서비스를 업데이트하기 위해 관여해야 하는 3개 팀에 대해 생각합니다.
기술 환경에서의 리더십은 방에서 가장 똑똑한 사람이 되는 것이 아닙니다. 가장 효과적인 통역사가 되는 것입니다.
리딩은 사회 기술(Social Skill)입니다
개발자들에게 이렇게 말하면 종종 못마땅해합니다. 사실만으로는 누구도 설득할 수 없습니다. 전문가들로 가득 찬 방에서 당신의 기술적 신뢰성은 회의에 참여할 자격을 줍니다. 하지만 실제로 생산적인 결과를 만들어내는 것은 당신의 사회 기술입니다.
모두가 읽고 이해할 수 있는 문서를 제공하는것이 이상적이지만, 현실에서는 사람들이 이해하도록 만들기 위해 대화를 해야 합니다. 사람들은 자신이 사용하는 도구에 대해 열정적이 될 수 있습니다. 데이터베이스 팀과 API 팀이 응답 시간에 대해 서로 다른 얘기를 하고 있을 때, 당신의 역할은 사실을 제시하는 것이 아닙니다. 대신 분위기를 읽고 기술적 제약과 불명확한 요구사항을 해결할 방법을 찾는 것입니다. 이는 기술 토론이 생산적일 때와 감정적 충돌로 변질되었을 때를 구분하고, 후자의 경우 적절히 개입할 줄 아는 것을 의미합니다.
리딩은 목표를 기억하는 것입니다
당신이 자신의 분야에서 전문가일 때는 깊이 파고들기를 좋아합니다. 그것이 당신을 전문가로 만들 겁니다. 그러나 모두가 나무를 살펴보는 동안 누군가는 숲 전체를 주시해야 합니다.
저는 엔지니어들이 다양한 캐싱 전략의 장점에 대해 토론하는 수많은 회의에 참석했지만, 실제 문제는 사용자 경험을 위해 “충분히 빠르다”는 것이 무엇을 의미하는지 명확하게 정의하지 않았다는 것이었습니다. 기술적 토론은 흥미로웠지만, 우리를 출시를 향해 나아가게 하지 못했습니다.
리더로서 당신의 일은 정교한 기술적 의견을 갖는 것이 아닙니다. 이 “토론”이 우리의 실제 문제를 해결하는 데 어떻게 더 가까워질 수 있는지 묻는 것입니다.
문제를 이해하고 전문가들로 가득 찬 방이 있다면, 해결책은 종종 토론에서 나옵니다. 하지만 누군가는 우리가 실제로 해결하려는 문제가 무엇인지 명확하게 설명해야 합니다.
프로덕트 팀이 고객들이 앱이 너무 느리다고 보고한다고 말할 때, 그것은 명확한 문제가 아닙니다. 그것은 증상입니다. 사용자들이 장바구니가 로드되는 것을 알아차리지 못하거나, 적절한 시점에 트리거 되지 않는 이벤트가 있거나, 피크 시간대에 앱이 느리게 느껴지는 것일 수 있습니다. 이러한 문제들 각각은 다른 해결책, 다른 우선순위, 다른 트레이드오프를 가집니다. 각 전문가는 자신의 시각으로 문제를 보고 있을 수 있으며, 실제 근본 문제를 놓칠 수 있습니다.
리더로서 당신의 역할은 팀원들이 문제를 명확하게 이해할 수 있는 방식으로 문제를 전달 하는 것입니다.
리딩은 “저는 모르겠습니다”라고 말하는 것입니다
정의상 리딩은 나아갈 길을 아는 것입니다. 하지만 현실에서 전문가들로 가득 찬 방에서 모든 것을 아는 척하는 것은 당신을 바보처럼 보이게 만듭니다.
대신 “모르겠습니다, 하지만 함께 알아봅시다”가 슈퍼파워가 됩니다. 이 말은 당신의 전문가들이 불확실성을 자유롭게 드러낼 수 있도록 해 줍니다. 지적 겸손을 모델링합니다. 그리고 자아를 방어하는 것보다 앞으로 나아가는 데 집중하게 합니다. 또한 당신의 전문가들이 빛날 수 있는 기회이기도 합니다.
모든 대화에서 가장 똑똑한 사람이 되어야 하는 리드만큼 짜증 나는 것은 없습니다. 당신의 데이터베이스 전문가는 쿼리를 최적화하는 방법을 배우는 데 수년을 보냈습니다. 성능 문제가 발생할 때 그들이 영웅이 되도록 하세요. 당신의 보안 전문가는 당신보다 위협 모델을 더 잘 알고 있습니다. 아키텍처 결정을 논의할 때 그들에게 발언권을 주세요.
생산적인 토론을 위한 공간을 만드세요. 두 명의 전문가가 구현 접근 방식에 대해 의견이 다를 때, 당신의 일은 “올바른” 답을 고르는 것이 아닙니다. 트레이드오프, 일정, 사용자 영향의 관점에서 결정을 재구성 하는 것을 돕는 것입니다.
당신의 가치는 모든 전문성을 갖는 것이 아닙니다. 언제 어떤 전문성이 필요한지 인식하고, 적절한 사람들이 최고의 작업을 기여할 수 있는 공간을 만드는 것입니다.
통역 챌린지
최근에 읽은 재미있는 블로그 포스트가 있었습니다. 개발자가 아닌 사람들이 개발자가 작성한 튜토리얼을 어떻게 읽는지에 대한 것이었습니다. 당신에게 자연스럽게 들리는 것이 다른 사람에게는 완전히 알아들을 수 없는 말일 수 있습니다. 리드로서 당신은 끊임없이 청중에 대해 생각해야 합니다. 같은 것을 전달하기 위해 여러 언어를 배워야 합니다.
개발자 언어: “인증 서비스는 사용자 서비스에 의존성(dependency)이 있고, 적절한 서킷 브레이커(circuit breaker)를 구현하지 않으면 높은 부하 시 연쇄 장애(cascading failure)가 발생할 것입니다.”
프로덕트 언어: “로그인 시스템이 다운되면 전체 앱을 함께 다운시킬 수 있습니다. 몇 가지 안전장치를 구축해야 하는데, 이것은 일정에 약 일주일을 추가하지만 잠재적인 중단을 방지합니다.”
임원 언어: “이번 스프린트에서는 기능 속도보다 시스템 안정성을 우선시하고 있습니다. 이것은 매출에 영향을 줄 수 있는 사용자 대상 서비스의 중단 위험을 줄입니다.”
세 가지 진술 모두 같은 기술적 결정을 설명하지만, 각각은 청중을 위해 만들어졌습니다. 당신의 전문가들은 프로덕트 언어를 배울 필요가 없어야 하고, 당신의 프로덕트 팀은 서킷 브레이커 패턴을 이해할 필요가 없어야 합니다. 하지만 누군가는 그 격차를 메워야 합니다.
“그냥 그런거야!”를 넘어서
“제가 리드니, 우리는 이런 식으로 할 겁니다.” 그것은 아마도 결정을 내리는 최악의 방법일 것입니다. 그것은 단기적으로는 효과가 있을 수 있지만, 신뢰를 무너뜨리고 전문가 팀을 번영하게 만드는 협력 문화를 죽입니다.
대신, 팀을 신뢰하고 결정의 이유를 전달하세요.
“우리는 더 보수적인 접근 방식을 선택합니다. 왜냐하면 틀렸을 때의 비용이 높고, 나중에 반복할 수 있기 때문입니다.”
“이것이 추가 작업처럼 느껴지는 것을 알지만, 우리의 아키텍처 목표와 일치하며 다음 세 가지 기능에서 시간을 절약할 것입니다.”
“이것은 가장 우아한 해결책은 아니지만, 우리 일정 내에서 자신 있게 출시할 수 있는 해결책입니다.”
전문가가 아니라는 것에 더 편안해질수록, 리더로서 더 효과적이 됩니다.
전문가들을 능가하려고 하는 것을 멈추면, 전문가 팀이 실제로 필요로 하는 것에 집중할 수 있습니다.
명확한 문제 정의
의사결정을 위한 맥락
다양한 관점 간의 해석
불필요한 복잡성으로부터의 보호
최고의 작업을 할 수 있는 공간
당신의 역할은 모든 답을 갖는 것이 아닙니다. 올바른 질문이 제기되고, 올바른 사람들의 의견이 들리고, 올바른 결정이 올바른 이유로 이루어지도록 하는 것입니다.
전문가 환경에서의 기술적 리더십은 명령과 통제에 관한 것이 아니라 연결과 맥락에 관한 것입니다. 당신은 모든 악기를 직접 연주하려는 지휘자가 아닙니다. 당신은 오케스트라가 함께 연주하는 곡이 무엇인지 이해하도록 돕는 사람입니다.
그것은 방에서 가장 똑똑한 사람이 되려고 하는 것보다 훨씬 더 흥미로운 도전일 겁니다.

(번역) 전문가들로 가득한 방에서 리드하는 법

댓글