AI로 만든 앱 디버깅하는 법: 실용적인 방법

AI로 만든 앱을 디버깅하려면, 먼저 버그를 일부러 다시 일으키고, 증거를 모으세요. 정확한 단계, 오류 메시지, 브라우저 콘솔과 네트워크 탭이 보여 주는 내용입니다. 그리고 그것을 "X를 했고, Y를 기대했지만, Z가 나왔다"의 형식으로 AI에게 전달하세요. 수정을 해서 상황이 더 나빠지면, 그 위에 수정을 더 쌓는 대신 마지막으로 잘 작동하던 버전으로 롤백하세요. 이 모든 것을 잘하려고 코드를 읽을 필요는 없습니다.

이 가이드는 전체 과정과, 비개발자를 위한 브라우저 개발자 도구의 간단한 둘러보기를 다룹니다.

디버깅 순환 과정

사람이 고치든 AI가 고치든 모든 버그 수정은 같은 순환 과정을 따릅니다.

1. 재현 — 버그를 안정적으로 일으킵니다.
2. 관찰 — 오류 메시지와 앱이 무엇을 하고 있었는지 모읍니다.
3. 설명 — AI에게 정확한 단계, 기대 결과, 실제 결과를 줍니다.
4. 수정 — AI가 한 가지만 바꾸게 합니다.
5. 검증 — 같은 단계를 정확히 반복해 고쳐졌는지, 주변이 깨지지 않았는지 확인합니다.
6. 필요하면 롤백 — 더 나빠졌다면 되돌리고, 더 나은 정보로 다시 시도합니다.

AI로 만든 앱에서 시간을 낭비하는 대부분은 1, 2, 5단계를 건너뛰기 때문입니다. "고장 났어요"라고만 말하거나, 테스트 없이 변경을 받아들이거나, 깨진 것 위에 또 다른 수정을 요청하는 것입니다.

1단계: 버그 재현하기

원할 때 일으킬 수 있는 버그는 이미 절반은 고친 것입니다. 버그를 일으키는 가장 짧은 단계들을 찾아보세요.

스스로 물어보세요.

• 항상 일어나나요? 가끔만 일어난다면, 일어날 때 무엇이 다른가요? 특정 레코드, 느린 연결, 로그아웃 상태인가요?
• 모든 사용자에게 일어나나요? 다른 계정으로 로그인해 보세요. 많은 버그는 데이터가 없는 새 사용자나 다른 역할의 사용자에게만 나타납니다.
• 모든 기기에서 일어나나요? 휴대폰 너비 화면과 다른 브라우저에서 해 보세요.
• 특정 변경 후에 시작되었나요? 어제는 잘 됐다면, 최근 몇 번의 변경이 가장 유력한 용의자입니다.

단계를 짧은 번호 목록으로 적어 두세요. 나중에 프롬프트에 붙여 넣을 것입니다.

2단계: 오류 메시지 읽기

오류 메시지는 겁나 보이지만, 그중 몇 부분만 알면 됩니다.

이해할 필요는 없고, 정확히 복사하면 됩니다. "Cannot read properties of undefined (reading 'name')"은 코드가 기대한 데이터(아마 예약이나 사용자)가 없었다는 것을 AI에게 알려 줍니다. "정의되지 않은 오류" 같은 의역은 그 정보를 잃습니다.

흔한 몇 가지를 대략 풀면 다음과 같습니다.

• undefined / null 오류 — 코드가 기대한 데이터가 도착하지 않았습니다. 로딩 상태나 코드가 처리하지 않은 빈 목록인 경우가 많습니다.
• 404 Not Found — 페이지나 API 주소가 없습니다. 경로의 오타, 또는 이름이 바뀐 페이지로의 링크인 경우가 많습니다.
• 401 Unauthorized / 403 Forbidden — 요청이 로그인되지 않았거나, 사용자가 그 동작을 할 권한이 없습니다.
• 500 Internal Server Error — 서버 쪽 코드가 충돌했습니다. 실제 이유는 브라우저가 아니라 서버 로그에 있습니다.
• CORS 오류 — 브라우저가 다른 도메인으로의 요청을 막았습니다. 보통 서버 쪽 설정 문제입니다.

