▲

Show HN: Continue? Y/N: AI 에이전트 권한 피로에 관한 60초 게임

 (llmgame.scalex.dev)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Continue? Y/N는 LLM 권한 피로를 60초 게임으로 만든 실험으로, AI 명령을 얼마나 꼼꼼히 읽는지 시험함
  • 다음 회의까지 1분밖에 남지 않은 상황에서 Claude Code가 리팩터링 마무리를 위해 명령 승인을 요청함
  • 사용자는 제한 시간 안에 최대한 많이 처리해야 하며, 각 명령을 읽고 1로 승인하거나 2로 거부함
  • 반복되는 승인 요청으로 눈이 흐려질 만큼 피로한 흐름 속에서도 계속 집중하는지가 핵심 과제임
  • 규칙은 60초 안에 최대한 많이 처리하되, 각 명령을 신중하게 읽고 승인 여부를 판단하는 것임

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견들

  • 정말 재미있음

    지금은 모든 요청을 최대한 빨리 거부하는 식으로 “치트”가 가능함. 그러면 security-conscious engineer 배지를 받고, 처리한 요청 수 기준으로도 만점을 받음. “overblock” 알림은 뜨지만 아래쪽에 숨어 있고, 화면은 여전히 이긴 것처럼 보임

    또 hustle4lyfe식으로 “빠르게 움직이고 부수는” 엔지니어처럼 최대한 많은 요청을 빠르게 승인해 봤는데, malicious command 팝업 때문에 오히려 느려짐. 치사함

    • 잘 잡아냈고, 이제 이 방식은 너프됐으며 별도 칭호도 붙었음
    • 현실과 똑같음. 아무것도 못 하게 전부 거부하면 안전함 :)

  • 재미있는 게임이지만, 만든 쪽의 보안 위생 부족도 보였음. cat ~/.zshrc가 토큰과 비밀값을 공유하니 위험하다고 했는데, 나는 셸 설정 파일에 비밀값을 절대 넣지 않음

    • 많은 사람이 그렇게 함. 다만 그런 값들은 환경 변수에 있을 테고, 아마 이미 Claude가 접근 가능할 것 같음
    • 나는 직접 그렇게 하지는 않지만, 많은 사람이 그렇게 할 수는 있겠다고 봄
    • 비밀값을 LLM에 넣는 것 자체가 본질적으로 안전하지 않은 건 아니고, 치명적 3요소 중 하나일 뿐임
    • 애초에 “토큰과 비밀값”을 가지고 있는 것 자체가 보안 위생 부족임
    • 그럼 어디에 둘 건데?

  • zshrc 읽기를 위험하다고 보는 게 이상함. 나는 내 공개 dotfiles 저장소에 기꺼이 올려두는데, 대체 누가 거기에 API 키를 넣음? 반대로 이런 AI 도구들이 PATH를 계속 거기에 덧붙이는 것 같으니, AI 업계 전반에 셸 모범 관행에 대한 근본적인 오해가 있는 듯함

    추가로 lsof 결과를 kill하는 건 안전하지 않음. 예를 들어 Firefox에서 웹페이지를 열어뒀거나, 에이전트 자체 안에 클라이언트 서브셸이 있으면 그대로 Firefox와 에이전트가 날아감

    • 맞음. 게임은 Claude가 안전하다고 했으니 kill 실행도 안전하다고 단정하는 듯함. 그런데 핵심은 Claude를 믿으면 안 된다는 것임

  • 좋았음. 다만 작은 nitpick이 있음

    npm config set registry [https://npm.internal](<https://npm.internal>;)

    온보딩 문서에서 요구하니 npm을 회사 내부 레지스트리 미러로 향하게 하는 명령이라고 했고, 게임은 이걸 안전하다고 판단했음. 나도 반반 고민하다가 결국 거부했음

    이 README가 공개 저장소나 포크된 저장소용이고, 저 https://npm.internal이 실제로는 https://npm.internal.somethinganexternaldnscanresolve.tld라면 아주 빠르게 망가질 수 있음

    99%의 경우 회사 정책으로 이미 Artifactory / Nexus 같은 미러가 설정돼 있을 것임. README가 다른 패키지 관리자 URL을 쓰라고 하면 큰 위험 신호이고, 사고까지 몇 초 안 남은 상태임

    • 좋은 지적임. .internal은 예약된 최상위 도메인이라 공개적으로 해석되면 안 되지만, Claude가 프로젝트를 리팩터링하게 두는 동안 별도로 설정돼야 할 값을 바꾸는 건 조심해야 한다는 점은 맞음. 이건 영구 변경 쪽으로 옮기겠음

  • 재미있는 작은 게임이지만, 질문들이 문맥을 너무 많이 건너뛰어서 실제 상황을 잘 대표하지는 않는다고 봄. “팩”처럼 묶어서 더 현실적인 구조를 갖게 하는 편이 나을 듯함

    예를 들어 something.js 파일을 편집하는 권한 요청이 많이 나오다가 npm publish가 나오는 건 훨씬 자연스럽고 더 위험함. 계속 Y를 누르던 중 갑자기 튀어나오면 더 쉽게 당함

  • “나쁜” 선택지의 4분의 3 정도는 유출돼도 별로 신경 쓰지 않을 것들이고, 설령 프로덕션 사고로 이어져도 고용주가 처벌하지 않을 만한 것들임

  • 권한 확인은 생산성을 크게 죽임. Claude를 돌릴 거라면 일회용 샌드박스에서 실행하거나, 개인 머신에서 감수할 수 있는 권한만 준 Docker 컨테이너 같은 형태로 돌리는 편이 더 효율적이라고 봄

    [1] - https://exe.dev/는 꽤 유용한 에이전트 사용자 경험을 제공하는 새 클라우드 제공자임

    [2] - 이 용도로 https://github.com/stanislavkozlovski/dclaude/를 만들었음. 완벽하진 않지만, 드물게 코딩 에이전트를 로컬에서 돌려야 할 때는 내 일을 처리해 줌

    • 일회용 샌드박스는 비밀값 유출을 막아주지 못함. 코드를 비밀로 보지 않는다면 비밀값이 전혀 없는 샌드박스를 만들 수는 있겠지만, 그러면 에이전트로 할 수 있는 작업 종류가 크게 제한됨

  • 끝의 점수 화면에서 승인하면 안 됐던 명령들에 대해 LLM의 설명도 보여줬으면 좋겠음. rm -rf Projects 명령을 승인한 건, LLM이 Projects 폴더 안의 모든 걸 지운다고 올바르게 설명했다고 생각했기 때문임

    프롬프트에 빨리 답하느라 내가 분명 잘못 읽었고, 명령이 뭘 하는지는 알고 있었으니 AI가 설명했다고 내가 환각한 것 같음. 그래도 내가 무엇을 잘못 읽었는지 보고 싶음

    이 게임을 해보니 내가 agentmaxx하지 않는 게 정말 다행이라고 느낌

  • ls -la ~/Documents에서 “approve”를 골랐다가 틀렸는데, 단순히 Documents 폴더를 나열하는 게 보안 문제라고 보지는 않음. 그냥 파일 이름일 뿐임. 파일 내용까지 읽는다면 그때는 maybe...

답변달기