프롬프트 인젝션부터 LLM 평가까지: Promptfoo 리뷰와 요금

요금과 문서는 2026년 10월 13일에 확인했습니다. 아래 실습 예제는 직접 작성한 고정 테스트 답변을 대상으로 로컬에서 실행했습니다. 호스팅 기능은 로그인한 제품 체험이 아닌 공개 문서를 기준으로 평가했습니다. 현재 Promptfoo 요금제.

Promptfoo는 어떤 툴인가요?

Promptfoo는 AI 모델이나 애플리케이션에 테스트 입력을 보내고, 응답을 검사하고, 결과를 비교할 수 있도록 보여 주는 오픈 소스 명령줄 툴이자 라이브러리입니다. **평가(eval)**는 답변이 요구사항을 충족하는지 반복해서 확인하는 테스트입니다. 레드팀 테스트는 애플리케이션이 요구사항을 어기도록 의도적으로 유도합니다. 프롬프트, 테스트 대상, 예제, 채점 규칙을 정의한 뒤 로컬 결과 화면에서 확인하거나 빌드 과정에 결과를 활용합니다. 핵심 가치는 “이번 변경으로 고객 지원 봇에 문제가 생겼는가?”라는 질문에 재현 가능한 방식으로 답할 수 있다는 점입니다. 소개 문서에서는 품질 평가와 보안 테스트를 모두 설명합니다.

어떤 팀에 적합하고, 언제 다른 툴을 봐야 할까요?

Promptfoo는 테스트 설정을 직접 관리하고 이를 고객이 실제로 사용하는 애플리케이션에 연결할 수 있는 개발자에게 적합합니다. 도움말 문서를 검색하고, 주문 기록을 읽고, 환불 툴을 호출하는 고객 지원 봇이 좋은 예입니다. 유용한 답변을 하는지와 안전하게 작업을 수행하는지는 각각 따로 테스트해야 합니다.

코드와 함께 검토할 수 있는 테스트, 프로바이더 간 비교, 애플리케이션에 맞춘 공격 테스트가 필요하다면 고려할 만합니다. 무엇을 올바른 답변으로 볼지는 여전히 사람이 정해야 합니다. 어떤 툴을 쓰든 의미 있는 평가를 하려면 이 작업이 필요합니다.

출처: Promptfoo, Braintrust, LangSmith. 과금 방식이 서로 다르므로 같은 구성의 상품처럼 비교해서는 안 됩니다.

당장 해결할 문제가 출시 전 테스트 정의보다 운영 환경에서 발생한 일을 팀이 함께 분석하는 것이라면, Promptfoo를 첫 도입 후보로 삼을 필요는 없습니다. 실험 검토와 공통 데이터셋이 업무의 중심이라면 Braintrust를 후보에 넣는 편이 좋습니다. 잘못된 결과의 원인을 찾기 위해 에이전트의 모델·툴 호출 순서를 따라가야 한다면 LangSmith를 살펴보는 편이 좋습니다. 각 툴의 요금과 구체적인 장단점은 뒤에서 다룹니다.

판단 기준은 네 가지입니다. 테스트 대상이 실제 운영 환경과 얼마나 유사한지, 채점 근거를 얼마나 살펴볼 수 있는지, 데이터 취급 제한 안에서 어떤 보안 테스트를 실행할 수 있는지, 전체 워크플로에 얼마가 드는지입니다. 연동 목록이 아무리 길어도 엉뚱한 대상을 테스트하는 문제까지 해결해 주지는 못합니다. 더 넓은 후보군은 에이전트 평가용 AI·LLM 벤치마크 감사 툴 비교에서 살펴볼 수 있습니다.

OpenAI 인수로 무엇이 달라졌나요?

현재 Promptfoo 공식 저장소에는 OpenAI의 일부라고 명시돼 있으며 MIT 라이선스도 유지하고 있습니다. 날짜가 명시된 회사 발표에서는 지향하는 방향을 확인할 수 있지만, 인수 완료일이나 인수 금액은 제시하지 않습니다. Promptfoo 저장소.

