6.2아키텍처 결정과 트레이드오프 전달

일반적인 시스템 설계에서는 "이 방식이 더 빠르다"처럼 한 축으로 우위를 말할 수 있는 경우가 많습니다. LLM 시스템에서는 그렇지 않습니다. 세 가지 성질이 설명을 어렵게 만듭니다.

첫째, 품질이 확률적입니다. "이 모델이 더 정확하다"는 진술은 항상 특정 평가셋 위에서만 참입니다. 다른 입력 분포에서는 순서가 뒤집힐 수 있습니다. 그래서 결정을 전달할 때는 결론보다 어떤 조건에서 그런가를 먼저 말해야 합니다.

둘째, 축들이 서로 물려 있습니다. 정확도를 올리려고 사고 과정을 길게 하면 지연과 비용이 함께 오릅니다. 검색 문서를 늘리면 근거는 좋아지지만 컨텍스트가 커져 비용이 오르고, 어느 지점부터는 오히려 관련 없는 내용이 섞여 품질이 내려갑니다. 한 축의 개선을 보고하면 듣는 쪽은 자연히 "그럼 다 좋아진 것"으로 받아들입니다. 이 오해가 나중에 신뢰를 깎습니다.

셋째, 전제가 자주 바뀝니다. 모델은 계속 갱신되고 가격도 바뀝니다. 6개월 전에 옳았던 결정이 지금은 옳지 않을 수 있습니다. 그래서 LLM 시스템의 결정 기록에는 일반적인 설계 문서에 없는 항목이 하나 더 필요합니다. 이 결정을 언제 다시 볼 것인가.

이 세 성질 때문에, 결정을 "무엇을 골랐다"로만 전달하면 반드시 나중에 다시 설명해야 합니다. 골격을 갖춰 남기는 편이 결국 시간을 아낍니다.

길 필요는 없습니다. 한 결정에 한 쪽이면 충분하고, 다음 다섯 가지가 빠지지 않으면 됩니다.

항목	무엇을 적는가	빠지면 생기는 일
맥락	어떤 제약 아래에서 이 결정이 필요했는가	나중에 "왜 이렇게 했지"가 반복된다
검토한 선택지	실제로 비교한 안과 각각의 측정값	검토하지 않은 것으로 오해받는다
기각 사유	왜 다른 안을 택하지 않았는가	같은 안이 몇 달 뒤 다시 제안된다
가역성	되돌리는 데 드는 비용과 시간	되돌릴 수 있는 결정에 과도한 논의가 붙는다
재검토 조건	무엇이 바뀌면 다시 보는가	낡은 결정이 그대로 굳는다

가역성을 명시하는 것은 논의 시간을 아끼는 데 특히 효과적입니다. 프롬프트 구조를 바꾸는 결정은 하루면 되돌릴 수 있고, 저장소와 인덱싱 방식을 바꾸는 결정은 몇 주가 듭니다. 되돌리기 쉬운 결정은 빨리 정하고 실측으로 확인하는 편이 낫고, 되돌리기 어려운 결정에 검토를 집중해야 합니다. 기록에 이 구분이 없으면 모든 결정이 같은 무게로 다뤄집니다.

재검토 조건은 LLM 시스템에서 사실상 필수 항목입니다. 조건은 막연한 시점이 아니라 관측 가능한 사건으로 적습니다.

• "현재 등급의 상위 모델 가격이 지금의 절반 아래로 내려가면"
• "월 요청량이 현재의 3배를 넘으면"
• "평가셋 정확도가 2회 연속 기준선 아래로 내려가면"

이렇게 적어 두면 결정 기록이 감시 목록의 역할을 겸합니다. 누군가 조건을 확인할 책임을 함께 적어 두면 더 좋습니다.

평가 결과를 전달할 때 가장 위험한 것은 단일 숫자입니다. "정확도 91%"라는 한 줄은 듣는 쪽에서 "10건 중 9건은 맞는다"로 번역되고, 그 번역은 대개 틀립니다. 다음 세 가지를 함께 제시하십시오.

