소프트웨어 개발에서 가장 큰 문제는 요구사항이 정확히 프로그램으로 이어지지 않는 것이다.

즉, 같은 요구사항이라도 사람마다 다르게 이해하고, 결과물은 더 달라질 수 있다.
바이브코딩은 요구사항을 대략 설명하고 AI에게 코드를 만들게 하는 방식이다.
하지만 다음과 같은 문제가 생긴다.
즉, 처음에는 결과가 빨리 나오는 것처럼 보이지만 나중에는 유지보수와 확장이 어려워진다.
복잡성(complexity)이란 소프트웨어 시스템의 구조와 관련된 것들 중, 그 시스템을 이해하고 수정하는 일을 어렵게 만드는 모든 것이다.”
AI가 잘못된 결과를 만들었을 때 단순히 토큰을 더 쓰거나 다시 시키는 방식은 근본적인 해결책이 아니다.
AI가 만든 코드는 중복이 많아질 수 있다.
중복이 많아지면 다음 문제가 생긴다.
그래서 단순히 “작동하는 코드”보다
좋은 코드베이스가 더 중요하다.
강의 핵심 문장:
코딩은 싸졌다?
코드는 싸졌다 X
좋은 코드베이스는 더 가치가 높아졌다 O
AI 때문에 코드를 생성하는 비용은 낮아졌다.
하지만 좋은 구조, 유지보수성, 확장성, 일관성을 가진 코드베이스의 가치는 오히려 더 높아졌다.
AI가 코드를 만들어줄 수 있어도 다음 요소들은 여전히 중요하다.
AI는 코드를 생성할 수 있지만,
전체 구조를 책임지고 판단하는 것은 개발자의 역할이다.
좋은 소프트웨어 설계를 위해서는 다음을 고려해야 한다.
모듈끼리 얼마나 강하게 연결되어 있는지를 의미한다.
하나의 모듈이 하나의 책임에 얼마나 집중하는지를 의미한다.
좋은 설계는
낮은 결합도 + 높은 응집도를 목표로 한다.
AI에게 단순히 “만들어줘”라고만 하면
처음에는 결과가 나올 수 있다.


하지만 구조 없이 계속 기능을 추가하면 다음 문제가 생긴다.
따라서 AI에게 코딩을 맡기더라도 먼저 구조와 설계 원칙을 정해야 한다.

