← 블로그 AX 전략

AI 네이티브 운영체제 만드는 법 — 6단계 구축 가이드

흩어진 사내 툴 7~12개를 하나로 합치고 그 위에 AI 에이전트를 얹는 순서 — 단계별 산출물·인터뷰 질문·프롬프트까지

AX LABS 2026.08.18 14분 읽기

AI 도입이 잘 안 풀리는 회사에는 공통점이 하나 있다. AI를 기존 스택 위에 얹기만 했다는 것. CRM에 붙은 AI 기능, 협업툴에 붙은 요약 버튼, 팀원 각자의 챗봇 구독. 툴은 여전히 흩어져 있고 데이터도 흩어져 있으니, AI가 볼 수 있는 범위는 자기가 붙어 있는 툴 하나뿐이다.

Boom Automations의 Luke Pierce가 최근 공개한 글이 이 문제를 정면으로 다룬다. 4년간 90개 이상 회사에 맞춤 시스템을 구축한 경험을 토대로, 회사 운영 자체를 AI 위에서 돌아가게 만드는 6단계 절차를 정리한 내용이다. 원문은 미국 시장 기준이지만 구조는 그대로 옮겨 쓸 수 있어서, 여기서는 국내 팀이 실제로 실행할 수 있는 형태로 각 단계의 산출물 양식·인터뷰 질문·프롬프트를 붙여 다시 썼다.

AI 네이티브 운영체제란 무엇인가

한 문장으로 줄이면, 회사의 모든 데이터가 한 곳에 있고 AI가 그 위에서 일하는 시스템이다. 로그인 하나, 데이터베이스 하나, 모든 부서가 같은 시스템 안에 있고, AI는 나중에 붙는 기능이 아니라 업무 흐름 자체에 들어가 있다.

핵심은 기술이 아니라 AI가 볼 수 있는 범위다. AI의 유용함은 결국 접근 가능한 데이터가 결정한다. 업무가 7개 툴에 흩어져 있으면 어떤 모델도 전체 그림을 볼 수 없다. 반대로 한 시스템에 모여 있으면, 붙이는 첫날부터 쓸모가 생긴다.

아래는 그 시스템을 만드는 6단계다. 순서 자체가 이 방법론의 핵심이다.

앞의 세 단계(매핑·정리·설계)는 아무것도 만들지 않는 단계다. 여기를 건너뛰고 4단계부터 시작하는 것이 실패한 프로젝트의 거의 공통된 패턴이다.

1단계 — 업무 매핑: 회사가 실제로 어떻게 돌아가는지 그린다

도구를 고르기 전, 코드 한 줄 쓰기 전에 전체 업무를 지도로 만든다.

무엇을 적는가

부서별로 워크플로를 전부 나열한다. 주 1회 이상 반복되면 워크플로다. 각각에 대해 시작 신호, 중간 단계 전부, "끝났다"의 정의를 적는다.

산출물은 스프레드시트 한 장이면 충분하다. 컬럼은 이렇게 잡는다.

컬럼	내용	예시
워크플로명	업무 이름	신규 고객 온보딩
트리거	무엇이 이 일을 시작시키나	계약서 서명 완료
담당	실제로 손을 움직이는 사람	AM
단계	1~N 순서대로	①계정 생성 ②킥오프 일정 ③자료 요청…
사용 툴	이 워크플로에서 거치는 툴 전부	시트, 메일, 노션, 드라이브
핸드오프	사람↔사람, 툴↔툴 넘어가는 지점	영업→AM, 시트→노션
중복 입력	같은 정보를 두 번 이상 타이핑하는 곳	고객사명·담당자 3곳
완료 정의	무엇이 되면 끝인가	킥오프 회의록 공유됨
주간 수작업 시간	사람 손이 들어가는 시간 추정	4.5h

어떻게 알아내는가

반드시 그 일을 실제로 하는 사람과 함께 짚는다. 대표가 아는 온보딩 절차와 담당 AM이 실제로 하는 절차는 보통 다른 프로세스다. 인터뷰는 이 8개 질문이면 대부분 나온다.

