EDIT: 물론 이건 예전에 이미 누군가 했던 것이다! 사실 어느 정도 예상은 했지만 트위터에서 사람들이 확인까지 해줬다 :) 그래도 계속 읽어보시라. 마지막에 나오는 CRC32 절충안은 꽤 흥미로운 트레이드오프고, 어쨌든 한번쯤 논의해볼 만한 주제다.

지금 DS4 프로젝트를 위한 에이전트를 만들고 있다. 로컬 추론 환경은 토큰이 부족하다. 최적화 하나하나가 중요한 전장이나 다름없다. 지금 모두가 쓰고 있는 EDIT 툴이 LLM에게 텍스트의 이전 버전을 그대로 토해내도록 강제한다는 사실에 꽤 놀랐다. EDIT old="foo" new="bar" 형태로 동작하는 이 CAS(check and set) 방식은 필요한 것이긴 하다. 충돌하는 편집이 자주 일어나기 때문이다 — 사용자가 동시에 편집하고 있을 수도 있고, 다른 브랜치를 체크아웃했을 수도 있는 등 여러 상황이 있고, 또 LLM이 특정 줄의 내용이 이랬다고 그냥 환각을 일으킬 수도 있기 때문이다.

결국 라인 번호만 쓰는 건 매우 취약하다는 뜻이다. 22번째 줄을 new="foobar"로 바꿔라 같은 방식은 좋지 않다. 그렇다고 매번 예전 텍스트를 다시 쓰느라 로컬 LLM이 토큰을 낭비하게 하고 싶지도 않다. 게다가 예전 텍스트에 특수 문자나 공백이 많으면 모델이 틀리기 쉬운데, 그러면 툴 호출이 실패하고 LLM은 같은 편집을 다시 시도해야 한다. 그래서 나는 (다시) CAS 스타일을 유지하면서도 토큰 효율적인 태그 기반 EDIT 툴을 설계했다.

READ와 SEARCH 툴은 이런 식의 결과를 반환한다:

10:Q8fA int count = 10;
11:rA3_ if (count > limit) {
12:Kq9z     count = limit;
13:PX0b }

즉 라인 번호와 태그가 함께 있는 셈이다. 태그는 4글자로 평균 2.5 LLM 토큰 정도이며, 해당 라인의 체크섬을 나타낸다. 이제 LLM은 이렇게 편집할 수 있다:

{
  "tool": "edit",
  "path": "/tmp/example.c",
  "line": 10,
  "tag": "Q8fA",
  "new": "int count = 11;"
}

또는 여러 줄을 이렇게:

{
  "tool": "edit",
  "path": "/tmp/example.c",
  "lines": "11:rA3_\n12:Kq9z\n13:PX0b",
  "new": "if (count > limit)\n    return limit;"
}

절약되는 토큰은 특히 에이전트가 대량의 텍스트를 삭제할 때 상당하지만, 일반적인 경우에도 마찬가지다. 다만 라인 번호와 태그 때문에 생기는 오버헤드도 있다. 잠재적인 트레이드오프도 있다. 태그를 8글자로 늘리고 라인 번호까지 해시에 포함시켜야 할지도 모른다. 충돌 가능성과 토큰화를 정확히 따져봐야 얼마나 이득인지 알 수 있겠지만, 나는 line:tag 형식이 마음에 든다. LLM이 나중에 라인 정보를 여러 방식으로 활용할 수 있기 때문이다. 예를 들어 연속된 툴 호출에서 범위를 가져오는 식이다. 태그를 활용하는 다른 방법이 있을지도 모른다. 예를 들어 ‘이 라인이 아직 dj4_인가?’ 같은 식으로 말이다.

흥미로운 점은 DeepSeek v4 Flash가 이 툴을 매우 효과적으로 사용할 수 있다는 것이다. 보기에는 꽤 자연스럽게 받아들이는 것 같다. 정확한 절약량을 측정하지는 않았지만, 현장에서 편집이 훨씬 빠르고 오히려 더 안정적이라는 걸 체감했다.

이에 대한 대안은 매번 전체 파일의 CRC32만 반환하는 것이다(기본적으로 부분 읽기에서도 태그가 파일 태그가 되는 셈이다). 그러면 라인 번호 + CRC만으로 작업하게 되고, 편집 시에는 그냥 11,12,13,14처럼 지정하면 된다. 당연히 토큰은 더 적게 든다. 다만 이 방식은 매번 파일의 CRC32를 다시 계산해야 하는데, 적당한 크기의 파일이라면 충분히 저렴하다. 하지만 이 접근법에는 한계가 있다. 관련 없는 곳에서 변경이 일어나도 편집이 실패하기 때문에 강한 트레이드오프가 존재한다. 전체 파일 방식을 두둔하자면, 10:23처럼 범위를 지정할 수 있다는 점은 엄청난 이득이라고 할 수 있다.

어느 쪽이 더 나은지는 두 시스템을 가지고 ds4-agent를 여러 세션에 걸쳐 써보며 충분한 실제 증거가 쌓여야만 판단할 수 있을 것 같다. 당장은 편집 모드를 전환할 수 있는 커맨드라인 옵션을 만드는 게 가장 올바른 첫걸음일 듯하다.