일전에 약속을 드렸던 것처럼 Fault Tolerance 패턴 자료를 공유드립니다. 고 가용성이라는 것이 서버쪽에서는 동일한 요소를 두개 주는 이중화라는 기법으로 확보가 가능하지만, 자동차나 프론트엔드, 모바일쪽에서는 이중화 전략을 쓰기에는 한계가 많습니다. 소프트웨어 아키텍처 설계 과정을 준비하면서 만든 자료입니다. 저 역시 많은 선배님들의 지식을 가지고 성장했던 것처럼, 이 자료가 많은 동료와 후배분 들에게 미약하나마 도움이 되었으며 합니다. pdf로 […]

제가 패턴학회에 이사회 맴버로 있고, 저에게 가르침과 영향을 많이 주신 두분이 계십니다. 한 분은 유연하면서도, 지혜로운 삶을 사는 자세를 가르쳐 주신 Linda Rising 이시고, 또 한분은 AT&T에서 네트워크 스위치 개발을 시작으로, 오랫동안 Fault Tolerant 패턴을 정리해 주신 Robert S. Hanmer 님입니다. Bob Hanmer 님은 요즘 외부 활동을 잠시 쉬고 계시지만 이 분의 여러가지 노력들을 아래와 […]

소프트웨어 아키텍트의 길은 멀고 험난합니다. 그 와중에 조금이나마 아키텍트를 꿈꾸거나, 진입하시는 분들을 위한 과정을 진행하고 있습니다. 이미 다양한 대기업에서 강의를 했습니다. 수업의 커리큘럼은 다음과 같습니다. 관심있는 기업 교육자 담당자 분들은 연락을 주시면 됩니다. 시간당 25만원이 아니면 강의를 하지 않습니다. 시간당 20만원의 요청이 제법있는데, 안 하기로 했습니다. 다만 수도권이 아닌 지방이라면 지식 공유를 위해 훨씬 저렴하게 […]

맥을 쓰다보면 Parallel Desktop , Clean My Mac 같은 솔루션들이 끊임없이 매출을 창출하기 위해 버전을 관리하는 방법들을 내놓고 있다. 물론 새버전이 나올때마다 새롭게 사게해서, 짜증이긴 하지만.. 그 들도 먹고 살아야 하니 어쩔수없다. 그 만큼 가치가 있다면 계속 돈주고 사야지. 그럼 솔루션 업체 입장에서는 어떻게 해야 저항없이 고객들이 새 버전으로 솔루션을 업그레이드 할수있게 만들 수 있을가? […]

싸움은 가능한 피해야 하나, 결국 제한된 자원에서 소수의 승자만 존재한다면, 어쩔수 없이 싸움(경쟁)을 해야 한다.

싸우지 않고 이기는 것이 가장 최상이다. 라는 말은 있으나 실제 어떻게 하면 구체적으로 이걸 하는지 실행 방법에 대해서 구체적으로 나온 글등은 찾기 어려웠다.  요즘 당하고 있는데.  역시 고수는 다르다는 것을 깨닫고 있다.

보통 고수들의 전략을 보면 다음과 같다.

  1. 절대 자신이 직접 싸우지 않는다.
  2. 자신의 의견을 대신해서 잘 내세울 여러 대리자들을 만든다.
  3. 대리자들을 만들기 위해서는 당연히 보상이 필요하다. (이익을 확실히 보장하거나, 한 자리를 주겠다거나, 넌 정의를 지키는 사도야  그러니 꼭 니가 나서야해!  그럴 힘은 너만 있어.. 등.. )
  4. 그리고 싸우고자 하는 상대의 부정적인 정보를 계속 전달한다.
  5. 이 대리자들은 부정적인 시각으로 벌써 상대방을 바라보기 때문에,  직접 만나도 의심의 눈초리로 바라본다.  대부분 설득이 되지 않는다.
  6. 결국 대리자와 당사자는 피터지게 싸운다.
  7. 대리자가 이기면, 자신의 영향력을 발휘해 계속 잘 관리하면서 같이 이익을 공유한다.
  8. 대리자가 진다면,  결국 자기는 크게 상처를 입지 않고,  결국 싸움판이 벌어졌기 때문에 싸운 당사자들만 피를 보며 평판이 나빠진다.

그럼 여기서 만약 내가 당하는 피해자라면 해야 될 방어 전략은 무엇이 있을까?

계속 읽기

mongodb가 혜성처럼 등장해 많은 사랑을 받은 이유가 여러가지 있다.  가장 큰 덕은 모바일의 폭발적인 성장이지만, 개발자에게는..

  • auto-sharding
  • schemaless + json 데이터 저장
  • 자체적으로 가지고 있는 master-slave  high availability 기능

