결론부터 말씀드리면, AI 코딩에서 에러는 실패가 아니라 정보입니다. 코딩을 모르는 사람의 유일한 무기는, 에러 메시지 전체를 그대로 AI에게 붙여넣는 것입니다. 이해하지 못해도 정확히 나르기만 하면 대개 풀립니다.
봇을 만든 반년간 마주친 에러들을 사전처럼 정리했습니다. 이름은 낯설어도 대응 방식은 단순합니다.
실제로 겪은 에러 사전
| 에러 | 증상 | 해결 |
|---|---|---|
| 로그인 실패(EXIT CODE 3) | 아침에 로그인이 무응답으로 종료 | 남은 프로세스 강제 종료 → 관리자 권한 실행 → 모듈 재등록 |
| NameError | 없는 이름 참조로 중단 | import 누락·오타. 에러 전체를 AI에 붙여넣어 수정 |
| 호출 한도(429) | 조회를 자주 하다 봇 정지 | 데이터 캐싱, 이벤트 기반 전환, 조회 속도 조절 |
| 연결 끊김(10053) | 소켓 끊김으로 수신 지연 | 전송 타임아웃 확대, 예외 처리로 감싸기 |
| 배치파일 한글 깨짐 | 한글 주석이 실행을 막음 | ANSI 인코딩으로 저장, 주석 최소화 |
| 매수 수량 0 | 리스크 한도에 걸려 매매 누락 | 종목당 리스크 비중 상향 또는 최소 수량 하한 |
에러를 AI에게 넘기는 요령
가장 흔한 실수는 에러를 요약해서 전하는 것입니다. “에러 났어”가 아니라, 화면에 뜬 메시지를 처음부터 끝까지 그대로 복사해 붙여넣어야 원인을 정확히 짚습니다. 봇 코드에도 “오류가 나면 멈추지 말고 전체 오류 메시지를 캡처해서 알려줘”라고 지시해 두면 진단이 빨라집니다.
반복되는 에러엔 구조로 대응한다
한 번씩 나는 에러는 그때그때 고치면 되지만, 계속 나는 에러는 근본을 봐야 합니다. 저는 호출 한도(429)를 도구를 바꾸면 사라질 줄 알았지만, 옮긴 뒤에도 따라왔습니다. 결국 호출 설계 자체(캐싱·조회 속도)를 바꿔야 잡혔습니다.
왜 도구를 바꿔도 429는 따라오나
제가 가장 오래 씨름한 에러는 호출 한도 초과(429)였습니다. 처음엔 사용하는 방식이 낡아서 그런 줄 알고 도구를 바꿨는데, 옮긴 뒤에도 같은 빨간 불이 떴습니다. 원인은 도구가 아니라 제 습관이었습니다. 필요하지도 않은 조회를 너무 자주, 너무 많이 던지고 있었던 것입니다.
해결의 방향은 세 가지였습니다. 첫째, 같은 데이터를 반복해서 불러오지 않도록 일정 시간 캐싱합니다. 둘째, 매 순간 확인하는 방식 대신 필요한 순간에만 반응하는 이벤트 기반으로 바꿉니다. 셋째, 조회와 조회 사이에 간격을 둬 한도를 넘기지 않게 합니다. 도구가 아니라 호출 설계를 바꾼 뒤에야 이 에러가 잦아들었습니다.
에러를 자산으로 바꾸는 기록법
에러는 한 번 겪고 흘려보내면 다음에 또 같은 자리에서 넘어집니다. 저는 마주친 에러와 그때의 해결책을 사전처럼 적어 두기 시작했습니다. 위의 표가 바로 그 사전입니다. 봇에도 “오류가 나면 멈추지 말고 전체 메시지를 캡처해 알려줘”라고 지시해, 사람이 자리를 비운 사이 난 에러도 기록에 남게 했습니다.
이렇게 쌓인 에러 기록은 초보에게 가장 실용적인 교재가 됩니다. 남의 정답이 아니라 내 봇이 실제로 넘어진 자리의 지도이기 때문입니다.
초보가 기억할 한 가지
에러 메시지가 무섭게 보이는 이유는 대개 영어와 낯선 용어 때문입니다. 하지만 그 내용을 이해하는 건 AI의 몫이고, 사람의 몫은 그걸 빠짐없이 나르는 것입니다. 당황해서 요약하거나 일부만 전하면 진단이 어긋납니다. 통째로 나르는 습관, 그 하나가 코딩 지식의 상당 부분을 대신합니다.
한글 인코딩 지옥, 그리고 진짜 해법
에러 중에서도 유독 오래 저를 괴롭힌 것은 배치파일의 한글 깨짐이었습니다. AI가 친절하게 한글 주석을 달아주면, 그 주석 때문에 파일이 인코딩 충돌로 실행되지 않았습니다. “한글 주석 달지 마”라고 몇 번을 말해도 또 달았습니다. 한참 뒤에야 진짜 해법을 찾았는데, 주석을 빼는 게 아니라 파일을 ANSI 인코딩으로 저장하거나 코드페이지를 전환하는 것이었습니다. 초보가 원인을 정확히 짚기까지의 거리가 그만큼 멀었습니다.
이 경험은 에러 대응의 핵심을 알려줍니다. 증상을 없애는 임시방편과, 원인을 제거하는 진짜 해법은 다르다는 것입니다. AI에게 물을 때도 “이 증상을 없애줘”보다 “이 에러의 원인이 뭐고 근본 해결책이 뭐야”라고 물어야 같은 에러를 반복하지 않습니다.
백업을 안 해서 당한 날
또 하나 뼈아팠던 것은 백업 사고였습니다. 설정을 바꾸다 도구 업데이트가 겹치면서 백업할 여유도 없이 설정이 날아간 적이 있습니다. 그 뒤로 저는 어떤 수정이든 “먼저 원본을 backup 파일로 복사하고 시작해”를 첫 지시로 붙입니다. 에러 사전만큼이나 중요한 것이, 에러가 나도 되돌아갈 수 있는 안전망입니다.
에러는 결국 두 종류입니다. 되돌릴 수 있는 에러와, 되돌릴 수 없는 에러. 백업 하나가 대부분의 에러를 앞의 종류로 바꿔줍니다.
에러는 겁낼 대상이 아니라 읽을 대상입니다. 정확히 읽고 정확히 나르는 습관 하나가, 없는 코딩 지식을 상당 부분 대신합니다.
마지막으로 한 가지. 에러가 무서운 진짜 이유는 그 내용이 아니라 혼자라는 느낌 때문입니다. 하지만 대부분의 에러는 이미 누군가 겪었고, AI는 그 해법을 알고 있는 경우가 많습니다. 에러 앞에서 멈추지 말고 통째로 복사해 물어보십시오. 그 한 번의 습관이 초보를 한 단계 위로 데려갑니다.
답글 남기기