Claude 시스템 설계 패턴

데모와 서비스 사이에는 구조가 있다

Claude를 처음 붙인 기능은 대개 단순하다. 사용자가 질문을 입력하면 애플리케이션이 Claude에게 보내고, Claude의 답변을 화면에 보여 준다. 이 구조는 빠르게 가치를 증명하기에 좋다. 문서 요약, 초안 작성, 분류, 간단한 질의응답은 단일 호출만으로도 충분히 쓸 만하다.

하지만 프로덕션 서비스는 다르다. 사용자는 오래된 문서를 올릴 수 있고, 권한이 없는 자료를 물어볼 수 있으며, Claude가 외부 API를 호출해야 할 수도 있다. 응답이 늦어지거나, 검색 결과가 틀리거나, 도구 실행이 실패하거나, 비용이 급증할 수도 있다. 이때 필요한 것은 더 긴 프롬프트가 아니라 시스템 구조다.

Claude 시스템 설계의 핵심 질문은 다음 네 가지다.

• 어떤 정보가 Claude에게 들어가는가?

• Claude가 어떤 판단을 맡는가?

• 외부 도구와 상태는 누가 관리하는가?

• 실패했을 때 어디에서 멈추고 누가 이어받는가?

이 장에서는 단일 호출, 루프형 호출, 에이전트형 시스템을 자율성의 단계로 보고, RAG, 모델 라우팅, 메모리, 사람 검토, 장애 격리까지 연결해 실제 서비스 구조를 설계한다.

AI 생성 이미지

자율성의 세 단계: 단일 호출, 루프, 에이전트

Claude 기반 시스템은 자율성에 따라 세 단계로 나눌 수 있다.

첫째, 단일 호출이다. 애플리케이션이 입력과 지시문을 보내고 한 번의 응답을 받는다. 요약, 문체 변경, 짧은 분류, 이메일 초안처럼 범위가 좁고 결과를 사람이 바로 검토할 수 있는 작업에 적합하다. 장점은 단순성이다. 디버깅이 쉽고 비용 예측도 쉽다. 단점은 복잡한 업무를 스스로 쪼개거나 재시도하지 못한다는 점이다.

둘째, 루프형 호출이다. 하나의 업무를 여러 단계로 나누고, 각 단계의 결과를 다음 단계 입력으로 넘긴다. 예를 들어 "문서 수집 → 핵심 쟁점 추출 → 근거 확인 → 초안 작성 → 검토표 생성"처럼 진행한다. 루프형 구조는 실패 지점을 분리할 수 있다. 어느 단계에서 품질이 떨어졌는지 알 수 있고, 그 단계만 다시 실행할 수 있다.

셋째, 에이전트형 시스템이다. Claude가 목표를 이해하고, 제한된 도구 안에서 다음 행동을 선택한다. 검색을 할지, 파일을 읽을지, 코드를 수정할지, 사용자에게 질문할지 판단한다. 자율성이 큰 만큼 위험도 커진다. 그래서 에이전트는 반드시 도구 권한, 반복 횟수, 비용 한도, 중단 조건, 사람 승인 조건을 가져야 한다.

좋은 설계는 처음부터 에이전트로 가지 않는다. 먼저 단일 호출로 가치가 있는지 확인하고, 반복되는 판단이 보이면 루프형으로 나눈다. 그다음 도구 선택 자체가 업무 가치의 핵심일 때만 에이전트형으로 확장한다.

루프는 작고 유한해야 한다

루프형 시스템의 가장 흔한 실패는 같은 시도를 계속 반복하는 것이다. Claude Code 같은 개발 보조 흐름에서도 에이전트가 같은 오류를 수정하려고 비슷한 패치를 반복하거나, 실패 원인을 바꾸지 않은 채 테스트만 다시 돌리는 상황이 생길 수 있다. 실무적인 해결책은 작업을 자율화하기 전에 원자 단위로 쪼개고, 각 단계마다 통과 기준과 실패 상태를 미리 정하는 것이다.¹

각 단계는 다음 네 가지를 가져야 한다.

예를 들어 "계약서 리스크 검토"를 한 번에 맡기지 않는다. 먼저 조항 목록을 추출한다. 다음으로 각 조항을 위험 유형별로 분류한다. 그다음 고위험 조항만 근거와 함께 설명한다. 마지막으로 사람이 검토할 질문 목록을 만든다. 각 단계가 통과해야 다음 단계로 간다.

루프에는 반드시 종료 조건이 있어야 한다. 세 번 실패하면 멈춘다. 같은 오류가 반복되면 새 계획을 요구한다. 외부 시스템을 변경하는 단계라면 실행 전 미리보기를 만들고 사람 승인을 받는다. 일정 시간 동안 진전이 없으면 자동 실행을 중단하고 사람에게 넘긴다. 루프는 똑똑해야 하는 것이 아니라 끝날 수 있어야 한다.

