바이브 코딩이란? 누구나 개발하는 시대라는 착시와 현실

바이브 코딩(vibe coding)은 사람이 원하는 결과를 말로 설명하고, 코드는 AI가 쓰게 하는 개발 방식입니다. 2025년 2월 안드레이 카파시(Andrej Karpathy)가 "코드가 있다는 사실조차 잊고 흐름(vibe)에 몸을 맡기는 새로운 코딩"이라고 부르면서 이름이 붙었고, 같은 해 11월 영국 콜린스 사전이 올해의 단어로 골랐습니다.

한눈에 보기

• 바이브 코딩은 만들고 싶은 것을 말로 설명하면 AI가 코드를 써 주는 개발 방식입니다.
• 타이핑은 줄였지만 판단은 못 줄였습니다. AI가 쓴 코드가 맞는지는 여전히 사람이 가립니다.
• 남에게 앱을 공개하기 전에는 권한 검사, 비밀번호 저장, 결제 처리, 백업, 비밀값 관리를 확인해야 합니다.

"이제 비전공자도 누구나 앱을 만든다"는 말이 자주 들립니다. 절반은 맞습니다. 화면 하나를 띄우는 일은 정말 쉬워졌습니다. 하지만 사람들이 돈을 내고 매일 쓰는 서비스를 만드는 일은 여전히 쉽지 않습니다. 이 글은 바이브 코딩이 무엇을 바꿨고 무엇은 바꾸지 못했는지, 공개된 조사와 사고 기록을 근거로 정리합니다.

이런 상황을 떠올려 보세요

필라테스 스튜디오 원장이 전화와 메신저로 받던 수업 예약을 앱으로 옮기려고, 주말 이틀 동안 바이브 코딩 도구에 말로 설명해 가며 예약 앱을 만들었습니다. 회원가입부터 수업 선택, 수강권 결제 화면까지 그럴듯하게 돌아갔습니다. 월요일 아침, 원장은 회원들에게 앱 주소를 보냈습니다.

그 주가 가기 전에 문제가 드러났습니다. 회원 A의 예약 내역에 회원 B의 이름과 연락처가 함께 보였습니다. 한 회원은 결제를 취소했는데 앱에는 여전히 결제 완료로 남아 있었습니다. 개발자인 지인에게 보여 주니, 회원 비밀번호가 입력한 글자 그대로 데이터베이스에 적혀 있다고 했습니다.

세 문제 모두 화면만 봐서는 알 수 없습니다. 회원 A가 B의 예약을 보는 것은 서버 쪽 권한 검사가 빠졌기 때문이고, 결제 취소가 반영되지 않는 것은 결제 상태를 처리하는 서버 쪽 코드가 없기 때문입니다. 비밀번호가 그대로 남은 것은 해시(hash, 원래 값으로 되돌릴 수 없게 바꾼 값) 처리를 하지 않았기 때문입니다. 비밀번호는 해시로 바꾼 값만 저장해야 합니다. 셋 다 뒤에서 볼 빙산 그림의 수면 아래에 있는 항목입니다. 원장은 무엇을 확인해야 하는지 몰랐을 뿐이고, 이 글은 그 목록을 다룹니다.

열 명이 하던 일을 한 사람이 하기까지

몇 년 전까지 새 서비스를 만드는 일은 팀 단위의 일이었습니다. 기획자 한 명이 요구사항을 쓰면 프런트엔드·백엔드·데이터베이스·인프라를 나눠 맡은 개발자 열 명 안팎이 붙었고, 애자일 방법론에 따라 2주 단위 스프린트를 여러 번 돌며 몇 달에 걸쳐 첫 버전을 냈습니다. 출시 뒤에는 운영과 유지보수 인력이 따로 필요했습니다.

여기서 프런트엔드(frontend)는 사용자가 보고 누르는 화면 쪽, 백엔드(backend)는 데이터를 저장하고 처리하는 서버 쪽, 인프라(infrastructure)는 서비스가 돌아가는 서버와 네트워크입니다. 애자일(agile)은 짧은 주기로 만들고 고치기를 되풀이하는 방식이고, 그 주기 한 번이 스프린트(sprint)입니다.

AI 코딩 도구가 들어오면서 필요한 인원이 빠르게 줄었습니다. 필자가 보는 현장에서는 기획 한 명에 개발자 두세 명이 예전 팀의 일을 몇 주 만에 해내는 경우가 흔해졌습니다. 여기서 한 걸음 더 나가 기획부터 개발, 배포까지 혼자 하는 1인 개발도 현실이 됐습니다.