이 일이 시작되는 걸 어떻게 아세요? (알림? 누가 말해줘서? 직접 확인?)
시작하고 나서 제일 먼저 여는 창이 뭔가요?
그 다음은요? — "그 다음은요?"를 끝까지 반복한다
이 중에 같은 내용을 두 번 이상 입력하는 곳이 있나요?
다른 사람에게 넘기는 지점은 어디인가요? 넘기고 나서 보통 얼마나 기다리나요?
최근에 이 일이 꼬였던 사례 하나만 말해주세요. 뭐가 원인이었나요?
이 절차 중에 "굳이 왜 하는지 모르겠는데 그냥 하는" 단계가 있나요?
이 워크플로 하나에 일주일에 몇 시간쯤 쓰세요?

6번과 7번이 특히 중요하다. 6번은 뒤에서 자동화 우선순위가 되고, 7번은 아무도 안 보는 산출물을 만들어내는 유령 단계를 잡아낸다.

왜 이 단계가 제일 중요한가

20명 규모라면 집중해서 일주일이면 끝난다. 그 결과로 얻는 것은 비슷한 규모 회사가 거의 갖고 있지 않은 것 — 회사가 실제로 어떻게 돌아가는지에 대한 완전한 그림이다. 원문에서도 아무것도 만들기 전에 이 지도만으로 이미 값을 했다는 반응이 반복해서 나온다고 말한다.

그리고 마지막 컬럼(주간 수작업 시간)이 이후 모든 단계의 우선순위와 ROI 계산 근거가 된다. 지도 없이 시작하면 우선순위를 목소리 큰 사람이 정하게 된다.

2단계 — 툴 정리: 흡수 / 유지 / 폐기

지도가 나왔으면 스택을 감사한다. 지금 쓰는 툴을 전부 꺼내 세 바구니에 나눈다.

바구니	판단 기준	흔한 대상
흡수	사실상 "정보를 정리해 담아두는" 역할이 전부인 툴	프로젝트 보드, 연락처 목록 수준의 CRM, 시트 트래커, 폼, 사내 위키
유지	한 가지 전문 기능을 아주 잘하거나 법·규제가 걸린 툴	회계·세무, 메일·캘린더, 업종 전용 시스템
폐기	아무도 안 쓰거나 다른 툴과 기능이 겹치는 것	결제만 되고 있는 구독, 중복 협업툴

흡수 판별 테스트 한 줄: 그 툴의 핵심 가치가 "우리 자료가 여기 정리돼 있다"라면 흡수 대상이다. 정리는 어차피 새 시스템이 하고, 심지어 다른 데이터와 연결된 채로 한다.

이 감사를 돌리면 보통 툴 7~~12개가 시스템 하나 + 유지 툴 2~~3개로 접힌다. 폐기 바구니는 이번 주에 바로 해지하면 되고, 프로젝트가 시작되기도 전에 첫 번째 ROI가 나온다.

정리 결과는 문서로 남긴다. 툴명 / 바구니 / 월 비용 / 담당 / 이관 시 옮겨야 할 데이터 / 판단 근거. 이 표가 4단계 이관 순서의 입력값이 된다.

3단계 — 데이터 모델 설계: 진실이 어디 있는지 정한다

모두가 건너뛰고 싶어 하고, 건너뛰면 전체가 무너지는 단계다. 데이터 모델이 곧 단일 진실 원천이고 나머지 전부가 그 위에 얹힌다.

절차는 세 가지다

① 엔티티를 나열한다. 회사가 굴러가는 데 필요한 명사들 — 고객, 프로젝트, 작업, 청구, 문서, 담당자, 리드, 발주, 협력사. 이 규모 회사는 보통 15~30개가 나온다.

② 관계를 정의한다. 고객 1 : N 프로젝트, 프로젝트 1 : N 작업·문서, 마일스톤 1 : 1 청구, 담당자 N : N 작업. 그림으로 그린다. 이 그림이 회사의 뼈대다.

③ 엔티티마다 "진실이 어디 있는지" 한 곳만 정한다. 고객 연락처가 시스템 안에 있으면, 누군가 따로 관리하는 시트에는 없어야 한다. 데이터가 두 곳에 살면 반드시 어긋나고, 어긋나는 순간 팀이 시스템을 안 믿기 시작한다. 그 다음은 다시 시트다.

설계 규칙 두 개

지금 회사 + 한 단계 위까지만 설계한다. 매출 2배 시점을 기준으로 잡고 거기서 멈춘다. 50배 미래를 상상해서 설계한 시스템은 아무도 이해하지 못하는 덩어리가 된다.

