[독서광] The Architecture of Open Source Applications Volume II

지난 번 [독서광] The Architecture of Open Source Applications을 소개해드렸는데, 이번에 Volume II를 독파한 기념으로 다시 한번 소개해드리겠다. 역시 HTML 버전은 무료이며, The Architecture of Open Source Applications 홈페이지에서 Volume I, II를 모두 읽을 수 있다. 지난번에는 킨들을 사용해 읽었지만 이번에는 신형 레티나 아이패드로 무척 쾌적한 환경에서 독파했다.

직전에 올려드린 [B급 프로그래머] (3) 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?에서 설명했듯이 이 책은 오픈 소스 아키텍처에 대한 문서를 이상적으로 위조해(!) 프로젝트가 흘러온 역사, 아키텍처의 선택 이유, 프로젝트에서 변경을 결정한 이유, 진행 과정에서 배운 교훈을 후대 프로그래머를 위해 멋지게 정리하고 있다. 국내에서도 인지도가 높아졌는지 심지어 Volume II의 1장인 'Scalable Web Architecture and Distributed Systems'는 확장성 있는 웹 아키텍처와 분산 시스템이라는 제목으로 번역까지 되었으므로 확장성을 고민하는 독자들께 좋은 선물이 되리라 생각한다. Volume II 서문에 나오는 이 책의 집필 목표는 이 책의 성격을 제대로 규정하고 있다.

소프트웨어 설계는 예제를 사용해 제대로 배울 수 있으며 또 그렇게 해야 한다. 전문가처럼 생각하는 방법을 배우기 위한 최선의 해법은 전문가들이 생각하는 방법을 연구하는 것이다.

Volume II에서도 Volumen I과 마찬가지로 정말 다양한 소프트웨어의 아키텍처를 소개한다. 누구나 한번쯤 들어봤음직한 GDB, Git를 비롯해, 함수형 언어 컴파일러와 프레임워크, 다양한 언어로 만들어진 네트워크 프레임워크, 웹 서버, 병렬 라이브러리, 임베디드 소프트웨어 패키징, 구성 관리 시스템, CMS에 이르기까지 분야를 가리지 않는다. 자신이 속하거나 관심이 있는 언어/분야의 내용만 집중적으로 읽어도 좋지만 여기저기 기웃거리는 과정에서 얻는 지식도 상당하므로 시간날 때마다 하나씩 읽어보면 소프트웨어 아키텍처와 설계에 대한 혜안을 얻을 수 있을 것이다.

결론: 백문이 불여일견! 소프트웨어 개발자라면 프로그래밍 언어, 개발 분야, 경험을 따지지 않고 누구에게나 강력하게 추천한다.

EOB

[B급 프로그래머] (3) 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?

지난번에 [B급 프로그래머] (2) 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?을 올려드리며 잠깐 한숨을 돌렸다. 마지막으로 다룰 내용은 3부작의 핵심인 이상화된 설계 문서를 _쉽고 제대로_ '위조'하는 방법이다. 파나스 큰 형님이 쓰신 논문의 'II. FAKING THE IDEAL PROCESS"를 함께 읽어보자. (이하 스크롤 압박 주의!)

앞서 우리가 따르고 싶은 이상적인 프로세스와 이 프로세스를 따르는 동안 만들어야 하는 문서를 설명했습니다. 우리는 마치 이상적인 방식에 따라 뭔가를 작업했다는 듯이 문서를 작성하는 방식으로 이런 프로세스를 "위조"합니다. 앞서 설명한 순서에 따라 문서를 만들어내려 노력합니다. 정보의 일부가 존재하지 않는다면, 이런 사실을 해당 정보가 등장해야 마땅한 문서의 일부로 기술하며 마치 정보가 변경되리라는 사실을 기대하듯 설계를 계속 진행해야 합니다. 오류를 찾으면, 반드시 수정하고 문서에 관련된 변경을 가해야 합니다. 문서는 설계를 담은 매체이며, 문서에 통합되기 전까지는 해당 설계 결정이 내려지지 않은 것처럼 취급해야 합니다. 중간에 얼마나 발이 걸려 넘어졌는지 무관하게, 최종 문서는 이상적이면서 정확해야 합니다. 심지어 우리가 가장 이성적이라 여기는 수학 분야조차도 이런 절차를 따릅니다. 수학자들은 근면성실하게 증명을 다듬어, 처음과는 완전히 다른 증명을 내놓습니다. 첫 증명은 종종 지극히 고통스런 발견 프로세스의 결과입니다. 수학자들이 증명을 해나감에 따라 이해도가 높아지며 단순화할 방법을 찾아냅니다. 궁극적으로, 몇몇 수학자들은 이론의 진실을 좀더 명백하게 밝혀줄 더 단순한 증명을 찾아냅니다. 더 단순한 증명을 논문으로 출간하는 이유는 독자들은 이론의 진실에 관심이 있지, 이론을 찾아나서는 프로세스에 관심이 있지 않기 때문입니다. 소프트웨어에도 이와 유사한 추론을 적용할 수 있습니다. 소프트웨어 문서를 읽기를 원하는 독자들은 프로그램을 이해하기를 원하지, 프로그램 제작 과정을 다시 경험하기를 원하지는 않습니다. 이상적인 문서를 제공하는 방법으로, 실제 독자들이 필요한 내용을 제공할 수 있습니다. 우리가 만든 문서를 이상적인 문서와 비교하면 한 가지 중요한 차이점이 있습니다. 우리에게는 수용하고 거부했던 설계 대안을 모두 기록하는 정책이 있습니다. 각 대안에 대해 왜 수용했으며, 왜 마지막으로 거부했는지를 설명합니다. 여러 달, 여러 주, 심지어 여러 시간이 지난 다음 우리가 무엇을 어떻게 했는지 궁금하게 여길 때, 문서에서 찾을 수 있습니다. 지금부터 여러 해가 흘러, 유지 보수 인력이 동일한 질문에 부딪혔을 때, 대답을 문서에서 찾을 것입니다. 이런 프로세스가 성과를 거두는 실례는 이상적인 프로세스를 보여주는 일부로 몇 년 전에 작성된 소프트웨어 요구 사항 문서를 들 수 있습니다. 일반적으로 요구 사항 문서는 코딩을 시작하기 전에 만들어지며, 결코 다시 사용되지 않습니다. 해당 요구 사항 문서를 만족하는 현재 소프트웨어의 운영 버전은 여전히 변경이 가해지고 있습니다. 소프트웨어를 테스트해야 하는 조직은 테스트를 광범위하게 선택하기 위해 이런 요구 사항 문서를 활용합니다. 새로운 변경이 필요지면 어떤 변경이 가해져야 하며 어떤 변경이 가해지면 안 되는지 기술하는 문서를 참조해야 합니다. 여기서 우리는 이상적인 프로세스의 시작 시점에 만든 (위조된) 문서가 소프트웨어를 실제 환경에 투입하고 나서 여러 해가 지난 다음에도 여전히 사용되고 있음을 볼 수 있습니다. 메시지는 명확합니다. 만일 문서를 주의 깊게 작성한다면 오랜 기간 동안 유용할 것입니다. 그리고 반대로, 이렇게 만든 문서가 광범위하게 쓰인다면, 올바로 작성할 가치도 있을 것입니다.

