<< Previous | Home | Next >>

나는 왜 Node의 세계에 남아 있는가?

레딧에 화자되고 있는 "Farewell Node.js(잘가 Nodejs)"와 이상욱님의 블로그에에서 번역한 글을 읽다가 Why I’m staying with Node(나는 왜 Node의 세계에 남아 있는가?)"라는 아티클이 눈에 뜨여 반대와 찬성의 글을 같이 곱씹어보면 좋을 것 같아서 Nodejs 옹호론자의 아티클을 번역해 봅니다.

무엇보다 먼저, Go 사용을 추천하면서 써내려간 획기적인 그의 뉴스와 Node.js에 대한 작별 인사를 한 TJ에게 경의를 표한다. 누구나 어떤 문제에 오랫동안 골머리를 앓는 사람들은 때가 되면 다른 것으로 이동해 간다. 그리고 그의 입장에선, 그것은 "일을 위한 올바른 도구"를 사용하는 것이었다.

좋다. 여러분은 Node.js를 좋아하지 않을수도 있다. 저 녀석은 매력적이면서 똑똑하다.

나에 대해서 말하자면, 아직 Node.js를 사용중에 있다. 여전히 우리는 우리의 앞에 거친 미래가 있을지라도, 나는 오래전부터 JavaScript에 배팅을 해왔고, 영어와 같은 것이라고 할까? JavaScript는 모든 곳에 있다.

물론 비유일지도 모르지만, TJ가 지적한 Node.js의 문제점은 우리들이 앉고 있었던 영어 문제와 비슷하다. 에러 처리 방식은 에러를 일으킬 가능성이 높고, 콜백은 동기식 트랜잭션보다 어렵다. 오류에 오류, 또 오류가 발생할 수 있다. 영어에서도 문법 실수는 항상 일어난다. 하지만, 대부분의 경우 서로 서로 모두 이해할 수 있고 실수를 고치는 방법도 알고 있다.

재미삼아 이야기해보면, JavaScript를 영어로한다면 Go는 하와이어가 되는 것이다,. 영어보다 심플하고, 작고, 효과적이고, 실수도 어렵고, 잘 알려지지 않았고, 자기만의 섬에 갖혀 있다고 말할 수 있다. 비슷한 관점에서 Java 독일어라고나 할까? 이제 이쯤에서 그만 하자.

비유는 제끼더라도 서로 흠집을 파고 들면서까지 Go vs Node를 비교하는 것보다는 Node.js를 계속 사용하려는데에는 몇가지 좋은 이유가 있다.

웹 애플리케이션
Node를 사용하면 시스템의 프런트 엔드와 백엔드의 코드를 그대로 공유해서 사용할 수 있다. 내가 만든 Change.orgOpenLikes, 그리고 당신이 지금 이 아티클을 읽고 있는 이 사이트처럼 Node 때문에, 유틸리티, 모델, 테스트 라이브러리, 심지어 라우팅 로직 조차도 공유할 수 있었다. 물론 유지보수 어플리케이션에 바람직하게 요구되는 프로그래밍의 원칙인 DRY 애플리케이션을 더 많이 만들수도 있다.

리쿠르팅
JavaScript의 대중적인 인기 덕분에 대부분의 사람들은 Javascript에 대해 조금이라도 알고 있다. Go를 사용할 수있는 사람을 채용한다면, 어디서 시작해야할 지 알수 없다. 이것은 개인적인 문제이지만, Node를 사용하고 있다면 쉽게 피할 수 있는 문제다. Node와 Go는 대체로 비슷한 역사를 가지고 있지만, JavaScript는 19세며,독립해 자립하고 있다. Node 경험이 전혀 없는 프로그래머도 몇년 동안 Javascript를 사용해서 안다면, 혼란없이 빨리 익힐 수 있다.

이번 주에 다른 팀에서 들어온 2명의 새로 입사한 직원이 4시간도 지나지 않아 코드베이스를 익히고, 첫 번째 커밋을 했다. 2011년이었다면 몇주 걸렸을 일을.(billwscott 트윗)


일을 위한 올바른 도구
뭐든지 상황에 따라 다르다. 높은 동시성이 요구되는 복잡한 지능 알고리즘을 필요하다면, Node 말고 다른것을 사용하는 것이 좋다. 나라면 Node에서 호출하는 방식의 서비스 같은 것을 할 것이다. Go와 Node 동시성과 속도를 비교하는 것은 for 루프를 앞으로 돌리거나 뒤로 돌려 어느 쪽이 더 성능이 좋은지를 비교 같은 것 같다. 이런 종류의 마이크로 벤치마크는 나에겐 설득력이 없다. 프로그래밍 언어, 프레임워크, 라이브러리를 선택할 때 항상 여러분 제품의 ROI를 고랴해야 하고, 사용자와 팀, 그리고 여러분 자신과의 사이에서 얼마나 효과적이었는지를 고려해야 한다.

