Extremely Agile

각설하고, 이 시스템을 백업하는 방법은 두 가지가 있습니다. (1) 어려운 방법 (2) 쉬운 방법. ㅋㅋ (There are two different methods for backing up the bitnami redmine stack. First one is more difficult than the second.)

어려운 방법은 Redmine 데이터베이스와 Redmine에 등록된 파일을 함께 백업하는 것이죠. 다음의 절차를 따릅니다. (Windows 기준으로) (The more difficult one is to backup Redmine DBMS and files that Redmine users registered. I will explain the procedure for Windows systems.)  

1. 모든 프로그램 -> Bitnami Redmine Stack -> Use Bitnami Redmine Stack (First, go to Start -> All Programs -> Bitnami Redmine Stack -> Use Bitnami Redmine Stack.)

이렇게 하면 화면에 콘솔 창이 하나 뜹니다. Redmine 이용과 관계된 모든 path 설정이 마쳐진 상태이므로, 가급적 이 창을 열어서 관리 작업을 수행하도록 하는 것이 좋죠. (Then, a console window will appear which is ready-to-go for Redmine administrations. All the environment variables are correctly set.)

2. DBMS 백업. 다음과 같이 합니다. (Then, do the DBMS backup just as follows.)

mysqldump -u root -p bitnami_redmine > redmine_backup.sql

패스워드를 물어볼텐데, BItnami Redmine 스택 설치할 때 입력했던 사용자 패스워드를 사용하면 됩니다. (If mysqldump prompts for password, input the user password that you have entered when you were installing the Bitnami Redmine stack.)

3. C:\Program Files\Bitnami Redmine Stack\apps\redmine\ 디렉터리로 이동 (After that, go to C:\Program Files\Bitnami Redmine Stack\apps\redmine\ directory.)

4. files 디렉터리 안에 있는 내용을 통째로 백업해 둠 (Backup all the files within the directory.)

이렇게 어렵게 백업한 파일을 복원할 때는 다음과 같이 합니다. 역시 아까 썼던 콘솔창을 활용하죠. (To restore the system status using the backup files, just do as follows.)

mysql -u root -p bitnami_redmine < redmine_backup.sql

