AI 시대의 회사는 먼저 읽힐 수 있어야 한다

AI가 고객 문의를 분류하는 일과, 그 문의가 해결될 때까지 필요한 판단과 이관을 이어 가는 일은 다릅니다. 후자를 하려면 어디서 일이 시작되고, 어떤 기준을 통과해야 다음 단계로 가며, 누가 예외를 승인하고, 언제 끝났다고 볼지 알아야 합니다. 이런 기준이 사람 머릿속이나 메신저에만 있다면 AI는 분리된 한 단계의 작업에 머물 수밖에 없습니다.

AI 시대에 회사가 지속적으로 발전하려면, 먼저 회사 자체가 Machine-readable해야 합니다. 그래야 RTB는 현재 사업을 데이터로 최적화하고, CTB는 전략적 기회를 빠르게 가설화·검증해 사업으로 전환할 수 있습니다.

회사가 Machine-readable하다는 것

Machine-readable Company는 문서가 많거나 데이터레이크를 갖춘 회사와 다릅니다. 업무, 목표, 의사결정, 책임, 기준, 데이터, 결과가 어떤 관계로 이어지는지 시스템이 해석할 수 있는 회사입니다. 사람에게 물어봐야만 “왜 이 일이 생겼고, 지금 어디서 막혔으며, 어떤 결정으로 여기까지 왔는가?”를 알 수 있다면 아직 읽을 수 있는 상태가 아닙니다.

그 중심이 Work Blueprint입니다. 단순한 Process Map이나 Workflow라면 업무의 순서에서 끝나기 쉽습니다. Work Blueprint는 다음을 하나의 실행 구조로 연결해야 합니다.

왜 하는가 → 무엇을 하는가 → 어떤 순서로 하는가 → 무엇을 입력받고 출력하는가 → 어떤 Gate를 통과해야 하는가 → 누가 결정하고 책임지는가 → 어떤 시스템과 데이터를 쓰는가

조직도를 먼저 그리고 일을 끼워 넣기보다 Value Flow를 먼저 정의하고 조직을 그 흐름에 매핑하는 이유도 여기에 있습니다. 각 단계에 IN / OUT / GATE / ACCOUNTABLE을 붙이면 일이 넘어가는 조건과 결과에 대한 책임이 드러납니다. 여기에 목표와 지표, 결정 기록이 연결돼야 Work Blueprint가 업무 설명서를 넘어 회사의 실행 모델이 됩니다.

데이터도 이 구조와 떨어져 있으면 소용이 없습니다. Data Foundation은 실제 업무에서 발생한 사실의 출처·품질·이력을 관리합니다. 데이터레이크가 이 기반의 일부가 될 수 있지만, 사실을 모으는 것만으로 그 의미까지 정해지지는 않습니다.

Ontology & SSOT는 공통 의미와 판단 근거를 만듭니다. Ontology는 고객, 계약, 서비스, 문의 같은 업무 개념과 그 관계를 연결합니다. SSOT는 그중 어떤 정의와 데이터를 판단의 기준으로 삼을지 정하고 관리합니다. 예를 들어 ‘고객’이 CRM에 등록된 사람인지, 계약을 체결한 사람인지, 실제 서비스를 이용하는 사람인지 부서마다 다르면 같은 데이터로도 서로 다른 수치가 나옵니다. 이 정의를 통일하고 어떤 기록을 기준으로 집계할지 정해야 사람과 AI가 같은 사실을 같은 뜻으로 읽습니다.

이 기반이 있어야 RTB의 SLI를 일관되게 측정하고, CTB의 Experiment에서 무엇을 성공의 Evidence로 볼지도 합의할 수 있습니다. Work Blueprint가 일의 구조를, Data Foundation이 사실을, Ontology & SSOT가 그 사실의 의미와 판단 근거를 연결합니다. 같은 데이터보다 같은 의미가 먼저입니다에서 이 문제를 더 다뤘습니다.

Machine-readable은 AI가 모든 결정을 스스로 내린다는 뜻이 아닙니다. 사람과 AI가 같은 업무 구조와 판단 근거를 읽고, 각자의 권한 안에서 일할 수 있는 상태를 뜻합니다.

RTB: 현재 사업을 계속 최적화한다

RTB(Run the Business)는 지금의 사업 모델과 운영체계를 안정적이고 효율적으로 운영하는 일입니다. 묻는 것은 “지금 하는 일을 어떻게 더 잘할 것인가?”입니다.

SLI → SLO → Gap → ROI → Improve → Verify

