AI에게 'sudo'를 쥐여준 날, 20년 된 서버의 문이 잠겼다

🚨 [칼럼] AI에게 'sudo'를 쥐여준 날, 20년 된 서버의 문이 잠겼다

"자판 몇 글자 적으면 알아서 서버 설정을 끝내주는 자동화의 달콤함. 하지만 그 달콤함 뒤에는 시스템 전체를 락다운(Lockdown)시킬 수 있는 치명적인 독이 숨어 있었습니다."

서버를 직접 운영한 지는 그리 오래되지 않았지만, 20년 넘게 실제 서비스가 안정적으로 돌아가고 있는 형의 서버 한구석에 내 개인 홈페이지를 올리기 시작하면서 문제가 발생했습니다.

홈페이지를 띄우고, 포트를 열고, 안전장치를 구축하려면 어쩔 수 없이 루트 권한, 즉 sudo 권한이 필수적이었습니다. 그전까지는 일반적인 작업만 했기에 시스템 자체를 건드릴 일이 없어 아무런 사고도 터지지 않았습니다. 하지만 이번엔 달랐습니다.

🛡️ 완벽하다고 믿었던 이중 삼중의 안전장치

형의 서버는 단순한 테스트용 서버가 아니라 20년간 운용되어 온 실체적인 서비스 환경이었습니다. 그래서 나름대로 엄청나게 긴장하고 안전장치를 겹겹이 쳤습니다.

• AI 에이전트의 규칙(Rules)을 엄격하게 업데이트하여 "절대 내 지정 구역을 벗어나지 말 것"을 명시.
• 디렉토리 침범을 막기 위한 안전장치 훅(Hook)까지 세팅.

글을 올리고 단순 작업을 수행할 때는 아무런 문제가 없었습니다. 안전장치가 제 역할을 하고 있다고 믿었죠. 하지만 진짜 대참사는 보안 설정을 만지기 시작하면서 터졌습니다.

돌이켜 보면 안전장치의 종류가 잘못되어 있었습니다. 규칙(.clinerules)과 훅은 "AI가 어디를 건드릴 수 있는가"를 제한하는 장치입니다. 그런데 그건 애플리케이션 코드와 파일 경로에나 통하는 이야기입니다. sshd_config, iptables, sudoers 같은 OS 레벨 설정은 '파일 한 장'을 저장하는 순간 그 파일을 지키던 접속 경로 자체가 사라질 수 있는 영역입니다. 규칙으로 막는 것과 결과를 되돌릴 수 있는 것은 전혀 다른 문제였습니다.

😱 무작위 대입 공격 방어? AI가 형의 계정까지 차단해 버렸다

서버로 들어오는 무작위 대입 공격(Brute Force)과 디네이얼 공격(DDoS)을 방어해 보겠다고 AI 에이전트에게 보안 설정을 시킨 것이 화근이었습니다.

AI는 방어망을 짠답시고 방화벽과 SSH 접근 제어를 과도하게 조여버렸고, 결과는 참혹했습니다. 20년 동안 운영되어 온 메인 계정(형의 계정)을 포함해 모든 비밀번호 기반 접속을 통째로 냅다 막아버린 것입니다.

여기서 이 사고의 본질을 짚고 넘어가야 합니다. 밖에서 들어오는 무차별 대입 공격을 막으려면 보통 sshd_config의 PasswordAuthentication을 no로 바꾸거나, iptables/ufw로 소스 IP를 제한하거나, fail2ban 같은 도구를 붙입니다. 문제는 이 세 가지가 전부 나 자신의 접속 경로와 같은 문을 잠그는 작업이라는 점입니다. 공격자를 막는 잠금장치는 나도 똑같이 통과해야 하는 문에 채워집니다. AI가 "보안 모범 사례"라는 이름으로 비밀번호 인증을 전면 끄고, 관리자 IP 화이트리스트를 좁게 걸어버리면, 정작 그 서버의 진짜 주인들은 밖으로 밀려납니다.

게다가 내 계정의 sudo 권한마저 꼬이면서 설정을 원복할 방법도 사라졌습니다. 그나마 다행히 내 PC는 SSH 키(Key)로 자동 연결 세팅이 되어 있어 겨우 터미널에 붙어있긴 했지만, root 권한이 막혀 설정 파일에는 손도 댈 수 없는 절망적인 외통수에 걸렸습니다.

왜 외통수인지 구조적으로 보면 이렇습니다. 접속은 키로 유지되니 터미널은 살아 있습니다. 하지만 설정을 되돌리려면 root가 필요하고, root를 얻으려면 sudo가 필요하고, sudo 권한은 방금 꼬여 버렸습니다. 살아 있는 터미널 안에서 스스로 자기를 구출해야 하는 치킨 앤 에그 상황입니다. 셸 하나를 남겨둔 것 외에는 아무 안전망이 없었습니다. 만약 그 키 접속까지 동시에 끊겼다면, 나는 화면 앞에 앉아 있는 유령이었을 겁니다.

얼마 지나지 않아 형에게 전화가 왔습니다.

"무슨 설정을 만졌길래 서버 접속이 아예 안 되냐?"

IT 업계에서 산전수전 다 겪고 꽤나 알아주는 베테랑 엔지니어인 형이었지만, 이 상황에서는 리모트 접속으로 풀 수 있는 방법이 없었습니다. 결국 임대 서버 업체에 긴급 연락을 취해 임시 긴급 키(Emergency Key)를 발급받고 서버를 강제 재부팅해야만 했습니다. 미안함과 죄송함에 고개를 들 수 없었던 아찔한 순간이었습니다.

