어제 주니어 개발자가 올린 PR(Pull Request)을 보고 한참을 모니터 앞에 앉아있었습니다. 외부 기술 문서를 수집해서 요약해 주는 사내 봇을 만들겠다며 가져온 코드가, 2010년대에나 쓸법한 정적 HTML 파싱 로직으로 도배되어 있었기 때문입니다. requests 라이브러리로 텍스트만 긁어와서 LLM에 던져주는 방식은, 모던 웹 환경인 SPA(Single Page Application)나 로그인이 필요한 동적 페이지 앞에서는 그야말로 무용지물입니다. 저는 그 친구를 불러 조용히 말했습니다. "우리가 만드는 건 장난감이 아니에요. 고객은 결과만 봅니다. 페이지 로딩도 못 해서 null 반환하는 에이전트에 돈을 낼 사람은 없어요." 그리고 조용히 링크 하나를 슬랙으로 보내줬습니다. 바로 Comet MCP입니다.
지금 엔지니어링 씬에서 '에이전트(Agent)'라는 단어가 남발되고 있지만, 실상은 초라하기 그지없습니다. 대부분의 웹 검색 도구(WebFetch 등)는 웹페이지의 껍데기, 즉 정적 텍스트만 가져옵니다. 반면 조금 더 나아가 보겠다고 browser-use 같은 라이브러리를 써서 범용 LLM에게 "좌표 (x, y)를 클릭해"라고 시키는 방식은 비용 효율성 측면에서 최악입니다. 비싼 GPT-4나 Claude 3.5 Sonnet의 토큰을 고작 버튼 위치 찾는 데 태우는 건, 최고급 휘발유를 바닥에 뿌리는 것과 다를 바 없으니까요. 게다가 DOM 구조가 조금만 바뀌어도 스크립트는 터져버립니다. 이게 제가 항상 말하는 '비용과 안정성의 트레이드오프'를 무시한 결과입니다.
GitHub에 공개된 hanzili/comet-mcp는 이 지긋지긋한 딜레마에 대한 꽤 현실적인 해답을 제시합니다. 핵심은 Claude Code라는 강력한 코딩 에이전트와 Perplexity가 작정하고 만든 AI 전용 브라우저인 Comet을 'MCP(Model Context Protocol)'로 연결했다는 점입니다. 기존 방식이 눈 가리고 손으로 더듬거리는 식이었다면, 이건 시신경이 연결된 진짜 눈을 달아주는 격입니다. 아키텍처를 뜯어보면 Claude Code가 MCP 서버를 통해 명령을 내리고, 이 명령은 CDP(Chrome DevTools Protocol)를 타고 로컬에 설치된 Comet 브라우저를 직접 제어합니다. 여기서 중요한 건 '제어의 주체'입니다. 멍청하게 좌표를 찍는 게 아니라, "이 문서를 조사해줘"라는 목적(Goal)을 던지면 브라우저 자체가 에이전트처럼 행동하며 심층 연구를 수행합니다.
설치 과정도 엔지니어라면 납득할 만한 수준입니다. ~/.claude.json에 MCP 서버 설정만 추가하고 Comet 브라우저를 설치하면 끝납니다. 물론 여기서도 주의할 점은 있습니다. 포트 9222번을 사용하기 때문에 기존에 크롬 디버깅을 돌리고 있었다면 충돌이 날 겁니다. 이런 디테일을 챙기지 않으면 "왜 안 되죠?"라며 삽질만 하게 됩니다. 하지만 일단 연결되면 comet_ask, comet_poll, comet_screenshot 같은 도구들을 통해 Claude가 브라우저를 자신의 손발처럼 부리기 시작합니다. 단순히 텍스트를 읽는 게 아니라, 로그인을 하고, 팝업을 닫고, 동적으로 로딩되는 데이터를 기다렸다가 가져오는 '행동'이 가능해진다는 뜻입니다.
제가 이 도구를 주목하는 이유는 단순히 기능이 신기해서가 아닙니다. 바로 '역할의 분리'가 명확하기 때문입니다. Claude는 코딩과 논리적 추론에 집중하고, 웹 탐색과 렌더링, 동적 상호작용은 거기에 특화된 Comet 브라우저에 위임합니다. 이렇게 해야 인프라 비용이 통제 가능한 범위 내로 들어옵니다. 범용 모델 하나로 모든 걸 해결하려는 'AI 만능론'은 결국 느리고 비싼 쓰레기를 만들 뿐입니다. 2025년의 AI 프레임워크를 조사하라고 시켰을 때, 정적 텍스트만 긁어와서 환각(Hallucination)을 섞어 뱉는 모델과, 실제로 페이지를 돌아다니며 팩트 체크를 하고 결과를 가져오는 모델. 클라이언트가 무엇을 원할지는 자명하지 않습니까?
물론 이것도 만능열쇠는 아닙니다. 로컬 머신에 무거운 브라우저 프로세스를 띄워야 한다는 리소스 부담이 있고, Perplexity 생태계에 종속된다는 단점도 있습니다. 하지만 엑셀로 크롤링하겠다는 고객의 요구를 기술적으로 우아하게 방어하려면, 적어도 우리 엔지니어들은 이런 도구가 왜 나왔는지, 어떤 문제를 해결하고 있는지 뼈저리게 이해해야 합니다. 주니어 여러분, beautifulsoup으로 HTML 태그 뜯으면서 밤새지 마십시오. 도구는 진화했고, 여러분의 시간은 더 가치 있는 비즈니스 로직 구현에 쓰여야 합니다. 지금 당장 터미널을 열고 MCP 설정을 건드려 보시길 바랍니다. 뒤처지는 건 한순간입니다.