이 순서는 용어의 나열이 아니라 운영 문제를 다루는 순서입니다. 예를 들어 고객 문의 처리 시간이 길다는 문제를 보겠습니다.

• SLI(Service Level Indicator)는 현재 상태를 관측할 지표입니다. 이 사례에서는 문의 처리 리드타임을 잡고, 실제로 평균 8일이 걸리는지 측정합니다.
• SLO(Service Level Objective)는 합의한 목표 수준입니다. 고객과 운영에 필요한 수준이 3일이라면, 그 수치를 목표로 둡니다.
• Gap은 현재 값과 목표의 차이입니다. 여기서는 5일입니다. 차이를 확인한 뒤에는 어디에서 대기와 재작업이 생기는지 원인을 찾습니다.
• ROI는 그 Gap을 줄이는 데 자원을 쓸 가치가 있는지 판단하는 기준입니다. 처리 시간을 단축했을 때의 고객·비용 효과를 개선 비용, Risk, Effort와 비교합니다.

그다음 Improve에서 인수인계나 승인 단계를 고치고, Verify에서 같은 SLI로 결과를 확인합니다. 장애율을 0.3%에서 0.05%로 낮추려는 경우도 같은 방식으로 현재·목표·Gap을 분명히 할 수 있습니다. 다만 모든 Gap을 없애는 것이 목적은 아닙니다. 가장 가치 있는 Gap부터 고르는 Gap-driven Optimization이 RTB의 핵심입니다.

이때 지표는 사람을 평가하기 위한 점수가 아닙니다. 리드타임, 핸드오프, 재작업처럼 운영체계가 어디서 막히는지 알려주는 튜닝 데이터여야 합니다. 그래야 개선 뒤에 실제로 무엇이 달라졌는지도 검증할 수 있습니다.

RTB에서 관측한 문제는 CTB의 출발점이 되기도 합니다. 상담 시간을 줄여도 문의량 자체가 계속 늘어난다면, 현재 절차의 개선만으로 해결할 수 있는지 다시 묻게 됩니다. 이때 전혀 다른 운영 방식을 가설로 세울 수 있습니다.

CTB: 전략적 기회를 사업으로 바꾼다

CTB(Change the Business)는 RTB와 출발하는 질문이 다릅니다. “지금과 다른 방식이 더 큰 가치를 만들 수 있는가?”를 묻습니다. 현재 운영의 목표치를 정하고 그 차이를 줄이는 일만으로는 답할 수 없습니다.

Strategic Opportunity → Hypothesis → Experiment / Initiative → Evidence → ROI / Expected Value → Scale / Stop / Pivot

앞의 고객센터 사례를 이어 보겠습니다. RTB라면 상담 절차를 개선해 상담 시간을 10% 줄이는 방안을 검토할 수 있습니다. CTB에서는 AI가 반복 문의를 맡는 새로운 운영 방식의 가능성을 다음 순서로 확인합니다.

• 전략적 기회(Strategic Opportunity): 반복 문의를 AI가 해결하고 상담사는 복잡한 문제에 집중할 수 있다면, 비용과 고객 경험에 어떤 가치를 만들 수 있는지 살펴봅니다.
• 가설(Hypothesis): “AICC가 반복 문의의 70%를 해결하면서도 CS 품질을 유지할 수 있는가?”처럼 검증할 수 있는 질문으로 바꿉니다. 70%는 달성한 성과가 아니라 실험으로 확인할 목표치입니다.
• 실험 / 변화 과제(Experiment / Initiative): 대상 문의와 성공 기준을 정해 작은 범위에서 실험합니다. 여러 업무나 시스템을 함께 바꿔야 한다면 목표·책임자·자원을 갖춘 변화 과제로 추진합니다.
• 검증 근거(Evidence): 실험에서 처리율, 재문의, 고객 만족도, 예외 처리 비용을 수집합니다. 가설이 어떤 조건에서 성립하고 어디에서 실패하는지 확인할 근거입니다.
• 투자 대비 효과 / 기대 가치(ROI / Expected Value): 확인한 효과를 구축·운영 비용과 비교하고, 적용 범위를 넓혔을 때의 가치도 추정합니다. 이때 성공 가능성과 아직 검증하지 못한 조건을 함께 고려합니다.
• 확대 / 중단 / 방향 전환(Scale / Stop / Pivot): 근거가 충분하면 적용 범위를 넓히고, 기대한 가치가 없으면 중단하며, 다른 가능성이 보이면 가설이나 접근 방식을 바꿉니다. 확대하기로 한 방식은 다음 단계에서 Work Blueprint에 반영해 일상 운영으로 연결합니다.

