Conductor의 클라우드가 13일에 읽기 전용으로 전환됩니다. 코딩 에이전트를 위해 무엇을 자체 호스팅할 계획인가요?

Conductor의 클라우드가 13일에 읽기 전용(read-only)으로 전환됩니다. 여러분은 코딩 에이전트(coding agents)를 위해 무엇을 자체 호스팅(self-hosting)하고 계신가요? 만약 이 소식을 놓치셨다면, Meta가 Conductor(여러 개의 코딩 에이전트를 병렬 작업 공간에서 실행하는 앱)를 인수했습니다. HN에서 인용한 발표 내용을 바탕으로 볼 때: 11월 4일 이후로는 신규 가입이나 다운로드가 없으며, 클라우드는 11월 13일에 읽기 전용이 되고, 11월 20일에는 클라우드가 종료되며 데이터 삭제가 시작됩니다. 로컬 앱은 당분간 계속 작동하며 2027년 초에야 점진적으로 중단될 예정입니다. 모두들 20일을 언급하지만, 만약 클라우드 작업 공간에 푸시되지 않은 브랜치(unpushed branches)가 있다면 13일이 중요한 날짜입니다. 그 이후에는 내용을 확인할 수 있지만 그것으로 끝입니다. 관련성이 있기 때문에 공개합니다: 저는 로컬 AI 워크스페이스를 만드는 회사에서 일하고 있어 이 문제에 대해 중립적이지 않습니다. 이름을 언급하거나, 링크를 제공하거나, 이 스레드에서 무언가를 판매하지는 않을 것입니다. 제가 글을 올리는 이유는 HN 댓글들을 읽다가 저희 자체 환경을 점검해 보게 되었고, 다소 겸허함을 느꼈기 때문입니다. 그 스레드에서 눈에 띄었던 것은 거의 아무도 자신의 코드에 대해 걱정하고 있지 않다는 것이었습니다. 코드는 git에 있습니다. 사람들은 클라우드 웹훅(cloud webhooks), 세션 API(session API), 격리된 VM(isolated VMs)과 같은 주변 요소들에 대해 불만을 표했습니다. 한 사람은 발표 하루 전에 클라우드 플랜에 '올인'하기로 결정했고, 지금은 환불 처리를 하고 있습니다. 다른 사람은 클라우드가 모든 작업 공간에 자체 VM을 제공했기 때문에 git worktree가 필요조차 없었다고 지적했습니다. 단일 머신으로 돌아가면 다시 worktree를 관리해야 합니다. 그래서 저희도 자체 에이전트 작업 공간 중 하나를 옮겨보았습니다. 특별할 것 없이 tar로 묶어서 동일한 Mac의 깨끗한 폴더에 복원했습니다. 약 520개의 파일, 약 136 MB였고 몇 초 만에 끝났습니다. 결과는 깨끗했습니다. 한동안 기분이 좋았습니다. 그러다가 그 작업 공간 뒤에 있는 대화 기록(conversation history) 중 일부가 클라우드 엔진을 거쳤기 때문에 애초에 폴더 안에 존재하지 않았다는 것을 깨달았습니다. 그래서 파일들은 잘 옮겨졌지만, 그것들이 존재하는 이유에 대한 기록은 옮겨지지 않은 것입니다. 나중에 다시 실행해보니 더 어리석은 것이 발견되었습니다.

그 안에 있는 폴더들 중 상당수는 심볼릭 링크(symlinks)였고, 저희 스크립트는 아무 말 없이 그것들을 건너뛰었습니다. 같은 기계에 복원했을 때는 링크들이 여전히 실제 무언가를 가리키고 있어서 숨겨졌습니다. 새로운 컴퓨터에서야 알았을 겁니다. (또한 제 첫 번째 복원 작업은 비어 있는 디렉터리 대신 공유 임시 디렉터리에 들어갔는데, 이 경우 디프(diff)가 무의미해집니다. 깨끗한 폴더를 사용하세요.) 에이전트 설정의 경우, "데이터 내보내기(export your data)" 버튼이 놓칠 만한 것은 대략 다음과 같다고 생각합니다: 푸시되지 않은 브랜치(읽기 전용 상태가 되면 사라짐), 환경 변수(env vars) 및 구성 파일(설정 파일)(어쨌든 비밀 정보는 내보내기에 포함되어서는 안 됨), 웹훅(webhooks) 및 크론 작업(cron jobs). 이들은 조용히 중단되는 경향이 있어서, 심지어 얻을 수 있더라도 세션 기록(session transcripts)은 보통 엄청난 원시 로그(raw logs) 형태로 제공되며, 어떤 커밋과 연결되어 있는지 알기 어렵습니다. 아무도 문서화하지 않은 프롬프트나 규칙 같은 것들이요. 저는 Conductor의 실제 내보내기는 본 적이 없어서, 이것은 일반적인 추측일 뿐 그들의 시스템에 대한 주장은 아닙니다.

자체 호스팅(Self-hosting)은 분명히 다른 사람이 삭제 날짜를 지정하는 문제를 해결해 줍니다. 하지만 에이전트가 호스팅된 모델 API를 호출한다면 도움이 되지 않으며, 이는 이제 사용자 측 누군가가 백업 및 패치 작업을 소유한다는 것을 의미합니다.

스레드에 있는 한 사람은 임대 서버에서 오픈 소스 에이전트 도구를 실행하고 몇 달 동안 거의 건드릴 필요가 없었다고 말했습니다. 따라서 일부 사람들에게는 분명히 잘 작동하는 것 같습니다. 또 다른 사람은 공식 CLI와 tmux, 그리고 몇 개의 스크립트로 돌아갔으며, 그 후로는 종속성(lock-in)에 대해 걱정하지 않게 되었다고 말했습니다.

따라서, 자체 하드웨어에서 코딩 에이전트를 실행하는 분들을 위해 질문드립니다: 병렬 에이전트의 설정은 어떻게 되나요? 순수 CLI + 워크트리(worktrees) + tmux인가요, 아니면 더 무거운 것이 필요한가요? 실제로 전체 에이전트 설정을 다른 기계에 복원해 본 사람이 있나요? 무엇이 빠져 있었나요? 에이전트 세션 로그는 어디에 저장되나요? 저는 처음 시도했을 때 저희의 로그를 찾을 수 없었고, 이것은 좀 창피한 일입니다. /u/Local_Low4345가 제출했습니다 [link] [comments]