10장: AI 엔지니어링 아키텍처와 사용자 피드백

마지막 장은 1장부터 9장까지 다뤄온 모든 요소들이 실제 제품 환경에서 어떻게 하나의 시스템으로 결합되는지 보여준다. 컨텍스트 보강, 가드레일, 라우터, 캐시, 에이전트, 모니터링이 단계별로 추가되며, 마지막에는 운영 데이터로 다시 시스템을 개선하는 사용자 피드백 루프가 닫힌다.

AI 엔지니어링 아키텍처

가장 단순한 AI 애플리케이션 구조는 사용자 질의 → 모델 API → 응답 의 3단 구조다. 그러나 실제로 이 구조만으로 제품을 운영하면 보안, 비용, 지연 시간, 품질 어느 하나도 보장되지 않는다. 책에서는 이 단순 구조에 다섯 단계를 점진적으로 덧붙여 운영 가능한 아키텍처에 도달하는 흐름으로 설명한다.

여기에 단계별로 컴포넌트가 추가된다.

1단계: 컨텍스트 보강

컨텍스트 구성은 파운데이션 모델 시대의 특성 공학(Feature Engineering) 에 해당한다. 모델은 학습 시점 이후의 사실, 사용자 개인 정보, 사내 문서 등을 알지 못하므로, 응답에 필요한 정보를 그때그때 프롬프트로 공급해야 한다.

대표적인 두 패턴은 6장에서 다룬 RAG와 에이전트의 도구 호출이다.

이 단계의 핵심은 "모델을 더 똑똑하게 만들기"보다 모델이 답하는 데 필요한 컨텍스트를 빠짐없이 모아 주는 것이다.

2단계: 가드레일 도입하기

가드레일은 위험을 줄이고 사용자와 서비스 제공자 모두를 보호하는 장치다. 입력 측과 출력 측 양쪽에 배치한다.

대표적인 가드레일 솔루션은 다음과 같다.

• 메타 Purple Llama — 책임 있는 LLM 사용을 위한 오픈 도구 모음
• NVIDIA NeMo Guardrails — 대화 흐름과 정책을 DSL로 정의
• Azure PyRIT, AI Content Filter
• Perspective API — 독성 점수 측정
• OpenAI Moderation API

가드레일에 사용되는 스코어러(Scorer) 는 보통 생성 모델보다 작고 빠르지만 그 자체가 AI 모델인 경우가 많다. 이 때문에 책에서는 스코어러를 모델 API "아래" 계층에 배치하는 것을 권장한다. 즉, 메인 모델보다 가벼운 분류·검출 모델을 게이트로 두어 비용과 지연을 동시에 통제한다.

3단계: 모델 라우터와 게이트웨이

서비스가 커지면 "모든 질의를 GPT-4 한 모델에 보낸다" 식의 단일 모델 전략은 비용·성능 양쪽에서 깨진다.

라우터

질의의 종류에 따라 서로 다른 모델·솔루션으로 보내는 컴포넌트다.

• 장점 1. 성능 — 특정 도메인 질의는 범용 대형 모델보다 특화 소형 모델이 더 정확할 수 있다.
• 장점 2. 비용 — 단순 분류·인사·FAQ 같은 질의는 저렴한 모델로, 추론·코드 생성 같은 어려운 질의만 비싼 모델로 보낸다.

라우터는 의도 분류기(Intent Classifier)와 거의 같은 역할을 하며, 다음 행동 예측기(Next Action Predictor)에도 활용된다. 라우터 자체는 빠르고 저렴해야 한다 — 그렇지 않으면 라우팅이 또 다른 병목이 된다.

게이트웨이

모델 게이트웨이는 조직이 다양한 모델 제공자와 안전하게 상호작용하도록 해 주는 중간 계층이다.

대표 솔루션은 Portkey AI Gateway, MLflow AI Gateway, Wealthsimple LLM Gateway, TrueFoundry, Kong, Cloudflare AI Gateway 등이 있다. 라우터와 게이트웨이는 종종 같은 계층에 묶여 운영된다.

4단계: 캐시로 지연 시간 줄이기

