솔직히 말해, 요즘 실리콘밸리에서 "AI 에이전트"라는 단어만 들어도 피로감이 몰려옵니다. 넷플릭스 플랫폼 엔지니어링 팀에서 시스템의 안정성을 지키는 제 입장에서 볼 때, 현재의 에이전트 개발 방식은 시한폭탄이나 다름없습니다. 특히 '알아서 다 해준다'는 식의 마법 같은 도구들은 운영 단계에서 반드시 대가를 치르게 됩니다. 그 대가는 보통 천문학적인 토큰 비용이거나, 환각(Hallucination)으로 인한 오작동, 그리고 새벽 3시에 울리는 PagerDuty 호출입니다.
오늘은 그중에서도 가장 골치 아픈 문제, 바로 '컨텍스트 윈도우(Context Window) 관리'와 '디버깅의 불투명성'을 해결할 수 있는 현실적인 도구를 소개하려 합니다. 화려한 GUI나 복잡한 프로토콜 대신, 우리에게 익숙한 터미널로 돌아가는 것. 그것이 바로 생존의 열쇠가 될 수 있습니다.
문제 상황: MCP의 함정과 컨텍스트의 늪
최근 AI 에이전트와 브라우저를 연결할 때 MCP(Model Context Protocol)가 표준처럼 여겨지고 있습니다. 하지만 SRE 관점에서 MCP는 위험 요소가 다분합니다. 가장 큰 문제는 서버가 컨텍스트를 통제한다는 점입니다.
Playwright 기반의 MCP 도구를 예로 들어봅시다. 에이전트가 웹 페이지를 읽을 때, MCP는 전체 접근성 트리(Accessibility Tree)와 온갖 콘솔 로그를 몽땅 긁어다 LLM의 컨텍스트에 밀어 넣습니다. 복잡한 웹 애플리케이션이라면 순식간에 수만 토큰이 증발합니다. 컨텍스트가 가득 차면 에이전트는 멍청해지고, 중요하지 않은 정보 때문에 환각을 일으킵니다. "로그인 버튼을 눌러줘"라고 했는데, 보이지도 않는 푸터(Footer)의 링크를 누르는 식이죠.
더 최악인 건 디버깅입니다. 에이전트가 실패했을 때, 도대체 그 시점에 어떤 데이터가 LLM에 들어갔는지 파악하기가 너무 어렵습니다. 블랙박스 안에서 터진 폭탄을 해체하는 기분이 듭니다.
해결책: Unix 철학으로 회귀, webctl
이런 상황에서 webctl이라는 도구는 매우 신선한 충격을 줍니다. 핵심은 간단합니다. 브라우저 자동화를 CLI(Command Line Interface) 기반으로 수행하는 것입니다. 이게 왜 생존 전략이 될까요? 바로 '제어권'을 우리가 다시 가져올 수 있기 때문입니다.
Unix의 파이프(|) 철학을 기억하십니까? webctl은 그 철학을 브라우저 자동화에 적용했습니다. AI에게 맹목적으로 전체 페이지를 던지는 대신, 우리는 CLI 도구를 이용해 정보를 필터링해서 줄 수 있습니다.
예를 들어, 현재 페이지의 상태를 스냅샷으로 찍을 때 다음과 같이 제어할 수 있습니다.webctl snapshot --interactive-only --limit 30
이 명령어는 페이지 전체가 아니라, 상호작용 가능한 요소(버튼, 입력창 등) 중 상위 30개만 추려서 가져옵니다. 불필요한 광고, 장식용 이미지, 내비게이션 바 등은 LLM의 컨텍스트에 들어가지도 못하게 원천 차단하는 것입니다.
더 나아가 grep이나 jq 같은 표준 리눅스 도구와 결합할 수 있습니다.webctl snapshot | grep -i "submit"
이렇게 하면 'submit' 관련 요소만 딱 잘라서 에이전트에게 전달할 수 있습니다. 토큰 절약은 물론이고, 에이전트가 엉뚱한 곳을 클릭할 확률을 기하급수적으로 낮춥니다.
검증된 결과: 투명한 디버깅과 안정적인 운영
이 방식이 주는 가장 큰 이점은 '재현 가능성(Reproducibility)'입니다. 에이전트가 특정 작업을 수행하다 실패했다면, 개발자는 로컬 터미널에서 똑같은 webctl 명령어를 입력해 볼 수 있습니다. 에이전트가 보는 것과 정확히 똑같은 텍스트 출력을 눈으로 확인하고, 어디서 문제가 생겼는지 즉시 파악할 수 있습니다. 서버 로그를 뒤질 필요도 없습니다.
또한, webctl은 CSS 선택자가 아닌 ARIA 역할(Role) 기반의 쿼리를 사용합니다.webctl click 'role=button name~="Submit"'
프론트엔드 개발자가 클래스 이름을 바꿔도, ARIA 역할이 유지되는 한 자동화 스크립트는 깨지지 않습니다. 이는 테스트 코드의 유지보수 비용을 획기적으로 줄여줍니다. 저는 과거 네이버 검색 인프라팀 시절부터 깨지기 쉬운 스크립트 때문에 고생한 적이 한두 번이 아닙니다. "변하지 않는 속성"을 기준으로 삼는 것은 자동화의 기본 중의 기본입니다.
마무리하며
기술이 발전한다고 해서 모든 것을 AI에게 위임하는 것이 능사는 아닙니다. 특히 인프라와 운영의 세계에서는 '무엇이 입력되고 무엇이 출력되는지'를 완벽하게 통제할 수 있어야 살아남습니다.
화려한 GUI 도구들이 난무하는 시대에 투박한 CLI 도구를 추천하는 것이 시대착오적으로 보일 수도 있습니다. 하지만 시스템 장애가 발생했을 때 우리를 구원하는 것은 언제나 검은 바탕의 터미널이었습니다. 에이전트 개발 과정에서 컨텍스트 관리 문제로 골머리를 앓고 있다면, 혹은 알 수 없는 이유로 치솟는 비용을 잡고 싶다면, 지금 당장 브라우저 제어권을 CLI로 가져오십시오.
여러분의 퇴근 시간과 수면 시간은 소중합니다. 기계가 알아서 하게 두지 말고, 기계가 무엇을 볼지 여러분이 직접 정해주십시오. 그것이 엔지니어가 시스템 위에 군림하는 방법입니다.
