Promptfoo 분석: LLM 평가와 레드팀을 한 번에 다루는 개발자 중심 AI 테스트 플랫폼

promptfoo는 LLM 애플리케이션을 위한 평가(eval), 레드팀(red teaming), 취약점 스캐닝, CI/CD 자동화를 한데 묶은 오픈소스 CLI이자 라이브러리입니다. 저장소 README와 공식 문서는 이 프로젝트를 “프롬프트, 모델, RAG, 에이전트를 시험하고 보안 점검하는 도구”로 설명하고 있습니다. GitHub 기준으로 저장소는 2026년 3월 9일 기준 최신 릴리스가 0.121.1이고, 약 11.8k 스타를 보유하고 있습니다. (GitHub)

 

promptfoo/README.md at main · promptfoo/promptfoo

 

Promptfoo를 한 문장으로 요약하면 이렇습니다.

“감(感)으로 프롬프트를 튜닝하지 말고, 테스트 케이스와 보안 시나리오로 LLM 시스템을 검증하자.” (Promptfoo)

---

프로젝트 소개

Promptfoo는 원래 Ian Webster가 만든 오픈소스 프로젝트이며, 현재 공식 소개 페이지에서는 공동 창업자 Ian Webster와 Michael D'Angelo가 이끄는 AI 보안 회사의 핵심 제품으로 소개됩니다. Ian Webster는 과거 Discord에서 LLM 엔지니어링과 개발자 플랫폼 팀을 이끌었다고 명시되어 있습니다. package.json에도 author가 Ian Webster로 표시됩니다. (Promptfoo)

이 프로젝트의 목적은 명확합니다.

• 프롬프트 품질을 반복적으로 검증하고
• 모델 간 성능을 비교하고
• RAG/에이전트의 실패 케이스를 찾고
• 배포 전에 보안 취약점을 자동으로 찾아내는 것 입니다. (GitHub)

공식 문서가 강조하는 핵심 포인트는 다음과 같습니다.

• 사용 사례별 벤치마크를 정의할 수 있음
• 자동화된 assertion과 metric으로 결과를 채점할 수 있음
• 캐싱, 동시성, live reload로 평가 속도를 높일 수 있음
• CLI, 라이브러리, CI/CD 형태로 모두 활용 가능함
• OpenAI, Anthropic, Azure, Google, HuggingFace, Llama 계열, 커스텀 API까지 폭넓게 연결 가능함 (Promptfoo)

---

왜 이 프로젝트가 등장했을까

LLM 애플리케이션 개발은 전통적인 백엔드 테스트와는 결이 다릅니다.

보통 웹 API라면 “입력 → 출력”이 비교적 결정적입니다. 하지만 LLM은 다음 문제를 가집니다.

1. 출력이 비결정적입니다.
   같은 입력에도 답변이 조금씩 달라질 수 있습니다.
2. 정답 판별이 어렵습니다.
   문자열 exact match만으로는 좋은 답변인지 평가하기 어렵습니다.
3. 보안 문제가 애플리케이션 레벨에서 발생합니다.
   프롬프트 인젝션, jailbreak, 데이터 유출, tool misuse 같은 문제는 일반 정적 분석기만으로 찾기 어렵습니다. (Promptfoo)

Promptfoo는 바로 이 틈을 메우려 합니다. 공식 문서가 말하듯 철학은 trial-and-error가 아니라 test-driven LLM development입니다. 즉, “프롬프트를 몇 번 바꿔보고 느낌상 좋아 보이면 배포”하는 방식을 버리고, 명시적인 테스트 세트와 점수 기준으로 모델 동작을 검증하자는 접근입니다. (Promptfoo)

이 배경은 창업자 소개와 인터뷰성 자료에서도 일관됩니다. Discord처럼 대규모 AI 제품을 운영하면서, 기존 보안 도구가 프롬프트 인젝션이나 에이전트 권한 오남용 같은 문제를 다루지 못한다는 현실이 Promptfoo의 출발점이었다고 설명됩니다. (Promptfoo)

---

Promptfoo가 해결하는 문제

