먼저 설명하고 나중에 수정하기: AI 코딩 도구가 버그 루프에 빠지는 것을 멈추는 방법

제가 겪었던 최악의 코딩 날들은 비슷했습니다. 오류가 발생합니다. "고쳐줘." 새로운 오류가 생깁니다. "고쳐줘." 원래 오류가 다시 나타납니다. 크레딧은 사라지고, 아무것도 작동하지 않으며, 저는 앱이 애초에 무엇을 하려고 했는지 잊어버린 채팅창만 바라보게 됩니다.

저에게 변화를 준 것은 지루한 습관 하나였습니다. 버그의 이해와 수정하는 것을 분리해서 생각하는 것입니다. AI에게 "그냥 고쳐줘"라고 요청하기 전에, AI가 무슨 일이 일어나고 있는지 설명하도록 만듭니다. 이 작은 변화만으로도 제가 겪던 루프의 대부분을 끊어낼 수 있었습니다.

'그냥 고치기'가 실패하는 이유

Cursor, Lovable, Bolt, Replit과 같은 AI 빌더들은 변경 사항을 만드는 데는 능숙합니다. 하지만 자신이 추측하고 있다는 것을 아는 능력은 떨어집니다. 동일한 채팅에서 계속 "여전히 작동하지 않아, 다시 시도해 봐"라고 말하면, 그들은 종종 수정을 반복하거나, 문제가 없었던 파일을 수정하거나, 아무것도 변하지 않았는데 자신감 있는 태도를 보입니다.

채팅창이 혼란스러워지고, 그런 혼란 속에서 네 번째 시도는 저에게 거의 작동하지 않습니다. 그래서 저는 진단(diagnosis)을 편집(editing)과는 별개의 작업으로 취급합니다.

제가 항상 사용하는 세 가지 프롬프트

저는 이 내용을 거의 그대로 붙여넣습니다. 여기에 발생한 오류, 정상적으로 작동하는 부분, 그리고 관심 있는 버그 부분을 바꿔 넣기만 하면 됩니다.

1. 먼저 설명하기 (Explain first)

Here's the exact error: [error]. Before you change anything, explain what it means, which file, most likely cause. Don't edit till I say go.

실제 오류를 붙여넣으세요: 브라우저 콘솔(F12), 터미널 출력 또는 빌드 로그입니다. "로그인이 깨졌어"와 같은 모호한 문구는 앱 전체에 대한 탐방을 유도합니다. 만약 사용 중인 도구가 편집할 수 없는 질문/계획 모드를 가지고 있다면, 이 단계에서 그것을 사용하세요.

2. 작동하는 부분을 격리하기 (Fence off what works)

These parts work and must not change: [list]. Only edit files related to [the bug]. List the files you plan to change and wait.

이것은 전형적인 "폼(form)을 고치다가 내비게이션(nav)을 망가뜨리는" 순환을 막아줍니다. 문제가 없는 부분을 명시하고, 수정하기 전에 계획된 편집 목록을 만들도록 요청하세요. 만약 그 목록에 요청하지 않은 것이 포함되어 있다면, 거절한다고 말하세요.

3. 증명 요구하기 (Prove it)

You said this was fixed, but it isn't. Stop editing. What's the cause, what's your evidence, what have you already tried? Then suggest something different.

승리했다고 주장하지만 아무것도 변하지 않았다면 다시 시도(try again)를 누르지 마세요. 강제로 멈춤(pause)을 주세요. 만약 '이미 시도됨' 목록에 반복되는 항목이 있다면, 그것은 막힌 것입니다. 이것이 루프를 중단할 신호이며, 크레딧을 또 소모하며 태울 필요는 없습니다.

3스트라이크 규칙 (The 3-strikes rule)

같은 채팅에서 같은 버그에 대해 세 번 실패한 수정 작업을 거치면, 저는 멈춥니다. 네 번째 시도는 하지 않습니다.

대신 저는 다음을 합니다:

간단한 인계 메모(handover note)를 요청합니다: 문제점, 정확한 오류 내용, 시도했던 것들, 중요한 파일 목록. 200단어 미만이며, 키나 비밀 정보는 포함하지 않습니다.
작동했던 마지막 버전으로 되돌아갑니다 (Roll back).
새로운 채팅을 시작합니다 (또는 도구가 허용하는 경우 컨텍스트를 지웁니다).
메모를 붙여넣고 다음과 같이 말합니다: 이미 시도한 것은 반복하지 마세요. 무언가를 변경하기 전에 원인을 설명하세요.

