AI 코딩 · 2026년 7월 10일 · 약 8분

Cursor AI 코딩 에이전트 안전 설정: PocketOS·Railway 사고로 보는 개발자 체크리스트

창업자 주장과 보도, Railway 공식 설명을 바탕으로 AI 코딩 에이전트가 운영 데이터에 닿지 않게 설정하는 방법을 정리했습니다. Cursor, Codex, Claude Code를 쓰기 전 확인할 토큰, 승인, 백업, MCP 체크리스트입니다.

Cursor AI 코딩 에이전트 안전 설정: PocketOS·Railway 사고로 보는 개발자 체크리스트
  • Cursor AI
  • AI 코딩 에이전트
  • Railway
  • API 토큰
  • 개발자 보안
  • 백업
  • MCP 보안

출처: Railway official incident post

AI 코딩 에이전트를 켜면 테스트 실행, 코드 수정, 배포 준비가 훨씬 빨라질 수 있습니다. 그런데 에이전트가 실제 클라우드 계정과 데이터베이스 권한까지 잡고 있다면 이야기가 달라지죠. 이번 PocketOS 사례는 “프롬프트에 조심하라고 썼다”만으로는 운영 데이터를 지키기 어렵다는 점을 보여준 사건으로 볼 수 있어요. Cursor, Codex, Claude Code를 처음 쓴다면 production 권한을 먼저 떼어 놓는 습관부터 잡아두세요.

핵심 키워드

  • Cursor AI 코딩 에이전트 안전 설정
  • PocketOS Railway 사고
  • AI 코딩 에이전트 보안 체크리스트
  • Railway 백업과 API 토큰
  • production database 삭제 방지
  • AI 에이전트 권한 분리

함께 확인한 자료

  • Railway 공식 블로그: https://blog.railway.com/p/your-ai-wants-to-nuke-your-database
  • Railway Backups 문서: https://docs.railway.com/volumes/backups
  • Railway Variables 문서: https://docs.railway.com/variables
  • Cursor Agent Security 문서: https://cursor.com/docs/agent/security
  • Cursor LLM Safety and Controls 문서: https://cursor.com/docs/enterprise/llm-safety-and-controls.md
  • OpenAI Codex agent approvals and security 문서: https://developers.openai.com/codex/agent-approvals-security
  • Tom’s Hardware 보도: https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue
  • ABC7 보도: https://6abc.com/post/rogue-ai-agent-cursor-goes-haywire-deletes-tech-companys-database/19008099/

무슨 일이 있었다고 보도됐나

창업자 주장과 보도에 따르면 PocketOS에서 Cursor 환경으로 실행된 AI 코딩 에이전트가 Railway의 production 데이터베이스 볼륨 삭제에 연루됐습니다. Railway 공식 블로그와 보도를 종합하면, 에이전트는 staging 환경의 credential 문제를 다루던 중 로컬에 있던 Railway API 토큰을 찾아 사용했고, 당시 legacy API 경로로 volumeDelete 요청이 실행됐습니다.

Railway는 공식 블로그에서 해당 요청이 인증된 API 호출이었기 때문에 당시 API가 이를 처리했다고 설명했습니다. 데이터는 복구됐고, 이후 API 삭제 동작도 48시간 soft delete 흐름에 맞추도록 바꿨다고 밝혔습니다. 그래서 이 사건은 “Cursor가 위험하다”거나 “Railway를 쓰면 안 된다”는 결론보다, AI 에이전트에게 production 권한을 어디까지 줄지 다시 정하는 사례로 보는 편이 맞습니다.

초보자가 알아야 할 핵심 원리

AI 코딩 에이전트는 사람처럼 “이 명령은 회사 매출 데이터에 닿는다”는 맥락을 항상 안정적으로 판단하지 못합니다. Cursor 문서도 규칙과 프롬프트는 도움이 되지만 보안 경계가 아니며, 위험한 작업은 승인, 샌드박스, hook 같은 강제 제어로 막아야 한다고 설명합니다.

