현업 개발자의 바이브코딩 설계 진단 · 개선법

한 줄 핵심

커서(Cursor)는 속도, 대화 품질, UI 가독성, 컨텍스트 활용 면에서 현업형 바이브 코딩에 매우 강력했으며, 클로드 코드보다 실무 피드백·설계 진단·UI 검증을 더 쾌적하게 수행할 수 있었다.

시간별 요약

1. 0:04
   커서로 시작한 이유 Claude Code 대신 Cursor를 선택해 속도와 평판을 시험해 보며, 평소 쓰던 도구를 다시 평가하는 흐름을 만든다. 빠른 반응과 그록(Grok) 모델의 응답 속도가 핵심 기대 포인트로 제시된다.
2. 2:01
   방치된 프로젝트 재진단 오래 방치된 프로젝트를 다시 이해하고 수습하는 상황을 통해, 바이브 코딩이 길어질수록 프로젝트 전체를 잃기 쉬운 문제를 보여 준다. 먼저 기술 스택과 인프라, 앱 구조를 파악하는 것이 출발점으로 잡힌다.
3. 6:00
   큰 구조와 DB 흐름 파악 서비스의 큰 설계와 데이터베이스 흐름을 먼저 묻고, 핵심 테이블과 데이터 플로우를 이해하려고 한다. 비개발자도 이해할 수 있게 쉽게 설명해 달라는 요구가 추가되며, 전사 정확도와 용어 보존의 중요성이 드러난다.
4. 10:01
   문서화의 효용과 한계 스펙을 따로 저장하는 방식은 개인 프로젝트에서는 중복과 유지보수 비용이 커서 비효율적일 수 있다고 본다. 코드 자체가 스펙이라는 관점이 강해지고, 문서는 작업 명세처럼 일시적으로만 유효하다는 인식이 정리된다.
5. 15:05
   도구와 컨텍스트 최적화 Cursor가 제공하는 린트, 서브에이전트, 브라우저, 룰 같은 기능을 확인하며 컨텍스트 최적화 수단을 점검한다. 도구를 설명할 때는 근거를 참조해야 하며, 공식 문서 기반의 답변이 신뢰도를 높인다는 점이 강조된다.
6. 24:03
   기존 유스케이스 문서의 보강 자동 생성된 유스케이스 문서가 실제 흐름을 충분히 담지 못해, 더 구체적인 코스 스타일 유스케이스로 보강하도록 요구한다. 테이블명과 컬럼명을 원문 그대로 유지해야 데이터 흐름을 정확히 이해할 수 있다는 문제의식도 드러난다.
7. 35:03
   아키텍처와 계층 침범 점검 클린 코드와 레이어드 아키텍처 준수 여부를 진단하도록 하고, Mermaid 다이어그램으로 구조를 브리핑받고자 한다. 다른 모듈의 테이블을 직접 읽는 식의 계층 침범이 발견되며, 구조적 수정 필요성이 제기된다.
8. 43:01
   침범 방지와 패키지 분리 논의 계층 침범을 당장 엄밀하게 잡을지, 코드베이스 비대화를 감수할지 비판적으로 검토한다. shared 패키지에 다양한 성격의 코드가 섞여 있는 문제를 분리할지 여부를 현실적인 비용과 함께 판단하게 한다.
9. 53:00
   그록과 클로드 코드 비교 그록은 설명이 더 쉽고 빠르며, 클로드 코드는 분석력은 괜찮지만 글발과 커뮤니케이션이 떨어진다는 인상이 강해진다. 같은 작업이라도 이해 가능한 언어로 설명해 주는 도구가 실무 체감이 훨씬 좋다는 결론에 가까워진다.
10. 1:04:02
    검증 게이트 설계 린터, 바이테스트 계약 테스트, 아키텍처 규칙 등으로 계층 침범을 프로그램적으로 막을 방법을 논의한다. 단순 문서 규칙보다 강제력이 있는 게이트를 세워야 재발을 줄일 수 있다는 관점이 정리된다.
