프로젝트 목표마다 명확한 소유자를 두고, 팀의 최종 의사결정과 신뢰·책임성의 원칙 아래 권한을 부여하는 방식으로 Rust의 로드맵 프로세스를 재활성화하자는 제안과 그 배경을 설명한다.
Rust에서 소유권은 중요한 개념이다 — 하지만 내가 말하는 것은 타입 시스템이 아니다. 나는 우리의 오픈 소스 프로젝트에서의 소유권을 말하고 있다. 최근 특히 Rust 커뮤니티에서 내가 보아온 큰 실패 양상 가운데 하나는 누가 의사결정할 권한을 갖는지 불분명하다는 느낌이다. 지난 6개월가량, 나는 Rust의 로드맵 프로세스를 다시 활성화하려는 시도로 프로젝트 목표 제안을 만들어 왔고 — 그 핵심은 각 목표에 소유자를 두는 생각이다. 이 글에서는 소유자가 된다는 아이디어 자체를 탐구해 보려 한다: 그것이 무엇을 의미하고, 무엇을 의미하지 않는지를.
내 제안에 따르면, 프로젝트는 최우선 목표들을 식별하고, 각 목표마다 지정된 소유자가 있게 된다. 바람직하게는 한 명의 구체적인 개인이지만, _소수의 그룹_일 수도 있다. 소유자는, 그렇다, 제안되는 설계를 소유하는 사람들이다. 마치 Rust에서처럼, 무언가를 소유하면 그것을 바꿀 권한이 있다.1
소유자가 설계를 소유한다고 해서 혼자 일한다는 뜻은 아니다. 좋은 러스타시안이라면 누구나 그렇듯, 그들은 이견을 소중히 여기며, 우려가 제기되면 소유자가 그것을 충분히 이해하고 완화하거나 해결하기 위해 최선을 다해야 한다. 하지만 항상 어느 순간에는 트레이드오프가 탁자 위에 모두 올라오고, 논의 공간이 충분히 지도화되며, 누군가가 무엇을 할지 결정을 내려야만 한다. 이 지점에서 소유자가 나선다. 프로젝트 목표 체계에서 소유자는 그 일을 하도록 우리가 선택한 사람이며, 진행을 유지하기 위해 결정을 내리는 일을 주저하지 않아야 한다.
소유자는 제안을 소유하지만, 그 제안을 받아들일지 여부를 결정하지는 않는다. 그것은 팀의 역할이다. 예를 들어 해당 목표가 언어에 변화를 요구한다면, 최종적으로 그 제안을 수락할지 결정하는 주체는 언어 설계 팀이다.
팀은 궁극적으로 소유자를 뒤집을 수 있다: 팀은 소유자에게 트레이드오프의 저울질을 다르게 한 수정안을 가져오라고 요청할 수 있다. 이것은 옳고 적절하다. 팀이야말로 자신들이 관리하는 도메인에 대해 가장 폭넓은 이해를 갖고 있는 존재로 우리가 인정하기 때문이다.2 하지만 팀은 그 권한을 신중하게 사용해야 한다. 특정 목표에 대해서는 대개 소유자가 트레이드오프를 가장 깊이 이해하고 있기 때문이다.
Rust의 일차적 목표는 권한 부여(empowerment) 이며 — 이는 언어 자체만큼이나 오픈 소스 조직에도 똑같이 해당된다. 우리의 목표는 사람들이 Rust를 개선할 수 있도록 권한을 부여하는 것이어야 한다. 이는 그들에게 제약 없는 변경 권한을 주는 것을 의미하지 않는다 — 그것은 개선이 아니라 혼란으로 이어질 것이다 — 그러나 그들의 비전이 Rust의 가치와 정렬되어 있다면, 그 비전을 실현하기 위한 능력과 지원을 보장해 주어야 한다.
소유권에는 흥미로운 긴장이 있다. 누군가에게 목표의 소유권을 부여하는 것은 일종의 신뢰 행위다 — 이는 우리가 그 사람이 뛰어난 판단력을 갖추었고 Rust와 그 가치를 이해하며 그에 따라 행동할 것이라고 여긴다는 뜻이다. 이것은 또한 소유자가 프로젝트에 알려진 사람이 아니라면 우리가 그 목표를 채택할 가능성이 낮다는 것을 의미한다. 반드시 Rust에 직접 참여해 본 사람일 필요는 없지만, 그들이 일을 잘 해낼지를 우리가 평가할 수 있을 정도의 평판은 갖추어야 한다.
프로젝트 목표 제안의 설계에는 신뢰를 높이도록 고안된 단계들이 포함되어 있다. 각 목표에는 예상되는 핵심 트레이드오프와 그것들을 어떻게 서로 저울질할지 밝히는 설계 공리(design axioms) 집합이 포함된다. 목표에는 또한 마일스톤이 명시되어, 저자가 작업을 점진적으로 나누고 접근하는 방법을 숙고했음을 보여 준다.
또한 프로젝트가 소유자를 신뢰해야 하는 것만큼 그 반대도 중요하다는 점을 강조할 가치가 있다: 프로젝트가 항상 자신의 약속을 잘 지켜 온 것은 아니다. 어떤 기능에 대한 제안을 요청해 놓고, 막상 제출되었을 때 응답하지 않은 적도 있다.3 혹은 무한 큐를 만들어 과도하게 쌓이게 함으로써 긴 지연을 초래하기도 했다.
프로젝트 목표 시스템에도 그러한 신뢰를 쌓기 위한 단계가 있다: 소유자는 팀으로부터 필요로 할 지원의 종류를 정확히 특정하고, 팀은 그것을 제공하겠다고 약속한다. 더 나아가 일반적인 기대는 어떤 프로젝트 목표든 중요한 우선순위를 나타낸다는 것이므로, 팀은 관련된 지명 이슈 등도 우선시해야 한다.
신뢰는 시간이 지나면서 유지되어야 한다. 프로젝트 목표 시스템에서 이를 위한 주요 메커니즘은 정기 보고다. 아이디어는 이렇다. 일단 목표를 식별하면, 추적 이슈를 만든다. 봇이 소유자에게 이 이슈에 대해 정기적으로 상태 업데이트를 제공하도록 알림을 보낸다. 그런 다음 주기적으로, 이 상태 업데이트를 모아 블로그 포스트로 게시한다. 이를 통해 진척이 없는 목표 — 최소한 상태 업데이트조차 제공되지 않은 목표 — 를 식별하고, 왜 그런지 들여다볼 수 있는 기회를 갖게 된다.
내 생각에, 우리가 모든 목표를 달성하지 못하는 것은 정상적이고 예상되는 일이다. 일이란 그런 것이다. 때로는 소유자가 다른 일로 바빠지기도 한다. 또 때로는 우선순위가 바뀌어, 한때는 목표였던 것이 더 이상 관련 없어 보이기도 한다. 괜찮다. 다만 그렇게 되었음을 분명히 인지하는 것이 중요하다. 문제는 사안을 어둠 속에 방치해 버리는 경우다. 그래서 무슨 일이 일어나고 있는지 정말로 알고 싶다면, github 코멘트, zulip 스레드, 이메일, 때로는 임의의 채팅과 회의록을 샅샅이 발굴하는 고고학적 탐사를 해야만 하는 상황이 된다.
Rust는 개방적이고 참여적인 언어라는 강한 가치를 지닌다. 이것은 좋은 일이며 Rust가 지금처럼 좋아질 수 있었던 핵심 요소다. Rust의 설계는 어느 한 사람의 것이 아니다. 이를 보장하는 핵심 방식은 합의에 의한 의사결정이다.
하지만 사람들은 때때로 합의가 모두의 동의를 뜻한다고 혼동한다. 이는 두 가지 차원에서 잘못이다:
? 연산자가 떠오른다). 이는 옳고 바람직하다. 팀은 가장 많은 맥락을 갖고 있으며, RFC 스레드에 참여하러 온 사람들 외에도 많은 경로로 의견을 받는다.현실은 Rust에서 이루어진 모든 좋은 일마다 누군가 소유자가 있었다는 것이다 — 일을 완수하도록 추진한 사람이었다. 하지만 우리는 그 소유자들을 명시적으로 지목하거나 구조 속에서 공식적인 자리를 부여한 적이 없다. 이제는 그것을 바로잡을 때라고 생각한다!