문제를 시스템으로 — Claude 솔루션 설계의 뼈대

1.1 비즈니스 문제를 Claude 솔루션으로 번역하기

설계의 출발점은 기술이 아니라 문제 정의입니다. "고객 문의를 자동화하고 싶다"는 요청을 그대로 받으면 실패합니다. 아키텍트는 그 뒤의 실제 목표(응답 시간 단축인지, 상담 인력 재배치인지, 정확도 보장인지)를 분리하고, 성공을 무엇으로 판정할지 먼저 합의합니다. 이때 결정론적 규칙으로 충분한 부분과 언어 이해가 필요한 부분을 나누는 것이 핵심입니다. Claude가 잘하는 일(모호한 자연어 해석, 요약, 분류, 추론)과 못하는 일(정확한 산술, 최신 사실 조회)을 구분해, LLM(large language model, 대규모 언어 모델)에 맡길 경계를 그립니다.

1.2 입력·처리·출력·피드백까지, 끝단을 잇는 설계

하나의 Claude 시스템은 네 흐름으로 봅니다. 입력을 정제·검증하는 앞단, 검색이나 도구로 맥락을 붙여 모델이 처리하는 중간, 결과를 정해진 형식(구조화 출력, structured output — 다음 시스템이 바로 받아 쓰는 JSON 같은 형태)으로 내보내는 뒷단, 그리고 결과 품질을 되받아 고치는 피드백 순환(feedback loop, 출력을 다시 입력으로 되먹여 성능을 교정하는 고리)입니다. 초보 설계는 가운데 처리만 그리다 멈추지만, 아키텍트는 잘못된 입력을 걸러내는 앞단과 오답을 감지해 재처리하는 뒷단까지 하나의 그림으로 잇습니다. 피드백 순환이 없으면 배포 뒤 품질이 서서히 무너집니다.

1.3 워크플로·에이전트·증강 LLM — 패턴을 고르는 기준

같은 요구도 세 패턴으로 받을 수 있습니다. 증강 LLM(augmented LLM — 검색과 도구를 한 번의 호출에 붙여 모델의 지식을 보강하는 최소 단위)은 단순·저지연 과제에 맞습니다. 워크플로(workflow — 설계자가 미리 정한 순서대로 여러 호출을 잇는 방식)는 단계가 예측 가능하고 감사 추적이 필요할 때 강합니다. 에이전트형(agentic — 모델이 스스로 다음 행동과 도구를 판단하며 진행하는 방식)은 경로를 미리 그릴 수 없는 개방형 과제에 씁니다. 아키텍트의 판단 축은 예측 가능성과 유연성의 맞교환입니다. 자유도가 높을수록 비용·지연·오류 가능성이 함께 오르므로, 통제가 필요한 규제 업무는 워크플로로 낮춰 잡는 편이 안전합니다.

1.4 다중 에이전트와 오케스트레이션 전략

한 에이전트로 감당하기 벅찬 과제는 역할을 나눠 여러 에이전트에 맡깁니다. 대표 구조는 지휘자-작업자(orchestrator-worker — 상위 에이전트가 과제를 나눠 하위 전문 에이전트에 배분하고 결과를 취합하는 형태)입니다. 조사·작성·검증을 서로 다른 에이전트가 맡으면 각자의 맥락이 짧아져 정확도가 오릅니다. 다만 다중 에이전트(multi-agent — 여러 자율 에이전트가 협업하는 시스템)는 호출 수와 지연, 조율 실패 위험이 함께 커집니다. 아키텍트는 하위 과제가 서로 독립적이고 병렬화 이득이 클 때만 나누고, 순차 의존이 강한 일은 굳이 분할하지 않습니다. 에이전트 사이에 무엇을 어떤 형식으로 넘길지(핸드오프 규약)를 먼저 규정해야 조율이 무너지지 않습니다.

1.5 복잡한 문제를 나누는 분해 기법

큰 과제를 한 번의 호출에 통째로 넣으면 모델의 주의가 흩어지고 오류가 섞입니다. 분해(decomposition — 복잡한 과제를 다루기 쉬운 하위 과제로 쪼개는 기법)는 설계자의 기본기입니다. 대표 방법은 프롬프트 체이닝(prompt chaining — 한 호출의 출력을 다음 호출의 입력으로 잇는 사슬)으로 추출·변환·검증을 단계로 나누는 것, 그리고 라우팅(routing — 먼저 요청 유형을 분류해 알맞은 처리 경로로 보내는 방식)으로 서로 다른 종류의 일을 갈라 보내는 것입니다. 각 단계가 짧고 검증 가능해질수록 어디서 틀렸는지 짚기 쉬워지고, 부분만 고쳐 다시 돌릴 수 있습니다. 분해의 목표는 정확도만이 아니라 고칠 수 있는 구조를 만드는 데 있습니다.

1.6 비즈니스 가치 기둥에 설계를 정렬하기

좋은 설계는 기술적으로 우아한 것이 아니라 사업 가치에 정렬된 것입니다. 효율(반복 업무 자동화), 전환(일하는 방식의 재설계), 생산성(같은 인력의 산출 증대), 비용, 성능 보장(SLA, service level agreement — 응답 시간·가용성처럼 계약으로 약속하는 서비스 수준) 가운데 이 프로젝트가 무엇을 겨냥하는지 먼저 정하지 않으면 설계 판단의 기준이 서지 않습니다. 응답 지연에 민감한 실시간 상담은 더 빠른 모델과 프롬프트 캐싱(prompt caching — 반복 맥락을 재사용해 비용·지연을 줄이는 기법)으로 SLA를 맞추고, 정확도가 최우선인 심사 업무는 상위 모델과 검증 단계를 더해 비용을 감수합니다. 같은 기능도 어느 기둥을 우선하느냐에 따라 모델 선택과 구조가 갈립니다.

! 흔한 함정

• 모든 문제를 에이전트형으로 풀려는 습관 — 예측 가능한 업무까지 자율 에이전트로 만들면 비용·지연·오류만 늘고 감사 추적이 어려워집니다. 통제가 필요한 일은 워크플로가 정답일 때가 많습니다.
• 피드백 순환을 빼고 배포하는 것 — 출력 품질을 되받아 교정하는 고리가 없으면, 초기엔 잘 작동해도 데이터 분포가 바뀌며 성능이 조용히 무너집니다.
• 다중 에이전트를 성능 근거가 아니라 유행으로 도입하는 것 — 순차 의존이 강한 과제를 억지로 쪼개면 조율 비용이 병렬화 이득을 넘어섭니다.
• 가치 기둥을 정하지 않고 시작하는 것 — 무엇을 최우선으로 삼는지 합의 없이 설계하면, 나중에 지연·비용·정확도가 충돌할 때 판단 근거가 사라집니다.