나는 회사를 하나의 거대한 IT 시스템으로 본다

시스템을 설계하고 구축하고 운영하는 일을 오래 하다 보니 어느 순간부터 회사에서 터지는 문제와 시스템에서 터지는 문제가 놀랄 만큼 겹쳐 보이기 시작했습니다. 직업병이라고 하면 할 말은 없습니다.

직원이 서버라는 얘기도 아니고, 회사를 컴퓨터처럼 굴리자는 얘기도 아닙니다.

서버 한 대에 모든 기능을 몰아넣으면 장애에 취약합니다. 개발자 한 명만 그 시스템을 알고 있어도 위험합니다. 서비스 사이의 연결 규칙이 없으면 금방 복잡해집니다. 모니터링이 없으면 장애가 난 다음에야 문제를 압니다. 트래픽이 늘었는데 서버를 못 늘리면 멈춥니다.

회사도 거의 똑같습니다.

대표 한 명이 모든 것을 결정합니다. 특정 직원만 그 업무를 처리합니다. 부서 사이에 일을 주고받는 기준이 없습니다. 매출이 떨어진 뒤에야 문제가 있었다는 것을 발견합니다. 사업은 커졌는데 사람과 프로세스는 예전 그대로입니다.

IT에서 이런 시스템을 보면 대개 문제가 있다고 말합니다. 그런데 회사에서는 같은 모습을 너무 쉽게 받아들이더라고요.

대표가 모든 것을 잘하는 회사는 좋은 회사일까

작은 회사에서 흔한 장면이 있습니다.

견적도 대표에게 물어봅니다. 계약도 대표가 확인합니다. 구매도 대표가 결정합니다. 고객 문제가 생겨도 대표에게 전화가 갑니다. 채용도 대표가 보고, 돈 나가는 것도 대표가 확인합니다.

처음에는 이 구조가 빠릅니다. 대표가 가장 많이 알고 있으니까요.

회사가 커지기 시작하면 얘기가 달라집니다.

아키텍처를 그려본 사람이라면 이 구조에서 바로 떠올리는 단어가 있습니다.

SPOF, Single Point of Failure.

한 지점이 멈추면 전체가 영향을 받는 구조입니다.

대표가 휴가를 가면 의사결정이 멈추고, 대표가 아프면 계약이 밀리고, 대표가 바쁘면 직원들이 결정을 기다립니다.

겉으로는 대표가 유능한 회사입니다. 시스템 관점에서는 위험한 회사입니다.

대표가 회사를 움직이는 것인지, 회사가 대표라는 서버 한 대에 얹혀 있는 것인지는 구분해야 하는 문제라고 봅니다.

저도 이걸 남 얘기로 못 합니다. 예전에 맡았던 플랫폼에서 릴리즈 승인 권한을 한동안 저 혼자 쥐고 있었습니다. 휴가 중에 새벽 2시에 전화를 받고 노트북을 연 적도 있습니다. 그때는 그게 책임감이라고 생각했습니다. 지금 보면 그냥 병목이었습니다. 승인 기준을 문서로 내려놓는 데 반년이 더 걸렸고, 진작 했어야 하는 일이었습니다.

직원이 계속 실수한다면 정말 그 직원의 문제일까

같은 장애가 세 번 반복됐다고 해보겠습니다.

그때마다 담당 개발자를 불러서 “다음부터 조심하세요”라고 말하고 끝낸다면, 그걸 좋은 운영이라고 부르기는 어렵습니다.

엔지니어들은 보통 그렇게 안 합니다. 왜 났는지 찾습니다. 로그를 보고, 프로세스를 추적하고, 재현 조건을 잡습니다.

그리고 묻습니다.

“이 장애가 다시 안 나게 하려면 뭘 바꿔야 하지?”

필요하면 Validation을 넣습니다. 자동화합니다. 모니터링을 붙입니다. 권한을 줄입니다. 프로세스를 바꿉니다.

회사에서는 이상하게 다른 쪽으로 갑니다.

“김 대리가 또 실수했어.” “요즘 직원들은 책임감이 없어.”

