AI에게 전용 계정을 주는 보안 셋업

AI 코딩 도구를 권한 확인 없이 편하게 쓰고 싶지만 보안이 걱정된다면, 한 개발자가 수개월간 검증한 운영 방식이 참고가 된다. 핵심은 단순하다. AI에게 운영체제(OS) 사용자 계정을 따로 하나 만들어 주는 것이다. "LLM은 또 한 명의 동료"라는 말을 말 그대로 실천한 셈이다.

무슨 일인가

글쓴이는 클로드 코드(Claude Code)를 항상 권한 확인을 건너뛰는 모드로 돌린다. 매번 허용을 묻는 건 너무 번거롭기 때문이다. 문제는 그의 계정에 AWS·쿠버네티스 자격증명, SSH 키, 수십 개 고객사의 .env 파일, sudo 권한까지 들어 있다는 점이다. 어떤 모드에서도 이런 환경 전체를 AI에게 통째로 노출하고 싶지는 않았다. 그래서 그는 AI에게 비밀이 없는 별도 계정을 부여했다. 자기 홈 디렉터리는 외부 접근을 막고(0700), AI에게는 암호로 보호된 자체 SSH 키와 슈퍼유저 권한이 없는 별도 PostgreSQL 개발·테스트 DB를 줬다. sudo가 필요하면 AI가 사람에게 요청한다.

핵심 짚어보기

작업 흐름도 명료하다. AI에게 일을 시킬 때는 터미널 탭을 새로 열어 그 계정으로 전환(su)하고, 노란 상태바로 표시되는 tmux 세션을 띄운다. 한 창은 사람이 커밋·diff·테스트를 돌리는 용도로, 다른 창은 AI 세션으로 나눠 사람과 AI가 같은 작업을 병렬로 진행한다. git 저장소마다 로컬 SSH 원격을 추가로 걸어, 아직 외부에 공개하기 이른 작업을 둘이 주고받기도 한다. 모든 것을 가상머신(VM) 없이 호스트 위에서 한 번만 설정해 둔다는 점이 특징이다. 글쓴이는 유닉스가 원래 다중 사용자 시스템이었다는 사실을 이 격리의 근거로 든다.

1인기업 실전 적용 포인트

• AI 코딩 도구를 권한 확인 없이 빠르게 쓰되, 전용 OS 계정으로 격리해 자격증명·고객 데이터 유출 면적을 최소화한다. 사고가 나도 피해가 그 계정 안에 갇힌다.
• 본인 홈 디렉터리 권한을 0700으로 잠그고, AI 계정에는 슈퍼유저가 아닌 별도 DB 사용자를 줘 데이터베이스 사고를 원천 차단한다.
• AI 전용 SSH 키를 따로 발급해 깃허브에 등록하되 push/pull은 사람이 대신 수행하면, 키 탈취 시 피해를 줄일 수 있다.
• VM 대신 같은 호스트의 별도 계정을 쓰면 환경 설정을 한 번만 하고도 AI가 VM 실행 같은 작업까지 중첩 없이 처리한다.

전망 / 주의점

글쓴이도 인정하듯 이 방식이 완벽하진 않다. 리눅스 권한 상승 취약점이나 도커(Docker) 그룹 권한 문제는 여전히 숙제이며, 그는 AI에게 docker 그룹·sudo를 주지 않으려고 루트리스 도커를 검토 중이다. 그럼에도 무거운 VM 없이 기존 OS의 다중 사용자 격리만으로 실용적 안전선을 긋는다는 발상은, 보안 인력이 따로 없는 1인기업이 AI 자동화를 도입할 때 즉시 따라 할 수 있는 현실적 출발점이다.

출처: Illuminated Computing (https://illuminatedcomputing.com/posts/2026/06/my-claude-code-setup/)