Thoughts2014.04.19 23:28

지나친 낙관 쪽으로 편항되어 있는 인간의 판단력은 대체로 신뢰하기 어렵다. 


그런 편향이 문제를 일으키는 것을 알기 때문에, 인간은 '비관적으로 판단하는 능력'을 학습하기 위해 부단히 노력해 왔다. 그러나 영화 '밀레니엄'에서도 확인할 수 있듯, 인간은 때로 'CLEAR AND PRESENT DANGER' 를 느끼면서도 그 위험을 회피하지 못하는 이상한 행동양태를 보인다. 과연 이 문제는 절차적 엄밀성으로 해결할 수 있는가. 나는 아니라고 생각한다. 





근본적으로, 잘못된 판단의 결과로 일어날 수 있는 재앙의 규모가 크다면 우리는 그 판단에 인간의 낙관적 편향이 끼어들 수 있는 기회를 제거해야 한다. '배가 기울고 있다'는 위험을 느꼈을 때, '조금 더 기다려도 되겠지'라는 낙관적 편향에서 오는 잘못된 결정을 내릴 확률을 0에 가깝게 떨어뜨려야 한다. 


그렇다면 해답은 자동화다. 무조건적으로 최대한 비관적인 결정을 내리도록 안전 절차를 수정하고 자동화해야 한다. 배에서 이상이 발견되면, 무조건 모든 승객을 하선시키도록 결정 절차를 자동화해야 한다. 사람이 죽는 것 보다는 안전 관리 비용이 증가하는 것이 낫기 때문. (비관적 판단에 편향된 자동화는 평균적 안전 관리 비용을 증가시킨다.)

저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Systems/Unix / Linux2012.05.24 17:23

SSL handshake failed: SSL error: Key usage violation in certificate has been detected


프로젝트 관리를 위한 서버에 VisualSVN 최신버전을 설치하고 Centos에서 svn co (checkout)을 돌렸더니 이런 오류가 발생한다. 자격증명서(certificate)에서 Key 사용에 관한 오류가 발생하여서 SSL 핸드셰이크(handshake)를 할 수 없다는 것. 


인터넷을 뒤져 이 문제가 libneon과 GnuTLS 등등에 있다는 것 까지는 알아냈는데, Centos에는 관련된 라이브러리가 설치되어 있지 않은 것처럼 보이는데도 문제가 생겨서 해결이 난감.


그래서 또다른 우회책을 찾았으니...


일단 VisualSVN 서버가 깔린 기계에서 regedit을 돌린다. 그리고 다음의 필드 추가.




즉, CreateGnuTLSCompatibleCertificate를 DWORD 타입으로 추가해서, 그 값을 1로 설정하는 것.


이렇게 한 다음에 이제 VisualSVN 서버에서 개인 자격 증명을 추가하면 되는데... 절차는 이렇다. 우선 VisualSVN 서버 관리자 화면의 왼쪽 Pane에서 최상위 노드를 클릭한 다음, 마우스 오른쪽 버튼을 누르고 Properties를 선택한다. 




그런 다음에 뜨는 창에서 Certificate를 선택하고, Change certificate를 누른다. 그리고 개인 자격 증명을 생성한다. 




이렇게 하고 Centos 쪽에서 Checkout을 실행해 보면, 다음과 같은 화면이 뜬다. 



지운 부분은 보시면 안되는 부분이니까 궁금해하지 마시고.. (수줍) 


아무튼 P를 선택하고 영구 승인을 한 다음에, 그냥 쓰면 된다. 개인 인증서라는게 껄쩍지근한 분들은 다른 해결책을 인터넷에서 찾아보시기 바라고.. ㅋㅋ


64비트 윈도우즈에서는 Registry 편집을 좀 달리해 주어야 할 수 있는데, 거기에 관해서는 아래의 링크를 참고하시기 바란다. 


http://www.visualsvn.com/support/topic/00056/



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 잘보고갑니다^^ 몰랐던 정보네요~

    2012.05.25 21:56 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2011.11.01 10:33
