AI로 만든 앱을 망가뜨리지 않고 개선하는 법

AI로 만든 앱을 망가뜨리지 않고 개선하려면, 프롬프트마다 한 가지만 바꾸고, 미리보기에서 확인하고, 다음으로 넘어가기 전에 체크포인트를 저장하세요. 코드가 무엇을 하는지 추측해서 설명하지 말고 여러분이 보는 것을 설명하고, 큰 변경은 만들기 전에 계획하고, 변경이 잘못되면 AI에게 자신의 수정을 고치게 하지 말고 마지막으로 잘 작동하던 버전으로 되돌리세요.

앱의 첫 버전은 몇 분 만에 완성되는 경우가 많습니다. 어려운 것은 쉰 번째 변경입니다. 새 프롬프트마다 이미 잘 작동하던 무언가를 깨뜨릴 위험이 있기 때문입니다. 이 가이드는 그런 일을 막는 루프를 설명합니다.

개선 루프

1. 변경 하나를 고르세요. 기능 하나, 버그 하나, 페이지 하나.
2. 사용자가 보고 하는 것의 관점에서 설명하세요.
3. 큰 변경은 먼저 계획하세요. 계획을 요청하고, 읽고, 그다음 만드세요.
4. 미리보기에서 결과를 확인하세요. 변경 사항과 그 주변 흐름을 함께 보세요.
5. 저장하세요. 체크포인트나 커밋을 남기세요.
6. 반복하세요.

각 단계는 변경을 작고 되돌릴 수 있게 유지하기 위해 존재합니다.

1단계: 짧은 목록을 유지하세요

프롬프트를 쓰기 전에, 바꾸고 싶은 것을 중요도 순으로 적으세요. 열 가지 바람을 한 메시지에 몰아 쓰는 것을 막아 주고, 작업 도중 떠오르는 아이디어에 “지금은 아니야”라고 말할 방법도 됩니다.

변경이 크다면 나누세요. “팀 계정 추가”는 이렇게 나뉩니다: 팀 만들기, 구성원 초대하기, 팀 전환하기, 데이터를 현재 팀으로 제한하기. 각각이 별도의 프롬프트입니다. 사용자 스토리 쓰는 법이 이렇게 나누는 데 좋은 방법입니다.

2단계: 보이는 것을 설명하세요

AI는 여러분이 말해 주지 않으면 화면을 볼 수 없습니다. 구체적인 것을 가리키고, 무엇이 일어나야 하는지 말하세요:

휴대폰에서 가격 페이지를 보면 Pro 카드의 버튼이 오른쪽 끝에서 잘립니다. 데스크톱 레이아웃은 그대로 두고, 640px보다 좁은 화면에서는 카드를 세로로 쌓고 버튼은 전체 너비로 만들어 주세요.

“가격 페이지가 모바일에서 보기 안 좋아요”라고 말하는 것과 비교해 보세요. 앞의 요청은 한 번에 만들고 확인할 수 있습니다. 뒤의 요청은 요청하지 않은 재디자인을 부릅니다.

스크린샷도 도움이 됩니다. 빌더가 이미지를 받는다면 하나를 첨부하고 문제 부분에 동그라미를 치세요.

3단계: 큰 변경은 계획부터 세우세요

앱의 여러 부분을 건드리는 작업(새 데이터 모델, 결제, 사용자 역할 등)이라면, 코드를 바꾸기 전에 계획을 요청하세요:

아직 코드는 바꾸지 마세요. 사용자가 팀에 속하고 자기 팀의 프로젝트만 보게 하려고 합니다. 계획을 세워 주세요. 어떤 테이블, 페이지, API 라우트가 바뀌는지, 기존 사용자의 데이터는 어떻게 되는지, 어떤 순서로 만들 것인지요.

계획을 읽으세요. 틀렸다면, 계획을 고치는 것이 빌드를 되돌리는 것보다 훨씬 저렴합니다.

4단계: 바뀌면 안 되는 것을 말하세요

AI 도구는 요청하지 않은 부분을 가끔 “정리”해 버립니다. 잘 작동하는 것은 보호하세요:

주문 테이블에 날짜 필터를 추가해 주세요. 테이블의 열, 스타일, 내보내기 버튼은 바꾸지 마세요.

모든 곳에 적용되는 규칙(브랜드 색상, 어조, “확인 없이 데이터를 절대 삭제하지 않기” 같은 것)은 반복해서 말하지 말고, AI가 매번 읽는 프로젝트 메모 파일이나 지식 설정에 넣으세요.

5단계: 변경한 것 이상을 확인하세요

프롬프트마다 다음을 테스트하세요:

• 변경 사항 자체. 요청한 대로 동작하나요? 데스크톱과 휴대폰 모두에서요?
• 주변 요소. 같은 페이지의 다른 것들, 그리고 같은 데이터를 쓰는 흐름.
• 핵심 경로. 가입, 로그인, 주요 행동, 결제. 큰 변경 후 30초 정도 훑어보면 대부분의 깨짐을 일찍 잡아낼 수 있습니다.

