바이브 코딩 실전 7화: AI가 코드를 망쳐도 돌아갈 수 있게

지난 편에서는 드디어 MyLog 프로젝트를 만들고

flutter run

으로 첫 화면까지 띄워봤습니다.

아직 기록 작성 기능도 없고,

저장 기능도 없습니다.

그런데 저는 지난 편 마지막에 중요한 일을 하나 해두자고 했습니다.

바로 현재 상태를 Git에 저장하는 것입니다.

왜 이렇게 서두르는 걸까요?

아직 코드도 별로 없는데 말입니다.

이유는 간단합니다.

이제부터 AI에게 실제 코드를 수정하게 할 것이기 때문입니다.

그리고 AI는 코드를 정말 빠르게 만들어줍니다.

문제는 가끔

망가뜨리는 속도도 상당히 빠르다는 것입니다. 🤖💥

오늘은 AI에게 과감하게 일을 맡길 수 있도록 우리 프로젝트에 세이브 포인트를 만들어보겠습니다.

1. Git은 개발자만 쓰는 어려운 도구일까?

Git이라는 이름을 처음 들으면 조금 부담스럽습니다.

터미널에서 이상한 명령어를 입력하고,

Branch가 어떻고,

Merge가 어떻고,

Commit이 어떻고...

왠지 검은 화면에서 키보드를 빠르게 두드리는 개발자들의 전유물처럼 보입니다.

하지만 바이브 코딩에서 우리가 알아야 할 Git은 훨씬 단순합니다.

처음에는 이렇게만 생각해도 됩니다.

게임을 생각해보겠습니다.

보스를 만나기 전에 저장합니다.

SAVE

전투를 시작합니다.

잘못됐습니다.

HP가 0이 됐습니다.

그러면 이전 세이브 포인트로 돌아갑니다.

Git도 거의 같은 역할을 합니다. 🎮

2. 바이브 코딩에서 Git은 오히려 더 중요하다

전통적인 개발에서는 개발자가 직접 코드를 수정합니다.

그래서 어느 파일을 어떻게 수정했는지 어느 정도 기억하고 있습니다.

하지만 AI 코딩 에이전트에게 이렇게 말한다고 해보겠습니다.

AI는 잠시 생각하더니

화면 파일을 수정하고,

데이터 모델을 수정하고,

저장 로직을 수정하고,

라우팅도 바꾸고,

테스트 파일까지 건드립니다.

총 8개 파일이 변경됐습니다.

우리는 요청을 한 문장 했을 뿐인데 말이죠.

그리고 앱을 실행합니다.

안 됩니다.

그 순간 머릿속에 떠오르는 문장.

바이브 코딩에서 Git이 중요한 이유가 바로 이것입니다.

AI는 사람보다 훨씬 넓은 범위를 짧은 시간 안에 수정할 수 있습니다.

그래서

변경 전 상태를 남기는 습관

이 더 중요해집니다.

3. Git과 GitHub는 같은 것이 아니다

비개발자라면 여기서 자주 헷갈립니다.

Git을 이야기하면 곧바로 GitHub를 떠올립니다.

하지만 둘은 다릅니다.

Git

내 컴퓨터에서 코드 변경 이력을 관리하는 도구

GitHub

Git 저장소를 인터넷에 올려 공유하고 협업할 수 있는 서비스

입니다.

쉽게 말하면

Git은 사진을 찍는 카메라이고,

GitHub는 그 사진을 올려두는 클라우드 앨범에 가깝습니다.

Git만으로도 내 컴퓨터에서 버전관리를 할 수 있습니다.

우리는 먼저 로컬 Git부터 제대로 사용하는 것에 집중하겠습니다.

4. Git의 핵심은 딱 세 가지부터

처음부터 Git의 모든 기능을 알 필요는 없습니다.

우리가 먼저 기억할 것은 세 가지입니다.

변경 확인

↓

저장할 내용 선택

↓

Commit

조금 더 실제 명령으로 보면

git status
git add
git commit

입니다.

겁먹지 마세요.

하나씩 보면 정말 단순합니다.

5. git status, 지금 무슨 일이 벌어졌는지 확인한다

프로젝트 폴더에서

git status

를 실행합니다.

이 명령은 현재 프로젝트 상태를 보여줍니다.

예를 들어 AI가 몇 개 파일을 수정했다면 어떤 파일이 변경됐는지 확인할 수 있습니다.

