모델을 바꿀까, 프롬프트를 고칠까 — 실데이터 200건으로 만든 LLM 선정 평가

LLM으로 텍스트에서 구조화 데이터를 뽑는 파이프라인을 설계할 때 가장 먼저 나오는 질문은 대개 "어떤 모델을 쓸까"다. 우리도 그렇게 시작했다. 인플루언서 데이터 서비스에서 수집한 프로필 바이오가 문자열로만 쌓여 있었고 여기서 활동 분야·연락처·계정 간 관계를 추출해야 했다.

후보는 Amazon Nova 2 Lite, Claude Haiku 4.5, Claude Sonnet 5였다. 결론은 모델 선택보다 프롬프트에 가까웠다. 이 글은 그 판단에 이른 평가 설계와 2026년 8월 5일의 실측 결과를 정리한다. 운영 DB 원문과 원시 결과에는 개인 식별 정보가 있어 공개하지 않으며 집계 수치와 익명화한 사례만 다룬다.

어떤 판정이 가장 비싼 실수를 만드는가

평가를 설계하기 전에 오판의 비용부터 따졌다. 항목마다 틀렸을 때의 대가가 다르기 때문이다.

• 활동 분야를 잘못 분류하면 탐색 필터가 조금 부정확해진다. 복구하기 쉽다.
• 계정 간 관계에서 **SAME_AS**를 잘못 판정하면 두 계정이 한 인물로 병합된다. 팔로워 합산, 성과 귀속, 정산이 함께 오염되고 되돌리기 어렵다.

평가 지표는 관계 유형 판정의 기준 일치율로 정했다. 가장 어렵고 틀렸을 때 손해가 큰 판정이다. 어떤 지표로 평가할지는 모델 비교보다 먼저 정한다. RAG 회귀 평가를 만들 때와 같은 원칙이다. 평가셋은 질문 목록이 아니라 판정 계약이다.

관계를 여섯 가지로 정의했다

판정을 시키려면 먼저 보기를 고정해야 한다. 바이오의 계정 언급에는 최소 다섯 가지 관계가 섞여 있었다. 여기에 "모르겠다"를 뜻하는 값을 더해 여섯 가지 enum으로 고정했다. 유형마다 시스템 대응이 다르다. 관계 정의는 단순 분류표가 아니라 후속 처리의 분기 조건이다.

칸막이 규칙은 두 개다. SAME_AS만 병합 후보다. OPERATES는 팔로워를 합산하지 않는다. 한 매거진 계정이 뷰티·음악 섹션 계정을 따로 운영하는 사례에서 셋을 한 주체의 도달로 세면 수치가 3배 부풀려진다.

MENTIONS도 의도적으로 만든 값이다. "모르겠다"를 고를 수 없는 분류기는 모든 언급을 어딘가에 밀어 넣는다. 초기 프롬프트에서 이 문제가 그대로 드러났다.

이 판정에는 문맥이 필요하다. 같은 바이오의 같은 문법 위치에 놓인 두 핸들이 하나는 본인 부계정(SAME_AS), 다른 하나는 다니는 체육관(AFFILIATED_WITH)인 사례가 있었다. 핸들 유사도 같은 규칙만으로는 구분하기 어렵다.

정답 세트가 없을 때의 기준선

사람이 라벨링한 정답 세트는 없었다. 그래서 가장 강한 후보인 Sonnet 5의 판정을 정답 프록시로 두고 나머지 조합이 이 기준에 얼마나 가까운지 측정했다.

이 수치는 정확도가 아니라 Sonnet 5와의 일치율이다. 불일치 사례를 하나씩 검토했을 때 Sonnet 판정이 더 일관되고 타당했지만 사람 정답 세트를 대신할 수는 없다. 이 한계 때문에 결과 표와 차트에서도 accuracy라는 표현을 쓰지 않았다.

첫 실행을 막은 세 가지 구현 차이

모델 이름만 바꿔서는 같은 실험이 돌아가지 않았다.

모델 ID의 v1:0은 AWS가 관리하는 모델 리비전이다. 아래 P1·P2·P3는 이 실험에서 프롬프트를 개선한 순서를 뜻한다. P1은 초기 프롬프트, P2는 결정 트리와 오판 규칙을 더한 프롬프트, P3는 입력 경계와 잔여 오류 대응까지 보강한 최종 프롬프트다.

Nova와 Claude를 같은 런타임에서 호출하려고 @aws-sdk/client-bedrock-runtime을 썼다. Anthropic 전용 SDK만으로는 Nova를 호출할 수 없기 때문이다. 이런 차이를 정리하지 않으면 모델 품질이 아니라 호출 코드와 파서 오류를 비교하게 된다.