정리되지 않은 채팅은 추측에 보상하지만, 명확한 개요가 있는 깔끔한 채팅은 계획에 보상합니다.

각 도구에서 되돌리는 방법 (How I roll back in each tool)

위험한 시도를 하기 전에 작동하는 체크포인트(checkpoint)를 저장하세요. 세 번의 실패를 경험했다면, 고장 난 변경 사항들을 파헤치기보다는 그 체크포인트로 돌아가세요.

Cursor. 이전 메시지에 마우스를 올리고 '체크포인트 복원(Restore Checkpoint)'을 사용합니다. 이는 파일만 복원하며 채팅 내용은 유지됩니다. 체크포인트는 로컬이며 Git과 분리되어 있으므로, 위험한 작업을 하기 전에 커밋하세요. 진단에는 질문 모드(Ask mode)가 도움이 됩니다. 왜냐하면 설명하는 동안 편집할 수 없기 때문입니다. 인계 메모를 작성한 후 새로운 채팅을 시작하세요.

Lovable. '히스토리(History)'를 열고 작동했던 마지막 버전으로 되돌아가세요 (Revert). 신뢰하는 버전을 북마크하세요. 리버트(Revert)는 코드만 복원합니다. 데이터베이스 변경 사항은 취소되지 않으며, 크레딧도 돌려받을 수 없으므로, 세 번에서 멈추는 것이 시간뿐 아니라 비용 절감에도 도움이 됩니다.

Bolt. 만약 변화 직후에 문제가 발생했다면, '버전 기록(Version history)' (시계 아이콘)을 열고 마지막으로 작동했던 버전을 미리 보고 이 버전을 복원하세요. 이것은 Bolt나 Supabase 데이터베이스를 변경하지 않습니다. 먼저 인계 메모를 받고, 그 다음 /clear를 입력하고 '컨텍스트 지우기(Clear context)'를 선택하세요. 코드는 유지되고, 혼란스러운 채팅 내용은 사라집니다. 영구적인 규칙들은 프로젝트 지식(project knowledge)에 넣어 /clear 후에도 살아남게 하세요.

Replit. 에이전트(Agent) 채팅에서 히스토리 아이콘을 열고, 체크포인트(checkpoint)를 찾아 'Rollback to here'를 선택하세요. 기본적으로 이것은 데이터베이스를 변경하지 않습니다. 개발용 데이터베이스의 경우 추가 옵션에서 'Database'에 체크할 수 있습니다. 프로덕션(Production) 데이터는 별개입니다. 롤백은 또한 에이전트의 대화 컨텍스트(conversation context)도 되돌리므로, 루프가 발생한 후에는 보통 원하는 동작입니다.

모든 도구에서 공통적인 규칙이 하나 있습니다: 대부분의 롤백은 라이브 데이터가 아니라 코드를 복원합니다. 만약 AI가 루프 동안 데이터베이스를 건드렸다면, 그것을 별도로 확인하세요.

수정하기 전 매번 해야 할 일

패러프레이즈(paraphrase)가 아닌 정확한 오류 메시지를 복사하세요
어떤 편집을 하기 전에 먼저 'Explain'을 실행하세요
절대 변경되어서는 안 되는 부분을 구분하여 표시하세요 (Fence off)
작동하는 버전을 저장하거나 북마크(bookmark)하세요
시도할 때마다 재테스트(re-test)하세요
세 번 실패하면 중단하세요 (Stop at three strikes)

이 모든 것이 영리한 방법은 아닙니다. 단지 도구가 긴 채팅에서 제멋대로 날뛰는 것을 거부하는 것일 뿐입니다. 편집하기 전에 설명하게 하고, 세 번 실패하면 롤백하여 처음부터 다시 시작하도록 만드세요.

저는 Debuff Labs를 운영합니다. 여기 무료 한 페이지 플로우차트가 있습니다: https://payhip.com/b/QaRgh, 그리고 전체 25가지 구조 요청 프롬프트(rescue prompts) 키트는 여기에 있습니다: https://payhip.com/b/qRu0s.