왜 대부분의 AI 아키텍처 다이어그램은 어려운 부분들을 무시하는가

AI 아키텍처 다이어그램은 인상적으로 보입니다.

사용자가 요청을 보냅니다.

요청은 LLM (Large Language Model)으로 전달됩니다.

아마도 벡터 데이터베이스 (Vector Database)가 있을 수도 있습니다.

아마도 몇 가지 도구 (Tools)가 있을 수도 있습니다.

답변이 돌아옵니다.

모든 것이 슬라이드 안에 깔끔하게 들어맞습니다.

문제는 그 중 어떤 것도 프로덕션 (Production) 환경에서 AI 시스템을 운영하는 데 있어 어려운 부분을 나타내지 않는다는 점입니다.

대부분의 아키텍처 다이어그램은 요청이 어떻게 이동하는지를 보여줍니다.

무언가 잘못되었을 때 어떤 일이 발생하는지를 보여주는 경우는 거의 없습니다.

실제로 대부분의 엔지니어링 시간은 바로 그 지점에서 소요됩니다.

다이어그램은 보통 너무 일찍 끝납니다

대부분의 AI 다이어그램은 모델 응답 단계에서 멈춥니다.

예를 들면 다음과 같습니다:

사용자 → API → 검색 (Retrieval) → LLM → 응답

이것은 개념을 설명하는 데는 유용합니다.

하지만 프로덕션 시스템을 설명하는 데는 유용하지 않습니다.

실제 엔터프라이즈 AI 인프라에는 아키텍처 슬라이드에 거의 등장하지 않는 질문들이 포함됩니다:

검색 (Retrieval)이 실패하면 어떻게 되는가?
모델이 타임아웃 (Timeout)되면 어떻게 되는가?
통합 API (Integration API)를 사용할 수 없으면 어떻게 되는가?
워크플로 (Workflow)가 6시간 동안 실행되면 어떻게 되는가?
출력 스키마 (Output Schema)가 변경되면 어떻게 되는가?
모델이 불완전한 데이터를 반환하면 어떻게 되는가?

이러한 질문들은 대개 모델 통합 자체보다 더 많은 엔지니어링 작업을 만들어냅니다.

아무도 실패 경로를 그리지 않습니다

프로덕션에서 가장 중요한 시스템은 종종 사용자가 결코 보지 못하는 시스템입니다.

예를 들어:

재시도 시스템 (Retry systems)
폴백 워크플로 (Fallback workflows)
데드 레터 큐 (Dead letter queues)
검증 레이어 (Validation layers)
감사 파이프라인 (Audit pipelines)
롤백 메커니즘 (Rollback mechanisms)

이러한 구성 요소들은 아키텍처 다이어그램에 거의 나타나지 않습니다.

하지만 이들이 시스템을 운영 가능한 상태로 유지하는 데 종종 책임을 집니다.

성공적인 요청 경로는 설계하기 쉽습니다.

실패한 요청 경로는 인프라가 테스트를 받는 지점입니다.

프로덕션에서 실패는 예외적인 케이스 (Edge cases)가 아닙니다.

그것은 예상된 동작입니다.

AI 시스템은 대부분의 다이어그램이 보여주는 것보다 더 많은 검증이 필요합니다

일반적인 다이어그램은 다음과 같이 보여줍니다:

데이터 → 모델 → 출력

단순합니다.

현실은 대개 매우 다르게 보입니다.

출력이 비즈니스 시스템에 도달하기 전에, 많은 팀은 다음과 같은 것들을 추가합니다:

스키마 검증 (schema validation)
비즈니스 규칙 검증 (business rule validation)
권한 확인 (permission checks)
신뢰도 평가 (confidence evaluation)
정책 집행 (policy enforcement)
워크플로우 검증 (workflow verification)

이는 추가적인 복잡성을 원해서가 아닙니다.

AI 출력은 확률적 (probabilistic)이기 때문입니다.

전통적인 소프트웨어는 일반적으로 예측 가능한 결과를 생성합니다.

AI 시스템은 생성된 결과가 사용하기에 안전한지 판단하기 위해 추가적인 계층 (layers)이 필요합니다.

