VC 심사역의 바이브 코딩 개발기 -3.2-

Feature 구현을 위한 여정

안녕하세요, 스타트업에 투자하는 VC 심사역 그믐입니다. 지난 글에서 VS Code와 Copilot으로 본격적인 폭주를 시작했다고 말씀드렸죠. 본격적으로 VS Code와 Copilot을 사용할 수 있게 되면서, 제가 원하는 프로덕트를 실시간으로 Test Server에서 보면서 제가 원하는 Detail들을 제 프로젝트에 녹여낼 수 있게 되었습니다. 레고 조립하듯, 도자기를 빗어나가듯이 하나씩 수정 해나간 이야기들을 해보려고 합니다.

Test Server로 실행: 내 손 안의 창작물

Copilot에게 프로그램을 실행해달라고 요청하자

`npm run dev` 명령어를 실행해주었고, `http://localhost:8080/` 에서 제 웹서비스를 볼 수 있게 되었습니다. 실시간으로 변화를 확인하면서 VS Code에서 직접 수정할 수 있게 되니, 드디어 도자기를 빚을 수 있는 찰흙이 제 손에 놓여진 느낌이었습니다.

한글화와 UI 개선: 처음으로 느낀 ‘개발’

본격적으로 이 프로젝트가 제 손에 들어오자 가장 처음하고 싶었던 일은 일단 모든 UI에 대한 한글 번역이었습니다. 물론 각 내용 ‘Sign Up’, ‘New Raid Plan’ 등을 검색하면 각 글자들을 찾아볼 수 있었겠지만, 정확한 위치를 이해하지 못한 저에게는 오래 걸릴 것으로 생각이 들었고, 한번 Copilot에게 이 작업을 맡겨 보았습니다.

너무나 당연하게도 이러한 간단한 UI 번역은 쉽게 했고, 특히 인상적이었던 것은 Copilot이 우리 프로젝트의 Context를 이해하여 단순 번역을 넘어서 WOW 게임에 맞는 용어를 사용한다는 점이었습니다. 'Tank'를 '탱커'로, 'Healer'를 '힐러'로, 'DPS'를 '딜러'로 번역하면서도 게임 내에서 실제로 쓰이는 한글 표현을 적용해주었죠. 동시에 UI의 색감과 형태도 개선하려 했습니다. 답답해 보이는 주황색 배경을 지우고 테두리를 얇게 하는 등의 작업을 진행했지만, 원하는 수준까지는 도달하지 못했습니다. Figma를 활용해 UI를 재구성하려 했으나, 당시엔 Cursor talk to figma MCP와 같은 편리한 도구를 활용하지 못해 아쉬움이 남았습니다.

Spec-Icon 적용: 개발자와 AI의 티키타카

다음 도전은 WOW의 직업별 특성 아이콘 추가였습니다. World of Warcraft에는 각 직업을 표시하는 색상과 직업마다 3개씩 존재하는 특성을 대표하는 아이콘이 있습니다. 이 아이콘으로 표시하면 UI가 깔끔해질 뿐 아니라, WOW 게이머라면 한눈에 직업과 특성을 파악할 수 있죠.

일반적인 개발 과정이라면 다음과 같은 단계가 필요했을 겁니다:

각 특성에 해당하는 아이콘 수집

각 직업별 아이콘 분리

현재 직업 및 특성 값과 아이콘 매칭

사실 이 일들이 꾀나 귀찮을 것을 알고 있었기 때문에 어떻게든 편하게 진행해보고 싶었습니다. 처음에 "와우의 각 특성 아이콘을 적용해줘"라고 요청했을 때 Copilot은 정확히 이해하지 못했습니다. 구글링을 통해 특성이 영어로 'Spec'이라는 것을 알게 된 후, "실제 WOW 게임에서 사용하는 Spec-Icon을 넣고 싶어"라고 구체적으로 설명하자 상황이 달라졌습니다. Copilot은 즉시 GitHub에서 관련 아이콘 파일들을 찾아내어 폴더 구조까지 갖춘 상태로 받아와서 각 특성 값에 매칭까지 완료했습니다. 제가 정확한 용어를 알려주자 마치 제 의도를 정확히 이해한 동료처럼 작업을 완벽하게 수행해낸 것이죠. 이 순간 단순한 도구가 아닌, 제 의도와 맥락을 파악해 협업하는 파트너와 함께 일하는 느낌이 강하게 들었습니다.

역할별 그룹화와 UI 개선: AI의 창의적인 기여

그 다음 제가 하고 싶었던 작업은 참가자 목록의 각 인원들에 대한 정리로 3가지 Layer가 있었습니다.

각 역할별(탱커,힐러,딜러) 그룹화

직업별 및 특성별 정렬

아이템 레벨 순 정렬 (내림차순)

