AI로 만든 앱에서 Git 사용하는 법

AI로 만든 앱에서 Git을 사용하려면 프로젝트를 Git 저장소에 연결하고, 작동하는 변경마다 커밋하며, 무엇이 바뀌었는지 한 줄로 적은 메시지를 남기고, .gitignore로 비밀 정보를 빼 두면 됩니다. 위험한 작업은 브랜치에서 하고, 다른 사람이 코드를 바꿨다면 프롬프트를 다시 주기 전에 pull 하세요. AI가 무언가를 망가뜨렸다면 그 위에 프롬프트를 계속 쌓지 말고 마지막으로 잘 작동하던 커밋으로 돌아가세요.

Git은 버전 관리 도구로, 코드가 저장된 모든 버전의 기록을 남깁니다. GitHub는 Git 저장소를 온라인에 보관하는 웹사이트입니다. 두 가지가 아직 낯설다면 GitHub가 무엇인지부터 읽어 보세요. 이 가이드는 대부분의 코드를 AI가 작성할 때 Git을 유용하게 만드는 습관에 관한 내용입니다.

AI와 작업할 때 Git이 더 중요한 이유

AI는 한 번의 턴에 파일 스무 개를 바꿀 수 있습니다. 빠르긴 하지만, 프롬프트 한 번으로 어제 테스트를 마친 기능이 조용히 깨질 수도 있다는 뜻이기도 합니다. Git을 쓰면 다음과 같은 것을 얻을 수 있습니다.

• 되돌아갈 길. 커밋된 어떤 버전이든 복원할 수 있습니다.
• 변경 기록. 프롬프트 하나가 정확히 어떤 파일과 어떤 줄을 건드렸는지 볼 수 있습니다.
• 빌더 바깥의 코드 사본. 코드가 내가 관리하는 곳에 남습니다.
• 표준화된 인계. 어떤 개발자, 호스팅 서비스, 도구든 Git 저장소를 기준으로 작업할 수 있습니다.

1단계: 저장소 연결하기

GitHub 등 비슷한 서비스에 저장소를 만들고(보통 비공개로), 프로젝트를 그 저장소에 연결하세요. Git을 지원하는 AI 앱 빌더 대부분은 설정 페이지의 "Connect GitHub" 버튼으로 이를 처리합니다. 버튼이 없다면 코드를 내보낸 뒤 직접 push 하거나, 개발자에게 한 번만 설정을 부탁하면 됩니다.

첫 push 전에, 저장소에 들어가면 안 되는 것이 제외되어 있는지 확인하세요.

.gitignore 파일을 확인해 줘. .env 파일, node_modules, 빌드 결과물 폴더, 비밀 정보가 들어 있는 파일이 모두 제외되어 있어야 해. 무엇을 추가했는지 알려 줘.

2단계: 작동하는 변경마다 커밋하기

커밋은 메시지가 붙은 저장 스냅샷입니다. 가장 중요한 습관은 무언가 작동하면 다음 요청을 하기 전에 커밋하는 것입니다.

1. 변경 하나를 요청합니다.
2. 미리보기에서 확인합니다.
3. 작동하면 커밋(또는 동기화)하고 메시지를 답니다.
4. 다음으로 넘어갑니다.

커밋을 작게 나누면 무언가 깨졌을 때 어떤 변경 때문인지 알 수 있고, 그 변경만 되돌리면 되므로 다른 작업은 지워지지 않습니다.

3단계: 나중에 읽어도 이해되는 메시지 쓰기

좋은 메시지는 무엇이 왜 바뀌었는지를 한 줄로 말해 줍니다.

• 좋은 예: 주문 페이지에 CSV 내보내기 추가
• 좋은 예: 오후 6시 이후 시간을 거부하던 예약 폼 수정
• 쓸모없는 예: update, changes, fix stuff

메시지는 AI에게 써 달라고 해도 됩니다.

마지막 커밋 이후의 변경 사항을 동사로 시작하는 한 줄로, 70자 이내로 요약해 줘.

4단계: 위험한 작업에는 브랜치 사용하기

브랜치는 별도로 진행하는 작업 흐름입니다. 브랜치에서 무언가를 시도하다가 잘 안 되면, 메인 버전을 건드리지 않고 버리면 됩니다.

다음과 같은 경우에 브랜치를 쓰세요.

• 변경이 큰 경우(화면 전체 재설계, 새 결제 흐름, 데이터베이스 변경 등).
• 다른 사람이 같은 앱을 함께 작업하는 경우.
• 실제 배포 전에 누군가 변경을 검토하길 원하는 경우.

작업이 끝나고 테스트까지 마치면 그 브랜치를 메인 브랜치에 병합(merge) 합니다. GitHub에서는 보통 풀 리퀘스트를 통해 진행합니다. 변경 내용을 보여 주는 검토 페이지입니다. 빌더가 한 개의 브랜치만 동기화한다면, 브랜치 관리는 GitHub 쪽에서 개발자가 맡을 수 있습니다.

