에이전틱스
도메인 2. 애플리케이션과 통합

2.1요구사항 이해

예상 학습 시간 25

"요약 기능을 만들어 주세요"라는 요청만으로는 코드를 시작할 수 없습니다. 이 수업에서는 업무 요구를 기능 요구와 인프라 요구로 갈라내고, 착수 전에 합의해 두어야 할 성공 기준을 정하는 법을 다룹니다.

기능 요구와 비기능 요구

요구사항은 두 갈래로 갈립니다.

기능 요구는 무엇을 하느냐입니다. "문서를 받아 세 문장으로 요약한다", "요약에 원문 근거를 표시한다" 같은 것입니다.

비기능(인프라) 요구는 어떤 조건에서 하느냐입니다. "응답이 3초 안에 온다", "하루 1만 건을 처리한다", "개인정보가 외부로 나가지 않는다" 같은 것입니다.

Claude를 쓰는 기능에서는 비기능 요구가 특히 설계를 좌우합니다. 같은 "요약"이라도 실시간으로 응답해야 하면 스트리밍과 모델 등급을 고민해야 하고, 야간 배치로 돌려도 되면 배치 처리로 비용을 크게 낮출 수 있습니다. 기능 명세만 받고 시작하면 구조를 나중에 갈아엎게 됩니다.

요구사항을 받을 때 최소한 물어야 할 것들이 있습니다.

  • 한 번에 처리할 입력의 크기와 하루 처리량
  • 응답까지 허용되는 시간
  • 틀렸을 때의 비용 — 사람이 검토하는가, 그대로 나가는가
  • 다룰 데이터에 민감정보가 있는가

성공 기준을 숫자로 만들기

"좋은 요약"은 검증할 수 없습니다. 착수 전에 무엇을 측정할지, 어느 값이면 통과인지를 합의해야 합니다.

여기서 흔한 실수가 정확도 하나만 정하는 것입니다. Claude를 쓰는 기능은 대개 여러 축이 함께 걸립니다.

예시 기준
품질평가 세트 100건에서 사람 판정 통과 90건 이상
지연p95 응답 3초 이내
비용건당 평균 토큰 예산 이내
안전민감정보가 출력에 포함되는 사례 0건

기준을 정할 때 먼저 기준선을 재는 편이 낫습니다. 업계 관행 수치를 그대로 목표로 삼으면 우리 데이터에서 달성 가능한지 알 수 없습니다. 간단한 프롬프트로 20건만 돌려 봐도 출발점이 나오고, 거기서 얼마나 올려야 쓸 만한지 이야기할 수 있습니다.

또 하나, 틀렸을 때의 비용이 비대칭이면 기준도 비대칭이어야 합니다. 놓치는 것보다 잘못 잡는 것이 훨씬 나쁜 기능이라면, 전체 정확도보다 오탐률에 기준을 걸어야 합니다.

요구를 구현 결정으로 옮기기

합의한 요구는 구현 선택으로 이어져야 합니다. 자주 나오는 대응 관계가 있습니다.

  • 급하지 않고 양이 많다 → 배치 처리. 실시간 호출보다 크게 저렴합니다.
  • 응답이 빨라야 한다 → 스트리밍으로 첫 글자까지의 시간을 줄이고, 낮은 등급 모델을 검토합니다.
  • 같은 지침이 매 요청에 붙는다 → 앞쪽에 고정 배치하고 프롬프트 캐싱을 켭니다.
  • 출력을 프로그램이 소비한다 → 구조화된 출력과 검증 계층을 둡니다.
  • 사람이 최종 확인한다 → 완벽한 자동화보다 검토하기 쉬운 형태가 낫습니다.
# 요구: 야간에 대량 처리, 지연은 무관, 비용이 중요
# → 실시간 호출이 아니라 배치로
requests = [
    {"custom_id": doc.id, "params": {"model": MODEL, "max_tokens": 1024,
                                     "messages": [{"role": "user", "content": prompt(doc)}]}}
    for doc in documents
]
batch = client.messages.batches.create(requests=requests)

