보안과 개인정보,
검토하시라고.

Gnista는 코딩 에이전트를 지켜보고, 노치에서 에이전트에게 응답할 수 있게 해 주는 Mac 앱이에요. 이 페이지는 회사 Mac에 올리기 전에 Gnista를 검토하는 분들을 위한 거예요. 무엇을 읽고, 무엇을 보내고, 뭔가 잘못되면 어떻게 되는지 적었어요.

2026년 10월 27일 업데이트

요약

Mac에서 돌아가요. 계정도, 텔레메트리도, 분석도 없어요.
누구의 세션, 코드, 프롬프트도 Mac 밖으로 나가지 않아요.
네트워크 요청은 아래 적은 것뿐, 그 밖엔 없어요.
스스로 무언가를 승인하는 일은 절대 없어요. 애매하면 에이전트가 직접 확인을 요청해요.
Developer ID로 서명하고, Apple의 공증을 받고, 강화된 런타임으로 빌드했어요.

Gnista가 읽는 것

에이전트 훅의 이벤트. 작은 헬퍼가 Application Support 안 Gnista 폴더의 Unix 소켓으로 보내요. 로컬 전용이고, 네트워크에서 기다리는 건 컨테이너를 켰을 때 Mac의 루프백에 여는 포트 하나뿐이며, 그 포트는 비밀번호를 요구해요. 원격 머신의 이벤트는 사용자 자신의 ssh를 거쳐, Mac에 있는 그 머신 전용 소켓으로 와요.
에이전트 자체의 세션 파일과 설정. 있는 자리에서, 제목, 진행 상황, 비용, 플랜 한도를 위해 읽어요.
자기 키체인 항목. 라이선스 키와 체험 시작 시점이 들어 있고, 체험 시작 시점은 환경설정에도 있어요. 동기화하지 않아요.
허락했을 때만: 맞는 터미널 탭이나 편집기 윈도우를 앞으로 가져오기 위한 자동화와 손쉬운 사용. 둘 다 선택 사항이에요.

절대 하지 않는 것

다른 앱의 키체인 항목이나 어떤 자격 증명도 읽지 않아요.
포트를 뒤지거나 네트워크를 스캔하지 않아요.
텔레메트리와 분석을 어떤 서비스에도 보내지 않고, 계정도 없어요. 충돌 보고서는 사용자가 동의했거나, 조직이 CrashReportsMode를 always로 정했을 때만 보내요.
에이전트 설정에서 자기 항목 말고는 바꾸지 않아요. 설정은 먼저 백업하고, 서식과 키 순서는 그대로 두고, 에이전트의 연결을 해제하면 Gnista의 줄만 정확히 지워요.

모든 네트워크 요청

호스트	요청	언제, 무엇을 보내는지
`gnista.sh`	업데이트 확인	자동 업데이트가 켜져 있으면 하루에 한 번쯤. 다른 모든 요청처럼 IP 주소, 그리고 Gnista 버전을 보내요. Mac의 프로필은 보내지 않아요.
`github.com`	다운로드: 업데이트, Linux용 헬퍼	확인에서 업데이트를 찾았을 때 그 업데이트, 그리고 원격 머신이 연결되어 있고 필요할 때 이 버전과 그 머신 프로세서에 맞는 Linux용 헬퍼. Gnista의 공개 다운로드(github.com/BlixtDunder/gnista-downloads, release-assets.githubusercontent.com에서 제공)에서 받아요. 다른 모든 요청처럼 IP 주소를 보내요. 모두 Gnista의 키로 서명된 경우에만 써요.
`report.gnista.sh`	라이선스, 충돌 보고서	라이선스: 키를 활성화할 때 키와 활성화의 이름표인 Mac 이름, 그 뒤 일주일에 한 번쯤 확인할 때, 그리고 키를 제거해 Mac의 자리를 비울 때(이 둘은 키와 이 Mac의 활성화 ID를 보내요). Gnista의 중계 서버는 그것만 판매 대행자(merchant of record)인 Creem에 넘기고, 주소별 요청 수(솔트를 넣은 해시로, 다음 날 잊어요) 말고는 라이선스에 관해 아무것도 남기지 않아요. 에이전트, 프로젝트, 사용량에 관한 건 아무것도 없어요. 충돌 보고서: Gnista나 그 헬퍼가 충돌한 뒤에만, 그리고 사용자가 동의했거나, 항상 보내기를 골랐거나, 조직이 `CrashReportsMode`를 `always`로 정했을 때만: 오류 내용, 발생 시각과 Gnista 코드에서 발생한 위치, 스레드 큐의 이름, 로드된 라이브러리의 이름과 주소, Gnista와 macOS 버전, Mac 모델과 프로세서 아키텍처, 충돌 보고서용 무작위 ID. 사용자 이름, 파일 경로, 프로젝트, 프롬프트, 코드는 없어요. 스웨덴에 있는 Gnista의 중계 서버가 Gnista 팀에 이메일로 전하고, 사본은 남기지 않아요.
`ssh`	원격 머신	설정 ▸ 원격에서 연결한 머신에 대해서만, 사용자 자신의 `ssh`와 ssh 설정으로, 파드라면 `kubectl`로: 헬퍼와 에이전트 훅 설치, 에이전트의 이벤트를 Mac으로 가져오고 응답을 돌려보내는 연결(‘연결’을 `manual`로 설정했으면 없음), 그리고 클릭했을 때 에이전트의 tmux 페인 띄우기. Gnista 팀에는 아무것도 가지 않아요.
`ampcode.com`	Amp 스레드	줄에 Amp 세션이 있을 때만: Gnista가 사용자로 로그인된 그대로 Amp 자체의 CLI(`amp threads export`, `amp threads usage`, `amp usage`)를 실행하고, 이 CLI가 Amp에서 스레드, 그 비용, 계정의 크레딧을 읽어요. Gnista는 자기 것은 아무것도 덧붙이지 않고, Gnista 팀에는 아무것도 가지 않아요.
`raw.githubusercontent.com`	모델 가격	‘사용량’을 켰을 때만, LiteLLM의 공개 모델 가격 목록을 하루에 많아야 한 번. 그냥 다운로드일 뿐, 사용자에 관한 건 아무것도 함께 가지 않아요.

