대표가 모든 것을 결정하는 회사는 왜 SPOF인가

회사를 운영하다 보면 이런 말을 자주 듣습니다.

"대표님한테 물어봐야 합니다."

가격을 바꿔도 대표에게 물어봐야 하고, 고객 대응도 대표에게 물어봐야 하고, 사람을 뽑는 것도 대표에게 물어봐야 합니다.

심지어 몇십만 원짜리 물건 하나 사는 것까지 대표의 승인이 필요합니다.

겉으로는 대표가 회사를 아주 꼼꼼하게 관리하는 것처럼 보입니다. 하지만 IT 시스템을 오래 다뤄온 제 눈에는 조금 다르게 보입니다.

이 회사에는 SPOF가 하나 존재합니다.

바로 대표입니다.

SPOF란 무엇인가

IT 인프라에는 SPOF, Single Point of Failure라는 개념이 있습니다.

우리말로 하면 '단일 장애점'입니다.

쉽게 말해서,

이것 하나가 멈췄을 때 전체 시스템이 멈추는 지점

입니다.

예를 들어 서버가 한 대뿐인데 모든 서비스가 그 서버에서 돌아간다고 생각해보겠습니다.

서버 성능이 아무리 좋아도 그 서버가 고장 나는 순간 서비스 전체가 멈춥니다.

그래서 중요한 시스템은 서버를 여러 대 둡니다.

DB도 이중화하고, 네트워크도 이중화하고, 로드밸런서도 이중화합니다.

왜냐하면 우리는 이미 알고 있기 때문입니다.

"아무리 뛰어난 시스템이라도 하나에 모든 것을 의존하면 위험하다."

그런데 이상하게도 회사에서는 이 원칙을 자주 잊습니다.

회사의 모든 요청이 대표에게 몰리는 구조

회사 조직도를 시스템 아키텍처처럼 그려보겠습니다.

고객 → 직원 → 팀장 → 대표 구매 → 직원 → 대표 채용 → 팀장 → 대표 가격 결정 → 영업 → 대표 생산 문제 → 공장 → 대표 거래처 문제 → 담당자 → 대표

모든 화살표가 대표에게 향합니다.

IT 아키텍처라면 이런 구조를 보는 순간 바로 문제라고 판단할 겁니다.

대표가 사실상

API Gateway + Database + Business Logic + 승인 시스템 + 장애 대응센터

역할을 모두 하고 있기 때문입니다.

초기에는 이 구조가 잘 돌아갑니다.

직원이 3명이고 고객이 10명이라면 대표가 모든 것을 판단하는 것이 오히려 빠릅니다.

하지만 회사가 커지면 상황이 달라집니다.

직원 30명, 고객 100명, 거래처 50곳이 되면 대표의 처리 용량은 늘어나지 않았는데 요청만 계속 증가합니다.

서버로 말하면 CPU는 그대로인데 트래픽만 10배 증가한 상태입니다.

이때부터 대표가 병목이 된다

대표에게 하루에 의사결정이 10개 들어올 때는 문제가 없습니다.

하지만 50개, 100개가 들어오기 시작하면 대표는 모든 것을 즉시 처리할 수 없습니다.

그래서 대기열이 생깁니다.

직원은 말합니다.

"대표님 결재 기다리고 있습니다."

팀장은 말합니다.

"대표님 결정 나면 진행하겠습니다."

거래처는 말합니다.

"지난번 요청 어떻게 됐나요?"

문제는 직원들이 일을 안 해서 생긴 것이 아닙니다.

의사결정 시스템의 처리량보다 요청량이 많아졌기 때문입니다.

IT에서는 이것을 개인의 능력 문제로 보지 않습니다.

아키텍처 문제로 봅니다.

대표가 유능할수록 더 위험할 수도 있다

여기서 재미있는 역설이 하나 있습니다.

대표가 무능해서 SPOF가 되는 경우보다 오히려 대표가 너무 유능해서 SPOF가 되는 경우가 많습니다.

대표가 판단을 잘합니다.

고객도 잘 압니다.

기술도 압니다.

가격도 압니다.

사람도 압니다.

그러니 직원들은 자연스럽게 생각합니다.

"대표님한테 물어보는 게 가장 정확하다."

