개발자 운영체제 선택: 우분투·macOS·윈도우 장단점과 누구에게 어떤 OS가 맞는지

들어가며

“개발자라면 리눅스를 써야 한다”는 말은 개발 커뮤니티에서 자주 반복됩니다. 실제로 서버, 클라우드, 컨테이너 생태계 대부분이 리눅스 위에서 돌아가고 있으니 틀린 말은 아닙니다. 하지만 이 말을 그대로 받아들여서 모든 개발자가 우분투로 넘어가야 한다고 결론 내리면 절반만 맞는 조언이 됩니다. iOS 앱을 만드는 사람에게는 macOS가 사실상 강제되고, 언리얼엔진으로 게임을 만드는 사람에게는 윈도우가 훨씬 매끄러운 선택입니다. 회사 업무 도구가 전부 윈도우 기반이라면 리눅스로 갈아타는 것 자체가 비생산적인 선택일 수도 있습니다.

이 글은 “어떤 OS가 최고인가”라는 질문 대신 “무엇을 만드는 사람에게 어떤 OS가 마찰이 적은가”라는 질문에 답하려 합니다. 타깃 플랫폼, 필수 도구, 팀 환경, 그리고 개인이 쓸 수 있는 하드웨어에 따라 답은 꽤 명확하게 갈립니다. 우분투·macOS·윈도우 각각의 실질적인 장단점을 먼저 짚고, 직군별로 어떤 선택이 합리적인지, 그리고 하나의 OS만 고집하지 않고 여러 개를 조합해 쓰는 실전 구성까지 다룹니다.

우분투: 서버와 같은 환경, 그리고 그 대가

왜 개발자들이 우분투를 선택하는가

우분투를 메인 개발 환경으로 쓰는 가장 근본적인 이유는 “배포 환경과 개발 환경을 일치시킬 수 있다”는 데 있습니다. AWS, GCP, Azure의 기본 VM 이미지 대부분이 우분투를 제공하고, GitHub Actions나 GitLab CI의 기본 러너도 우분투 기반입니다. Docker 컨테이너 역시 리눅스 네임스페이스와 cgroups 위에서 동작하는 기술이라, 우분투에서는 별도의 가상화 계층 없이 네이티브로 돌아갑니다. 반면 macOS와 윈도우에서 Docker를 쓰면 내부적으로 경량 리눅스 VM을 하나 띄우고 그 안에서 컨테이너를 실행하는 구조라, 파일 공유 성능이나 리소스 오버헤드 면에서 우분투와 차이가 생깁니다.

패키지 관리 측면에서도 우분투는 강점이 있습니다. apt로 대부분의 개발 도구를 몇 초 안에 설치할 수 있고, 공식 저장소에 없는 최신 버전이 필요하면 PPA(Personal Package Archive)를 추가해 해결하는 경우가 많습니다. 다만 PPA는 서드파티 저장소이므로 신뢰할 수 있는 출처인지 확인하지 않고 아무거나 추가하면 시스템 안정성에 영향을 줄 수 있습니다. 최근에는 Snap과 Flatpak처럼 배포판 버전에 덜 의존적인 패키징 방식도 널리 쓰이는데, 앱 구동 속도가 느리거나(특히 Snap의 콜드 스타트) 샌드박스 정책 때문에 파일 접근 권한 문제가 생기는 경우가 있어 상황에 따라 apt와 섞어 쓰는 것이 현실적입니다.

우분투의 LTS(Long Term Support) 릴리스 정책도 실무에서 중요합니다. LTS는 2년마다 나오고 5년간 표준 지원을 받기 때문에, 한번 세팅해 둔 서버나 개발 환경을 몇 년간 큰 변화 없이 유지할 수 있습니다. 프로덕션 서버는 대부분 LTS를 쓰고, 로컬 개발 환경도 같은 버전으로 맞춰두면 “내 컴퓨터에서는 되는데 서버에서는 안 되는” 문제를 줄일 수 있습니다.

