바이브 코딩 이후의 개발은 어떻게 달라질까: Google이 정리한 새로운 SDLC

얼마 전 Anthropic이 공개한 「Agentic Coding and Persistent Returns to Expertise」 연구를 정리한 글을 작성했다.

이 연구에서 특히 흥미로웠던 부분은 AI 코딩 도구를 잘 활용하기 위해 반드시 높은 수준의 코딩 전문성이 필요한 것은 아니라는 점이었다. 오히려 자신이 해결하려는 문제를 제대로 이해하고 있는 사람이 에이전트에게 더 정확한 지시를 내리고, 결과에서 잘못된 부분을 발견하며, 문제가 발생했을 때 방향을 바로잡을 가능성이 높았다.

다만 아무것도 모르는 상태와 어느 정도 이해하고 있는 상태 사이에는 비교적 큰 차이가 있었지만, 중간 수준 이상의 이해도를 갖춘 뒤에는 전문가와의 격차가 생각만큼 크지 않았다.

 

이번에 읽은 Google의 「The New SDLC With Vibe Coding」은 이 연구와 연결해서 읽기 좋은 문서였다.

Anthropic의 연구가 실제 Claude Code 사용 데이터를 바탕으로 사람과 에이전트가 어떻게 협업하는지를 분석했다면, Google의 문서는 바이브 코딩과 AI 에이전트가 보편화되면서 소프트웨어 개발 생명주기, 즉 SDLC가 어떻게 달라지는지를 보다 넓은 관점에서 설명한다.

단순히 “AI가 코드를 대신 작성한다”는 이야기가 아니다.

코드 생성 비용이 크게 낮아진 상황에서 소프트웨어 개발의 병목이 어디로 이동하는지, 어떤 역량과 과정이 이전보다 중요해지는지, 그리고 빠르게 만든 결과물을 실제 운영 가능한 제품으로 발전시키기 위해 무엇이 필요한지를 다룬다.

바이브 코딩은 무엇을 바꾸고 있는가

바이브 코딩은 자연어로 원하는 결과를 설명하고, AI가 코드를 작성하거나 수정하도록 하는 개발 방식이다.

예를 들어 사용자는 특정 프로그래밍 언어나 프레임워크의 문법을 직접 작성하지 않고도 다음과 같이 요청할 수 있다.

“사용자가 할 일을 등록하고 완료 상태를 변경할 수 있는 웹 앱을 만들어줘.”

AI는 이 요청을 바탕으로 화면을 구성하고, 데이터를 처리하는 로직을 작성하고, 필요한 파일을 생성한다. 사용자는 결과를 확인한 뒤 “디자인을 바꿔줘”, “로그인 기능을 추가해줘”, “모바일에서도 잘 보이게 수정해줘”와 같이 자연어로 다시 요청할 수 있다.

이 과정은 소프트웨어를 만드는 진입 장벽을 크게 낮췄다.

과거에는 간단한 아이디어를 실제 서비스로 구현하기 위해서도 프로그래밍 언어, 프레임워크, 데이터베이스, 배포 환경을 이해해야 했다. 지금은 이러한 구현 과정의 상당 부분을 AI 에이전트가 대신 수행할 수 있다.

따라서 프로토타입을 만드는 속도는 매우 빨라졌다. 아이디어를 검증하기 위해 몇 주 동안 개발해야 했던 작업을 며칠 또는 몇 시간 안에 시도할 수 있게 됐다.

하지만 이 문서의 핵심은 바이브 코딩의 편리함을 소개하는 데 있지 않다.

오히려 코드 작성이 쉬워졌기 때문에 소프트웨어 개발에서 다른 부분들이 더 중요해지고 있다는 점을 강조한다.

코드 작성 비용이 낮아지면 병목은 다른 곳으로 이동한다

기존의 소프트웨어 개발에서는 구현 자체가 많은 시간과 비용을 차지했다.

요구사항을 정리하고 설계를 마친 뒤에도 실제 코드를 작성하고, 기능을 연결하고, 오류를 수정하는 과정에 상당한 시간이 필요했다.

AI 코딩 에이전트는 이 구현 시간을 크게 줄인다. 정형화된 기능, 반복적인 코드, 화면 구성, 리팩터링, 테스트 코드 작성과 같은 작업은 이미 상당 부분 자동화할 수 있다.

그렇다고 전체 개발 과정이 자동으로 쉬워지는 것은 아니다.

