프롬프트 엔지니어링에서 시스템 엔지니어링으로 - 엔터프라이즈 AI 시스템에서 실제로 변화하는 것들

초기 AI 프로젝트는 대부분의 시간을 프롬프트 (Prompt)에 할애합니다. 팀들은 다음과 같은 요소들을 실험합니다:

문구 (wording), 역할 지침 (role instructions), 포맷팅 (formatting), 온도 (temperature), 예시 (examples), 출력 구조 (output structure)

솔직히 말해서, 이는 한동안 효과가 있습니다. 프롬프트를 변경하는 것만으로도 결과를 빠르게 개선할 수 있습니다. 하지만 AI 시스템이 엔터프라이즈 (Enterprise) 환경으로 이동하면, 프롬프트 엔지니어링 (Prompt Engineering)은 더 이상 주요 엔지니어링 문제가 아니게 됩니다. 시스템 엔지니어링 (System Engineering)이 그 자리를 대신합니다. 이 전환은 거의 모든 것을 변화시킵니다.

프롬프트 품질이 병목 현상이 되지 않음
소규모 프로젝트에서는 보통 모델 (Model)이 가장 취약한 부분입니다. 엔터프라이즈 시스템에서는 주변 인프라 (Infrastructure)가 훨씬 더 빠르게 병목 현상이 됩니다. 실제 문제는 다음과 같은 것들이 됩니다:

일관되지 않은 검색 (inconsistent retrieval), 워크플로 오케스트레이션 (workflow orchestration), 메모리 동기화 (memory synchronization), 큐 신뢰성 (queue reliability), 지연 시간 급증 (latency spikes), 제공업체 불안정성 (provider instability), 배포 안전성 (deployment safety), 관찰 가능성 (observability), 상태 관리 (state management)

결국 프롬프트는 훨씬 더 큰 운영 시스템 내부의 한 계층일 뿐이며, 대개 가장 취약한 계층도 아니라는 사실을 깨닫게 됩니다.

AI 시스템은 매우 빠르게 상태를 가지게 됨 (Stateful)
대부분의 팀은 자신이 상태가 없는 (Stateless) AI API를 구축하고 있다고 생각합니다. 하지만 그렇지 않습니다. 다음과 같은 요소를 추가하는 순간 여러분은 분산 상태 (Distributed state)를 운영하게 됩니다:

대화 이력 (conversation history), 검색 파이프라인 (retrieval pipelines), 에이전트 워크플로 (agent workflows), 메모리 시스템 (memory systems), 도구 실행 (tool execution), 백그라운드 작업 (background jobs)

이는 즉각적으로 아키텍처 (Architecture) 결정에 영향을 미칩니다. 최근 우리가 겪은 한 가지 문제는 외부에서 보기에는 환각 (Hallucination)처럼 보였습니다. 실제 문제는 다음과 같았습니다: 높은 트래픽 동안 비동기 상태 전파 (Async state propagation)가 지연되어, 두 명의 작업자 (Workers)가 서로 다른 검색 스냅샷을 처리한 것이었습니다. 모델의 출력은 오래된 컨텍스트 (Stale context)를 기반으로 논리적으로는 정확했습니다. 이것은 프롬프트 문제가 아닙니다. 이것은 분산 시스템 엔지니어링 (Distributed systems engineering) 문제입니다.

프롬프트 엔지니어링은 출력을 최적화하고, 시스템 엔지니어링은 안정성을 최적화합니다
이것이 가장 큰 변화입니다. 프롬프트 엔지니어링은 다음과 같이 질문합니다:

'어떻게 응답을 개선할 것인가?', '어떻게 환각을 줄일 것인가?', '어떻게 출력을 구조화할 것인가?', '어떻게 추론 품질을 높일 것인가?'

시스템 엔지니어링은 다음과 같이 질문합니다:

'제공업체(Providers)의 타임아웃(Timeout)이 발생하면 어떻게 되는가?', '배포 중에 무엇이 깨지는가?', '재시도(Retries)가 일관성(Consistency)에 어떤 영향을 미치는가?'

실패한 워크플로(Workflows)를 어떻게 복구하는가? 트래픽 급증(Traffic spikes) 시에는 어떤 일이 발생하는가? 실패를 어떻게 재실행(Replay)하는가? 손상된 상태(Corrupted state)를 어떻게 격리하는가? 두 번째 카테고리가 장기적인 운영 작업의 대부분을 차지합니다.

모델 제공업체는 인프라 의존성(Infrastructure Dependencies)이 됩니다
초기 AI 애플리케이션의 대부분은 제공업체가 일관되게 동작한다고 가정합니다. 하지만 프로덕션 시스템(Production systems)은 그러한 가정에 의존할 수 없습니다. 예상치 못하게 변하는 것들은 다음과 같습니다:

• 출력 형식 (Output formatting)
• 토큰화 (Tokenization)
• 도구 호출 동작 (Tool calling behavior)
• 지연 시간 (Latency)
• 중재 레이어 (Moderation layers)
• 구조화된 출력 동작 (Structured output behavior)
• 컨텍스트 처리 (Context handling)