개인의 역량이나 태도가 원인인 경우도 물론 있습니다. 사람 문제까지 전부 시스템 탓으로 미는 것도 게으른 진단입니다. 다만 같은 종류의 실수가 여러 사람에게서 반복된다면 질문을 바꿔볼 필요가 있습니다.

“왜 김 대리는 실수했을까”에서 “왜 우리 회사는 김 대리가 실수할 수 있는 구조로 되어 있을까”로 말입니다.

질문 하나 바꿨을 뿐인데 문제를 보는 위치가 통째로 달라집니다.

부서와 부서 사이에도 API가 필요합니다

마이크로서비스를 설계할 때 가장 오래 붙잡는 것 중 하나가 인터페이스입니다.

A 서비스가 B 서비스에 무엇을 요청하는지, 어떤 데이터를 넘기는지, 정상 응답은 무엇인지, 실패하면 어떻게 처리하는지를 정합니다.

API입니다.

회사도 같습니다.

영업팀이 생산팀에 주문을 넘깁니다. 생산팀이 구매팀에 자재를 요청합니다. 구매팀이 회계팀에 지급을 요청합니다. 현장에서 문제가 생기면 품질팀과 영업팀으로 정보가 흘러갑니다.

전부 인터페이스입니다.

문제는 이 API가 문서로 남아 있지 않다는 것입니다.

그래서 사람이 API가 됩니다.

“그거 박 과장님한테 물어보세요.” “이건 원래 이 대리가 처리해요.” “예전부터 이렇게 했어요.”

IT식으로 옮기면 꽤 무서운 구조입니다. 문서화되지 않은 비공식 API가 사람 머릿속에만 떠 있는 셈입니다. 그 사람이 퇴사하는 순간 API도 같이 사라집니다.

숫자가 많다고 Observability가 좋은 건 아닙니다

회사에는 이미 숫자가 많습니다.

매출. 영업이익. 재고. 원가. 수주액. 불량률. 생산량.

그래서 데이터로 굴러가는 회사라고 생각하기 쉽습니다.

운영에서는 데이터가 많다고 Observability가 좋다고 말하지 않습니다. 시스템 안에서 지금 무슨 일이 벌어지는지 설명이 되느냐가 기준입니다.

매출이 20% 떨어졌다는 것은 결과입니다

진짜 보고 싶은 건 그 앞입니다.

견적 요청이 줄었는지. 견적은 그대로인데 계약 전환율이 떨어졌는지. 생산 리드타임이 늘었는지. 원자재 가격이 올랐는지. 특정 고객군의 주문이 빠졌는지.

CPU가 100%가 된 다음에 장애를 발견하는 것보다 70%, 80%, 90%로 올라가는 과정에서 이상 징후를 잡는 쪽이 좋은 운영입니다.

경영 숫자도 사후 보고서가 아니라 회사라는 시스템에 꽂아둔 센서여야 한다고 봅니다.

제조업에서는 이게 더 선명하게 보입니다

오래 돌아간 공장에는 노하우가 두껍게 쌓여 있습니다. 그 상당수가 시스템이 아니라 사람에게 저장되어 있다는 게 문제입니다.

“이 기계는 소리가 이 정도 나면 한번 봐야 해.” “이 업체는 전화부터 해야 빨리 줘.” “이 도면은 그대로 만들면 안 되고 여기 2mm 정도 조정해야 해.”

가치 있는 지식입니다. 동시에 위험합니다.

IT로 치면 중요한 Business Logic이 소스코드가 아니라 개발자 머릿속에만 들어 있는 상태와 같습니다.

그래서 제조업 디지털 전환이 태블릿 지급하고 MES 깔고 끝나면 안 된다고 생각합니다. 먼저 할 일은 사람에게 숨어 있는 Business Logic을 찾아내는 것입니다. 그다음 데이터와 프로세스로 옮깁니다.

저는 이걸 제조업의 Legacy Refactoring이라고 부릅니다.

그렇다고 회사를 Kubernetes처럼 만들자는 얘기는 아닙니다

