배분하지 않았습니다

보통은 이렇게 합니다. 과제 목록을 만들고, 담당자를 지정하고, 일정을 넣고, 주기적으로 점검합니다. 저도 오래 그렇게 해왔습니다.

이번에는 안 했습니다.

IT팀은 일곱 명입니다. 팀장 한 명과 팀원 여섯 명이 정보기획, ERP, PLM, MES, CRM, AI, 보안, 인프라를 나눠 맡고 있습니다. 이 인원에게 과제를 나눠주지 않고 이렇게만 말했습니다.

각자 가장 답답했던 일을 하나 고르십시오.

왜 배분하지 않았는가

앞선 글들에서 반복해서 부딪친 원칙이 있습니다. 데이터를 입력하는 사람과 그 이득을 보는 사람이 같아야 시스템이 정착한다는 것입니다. 어긋나면 규정으로 강제해도 형식만 채워집니다.

과제도 같습니다. 위에서 배분한 과제는 받는 사람 입장에서 남의 일입니다. 하기는 하지만 일정에 맞춰 보고할 수 있을 만큼만 합니다. 그리고 만들어놓고 본인도 안 씁니다.

반대로 자기가 매일 겪는 불편을 고르면 만드는 이유가 자기 안에 있습니다. 중간에 막혀도 붙들고 있습니다. 다 만들면 본인이 제일 먼저 씁니다.

도구 값이 싸졌기 때문에 이 선택이 가능해졌습니다. 예전에는 개발 자원이 귀해서 우선순위를 정해 배분하는 것이 유일한 방법이었습니다. 지금은 각자 만들 수 있으니 굳이 줄을 세울 필요가 없습니다.

각자 고른 것

결과가 흥미로웠습니다.

• 보안 담당자 — 방화벽 로그 분석
• 인프라 담당자 — 자산관리 시스템
• CRM 담당자 — 고객 요구사항 포털
• AI 담당자 — 데이터 관리 포털
• 혁신 담당자 — 프로세스 관리 포털
• ERP 담당자 — Agent 관리 포털
• PLM 담당자 — KPI 주별 리포트, 교육자료 포털

팀장이 만든 두 건을 합쳐 프로젝트가 열 건이 되었습니다.

목록을 보고 두 가지가 눈에 들어왔습니다.

아무도 남의 영역을 고르지 않았습니다. 각자 자기가 매일 만지는 것에서 골랐습니다. 당연해 보이지만 배분했다면 이렇게 되지 않습니다. 배분하는 사람은 전체를 보고 나누기 때문에 담당자의 체감과 어긋나는 경우가 생깁니다.

아무도 "회사에 좋은 것"을 고르지 않았습니다. 다 자기가 불편한 것을 골랐습니다. 그런데 목록을 놓고 보면 회사에 필요한 것들입니다. 매일 그 일을 하는 사람이 느끼는 불편은 대개 실제 문제와 겹쳐 있습니다.

진행 상태는 고르지 않습니다

정직하게 쓰면 이렇습니다. 열 건의 상태가 제각각입니다.

• 가동 중 — 3건
• 개발 완료, 검증 중 — 2건
• 부분 가동 — 2건
• 개발 중 — 1건
• 착수 단계 — 2건

보기 좋은 그림은 아닙니다. 그런데 이 불균형이 배분하지 않았다는 증거이기도 합니다.

배분하고 일정을 넣었다면 상태가 더 고르게 보였을 것입니다. 다들 일정에 맞춰 보고할 수 있는 수준까지는 맞췄을 테니까요. 그리고 그렇게 맞춰진 것 중 실제로 쓰이는 것은 몇 개 안 됐을 것입니다.

지금은 반대입니다. 진도는 들쭉날쭉한데 가동에 들어간 것들은 실제로 쓰입니다. 만든 사람이 매일 쓰기 때문입니다.

이 방식이 항상 되는 것은 아닙니다

이 이야기를 "배분하지 말고 자율에 맡기면 된다"로 읽으면 안 됩니다. 몇 가지 조건이 갖춰져야 작동합니다.

그 일을 오래 한 사람이어야 합니다. 답답한 것을 고르라고 했을 때 답이 나오려면, 그 업무를 충분히 해봐서 어디가 아픈지 알아야 합니다. 온 지 얼마 안 된 사람에게는 이 질문이 어렵습니다.

안 해도 불이익이 없어야 합니다. 이것이 어렵습니다. 자율이라고 하면서 안 한 사람을 평가에서 불리하게 하면 배분과 다를 것이 없습니다. 그러면 사람들은 만들기 쉬운 것을 골라서 형식만 채웁니다.

만들 수 있는 환경이 있어야 합니다. 도구 라이선스와 최소한의 교육입니다. 저희는 하루짜리 교육이 출발점이었습니다.

그리고 이 방식에는 분명한 약점이 있습니다. 회사 전체에 중요한데 아무도 답답해하지 않는 일은 아무도 고르지 않습니다. 부서 사이에 끼인 일, 담당자가 애매한 일, 지금은 문제가 안 되지만 나중에 터질 일이 그렇습니다. 이런 것은 결국 따로 정해서 맡겨야 합니다. 자율이 배분을 대체하는 것이 아니라 나눠 갖는 것입니다.

다음 문제는 이미 보입니다

열 건이 각자 만들어지고 있다는 것은 다른 관점에서 보면 열 개가 각자 흩어져 있다는 뜻입니다.

만든 사람만 그 안을 압니다. 코드 스타일도 다르고, 데이터를 어디에 두는지도 다릅니다. 만든 사람이 다른 일을 맡거나 부서를 옮기면 그 도구는 방치됩니다.

이것을 속인화라고 부릅니다. 그리고 이 문제는 자율의 부작용이 아니라 자율의 필연적 결과입니다. 각자 만들게 했으니 각자 것이 됩니다.

그래서 지금 표준을 만들고 있습니다. 코드와 보안 규칙, 리뷰 절차, 공용 저장소, 그리고 무엇이 만들어졌는지 등록하는 자리입니다. 만드는 속도와 통제하는 체계를 다른 층으로 나눠서 관리하는 것입니다.

이 순서가 뒤집히면 안 됩니다. 먼저 통제 체계를 완성하고 시작하려 하면 아무것도 시작되지 않습니다. 반대로 통제 없이 계속 늘리면 나중에 정리하는 것 자체가 프로젝트가 됩니다. 만들면서 함께 만드는 수밖에 없습니다.

다음 글에서는 실제로 무엇을 알아야 이렇게 만들 수 있는지, 바이브 코딩의 핵심 개념을 정리해보겠습니다.