RAG: 모든 문서를 넣지 말고 필요한 조각을 찾는다

긴 정보를 다루는 가장 쉬운 방법은 모든 문서를 프롬프트에 넣는 것이다. 하지만 이 방식은 곧 한계에 부딪힌다. 컨텍스트 창은 유한하고, 문서가 많아질수록 비용과 지연 시간이 늘어난다. 더 큰 문제는 관련 없는 정보가 많아져 Claude가 중요한 근거를 놓칠 수 있다는 점이다.

RAG는 이 문제를 해결하는 대표 패턴이다. RAG는 Retrieval-Augmented Generation의 약자로, 필요한 지식을 외부 저장소에 보관하고 질문과 관련된 조각만 검색해 Claude에게 제공하는 방식이다. Claude Projects의 RAG 설명도 같은 원리를 따른다. 프로젝트 지식이 컨텍스트 한계에 가까워지면 모든 내용을 한 번에 넣는 대신, 질문 시점에 관련 정보만 검색해 사용한다. 이를 통해 컨텍스트 창만 사용할 때보다 더 많은 지식을 다룰 수 있다.²

RAG 설계에서 중요한 것은 "검색을 붙였다"가 아니다. 검색 품질이 답변 품질을 결정한다.

첫째, 청크 구성이 중요하다. 문서를 너무 작게 자르면 맥락이 사라지고, 너무 크게 자르면 검색 결과 안에 불필요한 내용이 많아진다. 정책 문서는 조항 단위, 제품 매뉴얼은 절 단위, 회의록은 안건 단위처럼 문서의 의미 구조에 맞춰 나누는 편이 좋다.

둘째, 메타데이터를 붙여야 한다. 문서 제목, 작성일, 버전, 부서, 권한 등급, 언어, 제품명 같은 정보는 검색과 필터링에 필요하다. 특히 사내 지식 도우미에서는 검색 전에 권한 필터를 적용해야 한다. Claude가 답변을 잘하더라도 사용자가 볼 수 없는 문서가 근거로 들어가면 시스템 실패다.

셋째, 재랭킹을 고려해야 한다. 첫 검색은 넓게 후보를 찾고, 두 번째 단계에서 질문과 가장 직접적으로 관련된 조각을 다시 고른다. RAG 품질이 낮을 때는 모델보다 검색 결과를 먼저 의심해야 한다.

넷째, 근거 제시 방식을 정해야 한다. 답변에는 문서명, 조항, 페이지, 날짜, 근거 ID가 붙어야 한다. 근거가 없으면 "확인되지 않음"이라고 말해야 한다. RAG의 목표는 Claude가 더 많이 아는 것처럼 보이게 만드는 것이 아니라, 답변을 검증 가능하게 만드는 것이다.

모델 라우팅: 비용 절감보다 중요한 작업 배치

모든 요청에 가장 강한 모델을 쓰면 단순하다. 하지만 비용과 지연 시간이 커진다. 반대로 모든 요청에 빠른 모델만 쓰면 고위험 판단에서 품질이 떨어질 수 있다. 모델 라우팅은 이 균형을 잡는 아키텍처 결정이다.

라우팅 기준은 단순히 "비싸냐, 싸냐"가 아니다. 다음 기준을 함께 본다.

• 작업 난도: 단순 분류인가, 복잡한 추론인가?

• 지연 허용치: 즉시 응답해야 하는가, 배치로 처리해도 되는가?

• 위험도: 틀렸을 때 사용자가 손해를 보는가?

• 근거 필요성: 문서 기반 검증이 필요한가?

• 출력 형식: 짧은 JSON인가, 긴 보고서인가?

• 도구 실행 여부: 외부 API 호출이나 쓰기 작업이 있는가?

예를 들어 고객 문의의 언어 감지와 카테고리 분류는 빠른 모델로 처리할 수 있다. 환불 정책 해석, 법무 리스크 요약, 복잡한 코드 변경 계획은 더 강한 모델로 보낸다. 검색 결과가 부족하거나 답변 확신도가 낮으면 fallback 모델을 호출하거나 사람 검토로 넘긴다.

라우팅은 한 번의 선택으로 끝나지 않는다. 운영 중에는 평가 결과를 보고 경로를 조정해야 한다. 쉬운 요청이 고성능 모델로 과도하게 가고 있다면 비용을 줄인다. 반대로 특정 유형에서 오류가 반복되면 더 강한 모델, 더 많은 근거, 사람 승인 경로를 붙인다.

상태와 메모리는 컨텍스트와 분리한다

대화 기록을 계속 Claude에게 넣으면 기억이 생기는 것처럼 보인다. 하지만 모든 기록을 컨텍스트에 누적하는 방식은 오래가지 못한다. 토큰 비용이 늘고, 오래된 정보가 최신 정보와 충돌하며, 민감한 정보가 불필요하게 반복 전달될 수 있다.