교훈
여기선 긴 회고를 하고 싶지 않다. 그래서 TJ 조언과 비슷하지만, 자신의 울타리 바깥에는 매력적인 솔루션들이 많이 있다. 여러분 자신이 잘해나갈 방법을 선택하는 것이 중요하고, 결국에는 자신을 포함한 사용자나 기업을 행복하게 만드는 것이다.
Tags :

개발자와 나이

"It’s official : developers get better with age. And scarcer."이라는 아티클이 레딧에서 다시 회자되고 있어 소개합니다.

아티클의 내용은, StackOverflow에서 개발자들의 Q&A 데이터를 분석 한 것으로, 개발자수는 27세를 정점으로 그 후 6,7년마다 절반으로 그 수가 줄어들지만, 높은 평가를 얻게 된다는 것.

Q&A 사이트여서 그런지, “높은 평가”라는 질문에 좋은 답변을 많이 했다는 것으로 40대의 답변자가 20대의 두배 정도 많았다고 합니다.

그리고 분석 데이터에 의하면 답변의 질은 나이와는 큰 차이가 없고, 단지 고연령 개발자는 많은 질문에 대답하고 있기 때문에, 높은 평가를 얻고 있다고 결론을 내렸다네요.

저도 비슷한 생각이 있는게, 기술 커뮤니티나 페북 그룹, 뉴스그룹 등에서 연장자분들이 아니더라도 눈팅이 아닌 댓글을 통해 답변을 성심성의껏 다는분들이 계신데 그분들이 정말 내공자라 생각이 듭니다.

그냥 '왜'라고 묻는 것이 항상 최선의 전략은 아니다

좋은 제품을 만드는데 있어서 본질을 파고드는 데 좋은 사례가 바로 '왜?'라는 질문을 자신과 이해당사자들과의 토론에서 끊임없이 하는 것이다. 하지만 건성의 '왜'로 핵심을 파지않고 그저 내용의 이해만을 도울 수 있는 왜는 지양해야 된다는 좋은 아티클 'ASKING WHY IS NOT ALWAYS THE BEST STRATEGY'이 있어 내용을 요약해 봅니다.

제품을 만들 때 ‘왜’라는 질문을 반복하는 것은 본질적인 문제에 도달할 수 있는 좋은 방법이지만, HubSpot 제품 디자이너 Daniel Ritzenthaler는 맹목적인 ‘왜’를 반복하는 것은 오히려 생산적이지 않다고 한다.

제품에 좋은 가치를 부여하는 생산적인 ‘왜’를 묻는데에는 3가지 레이어를 인식할 필요가 있다.
  • 첫 번째는 편리성 레이어. 여기는 있는 이 기능을 사용하여 실제로 무엇을 하려고 하는지를 묻는 레이어.
  • 두 번째는 유용성 레이어. 여기는 있는 이 기능을 사용하면 어떤 결과를 얻을 수 있는지를 묻는 레이어.
  • 세 번째는 바람직함의 레이어. 이것이 목적을 달성 한 후에, 다른 것들과의 차별점이 무엇인지를 묻는 레이어.
이 3가지의 ‘왜’라는 레이어를 염두해서 제품을 생각한다면 시간과 결과물에서 좋은 가치를 심을 수 있다고 한다.

관점의 변화

  • 문제 해결형 (problem solving) ⇒ 문제 제기형 (problem finding)
  • 프로세스로서의 디자인 (design as process) ⇒ 중재 (수단)으로 디자인 (design as medium)
  • 답을 제공 (provides answers) ⇒ 의문을 제기 (ask questions)
  • 산업에 대한 봉사 (in the service of industry) ⇒ 사회에 대한 봉사 (in the service of society)
  • 현재 세계를 위해 (for how the world is) ⇒ 앞으로 가능한 세계를 위해 (for how the world could be)
  • 과학 소설 (science fiction) ⇒ 사회적 소설 (social fiction)
  • 미래 (futures) ⇒ 현실과 병행하여 존재하는 세계 (parallel worlds)
  • 적응 (applications) ⇒ 시사점 (implications)
  • 생산을 위한 디자인 (design for productions) ⇒ 토론을위한 디자인 (design for debate)
  • 컨셉 디자인 (concept design) ⇒ 개념적인 디자인 (conceptual design)
  • 소비자 (consumer) ⇒ 시민 (citizen)
  • 사용자 (user) ⇒ 사람 (person), (human)
  • 구입하기 (makes us buy) ⇒ 생각하기 (makes us think)