원문이 한 문단으로 되어 있어 중간에 일부러 끊지 않았으므로, 한 번만 더 읽어보자. 두 번 읽었다면 지금부터는 실제로 이상적인 문서를 '위조'하는 방법에 대해 고민할 차례다. 본문을 읽다보면 밑줄을 그어야 하는 부분이 여러 곳 존재하는 데 그 중에서도 특히 "소프트웨어 문서를 읽기를 원하는 독자들은 프로그램을 이해하기를 원하지, 프로그램 제작 과정을 다시 경험하기를 원하지는 않습니다."라는 부분에 주목할 필요가 있다. 문서를 작성하는 과정에서 부딪히는 가장 큰 어려움은 바로 '우리가 앞으로 실제로 진행해야할 작업을 이상적인 형태가 아니라 전지적 관점에서 시시콜콜 기술하라'라는 말도 안 되는 요구다(말이 안 되는 이유는 시리즈 (1)번을 다시 읽어본다). 이런 말도 안 되는 요구에 따라 만든 문서로 최종 결과물을 검수하려니 여기저기서 삐걱거린다. 요구 사항을 낸 쪽에서는 미리 요구 사항을 제대로 수집하지 않았다고 난리며, 개발한 쪽에서는 애초부터 구현이 불가능한 설계 명세라고 난리다. 최종 사용자는 자신들의 의견이 반영되지 않았다고 난리며, 유지보수하는 인력들은 실제 개발 과정에서 일어난 변경 사항이 하나도 반영 안 된 죽은 문서라고 난리다. 어차피 책장 속에 들어가 다시는 꺼내보지 않을 운명에 처한 문서가 이 난리를 칠만큼 가치 있는지는 정말 잘 모르겠다.

그렇다면 문서를 어떻게 위조해야 할까? 개인적인 경험에 따르면, 미션 크리티컬한 프로젝트가 아니라면(음... 국방, 금융 말이지...) 처음 요구 사항 명세, 상위 아키텍처 설계, 상세 설계 문서 범위와 양을 최소로 줄이기를 권장한다. 그리고 문서를 작성할 경우 항상 타임머신을 타고 미래로 간 다음에 미래 시점에서 과거를 기술하는 방법으로 위조하는 방법을 권장한다. 이렇게 두 가지 기본 원칙을 제안한 이유를 조금 자세히 설명할 필요가 있겠다. 일단 범위와 양을 줄여야 하는 가장 큰 이유는 불확실성 때문이다. 어차피 문서 작업도 작업이므로 많은 시간이 들어가는데, 나중에 변경이 일어날 경우 문서를 작성하느라 날려버린 기회 비용을 상실하는 동시에 문서 수정 작업이라는 이중 난관에 부딪힌다. 어차피 처음부터 완벽한 문서를 만들지 못하는 상황에서 분량도 늘이고 완성도도 높이려 애를 써봐야 모든 사람이 괴로을 뿐이다. 게다가 내용 채워넣기 식으로 만든 문서는 본질을 흐리게 만들어 나중에 투입되거나 유지보수하는 인력에게 있어 혼란을 일으킨다. 로버트 C. 마틴 큰 형님께서 '가장 좋은 주석은 주석을 달지 않을 방법을 찾은 주석'이라고 표현했듯이, 어떻게 보면 소프트웨어 소스 코드와 최종 매뉴얼만으로 설명이 가능한 경우가 최선이다. 다음으로 미래 시점에서 과거를 기술하는 방법을 제안하는 이유는 사람의 사고 특성상 기한이 많이 남은 일일수록 추상적으로 생각하고 기한이 짧은 일일수록 구체적으로 생각하기 때문이다. 사람들은 사후분석에 능하다. 어떤 일이 터지고 나서 현실화된 다음에는 어떻게든 이를 합리화하고 이해하려는 노력을 기울이게 되므로, 미래 관점에서 과거를 서술하는 방식이 훨씬 쉽다. 하지만 프로젝트를 발주한 내/외부 '고객'에게 이런 요청을 할 경우에는 반드시 반대 급부를 제시해야 한다. 공동 설계 참여를 요청하거나(그렇게 되면 설계 문서가 이상화되어야 하는 이유에 대해 인정할 수 밖에 없는 상황에 놓이게 된다. 변경이 일상다반사인 상황에서 고정된 최종 형태를 고집할 수 있을까? 고집부린 사람이 나중에 다 뒤집어 쓰게 되는 판국인데?) 중간 검수 과정을 둬서 요구 사항 문서와 아키텍처/설계 문서를 깔끔하게 정리해(즉 위조해서!) 다시 제공하겠다는 (즉 처음 프로젝트 시작 시점에서 만든 문서는 큰 범위와 목표만 기술한다) 약속을 하는 방법이 대표적인 해법이다. 프로젝트가 중간 정도 지났으면 이미 상당한 밑그림과 세부 사항이 파악되었으므로 이상적인 최종 형태에 가까워지기에 작성하기도 읽기도 쉬운 문서 작성에 한 걸음 다가간 상태기 때문이다.

지금까지 일반적인 내용을 설명했는데, 위조된 문서의 구체적인 예가 없을까? 다행스럽게도 로버트 C. 마틴 큰 횽아가 작성한 '클린 코드'의 14장 '점진적인 개선'은 지금껏 B급 프로그래머가 봐 왔던 위조 문서 중에서 백미를 자랑한다. 일단 최종 형상을 보여준 다음에 원래 엉망인 코드로 돌아와 설계 관점에서 차근차근 개선하는 과정을 위조해서(!) 보여주는데, (앞서 피해야 한다고 말했던) '프로그램 제작 과정'을 따르면서도 (최종 목적인) '프로그램 이해를 도와주는' 놀라운 업적을 달성했다. 이렇게 된 이유를 생각해보니 설계 결정이 어떤 식으로 일어났고 그 결과 코드가 어떻게 변경되었는지를 유기적으로 설명하기 때문이다. 물론 일반적인 프로젝트 진행 과정에서 (감히?) 이런 파격적인 방식으로는 문서 작성이 힘들겠지만, 디자인 관련 결정을 이상적인 방식으로 기술하는 좋은 본보기가 되므로 꼭 읽어보기 바란다. 다음으로 소개할 예는 The Architecture of Open Source Applications Vol I, II(AOSA라 약칭하겠다)다. 오픈 소스 아키텍처를 설명하는 내용으로 이미 많은 분들께서 알고 계신 이 책은 프로젝트가 흘러온 역사, 아키텍처의 선택 이유, 프로젝트에서 변경을 결정한 이유, 진행 과정에서 배운 교훈을 비교적 이상적인 프로세스에 가깝게 기술한 훌륭한 사례 연구를 담고 있다. 물론 프로젝트가 어느 정도 진행된 다음 기술된 사후해석으로 취급해 가치를 인정하지 않는 분들도 계시겠지만, 소프트웨어 큰 그림을 이해하기 위해 필요한 구성 요소가 무엇인지를 잘 드러내고 있으므로 아키텍처 문서가 어떻게 되어야 하는지 궁금하신 분들께서는 반드시 읽어보시기 바란다(실제로 오픈소스 프로젝트 문서에서도 점점 AOSA의 해당 내용을 언급하는 경우가 많아지고 있다. 그만큼 도움이 된다는 말이다).

