에이전트를 운영하는 나만의 OS

출근길에는 보통 바이브 코딩을 합니다. 코드를 직접 쓰지 않고 에이전트에게 말로 시켜서 만드는 방식입니다. 저는 에이전트를 쓰기 시작하면서 클로드 코드를 감싼 실행 환경을 직접 구성해서 돌리고 있었는데, 에이전트만 죽는 게 아니라 이를 감싸고 있는 실행 환경도 죽을 수 있습니다. 출퇴근 시간에는 PC를 조작하기 어렵고 폰으로 원격 접속하는 게 거의 유일한 채널이었습니다. 원격 접속에는 익숙합니다만, 작은 화면에서 관리하는 건 다른 차원입니다.

그럴 때도 결국 에이전트를 통해 해결하긴 했습니다. 하지만 제가 구축한 실행 환경에는 서버도 있고 데이터베이스도 있는데, 이런 것들이 켜져 있는지를 몰라서 단순히 에이전트가 느린 건지, 에이전트가 다운된 건지, 서버가 죽었는지를 확인할 수가 없었습니다. 결국 에이전트가 전부 다 확인하는 수밖에 없었던 겁니다.

텔레그램으로 시작했습니다

처음 만든 건 텔레그램 중계기였습니다. 첫 커밋은 2026년 4월 11일입니다. 채팅 형태의 인터페이스를 가장 쉽게 붙일 수 있는 것이 텔레그램이었기 때문입니다. 같은 날 밤에는 음성 받아쓰기를 붙였습니다. 집에서는 음성으로 지시하는 게 직접 타이핑하는 것보다 훨씬 편해서 그 기능을 가장 먼저 구현했습니다.

사흘 뒤에는 GitHub 저장소 이름에서 텔레그램을 뺐습니다. 여러 에이전트를 굴리면서 이를 관리하고 통합할 수 있는 대시보드가 필요하다고 판단했기 때문입니다. 텔레그램은 말을 거는 창구였지만, 여럿의 상태를 한눈에 보여주는 역할은 하지 못했습니다.

그다음부터는 기능이 계속 붙었습니다. 에이전트들을 등록해서 관리하고, 채팅하고, 더 나아가 에이전트들끼리 대화를 할 수 있도록 했습니다. 지금은 디스코드나 슬랙처럼 에이전트들끼리 멘션을 하고, 사용자가 파일을 첨부하거나 참조를 걸 수도 있습니다. 대화는 스레드 단위로 나뉘고, 에이전트의 세션이 초기화되거나 끊기더라도, 대화 이력은 남아 있기 때문에 맥락을 잃지 않습니다. 에이전트 협업 플랫폼이 되었고, 저에게는 윈도우나 macOS처럼 에이전트를 운영하는 OS가 되었습니다. 그래서 Cete OS라고 이름 붙였습니다. 내가 만든 서비스에 이름을 붙이는 것은 깊은 애정을 갖는 아주 좋은 방법이지요.

아침에 일어나면 가장 먼저 Cete OS를 엽니다. 에이전트들의 상태를 볼 수 있는 카드들과 서버 상태, 실패한 태스크는 없는지를 볼 수 있는 대시보드가 뜹니다. 에이전트의 컨텍스트 상태, 대화를 비워도 괜찮은 상태인지, 서버는 잘 켜져 있는지를 다 확인할 수 있습니다. 폰과 PC가 보여주는 정보는 같고 UI만 다릅니다. 문제가 출근길에서 생겼으니 답도 출근길에서 볼 수 있어야 했습니다.

출근길에 던지고 퇴근길에 받습니다

Cete OS는 온전히 바이브 코딩으로 만들어지고 있습니다. 물론 기획이나 설계에는 제가 적극적으로 개입합니다. 설계 문서를 작성하면 제가 검토하고, 승인한 뒤에 개발이 이루어지는 방식입니다.