AI 코딩을 할 때는 다음 원칙이 필요하다.
한 번에 전체 시스템을 만들게 하지 말고
작은 기능 단위로 나누어 요청해야 한다.
프로젝트에서 사용하는 용어를 명확히 해야 한다.
예를 들어 DDD에서는 Ubiquitous Language가 중요하다.
이는 개발자와 사용자, 기획자가 같은 용어를 사용하도록 하는 것이다.
AI에게 바로 코딩을 시키기보다 다음을 먼저 정리해야 한다.
AI에게 모든 것을 한 번에 맡기면
개발자가 구조를 이해하지 못하게 된다.
결국 AI가 만든 코드를 사람이 통제하지 못하는 상황이 생긴다.
강의에서는 “너무 급해”라는 표현이 나온다.
이는 빠르게 결과물을 만들려는 태도가
오히려 장기적으로 문제를 만든다는 의미이다.
특히 한국식 개발 문화에서는
선행 작업보다 빠른 구현을 우선하는 경향이 있다.
하지만 요구사항 분석과 설계를 건너뛰면
나중에 더 큰 비용을 치르게 된다.
Peter Drucker의 말:
Efficiency is doing things right.
Effectiveness is doing the right things.
일을 효율적으로 하는 것
즉, 빠르고 적은 비용으로 수행하는 것.
올바른 일을 하는 것
즉, 진짜 필요한 문제를 해결하는 것.
AI 코딩은 효율성은 높일 수 있다.
하지만 올바른 방향으로 개발하고 있는지는 사람이 판단해야 한다.
AI 시대에 개발자는 단순히 코드를 읽고 수정하는
“인간 컴파일러”가 되어서는 안 된다.
필요한 것은 전략적 엔지니어이다.
전략적 엔지니어는 다음을 이해해야 한다.
강의에서는 다음 질문이 나온다.
계산기가 계산하는데, 코딩의 자세한 면을 알아야 하나요?
프롬프팅만 잘하면 그만이지 않나요?
이에 대한 답은 “아니다”이다.
계산기가 있어도 수학적 개념을 알아야 하듯이,
AI가 코딩해도 개발자는 코드와 구조를 이해해야 한다.
프롬프트만 잘 쓰는 것으로는
복잡한 소프트웨어를 안정적으로 만들 수 없다.
AI에게 풀스택 개발 경험을 모두 위임하면
개발자는 코드 작성 경험을 잃게 될 수 있다.
그러면 단기적으로는 효율적일 수 있지만
장기적으로는 전략적 엔지니어링 능력이 약해진다.
결국 개발 조직 자체가 흔들릴 수 있다.
AI 코딩 시대의 핵심은
“AI가 코드를 짜주니까 개발자가 필요 없다”가 아니다.
오히려 개발자는 더 깊고 넓은 지식을 가져야 한다.
중요한 것은 다음과 같다.
결론적으로,
AI는 개발을 도와주는 도구이지만
좋은 소프트웨어를 만드는 책임은 여전히 개발자에게 있다.
SPDD는 Structured Prompt-Driven Development의 약자로, 구조화된 프롬프트 기반 개발을 의미한다.
AI에게 단순히 “코드 짜줘”라고 요청하는 것이 아니라, 요구사항과 분석 내용을 먼저 정리하고, 이를 바탕으로 구조화된 프롬프트를 만들어 코드를 생성하는 개발 방식이다.
즉, SPDD는 AI 코딩을 즉흥적인 바이브코딩이 아니라 체계적인 소프트웨어 개발 프로세스 안에서 활용하는 방법이다.
요구사항을 대략 설명하고 AI에게 바로 코드를 생성하게 하는 방식이다.
빠르게 결과를 얻을 수 있지만, 요구사항이 불명확하거나 구조가 부족하면 유지보수와 확장이 어려워질 수 있다.
요구사항, 분석, 설계, 프롬프트를 구조화한 뒤 AI를 활용하는 방식이다.
초반에는 시간이 더 걸리지만, 코드의 일관성, 추적 가능성, 테스트 가능성, 유지보수성이 높아진다.
SPDD는 AI에게 코드를 대신 쓰게 하는 기술이 아니라, AI가 따라야 할 요구사항과 설계 기준을 명확히 만들어주는 개발 방식이다.
따라서 AI 코딩 시대에도 요구사항 분석, 설계, 테스트, 검토 같은 소프트웨어공학 지식이 여전히 중요하다.
AI 코딩 도구를 사용하면 빠르게 앱의 초기 형태, 즉 MVP를 만들 수 있다.
하지만 MVP가 만들어졌다고 해서 실제 운영 가능한 서비스가 완성된 것은 아니다.
실제 서비스에는 코드 작성 외에도 보안, 테스트, 배포, 로그, 장애 대응, 확장성, 데이터 무결성, 권한 관리, 비용 관리 등 많은 요소가 필요하다.
CodeRabbit 분석에 따르면 AI-generated code는 다음과 같은 문제를 더 많이 유발할 수 있다.
AI가 코드를 많이 생성할수록 사람이 직접 리뷰해야 할 코드도 많아진다.
하지만 생성되는 코드의 양이 사람이 현실적으로 리뷰할 수 있는 속도보다 빠르게 증가하면 품질 관리가 어려워진다.
따라서 AI가 만든 코드를 다시 AI에게만 리뷰시키는 방식이 항상 안전한지는 의문이다.
바이브코딩은 종종 “일단 앱을 만들어줘. 나중에 확인할게.”라는 방식으로 진행된다.
이 방식은 초기 결과물을 빠르게 얻을 수 있다는 장점이 있지만, 다음과 같은 위험이 있다.
즉, 빠르게 만든 코드가 반드시 좋은 코드나 운영 가능한 코드를 의미하지는 않는다.
개발 업무는 겉으로 보기에는 완료된 것처럼 보여도, 실제로는 많은 숨은 작업이 존재한다.
예를 들어 다음과 같은 일이 남아 있을 수 있다.
따라서 관리자는 단순히 “다 끝났나요?”라고 묻는 것보다
“어디에서 막혔나요?”, “협업 과정에서 병목이 있나요?”라고 물어야 한다.
바이브코더는 풀스택을 단순히 프론트엔드와 백엔드 정도로 생각할 수 있다.
하지만 실제 운영 환경의 풀스택은 훨씬 복잡하다.
실제 서비스에는 다음 요소들이 필요하다.
즉, 실제 풀스택 개발은 단순히 화면과 서버를 만드는 것이 아니라,
서비스가 안정적으로 운영될 수 있도록 전체 시스템을 설계하고 관리하는 것이다.
AI 코딩으로 빠르게 만든 앱은 MVP 수준일 수 있다.
MVP는 아이디어를 검증하기 위한 최소 기능 제품이다.
반면 Production Ready 앱은 실제 사용자에게 안정적으로 제공할 수 있는 운영 가능한 서비스이다.
Production Ready 앱에는 다음과 같은 요소가 필요하다.
따라서 MVP를 만드는 것과 Production Ready 서비스를 만드는 것은 완전히 다른 수준의 작업이다.
바이브코딩은 빠르게 결과물을 만드는 데에는 유용하다.
하지만 실제 서비스 운영에는 보이지 않는 복잡한 요소들이 많다.
AI가 코드를 생성해도 개발자는 다음을 판단해야 한다.
결론적으로 AI 코딩은 개발을 빠르게 도와주는 도구이지만,
좋은 소프트웨어를 만들기 위해서는 여전히 소프트웨어공학적 사고와 운영 관점이 필요하다.