쉽게 말하면

라고 묻는 명령입니다.

AI에게 작업을 맡긴 뒤 가장 먼저 익혀두면 좋은 습관입니다.

AI 작업 완료

↓

git status

↓

변경 파일 확인

AI가

라고 했는데 git status를 보니 12개가 변경돼 있다?

그럼 한번 더 확인해볼 이유가 생긴 겁니다. 👀

6. Diff, 정확히 무엇이 바뀌었는지 본다

파일 이름만 보는 것으로 부족할 때가 있습니다.

그럴 때는 Diff를 확인합니다.

Diff는 변경 전과 변경 후의 차이입니다.

예를 들어

- String title;
+ final String title;

처럼 어떤 코드가 빠지고 어떤 코드가 추가됐는지 보여줍니다.

GUI 기반 에디터에서는 보통 삭제된 코드는 빨간색,

추가된 코드는 초록색 등으로 표시해줍니다.

처음에는 코드를 완전히 이해하지 못해도 괜찮습니다.

우리가 확인할 것은 이런 것입니다.

완벽하게 읽지 못해도 변경 범위를 보는 습관 자체가 중요합니다.

7. Commit, 지금 상태를 저장한다

이제 변경 내용이 정상이라고 판단되면 저장합니다.

Git에서는 이 저장 지점을 Commit이라고 합니다.

예를 들어

git add .

로 변경 내용을 저장 대상으로 올리고,

git commit -m "Flutter 프로젝트 첫 실행 확인"

처럼 커밋합니다.

여기서 메시지가 중요합니다.

나중에 봤을 때

를 알 수 있어야 합니다.

좋은 예는 이런 식입니다.

기록 목록 화면 추가

기록 작성 화면 구현

로컬 저장 기능 추가

제목 필수 입력 검증 추가

반대로 이런 메시지는 별로 도움이 되지 않습니다.

수정

작업함

업데이트

최종

한 달 뒤 보면 아무 의미가 없습니다.

Git이 타임머신이라면 Commit 메시지는 시간여행 목적지의 표지판입니다.

"여기쯤이었던 것 같은데..."가 되지 않게 해줍니다. 🪧

8. 한 기능이 끝날 때마다 Commit 하면 될까?

대체로 좋습니다.

하지만 조금 더 정확한 기준을 잡아보겠습니다.

커밋하기 좋은 순간은

작고 의미 있는 작업 하나가 정상적으로 끝났을 때입니다.

예를 들어

기록 목록 화면 정상

→ Commit

그다음

기록 작성 화면 정상

→ Commit

다음

로컬 저장 정상

→ Commit

이런 방식입니다.

반대로 다음처럼 해서는 복구하기 어려워집니다.

로그인
검색
사진
다크모드
데이터베이스
UI 수정
버그 수정

↓

전부 끝난 뒤 Commit

이건 세이브 포인트를 마지막 보스 앞에 하나만 만드는 것과 비슷합니다.

중간에 어디서 망가졌는지 찾기가 어렵습니다.

9. AI에게 작업시키기 전에도 Commit 한다

이 습관은 앞으로 아주 자주 사용하겠습니다.

예를 들어 현재 MyLog 앱이 정상적으로 실행됩니다.

이제 AI에게 새로운 기능을 요청하려고 합니다.

먼저 이렇게 생각합니다.

대부분 YES입니다.

그래서 먼저 Commit 합니다.

현재 앱 정상 동작

↓

Commit

↓

AI에게 새 기능 요청

이제 AI가 프로젝트를 엉망으로 만들어도 최소한 돌아갈 곳은 있습니다.

비개발자 바이브 코딩에서는

AI에게 일을 시키기 전에 저장

이 아주 좋은 습관입니다.

10. 작업을 너무 크게 시키지 않는 이유도 Git과 연결된다

지난 편들에서 계속 강조했습니다.

AI에게 한 번에 너무 많은 일을 맡기지 말자고 했습니다.

Git에서도 같은 이유가 있습니다.

AI에게

라고 요청했다고 해보겠습니다.

변경 파일이 20개입니다.

앱은 실행되는데 검색만 이상합니다.

그럼 어떤 변경 때문에 문제가 생긴 걸까요?

찾기가 어렵습니다.

반대로

기록 목록 UI 수정
→ 확인
→ Commit

