6.1구조화된 디스커버리와 요구사항 수집

LLM 프로젝트에서 가장 흔한 실패는 기술이 아니라 기대치가 잘못 형성된 것입니다. 전형적인 경로는 이렇습니다.

1. 아키텍트가 손에 잡히는 사례 20건으로 데모를 만든다. 20건 모두 잘 동작한다.
2. 이해관계자가 그 자리에서 "정확도 100%"를 기억한다. 아무도 그렇게 말하지 않았지만 20건 중 20건이 그렇게 읽힌다.
3. 운영 첫 주에 1,200건이 들어온다. 상위 5개 유형이 전체의 60%를 차지하고, 나머지 40%는 데모에 없던 롱테일이다.
4. 롱테일에서 오류가 나온다. 전체로는 나쁘지 않은 수치인데도 "100%였는데 왜 틀리냐"는 대화가 시작된다.

문제의 뿌리는 데모의 입력 분포가 운영의 입력 분포와 다르다는 데 있습니다. 데모용 사례는 대개 문제를 설명하기 좋은 것, 즉 전형적이고 깨끗한 것으로 고릅니다. 운영 입력은 그렇지 않습니다. 디스커버리 단계에서 이 격차를 드러내지 못하면, 나중에 아무리 정직하게 숫자를 보고해도 "약속보다 못하다"는 인상만 남습니다.

두 번째 뿌리는 비교 기준이 없다는 것입니다. 이해관계자의 머릿속 기준선은 무의식적으로 100%입니다. 그런데 지금 그 일을 하는 사람의 성능을 물어보면 대부분 100%가 아닙니다.

물어볼 것	전형적인 답	이 답이 바꾸는 것
지금 이 일을 사람이 하면 얼마나 정확한가	"숙련자는 대부분 맞고, 신입은 자주 놓친다"	목표가 100%에서 "숙련자 수준"으로 내려온다
사람이 틀리는 경우는 주로 언제인가	"비슷한 조항이 두 개일 때"	평가셋에 반드시 넣어야 할 유형이 드러난다
사람이 틀렸을 때 지금은 어떻게 발견하는가	"고객이 항의할 때"	발견 장치가 없다는 사실이 드러난다
한 건 틀리면 무엇을 잃는가	"재작업 30분" 또는 "계약 분쟁"	필요한 정확도 수준 자체가 달라진다

마지막 질문이 특히 중요합니다. 오류 비용이 재작업 30분인 시스템과 계약 분쟁인 시스템은 같은 정확도라도 다른 설계를 요구합니다. 전자는 자동 실행이 가능하고, 후자는 사람 승인 단계가 필요합니다. 디스커버리에서 이 값을 잡지 못하면 아키텍처 결정의 근거가 통째로 비게 됩니다.

디스커버리 회의에서 "어떤 기능이 필요하십니까"로 시작하면 기능 목록만 남습니다. LLM 시스템에서 정작 필요한 것은 판정 기준과 실패 비용입니다. 다음 여섯 갈래를 순서대로 확인하십시오.

갈래	구체적인 질문	답이 없으면 생기는 일
기준선	지금 사람이 이 일을 얼마나 잘하는가	목표가 100%로 굳는다
오류 비대칭	놓치는 것과 잘못 잡는 것 중 무엇이 더 나쁜가	재현율과 정밀도 중 무엇을 희생할지 정할 수 없다
수신자	결과를 실제로 받아 쓰는 사람은 누구인가	요구를 말한 사람과 쓰는 사람이 달라 나중에 뒤집힌다
발견 장치	시스템이 틀렸을 때 누가 어떻게 알아채는가	조용한 실패가 쌓인다
입력 분포	실제로 들어오는 요청의 유형과 비중은 어떠한가	평가셋이 운영을 대표하지 못한다
변경 압력	이 업무의 규칙은 얼마나 자주 바뀌는가	유지 비용을 과소평가한다

오류 비대칭은 특히 자주 빠뜨리는 항목입니다. 예를 들어 보안 로그에서 이상 징후를 찾는 시스템이라면 놓치는 쪽(미탐)이 훨씬 나쁩니다. 반대로 고객에게 자동 발송되는 문구를 고르는 시스템이라면 잘못 보내는 쪽(오탐)이 훨씬 나쁩니다. 이 방향이 정해져야 임계값 설정과 사람 검토 지점을 정할 수 있습니다.

발견 장치를 묻는 이유는 LLM 시스템의 실패가 대개 조용하기 때문입니다. 서버가 죽으면 알림이 오지만, 요약이 미묘하게 왜곡되는 것은 아무도 알려 주지 않습니다. "누가 알아채는가"에 대한 답이 "고객이 항의할 때"라면, 그 자체가 설계해야 할 요구사항입니다.