자동 업데이트를 끄면(또는 MDM이 AutomaticUpdates를 false로 설정하면) 업데이트 확인이 멈춰요. 체험에는 온라인으로 가는 게 없고, 한 번 활성화하면 개인 라이선스 키는 오프라인에서도 작동해요. 팀 키는 마지막 확인 뒤 30일이 지나서 출시된 빌드를 쓰려면 가끔 확인이 필요해요. RemoteMachinesAllowed를 false로 설정하면 모든 터널이 닫히고, 누구도 서버를 연결할 수 없어요.

승인이 안전하게 실패하는 방식

‘Gnista에서 권한 요청에 응답’은 Claude Code, Codex, OpenCode처럼 노치에서 응답을 받을 수 있는 에이전트를 위한 설정이에요. 요청은 사람이 허용했을 때만 허용되고, ‘허용’은 0.5초가 지나야 누를 수 있어요. 기본으로 승인되는 건 없어요.

Gnista에서 응답이 없으면: Claude Code는 동시에 직접 확인도 요청하고, 먼저 응답한 쪽이 이겨요. 다른 에이전트는 요청을 돌려받아 평소처럼 직접 확인을 요청해요. 그 탭으로 가면 바로, 노치가 닫혀 있으면 10초 뒤, 노치 안에 있으면 길어야 45초 뒤예요.
Gnista가 실행 중이 아니면: 훅이 듣는 상대가 없다는 걸 알고 바로 돌아가요. 에이전트가 직접 확인을 요청해요.
Gnista가 잠겨 있으면(체험이 끝났고 라이선스가 없을 때): 모든 요청이 기다리지 않고 바로 돌아가요.
훅은 에이전트를 막지 않아요: 상태 훅은 30ms쯤 만에 돌아가고, 항상 깔끔하게 종료해요.
원격 머신: 그 머신의 헬퍼는 ‘Gnista에서 권한 요청에 응답’이 켜져 있을 때만 노치를 기다려요. 그 머신의 root 권한이 있는 사람은 누구나 승인 요청에 응답할 수 있고, 머신을 연결하면 설정에서도 그렇게 알려 줘요.
회사의 규칙: 팀 플랜이 있으면 MDM으로 ‘Gnista에서 권한 요청에 응답’을 끄거나 일부 에이전트로 제한할 수 있어요. MDM으로 Gnista를 보세요.

원격 머신

Gnista는 서버, 컨테이너, Kubernetes 파드에서 돌아가는 에이전트도 보여 주고, 노치에서 응답할 수 있어요. 누군가 머신을 연결하기 전까지는 꺼져 있고, RemoteMachinesAllowed를 false로 설정하면 계속 꺼져 있어요.

