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

이 툴을 사용하면 간단한 Issue tracking 시스템을 별 다른 수고 없이 구축할 수도 있는데요. 물론 SVN같은 외부 repository와 동기화한다거나 하는 작업은 안됩니다. Evernote 플러그인을 구현할 수 있다면 별문제겠지만, 가능한지는 잘 모르겠군요.

아무튼, 방법 자체는 이렇습니다. 

우선, Evernote를 설치하고 계정을 만듭니다. 그리고 Evernote를 실행합니다. 

다음으로 할 일은 공유될 Issue가 보관될 노트북을 만드는 것입니다. 

만들었다면, 해당 노트북을 공유하도록 지정합니다. 화면 좌측에 보면 "공유" 탭이 있는데요. 이 탭을 클릭하면 어떤 노트북을 공유할 것인지를 지정할 수 있습니다. 노트북 이름 옆에 있는 "공유 시작" 버튼을 누르면 해당 노트북을 공유할 수 있습니다. 이 때 공유할 사용자를 명시적으로 지정해 주어야 합니다. 

공유할 사용자를 지정하기 위해서는 해당 사용자에게 초대장을 보내야 합니다. 초대장을 발송할 메일 주소를 기입하고 "초대" 버튼을 누르면 됩니다. 프리미엄 버전 사용자라면, 초대받은 사용자가 공유하는 노트북을 수정까지 할 수도 있도록 지정할 수 있는데, 프리미엄 버전 사용자가 아니라면 그렇게 할 수는 없습니다. 공유된 노트북의 내용만 볼 수 있죠. 

아무튼 위와 같이 해서 노트북을 공유했다면, 해당 노트북에 이제 노트를 삽입하면 됩니다. 그러면 공유 사용자들이 모두 그 노트들을 볼 수 있습니다. 

하지만 Issue-tracking을 하려면 노트를 삽입할 때 약간 주의를 해야 하는데요. Issue가 진행중인지, 아니면 close된 것인지, 누가 해당 노트에 포함된 Issue를 처리해야 하는지 지정해야 하기 때문입니다. 

이런 '지정' 작업은 노트에 '태그'를 부여해서 처리할 수 있습니다. 처리해야 할 사람의 아이디, doing/done 등의 태그를 노트에 넣으면, 사용자들이 태그를 사용해 노트북을 검색해서 자신에게 할당된 issue, 진행중인 issue 등을 검색해 볼 수 있는 것이죠. 검색은 Evernote의 검색 기능을 활용해서 하면 됩니다.

복잡한 Issue tracking 시스템에 거부감이 있는 분, 혹은 Issue tracking 시스템까지 도입하기에는 작은 프로젝트를 진행중인 분들은 Evernote를 이런 식으로 사용해서 약간의 이득을 보실 수 있겠습니다. 