개발자 관점에서 보면 Promptfoo는 세 가지 층위를 한 번에 해결합니다.

1) 품질 평가

“이 프롬프트가 더 좋은가?”를 눈으로만 보지 않고 테스트 케이스로 비교합니다.
예를 들어 요약 정확도, JSON 형식 준수, 톤앤매너, 사실성, 비용, 응답 길이 등을 assertion으로 채점할 수 있습니다. (Promptfoo)

2) 시스템 회귀 테스트

프롬프트 수정, 모델 교체, temperature 조정, RAG 문서 변경 후 기존 동작이 깨졌는지 확인합니다.
즉, 프롬프트도 코드처럼 회귀 테스트 대상이 됩니다. (GitHub)

3) 공격자 시점 보안 테스트

Promptfoo의 red teaming은 단순히 정해진 jailbreak 문장 몇 개를 던지는 수준이 아닙니다.
공식 문서에 따르면 plugins가 악성 입력을 만들고, strategies가 그것을 어떤 방식으로 전달할지 정합니다. 특히 Meta Agent와 Hydra 같은 적응형 전략을 통해 단일 턴/멀티 턴 공격을 수행합니다. (Promptfoo)

---

핵심 기능

1. 선언형 평가 구성

Promptfoo의 가장 큰 장점은 YAML 중심 선언형 설정입니다.
간단한 테스트는 promptfooconfig.yaml만으로 바로 시작할 수 있습니다. 공식 예제 simple-test도 같은 방식을 사용합니다. (GitHub)

예를 들면 이런 형태입니다.

description: Basic assertion types and test case fundamentals

prompts:
  - file://prompts.txt

providers:
  - openai:gpt-5-mini

tests:
  - description: Check for exact match
    vars:
      body: Yes
    assert:
      - type: equals
        value: Yarr

  - description: Check if output is JSON
    vars:
      body: Output the story of your life in JSON
    assert:
      - type: is-json

  - description: Use LLM to evaluate output
    vars:
      body: The quick brown fox jumps over the lazy dog
    assert:
      - type: llm-rubric
        value: Is spoken like a pirate

이 방식의 장점은 분명합니다.

• 테스트 케이스를 코드가 아닌 데이터처럼 관리 가능
• 모델과 프롬프트를 바꾸어도 설정 재사용 가능
• Git diff로 변경 이력을 추적하기 쉬움
• CI에서 실행하기 쉬움 (GitHub)

---

2. 다양한 Assertion / Metric 지원

Promptfoo는 단순 문자열 비교를 넘어서 여러 수준의 판정을 지원합니다.

• deterministic assertion: equals, contains, is-json, cost 등
• model-graded assertion: llm-rubric
• context 기반 RAG 평가: context-recall, context-relevance, context-faithfulness
• 사용자 정의 스크립트: JavaScript / Python assertion (Promptfoo)

이게 중요한 이유는, LLM 평가는 결국 “좋은 답변”의 정의를 프로젝트별로 다르게 가져가야 하기 때문입니다.

예를 들어:

• 고객센터 봇이면 정책 준수와 친절함
• RAG 검색이면 근거 문맥 충실성
• 코드 생성이면 형식 정확성과 실행 가능성
• 요약 시스템이면 핵심 정보 보존과 길이 제한

Promptfoo는 이 기준들을 assertion 집합으로 조합하게 해 줍니다. (Promptfoo)

---

3. 모델 비교와 프롬프트 A/B 테스트

공식 README와 examples 폴더를 보면 Promptfoo는 다양한 모델 비교 예제를 제공합니다.
예제에는 OpenAI, Claude, Gemini, Llama, Mistral, Bedrock, Azure 등 여러 provider와 비교 실험이 포함되어 있습니다. (GitHub)

즉 개발자는 다음 같은 질문에 답할 수 있습니다.

• GPT-5-mini와 GPT-5 중 어떤 모델이 우리 use case에 더 낫나?
• temperature 0.2와 0.8 중 어느 쪽이 더 안정적인가?
• 기존 prompt A보다 새 prompt B가 실제로 개선되었나?