여기에 함정이 하나 있습니다.

시스템과 회사는 같지 않습니다.

서버는 감정이 없지만 사람에게는 감정이 있습니다. Pod는 지우고 다시 띄우면 되지만 직원을 그렇게 다루지는 못합니다. 컴퓨터는 명령을 정확히 수행하고, 사람은 의미와 동기와 관계에 흔들립니다.

IT 논리를 사람에게 그대로 얹으면 꽤 끔찍한 조직이 나옵니다. 그런 조직도 몇 번 봤습니다.

제가 하고 싶은 말은 사람을 기계처럼 관리하자는 게 아닙니다. 반대입니다.

사람이 기계처럼 반복해야 하는 일을 시스템이 가져가자는 쪽입니다. 판단과 협상, 창의성과 관계처럼 사람이 잘하는 일은 사람에게 남기고 반복적인 확인과 전달, 계산과 기록은 시스템으로 넘깁니다.

그래야 사람이 사람 몫의 일을 합니다.

그리고 AI가 들어왔습니다

최근에 변수가 하나 더 생겼습니다.

AI입니다.

예전 경영자는 자기가 약한 분야를 메우려면 사람을 뽑거나 외부 전문가를 불러야 했습니다. 지금도 전문가의 역할은 그대로 중요합니다. 다만 경영자가 문제를 탐색하는 비용은 확실히 내려갔습니다.

기술은 강한데 회계가 약한 사람이라면 회계 관점에서 자기 판단을 검토받습니다. 마케팅이 약하면 고객 관점에서 사업계획을 공격해보게 합니다. 계약서를 읽다 막힌 부분을 구조화하고, 사업 시나리오를 몇 개 만들어 비교합니다.

AI가 CEO가 되지는 않습니다.

저는 이렇게 보는 쪽이 맞다고 생각합니다. AI는 경영자의 비어 있는 모듈을 채우는 Copilot입니다.

앞으로 경영자의 경쟁력은 모든 것을 알고 있는 상태에서 조금씩 옮겨갈 것 같습니다. 문제를 발견하고, 구조화하고, 분해하고, 필요한 정보를 얻고, 틀린 정보를 걸러내고, 마지막 결정을 내리는 능력. 지식의 양보다 아키텍처를 보는 눈 쪽입니다.

좋은 경영자는 가장 바쁜 사람이 아닐지도 모릅니다

제가 생각하는 좋은 시스템은 이렇습니다. 특정 서버가 없어도 돌아갑니다. 장애가 나면 빠르게 감지합니다. 트래픽이 늘면 확장됩니다. 서비스 사이 인터페이스가 명확합니다. 운영 상태가 밖에서 보입니다. 장애가 반복되면 사람을 탓하기 전에 구조를 고칩니다. 반복 작업은 되도록 자동화합니다.

좋은 회사도 비슷하지 않을까 싶습니다.

대표가 잠시 없어도 돌아가고, 직원이 바뀌어도 업무가 이어지고, 문제가 커지기 전에 발견되고, 사업이 자라면 조직도 같이 늘어나고, 부서 사이 책임과 인터페이스가 분명하고, 같은 실수가 반복되면 프로세스가 바뀌는 회사.

저는 경영을 사람 관리하는 일로만 보지 않습니다. 경영자는 회사라는 시스템의 Architect 쪽에 더 가깝지 않나 생각합니다.

좋은 아키텍트의 목표는 모든 요청을 자기가 처리하는 게 아닙니다. 자기가 직접 붙지 않아도 시스템이 안정적으로 돌아가도록 설계하는 것입니다.

회사를 볼 때도 저는 같은 질문을 던져보려고 합니다.

“이 회사는 지금 좋은 시스템으로 설계되어 있는가?”

이 질문에서 《회사를 시스템처럼 경영한다》를 시작해보려 합니다.

다음 편은 대표가 모든 것을 결정하는 회사가 왜 SPOF가 되는가입니다. 답을 다 정해놓고 쓰는 건 아닙니다.