떠 있는 레코드를 만들지 않는다. 모든 레코드는 무언가에 연결된다. 고객·프로젝트·프로세스 중 어디에도 붙일 수 없는 문서라면, 왜 보관하는지부터 다시 묻는다.

1단계 지도에서 초안을 뽑는 프롬프트

매핑 시트를 그대로 붙여 넣고 아래 프롬프트를 쓰면 엔티티/관계 초안이 나온다. 사람이 검토·수정하는 것이 전제다.

아래는 우리 회사 워크플로 매핑 시트다.
이걸 근거로 운영 시스템의 데이터 모델 초안을 만들어줘.

1. 시트에 등장하는 명사를 후보 엔티티로 뽑고, 같은 것을 다르게 부른 경우
   (예: 고객사/클라이언트/거래처)는 하나로 합치되 어떤 표현들을 합쳤는지 표기해.
2. 엔티티 간 관계를 1:N / N:M으로 정리해. 근거가 된 워크플로 단계를 함께 적어.
3. 각 엔티티마다 필수 속성만 나열해. "있으면 좋은" 속성은 빼.
4. 같은 정보가 두 개 이상의 엔티티나 툴에 중복 기록되는 지점을 전부 찾아내고,
   진실의 위치를 어디로 정할지 후보와 근거를 제시해.
5. 어떤 워크플로에도 연결되지 않는 고아 엔티티가 있으면 따로 표시해.

추측으로 엔티티를 추가하지 마. 시트에 근거가 있는 것만 만들어.

[매핑 시트 붙여넣기]

여기를 제대로 하면 이후 단계가 전부 쉬워진다. 틀리면 1년 뒤에 다시 만들게 된다.

4단계 — 코어 구축과 이관: 팀이 실제로 사는 곳을 만든다

이제 팀이 매일 일하는 시스템을 만든다. 3단계 데이터 모델을 읽는 화면과 뷰다.

이관 순서

부서 하나씩. 1단계 지도에서 주간 수작업 시간이 가장 많았던 부서부터 시작한다. 그 부서가 새 시스템에서 완전히 일상 업무를 돌릴 때까지 다음 부서로 넘어가지 않는다. 전원을 한 번에 옮기려는 시도가 이 프로젝트를 죽이는 가장 흔한 방식이다.

화면은 기존 습관 그대로 다시 만든다

기존에 보드로 쓰던 것은 새 시스템에서도 보드로, 파이프라인으로 쓰던 것은 파이프라인 뷰로 만든다. 같은 멘탈 모델, 같은 손동작, 다만 이제 모든 것과 연결된 상태로. 원문이 밝힌 높은 정착률의 핵심 이유가 여기다 — 시스템이 첫날부터 익숙하게 느껴지고, 팀 입장에서는 툴이 하나 늘어난 게 아니라 여러 개가 사라진 것이기 때문이다.

이 단계의 유일한 금지 사항

아직 아무것도 자동화하지 않는다. 통합과 자동화를 동시에 하면, 아직 정리되지 않은 프로세스를 자동화하게 되고 결국 둘 다 무너진다. 4단계의 목표는 딱 두 개다. 깨끗하게 연결된 데이터, 그리고 한 시스템에서 완전히 살고 있는 팀.

5단계 — AI 에이전트 배치

단일 진실 원천이 생겼으므로, 이 단계는 빠르게 진행된다. 에이전트가 필요한 맥락을 이미 전부 갖고 있기 때문이다. 만드는 순서까지 포함해 네 종류를 권한다.

① 문서 인테이크 — 제일 먼저

영수증·세금계산서·견적서·계약서가 PDF와 메일로 들어온다. AI가 읽고, 항목을 추출하고, 구조화된 레코드로 DB에 넣는다. 제일 먼저 만드는 이유는 이것이 DB를 채우는 입구이고, 효과를 모두가 즉시 체감하기 때문이다. 원문 사례에서는 이 하나로 수년간 이어지던 수기 재입력 업무가 끝났다.

추출은 자유 서술이 아니라 스키마로 받는다.

