2주간의 바이브 코딩 (3.7 ~ 3.21, 저관여앱 제작 프로젝트을 마치며)

20개의 앱보다 더 오래 남은 것은 몇 가지 기준이다.
내가 2주 동안 만든 것은 단순한 업무용 도구였지만, 정작 배운 것은 무엇을 앞에 두고 무엇을 줄일지,
어디까지 AI에게 맡기고 어디서부터는 사람이 책임져야 하는지에 대한 판단이었다.
이 프로젝트는 기준을 잡는게 중요하다는걸 깨닫게 만들어준 2주간의 세미나다.

https://usekit.netlify.app/

UseKit - Finish small work fast with browser-based tools

(주의!!!) 이 글은 스크롤이 매우매우 길다. 아마도 이 썰을 푸는데 매우 신이 나있었던것 같다.

 

1. 닫힌 구조에서 시작

 

Q. 이번 2주의 시작점은 무엇이었나

A. 시작은 좀 엉뚱했다. 아주 근사한 문제의식이나 거창한 사업계획 같은 것도 아니다. 노곤한 오후 어느 날, 유튜브에서 우연히 본 ‘모나리자 vs 진주 귀고리를 한 소녀’의 미술관 센터 배틀 영상이 머리에 남았다. 초상화 입력과, 랩퍼들의 모션을 모사해서 저렇게도 만들수 있군.. 가사도 고증을 잘 살렸고 라임도 딱 맞는게, 너무나도 대단했다. 이 또한 결국 AI를 이용해 만든 일종의 놀이이자..지적 유희가 아닌가.. 그래서... 에잇. 그냥 정신줄 놓고 코딩도 한번 즐겨보자(?)란 생각이 들었다.

 

[쇼미더뭐니/4회] 모나리자 vs 진주 귀고리를 한 소녀 @미술관 센터 배틀 - YouTube

하아.. 아무튼, 정말 리스펙 합니다. ㅎㄷㄷ

 

생각은 늘 그렇듯 금방 옆길로 새는 법이다. 즐길거리에서 시작했다지만, 무엇을 해볼까 하는 아이템을 찾다가 뜬금없이 고환율에 따른 전국민 달러 앵벌이 운동 -> 구글 애드센스 -> 또 찾는 고객님과 돈과 그리고 클릭을 가져다줄 뭔가 적당히(?) 쓸 만한 솔루션, 그러면서도 너무 어렵지는 않은 것을 만들어 본다로 생각이 변했다. 결론은, 단순하고 누군가에게 유용한 웹앱 개발을 하는 것이다. 즉, 남들이 한 번쯤 필요해할 만한 걸, 웹 공간에 만드는 것이다. 찾으면 어딘간 있겠지. 그래도 취지는 작게나마 AI 와 함께 바이브 코딩으로 만드는 일 자체를 즐겨보고, 경험을 해보는 것이니 만큼  가볍게 시작하게 됐다.

 

우선 나는 이 일을 크게 벌일 생각은 1도 없었다. DB를 붙이고, 원격 객체를 두고, 외부 API나 Service 를 엮는 구조는 생각도 하지 않았다. 우선은, "닫힌 구조로 시작해 본다" 였다. 취미로 재미보려 하는 프로젝트에, 비용과 공수를 크게 들일 생각은 없기 때문이다. 내가 쫄보여서 그런것도 맞지만, 이건 막연한 불안이라기보다, 무엇이 사람을 피곤하게 만드는지.. 나름 겪어본 바가 있어 생기는 그런 종류의 경계심이라 생각해 본다. 그래서 처음에는 내가 이해할 수 있고, 내가 책임질 수 있고, 무엇보다 내가 끝까지 밀 수 있는 범위 안에서 시작하는 편이 낫다고 봤다. 대개 문제는 야심보다 마감기한이 먼저 알려주게 마련이다.

 

 

Q. 왜 하필 2주였나

 

A. 그간 경험해왔던 스프린트성 업무는 2주간 기간으로 해온적이 많아서 그 이상 계획을 잡는걸 상상을 잘 못한것 같다. -_-... 길지도 짧지도 않은 2주간의 기간. 어쩌면 충분한시간. 내가 적어도 하나를 시작해서, 배포하고, 다시 만져보고, 조금 부끄러운 부분까지 확인해볼 수 있는 시간. 무엇보다 2주 정도는 아직 변명보다 결과를 앞세울 수 있는(..)시간이었다. 길어지면 누구나 말이 많아진다. 짧으면 적어도 뭐라도 남기게 마련이다. 

 

 ...

 