구현 속도가 빨라지면 오히려 다음과 같은 질문이 더 중요해진다.

• 정확히 무엇을 만들어야 하는가
• 이 기능은 어떤 문제를 해결해야 하는가
• 어디까지 구현해야 완료된 것으로 볼 것인가
• 여러 선택지 가운데 어떤 접근 방식이 적절한가
• AI가 만든 결과가 실제 요구사항을 충족하는가
• 빠르게 추가된 코드가 기존 시스템을 깨뜨리지는 않는가
• 프로토타입을 실제 운영 환경에서도 사용할 수 있는가

즉, 기존에는 “코드를 얼마나 빠르고 정확하게 작성할 수 있는가”가 중요한 병목이었다면, AI 시대에는 “무엇을 만들 것인지 정의하고, 생성된 결과를 검증할 수 있는가”가 새로운 병목이 된다.

문서에서 말하는 새로운 SDLC는 기존 개발 단계를 없애는 것이 아니다.

요구사항, 설계, 구현, 테스트, 배포, 운영이라는 기본 단계는 여전히 존재한다. 다만 각 단계의 비중과 진행 방식이 달라진다.

특히 구현 단계가 짧아지는 대신, 계획과 검증 과정의 중요성이 커진다.

프롬프트보다 명세가 중요해진다

바이브 코딩을 이야기할 때 흔히 프롬프트 작성 능력이 중요하다고 말한다.

물론 AI에게 명확하게 지시하는 것은 중요하다. 하지만 규모가 있는 작업에서는 한 번의 좋은 프롬프트만으로 충분하지 않다.

예를 들어 다음과 같은 요청은 간단해 보인다.

“로그인 기능을 만들어줘.”

AI는 이 요청만으로도 로그인 화면과 기본적인 인증 코드를 만들 수 있다. 하지만 실제로 사용할 수 있는 기능을 만들려면 더 많은 조건이 필요하다.

• 이메일과 비밀번호를 사용하는가
• 소셜 로그인을 지원하는가
• 이메일 인증이 필요한가
• 로그인 실패 횟수를 제한하는가
• 비밀번호 재설정은 어떻게 처리하는가
• 사용자 세션은 얼마나 유지하는가
• 탈퇴하거나 정지된 계정은 어떻게 처리하는가
• 관리자와 일반 사용자의 권한은 어떻게 구분하는가

이러한 조건이 정해지지 않으면 AI는 일반적인 방식으로 빈칸을 채운다. 결과는 겉으로는 동작하더라도 실제 목적과 다를 수 있다.

따라서 바이브 코딩이 확산될수록 단순한 프롬프트보다 명세가 중요해진다.

무엇을 만들 것인지뿐 아니라 어떤 조건을 만족해야 하는지, 예외 상황을 어떻게 처리할지, 완료 여부를 무엇으로 판단할지를 구체적으로 정의해야 한다.

좋은 명세는 AI에게 많은 내용을 길게 전달하는 문서만을 의미하지 않는다.

핵심 목표, 사용자 흐름, 제약 조건, 예외 상황, 완료 기준이 서로 모순 없이 정리돼 있어야 한다. AI가 구현 과정에서 판단해야 할 불필요한 빈칸을 줄이는 것이 중요하다.

결국 프롬프트 엔지니어링이 개별 요청을 잘 작성하는 기술이라면, 새로운 SDLC에서는 프로젝트 전체의 기준을 설계하는 Spec Engineering에 가까운 능력이 필요해진다.

계획과 구현의 역할이 분리된다

Anthropic의 Claude Code 연구에서도 사람과 에이전트 사이의 역할 분담이 비교적 뚜렷하게 나타났다.

사람은 주로 무엇을 할지, 어떤 방향으로 진행할지, 무엇을 완료로 볼지를 결정했다. 반면 Claude는 어떤 파일을 수정하고, 어떤 코드를 작성하며, 어떤 명령을 실행할지를 더 많이 결정했다.

Google의 문서가 설명하는 새로운 SDLC도 비슷한 방향을 보여준다.

사람은 점점 구현 세부사항에서 멀어지고, 목표와 제약 조건, 우선순위, 완료 기준을 설정하는 역할을 맡는다. 에이전트는 이러한 기준 안에서 실제 작업을 수행한다.

여기서 중요한 점은 사람이 모든 구현 과정을 직접 통제해야 한다는 뜻이 아니라는 것이다.