그런 다음 아까 복사해뒀던 files 디렉터리 밑의 파일들을 원래 위치로 되돌려 놓습니다. 그런 다음 Bitnami Redmine 서비스들을 재시작하면 복원이 완료되죠. (Then, put all the copied files to their original location. After that, restart all the Bitnami Redmine services. That's it.)

그런데 백업 후 복원 이전에 시스템을 재설치한다거나 하면 Redmine 서비스 재시작 후에 Method가 missing 되었다면서 정상적으로 실행되지 않는 경우가 있습니다. 원인은 DBMS 마이그레이션이 올바르게 되지 않아서인데요. C:\Program Files\Bitnami Redmine Stack\apps\redmine 디렉터리에 가서 rake db:migrate RAILS_ENV=production 이라고 해 주면 DBMS 마이그레이션이 끝나면서 해결됩니다. (But, there might be a case that the Redmine stack, precisely, the underlying Rails system, complains that there are missing methods after the restart. The reason is that DBMS is not correctly migrated. To solve this problem, go to C:\Program Files\Bitnami Redmine Stack\apps\redmine\. And enter rake db:migrate RAILS_ENV=production. That will solve the problem.)

좀 더 쉬운 백업 방법은 C:\Program Files\Bitnami Redmine Stack\ 디렉터리를 통째로 백업하는 것이죠. (The easist way of backing up the Bitnami Redmine Stack is to backup the install directory as-is.) 

Bitnami Redmine Stack 1.2.0 기준으로 봤을 때, Gmail을 통한 메일 알림 설정은 다음과 같이 하면 됩니다. C:\Program Files\Bitnami Redmine Stack\apps\redmine\config\email.yml의 마지막 부분을 다음과 같이 고치면 OK. (Gmail-based email notification setup for BItnami Redmine 1.2.0 stack is done by modifing the C:\Program Files\Bitnami Redmine Stack\apps\redmine\config\email.yml file as follows.)

production:
   delivery_method: :smtp
   smtp_settings:
     enable_starttls_auto: true
     tls: true
     address: "smtp.gmail.com"
     port: 587
     domain: "smtp.gmail.com" # 'your.domain.com' for GoogleApps
     authentication: :plain
     user_name: "your_gmail_id@gmail.com"
     password: "your_gmail_pw"

development:
   delivery_method: :smtp
   smtp_settings:
     enable_starttls_auto: true
     tls: true
     address: "smtp.gmail.com"
     port: 587
     domain: "smtp.gmail.com" # 'your.domain.com' for GoogleApps
     authentication: :plain
     user_name: your_gmail_id@gmail.com
     password: "your_gmail_pw"

다른 버전의 Redmine 에서는 좀 다를 수 있으니 조심하세요. Gmail을 써서 email 공지가 날아가도록 하면 속도가 좀 느리다는 문제도 있습니다. (The detail of the configuration might differ by Redmine versions. Using gmail, you might suffer from delay: Gmail SMTP does not respond fast to your request.)
 

파워포인트와 키노트 둘 다 분명히 훌륭한 프로그램입니다. 그리고 대부분 기능은 엇비슷합니다. 아무래도 같은 일을 하는 프로그램이니까요. 그런데 세부사항으로 들어가면 파워포인트에서 좀 더 편리한 기능이 있고, 키노트에서 좀 더 편리하게 쓸 수 있는 기능이 있죠. 오늘은 그런 기능 중 하나에 대해 이야기해 보려고 하는데요. 

키노트에서 좀 더 편리한 기능 중 하나는, 도형에 그림을 채우는 기능입니다. 엄밀하게 이야기하자면 파워포인트에 있는 도형에 그림 채우기 기능이나 키노트에 있는 도형에 그림 채우기 기능이나 똑같긴 합니다. 그런데 키노트에는 하나의 기능이 더 있죠. '마스크' 기능입니다. 

마스크 기능을 어떻게 쓰는지 예를 좀 보시면...

 
일단 이렇게 슬라이드에 그림을 끌어다 놓습니다. (보통은 도형을 먼저 놓는데, 마스크 편집의 경우에는 그 반대죠.) 그리고 그 상태에서 상단의 "마스크" 버튼을 누릅니다. 이렇게 생긴 버튼입니다.

그러면 그림이 이렇게 변할겁니다. 

아래쪽에 마스크 편집이라는 버튼이 붙어있는 다이얼로그 박스도 하나 뜨는데 그건 캡처가 안되네요. 그런데 마스크 버튼을 누르면 사각형 마스크밖에 지정할 수가 없거든요. 다른 도형으로 마스크를 하고 싶으시다면 위쪽의 "마스크" 버튼을 다시 누르세요. 아마 "마스크 취소"로 이름이 바뀌어 있을 겁니다. 취소를 하셨다면, 메뉴에서 포멧->도형으로 마스크->별을 선택해 봅시다. 그림이 다음과 같이 바뀔 거에요.

이 사진은 캡처가 제대로 됐군요. 이 때 밝게 보이는 도형 영역이 화면에 실제로 마스킹되어 나타나게 될 부분이구요. 흐리게 음영처리된 부분이 해당 "마스크 영역" 뒤에 있는 그림입니다. 이 상태에서 그림 부분을 드래그 하면 별 안에 그림 어느 부분이 보이게 할 지 편하게 조정할 수 있구요. 그 아래 "마스크 편집" 다이얼로그 박스의 슬라이드 바를 왼쪽에서 오른쪽으로 움직이면 배율을 조정할 수도 있습니다. 적당히 조정하고 "마스크 편집" 버튼을 누르면...

이렇게 되구요. 이 상태에서 "마스크 편집" 버튼을 다시 누르면 그 윗 그림 상태로 다시 돌아갑니다만, 그림 영역 바깥 아무데나 클릭하면...

이렇게 되면서 편집이 종료됩니다. 굉장히 편리하죠. 하지만 문제는 지원하는 도형이 다채롭지가 않아서 좀 복잡한 도형을 이용할라치면 일일이 그려야 한다는 거... ㅎㅎ (그 부분은 파워포인트가 좋습니다.)

좀 더 꼼꼼한 메뉴얼이 필요하신 분은 이곳으로! http://evileye.tistory.com/1
 

SNMP MIB 파일이 없어도 그  세부사항을 살펴볼 수 있고, 어떤 항목들이 있으며 그 항목들 각각의 의미가 무엇인지 알고 싶다면? SIMPLEWEB 사이트를 방문해 보는 것이 좋을 듯. http://www.simpleweb.org/

웹사이트를 방문하면 좌측에 MIBs라는 메뉴가 있다. 이 메뉴를 클릭하면 다음과 같은 화면을 볼 수 있다.

 

 여기서 원하는 MIB을 선택하면 된다. 모든 MIB이 다 있는 건 아닐테지만, 중요 표준 MIB은 빠짐없이 볼 수 있다. 다음과 같이 표시된다.

MIB 항목 가운데 mplsTunnelRerouted 를 선택한 화면이다. 해당 MIB 항목의 의미를 description 필드 값을 통해서 자세히 확인할 수 있다.


 

http://ringblog.net/1934 그만님 블로그에서도 다루고 있는 주제지만, 카카오톡이 유발하는 keep-alive 성 트래픽이 단단히 문제가 되고 있는 모양. 특히 카카오톡 서버가 재부팅 되거나 재배치되는 경우에 증상이 심화되는 듯.

망 중립성 이야기도 나오는데, 아무래도 망이 좀 더 지능화 되어 '카카오톡 오버레이(overlay)' 같은 게 제공되지 않는 한 근본적인 해결은 어려울 듯. 그렇게 되면 카카오톡 회사는 타인의 트래픽을 침해하지 않는 선에서 ISP (Internet Service Provider)로부터 오버레이 회선을 구매하고, 그 오버레이 회선으로만 자사의 트래픽을 유통시킬 수 있을 것이다. 물론 그런 회선에 완벽한 QoS를 구현할 수 있고, 다른 사람들의 트래픽은 침해하지 않는다는 가정 하에서.

인터넷을 통한 '가상 회선별 QoS' 이야기는 NGN(Next Generation Network)이야기 나오면서 가장 크게 대두되었던 화두 중 하나인데 아직까지도 뾰족한 해결책이 없고, 그럼에도 사람들은 벌써 NGN을 넘어 '미래 인터넷' 이야기를 하고 있다.

사람들이 벌써부터 '미래 인터넷' 이야기를 하는 것은 아마 '현존하는 IP 프레임워크 위에서' 인터넷의 모든 문제를 해결하기가 굉장히 곤란해 보이기 때문인 듯. (이렇게 저렇게 다 해봤는데 안되더라 하는 게 가장 큰 이유일 것인데...)

사실 인터넷은 이미 '범 지구적인 인프라'가 되어 있지만, 아무도 그 인프라가 '정말로 안전한지', '정말로 예측가능한지' 모른다는 문제를 가지고 있다. 사실 이런 문제를 가지고 있는 인프라는 인프라로 불러서는 안된다. 왜냐? 인프라는 공공재적 성격이 크기 때문이다. 상수도도 인프라라고 부를 수 있고, 하수도, 전력 공급 시설 전부 인프라라고 부를 수 있다. 그런데 그런 인프라들은 예측 가능하다. 어떤 장애가 생겼을 때 어떻게 동작하게 될지, 예측이 가능하단 소리. 그래야 그 공공재에 기반하여 생활하는 사람의 삶의 질을 보장할 수 있다.

그런데 인터넷은 그렇지 않다. 웜 바이러스가 뿌려졌을 때 인터넷에 무슨 일이 벌어졌는지 아마 모두들 기억하시리라. 이런 건 인프라가 아니다.

카카오톡 사태에서도 볼 수 있듯이, 우리는 인프라가 아닌 '무언가' 위에 '우리 삶을 해피하게 해 줄' 뭔가를 만들려고 한다. 그러다 보니, '무언가'를 만드는 사람도 그렇고 '해피하게 해 줄 뭔가'를 만드는 사람도 그렇고, 전혀 해피하지가 않다. 

이 사태가 원천적으로 해결되려면 우리가 쓰는 인터넷이 좀 더 예측 가능하게 바뀌어야 한다. 예측 가능한 인터넷은 선언적(declarative) 기술에 기반한 것이어야 하고, 증명 가능(provable)해야 한다. 현재 인터넷 기술을 구성하는 요소 중 많은 것들은 증명에 기반한 것도 아니고, 선언적이지도 않다. 프로그래밍 언어적으로 이야기하자면, 절차적이다. 그냥 그렇게 하니까 돌아가던데? 라는 말 쪽에 좀 더 가깝다. 

우리는 인터넷이 갖고 있는 이 '원천적인' 문제가 빨리 해결되기를 소망한다. 그러기 위해서는 인터넷을 설계하는 사람이나 그 위에서 돌아가는 뭔가를 만드는 사람들이 머리를 맞대고 함께 고민해야 한다. 대한민국은 세계 No.1 인터넷 강국이라서 그런 연구 하기 걸맞다.

그런데 대한민국에서 인터넷의 문제를 원천적으로 해결할 솔루션이 나오지 않는다면?

그건 아마 대한민국이 그런 일 하기에 썩 적합하지 않아서 일지도 모른다.
 

회사 메일 계정을 IMAP으로 연결해서 확인하는데, 두 프로그램을 놓고 비교해보면 다음과 같은 결론을 내릴 수 있다.

1. 성능은 Mail이 우세
2. SNS를 포함하는 편의성은 Outlook이 우세

Outlook에서는 메일과 연동하는 일정 기능을 활용할 수 있는데, 이게 굉장히 강력하다. 일정을 잊지 않게 관리한다는 측면에서 보면 Outlook이 좋고, SNS와의 연동이나 주소록 관리, 이런 부가 기능적인 측면에서 보더라도 확실히 Outlook은 굉장한 프로그램이다. (기능이 너무 많아서 느린 걸지도 모른다.)

특히 최근에 강화된 SNS 관련 기능을 순서대로 살펴보면...(소셜 커넥터라고 함)

특정한 메일을 클릭하면 화면 우측 하단에 그 사람의 Social Identity를 추적하는 이런 아이콘이 뜨는데. 얼핏 보면 아바타 같기도 하다.

추가 버튼을 누르면, 이런 화면이 뜬다. 아직 내 계정이 어떤 SNS에도 연결되어 있지 않다는 뜻. "온라인으로 사용할 수 있는 소셜 네트워크 공급자 보기"를 클릭한다.

나에게는 Facebook 계정이 있다. 그러므로 Facebook 아이콘을 클릭한다.

다운로드 화면이 뜬다. "한국어"를 선택한 뒤에 변경 버튼을 눌러야 위와 같이 ko-kr에 대한 다운로드 링크가 뜬다.

위와 같은 화면을 그대로 보게되었다면, 설치가 잘 되었다는 뜻. 설치하고 나서 원래 화면으로 돌아가 보면, 다음과 같이 바뀌어 있을 것이다. 바뀌어 있지 않다면 창을 닫고 다시 띄울 것.

이제 공급자 가운데 Facebook을 선택하고 내 계정을 연결한다. 아래와 같이 연결된다.

이렇게 연결하고 나면, 메일을 보낸 상대방이 Facebook 계정을 가지고 있는 경우, 그 계정을 나와 연결하면 (Facebook에선 친구등록) 메일 보낸 상대방이 Facebook에 무슨 포스팅을 했는지까지 다음과 같이 확인할 수 있게 된다.

 

이렇게 좋은 기능들이 풍부한데도, IMAP 프로토콜에 이르면, 어쩐지 좀 불안정하다는 느낌이 든다. 특히 메일을 삭제하다보면, 중도에 IMAP 프로토콜 관련 오류 메시지가 뜨는 경우가 많다. (나중에 확인해 보면 메일은 분명히 지워져 있다.)

그럼 나는 POP를 써도 되는데 왜 IMAP을 고집하나?, 왜 그런건지 정확히 모르겠지만 POP에 '서버에 메일 남겨두기'라는 옵션을 켜두는 걸 까먹으면 불시에 서버에서 내 계정으로 전부 메일이 옮겨질지도 모른다는 강박관념, 그리고 로컬에 메일이 저장되어 있으면 불의의 사고로 메일이 전부 날아갈지도 모른다는 강박관념 때문에 IMAP을 쓰는 것이 아닌가 싶기도.

어쨌든 Outlook의 IMAP 문제는 굉장히 오래되었고, 속도도 그닥 빠른 편이 아니라서 웬만하면 메일 확인은 맥북에서 Mail로 하고 있다.

이 프로그램을 쓰다 보면 일단 IMAP 관련 성능은 Outlook 보다 확실히 낫다는 것을 느낄 수 있다. 한가지 불편한 것은 Mail에도 미리보기 기능이 있어서 MS Word나 Powerpoint 등으로 작성된 첨부파일은 '훑어보기'를 할 수 있긴 하지만  Hwp의 경우에는 뷰어 프로그램도 없고 훑어보기도 안되기 때문에, 메일 보내는 분에게 pdf 파일로 변환해서 보내주십사 부탁을 하게 되는 일이 꽤 잦다는 것.

이런 문제를 해결하기 위해서 HWP 첨부파일은 DROPBOX 폴더에 저장한 다음에 VirtualBox에 설치된 Windows XP의 HWP 프로그램을 통해서 열기도 하는데... (물론 VirtualBox와 Mac DROPBOX 폴더 사이의 동기화는 역시 DROPBOX를 이용해서 하고 있다.) 내가 쓰는 모든 컴퓨터에는 Dropbox가 설치되어 있기 때문에 어지간 하면 자리를 옮겨 가면서 작업을 하더라도 별 무리가 없다는 장점이 있기도.

옆동 사는 친한 부부가 캠핑을 가자고 조르는 통에 한번 갔다왔습니다. 장소는 이안숲속 캠핑장이었구요. 매점 바로 옆 풍차 있는 언덕 아래쪽에 텐트를 쳤습니다. (텐트치는 행위를 '사이트 구축한다'고 그러더군요.) 차가 LPG모델 소나타라 짐은 어쩔 수 없이 이런 식으로 갖고 갔습니다. (아시죠? LPG 승용차 트렁크의 반은 LPG 통이 먹고 들어간다는거... ㅎ)


더 큰 차를 사고 싶지만 그건 로또 대박난 뒤에나 *쿨럭* 아무튼 이렇게 이안숲속까지 좁게 좁게 타고 갔구요. 가서 텐트를 쳤는데 바람이 너무 많이 불어서 결국 한시간이나 걸려 텐트를 겨우 쳤습니다. 원래는 오분에서 십분 정도면 치고 노는건데... ㅎ


아이들은 텐트치면 제일 먼저 하는 일이 그 안에 들어가서 책읽는 거더군요. 텐트가 아늑하게 느껴져서 그런가봅니다. 두 집이 함께 가서 그런지 애들이 꽤 많네요. (뭐 그래봐야 네명밖에 안되지만.. ㅎ) 전면부에 보이는 좀 구려뵈는 텐트가 우리 집 텐트고, 그 반대편에 상대적으로 쌈빡해보이는 텐트가 친구 부부네 텐트입니다. 그 집 텐트가 아마 코베아 텐트일텐데 정확한 이름은 모르겠고, 저희 집 텐트는 코베아 빅돔 + 리오그란데 100입니다. 원래는 두 텐트를 하나로 연결해서 리오그란데 쪽을 전실로 써볼까 했는데, 그날 예상외로 바람이 너무 많이 불어서 포기했구요. 결국 리오그란데 안에 빅돔을 넣어서 추위 막는데만 신경썼습니다.


애들이 다 그렇겠지만 풀어놓으니 지들 끼리 알아서 잘 놀았구요.



윗 사진들은 자고 일어나 꺼벙하긴 하지만 그래도 즐겁게 노는 아이들 모습. (아저씨도 끼어있군요.ㅎ)


근데 요 위 두 사진을 보시면 아실지도 모르겠습니다만 그날 이안숲속에 오가와 텐트 동호회 분들이 잔뜩 오셨더군요. 그래서 오가와 텐트에 둘러싸여서 하룻밤을 보냈는데요. 비싼 텐트라 그런지 좋습디다. ㅎ 바람 불어도 조금 휘청거리기만 하지 절대 넘어가는 법이 없다는 이백삼십만원짜리 텐트... ㅋㅋ 어떤 분들은 거기 난로에 연통까지 연결해서 따뜻한 밤을 보내시더군요. 잠깐 부럽기도 했습니다.

하지만 그런 아쉬움은 부대찌개로 날려버리고....

점심 먹은 뒤 텐트 철거하고, 유성 온천탕에서 목욕하고 먼지 씻어낸 다음에 집으로 돌아왔습니다. 이안숲속까지 갔는데 정작 식물원 구경은 못하고, 그냥 먹고 쉬다 왔군요. 식물원 구경은 다음 기회에 :-)