Q. 왜 그렇게까지 무의존성에 가까운 구조를 고집했나

A. 이유는 두 가지다. 하나는 사용자 신뢰다. 보통의 사람들은 생각보다 자기 데이터 산출물이나 이미지 파일을, 보안이 충분히 확인되지 않은 낯선 웹 공간에 올리는 일을 좋아하지 않는다. 기능보다 먼저 이 기능 사용을 위해 “이걸 올려도 되나”가 떠오르는 순간, 이미 사용자들은 다른 페이지나 설치형 어플을 찾기 시작하게 된다.

다른 하나는 컴플라이언스다. 개인 장난감으로 끝날 때는 대충 넘길 수 있는 것도, 업무 용도로 들어가는 순간부터는 설명이 필요해진다. -_-.. 데이터가 어디로 가는지, 남는지, 연동되는지, 누가 볼 수 있는지. 그런 질문은 대개 기능 명세보다 늦게 오지 않는다. 그래서 시작부터 브라우저 내 로컬 리소스만 활용하게끔 하는 특이한 구조로, 모든 도구를 만들었다. 내가 집에서 개발을 하고 광고를 붙여 수입을 올린다고 한들, 업무에 사용할 목적으로 만들었다면 적어도 변명거리가 되니 말이다.

Q. 이런 소재들은 어떻게 찾았나

A. 거창한 방식은 아니었다. 개인적으로 업무를 하다가 “이건 있으면 좋겠다” 싶은 포인트가 몇 가지 있었다. 주변 동료분들과 업무를 같이 하다보니, 여러가지 스크립트 도구들을 만들어보게 된다. 딱히 대단한 문제라기보다 반복해서 걸리적거리고, 막상 찾으려면 누가 만들어둔 깔끔한 응용 프로그램 같은게 없는 종류의 것들이다. 그리고 몇몇은 생각보다 많은 툴들이 이미 만들어져 있었고, 지인에게 슬쩍 보여줬을 때도 비슷한 반응이 나왔다. 이런거 본거 같기도 하다고, 차별화로 이런 아이템도 넣어보면 어떻겠냐고 제안해 주신 고마운 분들도 있었다.

그러고 보면 개발 아이템이든 연구 주제든 결국 실제 환경에서의 니즈에서 출발해야 오래 갔다. 내가 답답해야 만드는 존재인지라.. ~~~ 를 이용한 Agent 제작 등과 같이, 인강속에서만 그럴듯한 문제는 딱 그화면 안에서만 그럴듯했다.

 

 

Q. 그런 선택 덕분에 실제로 얻은 가장 큰 이점은 무엇이었나

 

A. 핵심 기능에 집중할 수 있었다. 그리고 현실적인 답을 하자면.. 배포와 운영 부담이 줄었다는 점이었다. 뭔가 컴포넌트를 하나 더 붙여 보려 하면 늘 예기치 않은 난관이 훅 치고 들어왔다. 그리고 그런 난관은 대개 들어올 때나 멀리서 보면 작아 보여도, 나갈 때는 시간을 꽤나 앗아가게 마련이다. 이번에는 그걸 전부 상대할 여유가 없었다. 그래서 도구도 단순하게 가져갔다. VSCode, Codex, GitHub, 그리고 내가 만든 것을 호스팅할 장소인 Netlify. 그럴싸하고 멋진 조합은 아니었지만, 우선 이정도만 해도 일단 내 의도대로 웹 사이트 배포가 가능은 했다. 게다가 Action 으로 배포가 가능해지니, 꽤나 편했다. 그리고 결과를 눈으로 볼수 있으니 문제가 생겼을 때 어디를 봐야 하는지도 비교적 분명했다. 이 정도면 혼자 감당 가능한 복잡도라 생각한다.

 

 

Q. 그 도구 조합이 특히 잘 굴러갔던 순간은 언제였나.

 

A. 수정하고, 커밋하고, 배포하고, 다시 확인하는 흐름이 짧게 유지될 때였다. Github Action 통해, 바로바로 Deploy가 가능했다. 이건 생각보다 중요했다. 바이브 코딩이든 뭐든, 확인이 늦어지면 거의 모든 판단이 흐려진다.

초안은 AI의 도움을 받아 빠르게 만들 수 있다. 하지만 그 초안이 실제로 돌아가는지, 내가 놓친 예외가 없는지, 조용히 어색한 구석은 없는지는 결국 확인의 속도에 달려 있었다. 복잡한 인프라 없이 결과를 빨리 볼 수 있다는 건 편의가 아니라 일종의 안전장치에 가까웠다. 작은 태스크 안에도 놓친 것이 들어있다는 전제는 생각보다 자주 맞았다.

