바이브 코딩으로 나만의 오픈 클로 만들기 – 텔레그램 봇과 코덱스 CLI로 시작한 AI 에이전트에서 텔레그램 챗봇을 통해 서버 머신의 코덱스와 대화할 수 있도록 구축했다. 이번에는 본격적인 목표인 원격 개발 기능을 붙여볼 차례다. 외출 중에도 텔레그램으로 메시지 하나 보내서 이 봇 프로젝트 자체를 수정하고 배포할 수 있으면 된다.
보안을 위해 제한해야 했던 것
가장 먼저, 텔레그램 계정이 탈취당했다는 최악의 상황을 가정해봤다. 만약 봇이 텔레그램 메시지를 받는 즉시 코드를 수정하고 서비스를 재시작할 수 있다면, 공격자는 봇의 동작을 바꿔 머신의 중요 정보를 빼내거나 권한을 탈취할 수 있다. 이건 절대 허용하면 안 된다.
그래서 원칙을 하나 세웠다. 메인 저장소를 직접 수정하거나 서비스를 즉시 재시작하는 것은 막는다. 원격 개발은 항상 격리된 샌드박스 안에서만 이뤄져야 하고, 실제 반영은 별도의 승인 단계를 거치도록 설계해야 한다. 편의성과 보안 사이의 줄다리기지만, 여기서는 보안 쪽으로 줄을 세게 당겨놓고 시작하기로 했다.
텔레그램이 뚫려도 바로 본진으로 들어가면 안 된다
슬래시 명령어 기반으로 구현한 코덱스
코덱스가 처음 구현한 건 /devstart로 시작하는 프로젝트 개발 시작 피처였다. 챗봇에 /devstart cry-agent-bot 명령어를 남기면 이를 인식하고, 프로젝트를 따로 수정할 수 있는 워크스페이스를 만든 뒤 소스를 복사해 샌드박스 공간을 만드는 식이다. 그 안에서만 제한된 파일 편집이 가능하다.
자연어로 슬래시 명령어를 호출하자
다른 건 둘째치고, 일단 슬래시 명령어로 프로젝트를 시작해야 한다는 게 피곤했다. 챗봇에 crybot 개발 시작하자라고 자연스럽게 채팅을 남기면 개발이 시작되는 게 훨씬 자유롭지 않을까? 코덱스에게 넘긴 프롬프트는 다음과 같았다.
프롬프트
내가 챗봇에 메시지를 남기면 네가 추론해서 적합한 명령어를 찾고, 찾는 데 성공했다면 그 명령어를 시작해줘. 핵심 예시는 내가 자연어를 통해 프로젝트 개발을 시작할 수 있어야 한다는 거야.
이후 여러 번의 티키타카를 거친 끝에 자연어만으로도 프로젝트를 시작할 수 있게 됐다. 말하면 다 해주는 에이전트로구나 싶었다.
자연어 한 줄이 개발 워크스페이스 시작으로 이어지면 훨씬 편하다
일단 시작은 했는데 제약이 너무 많아
코덱스에게 처음부터 보안을 강조하며 구현을 시켰더니 기반 구조가 지나치게 빡빡했다. 챗봇에서 받은 내 프롬프트를 코덱스가 1차로 해석한 뒤, 워크스페이스에서는 미리 정의된 명령어 기반으로만 처리하는 구조였다.
예를 들어 변경 사항을 깃 커밋해줘라는 프롬프트를 넣었다고 하자. 일반적인 코덱스처럼 추론을 거쳐 깃 명령어를 생성해서 처리하는 게 아니라, 챗봇에서 1차 해석한 뒤 /gitcommit 같은 고정 명령어를 워크스페이스에 대해 실행하는 식이다.
보안을 위해 너무 많은 것을 열어놓을 수는 없으니 방향성 자체는 맞다. 하지만 이렇게 강한 제약 아래서는 원격 개발을 하기에 무리가 있다. 매번 내가 요구하는 프롬프트에 대응하는 명령어 셋을 일일이 추가할 수도 없는 노릇이고. 나는 챗봇을 통해 에이전트의 추론 능력을 그대로 활용하길 원했기 때문에, 이건 내가 원한 방향이 아니었다.
얇은 릴레이 구조
내 개선 요청을 받아들인 코덱스가 설계한 핵심 아이디어는 얇은 릴레이(thin relay) 개념이었다. 개발 모드가 열리면 그 뒤로 텔레그램에 보내는 메시지를 봇이 중간에서 해석하거나 분류하지 않고, 개발 워크스페이스 안의 코덱스 스레드로 그냥 통과시킨다. 봇 스스로 AI처럼 굴지 않고, 투명한 터널 역할만 하는 것이다.
하나의 코덱스 스레드가 여러 텔레그램 메시지 사이에서 이어지도록 스레드 ID를 저장해두고, 다음 메시지가 오면 codex exec resume으로 같은 스레드를 이어받는 구조도 함께 만들었다. 이렇게 하면 봇의 보안 경계는 유지하면서도 코덱스의 추론 능력은 그대로 쓸 수 있게 된다.
봇은 똑똑한 척하지 않고, 개발 스레드로 넘기기만 한다
계속되는 보안 검증
기능 구현이 끝날 때마다 지속적으로 보안 검증을 요구했다. 그렇게 강조했는데도 기능 개발 과정에서 보안을 함께 고려하지 못하는 건지, 구현 이후 자가 보안 점검에서도 꽤 많은 이슈가 발견됐다. 심볼릭 링크를 통해 세션의 경로 제한이 뚫린다든지, ../../../ 같은 상대 경로를 통해 세션에 주어진 공간 밖을 읽거나 쓸 수 있다든지 하는 것들이다.
바이브 코딩 환경에서는 이런 보안 점검을 습관처럼 해줘야 한다는 걸 다시 한번 느꼈다. 에이전트가 기능 구현에는 빠르지만, 보안까지 스스로 챙기리라 기대하기에는 아직 이르다.
구현이 끝나도 경계 검증은 끝나지 않는다
구조를 파악하는 것도 중요하다
코덱스가 단숨에 써내려간 수천 줄의 코드를 내가 일일이 리뷰하기는 요원해 보인다. 어차피 이 프로젝트는 학습이 목적이 아니라 기능 구현 자체가 목적이기 때문에 모든 코드를 내가 다 이해할 필요는 없다. 하지만 어떤 구조로 개발됐는지는 알아야 하지 않나 싶다.
바이브 코딩을 하다 보면 구현된 기능을 테스트하면서 잘 됐다고 판단했다가, 다른 케이스에서 실패하는 경우가 종종 있었다. 들여다보면 하드코딩된 부분이 적지 않고, 내가 자연어 추론으로 처리되길 기대했던 부분이 알고 보니 기계적인 규칙 분기로 구현돼 있기도 했다.
그래서 구현이 끝난 뒤에는 어떤 구조로 만들어졌는지 코덱스에게 설명을 요구하고, 보완점을 짚어서 내가 원하는 방향으로 다시 고쳐나가도록 지시했다. 이걸 반복하다 보니 얼추 내가 원하는 방향대로 개발이 이루어지고 있다는 감이 온다. 바이브 코딩에서 구현 후 구조 리뷰는 선택이 아니라 필수다.
결론
단 이틀 만에 수천 줄을 넘어 만 줄 이상의 코드를 써내려가는 코덱스를 보자니, 이 생산성은 더 이상 인간이 따라잡을 수 없겠구나 하는 소회가 든다. 반면 만들고 싶은 것들을 마음껏 빠르게 구현할 수 있으니, 참 좋은 세상이라는 생각도 든다.
뭐가 됐든 이제는 에이전트가 없던 시절로 돌아갈 수는 없겠지. 한 땀 한 땀 코드를 써내려가던 그 시절 ㅎㅎ 마치 프로그래밍 초기, 하나하나 천공판에 구멍을 뚫던 때를 보며 “어떻게 프로그래밍을 하지?” 했던 것처럼, 언젠가는 코드 한 줄 한 줄 직접 타이핑하던 시절을 돌아보며 같은 생각을 하게 될 것 같다.
얼추 모양새가 갖춰졌고, 마침 외출할 일이 있어 밖에서 텔레그램 챗봇으로 가벼운 기능 몇 개를 추가해뒀다. 집에 돌아와 통합까지 무사히 끝냈다. 이제 다음은 리마인더 기능이다. 내 서버에서 동작하는 비서 챗봇의 첫걸음.