AI는 환각을 일으킨 것이 아니었습니다. 우리의 아키텍처가 문제였습니다.
요약
AI 환각 현상의 근본 원인이 모델 자체보다 부적절한 시스템 아키텍처에 있음을 지적합니다. 모델이 추측하지 않도록 탐색 계층과 구조화된 컨텍스트를 도입하여 LLM을 시스템의 핵심 구성 요소로 통합하는 설계 방식을 제안합니다.
핵심 포인트
- 환각은 모델의 결함보다 아키텍처 설계의 문제일 가능성이 높음
- 프롬프트 엔지니어링만으로는 근본적인 추측 문제를 해결할 수 없음
- LLM이 추측하지 않도록 구조화된 컨텍스트를 제공하는 설계가 필요함
- 좋은 아키텍처는 모델이 내려야 하는 결정의 수를 최소화함
AI는 환각 (Hallucination)을 일으킨 것이 아니었습니다. 우리의 아키텍처가 문제였습니다.
모두가 적절한 모델을 선택하는 것에 대해 이야기합니다.
하지만 그 모델을 둘러싼 적절한 아키텍처 (Architecture)를 구축하는 것에 대해 이야기하는 사람은 거의 없습니다.
저는 그 교훈을 아주 힘들게 배웠습니다.
성공적인 프로토타입 (Prototype)과 함께 시작되었습니다.
우리는 AI 기반의 검증 엔진 (Validation engine)을 구축하고 있었습니다.
첫 번째 개념 증명 (Proof of concept)은 환상적이었습니다.
시스템은 애플리케이션을 분석하고, 검증 시나리오를 생성하며, 이를 자동으로 실행하고, 놀라울 정도로 정확해 보이는 결과물을 만들어냈습니다.
성공적인 데모 이후의 모든 엔지니어와 마찬가지로, 저는 이렇게 생각했습니다:
"생각보다 프로덕션 (Production)에 가까워졌군."
그 후 우리는 그것을 실제 엔터프라이즈 애플리케이션 (Enterprise application)에 연결했습니다.
모든 것이 변했습니다.
모델이 틀린 것이 아니었습니다. 모델은 추측을 하고 있었습니다.
AI가 가정을 하기 시작했습니다.
어떤 가정은 합리적이었습니다.
하지만 대부분은 기술적으로 부정확했습니다.
존재하지 않는 관계를 추론했습니다.
비즈니스 워크플로우 (Business workflows)를 오해했습니다.
잘못된 동작을 확신을 가지고 검증했습니다.
좌절스러운 부분은 무엇이었을까요?
그 응답들 중 어느 것도 명백하게 틀려 보이지 않았다는 점입니다.
그것들은 믿을만해 보였습니다.
그것이 훨씬 더 위험합니다.
우리의 첫 번째 본능은 다른 모든 사람들과 같았습니다.
우리는 프롬프트 (Prompts)를 탓했습니다.
그래서 프롬프트를 개선하기 시작했습니다.
더 상세한 지침
더 많은 예시
더 나은 포맷팅
추가적인 컨텍스트 (Context)
다른 모델들
각각의 개선은 하나의 문제를 해결했습니다.
하지만 각각의 개선은 또 다른 문제를 야기했습니다.
마치 두더지 잡기 게임을 하는 것 같았습니다.
진짜 문제는 프롬프트 엔지니어링 (Prompt engineering)이 아니었습니다.
어느 날 오후, 우리는 프롬프트에 대한 논의를 멈추고 다른 질문을 던졌습니다.
"왜 모델이 우리 시스템이 이미 알고 있는 정보를 추론하도록 강요받고 있는가?"
그 단 하나의 질문이 프로젝트를 바꾸어 놓았습니다.
모델에게 모든 것을 이해하라고 요구하는 대신, 우리는 아키텍처를 재설계했습니다.
애플리케이션이 탐색 (Discovery)을 담당하게 되었습니다.
플랫폼은 검증된 메타데이터 (Metadata)를 수집했습니다.
비즈니스 컨텍스트는 모델에 도달하기 전에 구조화되었습니다.
AI는 더 이상 추측할 필요가 없었기 때문에 추측을 멈추었습니다.
가장 큰 아키텍처적 변화
이전에는:
Application
↓
Large Language Model (대규모 언어 모델)
↓
Automation Engine (자동화 엔진)
이후:
Application (애플리케이션)
↓
Discovery Layer (탐색 계층)
↓
Structured Context (구조화된 컨텍스트)
↓
Large Language Model (대규모 언어 모델)
↓
Validation Engine (검증 엔진)
LLM은 전체 시스템이 아닌 하나의 구성 요소가 되었습니다.
그것이 모든 차이를 만들었습니다.
가장 큰 깨달음
AI 제품을 구축하는 것은 소프트웨어 아키텍처 (Software Architecture)에 대한 저의 사고방식을 바꾸어 놓았습니다.
좋은 아키텍처는 모델이 내려야 하는 결정의 수를 줄여줍니다.
나쁜 아키텍처는 모델에게 누락된 시스템 설계 (System Design)를 보완하도록 요구합니다.
이것들은 완전히 다른 철학입니다.
첫 번째는 신뢰할 수 있는 소프트웨어를 만들어냅니다.
두 번째는 인상적인 데모를 만들어냅니다.
마지막 생각
저는 다음과 같은 질문을 멈췄습니다:
"어떻게 하면 AI를 더 똑똑하게 만들 수 있을까?"
이제 저는 이렇게 묻습니다:
"어떻게 하면 AI가 추측할 필요를 없앨 수 있을까?"
제 경험상, 바로 그 지점에서 프로덕션급 (Production-grade) AI가 실제로 시작됩니다.
만약 여러분이 프로덕션을 위한 AI 시스템을 구축해 보셨다면, 여러분의 경험을 듣고 싶습니다.
모델이 아닌 아키텍처가 진짜 과제라는 것을 어느 시점에 깨달으셨나요?
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기