Posted by 이병준

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

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

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

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

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

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



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

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

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

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

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

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

  1. 혹시 하드웨어 과목을 담당하는 교수님 탓 아닐까요? ㅎㅎ
    저도 하드웨어과 소프트웨어가 어떻게 연결되는지 지금도 잘 감이 안 오는데
    추천해주신 이 책 한 번 읽어보려고 합니다. 제가 해왔던 공부와 일도 그렇고 지금 하는 일도
    하드웨어하고는 좀 멀긴 하지만 공부는 언제 어떤 상황에서든 계속 해야 한다고 생각이 들어서요...

    2010.10.20 23:47 [ ADDR : EDIT/ DEL : REPLY ]

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 이병준

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

  1. 기억상실

    동감합니다.
    추정을 하기위한 실험을 완료하면 연달아 프로그램도 완성되곤 합니다.
    결국 실험하는데 몇 일이 걸리고 공식적인 일하는데는 하루 이틀 밖에 안걸리는 셈이죠.
    이런 과정을 거치면 대부분의 경우 결과가 매우 만족스럽습니다.

    문제는 주위에서 바라보는 눈길이 곱지 못합니다.
    금새 될 일을 분석한답시고 몇일씩 끼고 앉아서 놀았다는 오해를 받지요.

    2010.10.14 10:45 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile2010. 8. 2. 15:02
  • 별로 하는 일 없어보이는 팀원도, 스스로는 '나름대로 열심히 하고 있다'고 생각한다. 다만 뽀대나게 일하는 방법을 모를 뿐이다.(관리자 법칙 12) 2010-04-12 20:31:04
  • 팀원을 통제하는 가장 효과적인 방법은 어떤 상황에서도 감정적으로 흔들리지 않는 것이다. 토론 중에 이성을 잃는 관리자만큼 없어보이는 사람도 드물다.(관리자 법칙 13) 2010-04-12 20:53:49
  • 회의실에 노트북을 지참하는 팀원이 많다는 것은 회의가 길고 지루하다는 뜻이다. 해결책은 두가지이다. 회의실에 무선 AP를 끊던가, 회의를 짧고 굵게 하던가.(관리자 법칙 14) 2010-04-13 12:15:52
  • 프로그래머를 긴급 수혈해서 일정이 단축되는 경우는 거의 없다. 확률로만 따지면 푸닥거리 쪽이 더 높을 지도 모른다.(관리자 법칙 15) 2010-04-13 15:16:55
  • 불확실성을 관리하는 가장 좋은 방법은 불확실하다는 사실을 가능한 한 빨리 드러내는 것이다. 드러내지 않으면 관리도 불가능하다.(관리자 법칙 16) 2010-04-13 17:07:59
  • 자신이 누구인지 잘 모르겠다면 평소에 무슨 생각을 하는지를 돌이켜보자. 평소에 리팩터링 생각만 하고 있다면 프로그래머일 것이고, 아키텍처 생각만 하고 있다면 아키텍트일 것이다. 다른 사람들 생각만 하고 있다면, 관리자일 가능성이 높다.(관리자 법칙 17) 2010-04-13 23:24:43
  • 잦은 야근은 개발 프로세스가 비효율적일 때 풍기는 냄새 중 하나이다.(관리자 법칙 18) 2010-04-14 01:08:14
  • 수평적인 사고는 관리자의 아집 때문에 빚어질 수 있는 재앙을 막는 데 기여한다.(관리자 법칙 19) 2010-04-14 13:14:55
  • 테스트를 게을리하는 프로그래머의 위험지수가 1이라면, 자신이 만든 테스트를 과신하는 프로그래머의 위험지수는 100정도 된다.(관리자 법칙 20) 2010-04-14 13:52:06
  • 기술적인 내용에 대한 이해도를 가늠하는 가장 좋은 방법 중 하나는, 그 기술을 설명하는 하나의 다이어그램을 성공적으로 그려낼 수 있는지를 보는 것이다.(관리자 법칙 21) 2010-04-21 11:04:37
  • 형평성은 단순히 1/N의 문제가 아니다.(관리자 법칙 22) 2010-04-22 14:40:24
  • 일을 빨리 끝내는 사람에게 일을 더 주면, 다음부터는 아무도 일을 빨리 끝내려 하지 않게 된다.(관리자 법칙 23) 2010-04-22 15:08:33
  • 팀원들로부터 최고의 생산성을 이끌어 내는 한가지 비결은, 팀원의 기여가 유무형의 보상으로 반드시 돌아오게 된다는 사실을 각인시키는 것이다. 대부분의 팀원들은 무형의 보상(좋은 평판, 늘어난 여유시간 등등)에 더 감동하는 경향이 있다.(관리자 법칙 24) 2010-04-26 10:01:38
  • 대부분의 팀원들은 상사로부터의 평가보다 동료 팀원들로부터의 평가에 더 민감하다.(관리자 법칙 25) 2010-04-26 10:02:31
  • 직무능력 개발에 어려움을 겪는 팀원이 있다면 목표를 너무 추상적으로, 너무 크게 잡고 있는 것이 아닌지 살펴보라.(관리자 법칙 26) 2010-04-26 16:34:08
  • 버그를 해결하기 전에 새로운 기능 추가를 지시하지 말라.(관리자 법칙 27) 2010-04-28 17:06:34
  • 테스트가 개발을 주도하게 하라.(관리자 법칙 28) 2010-04-28 18:08:13
  • 새로운 기능을 추가한 다음에는 시스템을 전부 다시 테스트하라. 시간이 많이 걸린다면, 자동화하라.(관리자 법칙 29) 2010-04-28 18:15:58
  • 비전을 찾지 못하는 팀원에게는, 자신의 전문성이 어디 있는지를 돌아보도록 조언하라.(관리자 법칙 30) 2010-04-29 10:23:50
  • 전문성은 동기(Motivation), 의지(Will), 시간(Time), 소통(Communication)의 네 가지 자질이 갖추어져 있어야 얻을 수 있는 자격증 같은 것이다.(관리자 법칙 31) 2010-05-03 15:36:31
  • 처음부터 완벽한 계획이란 없고, 예측은 언제나 불확실하다. 그러니 구체적인 사실에 집중하고, 완전한 일정을 만들려는 과욕은 버려라.(관리자 법칙 32) 2010-05-28 13:36:54
  • 팀원들이 자신을 미워하는 것 같으면 회의 시간에 혼자만 말하고 있지는 않은지 생각해 보라.(관리자 법칙 33) 2010-06-24 10:22:37

