먼저 고백부터 하자면, 나는 도시 이름을 입력하면 그 장소에 대한 정보와 함께 날씨까지 알려주는 AI 에이전트를 만들었다.

이미 날씨를 확인해 주는 것이 무엇인지 아는가? 날씨 API다. fetch 한 번이면 끝이다. 모델도 없고, 토큰도 없고, 'usage'라는 단어가 들어간 월별 청구서도 없다. 나는 이 사실을 에이전트를 만드는 내내 알고 있었다. 그래도 에이전트는 만들었다.

여기에 그 이야기가 있고, 왜 불필요한 일을 하는 것이 실제로는 핵심이었는지에 대한 작은 논거가 있다.

이 프로젝트의 기능

이것은 '여행 및 날씨 가이드(Travel & Weather Guide)'라고 불린다. 도시 이름(예: Lisbon, Kyoto 등)을 입력하면 다음 네 가지 정보를 돌려준다. 그 장소가 알려진 것에 대한 몇 문장 설명, 현재 실시간 날씨, 이 시기에 사람들이 일반적으로 하는 활동, 그리고 지금 방문하기 좋은 시기인지에 대한 명확한 판정이다.

이것은 두 가지 방식으로 실행된다. 검색창이 있는 웹 페이지:

여행 및 날씨 가이드 웹 UI:

그리고 발리에서 날씨를 물어볼 때 해커처럼 느끼고 싶을 때 사용할 수 있는 터미널 버전:

CLI 시작 화면: 'Travel & Weather Guide (종료하려면 exit 입력)' 메시지를 출력하고 도시 이름을 요청한다.

둘 다 내부적으로 동일한 에이전트를 사용한다. 날씨 자체는 키가 필요 없고 무료인 Open-Meteo에서 가져온다.

흥미로운 부분은 모델이 날씨를 가져오는 방식인데, 사실 모델은 직접 가져오지 못한다는 점입니다. 모델은 HTTP 요청을 보내거나 코드를 실행할 수 없으며, 오직 텍스트를 생성할 수 있을 뿐입니다. 따라서 스스로 무언가를 가져오는 대신, 내부적인 _도구 (tool)_에게 요청하고 답변을 기다립니다.

SDK의 모습은 다음과 같습니다:

