매번 로그인 때문에 멈추는 브라우저 에이전트 문제

이 기사는 MCP를 통해 브라우저 조작 에이전트를 사용하면서, 로그인이 필수인 사이트에서 매번 멈추고 있는 분들을 위한 글입니다.

여기서 말하는 MCP는 Model Context Protocol을 의미합니다. Claude Desktop이나 Cursor와 같은 클라이언트에서 외부 도구를 호출하기 위한 메커니즘이라고 생각하면 이해하기 쉽습니다. agent-browser는 해당 MCP를 통해 브라우저를 열거나, 클릭하거나, 페이지를 읽을 수 있는 도구입니다.

예를 들어, Google, SaaS 관리 화면, 사내 대시보드를 에이전트가 조작하게 하고 싶다고 가정해 봅시다. 브라우저 조작 자체는 가능하더라도, 매번 로그인이나 2FA(2단계 인증)가 끼어들면 워크플로우가 끊깁니다. 사람이 매번 인증을 도와줘야 한다면 에이전트화한 의미가 퇴색됩니다.

이 기사에서는 Vercel Labs의 agent-browser로 로그인 상태를 유지하는 방법을 실제 시도한 결과로부터 정리합니다.

AGENT_BROWSER_PROFILE로 브라우저 상태를 고정하기

결론: agent-browser로 로그인 상태를 지속하고 싶다면, MCP 서버 설정에 고정 session과 persistent profile path를 지정하는 것이 유효했습니다.

