'IT/Computing'에 해당되는 글 8

  1. 2011.02.15 구글 크롬 OS 이야기
  2. 2011.01.30 [펌/번역] How Facebook Ships Code
  3. 2011.01.27 내가 썼던 PC들.. (4)
IT/Computing | Posted by 철규님(최규철) 2011. 2. 15. 00:20

구글 크롬 OS 이야기



얼마전 구글에서 크롬OS(Chromium OS)를 발표하고, 얼마지나지 않아 크롬OS를 탑재한 크롬PC 테스트 제품이 등장했다.

그렇다고 구글이 일반 PC의 OS 시장에 적극적으로 뛰어들었다고 보기는 무리일 것 같고 크롬OS를 탑재한 PC를 새로운 이동형 디바이스에 대한 시도로 보는 것이 더 나을 것 같다. 실제로 시제품으로 나와서 테스트 중인 크롬PC를 살펴보면, 가장 특징적인 것이 3G 모뎀을 내장해서 이동통신사의 통신망을 이용한다는 점인데, 제조사의 소형화/경령화 기술만 추가된다면 기존의 태블릿이 가지는 입력의 불편성과 일반 PC사용 환경과의 차별에서 오는 거부감을 동시에 해소할 수 있는 디바이스가 될 것이다.

일반 사용자들이 많이 쓰는 문서 편집, 스프레드 시트, 프리젠테이션 관련 작업은 클라우드 컴퓨팅을 베이스로한 웹 어플리케이션을 통해서 지원이 가능할 것이니 기존의 태블릿보다는 활용도가 더욱 높을 것이고, 3G 통신망을 바로 사용할 수 있으니 기존의 넷북이 가지는 무선 통신의 제약에서도 충분히 벗어날 수 있을 것이다. 단순한 작업을 하기 위해서 수분에 달하는 부팅 시간을 기다리고, 쓸수록 느려지는 OS를 사용해온 사용자들에게는 여러모로 크롬OS가 반가운 존재일 것이다.