export const getWeather = tool({
  name: 'get_weather',
  description: 'Fetch current weather for a given city using Open-Meteo.',
...

저 tool() 래퍼 (wrapper)는 저의 Zod 스키마 (schema)를 모델이 읽을 수 있는 설명으로 변환합니다. 이제 모델은 get_weather(city) 함수가 존재한다는 것을 알고 있지만, 이를 직접 실행할 수는 없습니다. 오직 요청할 수 있을 뿐입니다.

루프 (loop)는 다음과 같이 진행됩니다:

1. 사용자가 리스본(Lisbon)에 대해 묻습니다.
2. 모델은 "날씨 데이터가 필요해"라고 생각하며, 구조화된 도구 호출 (tool call)인 get_weather({ city: "Lisbon" })을 내보냅니다. 아직 코드는 실행되지 않았습니다. 이는 단지 모델이 손을 드는 것과 같습니다.
3. SDK의 러너 (runner)가 요청을 확인하고, 로컬에서 저의 실제 JavaScript 함수를 실행하며, 그 함수가 Open-Meteo로 일반적인 fetch 요청을 보냅니다.
4. 결과가 모델에게 다시 전달됩니다.
5. 모델은 해당 데이터를 사용하여 최종 답변을 작성합니다.

사람들은 가끔 이것이 MCP라고 가정하곤 합니다. 하지만 아닙니다. MCP는 프로토콜을 통해 연결되는 별도의 서버에 존재하는 도구들을 위한 것입니다. 이 도구는 단지 제 프로세스 내에 있는 함수일 뿐입니다. 모델이 요청하면, 제 코드가 실행되고, 결과가 돌아옵니다. 모두 인메모리 (in-memory) 상에서, 하나의 리포지토리 (repo) 안에서, 프로토콜 없이 이루어집니다.

불편한 부분

그 루프를 다시 살펴보십시오. 리스본의 기온이 24°C라고 알려주기 위해 시스템은 다음과 같은 과정을 거칩니다:

• 전체 대화 내용과 도구 정의 (tool definitions)를 모델로 보냅니다.
• 모델이 날씨를 원한다고 결정할 때까지 기다립니다.
• 제가 처음부터 직접 실행할 수도 있었던 fetch를 실행합니다.
• 모든 것을 모델에게 다시 보냅니다.
• 모델이 한 단락을 작성하는 동안 다시 기다립니다.

부트캠프 1주 차 학생도 작성할 수 있는 단 한 번의 HTTP 호출을 위해, 두 번의 모델 왕복 (round-trips)과 엄청난 양의 토큰 (tokens)이 소모됩니다. fetch는 언제나 쉬운 부분이었습니다. 저는 언제 호출할지를 결정하기 위해 매우 비싼 중간 관리자를 만든 셈입니다.

그리고 중요한 점은 이것이 단지 저의 이상한 작은 프로젝트가 아니라는 것입니다. 이것은 우리가 처한 시대 전체의 모습입니다.

이제 모든 것이 에이전트(Agent)가 되어가고 있습니다

조용한 변화가 일어나고 있습니다. 예전에는 함수 호출 (Function call), 크론 잡 (Cron job), 또는 if 문이었던 많은 것들이 에이전트 (Agent)로 재구축되고 있습니다. 기존 방식이 작동을 멈췄기 때문이 아닙니다. 기존 방식은 빠르고 기본적으로 비용이 들지 않습니다. 단지 지금 모든 것이 원하는 형태가 바로 "에이전트 (Agent)"일 뿐입니다.

그중 일부는 진정으로 유익합니다. 작업이 모호하거나, 개방적이고, 판단이 필요하거나, 사전에 예측할 수 없는 방식으로 도구들을 엮어야 할 때, 에이전트 (Agent)는 자신의 토큰 (Token) 값을 증명합니다. 그것이 진정한 유스케이스 (Use case)이며, 정당하게 새로운 영역입니다.

하지만 많은 경우, 우리는 완벽하게 결정론적인 (Deterministic) 문제들을 미래처럼 "느껴지기" 때문에 확률적이고 토큰 사용량이 측정되는 레이어 (Layer)로 감싸고 있습니다. 우리는 이미 해결된 문제들을 가져와 "스마트"하게 만들었지만, 이는 대부분 더 느리고, 더 비싸며, 때로는 날씨에 대해 자신 있게 틀리는 것을 의미합니다. 이득은 실재합니다. 하지만 그에 따른 세금 (Tax) 또한 실재합니다. 두 가지 모두 동시에 사실이지만, 아무도 두 번째 사실을 입 밖으로 내고 싶어 하지 않습니다.

저의 날씨 에이전트 (Weather agent)는 그 세금에 대한 작고 솔직한 기념비입니다. 그것은 인공지능 (Artificial intelligence)을 코스프레하고 있는 fetch일 뿐입니다.

그렇다면 왜 이것을 만들었을까요?

세상의 문제를 해결하기 위해서가 아닙니다. 분명히 말씀드리겠습니다. AI가 설명해 주는 날씨가 부족해서 고통받는 사람은 아무도 없었습니다. 제 에이전트 (Agent)가 리스본이 따뜻하다고 말해준다고 해서 기후 변화가 1도 낮아지지는 않았습니다.

제가 이것을 만든 이유는, 실제로 에이전트 (Agent)를 만들어보지도 않고 파티에서 에이전트에 대해 "떠드는" 사람이 되고 싶지 않았기 때문입니다. 여러분도 그런 사람이 누구인지 알 것입니다. 저는 그런 사람이 되기를 거부합니다.

에이전트 시대 (Agentic era)는 제가 토큰 (Token)에 대해 어떤 의견을 갖든 상관없이 일어나고 있습니다.

결과적으로 에이전트 시대 (Agentic era)의 값비싼 불합리함을 이해하는 가장 좋은 방법은, 스스로 작고 유쾌한 불합리함을 실행해 보는 것이었습니다.

그러니 아니요, 날씨를 확인하기 위해 에이전트 (Agent)를 만들지는 마세요. 그냥 API를 호출하면 됩니다.

하지만 저는 이제 API를 호출했습니다. 에이전트 (Agent)를 통해서 말이죠. 일부러 그랬습니다. 그리고 토큰 (Tokens) 비용이 약간 들었다는 것 외에는 아무것도 후회하지 않습니다. 건배!

직접 시도해 보세요

코드는 GitHub에 있습니다: Dakudbilla/openai-travel-weather-agent.

# clone and install
git clone https://github.com/Dakudbilla/openai-travel-weather-agent.git
cd openai-travel-weather-agent
...

날씨 데이터는 무료 (Open-Meteo, 키 불필요)이므로, 비용이 발생하는 유일한 부분은 토큰 (Tokens)뿐입니다. 무료 OpenAI 계정을 생성하여 이를 위한 API 키를 발급받을 수 있습니다.

즐거운 코딩 되세요 (Happy Coding)