제공업체 측의 업데이트는 다운스트림 시스템(Downstream systems)을 소리 없이 불안정하게 만들 수 있습니다. 우리는 모델 제공업체를 불안정한 제3자 인프라와 정확히 동일하게 취급하기 시작했습니다. 이는 우리가 다음과 같은 것들을 구축하는 방식을 변화시켰습니다:

• 검증 레이어 (Validation layers)
• 재시도 로직 (Retry logic)
• 응답 정규화 (Response normalization)
• 폴백 시스템 (Fallback systems)
• 오케스트레이션 규칙 (Orchestration rules)

이러한 보호 장치가 없다면, 상류(Upstream)의 작은 변화가 프로덕션 동작으로 직접 유출됩니다.

오케스트레이션 복잡성은 예상보다 빠르게 증가합니다
단순한 AI 흐름은 관리하기 쉽습니다: 입력(Input) → 프롬프트(Prompt) → 응답(Response)
엔터프라이즈 시스템은 좀처럼 단순하게 유지되지 않습니다. 이제 다음과 같은 요소들이 포함됩니다:

• 검색 파이프라인 (Retrieval pipelines)
• 임베딩 생성 (Embedding generation)
• 벡터 검색 (Vector search)
• 메모리 업데이트 (Memory updates)
• 멀티 에이전트 조정 (Multi-agent coordination)
• 비동기 실행 (Async execution)
• 외부 통합 (External integrations)
• 워크플로 분기 (Workflow branching)

결국 오케스트레이션 레이어(Orchestration layer)는 프롬프트 레이어 자체보다 더 커지게 됩니다. 그리고 디버깅(Debugging)은 훨씬 더 어려워집니다. 하나의 실패한 워크플로는 다음과 같은 요소를 포함할 수 있습니다:

• 큐 시스템 (Queue systems)
• 다중 서비스 (Multiple services)
• 검색 실패 (Retrieval failures)
• 오래된 메모리 (Stale memory)
• 제공업체 재시도 (Provider retries)
• 부분 실행 복구 (Partial execution recovery)

그 시점에서는 프롬프트 문구보다 시스템 설계가 더 중요해집니다.

관측 가능성(Observability)이 완전히 변화합니다
전통적인 백엔드 모니터링(Backend monitoring)은 AI 시스템에 충분하지 않습니다. API가 건강하다고 해서 추론(Reasoning)이 건강하다는 뜻은 아닙니다. 다음과 같은 것에 대한 가시성(Visibility)이 필요합니다:

• 프롬프트 (Prompts)
• 검색된 문서 (Retrieval documents)
• 토큰 사용량 (Token usage)
• 오케스트레이션 타이밍 (Orchestration timing)
• 메모리 변이 (Memory mutations)
• 도구 실행 (Tool execution)
• 제공업체 지연 시간 (Provider latency)
• 모델 출력 (Model outputs)

그렇지 않으면 디버깅은 불가능해집니다. 우리가 이제 필수 사항으로 간주하는 한 가지는 다음과 같습니다: 전체 실행 재실행(Full execution replay). 단순한 로그(Logs)만이 아닙니다.

다음 항목들의 완전한 재구성(Complete reconstruction): 입력값(inputs), 검색 상태(retrieval state), 프롬프트 버전(prompt versions), 도구 출력(tool outputs), 모델 응답(model responses), 워크플로 결정(workflow decisions). AI의 실패는 종종 비결정론적(non-deterministic)이기 때문입니다. 재현성(replayability)이 없다면, 디버깅(debugging)은 추측에 불과하게 됩니다.

신뢰성이 지능을 압도하기 시작함
이 지점에서 엔터프라이즈의 우선순위가 급격히 변화합니다. 실험 단계에서 팀은 다음을 최적화합니다:

• 더 똑똑한 출력(smarter outputs)
• 더 나은 추론(better reasoning)
• 더 유능한 에이전트(more capable agents)
• 더 큰 컨텍스트 윈도우(larger context windows)

하지만 프로덕션(production) 환경에서는 우선순위가 바뀝니다:

• 안정적인 실행(stable execution)
• 예측 가능한 동작(predictable behavior)
• 복구 가능성(recoverability)
• 운영 가시성(operational visibility)
• 비용 제어(cost control)
• 배포 안전성(deployment safety)
• 부하 상황에서의 일관성(consistency under load)

예측 가능하게 동작하는 약간 약한 시스템이, 매우 유능하지만 불안정한 시스템보다 대개 더 가치 있습니다.

가장 큰 변화
가장 큰 변화는 엔터프라이즈 AI 시스템이 더 이상 모델의 문제가 아니라는 점을 깨닫는 것입니다. 그것은 인프라(infrastructure)의 문제입니다. 프롬프트는 여전히 중요합니다. 하지만 장기적인 성공은 다음 요소들에 훨씬 더 많이 달려 있습니다:

• 오케스트레이션 신뢰성(orchestration reliability)
• 상태 일관성(state consistency)
• 관측 가능성(observability)
• 운영 도구(operational tooling)
• 배포 안전성(deployment safety)
• 장애 복구(failure recovery)

모델은 움직이는 부품 중 하나일 뿐입니다. 그 주변의 인프라가 시스템이 프로덕션에서 살아남을 수 있을지를 결정합니다.