제 블로그인데 오랜만에 들어오니 낯설게 느껴집니다. :)
읽는 사람이 얼마 없기는 하지만 왠지 주변 시선이 느껴지면서 자연스럽게 글쓰기가 거북해졌나봅니다.

RSS 리더를 쓰면서 눈에 띄는 글들은 별표를 쳐서 보관을 해놓는데, 나중에 읽어야지 하면서 읽지 못한 글들이 많습니다. 사실 비판적으로 글을 읽고 그것을 실생활 혹은 업무에 적용한다는 것. 그리고 그것에 대해 다시 말할 수 있으려면 많은 노력이 필요합니다. 넘쳐나는 글들 때문에 정작 나 자신의 사고는 무뎌지는 것은 아닌지 걱정이 되기는 하지만 좋은 글들 몇가지를 블로그에 링크걸어볼까 합니다.

개발팀에서 팀과 개인이 모두 발전하기 위해 가장 먼저 해야할 일이 무엇일까요? 특히 신입 엔지니어와 기존 고참 엔지니어 사이에 존재하는 프로젝트에 대한 이해/실력의 차이를 줄이기 위해 가장 해야할 일은 무엇일까요?

정기적으로 프로젝트에 대한 세미나를 열고, 특정 부분에 대해 프리젠테이션할 수도 있습니다만 가장 중요한 것은 코드 리뷰를 통한 서로에 대한 이해/소통이 아닐까 싶습니다.

얼굴을 맡대고 서로 침을 튀어가며 이야기하는 것은 우리가 일반적으로 소통하는 방식이고 기본입니다. 하지만 우리는 매일 코드를 작성하고 그것을 기반으로 프로젝트를 이끌어 가는 프로그래머입니다. 대화만으로는 모든 것이 해결되지 않고, 그럴 필요도 없습니다.

우리는 코드라는 좋은 의사소통 수단을 가지고 있습니다. 결과로서의 코드가 우리가 하는 모든 것을 대변하고, 그것이 생각이 투영된 장(場)이니까요. 그러나 많은 팀들이 이런 좋은 수단을 활용하고 있지 못하고 있습니다.

코드는 오해의 여지가 없다는 점에서 대화보다 효율적입니다. 프로젝트를 수행하면서 일반적으로 주고 받는 대화들은 그것이 구체화되는 과정을 확실하게 트랙할 수 없다는 점에서 100% 신뢰성을 발휘할 수 없습니다. 그러나 코드는 과정과 결과를 명확히 보여줄 뿐만 아니라 꾸준한 리뷰 과정을 통해 서로의 경험과 지식이 스며들도록 할 수 있습니다.

서로의 코드를 살펴봄으로서 상대방의 스타일을 눈으로 느낄 수 있고, 경험적으로 좋은 코딩 프랙티스/아키텍쳐를 배우게 됩니다. 이런 과정에서 서로에 대한 신뢰가 쌓이는 것이 아닐까요?
신입 엔지니어는 고참들에게 직접적으로 지식을 전수받을 기회를 얻는 것이고, 그 반대일 수도 있습니다.

코드리뷰 없이 서로에 대한 안일한 믿음으로 프로젝트를 진행하는 것은 위태로워 보입니다. 서로가 무슨 일을 하는지 눈으로 확인할 수 없다면 불신이 쌓이기 쉽기 때문입니다. 이것은 상대방과 경기장에서 땀을 흘리며 직접 플레이를 해보는 것과 아닌 것의 차이와 같습니다.

코드를 작성하는 엔지니어라면, 당연히 코드로서 소통해야 합니다. 서로의 코드를 살펴보고 그에 비추어 자신의 코드를 살펴봐야 합니다. 이것은 비단 개인 뿐만 아니라 팀에도 많은 혜택을 가져다 줍니다. 일관성을 유지하기 쉽고, 누구나 프로젝트 전반에 대한 시야를 가지게 해줍니다. 또한 서로의 지식이 원활하게 소통하게 되고 그만큼 소화할 수 있는 지식의 양도 많아지게 됩니다.

코드리뷰는 주마다 한번씩 모여서 코드조각을 pt로 준비해서 살펴보는 것이 아닙니다. 이것은 작성 와중에 수시로 이루어지는 호흡과 같아야 합니다.

Cruise Control과 Hudson.

분류없음 | 2009/09/07 01:01 | dwha
최근 팀 빌드시스템에 한가지 변화가 있었습니다. 소프트웨어의 지속적인 무결성 확인을 위해 continous integration 툴을 사용하기로 결정한 것입니다. 좀 늦은 감이 없지는 않지만, 새로운 필요성에 의해 도입하기로 결정한 만큼 지금이 가장 적기라고 생각했습니다.

프로젝트는 과정 속에서 성장하고 변화하는데, 처음부터 어떤 개발론과 프랙티스에 짜맞출 필요는 없다고 생각합니다. 필요성에 대한 고찰없이 이런저런 개발 프랙티스와 그것에 필요한 툴들로 덩치만 키운채 시작하는 프로젝트는 부드러운 진입을 방해할 뿐만 아니라 유연성을 떨어뜨리는 요인이 될테니까요. 새로운 시도/모색이 중요한 것이지 교과서를 따라하는 것이 중요한 것은 아니겠죠.

