현시점 자동화 1등 브라우저

로그인 벽 앞에서 멈추는 자동화

AI 에이전트에 브라우저를 붙이는 것은 이제 기본 구성입니다. 화면을 읽고, 버튼을 누르고, 결과를 확인하는 일을 사람 대신 처리합니다.

문제는 그다음입니다. 사내 업무 시스템, 관리 콘솔, 링크드인처럼 로그인이 필요한 화면에 닿는 순간 상당수 자동화가 실패합니다. 그런데 에이전트는 오류를 내지 않습니다. 로그인 페이지를 읽고 작업을 마쳤다고 보고합니다.

실무 자동화 기준으로 보면 승부는 이미 갈렸습니다. 사용자가 실제로 쓰는 브라우저에 올라타는 방식이 1등입니다.

다만 근거의 범위를 먼저 밝힙니다. 2026년 7월 기준으로 두 방식(에이전트 전용 헤드리스 브라우저, 실사용 브라우저 제어)을 두 종류의 작업(로그인 서비스의 글 읽기, 공개 페이지 읽기)에 대해 직접 측정한 결과입니다. 시장의 모든 도구를 재본 순위는 아닙니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart LR
    subgraph ISO["격리형"]
        direction TB
        I1["에이전트"] --> I2["새 브라우저<br/>자체 프로필·로그인 없음"]
        I2 --> I3["아무도 아닌 신원"]
    end
    subgraph CO["동거형"]
        direction TB
        C1["에이전트"] --> C2["사용자의 실브라우저<br/>쿠키·로그인 세션 그대로"]
        C2 --> C3["사용자 본인 신원"]
    end
    ISO -.- CO
    style ISO fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style I1 fill:#f9fafb,stroke:#6b7280,color:#1f2937
    style I2 fill:#f9fafb,stroke:#6b7280,color:#1f2937
    style I3 fill:#e5e7eb,stroke:#6b7280,color:#111827
    style CO fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style C1 fill:#eff6ff,stroke:#3b82f6,color:#1f2937
    style C2 fill:#eff6ff,stroke:#3b82f6,color:#1f2937
    style C3 fill:#bfdbfe,stroke:#3b82f6,color:#111827

승부를 가른 축은 성능이 아니라 신원

AI용 브라우저는 크게 두 갈래입니다.

• 격리형 — 에이전트 전용으로 새 브라우저를 띄웁니다. 사람이 쓰는 브라우저와 완전히 분리되어 있고, 자체 프로필을 씁니다.
• 동거형 — 사용자가 지금 쓰고 있는 브라우저에 에이전트가 올라타 조작합니다. 쿠키와 로그인 세션을 그대로 물려받습니다.

겉으로는 같은 일을 합니다. 화면을 읽고 요소를 누릅니다. 그러나 누구의 신원으로 접속하는가가 정반대입니다. 격리형은 아무도 아닌 상태로, 동거형은 사용자 본인으로 접속합니다.

실측 — 33.5초 실패 대 3.5초 성공

같은 작업을 시켰습니다. 로그인이 필요한 서비스에서 피드 최상단 글을 읽어오는 일입니다.

격리형은 33.5초를 쓰고 로그인 페이지로 돌아왔습니다. 저장된 인증 상태가 하나도 없었으므로 당연한 결과입니다. 동거형은 3.5초 만에 본문과 작성자를 가져왔습니다.

작업	격리형	동거형	판정
로그인 서비스 읽기	33.5초 · 실패 (로그인 페이지로 튕김)	3.5초 · 성공 (본문 확보)	동거형
공개 페이지 읽기	1.25초	1.28초	동률

공개 페이지에서는 동률이었습니다

같은 두 방식을 로그인이 필요 없는 공개 페이지로 다시 쟀습니다. 1.25초와 1.28초. 사실상 동률입니다.

여기가 이 측정의 핵심입니다. 격차는 엔진 성능에서 나오지 않았습니다. 로그인 세션의 유무 하나에서 나왔습니다. 공개 페이지만 놓고 벤치마크를 돌린 조직은 정반대 결론에 도달합니다.

조건 하나에서만 잰 성능 비교는 도입 판단을 뒤집습니다.

1등에도 세 가지 예외가 있습니다

판정을 내렸으니 예외도 미루지 않습니다. 다음 세 가지 작업은 여전히 격리형이 맞습니다.

• 대량 수집 — 수십 개 페이지를 순회하는 작업을 실사용 브라우저로 돌리면 탭과 방문 기록이 오염됩니다. 모든 요청이 사용자 본인의 신원으로 나가는 것도 불필요한 노출입니다.
• 자사 서비스 점검 — 직접 만든 서비스의 품질 검증은 오히려 로그인도 쿠키도 없는 첫 방문자 상태가 필요합니다. 내 계정으로 검증하면 기존 세션 때문에 문제를 놓칩니다.
• 위험이 큰 조작 — 자동화가 잘못 눌렀을 때 실계정으로 글이 게시되거나 자료가 삭제될 수 있는 작업입니다. 사고가 나도 격리된 공간 안에서 끝나야 합니다.

즉 질문은 "어느 도구가 더 좋은가"가 아닙니다. 어떤 작업을 어느 쪽으로 보낼 것인가입니다.

