복잡한 개발환경...
on
적어도 옛날엔 CPU라고 하는 게 거의 직접적으로 x86을 의미하던 시절이 있었어서 개발환경이 다양해봐야 고작 windows 아니면 linux 정도 였던 것 같다. 두 개의 개발환경이 워낙 달라서 윈도우즈에서 리눅스 바이너리를 돌린다거나 그 반대의 경우는 잘 없었지만 wine이란 것도 있었고 (지금도 있지만) djgpp 같은 것들이 뭐랄까 중간의 영역에 있었던 것 같다. 그 이후로 뭐랄까 두 영역의 중간에 위치하는 것들 꽤 많이 있었던 것 같은데, MacOS가 MC68k 시절을 지나 powerPC를 지나 x86으로 넘어왔을 때는 하나의 CPU 계통에서 3개의 다른 OS가 활발히 움직이는 상황이 되었고 Qualcomm이 ARM을 채택해서 개발하게 된 이후로는 임베디드나 모바일 생태계의 CPU가 desktop내지는 high power computing 세계로 진입했고 또 MIPS 또한 이 영역에 발을 담궜던 시절도 있었다. 그러다, ARM 세력이 막강해져서 MIPS는 사실상 거의 도태되다시피 해버렸고 ARM은 linux, 글고 android와 MacOS 그리고 Windows까지 갖춘 막강한 진영이 되었다.
2024년인 지금에서는 macOS에서 x86과 ARM binary를 동시에 돌릴 수 있는 상황에 이르렀지만 ARM 세계에서나 그렇고 x86 세계에서는 QEMU라든가 가상 머신을 돌려야 가능한 이야기가 되어있다. 말이 가상 머신이지 host CPU를 그대로 사용하는 경우가 아니면 그러니까 다른 CPU를 emulation하는 경우에는 속도가 매우 떨어지는데, 그래도 리모트로 다른 머신에 연결해서 뭔가를 하는 것보단 빠르지 싶어서 선택하게 되는 옵션이긴 하다.
그래서, 뭔가 영역을 넘어서 개발을 하게 되는 경우를 생각해보면 어떤 것이 나에게 유리할까를 늘 생각해보게 된다.
그러니까, 나의 개발환경은 arm + MacOS인데 x86의 linux shared object 같은 것들을 가져다 써야할 경우엔 이걸 어떻게 해야할까? 와 같은 문제에 어떻게 대응하는 것이 유리하냐 이런 거다.
다른 것을 다 떠나서 나의 노력을 최소화하면서도 최대의 효과를 얻는 경우가 어떤 것일까 하는 것이다.
가상머신을 쓰는 방법
장점은 내가 쓰는 머신에서 모든 것을 할 수 있다인데, 이거 설치하고 하느라 용량도 제법 잡아먹고 그다지 빠르지도 않다는 게 단점이다. 요샌 docker도 arm에서 x86 binary를 돌릴 수 있게 되었지만 그다지 빠르진 않다. 그래도 돌릴 수 있는 게 어디냐 하는 장점은 물론 있다만.
리모트 머신을 쓰는 방법
사실 이게 가장 편리하다. 괜히 (나처럼) 가상머신 쓰느라 골머리 썩지 말고 그냥 remote machine을 쓰면 편리하다. NFS나 SMB로 파일시스템 공유해서 작업하면 로컬로 쓰는 것보단 살짝 불편/느리지만 가상머신보단 훨 빠르고 노가다 안해도 되니 편하다.
리모트로 docker를 쓰는 방법
x86 linux라도 옛날 버전의 linux의 바이너리를 만들어야 된다든가 테스트해야 된다면 이 방법도 고려해볼 수 있다. 리모트의 x86 머신에 docker server를 두고 리모트로 작업하는 건데 리모트 머신을 직접 쓰는 것보단, 로컬 docker machine을 쓰는 것 보단 노가다가 살짝 더 들어가긴 하지만 이 방법도 생각할 수 있다.
내가 생각해봤을 때 가상머신을 그것도 이종의 CPU를 쓰려고 노가다를 하는 게 가장 비효율적이었다. 물론 내가 가진 머신이 딱 한 대 뿐이면 사실 가상 머신 돌리는 것 말고는 답이 없다. 그게 아니면 괜히 고생하지 말자.
또 내가 arm + macOS 환경을 쓰는데 x86 리눅스 바이너리를 써야 되겠다고 생각하는 경우도 마찬가지로 x86 가상 머신이 별로 빠르지 않고 노가다는 많이 들어가니 권하지 않는다. 이 경우 arm linux를 설치하고 그 위에서 x86 code를 돌려보려고 한다든가 하는 노력을 기울일 수도 있는데, 이게 말만 쉽지 실제로 굉장히 골치 아프다. 모든 linux distro가 다 쉽게 할 수 있는 것도 아니고. 게다가 괜시리 OS를 별도로 설치하느라 수십GB의 파일 시스템만 낭비하게 되는 경향이 있다.