Vivek Haldar는 매일 자신의 과거 글을 다시 발굴해 LinkedIn 게시물 초안을 만드는 에이전트 스킬을 운영한다. 이 워크플로우는 원래 자연어 지시만으로 작성되어 있었다. 어떤 소스를 검색할지, 최근에 다룬 글인지 어떻게 확인할지, 어떤 글을 고를지, 최종 초안을 어떤 형태로 만들지 모두 스킬 문서에 적어 둔 방식이다.
원문: How I Cut an AI Agent’s Token Use by 94% — Vivek Haldar
자연어 스킬은 탐색 단계에 적합하다
처음부터 전용 프로그램을 만드는 일은 성급할 수 있다. 어떤 규칙이 정말 필요한지, 어느 단계에서 사람의 판단이 개입하는지, 예외가 얼마나 자주 발생하는지 아직 알 수 없기 때문이다.
자연어로 작성한 스킬은 이때 좋은 실험 도구가 된다. 에이전트는 지시를 해석하고 계획을 세우며 도구를 호출한다. 실행 과정에서 사용자는 실제로 필요한 단계와 불필요한 단계를 관찰할 수 있다. 규칙이 바뀌어도 문서를 고치면 되므로 초기 변화에도 유연하게 대응한다.
문제는 이 방식이 반복 실행에도 그대로 남을 때 발생한다. 에이전트가 매일 같은 위치에서 같은 자료를 읽고, 같은 인벤토리를 만들고, 같은 필터를 적용한다면 모델은 이미 확정된 절차를 매번 다시 추론하게 된다.
반복 실행하면 워크플로우가 굳어진다
몇 차례 실행한 뒤에는 스킬의 동작이 두 종류로 나뉜다.
| 작업 유형 | 예시 | 적합한 실행 방식 |
|---|---|---|
| 결정론적 작업 | 정해진 소스 조회, 목록 생성, 날짜 비교, 최근 게시물 제외 | 일반 코드 |
| 의미 중심 작업 | 후보 글의 흥미도 판단, 독자에게 맞는 관점 선택 | LLM |
| 생성 작업 | 선택한 글을 바탕으로 LinkedIn 초안 작성 | LLM |
원문 사례에서 매번 동일하게 실행되는 부분은 소스 가져오기, 콘텐츠 인벤토리 만들기, 최근 게시물 이력 확인, 필터 적용, 중간 상태 관리다. 이 작업들은 규칙이 충분히 안정되었으므로 Python 같은 일반 코드가 더 빠르고 저렴하게 처리할 수 있다.
반면 어떤 후보가 좋은 재게시 대상인지 판단하는 일은 글의 내용과 맥락을 읽어야 한다. 선택된 글을 짧고 자연스러운 LinkedIn 초안으로 바꾸는 일도 언어 생성이 필요하다. 이 두 지점은 LLM의 강점을 유지해야 한다.
스킬을 컴파일한다는 의미
Haldar가 말하는 컴파일은 자연어를 기계적으로 코드로 번역한다는 뜻이 아니다. 원래 스킬, 여러 번 실행한 trace, 전문 하네스에 관한 설명을 강한 모델에 함께 제공하고, 실제로 모델이 수행했던 작업을 분석해 안정된 부분을 코드로 내리는 과정이다.
자연어 스킬은 높은 수준의 의도를 제공한다. trace는 그 의도가 실제 실행에서 어떤 계획·도구 호출·분기·상태 변경으로 나타났는지 보여 준다. 두 자료를 결합하면 다음과 같은 판단이 가능해진다.
sources = fetch_known_sources()
inventory = build_content_inventory(sources)
recent = load_recent_posts()
filtered = apply_stable_filters(inventory, recent)
candidate = LLM.choose_candidate(filtered)
draft = LLM.write_linkedin_post(candidate)
save_state(candidate, draft)
여기서 앞의 네 단계와 마지막 상태 저장은 코드가 담당한다. LLM은 후보 선택과 초안 작성에만 호출된다. 중요한 점은 모델을 억지로 규칙 엔진으로 대체하지 않는다는 것이다. 의미 이해와 문장 생성이 필요한 작업은 여전히 모델의 영역으로 남긴다.
비용 감소는 모델 교체에서 나오지 않는다
컴파일 후 저자의 측정 결과는 토큰 사용량 94% 감소, 지연 시간 87% 감소였다. 실행 결과의 품질도 자신의 테스트에서는 사실상 유지되었다.
이 개선은 더 작거나 저렴한 모델로 바꿔서 얻은 결과가 아니다. 후보 선택과 초안 작성에는 원래 사용하던 모델을 그대로 사용했다. 모델이 계획·도구 호출·상태 관리까지 담당하던 구조에서, 일반 코드가 처리할 수 있는 일을 제거한 결과다.
이 차이는 에이전트 비용을 볼 때 중요한 관점을 제공한다. 모델 호출 한 번의 가격을 낮추는 일도 중요하지만, 애초에 호출할 필요가 없는 단계를 찾아 제거하는 편이 더 큰 효과를 낼 수 있다.
실무 적용 순서
이 패턴은 반복 실행되는 모든 에이전트 워크플로우에 적용할 수 있다.
- 자연어 스킬로 시작한다. 아직 요구사항과 예외를 모를 때는 유연한 방식으로 실제 흐름을 탐색한다.
- 실행 trace를 모은다. 계획, 도구 호출, 분기, 상태 변경, 실패 지점을 기록한다.
- 안정된 단계를 찾는다. 여러 실행에서 순서와 규칙이 거의 변하지 않는 작업을 표시한다.
- 결정론적 코드를 추출한다. 조회·변환·비교·필터·상태 관리처럼 명확한 작업을 프로그램으로 옮긴다.
- LLM 경계를 좁힌다. 의미 판단, 요지 파악, 생성처럼 언어 능력이 필요한 곳에만 모델을 호출한다.
컴파일 작업 자체에는 일회성 비용이 든다. trace를 읽고 설계를 판단하며 전용 하네스를 작성하려면 강한 모델과 충분한 컨텍스트가 필요하다. 하지만 이후 수백 번, 수천 번 실행할 워크플로우라면 이 비용은 반복 실행마다 절약되는 토큰과 시간으로 상쇄된다.
에이전트의 다음 경쟁력은 전용 하네스다
범용 코딩 에이전트는 매우 뛰어난 추론·워크플로우 엔진이다. 그러나 이미 모양이 정해진 절차를 매번 계획하고 실행하는 데에는 과한 도구일 수 있다. 에이전트가 강해질수록 모든 일을 모델에게 맡기는 방식보다, 모델이 잘하는 부분과 코드가 잘하는 부분을 분리하는 설계가 중요해진다.
이 관점은 독립 개발자와 도구 제작자에게도 기회를 만든다. 반복되는 에이전트 실행을 분석하고, 결정론적 부분을 전용 하네스나 컴파일러로 이동시키면 출력 품질을 유지하면서 비용과 지연 시간을 낮출 수 있다.
다만 처음부터 모든 것을 코드로 고정해서는 안 된다. 아직 탐색 중인 워크플로우를 너무 일찍 컴파일하면 잘못된 규칙과 예외 처리가 프로그램에 굳어질 수 있다. 유동적인 자연어 단계로 시작하고, 실제 실행에서 충분히 반복된 부분만 코드로 내리는 순서가 안전하다.
결론 및 시사점
한 줄 결론: 자연어 스킬로 워크플로우를 발견하고, 실행 trace에서 굳어진 부분만 코드로 컴파일하면 LLM은 판단과 생성에 집중하면서 비용과 지연 시간을 크게 줄일 수 있다.
에이전트 최적화의 핵심은 더 작은 모델을 찾는 데만 있지 않다. 반복 실행에서 모델이 불필요하게 다시 수행하는 계획·도구 호출·상태 관리를 찾아 일반 코드로 옮기는 데 있다. 결국 좋은 에이전트 시스템은 자연어의 유연성과 코드의 결정성을 단계별로 조합한다.