Jolt Awards 2011

댓글 달기 / Book, Software Development / /

Excellence Award는 Continuous Delivery, Productivity Award는 Seven Languages in Seven Weeks와 Mining the Social Web이 수상했다. 이들 Top 3 이외에 당장 관심이 가는 책은 Martin Fowler의 DSL 책, Scalability Rules 정도.

The Best Books

http://drdobbs.com/joltawards/231500080

  • Domain-Specific Languages, by Martin Fowler
  • The Art of Computer Programming, Volume 4A: Combinatorial Algorithms, Part 1, by Donald E. Knuth
  • The Joy of Clojure: Thinking the Clojure Way, by Michael Fogus and Chris Houser
  • Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages, by Bruce A. Tate
  • Mining the Social Web: Analyzing Data from Facebook, Twitter, LinkedIn, and Other Social Media Sites, by Matthew A. Russell
  • Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, by Jez Humble and David Farley

The Rest of the Best

http://drdobbs.com/joltawards/231600815

  • Arduino Cookbook
  • CLR via C#, 3rd Edition
  • Data Analysis with Open Source Tools
  • Eloquent Ruby
  • High Performance JavaScript
  • Scalability Rules: 50 Principles for Scaling Web Sites
  • The Software IP Detective’s Handbook: Measurement, Comparison, and Infringement Detection
  • The Rails 3 Way
  • The RSpec Book: Behavior Driven Development with Rspec, Cucumber, and Friends

Jolt Awards 2011 더 읽기"

NoSQL @ Netflix

댓글 달기 / Software Development / /

http://www.infoq.com/presentations/NoSQL-Netflix

지난 7월 QCon 발표. 이 발표자는 굉장히 여러 군데서 동일한 내용으로 발표한 모양인데도 불구하고, 실은 썩 마음에 드는 발표는 아니었지만, 실제 엔지니어링 경험이 뼈저리게 느껴져서 인상 깊게 보았던 발표다.

Netflix’s Cloud Transition

2008년 말, Netflix는 하나의 데이터센터를 가지고 있었고, SPOF와 cooling, power, space, traffic capacity 문제에 봉착하고 있었다. (문맥상 그야말로 데이터센터를 ‘보유’하고 있었던 것으로 보이는데, 미국의 경우 이러한 방식이 일반적인 방식인 것인지, 그리고, SPOF가 중요한 문제가 될 만큼 데이터센터의 신뢰성이 문제가 되는 수준인지 궁금하다.) 그리고, 놀랍게도 outsourcing을 통해,  당시 IaaS 플랫폼으로서는 leader 격이었던 AWS를 통해 해결하기로 결정한다.

Netflix의 cloud migration에서 중요한 점 중 하나는 가장 중요한 사용자 개인 정보 (PII), 결제 정보 (PCI DSS)는 그들의 데이터센터에 남겨놓고, 나머지 – 비디오의 메타데이터, 리뷰, 사용자의 비디오 큐, 시청 기록, 평점, 로그 등 만을 cloud로 이동했다는 점이다.

AWS로 가면서 자연스럽게 선택하게 된 storage는 바로 Simple DB와 S3인데, Simple DB는 RDBMS의 대체, S3는 Simple DB의 item 크기 제약을 넘어서고, single key로만 액세스하는 데이터를 저장하는데 사용한다. 그러다 Simple DB의 데이터 모델 제약이라든지, Scalability concern등의 문제들을 넘어서기 위해서 Cassandra도 사용하게 되었다고 한다. 이 발표에는 등장하지 않았지만 M-R과의 조합이 필요한 곳에는 Bigtable도 사용하는 것으로 보인다.

이 발표에서는 Simple DB와 Cassandra를 간략하게 소개하고, Simple DB를 실제로 적용할 때 겪었던 문제들을 정리하고, Cassandra 에서 이러한 문제들이 많이 해결되었다고 얘기하고 있다.

Problems in transition from RDBMS to Key-Value Data Store

