<div id="readability-page-1" class="page"><article dir="ltr" data-pagefind-body="true"><h2>좋은 결정은 맥락에서 나온다</h2><p><img src="https://feel5ny.github.io/images/2026/08/22/thumb_default.jpg" alt="좋은 결정은 맥락에서 나온다"></p><p>조직에서 결정이 느려지거나 나빠지는 순간을 관찰해보면, 원인이 사람의 역량인 경우보다 구조인 경우가 많다. 결정하는 사람과 맥락을 가진 사람이 서로 다른 사람인 구조. 이 글은 그 관찰에서 출발한 세 가지 생각과, 그 생각을 뒷받침해준 글들에 대한 기록이다.</p>
<p>요약하면 이렇다. <strong>가장 좋은 결정은 맥락을 가장 잘 아는 사람에게서 나온다. 그런 사람이 파트마다 있어야 조직 전체가 같이 올라간다. 그리고 지금은, AI가 그 비용을 낮춰주고 있다.</strong></p>
<h2 id="맥락을-가진-사람이-가장-잘-결정한다">맥락을 가진 사람이 가장 잘 결정한다</h2>
<p>좋은 기술 결정은 대체로 그 코드를 매일 만지는 사람에게서 나온다. 문제의 히스토리를 알고, 트레이드오프의 실물을 만져봤고, 결정의 결과를 자기가 감당할 사람. 리더가 결정을 가져가는 만큼, 결정은 이 맥락에서 멀어진다.</p>
<p>넷플릭스는 이 생각을 **“Context, not Control”**이라는 원칙으로 운영까지 밀어붙였다. 리드 헤이스팅스의 『규칙 없음(No Rules Rules)』에 나오는 내용인데, 넷플릭스에서 결정권자는 상사가 아니다. 그 사안에 대해 가장 많은 정보를 가진 사람, 이른바 <em>informed captain</em>이다. 모든 중요한 결정에는 캡틴이 이름으로 지정되고, 캡틴은 결정 전에 여러 직급의 반대 의견을 적극적으로 수집하되(farming for dissent), 결정은 다수결이 아니라 캡틴이 내린다. 리더의 역할은 그 사람이 최고의 결정을 내릴 수 있도록 맥락을 설정하는 것.</p>
<img src="https://feel5ny.github.io/images/2026/08/22/fig1-informed-captain.svg" alt="전통적 피라미드와 informed captain 구조 비교 — 왼쪽은 맥락이 아래에 있는데 결정은 위에서 내려오는 구조, 오른쪽은 리드가 맥락과 정렬을 내려주고 맥락을 가진 캡틴이 의견을 수집해 결정하는 구조">
<blockquote>
<p>“고성과 직원들이 있다면 맥락으로 리드하는 것이 최선이다. 독창적인 사고를 원한다면, 직원에게 무엇을 해야 할지 말하지 마라.”</p>
</blockquote>
<p>눈여겨볼 대목은, 이게 편한 리더십이 아니라는 걸 원칙 스스로 숨기지 않는다는 점이다. 헤이스팅스는 맥락을 설정하는 일이 명령을 내리는 것보다 훨씬 더 많은 품과 지속성을 요구한다고 썼고, 실제로 1년에 750시간을 1:1 미팅에 썼다고 한다. 결정하지 않는 리더는 게으른 리더가 아니라, 다른 곳에 품을 쓰는 리더다.</p>
<h2 id="그런-사람이-파트마다-있어야-전체가-올라간다">그런 사람이 파트마다 있어야 전체가 올라간다</h2>
<p>맥락 있는 사람이 결정을 잘한다는 것까지는 다들 동의한다. 문제는 많은 조직이 그 “맥락 있는 사람”을 한 명만 만든다는 것이다. 제일 잘 아는 사람에게 질문이 몰리고, 질문이 몰리니 더 잘 알게 되고, 더 잘 아니까 결정도 몰린다. 이 순환은 평소엔 효율처럼 보이지만, 그 한 사람을 <strong>병목</strong>이자 <strong>단일장애점</strong>으로 만든다. 모든 결정이 한 사람을 통과해야 하니 조직의 속도가 그 사람의 캘린더에 종속되고, 그 사람이 자리를 비우면 조직의 판단력이 함께 사라진다.</p>
<p>그래서 방향은 “가장 잘 아는 한 명”이 아니라 **“파트마다 가장 잘 아는 한 명”**이어야 한다. 도메인별로 informed captain이 서고, 각자의 영역에서 결정이 병렬로 일어나는 구조. 전체를 끌어올리는 건 한 명의 뛰어난 결정자가 아니라, 여럿의 맥락 있는 결정자다.</p>
<img src="https://feel5ny.github.io/images/2026/08/22/fig2-bottleneck-vs-captains.svg" alt="가장 잘 아는 한 명에게 모든 결정이 몰리는 병목 구조와, 파트마다 informed captain이 서서 결정이 병렬로 일어나는 구조의 비교">
<p>앤드류 하멜-로우(Andrew Harmel-Law)의 **조언 프로세스(advice process)**가 정확히 이 구조를 설계한다. 아키텍처 결정이 아키텍트 한 사람의 목을 통과하느라 조직이 느려지는 문제에 대해, 그의 해법은 과감하다. 결정은 누구나 내릴 수 있다. 다만 영향받는 사람들과 전문가에게 조언을 구할 것, 그리고 그 결정을 ADR(Architecture Decision Record)로 기록해 공개할 것. 결정권을 열면서도 무질서로 흐르지 않게 하는 장치가 프로세스 안에 내장되어 있다. 결정이 문서가 되는 순간, 결정은 한 사람의 머릿속이 아니라 누구나 검토하고 반박할 수 있는 공공재가 된다.</p>
<h2 id="그리고-지금은-ai가-그-비용을-낮춘다">그리고 지금은, AI가 그 비용을 낮춘다</h2>
<p>이 구조가 옳다는 걸 알면서도 조직들이 못 갔던 이유는 비용이다. 파트마다 캡틴이 서려면 두 가지 비용을 치러야 한다.</p>
<p>하나는 <strong>맥락을 쌓는 비용</strong>이다. 한 도메인의 히스토리, 코드, 과거 결정의 이유를 흡수하는 데 오래 걸렸고, 그래서 “제일 잘 아는 사람”은 오래 있었던 사람일 수밖에 없었다. 지금은 다르다. AI에게 코드베이스를 읽히고, 과거 문서와 논의를 요약시키고, “이 결정이 왜 이렇게 됐지”를 물을 수 있다. 맥락 획득의 진입장벽이 낮아지면, 캡틴이 될 수 있는 사람의 풀이 넓어진다.</p>
<p>다른 하나는 <strong>기록하고 가시화하는 비용</strong>이다. 결정을 문서로 남기고, 액션아이템을 정리하고, 흩어진 논의를 한곳에 모으는 일. 타냐 라일리(Tanya Reilly)가 **“Being Glue”**에서 지적했듯, 이런 글루 워크는 조직에 필수적이면서도 눈에 띄지 않고 저평가되어서, 결국 아무도 안 하거나 한 사람이 떠안게 된다. 그런데 이 일이야말로 AI가 잘 돕는 영역이다. 회의에서 결정문 초안을 뽑고, 논의를 액션아이템으로 정리하고, 문서의 인덱스를 유지하는 비용이 급격히 떨어지고 있다. 장을 만드는 일의 원가가 내려가고 있는 것이다.</p>
<img src="https://feel5ny.github.io/images/2026/08/22/fig3-ai-costs.svg" alt="파트별 캡틴을 가로막던 두 가지 비용 — 맥락을 쌓는 비용과 기록·가시화하는 비용 — 이 AI와 함께 낮아지는 것을 나타낸 개념도">
<p>맥락의 비용과 가시화의 비용이 같이 떨어지면, “파트마다 informed captain”은 이상론이 아니라 설계 가능한 목표가 된다.</p>
<h2 id="그래서-나는-뭘-해보고-있나">그래서 나는 뭘 해보고 있나</h2>
<p>4월부터 웹 챕터리드를 맡으면서, 이 생각들을 우리 규모에 맞는 작은 장치로 옮겨보는 중이다. 의사결정을 기록해서 누구나 검토하고 반박할 수 있게 하고, 액션아이템을 가시화해서 조율이 리드를 거치지 않아도 일어나게 하고, 판단과 리뷰의 권한이 특정 사람에게 몰리지 않도록 규칙으로 분산하고. 하나하나는 사소하지만 방향은 같다. <strong>리드를 통하지 않아도 의견이 흐르고, 일이 보이고, 결정이 일어나게 만드는 것.</strong></p>
<p>원래부터 일이 사람에게 몰리는 걸 보면 시스템으로 풀고 싶어지는 성향이 있었다. 위의 글들은 그 본능에 언어와 근거를 붙여줬고, AI는 그 방향의 실행 비용을 낮춰주고 있다.</p>
<h2 id="다만-정렬-없는-자율은-방임이다">다만, 정렬 없는 자율은 방임이다</h2>
<p>이런 주장에는 “그럼 리더는 결정을 안 하는 사람인가”라는 반문이 따라오는데, 원문들도 그렇게 말하지 않는다.</p>
<p>넷플릭스는 자율 앞에 전제를 붙인다. <em>Highly aligned, loosely coupled</em> — 실행이 느슨하게 풀리려면, 방향에 대한 정렬은 오히려 강해야 한다. 조언 프로세스도 마찬가지다. 아무나 마음대로 결정하는 게 아니라, 조언을 구하는 의무가 결정권과 한 몸이다. 정렬 없이 자율만 주는 건 위임이 아니라 방임이다.</p>
<p>그리고 장을 아무리 잘 만들어도 합의가 안 되는 순간은 반드시 온다. 양쪽 다 근거가 타당하고, 논의를 더 해도 평행선인 순간. 그때 끊어주는 건 여전히 리드의 일이다. “이번엔 이 방향으로 갑니다. 이유는 이거고, 한 분기 뒤에 재검토합니다.” 교착을 깨는 결정을 미루면, 팀은 그 침묵을 자율이 아니라 방치로 읽는다.</p>
<p>그러니까 바뀌어야 하는 건 “리더는 결정하는 사람”이라는 명제 전체가 아니라, 결정의 기본값이다. 기본값은 맥락을 가진 사람이 결정하는 것. 리드는 방향을 정렬하고, 결정이 잘 일어나도록 장을 만들고, 장이 실패하는 순간에만 개입하는 것.</p>
<h2 id="아직-실험-중이다">아직 실험 중이다</h2>
<p>5개월은 결론을 내리기엔 짧다. 만들어둔 장치들이 내가 손을 떼도 굴러가는지, 결국 내가 계속 밀어야 도는 바퀴인지는 시간이 더 지나야 안다. 파트마다 캡틴이 서는 그림도 아직은 방향이지 현실이 아니다.</p>
<p>다만 확신하는 건 하나다. 프레이밍은 말로 바뀌지 않는다. 리더에 대한 이미지가 바뀌는 건 선언문이 아니라, 리드가 없는 회의에서도 결정이 잘 일어나는 경험이 쌓였을 때다. 좋은 글들이 방향에 언어를 붙여줬고 AI가 비용을 낮춰줬으니, 이제 그걸 경험으로 바꾸는 게 내 일이다.</p>
<p>몇 달 뒤에, 이 실험이 어디까지 갔는지 다시 쓰겠다.</p>
<hr>
<h2 id="참고">참고</h2>
<ul>
<li><a href="https://jobs.netflix.com/culture" target="_blank" rel="noreferrer">Netflix Culture Memo&nbsp;<svg fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="1.7" viewBox="0 0 24 24" height="1em"><path d="M7 17L17 7"></path><path d="M7 7h10v10"></path></svg></a> — informed captain, farming for dissent, highly aligned loosely coupled</li>
<li><a href="https://www.leadingsapiens.com/netflix-leads-with-context-not-control/" target="_blank" rel="noreferrer">Why Netflix Leads with Context not Control&nbsp;<svg fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="1.7" viewBox="0 0 24 24" height="1em"><path d="M7 17L17 7"></path><path d="M7 7h10v10"></path></svg></a> — 리드 헤이스팅스, 『규칙 없음(No Rules Rules)』의 원칙 해설</li>
<li><a href="https://martinfowler.com/articles/scaling-architecture-conversationally.html" target="_blank" rel="noreferrer">Scaling the Practice of Architecture, Conversationally&nbsp;<svg fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="1.7" viewBox="0 0 24 24" height="1em"><path d="M7 17L17 7"></path><path d="M7 7h10v10"></path></svg></a> — Andrew Harmel-Law, 조언 프로세스(advice process)</li>
<li><a href="https://www.noidea.dog/glue" target="_blank" rel="noreferrer">Being Glue&nbsp;<svg fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="1.7" viewBox="0 0 24 24" height="1em"><path d="M7 17L17 7"></path><path d="M7 7h10v10"></path></svg></a> — Tanya Reilly, 글루 워크에 대하여</li>
</ul><h2>Related</h2></article></div>

필오의 개발일지

가장 좋은 결정은 맥락을 가장 잘 아는 사람에게서 나오고, 그런 사람이 파트마다 있어야 조직 전체가 올라간다 — 넷플릭스의 Context not Control, 조언 프로세스, 글루 워크, 그리고 AI가 낮춰주는 비용에 대한 기록

좋은 결정은 맥락에서 나온다

댓글