숫자로도 보입니다. 미국 스타트업 액셀러레이터(초기 스타트업에 투자하고 몇 달 동안 집중 지원하는 기관) Y Combinator는 2025년 겨울 배치(W25)에서 스타트업 4곳 중 1곳이 코드의 95%를 AI로 만들었다고 밝혔습니다. 배치(batch)는 액셀러레이터가 한 번에 뽑아 함께 키우는 스타트업 기수로, W25는 2025년 겨울 기수입니다. 바이브 코딩 플랫폼의 성장도 빠릅니다. 스웨덴의 Lovable은 출시 8개월 만에 연환산 매출 1억 달러를 넘겼는데, 당시 정규직은 45명이었습니다. 이후 4개월 만에 2억 달러에 이르렀습니다. Replit은 1년이 안 되는 사이 연환산 매출이 280만 달러에서 1억 5천만 달러로 늘었고, AI 코드 편집기 Cursor는 연환산 매출 10억 달러를 넘겼다고 발표했습니다. 연환산 매출(ARR, annual recurring revenue)은 지금의 구독 매출이 1년 내내 이어진다고 보고 계산한 값으로, 실제 1년 매출과는 다를 수 있습니다.

개발자 쪽 조사도 같은 방향입니다. 개발자들이 묻고 답하는 사이트 Stack Overflow의 2025년 개발자 설문(응답 약 4만 9천 명)에서 84%가 AI 도구를 쓰고 있거나 쓸 계획이라고 답했고, 전문 개발자의 51%는 매일 씁니다. 구글 DORA 2025 보고서에서는 응답자의 90%가 업무에 AI를 쓴다고 했습니다.

그런데 이 숫자에서 빠진 사람

YC의 발표에는 흔히 인용되지 않는 한 문장이 붙어 있습니다. YC 매니징 파트너 재러드 프리드먼은 "우리가 비개발자 창업자들에게 투자한 것이 아니다. 이들은 모두 처음부터 직접 제품을 만들 수 있는, 기술적으로 뛰어난 사람들이다"라고 말했습니다. 같은 자리에서 다이애나 후 파트너는 AI가 코드를 쓰더라도 개발자에게는 좋은 코드와 나쁜 코드를 가려내는 안목과 지식이 여전히 필요하다고 덧붙였습니다.

즉 "코드의 95%를 AI가 썼다"는 말은 "비전공자가 혼자 만들었다"는 뜻이 아닙니다. 무엇을 만들어야 하는지, AI가 쓴 코드가 맞는지 판단할 수 있는 사람이 키보드 앞에 앉아 있었다는 뜻입니다. 바이브 코딩이 줄여 준 것은 타이핑이지 판단이 아닙니다.

빙산의 일각인 화면

바이브 코딩으로 가장 빨리 나오는 것은 사용자 화면입니다. 버튼을 누르면 무언가 반응하고, 데모 영상으로 보여 주기에는 충분합니다. 문제는 그 화면을 실제 서비스로 운영하려는 순간부터 시작됩니다.

사용자가 회원가입을 하면 비밀번호는 어디에 어떻게 저장해야 할까요. 한 사용자가 남의 데이터를 볼 수 없게 하는 권한 검사는 화면이 아니라 서버에서 해야 합니다. 결제가 중간에 끊기면 주문 상태를 어떻게 되돌릴지, 데이터베이스 구조를 바꿀 때 기존 데이터는 어떻게 옮길지, 매일 백업은 어디에 남길지도 정해야 합니다.

출시한 뒤에는 운영이 기다립니다. 고객 문의에 답하고 회원을 관리할 관리자 페이지, 오류가 났을 때 무슨 일이 있었는지 추적할 로그, 서버가 멈추면 알려 줄 모니터링과 알림이 필요합니다. API 키 같은 비밀값을 코드에 넣지 않고 관리하는 법, 개인정보를 법에 맞게 다루는 법, 도메인과 인증서, 클라우드 비용 관리까지 알아야 합니다. API는 프로그램끼리 정해진 방식으로 데이터를 주고받는 창구이고, API 키는 그 창구를 쓸 때 내미는 열쇠 문자열입니다.

