HOLOLOG
GitHub

WSL vs Windows 개발 환경 세팅: 개발팀에서 나만 wsl일 때 무슨 문제가 발생할까. (nextjs, java Spring)

hojun lee · 11/09/2025
커버이미지

Windows에서 개발할 때 고생을 많이했다. 괜히 맥맥맥맥맥 하는게 아니었다. mac 으로 개발해보니 알게되었다. 쾌적하다라는 말은 이럴때 쓰는거였다.

근데 이번 회사에서 제일 좋은 갤럭시북을 줬다. 하하 다시 windows 환경이다.

WSL을 선택한 개인적인 이유

Path 지옥에서의 탈출 Windows 환경에서 개발할 때 가장 고통스러웠던 건 환경변수 설정.

Node.js, Python, Java 등 여러 개발 도구를 설치하다 보면 Path가 꼬이는 경우가 많았고, 특히 버전 관리가 복잡했음.

# Windows Path 설정 예시
C:\Program Files\nodejs\
C:\Python39\
C:\Program Files\Java\jdk-17\bin
C:\Program Files\Java\jdk-21\bin  # 이게 문제의 시작

반면 WSL에서는 ~/.bashrc나 ~/.zshrc에서 깔끔하게 관리할 수 있었음

export PATH="$HOME/.nvm/versions/node/v20.0.0/bin:$PATH"
export JAVA_HOME="/usr/lib/jvm/java-21-openjdk-amd64"

Mac에서 Windows로 전환하면서 이전 회사에서 Mac으로 개발하다가 현재 회사에서 Windows를 지급받았음. Mac의 Unix 기반 터미널에 익숙했던 터라 PowerShell이나 CMD는 너무 생소했음. WSL은 거의 완벽한 Linux 환경을 제공해서 전환 비용을 크게 줄여줬음.

팀에서 나만 WSL 환경일 때 벌어지는 문제

상황: 나만 WSL, 팀원들은 모두 Windows

  • 팀원 5명 중 나만 WSL Ubuntu 환경 -나머지 4명은 Windows 네이티브 환경 -프론트엔드(NextJS), 백엔드(Java Spring) 모두 같은 코드베이스 사용

이 차이가 나중에 얼마나 큰 문제를 일으킬지 알지못함.

NextJS SWC 컴파일 문제 - 폐쇄망의 함정

문제 발생

NextJS 15 프로젝트에서 WSL 환경 실행 시 다음 오류 발생:

Error: Failed to load SWC binary for linux/x64
Platform: linux-x64-gnu
Error: ENOTFOUND github.com

팀원들(Windows)은 정상 실행되는데 나(WSL)만 실패했음.

원인

  • NextJS의 SWC는 OS별 네이티브 바이너리가 필요하며, npm install 시 GitHub Release에서 자동 다운로드
  • 폐쇄망 환경에서 GitHub CDN 차단
  • WSL은 Windows 프록시 설정을 자동 상속하지 않아 다운로드 실패
  • 팀원들의 Windows는 회사 IT가 설정한 프록시로 정상 동작

해결 방법 (요약)

  1. 외부 환경에서 Linux용 SWC 바이너리 수동 다운로드
  2. WSL 환경이면 로컬 캐시에서 바이너리 복사, Windows면 npm 기본 동작 사용
  3. package.json에서 디펜던시 옵셔널로 지정

자세한 구현 과정은 별도 블로그 글로 정리 예정

본론 3: Java Spring SDK 실행 문제

문제 상황

IntelliJ에서 WSL의 Java 프로젝트 실행 시 여러 문제 발생:

  1. Java 8로 컴파일되는 문제 (프로젝트는 Java 21)
  2. Maven 의존성 다운로드 실패 (Nexus 인증)
  3. DB 접근 IP 화이트리스트 문제 (결정타) 
java: source value 8 is obsolete and will be removed in a future release
java: pattern matching in instanceof is not supported in -source 8

원인 분석

1. Java 버전 문제:

  • IntelliJ의 Java Compiler 설정이 Maven보다 우선순위 높음
  • Per-module bytecode version에 모듈이 8로 고정되어 있었음
  • .idea/compiler.xml에 캐시된 설정 잔류

2. Maven Nexus 인증 문제:

  • WSL의 ~/.m2/settings.xml은 있었지만 Windows로 옮기면서 누락
  • 폐쇄망에서 401 Unauthorized 에러 발생 
<!-- settings.xml 필수 -->
<servers>
    <server>
        <id>nexus</id>
        <username>nexus_id</username>
        <password>nexus_password</password>
    </server>
</servers>

3. DB 접근 IP 문제 (가장 치명적):