custom_id가 중요합니다. 배치는 순서를 보장하지 않으므로 결과를 원래 문서와 다시 짝지으려면 이 값이 있어야 합니다. 요구사항에서 "어떤 입력의 결과인지 추적해야 한다"가 나왔다면 이 지점이 설계에 반영되어야 합니다.

적합하지 않은 요구 걸러내기

모든 요구를 받아들이는 것이 좋은 일은 아닙니다. 착수 전에 걸러야 하는 유형이 있습니다.

정답이 하나로 정해진 계산 — 세금 계산, 재고 차감 같은 것은 결정적 코드가 맞습니다. 모델을 쓰면 느리고 비싸고 가끔 틀립니다.

출처를 보장해야 하는 사실 조회 — 모델의 기억에 의존하면 그럴듯한 오답이 나옵니다. 검색해서 근거와 함께 답하게 하거나, 아예 조회 기능을 쓰는 편이 맞습니다.

책임 소재가 사람에게 있어야 하는 판단 — 채용, 대출 승인 같은 영역은 최종 판단을 자동화하면 안 됩니다. 초안이나 보조 자료를 만드는 데까지가 적절합니다.

이런 요구가 들어왔을 때 그냥 거절하기보다 모델이 잘하는 형태로 다시 정의해 제안하는 편이 낫습니다. "합격 여부를 판정한다"를 "지원서에서 확인이 필요한 항목을 표시한다"로 바꾸면 같은 업무를 도우면서 판단은 사람이 쥡니다.

시험 함정

  • 응답 시간과 처리량을 기능 요구로 분류하는 선택지 — 이들은 비기능(인프라) 요구입니다.
  • 성공 기준을 정확도 하나로만 잡는 접근 — 품질·지연·비용·안전이 함께 걸립니다.
  • 업계 관행 수치를 그대로 목표값으로 삼는 선택지 — 우리 데이터의 기준선부터 재야 합니다.
  • 배치 처리에서 custom_id 없이 순서로 결과를 짝지을 수 있다는 서술 — 배치는 순서를 보장하지 않습니다.
  • 결정적 계산까지 모델에 맡기는 설계 — 느리고 비싸며 가끔 틀립니다.
  • 부적합한 요구를 그대로 거절하는 것이 유일한 답이라는 선택지 — 모델이 잘하는 형태로 다시 정의해 제안할 수 있습니다.

실습 시나리오

실제 시험과 같은 형식의 시나리오 문제입니다.

"고객 문의를 자동 분류해 담당 팀에 배정해 달라"는 요구를 받았습니다. 착수 전에 합의해 두면 가장 유용한 것은 무엇입니까?

빌드 연습 · 한 줄 요청을 착수 가능한 요구사항으로 펼치기

30
  1. 1.요청 고르기

    "회의록을 요약해 주세요" 같은 한 줄 요청을 하나 정합니다.

    기대 결과 · 출발점 문장이 한 줄로 적혀 있습니다.

  2. 2.기능·비기능 분리

    떠오르는 요구를 두 열로 나눠 적습니다.

    기대 결과 · 처리량·지연·민감정보 항목이 비기능 열에 들어가 있습니다.

  3. 3.기준선 측정

    간단한 프롬프트로 10건을 돌려 현재 품질을 눈으로 확인합니다.

    기대 결과 · 통과·실패 건수와 실패 유형이 기록됩니다.

  4. 4.성공 기준 작성

    품질·지연·비용·안전 네 축에 각각 기준을 씁니다.

    기대 결과 · 각 기준이 측정 방법과 함께 적혀 있습니다.

  5. 5.구현 결정 연결

    각 비기능 요구가 어떤 구현 선택으로 이어지는지 화살표로 적습니다.

    기대 결과 · 배치·스트리밍·캐싱 중 최소 하나가 근거와 함께 선택됩니다.

출처 및 더 읽기