AI 에이전트 시대, 브라우저 프로필 분리? 이젠 '워크스페이스 관리'가 핵심입니다!

이 글은 2026년 9월 5일 기준 SessionDock 프로젝트 현황에 기반한 개발 보고서입니다. SessionDock은 아직 출시된 완전한 애플리케이션이 아닙니다.

두 개의 AI 에이전트가 두 가지 프로젝트를 동시에 처리해야 한다고 가정해 봅시다. 각각의 에이전트는 로그인까지 완료된 브라우저 환경이 필요하죠. 만약 할당된 워크스페이스가 이미 사용 중이라면, 어떤 에이전트도 다른 프로필이나 브라우저로 몰래 전환해서는 안 됩니다. 이 문제는 생각보다 복잡합니다.

단순히 브라우저 프로필을 분리하는 것은 이 문제의 절반만 해결할 뿐입니다. 데이터 자체는 분리되겠지만, 우리는 워크스페이스가 어느 프로젝트에 속하는지, 누가 특정 시점에 이를 제어할 수 있는지, 그리고 제어권이 사람과 에이전트 사이에서 바뀐 후 지연된 액션은 어떻게 처리해야 하는지까지 알아야 합니다.

SessionDock은 바로 이러한 질문에 소프트웨어적으로 답하기 위한 저희의 시도입니다. 저희는 현재 리눅스 기반 로컬 환경에서 준비된 Chromium 워크스페이스를 개발 중이며, 사용자가 에이전트에게 제한된 시간 동안 작업을 위임할 수 있도록 하는 것을 목표로 합니다. 핵심 상태 관리 및 스케줄러 컴포넌트들은 이미 구현 및 테스트를 마쳤지만, 사용자 입력부터 실제 브라우저 액션까지 이어지는 완전한 경로는 아직 완성되지 않았습니다.

프로필은 '누가' 액션의 주체인지 말해주지 않습니다

단순히 두 개의 로그인을 서로 분리하는 것이 목표라면, 굳이 다른 도구가 필요하지 않을 수 있습니다. 저희 프로젝트의 출발점 역시 개별적인 Chromium 사용자 데이터 디렉터리를 사용하는 것입니다. 간단한 런치 스크립트로 서로 다른 디렉터리를 사용하는 두 개의 브라우저를 열고, 각기 다른 다운로드 경로를 할당해 줄 수도 있죠.

하지만 워크스페이스가 더 이상 한 사람만의 소유가 아니라, 다른 주체들이 번갈아가며 사용하게 될 때 추가적인 요구사항들이 등장합니다.

간단한 예시를 들어보죠. 어떤 사람이 관리 인터페이스에 로그인한 후, 제한된 작업을 에이전트에게 위임합니다. 그런데 작업 도중 사람이 무언가 확인해야 할 일이 생겨 제어권을 되찾아옵니다. 이때, 에이전트가 준비했던 브라우저 액션이 뒤늦게 도착한다면 어떨까요?

브라우저 데이터는 여전히 완벽하게 분리되어 있을 수 있습니다. 하지만 핵심 질문은 남습니다. 과연 에이전트가 그 액션을 계속 실행해도 되는 걸까요?

디렉터리 구조만으로는 이 질문에 답할 수 없습니다. 시스템은 현재 누가 워크스페이스를 제어하고 있는지에 대한 '권위 있는 기록'을 필요로 합니다. 제가 실무에서 자동화 봇을 돌릴 때 가장 당혹스러웠던 순간 중 하나가, 사람이 잠깐 개입했다가 봇이 준비한 액션이 뒤늦게 실행되면서 엉뚱한 결과를 냈을 때였죠. 브라우저 데이터가 아무리 잘 분리되어 있어도, 누가 지금 이 워크스페이스의 '진정한' 주도권을 가졌는지는 알 방법이 없었습니다.

브라우저 워크스페이스를 '관리형 리소스'로 다루기

SessionDock에서는 자체적인 할당과 로컬 데이터를 가진, 미리 준비된 브라우저 워크스페이스를 '슬롯(slot)'이라고 부릅니다.

현재 워크스페이스 코드에서 각 슬롯은 완전한 Chromium 사용자 데이터 디렉터리, 다운로드 디렉터리, 그리고 별도의 XDG 및 D-Bus 경로를 할당받습니다. 그래픽 환경은 독립적인 Weston 데스크톱을 사용하며, 패키징된 브라우저는 Google Chrome이 아닌 Chromium입니다.

스케줄러는 이러한 기술적 분리에 '고정된 바인딩(binding)'을 추가합니다. 데이터 모델에는 프로젝트, 워크트리, 환경, 예상 계정, 예상 테넌트 등의 정보가 포함됩니다. 에이전트 실행은 특정 바인딩에 대한 권한을 부여받으며, 요청할 때마다 임의의 환경을 자유롭게 선택할 수 없도록 설계되었습니다.

