AI 프로젝트가 아무도 쓰지 않는 시스템이 되는 이유 | Snowflake 황주연

URL: https://www.youtube.com/watch?v=4e5AUn3OUm4 날짜: 2026-08-13 채널: AI Community Bloom 블룸 영상 길이: 11분 00초 발표자: 황주연(Snowflake, Solution Engineer) 콘텐츠 유형: AI·엔터프라이즈 데이터·AX 인터뷰 Q&A 자막: 한국어 자동 생성 자막 기반. ASR 오탈자는 문맥에 따라 보정했다.

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==왜 많은 기업의 AI 프로젝트가 기술적으로는 성공해도 현업에서 아무도 쓰지 않는 시스템으로 남는가?==

• 문제의 핵심은 데이터의 양보다 데이터가 만들어진 맥락(Context)과 그 맥락을 설명할 사람의 부재다.
• "AI로 매출을 올리고 싶다"처럼 목표가 추상적이면 필요한 데이터와 성공 기준을 정할 수 없다.
• 현업의 문제 정의와 인프라·개발 조직의 구현 역량을 연결하는 협업 문화가 필요하다.
• 범용 만능 에이전트를 기다리기보다 PO 검증, 법률 검토, 팀 단위 매출 분석처럼 역할과 목표가 분명한 에이전트부터 만들어야 한다.

이 인터뷰의 결론은 간단하다. AI 프로젝트는 데이터부터 모으는 작업이 아니라, 개인·팀·회사가 무엇을 달성하려는지 먼저 정하고 그 목표를 거꾸로 따라가며 데이터·도구·에이전트를 설계하는 작업이다. 목표 없이 만든 도구는 프로젝트가 완료되어도 사용자의 일과 연결되지 않아 폐기된다.

1. 솔루션 엔지니어의 역할: 제품 설명이 아니라 고객의 운전까지 함께하는 일

1.1. 일반적인 세일즈와 Solution Engineer의 차이(00:00~01:27)

1. 인터뷰의 시작과 하루 일과 질문

   1. 진행자는 본격적인 질문에 앞서 황주연에게 개발팀과 어떻게 협력하는지, 영업을 하는지, 고객과 어떤 방식으로 일하는지 하루 일과를 물었다.
   2. 황주연은 먼저 자신이 맡은 Solution Engineer 역할을 설명해야 하루 일과를 이해할 수 있다고 답했다.

2. 자동차를 함께 타는 세일즈 비유

   1. 일반적인 세일즈가 자동차의 스펙과 성능을 설명하는 일이라면, 솔루션 엔지니어는 고객과 차에 실제로 함께 타는 역할이다.
   2. 고객이 운전하면서 "깜빡이는 어떻게 켭니까?", "주차는 어떻게 합니까?"처럼 실제 운영에서 부딪히는 질문을 할 때, 기능 설명을 넘어 사용 방법과 맥락을 이해하도록 돕는다.
   3. 고객이 더 많은 도움을 원하면 단순한 설명에 그치지 않고 드래프트(초안)나 추가 작업도 함께 수행한다.

3. 고객 상황에 맞춘 조정 작업

   1. 차가 한쪽, 예를 들어 오른쪽으로 계속 쏠리는 상황을 비유로 들었다.
   2. 이 경우 오른쪽 바퀴의 바람을 일부러 빼서 쏠림을 줄이는 식으로, 고객 환경에서 실제로 작동하도록 세부 조건을 조정한다.
   3. 즉 Solution Engineer는 엔지니어링 지식과 고객 대면 능력을 결합해 제품을 고객의 업무 흐름에 맞추는 직무다.

1.2. 고객의 가장 큰 문제는 기술이 아니라 맥락이다(01:27~02:18)

1. 문제의 소재: 사람과 조직까지 포함한 데이터 문제

   1. 진행자는 수많은 고객사를 만난 뒤 가장 문제가 되는 지점이 기술인지, 기업의 사람인지, 조직·문화인지 물었다.
   2. 황주연은 사람의 문제라고 볼 수도 있지만, 가장 찾기 어려운 것은 데이터 자체가 아니라 데이터의 Context라고 설명했다.

