바이브코딩(Vibe Coding)은
나에게 새로운 개발 방법론이라기보다
이미 사용하고 있던 작업 방식을 설명해주는 이름에 가깝다.
나는 전문 개발자는 아니다.
하지만 오래전부터 컴퓨터를 사용해왔고,
필요할 때마다 도구를 익혀 문제를 해결하는 방식으로 일해왔다.
최근 AI 도구를 활용해 코드를 생성하고 자동화를 시도하면서,
하나의 공통된 문제가 반복해서 드러났다.
문제는 코드를 “잘 만드는가”가 아니었다.
또한 어떤 AI가 더 똑똑한가의 문제도 아니었다.
실제 병목은
작업을 중단했다가 다시 이어갈 수 있는가,
그리고
같은 판단을 다시 설명하지 않아도 되는 구조인가에 있었다.
바이브코딩은
모든 것을 이해한 뒤 시작하는 방식이 아니다.
대신,
불완전한 이해 상태에서도 실행해보고
실패를 전제로 구조를 조정하는 방식에 가깝다.
이 과정에서 나는
AI를 “답변 도구”로 쓰는 단계와
AI를 “작업 흐름의 일부”로 다루는 단계가
명확히 다르다는 점을 체감하게 되었다.
이 블로그에는
완성된 서비스나 화려한 결과물보다,
다음과 같은 주제들을 정리해 나갈 예정이다.
- AI로 생성한 코드를 어떻게 선택하고 폐기했는지
- 자동화가 늘어날수록 관리 비용이 커졌던 이유
- 기억하지 못하는 도구가 왜 반복 비용을 발생시키는지
- 판단과 실행을 분리했을 때 구조가 어떻게 바뀌는지
- MCP(Model Context Protocol)라는 개념이
왜 운영 관점에서 의미를 갖게 되었는지
이 글은
바이브코딩으로 무엇을 “잘 만들었다”는 기록이 아니라,
바이브코딩을 통해
어떻게 작업을 지속 가능하게 만들 수 있을지를 고민한 과정에 대한 기록이다.