결론: 개발자들이 합심해 죄책감없이 _뻔뻔_하게 문서를 이상적인 형태로 위조(!)함으로써 우리 시대 가장 골치 아픈 문제 중 하나인 문서화 작업을 즐겁고 생산적으로 바꿔놓을 수 있다면 얼마나 좋을까? 이와 관련해 다른 좋은 방법이나 의견 있으면 언제든지 알려주시기 바란다. 정말 바라건데, 좋은 아이디어는 함께 공유합시다.

EOB

[독서광] 마이바티스 프로그래밍

지난번에 소개드린 [독서광] 데이터 접근 패턴과 같은 부류의 책 말고 실제 현장에 바로 적용 가능한 책을 원하는 독자분들이 분명히 존재한다. 오늘은 바로 이런 목적에 부합하는 마이바티스 관련 국내서(번역서가 아니다)인 '마이바티스 프로그래밍'을 소개해드리겠다.

먼저 마이바티스가 뭔지부터 잠깐 설명하고 넘어갈 필요가 있다. 마이바티스는 객체지향 애플리케이션을 작성할 때 관계형 데이터베이스를 손쉽게 사용하게 만드는 자료 매퍼 프레임워크라고 보면 된다. 하지만 프로그래밍에 앞서 관계형 테이블을 설계하고 SQL 구문을 작성한다는 측면에서 마이바티스는 단순히 하단 데이터베이스를 영속적인 객체 저장소로 보는 전통적인 ORM과 차이를 보인다. 실수를 유발하기 딱 좋은 엄청난 중복/반복 코딩으로 악명 높은 JDBC를 쉽게 사용하게 만들어주는 도구라 볼 수도 있겠다. 마이바티스는 SQL을 기반으로 출발하다보니 개발자들이 쉽고 빨리 기술을 배우고 적용할 수 있는 장점이 존재한다. 또한 관계형 자료를 객체로 인출하고 객체를 관계형 자료 형태로 저장할 수 있으므로, 도메인에 밀접한 프로그래밍 논리를 구현하기가 수월하다는 장점도 있다. 비즈니스 논리와 질의를 분리해서 얻는 장점은 여기서 다시 한번 설명하지는 않겠다.

자 이제 본격적으로 책 내용을 살펴보자. 이 책은 초중급자를 대상으로 필요한 개발 환경 구축부터 마이바티스의 기본 동작 방식과 활용법을 차근차근 단계적으로 설명한다. 실습이 가능하게 이클립스에서 바로 사용 가능한 예제 코드까지 홈 페이지에서 제공하고 있기에 테스트용 MySQL만 설정하면 바로 동작 과정을 확인할 수 있다. JDBC에 익숙한 개발자들이 마이바티스로 쉽게 넘어가게 CRUD 관련 코드를 JDBC 버전과 마이바티스 버전 양쪽으로 구현해놓았으므로 비교하면서 읽어보면 빠르게 부트스트래핑이 가능하다. 이렇게 감을 잡게 만든 다음, 웹 애플리케이션과 스프링 웹 애플리케이션 작성 방법을 설명해 마이바티스를 웹 애플리케이션 기반 프레임워크로 활용하도록 도와준다. 마지막으로 중급자를 위해 마이바티스 설정 파일, 매퍼 XML/인터페이스, 동적 SQL, 제네레이터를 참조 가능한 형태로 정리한다. 또한 (여러 가지 이유로) 기존 아이바티스에서 아직 벗어나지 못하는 개발자를 위해 아이바티스와 마이바티스의 차이점과 이주 방식에 대해 본문과 부록에서 설명하고 있으므로, 아직도 아이바티스를 사용하는 분들이 계시다면, 이 책을 읽고 마이바티스로 넘어가면 좋겠다는 생각을 해봤다. 마이바티스의 완성도가 상당히 높으므로 정말 불가피한 상황이 아닌 이상 굳이 레거시의 저주에 발목 잡힐 이유는 없다는 생각이다.

책을 읽다보니 아쉬운 점이 하나 있는데, 스프링 연동 설명이 생각보다 약했다. 물론 스프링이 워낙 복잡하니 정말 제대로 하려면 토비의 스프링과 같은 책을 읽어야 하는 상황이 정상이긴 하지만, 국내 개발자들이 스프링과 마이바티스를 하나로 묶어 개발을 진행하는 경우가 많으므로 혹시 후속 작품을 기획한다면 아예 제목부터 '마이바티스와 스프링 프로그래밍'으로 근사하게 하나 뽑은 다음에 핵심만 파고들면 더할 나위가 없겠다.

결론: 이미 눈치챘겠지만 책 목차와 전개 방식이 (늘 바쁘고, 핵심을 원하고, 바로 감을 잡게 만들어주는 뭔가를 요구하는...) 전형적인 한국 개발자를 위해 최적화되어 있으므로 국내서의 장점을 아주 잘 살렸다고 칭찬해주고 싶다. 마이바티스 책 한 권만 골라라고 하면 주저없이 이 책을 선택하겠다.

EOB

[B급 프로그래머] (2) 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?

지난번 올려드린 [B급 프로그래머] 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?라는 글에 많은 독자분들께서 관심을 보여주셨다. 따라서, 원래 2회로 예정했던 계획을 변경해 3회로 늘이기로 마음 먹었다(쪽대본 아니에요!). 오늘은 지난번 심각한 문제점에도 불구하고 이상적인 프로세스를 기술해야 하는 이유에 대해 파나스 형님께서 쓴 글의 III번 항목을 번역해봤다.

위에서 언급한 내용(이상적인 프로세스의 비현실성)은 아주 명백하며, 주의 깊은 사고가에게 잘 알려져 있으며, 정직한 사람들이라면 수긍할 것입니다. 그럼에도 불구하고 소프트웨어 설계 프로세스, 소프트웨어 설계 방법론을 다루는 워킹 그룹, 소프트웨어 설계를 논리적인 방법으로 기술하는 (이윤이 많이 남는) 각종 교육 과정에서는 늘 이상화된 프로세스를 주제로 삼습니다. 이런 사람들이 성취하려는 목표가 무엇일까요? 이상적이긴 하지만 완전히 달성할 수 없는 프로세스를 파악했다면, 최대한 비슷하게 이상적인 프로세스를 따를 수 있으며 그 결과 이상적인 프로세스를 따를 경우 만들 수 있어야 했던 문서를 작성할 수 있습니다. 이런 활동을 '이상적인 설계 프로세스를 위조(fake)하기'라 부릅니다. 이런 위조 기법이 필요한 이유를 정리하면 다음과 같습니다.