요즘 브라우저가 탭 기반으로 가다보니 한 번에 여러 탭을 열어놓고 웹을 서핑하는 일이 많아졌습니다. 그런데 보통은 한 번에 열어놓는 탭들이 서로 관련 있는 탭들인 경우가 많죠. 제가 블로그에 글을 올리려고 한다 칩시다. 그러면 관련 자료를 찾는 작업이 동시에 이루어져야 할 거에요. 그러다보면 열려 있는 탭들이 굉장히 많아지죠. 

그런데 실수로 그 탭들을 전부 다 닫아버렸다면?

낭패가 아닐 수 없겠죠. 이런 일을 방지하려면 아마 어떤 시점에 어떤 탭이 열려 있었는지 로그를 다 남겨 두면 될거에요. 그리고, 열린 탭들을 그룹으로 한 번에 로깅해 둘 수 있다면, 나중에 그 탭들을 전부 한꺼번에 열어서 중단했던 작업을 재개할 수도 있을 거구요.

이런 작업을 도와주는 재미있는 어플이 크롬 웹 앱 스토어에 올라와 있습니다. 일명 TimeMarks.


타임마크를 쓰면, 내가 어떤 시점에 어떤 탭들을 열어놓고 있었는지 저렇게 한 번에 확인할 수 있습니다. 물론, 그러려면 북마크 남기듯이 타임마크를 남겨둬야 하죠. (그래서 '타임마크'라는 이름을 쓴듯.)


타임마크는 크롬 브라우저에 앱을 설치하고 나면 보이는 확장 버튼을 눌러 남길 수 있어요. 타임 마크를 찍을 때, 그 마크가 무엇에 관한 것인지 주석을 달아놓을 수도 있죠. 타임마크의 색상을 달리 부여할 수도 있어서, 나중에 찾아볼 때 요긴하게 쓸 수도 있습니다.

물론 그게 다는 아니어서...


내가 어떤 웹 사이트를 돌아다녔는지에 대한 기록도 확인할 수 있죠. 옆에 시간 축이 함께 그려지기 때문에, 이 시간 축을 통해 '아... 내가 그 때 뭔 사이트를 보고 있었는데 그 사이트가 어디였는지 기억이 나질 않아...' 와 같은 유형의 문제를 해결할 수 있습니다. 


타임마크는 위와 같이 크롬 웹 스토어에 공개가 되어 있구요.

그런데 사실 이 타임마크 프로그램은 같이 공개된 YouPivot이라는 프로그램과 쌍이에요. 이 프로그램에 관한 기사는 IEEE Spectrum 10월자에도 실렸는데, http://spectrum.ieee.org/computing/software/a-prototype-of-pivot-searching 결국 지향하는 것은 시간 축을 고려한 검색이죠. 


근데 단순히 시간 축만 고려하는 건 아닙니다. 인간이 기억하는 방식을 모사하려고 해요. 가령 '내가 어떤 음악을 듣고 있었는데 그 때 이런 웹 페이지를 보고 있었거든. 그런데 뭐였는지 기억이 안나...' 와 같은 상황이 생겼을 때, '내가 듣고 있던 음악'을 축으로 삼아 그 음악과 관련된 웹 사이트를 검색할 수 있도록 한다는 것이죠. 시간축을 고려한 연관기억검색 정도가 되려나요?

YouPivot 프로그램 또한 크롬 웹 스토어에 공개가 되어 있는데, 아쉽게도 제 브라우저에서는 동작을 제대로 안해서 그 맛을 온전히 볼 수는 없었습니다만, http://youpivot.com/ 이곳에 관련 정보가 있으니 한번 찾아보시는 것도 좋을 것 같아요. 재미있는 시도이고, 인지과학을 기억 관리를 위한 소프트웨어에 접목한다는 측면에서 살펴볼 가치가 충분합니다. 


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. this’s a great point

    2011.11.01 21:21 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. Thanks for posting Really Such Things

    2011.11.01 21:21 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. Wow i was looking for this thanks for sharing this with us.

    2011.11.01 21:22 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 일반적인 웹브라우저 히스토리 기능에 날짜 표시를 더했군요. 이건 웹브라우저에 내장해도 좋을것 같은 기능입니다.
    헌데 웹페이지 타이틀이 없는 경우에는 구분하기가 애매하네요. 또한 링크를 휠클릭해서 새 탭으로 열어야 기능을 활용하기 좋을 것 같습니다. 잘 보고 갑니다.

    2012.01.12 11:57 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2011.03.17 09:44

