browser-use/browser-harness — LLM이 부족한 능력을 스스로 코드로 채우는 브라우저 하니스

592줄로 브라우저를 통째로 제어한다

Playwright 깔고, Selenium 깔고, 드라이버 버전 맞추고, headless 모드 설정하고. 브라우저 자동화를 한 번이라도 해봤으면 이 과정이 얼마나 귀찮은지 알 거야. browser-harness는 이 모든 중간 레이어를 걷어냈어. Python 592줄, 외부 프레임워크 의존성 제로, WebSocket 하나로 Chrome에 직접 붙어서 브라우저 전체를 제어해. Show HN에 올라온 지 얼마 안 돼서 8,800 스타, 일간 380 스타 페이스로 찍고 있어.

더 충격적인 건 self-healing이야. 에이전트가 실행 중에 함수가 없으면 그 자리에서 helpers.py를 열어 코드를 직접 작성해. LLM이 자기가 부족한 능력을 런타임에 코드로 메우는 거야. 이게 단순 자동화 도구가 아니라 "에이전트 인프라"로 불리는 이유야.

프로젝트 배경 -- browser-use 생태계와 왜 CDP 직접 접근인가

browser-harness를 이해하려면 먼저 browser-use를 알아야 해. browser-use는 2025년 등장한 AI 브라우저 에이전트 프레임워크로, $17M 시드 펀딩을 받은 프로젝트야. LLM에게 브라우저를 쥐여 주고 "이 웹사이트에서 이걸 해"라고 시키면 알아서 클릭하고, 입력하고, 스크롤하는 구조지. 현재 GitHub에서 가장 활발한 브라우저 에이전트 레포 중 하나야.

근데 browser-use의 내부를 들여다보면 Playwright 위에 올라가 있어. Playwright는 Microsoft가 만든 브라우저 자동화 프레임워크인데, 원래 E2E 테스트용이야. 테스트에는 훌륭하지만 에이전트용으로 쓰면 문제가 있어. 추상화 레이어가 두껍다 보니 에이전트가 "이 웹페이지에서 이 DOM 요소를 이렇게 조작하고 싶어"라고 할 때 중간에 낀 레이어가 지연을 만들고, 특정 CDP 명령을 직접 못 쓰는 경우도 생겨.

browser-harness는 이 문제를 정면으로 풀었어. Playwright도, Selenium도, puppeteer도 안 써. Chrome이 기본으로 제공하는 CDP(Chrome DevTools Protocol)에 WebSocket으로 직접 연결해. 개발자도구에서 네트워크 탭 열 때 쓰는 그 프로토콜이야. 이걸 Python 코드에서 바로 쓰면 브라우저가 할 수 있는 거의 모든 것을 제어할 수 있어. 스크린샷 찍기, DOM 탐색, 네트워크 가로채기, JavaScript 실행, 쿠키 조작 전부 다.

이건 browser-use 팀이 자기네 상위 프로젝트의 한계를 인정하고 "더 낮은 레이어가 필요하다"고 판단한 결과야. browser-use가 고수준 에이전트 프레임워크라면, browser-harness는 그 아래의 저수준 제어 레이어. 두 프로젝트가 같은 GitHub org 아래에 있는 건 우연이 아니야.

왜 하필 지금이냐면, 에이전트 브라우저 자동화의 안정성 문제가 점점 더 심각해지고 있기 때문이야. Playwright 기반 에이전트가 웹사이트 구조가 바뀌면 깨지고, selector가 변하면 멈추고, 동적 로딩에 타이밍을 못 맞추는 일이 너무 잦아. CDP 직접 접근은 이런 문제에서 한 발 더 낮은 곳에서 대응할 수 있게 해줘.

핵심 기능 -- self-healing이 작동하는 방식

browser-harness의 가장 특이한 기능은 self-healing이야. 보통 소프트웨어에서 self-healing이라 하면 에러 복구 정도를 떠올릴 텐데, 여기서는 말 그대로 에이전트가 코드를 직접 작성해.

