»
S
I
D
E
B
A
R
«
Rational Team Concert 적용 실패 – 원인 분석
Jul 15th, 2011 by Wegra Lee

지난번 글(새로운 툴을 대하는 자세)에서도 언급했듯, 나는 조직에 많은 툴들을 전파해보았다(혹은 전파하려 하였다). 그 중 규모면에서나 영향력면에서나 가장 큰 툴은 바로 Rational Team Concert (RTC) 일 것이다. 내가 접해본 툴들 중 가장 마음에 드는 툴이기도 하다. 그런 이유로 수년간에 걸쳐, 다양한 방법으로 팀원들을 끌어들이려 노력해보고, 한 때 좋은 분위기로 흘러가기도 했지만.. 현 시점에서 결론을 내려보면 ‘완전 실패’다. 자.. 이제부터 내가 느낀 실패 원인을 살짝 정리해보겠다.

자잘한 원인들을 모두 나열하자면 한도 끝도 없을테고 초점도 흐려질듯하니 생략하고, 내가 생각하는 가장 근본적인 원인만 다루려 한다. 바로 (주로 유교의 영향이 컸을 듯한) ‘수직적 문화’이다.

우리 문화는 서열을 중시한다. 조직에서의 서열은 이렇게 매겨진다.

  • 주인 >> 직급 >> 연차 > 나이 > 능력

이 서열을 뛰어넘기란 여간 어려운 게 아니다. 아무리 능력이 좋아도 직급이 더 높은 사람을 부릴 수 없으며, 심지어 같은 직급과 같은 연차라도 나이가 한 살이라도 더 많은 사람을 밑에 두기란 쉽지 않다. 여러 가지 예가 있다.

  • 과제가 잘 되어 팀 규모가 커지면, (팀원을 승진시키기보다) 규모에 어울리는 높은 직급의 사람들이 합류한다. 팀을 이끌던 원조 맴버들 대부분은 새로 들어온 높은 분들 밑으로 들어가서, 기존보다 작은 역할을 맡는다.
  • 적은 나이와 연차에도 능력을 인정받아 상대적으로 큰 규모의 팀을 이끄는 자가 있다면, 그의 팀은 다른 팀보다 젊은 사람들도 구성되어 있다.

특히 직급은 우리 조직 시스템에서 너무도 중요한 축을 담당한다. 말단 사원을 제외하고는 모든 사람들을 호칭할 때 직급을 붙여준다. 대부분은 때되면 붙여주는 직급이지만, 이를 생략하고 불렀다간 관계가 소원해질 것을 각오해야 한다. ^^;

굳이 회사에서만 예를 찾으려할 필요도 없다.

  • 바른 논리를 가지고 있더라도, 나이 많은 이에게 목소리를 높이면 버릇없다는 평을 듣기 십상이다.
  • 그룹 활동을 하는 연애인들의 리더는 십중팔구 나이가 가장 많거나, 동갑일 경우엔 생일이 가장 빠른 사람이다. 누가 막내인지 알리는 것도 빼놓지 않는다.
  • 운동 선수들 간의 엄격한 선후배 관계도 잘 알려져 있다.
  • (반대 급부로 생긴 말이지만) ‘나이 먹은게 벼슬이냐?’ ‘나이가 벼슬이다’와 같은 말이 심심찮게 쓰이는 것은 나이가그 사람의 상대적 위치를 결정짓는데 적지 않은 영향을 미침을 반증하고 있다.

불행히도 이런 문화는 우리가 쓰는 언어에 의해 아주 어렸을 때부터, 거의 언어를 배우기 시작하면서부터 주입된다. 한 살이라도 많으면 형, 누나, 오빠, 언니가 되고 그들에게는 말을 높이라고 교육받는다. 윗사람을 공경하는 문화야 칭송되기도 하고, 그리 나쁘지는 않은 문화라 생각한다. 다만 아쉬운 것은 단순히 나이 많은 이에 대한 어휘와, 정말 존경이나 높은 사람에 대한 예우로써 쓰는 어휘에 차이가 없다는 점이다. 즉, 우리는 존경과 나이 많음을 명확하게 구분짓지 않기 때문에 알게모르게 이 둘을 동일시 시킨다. 언어가 인간의 사고를 지배하기 때문이다. 초등학생만 되어도 선배는 후배에게 일을 시키고, 후배는 선배의 명령을 따르는 것이 몸에 익어버린다. 갑으로써 누릴 수 있는 힘과 을로써의 자세를 사회 관계를 처음 쌓게 되면서부터 체득하게 된다. 그리고 성인이 될 때까지 단 한 번도 이에서 벗어난 문화를 경험하지 못하고 성장한다. (채벌에 관대하게 된 데에도 많은 영향을 미쳤으리라 믿는다.)