TCP_NODELAY 옵션은 TCP의 Nagel 알고리즘을 무력화시키는 옵션입니다. Nagel 알고리즘은 무슨 알고리즘이냐 하면, 짤막한 패킷을 보낼 때 가능하면 버퍼링을 했다가, 버퍼가 다 차면 한번에 보내는 알고리즘입니다. 짤막한 패킷이 네트워크에 너무 많이 뿌려지면 네트워크 뿐 아니라 서버의 성능도 저하되기 때문에 도입된 일종의 congestion-control 알고리즘이죠.

이 알고리즘은 이미 보낸 패킷에 대한 ACK이 올 때 까지는 가능한 한 (그러니까 버퍼가 찰 때 까지) 많은 패킷을 버퍼링하려고 합니다. 그래서 TCP의 Delayed ACK과 같이 쓰이면 좀 안좋은 결과가 빚어질 수도 있습니다. 내가 보내는 패킷의 크기가 항상 작다고 해 보죠. 그럼 이 패킷은 ACK이 올 때 까지 전송되지 못하고 계속 버퍼에서 대기하게 될 겁니다. 내가 보낸 패킷에 대한 응답을 상대 서버가 보내게 되어 있고, 그 패킷을 받은 다음에야 다른 패킷을 또다시 전송하도록 되어 있다면? 상황에 따라 다릅니다만 최대 500ms 까지의 전송 지연을 체감하게 될 수도 있습니다.

