1인 운영자의 의사결정 속도에 대하여

결정이 빠르다는 말을 종종 듣습니다.

빠른 게 맞기는 합니다. 다만 빠른 결정과 정확한 결정 사이의 관계를 정확히 두고 일하지 않으면 그 빠름이 자기 함정이 됩니다. 처음에는 빠름을 미덕으로만 두었고, 그 결정들의 5할쯤이 일정 시간이 지난 뒤에 틀린 결정으로 판명나는 흐름을 한참 보고 나서야, 빠름의 의미를 다시 적어두기 시작했습니다.

지금의 정리는 이렇습니다. 1인 운영자의 빠름은 결정의 정확도를 높이는 도구가 아니라, 틀린 결정을 다음 결정으로 빠르게 정정할 수 있는 구조를 유지하는 비용입니다.

이 문장이 자기 변호처럼 읽힐 수 있어서, 한 단계 내려 적어둡니다.

큰 조직에서는 한 번의 결정에 여러 사람의 검토가 붙습니다. 검토가 붙는 만큼 시간이 가고, 그 사이에 정확도가 한 단계 올라갑니다. 1인 운영자는 같은 분기에 작은 결정 수백 개를 내립니다. 그 작은 결정 하나에 큰 조직 같은 검토를 붙이면 분기가 끝나기 전에 결정들이 줄을 서서 멈춥니다.

그래서 검토의 양을 줄이는 쪽이 아니라, 검토 없이 내린 결정의 일부가 틀려도 그것이 사이트 전체를 흔들지 않도록 결정의 단위를 작게 자르는 쪽에 무게가 갑니다. 사이트 하나의 작은 결정이 틀려도 다른 119 개의 사이트는 그대로 돌아갑니다. 결정의 단위와 결정의 영향 범위가 같이 줄어 있으니까 빠름이 작동할 자리가 생깁니다.

이 구조 안에서 빠르다는 게 어떻게 일하느냐.

새 기능을 사이트에 붙일지 말지를 두고 30 분 이상 고민하지 않습니다. 30 분 안에 결정이 안 나면 더 고민해도 결정이 안 난다고 가정합니다. 일단 한쪽으로 결정해서 붙이거나 안 붙이고, 그 결정이 작동하는지를 일주일 데이터로 봅니다. 일주일이 지나면 그 결정이 틀렸는지 맞았는지의 신호가 어느 정도 들어옵니다. 틀렸다는 신호면 다음 주에 정정합니다.

정정의 비용이 낮은 결정만 이 흐름으로 처리합니다.

정정 비용이 높은 결정은 다른 흐름으로 갑니다. 예를 들어 도메인 구조, 인프라 스택, 도구 선택 — 한 번 박으면 되돌리는 비용이 큰 결정들은 30 분이 아니라 며칠을 씁니다. 그 며칠 동안 사이트 한 개의 진행이 멈춰도, 그 결정이 portfolio 전체를 한 방향으로 묶기 때문에 그 멈춤이 정당화됩니다.

빠름과 느림의 두 흐름을 분리해두지 않으면, 모든 결정에 같은 속도가 적용됩니다. 정정 비용이 높은 결정을 30 분에 내리면 다음 6 개월이 그 결정을 안고 가게 되고, 정정 비용이 낮은 결정에 며칠을 쓰면 그 며칠이 다른 일을 못 하게 막습니다. 두 흐름을 매번 의식하는 게 1인 운영의 핵심 작업입니다.

이 정리를 적어두고 나서 한 번 더 의심해봅니다.

빠름이 정정 가능성에 기댄다는 건 정정이 실제로 일어난다는 전제가 깔립니다. 일주일이 지나면 데이터를 보고 정정한다는 흐름이 매번 지켜지는가. 솔직히 매번은 아닙니다. 어떤 사이트의 어떤 결정은 일주일이 지나도 안 들여다보고, 한 달이 지나서야 다른 작업 중에 우연히 발견됩니다.

빠름은 정정 구조와 같이 있어야 작동하는 도구이고, 그 도구를 잘 쓰는 사람과 그 도구만 들고 다니는 사람의 차이는 1년쯤 지나봐야 갈립니다.