이제 모델이 자체 weight 파일로 부팅하고 스스로 실행할 수 있는 단계에 한 걸음 더 다가선 느낌임
정말 멋짐! 내 로컬 환경에서 cloudrouter start .로 실행해봤는데 서버 인증을 위한 비밀번호 요청이 나왔음
그래서 이슈를 열었음
원인을 찾아서 수정했음. 패키지를 업데이트하고 다시 시도해보길 바람
아이디어는 좋지만 개인적으로 모놀리식 구조는 선호하지 않음
여러 기능을 한 도구에 억지로 넣으면 수정이나 확장이 어렵고, 유연성도 떨어짐
나는 작고 느슨하게 결합된 구성요소형 도구를 선호함. 이렇게 하면 사용자가 직접 수정하거나 조합하기 쉬움
Docker 템플릿이 여러 앱을 한 컨테이너에 묶어두는 방식인데, 이는 빌드·지원·호환성 부담을 키움
각 앱을 개별 컨테이너로 두고 TCP나 소켓, 볼륨으로 연결하는 게 더 나음
또 인증 코드에 브라우저 로직이 섞여 있는 건 응집도가 낮다는 신호임
그리고 rsync 코드에서 SSH 호스트 키 검증을 끄는 부분이 보였는데, 이는 보안상 위험이 큼
사용자 오버라이드 가능한 템플릿을 제공하면 이 문제를 어느 정도 해결할 수 있을 것 같음
나는 빠른 시작과 단순함을 위해 모놀리식 구조를 택했지만, 그만큼 설정 자유도는 줄어듦
Docker 템플릿의 경우, 에이전트가 작업 디렉토리를 업로드하고 바로 개발 환경을 띄우는 게 목적임
여러 컨테이너로 나누면 마운트, 네트워킹 등 복잡성이 커짐
SSH는 실제 호스트에 직접 연결되지 않고 TLS WebSocket을 통해 터널링됨
세션별 인증 토큰과 임시 VM 키를 사용하므로 SSH 포트가 외부에 노출되지 않음
훌륭한 데모였음
우리도 dstack에서 비슷한 걸 만들고 있음
최근에는 에이전트 지원 기능을 추가했음
우리는 개발에서 학습·추론으로 이어지는 컨테이너 오케스트레이션에 초점을 맞추고 있음
그냥 AWS/Azure/GCP CLI를 에이전트에게 쓰게 하면 안 되는 이유가 있나 궁금함
좋은 질문임. 하지만 한 줄 명령으로 SSH, 파일 동기화, 브라우저, GPU까지 준비된 VM을 바로 띄우는 게 편리함
클라우드 계정 설정이나 보안 그룹, SSH 키 관리 같은 번거로움이 없음
cloudrouter는 Docker/VNC/Jupyter Lab이 미리 포함되어 있어서 환경 설정을 신경 쓸 필요가 없음
가능하긴 하지만, AI가 더 적은 토큰으로 작업을 수행할 수 있게 해주는 도구의 가치도 있음