if there is new data to send
  if the window size >= MSS and available data is >= MSS
    send complete MSS segment now
  else
    if there is unconfirmed data still in the pipe
      enqueue data in the buffer until an acknowledge is received
    else
      send data immediately
    end if
  end if
end if

[알고리즘 출처: 위키피디아]

어떤 상황에서 그런 일이 벌어지나요? write-write-read를 하는 상황에서 벌어질 수 있습니다. 가령 제가 패킷을 한 번에 보내도 되는데, 두 개의 작은 패킷으로 나누어 보낸다고 해 보죠. 첫 번째 패킷은 서버에 잘 도착할 거에요. 그런데 서버는 아직 데이터를 온전히 다 읽지 못했고, 두 번째 패킷을 다 받아야 응답을 보낼 수 있다고 해 봅시다. delayed ACK은 서버가 보낼 응답 데이터가 있을 때, 그 위에 ACK을 piggyback한다는 정책이니까, 아마 클라이언트 쪽으로 첫번째 패킷에 대한 ACK은 발송되지 못할 거에요. Nagel은 ACK이 올 때 까지 버퍼가 차기를 기다릴 테니까, (ACK이 왔다면 보내겠지만) 두 번째 패킷은 서버 측에서 delayed ACK 타이머가 만료되고 (200ms 후) 첫 번째 패킷에 대한 ACK이 서버에서 클라이언트 쪽으로 전송된 이후에나 보내질 수 있게 됩니다.

따라서 전송해야 하는 패킷의 크기가 그다지 크지 않은 상황에서 전송 지연을 줄이려면 '클라이언트의 요청에 서버는 무조건 패킷으로 응답하'고, 'write는 무조건 한 번에 한다'는 원칙을 지켜야 합니다.

The user-level solution is to avoid write-write-read sequences on sockets. write-read-write-read is fine. write-write-write is fine. But write-write-read is a killer. So, if you can, buffer up your little writes to TCP and send them all at once. Using the standard UNIX I/O package and flushing write before each read usually works. - 출처: http://developers.slashdot.org/comments.pl?sid=174457&threshold=1&commentsort=0&mode=thread&cid=14515105

그런데 그 원칙을 잘 지켜도 전송 지연이 생기는 경우가 있을 수 있습니다. (사람은 실수하게 되어 있는 동물이니까요.) 그러면 이제 최후 수단으로 Nagel 알고리즘을 꺼버리는 방법을 써야 합니다. 끄려면 setsockopt와 TCP_NODELAY 옵션을 함께 사용하면 됩니다.

 

Evernote는 개인 메모를 여러 컴퓨터에서 실시간으로 동기화하고, 관리할 수 있도록 해 줍니다. 이 툴을 사용하면 맥 북에서 작성한 메모를 Windows PC에서 확인할 수도 있고, 수정할 수도 있죠. 수정한 사항은 Evernote를 실행중인 다른 컴퓨터에도 실시간으로 동기화됩니다. 

어제 마이크로소프트에서 일하는 김창훈 박사를 만났습니다. 대전에 일이 있어서 들렀는데, 저는 바빠서 저녁식사 하는 장소에는 가질 못하고 일하고 있다가 잠깐 가서 얼굴만 보고 와야 했죠. 신세진 일이 있어서 다음에는 저녁을 사겠다는 (대체 언제가 될지는 모르지만) 말만 하고 돌아왔습니다. 그런데 마침 어제 인사이트의 신간 "CODE: 하드웨어와 소프트웨어에 숨어있는 언어"를 받았습니다. 마이크로소프트의 찰스 펫졸드가 지은 책이죠. 마이크로소프트에서 일하는 두 사람을 같은 날 만나는 드문 경험을 한 셈입니다.

어제 대화를 나누다가 모교의 컴퓨터공학과 학생들에 대해서 이야기를 잠깐 나누었는데, 교과 과정이 학생들을 올바르게 이끌어주지 못하는 것 같다는 이야기를 하더군요. KAIST의 학생들과 비교해 보면, 질문의 내용과 수준이 너무 차이가 난다는 말도 했습니다. 하드웨어와 소프트웨어 관계에 대해서도 깊은 이해가 없는 것 같다는 말도 했구요.

보통 컴퓨터공학이라고 하면, 하드웨어와 소프트웨어 전반을 아우르는 지식 체계를 말합니다. 하드웨어를 잘 모르고 소프트웨어를 논하는 것도 우습고, 소프트웨어를 잘 모르고 하드웨어를 논하는 것도 우스운 법이니 그 둘 사이의 균형을 잘 맞추어야 하는데, 그걸 체계적으로 정리하고 가르치는 것이 컴퓨터공학과에서 보통 하는 일이죠.

그런데 제가 학부에서 보낸 4년을 돌아보면, 저는 하드웨어에 대해 공부하는 것이 너무 재미가 없었어요. 사실 그렇잖아요. 소프트웨어가 거시적이라고 본다면 하드웨어에는 미시적인 구석이 있죠. 플립-플롭이나 AND-게이트 같은 자그마한 소자들을 이렇게 저렇게 엮어서 덧셈과 뺄셈을 구현하는 게 재미있었을 턱이 있나요. 소프트웨어의 세계에서는 덧셈과 뺄셈은 그냥 되는 건데.

물론 지금 돌아보면 말도 안되는 생각이죠. 거기다 하드웨어를 알면 할 수 있는 일들이 훨씬 많아집니다. 아두이노 패키지처럼 하드웨어와 소프트웨어를 잘 결합해서 사람들로 하여금 보다 창조적이고 재미있는 일을 할 수 있도록 이끄는 프로젝트를 보면, 확실히 하드웨어와 소프트웨어는 같이 배워야 하는 무엇이라는 생각이 들어요. 아이폰을 비롯한 스마트폰 광풍을 봐도 그렇구요. 표면적으로는 앱 생태계가 활성화되는 것 같지만, 사실 그 시장을 지배하는 건 아이폰이라는 하드웨어죠. 물론 Xcode나 안드로이드 SDK같은 걸출한 Abstraction이 없었다면 지금의 아이폰도 없었을테니, 하드웨어와 소프트웨어를 따로 떼놓고 생각하려는 시도는 정말로 무의미해요.



말이 좀 샜는데, 다시 제 학부 시절로 돌아가 보겠습니다. 제가 왜 하드웨어 수업이 재미없었는지의 이유를 곰곰히 생각해봤는데, 대체적으로 다음과 같이 요약해 볼 수 있더군요.

1. 하드웨어의 세계가 너무 미시적으로 느껴져서 답답했다
2. 소프트웨어와의 연결고리를 제대로 찾지 못했다
3. 교수님들이 무슨 소리를 하는 것인지 제대로 알아듣지 못했다