권위와 가치

Square의 CEO인 Jack Dorsey가 재미난 글을 올렸네요. 회사생활을 하면서 우리도 이런 비슷한 유혹을 많이 받게 되죠? 아래는 Jack Dorsey가 Medium에 올린 글입니다.

회사 생활을 하다보면 사람들이 아이디어를 제시할 때 권위있는 사람들을 이름을 빌려서(혹은 유명한 포스트나 뉴스 기사 등도 포함) 자신의 아이디어에 설득력을 보강하려한다는 것을 많이 발견하게 됩니다.

누군가의 이름을 빌려서 아이디어를 팔 때는 아래 두가지의 일이 일어난다네요.
  1. 당신의 권위가 떨어진다.
  2. 그 아이디어의 가치가 떨어진다.
간단하다: 당신이 이야기(의견이나 아이디어)의 논지를 남에게 설득시키기 위해서 타인의 이름과 권위를 이용한다면, 당신이 한 의견의 가치는 떨어진다.(당신 스스로가 이야기를 믿지 않고 있을 수도 있다) 당신이 정말 그 일이 옳다고 믿는다면, 스스로가 만들어서 그것을 증명하는데 초점을 맞추어야 한다. 권위는 가치를 제시할 때 나오는 것이지 타인의 권위를 등에 엎는 것으로 자신의 생각에 대한 가치가 부여되는 것은 아니다.

우리는 "John이 이렇게 하라고 해요. 이것이 우리의 방식이에요."라는 결론에 이르게하는 토론이 아니라, 우리가 당연하게 생각했던 것들을 다시 생각하고 대담하고 말도 안되는 아이디어에 대해 열정적으로 토론하기를 원한다. 후자의 방식이라면 Agile하고 혁신성을 유지할 수 있지만, 전자는 시대에 뒤떨어지게 된다.
Tags :

README가 대문자인 이유

README 파일은 해당 디렉토리나 아카입의 소프트웨어에 대한 정보를 기술하는 파일이다. 그런데 왜 대문자로 구성되어 있는지 확인해 보니...

위키에 그 사례가 실려져 있었다.

It is traditionally written in upper case so that on case-preserving environments using an ASCIIbetical ordering, the name will appear near the beginning of a directory listing (since upper-case letters sort before lower-case letters in ASCIIbetical ordering).

ASCII 코드 순으로 정렬되는 환경을 채택한 곳에서는 README 파일이 제일 앞에 보이게 하기 위해서 전통적으로 대문자를 쓰게 된다.
그래서 맥에서 LANG=C이나 LC_COLLATE=C 환경에서 ls -l를 실행해 보니,
$ ls -l
total 7656
-rw-r--r--   1 pepsi  staff    16317 Jul 23  2013 README.md
drwxr-xr-x  11 pepsi  staff      374 Jul 27  2013 bin
-rw-r--r--   1 pepsi  staff     1316 Jul 23  2013 build.xml

ASCII 문자 코드 순으로 README가 맨 먼저 보여지게 된다. 결국, README의 대문자 관습이 존재 의미를 더욱 부각시켜 주는 거 같다.
Tags :

왜 일이 예상대로 끝나지 않는가?

Why is not end as expected things?

1. 시간을 낭비하고 있는건 아닌지.
시간이 있을 때 그때 그때 스스로 찾아서 완결해 가야 하는데, 마감이 임박하지(빠듯하지) 않으면 동기 부여가 안된다. 초반에 느슨하게 하다가 막판에 불지르다가 일정과 품질에 악영향을 준다.

2. 인터럽트 되는 일을 우선시 한건 아닌지.
일을 하게 되면 항상 생기게 마련이 일의 집중도를 떨어뜨리는 인터럽트이다. 이것 때문에 지금 하는 일이 밀려나고 나중에 다시 시작할 땐 업무 전환 비용이 생긴다. 이럴 땐 장유유서, 상명하달의 문화가 큰 적이 된다.

3. 딜레이는 다른 딜레이를 낳는다.
하는 일을 완결하지 못하면 다음 일에도 영향이 생긴다. 여기엔 능력 부족이 큰 기여를 한다.

4. 완벽한 성과를 내려고 한다.
완벽한 성과를 내려면 준비 과정의 비중을 많이 두게 된다. 그리고 진행중에는 적당한 룰 없이 이리 재고 저리 재고하다보면 그러한 업무태도가 결국 시간을 먹는 하마가 된다.
Tags :