이 외에도 우분투가 강점을 갖는 영역이 몇 가지 더 있습니다. 셸 스크립트 기반 자동화, 커널 레벨 작업(커스텀 드라이버, eBPF를 이용한 관측/보안 도구, 성능 프로파일링), 그리고 로보틱스 분야입니다. ROS2(Robot Operating System 2)는 공식적으로 특정 우분투 LTS 버전을 타깃으로 배포되기 때문에, 로봇 소프트웨어를 다루는 개발자에게는 우분투가 사실상 기본 선택지입니다. 임베디드 개발에서 크로스 컴파일 툴체인을 구성하거나 CUDA 기반 ML 학습 서버를 운영하는 경우에도 우분투 생태계의 문서와 드라이버 지원이 가장 두텁습니다. 그리고 무엇보다 무료이고 상대적으로 가벼워서, 오래된 하드웨어에서도 쾌적하게 돌아간다는 점이 실용적인 매력으로 작용합니다.

우분투의 단점을 솔직하게 말하면

우분투를 메인으로 쓰기로 결심했을 때 처음 부딪히는 장벽은 대체로 하드웨어 쪽입니다. NVIDIA 그래픽카드가 있다면 드라이버 설치 자체는 어렵지 않지만, Secure Boot가 켜진 상태에서는 커널 모듈 서명(MOK, Machine Owner Key) 등록 과정을 거쳐야 하고 이 단계를 건너뛰면 로그인 후 검은 화면만 보게 되는 경우가 흔합니다. 일부 노트북의 Wi-Fi 칩셋이나 지문 인식 센서는 리눅스 드라이버 지원이 아예 없거나 불안정하고, 고해상도 디스플레이의 프랙셔널 스케일링(150%, 175% 같은 배율)이 애플리케이션마다 흐릿하게 렌더링되는 문제도 여전히 남아 있습니다. Wayland로 기본 세션이 바뀐 이후로는 화면 공유나 원격 제어가 일부 애플리케이션에서 아직 X11만큼 매끄럽지 않은 경우도 있습니다.

한국에서 개발하는 입장이라면 한글 입력기(fcitx5, ibus)의 완성도와 안정성도 체감상 macOS나 윈도우의 IME보다 떨어지는 경우가 있고, 공동인증서 기반 은행/공공기관 사이트나 일부 관공서 서비스는 리눅스를 아예 지원하지 않아 별도의 윈도우 VM이나 다른 기기가 필요합니다. 카카오톡 PC 버전도 리눅스 네이티브 클라이언트가 없어 웹 버전이나 안드로이드 에뮬레이터로 우회해야 합니다. 여기에 Microsoft Office와 어도비 제품군의 리눅스 네이티브 버전이 없다는 점, 그리고 게임 라이브러리 대다수가 여전히 윈도우 우선이라는 점도 실사용에서 느끼는 제약입니다.

왜 하필 우분투인가

리눅스 배포판은 Fedora, Arch, Pop!_OS 등 선택지가 많습니다. Fedora는 최신 패키지를 빠르게 반영하고, Arch는 필요한 만큼만 설치하는 미니멀리즘과 커스터마이징 자유도가 강점이며, Pop!_OS는 NVIDIA 드라이버와 하이브리드 그래픽 지원이 기본 내장되어 있어 설치 직후 경험이 매끄럽습니다. 그럼에도 우분투가 기본 선택지로 자리잡은 이유는 압도적인 문서량과 커뮤니티 Q&A 축적, 그리고 클라우드/CI 벤더의 기본 지원 때문입니다. 어떤 에러 메시지를 검색해도 우분투 기준 해결책이 가장 먼저 나오고, 상용 소프트웨어(예: 일부 상용 CAD, DB 툴)의 리눅스 지원 목록에도 우분투가 가장 먼저 이름을 올리는 경우가 많습니다.

macOS: 유닉스 터미널과 상업용 앱의 조합