오늘 뉴스를 보다보니 후쿠시마 원전 건설 과정에 참여했던 분의 글이 화제가 되고 있더군요. http://www.viewsnnews.com/article/view.jsp?seq=73255 여기서 원문을 보실 수 있습니다. 글을 읽다보니 참으로 많은 생각이 떠올랐습니다. 그 분의 말이 사실이라고 가정합시다. 우리는 뭔가를 만들면서 비슷한 실수를 저지르지 않고 있다고 할 수 있을까요?

왜, 이러한 일이 일어난 것일까요. 그 근본적인 원인은 오로지 도면상의 설계에만 중점을 두고, 현장에서의 시공, 관리를 소홀히 했기 때문입니다. 비단 그것이 직접적인 원인이 아닐지라도, 이러한 사고는 발생할 것입니다.

우리도 마찬가지 실수를 종종 저지르고 있는 건 아닐까요? 설계를 너무 중요하게 생각한 나머지, 개발은 '돌아가게만 하면 된다'고 생각하는 오류를 저지르고 있는 건 아닐까요?

십여 년 전 까지는, 현장작업에 보신(봉심)이라 부르던 전문 기술자, 현장의 젊은 감독자 이상의 경험을 쌓은 전문가가 반장으로서 반드시 있었습니다. 전문가는 자신의 일에 자부심을 갖고 있어, 사고나 하자가 발생하는 것을 수치스럽게 여기며, 사고의 두려움도 잘 알고 있었습니다. 그러던 것이 10년 쯤 전부터, 현장에 전문가가 사라졌습니다. 비전문가들을 경험 불문이라는 형태로 모집하고 있습니다. 비전문가인 사람들은 사고의 무서움을 모르며, 어떤 것이 부실 공사인지, 어떤 것이 하자인지도 전혀 모르고 작업을 하고 있습니다. 그것이 현재 원전의 현실입니다.

우리는 어떻습니까? 지금 프로그래밍을 하고 있는 현장에 전문가는 존재하나요? 프로젝트 완료를 위해 경험 없는 개발자들이 낮은 임금에 개발과 교육을 동시에 진행하도록 강요받으며 투입되고 있지는 않나요? 현장에 있었던 전문가를 '더 훌륭한 일을 하도록' 다른 곳에 배치하고 있지는 않나요?

현장에 전문 기술자가 줄어들면서, 비전문가들도 건설, 제작을 할 수 있도록, 공사 과정이 설명서(manual)화되었습니다. 설명서화라 함은, 도면을 보며 건설을 하는 것이 아닌, 공장에서 어느 정도 조립된 부품을 가져와서, 현장에서 1번이면 1번, 2번이면 2번 하는 식으로, 그저 나무 블럭을 쌓아 올리듯 짜 맞추는 것을 말합니다. 그렇게 하면, 지금 자신이 무엇을 하고 있는 것인지, 얼마나 중요한 일을 하고 있는 것인지, 전혀 알지 못한 채 조립을 하게 됩니다. 이러한 것도, 사고나 고장이 빈번히 일어나는 원인 중 하나입니다.

여러분이 테스터라면, '이렇게 저렇게 테스트하라'고 지시하는 스크립트의 지령대로, 기계화된 테스트를 하고 있지는 않습니까? 그 과정에서 여러분의 창의력을 발휘할 기회는 혹 박탈되고 있지는 않나요? 무엇을 하고 있는지도 모른 채, 오직 테스트를 위한 테스트만을 하고 있지는 않습니까?

검사관이 용접이면 용접을, ‘그게 아니지. 잘 봐요. 이렇게 하는 거지.’라고 스스로 실연(實演)해서 보여줄 기량이 없다면, 진정한 검사는 이루어지지 않습니다. 그러한 기량이 없는 검사관이 착실한 검사를 할 수 있을 리가 없습니다. 건설사나 시공주의 설명을 듣고, 서류만 갖추어져 있으면 합격을 시키는, 이것이 현재의 관청 검사의 실태입니다.