당연하지만, RDMS에 있을 때 편하게 썼던 기능들이 필요해지면 application layer에서 알아서 구현해야 한다.

  • partial or no sql support
    • joins이나 group by가 없기 때문에 application layer에서 구현
  • no relations between domains
    • application layer에서 구현.
  • no transaction
    • simple db에서는 conditional put/delete op이 존재하기 때문에 이를 이용해 optimistic locking
    • cassandra에서는 batch mutate op 이용
  • no schema
    • attribute 이름 등에서 misspelling이 발생할 경우 silent하게 실패.
    • 공통 data access layer에서 validation
  • no sequences
    • primary key를 위해서는 자연스럽게 발생하는 unique key나 그러한 경우가 아닐 때는 UUID 사용
    • ordering을 위해서는 distributed sequence generator (using zookeeper)나 client timestamps 사용
  • no constraints (uniqueness, foreign key, referential , integrity)
    • application layer에서 구현

Workaround Issues in SimpleDB

SimpleDB의 설계나 구현이 아직 충분히 성숙되지 않았음을 엿볼 수 있기도 하고, 어떤 측면에서는 다른 DBMS에서도 충분히 겪을 수 있는 문제이나, 충분한 사용 경험이 없기 때문에 해결에 많은 시간을 들여야 할 가능성이 높다고 생각한다. 발표를 들으면서 발표자인 Siddharth Anand가 얼마나 고생했을지 감정이입이 될 정도.

  • no backup and recovery
  • no native support for types
    • 모든 데이터는 UTF-8 character string이고 sorting은 lexicographical만 지원하기 때문에, 숫자 sorting을 하기위해서 데이터에 zero-padding을 해야 한다는 어처구니 없는 일이 발생한다.
  • null attributes are not indexed
    • null 은 indexing이 안되어있기 때문에 where clause에 is null을 쓰면 full domain scan.
      • null인지 여부를 나타내는 필드를 추가해야 하기 때문에, 결국 sparse table의 장점을 잃어버림.
    • 역시 비슷한 문제로 null일 수 있는 attribute에 대해 order by 하면 null attribute의 record는 아예 나오지 않음.

  • data set partitioning

    • domain에 10GB limit와 1B attributes limit가 존재하기 때문에 domain을 application level에서 sharding 해야 함.
    • write throughput을 늘리기 위해서는 sharding 해야 함.

  • attribute name이 case-sensitive하므로 miscased나 misspelled attribute names을 체크해야 함.
  • limit N clause가 없으면 100개의 row만 return 되므로 실수하지 않았는지 체크해야 함.
  • 하나의 statement 내에서 하나의 attribute를 업데이트하고 다른 attribute는 null out할 수 없음.

Thoughts

흔히 NoSQL로 분류되는 storage들은 RDBMS가 아니라는 것 외에는 별로 공통적이라고 할만한 것이 없다. 그래서 NoSQL이라는 말을 쓰는 것을 매우 싫어하는 편이다. 이 발표를 들으면서 이러한 생각에 좀 더 확신이 들었다고 할 수 있을 것 같다.

NoSQL이라고 하는 storage들을 실제로 자세히 들여다보면 각각마다 데이터모델, 오퍼레이션 특성, 성능 특성, 성숙도는 천차만별이다.  결국 하나의 storage를 채용하기 위해서 서로 다른 특성들을 이해하고, 유효한 방법으로 평가는 일만 하더라도 결코 쉬운 일이 아닐뿐더러, 채용하기로 결정한 storage의 데이터모델에 적합하게 데이터를 구성한다든가, 위의 사례에서 보았듯이 각 storage별 세부 특성이나 결함 등을 처리하는 일까지 더한다면 하나의 storage solution을 도입하는 일은 보통 일이 아니다. 그래서, “NoSQL이란 거 좋다면서?”라고 말을 꺼내는 사람이 있으면 “그냥 RDBMS 쓰세요”라고 얘기해주는 것이 정답이라고 본다. NoSQL이라는 bandwagon에 타려고 발걸음을 서두르기 전에, 남들이 하는 이야기들을 반복하기 전에, 왜 RDBMS를 쓰면 안되는 지부터 자신의 도메인에서 고민해보았으면 한다.