추론 비용과 지연을 가장 직접적으로 낮추는 방법은 이미 생성한 응답을 다시 사용하는 것이다. 9장의 프롬프트(프리픽스) 캐싱이 모델 내부 KV 캐시 재사용이라면, 이 단계의 캐싱은 애플리케이션 수준의 응답 캐싱이다.

완전 일치 캐싱은 보통 인메모리 저장소(Redis 등) 와 표준 제거 정책으로 구현한다.

• LRU (Least Recently Used) — 가장 오랫동안 안 쓰인 항목 제거
• LFU (Least Frequently Used) — 가장 적게 쓰인 항목 제거
• FIFO — 들어온 순서대로 제거

시맨틱 캐싱은 들어오는 질의를 임베딩으로 변환한 뒤 벡터 DB에서 가장 가까운 캐시 항목을 찾는다. 임계값 설정이 핵심이며, 너무 느슨하면 잘못된 응답이 재사용되고 너무 엄격하면 캐시가 무용지물이 된다.

5단계: 에이전트 패턴 추가

6장에서 다룬 에이전트 패턴이 마지막으로 결합된다. 위의 1~4단계가 전부 갖춰져 있어야 에이전트가 안정적으로 동작한다 — 도구 호출(컨텍스트 보강), 안전한 입출력(가드레일), 모델 선택(라우터), 반복 호출 비용 절감(캐시) 모두가 에이전트 루프 안에서 매번 사용되기 때문이다.

모니터링과 관찰 가능성

관찰 가능성은 사후에 붙이는 기능이 아니라 제품 설계 단계부터 들어가야 하는 핵심 요소다. AI 시스템은 결정성이 낮기 때문에 일반 소프트웨어보다 더 촘촘한 관측이 필요하다.

운영 지표

CFR을 측정조차 못하고 있다면, 그 자체가 플랫폼을 더 관찰 가능하도록 재설계해야 한다는 신호다.

비즈니스/비용 지표

• DAU(일일 활성 사용자), 세션 지속 시간, 구독자 수 등 일반적인 제품 지표
• TPS(초당 토큰 수), RPS, 평균 토큰/요청 등 비용·용량 지표

로그와 트레이스

LLM 시스템에서 로그는 추가만 가능한 이벤트 기록(Append-only) 으로 설계한다. 한 번 기록한 요청·응답·메타데이터는 수정하지 않는다.

기록해야 할 항목은 다음과 같다.

• 모델 API 엔드포인트, 모델 이름, 버전
• 샘플링 설정(temperature, top-p, max tokens)
• 프롬프트 템플릿과 실제 렌더링된 프롬프트
• 입력·출력 토큰 수, 지연 시간 분해(TTFT, TPOT)
• 가드레일 결과, 라우팅 결정, 캐시 히트 여부

드리프트 감지

시스템이 "어제와 같은데 오늘부터 이상하다"라고 느껴지는 가장 흔한 원인은 드리프트다.

특히 마지막 케이스("같은 모델 이름인데 출력이 바뀌는 문제")는 클로즈드 모델을 사용할 때 피하기 어렵기 때문에, 회귀 테스트 셋을 주기적으로 돌려 출력 분포를 추적하는 것이 사실상의 표준 대응이다.

AI 파이프라인 오케스트레이션

오케스트레이터는 위의 모든 컴포넌트(게이트웨이, 라우터, 가드레일, RAG, 에이전트, 캐시)를 구성 요소 정의와 체이닝 두 단계로 묶어 준다.

• 구성 요소 정의 — 각 단계의 입출력 스키마, 모델 설정, 도구 명세 선언
• 체이닝 — 단계들을 순차/분기/반복으로 연결

대표 오케스트레이션 도구로는 LangChain, LlamaIndex, Flowise, Langflow, Haystack 등이 있다. 도구 선택보다 중요한 것은 체인 안의 각 단계가 독립적으로 평가·교체 가능해야 한다는 원칙이다. 그래야 4장에서 다룬 평가 파이프라인을 그대로 적용할 수 있다.

전체 아키텍처 한 장 요약

사용자 피드백