작동 방식을 단계별로 보면 이래. 에이전트가 브라우저에서 특정 작업을 수행하려 해. 예를 들어 LinkedIn에서 연결 요청을 보내려 한다고 치자. 이때 필요한 함수가 helpers.py에 없으면 에이전트가 멈추는 대신 LLM을 호출해서 "이 작업을 수행하려면 어떤 함수가 필요한가"를 물어봐. LLM이 함수 코드를 생성하면 에이전트가 helpers.py 파일에 그 함수를 직접 추가하고, 바로 실행해.

# helpers.py에 런타임에 추가되는 함수 예시
async def click_linkedin_connect_button(page):
    """LinkedIn 프로필 페이지에서 연결 버튼을 찾아 클릭"""
    connect_btn = await page.evaluate('''
        () => {
            const buttons = document.querySelectorAll('button');
            for (const btn of buttons) {
                if (btn.textContent.includes('Connect') ||
                    btn.textContent.includes('연결')) {
                    return btn.getBoundingClientRect();
                }
            }
            return null;
        }
    ''')
    if connect_btn:
        await page.click(connect_btn['x'], connect_btn['y'])

이건 기존 RPA(Robotic Process Automation)와 근본적으로 다른 접근이야. 기존 RPA는 사람이 시나리오를 짜고, 웹사이트가 바뀌면 사람이 다시 고쳐야 했어. browser-harness는 에이전트가 스스로 시나리오를 확장해. 처음에는 기본 기능만 있지만, 쓰면 쓸수록 helpers.py가 풍성해지면서 에이전트의 능력이 늘어나는 구조야.

여기에 domain-skills/ 폴더가 있어. 커뮤니티가 사이트별 레시피를 기여하는 공간이야. LinkedIn 자동화, Amazon 쇼핑, 경비 처리 같은 특화된 스킬 셋이 이미 들어가 있고, 누구나 PR로 새 도메인 스킬을 추가할 수 있어. 이건 에이전트 생태계의 "플러그인 마켓플레이스"와 비슷한 방향이야.

self-healing의 한계도 있어. LLM이 생성한 코드가 항상 올바르진 않아. 잘못된 함수가 helpers.py에 들어가면 이후 실행에서도 문제가 생길 수 있어. 현재는 이걸 검증하는 레이어가 얇은 편이야. 하지만 "완벽하지 않더라도 멈추지 않고 시도한다"는 철학이 에이전트 자동화에서는 의외로 실용적이야.

기술 스택 + 아키텍처 -- WebSocket 하나로 Chrome 전체를

browser-harness의 아키텍처는 놀라울 정도로 단순해. 전체 코어가 592줄이라는 사실이 이를 증명해. 외부 의존성 없이 Python 표준 라이브러리와 websockets 모듈만 사용해. 이건 "설치가 쉽다" 수준이 아니라 "의존성 지옥이 원천적으로 없다"는 수준이야.

핵심은 Chrome의 --remote-debugging-port 플래그야. Chrome을 이 플래그로 실행하면 CDP 엔드포인트가 열리고, 여기에 WebSocket으로 연결할 수 있어. browser-harness는 이 WebSocket 연결 하나로 페이지 탐색, DOM 조작, 네트워크 모니터링, 스크린샷, JavaScript 실행을 전부 수행해. 중간에 드라이버도 없고, 바이너리도 없어. Chrome만 있으면 돼.

아키텍처를 요약하면 이래:

1. Chrome 프로세스를 remote-debugging 모드로 시작
2. CDP WebSocket 엔드포인트에 연결
3. JSON-RPC 메시지로 브라우저에 명령 전달
4. 응답과 이벤트를 비동기로 수신
5. helpers.py의 함수들을 조합해 고수준 작업 수행
6. 함수가 없으면 self-healing으로 생성

이 구조의 장점은 디버깅이 투명하다는 거야. Playwright나 Selenium을 쓰면 중간 레이어에서 뭐가 잘못됐는지 찾기 어려울 때가 있어. browser-harness는 CDP 메시지가 그대로 오가니까, Chrome DevTools에서 직접 확인하는 것과 같은 수준의 가시성을 확보할 수 있어.

