Shawna Martell과 Dan Fike가 말하는 의사결정 분권화
- Aisha Washington
- 2시간 전
- 6분 분량
엔지니어링 조직은 흔히 팀이 자율적으로 움직이기를 원한다고 말합니다. 하지만 실제로 의사결정은 여전히 상위로 올라가거나, 회의에서 지연되거나, 마침 자리에 있는 시니어 아키텍트에게 의존하게 됩니다. Shawna Martell과 Dan Fike는 Cartek에서 개발한 다른 모델을 설명합니다. 명시적인 엔지니어링 전략을 수립한 뒤, Navigator라고 불리는 신뢰받는 기술 리더가 팀이 그 전략을 적용하도록 돕는 방식입니다.
이들의 접근법은 분권화를 단순한 권한 위임 이상의 것으로 봅니다. 사람들에게는 공유된 원칙, 충분한 현장 맥락, 경험 많은 조언자에 대한 접근성, 그리고 전략에 이의를 제기하거나 개선할 방법이 필요합니다. 이러한 요소들이 함께 작동하면 개인 기여자도 모든 질문을 관리 체계나 중앙화된 아키텍처 기능을 거치게 하지 않고 중요한 결정을 내릴 수 있습니다.
자율성에 엔지니어링 전략이 필요한 이유
Martell과 Fike는 Navigator 프로그램의 출발점을 반복적으로 발생하던 문제에서 찾습니다. 엔지니어들은 더 명확한 지침을 원했습니다. 합의된 프레임워크가 없다면 팀은 상충하는 기술적 선택지를 신뢰성 있게 판단할 수 없었고, 어떤 조직적 우선순위가 우선해야 하는지도 알 수 없었습니다.
그 결과가 반드시 나쁜 엔지니어링은 아니었습니다. 문제는 일관성 없는 엔지니어링이었다는 점입니다. 비슷한 트레이드오프에 직면한 두 팀이 서로 양립할 수 없는 결론에 이를 수 있었습니다. 각 팀이 서로 다른, 대부분 암묵적인 기준을 사용했기 때문입니다. 같은 논쟁은 반복해서 되풀이되었고, 지속 가능한 조직 지식을 만들어 내지 못한 채 시간을 소모했습니다.
모든 선택을 중앙에서 승인했다면 병목을 만드는 대가로 불일관성을 해결할 수 있었을 것입니다. 대신 Cartek은 좋은 의사결정의 근거를 널리 활용 가능하게 만들고자 했습니다. 엔지니어링 전략은 공유 참조점이 되었습니다. 즉, 조직이 트레이드오프를 평가하는 방식과 특정 상황에서 무엇을 중시하는지를 문서화한 설명입니다.
중요하게도 이 전략은 엔지니어들이 맥락을 요청한 데 대한 응답으로 탄생했습니다. Martell과 Fike는 이를 경영진이 고립된 상태에서 만들어 낸 지시 사항으로 제시하지 않습니다. 그 목적은 기여자들이 더 넓은 방향성과 연결된 선택을 유지하면서 행동할 자신감을 갖게 하는 것이었습니다.
이상적인 포스터가 아니라 현실에서 시작하기
Cartek의 프로세스에서 눈에 띄는 부분은 이미 의사결정이 이루어지고 있는 방식을 문서화하는 데 중점을 둔 점입니다. 팀은 이상적인 미래 조직을 묘사하는 것으로 시작하지 않았습니다. 먼저 일관성이 없어 보이거나 정당화하기 어려운 관행을 포함해 현재 상태를 살펴보았습니다.
이런 종류의 조직 고고학은 중요합니다. 어느 엔지니어링 그룹이든, 아무도 이를 기록해 두지 않았더라도 이미 전략을 갖고 있기 때문입니다. 전략은 반복되는 선택 속에 존재합니다. 팀이 즉각적인 성능과 미래의 확장성 중 무엇을 최적화하는지, 유연성을 높이기 위해 운영 복잡성을 감수하는지, 또는 새 서비스를 만드는 대신 기존 시스템을 확장하는지에 나타납니다.
과거의 설계 문서와 아키텍처 결정 기록은 이러한 패턴을 드러낼 수 있습니다. 유용한 기록에는 검토한 대안, 각 대안의 이점과 비용, 그리고 한 선택지가 우세했던 이유가 담깁니다. 여러 기록을 함께 보면 그러한 선택 뒤에 있는 가치가 드러납니다.
Martell과 Fike는 그 가치를 결정 자체와 구분합니다. 결정은 한 사례에서 무엇이 일어났는지를 말합니다. 원칙은 다른 사례에도 적용될 수 있는 조건부 지침을 제공합니다. 사실상 “이 조건이 적용될 때는 이 대응을 우선하라”는 뜻입니다. 그러한 원칙을 추출하려면, 특히 문서가 결과는 기록했지만 그 근거는 빠뜨린 경우, 과거 결정의 배경에 있던 사람들과 상황을 다시 살펴봐야 할 수 있습니다.
정직하게 시작하면 변화도 측정할 수 있습니다. 이상화된 전략은 고무적으로 들릴 수 있지만 정책과 실제 관행 사이의 거리를 감출 수 있습니다. 실제 시스템을 설명하면 조직이 의도적으로 더 나아질 수 있는 기준선이 만들어집니다.
Navigator는 팀이 지도를 읽도록 돕는다
프로그램의 이름은 중요한 책임 분담을 담고 있습니다. 엔지니어링 전략이 지도처럼 기능한다면, Navigator는 낯선 지형에서 사람들이 그 지도를 해석하도록 돕습니다. 이들은 전략에 기여하지만, 주된 역할은 전체 계획을 지시하거나 모든 기술적 질문을 직접 결정하는 것이 아닙니다.
논의된 당시, 약 12명의 Navigator가 약 400명 규모의 엔지니어링 조직을 지원했습니다. 이들은 프런트엔드와 백엔드 엔지니어링, 신뢰성, 보안 등 여러 기술 분야 출신이었습니다. 공식적인 위계에서의 위치도 다양했습니다. 일부는 팀 내부에서 깊이 일했고, 다른 일부는 시니어 리더십에 더 가까운 위치에서 활동했습니다.
선발은 직함보다 입증된 판단력, 기술적 깊이, 영향력에 더 크게 좌우되었습니다. Martell과 Fike는 관리 조직도와 나란히 존재하는 비공식 네트워크를 설명합니다. 어떤 엔지니어들은 문제가 모호할 때 동료들이 자연스럽게 찾아가 조언을 구하는 사람이 됩니다. Navigator 모델은 권한이 보고 체계만을 통해 흐른다고 가정하는 대신, 그러한 신뢰받는 인물을 인정하고 연결합니다.
Navigator는 자신을 둘러싼 제품과 시스템에 관한 상당한 맥락을 알아야 합니다. 어떤 결정이 진행 중인지 알고, 작업이 전략과 충돌하는 시점을 파악하며, 팀에 도움이 필요할 때 개입해야 합니다. 그렇다고 통제권을 가져간다는 뜻은 아닙니다. Navigator는 팀이 트레이드오프를 검토하도록 코칭하고, 관련 원칙을 식별하거나, 해결되지 않은 문제를 더 넓은 Navigator 그룹으로 가져갈 수 있습니다.
이들은 양방향으로 정보를 전달하기도 합니다. 전략은 팀이 현지의 선택을 내리는 데 도움이 되고, 팀이 마주하는 어려움은 전략이 불완전한 지점을 드러냅니다. 따라서 Navigator는 해석자이자 전략의 지속적인 개정에 중요한 기여자입니다.
아키텍처 병목 없는 조언
Cartek은 공식 아키텍트를 기술적 의사결정의 필수 관문으로 만드는 것을 의도적으로 피합니다. Staff engineer가 필요에 따라 아키텍처 업무를 수행할 수는 있지만, 조직은 의사결정 권한을 한곳에 집중하는 영구적인 역할을 원하지 않습니다.
대신 이 모델은 아키텍처 조언 프로세스에 가깝습니다. 엔지니어는 영향을 받는 사람들, 관련 경험이 있는 동료들, 문서화된 전략, 그리고 필요할 때 Navigator와 상담한 후 결정을 내릴 수 있습니다. 권한은 분산된 상태로 유지되지만, 상담은 기대됩니다.
전략은 집단적인 조언의 원천으로 기능합니다. 경험이 적은 엔지니어도 제안을 검토할 수 있는 기준을 제공합니다. 예를 들어, 조직이 성능과 확장성의 관계를 어떻게 평가하는지, 또는 유지보수 비용과 제공 속도 사이를 어떻게 저울질하는지 명확히 할 수 있습니다.
모든 질문을 보편적인 지침으로 축소할 수는 없습니다. Martell과 Fike는 어떤 기능이 기존 모놀리스에 속하는지, 아니면 새 서비스가 필요한지와 같은 선택을 언급합니다. 조직에 일반적인 방향은 있을 수 있지만, 모든 상황에 충분히 정밀한 규칙이 있는 것은 아닙니다. 그런 경우 전략은 모호함을 인정하고, 엔지니어가 충분한 정보를 바탕으로 상담하도록 안내해야 합니다.
이렇게 하면 판단력을 관료주의로 대체하지 않고 보존할 수 있습니다. 목표는 미래의 모든 답을 코드화하는 것이 아닙니다. 일상적인 선택을 더 쉽게 만들고, 정말 어려운 문제를 드러내며, 사람들이 예외를 일관된 방식으로 판단할 수 있게 하는 것입니다.
전략은 점진적으로 덜 틀려야 한다
Martell과 Fike는 전략을 완성된 교리가 아니라 진화하는 도구로 봅니다. 초기 원칙에는 빈틈이 있을 것입니다. 어떤 원칙은 지나치게 넓고, 다른 원칙은 작성자가 예상하지 못한 조건에서 실패할 수 있습니다.
실제 의사결정은 이를 개선하는 데 필요한 피드백을 제공합니다. 팀은 선택지를 전략과 비교하고, 지침이 도움이 되는 지점과 제대로 작동하지 않는 지점을 발견하며, Navigator를 통해 그 증거를 보고합니다. 시간이 지나면서 개별 결정과 공유 프레임워크 모두 점차 덜 틀리게 될 수 있습니다.
제한된 모호성을 허용하는 것도 설계의 일부입니다. 팀은 여전히 자신들의 시스템과 제약에 맞는 현지의 “마이크로 전략”을 개발할 여지가 필요합니다. Navigator는 모든 팀에 동일한 구현을 강요하지 않으면서, 이러한 현지 접근법이 조직의 더 큰 방향과 호환되도록 돕습니다.
Navigator들 간의 관계는 이러한 피드백 순환을 강화합니다. 이들이 모든 결정을 공동으로 소유하는 것은 아니지만, 문제가 여러 도메인에 걸칠 때 동료와 상담할 수 있습니다. 폭넓은 조직 인식과 깊이 있는 전문 지식의 조합은 보안, 신뢰성, 플랫폼 아키텍처, 제품 개발을 아우르는 문제에 특히 유용합니다.
탈중앙화는 멘토링 시스템이기도 하다
권한을 분산하는 일은 더 많은 사람이 그것을 행사하는 법을 배울 때에만 효과를 발휘한다. 따라서 Navigator 역할에는 트레이드오프를 파악하고, 적절한 조언을 구하며, 추론 과정을 기록하고, 불완전한 정보로 결정하는 방법을 가르쳐야 한다는 암묵적인 책임이 포함된다.
이는 이전에 영향력이 큰 선택을 맡아본 적이 없는 엔지니어에게 특히 중요하다. 중요한 제안이 나중에 접근하기 어려운 시니어 그룹에 의해 번번이 뒤집힌다면, 그들에게 “주도권을 가지라”고 말하는 것만으로는 충분하지 않다. Navigators는 의사결정 과정을 가시화하고, 결정을 실제 업무와 가까운 곳에 둔 채 기여자들을 지원할 수 있다.
Martell과 Fike는 Navigator 관점과 관리 관점도 구분한다. 관리자는 사람, 납품, 팀 실행 사이의 균형을 맞춰야 한다. Navigators는 깊이 있는 기술적 판단을 제공하고, 현지의 엔지니어링 선택을 조직 전체의 전략과 연결한다. 두 관점은 하나의 역할로 합쳐지기보다 서로를 보완해야 한다.
후보자는 기존 기여를 통해 인정받으며, 일반적인 지원 절차를 거치기보다 시니어 리더가 추천한다. 기술적 신뢰성만으로는 충분하지 않다. 다른 사람을 성장시키거나 판단을 공유하려 하지 않는 사람은 이 프로그램의 목적을 수행하기 어려울 것이다.
더 나은 의사결정을 통해 성공 측정하기
탈중앙화의 가치는 구체적인 의사결정 결과에서 드러난다. Martell과 Fike는 여러 도메인에서 나타나는 문제를 해결하기 위한 새로운 공용 플랫폼 서비스를 고려하던 팀을 설명한다. 겉으로는 타당해 보이는 대응은 범용 솔루션을 구축하고, 모든 이해관계자의 합의를 얻기 위한 긴 노력을 시작하는 것이었을 수 있다.
한 Navigator는 제안을 조직의 전략과 비교하고, 모든 경우에 적용되는 단일 플랫폼이 선호되는 방향이 아니라는 결론을 내렸다. 전략이 이미 합의된 기본값을 나타내고 있었기 때문에, Navigator는 전체 논거를 처음부터 다시 구축하지 않고도 문제를 해결할 수 있었다.
이는 입증 책임의 의미 있는 변화를 보여준다. 한 방향이 옳다고 지지자들이 다른 사람들을 반복해서 설득하는 대신, 문서화된 전략이 출발점이 된다. 다른 방향으로의 이탈은 여전히 가능하지만, 설득력 있는 설명이 필요하다.
진전을 보여주는 유용한 지표에는 더 빠른 의사결정, 불필요한 에스컬레이션 감소, 설계 문서에서의 더 명확한 추론, 기여자들의 더 큰 자신감이 포함된다. 정성적 신호도 중요하다. 엔지니어들은 덜 막막하다고 느껴야 하며, 반복되는 논쟁은 또 하나의 임시 타협안이 아니라 재사용 가능한 원칙을 점점 더 많이 만들어내야 한다.
엔지니어링 리더가 시작할 수 있는 방법
Martell과 Fike는 전략을 명확히 하기 전에 Navigators를 임명하는 방식은 효과가 없을 가능성이 크다고 분명히 말한다. 공유된 지도가 없다면, 신뢰받는 개인들은 단지 자신의 개인적 선호를 더 효율적으로 분산시킬 수 있다.
리더는 과거의 아키텍처 결정과 현재의 설계 문서를 검토하는 것부터 시작할 수 있다. 반복되는 트레이드오프를 파악하고, 가장 논쟁이 적은 원칙부터 기록하며, 표방하는 가치와 관찰되는 행동 사이의 간극을 살펴봐야 한다. 그러한 기록에 대한 불편함은 유용한 증거다. 이는 조직이 바꾸고자 할 수 있는 관행을 가리킨다.
실용적인 순서는 다음과 같다.
대표적인 결정과 그 추론을 문서화한다.
반복되는 패턴에서 조건부 원칙을 추출한다.
현재 관행이 원하는 방향과 충돌하는 영역을 파악한다.
이미 다른 사람에게 조언하고 있는, 존경받는 기술 기여자를 찾는다.
그들이 현지 업무를 조직 전략과 연결할 수 있는 위치에 배치한다.
실제 의사결정에서 누락이나 모순이 드러날 때 프레임워크를 수정한다.
더 깊은 교훈은 탈중앙화가 판단을 위한 인프라에 의존한다는 점이다. 문서화된 원칙은 일관성을 제공하고, Navigators는 맥락과 멘토링을 제공하며, 팀은 시스템이 현실에 기반을 두도록 유지하는 증거를 제공한다. 이러한 메커니즘이 함께 작동하면, 조직이 양립할 수 없는 기술적 방향으로 분열되지 않으면서 권한을 실제 업무에 더 가까이 이동시킬 수 있다.
