스스로에게 “Vibe Code”를 설득하기
Source: Dev.to
분위기가 문을 두드리다
“Vibe Coding”은 수동적인 구문 대신 순수한 자연어 의도를 통해 애플리케이션을 구축하는 방식을 의미합니다. 2024년 말에 처음 눈에 띄었고, 솔직히 말해서 게으른 사람들을 위한 유행어처럼 느껴졌습니다. 하지만 거실에서 직접 보게 되면서 상황이 바뀌었습니다. 아내가 v0를 사용해 무료 티어로 30분 이내에 기능적인 웹 앱을 만들었습니다.
완벽하진 않았습니다— UI는 보기 흉하고 로직은 부서지기 쉬웠지만 it worked. 저는 하루 안에 기본적인 기능을 갖춘 애플리케이션을 직접 연결할 수 있다고 자랑스럽게 말하곤 했습니다. 그런데 아내는 제가 보통 자부심을 갖고 있던 수많은 보일러플레이트와 배관 작업을 눈앞에서 바로 건너뛰어 버렸습니다.
Where It Thrives and Dies
Before this, I found that AI seldom had enough intelligence to help me fix a nuanced bug or upgrade a specific package. Naturally, I thought:
“If you aren’t able to even fix a bug, how can you build an app for me?”
That mindset held me back for a long while. After the astonishing moment in my living room—and a bit of digging—I was able to categorize where AI actually excels.
- Kick‑start – 보일러플레이트를 생성하고 초기 스텁을 연결하며, 매우 명확히 정의된 문제를 해결하는 것이 AI가 정말 잘하는 일입니다.
- Enterprise environment – 복잡한 비즈니스 로직, 방대한 기존 코드베이스, 그리고 10년 동안 패치된 레거시 시스템을 도입하면 AI는 환상을 만들기 시작합니다. 설계가 부실한 시스템이나 100 k 줄 이상의 코드를 가진 레포지토리에서는 AI 제안이 종종 전혀 의미가 없습니다. AI는 10년간 쌓인 기술 부채의 무게를 “느낄” 수 없습니다.
왜 우리는 거절하는가
만약 내가 처음에 vibe coding을 거절한 이유를 묻는다면, 솔직히 말하면 답은 AI의 기술적 능력만이 아니라 우리의 정체성에 관한 것입니다.
품질 함정
우리는 이 도구들이 만들어내는 “쓰레기” 같은 코드를 보게 됩니다—패턴의 부재, 중복, 뒤죽박죽인 파일 구조—그리고 몸을 떱니다. 엔지니어로서 우리는 세부 사항을 통제하도록 훈련받았습니다. 그 통제를 포기하는 것은 우리 장인의 정신을 배신하는 느낌이 듭니다.
알 수 없는 것에 대한 두려움
AI는 빠르게 일을 추진할 수 있는 모멘텀을 가지고 있습니다. 그것은 내가 사용해 보지 않은 솔루션이나 라이브러리를 소개합니다. 내부 메커니즘을 모두 이해하지 못한다면, 나는 내 경쟁력이 사라지는 느낌을 받습니다. 이것은 철학적인 장벽이기도 합니다:
모든 줄을 이해해야 할까요?
내게는 답이 언제나 예였습니다. 프로젝트 안에 알 수 없는 코드 조각이 있으면 마치 폭발을 기다리는 지뢰와도 같았습니다.
자아 점검
전문가 사이에서 느껴지는 진정하고 불편한 질투감이 있습니다. 비전문가가 $20 구독료만 내고 내가 수년간 고생해서 배운 프레임워크를 우회할 수 있다는 것이 “불공평”하게 느껴집니다. vibe coding을 “진짜 일”이 아니라고 치부하면, 내 자신의 투자에 대해 위안이 됩니다.
코드 품질이 정말 문제일까?
Vibe‑코드 프로젝트는 종종 단명하며, 결국 사라지게 된다. 이들은 아이디어나 도구 자체를 테스트하기 위해 만들어진다. 아이디어가 실패하면 코드는 “404 강” 속에서 조용히 사라진다. 아이디어가 성공하면 엔지니어에 의해 다시 작성된다.
엔지니어 관점: 짧은 기간에 쓰이는 코드의 품질을 정말 신경 써야 할까? 나는 언제나 빠른 Bash 스크립트나 일회용 Python 스크립트를 작성하고, 그 품질에 크게 신경 쓰지 않는다. 10분짜리 작업을 위해 엉성한 스크립트를 받아들일 수 있다면, 1일짜리 검증을 위한 vibe‑코드 프로토타입도 받아들일 수 있지 않을까?
비기술 사용자 관점: 많은 vibe‑코더들은 기술 배경이 없으며, 앞으로도 없을 가능성이 크다. 그들은 아마도 코드베이스를 들여다보지 않을 것이다. 중요한 것은 엔지니어를 고용하지 않고도 아이디어를 테스트할 수 있다는 점이다.
이 그룹의 큰 비중을 차지하는 사람들은 PM과 디자이너이다. 그들은 엔지니어와 무관하게 더 짧은 시간 안에 아이디어를 검증할 수 있는 도구를 얻는다. 어느 정도는 우리가 해야 할 “버려지는” 엔지니어링 작업의 양을 줄여준다.
소프트웨어 엔지니어링 정의
소프트웨어 엔지니어링은 단순히 애플리케이션을 시작하는 것 이상이며, 작업의 대부분은 이를 유지보수하는 것입니다. 이것은 새로운 깨달음은 아니지만, 다시 생각해보니 자신감을 회복할 수 있었습니다. AI가 “시작”을 담당한다면, 엔지니어의 가치는 지속 가능성으로 이동합니다. 엔지니어링은 “분위기”를 유지보수가 가능한 형태로 리팩터링하는 것입니다. 이는 첫 주말이 아니라 두 번째 해까지 살아남을 수 있는 시스템을 설계하는 것입니다.
선을 그리다
AI는 마술 트릭이 될 수도 있고 생산성 도구가 될 수도 있습니다. 경계는 흐릿하지만, 이를 명확히 그리면 엔지니어로서의 정체성을 잃지 않으면서 생산성을 높일 수 있습니다.
분위기 측면
- AI를 탐색, 빠른 프로토타이핑, 검증에 활용한다.
- PM이 아이디어 검증을 위해 “감각”을 원한다면 허용한다. 그 코드는 단기 사용을 위한 것이다.
엔지니어 측면
- AI를 사용해 스텁을 구현하고, 범위가 지정된 버그를 수정하며, 나중에 리팩터링하고 소유할 보일러플레이트를 생성한다.
—
Author: Zane Chen (original article on dev.to)
- 새로운 패턴을 배우고, 보일러플레이트를 설정하며, 엔지니어에게 명확하고 유익한 모든 것.