2. 데이터의 의미를 아는 사람이 사라진다

   1. 데이터가 존재해도 그 데이터가 어떤 의미를 갖는지, 왜 그런 형태로 저장됐는지, 누가 가장 잘 아는지를 찾기 어렵다.
   2. 회사가 시스템을 만들고 4~5년 동안 운영하는 사이 시스템은 Legacy System이 된다.
   3. 시간이 지나면 초기 설계자와 업무 담당자가 이동하거나 퇴사하고, 시스템과 데이터의 생성 배경을 설명할 사람이 없어지는 것이 핵심 난관이다.
   4. 따라서 엔터프라이즈 AI에서 어려운 일은 테이블을 찾는 것만이 아니라 그 테이블을 해석할 수 있는 사람과 맥락을 복원하는 일이다.

2. 파편화된 데이터 이해와 Reverse Engineering

2.1. "작년 대비 매출이 얼마나 늘었나요?"도 단순하지 않다(02:19~03:10)

1. 한 문장에 여러 정의가 들어간다

   1. 진행자는 앞에서 말한 매출 관련 사례를 꺼내 "작년 대비 매출이 얼마나 늘었나요?"라는 질문을 던졌다.
   2. 황주연은 이처럼 간단해 보이는 질문도 매출의 범위, 기준 기간, 집계 방식 등 여러 정의를 갖는다고 말했다.
   3. 질문을 처음 들은 고객은 "그게 그렇게 중요한가?" 또는 "나도 아는 내용이다"라고 반응할 수 있지만, 실제로는 추가 질문에 막힌다.

2. 엑셀에서는 답하지만 데이터 흐름을 설명하지 못한다

   1. 고객사에 "매출을 잘 뽑고 계십니까?"라고 물으면 대부분 그렇다고 생각한다.
   2. 매출을 데이터베이스(DB)에서 일관되게 산출하는 것이 아니라, 이미 만들어 둔 Excel 파일에서 뽑아 보고하기 때문이다.
   3. 그러나 "그 매출이 어느 시스템에서 왔고, 어떤 변환을 거쳤으며, 어떤 기준으로 계산됐습니까?"처럼 한 단계 더 들어가면 답하지 못한다.
   4. 문제는 숫자가 없다는 것이 아니라 숫자가 만들어진 데이터 흐름(Data Lineage)을 모른다는 데 있다.

3. 조직 내부 데이터 이해의 파편화

   1. 진행자는 질문에 답하는 것조차 어려울 정도로 내부 데이터 이해가 파편화돼 있다는 뜻인지 되물었다.
   2. 이 사례는 대시보드나 생성형 AI를 추가하는 것만으로 해결되지 않는다. 먼저 숫자의 정의·출처·변환 규칙을 복원해야 한다.

2.2. 고객 데이터셋을 받아 맥락을 복원하는 방법(03:10~04:36)

1. 첫 고객 미팅에서 파고드는 범위

   1. 매출과 같은 구체적인 질문으로 작업을 시작하면 고객사로부터 데이터셋을 받아 실제 구조와 흐름을 확인한다.
   2. 회사에 15년 정도 근무한 베테랑 담당자가 남아 있으면 과거 시스템과 업무 규칙을 설명할 수 있어 작업 속도가 크게 빨라진다.
   3. 반대로 오래 근무한 담당자나 핵심 관계자가 모두 나간 경우에는 기억에 의존할 수 없으므로 Reverse Engineering으로 시스템과 데이터의 의미를 다시 추적한다.

2. Reverse Engineering이 고객에게 줄 수 있는 불편함

   1. 진행자는 "내가 이 시스템을 오래 사용했는데 정말 잘 알고 있다"고 생각하는 고객 앞에서 외부 엔지니어가 시스템을 다시 분석한다고 하면 방어적 반응이 나올 수 있다고 지적했다.
   2. "제가 한 번 리버스 엔지니어링해 보고 구조를 찾아드리겠습니다"라는 제안은 신뢰를 만들 수도 있지만, 고객의 전문성을 부정하는 말처럼 들릴 위험도 있다.

3. 불편함을 줄이는 공유 순서

   1. 황주연은 Reverse Engineering 과정에서 고객이 불편할 수 있으므로 중간중간 결과를 계속 공유한다고 답했다.
   2. 최근에는 AI를 활용해 분석과 프로토타입 제작을 빠르게 할 수 있지만, 빠르다는 이유로 결과물을 고객에게 갑자기 들이밀지는 않는다.
   3. 먼저 프로토타입을 만들고 현업 담당자에게 공유한다.
   4. 현업 담당자의 피드백과 확인을 받은 뒤 관련 구성원에게 확장하고, 최종적으로 "OK"를 받은 형태로 만든다.
   5. 이 순서는 기술 검증뿐 아니라 세일즈·변화관리(Change Management)의 기술이기도 하다.