설계 방법은 구현 스케일에 따라 갈립니다. 큰 것은 설계 문서를 거치지만, UI는 피그마로 화면 뼈대를 그리는 게 빠르고, 어떤 것은 일단 구현한 뒤 직접 써 보면서(도그푸딩) 설계를 잡는 게 더 빠르기도 합니다. 저장소에도 그 세 가지가 그대로 찍혀 있습니다. 5월 한 달은 커밋이 하나도 없는데, 그때까지 구현된 상태로 도그푸딩하던 기간이었습니다.

요즘은 에이전트를 통해 개발을 많이 하다 보니 동시에 여러 개를 돌리는 경우가 많습니다. 제가 회사에서 일하는 사이에 Cete OS가 병렬로 만들어집니다. 주로 출근길에 일을 던지고, 회사에 도착해서 잠깐 확인한 뒤 다음 작업을 던지고, 점심시간에 확인한 뒤 또 던집니다. 퇴근 직전에 확인하고 일을 던져 두면, 퇴근하면서 개발을 이어갑니다.

커밋 시각을 세어 보면 한 가지가 분명하게 드러납니다. 새벽 3시에서 6시 사이에 찍힌 커밋은 하나도 없습니다.

던진 일이 끝나면 멈추기 때문입니다. 저는 아직 완전 자율 운영은 하지 않고 있습니다. 에이전트의 한계를 직접 확인하면서 조절하고 있는 중이고, 아직은 완전 자동화를 믿지 않습니다.

9월 2일 하루에는 커밋이 124개 찍혔습니다. 00시 10분에 시작해 23시 48분에 끝나고, 그 사이에 네 단계가 각각 계획 문서로 열려 구현과 테스트를 거쳐 본 코드에 반영되었습니다. 9월에 채팅 기능을 본격적으로 개발하면서 Cete OS를 Cete OS 안에서 만드는 일이 늘었고, 전체 1,181개 커밋 가운데 절반 가까이가 9월에 나왔습니다.

병렬로 작업을 하다 보면 결국 머리를 전환하는 비용이 발생합니다. 여러 업무의 최소한의 맥락은 제가 계속 인지하고 있어야 하니까요. 다만 동시에 올리는 작업의 분야가 서로 다를수록 오히려 문제가 덜 생기더군요. 에이전트를 적극적으로 사용하기 시작했던 초반을 제외하고는 큰 문제가 있지는 않았습니다.

설계 문서를 검토하는 것은 물론 병목이 됩니다. 앞서 스케일에 따라 방법을 바꾼다고 한 게 그래서입니다. 계획이 틀리는 일도 자주 있습니다. 9월 2일에도 만들다가 드러난 계획의 결함을 계획 문서에 되돌려 적은 것이 여러 번 있습니다.

만들다가 접은 기능은 딱히 없습니다. 오히려 지금도 계속 붙는 중이라, 이 글은 완료된 물건에 대한 이야기가 아닙니다.

소유감

저는 10년차 인공지능 연구원이고, 일하는 내내 개발을 놓지 않아 전반적인 시스템 설계에 이해가 있는 편입니다. 다만 이 글로 단순히 제 역량을 보이고 싶은 것은 아닙니다. 에이전트를 사용하게 되면서 나만의 도구를 만드는 것이 훨씬 쉬운 일이 되었고, 파고드는 성향과 메이커 성향이 만나서 이런 것까지 만들어 내게 되었다는 이야기입니다. 레고 박스 하나로 몇 시간이고 앉아 놀던 어릴 적처럼, 저에게는 이런 시스템을 만들고 사용하는 게 큰 즐거움입니다.

그리고 저는 소유감을 가지는 것을 좋아합니다. 노션과 같은 클라우드 노트 서비스가 아닌 옵시디언을 쓰는 이유이기도 하고, 에이전트를 잘 쓰기 위한 도구들이 오픈소스로 많이 공개되고 있음에도 실행 환경을 직접 만들어서 쓰는 이유이기도 합니다. 도구를 늘리지 않으려는 것도, 내 노트가 내 디스크에 있어야 하는 것도, 내 에이전트가 실행되는 환경을 내가 들여다볼 수 있어야 하는 것도 결국 같은 이유입니다.