이건 프롬프트 엔지니어링을 “예술”이 아니라 “실험”으로 바꾸는 지점입니다.

---

4. 커스텀 Provider와 언어 독립성

Promptfoo는 특정 LLM SaaS에 종속되지 않도록 설계되어 있습니다.
공식 provider 문서에 따르면 내장 provider 외에도 HTTP API, JavaScript provider, Python provider, 심지어 shell script provider까지 지원합니다. (Promptfoo)

이 의미는 꽤 큽니다.

예를 들어 여러분의 시스템이 이런 구조라도 붙일 수 있습니다.

• 자체 래핑한 사내 inference gateway
• LangChain / LlamaIndex / CrewAI 기반 파이프라인
• Python 함수로 감싼 RAG 체인
• 사내 MCP 또는 내부 HTTP endpoint

Promptfoo는 “모델 그 자체”만 테스트하는 툴이 아니라, 실제 애플리케이션 경로 전체를 provider처럼 감싸서 검증하는 툴에 가깝습니다. 이 해석은 공식 provider 문서와 예제 구조를 바탕으로 한 합리적 추론입니다. (Promptfoo)

---

5. Red Teaming: Promptfoo가 정말 강한 지점

Promptfoo를 단순 eval 도구가 아니라 AI 보안 플랫폼으로 보게 만드는 핵심은 red teaming입니다.

공식 red team 문서에 따르면 구성 요소는 크게 네 가지입니다.

• Targets: 테스트 대상 모델/엔드포인트
• Plugins: 적대적 입력 생성기
• Strategies: 공격 전달 방식
• Purpose: 시스템 목적 설명, 공격 생성의 문맥으로 사용 (Promptfoo)

또한 실행 흐름도 비교적 명확합니다.

promptfoo redteam init
promptfoo redteam run
promptfoo redteam report

redteam run은 test case 생성과 평가 실행을 묶은 shortcut으로 설명됩니다. (Promptfoo)

특히 흥미로운 부분은 전략(strategy) 개념입니다.
공식 전략 문서에서는 Meta Agent를 단일 턴 공격에, Hydra를 멀티 턴 상태 기반 공격에 추천하고 있습니다. 이는 단순히 “고정 jailbreak 문장 사전”을 돌리는 방식보다 훨씬 현실적인 공격 시뮬레이션에 가깝습니다. (Promptfoo)

추천 예시는 다음과 같습니다.

redteam:
  strategies:
    - jailbreak:meta
    - jailbreak:hydra

이 구성이 의미하는 바는 분명합니다.

• 단일 응답만 보는 챗봇
• 여러 턴에 걸쳐 상태를 유지하는 에이전트
• 외부 도구를 호출하는 agent workflow
• RAG 문서에 접근 가능한 시스템

같이 서로 다른 공격 표면을 가진 앱을 하나의 프레임워크 안에서 검사할 수 있다는 것입니다. (Promptfoo)

---

6. Code Scanning과 CI/CD 통합

Promptfoo는 실행형 eval만 다루지 않고, 코드 자체를 스캔하는 기능도 제공합니다.
공식 문서는 promptfoo code-scans run CLI와 GitHub Action을 제공하며, PR 단계에서 LLM 관련 보안 문제를 찾아 리뷰 코멘트나 결과를 남길 수 있다고 설명합니다. (Promptfoo)

여기서 중요한 포인트는 “일반 보안 스캐너가 못 보는 문제”를 겨냥한다는 점입니다.

예를 들면:

• prompt injection에 취약한 system prompt 연결
• PII 노출 가능성
• excessive agency
• jailbreak 우회 가능성
• 도구 호출 권한이 과도한 agent 설계 (Promptfoo)

즉 Promptfoo는 “모델 출력 평가”와 “코드 레벨 LLM 보안 리뷰”를 연결하는 방향으로 진화하고 있습니다.

---

프로젝트 구조 분석