검색 기능 추가
→ 확인
→ Commit

에러 처리 추가
→ 확인
→ Commit

이면 문제 발생 지점을 훨씬 쉽게 좁힐 수 있습니다.

작은 작업 단위와 Git은 아주 잘 맞습니다.

11. AI가 코드를 망쳤다. 어떻게 돌아갈까?

드디어 Git을 쓰는 가장 즐거운 순간입니다.

물론 이런 순간이 안 오는 게 더 좋습니다. 😅

AI에게 기능을 추가했는데 앱이 실행되지 않습니다.

수정을 또 요청했습니다.

더 이상해졌습니다.

세 번째 수정도 실패했습니다.

이때 흔히 하는 실수가 있습니다.

AI에게 계속 말합니다.

AI도 원래가 정확히 무엇이었는지 헷갈릴 수 있습니다.

이럴 때는 Git 기록을 기준으로 판단합니다.

먼저

git log --oneline

으로 커밋 목록을 확인할 수 있습니다.

예를 들면

a31f82d 기록 작성 화면 구현
c185430 기록 목록 화면 구현
b742ca1 Flutter 프로젝트 첫 실행 확인

이런 식입니다.

우리가 원하는 정상 상태가 명확하게 남아 있습니다.

12. 복구는 무작정 명령어부터 치지 말자

여기서 주의할 점이 있습니다.

Git에는 변경을 되돌리는 방법이 여러 가지 있습니다.

restore

revert

reset

등이 있습니다.

이 명령들은 상황에 따라 의미가 다르고, 잘못 사용하면 현재 작업을 잃을 수도 있습니다.

그래서 비개발자라면 처음에는

"이 명령을 실행하면 어떤 변경이 사라지는지 먼저 설명해줘."

라고 AI에게 묻는 것이 좋습니다.

예를 들면

현재 Git 상태를 확인해줘.

마지막 커밋 이후 AI가 수정한 내용만 버리고
마지막 정상 커밋 상태로 돌아가고 싶다.

아직 명령은 실행하지 말고

1. 현재 변경 상태
2. 어떤 명령을 사용할지
3. 사라지는 변경
4. 복구 가능한지

먼저 설명해줘.

그다음 이해한 뒤 실행합니다.

특히 reset --hard 같은 명령은 강력합니다.

강력한 도구는 항상 두 얼굴을 가지고 있습니다.

잘 쓰면 구조대,

잘못 쓰면 철거반입니다. 🚧

13. Branch는 왜 필요한가?

Git을 조금 검색하면 곧 Branch라는 말을 만나게 됩니다.

처음에는 어렵게 생각하지 않아도 됩니다.

Branch는

이라고 생각하면 됩니다.

현재 MyLog가 이렇게 있다고 해보겠습니다.

main

기록 작성
기록 저장
목록 보기

여기에 대규모 UI 개편을 해보고 싶습니다.

바로 main에서 작업하는 대신

feature/new-ui

라는 Branch를 하나 만듭니다.

그리고 그쪽에서 AI에게 과감하게 시켜봅니다.

main
│
├── 안정적인 기존 앱
│
└── feature/new-ui
      └── 새로운 UI 실험

실험이 성공하면 합치고,

실패하면 Branch를 버리면 됩니다.

본진은 살아 있습니다. 🏰

14. 그런데 첫 프로젝트부터 Branch를 많이 써야 할까?

아닙니다.

혼자 만드는 작은 MVP라면 초반에는

main

하나만 잘 관리해도 충분합니다.

작업이 커질 때 Branch를 사용하면 됩니다.

예를 들어

큰 UI 개편,

데이터 저장 구조 변경,

로그인 추가,

배포 설정 변경

처럼 프로젝트 전체에 영향이 큰 작업입니다.

처음부터

develop
feature
release
hotfix

구조를 완벽하게 만들 필요는 없습니다.

우리는 개발팀 30명이 아닙니다.

아직 MyLog 개발자는

사람 1명 + AI 직원 몇 명

정도입니다. 😎

15. .gitignore라는 것도 기억해두자

Git을 사용하다 보면 .gitignore라는 파일을 만나게 됩니다.

이름 그대로

입니다.

예를 들어

자동 생성 파일,

빌드 결과,

환경에 따라 달라지는 파일,

민감한 설정 파일

