AI로 코드를 짜다 보면 막힙니다. 에러가 나거나, 코드가 뭘 하는지 모르거나, 결과가 미덥지 않습니다. 이때 필요한 건 새 질문이 아니라 탈출구 프롬프트입니다. 핵심은 에러와 코드를 숨기지 말고 그대로 주되, 개인정보만 빼는 것입니다.
- 막힘을 에러·이해·수정·검산·방향 문제로 구분할 수 있습니다.
- 개인정보를 제거하면서 재현에 필요한 단서를 보존할 수 있습니다.
- 증상에 맞는 구원 프롬프트를 선택해 질문할 수 있습니다.
- AI 답이 원인을 좁히고 검산 방법을 제시하는지 판단할 수 있습니다.
배경지식
문제가 생겼을 때 보이는 현상을 증상, 그 현상을 만든 이유를 원인이라고 합니다. "파일이 안 열립니다"는 증상이고, 문자 인코딩이나 경로가 맞지 않는 것은 가능한 원인입니다. 증상만 말하면 AI는 여러 원인 가운데 하나를 추측하므로, 실제로 본 메시지와 실행 환경을 함께 줘야 합니다.
같은 문제를 다른 사람이 다시 일으켜 볼 수 있게 만든 작은 입력을 재현 예시라고 합니다. 큰 업무 파일 전체가 아니라 오류가 나는 열 몇 개와 합성값만 남겨도 구조 문제가 재현될 수 있습니다. 자동차 정비사가 같은 소리를 다시 들어 보는 것처럼, 재현돼야 제안한 수정이 원인을 고쳤는지 확인할 수 있습니다.
좋은 도움 요청은 하려던 일, 실행 환경, 실제 증상, 이미 확인한 것, 바꾸면 안 되는 제약을 분리합니다. AI의 답을 받은 뒤에는 한 번에 하나만 바꾸고 같은 재현 예시로 다시 확인합니다. 여러 곳을 동시에 바꾸면 무엇이 효과가 있었는지 알 수 없습니다.
왜 에러를 숨기면 안 되는가
막힌 코드를 들고 AI에게 가는 것은 고장 난 차를 정비소에 맡기는 것과 같습니다. "차가 좀 이상해요"라고만 하면 정비공은 처음부터 다 뜯어봐야 합니다. 하지만 "시동 걸 때 딸깍 소리가 세 번 나고 계기판에 빨간 등이 뜬다"고 하면 원인이 단번에 좁혀집니다. 에러 메시지가 바로 그 "딸깍 소리와 빨간 등"입니다.
기술적으로도 그렇습니다. 빨간 에러 메시지에는 대개 어느 파일, 몇 번째 줄, 무슨 종류의 문제인지가 담겨 있습니다. 이 정보를 지우고 "코드가 안 돼요"라고만 하면, AI는 있지도 않은 원인을 추측하며 멀쩡한 코드까지 새로 씁니다. 반대로 에러 전문을 그대로 주면 AI는 추측 대신 그 단서에서 출발합니다.
그래서 이 안내서의 프롬프트는 모두 같은 원칙 위에 서 있습니다. 숨기지 말고 그대로 주되, 개인정보만 뺀다. 막히는 상황은 생각보다 종류가 적어서, 아래 다섯 가지 틀로 대부분 빠져나올 수 있습니다.
붙여넣기 전, 개인정보만 바꾸기
외부 챗봇에 넣기 전 다음을 대체값으로 바꿉니다.
- 이름 →
홍길동또는<이름 삭제> - 전화·주소·상세위치 →
<연락처 삭제>·<주소 삭제> - 실제 사건·출동번호 →
SYN-2026-001같은 합성 번호 - 내부 서버 경로·업무망 URL →
<내부 경로 삭제> - API 키·토큰 →
<API 키 삭제>
왜 이 단계가 맨 앞에 오는지 짚고 갑니다. 외부 AI에 한번 붙여넣은 글은 내 손을 떠납니다. 신고자·환자 정보가 섞인 채 나가면 되돌릴 수 없습니다. 그래서 "고치는 것"보다 "빼는 것"이 먼저입니다.
한 줄로 보면 이렇게 바뀝니다(값은 모두 합성 예시입니다).
(원본 예시) 홍길동(010-0000-0000)님 신고, ○○구 ○○아파트 3동 화재 (대체 후) <이름 삭제>(<연락처 삭제>) 신고, <주소 삭제> 화재
에러를 재현하는 데 꼭 필요한 것은 코드의 구조와 에러 메시지이지 실제 사람 정보가 아닙니다. 값은 가려도 문제는 그대로 재현됩니다. 개인정보를 내보내기 전 로컬에서 먼저 걸러 내는 방법은 개인정보, AI에 넣기 전에 점검하기에 자세히 있습니다.
가상 상황: 밤 10시, 합쳐지지 않는 CSV
가상의 상황을 하나 들어 보겠습니다. 야간 근무 중인 대원이 합성 출동 CSV 세 개를 합쳐 유형별 통계를 만들려 합니다. AI가 준 코드를 실행하자 빨간 글자가 쏟아지고, UnicodeDecodeError라는 낯선 말만 눈에 들어옵니다. 시간은 늦었고 막막합니다.
여기서 "코드를 처음부터 다시 짜 줘"라고 하면 같은 문제가 반복되기 쉽습니다. 대신 아래 디버그 프롬프트(①)에 상황을 그대로 채워 넣습니다.
아래 코드를 실행했는데 실패했습니다. 실제 사건 정보와 개인정보는 제거했습니다.
바로 전체 코드를 다시 쓰지 말고, 원인을 단계별로 설명하고 수정 전에 확인할 명령부터 제안해 주세요.
[하려던 일] 합성 출동 CSV 3개를 합쳐 유형별 통계를 만들려고 했습니다.
[실행 환경] Windows, 로컬 파이썬 (Colab 아님)
[실행한 코드] pd.read_csv("dispatch_2026_01.csv")
[입력 파일 구조] 파일 3개, 컬럼: 접수시각, 유형, 행정동 (실제 값은 넣지 않음)
[오류 전문] UnicodeDecodeError: 'utf-8' codec can't decode byte ...
이렇게 물으면 AI는 대개 "파일 인코딩이 UTF-8이 아닐 수 있다"는 방향을 짚고, 코드를 갈아엎기 전에 인코딩을 확인하는 한 줄부터 제안합니다. 원인을 좁힌 뒤 고치는 편이, 새 코드를 통째로 받아 또 실패하는 것보다 빠릅니다.
가상 사례: 교육 안내가 너무 어렵게 나온 경우
다음은 실제 교육 과정과 무관한 가상 사례입니다. 교육 담당자는 합성 준비 메모를 초심자용 안내문으로 바꿔 달라고 했지만, AI 답은 낯선 전문용어와 긴 문단으로 가득합니다. 사실 오류 메시지는 없지만 출력 형식과 독자 수준이 맞지 않는 막힘입니다.
담당자는 처음부터 새 안내문을 요구하지 않고 ③ 수정 프롬프트를 고릅니다. 현재 답, 대상 독자, 유지할 사실, 바꿀 형식을 분리해 주고 "원문에 없는 준비물·일정은 추가하지 말라"고 적습니다. 결과는 짧은 문단과 확인 목록으로만 바꾸게 합니다.
표현을 고치는 과정에서 준비물이나 일정까지 달라지면 실패입니다. 담당자는 수정 전후를 나란히 놓고 합성 원문의 사실이 유지됐는지 확인하며, 실제 배포 여부는 교육 운영 기록과 승인 절차를 확인한 사람이 결정합니다.
다섯 가지 구원 프롬프트
막히는 상황은 크게 다섯 가지입니다. 증상에 맞는 프롬프트를 고르세요.
| 증상 | 쓸 프롬프트 |
|---|---|
| 빨간 에러가 났다 | ① 디버그 |
| 코드가 뭘 하는지 모르겠다 | ② 설명 |
| 동작은 하는데 조금 바꾸고 싶다 | ③ 수정 |
| 결과가 맞는지 의심스럽다 | ④ 검산 |
| 무엇부터 손대야 할지 모르겠다 | ⑤ 방향 |
각 프롬프트는 < > 안을 자기 상황으로 채워 씁니다.
① 디버그 — 에러가 났을 때
아래 명령 또는 코드를 실행했는데 실패했습니다. 실제 사건 정보와 개인정보는 제거했습니다. 바로 전체 코드를 다시 쓰기보다, 원인을 단계별로 설명하고 수정 전에 확인할 명령부터 제안해 달라고 요청합니다. [하려던 일] <예: 합성 출동 CSV 3개를 합쳐 유형별 통계를 만들려고 했습니다> [현재 폴더 또는 실행 환경] <예: D:\작업폴더 또는 Google Colab> [실행한 명령 또는 코드] <명령/코드 붙여넣기> [입력 파일 구조] <파일명, 컬럼명. 실제 데이터값은 넣지 않습니다> [오류 전문] <빨간 에러 메시지 전체>
② 설명 — 코드가 무슨 일을 하는지 모를 때
아래 코드를 코딩을 모르는 소방 업무자에게 설명하듯 한 줄씩 설명해 달라고 요청합니다. 전문용어는 풀어서 설명하고, 입력 파일·출력 파일·개인정보 관련 부분을 따로 표시해 달라고 요청합니다. 마지막에는 "업무 적용 전 사람이 확인할 것"을 체크리스트로 정리해 달라고 요청합니다. <코드 붙여넣기>
③ 수정 — 동작은 하지만 바꾸고 싶을 때
아래 코드에서 <바꾸고 싶은 것>만 바꿔 달라고 요청합니다. 나머지 구조는 유지하고, 바뀐 부분에는 짧은 주석을 달아 달라고 요청합니다. 새 패키지는 설치하지 않도록 요청합니다. 수정 뒤에는 기존 결과와 비교할 검산 방법을 함께 제안해 달라고 요청합니다. [바꾸고 싶은 것] <예: 월별 집계에 행정동별 표를 하나 더 추가합니다> [코드] <코드 붙여넣기>
④ 검산 — 결과가 의심될 때
이 결과가 맞는지 검증하는 코드를 작성해 달라고 요청합니다. 원본 데이터의 행 수, 합계, 빈값, 중복값과 대조하는 방식으로 확인해 달라고 요청합니다. 검산에 실패하면 결과를 저장하지 않고 이유를 출력하도록 해 달라고 요청합니다. [원본 데이터 구조] <파일명과 컬럼명> [현재 코드] <코드 붙여넣기> [현재 결과] <집계 결과 또는 의심되는 출력>
채워 넣은 예시를 하나 보겠습니다(모두 가상). 합성 출동 데이터를 월별로 집계했는데 합계가 어쩐지 커 보입니다.
이 결과가 맞는지 검증하는 코드를 작성해 주세요. 원본의 행 수, 유형별 합계, 빈값, 중복 행과 대조해 확인해 주세요. 검산에 실패하면 결과를 저장하지 말고 이유를 출력해 주세요. [원본 데이터 구조] 파일명 dispatch_syn.csv, 컬럼: 접수시각, 유형, 행정동 [현재 코드] (집계 코드 붙여넣기) [현재 결과] 1월 합계가 원본 행 수보다 큼 (원본 900행 남짓인데 합계는 그보다 많음)
행 수보다 합계가 크다면 같은 사건이 중복 집계됐을 수 있습니다. 검산 코드는 이런 어긋남을 숫자로 드러내 줍니다 — "맞아 보인다"가 아니라 "원본 900행, 집계 대상 900건 일치"처럼 대조 결과로 확인하는 것이 핵심입니다.
⑤ 방향 — 무엇부터 해야 할지 모를 때
내가 하려는 일은 아래와 같습니다. 아직 코드는 쓰지 말고, 업무를 3~5단계로 쪼개고 각 단계에서 필요한 입력 자료, 출력물, 검산 기준, 안전 주의사항을 먼저 정리해 달라고 요청합니다. [업무 설명] <예: 매월 예방 점검 결과 엑셀을 취합해 미점검 대상을 찾고 싶습니다> [사용 가능한 자료] <예: 합성 엑셀 예시, 공개 통계, 내부 기준은 넣지 않습니다> [제약] <예: 개인정보는 외부 AI에 넣지 않습니다. 결과는 사람이 확인한 뒤 공유합니다>
좋은 답변인지 보는 법
받은 답변이 쓸 만한지는 다섯 가지로 봅니다.
- 원인 설명 — 오류를 파일·경로·인코딩·컬럼 등으로 분해했는가
- 확인 순서 — 수정 전에 확인할 명령부터 제안했는가
- 검산 — 행 수·합계·중복·원문 대조가 들어 있는가
- 안전 — 개인정보·실제 사건 정보 제거를 안내했는가
- 변경 범위 — 요청한 부분만 바꿨는가(전체 구조·패키지를 크게 건드리지 않음)
같은 질문에 대한 두 답을 나란히 두면 차이가 뚜렷합니다(가상의 대비 예시).
| 보는 점 | 미덥지 않은 답 | 쓸 만한 답 |
|---|---|---|
| 원인 | "코드에 문제가 있네요" (뭉뚱그림) | "파일 인코딩이 CP949로 보입니다" (지목) |
| 순서 | 곧바로 전체 코드 재작성 | "먼저 인코딩을 확인해 보세요"부터 |
| 검산 | 없음 | "합친 뒤 행 수가 세 파일 합과 같은지 확인" |
| 변경 범위 | 새 라이브러리 설치 요구 | 기존 코드에서 한 줄만 수정 |
한마디로, 좁게 짚고 확인부터 권하는 답이 좋은 답입니다. 반대로 매번 전체를 새로 쓰거나 새 패키지를 자꾸 깔라는 답은 한 번 더 의심하세요.
이 프롬프트가 안 통할 때
구원 프롬프트는 탈출구이지 만능이 아닙니다. 다음 신호가 보이면 프롬프트를 더 다듬기보다 방식을 바꿔야 합니다.
- 같은 에러가 세 번 반복된다 — AI가 대화 맥락을 놓쳤을 수 있습니다. 지금까지 정리된 내용만 복사해 새 대화에서 다시 시작하세요.
- 고칠수록 더 꼬인다 — 방향 자체가 틀렸을 수 있습니다. ⑤ 방향 프롬프트로 돌아가 단계를 다시 쪼개세요.
- 코드가 아니라 데이터가 문제다 — 원본 파일이 깨졌거나 비어 있을 수 있습니다. 데이터를 먼저 손보는 지저분한 출동 데이터 정제하기가 필요합니다.
그리고 어떤 경우에도 마지막 관문은 사람입니다. AI가 준 수정 코드는 사람이 직접 실행하고, 결과는 AI 결과, 제출 전 1분 점검으로 검증한 뒤 업무에 씁니다. 출동 통계처럼 숫자가 중요한 작업이라면 출동 통계, CSV 한 장으로 월간 집계의 자동 검산 방식과 함께 보세요.
용어 한 줄 사전
| 용어 | 한 줄 설명 |
|---|---|
| 증상 | 화면이나 결과에서 직접 관찰한 문제의 모습입니다. |
| 원인 | 증상을 일으켰다고 확인하거나 검토 중인 이유입니다. |
| 실행 환경 | 운영체제·도구·파일 위치처럼 재현에 영향을 주는 조건입니다. |
| 오류 전문 | 생략하지 않은 전체 에러 메시지와 호출 위치입니다. |
| 재현 예시 | 개인정보 없이도 같은 문제를 다시 확인할 수 있는 작은 합성 입력입니다. |
| 검산 | 수정 뒤 결과가 기대값과 맞는지 별도 기준으로 확인하는 절차입니다. |
자주 묻는 질문
Q. 에러 메시지가 길어도 전부 줘야 하나요?
개인정보·내부 경로·비밀값을 대체한 뒤에는 처음부터 끝까지 주는 편이 원인을 찾기 쉽습니다. 마지막 한 줄만 주면 앞선 호출 위치가 사라질 수 있습니다.
Q. AI가 전체 코드를 새로 써 주면 더 빠르지 않나요?
바뀐 범위가 커지면 새 오류가 생기고 원인을 확인하기 어려워집니다. 먼저 확인 방법을 받고, 원인과 관련된 최소 부분만 바꾼 뒤 같은 입력으로 검산합니다.
Q. 답을 적용했는데 같은 문제가 반복되면 어떻게 하나요?
현재 코드·증상·이미 해 본 확인을 짧게 정리해 새 대화에서 다시 시작합니다. 같은 추측을 반복하지 않도록 "확인된 것"과 "아직 모르는 것"을 나눠 줍니다.
Q. 에러가 없는데 결과가 이상할 때는 무엇을 쓰나요?
④ 검산 프롬프트로 기대 관계와 대조 기준을 요청합니다. 실행 성공은 결과가 맞다는 뜻이 아니므로 행 수·합계·원문 같은 독립 기준이 필요합니다.
핵심 정리
- 보이는 증상과 가능한 원인을 나누고 실제 단서를 숨기지 않습니다.
- 개인정보·비밀값만 제거한 작은 재현 예시를 만듭니다.
- 막힘의 종류에 맞는 프롬프트를 고르고 한 번에 한 부분만 바꿉니다.
- 수정 결과는 사람이 직접 실행하거나 원문과 대조해 검산합니다.
다음 단계
- 지저분한 출동 데이터 정제하기 — 코드가 아니라 입력 데이터가 문제일 때 상태를 먼저 살핍니다.
- 출동 통계, CSV 한 장으로 월간 집계 — 합계와 전체 행 수를 대조하는 구체적 검산 흐름을 익힙니다.
- AI 결과, 제출 전 1분 점검 — 수정된 코드·문안을 실제 업무에 쓰기 전 마지막 판정을 수행합니다.