토요일, 5월 23, 2015

[B급 프로그래머] 5월 3주 소식

금주는 상당히 많은 소식을 정리해보았다.

  1. 웹/앱 소식
  2. 개발/관리도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리
EOB

토요일, 5월 09, 2015

[B급 프로그래머] 대규모 서버 소프트웨어에서 작업하는 동안 배운 교훈

지난번에 전해드린 소식 가운데, Lessons Learned while Working on Large-Scale Server Software이라는 블로그 글이 있었는데, 독자 여러분을 위해 간략하게 정리해드리겠다.

  1. 최악에 대한 계획을 세워라. 데이터베이스가 모두 내려가버리면 어떻게 되나? 모든 데이터가 다 날아가버리면 어떻게 되나? 시스템이 어떻게 실패하는지 이해하지 못하면 시스템이 어떻게 동작하는지도 이해하지 못한다.
  2. CAP 이론은 진짜다. 나쁜 일이 일어나는 목록이 아니라 중요한 결정을 내리게 강제하는 이론이다. 독배를 들었으면, 여기에 집중하라.
  3. 분산 컴퓨팅에 대한 오해는 진짜다. 네트워크는 빌어먹을 녀석이고, 대기 시간은 예측 불가능이고, 대역폭은 돈이 많이 들고 제약이 있고, 사람들은 당신의 네트워크에 침투하고, 구성 요소들은 이리저리 옮겨 다니고, 여러 팀과 회사가 시스템의 다양한 부분을 책임지고, 장비, 프로토콜, 직렬화 포맷은 엄청나게 다양하고... 시스템을 분산시켜야 한다면 다시 한번 생각하라. 어렵다.
  4. 역압이냐 평균 분배냐? 둘 중 하나를 골라라. Queues Don't Fix Overload를 보시오!
  5. 디버깅은 과학이다. 문제를 찾아 수정하는 과정에서 가설을 새우고 검증하라.
  6. 포스텔의 법칙은 어렵다. "전송할 때는 보수적으로, 받아들일 때는 자유롭게" 다시 말해, "좋은 데이터를 보내고, 쓰레기를 받을 준비를 하라"! 최대한 엄격하게 구현을 시작하라. 명세를 엄걱하게 구현하고 아무 것도 망가뜨리지 않게 만들어라.
  7. 네트워크를 신뢰하지 마라. 네트워크는 당신의 감정에 대해 신경 쓰지 않으며 당신의 신뢰에 보답하지도 않는다. 운영체제는 지역 컴퓨터를 벗어나 맺어진 연결에 대해 지역적으로 맺어진 연결과는 다르게 반응한다. 네트워크는 필요악이며, 즐거움을 찾을 장소는 아니다.
  8. 브루루스시스템 너마저! 가장 신뢰하는 기반 구조는 궁극적으로 가장 아픈 곳이 된다(B급 프로그래머 생각: 주키퍼야 미안하다. ㅋㅋ). 누군가 이런 기반 구조를 너무나도 신뢰하면 곧 당신(또는 다른) 팀에 마법이 된다. 모든 사람은 건드리지 않고서 여기에 신뢰하는 방식을 배움에 따라, 압력 하에서 썩고 고통 받기 시작한다. 결국 기존 시스템과 중요한 시스템의 특성을 모두 갖춘 구성 요소에 대해 어렵게 확장하는 작업을 벌여야 한다. 시스템의 성공은 운영자에 달려 있다. 충분한 연습이 없다면 시스템의 가장 취약한 부분이 된다.
  9. 빨리 죽이고 자주 죽이자. 오류 처리 방법에 대해 확신이 없으면, 죽여보자. 시끄럽고 빠르게 등장하는 오류는 찾기도 쉽고 수정도 쉽다. 수 일, 수 주, 수 달에 걸쳐 느릿느릿 시스템을 천천히 죽이는 오류는 진짜로 고통스럽다.
  10. 버그 수정은 실패를 초래한다. 새로운 소프트웨어 설치와 배포는 시스템에 있어 새로운 변수를 도입하는 훌륭한 수단이 된다. 배포가 커지면 더욱 무시무시해진다. 배포하고 나서 아무 문제가 없으면 두려워해야 한다. 우리 모두 실수를 하므로, 모든 것이 너무나도 조용하게 잘 돌아가면 나중에 문제를 감지하기까지 시간이 오래 걸릴 수도 있다는 사실을 암시할지도 모른다.
  11. 오래 시스템을 돌리야 그 때서야 버그가 나타날지도 모른다. 지속적인 개발은 오늘날 정도의 차이는 있지만 표준 관례다. 노드를 자주 재시작하면, 나타나기 전까지 오래 걸리는 이상한 동작, 손상, 확률이 낮은 이벤트가 숨겨진 채로 남을 것이다. (B급 프로그래머 생각: 상용 시스템에서도 이런 문제가 종종(응?) 등장하곤 한다. Boeing 787 software bug can shut down planes' generators IN FLIGHT를 참조하라!)
  12. 완전한 재시작을 준비하자. 부하가 걸렸을 때 백지 상태에서 전체 시스템을 재시작할 준비를 하자.
  13. 전역 변수 뿐만 아니라 전역 상태에 신경써라. 대규모 시스템, 특히 기존에 존재하는 시스템을 리펙터링할 경우, 문제 투성이가 될 수 밖에 없는 이유는 똑똑하고 산만한 양 쪽 사람들이 여러 가지 결정을 내렸고, 그 결과 모든 사람이 의지할 여러 부분을 눈에 보이지 않게 붙여놓았기 때문이다.
  14. 이게 모두 사람 때문이다. 시스템은 사람에 의해 죽고 산다. 시스템을 계속해서 살아있게 만들고, 운영하고 이상하다는 사실을 잽싸게 눈치채는 방법을 배우기 위해 힘들게 배운 교훈은 바로 개발에 시간이 걸리며 이 과정에서 사람이 개입한다는 사실이다. 이런 유형의 지식은 일반적으로 개발한 팀 내부에 남아 있고 개인이 역할을 떠나거나 바꿀 때 사라지는 경향이 있다. 새로운 팀원이 팀에 합류하면, 비공식적으로 이런 지식이 전달된다(우연한 시물레이션, 코드 검토, 기타 방법). 하지만 결코 영속적인 방식으로 진행되는 않는다. 영속적인 정보를 구축하고 전달하는 방식은 아주 중요하다. 시스템을 구축할 때, 운영자가 올바로 일을 처리할 것으로 가정하면 안 된다. 사람으로 인한 실패를 예상하라. 실수를 회복할 수 있는 도구에 대해 생각하려고 노력하라.

그냥 일반적인 좋은 이야기를 늘어놓은 것이 아니다. 원문을 읽어가면서 차분하게 검토해보기 바란다.

EOB

화요일, 5월 05, 2015

[B급 프로그래머] 5월 1주 소식

달콤했던 연휴도 다 끝나가므로, 5월 첫 주 소식을 정리해보았다.

  1. 웹/앱 소식
  2. 개발/관리 도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리
EOB

토요일, 5월 02, 2015

[B급 프로그래머] (Quora) 소프트웨어 개발자에게 자격증이 가치가 있을까?

Quora를 읽다보니 Are certifications for software engineers worth it?라는 글이 있어 독자 여러분들께 소개한다.

자격증은 가치가 있을지도 모르고 없을지도 모른다. 당신이 어디에 지원하느냐에 따라 달라진다.

마이크로소프트, 구글, 아마존과 같은 '엘리트' 소프트웨어 회사들은 일반적으로 소프트웨어 개발자를 위한 자격증에 중립적이지 않다. 실제로 부정적이다. 바로 그렇다. 당신이 자격증을 땄고 이들 회사 중 하나에 지원한다면, 이력서에 자격증 목록을 올리지마라.

이유는 자격증은 어느 정도 지식이 있음을 보여주긴 하지만, 엘리트 회사들이 원하는 핵심이 아니기 때문이다. 엘리트 회사들은 당신이 무엇을 아는지 실제로 관심이 없다. 엘리트 회사들은 만일 당신이 똑똑하고 전산 기초를 알고 있다면, 당신은 부족한 지식이 무엇이든 배을 수 있을 것이라 가정한다. 하지만 자격증은 당신이 실제 기술을 개선하는 대신 지식에 대해 신경쓰고 있음을 암시한다.

하지만 더 중요하게, 자격증을 따는 유형의 사람들은 공학도의 올바른 자질이 없을 가능성이 높다. 예를 들어, 나는 결코 자격증을 딸 생각이 없었고, 이들 회사에서 알고 있는 개발자 중 누구도 자격증을 딸 생각이 없었다. 만일 더 많이 배우고 싶다면, 코세라에서 강의를 듣거나 내가 직접 만드는 쪽에 집중할 것이다. 나는 심지어 탑 코더에도 참여해 이력서에 점수를 올릴지도 모른다. 나는 내가 자바 지식을 알고 있음을 보여줄 수 있기 위해 자바 지식을 기억하려고는 애쓰지 않을 것이다. 이렇게 하지 않는 이유는 기억에 신경쓰는 회사를 위한 직원으로 남고 싶지 않기 때문이다.

동일한 주장은 대다수 실리콘벨리 스타트업 대다수에도 적용될 수 있다. 스타트업에서는 자격증을 낮춰 본다.

어느 누구도 자격증에 대해 신경쓰지 않아야 한다는 사실을 의미하는가? 정확히 그렇지는 않다. 몇몇은 신경써야 한다. 특히 비기술 회사에서는 종종 자격증에 신경을 쓴다. 이들은 자바로 뭔가 만들어본 훌륭한 소프트웨어 개발자들 보다는 자바 2를 할 줄 안다는 지원자들에 끌리는 유형의 회사들이다.

위대한 소프트웨어 개발자들은 언어나 기술에 묶이지 않는다. 새로운 언어나 기술을 익히기가 쉽기 때문이다.

EOB