2026년 3월 9일, Promptfoo는 OpenAI의 인수에 합의했으며 통상적인 거래 종결 조건을 충족해야 인수가 완료된다고 발표했습니다. 이 결합을 통해 핵심 기술을 개선하고 모델 및 인프라 계층에 통합할 수 있을 것이라고 설명했습니다. 같은 발표에서 지속적인 서비스와 지원, 오픈 소스 제품군의 유지보수, 다양한 모델과 프로바이더 지원도 약속했습니다. Promptfoo 발표.

이는 회사가 밝힌 약속입니다. 현재 프로바이더 문서에는 경쟁사의 서비스와 로컬 런타임도 여전히 포함돼 있습니다. 통합에 관한 설명은 앞으로의 방향으로 받아들여야 합니다. 특정 기업용 기능을 이미 CLI에서 사용할 수 있다는 근거는 아닙니다.

도입을 결정할 때는 소유권 변화와 기술적 요구사항을 구분해야 합니다. 해당 발표만으로 Promptfoo를 OpenAI 전용 평가 툴이라고 볼 근거는 없습니다. 마찬가지로, 계획된 기업용 통합을 이유로 자체 워크플로에서 확인하지도 않은 기능을 구매해서도 안 됩니다. 현재 패키지, 현재 배포 옵션, 현재 계약 조건을 기준으로 평가해야 합니다.

테스트 설정과 프로바이더 지원

Promptfoo의 테스트 설정은 무엇을 측정하려 했는지 함께 확인하는 기준이 됩니다. YAML 형식은 prompts, providers, tests로 구성하며, 개별 테스트에는 vars와 선택 사항인 assert 규칙을 지정합니다. 프로바이더는 모델이나 애플리케이션을 호출하는 어댑터입니다. {{question}} 같은 변수는 테스트 입력을 프롬프트에 삽입합니다. 설정 가이드.

고객 지원 봇이라면 기존 프롬프트와 수정안을 같은 질문, 같은 채점 규칙으로 비교해야 합니다. 그렇지 않으면 두 번째 실행에서 더 쉬운 질문을 받았기 때문에 점수가 높아졌을 수도 있습니다. 프롬프트 문구, 검색 동작, 모델, 툴 권한 가운데 한 번에 하나씩 바꾸는 것이 좋습니다.

로컬 결과 매트릭스에서는 점수가 바뀐 답변을 직접 살펴볼 수 있습니다. 이를 통해 구체적으로 어떤 회귀 문제가 생겼는지 찾습니다. 프롬프트를 줄인 뒤 누락된 주문 식별자를 더 이상 묻지 않게 됐을 수도 있고, 저렴한 모델이 불확실한 배송일을 사실처럼 말했을 수도 있습니다. 평균 점수만 보면 어느 쪽이든 놓칠 수 있습니다.

어떤 프로바이더를 지원하나요?

Promptfoo의 프로바이더 목록에는 폭넓은 지원 범위가 나와 있습니다. 대표적인 예는 다음과 같습니다.

• 모델 API: OpenAI, Anthropic, Google AI Studio, Google Vertex AI, Azure OpenAI, Amazon Web Services Bedrock, Cohere, Mistral AI, DeepSeek, Alibaba Cloud Qwen, AI21 Labs, Meta Model API, MiniMax, Moonshot Kimi, xAI, IBM WatsonX.
• 호스팅·추론 서비스: Amazon SageMaker, Groq, Cerebras, Fireworks AI, Together AI, Hugging Face, OpenRouter, Replicate, Perplexity AI, NVIDIA NIM, Databricks, Snowflake Cortex, Cloudflare AI.
• 로컬 런타임: Ollama, llama.cpp, llamafile, LocalAI, Docker Model Runner, vLLM, Transformers.js.
• 애플리케이션 어댑터: HTTP, WebSocket, Python, JavaScript, 셸 명령, Model Context Protocol 서버, 문서에 안내된 에이전트 SDK 연동.

이 목록은 대표 사례이며, 링크된 목록에는 다른 게이트웨이와 특화 프로바이더도 포함돼 있습니다. 인증 방식과 지원 옵션은 각 어댑터 문서에서 확인해야 합니다. 프로바이더를 지원한다고 해서 자신의 계정으로 그 프로바이더의 모든 모델에 접근할 수 있는 것은 아닙니다.

모델뿐 아니라 고객 지원 애플리케이션 전체를 테스트하세요

