ax
-
프런트엔드 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인지..
-
프런트엔드 AX 설계기 3편 — `done` 경계를 측정으로 설계한 이야기AI 엔지니어링 2026. 7. 1. 19:51
1. 도입부 (Why This Matters)done은 안전해 보이는 단어다. 그런데 AI 보조 개발에서 done은 두 번 위험하다 — 작업이 들어갈 때, 그리고 나온 뒤.나온 뒤부터 보자. 대부분의 PM 도구는 작업 상태를 단방향으로 본다. specification → planned → in-progress → done. 한번 done이면 끝. "완료된 작업은 완료된 채로 남는다"는 가정 위에 서 있다. 사람만 일하던 시절엔 버텼다. 그러나 AI 에이전트는 task 7을 구현하다 이미 done인 task 2의 설계 결함을 드러내고, 당신은 의도를 실시간으로 바꾼다. 단방향 모델에는 무효화된 done을 표현할 자리가 없다.들어갈 때도 함정이 있다. AI가 짠 코드를 사람이 다 읽을 수 없으니, AI가 A..
-
프런트엔드 AX 설계기 2편 — 에이전트를 '자율 실행'에서 '명시적 동의'로AI 엔지니어링 2026. 6. 26. 19:16
1. 도입부 (Why This Matters)에이전트 도구를 처음 세팅하면 거의 모두 "자동"에 끌린다. 리뷰 에이전트, 문서 에이전트, 비평 에이전트를 만들어 두면 알아서 끼어들어 일을 거든다 — 적어도 그럴 거라 기대한다. 나도 그렇게 시작했다. 역할별 커스텀 에이전트 6개를 만들고, 요청이 들어오면 시스템이 알아서 적절한 에이전트를 골라 활성화하도록 했다.그리고 몇 주 뒤, 그 자동 활성화를 전부 껐다. 모든 에이전트를 명시적으로 호출할 때만 실행되는 '기본 OFF' 정책으로 되돌렸다.이 글은 그 회귀의 기록이다. 왜 자율성을 포기했는지, 그 대가로 무엇을 잃었는지, 그리고 "수백 개 에이전트를 상시 돌린다"는 마케팅을 최신 논문·토큰 데이터로 걸러낸 뒤 내린 절충안까지 다룬다. 도입을 고민하는 리..
-
프런트엔드 AX 설계기 1편 — AI 에이전트 설정을 4개 레이어로 쪼갠 이유AI 엔지니어링 2026. 6. 24. 19:13
1. 도입부 (Why This Matters)에이전트 설정을 처음 만들 때는 보통 한 파일에 다 적는다. "이런 상황에선 이렇게 해라"(instruction)와 "그러면 커밋하고 푸시해라"(권한이 필요한 행동)를 같은 스킬 문서에 함께 둔다. 혼자 쓸 때는 문제가 없다.문제는 에이전트 도구가 스킬을 모델이 알아서 불러오는 기능(auto-invoke)을 갖추면서 시작된다. 모델이 "지금 이 스킬이 필요해 보인다"라고 판단하면 사용자가 부르지 않아도 그 문서가 로드된다. 그런데 그 문서 안에 "로드되면 git add → commit → push 한다"가 적혀 있다면? 스킬이 로드되는 것만으로 부수효과가 실행될 수 있는 구조가 된다. instruction을 담는 모듈과 권한을 부여하는 경계가 같은 곳에 있었기..
-
프런트엔드 AX 설계기 0편 — 레거시 3개와 차세대 FE를 위한 워크플로우 설계기AI 엔지니어링 2026. 6. 19. 19:26
1. 도입부 (Why This Matters)React 15에 묶인 레거시 프로젝트 3개와, Next.js 기반 차세대 프로젝트들을 한 사람이 동시에 굴리는 상황을 떠올려 보자. 프로젝트마다 컨벤션이 다르고, 빌드 함정이 다르고, "여기서는 이렇게 하면 안 된다"는 암묵지가 다르다. 컨텍스트 스위칭 비용만으로도 하루가 샌다.여기에 AI를 얹으면 처음엔 빨라진 것 같다. 그런데 곧 다른 종류의 비용이 보인다. 채팅창에 그때그때 프롬프트를 복붙 하니 결과가 매번 다르고, AI가 건드리면 안 되는 곳을 건드려도 막을 경계가 없고, 잘 된 흐름을 재현할 수도 팀에 넘길 수도 없다. 산발적 사용의 한계는 속도가 아니라 운영 가능성에서 드러난다.이 글은 그 한계를 마주한 FE 한 명이 4개월에 걸쳐 AI 워크플로를..
-
안 깎는 것이 실력이다 — 압축 도구가 거부해야 할 출력 (Scrooge 2편)AI 엔지니어링 2026. 6. 13. 17:42
🔗 scrooge1. 도입부 — 압축 도구의 진짜 위험은 "덜 압축"이 아니다압축 도구를 만들 때 본능적으로 좇는 목표는 "최대한 깎기"다. 그런데 출력 압축에는 일반적인 성능 최적화에 없는 위험이 하나 있다. 너무 잘 깎으면 사람이 다친다.예를 들어 LLM이 이런 출력을 내야 하는 상황을 생각해 보자. "이 명령은 데이터베이스를 복구 불가능하게 삭제합니다. 실행 전 백업을 확인하세요." 압축 규칙이 이걸 "DB 삭제 주의"로 깎았다고 하자. 토큰은 줄었다. 하지만 복구 불가능이라는 사실과 백업 확인이라는 행동 지시가 사라졌다. 사용자가 이 경고를 가볍게 보고 명령을 실행하면, 줄인 토큰 몇 개가 데이터 전체와 맞바꿔진다.그래서 잘 만든 압축 도구의 핵심 설계는 "어떻게 더 깎을까"가 아니라 "무엇을 ..
-
측정하지 않으면 압축이 아니다 — 출력 압축 도구의 효과를 재는 법 (Scrooge 1편)AI 엔지니어링 2026. 6. 12. 15:53
🔗 scrooge1. 도입부 — "더 압축하자"가 위험한 이유압축 도구를 며칠 굴리다 보면 자연스러운 다음 생각이 떠오른다. *"영문 출력을 좀 더 깎을 수 있지 않을까?"* 규칙을 한두 줄 더 공격적으로 쓰면 토큰이 더 줄 것 같다.이 충동은 합리적으로 보이지만, 실은 방향을 모르는 최적화다. 더 깎았을 때 토큰이 정말 줄어드는지, 줄어든다면 얼마나 줄어드는지, 그 대가로 무엇이 깨지는지 — 이걸 모르는 채로 규칙만 더 공격적으로 쓰는 건 도박이다. 압축 도구에서 "규칙을 더 공격적으로"는 곧 출력의 명료성(auto-clarity)과 안전 register를 깎는 쪽으로 압력을 주는 일이기 때문이다. 이득은 불확실한데 위험은 확실하다.그래서 scrooge 개발 중 "더 압축하자"는 plan을 의도적으로..
-
토큰은 돈이다 — 한국어를 위한 LLM 출력 압축 도구 (Scrooge 0편)AI 엔지니어링 2026. 6. 10. 13:30
🔗 scrooge1. 도입부 — 왜 이 이야기가 중요한가LLM에게 길게 답하지 말라고 시켜본 적 있을 것이다. "간결하게", "불릿으로", "200자 이내로". 이게 단순한 취향 문제가 아닌 이유는, 출력 토큰이 곧 비용이자 지연시간이기 때문이다. 같은 정보를 절반의 토큰으로 전달할 수 있다면, 그건 API 청구서와 응답 속도에 직접 꽂히는 최적화다.그래서 "LLM 출력을 압축하자"는 도구들이 등장했다. 그런데 이들을 들여다보다가 한 가지가 걸렸다. 압축의 상당 부분이 영어의 약어 관습, 심하면 한문(Classical Chinese)식 함축에 기대고 있었다. 토큰을 줄이는 영리한 트릭이지만, 그 트릭을 읽어내려면 독자가 그 언어 문화의 소양을 갖고 있어야 한다. 압축된 출력이 누군가에게는 더 읽기 어려..