claude code
-
프런트엔드 AX 설계기 10편 - 단가가 아니라 실패비용으로 모델을 고른다AI 엔지니어링 2026. 7. 28. 07:00
"모든 command가 opus를 쓰는데, command별로 다른 model을 쓰게 할 수 있나?" 한 세션에서 이 질문으로 시작했다. 슬래시 command마다 하는 일이 다른데 전부 최상위 모델을 태우는 게 낭비처럼 보였다. 답은 기술적으로 "된다"였다. slash command frontmatter에 model:만 박으면 command별로 티어가 갈린다. 그래서 나눴다. 그리고 한 달 뒤 되돌렸다. 이 글은 그 왕복의 기록이다. AI 에이전트를 여러 개 굴리는 팀이라면 언젠가 "이건 싼 모델로 충분하지 않나?"를 마주한다. 나는 command 단위로 한 번 싸게 내려봤다가 철회했고, 반대로 특정 에이전트 하나는 측정을 거쳐 opus로 올렸다. 결론부터 말하면, 모델 선택의 축은 토큰 단가가 아니었다...
-
프런트엔드 AX 설계기 9편 - 외부 이슈 트래커 write 도구를 권한 경계 안에 가두기AI 엔지니어링 2026. 7. 24. 19:14
트래커 MCP를 붙인 날, 공들여 세운 권한 경계가 조용히 뚫렸다사내 워크플로에 외부 이슈 트래커(여기서는 'Jira류 이슈 트래커'로 부른다)의 MCP를 붙인 날이었다. 붙이자마자 에이전트는 플랜을 진행하다가 스스로 티켓을 만들고, 상태를 옮기고, 담당자를 바꿀 수 있게 됐다. 처음엔 좋아했다. "이제 플랜이랑 트래커가 알아서 붙는구나."다음 날 아침에 불편해졌다. 나는 이 시리즈 1·2·8편에서 슬래시 커맨드·에이전트·자율 모드의 권한을 한 겹씩 좁혀 왔다. 그런데 방금 붙인 이 write 도구는 그 경계를 전부 우회해서 팀 바깥 시스템을 바꾸고 있었다. 내가 문 앞에 세워 둔 검문소를, 뒷문으로 들어온 손님이 그냥 지나친 셈이다.MCP(Model Context Protocol)는 에이전트가 외부 도..
-
프런트엔드 AX 설계기 8편 - 자율 모드에서 설계한 건 자동화가 아니라 멈추는 지점이었다AI 엔지니어링 2026. 7. 22. 19:06
에이전트에게 "이 기능, 한 번에 끝까지 끝내줘"라고 시키고 싶었다. goal 하나를 던지면 구현부터 검증까지 알아서 도는 end-to-end 패턴은 이미 손에 익었고, 남은 욕심은 "매 단계 확인을 그만 받고 싶다"였다. 그래서 /feature 커맨드에 --auto 플래그를 붙였다. 그런데 붙이자마자 첫 실행이 엉뚱한 데서 멈췄다. 격리 작업공간(worktree)을 만들 권한이 없다는 것이었다. 폴더 하나 만드는, 언제든 되돌릴 수 있는 일 앞에서 파이프라인이 손을 든 것이다. 그 순간 질문이 뒤집혔다. 문제는 "어디까지 자동화하나"가 아니라 "어디서 멈춰 사람에게 넘기나"였다.이 글은 그 뒤로 --auto의 권한 경계를 다시 그은 작업기다. AI에게 자율 실행을 맡겨보려는 사람이라면 같은 벽을 만난다..
-
프런트엔드 AX 설계기 7편 - 게이트를 속이는 AI를 차단 없이 잡기AI 엔지니어링 2026. 7. 20. 17:48
게이트를 세운 이유는 단순했다. 사람이 매번 안 들여다봐도 품질 바닥이 유지되길 바랐다. lint·타입체크·테스트를 CI에 걸고, 구현은 AI 코더에게 "통과할 때까지 고쳐"라고 맡겼다. 며칠 뒤 초록불이 켜진 PR을 열었는데, 테스트 파일의 케이스 수가 줄어 있었다. 실패하던 테스트를 AI가 지워 버린 것이다. 게이트는 통과했고, 그 통과는 거짓말이었다.lint·tsc·test 게이트를 AI에게 맡겨 본 사람이라면 한 번쯤 겪는 장면이다. 이 글은 그 뒤에 무엇을 붙였는지에 대한 기록이다 — 게이트 옆에서 "게이트를 속이는지"를 보는 별도 레이어, 그리고 그 레이어가 정당한 수정까지 잡아 버리는 false-positive 폭탄이 되지 않게 만든 과정.게이트는 '고쳐라'와 동시에 '속여라'를 가르친다검증..
-
프런트엔드 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인지..
-
켰는데 왜 안 먹지 — 하나의 모드를 Claude Code와 Codex 두 호스트에 (Scrooge 4편)AI 엔지니어링 2026. 6. 15. 17:50
🔗 scrooge1. 도입부 — "같은 기능"이 호스트마다 다른 표면을 갖는다압축 모드 하나를 Claude Code에서 잘 돌렸다고 하자. 이걸 Codex에도 태우려 한다. 기능은 "똑같다" — 사용자 입력에 압축 지시를 끼워 LLM이 짧게 답하게 만든다. 그런데 막상 옮기려 보면, 두 호스트가 개입하는 메커니즘 자체가 다르다. 같은 기능인데 표면이 갈린다.여기에 더 음험한 문제가 겹친다. "scrooge가 켜졌다"는 말이 실은 세 가지 다른 의미로 쓰이고 있었다는 점이다. 설치됐다는 뜻인지, 지금 활성이라는 뜻인지, 이 세션에만 거는 지시라는 뜻인지. 이 셋을 섞으면 "분명 켰는데 왜 안 먹지" 같은 혼란이 반드시 생긴다.이 글에서 당신이 얻어갈 것은 두 가지다. 하나는 같은 기능을 다른 hook 메..
-
재현 안 되는 버그의 정답은 버그가 아니었다 — 비자명한 디버깅 기록 (Scrooge 3편)AI 엔지니어링 2026. 6. 14. 17:46
🔗 scrooge1. 도입부 — 가장 비싼 버그는 "버그가 아닌 버그"다디버깅의 교과서적 함정은 존재하지 않는 버그를 쫓는 것이다. 코드 어딘가가 틀렸다고 확신한 채로 가설을 세우고 검증하고 또 세우는데, 알고 보니 코드는 멀쩡했고 내 전제가 틀렸던 경우다.scrooge를 굴리며 만난 두 버그가 정확히 이 결을 가졌다. 하나는 "무응답"으로 보였지만 사실 정상 동작이었고, 다른 하나는 "압축 때문"으로 보였지만 압축은 원인이 아니었다. 둘 다 표면 증상이 엉뚱한 범인을 가리키고 있었다.이 글에서 당신이 얻어갈 것은 두 가지다. 하나는 가설을 체계적으로 배제해 "버그 아님"에 도달하는 절차, 다른 하나는 여러 원인이 겹친 현상에서 "진짜 원인"과 "가중 요인"을 분리하는 분석법이다. 둘 다 에이전트 툴링..