이 외에도 원문에는 참으로 많은 이야기들이 적혀 있습니다. 

이 세상에는 규정을 지키는 것 만으로 막을 수 없는 많은 위험 요인들이 존재합니다. 그래서 '시장은 천천히 좋아질 것이다'라는 낙관적인 관점의 투자자가, '언젠가는 911같은 사태가 또 일어날 것이다'라고 가정하는 비관적 투자자에게 패배하기도 하고, 규정을 '엄격히' 지켜 만들었다고 생각하는 우주 왕복선이 대기권을 벗어나 보지도 못하고 폭발하기도 합니다. 

규정은 사람이 만드는 것이기 때문에 규정 자체가 얼마나 안전한지, '허용 가능한 위험'의 위험성에 대해서 얼마나 고려하고 있는지에 대해서는 규정 자체에 대한 관리 감독이 없이는 알 수가 없습니다. 문제는 이런 규정의 헛점이 사태가 벌어진 다음에야 밝혀지게 된다는 데 있습니다.

그런 일을 방지하려면 규정-설계-실행 사이에 선순환 피드백 고리가 만들어져야 하는데, 현재 대부분의 생산 현장이나 건설현장에서 그런 피드백을 찾아보기는 힘듭니다. 

그나마 소프트웨어 개발을 하고 있는 우리들은 다행인 셈입니다. 우리는 문제가 생기면 '그다지 큰 부담 없이' 문제를 보고하고 그 해결책을 논의할 수 있습니다. 어쩌면 그것이 '소프트웨어'의 진정한 '소프트'함이 아닐까 싶기도 합니다. 

하지만 이미 쌓아올린 원전이나 다리, 건물같은 구조물에 이르면, 이야기가 조금 달라집니다. 그런 구조물들은 그야말로 '하드'한 구조물이기 때문입니다. '하드'한 구조물을 안전하게 구축하려면 그 구축과정의 윗 부분과 아랫 부분을 연결하는 피드백 고리가 가능하면 짧아야 합니다. '다 만들고 감사받는다'로는 부족하다는 이야기입니다. 

우리는 소프트웨어 개발 분야에서 우리가 얻은 교훈들이, 앞으로 더 늦기 전에 많은 분야에 반영되기를 희망합니다. 그렇지 않으면, 이런 재앙은 막기 어려울 것입니다. 

또한, '낙관적'으로 가정할 수 있는 부분은, 오직 '인간이 본질적으로 선함' 이상도 이하도 아니라는 점을 모두가 깨닫게 되기를 소망합니다. 그리하여 좀 더 철저하고, 좀 더 보수적인 개발과 구축 문화가 뿌리내리기를 희망합니다.

그리고 가능하면, 원전과 같이 재앙의 리스크가 너무나 높은 기술은 가급적인 도입을 자제할 수 있게 되기를 희망합니다. 많은 분들이 '리스크는 관리 가능하다'고 생각하십니다. 네. 물론 관리할 수 있겠지요. 하지만 인간의 '실수'는 대개 관리가 불가능합니다. 스리마일 섬의 사고도 그런 식으로 일어났습니다. 관리가 불가능한 실수가 연이어 터질 때, 그리고 그 실수의 결과가 인간이 통제 가능한 범위 밖에 있을때, 그 실수는 '관리가 가능하다'고 믿었던 리스크를 재앙으로 돌변시키고 맙니다.

그리고 마지막으로, 지금도 일본에서 일어나고 있는 모든 고통스러운 상황들이 곧 끝날 수 있기를 기원합니다.



신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Languages/Objective-C2009.12.17 14:11
연말이 되었는데 이런 저런 실험 탓에 기다려야 하는 시간이 많아서 시간도 때울 겸(?) 아이폰 앱을 하나 만들어 보았다. "아웃라이어"에 보면 10,000시간의 법칙이 나오는데, 요지는 10,000시간의 의도적 수련(deliberate practice)이 전문가를 만들어 준다는 것이다. 이 시간을 관리할 수 있게 하는 앱이다. (이런 거나 하고 있으니 한가해 보이는 걸까...)
 
