GN⁺: 대안 구현 문제(Alternative Implementation Problem)
(pointersgonewild.com)대안 구현의 문제
저자는 소프트웨어 세계에서 반복적으로 발생하는 대안 구현의 문제에 대해 이야기함. 저자의 경험은 주로 동적 타입 프로그래밍 언어를 최적화하는 것이었음.
- PyPy 프로젝트는 Python을 위한 고급 JIT 컴파일러를 개발했지만, 실제로는 거의 사용되지 않음. Python이 계속 새로운 기능을 추가하면서 변화하기 때문에 PyPy가 이를 따라잡기 어려웠음.
- LuaJIT은 높은 평가를 받고 있지만, Lua 언어가 계속 새로운 기능을 추가하면서 LuaJIT이 여러 버전 뒤쳐지는 상황임.
- TruffleRuby JIT은 가장 인상적인 성능을 자랑했지만 CRuby에 비해 기능 호환성이 부족해 제한적인 배포만 이루어짐.
교훈: 대안 구현은 실패할 수밖에 없는 선택임
- 대안 구현을 만들면, 정식 구현체의 변화에 종속될 수밖에 없음.
- 정식 구현체는 프로젝트의 방향을 통제하고, 대안 구현체는 그저 따라갈 수밖에 없음.
- 전통적으로 인터프리터 언어의 JIT 구현체를 만들 때, 인터프리터에 새로운 기능을 추가하는 게 훨씬 빠르기 때문에 정식 구현체가 JIT을 앞서나갈 수 있음.
YJIT: CRuby 내부에 Ruby JIT 컴파일러 구현
- YJIT은 또 다른 Ruby JIT이지만, CRuby 자체 내부에 구현하기로 선택함.
- 이를 통해 YJIT은 처음부터 모든 CRuby 기능과 100% 호환될 수 있었음.
- 지금은 Ruby의 공식 JIT이 되어 Shopify, Discourse, GitHub 등에 배포되고 있음.
더 넓은 관점에서의 교훈
- 기존 언어와 유사하지만 호환되지 않는 Crystal 언어도 제한적인 성공만 거둠.
- 기존 언어와 유사해 보이지만 호환되지 않는 것은 사람들을 혼란스럽게 할 뿐임.
- 새로운 프로그래밍 언어를 만들 때는 기존 언어의 하위 집합이 되려 하지 말고 자신만의 길을 가는 것이 좋음.
- 그래야 다른 구현체의 성능이나 기능, 라이브러리에 얽매이지 않고 자신만의 속도와 방향으로 진화시킬 수 있음.
GN⁺의 의견
- 해당 글에서 기술한 '대안 구현체 문제'는 프로그래밍 언어뿐 아니라 각종 소프트웨어 및 하드웨어 시스템을 만들 때 주의해야 할 사항임.
- 안정성과 호환성에만 신경 쓰다 보면 혁신이 어려워질 수 있음. 하지만 실제 사용자 관점에서 호환성은 매우 중요한 요소임. 신기술과 사용자 친화성의 균형을 맞추는 것이 중요함.
- 장기적인 관점에서 새로 만드는 프로젝트를 '누구와 호환되는가', '어떤 방향으로 진화시킬 것인가'를 충분히 고민할 필요가 있음.
- 새로운 프로그래밍 언어를 만들 때, 기존 언어의 문법만 비슷하게 하는 것은 혼란만 가중시킴. 오히려 자신만의 철학과 방향성을 뚜렷이 하는 것이 바람직함.
- 시장에서의 경쟁보다는 창의적이고 독창적인 솔루션을 내놓는 것이 장기적으로 성공할 가능성이 높아 보임.
Hacker News 의견
- 새로운 대안 구현을 개발할 때 기존 버전과 다른 아키텍처를 가지게 되면, 기존 버전에서 쉬운 것이 새 버전에서는 매우 어려울 수 있음. 예를 들어 proprietary 소프트웨어가 section 단위로 load/save하는 반면, 새 버전은 전체 문서를 메모리에 올리는 방식이라면 첨부파일 추가 기능을 지원하기 위해 새 버전의 전체 아키텍처를 수정해야 할 수 있음.
- 기존 구현의 대안으로 포지셔닝하는 것은 패배하는 명제임. "Python + X"라고 마케팅하는 프로젝트는 정식 버전과 경쟁하기 어려움. 그러나 MicroPython처럼 microcontroller용으로 설계되어 CPython과 경쟁하지 않고 다른 microcontroller 프로그래밍 환경과 경쟁한다면 성공할 수 있음.
- 호환성 주장과 달리 실제로는 오래된 언어 기능에 대해서도 호환성이 낮은 경우가 많아 대안 구현이 실패하는 이유가 됨. Ruby, Python의 경우 native C extension에 대한 지원 부족이 그 예시임.
- Startup 창업 경험에 따르면, 기본적인 기능 추구 대신 아키텍처가 기업용 기능을 지원할 수 있다는 것을 보여주고, 차별화된 무언가에 집중했어야 했음.
- 개발자들은 JIT보다 언어 기능과 상호운용성을 더 중요하게 여김. 기존 프로젝트에 기여하기보다 자신의 병렬 프로젝트를 만드는 것이 쉽지만, 누구를 위한 것인지 자문해 봐야 함. 자아도취에 빠지지 않도록 주의해야 함.
- Wrapper 코드는 표준에서 벗어나고 문서화가 부족해 고통을 야기함. 꼭 필요한 기능만 추가하고 기본값을 사용하는 것이 좋음.
- MySQL 호환성으로 인해 TiDB가 겪은 문제와 유사함. 이론적으로는 개방형 프로토콜이지만 실제로는 Chrome이 주도함.
- Kotlin에 대한 언급은 없었음.