3은 제 자질문제이니 넘어가도록 하고, 보통은 1과 2를 잘 이해하지 못해서 재미가 없었던 것 같아요. 특히 중요한 문제는 2번인 것 같은데, 소프트웨어와의 연결고리를 제대로 찾지 못하면 대부분의 학생들은 그걸 어디다 써먹어야 할지 잘 알지 못해요. 그들이 실생활에서 보는 대부분의 하드웨어는 소프트웨어라는 인터페이스에 둘러싸여 있거든요. 요즘은 그 소프트웨어들이 보여주는 하드웨어 abstraction이 너무 우아해서, 마치 하드웨어라는 것이 세상에 존재하기나 했었느냐고 묻는 것 같이 보일 때도 있죠. (물론 그래도 아직 사람들은 컴퓨터를 구입할 때 메모리 용량, CPU 속도 같은 걸 따지긴 해요.)

CODE는 바로 그 연결고리, 그러니까 하드웨어와 소프트웨어 사이에 어떤 관계가 있는지를 보여주는 책입니다. 저처럼 하드웨어에 대해서는 도통 관심이 없는 삶을 살다가 '정말 그렇게 살아도 되는 걸까?'하는 질문을 하기 시작한 분들이나, 컴퓨터공학과에서 새로운 인생을 시작하게 된 학부 1학년생들, 아니면 이제 막 컴퓨터라는 것에 대해 관심을 갖기 시작한 분들에게 정말로 괜찮은 안내서가 되어줄 거라고 확신합니다. 워낙 쉽게 씌여졌기 때문에, 그저 컴퓨터에 대해 좀 더 알고 싶다는 분들에게도 좋은 책이 될거라 믿습니다.

저는 이 책의 첫 페이지를 넘기는 순간 무척 즐거웠는데, 다른 분들도 그 경험을 함께 나눌 수 있었으면 좋겠습니다.

소프트웨어 프로젝트를 진행할 때 여러가지 이유로 추정을 하게 됩니다. "이 일을 하는 데 시간이 얼마나 걸릴까요?" 이 질문에 답을 하는 행위를 추정(estimation)이라고 합니다. 보통 계획은 추정 결과로 나온 추정치를 보고 잡습니다.

추정이 실패하는 데에는 여러가지 이유가 있습니다. 가장 최근의 사례를 예로 들어볼까요? 어떤 작업을 하는데 A라는 사람이 한 달이 필요할 거라고 추산했습니다. A는 해당 팀에서 소프트웨어 개발에 가장 정통한 사람이라고 부를 만한 능력을 가진 사람이었습니다. 그런데 막상 뚜껑을 열고 보니,그 일은 네 시간 만에 끝났습니다. 이런 경우, 추정은 실패했다고 보아야 합니다. 하지만 실제 업무 시간이 단축된 경우이니, 정말로 부정적인 효과로 이어진 추정이라고 보긴 힘듭니다. 만일 추정 대상이 된 업무가 프로젝트의 critical chain에 물려 있는 업무였다면, 이 실패한 추정은 프로젝트 기간 단축으로 이어졌을 것이고, 아무도 피를 보지 않았을 겁니다. 하지만 반대였다면?

위에서 예로 든 업무의 경우, 추정 실패 원인으로는 다음과 같은 것들을 들 수 있었습니다.

• cross-compiling에 대한 이해 부족
• autoconf와 같은 툴에 대한 이해 부족

따라서, 지식(knowledge)또는 노하우(know-how)가 부족했던 것을 추정 실패의 원인으로 추상화해 볼 수 있습니다. 대부분의 프로젝트가 그렇습니다. 추정은 '잘 모르기 때문에 하는' 행위라고 생각할 수 있습니다. 잘 알고 있다면, 추정할 필요가 없습니다.

소프트웨어 개발에서, 추정의 정확도를 높이는 가장 좋은 방법은 실험(experiment)입니다. 제 경험상, 실험은 다음과 같은 범주로 나누어볼 수 있었습니다.

• 구조 실험 (experiment on architecture)
• 성능 실험 (experiment on performance)

구조를 실험하는 것은 소프트웨어의 구조의 정당성을 확인하는 행위이고, 성능 실험은 어떤 소프트웨어가 실제 쓰이기에 합당한 성능을 보여주는지 알아보는 행위입니다. 이런 실험은 종종 테스트(test)와 혼동되기도 합니다만, 실험이 포괄하는 범위가 좀 더 넓기 때문에, 테스트는 그 하위 개념인 것으로 보는 것이 타당합니다.

에자일 세계에서는 실험을 종종 spike라고 부릅니다. 스파이크는 뭔가 잘 모를 때, 뭘 모르는지, 그리고 무엇을 몰랐는지 알아내기 위한 유용한 도구입니다. 소프트웨어 프로젝트를 진행하는 데 있어 가장 문제가 되는 지식의 불확정성(uncertainty)을 해결하는 가장 좋은 방법 중에 하나입니다.

스파이크를 진행하고 추정을 하면 추정의 정확도를 높일 수 있지만, 불확실성이 극도로 높을 때에는 스파이크를 진행하는 데 얼마나 걸릴 지 아는 것도 어렵다는 것이 문제가 되곤 합니다. 따라서 스파이크는 굉장히 숙련도가 높고 경험이 많은 사람들 한 두 명 정도가 모여 진행하는, 굉장히 집중적인 활동이 되어야 합니다. 아니면 프로젝트 후반부에 들어가는 시간과 맞먹을 정도의 오버헤드를 낳을 수도 있습니다.

추정이 보통 프로젝트나 스프린트 초반에 일어나는 행위라는 점을 감안하면, 스파이크도 가급적이면 사전적인 활동이 되어야 합니다. 그래야 추정치의 정확도를 높일 수 있고, 추정이 실패할 확률을 낮출 수 있습니다.

그러니, 무언가를 추정해야 하는데 그 무언가가 굉장히 중요하다면, 가급적 빨리 실험을 진행하는 것이 좋습니다. 회의를 해서 해결되는 문제라면 모두 모여서 머리 싸매고 해결책을 논하는 것이 좋겠습니다만, 회의를 해서 해결될 문제가 아니라면 무작정 비관적인 추산을 하는 것 보다는 하루라도 빨리 컴퓨터 앞에 앉아서 여러가지 대안들을 검증해 보는 것이 전체 프로젝트 진행을 위해서도 바람직합니다.

순서는 아무 의미가 없으므로 개의치 마시길. CVS가 자주 언급되긴 하지만, Subversion 사용자라면 CVS를 Subversion으로 바꾸어 읽으시기만 하면 OK.

1. CVS에 남겨진 변경 로그에 아무 메시지도 적혀있지 않다

변경 로그에 아무 메시지도 남기지 않는 것은 프로그래머들 사이에는 널리 만연된 관습 가운데 하나로, 보통 '자신이 만든 코드상의 변경이 로그를 적을 만큼 중요한 것이 아니'라고 보기 때문에 저질러지는 실수이다.

