코드와 씨름하며 가능성과 한계를 동시에 보다.
올해 상반기, 가벼운 마음으로 참가한 해커톤에서 예상치 못한 경험을 했습니다.
몇 년 전만 해도 해커톤은 개발·디자인·기획이 잘 맞는 사람들이 며칠 밤을 새우며 프로덕트를 만들어 시연하는, 일종의 형식이 있다고 생각했는데 AI 개발 도구가 고도화된 지금은 그 풍경이 완전히 바뀌어 있었습니다.
여느 때처럼 화면을 열심히 만들고 있었는데, 개발자들이 제가 만든 UI를 그냥 캡처해 가져가 바로 구현하는 장면을 보게 됐습니다. 프로덕 완성도보다 컨셉과 스피드가 중요한 해커톤의 특성상, 이 방식이 너무나 잘 들어맞았습니다. 몇 줄의 자연어 프롬프트만 넣어도 ‘뚝딱’ 프론트가 구현되는 모습을 보면서, “나도 직접 해보고 싶다”는 생각이 들었고, 곧바로 바이브 코딩에 입문했습니다.
지금까지 바이브 코딩으로 다음 두가지 서비스를 만들어보았습니다.
AI UX Writing Assistant 피그마 플러그인
To-do 앱
피그마 플러그인은 비교적 단순한 개발 구조라, 바이브 코딩으로 원하는 디자인 수준까지 끌어올리는 방법을 익히는 데 적합했습니다. 반면 To-do 앱은 데이터베이스를 다뤄야 했기 때문에, 더 큰 구조를 이해하는 경험을 할 수 있었습니다.
두 작업 모두 서비스를 구현하면서, “내가 개발한게 진짜 작동을 하네? 이게 되네?”하는 묘한 기쁨이 있었습니다.
이 사진이 제가 처음 투두 앱을 만들면서 느꼈던 감정에 가장 가까운 것 같습니다.
처음에는 Node.js, Vue, PostgressSQL 같은 기술 스택 이름만 봐도 위압감이 들었고, 데이터가 어떻게 흘러가는지, 서비스가 어떤 구조로 구성되는지 감이 부족하다는 걸 느꼈습니다.
(혹시 주변에 개발을 처음 시작하는 사람이 있다면, ‘당연히 알겠지’라고 생각하지 않는 게 좋습니다. 정말 하나하나가 낯설어요!)
그렇게 부족한 부분들을 조금씩 메워가며 전체 개발 구조를 대략적으로 이해하게 되었고, 나에게 맞는 IDE—혹은 더 저렴한 도구—를 찾아가며 개발보니 예전보다 훨씬 많은 걸 볼 수 있게 되었습니다.
바이브 코딩을 하면서 가장 크게 느낀 강점은, 작동하는 프로토타입과 간단한 프로세스 구현을 아주 빠르게 보여줄 수 있다는 점이었습니다.
예를 들어,
버튼 동작을 하나씩 정의하고
표 형태로 데이터를 입력·저장한 뒤
그 표 데이터를 자동으로 메일에 첨부해 발송하는 흐름까지
이 전체 과정을 ‘보여줄 수 있는 형태’로 만드는 데 걸리는 시간이 정말 짧게 걸립니다!
실제로 랜딩 페이지나 콘텐츠 노출 중심의 심플한 페이지라면 바이브 코딩만으로도 큰 어려움 없이 구현할 수 있습니다. 하지만 조금만 복잡한 기능이 들어가면 발생하는 에러는 난이도가 급격히 올라가고, AI가 잡지 못하는 오류를 비개발자가 온전히 해결할 확률은 낮다고 생각합니다.
이 단계는 혼자 넘기 어렵기에,
1) 개발 공부를 더 하거나 2) 개발자와 협업하는 것이 필요하다고 느꼈습니다.
바이브 코딩을 하며 얻은 팁도 있습니다. Rules 셋팅, Best Practice 적용, MCP 연결이 도움되며 - 무엇보다 좋은 모델에 투자하는 건 필수였습니다. (작업 효율, 오류 해결 가능성이 좋아집니다)
비개발자가 개발에 도전하는 일은 생각보다 쉽지 않습니다.
디자이너나 기획자로 일할 때와 달리, 직접 구현까지 책임져야 하는 순간이 오면 본능적으로 ‘내 수준에서 감당 가능한 범위의 프로덕트’를 선택하는 경향이 생겼습니다.
이는 역설적으로, 디자이너의 가장 큰 강점인 상상력과 확장성을 스스로 좁히는 결과를 만든다는 생각이 들었습니다. “이건 복잡하니까 피하자”, “내가 구현 못 할 것 같으니 단순한 구조로 가자” 같은 식으로 기술적 제약이 상상력의 경계를 만들어버린 거죠. 이 균형을 어떻게 풀어갈지, 비개발자로서 어디까지 실험하고 어디서부터 협업해야 할지를 고민하고 있습니다.
앞으로도 막히면 에이전트에게 또 묻고, 필요하면 개발자(사람)에게 도움을 구하며 계속 시도해볼 생각입니다. 좋은 시대에 태어난 만큼, 기술이 나를 어디까지 확장시켜줄지 기대하고 있습니다!