macOS는 BSD 계열 유닉스 커널 위에 만들어져 있어서, 터미널에서 bash/zsh를 쓰고 POSIX 도구 대부분이 그대로 동작한다는 점에서 리눅스와 개발 경험이 상당히 비슷합니다. 여기에 Homebrew라는 성숙한 패키지 매니저가 있어 brew install만으로 대부분의 CLI 도구와 언어 런타임을 설치할 수 있고, 동시에 상업용 디자인 툴, 문서 작업 도구, 오피스 스위트도 네이티브로 잘 돌아갑니다. 무엇보다 iOS/macOS 앱을 만들려면 Xcode가 필수인데 Xcode는 macOS 전용이라, 모바일(iOS) 개발자에게는 사실상 선택의 여지가 없는 플랫폼입니다.

애플 실리콘(M 시리즈) 칩으로 전환된 이후에는 성능당 전력 효율이 크게 개선되어, 배터리로 하루 종일 컴파일과 빌드를 반복해도 발열과 배터리 소모가 인텔 시절보다 훨씬 적습니다. 레티나 디스플레이의 HiDPI 렌더링 품질과 트랙패드 제스처, 전체적인 하드웨어 마감 완성도도 여전히 개발용 노트북으로서 강점입니다.

단점도 명확합니다. 우선 가격이 높고 하드웨어 구성을 자유롭게 고를 수 없습니다. 메모리나 저장공간을 나중에 업그레이드하는 것이 불가능한 모델이 대부분이라, 구매 시점에 필요한 사양을 넉넉히 예측해서 골라야 합니다. 애플 실리콘의 ARM 아키텍처로 넘어가면서 생긴 문제도 실무에서 자주 부딪힙니다. Docker Desktop은 macOS에서 리눅스 VM을 하나 띄우고 그 안에서 컨테이너를 돌리는 구조라, 볼륨 마운트를 통한 파일 공유 시 I/O 오버헤드가 발생하고 대량의 파일을 다루는 프로젝트(예: node_modules가 많은 모노레포)에서는 체감될 정도로 느려질 수 있습니다. 여기에 arm64와 amd64 이미지가 섞여 있는 팀 환경에서는 이미지 태그를 잘못 받아와 “로컬에서만 안 되는” 문제가 생기기도 하고, 이 경우 Rosetta 2나 QEMU 기반 에뮬레이션으로 x86 이미지를 돌리면 동작은 하지만 성능이 크게 떨어집니다. 오래된 x86 전용 도구나 일부 상용 소프트웨어가 ARM 네이티브 빌드를 아직 제공하지 않는 경우도 남아 있고, macOS의 기본 유틸리티(sed, date 등)는 BSD 계열이라 리눅스의 GNU coreutils와 옵션 문법이 미묘하게 달라 스크립트를 그대로 복사해 쓰면 에러가 나는 경우도 흔합니다. 예를 들어 sed -i 옵션은 BSD 버전에서 백업 확장자를 필수로 요구하는 문법 차이가 있어, GNU 기준으로 짠 스크립트가 macOS에서 그대로 실패하는 대표적인 사례입니다. 게이밍 라이브러리와 하드웨어 커스터마이징 자유도가 낮다는 점도 다른 두 OS 대비 약점으로 꼽힙니다.

윈도우: 가장 넓은 저변과 WSL2

윈도우는 데스크톱 OS 중 가장 넓은 사용자 기반을 갖고 있고, 그만큼 엔터프라이즈 환경과 기업 내부 도구가 윈도우를 기준으로 만들어진 경우가 많습니다. .NET/윈도우 데스크톱 애플리케이션을 개발한다면 Visual Studio와 윈도우가 가장 자연스러운 조합이고, 게임 개발 쪽에서도 언리얼엔진과 유니티의 실무 워크플로우, DirectX 기반 그래픽스 디버깅 도구, 콘솔 플랫폼 SDK 대부분이 윈도우를 기본 타깃으로 설계되어 있습니다. 하드웨어 선택 폭이 가장 넓어 예산과 용도에 맞춰 부품을 자유롭게 고를 수 있다는 점, Office 생태계와의 호환성, 그리고 한국의 은행/공공기관 웹사이트가 여전히 윈도우와 특정 브라우저 조합을 우선 지원한다는 점도 실무에서 무시할 수 없는 요소입니다.