GitHub 저장소 루트와 src 디렉터리를 보면 Promptfoo는 꽤 큰 TypeScript 중심 프로젝트입니다.
저장소 루트에는 src, examples, docs, site, code-scan-action, src/app, test 등이 있으며, package.json에는 workspaces로 src/app과 site가 선언되어 있습니다. 주 언어는 TypeScript가 약 96.8%입니다. (GitHub)

또 src 디렉터리에는 다음과 같은 하위 구조가 보입니다.

• assertions
• providers
• redteam
• codeScan
• commands
• server
• scheduler
• storage
• prompts
• testCase
• ui
• app (GitHub)

이 구조를 바탕으로 보면, Promptfoo는 대략 이런 계층으로 이해할 수 있습니다.

이 다이어그램은 공식 문서와 src 트리 이름을 근거로 재구성한 구조적 추론입니다. 실제 내부 클래스 관계를 그대로 옮긴 것은 아니지만, 책임 분리 방식은 상당히 잘 드러납니다. (GitHub)

구조적으로 보이는 특징

1) 명확한 도메인 분리

assertions, providers, redteam, testCase, commands가 분리되어 있어서
“입력 생성”, “모델 호출”, “평가”, “보안 공격”, “CLI orchestration”이 각각 독립 책임을 갖는 구조로 보입니다. (GitHub)

2) CLI + UI 병행 설계

README는 CLI 사용을 강조하지만, 루트에 src/app, site, ui, server가 있는 걸 보면 단순 CLI 도구를 넘어서 웹 뷰어/앱 경험까지 함께 제공하는 형태입니다. (GitHub)

3) “확장 가능한 플랫폼” 지향

providers, python, golang, ruby, integrations, external 폴더가 보인다는 점은 Promptfoo가 처음부터 특정 모델만 지원하는 도구가 아니라, 다양한 런타임과 외부 시스템 연결을 고려해 설계되었음을 시사합니다. 이 역시 트리 구조를 바탕으로 한 추론입니다. (GitHub)

---

실제 사용 흐름은 어떻게 보일까

개발자가 Promptfoo를 실제로 도입하는 흐름은 대체로 아래와 같습니다.

여기서 보안까지 확장하면 다음처럼 됩니다.

---

간단한 시작 예시

README 기준 가장 기본적인 시작은 아래와 같습니다. (GitHub)

npm install -g promptfoo
promptfoo init --example getting-started

export OPENAI_API_KEY=sk-abc123

cd getting-started
promptfoo eval
promptfoo view

설치 방식도 npm, brew, pip, npx를 모두 지원한다고 안내합니다. 즉 팀 상황에 따라 로컬 CLI, 일회성 실행, Python 환경 연동 등 선택지가 꽤 넓습니다. (GitHub)

---

어떤 팀에 특히 잘 맞을까

1. RAG를 운영하는 팀

RAG는 검색 품질만 문제가 아니라, 근거 없는 답변, 문맥 왜곡, 민감 문서 노출까지 함께 다뤄야 합니다. Promptfoo는 context-based assertion과 red team 기능을 같이 제공해서 이런 시스템에 특히 잘 맞습니다. (Promptfoo)

2. 에이전트 제품을 만드는 팀

에이전트는 일반 챗봇보다 상태, 도구 호출, 권한 범위가 복잡합니다. Promptfoo의 멀티턴 전략과 보안 점검 기능은 바로 이 계층을 겨냥합니다. (Promptfoo)

3. 프롬프트 변경이 잦은 팀

문서화되지 않은 프롬프트 수정은 품질 회귀를 자주 일으킵니다. Promptfoo는 프롬프트도 테스트 가능한 변경 단위로 바꿔 줍니다. (Promptfoo)

4. 규제/감사 대응이 필요한 팀

보안 리포트, CI 통합, 코드 스캔, 반복 가능한 테스트는 “왜 이 변경을 배포했는가”를 설명하는 데 유리합니다. 이는 OpenAI가 Promptfoo 인수 발표에서 언급한 평가·보안·컴플라이언스 요구와도 맥락이 닿아 있습니다. (OpenAI)

---

Promptfoo의 강점

제가 이 저장소를 자세히 훑어보고 느낀 Promptfoo의 가장 큰 강점은 다음 세 가지입니다.

