Vibe Coding Hangover: AI가 코드베이스를 망치는 것을 막는 방법

Source: Dev.to

문제

그 느낌을 아시죠.

토요일 밤에 Claude나 Cursor와 3시간을 보냅니다. 흐름에 몸을 맡깁니다. 프롬프트를 입력하고, AI가 생성하고, 붙여넣기. 앱이 동작합니다. 비전문가 친구들에게 보여주면 여러분을 천재라 생각하고, 마치 초능력을 얻은 듯합니다. 인생이 좋습니다.

그런데 숙취가 찾아옵니다.

버그를 발견하거나 “빠른” 기능을 추가하고 싶어집니다. 혹은 더 심각하게, 프로덕션에 푸시했는데 사용자가 문제를 겪기 시작합니다. 갑자기 여러분은 직접 쓰지 않은 수천 줄의 코드를 마주하고, 솔직히 말해 이해도 잘 되지 않습니다. AI에게 “수정해줘”라고 애원하지만, AI는 3일 전 왜 그런 결정을 내렸는지 기억하지 못해 소스에 또 다른 스파게티를 얹을 뿐입니다. 끝없는 AI 루프에 빠져 원을 그리며 맴돌게 됩니다.

이것이 *“Vibe Coding”*의 불편한 진실입니다. 프로토타입과 해커톤에서는 마법과도 같고, 무에서 유용한 무언가를 만들 때는 정말 놀랍습니다. 하지만 몇 달 동안 운영·디버그·확장이 필요한 실제 앱에서는 Vibe Coding이 거대한 유지보수 골칫거리가 됩니다. 기술 부채를 Vibe‑프롬프트만으로 해결할 수는 없습니다; 어느 시점에서는 실제 사람이 코드를 책임져야 합니다.

해결책: AI에게 핸드북을 제공하라

문제는 AI가 아니라 제약과 기억이 부족하다는 점입니다.

우리가 수동으로 코딩할 때는 (희망컨대) 내부 표준이 있습니다: “중복을 피하라”, “죽은 import는 정리하라”, “왜 그런지 문서화하라”. AI를 사용할 때는 속도를 위해 이러한 표준을 버리는 경향이 있습니다.

이를 해결하려면 AI를 마법의 지팡이가 아니라 매우 빠르고, 매우 건망증이 심한 신입 개발자처럼 다루세요. 엄격히 적용되는 사원 핸드북을 제공하십시오.

Claude(claude.md), Cursor(.cursorrules), 혹은 CLI 도구(AGENTS.md)를 사용하든, 위생을 강제하고 가장 중요한 외부 메모리를 유지하는 시스템 프롬프트가 필요합니다.

“시니어 엔지니어” 프롬프트

두 가지 거대한 문제를 해결하는 구체적인 명령 세트를 반복해 왔습니다:

• 코드 팽창 – AI가 진행하면서 리팩터링을 강제합니다.
• 건망증 – AI가 수행한 작업을 DEVLOG.md에 기록하도록 강제해, 다음 컨텍스트 창이 무슨 일이 있었는지 알 수 있게 합니다.

다음 내용을 AI 지시 파일에 복사‑붙여넣기 하세요:

# Project Guidelines & Philosophy

## 1. Code Quality: The Boy Scout Rule
Every session should improve the codebase, not just add to it. Actively refactor code you encounter, even outside your immediate task scope.

- **Don't Repeat Yourself (Rule of Three):** Consolidate duplicate patterns into reusable functions only after the 3rd occurrence. Do not abstract prematurely.
- **Hygiene:** Delete dead code immediately (unused imports, functions, variables, commented code). If it's not running, it goes.
- **Leverage:** Use battle‑tested packages over custom implementations. Do not reinvent the wheel unless the wheel is broken.
- **Readable:** Code must be self‑documenting. Comments should explain *why*, not *what*.
- **Safety:** If a refactor carries high risk of breaking functionality, flag it for user review rather than applying it silently.

## 2. Persistent Context & Memory
Since our context resets between sessions, we use files to track our brain.

**The Dev Log (`DEVLOG.md`)**  
At the completion of a task, you must check if `DEVLOG.md` exists. If so, propose an append summarizing:
1. **The Change:** High‑level summary of files touched.  
2. **The Reasoning:** Why we made specific structural decisions.  
3. **The Tech Debt:** Any corners we cut that need to be fixed later.

**Goal:** If a new developer (or a new AI session) joins tomorrow, they should be able to read `DEVLOG.md` and understand the state of the project immediately.

**Operational Rule**  
- After every interaction that includes a code change, you must append an entry to `DEVLOG.md` before finishing. Do not just suggest it. If you truly cannot write to the file (permissions/conflicts), provide the exact snippet the next person should paste. This is mandatory and should be treated as a checklist item for every task.

왜 효과가 있는가

1. “세 번의 규칙” 가드레일

AI 모델은 추상화를 좋아합니다. “세 번의 규칙”(세 번째 중복이 나타날 때까지 DRY 하지 않음)을 강제하면 AI가 단순 작업을 과도하게 설계하거나 불필요한 헬퍼 함수를 만드는 것을 막을 수 있습니다.

2. DEVLOG.md 앵커

AI 모델은 단기 기억 상실이 있습니다. 매 세션 종료 시 AI가 자신의 결정 요약을 마크다운 파일에 기록하도록 강제하면 프로젝트의 뇌를 위한 외부 하드 드라이브가 생깁니다. 새로운 세션이 시작될 때 AI는 DEVLOG.md를 읽고 즉시 다음과 같은 정보를 알 수 있습니다:

• “지난 화요일에 date-fns로 교체했습니다.”
• “그 API 엔드포인트를 반쯤 남겨두었습니다.”

요약

Vibe coding은 재미있지만, 엔지니어링은 장기성을 의미합니다. 모델에 제약을 두지 않으면 AI는 “지금 바로 동작하게 만들기”에 집중하고 “나중에 유지보수하기 쉬운 코드”는 무시합니다. 위 프롬프트를 사용해 AI가 여러분만큼 코드베이스를 존중하도록 강제하세요.

특정 시스템 프롬프트를 사용해 AI를 관리하고 계신가요? 댓글로 알려 주세요.