[ 그림 : Federico Fieni , 출처 : http://www.loleg.com/blog/2008/10/29/8517/ ]

클라우드 컴퓨팅을 기반으로 하는 OS이니만큼 대부분의 프로그램과 데이터는 서버에 저장이될 것이고, 이로 인해 크롬PC는 최소한의 용량을 SSD 타입으로 지원한다. 덕분에 제조사는 제조원가를 낮출 수 있으며, SSD의 장점으로 인해 베터리 사용 시간도 더욱 늘릴 수 있다. 물론 3G 통신망 사용으로 인해 아껴둔 베터리 사용량은 그만큼 다시 소모 되겠지만..

이동통신사 입장에서도 줄어만 가는 음성통화량/문자메세지 송수신량을 메우기 위해서는 데이터 통신으로 인한 수익성을 도모해야되는데, 이러한 크롬OS/크롬PC의 등장은 반갑기만 할 것이다. 즉, 이제는 PC도 이동통신사에서 약정을 맺고 구입해서 사용하게 될 수도 있다는 것이다.

이러한 눈에 직접적으로 보이는 효과 말고도 주목해야할 부분이 또 있는데, 바로 새로운 시각을 가진 시장 참여자가 시장을 크게 흔들어 놓을 수도 있다는 점이다. 기존의 하드웨어 제조업체가 판을 치던 휴대폰 시장에서, 소프트웨어에 강점을 가진 애플이 스마트폰 열풍을 일으키고 기존의 시장 질서를 파괴했듯이, 크롬OS를 내세운 구글의 OS 시장 등장은 또 다른 충격이 될지도 모를 일이다. 복잡한 프로그램을 실행해야되는 사용자의 경우는 별 영향이 없겠지만, 단순히 인터넷 서핑을 하고 음악을 듣고, 영화를 보고 문서를 작성하는 용도로 PC를 사용하는 사람들은 크롬OS의 매력에 충분히 빠져들 수 있을 것이다. 더군다나 하드웨어적인 발전도 크롬OS에 긍정적인 신호를 보내주고 있는데, SSD의 보급화, 4G 통신망의 확대, 저전력 디스플레이 개발 등 여러모로 크롬OS가 성공할 수 있는 하드웨어적인 기반이 갖춰져 가고 있다.
앞서 말했듯이 크롬OS가 기존의 PC OS들과 전면전을 펼치는 일은 없겠지만, 새로운 시장을 창출하는 과정에서 일부 기존의 시장 영역을 잠식하는 일은 충분히 벌어질 수 있는 일이라 예상할 수 있다.

구글 크롬OS는 'Chromium Project - Chromium OS'라는 이름으로 아래의 사이트에서 자세한 정보를 제공하고 있다.

구글 크롬OS를 직접 사용해보고 싶은 경우, torrent의 magnet 형식으로 구할 수 있으니 구글링을 하면 된다. ^^; 구글로 검색을 하니 VMWare 이미지 형태로 된 파일을 찾을 수 있었는데, 지금 내 컴의 uTorrent가 열심히 다운을 받고 있다. 조만간 간단한 preview 정도는 올릴 수 있지 않을까 생각한다. ^^

아래 구글 크롬OS 동영상을 보면 포스팅에서 적지 못한 자세한 사항을 잘 알 수 있을 것이라 생각한다.
어떻게보면 클라우드 컴퓨팅이라는 생소한 개념이 적용된 무거운 주제인데... 이런 것을 이처럼 쉽고 가볍게 이해시키는 것도 구글의 또 하나의 경쟁력이 아닐까?





 

댓글을 달아 주세요

IT/Computing | Posted by 철규님(최규철) 2011. 1. 30. 17:40

[펌/번역] How Facebook Ships Code


How Facebook ships code

Facebook이 코드를 작성/적용하는 방법

원문 : http://framethink.wordpress.com/2011/01/17/how-facebook-ships-code/ 
        by
yeeguy on January 17th, 2011


I’m fascinated by the way Facebook operates.  It’s a very unique environment, not easily replicated (nor would their system work for all companies, even if they tried).  These are notes gathered from talking with many friends at Facebook about how the company develops and releases software.
나는 페이스북의 운영 방식에 매료되어있다. 그것은 매우 독특한 환경으로, 쉽게 따라할 수 있는 것이 아니다.(물론 따라한다고 하더라도 모든 회사에 그들의 시스템이 적용될 수 있는 것도 아니다.) 다음은 페이스북에 근무하는 많은 친구들과의 대화를 통해 모아진 내용으로, 페이스북이 어떻게 그들의 소프트웨어를 개발하고 릴리즈하는지에 대한 내용들이다.
 

Seems like others are also interested in Facebook…   The company’s developer-driven culture is coming under greater public scrutiny and other companies are grappling with if/how to implement developer-driven culture. 
많은 사람들이 페이스북에 관심을 가지고 있는 것 처럼 보인다. 그 회사의 개발자 주도 문화는 더 많은 공공의 관심 속에 놓였고, 다른 회사들은 그런 개발자 주도 문화를 어떻게 구현할지, 또는 구현 가능할지를 고민하고 있다.
 The company is pretty secretive about its internal processes, though.  Facebook’s Engineering team releases public Notes on new features and some internal systems, but these are mostly “what” kinds of articles, not “how”…  So it’s not easy for outsiders to see how Facebook is able to innovate and optimize their service so much more effectively than other companies.  
그런데 페이스북은 그 내부 프로세스에 대해서는 꽤 비밀스러운 편이다. 페이스북의 Engineering팀은 새로운 feature나 일부 내부 시스템에 대한 public note를 내놓지만, 이들은 대부분 "무엇"에 대한 것이지 "어떻게"에 대한 것은 아니다. 그래서 페이스북이 어떻게 다른 회사보다 더 효율적으로 그들의 서비스를 최적화하고 개선해 나가는 것이 가능한지를 외부의 사람들이 알아보기란 쉬운 일이 아니다.
In my own attempt as an outsider to understand more about how Facebook operates, I assembled these observations over a period of months.  Out of respect for the privacy of my sources, I’ve removed all names and mention of specific features/products. And I’ve also waited for over six months to publish these notes, so they’re surely a bit out-of-date.  
나 또한 한명의 외부인으로써 페이스북이 어떻게 운영되는지를 더 이해하기 위해,  나는 한달여의 기간동안 이런 관찰 자료들을 모았다. 나의 소스 제공자 개개인의 프라이버시를 위해서 그들의 이름을 지웠으며, 특정 feature나 제품에 대한 언급 또한 삭제하였다. 그리고 이 자료들이 어느 정도 시간이 지난 것이 되도록 하기 위해 이 노트를 알리기 전까지 6개월을 더 기다렸다. 
 I hope that releasing these notes will help shed some light on how Facebook has managed to push decision-making “down” in its organization without descending into chaos…  It’s hard to argue with Facebook’s results or the coherence of Facebook’s product offerings.  I think and hope that many consumer internet companies can learn from Facebook’s example.

이 노트가 페이스북이 어떻게 의사결정 사항을 그들의 조직 하부에까지, 그들을 카오스 상태에 빠뜨리지 않고 전달하는지를 어느 정도 알게해 줄 수 있기를 바란다. 페이스북의 결과물이나 그들 제품의 일관성을 놓고 논쟁하기는 힘들 것 같다. 나는 많은 소비자 인터넷 회사들이 페이스북을 예제로 배울 수 있을 거라 생각하고, 그러길 바란다.

HUGE thanks to the many folks who helped put together this view inside of Facebook.   Thanks are also due to folks like epriest and fryfrog who have written up corrections and edits.
페이스북의 내부를 볼수 있도록 도와준 많은 가족들에게 무한한 감사를 드린다. 더불어 epriest나 fryfrog와 같이 오류 정정에 도움을 준 분들에게도 감사드린다.

Notes:

  • as of June 2010, the company has nearly 2000 employees, up from roughly 1100 employees 10 months ago.  Nearly doubling staff in under a year!
    2010년 6월 기준으로 페이스북에는 약 2천여명의 직원이 있는데, 이는 약 10개월 전보다 1100여명이 늘어난 수치다. 1년만에 직원이 거의 두배가 되었다.
  • the two largest teams are Engineering and Ops, with roughly 400-500 team members each.  Between the two they make up about 50% of the company.
    가장 큰 두개의 팀은 엔지니어링팀과 운영팀인데, 각각 약 400-500명 정도의 팀원을 아지고 있다. 그 두 팀이 전체회사의 약 50%를 차지한다.
  • product manager to engineer ratio is roughly 1-to-7 or 1-to-10
    프로젝트 메니저와 엔지니어의 비율은 약 1:7 또는 1:10 정도이다.
  • all engineers go through 4 to 6 week “Boot Camp” training where they learn the Facebook system by fixing bugs and listening to lectures given by more senior/tenured engineers.  estimate 10% of each boot camp’s trainee class don’t make it and are counseled out of the organization.
    모든 엔지니어들은 4-6주 간의 부트 캠프 훈련 과정을 거치는데, 이곳에서 그들은 버그를 고치거나 선배들로부터 강연을 들음으로써 페이스북의 시스템을 배워나간다. 부트 캠프 참가자 중 약 10% 정도가 과정을 수료하지 못하고 퇴사를 권고받는다.
  • after boot camp, all engineers get access to live DB (comes with standard lecture about “with great power comes great responsibility” and a clear list of “fire-able offenses”, e.g., sharing private user data)
    부트 캠프 이후, 모든 엔지니어들은 실제 DB에 대한 접근 권한을 가진다. (물론 "큰 권력은 큰 책임과 함꼐한다"와 같은 강연도 받고, 개인 정보 공유 등과 같은 해고 사유 목록도 같이 제공된다)
  • [EDIT thx fryfrog] “There are also very good safe guards in place to prevent anyone at the company from doing the horrible sorts of things you can imagine people have the power to do being on the inside. If you have to “become” someone who is asking for support, this is logged along with a reason and closely reviewed. Straying here is not tolerated, period.”
    "사람들이 권한을 가지면 저지를 수 있는 많은 끔찍한 것들을들을 예방하기 위한 매우 좋은 안전 장치 또한 있다. 만약 당신이 어떤 지원을 요청한다면, 이것은 사유와 함꼐 기록되고 면밀히 검토된다. 이곳에서 어떤 길을 벗어난다는 것은 허용되지 않는다."
  • any engineer can modify any part of FB’s code base and check-in at-will
    모든 엔지니어는 FB code base의 어느 부분이든 수정할 수 있고, 원한다면 check-in도 가능하다
  • very engineering driven culture.  ”product managers are essentially useless here.” is a quote from an engineer.  engineers can modify specs mid-process, re-order work projects, and inject new feature ideas anytime.  [EDITORIAL] The author of this blog post is a product manager, so this sentiment really caught my attention.  As you’ll see in the rest of these notes, though, it’s apparent that Facebook’s culture has really embraced product management practices so it’s not as though the role of product management is somehow ignored or omitted.  Rather, the culture of the company seems to be set so that *everyone* feels responsibility for the product.
    매우 개발자 주도적인 문화다. "Product Manager는 기본적으로 여기서는 무용지물이다."라는 것이 엔지니어들로 부터 나온 말이다. 엔지니어들은 프로세스 중간에서 스펙을 변경할 수도 있고, 프로젝트를 재조정할 수도 있다.
    [편집자주] 이 블로그 포스팅의 저자 또한 Product Manager이다. 그래서 이러한 감성(개념)이 나의 관심을 끌었다. 하지만 앞으로 당신들이 남은 부분에서 볼수 있겠지만, 페이스북의 문화는 실제적인 제품 관리를 중요시하며, 제품 관리가 무시된다거나 생략될 정도의 비중을 차지하는 것처럼 보이는 것은 절대 아니다.
  • during monthly cross-team meetings, the engineers are the ones who present progress reports.  product marketing and product management attend these meetings, but if they are particularly outspoken, there is actually feedback to the leadership that “product spoke too much at the last meeting.”  they really want engineers to publicly own products and be the main point of contact for the things they built.
    월간 cross-team 회의에서, 엔지니어들은 진행 사항을 알리는 사람이 된다. 제품 마케팅과 제품 관리에서도 이 미팅에 참여한다. 하지만 만약에 그들이 특별나게 노골적이라면, "제품쪽에서 지난 번 미팅에 지나치게 말이 많던데"라는 피드백이 팀장에세 전달된다. 그들은 진심으로 엔지니어들이 공식적으로 그 제품의 주인이기를 바라고, 그들이 하고 있는 일의 주 접덤이길 바란다.
  • resourcing for projects is purely voluntary.
    프로젝트를 위한 인력 조달은 순수하게 지원에 의해서 이루어 진다.
    • a PM lobbies group of engineers, tries to get them excited about their ideas.
      PM은 엔지니어 그룹들이 그들의 생각에 흥미를 가질 수 있도록 노력한다.
    • Engineers decide which ones sound interesting to work on.
      엔지니어들은 어떤 일이 흥미로운지 결정한다.
    • Engineer talks to their manager, says “I’d like to work on these 5 things this week.”
      엔지니어들은 그들의 관리자에게, "이번주에는 이 다섯가지 일을 하려고 해요"라고 알린다.
    • Engineering Manager mostly leaves engineers’ preferences alone, may sometimes ask that certain tasks get done first.
      엔지니어 매니저는 대부분 엔지니어의 선택을 인정한다. 가끔씩 특성 task가 먼저 완료되어야 한다고 말하기는 한다.
    • Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between.  If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on.  Same for Architect help.  But in general, expectation is that engineers will handle everything they need themselves.
      엔지니어들은 frontend의 Javascript부터 backend의 database code, 그리고 그 사이에 있는 모든 featrue를 스스로 관리한다. 만약 그들이 디자이너로부터 도움을 받길 원한다면, 그 디자이너들이 그들의 프로젝트에 관심을 가지도록 해야한다. 기술적 도움도 마찬가지다. 하지만 일반적으로 엔지니어들은 그들이 필요한 모든 것을 스스로 핸들할 수 있도록 요구된다.
  • arguments about whether or not a feature idea is worth doing or not generally get resolved by just spending a week implementing it and then testing it on a sample of users, e.g., 1% of Nevada users.
    어떤 특정 아이디어가 가치가 있는지 아닌지에 대한 논쟁은 그 아이디어를 실제로 구현하고 그것을 사용자 샘플에게 테스트를 함으로써 해결된다. 이 과정에 약 1주일 정도가 소요된다.
  • engineers generally want to work on infrastructure, scalability and “hard problems” — that’s where all the prestige is.  can be hard to get engineers excited about working on front-end projects and user interfaces.  this is the opposite of what you find in some consumer businesses where everyone wants to work on stuff that customers touch so you can point to a particular user experience and say “I built that.”  At facebook, the back-end stuff like news feed algorithms, ad-targeting algorithms, memcache optimizations, etc. are the juicy projects that engineers want.
  • commits that affect certain high-priority features (e.g., news feed) get code reviewed before merge. News Feed is important enough that Zuckerberg reviews any changes to it, but that’s an exceptional case.
    어떤 높은 중요도를 가진 기능에 대한 commit 사항들은 merger전에 code review를 받는다. 뉴스피드에 대한 것은 주크버그가 모든 수정 사항을 리뷰할 정도로 중요하지만, 매우 특별한 경우이다.
  • [CORRECTION -- thx epriest] “There is mandatory code review for all changes (i.e., by one or more engineers). I think the article is just saying that Zuck doesn’t look at every change personally.”
    "모든 수정 사항에 대한 코드 리뷰는 필수 사항이다. 내 생각에 이 문장은 주크버그가 모든 수정 사항을 일일이 확인하지 않는 다는 것을 말하고자하는 것 같다"
  • [CORRECTION thx fryfrog] “All changes are reviewed by at least one person, and the system is easy for anyone else to look at and review your code even if you don’t invite them to. It would take intentionally malicious behavior to get un-reviewed code in.”
    "모든 수정 사항은 최소 1명 이상으로부터 검토받는다. 시스템은 누구든 당신의 코드를 쉽게 리뷰할 수 있도록 되어 있다. 심지어 당신이 그들에게 요청을 하지 않아도. 이것은 검토되지 않은 코드가 포함될 수 있는 악의적인 행동을 감지한다.
  • no QA at all, zero.  engineers responsible for testing, bug fixes, and post-launch maintenance of their own work.  there are some unit-testing and integration-testing frameworks available, but only sporadically used.
    QA팀이 전혀 없다. 엔지니어들은 그들의 일에 대해서 테스트, 버그 수정, 사후 관리까지 모두 책임이 있다. 일부 unit-testing이나 integration-testing이 가능하지만, 드물게 사용 된다.
  • [CORRECTION thx fryfrog] “I would also add that we do have QA, just not an official QA group. Every employee at an office or connected via VPN is using a version of the site that includes all the changes that are next in line to go out. This version is updated frequently and is usually 1-12 hours ahead of what the world sees. All employees are strongly encouraged to report any bugs they see and these are very quickly actioned upon.”
    "우리도 QA팀을 가지고 있다. 단지 공식적인 QA 그룹이 아닐 뿐이다. 사무실에 있는 또는 VPN으로 연결된 모든 직원은 다음 번 출시를 위한 모든 수정사항을 포함한 버전의 사이트를 사용한다. 이 버전의 사이트는 매우 자주 업데이트 되며 세상에 공개되는 것보다 약 1-2시간 앞서있다. 모든 직원은 그들이 발견한 모든 버그를 보고하도록 매우 강력하게 요구되어 있으며, 이러한 것은은 매우 빨리 행동으로 옮겨진다."
  • re: surprise at lack of QA or automated unit tests — “most engineers are capable of writing bug-free code.  it’s just that they don’t have an incentive to do so at most companies.  when there’s a QA department, it’s easy to just throw it over to them to find the errors.”  [EDIT: please note that this was subjective opinion, I chose to include it in this post because of the stark contrast that this draws with standard development practice at other companies]
    re : QA팀이나 자동화 Unit Test가 없다는 것은 놀랍다. - "대부분의 엔지니어들은 버그가 없는 코드를 작성할 수 있다. 단지 대부분의 회사에서는 그렇게 할 동기를 가지지 못하는 것뿐이다. QA부서가 있으면, 코드를 단순히 그들에서 넘겨서 오류를 찾는것이 쉬운일이다." [역주: 주관적인 의견임을 참고 바란다. 이러한 설명이 다른 일반적인 회사의 개발 실무와의 적나라한 차이를 잘 나타내고 있어서 포함하였다. ]
  • [CORRECTION thx epriest] “We have automated testing, including “push-blocking” tests which must pass before the release goes out. We absolutely do not believe “most engineers are capable of writing bug-free code”, much less that this is a reasonable notion to base a business upon.”
    "우리는 릴리즈가 되기전에 반드시 패스해야 되는 "push-blocking" 테스트를 포함한 자동화 테스트를 갖추고 있다. 우리는 절대 "대부분의 개발자는 버그 없는 코드를 작성할 수 있다"라는 것을 믿지 않는다. 이것은 사업에 있어서는 말할 것도 없이 적절한 표현이 아니다."
  • re: surprise at lack of PM influence/control — product managers have a lot of independence and freedom.  The key to being influential is to have really good relationships with engineering managers.  Need to be technical enough not to suggest stupid ideas.  Aside from that, there’s no need to ask for any permission or pass any reviews when establishing roadmaps/backlogs.  There are relatively few PMs, but they all feel like they have responsibility for a really important and personally-interesting area of the company.
    re : PM의 영향이나 제약이 없다는 것도 놀랍다. - product manager는 독립성과 자유를 가지다. 영향력을 갖추기 위한 중요한 방법은 엔지니어 매지너들과 좋은 관계를 유지하는 것이다. 멍청한 아이디어를 제안하지 않도록 기술적으로도 충분해야한다. 더불어, 로드맵이나 backlog 작성을 할때 어떠한 허락이나 리뷰 또한 요구되지 않는다. 몇몇 관련된 PM이 있는데, 그들은 회사에서 메우 중요하고 개인적으로도 흥미 있는 영역에 대해서 책임을 지고 있다고 느끼고 있다.
  • by default all code commits get packaged into weekly releases (tuesdays)
    기본적으로 모든 commit된 소스는 화요일의 주간 릴리즈에 포함된다.
  • with extra effort, changes can go out same day
    추가적인 노력을 통해 수정사항은 다른 날에 나갈 수도 있다.
  • tuesday code releases require all engineers who committed code in that week’s release candidate to be on-site
    그 주에 코드를 commit한 모든 엔지니어들은 화요일 코드 릴리즈때 자리를 지키고 있어야 한다.  
  • engineers must be present in a specific IRC channel for “roll call” before the release begins or else suffer a public “shaming”
    엔지니어들은 릴리즈가 시작되기 전까지 특정 IRC channel을 통해 출석을 체크해야 하며, 그렇지 않으면 공개적인 망신을 당할수도 있다. 
  • ops team runs code releases by gradually rolling code out
    운영팀은 코드 릴리즈를 점진적으로 진행한다.
    • facebook has around 60,000 servers
      페이스북은 약 6만개의 서버를 가지고 있다.
    • there are 9 concentric levels for rolling out new code
      9단계의 중앙집중식 코드 발행 단계가 있다.
    • [CORRECTION thx epriest] “The nine push phases are not concentric. There are three concentric phases (p1 = internal release, p2 = small external release, p3 = full external release). The other six phases are auxiliary tiers like our internal tools, video upload hosts, etc.”
      "9계의 발행 단계가 모두 중앙집중식은 아니다. 세 개의 중앙집중식 단계가 있다. (P1=내부발행, P2=소규모 외부발행, P3=전체 외부 발행). 다른 6 단계는 내부툴, 비디오 업로드 호스트 등 보조적인 단계이다.)
    • the smallest level is only 6 servers
      최소 레벨은 6개의 서버다.
    • e.g., new tuesday release is rolled out to 6 servers (level 1), ops team then observes those 6 servers and make sure that they are behaving correctly before rolling forward to the next level.
      예를 들어 화요일의 새 릴리즈가 6개의 서버로 전달되면(레벨1), 운영팀은 그 6개의 서버가 다음 단계로 전달되기 전까지 정상적으로 동작하는 지를 확인 한다.
    • if a release is causing any issues (e.g., throwing errors, etc.) then push is halted.  the engineer who committed the offending changeset is paged to fix the problem.  and then the release starts over again at level 1.
      만약에 릴리즈아 어떠한 문제를 일으시키면(에러 발생 등) 발생은 중지된다. 그 문제가 있는 수정 사항을 적용한 엔지니어는 그 문제를 수정하도록 요구 받는다. 그리고는 레벨1부터 릴리즈가 다시 시작된다.
    • so a release may go thru levels repeatedly:  1-2-3-fix. back to 1. 1-2-3-4-5-fix.  back to 1.  1-2-3-4-5-6-7-8-9.
      그래서 릴리즈는 단계들을 반복해서 거치게 된다 : 1-2-3-수정. 다시 1. 1-2-3-4-5-수정. 다시 1. 1-2-3-4-5-6-7-8-9.
  • ops team is really well-trained, well-respected, and very business-aware.  their server metrics go beyond the usual error logs, load & memory utilization stats — also include user behavior.  E.g., if a new release changes the percentage of users who engage with Facebook features, the ops team will see that in their metrics and may stop a release for that reason so they can investigate.
    운영팀은 정말 잘 훈련되어 있고, 존경받고 있으며, 매우 업무에 해박하다. 그들의 서버들은 일반적인 에러 로그, 로드&메모리 활용통계를 벗어나기도 한다. 물론 사용자의 행동 또한 마찬가지다. 예를 들면 만약 새로운 릴리즈가 페이스북 기능을 사용하고 있는 사용자의 비율에 변화를 준다면, 운영침은 그들의 통계자료를 보고 추가적인 조사를 위해서 릴리즈를 중단하기도 한다.
  • during the release process, ops team uses an IRC-based paging system that can ping individual engineers via Facebook, email, IRC, IM, and SMS if needed to get their attention.  not responding to ops team results in public shaming.
    릴리즈 과정 중에, 운영팀은 각각의 엔지니어들에게 필요한 경우 그들에게 알리기 위해 Facevook, email, IRC, IM, SMS 등을 통해 개인을 호출할 수 있는 IRC 기반 paging system을 사용한다. 운영팀에 응답하지 않을 경우, 공개적 망신을 당한다.
  • once code has rolled out to level 9 and is stable, then done with weekly push.
    일단 코드가 9단계까지 전달되고 안정적이면, 주간 발행은 종료된다.
  • if a feature doesn’t get coded in time for a particular weekly push, it’s not that big a deal (unless there are hard external dependencies) — features will just generally get shipped whenever they’re completed.
    한 주의 발행 시간 전까지 코딩이 완료되지 않는다고 해도, 큰 문제는 아니다.(크게 외부적인 의존성만 없다면) - 특이 사항들은 완전히 완료되었을때 포함된다.
  • getting svn-blamed, publicly shamed, or slipping projects too often will result in an engineer getting fired.  ”it’s a very high performance culture”.  people that aren’t productive or aren’t super talented really stick out.  Managers will literally take poor performers aside within 6 months of hiring and say “this just isn’t working out, you’re not a good culture fit”.  this actually applies at every level of the company, even C-level and VP-level hires have been quickly dismissed if they aren’t super productive.
    SVN 상에 문제를 일으키거나, 공개적으로 책임을 추궁당하거나, 프로젝트에서 너무 자주 제외되면 엔지니어 해고의 사유가 된다. "매우 높은 효율을 가진 문화이다." 생산적이지 않거나 매우 특별나지 않은 사람은 쉽게 잘려나간다. 관리자들은 고용후 6개월은 낮은 효율성도 감수하지만, 이후에는 "안되겠어. 당신은 이 문화에 적합하지 않다"라고 말한다. 이러한 것은 실제로 회사의 모든 레벨에 적용이된다. 심지어 C-레벨과 VP-레벨 고용자들고 능력이 특출나지 않으면 곧 해고된 적도 있다.
  • [CORRECTION, thx epriest]  “People do not get called out for introducing bugs. They only get called out if they ask for changes to go out with the release but aren’t around to support them in case something goes wrong (and haven’t found someone to cover for you).”
    "사람들은 버그를 설명하라는 요구를 받지는 않는다. 그들은 단지 릴리즈에 수정하상이 포함될 것을 요구받을 뿐이다. 하지만 어떤 것이 잘못되고 있어도 지원을 해주지는 않는다. (당신을 보호해주지도 않는다.)"
  • [CORRECTION, thx epriest] “Getting blamed will NOT get you fired. We are extremely forgiving in this respect, and most of the senior engineers have pushed at least one horrible thing, myself included. As far as I know, no one has ever been fired for making mistakes of this nature.”
    "단지 비난을 받는다고 해서 당장 해고되는 것은 아니다. 우리는 이러한 점에 있어서는 최대한 용서한다. 그리고 대부분의 시니어 엔지니어들은 최소 한가지의 어려운일을 요구한다. 내가 하는 한, 실수를 저질렀다고 해고된 사람은 없다. "
  • [CORRECTION, thx fryfrog] “I also don’t know of anyone who has been fired for making mistakes like are mentioned in the article. I know of people who have inadvertently taken down the site. They work hard to fix what ever caused the problem and everyone learns from it. The public shaming is far more effective than fear of being fired, in my opinion.”
    "나 또한 위에 언급된 사항으로 해고된 사람을 보지는 못했다. 실수로 사이트를 다운 시킨 한 사람을 알고 있는데, 그들은 이유가 무엇이든 그것을 고치기 위해서 열심히 일했고 모두가 그것으로 부터 배웠다. 내 생각에는 공개적으로 책임을 추궁당하는 것이 해고에 대한 불안감보다는 보다 효율적이다.

It’ll be super interesting to see how Facebook’s development culture evolves over time — and especially to see if the culture can continue scaling as the company grows into the thousands-of-employees.
페이스북의 개발 문화가 앞으로 어떻게 발전해 나갈지, 특히 회사가 수천명의 직원을 가진 회사로 커가면서 그 문화가 어떻게 지속되는지는 보는 것은 매우 흥미로운 일일 것이다.


What do you think?  Would “developer-driven culture” work at your company?

어떻게 생각하는가?  "개발자 주도 문화"가 여러분의 회사에서도 가능할까?

 


댓글을 달아 주세요

IT/Computing | Posted by 철규님(최규철) 2011. 1. 27. 21:50

내가 썼던 PC들..

스마트폰 AP도 이제 1GHz도 모자가 듀얼코어도 나오는 판이지만..
그래도 아직은 스마프폰보다는 노트북이, 노트북보다는 데스크탑이 성능이 좋은건 사실이다.
(때문에 스마트폰이 PC를 대체할꺼라는 생각에는 절대 반대하는 1人)

노트북 산지도 오래됐고, 집에 있는 PC는 원래 살때부터 고사양 모델이 아니어서
좀 더 나은 성능의 PC가 필요한상태...
데스크탑 업그래이드가 사실 제일 좋은 답이지만...
혹시나 몰라서 계속 노트북도 눈길을 주고 있다.....

원래는 고르고 있는 노트북에 대한 기록겸 포스팅을 할려고 했는데..
일찍 퇴근한 기념으로 그동안 썼던 PC에 대한 이야기도 적어보자..



#1. 나의 첫 PC : 컬러모니터, 윈도우3.1

삼성전자의 기.술.혁.명 은 이때부터 시작된 것인가?

국민학교(난 초등학생 시절이 없는 세대다.....) 6학년으로 올라가면서 처음으로 개인컴퓨터를 샀다.
위에 나와 있는 삼성 알라딘은 아니었던 걸로 기억하고 당시 최고(!)의 컴퓨터 매장이었던
'세진 컴퓨터'에서 샀더랬다.

기억나는 것으로는 286 AT, 컬러모니터, 20MB HDD, 그리고 286에 돌아가도록 만들어진 윈도우3.1..
(윈도3.1이 286에는 원래 안돌아가는게 아니었던가? 암튼 내 기억으로는 내 컴에서 돌아갔었다..)
그리고 사운드카드도 달려있어서 스피커와 마이크도 연결했었고,
버튼이 달랑 두개 뿐인(휠도 없는) 마우스도 있었다..

당시에는 부팅이 끝나면 시커먼 도스프롬프트 화면에 커서가 꿈벅거리고 있었고,
컴퓨터 좀 만진다고 하는 사람들은 autoexe.bat 파일을 수정해서
부팅 직후 바로 mdir이 실행되게 해서 쓰곤 했다. 그때는 정말 mdir이 대세였다.

당시 mdir의 등장은 지금의 아이폰과 맞먹을 만큼의 UI 혁명이었다.


그런 환경에서 처음으로 접한 윈도우3.1은 정말 획기적인 사용환경이었다.
(그 당시의 윈도우3.1은 독립적으로 동작하는 운영체제가 아니라 도스위에 얹어진 사용환경 수준이었다.)
하지만 그 당시 사용 가능한 대부분의 프로그램은 도스창에서 실행이 가능했고,
당연히 윈도우3.1보다는 mdir의 사용 빈도가 더 높았다.

지금 기억으로는 윈도우3.1에서 사용했던 프로그램은
노래방 프로그램, 바이오리듬 프로그램, 카드 게임 프로그램 정도였던 것 같다.

마이컴이라는 PC 잡지와 함께 컴퓨터 관련 지식을 쌓아나갔고,
6학년 중반때 즈음에는 2400bps 모뎀을 연결해서 PC통신이란 것도 접해봤다.

아직도 본가에 가면 수십권이 쌓여있는 마이컴


#2. 나의 첫번째 개발용 컴퓨터 : 486SX

이후에 사용했던 컴퓨터는 부동소수점연산장치가 없는 486SX(부동소수점연산장치가 있는 건 486DX 였다).
486컴퓨터가 유행할때 쯤에는 조립형PC도 유행을 타고 있었다.
조금만 노력을 기울이면 컴퓨터 조립&수리 가게를 찾을 수 있었고,
내가 샀던 두번째 컴퓨터도 조립형PC였다.
(그때 기억으론 부산공고 옆 길에 있는 작은 PC 가게였다. 내가 286에쓴 MODEM을 처음으로 산곳..)

486PC를 가지는 순간부터 내 개발자 인생은 시작됐는지도 모르겠다.
컴퓨터 잡지에서 보고 아무 고민없이 세진컴퓨터로 가서는 Turbo C++ 3.0 정품을 샀다.


5.25" 플로피디스켓 6장, 영어 메뉴얼 2-3권 그리고 78,000원의 가격.
지금 와서는 도대체 무슨 생각으로 샀는지도 모르겠고...
우리 부모님도 "프로그래밍"이 뭔지도 모르면서 사줬는지도 모르겠다.
(참고로 이걸 사러 134번 버스를 타고 혼자서 초량에 세진 컴퓨터까지 갔다 왔던 기억이 있다.)
당연히 1달도 안되서 조용히 책장 구석으로 몰아 넣은 기억이 난다....
생각해봐라. 프로그래밍이라곤 GW-BASIC 밖에 안해본 중학생이.......
C++을 가지고 OOP를 한다니....말도 안되는 짓이다....ㅋ

그리고 이때 하이텔,천리안,나우누리 같은 대형BBS 뿐만 아니라 사설BBS가 많다는 것도 알게 된다.....
대형BBS는 그때 eyes(나우누리의 부산 서버명), 사설BBS는 매직라인을 가장 많이 썼었다.
eyes를 통해서 많은 친구들을 만났었고, 매직라인을 통해서 많은 지식을 쌓았었다.
매직라인 운영자 아저씨, 형님들 틈에서 리눅스도 써보고, 인터넷도 써보고(web, telnet, ftp, newsgroup 등),
홈페이지도 만들어봤다.(포토샵, HTML과의 첫만남)..
그리고 1년 동안 피닉스, 두메산골이라는 이름으로 BBS도 운영했었다.
물론 주용도는 프로그램 공유......엄연한 불법이지만 공소시효 만료 ㅡ.ㅡv

이때는 PC통신 프로그램으로 이야기와 새롬데이터맨이 피터지는 혈투를 벌이던 시기로 기억된다.

당시 최고의 인기였던 <이야기 5.3>. "갈무리"라는 단어를 기억하는가?

조금 늦게 나왔지만 빠른 속도로 많은 사랑을 받았던 <새롬 데이터 맨>

이미 이때만해도 통신없이는 못 사는(정도는 사실 아니지만) 상태였다.
덕분에 울집에는 두개의 전화선이 되었다. 1개는 집 전화용, 1개는 내 PC 통신 전용선.........
다시 한번 말하지만......우리 부모님은 뭔지도 모르면서 그걸 무슨 생각으로 해주신걸까....?



#3. 광속과의 만남 : 두루넷 그리고 펜티엄

고등학교때 즈음에서 우리나라에 광통신 전용선이 깔리기 시작했다.
모뎀(57Kbps) 또는 ISDN(144kbps) 등이 다였던 국내 통신 환경에서
두루넷이라는 업체가 무려 1Mbps의 속도를 서비스하기 시작한 것이다.
이미 통신이라는 것에 완전히 재미를 붙여버린 나는 정말 바로 가입했다.
지금 기억으로도 그때 두루넷 회원 번호가 천번대였던걸로 기억한다.

10년의 영광을 간직하고 지난 2006년 사라진 두루넷

1M의 광랜과 당시 최고 사양의 부품을 넣어 직접 조립한 PC의 조합...
당시의 PC 부품을 기억해보면, 인텔 펜티엄 CPU, 마이크로닉스 보드,
램은 꽂을수 있는 만큼, 스카시 하드디스크, 1m의 대형타워케이스에 3개의 쿨링팬.....
마이크로소프트 인체공학형 키보드 등.....
HW와 네트워크의 스피드에 묻여 나 또한 엄청난 속도로 컴퓨터에 빠져든다.

하지만 그때는 지금과 같은 S/W 프로그래밍 보다는,
ASP, PHP, CGI, HTML, JS 등 웹프로그래밍에 관심이 더 많았고, (왜냐면 훨씬 쉬우니까.... +_+)
덕분에 종종 아르바이트로 용돈 벌이도 했던 기억이 난다....




#4. 내 생에 최초의 노트북

대학을 입학하면서 그 핑계로 노트북을 구입했다. 지금은 HP에 인수합병된 Compaq의 노트북.
마음에 드는 모델이 국내에 정식 수입되지 않아 수입 대행업체를 통해 구입했는데.
덕분에 키보드에는 한글 각인이 없었고, 설치된 OS는 영문 버젼이었다.
14인치 모니터와 4키로 안팍의 무게 덕분에 이후 노트북 구매에 있어서
나에게 크기와 무게라는 확실한 기준을 안겨준 노트북으로 기억된다.

미국 직수입으로 인해 키보드에는 한글 각인이 없었던 내 노트북

2000년 정도에 270만원이었으니 당시는 거의 최상급 노트북이었다.
덕분에 이 노트북 하나만으로도 무려 7년정도를 버틴 기억이 난다.



#5. 잠시 스쳐간 PC

군대를 갔다온 후 노트PC는 아직도 쓸만했지만,
고등학교때 산 PC는 슬슬 힘들어하고 있었다.

하지만 이때는 이미 PC 가격이 엄청나게 내려간 뒤였고,
제법 고사양의 PC에 LCD 모니터를 포함해서 100만원이 조금 넘는 돈으로도 살 수 있었다.

내 책상에 공간의 자유를 준 LCD 모니터
이 PC는 제대후(2005.09.)에 구입해서는 인턴으로 입사전(2007.06)까지 사용했다.
2년 남짓밖에 사용하지 못했고, 4년만인 2009년 전사했지만.. (번개가 랜선을 타고......ㅠㅠ)
모니터만큼은 아직도 동생 책상에서 현역으로 뛰고 있다.
 


#5. 나의 최고의 선택 : 삼성 Sens Q40

2007년 인턴 실습을 앞두고 기숙사에서 사용할 수 있는 노트북을 골랐다.
컴팩 노트북으로 뼈저리게 느낀, 크기와 무게....
애초부터 13인치 초과, 2kg 이상은 쳐다보지도 않았다.
심사숙고 끝에 고른 제품이 삼성 Sens Q40


극강의 휴대성을 자랑하고, 아직까지 현역으로 뛰고 있는 Q40

Q40은 12인치의 크기에 1.2kg도 채되지 않는 무게, 최고두께가 2.5cm 정도로 정말 극강의 휴대성을 자랑한다.
저전력 CPU 및 설계가 적용되어서 쿨링팬이 없어 소음을 내지 않으면서도 발열량을 최소화하는..

너무 휴대성이 좋아 자주 들고 다니다보니 기스도 많이 가고 LCD 프레임에는 금이 갔지만,
아직까지 충분히 제 역할을 해주는 대단한 놈인것 같다.

당시 소니의 vaio 시리즈에 유일하게 대응할 수 있던 제품이었는데.......
요즘은 이 정도의 휴대성과 성능, 그리고 가격대를 갖춘 제품이 없어서 너무 아쉽다.




사실 노트북을 구매할까 싶어서 관련 정보를 적으려고 시작한 것이었다.
무슨 바람이 불어서 이런 글을 적게되었는지는 나도 잘 모르겠지만..
적는 동안 옛 생각도 새록새록 나고 재미있는 시간을 보낸 것 같다....

댓글을 달아 주세요

  1.  댓글주소  수정/삭제  댓글쓰기 Zelon 2011.01.29 20:15

    ㅋㅋ 마이컴은 역시 최고의 잡지였던듯

  2.  댓글주소  수정/삭제  댓글쓰기 Missbae 2011.02.08 09:48

    확실히 PC 월드, 세상 같은 애들보단 마이컴이 진리긴 진리

  3.  댓글주소  수정/삭제  댓글쓰기 BBS magic line 2012.12.16 20:04

    아직도 Magic Line 을 기억하고 계십니까?
    당시 sysop 을 기억하시는지요?
    대연동 사무실!!!
    undersys@naver.com