OS 호환성 삽질의 기록

1. 파일 시스템의 변화를 추적하는 기능을 사용하려고 했음

2. inotify 기반의 라이브러리를 최종적으로 선택함 (그나마 PoC를 통과한 몇 안 되는 라이브러리였음)

3. 원래 inotify 기능은 리눅스 커널에서 지원하는 기능이라 맥에서는 아예 C 라이브러리를 동적 로딩하다가 실패함. 주위에 조언을 구해보니 리눅스 컨테이너를 이용해서 개발하는 게 좋겠다고 함

4. x86_64 리눅스 서버에 배포할 예정이라서 실리콘 맥북 환경에 힘들게 개발용 amd64 리눅스 컨테이너를 마련했음

5. inotify 기능을 써보려고 하니 안 됨. 이상해서 검색해보니 (맥용 도커는 QEMU 위에서 가상화된 리눅스 위에 설치되는 건데) QEMU가 inotify 기능을 지원해주지 않는다고 함

6. 결국 실리콘 맥북 개발 환경에서는 inotify 기능을 테스트해볼 방법이 없음

6.5 맥에서는 원래 inotify 대신 kqueue 기능을 사용하는 것임

7. inotify와 kqueue를 아우르는 C 라이브러리도 있지만 이걸 파이썬용으로 만든 라이브러리는 버그가 있음. 원 저자에게 패치 제안을 했으나 묵묵부답

8. 7번이 해결된다고 하더라도 맥북 개발환경에서 리눅스 커널 일부 기능을 테스트하는 건 애초에 불가능한 문제였음을 깨달음

9. 컨테이너라는 건 원래 배포용이라, 개발용으로 dockerfile 빌드를 해보니 개발 lifecycle하고 당췌 맞질 않음

9.5 일반적으로 개발을 하려면 hot reload가 되어야 하는데 그러려면 프로젝트 디렉토리 볼륨을 공유해야 하고 외부 의존성 설치를 해야 하는데 외부 의존성은 requirements.txt나 package.json 등의 프로젝트 파일을 이용해야 함. 그런데 docker build 단계에서는 아직 볼륨 공유가 안 되어 있고 docker run 단계에 들어가야 볼륨 공유가 됨. (COPY 명령으로 일부 해결할 수 있긴 함)

10. 이런 저런 이유로 리눅스 커널과 관련있는 기능은 개발 환경에서의 테스트는 포기해고 서비스 환경에서 테스트를 해야 했음

11. C 바이너리 개발도 비슷하면서 약간 다른 문제가 있는데, 실리콘 맥북에서 x86_64 리눅스 바이너리를 개발해서 컨테이너로 배포하려면 상당히 어려움 (docker가 멀티 아키텍처 빌드를 지원하긴 함)

11.5. 서비스용 서버들이 arm64 아키텍처를 채택하면 실리콘 맥북 환경과 서비스용 서버의 호환성이 높겠지만, 그게 현실화되기 전에 내가 업계에서 은퇴할 것 같음 (nvidia의 ARM 인수 실패가 최소 몇 년을 지연시켰음)

12. 오픈소스 라이브러리를 여러 가지 PoC 하다보면 오픈소스 생태계는 참으로 취약하다는 걸 느끼게 됨. 주요 프레임웍을 최신 버전으로 사용하려고 시도하면 오픈소스 의존성들이 대응이 늦어서 제대로 동작하지 않는 많은 문제점을 발견함 (ex. react 18을 사용하면 16에서 잘 동작하던 facebook oauth 라이브러리가 동작하지 않는다든가)

12.5 오픈소스니까 (PR보내기 전에) 버그 제보와 패치 제안을 해보긴 하는데, 잘 받아주는 원 저자들도 일부 있지만 대부분은 대답조차 없거나, 거절하거나, 받아주긴 하는데 빠르게 릴리즈를 잘 안 해줌