어떤 종류의 변경이건, 로그는 남겨져야 한다. 그래야 다른 프로그래머들이 CI 서버로부터 유용한 정보를 얻을 수 있을 것이기 때문이다. 로그를 볼수 없다면 프로그래머는 다른 프로그래머가 자신의 모듈을 사용하면서 저지른 실수를 추적할 수 없다. 물론 그런 문제를 해결하는 가장 좋은 방법은 자신의 코드를 최대한 robust하게 만들고 타입 검사를 명확히 하고 인자 검사를 엄격히 하도록 하여 단위 테스트 단계에서 문제가 드러나도록 하는 것이다.

2. 자동 빌드를 위해 추가한 CVS 사용자 계정을 프로그래머들이 돌려쓴다

CVS 사용자 계정은 프로그래머들마다 하나씩 만들어져야 한다. 계정을 만드는 데 오랜 시간이 걸리는 것도 아니기 때문에, 하나의 계정을 돌려쓰고 있다면 그것은 CI 프로젝트 관리자가 되기에는 너무 게으르다는 뜻 밖에 되지 않는다.

3. CI 관리자가 프로그래머들과 대화를 하지 않는다

이슈 추적 시스템을 맹신하거나 CI 관리자가 본인의 능력을 너무 과대평가할 경우 흔히 벌어지는 일이다. CI 관리자는 그저 관리자일 따름이지 신이 아니기 때문에, 빌드 상에서 발생하는 문제를 스스로 해결하려고 해서는 안된다. 프로그래머들과 대화한 후에 프로그래머들이 직접 문제를 해결하도록 두는 편이 좋다. 그 편이 팀 전체의 능력 향상이나 화합에도 도움이 된다.

4. 단위 테스트 결과가 fail로 나온 이후에도 오랫동안 방치된다

이 문제의 원인은 다음과 같다.
1. 개발자가 CI 서버의 보고서를 보지 않는다.
2. 보았더라도 자기 문제가 아니라고 생각한다.

'보았더라도 자기 문제가 아니라고 생각하'는 이유는 다음과 같다.
1. 개발 서버의 문제라고 생각한다.
2. 다른 프로그래머의 문제라고 생각한다.

개발 서버의 문제가 아니라는 점을 알려주는 건 ci관리자의 몫이다. 자신이 commit한 소스로 인해 발생하는 빌드 문제는 해당 프로그래머의 문제이다. 해당 프로그래머는 자신의 소스가 필요로하는 라이브러리나 설정 파일을 지정된 디렉터리에 commit하여 빌드가 정상적으로 이루어지도록 할 의무가 있다. 그러므로 console output을 주의깊게 살펴야 한다. CI 관리자와 프로그래머간의 의사소통이 원활하지 않으면, fail된 단위 테스트나 망가진 build 프로세스는 오래 방치된다.

자신이 올린 소스가 다른 사람이 만든 테스트 케이스를 망가뜨리는 경우도 종종 있다. 이런 경우 테스트 케이스를 설계한 프로그래머와 새로운 소스 코드를 올린 프로그래머는 의사소통을 통해 문제를 해결하여야 한다. 의사소통이 되지 않으면 '서로 상대방 책임이라고 주장'하면서 fail된 단위 테스트가 방치되는 일이 생긴다.

5. 의미있는 빌드에 tag를 부여하지 않는다

CVS를 쓰건 Subversion을 쓰건 의미있는 빌드가 만들어졌다는 판단이 서면, 그 상태에 태깅을 해 주는 것이 좋다. 태깅을 하지 않는다는 것은 시스템 복원 지점을 설정하지 않고 Windows XP를 사용하는 것과 비슷한 일이다. 어떻게든 사용은 할 수 있겠지만, 비상시에 해야 하는 삽질의 양이 늘어난다는 점에서 그렇다.

6. CI 서버가 보여주는 빌드 리포트가 너무 건조하다

건조하다는 이야기는 재미가 없다는 이야기이고, 재미가 없다는 것은 빌드가 너무 평온하게 발전해 나가고 있다는 뜻이다. 빌드가 평온하게 발전해 나가고 있다는 것은 좋은 일이긴 하지만, 좀 나쁘게 해석하자면 '문제가 감춰진채로 드러나지 않고 있다'는 뜻일 수도 있다. 이럴 때는 테스트의 커버리지를 재점검하고, 테스트가 너무 말랑말랑하게 작성되어 있지는 않은지 점검해보는 것이 좋다. 테스트는 가급적 공격적인 것이 바람직하다.

[계속 수정됨...]

명심하라. 위대한 장수와 창의적인 전략가가 돋보이는 이유는 그들이 지식이 많아서가 아니라, 필요할 경우에는 선입견을 떨쳐버리고 당면한 순간에 온 신경을 집중하기 때문이다. 이것이 바로 창의력을 점화하고 행운을 거머쥐는 방법이다. 지식과 경험, 이론에는 한계가 있다.

미리 아무리 많은 생각을 하더라도, 어느 한순간에 발생하는 무한한 가능성과 인생의 혼돈에는 완벽하게 대비할 수 없다. 위대한 전쟁 철학자 카를 폰 클라우제비츠는 이것을 '마찰(friction)'이라 불렀다. 우리가 세우는 계획과 실제 일어나는 일의 차이를 일컫는 말이다.

마찰이 불가피하기 때문에 우리의 정신은 변화를 따라잡고 예측하지 못한 것에 적응해야만 한다. 변화하는 상황에 우리의 생각을 적응시키면 시킬수록, 그 상황에 대한 우리의 반응도 더욱 현실적으로 변한다. 이전에 소화했던 이론과 과거의 경험에서 헤어나지 못할수록, 우리의 반응도 부적절하고 자기 기만적으로 변한다.

보통 프로그래머들에게는 한가지씩의 무용담이 있습니다. 그 중 가장 흔한 것이 바로 "내가 만났던 가장 개같은 버그" 류의 무용담입니다.

이런 이야기는 왜 하는 것일까요? 뭐 다들 잘 아시겠습니다만, (1) 이런 무용담이 많으면 어디가서 분위기를 띄우기 좋고 (2) 자기가 경력이 꽤 된다는 걸 간단하게 입증해 보여줄 수 있으며 (3) 다른 프로그래머에게 유용한 정보를 전해줄 수 있다는 장점이 있습니다. 물론 이런 이야기는 '군대에서 축구한 이야기'랑 비슷하기 때문에, 프로그래머들이 둘 이상만 모이면 저절로 튀어나오게 되는 경향도 있긴 합니다. ^^;

프로그래밍 심리학이라는 책에도 나옵니다만, 천공 카드를 통해 프로그래밍을 했던 중세시대에도(ㅋㅋ) 소위 '개발자 커뮤니티'라는 것이 있었습니다. 천공 카드를 컴퓨터에 입력하려면 순번을 기다려야 하니까, 기다리면서 노가리들을 깠던 것이죠. 인터넷이 없었으니 당연했겠죠? 그 시대의 개발자들은 아마 지금 개발자들에 비해 백배는 수다스러웠을 겁니다.

각설하고... 그런데 버그에 관한 그런 무용담들을 들어보면, 보통 '버그를 잡았다'에서 스토리가 끝나버려요. 그 뒤의 이야기들은 좀체로 하질 않습니다. 오늘도 커피를 마시러 휴게실로 가다가 같이 일하는 분들하고 잠시 이야기를 할 기회가 있었는데요. 개발자를 한달간 애먹인 버그에 대해서 들려주시더군요. 관련된 모든 사람들의 영혼을 한달동안이나 잠식했던, 정말 가공할만한 버그였습니다. (가장 큰 문제는 그 버그가 그분들이 개발한 시스템에서 나온게 아니라는 점이었죠.) 듣는 제가 다 소름돋을 정도였으니....

