바이브코딩을 위한 넓고 얇은 지식을 시작하며

얼마 전, 누군가가 바이브코딩으로 일을 크게 벌였다. 아이디어는 빨리 나왔고, 화면도 얼추 만들어졌다. 본인 생각에는 이제 거의 다 된 일처럼 보였을 것이다. 그런데 막상 실제로 돌려보니 서비스는 제대로 동작하지 않았다. 서버 코드는 배포가 덜 되어 있었고, 환경변수는 서로 맞지 않았고, 연결돼야 할 것들은 연결되지 않았다. 결국 내게 들어온 요청은 “새로 만들어달라”가 아니라 “이거 왜 안 되는지 좀 봐달라”는 수습 요청이었다.

그 문제는 아주 깊은 연구가 필요한 종류는 아니었다. 인프라를 어느 정도 알고 있었다면 실제로 무엇이 올라갔는지 확인하고, 환경변수를 대조하고, 서비스가 어디서 끊기는지만 보면 비교적 빨리 정리할 수 있는 문제였다. 문제는 기술이 너무 어려워서가 아니었다. 무엇을 확인해야 하는지 몰랐다는 데 있었다.

나는 이 사례가 바이브코딩의 현재를 잘 보여준다고 생각한다. 우리는 예전보다 훨씬 빨리 만들 수 있게 됐다. 화면 하나 띄우고, 기능 하나 붙이고, 백엔드와 프론트를 이어보는 속도는 정말 빨라졌다. 하지만 속도가 붙었다고 해서 목적지까지 저절로 도착하는 건 아니다. 길을 모른 채 차만 빨라진 상태라면, 더 멀리 가기 전에 더 크게 헤매기 쉽다.

이 시리즈 제목을 ‘바이브코딩을 위한 넓고 얇은 지식’이라고 붙인 이유도 여기에 있다. 나는 이 시리즈로 누군가를 전문가로 만들고 싶은 게 아니다. 거대한 튜토리얼을 처음부터 끝까지 밀어 넣고 싶은 것도 아니다. 다만 바이브코딩으로 무언가를 만들고 있는 사람이, 적어도 지금 어디쯤 와 있는지, 어디서부터 확인해야 하는지, 무엇을 아직 모르고 있는지 정도는 분별할 수 있게 돕고 싶다.

여기서 중요한 건 ‘깊이’보다 먼저 ‘지도’다. 무엇을 모르는지 모르는 상태와, 무엇을 모르고 있는지 알고 있는 상태는 큰 차이가 있다. 전자는 막히면 모든 것이 한꺼번에 이상해 보인다. 후자는 적어도 질문을 나눌 수 있다. 이게 배포 문제인지, 서버 문제인지, 환경변수 문제인지, 브라우저에서 벌어지는 일인지, API 호출에서 끊긴 건지부터 가를 수 있다. 그 차이가 결국 완성도와 실현 여부를 가른다.

이 말이 “AI 쓰지 마라”는 뜻은 아니다. 오히려 반대다. 나는 바이브코딩이 아주 강력한 도구라고 생각한다. 예전 같으면 시작도 못 했을 사람이 제품을 만들고, 혼자서도 실험하고, 빠르게 검증할 수 있게 해준다. 다만 강력한 도구일수록, 어디에 쓰고 있는지 아는 최소한의 네비게이션이 더 중요해진다고 생각한다. 망치를 잘 쥐여줬다고 해서 집이 저절로 지어지지 않는 것처럼, AI가 코드를 잘 뽑아준다고 해서 서비스가 자동으로 완성되지는 않는다.

그래서 이 시리즈는 어떤 한 기술을 깊게 파고드는 시리즈가 아니다. 대신 바이브코딩을 하다 자주 부딪히는 주변 개념들을 하나씩 넓고 얇게 훑어보려 한다. 웹페이지는 실제로 무엇으로 이루어져 있는지, 브라우저는 무슨 역할을 하는지, 배포는 왜 생각보다 자주 발목을 잡는지, 도메인과 DNS는 왜 한 번쯤 이해해두면 좋은지, API와 인증과 데이터베이스는 어디에서 문제를 만들기 쉬운지. 그런 것들을 “지금 당장 다 외워야 하는 지식”이 아니라, “막혔을 때 어디서부터 확인할지 알려주는 지도”로 정리해보려고 한다.

이 시리즈가 약속하는 것도 그 정도다. 이 글들을 다 읽는다고 갑자기 인프라 전문가가 되지는 않을 것이다. 하지만 적어도 어디서부터 확인해야 할지는 알게 될 것이다. 그리고 같은 노력을 들이더라도, 조금은 더 나은 품질의 결과물을 만들 가능성은 높아질 것이다. 바이브코딩의 속도를 버리지 않으면서도, 그 결과물을 끝까지 데려가는 확률을 높이는 것. 나는 그 정도면 꽤 괜찮은 변화라고 생각한다.

다음 글에서는 웹페이지를 이루는 가장 기본적인 세 층, HTML과 CSS, Javascript를 아주 넓고 얇게 훑어보려 한다. 문법을 배우는 글은 아니다. 대신 내가 지금 보고 있는 화면이 어떤 층으로 이루어져 있는지, 그래서 문제가 생겼을 때 어디부터 의심하면 되는지 큰 그림부터 같이 잡아보려 한다.