아아, 정말 덥네요! AI에 대한 열기와 함께 LLM을 포함한 기능을 개발하는 일이 점점 늘어나고 있는 요즘입니다.

생성형 AI 앱 개발에 있어 모델 선정은 중요하지만, 더 중요한 것이 있다

LLM을 포함한 생성형 AI 앱 개발에 있어서 어떤 모델을 사용할지는 중요하죠. 저는 모델 선정에 한 달을 쏟은 적도 있습니다.

하지만 돌이켜 생각해 보면, 더 중요한 것이 있습니다. 그것은 바로 평가입니다!

모델 선정보다, 요구사항 정의 단계에서 평가 항목을 정해라

어떤 문서를 검색해서 답하는 RAG (Retrieval-Augmented Generation) 챗봇을 만들었을 때, GPT와 Claude와 Gemini를 나란히 비교하는 스프레드시트를 만들고, 벤치마크 기사를 샅샅이 읽으며, 미팅에서는 "이 모델이 더 똑똑하다"라고 열변을 토했습니다. 모델 원리주의자인 저는 모델만 틀리지 않는다면 철두철미하게 좋은 것을 만들 수 있다고 믿었습니다.

그런데, 만반의 준비를 마치고 선택한 모델로 출시 전 데모를 진행하던 중, 지난주와 똑같은 질문을 했는데 미묘하게 다르거나, 심지어 일부 틀린 답이 돌아와서 저는 식은땀을 흘렸습니다.

"지난주에는 제대로 대답했는데, 왜 이렇죠?"라는 질문을 받고, 제대로 대답하지 못한 채 우물쭈물했습니다.

한 달 동안 만든 모델 비교 자료는 아무런 도움이 되지 않았습니다 ＞＜

이 글에서는 그때 뼈저리게 느낀 생성형 AI 앱의 품질 보증은 기존의 소프트웨어와 근본적으로 다르다는 이야기를 쓰겠습니다.

결론부터 말씀드리자면, 이 글에서 가장 하고 싶은 말은 모델 선정에 시간을 쏟을 여유가 있다면 요구사항 정의 단계에서 평가 항목을 정해라! 입니다.

생성형 AI 앱은 "주사위를 던지는 소프트웨어"

기존의 소프트웨어는 결정론적 (Deterministic)

기존의 소프트웨어는 결정론적입니다. 동일한 입력을 주면 반드시 동일한 출력이 돌아옵니다.

자판기와 마찬가지로, 버튼을 누르면 항상 같은 음료수가 나오기 때문에 '버튼 A를 누르면 음료수 A가 나온다'라는 테스트를 작성할 수 있습니다.

AI 앱은 확률적 (Probabilistic)

반면, LLM을 포함한 앱은 확률적입니다. LLM은 다음에 올 단어를 확률 분포 (Probability Distribution)에서 선택하기 때문에, 동일한 입력이라도 출력이 매번 달라집니다.

자판기라기보다는 실력 있는 요리사에 가깝습니다.

"늘 먹던 걸로"라고 주문해도, 그날의 식재료나 기분에 따라 담음새와 간이 미묘하게 달라집니다.

대체로 맛있지만, 완전히 똑같은 접시는 두 번 다시 나오지 않습니다.

내부 처리의 블랙박스화 (Black Box)

더 까다로운 것은 내부 처리의 블랙박스화입니다.

기존의 코드라면 디버거 (Debugger)로 스텝 실행을 하여 이 행의 이 분기(Branch)가 잘못되었다고 특정할 수 있지만, LLM 내부에서 무엇이 일어나고 있는지는 만든 당사자들도 알 수 없습니다.

수천억 개의 파라미터 (Parameter) 계산 결과라고밖에 말할 수 없으며, 왜 이 답이 나왔는지를 밝혀낼 수단이 원리적으로 없습니다.

저도 처음에는 운영 로그를 뚫어지게 쳐다보며 원인을 찾으려 했지만, 시간 낭비였습니다.

한 건씩 원인을 제거하겠다는 발상을 버리고, "전체적으로 몇 퍼센트가 좋은 출력인가"를 통계적으로 측정하는 발상으로 전환해야 합니다.

즉, 생성형 AI 앱에서는 다음 세 가지가 동시에 무너집니다.

재현성 (Reproducibility): 동일한 입력이라도 동일한 출력이 보장되지 않음 -
설명 가능성 (Explainability): 왜 그런 출력이 되었는지 추적할 수 없음 -
정답의 일의성 (Uniqueness of Correct Answer): 애초에 "올바른 출력"이 하나로 정해지지 않음

"assert로 기대값과 완전히 일치하는지 확인한다"라는 기존의 테스트 발상이 근본적으로 통하지 않습니다.

테스트와 평가의 차이는 무엇인가

여기서 테스트와 평가에 대해 정리하겠습니다.

저는 이 두 가지의 구분을 하지 못했고, 똑똑한 모델을 고르면 품질이 올라갈 것이라고 착각하고 있었습니다.

