바이브 코딩 프로젝트의 6개월 후

바이브 코딩으로 프로젝트를 빠르게 만들었다. 그런데 6개월 뒤에도 이 프로젝트가 살아있을까?

이 시리즈의 마지막 글이다. 지금까지 바이브 코딩의 정의, 실패 패턴, 역할 전환, 워크플로우, 테스트, 1인 개발 시스템을 다뤘다. 이번 글에서는 지속 가능성을 이야기한다.

프로젝트는 완성되지 않는다

"완성했다"는 착각이 위험하다.

바이브 코딩으로 2주 만에 MVP를 만들었다고 치자. 동작한다. 유저도 있다. 그러면 끝인가?

아니다. 이제부터 시작이다.

• 버그가 나온다
• 유저가 기능을 요청한다
• 라이브러리가 업데이트된다
• 보안 취약점이 발견된다
• 서버 비용이 청구된다

프로젝트는 살아있는 것이다. 완성이 아니라 유지보수가 시작된 것뿐.

기술 부채의 복리 효과

바이브 코딩으로 빠르게 만들면, 그 속도만큼 기술 부채도 빠르게 쌓인다.

[1개월 차]
"테스트 나중에 쓰지"
"이 부분 나중에 리팩토링하지"
"일단 돌아가니까 넘어가자"

[3개월 차]
"버그 수정했는데 다른 데가 터졌네"
"이 코드 왜 이렇게 짰지?"
"테스트 없어서 무서워서 못 건드리겠다"

[6개월 차]
"새 기능 추가하려면 기존 코드 다 뜯어야 하는데"
"차라리 새로 만드는 게 빠르겠다"

기술 부채는 복리로 쌓인다. 초기에 "이번만" 넘어간 것들이 나중에 "전부" 문제가 된다.

6개월 생존 체크리스트

프로젝트가 6개월 뒤에도 살아남으려면 이것들이 필요하다.

1. 테스트 커버리지

□ 핵심 API에 통합 테스트가 있는가?
□ CI에서 테스트가 자동으로 돌아가는가?
□ 테스트 실패하면 배포가 막히는가?

테스트 없이 6개월 버티면 운이 좋은 거다. 대부분은 3개월 안에 "무서워서 못 건드리는" 상태가 된다.

2. 문서화

□ CLAUDE.md(또는 README)에 프로젝트 규칙이 있는가?
□ 복잡한 비즈니스 로직에 주석이 있는가?
□ 배포/운영 절차가 문서화되어 있는가?

3개월 전 코드는 남이 짠 코드다. 그 "남"은 과거의 나. 문서 없으면 기억 안 난다.

3. 모니터링

□ 에러가 발생하면 알림이 오는가?
□ 서버 상태를 확인할 수 있는가?
□ 유저 행동을 추적할 수 있는가?

"유저가 뭔가 안 된다고 하는데 뭐가 안 되는지 모르겠다"는 상황을 피해야 한다.

4. 백업과 롤백

□ DB 백업이 자동으로 되는가?
□ 배포 후 문제 생기면 롤백할 수 있는가?
□ 환경 변수와 설정이 버전 관리되는가?

"실수로 DB 날렸다"는 이야기를 남의 이야기로 만들어야 한다.

기술 부채 청산 전략

쌓인 기술 부채는 어떻게 갚나.

전략 1: 20% 시간

매주 하루(또는 몇 시간)를 기술 부채 청산에 쓴다.

[월~목] 기능 개발
[금요일] 기술 부채 청산
- 테스트 추가
- 리팩토링
- 문서 업데이트
- 의존성 업데이트

"나중에 한꺼번에 정리하지"는 절대 안 온다. 정기적으로 조금씩.

전략 2: 보이스카웃 규칙

"코드를 떠날 때는 들어올 때보다 깨끗하게."

버그 수정하러 들어갔으면:

• 버그 수정

• 관련 테스트 추가

• 근처 코드 약간 정리

기능 추가하러 들어갔으면:

• 기능 추가

• 테스트 추가

• 비슷한 기존 코드 통합

매번 조금씩 개선하면 기술 부채가 쌓이는 속도를 늦출 수 있다.

전략 3: 리팩토링 스프린트

기술 부채가 너무 쌓였으면, 한 주를 통째로 리팩토링에 쓴다.

[리팩토링 스프린트]
1. 가장 문제 되는 부분 3개 선정
2. 각각에 대해:
   - 현재 문제점 정리
   - 목표 상태 정의
   - 테스트 먼저 추가
   - 리팩토링
   - 테스트 통과 확인
3. 문서 업데이트

새 기능 개발을 멈추고 해야 해서 심리적으로 힘들다. 근데 안 하면 나중에 더 힘들다.

의존성 관리

6개월 동안 라이브러리 버전이 바뀐다. npm audit 돌리면 취약점 경고가 뜬다.

정기 업데이트

월 1회 의존성 업데이트를 한다.