일단 가장 잘 알려진 Cruise Control을 사용하기로 했습니다. xml형태의 하나의 설정파일로 모든 과정을 설정해서 사용하는 방식이었는데, 괜찮은 튜토리얼/예제들을 웹에서 쉽게 찾을 수 있어서 별 다른 어려움은 없었습니다. 한번 익숙해지면 효율이 높아지는 텍스트 형태의 설정방식도 마음에 들었습니다. 하지만 xml 설정방식에 함정이 많은 것은 어쩔 수 없더군요.

예를 들어, 빌드 실패시 이메일로 통지해주는 기능을 설정하기 위해 <email> 블록을 사용하는데, 이것이 <publishers> 블록 이외에도 다른 블록의 서브로 들어갈 수 있다는 것이 제가 만난  함정 중 하나였습니다. 이것이 문제가 되는 이유는 빌드 과정을 기술하는 <tasks> 블록의 하위로 <email> 블록이 들어갈 경우 실패 통지가 제대로 이루어지지 않기 때문입니다. 더 이상한 것은 실패 통지 이외의 다른 메일통지는 정상적으로 이루어진다는 것입니다.

이유를 찾아보니 <tasks> 블록이 빌드를 수행하는 과정에서 실패가 일어나면, 바로 해당 블록을 탈출하게 되어 있다고 합니다. 그러니 하위 블록으로 설정된 이메일 공지 영역에는 닿을 수 없었고, 이메일 통지도 제대로 이루어지지 않았던 것입니다.

쓸데없는 이야기가 길어졌는데, 이런식으로 경고메세지도 없이 잘 파싱되는 설정파일이 문제를 안고 있을 수 있다는 것입니다. 상황이 더 복잡하게 되면 무엇이 문제인지 찾는 것은 디버거없이 코드 속에서 오류를 찾는 것과 별반 차이가 없습니다.

반면 Hudson이라는 사용하기 쉬운 툴도 있습니다. 웹기반으로 편리하게 모든 과정을 설정할 수 있어서, 더 이상 xml 파일을 손수 건드릴 필요가 없습니다. Cruise Control과 Hudson을 비교해 놓은 페이지가 있는데 참고하시면 도움이 될 것 같습니다. 결국 우리도 Hudson으로 바꿔타야 될 것 같습니다. 무엇보다 유닛테스트 관련 기능의 풍부함과 내장된 분산빌드 기능이 매력적인 것 같습니다.
구글 크롬(chrome)팀이 새로운 업데이트 시스템을 개발해서 사용하기 시작했다고 합니다. 이름하야 Courgette.  어떻게 읽어야 될지 몰라서 찾아봤더니 []라고 읽고, 길다랗게 생긴 어떤 서양호박을 지칭한다고 합니다.

웹브라우저는 보안관련 업데이트를 자주해야 하는 특징이 있는데, 이러한 사실에 초점을 맞춰서 구글이 개발한 하나의 알고리즘입니다. 업데이트 바이너리의 사이즈를 최대한 줄여서 구닥다리 모뎀을 사용하는 사용자들도 빠르게 다운로드받고 업데이트할 수 있도록 하자는 것이 핵심입니다.

어떻게 동작하는지 살펴봤는데, 간단하게 요약하면 다음과 같습니다. 소스코드에서 몇 줄짜리 변경이 실행파일에 어떤 변화을 주는지 bsdiff로 살펴보면 바이너리 전역에서 광범위한 변화가 목격되는데, 그 원인을 찾아서 없애보자는 것이죠. 즉, 텍스트 형태인 소스에서 코드의 변화량과 바이너리 형태인 실행파일에서 바이트 변화량이 서로 선형적 비례관계를 갖도록 만들고 싶다는 것입니다.

두 변화량이 비대칭인 이유를 살펴보니, 프로그램 로직에 따라 특정 주소로 점프를 하거나 참조하는 부분에서 이 주소값들이 매번 다른 값으로 바뀌기 때문이랍니다. 코드에서는 이런 것들이 심볼로 고정되어 있는 반면, 바이너리에서는 링킹(linking) 단계를 거치면서 이것이 실주소값으로 결정되어 바뀌기 때문에 한두줄 코드 변화가 실행파일에서는 광범위한 변화를 일으키게 되는 것이죠.

이제 해법은 나왔습니다. 두 바이너리에서 이러한 주소값들(internal pointers) 찾아내서 심볼로 대체한 뒤 bsdiff를 수행하면 되겠군요. 물론 뒤에 심볼테이블이 추가되겠죠. 아, 그리고 클라이언트에서도 bspatch를 수행하기 전에 업데이트될 바이너리를 분석해서 심볼테이블을 만드는 작업이 필요하겠군요.