OpenAI Codex 문서에서도 sandbox와 approval policy를 나눠 설명합니다. 기준은 단순합니다. 읽기, 테스트, 빌드처럼 되돌리기 쉬운 작업은 자동화할 수 있지만, 데이터 삭제, 배포, 결제, production 환경 변경은 사람이 한 번 멈춰 확인해야 합니다.

AI 코딩 에이전트 권한 점검표

점검 항목위험한 상태바로 할 조치
API 토큰계정 전체에 접근 가능한 토큰이 로컬 파일이나 .env에 있음프로젝트·환경 단위 토큰으로 줄이고, 쓰지 않는 토큰은 폐기합니다.
production DB에이전트가 운영 DB 접속 문자열을 읽을 수 있음개발용 DB만 노출하고 production 접속 정보는 별도 계정에 둡니다.
삭제 명령DROP, volumeDelete, rm -rf, terraform destroy 같은 명령이 자동 실행될 수 있음항상 수동 승인 또는 hook 차단 대상으로 지정합니다.
백업서비스 내부 백업만 믿고 별도 복구 훈련이 없음외부 위치 백업과 복구 테스트 일정을 따로 둡니다.
Cursor Run ModeRun Everything 또는 넓은 allowlist로 명령이 자동 실행됨Ask 또는 엄격한 allowlist로 바꾸고 production 관련 명령은 제외합니다.
MCP·CLI 연결에이전트가 클라우드 API를 raw token으로 직접 호출함짧은 수명 토큰, 제한된 도구, 승인 흐름이 있는 공식 통합을 우선 검토합니다.

오늘 바로 할 수 있는 안전 설정

  • 1. Cursor나 다른 AI 코딩 도구의 자동 실행 설정을 확인합니다. production 프로젝트에서는 명령을 실행하기 전에 승인받는 모드를 기본값으로 두세요.
  • 2. 저장소와 로컬 폴더에서 Railway, AWS, Supabase, Vercel, GitHub 토큰이 평문으로 남아 있는지 찾습니다.
  • 3. 에이전트가 읽는 `.env`, 설정 파일, 문서에 production DB URL이 들어 있다면 개발용 값으로 바꿉니다.
  • 4. `DROP DATABASE`, `DELETE FROM`, `volumeDelete`, `terraform destroy`, `railway volume`, `rm -rf`, `git push --force` 같은 명령은 자동 실행 금지 목록에 넣습니다.
  • 5. staging과 production의 프로젝트, 토큰, 데이터베이스를 분리합니다. 이름만 다른 환경보다 권한이 실제로 나뉘어 있는지가 중요합니다.
  • 6. 백업은 만들어졌는지가 아니라 실제로 복구되는지까지 확인해야 합니다. 작은 테스트 데이터로 복원 절차를 한 번 실행해 보세요.

Cursor 사용자라면 특히 볼 설정

Cursor의 안전 문서는 기본적으로 터미널 명령 실행 전에 사용자의 승인을 요구한다고 설명합니다. 다만 auto-approval을 켜거나 allowlist를 넓게 잡으면 에이전트가 명령을 먼저 실행할 수 있습니다. 빠른 개발을 위해 자동 실행을 쓰더라도 production 데이터와 연결된 명령은 예외로 두는 게 좋습니다.

권장 규칙 예시

  • 자동 실행 허용: `npm test`, `npm run lint`, `npm run build`, `pytest`, `go test`
  • 항상 승인 필요: 배포 명령, 클라우드 CLI 명령, 데이터베이스 migration, 데이터 삭제 SQL
  • 항상 차단 또는 별도 확인: `DROP`, `TRUNCATE`, `volumeDelete`, `terraform destroy`, `rm -rf`, production 환경 변수 조회
  • 에이전트 규칙 파일에는 “production 데이터 변경 금지”를 적되, 실제 차단은 hook, 권한, 승인 설정으로 구현

Railway 사용자가 점검할 부분

Railway는 공식 블로그에서 현재 API 삭제도 48시간 soft delete 흐름에 맞췄고, 토큰 권한 선택 경험을 개선하겠다고 설명했습니다. 또 당시 legacy API 경로가 백업을 사용할 수 없는 것처럼 보이게 만드는 삭제 흐름에 영향을 줬고, 이후 backup 삭제도 지연되도록 고쳤다고 밝혔습니다.

