최근 회사에서 기존 프로젝트의 기능을 수정하고 새로운 기능을 추가하는 업무를 맡았습니다. 특이했던 점은 이 프로젝트가 처음부터 제가 개발한 것이 아니라, 이전 개발자가 AI를 적극 활용해 빠르게 개발한 프로젝트였다는 점입니다.
처음에는 “이미 구현된 프로젝트라면 기능만 조금 수정하면 되겠지.”라고 생각했습니다. 하지만 실제 코드를 살펴본 뒤 예상과는 전혀 다른 상황이라는 것을 알게 되었습니다.
기능은 동작했지만 유지보수는 어려웠습니다.
겉으로 보기에는 서비스가 정상적으로 동작했습니다. 하지만 코드를 하나씩 살펴보면서 여러 문제를 발견했습니다.
가장 먼저 보인 것은 데이터베이스 설계였습니다.
기능을 추가하려고 보니 필요한 컬럼이 없는 테이블이 있었고, 반대로 실제로는 사용하지 않는 구조도 일부 남아 있었습니다. 결국 기능을 구현하기 전에 데이터베이스 구조부터 다시 검토해야 했습니다.
하지만 이미 서비스가 운영 서버에 배포된 상태였기 때문에 단순히 컬럼을 추가하거나 삭제하는 수준으로 접근할 수는 없었습니다.
마이그레이션 과정에서 기존 데이터가 손상되지 않는지 확인해야 했고, 운영 환경에 영향을 주지 않도록 여러 번 검증하며 작업을 진행했습니다.
새로운 기능을 만드는 시간보다 기존 구조를 분석하는 시간이 더 오래 걸렸던 이유도 여기에 있었습니다.
불필요한 코드가 생각보다 많았습니다.
코드를 분석하면서 또 하나 느낀 점은 비슷한 역할을 하는 함수가 여러 개 존재한다는 것이었습니다.
이미 같은 기능을 수행하는 함수가 있는데도 이름만 다른 함수가 추가되어 있었고, 실제로는 호출되지 않는 코드도 남아 있었습니다.
AI가 빠르게 코드를 생성하면서 필요한 기능은 구현했지만, 중복된 코드나 더 이상 사용하지 않는 코드까지 함께 남아 있었던 것입니다.
이러한 구조에서는 새로운 기능을 추가할 때 어떤 코드를 수정해야 하는지 파악하는 데만 상당한 시간이 필요했습니다.
개발 시간은 예상보다 두 배 이상 걸렸습니다.
원래는 며칠이면 끝날 것으로 예상했던 작업이었습니다.
하지만 기존 구조를 분석하고, 데이터베이스를 수정하고, 운영 환경을 고려한 마이그레이션까지 진행하면서 실제 개발 시간은 예상보다 두 배 이상 소요되었습니다.
코드를 작성하는 시간보다 기존 구조를 이해하고 안전하게 수정하는 시간이 훨씬 길었습니다.
이 경험을 통해 ‘빠르게 만드는 것’과 ‘오랫동안 유지할 수 있는 것’은 전혀 다른 문제라는 사실을 다시 한번 느꼈습니다.
바이브 코딩의 문제는 AI가 아닙니다.
이번 경험을 통해 느낀 것은 바이브 코딩 자체가 문제라는 것이 아닙니다.
오히려 AI는 반복적인 코드 작성과 기능 구현에서 매우 뛰어난 도구였습니다.
문제는 설계와 검토 없이 AI가 생성한 결과를 그대로 프로젝트에 반영했을 때 발생했습니다.
프로젝트 구조를 충분히 고민하지 않고 기능을 계속 추가하면 중복 코드가 늘어나고, 데이터베이스 구조도 점점 복잡해집니다.
결국 그 부담은 나중에 유지보수를 하는 개발자가 모두 떠안게 됩니다.
앞으로는 이렇게 개발하려고 합니다.
이번 경험 이후에는 새로운 기능을 구현하기 전에 먼저 프로젝트 구조와 데이터베이스를 검토하는 습관을 가지게 되었습니다.
또한 AI가 생성한 코드도 바로 적용하기보다 불필요한 함수는 없는지, 중복된 로직은 없는지, 향후 유지보수를 고려한 구조인지 먼저 확인하려고 합니다.
AI는 개발 속도를 높여주는 훌륭한 도구입니다.
하지만 프로젝트를 오래 운영해야 한다면 속도보다 중요한 것은 구조와 설계라는 점을 이번 프로젝트를 통해 직접 경험했습니다.
바이브 코딩은 개발을 빠르게 시작하게 해주지만, 그 결과물을 오래 유지할 수 있도록 만드는 책임은 결국 개발자에게 있다는 사실을 다시 한번 느꼈습니다.
