Skip to content
게으른 엔지니어의 기술 블로그
Go back

노트북 2의 OpenAI reasoning effort 값이 Medium으로 확인됐다

Read in English →

두 변수를 하나로 착각할 뻔했다 · 7/7편

6편까지 전혀 다른 갈래의 버그 두 개를 더 찾아 고쳤지만, 정작 이 시리즈의 출발점이었던 질문 하나는 아직 답이 없었다. 노트북 2가 1편의 그 실험(노트 189개 대 63개) 당시 실제로 어떤 reasoning effort 값을 쓰고 있었는가.

확인은 다음 날에야 할 수 있었다 — 기기마다 따로인 Obsidian 플러그인 설정

이 값을 확인하는 일 자체는 어렵지 않다. 설정 화면을 열어 값 하나를 보면 끝나는 일이다. 문제는 노트북 2가 낮에 쓰는 회사 노트북이었다는 점이다. 이 볼트는 노트북 두 대와 아이폰까지 동기화 플러그인으로 묶여 있어서 노트는 어느 기기에서나 똑같이 보였지만, 플러그인 설정값은 기기마다 따로였다. 저녁에 집 노트북(노트북 1)이 High라는 걸 확인하고 “노트북 2는 Medium이 아닐까” 하는 의심이 들었을 때, 정작 노트북 2는 회사에 있었다.

그래서 확인은 다음 날 회사에 가서야 할 수 있었다. 그 사이 15시간 남짓 동안 4편의 추가 실험, 5편의 한/영 중복 감지 수정, 6편의 병렬 처리 검증과 버그 두 개 수정이 이어졌다.

확인된 값: Medium — 청크 사이즈 단독 효과로 확정

다음 날 오후, 노트북 2를 열어 직접 확인했다. Medium — 기본값 그대로, 한 번도 바꾼 적이 없었다. 이 값 하나로 지금까지의 조사 전체에 마침표를 찍을 수 있었다.

2편에서 노트북 2가 청크 크기를 6→2→1로 바꿔가며 보여준 fidelity 문제 발생률(40%→10%→0%)은, 처음부터 끝까지 reasoning effort가 Medium으로 고정된 상태에서 나온 결과였다는 뜻이다. 3편에서 걱정했던 “사실은 reasoning effort 차이가 섞여 들어온 것 아니냐”는 의심은 완전히 해소됐다 — 그건 정말 청크 크기 단독 효과였다.

더 힘이 되는 건 이 결론이 교차 검증된다는 점이다. 노트북 2가 청크를 1로 낮췄을 때(Medium, fidelity 0%)와, 4편에서 전혀 다른 시점에 노트북 1이 청크를 1로 고정하고 reasoning effort만 Medium으로 낮췄을 때(역시 fidelity 0%)의 결과가 정확히 같은 지점에서 만난다. 다른 기기, 다른 시점, 같은 설정값 — 그리고 같은 결론. 우연이라고 보기 어려운 일치였다.

4편에서 High로 고정한 채 청크만 낮췄을 때 나왔던 3%→7%라는 작은 변화(2편의 40%→10%→0%에 비하면 미미했던 그 결과)도 이제 설명이 된다. “reasoning effort가 높으면 청크 효과가 줄어든다”는 가설이 맞았던 게 아니라, 그냥 표본이 작아서(원본 30개 중 1~2건) 생긴 자연스러운 편차였던 것이다. Medium 쪽에서 나온 뚜렷한 단조 감소와 비교하면, 청크 크기가 fidelity에 미치는 영향은 reasoning effort 수준과 무관하게 실재하는 효과로 보는 쪽이 지금까지 쌓인 데이터 전체와 가장 잘 맞았다.

최종 결론 — 청크 사이즈와 reasoning effort 설정 가이드

ingestChunkSize(청크 크기)는 낮게(1~2) 유지해서 fidelity를 지킨다. 노트를 얼마나 잘게 쪼갤지와 처리 시간은 openaiReasoningEffort로 따로 조절한다. 두 설정은 겉보기엔 둘 다 “AI에게 얼마나 많은 일을 한 번에 시킬지”에 관련된 값처럼 보이지만, 실제로는 서로 다른 문제를 푸는 완전히 독립적인 손잡이였다.

남는 생각

이 조사를 시작하게 만든 건 노트 개수가 189개에서 63개로 줄었다는 단순한 관찰 하나였다. 그런데 그 차이의 진짜 원인을 확정하기까지, 실험을 여덟 번 다시 설계해서 돌려야 했고 — 그것도 “두 변수가 섞여 있을 수 있다”는 걸 뒤늦게 알아채고 나서야 제대로 갈라낼 수 있었다. 처음 봤을 때 가장 그럴듯해 보였던 단일 원인(청크 크기)이 사실이긴 했지만, 그게 사실이라는 걸 “그럴듯해 보인다”가 아니라 숫자로 확정하는 데는 훨씬 많은 작업이 필요했다.

그리고 이 과정에서 원래 찾으려던 것과 무관한 버그를 세 개나 더 찾아 고쳤다. 한/영 언어를 넘나드는 중복 감지 문턱값 문제, 그 문턱값 수정이 놓친 제품·회사명 노트의 사각지대, 그리고 프롬프트 예시 문구가 언어 규칙을 은근슬쩍 덮어써 버리는 문제까지. 셋 다 원래 하려던 “속도를 높여도 되는가”, “이 두 설정 중 뭐가 문제인가” 같은 질문에 답하는 과정에서 전수 감사를 게을리하지 않았기 때문에 드러난 것들이었다. 그리고 이 모든 걸 확정 짓는 마지막 퍼즐 조각은 결국 코드 분석도 실험 설계도 아니라, 노트북 하나를 열어 설정 값을 직접 눈으로 확인하는 가장 단순한 행동이었다.


Share this post:

두 변수를 하나로 착각할 뻔했다

  1. 1. LLM이 정리한 노트 189개가 어느 날 63개가 됐다
  2. 2. LLM 청크 크기를 낮추기만 했는데 fidelity 문제가 사라졌다
  3. 3. 실험을 다시 준비하던 중에 git 충돌 마커가 그대로 커밋됐다
  4. 4. OpenAI reasoning effort는 fidelity 문제의 범인이 아니었다
  5. 5. 한국어 노트와 영어 노트가 안 합쳐지는 이유를 임베딩 유사도로 확인했다
  6. 6. LLM 요청 동시성을 2에서 4로 올렸더니 다른 버그 두 개가 나왔다
  7. 7. 노트북 2의 OpenAI reasoning effort 값이 Medium으로 확인됐다