내 시간과 토큰을 조용히 낭비하고 있었던 AI 에이전트 습관

태그: ai, localai, machinelearning, productivity, agents

나는 내가 똑똑해 보이지만 실제로는 꽤나 낭비적인 방식으로 AI 에이전트 (AI agents)를 사용해 왔다는 것을 깨달았습니다.

그 패턴은 단순했습니다. 에이전트에게 유용한 무언가를 요청하면, 에이전트가 가서 그것을 알아내고, 결국 나는 답변을 얻게 됩니다. 문제는 에이전트에게 동일한 프로세스를 계속해서 재발견하도록 요청하면, 반복되는 추론 (reasoning), 반복되는 도구 사용 (tool usage), 그리고 반복되는 시행착오 (trial and error)에 대해 비용을 지불하게 된다는 점입니다. 이는 더 많은 토큰 (tokens), 더 높은 지연 시간 (latency), 그리고 에이전트가 실수할 기회가 더 많아짐을 의미합니다.

결국 나에게 깨달음을 준 것은 이것이었습니다: LLM 추론 (LLM inference)을 반복이 아닌 의사결정을 위해 사용하라.

만약 어떤 작업이 이미 한 번 해결되었다면, 나는 모델이 매번 그것을 다시 해결하기 위해 컨텍스트 (context)와 도구 호출 (tool calls)을 소모하는 것을 원하지 않습니다. 나는 모델이 작업을 인식하고, 신뢰할 수 있는 도구를 사용하며, 다음 단계로 넘어가기를 원합니다.

이것이 내가 Hermes를 사용하며 적용하고 있는 패턴이며, 이를 통해 나의 로컬 에이전트 (local agent) 설정이 훨씬 더 유용해졌습니다.

내가 실행 중인 설정

현재 나는 DGX Spark에서 Hermes를 실행하고 있습니다. 영상에서는 128 GB의 통합 메모리 (unified memory)를 가진 기기를 보여주는데, 당시에는 양자화된 (quantized) Qwen 3.5 모델을 로컬에 로드해 두었기 때문에 약 1 GB의 여유 공간이 있었습니다.

Hermes는 내가 현재 선택한 에이전트 프레임워크 (agent framework)입니다. 다른 옵션들도 시도해 보았지만, Hermes는 설치가 쉽고 사용하기 편리했습니다. 특히 마음에 드는 점 중 하나는 게이트웨이를 통해 Telegram을 지원한다는 것인데, 덕분에 터미널 창뿐만 아니라 휴대폰에서도 내 에이전트와 대화할 수 있습니다.

도구 측면에서 이 워크플로 (workflow)에 가장 중요한 것들은 다음과 같습니다:

• 웹 검색 및 스크래핑 (Web search and scraping)
• 터미널 액세스 (Terminal access)
• 파일 작업 (File operations)
• 코드 실행 (Code execution)
• 하위 에이전트 위임 (Sub-agent delegation)

웹 검색을 위해 나는 Tavily를 사용하고 있습니다. 영상에서 언급했듯이, 무료 티어는 한 달에 약 1,000번의 요청을 제공하는데, 이는 실험하기에는 충분하지만 에이전트가 호출을 낭비할 때 이를 인지할 수 있을 만큼 충분히 제한적입니다.

이것이 중요한 이유는, 이 포스트의 전체 내용이 불필요한 도구 사용 (tool usage)을 줄이는 것에 관한 것이기 때문입니다.

낭비되는 버전

저는 일반적인 프롬프트로 시작했습니다:

이번 주말 소피아의 날씨는 어떨 것 같아? 날씨에 맞춰서 활동 계획을 세우는 걸 도와줘.

이것은 제가 이동 중에 텔레그램 (Telegram)을 통해 에이전트에게 보낼 법한 전형적인 질문입니다.

Hermes가 결국 답변을 내놓기는 했지만, 실행 과정 (trace)을 지켜보는 것이 중요한 부분이었습니다. 에이전트는 웹 검색 (web search)을 수행하고, 웹 추출 (web extract)을 한 뒤, 시간과 날짜를 확인했습니다. 그러다 약간 헤매더니, 첫 번째 시도에서 원하는 것을 얻지 못하자 다시 검색을 수행했습니다. 영상에서 저는 실제 비용을 지적했습니다. 이 간단한 요청이 약 20k 토큰의 컨텍스트 (context)를 채웠다는 사실입니다.

그리고 그것이 바로 문제입니다.

답변은 괜찮았습니다. 하지만 과정은 그렇지 않았습니다.

만약 제가 날씨와 활동 제안을 정기적으로 요청한다면, 모델이 매번 즉흥적으로 미니 연구 프로젝트를 수행하는 것을 원치 않습니다.

더 나은 버전: 한 번 연구하고, 한 번 자동화하여, 영원히 재사용하기

에이전트에게 최종 질문을 다시 던지는 대신, 저는 하나의 기능 (capability)을 구축하는 방식으로 전환했습니다.