첫째, 평가와 보안을 분리하지 않는다

많은 팀이 “성능 평가 도구”와 “보안 점검 도구”를 따로 찾습니다. Promptfoo는 둘을 하나의 개발 워크플로 안에 넣습니다. (GitHub)

둘째, 선언형 구성이 실무에 잘 맞는다

YAML 기반이라 실험을 빠르게 쌓고, PR 리뷰에서 diff를 보며, CI에서 반복 실행하기 좋습니다. (GitHub)

셋째, 특정 모델 벤더에 묶이지 않는다

Provider 계층이 넓고 커스텀 확장이 가능해서, 실제 서비스 파이프라인을 그대로 검증하기 좋습니다. (Promptfoo)

---

아쉬운 점과 도입 시 주의점

좋은 프로젝트지만, 도입 전에 알아둘 점도 있습니다.

1. “설정 잘하는 능력”이 필요하다

Promptfoo는 강력하지만, 반대로 말하면 무엇을 어떻게 평가할지 팀이 정의해야 합니다.
좋은 assertion, 좋은 test set, 좋은 red team 목적 설명이 없으면 결과도 애매해집니다. 이 부분은 도구가 대신해 주지 못합니다. 이 평가는 공식 기능을 바탕으로 한 제 해석입니다.

2. LLM 평가 자체의 한계는 여전히 존재한다

llm-rubric 같은 모델 기반 평가는 편리하지만, 채점 모델 편향이나 일관성 문제를 완전히 없애진 못합니다. 그래서 deterministic metric과 혼합해서 써야 실무적으로 안정적입니다. 공식 문서가 deterministic assertion과 model-graded assertion을 모두 제공하는 이유도 여기에 있다고 볼 수 있습니다. (Promptfoo)

3. 보안 테스트는 “시작점”이지 “끝”이 아니다

Red teaming은 매우 중요하지만, 운영 환경의 권한 설계, 로그, rate limiting, human review까지 다 대체하진 않습니다. Promptfoo는 강력한 검증 도구이지, 모든 보안 문제를 자동으로 해결하는 마법 상자는 아닙니다. 이 문장은 공식 문서의 범위를 바탕으로 한 실무적 해석입니다.

---

최신 맥락에서 왜 더 중요해졌나

2026년 3월 기준 Promptfoo는 단순 오픈소스를 넘어, OpenAI가 인수 발표를 한 AI 보안 플랫폼이기도 합니다. OpenAI는 Promptfoo 기술을 Frontier에 통합해 에이전트 보안 테스트와 평가 역량을 강화하겠다고 밝혔고, 동시에 오픈소스 프로젝트는 기존 라이선스로 계속 유지하겠다고 발표했습니다. Promptfoo 측 블로그는 2024년 창업 이후 수십만 개발자가 사용했고 Fortune 500의 25% 이상이 의존한다고 주장합니다. (OpenAI)

이건 꽤 상징적입니다.
이제 AI 애플리케이션에서 중요한 것은 “모델 성능”만이 아니라,

• 안전한가
• 회귀를 막을 수 있는가
• 조직적으로 테스트 가능한가
• 에이전트 행동을 설명할 수 있는가

같은 문제라는 뜻이기 때문입니다. Promptfoo는 바로 이 변화의 중심에 있는 프로젝트입니다. (OpenAI)

---

정리

Promptfoo는 단순한 “프롬프트 비교 도구”가 아닙니다.
오히려 다음을 하나의 흐름으로 묶는 LLM 애플리케이션 검증 플랫폼에 가깝습니다.

• 프롬프트/모델 평가
• RAG 품질 검증
• 에이전트 회귀 테스트
• 레드팀 기반 보안 점검
• 코드 스캔과 CI/CD 자동화 (GitHub)

초급~중급 개발자 관점에서 가장 중요한 메시지는 이것입니다.

LLM 앱을 “잘 동작하길 바라는 상태”에서 “테스트로 증명하는 상태”로 바꿔 주는 도구가 Promptfoo다.