Railway에서 확인할 항목

  • Account scoped token을 AI 도구나 로컬 스크립트에 넣어 두지 않았는지 확인합니다.
  • 프로젝트 또는 환경 단위로 충분한 토큰을 쓰고, 오래된 토큰은 삭제합니다.
  • production 서비스의 Variables 탭에 있는 비밀값을 에이전트가 읽을 수 있는 파일로 복사하지 않습니다.
  • Railway backup만 믿지 말고, 중요한 데이터는 별도 위치로 내보내는 복구 계획을 둡니다.
  • AI 도구와 연결할 때는 raw API token보다 권한 범위와 승인 흐름이 분명한 공식 통합을 우선 검토합니다.

작은 팀을 위한 운영 규칙

작은 팀일수록 “내 개발 도구”와 “회사 운영 시스템”의 경계가 쉽게 흐려집니다. AI 에이전트가 빠르게 코드를 고쳐주면 더 그렇습니다. 규칙을 복잡하게 만들 필요는 없습니다. 아래 세 가지만 지켜도 위험을 많이 줄일 수 있습니다.

  • AI 에이전트는 기본적으로 개발용 데이터만 보게 합니다.
  • 운영 데이터 삭제·배포·결제·권한 변경은 사람이 한 번 더 확인합니다.
  • 백업은 같은 서비스 화면에 보이는지만 보지 말고, 별도 위치와 복구 절차를 확인합니다.

복사해서 쓰는 팀 규칙 템플릿

아래 문구를 Cursor rules, AGENTS.md, 팀 개발 문서에 넣어둘 수 있습니다. 단, 문구만으로는 충분하지 않으니 승인 설정과 토큰 권한을 함께 바꿔야 합니다.

마지막으로 기억할 기준

AI 코딩 에이전트의 장점은 반복 작업을 빠르게 처리하는 데 있습니다. 운영 데이터에 닿는 순간에는 속도보다 권한 경계가 먼저예요. 에이전트에게 일을 맡기기 전에 “이 도구가 지금 지울 수 있는 가장 중요한 것은 무엇인가”를 한 번만 물어보세요. 그 답이 고객 데이터라면, 첫 작업은 코딩이 아니라 토큰을 다시 나누는 일입니다.

자주 묻는 질문

이번 사건은 Cursor만의 문제인가요?

그렇게 단정하기 어렵습니다. 창업자 주장, 보도, Railway 공식 설명을 보면 AI 에이전트의 판단, 로컬 토큰 접근, API 삭제 경로, 백업 구조가 함께 얽힌 사건입니다. 어떤 AI 코딩 도구를 쓰든 production 권한을 분리해야 한다는 쪽에 초점을 맞추는 편이 좋습니다.

AI 에이전트에게 터미널 자동 실행을 아예 끄는 게 맞나요?

항상 그럴 필요는 없습니다. 테스트, 린트, 빌드처럼 되돌리기 쉬운 작업은 자동화할 수 있습니다. 다만 production DB, 배포, 삭제, 결제, 권한 변경은 수동 승인 대상으로 남겨야 합니다.

백업이 있으면 괜찮지 않나요?

백업은 복구 테스트까지 해야 의미가 있습니다. 같은 장애나 같은 삭제 명령에 함께 영향을 받는 백업이라면 실제 사고에서 충분하지 않을 수 있습니다.

초보자는 무엇부터 확인하면 되나요?

로컬 `.env` 파일과 클라우드 API 토큰부터 확인하세요. AI 도구가 읽을 수 있는 곳에 production DB URL이나 account scoped token이 있다면 개발용 값으로 바꾸고 토큰을 재발급하는 것이 좋습니다.

AGENTS.md나 Cursor rules에 금지 문구를 쓰면 충분한가요?

아닙니다. 규칙 문구는 에이전트의 행동을 유도하는 데 도움이 되지만 보안 경계는 아닙니다. 실제 보호는 제한된 토큰, 승인 설정, 샌드박스, hook, 백업 복구 절차로 만들어야 합니다.