이렇게 우리는 협동과 협업보다는 명령 하달과 수행 체제에 적합하게 훈련되었다. 평등한 관계 속에서 협업이 중시되는 사회에서는 뛰어난 리더가 중심이 되지만, 명령과 수행에 의해 움직이는 사회에서는 냉철한 관리자가 더 중요해진다.

이쯤에서 RTC를 잠시 살펴보자. 툴에는 툴 설계자의 노하우와 철학이 담겨있다.그럼  RTC 설계를 주도한  에릭 감마는 어떤 생각을 가지고 이 툴을 만들었을까.  이런저런 이야기를 하고 있지만, 핵심은 효율적인 협업투명성이다. 관리와 통제가 아닌 것이다.

우리 사회도 물론 협업과 투명성을 강조하지만, 평등한 관계에서의 협업/투명성과 수직적 관계에서의 그 의미는 완전히 달라진다. 후자에서의 협업은 같은 등급의 사람들끼리 잘 협동하고, 높은 사람의 말을 잘 따르는 것이다. 투명성은 높은 위치의 사람이 낮은 위치의 사람이 땡땡이 치지 못하게 잘 감시할 수 있는 일방적인 하향 투명성을 뜻한다. 협업은 그렇다 쳐도.. 투명성에 대해서는 실무자쪽에서 더욱 방어적으로 나오는 이유가 되기도 한다. 갑은 을을 마음대로 부릴 수 있음을 어려서부터 익히 배워왔기 때문에, 을은 갑으로부터 최대한 자신을 보호하고 싶어한다. 상향 투명성은 생각하기도 힘들고, 동급의 실무자들간 투명성도 그리 환영받지 못한다. 아랫 사람은 위에서 내린 명령만 잘 수행하면 되는 것이고, 그것이 어떻게 조합되어 전체를 만드는지는 윗사람이 생각할 문제이다. 또한 피지배 계층이 너무 많은 정보를 가지고 있다면 지배하기기 쉽지 않다. 과거 평민 이하에겐 교육을 시키지 않은 이유와 같다. 예를 들어, 지금까지의 과제 진척률이 고스란히 공개된다면 단순 채찍질용 일정 단축 요청 같은 것은 의도한 효과를 발휘하기 어렵다.

몇 년 전, 우리의 행태를 비판하며 프로젝트 투명성에 대한 생각도 끄적여 봤었지만, 하루 아침에 변화시키엔 수직적 문화의 뿌리는 우리 사회에 너무 깊게까지 내려 있다. 나이 차이가 수십년 이상 되는 사람들이 모여 있는 거대 조직에서는 말도 안되는 이상향일 지도 모르겠다.

이런 이질적인 동서양 문화에서 파생되는 또 하나의 심각한 문제는 바로 실무자로써의 생명이 짧다는 점이다.

일반적으로 사원으로 입사했다면 8년쯤 후, 박사로 입사했다면 거의 곧바로 관리자의 역할을 맡게된다. 편차가 심하긴 하지만 평균은 대략 이와 비슷할 것이다. 심지어 대규모 플랫폼을 개발하는 팀에서조차, 능력있는 고참 실무자를 아키텍트로 키워보려 면담을 해보면 ‘저도 이제 관리를 익혀야지요’하는 반응이 많다는 이야기도 들었다.

그런데 이것이 수직적 문화와 무슨 관련이 있단 말인가? 계급이 다르다는 것은 (암묵적으로) 하는 일이 다르다는 뜻이다. 승진을 했음에도 하는 일은 과거와 똑같다면 스스로도 실망스럽고, 주변의 위로 소리가 어색하지 않게 느껴진다. 실무 능력이 아무리 뛰어나도 관리 능력이 미달되면 그는 우리 사회에서 도태되기 쉽다.