11. 1:10:12
    테스트 수명과 유지비 테스트 규칙의 수명이 얼마나 오래 갈지, 그리고 린터·테스트·규칙 사이의 비용 대비 효과가 어떤지 고민한다. 개인용 MVP처럼 자주 바뀌는 제품에서는 과도한 분리는 오히려 유지보수를 망칠 수 있다는 판단이 나온다.
12. 1:18:02
    Prisma 변환과 추상화 방식 Prisma의 날짜 컬럼 변환을 공용 레벨에서 자동 처리할지, 별도 유틸로 둘지, 혹은 모노레포 패키지로 감쌀지 논의한다. Next.js 친화성, 의존성 역전, 데코레이터 같은 구현 방식의 적절성을 비교하게 된다.
13. 1:27:24
    착수 전 합의와 모델 선택 개발을 시작하기 전에 해야 할 작업을 목록화하고, 커서의 응답 속도와 사용 경험을 강하게 긍정한다. 바이브 코딩에서는 모델의 절대 성능보다 속도, 설명력, 피드백 품질이 더 중요할 수 있다는 시각이 드러난다.
14. 2:01:01
    UX 단순화와 MVP 실험 트레이너가 첫 사용에서 가치를 바로 체험해야 한다는 관점으로, 기능이 너무 많고 복잡한지 점검한다. 첫 실험에서 보여 줄 핵심 흐름과 나중에 보여 줄 요소를 분리해야 MVP 실험이 성립한다는 결론이 나온다.
15. 2:26:00
    화면 흐름과 입력 UX 개선 첫 가치 체험 이후의 화면 흐름과 종목 추가 방식까지 구체화하며, 체크 아이콘 위치나 운동 타입 선택 같은 세부 UX를 다듬는다. 숫자 입력과 종목 추가 과정이 너무 번거롭지 않도록 재설계가 필요하다는 점이 드러난다.
16. 2:56:00
    디자인 폴더와 산출물 정리 HTML 기반 중간 레이어가 토큰과 시간을 낭비한다고 판단해 디자인 폴더를 제거하려 한다. 이후에는 기획을 구체화한 뒤 이미지 생성으로 미리보기를 보는 방식이 더 낫다고 정리된다.
17. 3:21:00
    테스트 수준과 외부 의존성 단위 테스트, 렌더링 테스트, E2E, 스토리지·DB 연동 테스트의 경계를 다시 구분한다. 실제 DB가 꼭 필요한지, 로컬 도커로 대체할 수 있는지, 외부 인프라 의존 테스트는 별도 품질 게이트로 취급해야 하는지 고민이 이어진다.
18. 3:47:07
    규칙 문서화와 탐지 장치 문서만으로는 규칙이 약하므로, 지켜지지 않았을 때 탐지할 장치가 필요하다는 문제를 다룬다. 커밋 타이밍, 훅, CI, 작업 명세의 수명 관리까지 포함해 실무적으로 유지 가능한 형태를 고민한다.
19. 4:39:00
    훅과 CI의 역할 분리 프리푸시 훅과 CI의 역할을 구분해, 로컬에서 빠르게 막을 것과 원격에서 최종 검증할 것을 분리한다. 푸시 타이밍을 매번 신경 쓰지 않도록 개발자가 알아서 판단하는 수준의 자동화를 설계하려는 방향이 잡힌다.
20. 5:04:03
    최종 결론과 커서 추천 검증 게이트, CI, 문서, 푸시 정책까지 정리하고 나서, 커서가 바이브 코딩에 가장 잘 맞는 도구라는 결론에 도달한다. 빠르고, 설명이 친절하고, UI가 좋고, 컨텍스트 관리도 실무적으로 쓸 만하다는 점이 최종 추천 이유가 된다.

실무 인사이트

• 바이브 코딩에서도 코드보다 먼저 아키텍처·데이터 흐름·검증 게이트를 잡아야 나중에 수습 비용이 크게 줄어든다.
• 문서는 영구 진실이 아니라 작업 명세로 쓰는 편이 낫고, 장기 신뢰는 린터·테스트·CI 같은 강제 장치로 확보해야 한다.
• 에이전트 선택은 절대 성능보다 속도, 설명력, UI 가독성, 컨텍스트 비용까지 함께 봐야 실무 효율이 높다.