주변 사람들에게는 몇 번 얘기했었지만, 이 발표를 들으면서 한가지 매우 인상 깊었던 얘기는 consistency가 깨질 수 있는 것을 인정하고 배치의 형태로 항상 백그라운드에서 동작하고 있는 data fixer를 개발하고 있다는 내용이었다. 별 것 아니라고 생각할 수도 있지만, 이러한 패러다임은 RDBMS를 사용하던 시절에는 inconsistency를 유발하는 원인이 있다면 이를 제거해야 하는 것으로 보는 것 (아니면 아예 무시하거나)과는 완전히 다른 패러다임이다. 현재로서는 weak consistency의 NoSQL storage를 사용하면서도 아직 기존의 패러다임에 젖어 있는 것이 사실인 듯 하다. 지금은 transaction 없이 application layer에서 index를 만들고 나중에 consistency가 깨어지지 않기를 기도하겠지만, 앞으로는 application layer에서도 anomaly를 탐지하고 자연스럽게 해결할 수 있도록 해야할 뿐만 아니라, 지속적인 validation & flx 작업이 필요할 것이다. RDBMS도 경쟁하고 있는 환경에서 wea
k consistency 모델이 얼마나 유행할지는 잘 모르겠지만, weak consistency 모델의 이러한 데이터 운영 패러다임을 간략한 개념과 구현으로 정리할 수 있다면 바람직할 것 같다.

NoSQL @ Netflix 더 읽기"

Social Games

댓글 달기 / Game, Stray Thoughts / /

스마트폰과 페이스북 등과 같이 소위 ‘소셜 네트워크’를 쉽게 구성할 수 있는 플랫폼이 마련되면서 유행하기 시작한 것이 바로 Social Games.

이러한 게임들은 간단하게 얘기하자면 다음 3가지의 요소로 이루어져있다.

  • 얼마나 많은 시간을 게임에 투입했는가에 따라 주어지는 꾸준한 성장 또는 성과.
  • 게임 내의 다른 친구들에게 자신의 성과를 공유할 수 있는 장치.
  • 게임 내에서 얼마나 많은 친구들을 가지고 있거나 초대를 했느냐에 따른 추가 보상.

대체로 플레이어의 지혜나 반응속도, 게임에 대한 숙련도 등으로 보상 받는 다른 게임에 대비해 난이도가 매우 낮기 때문에 많은 사람들을 대상으로 할 수 있고, 꾸준한 성장 및 성과의 피드백, 그리고 소셜 네트워크는 게임을 지속적으로 플레이할 수 있도록 하는 힘이 될 수 있다.

하지만, 일반적인 게임들은 다음과 같은 요소들도 가지고 있다.

  • 플레이어의 지혜나 반응속도, 게임에 대한 숙련도와 같은 요소, 즉 성취를 위한 과정에 따라 서로 다른 보상이 주어지는 요소가 있다.
  • 게임을 구성하는 요소가 대입되는 세계관이 있고, 게임의 진행이 대입되는 스토리가 있어, 호기심이 게임을 지속적으로 플레이 할 수 있도록 하는 동기 부여가 된다.

이러한 요소들이 얼마나 세련되어 있는가, 개별 요소가 어느 정도로 배합되어 있는가는 게임 마다 다르다.

아직 Social Game의 역사는 짧기 때문에 단정적으로 얘기할 수는 없지만, Social Game들에서 이러한 요소가 거의 ‘결여’되어 있는 이유 중 하나는 충분하지 않은 경쟁이라고 생각한다. 다시 말해, 이러한 세련된 요소를 추가하는데 비용을 지출하지 않아도 충분히 매출을 올릴 수 있기 때문이다.

물론, 이러한 이유를 Social Game의 특성 상 낮은 난이도의 필요성과 같은 이유에서 찾을 수도 있다. 하지만, 궁극적으로 사람들의 ‘필요’가 아니라 ‘재미’를 파는 시장에서는 사람들은 동일한 방식의 게임에 질릴 수 밖에 없고, 결국 충분한 경쟁이 있다면 좀 더 높은 수준의 요구를 충족시킬 필요성도 생겨나리라 생각한다.