1. 설계자들은 지침이 필요합니다. 큰 프로젝트를 맡았다면, 엄청난 작업 분량에 쉽게 압도 당합니다. 무엇을 먼저해야 할지 확실하지 않습니다. 이상적인 프로세스를 제대로 이해하면, 프로젝트 진행 방식을 알 수 있습니다.
2. 주먹구구식 임시 변통 대신 프로세스를 따르려 노력할 경우 이상적인 설계에 좀더 가까이 다가갈 것입니다. 예를 들어, 심지어 이상적인 시스템을 설계하기에 필요한 모든 사실을 모를 경우에도, 코딩에 앞서 이런 사실을 찾으려는 노력은 설계를 더 좋게 만들고 재작업을 줄일 것입니다.
3. 조직이 여러 소프트웨어 프로젝트를 수행할 때, 표준화된 절차는 큰 장점입니다. 여러 프로젝트 사이에서 좋은 설계 검토를 비롯해, 사람, 아이디어, 소프트웨어 공유를 원활하게 만듭니다. 표준화된 프로세스를 명세할 경우, 이상적이어야 한다는 사실은 합리적으로 보입니다.
4. 이상적인 프로세스에 동의했다면, 프로젝트를 만들어가는 프로세스를 측정하기가 더 쉬워집니다. 이상적인 프로세스가 요청하는 내용과 비교해 프로세스의 산출물을 비교할 수 있습니다. 어느 부분에서 뒤쳐졌는지 앞섰는지 알 수 있습니다.
5. 외부에서 프로젝트 진행을 주기적으로 검토하는 관례는 좋은 관리에 있어 핵심입니다. 프로젝트가 표준 프로세스를 따르려 시도한다면, 검토도 쉬워집니다.

지난번 글을 읽고 나서 이번 글을 읽으면 갑자기 멘붕이 올 것이다. 분명히 이상화된 프로세스는 현실적이지 않다고 말했는데, 그래도 이상적인 프로세스를 추구해야 한다는 모순된 이야기가 나온다. 너무 고민하지 마시라. 여기서 핵심은 바로 '위조(fake)'니까. 위조를 사전에서 찾아보면 '어떤 물건을 속일 목적으로 꾸며 진짜처럼 만듦.'이라 나온다. 코드 작성 과정에서 초롱초롱한 눈망울로 모니터 속에 들어갈 기세로 집중하는 개발자들이 문서를 작성하기만 하면 동공이 풀리고 어깨가 축 늘어지고 줄담배를 피고 웹 서핑을 하며 머리카락을 쥐어 뜯는 이유는 늘 진실되게 대화하는 컴퓨터 프로그래밍 언어와 달리 능숙한 위조를 요구하는 사람 언어로 뭔가를 작성해야 하기 때문이다. 레지스터 값 하나에 목숨을 거는 개발자들에게 위조는 고문 그 자체다. T_T 하지만, 문서를 보는 주체는 컴퓨터가 아니라 사람이므로 당연히 사람에 맞춰야 하며(빌어먹을 인문학!!!!!), 이 과정에서 이상과 현실 사이에 심각한 괴리가 생기기 마련이다.

자 그렇다면 우리가 위조해야 하는 이상화된 형태의 소프트웨어 설계 "프로세스"가 무엇일까? 파나스 큰 형님이 초지 일관 주장하는 모듈화와 관련이 깊다. 요약하자면 요구 사항 명세, 모듈 구조 설계와 문서화, 모듈 인터페이스 설계와 문서화, 'uses' 계층 설계와 문서화, 모듈 내부 구조 설계와 문서화, 프로그램 작성, 유지 보수 순을 따른다. 세부 사항을 여기서 설명할 경우 큰 주제를 흐릴 가능성이 높으므로 다음에 기회가 닿으면 하나씩 소개하기로 하겠다.

여기까지 글을 적고 허무하게 끝내버리면 "사람 약 올리냐!"라고 민원이 빗발칠게 뻔하므로, 다음에 올려드릴 마지막 글에서는 불쌍한 개발자들을 위해 이상화된 설계 문서를 _쉽고 제대로_ '위조'하는 방법을 (지금까지 경험을 곁들여) 정리하겠다.

EOB

[일상다반사] 파워포인트 협업 도구인 Kivo

(이미지는 Kivo (YC S13) uses git to make collaborating on documents easier, starting with PowerPoint에서 가져왔습니다)

지난번 [일상다반사] Schemer: 소셜 TO-DO 리스트를 소개드리면서 아이디어를 떠올리기만 하고 실행에 옮기지 못했던 사례를 들었는데, 독자 여러분들께서 많은 관심을 보여주셨기에 오늘도 이야기 보따리를 하나 풀어놓으려 한다. 역시 작년 초에 회사에서 브레인스토밍을 하다 완전 엉뚱한 서비스를 하나 제안한 적이 있었다. 간략하게 소개하자면, 사람들이 만들어내는 문서의 유사도를 계산해 관련된 문서를 클러스터링하고 차이점 등을 보여주는 서비스였다. 예를 들어, 사내 컴퓨터 여러 대에 'Super프로젝트_제안서_2013_08_15.pptx", 'Super프로젝트_제안서_2013_08_16.pptx", 'Super프로젝트_제안서_2013_08_17.pptx"라는 문서가 흩어져 있으면 이를 자동으로 감지해 "Super프로젝트_제안서"라는 범주를 만들고 여기에 파일 세 개를 집어넣어 연관된 문서나 관련된 문서를 쉽게 찾고 버전을 추적하게 지원하는 도우미라 보면 되겠다. 여기서는 파일 이름의 첫부분이 모두 유사하므로 수동으로도 관리할 수 있다고 생각할지 모르겠지만, 그냥 "프로젝트_제안서.pptx"라고 이름을 붙이거나 앞에 작성자 명을 추가해 "jrogue_프로젝트_제안서_2013_08_15.pptx"라 붙일 경우에도 자동으로 파일들을 연관지을 수 있다면 대박이 아닐까 생각했다. 이번에는 진전이 있어 메타 정보를 뽑아내어 데이터베이스화하고, subversion을 사용해 버전 관리를 하는 아이디어까지 도출되었으나 역시... 상품화의 길은 멀고도 험난하다는 진리만 깨닫고 말았다.

