서론

지금까지 「AI 에이전트 검증용 PC를 만드는 메모」로서, 설계 사상의 정리부터 Docker, WSL, Git, Node.js, Codex CLI 도입까지를 기록해 왔다.

하지만 시리즈를 되돌아보면, 애초에 「왜 검증 전용 PC를 준비했는가」라는 출발점을 충분히 쓰지 못했다.

이 검증용 PC를 만든 본래의 목적은 Codex CLI를 구동하는 것만이 아니다.

시도해보고 싶었던 것은 브라우저 상의 정보를 읽고, 여러 탭을 다루며, 경우에 따라서는 Web 상에서 조작까지 수행하는 AI 에이전트였다.

하지만 평소 사용하는 PC나 브라우저에는 로그인 정보, Cookie, 열람 기록, 클라우드 서비스, 개인 파일 등이 모여 있다.

편리해 보인다고 해서 갑자기 평소 사용하는 환경에서 시도하는 것은 불안했다.

그래서 오래된 노트북 PC를 초기화하고, Microsoft 계정, Google 계정, AI 서비스의 계정도 검증용으로 분리하기로 했다.

본래 시도하고 싶었던 것은 브라우저 AI 에이전트였다

현재 이 시리즈에서는 다음과 같은 구축을 진행하고 있다.

Docker Desktop
WSL2 / Ubuntu
Git
...

여기까지의 흐름만 보면 Codex CLI나 개발 환경을 만드는 것이 첫 번째 목적이었던 것처럼 보인다.

하지만 출발점은 다른 곳에 있었다.

본래 시도해보고 싶었던 것은 다음과 같은 AI 에이전트였다.

• 브라우저 상의 여러 페이지를 읽는다
• Web 상의 정보를 비교·정리한다
• 브라우저 내에서 작업을 보조한다
• 로컬 파일을 읽거나 편집한다
• 여러 도구를 횡단하여 작업한다

기존의 채팅 AI보다 PC나 브라우저에 접할 수 있는 범위가 넓다.

그렇기에 평소 사용하는 환경과는 분리하여 시도하고 싶다고 생각했다.

평소 사용하는 PC에서 시도하는 것이 무서웠던 이유

평소 사용하는 브라우저에는 상상 이상으로 많은 정보가 모여 있다.

로그인 중인 Web 서비스
Cookie 및 세션 정보
검색 기록·열람 기록
...

브라우저 AI 에이전트가 어디까지 액세스할 수 있는지는 제품이나 설정에 따라 다르다.

다만, 액세스할 수 있는 범위가 넓은 도구를 테스트한다면, 처음부터 진짜 데이터가 들어있는 환경을 넘겨주지 않는 편이 안심할 수 있다.

그래서 평소 사용하는 PC에 추가하는 것이 아니라, 오래된 노트북 PC를 검증 전용기로 사용하기로 했다.

처음에 단말기를 초기화했다

검증용으로 사용할 노트북 PC는 한 번 초기화했다.

목적은 단순히 동작을 가볍게 하기 위함이 아니다.

이전의 이용 데이터나 계정, 평소 사용하는 파일이 남은 상태에서 AI 에이전트를 테스트하지 않기 위해서다.

메인 PC
→ 평소의 업무, 제작, 개인 데이터를 다룸
검증용 PC
...

이것은 네트워크로부터 완전히 격리하는 「에어 갭 (Air Gap)」은 아니다.

같은 가정 내 네트워크로 접속하는 경우도 있기 때문에, 단말기를 분리하는 것만으로 모든 리스크가 사라지는 것은 아니다.

그럼에도 개인 데이터나 업무 환경과 물리적으로 단말기를 분리함으로써, 오작동 시의 영향 범위를 작게 만들 수 있다고 생각했다.

계정도 검증용으로 분리했다

단말기뿐만 아니라 검증에 사용하는 계정도 분리했다.

보안상의 이유만은 아니다.

평소 사용하는 AI 서비스에는 단순한 작업 이력이 아니라, 오랜 시간을 들여 쌓아온 소중한 대화나 설정이 남아 있다.

검증 중의 오작동이나 예기치 않은 연동으로 인해 그것들에 영향이 미칠 가능성을 가능한 한 피하고 싶었다.

그 때문에 다소 번거로움이나 비용이 늘어나더라도 Microsoft, Google, AI 서비스의 계정을 검증용으로 분리하기로 했다.

이번에 새로 준비한 것은 다음과 같은 계정이다.

• Windows에서 사용하는 Microsoft 계정
• Google 관련 서비스의 검증용 계정
• ChatGPT 등 AI 서비스의 검증용 계정
• 향후 사용할 가능성이 있는 개발·클라우드 서비스의 검증용 계정

실제 기사에서는 이메일 주소, 계정명, 전화번호 등은 공개하지 않는다.

중요한 것은 평소 사용하는 계정을 그대로 AI 에이전트에게 넘겨주지 않는 것이었다.