---

2. AI가 밀어주고, 사람이 붙잡는 것

Q. 반대로, 해보면서 “이건 AI가 알아서 다 해주지 않는구나” 하고 느낀 지점은 어디였나.

 

A. 예상보다 뻔한 곳이었다. UI 문구, 상태 변화, 레이아웃. 그리고 역시나 UX다.
이상하게도 이런 문제는 로컬에서 얼추 괜찮아 보여도 꼭 배포하고 나면 눈에 띄었다. 그제야 간격이 어색하고, 문구가 과하고, 상태 변화가 설명 없이 툭 튀어나온다는 걸 알게 됐다. 여기에 예외 처리나 현재 버전에서 지원하지 않는 문법 같은 사소한 문제가 얹히면, 작업은 금방 스트레스로 변했다.

 

창 전체 스크롤 예방을 위해 작업 목록에 스크롤바를 달아야 한다는 생각을, AI 가 미쳐 하지 못했을 수도 있다.

무엇보다 UX 수정은 AI가 대신 짊어져 주는 종류의 일이 아니었다. 처음 만든 UX를 바꾸려면 결국 사람이 다시 설명해야 했다. 그리고 그 설명이 늘 원하는 결과를 바로 부르는 것도 아니다. 또한.. 그게 만약 된다면, 한번의 태스크에 꽤나 많은 토큰을 태운 상황일 것이다. 그래서 설명이 어려운 요구사항 수정은 필요한 문법이나 API 사용법을 따로 검색한 뒤, 그냥 수동으로 고쳐버리는 경우도 허다했다. AI는 초안을 대신 써줬지만, 배포 후의 미세조정까진 생각보다 잘 책임져 주지 않는다.

 

Q. 그럼 이번 2주 동안 AI에게 맡겨도 되는 영역과, 직접 잡아야 하는 영역은 어떻게 나뉘었나.

A. AI에게 맡겨도 되는 쪽은 꽤 명확했다. 초안 구현, 반복 코드, 구조 제안, 와이어링 성격의 작업은 분명히 빨라졌다. 백지 상태를 깨는 데도 도움이 됐다. 적어도 “아무것도 없는 화면” 앞에서 굳어 있는 시간은 줄여줬다.

반대로 직접 잡아야 하는 영역도 선명했다. UX 감각, UI 문구와 상태 변화의 자연스러움, 언어적인 표현, 실제 웹 페이지에서의 동작 테스트, 배포 후에야 드러나는 어색함 수정 같은 것들이었다. 보이는 것과 읽히는 것, 그리고 눌러봤을 때 드는 느낌은 여전히 사람이 챙기게 됐다. AI는 초안을 밀어주지만, 최종 감각까지 책임지지는 않았다. 그 부분까지 기대하면 대개 사람이 손해를 봤다.

Q. 이번 2주 동안 “의외로 사람이 많이 봐야 하는 일이구나” 하고 느낀 대표 사례가 있나.

A. 버튼 문구가 그랬다. 이상하게도 AI는 버튼 하나에도 너무 많은 의미를 싣고 싶어 하는 경향이 있었다. 그냥 절차라고 하면 될 것을 흐름이라고 하고, 순서라고 하면 될 것을 괜히 경험처럼 포장하려 들었다.

단순한 웹앱에서는 그런 표현이 철학으로 읽히기보다 과장으로 느껴졌다. 사용자는 문장을 음미하러 온 게 아니라, 뭔가를 빨리 끝내러 왔기 때문이다. 결국 사람은 자주 덜어내는 역할을 하게 됐다. AI가 자꾸 무언가를 더 얹으려 할 때, 그걸 다시 평범한 말로 되돌려 놓는 일. 묘하게도 이런 일이 제법 중요했다.

Q. 반대로 “이건 AI 도움을 받아서 확실히 빨라졌다”고 느낀 장면은 무엇이었나.

A. 백지공포증을 넘기는 데는 확실히 효과가 있었다. 시작점을 만들어주는 능력은 꽤 쓸 만했다. 그리고 와이어링 성격의 작업에도 강했다. 아이디어를 일단 작동하는 형태로 옮겨놓는 속도는 사람이 처음부터 전부 손으로 짜는 것보다 훨씬 빨랐다.

