RAG 운영 Q&A — 비용 · 관측 · 모듈화 · 노코드 거버넌스 21문답

RAG를 만드는 것과 운영하는 것은 다른 문제다. 만들 때는 "어떻게 동작하게 하나"를 묻지만, 운영에서는 "무엇이 비싸고 무엇이 느린지 어떻게 아나", "6개월 뒤에도 고칠 수 있나", **"개발조직이 병목이 되지 않으려면"**을 묻는다.

이 글은 그 질문들을 모았다. 비용 구조와 절감 순서, 관측으로 병목을 가리는 법, 워크플로를 유지보수 가능하게 쪼개는 기준, 그리고 노코드로 확산시키면서 통제를 잃지 않는 설계다. 전체 맥락은 핵심개념 · LangGraph 모듈화 · Dify 노코드 시리즈에 있다.

핵심 수치 정리

운영 판단에 반복해 등장하는 값들이다. 왜 그 값인지를 함께 둔다.

Q. RAG 운영 비용을 어떻게 줄이나

순서가 있다. 출력 단가가 입력의 3배라는 구조에서 출발한다.

전제는 관측이다. 프로젝트별 토큰·비용을 먼저 보고 큰 항목부터 손댄다. 실무에서 비용이 새는 지점은 대개 둘 — 대화 히스토리를 자르지 않고 전부 재전송하는 것과 top-k를 습관적으로 크게 잡는 것이다. 각 레버의 근거는 토큰과 컨텍스트 윈도우에 있다.

Q. 한국어 서비스에서 토큰 비용이 왜 더 나오나

BPE 토크나이저가 영어 코퍼스 중심으로 학습됐기 때문이다. 언어 난이도와 무관하다.

대응이 둘이다. 사용자 입력은 못 바꾸니 시스템 프롬프트를 영어로 쓰고, 토크나이저 세대가 새로운 모델로 간다. 두 번째가 더 크다 — 모델 교체만으로 한국어 토큰 수가 27% 줄었다.

단가를 비교할 때 토큰 수 변화까지 함께 봐야 하는 이유가 여기 있다.

Q. 컨텍스트가 128K면 긴 문서를 다 넣으면 되나

두 가지가 걸린다. 하나는 비대칭이고 하나는 비용이다.

컨텍스트가 128,000이어도 출력은 4,096이 상한인 모델이 있다. 긴 요약은 애초에 한 번에 나오지 않는다.

그리고 넣는 만큼 매 호출 과금되고, 관련 없는 문서가 섞이면 정확도가 오히려 떨어진다. 넓은 윈도우는 여유지 목표가 아니다. 검색으로 걸러 적게 넣는 것이 여전히 정답이다.

Q. 온프레미스 LLM은 언제 도입하나

둘 중 하나가 성립할 때만 본다.

둘 다 아니면 API가 거의 항상 옳다. 여기에 재현성 요건(모델 버전 고정)이 더해지면 로컬이 유리해진다.

손익분기 계산에서 가장 흔한 오류는 운영 인건비 누락이다.

API 월 비용   = (월 입력토큰 ÷ 1M × 입력단가) + (월 출력토큰 ÷ 1M × 출력단가)
로컬 월 비용  = GPU 감가상각 + 전력비 + 운영 인건비 안분

세 번째 항을 빼면 로컬이 항상 이기는 것처럼 보인다. 실제로는 GPU 하드웨어 비용보다 "이걸 관리할 사람"의 비용이 큰 경우가 많다. 그래서 조직 규모가 작을수록, 반출 제약이 없으면 API가 합리적이다. 판단 체크리스트 7항은 로컬 LLM 운영에 정리했다.

Q. 양자화하면 성능은 그대로인가

손실이 있다. "Q4로 줄여도 같다"는 인식은 틀렸다.

