이 글은 2019년에 Scale 팀에 보냈던 메모로, 실제로 회사 내 많은 사람들의 일하는 방식을 크게 바꿔놓았습니다. Scale에 계시지 않은 분들께도 이 글이 마찬가지로 유익하게 다가가길 바랍니다.
조직이 커질수록 효율성이 떨어지는 이유로 흔히 “소통 비용”이 꼽힙니다. 팀 규모가 커지면 서로 소통하는 데 쓰는 시간이 기하급수적으로 늘어나고, 그만큼 효율도 떨어진다는 단순한 논리죠.
이 설명도 일리가 있지만, 저는 훨씬 더 본질적인 이유가 있다고 생각합니다. 바로 ‘정보 압축’이 엄청나게 어렵다는 점입니다.
안타깝게도, 우리 모두는 정보 압축을 잘하지 못합니다. 인간이라면 어쩔 수 없는 한계죠.
현실 세계는 정말 복잡합니다. 어떤 일이든, 실제로는 수많은 뉘앙스와 비합리적인 복잡성, 그리고 예측할 수 없는 우연성이 뒤섞여 있습니다. 즉, ‘실제로 무슨 일이 벌어지고 있는지’는 생각보다 훨씬 복잡하죠. 하지만 우리가 서로 소통할 때는, 대개 몇 마디 완결된 말로만 생각을 전달합니다. A라는 사람이 B에게 복잡한 아이디어를 설명해야 할 때, 어쩔 수 없이 많은 세부 사항을 생략하게 되고, 결과적으로 지나치게 단순화된 메시지가 전달됩니다. 이처럼 복잡한 시스템에 대한 머릿속 이미지를 인간이 이해할 수 있는 형태(주로 말이나 그림)로 바꾸는 과정이 바로 ‘정보 압축’입니다. 그리고 B가 이 메시지(‘압축본’)를 통해 이해하게 되는 것이 바로 ‘압축 해제된 이미지’입니다.
이처럼 본래 매우 복잡한 아이디어도 인간 언어라는 아주 좁은 창을 거쳐야 하고, 그 과정에서 대부분의 뉘앙스가 사라져버립니다.
이 과정은 거의 성공하지 못합니다. 결국 B가 머릿속에서 그려내는 ‘압축 해제된 이미지’는 실제로 무슨 일이 벌어지고 있는지와는 거리가 먼, 심각하게 왜곡된 모습이 되기 일쑤입니다. 이렇게 왜곡된 이미지를 바탕으로 B는 문제를 해결하려고 하지만, 실제 상황을 제대로 파악하지 못한 채 엉뚱한 방향으로 일을 하게 됩니다. 더 심각한 건, 본인은 문제를 해결하고 있다고 믿으면서도 실제로는 아무런 해결도 이루어지지 않는다는 점입니다.
이런 비효율성은 단순히 소통 비용이 늘어나는 것보다 훨씬 더 큰 비용을 초래합니다. 특히 규모가 큰 조직일수록 이런 현상이 두드러지게 나타나죠. 대부분의 사람들이 실제로는 아무런 의미 없는 일을 하고 있지만, 그 사실을 모르거나, 알면서도 어쩔 수 없이 계속 그렇게 일하고 있습니다.
결국, 아무도 진짜 사실을 온전히 전달하지 못하는 셈입니다. 대부분은 일부러가 아니라, 자연스럽게 중요한 부분이 빠지기 때문입니다.
이 과정이 성공적이라는 건 어떤 의미일까요? 사실 B가 ‘실제로 무슨 일이 벌어지고 있는지’를 완벽하게 이해하는 건 거의 불가능합니다. 하지만 가장 좋은 경우라면, B가 ‘가장 중요한 것’이 무엇인지 파악할 수 있습니다. 즉, 실제 상황을 바꿀 수 있는 핵심적인 요인(needle movers)을 알아내거나, 수학적으로 표현하자면 변화에 가장 큰 영향을 미치는 벡터(특징)를 이해하는 것이죠.
이처럼 신뢰할 수 있는 좋은 정보 압축이 이뤄지면, B는 실제 문제에 의미 있는 영향을 미칠 수 있기 때문에 그 가치가 매우 큽니다.
이 현상을 ‘고객’ 관점에서 바라볼 수도 있습니다. 여기서 말하는 ‘고객 문제’란, 넓은 의미에서 내가 도와주려는 누구든 될 수 있습니다. 고객이 자신의 문제를 압축해서 전달하는 방식은 곧 그들이 요청하는 바, 즉 요구사항입니다. 하지만 고객이 요청하는 것이 실제로 그들이 진짜로 원하는 것과 일치하는 경우는 거의 없습니다. 대부분의 경우, 우리가 최종적으로 만들어내는 결과물은 고객의 문제를 제대로 해결하지 못하고, 심지어 실제 고객 문제를 가장 단순하게 해결하는 방법에 비해 훨씬 더 많은 시간이 소요되곤 합니다.
이렇게 일이 잘못되는 사례는 우리 모두 수없이 봐왔고, 아마 지금 이 순간에도 Scale 안의 여러 곳에서 동시에 벌어지고 있을 겁니다. 문제를 해결하는 사람이 엄청난 호기심을 가지고 추가 질문을 던지며 더 나은 정보를 얻으려 노력하지 않는 한, 대부분의 경우 결과물은 항상 ‘엉뚱한 것’이 만들어지기 마련입니다.
여기서 ‘엉뚱한 것’이란, ‘얼마나 쉽게 만들 수 있는지’와 ‘얼마나 효과적으로 문제를 개선하는지’라는 효율성의 관점에서 최적점과는 한참 거리가 먼 결과물을 의미합니다.
겉으로는 잘 드러나지 않지만, 실제로는 엄청난 비용을 초래하는 숨은 비용 중 하나가 바로 복잡하기만 하고 문제는 제대로 해결하지 못하는 솔루션을 만드는 데 들어가는 비용입니다. 이런 상황이 가장 흔하게 발생하는 경우는, 비개발자가 개발자에게 어떤 일을 요청하면서 그 일이 쉬울 거라고 생각하지만, 실제로는 전혀 그렇지 않은 경우입니다.
그렇다면 이런 문제가 어디서 발생하는 걸까요? 이제 B의 머릿속, 즉 압축 해제 과정에서 무슨 일이 벌어지는지 살펴보겠습니다.
압축 해제 함수는 다음과 같은 신호들을 종합합니다:
- 압축본/메시지
- 공유 컨텍스트: A와 B가 과거 공유 경험을 통해 이해한 ‘진짜 상황’
- 사전 지식(Prior): B의 과거 경험과 철학이 정보 해석 방식을 형성하는 요소
이제 5명 미만의 스타트업이 효율적인 이유가 보입니다. 모든 구성원이 내부 업무와 고객 상호작용을 직접 목격하므로 공유 컨텍스트가 매우 강력합니다. 더욱 미묘한 점은 초기 멤버들은 사상과 경험이 유사해 사전 지식이 비슷하다는 사실입니다. 덕분에 복잡한 아이디어도 소량의 정보만으로 전달이 가능하죠.
반면, 부서 간 벽이 높은(사일로화된) 조직에서는 인계가 이뤄질 때 공유 컨텍스트가 거의 존재하지 않고, 서로 다른 팀원들 사이에 사전 지식도 잘 공유되지 않습니다. 이로 인해 저는 성장하는 조직에 대해 두 가지 중요한 법칙이 있다고 확신하게 되었습니다.
- 가능하다면 수직 통합(vertical integration)이 항상 더 낫습니다. 인계를 최소화해야 합니다.
(참고: 이것이 Scale이 엔지니어링 팀을 수직적으로 조직한 큰 이유 중 하나입니다. 제한된 컨텍스트에서 이뤄지는 인계의 비용이 눈에 띄지 않게 계속 쌓이고 있었거든요.) - 강한 조직 문화는 효율성을 위해 반드시 필요합니다. 그래야 사전 지식(prior)이 공유될 수 있습니다.
그렇다면 이 문제를 어떻게 해결할 수 있을까요? 가장 좋은 방법은 스스로 문제를 해결하는 것입니다. 인계를 피하세요. 문제를 깊이 이해하게 되면, 정보 병목 현상은 자연스럽게 사라집니다. 우리의 뇌는 문제의 잠재적인 복잡성을 모두 저장할 수 있고, 언어나 그림보다 훨씬 더 뛰어납니다.
실제로 문제의 고통을 직접 겪고, 깊이 이해하는 데 시간을 투자한다면, 부실한 정보 압축에 의존할 필요 없이 문제를 정면으로 해결할 수 있습니다.
이런 방식에는 여러 가지가 있습니다.
- 도그푸딩(dogfooding)은 정말 중요합니다. Scale의 모든 구성원은 반드시 데이터 라벨링과 모델 학습을 직접 경험해봐야 합니다.
- 고객 문제에 대한 호기심은 세일즈 과정에서 무엇보다 중요합니다. 고객은 결코 충분한 정보를 직접적으로 알려주지 않습니다. 모든 정보 압축은 본질적으로 불완전하기 때문이죠. 진짜 문제를 제대로 이해하려면, 스스로 이해의 빈틈을 적극적으로 메워야 합니다.
- 개발자는 다른 역할도 경험해봐야 하고, 그 반대도 마찬가지입니다.
- 세부적인 부분까지 깊이 파고드세요. 문제를 제대로 이해하려면, 많은 맥락을 쌓는 데 시간을 아끼지 마세요.
- 고객 출신 인재를 채용하는 것은 제품에 엄청난 도움이 될 수 있습니다. 이들은 어떻게 하면 더 잘할 수 있는지에 대한 풍부한 맥락을 함께 가져오기 때문입니다.
이런 정보 압축의 문제를 해결하는 방법은, 고객과 코드가 최대한 가까이 맞닿아 있는 끈끈한 팀을 만드는 것입니다. 최고의 결과는 항상 고객과의 소통과 실제로 만들어지는 코드가 긴밀하게 연결되어 있을 때 나옵니다. 가장 이상적인 경우에는 이 모든 역할을 한 사람이 맡기도 하고, 최소한 같은 공간에서 같은 사람들이 함께 일해야 합니다.
궁극적인 해법은 아예 정보 압축에 의존하지 않는 것입니다. 엔지니어, 영업, 지원, 마케팅, 운영 등 다양한 역할을 직접 경험하며, 모든 것이 어떻게 맞물려 돌아가는지 압축되지 않은 상태로 이해하세요. 제가 아는 모든 훌륭한 제품의 비결은 바로 여기에 있습니다.
blog by ash에서 더 알아보기
구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.