오히려 에이전트가 자율적으로 작업할 수 있도록 명확한 작업 범위와 판단 기준을 제공하는 것이 중요하다.

AI가 더 많은 실행 권한을 가질수록 계획의 품질이 결과에 미치는 영향도 커진다. 초기 방향이 잘못되면 에이전트는 잘못된 방향으로도 매우 빠르게 많은 코드를 작성할 수 있기 때문이다.

따라서 AI 시대의 계획은 개발을 시작하기 전에 한 번 작성하고 끝나는 문서가 아니다.

작업 결과를 확인하고, 새롭게 발견된 조건을 반영하고, 다음 작업 범위를 다시 조정하는 반복적인 과정이 된다.

데모가 아니라 평가 가능한 결과가 필요하다

바이브 코딩으로 만든 결과물은 처음에는 상당히 인상적으로 보일 수 있다.

짧은 요청만으로 화면이 만들어지고, 버튼이 동작하며, 데이터가 저장된다. 이전보다 훨씬 빠르게 눈에 보이는 결과를 얻을 수 있다.

하지만 화면이 한 번 정상적으로 보였다는 사실과 실제로 안정적인 소프트웨어가 만들어졌다는 것은 다르다.

데모는 특정한 조건에서 기능이 동작하는 모습을 보여준다. 반면 실제 제품은 여러 사용자, 다양한 입력값, 예외 상황, 네트워크 오류, 권한 문제와 같은 조건에서도 반복적으로 동작해야 한다.

AI는 결과물을 빠르게 생성할 수 있지만, 생성된 결과가 올바른지는 스스로 완벽하게 보장하지 못한다.

그래서 새로운 SDLC에서는 평가, 즉 Eval의 중요성이 커진다.

여기서 평가는 단순히 코드가 실행되는지를 확인하는 것이 아니다.

요구사항을 실제로 충족했는가
주요 사용자 흐름이 정상적으로 작동하는가
잘못된 입력을 적절히 처리하는가
기존 기능이 변경으로 인해 깨지지 않았는가
성능과 보안 기준을 만족하는가
완료 기준을 객관적인 근거로 확인할 수 있는가

이러한 질문에 답할 수 있어야 한다.

특히 “AI가 작업을 완료했다고 말했다”는 것은 충분한 증거가 아니다. 테스트 통과, 빌드 성공, 실제 화면 확인, 로그, 코드 변경 내역과 같이 검증 가능한 결과가 필요하다.

이 점은 Anthropic 연구에서 성공 여부를 판단할 때 테스트 통과, 커밋, Pull Request와 같은 확인 가능한 신호를 사용한 것과도 연결된다.

AI 시대에는 결과물의 양보다 결과를 검증할 수 있는 구조가 더 중요해진다.

테스트는 마지막 확인 단계가 아니라 작업 루프의 중심이 된다

기존 개발에서도 테스트는 중요했다. 하지만 일정이 부족하거나 빠른 출시가 필요한 경우 테스트가 개발 마지막 단계로 밀리는 경우가 많았다.

AI 에이전트를 활용하는 개발에서는 이러한 접근이 더 위험할 수 있다.

AI는 매우 빠른 속도로 여러 파일을 수정할 수 있다. 하나의 기능을 추가하면서 다른 부분을 예상치 못하게 변경할 수도 있고, 이미 존재하는 구조를 충분히 이해하지 못한 상태에서 중복 코드를 만들 수도 있다.

변경 속도가 빨라질수록 사람이 모든 코드를 한 줄씩 검토하는 방식은 한계가 있다.

이때 테스트는 단순한 품질 보증 수단을 넘어 AI의 작업 방향을 제어하는 수단이 된다.

명확한 테스트가 있다면 에이전트는 다음과 같은 반복 작업을 수행할 수 있다.

요구사항 확인 → 코드 작성 → 테스트 실행 → 실패 원인 분석 → 코드 수정 → 테스트 재실행

 

이 과정에서 테스트는 에이전트에게 무엇이 맞고 틀린지를 알려주는 객관적인 기준이 된다.

반대로 테스트가 없다면 에이전트는 자신이 만든 결과가 실제로 올바른지 판단하기 어렵다. 사람 역시 화면을 몇 번 확인하거나 코드 일부를 읽는 정도에 의존하게 된다.

따라서 새로운 SDLC에서는 테스트가 구현 이후에 추가되는 작업이 아니라, 요구사항과 함께 정의되는 것이 이상적이다.

