eval
-
프런트엔드 AX 설계기 10편 - 단가가 아니라 실패비용으로 모델을 고른다AI 엔지니어링 2026. 7. 28. 07:00
"모든 command가 opus를 쓰는데, command별로 다른 model을 쓰게 할 수 있나?" 한 세션에서 이 질문으로 시작했다. 슬래시 command마다 하는 일이 다른데 전부 최상위 모델을 태우는 게 낭비처럼 보였다. 답은 기술적으로 "된다"였다. slash command frontmatter에 model:만 박으면 command별로 티어가 갈린다. 그래서 나눴다. 그리고 한 달 뒤 되돌렸다. 이 글은 그 왕복의 기록이다. AI 에이전트를 여러 개 굴리는 팀이라면 언젠가 "이건 싼 모델로 충분하지 않나?"를 마주한다. 나는 command 단위로 한 번 싸게 내려봤다가 철회했고, 반대로 특정 에이전트 하나는 측정을 거쳐 opus로 올렸다. 결론부터 말하면, 모델 선택의 축은 토큰 단가가 아니었다...
-
프런트엔드 AX 설계기 6편 - done은 직관으로 정하는 상태가 아니다AI 엔지니어링 2026. 7. 17. 17:51
에이전트에게 일곱 번째 task를 맡긴 참이었다. 구현 도중 에이전트가 두 번째 task —이미 done으로 닫아둔— 의 설계가 틀렸다는 걸 스스로 드러냈다. 나는 잠깐 멈췄다. 상태 판에는 분명 done이라 적혀 있는데, 그 done은 더 이상 사실이 아니었다. 팀에 AI 보조 개발을 들이면 이 장면을 반드시 만난다. 사람이 혼자 짤 때보다 에이전트는 더 자주, 더 빨리 앞선 결정을 무너뜨린다(빈도는 내 운영 관찰이지 벤치마크는 아니다 — 추정으로 읽어달라). 그런데 내가 쓰던 상태 도구에는 그 상황을 적을 칸이 없었다.이 글은 그 뒤로 done이라는 상태를 다시 설계한 작업기다. 두 군데가 나를 물었다. done에서 나오는 쪽과, 애초에 done으로 들어가는 쪽. 두 번 다 내 직관이 틀렸고, 두 번..
-
프런트엔드 AX 설계기 4편 - LLM-as-judge는 왜 "다른 에이전트"가 채점해야 하는가AI 엔지니어링 2026. 7. 3. 19:47
1. 도입부 (Why This Matters)AI가 spec을 쓰고, 같은 세션에 "이 spec 괜찮아?"라고 물으면 거의 항상 "좋다"는 답이 돌아온다. 점수를 매기게 해도 마찬가지다 — 늘 0.85쯤에서 통과한다. 자동 검증을 붙였다는 안도감은 크지만, 실제로 돌아간 건 검증 연극(theater)에 가깝다.이 글은 그 자기 채점이 왜 항상 통과하는지(self-preference bias), 그걸 체크를 더 넣는 대신 구조로 어떻게 풀었는지(writer/evaluator 분리 + 절대 rubric + 실데이터 임계값 보정), 그리고 모델을 상위 티어로 올린 뒤에도 이 분리가 여전히 필요한지 A/B로 재측정한 결과까지 담는다. 읽는 데 8~10분. 다 읽고 나면 지금 돌리는 자동 검증이 theater인지..
-
측정하지 않으면 압축이 아니다 — 출력 압축 도구의 효과를 재는 법 (Scrooge 1편)AI 엔지니어링 2026. 6. 12. 15:53
🔗 scrooge1. 도입부 — "더 압축하자"가 위험한 이유압축 도구를 며칠 굴리다 보면 자연스러운 다음 생각이 떠오른다. *"영문 출력을 좀 더 깎을 수 있지 않을까?"* 규칙을 한두 줄 더 공격적으로 쓰면 토큰이 더 줄 것 같다.이 충동은 합리적으로 보이지만, 실은 방향을 모르는 최적화다. 더 깎았을 때 토큰이 정말 줄어드는지, 줄어든다면 얼마나 줄어드는지, 그 대가로 무엇이 깨지는지 — 이걸 모르는 채로 규칙만 더 공격적으로 쓰는 건 도박이다. 압축 도구에서 "규칙을 더 공격적으로"는 곧 출력의 명료성(auto-clarity)과 안전 register를 깎는 쪽으로 압력을 주는 일이기 때문이다. 이득은 불확실한데 위험은 확실하다.그래서 scrooge 개발 중 "더 압축하자"는 plan을 의도적으로..