‘Empires & Allies’와 같은 게임을 보면 Social Game도 점차 진화하고 있다고 생각하지만, 아직 현재의 수준에서는 ‘재미의 밀도’라는 면에서는 내가 요구하는 수준에 미치지 못하는 것이 사실이다.

Social Games 더 읽기"

위대한 리더의 위대한 질문

댓글 달기 / Book / /

8994382100_f

위대한 리더의 위대한 질문 | 요코야마 타로 지음 | 홍성민 옮김 | 예인

탄성이 나오는 경영의 성공을 일궈낸 리더들의 질문이라고 해서 그 질문이 정말로 누구에게나 해답을 주리라고는 생각하지 않는다. 하지만, 요즘 방향을 잃고 헤매고 있는 나를 위해 내가 스스로에게 어떤 질문을 해야 하는가에 대해서 적절한 대답을 들을 수가 있었던 것 같다.

자세한 서평은 사족에 불과할 듯 하고 인상 깊은 구절들을 발췌해 보았다.

GE 잭 웰치 전 회장

아무도 실적에 의문을 갖지 않을 때, 게다가 우량기업에서는 종신고용이 당연했던 1980년대 초반에 웰치는 구조조정을 단행했다.

CEO의 지위에 올라 잡다한 사업을 정리할 때 그는 피터 드러커가 던진 질문이 떠올랐다.

"이제까지 이 사업을 안 하고 있었다면, 지금 새로 시작하겠는가?"

웰치는 깊이 생각해봤다. 우리는 과거의 경험에서 벗어나기 어렵다. 전망이 없는 사업에 자본을 계속 투입하다가는 한순간에 모든 기회를 잃게 된다. 이것이 경영이 실패하는 전형적인 과정이다. 웰치는 그렇게 되기 전에 미리 손을 쓰고 싶었다. 당시 GE의 많은 사업군을 재편성하지 않으면 반드시 벽에 부딪힐 때가 온다는 것을 웰치는 확신하고 있었다. 드러커의 질문에 대한 대답이 ‘노’라면 그 사업은 철수해야 한다. ‘예스’라면 다시 드러커의 두 번째 질문으로 넘어가야 한다.

"그럼 그 사업을 어떻게 시작해야 할까?"

웰치는 장래성이 높은 사업군을 중심으로 자사의 영역을 재정리하고 구조조정을 단행했다. GE가 손을 대는 사업은 시장점유율에서 1, 2위가 되어야 한다고 그는 생각했다. 그래서 전망이 없는 사업이나 1, 2위의 지위를 차지했어도 부가가치가 적은 사업은, 드러커의 질문에 ‘참여할 의사’가 없다고 대답해야 했다. 이렇게 해서 장래성이 희박하다고 예상되는 수십 개의 사업이 매각 또는 폐쇄되었다. 이적이나 해고를 당한 종업원 수는 십 수만 명이나 되었다.

유니클로 야나이 다다시 회장

"가장 좋은 회사는 ‘사장이 말한 그대로는 실행되지 않는 회사’가 아닐까?"

모험적인 기업가가 얼마나 더 멀리 나갈 수 있는지는 회사가 성장했을 때 이런 사고방식을 가질 수 있느냐 없느냐에 달려있다. 같은 시각에서 보면 "경영자는 철학적인 본질만을 말해야 한다, 경영자가 일일이 참견을 하면 혼란이 일어난다"라는 지적도 있을 수 있다. 그러나 현실에서는 철학적인 본질만을 말할 수는 없다. 중요한 문제가 발생했을 때 철학적으로 처리하라고 하면 기업은 순식간에 좌초한다. 경영자가 아무리 철학적인 본질만을 이야기한다고 해도 위급한 상황에서는 결국 직원에게 "이렇게 하라!"하고 스스로 책임을 지고 말하게 된다.

NTT 도코모 오보시 고지 회장

"휴대전화와 인터넷을 결합시키는 건 어떨까?"

