원문은 mauriciojuba.com에서 처음 게시되었습니다.

ARTICLE · GENAI · ENTERPRISE

기업 팀을 위한 실용적인 GenAI (생성형 AI) 아이디어 구상 파이프라인.

GenAI (생성형 AI)는 빠르게 업계가 가장 선호하는 망치가 되었고, 갑자기 모든 것이 못처럼 보이기 시작했습니다. 기업 환경에서 이는 예측 가능한 혼란, 즉 비대해진 백로그 (backlog), 모호한 "모든 곳에 AI를"이라는 명령, 그리고 주로 과장된 홍보를 정당화하기 위해 존재하는 솔루션들로 이어집니다.

제가 대기업 내부의 GenAI 이니셔티브에 합류했을 때, 초기 방향은 제품 전략이 아니었습니다. 그것은 단 한 문장이었습니다: "GenAI가 적용될 수 있는 회사 전반의 유스케이스 (use cases)를 찾아라." 이는 주도적으로 들립니다. 하지만 실제로는 모호함, 공포, 그리고 소음을 만들어냅니다.

그래서 우리는 브레인스토밍보다 훨씬 더 가치 있는 일을 수행하는 파이프라인을 구축했습니다. 그것은 투자를 하기 전에 명확성, 타당성, 그리고 책임 소재를 강제하는 것입니다. 그 파이프라인이 바로 MAGIC 프레임워크가 되었습니다.

MAP (매핑) · ANALYZE (분석) · GRADE (등급 산정) · INPUT (입력) · COMMIT (실행)

기업에서 GenAI 아이디어 구상이 실패하는 이유

figure

프레임워크를 도입하기 전, 이해관계자들은 보통 두 가지 극단으로 나뉘었습니다:

두려움 (FEAR)

저항 (RESISTANCE)

"내 분야에 AI가 도입된다는 것은 일자리 위험처럼 들린다."

• 정보 독점
• 방어적 태도
• 정치적 마찰
• 협업 지연

과장 (HYPE)

과신 (OVERCONFIDENCE)

"GenAI는 모든 것을 해결할 수 있다."

• 문제보다 앞선 솔루션
• 워크플로우 (workflow) 현실 무시
• 비용 인식 부족
• 데이터 제약 사항 무시

게다가, 제안된 많은 "GenAI 유스케이스 (use cases)"는 GenAI가 전혀 필요하지 않은 것들이었습니다. 자동화 (Automation), 프로세스 재설계 (process redesign), 또는 더 나은 정보 아키텍처 (information architecture)가 그중 80%를 더 빠르고, 저렴하며, 안전하게 해결할 수 있었습니다. 그리고 우리가 무시할 수 없었던 제약 사항이 있었습니다: 토큰 비용 (token cost) 때문에 무분별한 실험은 대규모로 진행할 경우 비용이 많이 들었습니다.

전통적인 아이디어 구상 (ideation) 방식만으로는 충분하지 않았습니다. 우리는 불확실성, 리스크, 그리고 데이터의 현실을 고려하여 설계된 파이프라인이 필요했습니다.

Map

figure

GenAI가 중요하게 작용할 수 있는 지점 식별

브레인스토밍이 아닌 구조화된 발견 (Structured discovery)입니다. 업무가 실제로 어디에서 무너지나요? 어떤 팀이 워크플로우 (workflow)를 소유하고 있나요? 담당자 (POC)와 의사 결정권자는 누구인가요? 요청 뒤에 숨겨진 실제 수행해야 할 과업 (job-to-be-done)은 무엇인가요?

결과물 (OUTPUT)

• → 맥락을 포함한 하나의 문제 정의 (problem statement)

• → 하나의 주요 사용자 그룹

• → 고통(pain)이 발생하는 하나의 워크플로우 순간

• → 이해관계자(stakeholders) 및 담당자(POC) 목록

이를 매핑할 수 없다면, 그것은 유스케이스 (use case)가 아니라 단순한 제안에 불과합니다.

지원 에이전트는 5개의 시스템을 통해 하루 300개 이상의 티켓을 처리합니다.

• ·무슨 일이 일어나고 있는가?

