일의 문법 — 업무는 어떻게 정의되고 결정되는가

효율적으로 굴러가는 조직에는 명확한 문법이 있습니다. 일의 단위가 정의되고(무엇이 일인가), 결정의 주인이 명시되며(누가 결정하는가), 기록이 맥락을 실어 나르고(왜 그렇게 결정했는가), 검증이 결과를 확인합니다(올바른 결정이었는가). 이 네 가지 요소가 갖춰진 조직에서만 자율은 언제든 회수 가능한 호의가 아니라 안전하게 보호받는 권리가 됩니다. 자율은 체계의 반대말이 아니라 체계의 산출물입니다.

일의 단위: 조직과 프로젝트를 분리한다

많은 조직에서 새로운 일을 시작할 때 팀이나 TF 같은 조직부터 만드는 관행이 있습니다. 이 관행의 비용은 시간이 지나 조직도에 쌓입니다. 일이 끝나도 조직은 남고(해산 절차는 생성보다 부실하기 마련이므로), 유령 팀과 만료된 TF가 트리를 채우며 조직도는 현실을 반영하지 못하게 됩니다. 프로젝트를 등록하고 관리할 별도의 시스템이 없어 조직도가 그 역할을 겸했기 때문에 일어나는 현상입니다.

문법의 첫 문장은 조직과 프로젝트의 분리입니다. 조직은 사람이 소속된 집(Line)이고, 일은 명확한 목표, 오너, 기한, 종료 조건이 있는 프로젝트(Task)로 선언해야 합니다. 임시 조직이 필요하다면 만료일(TTL)을 의무적으로 지정하고 만료 시 자동 해산되도록 설계해야 합니다. 이 분리가 이루어져야 새 프로젝트가 조직도를 오염시키지 않고, 조직도는 신뢰할 수 있는 인사 기록으로 남습니다.

결정의 문법: 주인과 문의 종류를 명시한다

결정이 느린 조직의 공통점은 의사결정 방식이 사안마다 매번 재협상된다는 점입니다. 이 결정은 만장일치인지, 리더의 직관인지, 실무자의 전결인지 모호합니다. 이 혼선을 해결하는 원칙은 두 가지입니다.

첫째, 모든 결정에 명명된 주인을 두는 것입니다. 넷플릭스의 Informed Captain, 아마존의 Single-threaded Owner, 토스의 DRI(Directly Responsible Individual)는 이름은 달라도 본질은 같습니다. “이 결정의 주인이 누구인가?”라는 질문에 즉시 한 사람의 이름이 나와야 합니다. 주인은 다양한 의견을 수렴하지만 끝없는 합의를 기다리지 않으며, 결정을 내리면 반대자도 헌신하여 실행(Disagree & Commit)합니다. 주인이 없는 결정은 회의를 떠돌다 가장 바쁜 상급자에게 몰려 조직 전체의 처리량을 떨어뜨립니다.

둘째, 문의 종류를 구분하는 것입니다. 제프 베조스의 one-way / two-way door 구분이 대표적입니다. 되돌릴 수 있는 결정(two-way)은 현장에서 신속히 전결하고 사후 공유하며, 되돌리기 어려운 중대한 결정(one-way)만 상위 결정권자의 검토를 거칩니다. 많은 조직이 지출 결재에는 정밀한 전결 규정을 두면서도 제품, 기술, 조직 결정에는 아무런 기준이 없는 경우가 많습니다. 문의 성격을 명시하는 것만으로도 결정 속도는 극적으로 빨라집니다.

기록의 문법: 맥락을 인프라로 만든다

결정의 주인을 정해도, 그 주인이 좋은 결정을 내리려면 충분한 맥락이 공급되어야 합니다. 소규모 조직에서는 맥락이 공기처럼 자연스럽게 흐르지만, 규모가 커지면 맥락은 인프라를 통해서만 유통됩니다.

아마존은 회의를 프레젠테이션 대신 6페이지 서술형 문서(6-pager)를 읽는 것으로 시작합니다. 문서가 맥락을 정확하게 실어 나르고, 회의 시간은 오직 판단과 토론에만 씁니다. 원격 조직 깃랩(GitLab)은 핸드북 퍼스트(Handbook-first)를 원칙으로 삼아 모든 프로세스와 결정을 문서화하여 단일 진실 원천으로 삼습니다. 회의는 정보 전달 장치가 아니라 결정 포럼이며, 정보는 기록을 통해 비동기로 흐릅니다.

기록의 최소 단위는 결정 로그(Decision Log)입니다. 무엇을, 누가, 왜 결정했는지, 무엇을 포기했고 어떤 지표로 언제 검증할지를 남기는 것입니다. 이 기록이 시스템에 축적될 때 “이거 왜 이렇게 정했나요?”라는 질문에 조직은 사람이 아닌 시스템으로 응답할 수 있습니다.

검증의 문법: 제도도 디버깅 대상이다

소프트웨어 엔지니어링에서는 코드에 대해 엄격한 테스트, 리뷰, 모니터링, 롤백 체계를 갖추면서도 정작 조직의 제도와 업무 규칙은 배포 후 방치되는 경우가 많습니다. 규칙이 실제로 문제를 해결했는지, 예상치 못한 부작용은 없는지, 유효기간이 끝났다면 폐기할 것인지 검증하지 않는다면 제도는 계속 누적되어 관료주의를 낳습니다.

제도의 검증 루프도 소프트웨어와 같아야 합니다. 도입 시점에 해결하고자 하는 문제와 목표 지표를 정의하고, 일정 기간 후 전후를 비교하며, 효과가 없을 시 폐기할 조건을 미리 명시해야 합니다. 이때 지표는 근태나 활동량 같은 입력이 아니라 리드타임이나 배포 빈도 같은 실질적인 출력이어야 지표의 왜곡과 감시 비용을 막을 수 있습니다.

일의 단위가 정의되고, 결정의 주인과 성격이 명시되며, 맥락이 기록으로 흐르고, 결과가 지속적으로 검증되는 조직에서 비로소 “알아서 하세요”라는 말이 방치가 아닌 진정한 위임이 됩니다. 명확한 경계와 시스템이 뒷받침될 때 자율은 조직의 가장 강력한 무기가 됩니다.