호스팅형과 셀프 호스팅 개인 에이전트 중 하나를 고르는 일은 "쉬움"과 “프라이버시” 사이의 선택이 아닙니다. 시스템의 각 부분을 누가 운영하는지, 데이터가 어디로 이동하는지, 어떤 장애가 내 책임이 되는지를 고르는 일입니다.
이 구분은 단순한 채팅 앱보다 개인 에이전트에서 더 중요합니다. 에이전트는 진행 중인 Task를 들고 있고, 모델을 호출하고, 웹을 검색하고, 다른 서비스에 연결하고, 컴퓨터 환경에서 일하고, 나중에 결과를 들고 돌아올 수 있습니다. 애플리케이션을 내 기기로 옮기면 그런 경계의 일부가 바뀝니다. 하지만 모든 의존성이 저절로 함께 옮겨 오지는 않습니다.
Comma는 두 가지 길을 모두 제공합니다. Comma가 운영하는 호스팅 서비스와, Docker Compose로 실행할 수 있는 오픈 소스 배포입니다. 어느 형태든 같은 제품임을 알아볼 수 있지만, 운영 모델과 일부 기능은 같지 않습니다. 이 가이드는 셀프 호스팅을 훈장처럼 여기지도, 호스팅형 소프트웨어를 모두가 피해야 할 타협처럼 여기지도 않으면서 그 트레이드오프를 설명합니다.
짧은 답
에이전트를 쓰고 싶지만 그 인프라의 운영자가 되고 싶지는 않다면 호스팅형 Comma를 고르세요. Comma가 서비스를 운영하고, 호스팅 워크스페이스 데이터를 저장하고, 업데이트와 백업을 맡고, 워크스페이스용 클라우드 컴퓨터를 제공합니다. 호스팅 제품에는 Comma가 소개하는 회의 녹음 기능도 포함됩니다. 이렇게 관리되는 경험을 얻는 대신, 계정, 요금제, 데이터 처리, 가용성에 관한 서비스의 경계를 받아들이게 됩니다.
애플리케이션 스택, 데이터베이스, 모델 설정, 배포 환경을 직접 통제하는 일이 운영 부담을 감수할 만하다면 셀프 호스팅 Comma를 고르세요. 인스턴스는 내가 관리하는 기기에서 돌아가고, 애플리케이션 데이터는 내가 운영하는 데이터베이스와 오브젝트 스토리지에 저장됩니다. 업그레이드, 백업, 공개 네트워크 설정, 용량, 모니터링, 장애 복구도 내 몫입니다. 모델 호출과 선택적인 연동은 여전히 외부 제공업체로 데이터를 보낼 수 있습니다.
어느 쪽을 고르든 권한과 연결된 서비스를 이해해야 한다는 점은 변하지 않습니다. 쓸모 있는 질문은 단순히 Comma가 어디에 설치되어 있는가? 하는 것이 아닙니다. 각 구성 요소를 누가 운영하며, 이 Task가 실행될 때 정보는 어디로 가는가? 하는 것입니다.
구호가 아니라 책임을 비교하세요
공식 셀프 호스팅 가이드는 이 분담을 구체적으로 보여 줍니다.
이것은 기능 점수표가 아닙니다. 어떤 사람에게는 영구 볼륨 다섯 개와 리버스 프록시를 관리하는 일이 불필요한 부담입니다. 다른 사람에게는 애플리케이션과 그 기록을 직접 통제하는 인프라에 두는 것이 제품을 쓰는 가장 큰 이유입니다. 더 나은 선택지는 그 책임을 실제로 계속 감당할 수 있는 쪽입니다.
데이터 경로를 따라가 보세요
"셀프 호스팅"은 Comma 스택이 어디에서 돌아가는지를 말합니다. 모든 데이터가 그 기기에 머문다는 뜻은 아닙니다.
기본 셀프 호스팅 스택에서는 Task, 채팅, 파일이 내가 운영하는 서비스에 저장됩니다. Compose 배포에는 Comma 서버와 클라이언트 외에 PostgreSQL, Redis, ClickHouse, MinIO, 설정 볼륨이 포함됩니다. Comma의 가이드에 따르면 이 스택은 분석 데이터나 트레이스를 Comma로 보내지 않습니다. 쓸모 있는 경계이지만, 데이터 흐름 분석이 여기서 끝나지는 않습니다.
에이전트가 모델을 호출하면 요청은 그 인스턴스에 설정된 모델 제공업체로 갑니다. 웹 검색과 페이지 읽기를 위해 Exa 키를 추가하면 관련 요청은 Exa로 갑니다. 인스턴스를 공개하면 로그인 코드를 보내기 위해 실제 메일 서버가 필요합니다. 연결된 앱과 에이전트가 쓰는 웹사이트는 각자의 데이터 처리 방식을 가진 별개의 서비스로 남습니다. 리버스 프록시, DNS 제공업체, 호스팅 회사, 백업 저장소도 내가 설계하는 운영 경로의 일부가 될 수 있습니다.
호스팅형 Comma의 경로는 다릅니다. Comma가 애플리케이션을 운영하고 호스팅 워크스페이스 데이터를 저장하며, 모델과 연동의 경로는 호스팅 설정과 내가 고른 서비스에 따라 정해집니다. 호스팅형이면 서버 관리는 필요 없지만, 무엇을 연결할지, Task가 어떤 정보를 써야 할지 정할 필요까지 사라지지는 않습니다.
어느 배포든 프라이버시에 대해 폭넓은 결론을 내리기 전에 현실적인 워크플로 하나를 그려 보세요. Task가 외부 모델로 Drive 문서를 요약한다면 이렇게 물어보세요.
Task와 문서 참조는 어디에 저장되는가?
원본은 어떤 서비스가 가져오는가?
모델 요청에는 어떤 내용이 들어가는가?
그 요청은 어떤 제공업체가 받는가?
결과, 로그, 백업은 어디에 보관되는가?
연결을 철회하거나 저장된 상태를 삭제할 수 있는 사람은 누구인가?
이 연습은 배포 방식의 이름표보다 더 많은 것을 드러냅니다. 셀프 호스팅은 중요한 저장소와 설정을 직접 통제하게 해 주지만, 전체 경로는 내가 만든 워크플로 자체의 성질입니다.
자체 모델을 쓰는 것은 경로를 정하는 일입니다
Comma의 셀프 호스팅 설정에서는 모델 제공업체의 엔드포인트, 프로토콜, 모델 ID, API 키, 컨텍스트 예산, 출력 한도를 정할 수 있습니다. 제공업체 호출은 나의 제공업체 계정을 쓰므로, 과금과 이용 약관은 Comma 크레딧이 아니라 그 제공업체와의 관계에 속합니다.
이 유연성 덕분에 여러 구성이 가능합니다. 내 계정으로 상용 모델 API를 쓸 수도, 호환되는 비공개 엔드포인트를 가리킬 수도, 내가 운영하는 모델을 설정할 수도 있습니다. 이런 선택지를 "로컬 AI"로 뭉뚱그려서는 안 됩니다. 프롬프트를 클라우드 모델로 보내는 셀프 호스팅 Comma 인스턴스에는 여전히 외부로 나가는 모델 데이터 경로가 있습니다. 비공개 모델을 돌리면 그 경로를 바꿀 수 있지만, 설정한 엔드포인트와 주변 인프라가 실제로 의도한 경계 안에 있을 때만 그렇습니다.
자격 증명에도 같은 주의가 필요합니다. 스택을 운영한다는 것은 모델 키, 생성된 시크릿, 메일 자격 증명, 연동이 쓰는 토큰을 보호한다는 뜻입니다. 설정을 통제하는 것이 가치 있는 이유는 바로 설정이 책임을 지기 때문입니다.
셀프 호스팅은 시스템을 운영하는 일입니다
공개 저장소는 단일 노드 Docker Compose 출발점을 완전한 형태로 제공합니다. 웹 클라이언트, 관리자 클라이언트, 서버를 빌드하고, 이를 받치는 데이터 서비스를 시작합니다. 첫 실행은 로컬에서 할 수 있습니다. 포트는 기본적으로 루프백에만 바인딩되고, Mailpit이 로그인 코드를 받을 로컬 받은편지함을 제공합니다.
로컬에서 성공했다고 프로덕션 준비가 끝났다는 증명이 되지는 않습니다. 공개 배포에는 리버스 프록시 뒤의 HTTPS, 웹 앱, 관리자 앱, 제품 API마다 따로 둔 오리진, 그리고 실제 SMTP 서비스가 필요합니다. 공개 가입은 기본적으로 꺼져 있습니다. 누가 인스턴스에 접근할 수 있는지, 인증서와 DNS를 어떻게 관리할지, 시크릿을 어떻게 저장할지, 보안 업데이트를 어떻게 적용할지 정해야 합니다.
백업도 데이터베이스 하나를 복사하는 일이 아니라 시스템 전체의 성질입니다. Comma의 가이드는 스택을 멈추고 이름 있는 볼륨 다섯 개를 함께 백업하라고 안내합니다. config, postgres, objects, clickhouse, redis입니다. 설정 볼륨에는 암호화 키와 인증 시크릿이 들어 있습니다. 다른 볼륨은 남기고 이것을 잃으면, 의미 있게 복구할 수 없는 데이터만 남을 수 있습니다. 복원을 실제로 테스트해 보기 전까지 백업 계획은 완성된 것이 아닙니다.
업그레이드는 또 다른 책임입니다. 유지 보수 시간, 빌드에 충분한 디스크 공간, 서비스 장애를 감지할 방법, 그리고 용도에 맞는 롤백이나 복구 계획이 필요합니다. 에이전트가 일상 업무의 일부가 되면, 기기의 가용성, 스토리지 상태, 네트워크 설정은 호스팅 서비스라면 대신 떠안았을 제품 문제가 됩니다.
오픈 소스는 내가 살펴보고 수정할 수 있는 범위를 바꾸지만, 이런 운영 작업을 없애 주지는 않습니다. Comma의 원본 코드는 AGPL-3.0-only로 라이선스되어 있으며, 저장소에는 수정한 버전을 서비스로 제공할 때의 소스 공개 의무도 설명되어 있습니다. 의미 있는 통제권이지만, 보안 감사나 지원 계약과는 다르고, 특정 배포가 올바르게 설정되었다는 보장도 아닙니다.
두 경로의 클라우드 컴퓨터는 같은 기능이 아닙니다
호스팅 제품은 워크스페이스용 클라우드 컴퓨터를 제공합니다. 덕분에 에이전트는 사용자가 따로 환경을 마련하지 않아도, 한 번의 모델 호출을 넘어서는 파일, 도구, 브라우저 같은 실행이 필요한 일을 할 환경을 갖습니다.
2026년 10월 26일 기준으로, 공개 셀프 호스팅 스택의 그룹 클라우드 컴퓨터는 기본적으로 꺼져 있고 Cloudflare 설정이 필요합니다. 핵심 서비스가 돌아간다고 해서 저장소가 그 기능을 자동으로 쓸 수 있는 로컬 샌드박스로 만들어 주지는 않습니다. 클라우드 컴퓨터에서 하는 일이 Task의 중심이라면, 애플리케이션 서버만이 아니라 그 런타임, 설정, 비용, 격리, 유지 보수까지 결정에 포함하세요.
이 점이 실제 답을 바꿀 수 있습니다. 지속되는 Task, 연결된 모델 호출, 저장된 애플리케이션 데이터의 통제가 주로 필요한 사람은 추가 설정을 받아들일 수 있습니다. 바로 쓸 수 있는 실행용 컴퓨터가 에이전트 경험의 일부이기를 기대하는 사람은 Docker를 돌릴 수 있더라도 호스팅형 Comma를 더 좋아할 수 있습니다.
회의 녹음에는 별도의 런타임 경계가 있습니다
같은 경고가 회의에도 적용됩니다. 2026년 10월 26일 기준으로 Comma의 호스팅 경험에는 회의 녹음이 포함되지만, 공개 셀프 호스팅 저장소에 따르면 회의와 Agent VMM 호스트에는 저장소에 포함되지 않은 런타임이 필요합니다.
그러므로 핵심 애플리케이션을 셀프 호스팅해도 호스팅형의 회의 경로가 그대로 재현되지는 않습니다. 추가 인프라를 직접 만들거나 연동할 수는 있지만, 그때는 내 상황에 해당하는 권한, 녹음 관련 법률, 스토리지 설계, 전사 제공업체를 고려해야 합니다. 그것은 내가 운영하는 시스템이지, 표준 Compose 스택에 들어 있는 스위치가 아닙니다.
이것을 분명한 제품 경계로 다루세요. 통화를 녹음하고 처리하는 것이 결정적인 용도라면, 지금 호스팅형과 셀프 호스팅 Comma는 서로 대체할 수 없습니다.
고르기 전에 하는 책임 테스트
셀프 호스팅에 관해 가장 쓸모 있는 질문은 "Docker를 돌릴 수 있는가?"가 아닙니다. "첫 실행에 성공한 뒤에도 이 서비스를 계속 맡고 싶은가?"입니다.
오래 쓸 수 있는 기기나 서버가 있고, 그 상태를 보호하고 백업할 수 있으며, 내가 설정하는 외부 제공업체를 이해하고, 배포를 유지 보수할 만큼 직접적인 통제를 중요하게 여긴다면 셀프 호스팅이 잘 맞습니다. 나만의 네트워크 경계, 모델 엔드포인트, 보존 절차, 소스 수준의 맞춤화가 필요할 때 특히 의미가 있습니다.
서버보다 결과가 중요하거나, 관리되는 클라우드 컴퓨터나 회의 경로가 필요하거나, 개인 에이전트의 가용성이 내 유지 보수 습관에 좌우되기를 원하지 않는다면 호스팅형 Comma가 잘 맞습니다. 호스팅형을 고른다고 권한을 신중하게 설정하거나 연결할 대상을 제한하지 못하는 것은 아닙니다. 인프라 운영을 Comma에 맡길 뿐입니다.
결정하기 전에 다음 질문에 대한 답을 적어 보세요.
어떤 데이터를 내가 운영하는 인프라에 저장해야 하는가?
어떤 모델 제공업체가 Task 내용을 받으며, 어떤 계정으로 받는가?
나의 주요 워크플로에 클라우드 컴퓨터나 회의 녹음이 필요한가?
HTTPS, 메일 발송, 시크릿, 업데이트, 접근 제어를 관리할 수 있는가?
내 백업 세트는 무엇이며, 복원을 테스트해 보았는가?
내가 자리를 비운 사이 장애가 나면 누가 알아차리고 고치는가?
셀프 호스팅을 고르는 이유가 구체적인 경계 때문인가, 아니면 그 말이 더 안전하게 들려서인가?
답이 서로 다른 방향을 가리킨다면, 가장 중요한 워크플로를 받쳐 줄 수 있는 배포부터 시작하세요. 추상적인 기능 비교보다 범위가 정해진 Task 하나와 그 실제 데이터 경로에서 더 많은 것을 배울 수 있습니다.
호스팅형과 셀프 호스팅 개인 에이전트에 관한 질문
셀프 호스팅 Comma는 자동으로 더 프라이빗합니까?
아닙니다. 애플리케이션 스택과 데이터베이스를 내 통제 아래 두고, 표준 스택은 분석 데이터나 트레이스를 Comma로 보내지 않습니다. 그래도 모델 제공업체, 검색, 메일, 연결된 앱, 네트워크 서비스, 백업이 데이터를 받거나 저장할 수 있습니다. 프라이버시는 전체 설정과 워크플로에 달려 있습니다.
셀프 호스팅 Comma에는 Comma 계정이나 구독이 필요합니까?
공개 Docker Compose 스택에는 Comma 계정도, Stripe도, Comma 크레딧도 필요하지 않습니다. 기기는 직접 마련하고, 모델 제공업체 계정이나 비공개 모델을 설정합니다. 이런 선택에는 각자의 인프라 비용과 사용량 비용이 따를 수 있습니다.
내 모델 제공업체를 쓸 수 있습니까?
네. 셀프 호스팅 스택은 제공업체 엔드포인트, 프로토콜, 모델, 자격 증명을 설정할 수 있게 해 줍니다. 필요한 인터페이스를 지원한다면 직접 운영하는 제공업체도 쓸 수 있지만, Comma를 셀프 호스팅한다고 해서 서드파티 모델이 로컬이 되지는 않습니다.
셀프 호스팅 버전에는 클라우드 컴퓨터가 포함됩니까?
바로 쓸 수 있는 기본 기능으로는 포함되지 않습니다. Comma의 공식 가이드에 따르면 그룹 클라우드 컴퓨터에는 Cloudflare 설정이 필요합니다. 워크플로가 컴퓨터 실행에 의존한다면 그 별도의 설정과 운영 경계를 계획에 넣으세요.
셀프 호스팅 버전에는 회의 녹음이 포함됩니까?
아닙니다. 공개 저장소에 따르면 회의 런타임은 포함되지 않습니다. 따라서 이 용도에서는 호스팅 서비스와 표준 셀프 호스팅 스택이 다릅니다.
무엇을 백업해야 합니까?
스택을 멈춘 상태에서 이름 있는 볼륨 다섯 개, 즉 설정, PostgreSQL, 오브젝트, ClickHouse, Redis를 한 세트로 백업하세요. 설정 볼륨에는 암호화와 인증 시크릿이 들어 있으니 반드시 보존하세요. 업그레이드나 복원 전에는 최신 셀프 호스팅 가이드를 따르세요.
오픈 소스면 안전합니까?
아닙니다. 소스가 공개되어 있으면 검토, 수정, 독립적인 운영이 가능해집니다. 보안은 여전히 코드, 그 의존성, 내 설정, 네트워크 노출, 자격 증명, 업데이트 습관, 운영 대응에 달려 있습니다.
유지할 수 있는 경계를 고르세요
호스팅형 개인 에이전트는 서비스 운영자를 신뢰하고 평가하라고 요구합니다. 셀프 호스팅 개인 에이전트는 내가 운영자가 되라고 요구합니다. Comma가 둘 다 지원하는 이유는 통제와 편의에 대한 선호가 사람마다 다르고, 알맞은 경계가 맡기려는 일에 따라 달라지기 때문입니다.
관리되는 경험을 원한다면 호스팅형 Comma로 시작하세요. 스택을 직접 운영하고 싶다면 셀프 호스팅 가이드 전체를 읽고, 공식 저장소를 살펴보고, 중요한 Task를 올리기 전에 모델, 네트워크, 백업, 클라우드 컴퓨터, 회의의 경계를 계획하세요.