여기서 "예상(expected)"이라는 단어가 중요합니다. 저장된 계정 이름이 해당 웹사이트에 실제로 그 계정으로 로그인되어 있다는 것을 증명하지는 않습니다. 완전한 로그인, 확인, 위임 플로우는 아직 통합되지 않았습니다.

마찬가지로, 워크트리 할당 역시 현재 테스트 중인 코어에서는 데이터 모델 개념에 불과합니다. SessionDock이 모든 Git 워크트리를 자동으로 찾아 적절한 인터페이스를 열 수 있다는 의미는 아닙니다.

리스(Lease)로 접근을 제어하고, 에포크(Epoch)로 소유권 변경을 확실히

사람과 에이전트가 동시에 동일한 슬롯에 기록해서는 안 됩니다. 따라서 스케줄러는 독점적이고 시간 제한이 있는 접근 권한인 '리스(leases)'를 사용합니다.

리스의 '에포크(lease epoch)'는 이 모델을 보완합니다. 이는 제어 권한에 대한 단조롭게 증가하는 세대 번호입니다. 제어권이 변경되면, 이전 세대의 권한은 자동으로 무효화됩니다.

간단한 예시를 들어볼까요:

에이전트 A가 에포크 41에서 슬롯을 제어합니다.
사람이 제어권을 다시 가져옵니다.
현재 에포크는 42가 됩니다.
에이전트 A로부터 에포크 41을 가진 지연된 액션이 도착합니다.
권한 확인 절차는 이를 '만료된' 액션으로 간주하여 거부합니다.

디스패치(dispatch) 전에 상태 머신은 에이전트가 여전히 제어권을 가지고 있는지, 세션이 준비되었는지, 그리고 예상되는 리스 에포크가 현재 에포크와 일치하는지 확인합니다. 이 핵심 로직은 단위 테스트를 통해 검증되었습니다.

하지만 이것이 종단 간(end-to-end) 보호되는 브라우저 액션을 증명하는 것은 아닙니다. 확인 절차가 전체 실행 경로의 올바른 지점에 위치해야 하며, 이 통합 작업은 아직 진행 중입니다.

또한, 이러한 확인 절차가 이미 웹사이트에 도달한 액션을 되돌릴 수도 없습니다. 웹 서비스가 변경 사항을 수락했다면, 로컬에서의 제어권 변경이 이를 되돌리지 못합니다. 따라서 알 수 없는 결과, 복구, 그리고 격리(quarantine)는 여전히 설계의 중요한 부분으로 남아 있습니다.

개별 브라우저도 결국 '동일한 리소스'를 변경할 수 있다

스케줄러는 독립적인 슬롯을 병렬로 할당할 수 있습니다. 그러나 이것이 애플리케이션 수준에서 이들의 작업이 독립적이라는 것을 의미하지는 않습니다.

두 개의 개별 브라우저가 동일한 계정을 사용하여 동일한 서버 측 리소스를 수정할 수 있습니다. 예를 들어, 두 에이전트가 동시에 동일한 제품 레코드를 편집할 수도 있습니다. 개별 쿠키와 다운로드 디렉터리가 이런 충돌을 방지하지는 못합니다.

따라서 스케줄러는 '충돌 키(conflict keys)'도 지원합니다. 이는 올바르게 설명된 충돌인 경우, 알려진 공유 리소스에 대한 작업을 조율할 수 있습니다. SessionDock은 임의의 웹사이트 비즈니스 로직을 자동으로 이해하지는 못합니다.

이러한 구분은 데이터 모델에 중요합니다. 로컬 브라우저 분리, 워크스페이스 제어 권한, 그리고 애플리케이션 데이터 충돌은 세 가지 별개의 관심사입니다.

브라우저 실행과 화면 표시는 '별개'의 작업

그래픽 환경은 또 다른 요구사항을 추가합니다. 사람은 에이전트에게 자신의 비밀번호나 TOTP 시드를 제공하지 않고도 실제 Chromium 워크스페이스에 로그인할 수 있어야 합니다. 동시에, 브라우저는 사람의 데스크톱에 일반적인 창으로 계속 나타나지 않아야 합니다.

따라서 워크스페이스 프로토타입은 브라우저 실행과 호스트에서의 표시를 분리합니다. Chromium은 독립적인 Weston 데스크톱에서 실행되도록 설계되었고, 뷰어는 사용자의 명시적인 액션 후에만 별도로 열립니다.