먼저, 저는 Hermes에게 API 키가 필요 없고 자동화하기 쉬운 무료 날씨 API를 조사해달라고 요청했습니다:

일기 예보를 제공하는 무료 및 오픈 API를 조사해줘. API 키가 필요하지 않고 Python 스크립트로 쉽게 자동화할 수 있는 API를 찾아줘. 아직 스크립트는 작성하지 마. 내가 먼저 API를 선택할 수 있게 해줘.

Hermes는 조사를 시작했고, Open-Meteo, WeatherAPI, met.no를 포함한 몇 가지 옵션을 가지고 돌아왔습니다. Hermes는 Open-Meteo를 추천했고, 그것으로 충분했습니다.

그래서 저는 다음 단계로 넘어가 구체적인 것을 만들어달라고 명령했습니다:

Open-Meteo를 사용하자. 오픈 코드 서브 에이전트 (open code sub-agent)를 생성하고 디렉토리를 만들어줘. 해당 디렉토리 내부에서 서브 에이전트는 CLI로 래핑된 (wrapped by) Open-Meteo API 클라이언트를 구현해야 해. Python을 사용해줘. 반드시 실제 데이터를 사용하고, 유닛 테스트 (unit tests)에만 모의 객체 (mocks)를 사용해줘. 준비되면 보고해줘.

“실제 데이터를 사용하고, 유닛 테스트 (unit tests)에만 모의 객체 (mocks)를 사용해줘”라는 문구는 제가 자주 사용하는 문구입니다. 에이전트가 현실에 기반하여 실행될 수 있다면, 자신의 작업물을 훨씬 더 잘 검증할 수 있기 때문입니다.

Hermes는 코딩에 집중하는 하위 에이전트 (sub-agent)에게 작업을 위임했고, 프로젝트를 생성하고 CLI를 구현했습니다.

그다음 가장 중요한 부분이 이어졌습니다.

에이전트를 절대 믿지 마라

에이전트가 프로젝트가 완료되었다고 말했을 때, 저는 그것을 그냥 받아들이지 않았습니다.

저는 실제 요청으로 테스트를 진행했습니다:

이제 실제 API로 테스트해 보자. 이 스크립트를 사용해서 베를린의 일기 예보를 알려줘.

이것은 제가 계속해서 되새기는 규칙입니다: 에이전트를 절대 믿지 마세요.

코드를 읽으세요. 스크립트를 실행하세요. 출력을 검증하세요. 실제 API를 사용하고 있는지 확인하세요. 예상치 못한 동작을 하고 있지는 않은지 확인하세요. 그 과정이 모두 끝난 후에야 비로소 그것은 “실험 (experiment)”에서 “역량 (capability)”으로 넘어갈 수 있습니다.

데모에서 스크립트는 약 0.4초 만에 베를린의 7일 예보를 반환했습니다. 바로 이 순간 전체적인 패턴이 명확해집니다. 토큰을 많이 소모하며 느리게 진행되던 부분은 해당 작업을 수행하는 방법을 찾아내는 과정이었습니다. 일단 그 문제가 해결되면, 가장 좋은 방법은 그것을 패키징 (packaging)하는 것입니다.

일회성 스크립트를 영구적인 기술로 전환하기

날씨 CLI가 작동하자, 저는 Hermes에게 이를 재사용 가능한 기술 (skill)로 래핑 (wrap)해달라고 요청했습니다:

이제 이 CLI 스크립트를 래핑하여, 향후 세션에서 내가 날씨에 대해 물어볼 때마다 사용할 수 있는 너만의 기술을 만들어줘.

Hermes는 자신의 기술 관리 흐름 (skill management flow)을 사용하여 해당 기술을 생성했고, 이는 Hermes의 영구적인 기술 세트 (skill set)의 일부가 되었습니다.

그 후 저는 완전히 새로운 세션을 시작했습니다.

이것이 진짜 테스트입니다. 왜냐하면 새로운 세션은 새로운 컨텍스트 (context)를 갖기 때문입니다. 이전 채팅으로부터 숨겨진 기억도 없고, 부정행위도 불가능합니다.

저는 똑같은 질문을 다시 던졌습니다:

이번 주말 소피아의 날씨는 어떨 것 같아? 날씨를 바탕으로 활동 계획을 세우는 걸 도와줘.

이번에 Hermes는 자신의 기술을 확인하고, 날씨 기술을 찾아내어, 스크립트를 실행한 뒤, 활동 제안이 포함된 깔끔한 답변을 제공했습니다.

그 차이는 엄청났습니다.

첫 번째 경우에는 두 번의 Tavily 검색을 포함하여 웹 검색을 마구 소모했고, 답변 방법을 알아내는 데 많은 토큰을 사용했습니다. 두 번째 경우에는 제가 이미 검증한 스크립트에 대한 본질적으로 단 한 번의 도구 호출 (tool call)로 전체 과정을 축소했습니다.

그 패턴을 한 줄로 요약하면 다음과 같습니다:

한 번 탐색하고. 한 번 자동화하고. 기술 (skill)로 감싸라. 영원히 재사용하라.