무언가 이상하다면 정확하게 보고하세요. 좋은 버그 리포트 작성법을 참고하세요.

6단계: 쌓지 말고 되돌리세요

변경이 무언가를 깨뜨렸고 첫 번째 수정이 통하지 않으면 멈추세요. 추가 “수정”마다 깨진 상태 위에 쌓이므로, 문제가 복리처럼 불어납니다.

대신:

1. 마지막으로 작동했던 버전으로 되돌리세요 (체크포인트나 Git 커밋).
2. 프롬프트의 무엇이 불명확했는지 생각해 보세요.
3. 더 작거나 더 명확한 요청으로 다시 시도하세요.

방금 변경으로 임시 저장이 깨졌어요. 되돌렸습니다. 이번에는 헤더에 텍스트로 된 자동 저장 표시만 추가해 주세요. 임시 저장 방식은 바꾸지 마세요.

7단계: 다시 만드는 것이 맞는 때를 아세요

처음부터 다시 만들면 작동하던 세부 사항을 많이 버리게 됩니다. 다음의 경우에만 가치가 있습니다:

• 제품 아이디어가 완전히 바뀌었을 때.
• 기반 구조가 지금 필요한 것을 감당할 수 없을 때. 예를 들어 정적 사이트로 만들어졌는데 이제 계정과 데이터베이스가 필요할 때.
• 프로젝트가 아직 거의 비어 있을 때.

다시 만들 때는 유지할 것을 적으세요. 이름, 색상, 문구, 사용자가 좋아했던 부분.

예시 프롬프트

계속하기 전에, 지금 앱이 어떻게 작동하는지 요약해 주세요. 페이지, 저장하는 데이터, 그리고 취약해 보이는 부분을 알려 주세요.

반복 예약을 추가하고 싶어요. 유용한 가장 작은 버전은 무엇인가요? 한 번에 하나씩 만들 수 있도록 세 가지 별도의 변경으로 제안해 주세요.

최근 변경 세 개를 검토해서 결제 흐름을 깨뜨렸을 만한 것이 있는지 확인해 주세요. 아직 수정하지는 마세요.

흔한 실수

• 한 프롬프트에 요청 열 개. 일부는 끝나고, 일부는 반쯤 끝나고, 어느 것이 어느 것인지 알 수 없습니다.
• 모호한 피드백. “고장 났어요”나 “더 좋게 해 주세요”는 추측을 낳습니다.
• 주변 확인을 하지 않기. 공유 컴포넌트 하나를 바꾸면 다른 페이지 세 개가 깨질 수 있습니다.
• 수정을 또 수정하기. 버그에서 프롬프트를 네 번 거쳤다면, 되돌리세요.
• 매번 같은 맥락을 반복하기. 상시 규칙은 프로젝트 메모에 두세요.
• 막히면 다시 만들기. “처음부터 다시”라는 순간의 대부분은 실제로는 “두 단계 되돌리기”입니다.

체크리스트

• 프롬프트마다 목표는 하나.
• 보이는 것과 일어나야 할 것을 설명함.
• 큰 변경은 코드 전에 계획을 받음.
• 바뀌면 안 되는 것을 말함.
• 변경 후에는 그 변경, 주변 요소, 핵심 경로를 테스트함.
• 잘 작동하는 변경마다 체크포인트나 커밋을 저장함.
• 수정이 실패하면 쌓지 않고 되돌림.
• 상시 규칙은 AI가 매번 읽는 프로젝트 메모에 있음.

Mythex에서 개선하기

Mythex는 이 루프를 중심으로 만들어졌습니다:

• 계획, 빌드, 질문 모드. 계획 모드는 편집 전에 접근 방식을 논의하고, 질문 모드는 코드를 바꾸지 않고 답하며, 빌드 모드는 변경을 만듭니다. 채팅을 참고하세요.
• 체크포인트. 각 성공한 차례 뒤에 Mythex가 git 체크포인트를 저장하고, 이 시점으로 되돌리기로 롤백할 수 있습니다. 이전 메시지를 편집한 뒤 폐기하고 다시 보내기를 눌러 그 지점부터 다른 프롬프트를 시도할 수도 있습니다. 다시 만들지 않고 개선하기를 참고하세요.
• 지식. 프로젝트 설정 → 지식에는 에이전트가 모든 메시지마다 따르는 상시 메모가 있습니다.
• **/test**는 큰 변경 후 에이전트가 사용자처럼 미리보기를 클릭해 보게 합니다.

요청이 작을수록 크레딧도 적게 듭니다. 프롬프트 자체를 쓰는 법은 AI 앱 빌더용 프롬프트 쓰는 법을, 무언가 깨졌을 때는 AI로 만든 앱 디버깅하는 법을 참고하세요.

자주 묻는 질문