문제는 그 다음이었다. 3월 7일 날짜계산기 앱부터 시작해 고작 보름 남짓한 사이에 20개 앱을 추가하다 보니, 와이어링 정책이나 룰, 컨벤션이 시기마다 조금씩 달라졌을 가능성이 계속 신경 쓰였다. 하나를 빨리 만드는 데는 유리했지만, 많이 쌓였을 때도 같은 제품처럼 보이게 만드는 문제는 별개의 숙제로 남았다. 속도는 얻었고, 대신 정리할 목록도 함께 얻었다.

---

3. 많이 만든 다음에야 보이는 문제

Q. 20개 앱을 쌓고 나서 가장 먼저 부딪힌 문제는 무엇이었나.

 

A. 의외로 만드는 피로보다 먼저 온 건 소재 고갈과 탐색 문제였다. 처음에는 주변의 자잘한 불편과 즉흥적인 아이디어만으로도 꽤 빨리 앞으로 나갈 수 있었다. 그런데 20개쯤 쌓이고 나니, 이제부터는 아무거나 만들 수 있는 게 아니라 정말 남길 만한 소재를 골라야 한다는 문제가 생겼다. 만드는 문제보다 찾는 문제가 더 커진 셈이었다.

더 골치 아픈 건 사용자 입장도 마찬가지다. 나는 20개를 만들어 띄워놓으면 그만이지만, 사용자는 그 안에서 자기한테 필요한 앱을 찾아야 했다. 그 사소할지도 모르는 요구사항을 갖고 말이다. 만드는 사람에게는 목록이었지만, 쓰는 사람에게는 거의 미로가 된다.

 

Q. 그렇다면 발견 가능성과 진입 구조는 처음부터 기본이 되었어야 했나.

A. 그건 나중에 붙일 기능이 아니었다. 애초에 기본이 되었어야 했다. 앱이 목록 안에서 잘 찾히는 것도 중요했지만, 더 본질적으로는 정작 이게 필요했던 사람에게 이 도구가 알려질 수 있느냐의 문제였다.

베스트는 명확했다. 필요한 순간에, 필요한 사람이, 필요한 앱을 너무 늦지 않게 딱 발견하는 것.! 그게 빠져 있으면 20개를 만들어도 사용자는 없을 수 있고, 반대로 한 사람에게 정확히 닿으면 작은 앱 하나도 꽤 유효해진다. 발견 가능성과 진입 구조는 부가 기능이 아니라 기본 설계였다.

Q. 그렇다면 UseKit은 앞으로 앱 모음이 아니라, 문제를 빠르게 찾게 해주는 구조로 가야 한다고 보나.

 

A. 그렇다. 당연한 이야기였다. 다만 그 당연한 걸 뒤늦게 더 선명하게 보게 됐다. 앱을 계속 추가하는 동안에는 만드는 일 자체가 중심이었지만, 어느 순간부터는 앱의 개수보다 사용자가 자기 문제에 맞는 도구를 빨리 찾을 수 있느냐가 훨씬 중요해졌다.
그래서 마지막에 홈 화면도 갈아엎었다. 이유는 단순했다. 앱을 늘어놓는 것만으로는 사용자가 덜 헤매지 않는다. 오히려 더 헤맨다. 필요한 건 “무엇이 있나”를 보여주는 화면이 아니라, “지금 내가 뭘 써야 하나”를 빨리 감지하게 해주는 구조였다.

 

Q. 홈 화면을 갈아엎으면서, 가장 먼저 버리고 싶었던 것은 무엇이었나.

 

A. 필요 이상으로 오버엔지니어링된 것들이었다. 개발자나 일부 숙련된 사용자에게는 의미가 있을지 몰라도, 대부분의 사람에게는 첫 화면에서부터 부담으로 느껴질 수 있는 도구들이었다. 그리고, 아무래도 휴먼이 내린 Prompt 로 일을 한 기계가 작성한 코드라,  복잡도가 높은 몇몇 어플들의 경우, 결국 기계의 오해에 따른 휴먼에러가 어딘가 있을수 밖에 없다.

 

기능적으로는 그럴듯해 보여도, 막상 사용자는 그걸 보고 “이게 내 문제를 해결해주나”보다 “이건 뭘 아는 사람이 써야 하나”를 먼저 떠올릴 수 있다. 첫 화면은 기술 시연장이 아니라 해결의 입구여야 했다.

 

Q. 이번엔 반대로, 그렇다면 UseKit에서 남기고 싶은 앱의 기준은 무엇이었나.

 