{
  "doc_type": "invoice | quote | receipt | contract | unknown",
  "issuer": { "name": "string", "biz_no": "string|null" },
  "issued_at": "YYYY-MM-DD",
  "currency": "KRW",
  "total_amount": 0,
  "tax_amount": 0,
  "line_items": [{ "desc": "string", "qty": 0, "unit_price": 0, "amount": 0 }],
  "match": { "client_id": "string|null", "project_id": "string|null" },
  "confidence": 0.0,
  "needs_review": true
}

confidence와 needs_review는 선택이 아니라 필수다. 자신 없는 건은 사람 검토 큐로 보내는 경로가 있어야 운영에 올릴 수 있다. 초기 2~4주는 전건을 사람이 확인하면서 실제 정확도를 측정하고, 그 수치를 근거로 임계값을 정한다.

② 문서 생성

제안서, 계약 범위 문서, 보고서, 고객 대상 진행 업데이트. 시스템이 고객과 프로젝트 맥락을 전부 갖고 있으므로 반나절 걸리던 작업이 클릭 한 번이 된다. 여기서 품질을 가르는 것은 모델이 아니라 좋은 예시 3~5건과 금지 표현 목록이다.

③ 운영 질의

DB 전체에 연결돼 누구나 물어볼 수 있는 에이전트. 어떤 프로젝트가 지연 중인지, 이 고객사에 지난 분기 얼마를 청구했는지, 미수금이 어디인지. 20분씩 뒤지던 질문이 몇 초로 줄어든다.

권한 범위를 데이터 모델 단계에서 미리 정해두면 여기서 그대로 쓰인다. 급여·인사 정보처럼 조회 주체를 가려야 하는 엔티티는 3단계에서 표시해 둔다.

④ 라우팅·분류

들어오는 문의·요청을 읽고 유형을 분류해 담당자와 우선순위까지 붙여둔다. 사람이 열어보기 전에 이미 정리돼 있는 상태를 만든다.

운영비를 가르는 설계: 모델 라우팅

모든 작업에 최상위 모델이 필요하지는 않다. 단순 추출·분류는 빠르고 저렴한 모델로, 추론·판단·초안 작성은 프론티어 모델로 보낸다. 원문은 이 라우팅만으로 AI 비용이 80% 이상 줄어드는 경우가 흔하다고 말한다. 숫자는 워크로드마다 다르겠지만 방향은 분명하다 — 호출 건수가 가장 많은 층이 가장 단순한 작업이기 때문에, 여기를 내리는 것이 비용 구조를 바꾼다.

실무에서는 이렇게 시작하면 된다.

작업	모델 등급	판단 기준
문서 항목 추출, 문의 분류, 태깅	소형·저가	정답이 정해져 있고 검증이 쉬움
요약, 정형 초안, 번역	중형	형식은 정해져 있고 표현만 생성
제안서 작성, 이상 징후 판단, 코드	프론티어	틀리면 비용이 크고 맥락이 넓음

등급을 내릴 때는 반드시 같은 입력 30~50건으로 소형과 대형의 결과를 비교한 뒤에 내린다. 감으로 내리면 조용히 품질이 깎인다.

6단계 — 백그라운드 자동화

마지막은 사람 손이 아예 닿지 않아야 하는 일이다. 상태가 바뀌면 고객에게 메일이 나가고, 기한이 지나면 리마인더가 돌고, 마일스톤이 끝나면 청구가 생성되고, 문서가 알아서 만들어져 제자리에 저장된다.

목록은 새로 만들 필요가 없다. 1단계 지도에서 표시한 핸드오프와 반복 작업이 그대로 자동화 후보다. 주간 수작업 시간 순으로 정렬해 위에서부터 만든다.

원문에서 가장 큰 사례는 이런 백그라운드 자동화를 28개 돌린다. 리마인더·메일·문서 작업이 통째로 사람 머릿속에서 사라진 상태다.

자동화마다 다음 세 가지를 같이 정의해 두면 나중에 사고가 안 난다.

발동 조건: 어떤 상태 변화에서 도는가 (모호하면 안 만든다)
되돌리는 법: 잘못 나갔을 때 어떻게 취소·정정하는가
관측 지점: 이 자동화가 이번 주에 몇 번 돌았고 몇 번 실패했는가

완성되면 어떤 모습인가

원문의 사례 하나. 창고·물류 회사가 액티브 프로젝트 450건을 Airtable·엑셀·드롭박스·PDF 도구에 나눠 운영하고 있었고, PM 5명이 각자 다른 방식으로 일하고 있었다.

