브라우저 자동화 에이전트의 도구 라이브러리 확장 시 발생하는 컨텍스트 팽창 및 JSON 이스케이프 문제 해결 방법

핵심 요약

브라우저 자동화 에이전트 구축 시 발생하는 시스템 프롬프트의 토큰 제한 문제와 JSON 내 자바스크립트 코드 삽입에 따른 파싱 오류를 해결하기 위한 아키텍처 설계 고민이다.

배경

Llama-3 8k 모델을 사용하여 자바스크립트 기반 브라우저 자동화 에이전트를 개발하던 중, 도구 라이브러리 증가로 인한 프롬프트 크기 초과와 JSON 파싱 오류 문제에 직면했다. 이를 해결하기 위해 ID 기반 도구 선택 방식의 효용성과 대안 아키텍처에 대해 커뮤니티의 조언을 구했다.

의미 / 영향

브라우저 자동화 에이전트 설계 시 프롬프트 내 코드 직접 삽입은 확장성과 안정성 측면에서 한계가 명확하다. 도구 정의와 실행 로직을 분리하는 ID 기반 매핑 아키텍처가 대규모 도구 라이브러리 운영의 필수적인 해결책임이 확인됐다.

합의점 vs 논쟁점

논쟁점

도구의 실제 코드를 LLM에게 숨겼을 때 복잡한 상황에서의 추론 및 도구 선택 정확도가 유지될 수 있는지 여부

실용적 조언

도구의 전체 코드 대신 이름과 기능 설명만 프롬프트에 포함하고, 실행 시 ID를 매핑하여 서버 측에서 코드를 호출하라.
JSON 내 코드 삽입 대신 사전에 정의된 함수 호출(Function Calling) 인터페이스를 활용하여 파싱 오류를 방지하라.

언급된 도구

Llama-3중립

에이전트의 추론 및 도구 선택 엔진

섹션별 상세

시스템 프롬프트 내에 모든 자바스크립트 선택자와 스니펫을 포함하는 방식이 도구 라이브러리 확장 시 심각한 컨텍스트 팽창을 유발한다. 현재 Llama-3의 8k 토큰 제한에 도달하여 400 Bad Request 오류가 발생하고 있으며, 이는 에이전트의 확장성을 저해하는 주요 원인으로 지목됐다. 라이브러리가 커질수록 프롬프트 관리가 불가능해지는 구조적 한계가 드러났다.

LLM이 생성하는 JSON 응답 내에 원시 자바스크립트 코드를 직접 포함할 때 발생하는 구문 분석 오류가 심각하다. 중첩된 따옴표, 정규 표현식, 여러 줄 코드의 이스케이프 처리가 제대로 이루어지지 않아 시스템이 빈번하게 중단되는 현상이 보고됐다. 이는 데이터 추출의 신뢰성을 떨어뜨리고 사후 처리 로직을 복잡하게 만드는 요인으로 작용한다.

도구의 실제 코드를 숨기고 ID 기반으로 도구를 선택하게 하는 방식이 LLM의 추론 능력에 미치는 영향에 대한 의문이 제기됐다. 코드를 직접 보지 못할 경우 LLM이 해당 도구의 역할을 정확히 이해하고 적절한 상황에 호출할 수 있는지에 대한 검토가 필요하다. 도구의 기능 설명(Description)만으로 충분한 컨텍스트가 제공되는지가 핵심 쟁점이다.

동적 브라우저 데이터 추출을 위한 더 나은 아키텍처 설계에 대한 논의가 이루어졌다. 프롬프트 팽창을 방지하면서도 에이전트가 수많은 도구 중 필요한 것만 효율적으로 선택하여 실행할 수 있는 구조적 대안을 모색하고 있다. RAG(Retrieval-Augmented Generation)를 도구 선택 프로세스에 도입하는 방안 등이 잠재적 해결책으로 거론됐다.

실무 Takeaway

시스템 프롬프트에 모든 도구 코드를 포함하는 방식은 토큰 제한으로 인해 대규모 라이브러리 확장에 부적합하다.
JSON 내에 복잡한 코드를 직접 출력하게 하는 설계는 이스케이프 문제로 인해 파싱 실패율을 높이는 주범이다.
도구의 상세 코드 대신 기능 설명과 ID만 제공하는 방식이 프롬프트 효율성과 시스템 안정성 측면에서 유리하다.