AI 코딩 워크플로: 바이브 코딩 대신 계획·검토 중심 개발법

핵심 메시지

• AI를 즉흥적으로 시키는 “바이브 코딩”이 아니라, 무엇을 어떻게 만들지 먼저 정한 뒤 AI에 위임하는 방식을 권한다.
• 복잡한 작업은 항상 계획부터 시작한다. 커서의 플랜 모드처럼 AI에게 먼저 마크다운 형태의 작업 계획을 만들게 하고 그 계획을 검토한다.
• AI는 대체자가 아니라 보조자로 다루며, 생성된 계획과 코드를 사람이 직접 검토하는 단계가 핵심이다.
• AI 코드는 첫 시도에 완벽하지 않다. 다만 90% 수준까지 끌어올려 주므로 충분한 시간 절약 가치가 있다.

쉽게 이해하기

영상은 .NET 애플리케이션을 개발할 때 AI 도구(주로 커서 IDE)를 어떻게 쓰는지에 대한 발표자의 개인 워크플로를 다룬다. 발표자는 도구 자체보다 “AI와 상호작용하는 방식”이 더 중요하다고 강조하며, IDE든 CLI든 같은 원칙이 적용된다고 말한다.

발표자는 두 가지 전제를 둔다. 첫째, 무엇을 만들지와 충분한 시간이 주어졌을 때 어떻게 도달할지를 개발자가 이미 알고 있어야 한다. 둘째, AI를 사람을 대체하는 존재가 아니라 보조자로 취급한다. 이 전제 위에서 그는 단일 파일보다 복잡한 작업은 항상 “계획”에서 시작한다고 설명한다.

실제 예시로, 그는 할 일(To-do) 앱의 쿼리를 EF Core에서 Dapper 기반 원시 SQL로 마이그레이션하는 작업을 보여준다. 커서의 플랜 모드에 구체적인 요구사항(특정 인터페이스 사용, 커맨드 핸들러는 건드리지 말 것 등)을 전달하면, AI가 코드베이스를 스캔해 마크다운 형태의 계획 문서를 먼저 생성한다. 이 계획은 어떤 AI 도구로도 만들 수 있는 일반적인 산출물이라고 짚는다.

계획을 검토해 만족하면 빌드를 눌러 코드를 생성하게 하고, 그다음 생성된 코드를 한 줄씩 검토한다. 발표자는 불필요한 NuGet 패키지 제거, 연결 팩토리를 싱글톤으로 변경, 라이브러리의 최신 권장 방식과 다른 부분 수정 등 경험에 기반한 교정 사례를 보여준다. AI가 기존 코드로 학습되어 항상 최신 모범 사례를 반영하지는 않는다는 점이 코드 검토가 필요한 이유다.

마지막으로 그는 테스트 작성(가능하면 실제 DB를 쓰는 통합 테스트)과 실제 실행·검증을 강조한다. AI는 첫 시도에 완벽하지 않지만 약 90%까지 끌어준다는 것이 그의 결론이며, 주니어 개발자가 AI에만 의존하면 어렵게 배워야 할 교훈을 놓칠 수 있다는 우려도 함께 남긴다.

주요 인사이트

• “계획을 먼저 만들게 하고 검토한다”는 절차는 평소 사람이 직접 개발할 때의 흐름(계획 → 작은 단계로 분해 → 하나씩 구현)을 AI에 그대로 위임하는 것이다.
• AI에게 요구할 때는 모호하게 던지지 말고 사용할 인터페이스, 건드리지 말 영역, 패키지 관리 방식 등을 구체적으로 지정해야 의도대로 결과가 나온다.
• 원시 SQL처럼 정확성이 중요한 코드는 인메모리 DB가 아니라 실제 DB 인스턴스로 검증해야 미묘한 버그를 막을 수 있다.
• AI가 만든 코드를 “맞겠지”라고 가정하는 태도가 가장 큰 실수의 원천이며, 실제 빌드·실행으로 확인하는 습관이 필요하다.

자주 묻는 질문

관련 AI 소식