외산 클라우드 코딩 에이전트를 안전하게 격리해 쓰기
왜 이 글을 쓰나
시민운동가나 시빅테크 실천가로 일하다 보면, 때로는 미국이나 중국 클라우드가 제공하는 강력한 AI를 써야만 하는 상황이 옵니다. 자국·주권 모델이 아직 성능을 따라가지 못하거나, 비용과 생존의 문제로 외국 서비스를 택할 수밖에 없기 때문입니다. 이런 선택은 불가피한 현실이지, 그 자체가 목적은 아닙니다. 진짜 목표는 그 힘을 빌려 우리만의 공공적 AI를 키우는 것입니다. 그러려면 그 과정에서 민감한 정보가 새어 나가지 않도록 격리하는 실천 기술이 필요합니다.
1부 — 관점: 국기가 아니라 목적으로 판단한다
AI 공급자를 평가하는 진짜 축은 미국 대 중국이라는 국기가 아닙니다. 핵심은 오픈 웨이트(open-weight)냐 폐쇄형 API냐입니다. 오픈 웨이트라면 언젠가 가중치를 내려받아 직접 호스팅할 수 있습니다. 곧 탈출구가 있고, 주권을 쥘 수 있다는 뜻입니다. 반면 폐쇄형 API는 접근권을 빌려 쓸 뿐이라, 집주인이 언제든 값을 올리거나 약관을 바꾸거나 서비스를 끊을 수 있습니다.
그래서 어느 공급자를 대하든 대칭적으로 바라봐야 합니다. 국가라는 조건반사가 아니라, 이 도구가 나의 목표(주권, 오픈소스 공동체, 지역의 가치)를 얼마나 섬기는지를 기준으로 삼아야 합니다.
데이터 주권의 규칙은 “어떤 AI를 쓰느냐”가 아니라 데이터의 민감도로 가릅니다. 민감하지 않은 작업(공개 코드, 일반적인 로직)은 빌려 쓴 클라우드에 맡겨도 됩니다. 그러나 민감한 데이터(회원 정보, 비밀값, 업무 데이터)는 어떤 외국 클라우드로도 — 학습용으로든 잠깐의 전송으로든 — 흘러가서는 안 됩니다. 반드시 셀프 호스팅만 허용해야 합니다. 여기에는 중요한 반전이 있습니다. 당신의 민감한 데이터를 학습해 기억해 버린 오픈 웨이트 모델은, 누구나 그 가중치를 내려받을 수 있기에 폐쇄형보다 오히려 더 위험할 수 있습니다.
큰 그림에서 이것은 데이터를 공동의 영역으로 되돌리는 운동입니다. 지역을 소중히 여기되 그 지역주의를 전 세계 모든 지역에 열어 두는 방식으로, 세계의 오픈소스 연대에 함께 서는 일입니다.
2부 — 실전: 전용 OS 유저로 코딩 에이전트 격리하기
이제 실제로 코딩 에이전트를 격리하는 방법을 봅니다. 특정 머신에 의존하지 않고 누구나 따라 할 수 있는 일반적인 방법입니다.
함정: 작업 디렉토리만으로는 막히지 않는다
많은 코딩 에이전트 CLI가 Read/Edit/Write 도구만 준다고 해서 작업 디렉토리 밖을 못 볼 것이라 믿으면 위험합니다. Read 도구는 실행 중인 OS 유저가 읽을 수 있는 모든 절대 경로를 읽습니다. 즉 “작업 디렉토리 게이트”는 문서상의 약속일 뿐, 실제 경계가 아닙니다.
확인하려면 미끼(canary) 테스트를 해 보세요. 작업 공간 밖에 가짜 비밀값이 담긴 미끼 파일을 두고, 에이전트에게 그 절대 경로를 읽어 보라고 시킵니다. 읽어 온다면 당신의 게이트는 새고 있는 것입니다. (미끼는 가짜값이니 실제 유출 없이 경계만 시험할 수 있습니다.)
견고한 해결책 — OS 수준 격리의 네 가지 요소
-
홈 디렉토리 밖의 독립 런타임. 코딩 CLI 바이너리(요즘 도구들은 자체 완결된 네이티브 바이너리로 배포됩니다)를
/opt같은 시스템 위치에 root 소유로 복사해 둡니다. 나중에 홈을 잠근 뒤에도 실행되도록 하기 위해서입니다. -
전용 비특권 OS 유저(예:
worker). 자신만의 홈·작업 공간·설정·인증정보를 가지며, 메인 계정과 아무것도 공유하지 않습니다. -
메인 홈을 기본 거부(default-deny)로 잠금. 메인 홈 디렉토리를
chmod 750으로 바꿔, worker 유저(“other”)가 안으로 들어오지조차 못하게 합니다. 당신의 민감한 프로젝트가 에이전트에게 물리적으로 읽히지 않게 하는 핵심 장치입니다. -
도구 게이트. 셸/실행과 네트워크 도구(Bash, 웹 fetch, 웹 검색)는 끄고, 파일 read/edit/write만 허용합니다. 그런 다음 권한을 worker 유저로 내려서 에이전트를 실행합니다(
sudo -u worker ...).
검증
미끼 테스트를 다시 돌립니다. 이번에는 반드시 거부(permission denied) 되어야 합니다. 동시에 평범한 코드 생성 작업은 여전히 정상 동작하는지도 확인합니다.
솔직한 경계
OS 격리는 에이전트가 당신의 비밀을 읽는 것을 막아 줄 뿐, 당신이 준 작업 지시문과 작업 공간 안의 파일은 여전히 외국 클라우드로 전송됩니다. 그러니 원칙은 변하지 않습니다. 민감하지 않고 자체 완결적인 작업만 맡기세요. 결과물의 실행과 검증은 격리된 에이전트가 아니라 신뢰할 수 있는 사람이 직접 해야 합니다.
맺음
지속 가능한 해답은 얌전한 세입자가 되는 것이 아니라 자기 집을 소유하는 것입니다. 자신의 하드웨어에 오픈 웨이트를 직접 호스팅하는 것이지요. 그 길을 걷는 동안, 외국 API는 민감하지 않은 작업에 한해 빌려 쓰는 편리한 수단으로 활용하면 됩니다.
이 글의 초안은 위에서 설명한 방식대로 격리한 외산 코딩 에이전트가 직접 작성했고, 신뢰할 수 있는 사람이 사실관계와 표현을 검토·수정했습니다. 방법을 글 자체로 시연한 셈입니다.