표본과 그 출처. 몇 건에서 잰 숫자인지, 그 표본이 어떻게 만들어졌는지 밝힙니다. 200건 중 182건이라고 말하면, 듣는 쪽도 이 숫자가 얼마나 흔들릴 수 있는지 감을 잡습니다. 표본이 작을수록 이 정보가 중요합니다.

입력 분포. 평가셋이 운영 트래픽을 어떻게 반영했는지 한 줄로 적습니다. "상위 5개 문의 유형이 실제 비중과 같게 들어갔고, 월 1회 미만으로 들어오는 유형은 제외했다"처럼 쓰면 이 숫자가 어디까지 적용되는지가 분명해집니다.

꼬리와 최악. 지연은 평균이 아니라 p50과 p95를 함께 냅니다. 평균 응답이 좋아 보여도 p95가 나쁘면 사용자 절반 가까이가 불만을 갖습니다. 비용도 마찬가지로 요청당 평균과 함께 월 예상액과 최악의 달을 제시해야 예산 논의가 가능합니다.

세 축을 한눈에 비교하는 표를 만들어 두면 회의가 훨씬 짧아집니다.

안	평가셋 정확도 (200건)	p95 지연	요청당 비용	되돌리는 비용
현행 유지	88%	640ms	1배	없음
상위 모델	91%	1.5초	4배	낮음 (설정 변경)
검색 보강	93%	900ms	1.6배	중간 (인덱스 구축)

이런 표를 앞에 두면 "정확도가 높은 것을 쓰자"는 대화가 "3%p를 위해 지연 2.3배를 감당할 것인가"라는 대화로 바뀝니다. 후자가 실제로 해야 할 대화입니다.

한 가지 더. 정확도 차이를 보고할 때는 그 차이가 표본 크기에 비해 의미 있는지 함께 언급하십시오. 200건에서 88%와 91%는 건수로는 6건 차이입니다. 이 정도 차이를 확정적인 우열로 제시하면 나중에 순서가 뒤집혔을 때 설명이 궁색해집니다.

같은 결정도 듣는 사람에 따라 먼저 알아야 할 것이 다릅니다. 순서를 잘못 잡으면 내용이 옳아도 전달되지 않습니다.

청중	가장 먼저 알아야 할 것	흔한 실수
경영진	얼마가 들고, 틀리면 무엇을 잃고, 되돌릴 수 있는가	모델 구조와 프롬프트 기법부터 설명한다
제품 담당	무엇이 되고 무엇이 안 되는가, 언제 쓸 수 있는가	평균 성능만 말하고 실패 유형을 감춘다
보안·법무	데이터가 어디로 가고 무엇이 남는가, 누가 접근하는가	성능 이야기로 시작한다
운영팀	장애일 때 무엇을 보고 무엇을 할 수 있는가	인계 시점에야 처음 대화한다

경영진에게는 가역성이 특히 잘 통하는 언어입니다. "이 결정은 설정 변경으로 하루면 되돌릴 수 있습니다"라는 한 문장이 긴 기술 설명보다 결정을 빠르게 만듭니다.

제품 담당에게는 실패 유형을 먼저 말하는 편이 낫습니다. 무엇이 안 되는지 알아야 사용자 흐름을 설계할 수 있기 때문입니다. 실패를 감추고 시작하면, 나중에 발견될 때 신뢰가 크게 깎입니다.

운영팀은 인계 시점이 아니라 설계 시점부터 대화에 넣어야 합니다. 운영팀이 나중에 확인할 수 없는 지표는 설계 단계에서 애초에 만들어 두지 않으면 나중에 붙이기 어렵습니다. 무엇을 로그로 남길지, 이상을 어떻게 알아챌지는 아키텍처 결정의 일부입니다.

전달의 마지막 단계는 되읽기입니다. 회의가 끝날 때 결정된 것과 미뤄진 것을 세 줄로 요약해 그 자리에서 확인받으십시오. 문서로 나중에 보내는 것보다 그 자리에서 어긋남을 잡는 편이 훨씬 저렴합니다.