비개발자의 '바이브코딩'에서 가장 큰 잠재적 위험은 위험 평가일지도 모른다.

내가 계속 마주치는 건 변수로 만들어진 파괴적인 명령어임. cron에서 rm -rf $BACKUP_DIR/*를 실행하는 스크립트 뒷수습을 한 적이 있는데, cron에는 쉘 환경 변수가 없어서 BACKUP_DIR이 비어있었거든. 한 번 데여본 사람은 바로 윗줄에 변수가 설정됐는지 확인하는 체크 로직을 넣는데, 그런 체크는 AI한테 하라고 시킬 생각조차 못 하는 부분이지.

거의 AI로만 만든 게임을 개발하면서 최소 열 번은 이런 생각을 했어. "내가 프로 개발자가 아니었으면 이 문제 때문에 진짜 고생했겠다" 아니면 "젠장, 10년 차 개발자인 나도 이 버그 때문에 막히는데 경험 없는 '바이브코더'들은 이걸 어떻게 해결하는 거지?" 어떤 이슈들은 "내가 바이브코더였으면 이 문제 때문에 프로젝트 접었을 거야"라는 생각까지 들더라. 그래서 앞뒤 안 보고 무작정 달려들어서 결국 작동하는 앱이나 게임을 출시하는 바이브코더들에게 경의를 표함, 그건...

네, 저도 똑같이 경험했습니다

네가 말한 함정이 바로 이거야. AI한테 방어해달라고 요청하려면 애초에 어떤 위험 요소가 있는지 알고 있어야 하잖아. 그게 바로 "그냥 코드 리뷰해라"나 "프롬프트를 더 잘 짜라"는 말이 비개발자들한테는 안 통하는 이유지. 자기가 모르는 유형의 버그는 리뷰 자체가 불가능하니까. akl773이 든 예시가 딱 깔끔한 경우인데, BACKUP_DIR이 설정 안 된 상태에서 rm -rf $BACKUP_DIR/*가 실행되는 건 가상의 시나리오가 아님. 이건 쉘에서 흔히 발생하는 실수(따옴표 안 쓴 확장, 설정 안 된 변수 삽입 등) 중 하나거든...

"난 쟤네보다 낫다" -> 내 지위를 잃을까 봐 두려운 거겠지

제대로 된 바이브 코더라면 여러 인스턴스와 모델을 돌려서 같은 프로젝트를 검증하게 만들지. 프로젝트 하나당 인스턴스 하나만 쓴다면... 그게 바로 네가 틀린 지점이야.

난 내 결과물에 내 평판을 걸고 있어. 위험 요소는 알고 이해하고 있고, 내 코드에 대한 신뢰(AI가 생성했더라도)는 나한테 달려 있는 거지.