처음에는 브라우저 오른쪽에서 대화도 하고 코드도 고치면 편하겠다고 생각했다. 개발이 진행되면서 더 중요한 것은 대화창의 위치보다 이미 만들어 둔 도구를 같은 대화에서 정확히 쓰는 일이라는 판단이 생겼다. 그 변화 때문에 내부 CLI를 제거하고 외부 MCP 연결을 중심으로 다시 정리했다.
옆에 있다는 편의와 책임이 한곳에 있다는 문제
브라우저 안의 대화는 보고 있는 페이지와 요청을 가까이 둘 수 있었다. 하지만 요청 해석과 다음 행동 선택, 오류 조사와 실행까지 내부에서 계속 이어지면 어떤 부분이 브라우저의 책임이고 어떤 부분이 에이전트의 판단인지 설명하기 어려워졌다. 이미 만든 플러그인을 외부 대화에서도 쓸 수 있다면 판단 창을 한 번 더 가질 필요가 있는지 다시 보게 됐다.
개발 기록에는 내부 CLI를 먼저 비활성화하고, 기존 탭·로그인·플러그인·주피터를 유지한 채 외부에서 실제 작업을 시험하자는 요청이 남아 있다. 이후 제거로 이어졌다. 이 과정을 처음부터 완성된 한 가지 설계를 그대로 실행한 이야기로 쓰고 싶지는 않다. 사용해 본 뒤 경계를 바꾼 선택이었다.
대화를 없앤 것이 아니라 실행 호스트의 역할을 정했다
현재 구조에서 새로운 판단은 연결된 외부 Codex 대화가 맡는다. 브라우저는 실제 세션과 탭, 작업 상태와 중지를 소유한다. 외부에서 명령이 왔다고 다른 계정으로 조용히 바꾸거나 이미 전달한 변경을 다시 실행하지 않는다. 어디서 판단하든 실제 동작은 기존 검증 통로를 지나도록 남겨 뒀다.
이 구분 덕분에 플러그인을 쓸 때 내부 모델을 한 번 더 호출하지 않는 경로를 만들 수 있었다. 다만 외부 에이전트의 판단 비용이 사라지는 것은 아니다. 또 연결이 끊겼을 때 브라우저의 실행 상태가 없어지는 것도 아니다. 대화의 수명과 실행의 수명을 서로 다르게 보관해야 이후 결과를 읽고 이어갈 수 있다.
연결은 같은 브라우저의 고정된 입구를 사용한다
외부 MCP 서버는 stdio 입구를 제공하고 실행 중 앱의 인증된 로컬 파이프와 연결한다. 명령과 인자는 엄격한 계약으로 검사한다. 현재 작업 확인, 필요한 스키마 발견, 플러그인 실행과 상태 읽기처럼 역할이 나뉜 명령을 사용한다. 임의 페이지 JavaScript나 일반 셸 실행을 브라우저 제어 도구로 추가한 방식은 아니다.
개인 연결 파일의 토큰이나 실제 경로를 사용 안내에 넣을 필요는 없었다. 연결이 어디에 있는지 아는 호스트 설정과 공개할 기능 계약은 다르다. 같은 컴퓨터 사용자 권한 안의 로컬 연결이라는 한계도 남아 있다. 파이프를 사용한다는 이유만으로 컴퓨터 전체가 격리됐다고 표현하지 않는다.
UI에서 하던 일을 우회하지 않도록 연결했다
MCP 명령도 같은 TaskController와 ActionBroker, 탭 사용권과 네이티브 입력·실제 결과 확인을 사용한다. 외부 호출이라고 더 약한 실행기를 만들면 화면에서 지킨 규칙이 바깥에서는 사라질 수 있다. 그래서 새로운 입구를 만드는 것과 새로운 권한을 만드는 것을 분리했다.
작업 완료도 단순히 외부 대화가 끝났다는 이유로 결정하지 않는다. 시작한 작업의 상태와 미확정 결과를 확인하고, 원래 기대 조건을 입증해야 완료로 이어진다. 이 부분은 별도 ERP의 저장 응답 이야기와 닮아 보여도 다루는 경계가 다르다. 여기서는 브라우저에 전달된 실제 입력과 그 입력의 결과를 연결한다.
기존 작업을 버리지 않는 전환이 필요했다
제거의 대상은 내부 모델·CLI 게이트웨이와 연결된 런타임·화면·IPC였다. 기존 대화와 설정을 디스크에서 지워 전환한 것은 아니었다. 현재 탭과 로그인, 플러그인과 노트북을 보존해 외부 대화가 그 자산을 다시 사용할 수 있어야 했다. 코드를 덜어내는 작업에도 보존할 대상의 목록이 필요했다.
과거 소스를 archive에 둔 것은 역사적 회귀와 복구 자료를 남기기 위한 것이다. 현재 제품에서 자동으로 다시 불러올 기능으로 소개하면 안 된다. 이후 코드와 문서를 읽을 때도 이전 내장 모델의 설명이 보이면 시점과 현재 연결을 함께 확인한다. 전환의 완료와 과거 기록의 존재는 모순이 아니다.
다른 업무 프로그램에서도 먼저 나눌 질문
에이전트가 직접 다룰 프로그램을 만든다면 요청을 이해하는 주체, 실행 상태를 보관하는 주체, 결과를 확인하는 주체를 먼저 정하면 좋다. 모두 같은 프로세스에 넣어야만 편한 것은 아니다. 실행이 반복되고 대화는 길어질수록 이 책임을 설명할 수 있는 구조가 유지보수에 도움이 된다.
이 글은 현재 소스의 외부 제어 계약과 제거 기록을 대조한 제작 회고다. 이번 집필에서 원래 앱을 재설치하거나 실제 고객 계정을 시험하지 않았다. 어떤 구성이 언제나 더 빠르다고 약속하는 비교도 아니다. 내가 바꾼 것은 AI라는 이름보다, 내가 내린 판단을 실행 가능한 도구에 어떻게 전달할지에 대한 경계였다.