프롬프트 개선이 모델 교체보다 컸다

Nova 2 Lite + P1을 Claude Haiku 4.5 + P1으로 바꾸면 일치율은 50%에서 64%로 14%p 올랐고 비용은 약 2.98배가 됐다. 같은 Nova 2 Lite에서 P1을 P3로 고치자 일치율은 87%에 도달했고 비용은 약 1.36배가 됐다. 병목이 모델 성능에 있었다면 Haiku가 Nova를 크게 앞섰어야 한다. 이 실험의 병목은 판정 기준의 모호함이었다.

집계 수치 말고 분포를 함께 봤다

일치율만으로는 모델의 오판 습관을 찾기 어렵다. 판정 유형의 분포를 기준선과 나란히 놓자 문제가 드러났다.

Nova 2 Lite + P1은 COLLABORATES를 19건 내면서 MENTIONS는 한 건도 내지 않았다. 근거가 약한 언급까지 협업으로 밀어 넣은 셈이다. 가장 위험한 SAME_AS도 33건으로 과다했다. 육안 검토에서 잘못된 병합 후보 20건을 찾았다. P3에서는 OPERATES 6건과 BRAND_OF 1건이 Sonnet 판정과 같아졌다.

confidence는 기본값으로 믿지 않았다

confidence는 모델이 판정과 함께 반환하는 0~1 사이의 자기 확신 값이다. 우리는 이 값을 판정 결과와 같은 레코드에 저장하고 근거가 된 원문 조각(evidenceText)도 반드시 남긴다. 숫자만으로는 검토자가 판단 근거를 확인할 수 없다.

초기 confidence는 트리아지에 쓸 수 없었다.

P1에서는 판정의 절반 이상이 최고 확신이었다. confidence < 0.7을 사람 검토 큐로 보내도 위험한 판정을 충분히 걸러내지 못했다. 프롬프트에 **"관계가 원문에 문자로 쓰여 있을 때만 1.0"**이라는 앵커 계약을 넣자 1.0 비율이 14%로 내려갔다. confidence도 프롬프트로 정의해야 하는 출력이었다.

검토 화면에 0.87 같은 소수를 그대로 노출하지 않기로 했다. 모델이 낸 0.87과 0.85에는 그만한 해상도가 없다. 저장소에는 소수 셋째 자리 연속값을 두되 운영에서는 임계값 0.7로 검토 큐 진입 여부를 가르고 화면에는 구간 라벨과 evidenceText를 보여준다. confidence와 확정 상태도 분리했다. confidence는 모델의 확신이고 확정은 사람이 PENDING을 CONFIRMED 또는 REJECTED로 바꾸는 행위다. 재추론은 사람의 확정을 덮어쓰지 않는다.

오판을 규칙으로 바꿔 프롬프트를 고쳤다

P1의 오판 22건을 유형별로 세고 패턴마다 규칙을 넣었다.

판정 순서는 결정 트리로 고정했다. 본인 자산인지, 별개 주제 계정인지, 브랜드·기관인지, 개인 관계인지, 실제 공동 작업인지 차례로 확인한다. COLLABORATES는 "함께 만든다"는 근거가 있을 때만 선택하도록 부정 규칙도 더했다.

P3에서는 입력 구조의 버그까지 고쳤다. Nova가 프롬프트 헤더의 프로필 주인 핸들을 바이오 내용으로 오인해 추출한 사례가 12건 있었다. 입력을 [메타]와 [bio 본문]으로 나누자 2건으로 줄었다. 프롬프트 개선은 판정 문구뿐 아니라 입력 경계를 설계하는 일도 포함한다.

실제 바이오의 핸들을 익명화하면 판정 변화는 다음과 같다.

"뷰티 브랜드 CEO. -18kg 감량 후 3년째 유지 중 @brand_official"
   P1: SAME_AS   ← 개인 계정과 브랜드 계정을 한 인물로 병합
   P3: BRAND_OF  ← 관계만 기록하고 병합하지 않음

"패션 브랜드 앰버서더 2기 @fashion_kr"
   P1: COLLABORATES     P3: AFFILIATED_WITH

"배우 ○○○ @actor_a 의 아내"
   P1: COLLABORATES     P3: MENTIONS

최종 프롬프트(P3)의 뼈대

원본 프롬프트 파일은 남아 있지 않다. 아래 예시는 평가 보고서에 기록된 규칙을 바탕으로 판정 부분만 재구성했다.

