GitHub 에이전트 워크플로우 토큰 효율화 공부 정리

GitHub 블로그에서 에이전트 워크플로우 관련 글을 읽었는데, 제목부터 와닿는 구석이 있었다. “조용히 API 비용이 쌓인다”는 표현이 딱 그랬다. PR이 올라올 때마다 자동으로 에이전트가 돌고, 그 비용이 눈에 안 보이다가 어느 순간 청구서로 나타나는 상황. 그 문제를 GitHub 팀이 직접 파악하고 개선한 과정을 정리한 글이었다.

처음에 스크롤을 훑을 때는 “API 비용 줄이기 팁”쯤으로 봤는데, 읽어보니 조금 달랐다. 단순히 비용을 아끼는 게 아니라, 에이전트가 어떻게 돌아가는지를 먼저 볼 수 있게 만드는 것부터 시작한다는 점이 흥미로웠다.

1️⃣ 이게 뭐냐?

핵심은 두 가지 구조다. 하나는 API 프록시 기반 로깅, 다른 하나는 자가 최적화 에이전트다.

로깅부터 보면, Claude CLI나 Copilot CLI 같은 서로 다른 프레임워크에서 나오는 로그를 하나의 형식으로 정규화해서 쌓는다. 입력/출력/캐시 토큰이 어떻게 쓰이는지 한눈에 볼 수 있게 되고, 이 데이터가 이후 최적화의 재료가 된다.

비용을 단순히 토큰 개수로만 보면 모델마다 단가가 달라서 비교가 어렵다. 그래서 캐시 읽기를 0.1배, 출력 토큰을 4배로 가중치를 두는 “유효 토큰” 지표를 따로 만들었다. 이걸로 서로 다른 모델로 돌린 워크플로우를 같은 선 위에 놓고 볼 수 있게 된다.

그 다음이 흥미롭다. “Daily Token Usage Auditor”와 “Daily Token Optimizer”라는 에이전트 두 개를 따로 만들었다. 하나는 토큰 소비 패턴을 분석해 이상 징후를 잡아내고, 다른 하나는 워크플로우 소스를 직접 들여다보고 최적화 제안을 GitHub 이슈로 남긴다. 에이전트가 에이전트를 감시하는 구조다.

실제 최적화 방식 중 인상적인 건 “미사용 도구 제거”였다. 40개 도구를 등록해 놓고 실제로는 2개만 쓰는 경우, 나머지 38개의 스펙이 매 턴 컨텍스트에 그대로 쌓이고 있었다는 거다. 안 쓰는 도구를 빼는 것만으로 턴당 꽤 많은 컨텍스트가 줄었다고 한다.

또 하나, “결정적 데이터는 LLM 추론 밖으로” 패턴이 있었다. 에이전트가 이슈 메타데이터를 매번 직접 가져오게 두는 대신, 워크플로우 시작 전에 미리 CLI로 뽑아서 파일로 넘겨주는 식이다. 글에서 가장 큰 효과를 낸 기법이라고 했다.

2️⃣ 내가 든 생각

읽으면서 계속 걸리는 부분이 있었다. 에이전트를 만들 때 “이게 왜 비싼지”를 애초에 알기 어렵다는 점이다. 로그가 없으면 어디서 토큰이 새는지도 모른다. 결국 프록시를 끼워서 관찰 가능성을 먼저 확보하는 게 출발점인데, 그 단계가 없으면 최적화 방향 자체를 잡기 어려운 것 같다.

👉🏻 “제일 싼 LLM 호출은 하지 않는 호출이다” — 글 전체를 요약하는 한 줄인 것 같았다. 결정적으로 구할 수 있는 데이터를 LLM에게 물어보게 두지 말라는 뜻인데, 당연한 말인 것 같은데도 에이전트를 짜다 보면 흐릿해지는 경계인 것 같다.

💡 어디까지 LLM이 판단하고, 어디까지 코드가 처리해야 할까?

디자이너 관점에서 보면, 이건 컴포넌트 설계에서 “이 로직이 누구 책임이냐”를 정하는 문제랑 닮아 있다. 데이터 페칭을 부모가 하냐 자식이 하냐, 경계를 어디서 긋느냐. 에이전트도 결국 그 책임 경계 문제인 것 같다.

측정 얘기도 흥미로웠다. 토큰 수를 줄이는 건 할 수 있어도, 그게 출력 품질도 같이 떨어뜨린 건지 판단하기가 어렵다고 했다. 턴 수나 도구 완료율 같은 간접 신호로 볼 수밖에 없다는 걸 솔직하게 인정하는 부분이 인상적이었다.

⭐️ 마지막으로

공부 끝에 남은 건 “측정할 수 없으면 최적화할 수 없다”는 말이 생각보다 실제라는 인상이다. 에이전트가 뭘 하는지 보이지 않으면 개선 방향조차 잡기 어렵다. 이번 글에서는 관찰 가능성을 갖추는 것 자체가 첫 번째 과제였고, 나머지는 그 다음 문제였다.

---

참고 원문: Improving token efficiency in GitHub Agentic Workflows