Page history of 윈도우 개발환경 삽질기

Preview HTML

Diff with current

---

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 &gt;= 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이다. 하지만 cygwin은 최신 패키지 지원이 한 박자 늦고 지원되는 패키지 수가 적다. 어차피 Window 네이티브와의 조합이 필요하다면 굳이 파이썬을 cygwin으로 설치해서 얻는 이득이 별로 없다. 그래서 cygwin은 시도해보지 않는다. VirtualBox는 아무리 좋아졌다고는 하나 여전히 느리고 스위칭이 불편하기 때문에 다른 모든 방법에 나쁘다고 판단할 경우에만 선택할 것이다. Windows 네이티브는 이미 여러 번 실험해봐서 가능하고 약간 불편하지만 그럭저럭 쓸만하다는 사실을 알고 있는 상태다. WSL은 bash.exe를 통해서만 리눅스 바이너리를 실행할 수 있다는 치명적인 단점(이것 때문에 PyCharm에서 직접 local interpreter로 지정할 수 없다)이 있지만 그 단점은 일부분 회피 가능하고, 윈도우 개발툴로 편집하고 리눅스 서버로 돌아가는 상황을 VirtualBox보다 좀더 매끄럽게 연출할 수 있다. 그래서 WSL 세팅을 먼저 시작해보았다.</p>
<h3>Windows Subsystem for Linux</h3>
<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>
<h4>WSL로 X 서버 사용하기</h4>
<p>예전에 WSL 자료 찾다가 스쳐지나가면서 본 내용 중에 X를 쓸 수 있다는 것이 있었다. MS는 WSL에 xserver 패키지를 탑재하지 않았지만 xming 등의 서버를 윈도에서 띄우고 그 서버에 접속해서 gnome 앱을 띄우는 게 가능하다. 나는 vcxsrv를 써서 했는데, 생각보다 너무 쉽게 성공했다. 그렇다면 이걸로 PyCharm을 WSL 안에서 띄워서 쓸 수 있지 않을까? 실제로 윈도우와 리눅스가 완전히 통합된 것 같은 느낌으로 개발용 GUI 툴도 전부 리눅스용을 쓰면서 작업이 가능하다. 그래서 PyCharm 리눅스 버전도 받아서 실행해봤다.</p>
<h3>Windows 네이티브 개발환경</h3>
<p>Windows 네이티브로 개발환경을 구축한다는 것은 리눅스 호환 시도를 하지 않고 윈도우용으로 빌드된 소프트웨어를 설치해서 사용한다는 것이다. 가장 윈도우스러운 방법이지만 posix 계열 개발자들이 윈도우에서 되도록 하고 싶어하지 않는 일이기도 하다. 하지만, 과거의 경험을 떠올려봐도 윈도우용으로 직접 빌드된 소프트웨어를 쓸 때 가장 안정적이긴 했다. 다만, 이 경우 posix 계열에 비해 크게 불편한 점이 여러 가지 있다.</p>
<h4>패키지 관리</h4>
<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>
<p> </p>
<h4>터미널</h4>
<p>두번쨰 문제는 터미널(과 쉘)이다. 옛날옛적의 cmd는 허접하기 그지 없었는데, 특히 가장 결정적인 문제는 창 크기 조절이 제대로 안된다는 거였다. 가로폭을 자유롭게 조정할 수 없었다. 다행히 이제 그 문제는 해결되어 있다. 하지만 여전히 맥이나 리눅스에 비하면 허접하기 그지 없다. 다만, 이 문제는 좀 나누어서 생각할 필요가 있다. 커맨드라인의 역할을 터미널과 쉘로 나누어서 본다면 터미널 쪽은 이제 쓸만하다. 창 크기 조절, 폰트 설정, copy &amp; 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><strong>터미널 해결: cmder</strong></p>
<p> </p>
<h3>폰트 가독성 문제</h3>
<p>맥북프로 레티나 15인치를 쓰다가 넘어오니까 폰트 가독성이 너무 심하게 차이가 났다. 이거 윈도에 뭔가 결함이 있는 것이 아닌지 의심이 들 정도였다. 하지만 이리저리 추적해본 결과 원인을 알았다. 맥북프로 레티나 15인치는 실제로 15.4인치에 해상도는 레티나로 2880x1800, 일반 해상도로 환산하면 1440x900이고, 삼성 노트북 펜 15인치는 딱 15인치에 1920x1080이다. 물리적인 화면은 맥북이 큰데 폰트가 렌더링되는 기준 해상도는 더 낮아서 동일한 크기의 폰트라면 맥북이 3~40% 크게 표시된다. 그런데 맥북은 레티나니까 더 선명하다. 같은 글자가 맥북에서 더 크고 더 선명하게 보인다는 뜻이다. 실제로 삼성 노트북 펜의 권장 세팅으로 보이는 글자 크기는 시력이 나쁜 나에게는 도저히 못 써먹을 수준이었다. 삼성 노트북의 문제만이 아니라 서피스 프로도 그랬다. 윈도우가 이런 문제에 개념이 아직 부족한 것 같다. 추정컨데, 애플은 하드웨어와 소프트웨어를 같이 만드니까 맥북의 크기를 잡을 때부터 적절한 해상도를 정했을 것이고, 윈도우 노트북이나 안드로이드 기기들처럼 물리적인 화면 크기는 작은데 해상도가 높아서 기본 세팅에서 글자가 아주 작게 보이는 현상이 일어날 수 없게 통제 가능했을 것이고, 또 의도적으로 통제했을 것이다. 윈도우도 고해상도 스크린이 쏟아져나오는 상황에서 이런 문제에 대해 좀더 세심한 대응이 필요하다.</p>
<p>그래도 대응이 전혀 없는 것은 아닌 게, <q>텍스트, 앱 및 기타 항목의 크기 변경</q>이라는 기능이 있어서 퍼센티지로 키울 수 있다. 서피스 프로에서도 이 기능으로 확대를 해서 썼고 이번에도 150%로 확대를 해서 썼다. 그런데, 확대하는 퍼센티지에 따라 폰트 렌더링이 달라졌다. 150%에서는 폰트가 뭉개지는 현상이 여기저기서 발생했다. 가까이서 보니 거의 버그 수준이다. 그래서 확대 수준, 해상도, 폰트 크기 등을 이리저리 변경해봤는데, 그 때마다 뭉개지는 지점이 달랐다. 175%에서는 대부분 안 뭉개졌지만 너무 컸고, 125%에서는 더 많이 뭉개졌다. 다행히 150%에서 폰트 사이즈를 이리저리 조절해서 안 뭉개지는 지점을 찾을 수 있었다. 이 확대 기능이 폰트를 렌더링할 때 확대하는 게 아니라 마치 폰트 렌더링을 다 하고 나서 확대를 하는 것 같은 느낌이 들 지경이다. 그렇다고 해상도 자체를 낮춰버리면 뭉개지진 않는데 대신 흐릿해보인다. </p>
<p>폰트 종류도 좀 고민이 되어서 이것저것 다 깔아봤는데, 어차피 윈도우 기본 폰트를 변경하는 게 까다롭기도 하고 맑은 고딕이 꽤 괜찮기도 해서 대부분의 케이스에 맑은 고딕을 그냥 쓰기로 했고, 고정폭이 필요한 경우는 굴림체로 되어 있는 경우가 많아서 Consolas로 바꾸고 Fallback 폰트로 D2Coding을 지정하거나, 혹은 아예 처음부터 D2Coding으로 적용했다.