안티그래비티 작업 속도, 터미널과 WSL 중 진짜 승자는?

안티그래비티 작업 속도, 터미널과 WSL 중 진짜 승자는?

안티그래비티(Antigravity)를 처음 깔고 프로젝트를 돌릴 때 가장 먼저 부딪히는 갈림길이 있습니다. 윈도우 기본 PowerShell에서 그냥 쓸 것인가, 아니면 WSL2를 깔아서 리눅스 환경에서 돌릴 것인가의 문제입니다.

처음에는 둘 다 되니까 편한 쪽으로 시작했는데, 며칠 써보니 작업 속도와 안정성에서 차이가 꽤 컸습니다. 특히 에이전트가 npm install이나 git clone, 파일 일괄 수정 같은 명령을 자동으로 실행할 때 환경에 따라 결과가 갈렸습니다.

결론부터 말하면 어느 쪽이 무조건 좋다고 단정할 수는 없고, 작업 성격에 따라 승자가 달라집니다. 이 글에서는 양쪽을 직접 돌려보면서 느낀 속도 차이와 어떤 상황에서 어느 쪽이 유리한지 정리했습니다.

📌 핵심 요약

PowerShell은 윈도우 네이티브 작업에 강하고, WSL2는 파일 집약적 자동화 작업에 강합니다. 안티그래비티 에이전트의 자율 모드 특성상 WSL2 ext4 환경이 평균 2~5배 빠르며, 둘 다 깔아두고 프로젝트 단위로 분리 운용하는 것이 가장 효율적입니다.

📑 목차

• 1. 안티그래비티에서 터미널 환경이 중요한 이유
• 2. WSL2가 안티그래비티와 잘 맞는 이유
• 3. 작업별 속도 차이 직접 비교
• 4. 실전 추천 운용 방식
• 5. 정리 및 최종 결론

1. 안티그래비티에서 터미널 환경이 중요한 이유

안티그래비티는 2025년 11월 18일 구글이 Gemini 3와 함께 공개한 에이전트 중심 IDE입니다. 단순한 코드 자동완성 도구가 아니라, AI 에이전트가 직접 터미널 명령을 실행하고 브라우저 테스트까지 자율적으로 수행하는 구조입니다.

그래서 터미널 환경 자체가 작업 속도에 그대로 영향을 줍니다. 윈도우 PowerShell 환경은 별도 설치 없이 바로 시작할 수 있다는 점이 가장 큰 장점입니다.

PowerShell 환경의 특징

안티그래비티를 설치하면 기본 터미널이 PowerShell로 잡혀있고, 에이전트가 명령을 던지면 곧바로 윈도우 네이티브로 실행됩니다. GUI 도구나 윈도우 전용 SDK를 함께 쓰는 작업에서는 이 직결 구조가 빠릅니다.

다만 단점도 분명합니다. 리눅스 빌드 스크립트나 셸 스크립트가 섞여 있으면 호환성 문제가 잦고, npm install처럼 작은 파일을 대량으로 다루는 작업에서는 NTFS 한계로 속도가 떨어집니다.

2. WSL2가 안티그래비티와 잘 맞는 이유

반면 WSL2는 윈도우 안에 가상 리눅스 커널을 올려서 돌리는 방식입니다. 마이크로소프트 공식 문서에 따르면 git clone, npm install, apt update 같은 파일 집약적 작업에서 WSL1 대비 약 2배에서 5배 빠른 속도를 보여주고, 압축 파일 해제 작업은 최대 20배까지 빨라집니다.

이게 WSL2 내부 파일 시스템 안에서 작업할 때의 이야기인데, 안티그래비티 에이전트가 자율적으로 수십 개 파일을 동시에 만들고 수정하는 작업 패턴과 잘 맞아떨어집니다. 실제로 같은 리액트 프로젝트의 의존성 설치 시간이 WSL2 환경에서 절반 가까이 줄어드는 경험을 했습니다.

⚠️ 주의할 함정

WSL2 안의 파일을 윈도우 측에서 접근하면 가상화 계층을 거치기 때문에 읽기는 1.1배에서 10.2배, 쓰기는 1.7배에서 2.8배까지 느려진다는 벤치마크가 있습니다. 즉 프로젝트 폴더의 위치가 속도를 좌우합니다.

3. 작업별 속도 차이 직접 비교

양쪽 환경에서 같은 작업을 돌려보면 차이가 더 분명해집니다. 가벼운 작업과 무거운 작업으로 나눠서 비교해 봤습니다.

작업 종류	PowerShell	WSL2	권장 환경
단일 파일 수정	빠름	빠름	PowerShell
npm install	느림	빠름	WSL2
git clone	보통	빠름	WSL2
도커 빌드	매우 느림	매우 빠름	WSL2
GUI 앱 연동	빠름	보통	PowerShell
브라우저 자동화	보통	빠름	WSL2

체감상 가장 큰 차이가 나는 지점은 의존성 설치와 빌드 단계였습니다. PowerShell에서 3분 넘게 걸리던 npm install이 WSL2 ext4 파일 시스템에서는 1분 30초 내외로 끝났습니다.

반대로 단일 파일 수정이나 간단한 스크립트 실행은 PowerShell이 오히려 비슷했습니다. 결국 핵심은 파일 입출력 빈도입니다. 에이전트가 한 번에 수십에서 수백 개 파일을 건드리는 자율 모드 작업이라면 WSL2가 압도적으로 유리하고, 단발성 명령 위주라면 환경 차이가 거의 없습니다.

4. 실전 추천 운용 방식

그러면 어떻게 쓰는 게 정답일까요. 결론은 둘 다 깔아두고 프로젝트 단위로 분리하는 것입니다.

실제로 PowerShell에서 안티그래비티 터미널 실행이 막혔던 사용자가 프로젝트 폴더를 WSL로 옮기고 Remote-WSL로 접속하자 정상 작동했다는 후기가 다수 보입니다. 거꾸로 평소에 WSL을 기본 터미널로 잡아두면 일부 윈도우 SDK 작업에서 오류가 나는 경우도 있어서, 안티그래비티 설정에서 기본 셸을 PowerShell 7로 바꾸면 해결된 사례도 함께 보고됩니다.

🎯 추천 운용 3원칙

• 리눅스 기반 백엔드, 도커, 노드 프로젝트는 WSL2 ext4 영역에 두고 Remote-WSL로 접속
• 윈도우 데스크톱 앱, 닷넷, 파워셸 자동화 작업은 PowerShell로 진행
• 윈도우 탐색기 경로로 WSL 파일을 직접 만지지 않을 것

이 세 가지만 지켜도 속도 손실의 80%는 막을 수 있습니다.

5. 정리 및 최종 결론

양쪽을 직접 돌려본 입장에서 정리하면, 단순 비교로 승자를 가리기는 어렵지만 안티그래비티의 진가를 뽑아내려면 WSL2 쪽이 더 잘 맞습니다.

에이전트가 자율적으로 파일을 대량으로 다루고 빌드와 테스트까지 연쇄로 실행하는 워크플로우 자체가 리눅스 환경에 최적화되어 있기 때문입니다. 다만 윈도우 네이티브 도구와 자주 연동하거나 단발성 가벼운 작업 위주라면 굳이 WSL을 깔 필요 없이 PowerShell로도 충분합니다.

✅ 최종 결론

개인적으로는 WSL2를 기본으로 두고 윈도우 전용 작업이 생길 때만 PowerShell을 여는 운용이 가장 만족스러웠습니다.