# 업데이트 가능한 패키지 확인
npm outdated
 
# 마이너/패치 업데이트
npm update
 
# 메이저 업데이트 (주의)
npm install package@latest

메이저 버전 업데이트는 Breaking change가 있을 수 있으니 조심.

취약점 체크

npm audit
npm audit fix

CI에 넣어두면 취약점 생길 때 알림 받을 수 있다.

AI 코드의 장기 유지보수

바이브 코딩으로 만든 코드는 장기 유지보수에서 특별한 문제가 있다.

문제: "내가 안 짠 코드"

내가 직접 짜면 로직을 기억한다. AI가 짜면 기억이 없다. 6개월 뒤에 이 코드를 보면:

"이게 뭐지?" "왜 이렇게 짰지?" "이거 고쳐도 되나?"

해결: 의도 기록

AI에게 시킬 때 왜 이 기능이 필요한지를 같이 기록한다.

// BAD
"로그인 기능 만들어줘"
 
// GOOD  
"로그인 기능 만들어줘"
 
[기록: 2024-01-15]
목적: 관리자만 접근 가능한 페이지를 위해
결정: 이메일+비밀번호 방식 (OAuth는 복잡해서 나중에)
참고: 비밀번호는 bcrypt로 해싱

이 기록이 있으면 6개월 뒤에도 "왜 이렇게 했지?"에 답할 수 있다.

해결: 테스트가 문서

테스트 코드는 이 코드가 뭘 해야 하는지를 보여준다.

describe('로그인', () => {
  it('올바른 정보로 로그인하면 토큰을 반환한다', ...)
  it('존재하지 않는 이메일이면 USER_NOT_FOUND를 반환한다', ...)
  it('비밀번호가 틀리면 INVALID_PASSWORD를 반환한다', ...)
})

이 테스트만 봐도 로그인 API가 뭘 하는지 알 수 있다. 구현 코드를 안 봐도.

운영 비용

프로젝트가 살아있으면 비용이 든다.

예상 비용 (개인 프로젝트 기준)

도메인: 년 1~2만원
호스팅:
  - Vercel/Cloudflare (무료~월 2만원)
  - AWS/GCP (사용량 따라, 월 0~수십만원)
DB:
  - Supabase 무료 티어 (500MB)
  - 초과 시 월 2~3만원부터
기타:
  - 에러 모니터링 (Sentry 무료 티어)
  - 분석 (Google Analytics 무료)

개인 프로젝트면 무료 티어로 충분한 경우가 많다. 근데 트래픽 늘면 비용도 는다.

비용 폭탄 방지

• 알림 설정: 비용이 일정 금액 넘으면 알림
• 무료 티어 한도 파악: 언제 유료 전환되는지 알기
• 스케일 다운 옵션: 트래픽 없으면 줄이는 방법 알아두기

프로젝트 종료 조건

모든 프로젝트가 영원히 살아있을 순 없다. 종료할 때도 있다.

종료 고려 시점

• 유저가 없다 (6개월째 본인만 사용)
• 유지보수 비용 > 가치
• 더 좋은 대안이 생겼다
• 관심이 없어졌다

종료 방법

1. 점진적 종료: 새 기능 중단 → 유지보수만 → 공지 후 종료
2. 데이터 백업: 유저 데이터 내보내기 제공
3. 코드 아카이브: GitHub에 아카이브 상태로 보존
4. 문서화: 왜 종료했는지 기록

종료도 책임감 있게.

시리즈 마무리

"바이브 코딩 생존 가이드" 7편을 마친다.

핵심 메시지

1. 바이브 코딩은 도구다 - 좋은 도구지만 만능은 아니다
2. 구조가 필요하다 - 자유롭게 쓰되 규칙은 지켜야 한다
3. 검증이 핵심이다 - AI 코드를 믿지 말고 테스트로 확인
4. 역할이 바뀐다 - 구현자에서 감독자로
5. 지속 가능해야 한다 - 빠르게 만드는 것보다 오래 유지하는 게 어렵다

바이브 코딩의 미래

AI 코딩 도구는 계속 발전할 거다. 더 똑똑해지고, 더 많은 걸 할 수 있게 될 거다.

근데 핵심은 변하지 않는다:

• 뭘 만들지는 사람이 결정한다
• 맞는지 확인하는 건 사람 몫이다
• 책임은 사람에게 있다

도구가 아무리 좋아져도, 결국 그 도구를 쓰는 건 사람이다.

마지막으로

바이브 코딩은 자유를 준다. 코드를 직접 치지 않아도 되는 자유. 아이디어를 빠르게 현실로 만드는 자유.

하지만 책임은 사라지지 않는다. 코드의 품질, 사용자 경험, 보안, 유지보수... 모두 여전히 개발자의 책임이다.

이 시리즈가 그 책임을 다하는 데 도움이 됐으면 한다.

바이브 코딩은 자유를 주지만, 책임은 사라지지 않는다.