A. 단순한 것, 설명이 거의 필요하지 않은 것, 그리고 일반 사무직에게도 바로 통할 수 있을 것. 기준은 그 정도였다. 처음 보는 사람이 봐도 대충 무엇을 하는지 감이 오고, 길게 읽지 않아도 손이 먼저 갈 수 있는 앱들 말이다.

 

그래서 지금은 그런 앱만 딱 8개 정도 추려서 보여주고 있다. 많다고 좋은 게 아니었다. 오히려 너무 많으면 선택지가 아니라 피로가 된다. 첫 화면에서는 “우리가 이렇게 많이 만들었다”보다 “당신은 여기서 바로 하나를 고를 수 있다”가 더 중요했다.

 

 

Q. 그렇다면 숨긴 앱들은 버린 것인가, 아니면 뒤로 물린 것인가.

 

A. 버리지 않고 뒤로 물렸다. 다만 그냥 감춘 게 아니라, 카테고리나 관련 앱, 데이터 같은 기준을 버튼으로 선택하면 그에 맞는 리스트가 뜨도록 해두었다. 첫 화면에서는 선택지를 줄이되, 필요할 때는 맥락에 맞게 더 들어갈 수 있게 한 셈이었다.
결국 중요한 건 다 보여주는 게 아니라, 지금 필요한 것만 먼저 보이게 하는 일이었다. 나머지 앱들은 사라진 게 아니라 한 단계 뒤로 간 것이다. 그렇게 해야 첫 화면은 가벼워지고, 전체 도구군은 그대로 유지할 수 있었다.

 

 

Q. 그렇게 정리하고 나니, UseKit이 어떤 서비스여야 하는지가 조금 더 분명해졌나.

 

A. 그건 분명했다. 컨셉이 어느 정도는 명확해졌다고 느꼈다. 아쉽다면 그게 만들기 전에 명확했던 게 아니라, 만들면서 명확해졌다는 점이었다. 조금 더 일찍 정리됐으면 덜 돌아갔을 수도 있다.

 

그래도 안 만들고는 몰랐을 것도 많았다. 짧다면 짧고 길다면 긴 그 2주 동안, 무엇을 앞에 둘 것인지, 무엇을 뒤로 물릴 것인지, 무엇이 실제로 통하는지, 무엇이 만드는 사람 입장에서만 그럴듯했는지를 꽤 많이 배웠다. 결국 UseKit은 앱을 많이 늘어놓는 곳이 아니라, 필요한 순간에 너무 오래 생각하지 않고 바로 써볼 수 있는 도구를 건네는 쪽이어야 했다.

 

 

Q. 이번 2주를 지나면서 바이브 코딩에 대해 달라진 생각이 있나.

 

A. 크게 세 가지였다. 빠르지만 결국 사람이 붙어야 한다는 것, 초안에는 강하지만 제품화에는 별도 기준이 필요하다는 것, 그리고 혼자 만드는 속도는 높여주지만 일관성 관리라는 새 과제를 남긴다는 것이었다.

 

결국 바이브 코딩은 시작을 쉽게 만들어준다. 속도도 분명히 준다. 다만 그것이 제품 기준, 문체 기준, 구조 기준, UX 기준까지 자동으로 정리해주지는 않는다. 그런 건 여전히 사람이 정해야 했다. 요약하면 이랬다. AI는 일단 굴러가게 만드는 데는 유능했다. 그런데 굴러간다는 사실이 곧 잘 만들어졌다는 뜻은 아니었다. 그 차이를 구분하는 순간부터 일이 다시 시작됐다.

 

 

Q. 그렇다면 이 2주는 결과를 만든 시간이었나, 기준을 배운 시간이었나.

 

A. 지금 돌아보면 결과를 만든 시간이기도 했지만, 더 크게는 기준을 잡는 게 중요하다는 걸 깨닫게 된 2주간의 세미나에 가까웠다. 뭘 만들 수 있느냐보다 어떤 걸 앞에 둘 것인지, 무엇을 덜어낼 것인지, 어디까지 AI에게 맡기고 어디서부터는 사람이 책임져야 하는지 같은 기준이 더 중요했다.

 

결국 결과물은 남는다. 하지만 그 결과물을 다시 쌓아갈 수 있게 만드는 건 기준이었다. 그런 의미에서 이번 2주는 몇 개의 앱을 더 만든 시간이기도 했지만, 그보다 먼저 앞으로 무엇을 만들고 어떻게 보여줄지를 배우는 시간이었다.