AI 에이전트는 모델과 도구가 어디서 도는지가 중요하다

새 에이전트를 살펴볼 때는 구조를 중심으로 나눠 본다. 에이전트는 모델, 에이전트 루프, 도구 세 가지로 구성된다.

• 모델은 에이전트가 수행할 수 있는 작업을 좌우한다.
• 에이전트 루프는 사용자 경험(UX)을 결정한다. 자세한 내용은 The Unreasonable Effectiveness of an LLM Agent Loop with Tool을 참고할 수 있다.
• 도구 집합은 에이전트의 기능과 권한, 그리고 문제가 발생했을 때 피해가 미칠 범위를 정한다.

루프와 도구를 합쳐 흔히 ‘하네스’라고 부른다. 이 구성 요소는 모두 코드이며, 코드는 어딘가에서 실행돼야 한다. 에이전트 구성 요소가 어디서 실행되는지, 즉 에이전트의 토폴로지는 AI 제품을 만드는 기업과 AI 도구를 사용하는 사람의 비용·기능·효과·보안에 영향을 준다. 원격 MCP 서버를 사용하면 다른 곳에서 실행되는 도구를 노출할 수 있다.

모델은 어디서 실행되는가

모델을 실행하는 방법은 다른 업체가 호스팅하는 GPU를 쓰거나 자체 GPU를 사용하는 것이다. 나비에-스토크스 방정식을 둘러싼 논란이 보여주듯, 데이터가 학습에 쓰이지 않는다고 확신할 수 있는 유일한 방법은 데이터를 업체에 보내지 않는 것이다. 흔한 문제를 다룬다면 크게 상관없을 수 있지만, 극히 드문 표현이 학습 데이터에 들어갈 가능성도 있다고 본다.

예를 들어 컴퓨터에 저장된 청구서 스캔본을 OCR로 읽고 분류하는 데 LLM을 쓴다면 로컬 모델을 선택할 수 있다. 속도가 중요하지 않아 밤새 실행해도 되고, 개인정보를 보호할 수 있기 때문이다. Apple Vision Framework도 참고할 만하다. ScanShelf는 이런 방식의 사례다.

켄 톰슨(Ken Thompson)의 1984년 튜링상 강연인 Reflections on Trusting Trust은 지금 다시 보면 의미가 다르다. 이 글은 컴파일러의 소스 코드에서는 보이지 않지만 컴파일러를 통해 퍼지는 트로이 목마를 어떻게 숨길 수 있는지 다룬다. LLM에도 변조된 가중치가 들어가 에이전트가 부적절한 행동을 하게 만들 수 있다. LLM이 컴파일러인지에 대한 논의는 여기에서 볼 수 있으며, 실제로 시도된 사례도 있다. 따라서 어떤 업체를 신뢰할지 선택해야 한다.

LLM은 기존 SaaS의 비용 구조에도 부담을 준다. 예를 들어 다이어그램 편집 SaaS에서 사용자가 에이전트로 다이어그램을 수정하도록 한다면 토큰 비용을 누가 낼지가 문제가 된다. 에이전트가 없던 때는 고객 한 명당 데이터베이스 행 몇 개가 비용의 대부분이었지만, 이제 고객은 몇 문장만으로 100달러의 비용을 발생시킬 수 있다. exe.dev에서는 사용자가 자신의 ChatGPT 구독을 가져와 OpenAI 모델로 애플리케이션을 만들 수 있다. 이는 양쪽 모두에 이득이 되는 방식이며, 앞으로 ‘자신의 모델 가져오기’ 옵션이 더 늘어날 것으로 본다.

에이전트가 내장된 맞춤형 드로잉 편집기도 만들었다. 앞으로는 여러 제품에서 ‘에이전트 창’을 보게 될 것이다.

루프는 어디서 실행되는가

ChatGPT를 쓰면 루프는 오픈AI 서버에서 실행된다. 코딩 에이전트를 실행하면 루프는 노트북에서 돌아간다. 웹 브라우저에서 루프를 실행할 수도 있다. ItsyBitsy가 그 사례이며, 같은 방식을 쓴 다른 제품도 많다.

다른 사람이 만든 루프는 제약이 있다고 느끼는 경우가 많다. 예를 들어 관측 도구 업체가 제공하는 에이전트 루프보다, 선호하는 에이전트가 내 소스 코드와 관측 도구를 직접 참조하도록 하는 방식을 더 좋아한다.

루프는 LLM 에이전트가 전체 대화 기록을 바탕으로 작동하므로 메시지 기록을 유지해야 하며, 그 기록을 저장할 장소도 필요하다. Shelley의 기록을 SQLite에 저장하기로 한 결정은 만족스럽다. Pi Durable도 SQLite를 사용한다.

루프는 에이전트의 사용자 인터페이스도 제공한다. 이미지를 표시할 수 있는지, 동영상에 피드백을 주는 기능이 있는지, 일반 텍스트만 지원하는지, 첨부 파일을 처리할 수 있는지, 대화를 공유할 수 있는지 모두 루프가 결정해야 할 사항이다.

