aiprompt-smith
내가 만든 ai 툴 성능을 측정하고 개선해보기
ai 툴 품질을 감으로만 판단하지 않고, 데이터셋과 자동 채점으로 개선 폭을 수치화한 기록.
Jan 23, 20261 min read
ai 툴 품질을 감으로만 판단하지 않고, 데이터셋과 자동 채점으로 개선 폭을 수치화한 기록.
prompt‑smith는 프롬프트를 점검하고 개선 포인트를 정리해주는 도구입니다.
요구사항을 정리하고, 빠진 요소를 체크하고, 개선안을 만드는 흐름을 제공합니다.
실무에서 prompt‑smith를 꽤 잘 쓰고 있었지만, 어느 순간 이런 생각이 들었습니다. “진짜 효과가 있는 걸까?”
좋아진 느낌은 오는데, 그걸 팀에 설명하거나 다음 개선 방향을 정하려면 숫자가 필요했습니다.
그래서 이번에는 감이 아니라 측정으로 확인해보기로 했습니다.
실무에서 자주 나오는 형태를 선택했습니다. 입력은 문의 + 컨텍스트, 출력은 라우팅에 필요한 JSON입니다.
{
"category": "...",
"priority": "...",
"needs_human": true,
"language": "ko|en",
"action": "...",
"confidence": 0.0,
"injection_detected": false
}
도메인은 핀테크로 잡았지만 어디까지나 예시입니다. 데이터는 50건(ko:en = 7:3)이며, 인젝션 케이스 3건을 포함했습니다. PII는 포함하지 않았습니다.
참고로 실제 사용자 로그가 아닌 합성 데이터셋이라 분포 차이는 있을 수 있습니다.
목표는 단순합니다. prompt‑smith로 개선한 프롬프트가 실제로 성능을 올리는지 확인하는 것.
그래서 동일한 데이터셋과 동일한 모델에서 **P0(일반 프롬프트)와 P1(개선 프롬프트)**을 비교했습니다.
평가 지표는 PASS/FAIL로 단순화했고, 실패 원인은 자동 채점 로그로 따로 수집했습니다.
즉, “좋아 보인다”가 아니라 “몇 건이 정확히 맞았는가”로 판단했습니다.
모델 출력은 CSV로 모으고, 자동 채점 스크립트로 PASS/FAIL을 계산했습니다.
이번 실험은 gpt‑4.1‑mini로 진행했습니다. 비용과 성능 균형을 고려해 선택했습니다.
python automation/scripts/ps_run_openai.py \
--dataset ps_fintech_router_dataset_v1.json \
--model gpt-4.1-mini \
--prompt-file ps_fintech_router_prompt_p0.md \
--out automation/outputs/ps_fintech_runs_filled_41mini_p0.csv
python automation/scripts/taskpack_cli.py ps-grade \
--dataset ps_fintech_router_dataset_v1.json \
--runs automation/outputs/ps_fintech_runs_filled_41mini_p0.csv \
--out automation/outputs/ps_fintech_runs_graded_41mini_p0.csv
정답(JSON)과 모델 출력(JSON)을 비교해 자동 채점하며, 키 누락/형식 오류/값 불일치는 FAIL 처리합니다.
먼저 P0 프롬프트로 전체 데이터셋을 돌려 baseline을 만들었습니다.
그 결과를 보면서 실패 패턴을 요약했고, 그 기준을 prompt‑smith 개선안에 반영해 P1 프롬프트를 만들었습니다.
같은 조건에서 다시 실행한 뒤, 두 결과를 비교했습니다.
설계는 단순하지만, “같은 조건에서 비교한다”는 원칙을 지키는 데 집중했습니다.
P0는 “기본 지시 + 스키마 안내” 수준으로 얕게 작성했습니다. 이후 prompt‑smith를 기준으로 판단 규칙을 명시하고 라우팅 기준을 구체화한 P1을 만들었습니다.
| 프롬프트 | PASS | FAIL | 개선폭 |
|---|---|---|---|
| P0 | 12 | 38 | — |
| P1 | 47 | 3 | +35 |
단순한 문장 다듬기가 아니라, 의사결정 규칙을 명확히 넣는 것이 성능을 크게 끌어올렸습니다.
P0에서 실패가 많았던 이유는 비슷했습니다. needs_human 과소 판단, priority 과소/과대 판단, 일부 카테고리 혼동.
P1에서는 이 규칙을 사전에 명시했고 결과가 급격히 좋아졌습니다. 이 변화는 “모델이 더 똑똑해져서”라기보다, 판단 기준을 명확히 제공받았기 때문이라고 보는 게 맞습니다.
아래 표는 P0 기준으로 자동 채점에서 가장 많이 나온 실패 원인입니다.
| 원인 | 건수 |
|---|---|
| needs_human 과소 판단 | 13 |
| priority 높음 → 보통 | 8 |
| priority 긴급 → 높음 | 5 |
P1은 규칙을 상세히 넣으면서 프롬프트 길이가 크게 늘었습니다. 이번 실험 기준으로 입력 토큰은 약 3.6배, 전체 토큰은 약 3.2배 증가했습니다. 성능은 좋아졌지만, 토큰 효율을 줄이는 작업이 다음 개선 과제로 남았습니다.
적어도 이 실험에서는 효과적이었습니다. 개선 폭이 컸고, 같은 조건에서 결과가 재현됐으며, 실패 패턴도 눈에 띄게 줄었습니다.
다만 이 결론은 합성 데이터셋 + 특정 도메인 + 특정 모델에 의존합니다. 실무 로그에 적용하려면 홀드아웃/재현 테스트가 필요합니다.
다음으로는 P2에서 남은 실패 케이스(고객불만/보안 우선순위) 규칙을 더 강화해볼 예정입니다. 그리고 gpt‑4o‑mini와의 비용/성능 비교, 더 리얼한/대규모 로그 기반 데이터셋으로 재검증도 계획하고 있습니다.
프롬프트 개선을 감으로만 접근하지 않고, 측정 가능한 개선으로 전환해보니 방향이 훨씬 또렷해졌습니다. 다음 개선은 어디를 손봐야 하는지가 수치로 보이니까요.
이 글이 프롬프트 개선 과정을 정량화하려는 분들께 도움이 되었으면 합니다.