2개월간의 바이브 코딩, 이제 코딩은 병목 현상이 아니다

AI로 무언가를 만드는 데 있어 가장 어려운 부분이 프롬프팅일 거라 생각했다. 하지만 알고 보니 훨씬 지루한 문제였다. 바로 자신이 실제로 무엇을 원하는지 결정하는 것이다.

지난 한 달 반 동안 나는 Atoms를 사용해 작은 운영 도구를 만들고 있었다. 사용자 로그인, 역할, 데이터베이스, 관리자 페이지, 결제 규칙, 몇 개의 SEO 페이지 등, 평범하게 시작했다가 어느새 실제 제품이 되어버린 상황이었다. 나는 기술적인 부분에서 실력 차이가 날 것이라 생각했다. 더 나은 프롬프트, 더 나은 모델 선택, 더 나은 도구 전환 같은 것들 말이다. 다른 도구들도 사용해 봤다. 더 직접적인 코딩을 위해 Claude Code를, 더 깔끔한 UI를 위해 Lovable을 썼다. 하지만 Atoms는 내가 회피해왔던 무언가를 직면하게 만든 첫 번째 도구였다.

대부분의 AI 도구는 당신이 생각보다 더 오랫동안 모호한 상태로 머물게 해준다. Atoms는 더 엔드 투 엔드(end to end) 방식이라 모호함이 빠르게 비용으로 돌아온다. 만약 내가 '온보딩을 더 좋게 만들어줘'라고 말하면, 그것은 단순한 UI 수정이 아니었다. 권한, 데이터 구조, 사용자가 처음 보는 것, 저장되는 데이터, 트리거되는 이메일, 유료 티켓에서 해제되는 기능 등 모든 것에 영향을 미쳤다. 그 한 문장이 조용히 결제 로직, 계정 상태, 접근 제어, 그리고 고객 지원의 골칫거리로 변할 수 있었다.

일주일 동안 엉망인 결과물을 얻은 후, 나는 더 나은 프롬프트를 짜는 것을 멈추고 훨씬 덜 재미있는 일을 시작했다. 프롬프트가 아니라 규칙을 적었다. 실제 제품 규칙들이다: 이건 누구를 위한 것인가? 가입 직후에 무슨 일이 일어나는가? 어떤 데이터가 정말로 필요한가? 유료 사용자는 무료 사용자와 무엇이 다른가? 절대 자동으로 변경되어서는 안 되는 것은 무엇인가?

이러한 제약 조건이 명확해지자 Atoms는 극적으로 좋아졌다. 리서치 측면이 더 유용해졌고, 백엔드는 더 이상 무작위로 느껴지지 않았다. 수정 사항은 더 작고 안정적으로 변했다. SEO 관련 작업조차 더 이해가 잘 되었다. 내가 모호하게 콘텐츠를 요청하는 대신 실제 제품 구조에 기반했기 때문이다.

가장 가치 있는 기술은 코딩도, 프롬프팅도 아니었다. 바로 제품에 대한 명확성이었다. 그래서 많은 사람이 이런 도구를 좋아하거나 혹은 금방 포기하는 것 같다. 이미 의사결정 방법을 알고 있다면 이 도구들은 엄청나게 강력하게 느껴진다. 만약 도구가 당신을 대신해 결정해주길 바란다면, 잠시 동안은 가능할지 몰라도 결국 한계가 드러날 것이다.

이 사실이 나를 더 낙관적으로 만들었다. 개발자라는 직업이 사라지는 것이 아니라는 뜻이기 때문이다. 그저 변화하고 있을 뿐이다. '이걸 코딩할 수 있는가'보다는 '기계가 움직이기 전에 무엇이 좋은 결과물인지 정의할 수 있는가'가 더 중요해졌다.

다른 의견들도 환영한다.