*이 장을 다 읽고 나면 알게 될 것: 좋은 AI Agent 과제를 찾는 체계적 방법, RAPIDS 프레임워크로 과제를 평가하는 법, MECE로 빠짐없이 분류하는 법, 4D Ready 체크리스트로 실행 가능성을 검증하는 법, 그리고 첫 과제 선택이 왜 조직 전체의 학습 장치가 되는가*
도입: 회의실에서 벌어진 일
2019년 어느 가을. 서울의 한 대기업 회의실이었다. 디지털 전환 TF 킥오프 미팅. 스무 명 남짓한 임원과 팀장이 모여 있었다. 나는 컨설턴트로 앉아 있었다.
CTO가 말했다. "AI로 할 수 있는 일을 모두 정리해오라고 했습니다. 각 부서에서 올린 과제가 몇 개인지 아십니까?" 슬라이드가 넘어갔다. 숫자가 떴다. 127개.
회의실이 웅성거렸다. 127개. 대단해 보였다. 그러나 나는 속으로 한숨을 쉬었다. 경험상 이런 리스트는 위험하다.
리스트를 훑어봤다. "고객 문의 자동 응답", "보고서 자동 생성", "재고 예측", "직원 감정 분석", "회의록 요약". 그럴듯해 보였다. 그러나 절반은 데이터가 없었다. 3분의 1은 담당자가 불분명했다. 나머지의 상당수는 현업 부서가 원하지 않는 것이었다. IT 부서가 기술적으로 해볼 만하다고 올린 것이었다.
6개월 뒤, 이 회사는 127개 중 3개를 시작했다. 12개월 뒤, 3개 중 1개만 살아남았다. 살아남은 1개도 현업에 제대로 안착하지 못했다. Pilot purgatory. 시범사업의 연옥이다.
나는 이런 장면을 여러 번 봤다. 데이터 분석 기반 컨설팅을 하면서. 기술이 바뀌어도 패턴은 같다. ERP 도입 때도 그랬고, 빅데이터 때도 그랬고, AI 때도 그렇다. 문제는 늘 같은 곳에 있다. 좋은 과제를 찾는 것이 가장 어려운 일이다.
기술은 넘친다. 도구도 넘친다. 인력도 어떻게든 구한다. 그런데 좋은 과제가 없다. 더 정확히 말하면, 좋은 과제를 고르는 눈이 없다. 127개를 모으는 것은 쉽다. 그중에서 진짜 해야 할 3개를 고르는 것이 어렵다. 그리고 그 3개 중에서 첫 번째를 고르는 것이 가장 어렵다.
이 장은 그 눈을 만드는 장이다.
20.1 왜 과제 발굴이 가장 어려운가
Agent를 만드는 일은 기술 프로젝트처럼 보인다. 그러나 실은 비즈니스 프로젝트다. 기술은 수단이고, 과제가 목적이다. 목적이 잘못되면 수단이 아무리 좋아도 소용없다.
많은 조직이 이 순서를 뒤집는다. "LangGraph를 써보고 싶다"에서 시작한다. "GPT-4를 연동해보고 싶다"에서 시작한다. 기술에서 출발해서 과제를 찾는다. 이것이 첫 번째 함정이다. 기술에서 출발하면, 기술에 맞는 과제를 찾게 된다. 조직에 가장 중요한 과제가 아니라.
두 번째 함정은 너무 큰 과제를 고르는 것이다. "전사 지식 관리 시스템", "고객 경험 전면 혁신", "공급망 자동 최적화". 듣기엔 멋지다. 그러나 이런 과제는 범위가 넓고, 이해관계자가 많고, 성공의 기준이 모호하다. 첫 과제로는 최악이다.
세 번째 함정은 너무 작은 과제를 고르는 것이다. "회의록 요약", "이메일 자동 분류". 빨리 만들 수 있다. 데모도 된다. 그러나 비즈니스 임팩트가 작다. 경영진이 관심을 끊는다. 예산이 줄어든다. 팀이 흩어진다.
좋은 과제는 이 세 함정 사이의 좁은 길에 있다. 기술이 아니라 비즈니스에서 출발하고, 너무 크지도 작지도 않으며, 성공하면 조직이 눈에 띄게 달라지는 과제. 그것을 찾아야 한다.
그래서 체계가 필요하다.
잠시 멈추고 생각해보자
당신의 조직에서 AI 프로젝트를 시작할 때, 과제를 먼저 정했는가 기술을 먼저 정했는가? 만약 기술에서 출발했다면, 그 프로젝트는 지금 어떻게 되었는가?
20.2 RAPIDS 프레임워크 — 좋은 과제의 여섯 가지 조건
나는 30년간의 산업 컨설팅 경험에서 하나의 프레임워크를 정리했다. 좋은 Agent 과제를 평가하는 여섯 가지 기준이다. 앞글자를 따면 RAPIDS가 된다. 급류라는 뜻이다. 좋은 과제는 물살이 빠른 곳에 있다. 느리고 고인 곳에는 없다.
R — Repetitive (반복적인가)
좋은 과제는 반복적이다. 한 번 하고 끝나는 일이 아니라, 매일, 매주, 매월 되풀이되는 일이어야 한다. Agent는 한 번 만들면 계속 쓰인다. 그러므로 과제도 계속 발생해야 한다.
삼성SDS가 사내 IT 헬프데스크에 챗봇을 도입한 것이 좋은 예다. "비밀번호 초기화해주세요", "VPN 접속이 안 됩니다", "프린터가 안 됩니다". 하루에 수백 건씩 반복되는 문의다. 이런 과제는 Agent가 가장 빛을 발한다.
반면, "올해 사업 전략을 수립하라"는 과제는 어떤가. 일 년에 한 번 하는 일이다. Agent가 도울 수 있지만, 그것만을 위해 Agent를 만드는 것은 비효율적이다.
반복의 빈도를 본다. 일 단위, 주 단위, 월 단위. 빈도가 높을수록 좋은 과제다.
A — Automatable (자동화 가능한가)
반복적이라고 다 자동화할 수 있는 것은 아니다. 자동화가 가능하려면 두 가지가 필요하다. 규칙이 명확하거나, 패턴이 학습 가능해야 한다.
규칙이 명확한 일은 전통적 자동화로도 된다. RPA의 영역이다. Agent가 필요한 것은 규칙이 완벽하지 않지만 패턴이 있는 일이다. 예를 들어, 고객 문의를 분류하는 일. 규칙으로 정리하면 50개쯤 된다. 그래도 빠지는 것이 있다. 그러나 패턴은 있다. 이런 일에 LLM 기반 Agent가 강하다.
자동화가 어려운 일은 무엇인가. 고도의 창의성이 필요하거나, 물리적 세계와 상호작용이 필요하거나, 정치적 판단이 개입되는 일이다. 이런 일은 Agent가 "돕는" 것은 가능하지만, "대신하는" 것은 아직 어렵다.
P — Predictable (예측 가능한가)
좋은 과제는 입력과 출력의 관계가 어느 정도 예측 가능하다. 같은 입력이 들어오면 비슷한 출력이 나와야 한다. 완벽히 같을 필요는 없다. 그러나 대략의 범위가 있어야 한다.
주가 예측은 어떤가. 입력은 방대하고 출력은 불확실하다. 그래도 특정 조건에서 방향성은 패턴이 있다. 나의 시스템에서 우리가 만든 주가 예측 시스템도 정확한 가격을 맞히는 것이 아니라, 방향성과 리스크 시그널을 포착하는 데 초점을 둔다. 출력의 범위를 좁히면 예측 가능성이 올라간다.
반면, "이 광고 캠페인이 성공할까?"는 예측이 매우 어렵다. 변수가 너무 많고, 과거 패턴이 미래를 보장하지 않는다. 이런 과제는 Agent가 분석을 도울 수는 있지만, 핵심 판단을 맡기기는 어렵다.
I — Information-rich (데이터가 풍부한가)
Agent는 데이터를 먹고 산다. 데이터가 없으면 Agent도 없다. 이것은 당연한 이야기지만, 놀랍도록 많은 프로젝트가 이 당연한 것을 무시한다.
"데이터가 있다"와 "데이터에 접근할 수 있다"는 다른 말이다. 데이터가 있어도 시스템에 갇혀 있으면 쓸 수 없다. 종이 문서에 있으면 디지털화부터 해야 한다. 개인정보가 포함되어 있으면 법적 검토가 필요하다.
미국의 JP모건이 계약서 검토에 AI를 도입한 사례가 유명하다. 연간 36만 시간의 법률 검토 업무를 AI가 수초 만에 처리한다는 이야기. 이것이 가능했던 이유 중 하나는 JP모건에 수십 년간 축적된 계약서 데이터가 디지털 형태로 존재했기 때문이다. 데이터의 양과 질, 그리고 접근 가능성. 세 가지 모두 충족되어야 한다.
D — Decision-heavy (의사결정이 많은가)
Agent의 진짜 가치는 단순 자동화가 아니라 의사결정 지원이다. 매일 수십 번의 작은 판단을 내려야 하는 업무가 좋은 과제다.
예를 들어, 이커머스 회사의 상품 추천이 그렇다. 어떤 고객에게 어떤 상품을 보여줄 것인가. 하루에 수백만 번의 판단이 일어난다. 각각의 판단은 작지만, 합치면 매출의 상당 부분을 좌우한다. 쿠팡이 추천 알고리즘에 투자하는 이유다.
기업 내부에서도 마찬가지다. 구매 발주 승인, 인력 배치, 일정 조정, 고객 응대 방식 결정. 매일 반복되는 작은 의사결정들. 이런 곳에 Agent를 두면 일관성이 올라가고, 속도가 빨라지고, 담당자의 부담이 줄어든다.
S — Scalable (확장 가능한가)
마지막 기준은 확장성이다. 한 부서에서 성공하면 다른 부서로 퍼질 수 있는가. 한 프로세스에서 성공하면 유사한 프로세스에 적용할 수 있는가.
네이버가 스마트스토어 판매자 지원에 AI를 도입한 것을 보자. 상품 설명 자동 생성, 고객 문의 자동 응답, 광고 최적화 추천. 이런 기능은 한 판매자에게 적용되면 수십만 판매자에게 확장할 수 있다. 확장 비용이 거의 선형적이다. 이것이 좋은 과제다.
반면, 특정 임원의 보고서 스타일에 맞춘 자동화는 확장이 어렵다. 그 임원이 바뀌면 쓸모없어진다. 다른 부서에 적용하려면 처음부터 다시 만들어야 한다.
여섯 가지 기준을 한눈에 보면 이렇다. 반복적이고, 자동화 가능하고, 예측 가능하고, 데이터가 풍부하고, 의사결정이 빈번하고, 확장 가능한 과제. RAPIDS 점수가 높을수록 좋은 Agent 과제다.
잠시 멈추고 생각해보자
당신의 업무 중 RAPIDS 여섯 기준을 모두 충족하는 것이 있는가? 각 기준별로 1~5점을 매겨본다면, 총점이 가장 높은 업무는 무엇인가?
20.3 MECE로 과제를 빠짐없이 분류하기
RAPIDS는 개별 과제의 품질을 평가하는 도구다. 그러나 그 전에 과제를 빠짐없이 찾아야 한다. 여기서 MECE가 등장한다.
MECE는 컨설팅의 기본 원칙이다. Mutually Exclusive, Collectively Exhaustive. 서로 겹치지 않고, 빠진 것이 없게. 맥킨지에서 시작된 이 원칙은 단순하지만 강력하다.
과제를 MECE로 분류하는 방법은 여러 가지가 있다. 내가 실무에서 가장 자주 쓰는 방법은 두 가지 축을 교차하는 것이다.
첫 번째 축: 업무 프로세스 단계
어떤 조직이든 핵심 프로세스가 있다. 제조업이라면 구매-생산-물류-판매-서비스. 금융이라면 고객획득-심사-운용-리스크관리-결산. 이 프로세스의 각 단계를 나열하면 첫 번째 축이 된다.
두 번째 축: 업무 유형
각 단계 안에서 업무의 성격을 분류한다. 데이터 수집, 분석과 판단, 문서 작성, 커뮤니케이션, 모니터링. 이 다섯 가지 유형이면 대부분의 업무를 덮는다.
두 축을 교차하면 매트릭스가 된다. 프로세스 단계가 5개이고 업무 유형이 5개이면 25칸이 나온다. 각 칸에 해당하는 업무를 채운다. 이렇게 하면 빠진 것을 발견하기 쉽다. "구매 단계의 모니터링 업무는 뭐가 있지?" 이런 질문이 자연스럽게 나온다.
빈 칸이 있다고 걱정할 필요는 없다. 모든 칸에 과제가 있어야 하는 것은 아니다. 그러나 빈 칸이 있다는 것을 아는 것이 중요하다. 모르고 빈 것과 알고 빈 것은 다르다.
실제 작업에서는 이 매트릭스를 워크숍 형태로 채운다. 현업 담당자 5~8명이 모여서, 각 칸에 해당하는 업무를 포스트잇에 적어 붙인다. 한 시간이면 80~120개의 후보 과제가 나온다. 도입부에서 말한 127개도 이런 식으로 나온 것이다. 문제는 그 다음이다. 이 많은 후보 중에서 좋은 것을 골라야 한다. 여기서 RAPIDS가 다시 등장한다.
매트릭스의 각 과제에 RAPIDS 점수를 매긴다. 6개 기준에 각각 1~5점. 총 30점 만점. 점수가 높은 순서대로 정렬한다. 상위 10개가 후보군이 된다.
이 방법이 완벽하지는 않다. 점수가 주관적이다. 같은 과제에 대해 현업과 IT가 다른 점수를 매기기도 한다. 그래서 점수 자체보다 점수를 매기는 과정에서 나오는 토론이 더 중요하다. "왜 이 과제의 데이터 점수가 낮다고 보는가?" "확장성을 높이려면 무엇이 필요한가?" 이런 대화가 과제를 날카롭게 만든다.
잠시 멈추고 생각해보자
당신의 조직에서 핵심 프로세스는 몇 단계로 나뉘는가? 각 단계에서 가장 반복적이고 시간이 많이 드는 업무는 무엇인가? 그 업무에 데이터는 충분한가?
20.4 4D Ready 체크리스트 — 실행 가능성의 네 가지 문
RAPIDS 점수가 높은 과제를 골랐다. 그러나 아직 시작하면 안 된다. 하나 더 확인할 것이 있다. 실행 가능성이다.
아무리 좋은 과제라도 실행 조건이 갖춰지지 않으면 실패한다. 나는 이것을 4D Ready라고 부른다. 네 가지 D가 모두 Ready여야 시작할 수 있다.
Data Ready — 데이터에 접근할 수 있는가
RAPIDS의 I(Information-rich)와 겹치는 부분이 있다. 그러나 여기서는 더 구체적으로 본다.
데이터가 어디에 있는가. 어떤 형식인가. API로 접근할 수 있는가. 개인정보가 포함되어 있는가. 비식별화가 필요한가. 데이터의 품질은 어떤가. 결측값이 많은가. 최신 데이터인가.
이 질문에 하나라도 "모르겠다"가 나오면 아직 Data Ready가 아니다. 먼저 데이터 실사를 해야 한다. 데이터 실사 없이 프로젝트를 시작하는 것은 지도 없이 산에 오르는 것과 같다.
한국의 한 중견 제조업체에서 있었던 일이다. 품질 검사 자동화를 하겠다고 프로젝트를 시작했다. 3개월 뒤에 알게 된 사실. 품질 검사 데이터의 절반이 종이 체크리스트에 있었다. 나머지 절반은 엑셀 파일에 있었는데, 부서마다 양식이 달랐다. 데이터를 정리하는 데만 4개월이 걸렸다. 프로젝트 일정은 이미 무너져 있었다.
Domain Ready — 도메인 전문가가 확보되었는가
Agent는 기술팀만으로는 만들 수 없다. 해당 업무를 가장 잘 아는 사람이 반드시 참여해야 한다. 그 사람이 Domain Expert다.
도메인 전문가의 역할은 세 가지다. 첫째, 업무의 규칙과 예외를 알려준다. 둘째, Agent의 출력이 맞는지 판단한다. 셋째, 현업에 안착하도록 돕는다. 이 세 가지 중 하나라도 빠지면 Agent는 현실과 동떨어진 것이 된다.
문제는 도메인 전문가가 바쁘다는 것이다. 그들은 현업에서 가장 잘하는 사람이다. 가장 잘하는 사람이 가장 바쁘다. 그래서 프로젝트에 시간을 내기 어렵다. 이것을 해결하지 않으면 프로젝트는 표류한다.
해법은 간단하지만 어렵다. 경영진이 도메인 전문가의 시간을 공식적으로 확보해줘야 한다. "여유 시간에 참여하라"가 아니라, "주 2일은 이 프로젝트에 투입하라"가 되어야 한다. 이것이 Decision Ready와 연결된다.
Decision Ready — 의사결정자가 지원하는가
Agent 프로젝트의 가장 큰 적은 기술적 난관이 아니다. 조직 정치다.
새로운 Agent가 기존 업무를 바꾼다. 업무가 바뀌면 권한이 바뀐다. 권한이 바뀌면 저항이 생긴다. 이 저항을 뚫으려면 충분한 권한을 가진 의사결정자의 지원이 필요하다.
의사결정자의 지원이란 구체적으로 무엇인가. 세 가지다. 예산을 배정한다. 인력을 배정한다. 장애물이 생겼을 때 해결해준다. 이 세 가지를 하지 않는 의사결정자는 지원하는 것이 아니라 구경하는 것이다.
글로벌 사례를 보면 명확하다. 아마존의 알렉사 팀이 초기에 성공할 수 있었던 이유 중 하나는 제프 베이조스가 직접 관심을 갖고 자원을 밀어넣었기 때문이다. 반면, 구글의 수많은 AI 프로젝트 중 상당수가 사라진 이유는 조직 내부의 우선순위 경쟁에서 밀렸기 때문이다. 기술의 문제가 아니었다.
Deployment Ready — 운영 환경이 준비되었는가
마지막 D는 운영 환경이다. Agent를 만들었다고 끝이 아니다. 현업에서 실제로 쓸 수 있어야 한다.
운영 환경은 기술적인 것과 조직적인 것이 있다.
기술적으로는 인프라가 준비되어야 한다. 클라우드인가, 온프레미스인가. 보안 정책에 맞는가. 기존 시스템과 연동할 수 있는가. 응답 속도는 충분한가.
조직적으로는 운영 체계가 준비되어야 한다. Agent가 틀린 답을 내면 누가 대응하는가. 모델을 업데이트하는 주기는 어떻게 되는가. 사용자 교육은 어떻게 하는가. 성과를 어떻게 측정하는가.
4D 중 하나라도 빨간불이면, 프로젝트를 시작하기 전에 그 빨간불부터 해결해야 한다. 빨간불을 무시하고 시작하면, 나중에 더 큰 비용을 치른다.
잠시 멈추고 생각해보자
당신의 조직에서 진행 중인 AI 프로젝트가 있다면, 4D Ready를 각각 체크해보라. 어느 D에 가장 큰 빨간불이 켜져 있는가? 그 빨간불은 누가 해결할 수 있는가?
20.5 우선순위 매트릭스 — Impact × Feasibility
RAPIDS로 과제의 품질을 평가했다. 4D Ready로 실행 가능성을 확인했다. 이제 우선순위를 정해야 한다. 후보가 10개라면 어떤 순서로 할 것인가.
가장 단순하면서도 효과적인 도구는 2×2 매트릭스다. 가로축에 Feasibility(실행 용이성), 세로축에 Impact(비즈니스 임팩트). 각 과제를 이 매트릭스 위에 놓는다.
오른쪽 위 (Impact 高, Feasibility 高): Quick Win. 당장 시작해야 할 과제다. 성과도 크고 실행도 쉽다. 이런 과제가 많지는 않다. 그러나 하나만 있어도 첫 과제로 충분하다.
왼쪽 위 (Impact 高, Feasibility 低): Strategic. 전략적으로 중요하지만 당장은 어렵다. 로드맵에 넣되, 지금은 준비 작업을 한다. 데이터를 모으거나, 도메인 전문가를 확보하거나, 인프라를 깔거나.
오른쪽 아래 (Impact 低, Feasibility 高): Fill-in. 쉽지만 임팩트가 작다. 팀의 학습용으로 쓸 수 있다. 그러나 이것만 하면 안 된다. "쉬운 것만 한다"는 비판을 받게 된다.
왼쪽 아래 (Impact 低, Feasibility 低): 하지 않는다. 시간 낭비다.
이 매트릭스에서 핵심은 Impact를 어떻게 정의하는가다. 매출 증가인가, 비용 절감인가, 고객 만족도 향상인가, 직원 생산성 향상인가. 조직마다 다르다. 그리고 같은 조직 안에서도 시점에 따라 다르다.
한 가지 실용적인 방법을 제안한다. Impact를 정할 때 "이 과제가 성공하면 경영 회의에서 보고할 만한가?"를 기준으로 삼는 것이다. 이 질문에 "그렇다"고 답할 수 있으면 Impact가 충분한 것이다. "글쎄"이면 부족한 것이다. 단순하지만, 놀랍도록 정확한 필터다.
Feasibility는 4D Ready 점수로 판단한다. 네 가지 D가 모두 초록불이면 Feasibility가 높다. 하나라도 빨간불이면 낮다. 노란불이 많으면 중간이다.
20.6 첫 과제 선택의 진짜 의미
여기까지 읽으면 과제를 고르는 기술적 방법은 충분히 갖춘 것이다. 그러나 한 가지 더 말해야 할 것이 있다. 첫 과제의 의미다.
첫 과제는 단순한 실험이 아니다. 조직 전체의 학습 장치다.
좋은 첫 과제는 세 가지를 동시에 한다.
첫째, 성공 경험을 만든다. 조직이 "우리도 할 수 있다"는 자신감을 가진다. 이 자신감이 다음 과제의 추진력이 된다. 실패하면 반대다. "역시 안 된다"는 학습된 무력감이 퍼진다. 한번 퍼지면 2~3년은 회복이 어렵다.
둘째, 기술과 프로세스를 학습한다. 첫 과제를 하면서 팀은 LLM의 특성을 배우고, 프롬프트 엔지니어링을 익히고, 데이터 파이프라인을 만들고, 평가 체계를 세운다. 이 학습이 다음 과제에서 재활용된다. 그래서 첫 과제는 기술적으로도 "표준이 될 만한" 과제여야 한다. 너무 특수한 과제는 학습의 전이가 어렵다.
셋째, 조직의 신뢰를 쌓는다. 현업이 AI를 믿게 된다. 경영진이 투자를 계속하게 된다. IT 부서의 역량이 인정받는다. 이 신뢰가 없으면 두 번째 과제는 시작조차 어렵다.
내가 컨설팅에서 본 가장 좋은 첫 과제 사례를 하나 이야기하겠다. 한 중견 화학회사에서 있었던 일이다. 이 회사는 매일 아침 전날의 생산 데이터를 정리해 보고서를 만들었다. 현장 담당자가 엑셀로 데이터를 모으고, 팀장이 검토하고, 공장장에게 보고한다. 매일 2시간이 걸리는 일이었다.
이 과제를 RAPIDS로 평가하면 어떤가. 반복적이다(매일). 자동화 가능하다(데이터가 시스템에 있다). 예측 가능하다(보고서 형식이 정해져 있다). 데이터가 풍부하다(MES에 쌓여 있다). 의사결정이 있다(이상치 발견 시 대응이 필요하다). 확장 가능하다(다른 공장에도 적용 가능하다). 6개 기준 모두 높은 점수다.
4D Ready도 확인했다. 데이터는 MES에 API로 접근 가능. 도메인 전문가는 현장 팀장이 주 3일 참여 가능. 공장장이 직접 스폰서. 운영 인프라는 기존 서버 활용 가능. 네 가지 D 모두 초록불이었다.
6주 만에 Agent가 만들어졌다. 매일 아침 6시에 자동으로 보고서가 생성된다. 이상치가 있으면 빨간색으로 표시된다. 현장 담당자의 2시간이 10분으로 줄었다. 공장장은 아침 7시에 커피를 마시며 보고서를 본다. 만족도가 높았다.
이 작은 성공이 무엇을 만들었는가. 6개월 뒤, 이 회사는 5개의 추가 Agent 프로젝트를 진행했다. 현업 부서에서 먼저 요청이 왔다. "우리 부서도 만들어달라." 이것이 첫 과제의 힘이다.
반대 사례도 있다. 다른 회사에서 첫 과제로 "전사 지식 관리 시스템"을 선택했다. RAPIDS 점수는 나쁘지 않았다. 그러나 4D Ready에서 문제가 있었다. 데이터가 부서마다 다른 형식으로 흩어져 있었고, 도메인 전문가가 너무 많이 필요했고, 의사결정자의 관심이 분산되었다. 1년이 지나도 뚜렷한 성과가 없었다. 팀은 지쳤고, 경영진은 실망했다.
같은 기술, 같은 수준의 팀. 과제 선택이 달랐을 뿐이다.
잠시 멈추고 생각해보자
당신의 조직이 AI Agent의 첫 과제를 고른다면, 그 과제가 성공했을 때 누가 가장 기뻐하겠는가? 그 사람이 기뻐하는 것이 조직 전체에 어떤 파급 효과를 만들겠는가?
20.7 좋은 과제와 나쁜 과제 — 실전 가이드
지금까지의 프레임워크를 종합해서, 좋은 과제와 나쁜 과제의 특징을 정리한다.
좋은 첫 과제의 특징:
하나. 범위가 명확하다. "이 데이터로, 이 결과를, 이 사용자에게." 한 문장으로 정의할 수 있다.
둘. 성공 기준이 숫자로 측정 가능하다. "처리 시간 50% 단축", "정확도 90% 이상", "월 100시간 절감". 모호한 "업무 효율화"가 아니다.
셋. 3개월 이내에 첫 결과를 볼 수 있다. 1년짜리 프로젝트는 첫 과제가 아니다. 긴 프로젝트는 중간에 무엇이 바뀔지 모른다. 경영진의 관심도 3개월이 한계다.
넷. 실패해도 큰 피해가 없다. 좋은 첫 과제는 Agent가 틀려도 사람이 잡아낼 수 있는 구조다. Human-in-the-loop. 첫 과제에서 사람을 완전히 빼면 안 된다.
다섯. 현업이 원하는 과제다. IT가 하고 싶은 과제가 아니라, 현업이 매일 불편해하는 과제다.
나쁜 첫 과제의 특징:
하나. "AI로 무엇이든 해보자"에서 시작한 과제. 목적이 없다.
둘. 경영진이 외부에서 보고 "우리도 해보라"고 한 과제. 자기 조직의 맥락이 빠져 있다.
셋. 데이터가 아직 없는데 "만들면서 모으면 되지"라고 하는 과제. 안 된다.
넷. 담당자가 바뀌어도 괜찮다고 생각하는 과제. 도메인 전문가 없이는 괜찮은 Agent가 나오지 않는다.
다섯. 성공해도 누가 좋아하는지 불분명한 과제. 사용자가 없는 제품을 만드는 것이다.
이 기준이 절대적인 것은 아니다. 조직마다 상황이 다르다. 그러나 방향은 분명하다. 좋은 과제는 찾는 것이지 만드는 것이 아니다. 이미 현장에서 사람들이 고통받고 있는 곳에 있다. 그 고통을 잘 듣는 것이 과제 발굴의 시작이다.
핵심 정리
Agent 프로젝트의 성패는 기술이 아니라 과제에서 갈린다. 좋은 과제를 찾는 것이 가장 어렵고 가장 중요한 일이다.
RAPIDS 프레임워크는 과제의 품질을 평가하는 여섯 기준이다. Repetitive(반복적), Automatable(자동화 가능), Predictable(예측 가능), Information-rich(데이터 풍부), Decision-heavy(의사결정 빈번), Scalable(확장 가능). 이 여섯 기준의 점수가 높을수록 좋은 과제다.
MECE 매트릭스는 과제를 빠짐없이 발굴하는 도구다. 업무 프로세스 단계와 업무 유형을 교차해 빈 곳 없이 훑는다. 빈 칸이 있다는 것을 아는 것 자체가 가치다.
4D Ready는 실행 가능성의 체크리스트다. Data Ready, Domain Ready, Decision Ready, Deployment Ready. 네 가지 중 하나라도 빨간불이면 시작하기 전에 해결해야 한다.
Impact × Feasibility 매트릭스는 우선순위를 정하는 도구다. Quick Win 영역에 있는 과제를 첫 과제로 삼는다.
가장 중요한 것은 첫 과제의 의미다. 첫 과제는 실험이 아니라 학습 장치다. 성공 경험, 기술 학습, 조직 신뢰를 동시에 만들어야 한다. 이 세 가지가 다음 과제의 추진력이 된다.
반드시 답해봐야 할 질문 5가지
질문 1. 당신의 조직에서 매일 반복되지만, 아무도 개선하려 하지 않는 업무는 무엇인가? 그 업무의 RAPIDS 점수는 몇 점인가?
질문 2. MECE 매트릭스를 직접 그려보라. 가로축에 핵심 프로세스 5단계, 세로축에 업무 유형 5가지. 가장 많은 과제가 몰리는 칸은 어디인가? 비어 있는 칸은 어디인가?
질문 3. 4D Ready 중에서 당신의 조직이 가장 약한 D는 무엇인가? Data인가, Domain인가, Decision인가, Deployment인가? 그것을 해결하려면 무엇이 필요한가?
질문 4. 만약 당신이 첫 과제의 결과를 경영 회의에서 3분간 보고한다면, 무엇을 보여주겠는가? 그 3분 안에 "다음 과제도 하겠습니다"라는 승인을 받을 수 있겠는가?
질문 5. 당신의 조직에서 과거에 실패한 IT 프로젝트가 있다면, 그 프로젝트는 RAPIDS와 4D Ready 중 어디에서 문제가 있었는가? 같은 실수를 반복하지 않으려면 무엇을 바꿔야 하는가?
더 깊이 탐구하기
앤드루 응(Andrew Ng)의 「AI Transformation Playbook」 (2018). AI 프로젝트의 과제 선정과 조직 전환에 대한 실용 가이드. 짧지만 핵심이 있다.
바바라 민토, 「논리의 기술(The Minto Pyramid Principle)」 (1987). MECE 원칙의 원전. 과제 분류뿐 아니라 사고의 구조화에 필수적인 책이다.
맥킨지 디지털, 「The State of AI in 2025」 보고서. 기업 AI 도입의 성공과 실패 패턴을 데이터로 정리한 연례 보고서.
토마스 데이븐포트, 「AI Advantage」 (2018). 기업의 AI 과제 선정에서 Quick Win 전략과 장기 전략의 균형을 다룬 책.
나의 시스템 Composite AI Framework 백서 (2025). RAPIDS와 4D Ready를 포함한 과제 발굴 방법론의 실무 적용 사례.
다음 장에서는 과제가 정해진 뒤의 이야기다. 선택한 과제를 어떻게 Agent 아키텍처로 번역하는가. 9-node GoT(Graph of Thought) 아키텍처의 설계 원리와 실전 적용을 본다. 과제를 골랐다면 이제 만들 차례다.