평가(eval)는 왜 중요한가: OpenAI가 품은 오픈소스 'promptfoo'로 들여다봤습니다

얼마 전 이 블로그에서 OpenAI Cookbook을 살펴보며, 평가(eval)가 조용히 떠오르는 갈래라고 적었습니다. 그래서 평가의 원조 격인 저장소 openai/evals를 열어 봤는데, 의외로 한산했습니다. 의미 있는 갱신은 2024년에 멈춰 있고, 안내문은 "이제 OpenAI 대시보드에서 직접 쓰라"고 가리킵니다. 원조가 조용해진 셈입니다.

그래서 질문을 바꿨습니다. 그러면 지금 평가의 에너지는 어디에 모여 있을까요. 저장소들의 별표와 최근 활동을 비교해 보니, 가장 활발하면서도 평가에 집중한 곳은 promptfoo였습니다. 그리고 들여다보다 한 문장에서 멈췄습니다. promptfoo가 자사 안내에서 "이제 OpenAI의 일부가 되었다"고 밝히고 있었기 때문입니다. 원조 저장소는 멈췄는데, OpenAI는 대신 바깥에서 가장 활발한 평가 도구를 품은 것입니다. 오늘은 이 promptfoo를 앵커 삼아, 평가가 무엇이고 왜 이렇게 중요해졌는지 적어 보려 합니다. 처음 보시는 분도 편하게 따라오실 수 있게 풀겠습니다.

평가(eval)가 무엇인가

평가는 쉽게 말해 AI 시스템을 위한 시험입니다. 한 번 잘 되는 시연(demo)이 아니라, 정해진 문제 묶음을 반복해서 풀려 보고 "얼마나 자주, 얼마나 정확히 맞히는가"를 숫자로 재는 일입니다. promptfoo의 소개 문구가 핵심을 찌릅니다. 시행착오 방식을 멈추고, 안전하고 믿을 수 있는 AI 앱을 출시하라는 것입니다.

왜 시험이 필요할까요. AI는 같은 질문에도 매번 조금씩 다르게 답합니다. 그래서 한 번 잘 됐다고 늘 잘 되는 게 아닙니다. 모델을 새 버전으로 바꾸거나, 프롬프트(모델에게 주는 지시문)를 손보거나, 검색 방식을 바꾸면 어딘가는 좋아지고 어딘가는 나빠집니다. 그걸 눈대중이 아니라 숫자로 봐야, 바꾼 것이 정말 나아진 것인지 알 수 있습니다.

promptfoo: 평가를 개발 흐름에 넣은 도구

promptfoo는 LLM 앱을 평가하고 레드티밍하는 명령줄 도구이자 라이브러리입니다. 글을 쓰는 시점 기준 별표가 2만 2천 개가 넘고, 자유롭게 쓸 수 있는 MIT 라이선스입니다. 작동 방식은 단순합니다. 설정 파일에 "이런 입력을 주고 이런 기준을 통과해야 한다"를 적어 두면, 여러 모델(GPT, Claude, Gemini, DeepSeek 등)에 같은 입력을 넣어 결과를 나란히 비교하고, 정해 둔 기준으로 점수를 매겨 표로 보여 줍니다.

기준(promptfoo에서는 assertion이라 부릅니다)에는 여러 종류가 있습니다. 정답과 정확히 일치하는지, 특정 문구가 포함됐는지 같은 단순한 것부터, 다른 모델을 심사위원처럼 써서 "이 답이 기준에 맞는지" 점수를 매기게 하는 방식까지 있습니다. 마지막 방식이 흥미로운데, AI의 답을 사람이 일일이 보지 않고 또 다른 AI가 평가하게 해 규모를 키우는 것입니다. 물론 평가하는 모델도 틀릴 수 있어 맹신은 금물입니다.

또 하나 중요한 특징은 이 평가를 개발 자동화 흐름(CI/CD)에 끼워 넣을 수 있다는 점입니다. 소프트웨어 개발에서 코드를 고칠 때마다 자동으로 시험이 돌듯, 프롬프트나 모델을 바꿀 때마다 평가가 자동으로 돌아 나빠진 곳을 잡아냅니다. 평가가 일회성 행사가 아니라 일상적 안전장치가 되는 것입니다. promptfoo가 OpenAI와 Anthropic에서도 쓰인다고 소개하는 걸 보면, 모델을 만드는 회사들조차 이런 도구에 기대고 있다는 뜻입니다.

그냥 평가가 아니라 '공격'까지: 레드티밍

promptfoo가 평범한 시험 도구와 다른 지점은 레드티밍(red teaming)입니다. 우리말로는 모의 공격에 가깝습니다. 보안에서 일부러 침입을 시도해 약점을 찾듯, AI 시스템에 일부러 위험한 입력을 던져 무너지는 지점을 미리 찾아내는 것입니다.

promptfoo는 이런 공격 입력을 자동으로 만들어 줍니다. 안전장치를 우회하려는 시도(흔히 탈옥이라 부릅니다), 숨겨야 할 개인정보를 토해 내게 하는 유도, 해로운 내용을 생성하게 만드는 함정 같은 것들입니다. 만들어 둔 AI에 이런 공격을 퍼부어 보고, 어디서 무너지는지 목록으로 돌려줍니다.

