A.J.Kuhn, Endless supply of passion!

序.
소프트웨어의 버전관리를 위한 여러 소프트웨어가 존재하고, 이들의 기능은 충분할 정도로 강력하다. 하지만 버전관리는 어떤 버전관리 시스템을 이용하느냐(What) 보다, 어떻게 사용하는가(How)가 중요한데, 실제적으로 이에 관한 논의는 부족해 보인다.

오로지 trunk에다가 commit/update를 반복하고만 있지는 않은가? 대부분의 프로젝트들이 이런식으로 진행되는 것이 현실이다.

버전관리 방안은 프로젝트 내에서 개발자 전체가 공통으로 지켜야만 의미가 있으며, 그렇지 않을 경우 되려 프로젝트에 방해가 될 수 있다. 때문에 룰이 너무 복잡하지 않은... 모두가 따를만한 실용적인 방안을 제안하고자 한다.(Subversion 기준)

1. Glossary
* SVN : 버전관리 시스템 Subversion의 약자
* revision : Subversion의 버전번호. 하나의 commit때마다 1씩 증가됨
* trunk : 관습적으로 Subversion에서 버전의 줄기 이름이자 디렉토리 이름으로 사용됨
* branch : 버전의 가지를 의미하며, 보통 주요 릴리즈마다 생성됨 각 릴리즈에서의 버그패치는 여기서 이루어짐
* tag : 의미있는 특정revision에 부여하게 되며, 보통 특정tag의 소스는 변경하지 않는 것이 원칙
* RB : Release Branch의 약자. 배포용 branch이름의 prefix로 흔히 쓰인다.
* REL : Release의 약자, 배포용 tag이름의 prefix로 흔히 쓰인다.
* BUG : 버그수정용 branch이름의 prefix로 흔히 쓰인다.
* PRE : 버그수정이전 tag의 prefix로 흔히 쓰인다.
* POST : 버그수정이후 tag의 prefix로 흔히 쓰인다.
* TRY : 실험적인 용도의 branch의 prefix로 흔히 쓰인다.

2. 방안
프레임워크에 관한 관리방안과, 서비스/어플리케이션에 대한 관리방안을 별도로 가져갈것을 제안한다.

2.1. 공통사항
* branch와 tag생성시는 모든 개발자가 commit을 완료한 후에 이루어져야 한다. 따라서 생성시에는 모든 개발자에게 통보/합의 되어야 한다.
* tag에서는 절대 변경을 가하여선 안된다.
* branch와 tag명은 명명 규칙을 반드시 지킨다.
  RB, REL, BUG, PRE, POST, TRY
* RB(branch), REL(tag)는 반드시 생성시키되, 각각의 룰을 따른다. BUG/PRE/POST/TRY는 권장하지 않으며, 반드시 필요할 때만 생성한다.(숫자를 줄이기 위해서 이다)
* 개발자들의 trunk/branch/tag 작업본은 동일한 디렉토리 구조로 받도록 권장한다.
* 외부 모듈은 바이너리형태로 버전관리하는 것을 원칙으로 한다.
* Branch의 생성시에는 반드시 tag도 생성한다.

2.2. Framework
* Framework는 반드시 충분히 테스트 된 후 릴리즈 tag를 생성해야 한다.
* 중대한 변화(클래스 대량추가등), 혹은 하위호환이 깨지는 변경이 일어나기 직전에 반드시 branch를 생성한다.
* 반드시 tag버전으로 타 Application에 binary를 배포한다.
* 릴리즈 tag 생성 후, 하루 이 내에 반드시 trunk에 병합한다.

2.3. Application/Service
* 신규 서비스의 사내오픈 직전에 반드시 branch를 생성한다.
* 서비스 개편에 따른 사내오픈 직전에 반드시 branch를 생성한다.
* 상용서버에 Deploy직전에는 반드시 tag를 생성한다.(사내오픈/상용오픈 모두).
* 사내오픈 후에는 당분간 branch만 가지고 작업하고. 상용오픈의 안정성을 확인 한 후 병합한다.