이 가운데 어느 것도 화면에는 드러나지 않습니다. 그래서 바이브 코딩으로 만든 데모는 완성품처럼 보이지만, 실제로는 빙산의 수면 위만 만들어진 상태인 경우가 많습니다. AI에게 "로그인 기능 만들어 줘"라고 하면 로그인 화면은 나옵니다. 그 로그인이 안전한지는 이 목록을 아는 사람만 확인할 수 있습니다.

아파트 모델하우스를 떠올려 보면 쉽습니다. 모델하우스는 실제 집처럼 꾸며 두었지만 사람이 살 수는 없습니다. 입주하려면 벽 뒤의 배관과 전기 배선이 제대로 이어졌는지, 소방 설비가 점검을 통과했는지 확인해야 합니다. 바이브 코딩으로 만든 화면은 모델하우스에 가깝고, 빙산 아래 항목은 입주 전에 받아야 하는 배관·전기·소방 점검에 해당합니다. 필라테스 예약 앱에서 드러난 세 문제도 모두 이 점검 목록에 들어 있습니다.

실제로 벌어진 일들

바이브 코딩이 퍼진 지난 1~2년 사이 공개된 사고와 조사 결과를 보면 문제가 어디서 생기는지 분명하게 보입니다.

표의 용어를 풀어 보겠습니다. RLS(Row Level Security, 행 단위 보안)는 데이터베이스 표의 줄마다 누가 읽고 쓸 수 있는지 정해 두는 기능입니다. "회원은 자기 예약만 본다"는 규칙을 데이터베이스에 걸어 두는 일입니다. CVE(Common Vulnerabilities and Exposures)는 공개된 보안 취약점마다 붙이는 국제 일련번호입니다. 인증 로직(authentication logic)은 로그인한 사람이 본인이 맞는지 확인하는 코드로, 이것이 브라우저에 있으면 사용자가 그 확인을 건너뛸 수 있습니다.

AI가 쓴 코드 자체의 보안 수준도 조사됐습니다. 보안 기업 Veracode가 100종이 넘는 언어 모델에 실제 개발 과제를 풀게 한 결과, 만들어진 코드의 45%가 보안 검사를 통과하지 못하고 OWASP Top 10 취약점을 담고 있었습니다. OWASP Top 10은 웹 보안 비영리 단체 OWASP가 꼽은 가장 흔하고 위험한 웹 취약점 열 가지입니다. Java는 실패율이 72%였고, 웹에서 흔한 크로스사이트 스크립팅(XSS)은 86%의 경우 막지 못했습니다. XSS는 웹페이지에 악성 스크립트를 끼워 넣어 방문자의 브라우저에서 실행되게 하는 공격입니다. 더 새롭고 큰 모델이라고 보안이 나아지지도 않았습니다. 미국 조지타운대 CSET도 2024년 보고서에서 다섯 개 모델이 만든 코드 조각의 절반 가까이에 악용될 수 있는 버그가 있었다고 밝혔습니다.

코드가 잘 돌아가는 것과 안전한 것은 다른 문제입니다. 그리고 그 차이는 무엇을 확인해야 하는지 아는 사람만 찾아낼 수 있습니다.

쓰면서도 믿지 않는 개발자들

현업 개발자들은 이 차이를 이미 체감하고 있습니다. 앞의 Stack Overflow 설문에서 AI 답의 정확도를 믿는다는 응답은 32.7%였고, 믿지 않는다는 응답이 45.7%로 더 많았습니다. 가장 큰 불만(66%)은 "거의 맞지만 조금 틀린 답"이었고, 두 번째 불만은 AI가 만든 코드를 디버깅(debugging, 프로그램의 오류를 찾아 고치는 일)하는 데 시간이 더 든다는 것이었습니다. 바이브 코딩이 자기 업무 방식이 아니라고 답한 개발자도 77%를 넘었습니다.

"거의 맞는 답"이 위험한 이유는 틀린 곳을 알아보는 데 전문성이 필요하기 때문입니다. 완전히 틀린 코드는 실행해 보면 바로 드러납니다. 거의 맞는 코드는 잘 돌아가다가 특정 조건에서만 문제를 일으키고, 그 조건이 무엇인지는 경험이 있어야 짐작할 수 있습니다.

품목과 단가는 모두 맞는데 합계 한 줄만 틀린 견적서와 같습니다. 훑어보면 멀쩡하고, 틀린 곳은 계산을 한 줄씩 따라가 본 사람만 찾습니다. 그 견적서가 그대로 고객에게 나가면 손해는 보낸 쪽이 떠안습니다.