일반적으로 요즘 레이드 요즘 20~30인수준이 가는 것이 일반적인데, 그렇다면 보통 탱커 2명, 힐러 4~6명, 딜러 14~22 명 수준으로 구성하는 것이 일반적이기 때문에 각 역할 별로 몇명이 있는 지가 중요합니다. 그리고 동일한 직업이나 특성이 많이 겹치는 경우에는 얻고 싶어하는 아이템이 많이 겹치기 때문에 좋지 않은 부분이 있어 위 와 같은 정렬이 필요했습니다.

이 때 각 역할별 그룹화를 먼저 요청하였는데, 이 때에 자신이 어디서 가져왔는지 꾀나 맘에드는 UI를 적용해주어서 UI 전반을 해당 UI 형태로 변경하게 되었습니다.

GitHub 저장: 부활지점 갱신

프로젝트가 형태를 갖추기 시작하자 다른 사람들에게 보여주고 싶어졌습니다. 배포를 위해서는 Git에 코드를 올려야 한다고 Copilot이 알려주었지만, 제가 Git 사용법을 전혀 몰랐죠.

하지만 저에게 는 괜찮은 개발자가 옆에 있지 않겠습니까. Copilot에게 "이 프로젝트를 GitHub에 올려줘"라고 단순하게 요청했더니, Copilot이 커밋, 푸시 등의 복잡한 과정을 알아서 처리해주었습니다. 정확히 뭘 하는지 몰랐지만 뭔가 Git의 저장소에 가니 파일도 늘어있고 뭔가 백업이 된 것으로 보였습니다. 물론, 브랜치 개념도 모른 채 master와 main을 뒤섞어 사용하는 바람에 나중에 배포할 때 고생하긴 했지만요.

모바일 대응의 함정: 프로젝트 붕괴의 시작

다른 사람들에게 자랑하고 싶어진 저는 "모바일에서도 잘 보이게 반응형으로 만들어줘"라고 요청했습니다. 그러나 이것이 재앙의 시작이었습니다. Copilot이 코드를 수정하면서 기존에 잘 작동하던 기능들이 하나둘 망가지기 시작했습니다. 참가자 추가가 안 되고, 삭제 버튼이 작동하지 않았으며, 레이아웃이 완전히 엉망이 되었죠. 더 심각한 건 Copilot이 점점 컨텍스트를 잃어가면서 엉뚱한 코드를 생성하기 시작했다는 점입니다. 결국 Copilot이 "이전 대화 컨텍스트를 사용할 수 없습니다"라는 메시지를 표시했을 때, 모든 것이 망했다는 것을 깨달았습니다.

Git으로 구원받다: 이전 버전으로 복구

절망하던 중, "이전 커밋으로 돌아가고 싶어"라고 Copilot에게 물어봤더니 Git 명령어를 알려주며 복구 방법을 안내해주었습니다. 다행히 모바일 대응 전 상태로 돌아갈 수 있었죠.

이 경험을 통해 커밋의 중요성을 뼈저리게 느꼈습니다. 이후로는 기능 하나를 추가할 때마다 "이거 커밋해줘"라고 요청한 뒤에 새로운 대화창을 열어서 작업을 진행하는 습관이 생겼습니다.

배운 점과 다음 단계

이번 여정을 통해 몇 가지 중요한 교훈을 얻었습니다:

적절한 Context의 제공 : 'Spec-Icon'처럼 정확한 용어를 사용하면 AI가 맥락을 더 잘 이해하고 효과적으로 작업할 수 있습니다.

커밋은 안전망: 작은 변화라도 자주 커밋하는 습관이 중요합니다. 무언가 잘못되었을 때 돌아갈 수 있는 지점이 생기기 때문입니다.

AI도 한계가 있다: Copilot이 맥락을 잃는 순간이 오면 결과물이 엉망이 될 수 있습니다. 대화 컨텍스트를 유지하는 것이 중요하며, 때로는 새로운 세션을 시작하는 것이 더 효과적일 수 있습니다.

비개발자도 할 수 있다: 코딩 경험이 전혀 없는 저도 AI의 도움으로 실제로 작동하는 웹 애플리케이션을 만들 수 있었습니다. 물론 한계는 있지만, 그 한계는 생각보다 훨씬 높았습니다.

다음 개발기에서는 몇 가지 추가 기능 구현과 Vercel을 통한 배포와 Supabase 데이터베이스 연결 과정에서 겪은 경험을 공유해드리겠습니다. 실제 인터넷에 공개되는 서비스를 만드는 과정은 또 다른 차원의 도전이었거든요.

비개발자의 AI 코딩 여정, 계속 지켜봐 주세요!

#바이브코딩 #VC심사역 #Copilot #AI개발 #WOW