기능을 설명할 때부터 어떤 테스트를 통과해야 완료된 것인지 정해두면, AI는 더 자율적으로 구현과 수정을 반복할 수 있다.

아키텍처의 중요성은 오히려 커진다

AI가 코드를 잘 작성할수록 아키텍처의 중요성이 줄어들 것처럼 보일 수 있다.

하지만 문서는 오히려 반대 방향을 보여준다.

AI는 주어진 구조 안에서 기능을 추가하고 코드를 수정하는 데 강하다. 그러나 시스템 전체가 어떤 구조를 가져야 하는지, 향후 어떤 변화에 대비해야 하는지, 어떤 기술적 트레이드오프를 받아들여야 하는지는 별도의 판단이 필요하다.

특히 바이브 코딩에서는 기능을 빠르게 추가할 수 있기 때문에 초기에는 구조적인 문제가 잘 드러나지 않을 수 있다.

요청할 때마다 새로운 코드가 추가되고, 비슷한 로직이 여러 위치에 생기며, 서로 다른 라이브러리와 패턴이 혼합될 수 있다. 당장은 동작하지만 규모가 커질수록 변경하기 어려운 시스템이 될 수 있다.

이를 흔히 기술 부채라고 부른다.

AI는 코드 생성 비용을 낮추지만, 잘못된 구조 위에 더 많은 코드를 쌓는 비용까지 없애주지는 않는다. 오히려 좋지 않은 구조를 더 빠르게 확장할 가능성도 있다.

따라서 다음과 같은 판단은 여전히 중요하다.

• 시스템을 어떤 단위로 나눌 것인가
• 각 구성 요소의 책임을 어떻게 구분할 것인가
• 데이터는 어디에서 관리할 것인가
• 외부 서비스와의 의존성을 어떻게 통제할 것인가
• 보안과 권한을 어느 계층에서 처리할 것인가
• 프로토타입 코드를 유지할 것인지 다시 설계할 것인지

코드를 작성하는 방법은 AI가 제안할 수 있지만, 이러한 선택이 프로젝트의 목적과 미래에 적합한지는 사람이 판단해야 한다.

문서와 컨텍스트가 AI의 작업 환경이 된다

AI 코딩 에이전트가 프로젝트를 잘 이해하려면 충분한 컨텍스트가 필요하다.

작은 프로젝트에서는 현재 파일 몇 개와 사용자의 요청만으로도 작업할 수 있다. 하지만 프로젝트가 커지면 코드만 읽어서는 모든 의도를 이해하기 어렵다.

왜 특정 기술을 선택했는지, 어떤 기능은 변경하면 안 되는지, 현재 구조에서 어떤 규칙을 따라야 하는지와 같은 정보는 코드에 명확하게 드러나지 않을 수 있다.

이때 README, 요구사항 문서, 아키텍처 문서, ADR, 코딩 규칙, 테스트 케이스, 작업 목록과 같은 자료가 중요해진다.

과거의 문서화는 주로 사람이 프로젝트를 이해하고 인수인계하기 위한 활동으로 여겨졌다.

AI 에이전트 환경에서는 문서가 에이전트에게 프로젝트의 기억을 제공하는 역할도 한다.

예를 들어 프로젝트에 다음과 같은 정보가 정리돼 있다면 에이전트의 작업 품질이 좋아질 수 있다.

• 프로젝트가 해결하려는 문제
• 현재 기술 스택과 선택 이유
• 디렉터리와 모듈의 역할
• 반드시 따라야 하는 개발 규칙
• 수정하면 안 되는 영역
• 주요 사용자 흐름
• 테스트 및 배포 방법
• 알려진 제약사항과 미해결 문제

결국 컨텍스트 관리란 AI에게 한 번에 최대한 많은 정보를 넣는 것이 아니다.

현재 작업에 필요한 정보를 찾기 쉽고, 최신 상태로 유지하며, 서로 모순되지 않게 관리하는 것이다.

에이전트의 컨텍스트 창이 아무리 커지더라도, 정리되지 않은 정보가 많으면 올바른 판단을 내리기 어렵다.

빠른 생성만큼 변경 관리가 중요해진다

AI 에이전트를 사용하면 한 번에 많은 변경을 만들 수 있다.

문제는 변경의 양이 많아질수록 사람이 무엇이 바뀌었는지 이해하기 어려워진다는 것이다.