As pointed out in the book "Outliers", a professional is made by 10,000 hours deliberate practice. This iPhone app manages time spent on your deliberate practices.

First, you define "Areas" where you want to be a professional.


Next, you define "activities" which comprise an area. The time spent on each activity is summed and displayed in the area view page.


By clicking activity and press "Start" button, you can count the time spent on the acvitivity. Following screen shows that I've spent 8 minutes on 'coding' activity :-)


To stop the counting, you can press "stop" button or "back" button at the top of the screen. That's it.

개인적인 용도로 써먹을려고 만들었는데, 시험삼아 공개해보는 것도 나쁘지 않을 것 같아서 앱 스토어에 등록을 신청해 둔 상태다. 어제 먹은 술이 덜 깨서 등록 절차를 제대로 밟았는지도 잘 모르겠다. 

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 깔끔한데요! 아이폰 사면 함 다운받아보겠습니다 ^^
    그나저나, 10,000시간 채우기 전에 배터리 수명이 다하지 않을런지요.. ㅋ

    2009.12.17 18:37 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 괜찮네요 어플등록되면 다운받겠습니다.^^

    2009.12.18 09:27 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 왠지 대박 얘감!!!

    2009.12.18 10:01 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 남미영

    팀장님..역쉬..^^
    아이폰 언제 살지 모르겠으나..저도 다운받아서 사용해봐야겠습니다.
    10000시간 투자하면 아웃라이어가 될 수 있을까요?? 감사합니다.

    2009.12.18 10:49 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2009.08.31 09:42
요즘 업체와 공동 연구/개발 과제를 진행하고 있습니다.

공동 연구/개발 과제를 진행함에 있어서 최근에 느꼈던 점들을 간단하게 정리해 보겠습니다. (제가 갑의 위치이고, 공동 연구 과제를 진행하는 타 업체가 을의 관계입니다. 그러니, 제가 요구사항을 주고 그 쪽에서 그 요구사항에 맞추는 관계에 가깝습니다.)

제가 이분들과 작업을 함에 있어, Agile 적으로 진행해보려고 했습니다만, 아마 그 분들은 제가 그러고 있는지도 눈치를 잘 못채셨을 겁니다. 그냥 좀 다른 식으로 프로젝트 관리를 하는구나... 하셨겠죠. 굳이 강제한 부분이라면 일일 빌드 서버를 만들어 달라, 뭐 그정도였습니다.

1. 실무자와의 미팅에서 Pair Programming이 특히 효과적이다.

개발을 진행할 경우에, 실무자와의 미팅이 가장 중요합니다. 양쪽이 공동 개발을 진행하는 경우, 코드의 독점적인 소유권을 주장하여야 하는 부분에 있어서는 선을 지킬 필요도 있습니다만, 그렇지 않은 부분에 있어서는 실무자와 자주 대화를 갖는 것이 중요합니다. 미팅 시간은 가능한한 짧게 하고, 이슈가 되는 부분에 대해서는 집중적으로 토론을 하는 식으로 진행하여, 가급적 회의 시간이 한 시간이 넘지 않도록, 부드러운 분위기에서 진행될 수 있도록 했습니다.

이 과정에서 필요할 경우에는 Pair Programming을 진행하여 코드를 상호 검토했습니다. 가능하면 개발 쪽에서는 코드 수준에서 대화가 이루어지도록 신경을 썼습니다. 그러다보니 코드에 대한 상호 이해도가 높아져 시간이 흐르자 더욱 편안한 분위기에서 대화를 진행할 수 있었습니다.

Pair Programming이 어느 정도 익숙해지자 나중에는 전화로도 코드를 상호 검토할 수 있게 되었습니다만, 아무래도 실험 환경이 갖추어져야 확인할 수 있는 버그는 원격지에서 상호 검토하기가 어려웠습니다. 그런 부분은 어떻게 해결해야 할 지 좀 더 연구를 해 보아야 할 것 같습니다.

2. 일정을 맞추는 데는 1주 단위의 이터레이션이 효과적이다