윈도우 개발 환경에 대한 인식을 크게 바꾼 것은 WSL2입니다. 이전의 WSL1이 시스템 콜을 변환해주는 호환 계층이었다면, WSL2는 실제 리눅스 커널을 경량 VM 위에서 그대로 돌리는 방식이라 대부분의 리눅스 네이티브 도구가 별다른 이슈 없이 동작합니다. 다만 완벽하지는 않습니다. /mnt/c 경로를 통해 윈도우 파일시스템에 접근하면 9P 프로토콜을 거치는 구조라 파일 수가 많은 프로젝트에서 체감될 정도로 느리고, 네트워킹 모드(NAT 기본값, 최근 지원되는 mirrored 모드)에 따라 localhost 공유 동작이 달라지는 것도 익숙해지기 전까지는 헷갈리는 지점입니다. GPU 연산(CUDA)은 윈도우 쪽 NVIDIA 드라이버가 WSL2에 노출해주는 방식으로 지원되지만, 실시간성이 중요한 하드웨어 제어나 USB 장치 저수준 접근은 여전히 제약이 있습니다. 이 비교는 WSL2와 듀얼 부팅 선택 가이드에서 더 자세히 다뤘습니다.

윈도우의 단점 중 실무에서 가장 자주 부딪히는 것은 경로 구분자(\)와 줄바꿈 문자(CRLF), 그리고 파일시스템의 대소문자 비구분 정책입니다. 리눅스나 macOS에서 만든 스크립트를 그대로 윈도우에서 돌리면 경로 처리나 줄바꿈 관련 오류가 나는 경우가 흔하고, PowerShell과 bash의 문법 차이 때문에 팀 내에서 스크립트를 두 벌 유지해야 하는 상황도 생깁니다. 백신 프로그램이 빌드 폴더를 실시간 검사하면서 컴파일 속도를 눈에 띄게 늦추는 경우도 있고, 시스템 업데이트로 인한 강제 재시작이 작업 흐름을 끊는 것도 개발자 입장에서는 불편한 지점입니다. 일부 오픈소스 도구는 여전히 윈도우 지원이 2순위라 문서가 부족하거나 특정 기능이 리눅스/맥에만 있는 경우도 있습니다.

세 OS 비교표

아래 표는 개발 작업에서 자주 부딪히는 기준으로 세 OS를 정리한 것입니다. 절대적인 점수가 아니라 “이 기준에서는 이 OS가 상대적으로 유리하다”는 비교로 읽어야 합니다.

기준	우분투	macOS	윈도우
서버/클라우드 환경 일치	가장 유리. 대부분의 클라우드 이미지·CI 러너가 우분투 기반	유닉스 계열이라 셸/도구 호환성은 좋으나 커널은 다름	WSL2로 근접하지만 네이티브는 아님
컨테이너(Docker)	네이티브 실행, 오버헤드 없음	리눅스 VM 경유, 파일 공유 I/O 오버헤드	Docker Desktop이 WSL2 백엔드 경유
모바일 앱 개발	안드로이드는 가능, iOS 불가	iOS/안드로이드 모두 가능 (Xcode 필수)	안드로이드는 가능, iOS 불가
게임/그래픽스 개발	상대적으로 도구 생태계 약함	Metal API 기반 개발 가능, DirectX 타깃은 불리	언리얼/유니티 실무 워크플로우, DirectX 디버깅 최적
하드웨어 선택 폭	넓음(기존 PC 대부분 설치 가능)	애플 기기로 제한	가장 넓음
가격	무료, 저사양 하드웨어도 활용 가능	높음, 업그레이드 제약	하드웨어 가격대 다양
한국 업무 환경(은행/공공기관)	지원 안 되는 경우 많음	브라우저로 우회 가능한 경우 많음	가장 원활
배터리/노트북 효율	기종별 편차 큼	애플 실리콘 이후 최상급	기종별 편차 큼
커스터마이징 자유도	매우 높음	낮음	중간
학습 곡선(입문자 기준)	상대적으로 높음	중간	낮음(익숙함)