[메타]
프로필 주인: @{handle}
(이 핸들은 판정 대상이 아니다. 아래 bio 본문에서 언급된 핸들만 판정한다.)

[bio 본문]
{정제된 바이오 텍스트}

관계 판정 — 언급된 각 @핸들을 아래 순서로 검사한다:
1. 본인 자산인가? (본인의 부계정임을 나타내는 표기)        → SAME_AS
2. "○○ 계정"처럼 용도를 명시한 별개 주제 계정인가?         → OPERATES
3. CEO·대표·창업 표현과 함께 나오는 브랜드인가?            → BRAND_OF
4. 브랜드·기관·소속(앰버서더, 소속사, 체육관)인가?         → AFFILIATED_WITH
5. 개인 관계(배우자·가족·지인)인가?                        → MENTIONS
6. "함께 만든다"는 근거가 원문에 있는가?                   → COLLABORATES
7. 어디에도 근거가 없으면                                  → MENTIONS

부정 규칙:
- COLLABORATES는 공동 작업의 근거가 문자로 있을 때만 쓴다.
- 맥락 없는 브랜드 핸들은 협업이 아니라 소속·후원으로 본다.
- "_official", "_pick" 같은 큐레이션 핸들 패턴은 SAME_AS가 아니라 OPERATES다.
- 링크 허브 URL은 계정이 아니다. 연락 채널(link_hub)로 분류한다.

confidence:
- 관계가 원문에 문자로 쓰여 있을 때만 1.0을 쓴다.

결정 트리는 유형 사이에서 모델이 재량을 발휘할 여지를 줄였다. 부정 규칙은 근거가 약한 판정을 MENTIONS로 보내 기본값을 보수적으로 바꿨다. [메타]와 [bio 본문]의 분리는 입력 경계를 모델에 명시한 조치다.

월 $10 미만 구성을 골랐다

채택한 구성은 Amazon Nova 2 Lite + P3다.

비용은 표에 적은 평균 입출력 토큰과 2026년 8월 5일의 모델 단가로 계산한 USD 추정치다.³⁴ 평균 토큰을 정수로 반올림해 소수점 둘째 자리에는 작은 오차가 생길 수 있다. Sonnet 5에는 2026년 8월 31일까지 적용되는 도입 단가를 썼다. 운영 기록에는 모델, 엔드포인트 유형, 입출력 토큰, 적용 단가와 계산일을 함께 남긴다.

모든 판정을 경량 모델에 맡기지는 않는다. 오판 비용의 비대칭에 맞춰 계층을 나눴다.

모델 평가 밖에서 운영을 지키는 장치

평가 결과만으로 운영 준비가 끝나지는 않는다. 실험에서 확인한 장치는 네 가지다.

1. 스키마 후검증. P1 결과의 4%가 사전 정의를 벗어났다. 톤 값이 카테고리 자리에 들어가는 식이다. 허용 값과 대조해 이탈 값은 버린다.
2. inferenceVersion 기록. 프롬프트가 바뀌면 버전을 올리고 어떤 기존 데이터를 다시 처리할지 정한다.
3. 절단된 입력 표시. 샘플의 18%가 "더 보기"에서 잘려 있었다. 잘린 입력은 신뢰도를 낮추거나 재수집한 뒤 판정한다.
4. 사람 검토 워크플로. 연락처·소속·계정 병합처럼 틀렸을 때 손해가 큰 항목은 사람이 확정한다.

남은 13%의 불일치는 맥락 없는 핸들, 여러 언어가 섞인 바이오처럼 Sonnet도 확신하지 못한 사례에 몰렸다. 여기서 프롬프트 규칙을 더 늘리면 특이 사례에 과적합하기 쉽다. confidence와 근거를 붙여 사람에게 넘기는 편이 낫다. 이 경계는 PoC를 운영으로 넘길 때의 게이트와 이어진다.

모델보다 평가 계약을 먼저 고른다

"어떤 모델을 쓸까"보다 앞에 둘 질문이 있다. 어떤 오판의 비용이 가장 큰가, 정답이 없을 때 무엇을 기준선으로 삼을 것인가, 오판을 어떤 규칙으로 바꿀 것인가. 이 세 가지를 정하고 나면 모델은 비용·지연·운영 경계 안에서 고를 수 있다. 우리 실험에서는 가장 저렴한 모델인 Nova 2 Lite에 P3를 적용한 조합이 그 조건을 만족했다.

추출·분류 파이프라인을 실제 데이터로 검증할 범위와 검토 기준은 데이터 & ML 엔지니어링에서 함께 정한다.

참고 자료