9월 초까지 개발을 완료해야 한다는 압박때문에 1주 단위로 이터레이션을 진행한 부분이 있었습니다. 매주 이슈를 확인하고, 매주 일의 우선순위를 재검토했습니다. 다행히 우선순위가 자주 바뀌는 일은 없었습니다만, 그래도 매주 결과물을 확인하고 진도를 재검토했기 때문에 모두 긴장감을 유지하면서 작업을 진행할 수 있었습니다. 1주가 효과적으로 먹힐 수 있었던 데는 프로젝트에 참여햇던 개발자의 역량이 뛰어났던 것도 한 몫을 했겠습니다만, 매주 시연을 하고 결과물을 확인할 수 있었던 것은 아무래도 초기부터 '매주 결과물을 시연한다'는 원칙을 세우고 작업을 했기 때문에 가능했던 일일 것 같습니다. 덕분에 개발 시스템은 언제나 '통합 가능한 상태'를 유지할 수 있었습니다.

문서를 만든다거나 하는, 개발자에게 자칫 부담으로 다가올 수 있는 부분은 제가 최대한 지원하고, 남은 부분을 그쪽에서 매꿔 넣는 식으로 결과물을 만들어 냈습니다.

3. 제품 책임자(Product Owner)는 가능하면 갑과 을이라는 관계를 잊어야 한다

'마이클 콘'도 저와의 개인적 서신에서 언급한 바 있습니다만, 제품 책임자는 제품의 성공을 담보할 책임을 지는 사람이지 갑과 을의 관계를 관리하는 책임을 지는 사람이 아닙니다. 갑과 을이라는 관계는 잠시 잊고, 공동선을 추구하는 것이 바람직합니다. 가급적이면 실무에 직접 뛰어들 수도 있는 역량을 가져야 하고, 외부로부터의 갑작스러운 요구사항 변동을 적절한 수준에서 차단할 영향력도 가지고 있어야 합니다. 특히 제품 개발에 있어서 '추가될 기능의 우선순위'를 정하는 데 영향력을 행사할 수 있어야 합니다.

그래야 원활한 프로젝트 진행이 가능해 집니다. 특히 제품 책임자로서 사람들과 대화를 할 때는 가급적 NVC 원칙 (Non-violent communication) 원칙을 지키도록 해야 합니다. 대화에 감정이 끼어들기 시작하면, 소통이 불가능해집니다. 일이 꼬이고 있다면, 가급적 그 책임은 자신에게 있다는 자세를 가질 필요도 있습니다.

- - -

요즘 머리가 아픈 일이 많아서 블로그 업데이트를 잘 못했습니다. 체중도 현재 63키로입니다. (제 키는 171입니다) 운동 중독증에 가깝게 운동을 해 댄 탓도 있겠습니다만, 식사를 제때 못하거나 건너뛴 탓도 있는 것 같습니다. 가끔 들러 제 글을 기다려주신 분들께 사과말씀 드립니다.

개인적인 문제도 있습니다만, 요즘 프로젝트 일정이 너무 빡빡합니다. 9월 8일로 예정된 시연도 차질 없이 준비해야 하고요.
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. soultemple

    고생한 만큼의 결과가 나올때 기쁜거죠. 마무리 잘하시고 유익한글 남겨주시길 ...

    2009.08.31 13:06 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 재미있는 프로젝트네요.
    좀 더 많은 프로젝트가 재미있어지면 좋겠는데요...^^

    물론, 일일빌드 성공, 1주의 이터레이션, 짝프로그래밍의 적용이
    개발자에게 상당한 부담이 될 수도 있을 것 같습니다.
    중간에 한눈 팔 수 없게 하니까요...^^

    2009.09.01 10:37 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그래서 많은 부분을 개발자의 자율에 맡겼습니다. 간섭은 최대한 배재하려고 했죠. (간섭하기도 힘든 상황이었습니다만...) 어쨌든 좋은 결과를 얻고 있습니다.

      2009.09.01 13:53 신고 [ ADDR : EDIT/ DEL ]
  3. 수고하셨습니다. 후배들에게 사례로 언급해도 될까요?

    2009.09.05 14:31 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 비밀댓글입니다

    2009.12.10 13:51 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2009.02.18 13:24
순서는 아무 의미가 없으므로 개의치 마시길. 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 서버가 보여주는 빌드 리포트가 너무 건조하다

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