디스커버리에서 답을 받아 적는 것으로 끝내면 안 됩니다. 받은 답을 그 자리에서 되읽어 확인하십시오. "그러니까 누락 한 건이 재작업 30분이고, 잘못 표시하는 것보다 놓치는 게 더 나쁘다는 말씀이시죠"라고 되물으면, 절반 정도는 그 자리에서 수정됩니다.

요구사항 문서에 "정확하게", "빠르게", "자연스럽게" 같은 말이 남아 있으면 그 문서는 인수 시점에 반드시 분쟁을 만듭니다. 측정 가능한 기준의 조건은 세 가지입니다. 무엇을 세는가, 어떤 표본에서 세는가, 얼마면 통과인가.

모호한 요구	측정 가능한 기준	무엇이 달라졌는가
고객 응대를 개선한다	환불 문의 1차 응답 초안의 상담원 수정률이 평가셋 200건에서 30% 이하	세는 대상, 표본, 통과선이 모두 생겼다
요약이 정확해야 한다	원문에 없는 사실이 포함된 요약이 평가셋 150건 중 3건 이하	"정확"을 환각 건수로 조작적으로 정의했다
빨라야 한다	운영 트래픽 기준 p95 응답이 첫 토큰까지 400ms 이내	평균이 아니라 꼬리를, 총 완료가 아니라 체감을 잡았다
안전해야 한다	사전 정의한 금칙 요청 80건 중 통과하는 것이 0건	검증 가능한 테스트셋으로 바꿨다

여기서 표본을 명시하는 것이 핵심입니다. "정확도 90%"는 어떤 입력에서 잰 90%인지 말하지 않으면 아무 약속도 아닙니다. 입력이 바뀌면 같은 시스템이 다른 숫자를 냅니다. 그래서 기준을 쓸 때는 반드시 평가셋을 함께 지정하고, 그 평가셋이 운영 분포를 어떻게 반영했는지 한 줄이라도 남깁니다.

Anthropic 문서의 성공 기준 정의 지침도 같은 방향을 가리킵니다. 성공 기준은 구체적이고, 측정 가능하며, 달성 가능하고, 그 업무에 실제로 중요한 것이어야 합니다. 여기에 LLM 시스템 고유의 조건을 하나 더 붙이면 좋습니다. 재측정이 가능해야 합니다. 사람이 매번 눈으로 확인해야만 판정되는 기준은 몇 주 지나면 아무도 측정하지 않게 됩니다.

기준을 정할 때 흔히 저지르는 실수가 지표를 하나만 두는 것입니다. 정확도만 목표로 걸면 지연과 비용이 조용히 나빠지고, 비용만 걸면 품질이 내려갑니다. 최소한 품질·지연·비용 세 축에 각각 하나씩, 그리고 안전 관련 통과 조건 하나를 두는 편이 안전합니다. 이때 하나는 목표, 나머지는 제약으로 구분해 두면 트레이드오프 논의가 훨씬 쉬워집니다.

디스커버리의 마지막 산출물은 기능 목록이 아니라 범위 결정입니다. LLM 시스템에서 범위를 줄이는 가장 효과적인 방법은 기능을 빼는 것이 아니라 자동화 수준을 낮추는 것입니다.

같은 기능도 자동화 수준에 따라 위험과 구현 부담이 크게 달라집니다.

수준	형태	사람의 역할	적합한 조건
1	참고 정보 제시	사람이 전부 판단	오류 비용이 크고 신뢰가 아직 없다
2	초안 생성	사람이 수정 후 사용	초안 품질이 사람 기준선에 근접했다
3	자동 실행 + 사후 감사	사람이 표본 점검	오류가 되돌릴 수 있고 발견 장치가 있다
4	완전 자동	예외만 사람에게	오류 비용이 작고 지표가 안정적이다

첫 릴리스를 2수준으로 잡으면 두 가지를 동시에 얻습니다. 첫째, 사람이 수정하는 행위 자체가 평가 데이터가 됩니다. 수정률과 수정 내용이 다음 개선의 재료입니다. 둘째, 오류가 사용자에게 직접 도달하지 않으므로 초기 품질 변동을 감당할 수 있습니다.

반대로 첫 릴리스를 4수준으로 잡으면 평가 데이터를 얻기 전에 위험을 먼저 떠안습니다. 이해관계자가 "어차피 자동화가 목표 아니냐"고 말할 때, 아키텍트가 제시해야 할 것은 거부가 아니라 경로입니다. "3개월간 2수준으로 운영해 수정률이 15% 아래로 안정되면 3수준으로 올린다"처럼 승급 조건을 숫자로 합의하면, 자동화 목표를 포기하지 않으면서 순서를 지킬 수 있습니다.

범위를 좁힐 때 함께 정해야 할 것이 명시적 제외 목록입니다. "이번 릴리스에서 하지 않는 것"을 문서에 남기지 않으면, 하지 않기로 한 일이 나중에 누락으로 취급됩니다. 제외 항목마다 이유와 재검토 시점을 한 줄씩 붙이십시오. 이 목록이 나중에 인수인계 문서의 절반을 채웁니다.