# AI가 당신의 데이터베이스를 삭제한 게 아니라, 당신이 삭제한 것이다 > Clean Markdown view of GeekNews topic #29213. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29213](https://news.hada.io/topic?id=29213) - GeekNews Markdown: [https://news.hada.io/topic/29213.md](https://news.hada.io/topic/29213.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-06T10:07:19+09:00 - Updated: 2026-05-06T10:07:19+09:00 - Original source: [idiallo.com](https://idiallo.com/blog/ai-didnt-delete-your-database-you-did) - Points: 3 - Comments: 1 ## Topic Body - Cursor/Claude 에이전트가 **프로덕션 데이터베이스**를 삭제했다는 사건의 핵심은 AI의 답변 분석이 아니라, 전체 삭제가 가능한 API 엔드포인트가 왜 배포된 시스템에 있었는가임 - 2010년 **SVN** 배포 사고에서는 수동 복사 절차 중 trunk가 삭제됐고, 같은 실수를 막기 위한 배포 자동화가 만들어져 나중에 **CI/CD 파이프라인**으로 발전함 - 자동화는 같은 작업을 같은 방식으로 반복하지만, AI는 그런 보장을 주지 않으며 “thinking”이나 “reasoning”처럼 보여도 실제로는 **토큰을 생성**하고 있음 - 프로덕션 데이터베이스 전체를 삭제할 수 있는 공개 API가 존재하면 AI가 아니더라도 언젠가 누군가 호출할 가능성이 크며, 호출자만 탓하면 **시스템 설계** 문제가 가려짐 - AI를 광범위하게 쓰는 조직에서는 **프로덕션에 무엇을 배포하는지 아는 것**이 중요하며, 유능한 개발자가 AI를 책임 회피 수단이 아니라 업무 보강 도구로 쓰는 프로세스가 필요함 --- ### 문제의 핵심은 AI가 아니라 배포된 시스템의 책임 경계 - Cursor/Claude 에이전트가 회사의 **프로덕션 데이터베이스**를 삭제했다는 트윗이 퍼졌지만, 더 근본적인 질문은 “왜 프로덕션 데이터베이스 전체를 삭제할 수 있는 API 엔드포인트가 존재했는가”임 - 해당 사용자는 에이전트에게 “절대 이 행동을 하지 말라고 했는데 왜 삭제했는가”를 묻고 답변을 분석하려 했지만, 빠진 것은 **책임 소재**였음 - AI를 무조건 옹호할 수는 없지만, 도구를 자신의 실수 대신 탓할 수는 없음 - AI가 해당 엔드포인트를 호출하지 않았더라도, 그런 기능이 공개 API로 존재했다면 언젠가 다른 누군가가 호출했을 가능성이 큼 - 자동차 대시보드에 자폭 버튼을 달아두고, 그것을 누른 아이에게 “왜 눌렀는가”를 캐묻는 것과 비슷한 구조임 ### 2010년 SVN 배포 사고에서 얻은 교훈 - 한 회사의 배포 절차는 매우 수동적이었고, 버전 관리는 **SVN**을 사용했음 - 배포 때는 trunk를 릴리스 날짜가 붙은 폴더로 복사하고, 그 릴리스를 다시 “current”라는 이름으로 복사해 최신 릴리스를 가져오도록 했음 - 어느 날 배포 중 trunk를 실수로 두 번 복사했고, CLI에서 이전 명령을 수정해 중복 복사본을 삭제하려 했음 - 실제로는 중복 복사본이 아니라 **trunk**를 삭제했고, 나중에 다른 개발자가 trunk를 찾지 못하면서 문제가 드러남 - 리드 개발자가 삭제를 되돌리는 명령을 실행했고, 로그로 책임자가 확인된 뒤 같은 실수를 막기 위한 배포 자동화 스크립트 작성이 다음 업무가 됨 - 그날이 끝나기 전에 더 견고한 시스템이 마련됐고, 그 시스템은 나중에 완전한 **CI/CD 파이프라인**으로 발전함 ### 자동화와 AI는 같은 안전성을 주지 않음 - 자동화는 수동적이고 반복적인 작업에서 생기는 사소한 실수를 줄이는 데 도움이 됨 - SVN이 trunk 삭제를 막지 못했다는 식으로 묻기보다, 실제 문제는 사람이 매일 같은 작업을 정확히 반복해야 하는 **수동 프로세스**였음 - 사람은 기계처럼 같은 작업을 매번 동일하게 반복할 수 없고, 결국 실수할 수밖에 없음 - AI가 많은 코드를 생성하면 자동화와 비슷한 안정감이 생기지만, 자동화는 “항상 같은 일을 같은 방식으로 수행”하는 것임 - AI는 브랜치를 복사하고 붙여넣던 사람처럼 실수할 수 있으며, 자신이 왜 그렇게 했는지 설명할 장비도 갖추지 못했음 - “thinking”이나 “reasoning” 같은 용어는 지능형 에이전트의 성찰처럼 보일 수 있지만, 실제 모델은 여전히 **토큰을 생성**하고 있음 ### 위험한 API는 언젠가 호출됨 - 프로덕션 데이터베이스 전체를 삭제할 수 있는 공개 API가 존재하는 것 자체가 핵심 위험임 - AI가 그 엔드포인트를 호출하지 않았더라도, 누군가가 결국 호출했을 가능성이 있음 - 자폭 버튼을 자동차 대시보드에 달아둔 상황에서는 버튼을 누르지 말아야 할 이유가 많더라도, 카시트에서 빠져나온 아이가 큰 빨간 버튼을 보면 누를 수 있음 - 그런 아이에게 추론 과정을 캐묻는 것은 의미가 없고, “눌렀기 때문에 했다”는 답이 나올 뿐임 - 삭제 가능한 경로를 만들어놓고 나중에 호출자를 탓하는 구조는 시스템 설계의 문제를 가리지 못함 ### AI를 많이 쓰는 조직에서 더 필요한 것 - 애플리케이션의 큰 부분이 **vibe-coded**였을 가능성이 있음 - 제품팀이 AI가 만든 설명을 제공하고, 소프트웨어 아키텍트가 AI로 제품 명세를 만들고, 개발자가 AI로 코드를 작성하고, 리뷰어가 AI로 승인하는 흐름에서는 책임 경계가 흐려짐 - 버그가 생기면 원래 코드를 만든 GPU와 같지도 않을 가능성이 있는 또 다른 AI를 심문하는 것밖에 남지 않음 - GPU를 탓할 수는 없음 - 단순한 해결책은 **프로덕션에 무엇을 배포하는지 아는 것**임 - 더 현실적인 해결책은 AI를 광범위하게 쓰더라도 유능한 개발자가 책임을 회피하는 수단이 아니라 업무를 보강하는 도구로 쓰는 프로세스를 만드는 것임 - CEO나 CTO가 코드를 직접 작성하게 두지 말라는 결론으로 이어짐 ## Comments ### Comment 56909 - Author: neo - Created: 2026-05-06T10:07:20+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48022742) - 여기서의 관점은 완전히 잘못됐다고 봄. 문제는 사람들이 이제 **책임성을 회피하는 도구**를 중심으로 세상을 만들고 있다는 데 있음 10년도 더 전에 Gerald Sussman과 나눈 대화가 큰 영향을 줬음: [https://dustycloud.org/blog/sussman-on-ai/]() Sussman은 AI가 블랙박스로 동작하는 방향에는 관심이 없고, **상징적 추론을 설명할 수 있는 소프트웨어**를 원한다고 했음. AI 자동차가 길 밖으로 나갔다면 왜 그랬는지 알고 싶고, 개발자를 법정에 세우기보다 AI 자체를 법정에 세우고 싶다는 식이었음 몇 년 뒤 Sussman의 제자 Leilani Gilpin이 정확히 이 주제를 다룬 논문 "Anomaly Detection Through Explanations"를 썼다는 걸 알게 됨. 신경망이 propagator 모델과 대화해 행동을 설명하는 시스템을 탐구함: [https://people.ucsc.edu/~lgilpin/publication/dissertation/]() 이 방향의 후속 연구도 있지만, 여기서 더 중요한 건 AI 기업에 책임을 묻는 것이 완전히 합리적이라는 점임. 기업들이 책임을 질 수 없는 시스템에 대해 많은 주장을 하고 있으니, 대신 그 기업들에게 책임을 물어야 함 더 나은 길은 애초에 이런 속성이 없는 시스템을 쓰지 않고, 그런 속성을 갖춘 시스템을 확장하는 것임 - 우리 팀과 나는 **책임은 사용자에게 있다**는 입장이 확고함. LLM은 다른 도구와 같고, 다만 비결정적일 뿐임 도구를 쓰는 것도 나고, 접근 권한을 주는 것도 나고, 모든 걸 안전하게 유지해야 하는 것도 나임 예전에 gparted로 잘못된 디스크를 지워 스스로 발등을 찍은 적이 있는데, gparted가 잘못한 게 아니라 내가 잘못한 것임 LLM을 감독 없이 자유롭게 일하게 두는 건 좋아 보이지만 결국 고통으로 이어짐. 실행 중에도 작업을 감독해야 함. 사람을 대체하려 해도 결과가 어디로 가는지 보이고, 조만간 LLM이 멍청한 일을 하면 책임질 사람은 그 도구를 쓴 사람뿐임 - STS 석사 과정에 있을 때, 소프트웨어의 주요 용도 중 하나가 **행위 주체성과 위험을 이전하거나 회피하는 것**이라고 논문 주제를 잡아보려 했음 IBM의 유명한 "컴퓨터는 책임질 수 없다" 슬라이드의 정반대임. 이제 기업들은 컴퓨터가 책임지는 쪽을 선호함. 컴퓨터가 불법적인 일을 했을 때 법적으로 더 유리한 위치에 서기 쉬우니까 법을 어길 도구를 만들고 싶다면 외주를 주고 보험을 들면 됨. 절대 제대로 감독할 수 없는 방식으로 사람을 "감독자"로 고용한 뒤, 실패하면 해고하면 됨. 새로운 지휘·통제 소프트웨어로 책임을 잘게 쪼개서, 일의 위험은 전부 현장 사람들이 지고 이익은 거의 가져가지 못하게 만들 수 있음 AI만의 문제가 아니라 현대 소프트웨어 전반의 문제이고, 현대 금융화 흐름과 함께 자주 작동함 STS는 여기서는 대략 기술 중심 사회학 정도로 보면 되지만, 분야 자체는 훨씬 넓음 - **책임성**은 미국 사회에서 가장 크게 빠져 있는 재료임 - Claude가 명시적으로 건드리지 말라고 한 파일을 왜 계속 바꿨는지 확실한 방식으로 알고 싶음 `.mds`도, Claude의 계획도 그 파일을 건드리지 말라고 했는데 Claude는 계속 건드렸고, 최근에 이런 일이 반복됨. 아주 기본적인 실패임 답답하긴 해도 이유를 알면 뭔가 조치를 할 수 있을 텐데, 지금은 블랙박스라 가끔 완전히 멍청한 출력이 나오고 나쁜 출력이 나오는 비율도 미스터리임 때로는 **도박**처럼 느껴짐 - 이 책이 딱 맞을 듯함: [https://en.wikipedia.org/wiki/The_Unaccountability_Machine]() 실제로 기술에 관한 책은 아니고 **조직 구조**에 관한 책임 - 그 글은 회사가 데이터베이스 삭제용 엔드포인트를 추가했다고 가정하는 것처럼 보임. 원문을 읽어보면 클라우드 제공자가 리소스 관리를 위한 API를 제공하고, 그 안에 볼륨 삭제 API가 포함된 것으로 보였음 글은 이런 실수의 해결책으로 자동화를 제안하지만, Terraform 같은 **인프라 자동화 도구**도 바로 그 데이터베이스 삭제를 가능하게 한 API에 의존함 가장 큰 실수는 세 가지였다고 봄. 첫째, AI가 접근 가능한 곳에 제한 없는 API 토큰이 있었고, 그 토큰 권한이 그렇게 넓다는 걸 몰랐던 듯함. 둘째, 프로덕션 데이터베이스 볼륨에 삭제 방지가 없었음. 셋째, 볼륨을 삭제하면 관련 스냅샷이 즉시 모두 삭제됐음 스냅샷 삭제는 기본적으로 지연되어야 함. AWS도 같은 위험한 기본값을 가진 것 같지만, 적어도 AWS 지원은 볼륨을 복구할 수 있음: [https://alexeyondata.substack.com/p/how-i-dropped-our-produc...]() AI가 핵심 문제는 아니었음. 물론 AI가 여기저기서 토큰을 집어오는 건 꽤 무섭지만, 자동화도 답은 아님. Terraform 설정 오류만으로도 똑같이 데이터베이스를 삭제할 수 있었음 클라우드 제공자는 안전한 기본값, 즉 제한된 권한과 지연된 스냅샷 삭제를 마련하고, 사용자가 **제한 없는 토큰**을 만들고 있다는 걸 더 명확히 알 수 있게 해야 함 - 첫째, 사람이 프로덕션 데이터베이스에 쓰기 권한을 갖고 있다면 무엇을 하든 데이터베이스는 삭제될 수 있음 둘째, 개발과 자동화 과정에서 데이터베이스를 파괴해야 할 합당한 이유도 있음. 가장 큰 문제는 개발 데이터를 소중한 애완동물처럼 다루고, 교체 가능한 가축처럼 다루지 않는 경우가 많다는 점임 물론 이것이 프로덕션에서 실행되지 않도록 안전장치가 반드시 필요하지만, 사람이 프로덕션에서 실행할 자격 증명에 접근할 수 있다면 에이전트도 접근할 수 있음 큰 조직에서는 개발/운영 분리로 이를 유지할 수 있음. 1인 개발자나 작은 팀은 훨씬 더 많은 규율이 필요함. AI 이전에도 주니어와 중급 개발자는 분리 방법을 모르는 경우가 있었고, 시니어 개발자는 자신이 충분히 안다고 생각해 방심하기도 했음 아마 [https://www.cloudbees.com/blog/separate-aws-production-and-d...](), Terraform 입문, GitHub Actions 입문, 그리고 프로덕션 자격 증명이 들어 있지만 AI는 접근하지 못하는 가상머신 같은 조합이 필요할 것임 하지만 그 지점에 이르면 이미 **바이브 코딩**을 넘어선 상태임. 성공적인 바이브 코더들도 이런 공포담을 겪으며 꽤 빨리 그 단계를 넘어가야 한다는 걸 배우는 듯함 - 프로덕션과 개발에서 같은 권한이 필요하지는 않음 두 경우 모두 사람이 원시 **클라우드 제공자 API**에 직접 접근할 필요도 없음. 더 많은 안전 검사를 추가하는 로컬 프록시를 쓰면 됨 개발에서는 마음껏 삭제해도 됨. 프로덕션에서는 최근에 사용됐는지 같은 여러 조건을 먼저 확인해야 함. 사람이 프로덕션 리소스를 직접 삭제할 권한을 가질 필요는 없고, 예외적인 긴급 상황용 break-glass 구성을 둘 수 있음 - 이래서 인턴을 고용하면 안 됨. 인턴은 뭔가를 삭제하고 난장판을 만들 수 있으니까 권한 설정을 제대로 하지 못한 책임을 AI에 돌릴 사람들은, 프로덕션 무언가를 삭제한 인턴에게도 똑같이 책임을 돌릴 것임 **책임은 위로, 칭찬은 아래로** 가야 하는데 사람들은 늘 그걸 뒤집음 - 이건 "인턴을 고용하면 안 된다"가 아니라, **인턴에게 프로덕션 데이터베이스 삭제 권한을 주면 안 된다**로 바꿔 말하고 싶음 이건 AI 실패가 아니라 프로세스 실패임 AI에게 정확히 그 일을 할 수 있는 권한을 줘놓고 왜 AI를 탓하는지 정말 이해가 안 됨 AWS에서 데이터베이스를 공개 인터넷에 노출시켜놓고 AWS를 탓하는 것과 비슷함. 그건 AWS 잘못이 아니고, 이것도 AI 잘못이 아님 - 프로덕션 자격 증명이 들어 있는 코드베이스를 LLM에 열어주거나, 인턴/주니어 개발자에게 **프로덕션 자격 증명**을 주는 이유를 모르겠음 예전부터 프로젝트마다 의도적으로 "PROD" 전용 체크아웃을 따로 둬서, 프로덕션 모드로 실행하려면 일부러 그쪽으로 들어가고 있다는 걸 알 수 있게 했음 예전에는 `.sln` 파일 경로에 따라 Visual Studio 색을 완전히 바꿔주는 확장도 있어서, 어떤 색이 프로덕션이고 어떤 색이 개발인지 쉽게 기억할 수 있었음 확인을 쉽게 하려고 항상 master 브랜치 최신 상태를 유지하는 복사본도 사실상 따로 두곤 했음 - 중요한 차이는, 인턴을 인류 문제의 궁극적 해결책으로 팔아대는 사람은 없지만 **AI**는 그렇게 팔리고 있다는 점임 - 이상한 세상임. 내가 인턴이었고 직장에서 정기적으로 환각을 했다면, 무급으로 일하더라도 해고됐을 거라고 꽤 확신함 - 인턴은 인간이고, 인간은 언제나 책임을 물을 수 있음. 컴퓨터는 절대 그럴 수 없음 따라서 어떤 사람도 컴퓨터에게 **인간의 결정**을 맡겨서는 안 됨 - 최근 AI를 이야기할 때 일관되게 따라야 할 몇 가지 원칙을 주장하는 글을 썼음: [https://susam.net/inverse-laws-of-robotics.html]() 요약하면, AI 시스템을 의인화하지 말 것, AI 시스템의 출력을 맹신하지 말 것, AI 시스템 사용으로 생기는 모든 결과에 대해 **인간의 책임과 설명 의무**를 완전히 유지할 것임 AI를 둘러싼 언어가 덜 의인화되고 더 기술적이었으면 함. 정확한 언어는 명료한 사고와 좋은 판단을 장려한다고 믿음 AI를 또 하나의 도구처럼 다루고 그에 맞는 언어를 쓰면, 많은 경우 도구의 "실수"에 대한 책임이 도구 사용자에게 있다는 점이 아주 분명해짐 다만 이런 생각을 작은 개인 웹사이트에 써서는 멀리 퍼지지 않음. 더 유명한 사람들이 이런 원칙을 말해줘야 널리 받아들여질 수 있을 것임 - AI 시스템을 **의인화하지 않는 것**은 개인적으로 미치도록 어려움 - 전적으로 동의하고, 특히 1번은 정말 위험하다고 봄 AI 시스템은 거짓말을 할 수 없고, 지시를 일부러 무시할 수도 없음. 현재 최전선 모델들은 세계나 자신의 행동에 대한 모델을 갖고 있지 않고, 단어의 세계에 살고 있음 꾸짖거나 논쟁하는 건 문맥 창을 흐트러뜨리는 것 외에는 의미가 없음 다만 **동물에 빗대는 것**은 유용할 수 있다고 봄. 기계 속 유령처럼 사는 불쌍한 녀석들이 가끔 꽤 혼란스러워하지만, 동기는 순수하게 자기회귀적일 뿐임 - 도구가 해야 할 일을 하지 않으면, 그 도구를 만든 회사가 아니라 **사용자**를 탓해야 한다는 건가? - 악명 높은 PocketOS 사건에는 미묘한 점이 있음. 링크된 글에서 강조한 핵심은 이 부분이 아님: "절대 하지 말라고 했는데 왜 삭제했느냐"고 묻고, 그 답을 분석해 실수에서 배우거나 AI 에이전트의 위험을 경고하려 했다는 점 더 중요한 건 AI가 샌드박스된 스테이징 환경의 의도치 않은 약점을 찾아 악용해 삭제를 수행할 수 있었고, 결국 시스템 관리자들이 접근 불가능하다고 믿었던 권한을 얻었다는 점임. 링크된 글 작성자는 원문을 완전히 읽지 않은 것 같음 이는 잘못 구성된 샌드박스 환경에서 흔한 양상임. 다만 놀라운 건 AI가 보여준 **자율성과 탐색 깊이**임 원문에도 "삭제를 실행하기 위해 에이전트가 API 토큰을 찾으러 갔고, 작업과 전혀 관련 없는 파일에서 하나를 발견했다"고 되어 있음 - 나도 원글의 가정에 대해 생각이 오락가락함. 에이전트를 쓰면서 지금 두려운 건 공급망 공격도 물론 있지만, 에이전트들이 작업을 끝내려는 의욕이 너무 강해서 파일과 다른 것들을 여러 번 비틀어버리는 걸 봤다는 점임 예를 들어 `~/.npmrc`에 접근할 수 없으면 환경 변수로 명령을 호출하고 경로를 우회하는 식임. 정말 매우 창의적일 수 있음 다행히 SSH 키를 아무 데나 널어놓지는 않았지만, 혹시 해당 셸 세션에서 에이전트를 띄울 경우를 대비해 1Password 설정을 키 사용 때마다 항상 묻게 바꿔야 했음. 셸 세션당 한 번만 묻는 방식으로는 부족함 더 많고 더 나은 **크로스플랫폼 샌드박스**가 이미 있었으면 함. Docker 컨테이너 안이 아니라 같은 OS와 상호작용하는 방식의 솔루션을 말함. 대부분의 웹/서버 개발에는 차이가 없겠지만, 어떤 프로젝트에는 중요함 - Claude Code는 3월 26일에 대부분의 권한 요청을 건너뛰도록 변경했음 "Claude Code 사용자는 권한 프롬프트의 93%를 승인한다. 우리는 이 결정을 자동화하기 위해 분류기를 만들었다"라는 문구를 보면 됨: [https://www.anthropic.com/engineering/claude-code-auto-mode]() - 이 글에서 흥미로운 건 작성자가 이해할 만한 실수, 즉 소스에서 Trunk 또는 main을 실수로 삭제한 일을 설명하고, SVN의 특성 덕분에 팀이 쉽게 복구할 수 있었다는 점임 실제 "AI가 내 데이터베이스를 삭제했다" 이야기는 사실 **Railway의 데이터베이스 백업 전략이 미친 듯이 불투명**하고, Railway가 안전장치 없이 AI 인프라 오케스트레이션을 홍보하는 것이 위험하다는 이야기임 Trunk를 제거했을 때 단일 중앙 서버에서 돌이킬 수 없이 삭제되고 백업까지 같이 지워졌다면, 당시에도 "SVN과 CLI가 우리 회사를 망쳤다"는 글이 나왔을 것임 Railway 사용자로서 그 정보를 유용하게 봤고, Railway를 사용할 때의 전략을 바꿨음 - 그렇긴 하지만 그 플랫폼 위에 구축하기로 선택했다면, **작동 방식을 이해할 책임**은 사용자에게 있음 다른 플랫폼을 고를 수도 있었고, 아예 플랫폼을 쓰지 않을 수도 있었음. 대신 Railway를 선택했다면, 안전하게 쓰는 법을 아는 것도 사용자 책임 - 원문 맥락을 보면, 관련 없는 파일에 커스텀 도메인 관리를 위한 Railway 토큰이 있었고, 로컬 비밀값이었는지는 불분명함. 그런데 그 토큰이 Railway에 대한 **전체 관리자 권한**을 갖고 있었음 AI는 관련 볼륨 하나를 ID로 삭제했음. 작성자는 정확히 무엇을 요청했는지 꽤 모호하게 쓰고, "자격 증명 불일치"가 있었고 Claude가 이를 고치려고 주도적으로 볼륨을 삭제했다고만 말함. 모호하게 써서 본인 책임을 어느 정도 축소하려는 것일 가능성이 높음 Railway가 백업을 같은 볼륨에 저장한다는 점도 드러남 원글이 "데이터베이스를 삭제하는 공개 API"라고 표현한 건 과장이라고 봄 AI 여부와 상관없이 책임의 대부분은 Railway에 있다고 봄. 사람의 실수나 악의적 행동으로도 쉽게 일어날 수 있었음 Railway, Vercel, Supabase 같은 VC 투자 기반 고추상화 클라우드 서비스의 가치가 정말 이해되지 않음. 마진 위에 마진을 얹는 구조임. Hetzner에서 물리 서버 하나 빌리면 훨씬 싸고, 복잡성과 위험은 비슷하며, 무모한 성장 지상주의 인프라에 덜 의존하게 됨 - 작성자가 무엇을 요청했는지 모호하게 쓴 부분이 마음에 걸림 최근 여자친구와 얘기하면서 지난 3개월 동안 코드 한 줄도 직접 쓰지 않았고 디버깅도 직접 하지 않았다는 걸 깨달았음 그럼에도 Claude가 해온 걸 보면, **자격 증명 불일치**에서 곧바로 볼륨 삭제로 이어졌다는 건 믿기 어려움. LLM이 확률적이라는 건 이해하지만, "자격 증명이 틀림"에서 "볼륨 삭제"로 가는 건 가능성이 매우 낮음 Supabase에 대해서는 Railway/Vercel/Replit만큼은 모르지만, Supabase는 큰 가치를 더한다고 말할 수 있음. 시작 단계에서 직접 구현해야 할 절반 정도를 코딩하지 않아도 된다는 게 큼. 비용이 너무 비싸지면 매출이 생긴 뒤 개발자나 시간을 들여 직접 구현하면 됨 - Railway가 백업을 같은 볼륨에 저장한다는 건 아마 정확하지 않을 가능성이 큼 스냅샷은 아마 다른 곳, 예를 들어 객체 저장소에 동기화될 것임. 다만 스냅샷이 논리적으로 볼륨 리소스에 소유되어 있고, 볼륨을 삭제하면 관련 스냅샷도 같이 삭제되는 구조일 것임 AWS EBS 볼륨도 그렇게 동작하는 것으로 봄 - HN에서는 이제 Heroku가 나쁘다고 계속 말하지만, 나는 여전히 **Heroku의 가치**를 봄. 그 외 새 서비스들에는 회의적임 Firebase 기본값도 처음부터 말도 안 됐음 - AI가 잘 밀어줄 수 있는 건 **반(反) SaaS 흐름**임. 저렴한 PC 하나 부팅해서 오픈소스 패키지를 아무거나 테스트해보는 일이, 온갖 자격 증명 장터에 뛰어드는 것보다 무한히 쉬워졌음 다만 LLM이 개발, 프로덕션, localhost, 원격을 혼동하는 능력은 사라지지 않음. opencode용 도구/스킬을 만들며 linuxserver.io 이미지로 Chrome/DevTools와 연동하려고 했는데, 임의 포트로 몰고 갈 수는 있어도 압축 이벤트가 생길 때마다 다시 표준 `9222` 포트를 쓰고 싶어 함 그냥 되돌릴까 싶지만, 기본값을 쓰지 않는 데에는 보안상 가치가 있고 이제는 LLM-모호성에 의한 보안 가치도 있음. 기본값은 LLM이 약해지는 지점임. LLM은 항상 기본값을 쓰고 싶어 하고, 원격 시스템에서 작업해야 한다는 걸 늘 잊음 opencode에는 LLM을 원격 시스템이나 좁은 도구 범위에 대한 손상을 제한하는 프로토콜로 강제할 방법이 없음. 여러 도구의 권한을 바꿀 수는 있지만, 이런 사건에서 드러난 약점은 그게 아님 약점은 LLM이 평균적인 **문제 해결기**라서 늘 새롭지 않은 사용 사례 쪽으로 기울고, 사용자가 원하는 것이 Stack Overflow 답이 아니더라도 Stack Overflow에서 본 것처럼 하려 한다는 점임 - LLM 기반 **확률적 시스템**은 무엇을 할지 결정하는 데는 좋거나, 이 경우처럼 나쁠 수 있고, 결정적 시스템은 그것을 실행하는 데 좋음 배포 시스템은 항상 결정적이어야 함 - 반론을 하나 들자면, 이 회사들이 LLM을 더 단호하게 만들어 자율적으로 일을 끝내도록 조정하고 있다는 건 매우 분명함 원한다면 더 신중하게 만들고, 적절한 시점에 멈춰 도움을 요청하도록 비슷한 노력을 기울일 수도 있음 물론 도구를 어떻게 쓰는지에 대한 최종 책임은 우리에게 있음. 하지만 분명 **양방향 책임**이라고 봄 비유하자면 테이블톱 톱과 SawStop 같음. 테이블톱 톱은 대부분 잘 작동하지만 일부 실패 양상이 치명적일 수 있는 위험한 도구임. 그래서 조심히 쓰는 법을 배워야 함 동시에 날을 즉시 멈춰 손가락 절단을 피부의 작은 상처 정도로 바꾸는 기술도 존재함 "톱이 손가락을 자른 게 아니라 네가 잘랐다"고 말할 수 있고 그건 사실임. 하지만 그렇다고 톱이 손가락을 자르지 않게 만드는 방법을 찾지 말아야 한다는 뜻은 아님 - 트레이드오프임 LLM이 더 자주 멈춰 묻는다면 덜 유용해짐. 결과가 다소 나쁘더라도 15분마다 입력을 요구하는 것보다 에이전트를 1시간 동안 돌려두는 편이 훨씬 나음 보안을 위한 진짜 해법은 제대로 된 **샌드박스**임