그런데... Kivo라는 서비스를 보고 나서 '아차!'하는 생각이 들었다. 역시 내가 생각하면 남들은 서비스를 한다는 진리가 다시 한번 증명되는 순간이었다. Kivo는 파워포인트 플러그인 형태로 사용자가 특정 문서에 대해 변경한 내용을 git에 올린 다음 이를 남들과 공유하게 만드는 기능을 제공한다. 어차피 협업이 가능한 구글 docs가 있지 않느냐고 반문할지도 모르겠는데, 둘은 작업 흐름이 다르다. 솔직히 제안서 등을 작성할 때, 수십 명이 달라붙어 실시간으로 문서를 편집하지는 않는다(그랬다가는 지옥문이 열릴테니까). 특정 부분을 맡은 사람이 문서를 조각 내어 작성하고, 나중에 취합한 다음에는 일부 관련자들만 공동 작업을 번갈아가며 하게 된다. 하지만 우리가 소스 코드 관리 시스템에서 늘상 목격하는 편리한 작업 이력과 변경 내용 확인 기능을 사용할 수 없으므로 여기저기서 실수/재작업/일부 내용 누락과 같은 문제가 터져나오기 마련이다. Kivo는 파워포인트 페이지 단위로 변경된 이력을 git로 관리해 일목요연하게 보여주며 필요하다면 각 페이지 별로 다른 이력을 적용해(git의 cherry picking 기능이 떠올랐다) 문서를 꾸밀 수도 있다.

물론 아직 제한점이 많다. 현재 파워포인트만 지원하며, 오피스 2007/2010 버전에서만 동작한다(2013 버전에서는 제대로 동작하지 않음을 확인했다). 또한 아직 매킨토시 버전은 출시되지 않았다(조만간 베타 버전이 나올 것 같긴 하다). 워드 버전은 개발 중이라고 하는데, 페이지 단위로 명확하게 변경 내용을 확인할 수 있는 파워포인트와는 달리 목차를 기준으로 변경 내용을 보여줘야 하는 관계상(그렇지 않으면 폰트 크기만 아주 사알짝 변경해도 재앙이 벌어진다. T_T) 구현이 그렇게 쉽지는 않아 보인다. 엑셀 같은 경우에는 보여주는 내용 뿐만 아니라 매크로 등 변경 내용이 더욱 중요하므로 구현 자체가 불가능할지도 모르겠다는 생각도 든다. 하지만 이런 여러 가지 제약에도 불구하고 Kivo의 잠재력은 충분히 커 보인다. 지금까지 DMS(Document Management System)나 KMS(Knowledge Management System)에서는 문서를 다룰 때 문서 전체를 하나의 엔티티로 취급했기에 조밀도가 떨어지고, 위키와 같은 시스템에서는 문서 내부의 변경 내역을 확인하도록 이력 관리를 해주므로 조밀도는 높으나 외부로 공개할 경우 참으로 난감한 상황(Confluence와 같은 기업용 위키조차도 PDF나 doc/docx로 export하는 기능은 낙제에 가깝다)이 벌어지므로 뭔가 다른 획기적인 해법이 필요하다는 사실은 누구나 공감하고 있기 때문이다.

사업적인 측면에서 보면, github나 bitbucket등의 대성공과 마찬가지로 외부로 유출되면 곤란한 기업의 핵심 기밀 문서가 아닌 일반적인 문서인 경우 호스팅 서비스로도 충분한 위력을 발휘할 가능성이 아주 높다. 백업, 이력 관리, 협업, 클라우드 저장소와 같은 핫한 키워드가 모두 따라다니는 데다 마이크로소프트 오피스라는 현존하는 전세계에서 가장 막강한 문서 관리 기반 구조를 등에 업고 있기 때문이다. 오히려 어떤 면에서 오피스 365보다 더 희망적이라는 생각도 해본다. 마이크로소프트가 M&A를 할지도... ㅋㅋ 아직 무료로 서비스하는 상태라 혹시 오피스 2007이나 2010를 사용하는 분들께서 한번 실험해보시기 바란다.

EOB

[일상다반사] '해커스' 출간 소식

여러분들께서 기대하고 고대하던 블록버스터인 Hackers: Heroes of the Computer Revolution - 25th Anniversary Edition 번역서인 '해커스'가 곧 출간된다는 기쁜 소식을 전해드리겠다. 아시는 분은 다 아시겠지만, 한국에서도 1991년 '해커'(상/하), 1996년 '해커 그 광기와 비밀의 기록'이라는 이름으로 이미 두 차례 출간된 적이 있는 이 책은 25주년을 기념해 오라일리에서 새로 출간함으로써 한국에서도 복간의 기회를 얻게 되었다. 거의 500페이지에 달하는 분량(물론 본문에 코드는 단 한 줄도 없다 T_T) 때문에 번역과 편집 시간이 오래 걸린 점을 각별히 양해 부탁드리겠다.

몇 가지 뒷 이야기를 정리해 보겠다. 1970~80년대 캘리포니아를 배경으로 하니 너무나도 당연하겠지만, 19금 수준의 자유분방한 이야기(전사적으로 술판 벌이고, 약빨고, 감옥가고, 포르노 게임 만들고, ... T_T)가 제법 나오지만... 무삭제를 원칙으로 문장 하나 시 한 줄 빼먹지 않고 꼼꼼하게 번역했다. 또한 8비트 컴퓨터는 물론이고 플로피 디스크조차 주변에서 찾기 어려운 관계상, 새로 이 책을 접하는 독자 여러분의 이해를 돕기 위해 본문 곳곳에 편집팀의 도움을 받아 사진과 그림을 추가했다. 마지막으로 옛날 이야기가 너무 옛날 이야기처럼 느껴지지 않도록 역사성과 정확성을 희생하지 않는 범위 내에서 최대한 현대적인 감각으로 번역했으므로(이를 위해 20년전과 15년전에 출간된 기존 번역서는 참고 목적으로도 들여다보지 않았다), 신세대 개발자 여러분들도 무리 없이 읽을 수 있으리라 믿는다.

최근 한국에서 IT 관련해 여러 가지 담론들(인문학, 통섭, 창의력, 조기 교육)이 튀어나오고 있지만, 이 책을 읽는 순간 하나같이 부질없는 허상이라는 사실을 깨닫게 될 것이다. IT 인력을 양성(응?)해 경제 발전(!)에 기여하자는 거창한 구호를 듣고 있으려니, 컴퓨터 세상을 직접 지배하고, 자기 손으로 뭔가를 만들고, 너무나도 재미있어 몰입하고, 남과 함께 공유하는 _자발적인_ 해커 정신이 더더욱 귀중하게 느껴진다. 요즘 너무나도 자연스럽게 세상에 침투한 오픈 소스는 결코 공짜로 얻어진 것이 아니다. 바로 다음과 같은 구호를 부르짓은 선구자 해커들의 투쟁에 의해 얻어진 것이다.

프로그램은 최대한 노출되어야 한다. 왜냐하면 정보는 자유로워야 하며 가속화된 정보의 흐름은 세상을 개선하니까!

무더운 여름, 독자 여러분들도 잠시나마 시원한 해커 세상으로 몰입할 준비가 되었는지? 이미 온라인 서점에서는 예판에 돌입했으니 그동안 절판된 책을 찾아 다니느라 고생하신 분들께서는 지금 바로 뽐뿌질 당하시기 바란다. :)