3. AI 프로젝트가 실패하는 출발점: 목표 없는 도입

3.1. End-to-End 지원의 첫 단계는 데이터가 아니다(04:36~05:56)

1. 전사 AX 기업과 AX를 시작하려는 기업

   1. 진행자는 Amore 같은 기업처럼 AI를 도입해 전사 AX(AI Transformation)를 진행하는 경우와 이제 시작하려는 기업을 예로 들며, 어디서부터 어디까지 지원하는지 물었다.
   2. 기업은 흔히 "데이터를 먼저 준비해야 한다"고 생각하지만, 황주연은 순서를 뒤집어 "AI로 무엇을 하고 싶은가"부터 물어야 한다고 답했다.

2. 추상적인 목표는 사실상 복권을 찍어 달라는 요청이다

   1. 고객이 "AI로 뭔가 잘되는 것을 보고 싶다" 또는 "AI로 매출을 올리고 싶다"고 말하는 경우가 있다.
   2. 황주연은 이런 말을 들으면 속으로 "로또 번호를 찍어 달라는 것 같다"고 생각한다고 농담 섞어 말했다.
   3. 목표가 없으면 AI 활용법의 성공 여부를 판단할 기준도, 무엇을 구현해야 하는지도 정하기 어렵다.

3. 좋은 AI 과제의 형태

   1. 이미 발주서(Purchase Order, PO)가 있고, 그 발주가 회사의 규정이나 조건에 적합한지 판단해 달라는 과제는 목적이 명확하다.
   2. 새로운 제품의 성분표가 있을 때, 그 성분표가 각 국가의 규정에 적합한지 판단해 달라는 과제도 구체적이다.
   3. 이런 경우에는 먼저 목적이 확정되고, 그 목적을 달성하는 데 필요한 데이터가 무엇인지 역으로 결정된다.
   4. 목표를 먼저 정하고 필요한 데이터·모델·워크플로를 설계해야 AI 프로젝트를 빠르게 진행할 수 있다.

3.2. "우리도 AI를 해야 한다"가 사용되지 않는 시스템을 만든다(05:56~07:20)

1. 아이디어가 목표처럼 보이는 착시

   1. 진행자는 AI로 뭘 하고 싶다는 마음 자체가 목표가 되기 어려운 이유와, 기업의 AX 준비 수준을 물었다.
   2. 황주연은 안타깝지만 많은 경우 AI를 추진하는 쪽에서 먼저 "우리도 AI를 해야 한다"고 결정하고, 현업 쪽에 아이디어를 내라고 요청한다고 설명했다.
   3. 현업은 "아이디어는 있긴 한데 매출을 올리고 싶다"처럼 추상적인 요구를 내놓게 된다.

2. 시간은 쓰지만 효율적 결과가 나오지 않는 구조

   1. 이런 상태에서는 컨설팅과 개발에 많은 시간이 들어가도 효율적인 결과를 만들기 어렵다.
   2. 설령 프로젝트가 기술적으로 성공하고 도구가 완성되더라도, 실제 사용자의 목표·업무·성과지표와 연결되지 않으므로 결국 아무도 쓰지 않는 시스템이 된다.
   3. 여러 차례 컨설팅을 거쳐 도구를 만들어 주었는데도 현업에서 사용되지 않는 사례가 가장 안타까운 이유가 여기에 있다.
   4. 프로젝트를 시작하기 전에 무엇을 해결하려는지, 누가 언제 어떤 판단에 사용할지를 알고 있어야 한다.

3. 실행 전 확인할 질문

   1. 회사·팀·개인이 해결하려는 구체적인 업무 문제는 무엇인가?
   2. 결과를 누가 사용하며, 현재의 업무 흐름에서 어느 단계에 연결되는가?
   3. "AI를 썼다"가 아니라 어떤 판단 시간 단축, 오류 감소, 규정 준수, 매출·비용 개선을 성공으로 볼 것인가?

4. 현업과 인프라 조직의 협업 문화