오보시는 직원들과 상의를 했다. 직원들은 모두들 ‘사장이 또 이상한 이야기를 꺼내는군’하는 반응이었다. <…> 오보시가 기술 담당 임원에게 지시를 내리자, 이는 아주 어렵고 무리한 도전이라는 소극적인 대답이 돌아왔다. 그러자 오보시는 기술 담당 임원에게 이렇게 물었다.

"어려운 일을 하는 사람이 프로가 아닌가요?"

도토루 커피 도리바 히로미치 창업자

"커피숍 사업이 이 세상에 존재하는 의의는 무엇일까?"

우리도 자신의 일이 세상에 존재하는 이유가 무언지 한 번쯤 진지하게 생각해볼 필요가 있다. 물론 그런 자문을 했다고 해서 바로 달라지는 것은 없다. 상사가 좋게 봐주는 것도 아니다. 그렇더라도 스스로에게 자신의 일이 존재하는 이유를 물어보면 마음이 깨끗해지고 미래에 좋은 결과를 가져오게 하는 힘이 될 것이다.

"요즘 코스트 병에 걸렸습니까?"

제품의 질을 떨어뜨려 가격을 인하하는 것은 누구나 할 수 있다. 그러나 그것은 결국 망하는 지름길이다. 경영사에는 그런 사례가 얼마든지 있다.

<…> 사업을 성공시켜 개혁을 이뤄내는 사람은 현실과 현실에서 이끌어낸 가설을 직시한다. 선견성을 갖고 있는 것이다. 따라서 사업에 성공하려면 가설에 맞춰 변하지 않으면 안 된다. "150엔이라면 고객들이 언제든 마셔줄 것이다. 그렇게 하기 위해서 우리는 어떻게 해야 할까?"하고 생각하게 되는 것이다. 변화는 쉽지 않다. 변화에는 혹독한 제약이 있기 때문이다. 그래서 대부분의 사람들은 이 단계에서 사고를 멈춰버린다.

그러나 도리바와 같은 위대한 질문자는 달랐다. 그는 반대로 "어떻게 하면 제약을 제거할 수 있을까?"하고 자문했다. 방법은 찾으면 얼마든지 있으며, 해결책도 발견할 수 있다. 이후에는 일관되게 자신의 의지를 관철시키면 된다. 제약을 제거할 때는 비용만을 생각하는 ‘코스트 병’처럼 본질을 놓쳐서는 안된다.

스즈키 모터스 스즈키 오사무 회장

스즈키 오사무도 기술 쪽은 자세히 아는 것이 없었다. 그래서 고민하고 있는 기술자 옆에서 "스페어타이어는 필요 없다, 재떨이는 빼라"하면서 지시했다. 당시 기술자들은 그의 말에 질린 표정으로 "그런 것으로는 원가를 35만 엔에 맞출 수 없습니다"라고 맞받아쳤다. 스즈키 오사무는 "그렇게 전부 안 된다면, 몸체를 종이로 만들면 어떨까?"라고 끝까지 밀어붙였다. 그러고는 마지막에는 이렇게 물었다.

"그럼 엔진을 떼어버리면 어떨까요?"

세븐 일레븐 스즈키 도시후미 회장

"실패를 왜 두려워하지요?"

그리고 이렇게 덧붙였다.

"실패도 공부입니다."

1990년대 후반 무렵, 그는 볶음밥 상품을 시식하던 중 "이것은 볶음밥이라고 할 수 없다"라고 딱 잘라 말했다. 하지만 이미 점포에서 어느 정도 판매가 되고 있던 상품이었다. 담당자는 그럭저럭 팔리니까 괜찮지 않느냐고 변명을 했다. 그러자 스즈키는 담당자를 호되게 질책하며 물었다.

"그럭저럭 팔리니까 이 정도로도 괜찮다는 겁니까?"

"어떻게 그 제약을 제거할 것인지를 고민해야 소기의 목적을 달성할 수 있지 않을까요?"

