'일단 뭔가 돌아가는 걸 만들어봤다'는 감각, 한 번쯤 느껴봤을 것이다. AI 도구에 아이디어를 설명했더니 10분 만에 그럴싸한 UI가 뜨고, 30분 만에 API가 붙고, 1시간 만에 데모 링크가 생겼다. 흥분되는 순간이다. 그런데 그 흥분이 가라앉고 나면 불편한 질문이 남는다. 이걸 실제로 쓸 수 있을까?
이 질문에 제대로 답하려면 AI 보조 개발을 하나의 단계로 보는 시각에서 벗어나야 한다. dev.to에 최근 올라온 세 편의 글—Vibe Engineering 개념을 정리한 Naresh의 글, Task-Driven Development를 실전 적용한 Luis의 경험기, 그리고 개발자 경험이 AI 시대에 왜 더 중요해지는지를 짚은 Ebenezer의 분석—을 나란히 읽으면 하나의 흐름이 보인다. 탐색 → 구조화 → 검증이라는 세 단계가 그것이다. 각 단계는 독립적으로도 가치 있지만, 세 단계를 하나의 사고 프레임으로 연결할 때 비로소 '아이디어에서 프로덕션까지'의 루프가 닫힌다.
1단계: Vibe Engineering — 구조보다 탐색이 먼저다
Vibe Engineering은 '느낌대로 코딩한다'는 뜻이 아니다. Naresh의 정의를 빌리면, 이 단계의 핵심은 구조보다 탐색이 먼저라는 태도다. 아직 무엇을 만들어야 할지 명확하지 않은 상태에서 AI와 대화하며 아이디어에 형태를 부여하는 과정이다. 맞고 틀림을 따지는 게 아니라, 이 방향이 가치 있는가를 빠르게 검증하는 것이 목표다.
이 단계에서 AI는 코드 생성기가 아니라 사고 파트너다. 프롬프트를 던지고 결과물을 받는 것이 아니라, 질문을 던지고 피드백을 해석하고 방향을 조정하는 반복이 이루어진다. 중요한 것은 이 루프를 돌리는 속도다. 탐색 비용이 거의 제로에 가까워졌다는 것, 그것이 Vibe Engineering이 가져온 가장 큰 변화다. 예전엔 아이디어 하나를 검증하려면 스택을 고르고 환경을 세팅하고 작은 조각들을 수작업으로 붙여야 했다. 지금은 그 과정 전체가 대화 몇 번으로 대체된다.
단, 이 단계를 끝으로 착각하면 안 된다. Naresh가 명시적으로 경고하듯, Vibe Engineering은 어떤 시스템을 만들 가치가 있는지 발견하는 단계이지, 그 시스템 자체를 만드는 단계가 아니다. 프로토타입이 한 번 돌아간다는 것은 그것이 신뢰할 수 있다는 증거가 아니다. 바로 이 지점에서 2단계로의 전환이 필요해진다.
2단계: Task-Driven Development — 방향을 에너지로 변환하라
Luis의 경험기는 솔직하다. 그는 1년 전 Vibe Coding으로 ExamGenius를 20시간 만에 만들었고, 개발 시간을 85% 줄였다고 자랑했다. 그런데 1년 후 그가 쓴 글의 제목은 이렇다: "Vibe Coding을 멈추고 배포를 시작했다." 무엇이 바뀐 것일까.
Vibe Coding의 문제는 코드 품질이 아니었다. AI가 생성한 코드는 충분히 깔끔했다. 문제는 방향의 부재였다. 명확한 스코프 없이 'AI야, 이거 고쳐줘'를 반복하면 AI는 요청받지 않은 15개 파일을 건드리고, 아무도 이유를 모르는 코드가 코드베이스에 쌓인다. 그린필드 프로젝트에서는 괜찮다. 하지만 팀이 있고, 레거시가 있고, 실제 사용자가 있는 프로젝트에서는 이 패턴이 무너진다.
그가 도입한 Task-Driven Development의 핵심은 간단하다. 코드를 생성하기 전에 계획을 검토한다. Spec → Tasks → Subtasks → Plan 검토 → 실행 → 리뷰의 순서에서, 'Plan 검토' 단계가 가장 중요하다. AI에게 먼저 구현 계획을 짜게 하고, 개발자가 그것을 승인하거나 수정한 뒤에 코드를 건드리게 하는 것이다. '만들어줘'와 '어떻게 만들 건지 말해줘, 그 다음에 만들어'의 차이가 결국 프로덕션 품질의 차이가 된다.
그리고 Definition of Done이 등장한다. 테스트 통과, 기존 패턴 준수, 회귀 없음, 번역 완성 여부 같은 구체적인 완료 기준을 태스크마다 붙이면 AI는 '코드를 생성하는 블랙박스'에서 '기준을 충족해야 하는 실행자'로 역할이 바뀐다. 이 구조 안에서 개발자는 다시 아키텍트와 리뷰어가 된다. AI가 실행하고, 인간이 방향을 결정한다.
3단계: 경험 기반 평가력 — AI가 대답하지 않는 질문을 던지는 능력
Task-Driven Development가 구조를 제공한다면, Ebenezer의 글은 그 구조를 실질적으로 작동시키는 힘이 무엇인지를 짚는다. AI가 생성한 코드는 이제 표면적으로 깔끔하다. 주니어가 AI를 써서 만든 코드와 시니어가 직접 짠 코드는 겉보기엔 구분이 안 된다. 바로 이 수렴이 문제다.
겉모습이 다 비슷해진 세상에서, 진짜 실력은 '무엇이 실제로 옳은가'를 가려내는 능력이 된다. Ebenezer의 표현을 빌리자면, AI는 당신이 묻는 것에만 대답한다. 외부 API가 다운됐을 때 어떻게 되는지, 동시 요청이 몰릴 때 커넥션 풀이 버티는지, 6개월 후 쿼리 패턴이 바뀌었을 때 데이터 모델이 따라오는지—이런 질문은 그 상황을 직접 겪어본 사람만 할 수 있다. 경험은 물어봐야 할 것을 알게 해주는 능력이다.
그는 또 하나 중요한 전환을 짚는다. 예전엔 개발자가 초안을 썼다. 이제는 AI가 쓴 초안을 편집한다. 그런데 편집은 쓰기보다 어렵다. 코드를 직접 쓸 때는 맥락이 머릿속에 있다. 편집할 때는 AI의 의도를 역공학으로 파악하고, 그것이 실제 요구사항과 맞는지를 검증해야 한다. 'AI가 코드를 쓰고 나는 리뷰한다'는 말은 쉽게 들리지만, 그 리뷰가 진짜 가장 어려운 부분이다.
세 단계가 하나의 루프가 될 때
이 세 단계를 선형으로 보면 안 된다. 실제 워크플로우에서는 순환한다. Vibe Engineering으로 아이디어의 가능성을 빠르게 탐색하고, Task-Driven Development로 실행에 구조를 부여하고, 경험 기반 평가력으로 AI 출력물의 진짜 품질을 검증한다. 그리고 검증 과정에서 발견한 것들이 다시 다음 탐색의 방향을 정제한다.
이 흐름에서 놓치기 쉬운 함정이 하나 있다. 속도의 착각이다. Vibe Engineering은 탐색 비용을 거의 제로로 만든다. Task-Driven Development는 실행 속도를 크게 높인다. 하지만 경험 기반 평가력은 여전히 시간이 필요하다. 장애를 겪고, 마이그레이션을 해보고, 설계 결정이 6개월 후 발목을 잡는 경험을 쌓아야 한다. AI가 주니어의 생산성을 시니어 수준으로 끌어올리는 동안, 그 경험을 쌓을 기회 자체가 줄어들 수 있다는 것—이것이 이 흐름 전체에 드리운 가장 조용한 위험이다.
그래서 지금 이 시대에 필요한 개발자상은 역설적이다. AI를 적극적으로 쓰되, 의도적으로 어려운 문제에 자신을 노출시켜야 한다. 탐색은 AI와 함께 빠르게, 판단은 경험을 갖춘 인간이 천천히. 이 두 속도를 동시에 유지하는 것이 '아이디어에서 프로덕션까지'를 제대로 가져가는 사고 방식의 핵심이다.
Vibe Engineering이 가져다준 가장 큰 선물은 속도가 아니다. 만들어볼 가치가 있는 것을 더 빨리 발견할 수 있게 됐다는 것이다. 그 발견을 실제 가치로 바꾸는 일은, 여전히 구조와 판단력을 갖춘 사람의 몫이다.