누구에게 어떤 OS가 어울리나

백엔드/인프라 개발자

서버가 리눅스에서 돈다면 로컬 환경도 리눅스로 맞추는 것이 디버깅 시간을 가장 많이 아낍니다. 우분투 네이티브나 macOS 둘 다 합리적인 선택이고, 회사 지급 노트북이 윈도우라면 WSL2로 시작해도 충분한 경우가 많습니다. 컨테이너 오케스트레이션, 쉘 스크립트 자동화, systemd 서비스 운영 경험을 쌓고 싶다면 우분투 네이티브 쪽이 더 배울 것이 많습니다.

프론트엔드/웹 개발자

Node.js, 브라우저 개발자 도구, 대부분의 프레임워크 CLI는 세 OS 어디서든 잘 동작합니다. 이 경우에는 OS보다 팀의 관례와 개인 취향이 더 중요한 기준이 됩니다. macOS는 디자이너/PM과의 협업 도구 호환성이 좋고, 우분투는 가볍고 빠르며, 윈도우는 회사 업무 도구와의 통합이 좋습니다.

iOS/안드로이드 모바일 개발자

iOS 개발자라면 사실상 macOS가 필수입니다. 안드로이드만 개발한다면 세 OS 모두 Android Studio가 잘 동작하지만, 크로스 플랫폼(React Native, Flutter)으로 iOS/안드로이드를 동시에 다룬다면 결국 macOS 한 대는 있어야 빌드와 배포 파이프라인을 완결할 수 있습니다.

게임/그래픽스 개발자

언리얼엔진이나 유니티로 PC/콘솔 게임을 만든다면 윈도우가 실무 마찰이 가장 적습니다. 비주얼 스튜디오 디버거, DirectX 셰이더 디버깅 도구, 콘솔 플랫폼 SDK 대부분이 윈도우 우선이기 때문입니다. 다만 모바일 게임이나 애플 생태계(Metal, visionOS 등)를 타깃으로 한다면 macOS가 필요해집니다.

임베디드/로봇(ROS2)/C++ 시스템 프로그래머

우분투 LTS가 사실상 기본값입니다. ROS2 공식 배포가 특정 우분투 버전을 타깃으로 하고, 크로스 컴파일 툴체인과 드라이버 문서도 우분투 기준으로 가장 잘 정리되어 있습니다. 실시간 하드웨어 제어나 커널 모듈 작업이 잦다면 WSL2가 아니라 네이티브 설치나 듀얼 부팅을 권합니다.

데이터/ML 엔지니어

CUDA 기반 학습 서버를 다룬다면 우분투가 표준입니다. 로컬 개발 환경은 macOS(애플 실리콘 GPU로 소규모 실험)나 WSL2를 깐 윈도우로도 충분한 경우가 많지만, 실제 대규모 학습은 결국 우분투 서버에서 돌리게 되므로 로컬 환경도 우분투로 맞추면 명령어와 도구 체계가 일관됩니다.

학생/입문자

지금 갖고 있는 노트북을 그대로 쓰는 것이 최선입니다. OS를 갈아타는 데 드는 시간과 시행착오가 학습 초반의 실질적인 장벽이 되는 경우가 많습니다. 여유가 있고 웹 개발을 배우는 중이라면 macOS나 WSL2를 설치한 윈도우가 이후 취업 후 서버 환경 적응에 도움이 됩니다.

회사 지급 노트북만 있는 경우

대부분 윈도우가 지급되는데, 관리자 권한이 있다면 WSL2로 시작하는 것이 가장 마찰이 적습니다. 회사 정책상 WSL2도 막혀 있다면 SSH로 접속하는 원격 개발 서버나 클라우드 개발 환경을 대안으로 쓸 수 있습니다.

1인 개발/프리랜서