![WSL DB 접근 차단](generated_image 가상 네트워크 IP(172.30.98.229) 사용

  • Windows는 내부망 고정 IP(10.11.5.168) 사용
  • DB 방화벽은 10.11.5.168만 화이트리스트에 등록
  • WSL IP는 차단됨

해결 시도와 한계

포트포워딩 시도:

# Windows → WSL 포트포워딩 (인바운드만 가능)
netsh interface portproxy add v4tov4 listenport=8080 listenaddress=10.11.5.168 connectport=8080 connectaddress=172.30.98.229

이 방법은 외부에서 WSL로 들어오는 트래픽만 처리 가능. WSL에서 DB로 나가는 트래픽의 발신 IP는 변경 불가. 근본적 해결책 아님.

최종 결정: Windows로 전환

결국 프로젝트를 Windows(C:\dev)로 이동하고 다음 작업 수행:

  1. WSL의 ~/.m2/settings.xml을 Windows로 복사
  2. Maven 캐시 삭제: .m2/repository/org/springframework 삭제
  3. IntelliJ Java Compiler 설정에서 Per-module bytecode version 제거
  4. Project Structure에서 모든 Java 버전을 21로 통일 
# Windows에서 정상 실행 확인
mvn clean install
mvn spring-boot:run

Windows IP로 DB 접근이 정상 작동했고, 팀원들과 동일한 환경이 됨.

자세한 링크

본론 4: 프론트는 WSL, 백엔드는 Windows로 분리 개발 시 문제점

시나리오: 절충안으로 하이브리드 환경 시도

Windows로 전환하기 전, 다음과 같은 절충안을 고려했음:

  • 프론트엔드(NextJS): WSL에서 개발 (익숙한 Linux 환경)
  • 백엔드(Java Spring): Windows에서 개발 (DB 접근 문제 해결)

발생한 문제들

1. 파일 시스템 속도 저하

WSL에서 Windows 파일 시스템(/mnt/c/) 접근 시 I/O 성능 저하:

  • WSL 내부 파일: npm install 약 30초
  • Windows 파일(/mnt/c/): npm install 약 2분

2. Git 줄바꿈 문제 (CRLF vs LF)

# WSL에서 커밋
warning: LF will be replaced by CRLF in src/App.tsx

# Windows에서 풀
modified:   src/App.tsx (줄바꿈만 바뀜)

팀원들과 불필요한 diff가 계속 발생함.

4. 포트 바인딩 혼선

  • 프론트(WSL): localhost:3000
  • 백엔드(Windows): localhost:8080

WSL에서 Windows의 localhost:8080에 접근은 가능하지만, 반대는 복잡했음 (포트포워딩 필요).

5. 환경변수 관리 이중화

  • 프론트: ~/.bashrc (WSL)
  • 백엔드: 시스템 환경변수 (Windows)

두 곳을 따로 관리하다 보니 실수가 잦았음.

본론 5: 결국 Windows로 통일한 이유

최종 결정: 팀 표준 환경 따르기

고민 끝에 모든 개발 환경을 Windows 네이티브로 통일했음. 이유는:

  1. 협업 효율: 팀원들과 똑같은 오류를 공유하고 해결책도 빠르게 공유됨
  2. 온보딩 간소화: 신입 개발자가 들어와도 설정 가이드가 단순함
  3. 트러블슈팅 시간 절약: 구글링 시 대부분의 해결책이 Windows 기준
  4. 회사 인프라 정책: 내부망, VPN, 보안 프로그램 등이 모두 Windows 최적화

WSL의 장점을 포기하면서 얻은 것

  • 팀 전체의 개발 속도 향상
  • 불필요한 환경 차이 디버깅 시간 제로
  • DB, 내부 API 등 회사 인프라 접근 안정화
  • "이거 왜 나만 안 돼?" 같은 대화가 사라짐

결론: 개인 선호 vs 팀 협업의 균형

배운 점

  1. "나한테 좋은 환경" ≠ "팀에 좋은 환경": 개인적으로 WSL이 편했지만, 팀 협업에서는 오히려 독이 됨
  2. 환경 통일의 중요성: 같은 코드, 같은 도구, 같은 문제를 공유해야 효율이 올라감
  3. 회사 인프라 고려: 개발 환경은 회사의 네트워크, 보안 정책과 맞아떨어져야 함
  4. 폐쇄망 환경의 특수성: 네이티브 바이너리 의존성, 프록시 설정, IP 제약 등 고려사항이 많음

WSL을 선택해도 되는 경우

  • 팀 전체가 WSL 사용
  • 오픈소스 프로젝트 (인프라 제약 없음)
  • 1인 개발 (협업 이슈 없음)
  • Docker/Kubernetes 위주 개발 (로컬 환경 의존도 낮음)
  • Windows 11 + WSL2 미러 모드 (네트워크 문제 완화)

Windows를 선택해야 하는 경우

  • 팀 대다수가 Windows 사용
  • 회사 내부망 DB/API 접근 필요
  • 폐쇄망 환경 (가지마셈)
  • Windows 전용 도구 사용 (특정 VPN 클라이언트 등)
  • 협업 환경 통일이 우선순위

마무리: 지금은 Windows에 적응 중

처음엔 PowerShell이 불편했지만, 지금은 oh-my-posh와 winget으로 어느 정도 만족스러운 환경을 구축했음. 무엇보다 팀원들과 "이거 왜 나만 안 돼?" 같은 대화가 사라진 게 가장 큰 수확이었음.

혼자 개발할 땐 WSL이 답이었지만, 팀으로 일할 땐 통일된 환경이 답.

부록: Windows 환경 개선 팁

PowerShell 꾸미기

# oh-my-posh 설치
winget install JanDeDobbeleer.OhMyPosh

# 터미널 테마 적용
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\atomic.omp.json"

패키지 관리

# winget으로 개발 도구 설치
winget install Git.Git
winget install OpenJS.NodeJS.LTS
winget install Volta.Volta  # Node 버전 관리
winget install Microsoft.OpenJDK.21

Git 설정

git config --global core.autocrlf true  # CRLF 자동 변환
git config --global core.eol lf  # 저장소는 LF 유지
  • WSL Windows 개발환경 비교
  • NextJS SWC WSL 컴파일 오류
  • Java Spring WSL Windows 차이
  • 개발팀 환경 통일 중요성
  • WSL path 환경변수 문제
  • Mac 개발자 Windows 전환
  • 프론트엔드 WSL 백엔드 Windows
  • 팀 협업 개발환경 설정
  • WSL 폐쇄망 네트워크 문제
  • Windows 네이티브 개발 장점
  • IntelliJ Java 버전 문제
  • Maven settings.xml 설정