바이브 코딩으로 나만의 오픈 클로 만들기 – SSO Server를 통한 2차 인증에서도 언급했지만, 원격 개발 기능이 붙었다고 해서 곧바로 원격에서도 로컬처럼 개발할 수 있게 된 건 아니었다. 텔레그램 챗봇으로 코드를 맡기고 테스트하고 디버깅하는 흐름까지는 만들어졌는데, 막상 이 에이전트 봇 자체를 고치려고 하면 여전히 호스트 환경에 기대는 부분이 많았다. 단순한 원격 접속이 아니라, 호스트와 거의 같은 환경에서 개발하면서도 운영 중인 봇과는 완전히 분리된 상태로 실험할 수 있는 구조가 필요했다.
그래서 선택한 방식이 가상 머신이었다. 호스트와 최대한 비슷한 개발 환경을 하나 더 만들어서, 그 안에 코덱스 에이전트와 에이전트 봇을 올리고 원격 개발용 샌드박스로 쓰는 것이다. 운영 환경은 건드리지 않고, 모든 실험은 가상 머신 안에서 끝내는 구조를 만드는 게 목표였다.
도커 VS 가상 머신
처음엔 도커가 먼저 떠올랐다. 익숙하고, 환경 분리도 깔끔하고, 빠르게 올렸다 내리기도 편하니까. 하지만 이 프로젝트는 단순히 파이썬 프로세스 하나만 띄우는 구성이 아니었다. 텔레그램 챗봇, 브라우저 로그인, 승인 흐름, 예약 실행처럼 장기적으로 살아 있어야 하는 구성요소가 서로 엮여 있었고, 컨테이너 하나로 비슷한 환경을 만드는 것과 호스트와 같은 방식으로 개발하는 것은 생각보다 꽤 다른 문제였다.
개발 환경까지 그대로 옮기려면 도커 안에 도커를 두거나, 브라우저와 세션 접근을 따로 맞추거나, 권한 문제를 계속 우회해야 했다. 반면 가상 머신은 운영체제부터 런타임, 셸 환경, 설치 도구, 브라우저 자동화 흐름까지 통째로 비슷하게 맞출 수 있었다. 완전히 똑같지는 않더라도, 호스트와 같은 감각으로 개발하고 테스트하기엔 도커보다 가상 머신이 훨씬 단순하고 직접적이었다.
이 경우엔 도커보단 가상 머신이 더 낫다
가상 머신 셋팅 그리고 테스트
에이전트에게 지금 호스트 머신의 환경과 최대한 비슷한 가상 머신을 셋팅해 달라고 요청했다. 당연히 첫 시도부터 100% 동일하진 않았다. 패키지 버전, 브라우저 동작, 세션 유지 같은 부분에서 자잘한 차이가 나왔는데, 이건 오히려 에이전트와 대화하면서 바로바로 수정해 나가는 게 빨랐다. 한 번에 완성된 환경을 만드는 게 아니라, 실제로 돌려 보면서 호스트와의 차이를 줄여 가는 방식으로 맞춰 간 셈이다.
이런 반복을 거치면서 브라우저 로그인 흐름과 가상 머신 런타임도 점점 안정화됐다. 호스트에서 하던 것처럼 코덱스 에이전트에게 작업을 맡기고, 개발 세션을 열고, 실제 서비스 흐름을 따라가며 테스트하는 루프가 가상 머신 안에서도 거의 같은 감각으로 돌아가기 시작한 것이다. 덕분에 승인 흐름, 예약 실행, 리마인더 처리처럼 서비스 전반을 건드리는 변경도 먼저 가상 머신에서 검증할 수 있는 기반이 만들어졌다.
호스트 에이전트 봇에 가상 머신의 에이전트 연결
환경만 비슷하게 만드는 걸로는 충분하지 않았다. 진짜 중요한 건 호스트의 에이전트 봇과 가상 머신의 에이전트를 어떻게 연결하느냐였다. 가장 단순한 방법은 텔레그램 챗봇을 하나 더 두는 것이었다. 개발용 챗봇을 따로 만들고, 봇을 개발 모드로 전환하면 기존 챗 흐름 일부를 가상 머신의 에이전트로 릴레이하는 구조다.
이렇게 나누니 역할이 깔끔하게 갈렸다. 일반 챗은 가상 머신의 에이전트 세션과 대화하고, 개발 챗에서는 가상 머신 안에서 돌아가는 에이전트 봇 자체를 수정하고 실험한다. 검증이 끝난 뒤에만 호스트 머신 쪽 에이전트에게 통합을 요청하면 된다. 앞서 2차 인증을 걸어 둔 메인 저장소 통합이나 서비스 재시작 같은 민감한 동작은 여전히 호스트에 남겨 두고, 실험과 반복만 가상 머신이 맡는 구조다. 보안과 운영 안정성을 크게 해치지 않으면서도 텔레그램만으로 봇 개발을 밀어붙일 수 있게 된 것이다.
이 구조의 장점은 단순히 편하다는 데서 끝나지 않는다. 민감한 기능을 붙이거나 기존 동작을 크게 바꿔야 할 때도 일단 가상 머신 안에서 먼저 흔들어 볼 수 있다. 사이드 이펙트를 미리 확인하고, 충분히 안정화한 뒤에만 호스트 쪽으로 가져오는 흐름이 자연스럽게 만들어졌다는 점이 훨씬 중요했다.
후기
텔레그램 챗봇만으로 에이전트 봇을 손보는 흐름이 한 단계 더 자연스러워졌다. 일반 챗과 개발 챗의 역할이 나뉘면서, 운영 중인 호스트 서비스를 망가뜨릴 위험이 크게 줄었다. 뭔가 깨지거나 예상 못 한 부작용이 나더라도 일단 가상 머신 안에서 끝난다는 게 생각보다 마음 편한 일이었다.
무엇보다 이 분리된 개발 환경이 생기고 나서부터 새 기능을 붙이는 흐름이 훨씬 수월해졌다. 상황 기반 연관 리마인더 규칙, 날짜 미정 리마인더 보관, 웹 리마인더 대시보드, 옵시디언 문서 갱신과 워드프레스 발행까지 — 이런 흐름들을 먼저 안전한 공간에서 검증한 뒤 운영 쪽에 반영할 수 있게 됐다. 한 번의 수정이 서비스 전체에 어떤 영향을 줄지 덜 불안해진 것이다.
물론 아직 과제는 남아 있다. 현재의 에이전트 봇 개발 모드는 기존 프로젝트 개발 세션과 완전히 분리됐다고 보기 어렵고, 기능 경계도 더 다듬어야 한다. 그래도 단순히 원격에서 개발이 된다는 수준을 넘어서, 원격에서도 로컬처럼 개발하고 안전하게 검증할 수 있다는 쪽으로 확실히 한 발 더 나아간 셈이다.