Linux에서 돌아가던 AI의 Python 코드가 Windows에서 고장 나는 5가지 지점
요약
AI가 생성한 Python 코드가 Windows 환경에서 예상치 못한 오류를 일으킬 수 있는 5가지 지점을 분석합니다. 특히 `open()` 함수 사용 시 인코딩(`encoding=`) 명시와 CSV 파일 작성 시 개행 문자 처리(`newline=`)의 중요성을 강조하며, 개발자가 놓치기 쉬운 환경 변수 검증의 필요성도 제시합니다.
핵심 포인트
- `open()` 사용 시 반드시 `encoding=`을 지정하여 인코딩 문제를 방지해야 합니다.
- `csv.writer` 사용 시 개행 문자 오류를 막기 위해 `newline=''` 옵션을 추가해야 합니다.
- 파일 이름 생성 시 특수문자(`:`, `?`) 처리 방식에 대한 OS 레벨의 차이를 이해해야 합니다.
- 코드 검증 과정에서 환경 변수 설정이 실제 동작을 왜곡할 수 있으므로 주의가 필요합니다.
AI에게 작성시킨 Python 코드가 Windows에서도 작동하는지 확인하기 위한 작은 스크립트 모음이 있습니다. 얼마 전 이 스크립트들을 '한 번에 실행하는 담당자'를 거치지 않고 하나씩 직접 실행해 본 결과, 이전 기록과 다른 결과가 하나 나왔습니다.
원인은 한 번에 실행하는 담당자가 자식 프로세스에 PYTHONUTF8=1 (Python을 강제로 UTF-8로 작동시키는 설정)을 전달하고 있었기 때문이었습니다. 즉, Windows에서 가장 흔하게 발생하는 차이를 검증하는 사람이 스스로 없애고 있던 것입니다.
본문에서는 순수한 상태에서 재측정한 결과를 바탕으로, AI 코드가 Windows에서 고장 나기 쉬운 5가지 지점을 공개합니다. 이들은 모두 에디터 검색 한 번으로 해당 위치를 찾을 수 있습니다.
제공된 출력은 모두 실제로 실행하여 얻은 결과입니다 (Windows 10 Pro / Python 3.12.10, 2026-09-28).
open(에서 encoding=이 빠져 있는 경우
encoding을 명시하지 않고 한글을 저장한 후 UTF-8로 다시 읽어봅니다.
with path.open("w") as handle:
handle.write("일본어 텍스트\n")
순수한 Windows에서의 결과입니다.
locale.getpreferredencoding(False) = cp932
=== UTF-8로 읽을 수 있는지 ===
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x93 in position 0: invalid start byte
...
같은 기기에서 PYTHONUTF8=1을 적용하면 다음과 같이 됩니다.
locale.getpreferredencoding(False) = utf-8
=== UTF-8로 읽을 수 있는지 ===
읽었다 (기본값이 UTF-8일 가능성)
같은 PC, 같은 코드로 결과가 반대가 되었습니다. AI가 작성하는 코드는 encoding을 생략하는 경우가 많아 개발자의 환경(Mac・Linux・UTF-8 모드)에서는 통과해 버립니다. open(와 read_text(를 검색하여 encoding=이 붙어 있는지 확인해 보세요.
또 다른 교훈은, 검증을 실행하는 메커니즘의 환경 변수도 확인 대상이라는 것입니다. 제 경우, 출력 문자 깨짐을 피하기 위해 추가했던 한 줄이 확인하고 싶었던 동작 자체를 지워버렸습니다.
open(에 newline=가 없는 경우
2. CSV를 작성하는 코드
with csv_path.open("w", encoding="utf-8") as handle:
writer = csv.writer(handle)
=== CSV에서 이중 공백 줄이 나오는 예시 ===
바이트열: b'a,b\r\r\nc,d\r\r\n'
-> newline=""를 붙이지 않으면 빈 줄이 들어감
csv 모듈이 추가하는 개행에 Windows의 개행 변환이 한 번 더 적용되고 있습니다. 스프레드시트 프로그램으로 열면 1줄 간격마다 공백 줄이 들어갑니다. csv.writer를 검색하여 직전 open에 newline=가 있는지 확인하세요.
3. 제목이나 사람 이름에서 파일명을 만드는 경우
'file<name.txt' -> OSError: Invalid argument
'file:name.txt' -> 생성 가능
'file?name.txt' -> OSError: Invalid argument
...
:는 '생성 가능'으로 나오지만, 실제 내용은 다릅니다. file:name.txt에 한 글자를 작성한 후 폴더를 보면 다음과 같았습니다.
['file']
0
만들어진 것은 file이라는 이름의 0바이트 파일뿐이며, 작성했다고 생각하는 내용은 보이는 곳에 없습니다 (NTFS의 '대체 데이터 스트림'이라는 파일 내부 저장 위치로 들어갑니다). 에러가 발생하지 않기 때문에 ?나 *처럼 당연히 실패하는 것보다 인지하기 어려운 고장 방식입니다.
で差し替えます。
=== 開いたまま上書きで置き換える ===
PermissionError: アクセスが拒否されました。
'임시 파일에 작성한 후 덮어쓰기'는 고장 나기 어려운 방식으로 정석적이지만, Windows에서는 덮어쓸 대상이 열려 있는 것만으로 실패합니다. 스프레드시트 프로그램에서 CSV를 열어둔 채로 출력하는 일반적인 사용 사례에서 발생합니다. os.replace()와 .rename()을 검색하여 실패했을 때의 메시지가 있는지 확인해 보세요.
5. 원래 이름에 문자를 추가하기
100자: 작성 가능
200자: 작성 가능
255자: OSError
파일명 하나에도 길이가 제한이 있습니다. '원래 이름 + 날짜 + _backup'처럼 덧붙이는 처리를 여러 번 거치면 한계에 도달합니다. 참고로, 이 PC에서는 폴더를 60단계 깊이, 전체 경로 길이로 335자까지 만들 수 있었습니다. 전체 경로의 상한선은 설정에 따라 달라지므로, 직접 테스트해도 다른 PC에서 작동한다고 보장할 수는 없습니다.
요약
| 검색할 구문 | 확인할 내용 | 발생 상황 |
|---|---|
open( / read_text( | encoding=이 있는지 | 일본어를 읽고 쓰는 모든 경우 |
csv.writer | 직전의 open에 newline='' | CSV를 출력할 때 |
`f
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기