이와 달리, 수평적 사회에서는 하는 일의 차이보다는 능력의 차이가 보다 중시된다. 조직을 이끄는데 있어 관리는 물론 중요하지만, 직급이 높으면 관리를 해야한다는 인식보다는 개개인이 가장 잘 할 수 있는 일을 하는 것이 올바르다 생각한다. 관리는 직급의 구분 기준보다는 역할이 다른 것으로 인식된다.

그래서 다시.. RTC와 무슨 상관인가? 관리자 입장에서 생각해보자.

  • 현 상황을 보려면 Eclipse를 깔고 매번 실행해야 한다고? 개발도 안하는데 그 무거운 툴을 내 느린 노트북에서 실행하라니..
  • 소스 컨트롤? 빌드 상태? 그런 건 알아서 풀고, 정 문제가 되면 개선안과 함께 보고해.
  • 이슈? 버그 현황? 한 페이지로 깔끔히 정리해와.
  • 수하 직원에게 업무를 할당하는데 직접 툴에 입력하라니? 말로 시키면 알아서 잘 처리하고 결과만 제때 보고하면 되지.

기타 등등.. 관리자 입장에서는 전문 개발 툴에 통합된 RTC의 인터페이는 불필요한 기능들로 가득차있고 복잡하고 무겁다. 관리를 잘 하기 위해서는, 스스로 툴을 조작하며 이러저런 상세 정보 속에서 헤매이기보다는, 핵심 정보들만 빨리 캐취해서 적시에 올바른 의사 결정을 내리는 것이 훨씬 중요하다. 즉, RTC는 이런 문화에 속한 관리자를 위한 툴이 아니다.

그렇다면 개발자에게는 좋은가..

  • RTC에 열심히 자료를 축적해 놓아도, 상사는 항상 자신이 보고픈 것만 나오는 별도 자료를 요구한다. 어차피 보고 자료 따로 만들 거, 굳이 중복 작업 할 필요 있나!
  • 내게 할당된 일과 그 진척 상황이 거의 실시간으로 공개되니 감시받는 기분이 든다.
  • 요구사항은 별도 문서로.. 일정 관리도 마찬가지. 테스트는 다른 팀에서. 다 빼고나면 내가 쓸 건 소스 컨트롤과 빌드뿐인데.. 그 정도는 오픈 소스 공짜툴 중에도 좋은게 널리고 널렸지. 이왕이면 다른 회사로 옮기거나 집에서 혼자 쓸 때도 그대로 사용할 수 있는 오픈 소스 툴들을 써보는게 좋지 않을까?

이렇듯, 개발자 입장에서도 그리 매력적이라 보기는 힘들다는 생각에 이르렀다. 결국 우리 사회 구성원 누구에게도 딱 맞지 않은.. 먼 나라의 툴이 되어버린 것이다.

물론 우리 사회도 조금씩 변해가고 있다. 요즘의 젊은 벤쳐 기업이나 열린 마음의 사람들로 구성된 작은 팀에서는 RTC가 진정한 힘을 발휘하기에 충분한 문화를 만들 수도 있을 것이다. 그리고 점점 더 상황은 나아질 것이라 믿어 의심치 않는다. 하지만 똑같은 수준에서, 몇 년 내에 급격한 개선이 있을 것이라고는 절대 생각하지 않는다. 조직 문화를 성공적으로 혁신시키려면, 조직 구성원들 대부분이 그 필요성을 마음속 깊이 공유한 상태여야 한다. 그렇지 못한 상태에서 무리하게 추진한다면  모난 돌 취급을 받게 되거나, (추진자가 높은 사람이라면) 마지못해 하는 척만 하다가 머지 않아 원상복귀된다. 혹은 형식만 남아 안함만 못한 상태가 되어버린다.

RTC와 같이 프로젝트 개발 과정 전반을 아루르며 팀 구성원 모두가 써야하는 툴을 온전히 도입하는 것은, 팀 문화 전반을 바꾸려는 시도와 같다. 개인적으로 마음에 들더라도, 팀 차원에서의 적용을 시도하려면 분위기와 팀원들의 성향을 잘 판단해서 추진하기 바란다. 우리팀은 지금 50명 이상이 RTC를 사용하는 듯 싶지만, 에릭 감마가 의도한  방식대로 사용하는 사람도 거의 없을 뿐더러, 관리자쯤 되면 쓰는 사람을 손에 뽑고, 매뉴얼/검색/옆사람을 통해 쉽게 해결할 수 있는 사소한 것들로도 수시로 (전파자인) 나를 찾아 귀찮게 하는 상황이다. ^^;;