이 글은 공중곡예사님의 2010년 4월 12일에서 2010년 6월 24일까지의 미투데이 내용입니다.

Posted by 이병준

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

  1. duru

    ㅋㅋ 관리자법칙은 몇번까지 갈꺼에유? 콘텐츠 아이디어가 넘치네유~~

    2010.08.04 14:08 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile2010. 7. 6. 11:36
  • 전문성은 동기(Motivation), 의지(Will), 시간(Time), 소통(Communication)의 네 가지 자질이 갖추어져 있어야 얻을 수 있는 자격증 같은 것이다.(관리자 법칙 31) 2010-05-03 15:36:31
  • Segmentation Fault가 당신을 괴롭힐 때에는 Core Dump 옵션을 켜두고 나머지는 gdb에게 맡겨라.(core dump가 안될 경우에는 .bash_profile에 ulimit -S -c 4096. 자세한건 /etc/profile 참고) 2010-05-11 13:11:01
  • 디버깅은 내가 흩뿌린 비합리의 흔적들로부터 합리적인 원인을 찾아내는 과정이다.(디버깅의 도) 2010-05-11 20:41:49
  • 판도라의 상자에는 열쇠가 없다. 이미 당신의 마음 속에 열쇠가 있기 때문이다.(판도라의 상자) 2010-05-18 13:01:19
  • 처음부터 완벽한 계획이란 없고, 예측은 언제나 불확실하다. 그러니 구체적인 사실에 집중하고, 완전한 일정을 만들려는 과욕은 버려라.(관리자 법칙 32) 2010-05-28 13:36:54
  • 로지텍 K340 이거 괜찮군… ㅎㅎㅎ(키보드 K340) 2010-05-29 23:16:21
  • 로지텍 애니웨어 마우스이것도 괜찮은데? ㅋㅋ(지름의 계절인가) 2010-05-31 16:51:30
  • 몇년 동안 어렵다는 이유로 적용을 미뤘던 autoconf, automake의 적용을 두시간 만에 끝내다.(구글신에게 경배를) 2010-06-04 17:30:30
  • 심볼릭 링크가 포함되어 있는 디렉터리를 tar 할때는 -L 옵션. tar cvfL src.tar src/ 이렇게 해야 함. autoconf 적용된 프로젝트의 경우에는 더더욱.(머리가 나빠서 메모해둬야...) 2010-06-10 10:12:53
  • Java Jar 파일 내 클래스 동적 로딩(북마크) 2010-06-11 11:47:47
  • Cygwin의 POSIX pthread 라이브러리의 pthread_attr_setscope 함수는 PTHREAD_SCOPE_SYSTEM을 지원하지 않습니다.(그러니 대신 PTHREAD_SCOPE_PROCESS를 쓰시도록.) 2010-06-16 08:56:38
  • GLOBECOM 2010 논문 통과. 12월은 미국 마이애미에서.(이제 박사 졸업도 눈앞으로 다가오는 건가...) 2010-06-24 08:50:35
  • 팀원들이 자신을 미워하는 것 같으면 회의 시간에 혼자만 말하고 있지는 않은지 생각해 보라.(관리자 법칙 33) 2010-06-24 10:22:37
  • MAC에서 ._로 시작되는 파일들이 tar 파일 안에 같이 묶이는 것이 싫을 때는 bash에서 export COPYFILE_DISABLE=true를 설정할 것.(결론은 그러면 빠진다는 거) 2010-06-29 14:35:11
  • Visual Studio 2010에서 쓸만한 diff툴을 찾는다면?(CodeCompare를 시도해 보시길. 찾았던 것 중에선 가장 괜찮았어... 거기다 공짜야... ㅎㅎㅎ) 2010-07-06 11:33:25
  • 업무가 지겨울 때는 소소한 물품들을 바꿔보는 것도 도움이 된다. 키보드, 마우스, 컵, 펜, 연필, 포스트 잇 등등. 책상은 정리하고 생수라도 한통 가져다 놓자. 마실 것이 항상 옆에 있으면 금연에도 도움이 된다.(업무가 지겨울 때 1) 2010-07-06 11:34:57

