Indie Hackers

I brought PromptBrake’s free tools into AI assistants and GitHub CI

PromptBrake 무료 도구를 AI 어시스턴트와 GitHub CI에 연결했습니다

PromptBrake가 프롬프트 인젝션 테스트 도구와 OWASP LLM 위험 매핑을 AI 어시스턴트, GitHub CI에서 쓰도록 공개했습니다. 웹 도구와 MCP는 테스트 입력과 계획을 준비하고, GitHub Action은 설정한 AI 엔드포인트를 직접 검사합니다.

AI 요약

PromptBrake 창업자 Ammar는 AI 챗봇과 에이전트를 배포 전에 테스트하는 도구를 만들고 있습니다. 직접 에이전트를 수동으로 검사하면서 변경 사항마다 무엇이 나아지고 깨졌는지 추적하기 어려웠던 경험이 출발점입니다. 이번에는 도구를 개발자가 일하는 환경에 연결했습니다.

공개한 도구

무료 웹 도구는 프롬프트 인젝션 테스트 입력, OWASP LLM 위험 매핑, 릴리스 계획, 사용자 지정 응답 테스트 묶음을 제공합니다. 원격 MCP 서버는 이 네 가지 도구를 호환되는 AI 어시스턴트에 연결합니다. PromptBrake 계정이나 API 키는 필요하지 않습니다.

Codex, Claude Code, Cursor에서 도구를 쓰도록 재사용 가능한 스킬과 플러그인 묶음도 공개했습니다. 소스 코드는 공개됐지만, 디렉터리 등록 승인과 클라이언트 지원 여부는 환경마다 다릅니다.

무료 GitHub Action은 CI에서 프롬프트 인젝션과 합성 비밀 정보 유출 검사를 실행합니다. 웹 도구와 MCP는 테스트 입력과 계획을 준비하는 역할이고, GitHub Action은 사용자가 설정한 엔드포인트를 실제로 호출합니다. 도구 빌더에서 만든 사용자 지정 테스트 묶음은 별도의 PromptBrake runner와 CI 접근 권한이 필요합니다.

검사 범위와 사용 지표

응답 검사는 텍스트를 비교합니다. 에이전트가 백엔드에서 권한에 맞게 동작했는지까지 입증하지는 않습니다. 팀 단위로 더 넓은 검사를 원하는 고객에게는 유료 runner 요금제가 있습니다.

초기 운영에서 배운 점은 MCP 디렉터리 탐색 트래픽을 실제 사용량으로 보면 안 된다는 것입니다. 디렉터리 조회와 상태 확인 요청이 실제 도구 호출처럼 보일 수 있어, Ammar는 실제 호출을 따로 집계합니다. 아직 초기 단계라 어떤 배포 경로가 반복 사용으로 이어지는지 살피고 있습니다.

Indie Hackers 반응

  • @z_tasnim_s75 — CI에 넣은 점이 좋습니다. 저는 n8n AI 워크플로를 만들고 있는데, 구조화된 출력과 검증이 안정성을 지켜줍니다. 팀마다 사용자 지정 규칙을 지원할 계획인가요?
  • @conformly — 테스트 입력을 준비하는 단계와 엔드포인트를 실제 호출하는 단계를 나눈 점이 흥미롭습니다. 저도 무료 CLI와 GitHub Action으로 접근성 검사기를 만들었는데, CI에서 실제로 쓰이기 시작한 건 검사가 단순해진 뒤였습니다. 명령 하나, 단일 점수, 임계값, 그리고 다른 테스트처럼 빌드를 실패시키는 종료 코드가 필요했습니다. 먼저 보고서를 읽어야 하는 도구는 무시당했습니다. 또 다른 교훈은 잡음입니다. 금요일 배포 때 오탐이 나면 검사를 끄게 됩니다. 도구가 감지하지 못하는 범위를 분명히 밝혀야지, 검사 범위를 부풀리면 안 됩니다. 응답 검사가 백엔드 권한 준수를 입증하지 못한다고 밝힌 점이 신뢰를 쌓는 데 도움이 됩니다. MCP 트래픽도 마찬가지입니다. 디렉터리 조회와 실제 도구 호출을 분리하는 것만이 의미 있는 지표입니다.
    • @Specialist-Bee9801 — 공유해 주셔서 감사합니다. 금요일 배포 사례가 와닿습니다. 잡음이 많은 검사 하나가 신뢰를 무너뜨릴 수 있습니다. 처음부터 빌드를 실패시키게 했나요, 아니면 우선 차단 없이 써보게 했나요?
  • @369mmaker — 디렉터리 조회 트래픽과 실제 도구 호출을 구분하는 점이 좋은 배포 교훈입니다. 디렉터리 탐색만으로 초기 지표가 실제보다 좋아 보일 수 있습니다. 무료 웹 도구에서 CI Action으로 이어지는 흐름은 팀이 릴리스 때 이미 쓰는 환경에서 부담 없이 시험하게 해줍니다.
    • @Specialist-Bee9801 — 감사합니다. 발견되는 것과 실제로 쓰이는 것은 다르다는 점이 지금까지 가장 큰 교훈입니다. 팀이 이미 쓰는 워크플로에서 시험할 수 있어 CI Action은 자연스러운 다음 단계였습니다. 아직 초기 단계지만 반복 사용으로 이어질지 궁금합니다.
    • @369mmaker — 공감해 주셔서 감사합니다. 발견과 실제 사용은 서로 다른 문제입니다. 첫 클릭이 아니라 반복 사용이 목표라면 사람들이 이미 실행하는 워크플로에 들어가는 선택이 맞습니다. 앞으로 몇 주 동안 어떤 결과가 나오면 반복 사용이라고 판단하시겠습니까?
    • @Specialist-Bee9801 — 앞으로 몇 주 동안 몇 팀이 Action을 CI에 계속 두고 여러 PR에서 실행하면 반복 사용이라고 보겠습니다. 첫 시도 이후에도 유용하다는 뜻이니까요.
    • @369mmaker — 명확한 기준입니다. 몇 주 동안 실제 PR에서 몇 팀이 실행하면 시연이 아니라 사용이라고 볼 수 있습니다. 새로움이 사라진 뒤에도 유지한다면 Action이 워크플로에 자리 잡았다는 뜻입니다.
    • @Specialist-Bee9801 — 맞습니다. 그렇게 되길 바랍니다. 사용량이 조금 쌓이면 결과를 공유하겠습니다.

원문: Indie Hackers / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