보통은 거기까지 듣고 마는데, 오늘은 제가 이런 질문을 한번 해봤습니다.

"그런 버그를 한 번 겪고 나면 본인이 어떻게 달라졌다고 느끼나요?"

질문을 좀 뜨악하게 들으시는 것 같아서 좀 다르게 물어봤습니다.

"그런 버그가 (프로그래머로서의) 자신의 인생을 바꿔 놓았다고 느낄 때가 있나요?"

생뚱맞게 들리실수도 있겠습니다만, 저는 이런 질문을 한번쯤은 던져 보아야 하지 않나 합니다. 제가 이 직장에 처음 들어왔을때 처음 맞닥뜨린 가장 심각했던 'UNDETERMINISTIC' 버그^[각주:1]는 시그널 핸들링 관한 것이었습니다. 시스템이 죽긴 죽는데, 진짜 어쩌다 한번 죽는 겁니다. 그리고 그 상황 사이의 일관성을 찾기가 정말 힘들었어요.

이 문제의 해결책을 찾기 위해 정말 많은 삽질을 했습니다. (지금 생각하면 삽질이 아니라 당연하게 해야 하는 일들이지만요.) 첫 번째로 했던 일은 메모리 누수가 시스템의 crash로 이어지는 시점을 정확하게 동기화시키기 위해 MALLOC_CHECK_ 환경 변수의 값을 설정하는 것이었습니다. (Linux라면 man malloc하시면 관련 자료가 나올 겁니다.) 처음에는 시스템이 죽는 이유가 메모리 누수 때문이 아니었을까 하고 추측했거든요. (그당시에는 valgrind에 대해서 몰랐습니다.)

물론 그래도 문제가 해결이 안되었습니다. 한달 뒤에야 겨우 문제의 실마리를 찾을 수 있었죠. (쪽팔립니다ㅎㅎ) 문제인즉슨 이런거였습니다. write를 할 때 리턴 값으로 '파이프가 깨졌다'는 오류 메시지를 받을 수 있을 것으로 기대했었는데 (write를 하는 중에 서버가 죽을 경우를 대비하려던 거였죠) 문제는 그게 SIGPIPE 시그널을 block 하지 않으면 제대로 동작하지 않고 프로세스가 죽는다는 거였습니다. (그것도 꼭 항상 죽는건 아니었죠. ㅋㅋ)

이 문제의 교훈은 이런 거였습니다. 매뉴얼에 의존해서 그대로 몇 줄 코드를 구현했습니다. ('상대 프로세스가 죽을 경우 내 프로세스는 파이프가 깨졌다는 오류 메시지를 받는다'는 것이 매뉴얼 내용이었습니다.) 그런데 그 코드가 정말로 제대로 동작하는지는 확인을 하지 않았던 겁니다. '몇 줄'에 불과하고, '매뉴얼 대로' 구현했기 때문에, 거기 버그가 숨어들어갈 거라고는 생각을 못했던 것이죠.

이 문제를 '기계적'으로 해결하려면, 작은 수정을 가할 때 마다 그 수정이 정말로 올바른지 확인을 하고 넘어가야 했습니다. TDD 수준으로 보폭을 좁게 가져가는 것이 필요하다는 결론을 그 때 얻은 거죠. 이 결론을 실천해 볼 기회는 2년 뒤에 찾아왔습니다. 일단 모든 코드의 구현을 마친 뒤 (테스트 과정에서 설계가 변경될 수 있다는 가정은 일단 배재했기 때문에 그럴 수 있었습니다. 코드에 확신이 있기도 했고, 사실 무식할 때 가장 용감해지는 법이니까요), 시스템의 아주 작은 부분부터 차례로 테스트를 해 나기가 시작했습니다. 테스트를 마친 코드만을 조금씩 시스템에 포함시켜서 빌드를 해 나가기 시작했고, 그 부분이 제대로 시험되었다는 확신이 들 때메만 다음 코드로 넘어갔습니다. 이런 식으로 해서 결국 연동시험 때 발견된 버그 수를 0으로 낮출 수 있었습니다. 테스트에 CppUnit을 도입한 것, TDD를 공부한 것, '한 걸음을 뗄 때 마다 뒤돌아보기'에 대한 확신이 생긴 것 등이 그 시기에 했고 느꼈던 것들입니다. (지금 생각하면 '책 한 권만 잘 읽었어도 더 잘 할 수 있었을텐데' 하긴 합니다만.)

결국, '그 자그마한 버그 하나'가 저를 바꿔놓은 것이죠. 이 블로그도 그 덕에 생겼습니다. ^^;

많은 개발자들이 Continuous Integration이나 Issue Tracking의 필요성에 대해 공감은 하면서도 실제 도입을 망설이는 이면에는 '버그는 부끄러운 것'이라는 개발자적 자존심이 어느 정도 깔려 있다고 저는 생각합니다. 그런 부분을 해소할 수 있으려면, 버그 자체도 지식으로 대우하는 자세가 필요합니다. Bug Tracking이라는 말 대신 Issue Tracking이라는 다소 점잖은 용어가 널리 쓰이는 것도, 어쩌면 그래서일지도 모르겠어요.

버그가 나를 더 좋은 곳으로 데려갈 수 있다는 확신을 가지는 것은, 그런 의미에서 중요하다고 생각합니다. 여러분도 저처럼, '나를 바꾼 버그'를 하나씩 가지고 계신가요?

흔히 시스템을 만들 때 요구사항을 먼저 수집하곤 합니다. 그러나 떄로는 실제 사용자로부터 요구사항을 수집하지 않은 상태에서 (혹은 수집할 수 없는 상태에서) 시스템을 만들어야 하는 경우도 있습니다. 특히 새로운 프로그램을 만드는 경우에 그런 일이 많이 벌어집니다.

실제 사용자로부터 요구사항을 수집할 수 없거나, 수집하지 않은 상태에서 시스템을 만들어야 하는 프로젝트는, 대략 다음 중 하나의 경우에 해당합니다.

1. 연구용 프로젝트
2. 납품이 가능할지 알 수 없는 상태에서 진행되는 프로젝트
3. 혁신적 프로젝트

연구용 프로젝트는 보통 연구자의 필요에 의해 시작되고 진행되기 떄문에, 연구자 자신이 실제 사용자가 되기도 합니다. 그런 측면에서 보자면 "요구사항을 알 수 없어도" 적어도 연구자 자신의 필요에 부합하는 시스템은 나오게 마련입니다. 제 짧은 소견에 비추어 보자면, 많은 오픈소스 프로젝트들은 이 범주에 듭니다. 이런 범주에 드는 시스템은 공개되는 순간 비슷한 관심사를 가지고 있는 많은 동료 연구자들의 지지를 받게 마련이고, 데드라인이라는 제약에서 한 걸음 떨어져 있는 경우가 많아 비교적 느긋하게 요구사항 변화를 통제할 수 있습니다.

