윈도우 AI 코딩 도구 설정, 깔기 전에 점검할 네 가지
윈도우에서 AI 코딩 도구를 쓰려면 도구 설치와 별개로 미리 봐 둘 윈도우 설정이 몇 개 있다. 나는 git 커밋이 긴 경로에서 멈춘 일이랑 PowerShell 이 명령마다 다른 인코딩으로 파일을 쓴 일을 겪었다. 둘 다 미리 한 번 봐 뒀으면 안 헤맸을 것들이다.
윈도우 AI 코딩 도구 설정에서 먼저 볼 건 네 가지다. git 줄바꿈 설정(core.autocrlf 와 .gitattributes), 긴 경로(LongPathsEnabled 와 core.longpaths), PowerShell 실행 정책, 그리고 PowerShell 이 파일을 쓰는 인코딩. 네 가지 다 바꾸기 전에 지금 값부터 읽어 보는 게 순서다. 아래 내용은 2026년 10월 13일에 연 공식 문서와 내 PC 에서 읽은 값 기준이다.
윈도우 AI 코딩 도구 설정, 지금 값부터 읽기
바꾸는 명령보다 읽는 명령이 먼저다. 이 정도면 된다.
git --version
git config --show-scope --get-all core.autocrlf
git config --show-scope --get-all core.longpaths
(Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem).LongPathsEnabled
Get-ExecutionPolicy -List
$PSVersionTable.PSVersion.ToString()--show-scope 를 붙이면 그 값이 system 에서 왔는지, global 이나 저장소(local)에서 왔는지 같이 나온다. 같은 설정이 여러 군데 걸려 있으면 어디 걸 따르는지 헷갈리는데, 이걸로 한 번에 보인다.
내 PC 에선 이렇게 나왔다. core.autocrlf 는 system 에 true, 작업하던 저장소엔 local 로 false 가 따로 들어 있었다. 저장소 밖에서 같은 명령을 치면 system 의 true 만 나왔다. core.longpaths 는 아무 데도 없었고, 레지스트리 LongPathsEnabled 는 1. 실행 정책은 LocalMachine 이 RemoteSigned 였는데, 이 명령을 돌린 세션에선 Process 의 Bypass 가 우선했다. Process 값은 PC 에 저장되는 게 아니라 그 세션과 거기서 띄운 자식 PowerShell 세션에만 걸린다.
git 줄바꿈 설정, core.autocrlf 와 .gitattributes
윈도우는 줄 끝이 CRLF, 리눅스와 맥은 LF 다. AI 도구가 파일을 새로 쓰거나 고칠 때 어느 쪽으로 쓰는지가 도구마다 다를 수 있어서, 줄바꿈 규칙을 저장소에 먼저 정해 두는 게 편하다.
git-config 문서를 보면 core.autocrlf=true 는 모든 파일에 text=auto 를 걸고 core.eol 을 crlf 로 둔 것과 같다. 작업 폴더에선 CRLF, 저장소엔 LF 로 두고 싶을 때 쓰는 값이다. input 이면 꺼낼 때 변환을 안 한다.
근데 이 값은 PC 마다 다르다. 내 PC 처럼 system 에 true 가 들어 있는 경우도 있고, 다른 사람 PC 엔 없을 수도 있다. 그래서 저장소 안에 .gitattributes 로 같이 쓸 규칙을 적어 두는 쪽을 권한다. gitattributes 문서에 따르면 text 속성이 정해지지 않은 파일에만 core.autocrlf 로 변환 여부를 정한다. 다만 text=auto 만으로 작업 폴더의 줄바꿈까지 같아지는 건 아니다. eol 이 없으면 작업 폴더 쪽은 여전히 core.autocrlf, core.eol, 플랫폼을 따른다. 거기까지 정하려면 eol=lf 나 eol=crlf 도 적어야 한다.
문서에 나오는 예시는 이렇다.
* text=auto
*.sh text eol=lf
*.jpg -text* text=auto 는 git 이 글자 파일인지 스스로 판단해서 저장소엔 LF 로 넣게 한다. *.sh 같은 셸 스크립트는 작업 폴더에서도 LF 로 두고, 그림 파일은 변환하지 않게 막는 줄이다. 이미 파일이 들어 있는 저장소에 나중에 넣는다면 문서는 git add --renormalize . 로 다시 맞추고 커밋하라고 한다. 기존 파일을 한꺼번에 올리는 명령이라, 하던 변경을 먼저 정리해 두고 정규화 뒤엔 git status 로 바뀐 파일을 확인한 다음 커밋하자. 이 정규화 명령은 공식 문서 예시고 나는 이번에 돌려 보지 않았다.
하나 주의할 게 있다. 문서의 core.safecrlf 설명에 따르면 줄바꿈 변환은 글자 파일로 잘못 분류된 바이너리 파일을 망가뜨릴 수 있다. 그림이나 압축 파일 확장자가 있다면 -text 로 빼 두자.
윈도우 긴 경로 설정, LongPathsEnabled 와 core.longpaths
Microsoft 문서에 따르면 몇몇 예외를 빼면 윈도우 API 의 경로 한도 MAX_PATH 는 끝의 널 문자까지 쳐서 260자다. 윈도우 10 1607 부터 이 한도를 풀 수 있는데 조건이 둘이다. 레지스트리 HKLM\SYSTEM\CurrentControlSet\Control\FileSystem 의 LongPathsEnabled 가 1 이어야 하고, 프로그램 쪽도 긴 경로를 쓰겠다고 선언(longPathAware)해 둬야 한다. 레지스트리는 관리자 권한 PowerShell 에서 문서에 나온 New-ItemProperty 명령으로 켤 수 있고, 그룹 정책의 Enable Win32 long paths 로도 된다. 켠 뒤엔 이미 떠 있던 프로그램이 값을 모를 수 있어서 재부팅이 필요할 수 있다고 적혀 있다.
여기서 많이 헷갈린다. 레지스트리를 켰다고 모든 프로그램이 긴 경로를 읽는 게 아니다. 내 PC 도 LongPathsEnabled 가 1 이었는데 git 커밋이 282자 경로에서 Filename too long 으로 멈췄다. 그때 얘기는 지난 글에 적었다.
git 은 따로 켜야 한다. Git for Windows 안내를 보면 긴 경로 지원은 기본으로 꺼져 있고 git config core.longpaths true 로 켠다. 범위를 안 붙이고 저장소 안에서 치면 그 저장소 설정에 들어간다. C 로 된 git 명령에만 해당하고, 스크립트로 된 명령은 켜도 실패할 수 있다고 적혀 있다. 나는 지난번에 -c core.longpaths=true 로 한 번만 켜서 됐고, 평소엔 AI 도구가 쓰는 임시 파일을 짧은 경로에 두는 쪽으로 피해 가고 있다. 프로젝트 폴더 자체를 C:\dev 처럼 짧은 데 두는 것도 같은 이유로 도움이 된다.
PowerShell 실행 정책 확인
AI 코딩 도구가 .ps1 스크립트를 만들어 돌리려는데 실행 자체가 막히는 경우가 있다. 실행 정책 문서에 따르면 윈도우 클라이언트의 기본값은 Restricted 고, 이건 명령 한 줄씩은 되지만 스크립트 파일은 하나도 못 돌린다. 모든 범위가 Undefined 여도 Restricted 로 친다.
RemoteSigned 는 내 PC 에서 쓴 스크립트는 그냥 돌리고, 인터넷에서 받은 것으로 표시된 스크립트는 서명을 요구한다. 받는 방법에 따라 그 표시가 안 붙을 수도 있다고 문서에 나와 있다. 바꾸는 명령은 Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser 처럼 범위를 붙여 쓴다. LocalMachine 범위를 바꾸려면 관리자 권한으로 PowerShell 을 띄워야 한다고 문서에 나와 있다.
범위끼리는 우선순위가 있다. Process 가 제일 높고 그다음 CurrentUser, LocalMachine 순서. 그룹 정책으로 정해진 값은 이 셋보다 위라서, 회사 PC 라면 바꿔도 안 먹을 수 있다. 그리고 문서는 실행 정책이 보안 경계가 아니라고 분명히 적었다. 실수로 스크립트를 돌리지 않게 막는 정도라는 뜻이니, 편하자고 Bypass 를 아예 깔아 두는 건 권하지 않는다. 지금 정책에서 돌아간다면 바꿀 필요 없다. 꼭 바꿔야 한다면 돌릴 스크립트 내용부터 확인하고 필요한 정책과 범위를 정하자. 범위를 좁게 잡는다고 스크립트가 안전해지는 건 아니니까.
PowerShell 인코딩 설정은 버전부터
마지막은 인코딩이다. $PSVersionTable 로 버전부터 보자. 5.1 이면 조심할 게 많다.
인코딩 문서에 따르면 프로필 같은 곳에서 기본 인코딩 설정을 바꾸지 않은 5.1 은 명령에 인코딩을 따로 안 주면 Out-File 이랑 > 가 UTF-16LE 로 쓰고, Set-Content 는 새 파일이나 빈 파일에 쓸 때 시스템 ANSI 코드페이지로 쓴다. 프로필에서 기본 인코딩을 바꿔 뒀다면 결과가 달라질 수 있다. -Encoding UTF8 을 주면 BOM 이 붙는다. BOM 없는 스크립트는 ANSI 로 읽어서, 한글이 든 UTF-8 스크립트가 깨질 수 있다. PowerShell 6 부터는 기본이 BOM 없는 UTF-8 이라고 적혀 있다.
AI 도구가 PowerShell 로 파일을 쓰게 두면? 이 차이가 그대로 파일에 남는다. 명령마다 실제로 어떤 바이트가 나왔는지는 직접 재 본 글에 표로 정리해 뒀다. 프로젝트 규칙에 "파일은 UTF-8, BOM 없이, LF 로" 같은 줄을 적어 두면 도구에게도 사람에게도 기준이 생긴다. 다만 5.1 로 돌릴 한글 든 .ps1 은 예외로 두자. 문서는 이런 스크립트를 UTF-8 BOM 으로 저장하라고 한다.
네 가지를 다시 짚으면? git 줄바꿈은 .gitattributes 에 저장소 규칙을 적고 작업 폴더 쪽은 eol 까지 확인하고, 긴 경로는 레지스트리와 git 설정을 따로 보고, 실행 정책은 범위를 붙여 필요한 만큼만, 인코딩은 버전부터 확인. 바꾸는 건 그다음이다.
다음엔 AI 에게 설날 그림을 시켰더니 중국 춘절풍이 나온 얘기를 하려고 한다.