다음 단계로, 기획 > 디자인 > 개발 프로세스를 어떻게 줄일지, 효율화할지에 대한 고민을 했다. 그런데 질문이 아애 잘못됐다는 것을 문득 깨달았다. 완전히 파괴적인 변화가 필요했던 것이다. 아무 것도 없는 상태에서 우리 팀 규모로 가장 빠르게, 그리고 제대로 제품을 개발할 수 있는 방법은 무엇일까? 이전 것들은 아애 잊기로. 일단 제품 개발 과정 중간에서 자리를 굳건히 지키고 있던 피그마를 과감히 버리기로 했다. 백로그가 시각적으로 구현되는 순간, 우리의 사고는 그 화면에 갇히게 된다고 생각했다. 화면이 아닌 코드 위에서 시작해보자! 기능단위의 업무에서 문제단위의 업무로 넘어가는 순간이다. 바이브코딩으로 만들어낸 화면들이 과연 일관적일까? 사람이 하는 것 만큼 디테일한 것들에 대한 대응이 가능할까? 따라오는 걱정과 의문이 많았지만, 속도와 유연함을 위해 감수할 수 있는 것들이었다. 디자이너, 기획자도 우리 플랫폼의 모든 소스를 내려받아 프롬

우리팀은 팀원들의 개선요청, 아이디어, 고객의 요청사항을 모두 모아서 노션 데이터 베이스 형태로 쌓아둔다. 그것을 가져다가 문제를 파악하고 플랫폼 개선 사안을 기획한 후 디자인하고 개발해왔다. 지금까지 쌓여 처리하고 있지 못한 350여개의 백로그 데이터는 이 과정에 최적화되어있기 때문에 기획자, 디자이너, 개발자, 그리고 QA를 함께 진행할 팀원들을 고려한 정보를 담고있다. 이것을 1인 PM형태, 즉 그 백로그를 담당할 한 명의 바이브코더가 관리하거나 다른 팀원들과 소통하기 편한 형태로 개편하는 작업을 해야 했다. 노션에 새로운 데이터베이스 세트를 만들고 하나하나 검토하여 마이그레이션 하는 작업을 거쳤다(그 과정에서 우리 플랫폼의 전반적인 문제들을 되짚어볼 수 있어서 좋았다). 백로그 데이터의 상태가 문제인식 > 바이브코딩 > PR > QA > 배포 > 리뷰로 간소화되었고, 안에 있는 정보들도 문제 > 솔루션 > 기대효과 정도만 담으면 작업을 바로

여기 저기서 하도 떠들어대서, 내가 뭐 한마디 덧 붙이는 것이 큰 의미는 없겠지만, 최근 바이브코딩을 시작하며 느낀 감정들을 도저히 기록하지 않을 수가 없다. PM이 만든 서비스 기획안을 넘겨받아 디자이너가 와이어프레임을 짜고, 다같이 모여 피드백을 주고 받은 후 여러 번의 수정을 거쳐 완성된 피그마 화면을 보며 개발자가 코딩을 했던 일련의 과정이, 2시간 정도의 채팅으로 진정 대체되는 날이 온 것이다. 이제는 누구나 자연어로 디자인, 코딩할 수 있는 시대가 됐다. 클로드 코드나 구글 안티그래비티와 같은 놈들과 잠깐만 이야기해봐도 위화감을 느낄 수 있다. IT스타트업을 운영하며 처음 느끼는 허탈감이라고 표현해야 할까. 동시에 가슴 뛰는 설렘도 느꼈다. 대부분의 스타트업들이 외부 투자금을 신규 인력의 인건비로 사용해왔고, 팀이 커지며 여러가지 문제를 해결하는 방식으로 성장했는데, 이제는 인력이 늘지 않아도 다양한 문제를 동시다발적으로 풀어낼