같은 6단계를 그대로 밟은 결과는 하나의 AI 네이티브 운영체제였다. 화면 41개, 테이블 50개, 백그라운드 자동화 28개. 들어오는 영수증·견적서·계산서를 AI가 전부 읽고, 계약 범위 문서는 클릭 한 번에 생성되고, 세 가지 요금 체계가 걸린 청구가 자동으로 계산되며, 고객은 포털에서 자기 건을 직접 조회한다. 기존 스택은 전부 사라졌고, 툴 사이에서 데이터를 옮기던 시간이 그대로 팀에게 돌아왔다.

왜 매출 30억~150억 구간이 가장 크게 이기는가

원문은 이 방식의 ROI가 가장 크게 나오는 구간을 연 매출 200만~~1,000만 달러(약 30억~~150억 원), 인원 20명 안팎, ERP 없음으로 특정한다. 부서마다 다른 SaaS를 쓰고 그 사이를 자동화 도구 몇 개가 임시로 잇고 있는 상태다.

이유는 두 가지다.

첫째, 걷어낼 것이 없다. 대기업의 AI 도입은 수십 년 쌓인 레거시, 마이그레이션 프로젝트, 부서 간 정치와 싸워야 한다. 20명 회사는 그 전부가 없다. 벗어날 대상이 스프레드시트와 월 단위 구독뿐이다.

둘째, 비중이 다르다. 주당 60시간의 수작업을 걷어내면 20명 회사는 회사가 바뀐다. 대표가 주 10시간 이상을 돌려받고, 팀은 앱 사이 복사·붙여넣기에서 벗어나며, 인원을 같은 속도로 늘리지 않고도 매출을 키울 수 있다. 같은 60시간이 500명 회사에서는 반올림 오차다.

여기에 하나 더. 레거시 ERP 세대를 통째로 건너뛸 수 있다. 유선전화망을 깔지 않은 나라가 곧장 이동통신으로 간 것과 같은 구조다.

실패하는 방식 네 가지

정리하면 이렇다. 우리가 현장에서 반복해서 보는 것과도 겹친다.

1️⃣ 1단계를 건너뛴다. 지도 없이 시작한 프로젝트는 예외 없이 중반에 "이게 원래 어떻게 돌아가던 거였죠?"에서 멈춘다.

2️⃣ 통합과 자동화를 동시에 한다. 정리되지 않은 프로세스를 자동화하면 잘못된 절차가 더 빨리 돌 뿐이다.

3️⃣ 진실을 두 곳에 둔다. "일단 시트도 같이 쓰죠"가 시스템 신뢰를 무너뜨리는 첫 문장이다.

4️⃣ 전 부서를 한 번에 옮긴다. 한 부서가 완전히 정착한 뒤 다음으로 가는 것이 유일하게 작동하는 방식이다.

이번 주에 할 일

1단계만 한다. 일주일을 비우고, 워크플로를 전부 매핑하고, 수작업 시간을 재는 것. 그 뒤로 아무것도 만들지 않더라도 이 지도는 회사를 보는 눈을 바꾼다. 그리고 만들기로 한다면, 이후 전부가 여기에 의존한다.

순서를 지킨다. 매핑 → 툴 정리 → 데이터 모델 → 코어 구축 → 에이전트 → 자동화. 실패한 AI 프로젝트는 대부분 어느 한 단계를 건너뛰었고, 그 단계는 보통 첫 번째다.

에이전트를 어떤 구조로 얹을지, 어디에 검문소를 세울지는 실패 기반 하네스 수정 루프에서 더 깊이 다뤘다. 5단계 이후의 운영 품질은 결국 그 루프가 결정한다.

AX LABS는 국내 대기업을 대상으로 AI 에이전트 개발, 실무자와 컨설턴트가 한 팀으로 5주간 현업 문제를 푸는 Project Based Learning, AI 교육·워크숍을 수행하고 있습니다. 우리 회사의 업무 지도를 그리고 그 위에 무엇을 올릴지 함께 정하고 싶다면 문의하기 →

참고

원문: Luke Pierce, "The Full Guide to Building an AI-Native Operating System" (@lukepierceops)
Boom Automations: https://boomautomations.com