# Vibe Coding 체험기: VibeX 개발로그 #2

# 추가된 새로운 기능들

지난 편 이후로 Vibex에 몇 가지 핵심 기능들을 추가했습니다. 사용자 경험을 풍부하게 하고 초기 프로덕트 개발 시 필요한 정보를 공유할 수 있도록 하는 데 중점을 두었습니다.

### + 미디어 및 URL 미리보기

스레드에 이미지와 비디오를 첨부할 수 있게 되었고, URL을 붙여넣으면 미리보기가 자동으로 생성됩니다. 미리보기는 2, 3번의 프롬프트로 금방 추가되었습니다. 조금 문제가 되었던 부분은 image, video의 출력 비율 및 크기 계산이었습니다. 있는걸 참고하자는 마인드로 x.com의 규칙을 그대로 적용했습니다.

### + 다크/라이트 테마 설정

사용자의 취향에 맞춰 다크 모드와 라이트 모드를 오갈 수 있도록 테마 설정 기능을 추가했습니다. 처음으로 단 한번의 프롬프트로 만족스러운 결과를 제공했던 기능입니다. 물론 자잘한 색상 수정이 있긴했지만 설정페이지 까지 깔끔하게 만들어줘서 놀랐습니다.

![테마 설정화면](https://upload.cafenono.com/image/slashpagePost/20251113/160402_lk8H4uI5o0STvIeYPe?q=80&s=1280x180&t=outside&f=webp)

### + AB 투표 기능

스레드에 AB 투표 기능을 추가하여 사용자 참여를 유도하고, 다양한 의견을 수렴할 수 있는 기반을 마련했습니다.

> **_AB vote는 AB 테스트를 생각에 두고 개발한 기능입니다. 실제 AB 테스트는 2가지 UIUX를 제공하고 통계적 결론을 도출하지만, VibeX는 짧고 빠른 선택을 위해 투표 형태의 기능으로 구현 했습니다._**

기존 스레드 안에 투표폼을 추가하고 싶었기 때문에 직접 구현하다가는 AI와 사투를 벌일것 같았습니다. 그래서 V0를 통해 기본 프론트 코드를 도출했습니다. 결과적으로 매우 좋은 선택이 되었는데 V0에 이미 많은 학습데이터를 통해 제가 원하는 UI와 기능을 구현해줬습니다. 그대로 code를 복사해서 Cursor에게 연결만 부탁했고, 결과적으로 30분 만에 대부분의 기능이 구현되었습니다.

![V0의 version 1 결과](https://upload.cafenono.com/image/slashpagePost/20251113/160443_47MmpGHGyw5GzmMVxm?q=80&s=1280x180&t=outside&f=webp)

문제는 Supabase의 정책과 함수, Cursor가 작성한 러프한 형변환 코딩이 문제였습니다. 스레드 테이블에서 AB vote 테이블을 참조해야 하기 때문에 DB내 함수와 정책이 필요 했습니다. 아래 언급하겠지만 치열한 Supabase 설정이 있었기에 지속적인 오류를 잡는데 5일 정도 소모한 것 같습니다…

![최종 구현된 AB vote가 포함된 스레드](https://upload.cafenono.com/image/slashpagePost/20251113/160459_awEEBoTgoqBM98Atgz?q=80&s=1280x180&t=outside&f=webp)

### + 다국어 지원

한국어, 영어, 일본어 등 3개국어를 지원하여 글로벌 사용자들이 Vibex를 더 편하게 이용할 수 있도록 했습니다.

다국어 기능은 현재 시점에 굳이 추가할 기능은 아니었는데 Cursor가 간단히 설정할 수 있을 거라 예상하고 진행했습니다. 그런데 Cursor가 추천해준 2가지 방법(i18next, next-intl) 중 next-intl을 선택해서 진행시켰는데 2가지를 혼용해서 작성을 해버렸습니다. 다국어 수정을 하면서 확인된 것이었는데 Cursor가 i18next 방식을 메인으로 설정하고 수정요청을 하면 next-intl을 고려하고 수정해서 문제가 발생했습니다. 최종적으로 i18next 방식으로 정리했지만 당당하게 코드가 꼬인 것도 처음이라 신비한(?) 경험이었습니다. 다들 조심하세요..

# 타임라인 최적화(와 실패)

가장 많은 시간과 노력을 들였던 부분 중 하나는 바로 타임라인 출력 최적화였습니다. 사용자들이 스레드를 끊김 없이 볼 수 있도록 부드러운 사용자 경험을 제공하는 것이 목표였죠. 구체적인 최적화 목표는 다음과 같았습니다.

- **무한 스크롤**: 타임라인 아이템을 10개씩 마지막 아이템까지 출력

- **페이지 간 좋아요 상태 실시간 공유**: 캐시를 사용해서 여러 페이지에서 동일한 스레드를 보더라도 좋아요 상태가 실시간으로 동기화

- **DB 테이블과 백그라운드 동기화**: 사용자의 좋아요 클릭과 같은 액션이 DB에 즉시 반영되도록 백그라운드에서 동기화

- **한 번 출력된 아이템은 재사용**: 목록이 있는 페이지에 접근할 때 마다 로딩이 발생해서 이미 출력된 아이템을 재사용

- **사용자 화면 비동기 업데이트**: 사용자가 좋아요를 누르면 화면에는 즉시 반영되도록 하고 비동기 업데이트를 통해 사용자간은 시간차를 두고 반영, DB 업데이트는 백그라운드에서 수행

- **스레드 상세 페이지 복귀 시 스크롤 위치 유지**: 스레드 상세 페이지로 이동했다가 다시 타임라인으로 돌아왔을 때, 이전에 보던 스크롤 위치를 캐시에 저장해서 복귀할 때 위치가 유지

이러한 최적화 목표를 달성하기 위해 비동기(화면상에서 좋아요 상태 변경 등)와 동기(DB에 업데이트) 방식을 상황에 맞게 적용하려 노력했습니다. 하지만 이 과정에서 예측하지 못한 오류들이 발생하기 시작했고, 하나의 오류를 수정하면 또 다른 오류가 발생하는 악순환에 빠지게 되었습니다.

결론적으로 3번의 타임라인 코드 재작성과 1주일간 사투 끝에 패배 했습니다. 원인분석, 콘솔메시지, 소스 코드 위치 등 다양한 방안으로 수정요청을 했지만 잘 되는것 같다가도 연신 오류가 발생해서 현재는 가장 기본동작만 하도록 구현했습니다.

- 페이지 접속 시 매번 로딩

- 무한 스크롤

- DB와 실시간 동기화

- 캐시 없이 좋아요 상태 공유

다시 정리해보면 좀 더 깔끔한 로직과 예외처리 방안을 정리해서 다시 시도해볼까 고려중인데 조금 뒤에 해보겠습니다..

# Supabase 설정을 두고 Cursor와의 사투

### + Cursor의 역습

오류를 해결하는 과정에서 저는 Supabase의 정책(policy), 트리거(trigger), 함수(function) 등을 수정해달라고 Cursor에게 요청하게 되었고, 이로 인해 직접 DB를 수정하게 되는 상황이 발생했습니다. 결과적으로 무분별한 DB 초기화와 마이그레이션이 발생했습니다.

처음에는 Cursor에게 직접 supabase cli를 통한 수정을 진행했는데 언젠가부터 DB의 정책, 아이템들이 초기화되는 현상이 시작되었습니다. DB에 대한 지식이 전무하니 내가 뭔가 실수했겠거니 생각했는데 초기화가 3회 이상 넘어가니 너무 화가나기 시작했습니다. 범인을 색출하니 cli로 Cursor가 뭔가 이상하면 계속 초기화 명령을 날렸던 것이었습니다. 결국엔 허용한건 저 이지만……

이후 "직접 cli로 수정하지 말고 SQL로 작성해달라"요청을 해서 직접 SQL Editor에서 검토 후 실행하는 방법으로 진행했습니다. Cursor Rules에도 "요청하지 않으면 DB를 수정하지 말라고" 추가했습니다. 하지만 그럼에도 불구하고 중간중간 cli로 DB를 초기화하고 마이그레이션하는 어뷰징을 계속했습니다. (프롬프트에 절대 하지 말라고 작성해도 마이그레이션을 수행하는 경우도 있었습니다. 아마 작업을 진행하는 것이 상위 명령이라고 해석한 것 같습니다.)

이는 바이브코딩 과정에서 매우 중요한 교훈을 주는 부분이었습니다.

### + Development DB 별도 구성

결국, 이 문제들을 해결하기 위해 개발용 DB를 별도로 구성하기로 결정했습니다. Supabase에 별도 프로젝트를 생성하여 개발(development) DB를 프로덕션(production) DB와 분리한 것이죠. 이를 통해 다음과 같은 규칙을 세울 수 있었습니다.

- 더 이상 프로덕션 DB를 마음대로 수정하지 않는다.

- 개발 버전에서는 개발용 DB만 사용하도록 설정한다.

이러한 분리 작업은 이후 개발 과정에서 발생할 수 있는 치명적인 오류를 사전에 방지하는 데 큰 도움이 되었습니다. 그리고 신기하게도 이후에 개발DB는 초기화나 마이그레이션을 시도하지 않고 있습니다. 일부러 그런것 같습니다.

# Cursor(Vibe 코딩)를 2주간 사용하며 배운 점

2주간 Cursor와 함께 개발을 진행하면서 몇 가지 중요한 교훈을 얻었습니다.

### + 오류 수정 요청 시 주의사항

오류 수정 요청을 할 때는 다음 정보들을 최대한 구체적으로 제공해야 합니다.

- 이슈에 대한 현황 및 증거: 콘솔 메시지, 에러 화면 캡처 등 문제를 명확하게 보여줄 수 있는 자료가 필수입니다.

- 수정 타겟 및 범위: 어떤 파일, 어떤 코드 블록을 수정해야 하는지 명확히 제시하면 더 좋습니다.

- 대략적인 원인 분석: 예상하는 로직상의 문제점이나 코드의 취약점을 함께 제시하면 문제 해결에 큰 도움이 됩니다.

- 수정 요청 및 방법 제시: 어떤 방식으로 수정되어야 하는지, 가능하다면 수정 방법까지 제시하면 더 빠르고 정확한 해결이 가능합니다.

### + 2~3회 안에 해결을 못하면 단계별 검토 요청 필요~
~

한 가지 문제에 대해 2~3회 이상 대화를 주고받았는데도 해결되지 않는다면, 더 이상 단편적인 요청만 하지 말고 문제 해결을 위한 단계별 접근 방식이나 특정 부분에 대한 심층적인 검토를 요청하는 것이 효과적입니다. 만약 계속 반복 요청한다면 높은 확률로 로직이 꼬일 것 입니다.

### + 정기적인 채팅 초기화 필요

LLM 모델과의 채팅이 길어질수록 컨텍스트가 복잡해지거나 이전 대화의 영향으로 불필요한 답변이 나올 수 있습니다. 주기적으로 채팅을 초기화하고 새로운 마음으로 시작하는 것이 좋습니다.

### + LLM 모델이 중간에 바뀐 것 같다면 다시 설명해 주는 것이 좋음

가끔 LLM 모델의 업데이트나 내부적인 변화로 인해 이전에 설명했던 내용들을 기억하지 못하는 것처럼 보일 때가 있습니다. 이런 경우에는 번거롭더라도 핵심 내용을 다시 한번 설명해 주는 것이 원활한 소통에 도움이 됩니다.

# 중간점검

Vibex 개발은 삽질의 연속이었지만, 그만큼 많은 것을 배우고 성장할 수 있는 시간이었습니다.

> **_지금까지 산출물: _**~**_[https://vibexx.vercel.app/](https://vibexx.vercel.app/)_**~ (서비스 종료)

도메인을 구매하려고 했지만 vibex가 생각보다 많이 사용하는 이름이라 비싸서 vercel 기본으로 유지했습니다..(심지어 vercel에서도 vibex가 사용중이라 vibexx로 설정..)

오픈 테스트를 진행하면서 활성화 및 서비스 안정화를 진행할 예정입니다. 그래서 막간 홍보

For the site tree, see the [root Markdown](https://slashpage.com/dogma13.md).