정도 되지 않을까 생각한다.

sharding이라는 것은 꽤 귀찮은 작업으로 어떻게 데이터를 분배해야 할지 많은 고민을 해야 되는데, 굳이 크게 고민하지 않고 auto-sharding을 쓸수 있는 적당한 규모의 프로젝트라면 마다할 필요가 없다.

또한 High Availiability를 자체적으로 지원을 하는데

replica-set-primary-with-secondary-and-arbiter1) 별도의  watcher인  arbiter 를 셋업하여 master-slave를 감시하는 방법

replica-set-primary-with-two-secondaries2) watcher없이 master-slave가 서로 heartbeat 메세지를 보내고 문제를 감지해 failover를 처리하는 방법

이렇게 두가지를 지원한다.  개발자에게는 야호하고 소리를 지를수 있는 좋은기능! (단 죽은 master를 어떻게 살리지는 개발자 여러분의 몫 – 좋은 방법이 있으면 공유를…)

계속 읽기

TDD

꽤 진부하면서도, 논쟁거리가 될수도 있지만, 개인적인 경험과 고민 끝에 글을 나누고자 한다. 꽤 스타트업을 기술적, 아키텍팅 쪽을 컨설팅하면서 지켜보아 왔던 경험치를 가지고 말씀 드리는 겁니다.  (물론 삼성이라는 대기업만 다닌 니가 스타트업을 얼마나 잘 알아? 라고 물어보실수 있지만 말랑 스튜디오, 빙글, 이노피아 테크 등 꽤 많은 업체들을 컨설팅하고 이야기를 나누고, 그들을 지켜보온 경험치라고 생각을 해주시면 될듯 합니다)

개발자들에게 TDD의 도입을  물으면 찬반이 매우 명확한 편입니다. 특히 큰 규모의 라이브 시스템을 운영한  웹 개발자 분들은 TDD를 통해 조기에 많은 문제를 잡고, 찐한 경험 이야기를 해주십니다. 100%로 동의합니다. 많은 유저들이 동시에 모여서 나가는 서비스라면 품질이 매우 중요해지고,  돌다리도 두들기고 건너가는 것이 맞습니다.  큰 웹서비스를 경험하신 분 입장에서는 TDD 가 큰 보험이 되며, 그 다음 Step을 넘어가는 좋은 보험이 되죠.

은총알은 없다.

특정 방법론, 전략이 A 상황에서는 좋은 약이 될수 있지만, 모든 상황에  항상 옳다고 할수 있을까요?

어떤 방법론이든, 기법이든 항상 장단이 있습니다. 전달을 할때 꽤 신중하게 전달을 해야 한다고 봅니다. “TDD는 좋다!” , “내가 해본 경험으로서는 정말 보험이 되고 든든한 녀석이다!!”  라고 말을 하지만, 모든 상황에서 적절한 방법인지는 정말 고민을 해봐야 합니다. 정말 크게 이슈가 되었던 Joel과 Bob 삼촌의 TDD 논쟁 사건을 보더라도, Joel쪽에 공감하는 사람도 제법있습니다.  이 논쟁에서 Bob 삼촌의 이야기를 지지하는 사람도 있지만, 아닌 사람도 꽤 많다는 것이죠..

정말 공감가는 글이 있는데,  바로 TDD역시 비용의 문제라는 것이다.  미물님께써 적은신 글을 보고 크게 공감을 하고 있습니다.   바로 비용이라는 측면에서 바라보아야 한다는 것입니다. 또한 지금 xper 에서 논의되고 있는 “TDD 는 죽었다.”  라는 글을 보면 공감할 부분이 꽤 있습니다.

계속 읽기

소마에 멘티들과 지난 몇개월 동안 재미난 프로젝트를 진행했습니다.

조재우, 노성현, 윤강호, 박종훈    (사진은 추후 잘 나온걸로 공개하겠습니다.)

안드로이드 테스트 자동화와 프로파일러를 직접 구축한 프로젝트를 진행했습니다. 기획, 개발 총 3달이 걸렸으며, 아직 시장에 바로 나가기에는 좀더 다듬을 필요는 있습니다.

일단 보시죠. 백번 듣는것 보다는 보시는게 더 나을거 같습니다.

기존 프로파일러와 다르게 SaaS 형태로 접근성을 높였으며,  테스트를 쉽게 그리고 프로파일링도 쉽게 만들기 위해 큰 고심을 했습니다. 몇몇 업체를 만나 안드로이트의 동적 분석, 자동화 테스트를 도와 드렸으며, 시행 착오를 겪으면서 조금씩 더 개선하고 있습니다.