가볍게 소개해보고 분위기를 살펴보는 것으로 시작하는 것은 나쁘지 않은 방법일 것이다. 단, 몇 마디 긍정적인 피드백만으로 너무 쉽게 총대를 둘러매진 말길 바란다. ^^

(updated: 내가 이런 글을 적은 이유 중 하나는, 이런 문화적 차이를 미리 알고 충분히 고려해서 적용을 시도해보는 것과, 무턱대고 밀어붙이는 것에는 분명 큰 차이가 있을 거라 믿기 때문이다. 뭐든 내맘에 든다고 다른 사람 맘에도 들거란 생각은 위험하지만, 만약 이 툴이 정말 마음에 든다면, 당신은 주변 사람들과는 다른 사상을 가지고 있을 확률이 많을 것이다. ^^ 실패하더라도 남 탓하지 말고, 사회 탓도 하지 말기 바란다. 이 시스템은 또 이 시스템 만의 장점이 있다. 적응을 해보던지, 정 맞지 않다면 일찌감치 다른 조직을 찾아 모험을 떠나보는 것도..^^)

새로운 툴을 대하는 자세
Sep 27th, 2010 by Wegra Lee

회사 생활을 하면서 나는 참 많은 툴들을 팀에 전파하려 노력하였고 또 전파한 편이다. 테스트 자동화, 분산 컴파일, 테스트 커버리지 측정, 프로파일링, 정적 코드 분석, 컨티뉴어스 빌드, 애플리케이션 라이프 사이클 관리 등 그 분야도 소프트웨어 개발 전반에 걸쳐있다.

매번 새로운 툴을 도입하려 할 때마다 사람들의 반응은 제각각이다. 툴이 제공하는 기능 리스트(무엇을 할 수 있다)만 보는 사람, 자신에게 당장 필요한 핵심 기능 몇 가지에만 관심을 갖는 사람, 이전에 사용해본 유사한 툴과 똑같은 취급하는 사람 등 많은 부류가 있다. 하지만 아쉬운 점은 정작 그 툴의 진정한 가치에 관심을 보이는 사람은 찾기 힘들다는 점이었다.

좋은 툴들엔 그 툴이 현재의 모습을 갖추기까지 거친 수많은 시행 착오로부터 얻어진 노하우와 설계자의 철학이 담겨 있다. 고객들로부터 받은 엄청난 양의 피드백 역시 툴의 기능과 동작 방식에 지대한 영향을 미친다.

툴을 제대로 익힌다는 것은 이러한 경험과 노하우를 함께 습득한다는 의미를 갖는다.

툴 제작자들은 고객이 별다른 교육 없이도 최대한 쉽게 사용하게 만들기 위해 많은 노력을 기울이지만, 여기엔 분명한 한계가 있다. 아무것도 없는 야구공 하나도 잘 던지라면 제대로 쥐는법부터 시작해 많은 학습과 연습이 필요하다. 하물며 복잡한 소프트웨어 개발을 위해 수많은 사람들이 함께 사용해야할 툴이라면 오죽하랴.

툴을 제대로 활용할 줄 모르는 사람에게는 어떤 툴을 제공하건 생산성에 큰 변화가 없다. 이들은 대부분 기본적인 기능만 사용하게 되는데, 기본 기능만 놓고 본다면 이름 있는 유사 툴들 사이에 큰 차이를 찾아보긴 어렵기 때문이다. 병목 현상이 발생하던 부분에서 성능이 대폭 개선되는 경우(분산 컴파일, 저장소 프락시 등)나, 개발자가 할 일을 대신해주는 경우(자동 빌드, 정적 코드 분석)와 같이 한정된 상황에서만 그나마 효과를 얻게 된다.

여기까지는 양호한 편이다. 심한 경우 툴이 만들어진 의도와 다르게 활용되는 경우도 많다. 툴의 설계자는 일반적인 사람들의 잘못된 습관을 바로잡기 위해 기능과 인터페이스를 설계했는데, 바로 그 잘못된 습관대로 일을 진행하면서 오히려 툴이 잘 맞지 않는다고 불만을 토로하기도 한다. 방법을 바꾸면 더 큰 효과를 얻을 수 있음에도, 왜 툴이 내 마음과 맞지 않는지는 깊게 생각하지 않는다.