사용자 자신의 ssh: Gnista는 사용자가 직접 하듯이, 사용자의 ssh 설정, 키, 에이전트로 Mac의 ssh를 실행해요. 비밀번호나 키는 저장하지 않아요. 로그인에 사람이 필요하면(비밀번호, 2단계 인증) ‘로그인’이 그걸 위해 터미널을 열어요. 파드는 사용자 자신의 kubectl을 거쳐요.
서명된 헬퍼, root도 데몬도 없이: Gnista는 헬퍼를 그쪽 사용자 홈의 ~/.gnista에 복사하고, Mac에서처럼 그쪽 에이전트 설정에 자기 줄을 더해요. Linux 헬퍼는 Gnista의 키로 서명돼 있고, 서명이 맞지 않는 헬퍼는 Gnista가 거부해요. 공개 키는 gnista.sh/downloads/linux/gnista-linux.pub에 있어요. root가 필요 없고, 서비스를 설치하지 않으며, 에이전트의 훅이 부를 때만 실행돼요.
Mac마다 소켓 하나: 머신을 연결한 Mac마다 그쪽에 자기 전용 소켓이 생기고, 그 사용자만 읽을 수 있어요. Mac의 컨테이너는 Mac의 루프백 포트로 닿고, 모든 연결은 무작위 비밀번호로 시작해야 해요. 비밀번호는 그것을 마운트하는 컨테이너를 위해 ~/.gnista/containers에 있어요.
‘연결 해제’는 그쪽 에이전트 설정에서 Gnista의 줄을 빼고 ~/.gnista를 지워요. 다른 Mac이 아직 쓰고 있으면 지우지 않아요.

보안 도구가 터널을 잡아낼 때

머신마다 ‘연결’ 설정이 있고, 팀 플랜이 있으면 MDM의 RemoteConnection으로 모든 Mac에 정할 수 있어요:

자동 (automatic): Gnista 자신의 ssh 연결이 머신의 소켓을 Mac으로 포워딩해요. 서버가 소켓을 포워딩하지 않으면 그쪽 루프백에서 비밀번호를 요구하는 포트를 쓰고, 아무것도 포워딩하지 않으면 ‘포워딩 없이’처럼 동작해요.
포워딩 없이 (relay): 포워딩을 전혀 하지 않아요. Kubernetes 파드에서처럼, 헬퍼가 평범한 ssh 명령의 입출력으로 훅의 메시지를 실어 날라요.
내 ssh로 (manual): Gnista는 연결을 열지 않아요. ‘설정’이 헬퍼를 한 번 설치하고, 사용자의 ssh 설정에 넣을 RemoteForward 줄을 줘요. 그 뒤로는 사용자 자신의 ssh 세션이 에이전트의 이벤트를 실어 날라요. 서버의 sshd_config에 StreamLocalBindUnlink yes가 있으면, 끊긴 세션 다음 세션이 바로 연결돼요.

Mac에 남기는 것

Application Support 안 자기 폴더에: 최근에 끝난 세션, 가장 최근의 플랜 한도, 모델 가격 목록, 바꾼 에이전트 설정의 백업, 아직 보내지 않은 충돌 보고서(30일 뒤 삭제), 내려받은 Linux 헬퍼, 사용자가 직접 만든 에이전트, 모델, 이동 규칙 파일. 설정은 자기 환경설정 도메인 sh.gnista.Gnista에, 라이선스 키와 체험 시작 시점은 자기 키체인 항목에 있고, 체험 시작 시점은 환경설정에도 있어요. 설정에서 Gnista의 연동을 제거하면 모든 에이전트 설정에서 Gnista의 줄이 빠져요.

서명과 업데이트

Gnista는 Developer ID로 서명하고, Apple의 공증을 받고, 강화된 런타임으로 빌드했어요. 그래서 경고 없이 열리고, macOS가 변조되지 않았는지 확인해요. Gnista는 gnista.sh에서 업데이트를 찾고 Sparkle을 통해 GitHub에 있는 Gnista의 공개 다운로드에서 받아요. 업데이트는 하나하나 우리 EdDSA 키로 서명돼요. 서명이 맞지 않는 업데이트는 Gnista가 거부해요.

샌드박스 앱은 아니고, 그럴 수도 없어요. 에이전트의 파일을 읽고 설정을 고쳐야 하니까요. Mac App Store에 없는 이유도 그거예요.

문의

검토에 필요한데 여기 없는 게 있나요? support@gnista.sh로 메일 주세요. 웹사이트와 구입에 관해서는: 개인정보 처리방침.