Promptfoo의 HTTP 어댑터는 요청을 구성하고 transformResponse로 답변을 추출할 수 있습니다. json.output이 그 예입니다. 사용자 정의 Python 프로바이더를 통해 기존 애플리케이션 코드를 호출할 수도 있습니다. 고객 지원 봇의 동작이 검색, 세션 상태, 권한 확인, 툴 실행에 좌우된다면 이런 연결 방식이 중요합니다. HTTP 프로바이더 문서.

실제와 비슷한 고객 질문을 해당 애플리케이션 경로로 보내고 응답을 평가합니다. 애플리케이션에서 사용하도록 정한 권한 제한 사용자 계정과 고정 테스트 기록도 그대로 적용해야 합니다. 검색 계층을 건너뛰고 모델만 테스트해서는 한 고객이 다른 고객의 주문을 조회할 수 있는지 거의 알 수 없습니다.

따라서 어댑터 연동은 체크 표시만 하고 끝낼 일이 아니라 엔지니어링 작업입니다. 권한을 결정하는 맥락을 유지하고, 고객에게 보이는 필드를 파싱하며, 실행된 작업도 따로 살펴봐야 합니다. 마지막 답변에서 정중하게 거절하더라도 그전에 무단으로 실행된 환불까지 되돌릴 수는 없습니다.

Promptfoo로 고객 지원 봇의 LLM 평가 시작하기

Promptfoo는 이미 만들어진 답변도 평가할 수 있습니다. 모델을 반복 호출하는 데 비용을 쓰기 전에 시작하기 좋은 방식입니다. echo 프로바이더는 입력한 텍스트를 그대로 반환하므로 검증 규칙이 답변을 직접 검사합니다. Echo 자체는 모델을 호출하지 않습니다. 여기에 LLM 심사 모델을 추가하면 얘기가 달라집니다. Echo 프로바이더 문서.

다음 예제는 고객 로그나 실제 모델 출력이라고 주장하는 데이터가 아닌, 직접 작성한 고정 테스트 답변을 사용합니다. 고객 지원 정책이 환불 요청을 Settings, Billing, Request refund 순서로 안내하도록 정했다고 가정합니다. 주문 상태를 알 수 없을 때는 발송됐다고 말하지 말고 담당 지원 채널로 넘겨야 합니다.

다음 내용을 promptfooconfig.yaml로 저장합니다.

description: Support bot answer checks
prompts:
  - '{{answer}}'
providers:
  - echo
tests:
  - description: Approved refund instructions
    vars:
      answer: 'Open Settings, choose Billing, and select Request refund.'
    assert:
      - type: icontains-all
        value: [Settings, Billing, Request refund]
  - description: Escalate an unknown order status
    vars:
      answer: 'I cannot verify your order status. Please contact support.'
    assert:
      - type: icontains
        value: contact support
      - type: not-icontains
        value: has shipped
  - description: Reject an invented order status
    vars:
      answer: 'Your order has shipped. Please contact support if needed.'
    assert:
      - type: icontains
        value: contact support
      - type: not-icontains
        value: has shipped

여기에 쓰인 검증 유형은 공식 문서에 나와 있습니다. icontains는 대소문자를 구분하지 않고 텍스트 포함 여부를 확인하며, icontains-all은 지정한 문구가 모두 들어 있어야 통과합니다. not- 접두사는 검사의 의미를 반대로 바꿉니다. 검증 규칙 레퍼런스.

문서에 명시된 Node.js 요구사항인 >=22.22.0을 충족하는 환경에서 다음을 실행합니다.

npx promptfoo@latest eval -c promptfooconfig.yaml -o support-results.json
npx promptfoo@latest view

시작 가이드에는 평가와 결과 뷰어 명령이, 레드팀 빠른 시작 가이드에는 Node 요구사항이 나와 있습니다. 평가 명령이 끝난 뒤 뷰어를 별도 명령으로 실행합니다.

이 리뷰를 위해 로컬에서 실행한 결과는 의도한 대로였습니다. 환불 안내 답변과 불확실성을 인정한 답변은 통과했고, 배송 상태를 지어낸 답변은 실패했습니다. 마지막 답변에는 지원 채널로 안내하는 문구가 있었지만, 그렇다고 금지된 주장을 한 문제가 상쇄되지는 않았습니다. 이 결과로 확인한 것은 예제의 연결 구성과 검증 규칙입니다. 실제 모델의 신뢰성에 대해서는 아무것도 입증하지 않습니다.

