From Business Problems to AI Solutions: Where Does Transformation Support Fail

1. 문제 정의 (Problem Statement)

• 배경: AI 프로젝트는 기존 IT 프로젝트보다 실패율이 약 2 배 높으며, 그 주요 원인은 비즈니스 이해관계자가 의도한 문제와 데이터 과학 팀이 기술적으로 정의한 솔루션 간의 불일치 (Misalignment) 입니다.
• 핵심 문제: "고객 이탈 감소"나 "부정 거래 탐지"와 같은 비즈니스 문제 (Business Problem, BP) 를 "분류 (Classification)", "회귀 (Regression)", "군집화 (Clustering)" 등의 구체적인 ML 작업 (ML Task) 및 알고리즘 사양으로 전환하는 과정이 여전히 **임의적 (ad hoc)**이고 전문가의 직관에 의존하고 있습니다.
• 전통적 RE 와의 차이: 전통적인 요구사항 공학 (RE) 은 목표에서 요구사항으로의 정제 과정을 다루지만, BP→ML 변환은 비즈니스 언어 (목표, 의사결정) 를 통계적/알고리즘적 언어 (ML 패러다임, 작업 유형) 로 변환하는 **교차 도메인 유도 (Cross-domain derivation)**가 필요하여 기존 방법론으로 해결하기 어렵습니다.
• 정의된 용어:
  • BP (Business Problem): 조직이 해결하려는 측정 가능한 격차 (전략적 목표, 의사결정 필요성, 성능 격차, 제약 조건).
  • MLS (ML Solution Specification): 비즈니스 요구사항과 ML 구현을 연결하는 사양 (ML 패러다임, 작업 유형, 데이터 요구사항, 평가 기준 등).
  • 변환 (Transformation): BP 를 명시적이고 추적 가능한 MLS 로 유도하는 과정.

2. 연구 방법론 (Methodology)

• 연구 설계: 18 개의 기존 접근법 (RE, ML 프로젝트 관리, 자동화 분야) 에 대한 **체계적 내러티브 문헌 고찰 (Structured Narrative Literature Review)**을 수행했습니다.
• 데이터 수집: IEEE Xplore, ACM, Springer 등 5 개 디지털 라이브러리에서 검색하여 129 건의 초기 논문을 수거, 제목/초록 검토 및 전체 텍스트 심사를 거쳐 최종 18 개의 접근법을 선정했습니다.
• 분석 프레임워크:
  • 분류 체계 (Taxonomy): 18 개 접근법을 4 가지 패밀리 (RE4AI, Data-Centric RE, 프로젝트 관리 프로세스, 자동화 지향) 로 분류.
  • 입력/출력 아티팩트 분석: 6 가지 입력 아티팩트 (전략적 목표, 제약 조건 등) 와 6 가지 출력 아티팩트 (데이터 요구사항, 알고리즘 사양 등) 를 분석.
  • 7 단계 변환 프레임워크: BP→MLS 변환을 7 단계 (S1~S7) 로 정의하고 각 접근법의 지원 정도를 평가했습니다.
    • S1: 문제 정의 (Problem Framing)
    • S2: 의사결정/질문 형식화 (Decision/Question Formulation)
    • S3: ML 작업 형식화 (ML Task Formulation) - 핵심 결손 구간
    • S4: 데이터 요구사항 명세
    • S5: 제약 조건 통합
    • S6: 평가 기준 설정
    • S7: 배포 가정
  • 신뢰도: 두 명의 저자가 독립적으로 평가하여 Cohen's kappa(κ=0.83) 로 높은 일치도를 보임.

3. 주요 결과 (Key Results)

• 전반적인 지원 부족: 18 개 접근법 중 어떤 접근법도 7 단계를 모두 체계적으로 지원하지 않았습니다. 모든 접근법이 최소 하나의 단계에서 '최소한 (Minimal)'의 지원만 제공했습니다.
• S2-S3 단절 (The S2-S3 Discontinuity):
  • 비즈니스 목표를 구체적인 ML 작업 (S3) 으로 전환하는 단계에서 지원이 급격히 떨어집니다.
  • S3 (ML 작업 선택) 의 평균 지원 점수는 1.22 (5 점 만점 기준) 로 가장 낮았습니다.
  • 18 개 접근법 중 S3 에 대해 '강력한 (Strong)' 지원을 제공하는 접근법은 0 개였으며, '부분적 (Partial)' 지원만 제공하는 접근법은 4 개 (GR4ML, AI Use Cases, BDDS, SmartML) 뿐이었습니다.
  • 대부분의 접근법은 ML 작업이 이미 정해져 있다고 가정하거나, 데이터 준비 (S4) 로 바로 넘어가는 경향이 있었습니다.