체감 속도와 실제 속도의 차이

AI를 쓰면 빨라진다는 느낌도 한 번쯤 의심해 볼 만합니다. 비영리 연구기관 METR는 2025년 7월, 숙련된 오픈소스 개발자 16명이 자기가 관리하는 대형 저장소에서 실제 이슈 246건을 처리하는 과정을 무작위 대조 실험으로 측정했습니다. 무작위 대조 실험(randomized controlled trial)은 과제를 무작위로 나눠 AI를 쓴 쪽과 쓰지 않은 쪽을 비교하는 방식입니다. 개발자들은 시작 전에 AI 덕분에 24% 빨라질 것이라고 예상했고, 끝난 뒤에도 20% 빨라졌다고 느꼈습니다. 실제 측정값은 19% 느려진 것이었습니다.

이 실험은 이미 잘 아는 큰 코드베이스(codebase, 한 서비스를 이루는 소스 코드 전체)에서, 2025년 초의 도구로 진행됐다는 한계가 있습니다. METR도 결과를 특정 시점, 특정 환경의 스냅숏으로 봐 달라고 했습니다. 그래도 한 가지는 분명합니다. 숙련자조차 AI가 얼마나 도움이 되는지 스스로 정확히 가늠하지 못합니다. 비전공자라면 이 착시는 더 커질 수 있습니다. 화면이 빨리 나오니 거의 다 됐다고 느끼지만, 실제로는 빙산 아래를 아직 시작도 하지 않은 경우가 많습니다.

구글 DORA 2025 보고서는 이 현상을 한 문장으로 정리했습니다. "AI는 팀을 고쳐 주지 않는다. 이미 있는 것을 키울 뿐이다." 튼튼한 팀은 AI로 더 잘하게 되고, 약한 팀은 AI 때문에 약점이 더 드러난다는 뜻입니다. 같은 보고서는 AI 사용이 늘수록 처리량(같은 기간에 내보내는 변경의 양)은 늘지만 배포 안정성은 여전히 떨어지는 관계를 보고했습니다.

바이브 코딩이 가장 큰 효과를 내는 사람

그렇다면 바이브 코딩의 효과를 가장 크게 누리는 사람은 누구일까요. 필자는 20년 넘게 개발과 아키텍처 일을 해 오며 요즘 거의 모든 코드를 AI와 함께 씁니다. 체감으로는 혼자서 예전 팀 하나의 몫을 해내는 날도 있습니다. 하지만 그 속도는 AI에서만 나오지 않습니다. 무엇을 만들지, 어떤 구조로 나눌지, AI가 쓴 코드의 어디를 의심해야 하는지 아는 데서 나옵니다.

아래 표의 세션(session)은 로그인한 사람을 서버가 기억해 두는 기록입니다.

카파시가 처음 바이브 코딩을 설명할 때 든 방식, 즉 변경 내용을 읽지 않고 받아들이고 오류 메시지를 그대로 붙여 넣는 방식은 가벼운 실험을 위한 것이었습니다. 그는 스스로 이 방식이 "버려도 되는 주말 프로젝트라면 나쁘지 않다"고 했습니다. 사용자의 돈과 개인정보가 오가는 서비스는 주말 프로젝트가 아닙니다.

혼자 해도 되는 것과 전문가가 봐야 하는 것

모든 일에 전문가가 필요하지는 않습니다. 기준은 틀려도 나 혼자 불편하고 끝나는 일인지, 남의 돈과 개인정보가 걸린 일인지입니다.

왼쪽 칸의 일도 고객 명단을 넣거나 실제 고객에게 열어 주는 순간 오른쪽으로 옮겨 갑니다. 필라테스 예약 앱도 회원들에게 주소를 보낸 날 오른쪽 칸이 됐습니다.

출시 전 점검표

남에게 앱 주소를 보내기 전에 아래 항목을 확인해 보세요. 뜻을 모르는 항목이 바로 도움을 받아야 할 곳입니다.