이 구분은 중요합니다. 채점기를 신뢰하기 전에 반드시 통과해야 할 답변과 반드시 실패해야 할 답변을 넣어 봅니다. 둘 다 통과한다면 모델을 비교하기 전에 테스트부터 고쳐야 합니다. 평가할 모델을 테스트 체계의 첫 디버깅 도구로 삼아서는 안 됩니다.

문구 일치 검사에서 고객 지원 품질 평가로 확장하기

Promptfoo의 모델 기반 검증은 문자열 비교로 놓치는 기준을 평가할 수 있습니다. llm-rubric은 작성한 평가 기준표에 따라 채점하고, factuality는 답변을 기준 진술과 비교합니다. 채점에 사용할 프로바이더도 명시적으로 선택할 수 있습니다. 모델 기반 검증 규칙.

이 봇에 유용한 평가 기준은 제공된 주문 정보만 사용하고, 정보가 부족하면 이를 인정하며, 허용된 다음 행동을 안내하도록 요구하는 것입니다. 심사 모델에는 관련 정책과 기준이 되는 사실을 함께 줘야 합니다. 그렇지 않으면 배송에 관한 주장이 사실인지 추측하라고 시키는 셈입니다.

정확히 지켜야 할 요구사항에는 결정론적 검사를 유지하고, 표현이 달라질 수 있는 부분에는 판단을 활용합니다. 이 예제는 “소포가 배송 중입니다” 같은 표현을 놓칠 수 있습니다. 반대로 잘못된 내용을 바로잡으려고 금지된 문구를 인용한 정상적인 문장을 탈락시킬 수도 있습니다. 이는 선택한 검사 방식의 한계이지, 봇이 안전하거나 위험하다는 증거는 아닙니다.

그다음 고정 테스트 답변을 수집한 실제 답변으로 바꾸거나 애플리케이션 프로바이더를 연결합니다. 잘못된 것으로 확인된 고정 답변은 채점 로직을 검증하는 테스트로 남겨 둡니다. 프롬프트를 바꿨다는 이유로 성공의 정의까지 자신도 모르게 바뀌어서는 안 됩니다.

프롬프트 인젝션과 권한 침해를 점검하는 AI 레드팀 테스트

Promptfoo의 레드팀 워크플로는 공격 입력을 생성하고, 대상에 실행한 뒤, 검토할 수 있도록 실패 사례를 보여 줍니다. 플러그인은 어떤 동작을 시험할지 정하고, 전략은 공격을 전달하는 방식을 바꿉니다. 문서에 명시된 테스트 대상에는 HTTP 엔드포인트, 브라우저 상호작용, 모델 직접 연결, 사용자 정의 코드 연결이 포함됩니다. 레드팀 빠른 시작 가이드.

고객 지원 봇의 일반 평가는 환불 자격이 있는 고객이 올바른 안내를 받는지 확인합니다. 레드팀 테스트는 고객이 봇을 조작해 다른 사람의 기록을 노출시키거나, 정책을 우회하거나, 연결된 툴을 오용하게 만들 수 있는지 확인합니다. Promptfoo 문서는 간접 프롬프트 인젝션, 데이터 유출, 무단 접근, 툴 악용 등 애플리케이션 수준의 위협을 다룹니다. 레드팀 가이드.

쓰기 권한이 있는 에이전트라면 통제된 테스트 환경을 사용하고, 대화 기록과 함께 작업 후의 데이터도 확인해야 합니다. 답변만 평가하면 권한 없는 툴 실행을 놓칠 수 있습니다. 반대로 심사 모델이 기대한 만큼 친절하게 들리지 않더라도 거절이 올바른 응답일 수 있습니다.

발견한 문제를 수정한 뒤에는 회귀 테스트 케이스로 남겨야 합니다. 새로운 실패를 찾는 탐색과 이미 알려진 실패가 재발했는지 확인하는 재실행을 구분합니다. AI 에이전트 보안 평가 실행 가이드에서는 이 출시 절차를 더 자세히 다룹니다.

CI와 보고서: 실패하면 출시를 막도록 구성하기