이 글은 공중곡예사님의 2010년 5월 3일에서 2010년 7월 6일까지의 미투데이 내용입니다.

Posted by 이병준

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

Extremely Agile2010. 4. 11. 12:59
  • 아랫사람이 시간남는 걸 못견뎌 하는 상사를 만나면 스스로 생산적인 일을 할 가능성이 떨어진다.(관리자 법칙 1) 2010-04-09 16:39:33
  • 아랫사람이 시간남는 걸 못견뎌 하는 상사를 만나면 프로젝트 일정이 단축될 가능성이 떨어진다.(관리자 법칙 2) 2010-04-09 16:46:54
  • 자수성가형 관리자는 보통 휴식과 게으름을 같은 것으로 여긴다.(관리자 법칙 3) 2010-04-10 20:29:12
  • 자수성가형 관리자는 한 가지 일을 하는 데에도 여러 가지 방법이 있을 수 있다는 사실을 잘 모르거나 무시하는 경향이 있다.(관리자 법칙 4) 2010-04-10 20:31:25
  • 도로에 차를 100% 밀어넣으면 주차장으로 변한다. 마찬가지로, 직원에게 100%의 일감을 선물하는 관리자는 프로젝트를 성공시키기 어렵다.(관리자 법칙 5) 2010-04-10 20:51:28
  • 코딩을 좋아하는 사람에게는 코드를 주고 기획을 좋아하는 사람에게는 기획서를 주고 야부리를 좋아하는 사람에게는 차 열쇠를 주라.(관리자 법칙 6) 2010-04-10 22:55:49
  • 어떤 사람이 겉멋 든 프로그래머인지 아닌지를 판단하는 가장 좋은 방법은, 그가 작성한 주석문(comment)을 보는 것이다.(관리자 법칙 7) 2010-04-10 22:58:05
  • 지나치게 비관적인 관리자는 돈줄을 말리고, 지나치게 낙관적인 관리자는 팀원들의 피를 말린다.(관리자 법칙 8) 2010-04-11 09:32:23
  • 팀원은 레몬과 같다. 레몬으로 사과주스를 만들 수 있다는 환상은 버리도록 하라.(관리자 법칙 9) 2010-04-11 09:41:46
  • 팀원 입장에서 가장 골치아픈 사람은 윗사람에겐 YES MAN, 아랫 사람에겐 NO MAN인 팀장이다.(관리자 법칙 10) 2010-04-11 12:54:46
  • 프로그래머와 운동 선수의 공통점은, 전문가가 될때쯤 되면 관리자로부터 은퇴 압박을 받게 된다는 점이다.(관리자 법칙 11) 2010-04-11 12:57:02

이 글은 공중곡예사님의 2010년 4월 9일에서 2010년 4월 11일까지의 미투데이 내용입니다.








WARNING: 상기 내용은 본 블로그 운영자의 개인적인 생각이니 심각하게 받아들이시면 정신 건강에 심히 해로울 수도 있습니다. :-)








Posted by 이병준
TAG 1, 10, 11, 2, 3, 4, 5, 6, 7, 8, 9, 관리자, 법칙

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

  1. 카키

    헛... 관리자 아닌게 다행...
    전 이만 주석문 관리하러...ㅠ^^ㅠ

    2010.04.19 11:32 [ ADDR : EDIT/ DEL : REPLY ]
  2. dhyi123

    100% 에서 심하게 공감.
    요새 제가 100% 인 상황인데 창조적인 아이디어는 하나도 안나옴.

    2010.05.05 09:36 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile2010. 1. 6. 17:18