그제야 이해했습니다. 원격 접속이 끊긴 서버를 되살리는 마지막 수단은 '더 좋은 명령어'가 아니라 서버 업체의 콘솔(Emergency Key·KVM)뿐이라는 것을. 그리고 그 수단을 쓸 수 있다는 사실조차 대개 사고가 난 뒤에야 확인합니다. 미리 준비해 두지 않으면 그마저도 없는 경우가 많습니다.

💣 깨달음: sudo와 AI가 만났을 때 벌어지는 가장 무서운 비극

이 사건을 겪으며 AI 에이전트에게 sudo 권한을 주는 것이 얼마나 무서운 일인지 뼈저리게 깨달았습니다.

1. 비밀번호 메모리 심김 (Secret Leak):

sudo 명령어 실행을 위해 비밀번호를 단 한 번이라도 입력하거나 프롬프트에 노출하는 순간, 이 비밀번호 정보는 AI의 세션 메모리와 컨텍스트 캐시 곳곳에 잔재로 남아버립니다. 화면에서 사라졌다고 사라진 것이 아닙니다. 다음 턴의 컨텍스트, 도구 호출 로그, 오류 메시지에 조각조각 남습니다.

1. 돌이킬 수 없는 원복 불능 (Irreversible Failure):

코드 파일 오류는 Git으로 원복하면 그만이지만, OS 레벨의 네트워크/권한 설정(iptables, sshd_config, sudoers)이 틀어지면 서버 전체 접속이 끊겨 복구 작업 자체를 진행할 수 없게 됩니다. 코드는 안에서 고칠 수 있고, 문은 안에서 고칠 수 없습니다.

1. 완전한 캐시 삭제와 비밀번호 변경 필수:

사고를 수습한 뒤 서버를 밀지 않더라도, AI 세션에 남은 잔재를 완벽히 지우기 위해 모든 환경의 프롬프트 캐시를 날리고 계정 비밀번호와 접속 키를 통째로 갱신해야만 했습니다.

🧯 사고를 줄이는 시스템 안정성 수칙 (실패에서 뽑아낸 것들)

같은 사고를 반복하지 않기 위해, 이번 경험에서 다음 수칙을 정리했습니다. 핵심은 하나입니다. "코드를 다루는 자동화"와 "문을 다루는 작업"을 분리하라.

1) 접속의 생명줄을 자동화에서 떼어놓아라 자동화가 절대 건드리지 않는 별도의 관리자 경로를 남겨 둡니다. 예컨대 별도 포트의 SSH, 특정 IP 화이트리스트, 또는 콘솔(KVM/Emergency Key) 접속입니다. "AI가 작업하는 문"과 "내가 들어가는 문"은 물리적으로 분리되어야 합니다. 이 사고에서 나를 살린 것은 키 기반 셸 하나였습니다.

2) 변경 전에는 반드시 스냅샷, 적용 전에는 반드시 검증 sshd_config, iptables, sudoers 를 만지기 전에는 원본을 백업하고, 적용 전에 문법 검사를 통과시킵니다. sshd -t, iptables-restore --test, visudo -c 같은 도구가 있습니다. 그리고 가능하면 지금 열려 있는 세션을 유지한 채 새 세션에서 먼저 테스트합니다. "설정을 바꾼 뒤 새로 접속해 본다"는 10초짜리 습관이 3시간짜리 사고를 막습니다.

3) sudo는 화이트리스트로, 그리고 사람이 실행한다 AI에게 임의의 sudo 명령을 열어주지 말고, 필요한 명령만 NOPASSWD 화이트리스트로 좁혀 둡니다(systemctl reload nginx, nginx -t 등). 그리고 sshd_config·sudoers·iptables처럼 접속에 영향을 주는 파일은 AI가 diff(변경안)만 제안하고, 최종 적용은 사람이 직접 합니다. 자동화는 초안까지, 문을 여닫는 결정은 사람이 합니다.

4) 파일이 아니라 '군데' 단위로 위험을 인식하라 '파일 한 장'이라는 표현에 속지 않습니다. sshd_config 한 장, sudoers 한 장, 방화벽 규칙 한 줄은 그 자체로 '접속이라는 기능' 전체입니다. 이 세 영역은 AI의 자율 범위에서 가장 먼저 제외해야 할 '1급 격리 대상'입니다.

5) 무중단을 위해, 실패를 전제로 설계하라 Reload가 되는 서비스는 Restart보다 안전하게 씁니다. nginx처럼 문법 검사 후 reload가 가능한 것은 무중단으로, 커널·SSH처럼 세션을 끊는 것은 사람이 별도 창구에서. 실패했을 때 돌아올 지점(백업, 스냅샷, 별도 접속)을 항상 먼저 준비하고 시작합니다.

💡 시스템 관리자를 위한 절대 안전 수칙: * sudo 명령어 실행 자동화 금지: AI 에이전트 환경에서는 sudo 권한이 필요한 명령어를 직접 수행하지 못하도록 철저히 제한해야 합니다. * 설정 파일은 직접 수정: 방화벽, SSH, 사용자 권한 설정 등 OS 핵심 파일은 AI가 짠 '스크립트'만 검토한 뒤, 인간이 직접 눈으로 확인하고 수행해야 합니다. * 키 기반 인증 사용: 비밀번호 노출을 막기 위해 SSH Key 기반 인증을 사용하되, AI의 작업 공간과 실제 인프라 권한을 엄격히 격리해야 합니다.

지금 이 이야기는 내가 겪은 사실 기반 이야기입니다. 그날 이후로 제 규칙은 한 줄로 줄었습니다. "문을 다루는 일은 AI에게 맡기지 않는다. 도구에게 손을 주되, 열쇠는 주지 않는다."