모래 위의 화려한 유리 궁전, 바이브 코딩

오랜만에 코딩 이야기를 하고자 합니다.
바로 '바이브 코딩' 이야기인데요.

바이브 코딩을 개인적으로 2년 가까이 연습해본 개발자로서 '코딩이나 IT 지식 없이 말로만 코딩하는 것'의 위험성을 충분히 느끼고 내린 결론은 "AI를 이용하더라도 코딩지식, IT지식은 여전히 익혀야 한다"는 것입니다.

말로만 코딩하면 마치 마법같이 멋진 결과물을 뚝딱 만들어내는 매력, 저도 충분히 경험해 보았는데요.
수준 높은 기술, 전에는 자료가 없어서 구현조차 어려웠던 기술조차도 바이브 코딩으로 알아낼 수도 있습니다.
그런데 그 멋진 결과물이 암반이 튼튼한 곳에 지어진 집이 아니라, '모래 위에 지어진 집'이라는 사실, 알고 계신가요?

아니 집은 그저 평범한 수준에 불과하지요.
화려한 유리 궁전에 비교할 법 합니다. 그만큼 화려한 결과물을 뽑아낼 수가 있습니다.

그런데 이러한 집이 날씨가 평온할 때면 그저 아름답게 빛납니다.
더할 나위 없이 말이지요.
하지만 항상 날씨가 평온하기만 하지는 않습니다.
비바람이 불어 닥치면 반석 위에 지은 집은 무너지지 않습니다. 그 토대가 튼튼하기 때문이지요.
하지만 모래 위에 지은 집은 지반이 든든하지 못해 모래가 꺼지면서 함께 무너지게 되어 있습니다.
어디를 수선해야 할지도 모른 채로 말이지요.

그것이 바이브 코딩과 같다고 생각합니다.

모든 개발산출물은 한번 만든다고 끝나는게 아닙니다.
운영하면서 안정화 단계, 사용자의 요구 수렴 등을 반영하기 위해 끝없이 업그레이드, 유지보수가 감행되어야 하지요.
초기 개발이 30%라면, 유지보수는 70%에 비유할 수 있습니다.
그만큼 유지보수의 비중이 더 크다고 볼 수 있는데요.

이런 말 들어 보셨을 겁니다.
"바이브 코딩 천국, 바이브 디버깅 지옥"

AI는 MVP 수준의 프로토 타입은 꽤 잘 만듭니다.
개인 취미용으로 1인용 앱을 만든다면 사용 목적에 꽤 적합합니다.

그런데.. 이 프로토 타입을 다른 사람도 사용 가능하도록 서비스를 하는 것은 다른 문제입니다.
바로 운영과 유지보수의 영역이 필요하거든요. 그것도 아주 많이.

이를테면 사용자가 많아져 사용자가 100명이 되니 갑자기 작동이 되지 않는다거나,
처음에는 정수로 정산을 하도록 하는 걸 만들었는데 소숫점으로 바꿔야 해 AI에게 고쳐달라고 했는데 갑자기 모든 고객 데이터가 삭제되는 대형사고도 발생할 수 있습니다.

이러한 것이 바로 비바람에 비유할 수 있습니다.
애초에 탄탄한 설계나 프로젝트에 대한 코딩/IT지식 없이 만들어졌기 때문입니다.
어떤게 위험하고 복잡한 작업인지, 안전장치는 어떻게 마련해야 사고가 안 나는지 등은 '코딩/IT지식' 없이는 절대로 불가합니다.

바이브 코딩의 창시자 '안드레 카파시'는 OPENAI의 창립 멤버입니다.
프로그래머가 직접 코딩하던 전통적 방식에서 데이터 신경망 최적화를 통해 코드를 생성하는 패러다임의 전환을 성공적으로 이끌어낸 인물인데요.
'영어가 새로운 코드 언어이다' 라는 말로 특히 유명합니다.
그냥 간단히 AI계의 괴물이자 천재라 표현해도 될 법합니다.

그런데 문제가 있었습니다.
안드레 카파시의 천재성은 비개발자의 코딩 영역, IT지식에의 문외함을 전혀 몰랐던 것입니다.
모든 사람들이 오류가 나면 이러 이러한 것을 수정해달라고 정확한 문제점을 파악하고 요구할 수 있는 개발자  수준으로 생각했던 것이지요.