• 패밀리별 특징:
  • RE4AI: 요구사항 조직화에는 강점이 있으나, 비즈니스 목표에서 ML 작업으로의 유도 규칙이 부재합니다.
  • Data-Centric: 데이터 요구사항에 집중하지만, 문제 특성에서 작업을 유도하는 논리가 명시되지 않았습니다.
  • 프로젝트 관리 (CRISP-DM 등): 프로세스 단계는 정의하지만, 각 단계 내 '어떻게' 결정을 내릴지에 대한 구체적인 지침이 없습니다.
  • 자동화 (AutoML 등): 이미 정의된 작업 내 알고리즘 선택은 자동화하지만, 비즈니스 문제에서 작업 유형을 결정하는 단계는 다루지 않습니다.

4. 핵심 기여 (Key Contributions)

A. 분석적 Translation Problem (ATP) 의 정의

저자들은 비즈니스 특성과 ML 형식화 사이의 명시적이고 추적 가능한 매핑 부재를 **"Analytics Translation Problem (ATP)"**으로 정의했습니다.

• 입력: 목표 (O), 제약 (C), 데이터 가용성 (D), 사용자 요구 (R)
• 출력: ML 패러다임 (P), 작업 유형 (T), 알고리즘 제약 (A), 평가 기준 (E)
• 문제: 현재 $f_{ATP}: (O, C, D, R) \rightarrow (P, T, A, E)$를 매핑하는 함수나 체계적 방법이 존재하지 않습니다.

B. 5 가지 연구 권장사항 (Research Recommendations)

ATP 를 해결하기 위해 향후 프레임워크가 제공해야 할 5 가지 구체적인 방향을 제시했습니다.

1. R1: 다중 형식화 탐색 지원 (Multi-Formulation Exploration)
   • 하나의 비즈니스 문제에 대해 여러 ML 작업 (분류 vs 회귀 등) 을 병렬적으로 고려하고 비교할 수 있는 공간을 제공해야 합니다. (예: GR4ML 의 다중 뷰 구조 확장)
2. R2: 작업 유도 지침 제공 (Task Derivation Guidance)
   • 비즈니스 질문을 ML 작업 유형으로 매핑하는 명시적인 규칙 (구조적 규칙 및 데이터 규칙) 을 제공해야 합니다. (예: "레이블이 없으면 지도 학습 제외"와 같은 필터링 로직)
3. R3: 제약 조건 기반 알고리즘 필터링 (Constraint-Algorithm Filtering)
   • 설명 가능성, 공정성, 지연 시간 등의 제약 조건이 알고리즘 선택을 어떻게 제한하는지 사전에 필터링할 수 있는 매핑 행렬을 제공해야 합니다.
4. R4: 확률적 추적성 구현 (Probabilistic Traceability)
   • ML 모델의 성능이 불확실성을 내포하므로, 비즈니스 목표와 ML 결정 간의 연결을 이진 (성공/실패) 이 아닌 예상 성능 범위와 신뢰도로 추적해야 합니다.
5. R5: 데이터 기반 수정 경로 정의 (Data-Triggered Revision Paths)
   • 데이터 탐색 결과 (레이블 부족, 불균형 등) 가 상류의 결정 (목표, 작업 유형 등) 을 무효화할 경우, 이를 수정하기 위한 명시적인 트리거와 경로를 정의해야 합니다.

5. 의의 및 시사점 (Significance)

• 요구사항 공학 (RE) 의 확장: AI 시스템 개발에서 ML 작업 결정 단계를 명시적인 요구사항 활동으로 격상시켜야 함을 주장합니다. 이는 전통적인 RE 개념 (목표 분해, 추적성) 을 비즈니스-ML 경계에 맞게 재적용해야 함을 의미합니다.
• 실무적 가이드: 실무자들은 단일 방법론에 의존하기보다, 다양한 패밀리의 아티팩트 (예: BDDS 의 근본 원인 분석 + RE4HCAI 의 제약 분류) 를 결합하여 맹점을 줄여야 합니다.
• 미래 연구 방향: 본 논문은 AI 프로젝트의 초기 단계에서 발생하는 '직관 의존성'을 '원칙적이고 추적 가능한 정제 메커니즘'으로 대체하기 위한 연구 의제 (Research Agenda) 를 제시합니다. 이는 생성형 AI 도구가 비즈니스-기술 변환을 지원하기 위한 전제 조건이기도 합니다.

결론적으로, 이 논문은 AI 프로젝트 실패의 근본 원인 중 하나인 "비즈니스 문제에서 ML 작업으로의 전환 부재"를 체계적으로 분석하고, 이를 해결하기 위한 구체적인 방법론적 프레임워크와 연구 방향을 제시했다는 점에서 중요한 의의를 가집니다.