Promptfoo는 코드가 바뀔 때 자동 검사를 실행하는 지속적 통합, 즉 CI에 적합합니다. 문서는 일반 평가, 레드팀 스캔, 저장된 프로브 재실행, JSON·HTML·JUnit 등으로 결과를 내보내는 방법을 다룹니다. CI/CD 가이드.

개발자가 시스템 프롬프트나 검색 동작을 바꿀 때는 구성이 고정된 회귀 테스트 모음을 사용합니다. 새로운 사례를 찾기 위한 폭넓은 공격 생성은 별도로 실행합니다. 매번 비교할 때마다 새로운 공격을 섞으면 점수가 바뀐 이유를 가리기 어려워집니다. 애플리케이션에 문제가 생긴 것인지, 테스트가 더 어려워진 것인지 구분해야 합니다.

CLI 문서에 명시된 기본 동작은 테스트가 실패하거나 통과율 기준에 미달하면 종료 코드 100을 반환하는 것입니다. 그 밖의 오류에는 1을 사용합니다. 기본 통과율 기준은 100%이며, 이 설정들은 변경할 수 있습니다. CI 작업은 보고서 파일이 정상적으로 만들어졌다고 테스트도 성공한 것으로 처리해서는 안 됩니다. 실패 상태를 그대로 반영해야 합니다. CLI 레퍼런스.

출시 기준을 정할 때는 치명적인 오류와 일반적인 품질 미달을 구분합니다. 다른 답변이 대체로 유용했다는 이유로 무단 접근 문제가 평균 속에 묻혀서는 안 됩니다. 출시를 막는 각 사례에 담당자를 지정하고, 증거를 보관하고, 변경 후 같은 사례를 다시 실행합니다.

보고서는 다른 사람이 결론을 검토하고 이의를 제기할 수 있게 한다는 점에서 가치가 있습니다. 결과와 함께 애플리케이션 리비전, 설정, 테스트 데이터, 심사 모델 선택도 보관합니다. 이런 맥락이 없으면 통과한 보고서라도 다음 모델이나 프롬프트 변경 이후에는 재현할 수 없게 될 수 있습니다.

Promptfoo 요금제: Community, Enterprise, On-Premise

Promptfoo는 세 가지 요금제를 공개하고 있습니다. 유료 요금제는 견적을 받아야 하며, 현재 페이지에는 두 요금제 모두 달러 기준 시작 가격이 나와 있지 않습니다. 2026년 10월 13일 Promptfoo 요금 페이지에서 확인했습니다.

프로브 제공량은 무엇을 기준으로 계산하나요?

Promptfoo는 레드팀 평가 중 대상에 요청을 보낼 때 프로브를 집계합니다. 내부 생성 및 채점 호출은 프로브로 계산하지 않습니다. 추론 문서에 따르면 로컬 모델을 포함해 추론을 직접 운영해도 한도 계산은 그대로 적용됩니다. 추론과 한도.

프로브 제공량을 서로 다른 보안 시나리오의 수라고 해석해서는 안 됩니다. 대상에 요청을 반복하는 전략과 단일 턴 사례는 제공량을 소모하는 방식이 다릅니다. 테스트 범위는 애플리케이션, 선택한 공격, 실행 중 발생한 요청에 달려 있습니다. 대상을 연결한 뒤 실제 요청 수를 관찰해 예산을 잡아야 합니다.

월 비용과 답변당 평가 비용은 얼마인가요?

Promptfoo의 라이선스가 무료여도 대상 모델 추론, 공격 생성, 모델 기반 채점, 인프라, 실패 검토에 드는 비용은 따로 계산해야 합니다. 월 총비용은 이 가운데 어떤 서비스를 직접 운영하고 어떤 서비스를 구매하는지에 따라 달라집니다. 테스트 실행기가 무료라고 프로바이더 이용료까지 없어지는 것은 아닙니다.

실습 예제에서는 평가한 고정 테스트 답변당 모델 추론 비용이 $0입니다. Echo가 모델을 호출하지 않고 검사도 결정론적으로 수행하기 때문입니다. LLM으로 채점하는 테스트 모음에까지 이 결과를 적용할 수는 없습니다. 심사 모델이 모든 답변을 읽기 시작하면 그 사용량도 평가 예산에 포함됩니다. 문서에 명시된 Echo 동작.