이전보다 훨씬 다양하고 강력한 기능을 갖춘 툴을 보여줘도, 기존에 사용해본 유사 툴의 틀에 갖혀 장점을 보지 못하는 경우도 많다. ‘이 툴은 이런 거야’라고 일찌감치 단정짓고 더 이상 파고들려 하지 않는다.

이러한 태도를 버리지 못한다면 새로운 툴 도입이란 똑같은 일을 하기 위한 방법을 하나 더 익히는 것 이상도 이하도 아니게 된다. 결국 아무리 좋은 툴이 새로 나오더라도 도입에 보수적이게 되는 원인 중 하나가 된다.

팀원 전체가 그렇지는 못하다면, 개인적으로라도 툴에 녹아있는 사상을 공부하고, 제대로된 활용법을 익히려 노력해보자.

과거의 유사 툴이나 시장의 경쟁 툴들과 어떻게 다른지, 왜 다른지 파헤쳐보라. 같은 일이라도 다양한 접근법이 존재함을 배우고, 각각의 장단점을 깨달아 내가 처한 상황에서 최선의 방법을 찾을 수 있는 눈을 갖게 될 것이다.

내가 생각한 것과 다르게 동작한다면 왜 그렇게 만들었졌지 알아보라. 내가 하던 방식에서 많은 문제점을 발견하고 더 나은 방식을 배우는 계기가 될 것이다.

설계자가 그 툴을 만든 목적과 배경은 무엇인지, 어디에 주안점을 두었는지 알아보라. 내가 속한 팀, 나의 환경이 그들이 해결하고자 하던 문제를 그대로 앉고 있는가? 그렇다면 툴 도입이 해당 문제에 대한 확실한 해결책이 되도록 노력해보자. 문제를 인식/공유하고 툴 도입의 목적을 명확히 하자. 그리고 툴을 제대로 활용하고 있는지, 문제는 잘 개선되고 있는지 정기적으로 평가해보자.

툴 제작자가 권장하는 활용 방법(Best Practice)은 절대 빼먹어서는 안된다. 가이드라인을 잘 숙지하고 최대한 맞춰보려 노력해보자. 충분히 익숙해진다면 내가 생각하는 방식이 곧 툴이 동작하는 방식이 된다. 머리 따로 몸 따로 움직이던 시절을 떠올리며 여유 가득한 미소를 짓게될 것이다.

이러한 과정을 거치면서 툴 도입 효과가 극대화됨은 물론, 자신의 역량도 함께 성장한다. 제대로 활용할 줄 아는 툴이 많은 것은 좋은 개발자가 갖춰야할 덕목 중 하나이기도 하다.

쉬어가기.. 혁신을 이끌어내는 방법
Jan 11th, 2010 by Wegra Lee

우리는 창의력과 혁신을 강조하는 시대에 살고 있다. 소프트웨어 개발도 당연히 그 중심에 서 있다. 하지만 우리의 소프트웨어 개발 문화는 창의력을 심히 제한하는 방식으로 굳어져 있다.

일반적으로 우수한 편에 속하는 지적 능력을 가지고 있고, 새로운 것을 만들어내는 것을 즐기는 소프트웨어 개발자들. 그들은 회사에서 어떤 대우를 받고 있나. 조직이 조금만 커져도 기획은 별도의 부서에서 진행하고, 소프트웨어 개발은 몇몇 관리자들이 이끌게 된다. 소프트웨어 개발자들은 창의력을 발휘하기 보다는 시키는 일만 열심히 해야 하는 위치에 놓이게 된다. 코드를 찍어내고 타의에의해 변경된 요구사항들 때문에 수정/테스트를 반복하는 나날을 보내며 발언권은 점점 작아진다.

기술 개발을 중시하는 몇몇 소수 기업을 제외하고는 대부분(대기업)의 윗사람들은 아직까지 소프트웨어 개발자들을 단순 노동자 취급하고 있다. 이를 빗대어 나는 ‘소프트웨어 제조업’ 에 종사하고 있다고 얘기하곤 한다.

반면, 개발자들의 능력을 믿고 그들에게 스스로 혁신을 일으킬 수 있도록 지원해주는 대표적인 기업들로 Google, Apple, Rally Software 등을 들 수 있다.