계속 읽기

2013년 11월 21일 한,중,일을 대표하는 오픈소스 전문가가 모여 트레이팅 캠프를 엽니다.

장소는 부산  파라다이스 호텔에서 오전 10시부터 시작됩니다.

제가 동북아 오픈소스 포럼의 한국측 WG2 인력양성 분과장이라 소개를 하는 시간을 가지며,  오시는 분은 다음과 같습니다.

  • 한국 : 진성주 ,  Apache Usergrid Committer
  • 중국 : Hui CHENG, Open Stack Board Member
  • 일본 : Yoshiki SIGIURA , NCA Steering Committer

한중일을 대표하는 오픈소스 선수가 직접 여는 캠프이며, 부산 시민 여려분에게도 큰 도움이 될거 같습니다.

경남 지역에 개발자 분들의 많은 참여 바랍니다. 🙂

신청은 여기에 하시면 됩니다.

계속 읽기

패턴 저자 : 손영수, 오혜성, 양현철, 정승수

아키텍쳐 시각화 패턴 I 회에서는  아키텍처 시각화 패턴의 전체적인 구조와 구성되는 패턴들의 종류들을 간단히 소개하고, 아키텍처 시각화를 하기 전에 소프트웨어 시스템을 분석하기 위한 기본 요소들인 Domain Level Classifier Pattern과 Class Dependency Classifier Pattern에 대해서 살펴보았다. 2회에서는 시간에는 소프트웨어 시스템의 아키텍처적인 분석에 기본이 되는 다양한 Metric 분석과 관련된 패턴에 대해서 설명하고자 한다

Base Metric Extractor Pattern의 정의

소프트웨어 시스템의 아키텍처를 분석하기 위하여 의존성만을 이용하게 되면 분석의 시야가 좁아 보다 다양한 측면에서의 분석이 힘들어진다. 그리고 의존성만을 시각화한 Chart로는 상호 참조와 같은 아키텍처적인 문제만을 바로 확인할 수 있고 그 외의 소스 코드의 크기나 복잡성 등과 관련된 문제들은 확인할 수 있는 방법이 존재 하지 않는다. 의존성 분석만으로는 파악할 수 있는 아키텍처적인 문제들의 한계가 존재한다. 그렇기 때문에 이를 보완할 수 있는 다른 분석 방법들이 필요하다. 또한 이를 보완할 분석 방법도 매우 직관적이고 명시적으로 분석할 수 있어야 하며, 매우 빠른 시간에 아키텍처를 파악할 수 있어야 한다.

이때 소프트웨어 메트릭이라는 소프트웨어 시스템의 품질을 나타내는 지표를 이용하면 이 문제를 해결할 수 있다. 이 지표는 소프트웨어의 측정 기술을 기반으로 소프트웨어 생명 주기 동안에 소프트웨어의 특징 또는 특성을 객관적이고 과학적인 수치로 정량화한 지표이다. 또한, 다양한 문제점들을 정의하고, 관련된 기초 데이터를 수집하고, 문제점들을 객관적이고 과학적인 수치에 의해 분석하여 다양한 문제점들의 연관 관계 및 해결 방법을 탐색하며, 다양한 문제점들을 종합적으로 해결할 수 있는 문제 분석 프로세스 및 소프트웨어에 대한 지표이다.

이러한 지표들 중에서 품질 향상에 많은 도움을 줄 수 있는  소프트웨어 메트릭의 종류를 크게 4가지가 존재한다.

  • 첫번째로 단순히 패키지, 클래스, 메소드, 필드의 갯수,  코드 라인 수를 나타내는 “Count Metric”,
  • 두번째로 코드내의 순환복잡도, 무거움, 엉킴을 나타내는 “Complexity Metric”,
  • 세번째로 코드 간의 의존성을 나타내는 “Robert C. Martin Metric”,
  • 마지막으로 코드간의 상속을 수치로 나타내는 “Chidamber & Kemerer Metric”

이러한 메트릭을 통해 다음과 같은 이점을 얻을수 있다.

  •  소프트웨어 시스템의 코드를 정량적으로 분석이 가능하다.
  • 소프트웨어 시스템의 품질을 수치화 시키기 때문에 객관적인 분석이 가능하다.
  • 소프트웨어 시스템의 문제를 직관적으로 파악할 수 있다.
  • 소프트웨어 시스템을 다양한 시각으로 분석할 수 있게 된다.

계속 읽기