내가 사람들을 모아놓고 강의를
할 때마다 자주 느끼는 점은 많은 사람들이 자신의 성공 체험을 말할 때 가장 활기가 넘친다는 것이다. 누구나 자신감을 가져야 하고 의지할 곳이 필요하기 때문에 당연한 모습이다. 그러나 중요한 것은 그 다음 생각이다. 나는 그들에게 종종 묻는다.

"그때의 경험과 현재의 문제에서 무엇이 같고 무엇이 다른가요?"

대부분은 바로 답변을 하지 못하고 오랫동안 생각에 잠긴다. 이것은 그들이 무의식적으로 자신의 경험에 전적으로 의지하고 있기 때문이다. 다시 말하면 자신의 경험에서 빠져나와 문제를 바라보려고 한 적이 전혀 없었다는 얘기다.

혼다 후지사와 다케오 전 부사장

"이런 상태로 평온하게 일에 몰두할 수 있을까?"

승진에 무관심한 사람은 없을 것이다. 후지사와는 연구소를 독립 회사로 만들어 피라미드 구조가 아닌 문진형으로 평평하게 만들어버렸다. 이렇게 되면 과장이 몇백 명이 되어도 이상할 게 없었다. 이러한 구조는 혼다의 성장에 큰 효과를 발휘했다. 기술자들은 기술 개발에만 몰두하는 것이 그들의 역할이라고 생각했다.

맥킨지 아태지역 오마에 겐이치 전 회장

"당신이 그 문제 해결에 관한 모든 권한을 갖고 있다면 무엇부터 시작하시겠습니까?"

대부분의 사람들은 자신의 경험과 권한 범위 내에서 할 수 있는 일만을 생각한다. 이렇게 하면 될 거라는 믿음이 있어도 그 여정이 너무 멀게 느껴지면 생각하기를 멈춰버린다. 그럴 때 이런 질문을 던져보면 그 자리에서 대답하는 사람이 거의 없다. 결국에는 문제를 잘못 이해하는 것을 제외하면, 해결을 위한 아이디어가 떠오르지 않거나 아이디어를 실행할 힘이나 권한이 없는 것 중 하나로 좁혀진다.

이 질문은 양쪽 모두에 작용하는 매우 좋은 질문이다. 어떤 것을 선택해도 자유로운 입장이 주어진다면 누구나 아이디어를 떠올릴 수 있다.

"사장에게 1분밖에 시간이 없다면 당신은 무엇을 말할 것인가?"

강한 인상을 주는 사람은 거의 예외 없이 중요한 이야기를 먼저 꺼낸다. 그것도 자신이 선택한 가장 짧은 단어로 간결하게 말한다. 그들은 그렇게 말하기 위한 준비를 남들보다 많이 한다. 그 정도 준비하면 누구나 할 수 있다.

경영 컨설턴트 후나이 유키오

"당신의 생각은 어떻습니까? 그 일을 진정으로 하고 싶습니까, 하고 싶지 않습니까?"

고객이 "사실은 그다지 하고 싶지 않지만 사정이 있어서……"라고 말하면 후나이는 "그럼 그만두세요"라고 단호하게 말한다. 고객이 "그 일을 하고 싶다"라고 말할 때 다음 질문이 이어진다.

당신은 위기에 처했을 때 스스로에게 이렇게 솔직한 질문을 던져본 적이 이쓴ㄴ가? 하고 싶지 않은 일을 억지로 하는데 성공적인 결과가 있을 수 없다.

위대한 리더의 위대한 질문 더 읽기"

Development at the Speed and Scale of Google

댓글 달기 / Software Development / /

어제 송년회가 피곤했던지 일찍 잠들었다 새벽에 깨는 바람에, QCon SF 2010에서 Google의 Engineering Manager인 Ashish Kumar가 발표한 Development at the Speed and Scale of Google이라는 Presentation을 보게 되었다.

이 발표의 내용은 Google의 Infrastructure 중 하나인 빌드 시스템에 관한 내용으로 아주 재미있는 발표는 아니었지만, 몇 가지 흥미로운 점이 있었다.

Monolithic Code Tree