이렇게 말하니깐 쉬워보이는데, 기술적 경중을 떠나 중요한 점은 이런 것을 시도한다는 점이 아닐까 싶습니다. 업데이트가 잦기로 따지면 온라인 게임도 둘째가라면 서럽습니다. 물론 특성상 업데이트 팩에서 실행파일의 비중이 현저히 작아 Courgette 알고리즘은 그다지 쓸모있지는 않겠지만, 업데이트 사이즈를 줄이기 위해서 어떤 노력을 기울여 왔는지 생각하게 됩니다.

속도를 최고의 덕목 중에 하나로 생각하는 구글이니 그럴 수 있다는 생각이 들면서도, 사소하게 넘어갈 수 있는 부분에서도 새로운 시도를 한다는 것이 부럽기도 하고, 좋아 보이네요.

나중에 필요하면 쓰려고, 개인적으로 링크만 걸어놓았던 것인데, 정리해서 올려봅니다.
원본 기사를 보시려거든 이곳으로 가보세요.


1. VLC - 비디오 뷰어인데 변환 기능도 가지고 있다네요.
2. FoxIt Reader - 작고 빠른 PDF 리더.
3. Pidgin & Adium - 인터넷 메신저 클라이언트.
4. IrfanView - 이미지 뷰어.
5. FireFox - 웹브라우저.
6. 7-Zip - 파일 압축/해제 도구.
7. Opera - 웹브라우저.
8. Revo Uninstaller - 확실하게 uninstall하고 싶을 때 사용하는 것.
9. Ever Note - 여러 가지 플랫폼에서 데이타를 관리할 수 있도록 도와주는 도구라네요.
10. Notepad++ - 문서/코드 편집도구.
11. CCleaner - 시스템 정리.
12. Skype - VoIP, 비디오 컨퍼런스 툴.
13. InfraRecorder - Burning and ripping CD/DVD.
14. TextPad & Smultron - 코드 편집도구.
15. CutePDF Writer - PDF 생성도구.
16. FileZilla - FTP 프로그램.
17. Malwarebytes Anti-Malware - 빠르고 품질도 괜찮다는 악성코드 제거도구.
18. Audacity - 오디오 편집툴.
19. KeepPass - 패스워드 관리툴.
20. AbiWord - 워드프로세서.
21. GIMP & Paint.NET - 포토샵의 일종이라고 말하는게 편하겠죠?
22. Belarc Advisor - 윈도우 PC에 대한 하드웨어/소프트웨어 full system audit을 해준다고 합니다.
23. Everything - 윈도우에서 파일을 쉽고, 빠르게 찾을 때 쓰는 거랍니다.
24. TrueCrypt - 디스크 암호화 도구.
25. Launchy - 윈도우에서 간단한 타이핑으로 어플리케이션을 찾고, 실행할 수 있도록 도와준답니다.

SIGGRAPH를 포함한 저명 그래픽스학회들의 논문 제출수(submitted)와 채택논문수(accepted) 및 논문채택비율(acceptance rate)을 연도별로 일목요연하게 정리한 사이트를 발견했습니다.

제가 가장 관심을 가지고 있는 블로그들 중에 하나를 통해 알게 되었는데요, 이 블로그에는 SIGGRAPH의 관련자료를 그래프로도 그려놓았으니 참고하시면 좋을 듯 합니다.

석사를 졸업하면서 쓴 첫 논문은 작년에 CGI(Computer Graphics International 2008)에 채택되었습니다. CGI 데이타도 있어서 살펴보았는데, 220개의 논문이 제출되고, 그 중 39개의 논문이 채택되었더군요. 40개의 short paper는 제외하구요. 그래서 채택율이 18% 였습니다. 물론 SIGGRAPH처럼 좋은 논문들이 많이 몰리는 conference는 아니지만 그래도 꽤 경쟁율이 높았었네요. 신기합니다.

회사에 다니면서도 내용있는 논문을 꾸준히 쓰고 싶었은데, 과연 지금같은 생활패턴으로 가능할지 모르겠습니다. 주말에는 늘어지고, 일이 끝나고 나면 머리는 방전된 느낌이니 말이죠. :)

피싱 사기 조심하세요.

분류없음 | 2009/07/01 13:11 | dwha
예전에 쓰던 네이트온 아이디가 해킹 당했습니다. 게다가 피싱(phishing) 사기에 악용되었더군요. 이상하게 생각한 친구들이 연락을 줘서 그 사실을 알았습니다. 부랴부랴 사이버 수사대에 신고를 했는데, 그쪽에서도 뾰족한 수가 없다고 하네요. IP주소가 중국발인데다가 계좌번호도 사기치는 놈들 것이 아니라서 잡기가 힘들다고 합니다.

놀란 가슴을 붙잡고 이참에 안 쓰고 있는 계정들은 모두 삭제를 해버렸습니다. 그리고 자주 쓰는 사이트들의 암호도 싹 바꿨습니다. 제가 타이핑하기도 힘든 패스워드로 말이죠. 까먹을까봐 걱정입니다.

새삼 보안의 중요성을 느끼게 되네요. 암호를 너무 쉬운 것으로 쓰던 제 잘못입니다. 주변에 이런 일로 피해보시는 분들이 없었으면 좋겠네요. 죄송한 마음 뿐입니다.
태그 : 피싱,해킹