Promptic

프롬프트와 라벨 예시를 넣으면 고른 지표에서 점수가 더 높은 개정안을 찾는다. 후보마다 점수가 붙으니 문장 표현을 두고 다투는 대신 버전을 비교하게 된다. 남은 프롬프트는 읽을 수 있는 형태를 유지한다. 반년 뒤 유지보수할 사람에게는 중요한 조건이다. 어떤 예시를 넣을지는 여전히 프롬프트 엔지니어링 판단의 몫이고, 탐색의 질은 테스트 세트의 질을 넘지 못한다.

같은 테스트 세트를 두 개 이상의 모델에 물리면 품질, 비용, 지연 시간이 나란히 놓인다. 비싼 모델이 더 안전하다는, 대부분 팀이 기본값으로 틀리는 가정에 답이 생긴다. 간단한 요청은 싼 후보에 맡기고 어려운 요청만 다른 모델로 보낼 수 있다.

에이전트에서는 프롬프트 문자열 하나가 아니라 구조와 도구 경로를 시험한다. 어느 경로가 정답에 닿는지, 호출을 얼마나 쓰는지 보인다. 프롬프트만 다루는 도구와 갈라지는 지점이 여기다. 에이전트 실패는 문장이 아니라 도구 선택에서 나오는 경우가 많다.

SDK가 모델 호출, 도구 호출, 워크플로 단계를 OpenTelemetry span으로 내보낸다. 단계별 시간과 비용이 보이고, 그 트레이스가 조정의 재료가 된다. 여기서 트레이싱은 입구이지 제품의 목적지가 아니다.

예시를 불러오고 AI 도움으로 더 만들고, 출력을 자동 채점하는 judge를 구성할 수 있다. Team 이상에는 AI 기반 데이터·judge 생성이 붙어 "예시 30개"에서 "예시 300개"까지의 거리가 줄어든다. 채점 기준은 직접 고칠 수 있어, 엉뚱하게 채점하는 judge를 도메인 전문가가 바로잡는다.

대시보드의 기능은 REST API와 SDK, CLI로 모두 닿는다. Business 플랜에는 평가 점수가 떨어지면 빌드를 실패시키는 CI/CD 게이트와 역할 기반 접근 제어가 더해진다. 코딩 에이전트가 API로 조정 루프를 대신 돌릴 수도 있어, 저장소 작업을 이미 자동화한 팀에 맞는다.