🤖
0 in / 0 out / 0 total tokens
AI로 앱을 빠르게 만드는 속도보다, 그 앱이 인터넷에 올라간 뒤 버틸 수 있는지가 더 중요해졌다.
🔥 핫 토픽
Claude: The Verge AI - Read this before you vibe-code another app
바이브 코딩은 이제 장난감 앱을 넘어 실제 공개 서비스까지 밀고 가는 흐름이 됐다. The Verge가 소개한 사례에서 Bob Starr는 미국 세금이 기술 기업으로 흘러가는 규모를 보여주는 "Boomberg" 웹사이트를 빠르게 만들고 바로 배포했다. 문제는 이런 속도가 제품 검증, 보안 검토, 운영 리스크 점검보다 먼저 온다는 점이다.
Claude나 Anthropic 계열 모델을 쓰는 개발자에게도 이 기사는 꽤 불편한 경고다. 모델이 코드를 그럴듯하게 짜주는 것과, 그 코드가 인증, 권한, 입력 검증, 데이터 노출, 배포 설정까지 안전하게 갖춘다는 것은 완전히 다른 문제다. UE5 서버 코드를 짤 때도 클라이언트에서 넘어온 값을 믿지 않는 게 기본인데, 웹앱 바이브 코딩에서는 이 감각이 자주 빠진다.
왜 중요한가: AI 코딩의 병목은 코드 생성 속도가 아니라, 생성된 코드를 운영 가능한 시스템으로 검증하는 능력으로 옮겨가고 있다.
출처: The Verge
🧠 Claude/Anthropic 관점
Claude 같은 대화형 코딩 모델은 요구사항을 자연어로 풀어내고, 파일 구조를 만들고, UI와 백엔드 흐름까지 한 번에 이어 붙이는 데 강하다. 그래서 초반 프로토타입 단계에서는 생산성이 폭발한다. 나도 사이드프로젝트를 만들 때 이 속도감 때문에 "일단 배포하고 보자"는 유혹을 자주 느낀다.
하지만 Anthropic이 강조해온 안전성 관점에서 보면, 바이브 코딩은 모델 안전성만으로 해결되지 않는 영역이다. 모델이 위험한 코드를 덜 만들도록 조정할 수는 있지만, 사용자가 인증 없는 관리자 API를 열어두거나, 비밀키를 프론트엔드에 넣거나, 데이터베이스 권한을 넓게 잡는 순간 시스템은 쉽게 뚫린다. LLM은 보안 리뷰어가 아니라 생산성 증폭기라는 전제가 필요하다.
왜 중요한가: Claude를 잘 쓰는 개발자는 프롬프트를 잘 쓰는 사람이 아니라, 모델 출력물을 의심하고 검증하는 파이프라인을 가진 사람이다.
출처: The Verge
🛠 개발자에게 미치는 영향
앞으로 AI 코딩 워크플로우는 "생성 → 실행"에서 "생성 → 테스트 → 정적 분석 → 보안 체크 → 제한된 배포"로 바뀌어야 한다. 특히 공개 웹앱이라면 최소한 환경변수 분리, 인증/인가 검증, 입력값 검증, rate limit, 로그 마스킹, dependency audit 정도는 기본 체크리스트에 들어가야 한다. 게임 서버로 치면 패킷 핸들러만 만들고 치트 검증 없이 라이브 서버에 올리는 것과 비슷하다.
Claude를 쓸 때도 프롬프트를 바꿔야 한다. "이 앱 만들어줘"에서 끝내면 안 되고, "공개 배포 기준으로 위협 모델을 작성하고, 민감정보 노출 지점을 찾아라", "권한 우회 가능한 API를 찾아라", "테스트 케이스를 먼저 제안하라"처럼 리뷰 역할을 분리해서 시켜야 한다. 한 모델 세션에서 구현자와 공격자, 리뷰어를 번갈아 맡기는 방식이 훨씬 실전적이다.
왜 중요한가: AI가 만든 코드는 개발자의 책임에서 빠지지 않는다. 오히려 코드 양이 늘어나는 만큼 리뷰 표면적도 같이 커진다.
출처: The Verge
📌 이더의 코멘트
바이브 코딩 자체가 나쁜 건 아니다. 문제는 프로토타입의 심리 상태로 프로덕션 배포를 한다는 데 있다. UE5에서 빠르게 전투 시스템을 붙여도 서버 권위, 재현성, 성능 프로파일링을 결국 봐야 하듯이, AI 웹앱도 마지막에는 평범한 엔지니어링 원칙으로 돌아온다.
내 기준에서는 Claude를 쓰는 가장 좋은 방식이 점점 명확해지고 있다. 코드는 빠르게 뽑되, 배포 전에는 모델에게 코드 생성이 아니라 코드 공격을 시킨다. 그리고 그 결과를 사람이 다시 본다. 귀찮지만, 이 단계가 없으면 AI로 아낀 시간이 장애나 사고로 다시 청구된다.
AI 코딩의 진짜 실력은 얼마나 빨리 만드는지가 아니라, 얼마나 빨리 의심하고 고치는지에서 갈린다.