비교하자면, Braintrust가 공개한 Starter의 초과 요금은 1,000회 채점당 $2.50이며, 추가 채점당 $0.0025로 계산됩니다. 이는 채점 요금입니다. 승인된 고객 지원 답변 하나를 얻는 데 드는 전체 비용은 아닙니다. 모델 사용량과 데이터 처리량은 별도로 과금됩니다. Braintrust 요금.

비용을 나눌 때 유용한 기준은 고객 지원 정책에 따라 승인된 답변 수입니다. 해당 평가에 들어간 비용을 승인된 답변 수로 나누고, 실패 조사에 드는 비용도 함께 드러나도록 관리합니다. 지어낸 주문 정보를 통과시키면서 실행 비용만 줄였다면 잘못된 목표를 최적화한 것입니다.

도입 판단을 바꾸는 한계

Promptfoo에서 가장 주의할 점은 스캐너를 로컬에서 실행한다고 모든 보안 작업이 로컬에서 이뤄지지는 않는다는 것입니다. 데이터 처리 문서는 대상 호출, 생성, 채점을 구분합니다. 호스팅된 채점 서비스에는 테스트 프롬프트, 대상 응답, 평가 기준이 전달될 수 있습니다.

일부 중요한 테스트에는 호스팅된 추론 서비스가 필요합니다. 같은 문서는 bola, bfla, indirect-prompt-injection 등을 원격 전용 플러그인으로 명시합니다. 각각 리소스 접근, 기능 권한, 외부 콘텐츠를 통해 들어오는 지시와 관련된 테스트입니다. 원격 생성을 끄면 사용할 수 있는 테스트 범위가 줄어듭니다. 비활성화 플래그가 네트워크 격리를 보장하는 것도 아닙니다. 취급이 제한된 고객 지원 데이터셋이라면 완전한 로컬 테스트 계획을 약속하기 전에 이 문제부터 해결해야 합니다.

추론을 직접 운영해도 프로브 한도는 사라지지 않습니다. 이는 데이터가 어디로 전송되는지와 별개의 제약입니다. 추론 문서는 자체 추론 설정을 쓰더라도 사용량을 계속 집계한다고 명시합니다. 오픈 소스라는 이유로 호스팅된 공격 서비스를 무제한 이용할 수 있다고 가정해서는 안 됩니다.

채점기가 잘못된 동작에 높은 점수를 줄 수 있습니다. 실습 예제는 특정 배송 문구를 포착할 뿐, 근거 없는 모든 배송 주장을 잡아내지는 못합니다. LLM 심사 모델은 유연성을 더하지만, 또 다른 모델의 해석도 개입시킵니다. 책임 있는 고객 지원 담당자들이 허용 가능하거나 불가능하다고 동의하는 예제를 사용해 평가 기준을 보정해야 합니다.

답변 테스트는 작업 실행의 문제를 놓칠 수 있습니다. 대상 어댑터가 최종 텍스트만 보여 준다면, 에이전트가 올바른 계정을 사용했는지 또는 맞는 기록을 변경했는지 그 텍스트만으로 입증할 수 없습니다. 성공 여부에 툴 실행이 포함된다면 작업 증거나 애플리케이션 상태 검증을 추가해야 합니다.

운영 업무는 여전히 팀의 몫입니다. 누군가는 테스트 케이스를 유지하고, 발견된 문제를 조사하고, 무엇이 출시를 막아야 하는지 결정해야 합니다. 관리형 대시보드를 구매하면 이 업무를 조율하기 쉬워질 수는 있습니다. 하지만 테스트가 지켜야 할 환불 정책이나 고객 접근 규칙까지 대신 정해 주지는 못합니다.

Promptfoo 대안 비교

Braintrust: 팀이 함께 평가하고 검토하는 일이 우선일 때

Braintrust는 추적, 실험, 데이터셋, 채점을 하나의 공유 플랫폼에 모았습니다. 동료들과 변경 사항을 검토하고 관찰한 동작을 평가 데이터로 만드는 일이 반복된다면 적합합니다. 이런 업무에서는 설정 중심의 프로세스보다 Braintrust가 제공하는 범위를 먼저 도입 후보로 검토할 만합니다.