CTB는 기존 업무를 조금 더 빠르게 만드는 프로젝트가 아닙니다. Opportunity를 Hypothesis로 바꾸고, 실험으로 검증해 새로운 운영 방식이나 사업으로 전환할지 결정하는 Hypothesis-driven Transformation입니다.

검증된 CTB는 새로운 RTB가 된다

RTB와 CTB는 두 개의 독립된 체계가 아닙니다. 성공한 CTB가 일상 운영에 편입되면 그것이 새로운 RTB가 됩니다.

사람이 장애를 탐지하고 복구하던 조직이 AI 자동복구를 Pilot으로 시험한다고 해보겠습니다. 가령 특정 장애 유형에서 MTTR이 40%, 운영비가 30% 줄고 품질 악화가 없다는 근거를 얻었다면, 그 결과만 보고 곧장 전면 적용하지는 않습니다. 자동복구를 허용할 조건, 사람의 승인 범위, 실패했을 때의 복구 절차와 책임자를 정해야 합니다.

검증된 방식과 조건을 Work Blueprint에 반영하면 AI 자동복구가 새로운 표준 운영이 됩니다. 그때부터는 새 RTB의 SLI와 SLO를 정하고 다시 Gap을 측정합니다. 실패한 Pilot도 어떤 조건에서 통하지 않았는지 규칙과 데이터에 남겨야 다음 실험에 쓸 수 있습니다.

Operate → Measure → Optimize → Discover → Experiment → Transform → Standardize → Operate

회사는 이렇게 운영을 개선하면서 새로운 기회를 찾고, 검증된 변화를 표준화하는 하나의 루프로 움직입니다.

결국 중심은 Machine-readable Company

이 모델에서 RTB와 CTB는 같은 기반을 서로 다른 목적으로 사용합니다.

• RTB — Machine-readable → Observable → Measurable → Optimizable. 업무와 결과가 읽혀야 현재 상태를 관측하고 목표와의 Gap을 측정해 운영을 최적화할 수 있습니다.
• CTB — Machine-readable → Understandable → Hypothesizable → Experimentable. 현재 사업이 어떻게 움직이는지 이해해야 다른 방식의 가치를 가설로 세우고 빠르게 실험할 수 있습니다.

그래서 AI 도입의 첫 질문은 “AI를 어디에 붙일까?”보다 “우리 회사는 AI가 이해할 수 있는 회사인가?”에 가깝습니다. 업무는 사람 머릿속에 있고 결정 근거는 회의와 메신저에 사라지며 데이터가 실제 업무와 연결되지 않는다면, AI를 붙여도 효과는 부분적인 업무 자동화에 머물기 쉽습니다.

반대로 업무와 데이터의 관계가 명확하면 AI가 참여할 수 있는 범위가 넓어집니다. Observe로 현재 상태를 읽고, Diagnose로 병목을 찾고, Recommend로 개선안이나 가설을 제안합니다. Prioritize에서 ROI와 Risk를 따져 사람과 Agent가 맡을 Execute 범위를 정합니다. Verify로 결과를 확인하고, Learn에서 Work Blueprint와 Rule을 갱신합니다. 판단과 책임의 경계는 각 단계에서 명확해야 합니다.

문제를 한 번 해결하고 끝내지 않고, 발생한 예외를 규칙에 반영해 회사의 운영 방식 자체를 바꾸는 것입니다. 전사 업무를 한꺼번에 모델링할 필요는 없습니다. 중요한 업무 하나를 골라 목표, 흐름, 권한, 데이터, 지표를 연결하고 작은 개선이나 실험부터 시작하면 됩니다.

AI-native Company는 업무와 의사결정 구조를 Machine-readable하게 만들고, RTB는 SLI·SLO·ROI를 기반으로 지속 최적화하며, CTB는 전략적 기회를 가설·실험·데이터로 검증해 사업으로 전환하는 회사입니다. 검증된 변화는 Work Blueprint에 반영해 새로운 RTB로 표준화합니다.

Value Flow와 책임·검증을 중심에 둔 기존 조직 운영체계를 AI 시대의 Company OS로 확장한 모델입니다.

결국 AI 시대의 경쟁력은 AI를 몇 곳에 도입했는지보다, 회사가 얼마나 빨리 Optimize → Learn → Change할 수 있는지에서 나옵니다.

AI 시대의 Company Operating Model

모바일에서는 그림을 좌우로 넘기고, 누르면 원본 크기로 볼 수 있습니다.