이게 중요한 이유는, AI가 점점 더 실제 권한을 갖기 때문입니다. 단순히 답만 하던 AI가 메일을 보내고, 코드를 실행하고, 결제를 다루는 에이전트로 바뀌면, 한 번의 잘못이 실제 피해로 이어집니다. 그래서 "잘 작동하는가"만큼이나 "공격에 무너지지 않는가"가 중요해집니다. 평가와 보안 점검이 한 도구 안에서 만난 것은 우연이 아니라고 봅니다.

원조는 조용한데, OpenAI는 왜 promptfoo를 품었나

여기서 앞의 이야기로 돌아갑니다. OpenAI가 2023년에 공개한 openai/evals는 평가라는 말을 널리 퍼뜨린 원조입니다. 별표가 1만 8천 개가 넘지만, 의미 있는 갱신은 2024년에 멈췄고 최근 석 달간은 거의 손대지 않았습니다. 대신 안내문은 호스티드(클라우드) 제품으로 사람들을 보냅니다.

그리고 promptfoo는 자사 안내에서 "이제 OpenAI의 일부가 되었다"고 밝힙니다. 오픈소스와 MIT 라이선스는 그대로 유지한다고 덧붙입니다. 저는 이 두 사실을 나란히 놓고 봅니다. 모델을 가장 잘 만드는 회사 중 하나가, 자신의 옛 평가 저장소를 더 키우는 대신 바깥에서 가장 활발한 평가·보안 도구를 품었다는 것입니다.

이건 평가가 더 이상 연구실의 곁가지가 아니라, 제품과 전략의 한복판으로 들어왔다는 신호로 읽힙니다. 좋은 모델을 만드는 일과, 그 모델이 제대로 또 안전하게 일하는지 측정하는 일이 떼어 놓을 수 없게 된 셈입니다.

그래서 왜 중요한가

평가의 중요성은 한 문장으로 줄일 수 있습니다. 측정할 수 없으면 개선할 수 없습니다. AI는 눈대중으로는 좋아졌는지 나빠졌는지 알기 어렵습니다. 평가는 그 막연함을 숫자로 바꿔 줍니다.

앞서 이 블로그에서 다룬 'Code as Agent Harness' 논문도 결국 같은 곳을 가리켰습니다. 그 논문이 꼽은 가장 어려운 숙제 중 하나가 바로, 최종 성공 여부만으로는 부족한 평가와 불완전한 상황에서의 검증이었습니다. 에이전트가 실제 업무에 들어갈수록, "한 번 잘 된다"와 "믿고 맡길 수 있다" 사이의 거리를 메우는 일이 핵심이 됩니다. 그 거리를 메우는 장치가 바로 평가입니다.

창업자·투자자라면

창업자에게 평가는 두 가지를 동시에 줍니다. 속도와 안전입니다. 평가 체계가 있으면 프롬프트나 모델을 과감히 바꿔 보고도 무엇이 나빠졌는지 바로 알 수 있어 빠르게 움직일 수 있습니다. 동시에 레드티밍으로 약점을 미리 막으면, 사고가 터진 뒤가 아니라 터지기 전에 손쓸 수 있습니다. 특히 자기 도메인에 맞춰 직접 만든 비공개 평가셋은 쉽게 베껴지지 않는 자산이 됩니다. 무엇을 "잘한 것"으로 볼지에 대한 그 회사만의 기준이 담기기 때문입니다.

투자자에게는 두 가지로 읽힙니다. 하나는 옥석을 가리는 잣대입니다. AI 회사를 볼 때 저는 그 팀이 시연을 보여 주는 팀인지, 측정을 보여 주는 팀인지를 눈여겨봅니다. 자기 제품을 숫자로 설명할 수 있는 팀은 대체로 더 단단합니다. 다른 하나는 시장 자체입니다. OpenAI가 promptfoo를 품고, 모델을 만드는 회사들조차 이런 도구를 쓴다는 건, 평가·보안 레이어가 그 자체로 의미 있는 시장이라는 뜻입니다. 응용 단계의 도구에는 기회이고, 이 레이어를 가볍게 보는 전략에는 리스크로 읽힙니다.

한 줄 요약

평가(eval)는 AI를 시연이 아니라 측정의 대상으로 바꾸는 일입니다. promptfoo는 그 측정을 개발 흐름에 넣고, 한 걸음 더 나아가 일부러 공격해 약점까지 찾습니다. 원조 openai/evals가 조용해진 사이 OpenAI가 promptfoo를 품은 장면은, 평가가 곁가지에서 한복판으로 옮겨 왔음을 보여 줍니다. 제가 가져가는 한 가지는 이렇습니다. AI의 경쟁력은 점점 "얼마나 잘 만드느냐"만이 아니라 "얼마나 잘 측정하고 지키느냐"에서 갈릴 가능성이 높습니다.

(이 글은 특정 종목이나 투자에 대한 권유가 아니라, 제 관점을 담은 정보 공유 차원의 글입니다.)