[계속 수정됨...]


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. dhyi123

    CI 라는 것이 무엇의 약자인지요? CI 서버라는 것은 cvs 서버이면서 테스트도 같이 해서 리포트도 보내는 등 여러가지 역할이 있는 거 같네요. 개발자가 신규로 개발하는 경우는 해당 단위 테스트를 새로 추가해야 CI 서버도 자종으로 동작하겠죠? (제가 좀 무식해서.. ^ ^)

    2009.02.18 14:46 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • Continuous Integration의 약자입니다. Hudson, CruiseControl 등의 제품이 있는데 저는 Hudson을 사용합니다. ^^

      2009.02.18 14:53 신고 [ ADDR : EDIT/ DEL ]
  2. 이병준 선배님, 저 조영일입니다.
    오래간만에 인터넷에서 뵙네요.
    메타블로그에서 이것저것 찾다가 우연히 발견해서 들어오게 되었습니다.
    OO 전문가에 소설도 쓰시니 딱 알아보겠더라구요.
    잘 지내시죠? 식구들 모두 건강하시구요?
    둘째가 아주 귀엽던데, 건강하게 잘 크는지 궁금합니다.

    2009.02.23 18:30 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 100% 공감합니다. 특히 3번 항목은 제가 얼마전까지도 잘못 하고 있던 내용이군요.
    '불확실성과 화해하는..'책을 읽기 시작하면서 블로그 방문해 보았습니다.
    좋은 글들 많이 부탁드립니다.

    2009.03.24 13:11 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 좋은 글 잘 봤습니다. 다 공감합니다.
    1번 같은 경우는 예전에 써놓은 글이 있어서 트랙백으로 겁니다.

    2011.06.20 09:47 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2007.10.08 02:07
평판이란 무엇일까요? 평판이란 이미지이기도 합니다. 이미지는 '다른 사람에게 내가 어떤 모습으로 비추어지느냐'는 물음에 대한 대답이지요. 좋은 이미지를 싫어하는 사람은 없습니다. 프로그래머도 마찬가지입니다.

프로그래머라는 부류의 사람들을 세상은 굉장히 단순하게 파악하는 경향이 있습니다. '길고 흰 손가락을 가진 마르고 성마른 외모를 가진 20대 초반에서 30대 중반까지의 남성으로, 안경을 착용하였으며 대인관계에 어려움을 겪고, 사람과 소통하는 것 보다는 국방성 데이터베이스를 해킹하는 데 더 재미를 느낀다.' 뭐 이정도가 세상 사람들이 알고 있는 '프로그래머', 엄밀하게는 IT 업계 종사자의 이미지죠. 이런 이미지를 만드는 데는 아마 헐리우드가 단단히 한 몫을 했을 겁니다.

그래서인지는 모르겠습니다만, 대부분의 프로그래머는 '세상 사람들이 자기를 어떻게 보느냐'보다는 '관련 업게 종사자들이 자기를 어떻게 보느냐'를 더 중시합니다. 세상사람들은 어차피 모든 프로그래머를 다 똑같이 취급하므로 (그런 점에 있어서는 군대 계신 분들과도 비슷한 면이 있습니다 ㅋㅋ) 같은 직종에 있는 사람에게나 좋은 소리를 듣는 것이 여러가지로 이롭다는 것이죠. 다른 직종도 마찬가지라구요? 아니요. 그렇지는 않습니다.

* * *

그렇다면 프로그래머는 '다른 프로그래머들' 혹은 '같은 직장에 있는 다른 근무자들'에 대한 자신의 이미지를 어떻게 하면 보다 개선할 수 있을까요? 오늘은 가장 간단한 방법 하나를 가르쳐 드리겠습니다[각주:1].

사용자 삽입 이미지
많은 사람들이 책꽃이에 책을 꽂아 놓습니다. 하지만 프로그래머들에게 있어서 책은 참고서로서의 활용도가 더 높기 때문에, 가능하면 책을 꽂아놓지 않는 것이 더 좋습니다. 자주 보는 책들을 책상위에 꺼내 놓고, 위의 그림처럼 쌓아놓도록 합시다. (제목이 잘 보이도록 쌓아놓으면 더 효과적입니다.) 그러면 사람들은 당신이 프로그래머임에 틀림없다고 믿습니다.