4.1. 아이디어는 현업에서, 구현은 인프라·개발에서(07:20~08:02)

1. 두 조직의 도움이 모두 필요하다

   1. 황주연은 AI를 추진하려면 현업 조직과 인프라 조직, 두 종류의 조직이 모두 필요하다고 말했다.
   2. 업무 아이디어와 실제 고충은 현업에서 나오지만, 이를 구체적인 시스템과 Enterprise AI로 구현하는 방법은 별도의 기술 역량을 요구한다.

2. 현업이 막히는 지점

   1. 현업 담당자는 자신의 아이디어를 갖고 있어도 데이터를 이용한 엔터프라이즈 AI를 어디서부터 구현해야 하는지 몰라 시작 단계에서 막힌다.
   2. 아이디어를 업무 요구사항, 데이터 흐름, 평가 기준, 운영 절차로 구체화하는 지원이 필요하다.

3. 인프라팀이 아이디어를 말하지 않는 지점

   1. 인프라팀에도 개선 아이디어가 있지만, "이건 다 내 일"이 될까 봐 적극적으로 꺼내지 않는 경우가 있다.
   2. 현업은 문제를 알고 인프라팀은 구현 가능성을 알지만 서로의 정보를 공유하지 않으면 어느 쪽도 완성된 해법을 만들 수 없다.
   3. 따라서 부서 간 협업을 개인의 선의에 맡기지 않고, 아이디어를 공유하고 실험하며 성과를 함께 인정하는 조직 문화로 만들어야 한다.

5. 에이전트에 대한 오해와 현실적인 적용 범위

5.1. 가까운 시기에 만능 에이전트는 없다(08:02~08:43)

1. 범용 지능에 대한 과도한 기대

   1. 진행자는 기업이 AI를 도입하면 무엇이든 잘할 수 있을 것이라는 기대와 흔한 오해를 물었다.
   2. 황주연은 당장 2~3년 안에 모든 일을 처리하는 만능 에이전트는 나오지 않는다고 단언했다.

2. 목표가 분명한 에이전트

   1. 에이전트는 PO를 검증하거나 법률 문서를 체크하는 것처럼 목표와 책임 범위가 분명해야 한다.
   2. 역할이 다른 에이전트를 여러 개 연결하는 Multi-Agent 구조로 기능을 강화할 수는 있다.
   3. 그러나 어떤 질문이든 이해하고 답하는 만능 에이전트는 현재 없으며, 황주연은 그런 수준은 자신의 예상으로도 10년 안에는 어려울 것이라고 말했다.

5.2. 1~2년 안에 가능한 팀 단위 에이전트(08:43~09:08)

1. 역할과 프로세스가 정해진 팀

   1. 진행자는 향후 1~2년에 실현 가능성이 높은 에이전트 영역과 여기에 투자해야 할지 물었다.
   2. 황주연은 팀 단위 에이전트는 충분히 가능하다고 보았다.

2. 매출 분석 사례

   1. 팀 단위의 매출 분석처럼 어느 정도 역할(Role)이 정해져 있는 업무는 에이전트가 활용될 수 있다.
   2. 질문·데이터·검토자·승인자 같은 역할이 정의되어 있으면, 에이전트가 팀의 반복 분석과 보고 과정을 지원할 수 있다.
   3. 핵심은 에이전트가 모든 일을 하는 것이 아니라, 이미 정리된 팀 업무의 특정 단계를 맡기는 것이다.

6. 데이터가 어디 있는지 몰라도 목표부터 정하라

6.1. MCP와 Google Workspace 연결이 바꾼 데이터 접근(09:08~10:03)

1. 청중의 범위

   1. 이날 행사에는 엔터프라이즈 종사자뿐 아니라 스타트업과 중견기업에서 AX를 담당하는 사람도 많이 참석했다.
   2. 진행자는 이들이 AI를 시작하기 전에 데이터와 관련해 어떤 순서를 밟아야 하는지 조언을 요청했다.

2. 데이터 위치를 몰라도 시작할 수 있는 환경

   1. 황주연은 앞서 말한 것처럼 데이터가 어디 있는지 정확히 몰라도 최근에는 MCP(Model Context Protocol)나 Google Workspace 같은 연결 수단을 활용해 여러 업무 데이터에 접근하고 연결할 수 있다고 설명했다.
   2. 연결 기술의 발전으로 데이터 접근 자체는 예전보다 쉬워졌지만, 그것이 목표 없는 프로젝트를 정당화하지는 않는다.

