Title:
윈도우 개발환경 삽질기
|
edited by
Youngrok Pak
at
6 years, 6 months ago.
<p>드디어 삼성 노트북 펜 15인치가 도착해서 세팅을 시작했다. 목표는 맥/리눅스에 근접할 정도로 편리한 개발 환경을 구축하는 것. 필요한 개발 환경은 대충 다음과 같은 것들이다.</p>
<ul>
<li>파이썬</li>
<li>node.js 기반의 프론트엔드 도구</li>
<li>안드로이드 앱</li>
<li>electron 기반의 데스크탑 앱</li>
<li>윈도우 앱 automation (pywinauto 등으로)</li>
<li>머신러닝 (1~2년 후에 필요)</li>
<li>iOS? (가능한 방법이 있을까?)</li>
</ul>
<p>이 중에 가장 중요한 것은 물론 파이썬이다. 파이썬 개발 환경 구축을 위해서는 다음과 같은 것들이 필요하다.</p>
<ul>
<li>git, ssh</li>
<li>python >= 3.6</li>
<li>pycharm에서 project interpreter 지정이 가능할 것</li>
<li>파이썬 패키지에서 사용하는 네이티브 라이브러리들, postgresql이나 rabbitmq 등 posix 기반에서 개발된 소프트웨어들</li>
<li>좋은 커맨드라인 인터페이스</li>
</ul>
<p>파이썬 다음으로 중요한 것은 node.js 기반 도구들인데, 파이썬과 요구사항은 비슷하다. 이런 요구사항을 소화하기 위해 가능한 옵션은 다음과 같은 것들이 있다.</p>
<ul>
<li>VirtualBox</li>
<li>cygwin</li>
<li>Windows 네이티브 + 커맨드라인 보조 툴(mingw 등) + Visual Studio(C/C++ Compiler)</li>
<li>Windows Subsystem for Linux</li>
</ul>
<p>내가 기술적으로 이상적이라고 생각하는 방안은 cygwin이다. 맥이 posix 호환을 통해 오픈소스 세상에서 살아남아 macport를 거쳐 homebrew 생태계가 완성되었듯, 윈도우도 네이티브 기반으로 posix 호환이 되면 오픈소스 생태계에 편입될 수 있다. 하지만 현실 속의 cygwin은 최신 패키지 지원이 한 박자 늦고 지원되는 패키지 수가 적다. 어차피 Window 네이티브와의 조합이 필요하다면 굳이 파이썬을 cygwin으로 설치해서 얻는 이득이 별로 없다. 그래서 cygwin은 시도해보지 않는다. VirtualBox는 아무리 좋아졌다고는 하나 여전히 느리고 스위칭이 불편하기 때문에 다른 모든 방법에 나쁘다고 판단할 경우에만 선택할 것이다. Windows 네이티브는 이미 여러 번 실험해봐서 가능하고 약간 불편하지만 그럭저럭 쓸만하다는 사실을 알고 있는 상태다. WSL은 bash.exe를 통해서만 리눅스 바이너리를 실행할 수 있다는 치명적인 단점(이것 때문에 PyCharm에서 직접 local interpreter로 지정할 수 없다)이 있지만 그 단점은 일부분 회피 가능하고, 윈도우 개발툴로 편집하고 리눅스 서버로 돌아가는 상황을 VirtualBox보다 좀더 매끄럽게 연출할 수 있다. 그래서 WSL 세팅을 먼저 시작해보았다.</p>
<h2>Windows Subsystem for Linux</h2>
<p>WSL의 가장 큰 장점은 무거운 가상머신 없이 리눅스와 윈도우의 상호운용이 가능하다는 것이다. VirtualBox 같은 가상머신이 들어가면 SSH와 공유 폴더를 통해 상호운용을 해야 하는데, 참을 만한 정도이기는 해도 개발자는 이 정도 편리함에 만족해서는 안된다고 생각한다. 그래서 윈도우 native를 이용할 때의 장점을 하나도 잃지 않으면서 Linux의 장점도 같이 살릴 방법을 찾기로 했다.</p>
<p>WSL을 그냥 사용하는 방법은 간단하다. <a href="https://docs.microsoft.com/en-us/windows/wsl/install-win10">WSL을 활성화</a>하고 ubuntu를 설치해서 ubuntu를 실행하면 bash.exe가 실행된다. 이 bash.exe 안에서는 완전한 linux처럼 쓸 수 있다. 초기에는 패키지가 다소 부족했지만이제 개발에 필요한 대부분의 우분투 패키지를 지원한다. X 서버가 지원되지 않지만 GUI 도구는 윈도우를 쓸 것이기 때문에 별 문제 없다. 쉘도 bash니까 충분히 편리하다. 쉘을 띄우는 터미널은 여전히 cmd 기반이지만 예전과 달리 창 크기 조절도 되고 별 문제는 없다. 여기까지는 OK.</p>
<p>가장 결정적인 문제는 PyCharm과 같은 IDE에서 연동하는 것이다. WSL에서 sshd를 띄우고 remote로 사용하는 것은 원래부터 가능하지만 이건 VirtualBox를 쓰는 거나 별 차이 없다. 그렇다면 굳이 완벽한 호환성을 보여주는 VirtualBox를 놔두고 불완전한 WSL을 쓸 필요가 없다. 하지만 PyCharm에서는 아직 WSL 지원이 없다. <a href="https://blog.jetbrains.com/ruby/2017/10/rubymine-2017-3-eap5-wsl-support-improved-parameter-hinting/">RubyMine의 WSL Support</a>를 보면 PyCharm에도 곧 될 것 같지만 아직은 안된다. 그런데, PyCharm이 project interpreter를 설정하는 방법은 실행가능한 파이썬 인터프리터를 지정해주는 것이다. WSL의 파이썬을 실행하고 싶으면 <code>bash -c "/path/to/python"</code>과 같이 실행할 수 있다는 점을 이용하면 batch 파일을 만들어서 해결할 수 있지 않을까? 그런 생각으로 이미 <a href="https://stackoverflow.com/a/37004847">python.bat</a>을 만드는데 성공한 사람이 있었다. 이걸 써보니 과연 project interpreter로 등록이 되고 pip 패키지도 정상적으로 리스트업된다. 그러나, 실제 파이썬 파일 파싱에는 실패하는지 컴파일 에러가 표시되고 pip 패키지도 자동으로 설치되지 않는다. 여러 가지 호환성 문제가 있는 것으로 추정된다. 이걸 끝까지 해킹해보면 아마도 해결할 수 있는 문제일 가능성이 크지만, 그냥 PyCharm에 WSL Support가 등장하길 기다리는 게 더 현명할 것 같다.</p>
<p>혹시나 해서 sshd를 띄우고 Remote Interpreter로 등록하는 것도 해보았는데, 잘 되긴 하지만 여전히 느리고 사소한 문제들이 이것저것 있어서 이걸 하느니 차라리 윈도우 네이티브를 선택하는 게 낫다고 판단했다.</p>
<p>하지만, 아직 WSL을 완전히 포기하진 않았다.</p>
<h3>WSL로 X 서버 사용하기</h3>
<p>예전에 WSL 자료 찾다가 스쳐지나가면서 본 내용 중에 X를 쓸 수 있다는 것이 있었다. MS는 WSL에 xserver 패키지를 탑재하지 않았지만 xming 등의 서버를 윈도에서 띄우고 그 서버에 접속해서 gnome 앱을 띄우는 게 가능하다. 나는 vcxsrv를 써서 했는데, 생각보다 너무 쉽게 성공했다. 그렇다면 이걸로 PyCharm을 WSL 안에서 띄워서 쓸 수 있지 않을까? 실제로 윈도우와 리눅스가 완전히 통합된 것 같은 느낌으로 개발용 GUI 툴도 전부 리눅스용을 쓰면서 작업이 가능하다. 그래서 PyCharm 리눅스 버전도 받아서 실행해봤다. 생각보다 너무 깔끔하게 잘 실행되었다. 딱 하나 문제가 있었는데 한글 입력이 안된다는 것. 하지만 이 문제도 아마 삽질하면 극복 가능할 것으로 보인다. 그놈 앱들의 경우 정상적으로 그놈 쉘에 로그인하지 않고 바로 실행해서 그런지 사소한 문제들이 이것저것 있었지만 역시 다 극복 가능한 것들이다. 이 방안도 삽질 조금 더 하면 좋은 대안이 될 것 같다.</p>
<h2>Windows 네이티브 개발환경</h2>
<p>Windows 네이티브로 개발환경을 구축한다는 것은 리눅스 호환 시도를 하지 않고 윈도우용으로 빌드된 소프트웨어를 설치해서 사용한다는 것이다. 가장 윈도우스러운 방법이지만 posix 계열 개발자들이 윈도우에서 되도록 하고 싶어하지 않는 일이기도 하다. 하지만, 과거의 경험을 떠올려봐도 윈도우용으로 직접 빌드된 소프트웨어를 쓸 때 가장 안정적이긴 했다. 다만, 이 경우 posix 계열에 비해 크게 불편한 점이 여러 가지 있다.</p>
<h3>패키지 관리</h3>
<p>가장 심각한 문제는 개발에 필요한 패키지를 직접 설치하는 것이 몹시 번거롭다는 것이다. 내가 지금 작업하고 있는 프로젝트를 제대로 돌리려면 파이썬, PostgreSQL, RabbitMQ, Redis, Java, Node.js, yarn 등이 잘 설치되어야 하는데, 윈도우에서는 각각 바이너리를 받아서 설치하려면 몹시 귀찮다. 리눅스라면 apt, 맥에서는 brew로 매우 손쉽게 해결되는 일인데, 윈도우는 그게 어렵다. 그래도 이런 것들은 한 번 설치하면 다시 건드리는 일이 드물어서 1년에 몇 번 안되는 일이긴 하다. 그래서, 수동으로 관리하는 것도 선택지이긴 하다. 그러나, 윈도우에도 brew와 같은 시도가 여러 가지 있기 때문에 실험을 해보기로 했다.</p>
<p>가장 먼저 써본 것은 인지도가 가장 높고 패키지 수도 가장 많은 chocolatey였다. 하지만 뭐가 문제인지 패키지 설치가 제대로 되지 않거나, 너무 오래걸리거나, 오래 걸리는데 진행률 피드백이 제대로 나오지 않았고, 매번 관리자 권한으로 powershell을 열어야 하는 것도 귀찮았다. 그래서 scoop으로 넘어갔다. 이미 파이썬과 PostgreSQL은 설치한 상태여서 node.js와 yarn을 시도해보았는데 아주 깔끔하게 잘 설치되었다. 이 정도면 brew만은 못하지만 그럭저럭 만족할 수 있을 것 같다.</p>
<p><strong>해결: scoop으로 먼저 install 해보고 없으면 수동으로 설치파일 받아서 설치한다.</strong></p>
<h3>터미널</h3>
<p>두번쨰 문제는 터미널(과 쉘)이다. 옛날옛적의 cmd는 허접하기 그지 없었는데, 특히 가장 결정적인 문제는 창 크기 조절이 제대로 안된다는 거였다. 가로폭을 자유롭게 조정할 수 없었다. 다행히 이제 그 문제는 해결되어 있다. 하지만 여전히 맥이나 리눅스에 비하면 허접하기 그지 없다. 다만, 이 문제는 좀 나누어서 생각할 필요가 있다. 커맨드라인의 역할을 터미널과 쉘로 나누어서 본다면 터미널 쪽은 이제 쓸만하다. 창 크기 조절, 폰트 설정, copy & paste 등 큰 문제는 없다. 딱 한 가지 부족한 점은 탭이 안된다는 것이다. 개발하다보면 한 프로젝트에서 여러 개의 터미널을 열어야 하는 경우가 많아서 나는 보통 프로젝트당 하나의 터미널 윈도우를 열고 그 안에서 탭으로 해당 프로젝트에 필요한 터미널들을 연다. 윈도우는 이게 안된다. 이건 git과 함께 설치되는 bash도 마찬가지고, WSL의 bash도 마찬가지다. 이 문제를 해결하려면 별도의 터미널 소프트웨어를 써야 한다. PowerShell ISE를 쓰면 탭은 되지만 조금 무겁고 runserver에서 output이 안 나온다. 뭔가 사용법을 상세히 배워야 쓸 수 있을 것 같다.</p>
<p>쉘 쪽은 cmd든 PowerShell이든 둘다 bash에 비해 불편하다. PowerShell은 cmd의 단점을 개선하기 위해 나온 거라는데 여러 가지로 기능이 많이 추가되었고, PowerShell에서만 쓸 수 있는 명령 중에 필요한 것도 이것저것 있지만, 대신 권한 문제가 좀더 까다롭다. 그래서 파이썬의 경우 venv의 activate를 그냥 실행할 수 없고 권한 설정을 변경해줘야 한다. 내 경우는 다음과 같이 해결했다.</p>
<pre>Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned<br>venv\Scripts\activate.ps1</pre>
<p>큰 문제는 없으나 bash의 편리함이 자꾸 생각난다. </p>
<p>그래서 대안을 찾기로 했다. cmd나 PowerShell은 터미널과 쉘이 일체형인 것으로 추정되는데, 대안 도구들은 두 개를 분리해서 쓸 수 있는 경우가 많은 것 같다. 처음 생각한 것은 git과 함께 배포되는 Git Bash인데, 이건 터미널은 mintty를 써서 mingw로 빌드된 bash를 띄운다. 둘다 편리하지만 탭이 없다. mintty에 탭 기능이 추가된 fork도 있지만 mingw 커뮤니티에서 정식으로 배포하는 게 아니다보니 좀 꺼려졌다. 그래서 일단 Git Bash는 보류.</p>
<p>windows best terminal로 검색하니까 여러 가지가 나온다. cmder이 여러 사이트에서 상위권으로 추천된다. console2, consolez, conemu 등등 다양하게 설치해봤는데, 깊이 써보지는 않았고 탭 기능이 잘 동작하는지, 첫 인상이 좋은지만 봤다. 일단 cmder는 탭 기능이 잘 동작했고, 쉘로 cmd와 powershell을 고를 수 있으며, 초기 폰트 세팅이나 컬러가 마음에 들었다. cmder를 먼저 써보고 다른 것들을 써봤는데 다른 것들은 모두 폰트 세팅이나 컬러가 맘에 안 들어서 굳이 더 깊이 써보지 않았다. 이 상태에서 cmder를 좀더 살펴보니 git을 설치했을 때 같이 설치한 ssh 등이 있는 경로를 PATH로 잡아준다는 장점도 있고, 쉘을 다양하게 선택할 수 있다는 점도 좋았다. 여러 모로 최적이라고 생각된다. scoop를 미리 알아둔 건 여기서 터미널 테스트할 때도 손쉽게 설치하고 테스트해볼 수 있어서 유용했다.</p>
<p>하지만 막상 작업할 때 쓰기 시작하자 살짝 느린 속도가 맘에 안 들었다. 그래서 그냥 탭 기능 안 쓰고 powershell을 쓸까 하다가, cmder의 기반인 conemu를 직접 써보면 어떨까 싶었다. 써보니 cmder보다 살짝 빠르다. cmder에서 powershell에 주는 요상한 옵션들을 안 주니까 더 좋은 것 같다. 단축키가 좀 이상해서 몇 가지만 바꿔주고 쓰니까 꽤 괜찮다.</p>
<p>powershell에서 ls가 추가된 건 좋은데 컬러가 안 나오니까 좀 별로였다. 그래서 <a href="https://github.com/joonro/Get-ChildItemColor">Get-ChildItemColor</a>라는 걸 찾아서 설치했는데 꽤 괜찮고 설치도 쉽다. 이걸 또 기본 프로파일에 넣고 싶어서 powershell의 기본 프로파일 어떻게 쓰는지 찾아보니 <a href="https://blogs.technet.microsoft.com/heyscriptingguy/2012/05/21/understanding-the-six-powershell-profiles/">Understanding the Six PowerShell Profiles</a>에 설명이 되어 있어서 $profile 찾아서 설정했다. 설정하는 김에 virtualenv도 넣어두니 편리하다. 원래는 virtualenv 용도로 direnv를 쓰려고 했는데, 윈도우에서는 좀 복잡한 것 같다. </p>
<p><strong>결론: ConEmu + PowerShell + color ls + custom profile</strong></p>
<h3>폰트 가독성 문제</h3>
<h4>맥과 윈도우의 폰트 렌더링 차이</h4>
<p>맥북프로 레티나 15인치를 쓰다가 넘어오니까 폰트 가독성이 너무 심하게 차이가 났다. 이거 윈도에 뭔가 결함이 있는 것이 아닌지 의심이 들 정도였다. 이리저리 추적해본 결과 몇 가지 원인이 나왔다. 일단 맥북프로 레티나 15인치는 실제로 15.4인치에 해상도는 레티나로 2880x1800, 일반 해상도로 환산하면 1440x900이고, 삼성 노트북 펜 15인치는 딱 15인치에 1920x1080이다. 물리적인 화면은 맥북이 큰데 폰트가 렌더링되는 기준 해상도는 더 낮아서 동일한 크기의 폰트라면 맥북이 3~40% 크게 표시된다. 그런데 맥북은 레티나니까 더 선명하다. 같은 글자가 맥북에서 더 크고 더 선명하게 보인다는 뜻이다. 삼성 노트북 펜의 권장 세팅으로 보이는 글자는 일단 크기부터가 너무 작아서 시력이 나쁜 나에게는 도저히 못 써먹을 수준이었다. 삼성 노트북의 문제만이 아니라 서피스 프로도 그랬다. 그래서 보통은 <q>텍스트, 앱 및 기타 항목의 크기 변경</q> 옵션을 150% 정도 놓고 쓴다. 문제는 이렇게 확대해도 폰트가 일그러지는 현상이 발생한다는 것이다. 확대 정도에 따라 일그러지는 부분이 달랐다. 그러니까, 윈도우에서는 같은 폰트라도 해상도나 확대 정도에 따라 폰트가 다르게 렌더링된다는 것이다. 이를테면 나눔바른고딕에서 '용'자를 놓고 보면 확대 크기에 따라 초성과 중성이 가까이 붙기도 하고 중성과 종성이 가까이 붙기도 한다. 이건 너무 심한 거 아닌가...</p>
<p>여기까지만 보면 윈도우의 폰트 렌더링은 후지고 맥은 좋은 것 같다. 하지만 외부 모니터를 연결해보면서 맥의 100% 우위는 아니라는 것을 알게 되었다. 찾아보니 윈도우와 맥은 폰트 렌더링에서 추구하는 바가 달랐다. 맥은 예전부터 폰트를 디자인된 원본에 최대한 가깝게 렌더링하는 것을 추구했다. 그래서 한글처럼 복잡한 글자는 낮은 해상도의 스크린에서 흐릿하게 보이는 단점이 있는 대신, 폰트 디자이너의 의도에 매우 가깝게 렌더링되어 항상 예쁘게 나왔다. 반대로 윈도우는 낮은 해상도의 스크린에서도 선명하게 보이는 것을 추구했기 때문에 어떤 해상도에서도 선명하게 보이는 대신 해상도나 확대 정도에 따라 폰트가 일그러지는 문제가 있다. 그래서 큰 외부 모니터에 연결하니 맥 화면은 폰트가 흐릿해보였고 윈도우 화면은 폰트가 일그러져 보였다.</p>
<p>하지만 맥은 이 문제를 레티나로 해결했다. 애플 기기들은 이제 대부분 레티나로 전환되었기 때문에 맥은 폰트 원래 디자인을 살리면서도 윈도우보다 더 선명하게 폰트를 렌더링한다. 외부 모니터에서는 장단점이 있지만 자체 기기에서는 맥의 완승인 것이다. 애플 기기들의 ppi는 큰 차이가 나지 않기 때문에 비슷한 pt 사이즈의 폰트는 실제로 보는 크기도 비슷하다. 하드웨어와 소프트웨어를 같이 만드는 전략의 승리다. 반면 윈도우 기기들은 크기와 해상도를 제멋대로 결정하기 때문에 삼성 노트북 펜과 같은 문제가 흔하게 발생한다.</p>
<p>이 문제는 윈도우 노트북도 제조사에서 화면 크기에 잘 맞는 해상도를 선택하되 레티나와 비슷한 ppi로 만들고, 윈도우에서 확대 옵션을 200%를 권장으로 설정하게 하면 해결될 것 같다. 사실 지금 삼성 노트북 펜만 해도 150%로 설정하고 폰트 렌더링 방식만 ClearType이 아닌 맥과 비슷한 전략을 취하면 많이 개선될 것 같다. </p>
<p><strong>반쪽 해결: 150% 확대를 하고 폰트를 잘 선택한다.</strong></p>
<h4>폰트 선택</h4>
<p>폰트 종류도 좀 고민이 되어서 이것저것 다 깔아봤는데, 어차피 윈도우 기본 폰트를 변경하는 게 까다롭기도 하고 맑은 고딕이 꽤 괜찮기도 해서 대부분의 케이스에 맑은 고딕을 그냥 쓰기로 했는데, 가끔 너무 얇다는 생각이 들었다. 그래서 나눔바른고딕으로 바꾸니까 큰 글씨는 괜찮은데, 작은 글씨는 위와 같은 문제가 발생했다. 해상도에 따라 글자가 일그러지는 문제도 컸다. 그래서 애플고딕이나 노토 산스를 가져와서 써보고 싶었는데 노토 산스는 쉽게 다운 받아서 설치할 수 있고 라이선스 문제도 없어서 먼저 써봤다. 써보니 예상보다 품질이 매우 좋았다. 일그러짐이 전혀 없진 않지만 크기를 이리저리 변경해도 별 문제가 없었다. 가독성도 더 좋다. 내 느낌으로는 산돌네오고딕 = 노토 산스 > 나눔바른고딕 >= 맑은 고딕 >>> 돋움 > 굴림이다.</p>
<p>고정폭이 필요한 경우는 굴림체로 되어 있는 경우가 많아서 Consolas로 바꾸고 Fallback 폰트로 D2Coding을 지정하거나, 혹은 아예 처음부터 D2Coding으로 적용했다. 노토 산스 모노도 상당히 좋다. 그런데, 구글 검색창에는 놀랍게도 폰트가 굴림으로 지정이 되어 있었다. 옛날에는 어떻게 굴림에 만족했을까 싶을 정도로 이상했다. 영문 폰트도 엉망진창이다. 그래서 굴림, 돋움 등을 아예 삭제할까 하는 생각에 검색해보니 의외로 쉽게 삭제가 가능했다. 제어판에서 그냥 한국어 추가 글꼴을 삭제하면 된다. 리부팅이 필요하긴 했지만, 여튼 지우고 나니 굴림을 볼 일은 사라졌다.</p>
<p><strong>해결: sans-serif는 Noto Sans, serif는 Noto Serif, monospace는 D2Coding </strong></p>
<h3>단축키 문제</h3>
<p>윈도우로 돌아와서 가장 불편한 것이 폰트라면 두번째는 단축키다. 윈도우에서 맥으로 넘어갈 때는 단축키에 적응 시간이 좀 필요했지만 더 편해졌다는 느낌을 많이 받았었다. 그 이유는 크게 두 가지인데, 첫번째는 맥 앱들의 단축키 일관성이 매우 높다는 것이다. 특히 대부분의 맥 앱은 설정 단축키가 <code>Command + ,</code>로 일정해서 새로운 앱을 세팅하기가 매우 쉽다. 하지만 윈도우는 다 제각각이고 단축키가 없는 경우도 많아서 불편하다.</p>
<p>두번째는 대부분의 단축키가 Command 키 하나로 쓸 수 있다는 것이다. copy & paste, 창 전환, 앱 내 창 전환, 탭 열기, 탭 닫기, 앱 종료, 새 문서 만들기, 저장 등등 자주 쓰는 명령은 모두 Command 키로 단축키가 연결된다. 단순히 Command 하나라서 좋은 게 아니라 Command는 엄지로 누르기 때문에 새끼손가락으로 눌러야 하는 CTRL보다 월등히 편하다. 내가 윈도우에서 맥으로 넘어와서 단축키 적응이 덜 되었을 때도 손이 편하다고 느꼈던 이유가 바로 이것이었다. 이 장점은 첫번째 장점인 일관성과 결합되어 시너지를 일으킨다. </p>
<p>윈도우로 돌아오고 나서는 이 장점이 너무 아쉬웠다. 윈도우 앱들은 정말 족보 없는 단축키가 난무한다. IntelliJ도 단축키가 엉망진창이다. 가만 생각해보니 나는 IntelliJ 계열을 맥으로 넘어오고 나서 쓰기 시작해서 윈도우 버전의 단축키가 이렇게 엉망진창인지 몰랐다. modifier 키를 쓰는 방식도 일관성이 없다. 그냥 개발자 마음에 드는 키를 아무 거나 갖다 붙이는 식이다. 이 문제는 아직 해결책을 발견하지 못했다.</p>
<p>그래도 단점만 있는 건 아니다. 윈도우 키가 워낙 편리해서 이런 단점들을 많이 상쇄한다. 윈도우 키로 뜨는 메뉴는 맥 스포트라이트보다 압도적으로 편리하고 윈도우 키랑 연계되는 다른 단축키들도 편리한 게 많다. 한영키가 편하고 맥과 달리 즉각적으로 반응한다는 점도 좋다. 안 쓴지 오래되서 덜 익숙하지만 Home, Pg Up, Pg Dn, End 키도 옛날처럼(?) 쓸 수 있다는 게 좋다. Backspace와 Delete가 따로 있고 따로 동작한다는 점도 좋다. 한자 키도 좋다. 그래서 단점들의 해법은 발견하지 못했지만 참고 쓸 수 있을 것 같다.</p>
<p><strong>미해결</strong></p>
<h2>결론</h2>
<p>WSL과 윈도우 네이티브 둘다 실무가 가능한 수준까지 세팅하는데는 성공했다. 일단은 좀더 안정적이고 검증된 윈도우 네이티브를 쓸 예정이지만, 시간이 나면 다시 WSL에서 GUI를 쓰는 방향을 검토해볼 것이다. 윈도우 네이티브 앱을 개발해야 될 가능성이 있다는 점도 이 방향으로 결정하는데 영향을 주었다. 맥에서 윈도우로 돌아오면서 걱정했던 개발 환경의 문제는 scoop과 powershell이 생각보다 많이 해결해주었다. 폰트 문제만 아니었다면 아마도 윈도우가 OS X보다 더 좋은 운영체제라는 결론을 내렸을지도 모른다. WSL은 발전 가능성이 기대되고, 전반적으로 윈도우가 좋은 방향으로 발전해가는 것 같다.
WikiNamu
영록이 홈페이지