보너스: 빈꿈님께서 그려주신 삽화

업데이트: 드디어 출간되었습니다. 따끈따끈한 인증샷 추가.

EOB

[B급 프로그래머] 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?

그 동안 불꽃튀는 논쟁이 벌어질만한 내용은 언급을 자제했으나... 무더운 여름을 날려버리기 위해 오늘은 조금 도발적인 주제를 다뤄보도록 하겠다. 파나스 큰 형님이 쓰신 논문인 A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT 의 II번 항목을 번역해봤다.

우리는 "이성적인" 방식으로 전개되는 소프트웨어 프로젝트를 결코 보지 못할 것입니다. 몇 가지 이유를 정리하면 다음과 같습니다.

1. 대부분 소프트웨어 시스템 제작을 의뢰하는 사람들은 정확히 무엇을 원하는지 모르며, 자신들이 알고 있는 내용을 우리에게 말해줄 능력이 부족합니다.
2. 심지어 우리가 요구 사항을 알았다 하더라도, 소프트웨어 설계에 필요한 다른 사항이 존재합니다. 이런 세부 사항은 구현을 진행하는 과정에서만 알게 됩니다. 이렇게 알게된 몇몇 지식은 설계를 무효로 만들어버리므로 설계 단계로 거슬러 올라가야합니다. 잃어버린 작업량을 최소로 줄이려 시도하기에, 결과로 만들어진 설계는 이성적인 설계 프로세스에서 나온 결과와는 거리가 멉니다.
3. 시작하기 전에 모든 관련 사항을 알고 있다하더라도, 경험에 따르면 우리 인간은 올바른 시스템을 설계하고 만들기 위해 반드시 고려해야 하는 엄청난 세부 사항을 완전히 이해할 수 없습니다. 소프트웨어 설계 프로세스는 고려 사항을 분리함으로써 관리 가능한 정보를 사용해 작업하는 과정입니다. 하지만 고려 사항을 분리할 때까지 우리는 필연적으로 오류를 만들어내기 마련입니다.
4. 심지어 필요한 모든 세부 사항을 마스터할 수 있다하더라도 가장 하찮은 프로젝트조차도 외부 원인에 의해 변경될 운명에 처합니다. 몇몇 변경은 직전 설계 결정을 무효로 만듭니다. 이런 결과로 만들어진 설계는 이성적인 설계 프로세스가 생성한 설계와 거리가 멉니다.
5. 사람의 오류는 사람이 개입되지 않아야 피할 수 있습니다. 심지어 고려 사항을 분리한 다음에도 오류가 발생합니다.
6. 우리는 종종 사전에 형성된 설계 아이디어 때문에 부담을 느낍니다. 우리가 고안했던 아이디어, 관련된 프로젝트에서 얻은 아이디어, 수업 시간에 들은 아이디어 말입니다. 종종 좋아하는 아이디어를 사용하거나 시도하려 프로젝트를 맡기도 합니다. 이런 아이디어는 요구 사항에서 이성적인 설계 프로세스를 사용해 유도되지 않았을지도 모릅니다.
7. 종종 경제적인 이유 때문에 다른 프로젝트를 위해 개발한 소프트웨어를 사용하도록 장려합니다. 어떤 상황에서는 진행 중인 다른 프로젝트와 소프트웨어를 공유하도록 장려하기도 합니다. 이런 결과로 만들어진 소프트웨어는 양쪽 프로젝트 어디를 봐도 이성적인 소프트웨어가 아닙니다. 즉, 요구 사항 자체를 기반으로 개발한 소프트웨어가 아니며, 노력을 줄일 목적으로 고만고만하게 만든 소프트웨어입니다.

이런 이유 때문에, 소프트웨어 설계자가 요구 사항으로부터 이성적이고 오류가 없는 방식으로 설계한 그림은 엄청나게 비현실적입니다. 어느 시스템도 이런 이성적인 방식으로 개발되지 않았으며, 아마도 앞으로도 이런 일은 생기지 않을 것입니다. 심지어 교과서나 논문에 나온 작은 프로그램 개발조차도 비현실적입니다. 교과서나 논문에 나온 프로그램은 개선되고 수정되는 과정을 거치면서 저자들이 바라는 바를 보여주지 실제 일어난 과정을 보여주지는 않습니다.

여러분이 진행 중인 소프트웨어 개발 과정을 잠시 상상해보자. 애자일 개발 방법을 논하지 않더라도 고객 요구 사항을 수집하고, 스펙을 만들고, 아키텍처 설계를 마치고, 세부 설계에 들어간 다음 불꽃 코딩을 거치면 위대한 결과물이 톡 튀어 나온다고 생각하는 개발자는 그렇게 많지 않을 것이다. 하지만 구현에 앞서 문서(스펙, 아키텍처, 세부 설계, 뭐든 좋다)를 열과 성을 다해 제대로 작성하지 않았기에 소프트웨어가 엉망진창으로 나온다는 희한한(응?) 주장에는 딱히 반박하지 못했을 것이다. 하지만 정말 그럴까? 우리는 소프트웨어 개발에 앞서 이성적이고 완벽한 문서가 짜잔하고 만들어질 수 있느냐를 놓고 고민할 필요가 있다. 이런 고민이 필요한 이유는 간단하다. 개발자들이 처음부터 완벽한(아니 이성적인) 문서를 만들지 못했다는 죄책감에서 벗어나야 하기 때문이다. 처음부터 완벽한 소프트웨어가 없듯이 처음부터 완벽한 문서도 없다. 그렇다면 이런 상황에서 어떻게 문서를 만들어야 할까? 다음 번에 파나스 큰 형님의 조언을 정리해드리겠다. 조금만 기다리시라. :)

주의: "용감한 프로그래머에게 설계 따윈 필요없으니 코딩으로 바로 뛰어들자!"라는 주장이 아님을 노파심에서 다시 한번 강조한다.

EOB

[독서광] 데이터 접근 패턴

요즘 워낙 많은 책(한국어판, 원서)을 동시에 읽고 있다보니 서평이 뜸했었다. 오늘은 간만에 설계 관련 책을 하나 소개해드리려고 하는데, "데이터베이스와 효율적으로 상호작용하는 25가지 소프트웨어 디자인 패턴"이라는 긴 부제가 붙은 '데이터 접근 패턴'이 주인공이다. 주의 사항을 몇 가지 짚고 넘어가자. 이 책은 2003년도에 원서가 출간되었고 번역서가 2013년에 출간되었기에 10년이라는 공백이 존재한다. 따라서 아주 새롭고 신기한 신기술은 다루지 않는다는 사실을 반드시 인지해야 한다. 또한 요즘 나오는 마이바티스 등 각종 데이터베이스 프레임워크와 ORM과 같은 기술을 소개하지도 않으며, 순수하게 JDBC만으로 모든 예제를 설명하기에 착오없으시기 바란다. 마지막으로 철저하게 관계형 데이터베이스를 중심으로 설명이 진행되므로(일례로 5부는 트랜잭션과 잠금에 대한 내용을 중심으로 구성되어 있다) 요즘 유행하는 NoSQL 관련 내용을 기대하면 안 된다. 이 책을 읽기 위해서는 자바와 JDBC 프로그래밍 기술, 관계형 데이터베이스에 대한 기초 지식, 그리고 (필수는 아니지만) 패턴에 대한 기본적인 이해가 필요하다.