테스트는 합격/불합격 판정입니다.

"입력 X에 대해 출력 Y가 반환될 것"이라는 사양(Specification)이 있고, 일치하면 합격, 일치하지 않으면 불합격이라는 O/X의 세계입니다.

산수 문제의 정답 확인과 같아서, 답은 하나로 정해져 있습니다.

평가는 채점입니다.

"이 출력은 어느 정도 좋은가"를 여러 관점에서 스코어링 (Scoring) 합니다.

국어 작문 채점에 가까워서, "오타는 없는가", "주제에 부합하는가", "논리가 통하는가"라는 관점마다 점수를 매깁니다.

만점 답안은 하나가 아니며, 80점짜리 답안은 몇 가지라도 존재할 수 있습니다.

생성형 AI 앱에 필요한 것은 테스트가 아니라 평가입니다.

정답이 하나로 정해지지 않는 이상, "정답과 일치하는가"가 아니라 좋은 출력의 조건을 얼마나 충족하는지를 측정할 수밖에 없기 때문입니다.

그렇다면 구체적으로 어떻게 평가할까요?

LangChain이 정리하고 있는 평가 기법이 참고가 됩니다.

• 휴리스틱 평가 (Heuristic Evaluation): 출력이 JSON으로 파싱 가능한지, 글자 수 제한 내에 있는지와 같은 규칙 기반(Rule-based) 체크. 이 부분은 기존의 테스트와 유사하며 자동화하기 쉽습니다.
• 인간 평가 (Human Evaluation): 사람이 출력을 읽고 채점합니다. 정확도는 높지만 확장성(Scale)이 떨어집니다.
• LLM-as-a-Judge: 채점 기준을 프롬프트에 작성하여, 별도의 LLM이 채점하게 합니다. 인간 평가의 자동화 버전입니다.
• 데이터셋 평가 (Dataset Evaluation): 예상 질문과 기대되는 답변의 쌍을 준비해 두고, 이를 일괄 실행하여 스코어의 추이를 추적합니다.

실무에서 주력이 되는 것은 LLM-as-a-Judge입니다.

요령은 5단계 평가와 같은 모호한 스코어로 만들지 말고, "사실과 모순되지 않는가: 예/아니오"와 같이 이진(Binary) 질문으로 분해하는 것입니다.

LLM에게 "이 답변은 몇 점인가요?"라고 물으면 채점이 매우 흔들리지만, "예/아니오"라면 정밀도가 높습니다.

그리고 이 평가는 출시 전에 한 번 하고 끝내는 것이 아닙니다.

개발 중에는 프롬프트를 변경할 때마다 데이터셋으로 회귀 테스트(Regression Check)를 수행하고, 출시 후에는 운영 로그를 샘플링하여 계속해서 평가합니다.

요리사의 비유로 돌아가면, 개점 전 시식뿐만 아니라 영업 중에도 계속해서 맛을 보는 담당자를 두는 이미지입니다.

요구사항 정의 단계에서 평가 항목을 결정하라

이 부분이 이 글에서 가장 하고 싶은 말입니다.

이 글 서두의 챗봇 데모 실패 이후, 저는 평가 체계를 서둘러 사후에 추가하려고 했지만, 그 순간 제가 매우 위험한 상황에 빠져 있다는 것을 깨달았습니다.

그때 처음으로, "좋은 답변이란 무엇인가"를 아무도 정의하지 않았다는 사실을 깨달았기 때문입니다.

제품 개발에는 다양한 사람들이 관여합니다. 기획 측은 "정확하게 답해주길 바란다"고 하고, 영업 측은 "다소 모호하더라도 친근한 문구면 좋겠다"고 하며, 법무 측은 "단정적인 표현은 모두 안 된다"고 합니다. 모두 제각각 말합니다.

출시 후에 이 작업을 하면, 모든 사람의 "왠지 품질이 나쁘다"라는 감각과 감정론에 맞서 싸우게 됩니다. 기준이 없기 때문에, 수정해도 고쳐진 것인지 아닌지조차 아무도 판단할 수 없습니다.

기존 개발에서도 "테스트 관점은 설계 시에 결정합시다"라고 말하지만, 생성형 AI 앱에서는 이것이 노력 목표가 아니라 필수적인 전제 조건이 됩니다.

이유는 단순합니다. 평가 항목을 결정하는 것이 곧 요구사항을 결정하는 것이기 때문입니다.

예를 들어, "정확성: 참조 문서와 모순되지 않음", "안전성: 단정적인 법적 조언을 하지 않음", "톤(Tone): 경어체를 사용함"이라고 적어 내려가는 순간, 그것이 그대로 제품의 사양서가 되고, LLM-as-a-Judge의 채점 프롬프트가 되며, 출시 판정의 기준이 됩니다.

여기까지 오면, 서두에서 제가 모델 선정에 아무런 도움이 되지 않았던 이유도 알 수 있습니다.

비교하기 위한 척도를 가지고 있지 않았기 때문입니다.