Q4_K_M부터 시작하고 품질이 부족하면 Q5_K_M으로, VRAM이 부족하면 Q4_K_S로 움직인다. Q3 이하는 체감 저하가 와서 프로덕션 후보가 되기 어렵다. 등급 전체 비교는 로컬 LLM 운영에 있다.

Q. VRAM은 어떻게 산정하고, 부족하면 실행이 불가능한가

산정은 간이식으로 충분하고, 부족해도 동작은 한다. 문제는 속도다.

총 VRAM (GB) ≈ 파라미터 수(B) × 비트수 ÷ 8 × 1.2 + 컨텍스트 여유분

1.2배는 KV 캐시와 프레임워크 오버헤드다. KV 캐시는 컨텍스트 길이에 비례해 선형 증가하므로 4K로 계산해 두고 32K를 밀어넣으면 예산이 어긋난다.

VRAM이 모자라면 일부 레이어가 CPU로 오프로딩된다. 동작은 하지만 토큰 생성 속도가 수 배에서 수십 배 느려진다. 따라서 "돌아간다"와 "쓸 만하다"는 다르고, 용량 산정은 전 레이어가 GPU에 올라가는 조건을 목표로 잡는다.

Q. 비동기로 바꾸면 얼마나 빨라지나

단일 요청의 지연은 줄지 않는다. 줄어드는 것은 처리량이다.

정확한 표현은 **"I/O 대기가 지배적인 구간을 병렬화해 처리량(throughput)을 높였다"**이다. 문서 5건을 각 2초에 처리하면 순차로는 10초지만 병렬로는 2초 수준으로 수렴한다.

Q. RAG가 느린데 어디를 고칠지 어떻게 판단하나

추측하지 않고 트레이스를 본다. 전형적인 워터폴이 답을 준다.

이 상태에서 벡터 DB를 튜닝하거나 인덱스를 바꾸는 것은 최대 3.6%를 건드리는 일이다. 고칠 곳은 모델 교체, 출력 길이 축소, 스트리밍 도입이다.

관측이 없으면 이 판단을 거꾸로 하기 쉽다. 눈에 보이는 것이 검색 쪽 코드이기 때문이다. 그래서 기능보다 관측을 먼저 깐다. 트레이스를 읽는 법은 비동기와 트레이싱에서 다뤘다.

Q. 관측 도구를 프로덕션에 붙일 때 걸리는 것이 있나

트레이싱은 프롬프트와 검색 문서 원문을 외부 SaaS로 보낸다.

로컬 LLM을 도입하는 이유가 데이터 반출 통제인 조직이라면, 관측 도구에도 같은 기준을 적용해야 논리가 맞다.

LLM 호출만 잠그고 관측 도구는 열어 두는 구성은 통제 목적 자체를 무너뜨린다.

Q. API 키는 팀에서 어떻게 관리하나

원칙이 넷이고, 프록시가 전제다.

키를 서버에 가두는 것은 보안만의 문제가 아니다. 프록시 지점이 있어야 사용자별 쿼터·캐싱·모델 라우팅·감사 로그를 걸 수 있고, 앞의 비용 절감 레버 대부분이 이 지점에서만 구현 가능하다.

예산 상한은 두 단으로 잡는다. 하드 스톱은 예상치의 1.5~2배, 소프트 경보는 예상치의 1배 지점이다. 하드 스톱을 예상치에 딱 맞추면 트래픽이 튀는 날 서비스가 통째로 멈춘다. 자세한 설계는 비동기와 트레이싱에 있다.

Q. 에이전트 워크플로를 유지보수 가능한 구조로 어떻게 설계하나

셋을 고정한다.

스키마가 안 바뀌는 한 앞뒤 모듈을 회귀 테스트할 필요가 없다. 스키마가 흔들리면 모듈화 자체가 무너진다 — 도메인 전문가와 흐름 엔지니어를 나눈 조직 구조도 다시 한 사람에게 합쳐진다. 경계를 긋는 7가지 기준은 모듈화 — 경계를 어디에 긋나에 있다.