날씨보다 더 흥미로운 사례

날씨는 단순한 예시일 뿐이지만, 낭비되는 부분이 눈에 잘 띄기 때문에 유용합니다.

영상에 나온 더 흥미로운 사례는 제가 텔레그램 (Telegram)을 통해 휴대폰으로 직접 만든 것입니다. 저는 주식 관련 질문에 에이전트를 꽤 자주 사용하기 때문에, 공개 API에서 주식 또는 지수 데이터를 가져오는 주식 분석 스크립트 (stock analyzer script)를 만들도록 했습니다.

패턴은 동일합니다:

대중적이고 공개된 API에서 주식 또는 지수 데이터를 가져오는 주식 분석 Python 스크립트를 생성하세요. 실제 데이터를 사용하세요. 단위 테스트 (unit tests)에만 모의 데이터 (mocks)를 사용하세요.

완료된 후, 저는 1년 전 Microsoft의 데이터를 실제 실행하여 검증했습니다. 출력 결과에는 약 250거래일의 데이터, 최신 가격, 몇 가지 이동 평균 (moving averages), 기술적 지표 (technical indicators), 그리고 짧은 해석이 포함되어 있었습니다.

그다음 저는 그것을 기술 (skill)로 만들었습니다.

완전히 새로운 세션에서, 저는 USO ETF에 대해 모호한 질문을 던졌습니다. 스크립트에 대해 언급하지도 않았고, 워크플로 (workflow)를 다시 설명하지도 않았습니다. Hermes는 스스로 주식 분석 기술 (stock analyzer skill)을 선택하여 현재 데이터가 포함된 유용한 요약본을 반환했습니다.

이 지점부터 모델과 채팅하는 느낌보다는 시간이 흐름에 따라 개인 비서를 성장시키는 듯한 느낌이 들기 시작합니다.

제가 지키고 싶은 보안 규칙

여기서 핵심적인 안전 아이디어는 간단합니다: 자동화하기 전에 검증하라.

만약 에이전트가 스크립트를 작성한다면, 그것을 읽으십시오. 만약 무언가 작동한다고 주장한다면, 테스트하십시오. 만약 실제 시스템에 대한 접근이 필요하다면, 실제로 수행하기를 원하는 작업만을 노출하십시오.

민감한 사항에 대해서라면, 저는 에이전트(agent)를 가능한 한 가장 좁은 가이드레일(rails) 안에 두겠습니다. 실제로 이는 가능한 경우 읽기 전용(read-only) 권한을 선호하고, 광범위한 접근 권한 대신 특정 목적을 위해 구축된 작은 도구(tools)들을 사용하며, 해당 워크플로(workflow)가 올바르게 작동하는 것을 확인한 후에만 영구적인 기술(skill)로 승격시키는 것을 의미합니다.

에이전트가 더 유능해질수록, 이 점은 더욱 중요해집니다.

더 큰 그림 (The Bigger Picture)

이 패턴에서 제가 가장 좋아하는 점은 이것이 복리로 쌓인다는 것입니다.

반복되는 에이전트 작업이 포착될 때마다, 저에게는 두 가지 선택지가 있습니다.

• 에이전트가 해결책을 다시 찾아내도록 계속 비용을 지불할 것인가.
• 아니면 그 해결책을 재사용 가능한 능력(capability)으로 전환할 것인가.

시간이 흐름에 따라, 이는 전체 설정의 형태를 변화시킵니다.

저는 모델을 만능 즉흥 연주자처럼 취급하는 것을 멈추고, 신뢰할 수 있는 도구(tools)를 언제 호출해야 하는지 아는 코디네이터(coordinator)처럼 취급하기 시작합니다. 모델은 여전히 지능(intelligence)을 제공하지만, 반복적인 부분은 코드로 이동합니다.

이는 더 도메인 특화된(domain-specific) 어시스턴트(assistant)로 가는 문을 열어줍니다. 자연스러운 다음 단계는 매물을 확인하고, 모기지 뉴스를 가져오고, 변경 사항을 요약하며, 정해진 일정에 따라 텔레그램(Telegram) 업데이트를 보내는 개인 부동산 어시스턴트와 같은 것입니다. 원리는 동일하며, 단지 누군가의 일상에 실제로 중요한 워크플로에 적용될 뿐입니다.

이 부분이 제가 흥미를 느끼는 지점입니다. AI의 마법이 아니라, 제가 지속적으로 내구성이 있는 기술(durable skills)을 가르침으로써 점점 더 유용해지는 꾸준히 개선되는 어시스턴트 말입니다.

Hermes 세션, 날씨 기술 구축, 그리고 텔레그램 기반의 주식 예시를 포함한 전체 과정을 보고 싶다면, 여기 YouTube 영상을 시청하세요:

만약 로컬에서 에이전트를 실험하고 계신다면, 어떤 반복 작업을 가장 먼저 기술(skill)로 전환하고 싶은지 꼭 듣고 싶습니다.