도구는 어디서 실행되는가

도구가 없으면 에이전트라고 할 수 없다. LLM이 한 번 답변하는 방식에서 에이전트 루프로 넘어가면 큰 변화가 생긴다. 에이전트가 작성한 내용을 실제로 시험할 수 있으면 결과가 더 좋아진다.

하지만 코드를 실행하려면 실행 장소가 필요하다. 실행할 코드가 위험할 수 있다고 가정해야 한다. 코드가 쿠키를 훔치거나 밤중에 불필요하게 화재경보기를 울릴 수도 있고, 더 심각한 문제를 일으킬 수도 있다.

코드 실행은 가벼운 작업만이 아니다. 파일 편집뿐 아니라 컴파일, 동영상 처리, 테스트 실행 등 부하가 큰 작업도 포함된다.

가상 머신(VM)은 코드를 안전하게 실행하는 표준적인 방법이다. 하지만 VM을 사용해도 네트워크에 접속할 수 있는지, 다른 서비스에 접근할 자격 증명이 있는지, 메모리가 충분한지 등 고려할 변수가 많다.

코딩 에이전트를 로컬에서 실행하는 방법도 있지만, ‘치명적인 삼중 조건’(Lethal Trifecta)에 따른 피해 범위가 더 커진다. 예를 들어 신뢰할 수 없는 콘텐츠에 노출되면 에이전트가 비밀 정보를 유출할 수 있다.

완전한 컴퓨터 없이도 유용한 에이전트를 만들 수 있다. WASM에서 실행되는 Python인 Pyodide는 별도의 컴퓨터 없이 샌드박스화할 수 있다. 여러 WASM JavaScript 구현체도 있다. 에이전트 루프를 브라우저에서 실행하는 방법도 있는데, 브라우저는 평소에도 샌드박스화된 코드를 실행한다. 이런 접근법의 간단한 목록은 여기에서 볼 수 있다. 읽기 전용 데이터베이스 연결을 통해 에이전트가 SQL을 실행하도록 하는 방법도 있으며, 이는 상당히 안전하다.

도구가 루프와 같은 주소 공간에 있을 필요는 없으며, 가까운 곳에 있을 필요도 없다. ChatGPT에서 ‘커넥터’를 사용하면(OpenAI가 MCP를 부르는 방식과 대략 같다), 오픈AI가 호스팅하는 에이전트 루프가 다른 곳의 자원에 접근할 수 있다. 예를 들어 exe.dev MCP를 사용하면 ChatGPT가 exe VM을 다룰 수 있다. MCP를 사용할 때는 OAuth 토큰이 어디에 보관되는지 확인해야 한다.

제품을 쓸모 있게 만들기 위해 Muse, GrokBot, OpenAI Dots 등은 모두 VM을 제공한다.

에이전트 구조를 살펴보기

어떤 구성을 택하든 상충 관계가 있다. 에이전트 제품의 토폴로지를 살펴보면 각 제품의 구조를 나눠 볼 수 있다. 구성 요소가 어디서 실행되는지 알면 제품이 할 수 있는 일과 할 수 없는 일을 판단할 수 있다.

exe.dev에서 일하면서 거의 매일 서로 독립된 에이전트 루프 구현 다섯 가지를 사용한다. 코딩 에이전트 Shelley, 경보 에이전트 Sisyphus, 배포 감독 에이전트 Athena, 운영 에이전트 Puck, 저장소 소식을 전하는 Slack 에이전트다. Shelley는 범용 코딩 에이전트지만 나머지 네 가지는 특정 목적에 맞춰 만든 소프트웨어다. 점점 더 많은 소프트웨어에 에이전트 루프가 내장될 것이다.

다른 시스템과도 계속 상호작용하며, 에이전트를 이용해 시스템을 연결한다. 코딩 에이전트가 이해하기 쉬운 제품을 만드는 기업은 그 가치를 알아본다. 에이전트를 연결할 수 있는 제품으로 옮겨 가면서, 더 오래되고 세련된 기존 제품에서 벗어나게 되는 상황은 클레이턴 크리스텐슨의 혁신가의 딜레마를 떠올리게 한다. Revisiting Joel’s Test의 아홉 항목 중에서도 이것이 가장 중요하다.

모든 일을 해결하는 ‘하나의 루프’는 없다. 범용 챗봇에 적합한 사용자 경험과 도구 집합은 코딩 에이전트에 적합한 것과 다르다. 제품에 에이전트를 넣을 때는 에이전트의 토폴로지를 고려해야 한다.

def loop(llm):
 msgs, msg = [], user_input()
 while True:
 msgs += [msg]
 output, tool_calls = llm(msgs)
 print("Agent: ", output)
 if tool_calls:
 msg = [ handle_tool_call(tc) for tc in tool_calls ]
 else:
 msg = user_input()