*이 장을 다 읽고 나면 알게 될 것: 왜 LLM 하나로는 부족한지, JK의 Composite AI Framework가 어떤 9개 영역으로 구성되는지, 그리고 이 프레임워크가 실제 프로젝트에서 어떻게 작동하는지*
도입: 화이트보드 앞에 선 오후
2024년 가을이었다. 서울 강남의 한 대기업 회의실. 나는 화이트보드 앞에 서 있었다. 청중은 디지털 전환 TF 팀원 열두 명. 그들의 질문은 간단했다. "우리 회사에 AI Agent를 도입하려고 합니다. 어디서부터 시작해야 하나요?"
나는 마커를 들고 화이트보드에 네모 하나를 그렸다. 그 안에 'LLM'이라고 썼다. 그리고 물었다. "여러분이 생각하는 AI Agent가 이겁니까?"
고개가 끄덕여졌다. 대부분의 사람들이 그렇게 생각한다. AI Agent는 곧 LLM이다. ChatGPT 같은 것을 우리 업무에 연결하면 된다. API 키를 받고, 프롬프트를 잘 쓰고, RAG를 붙이면 끝이다.
나는 그 네모 옆에 여덟 개의 네모를 더 그렸다. Graph DB, Vector DB, Rule Engine, ML Pipeline, Monitoring, Security, Change Management, Industry Template. 그리고 그것들을 선으로 연결했다. 선이 꽤 많았다.
"이게 제가 보는 AI Agent입니다."
회의실이 조용해졌다. 누군가가 말했다. "그러니까... LLM은 아홉 개 중 하나라는 말씀이신가요?"
맞다. LLM은 아홉 개 중 하나다. 중요한 하나이긴 하다. 그러나 하나일 뿐이다.
이 장은 4부의 첫 번째 기술 장이다. 앞의 18장에서 조직 구조의 변화를 다뤘다. 이제 그 변화를 실현하기 위한 기술 프레임워크를 본다. 4부의 제목은 "JK's Composite AI Framework"다. 솔직히 말하면 자기 이름을 붙이는 것이 조금 쑥스럽다. 그러나 이것은 내가 금융시장 분석에서 시작해 전략 컨설팅사, 컨설팅 파트너, 글로벌 IT기업 금융사업총괄이사를 거친 컨설팅 경험과, 나의 시스템 수석 AI 아키텍트로 전환한 이후의 시스템 구축 경험을 압축해 만든 것이다. 누군가의 프레임워크를 소개하는 것이 아니라 내가 만든 것을 공유하는 것이다. 그래서 이름을 붙였다.
이 장에서는 프레임워크의 전체 그림을 보여준다. 나무 하나하나를 보기 전에, 먼저 숲 전체를 조감한다. 다음 여덟 개 장에서 각 영역을 깊이 다룬다.
19.1 왜 "Composite"인가 — LLM만으로는 부족하다
Composite라는 단어를 사전에서 찾으면 "여러 요소의 복합체"라는 뜻이 나온다. 탄소 섬유 복합재가 Composite Material이다. 탄소 섬유만으로는 부족하다. 수지와 결합해야 비로소 비행기 날개가 된다. AI도 마찬가지다.
2023년에서 2024년 사이, 전 세계 기업들이 LLM에 열광했다. 그리고 2025년에 들어서면서 많은 기업이 같은 벽에 부딪혔다. LLM은 놀라운 능력을 가졌지만, 그것만으로는 기업의 실제 문제를 풀 수 없다.
왜 그런가. 몇 가지 이유가 있다.
첫째, LLM은 환각한다. 기업의 의사결정에서 환각은 치명적이다. 계약서의 숫자가 틀리면 소송이 된다. 재무 보고서의 수치가 잘못되면 감사에 걸린다. LLM만으로는 이 문제를 풀 수 없다.
둘째, LLM은 구조를 모른다. 기업의 데이터는 관계형이다. 공급업체와 부품의 관계, 고객과 계약의 관계, 부서와 프로젝트의 관계. 이런 복잡한 관계를 LLM에게 텍스트로 던져주면, 관계의 깊이를 놓친다. 그래프 데이터베이스가 필요한 이유다.
셋째, LLM은 규칙을 지키지 않는다. 정확히 말하면, 규칙을 프롬프트에 넣으면 대부분은 따르지만 가끔 무시한다. 금융 규제, 의료 프로토콜, 제조 공정 기준. 이런 것은 "대부분 따른다"로는 안 된다. 100% 따라야 한다. 그래서 Rule Engine이 필요하다.
넷째, LLM은 수치 예측에 약하다. 수요 예측, 가격 최적화, 이상 탐지. 이런 작업은 전통적인 ML 모델이 훨씬 잘한다. XGBoost, LSTM, Prophet 같은 것 말이다. LLM에게 시계열 예측을 시키는 것은 망치로 나사를 박는 것과 같다.
그래서 답은 복합이다. LLM + Graph DB + Vector DB + Rule Engine + ML Pipeline. 이것이 Composite AI의 핵심이다.
가트너가 2024년에 Composite AI라는 용어를 쓰기 시작했다. 나도 비슷한 시기에 같은 결론에 도달했다. 그러나 가트너는 개념을 제시했고, 나는 실제로 만들었다. 나의 시스템 — 반도체·AI 글로벌 밸류체인 분석·정보 제공 플랫폼 — 에서 운영하는 시스템들 — Article Lingua, SAF(Strategic Analysis Framework), KVIC(Korean Value-chain Intelligence Center) — 이 모두 이 복합 접근법으로 만들어졌다. 개념이 아니라 작동하는 시스템이다.
잠시 멈추고 생각해보자
당신이 속한 조직에서 AI를 도입하려 한다면, LLM만으로 풀 수 있는 문제와 그렇지 않은 문제를 각각 세 개씩 나열해볼 수 있는가? 그 경계는 어디에 있는가?
19.2 프레임워크가 필요했던 이유 — 컨설턴트의 오래된 습관
프레임워크를 만든 이유를 말하려면 내 직업적 습관을 먼저 말해야 한다.
나는 1995년 금융시장 분석에서 시작해 전략 컨설팅에서 전략·리스크분석 모델링·해외진출전략을 수행하고, AI/ML 솔루션 사업을 이끌고, 대학에서 글로벌 밸류체인을 강의했다. 컨설턴트의 본업은 복잡한 문제를 구조화하는 것이다. 고객이 "우리 회사가 잘 안 됩니다"라고 말하면, 그 "잘 안 됨"을 MECE하게 나누고, 각 조각의 원인을 찾고, 우선순위를 정하고, 실행 계획을 만든다. 이것을 수백 번 반복했다. 자동차, 조선, 화학, 반도체, 금융. 산업은 달라도 방법론은 같았다.
2022년 말, ChatGPT가 나왔다. 나도 처음에는 단순한 도구로 봤다. 그러나 쓰면 쓸수록 이것이 단순한 도구가 아니라는 것을 깨달았다. 이것은 기업의 업무 방식 자체를 바꿀 수 있는 것이었다.
그래서 직접 만들어보기로 했다. LangGraph로 워크플로를 짜고, pgvector로 벡터 검색을 하고, ArangoDB로 지식 그래프를 만들고, Qwen3 같은 오픈소스 LLM을 RunPod 위에 올렸다. MLflow로 실험을 추적했다. 만들면서 배우고, 배우면서 만들었다.
그 과정에서 패턴이 보이기 시작했다. 어떤 프로젝트든 같은 아홉 가지 질문이 반복되었다.
1. 이 과제가 정말 AI로 풀어야 하는 것인가?
2. 시스템의 구조를 어떻게 설계할 것인가?
3. 어떤 데이터와 지식이 필요한가?
4. 어떤 기술 스택을 쓸 것인가?
5. 어떤 순서로 만들 것인가?
6. 만든 후 어떻게 관찰하고 개선할 것인가?
7. 보안과 거버넌스를 어떻게 확보할 것인가?
8. ROI를 어떻게 증명하고 조직을 어떻게 바꿀 것인가?
9. 우리 산업의 특수성을 어떻게 반영할 것인가?
이 아홉 가지 질문이 아홉 개의 영역이 되었다. 그것이 Composite AI Framework다. 거창한 것이 아니다. 수백 번의 프로젝트 경험과 수십 번의 시스템 구축 경험이 만들어낸 체크리스트다.
19.3 아홉 개의 영역 — 숲의 지도
이제 전체 구조를 본다. 아홉 개의 영역을 하나씩 짧게 소개한다. 깊은 내용은 다음 장부터 다룬다.
영역 1. 과제 발굴 — RAPIDS + MECE + 4D Ready
모든 것은 과제에서 시작한다. AI를 도입하겠다는 의지는 좋다. 그러나 어떤 과제에 적용할 것인가를 제대로 정하지 않으면, 좋은 기술도 방향을 잃는다.
나는 과제 발굴에 세 가지 도구를 결합한다. RAPIDS는 과제의 반복성(Repetitive), 자동화 가능성(Automatable), 예측 가능성(Predictable), 정보 풍부성(Information-rich), 의사결정 밀도(Decision-heavy), 확장성(Scalable)을 평가하는 6가지 기준이다. 여기에 MECE로 누락 없이 후보를 나열하고, 4D Ready(Data ready, Domain ready, Decision ready, Deployment ready) 필터로 실행 가능성을 검증한다. 이 과정을 거치면 "할 수 있고, 해야 하는" 과제가 남는다.
영역 2. 아키텍처 설계 — 9-node GoT
과제가 정해지면 시스템의 뼈대를 설계한다. 나는 9-node Graph of Thought(GoT) 아키텍처를 쓴다. 전통적인 선형 파이프라인이 아니다. 그래프다. 노드 사이에 조건부 분기, 병렬 처리, 피드백 루프가 있다. LangGraph가 이 구조를 코드로 구현하는 데 적합하다.
왜 9개 노드인가. 경험적으로 그렇다. 너무 적으면 유연성이 떨어지고, 너무 많으면 복잡도가 폭발한다. 9개가 대부분의 기업 과제를 다루기에 충분한 수다. 물론 프로젝트에 따라 노드를 더하거나 뺀다.
영역 3. 데이터와 지식 — Graflo, OntoCast, GraphRAG
AI의 품질은 데이터의 품질이 결정한다. 이것은 진부한 말이지만 여전히 사실이다.
나는 데이터와 지식을 세 층으로 나눈다. Graflo는 비정형 데이터를 그래프 구조로 변환하는 파이프라인이다. OntoCast는 도메인 온톨로지를 자동으로 구축하고 관리하는 시스템이다. GraphRAG는 ArangoDB 기반의 그래프 검색과 pgvector 기반의 벡터 검색을 결합한 하이브리드 검색이다. 단순한 텍스트 RAG보다 맥락을 훨씬 깊이 이해한다.
영역 4. 기술 스택 — LangGraph, pgvector, ArangoDB 등
기술 스택은 도구 상자다. 어떤 도구를 쓸 것인가는 과제와 아키텍처가 정해진 후에 결정해야 한다. 순서가 중요하다. 기술부터 정하고 과제를 찾는 것은 망치를 들고 못을 찾는 것이다.
나의 기본 스택은 이렇다. 오케스트레이션은 LangGraph. 벡터 검색은 pgvector. 그래프 데이터베이스는 ArangoDB. LLM은 프로젝트에 따라 다른데, 비용과 보안이 중요하면 Qwen3 같은 오픈소스를, 성능이 우선이면 Claude나 GPT를 쓴다. GPU 인프라는 RunPod. 실험 추적은 MLflow. 이 조합이 비용 대비 성능에서 가장 균형 잡혀 있다는 것이 내 경험이다.
영역 5. 구현 로드맵 — PoC에서 운영까지
좋은 설계는 필요 조건이다. 충분 조건은 아니다. 실제로 만들어야 한다. 그리고 만드는 과정에는 명확한 단계가 필요하다.
나는 네 단계를 따른다. PoC(4~12주), MVP(4~8주), Pilot(8~12주), Production. 각 단계마다 통과 기준이 있다. PoC에서 MVP로 넘어가려면 핵심 기능의 정확도가 목표치를 넘어야 한다. MVP에서 Pilot으로 가려면 사용자가 실제로 쓸 수 있어야 한다. 이 단계를 건너뛰면 나중에 더 큰 비용을 치른다.
영역 6. AgentOps — 관찰, 평가, 개선
시스템을 배포한 후가 진짜 시작이다. LLM 기반 시스템은 전통적 소프트웨어와 다르다. 같은 입력에도 다른 출력이 나올 수 있다. 그래서 지속적인 관찰이 필요하다.
AgentOps는 세 가지 축으로 구성된다. 관찰(Observe) — 시스템이 실제로 무엇을 하고 있는지 추적한다. 평가(Evaluate) — 출력의 품질을 자동으로 측정한다. 개선(Improve) — 관찰과 평가 결과를 바탕으로 프롬프트, 검색, 모델을 조정한다. 이것은 한 번 하고 끝나는 것이 아니라 영원히 돌아가는 바퀴다.
영역 7. 보안과 거버넌스
AI 시스템이 기업의 핵심 업무에 들어가면 보안이 급이 달라진다. 고객 데이터가 LLM으로 흘러가는 것을 막아야 한다. 프롬프트 인젝션 공격을 방어해야 한다. 누가 어떤 데이터에 접근할 수 있는지를 통제해야 한다. 규제 준수도 확인해야 한다.
이 영역은 기술만의 문제가 아니다. 정책, 프로세스, 교육이 함께 가야 한다. 기술적으로는 완벽한데 사람이 비밀번호를 포스트잇에 써 붙여놓으면 소용없다.
영역 8. ROI와 조직 변화관리
기업에서 AI 프로젝트가 죽는 가장 흔한 이유는 기술의 실패가 아니다. ROI를 증명하지 못해서다. 또는 조직이 변화를 받아들이지 않아서다.
Pilot purgatory라는 말이 있다. PoC는 성공하는데 운영으로 넘어가지 못하는 상태. 2025년 현재 전 세계 기업 AI 프로젝트의 절반 이상이 이 상태에 머물러 있다는 조사가 있다. 기술이 아니라 조직의 문제다. 그래서 이 영역을 프레임워크에 포함시켰다. 기술만 아는 컨설턴트는 이 지점에서 실패한다. 전략 컨설팅사, 컨설팅, 글로벌 IT기업를 거치며 조직을 봐온 경험이 여기서 쓰인다.
영역 9. 산업별 적용
마지막 영역이다. 모든 산업은 고유한 규칙, 데이터, 프로세스를 가진다. 금융은 규제가 촘촘하다. 제조는 실시간 데이터가 핵심이다. 의료는 정확도가 생명이다. 유통은 수요 예측이 핵심이다.
앞의 여덟 개 영역이 범용 엔진이라면, 이 영역은 산업별 튜닝이다. 같은 프레임워크를 쓰되, 산업의 언어와 규칙에 맞게 조정한다. 자동차 산업에서 쓰는 Composite AI와 금융에서 쓰는 Composite AI는 구조는 같되 내용이 다르다.
잠시 멈추고 생각해보자
아홉 개 영역 중에서 당신의 조직이 가장 강한 영역은 어디인가? 가장 약한 영역은? 그 약한 영역이 전체 프로젝트의 병목이 되고 있지는 않은가?
19.4 복합의 힘 — 네 가지 기술의 결합
Composite AI의 핵심을 한 문장으로 줄이면 이렇다. 서로 다른 AI 기술이 각자의 강점으로 서로의 약점을 메운다.
구체적으로 보자.
Graph + LLM. 지식 그래프는 엔티티 사이의 관계를 정확히 표현한다. LLM은 자연어를 이해하고 생성한다. 둘을 결합하면, 사용자가 자연어로 질문하고 그래프가 정확한 관계를 찾아 LLM이 답을 생성하는 시스템이 된다. 순수 LLM보다 환각이 크게 줄어든다.
Vector + Graph. 벡터 검색은 의미적 유사성을 잘 찾는다. 그러나 "A와 B의 관계"를 정확히 찾지는 못한다. 그래프 검색은 관계를 정확히 찾지만, 유사한 개념을 넓게 탐색하지는 못한다. 둘을 합치면 넓이와 깊이를 동시에 가진다. 이것이 GraphRAG의 핵심 아이디어다.
Rule + LLM. LLM은 유연하다. 그러나 규칙을 100% 따르는 것은 불가능하다. Rule Engine은 딱딱하다. 그러나 규칙은 100% 따른다. 둘을 합치면, LLM이 유연하게 판단하되 최종 출력은 Rule Engine이 검증하는 구조가 된다. 금융이나 의료 같은 규제 산업에서 필수적인 조합이다.
ML + LLM. 수요 예측, 이상 탐지, 분류 같은 작업은 전통 ML이 더 정확하다. LLM은 그 결과를 사람이 이해할 수 있게 설명하고, 다음 행동을 제안한다. ML이 "다음 달 수요가 15% 증가할 것"이라고 예측하면, LLM이 "재고를 미리 확보하고 물류 파트너에게 통보하라"고 말한다. 예측의 정확성과 행동의 구체성이 합쳐진다.
이 네 가지 결합이 Composite AI의 근간이다. 어떤 프로젝트에서든 이 네 가지 중 최소 두 가지는 쓰인다. 네 가지가 모두 쓰이는 프로젝트도 있다.
19.5 실전에서의 작동 — 나의 시스템의 세 가지 시스템
이론은 여기까지다. 실전을 보자. 나의 시스템에서 이 프레임워크로 만든 세 가지 시스템을 짧게 소개한다.
Article Lingua. 영어 학습 플랫폼이다. Economist와 WSJ 기사를 기반으로 한다. LangGraph 4-노드 파이프라인이 기사를 분석하고, 사용자 수준에 맞는 어휘를 추출하고, SM-2 알고리즘으로 복습 일정을 만든다. 여기서 Composite AI가 어떻게 작동하는가. LLM이 기사를 분석한다. Vector DB가 유사 기사를 찾는다. ML 모델이 사용자의 어휘 수준을 예측한다. Rule Engine이 복습 간격을 계산한다. 네 가지가 모두 쓰인다.
SAF(Strategic Analysis Framework). 글로벌 산업 분석 리포트를 자동으로 생성하는 시스템이다. 매일 수백 개의 뉴스를 수집하고, GraphRAG로 산업별 맥락을 파악하고, LLM이 분석 리포트를 작성한다. Graph DB(ArangoDB)가 기업 간 관계, 공급망 구조, 기술 의존도를 저장한다. 단순히 뉴스를 요약하는 것이 아니다. "이 뉴스가 어떤 기업의 어떤 사업에 어떤 영향을 줄 수 있는가"를 구조적으로 분석한다. LLM만으로는 불가능한 작업이다.
KVIC(Korean Value-chain Intelligence Center). 한국 가치사슬 인텔리전스 시스템이다. 2권에서 다룬 삼중 매트릭스 — 반도체 × 디지털 AI × Physical AI — 를 실시간 데이터로 모니터링한다. 기업 실적, 특허, 뉴스, 정책을 그래프로 연결하고, 가치사슬의 변화를 추적한다. 여기서는 Graph DB가 핵심이다. 수천 개의 기업과 기술이 어떻게 연결되어 있는지를 그래프가 표현하고, LLM이 그 변화의 의미를 해석한다.
세 시스템의 공통점이 보이는가. LLM 혼자 일하는 것이 하나도 없다. 항상 Graph, Vector, ML, Rule 중 두 가지 이상과 협력한다. 이것이 Composite AI다.
잠시 멈추고 생각해보자
당신의 업무에서 LLM만으로 풀리지 않는 문제는 무엇인가? 그 문제에 Graph, Vector, Rule, ML 중 어떤 것을 결합하면 풀릴 수 있겠는가?
19.6 프레임워크를 읽는 순서 — 다음 여덟 개 장의 지도
이 장은 숲 전체를 조감한 것이다. 다음 여덟 개 장에서 각 영역을 하나씩 깊이 들어간다.
19장은 과제 발굴이다. RAPIDS, MECE, 4D Ready를 써서 어떻게 "할 수 있고, 해야 하는" 과제를 찾는지를 다룬다.
20장은 아키텍처 설계다. 9-node GoT 아키텍처가 무엇인지, LangGraph로 어떻게 구현하는지를 본다.
21장은 데이터와 지식이다. Graflo, OntoCast, GraphRAG의 실체를 파헤친다.
22장은 기술 스택과 환경 설계다. LangGraph, pgvector, ArangoDB, Qwen3, RunPod, MLflow를 어떻게 조합하는지를 다룬다.
23장은 구현 로드맵이다. PoC에서 운영까지의 구체적 단계와 각 단계의 통과 기준을 정리한다.
24장은 AgentOps다. 관찰, 평가, 개선의 실무를 다룬다.
25장은 보안과 거버넌스다. 기업 환경에서 AI Agent를 안전하게 운영하는 방법을 본다.
26장은 ROI와 조직 변화관리다. Pilot purgatory를 어떻게 탈출하는지, 조직을 어떻게 움직이는지를 다룬다.
그리고 5부에서는 이 프레임워크를 산업별로 적용하는 방법을 본다. 28장이 산업별 Enterprise Agent, 29장이 한국형 Agentic Enterprise다.
순서대로 읽어도 좋고, 자기에게 급한 영역부터 읽어도 좋다. 그러나 한 가지만 기억하라. 이 아홉 개 영역은 서로 연결되어 있다. 과제 발굴 없이 아키텍처를 설계하면 방향을 잃는다. 아키텍처 없이 기술 스택을 고르면 삽질한다. 기술만 있고 AgentOps가 없으면 시스템이 썩는다. ROI 없이 만들면 조직이 외면한다. 하나도 빠질 수 없다.
핵심 정리
Composite AI는 단일 AI 기술이 아니라 여러 AI 기술의 복합이다. LLM, Graph DB, Vector DB, Rule Engine, ML Pipeline이 각자의 강점으로 서로의 약점을 메운다. LLM만으로 기업의 실제 문제를 풀 수 있다는 생각은 환상이다.
JK의 Composite AI Framework는 아홉 개의 영역으로 구성된다. 과제 발굴, 아키텍처 설계, 데이터/지식, 기술 스택, 구현 로드맵, AgentOps, 보안/거버넌스, ROI/조직 변화관리, 산업별 적용. 이 아홉 가지는 데이터 분석, 머신러닝 기반 컨설팅, AI 솔루션 사업을 거친 경험과 나의 시스템에서의 Agentic AI 시스템 구축 경험이 만들어낸 체크리스트다.
이 프레임워크는 나의 시스템의 세 가지 시스템 — Article Lingua, SAF, KVIC — 에서 실제로 작동하고 있다. 세 시스템 모두 LLM 혼자 일하지 않는다. Graph, Vector, ML, Rule 중 두 가지 이상과 항상 협력한다.
아홉 개 영역은 서로 연결되어 있다. 하나를 빠뜨리면 전체가 흔들린다. 다음 여덟 개 장에서 각 영역을 하나씩 깊이 다룬다.
프레임워크는 지도다. 지도 자체가 목적지는 아니다. 그러나 지도 없이 길을 떠나는 것은 용기가 아니라 무모함이다.
반드시 답해봐야 할 질문 5가지
질문 1. 당신의 조직은 지금 AI를 어떻게 사용하고 있는가? LLM 단독인가, 아니면 다른 기술과 결합하고 있는가? 결합하고 있다면 어떤 조합인가?
질문 2. 아홉 개 영역 중에서 당신의 조직이 가장 취약한 영역은 어디인가? 그 취약함이 AI 프로젝트의 실패로 이어진 경험이 있는가?
질문 3. Pilot purgatory에 빠진 적이 있는가? 그 원인은 기술이었는가, 조직이었는가, ROI 증명의 실패였는가?
질문 4. 당신의 업무에서 Graph DB가 필요한 장면은 무엇인가? 엔티티 간 관계가 복잡한 데이터를 다루고 있는가? 지금은 그것을 어떻게 처리하고 있는가?
질문 5. 만약 Composite AI Framework를 당신의 조직에 적용한다면, 어떤 과제부터 시작하겠는가? 그 과제를 선택한 이유는 무엇인가?
더 깊이 탐구하기
가트너, 「Composite AI」 리서치 노트 (2024). Composite AI 개념의 학술적·산업적 정의와 시장 전망을 정리한 보고서.
Chip Huyen, *AI Engineering* (O'Reilly, 2025). LLM 기반 애플리케이션 설계의 실전 가이드.
해리슨 체이스, 「LangGraph Documentation」 (2025). LangGraph의 공식 문서이자 그래프 기반 Agent 오케스트레이션의 가장 실용적인 참고 자료.
ArangoDB, 「GraphRAG with ArangoDB」 기술 백서 (2025). 그래프 데이터베이스와 RAG를 결합하는 구체적 방법론을 다룬 기술 문서.
나의 시스템, 「Composite AI Framework 내부 백서」 (2025). 이 프레임워크의 상세 버전. Article Lingua, SAF, KVIC의 아키텍처와 성과 지표를 포함한다.
다음 장에서는 프레임워크의 첫 번째 영역인 과제 발굴로 들어간다. RAPIDS, MECE, 4D Ready를 써서 "AI가 풀어야 할 진짜 문제"를 어떻게 찾는지를 본다. 기술보다 먼저 과제가 있다. 좋은 과제를 찾지 못하면 좋은 기술도 쓸모가 없다.