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)을 해결하는 가장 좋은 방법 중에 하나입니다.

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

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

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

최근에 하고 있는 짓들이란게 이런거라는...ㅎㅎ
그래서 글도 잘 못쓰고 있습니다.
이 블로그에 가끔 들러주는 분들께 죄송할 따름...

다들 눈 많이 내리는 한겨울에 별 탈 없이 지내고 계신지...

저는 보시다시피 당분간은 아이폰 응용 개발이나
논문 작성 때문에 바쁠 예정이라 블로그에는 좀 소홀할 듯 싶습니다.

이 한 겨울에 다들 건강 조심하시고...

이런 식으로라도 가끔 글 남기도록 하겠습니다.

아이팟 터치가 두대가 생겨서 그래도 할 수 있는 것들이 좀 늘어나 즐겁네요.

대박까진 몰라도 뭔가 새로운 것들을 배울 수 있는 기회가 되었으면 좋겠습니다.
새로운 것을 배운다는 것은 언제나 즐거운 일이니까요.

(그래도 Objective-C에는 친숙해지기가 너무나 어렵군요. ㅎㅎ)

논문은 Consistent Hashing을 활용한 failover system 구현에 관한 것입니다.
잘 될지는 모르겠지만... 2월이 마감이라 이번 한달 동안은 꽤나 바쁠 것 같군요.
이제 실험도 착수해야하고... 논문도 고쳐야 하니까요.

사실 실험에는 젬병인데...
어떻게 해야 할지 고민도 많이 되는군요.

나이들어 박사학위 과정에 계속 머물러 있는 것도 부담이라
이번에는 어떻게든 끝내야 할텐데....

최근에 Fit이라는 테스팅 프레임워크에 대한 책을 번역했습니다. 이 책의 초고는 지금 베타리더분들께 가 있는데, 조만간 출판사로 넘길 수 있지 않을까 생각합니다. 기다리시는 분들께 다시 한번 사과말씀 드립니다. 아무튼 오늘 하려는 이야기는 그게 아니고...

FitNesse라는 프레임워크가 있습니다. 이 프레임워크는 Fit을 Wiki 형태로 사용할 수 있게 해주는 좋은 도구입니다. 이 도구를 처음 접하고, 어떻게 써먹으면 좋을까 고민을 좀 했습니다. 제가 회사에서 맡은 일이 주로 네트워크 프로토콜 스택을 구현하는 일이라, 거기에 적용할 방법이 없을까 생각해봤습니다. 아니, 처음부터 그렇게 생각한 건 아닙니다. 첨엔 삽질부터 시작했죠. 그 삽질이 어떤 과정으로 진행되었는지 살펴보자면 대략 다음과 같습니다.

1.
처음에 이 프로토콜 스택을 구현하기 시작할 때, 일단 통신과 관련된 패킷 핸들링 부분은 좀 천천히 구현하고, 프로토콜의 핵심이 되는 '메시지 교환 sequence' 부터 설계하고 구현할 수 없을까 생각했습니다. 그러다 보니 결국 프로토콜 스택을 두 계층으로 나누게 되었습니다. 편의상 위에 있는 놈을 U라고 하고, 아래쪽에 있는 놈을 D라고 해 보겠습니다.

2.
먼저 저는 U를 구현했습니다. U에 대한 테스트 작성을 병행했는데, 아무래도 D를 구현하지 않았기 때문에 테스트 작성이 쉽지가 않았습니다. 제가 알고 있는 한, 이 문제를 해결하는 방법은 mocking 라이브러리를 이용하는 것이었습니다. 그래서 D를 mock 하기로 결정했습니다. 그런데 jMock을 써서 D를 mock 하려 하자 난관에 부닥쳤습니다. D를 mock 하는 건 좋은데, mock된 D가 U의 콜백 함수를 부르도록 할 방법이 마땅치 않았던 것입니다. 그래서 오픈 mocking 라이브러리들은 제쳐놓고, 제가 직접 D에 대한 mock 객체를 구현하기 시작했습니다.

3.
처음에는, D 객체는 딱 하나만 만들어 놓고, 모든 U들이 D를 통해 통신하도록 했습니다. (실제 시스템은 U+D가 장비마다 하나씩 들어가게 되어 있는데, 그것과는 다른 구성이었습니다. 나중에 문제를 일으켜 결국 리팩토링하게 됩니다. -_-;) 어찌 어찌 해서, jUnit 테스트 케이스를 완성했습니다. 테스트 케이스는 우아하게 실행되었고, 모든 테스트 케이스에 파란불이 켜졌습니다. 저는 테스트 결과와, 테스트 작성 결과로 수정되고 작성된 U의 클래스들을 다이어그램으로 정리해 보고서를 제출했습니다. 거기까지는 괜찮았고, 저는 일주일 동안 Fit의 번역 작업에만 매진할 수 있었습니다.