등은 Git에 올리지 않는 것이 좋습니다.

Flutter 프로젝트를 만들면 기본적으로 적절한 .gitignore 파일도 생성됩니다.

하지만 나중에 API Key나 환경변수를 사용하기 시작하면 이 부분이 굉장히 중요해집니다.

우리가 #16에서 보안을 다룰 때 다시 제대로 만나게 될 겁니다.

지금은 하나만 기억하겠습니다.

Git은 기억력이 너무 좋아서 한번 남긴 비밀을 지우기가 생각보다 번거롭습니다.

비밀 일기장을 영구 기록 보관소에 넣는 것과 비슷합니다. 🔐

16. GitHub에 올리는 건 언제 할까?

GitHub 같은 원격 저장소를 사용하면 추가적인 장점이 있습니다.

컴퓨터가 고장 나도 코드를 복구할 수 있고,

다른 기기에서도 작업할 수 있고,

협업할 수도 있습니다.

하지만 우리 첫 번째 목표는 Git 개념을 익히는 것입니다.

우선 로컬에서

변경
↓
확인
↓
Commit
↓
복구

흐름을 먼저 익히겠습니다.

원격 저장소 연결은 필요해지는 시점에 진행해도 늦지 않습니다.

중요한 것은 GitHub 계정을 만드는 것이 아니라

버전관리 습관을 만드는 것입니다.

17. AI에게 Git 작업을 전부 맡겨도 될까?

가능은 합니다.

코딩 에이전트에게

라고 할 수 있습니다.

하지만 초반에는 AI가 자동으로 커밋하게 두기보다 우리가 한번 확인하고 커밋하는 것을 권합니다.

왜냐하면 Commit은 단순한 저장 버튼이 아니라

라는 의미이기 때문입니다.

따라서 처음에는 이런 흐름이 좋습니다.

AI

작업 완료

↓

사람

앱 실행 확인

↓

사람

git status / Diff 확인

↓

사람

정상 여부 판단

↓

Commit

AI에게 Git 명령 실행을 맡기더라도

커밋 시점은 사람이 결정하는 것

이 좋습니다.

18. AI에게 작업 후 보고서를 시켜보자

앞으로 아주 유용하게 쓸 프롬프트 하나를 만들어보겠습니다.

AI가 코딩을 완료했을 때 이렇게 요청합니다.

작업이 끝났다면 아직 커밋하지 마.

먼저 다음 내용을 보고해줘.

1. 변경한 파일 목록
2. 각 파일에서 변경한 내용
3. 새로 추가한 패키지
4. 삭제한 코드나 파일
5. 실행 또는 테스트 결과
6. 기존 기능에 영향을 줄 가능성
7. Git에 커밋해도 되는 상태인지

내가 확인한 뒤 커밋한다.

이렇게 하면 AI가 작업자이면서 동시에 변경 보고서를 작성하는 역할도 합니다.

비개발자가 모든 코드를 읽을 수 없어도

무엇이 변했는지 추적하는 습관

을 만들 수 있습니다.

19. Commit 메시지도 AI에게 도움받을 수 있다

변경 내용을 확인한 다음 이런 요청은 괜찮습니다.

예를 들어

feat: 기록 작성 화면 추가

또는

feat: 로컬 기록 저장 기능 구현

같은 메시지를 제안할 수 있습니다.

나중에는 feat, fix, refactor 같은 규칙도 조금씩 익힐 수 있습니다.

하지만 지금 중요한 것은 형식보다 의미입니다.

6개월 뒤 내가 봐도

무엇을 했는지 알 수 있는 메시지

면 충분합니다.

20. MyLog에서는 이렇게 운영하자

앞으로 우리 연재에서 사용할 기본 Git 흐름을 정해보겠습니다.

1. 현재 앱이 정상인지 확인

↓

2. git status 확인

↓

3. 필요하면 Commit

↓

4. AI에게 작은 작업 하나 요청

↓

5. 변경된 파일 확인

↓

6. 앱 실행 / 테스트

↓

7. 정상이라면 Commit

↓

8. 다음 작업 진행

이게 앞으로 계속 반복될 기본 루프입니다.

조금 번거롭게 느껴질 수도 있습니다.

하지만 프로젝트가 커질수록 이 몇 분이 몇 시간을 구해줍니다.

21. 오늘의 삽질 방지 팁 🛠️