3. 시나리오
* 3개월 전 REL-1.1을 배포하여 이상없이 서비스 중... 현재는 trunk에서 차기버전을 개발 중이다.
* 현재 서비스중인 서비스에 작은 기능의 추가 요구사항이 있어 RB-1.0에서 기능을 개발하여 REL-1.1.1을 배포함.
* 배포 후 1시간 만에 갑자기 서비스가 Hang되는 상황이 발생하여 긴급히 REL-1.1을 다시 배포하여 서비스 재개
* REL-1.1.1에서 치명적인 버그를 발견하여 이를 수정하고 REL-1.1.2 를 다시 배포
* 서비스 안정을 확인 후 REL-1.1과 REL-1.1.2사이의 변화내용을 trunk에 병합

終.
브랜치와 태그를 깊게 활용하되 그 룰을 최대한 간략화한 제안이다. 버전관리로 얻을수 있는 득과 실행(실천)가능성 사이의 고민의 산물이다. 절대적인 방안은 아니므로 프로젝트별로 현실에 맞게 적절히 응용해도 좋을 듯 하다.

소셜 웹 기획 카테고리 컴퓨터/IT 지은이 조슈아 포터 (인사이트, 2008년) 상세보기

처음 읽고 나서는 내용에 불만이 많았다.
알려진 사실들만을 나열하고 있지 않나 하는 실망감이 있었다.
하지만 곰곰히 생각해보니 알려진 사실들을 잘 정리해 주는것도 책의 의미로써 충분한 것이 아닌가!
이 책은 '잘 정리해 준'수준은 충분히 된다.

책의 전개는 소설로 치면 순차적 시간전개다.
최초접속~가입~활동~활발한활동 에 이르는 각 단계에서 사용자들을 다음 단계로 이끌기 위한 구체적인 액션플랜을 제시한다. 결국 이전 단계의 기획이 훌륭해야 다음 단계로의 이행이 가능해 지는 것이다.
이러한 웹 기획(책에서 정의한 '소셜 웹'에 따르면 사실 세상의 거의 모든 웹들이 '소셜 웹'이니 굳이 '웹'과 '소셜 웹'을 구분할 필요는 없겠다)요소들을 구체적으로 자신있게 제안하는데, 사실 소셜서비스라 해도 유형에 따라 각기 다른 정책이 필요할 것같은데 너무 자.신.있.게. 일갈하지 않았나도 싶다. 뭐.. 딱히 웹 기획에 대한 통찰이 없는 상태라면, 그대로 따라보는것도 좋을 듯 하다. 

* TV시대가 인류역사상 유일한 단방향 소통시대였다는 통찰
* 소셜서비스의 '매개체'에 주목한점
* 깔때기 분석이라는 (비교적 꽤)정량적 측정방식을 (내게)소개해준 것
등이 이 책에 대한 긍정적 평가를 갖게 했다.

이모셔널 디자인 카테고리 예술/대중문화 지은이 Donald A. Norman (학지사, 2006년) 상세보기

UXD계의 구루가 썼다하여 기대가 컸던 책...

이 책은 100여 페이지 남짓 되는 Part 1. 만을 읽어도 얻고자하는 지식의 대부분을 얻을 수 있다. 나머지 내용들은 부차적인 설명이거나 주제로 부터 한참은 유리되어 있다.

아래의 세 가지 유형의 디자인의 차이를 이해시키는 것이 이 책의 주제이다.

* 본능적디자인 : 한눈에 이쁘다고 느끼는 디자인
* 행동적디자인 : 사용해보면 편리한 디자인
* 반성적디자인 : 개인별로 각기 다른 경험을 회고시켜주는 디자인

나에게 있어 이 책이 상기시키는 단 하나의 단어를 꼽으라면 '졸리움'이다. 잠자리에서 두페이지만 읽으면 견딜수 없이 졸음이 몰려온다. 덕분에 한동안 잠자리가 두렵지 않았다(약간 수면장애가 있는편이다).