전통 SDLC에서 VDLC로, 그런데 VDLC도 벌써 옛말입니다

요즘 개발 방법론 이야기가 부쩍 많이 들립니다. SDLC는 끝났고 이제 VDLC라는 식의 글도 종종 보이고요.

저도 요즘은 AI한테 코드를 맡기는 일이 많아져서 관심이 갔습니다. 그래서 좀 찾아봤는데, 알아보다가 좀 허탈해졌습니다.

결론부터 말하면 이렇습니다. VDLC의 뿌리인 "바이브 코딩"이라는 말은, 그 말을 만든 사람이 이미 접었습니다. 만든 지 1년 만에요.

먼저 SDLC가 어떻게 흘러왔는지

순서대로 보면 흐름이 눈에 들어옵니다.

방법론이 바뀌는 주기 · 31년 → 24년 → 1년

시작은 1970년 윈스턴 로이스의 논문입니다. 요구사항 → 설계 → 구현 → 검증 → 유지보수 순서로 흐르는 폭포수 모델이죠.

여기 재밌는 대목이 있습니다. 로이스는 그 논문에서 "이렇게 한 번에 쭉 가면 위험하다"고 썼습니다. 반복해서 돌아야 한다고 했는데, 정작 폭포수의 아버지로 기억됩니다. 사람들이 그림만 보고 경고문은 안 읽은 셈입니다.

그다음이 2001년 애자일 선언입니다. 한 번에 다 설계하지 말고 짧게 돌면서 고치자는 쪽으로 무게추가 넘어갑니다. 2주 스프린트가 표준이 되죠. 폭포수에서 여기까지 31년 걸렸습니다.

그리고 2025년 2월 2일, 안드레이 카파시가 트위터에 한 문장을 남깁니다. "바이브 코딩이라는 새로운 코딩이 있다. 코드가 존재한다는 사실조차 잊어버리는 것이다." 애자일에서 여기까지 24년입니다.

이 말이 그해 콜린스 사전 올해의 단어로 뽑힙니다. 농담처럼 시작한 말이 사전에 오른 거죠.

그걸 방법론으로 만들려는 시도가 나옵니다

회사에서 "우리 이제 바이브로 갑니다"라고 할 수는 없으니, 틀을 만드는 작업이 이어집니다. 그중 하나가 VDLC(Vibe Coding Development Lifecycle)이고, 더 문서가 잘 갖춰진 쪽은 AWS가 내놓은 AI-DLC입니다.

전통 SDLC와 AI-DLC의 구조 비교

AI-DLC는 인셉션 · 컨스트럭션 · 오퍼레이션 세 단계로 갑니다. 용어가 좀 낯선데, 정리하면 이렇습니다.

인텐트(Intent)는 하고 싶은 것이고, 유닛(Unit)은 그걸 쪼갠 덩어리이고, 볼트(Bolt)는 한 바퀴 도는 단위입니다. 여기서 볼트가 핵심인데, 2주가 아니라 몇 시간에서 며칠입니다.

제가 보기에 중요한 건 단계 수가 5개에서 3개로 준 게 아닙니다. 한 바퀴 도는 시간이 2주에서 몇 시간으로 줄었다는 쪽입니다. 요구사항 정하고 만들고 검증하고 배포하는 일 자체는 그대로거든요.

그리고 AI-DLC 문서를 보면 단계마다 사람이 승인하는 관문이 있습니다. 사람을 빼는 게 아니라 위치를 옮기는 구조입니다. 코드를 쓰는 자리에서 검토하는 자리로요.

그런데 용어를 만든 사람이 용어를 접었습니다

여기서 허탈해진 대목입니다.

2026년 2월, 카파시가 "바이브 코딩은 한물갔다"고 말합니다. 본인이 1년 전에 만든 말을요.

이유는 이렇습니다. 모델이 좋아져서 이제는 전문가들도 일상적으로 쓰는 작업 방식이 됐는데, "바이브"라는 말에는 대충 감으로 한다는 뉘앙스가 남아 있다는 겁니다.

대신 내놓은 이름이 에이전틱 엔지니어링입니다. 코드를 직접 쓰는 게 아니라 에이전트를 시키고 감독한다는 뜻에서 "에이전틱"이고, 거기에도 기술과 전문성이 필요하다는 뜻에서 "엔지니어링"입니다.

그러니까 SDLC → VDLC라고 정리하는 순간 이미 반 박자 늦은 셈입니다. 폭포수에서 애자일까지 31년 걸리던 게, 이제는 용어 하나가 1년을 못 버팁니다.

그래서 정말 빨라졌나

이름이야 어떻든 실제로 빨라졌으면 된 거 아니냐 싶은데, 여기에 흥미로운 데이터가 있습니다.

체감과 실측의 간극 · METR 무작위 대조 실험

METR이라는 곳에서 숙련 개발자 16명에게 실제 과제 246건을 시키고 시간을 쟀습니다. 자기가 5년쯤 다룬 저장소에서요.

시작 전에 물어보니 24% 빨라질 것 같다고 했습니다. 끝나고 물어보니 20% 빨라진 것 같다고 했고요. 그런데 실제로 재어 보니 19% 느려져 있었습니다.

빨라졌다고 느끼는데 실제로는 느려진 겁니다. 이 간극이 저는 제일 무섭습니다.

스택오버플로우 2025년 설문도 비슷한 그림입니다. AI를 쓰는 개발자는 84%로 늘었는데, 정확성을 믿지 않는다는 답이 31%에서 46%로 뛰었습니다. 가장 큰 불만으로 꼽힌 건 "거의 맞는데 살짝 틀림"이 66%였고요.

이 "거의 맞음"이 진짜 문제입니다. 완전히 틀린 코드는 바로 터지니까 금방 찾습니다. 그런데 거의 맞는 코드는 잘 돌아가는 것처럼 보이다가 엉뚱한 데서 터집니다. 응답자 45%가 AI 코드 디버깅이 직접 짜는 것보다 오래 걸린다고 답한 이유겠죠.

다만 이 실험은 2025년 초 모델 기준이고 표본도 16명으로 작습니다. 지금 다시 재면 다른 결과가 나올 수도 있습니다. 그래도 체감과 실측이 벌어진다는 사실 자체는 기억해 둘 만합니다.

남는 생각

정리하면서 든 생각은 이렇습니다.

용어는 계속 바뀔 겁니다. 바이브 코딩이 에이전틱 엔지니어링이 됐듯이, 내년에는 또 다른 이름이 나올 거예요. 그걸 따라 외우는 건 별로 의미가 없어 보입니다.

바뀌지 않는 건 따로 있습니다. 누가 코드를 쓰든 그게 맞는지 확인할 책임은 사람에게 남는다는 것입니다. AI-DLC가 단계마다 승인 관문을 둔 것도 같은 이야기고요.

예전에 폭포수에서 애자일로 넘어올 때 "문서 안 써도 된다"고 오해한 사람들이 있었습니다. 애자일 선언은 문서보다 작동하는 소프트웨어를 앞에 둔다고 했지 문서를 없애라고 한 적이 없는데 말이죠.

지금도 비슷한 오해가 생길 것 같습니다. 바이브 코딩이 "코드를 안 봐도 된다"는 뜻으로 읽히는 것 말입니다. 카파시가 1년 만에 이름을 바꾼 이유도 아마 거기에 있지 않을까 싶습니다.

로이스가 1970년에 "이렇게 하면 안 된다"고 써놨는데 그림만 보고 따라한 것처럼, 우리도 같은 실수를 반복하는 중인지도 모르겠네요. ^^