그 결과 조직의 학습은 멈춥니다.

직원은 판단하지 않고 질문합니다.

팀장은 결정하지 않고 보고합니다.

결국 대표에게 더 많은 정보가 모입니다.

그러면 대표는 다시 생각합니다.

"역시 내가 해야 제대로 된다."

이렇게 루프가 하나 만들어집니다.

대표가 잘한다 → 직원이 대표에게 의존한다 → 직원의 판단력이 성장하지 않는다 → 대표가 더 많이 결정한다.

이 구조가 몇 년 지속되면 정말 위험해집니다.

문제는 대표의 과로가 아니다

여기서 문제를 이렇게 정의하는 경우가 많습니다.

"대표가 너무 바쁘다."

하지만 이것은 결과입니다.

원인은 다릅니다.

의사결정 권한과 정보가 한 사람에게 집중되어 있는 구조가 문제입니다.

그래서 대표에게 비서를 붙인다고 해결되지 않습니다.

결재 시스템을 도입한다고 해결되지도 않습니다.

ERP를 구축한다고 해결되지도 않습니다.

잘못하면 종이 결재가 전자 결재로 바뀔 뿐입니다.

대표가 최종 승인해야 하는 구조는 그대로이기 때문입니다.

병목 서버 앞에 좋은 UI를 붙인다고 시스템 처리량이 늘어나는 것은 아닙니다.

더 큰 문제는 대표가 사라졌을 때 나타난다

대표가 하루 휴가를 갔습니다.

결정이 밀립니다.

대표가 일주일 해외출장을 갔습니다.

중요한 계약이 멈춥니다.

대표가 건강 문제로 한 달 자리를 비웠습니다.

회사 전체가 흔들리기 시작합니다.

이 상태라면 회사가 대표를 중심으로 돌아가는 것이 아니라,

대표가 회사 그 자체인 것입니다.

IT 시스템이라면 이런 서비스를 절대 안정적인 시스템이라고 부르지 않습니다.

아무리 평소 장애가 없어도 컴포넌트 하나가 장애 나는 순간 전체가 멈추기 때문입니다.

그렇다면 대표의 권한을 없애야 할까?

그것도 아닙니다.

이 문제를 해결한다고 모든 직원에게 모든 결정권을 나누는 것도 위험합니다.

분산 시스템에서도 모든 노드가 제멋대로 판단하면 데이터가 깨집니다.

조직도 마찬가지입니다.

중요한 것은 권한을 없애는 것이 아니라 권한의 경계를 설계하는 것입니다.

예를 들어 구매라면 이렇게 만들 수 있습니다.

50만 원 이하 → 담당자 300만 원 이하 → 팀장 1,000만 원 이하 → 본부장 그 이상 → 대표

가격 할인도 마찬가지입니다.

5% → 영업 담당자 10% → 영업팀장 20% → 대표

고객 장애도 심각도에 따라 나눌 수 있습니다.

일반 문의 → 담당자 서비스 영향 → 팀장 회사 전체 위험 → 대표

이렇게 하면 대부분의 요청이 조직 내부에서 처리되고 정말 중요한 것만 대표에게 올라옵니다.

좋은 조직은 API가 잘 정의된 시스템과 비슷하다

마이크로서비스에서 인터페이스는 특히 중요합니다.

A 서비스가 B 서비스의 내부 구현까지 매번 물어보면 시스템이 엉망이 됩니다.

그래서 API 계약을 정의합니다.

"이 요청을 보내면 이런 결과가 돌아온다."

회사도 비슷합니다.

직원이 매번 대표의 머릿속을 해석해야 한다면 조직에 API가 없는 것입니다.

대표의 판단 기준을 밖으로 꺼내야 합니다.

예를 들어,

"왜 이 거래는 승인하고 저 거래는 거절했을까?"

그 기준을 문서화합니다.

"어떤 고객은 외상을 허용하고 어떤 고객은 안 되는가?"

기준을 만듭니다.

"어떤 프로젝트는 진행하고 어떤 프로젝트는 포기하는가?"

원칙을 만듭니다.

대표의 머릿속에 있던 판단 로직이 조직의 규칙으로 바뀌기 시작합니다.

이것이 회사의 Business Logic을 개인의 머리에서 시스템으로 옮기는 과정입니다.

