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

현업에서 아키텍트에게 도착하는 문장은 대개 이미 해법의 형태를 하고 있습니다. "고객 문의 챗봇을 만들어 주세요", "계약서를 읽는 AI가 필요합니다" 같은 요청입니다. 이 문장을 그대로 요구사항으로 받으면 해법이 문제를 정의해 버리는 순서 역전이 일어납니다.

번역의 첫 단계는 요청을 세 성분으로 쪼개는 것입니다.

• 관찰된 증상 — 실제로 무엇이 불편한가. "문의 응답까지 평균 6시간이 걸린다"
• 추정된 원인 — 요청자가 생각하는 이유. "상담원이 부족하다"
• 제안된 해법 — 요청 문장 그 자체. "챗봇을 만들자"

이 중 아키텍트가 반드시 확보해야 하는 것은 첫 번째입니다. 증상이 수치로 잡히지 않으면 이후의 모든 설계 판단에 근거가 없습니다. 두 번째와 세 번째는 참고 자료일 뿐 제약이 아닙니다.

실무에서 자주 드러나는 역전 사례가 있습니다. 문의 6시간 지연을 조사했더니 문의의 상당수가 배송 조회 단일 유형이고, 그 답은 이미 사내 API가 즉시 반환할 수 있는 값이었습니다. 이 경우 필요한 것은 대화형 모델이 아니라 자연어를 기존 API 호출로 바꾸는 얇은 계층과, 나머지 유형을 사람에게 넘기는 분기입니다. 요청을 그대로 받아 범용 챗봇을 만들었다면 이미 결정적으로 풀리는 문제에 확률적 구성 요소를 얹는 셈이 됩니다.

시험에서는 이 판단을 "요청자가 원한 것"과 "문제를 푸는 것"이 갈리는 상황으로 제시합니다. 요청을 그대로 구현하는 선택지는 대체로 오답입니다.

문제를 확보했으면 다음 질문은 "여기에 모델이 필요한가"입니다. Claude 기반 솔루션이 값을 하는 지점은 결정적 규칙으로 표현하기 어려운 자연어 판단이 개입할 때입니다. 반대로 규칙이 명확한 곳에 모델을 쓰면 비용과 지연, 비결정성만 늘어납니다.

판별에 쓰는 실무 기준은 세 가지입니다.

1. 규칙으로 쓸 수 있는가 — 조건을 열거해 코드로 옮길 수 있다면 코드가 낫습니다. 세율 계산, 재고 차감, 자릿수 검증은 모델의 일이 아닙니다.
2. 입력이 얼마나 열려 있는가 — 형식이 고정된 입력은 파서로 충분합니다. 사람이 자유롭게 쓴 문장, 형식이 제각각인 문서, 맥락에 따라 뜻이 달라지는 표현이 모델의 영역입니다.
3. 오류를 감당할 수 있는가 — 모델은 확률적으로 답합니다. 틀렸을 때의 비용이 크고 되돌릴 수 없다면, 모델을 쓰더라도 검증 단계나 사람 확인을 함께 설계해야 합니다.

세 기준을 한 문제에 동시에 적용하면 대개 혼합 구조가 나옵니다. 전부 모델이거나 전부 코드인 설계는 드뭅니다.

# 안티패턴: 판정 가능한 규칙까지 모델에 맡긴다
verdict = ask_model(f"이 청구 금액 {amount}원이 한도 {limit}원을 넘는가?")

# 개선: 판정은 코드, 해석은 모델
over_limit = amount > limit                      # 결정적
reason = ask_model(claim_text, task="초과 사유를 분류")  # 자연어 판단

Anthropic의 「Building effective agents」도 같은 방향을 권합니다. 가장 단순한 구성을 먼저 찾고, 복잡성은 그것이 성능으로 보상될 때만 더하라는 원칙입니다. 모델을 쓰지 않는 선택도 아키텍처 결정이며, 시험에서는 이것이 정답인 경우가 적지 않습니다.

번역의 마지막 단계는 "무엇이 되면 성공인가"를 숫자로 적는 것입니다. Anthropic 문서는 프롬프트를 쓰기 전에 경험적으로 측정 가능한 성공 기준을 정의하라고 명시합니다. 이 순서를 뒤집으면 나중에 나온 결과에 기준을 맞추게 됩니다.

좋은 성공 기준은 네 요소를 갖습니다.

• 지표 — 무엇을 재는가 (분류 정확도, 필드 추출 일치율, 응답 지연)
• 목표값 — 얼마여야 하는가 (0.92 이상, p95 2초 이하)
• 측정 방법 — 어떤 데이터셋으로 어떻게 재는가 (사람이 라벨링한 300건 보류 집합)
• 기준선 — 지금은 얼마인가 (현재 사람 처리 정확도 0.95, 처리량 시간당 40건)

기준선이 특히 중요합니다. 기준선 없이 "정확도 0.92"만 적으면 그것이 개선인지 후퇴인지 알 수 없습니다. 사람이 0.98로 처리하던 일을 0.92로 자동화하는 것은, 처리량이 20배가 되고 오류 비용이 낮은 경우에만 정당합니다. 이 교환을 명시적으로 적어 두는 것이 아키텍트의 몫입니다.

지표를 하나만 두면 다른 축이 조용히 무너집니다. 실무에서는 최소한 품질·지연·비용 세 축을 함께 적고, 그중 무엇이 상한이고 무엇이 최적화 대상인지 구분합니다. 예를 들어 "지연 p95 2초는 상한, 비용은 요청당 30원 이하, 그 제약 안에서 정확도를 최대화"처럼 씁니다. 이렇게 적어 두면 이후 모델 선택과 패턴 선택이 취향이 아니라 계산이 됩니다.

문제와 기준이 정해져도 한 번에 전체를 만드는 것은 위험합니다. 모델 기반 시스템은 실제 데이터를 넣어 보기 전에는 품질을 알 수 없기 때문입니다. 규모를 키우기 전에 좁은 범위에서 기준 충족 여부를 확인하는 절차가 필요합니다.

범위를 자르는 기준은 "가장 쉬운 것"이 아니라 가장 대표적이면서 검증 가능한 것입니다.

• 전체 물량에서 유의미한 비중을 차지할 것 (파일럿 결과가 확장 근거가 되어야 함)
• 정답을 확보할 수 있을 것 (사람이 라벨링했거나 기존 처리 이력이 남아 있는 구간)
• 실패해도 되돌릴 수 있을 것 (사람 검토를 거치는 경로에 먼저 붙임)

// 파일럿 단계: 모델 결과를 적용하지 않고 기존 처리와 나란히 기록만 한다
const humanResult = await currentPipeline(doc);
const modelResult = await claudePipeline(doc);

await logComparison({
  docId: doc.id,
  human: humanResult,
  model: modelResult,
  agreed: isEqual(humanResult, modelResult),
});

return humanResult; // 운영 결과는 아직 사람 쪽을 쓴다

이 구조를 섀도 운영(shadow deployment)이라 부릅니다. 사용자에게는 기존 결과가 나가고 모델 결과는 비교 기록으로만 쌓이므로, 위험 없이 실제 분포에서 품질을 측정할 수 있습니다. 파일럿에서 기준을 넘기면 사람 검토를 붙인 제한 운영으로, 그다음 자동 처리로 단계를 올립니다.

시험 함정 하나를 미리 짚습니다. "파일럿은 가장 어려운 사례로 해야 한다"는 선택지가 자주 나옵니다. 어려운 사례만 모으면 실패율이 실제 분포보다 과장되어 확장 판단을 그르칩니다. 파일럿 집합은 운영 분포를 닮아야 합니다.