1. 다른 계정으로 로그인했을 때 남의 데이터가 보이지 않는가(권한 검사를 서버나 데이터베이스에서 하는가)
2. 비밀번호를 입력한 글자 그대로가 아니라 해시로 저장하는가
3. API 키 같은 비밀값이 화면 코드나 공개 저장소에 없는가
4. 결제가 중간에 끊기거나 취소됐을 때 주문 상태가 맞게 바뀌는가
5. 시험용과 운영용 데이터베이스가 나뉘어 있는가
6. 매일 백업이 되고, 그 백업으로 되살려 본 적이 있는가
7. 오류가 나면 원인을 볼 수 있는 로그가 남는가
8. 서버가 멈추면 알림이 오는가
9. 개인정보 처리방침이 있고, 필요 없는 개인정보는 모으지 않는가
10. AI 도구에 운영 데이터베이스를 지우거나 바꿀 권한을 주지 않았는가

개발자에게는 이렇게 부탁하면 됩니다.

"이 앱을 회원들에게 공개하려고 하는데, 위 점검표 가운데 빠진 것이 무엇인지 봐 주시고, 특히 남의 데이터가 보이지 않는지와 비밀번호·비밀값 처리를 먼저 확인해 주세요."

그래도 시작하려는 사람에게

바이브 코딩이 무의미하다는 이야기가 아닙니다. 아이디어를 빠르게 확인하고, 데모를 만들고, 반복 작업을 줄이는 데는 아주 쓸모 있는 도구입니다. 다만 서비스를 만들려면 AI에게 맡기기 전에 알아야 할 것이 있다는 점을 인정하고 시작하는 편이 낫습니다.

먼저 빙산 그림의 항목을 한 번씩 이름이라도 알아 두기를 권합니다. 프런트엔드와 백엔드가 어떻게 나뉘는지, 데이터베이스 권한은 어디서 검사하는지, 비밀값은 왜 코드에 넣으면 안 되는지 정도만 알아도 AI에게 하는 요청이 달라지고, AI가 쓴 코드에서 확인할 곳이 보입니다. 필자가 쓴 「바이브 코딩의 시대, 프롬프트를 넘어 컨텍스트 엔지니어링으로」는 이 과정을 AI와 협업하는 원리부터 실전까지 순서대로 다룹니다. AI에게 어떤 맥락을 주어야 하는지는 컨텍스트 엔지니어링 글에서, AI를 실제 제품에 안전하게 붙이는 장치는 하네스 엔지니어링 글에서 더 자세히 볼 수 있습니다.

배포와 인프라 운영은 가장 먼저 부딪히는 벽입니다. 서버를 빌리고, 도메인을 연결하고, 인증서를 붙이는 일은 화면을 만드는 일과 전혀 다른 지식을 요구합니다. 젠아이랩스(GenAI Labs)가 만든 GensApps는 이 부분의 부담을 덜기 위한 서비스입니다. Claude Code·Cursor 같은 AI 편집기에 MCP 서버(AI 편집기와 외부 서비스를 잇는 연결 장치) 주소 하나를 등록하고 "배포해 줘"라고 말하면, 만든 결과물이 공개 주소로 올라갑니다. 클라우드 계정이나 결제 수단 없이 만든 것을 먼저 보여 주고, 그다음에 빙산 아래를 하나씩 채워 가면 됩니다. 다만 배포를 대신해 준다고 앱 안의 보안까지 지켜 주지는 않습니다. 권한 검사와 비밀값 관리, 데이터 백업, 개인정보 보호는 여전히 앱을 만든 사람의 몫입니다.

자주 묻는 질문

코딩을 전혀 몰라도 바이브 코딩을 할 수 있나요?

화면을 만들고 아이디어를 확인하는 데까지는 할 수 있고, 표의 왼쪽 칸 일은 충분히 해 볼 만합니다. 다만 남에게 내놓으려면 적어도 빙산 그림의 항목이 무엇인지는 알아야 합니다. 문법을 외우기보다 어디를 확인할지 아는 것이 먼저입니다.

어떤 도구로 시작하면 좋을까요?

도구는 크게 두 갈래입니다. Lovable이나 Replit처럼 브라우저에서 말로 설명하면 화면과 서버를 함께 만들어 주는 서비스가 있고, Cursor나 Claude Code처럼 내 컴퓨터에서 코드를 직접 다루며 AI와 함께 쓰는 도구가 있습니다. 처음이라면 앞쪽이 쉽고, 코드를 직접 고쳐 나갈 생각이라면 뒤쪽이 맞습니다. 어느 쪽이든 표의 왼쪽 칸에 있는 작은 일로 먼저 연습해 보기를 권합니다.

바이브 코딩으로 만든 앱으로 돈을 받아도 되나요?