책을 쌓아놓으면 책상에 '나름대로 의미가 있는 무질서'를 부여할 수 있을 뿐 아니라, 자리를 비운 사이에 상사가 파티션 사이를 오락가락 하는 경우에도 자신의 이미지를 긍정적으로 관리할 수 있습니다. 상사는 당신의 책상 위에 있는 책들을 보고 당신에 대한 보다 긍정적인 생각을 가지게 될 것이고, 책상 위에 부여된 무질서는 당신의 이미지를 보다 신비롭게 바꿔줄 것입니다. 프로그래머에게 있어서 너무 깔끔한 책상은 별로 매력이 없습니다.

하지만 이런 효과가 지속적으로 발생하도록 하려면, 책상 위에 쌓아둔 책들을 주기적, 혹은 비주기적으로 셔플(shuffle)하는 것이 좋습니다[각주:2]. 그래야 당신이 그 책들을 지속적으로 보고 있다는 인상을 다른 사람들에게 심어줄 수가 있습니다.

하지만 몇가지 주의할 점도 있습니다. 책의 목록이 사람들에게 노출되도록 해야 한다는 점이 중요하기 때문에, 가급적 뭔가 '있어보이는' 책을 골라야 한다는 점입니다. 당신이 만일 C++로 프로그래밍을 하는 프로그래머라면, Template Metaprogramming에 관한 책을 구매해서 쌓아두면 좋을 것입니다.

명심하세요. '널리 알려진 책'이면서 또한 '쉽게 읽히지 않는' 어려운 책일 수록 효과가 높습니다. 그런 점에 있어서는 Donald Knuth 교수의 "The Art of Computer Programming" 시리즈가 이미지 관리용으로는 최고의 도서라고 할 만 합니다.

그런데 당신이 쌓아둔 책에 대해 누가 질문을 하면 뭐라고 해야 하나요? 그럴때는 최근 널리 알려지게 된 사자성어대로, '소이부답'하면 됩니다. 씩 웃어주시고, '직접 읽어보세요'라고 해주세요. 대답하기 위해 최선을 다하는 것은 좋지만, 중간에 버버거리게 되면 당신에 대한 신뢰는 떨어지게 됩니다. '보시면 알게 됩니다'가 보다 Guru 적인 대답입니다. 그렇게 해도 상대방이 계속 미심쩍어한다거나, 질문을 해 댄다면 어떻게 해야 하나요? 그럴때는 '글쎄 저도 공부중이라서요'라고 해 주는게 가장 낫습니다. 말을 많이 하려고 하다보면 실수를 하게 되니까 가급적 이런 저런 변명은 하지 않도록 하세요.

간혹 진짜 고수가 당신의 도서 목록을 보고 이런저런 질문을 해대거나, 대화를 시도하는 경우도 생길 수 있습니다. 그런 사람들은 입을 여는 순간 당신이 이해할 수 없는 말들을 토해내기 때문에, 대화를 하는 순간 바로 알아챌 수 있습니다. 그런 사람을 만나면, 가급적 오랜 시간 대화를 하면서 그 사람이 하는 말을 잘 들어두세요. 그 사람이 하는 말을 잘 들어두고 외워두면, 나중에 다른 사람이 비슷한 질문을 할 때 대답으로 써먹을 수도 있어 좋습니다.



  1. 물론 농담입니다. [본문으로]
  2. Life is Shuffle. [본문으로]
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 완벽하군요. 이런 비법을 알고 계셨다니.

    2007.10.09 20:52 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. ssoon

    정말로 완벽합니다.

    2007.10.16 09:59 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 저는 마지막 부분을 이렇게 수정해봤습니다. ^^ 글이 참 재미나내요.
    잘 들어두세요. 그 사람이 하는 말을 잘 듣고 있으면 겸손하고 유연한 개발자라는 이미지를 보다 공고하게 할 수 있습니다.

    2009.04.14 18:19 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 낭만고양이

      재미있게 읽어주셔서 감사합니다. ^^

      2009.04.28 23:33 신고 [ ADDR : EDIT/ DEL ]