JS 포트인 browser-harness-js도 같은 아키텍처를 따라. Node.js 생태계에서 쓰고 싶은 사람들을 위한 거야. Python 버전이 메인이고, JS 버전은 커뮤니티 기여 기반으로 따라가는 구조야.

경쟁 레포 비교

browser-harness가 놓인 경쟁 지형을 정리하면 이래. 각 프로젝트의 접근 방식이 상당히 달라서 직접 비교하는 게 유의미해.

browser-harness 는 592줄 Python, CDP 직접 연결, self-healing 지원, 프레임워크 의존성 없음. MIT 라이선스. 에이전트가 코드를 직접 작성하는 것이 차별점. 8,800 스타.

browser-use/browser-use 는 같은 org의 상위 프로젝트. Playwright 기반 고수준 에이전트 프레임워크. $17M 시드 펀딩. LLM에게 자연어로 브라우저 작업을 시키는 데 최적화. 추상화가 두꺼운 대신 사용이 쉬움. 스타 수는 browser-harness보다 훨씬 많아.

Skyvern-AI/skyvern 은 비전 기반 브라우저 자동화. DOM 파싱 대신 스크린샷을 찍어서 비전 모델이 "어디를 클릭할지" 결정. selector 변경에 강한 대신 속도가 느리고, 비전 모델 비용이 추가로 들어. 복잡한 폼 처리에 강점.

microsoft/playwright 는 E2E 테스트 프레임워크. 에이전트용이 아니라 테스트용. selector 기반으로 안정적이지만 동적 웹사이트에서 에이전트가 쓰기엔 유연성이 부족. 가장 성숙하고 문서가 풍부. 에이전트 프로젝트들이 이 위에 올라가는 경우가 많아.

정리하면, Playwright가 가장 안정적인 기반이고, browser-use가 그 위의 에이전트 레이어이고, browser-harness는 Playwright 자체를 걷어내고 CDP로 바로 간 급진적 접근이야. Skyvern은 아예 DOM 대신 비전으로 우회한 별개 노선이고.

왜 지금 뜨는가 -- 에이전트 브라우저 자동화 생태계 맥락

2026년 상반기는 "에이전트가 브라우저를 쓴다"는 개념이 실험에서 프로덕션으로 넘어가는 전환기야. OpenAI의 GPT-5.5가 OSWorld에서 56%를 달성하면서 "컴퓨터를 쓸 줄 아는 AI"가 현실이 됐고, Anthropic의 Claude가 computer use 기능을 내장하면서 "브라우저를 직접 조작하는 LLM"이 상품화됐어.

이 흐름에서 가장 크게 부족한 게 인프라야. LLM이 아무리 똑똑해져도 브라우저를 안정적으로, 빠르게, 유연하게 제어할 수 있는 하네스가 없으면 실제 작업 수행률이 낮아. 웹사이트는 매일 바뀌고, 동적 렌더링은 타이밍이 까다롭고, 로그인 세션은 풀리고, CAPTCHA는 등장해. 이런 실전 문제를 해결하는 건 LLM의 능력이 아니라 하네스의 품질이야.

browser-harness가 Show HN에서 폭발한 건 이 타이밍과 맞아떨어졌기 때문이야. 기존에 Playwright 위에 에이전트를 올려서 쓰던 사람들이 "왜 중간 레이어가 필요하지? CDP로 바로 가면 안 되나?"라는 질문을 이미 하고 있었어. browser-harness가 그 질문에 592줄짜리 답을 내놨고, Hacker News 커뮤니티가 반응한 거야.

에이전트 브라우저 자동화 시장 자체도 커지고 있어. RPA 시장이 2025년 기준 약 $15B 규모인데, 여기에 LLM 기반 에이전트가 들어오면서 기존 UiPath, Automation Anywhere 같은 레거시 RPA를 대체하는 움직임이 가속화되고 있어. browser-harness 같은 오픈소스 도구는 이 시장의 인프라 계층을 담당해.

