수백 개 파일에 흩어져 있는 같은 패턴을 전부 고쳐야 하는 상황, 다들 한 번쯤 겪어보셨을 거예요. 오래된 API를 새 걸로 바꾸거나, 로깅 방식을 통일하거나, 라이브러리 메이저 버전을 올리는 그런 작업이요. 요즘은 이런 걸 AI 에이전트에게 통째로 맡기고 싶어지는데, 막상 해보면 두 가지 문제에 부딪혀요. 토큰 비용이 무섭게 나오고, 파일마다 미묘하게 다르게 고쳐놔서 일관성이 깨진다는 거죠. 이 문제에 대해 프런티어 모델은 단 한 번의 수정에만 필요하다는 흥미로운 접근이 나왔어요.
아이디어는 이래요
프런티어 모델이 뭐냐면, 각 회사의 최상위 버전처럼 가장 똑똑하지만 가장 비싼 모델을 말해요. 이 접근의 핵심은 그 비싼 모델을 딱 한 곳에만 쓰는 거예요. 순서로 보면 이렇게 돼요.
1. 고쳐야 할 수백 곳 중에서 대표 사례 하나를 골라, 가장 똑똑한 모델에게 맡겨서 완벽하게 수정해요. 일종의 모범 답안을 만드는 거죠.
2. 그 수정 전후를 비교해서 변환 규칙으로 일반화해요. 이런 모양의 코드는 이런 모양으로 바뀐다는 패턴을 뽑아내는 거예요.
3. 나머지 수백 곳에는 그 규칙을 기계적으로 적용해요. 저렴한 소형 모델이 맡거나, 아예 AST 변환 같은 결정적 도구가 처리하는 거죠.
여기서 AST가 뭐냐면 추상 구문 트리(Abstract Syntax Tree)라고, 코드를 글자의 나열이 아니라 문법 구조로 표현한 트리예요. 코드를 이 구조로 다루면 함수 이름만 바꾸고 인자는 그대로 둔다 같은 수정을 단순 검색-치환보다 훨씬 정확하게, 그리고 몇천 곳이든 완전히 똑같이 반복할 수 있어요. 사람으로 비유하면, 시니어가 첫 번째 사례를 직접 풀어서 가이드 문서를 만들고, 나머지는 그 가이드대로 일괄 처리하는 것과 같은 구조인 거죠.
왜 이 방식이 합리적일까요
일단 비용이에요. 프런티어 모델과 소형 모델의 API 가격은 수십 배까지 차이 나거든요. 500개 파일을 전부 최상위 모델로 고치는 것과, 1개만 최상위 모델로 고치고 나머지를 규칙으로 처리하는 건 자릿수가 다른 비용이 나와요. 그런데 더 중요한 건 일관성과 검증이에요. LLM은 같은 지시를 줘도 파일마다 조금씩 다르게 고칠 수 있는데, 규칙 기반 변환은 결과가 결정적이라 리뷰할 때 규칙이 맞는지만 확인하면 되거든요. 500개의 제각각인 수정을 하나하나 리뷰하는 것보다 훨씬 안전하죠.
사실 이 계보의 도구들은 원래 있었어요. 자바스크립트 진영의 jscodeshift 같은 codemod 도구, 구조 검색 도구 ast-grep, 자바 진영의 OpenRewrite 같은 것들이요. 다만 지금까지는 변환 규칙을 사람이 직접 짜야 해서 진입장벽이 높았는데, 이제 그 규칙을 LLM이 만들어주면서 LLM으로 규칙을 만들고 규칙으로 코드를 고친다는 조합이 실용적인 패턴이 된 거예요.
당장 써먹는 법
다음에 대규모 마이그레이션을 만나면 에이전트한테 전부 고쳐달라고 하는 대신, 이 파일 하나를 고치고 같은 변경을 적용할 codemod 스크립트를 만들어달라고 해보세요. 결과물 검증도 쉬워지고 비용도 확 줄어요. 변경 규모가 클수록, 패턴이 반복적일수록 효과가 커지고요. 반대로 파일마다 맥락 판단이 필요한 수정이라면 이 방식이 안 맞으니, 기계적으로 반복되는 부분과 판단이 필요한 부분을 먼저 구분하는 게 시작이에요.
정리하면, 비싼 모델의 역할은 노동이 아니라 시범이라는 거예요. 여러분은 대규모 코드 변경을 어떻게 처리하고 계세요? codemod와 에이전트, 어느 쪽이 잘 맞던가요?
🔗 출처: Hacker News