만들려는 결과물이 무엇인지가 기준입니다. SaaS 백엔드나 API 서버라면 우분투나 macOS, 모바일 앱이라면 macOS, 윈도우 데스크톱 유틸리티나 게임이라면 윈도우입니다. 여러 플랫폼을 동시에 지원해야 한다면 뒤에서 다룰 하이브리드 구성을 적극적으로 활용하는 것이 현실적입니다.

하이브리드 구성: 하나만 고르지 않아도 된다

실무에서는 하나의 OS만 고집하기보다 여러 방식을 조합해서 쓰는 경우가 더 많습니다.

WSL2는 윈도우 노트북에서 리눅스 커널을 그대로 쓰는 가장 가벼운 방법입니다. 재부팅 없이 즉시 켜고 끌 수 있고, 실패해도 앱 제거 수준으로 되돌릴 수 있어 위험 부담이 거의 없습니다. GPU 연산이 필요한 경우에도 윈도우 드라이버를 그대로 활용할 수 있어 딥러닝 실험에도 무리가 없습니다. 자세한 설정과 성능 팁은 WSL2와 듀얼 부팅 비교 가이드에 정리했습니다.

듀얼 부팅은 실시간 하드웨어 제어나 커널 모듈 개발처럼 VM 계층이 방해가 되는 작업에 필요합니다. 다만 파티션과 부트로더를 직접 건드리는 작업이라 절차를 잘못 따르면 기존 윈도우 부팅에 영향을 줄 수 있으므로, 별도 물리 디스크를 쓰는 방식이 가장 안전합니다. 우분투 데스크톱 사용법 자체가 낯설다면 윈도우 개발자를 위한 우분투 적응 가이드를, 설치 후 실전 명령어는 우분투 필수 명령어 가이드와 우분투 VS Code 개발 팁을, 노트북 하드웨어별 세팅은 씽크패드 우분투 개발 환경 가이드를 참고하시기 바랍니다.

가상머신(VM)은 macOS나 윈도우 위에 우분투를 올려서 격리된 환경을 쓰는 방법입니다. 성능 오버헤드가 WSL2보다 크고 GPU 패스스루 설정이 까다롭지만, 여러 버전의 리눅스를 동시에 테스트하거나 완전히 격리된 실험 환경이 필요할 때 유용합니다.

원격 개발은 로컬 OS와 무관하게 SSH로 리눅스 서버에 접속해 VS Code Remote-SSH나 Dev Container로 작업하는 방식입니다. 로컬 머신의 사양이나 OS 제약에서 자유로워지고, 팀 전체가 동일한 개발 컨테이너 이미지를 쓰면 “내 컴퓨터에서만 되는” 문제 자체를 구조적으로 없앨 수 있습니다. GitHub Codespaces 같은 클라우드 개발 환경도 같은 맥락입니다.

macOS + 리눅스 서버 조합도 흔합니다. 로컬에서는 macOS의 쾌적한 UX와 배터리 효율을 누리면서, 실제 실행이 필요한 작업(도커 빌드, GPU 학습, 프로덕션과 동일한 환경 테스트)은 SSH로 붙는 원격 우분투 서버에서 처리하는 방식입니다.

팀에서 OS가 섞여 있을 때 실제로 부딪히는 문제

팀원들이 서로 다른 OS를 쓰는 상황은 이제 예외가 아니라 기본값에 가깝습니다. 이때 반복적으로 발생하는 문제들이 있습니다.