5단계: 안전하게 되돌리기

프롬프트 때문에 앱이 깨졌을 때는 그 위에 프롬프트를 다섯 번 더 쌓고 싶은 충동을 참으세요. 마지막으로 잘 작동하던 버전으로 돌아간 뒤, 더 명확한 프롬프트로 다시 시도하는 편이 낫습니다.

• 빌더에서: 체크포인트나 복원 기능이 있다면 그것을 사용하세요.
• Git에서: git revert는 과거 커밋을 되돌리는 새 커밋을 만들어서 기록을 그대로 보존합니다. 다른 사람이 이미 가져간 코드라면 이 방법이 안전합니다.
• 공유 브랜치에서는 git push --force 사용을 피하세요. 정확한 이유를 모르는 한 모든 사람의 기록을 다시 쓰게 됩니다.

확신이 없다면 이렇게 물어보세요.

마지막 변경으로 로그인 페이지가 깨졌어. 이전 커밋과 비교해서 어떤 파일이 바뀌었는지 보여 주고, 각 변경이 무엇을 했는지 설명해 줘. 아직 아무것도 바꾸지는 마.

6단계: 프롬프트 전에 pull 하기

개발자나 다른 도구가 GitHub의 코드를 바꾸면, AI 빌더는 그 변경을 pull 로 가져오기 전까지 알지 못합니다. 오래된 코드를 기준으로 프롬프트를 주면 충돌이 생기고 작업이 사라질 수 있습니다.

• 세션을 시작할 때마다 pull 하세요.
• 누가 무엇을 편집하는지 정하고, 양쪽이 같은 파일을 동시에 수정하지 않도록 하세요.
• 병합 충돌(같은 줄을 두 사람이 바꾼 경우)이 생기면, 개발자나 AI에게 해결을 맡기고 왜 그렇게 선택했는지 설명받으세요.

예시 프롬프트

시작하기 전에: 지난 세션 이후 저장소에 무슨 변경이 있었는지 알려 줘. 커밋 내용을 요약해 줘.

다음 변경은 단독으로 해 줘. 각 주문서에 "복제" 버튼을 추가해 줘. 다른 것은 건드리지 마. 따로 커밋할 수 있게 해 줘.

과거 커밋까지 포함해서 API 키, 비밀번호, .env 파일이 Git에 추적되고 있지 않은지 확인해 줘. 파일 이름만 보고하고 값은 보여 주지 마.

흔한 실수

• 비밀 정보 커밋하기. 한 번 Git 기록에 들어간 키는 파일을 지운 뒤에도 노출된 상태입니다. 반드시 재발급하세요.
• 일주일에 한 번 거대한 커밋 하나. 한 가지 변경만 되돌리는 것이 불가능해집니다.
• "update" 같은 메시지. 무엇이 깨졌는지 찾을 수 없게 됩니다.
• 오래된 코드 기준으로 프롬프트하기. 다른 사람이 편집 중이라면 먼저 pull 하세요.
• 실수를 고치려고 강제 push 하기. 다른 사람의 작업을 지울 수 있습니다. 대신 revert 하세요.
• node_modules 커밋하기. 용량이 아주 크고, 어차피 잠금 파일로 다시 만들어집니다.

체크리스트

• 프로젝트가 비공개 저장소에 연결되어 있습니다.
• .gitignore에 .env, node_modules, 빌드 결과물, 비밀 정보가 제외되어 있습니다.
• 작동하는 변경마다 커밋합니다.
• 커밋 메시지가 무엇이 바뀌었는지 한 줄로 설명합니다.
• 크거나 위험한 변경은 브랜치에서 하고 검토받습니다.
• 다른 사람이 코드를 편집할 때는 프롬프트 전에 pull 합니다.
• 체크포인트나 git revert로 되돌리고, 강제 push는 하지 않습니다.
• 한 번이라도 커밋된 키는 모두 재발급했습니다.

Mythex에서의 Git

Mythex는 AI 에이전트 턴이 성공할 때마다 Git 체크포인트를 저장하며, 이 시점으로 되돌리기를 누르면 프로젝트가 그 시점으로 롤백됩니다. 이것이 5단계에서 설명한 빌더 쪽 되돌리기입니다. 자세한 내용은 반복 작업을 재빌드 없이 하기를 참고하세요.

Pro 요금제에서는 프로젝트 설정의 GitHub 동기화로 저장소를 연결해 push와 pull을 할 수 있고, 내보내기로 비밀 정보와 node_modules를 제외한 프로젝트를 다운로드할 수 있습니다. 자세한 내용은 GitHub, 내보내기, 가져오기를 참고하세요. 프로젝트를 개발자에게 넘기기 전에 GitHub를 연결해 두면 인계가 훨씬 간단해집니다. AI로 만든 앱을 개발자와 함께 작업하는 법과 AI로 만든 앱을 내보내고 직접 호스팅하는 법도 함께 보세요.

자주 묻는 질문