이 책 목차를 보면 1부 '분리 패턴'에서는 데이터 접근 코드와 비즈니스 논리를 구분하는 방법을 소개한다. 2부 '리소스 패턴'에서는 데이터베이스 프로그램에서 사용하는 여러 가지 리소스를 격리하는 방법을 소개한다. 3부 '입출력 패턴'에서는 관계형 데이터의 물리 형태와 도메인 객체 표현을 분리하는 방법으로 데이터 입출력 연산을 단순화하는 방법을 소개한다. 4부 '캐시 패턴'에서는 물리적인 데이터베이스 접근을 최소화하는 다양한 캐시 전략과 구성 요소를 설명한다. 마지막으로 5부 '동시 실행 패턴'에서는 동시에 데이터에 접근이 일어날 경우 발생하는 문제점을 해결하기 위해 트랜잭션과 잠금을 설명한다. 목차를 보면 알겠지만 요즘 나오는 데이터베이스 프레임워크가 여러분을 위해 뒤에서 열심히 서비스하는 내용을 어떤 이론에 기반해 어떻게 설계하고 구현할지를 다룬다고 보면 틀림없겠다. 물론 어디까지나 설명을 위한 설계와 예제이므로 실전에서는 한계가 분명히 존재하며, 이 책에 나온 코드를 그대로 사용할 수 있으리라는 기대는 접기 바란다.

그렇다면 이 책은 어떤 독자를 대상으로 할까? 우선 기본 데이터베이스 프레임워크를 분석하거나 아예 필요에 딱 맞춰 새로 만들려는 개발자들이 참고할만하다. (어차피 이런 부류의 경쟁서가 아예 없으므로) 완벽하지는 않지만 출발점으로는 좋아보인다. 다음으로 데이터베이스를 많이 다루는 엔터프라이즈 애플리케이션 설계에 관심이 있는 설계자들이 참고할만하다. 특히 캐시 패턴과 동시 실행 패턴은 기초 이론에 대한 설명과 실제 예제가 함께 등장하므로 구체적인 기반 위에서 설계를 진행할 수 있게 도와준다. 마지막으로 (어떤 사정상) 어쩔 수 없이... JDBC 만으로 프로그램을 만드는 프로그래머에게 도움을 준다. "요즘 누가 JDBC로 날 코딩을 하지?"라고 의문이 생기는 분들도 계시겠지만... 뭐 사정상 필요한 경우가 있기 마련이다(예: B급 프로그래머. T_T).

번역 상태를 보자. 이런 부류의 서적에서 필연적으로 다가오는 '용어' 문제는 누가 번역하더라도 풀지 못할 난제이므로 책의 가장 뒷편에 나오는 용어 정리 항목을 먼저 읽어 머리 속에 한글단어-영어단어-개념이라는 해시맵을 만들고 나서 시작해야 할 것이다. 만일 이런 indirection 과정을 참지 못하거나 용어에 민감해 신경질이 나는 독자라면 번역서 대신 원서를 강력하게 추천한다. 비문이 조금씩 눈에 띄고 직역이 많긴 하지만 다행스럽게도 이해하는 과정에서 큰 어려움은 없었다. 코드에 잘못된 문자가 들어가거나 띄어쓰기가 이상하거나 하는 경우가 있긴 했지만, 실시간으로 고쳐서 읽을 수 있는 수준이었다. 시간 절약을 위해 원서 대신 번역서를 읽어도 무방하다는 생각이다.

결론: 아주 새로운 내용은 없지만 기초를 잘 설명하고 있으므로 데이터베이스 애플리케이션과 관련해 설계와 구현에 관심이 있는 독자분께 추천드린다.

EOB

[일상다반사] Schemer: 소셜 TO-DO 리스트

작년 초인가 회사에서 브레인스토밍을 하다 완전 엉뚱한 서비스를 하나 제안한 적이 있었다. 간략하게 소개하자면, 일정표에 내가 뭔가를 기록하면 이에 따라 영감을 주는 다른 활동들이나 제안을 해주는 서비스였다. 예를 들어, '생일'이라 입력하면 선물 목록을 제시한다거나 '휴가'라 입력하면 가볼만한 곳을 알려주는 등 나름 인공 지능적인 특성으로 사용자의 의사 결정에 도움을 주는 비서라고 보면 되겠다. 하지만 늘 그렇듯 너무나도 막연한 아이디어라 현실로 옮기지는 못했다. 그리고는 바쁜 일상에 파묻혀 아이디어를 완전 잊어버리고 있었다.

그런데... 스키머라는 서비스를 보고 나서 '아차!'하는 생각이 들었다. 내가 생각한 내용을 이미 다른 사람이 만들고 있다고 생각하면 틀림없는데, 이번에도 이 법칙이 정확하게 맞아떨어진 순간이었다. 영어 사전에서 scheme을 찾아보면 '계획, 제도'라는 뜻이 있다. 딱 한 문장으로 요약하자면 스키머는 소셜 할 일 목록 정리기라고 보면 되는데, 기존의 다른 할 일 목록 서비스와 차별화하기 위해 구글 플러스와 연계해 남들이 하는 작업을 공유(응?)할 수 있게 만들어 놓았다. '소셜'과 '할 일 목록'이라는 어울리지 않는 두 단어를 보며 사생활 침해와 관련해 걱정이 들지도 모르겠는데, 이미 우리는 포스퀘어로 동선을 인터넷에 남기고 페북에 사진을 남기고 태깅을 하고 트위터로 별 시시콜콜한 이야기를 다 올리는 세상에 살고 있다. T_T

요렇게 설명하고 보니 도대체 무슨 서비스인지 감이 잘 오지 않을 것이다. 따라서 실제 예를 드는 편이 좋을 것 같다. 스킴은 크게 두 가지 방식으로 사용자의 할 일을 넛지해준다. 하나는 미리 정의된 태그로 식당, 영화, 책, 패션, TV, 요리, 휴가 등의 활동에 대해 다른 사람들이 무엇을 하는지 훔쳐(!)볼 수 있다. 다른 하나는 검색어를 입력해 다른 사람들이 많이 계획한 활동을 훔쳐볼 수 있다. 예를 들어, 영화를 보기 위해 'movie'라고 입력한 순간 다른 사람들이 입력한 내용이 목록으로 나온다. 여기서 선택하면 몇 명이 이 계획을 시작했는지, 몇 명이 성공리에 이 계획을 마무리했는지 숫자로 된 통계를 볼 수 있다. 해당 목록을 선택하면 시작한 무리에 속하게 되며, 계획을 마무리하고 나서 'done' 버튼을 콕 찍어주면 완료한 무리에 속하게 된다. 해당 계획이 얼마나 난이도가 높은지를 직접 확인할 수 있는 셈이다.