이 글은 공중곡예사님의 2009년 12월 17일에서 2010년 1월 6일까지의 미투데이 내용입니다.

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

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

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

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

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

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

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

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

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

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

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

Posted by 이병준

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

  1. duru

    새해 첫 과업이 논문 통과군요.
    희망하시는 모든 일 다 이룰 거라 믿어 의심치 않습니다.^^
    더불어 건강 더 잘 챙기시고,,,
    최근 내 주위의 좋은 사람들이 하나둘 안 좋은 소식이 들리네유...ㅠ

    2010.01.12 10:55 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/TDD2009. 5. 14. 22:13
최근에 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를 고객(저)과 개발자(용역업체) 사이의 소통에 활용해 생산성을 높인 사례를 확보할 수 있지 않을까... 그런 기대를 하고 있습니다. 그리고 다음번에는 어떻게 적용하면 더 좋을지도 알게 될 것 같구요.

Posted by 이병준

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

  1. 지금 제가 개발과 프로그래밍(웹)에 관해서 공부한 내용을 갖고 이해하기에는 조금 어려운 포스팅인 것 같습니다.
    그래도 많은 도움이 되는 것 같아서 이해하는데 너무 집착하기보다는 이렇게 활용 할 수도 있다라는 생각을 갖고
    관심을 갖고 읽게 되었던 것 같습니다.^^

    2009.05.22 03:15 [ ADDR : EDIT/ DEL : REPLY ]
    • 모든 사람이 이렇게 해야 하는 건 아닙니다. 이런 방법도 있다는걸 알아두면 언젠가는 써먹을 때가 있겠죠...

      2009.05.22 08:28 [ ADDR : EDIT/ DEL ]

Extremely Agile/General2009. 2. 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 ]

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

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

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


- 전쟁의 기술 (The 33 Strategies of War) 52p.  "과거의 방식으로 싸우지 마라"
Posted by 이병준

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

  1. 음. 너도 읽었구나. 나도 하루 한장씩 아껴읽으며 되새겼던 책이네. 그 사람 다음 책도 샀는데 권력의 법칙. 이건 아직 못 읽음. 잘 지내라.

    2009.04.29 03:32 [ ADDR : EDIT/ DEL : REPLY ]
  2. 좋은 글이네요.^^

    전쟁이 잔혹하고 처참하고 많은 사람들이 결코 지지하고 원하지 않지만
    과거 세계적인 사건에서 역사적인 인물들을 보면 이기적인부분도 있었고 리더쉽있게
    이끌어서 승리를 한 인물들을 생각해보면 많이 있는 것 같네요.

    2009.05.20 01:57 [ ADDR : EDIT/ DEL : REPLY ]

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