검증용 계정에는 처음부터 다음과 같은 것을 가져오지 않는다.

개인 메일
업무 메일
진짜 고객 데이터
...

우선은 공개 정보, 더미 데이터, 잃어버려도 상관없는 테스트 파일만으로 시도한다.

사실, 이 시점에서 작은 실험은 시작할 수 있었다

단말기를 초기화하고, 검증용 계정을 준비하고, 개인 데이터를 가져오지 않는 상태로 만들었다.

공개 웹 페이지의 요약이나, 더미 계정(Dummy Account)을 사용한 작은 브라우저 AI 실험이라면 이 시점부터 시작할 수도 있었다.

하지만 당시에는 Docker를 사용하면 브라우저 AI 에이전트(AI Agent)를 포함하여 더욱 강력하게 격리할 수 있지 않을까 생각했다.

그래서 먼저 Docker나 WSL2의 환경 구축으로 넘어갔다.

Docker라면 전부 격리할 수 있다고 생각했다

당시에는 Docker에 대해 "애플리케이션이나 실행 환경을 안전한 상자 안에 가둘 수 있는 메커니즘"이라는 이미지를 가지고 있었다.

AI 에이전트
↓
Docker에 넣기
...

Docker는 애플리케이션이나 의존성(Dependency)을 컨테이너(Container) 내로 분리하기 위한 편리한 메커니즘이다.

Python 등의 실행 환경을 Windows 본체에 직접 설치하지 않고, 컨테이너 내부에서만 구동하는 용도로도 적합하다.

실제로 다음과 같은 검증은 가능했다.

Windows 측
C:\AI-LAB\workspace
Docker 컨테이너 측
...

Windows 측의 검증용 폴더만을 컨테이너로 전달하고, 컨테이너 내부의 Python을 구동하는 것까지는 성공했다.

하지만 Docker는 PC 위의 모든 AI 에이전트를 그대로 간단하게 가둘 수 있는 만능 상자는 아니었다.

브라우저 통합형 AI를 Docker에 넣는 것은 별개의 문제였다

브라우저 AI 에이전트 중에는 평소 사용하는 데스크톱 브라우저에 통합되는 것들이 있다.

이 경우, Docker 컨테이너 내에 단순히 설치한다고 해서 끝나는 것이 아니다.

GUI 브라우저를 컨테이너 내에서 구동할 경우, 용도에 따라 다음과 같은 메커니즘이 필요해진다.

헤드리스 브라우저 (Headless Browser)
Playwright나 Selenium
화면 표시용 VNC
...

게다가 일반 사용자용 브라우저 통합 기능이나 데스크톱 앱은 애초에 Docker 내에서 구동하는 것을 전제로 하지 않는 경우도 있다.

Docker 내에서 Chromium을 자동 조작하는 메커니즘을 만드는 것과, 평소 사용하는 브라우저의 AI 기능을 Docker에 가두는 것은 별개의 문제였다.

실제로 조사하고 접하면서, 같은 AI 에이전트라도 브라우저, 로컬 파일, 터미널(Terminal), 컨테이너 등 액세스할 수 있는 범위가 크게 다르다는 것을 알게 되었다.

따라서 하나의 격리 방법으로 모든 것을 지키려 하기보다, 종류별로 "우리(Cage)"를 나누어 생각하기로 했다.

AI 에이전트마다 다른 "우리"

현재는 에이전트를 크게 3가지 종류로 나누어 생각하고 있다.

브라우저 계열 AI 에이전트

브라우저상의 페이지나 탭, 웹 서비스(Web Service)를 다루는 에이전트.

전용 PC
검증용 브라우저 프로필
검증용 계정
...

브라우저 계열에서는 Docker에만 의존하기보다 단말기·계정·브라우저 프로필을 분리하는 것이 현실적인 격리 방법이 된다.

CLI · 로컬 파일 조작 계열

Codex CLI나 Claude Code 등, 터미널에서 파일을 조작하는 에이전트.

WSL / Ubuntu
~/agent-sandbox
Git을 통한 차이(Diff) 확인
...

이쪽은 조작 대상이 되는 작업 디렉터리(Working Directory)를 한정하고, Git으로 변경 사항을 확인할 수 있는 상태를 만든다.

Docker로 구동하는 앱이나 서비스

Python 환경, 웹 앱(Web App), Dify 등, 컨테이너로서 구동하는 대상.

Docker 컨테이너
마운트할 폴더를 한정
불필요한 포트(Port)를 공개하지 않음
...

Docker는 이 종류의 격리에 강하다.

CLI 에이전트 구축은 탈선이 아니었다

본래의 목적이 브라우저 AI 에이전트였다면, CLI 에이전트 구축은 멀리 돌아온 것처럼 보일 수도 있다.

하지만 첫 번째 검증 대상으로 Codex CLI를 시도해 본 것은 결과적으로 중요한 배움이 되었다.

Codex CLI를 시도하는 과정에서 다음과 같은 사항을 실제로 확인할 수 있었다.