{
"mcpServers": {
"agent-browser": {
...

이 설정에서는 MCP 클라이언트가 agent-browser mcp를 실행할 때, 동일한 session 이름과 동일한 profile directory를 매번 전달합니다. 그러면 브라우저 측에서는 "지난번과 동일한 사용자의 브라우저"로 인식하여 실행하기 쉬워집니다.

MCP를 통해서도 동일한 profile directory를 읽게 하는 것이 로그인 지속의 핵심입니다.

중요한 것은 AGENT_BROWSER_PROFILE입니다.

브라우저의 profile에는 cookie, localStorage, IndexedDB, Service Worker, cache 등이 저장됩니다. 평소 Chrome에서 로그인 상태가 유지되는 것도 이러한 브라우저 측 저장 영역이 있기 때문입니다.

--restore / AGENT_BROWSER_RESTORE를 통해서도 cookie나 localStorage는 자동으로 저장할 수 있습니다. 다만, Google 로그인과 같은 인증에서는 cookie뿐만 아니라 IndexedDB, Service Worker, cache 등도 관계될 수 있습니다. 따라서 브라우저 profile 전체를 고정하는 편이 더 안전합니다.

session과 profile은 무엇이 다른가

agent-browser에는 --session이 있습니다. 이는 브라우저 인스턴스나 storage를 session별로 나누기 위한 이름입니다.

하지만 session은 "어느 브라우저 조작의 묶음인가"를 식별하는 이름입니다. 반면, 로그인 상태를 길게 남기려면 "브라우저가 어디에 상태를 저장할 것인가"도 결정해야 합니다. 이 저장 장소가 바로 profile directory입니다.

선택지는 주로 3가지가 있습니다.

방법	적합한 용도
--session	동시에 여러 브라우저 조작을 분리하고 싶을 때
--session <id> --restore	cookie / localStorage를 자동 저장·복원하고 싶을 때
--profile <path>	로그인된 브라우저 상태를 통째로 지속하고 싶을 때

이번에 하고 싶은 것은 MCP를 통한 에이전트가 로그인된 사이트를 지속적으로 이용하게 하는 것입니다. 따라서 중심에 두어야 할 것은 --profile <path>였습니다.

로그인 지속을 위해서는 session 이름뿐만 아니라 "상태의 저장 장소"를 고정해야 합니다.

우선은 cookie와 localStorage 저장만 분리하기

먼저, 인증 사이트가 아닌 example.com에서 최소한의 확인을 진행했습니다.

갑자기 Google에서 시도하면 실패했을 때 원인을 파악하기 어렵습니다. 로그인 자체가 실패한 것인지, cookie가 남지 않은 것인지, 아니면 profile 지정이 잘못된 것인지 구분하기 어렵기 때문입니다. 그래서 우선 cookie와 localStorage만을 직접 작성하고, 브라우저를 닫은 후에도 남아있는지 확인했습니다.

확인한 agent-browser 버전은 다음과 같습니다.

agent-browser 0.31.1

사용한 session과 profile입니다.

SESSION=mcp_persist_test
PROFILE=~/.agent-browser/profiles/mcp-persistence-test

실행 흐름은 다음과 같습니다.

agent-browser --session "$SESSION" --profile "$PROFILE" open https://example.com
agent-browser --session "$SESSION" eval \
"localStorage.setItem('agent_browser_persist_test','ok-'+Date.now()); \
...

이 명령에서는 먼저 example.com을 엽니다. 그다음 JavaScript의 eval로 localStorage와 cookie에 테스트용 값을 작성합니다. 그 후 브라우저를 닫고, 동일한 profile을 지정하여 다시 엽니다. 마지막으로 저장된 값이 남아있는지 읽어옵니다.

인증 사이트에서 시도하기 전에, 저장 메커니즘만을 분리하여 확인합니다.

재시작 후의 출력입니다.

{
"ls": "ok-<timestamp>",
"cookie": "agent_browser_persist_cookie=ok",
...

적어도 cookie와 localStorage는 브라우저를 닫은 후에도 동일한 profile로 복원할 수 있었습니다.

env 경로로도 재사용할 수 있는가

다음으로 MCP에서 사용하는 형태에 가깝게 만들었습니다.

MCP 클라이언트는 agent-browser mcp를 서브프로세스 (subprocess)로 실행합니다. 실제 운영 시에는 매번 CLI 플래그 (flag)를 수동으로 지정하는 대신, MCP 설정 (config)의 env에 환경 변수 (environment variable)로 설정하는 경우가 많습니다.

그래서 환경 변수만으로 동일한 profile을 지정하여 확인했습니다.

AGENT_BROWSER_SESSION="$SESSION" \
AGENT_BROWSER_PROFILE="$PROFILE" \
agent-browser open https://example.com
...

출력은 동일했습니다.

{
"ls": "ok-<timestamp>",
"cookie": "agent_browser_persist_cookie=ok",
...

즉, MCP 설정 (config)의 env에 AGENT_BROWSER_PROFILE을 넣는 방침은 적어도 동일한 환경 변수 경로에서는 작동했습니다.

참고로, 이 실험에서는 실제 MCP 도구 호출 (tool call)까지 직접 실행하지는 않았습니다. 다만 agent-browser의 README에서는 MCP의 도구 호출 (tool invocation)은 CLI와 동일한 설정 파일 (config file)과 환경 변수 (environment variable)를 사용한다고 설명되어 있습니다.

Google 로그인은 브라우저를 닫아도 유지될 수 있는가

마지막으로 실제 로그인이 포함된 Google 계정으로 시도했습니다.

여기서는 인증 정보를 에이전트 (agent)에게 전달하지 않았습니다. headed browser를 열고, 사람이 수동으로 로그인과 2FA를 완료했습니다. headed는 브라우저 화면을 표시하는 실행 모드입니다. 첫 로그인이나 2FA 시에는 사람이 화면을 보고 조작할 수 있는 편이 안전합니다.

사용한 설정입니다.

SESSION=google-login-test
PROFILE=~/.agent-browser/profiles/google-login-test

실행 명령입니다.

agent-browser \
--session "$SESSION" \
--profile "$PROFILE" \
...

로그인 후, https://myaccount.google.com/를 열어 확인했습니다.

agent-browser --session "$SESSION" open https://myaccount.google.com/
agent-browser --session "$SESSION" wait --load networkidle
agent-browser --session "$SESSION" get url
...

관찰 결과입니다.

URL: https://myaccount.google.com/
TITLE: Google 계정

Google 계정 설정 페이지의 본문도 읽을 수 있었습니다. 로그인된 상태임을 확인할 수 있었습니다.

그 후, browser session을 닫았습니다.

agent-browser --session "$SESSION" close

동일한 profile로 재시작했습니다.

agent-browser \
--session "$SESSION" \
--profile "$PROFILE" \
...

재시작 후에도 동일한 상태였습니다.

URL_AFTER_REOPEN: https://myaccount.google.com/
TITLE_AFTER_REOPEN: Google 계정

Google 로그인 화면으로 돌아가지 않았습니다. 이번 환경에서는 Google 로그인도 persistent profile로 지속할 수 있었습니다.

인증 정보는 에이전트에게 전달하지 않고, 최초 1회만 사람이 로그인합니다.

그대로 사용할 수 있는 MCP 설정 예시

실운영에서는 우선 이 형태가 적절해 보입니다.

{
"mcpServers": {
"agent-browser": {
...

AGENT_BROWSER_SESSION은 MCP를 통한 브라우저 조작을 동일한 session으로 모으기 위한 이름입니다. AGENT_BROWSER_PROFILE은 로그인 상태를 저장하는 profile directory입니다. AGENT_BROWSER_HEADED는 최초 로그인 시 화면을 표시하기 위해 사용합니다. AGENT_BROWSER_IDLE_TIMEOUT_MS는 아무런 조작이 없을 때 daemon을 자동으로 종료하기까지의 시간입니다. 위의 예시에서는 3600000 ms, 즉 1시간으로 설정했습니다.

필요하다면 AGENT_BROWSER_RESTORE도 추가합니다.

{
"AGENT_BROWSER_RESTORE": "myapp"
}

단, Google이나 SaaS 관리 화면과 같은 로그인에서는 우선 AGENT_BROWSER_PROFILE을 고정하는 쪽을 우선시하고 싶습니다.

profile은 "로그인된 브라우저의 저장소"로 취급

다른 사이트나 팀에서 사용할 때는, profile을 "로그인된 브라우저의 저장소"로 취급하면 이해하기 쉽습니다.

먼저, 사이트나 용도별로 profile path를 나눕니다.

~/.agent-browser/profiles/google-login-test
~/.agent-browser/profiles/company-admin
~/.agent-browser/profiles/staging-dashboard

profile을 나누는 이유는 로그인 상태를 섞이지 않게 하기 위해서입니다. Google용, 사내 관리 화면용, 검증 환경용을 동일한 profile에 넣으면 cookie나 권한을 분리하기 어려워집니다. 용도별로 나누어 두면 불필요해진 profile만 삭제할 수도 있습니다.

profile은 로그인된 브라우저의 저장소이므로, 용도별로 나누어 비밀 정보로 취급합니다.

그 바탕 위에서, MCP config의 env에 AGENT_BROWSER_PROFILE을 고정합니다. 최초 1회만 AGENT_BROWSER_HEADED=true로 브라우저를 열어 사람이 로그인과 2FA를 완료합니다.

2회차부터는 동일한 profile을 사용하여 로그인된 상태로 열 수 있는지 확인합니다. 여기까지 가능하다면 에이전트에게 비밀번호나 2FA code를 전달할 필요가 없습니다.

주의할 점은 profile directory를 Git 관리 대상에 포함하지 않는 것입니다. profile에는 인증된 cookie나 token이 포함되어 있으므로, 코드가 아닌 비밀 정보에 가깝게 취급해야 합니다.

만약 browser가 제대로 실행되지 않는다면, 먼저 session을 종료합니다.

agent-browser --session myapp close

이 작업은 실행 중인 browser session을 종료하기 위한 것입니다. 로그인 상태가 저장된 profile directory 자체를 삭제하는 작업이 아닙니다.

오래된 socket이나 pid의 sidecar가 남아 있는 경우, 해당 session의 상태를 정리합니다. 단, 로그인 상태를 유지하고 싶다면 profile directory까지 삭제하지 않도록 주의하십시오.

사용 전 알아두어야 할 제약 사항

이번 검증에서는 Google 로그인의 유지가 확인되었습니다. 하지만 모든 환경에서 동일하게 작동한다는 보장은 없습니다.

추가 확인이 필요할 가능성이 높은 케이스는 다음과 같습니다.

• Google Workspace나 사내 IdP의 정책이 엄격한 경우
• IP, device fingerprint, browser version의 변화로 인해 재인증이 필요한 경우
• 장기간 방치 후 session이 만료되는 경우
• SSO가 추가 조건을 요구하는 경우
• 서비스 측에서 headless 액세스를 제한하는 경우

어떤 방법을 선택해야 하는가

MCP를 통한 브라우저 에이전트에서 로그인 상태를 끊김 없이 사용하고 싶다면, 우선 persistent profile을 사용하는 것이 좋아 보입니다.

• 일시적인 작업 분리가 목적이라면 session을 사용합니다.
• cookie / localStorage의 복원이 목적이라면 --restore를 사용합니다.
• Google이나 SaaS 관리 화면과 같은 실제 로그인이 목적이라면 --profile <path>를 사용합니다.

브라우저 에이전트 도입 후 발생하는 마찰은 단순히 "페이지를 조작할 수 있는가"에 그치지 않습니다. "인증을 포함한 상태를 안전하게 지속할 수 있는가"가 실용성을 좌우합니다.

이번 검증에서 agent-browser의 persistent profile은 그 마찰을 상당히 줄여줄 수 있었습니다.

참고 자료

• agent-browser repository: https://github.com/vercel-labs/agent-browser - MCP server section in README: https://github.com/vercel-labs/agent-browser#mcp-server
• Authentication / sessions docs: https://github.com/vercel-labs/agent-browser/blob/main/docs/src/app/sessions/page.mdx
• Configuration docs: https://github.com/vercel-labs/agent-browser/blob/main/docs/src/app/configuration/page.mdx

Discussion