browser-use가 $17M 시드를 받은 것도 이 맥락에서 이해돼. 브라우저 에이전트 시장이 충분히 크다고 투자자들이 판단한 거야. browser-harness는 그 투자의 기술적 하위 구조를 오픈소스로 제공하는 셈이고, 이건 "오픈코어" 전략의 전형적인 패턴이야.

Show HN 일간 380 스타는 이 카테고리에서 상당히 높은 숫자야. 같은 기간 에이전트 관련 레포들과 비교하면 관심도가 매우 높은 편. browser-use 생태계의 브랜드 파워가 초기 트래픽을 끌었고, self-healing이라는 킬러 피처가 스타를 유지시키고 있어.

시작하기

설치와 실행은 간단해. 외부 의존성이 거의 없어서 환경 문제가 적어.

# 레포 클론
git clone https://github.com/browser-use/browser-harness.git
cd browser-harness

# 의존성 설치 (websockets만 필요)
pip install -r requirements.txt

# Chrome을 remote-debugging 모드로 실행
# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-harness

# 기본 사용
python harness.py --url "https://example.com"

흔한 함정 몇 가지를 정리하면 이래.

첫 번째, Chrome이 이미 실행 중이면 remote-debugging-port가 충돌해. 기존 Chrome 인스턴스를 다 닫고 새로 시작하거나, 별도의 user-data-dir을 지정해야 해.

두 번째, WSL(Windows Subsystem for Linux)에서 쓸 때 Chrome GUI가 안 뜰 수 있어. headless 모드를 추가하거나 Windows 쪽 Chrome에 연결하는 방식을 써야 해.

세 번째, self-healing이 helpers.py를 수정하기 때문에, 프로덕션에서 쓸 때는 helpers.py의 변경 이력을 git으로 추적하는 걸 권장해. 에이전트가 만든 함수 중 문제 있는 걸 빠르게 롤백할 수 있어야 하니까.

네 번째, domain-skills/ 폴더의 레시피는 특정 시점의 웹사이트 구조에 맞춰져 있어. LinkedIn이 UI를 바꾸면 기존 레시피가 깨질 수 있어. 이때 self-healing이 작동하긴 하지만, 복잡한 플로우는 직접 업데이트하는 게 안전해.

한계와 전망

가장 큰 한계는 보안이야. 에이전트가 런타임에 코드를 작성하고 실행한다는 건, 잘못된 입력이나 프롬프트 인젝션 공격에 취약하다는 뜻이야. helpers.py에 악의적인 코드가 주입되면 시스템 전체가 위험해질 수 있어. 프로덕션 환경에서는 샌드박스 안에서 실행하고, helpers.py 변경을 사람이 승인하는 워크플로를 추가해야 해.

592줄의 장점은 동시에 단점이기도 해. 코어가 작다는 건 기능이 제한적이라는 뜻이야. 멀티탭 관리, 파일 다운로드 처리, 인증 플로우 자동화 같은 기능은 아직 helpers.py에 커뮤니티가 채워야 하는 영역이야. Playwright가 수년에 걸쳐 쌓아온 edge case 처리량을 592줄이 따라잡으려면 시간이 필요해.

전망은 밝은 편이야. 에이전트 브라우저 자동화 시장이 커지고 있고, CDP 직접 접근이라는 아키텍처적 선택은 방향이 맞아. browser-use 생태계의 후광 효과도 있고. 단기적으로는 domain-skills 폴더의 레시피가 얼마나 빠르게 축적되느냐가 성장의 열쇠야. 장기적으로는 self-healing의 신뢰도를 높이는 검증 레이어가 추가되면, "에이전트를 위한 브라우저 런타임"이라는 위치를 확실하게 잡을 수 있어.

참고 자료

• browser-use/browser-harness GitHub
• Show HN: Self-healing browser harness via direct CDP
• Browser Harness 공식 사이트
• browser-harness-js (JS 포트)
• browser-use/browser-use (상위 프로젝트)
• Chrome DevTools Protocol 공식 문서