• AI 에이전트가 접촉하는 작업 장소를 한정한다
• 작업 전에 Git 상태를 확인한다
• 작업 후에 git status와 git diff를 확인한다
• 변경 내용을 확인한 뒤 커밋(Commit)한다
• 비밀 정보(Secret)를 작업 장소로 가져오지 않는다
• AI를 위한 안전 규칙을 파일로 전달한다
• 파괴적인 조작을 승인 없이 수행하게 하지 않는다

이것들은 향후 Claude Code 등 다른 CLI 에이전트를 시도할 때도 공통적으로 사용할 수 있는 사고방식이다.

Docker, WSL, Git, Codex CLI의 구축은 본래의 목적에서 벗어난 것이 아니었다.

CLI 에이전트 (CLI Agent)에게 어디까지 권한을 부여하고, 무엇을 직접 확인할 것인지를 이해하기 위한 별도의 레이어 (Layer) 준비였다.

현재의 검증 환경

현재의 구성은 다음과 같다.

검증 전용 노트북 PC
├─ 검증용 Microsoft 계정
├─ 검증용 Google 계정
...

외부에는 전용 PC와 검증용 계정이 있다.

내부에는 Windows 측의 AI-LAB,
Ubuntu 측의 agent-sandbox,
Docker 컨테이너가 있다.

하나의 메커니즘으로 모든 것을 보호하는 것이 아니라, 여러 개의 작은 격리 (Isolation)를 겹치는 구성이 되었다.

앞으로 시도하고 싶은 것

앞으로는 에이전트별로 작은 실험부터 시작한다.

브라우저 계열

• 공개 웹 페이지 요약
• 여러 탭의 정보 비교
• 더미 (Dummy) 계정을 사용한 조작
• 연동 서비스를 최소한으로 제한한 검증
• 다운로드 및 외부 전송 확인

CLI · 로컬 파일 계열

• agent-sandbox 내의 작은 파일 편집 - Git으로 차이(Diff) 확인
• Codex와 Claude Code의 동작 비교
• AI용 규칙 파일 검증

Docker 계열

• 검증용 앱의 컨테이너 실행
• 마운트 (Mount) 범위 확인
• 포트 (Port) 공개 범위 확인
• 비밀 정보를 다루기 전의 설계
• Docker secrets 등의 검토

갑자기 실무 데이터나 평소 사용하는 계정을 넘겨주지는 않는다.

우선은 "실패해도 상관없는 실험"을 반복한다.

초보자였기에 남겨두고 싶은 것

당초에는 Docker를 사용하면 모든 AI 에이전트를 안전하게 격리할 수 있을 것이라고 생각했다.

실제로 에이전트의 종류에 따라 필요한 격리 방법은 달랐다.

이는 단순한 실패라기보다, 첫 가설을 실제 구축을 통해 업데이트한 결과다.

최초의 가설
Docker로 한꺼번에 격리한다
구축 후의 이해
...

처음부터 정답을 알고 있었던 것은 아니다.

모르는 상태에서 작게 시도하고, 차이를 깨닫고, 설계를 수정해 나갔다.

마찬가지로 "AI 에이전트를 시도하고 싶지만, 평소 사용하는 PC에서 돌리는 것은 무섭다"라고 느끼는 사람에게 하나의 검토 자료가 된다면 좋겠다.

요약

브라우저 AI 에이전트를 안전하게 테스트하기 위해 오래된 노트북 PC를 초기화하고, 검증용 계정도 분리했다.

처음에는 Docker가 모든 것을 격리해 줄 것이라고 생각했다.

하지만 실제로는 AI 에이전트의 종류에 따라 서로 다른 격리 방법이 필요했다.

브라우저 계열
→ 전용 PC · 검증용 계정 · 브라우저 프로필 (Browser Profile)
CLI · 파일 조작 계열
...

전용 PC를 준비한 판단은 최종 목적에서 벗어나지 않았다.

오히려 브라우저 AI 에이전트를 테스트하기 위해 필요한, 가장 바깥쪽의 격리를 가장 먼저 만들었던 것이다.

Docker, WSL, Git, CLI 에이전트 환경의 구축은 그 내부로 안전한 작업 공간을 추가해 나가는 공정이었다.

본편에서는 충분히 다루지 못했던 "검증 환경의 외부를 어떻게 나누었는가"를 정리하기 위해, 이번 기사를 설계 보충으로서 정리했다.

앞으로는 처음에 시도하고 싶었던 브라우저 계열 AI 에이전트에 대해서도 검증용 환경 안에서 작게 시도해 나갈 것이다.

보충

이 기사는 필자가 실제로 AI 에이전트 검증용 단말기를 구축하는 과정에서 얻은 작업 로그와 시행착오를 바탕으로, ChatGPT와의 대화를 통해 정리 및 집필한 것입니다.

절차나 설계 방침은 실제로 시도한 내용과 그 과정에서 얻은 배움을 기반으로 정리했습니다.

Discussion