일반적인 벤치마크에서 똑똑한 모델이 해당 제품의 태스크(Task)에서 강하다고 단정할 수 없습니다.

평가 항목과 데이터셋만 갖춰져 있었다면, 모델 선정은 한 달간의 논의가 아니라, 후보 모델을 교체하며 스코어를 비교하는 몇 시간의 측정만으로 끝났을 것입니다.

역으로 말하면, 평가 항목을 써 내려갈 수 없는 기능은 요구사항이 확정되지 않은 기능입니다.

"AI로 적절하게 요약한다"라는 요구사항인 채로 개발을 시작하면, "적절하게"의 정의를 둘러싸고 반드시 나중에 갈등이 생깁니다. 이는 AI 제품 개발의 안티 패턴(Anti-pattern)이라고 해도 과언이 아닙니다! 저는 다시는 평가 항목이 없는 생성형 AI 프로젝트는 하지 않겠다고 마음먹었습니다.

평가 관점이 고민된다면 ISO/IEC 25059를 보라

그렇다고는 해도, 갑자기 "평가 항목을 써 내려가라"고 하면 무엇을 관점으로 삼아야 할지 모를 것입니다. 저도 처음에는 갈피를 잡지 못했습니다.

그때 초안으로서 도움이 되는 것이 ISO/IEC 25059:2023라는, AI 시스템을 위한 제품 품질 모델의 국제 표준입니다.

위 내용은 우수하므로, 아래의 note 해설 기사나 산총연(AIST)의 "생성형 AI 품질 매니지먼트 가이드라인"은 ISO/IEC 25059를 베이스로 일본의 LLM 이용 시스템에 맞춰 구체화·실천화한 가이드라인이므로 참고가 될 수 있습니다.

흥미로운 점은 이 표준이 기존의 소프트웨어 품질 모델(ISO/IEC 25010)을 그대로 사용하지 않고 AI에 맞춰 정의를 바꾸었다는 점입니다.

예를 들어 기능적 정확성은 "항상 옳은 것"이 아니라 "요구되는 정밀도 범위 내에서 옳은 것"으로 정의되어 있습니다.

국제 표준조차도 AI는 100%의 정확성을 보장할 수 없다는 전제 위에 서 있는 것입니다.

"정답률 100%를 목표로 합니다"라는 요구사항 자체가 애초에 성립하지 않는다는 점에 대한 좋은 근거가 됩니다.

이 표준에는 생성형 AI 앱의 평가 항목을 생각할 때 힌트가 될 특성들이 나열되어 있습니다.

• 기능 정확성 (Functional Correctness): 요구되는 정밀도 범위 내에서 올바른 출력을 반환하는가 -
  강건성 (Robustness): 프롬프트 인젝션 (Prompt Injection)과 같은 의도적인 공격이나 예상치 못한 입력에 견딜 수 있는가 -
  투명성 (Transparency): 학습 데이터나 제약 조건이 이해관계자에게 적절히 전달되고 있는가 -
  사용자 제어성 (User Controllability): 사용자가 출력을 수정하거나 AI의 제안을 덮어쓸 수 있는가 -
  개입성 (Intervenability): 문제를 감지했을 때, 운영 측에서 위해를 방지하기 위한 개입을 즉시 할 수 있는가

전부를 채택할 필요는 없습니다. 예를 들어, 요구사항 정의 (Requirements Definition) 킥오프 단계에서 "이 프로덕트에서는 어떤 항목이 유효한가"를 관계자들과 하나씩 검토해 나가는 체크리스트로 사용하면 좋습니다. 처음부터 관점을 발명하는 것보다 훨씬 빠르게 합의에 도달할 수 있습니다.

요약

• 생성형 AI 앱은 확률적으로 동작하므로, 기대치 일치 여부만을 확인하는 테스트만으로는 품질을 보장할 수 없다
• 필요한 것은 합격/불합격을 판정하는 "테스트 (Test)"가 아니라, 관점별로 점수를 매기는 "평가 (Evaluation)"
• 평가는 휴리스틱 (Heuristic), 인간 평가 (Human Evaluation), LLM-as-a-Judge, 데이터셋 평가를 조합한다. LLM-as-a-Judge는 예/아니오 질문으로 분해하는 것이 안정적이다
• 평가 관점이 고민된다면, ISO/IEC 25059의 품질 특성을 체크리스트의 초안으로 활용한다
• 모델 선정 또한, 평가 항목과 데이터셋이라는 척도가 있어야 비로소 결론을 내릴 수 있다
• 그리고 무엇보다, 평가 항목은 요구사항 정의 단계에서 결정한다. 평가 항목을 결정하는 것이 생성형 AI 앱의 요구사항 정의 그 자체다

당신의 프로젝트에서 '좋은 출력'에 대한 정의는 이미 문서화되어 있습니까?

그렇지 않다면, 모델 선정에 앞서 우선 그 작업부터 시작하는 것이 좋다고 생각합니다.

Discussion