앞 글에서 만들고 있는 Obsidian 플러그인(공개 전)의 판단 하나를 판단 전용 모델로 바꿀 수 있는지 재봤다. 두 노트가 같은 개념이라 합쳐야 하는지, 다른 개념이라 따로 둬야 하는지를 묻는 판단이다. 지금은 gpt-6-luna를 일반 호출로 부르고, 후보는 TypeSafe의 Jev와 OpenAI의 Decisions API였다.
결과는 이랬다. 플러그인이 실제로 쓰는 판단 규칙을 그대로 넣자 Decisions API는 틀린 답에도 확신 0.94 같은 높은 값을 붙였다. 그 규칙은 조건 여러 개를 질문 하나에 담고 있었고, 두 회사 문서는 모두 그렇게 하지 말라고 권하고 있었다. 이번 글은 그 권고를 실제로 따라 해 본 기록이다. Luna에게 하듯 프롬프트를 두 차례 고쳐 가며 쟀다.
미리 범위를 밝혀 둔다. 시험 데이터는 내 노트 보관소에서 뽑은 노트 쌍 37개이고, 같은 데이터를 보며 두 번 고쳤다. 여기서 통한 방법이 다른 판단, 다른 데이터에서도 통한다고 말하려는 글이 아니다. 이 케이스에서 무엇이 통했고 무엇이 안 통했는지까지만 적는다.
출발점 — 규칙 자체를 고친 것만으로 좋아졌다
튜닝 전에 규칙부터 손봐야 했다. 앞 글에서 찾은 버그 때문이다. “출처가 다른 두 노트는 같은 구체적 사건을 다룰 때만 같은 개념”이라는 규칙이 제품·회사 같은 고유한 대상에도 적용돼서, “Claude Code”와 “클로드 코드” 같은 쌍을 합치지 못했다. 그래서 “같은 고유한 대상은 출처가 달라도 같은 대상, 단 하위 주제 관계는 여전히 다른 개념”이라는 예외를 시험용 프롬프트에 넣었다.
이 규칙으로 질문 구조는 그대로 둔 채 다시 쟀다. 판단이 애매해 정답 자체가 의심스러운 세 쌍을 빼고 37쌍으로 셌다.
| 모델 | 고치기 전 규칙 | 고친 규칙 |
|---|---|---|
| gpt-6-luna (일반 호출) | — | 36쌍 |
| Jev | 33쌍 | 35쌍 |
| Decisions API | 32쌍 | 34쌍 |
규칙의 구멍을 메운 것만으로 두 판단 전용 모델도 함께 좋아졌다. 하지만 Decisions API는 한 쌍(같은 기사의 넓은 주제와 그 일부를 다룬 노트)을 여전히 확신 0.94로 틀렸다. 이 상태를 기준선으로 두고 문서 권고 두 가지를 시험했다.
문서가 권한 두 가지 — 질문 나누기와 입력 줄이기 (Decisions API·Jev 프롬프트 권장사항)
OpenAI는 Decisions API 가이드에서 서로 다른 관심사는 서로 다른 질문으로 나누라고 권한다. TypeSafe는 Jev 1.13의 약점을 정리한 문서에서 질문 하나에 판단 여러 개를 숨기지 말라고 하고, 판단과 상관없는 내용이 입력에 많으면 정확도가 떨어진다고 적었다.
내 경우에 옮기면 두 가지다. 첫째, “같은 개념인가”라는 선택지 질문 하나를 참·거짓 질문 여러 개로 나누고, 답을 조합하는 건 코드에 맡긴다. 둘째, 노트에서 판단과 상관없어 보이는 부분(태그나 날짜 같은 메타데이터, 관련 문서 링크 목록, 링크 경로)을 빼고 보낸다.
입력을 줄였더니 오히려 틀렸다 (LLM 입력 컨텍스트 줄이기)
입력 줄이기가 먼저 실패했다. 처음에는 노트 머리말(frontmatter)에서 제목과 분류만 남기고
다 지웠는데, Decisions API가 34쌍에서 29쌍으로 떨어졌다. 이유는 금방 보였다. 지운 것 중에
source, 즉 노트가 어느 원문 기사에서 나왔는지 적힌 줄이 있었다. 내 규칙은 “두 노트가 같은
원문에서 나왔는가”를 핵심으로 따지는데, 그 판단에 필요한 정보를 내 손으로 뺀 셈이다.
source를 남기고 다시 줄여 봤지만 그래도 나빠졌다. Decisions API는 32쌍, Jev는 33쌍으로 둘 다
기준선보다 낮았다. 남은 후보는 관련 문서 링크 목록이다. 같은 기사에서 나온 형제 노트들은
서로를 링크로 가리키고 있어서, “일부러 따로 만든 노트”라는 단서 역할을 했을 수 있다. 다만
이건 확인하지 않은 추측이다. 이 케이스에서 분명한 건 하나다. 사람 눈에 군더더기로 보이는
부분이 모델에게는 판단 근거였을 수 있으니, 무엇을 지울지는 판단 기준과 맞춰 보고 정해야 했다.
질문 나누기 1차 — 질문 하나를 모델이 다르게 읽었다 (Decisions API predicate)
판단을 참·거짓 질문 세 개로 나눴다.
- 두 노트가 같은 고유한 대상(특정 제품·회사·인물·작품 등) 하나를 다루는가
- 한 노트가 다른 노트의 상위 개념이고, 다른 노트는 그 일부나 특정 사례인가
- 두 노트가 같은 구체적 사건·연구·보고서를 요약한 것인가
조합은 코드가 한다. 1이 참이면 같다, 아니면 2가 참이면 다르다, 아니면 3이 참이면 같다, 그 밖은 다르다.
정답 수는 Decisions API 34쌍, Jev 33쌍으로 기준선과 비슷했다. 그런데 틀린 쌍을 열어 보니 같은 문제가 반복되고 있었다. 한 기사에서 서로 다른 하위 주제를 하나씩 맡아 만든 형제 노트들에 두 모델 모두 3번 질문을 “참”(0.89~1.0)으로 답했다. “같은 구체적 사건을 요약했나”를 “같은 기사에서 나왔나”로 읽은 것이다. 틀린 말은 아니다. 같은 기사이니 같은 사건을 다루는 건 맞다. 내가 묻고 싶었던 건 “같은 대상을 다루는가”였는데, 질문이 그렇게 적혀 있지 않았다.
질문 나누기 2차 — Decisions API가 37쌍 중 36쌍 (참·거짓 질문, 선택지 순서 편향 없음)
3번 질문만 고쳤다. “두 노트가 같은 대상을 같은 범위로 다루는가. 같은 원문에서 나왔어도 서로 다른 하위 주제면 거짓이고, 원문이 달라도 같은 구체적 사건을 다루고 날짜·수치·인물 같은 사실이 겹치면 참이다.”
Decisions API는 37쌍 중 36쌍을 맞혔다. 일반 호출로 부른 gpt-6-luna와 같은 수다. 기준선에서 확신 0.94로 틀리던 쌍도, 그 비슷한 하위 주제 쌍들도 이제 맞혔다. 하나 남은 오답도 정답 쪽이 의심스럽다. 한쪽은 출처 네 개를 묶어 기업 AI 비용 문제를 넓게 다룬 노트이고, 다른 쪽은 그중 한 사건(Uber의 AI 예산 소진)을 중심으로 같은 문제를 다룬 노트다. 내가 “같다”로 정했던 쌍이다. 모델은 2번(포함 관계)에 0.93을 줬다. 규칙대로라면 모델 쪽이 맞을 수도 있다.
덤으로 앞 글에서 본 선택지 순서 쏠림도 사라졌다. 참·거짓 질문에는 순서를 바꿀 선택지가 없다. 속도는 그대로 한 번에 0.16초 안팎이었다. 질문 세 개를 한 요청에 같이 넣을 수 있어서 호출 수도 늘지 않았다.
아쉬운 점은 확신 값이다. 세 답을 조합한 판단의 확신을 가장 자신 없는 답에 맞춰 계산하니 값이 전반적으로 낮게 나왔다. 확신 0.9 이상인 판단만 따르면 오답은 없지만, 그렇게 걸러지는 쌍이 37쌍 중 12~13쌍뿐이다. 나머지는 여전히 LLM에 넘겨야 한다.
Jev는 나누지 않는 쪽이 나았다 (noul 확률과 confidence 게이팅)
같은 방법을 Jev에 쓰자 결과가 달랐다. 정답 수는 35쌍으로 기준선과 같았는데, 참·거짓 질문에 대한 Jev의 확률이 0.2~0.6 사이에 몰려 있었다. 맞히긴 해도 확신이 약하다는 뜻이고, 확신으로 걸러낼 수 있는 쌍이 크게 줄었다.
Jev는 질문 하나로 묻는 기준선이 가장 쓸 만했다. 35쌍을 맞혔고, 틀린 두 쌍에는 0.2와 0.32의 낮은 확신을 붙였다. 확신 0.8 이상인 답만 따르면 37쌍 중 26쌍을 오답 없이 처리하고, 나머지 11쌍만 LLM에 넘기면 된다. Jev가 앞 글부터 보여 준 장점, 틀릴 때 스스로 자신 없어 한다는 점이 그대로 살아 있는 구성이다.
정리하면 이 케이스에서는 두 모델에 맞는 방법이 갈렸다. Decisions API는 질문을 나눠야 제대로 맞혔고, Jev는 나누지 않고 확신으로 거르는 편이 나았다. 같은 문서 권고라도 모델마다 효과가 달랐다.
시간과 비용 — 판단 1,000번이면 (gpt-6-luna·Decisions API·Jev 요금 비교)
판단 전용 모델로 바꾸면 얼마나 아끼는지도 계산해 봤다. gpt-6-luna는 실제 플러그인 설정(reasoning high)으로 10쌍을 다시 불러 사용량 기록을 받았다. 판단 한 번에 입력이 3,000토큰 안팎이었고, 그중 판단 규칙이 담긴 앞부분 1,386토큰은 캐시돼서 싸게 과금됐다. reasoning을 포함한 출력은 판단 한 번에 100~600토큰 정도였다. 요금은 2026년 10월 기준 공개 가격이다(gpt-6-luna 입력 100만 토큰당 0.10달러, 출력 0.50달러, Decisions API 입력만 0.10달러, Jev 입력만 0.042달러).
| 방식 | 한 번 걸리는 시간 | 1,000번 시간 | 1,000번 비용 |
|---|---|---|---|
| gpt-6-luna (지금 방식) | 약 2.5~3초 | 약 40~50분 | 약 0.36달러 |
| Decisions API, 질문 셋으로 나눔 | 약 0.16초 | 약 3분 | 약 0.2~0.3달러 |
| Jev, 질문 하나 | 약 0.28초 | 약 5분 | 약 0.14달러 |
| Jev가 먼저 보고 확신 0.8 미만만 gpt-6-luna로 | 평균 약 1초 | 약 20분 | 약 0.25달러 |
Decisions API와 Jev의 비용은 같은 입력을 gpt-6-luna가 센 토큰 수로 계산한 추정이고, 마지막 줄은 이번 37쌍에서 Jev가 혼자 처리한 비율(약 70%)을 그대로 쓴 추정이다.
예상과 달랐던 건 비용이다. 판단 전용 모델이 훨씬 쌀 줄 알았는데, gpt-6-luna는 reasoning을 high로 켜도 이 판단에서는 생각을 길게 하지 않았고, 매번 같은 규칙 부분이 캐시돼서 Decisions API와 거의 같은 값이 나왔다. 테스트용 노트 보관소에 지금까지 쌓인 판단이 1,082번인데, 어느 방식으로 했든 0.5달러가 안 된다. 이 규모에서 판단 전용 모델이 주는 건 돈이 아니라 시간이다. 같은 1,000번을 gpt-6-luna로는 40분 넘게 기다리고, Decisions API로는 3분이면 끝난다.
이 결과를 어디까지 믿을 수 있나
숫자를 읽을 때 걸리는 점이 몇 가지 있다.
- 데이터가 작다. 37쌍이고, 한 사람의 노트 보관소에서 나왔다. 한국어와 영어가 섞여 있고 주제도 AI와 업무 쪽에 몰려 있다.
- 같은 데이터로 고쳤다. 질문 문구를 두 번 고치면서 같은 37쌍의 결과를 봤다. 이 데이터에 맞춰진 면이 있을 수 있다. 새 쌍으로 다시 재기 전까지 36/37은 이 데이터에서의 숫자다.
- 정답도 완벽하지 않다. 정답은 내가 노트를 읽고 정했고, 그중 몇 쌍은 규칙을 어떻게 읽느냐에 따라 답이 갈린다. 이번에 남은 오답 하나가 그런 쌍이다.
- 문서 권고가 틀렸다는 뜻도 아니다. 입력 줄이기가 안 통한 건 내 입력에서 지운 부분이 판단 근거였을 가능성이 커서다. 판단과 정말 상관없는 내용을 지우는 경우라면 결과가 다를 수 있다.
남는 생각
앞 글의 결론은 “Decisions API는 내 질문 모양에 맞지 않는다”였다. 이번에 질문 모양을 도구에 맞추자 적어도 이 37쌍에서는 일반 LLM 호출만큼 맞혔다. 도구의 한계로 보였던 것 중 상당 부분이 질문을 어떻게 던지느냐의 문제였던 셈이다.
가장 크게 남는 건 질문 문구 하나의 무게다. “같은 구체적 사건을 요약했나”와 “같은 대상을 같은 범위로 다루나”는 사람이 보기엔 비슷한 질문인데, 모델은 앞의 것을 “같은 기사냐”로 읽었다. reasoning 없이 한 번에 답하는 판단 전용 모델일수록, 질문이 무엇을 묻는지를 글자 그대로 받아들인다. 판단 기준을 질문으로 옮길 때는 내가 의도한 뜻 말고 다른 뜻으로 읽힐 여지가 없는지부터 봐야 했다.
판단 전용 모델은 플러그인에 아직 붙이지 않았다. 새 노트 쌍을 모아 이 구성을 다시 재 보고, 그때도 비슷하게 나오면 그때 붙여 볼 생각이다. 그리고 이 글을 쓴 뒤, 판단 규칙 자체를 다시 보게 됐다. “출처가 다르면 같은 개념이 아니다”라는 출발점이 맞는지부터 따져 봤는데, 그 이야기는 다음 글에 적는다.