Vibe Coding은 문제가 아니다 — '엔지니어링'이라 부르는 것이 문제다

본문

AI 코딩 도구가 일상화되면서 vibe coding을 둘러싼 논쟁이 뜨거워지고 있습니다. dev.to의 소프트웨어 엔지니어 George Kobaidze는 "vibe coding은 창작 과정이지만 엔지니어링은 아니다"라고 말하면 곧바로 gatekeeper라는 반발이 돌아오는 현 상황을 지적하며, 두 개념의 차이를 정면으로 정리합니다.

'만들기(creation)'와 '엔지니어링'은 다르다

저자는 creation이 더 넓은 개념이며, 엔지니어링은 그 안에 포함되는 활동이라고 정의합니다. 엔지니어링은 제작뿐 아니라 유지보수, 디버깅, 리팩터링 등 엔지니어가 실제로 하루 대부분을 보내는 작업 전반을 가리킵니다. 그래서 진짜 질문은 "제작 과정에서 누가 엔지니어링을 하는가 — 당신인가, 코딩 에이전트인가, 둘 다인가"라고 묻습니다.

세 가지 작업 방식의 구분

저자는 AI 활용 방식을 세 단계로 나눕니다. 첫째, 프롬프트를 써서 AI에 넘기고 코드를 수정도 리뷰도 하지 않는 방식 — 프로그래밍 지식이 전혀 없어도 무언가를 출시할 수 있는, 진정한 의미의 vibe coding입니다. 둘째, AI가 전부 작성하고 사람이 전부 읽는 방식 — 좋은 코드와 나쁜 코드를 구별할 실력이 필요하므로 vibe coding이 아니라고 못 박습니다. 셋째, 사람이 주도권을 잡고 AI와 함께 작성하는 방식 — AI가 속도와 제2의 의견, 놓쳤을 엣지 케이스를 제공하며, 이 역시 vibe coding이 아니라고 분류합니다.

추상화의 다음 단계, 하지만 아직은 아니다

저자는 어셈블리 이후 계속되어 온 추상화와 시맨틱 확장의 연장선 위에 vibe coding이 있다고 봅니다. 언젠가 업무의 95%가 프롬프트 작성이 되는 날이 오면 자신도 환영할 것이며 삶이 편해질 것이라고 인정합니다. 다만 지금 당장 코드 분석 없이 금융 시스템, 헬스케어 앱, 민감 데이터를 다루는 소프트웨어를 만들 준비는 되어 있지 않으며, 논점을 증명하겠다고 억지로 밀고 나가면 "절대적인 혼란(absolute chaos)"을 부를 것이라고 경고합니다.

저자가 긋는 경계선

혼자 재미로 만드는 프로젝트라면 처음부터 끝까지 vibe coding해도 좋다고 말합니다. 하지만 개인 데이터를 처리하고 돈을 다루며 수익을 내는 실제 제품을 전부 vibe coding으로 만든다면 세 가지 중 하나를 의미한다고 지적합니다. 첫째, 코딩·보안·모범 사례의 기초를 배우는 데 2~4주를 쓸 의지가 없는 경우. 둘째, 자기 제품의 품질과 궁극적으로 타인의 개인 데이터·보안을 신경 쓰지 않는 경우. 셋째, 내부 동작 원리에 호기심이 없는 경우 — 엔지니어를 자처한다면 소프트웨어 엔지니어링의 메커니즘을 이해하려는 열망이 있어야 한다는 것입니다. 그리고 이 세 가지가 지금 끊임없이 일어나고 있다는 점이 슬픈 부분이라고 덧붙입니다.

10년차 엔지니어가 일하는 방식

저자는 10년 경력에도 익숙하지 않은 언어로 작업할 때 하루 이틀을 언어 레퍼런스와 문서, 기본 메커니즘 학습에 쓰며, 그래야 AI가 만들어낸 결과물을 이해할 수 있다고 합니다. AI가 생성한 코드는 전부 리뷰하고 후속 질문을 끊임없이 던져, 프로젝트를 만드는 데 쓰는 것보다 코드를 심문하는 데 더 많은 토큰을 쓴다고 밝힙니다. 자신이 아는 강한 엔지니어들은 모두 이렇게 일하며, AI를 매일 광범위하게 쓰면서도 결과를 있는 그대로 받아들이지 않습니다. "운전대를 놓을 수 있는 시점은 올 것이다. 하지만 아직은 아니다. 길을 벗어나지 않으려면 핸들을 계속 잡고 있어야 한다"고 맺습니다.

원문: dev.to / 번역·요약: Trawling