RAG를 안정적으로 운영하는 법: Postman Enterprise로 검색·생성 API를 통제하기

앞선 두 글에서 우리는 Postman 컬렉션을 API의 단일 진실 공급원(SSOT) 으로 두는 법과, 조직이 커질 때 환경 전략·컬렉션 규칙·접근 통제로 거버넌스를 세우는 법을 다뤘습니다. 이번 글은 그 두 축을 요즘 가장 뜨거운 워크로드인 RAG(Retrieval-Augmented Generation) 에 적용합니다.

핵심 메시지를 먼저 분명히 해 둡니다. Postman은 RAG 플랫폼이 아닙니다. 청킹·임베딩 생성·벡터 인덱싱·검색 랭킹은 벡터 DB(Pinecone, Weaviate, Qdrant, pgvector)와 프레임워크(LangChain, LlamaIndex)의 몫입니다. Postman이 맡는 것은 그 구성요소들을 잇는 API 레이어 — 임베딩 API, 벡터 검색 API, LLM 생성 API와 그 사이의 흐름을 검증하고 통제하는 일입니다.

RAG의 진짜 문제: 모델이 아니라 "흐름"

"RAG를 만들어줘"라고 하면 보통 개별 호출은 잘 나옵니다. 임베딩을 만들고(POST /embeddings), 벡터 DB에 질의하고(POST /query), 그 결과를 프롬프트에 넣어 생성(POST /messages)합니다. 문제는 이 네 단계 사이에 흐르는 데이터입니다.

• 쿼리 임베딩이 검색 단계로 온전히 전달되는가
• 검색 결과가 정한 top_k와 유사도 임계값을 지키는가
• 생성 응답이 검색된 컨텍스트에 근거(citation) 를 두는가
• 호출당 토큰 비용이 예산 안에 있는가

이런 "요청 사이의 계약"은 개별 엔드포인트 테스트만으로는 보이지 않습니다. Postman 컬렉션은 이 흐름을 하나의 실행 가능한 워크플로로 묶어 한 번에 검증하게 해 줍니다. Postman은 이제 LLM을 외부 API가 아니라 1급 요청으로 다루며, OpenAI·Anthropic·Google 등 원하는 모델을 추가해 요청을 보내고 응답·응답시간·토큰 수로 비교할 수 있습니다.

1. 환경 전략을 RAG에 적용한다

1편의 3단계 환경 전략은 RAG에서 더 큰 값을 합니다. 환경 변수만 바꿔 모델·인덱스·검색 강도·비용 한도를 전환하면, 코드를 건드리지 않고 개발과 프로덕션의 동작을 분리할 수 있습니다.

환경	LLM 모델	벡터 인덱스	top_k	유사도 임계값	토큰 예산
Development	저비용·소형	dev(샘플 데이터)	8	0.60	16,000
Staging	prod와 동일	staging	4	0.70	8,000
Production	고성능	prod	4	0.75	8,000

// 컬렉션 레벨 Pre-request — 환경별 RAG 구성 주입
pm.collectionVariables.set('model', pm.environment.get('llm_model'));
pm.collectionVariables.set('top_k', parseInt(pm.environment.get('retrieval_top_k')) || 4);
pm.collectionVariables.set(
  'score_threshold',
  parseFloat(pm.environment.get('score_threshold')) || 0.7,
);

개발 인덱스에서는 top_k를 넉넉히 두고 임계값을 낮춰 빠르게 실험하고, 프로덕션에서는 정밀도를 높여 비용과 환각을 함께 줄입니다. API 키는 secret 타입 또는 Postman Vault에 두어 평문 노출을 막습니다(뒤의 거버넌스 절에서 다시 다룹니다).

2. 검색 → 생성 흐름을 변수 체이닝으로 검증한다

2편의 변수 체이닝을 그대로 RAG 4단계(임베딩 → 검색 → 생성 → 평가)에 적용합니다. 각 단계에서 값을 다음 단계로 넘기며 계약을 확인합니다.

// Step 1 — POST /embeddings 응답에서 쿼리 벡터 추출
const res = pm.response.json();
if (res.data && res.data[0] && res.data[0].embedding) {
  pm.collectionVariables.set('query_vector', JSON.stringify(res.data[0].embedding));
} else {
  pm.execution.setNextRequest(null); // 임베딩 실패 시 워크플로 중단
}

// Step 2 — POST /vectordb/query 결과의 "검색 계약" 검증
const matches = pm.response.json().matches;
pm.test('[REQ #12] 검색 결과가 top_k 이내', function () {
  pm.expect(matches.length).to.be.at.most(parseInt(pm.collectionVariables.get('top_k')));
});
pm.test('[REQ #13] 최상위 문서 유사도가 임계값 이상', function () {
  const threshold = parseFloat(pm.collectionVariables.get('score_threshold'));
  pm.expect(matches[0].score).to.be.above(threshold);
});
// 다음 생성 단계로 컨텍스트 문서 ID 전달
pm.collectionVariables.set('context_ids', JSON.stringify(matches.map((m) => m.id)));