아키텍처가 완성되었다면, 그 위에서 발생하는 사용자 신호를 다시 모델·프롬프트·라우터 개선에 사용하는 것이 마지막 퍼즐이다. 피드백은 평가 데이터, 파인튜닝 데이터, 라우팅 규칙, 가드레일 정책 모두의 원료가 된다.

명시적 피드백과 암시적 피드백

전통적으로 피드백은 두 종류로 나뉜다.

대화형 인터페이스(LLM 챗봇)에서는 두 신호의 경계가 더 흐려진다. 사용자가 "아니 그게 아니고…"라고 다시 물으면, 이는 명시적인 부정 피드백이면서 동시에 대화 흐름 안에 자연스럽게 섞여 있는 암시적 신호이기도 하다.

대화형 피드백 추출

대화형 피드백은 사용자 메시지의 내용과 의사소통 패턴 양쪽에서 추출할 수 있다.

이런 신호는 일상 대화 속에 자연스럽게 섞여 있어 추출이 까다롭다. 실무에서는 다음 두 가지 방식이 함께 쓰인다.

1. 분류 모델 — 사용자 메시지를 "긍정/부정/중립", "정정 요청/추가 질의/만족" 등으로 분류
2. 세션 단위 휴리스틱 — 재질의 횟수, 대화 길이, 마지막 응답 후 행동(복사/이탈/재시도)을 합쳐서 점수화

추출한 신호는 다음에 다시 투입된다.

• 평가 데이터 — 회귀 테스트 셋에 부정 사례 추가
• 라우터 학습 — "이 유형의 질의는 모델 B로 보냈을 때 부정 피드백이 많더라"
• 프롬프트 개선 — 반복적으로 실패하는 패턴을 시스템 프롬프트로 흡수
• 파인튜닝 / 선호 학습 — 7장의 RLHF/DPO 데이터의 원천

이 루프가 닫혀야 비로소 AI 시스템은 운영 데이터에서 스스로 학습하는 제품이 된다.

피드백 시스템을 설계할 때 흔한 함정

책의 본문과 별개로, 실무에서 자주 부딪히는 함정들이 있다.

• 부정 피드백만 학습 — 좋아요/싫어요 중 싫어요만 모으면, "나쁘지 않은 응답"의 분포가 사라진다. 균형 표본이 필요하다.
• 피드백 = 정답이라는 착각 — 사용자가 누른 좋아요는 "그 응답이 사실"이라는 뜻이 아니라 "그 응답이 도움이 됐다"는 뜻이다. 사실성 평가는 별도 트랙에서 해야 한다.
• 로그가 없어서 라벨링도 못함 — 모니터링 단계에서 프롬프트·응답·설정을 함께 기록하지 않으면, 나중에 피드백을 받아도 어떤 컨텍스트에 대한 평가인지 복원하지 못한다. 관찰 가능성이 곧 피드백 인프라다.

정리

10장은 이 책 전체의 콜백이다. 컨텍스트 보강(RAG·에이전트, 5·6장), 가드레일(평가, 3·4장), 라우터·캐시(추론 최적화, 9장), 파인튜닝·데이터셋(7·8장)이 한 다이어그램 안에서 합류한다.

그리고 그 위에 모니터링과 사용자 피드백이 얹혀, 시스템이 한 번 만들어지고 끝나는 것이 아니라 운영하면서 끊임없이 다시 학습되는 제품으로 닫힌다. 결국 AI 엔지니어링은 "한 번 잘 만든 모델"이 아니라 "잘 측정하고, 잘 갈아끼울 수 있는 시스템"을 만드는 일이라는 것이 이 책의 마지막 메시지로 읽힌다.

이 시리즈를 마무리하며 가장 와닿았던 점은, 이 책이 끝까지 한 가지 태도를 유지한다는 사실이다 — "평가 가능하게 만들고, 관찰 가능하게 만들고, 교체 가능하게 만들어라." 모델은 바뀌고, 가격도 바뀌고, 사용자 패턴도 바뀐다. 그 변화에 끌려가지 않으려면 시스템의 모든 단계가 측정·교체 가능해야 한다는 것. 이 한 줄이 책 전체를 관통한다.