할 일 정하기와 검색 이외 나머지 다른 기능은 딱히 없다(아직까지는 나의 계획을 확인하고 남들이 성취한 업적을 보는 정도가 끝이다). 기능만 놓고 보면 별 거 아닌 서비스처럼 느껴질지도 모르겠지만 잠재력은 충분히 있어 보인다. 특히 사업 모델로 확장 가능한 플랫폼 형태라는 사실이 중요하다. 스키머에 처음 가입할 때 지역을 입력하라고 나오는데, 지역 기반 서비스와 연계하기 위한 기초 자료 수집으로 보인다. 이 정보를 이용해 'Pizza'라 입력했을 때 서비스 제휴를 맺은 가맹점의 전화나 위치가 할 일 목록에 나오거나 'Movie'라 입력했을 때 서비스 제휴를 맺은 근처 영화관 상영 시간표와 남은 좌석 수가 나오면 대박이 아닐 수 없다. 물론 아직 한국어 서비스는 지원하지 않으므로(지금은 한글로 계획을 입력할 경우 아무런 힌트도 주지 않는다) 적어도 한국에서는 머나먼 미래지만 미국에서는 현실이라고 보면 되겠다. 물론 장애물도 존재한다. 매번 상업 광고만 나올 경우 쉽게 식상해지므로 꾸준히 우연을 맛볼 수 있는 사용자의 집단 지성 풀이 구축되어야 하는데, 사용자가 많아야 광고(?)주가 붙으며, 광고주가 붙어야 체리피커들도 많아질테니 닭이 먼저냐 달걀이 먼저냐 하는 문제에 바로 부딪힐 것 같다.

스키머가 그저 그런 또 하나의 할 일 목록 서비스로 조용히 묻힐지 아니면 구글의 각종 서비스를 등에 업고 무럭무럭 커나갈지는 사용자의 참여 수준에 달린 것 같다. 하지만 기존 구글의 지나온 발자취를 보면 성공할 가능성이 아주 높아 보이지는 않는다.

EOB

[B급 프로그래머] hg/git 클라이언트인 SourceTree

예전에는 DVCS(분산 버전 관리 시스템)이 없는 세상에서 어떻게 개발을 진행했는지 모를 정도로 급속도로 git와 hg(mercurial)이 개발자들 사이에서 일반화되는 추세다. 물론 여전히 CVS나 subversion을 사용하시는 분들을 위해 얼른 DVCS의 세상을 접할 수 있도록 오늘은 SourceTree라는 무료(라이선스를 받기 위한 등록은 필요하다) 클라이언트를 하나 소개해드리겠다.

SourceTree는 기업용 위키인 Confluence와 기업용 이슈 추적 시스템인 JIRA로 유명한 Atlassian이 자사의 DVCS 호스팅 서비스인 Bitbucket과 자연스럽게 연동할 목적으로 배포한 git/hg 클라이언트다. 원래 맥OS X용만 있었는데, 윈도우로 이식되었기에 기존에 유명한 거북이(Tortoise) 시리즈를 사용하던 분들이라면 대체품으로 고려할만하다. Bitbucket을 사용하시는 분들이라면 clone할 때 다음 윈도우가 뜨는데 아래쪽 버튼(Clone in SourceTree)을 콕 누르면 바로 SourceTree를 사용해 클론 작업을 수행한다. 또한 git와 hg를 동시에 지원하기 때문에 git와 hg를 혼합해서 산출물을 관리해야 하는 프로젝트에서 특히 위력을 발휘한다.

원래 소스코드 관리 client는 개발자의 호불호가 확실히 갈리는 특성이 있어 사람마다 평가는 다르겠지만, 개인적으로는 만족하는 편이다. 기존 Tortoise의 셸 확장 방식을 선호하는 분들이라면 단독형으로 동작하는 SourceTree가 조금 불편하게 느껴질지도 모르겠다. 변경되었거나 새로 추가한 파일에 대한 관리는 큰 문제 없지만 전체 파일을 보면서 뭔가를 할 경우에는 답답할지도 모르겠다. 그리고 hg와 git를 사용자 인터페이스 변경 없이 함께 사용하려다보니 아무래도 기능이 적은 hg보다는 git 쪽이 완성도가 떨어지는 느낌이다(git에서는 복잡한 기능이 필요할 때 Terminal 버튼을 눌러 명령행에 의존해야 한다). 하지만 점차 개선되리라 믿는다.

SourceTree에서 개발자를 위해 마련한 선물 중에 가장 푸짐한 항목은 바로 git flow 지원이다(세부 설명은 A successful Git branching model과 한국어 번역을 참조하기 바란다). DVCS를 사용하다보면 브랜치 전략에 대해 고민을 하지 않을 수 없는데, 매번 바퀴를 발명하기가 곤란하니 개발자들이 아예 고정된 형태의 우수 사례를 수립하기 시작했고, 기능에 따른 브랜치와는 달리 개발/배포에 주안점을 둔 상위 단계의 브랜치 전략이 업계 표준으로 받아들여지기 시작했다. git flow는 브랜치마다 특정 역할을 할당하고 상호 작용하는 방식과 시점을 정의하며, 배포를 준비하고 관리하고 기록할 목적으로 개별 브랜치를 활용한다. 수작업으로 이런 정책을 따라가도 좋지만 반복적인 작업에 시간도 낭비되고 실수할 가능성도 높기 때문에 SourceTree에서는 아예 상단에 큼지막한 'Git Flow'라는 아이콘을 제공해 개발자가 손쉽게 git flow를 쫓아가도록 지원한다. 물론 SourceTree는 git flow의 자매품인 hg flow 기능도 제공하므로 git에 비해 상대적으로 브랜치 우수 사례가 정립되지 못한 hg 세상의 개발자들에게도 도움을 줄 것이다.

하지만 어디까지나 도구는 도구이므로, SourceTree를 사용한다고 해서 저절로 git나 hg의 복잡성이 해결되지는 않는다. 심지어 SourceTree와 hg에 익숙한 개발자들도 도구는 그대로 DVCS만 바뀐 git 세상에서는 매트릭트에서 기차역을 해매는 네오처럼 멘붕에 빠질 수 있으므로 기반 git 철학에 대해 파고들 필요가 있다. hg는 이미 [독서광] Mercurial: The Definitive Guide에서 소개를 드렸기에, 후속편으로 8월 중에는 git 서적 한 권을 소개해드리도록 하겠다.

결론: 지금까지 익숙했던 SVN는 잊어버리시고 hg가 되었든 git가 되었든 DVCS라는 신세계로 오시기 바랍니다. 지금까지 hg에 조금 익숙해질만 하니 다시 git로 넘어가느라 좌충우돌하고 있는 B급 프로그래머였습니다. ;)

EOB