flowchart TB
    START["자동화 작업"] --> Q1{"로그인이<br/>필요한가?"}
    Q1 -->|아니오| Q2{"대량 수집·자사 QA·<br/>위험한 조작인가?"}
    Q1 -->|예| CO1["동거형<br/>실브라우저 제어"]
    Q2 -->|예| ISO1["격리형<br/>헤드리스 샌드박스"]
    Q2 -->|아니오| CO2["동거형<br/>실브라우저 제어"]
    style START fill:#e0e7ff,stroke:#6366f1,color:#1f2937
    style Q1 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style Q2 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style ISO1 fill:#f3f4f6,stroke:#6b7280,color:#111827
    style CO1 fill:#dbeafe,stroke:#3b82f6,color:#111827
    style CO2 fill:#dbeafe,stroke:#3b82f6,color:#111827

세 번째 선택지 — 에이전트에게 통째로 맡기기

브라우저 안에 들어 있는 또 다른 AI에게 자연어로 작업을 위임하는 방식도 있습니다. 화면을 직접 읽지 않아도 되니 다루는 정보량은 줄어듭니다.

대신 응답에 20초가 걸렸고, 빠른 모드는 별도 사용량 결제를 요구했습니다. 무엇을 어디서 찾아야 할지 모호한 작업에는 유효하지만, 정해진 화면에서 정해진 값을 읽어오는 일에는 과합니다.

진짜 1등인 이유 — 지능이 어디에 쌓이는가

속도 때문이 아닙니다. 도구를 오래 쓸수록 갈리는 지점은 따로 있습니다.

격리형 도구는 스스로 똑똑해지지 않습니다. 대신 작업 절차가 조직의 문서와 스크립트로 남습니다. 검토할 수 있고, 고칠 수 있고, 다른 사람에게 넘길 수 있습니다.

벤더의 브라우저 에이전트는 반대입니다. 쓸수록 사용자 맥락을 학습해 똑똑해지지만, 그 지능은 벤더 앱 안에 남습니다. 열어볼 수도, 버전을 관리할 수도, 다른 환경으로 옮길 수도 없습니다. 서비스를 해지하면 함께 사라집니다.

실사용 브라우저에 직접 제어를 붙이는 방식만이 둘을 동시에 가져갑니다. 로그인 세션은 브라우저에서 빌리고, 작업 절차는 조직 자산으로 쌓습니다. 도구 선택은 성능 비교가 아니라 자산 귀속의 문제입니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart LR
    subgraph VEN["벤더 에이전트 방식"]
        direction TB
        V1["지능"] --> V2["벤더 앱 안에 갇힘<br/>열람·이식·버전관리 불가"]
        V2 --> V3["해지하면 사라짐"]
    end
    subgraph OWN["실브라우저 직접 제어"]
        direction TB
        O1["로그인 세션"] --> O2["브라우저에서 빌림"]
        O3["작업 절차"] --> O4["조직 자산으로 남김<br/>문서·스크립트"]
    end
    VEN -.- OWN
    style VEN fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style V1 fill:#fffbeb,stroke:#f59e0b,color:#1f2937
    style V2 fill:#fffbeb,stroke:#f59e0b,color:#1f2937
    style V3 fill:#fde68a,stroke:#f59e0b,color:#111827
    style OWN fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style O1 fill:#f0fdf4,stroke:#22c55e,color:#1f2937
    style O2 fill:#f0fdf4,stroke:#22c55e,color:#1f2937
    style O3 fill:#f0fdf4,stroke:#22c55e,color:#1f2937
    style O4 fill:#bbf7d0,stroke:#22c55e,color:#111827

도구 하나를 고르는 데 밟은 3단계

이 판단은 30분 만에 끝났습니다. 순서는 세 단계였습니다.

• 측정 — 실제 업무와 같은 작업으로 두 방식을 재고 숫자를 남깁니다.
• 정책 — 작업 유형별로 어느 쪽에 보낼지 규칙을 정하고, 예외를 명시합니다.
• 자산화 — 그 규칙을 사람과 에이전트가 실제로 읽는 위치에 기록합니다.

조직 단위 AX가 개념 증명(PoC)에서 멈추는 지점이 정확히 여기입니다. 도구는 도입하지만 측정하지 않고, 측정해도 정책으로 만들지 않으며, 정책을 정해도 기록하지 않습니다. 측정 없이 도입한 도구는 정책이 될 수 없습니다.

flowchart LR
    M["측정<br/>실업무로 재고 숫자를 남김"] --> P["정책<br/>작업별 라우팅 규칙·예외"]
    P --> A["자산화<br/>에이전트가 읽는 곳에 기록"]
    A -->|새 도구·작업마다 반복| M
    style M fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style P fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style A fill:#dcfce7,stroke:#22c55e,color:#1f2937

마치며

AI 브라우저 도입을 검토 중인 조직이라면 순서는 하나입니다. 공개 페이지가 아니라 실제 업무 화면으로 재고, 로그인 필요 여부로 1차 분기하고, 오조작 위험이 큰 작업만 격리로 남깁니다.

그리고 정한 규칙을 에이전트가 읽는 위치에 적어둡니다. 기록되지 않은 판단은 다음 주에 사라집니다.