예전에는 사람이 직접 코드를 작성했기 때문에 작성 과정 자체가 코드에 대한 이해를 만드는 시간이기도 했다. AI가 구현을 맡으면 사용자는 짧은 시간 안에 훨씬 많은 결과물을 받게 된다.

따라서 새로운 SDLC에서는 변경을 작게 나누고, 각 변경의 목적을 명확히 하며, 검토 가능한 단위로 관리하는 것이 중요해진다.

하나의 요청으로 여러 기능과 리팩터링을 동시에 진행하면 문제가 발생했을 때 원인을 찾기 어려워진다.

반대로 작업을 작은 단위로 나누면 다음을 확인하기 쉽다.

• 어떤 요구사항 때문에 변경했는가
• 실제로 어떤 파일이 수정됐는가
• 테스트 결과는 어떠한가
• 예상하지 않은 영향은 없는가
• 문제가 생기면 어느 변경으로 돌아가야 하는가

AI가 빠르게 코드를 만들 수 있다는 이유로 한 번에 많은 작업을 맡기는 것이 항상 효율적인 것은 아니다.

생성 속도가 빨라질수록 작업 범위와 변경 이력을 통제하는 방식이 더 중요해진다.

보안과 운영은 자동으로 해결되지 않는다

바이브 코딩으로 만든 프로토타입은 로컬 환경에서는 정상적으로 동작할 수 있다.

하지만 실제 사용자에게 제공하려면 보안, 개인정보 보호, 모니터링, 장애 대응, 비용 관리, 배포와 같은 운영 문제를 고려해야 한다.

AI가 만들어 준 기능이 동작한다고 해서 다음 항목까지 자동으로 보장되는 것은 아니다.

• 비밀키나 개인정보가 코드에 노출되지 않는가
• 사용자가 접근하면 안 되는 데이터에 접근할 수 없는가
• 외부 패키지에 알려진 취약점은 없는가
• 오류가 발생했을 때 원인을 추적할 수 있는가
• 사용량이 늘어났을 때 비용과 성능을 감당할 수 있는가
• 문제가 발생하면 이전 버전으로 복구할 수 있는가

특히 AI가 외부 라이브러리와 서비스를 빠르게 추가할수록 의존성 관리가 복잡해질 수 있다.

따라서 프로토타입과 운영 가능한 제품 사이에는 여전히 큰 차이가 존재한다.

새로운 SDLC는 AI가 구현한 결과를 그대로 배포하는 과정이 아니라, 빠르게 생성된 결과를 검증하고 안전한 운영 구조 안으로 옮기는 과정까지 포함해야 한다.

바이브 코딩에서 Agentic Engineering으로

문서는 바이브 코딩 자체를 부정하지 않는다.

바이브 코딩은 아이디어를 빠르게 검증하고, 새로운 기능을 실험하고, 반복적인 구현 작업을 줄이는 데 매우 유용하다.

특히 무엇을 만들지 아직 확실하지 않은 초기 단계에서는 완벽한 설계보다 빠른 실험이 더 중요할 수 있다. 이때 AI와 대화하면서 화면과 기능을 만들어 보는 것은 생각을 구체화하는 데 도움이 된다.

다만 프로토타입이 성장하면 접근 방식도 달라져야 한다.

처음에는 자연어 요청과 결과 확인만으로 충분했더라도, 실제 서비스로 발전시키려면 명세, 테스트, 아키텍처, 보안, 변경 관리, 배포와 운영 체계가 필요하다.

이 지점에서 바이브 코딩은 Agentic Engineering으로 발전한다.

Agentic Engineering은 단순히 AI에게 코드를 많이 작성하게 하는 방식이 아니다.

에이전트가 안정적으로 일할 수 있도록 다음을 설계하는 접근에 가깝다.

• 명확한 목표와 작업 범위
• 필요한 프로젝트 컨텍스트
• 확인 가능한 완료 조건
• 자동화된 테스트와 평가
• 작은 단위의 변경과 검토
• 사람의 승인이 필요한 지점
• 실패했을 때 복구할 수 있는 구조

즉, 에이전트의 자율성을 높이면서도 결과의 품질과 책임을 통제할 수 있는 작업 환경을 만드는 것이다.

Anthropic의 연구와 연결해서 보면

Anthropic의 연구와 Google의 문서는 서로 다른 방식으로 비슷한 결론을 보여준다.

