바이브 코딩으로 자동화를 해결하는 내 방식

13년 동안 C, C++, C#, Python을 만지며 일했습니다. 그런 제가 요즘 자동화 작업의 상당 부분을 정식 설계 문서 없이, AI와 대화하며 코드를 만드는 이른바 “바이브 코딩”으로 처리합니다. 이 글은 그 방식에 대한 제 솔직한 관점입니다.

왜 정식 설계부터 하지 않게 됐나

오래 개발한 사람일수록 “일단 설계부터”라는 습관이 몸에 배어 있습니다. 저도 그랬습니다. 그런데 혼자 쓰는 자동화 스크립트나 반복 작업 도구에서는, 설계 문서를 갖추는 비용이 결과물보다 커지는 경우가 잦았습니다.

자동화는 대개 “이 작업을 손으로 안 하고 싶다”는 작은 목적에서 출발합니다. 목적이 좁고 명확할 때는 거창한 구조보다, 대화하며 빠르게 한 번 돌려보는 쪽이 답에 더 빨리 닿습니다. 물론 여러 사람이 오래 유지할 코드라면 이야기가 다릅니다. 저는 그 경계를 의식적으로 나눠 둡니다.

제 기준은 단순합니다. 혼자 쓰고 언제든 버릴 수 있는 자동화면 Codex와 대화하며 바로 만들고, 남이 이어받거나 오래 돌려야 하는 거면 그때만 설계를 챙깁니다. n8n으로 짜는 개인 워크플로우 대부분은 전자라, 설계 문서 없이 대화로 풉니다.

내가 대화하며 코드를 만드는 흐름

제 방식은 단순합니다. 먼저 “무엇을, 어떤 입력으로, 어떤 결과로” 만들고 싶은지 한두 문장으로 정리합니다. 그다음 그걸 그대로 AI에게 말하듯 던지고, 나온 코드를 바로 돌려 봅니다. 안 되면 에러나 어색한 부분을 다시 말로 설명하고 고쳐 나갑니다.

핵심은 한 번에 완성하려 하지 않는다는 점입니다. 작은 덩어리를 돌려 보고, 눈으로 확인하고, 다음 덩어리로 넘어갑니다. 13년치 경험은 코드를 처음부터 다 쓰는 데 쓰이지 않고, 나온 코드가 위험한지 아닌지를 판단하는 데 쓰입니다.

엔지니어 경험이 사라지는 게 아니다

요즘 자주 보이는 오해가 “바이브 코딩이면 개발 지식이 필요 없다”는 말입니다. 제 생각은 조금 다릅니다. 오히려 코드를 읽고 의심할 줄 아는 능력이 그대로 살아 있어야, AI가 만든 결과물을 믿을지 말지 결정할 수 있습니다.

저에게 이 방식은 실력을 내려놓는 게 아니라, 실력을 쓰는 자리를 옮긴 것에 가깝습니다. 타이핑은 줄었지만 판단은 줄지 않았습니다.

정리하며

바이브 코딩은 만능이 아닙니다. 다만 목적이 좁고 빠른 확인이 중요한 자동화에서는, 저처럼 오래 코드를 만진 사람에게도 충분히 합리적인 선택일 수 있습니다. 도구가 코드를 대신 써 주는 시대에, 남는 일은 결국 “이게 맞는지 판단하는 일”이라고 봅니다.