Q. 모듈 경계는 무엇을 기준으로 긋나

재실행 단위가 핵심 기준이다.

매핑 코드가 길어지면 경계를 잘못 그은 신호로 본다. 억지로 나누면 변환 코드만 늘어난다.

Q. 서브그래프와 함수는 어떻게 구분하나

내부에 "흐름"이 있으면 서브그래프, "변환"만 있으면 함수다.

경계를 긋는 것과 그 단위를 무엇으로 올릴지는 별개 판단이다. 경계는 재실행 단위로 정하지만, 올리는 형태는 내부 구조로 정한다.

컴파일된 그래프는 그 자체로 호출 가능 객체라 add_node("이름", 컴파일된_그래프)로 바로 꽂힌다. 부모 입장에서 함수를 넣든 그래프를 넣든 계약은 동일하다 — State를 받아 State 일부를 돌려준다. 그래서 함수로 시작했다가 나중에 그래프로 승격시켜도 부모 배선은 바뀌지 않는다.

Q. 운영 중인 파이프라인에 신규 단계를 넣어야 한다면

그래프를 먼저 고치지 않는다. 순서를 뒤집는 것이 핵심이다.

앞단을 한 번만 실행해 체크포인터에서 상태를 꺼내고, 신규 로직을 그래프 밖에서 그 상태로 직접 호출해 눈으로 검증한다. 검증이 끝난 뒤에야 노드로 등록하고 엣지를 재배선하며, 옛 배선은 주석으로 남긴다.

앞단을 반복 실행하지 않으니 개발 루프가 짧고, 문제가 생기면 두 줄 되돌리면 끝난다. 안전 체크리스트 10항과 삽입 위치 4종은 서브그래프와 레거시 개조에 있다.

성공 조건은 하나다. State 스키마가 그대로면 앞뒤 모듈은 신규 노드의 존재를 모른다. 신규 노드가 새 키를 요구하는 순간 스키마 변경 → 앞뒤 영향 검토 → 전 구간 회귀가 줄줄이 따라온다.

Q. 병렬 노드가 결과를 덮어쓰는 문제는 어떻게 막나

병렬 노드끼리 쓰는 State 키를 분리하거나, 같은 키면 리듀서로 누적 병합한다.

리듀서 선택이 곧 동시성 설계다. 병렬 노드 4개가 각자 결과를 반환하는데 리듀서가 덮어쓰기면 에러도 없이 셋을 잃는다. 값 하나만 남는다.

Q. 멀티에이전트는 무엇이 다른가

다르지 않다. 서브그래프의 확대 적용이다.

노드가 함수 → 그래프 → 에이전트 팀으로 커질 뿐 계약은 동일하다. 그래서 모듈 계약을 잘 잡아 둔 조직이 멀티에이전트로 넘어갈 때 추가 비용이 거의 없다.

화려해 보이는 리서치 에이전트도 뜯어 보면 모듈 + 병렬 + Human-in-the-loop의 조합이다. Supervisor 패턴과 계층적 팀 구성은 병렬 처리와 멀티에이전트에 정리돼 있고, 언제 쪼개는지의 판정 기준과 각 토폴로지의 구현은 멀티에이전트 패턴 시리즈에서 더 깊게 다룬다.

Q. 노코드를 왜 쓰나

코드는 개발조직이 병목이 되기 때문이다. 노코드는 병목 리스크를 거버넌스 리스크로 교환하는 결정이다.

그래서 도입 판단의 진짜 질문은 "노코드가 좋은가"가 아니라 **"우리 조직이 거버넌스 리스크를 감당할 준비가 되었는가"**다.

Q. 어떤 업무를 노코드로 열지 어떻게 정하나

결과를 사람이 한 번 더 보는 업무는 열고, 결과가 그대로 시스템에 반영되는 업무는 코드로 잠근다.