이러한 계층들은 아키텍처 슬라이드에 거의 등장하지 않습니다.

실제 복잡성은 컴포넌트 사이에 존재한다

많은 AI 논의는 개별 기술에 집중합니다.

모델 (The model).
벡터 데이터베이스 (The vector database).
프레임워크 (The framework).

어려운 작업은 대개 이러한 컴포넌트들 사이에서 발생합니다.

예를 들어:

검색 (Retrieval)은 다음과 같은 것들을 결정해야 하기 전까지는 단순해 보입니다:

어떤 문서가 자격이 있는가
관련성 (relevance)을 어떻게 측정하는가
중복 콘텐츠를 어떻게 처리하는가
컨텍스트 (context)를 어떻게 조립하는가
메모리 (memory)가 검색과 어떻게 상호작용하는가

마찬가지로, 도구 호출 (tool calling)은 다음과 같은 것들을 관리해야 하기 전까지는 간단해 보입니다:

권한 (permissions)
재시도 (retries)
실행 제한 (execution limits)
타임아웃 처리 (timeout handling)
의존성 실패 (dependency failures)

대부분의 운영 (production) 이슈는 모델 내부가 아니라, 이러한 경계선에서 발생합니다.

관측 가능성 (Observability)은 거의 모든 다이어그램에서 누락되어 있다

AI 아키텍처 슬라이드에 거의 나타나지 않는 한 가지는 관측 가능성 (observability)입니다.

하지만 가장 중요한 운영상의 질문 중 일부는 여기에 달려 있습니다.

다음과 같은 질문들 말입니다:

모델이 왜 이런 결정을 내렸는가?
어떤 문서가 답변에 영향을 주었는가?
어떤 도구가 호출되었는가?
어떤 버전의 프롬프트 (prompt)가 실행되었는가?
어떤 검색 파이프라인 (retrieval pipeline)이 사용되었는가?
왜 어제 토큰 (token) 사용량이 두 배로 늘었는가?

관측 가능성이 없다면, AI 시스템을 진단하는 일은 매우 빠르게 어려워집니다.

하지만 관측 가능성 계층은 다이어그램을 지저분하게 만듭니다.

그래서 종종 생략되곤 합니다.

그 결과, 실제 시스템보다 더 깔끔해 보이는 그림이 만들어집니다.

운영 환경의 AI는 AI라기보다 인프라에 가깝다

충분한 배포를 거치고 나면 한 가지 사실이 분명해집니다.

모델은 아키텍처의 일부분일 뿐이라는 사실입니다.

더 큰 과제는 그 주변의 인프라 (infrastructure)를 구축하는 것입니다.

여기에는 다음이 포함됩니다:

모니터링 (monitoring)
검증 (validation)
버전 관리 (versioning)
보안 (security)
거버넌스 (governance)
장애 처리 (failure handling)
배포 관리 (deployment management)
운영 제어 (operational controls)

이러한 시스템들이 AI가 기업 환경 내에서 지속적으로 실행될 수 있는지 여부를 결정합니다.

첫 번째 슬라이드에 있는 아키텍처 다이어그램 (architecture diagram)이 결정하는 것이 아닙니다.

더 큰 교훈

대부분의 AI 아키텍처 다이어그램은 역량을 설명하기 위해 설계됩니다.

프로덕션 시스템 (production systems)은 현실을 처리하기 위해 설계됩니다.

현실에는 다음이 포함됩니다:

장애 (failures)
재시도 (retries)
잘못된 데이터 (bad data)
통합 문제 (integration issues)
운영 드리프트 (operational drift)
인프라 사고 (infrastructure incidents)

이것들이 바로 엔지니어링 시간을 소비하는 부분들입니다.

그리고 이 부분들은 대개 다이어그램에서 누락되어 있습니다.

AI 시스템에서 가장 쉬운 부분은 해피 패스 (happy path)를 그리는 것입니다.

어려운 부분은 그 이후 매일 그 경로가 작동하도록 유지하는 데 필요한 모든 것입니다.