대표가 해야 할 일도 바뀐다

작은 회사의 대표는 직접 문제를 해결합니다.

하지만 조직이 커질수록 대표의 역할은 달라져야 합니다.

문제를 해결하는 사람이 아니라,

문제가 반복되지 않도록 시스템을 설계하는 사람이 되어야 합니다.

직원이 같은 질문을 세 번 한다면 직원만 탓할 일이 아닐 수 있습니다.

"왜 이 질문이 계속 나올까?"

를 봐야 합니다.

승인 요청이 계속 올라온다면

"왜 이 결정은 아직도 대표가 해야 하지?"

를 봐야 합니다.

사고가 반복된다면

"누가 실수했지?"

보다

"왜 이 실수를 막는 구조가 없지?"

를 먼저 봐야 합니다.

이 관점의 차이가 꽤 큽니다.

결국 대표의 능력은 '내가 얼마나 잘하느냐'에서 바뀐다

초기 창업자는 대부분 자신이 직접 뛰면서 회사를 만듭니다.

영업도 하고, 기술도 보고, 사람도 뽑고, 돈도 관리합니다.

그 단계에서는 그것이 맞습니다.

하지만 회사가 커진 뒤에도 같은 방식으로 운영하면 대표 자신이 회사 성장의 한계가 됩니다.

그래서 어느 순간부터 대표의 능력을 평가하는 기준도 달라져야 합니다.

"대표가 얼마나 많은 일을 처리할 수 있는가?"

가 아니라,

"대표가 없어도 얼마나 많은 일이 정상적으로 처리되는가?"

가 되어야 합니다.

좋은 시스템은 관리자가 계속 붙어 있어야 돌아가는 시스템이 아닙니다.

정상 상황에서는 스스로 돌아가고, 예외 상황에서만 관리자가 개입합니다.

좋은 회사도 비슷하다고 생각합니다.

대표가 없어도 돌아가는 회사

제가 생각하는 좋은 회사의 구조는 Kubernetes와도 조금 닮아 있습니다.

Pod 하나가 죽었다고 클러스터 관리자가 직접 서버에 접속해서 프로세스를 다시 실행하지 않습니다.

시스템이 스스로 복구합니다.

트래픽이 증가하면 확장합니다.

노드가 장애 나면 다른 곳으로 워크로드를 옮깁니다.

사람이 개입해야 하는 것은 시스템이 처리할 수 없는 예외 상황입니다.

회사도 그렇게 만들 수 있습니다.

일상적인 의사결정은 조직이 처리하고,

반복적인 문제는 프로세스가 처리하고,

정상적인 운영은 시스템이 처리하고,

대표는 정말 중요한 예외와 방향을 결정합니다.

그때부터 대표는 회사에서 가장 바쁜 사람이 아니라,

회사가 어디로 가야 하는지를 가장 많이 고민하는 사람이 됩니다.

결국 경영은 장애점을 제거하는 일일지도 모른다

IT 시스템을 설계할 때 좋은 아키텍트는 가장 먼저 묻습니다.

"여기 어디가 SPOF인가?"

서버인가?

네트워크인가?

DB인가?

스토리지인가?

저는 회사를 볼 때도 같은 질문을 던져볼 필요가 있다고 생각합니다.

"이 조직에서 저 사람이 없으면 멈추는 업무는 무엇인가?"

"저 팀장이 휴가를 가면 멈추는 프로세스는 무엇인가?"

그리고 가장 중요한 질문.

"내가 없으면 이 회사는 어디까지 멈추는가?"

만약 거의 모든 것이 멈춘다면 그것은 대표가 중요한 사람이라는 증거만은 아닙니다.

어쩌면 아직 회사의 아키텍처가 제대로 만들어지지 않았다는 신호일 수도 있습니다.

회사가 성장한다는 것은 직원 수가 늘어나는 것만이 아닙니다.

사람에게 의존하던 구조가 시스템에 의존하는 구조로 바뀌는 것.

저는 그것이 조직이 성장하는 과정이라고 생각합니다.

그리고 대표의 역할은 모든 결정을 내리는 사람이 아니라,

자신이 모든 결정을 내리지 않아도 되는 회사를 설계하는 사람

이어야 하지 않을까요.