혁신적 프로젝트는 보통 시장을 선도할 목적으로 시작되는 프로젝트인데, 운이 좋으면 굉장히 많은 잠재적 사용자들을 고용(?)해서 시작할 수 있습니다만(큰 회사인 경우에 그렇죠) 그렇지 않을 경우에는 프로젝트에 관계된 사람들이 시장의 요구를 예측해서 진행해야 합니다. 어느 쪽이건 간에, 가급적 빠른 시간 내에 내부/외부 사용자들을 접촉해서 피드백을 받기 시작해야 합니다. 그렇지 않으면 프로젝트 후반부에 요구사항 변경과 씨름하느라 일이 좀 힘들어지죠. 혁신적 프로젝트라는 것이 이전 프로젝트의 결과물에 기반한 경우에는 이전 사용자들로부터 수집한 많은 이야기들이 새로운 프로젝트의 밑거름이 될 수 있어서 좀 낫겠습니다만, 그런 경험이 없는 프로젝트라면 더더욱 조심하는 것이 좋습니다.

가장 난감한 프로젝트 유형은 납품이 가능할지 알 수 없는 상태에서 진행되는 프로젝트입니다.

가령 A라는 회사가 B라는 고객이 조만간 '이런 저런 시스템'을 BMT를 통해 구매할거라는 소문을 들었다고 합시다. A라는 회사는 '이런 저런 시스템'을 만들어 본 경험이 있는 회사는 아닌데, '이런 저런 시스템과 비슷한 시스템'을 만들어 본 경험은 있는 회사입니다. B라는 고객은 '이런 저런 시스템'에 꽤 큰 돈을 들일 가능성이 높은 회사라, A사의 경영진은 곧 '이런 저런 시스템'을 만들기 위한 프로젝트 팀을 꾸립니다.

문제는, 이 때 부터 '이런 저런 시스템'에 대한 추측과 '이런 저런 시스템'을 사용할 사용자에 대한 추측이 진행된다는 점입니다. 개발자들은 (1) 이런 요구사항이 나중에 어마어마한 CUSTOMIZATION 요구로 다가올 수 있다는 점과 (2) 계약이 불발날 경우에는 자신들이 만든 코드가 백업 테이프 어딘가에 처박혀 먼지를 뒤집어 쓰게 될 수도 있다는 점을 알고 있기 때문에, 가능한한 그런 일을 피하고자 하게 마련입니다.

이 때 부터 소위 Software Engineering의 여러가지 원칙들이 시험대에 오릅니다. "과도한 Generalization은 좋지 않다"같은 원칙이 제일 먼저 공격을 받습니다. 요구사항을 정확히 알수 없는 상황에서 개발자들은 본능적으로 "모든 코드를 최대한 확장 가능하게 만들"려 애쓰게 됩니다. 언뜻 보면 디자인 패턴(Design pattern)을 통한 개발에 모든 개발자들이 맹목적으로 달려들기 때문에 상황이 개선되고 있는 것 처럼 보이기도 합니다만, 나중에 보면 애초에 만들려던 '이런 저런 시스템' 대신 '어디서 많이 본 시스템', 그것도 마치 '미들웨어의 냄새가 강하게 풍기는' 시스템이 만들어지게 되는 일이 왕왕 생깁니다.

(이런 일이 벌어지고 있는지를 확인하는 가장 간단한 방법은 프로젝트 관리 차트에 '기능(feature)'의 이름 대신 추상적인 SW Engineering 용어들이 적히고 있는지를 보는 것입니다.)

이런 시스템은 '알 수 없어서 발생하는 리스크'를 전부 회피했기 때문에 'CUSTOMIZATION 하기 좋은 시스템'으로 보일 수도 있습니다만, 소위 '구매자의 마음을 끄는 기능'이 없어서 외면을 받기도 합니다. 구매자의 입장에서 보면, '가치를 생산하기 위해서는 반드시 CUSTOMIZATION을 해야 하는' 시스템이 달갑지만은 않을 테니까요.

물론 시스템을 개발한 사람 입장에서는 '빠른 CUSTOMIZATION'을 강점으로 내세워 홍보를 하면 그런 단점은 커버할 수 있지 않겠느냐고 생각할 수도 있겠습니다만, 문제는 "고객과의 소통이 이루어지지 않은 상태에서 generazation을 하기 위해 내렸던 결정들이 반드시 옳을거라는 보장을 할 수 없다"는 점입니다. 나중에 요구사항에 맞지 않아서 구조 자체를 다 뜯어고쳐야 한다면 그것도 난감하기는 마찬가지라는 이야기죠.

이런 상황이라면, 애자일을 하건 워터폴을 하건 아마 마찬가지일 거에요.


앞선 글에도 적었었습니다만, 세상 어디를 가나 이런 사정은 마찬가지입니다. 적고 보니 '소통'이 중요하다는 이야기를 한 셈인데, '소통'은 리스크를 드러내 준다는 점에서 의미가 있습니다. 요구사항을 알기 위해서 '소통'을 그렇게 열심히 하는 이유는, 가급적 모든 리스크를 빨리 드러내 주어야 계속되는 플래닝 과정이 좀 더 의미있는 결과를 내놓을 가능성이 높아지기 때문입니다.

어제 100분 토론에서 미네르바 아저씨 이야기를 듣다보니, 적어도 그가 '공익'에 한가지 기여를 했다는 점은 분명해 보이더군요. 바로, 이 사회의 리스크를 남김없이 보여주었다는 점이죠. 한 명의 인터넷 스타의 글에 휘둘릴 정도로 취약한 경제구조를 가지고 있다는 점과, 그런 글에 신경증적 반응을 보일 정도로 너그럽지 못한 행정부/사법부/입법부를 가지고 있다는 점.

앞으로 주식투자는 최대한 보수적으로 해야 할 것 같아요.ㅋㅋ

사람들이 살아가고 지식을 나누는 방법에는 지식간 경계를 뛰어 넘는 어떤 공통점 같은 것이 있습니다. 보통 XP에서 많이 하는 것으로 알려져 있는 짝 프로그래밍(Pair Programming)도 예외는 아닙니다. 많은 프로그래머들이 "지나치게 급진적"인 것으로 생각하는 이 프로그래밍 기법은, 사실 다른 쪽에서는 그다지 새로운 것이 아닐 수도 있습니다.

책을 통해 기타를 배운다면 결국 완벽한 4분음표와 2분음표로 동요나 칠 수 있을 겁니다. 그러나 대부분의 기타리스트들처럼 친구들이 치는 것을 보고 들어 기타를 배운다면, "Smoke on the water", "Sunshine of your love", "Black bird" 같은 모든 곡을 다 칠 수 있을 정도로 진일보할 겁니다. 즉, 무슨 뜻인가 하면 악보를 몰라도 기타는 칠 수 있다는 말입니다.

- 천재반 기타, p63

가끔 짝 프로그래밍이 두 사람의 기타리스트가 앉아 음악을 연주하는 잼 세션과도 비슷하지 않을까, 하는 생각을 해 봅니다. 기타 대신 키보드를 두드린다는 차이만 있을 뿐이죠. 두 사람이 서로의 기량에 대해 좀 더 열린 마음을 가질 준비만 되어 있다면 결과물의 품질은 아마 더 좋아질겁니다.

비단 짝 프로그래밍이 아니더라도, 마음을 좀 느슨하게 먹으면 일이 잘 풀리는걸 경험하기도 합니다. 제가 최근에 까칠함 대신에 친절함을 모토로 삼아보자고 마음을 먹었는데, 뭔가 얻어먹을 일이 좀 많아지더군요. :-P