웹 ChatGPT로 4개 AI 에이전트 운영하기: 로컬 LLM 없는 브라우저 하네스 설계
핵심 답변: 이 실험은 모델 API를 직접 호출하거나 로컬 LLM을 실행하지 않습니다. 브라우저의 웹 ChatGPT 대화 세션을 전문 에이전트의 작업 환경으로 사용하고, 로컬에서 만든 브라우저 하네스, 세션 수퍼바이저, 오케스트레이터가 상태 관측, 작업 연속성, 전략 선택과 결과 검증을 담당합니다. 완전한 무인 운영이나 무제한 모델 사용을 보장하는 방식은 아닙니다.
왜 웹 ChatGPT를 에이전트 실행 환경으로 선택했을까?
API 기반 에이전트는 프로그래밍하기 편하지만 모델 사용량에 따라 비용이 늘어날 수 있습니다. 로컬 LLM은 추론 장비와 모델 운영이 필요합니다. 반면 이미 이용 중인 웹 ChatGPT 구독 범위에서 작업한다면 별도 모델 API 사용량 과금 없이 실험할 수 있습니다.
여기서 구독 범위가 중요합니다. 웹 ChatGPT에도 모델별 사용량 제한, 서비스 정책, 대화 길이 제한이 있습니다. 따라서 “무제한 토큰”이나 API 사용을 우회하는 방식이라고 표현하지 않습니다. 이 글의 비용 비교는 개인의 설계 동기에 관한 설명이지, 측정된 비용 절감률이 아닙니다.
브라우저 하네스와 세션 수퍼바이저는 무엇이 다른가?
하네스는 브라우저 연결, 화면 상태 관측, 허용된 상호작용, 실행 결과 확인을 담당합니다. 수퍼바이저는 그 위에서 웹 ChatGPT 대화 세션의 반복 실행, 응답 대기, 체크포인트, 후속 세션 인계와 복구를 다룹니다. 로컬 오케스트레이터는 여러 전문 에이전트의 목표, 우선순위, 정책, 성과 기록을 관리합니다.
이 계층은 ChatGPT 서비스 내부를 수정하는 것이 아닙니다. 웹 UI를 관측하는 외부 로컬 도구를 이용하므로 화면 변경과 인증 상태에 영향을 받습니다. 모델 추론은 웹 ChatGPT가 담당하며 하네스 내부에서 로컬 LLM을 사용하지 않습니다.
네 개의 에이전트가 함께 움직이는 방법
서로 다른 목표를 가진 네 개의 웹 ChatGPT 대화가 각각 에이전트 A, B, C, D로 동작합니다. 공개 글에서는 실제 프로젝트명, 도메인, 에이전트 별칭과 사용자 계정 정보를 제외했습니다.
각 세션은 독립적인 컨텍스트를 참고합니다. 오케스트레이터는 공통 정책과 실행 이력을 확인하지만, 실제 외부 서비스 작업은 계정과 권한이 검증된 경로를 거쳐야 합니다. 다음 행동을 선택하는 코드와 실제 게시하거나 발신하는 실행기는 별개의 책임입니다.
한 번의 실행 사이클은 어떻게 검증할까?
- 관측: 브라우저와 대화 상태를 확인합니다.
- 판단: 목표와 이전 결과를 고려해 다음 작업을 고릅니다.
- 실행: 권한이 확인된 브라우저 또는 서비스 연결 경로를 사용합니다.
- 검증: 게시 URL, 발신 기록, 제공자 응답 등 원본 증빙을 확인합니다.
- 평가: 사람이 반응했는지, 사용자가 늘었는지 등 실제 결과를 구분합니다.
- 개선: 실패 원인과 피드백을 다음 전략에 반영합니다.
실제 구현은 계속 개선 중입니다. 모든 단계가 언제나 자동으로 성공하는 완성형 시스템이라는 뜻은 아닙니다.
왜 실행 횟수만으로 성공을 판단하지 않을까?
프롬프트가 전송되었다는 기록은 실제 게시를 증명하지 못합니다. 이메일 전달 성공도 열람, 회신, 협업 성사를 증명하지 못합니다. 브라우저에서 버튼을 클릭했다는 사실 역시 서버 측 작업 완료와 같지 않습니다.
따라서 세션 유지 지표와 실제 사업·커뮤니티 성과를 분리해서 추적해야 합니다. 실패하거나 결과가 불분명한 작업은 무조건 재시도하지 않고, 먼저 원본 상태와 중복 가능성을 확인합니다.
실제 외부 성과는 있었을까?
있었습니다. 이 운영 실험에 연결된 한 소규모 독립 정보 프로젝트에서는, 단순한 초안 작성이나 메시지 발송을 넘어 외부 매체 게재와 전문가 협력 관계라는 결과를 확인했습니다.
프로젝트의 전문 정보를 정리하고, 관련 분야의 매체와 전문가를 조사하고, 적합한 대상에게 자료와 협력 가능성을 전달하는 과정에서 다음과 같은 결과가 나왔습니다.
- 해외 전문 매체에 기고 콘텐츠가 실제로 게재됐습니다.
- 외부 전문 조직의 공개 리소스에 프로젝트 링크가 등록됐습니다.
- 해당 분야 전문가에게서 콘텐츠 활용 허가를 받았습니다.
- 외부 전문가가 먼저 후속 콘텐츠 제작 및 협력 가능성을 제안했습니다.
- 별도의 편집 협업도 초기 연락을 넘어 진행됐습니다. 최종 게재까지 완료됐다는 의미는 아닙니다.
특히 중요한 변화는 외부에 먼저 소개하는 단계에서, 외부 전문가가 새로운 협력 가능성을 먼저 제안하는 단계로 발전했다는 점입니다. 이는 반복 실행 횟수와 구분되는 실제 관계 성과입니다.
다만 이 결과를 AI가 모든 작업을 자율적으로 완료했다는 증거로 해석해서는 안 됩니다. 사람의 판단, 외부 기여자의 협조, 권리 확인과 편집 과정이 함께 작용했습니다. 외부 게재나 제안이 대규모 사용자 확보 또는 공식적인 기관 승인과 같은 뜻도 아닙니다.
프로젝트와 협력자를 식별할 수 있는 이름, 분야, URL, 날짜는 의도적으로 생략했습니다. 검증된 외부 결과는 있었지만, 그 결과를 오직 하네스의 효과로 돌리지는 않는 것이 이 사례를 설명하는 정확한 방식입니다.
운영 중 드러난 기술적 문제
UI 변동성: 웹 인터페이스는 안정적인 자동화 API가 아닙니다. 관측과 실행 결과를 분리해야 합니다.
대화 길이 제한: 새 채팅으로 옮겨도 이전 작업의 완료·미완료 상태와 중복 방지 정보가 이어졌는지 검증해야 합니다.
레거시 구조: 프로젝트가 늘면서 이전 관리 경로와 새로운 통합 경로가 공존할 수 있습니다. 하나의 레지스트리와 상태 정의로 정리하고 테스트해야 합니다.
작업량과 성과의 간극: 반복 실행이 정상이어도 조사와 초안만 쌓일 수 있습니다. 외부 행동과 실제 반응을 별도로 확인해야 합니다.
이 문제들을 줄이기 위해 상태 모델, 복구 절차, 검증 로직을 지속적으로 다듬고 있습니다. 제안된 아키텍처의 모든 요소가 이미 운영 코드에 반영됐다고 주장하지는 않습니다.
자주 받는 질문
로컬 LLM을 쓰나요?
아니요. 이 브라우저 하네스와 오케스트레이션 구성에서 모델 추론을 위한 로컬 LLM은 사용하지 않습니다. 로컬 프로그램은 세션과 실행을 관리합니다.
OpenAI 모델 API를 직접 호출하나요?
이 구성의 에이전트 추론 경로는 직접 모델 API 호출이 아니라 웹 ChatGPT 대화입니다. 외부 서비스 연동을 위한 API 사용 여부와는 별개의 이야기입니다.
웹 ChatGPT를 무제한으로 사용할 수 있나요?
아니요. 구독 범위, 모델별 사용량 제한, 대화 길이 제한, 서비스 정책을 고려해야 합니다. 사용 가능량이나 장기 비용을 보장하는 설계가 아닙니다.
세션을 계속 돌리면 실제 성과가 자동으로 생기나요?
그렇지 않습니다. 실행 증빙과 사람의 반응을 구분해야 하며, 반복 실행만으로 목표 달성을 주장할 수 없습니다.
마치며: 가난한 AI 개발자의 생존형 아키텍처
솔직히 시작은 거창하지 않았습니다. 여러 에이전트를 돌리고 싶은데 API 토큰 비용을 계속 감당하기는 부담스럽고, 로컬 LLM을 위한 장비 투자도 만만치 않았습니다.
그래서 생각했습니다. “이미 구독 중인 웹 ChatGPT를 작업 환경으로 활용하면 되지 않을까?”
그 결과 브라우저 하네스를 만들고, 세션 수퍼바이저를 붙이고, 결국 오케스트레이터까지 만들게 됐습니다.
토큰 비용을 아껴보려다가 세션 복구와 디버깅을 연구하게 된 셈입니다. 어쩌면 API 비용 대신 제 시간을 지불하고 있는지도 모르겠습니다.
그래도 그 과정에서 배운 것은 분명합니다. 여러 AI를 실행하는 것과 여러 AI가 실제 목표를 달성하도록 운영하는 것은 다른 문제입니다.
웹 ChatGPT 에이전트 운영, 브라우저 하네스 설계, 세션 인계나 실행 검증에 대해 궁금한 점이 있다면 댓글로 질문해 주세요. 다른 설계 접근이나 개선 아이디어도 환영합니다.
관련 글: 웹 ChatGPT와 로컬 도구를 연결한 개발 환경