Google은 어느 정도 알려진 바와 같이, 하나의 코드 저장소에 모든 코드를 관리하고 있으며, 누구든지 필요한 소스코드를 체크아웃해서 사용할 수 있다.

Reducing Checkout Costs

모든 것을 소스로부터 빌드하기 때문에, 의존성을 가진 코드들을 체크아웃하는 비용을 무시할 수가 없는데, 사실 변경하려는 코드가 아닌 코드에 대한 로컬 복사본은 필요 없으므로, FUSE 기반 파일 시스템을 이용한 전체 code tree의 읽기 전용 복사본을 이용한다고 한다.

Reducing Code Review Costs

Google의 개발 프로세스를 보면 commit 이전의 코드 리뷰가 필수적으로 들어가있는 것으로 보이며, 코드 리뷰의 비용을 줄이기 위한 시도로서, 웹 상에서 graphical diffs를 조회하고 이에 대한 comment를 남길 수 있는 code review 도구와 lint error, code coverage, code analysis, test results 등이 제공된다.

IDE 기반의 도구에 대비해, 웹 기반 도구를 사용하고 있는 것이 흥미로운 점인데, C/C++ 계열에는 적절한 IDE가 부족한 점도 있겠지만, 아무래도 웹 기반 도구는 그 기본적인 특성 덕분에 하나의 정보를 여러 사람들에게 공유하기가 매우 쉽다는 점이 커다란 장점으로 작용하는 듯 하다. 다시 말해, 웹 만큼 훌륭한 shared workspace는 흔치 않다.

Reducing Build Costs

개발 과정에서의 커다란 비용 중의 하나로 지적하고 있는 것이 바로 build를 하는 도중 기다리는 비용인데, 이를 줄이기 위해서 object 파일들의 캐슁, 빌드 결과물에 대한 lazy한 액세스, incremental link (old binary + modified object files) 등을 지원하는 분산 빌드 시스템을 채용하고 있는 것 같다.

Continuous Integration

지속적인 통합 (Continuous Integration)이 실패했을 때 발송되는 메일에는 빠르게 원인을 파악할 수 있도록, 실패한 테스트의 목록, 실패를 유발한 Difff를 포함하고 있으며, 테스트 결과, 변경사항, 빌드 결과에 해당하는 웹 도구들에 대한 직접적인 링크를 포함하고 있다.

흔히 이러한 종류의 메일 보고서의 내용은 소홀한 경우가 많은데, 문제에 대한 진단이라는 것이 최종적인 목표라는 점을 생각한다면, 이러한 메일 보고서의 내용을 잘 갈고 닦을 필요가 있다.

Infrastructure

Google의 빌드 시스템은 외부에서도 사용할 수 있는 형태로 공개되어 있지는 않지만, 원래는 존재하지 않던 도구들을 Google이 사용하고 있는 것은 아니다. 가장 중요한 것은 아무래도 모든 도구들과 시스템이 통합된 형태로, 아무런 비용을 지불하지 않아도 전사적으로 제공되며, 실제 개발 과정에서 가능한 한 보이지 않는 형태로 제공되는 것으로 보인다.

여러 가지 종류의 도구들 (예를 들어, 여러 회사의 도구)을 혼합해서 사용하는 경우, 절대로 기능적인 면은 통합된 도구에 비해서 부족하지 않겠지만, 실제로는 접근성 등에 있어서 균질적이지 않아서, 어떤 도구는 사용하지만, 어떤 도구는 상대적으로 소외되어서 결과적으로 효율 차이가 발생하는 것으로 보인다.

Measurement

빌드 시스템 자체와는 별개로 흥미로웠던 것은 빌드 시스템의 각 요소에 대한 필요성을 실제 데이터로 증명하고, 빌드나 빌드 시스템의 개선을 위해서도 측정의 중요성을 지속적으로 강조하고 있다는 점이다. 즉,  ‘Cannot improve what we don’t measure’라는 모토인데, 엔지니어로서는 더 이상 공감하기 어려운 이야기라고 생각한다. 단기간의 개선은 직관이나 추측이 잘 먹힐지는 몰라도, 장기간에 걸친 개선에 있어서 측정은 필수적이다.