상태와 메모리는 분리해서 설계해야 한다.

세션 상태는 지금 진행 중인 작업에 필요한 임시 정보다. 현재 단계, 선택된 문서, 사용자가 승인한 옵션, 마지막 오류 등이 여기에 속한다. 세션이 끝나면 버리거나 최소한만 저장한다.

사용자 선호는 반복 사용 가치가 있는 정보다. 선호하는 문체, 보고서 형식, 언어, 자주 쓰는 제품명 같은 정보다. 단, 개인정보나 민감 정보는 저장 근거와 삭제 방법을 갖춰야 한다.

대화 기록은 그대로 넣기보다 요약 상태로 압축한다. "사용자는 A안을 선택했고, B는 제외했으며, 다음 단계는 예산표 작성이다"처럼 작업에 필요한 상태만 남긴다.

지식 저장소는 RAG로 검색할 문서다. 매번 컨텍스트에 넣지 않고, 질문과 관련될 때만 불러온다.

어떤 정보를 어디에 둘지는 최신성, 민감도, 재사용 가치, 토큰 비용, 검색 가능성으로 판단한다. 최신성이 높으면 실시간 조회나 짧은 세션 상태가 낫다. 민감도가 높으면 저장하지 않거나 암호화·권한 통제를 적용한다. 재사용 가치가 낮으면 메모리로 만들지 않는다.

Human-in-the-loop는 예외가 아니라 설계 요소다

사람 검토는 AI가 실패했을 때 급히 붙이는 안전장치가 아니다. 처음부터 시스템 경로에 들어가야 한다. 특히 다음 경우에는 human-in-the-loop가 필요하다.

• 금전, 계약, 법률, 의료, 인사 결정에 영향을 주는 경우

• 외부 시스템에 쓰기 작업을 수행하는 경우

• 개인정보나 기밀 정보가 포함된 경우

• Claude가 근거 부족이나 불확실성을 표시한 경우

• 같은 단계가 반복 실패한 경우

• 사용자가 이의를 제기했거나 불만을 표현한 경우

사람 검토를 넣는다고 해서 모든 작업을 느리게 만들 필요는 없다. 저위험 작업은 자동으로 통과시키고, 중간 위험은 샘플링 검토를 하며, 고위험 작업은 승인 전 대기 상태로 둔다. 중요한 것은 Claude의 결과를 사람이 다시 처음부터 읽게 만드는 것이 아니다. 검토자가 빠르게 판단할 수 있도록 근거, 변경 전후 비교, 위험 표시, 추천 행동을 함께 제공해야 한다.

장애 격리: 실패해도 작게 실패하게 만든다

운영 가능한 Claude 시스템은 실패하지 않는 시스템이 아니다. 실패해도 영향 범위가 작고, 원인을 추적할 수 있으며, 되돌릴 수 있는 시스템이다.

장애 격리는 설계 단계에서 시작한다. 도구 호출 권한은 최소화한다. 읽기 도구와 쓰기 도구를 분리한다. 쓰기 작업은 실행 전 미리보기를 만들고, 중요한 작업은 사람 승인을 받는다. 외부 API 호출에는 타임아웃과 재시도 제한을 둔다. 같은 요청이 여러 번 실행되어도 문제가 없도록 멱등성을 고려한다. 비용 한도와 반복 횟수 한도를 둔다.

출력도 격리해야 한다. Claude의 응답을 바로 데이터베이스에 쓰지 말고 스키마 검증을 거친다. JSON 형식이면 필수 필드, 허용값, 길이, 금지 문자열을 검사한다. 사용자가 보는 답변에는 불확실성, 근거 부족, 사람 검토 필요 상태를 표시한다.

로그와 감사 기록도 필요하다. 어떤 모델, 어떤 프롬프트 버전, 어떤 검색 결과, 어떤 도구 입력, 어떤 승인자가 있었는지 남겨야 한다. 단, 원문 개인정보와 기밀정보를 무분별하게 저장해서는 안 된다. 운영 로그는 추적 가능성과 데이터 최소화 사이에서 설계해야 한다.

참조 아키텍처: 내부 지식 도우미

가장 현실적인 시작점은 내부 지식 도우미다. 구조는 다음과 같다.

1. 사용자가 질문한다.

2. 인증 시스템이 사용자 권한을 확인한다.

3. 검색 시스템이 권한이 있는 문서만 대상으로 관련 청크를 찾는다.

4. 필요하면 재랭킹으로 근거 후보를 좁힌다.

5. Claude가 근거 기반 답변을 만든다.

6. 답변에는 문서명, 날짜, 조항, 근거 ID를 붙인다.

7. 근거가 부족하면 확인 불가로 응답하거나 담당자에게 연결한다.

