AX의 핵심 철학 AX는 IT 도입의 문제가 아니라 조직의 역할을 다시 설계하는 HR의 문제입니다. AI를 조직의 업무와 의사결정 프로세스에 참여시키고, 사람과 AI가 병립하여 고객가치와 업무성과를 만드는 경영체계입니다.
SECTION 03
도구와 역할은 무엇이 다른가?
도구는 사람이 사용해야 기능하지만, 역할은 조직의 업무체계 안에서 계속 수행되어야 합니다.
구분
도구
역할
주도권
사람에게 있다
업무시스템에 있다
설명 기준
어떤 기능을 제공하는가?
어떤 성과를 만들어야 하는가?
작동 조건
사람이 필요할 때 선택하여 사용한다
업무 흐름과 조건에 따라 지속적으로 수행된다
사람이 없을 때
사용자가 사라지면 기능도 업무에서 사라진다
담당자가 바뀌어도 역할은 시스템 안에 남아야 한다
시스템과의 관계
없어도 기존 업무시스템은 유지된다
필요한 역할이 없으면 업무시스템이 완성되지 않는다
도구는 기능으로 설명한다
문서를 요약한다 · 회의록을 작성한다 · 데이터를 분석한다 · 질문에 답한다 · 블로그 글을 작성한다 · 숏폼 영상을 자동 제작한다
역할은 성과로 설명한다
누락을 방지한다 · 오류를 조기에 발견한다 · 의사결정 근거를 제공한다 · 고객가치를 높인다
도구 도입 = 기능의 추가 │ 역할 도입 = 업무체계의 변화
‘시스템에 주도권이 있다’는 의미 AI가 경영권이나 최종 결정권을 갖는다는 뜻이 아닙니다. 특정 직원의 기억과 실행 의지에 의존하지 않고, 조직이 정의한 역할이 업무 프로세스 안에서 지속적으로 작동한다는 뜻입니다.
과정의 출발점 도구를 먼저 고르지 않습니다. 고객가치와 업무성과를 먼저 정의하고, 이를 달성하는 데 필요한 역할을 찾은 뒤 사람·코딩 시스템·맞춤 AI 에이전트에 적합하게 배치합니다.
AX코칭 전문가 과정 · MODULE 01
서비스 청사진 작성법
조직진단을 위한 실전 교안
고객이 경험하는 서비스와 조직 내부의 업무를 한눈에 연결하고, 업무규칙·코딩 시스템·맞춤 AI 에이전트·사람의 역할을 진단하기 위한 실전 교안
과정 안내
왜 서비스 청사진을 배우는가?
AX(AI Transformation, 인공지능 기반 조직 전환)는 AI(Artificial Intelligence, 인공지능) 도구를 고르는 일에서 시작하지 않습니다. 고객가치를 만드는 조직의 흐름을 이해하고, 필요한 역할과 업무규칙을 정의한 뒤 코딩 시스템·맞춤 AI 에이전트·사람을 올바르게 배치하는 일에서 시작합니다.
고객가치 확인→서비스 흐름 진단→문제·단절 발견→규칙·시스템·AI·사람 설계
서비스 청사진은 고객에게 보이는 경험과 보이지 않는 조직의 움직임을 함께 펼쳐 보는 지도입니다.
SECTION 01
서비스 청사진의 개념과 목적
고객의 경험과 그 경험을 만들어 내는 조직의 활동을 한 장에 연결합니다.
1. 서비스 청사진이란?
서비스 청사진(Service Blueprint)은 고객이 서비스를 경험하는 과정과, 이를 제공하기 위해 조직 내부에서 수행되는 업무를 시간순으로 연결한 설계도입니다.
에스유디자인 사례
고객에게 보이는 흐름 문의 → 상담 → 현장 방문 → 견적 확인 → 계약 → 공사 → 인수 → A/S
뒤에서 움직이는 흐름 문의 접수 → 담당자 배정 → 고객정보 확인 → 현장 일정 조율 → 견적 산출 → 도면 검토 → 자재 발주 → 공정 관리 → 수금 관리
2. 핵심 용어
용어
뜻
인테리어 회사 예시
서비스
고객의 문제를 해결하고 가치를 제공하는 전체 과정
고객이 원하는 업무공간을 기획하고 완성하는 것
고객 여정
고객이 필요를 느낀 순간부터 서비스가 끝날 때까지의 흐름
검색 → 문의 → 상담 → 계약 → 공사 → 입주
고객 행동
각 단계에서 고객이 실제로 하는 행동
전화하기, 도면 보내기, 견적 검토하기
접점
고객과 회사가 만나는 순간과 통로
전화, 카카오톡, 상담실, 현장
조직 활동
고객 경험을 만들기 위한 내부 업무
상담 기록, 견적 작성, 공정 확인
3. 무엇을 발견하기 위한 도구인가?
고객 경험의 문제고객이 불안하거나 기다리고, 같은 설명을 반복하는 지점
조직 흐름의 단절부서 간 정보가 끊기거나 특정 직원에게 의존하는 지점
운영 위험실수·누락·재작업이 반복되는 지점
AX 기회사람이 판단할 일과 AI가 지원·실행할 일을 구분할 지점
4. 일반 업무 프로세스와의 차이
구분
일반 업무 프로세스
서비스 청사진
출발점
조직과 부서의 업무
고객의 목적과 경험
핵심 질문
우리 조직은 무엇을 하는가?
고객은 무엇을 경험하며, 그것을 누가 어떻게 만드는가?
주요 관찰
업무 순서, 담당자, 승인
접점, 대기, 감정, 내부업무와의 연결
첫 번째 원칙 “우리 회사가 무슨 일을 하는가?”보다 “고객이 어떤 목적을 이루기 위해 어떤 경험을 하는가?”에서 시작합니다.
강의 점검 질문
우리 회사가 제공한다고 생각하는 서비스와 고객이 얻고자 하는 가치는 같은가?
현재 업무 흐름은 고객 관점인가, 부서 관점인가?
SECTION 02
고객 여정과 고객 행동 정의하기
서비스 청사진의 첫 번째 줄에는 회사 업무가 아니라 고객의 행동을 시간순으로 적습니다.
1. 고객 여정과 여정 단계
고객 여정(Customer Journey)은 고객이 필요를 인식한 순간부터 서비스를 이용하고 관계가 끝날 때까지의 전체 흐름입니다. 이 안의 큰 구간을 여정 단계(Journey Stage)라고 합니다.
문제 인식→업체 탐색→문의·상담→제안·계약→설계·시공→검수·A/S
2. 고객 행동은 동사로 쓴다
여정 단계
고객이 실제로 하는 행동
업체 탐색
검색하고 시공사례와 후기를 비교한다
문의·상담
상담을 요청하고 요구사항·예산·일정을 설명한다
제안·견적
제안서와 견적서를 비교하고 질문한다
계약
조건을 협의하고 계약서에 서명한다
시공
진행 상황을 확인하고 변경을 요청한다
검수·A/S
하자를 확인하고 보완 또는 수리를 요청한다
표현을 바꿔 보세요. “견적서 발송”은 회사 행동입니다. 서비스 청사진의 고객 행동에는 “견적서를 받아 검토한다”라고 씁니다.
3. 행동 뒤의 실제 목표를 찾는다
고객 행동
고객이 실제로 이루려는 목표
시공사례를 검색한다
믿고 맡길 회사를 찾는다
견적서를 검토한다
가격이 적정하고 빠진 항목이 없는지 확인한다
공사 진행 상황을 묻는다
예정대로 입주할 수 있는지 안심하고 싶다
하자를 전달한다
회사가 끝까지 책임지고 해결하는지 확인한다
고객에게 견적서를 전달하는 것이 목적이 아닙니다. 고객이 예산 안에서 원하는 공간을 만들 수 있는지 판단하게 하는 것이 목적입니다.
4. 분석 범위를 정하는 방법
고객 유형 1명예: 직원 30명의 사무실 이전을 결정하는 중소기업 대표
목적 1개예: 정해진 예산과 일정 안에 안심하고 새 사무실에 입주한다
시작점 1개예: 기존 사무실의 문제를 인식하고 업체를 찾기 시작한다
종료점 1개예: 입주 후 첫 번째 A/S가 완료된다
5. 실제 작성 순서
고객 유형을 한 명으로 특정합니다.
고객이 이루려는 최종 목적을 정합니다.
여정의 시작점과 종료점을 정합니다.
여정을 5~10개의 큰 단계로 나눕니다.
각 단계의 고객 행동을 동사로 적습니다.
두 번째 원칙 고객의 행동만 적지 말고, 그 행동 뒤에 있는 의도와 기대를 함께 봅니다.
강의 점검 질문
우리가 분석하려는 고객은 구체적으로 누구인가?
그 고객이 최종적으로 이루려는 목적은 무엇인가?
여정의 시작과 끝이 한 장에 담을 수 있을 만큼 명확한가?
SECTION 03
고객 접점과 물리적 증거
고객이 회사와 어디에서 만나고, 무엇을 보고 서비스의 품질을 판단하는지 찾습니다.
1. 고객 접점
고객 접점(Touchpoint)은 고객이 회사·직원·시스템과 직접 상호작용하는 순간과 통로입니다. 대면뿐 아니라 홈페이지, 전화, 카카오톡, 이메일, 문서, 현장, 결제와 A/S도 모두 포함합니다.
2. 물리적 증거
물리적 증거(Physical Evidence)는 고객이 서비스의 존재와 품질을 판단하게 해주는 확인 가능한 단서입니다. 문서뿐 아니라 공간, 이미지, 말투, 현장 상태처럼 고객이 보고·듣고·받는 모든 흔적을 포함합니다.
구분
핵심 질문
예시
고객 접점
고객은 회사와 어디에서 만나는가?
상담 미팅, 현장 방문, 카카오톡 보고, A/S 접수
물리적 증거
고객은 무엇을 보고 품질을 판단하는가?
상담자료, 견적서, 현장사진, 공정표, A/S 완료확인서
3. 인테리어 서비스에 적용하기
고객 행동
고객 접점
물리적 증거
업체를 검색한다
홈페이지·검색·SNS
시공사례, 후기, 회사 소개
상담을 신청한다
전화·카카오톡·문의폼
자동응답, 예약확인 메시지
요구사항을 설명한다
대면·Zoom·현장미팅
상담표, 질문지, 미팅 공간
제안과 견적을 검토한다
설명회·이메일
제안서, 도면, 견적서, 일정표
공사를 확인한다
현장방문·단체방
현장사진, 공정보고서, 변경기록
검수하고 A/S를 요청한다
현장 입회·접수채널
체크리스트, 하자목록, 완료확인서
4. 접점마다 확인할 네 가지
고객은 누구 또는 어떤 시스템과 만나는가?
어떤 정보를 주고받는가?
무엇을 보고 서비스 품질을 판단하는가?
그 순간 어떤 감정을 느끼는가?
견적 설명 접점 진단
대상 영업담당자 또는 대표
정보 공사범위·금액·일정·제외사항
물리적 증거 견적서·도면·자재표·공정표
감정 기대·의심·비교 부담·추가비용에 대한 불안
5. 자주 발생하는 실수
고객이 실제로 보지 않는 내부자료까지 물리적 증거로 적습니다.
“카카오톡”처럼 채널명만 쓰고 어떤 상호작용인지 적지 않습니다.
대기·반복 문의·이해 실패 같은 불편한 접점을 제외합니다.
자료가 존재하는지만 보고 고객이 이해하고 신뢰하는지는 확인하지 않습니다.
세 번째 원칙 고객은 조직 내부의 노력을 직접 볼 수 없습니다. 고객에게 전달된 결과와 흔적으로 회사의 품질과 신뢰를 판단합니다.
강의 점검 질문
우리의 중요한 접점마다 고객에게 남는 신뢰의 증거가 있는가?
고객이 가장 불안해하는 접점은 어디인가?
그 접점의 물리적 증거는 고객이 이해하기 쉬운가?
SECTION 04
전면 업무와 가시선
고객의 행동에 대응하여 고객에게 직접 보이는 직원과 시스템의 행동을 연결합니다.
1. 전면 업무란?
전면 업무(Frontstage Action)는 고객이 직접 보거나 느낄 수 있는 직원·시스템의 행동입니다. 대면 응대뿐 아니라 자동응답, 일정 알림, 공정보고처럼 디지털 접점에서 일어나는 행동도 포함됩니다.
고객 행동
전면 업무
상담을 신청한다
시스템이 접수 완료와 연락 예정 시간을 안내한다
요구사항을 설명한다
상담자가 질문하고 핵심 요구를 재확인한다
현장조사에 참여한다
담당자가 실측하며 진행 방법과 확인사항을 설명한다
견적서를 검토한다
담당자가 범위·금액·제외사항과 산출 근거를 설명한다
공사 상황을 확인한다
현장담당자가 사진과 다음 공정계획을 보고한다
A/S를 요청한다
담당자가 접수를 확인하고 처리 일정을 안내한다
2. 상호작용선
상호작용선(Line of Interaction)은 고객 행동과 전면 업무가 직접 만나는 경계입니다. 고객이 정보를 요청·제공하고 조직이 응답하는 모든 순간이 이 선을 통과합니다.
상담 접점의 상호작용
고객 행동 상담폼에 요구사항과 연락처를 입력한다.
상호작용 정보 제출과 접수 확인이 오간다.
전면 업무 시스템이 접수 완료와 담당자의 연락 시간을 안내한다.
고객 행동에 대응하는 전면 업무가 없으면 고객은 방치되었다고 느낍니다. 반대로 고객 행동과 연결되지 않는 전면 업무는 불필요한 설명이나 과잉 서비스일 수 있습니다.
3. 가시선
가시선(Line of Visibility)은 고객에게 보이는 업무와 보이지 않는 내부 업무를 나누는 경계입니다.
고객에게 보이지 않던 내부 활동의 일부를 보여주면 신뢰를 높일 수 있습니다. 자재 발주 완료, 주간 공정계획, 변경 승인 기록, 검수 결과 등이 그 예입니다. 다만 모든 내부 정보를 공개하면 오히려 혼란이 생길 수 있습니다.
가시선을 조정하는 기준은 “이 정보가 고객의 판단과 신뢰에 도움이 되는가?”입니다.
7. AX 관점에서 역할 나누기
전면 업무
사람에게 적합한 역할
AI·시스템에 적합한 역할
최초 상담
상황과 감정 이해, 신뢰 형성
기본정보 수집, 질문 누락 확인
일정 안내
예외 상황의 협의와 조정
예약·알림·변경 안내
견적 설명
조건 협상과 책임 있는 판단
항목 요약과 비교표 작성
공정 보고
문제 설명과 의사결정 지원
사진 정리와 진행률 보고
A/S 응대
불만·갈등·책임 조정
접수·분류·처리상태 추적
네 번째 원칙 전면 업무는 고객에게 보이는 직원과 시스템의 행동이며, 가시선은 보이는 서비스와 내부 업무를 나누는 경계입니다.
강의 점검 질문
모든 고객 행동에 대응하는 전면 업무가 있는가?
고객이 기다리는데 아무 안내도 없는 구간은 어디인가?
직원마다 대응이 달라지는 접점은 어디인가?
고객에게 보여줘야 할 정보가 가시선 아래에 숨겨져 있지는 않은가?
사람과 AI의 역할을 다시 나눌 수 있는 지점은 어디인가?
SECTION 05
후면 업무와 내부 상호작용선
고객에게 보이지 않지만 전면 서비스를 가능하게 만드는 활동과 역할 사이의 인계를 진단합니다.
1. 후면 업무란?
후면 업무(Backstage Action)는 고객에게 직접 보이지 않지만 고객에게 제공되는 서비스를 준비하고 실행하기 위해 수행하는 내부 활동입니다.
견적서 뒤에서 일어나는 업무
현장 실측자료 정리 → 도면 검토 → 공종별 수량산출 → 협력업체 단가 확인 → 원가·목표이익 검토 → 누락 점검 → 책임자 승인 → 견적서 편집
고객에게 보이는 서비스의 품질은 보이지 않는 후면 업무의 품질에 의해 결정됩니다.
2. 사람보다 역할을 기준으로 구분한다
조직이 작으면 한 사람이 전면과 후면 역할을 모두 수행합니다. 대표가 고객에게 견적을 설명할 때는 전면 역할이고, 설명 전 원가와 이윤을 검토할 때는 후면 역할입니다. 따라서 부서명이나 직급이 아니라 그 순간 수행하는 역할을 기준으로 구분합니다.
3. 전면 업무와 후면 업무 연결하기
고객 행동
전면 업무
후면 업무
상담을 신청한다
접수와 연락 시간을 안내한다
고객정보와 문의내용을 확인한다
요구사항을 설명한다
질문하고 핵심 요구를 재확인한다
상담내용을 정리하고 관련 담당자에게 전달한다
견적서를 검토한다
범위·금액·제외사항을 설명한다
수량과 단가를 검토하고 승인받는다
공사 상황을 확인한다
현황과 다음 일정을 안내한다
진도와 협력업체 일정을 취합한다
변경을 요청한다
가능 여부와 추가비용을 설명한다
도면·공정·원가에 미치는 영향을 검토한다
A/S를 요청한다
처리 일정을 안내한다
원인을 분석하고 보수인력과 자재를 배정한다
4. 내부 상호작용선
내부 상호작용선(Line of Internal Interaction)은 후면 업무와 이를 지원하는 부서·시스템·협력업체의 활동을 나누는 경계입니다.
견적 원가 검토의 내부 상호작용
후면 업무 견적담당자가 원가를 검토한다.
내부 상호작용 구매담당자에게 최신 자재단가를 요청한다.
지원 프로세스 구매담당자가 공급업체별 단가를 조사해 제공한다.
서비스의 지연·누락·재작업은 개인의 능력보다 역할과 부서 사이의 인계에서 자주 발생합니다.
5. 인계물과 완료 조건
내부 인계
전달되는 결과물
완료 조건
상담 → 설계
고객 요구사항 정리표
예산·일정·필수 요구가 빠짐없이 기록됨
설계 → 견적
도면·자재표·공사범위
견적 가능한 수준으로 사양이 확정됨
견적 → 영업
승인된 견적서
원가·이윤·제외사항 검토가 완료됨
영업 → 현장
계약서·최종도면·변경기록
고객과 합의한 최신 자료임이 확인됨
현장 → 재무
기성·준공 확인자료
청구 근거와 승인 상태가 확인됨
A/S → 현장
접수내용·사진
위치·증상·긴급도가 분류됨
자료를 전달했다고 인계가 끝나는 것은 아닙니다. 다음 담당자가 바로 업무를 시작할 수 있는 상태여야 인계가 완료된 것입니다.
6. 조직진단에서 표시할 신호
반복 입력같은 정보를 여러 문서와 시스템에 다시 입력한다
대기승인·자료·답변을 기다리며 업무가 멈춘다
재작업정보 부족이나 변경 누락으로 다시 작업한다
개인 의존특정 직원만 자료 위치와 처리 방법을 안다
책임 불명확누가 결정하고 확인하는지 정해져 있지 않다
버전 혼란최신 도면·견적·계약 내용을 구분하기 어렵다
업무 단절앞 단계의 정보가 다음 단계로 전달되지 않는다
확인 부재요청은 했지만 완료 여부를 추적하지 않는다
7. AX 관점에서 역할 나누기
업무 성격
적합한 역할
반복적인 정보 수집·분류·정리
맞춤 AI 에이전트
문서 간 변경사항 비교
맞춤 AI 에이전트
누락·규칙·기준 점검
맞춤 AI 또는 코딩 시스템
일정·요청·완료상태 추적
코딩 시스템
원가·공기·위험에 대한 판단
담당자와 책임자
계약조건 변경 승인
권한을 가진 사람
고객에게 약속할 내용 결정
책임 있는 사람
다섯 번째 원칙 AI는 후면 업무의 실행과 검토를 지원할 수 있지만, 의사결정 권한과 책임까지 자동으로 갖는 것은 아닙니다.
강의 점검 질문
각 전면 업무를 가능하게 하는 후면 업무가 연결되어 있는가?
누가 누구에게 어떤 결과물을 넘기는가?
인계물의 완료 조건과 승인자가 정해져 있는가?
대기·누락·재작업이 반복되는 경계는 어디인가?
특정 직원이 없으면 멈추는 업무는 무엇인가?
AI가 지원할 업무와 사람이 책임질 업무가 구분되어 있는가?
SECTION 06
지원 프로세스와 시스템
후면 업무가 안정적으로 실행되도록 부서·시스템·데이터·지식·외부 협력자가 제공하는 기반을 연결합니다.
1. 지원 프로세스란?
지원 프로세스(Support Process)는 고객과 직접 만나지는 않지만 전면·후면 업무가 수행되도록 기준·정보·승인·자원을 제공하는 조직 안팎의 활동입니다.
견적 설명을 가능하게 하는 세 층
전면 업무 영업담당자가 견적 내용을 설명한다.
후면 업무 견적담당자가 수량·단가·원가를 검토한다.
지원 프로세스 구매담당자가 최신 단가를 제공하고 시스템이 과거 견적을 조회한다.
2. 후면 업무와 지원 프로세스 구분
구분
후면 업무
지원 프로세스
핵심 역할
특정 고객에게 제공할 서비스를 직접 준비한다
전면·후면 업무가 작동할 기반을 제공한다
서비스와의 거리
해당 고객·프로젝트와 직접 연결된다
여러 고객과 업무에 공통으로 쓰인다
주요 참여자
영업·설계·견적·현장 담당자
구매·재무·인사·법무·IT·협력업체
견적 예시
해당 고객의 수량과 원가를 계산한다
최신 자재단가와 협력업체 정보를 관리한다
구분 질문: 이 활동은 특정 고객의 서비스 건을 직접 처리하는가, 여러 서비스가 작동할 기반을 제공하는가?
3. 청사진의 완성된 세로 구조
위에서부터
무엇을 기록하는가?
물리적 증거
고객이 보고 서비스 품질을 판단하는 것
고객 행동
고객이 실제로 하는 일
상호작용선
고객과 조직이 만나는 경계
전면 업무
고객에게 보이는 조직의 행동
가시선
보이는 업무와 보이지 않는 업무의 경계
후면 업무
특정 고객의 서비스를 준비하는 내부 활동
내부 상호작용선
후면 업무와 지원 기능이 만나는 경계
지원 프로세스
부서·시스템·데이터·협력업체의 지원 활동
4. 지원 프로세스의 네 가지 유형
조직과 부서구매·재무·인사·법무·품질·안전·경영지원
시스템과 도구고객관계관리(CRM)·전사적 자원관리(ERP)·전자결재·문서·프로젝트·예약 시스템
데이터와 지식고객정보·단가표·설계기준·공사이력·매뉴얼·법규
외부 협력자공급업체·전문업체·운송·장비·기술·법률 전문가
5. 인테리어 서비스에 적용하기
여정
후면 업무
필요한 지원 프로세스
상담
고객 요구사항을 정리한다
CRM·상담양식·고객정보 관리기준
현장조사
실측자료와 현장조건을 정리한다
실측도구·도면양식·사진 저장체계
설계
공간계획과 자재를 검토한다
CAD·3D·자재 라이브러리·설계기준
견적
수량과 원가를 산출한다
단가DB·과거 견적·협력업체 견적·승인체계
시공
공정·인력·자재를 조정한다
공정관리·협력업체DB·발주·재고관리
A/S
원인을 분석하고 조치한다
하자이력·보증기준·협력업체 연락체계
6. 시스템 이름이 아니라 제공 역할을 적는다
부족한 표현
진단 가능한 표현
CRM
문의·상담·견적·계약 상태를 하나의 고객번호로 연결한다
파일 서버
승인된 최신 도면을 현장담당자가 조회할 수 있게 관리한다
회계시스템
계약금·기성금·잔금의 청구와 입금을 추적한다
단가DB
자재·노무·협력업체별 최신 단가와 적용일을 제공한다
누가 또는 어떤 시스템이 + 무엇을 + 누구에게 + 어떤 기준으로 제공한다
7. 시스템·데이터·지식·규칙을 구분한다
구분
의미
예시
시스템
정보를 저장·처리·전달하는 도구
CRM, ERP, 파일 서버
데이터
시스템 안에서 활용되는 정보
고객정보, 단가표, 계약서, 공정률
지식
데이터를 해석하고 판단하는 기준과 경험
견적 누락 판단법, 하자 대응법
규칙
업무 수행과 승인의 공식 기준
이윤율, 결재권한, 파일명 규칙
AX 진단 포인트 AI의 품질은 모델 성능뿐 아니라 연결된 데이터·지식·업무규칙의 품질에 좌우됩니다.
8. 지원 프로세스 진단 기준
정보 품질정확성·최신성·출처·현장 사용성
접근성필요한 사람이 필요한 시점에 찾는가?
연결성단계 간 정보 연결과 중복 입력 여부
책임과 권한등록·갱신·승인·오류수정의 주체
지속성퇴사·시스템 변경에도 운영 가능한가?
9. AX 관점의 지원 역할
필요한 역할
코딩 시스템·맞춤 AI가 할 일
사람이 책임질 일
지식 검색
과거 견적·도면·계약·회의록 검색
검색결과의 적용 여부 판단
누락 점검
필수 문서·항목·승인 누락 감지
중요도 판단과 최종 승인
변경 추적
도면·견적·계약의 차이 비교
변경 영향 판단과 고객 협의
일정 관리
기한·지연·미완료 상태 알림
우선순위 조정과 자원 배치
지식 축적
완료 업무와 피드백을 분류·저장
표준화할 지식의 선정과 승인
10. 도구 선택의 올바른 순서
고객가치→고객 여정→전면·후면 업무→문제와 인계→지원 역할→업무규칙→시스템·AI·사람
여섯 번째 원칙 CRM·ERP·AI 에이전트부터 고르지 않습니다. 고객가치를 위해 필요한 지원 역할과 업무규칙을 먼저 정의하고, 코딩 시스템·맞춤 AI 에이전트·사람 중 적합한 수행방식을 선택합니다.
강의 점검 질문
각 후면 업무에 필요한 정보·기준·자원은 무엇인가?
그것을 누가 어떤 기준으로 제공하는가?
시스템 이름이 아니라 제공 역할로 표현했는가?
데이터·지식·규칙의 관리 책임자가 있는가?
담당자 교체 후에도 유지되는 구조인가?
SECTION 07
문제점·대기·실패 지점 표시하기
서비스가 끊기거나 느려지고 오류가 발생하는 위치를 표시해, 청사진을 업무 설명도에서 조직진단 도구로 전환합니다.
1. 찾아야 할 네 가지 문제
구분
의미
인테리어 서비스 예시
고객 불편점
고객이 불안·혼란·불만을 느끼는 순간
견적 진행 상태를 알 수 없다
대기 지점
정보·결정·승인을 기다리며 흐름이 멈추는 곳
협력업체 단가가 올 때까지 견적이 중단된다
실패 지점
누락·오류·오해가 실제 문제로 이어지는 곳
변경된 도면이 현장에 전달되지 않는다
병목 지점
특정 역할의 처리능력이 전체 속도를 제한하는 곳
모든 견적과 계약을 대표가 직접 승인한다
2. 고객 불편·대기·실패·병목을 구별한다
고객 불편반복 설명, 무응답, 이해하기 어려운 견적, 진행상태 불명
대기고객 회신, 내부 승인, 부서 자료, 외부업체, 자원, 시스템 처리 대기
실패정보·승인·기록 누락, 전달·버전·계산·일정 오류
병목대표 집중, 특정 직원 독점, 승인기준 부재, 대체자 없음
시간을 구분하세요. 견적 완료에 5일이 걸려도 실제 작업시간은 6시간이고 나머지는 자료와 승인을 기다린 시간일 수 있습니다. 개선 가능성이 큰 곳은 작업시간보다 대기시간인 경우가 많습니다.
3. 청사진 표시 범례
표시
의미
사용 예
P
고객 불편점 Pain Point
고객이 같은 내용을 반복 설명
W
대기 지점 Wait Point
단가 회신을 평균 이틀 대기
F
실패 지점 Fail Point
이전 도면으로 시공
B
병목 지점 Bottleneck
대표의 승인에 업무 집중
R
위험 지점 Risk Point
계약·안전·원가의 중대한 위험
O
개선 기회 Opportunity
반복 검수를 AI가 지원 가능
한 지점에 여러 표시를 함께 붙일 수 있습니다. 예: WBR 대표 승인 대기 + 대표 병목 + 금액 오류 위험.
4. 문제를 진단 가능한 문장으로 쓴다
모호한 표현
진단 가능한 표현
소통 부족
현장 변경사항이 당일 안에 설계·견적 담당자에게 전달되지 않는다
견적 지연
협력업체 단가 회신을 평균 이틀 기다린다
관리 미흡
담당자·기한·완료 조건이 없는 요청이 발생한다
자료 정리 안 됨
승인된 최신 도면과 이전 도면이 같은 폴더에 섞여 있다
어디에서 + 무엇이 + 왜 멈추거나 잘못되고 + 어떤 영향을 만드는가
5. 현상에서 근본원인까지 추적한다
단계
견적 제출 지연
이전 도면 사용
현상
약속한 날짜에 견적을 전달하지 못한다
현장에서 이전 도면으로 시공한다
직접 원인
협력업체 단가 회신을 기다린다
변경도면이 현장에 전달되지 않았다
구조적 원인
표준단가DB와 회신 기한이 없다
카톡·메일·폴더에 여러 버전이 존재한다
근본 문제
가격정보 축적·갱신 책임자가 없다
최신본 승인·배포 규칙이 없다
5왜 분석 예: 견적 오류가 반복된다
왜? 공종 하나가 누락됐다.
왜? 담당자가 도면을 보며 수기로 항목을 작성했다.
왜? 공종별 표준 체크리스트가 없다.
왜? 과거 오류와 경험이 개인별로 저장되어 있다.
왜? 완료된 견적을 조직 지식으로 축적하는 역할과 절차가 없다.
결론: 개인의 실수가 아니라 조직의 지식 축적 구조가 없는 문제다.
6. 문제의 영향을 측정한다
측정 항목
기록 예
발생 빈도
월 12건 중 4건
대기·재작업
평균 2일 대기, 건당 3시간 재작업
비용·매출
재시공비 150만원, 계약전환율 감소
고객 영향
고객 재문의 평균 3회
위험·의존도
안전·계약에 중대 영향, 대체 직원 없음
정확한 데이터가 없으면 높음·중간·낮음, 자주·가끔·드물게, 치명적·중대·경미로 먼저 평가하고 이후 데이터를 수집합니다.
7. 해결 우선순위 정하기
우선순위 점수 = 영향도 × 발생 가능성 × 개선 가능성 (각 1~5점)
문제
영향도
발생 가능성
개선 가능성
점수
최신 도면 혼선
5
4
4
80
견적 승인 대기
4
5
3
60
상담 예약 안내 지연
3
3
5
45
점수의 예외 안전·법적 책임·대규모 손실 가능성이 있는 문제는 발생 빈도가 낮아도 우선 처리합니다.
8. 해결책보다 역할을 먼저 정의한다
문제 위치→영향 확인→구조적 원인→필요 역할·업무규칙→시스템·AI·사람→개선 지표
견적 지연의 원인이 대표 승인 병목인데 견적서 생성 AI만 도입하면 작성시간은 줄어도 승인 대기는 남습니다. “챗봇·ERP·자동화”를 먼저 선택하지 말고 원인을 해소할 역할을 먼저 정해야 합니다.
9. AX 적용 후보와 사람의 책임
문제 특성
적합한 구현방식
사람에게 남길 책임
같은 정보를 반복 입력
코딩 시스템의 데이터 연결
계약·금액의 최종 승인
문서의 누락·차이 확인
맞춤 AI의 비교·검수
안전·법적 판단
자료 검색에 장시간 소요
맞춤 AI 지식검색 에이전트
고객 조건 협상
요청과 완료 여부 누락
코딩 시스템의 상태·알림
예외의 우선순위 결정
보고서 작성 부담
맞춤 AI의 자료취합·초안
AI 결과의 최종 검토
변경 전달 누락
코딩 시스템의 변경통보·이력
변경 영향과 대외 약속 결정
10. 청사진 문제 표시 예
여정
전면 업무
후면·지원 업무
문제 표시
상담
상담자가 내용을 확인한다
CRM·상담양식에 정리
P 같은 내용을 반복 설명
견적
완료 예정일을 안내한다
수량·원가·단가 검토
WB 단가 회신·대표 승인 대기
계약
계약조건을 설명한다
최종 조건과 문서 검토
R 구두 합의가 문서에 누락
시공
공정 현황을 보고한다
공정·도면 정보 관리
F 이전 도면 사용 가능성
A/S
처리 일정을 안내한다
하자 원인·업체 배정
PW 담당자·일정 안내 지연
일곱 번째 원칙 고객에게 나타난 현상에서 조직 내부의 구조적 원인까지 추적합니다. AX는 문제를 발견하자마자 도구를 고르는 일이 아니라, 원인을 해결할 역할과 업무규칙을 정의하고 코딩 시스템·맞춤 AI 에이전트·사람 중 적합한 수행방식을 배치하는 일입니다.
강의 점검 질문
고객의 불편과 내부의 원인을 같은 위치에서 연결했는가?
실제 작업시간과 대기시간을 구분했는가?
문제를 ‘소통 부족’이 아닌 관찰 가능한 문장으로 썼는가?
현상·직접 원인·구조적 원인·근본 문제를 구분했는가?
안전·계약·원가의 치명적 위험을 점수와 별도로 검토했는가?
해결 도구보다 필요한 역할을 먼저 정의했는가?
SECTION 08
사람·코딩 시스템·맞춤 AI 에이전트의 역할 배치
문제 해결에 필요한 역할을 먼저 정의하고 업무규칙을 정한 뒤, 확정적인 업무는 코딩 시스템에, 해석·추론은 맞춤 AI 에이전트에, 예외판단과 최종 책임은 사람에게 배치합니다.
1. AX에서 역할 배치란?
AX의 목적은 사람이 AI 도구를 잘 사용하는 데 있지 않습니다. 고객가치를 만드는 업무체계 안에서 필요한 역할을 정의하고, 업무규칙·코딩 시스템·맞춤 AI 에이전트·사람이 각자의 기능과 책임을 갖도록 조직을 다시 설계하는 데 있습니다.
해결할 문제→필요 역할→행동 분해→업무규칙→수행방식 배치→권한·통제·책임
2. 기능과 역할은 다르다
기능 중심 표현
역할 중심 표현
문서를 요약한다
현장보고에서 경영자가 확인해야 할 위험과 결정을 추출한다
견적서를 작성한다
도면·단가·과거 견적을 바탕으로 초안을 만들고 누락을 점검한다
자료를 검색한다
최신 승인자료와 과거 사례를 근거와 함께 제공한다
일정을 알려준다
지연 가능성을 감지하고 조정이 필요한 일정을 보고한다
기능은 AI가 무엇을 할 수 있는지를 말하고, 역할은 누구를 위해 어떤 결과를 만들며 어디까지 책임지는지를 말합니다.
3. 역할 정의의 여섯 요소
역할 목적어떤 고객가치와 조직성과에 기여하는가?
입력정보어떤 데이터·문서·요청이 필요한가?
수행업무무엇을 판단·작성·분류·추적하는가?
결과물누구에게 어떤 형태로 제공하는가?
권한 범위조회·작성·수정·전달·실행 중 어디까지인가?
검토와 책임누가 검토하고 최종 책임지는가?
○○ 역할은 [고객가치]를 위해 [입력정보]를 바탕으로 [업무]를 수행하고 [대상]에게 [결과물]을 제공한다. 권한 밖의 사항은 [책임자]의 승인을 받는다.
4. 네 가지 관점을 구분한다
구분
의미
적합한 일
책임
업무규칙
사람·시스템·AI가 따라야 할 기준과 조건
시작·완료 조건, 계산식, 승인한도, 중단·예외 기준
조직이 기준의 적정성을 책임
코딩 시스템
확정된 규칙을 프로그램으로 동일하게 실행
계산·상태·버전·권한·차단·기록·알림
개발·운영 역할이 정상작동 관리
맞춤 AI 에이전트
도메인 지식으로 문서와 상황을 해석·비교·추론
요구 구조화, 누락·불일치 탐지, 근거·대안 제시
독립적인 법적·경영 책임 불가
사람
목표·맥락·예외·협상·승인 판단
고객관계, 중요 결정, 갈등 조정, 최종 승인
조직적 최종 책임 담당
업무규칙은 수행 주체가 아니라 모든 수행 주체가 따라야 할 운영기준입니다. 코딩 시스템과 맞춤 AI 에이전트는 서로 다른 방식으로 역할을 수행하고, 사람은 예외와 최종 결과를 책임집니다.
5. 코딩 자동화와 AI 자율성을 구분한다
배치 수준
실제 수행
사람의 역할
예시
규칙 자동화
코딩 시스템이 정해진 조건을 동일하게 실행
규칙 승인·예외 처리
계약금 입금일 알림, 미승인 발송 차단
AI 보조
맞춤 AI가 자료·초안·검색결과 제공
전체 검토·완성
견적 설명자료 초안
AI 분석·협업
맞춤 AI가 비교·분류·추천하고 사람과 반복
진위 확인·선택·피드백
누락 후보 검토·수정
사람 승인 후 실행
AI가 실행안을 만들고 코딩 시스템이 승인상태 확인 후 실행
사전 승인
승인된 고객안내 발송
제한적 자동실행
정해진 저위험 범위에서 AI와 시스템이 실행
예외·성과 감독
일반 문의 분류와 담당자 배정
정해진 규칙을 항상 같은 결과로 실행하는 일은 AI보다 코딩 시스템에 적합합니다. AI의 자율성이 높아져도 접근권한·승인상태·실행차단·기록은 코딩 시스템이 통제하고, 목표·중단조건·보고시점·검토책임자는 사람이 정합니다.
6. 인테리어 회사의 역할 배치 사례
업무
업무규칙
코딩 시스템
맞춤 AI 에이전트
사람 역할·책임
성과지표
견적 공종 누락
승인 도면·필수공종·유효단가로 검수
최신 도면과 견적 버전 연결·검수이력
도면·수량표·견적항목의 누락·불일치 탐지
실제 누락·단가 판단, 견적책임자 승인
누락률·재견적시간
이전 도면 사용
승인된 최신본만 사용
최신본 지정·이전본 잠금·배포기록
변경 차이와 영향 항목·근거 제시
적용본·공사비·공정 영향 확정
버전 오류·재시공
고객 반복 문의
승인된 현황만 정해진 주기로 안내
자료수집·상태·발송 일정 관리
사진·작업기록으로 보고서 초안
심각성·설명 내용 판단, 현장책임자 승인
재문의율·보고지연
7. 맞춤 AI 에이전트 권한을 단계별로 설계한다
단계
허용 범위
예시
1. 조회
자료를 읽고 검색
과거 견적 검색
2. 제안
초안과 선택안 제시
누락 의심 항목 제안
3. 작성
승인 전 문서 생성·수정
견적 초안 작성
4. 전달
지정된 내부 대상에게 전달
지연 위험 보고
5. 실행
외부 전송·발주·예약 수행
승인된 고객안내 발송
6. 제한적 결정
정해진 범위의 결정
기준 내 일반 문의 처리
책임 원칙 계약·금액·안전·법률·대외 약속은 AI가 초안을 만들더라도 권한을 가진 사람의 승인을 남깁니다.
8. 사람·코딩 시스템·맞춤 AI 사이의 인계
인계 방향
인계물
완료 조건
사람 → 코딩 시스템
고객 요구·승인자료·처리기준
필수정보·승인상태·적용버전이 기록된다
코딩 시스템 → 맞춤 AI
같은 프로젝트로 연결된 요구·도면·산출표·견적
분석할 자료와 버전이 하나로 확정된다
맞춤 AI → 사람
이상항목·위치·근거·불확실성·추천안
사람이 원자료로 재검증할 수 있다
사람 → 코딩 시스템
수정·예외판단·승인·반려
결정 내용·책임자·이유가 기록된다
코딩 시스템 → 고객·사람
승인 결과물·완료·지연·오류 알림
권한·상태·최종본·수신자가 확인된다
9. 보고와 중단 조건
즉시 보고금액·원가 기준 이탈, 안전·법적 위험, 고객 약속 변경, 승인자료 불명, 충돌 지시, 권한 밖 실행
정기 보고진행률, 지연, 반복 오류, 고객 불만, 절감 성과, 새 조직지식
자체 처리기준이 명확한 분류, 승인 양식 정리, 상태 확인, 내부 알림과 기록
10. 역할책임표(RACI)로 책임을 명확히 한다
구분
의미
AI 배치 원칙
R — Responsible
업무 수행자: 실제로 업무를 처리
AI가 맡을 수 있음
A — Accountable
최종 책임자: 승인하고 결과를 책임짐
중대한 판단은 권한 있는 사람이 담당
C — Consulted
사전 협의자: 판단 전에 의견 제공
AI가 근거·대안을 제공할 수 있음
I — Informed
결과 공유 대상: 진행과 결과를 전달받음
맞춤 AI·코딩 시스템이 자동 통보 가능
11. 역할 배치표
문제
필요 역할
수행방식
결과물
권한
책임자
지표
견적 누락
문서 간 누락 점검
맞춤 AI 에이전트
누락 의심 목록·근거
조회·제안
견적책임자
누락률
승인 대기
승인기준 실행·경로 통제
코딩 시스템
승인 요청·이력
전달·차단
대표
승인시간
도면 혼선
최신본 통제·차이 탐지
코딩 시스템+맞춤 AI
최신본·차이·근거
내부 배포·제안
설계책임자
버전 오류
12. AI 바이브코딩은 코딩 시스템의 개발방법이다
AI 바이브코딩(AI Vibe Coding)은 원하는 업무흐름·화면·규칙을 자연어로 설명하고 AI의 도움을 받아 프로그램을 설계·수정하는 개발방식입니다. 접수화면·필수자료 확인·계산·승인경로·대시보드·버전·이력·알림·AI 검토화면을 빠르게 프로토타입으로 만들 수 있습니다.
바이브코딩은 업무를 수행하는 조직 역할이나 미래형 청사진의 레인이 아닙니다. 바이브코딩으로 개발된 코딩 시스템이 운영 중에 업무규칙을 실행합니다. 맞춤 AI 에이전트 개발과도 구분하며, 실제 운영 전에는 계산 정확성·권한·보안·오류처리·백업·유지보수·복구절차를 검증합니다.
AX 제안 문장
견적 접수·계산·승인·버전·발송·이력관리 영역은 업무규칙 기반 코딩 시스템으로 설계하고, 초기 검증용 시스템은 AI 바이브코딩을 활용해 신속하게 프로토타입으로 구축한다.
여덟 번째 원칙 AX는 사람의 업무 일부를 AI에 넘기는 작업이 아닙니다. 고객가치를 중심으로 업무규칙을 정하고, 코딩 시스템·맞춤 AI 에이전트·사람의 역할·권한·인계·책임을 다시 설계하는 일입니다.
강의 점검 질문
AI 기능이 아니라 고객가치에 기여하는 역할로 정의했는가?
입력·결과물·권한·검토자·성과지표가 명확한가?
사람과 AI 사이의 인계물과 완료 조건이 있는가?
업무규칙과 코딩 시스템, 맞춤 AI 에이전트가 구분되어 있는가?
바이브코딩을 역할이 아니라 코딩 시스템 개발방법으로 정의했는가?
즉시 보고와 자체 처리의 경계가 정해졌는가?
최종 책임자 A가 사람으로 명확하게 지정됐는가?
SECTION 09
미래형 서비스 청사진 설계
현재 문제를 고치는 수준을 넘어 고객가치가 더 잘 만들어지도록 고객경험·업무규칙·코딩 시스템·맞춤 AI 에이전트·사람의 역할과 책임을 다시 설계합니다.
1. 현재 상태와 미래 상태
구분
현재 상태(As-Is)
미래 상태(To-Be)
목적
실제 작동 방식과 문제 파악
개선된 고객경험과 업무체계 설계
고객
대기·불안·반복 행동
줄어든 노력과 명확한 판단 근거
조직
현재 역할·인계·승인
업무규칙·코딩 시스템·맞춤 AI·사람의 새로운 역할
성과
현재 시간·오류·비용
목표 시간·품질·비용
현재 상태는 단순한 문제 목록이 아니라 AI 도입 효과를 비교하기 위한 기준선입니다. 누가 어떤 일을 하고, 얼마나 시간이 걸리며, 어디에서 오류·대기·재작업이 발생하고, 누가 판단과 책임을 맡는지 기록해야 합니다. 이 기준선이 없으면 일반적인 업무개선 효과와 AI 도입으로 생긴 효과를 구분할 수 없습니다.
2. 현재 조직의 역할을 기준선으로 기록한다
현재 역할·업무
업무량·시간
오류·대기·재작업
권한·책임
현재 성과지표
견적 담당자가 도면과 내역을 전수 비교
건당 4시간
누락 재검토·수정 견적
담당자 검토, 대표 최종 승인
리드타임 5일·누락률 8%
기준선은 직무명만 적는 표가 아닙니다. 현재 사람이 수행하는 활동, 판단, 인계, 승인, 책임과 그 결과를 함께 기록합니다. 이후 AI가 맡을 역할과 사람이 계속 맡을 역할을 비교해야 제거·축소·강화·창조의 변화와 효과를 설명할 수 있습니다.
3. 목표 고객가치에서 시작한다
우리는 [고객]이 [과정]에서 겪는 [문제]를 줄이고 [새로운 경험과 가치]를 제공한다.
견적 서비스 목표
사무실 인테리어를 검토하는 경영자가 견적 범위와 추가비용을 불안해하는 문제를 줄이고, 상담 후 3일 안에 근거가 명확하고 비교 가능한 견적을 받도록 한다.
4. 고객 행동과 내부 흐름을 함께 바꾼다
현재 흐름
미래 흐름
고객이 같은 요구를 반복 설명
최초 입력정보를 확인·수정하면 후속 단계에 연결
진행상태를 전화로 문의
현재 단계와 완료 예정일을 직접 확인
담당자가 과거 견적·단가를 개별 검색
AI가 유사 견적과 최신 단가를 근거와 함께 제공
모든 견적을 대표가 승인
기준 이내는 책임자, 예외만 대표가 승인
여러 채널로 도면 배포
승인된 최신본만 공식 배포
5. 정상 흐름과 예외 흐름
정상 업무뿐 아니라 필수자료 부족, 단가정보 노후, 이윤기준 이탈, 상충 지시, 안전·법률 검토 같은 예외를 함께 설계합니다. 예외 발생 시 AI의 중단 여부, 보고 대상, 전달 근거, 재개 승인자를 정합니다.
6. 미래형 청사진 작성표
여정
목표 고객경험
업무규칙
코딩 시스템
맞춤 AI 역할
사람 역할
데이터
예외·지표
상담
한 번만 설명
필수정보·확인기준
접수·상태·후속단계 연결
내용 구조화·누락 질문
숨은 요구 판단
고객관계관리·상담기록
정보 부족·반복 설명 횟수
견적
3일 안에 근거 있는 견적
적용도면·단가·이윤·승인기준
버전·계산·승인경로·이력
사례검색·누락·불일치 탐지
단가·예외·이윤 판단
단가DB·과거 견적
이윤 이탈·리드타임·누락률
시공
진행상황을 안심하고 확인
보고주기·변경·안전기준
공정·도면상태·발송통제
사진·기록 요약·위험 신호
문제 설명·대안 결정
공정·도면·현장기록
일정·안전 위험·고객 재문의
7. 서비스 청사진과 상세 구현설계의 경계를 지킨다
서비스 청사진에는 고객가치와 연결되는 업무규칙, 코딩 시스템의 자동행동, 맞춤 AI의 해석·추론, 사람의 판단·책임을 서비스 수준에서 표시합니다. 세부 계산식·조건문·상태 전환·장애복구·기술적 인계는 프로세스 청사진에서 상세화합니다.
8. 단계적으로 구현한다
업무규칙 정립→데이터·버전 정비→바이브코딩 시스템→맞춤 AI 연결→통합 PoC→조직 학습
아홉 번째 원칙 미래형 청사진은 현재 업무에 AI를 붙이는 그림이 아니라 고객가치가 더 잘 만들어지도록 업무규칙·코딩 시스템·맞춤 AI 에이전트·사람이 협업하는 전체 업무체계를 다시 설계하는 그림입니다.
SECTION 10
ERRC 분석과 AX 실행과제
현재 조직의 역할과 성과를 기준으로 AI 역할이 도입되었을 때 무엇이 제거·축소·강화·창조되는지 분석하고, 그 차이를 측정 가능한 AI 도입 효과로 정의합니다.
1. ERRC의 네 방향
구분
한글 의미
핵심 질문
Eliminate
제거
고객가치와 위험관리에 기여하지 않아 없앨 일은?
Reduce
축소
횟수·시간·단계·비용을 줄일 일은?
Raise
강화
고객가치와 성과를 위해 더 잘해야 할 일은?
Create
창조
새롭게 만들 고객경험·역할·체계는?
ERRC는 미래 아이디어만 적는 표가 아닙니다. 현재 조직의 역할과 업무를 기준점으로 놓고 AI 역할 도입 전후의 차이를 설명하는 비교 분석입니다.
2. AI 도입 효과를 만드는 인과관계
현재 역할·성과→AI 역할 도입→ERRC 변화→사람 역할 변화→도입 효과
AI 도입 효과는 ‘AI를 사용했다’는 사실이 아니라 위 인과관계의 마지막에 나타난 변화입니다. 따라서 모든 효과에는 도입 전 기준값, 목표값, 측정방법이 있어야 합니다.
3. 변화의 원인을 구분한다
변화 구분
의미
예시
AI 없이도 가능한 변화
표준화·권한 위임·절차 단순화만으로 가능한 개선
대표의 전건 승인을 금액 기준 승인으로 변경
AI가 직접 가능하게 한 변화
대량 비교·분류·탐지·추천처럼 AI 역량이 직접 만든 변화
도면과 견적서의 누락 의심 항목 자동 탐지
사람과 AI의 결합으로 실현되는 변화
AI의 제안과 사람의 판단·책임을 함께 재설계해야 생기는 변화
AI가 예외를 선별하고 책임자가 고위험 건만 판단
일반 업무개선 효과를 모두 AI의 성과로 계산해서는 안 됩니다. 반대로 AI 기능이 있어도 사람의 권한·책임·인계 방식이 바뀌지 않으면 조직성과로 이어지지 않을 수 있습니다.
4. 기존 역할을 업무규칙과 수행방식으로 재배치한다
업무
업무규칙
코딩 시스템
맞춤 AI 에이전트
도입 후 사람의 역할
요구사항 정리
필수정보·확인·완료기준
상담정보 저장·후속단계 연결
상담 내용을 구조화하고 빠진 질문 제안
숨은 요구와 우선순위를 판단·확정
견적 검수
적용도면·필수공종·유효단가 기준
자료·버전 연결과 검수이력 기록
누락·불일치 의심 항목과 근거 선별
실제 누락 여부와 금액·예외 판단
견적 승인
금액·이윤율별 승인권한과 제출조건
자동계산·승인경로·미승인 발송 차단
기준 이탈 원인과 조정안 추천
정상 건 승인, 대표는 고위험 예외 결정
지식 활용
공식 자료·유효기간·갱신책임
검색·버전·접근권한·사용이력 관리
유사 사례·최신 단가·적용 근거 추천
조건의 적합성과 최종 단가·이윤 결정
5. 견적 프로세스 ERRC 분석
업무
제거
축소
강화
창조
측정할 효과
요구사항 정리
동일 고객정보의 반복입력
반복 설명과 재확인
요구 누락 확인
AI 누락 질문과 상담정보 연결
반복 설명 횟수·입력 오류율
견적 검수
사람이 수행하던 기계적 대조
전수 반복검토 시간
근거 확인과 예외 판단
AI 누락 탐지와 검수 이력 축적
검토시간·누락률·재작업률
견적 승인
관행적인 대표 전건 승인
대표 승인 건수와 대기
고위험 건의 판단 품질
위험기반 예외 승인 체계
대표 승인 비율·승인시간
지식 활용
개인별 파일 탐색과 임의 자료 배포
자료 검색시간
단가 근거와 최신본 통제
사례 추천과 피드백 지식화
검색시간·버전 오류·견적 편차
6. AI 도입 효과를 세 층위로 정의한다
효과 층위
확인할 변화
견적 업무 예시
핵심성과지표(KPI) 예시
고객가치 효과
고객의 시간·노력·불안·신뢰가 어떻게 달라지는가?
더 빠르고 근거가 명확한 견적
견적 리드타임·고객 재문의·만족도
조직성과 효과
시간·비용·오류·품질·위험이 어떻게 달라지는가?
누락과 재작업 감소, 승인 병목 해소
누락률·재작업률·승인시간·원가 편차
역할·인적자원 효과
사람이 어떤 반복업무에서 벗어나 어떤 판단·책임을 강화하는가?
전수 확인자에서 예외 판단자·지식 책임자로 전환
반복업무 시간·대표 승인 비율·예외 처리 품질
AI 도입 효과 문장은 다음처럼 작성합니다.
“현재 [사람·조직]이 [업무]를 수행해 [현재 지표]가 발생한다. [AI 역할]을 도입하여 [제거·축소·강화·창조]하고, 사람은 [새 역할]에 집중한다. 그 결과 [고객·조직·역할 지표]를 [목표값]으로 개선한다.”
7. ERRC 결과를 구현방식으로 전환한다
ERRC로 발견된 변화
필요한 역할
구현방식
반복 입력 제거
고객정보 연결·상태관리
코딩 시스템
대표 전건 승인 축소
기준별 승인경로·발송 통제
업무규칙+코딩 시스템
누락 검수 강화
문서 의미 비교·이상 탐지
맞춤 AI 에이전트
예외판단 강화
고위험 항목 판단·승인
사람
오류 지식축적 창조
오류이력·패턴분석·기준 개선
코딩 시스템+맞춤 AI+운영책임자
이 단계에서 바이브코딩은 역할이 아니라 코딩 시스템을 빠르게 프로토타입으로 개발하는 방법으로 제안합니다.
8. 실행과제 문장
[문제]를 해결하기 위해 [역할]을 구축한다. [수행자]가 [업무]를 하고 [책임자]가 승인하며 [성과지표]로 검증한다.
9. 우선순위와 선행관계
고객가치 영향, 조직성과, 위험 감소, 실행 가능성, 학습 가치를 각각 평가합니다. 다만 안전·법률·대규모 손실 위험은 합계점수와 관계없이 우선합니다.
업무규칙→버전·데이터 정비→코딩 시스템→맞춤 AI 검수→사람 역할 전환→피드백 축적
강의 점검 질문
현재 조직에서 누가 무엇을 하고 어떤 책임을 지는지 기준선을 기록했는가?
AI가 맡을 역할과 도입 후 사람이 맡을 역할이 구분되어 있는가?
업무규칙·코딩 시스템·맞춤 AI 에이전트 중 적합한 구현방식을 정했는가?
제거·축소·강화·창조가 AI 도입 전후의 차이로 설명되는가?
일반적인 프로세스 개선 효과와 AI가 직접 만든 효과를 구분했는가?
고객가치·조직성과·역할 변화의 지표에 현재값과 목표값이 있는가?
열 번째 원칙 ERRC는 업무를 단순히 없애거나 추가하는 표가 아닙니다. 현재 조직을 기준으로 AI 역할 도입이 무엇을 바꾸고, 사람의 역할과 고객·조직의 성과를 어떻게 변화시키는지 밝히는 전략 분석입니다.
SECTION 11
AX 제안서 완성하기
진단·역할설계·미래형 청사진·실행과제를 경영자의 의사결정을 이끄는 하나의 제안 논리로 완성합니다.
1. 주요 용어
용어·약자
영문 원어
한글 해석과 실무 의미
AX
AI Transformation
인공지능 기반 조직 전환: AI를 조직의 역할로 배치해 업무체계를 바꾸는 것
RACI
Responsible·Accountable·Consulted·Informed
수행·최종책임·사전협의·결과공유 역할을 구분하는 방법
PoC
Proof of Concept
개념검증·사전 실증: 본격 구축 전 작은 범위에서 효과와 위험을 시험
KPI
Key Performance Indicator
핵심성과지표: 변화의 성과를 판단하는 핵심 수치
CRM
Customer Relationship Management
고객관계관리: 문의·상담·견적·계약·A/S 상태 관리
ERP
Enterprise Resource Planning
전사적 자원관리: 회계·구매·재고·인사·원가 통합관리
업무규칙
Business Rule
사람·시스템·AI가 따라야 할 시작·판단·승인·중단·완료 기준
코딩 시스템
Coded System
확정된 업무규칙을 계산·상태·권한·차단·기록으로 실행하는 프로그램
AI 바이브코딩
AI Vibe Coding
자연어와 AI의 도움으로 업무시스템을 설계·수정하는 개발방법
맞춤 AI 에이전트
Custom AI Agent
역할·도메인 지식·도구·권한·보고체계를 결합한 AI 업무 수행자
2. 제안서의 목적과 고객
AX 제안서는 AI 기능을 소개하는 문서가 아니라 최종 고객가치를 중심으로 조직의 역할과 업무체계를 다시 설계하는 경영 제안서입니다.
대상
의미
핵심 질문
1차 고객
AX 코칭을 의뢰한 경영자·임원
어떤 경영문제를 해결하려는가?
내부 사용자
새 업무체계에서 일할 직원
어떤 역할과 책임을 수행하는가?
최종 고객
조직의 제품·서비스 구매자
이 변화로 어떤 가치를 얻는가?
직원이 AI를 잘 쓰게 하는 데서 멈추지 않고, 직원과 AI의 역할 변화가 최종 고객에게 어떤 가치를 만드는지 설명해야 합니다.
3. 제안서 기본 논리
최종 고객가치→현재 조직 기준선→구조적 원인→필요 역할·업무규칙→시스템·AI·사람 배치→ERRC 변화→PoC→효과·경영자 결정
4. 최종 목차
장
내용
결과물
1~2
제안 개요·최종 고객가치
제안 범위와 고객가치
3~5
현재 상태·현재형 청사진·구조적 원인
조직진단 결과
6~7
AX 목표·미래형 청사진
목표 업무체계
8~9
역할책임·ERRC·구현방식 분석
업무규칙·코딩 시스템·맞춤 AI·사람의 배치와 도입효과
10~12
로드맵·PoC·성과검증·위험관리
기준값·목표값·구축계획·통제방안
13
최종 제안
경영자 의사결정안
5. 역할책임표(RACI)
구분
한글 뜻
AI 배치 원칙
R — Responsible
실제 업무 수행자
AI가 맡을 수 있음
A — Accountable
최종 책임자·승인자
계약·금액·안전은 권한 있는 사람이 담당
C — Consulted
사전 협의자
AI가 근거와 대안을 제공할 수 있음
I — Informed
결과 공유 대상
AI·시스템이 자동 통보 가능
6. 개념검증(PoC)
개념검증(PoC: Proof of Concept)은 본격적인 투자 전에 실제 자료와 제한된 업무범위에서 효과와 위험을 시험하는 과정입니다. 현재 방식과 AI 도입 방식을 같은 지표로 비교하여 효과가 AI 역할에서 비롯되었는지 검증합니다.
단순 시험사용
개념검증
기능을 사용하고 느낌으로 평가
업무·기간·권한·지표·성공·중단 기준을 정해 검증
견적검수 개념검증
완료 견적 20건을 대상으로 AI가 누락 의심 항목만 제안하고 견적책임자가 판정합니다. 탐지율·잘못된 경고·검토시간·수정률을 측정하며, 중대한 금액오류나 기밀유출 위험이 발생하면 중단합니다.
검증 영역
확인할 질문
업무규칙
적용도면·단가·검수·승인·중단 기준이 명확하고 실제 적용 가능한가?
AI 바이브코딩 기반 코딩 시스템
버전·계산·상태·권한·발송 차단·기록을 정확히 실행하는가?
맞춤 AI 에이전트
문서의 누락·불일치를 원자료 위치와 근거를 제시하며 탐지하는가?
사람의 역할 전환
담당자가 AI 결과를 검증하고 반복업무 대신 예외·승인 판단에 집중하는가?
바이브코딩으로 만들더라도 검증은 생략하지 않습니다. 업무규칙의 적정성과 계산·권한·차단 기능을 별도로 검증해야 합니다.
7. 핵심성과지표(KPI)
핵심성과지표(KPI: Key Performance Indicator)는 AI 사용량이 아니라 고객과 조직의 결과가 달라졌는지를 측정합니다. 도입 전 기준값과 도입 후 목표값을 함께 두고 고객가치·조직성과·역할 변화를 구분해 측정합니다.
지표
현재
목표
측정방법
견적 리드타임
평균 5일
평균 3일
접수일~제출일
견적 누락률
8%
2% 이하
수정·추가 견적 건수
대표 승인 비율
100%
20% 이하
승인기록
고객 재문의
건당 3회
1회 이하
전화·메신저 기록
8. AX 제안의 다섯 가지 구현과제
제안과제
구현 내용
주요 책임 주체
업무규칙 정비
시작·계산·검수·승인·중단·완료·예외 기준 표준화
업무책임자·승인권자
AI 바이브코딩 기반 코딩 시스템 개발
접수·계산·상태·버전·권한·차단·기록·대시보드 구현
업무책임자·시스템 개발 담당자
맞춤 AI 에이전트 개발
도메인 지식 기반 해석·검색·비교·추론·근거 제시
도메인 담당자·에이전트 개발 담당자
사람의 역할 전환
반복 전수검토 축소, 고객맥락·예외·협상·승인 강화
현업 담당자·최종 책임자
운영·학습체계 구축
오탐·미탐·규칙·시스템·도메인 지식의 지속 갱신
지정된 운영 책임자
‘AI 바이브코딩 기반 코딩 시스템 개발’과 ‘맞춤 AI 에이전트 개발’은 별개의 개발과제입니다. 전자는 정해진 조건을 안정적으로 실행하고, 후자는 문서와 상황의 의미를 해석·추론합니다. 두 결과물이 실제 서비스 흐름에서 인계되고 사람의 검토·승인으로 연결되어야 합니다.
9. 위험과 경영자 결정사항
위험
통제방안
AI 오류·오래된 정보
근거·출처·유효기간 표시와 사람의 검토
기밀 유출
접근권한·저장위치·외부전송 제한
잘못된 자동실행
단계별 권한과 승인 후 실행
책임 불명확
역할책임표와 최종 책임자 지정
기술 종속
데이터 표준화와 교체 가능한 구조
경영자는 우선문제, 업무규칙의 승인, 코딩 시스템과 맞춤 AI 에이전트의 개발범위, PoC 대상, AI 권한, 책임자, 데이터 범위, 예산, 성공·중단 기준과 확대 시점을 결정해야 합니다.
열한 번째 원칙 AX 제안서는 AI 기능을 판매하는 문서가 아닙니다. 최종 고객가치를 중심으로 업무규칙을 정비하고, 코딩 시스템·맞춤 AI 에이전트·사람의 역할을 설계하여 검증 가능한 구축과제로 전환하는 경영 제안서입니다.
SECTION 12
심화과정 확장과 실전과제
기본과정의 제안서 작성 역량을 실제 조직진단·구축·검증을 수행하는 AX 컨설팅 역량으로 확장합니다.
과제
학습목표
주요 제출물
1. 고객·경영자·직원 인터뷰
요구 뒤의 고객가치와 구조적 문제 발견
대상자 지도·질문지·문제 가설·증거목록
2. 프로세스 청사진
내부 업무의 입력·처리·출력·승인·예외 진단
현재형·미래형 프로세스 청사진과 비교표
3. 역할·수행방식 배치
필요한 역할을 업무규칙·코딩 시스템·맞춤 AI·사람에 배치
역할기술서·업무규칙표·역할전환표·RACI·인계규칙
4. 데이터·지식관리
시스템과 AI가 사용할 데이터·지식·기준 정비
자산목록·버전규칙·생애주기·접근권한표
5. AX 구현설계
바이브코딩 시스템과 맞춤 AI 에이전트를 구분해 설계
시스템 기능명세·에이전트 정의서·정보흐름·보안·복구
6. 개념검증과 성과평가
규칙·시스템·AI·사람의 통합효과와 위험 검증
기준선·PoC 계획·가설·KPI·시험결과·효과 판정
7. 투자효과와 사업성
구축비용과 기대효과를 경영자 언어로 설명
비용표·효과 산정·투자회수·의사결정안
8. 조직 변화와 AI 육성
사람과 AI가 함께 성장하는 운영체계 구축
변화관리·교육·피드백·성과평가·운영회의안
9. 위험·윤리·보안·책임
오류·유출·권한 남용을 예방하는 정책 수립
위험평가·권한표·승인·중단·사고대응 절차
10. 실제 고객 제안발표
경영자의 의사결정을 받을 최종 제안 완성
진단보고서·청사진·로드맵·제안서·15분 발표자료
과제 진행 순서
진단→분석→역할 설계→기반·시스템→검증→경영성·통제→최종 제안
최종 AX 컨설팅 패키지
진단조직진단 보고서·서비스 및 프로세스 청사진·구조적 문제
설계AI 도입 전후 ERRC·업무규칙·코딩 시스템·맞춤 AI 에이전트·사람 역할 구성
검증규칙·시스템·AI·사람의 통합 PoC·고객·조직·역할별 도입 효과·투자효과·위험관리
제안단계별 실행 로드맵·최종 제안서·경영자 발표자료
과정의 최종 메시지 AX는 사람이 AI 도구를 잘 쓰는 방법을 배우는 것이 아닙니다. 최종 고객가치를 기준으로 업무를 진단하고, 업무규칙을 정비하며, 코딩 시스템·맞춤 AI 에이전트·사람의 역할·권한·책임을 다시 설계하여 고객과 조직의 성장을 만드는 경영혁신입니다.
AX코칭 전문가 과정 · MODULE 02
프로세스 청사진 작성법
업무성과를 위한 실전 교안
특정 업무의 입력·처리·판단·인계·승인·예외를 연결하고, 요구되는 업무성과를 반복해서 달성하도록 사람과 AI의 역할을 설계하는 실전 교안
프로세스 청사진 업무성과를 위한 프로세스 진단과 역할 설계
SECTION 01
프로세스 청사진의 개념과 목적
프로세스 청사진은 업무순서를 보기 좋게 그리는 문서가 아닙니다. 요구되는 업무성과를 안정적으로 반복해 만들어 내도록 업무구조를 설계하는 지도입니다.
1. 프로세스란 무엇인가?
프로세스(Process)란 특정한 성과를 만들기 위해 입력받은 정보·자원·요청을 일정한 순서와 기준에 따라 처리하여 결과물로 바꾸는 업무의 흐름입니다.
무엇을 받아서 → 누가 → 어떤 기준으로 처리하고 → 무엇을 만들어 내는가?
프로세스는 단순한 업무순서가 아닙니다. 요구되는 결과와 품질을 반복해서 만들어 내는 체계입니다.
에스유디자인 견적 프로세스 사례
구성요소
내용
입력
고객 요구사항, 현장정보, 도면, 공사범위
수행자
영업담당자, 설계담당자, 견적담당자, 대표
활동
요구사항 확인, 수량산출, 단가적용, 원가검토, 승인
기준
견적기준, 목표이윤율, 최신 단가, 승인 권한
출력
고객에게 제출할 승인된 견적서
업무성과
정확한 견적을 약속된 기한 안에 제출
2. 프로세스 청사진이란?
프로세스 청사진(Process Blueprint)은 특정 업무가 시작되어 결과물이 완성될 때까지 업무성과를 만들어 내는 요소를 한눈에 연결한 업무 설계도입니다.
입력과 시작조건어떤 요청·자료·상태가 갖춰져야 업무가 시작되는가?
활동과 수행자누가 무엇을 어떤 순서로 처리하는가?
판단과 통제어떤 기준으로 판단·검토·승인하는가?
인계와 정보누구에게 무엇을 어떤 완료조건으로 넘기는가?
예외와 대응오류·반려·변경이 발생하면 누가 어떻게 대응하는가?
출력과 성과무엇이 완성되어야 하며 어떤 지표로 성과를 판단하는가?
누가 수행해도 요구되는 업무성과를 안정적으로 만들 수 있도록 업무의 흐름·기준·책임·통제를 명확하게 만드는 문서입니다.
3. 프로세스 청사진의 직접적인 목적
프로세스 청사진의 직접적인 목적은 업무성과 향상입니다. 여기서 업무성과란 매출 같은 최종 경영성과만이 아니라 해당 프로세스가 책임져야 할 구체적인 결과를 뜻합니다.
업무성과
확인 질문
품질
결과물이 요구기준을 충족했는가?
정확성
오류·누락·잘못된 판단이 없는가?
처리시간·납기
약속된 날짜와 시간 안에 완료했는가?
비용·생산성
불필요한 자원과 비용을 줄이고 필요한 결과를 만들었는가?
안전·규정준수
사고 예방과 법률·계약·내부기준을 지켰는가?
재작업
같은 일을 반복하거나 다시 수정하지 않았는가?
“견적서를 작성했다”는 활동의 완료일 뿐 업무성과가 아닙니다. “누락 없이 적정 이윤을 반영한 견적서를 약속된 기한 안에 승인하여 고객에게 제출한다”처럼 결과물·품질·시간·비용이 드러나야 합니다.
4. 서비스 청사진과 무엇이 다른가?
구분
서비스 청사진
프로세스 청사진
목적
고객가치와 고객경험 향상
업무성과 향상
출발점
고객이 이루려는 목적
업무의 시작조건과 요구결과
중심 대상
고객 행동과 조직 활동의 연결
내부 업무의 처리와 통제 구조
분석 범위
고객의 전체 서비스 여정
특정 업무 프로세스
핵심 질문
고객에게 어떤 가치를 제공해야 하는가?
어떤 성과를 어떻게 안정적으로 만들 것인가?
주요 문제
불안, 불편, 대기, 신뢰 저하
오류, 누락, 병목, 재작업, 책임 불명확
주요 지표
만족도, 고객 노력, 재문의, 신뢰
처리시간, 오류율, 생산성, 원가, 납기
결과물
고객가치 중심의 서비스 구조
성과 중심의 업무 실행 구조
5. 같은 견적 업무를 바라보는 두 관점
서비스 청사진의 질문
고객은 견적서로 무엇을 판단하려는가?
공사범위와 추가비용을 충분히 이해하는가?
기다리는 동안 불안하지 않은가?
견적 경험이 회사에 대한 신뢰를 높이는가?
↔
프로세스 청사진의 질문
필요한 정보가 빠짐없이 접수되는가?
수량과 단가는 누가 어떤 기준으로 검토하는가?
어떤 견적을 누가 승인해야 하는가?
누락·재작업은 어디에서 발생하는가?
약속된 제출기한을 지키는가?
서비스 청사진에서는 고객이 견적을 통해 얻는 가치가 중심이고, 프로세스 청사진에서는 정확한 견적을 기한 안에 만들어 내는 업무성과가 중심입니다.
6. 두 청사진은 어떻게 연결되는가?
고객가치: 빠르고 이해하기 쉬운 견적→업무성과: 정확한 견적을 3일 안에 제출→업무설계: 확인·산출·검토·승인·제출
서비스 청사진이 고객가치의 방향을 제시하면 프로세스 청사진은 그 가치를 뒷받침하는 업무성과를 구현합니다. 다만 프로세스 청사진의 직접적인 작성 목적과 측정 대상은 업무성과입니다.
성과지표
현재
목표 예시
견적 제출시간
평균 5일
평균 3일
견적 누락률
8%
2% 이하
재작업 횟수
건당 2회
1회 이하
대표 승인 비율
100%
예외 견적만 승인
최신 단가·도면 적용률
측정하지 않음
100%
7. 업무 목록·플로차트·매뉴얼과의 차이
구분
설명
핵심 질문
업무 목록
해야 할 업무를 나열
무엇을 해야 하는가?
플로차트
업무의 순서와 분기를 표시
어떤 순서로 진행되는가?
매뉴얼·SOP
업무 수행방법과 기준을 설명
구체적으로 어떻게 해야 하는가?
일반 체크리스트
필요한 확인사항을 점검
빠뜨린 것이 없는가?
프로세스 청사진
성과를 만드는 전체 업무구조를 연결
누가 무엇을 받아 어떤 기준으로 처리하고 무엇을 넘겨 어떤 성과를 만드는가?
CAC
성과 실패를 막기 위한 결정적 행동을 확인
절대로 누락해서는 안 되는 행동이 실행됐는가?
프로세스 청사진은 다른 문서들을 대체하지 않습니다. 전체 업무구조를 먼저 보여주고 필요한 단계에 매뉴얼·양식·일반 체크리스트·CAC를 연결하는 상위 업무지도입니다.
8. 프로세스 청사진으로 발견하는 문제
업무흐름중복입력, 불필요한 승인, 업무집중, 인계 단절
성과기준완료기준 불일치, 최신본 기준 부재, 성과 미측정
책임구조수행자·승인자 혼선, 최종책임자 부재, AI 검토자 미지정
예외처리자료 부족, 기준 이탈, 오류 발생 시 중단·보고·복구 절차 부재
9. 프로세스 청사진과 CAC의 관계
CAC(Critical Action Checklist, 크리티컬 액션 체크리스트)는 프로세스 안에서 업무성과를 지키기 위해 반드시 실행해야 하는 핵심 행동을 관리합니다.
업무 활동
CAC 후보
판단 이유
견적서 표지 디자인을 정리한다
낮음
누락되어도 견적의 핵심성과에 미치는 영향이 작음
고객의 최종 요구사항을 확인한다
높음
누락되면 견적범위 오류와 재작업 발생
승인된 최신 도면인지 확인한다
높음
잘못된 도면은 수량과 금액 오류로 연결
목표 이윤율 충족 여부를 확인한다
높음
누락되면 회사 손실로 연결
제출 전 제외사항을 확인한다
높음
누락되면 분쟁과 추가비용 문제 발생
프로세스 청사진은 업무성과가 만들어지는 전체 구조이고, CAC는 그 성과의 실패를 막는 핵심 통제장치입니다.
10. 프로세스 청사진 작성의 전체 흐름
분석할 프로세스를 선택합니다.
시작점과 종료점을 정합니다.
요구되는 결과물과 업무성과를 정의합니다.
실제 업무단계와 담당자를 조사합니다.
입력·활동·판단·승인·인계·출력을 연결합니다.
대기·병목·누락·재작업·예외를 찾습니다.
성과에 결정적인 행동을 찾아 CAC로 작성합니다.
사람·AI·시스템의 역할과 책임을 배치합니다.
미래형 프로세스와 성과지표를 설계합니다.
AX 실행과제와 개념검증(PoC)으로 전환합니다.
SECTION 01 핵심 원칙 서비스 청사진은 고객가치를 설계하고, 프로세스 청사진은 그 가치를 뒷받침하는 업무성과가 반복적으로 달성되도록 업무체계를 설계합니다.
프로세스 청사진의 중심은 업무순서를 예쁘게 그리는 것이 아니라 결과물·성과기준·책임·인계·예외·통제를 명확하게 만드는 것입니다.
이해 점검
프로세스 청사진의 직접적인 목적이 고객경험이 아니라 업무성과인 이유는 무엇인가?
우리 조직에서 업무성과가 가장 불안정한 프로세스는 무엇인가?
그 프로세스가 반드시 만들어야 할 결과물과 성과는 무엇인가?
현재 그 성과가 달성됐는지를 어떤 지표로 판단하고 있는가?
SECTION 02
분석할 프로세스의 범위 정하기
프로세스의 범위는 부서나 업무 분야가 아니라, 하나의 결과물과 업무성과를 책임질 수 있는 시작점과 종료점으로 정합니다.
1. 프로세스 범위란?
프로세스 범위(Process Scope)란 분석하려는 업무의 시작점과 종료점, 포함 업무와 제외 업무를 정한 경계입니다.
범위가 명확하지 않으면 고객상담·설계·견적·계약·시공·수금이 한 장에 섞여 각 업무의 성과와 책임을 구체적으로 진단할 수 없습니다.
프로세스 범위를 정하는 것은 업무를 작게 보는 일이 아니라, 하나의 성과를 책임질 수 있는 단위로 업무를 잘라내는 일입니다.
구성요소
핵심 질문
프로세스명
어떤 결과를 만드는 업무인가?
목적
이 프로세스는 어떤 업무성과를 만들어야 하는가?
시작 조건
어떤 사건이나 요청이 발생하면 시작되는가?
종료 조건
어떤 결과물이 어떤 상태가 되면 끝나는가?
포함·제외 범위
이번 분석에서 어디까지 다루고 무엇을 다루지 않는가?
프로세스 책임자
전체 업무성과를 책임지는 사람은 누구인가?
성과지표
무엇을 측정해 성공 여부를 판단하는가?
2. 프로세스명은 결과가 드러나게 작성한다
프로세스명은 부서명이나 막연한 업무 분야가 아니라 만들어야 할 결과와 주요 행동이 드러나도록 작성합니다.
모호한 프로세스명
결과가 드러나는 프로세스명
영업 업무
신규 고객상담·요구사항 확정 프로세스
견적 업무
견적 작성·검토·승인 프로세스
현장 업무
일일 시공 진행·품질 확인 프로세스
발주 업무
자재 선정·승인·발주 프로세스
도면 관리
도면 검토·승인·최신본 배포 프로세스
A/S
하자 접수·처리·완료 확인 프로세스
3. 시작점은 관찰 가능한 사건이나 조건으로 정한다
“견적을 시작한다”처럼 추상적으로 쓰지 않고, 누가 보아도 프로세스가 시작됐다고 판단할 수 있게 작성합니다.
모호한 시작점
명확한 시작점
고객이 문의한다
영업담당자가 고객의 견적 요청서를 접수한다
견적 업무를 시작한다
요구사항·실측자료·최신 도면이 견적담당자에게 전달된다
현장을 준비한다
승인된 계약서와 착공 요청서가 현장담당자에게 전달된다
발주를 준비한다
승인된 자재목록과 발주 요청서가 구매담당자에게 접수된다
시작 조건에는 ① 어떤 사건이 발생했는지, ② 어떤 자료가 들어왔는지, ③ 누가 접수했는지가 드러나야 합니다.
4. 시작 조건과 선행 업무를 구분한다
견적 프로세스 시작 조건
고객 요구사항, 현장 실측자료, 최신 도면이 견적담당자에게 접수된다.
고객발굴·첫 상담·현장방문은 이 입력자료를 만드는 선행 업무입니다. 견적 프로세스가 결과를 받아 사용하지만 이번 분석범위에 반드시 포함할 필요는 없습니다.
견적 내부의 문제자료를 받은 뒤 확인·보완하는 절차가 문제라면 견적 프로세스에서 진단합니다.
선행 업무의 문제영업담당자의 요구사항 수집 자체가 문제라면 상담 프로세스까지 범위를 확장하거나 별도로 분석합니다.
5. 종료점은 행동이 아니라 완료 상태로 정한다
“견적서를 보낸다”라는 행동만으로 끝내지 않고, 결과물이 어떤 기준과 상태를 충족해야 완료되는지 정의합니다.
모호한 종료점
명확한 종료점
견적서를 작성한다
승인된 최종 견적서가 고객에게 제출되고 제출기록이 저장된다
도면을 배포한다
승인된 최신 도면이 관련 담당자에게 배포되고 이전본 사용이 차단된다
발주서를 보낸다
발주서가 공급업체에 전달되고 납기 확인 결과가 관리대장에 기록된다
A/S를 마친다
하자보수가 완료되고 고객의 완료 확인이 기록된다
종료 조건에는 ① 결과물, ② 품질기준, ③ 승인자·인수자, ④ 완료기록이 포함되어야 합니다.
6. 시작점과 종료점이 업무성과를 결정한다
구분
견적 프로세스 정의
시작점
고객 요구사항·실측자료·최신 도면이 견적담당자에게 접수된다
종료점
승인된 견적서가 고객에게 제출되고 제출기록이 저장된다
결과물
승인된 최종 견적서와 산출·승인·제출 기록
품질성과
공사범위·수량·단가·제외사항 누락 없음
시간성과
완전한 자료 접수 후 3영업일 이내 제출
비용성과
정해진 목표이윤율 충족
통제성과
승인권한과 최신 도면 기준 준수
이렇게 경계를 정해야 자료 확인시간·초안 작성시간·승인 대기시간·수정 횟수·누락률을 나누어 측정할 수 있습니다.
7. 프로세스의 크기를 구분한다
수준
의미
에스유디자인 사례
전체 사업 흐름
고객과 계약하고 서비스를 제공하는 전체 흐름
문의→상담→계약→시공→수금→A/S
핵심 프로세스
하나의 독립된 업무성과를 만드는 흐름
견적 작성·검토·승인
하위 프로세스
핵심 프로세스 안에서 중간결과를 만드는 흐름
수량산출, 단가적용, 원가검토
업무 활동
한 명 또는 한 시스템이 수행하는 행동
도면에서 벽체 수량을 산출한다
세부 작업
활동을 실행하는 구체적인 조작
도면 파일을 열고 벽체 길이를 측정한다
프로세스 청사진은 일반적으로 핵심 프로세스 또는 하위 프로세스 수준에서 작성합니다. 전체 사업을 한 장에 담으면 추상적이고, 마우스 클릭 같은 조작까지 담으면 구조를 파악하기 어렵습니다.
8. 적절한 범위인지 확인한다
하나의 분명한 시작 조건이 있는가?
하나의 핵심 결과물이 있는가?
종료 상태를 객관적으로 확인할 수 있는가?
전체 업무성과의 책임자를 지정할 수 있는가?
처리시간·오류율·비용 등의 지표를 측정할 수 있는가?
업무흐름을 5~15개의 주요 단계로 표현할 수 있는가?
정상적인 업무 한 건의 흐름을 설명할 수 있는가?
이 범위 안에서 개선과제를 실행할 수 있는가?
범위 조정 기준 주요 단계가 30~50개 이상이면 하위 프로세스로 나눕니다. 반대로 단계가 두세 개뿐이라 문제원인을 분석할 수 없다면 범위를 조금 넓힙니다.
9. SIPOC이란?
SIPOC은 상세 업무를 그리기 전에 프로세스의 공급자·입력·처리·출력·결과 수령자를 한눈에 정리하여 분석범위를 확인하는 방법입니다.
누가(S) 무엇을 제공하면(I), 어떤 큰 단계로 처리하여(P), 무엇을 만들고(O), 그 결과를 누가 사용하는가(C)?
영문
한글 의미
핵심 질문
S — Supplier
공급자
입력자료와 기준을 누가 제공하는가?
I — Input
입력
프로세스를 수행하려면 무엇이 필요한가?
P — Process
핵심 처리단계
입력을 어떤 큰 단계로 처리하는가?
O — Output
출력
어떤 결과물과 기록이 만들어지는가?
C — Customer
결과 수령자
그 결과물을 누가 받아 사용하는가?
SIPOC의 Customer는 최종 소비자만을 뜻하지 않습니다. 프로세스의 결과를 받아 다음 업무를 수행하는 내부 담당자·부서·후속 프로세스도 포함합니다.
서비스 청사진의 고객조직의 존재이유와 이익을 제공하는 최종 고객
SIPOC의 Customer해당 프로세스의 출력물을 받아 사용하는 내부 또는 외부 결과 수령자
10. SIPOC은 출력과 성과에서 거꾸로 작성한다
S부터 순서대로 작성하면 현재 가지고 있는 자료와 현재 하는 일에 끌려가기 쉽습니다. 프로세스 청사진에서는 요구되는 결과와 성과에서 거꾸로 작성합니다.
① 결과 수령자→② 출력물→③ 성과요건→④ 처리단계→⑤ 입력→⑥ 공급자
결과 수령자: 결과물을 누가 사용하는가?
출력: 그 사람이 받아야 할 결과물은 무엇인가?
성과요건: 결과물의 품질·시간·비용 기준은 무엇인가?
처리단계: 결과물을 만들기 위한 큰 단계는 무엇인가?
입력: 각 단계를 수행하려면 무엇이 필요한가?
공급자: 필요한 입력을 누가 제공하는가?
11. 견적 프로세스 SIPOC 사례
한 개의 가로표에서 각 행을 1:1로 연결해 읽으면 안 됩니다. 여러 공급자가 제공한 여러 입력을 전체 프로세스가 함께 처리하여 여러 결과물을 만드는 구조입니다.
고객·영업·설계·현장·구매담당자가 견적에 필요한 자료를 제공하면, 견적담당자가 자료확인·수량산출·단가적용·검토·승인을 거쳐 최종 견적서를 만들고, 고객과 후속 업무 담당자가 그 결과를 사용합니다.
11-1. 공급자와 입력자료
공급자(Supplier)
제공하는 입력(Input)
고객
원하는 공사범위, 예산, 희망일정
영업담당자
상담기록, 고객 요구사항
설계담당자
최신 도면, 마감재 정보
현장담당자
실측자료, 현장조건
구매담당자
자재단가, 협력업체 견적
회사
목표이윤율, 승인기준, 견적양식
공급자는 물건을 파는 공급업체만을 뜻하지 않습니다. 프로세스가 시작되고 수행되도록 정보·자료·기준을 제공하는 사람이나 조직입니다.
11-2. 다섯 단계의 처리과정
단계
무엇을 하는가?
1. 접수자료 확인
필수자료가 모두 있는지 확인하고 누락자료의 보완을 요청한다
2. 공사범위·수량 산출
도면과 현장정보를 기준으로 공사항목을 나누고 수량을 계산한다
3. 단가·원가 적용
자재비·노무비·외주비와 최신 단가를 반영한다
4. 누락·수익성 검토
빠진 항목, 목표이윤율, 제외사항과 별도공사를 확인한다
5. 승인·제출
승인권자가 검토한 견적서를 고객에게 제출하고 기록을 저장한다
SIPOC의 Process에는 처음부터 모든 세부작업을 적지 않습니다. 전체 흐름을 5~7개의 큰 단계로 요약하고 이후 섹션에서 세부 활동으로 나눕니다.
11-3. 출력물과 결과 수령자
출력(Output)
결과 수령자(Customer)
사용 목적
승인된 최종 견적서·제외사항
최종 고객
공사범위와 금액을 검토하고 계약 여부를 판단
승인된 견적서
영업담당자
고객에게 견적내용과 조건을 설명
견적서·공사범위
계약담당자
계약서를 작성하고 계약범위를 확정
수량·산출근거·공사범위
현장담당자
실행예산과 시공범위를 확인
원가·이윤·승인기록
재무담당자·경영자
수익성과 위험을 검토
제출기록
견적책임자
어떤 버전을 언제 누구에게 제출했는지 확인
견적서만 있고 산출근거·제외사항·승인기록·제출기록이 없다면 프로세스가 완전하게 끝났다고 보기 어렵습니다.
자료검색·사실확인·형식변환·파일통합·진행상태 문의·승인자 탐색·오류수정·재설명·재입력·개인백업처럼 공식 절차 밖에서 실제 성과를 만드는 행동도 현재형에 기록합니다. 이들은 기준 부재·데이터 분산·시스템 미연결·인계 불명확·개인의존을 보여줍니다.
9. 각 단계의 성과 기여를 확인한다
업무단계
출력
보호하는 CTQ
요구사항을 공사범위표로 정리한다
확정 공사범위표
요구사항 반영
최신 승인 도면을 식별한다
적용 도면정보
최신 도면 사용
공종별 수량을 산출한다
수량산출표
수량 정확성
유효한 단가를 적용한다
단가·원가표
단가 유효성
이윤율을 검토한다
이윤검토 결과
목표이윤율
제출본과 시각을 저장한다
제출기록
버전 추적
출력이나 CTQ에 기여하지 않는 단계도 현재형에서는 사실대로 기록하고, 이후 ERRC에서 제거·축소 여부를 판단합니다.
10. 역할로 배치 가능한 수준까지 구체화한다
“견적을 잘 만든다”가 아니라 요구사항 분류·수량 추출·유사견적 검색·단가 조회·누락 표시·이윤율 예외보고·최종 승인처럼 씁니다. 그래야 이후 AI의 분류·검색·비교, 시스템의 저장·전달·통제, 사람의 판단·승인을 구분할 수 있습니다. 현재형에서는 지금 실제 수행자를 기록하고 미래형에서 재배치합니다.
11. 견적 프로세스 업무단계 사례
번호
수행자
업무단계
출력·완료조건
1
영업
고객 요구사항을 공사범위표로 정리한다
요구사항이 항목별 기록됨
2
견적
필수 견적자료의 접수 여부를 확인한다
자료상태와 보완요청 기록
3
견적
최신 승인 도면을 식별한다
번호·개정일·승인상태 기록
4
견적
공종별 수량을 산출한다
대상 공종의 수량과 근거
5
구매·견적
유효한 자재·외주단가를 확인한다
출처·기준일이 있는 적용단가표
6
견적
원가와 판매가를 계산한다
항목별 금액이 있는 견적 초안
7
견적
제외사항과 별도공사를 작성한다
포함·제외 범위가 구분됨
8
책임자
수량·단가·누락을 검토한다
수정사항 또는 검토완료 기록
9
책임자
목표이윤율 충족 여부를 검토한다
충족 또는 예외승인 요청
10
승인권자
최종 견적과 예외사항을 승인한다
승인·반려 기록
11
영업
승인된 견적서를 고객에게 제출한다
수신자 전달 완료
12
영업
제출본과 제출기록을 저장한다
파일·일시·수신자 저장
12. 중요 단계 정의표
항목
작성 사례
업무명·수행자
P-04 공종별 수량을 산출한다 · 견적담당자
시작 조건·입력
최신 승인 도면과 확정 공사범위표가 준비됨
활동·기준
공종별 산출기준과 포함·제외 범위에 따라 수량 계산
도구
CAD, Excel, 수량산출 양식
출력·완료조건
모든 대상 공종의 수량과 근거가 기록된 산출표
인계 대상
견적책임자
관련 CTQ
수량 정확성, 최신 도면 사용
주요 오류·증거
공종 누락·구도면·중복산출 / 산출표·도면번호·검토기록
CTQ 영향, 오류·재작업, 판단·승인, 인계, AI·시스템 배치, CAC 후보가 있는 단계부터 상세 정의합니다.
SECTION 05 핵심 원칙 업무단계는 누가 무엇을 받아 어떤 기준으로 행동하고 무엇을 만들어 넘기는지 설명하는 실행 단위입니다.
수행자·입력·기준·출력·완료조건이 달라지면 별도 단계로 나누고, 이후 역할 배치와 성과측정이 가능할 만큼 명확하게 씁니다.
이해 점검
“견적서를 검토한다”가 부족한 이유는 무엇인가?
여러 사람이 함께하는 업무를 어떤 기준으로 나눌 것인가?
완료조건을 행동이 아니라 상태로 써야 하는 이유는 무엇인가?
불필요해 보이는 현재 업무를 지금 바로 삭제해도 되는가?
SECTION 06
스윔레인으로 업무흐름 연결하기
스윔레인은 업무순서뿐 아니라 업무성과를 만드는 역할·인계·대기·책임의 경계를 보여주는 프로세스 지도입니다.
1. 스윔레인이란?
스윔레인(Swimlane)은 수영장 레인처럼 사람·부서·AI·시스템별 업무영역을 나누어 프로세스를 표현하는 방법입니다. 각 단계를 실제 수행자 레인에 놓으면 누가 무엇을 하고 누구에게 넘기며 어디에서 대기·병목·책임변화가 생기는지 볼 수 있습니다.
일반 플로차트
스윔레인
자료확인→수량산출→단가적용→검토→승인→제출
영업의 자료전달→견적의 산출·작성→책임자의 검토→권한자의 승인→영업의 제출
2. 레인은 사람 이름이 아니라 역할로 만든다
피해야 할 레인명
적절한 역할 레인
김대리·박과장·김대표
영업담당자·견적담당자·견적책임자·승인권자
ChatGPT·Claude
견적검수 AI·도면 버전관리 AI·원가 이상탐지 AI
사람 이름은 담당자표에 기록하고 청사진에서는 직원이 바뀌어도 유지되는 역할명을 씁니다. AX 청사진은 역할과 책임을 다루므로 가능한 한 부서보다 역할 단위로 구성합니다.
3. 역할·부서·시스템·AI 레인
레인
장점
주의점
부서
조직 전체 흐름을 단순하게 표현
부서 안의 실제 책임자가 흐려짐
역할
수행자·책임·인계가 명확
너무 많으면 하위 청사진으로 분리
시스템
자동처리·저장·알림을 구분
사람의 클릭과 시스템 자동행동을 구분
AI
AI의 입력·출력·인계를 역할로 표현
현재 없는 AI를 As-Is에 넣지 않음
4. 현재형과 미래형을 섞지 않는다
현재형(As-Is)지금 실제로 수행하는 사람·부서·시스템·AI만 표시합니다. 비공식 AI는 계정·권한·검토·기록의 현재 상태도 적습니다.
미래형(To-Be)개선 후 배치할 사람·AI·시스템 역할과 새 인계·권한·통제를 표시합니다.
현재형에는 사실을 그리고, 미래형에는 설계한 역할을 그립니다. 둘을 섞으면 현재 문제와 개선효과를 비교할 수 없습니다.
5. 기본 구성요소
요소
의미
견적 사례
시작
프로세스를 시작시키는 사건
필수 견적자료 접수
업무단계
수행자의 구체적인 활동
공종별 수량을 산출한다
흐름선
다음 업무로 진행되는 순서
자료확인 후 수량산출
판단·분기
조건에 따라 흐름이 갈라짐
필수자료가 모두 있는가?
인계
다른 역할로 결과가 넘어감
견적 초안→견적책임자
종료
완료조건을 충족한 상태
제출·기록 완료
출력·주석
문서·정보·문제·대기 설명
수량표·승인기록·승인 대기 1일
6. 작성 방향과 경계
일반적으로 가로축은 시간과 업무순서, 세로축은 수행 역할로 둡니다. SECTION 02에서 정한 시작점과 종료점을 먼저 배치하고 그 사이에 SECTION 05의 단계를 놓습니다.
시작: 필수자료 접수→역할별 업무와 인계→종료: 승인 견적 제출·기록
7. 정상 흐름부터 연결한다
영업담당자가 요구사항을 정리하고 견적자료를 전달합니다.
견적담당자가 필수자료·최신 도면을 확인하고 수량·단가를 적용해 초안을 작성합니다.
견적책임자가 누락·산출근거·이윤율을 검토하고 승인을 요청합니다.
승인권자가 최종 견적을 승인합니다.
영업담당자가 고객에게 제출하고 기록을 저장합니다.
정상 흐름을 완성한 후 자료부족·반려·변경·긴급 업무를 추가합니다.
8. 역할별 기본 골격
순서
영업담당자
견적담당자
견적책임자
승인권자
1~2
요구사항 정리·자료 전달
3~7
자료·도면 확인, 수량·단가·초안
8~10
누락·근거·이윤 검토, 승인요청
11
최종 승인
12~13
고객 제출·기록 저장
9. 같은 레인 흐름과 레인 간 인계를 구분한다
같은 레인견적담당자가 도면확인→수량산출→단가적용→초안작성을 연속 수행
레인 간 인계견적담당자가 견적 초안·수량·단가근거를 견적책임자에게 넘겨 검토책임이 이동
레인 사이에서는 인계물 누락·미완료 전달·수신 미확인·버전 오류·책임혼선·승인 대기가 자주 발생하므로 중요한 진단지점입니다.
10. 인계물과 완료조건을 표시한다
보내는 역할
받는 역할
인계물
완료조건
영업
견적
요구사항·도면·실측자료
필수자료 목록과 함께 전달
견적
책임자
초안·수량·단가근거
작성자 자체검토 완료
책임자
승인권자
검토완료 견적·이윤·예외사항
검토결과와 승인요청 기록
승인권자
영업
승인된 최종 견적서
승인자·일시·조건 기록
영업
고객
최종 견적서·제외사항
파일 전달과 수신자 기록
좋은 인계는 보내는 사람·받는 사람·인계물·인계 상태·수령 확인이 명확합니다.
11. 인계·공유·통보를 구분한다
구분
책임 이동
후속 행동
사례
인계
있음
필수
초안을 책임자에게 넘겨 검토를 시작
공유·통보
없음
필요에 따라
진행상태를 영업담당자에게 알림
12. 사람과 시스템의 행동을 구분한다
사람의 도구사용견적담당자가 시스템에서 최신 단가를 조회한다 → 견적담당자 레인
시스템의 자동행동시스템이 금액기준으로 승인권자를 지정하고 알림을 발송한다 → 시스템 레인
13. AI를 독립 역할로 표시하는 기준
AI가 정해진 입력을 받고 반복 업무를 수행하며 결과물을 만들어 다음 역할에 전달하거나 예외를 보고하고 기록을 남길 때 별도 레인을 검토합니다.
AI가 도구인 경우
AI가 역할인 경우
견적담당자가 AI로 설명문을 작성하고 직접 검토·복사
견적검수 AI가 초안과 도면을 비교해 누락 의심목록을 만들고 책임자에게 전달
AI 제품명이 아니라 조직 역할명으로 작성하며, 입력·실행·출력·권한·검토자·예외보고·기록·최종책임을 함께 정의합니다.
14. 인계 횟수와 문제를 진단한다
레인 경계를 자주 넘을수록 전달대기·정보누락·책임혼선·버전오류·반복확인이 늘 수 있습니다. 다만 품질·안전·계약 통제에 필요한 인계는 유지해야 합니다.
문제 표시
기록할 내용
대기·병목
무엇을 얼마나 기다리고 어느 역할에 업무가 집중되는가?
반복·누락
어디로 몇 번 돌아가며 어떤 정보·검토가 빠지는가?
개인의존·버전
누구의 경험·파일에 의존하고 최신본을 어떻게 구분하는가?
비공식 처리
전화·메신저·구두승인으로 무엇을 처리하는가?
성과 영향
시간·오류·비용·재작업에 어떤 영향을 주는가?
현재 흐름은 삭제하지 않고 문제표시만 추가합니다. 개선은 진단과 ERRC 이후 미래형에서 설계합니다.
15. 작성 순서
시작점·종료점 배치
실제 참여 역할과 레인 구성
정상 업무를 시간순으로 배치
같은 역할의 업무 연결
레인 간 인계 연결
인계물·완료조건 표시
시스템과 현재 AI의 실제 행동 표시
대기·반복·누락 문제 주석
실제 담당자 검증
판단·분기·예외 추가
16. 자주 발생하는 오류
사람 이름으로 레인을 만듭니다.
부서와 역할을 혼합해 기준이 달라집니다.
업무상자에 행동이 아닌 문서명만 적습니다.
인계 화살표에 인계물과 완료조건이 없습니다.
사람의 클릭을 시스템 자동행동으로 표시합니다.
현재형에 계획 중인 AI를 넣습니다.
모든 희귀 예외를 한 장에 넣어 읽기 어렵게 만듭니다.
SECTION 06 핵심 원칙 스윔레인은 업무성과를 만드는 역할·인계·책임의 구조입니다.
레인은 역할명으로 만들고, 다른 레인으로 이동할 때 무엇이 어떤 완료상태로 인계되는지 표시합니다.
AI·시스템은 독립적으로 입력을 받고 결과를 전달할 때 역할 레인으로 배치합니다.
이해 점검
역할 레인이 AX 청사진에 적합한 이유는 무엇인가?
사람의 시스템 사용과 시스템 자동수행을 어떻게 구분하는가?
인계물과 완료조건을 표시해야 하는 이유는 무엇인가?
현재 없는 AI를 As-Is에 넣으면 어떤 문제가 생기는가?
SECTION 07
판단·승인·분기 조건 작성하기
실제 프로세스는 한 방향으로만 진행되지 않습니다. 조건을 충족하면 다음 단계로 가고, 부족하면 보완하며, 위험하면 중단하거나 상급자에게 보고합니다.
1. 판단과 분기가 필요한 이유
“자료확인→수량산출→단가적용→검토→승인→제출”만으로는 자료부족·구도면·단가노후·이윤율 미달·승인한도 초과·반려와 재작업을 표현할 수 없습니다. 조건과 결과별 흐름을 표시해야 실제 작동하는 청사진이 됩니다.
용어
의미
견적 사례
판단
정보와 기준을 비교하여 상태 판정
필수자료가 모두 접수됐는가?
분기
판단결과에 따라 흐름이 갈라짐
충족→산출, 미충족→보완
검토
내용과 기준 충족 여부 확인
수량·단가·누락 검토
승인
권한자가 진행·제출을 허가
최종 견적 제출 승인
보완·반려
부족한 정보 추가 또는 이전 단계 재처리
실측자료 보완·이윤율 반려
에스컬레이션
권한 밖 문제를 상위 책임자에게 보고
손실 가능 견적 대표 보고
반복·병렬
재수행 또는 둘 이상의 업무 동시진행
수정·재검토 / 수량과 단가 동시확인
2. 업무와 판단을 구분한다
업무단계필수자료를 대조한다, 수량을 산출한다, 제외사항 목록을 만든다처럼 결과를 만드는 행동
판단단계필수자료가 모두 있는가, 최신 승인도면인가, 이윤율이 기준 이상인가처럼 진행방향을 정하는 질문
필수자료를 확인한다→모두 접수됐는가?→예: 수량산출 / 아니요: 보완요청
3. 판단 질문을 명확하게 작성한다
모호한 질문
명확한 판단 질문
자료에 문제가 있는가?
필수자료 목록의 모든 항목이 접수됐는가?
견적이 적정한가?
예상이윤율이 최소 목표이윤율 이상인가?
도면이 맞는가?
도면번호·개정일·승인상태가 유효한가?
대표에게 물어봐야 하는가?
견적금액이 책임자의 승인한도를 초과하는가?
좋은 판단은 대상·기준·가능한 결과·결과별 후속업무·판단자·판단근거가 분명합니다.
4. 암묵적 판단을 기준으로 바꾼다
암묵적 판단
명확한 기준 사례
금액이 크면 대표 승인
총 견적금액 1억원 초과 시 대표 승인
이윤이 낮으면 보고
예상이윤율 15% 미만이면 예외승인 요청
단가가 오래되면 확인
기준일로부터 90일 지난 단가는 재확인
변경이 많으면 재견적
공사범위 또는 총금액 10% 이상 변경 시 재견적
공기가 촉박하면 보고
착공 준비기간 14일 미만이면 일정위험 보고
주의 위 수치는 설명을 위한 예시입니다. 실제 기준은 회사의 정책과 데이터로 정합니다.
5. 검토·승인·협의·통보·인계를 구분한다
구분
핵심 의미
견적 사례
검토
내용과 기준의 적합성 확인
수량·단가·누락 검토
승인
권한으로 진행·제출을 허가하고 결정 책임
예외 이윤율 허가
협의
결정 전 전문의견 제공
구매담당자에게 최신 단가 확인
통보
결정·진행상태를 알림, 허가 불필요
영업에게 승인완료 알림
인계
다음 수행자에게 업무와 책임을 넘김
승인 견적서를 영업에게 전달
검토자는 내용의 적합성을 확인하고, 승인자는 조직의 권한으로 진행 여부를 결정합니다.
6. 승인권한표를 만든다
조건
검토자
승인자
대표 보고
표준 견적·기준 이윤 이상
견적책임자
견적책임자
불필요
승인한도 초과
견적책임자
임원·대표
필요
목표이윤율 미달
견적책임자·재무
대표
필수
새 공법·불확실한 원가
설계·현장·견적
대표
필수
계약·법률·안전 예외
관련 책임자
권한자
필수·즉시
실제 권한표에는 승인 대상·금액·이윤·위험기준·검토자·승인자·기한·대리자·기록방법·미승인 시 중단 여부를 포함합니다.
7. 네 가지 분기 유형
하나만 선택한도 이내→책임자 승인 / 초과→대표 승인
여러 조건 적용공법 위험→설계, 원가 불확실→구매, 계약 예외→계약 검토를 함께 수행 가능
병렬처리수량산출과 자재·외주단가 확인을 동시에 하고 둘 다 완료되면 초안 작성
반복·재작업검토기준 미달→수정→재검토, 충족 시 승인 요청
판단상자에서 나가는 모든 화살표에는 ‘예·아니요’ 또는 금액·이윤율 같은 구체적인 조건을 표시합니다.
8. 복잡한 조건은 판단표로 연결한다
판단 대상
일반 진행
상위 승인
중단·보완
필수자료
모두 접수
해당 없음
부족하면 작성 중단
도면
승인된 최신본
예외 사용 시 설계책임자
버전 불명 시 중단
이윤율
기준 이상
미달 시 대표
손실 예상 시 조건 재검토
견적금액
담당 승인한도 이내
한도 초과 시 상위자
승인자 부재 시 대기
단가
유효기간 이내
예외단가 책임자 확인
출처 불명 단가 금지
계약조건
표준조건
예외조건 대표·계약 검토
법률위험 미해결 시 중단
9. 보완·수정·반려·중단을 구분한다
구분
의미
돌아가는 위치
보완
부족한 정보나 자료를 추가
자료를 만드는 단계
수정
결과물 일부 오류를 고침
오류가 발생한 단계
반려
핵심 기준 미충족으로 재처리
책임 있는 이전 단계
중단
중대한 조건으로 진행 불가
보류 또는 프로세스 종료
반복에는 수정자·재검토자·완료기준·반복 횟수·기한과 에스컬레이션 조건이 있어야 합니다. “문제 없을 때까지 수정”처럼 무한반복을 만드는 표현은 피합니다.
10. 조건부 승인과 사후 승인
조건부 승인특정 조건 충족을 전제로 진행. 조건·확인자·기한·미충족 시 처리·외부제출 가능범위를 기록
사후 승인긴급상황에서 먼저 실행 후 승인. 허용상황·임시권한·범위·승인기한·복구방법·발생기록을 제한적으로 정의
11. 에스컬레이션 조건
승인한도 초과, 이윤율 미달, 계약·안전·법률 위험, 기준 충돌, 반복 오류, 기한 초과 위험, 고객요구와 정책 충돌, AI·시스템의 판단 불가 상황은 상위 책임자 또는 전문 역할에 보고합니다.
[발생 조건]이면 [수행자]는 [근거·대안]을 [보고 대상]에게 [기한] 안에 보고하고, 승인 전까지 [중단할 업무]를 실행하지 않는다.
이윤율 미달 에스컬레이션
예상이윤율이 최소기준보다 낮으면 견적책임자는 원가·판매가·이윤율·수주 필요성·조정안을 대표에게 제출하고, 예외승인 전까지 고객에게 최종 견적을 발송하지 않는다.
12. 판단과 승인의 증거
기록 항목
사례
판단 대상·적용 자료
견적번호·프로젝트·견적버전·도면번호
적용 기준
승인한도·목표이윤율
판단 결과
승인·조건부 승인·반려·중단
판단 사유
전략고객·원가변동·계약조건
결정자·시각
견적책임자·대표·승인일시
후속 조건·파일
단가 재확인·승인본·검토표·예외보고서
13. 현재형과 미래형 판단을 섞지 않는다
현재 “금액이 크다고 느껴지면 대표에게 질문하고, 긴급하면 메신저로 구두승인하며, 이윤율은 대표가 상황에 따라 판단하고, 승인기록은 없다”면 그대로 기록합니다. 승인한도 불명확·대표 의존·판단기준 개인화·기록 부재를 문제로 표시하고, 미래형에서 권한표·판단표·자동 알림·예외보고를 설계합니다.
14. AI 배치 전에 판단의 성격을 분류한다
판단 성격
사례
규칙 기반
금액이 승인한도를 초과하는가?
비교 기반
견적서와 도면 사이에 누락 의심 항목이 있는가?
데이터 기반
과거 견적보다 단가가 비정상적으로 높은가?
전문 판단
공법·현장조건을 고려할 때 원가가 적정한가?
관계·전략 판단
전략고객에게 낮은 이윤율을 허용할 것인가?
법적·안전 판단
계약·안전 위험을 감수하고 진행할 수 있는가?
이 구분을 바탕으로 이후 규칙은 시스템, 비교·분석은 AI, 전문·전략·책임 판단은 권한 있는 사람에게 배치할지 검토합니다. 지금은 AI 가능성 때문에 판단업무부터 넘기지 않습니다.
이 순서를 지키면 기술 자체가 아니라 성과문제와 필요한 역할에서 출발할 수 있습니다. ERRC 이후에는 개선안을 실제로 지키게 만드는 CAC를 설계하고, 필요한 역할을 사람·AI·시스템에 배치합니다.
23. 통합 ERRC 개선표
항목
작성 내용
성과격차
견적 검토와 승인에 평균 1.5일 소요, 제출 후 누락 발견 월 3건
구조적 원인
자료가 분산되고 검토기준이 개인 경험에 의존
위험·통제 공백
구도면·누락항목·이상단가의 제출 전 전수점검 없음
1차 ERRC
반복입력 제거 / 전수 재검토 축소 / 버전·단가 검증 강화 / 사전검수 창조
필요 역할
자료를 대조하고 이상항목과 판단근거를 검토자에게 알리는 역할
AI 역할 가설
도면·산출표·견적서를 대조하여 누락·불일치·이상단가 후보와 근거를 제시
AI 도입효과 ERRC
수기대조 제거 / 검토시간 축소 / 사전탐지 강화 / 상시검수·학습 창조
사람의 최종 역할
예외·고위험 검토, 수정·승인 판단, 고객조건 조정, 최종 책임
성과지표 후보
검토시간, 제출 전 오류발견률, 재작업률, 탐지정확도, 사람검토시간
후속 과제
CAC와 통제 설계, 역할 배치, To-Be 프로세스, PoC 검증
24. SECTION 10의 최종 결과물
1차 개선방향성과격차·구조적 원인·통제 공백에 대한 기술중립적 ERRC
필요 역할 후보개선안을 실행하는 데 필요한 역할을 동사로 정의
AI 역할 가설입력·수행·출력·근거·전달대상이 명확한 역할 문장
2차 도입효과AI 역할이 제거·축소·강화·창조하는 변화와 측정지표
사람 역할 변화AI 도입 후 사람이 맡을 판단·예외·승인·책임
통합 문서성과문제부터 후속과제까지 연결한 ERRC 개선표
SECTION 10 핵심 원칙 프로세스 ERRC의 판단 기준은 업무성과와 위험통제입니다.
먼저 기술중립적으로 업무개선 방향을 정하고, 필요한 역할을 정의한 뒤 AI 역할 가설의 도입효과를 다시 ERRC로 분석합니다.
AI의 효과는 자동화 여부가 아니라 무엇이 제거·축소·강화·창조되는지와 사람의 역할이 어떻게 바뀌는지로 설명합니다.
이해 점검
서비스 청사진 ERRC와 프로세스 청사진 ERRC의 직접 목적은 어떻게 다른가?
왜 AI를 정하기 전에 1차 업무개선 ERRC를 해야 하는가?
AI가 사람의 반복검토를 제거하더라도 사람에게 남겨야 할 책임은 무엇인가?
견적검수 AI의 제거·축소·강화·창조 효과를 각각 한 가지씩 설명할 수 있는가?
AI 처리시간이 빨라져도 순효과가 낮을 수 있는 경우는 무엇인가?
SECTION 11
CAC로 핵심행동과 통제 설계하기
ERRC가 무엇을 바꿀 것인가를 결정한다면, CAC는 바뀐 프로세스에서 무엇을 반드시 실행해야 하는가를 정합니다.
1. CAC란 무엇인가?
CAC(Critical Action Checklist)는 프로세스의 성과와 품질을 지키고 중대한 위험을 통제하기 위해 반드시 실행해야 하는 핵심행동을 정리한 체크리스트입니다. 우리말로는 핵심행동 체크리스트라고 할 수 있습니다.
CAC = 업무성과와 위험통제를 위해 반드시 실행하고 확인해야 하는 결정적 행동
CAC는 해야 할 일을 모두 나열하지 않습니다. 실행하지 않으면 CTQ를 충족하기 어렵거나, 누락되면 중대한 오류·손실이 생기거나, 다음 단계 전에 반드시 확인하고 증거를 남겨야 하는 행동만 선별합니다.
2. CAC가 필요한 이유
기준의 일관성“검토한다”가 아니라 무엇을 어떤 기준으로 확인하는지 정합니다.
실행의 증거누가 언제 무엇을 확인했는지 기록으로 남깁니다.
오류의 차단잘못된 결과가 다음 단계나 고객에게 넘어가기 전에 멈춥니다.
개선의 정착ERRC로 바꾼 프로세스를 실제 행동으로 전환합니다.
프로세스 청사진이 업무의 흐름을 보여준다면, CAC는 그 흐름에서 절대로 빠뜨리면 안 되는 행동을 정합니다.
3. CTQ와 CAC의 차이
구분
CTQ
CAC
의미
결과물이 반드시 충족해야 하는 핵심 품질요건
품질과 성과를 지키기 위해 반드시 실행해야 하는 행동
중심 질문
결과가 어떤 상태여야 하는가?
그 결과를 위해 무엇을 반드시 해야 하는가?
측정 대상
결과의 품질과 성과
행동의 실행 여부와 증거
견적 사례
최신 승인도면 사용률 100%
산출 전 도면번호·개정일·승인상태를 확인·기록
CTQ: 최신 승인도면 사용률 100%→CAC: 산출 전 번호·개정일·승인상태 확인
4. 일반 체크리스트·SOP·통제와의 차이
구분
역할
프로세스 청사진
업무가 어떤 순서와 구조로 진행되는지 보여줌
SOP
업무를 수행하는 전체 방법과 절차를 설명
일반 체크리스트
필요한 여러 업무활동을 빠짐없이 확인
통제
오류·손실·무권한 실행을 예방·발견·복구
CAC
성과와 통제를 위해 절대로 누락하면 안 되는 행동을 확인
“이메일 확인·도면 열기·팀장 전달”은 일반 활동입니다. “산출 전 도면번호·개정일·승인상태를 공식 목록과 대조”처럼 누락 시 성과와 위험에 직접 영향을 주는 행동이 CAC입니다.
5. CAC는 어디에서 도출하는가?
출력·CTQ→성과격차→실패유형·위험→통제 공백→ERRC→CAC
도출 근거
CAC로 전환하는 질문
CTQ
이 결과기준을 지키려면 무엇을 반드시 해야 하는가?
반복 오류·위험
같은 실패를 예방하거나 조기에 발견하려면 언제 무엇을 확인해야 하는가?
통제 공백
현재 빠져 있는 확인·중단·보고·승인 행동은 무엇인가?
판단·인계
어떤 조건을 확인해야 다음 흐름이나 담당자에게 넘길 수 있는가?
ERRC
개선된 방식이 실제로 실행되려면 어떤 행동이 필요한가?
AI 역할
AI 결과를 안전하게 사용하려면 AI와 사람이 각각 무엇을 확인해야 하는가?
6. CAC 도출의 6단계
결과: 최신도면·누락 0건·목표이윤처럼 지켜야 할 CTQ와 성과를 정합니다.
실패: 구도면 사용·공종 누락·미승인 제출처럼 실패상황을 구체화합니다.
원인: 개인 태도가 아니라 공식 저장위치·기준·권한·정보흐름의 문제를 찾습니다.
행동: 실패를 예방하거나 조기에 발견할 결정적 행동을 정합니다.
기준·증거: 무엇이면 통과인지, 무엇을 기록할지 정합니다.
실패 대응: 미통과 시 중단·보고·수정·승인·재개 방법을 정합니다.
7. 좋은 CAC 문장의 구조
실행 시점·조건 + 수행 역할 + 핵심행동 + 판정기준 + 실행증거 + 실패 시 대응
구성요소
도면확인 사례
시점·조건
수량산출을 시작하기 전에
수행 역할
견적담당자가
핵심행동
적용 도면을 공식 도면목록과 대조
판정기준
번호·개정일·승인상태가 모두 일치
실행증거
확인자·확인일시·적용 도면번호 기록
실패 대응
산출 중단 후 설계책임자에게 보고
완성된 CAC 문장
견적담당자는 수량산출 전에 적용 도면의 번호·개정일·승인상태를 공식 도면목록과 대조하고 확인기록을 남긴다. 불일치하거나 승인상태가 불명확하면 산출을 중단하고 설계책임자에게 보고한다.
8. 관찰 가능하고 한 행동씩 작성한다
모호한 표현
관찰 가능한 CAC
도면을 꼼꼼히 확인한다
도면번호·개정일·승인상태를 공식 목록과 대조한다
적정 단가를 적용한다
단가의 출처·기준일·유효기간을 확인한다
이윤율을 검토한다
원가·판매가·이윤율을 계산하고 최소이윤율 이상인지 확인한다
문제가 있으면 보고한다
이윤율 미달 시 제출을 중단하고 예외승인을 요청한다
한 항목에는 통과·실패를 한 번에 판정할 수 있는 하나의 핵심행동만 담습니다. 꼼꼼하게·적절하게·필요시·가능하면 같은 표현은 구체적인 조건이나 수치로 바꿉니다.
9. CAC 후보 선별 기준
누락되면 CTQ를 충족하지 못하는가?
고객·회사·후속 업무에 큰 손실이 발생하는가?
반복 오류·재작업이 발생했는가?
담당자마다 실행이나 판단이 다른가?
실행증거를 남겨야 하는가?
다음 단계 전에 반드시 확인해야 하는가?
법률·계약·안전·보안·승인과 관련되는가?
AI가 잘못 작동했을 때 사람이 반드시 확인해야 하는가?
누락되어도 성과와 위험에 거의 영향을 주지 않는 일반 활동은 SOP에 두고 CAC에서는 제외합니다.
10. CAC 유형과 세 가지 관문
유형
목적
견적 사례
시작조건
불완전한 상태의 업무 시작 방지
필수자료 100% 접수 확인
실행·판단
핵심업무와 분기기준 확인
최신도면·이윤율 미달 확인
인계
다음 역할이 사용할 수 있는 상태 확인
근거자료·예외사항 함께 전달
승인
적정 권한자의 허가 확인
금액·위험등급별 승인
완료·복구
종료조건과 정상복귀 확인
제출기록·수정본 회수·재제출
AI 통제
AI 결과·권한·사람검토 관리
근거·신뢰도·고위험 검토
시작 관문입력이 완전해야 시작합니다.
이동 관문결과가 기준을 충족해야 다음 단계로 넘깁니다.
종료 관문승인·버전·수신자·기록을 확인한 뒤 외부로 내보냅니다.
11. 견적 프로세스 CAC 사례
단계
CAC
판정기준·증거
실패 대응
자료접수
요구사항·도면·현장정보·기한 확인
필수항목 100% / 접수기록
보완요청 후 시작 보류
도면확인
번호·개정일·승인상태 대조
최신 승인본 일치 / 확인이력
산출 중단·책임자 보고
수량산출
필수 공종과 산출표 대조
미반영 0건 / 대조표
보완 후 재검토
단가적용
출처·기준일·유효기간 확인
유효 승인단가 / 출처기록
갱신 요청
이윤검토
원가·판매가·이윤율 계산
목표 이상 / 계산표
제출 중단·예외승인
승인·제출
승인자·상태·파일버전·수신자 확인
권한표·최종본 일치 / 승인·제출이력
발송 중단 또는 회수·정정
12. 담당자는 이름이 아니라 역할로 정한다
잘못된 표현
바람직한 표현
김대리가 확인한다
견적담당자가 확인한다
박부장이 승인한다
견적책임자가 승인한다
대표님께 물어본다
예외승인권자에게 승인을 요청한다
AI가 알아서 확인한다
견적검수 역할이 불일치 항목과 근거를 제시한다
13. 사람·AI·시스템의 CAC
수행 주체
CAC 사례
사람
AI가 표시한 고위험 항목과 판단근거를 검토한다
AI
도면·산출표·견적서의 누락과 불일치를 대조하고 근거를 제시한다
시스템
승인상태가 완료되지 않으면 외부발송을 차단하고 이력을 남긴다
AI와 시스템이 행동을 실행해도 결과를 관리하고 최종 판단·책임지는 사람의 역할은 명확해야 합니다.
14. AI 역할에 추가할 CAC
영역
CAC 작성 예시
입력자료
분석 전 문서번호·버전·승인상태 확인
출처·근거
단가 출처·기준일과 이상판단의 비교근거 표시
불확실성
신뢰도 기준 미달 결과는 사람 검토로 전환
사람 검토
고액·저이윤·계약예외는 책임자가 최종 검토
권한
AI는 초안·경고만 작성하고 승인·발송은 수행하지 않음
보안·기록
사용등급 확인 후 입력하고 모델·결과·수정·승인이력 저장
장애·성과
장애 시 수기검토로 전환하고 오탐·미탐·검토시간 점검
15. AI 결과를 사용하는 사람의 CAC
AI가 사용한 도면과 견적서의 버전을 확인합니다.
이상항목의 비교근거를 확인합니다.
고위험과 신뢰도 기준 미달 항목을 직접 검토합니다.
필수 안전·계약 항목을 별도로 확인합니다.
수정 여부와 근거를 기록합니다.
최종 승인 여부를 사람이 결정합니다.
“AI 결과를 사람이 검토한다”만으로는 CAC가 아닙니다. 무엇을 어떤 기준으로 검토하고, 언제 승인·중단하며, 어떤 증거를 남기는지까지 작성해야 합니다.
16. CAC 적정성 평가
판단기준
확인 질문
결정성
누락되면 성과나 위험에 직접 영향을 주는가?
명확성·판정성
누가·언제·무엇을 하며 통과·실패를 구분할 수 있는가?
증거성·적시성
기록이 남고 다음 단계 전에 작동하는가?
책임성·대응성
책임 역할과 실패 시 중단·보고·수정·승인이 정해졌는가?
경제성
통제비용이 예방하는 손실보다 과도하지 않은가?
CAC가 너무 많으면 중요한 항목이 묻히고 일괄체크·우회·형식화가 생깁니다. 일반 활동은 SOP에 두고, 중복 CAC는 통합하며, 실제 오류 감소에 효과가 없는 항목은 제거합니다.
17. CAC 통합 작성표
항목
최신 승인도면 확인 사례
CTQ·실패유형
최신 승인도면 100% / 구도면·미승인 도면 사용
위험·원인
수량·금액 오류 / 공식 최신본 위치와 확인기준 불명확
ERRC
버전확인 강화·이전본 사용 제거
수행조건·역할
수량산출 전 / 견적담당자
핵심행동·통과기준
번호·개정일·승인상태 대조 / 최신 승인본과 일치
증거·실패 대응
확인자·시각·도면번호 / 산출중단→보고→승인본 등록 후 재개
자동화·AI 후보
최신본 식별·이전본 차단 / 문서 간 도면정보 불일치 탐지
사람 책임·지표
적용도면 최종확정 / 구도면 건수·확인 누락률·재작업률
18. SECTION 11의 최종 결과물
CAC 후보목록CTQ·위험·통제 공백에서 도출
CAC 정의문시점·역할·행동·기준·증거·실패대응
CAC 배치도시작·이동·종료 관문
AI 통제 CAC입력·근거·불확실성·권한·사람검토
역할 연결표사람·AI·시스템의 행동과 책임
통합 CAC표CTQ부터 성과지표까지 연결
SECTION 11 핵심 원칙 CAC는 모든 업무를 나열하는 목록이 아니라 업무성과와 위험통제를 위해 절대로 빠뜨리면 안 되는 결정적 행동입니다.
좋은 CAC에는 언제·누가·무엇을·어떤 기준으로 실행하고 어떤 증거를 남기며 실패하면 어떻게 대응하는지가 나타나야 합니다.
AI가 도입되면 AI가 수행할 CAC와 AI 결과를 검토·승인·책임지는 사람의 CAC를 함께 설계합니다.
이해 점검
CTQ와 CAC는 어떻게 다른가?
모든 업무항목을 CAC로 지정하면 안 되는 이유는 무엇인가?
“도면을 꼼꼼히 확인한다”를 실행 가능한 CAC로 바꿀 수 있는가?
시작·이동·종료 관문에 각각 어떤 CAC가 필요한가?
AI와 사람이 각각 수행해야 할 CAC는 무엇인가?
SECTION 12
업무성과를 만드는 필요한 역할 정의하기
CAC가 반드시 해야 할 행동을 정한다면, 역할 정의는 그 행동과 결과를 누가 책임져야 하는지를 정하는 과정입니다.
1. 역할이란 무엇인가?
역할(Role)은 특정한 업무성과를 만들기 위해 맡겨진 행동·판단·권한·책임의 묶음입니다. 직급이나 사람 이름이 아니라, 어떤 입력을 받아 무엇을 수행·판단하고 어떤 출력과 증거를 누구에게 전달하는지를 정의합니다.
역할 = 공통 목적의 업무행동 + 판단기준·권한 + 결과물 + 책임
역할 중심 표현
“김 대리가 견적을 본다”가 아니라 “고객 요구사항과 도면을 받아 수량과 단가를 산출하고, 근거가 포함된 견적초안을 만드는 역할”로 정의합니다.
2. 역할·사람·직책·도구의 차이
구분
의미
견적 사례
사람
실제 업무를 수행하는 개인
김 대리
직책·부서
조직구조상의 직위와 소속
견적팀장·견적팀
업무
실제로 수행하는 하나의 행동
도면을 확인한다
역할
특정 결과에 대한 행동·권한·책임의 묶음
견적 품질·위험 검수 역할
도구
역할 수행을 지원하는 수단
Excel·ERP·AI
수행 주체
역할을 실제로 맡는 대상
사람·AI·시스템
한 사람이 여러 역할을 맡거나 하나의 역할을 여러 주체가 나눠 맡을 수 있습니다. 역할을 먼저 정의해야 현재 직원·신규직원·외주·AI·시스템에 일관되게 배치할 수 있습니다.
3. 역할을 먼저 정의해야 하는 이유
“견적 AI·챗봇·문서자동화·에이전트를 도입한다”로 시작하면 무엇을 책임지는지 알 수 없습니다. 역할을 먼저 정하면 목표성과·입력·행동·출력·권한·보고조건·최종 책임이 분명해집니다.
AX의 출발점은 AI 도구를 선택하는 것이 아니라 프로세스에 필요한 역할을 정의하는 것입니다.
4. 필요한 역할의 도출 근거
업무단계→판단·인계→성과격차→위험·통제→ERRC→CAC→필요 역할
도출 근거
역할을 찾는 질문
업무단계·출력
이 결과물을 만드는 기능은 무엇인가?
판단·인계
누가 기준을 판단하고 전달품질을 책임져야 하는가?
성과격차
부족한 성과를 개선할 기능은 무엇인가?
위험·통제 공백
위험을 예방·발견·복구하는 데 빠진 역할은 무엇인가?
ERRC
제거·축소·강화·창조된 흐름에 새로 필요한 역할은 무엇인가?
CAC
핵심행동을 수행하고 증거를 남길 책임은 누구에게 필요한가?
5. 현재 조직도가 아니라 필요한 기능에서 출발한다
프로세스가 만들어야 할 성과를 확인합니다.
성과를 위해 필요한 기능을 찾습니다.
비슷한 기능을 역할 단위로 묶습니다.
역할 간 판단·인계·책임관계를 정합니다.
다음 단계에서 사람·AI·시스템에 배치합니다.
“지금 누가 하고 있는가?”보다 먼저 묻습니다. “이 성과를 위해 어떤 역할이 반드시 필요한가?” 현재 검수자가 없더라도 검수 역할의 필요성까지 없어지는 것은 아닙니다.
6. 행동을 역할로 묶는 기준
한 행동을 곧바로 하나의 역할로 만들지 않습니다. 같은 목적·결과물·전문지식·판단기준·권한·책임을 가진 행동을 하나의 역할로 묶습니다.
업무행동
역할로 묶는 방식
요구확인·필수자료 확인·보완요청
견적접수·요구사항 구조화 역할
도면해석·공종분류·수량산출
수량산출 역할
단가출처·기준일·유효기간 관리
단가정보 관리 역할
누락·불일치·이상단가 확인
견적검수 역할
이윤율 미달·계약예외 판단
예외판단·승인 역할
수행과 승인을 분리해야 하거나, 이해충돌·독립검토·전문성·권한 수준이 다르면 역할도 분리합니다.
7. 대표 역할 유형
역할 유형
주요 책임
견적 사례
요청·접수
입력자료를 완전하게 접수
요구·도면·기한 확인
실행
핵심 결과물 생성
수량산출·견적초안
정보관리
기준정보의 정확성과 최신성 관리
표준·협력업체 단가
검토·판단
오류 발견과 조건별 분기
누락검수·위험등급
승인
권한에 따라 실행 허가
고액·저이윤 견적승인
조정·인계
부서 연결과 사용 가능한 상태 전달
영업·설계·견적 조정
예외대응
비정상 상황의 판단·보고·복구
구도면·단가불명 대응
기록·성과관리
이력 보존과 KPI 개선
승인·제출이력·재작업 분석
8. 견적 프로세스 필요 역할 사례
필요 역할
존재 목적
핵심 출력
견적접수
완전한 자료로 시작
접수정보·보완요청
요구사항 구조화
고객 요구를 견적조건으로 전환
범위·조건·제외사항
적용도면 확인
최신 승인본 사용 보장
적용 도면목록
수량산출·단가관리
정확한 물량과 최신 단가 제공
산출표·출처 있는 단가
견적작성·검수
초안 생성과 오류 발견
견적초안·검수결과
수익성·예외판단
손실위험과 표준 밖 조건 판단
수익성 분석·예외안
승인·고객제출 관리
권한 있는 승인과 정확한 버전 전달
승인본·제출기록
성과관리
오류·지연 분석과 기준 개선
KPI·개선과제
9. 좋은 역할명과 목적문
모호한 역할명
구체적인 역할명
지원 역할
견적자료 수집·보완 역할
관리 역할
견적단가 최신성 관리 역할
AI 역할
견적 누락·불일치 탐지 역할
검토자
견적 품질·위험 검수 역할
역할명 = 대상 + 책임 행동 + 역할
목적문은 “견적서를 검토한다”가 아니라 “고객 제출 전에 누락·불일치·이상단가를 발견하여 견적오류와 재작업을 줄인다”처럼 기대성과까지 씁니다.
10. 역할 정의서 구성
항목
작성 질문
역할명·목적
어떤 성과를 위해 존재하는가?
시작조건·입력
언제 무엇을 누구에게 받는가?
핵심행동·CAC
무엇을 수행하고 절대로 빠뜨리면 안 되는 행동은 무엇인가?
판단기준·권한
무엇을 기준으로 어디까지 조회·작성·요청·중단·승인할 수 있는가?
출력·인계
어떤 결과를 누구에게 어떤 상태로 넘기는가?
예외·증거
언제 상향하며 무엇을 기록하는가?
성과·역량·책임
어떻게 측정하며 필요한 지식과 최종 책임은 무엇인가?
11. 견적 누락·불일치 탐지 역할 정의 사례
항목
정의
존재 목적
제출 전 문서 간 오류를 발견하여 재작업과 손실을 줄임
시작·입력
견적초안 완료 시 / 요구·도면·산출표·단가·견적초안
핵심행동
문서 대조, 필수 공종 누락, 이상단가, 계약위험 탐지
CAC
버전확인·전수대조·근거기록·고위험 보고
출력
이상항목·근거·수정요청·검수기록
권한
조회·표시·추천·수정요청·제출중단 요청
제한 권한
임의수정·예외승인·고객발송·최종승인 불가
지표
탐지율·오탐·미탐·검수시간·제출 후 오류
12. 역할의 권한과 책임을 구분한다
권한
의미
검수 사례
조회·작성
정보 열람·결과물 생성
문서 조회·검수보고서 작성
추천·요청
대안 제시·타 역할에 행동 요구
수정안 추천·수정요청
수정·중단
원본 변경·다음 단계 정지
승인 범위 수정·고위험 제출중단
승인·실행
사용 허가·외부 전달
최종제출 승인·고객발송
책임
의미
수행 책임
실제 행동을 실행
검토 책임
결과와 근거를 검증
승인 책임
결과의 사용을 허가
최종 책임
결과에 대한 조직적 책임
AI가 업무를 수행할 수는 있지만 조직의 최종 책임까지 AI에 이전할 수는 없습니다.
13. 역할 분리와 통합
작성자가 자기 결과를 승인하거나 단가 등록자가 적정성까지 단독 검증하거나 AI가 작성·검토·승인·발송을 모두 하면 오류·조작·이해충돌을 발견하기 어렵습니다. 위험이 클수록 작성→검토→승인→외부실행을 분리합니다.
소규모 조직에서는 한 사람이 여러 역할을 맡을 수 있습니다. 그러나 역할의 목적·기준·기록은 분리해야 합니다. 역할을 통합할 수는 있어도 필요한 역할 자체를 삭제해서는 안 됩니다.
14. 현재 역할과 필요 역할의 격차
역할 격차
의미
견적 사례
부재·불명확
필요 역할이 없거나 책임자가 불명
반복오류 분석 없음·도면 최신성 책임 불명
중복·분산
같은 일을 반복하거나 정보가 흩어짐
영업·견적 중복입력·개인별 단가관리
집중
한 사람에게 과도하게 몰림
대표가 모든 견적 검토·승인
충돌
서로 다른 목적·권한이 충돌
수주담당자가 수익성 예외까지 승인
단절
인계 후 책임이 사라짐
제출 후 수신·정정 책임 없음
역량·권한 부족
필요 능력·실행권한이 없음
오류 발견 후 제출을 중단할 수 없음
공식 조직도 밖의 “도면 찾는 사람·과거 견적을 기억하는 사람·문제 시 고객을 설득하는 사람” 같은 숨은 역할도 찾아 특정인 의존과 퇴사 위험을 진단합니다.
15. 사람·AI·시스템 배치 준비
특성
후보
반복적인 검색·요약·분류·비교·누락탐지, 비정형 문서 해석
AI 역할 후보
규칙적 계산·저장·상태·버전·권한·이력관리
코딩 시스템 후보
목표·협상·예외·윤리·법률·안전·최종 판단과 책임
사람 역할
“GPT 견적봇”처럼 기술명으로 정의하지 않고 “견적 누락·불일치 탐지 역할”처럼 기술이 바뀌어도 유지되는 역할로 정의합니다.
16. 역할 관계와 완성도 점검
개별 역할 목록으로 끝내지 않고 입력·출력·완료조건·판단·요청·보고·승인·책임을 연결합니다.
접수→산출→작성→검수→예외·승인→제출·기록
목적·시작조건·입력·출력이 명확한가?
행동·CAC·판단기준·권한이 정의됐는가?
인계 대상과 완료조건이 있는가?
예외·상향·증거·성과지표가 있는가?
수행·검토·승인·최종책임이 구분됐는가?
17. SECTION 12의 최종 결과물
필요 역할 목록업무성과에 필요한 전체 역할
역할 목적문존재 이유와 기대성과
역할 정의서입력·행동·CAC·권한·출력·예외·성과
역할 관계도요청·인계·검토·승인 관계
역할 격차표부재·중복·집중·분산·충돌·단절
책임구조수행·검토·승인·최종책임 구분
SECTION 12 핵심 원칙 역할은 현재 직원의 직급이나 조직도를 옮기는 것이 아니라 요구되는 업무성과를 위해 필요한 행동·판단·권한·책임의 묶음입니다.
기술과 사람을 먼저 정하지 않고 역할을 정의해야 다음 단계에서 가장 적합한 수행방식에 배치할 수 있습니다.
AI는 역할을 수행할 수 있지만 최종 판단과 조직적 책임은 명확한 사람이 맡아야 합니다.
이해 점검
역할과 직책·사람·도구는 어떻게 다른가?
기존 조직도보다 필요한 기능을 먼저 정의해야 하는 이유는?
한 사람이 여러 역할을 맡아도 역할 정의를 분리해야 하는 이유는?
작성·검토·승인 역할을 언제 분리해야 하는가?
“견적 AI”를 역할 중심으로 바꾸면 어떻게 표현할 수 있는가?
SECTION 13
업무규칙을 정하고 사람·코딩 시스템·맞춤 AI 에이전트에 역할 배치하기
필요 역할을 먼저 정의하고 업무규칙을 정한 뒤, 확정적인 업무는 코딩 시스템으로 자동화하고 해석과 추론이 필요한 업무는 도메인 지식을 갖춘 맞춤 AI 에이전트로 구현합니다. 예외판단과 최종 책임은 사람이 맡습니다.
1. 역할 배치란 무엇인가?
역할 배치(Role Allocation)는 SECTION 12에서 정의한 필요 역할과 CAC를 행동 단위로 나누고, 업무규칙·코딩 시스템·맞춤 AI 에이전트·사람 중 가장 적합한 구현방식을 정하는 과정입니다.
필요 역할→행동 분해→업무규칙→수행방식 배치→권한·통제·책임
2. 네 가지 관점을 구분한다
구분
의미
견적 사례
업무규칙
모든 수행 주체가 따라야 할 기준과 조건
최소이윤율·승인한도·제출조건
코딩 시스템
명확한 규칙을 프로그램으로 자동 실행
이윤율 계산·승인경로·발송 차단
맞춤 AI 에이전트
문서와 상황을 해석·추론하며 정의된 역할 수행
누락·불일치·계약위험 탐지
사람
목표·예외·협상·승인·최종 책임 담당
이윤율 미달 예외승인
업무규칙이 판단기준을 정하고, 코딩 시스템과 AI 에이전트가 역할을 수행하며, 사람이 예외와 최종 결과를 책임집니다.
3. 기술이 아니라 역할에서 출발한다
기술 중심 정의
역할 중심 정의
GPT 견적봇
견적 누락·불일치 탐지 역할
Claude 검토도구
계약조건·위험요소 검토 역할
Excel 자동화
수량·단가 계산과 검증 역할
이메일 자동발송
승인 결과물의 고객전달 역할
역할은 유지되지만 이를 구현하는 모델과 도구는 바뀔 수 있습니다. AX는 도구를 끼워 넣는 것이 아니라 필요한 역할을 정의하고 가장 적합한 방식으로 구현하는 것입니다.
4. 역할 전체가 아니라 행동 단위로 배치한다
견적검수 역할의 행동
적합한 수행방식
검수대상 문서·버전 수집, 필수자료 확인
코딩 시스템
문서 의미 파악, 문서 간 비교, 이상후보 탐지
맞춤 AI 에이전트
계약·고객 맥락 해석
사람+맞춤 AI 에이전트
실제 오류·예외 판단, 수정·승인 결정
사람
승인 전 발송 차단, 검수·승인이력 저장
코딩 시스템
5. 업무규칙이란 무엇인가?
업무규칙(Business Rule)은 시작조건·필수자료·계산식·판단기준·허용범위·승인권한·중단·예외보고·완료·기록 기준을 정한 조직의 약속입니다. 수행 주체가 아니라 사람·시스템·AI 모두가 따라야 할 운영기준입니다.
견적 업무규칙
필수자료가 모두 접수되어야 시작한다. 승인된 최신 도면만 사용한다. 목표이윤율 미만이면 제출을 중단한다. 1억 원 이상은 대표 승인을 받는다. 승인되지 않은 견적서는 외부로 발송할 수 없다. AI가 고위험으로 분류한 항목은 사람이 검토한다.
규칙이 먼저입니다. 업무규칙이 불명확하면 사람도 일관되게 판단할 수 없고 코딩 시스템과 AI 에이전트도 안정적으로 작동할 수 없습니다.
6. 업무규칙과 코딩 시스템의 차이
구분
업무규칙
코딩 시스템
역할
무엇을 어떻게 처리할지 정함
규칙을 프로그램으로 실행
형태
정책·기준·조건·권한표·CAC
프로그램·화면·워크플로·DB
사례
승인 전 발송할 수 없다
미승인 상태에서 발송기능 차단
책임
조직이 기준의 적정성을 책임
개발·운영 역할이 정상작동 관리
“이윤율 15% 미만은 대표 예외승인”이라는 규칙을 시스템은 자동계산→일반경로 중단→대표요청→발송차단→승인이력 저장으로 실행합니다.
7. 코딩 시스템이 적합한 영역
코딩 시스템은 입력조건과 처리규칙이 명확하고 같은 조건에서 항상 같은 결과가 나와야 하는 업무환경입니다.
업무
코딩 시스템 역할
자료접수
필수항목이 없으면 접수완료 불가
계산·승인
이윤율 자동계산과 조건별 승인자 지정
상태·버전
최종 승인본 잠금·구버전 사용 방지
권한·실행
승인완료 상태에서만 외부발송 허용
기록·성과
작성·수정·검토·승인·제출이력과 KPI 집계
확정적인 규칙·계산·상태·권한·기록은 AI의 추론보다 코딩 시스템으로 실행·통제하는 것이 안정적입니다.
8. AI 바이브코딩으로 시스템을 제안한다
바이브코딩은 원하는 업무흐름·화면·규칙을 자연어로 설명하고 AI의 도움을 받아 프로그램을 설계·수정하는 개발방식입니다. 접수화면·필수자료 체크·이윤율 계산·승인경로·대시보드·버전·이력·알림·에이전트 검토화면을 빠르게 프로토타입으로 만들 수 있습니다.
AX 제안 문장
견적 접수·승인·이력관리 영역은 업무규칙 기반의 코딩 자동화 시스템으로 설계하고, 초기 검증용 시스템은 AI 바이브코딩을 활용해 신속하게 프로토타입으로 구축한다.
실제 운영 전에는 계산 정확성·사용자 권한·보안·오류처리·백업·연결 안정성·유지보수·변경이력·복구절차를 검증합니다. 바이브코딩은 업무규칙을 대신하지 않고 명확한 규칙을 빠르게 구현하는 방법입니다.
9. AI가 적합하다는 의미
AI가 적합하다는 것은 단순히 ChatGPT에 질문한다는 뜻이 아닙니다. 고객의 자연어 요구, 도면·사진·계약서, 여러 문서의 의미, 과거사례의 유사성, 누락·불일치·이상징후를 해석하고 근거 있는 대안을 제시해야 하는 업무를 뜻합니다.
고정 조건문만으로 어려운 이 영역은 일반 LLM의 일회성 답변에 맡기지 않고, 도메인 지식을 갖춘 맞춤 AI 에이전트로 개발하여 역할에 배치합니다.
10. 단순 LLM과 맞춤 AI 에이전트의 차이
구분
단순 LLM 사용
맞춤 AI 에이전트
작동
사용자가 필요할 때 질문
정해진 조건에 따라 역할 수행
지식
일반 학습지식
회사 규정·업무기준·도메인 지식 연결
맥락
현재 대화 중심
프로젝트·문서상태·프로세스 단계 이해
행동
답변·요약·생성
검색·비교·분류·판단지원·도구 실행
권한·CAC
명확하지 않음
허용권한과 필수행동을 명시
예외·기록
사용자 판단에 의존
고위험을 상향하고 입력·근거·결과·수정이력 관리
성과
답변 만족도
정확도·미탐·오탐·재작업·시간
LLM은 언어를 이해·생성하는 기반 엔진이고, 맞춤 AI 에이전트는 그 엔진에 역할·지식·절차·도구·권한·통제를 결합한 업무 수행자입니다.
11. 맞춤 AI 에이전트의 구성
LLM + 역할 + 도메인 지식 + 업무규칙·절차 + 도구 + 권한 + 기억·상태 + CAC + 사람 보고체계
구성
견적검수 에이전트 사례
역할·목적
제출 전 견적오류 탐지
도메인 지식
공종체계·산출·단가·계약조건·과거오류
입력·절차
요구·도면·산출표·견적 / 버전확인→대조→위험분류→보고
도구
문서검색·DB조회·계산·보고서 작성
권한
조회·분석·추천·보고
CAC·상향
필수 공종·근거 확인 / 고위험·기준불명·신뢰도 미달 보고
성과
탐지율·미탐·오탐·검토시간
맞춤 에이전트가 반드시 새 모델을 학습한다는 뜻은 아닙니다. 기존 LLM에 역할지시·사내 지식베이스·검색·업무도구·워크플로·권한·사람승인·평가기준을 결합해 구현할 수 있습니다.
12. 견적검수 맞춤 AI 에이전트 사례
항목
정의
역할명
견적 누락·불일치 탐지 에이전트
목적
고객 제출 전 오류를 발견하여 재작업과 손실 감소
도메인 지식
인테리어 공종·산출·단가·오류사례·계약·안전·승인기준
핵심행동
버전확인, 요구 구조화, 문서 대조, 누락·이상단가·위험 탐지
출력
이상항목·위험등급·비교근거·수정안·사람 검토요청
허용 권한
조회·검색·비교·분류·추천·보고
제한 권한
원본 임의수정·예외승인·고객발송·최종승인
13. 사람이 맡아야 하는 역할
목표·기준우선순위와 새로운 판단기준 결정
맥락·관계고객 의도·현장상황·이해관계 해석과 협상
예외·책임불완전 정보, 계약·법률·안전·윤리의 최종 판단
AI 관리오탐·미탐 수정, 결과 승인, 지식·기준 개선
AI 도입 후 사람은 모든 문서를 반복 대조하기보다 이상·고위험 중심 검토, 추천사례의 적용 판단, 예외승인과 최종책임에 집중합니다. 기존 업무를 그대로 유지하면 이중작업이 됩니다.
제거하면 안 되는 사람 역할 고객 의도 확인, 계약범위·안전·법률·윤리 판단, 이윤 예외승인, 협상, 새로운 기준 결정, 최종 승인과 사고책임은 신중하게 사람에게 남깁니다.
14. 수행방식 판단 기준
판단항목
사람
맞춤 AI 에이전트
코딩 시스템
업무
협상·예외·책임
해석·비교·추론·생성
계산·저장·통제
입력
복잡한 상황·관계
문서·이미지·자연어
구조화 데이터
기준
불명확·변동적
기준은 있으나 해석 필요
명확·고정적
위험
중대·비가역적
사람이 검토 가능한 중간위험
규칙으로 차단 가능
권한
승인·협상·책임
제한된 추천·실행
정해진 조건의 실행
업무규칙이 먼저 정의됐는가?
항상 같은 결과라면 코딩 시스템이 적합한가?
문서·상황의 의미 해석과 도메인 지식이 필요한가?
AI 결과를 사람이 검증할 수 있는가?
오류가 되돌릴 수 없거나 책임이 중대하면 사람 승인이 필요한가?
실패 시 대체절차가 있는가?
15. 역할 배치 절차와 협업형 구조
필요 역할을 행동 단위로 나눕니다.
행동별 업무규칙을 정의합니다.
명확한 실행·계산·통제는 코딩 시스템에 배치합니다.
해석·비교·추론·생성은 맞춤 AI 에이전트 후보로 분류합니다.
목표·예외·협상·승인·책임은 사람에게 배치합니다.
권한·보고·CAC·증거·대체절차·성과지표를 정합니다.
AI: 분석·근거→사람: 예외·판단→시스템: 승인·통제·기록
저위험 내부업무는 단독 수행도 가능하지만, 고위험 프로세스는 사람+AI+시스템 협업형이 적합합니다.
16. AI 에이전트 권한 수준
수준
AI 권한
사람 역할
0
정보 검색·조회
직접 판단
1
요약·초안
전체 검토·수정
2
분석·분류·추천
선택·결정
3
사람 승인 후 실행
사전승인
4
정해진 저위험 범위 자동실행
예외·성과 감독
금지
최종 책임이 필요한 판단·승인
사람이 직접 수행
17. 사람에게 보고해야 하는 조건
입력자료·버전·승인상태가 불명확합니다.
업무규칙이 충돌하거나 신뢰도가 기준 미달입니다.
과거와 크게 다른 새 상황 또는 고액·저이윤·계약·안전 항목입니다.
개인정보·영업비밀 위험이 있습니다.
AI 판단과 시스템 계산이 다릅니다.
권한 밖의 수정·실행 또는 사람 필수승인이 필요합니다.
좋은 AI 에이전트는 항상 답을 내놓는 존재가 아니라 판단할 수 없는 상황을 식별하여 적절한 사람에게 넘기는 역할까지 수행합니다.
18. 시스템이 AI 권한을 통제한다
통제 대상
코딩 시스템의 통제
자료 접근
허용된 프로젝트·문서만 조회
원본 수정
AI는 제안본·복사본만 작성
승인·외부발송
사람 승인계정과 승인완료 상태에서만 실행
개인정보
민감정보를 마스킹해 전달
기록
AI 입력·결과·수정·승인이력 저장
모델·장애
승인 모델만 연결하고 장애 시 수기절차 안내
프롬프트만으로 안전성을 확보하지 않습니다. 업무규칙·시스템 권한·사람 승인·실행기록을 함께 설계합니다.
19. 통합 적용 사례
영역
최신 승인도면 확인
이윤율 미달 처리
업무규칙
승인된 최신본만 사용
15% 미만 대표 예외승인·제출금지
코딩 시스템
공식본 상태·버전·이전본 차단
자동계산·승인경로·발송차단·기록
맞춤 AI 에이전트
문서 간 도면정보 불일치와 근거 제시
원인·유사견적 분석과 조정안 추천
사람
불일치 해소·적용도면 최종확정
전략·손실·고객관계 판단과 예외승인
20. 견적 프로세스 역할 배치 매트릭스
핵심업무
업무규칙
코딩 시스템
맞춤 AI 에이전트
사람
자료접수
필수자료 기준
누락 시 시작차단
요구 구조화
불명확 요구 확인
도면관리
승인 최신본
버전·상태·권한
버전 불일치 탐지
적용본 확정
수량·단가
산출·유효기준
계산·DB·저장
누락·이상단가 탐지
예외 적용 판단
견적검수
필수 검사항목
상태·이력 관리
누락·불일치·위험
오류·예외 판단
이윤·승인
최소이윤·권한
계산·승인경로
원인·조정안 추천
예외승인
고객제출
승인본만 제출
발송차단·기록
메일 초안
승인·협상
성과관리
KPI·개선주기
집계·대시보드
오류패턴 분석
기준 개선
21. 인계조건과 책임구조
인계
완료조건
코딩 시스템→AI 에이전트
분석 문서와 버전 확정
AI 에이전트→사람
이상항목·위험등급·근거 제공
사람→코딩 시스템
수정·예외판단·승인 완료
코딩 시스템→고객제출
승인상태·최종버전·수신자 확인
책임
견적 사례
수행
AI가 누락·불일치 탐지
검토
견적담당자가 근거 검증
승인
견적책임자가 제출 허가
최종 책임
승인권자가 결과에 조직적 책임
22. ERRC로 AI 도입효과 재확인
ERRC
견적검수 에이전트 도입효과
제거
사람의 문서 수기 전수대조
축소
전체항목 검토를 이상·고위험 중심으로 전환
강화
전수검사·일관성·사전탐지·근거기록
창조
상시검수·조기경고·반복오류 학습
23. AX 제안의 세 가지 구현안
구현안
제안 내용
업무규칙 정비안
기준·권한·CAC·예외·승인조건 표준화
바이브코딩 시스템안
계산·상태·승인·권한·기록 자동화
맞춤 AI 에이전트안
해석·추론·검색·비교·생성 역할을 도메인 특화
통합 AX 제안 문장
견적의 시작조건·단가 유효기간·승인권한·제출조건은 업무규칙으로 표준화합니다. 계산·승인경로·버전·발송통제·이력은 AI 바이브코딩 기반 업무시스템으로 구현합니다. 요구사항 해석과 도면·산출표·견적서의 누락·불일치 탐지는 인테리어 견적 도메인 지식을 갖춘 맞춤 AI 에이전트에 배치합니다. 예외판단·고객협상·최종승인은 사람이 담당합니다.
24. 위험과 적정성 점검
위험
점검 질문
규칙·코딩 오류
기준이 명확하고 계산·승인·차단이 정확한가?
단순 LLM·과도의존
도메인 역할로 설계했고 장애 시 대체할 수 있는가?
이중업무·책임공백
사람이 전부 반복하지 않으며 오류 시 책임자가 있는가?
권한·형식적 검토
AI의 수정·승인·발송을 제한하고 사람이 실제 검토하는가?
데이터·기준 노후화
기밀을 보호하고 규칙·지식을 갱신하는 역할이 있는가?
기술 종속·성과착시
도구가 바뀌어도 역할이 유지되며 오탐·미탐·재작업을 측정하는가?
25. 역할 배치 통합설계표
항목
견적 누락·불일치 탐지 사례
목표·규칙
제출 전 오류발견 / 최신도면·필수공종·유효단가·승인조건
코딩 시스템
문서수집·버전·접근권한·발송차단·이력
맞춤 AI 에이전트
문서 대조·누락·불일치·이상단가 탐지
도메인 지식
공종·산출·단가·오류사례·계약조건
사람 역할
오류확인·예외판단·수정·최종승인
권한·제한
조회·분석·추천·보고 / 원본수정·예외승인·발송 금지
상향·CAC
고위험·기준불명·신뢰도 미달 / 버전·근거·사람승인
실패·책임
중단·보고·수기전환 / 견적책임자
성과지표
검토시간·탐지율·오탐·미탐·재작업·제출 후 오류
26. SECTION 13의 최종 결과물
업무규칙표시작·판단·승인·중단·완료기준
행동·수행방식표사람·시스템·에이전트 적합성
바이브코딩 시스템안계산·워크플로·권한·기록 프로토타입
맞춤 에이전트 정의서역할·지식·도구·권한·보고조건
사람 역할 변화표AI 도입 후 제거·축소·강화되는 역할
인계·통제·성과완료조건·차단·대체절차·측정기준
SECTION 13 핵심 원칙 먼저 업무규칙을 명확하게 정의합니다. 확정적인 계산·조건·권한·기록은 코딩 시스템으로 자동화하고, AI 바이브코딩으로 프로토타입을 빠르게 제안할 수 있습니다.
문서·이미지·상황의 해석과 추론은 단순 LLM 사용에 머물지 않고 도메인 지식을 갖춘 맞춤 AI 에이전트로 구현합니다.
업무규칙이 기준을 정하고, 코딩 시스템이 확정적인 업무를 실행·통제하며, 맞춤 AI 에이전트가 해석·추론을 수행하고, 사람이 예외를 판단하고 최종 책임집니다.
이해 점검
업무규칙과 코딩 시스템은 어떻게 다른가?
명확한 규칙업무를 AI 에이전트보다 시스템에 맡겨야 하는 이유는?
바이브코딩은 AX 제안에서 무엇을 구현하는 방법인가?
단순 LLM과 맞춤 AI 에이전트의 차이는?
맞춤 에이전트에 도메인 지식·CAC·권한·보고조건이 필요한 이유는?
AI에게 허용·제한할 권한은 무엇인가?
AI가 반드시 사람에게 보고해야 하는 상황은?
사람·시스템·에이전트가 협업할 때 최종 책임자는 누구인가?
SECTION 14
미래형(To-Be) 프로세스 청사진 그리기
SECTION 13에서 업무규칙을 정하고 필요한 역할의 구현방식을 배치했습니다. 이제 고객 요청부터 결과 전달까지 사람·코딩 시스템·맞춤 AI 에이전트가 어떤 순서로 일하고, 어떤 조건에서 결과를 넘기며, 예외가 생기면 어떻게 멈추고 복구하는지 하나의 흐름으로 연결합니다.
1. To-Be 프로세스란 무엇인가?
미래형(To-Be) 프로세스는 개선 후 조직이 실제로 운영할 업무흐름입니다. 시작조건·수행주체·행동·판단·출력·인계·예외·종료조건을 연결하여 목표성과를 반복해서 만들 수 있어야 합니다.
To-Be = 목표성과 + 새 업무흐름 + 역할별 행동 + 인계조건 + 통제·예외 + 측정방법
AI를 어느 단계에 쓰는지만 표시한 그림이나 기존 순서에서 사람 이름을 AI로 바꾼 그림은 운영 가능한 To-Be가 아닙니다.
2. 앞 섹션의 결과물을 이어받는다
앞 단계
To-Be에 반영할 결정
현재형(As-Is)과 성과격차
현재 흐름, 지연·오류 지점, 개선 전 기준선
ERRC
제거·축소할 업무와 강화·창조할 행동
CAC
시작·이동·종료 관문에서 반드시 수행할 핵심행동
필요 역할
성과를 만드는 역할의 목적·권한·출력·책임
역할 구현방식
업무규칙, 코딩 시스템, 맞춤 AI 에이전트, 사람의 배치
작성 전 확인 As-Is와 개선 전 수치를 지우지 않습니다. 무엇이 달라졌고 효과가 있었는지 비교할 기준으로 남겨 둡니다.
3. 시작과 끝을 먼저 고정한다
To-Be의 범위는 SECTION 02에서 정한 프로세스 범위와 맞춥니다. 견적 사례의 시작은 고객의 견적 요청과 필요한 자료의 접수, 끝은 고객에게 승인된 견적을 전달하고 발송·승인이력을 기록한 상태입니다.
항목
견적 사례
시작 사건
고객의 견적 요청 접수
시작 가능 조건
요구사항·도면·납기 등 필수자료 확인, 자료 상태 기록
종료 결과
승인된 견적의 고객 전달과 증거 보관
종료 금지 조건
미승인 견적, 적용도면 불명, 필수 검수 미완료
자료가 부족한 요청도 사라지는 일이 없도록 접수는 기록합니다. 다만 자료 보완 전에는 산출 시작을 보류하도록 별도의 상태를 둡니다.
4. 역할별 레인을 만든다
스윔레인은 담당자의 이름이나 제품명이 아니라 역할명으로 만듭니다. 한 레인에 놓인 행동은 해당 역할이 실제 수행해야 합니다.
레인
주요 행동
영업·고객소통 담당
요청 접수, 부족한 자료 확인, 고객과의 전달·협의
코딩 시스템
필수자료·버전·상태 확인, 계산, 접근권한·승인경로·발송 통제와 기록
견적 담당
수량·단가 적용, AI 결과 검토, 견적 수정
견적검수 맞춤 AI 에이전트
요구·도면·산출표·견적서의 의미를 비교하고 누락·불일치 근거 제시
견적책임자·승인권자
고위험·예외 판단, 제출 승인, 결과에 대한 최종 책임
업무규칙은 레인에 앉아 일하는 주체가 아니라 모든 레인의 행동을 제한하고 판단하는 기준입니다. 코딩 시스템은 그중 명확한 규칙을 실행하거나 위반을 차단합니다.
5. 정상 경로를 단계·출력·인계조건으로 작성한다
단계
주체와 행동
출력
다음 단계 조건
① 접수
영업 담당이 고객 요구와 자료를 접수
요청기록·자료목록
누가 무엇을 요청했는지 확인
② 시작 관문
시스템이 필수자료·승인 도면 버전을 확인
자료상태·적용본
부족·구버전 자료가 해소됨
③ 산출·작성
견적 담당이 수량·단가를 적용하고 시스템이 계산
근거를 포함한 견적초안
계산·공종·단가 검증 통과
④ 의미 검수
맞춤 AI가 문서 간 누락·불일치·위험을 탐지
위치·근거·위험등급이 있는 검수결과
검토할 항목과 근거가 확인됨
⑤ 수정·검토
견적 담당이 AI 결과를 검증하고 수정
수정본·검토기록
미해결 이상항목 처리 또는 예외 상향
⑥ 승인
책임자가 이윤·계약·예외를 판단하고 승인
승인된 최종본·승인기록
제출조건과 승인권한 충족
⑦ 전달·종료
시스템이 최종본·수신자·승인상태를 확인하고 발송을 기록
발송본·이력
고객 전달 및 증거 보관 완료
각 단계에서 “완료”는 행동을 시작했다는 뜻이 아니라 다음 역할이 이어서 일할 수 있는 출력과 증거가 준비됐다는 뜻입니다.
6. 인계는 결과물과 수용조건을 함께 적는다
인계
결과물
받는 쪽의 수용조건
시스템 → 견적 담당
확인된 자료목록·승인 도면 버전
산출에 사용할 적용본이 하나로 확정됨
견적 담당 → AI
요구사항·적용도면·산출표·견적초안
같은 프로젝트·버전으로 분석 가능
AI → 견적 담당
이상항목·문서 위치·근거·불확실성
담당자가 원자료로 재검증 가능
견적 담당 → 승인권자
수정본·남은 쟁점·이윤·검토기록
예외와 승인 필요사항이 드러남
승인권자 → 시스템
최종 승인과 승인본
권한·상태·버전·수신자 조건 충족
“AI가 불일치를 발견했다”는 완료가 아닙니다. 어느 도면의 무엇이 어떤 견적 항목과 다른지 확인할 수 있어야 담당자가 이어받을 수 있습니다.
7. 판단·분기·되돌림을 그린다
판단 질문
예
아니오·불명확
필수자료와 승인 도면이 갖춰졌는가?
산출 시작
자료보완 요청·시작 보류
AI가 근거를 제시하고 담당자가 확인했는가?
수정 또는 검수완료
재분석·원자료 확인·사람에게 상향
이윤·계약·승인 기준을 충족하는가?
최종 승인
조정·예외승인 또는 제출 중단
승인본·수신자·발송조건이 일치하는가?
고객 전달
발송 차단·정정 후 재확인
분기마다 판단기준, 판단자, 되돌아갈 단계, 재개조건을 적습니다. 보류 상태가 영구 대기가 되지 않도록 담당자와 후속 확인 시점도 정합니다.
8. CAC를 시작·이동·종료 관문에 붙인다
관문
빠뜨리면 안 되는 행동
실패 시
시작
필수자료·도면 버전·승인상태 확인
산출 보류·보완 요청
이동
산출근거와 AI 이상항목·검토결과 확인
수정·재검수·책임자 보고
종료
이윤·계약 예외승인, 최종버전·수신자 확인
제출 차단·승인 절차 재개
AI의 검수행동과 사람의 AI 결과 검토행동을 각각 표시합니다. 같은 사람이 여러 역할을 맡더라도 작성·검토·승인의 기준과 기록을 구분합니다.
9. 예외와 장애의 대체 경로를 만든다
상황
즉시 처리
재개 조건
최신 도면 불명·자료 누락
산출 보류, 자료 소유자에게 확인 요청
공식 적용본 확정
AI 근거 없음·판단 불가
자동 통과 금지, 담당자 원자료 검토
검토기록과 해결·상향 결과 등록
AI 결과와 시스템 계산 충돌
제출 보류, 기준·입력·계산식 재확인
차이의 원인과 정정내용 확인
이윤·계약·안전의 중대 예외
정해진 승인권자에게 상향
사람의 명시적 판단과 승인
에이전트·시스템 장애
장애기록, 승인된 수기 검토 절차로 전환
필수 검수·승인 증거 확보 후 정상화
대체 경로를 만들었다고 필수 CAC를 생략할 수 있는 것은 아닙니다. 누가 수기로 확인하고 어떤 증거를 남기는지 정합니다.
10. 권한과 책임을 단계마다 확인한다
AI는 허용된 프로젝트의 자료를 조회·비교하고 근거와 추천을 제시합니다. 원본수정·예외승인·외부발송 권한은 별도 승인 없이 주지 않습니다.
시스템은 승인 상태·접근권한·버전·발송조건을 확인하고 위반 시 차단·기록합니다.
사람은 불명확한 고객 의도, 예외, 계약·안전·이윤과 최종 승인을 판단합니다.
각 단계의 수행·검토·승인·최종책임을 구분해 기록합니다.
업무규칙과 권한이 바뀌면 그림만 고치는 것이 아니라 시스템 조건, 에이전트 지식·지시, 담당자 절차도 함께 갱신합니다.
11. As-Is와 나란히 비교해 이중업무를 없앤다
관점
현재형(As-Is)
미래형(To-Be)
자료
담당자가 메일·폴더에서 수작업으로 최신본 탐색
시스템이 상태·버전을 확인, 사람은 모호한 자료 확정
검수
담당자의 수기 전수 대조
AI가 전수 비교·근거 제시, 사람은 이상·고위험과 오류 확인
계산
개인별 엑셀 계산과 수기 확인
시스템이 정해진 계산·차단·이력을 일관되게 실행
제출
승인 상태를 메일로 다시 확인
승인본만 발송 가능, 승인권자가 예외·최종 결과 판단
기존 수기 검토를 그대로 둔 채 AI 검수만 추가하면 이중업무가 됩니다. ERRC의 제거·축소·강화·창조 항목과 새 사람 역할을 이 비교에서 다시 확인합니다.
12. 성과와 통제 효과를 측정한다
성과 질문
예시 지표
함께 볼 역효과
견적이 빨라졌는가?
접수→승인 평균시간, 대기·재작업 시간
AI 검토·예외처리로 늘어난 시간
품질이 좋아졌는가?
제출 전 탐지율, 제출 후 오류·재작업률
AI 오탐·미탐, 형식적 사람 승인
통제가 강화됐는가?
구버전 사용·미승인 발송·CAC 누락 건수
승인 지연·우회·수기 예외 증가
고객성과가 개선됐는가?
견적 회신시간, 고객 수정요청·분쟁 건수
고객 맥락 누락·설명 부족
측정기준·집계 주기·책임자·개선 전 기준선을 함께 적습니다. 처리시간 하나만 개선되고 고객 오류가 늘었다면 성공한 To-Be가 아닙니다.
13. 한 장의 청사진에 표시할 필수 정보
시작 사건과 종료 결과, 고객에게 전달되는 가치
역할별 레인과 순서, 업무별 입력·출력
업무규칙과 시스템 자동행동, 맞춤 AI의 해석·추론 행동
판단·분기·보류·되돌림 및 재개 조건
시작·이동·종료 관문의 CAC와 승인권한
인계 결과물·수용조건·증거, 예외·장애 대체 경로
As-Is와 비교할 성과지표와 최종 책임자
그림이 복잡하면 전체 흐름은 한 장에 두고 복잡한 예외·검수 절차만 하위 청사진으로 분리합니다. 전체 흐름에서 하위 절차의 시작점과 복귀점을 표시합니다.
14. 작성 순서
범위·목표→역할 레인→정상 경로→분기·인계→CAC·권한→예외·측정
고객 결과와 개선 목표를 다시 적습니다.
SECTION 12~13의 필요 역할과 구현방식을 레인으로 놓습니다.
정상 경로를 행동·출력 단위로 연결합니다.
각 인계에 수용조건을, 각 판단에 실패·되돌림 경로를 붙입니다.
CAC, 시스템 차단, 사람의 승인·책임을 관문에 배치합니다.
예외·장애 경로와 증거, As-Is 대비 성과지표를 적습니다.
실제 견적 사례 한 건을 시작부터 종료까지 따라가며 빈 단계와 책임공백을 찾습니다.
15. 견적 사례로 끝까지 따라가기
도면 변경이 있는 견적 요청
고객이 견적을 요청하지만 첨부한 도면이 승인본인지 불분명합니다. 영업 담당은 요청을 접수·기록합니다. 시스템은 적용 도면을 확정할 수 없어 산출 시작을 보류합니다. 담당자가 고객에게 공식본을 확인받으면 시스템이 버전과 상태를 기록하고 견적 담당자가 산출·작성합니다.
맞춤 AI 에이전트는 승인 도면의 변경 부분과 견적초안을 비교해 누락 가능성을 위치·근거와 함께 알립니다. 견적 담당자는 원도면으로 확인해 수정하거나 오탐 이유를 기록합니다. 이윤율이 승인기준 미달이면 시스템이 제출을 차단하고 승인권자에게 상향합니다. 승인권자가 조정 또는 예외승인을 결정한 뒤 시스템이 승인본·수신자를 다시 확인하여 발송·기록합니다.
이 사례에는 정상 경로뿐 아니라 도면 불명→보류→자료확정→재개, AI 이상탐지→사람 검증→수정, 이윤 예외→발송차단→사람 승인의 세 갈래가 함께 그려져야 합니다.
16. 완성도 점검
시작·끝과 고객이 받는 결과가 명확한가?
각 행동이 실제 역할의 레인에 있고, 업무규칙과 시스템 행동이 구분되는가?
AI의 근거·불확실성과 사람이 검증할 원자료가 함께 넘어가는가?
판단 실패·자료 부족·장애 때 멈춤·보고·재개 경로가 있는가?
작성·검토·승인·발송의 권한과 최종 책임이 보이는가?
ERRC로 제거한 일을 사람이 계속 반복하지 않는가?
As-Is 기준선과 비교해 시간·품질·위험·고객성과를 측정할 수 있는가?
17. SECTION 14의 최종 결과물
To-Be 스윔레인 청사진역할별 정상·예외 흐름
인계·완료조건표출력·받는 사람·수용조건·증거
분기·예외표판단기준·보류·되돌림·재개
CAC·권한 배치표시작·이동·종료 관문과 승인
As-Is/To-Be 비교표ERRC와 사람 역할 변화
성과측정안기준선·지표·역효과·책임자
SECTION 14 핵심 원칙 To-Be는 새 도구를 배치한 그림이 아니라 성과가 만들어지는 실행 흐름입니다. 각 단계는 누가 어떤 입력을 받아 무엇을 판단·수행하고, 어떤 결과와 증거를 어떤 조건으로 넘기는지 보여줘야 합니다.
정상 경로와 함께 보류·되돌림·사람의 예외판단·장애 대응을 설계합니다. 업무규칙은 기준을 정하고, 코딩 시스템은 명확한 규칙을 실행·통제하며, 맞춤 AI 에이전트는 해석·추론의 근거를 제시하고, 사람이 최종 판단과 책임을 맡습니다.
이해 점검
To-Be 청사진과 단순 업무순서도는 어떻게 다른가?
업무규칙을 사람·시스템·AI 레인과 어떻게 구분할 것인가?
AI의 누락 탐지 결과를 담당자에게 넘길 때 어떤 근거가 필요한가?
자료·도면이 불명확하거나 승인되지 않았을 때 어디서 멈추고 어떻게 재개하는가?
As-Is와 비교해 이중업무와 도입 효과를 어떻게 확인하는가?
SECTION 15
PoC로 To-Be를 검증하고 AX 제안과제로 전환하기
SECTION 14에서 완성한 To-Be는 “이렇게 일하면 목표한 업무성과를 만들 수 있다”는 설계안입니다. SECTION 15에서는 실제 업무자료와 조직의 운영 조건에서도 그 설계가 작동하는지 작은 범위에서 검증합니다. 이를 PoC(Proof of Concept, 개념 검증)라고 합니다.
PoC의 목적은 AI 기능을 한 번 시연하는 것이 아닙니다. 새 업무흐름이 기존보다 업무성과를 높이면서 오류와 책임을 통제할 수 있는지 경영자가 판단할 근거를 만드는 것입니다.
1. 무엇을 검증할 것인가?
To-Be 전체를 한꺼번에 구현하기보다, 성과에 영향이 크고 결과를 측정할 수 있는 구간을 고릅니다. 견적 프로세스라면 ‘고객 제출 전 누락·불일치 검수’가 PoC 후보가 됩니다.
검증 대상
확인할 질문
업무성과
검토시간과 제출 후 오류가 줄어드는가?
업무규칙
필수자료·적용도면·승인조건을 명확하게 정하고 적용할 수 있는가?
AI 바이브코딩 기반 업무시스템
개발한 시스템이 버전 확인·계산·권한 통제·발송 차단·기록을 정확히 수행하는가?
도메인 맞춤 AI 에이전트
도면·산출표·견적서의 누락과 불일치를 근거와 함께 찾아내는가?
사람 역할
담당자가 AI 결과를 검증하고 예외를 판단할 수 있는가?
운영 가능성
자료 준비, 권한 관리, 기준 갱신과 장애 대응을 지속할 수 있는가?
AI 바이브코딩은 업무시스템을 개발하는 방법입니다. 개발된 시스템은 운영 중에 확정적인 업무규칙·계산·권한·기록을 코드로 실행합니다. 문서의 의미를 해석하고 추론하는 일은 별도의 도메인 맞춤 AI 에이전트가 맡습니다.
2. 검증 가설을 문장으로 쓴다
견적 PoC의 가설은 다음처럼 쓸 수 있습니다.
견적 검수 PoC 가설
“AI 바이브코딩으로 개발한 업무시스템이 승인된 최신 도면과 견적초안을 연결하고, 도메인 맞춤 AI 에이전트가 누락·불일치를 근거와 함께 제시하면, 견적 담당자는 수기 전수대조 시간을 줄이면서 제출 전 오류를 더 많이 발견할 수 있다.”
이 문장에는 어떤 조건에서, 시스템·에이전트·사람이 각각 무엇을 하고, 어떤 업무성과가 달라질 것인지가 들어 있습니다. “견적에 AI를 도입한다”만으로는 검증할 수 없습니다.
3. 검증 범위와 비교 기준을 정한다
PoC를 시작하기 전에 대표적인 견적 사례를 선정합니다. 정상 사례뿐 아니라 도면 변경, 자료 누락, 모호한 고객 요구, 단가 이상, 승인 예외도 포함합니다. 실제 고객에게 발송하기 전 단계에서 기존 방식과 To-Be 방식을 비교합니다.
사전에 정할 항목
견적 PoC 예시
시작·종료
자료 접수부터 제출 승인 전 검수까지
검증 자료
승인 도면, 고객 요구사항, 산출표, 단가자료, 견적초안
기존 기준선
현재 검수시간, 발견 오류, 제출 후 수정 건수
비교 방법
같은 유형의 견적을 기존 방식과 새 흐름으로 검토
범위 제외
고객 자동 발송, AI의 예외승인·원본 수정
성공 기준과 중단 기준은 결과를 보기 전에 합의합니다. 결과를 본 뒤 기준을 바꾸면 경영자가 투자 여부를 판단하기 어렵습니다.
4. 성공은 속도·품질·통제를 함께 본다
항목
측정 방법
함께 확인할 역효과
시간
견적 1건당 검수·수정 소요시간
AI 결과를 재확인하는 시간
품질
실제 누락·불일치 발견 건수, 제출 후 오류
AI의 오탐·미탐
통제
구도면 사용, 미승인 제출, CAC 누락 건수
승인 우회·형식적 검토
사람의 부담
예외 검토·재작업·상향 건수
일이 줄지 않고 다른 단계로 옮겨갔는지
운영
자료 준비시간, 장애, 기준 갱신 노력
담당자가 지속 운영할 수 있는지
처리시간이 줄어도 중요한 오류를 놓치거나 사람의 재검토 부담이 커졌다면 설계를 고쳐야 합니다. 반대로 시간이 크게 줄지 않아도 중대한 제출 오류를 예방했다면 그 효과를 별도로 평가해야 합니다.
각 지표에는 측정방법·기존 기준선·목표값·측정 책임자를 정합니다. 목표값은 해당 조직의 실제 자료를 확인한 뒤 설정합니다.
5. PoC에서 네 영역을 실제로 나누어 시험한다
영역
PoC에서 수행할 일
검증할 결과
업무규칙 정비
공식 도면, 단가 유효기간, 필수 검수항목, 승인권한을 정의
사람과 시스템이 같은 기준을 적용하는가?
AI 바이브코딩 기반 업무시스템 개발
버전·상태 확인, 확정적인 계산, 접근권한, 발송 차단, 검수·승인 기록을 구현
정해진 조건을 정확하고 일관되게 실행하는가?
도메인 맞춤 AI 에이전트 개발
인테리어 견적의 공종·산출·단가·계약조건을 바탕으로 문서의 의미를 비교
누락·불일치를 원자료 위치와 근거를 제시하며 탐지하는가?
사람의 업무 전환
AI 결과의 진위를 확인하고 고객 의도·예외·최종 승인을 판단
검토와 책임이 실제로 수행되는가?
PoC 중 AI가 제시한 항목마다 원자료 위치, 판단 근거, 담당자의 확인 결과를 남깁니다. 그래야 “무언가를 찾아냈다”와 “정확하게 찾아냈다”를 구분할 수 있습니다.
바이브코딩으로 만들더라도 검증은 생략하지 않습니다. 업무규칙 자체의 승인과 계산·권한·차단 기능의 검증이 필요합니다.
6. 결과에 따라 확대·수정·중단을 결정한다
결정
판단 상황
다음 행동
확대
성과·품질·통제 기준을 충족하고 운영 가능
적용 범위와 담당 조직을 단계적으로 확대
수정 후 재검증
효과는 있지만 오탐·자료 품질·인계·시스템 오류가 큼
규칙·시스템·에이전트 지식·사람의 검토 절차를 고쳐 재시험
중단 또는 과제 전환
순효과가 없거나 위험을 통제하기 어려움
해당 구현을 멈추고 원인에 맞는 개선과제로 전환
PoC가 목표를 충족하지 못해도 어디에서 막혔는지 확인했다면 의사결정에 필요한 결과를 얻은 것입니다. 예를 들어 도면의 공식 버전을 구분할 수 없다면 에이전트 성능 개선보다 도면관리 규칙과 시스템 정비가 먼저일 수 있습니다.
7. PoC 결과를 AX 제안과제로 바꾼다
AX 제안서는 도구 목록이 아니라 다음 의사결정 흐름으로 작성합니다.
현재 성과·격차·원인→목표성과·To-Be→PoC 결과→구축·운영 과제→경영자 결정
현재 업무성과 → 성과격차와 구조적 원인 → 목표성과 → To-Be 역할·업무흐름 → PoC 검증 결과 → 구축·운영 과제 → 예상 효과와 위험 → 경영자의 결정사항 순서로 설명합니다.
제안과제
구현 내용
책임 주체
업무규칙 정비
공식 도면, 단가 유효기간, 검수·예외승인 기준
업무책임자·승인권자
AI 바이브코딩 기반 업무시스템 개발
버전·계산·상태·권한·발송 차단·이력 기능 개발
업무책임자·시스템 개발 담당자
도메인 맞춤 AI 에이전트 개발
도면·산출표·견적서의 의미 비교와 근거 있는 이상탐지
견적 도메인 담당자·에이전트 개발 담당자
사람의 업무 전환
수기 전수대조 축소, 이상 검증·예외판단 강화
견적 담당자·견적책임자
운영·학습 체계
오탐·미탐 기록, 업무규칙·시스템·도메인 지식 갱신
지정된 운영 책임자
‘AI 바이브코딩 기반 업무시스템 개발’과 ‘도메인 맞춤 AI 에이전트 개발’은 별개의 개발과제입니다. 전자는 정해진 조건을 안정적으로 실행하도록 만들고, 후자는 도메인 지식을 바탕으로 해석·추론하는 역할을 구현합니다. 두 결과물이 실제 프로세스에서 인계되고 사람의 검토·승인으로 연결되어야 합니다.
경영자에게 요청할 결정
“어떤 업무성과를 위해 업무규칙을 정비하고, 어떤 시스템과 에이전트를 개발하며, 사람의 역할을 어떻게 바꿀 것인가? PoC 결과에 근거할 때 어디까지 투자하고 누가 운영할 것인가?”
SECTION 15의 최종 결과물
PoC 계획서검증 가설·범위·사례·담당자·기간
사전 판정 기준기존 기준선, 성공·중단 조건
검증 기록업무시스템 실행, 에이전트 탐지 근거, 사람 확인·승인
성과 비교표시간·품질·통제·운영 부담 변화
AX 제안과제 목록업무규칙, 바이브코딩 시스템, 맞춤 에이전트, 사람 역할, 운영체계
경영자 의사결정안확대·수정 후 재검증·중단 중 권고와 근거
SECTION 15 핵심 원칙 PoC는 AI 기능의 시연이 아니라 To-Be 프로세스가 목표한 업무성과를 실제로 만드는지 검증하는 과정입니다. 확정적인 업무는 AI 바이브코딩으로 개발한 시스템에서 실행하고, 해석·추론은 도메인 맞춤 AI 에이전트가 수행하며, 예외판단·승인·최종 책임은 사람이 맡습니다. 그 검증 결과를 AX 제안의 근거로 사용합니다.
AX코칭 전문가 과정 · MODULE 03
AX 지식관리 방법론
조직의 정체성을 이어가는 실전 교안
로컬에서 업무지식을 생성·검증하고, 서버에서 안전하게 지식화·연결·인덱싱하며, 다시 로컬에서 활용·융합·재생산하는 3단계 AX 지식관리 실전 교안
AX 지식관리 1단계 로컬 생성 → 2단계 서버 지식화 → 3단계 로컬 재활용
과정 안내
왜 AX에서 지식관리를 배우는가?
AX(AI Transformation, 인공지능 기반 조직 전환)는 범용 AI를 직원에게 제공하는 것만으로 완성되지 않습니다. 조직이 업무를 통해 축적한 지식과 규칙을 AI가 활용할 수 있는 체계로 만들고, AI가 사람과 같은 업무 맥락 안에서 역할을 수행하도록 해야 합니다.
현장 지식 생성→조직지식 가공·축적→사람·AI 공동 활용→새로운 지식 재생산
지식관리는 AX를 움직이는 연료이며, 조직의 정체성을 AI에게 전달하고 사람과 AI가 같은 기준으로 협업하게 만드는 초석입니다.
SECTION 01
지식관리의 개념과 목적
지식관리는 자료를 저장하는 일이 아니라, 사람과 AI가 업무 중 필요한 근거를 찾아 판단에 사용하고, 그 결과를 다시 조직의 지식으로 축적하는 체계입니다.
1. 지식관리란?
업무 중에는 문서만 만들어지는 것이 아닙니다. 고객의 요구, 담당자의 판단, 문제를 해결한 방법, 시행착오, 예외 처리, 승인 이유와 업무 결과가 함께 발생합니다. 지식관리는 이러한 자료와 경험이 사라지지 않도록 모으고, 필요한 업무에서 다시 사용할 수 있도록 연결하고, 사용 결과를 통해 계속 개선하는 활동입니다.
2. 자료저장과 지식관리의 차이
구분
자료저장
AX 지식관리
핵심 질문
파일을 어디에 보관할 것인가?
누가 어떤 업무에서 어떤 근거를 사용하고, 그 결과를 어떻게 다시 지식으로 만들 것인가?
관리 대상
문서·파일·폴더
원본자료·업무맥락·판단기준·관계·경험·결과
사용 주체
주로 사람
사람·업무시스템·AI
완료 기준
정해진 위치에 저장
필요한 순간에 검색·활용되고 새로운 지식으로 환류
3. 지식관리의 직접적인 목적
업무 활용필요한 지식을 필요한 순간에 찾아 판단과 행동에 사용
조직 기억담당자가 바뀌어도 업무경험과 판단근거를 조직에 유지
공동 기준사람과 AI가 같은 원본·규칙·승인된 지식을 바탕으로 협업
지속 학습업무 결과와 시행착오를 다시 지식으로 만들어 조직의 역량을 확대
첫 번째 원칙 지식의 가치는 저장량이 아니라 업무에서 사용되고, 판단과 결과를 개선하며, 다시 조직의 지식으로 돌아오는가로 판단합니다.
강의 점검 질문
우리 조직은 지식을 관리하고 있는가, 파일을 보관하고 있는가?
업무 중 만들어지는 판단과 경험은 어디에 남는가?
저장된 자료가 실제 업무에서 다시 사용되고 있는가?
SECTION 02
AX의 연료와 조직의 정체성
업무를 수행하며 축적한 판단 기준과 경험은 조직이 무엇을 중요하게 여기고 어떤 방식으로 고객가치를 만드는지를 보여주는 조직의 정체성입니다.
1. 조직지식은 왜 정체성인가?
같은 업종의 회사라도 고객을 이해하는 방식, 견적을 판단하는 기준, 문제를 해결하는 순서, 품질을 정의하는 수준과 위험을 다루는 방식은 서로 다릅니다. 이 차이는 조직이 오랜 시간 업무를 수행하며 축적한 지식에서 만들어집니다.
업무경험 + 판단기준 + 시행착오 + 고객 대응방식 = 조직의 정체성을 표현하는 지식체계
2. 조직지식이 없는 AI
AI는 일반화된 지식을 가지고 있지만 우리 조직이 축적한 경험과 판단기준까지 알고 있지는 않습니다. 조직의 지식체계가 없다면 AI는 누구에게나 적용되는 범용적인 방식으로 일할 수밖에 없습니다.
구분
범용 지식에만 의존하는 AI
조직지식을 활용하는 AI
판단 기준
일반적인 사례와 평균적인 방법
조직의 승인기준·업무규칙·과거 사례
업무 맥락
사용자가 매번 설명해야 함
고객·프로젝트·업무단계와 연결된 맥락 활용
결과
어느 조직에서나 나올 수 있는 범용 결과
조직의 방식과 고객가치를 반영한 결과
학습
업무결과가 다음 업무에 축적되지 않음
검토·수정·승인 결과가 조직지식으로 환류
3. AI를 훈련시킨다는 의미
여기에서 AI를 훈련시킨다는 것은 모델 자체를 새로 학습시키는 것만 뜻하지 않습니다. 조직의 문서·업무규칙·사례·피드백을 AI가 검색하고 참조하며, 역할 수행 과정에서 지속적으로 활용하게 만드는 것까지 포함합니다.
우리의 지식이 없다면 AI는 일반적인 방식으로 일합니다. 우리의 지식체계가 있을 때 AI는 비로소 우리 조직의 맥락과 기준 안에서 협업할 수 있습니다.
두 번째 원칙 지식체계는 AI가 우리 조직의 정체성과 업무기준을 이해하고 사람과 같은 맥락에서 협업하게 만드는 AX의 연료입니다.
SECTION 03
로컬·서버·로컬 3단계 순환구조
비즈니스 조직의 지식관리는 현장에서 태어난 지식이 서버에서 조직지식으로 가공되고, 다시 현장으로 돌아와 새로운 지식으로 재생산되는 순환구조입니다.
1. 로컬: 생성→2. 서버: 가공·축적→3. 로컬: 활용·융합·재생산→서버로 환류
1단계. 로컬 — 업무지식의 생성
담당자의 업무 현장에서는 고객과의 대화, 이메일, 메신저, 회의록, 견적서, 도면, 보고서, 의사결정, 문제 해결 과정과 시행착오가 매일 생성됩니다. 아직 정리되지 않은 자료도 있지만 조직의 실제 경험이 발생하는 최초의 지식입니다.
로컬에서 발생하는 지식
고객 요구사항, 현장사진, 수정 도면, 견적 검토 의견, 회의 결정사항, 공사 중 발생한 문제와 해결방법, 승인과 반려 이유
2단계. 서버 — 조직지식으로 가공·축적
로컬에서 생성된 업무지식을 서버로 모아 조직이 공동으로 활용할 수 있도록 저장하고 가공합니다. 중복을 정리하고, 업무와 연결하여 분류하고, 출처·버전·관계를 표시하며, 검증된 지식과 미검증 자료를 구분합니다.
서버는 자료를 쌓는 창고가 아니라, 현장의 경험을 조직의 지식으로 전환하는 곳입니다.
3단계. 로컬 — 지식의 활용과 재생산
사람과 AI는 서버에 축적된 기존 지식을 다시 업무 현장으로 가져와 현재의 고객·상황·문제에 적용합니다. 기존 지식은 새로운 데이터와 경험을 만나 수정·보완되거나 새로운 업무지식으로 재생산되고, 다시 서버로 이동하여 조직 전체의 지식이 됩니다.
단계
핵심 활동
주요 결과
로컬 생성
업무 수행 중 데이터·판단·경험 발생
원본자료와 현장지식
서버 가공·축적
수집·분류·연결·검증·버전관리
사람과 AI가 활용할 조직지식
로컬 활용·재생산
기존 지식과 현재 상황을 결합해 업무 수행
새 결과물·판단·교훈과 개선된 지식
환류
새 지식을 다시 서버에 반영
확대되고 최신화된 조직지식
세 번째 원칙 지식은 현장에서 사용될 때 가치가 생기고, 사용 결과가 다시 축적될 때 성장합니다. 지식관리는 한 번 끝나는 저장 절차가 아니라 계속 반복되는 순환시스템입니다.
강의 점검 질문
우리 조직의 업무지식은 어느 로컬에서 매일 생성되는가?
서버에 모인 자료는 조직지식으로 가공되고 있는가?
기존 지식을 활용한 결과가 다시 서버로 돌아오는가?
SECTION 04
지식 순환구조에서 AI의 역할
AI는 지식관리 시스템 밖에서 필요할 때만 사용하는 도구가 아니라, 지식의 생성·가공·활용·환류 전 과정에 역할로 참여합니다.
1. 로컬에서 지식 생성을 지원한다
회의·상담·업무 내용을 기록하고 요약
문서와 대화에서 핵심정보·결정사항·후속업무 추출
관련 고객·프로젝트·업무단계와 연결
누락되기 쉬운 경험과 암묵지의 기록을 지원
2. 서버에서 지식을 가공하고 조직화한다
중복·유사 자료와 관련 지식 탐지
업무·고객·프로젝트별 분류와 연결
기존 지식과 새로운 자료의 충돌·변경사항 탐지
사람과 다른 AI가 검색·활용할 수 있는 형태로 구조화
검토·승인이 필요한 지식을 책임자에게 인계
3. 로컬에서 기존 지식의 활용과 재생산을 지원한다
현재 업무에 필요한 기준·사례·원문 검색
관련 근거와 출처를 제시하고 현재 상황과 비교
문서·제안서·보고서·업무 결과물의 초안 생성
기존 지식과 새로운 데이터를 융합
업무 결과에서 새로운 지식과 개선사항을 추출해 서버로 환류
4. AI가 높이는 지식관리 성과
성과
AI가 기여하는 방식
속도
수집·요약·분류·검색·연결을 신속하게 수행
정확성
원문·버전·관련 기준을 대조하고 누락과 충돌을 탐지
재사용성
개인의 자료를 다른 구성원과 AI가 활용할 수 있게 구조화
재생산성
기존 지식과 새로운 업무경험을 결합하여 새로운 결과물을 생성
지속성
담당자가 바뀌어도 조직의 판단근거와 업무경험을 유지
확장성
하나의 지식을 여러 업무·부서·에이전트가 반복 활용
AI가 지식의 진위를 최종 확정하는 것은 아닙니다. AI는 수집·정리·연결·탐지·제안을 수행하고, 사람은 정확성·예외·중요 변경을 확인하고 승인합니다.
네 번째 원칙 AI는 지식검색 도구가 아니라 지식의 생성부터 가공·활용·재생산까지 참여하여 조직지식의 속도·정확성·재사용성과 재생산성을 높이는 역할입니다.
SECTION 05
모든 규칙을 사람에게 심지 않고 시스템에 심는다
AX 지식관리의 운영철학은 사람의 기억과 성실성에 의존하던 규칙을 시스템이 실행할 수 있는 구조로 전환하는 것입니다.
1. 사람에게 심어진 규칙은 왜 무너지는가?
사람의 교체담당자가 퇴사하거나 이동하면 그 사람이 기억하던 규칙도 함께 사라짐
망각과 착각알고 있던 규칙을 빠뜨리거나 다르게 기억함
절차 생략바쁨·귀찮음·게으름으로 정해진 절차를 건너뜀
전달 오류구두교육과 인수인계 과정에서 누락·왜곡·자의적 해석 발생
새로운 직원이 들어올 때마다 같은 규칙을 다시 교육해야 하고, 담당자가 바뀌면 업무의 품질과 방식도 달라집니다. 조직의 규칙이 시스템에 남는 것이 아니라 사람과 함께 사라지는 구조입니다.
2. 지식의 흐름을 시스템 규칙으로 만든다
지식의 흐름
시스템에 심을 규칙
파일 생성
파일명·작성자·프로젝트·생성일·문서상태 기록
파일 이동
업무단계와 승인상태에 따라 정해진 위치로 이동
폴더 생성
고객·프로젝트·업무유형별 표준구조 적용
파일 수정
원본 보존, 새 버전 생성, 변경이력 기록
파일 삭제
권한·보존기간 확인 후 복구 가능한 상태로 이동
지식화
핵심 내용·출처·적용조건·관련 업무 연결
지식 활용
업무와 권한에 맞는 최신 승인 지식 제공
지식 갱신
새 결과와 기존 지식의 차이를 탐지하고 검토 요청
지식 폐기
대체 지식과 폐기 사유를 기록하고 일반 활용에서 제외
3. 규칙의 성격에 따라 구현방식을 구분한다
규칙의 성격
주요 구현영역
예시
결과가 확정적이어야 하는 규칙
업무규칙과 코딩 시스템
파일명·이동·권한·삭제·버전·승인상태
문서와 상황의 해석이 필요한 규칙
맞춤 AI의 지침과 조직지식
의미 파악·분류·관계 발견·충돌 탐지
조직의 책임과 권한이 필요한 규칙
사람의 관리·확인·판단·승인
새 규칙의 제정, 중요한 변경, 예외와 최종 승인
모든 것을 AI의 자율판단에 맡긴다는 뜻이 아닙니다. 사람이 규칙을 기억해 매번 수작업으로 실행하던 구조를, 규칙의 성격에 맞게 시스템과 AI에 내재화하고 사람이 관리·확인·승인하는 구조로 전환한다는 뜻입니다.
사람은 바뀌어도 시스템은 남아야 합니다. 담당자의 교체가 조직지식의 단절로 이어지지 않도록 업무규칙과 지식의 흐름을 시스템에 심습니다.
다섯 번째 원칙 규칙은 사람의 기억에 맡기지 않습니다. 확정적인 규칙은 시스템이 실행하고, 해석이 필요한 일은 조직지식을 가진 AI가 지원하며, 사람은 시스템을 관리하고 결과를 확인하고 중요한 예외와 변경을 승인합니다.
강의 점검 질문
담당자가 바뀌면 함께 사라지는 업무규칙은 무엇인가?
직원이 기억해서 수행하는 파일·폴더·버전관리 절차는 무엇인가?
확정적 규칙, AI의 해석, 사람의 승인으로 구분했는가?
SECTION 06
1단계 로컬 업무지식 체계화의 목적
로컬 1단계의 목적은 담당자 PC를 깔끔하게 정리하는 것이 아닙니다. 업무데이터가 생성된 순간부터 실행·검증·완료·보관·지식화까지 전사 공통의 흐름을 갖게 하는 것입니다.
1. 파일관리는 위치가 아니라 흐름을 관리하는 일이다
업무파일은 처음부터 완성된 지식으로 만들어지지 않습니다. 고객 요청이나 아이디어에서 시작해 자료가 모이고, 방향이 정해지고, 실행과 수정이 반복되며, 결과가 검증된 뒤에야 다시 활용할 수 있는 지식이 됩니다.
“어디에 저장할까?” → “어떤 업무에서 생겼고, 지금 어느 상태이며, 다음에는 어디로 가야 하는가?”
2. 하나의 프로젝트 안에서도 데이터는 다르게 태어난다
업무·역할
생성 데이터
형식
주요 시점
영업
고객문의·상담·요구사항
메신저·이메일·문서·음성
문의·상담
설계
도면·렌더링·마감계획
CAD·PDF·JPG·3D
제안·설계
견적
수량산출·단가·견적서
Excel·PDF
설계 중·계약 전
현장
사진·작업일지·변경기록
JPG·영상·문서·메신저
시공 중
재무
청구·입금·원가자료
Excel·회계 데이터
계약부터 준공 후
파일의 형식과 생성시점은 달라도 모두 같은 프로젝트의 업무지식입니다. 한 부서의 폴더만 정리해서는 프로젝트 전체의 맥락을 이어갈 수 없습니다.
업무지식의 기본 단위는 파일 한 개가 아니라 파일과 맥락이 함께 담긴 프로젝트입니다.
여섯 번째 원칙 로컬 1단계에서는 다양한 업무데이터가 만들어지고 바뀌고 완료되는 전체 흐름을 하나의 프로젝트 맥락 안에서 관리합니다.
SECTION 07
생애주기형 업무와 반복업무형 업무
모든 업무를 같은 폴더구조로 관리하지 않습니다. 시작과 완료가 있는 업무와 계속 반복되는 업무를 먼저 구분합니다.
구분
쉬운 설명
예시
관리방식
생애주기형
시작·진행·완료·보관의 흐름이 있는 업무
고객 프로젝트·제안서·행사·연구·교안 제작
Reference·Inbox·Action·Result·Share
반복업무형
같은 양식과 절차로 계속 되풀이하는 업무
업무일지·주간회의·월간보고·정기 콘텐츠
Routines 작업공간·Outputs 결과 누적
주차장
아직 어디에 둘지 판단하기 어려운 자료
정체가 불분명한 임시자료
임시보관 후 다시 분류
운영시스템
현재 PC에서 실제 작동 중인 시스템
자동화 스크립트·자체 도구
업무자료와 분리해 운영
연구 중인 시스템과 실제 가동 중인 시스템을 구분합니다. 개발·실험 중이면 생애주기형 연구업무이고, 실제 운영에 투입된 뒤에는 운영시스템입니다.
반복업무의 푸시 방식
Routines: 양식·현재 작업→정제·확정→Outputs: 날짜별 결과 누적
업무일지처럼 양식을 계속 쓰는 경우에는 푸시 후 양식만 남기고, 뉴스수집처럼 매번 새로 수집하는 경우에는 작업공간을 비울 수 있습니다. 이 규칙도 루틴별로 시스템에 정합니다.
일곱 번째 원칙 업무의 성격을 먼저 구분해야 AI가 적합한 폴더를 만들고 다음 이동과 보관방식을 판단할 수 있습니다.
SECTION 08
생애주기형 파일관리 5단계
생애주기형 업무는 참고자료·생성·실행·검증결과·공유보관의 상태를 구분해 관리합니다.
Reference+Inbox→Action→Result→Share
1. Reference — 참고자료
외부 공급자료·법령·기준·조사자료·과거 사례처럼 업무 전반에서 꺼내 쓰는 자료입니다. 시간순 파이프라인의 한 단계가 아니라 Inbox부터 Share까지 항상 곁에서 참고하는 자료창고입니다.
2. Inbox — 생성·접수·방향 설정
새 아이디어·고객 요청·초안 또는 계획변경으로 다시 검토해야 하는 업무가 들어옵니다. 새 업무와 재검토 업무를 따로 나누지 않고, 목적·책임자·범위와 다음 단계 조건을 정합니다.
3. Action — 실행·고도화·검증
방향이 정해진 업무를 실제로 작성·설계·분석·수정·시험합니다. 가장 많은 버전이 생기는 곳이므로 원본·작업본·승인본과 변경이력이 중요합니다. 아직 검증되지 않았으므로 조직의 공식지식처럼 사용하면 안 됩니다.
4. Result — 안정화된 검증결과
실행과 검토를 거쳐 반복 사용이 가능할 만큼 안정화된 결과입니다. 단순한 완료 폴더가 아니라 개인의 업무결과를 조직지식으로 승격할지 판단하는 관문입니다.
5. Share — 공유·장기보관
충분히 검증된 결과를 템플릿으로 추출해 공유하거나 장기보관 위치를 찾을 수 있도록 정리합니다. 작업 중 생긴 모든 파일을 복사해 두는 곳이 아닙니다.
이동
업무상태의 변화
Inbox → Action
목적·책임·수행 여부와 방향이 정해짐
Action → Result
실행과 검증을 마쳐 안정된 결과가 됨
Result → Share
반복 사용·공유·장기보관이 가능한 형태로 정제됨
Result → 서버
개인의 결과가 조직 공동지식의 후보로 승격됨
기존 단계 → Inbox
요구나 계획 변경으로 방향을 다시 정해야 함
폴더의 이동은 파일을 옮기는 행위가 아니라 업무상태가 달라졌다는 뜻입니다.
여덟 번째 원칙 단계의 이름보다 각 단계의 들어가는 조건과 나오는 조건을 전사 공통으로 정하는 것이 중요합니다.
SECTION 09
여러 부서와 파일을 하나의 프로젝트로 관리하기
공통 포맷은 모든 파일을 하나의 확장자로 바꾸는 것이 아닙니다. 원본형식은 유지하되 파일의 신분·상태·관계를 설명하는 공통언어를 만드는 것입니다.
1. 프로젝트 전체와 개별 자료의 상태는 다를 수 있다
프로젝트가 시공 중이어도 계약서는 완료, 변경도면은 작업 중, 현장사진은 계속 생성 중일 수 있습니다. 따라서 프로젝트 전체의 진행단계와 프로젝트 안의 개별 업무자료 생애주기를 구분합니다.
로컬의 README·커밋메시지·파일 메타데이터·지식 이관카드에서 프론트매터 초안을 자동으로 만들고, AI와 시스템이 필수항목·ID·상태·권한·원본연결을 검사합니다. 중요한 지식은 사람이 승인한 뒤 Wiki와 인덱스에 발행합니다.
항목 이름을 전사 공통으로 고정합니다. project·project_id·project-code처럼 같은 의미를 서로 다른 이름으로 쓰면 검색과 자동화가 무너집니다. 필수·선택항목, 날짜형식, 상태값, 중요도, 권한등급과 태그규칙을 정합니다.
열여덟 번째 원칙 프론트매터는 단순 태그가 아니라 지식의 신분·출처·상태·중요도·관계·권한·지식화 범위와 인덱싱 방법을 시스템에 전달하는 조직지식의 공통규격입니다.
SECTION 19
지식을 구조·관계·의미 단위로 연결
Markdown 파일이 많이 만들어졌다고 지식체계가 완성되는 것은 아닙니다. 문서가 조직의 어디에 속하고 무엇과 연결되며 어떤 의미를 갖는지 구조화해야 합니다.
연결방식
핵심질문
도구·기술 예시
구조
어느 회사·부서·프로젝트·업무단계에 속하는가?
폴더·프론트매터·일반 데이터베이스
관계
어떤 자료를 바탕으로 만들었고 무엇에 영향을 주는가?
Obsidian 링크·Graphify·GraphRAG 계열
의미
표현이 달라도 비슷한 문제와 사례는 무엇인가?
임베딩·Qdrant 등 벡터 검색
도구의 역할을 혼동하지 않는다
Obsidian은 사람이 읽는 Markdown Wiki와 링크, 그래프 기술은 사람·고객·프로젝트·사건·규칙의 관계, Qdrant는 의미가 비슷한 지식의 검색, 일반 DB는 사용자·권한·버전·상태, 원본 저장소는 증거파일 보존을 담당합니다.
고객 요구→설계도면→수량산출→견적→계약·시공
열아홉 번째 원칙 하나의 도구가 모든 지식관리를 해결하지 않습니다. 구조·관계·의미·확정정보·원본을 담당하는 기술을 구분해 연결합니다.
SECTION 20
지식을 꺼내 쓰기 위한 인덱스 방법론
저장은 지식을 넣는 기술이고, 인덱스는 필요한 지식을 다시 찾는 기술입니다. 하나의 검색방식만으로는 조직의 질문에 충분히 답하기 어렵습니다.
인덱스
잘 찾는 것
예시
메타데이터
정확한 조건
프로젝트·고객·날짜·작성자·상태·권한
키워드
실제 단어·번호
계약번호·자재명·도면번호·법령명
의미
표현은 달라도 뜻이 비슷한 지식
유리 파손·파티션 균열·강화유리 크랙
관계
연결된 자료와 영향
도면을 근거로 만든 견적·같은 자재를 쓴 현장
혼합
여러 조건을 함께 반영
의미+키워드+권한+최신성+승인상태
자료에 맞는 검색단위를 정한다
자료
검색단위 예시
계약서
조항·항목
회의록
안건·결정·할 일
견적서
공종·품목·금액항목
도면
도면번호·공간·레이어·주요 객체
현장사진
사진·위치·공정·문제
업무규칙
하나의 판단·승인·중단기준
커밋메시지
한 번의 변경·이유·영향
검색결과에는 내용만 보여주지 않고 원본·위치·프로젝트·책임자·승인상태·버전·적용조건·관련 커밋을 함께 제시합니다. 새 버전·폐기·삭제는 Markdown·메타데이터·벡터·그래프·AI 검색대상에 함께 반영되어야 합니다.
스무 번째 원칙 인덱스는 데이터베이스를 설치하는 일이 아니라 조직의 실제 질문에 맞춰 무엇을 어떤 단위와 조건으로 찾을지 설계하는 방법론입니다.
SECTION 21
기술을 실제 회사자료로 검증한 뒤 도입한다
MarkItDown·OCR·Obsidian·그래프 기술·Qdrant는 설치목록이 아니라 검증후보입니다. 실제 파일과 실제 질문으로 정확성·보안·운영성을 확인합니다.
1. 대표 표본을 준비한다
일반 PDF·스캔문서·복잡한 Excel·사진·도면·한글문서·회의록·README와 커밋이 연결된 프로젝트·최신본과 폐기본·보안등급이 다른 자료를 포함합니다.
2. 실제 질문으로 시험한다
이 도면을 근거로 작성된 견적은 무엇인가?
고객 요구사항이 변경된 이유는 무엇인가?
같은 하자가 발생한 다른 현장은 어디인가?
현재 사용해야 하는 승인본은 무엇인가?
이 업무규칙은 왜 만들어졌는가?
현재 사용자가 볼 권한이 있는가?
3. 판정기준
검증영역
확인할 내용
변환
글자·표·수치·단위·페이지·이미지를 정확히 추출하는가?
관계
실제로 관련된 자료를 연결하고 잘못 연결하지 않는가?
검색
필요한 지식이 검색결과 상위에 나오는가?
근거
원본·위치·버전·승인상태를 함께 제시하는가?
갱신
새 버전·폐기·삭제가 검색에 정확히 반영되는가?
보안
권한 없는 사람과 AI에게 내용이 노출되지 않는가?
운영
오류를 찾고 다시 처리하고 복구할 수 있는가?
비용·속도
자료량이 늘어나도 조직이 감당할 수 있는가?
변환 검증→연결 검증→검색 검증→전체 흐름→보안·복구
스물한 번째 원칙 앞 단계의 오류는 뒤 단계에서 더 커집니다. 잘못 변환된 문서를 좋은 검색엔진에 넣어도 정확한 지식은 나오지 않습니다.
SECTION 22
3단계 사용을 위한 서버 접근관문 구축
로그인·권한·MCP·검색·보안·접근기록은 3단계 로컬에서 만드는 것이 아니라 2단계 서버의 보안구획에 구축합니다.
로컬 사람·AI→로그인·신원확인→역할·업무범위 확인→MCP·검색관문→허용된 지식
1. 로그인과 권한을 구분한다
로그인은 누구인지 확인하는 과정이고, 권한은 어느 지식을 보고 검색·다운로드·수정·승인할 수 있는지 정하는 과정입니다. 부서·직책뿐 아니라 참여 프로젝트·보안등급·업무목적·접속장치·사람 또는 AI 여부를 함께 확인합니다.
2. 검색 전에 범위를 제한한다
전체 지식을 검색한 뒤 화면에서 숨기는 방식이 아니라, 사용자와 AI의 권한을 먼저 확인하고 허용된 범위 안에서만 키워드·벡터·그래프 검색과 LLM 추론을 수행합니다.
3. 일반 MCP와 관리자 MCP를 분리한다
구분
허용기능
접근자
일반 지식 MCP
승인된 지식검색·일부 읽기·출처확인·오류신고·갱신요청
승인된 직원과 업무 AI
관리자 MCP
반입·변환·인덱스·권한·백업·복구·폐기·시스템 관리
별도 승인된 시스템 관리자
관리자 MCP와 관리화면은 일반 사용자가 접근하지 못하는 관리망·승인장치·관리계정 등의 보안구획에 둡니다. 시스템 운영권한과 지식내용 승인권한도 필요에 따라 분리합니다.
4. 모든 접근과 변경을 기록한다
누가 어떤 역할과 AI로 어느 지식을 검색·열람·다운로드·수정·승인·폐기했는지, 어떤 접근이 왜 거부되었는지 기록합니다. 검색기록 자체의 접근권한과 보존기간도 정합니다.
프론트매터 권한만으로 끝나지 않습니다. 같은 권한규칙을 원본 저장소·Wiki·키워드·벡터·그래프·MCP·AI 답변과 외부전송에 모두 적용합니다.
스물두 번째 원칙 사람과 AI는 서버에 직접 들어가지 않습니다. 서버가 구축한 접근관문이 신원·역할·프로젝트·보안등급을 확인하고 허용된 지식만 제공합니다.
SECTION 23 · 실습과제
2단계 서버 실습: LLM Wiki와 안전한 지식접근 구조 구현하기
서로 다른 바이너리 업무파일을 AI가 읽고 찾을 수 있는 지식으로 바꾸어 작은 LLM Wiki를 만들고, 로그인·MCP 또는 이에 상응하는 기술로 사용자별 접근범위를 분리해 봅니다. 문서로만 설계하지 말고 핵심 흐름이 실제로 작동하는 시제품을 완성합니다.
실습자료 보안 실제 회사자료는 사용승인을 받은 경우에만 활용합니다. 그 외에는 개인정보·고객명·계약금액 등을 제거한 자료나 교육용 예제파일을 사용합니다.
실습 목표
목표
완성해야 할 결과
바이너리 업무파일 지식화
PDF·Word·Excel·이미지·스캔문서 등 서로 다른 형식의 원본을 Markdown 또는 검색 가능한 구조로 변환
LLM Wiki 구축
변환한 지식에 공통 프론트매터와 관계를 부여하고, 사람이 읽고 AI가 검색할 수 있는 Wiki 구성
지식검색 구현
메타데이터·키워드·의미·관계 중 한 가지 이상을 사용해 필요한 지식을 찾고 출처를 함께 제시
접근권한 분리
로그인·MCP 또는 동등한 기술을 적용해 일반 사용자·제한 사용자·관리자의 접근범위와 기능을 구분
과제 1. 바이너리 파일을 LLM Wiki 지식으로 바꾸기
업무주제 하나를 정합니다. 하나의 프로젝트나 반복업무를 선택합니다.
서로 다른 형식의 파일을 3개 이상 준비합니다. 예: 일반 PDF 또는 Word, 스캔 PDF 또는 이미지, Excel이나 다른 업무파일.
파일별 지식화 범위를 정합니다. 본문, 표와 수치, 이미지 내용, 생성일·작성자 같은 메타데이터, 프로젝트 맥락과 자료 간 관계 중 무엇을 지식으로 만들지 표시합니다.
원본은 그대로 보존하고 변환본을 만듭니다. MarkItDown·OCR 또는 동등한 기술을 사용하여 Markdown이나 검색 가능한 구조로 변환합니다. 변환하지 못한 내용과 오류도 기록합니다.
공통 프론트매터를 붙입니다. 프로젝트명·문서종류·작성자·생성일·보안등급·승인상태·원본경로·버전·관련 커밋·지식화 범위 등을 같은 규칙으로 작성합니다.
Wiki에 올리고 관계를 연결합니다. README와 커밋메시지를 활용하여 원인자료·결과자료·이전버전·관련 프로젝트를 연결합니다.
검색을 구현합니다. 메타데이터·키워드·벡터·그래프 중 하나 이상을 적용하고 실제 업무질문으로 결과와 출처를 확인합니다.
원본 보존→지식범위 결정→MD·구조 변환→프론트매터→Wiki·인덱스
과제 2. 지식을 안전하게 꺼내 쓰는 접근관문 만들기
다음 세 역할을 만들고 역할별로 보이는 지식과 사용할 수 있는 기능이 실제로 달라지도록 구현합니다.
역할
예시 접근범위
구현 확인
일반 사용자
전사에 승인·공개된 지식의 검색과 출처확인
관리기능과 제한자료에 접근할 수 없음
부서·프로젝트 사용자
공통지식+참여 중인 부서·프로젝트 지식
다른 부서·프로젝트 자료는 검색결과에도 나타나지 않음
시스템 관리자
반입·변환·인덱스·권한·오류·백업 관리
별도 관리영역에서만 관리기능 사용
구현방법은 자유롭게 선택합니다. 역할이 분리된 로그인, 일반 지식 MCP와 관리자 MCP의 분리, API 게이트웨이, 권한이 적용된 검색서비스 등 같은 목적을 달성하는 다른 기술도 사용할 수 있습니다. 단, 화면에서만 자료를 숨기지 말고 검색과 원본 접근 전에 권한을 확인해야 합니다.
반드시 시험할 다섯 가지
권한이 있는 사용자는 필요한 지식을 찾고 원본·버전·승인상태를 확인할 수 있는가?
권한이 없는 사용자는 제목·검색결과·AI 답변·원본파일에서 제한지식을 볼 수 없는가?
일반 사용자는 관리자 기능이나 관리자 MCP에 접근할 수 없는가?
지식이 갱신·폐기·삭제되면 Wiki와 검색결과에도 같은 상태가 반영되는가?
변환오류가 있는 자료는 정상지식처럼 공개되지 않고 검토대상으로 분리되는가?
제출물
제출물
포함할 내용
전체 흐름도
원본 반입 → 변환 → 프론트매터 → Wiki·인덱스 → 권한확인 → 검색·활용 흐름
변환 결과
3개 이상 원본의 지식화 범위표, 변환된 MD 또는 구조화 파일, 변환오류 점검결과
LLM Wiki 시제품
공통 프론트매터, 자료 간 링크, 검색화면 또는 실행방법
검색 시연
실제 업무질문 5개, 검색·AI 답변, 원본 출처와 결과평가
권한표와 접근 시연
역할별 허용·거부 기능, 로그인·MCP 또는 대체기술의 실행화면과 접근기록
기술선정 기록
선택한 도구, 선택이유, 확인된 한계, 다음 개선사항
수준별 구현범위
구분
구현범위
기본
3개 파일 변환, 공통 프론트매터, 작은 Wiki, 한 가지 검색, 3개 역할의 간단한 로그인 또는 권한 시제품
표준
변환 자동화, 프론트매터 검사, 두 가지 이상 혼합검색, 3개 역할의 실제 접근차단과 기록
심화
일반·관리자 MCP 분리, 사용자·프로젝트별 범위제어, 자동 재인덱싱, 갱신·삭제·복구와 보안시험
도구 예시
MarkItDown·OCR·Obsidian·Qdrant·GraphRAG는 선택 가능한 예시입니다. 같은 기능을 수행하는 다른 도구를 사용해도 됩니다. 중요한 것은 도구의 이름이 아니라 원본 추적, 변환 정확성, 공통 메타데이터, 검색 가능성, 권한 분리가 실제로 작동하는지입니다.
과제의 핵심 질문 우리 조직의 서로 다른 업무파일을 어떻게 믿을 수 있는 지식으로 바꾸고, 사람과 AI가 각자 허용된 범위 안에서만 안전하게 꺼내 쓰게 할 것인가?
SECTION 24 · 3단계 로컬
서버지식을 로컬 업무에서 활용·융합·재생산
3단계 로컬은 서버를 관리하는 단계가 아닙니다. 서버가 제공한 로그인·검색·MCP 접근수단을 사용하여 허용된 조직지식을 현재 업무에 적용하는 단계입니다.
기능
2단계 서버
3단계 로컬
로그인·권한
시스템 구축·운영·갱신
로그인하고 부여받은 범위에서 사용
MCP
보안구획에 구축·관리
승인된 MCP에 사람과 업무 AI가 연결
검색
인덱스·권한필터·출처 제공
질문하고 결과를 현재 업무에 적용
조직지식
원본·Wiki·관계·벡터 보호
허용된 내용·근거·원본만 열람
재생산
피드백과 이관후보 접수
기존지식과 새 상황을 결합해 결과 생성
활용의 전체 흐름
로그인·MCP 연결→질문·업무맥락→허용 지식·출처→로컬 적용·판단→새 결과 생성
현장업무 재활용 사례
서버의 과거 하자사례 + 현재 현장사진 + 현재 도면·자재정보 → AI와 현장담당자의 비교·판단 → 하자예방 조치 → 새로운 처리결과와 교훈 → 로컬 생애주기 관리 → 검증 후 다시 서버로 이관
서버는 답변과 함께 원본 출처·프로젝트·버전·승인상태·적용조건·관련 지식을 제공합니다. 충돌하거나 승인되지 않은 지식은 하나의 답으로 합치지 않고 사람의 확인이 필요하다고 알려야 합니다.
1단계 로컬 생성·검증 → 2단계 서버 지식화·접근관문 → 3단계 로컬 활용·재생산 → 다시 1단계
3단계 핵심 원칙 접근시스템은 서버에서 구축하고 로컬은 이를 사용합니다. 사람과 AI는 승인된 조직지식을 현재 업무와 결합해 새로운 업무성과를 만들고, 그 결과를 다시 로컬 생애주기와 서버 이관으로 환류합니다.
SECTION 25 · 3단계 운영
LLM 합성지식을 검증하여 조직의 정본으로 승격한다
3단계 로컬은 서버지식을 현재 업무에 적용하고 새로운 결과를 만드는 단계입니다. 그러나 LLM이 여러 자료와 현재 상황을 결합해 만든 합성지식은 유용한 초안일 뿐, 아직 조직이 승인한 정본은 아닙니다.
서버 정본 → 검색 → 현재 상황과 결합 → LLM 합성지식 → 업무 적용 → 결과 검증 → 승인 정본 → 서버 환류
검증된 지식이 다시 서버로 들어가면 다음 업무는 이전보다 더 많은 경험과 근거에서 출발합니다. 이 순환이 반복되면서 조직지식은 단순히 쌓이는 것이 아니라 사용성과 검증결과가 더해져 복리처럼 성장합니다.
합성지식은 정본이 아닙니다. LLM은 서로 다른 프로젝트의 조건을 잘못 결합하거나 오래된 자료와 최신 자료를 섞고, 원본에 없는 내용을 추론할 수 있습니다. 출처가 맞더라도 현재 업무의 적용조건과 다를 수 있습니다.
합성지식의 상태를 구분한다
상태
의미
사용범위
서버 정본
조직이 검토·승인한 공식지식
허용된 업무에서 공식 사용
합성 초안
LLM이 기존 지식과 현재 상황을 결합한 결과
참고·검토용
업무 적용본
담당자가 실제 업무에 적용한 내용
해당 프로젝트 내부 사용
검증본
원본과 적용결과를 확인한 지식
정본 승격 승인 요청
승인 정본
권한자가 공식지식으로 승인한 결과
서버에 등록하여 재사용
보류·폐기
오류·중복·조건 불충분이 확인된 결과
검색·재사용 제한
합성지식에는 사용한 원본과 출처, 원본 버전과 승인상태, 생성일과 생성 AI, 적용대상과 조건, 담당자, 실제 적용결과, 검토·승인·폐기 상태를 함께 기록합니다.
정본 승격규칙을 세 영역에 심는다
영역
담당할 규칙
자동화·코딩 시스템
출처·버전 표시, 필수정보 검사, 권한 확인, 중복·충돌 탐지, 미승인 지식 분리, 검토기한 알림, 승인 후 Wiki·인덱스 갱신, 전체 이력 기록
업무규칙
어떤 합성지식을 바로 참고할 수 있는지, 언제 원본대조와 복수검토가 필요한지, 실제 적용을 몇 회 확인할지, 누가 승인할지 정의
결재라인·사람
현재 상황의 적합성 판단, 수치·조건·예외 검토, 재사용 가치 판단, 고위험 지식의 최종 승인과 책임
위험수준에 따라 승인강도를 다르게 한다
위험
업무 예시
승격방식
낮음
일반 안내문·내부 아이디어·표현 개선
담당자 확인
보통
견적 참고자료·업무절차·고객 대응사례
담당자+책임자 검토
높음
계약조건·비용결정·품질판정
부서책임자 또는 의사결정자 승인
매우 높음
법률·안전·인사·대외 공표
전문가 검토+공식 결재
합성 초안→원본 대조→업무 적용→결과 검증→정본 승인·환류
스물다섯 번째 원칙 지식은 검색했다고 완성되지 않습니다. LLM의 합성지식은 출처·적용결과·위험수준에 따른 검토와 승인을 거쳐야 조직의 정본이 됩니다.
SECTION 26 · 3단계 기술 팁
로컬과 원격에서 안전하게 서버지식에 접근한다
사무실 PC뿐 아니라 현장 노트북·재택 PC·승인된 모바일과 업무 AI도 지식을 활용할 수 있어야 합니다. 원격접근의 목표는 서버를 인터넷에 공개하는 것이 아니라 승인된 사람과 기기만 허용된 지식에 도달하게 하는 것입니다.
원격접근에서 구분할 네 가지
구분
확인할 질문
사용자 신원
접속하려는 사람은 누구인가?
접속기기
회사가 승인한 PC·노트북·모바일인가?
지식범위
어느 부서·프로젝트·보안등급까지 볼 수 있는가?
사용기능
검색·열람·다운로드·수정·승인·관리 중 무엇을 할 수 있는가?
네트워크 진입권한과 지식 사용권한은 다릅니다. Tailscale·VPN은 서버가 있는 네트워크에 들어오는 권한을 통제하고, Wiki 로그인·MCP 권한은 그 안에서 어떤 지식과 기능을 사용할지 결정합니다. 두 층을 모두 적용합니다.
일반 사용자는 Wiki와 일반 MCP만, 관리자는 별도 SSH·관리자 MCP만 사용하게 합니다.
퇴사·직무변경·기기분실 시 사용자와 기기권한을 즉시 회수합니다.
MagicDNS를 사용하면 Tailscale 장치를 숫자 IP 대신 장치이름으로 접근할 수 있습니다. Tailscale SSH는 일반 지식검색이 아니라 승인된 관리자의 서버관리 통로로 제한합니다. 내부 지식서비스는 tailnet 내부용 Serve를 검토할 수 있지만, 인터넷에 공개하는 Funnel은 특별한 이유가 없다면 사용하지 않습니다.
일반 직원은 NAS의 Wiki HTTPS만, 시스템 관리자는 HTTPS와 SSH만 사용합니다. 별도 허용이 없는 복합기와 다른 서버는 접근할 수 없습니다. 실제 정책은 저장 전에 정책검사와 테스트 기능으로 검증합니다.
5. 원격기기에서 접속한다
Windows·macOS·모바일은 승인된 서브넷 경로를 사용할 수 있으며, Linux 클라이언트는 다음 설정이 필요할 수 있습니다.
sudo tailscale set --accept-routes
먼저 https://10.77.20.20으로 시험하고, 실제 운영에서는 내부 DNS와 Split DNS를 구성해 https://knowledge.company.internal과 같은 이름을 사용합니다. 서브넷 뒤의 NAS는 Tailscale 장비가 아니므로 MagicDNS 이름이 자동 생성된다고 가정하지 않습니다.
필수 연결시험
외부 인터넷에서 승인된 노트북으로 Wiki에 접속되는가?
일반 직원이 복합기·SSH·NAS 관리자화면에 접근하지 못하는가?
미승인 기기와 퇴사자 계정이 차단되는가?
서브넷 라우터가 꺼졌을 때 안전하게 연결이 중단되는가?
IP는 접속되지만 이름이 안 될 경우 내부 DNS를 점검했는가?
사무실과 재택 네트워크의 IP 대역이 겹치지 않는가?
서브넷 전체를 모든 사람에게 허용하지 않습니다. 경로는 네트워크 단위로 광고하더라도 권한은 “필요한 사용자 → 필요한 장비 → 필요한 포트”로 좁게 설정합니다. Tailscale을 통과한 뒤에도 Wiki·NAS 로그인과 지식별 권한을 유지합니다.