만든 방법이 무엇이든, 돈을 받는 서비스에 요구되는 기준은 같습니다. 돈을 받기 시작하면 사업자 등록, 결제대행사 계약, 이용약관과 개인정보 처리방침, 환불 규정처럼 챙길 일이 늘어납니다. 결제와 개인정보는 표의 오른쪽 칸이므로 출시 전에 전문가의 확인을 받는 편이 안전합니다. 이 답은 법률 자문이 아니며, 업종과 규모에 따라 절차가 다르니 세무사나 변호사와 상의하시기 바랍니다.

정리

바이브 코딩은 개발의 문턱을 확실히 낮췄습니다. 필자가 보는 현장에서는 기획자 한 명과 개발자 열 명이 몇 달 걸리던 일을 두세 명, 때로는 한 사람이 해내는 경우가 늘었습니다. 하지만 그 한 사람은 대개 화면 아래에 무엇이 있는지 아는 사람입니다. 바이브 코딩은 판단을 대신하지 않고, 판단할 줄 아는 사람의 속도를 키웁니다. 누구나 시작할 수는 있지만, 누구나 서비스를 끝까지 운영할 수 있는 것은 아닙니다. 그 차이를 알고 시작하는 것이 바이브 코딩을 제대로 쓰는 첫걸음입니다.

개발자를 위한 심화

이 부분은 직접 구현하는 개발자를 위한 내용입니다.

행 단위 보안(RLS) 예시

Lovable 사례처럼 브라우저가 Supabase 같은 데이터베이스에 직접 붙는 구조에서는 공개 키(anon key)가 브라우저 코드에 들어가는 것이 정상입니다. 그래서 보안은 키를 숨기는 데서가 아니라 데이터베이스 쪽 정책에서 나와야 합니다. Supabase 문서의 표현대로, 외부에 열린 스키마에 있는 표에 RLS가 꺼져 있으면 그 표에 권한을 받은 역할은 누구나 읽고 쓸 수 있습니다.

아래는 Supabase 문서의 예를 바탕으로 권한 줄을 더한 것으로, profiles 표를 로그인한 사용자가 자기 줄만 읽을 수 있게 막는 SQL입니다.

alter table public.profiles enable row level security;

revoke all on table public.profiles from anon, authenticated;
grant select, insert, update, delete on table public.profiles to authenticated;

create policy "Users can view their own profile."
on profiles for select
to authenticated
using ( (select auth.uid()) = user_id );

grant는 그 역할이 표에 어떤 동작을 할 수 있는지를, 정책(policy)은 그 동작이 어느 줄에 닿는지를 정합니다. RLS를 켠 표에서는 정책이 없는 동작이 막히므로, 쓰기(insert·update·delete)가 필요하면 동작마다 정책을 따로 둡니다. 정책을 만든 뒤에는 계정 두 개로 로그인해 서로의 줄이 보이지 않는지 확인하는 시험을 남겨 두는 편이 좋습니다.

비밀값 관리

• Supabase의 service_role 키처럼 RLS를 건너뛰는 키는 서버에서만 쓰고, 브라우저 코드나 공개 저장소에 넣지 않습니다.
• 비밀값은 환경 변수나 클라우드의 비밀값 저장소(AWS Systems Manager Parameter Store, Secrets Manager 등)에 두고, 저장소에는 이름만 남깁니다. .env 파일은 .gitignore에 넣고, 예시 파일(.env.example)의 비밀값 자리는 비워 둡니다.
• 한 번 커밋된 키는 파일에서 지워도 git 기록에 남습니다. 노출된 키는 지우는 것으로 끝내지 말고 새로 발급해 바꿉니다.
• AI 에이전트에는 운영 데이터베이스 쓰기 권한과 운영 비밀값을 주지 않습니다. Replit 사례처럼 멈추라는 지시가 있어도 에이전트가 따르지 않을 수 있으므로, 막는 장치는 지시가 아니라 권한으로 둡니다.

글쓴이 박수현(젠아이랩스 대표) with AI (Claude Opus 5.5). 이 글의 관점과 주장은 필자의 20년 넘는 개발·아키텍트 경험에서 나왔고, 근거 자료 조사와 도표 제작, 문장 정리는 Claude Opus 5.5와 함께했습니다. 인용한 수치는 모두 출처 원문과 대조했습니다. 『바이브 코딩의 시대, 프롬프트를 넘어 컨텍스트 엔지니어링으로』를 비롯해 AI 실무서 네 권을 썼습니다.