8. 로그에는 요청 ID, 검색 문서 ID, 모델 버전, 비용, 오류 상태를 남긴다.

이 구조에서 Claude는 모든 것을 아는 사내 전문가가 아니다. 검색된 근거를 바탕으로 설명하고 정리하는 인터페이스다. 그래서 품질 개선도 프롬프트만 고치는 것으로 끝나지 않는다. 문서 품질, 청크, 메타데이터, 권한 필터, 재랭킹, 평가셋을 함께 개선해야 한다.

참조 아키텍처: 문서 검토 코파일럿

계약서, 제안서, 정책 문서 검토는 루프형 설계가 잘 맞는다.

1. 문서 구조와 주요 조항을 추출한다.

2. 조직의 검토 기준과 비교한다.

3. 고위험 조항만 근거와 함께 표시한다.

4. 누락된 조항과 모호한 표현을 찾는다.

5. 수정 제안과 질문 목록을 만든다.

6. 법무 또는 담당자가 승인한다.

여기서 Claude가 최종 법률 판단을 내려서는 안 된다. Claude의 역할은 검토자가 놓치기 쉬운 쟁점을 정리하고, 근거 위치를 찾아주고, 수정 초안을 제안하는 것이다. 고위험 조항, 불확실한 해석, 외부 제출 문서는 사람 승인 없이는 다음 단계로 넘어가지 않는다.

참조 아키텍처: 고객지원 에이전트

고객지원은 에이전트형 구조로 확장하기 쉽지만, 그만큼 통제가 중요하다.

처음에는 문의 분류와 답변 초안 생성부터 시작한다. 이후 주문 조회, 환불 가능 여부 확인, 티켓 생성 같은 도구를 붙인다. 마지막으로 제한된 범위에서 자동 처리까지 확장할 수 있다.

단, 환불 실행, 계정 변경, 민감 정보 조회는 읽기와 쓰기를 분리해야 한다. Claude가 환불을 제안할 수는 있어도, 실제 실행은 정책 검사와 승인 절차를 거쳐야 한다. 고객에게 보낼 답변은 톤, 금지 표현, 정책 근거, 에스컬레이션 조건을 검사한다.

고객지원 에이전트의 목표는 모든 문의를 자동 처리하는 것이 아니다. 쉬운 문의는 빠르게 해결하고, 어려운 문의는 더 좋은 정보와 함께 사람 상담원에게 넘기는 것이다.

도입 순서: 작게 시작해 경계를 넓힌다

Claude 시스템은 다음 순서로 발전시키는 것이 안전하다.

1. 단일 호출 MVP로 업무 가치를 확인한다.

2. 출력 형식과 성공 기준을 고정한다.

3. 실제 실패 사례를 모아 평가셋을 만든다.

4. 문서 근거가 필요하면 RAG를 붙인다.

5. 반복 업무는 루프형으로 나누고 단계별 통과 기준을 둔다.

6. 도구 호출은 읽기 전용부터 시작한다.

7. 쓰기 작업에는 미리보기, 승인, 롤백을 붙인다.

8. 요청 난도와 위험도에 따라 모델 라우팅을 적용한다.

9. 반복 실패와 고위험 판단은 사람에게 넘긴다.

10. 로그, 비용, 품질, 오류를 운영 대시보드로 본다.

이 순서를 따르면 Claude 기능은 데모에서 서비스로 이동한다. 핵심은 Claude에게 더 많은 자유를 주는 것이 아니다. 자유를 줄수록 더 명확한 경계, 검증, 중단 조건을 함께 주는 것이다.

설계 체크리스트

Claude 기능을 배포하기 전 다음 질문에 답해야 한다.

• 이 기능은 단일 호출, 루프형, 에이전트형 중 어디에 속하는가?

• 각 단계의 목표와 통과 기준은 명확한가?

• 검색 문서는 권한 필터와 메타데이터를 갖추었는가?

• 답변에 근거 위치를 표시할 수 있는가?

• 모델 라우팅 기준은 비용뿐 아니라 위험도와 난도를 반영하는가?

• 상태, 메모리, 대화 기록, 지식 저장소가 분리되어 있는가?

• 반복 실패 시 멈추는 조건이 있는가?

• 외부 시스템 변경 전 미리보기와 승인 절차가 있는가?

• 롤백, 감사 로그, 비용 한도, 재시도 제한이 있는가?

• 사람이 개입해야 하는 조건이 제품 흐름 안에 들어 있는가?

이 질문에 답할 수 있으면 Claude는 단순한 답변 생성기가 아니라 운영 가능한 시스템의 한 구성 요소가 된다.

참고

¹The Claude Code 'Infinite Loop' Bug: How to Spot It, Stop It, and Get Your Project Back on Track

²Retrieval augmented generation (RAG) for projects