3. 목표에서 데이터로 역산하는 순서

   1. 먼저 "내가 무엇을 하고 싶은가", "우리 회사가 무엇을 하고 싶은가", "우리 팀이 무엇을 하고 싶은가"를 정한다.
   2. 그 목표에 필요한 데이터가 무엇인지 역으로 찾는다.
   3. 필요하면 데이터셋을 새로 만들거나 권한을 받아 연결할 수 있지만, 목표 없이 데이터를 먼저 모으면 비용과 시간이 크게 늘어난다.
   4. 따라서 첫 단계는 목표와 AI를 어느 정도까지 사용할지 정하는 일이다.

6.2. 수첩 속 개인 지식이 에이전트가 된 사례(10:03~10:44)

1. 식품업체의 나이 많은 담당자

   1. 황주연은 식품업체에서 만난 나이가 있는 담당자 C님의 사례를 소개했다.
   2. C님은 자신의 아이디어와 업무 노하우를 컴퓨터보다 수첩에 손으로 적고, 수첩을 보며 내용을 정리하는 방식으로 일하고 있었다.

2. 암묵지를 가이드로 바꾸기

   1. 황주연은 그 수첩의 내용을 관찰하고 정리해 가이드로 구성했다.
   2. 그러자 C님이 오랫동안 쌓아 온 지식(Knowledge)이 바로 에이전트의 구성 요소로 바뀌었다.
   3. 이 사례는 데이터베이스에 이미 정제된 데이터가 있어야만 AI를 만들 수 있다는 생각이 틀렸음을 보여준다.

3. 사람의 아이디어를 AI로 확장하기

   1. 조직 구성원이 가진 아이디어와 암묵지를 먼저 잘 정리하면, AI를 통해 구현 가능한 업무 지식으로 바꿀 수 있다.
   2. 그 결과 개인의 업무 역량이 커지고, 회사에 기여하는 방식도 확장된다.
   3. AI 시대의 재미있는 순간은 AI가 사람을 대체할 때가 아니라, 사람 안에 있던 지식이 정리되어 더 많은 사람과 시스템이 활용할 수 있게 될 때다.

주요 발언 모음

"제일 찾기 어려운 거는 데이터가 아니라 컨텍스트다."

"데이터에 가진 의미를 찾는 게 어려운 게, 누가 이걸 알고 있는지 모른다."

"AI로 뭔가 잘되는 걸 보고 싶어요, AI로 매출을 올리고 싶어요라고 하면 로또를 찍어 달라는 것처럼 들린다."

"목표가 없는 AI 활용은 거의 잘 되기 어렵다."

"당장 2~3년 내에서는 만능 에이전트가 없다."

"목표를 먼저 설정하시고 AI를 어느 정도 사용하겠다는 것부터 잡아 주시면 큰 도움이 된다."

"가지고 계신 아이디어들을 잘 정리하고 AI의 힘으로 구현할 수 있다면, 크게 발전하고 회사에 기여할 수 있다."

핵심 데이터 & 수치

• 4~5년: 회사가 시스템을 운영하는 동안 초기 맥락이 사라지고 시스템이 Legacy System으로 변하는 시간의 예시다.
• 15년: 한 회사에 약 15년 근무한 베테랑이 남아 있으면 과거 데이터와 업무 규칙을 복원하는 일이 빨라진다는 사례다.
• 2~3년: 황주연이 가까운 시기에 만능 에이전트가 나오기 어렵다고 본 기간이다.
• 10년: 어떤 질문에도 답하는 만능 에이전트가 가능해지는 시점도 자신의 예상으로는 10년 안에 어렵다고 한 표현이다.
• 1~2년: 역할과 업무 범위가 정해진 팀 단위 에이전트가 현실화될 수 있다고 본 기간이다.
• 사례 2개: 목적이 명확한 AI 과제로 발주서(PO) 적합성 검증과 제품 성분표의 국가별 규정 적합성 검토를 들었다.
• 연결 기술: MCP와 Google Workspace를 활용하면 데이터 위치를 완전히 파악하지 못해도 업무 데이터 연결을 시도할 수 있다.

결론 및 시사점