• ·그것이 왜 중요한가?

• ·조직 내 어디에 위치하는가?

구조화된 정보 누락으로 인한 케이스 거부.

• ·어떤 이벤트가 마찰을 일으키는가?

• ·언제 업무 중단이 발생하는가?

Tier 1 지원 에이전트.

• ·누가 고통을 겪는가?

• ·그들이 달성하려는 것은 무엇인가?

높은 인지 부하 (cognitive load) + 반복적인 수동 요약 작업.

• ·정확히 어떤 단계에서 문제가 발생하는가?

• ·현재는 어떻게 진행되는가?

도구 간 복사 및 붙여넣기 + 수동 태깅 (manual tagging).

• ·임시 방편 (workaround)은 무엇인가?

지원 운영 리드 (Support Ops Lead) · Salesforce 관리자 · IT 보안.

• ·워크플로우 소유자

• ·담당자 (POC)

• ·의사 결정권자

• ·데이터 소유자

Analyze

figure

환상이 아닌 워크플로우를 이해하기

GenAI의 열풍이 현실과 만나는 지점: 인터뷰와 쉐도잉 (shadowing), 단계별 워크플로우 매핑 (workflow mapping), 그리고 마찰 (friction), 낭비 (waste), 의사결정 지점 (decision points)을 찾아내는 과정입니다. "이 도구가 마음에 들지 않는다"와 "이 단계는 구조적으로 잘못되었다"를 구분하십시오.

OUTPUT

• → 워크플로우 맵 (as-is)

• → 단계별로 태깅된 페인 포인트 (Pain points)

• → 성공의 모습에 대한 명확한 정의

대부분의 "GenAI 요청"에는 더 단순한 진실이 숨겨져 있습니다: 프로세스가 불분명한 것이지, 지능이 낮은 것이 아닙니다.

• INTAKE (접수): 내부 도구를 통해 들어온 요청 생성. DECISION NODE (의사결정 노드): 다중 접수 경로, 일관성 없는 필드.

• CASE CREATION (사례 생성): 에이전트가 수동으로 요청 구조화. FRICTION (마찰): 구조화된 정보 누락. WASTE (낭비): 시스템 간의 복사 및 붙여넣기.

• CONTEXT GATHERING (컨텍스트 수집): 에이전트가 지원 데이터를 위해 3개 이상의 시스템 확인. FRICTION (마찰): 높은 인지 부하 (cognitive load). WASTE (낭비): 반복적인 수동 요약.

• VALIDATION (검증): 관리자가 요청 검토. FRICTION (마찰): 불완전한 데이터로 인한 사례 거절. DECISION NODE (의사결정 노드): 주관적인 승인 기준.

• ESCALATION (에스컬레이션): 요청이 전문 팀으로 전달됨. WASTE (낭비): 이미 알고 있는 정보의 재입력.

• DELIVERY (전달): 최종 결과물이 최종 사용자에게 전달됨. FRICTION (마찰): 예측 불가능한 처리 시간.

Grade

figure

데이터 준비성 (data readiness) + 리스크 및 가드레일 (risk & guardrails)

대부분의 팀이 건너뛰는 단계이며, 대부분의 GenAI 이니셔티브가 나중에 실패하는 이유입니다. 우리가 이것을 할 수 있는가 (데이터가 있는가, 접근 가능한가, 구조화되어 있는가, 신뢰할 수 있는가, 소유자는 누구인가, 얼마나 최신인가)? 그리고 우리가 해야 하는가 (무엇이 민감한가, 무엇이 경계 밖으로 절대 나가면 안 되는가, 언제 인간에게 에스컬레이션해야 하는가, 실패 상태는 무엇인가)?

OUTPUT

• → 데이터 준비성 점수 (정성적일지라도)

• → 리스크 분류

• → 토큰 비용 (token cost)에 대한 첫 번째 실질적인 파악

입력 (inputs), 검색 (retrieval), 그리고 출력 제약 조건 (output constraints)을 이해하지 않고서는 비용을 추정할 수 없습니다.

• ·데이터에 프로그래밍 방식으로 접근 가능한가?

