시작
늦었지만 바이브 코딩을 시작했다. 코딩다운 코딩을 하지 않은 지 이제 한 달이 되었다. 이 시점에서 회고를 하기 위해 글을 남겨본다.
커서는 나올 때부터 계속 쓰고 있었다. 지금은 의존성이 생겨 코딩을 할 때 커서 없이 코딩하는 것이 답답하다.
이제는 바이브 코딩 없이 제품을 만드는 것이 답답할 정도가 되었다.
추석 연휴 때 시작했다. 시간이 많아 뭘 만들까 생각하다가 바이브 코딩의 생산성을 기대하고 조금은 커 보이는 프로젝트인 메신저를 만들어 보기로 했다. 메신저를 만들기로 한 이유는 지금 카카오톡의 안 읽은 메시지 수가 999이기 때문이다. 오픈 채팅방 몇 개에 들어가니 금방 999가 되었다. 뭔가 설정이 있을 것 같기도 하지만 귀찮아서 그냥 뒀고 메시지를 잘 놓치고 있어 가족과 지인들이 쓸 메신저를 만들기로 했다.
먼저 가능할지 맛보기를 해봤다. 클로드 코드로 시작했고 회사에서 쓰고 있는 계정으로 연결해 API 키 방식으로 시작했다. 아무 사용법도 보지 않고 그냥 설치 후에 긴 프롬프트로 만들고 싶은 것의 기본 기능을 만들어 달라고 했다. iOS와 안드로이드 모두 돼야 하니 플러터로 만들어 달라고 하고 서버는 우선 Firebase로 해달라고 했다. 로컬에 firebase CLI도 설치되어 있고 Firebase 콘솔에서 프로젝트도 만들어놨기 때문에 알아서 firebase 프로젝트 연결도 잘했다. 필요한 Cloud function이 있으면 알아서 배포도 잘해줬다. 1시간이 걸리지 않아서 쓸 만한 메신저 앱을 만들었다. 생각보다 좋았고 스토어에 등록할 수 있는 완성도 있는 버전을 추석 연휴 동안 만들 수 있을 것 같아 시작했다.
친구친구
앱 이름은 친구친구로 했다. 디자이너가 없지만 고민이 필요한 디자인이 많지 않고 여러 메신저를 보면서 비슷하게 하면 될 것이라 따로 피그마 같은 곳에서 디자인을 하진 않았다. 로고도 대충 'ㅊㄱㅊㄱ'로 해서 금방 만들었다.
이제 기능을 붙여가기 시작했다. 1:1 채팅은 아직 필요 없어서 그냥 단톡방만 만들었고 1:1 대화하려면 둘이 있는 단톡방을 만들어서 하도록 했다. 메시지 읽음 처리, 푸시 메시지, 앱 실행 중 푸시 메시지 처리, 메시지 삭제, 메시지에 답장, 프로필 사진, 상태 메시지, 이모티콘!!, 이미지 전송, 이미지 묶음 전송, 메시지에 반응 남기기, 채팅방에 링크로 초대하기, 연락처에 있는 친구를 찾아서 친구 신청하고, 수락, 취소 등등 기본 기능을 만들었다. 내친김에 플러터에서 맥 버전도 만들 수 있다고 해서 맥 버전까지 만들었다. 그리고 추석 연휴가 끝날 때쯤 앱 스토어와 플레이스토어에 등록했다. 다행히 심사는 까다롭지 않았다.
아내와 주변 지인의 도움으로 고퀄리티의 이모티콘도 3종 갖게 되었다. 심지어 움직이는 이모티콘까지! 아래는 아내가 그려준 이모티콘이다.
더 해보기
충분히 쓸 수 있는 기능이 되었지만 바이브 코딩 덕분에 조금 더 해보고 싶은 것들이 생겼다. 그전에 10일 정도 쓴 토큰 비용은 $150 정도였다. 생각보다 많이 나가서 $200 짜리 구독 상품을 결제했다. 맥 버전에서 다른 메신저들처럼 채팅 창을 새 창으로 띄우는데 플러터는 문제가 있었다. 플러터 엔진을 창마다 실행해야 되었고 창과 창에서 공유하는 데이터 때문에 동시성 문제가 있었다. 바이브 코딩이니까 플러터로 할 필요가 있나? 어차피 내가 코드를 고칠 것도 아닌데! 그래서 맥을 네이티브로 다시 만들었다. 3일 정도 걸렸다.
다음으로 AI 기능을 넣어봤다. 채팅방에서 AI에게 말을 걸 수 있게 하고 채팅 내용과 친구들의 상태 메시지를 Context에 주고 답을 할 수 있게 했다. 아직 뭘 어떻게 활용해야 할지는 모르겠다.
또 알림 기능도 넣었다. 정해진 시간에 단톡방에 반복 알림을 해주는 기능이다. 이것은 개인적으로 잘 쓰고 있다. AI에 뭘 활용해볼까 하다가 함수 호출 기능을 써서 말로 알림을 등록하거나 고치거나 지울 수 있게 했다. 역시 코딩을 하진 않았다. 코딩을 해야 했다면 귀찮아서 안 했을지도 모른다.
마지막으로 윈도우즈 버전을 만들었다. 원래 회사 일 시작을 윈도우즈 개발자로 시작했지만 그것은 20년도 넘은 일이라 아무것도 모르는 상태(나도 모르게 cls가 생각났다 ㅋㅋㅋ)지만 AI가 해줄 것이라 AI를 믿고 윈도우즈 버전을 만들었다. 맥에서 UTM을 설치해 개발했다. 4코어에 16기가 램을 주고 100G 스토리지 할당했는데도 느렸지만 그래도 잘해서 쓸만하게 만들었다. 역시 네이티브로 만들었다.
이렇게 완성
지금은 처음 버전보다 많이 달라졌다. 재밌는 것들을 많이 넣어볼 생각이다. 아이폰, 안드로이드는 무료이고 맥, 윈도우즈는 유료로 했다. 저렴한 서버를 쓰고 있지만 그래도 서버비는 어떻게든 마련해야 하기 때문에 어쩔 수 없었다. 아래 홈페이지에 링크를 걸어놨다.
이제 바이브 코딩에 대해 회고를 해보자.
좋은 점
생산 속도
첫 번째로 좋은 점은 당연히 생산성이다. 대부분의 기능 구현에 사람보다 훨씬 빠르다. 특히 어려운 기능을 더 빨리 만든다. 만약 혼자서 '친구친구' 아이폰, 안드로이드, 맥, 윈도우즈까지 만들려고 했다면 공부도 해야 하고 삽질도 많이 해야 하고 해서 몇 달은 걸렸을 것 같다. 윈도우즈 같은 것은 해볼 생각도 안 했을 것 같다. 아직 많은 사용자를 갖지 않은 스타트업이라면 바이브 코딩으로 만드는 것이 좋을 것 같다는 확신이 든다. 막 시작하는 스타트업인데, 개발자 여럿을 두고 코딩을 하고 있는다면 경쟁사들을 따라가지 못할 것 같다.
개발자 학습
두 번째 좋은 점은 AI가 코드를 작성하는 것을 보고 있으면서 학습이 된다는 점이다. 몰랐던 방법으로 문제를 해결하는 경우가 여러 번 있었고 좋은 선택이었다고 생각한다. 물론 코드를 잘 몰라 이해할 수 없다면 학습에 도움이 되진 않을 것이다. 커서를 사용할 때도 조금씩 배우는 것이 있었지만 바이브 코딩으로 더 많은 것을 배울 수 있었다.
과감함
개발자의 입장에서 조금 더 과감한 도전을 할 수 있게 해 준다. 어떤 기능들은 몰라서 학습 비용 때문에 엄두가 나지 않는 것들도 바이브 코딩으로 시도해 볼 수 있다. 자주 해보지 않으면 귀찮은 휴대폰 문자 인증이나 연락처 연동, 윈도우즈 개발, 결제 연동, 움직이는 APNG(이런 것이 있는 줄도 몰랐다) 등등은 바이브 코딩이 아니었다면 시도하지 않았을 것 같다.
비용
$200의 클로드 Max 플랜을 사용하고 있는데 바이브 코딩을 잘해보지 않은 사람들은 아마도 비싸다고 느낄 것이다. 하지만 해본 사람들은 저렴하다고 느낄 것이다. 나도 처음에는 비싸다고 생각했지만 결과물과 생산 속도를 보고 저렴하다고 생각했다. 개발자 몇몇의 역할을 해내는 것이 맞는 것 같다.
어려운 점
어려운 과제
몇몇 과제는 AI가 어려워했다. 최신 버전의 XCode 설정과 인증서 문제에 관해서 조금 어려워했다. 기본적으로는 알고 있는 지식을 사용하기 때문에 최신 버전에 대한 이해가 부족하다. 하지만 웹 검색을 스스로 하거나 시키면 최신 문제들도 해결할 수 있었다. 또 코드가 길어지면 코드를 고치는데 어려워했다. 어떤 경우에는 한참을 고치다가 스스로 포기하기도 했다. 마지막으로 애니메이션에 관련된 문제를 해결하는데 어려웠다. 애니메이션 문제는 설명하기도 힘들고 고치는 것도 힘들어했다. 어떤 경우에는 최대한 화면을 캡처해서 사진을 제공해서 문제를 해결하기도 했다.
대기 시간
프롬프트를 입력하면 뿅 하고 바로 나왔으면 좋겠다. 아무튼 프롬프트를 입력하고 한참 기다려야 기능이 완성된다. 아직은 그렇고 점점 빨라질 것으로 기대한다. 대기 시간이 짧아질수록 생산 속도는 더 빨라질 것 같다.
코드 품질
지금은 코드를 거의 보지 않기 때문에 코드 품질이 어떤지 사실 잘 모른다. 하지만 코드가 커지면 AI 스스로도 고치는데 어려움을 많이 느낀다는 사실을 알게 되었다. AI 입장에서도 좋은 코드가 고치기 쉬운 코드인 것 같다. 그래서 앞으로는 코드 품질에도 조금은 신경을 써야겠다. 품질을 높이는 가장 쉬운 방법은 테스트 코드를 적당히 만들면 될 것 같다. AI로 TDD를 해보는 것도 도움이 될 수 있을 것 같다. 먼저 테스트를 만들라고 시키고 관련된 코드를 만들라고 하면 저절로 좋은 코드가 만들어질 수밖에 없다. 하지만 코드 품질에 너무 신경을 쓰진 않아도 될 것이다. 왜냐하면 정말 잘 되면 다시 만들면 되기 때문이다. 첫 버전은 버린다.
단어 선택
단어 선택은 중요하다. 중간에 단어를 잘 못 말해서 한참을 헤맸다. iOS에서 로컬 알림? 인지 로컬 푸시? 인지와 관련된 내용인데, 그냥 내 생각에 로컬 알림이라고 계속 말했고 뭔가 iOS에서 LocalNotification에 관련된 기능이 있었는데 내가 원하던 것은 그것이 아니었었다. 당연한 말이겠지만 프롬프트에 정확한 말을 써줘야 하는 것이 어려웠다. 또 실수를 할 수도 있겠지만 애매하면 지금은 최대한 주절주절 써준다.
앞으로 할 것
레거시 코드
새 프로젝트 만들 때는 바이브 코딩을 해봤지만 원래 있던 레거시 코드를 바이브 코딩으로 유지보수 할 수 있을지 궁금했다. 한 번은 하스켈로 되어 있는 현재 프로젝트의 간단한 버그를 고치는 데 사용해 봤는데 잘 동작해서 가능성이 없지는 않았다. 버그가 워낙 간단한 형태라 잘 동작했지만 복잡한 기능 추가도 잘할 수 있을지 의문이다. 그리고 언어 차원에서 정적 타입 언어와 동적 타입 언어에 차이도 왠지 있을 것 같았다. 타입 시스템은 구문 오류 체크에도 쓰지만 타입 자체가 언어에 부수적인 정보로 사용될 수 있기 때문에 정적 타입 시스템이 있는 언어가 조금 더 유리할 것 같았다. 물론 하스켈처럼 학습량이 부족한 언어보다 대중 적인 언어가 더 잘 될 것 같긴 하다.
개발자와 협업
아직 바이브 코딩으로 혼자 개발해 봤지 다른 개발자와 협업해보지 못했다. 바이브 코딩으로 협업을 한다면 어떤 것을 생각해봐야 할지 생각만으로는 잘 알 수 없다. 대규모 바이브 코딩을 위해서는 다른 개발자와 협업을 해봐야 할 것 같다. 직관적으로 생각나는 것은 코드 병합인데 병합도 AI가 할 수 있을 것 같기도 하고 어떤 현실적 문제가 있을지 궁금하다.
디자이너와 협업
기존 프로젝트는 디자이너가 피그마나 스케치로 디자인 리소스를 주면 그것을 보고 개발자가 화면 작업을 했다. 바이브 코딩으로 하면 어떻게 해야 할까? 우선 피그마 MCP 같은 것을 클로드 코드에 붙일 수 있으니 가능할 것 같다. 피그마 MCP가 어느 정도로 화면 인식을 할 수 있을까? 피그마나 스케치에서 화면 정리가 잘 되어 있어야 할 것 같기도 하고 AI가 알아서 화면을 잘 찾을 수 있을 것 같기도 하고 이것도 궁금한 점이다. 또 화면이 고쳐졌을 때 다시 반영하는 것은 어떤 식으로 해야 할지도 해봐야 알 것 같다.
테스트 자동화
바이브 코딩을 하면서 모든 QA는 사람이 했다. 그래서 가장 시간이 많이 걸린 것은 QA이다. 요즘은 통합 테스트로 UI 테스트까지 가능한 시대이니 테스트 자동화도 왠지 AI가 만들고 할 수 있을 것 같다. 앞으로는 이런 것들을 시도해 보고 또 회고를 해보자.
팁?
클로드 코드를 쓰고 있는데 프롬프트로 이것저것 시키고 책을 보고 있다. 하지만 언제 끝났는지 알 수 없기 때문에 화면을 가끔 쳐다봐야 해서 책 읽은데 집중이 안된다. 그래서 클로드 코드에게 작업이 끝나면 터미널에서 다음 명령어를 실행해 달라고 하니 작업이 끝날 때마다 소리가 나서 언제 작업이 끝났는지 알 수 있다. ㅋㅋㅋㅋ
afplay /System/Library/Sounds/Ping.aiff아직 사소한 버그들이 조금있지만 바이브와 함께 빠르게 업데이트해 나가고 있습니다. 친구친구 앱 많이 써주세요. ㅎㅎㅎ 😍
