평가·시험·최적화 — 성능을 증거로 바꾸는 설계

4.1 평가 지표 정의 — 정확도만으로는 부족합니다

'좋아 보인다'는 인상을 운영 가능한 숫자로 바꾸는 일이 평가의 출발입니다. 아키텍트는 정확도(accuracy, 답이 기준과 얼마나 일치하는가)만이 아니라 지연시간(latency, 응답까지 걸리는 시간), 요청당 비용, 안전성(safety, 유해하거나 부적절한 출력을 막았는가), 보안(security, 민감정보 유출과 프롬프트 주입 방어)까지 각각의 합격선을 정해야 합니다. 지표는 하나가 아니라 묶음으로 함께 움직이며, 서비스 수준 목표(SLO)에 연결될 때 비로소 운영의 언어가 됩니다. 어디까지 허용할지 먼저 합의하지 않으면 개선은 방향 없는 손질에 그칩니다.

4.2 평가용 데이터셋과 시험 틀 — 채점 방식을 섞습니다

믿을 수 있는 평가는 대표성 있는 정답셋(golden set, 기대 답을 미리 정해 둔 검사용 묶음)에서 시작합니다. 여기에 자주 나오는 경우뿐 아니라 드물지만 위험한 경계 상황을 반드시 담아야 합니다. 채점은 한 방식에 기대지 않습니다. 규칙 기반 자동 채점(형식·키워드가 정확히 맞는가), 모델을 심판으로 쓰는 LLM-as-judge(모델이 답의 품질을 평가), 그리고 도메인 전문가의 직접 검수를 함께 씁니다. 자동 채점은 규모를, 전문가 검수는 미묘한 판단을 담당하며, 둘을 겹쳐 볼 때 사각지대가 줄어듭니다.

4.3 A/B 시험과 반복 개선 — 바꾸기 전후를 비교합니다

프롬프트나 모델을 바꿨을 때 정말 나아졌는지는 실제 사용 상황에서 두 버전을 나란히 비교해야 알 수 있습니다. A/B 시험(A/B testing, 사용자를 두 갈래로 나눠 각기 다른 버전을 보여주고 결과를 견주는 방법)은 이 판단의 표준 도구입니다. 다만 표본이 충분히 쌓여 통계적으로 의미 있는 차이인지 확인해야 하고, 목표 지표만이 아니라 함께 무너지면 안 되는 보호 지표(guardrail, 비용·안전성 등)를 같이 지켜봐야 합니다. 배포 전 정답셋 평가로 큰 회귀를 먼저 거른 뒤, 실사용 비교로 마무리하는 2단 구조가 안전합니다.

4.4 무엇이 잘못됐는지 가려내기 — 프롬프트·환각·모델 선택

장애가 났을 때 원인을 정확히 짚는 능력이 아키텍트의 값어치입니다. 지시가 모호하거나 서로 충돌하는 프롬프트 결함, 근거 없는 내용을 그럴듯하게 지어내는 환각(hallucination), 작업 난도에 견줘 지나치게 작거나 큰 모델을 고른 모델 선택 오류는 겉으로 비슷해 보여도 처방이 다릅니다. 특히 검색으로 근거를 대는 구조(RAG)에서는 검색이 틀린 문서를 가져온 것인지, 문서는 맞는데 생성 단계가 잘못 읽은 것인지부터 갈라야 합니다. 원인을 뭉뚱그리면 엉뚱한 곳을 고치게 됩니다.

4.5 토큰·지연·비용의 균형 잡기

품질을 지키면서 운영 원가를 낮추는 일은 상충 관계를 다루는 설계입니다. 반복되는 긴 지시나 참고 문서는 prompt caching(반복 입력을 다시 계산하지 않고 재사용해 비용과 지연을 함께 줄이는 기능)으로 아낄 수 있고, 작업 난도에 맞춰 상위·하위 모델을 나눠 배치하면 쉬운 요청에 비싼 모델을 쓰는 낭비를 막습니다. 컨텍스트에 넣는 문서를 필요한 만큼만 추리면 토큰이 줄고, 스트리밍(streaming, 답을 조각으로 먼저 흘려보내기)은 총 시간은 그대로여도 체감 지연을 크게 낮춥니다. 정답은 없고, 서비스 성격에 맞는 지점을 고르는 판단이 있을 뿐입니다.

4.6 운영 관측 — 배포한 뒤에도 계속 지켜봅니다

평가는 배포 전 한 번으로 끝나지 않습니다. 실제 트래픽은 검사 때 예상하지 못한 입력을 계속 만들어 내기 때문에, 운영 중 상태를 들여다보는 관측성(observability) 체계가 필요합니다. 요청과 응답, 지연·비용, 사용자 피드백을 남긴 기록(log)을 바탕으로 시간이 지나며 품질이 서서히 어긋나는 성능 표류(drift)를 감지하고, 정해 둔 선을 넘으면 담당 엔지니어에게 알림이 가도록 설계합니다. 여기서 모인 실제 실패 사례는 다시 정답셋으로 돌아가, 다음 평가를 더 촘촘하게 만드는 되먹임 고리를 이룹니다.

! 흔한 함정

• 배포 전 정답셋에서 좋았던 프롬프트가 실사용에서 무너지는데, 운영 중 관측 없이 한 번의 평가로 끝났다고 여기는 것 — 평가는 배포 후에도 이어집니다.
• 정확도 한 지표만 끌어올리다 지연·비용·안전성이 함께 내려앉는 것을 놓치는 것. 지표는 언제나 묶음으로 봐야 합니다.
• 모델을 심판으로 쓰는 자동 채점(LLM-as-judge)을 만능으로 믿고, 위험이 걸린 판단까지 도메인 전문가 검수를 생략하는 것.
• 환각을 무조건 프롬프트 탓으로 돌려, 검색이 틀린 근거를 가져온 구조적 결함을 지나쳐 버리는 것.