서론
지난 글 에서는 본업과 개발을 병행하려고 만든 작업 흐름을 정리했다. 인터뷰로 기획하고, 코덱스가 검토하고, 구현과 리뷰가 알아서 돌다가 막히면 텔레그램으로 연락 오는 구조였다. OMC에 개인 지침과 스킬을 이거저거 덧붙여서 쓰고 있었다.
한달쯤 뒤에 플러그인을 지웠다. OMC 훅이 캐시 문제를 일으키는 것으로 의심됐고, 지운 뒤에는 실제로 캐시 미스율이 크게 낮아졌다.
기획하고 구현하고 리뷰하는 흐름은 대부분 남겼다. OMC를 제거하면서 내가 쓰던 기능 중 어떤 것이 플러그인에 의존하는지 확인하고, 필요한 것은 따로 옮기는 복잡한 과정이었으나 일종의 바이브코딩 튜토리얼로써 재미가 있었다.
캐시가 자꾸 깨지고 있었다
시작은 토큰 사용량이었다. 밤에 일을 하나 시켜놓고 자러갔다 왔더니 클로드 x20 요금제에서 하룻밤 사이에 주간 사용량의 40% 정도 올라가길래 로그를 봤더니, 이미 보낸 대화를 캐시에서 읽지 못하고 대량으로 다시 쓰는 일이 반복되고 있었다. 캐시로 재사용하면 싸게 처리할 내용을 계속 다시 처리하고 있었던 거다.
코딩 에이전트는 내가 방금 친 문장만 보고 일하는 게 아니라 앞에서 읽은 코드, 도구 실행 결과, 정해 둔 규칙 같은 맥락을 다음 요청에도 같이 받는다. 앞부분이 같으면 캐시를 재사용해서 비용을 줄일 수 있다.
그런데 내 로그에서는 잘 읽던 캐시가 갑자기 줄고 다시 쓰는 양이 늘었다가, 바로 다음 요청에서는 또 정상적으로 읽혔다. 작업이 멈추거나 답변이 이상해지는 것도 아니었다. 겉으로는 계속 잘 일하고 있으니 사용량을 따로 보지 않으면 모르고 지나갈 만했다.
조사하다가 Claude Code 공개 이슈 를 찾았다. 스레드에서는 훅이 넣은 문장처럼 뒤늦게 들어온 내용을 처리하면서 이미 보낸 메시지가 바뀌고, 그 때문에 캐시를 재사용하지 못하는 문제를 다루고 있었다.
내 요청에서도 비슷한 게 보였다. OMC는 도구를 쓰기 전후에 훅으로 지시사항을 넣고 있었는데, 그 문장들이 쌓이다가 나중에 다른 형태로 바뀌었다. OMC를 끈 대조 세션에서는 그 누적과 변형이 나타나지 않았다.
훅이 하는 일 자체는 이상한 게 아니었다. 도구를 쓰기 전에 지켜야 할 규칙을 알려주거나, 작업이 끝난 뒤 확인할 것을 상기시키는 식이다. 다만 이미 대화에 들어갔던 문장이 나중에 다른 형태로 다시 조립되면, 사람 눈에는 같은 지시사항이어도 캐시가 비교하는 앞부분은 달라질 수 있었다. 긴 대화에서 이게 반복되고 있었다.
공개 이슈와 내 캡처를 맞춰보고, OMC 훅이 넣는 컨텍스트를 클로드 코드가 다시 조립하는 과정에서 캐시가 깨진다고 잠정 결론을 내렸다. 훅이 과거 대화를 직접 고치는 건 아니지만 내 환경에서는 그 훅이 클라이언트의 문제를 건드리고 있는 것으로 봤다. 그래서 우선 해당 훅을 끄기로 했다.
훅을 끄고 보니 플러그인도 필요한가 싶었다
그러고 나니 나머지 기능 때문에 OMC를 계속 유지해야 하는지도 궁금해졌다. 실제 사용 기록을 보니 제일 많이 부른 건 내가 만든 리뷰 스킬과 커밋 스킬이었다. OMC 스킬은 50개쯤 있었는데, 마지막 세션에서 내가 쓴건 deep-interview 하나였다.
훅만 끄고 계속 쓰는 방법도 있었다. 그런데 필요한 기능을 따로 가져올 수 있다면 OMC에 연결된 부분까지 계속 유지할 필요는 적었다. 그래서 전부 버리기 전에 스킬을 하나씩 열어보고 가져올 것과 남길 것을 골랐다.
그래서 당시에는 필요한 것만 가져오고 플러그인은 지웠다. deep-interview는 OMC 없이 동작하게 고쳤고, 쓸 만한 스킬 몇 개도 같이 옮겼다. 사용량을 보여주는 HUD와 텔레그램 알림은 남겼다. 코덱스를 부르는 명령도 작은 스크립트로 대체했다.
그런데 deep-interview도 이후 하네스를 다시 정리하면서 지웠다. 7월에는 일단 쓸 것을 옮겨서 플러그인을 없앴고, 그 뒤에는 따로 남겨 둔 스킬도 다시 정리한 셈이다.
어쨋든 내가 하는 일은 크게 달라지지 않았다. 원하는 걸 설명하고, 중간에 판단이 필요한 부분을 확인하고, 완성된 걸 테스트하는 흐름은 그대로였다. 지난 글에서 원했던 것도 이거였으니 그 부분까지 같이 버릴 필요는 없었다.
지우고 나서는
OMC를 제거한 뒤 캐시 미스율이 급격히 낮아졌다. 특히 그전에는 백그라운드 알림을 받을 때 종종 깨지던 캐시가, 제거 당일 조사한 알림 요청에서는 한 번도 깨지지 않았다.
같은 날 에이전트에 메시지를 보내는 방식도 바꿨으니 OMC 하나만의 문제였다고 확정하지는 못했다. 그래도 훅을 의심해서 걷어냈고, 그 뒤 눈에 띄게 나아졌으니 다시 켤 이유는 없었다.
알림 자체가 없어져서 미스가 안 잡힌 것도 아니었다. 백그라운드 작업의 알림은 계속 들어왔고, 그 요청들에서 이전처럼 캐시가 깨지는지 본 결과였다. 필요한 기능을 유지하면서 문제로 보이던 증상을 줄였다는 점에서, 내 환경에서는 제거할 만한 이유가 있었다.
그날만 우연히 조용했던 건지도 뒤에 다시 봤다. 8월 초와 말의 점검에서도 미스는 제거 전보다 낮게 유지됐다. 아예 없어졌다는 얘기는 아니다. 가끔 깨지는 요청은 남았지만, 처음 이걸 뜯어보게 만든 수준으로 돌아가지는 않았다.
플러그인을 끄기 전후로 세션 시작에 들어가는 입력도 비교해봤는데, 그건 약 3천 토큰 줄어드는 정도였다. 설치된 파일을 많이 지웠다고 시작 비용이 엄청 줄어드는 건 아니었다.
결론
지난 글을 쓸 때는 잘 굴러가는 구조를 만들었다고 생각했다. 실제로 필요한 작업도 해주고 있었으니까. 그런데 작업 결과가 잘 나오는 동안에도 뒤에서는 같은 내용을 계속 다시 처리하고 있을 수 있었다. 그걸 유지하는 데 얼마나 드는지는 따로 봐야 했다.
캐시 문제 때문에 뜯어봤고, 그러고 나서야 플러그인 전체를 들고 있지 않아도 내가 쓰던 흐름을 유지할 수 있다는 걸 알았다. 일단 가져왔던 deep-interview까지 나중에 지운 걸 보면, 그때 남긴 것들이 끝까지 남는 것도 아니었다.
이때 사용량 한도를 한번 얻어맞고, 이후에 모델들 가격이 비싸지면서(반대로 말하면 구독제의 사용량 한도가 줄어들면서) 오케스트레이션을 적극적으로 하거나 싼 모델을 찾아다니게 되었다. 이건 다음 글에서 이어서 적겠습니다.