1. AI 프로젝트의 첫 질문은 "어떤 모델을 쓸까?"나 "데이터가 어디에 있나?"가 아니라 "누가 어떤 업무 문제를 해결하려는가?"여야 한다.
2. "AI로 매출을 올리겠다"는 비전은 실행 목표가 아니다. PO 적합성 검증, 국가별 성분 규정 검토처럼 입력·판단·출력이 구체적인 과제로 바꿔야 한다.
3. 데이터 품질을 평가할 때는 값의 정확성뿐 아니라 정의, 생성 과정, 변환 이력, 해당 맥락을 아는 사람까지 확인해야 한다.
4. 오래된 시스템을 AI에 연결하기 전에는 퇴사자와 레거시 시스템에 남은 암묵지를 Reverse Engineering과 현업 인터뷰로 복원해야 한다.
5. 고객의 신뢰를 얻으려면 분석 결과를 한 번에 제시하지 말고, 프로토타입을 만들고 현업 담당자에게 중간 공유하며 단계적으로 검증해야 한다.
6. 현업은 문제와 아이디어를 제공하고, 인프라·개발 조직은 구현·운영을 담당하되, 두 조직이 함께 성공 기준을 정의해야 한다.
7. 만능 에이전트를 기다리기보다 역할, 데이터, 승인 흐름이 정해진 팀 업무부터 에이전트화해야 한다.
8. AI의 실질적인 가치는 개인이 수첩에 적어 둔 노하우처럼 조직 안에 흩어진 암묵지를 구조화해 재사용 가능한 가이드와 에이전트로 바꾸는 데 있다.
9. 목표 없이 만든 시스템은 기술적으로 완성되어도 사용자의 업무 흐름과 만나지 못해 폐기된다. 이것이 제목의 "아무도 쓰지 않는 시스템"이 되는 직접적인 이유다.

핵심 요약 (20줄)

AI 프로젝트가 실패하는 원인은 데이터가 부족해서가 아니라 목표와 맥락이 부족해서다.

Solution Engineer는 제품 스펙을 설명하는 데서 멈추지 않고 고객과 실제 운영을 함께한다.

자동차를 함께 타며 깜빡이와 주차를 알려 주는 비유로 고객 업무에 맞춘 지원을 설명했다.

고객의 가장 어려운 문제는 데이터 자체보다 데이터의 의미를 아는 Context를 찾는 일이다.

4~5년 운영된 시스템은 Legacy System이 되고 초기 설계 맥락이 사라질 수 있다.

작년 대비 매출이 얼마나 늘었는지 묻는 간단한 질문도 여러 정의를 포함한다.

Excel에서 매출을 뽑을 수 있어도 데이터가 어디서 와서 어떻게 변했는지는 모를 수 있다.

데이터 흐름을 모르면 추가 질문 하나에 매출 수치의 근거를 설명하지 못한다.

약 15년 근무한 베테랑이 남아 있으면 시스템과 업무 맥락을 복원하는 일이 빨라진다.

핵심 담당자가 떠났다면 Reverse Engineering으로 레거시 데이터의 의미를 복원해야 한다.

분석 과정은 고객이 불편할 수 있으므로 중간 결과와 프로토타입을 단계적으로 공유해야 한다.

AI 도입은 데이터를 먼저 준비하는 것이 아니라 AI로 무엇을 할지 먼저 정하는 데서 시작한다.

AI로 매출을 올리고 싶다는 말은 구체적인 성공 기준이 없어 로또 번호를 요구하는 것과 같다.

발주서 적합성 검증과 국가별 성분표 규정 검토는 목적이 분명한 AI 과제다.

목표가 정해지면 필요한 데이터와 구현 과정은 역으로 결정할 수 있다.

우리도 AI를 해야 한다는 식의 추진은 시간이 들어도 아무도 쓰지 않는 시스템을 만들 수 있다.

현업은 아이디어를 내고 인프라·개발 조직은 구현하므로 두 조직의 협업 문화가 필수다.

2~3년 안에 만능 에이전트는 어렵고 PO 검증이나 법률 체크처럼 목적을 좁혀야 한다.

역할이 정해진 팀의 매출 분석처럼 범위가 분명한 업무는 1~2년 안에도 에이전트화할 수 있다.

수첩 속 개인 노하우도 정리해 가이드로 만들면 조직이 활용하는 에이전트로 확장할 수 있다.