• ·API를 사용할 수 있는가?

• ·PDF 또는 이메일에 갇혀 있는가?

• ·데이터의 소유자는 누구인가?

• ·사용 권한을 승인할 수 있는 사람은 누구인가?

• ·오용에 대한 책임은 누구에게 있는가?

• ·데이터가 완전한가?

• ·데이터가 일관적인가?

• ·과거의 노이즈(noise)가 존재하는가?

• ·개인정보(PII)가 포함되어 있는가?

• ·규제 대상 데이터인가?

• ·국가 간 데이터 전송 제한(Cross-border restrictions)이 있는가?

• ·예상 토큰(token) 볼륨은 어느 정도인가?

• ·추론(inference) 빈도는 어떠한가?

• ·긴 문맥(Long-context) 요구 사항이 있는가?

Input (입력)

figure

구축하기 전에 현실을 시뮬레이션하십시오

UI를 테스트하는 것이 아니라, 요청의 명확성을 테스트하는 것입니다. 당신이 요청한 것을 정확히, 그 이상도 그 이하도 아닌 그대로 수행하는 강력하지만 문자 그대로만 실행하는 수행자(executor)를 상상해 보십시오. 지시 사항이 모호하면 결과도 모호합니다. 지금까지 파악한 모든 것을 사용하여, 오직 동작 동사(action verbs)만으로 요청을 구성하십시오.

출력 (OUTPUT)

• →기능(features)이 아닙니다. 인터페이스(interfaces)도 아닙니다. 동작(actions)입니다.

요청에 모호함이 숨겨져 있다면, 출력은 그 모호함을 증폭시킵니다.

Commit (확정)

구축하거나, 아니면 포기하거나

창조는 자동으로 이루어지지 않습니다. 데이터 계층(data layer)이 이를 지원합니까? 누락된 API가 차단 요소(blocker)입니까? 모델 용량(model capacity)이 충분합니까? 토큰 비용이 확장(scale)됩니까? 리스크가 수용 가능한 수준입니까? 결과가 측정 가능합니까?

출력 (OUTPUT)

• →아니오(no)라면 → 구축하지 않습니다. 그 이유를 기록하고 다음으로 넘어갑니다.

• →예(yes)라면 → 의도적으로 MVP(Minimum Viable Product) 범위를 정의합니다.

열정이 아닌, 증거에 기반한 결정입니다.

• ·데이터가 구조화되어 있는가?

• ·필요한 API가 존재하는가?

• ·모델 용량이 충분한가?

• ·예상 월간 토큰 비용

• ·인프라(Infra) 비용

• ·기회 비용

• ·컴플라이언스(Compliance) 노출 위험

• ·에스컬레이션(Escalation) 커버리지

• ·장애 허용치(Failure tolerance)

MAGIC 도입 후 무엇이 변했는가

• → 잘못된 유스케이스(Use cases)는 조기에, 그리고 저렴한 비용으로 퇴출되었습니다.

• → 유용한 유스케이스(Use cases)는 누락된 정보가 빠르게 드러남에 따라 더 빠르게 진행되었습니다.

• → GenAI는 더 이상 "기술적 이니셔티브(Technology initiative)"가 아니라 제품 결정의 규율(Product-decision discipline)이 되었습니다.

이러한 변화는 기업용 GenAI의 진정한 적이라 할 수 있는 비용, 리스크, 그리고 조직적 피로(Organizational fatigue)를 줄여줍니다. MAGIC을 적용하고 싶다면, 세 가지 후보 유스케이스(Use cases)로 시작하여 엔드 투 엔드(End-to-end)로 실행해 보십시오. 만약 최소 하나라도 퇴출시키지 못했다면, 당신의 필터는 너무 느슨한 것입니다.

요약 (TL;DR)

대부분의 GenAI 아이디어 구상(Ideation)이 실패하는 이유는 데이터의 현실과 리스크를 건너뛰기 때문입니다. MAGIC은 투자 전에 명확성을 강제합니다. 즉, "AI를 사용해야 한다"를 "이 문제는 이러한 제약 조건 하에서 AI를 사용할 가치가 있다"로 바꿔줍니다.