자주 바뀌고 담당자가 직접 고치는 초안 생성 업무가 1순위다.

열기로 한 업무 안에서도 에이전트가 아니라 워크플로우를 표준으로 삼는다.

에이전트는 경로와 비용이 런타임에 결정돼 예측이 안 된다. 확산 초기에는 max_iteration을 낮게 잡아 제한적으로만 허용한다.

그리고 이 경계는 고정이 아니다. 노코드는 요구사항 발굴 도구로도 기능하므로, 검증된 것을 코드로 이관하는 것이 정상 경로다.

노코드에서도 Query Expansion + 병렬 검색 + Rerank 같은 상급 기법이 노드 조립으로 구현된다. 한계는 기능이 아니라 품질을 측정하고 실패를 다루는 방식에서 온다.

Q. 개발자 없이 굴러가는 AI를 어떻게 통제하나

금지 목록이 아니라 부품과 관측으로 통제한다. 3계층이다.

가장 강력한 수단은 워크플로우 도구화다. 위험한 처리(사내 시스템 호출·개인정보 접근)를 도구 안에 가두고 현업에는 인터페이스만 노출하면, 위험한 조합이 애초에 만들어지지 않는다.

배포 계층에서 반드시 잡을 것은 비용 파라미터 셋이다. 비용 사고의 전형이 여기서 나온다.

셋 다 워크플로우 리뷰에서 눈으로 잡히는 항목이라, 배포 전 체크리스트에 명시하는 것만으로 대부분 예방된다.

사후 계층에서는 DSL(YAML)을 익스포트해 Git에 올린다. 노코드 산출물에도 버전관리·리뷰·롤백이 붙고, 노드 추가와 프롬프트 변경이 diff로 보인다. 다만 DSL에는 프롬프트·좌표·UI 상태가 뒤섞여 가독성이 코드보다 나쁘고, API 키나 데이터셋 식별자 같은 민감값이 포함될 수 있어 저장소에 올리기 전 마스킹 규칙을 먼저 정해야 한다.

금지로 막으면 확산이 멈추고, 설계로 막으면 안 멈춘다. 거버넌스 3계층과 배포 전 체크리스트 12항은 사내 AI의 확산과 통제에 있다.

Q. 전사 AI 도입을 어떻게 확산시키나

확산은 교육 문제가 아니라 부품 공급 문제다.

개발조직이 검증된 지식베이스와 워크플로우를 부품으로 만들어 두면 현업은 조립만 하면 된다. 순서를 지키는 것이 절반이다 — 0단계 없이 시작하면 나중에 전부 다시 만들고, 2단계 없이 확산하면 난립한다.

성공 지표는 만들어진 앱 수가 아니라 개발 개입 없이 완결된 비율이다. 앱 수는 난립해도 올라가지만 이 비율은 부품이 갖춰졌을 때만 오른다. 그 과정에서 개발조직의 역할이 구현자에서 플랫폼 제공자로 바뀐다.

Q. MCP는 왜 중요한가

사용자를 사내 챗봇으로 오게 하는 대신, 이미 쓰는 도구 안에 사내 지식을 넣는 방식이기 때문이다.

채택률이 근본적으로 달라진다. 그리고 MCP는 앱 안이 아니라 퍼블리시 계층에 붙으므로 이미 만들어 둔 앱을 코드 한 줄 고치지 않고 노출할 수 있다.

동시에 확산의 최고 수단이자 통제의 최대 난점이다. 연동 사례와 도구 강제 프롬프트는 워크플로우 9종 해부에 있다. 엔드포인트 URL 하나가 사내 지식 전체에 대한 접근권이 되므로 URL 자체를 자격증명으로 취급하고, 어떤 지식베이스를 열지는 문서 등급 기준으로 별도 승인한다. 공개 가능 등급만 여는 것이 안전한 출발점이다.

용어 정리