줄바꿈 문자 차이(윈도우 CRLF vs 유닉스 계열 LF)는 .gitattributes에 * text=auto와 확장자별 규칙을 명시해 Git이 자동으로 정규화하도록 하는 것이 가장 확실한 해결책입니다. 파일명 대소문자 처리 방식도 문제가 됩니다. macOS와 윈도우 기본 파일시스템은 대소문자를 구분하지 않는 반면 리눅스 ext4는 구분하기 때문에, Component.tsx와 component.tsx를 같은 파일로 착각하고 커밋했다가 리눅스 CI에서만 빌드가 깨지는 사고가 흔합니다. 경로 구분자 문제는 코드에서 path.join류의 플랫폼 독립적인 API를 쓰는 것으로 대부분 해결되지만, 셸 스크립트는 애초에 bash 전용으로 통일하고 윈도우 팀원은 WSL2나 Git Bash에서 실행하도록 규칙을 맞추는 편이 유지보수가 쉽습니다. Docker 이미지를 여러 아키텍처(amd64/arm64)에서 섞어 쓰는 팀이라면 docker build --platform linux/amd64처럼 플랫폼을 명시하지 않으면 애플 실리콘 맥에서 빌드한 이미지가 프로덕션 서버에서 실행되지 않는 사고가 날 수 있습니다. 이런 문제들을 근본적으로 줄이는 방법은 결국 개발 환경 자체를 컨테이너나 Dev Container로 통일해서, 로컬 OS가 무엇이든 실제 빌드/실행은 같은 이미지 안에서 이뤄지도록 만드는 것입니다.

그래서 어떤 기준으로 고를 것인가

OS를 정하기 전에 아래 질문에 먼저 답해보는 것을 권합니다.

• 만들려는 결과물의 타깃 플랫폼이 무엇인가? (서버/웹, iOS, 안드로이드, 윈도우 데스크톱, 콘솔/PC 게임)
• 필수 도구가 특정 OS 전용인가? (Xcode, 특정 상용 CAD 소프트웨어, DirectX 디버거)
• 실시간 하드웨어 제어나 USB 저수준 접근이 필요한가? (필요하다면 VM/WSL2보다 네이티브가 유리)
• 팀의 CI/배포 환경과 로컬 환경을 얼마나 일치시켜야 하는가?
• 지금 갖고 있는 하드웨어를 바꿀 수 있는가, 아니면 기존 장비로 시작해야 하는가?
• 회사 정책이나 IT 보안 규정이 OS 선택 자체를 제한하는가?
• 배터리와 이동성이 중요한 업무 방식인가, 아니면 고정된 자리에서만 작업하는가?
• 한국의 은행/공공기관 서비스나 특정 국내 소프트웨어를 얼마나 자주 써야 하는가?

이 질문들에 대한 답이 겹치는 지점이 많을수록 하나의 OS로 충분하고, 답이 서로 다른 방향을 가리킬수록 하이브리드 구성(WSL2, 원격 개발, VM)을 고려하는 것이 현실적입니다.

마치며

우분투로 처음 넘어갔을 때 가장 먼저 부딪혔던 것은 거창한 커널 문제가 아니라 한글 입력기였습니다. fcitx5 설정에서 한/영 전환 키가 다른 단축키와 충돌해 몇 번을 껐다 켰다 했고, 특정 애플리케이션에서는 조합 중인 글자가 화면에 안 보이다가 엔터를 눌러야 갑자기 나타나는 증상 때문에 초반 며칠은 메모장에 먼저 쓰고 복사하는 웃긴 방식으로 버텼습니다. 지금 생각하면 사소한 문제였지만, “리눅스가 개발에 더 좋다”는 말만 믿고 넘어온 사람 입장에서는 이런 자잘한 마찰이 생산성 이야기보다 먼저 체감되는 부분이었습니다.

애플 실리콘으로 넘어간 이후로는 반대 방향의 마찰을 겪었습니다. 팀에서 쓰던 Docker 이미지 중 일부가 amd64 전용으로 빌드되어 있었는데, 맥에서 그대로 받아 실행하면 QEMU 에뮬레이션으로 돌아가면서 로컬 개발 서버 응답이 눈에 띄게 느려졌습니다. 원인을 찾기 전까지는 “내 맥이 느린가” 하고 의심했는데, 결국 이미지 태그에 아키텍처를 명시하지 않은 팀의 빌드 스크립트 문제였습니다. 이런 경험들은 결국 OS 자체의 우열보다 “내가 무엇을 만들고, 어떤 환경과 맞춰야 하는가”를 먼저 따져야 한다는 것을 다시 확인시켜 줬습니다. 정답은 하나로 정해져 있지 않고, 지금 하는 작업의 요구사항이 답을 정합니다.