벤치마크는 좋은데, 실제로는 왜 자꾸 뭔가 빠질까?

왜 이제 이 이야기를 꺼내는가

원문을 확인해본 결과, GitHub이 올린 글의 핵심은 생각보다 단순했습니다. “벤치마크(benchmark)에서 잘 나온 언어 모델(language model)이 실제 운영(production) 환경에서는 자꾸 예상과 다르게 작동한다”는 관찰입니다.

이건 기술 업계가 처음 마주친 문제는 아닙니다. 하지만 지난 35년을 보면서 느낀 점이 있다면, 매 기술 물결마다 이 같은 간극(gap)이 반복된다는 겁니다. 통계 모델에서 시작한 머신러닝이 웹으로 나가던 2010년대 초반, 마찬가지 문제를 겪었거든요. 그때는 “실험실에선 되는데 서버에서는 왜 안 되나” 하고 답답해하던 개발자들이 많았습니다.

지금 GitHub의 포스트가 중요한 이유는, 그 간극이 단순한 ‘버그’가 아니라 평가 방식 자체의 문제(evaluation problem)라고 명시했다는 점입니다. 이는 자동화 운영자나 1인 개발자에게 무척 실질적인 메시지입니다.

깔끔한 테스트와 지저분한 현실 사이

원문은 GitHub이 직접 만난 사례를 들었습니다. 시크릿 스캐닝(secret scanning)—즉, 저장소에 실수로 올라간 토큰이나 키 같은 민감한 정보를 찾아내는 일입니다.

여기서 문제가 생겼습니다. LLM이 “이건 진짜 시크릿이고, 이건 가짜 시크릿이야” 하고 분류하는 건 테스트 데이터(curated dataset)에서는 꽤 잘했습니다. 하지만 실제 코드를 보면 상황은 달랐습니다:

• 입력이 명확하지 않음 (ambiguous)
• 라벨 표기가 일관성이 없음 (labels may be inconsistent)
• 중요한 맥락이 빠져있거나 잘려 있음 (missing or truncated)
• 실제 환경의 데이터 분포가 테스트 환경과 다름 (evaluation set may not reflect production distribution)

이걸 읽고 있으면, n8n이나 Zapier 같은 자동화 플랫폼을 운영해본 경험이 떠오릅니다. API 연결이 테스트 환경에서는 완벽한데, 실제 고객 데이터가 들어오는 순간 “왜 이 필드가 비어있지?”, “이 값의 형식이 우리 예상과 다른데?” 같은 메시지들이 쏟아지는 거죠.

GitHub의 사례에서 핵심은 더 깊습니다. 단순히 “데이터가 지저분하다”는 게 아니라, 보안 워크플로우(security workflow) 같은 실제 결정을 해야 한다는 점입니다. 거짓양성(false positive)을 너무 많이 줄이면 진짜 위험을 놓칠 수 있고, 거짓양성을 덜 제거하면 개발자가 헛일에 시간을 낭비합니다.

무엇을 먼저 봐야 하는가

원문의 첫 번째 조언이 흥미롭습니다: “모델을 먼저 조정하려고 하지 말고, 무엇을 결정해야 하는지를 먼저 정의하라(Start with the product decision, not the model).”

이건 역설적으로 들립니다. LLM 시스템을 만드는데, LLM을 만지지 말라니요? 하지만 읽어보면 논리가 명확합니다.

팀이 성과가 떨어진다고 생각되면, 대부분 프롬프트(prompt)를 다시 쓰거나, 문맥을 추가하거나, 모델을 바꾸는 식으로 접근합니다. 하지만 GitHub의 관찰은 이겁니다: 먼저 우리가 정말로 원하는 결과가 무엇인지 명확히 해야 한다는 것입니다.

보안 팀은 “정확도가 95%인 분류기”를 원하는 게 아니라, “고개발자 시간을 낭비하지 않으면서도 실제 보안 위험은 놓치지 않는 시스템”을 원합니다. 이건 전혀 다른 평가 기준입니다.

1인 자동화 운영자나 스타트업 개발자 입장에서 보면, 이건 매우 현실적인 조언입니다. n8n 워크플로우를 만들 때도, LLM을 붙일 때도, “이게 정확한가?”가 아니라 “이게 비즈니스 결과를 나아지게 하는가?”를 먼저 물어야 한다는 뜻입니다.

남아있는 질문들

하지만 여기서 논쟁의 여지가 남아있습니다.

“제품 결정을 먼저 정의한다”는 것이 이론상으로는 맞지만, 실제로 중소 팀이 운영할 때는 어떻게 실행하나요? 특히 자동화 엔지니어가 혼자 여러 LLM 연동을 맡고 있을 때, 매번 이런 식의 ‘메타 평가(meta-evaluation)’를 하고 들어갈 수 있을까요? 시간과 리소스 측면에서 현실적인지가 계속 지켜봐야 할 지점입니다.

또 다른 질문은, GitHub이 제시한 이 평가 방식이 얼마나 일반화(generalize)될 수 있느냐는 겁니다. 보안 분야 같이 “거짓음성의 대가가 크다”는 도메인에서는 이 원칙이 잘 작동하겠지만, 이메일 자동 분류나 이미지 태깅 같은 다른 영역에서도 같은 방식이 먹혀들까요?

이 이슈는 다음 편에서 GitHub이 구체적으로 제시한 평가 방법론들(offline metrics, human review, production monitoring 등)을 어떻게 실제 워크플로우에 녹여낼 수 있는지 살펴보겠습니다.