그러니 '디버깅이 지옥'일 수 밖에요.
감당할 수 없는 유리 궁전을 만들어 놓고 이를 수선하려고 해도 AI에게 이 곳이 문제니 고쳐달라고 할 수가 없기 때문입니다. 뭐가 문제인지 원인을 모르거든요.
그제서야 어떻게든 고쳐보려고 AI가 만든 코드를 이리 저리 들여다 보고 어떤게 문제인지 알아내기 위해 '학습'을 시작합니다. 쌓였던 기술 부채를 일부라도 이해하지 않고서는 고칠수가 없으니까요.

바이브 코딩 창시자 안드레 카파시의 후기 의견은 아래와 같습니다.
초기 '코드를 들여다보지도 않아도 된다'는 표현은 과장이며,
실제 라이브 단계에서는 여전히 코드를 읽고 검증하는 과정이 필수적이라고 밝혔습니다.
작성 속도는 극적으로 빨라지지만, 시스템이 커질수록 AI가 만든 코드를 사람이 읽고 리뷰(Code Review)하는 능력이 오히려 더 중요해진다고 보았습니다.

"바이브 코딩은 개발자를 대체하는 마법이 아니라, 개발자가 엔지니어링의 본질(설계, 구조, 검증)에 집중하게 만드는 강력한 레버리지"라는 의견이 결국 안드레 카파시의 결론입니다.

IT계열의 서비스를 개발하고 운영하는데에는 많은 코딩 / IT 계열의 도메인 지식이 필요합니다.
기본적으로 개발 산출물은 "유지 보수가 용이하도록 개발"되어야 합니다.
그리고 "개발환경"과 "프로덕션" 환경을 분리하여 개발환경에서의 개발 후 프로덕션에 적용하는 것이 안전합니다.
그 과정에 위험성이 높은 변경 작업은 사전 모든 영역에서의 검토가 충분히 이루어져야 하고,
코딩에 없는 시스템에 적용된 자동화에 대해서도 파악, 수정이 필요합니다.
만일 외부 시스템과 연결되는 부분이 있다면 함부로 변경해도 되는 것인지에 대한 사전 파악 또한 이루어져야지요. 이러한 경우 '변경을 포기'하는 것이 가장 합리적입니다.

더 나아가서는 시스템이 커질 경우 작동이 극도로 느려질 위험에 대해,
시스템 부하가 적게 가는 구조를 설계하고 변경하는 방법에 대해서도 익혀야 합니다.
나열하자면 수도 없이 많습니다만, 그러한 모든 지식들은 필요시마다 하나씩 익혀야 하는 것이지요.

결론은 서비스가 필요한 개발, 규모가 점점 커질수밖에 없는 개발은 여전히 개발자가 중요합니다.
내가 개발자가 되어서라도 말이지요.

요새 AI소설, AI카툰 등을 실험적으로 시도해보고 있는데요.
이 또한 마찬가지더라구요.
짧은 단편의 이야기는 AI가 멋지게 잘 써줍니다.
하지만 스토리가 길어지는 장편이 되면 이야기가 달라집니다.
스토리 초기에 깔아놓은 복선은 다 잊어버리고 회수할 생각없이 끝을 내버리거나,
추억의 이야기조차도 엉뚱한 내용으로 조작해 버립니다.
새로운 세션에서 시작하지 않았더라도 말이지요.

그래서 방향성을 잡아 주지 않으면 안되겠더라구요.

"너 이 이야기 까먹은거야? 과거 스토리 반영해서 이번 화 다시 작성해줘"

첨부파일을 첨부해서 이런식으로 말입니다 :)

결론은 AI로 소설을 쓰려면 모든 스토리를 사람 작가가 기억하고
AI가 딴 길로 새지 않도록 계속해서 이끌어 주어야 하지요.
코딩과도 같은 맥락입니다.이것이 아직 AI 기술의 현주소입니다.
코딩, 여전히 필요하고 배워볼 만하다는 사실.

---

성경 말씀 공유드립니다.
오늘 내용에도 모티브가 되는 말씀인데요.
지혜의 성경 말씀, 읽어보셨으면 좋겠습니다 :)

"그러므로 누구든지 나의 이 말을 듣고 행하는 자는 그 집을 반석 위에 지은 지혜로운 사람 같으리니
비가 내리고 창수가 나고 바람이 불어 그 집에 부딪치되 무너지지 아니하나니 이는 주추를 반석 위에 놓은 까닭이요 나의 이 말을 듣고 행하지 아니하는 자는 그 집을 모래 위에 지은 어리석은 사람 같으리니
비가 내리고 창수가 나고 바람이 불어 그 집에 부딪치매 무너져 그 무너짐이 심하니라"

- 마태복음 7장 24~27절 -