현실에서는 time-to-market 요구사항이나 엔지니어 개인의 취향, 심리적 상태와 같은 요소 때문에 측정이 희생되는 모습을 자주 보게 된다. 다소 공격적으로 얘기해서, 합리적인 trade-off를 통해 희생하거나, 다른 요소에 의해 제약 받지 않은 상태임에도 불구하고, 측정을 소홀히 하는 엔지니어는 엔지니어로서의 기본적인 소양이 부족한 것이 아닌가 생각을 해본다.

Development at the Speed and Scale of Google 더 읽기"

mediocrity was a failure of will, not talent

댓글 달기 / Software Development, Stray Thoughts / /

Whatever failing prompted Cutler to mistreat people, his capacity for blocking out the ordinary distractions of life was his road to excellence. People rarely achieved greatness because they were too blinded by daily routine even to try anything extraordinary. For Cutler mediocrity was a failure of will, not talent.

커틀러가 사람들을 학대하게 만드는 것이 무엇이었든 간에, 그를 뛰어나게 만드는 것은, 바로 일상 생활에서 집중을 방해하는 것들을 차단해내는 능력이었다. 사람들이 훌륭한 무언가를 이루어내기 어려운 이유는, 반복되는 일상에 잠식되어, 더 이상 평범하지 않은 무언가를 시도하지 못하기 때문이다. 커틀러가 생각하기에, 뛰어남에 미치지 못하는 평범함이란, 그저 의지의 부족이지, 재능의 부족이 아니었다.

— quoted from Showstopper!, Pascal G. Zachary

mediocrity was a failure of will, not talent 더 읽기"

Great teams have members that defy roles

댓글 달기 / Management, Software Development / /

The best teams I have worked in and with are those that defy the traditional roles and responsibilities.  Putting up artificial walls between extremely closely related disciplines can only be detrimental to getting great team work.  Any given set of devs, testers and PMs working on a feature have a different set of skills and experience they bring to the team.    Putting in place a structured set of expectations denies this fact.  If the developer is more senior and experienced in an area, then  you may want them leading more of the design of the feature, not just the implementation.   Likewise if the PM is very senior and an experienced software architect, you may want them to have more of an input in the actual implementation decisions.

내가 함께 일했던 최고의 팀들은 전통적인 역할과 책임에 반하는 팀들이었다. 서로 밀접한 관련을 갖는 분야들 사이에 장벽을 세우는 것은 팀워크에 방해가 될 뿐이다. 하나의 기능을 위해 모인 개발자, 테스터, PM들로 구성된 팀은 서로 다른 기술과 경험의 집합을 보유하고 있다. 정해진 역할과 책임을 강제하는 것은 이러한 사실을 부인하는 것이다. 개발자가 해당 분야에 있어서 경험이 깊다면, 구현 뿐만 아니라 좀 더 많은 기능 설계를 이끌어가기를 바랄 것이다. 마찬가지로, PM이 매우 숙련된 소프트웨어 아키텍트라면, 실제 구현 결정에 있어서 좀 더 관여하기를 원할 것이다.

— quoted from ‘Great teams have members that defy roles‘ by Brad Adams

Great teams have members that defy roles 더 읽기"

엔지니어와 비즈니스

댓글 달기 / Software Development / /

"None of us knew anything about the PC industry," said Rob Short. "We thought we were the hotshots–and knew what was going on–because we understood the technology. But we didn’t see what was happening in the PC business."

“우리들 모두는 퍼스컴 업계에 대해 아무 것도 몰랐습니다. 기술을 이해하고 있으니까 그것이 전부인 듯 자신만만하게 상황을 잘 알고 있다고 우리 스스로 생각하고 있었을 뿐입니다. 그러나 퍼스컴 업계에서 무엇이 일어나고 있는지 우리는 사실 아무것도 모르고 있었습니다.”

— quoted from Showstopper!, Pascal G. Zachary

엔지니어와 비즈니스 더 읽기"