바이브 코딩을 하다가 앱이 망가졌을 때 가장 먼저 AI에게

라고 말하지 마세요.

먼저 물어봅니다.

마지막 정상 Git Commit 이후
어떤 파일이 변경됐는지 확인해줘.

아직 수정하지 말고
현재 변경 중 문제가 될 가능성이 높은 부분을
먼저 분석해줘.

이 방법의 장점은 AI가 현재 코드만 보는 것이 아니라 정상 상태와 차이를 기준으로 문제를 찾게 한다는 것입니다.

디버깅 범위가 훨씬 줄어듭니다.

Git은 단순히 복구용 도구가 아닙니다.

AI에게 좋은 단서를 제공하는 디버깅 지도이기도 합니다.

22. Git을 쓰면 AI에게 더 과감하게 시도할 수 있다

Git의 진짜 장점은 망가졌을 때 복구하는 것만이 아닙니다.

오히려 더 큰 장점은

실험하기 쉬워진다는 것입니다.

해봅니다.

별로입니다.

돌아옵니다.

해봅니다.

문제가 생깁니다.

돌아옵니다.

Git이 없으면 큰 변경이 무섭습니다.

Git이 있으면

가 가능합니다.

바이브 코딩의 빠른 실험 속도와 Git은 꽤 좋은 조합입니다.

AI는 액셀이고,

Git은 브레이크이자 후진 기어입니다.

빠른 차일수록 둘 다 필요합니다. 🚗💨

23. 오늘 기억할 Git 다섯 가지

복잡한 명령어는 잠시 잊고 이것만 기억해두겠습니다.

Repository

Git으로 관리되는 프로젝트

Status

현재 어떤 파일이 변경됐는지 확인

Diff

구체적으로 무엇이 달라졌는지 확인

Commit

현재 정상 상태를 저장하는 세이브 포인트

Branch

기존 정상 상태를 보호하면서 별도로 실험하는 작업 공간

이 정도면 앞으로 바이브 코딩을 진행하기에 충분합니다.

나머지는 필요할 때 하나씩 배우면 됩니다.

24. 오늘의 완료 조건

이번 편도 완료 기준을 만들어보겠습니다.

[ ] MyLog 프로젝트의 Git 상태를 확인했다.

[ ] git status가 무엇을 보여주는지 이해했다.

[ ] 변경 파일의 Diff를 확인해봤다.

[ ] Commit의 의미를 이해했다.

[ ] 의미 있는 Commit 메시지를 작성했다.

[ ] AI 작업 전 Commit을 남기는 이유를 이해했다.

[ ] 문제가 발생했을 때 Git 기록을 기준으로 복구한다는 원칙을 익혔다.

[ ] Branch가 무엇인지 개념적으로 이해했다.

[ ] API Key 같은 민감한 값을 Git에 저장하면 안 된다는 것을 기억했다.

여기까지 왔다면 이제 AI에게 코드를 수정시키는 것이 훨씬 덜 무섭습니다.

우리 뒤에 처음으로 제대로 된 안전망이 생겼으니까요.

이제 PRD도 있고,

프로젝트도 있고,

Git이라는 안전장치도 준비했습니다.

그렇다면 바로 첫 기능을 만들면 될까요?

한 가지가 더 있습니다.

AI에게 매번

같은 말을 반복하다 보면 슬슬 피곤해집니다.

그래서 다음 편에서는 AI가 프로젝트의 규칙을 지속적으로 이해하게 만드는 방법을 알아보겠습니다.

프로젝트 규칙,

코딩 원칙,

작업 방식,

완료 기준,

금지 사항

등을 문서화해서 AI가 새로운 작업을 시작할 때마다 기준으로 사용하도록 만들어봅니다.

다음 편은

[바이브 코딩 실전 #08] AI에게 매번 설명하지 마세요 | 프로젝트 규칙과 컨텍스트 관리법

입니다.

여기까지 준비하면 그다음부터는 정말 화면을 만들기 시작합니다.

이제 AI 직원에게 업무 매뉴얼 한 권만 건네주면 됩니다. 📘🤖

#바이브코딩 #VibeCoding #AI코딩 #Git #Git사용법 #버전관리 #비개발자Git #비개발자앱개발 #AI에이전트 #GitCommit #GitBranch #GitDiff #Flutter #MVP개발 #MyLog #바이브코딩실전