작게 반복하기

바이브 코딩에서 가장 흔한 실수는 한 번에 너무 많이 만드는 것이다. 큰 덩어리를 받아 한꺼번에 실행하면, 어디가 틀렸는지 찾는 데 더 오래 걸린다. 작게 만들고, 바로 돌려보고, 확인하고, 커밋한다. 이 짧은 루프가 빠르면서도 안전한 작업의 핵심이다.

학습 목표

• 작은 단위 반복이 왜 더 빠른지 이해한다.
• 만들기 → 실행 → 확인 → 커밋 루프를 실천한다.
• 단계마다 커밋해 안전하게 되돌릴 수 있게 한다.

피드백 루프

기본 리듬은 다음과 같다.

1. 작은 한 조각을 요청한다
2. 결과를 실행해 본다(직접 또는 에이전트에게 시켜서)
3. 의도대로 동작하는지 눈으로 확인한다
4. 좋으면 커밋한다 → 다음 조각으로

조각이 작을수록 2~3단계가 빨라지고, 문제가 생겨도 원인을 좁히기 쉽다. 10줄짜리 변경에서 버그를 찾는 것과 300줄에서 찾는 것은 난이도가 다르다.

한 번에 한 가지

3강에서 나눈 단계를 하나씩 진행한다. 예를 들어 댓글 기능이라면, 먼저 목록 렌더링만 시킨다.

> 1단계만 하자. 댓글 타입과 목 데이터 3개를 정의하고,
> 화면에 목록만 렌더해줘. 작성 폼은 아직 만들지 마.

실행해서 목록이 보이는지 확인한 뒤에야 다음으로 넘어간다. "아직 ~는 하지 마"라고 범위를 못 박는 것이 한 조각을 작게 유지하는 요령이다.

바로 실행해서 확인한다

만들어진 코드는 반드시 돌려본다. 에이전트에게 실행과 확인을 맡길 수도 있다.

> 개발 서버를 실행하고, 콘솔에 에러가 없는지 확인해줘.

npm run dev

화면이 의도대로인지, 콘솔에 빨간 에러가 없는지, 엣지 케이스(빈 목록 등)는 어떤지 본다. "코드가 그럴듯해 보인다"와 "실제로 동작한다"는 다르다.

단계마다 커밋한다

각 조각이 잘 동작하면 즉시 커밋한다. 커밋은 되돌릴 수 있는 안전한 지점을 만든다.

git add -A
git commit -m "댓글 목록 렌더링 추가"

커밋을 자주 해 두면, 다음 단계에서 일이 꼬여도 마지막 정상 지점으로 깔끔하게 되돌아갈 수 있다(다음 강의에서 다룬다). 큰 변경을 시작하기 전에는 반드시 먼저 커밋해 두는 것을 습관으로 삼는다.

> 방금까지 잘 동작하니 변경사항을 커밋해줘.
> 그다음 2단계인 작성 폼 추가로 넘어가자.

막혔을 때도 작게

한 조각이 자꾸 안 풀리면, 더 작게 쪼갠다. 폼 전체가 안 되면 입력 필드 하나만, 그것도 안 되면 정적 마크업만 먼저 만든다. 작은 성공을 쌓는 편이 큰 실패를 반복하는 것보다 빠르다.

안티패턴

• 한 번에 전부 요청하고 마지막에 한꺼번에 실행: 버그 원인 추적이 악몽이 된다.
• 확인 없이 다음으로 진행: 깨진 토대 위에 계속 쌓게 된다.
• 커밋 없이 큰 변경: 되돌릴 지점이 없어 통째로 손해 본다.
• 결과를 안 읽고 수락: 동작하는 듯해도 엉뚱한 것을 만들고 있을 수 있다.

요약

작게 반복하는 것이 빠른 길이다. 한 번에 한 조각만 만들고, 바로 실행해 의도대로 동작하는지 확인하고, 좋으면 커밋한다. 작은 단위는 문제의 원인을 좁혀 주고, 잦은 커밋은 안전한 되돌림 지점을 만든다. 막히면 더 작게 쪼개라. 속도는 큰 덩어리가 아니라 짧은 루프에서 나온다.