Anthropic은 실제 Claude Code 사용 데이터를 분석해 사람이 주로 계획을 결정하고, Claude가 구체적인 실행을 담당하는 경향을 확인했다. 또한 특정 작업에 대한 이해도가 높은 사용자는 더 명확하게 지시하고, 더 많은 검증을 요청하며, 문제가 발생했을 때 에이전트의 방향을 바로잡을 가능성이 높았다.

Google의 문서는 이러한 협업 구조가 SDLC 전체를 어떻게 바꾸는지 설명한다. AI가 구현을 더 많이 담당할수록 사람은 문제 정의, 명세, 아키텍처, 평가 기준과 같은 상위 수준의 판단에 더 집중하게 된다.

두 문서를 함께 보면 AI 시대에 중요해지는 것은 단순한 코딩 능력이나 프롬프트 작성 요령만은 아니라는 점이 보인다.

자신이 해결하려는 문제를 이해하고, 원하는 결과를 구체적으로 표현하고, 생성된 결과가 올바른지 판단하는 능력이 중요하다.

그리고 여기서 말하는 이해는 반드시 최고 수준의 전문성을 의미하지 않는다.

Anthropic의 연구에서도 초보에서 중간 수준으로 이동할 때 가장 큰 성과 차이가 나타났고, 중간 수준과 전문가 사이의 차이는 상대적으로 작았다. 결국 해당 분야를 완전히 마스터해야만 AI를 활용할 수 있는 것은 아니지만, 최소한 문제와 결과를 판단할 수 있을 정도의 이해는 필요하다는 의미로 읽힌다.

함께 살펴보기 좋은 AZTKS Review Skill

이 두 글과 함께 살펴보기 좋은 스킬로 aztks-review-skill이 있다.

현재 수업을 듣고 있는 강사가 작성한 스킬로, Claude Code, Codex, Cursor 같은 에이전트 환경에서 기획서, PRD, SRS, 코드 등의 산출물을 일정한 기준에 따라 검토하도록 구성돼 있다.

https://github.com/wild-mental/aztks-review-skill

GitHub - wild-mental/aztks-review-skill: 알잘딱깔센(AZTKS) 5차원으로 대량 기획서·PRD·SRS·코드를 분량 통

AI에게 결과물을 생성하게 하는 데서 끝나는 것이 아니라, 누락과 모순은 없는지, 근거가 충분한지, 실제 목적에 맞게 작성됐는지를 다시 확인한다는 점에서 이번 문서가 강조하는 평가와 검증의 흐름과 연결해서 보기 좋다. 나도 문서 작성 뒤에 리뷰용으로 좋을 것 같아서 저장해놨는데, 이번 소개글과 잘 연결되는 스킬이라 생

마무리

바이브 코딩은 소프트웨어를 만드는 속도와 접근성을 크게 바꾸고 있다.

하지만 코드 생성이 쉬워졌다고 해서 좋은 소프트웨어가 자동으로 만들어지는 것은 아니다.

오히려 구현 비용이 낮아질수록 다음과 같은 요소들의 중요성이 더 커진다.

• 무엇을 만들지 정의하는 문제 설정
• 요구사항과 완료 조건을 구체화하는 명세
• 시스템 전체를 바라보는 아키텍처
• 에이전트에게 필요한 정보를 제공하는 컨텍스트 관리
• 결과를 객관적으로 확인하는 테스트와 평가
• 변경을 추적하고 되돌릴 수 있는 관리 체계
• 실제 서비스에 필요한 보안과 운영 구조

결국 새로운 SDLC의 핵심은 AI에게 더 많은 코드를 작성하게 하는 것이 아니다.

AI가 올바른 문제를 해결하고 있는지, 생성된 결과를 신뢰할 수 있는지, 그리고 그 결과를 지속적으로 유지하고 개선할 수 있는지를 확인하는 구조를 만드는 것이다.

바이브 코딩이 “말로 소프트웨어를 만드는 방법”을 열었다면, 그다음 과제는 그렇게 만들어진 소프트웨어를 어떻게 책임 있게 관리할 것인가에 있다.

참고 자료

• Google, The New SDLC With Vibe Coding
  https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding
• Anthropic, Agentic Coding and Persistent Returns to Expertise
  https://www.anthropic.com/research/claude-code-expertise
• AZTKS Review Skill
  https://github.com/wild-mental/aztks-review-skill