이것은 아키텍처적 결정이지, 포커스 처리나 2단계 인증에 대한 입증된 보장이 아닙니다. 현재 조사 호스트에서는 네임스페이스가 차단되어 실제 Chromium 실행이 실패했습니다. 로그인 및 포커스 테스트 매트릭스도 아직 공개되지 않았습니다. USB 보안 키와 스마트폰 패스키는 현재 프로토타입에서 명시적으로 차단되어 있습니다.

SessionDock은 사용자의 일반적인 데스크톱 Chrome 설치에서 기존 세션을 가져오지도 않습니다. 의도된 흐름은 각 슬롯 내에서 수동으로 로그인하는 것입니다. 영구 프로필 경로는 재시작 후에도 이 로그인을 유지하도록 설계되었지만, 실제 인증 및 재시작 테스트를 통해 아직 입증되지는 않았습니다.

단일 권한 주체, 하지만 아직 완전한 실행 경로는 아님

저장소에는 로컬 API, SQLite 영속성, 스케줄러, 상태 머신을 포함하는 Go 데몬이 있습니다. 또한 별도의 워크스페이스 프로토타입과 Native Messaging을 사용하는 Chromium 확장 프로그램의 일부도 포함되어 있습니다.

이들의 책임은 의도적으로 분리되어 있습니다. 데몬은 권한과 상태에 대한 '권위 있는 출처'로 남아있도록 설계되었습니다. 브라우저 컴포넌트가 자체적인, 잠재적으로 오래된 결정으로 이 권한을 대체해서는 안 됩니다.

이러한 부분들은 아직 사용 가능한 제품으로 연결되어 있지 않습니다. 일반적인 CLI는 데몬을 제어하지 않으며, 실제로는 도움말 및 버전 출력만 사용 가능합니다. MCP 서버, 에이전트 어댑터, 그리고 완전한 액션 실행기는 아직 누락되어 있습니다. 워크스페이스 프로토타입은 아직 스케줄러에 연결되어 있지 않습니다.

따라서 스케줄러 테스트 통과가 성공적인 에이전트 실행을 의미하지는 않습니다. 마찬가지로, 준비된 슬롯 디렉터리가 두 개의 브라우저가 동시에 작동하는 것을 증명하지도 않습니다. 둘 다 개별 컴포넌트에 대한 유용한 증거를 제공하지만, 완전한 사용자 흐름에 대한 증거는 아닙니다.

이 아키텍처가 '보장하지 않는' 보안 경계

분리된 프로필이 모든 로컬 프로세스에 대한 보안 경계가 되는 것은 아닙니다.

슬롯들은 여전히 동일한 호스트에 존재하며 궁극적으로 동일한 호스트 사용자에게 속합니다. Chromium은 호스트의 네트워크 접근을 공유합니다. 에이전트와 에이전트가 도달할 수 있는 다른 모든 호스트 파일 간의 강력한 격리는 아직 구현되지 않았습니다.

만약 에이전트가 SessionDock 외부에서 광범위한 파일 접근 권한을 가지고 있다면, API 권한 모델만으로는 다른 경로를 통한 접근을 막을 수 없습니다. 미래의 모든 보안 주장은 이 경계를 고려해야 할 것입니다.

현재 설계가 말해주는 것

따라서 저희의 설계는 브라우저 창 자체보다는 '준비된 워크스페이스에 대한 통제된 접근'에 중점을 둡니다.

책임은 여러 컴포넌트에 분산되어 있습니다. 슬롯은 로컬 브라우저 데이터를 소유하고, 바인딩은 작업 컨텍스트를 설명하며, 리스는 현재 제어권을 부여합니다. 에포크는 만료된 권한을 감지할 수 있게 하고, 충돌 키는 알려진 공유 리소스를 조율합니다.

핵심 모델은 현재 가시적인 애플리케이션보다 더 진전되어 있습니다. 다음으로 의미 있는 증명은 또 다른 아키텍처 다이어그램이 아니라, 완전한 흐름을 보여주는 것입니다. 즉, 테스트 워크스페이스를 준비하고, 수동으로 로그인한 다음, 제한된 시간 동안 에이전트에게 위임하고, 실제 액션을 관찰하며, 다시 제어권을 되찾아오는 과정 말이죠.

이러한 흐름이 작동하고 테스트되기 전까지 SessionDock은 개발 프로젝트로 남아있을 것입니다. 하지만 근본적인 문제는 이미 분명합니다. 브라우저 에이전트는 단순한 브라우저 그 이상을 필요로 합니다. 에이전트는 명확한 워크스페이스와 그 안에서 행동할 수 있는 검증 가능하고 제한된 권한을 필요로 합니다.

---

원문: https://dev.to/volker_schukai/multiple-browser-agents-need-more-than-separate-profiles-565j 수집일: 2026-09-07 01:31:26