추가: 물론 이 방식은 과거에 이미 누군가 구현한 것이다! 크게 의심하지는 않았지만 트위터에서 사람들이 확인해 주었다 :) 그래도 계속 읽어보길 바란다. 마지막에 나오는 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이 라인 정보를 여러모로 활용할 수 있기 때문이다. 예를 들어 연속된 툴 호출에서 범위를 지정하는 식이다. 태그를 활용하는 다른 방법도 있을지 모른다. 이를테면 is this line still dj4_? 같은 식으로 말이다.

흥미로운 점은 DeepSeek v4 Flash가 이 툴을 매우 효과적으로 사용한다는 것이다. 보기에는 이 방식이 모델에게 꽤 자연스러운 모양이다. 정확한 절약량을 측정하지는 않았지만, 현장에서 편집 속도가 훨씬 빨라졌고 신뢰성도 오히려 높아진 것을 체감했다.

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

어느 쪽이 더 나은지는 두 방식을 ds4-agent에서 여러 세션에 걸쳐 직접 써보며 충분한 실전 데이터를 쌓아야 판단할 수 있을 것 같다. 당장은 편집 모드를 전환할 수 있는 커맨드라인 옵션을 만드는 것이 가장 합리적인 첫걸음일 듯하다.