TJ Holowaychuck이 Node.js를 떠나며 지적한 Node.js의 문제들
원문은 이곳에서 읽을 수 있습니다.나는 항상 C를 사랑해왔지만 C로 무엇인가를 해본 사람은 그것이 가치를 하면서도 에러를 만들어 내기 쉽다는 것을 알고 있을 것이다. 빠르게 결과물을 만들어 낼 수 없다는 이유로 매일 사용하는 언어로는 부적합하다. 그 언어의 단순함에 대해서는 항상 내가 동경해왔던 바이지만 대량의 표준 구현들이 없이는 멀리 나아가기는 힘들다.
분산 시스템에 관련된 일을 더 하면 할 수록 나는 Node의 방향성에 대해 더 많이 좌절하게 되었다. 왜냐하면 그 방향성이 사용성과 견고함 보다는 항상 퍼포먼스에 방점을 두고 있기 때문이다. 최근 몇 주동안 나는 대규모 분산 시스템을 Go언어로 다시 개발하였고 그것이 견고하며 퍼포먼스도 뛰어나고 유지보수도 쉬우며 동기 코드들은 일반적으로 더 간결하고 뛰어나서 더 나은 테스트 커버리지를 갖고 있다는 것을 발견하였다.
나는 Go언어가 최후의 성배라는 것을 얘기하려는 것이 아니다. 그것은 완벽하지는 않지만 언어로써 지금 존재하는 것 중 나에게 최적의 솔루션 처럼 보인다는 이야기이다. 소위 말하는 다음 세대의 언어로 일컫는 Rust나 Julia가 자신의 자리를 찾아가고 성숙해짐에 따라 우리는 더 대단한 솔루션을 갖게 될 것임을 확신한다.
개인적으로 Go의 반복 속도에 대해 큰 흥미를 갖고 있다. 그리고 그것이 2.0버전을 향해 감에도 이미 뛰어난 것들을 포기하고 새로운 것을 시도하는데에 두려워하지 않는 다는 점에서 더욱 큰 흥미를 가지게 한다.
수정: 내가 이메일 리스트에서 뭔가를 잘 못 본거 같다. 그들은 곧 과거와 단절되는 변화에 대해 더이상 반가지 않을 것 같다. 이것이 진실이다 하더라도 나는 혁신적 변화가 언어의 발전에 도움이 된다면 그들이 마다하지 않을 것임을 믿기 때문에 Go 언어를 계속 사랑할것이다.
왜 Go 인가
Node가 당신의 요구 조건에 맞다면 Node는 여전히 훌륭한 툴이다. 그러나 만일 어떤 것이 당신의 신경을 거슬린다면 한번 주위에 다른 어떤 것이 있는지 돌아보기를 권한다. 프로덕션 환경에서 단지 몇시간 동안 Go를 써본것 만으로도 나는 Go에 낚여들고 말았다.다시 한번 말하지만 Go가 완벽한 언어라고 얘기하고 싶은 것은 아니다. 그러나 단지 그것의 역사에 비교하면 굉장히 성숙되어 있고 이미 견고한 언어이며 리팩토링은 단순하고 즐거우며 Go를 위한 툴들도 (프로파일링, 디버깅) 훌륭하다. 그리고 커뮤니티도 문서화와 포맷팅, 벤치마켕과 API 디자인에 관해 이미 정교한 규칙들을 가지고 있다.
처음에 Go를 접했을 때 Node의 극도의 모듈화에 익숙해져 있었고, Ruby의 끔찍한 stdlib의 대부분을 경험해본 나는 Go의 stdlib는 끔찍한 것이라고 생각했었다. 그러나 Go언어를 조금 더 심도있게 접근해보고 난 뒤 Go stdlib의 압축, json, IO, buffered IO, 문자열 조작등 라이브러리의 대부분은 현재 프로그램들의 정수를 잘 집어 낸 것임을 깨닫게 되었다. 이 API들은 잘 정의되어 있으면 굉장히 강력하다. 한 프로그램의 전체를 단지 stdlib으로만 만들 수 있을 정도다.
서드파티 Go 패키지
대부분의 Go 라이브러리는 굉장히 비슷하게 구성되어 있고 내가 지금껏 겪어보고 일해본 대부분의 서드 파티 코드는 굉장히 질적으로 우수하다. 이것은 유저들의 실력이 천차만별인 Javascript 코더들이 대부분이 Node의 세계와는 대비되는 일이다.Go 패키지들을 위한 중앙 저장소는 존재하지 않는다. 따라서 5개나 6개의 패키지들이 같은 이름을 갖고 있는것을 종종 발견하게 된다. 처음에는 이것이 매우 혼란스러울 수 있으나 흥미로운 부작용을 낳고 있다. 어떤 것이 괜찮은 것인지 알기 위해 하나씩 리뷰를 해보아야만 하는 것이다. Node의 세계에서는 표준 처럼 보이는 이름을 가진 패키지들이 있다. 가령 "redis", "mongodb-native", "zeromq" 같은 것들은 딱 보기에 표준 처럼 보이기 때문에 같은 기능을 하는 다른 패키지들을 찾기보다는 이것들이 최적의 솔루션이다라고 착각하고 이것들에 머물게 되며 더 나은 것들을 찾을 노력을 하지 않게 된다.
Go VS Node
만일 당신이 분산 처리 작업을 하고 있다면 Go의 동시성에 관련된 기본 요소들이 매우 설명적이라서 굉장히 편리함을 느낄 수 있을 것이다. 우리는 이와 비슷한 것들을 Node에서 제네레이터를 통해 성취할 수도 있지만 내 의견으로는 아직 갈길이 멀다고 생각한다. 스택 에러 핸들링과 리포팅을 분리하지 않고는 기껏해야 반쯤의 성공이 될 것이다. 그리고 우리가 지금 현재 잘 동작하는 솔루션을 가지고 있는데에도 불구하고 3년간 커뮤니티가 단편화되지 않도록 기다리고 싶지도 않다.Go의 에러 처리는 매우 뛰어나다고 생각한다. Node는 모든 에러 상황에 대해 생각을 해야 하고 어떻게 처리할지 결정해야 한다는 점에서 뛰어나지만 아래의 이유로 실패라고 생각한다.
- 중복된 콜백을 받을 수 있다.
- 콜백을 전혀 받지 못할 수도 있다.
- out-of-band 에러를 받을 수도 있다.
- emitter가 다수의 에러 이벤트를 뿜어낼 수도 있다.
- 에러 이벤트를 잃게 되는 경우 모든 것을 망가지게 만든다.
- 에러 핸들러가 무엇을 해야할지 확실치 않은 경우가 많다.
- 에러 핸들러는 매우 장황하다.
- 콜백 자체가 별로다.
노드의 미래
난 여전히 노드가 잘 되길 기원한다. 수 많은 사람들이 많은 시간을 투자를 했고 그것이 잠재력도 있다고 생각한다. Joyent와 팀은 Node의 사용성에 더 많은 투자를 하기를 원한다. 왜냐하면 해당 언어로 개발된 어플리케이션이 취약하고 디버깅이 힘들고 리팩토링 개발이 힘들다면 퍼포먼스는 의미가 없다고 생각하기 때문이다.4~5년 동안 여전히 “Error: getaddrinfo EADDRINFO” 같은 알아보기도 힘든 에러가 지속되고 있는 점은 어디에 우선순위가 있었는지를 반증한다. 물론 시스템의 코어에만 집중하고 있었다면 이러한 것 쯤은 간과할 수 있음을 이해는 하지만 유저들은 이런한 것들에 대해 수차례 이야기를 해왔지만 어떤 결과로도 이어지지 않았다.
스트림은 잘 동작하지 않고 콜백은 별로 좋은 방법이 아니며, 에러는 모호하다. 툴 들도 여전히 별로며 커뮤니티 규칙도 있기는 있는것 같은데 Go 커뮤니티의 그것에 비하면 부족하다. 그럼에대 불구하고 웹사이트를 개발하는 것 같은 분야에는 노드를 계속 사용할 것 같다. Node가 기본적인 문제들을 해결한다면 여전히 관련되어 있을 것 같지만 그러나 사용성에 앞서 퍼포먼스를 강조하는 것으로는 일이 해결될것 같지 않다. 특히나 다른 솔루션은 퍼포먼스와 사용성 두가지 토끼를 모두 잡고 있는 마당에 말이다.
노드 커뮤니티가 제네레이터를 포용하고 Node의 코어로 적극 구현하여 에러 전달을 아주 잘 할 수 있다면 에러 처리에 관한 분야에서는 비교가 될 수 있을 것이다. 그리고 이것은 극적으로 Node의 사용성과 견고함을 향상 시킬것이다.
한가지 좋은 소식은 오랫 동안 Node의 코어에 기여한 StrongLoop의 멋진 사람들과 얘기를 했었는데, 그들은 정말로 개발자들의 플랫폼에 대한 피드백에 대한 이야기를 듣고 올바른 방향성을 가지고 현재의 이슈들을 해결할 방향과 계획을 세워서 미래에는 더 즐겁게 사용할 수 있는 Node버전을 만들겠다고 한다. 그러나 Node 코어에 관련한 일을 하고 있는 몇개의 회사들 사이의 논쟁이 어떻게 끝날지는 모르겠지만 개발자들이 이끄는 방향이 결국엔 승리할 것이라고 생각한다.
지금까지 말한 것들은 Node와 함께 일하는 정말로 능력있는 그 누구를 비방하려고 하는 것은 아니지만 이제 Node에 대한 관심은 없다. 커뮤니티의 일원으로써 많은 멋진 사람들을 만났고 좋은 시간들을 보냈다.
결국 내가 하고 싶었던 이야기는 절대 당신이 파놓은 우물속에만 갇혀있지 말고 주위에 뭐가 있는지 둘러보라는 이야기이다. 멋진 솔루션들이 도처에 존재하니깐 말이다.
No comments:
Post a Comment