// Step 3 — 생성 응답 검증: 근거(grounding)와 비용 가드
pm.test('[REQ #20] 응답에 출처가 포함된다', function () {
  pm.expect(pm.response.json().citations).to.not.be.empty;
});
pm.test('[REQ #21] 토큰 사용량이 예산 이내', function () {
  const budget = parseInt(pm.environment.get('max_total_tokens')) || 8000;
  pm.expect(pm.response.json().usage.total_tokens).to.be.below(budget);
});

setNextRequest는 Collection Runner·Newman·Postman CLI에서만 동작한다는 점만 기억하면(개별 Send에는 효과가 없습니다), 이 4단계를 하나의 런으로 묶어 "AI가 만든 RAG가 검색·생성 계약을 지키는가"를 한 번에 확인할 수 있습니다.

3. 모델 비교와 회귀: 비결정성을 다루는 법

RAG에서 까다로운 부분은 생성 출력이 비결정적이라는 것입니다. Postman은 프롬프트 컬렉션을 버전 관리되는 자산으로 두어, 모델이나 버전이 바뀌어도 같은 테스트 스위트로 결과를 비교·회귀할 수 있게 합니다. Collection Runner는 대규모 평가에, Flows는 시나리오별 인터랙티브 평가에 적합합니다. 새 모델이 나왔을 때 "프로덕션 프롬프트 컬렉션을 그대로 새 모델에 돌려보고 응답 품질·응답시간·비용을 나란히 비교"하는 워크플로를 만들 수 있습니다.

4. Mock으로 백엔드 없이 병렬 개발

2편에서 본 Mock 서버를 RAG에도 씁니다. 벡터 DB나 LLM 엔드포인트가 아직 없거나, 외부 호출 비용을 아끼고 싶을 때 예시 응답 기반 Mock으로 검색·생성 엔드포인트를 흉내 냅니다. 프론트엔드·평가 파이프라인은 실제 모델을 기다리지 않고 명세대로 병렬 개발하고, 같은 컬렉션으로 나중에 실제 구현을 검증합니다. 명세와 구현이 어긋나면 테스트가 바로 잡아냅니다.

5. Enterprise가 RAG에서 특히 빛나는 지점

RAG 운영은 결국 비싸고 민감한 API 키 + 다환경 + 다팀 문제입니다. 일반 API보다 거버넌스의 값이 더 큽니다.

• 시크릿·Vault — 임베딩·생성 호출은 과금되고, 키 유출은 곧 비용 사고입니다. secret 타입과 Postman Vault로 키를 보호하고, 규제 환경에서는 Enterprise의 BYOK 암호화 애드온으로 자체 키 관리까지 확장합니다.
• 고급 RBAC — 누가 프로덕션 LLM·벡터 엔드포인트를 호출할 수 있는지 역할별로 분리합니다. "프로덕션 인덱스에 쓰기 가능한 사람"을 좁히는 것만으로 사고 표면이 줄어듭니다.
• 감사 로그 — AI API는 호출당 비용과 데이터 거버넌스 이슈가 있어 "누가 무엇을 했는가"의 가치가 큽니다. 감사 로그는 Postman API로도 제공되어 SIEM과 연동해 이상 사용을 추적할 수 있습니다.
• Private API Network — 팀마다 제각각 파이프라인을 배선하는 대신, 승인된 retrieval·embedding API만 사내 카탈로그로 노출해 재사용을 강제합니다.
• 거버넌스 경고 / Partner Workspaces — 내부 RAG 서비스 API에 표준을 일관되게 적용하고, 필요하면 파트너 워크스페이스로 RAG API를 외부에 안전하게 공개합니다.

여기에 Git Sync를 결합하면, 프롬프트·컬렉션 변경이 GitHub 커밋으로 남고 Postman 감사 로그로도 남아 이중의 가시성을 확보합니다.

정리

RAG의 품질은 모델 하나가 아니라 임베딩·검색·생성 API가 이루는 흐름에서 갈립니다. Postman은 그 흐름을 대체하지 않고 검증하고 통제합니다.

• 환경 변수로 모델·인덱스·검색 강도·비용 한도를 코드 변경 없이 전환하고,
• 변수 체이닝으로 검색·생성 계약을 한 번의 런으로 검증하며,
• Mock으로 백엔드 없이 병렬 개발하고,
• 시크릿·RBAC·감사·Private API Network로 비싸고 민감한 AI API를 조직 차원에서 통제합니다.

로로소프트는 Postman Enterprise 플랜의 한국 내 정식 도입을 지원합니다. RAG·에이전트 워크로드에 맞는 구성과 견적이 필요하시면 도입 문의로 알려주세요.

참고: Postman의 AI 관련 기능(AI Agent Builder, Flows, 모델 평가)과 플랜·가격은 빠르게 바뀝니다. 게시 전 공식 문서·가격 페이지에서 최신 명칭과 수치를 한 번 더 확인하시길 권합니다.