4.
그런데 일주일이 지나고 다시 Eclipse 앞에 앉았을 때, 저는 뭔가 문제가 있다는 사실을 깨달았습니다. U를 완성할 수 있었던 것은 좋았는데, 테스트를 위해 작성한 jUnit 프로그램이 너무 복잡했던 것입니다. 여러 개의 U 객체를 묶어 통신 시나리오를 만들고 그 통신 시나리오대로 움직이는지를 테스트하려다 보니, 결국 굉장히 길고도 이해하기 까다로운 테스트가 만들어 졌던 것이죠. 그리고 일주일이 지나자, 저는 그 테스트가 어떻게 완성된 것인지를 까먹어 버렸구요. 그 덕분에, 프로그램 수정 결과로 테스트가 깨져도 대체 테스트가 '왜' 깨진 것인지를 파악하기가 쉽지 않았습니다.

5.
결국 저는 '장문의 jUnit 테스트 케이스는 그다지 바람직하지 않다'는 교훈을 얻었습니다. 저에게는 길고 장황한 통신 시나리오를 테스트할 다른 방법이 필요했습니다.

6.
그래서 결국 FitNesse로 프로그래머 테스트를 할 방법이 없을까 생각했습니다. 일단 FitNesse를 사용하기로 결정하자, 그 방법은 어렵지 않게 찾을 수 있었습니다. DoFixture를 사용하는 것이었죠. 네트워크를 통해 발생하는 모든 행위를 DoFixture의 액션으로 구현하고, 그 액션이 올바르게 실행되는지를 보기로 결정했습니다. 그래서, 다음과 같은 테이블을 작성했습니다.


테이블 중간 중간에, 이 테스트가 의도하는 바가 무엇인지를 보여주는 텍스트를 삽입했습니다. 그리고 이 테스트를 돌리기 위해 프로그램을 수정해 나가기 시작했습니다.

7.
테이블이 테스트를 주도하기 때문에, 테스트 코드의 엔트리 포인트부터 시작되는 제어의 흐름을 따라가기가 편했습니다. 그 덕에, 테스트를 실제 테스트 대상 시스템에 돌리는 픽스쳐 코드는 비교적 시간이 흐른 뒤에 다시 보더라도 그다지 어렵지 않게 이해할 수 있었습니다.

뭔가 수정할 때 마다 테스트를 계속 돌려 봤기 때문에, 내가 어디서 실수를 저질렀는지 계속 확인할 수 있었습니다. 그리고 굉장히 심각한 리팩토링을 해야 할 때도 (나중에 D를 U 별로 하나씩 분리한 다음에 D끼리 통신하도록 만드는 수정을 했는데, 그게 이번 코딩에서는 그럭저럭 '굉장히 심각한' 리팩토링이었습니다 ㅋㅋ) 그 결과가 올바른 것이었는지 재때 확인할 수 있었습니다. 결국, 항상 다음과 같은 화면을 볼 수 있었습니다.


이 과정을 거쳐 저는 U가 가져야 하는 기능의 대부분이 정상 동작함을 확인하고, D가 어떤 식으로 동작해야 하는지에 관한 세부사항을 알 수 있었습니다. 이제 D를 개발하기 시작해야 하는데, 위의 테스트를 계속해서 활용하면 D를 구현하는 것이 그다지 어렵지는 않을 거라고 기대하고 있습니다.

FitNesse를 테스트 도구로 활용하면서, 프로그램의 테스트 가능성에 대해 좀 더 많이 생각해 보게 되었습니다. 일단 테스트 가능성에 대해 생각하기 시작하자, 프로그램의 각 모듈 (이 예의 경우에는 U와 D) 사이의 관계가 좀 더 선명하게 드러나기 시작했고, 테스트 픽스쳐의 코드도 그 관계를 좀 더 분명하게 드러내게 되었습니다. 덕분에 U와 D를 설계하면서 놓쳤던 것들이 코드에 보완되기 시작했구요.

아마 이건 UI와 테스트가 거의 같은 계층에 있기 때문일 겁니다. 테스트를 좀 더 잘 할수 있으려면 U가 외부에 제공하는 인터페이스가 명확해야 합니다. U가 테스트를 잘 지원하려면 D와의 인터페이스도 분명해야 하죠.

8.
사실 앞으로 남은 일이 더 걱정입니다만, (프로토콜 개발은 제가 직접 하는 게 아니고 용역 업체와 진행하게 되어 있습니다) 이번 개발이 잘 완료되면 FitNesse를 고객(저)과 개발자(용역업체) 사이의 소통에 활용해 생산성을 높인 사례를 확보할 수 있지 않을까... 그런 기대를 하고 있습니다. 그리고 다음번에는 어떻게 적용하면 더 좋을지도 알게 될 것 같구요.