Starter는 $0/월이며 처리 데이터 1 GB, 10,000회 채점, 14일 보관을 제공합니다. Pro는 $249/월이며 5 GB, 50,000회 채점, 30일 보관을 제공합니다. Enterprise는 별도 견적입니다. Starter의 초과 데이터 요금은 $4/GB, 초과 채점 요금은 $2.50/1,000회입니다. Pro는 각각 $3/GB, $1.50/1,000회이며, 보관 기간 연장은 별도 과금합니다. 현재 Braintrust 요금제.

과금 항목이 여러 갈래라는 점이 제약입니다. 채점 횟수, 처리 데이터, 보관 기간, 모델 사용량을 기준으로 예상 사용량을 계산해야 합니다. 당장 필요한 것이 규모가 작고 검토하기 쉬운 테스트 모음과 애플리케이션 공격 테스트라면 Promptfoo가 더 적합합니다. 기대 동작을 직접 정의하는 일을 피하려는 이유만으로 공유 플랫폼을 구매해서는 안 됩니다.

LangSmith: 에이전트의 실행 경로를 추적해야 할 때

LangSmith는 추적, 데이터셋 수집, 주석 작성, 온라인·오프라인 평가 기능을 제공합니다. 답변이 나오기까지 어떤 일이 이어졌는지 조사하는 것이 핵심 업무라면 적합합니다. 고객 지원 에이전트는 잘못된 기록을 검색하고도 그럴듯한 문장을 반환할 수 있습니다. 이런 문제를 조사할 때 실행 트레이스는 중요한 증거가 됩니다.

Developer는 $0/좌석/월이며 좌석 한 개로 제한됩니다. 사용량 요금이 발생하기 전까지 월 5,000건의 기본 트레이스를 제공합니다. Plus는 $39/좌석/월이며 월 10,000건의 기본 트레이스를 제공하고 좌석을 추가할 수 있습니다. 공개된 제공량은 전체 합계이며 좌석 수만큼 늘어나지 않습니다. Enterprise는 별도 견적입니다. LangSmith 요금.

검토 인원이 늘어나는 팀에서는 좌석을 추가할수록 비용이 늘면서 사용량도 계속 별도로 과금된다는 점이 제약입니다. 당장의 목표가 공격 테스트 범위를 명확히 갖춘 자동 출시 검사라면 Promptfoo가 더 적합합니다. LangSmith의 트레이스, Braintrust의 채점, Promptfoo의 프로브는 서로 다른 사건을 뜻합니다. 각각의 제공량을 동일한 테스트 실행 횟수처럼 비교하면 예산을 잘못 잡게 됩니다.

결론: 테스트를 직접 책임질 수 있다면 도입할 만합니다

개발자가 검토하고 반복 실행할 수 있는 명시적인 품질 검사와 공격 테스트가 필요하다면 Promptfoo는 고객 지원 봇이나 에이전트 프로젝트에서 역할을 할 수 있습니다. 데이터 흐름, 테스트 범위, 운영 방식이 맞는다면 Community로 시작하면 됩니다. 협업, 통제, 배포 요구사항에서 구체적인 필요가 생겼을 때 관리형 기능을 구매합니다.

무엇이 발목을 잡고 있느냐에 따라 선택은 달라집니다. 안전하고 올바른 답변이 무엇인지 설명할 수 없다면 정책과 예제부터 정리해야 합니다. 이를 설명할 수는 있지만 실패를 재현하지 못한다면 Promptfoo가 합리적인 다음 단계입니다. 이미 실패를 재현할 수 있고 공동 분석이나 실행 추적이 문제라면 Braintrust나 LangSmith도 함께 평가해야 합니다.

다음으로 할 일은 대표적인 고객 지원 질문을 저장하고, 허용되는 답변과 금지된 작업을 정의하고, 일부러 잘못 만든 답변이 실패하는지 확인하는 것입니다. 그런 다음 실제 애플리케이션을 연결하고 데이터 접근 범위를 살핀 뒤, 발생하면 출시를 중단해야 할 보안 사례를 추가합니다. 점수를 보기 전에 출시 기준을 먼저 공개해야 합니다.

도입 전 자주 묻는 질문

AI 시스템을 만들고 운영하며 얻은 실용적인 개발 기록과 현장 경험은 뉴스레터 구독으로 받아볼 수 있습니다.