3단계: 브라우저 개발자 도구 사용하기

모든 데스크톱 브라우저에는 기본 개발자 도구("devtools")가 있습니다. 페이지가 뒤에서 무엇을 하는지 보여 줍니다. Chrome, Edge, Firefox에서는 페이지 아무 곳이나 우클릭하고 검사를 고르거나 F12(Mac에서는 Cmd+Option+I)를 누르세요. Safari에서는 먼저 Safari 설정에서 개발자 메뉴를 켜야 합니다.

탭은 세 개만 알면 됩니다.

콘솔

Console 탭은 페이지 코드의 오류와 메시지를 나열합니다. 오류는 빨간색으로 표시됩니다. 버튼을 눌러도 아무 일도 일어나지 않는다면, 콘솔은 클릭하는 순간의 빨간 오류를 자주 보여 줍니다. 오류의 전체 텍스트를 복사하세요(대부분의 브라우저에서 우클릭하면 복사 옵션이 있습니다).

네트워크

Network 탭은 페이지가 보내는 모든 요청을 나열합니다. 데이터 불러오기, 폼 저장, 로그인 등입니다. 탭을 열고 버그를 일으키는 단계를 반복하세요.

• 빨간색이거나 상태가 400 이상인 행을 찾으세요.
• 실패한 행을 클릭해 Response를 보세요. 서버 오류에는 화면에 보이는 어떤 것보다 유용한 메시지가 들어 있는 경우가 많습니다.
• 요청의 URL과 상태 코드를 적어 두세요. "/api/bookings로 보낸 POST가 500을 반환했다"는 AI에게 매우 유용한 문장입니다.

버그가 페이지 새로고침이나 리디렉션과 관련되어 있다면 Preserve log를 켜서 요청이 사라지지 않게 하세요.

요소

Elements(또는 Inspector) 탭은 페이지의 구조와 스타일을 보여 줍니다. 레이아웃 버그에 가장 유용합니다. 요소 위에 마우스를 올리면 크기와 간격이 강조됩니다. 여기서 아무것도 고칠 필요는 없습니다. "푸터가 모바일에서 2,000픽셀 너비라서 페이지를 옆으로 밀어낸다"라고 말하는 것으로 충분합니다.

4단계: 서버 로그 확인하기

일부 버그는 브라우저가 볼 수 없는 서버에서 일어납니다. 네트워크 탭의 500 오류가 대표적인 신호입니다. 서버 로그, 즉 백엔드가 실행되는 동안 남기는 텍스트 출력에는 보통 스택 트레이스(실패할 때 실행 중이던 함수 목록)와 함께 실제 오류가 들어 있습니다.

위치는 도구에 따라 다릅니다. 대부분의 AI 앱 빌더에서는 프로젝트의 터미널이나 로그 화면을 열거나, AI에게 바로 요청하면 됩니다. "마지막 요청의 오류 서버 로그를 확인하고 무엇이 실패했는지 알려 줘."

5단계: AI에게 버그 설명하기

모은 정보를 다음 형태로 정리하세요.

예약 페이지에서, 회원으로 로그인한 상태로: 내일 9시 수업의 취소를 클릭했습니다. 기대: 예약이 사라지고 수업의 빈자리가 하나 늘어납니다. 실제: 화면에 아무 변화도 없습니다. 콘솔에는 BookingCard.tsx:31에서 TypeError: Cannot read properties of undefined (reading 'id')가 나오고, 네트워크 탭에는 DELETE /api/bookings/123이 500을 반환했습니다. 원인을 찾아 고치고, 예약이 한 개인 회원과 여러 개인 회원 모두에 대해 취소가 동작하는지 확인하세요.

각 부분이 중요한 이유:

• 어디에서, 누구로 로그인했는지는 화면과 역할을 하나로 좁혀 줍니다.
• 정확한 단계는 AI가 재현할 수 있게 합니다.
• 기대 대 실제는 '고쳐졌다'의 의미를 정의합니다.
• 오류 텍스트와 실패한 요청은 원인을 바로 가리킵니다.
• **"확인하세요"**는 AI에게 편집만 하지 말고 검증도 하라고 요청합니다.

AI가 두 번 수정을 시도했다가 실패했다면, 무엇이든 바꾸기 전에 설명하라고 요청하세요.

아직 코드를 바꾸지 마세요. 무엇이 이것을 일으킨다고 생각하나요? 그 근거는 무엇인가요?

잘못된 추측은 글로 적혀 있을 때 쉽게 알아챌 수 있고, 잘못된 수정을 고치는 것보다 훨씬 저렴합니다.

6단계: 검증하고 주변 확인하기

AI가 고쳤다고 말하면, 1단계의 정확한 단계를 반복하세요. 그다음 주변을 확인하세요.

• 다른 사용자 역할로 같은 동작
• 데이터가 없을 때와 많을 때 같은 동작
• 고친 것과 컴포넌트를 공유하는 페이지
• 레이아웃을 건드렸다면 휴대폰 너비 화면

AI의 변경은 때때로 한 경로를 고치면서 다른 경로를 조용히 깨뜨립니다. 지금 2분 확인하면 나중에 헷갈리는 한 시간을 아낄 수 있습니다.

7단계: 쌓지 말고 롤백하기

수정으로 상황이 더 나빠졌거나, 세 번 시도해도 진전이 없다면 되돌아가세요. 마지막으로 잘 작동하던 버전으로 롤백하고 더 나은 증거로 다시 요청하는 것이, 잘못된 수정 세 번 위에 네 번째 수정을 요청하는 것보다 거의 항상 낫습니다. 실패한 시도마다 코드가 남고, 그 코드가 다음 시도를 헷갈리게 합니다.

롤백을 쉽게 만드는 좋은 습관:

• 변경할 때마다 테스트하세요. 어떤 변경이 깨뜨렸는지 알 수 있습니다.
• 변경은 작게 유지하세요. 메시지 하나에 기능 하나 또는 수정 하나.
• 위험한 작업 전에 마지막 정상 버전을 기록해 두세요.
• 코드가 Git에 있다면, 정상 작동하는 버전을 커밋해서 돌아갈 수 있게 하세요.

AI로 만든 앱의 흔한 버그 패턴

버그가 아닌 경우

일부 "버그"는 AI가 지시받은 그대로 만든 것이고, 설명이 모호했던 경우입니다. 요청하는 수정이 사실상 동작의 변경이라면 분명히 말하세요. "이렇게 바뀌게 해 줘…"라고요. 올바른 동작이 무엇인지 확신이 없다면, 먼저 그것을 결정하세요. 규칙을 명확하게 지정하는 방법은 AI 앱 빌더용 프롬프트 작성법에서 다룹니다. 그리고 실사용자를 위해 앱을 준비하고 있다면, 출시 전에 할 점검은 AI 프로토타입을 실서비스로 옮기는 법에 있습니다.

Mythex에서 디버깅하기

Mythex에는 순환 과정의 각 단계를 위한 도구가 있습니다.

• 미리보기로 버그를 재현합니다. 휴대폰 크기 프레임도 포함됩니다.
• **/test**는 에이전트가 라이브 미리보기에서 사용자처럼 클릭하며 깨진 흐름을 보고하게 합니다.
• **/fix**는 에이전트가 깨진 부분에 집중하게 합니다.
• 계획(Plan) 모드는 에이전트가 무엇이든 편집하기 전에 조사하고 설명하게 합니다.
• 코드 → 터미널에서 앱의 서버 로그를 볼 수 있습니다.
• 이 시점으로 되돌리기는 어떤 응답에서든 프로젝트를 그 체크포인트로 롤백합니다.

게시가 실패하면 게시 대화상자에 보통 AI로 수정이 나타나며, 이는 빌드 출력이나 앱의 로그를 읽습니다. 문서의 앱 디버깅과 게시 문제 해결을 참고하세요.

자주 묻는 질문