Google 은 20% 제도로 유명하다[1]. 자신에게 주어진 시간 중 20% 정도를 주업무가 아닌 다른 일에 할애하도록 권장하는 제도로, 다양한 형태로 응용 가능하다. 매일매일 20%의 시간을 다른 일에 투자하는 것은 대부분의 경우는 현실적이지 않다. 프로젝트 마감이 코앞인데 다른 일에 정신 팔기도 힘들고, 하루 1~2시간씩 해서는 진도도 나가지 않기 때문이다. 대신 그들은 1주일에 하루, 1달에 1주, 혹은 6개월에 1달, workaholic 이라면 주말을 이용 등등.. 자유롭게 변형해서 일한다. 과제가 바쁠때는 열심히 그 일에 매달렸다가 한가할 타임에 그동안 못 쓴 20%를 쓰는 식이다.

20%의 시간에는 어떤 일을 할까? 이것도 아주 자유롭다. 전혀 새로운 과제를 수행할 수도 있고, 관심있는 다른 팀 과제를 지원할 수도 있고, 자신의 주 과제를 진행하면서 불편했던 부분을 자동화하거나 유용한 유틸리티를 만들거나, 최적화/리펙토링을 할 수도 있고, gmail/chrome browser 등에 유용한 플러그인을 만들어넣을 수도 있다. 공부를 할 수도 있다.

이렇게 해서 나온 결과들은 팀의 개발 생산성을 향상시키고, 제품의 품질을 좋게하고, 새로운 것을 배우게 만들고, 운이 좋으면 구글의 미래를 이끌어갈 제품으로 거듭날 수도 있다. Gmail, Google News, Google Talk, Orkut, Google Sky [2], Go programming language [3] 등은 모두 20% 시간에 시작된 프로젝트들이다.

Apple 의 경우 1년에 1달 가량 자신이 원하는 일을 할 수 있게 해준다지만.. 자세한 내용은 잘 알려지지 않았다[4].

마지막으로 Rally 의 경우 8주의 개발 사이클 중 마지막 1주는 회사의 미션과 관련된 일이라면 어떤 것이든 할 수 있는 권한이 주어진다[5]. 기간이 일정하게 주어져 있기 때문에 융통성이 조금 부족하지 않을까 우려되긴 하지만 한 숨을 돌리며 자신들의 과거를 뒤돌아볼 수 있다는 점만으로도 확실한 장점이 될 것이다.

다시 암울한 우리의 이야기로 돌아와보자.

나는 현 회사의 윗사람으로부터 ‘관지자가 할 일은 개발자가 놀지 않게 하는 것’ 이란 얘기를 들었다. 여기서 논다는 것은 ‘주업무와 직접적으로 관련 없는 모든 일’을 지칭한다. 내게는 ‘공장 가동을 멈추지 말 것’ 정도로 들렸다. 공식적인 주업무 외에는 회사에 기여하지 못하는 것으로 여겨기기 때문에 일거리를 만들어서라도 주지 않으면 능력 없는 관리자가 되는 것이다.

개발자 입장에서도 마찬가지다. 좋은 아이디어가 있더라도 side job 은 업적으로 인정받기 어렵다. 놀고 있는 것으로 받아들여지므로 드러내놓고 할 수도 없다. 결국 몰래 하거나 개인 시간을 희생해서 짬짬이 하게 되고, 인정받지 못하기 때문에 의욕이 생길리 만무하다.

고급 인력인 개발자들의 좋은 두뇌를 활용하지 못하고, 반대로 창의성을 저하시키는 이런 문화는 하루 빨리 고쳐져야 한다. 말로만 소프트웨어가 중요하다고 하지 말고, 소프트웨어 개발의 특성과 개발자들을 이해하려는 노력이 절실하다.

두서 없지만 이 글은 이쯤에서 마무리하기로 하고, 유사 주제로 작성하고 있는 글이 있으니 그 쪽에서 정리를 시도해보기로 하겠다. ^^


References

  1. Pros and Cons of Google’s 20 percent time concept? (Ask MetaFilter)
  2. Top 20 Percent Projects at Google (eWeek.com)
  3. The Go Programming Language (Google, golang.org)
  4. 애플 “한국을 모바일 테스트베드로 활용” (아시아 경제)
  5. Principles of Agile Architecture (wegra.org)
»  Substance: WordPress   »  Style: Ahren Ahimsa