이런 이야기는 왜 하는 것일까요? 뭐 다들 잘 아시겠습니다만, (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. reproduce하기 굉장히 난감한, 발현 시점을 도무지 정확히 알 수 없는 버그. [본문으로]
Posted by 이병준

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

  1. 공감하고 갑니다. ^^

    2009.01.29 02:40 [ ADDR : EDIT/ DEL : REPLY ]
    • 아. 안녕하세요? 제가 블로그 첨 열었을 때 A2님 블로그에서 X-note에 리눅스 설치하는 방법을 참고했던 기억이 나네요. 새해 복은 많이 받으셨는지? 올해도 건승하시길~

      2009.01.29 09:11 [ ADDR : EDIT/ DEL ]
  2. 정말 공감가는 글입니다. 저는 아직 인생까지 걸어보진 못했지만 잡아내는 버그 한두개로 소프트웨어 자체를 fail 시켜야 한다는 점에서는 거의 매일 누구에겐가는 운명적인(?) 버그를 잡아낸다고 해야하나요. 하지만 더 열심히 한다면 언젠가는 저도 제 인생을 바꿀만한 버그를 잡아내는 날이 오겠죠? ^^; 어쨌든 이젠 돌다리를 두들겨만보고 건너는 버릇은 아예 없앴습니다. 뛰어보고 엎어보고 발로 차보고 긁어보고 맛도 본 후에나 건너게 되더군요.

    2009.03.26 13:00 [ ADDR : EDIT/ DEL : REPLY ]

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

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

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

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

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

  1. [가짜대통령 이명박 사형 결정 전문] 미ㄴㅔ르바? : 官error안봐??

    [百姓有過 在여一人]<論ㅓ ㅛ曰>

    대통령 스스로가 법을 존중하고 준수하지 않는다면,
    다른 공직자는 물론,
    국민 누구에게도 법의 준수를 요구할 수 없는 것이다.
    <관습헌법? 대통령(노무현) 탄핵 결정 전문> / 가짜대통령 이명박 사형 결정 전문!
    / 관습헌법사항 한 줄조차 몰라서~? 미네르바에게 무슨 법의 준수를 요구하겠답시고??

    의법, 무효대통령! 위헌대통령! 위법대통령! 불법대통령! 사기대통령! 대통령직장물대통령! 사이비대통령! 비합법대통령! 부적법대통령! 가짜대통령! 이명박을 사형으로 처단하라!~@!!
    dead line(2009.02.09.)day
    [명령章!] 이명박을 사형으로 처단하라!~!!.hwp / 이명박 운명 : 대한민국 대운
    대역죄인대통령 치하의 국민들은 다 죄인~!!

    2009.01.18 19:08 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2009. 1. 15. 23:07

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

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

- 천재반 기타, p63




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

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

Posted by 이병준

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

  1. 짝 프로그래밍에 대해 간단히 이해할 수 있는 좋은 포스팅인 것 같습니다.^^
    아직 프로그래밍 방법론에 익숙하지 않은 초보 학생이지만 관심 갖고 앞으로
    많은 내용 보면서 공부 하고 싶습니다.^^

    2009.05.17 08:15 [ ADDR : EDIT/ DEL : REPLY ]
    • 낭만고양이

      열심히 하시길~ ^^

      2009.05.17 08:21 [ ADDR : EDIT/ DEL ]

Extremely Agile/General2008. 12. 19. 14:07

여러가지 협업 시스템을 써 봤습니다만, 중앙의 스토리지가 명시적으로 드러나지 않고도 협업이 가능하게 해 주는 시스템은 Groove가 처음입니다. Microsoft Groove는, 제가 써 본 마이크로소프트 사의 제품 중에서 가장 재미있는 툴이라고 할 만 합니다. (그럼 강추? ㅋㅋ)

Groove는 메시지 기반으로 참여자간의 작업을 동기화합니다. 같은 작업에 묶여있는 사용자는, 네트워크에 접속되는 순간 참여자들과의 통신을 통해 로컬 하드디스크에 있는 문서들을 동기화합니다. 그래서 분산 솔루션이고, 중앙에 CVS나 Subversion 같은 것을 설치할 필요가 없습니다.

하드 디스크 상에 다른 사용자들과 동기화하고 싶은 폴더가 있는 경우에는, Groove 설치 후에 해당 폴더를 마우스로 오른쪽 클릭하여 모든 사용자에게 공개하고 동기화 할 수도 있습니다[각주:1]. 엄청 간단하죠.

거기다 도구 안에 "토론", "문제점 보고(issue tracking 관련 기능입니다.)", "채팅", "일정", "쪽지" 등등 다양한 기능이 통합되어 있고 그것도 공유가 되기 때문에, 아웃룩 같은 것을 통해 일정을 공유하느라 피곤하셨던 분들은 이 툴을 사용하면 쾌적함을 느끼실 수 있을 것 같네요.

하지만 이 툴의 가장 큰 장점은, 서로 분산되어 일하는 사람들의 공동 작업을 굉장히 '재미있게' 만들어준다는 점입니다. 모든 프로젝트에 있어 가장 중요한 것은 뭐니뭐니해도 재미죠. 같은 일을 하는 사람들과 Groove 세션을 만들어 작업을 하다 보면, 서로 어긋나는 부분이 줄어든다는 느낌을 받게 됩니다.

거기다 시스템이 확장 가능하게 만들어져 있어서, 써드 파티 응용과 연결될 수 있습니다. (현재는 마이크로소프트 웹 사이트에 공개된 Asset 관리 플러그인과 연동할 수 있습니다. 프로젝트를 하다보면 관련 자산을 관리할 필요가 있는데, 그럴 때 유용하죠.)  

  1. 물론 이 기능에는 치명적인 약점이 있긴 합니다. 태생이 Unix 인 프로젝트의 소스 코드 중에는 .classpath 처럼 파일 이름이 .으로 시작되는 것들이 있어요. 이런 파일명을 Groove는 올바르게 처리하지 못합니다. 그래서 Unix에서 개발된 소스 코드를 공유하는 것은 힘들어요. (나중에 가능하게 해주는 옵션을 찾으면 포스팅하겠습니다.) [본문으로]
Posted by 이병준

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

  1. SVN이나 CVS를 단순히 공유의 기능으로 사용한다면 모를까, Groove가 이를 대신하기는 어렵습니다. 어쨋든 Groove가 재미있는 제품인 것 같더군요.

    2008.12.19 15:17 [ ADDR : EDIT/ DEL : REPLY ]
    • 맞습니다. 대신하기는 곤란하죠. 다만 개발팀이 아주 소규모로만 협업을 진행할 경우에 협업을 돕는 보조 도구로 사용할 수는 있습니다. 소스 코드를 공유하기 위해 사용하는 것은 주석에도 적었습니다만 불편해요. 자동 빌드를 할 수 있는 것도 아니구요. ㅎㅎ 한계는 분명합니다. 좀 더 생산적인 협업을 할 수 있도록 도와주는 제품일 뿐이죠.

      2008.12.19 16:44 [ ADDR : EDIT/ DEL ]
  2. adones

    어떤점이 재미가 있다는거져? 흥미로운 제품임은 사실이지만 작업을 재미있게 만들어 준다는게 어떤건지 궁금하네요. 그냥 MS니깐 핧아주는것도 사실에 기반해야 한다고 봅니다만?

    2009.03.23 09:05 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2008. 12. 7. 11:03
옷을 사러 나갈 시간이 통 없어서 가끔 인터넷에서 쇼핑을 합니다. 인터넷에서 쇼핑을 하다 보면 반품을 하거나 교환을 해야 할 경우 좀 난감해서 가급적 물건을 살때 조심을 하는 편인데요. 그래도 열번에 한번 정도는 교환을 할 일이 생깁니다. 이번에는 인터넷에서 스웨터 하나를 샀는데, 올이 튿어진 부분이 있더군요. 그래서 반품신청을 하려고 택배회사 웹사이트를 찾았습니다.

저는 택배회사의 서비스에 큰 반감이 있는 사람은 아닙니다. 여태껏 택배회사로부터 물을 먹은 적도 한번도 없었고, 기한이 촉박한 물건은 인터넷으로 주문하지 않는 편이라서 택배회사의 배송 지연때문에 피해를 본 적도 없었습니다. 대부분, 하루나 이틀 정도만 기다리면 아주 '건강한' 상태의 물건을 받을 수 있었죠. 로젠 택배의 경우도 그랬습니다. 여태껏 로젠 택배를 통해 물건을 받으면서 단 한번도 물건이 파손되거나, 배송이 지연되거나, 배송기사님이 불친절 하다거나 하는 경우를 겪은 적이 없었습니다.

하지만 로젠 택배회사의 웹 사이트에는, "어라?" 싶은 구석이 있더군요. 이번에 처음 알았습니다.

로젠택배 웹사이트를 통해 배송신청을 하려면, 우선 회원가입을 해야 합니다. (회원가입하지 않아도 배송신청을 할 수 있는 웹 사이트들도 많습니다. 하지만 '회원가입' 덕에 혜택을 누리게 되는 일도 있으므로 이정도는 그냥 넘어가 줄 수도 있을 것 같습니다.) 회원가입을 하고 나면, 이제 교환/반품 배송신청을 할 수 있습니다.

로젠택배 웹사이트를 통해 교환/반품 배송신청을 하려면, 우선 원래 배송된 물품의 운송장 번호를 적어넣어야 합니다. 그런데 인터넷으로 뭔가를 주문해보신 분이라면, 이 운송장 번호라는 것이 포장지를 뜯는 과정에서 파손되기 쉽다는 사실을 아마 아실겁니다. 그래서 이런 경우를 '굳이' 대비하려면, 포장지를 뜯기 전에 운송장 번호를 미리 적어둬야 합니다. 그런데 보통 그렇게들 하시나요? (안하신다는 쪽에 오백원 걸겠습니다 ㅋㅋ) 그러니, 운송장 번호를 적도록 하는 대신, 반품하는 사람의 전화번호나 주소지로 원 배송 내역을 조회할 수 있도록 했으면 아마 더 나았을 겁니다.

하지만 이 사이트의 진짜 문제는 그게 아닙니다.

운송장 번호를 제대로 입력하고 완료 버튼을 누르면 다음 화면이 뜨는데, 이 화면이 진짜 난감합니다. 이전 화면에서 운송장 번호를 입력할 때, 저는 '물품을 받을 사람' 부분에 받는 사람 주소지가 자동으로 완성될 것으로 생각했습니다. (원래 운송장 정보에 기록된 발신인 주소가 수신인이 되어야 할 테니까요.) 그런데 그렇지가 않더군요. 결국, 수신자 주소를 수동으로 입력해야 했습니다. 귀찮았지만, 어쨌든 열심히 입력하고 완료 버튼을 눌렀습니다. 그런데 그 순간 "배송비 계산 버튼을 눌러 수신자 주소를 확인하시라"는 메시지가 뜹니다. 웬 도깨비같은... 어쨌든 누르라고 했으니 누릅니다. (오늘날 대한민국 웹 사용자들은 이런 요구를 받아도 이제 별로 당황하지 않습니다.) 누르니까 다음과 같은 오류 메시지가 뜹니다.

'입력하신 주소와 원 운송장의 보낸 사람 주소가 일치하지 않습니다.'

받을 사람 주소지가 자동으로 완성되도록 사이트를 설계했다면 발생하지 않을 오류인데, 사용자보고 입력하도록 만들어 놓고는 잘못 입력했으니 다시 입력하랍니다. 허허...

한 열번 정도 시도해 보다가, 결국 다음날 로젠택배 고객센터로 전화를 걸었습니다. 고객샌터 상담원은 굉장히 친절합니다. '어제 내가 왜 열을 받았었지?' 할 정도로 말이죠. 그래서 전날 웹 사이트에서 열받은건 완전히 까먹고는 순순히 교환/반품 배송신청을 했습니다. 그런데 또 원 운송장 번호를 묻더군요. 묻는대로 대답해줬습니다. 그랬더니 받으실 분 주소를 묻더군요. 그래서 제가 물었습니다.

"원래 물건을 보낸 사람 주소로 보내면 되는거 아닌가요? 그 정보는 운송장 번호를 보면 알수 있을텐데요."

그랬더니, 보낸 주소와 받는 주소가 달라질수도 있어서 묻는답니다. 이 대목에서 저는 잠시 멍해졌습니다. 정말 그것이 정책이라면, '입력하신 주소와 원 운송장의 보낸 사람 주소가 일치하지 않습니다.'같은 오류는 로젠택배 웹 사이트에서는 발생하면 안되는 것이었으니까요. 어쨌든 친절하신 상담원 덕에, 저는 무사히 배송 신청을 마쳤습니다.

* * *

보통 웹 사이트는 '고객의 만족도를 더욱 높이기 위해' 만듭니다. 당연히 그 UI도 그런 방향으로 설계되어야 하죠. 그런데 위의 로젠택배 사이트처럼, 간혹 그와 정 반대되는 일을 하고 있는 웹 사이트도 만나게 됩니다. 고객의 만족도를 높이기는 커녕 고객의 만족도를 감소시키는 일을 하고 있는 웹 사이트 말이죠. (오해를 살까 싶어 말해두는 건데, 저는 로젠택배의 '일반적인' 서비스에 대해서는 아무 반감이 없습니다. 다만 그 '웹사이트'가 하는 일이 영 맘에 들지 않아 투덜대는 것일 뿐이죠.)

이와 비슷한 사례는 인사이트의 번역서, "소프트웨어, 누가 이렇게 개떡같이 만든 거야"에서도 많이 발견할 수 있습니다만, 고객의 적극적인 투덜거림이 없으면 개선되기 힘듭니다. 이 책에서도 UPS라는 웹 사이트의 경우를 예로 들어 '고객의 만족과 반대로 작용하는 사용성'을 설명하고 있는데요. 유독 택배회사의 웹 사이트들에서 이런 anti-usability 패턴들을 많이 발견하게 되는 것은 대체 무슨 이유에서일까요?
Posted by 이병준

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