▲ 용마산 중턱에서 찍은 서울 전경

위드로봇은 서울 성수동에 있습니다. 근처에는 용마산과 아차산이 있지요. 3월 25일 수요일 오후 시간, 모든 업무를 멈추고 다들 지하철 9선을 타고 용마산역으로 가서 등산을 시작했습니다. 목표는 용마산 정상 찍고, 아차산을 거쳐 광나루역 쪽으로 내려오는 코스를 잡았죠. 날씨는 참 좋았고, 스모크 탓에 서울의 전경이 또렷하게 보이지는 않았지만 간만에 멀리 보는 눈 운동 실컷 했습니다.


아, 한가하거나 팔자가 좋아 보인다고요? 천만에요. 요즘 세상에 맘 편한 회사가 어디 있겠습니까? 힘들고 바쁘지만, 그 와중에서 짬을 만들어 내서 운동도 하고, 바람도 쐬는 것이지요. 하산해서 닭백숙으로 배를 든든히 채우고 다들 헤어졌습니다. 바쁜 일이 있는 맴버들은 다시 회사로 복귀하기도 했고요.

위드로봇 맴버들은 이러고 살고 있습니다.

저작자 표시
신고
Posted by getcome
2015년 3월 18일 수요일부터 20일 금요일까지 서울 강남구 삼성동 COEX에서 Automation World와 Korea Vision Show가 개최됩니다. 위드로봇은 작년에 이어 두 번째로 같은 전시회에 부스를 조그마하게 내고 OjOcam 카메라에 관련된 연구 결과물들을 전시합니다. USB 3.0 인터페이스를 이용하여 고객이 원하는 사양으로 카메라를 만들어 주는 커스터마이즈 서비스가 다른 업체들과의 차별점인 것 같습니다. 영상 처리 시스템으로 고민하고 계신 분은 COEX 부스 S116호에 들려주세요. 카메라 선정, 캘리브레이션, 영상 처리 알고리즘 등 궁금하신 내용에 대해 상의해 드립니다.

▲ 전시회 하루를 앞두고 부스를 열심히 꾸미고 있습니다.

▾ 국제공장자동화전, 스마트공장기술전, 한국머신비전산업전 3개의 전시회가 같이 개최되므로 볼거리는 풍부합니다.


▾ 초대권은 위드로봇 세미나에 오신 분들에게는 필요한 만큼 많이 드렸습니다.



▾ 부스는 다른 큰 기업에 비하면 작고 볼품없습니다. ^^ 하지만 실력이나 열정은 부스 크기에 비례하지는 않으니 그냥 지나치지 마시고 꼭 들려주세요. S116호입니다.



▾ 전시회 준비 마치고 집으로 돌아가는 길은 무척 밀렸습니다. 선릉역 쪽 지하철 공사가 원인이더군요. 한 블록 지나가는데 20분 걸렸습니다. 그 와중에 조금이라도 빨리 가겠다고 끼어드는 차량이 매우 많았는데, 뭐 급한 일이 있어서겠죠. ^^



저작자 표시
신고
Posted by getcome




바쁘다는 핑계로, 더 급하고 중요한 일이 산더미라는 이유로 이 블로그를 내버려둔지 2년이 지났습니다. 문득 블로그를 살려야겠다고 생각이 나곤 했습니다만 애써 모르는 척 내 팽개쳐 두었죠. 

아직도 어렵고 힘든 부분이 많이 남아있지만, 그래도 작년과 달라진 점이 있다면 스스로를 위로할 줄 알게 된 점인 것 같아요. 요즘 음악을 틀어놓고 일하는 습관이 생겼는데 김동률, 이상순의 Verandah project 앨범 Day off에 있는 9번째 곡 "괜찮아"를 듣다 보니 기분이 묘해지면서 블로그에 쌓인 먼지 털어내고 조금씩이라도 글을 써야겠다고 결심했습니다. 그러고 보니 이 블로그의 맨 처음 글도 김동률의 "거위의 꿈"으로 시작했었죠. 고마워요 김동률~. 당신 덕분에 다시 시작할 힘을 낼 수 있네요.


베란다 프로젝트(김동률, 이상순) - '괜찮아'의 가사 전문

함께 출발한 네 친구들이
어느새 저만치 앞서 달릴 때

닿을 듯 했던 너의 꿈들이
자꾸 저 멀리로 아득해 질 때

그럴 때 생각해
지금 이 순간이 언젠가 너를
더욱 빛나게 할 거야

괜찮아, 힘을 내
넌 할 수 있을 거야
좀 서툴면 어때
가끔 넘어질 수도 있지

세상에 모든 게 단 한번에 이뤄지면
그건 조금 싱거울 테니

너보다 멋진 네 친구들이
한없이 널 작아지게 만들 때

널 향한 사람들의 기대로
자꾸 어디론가 숨고 싶을 때

그럴 때 생각해
지금 이 순간이 언젠가 너를
더욱 빛나게 할 거야

괜찮아, 힘을 내
넌 할 수 있을 거야
좀 더디면 어때
꼭 먼저 앞설 필요는 없지

저 높은 정상에 너 혼자뿐이라면
그건 정말 외로울 테니

괜찮아, 힘을 내
넌 할 수 있을 거야
뒤를 돌아봐
벌써 이만큼 온 거잖아

언젠가 웃으며 오늘을 기억할 날에
조금 멋쩍을지 몰라
너도 몰래 어느새
훌쩍 커버린 너일 테니


저작자 표시
신고
Posted by getcome
연구실에 2009년에 구매한 후 잠깐 사용하고 방치되어 있던 MacBook Pro가 하나 있었는데요, 최근 위드로봇 연구실의 인원이 증가하면서 이래저래 노트북이 많이 필요하게 되어 제가 사용하던 노트북은 다른 연구원이 쓰게 되었고, 저는 아무도 안쓰려는 기피 대상의 MacBook Pro를 할당받게 되었습니다. 개발하려면 임베디드 컴파일러를 설치해야 하기에 아무래도 OSX는 좀 힘들죠. 저는 이제 기껏 쓰는 프로그램이 Word, Power Point, Excel 수준이니 Mac으로 switching 해도 되지 않을까 싶어 과감히 도전했습니다.

당장 국책과제 보고서를 써야 하는데 HWP 문서 포맷은 맥에서는 방법이 없네요. 설 연휴지만 연구실로 출근해서 이런저런 작업을 시작하였습니다. 
부랴부랴 VM Fusion과 WIN7 조합으로 HWP 파일을 편집하는 단계까지 왔는데 OS 업데이트하라는 메시지가 떠서 무심코 업데이트 버튼을 클릭했다가...
오후 12시에 시작한 업데이트 9개가 오후 5시가 되어도 끝날 생각을 하지 않네요. 

 
이래저래 올해 설 연휴 동안 쉴 수 있을런지 모르겠습니다.  
저작자 표시
신고
Posted by getcome

이 글은 디바이스마트 매거진 10호에 실린 글로 다른 개발자분들의 의견을 듣고자 원문 그대로 올려놓습니다. 


글을 쓰게 된 계기

제가 일하고 있는 위드로봇()가 서초동에서 성수동으로 확장 이전한 것을 기념하여 디바이스마트 고객을 대상으로 무료 공개 강좌를 진행한 적이 있습니다. 이 강좌 내용을  디바이스마트 매거진에 지면으로 옮기며 독자 분들과 만난 지 일년이 되어 갑니다. 2011 12월에는 3 가속도 센서와 2 자이로 센서로 구성된 myARS-USB 제품 개발에 관한 개발 과정을 소개하는 원고를 청탁 받고 고민하던 끝에 특정 제품 개발에 관한 이야기보다는 일반적인 개발 과정의 이야기로 편하게 독자 분들에게 소개하고, 여러분들은 어떻게 생각하시는지 묻고 싶어졌습니다. WITHROBOT Lab.이라는 조그마한 연구소를 만든 지 이제 3년이 지났고 그간 크고 작은 대기업 연구소, 정부 출연 연구소, 대학 연구실로부터 수주 받아 진행한 과제가 60 가까이 되기에 다양한 경험을 있었습니다. 오늘 풀어놓는 이야기는 60여건의 과제를 거쳐온 조그마한 회사의 개발자이자 오너가 겪은 좌충우돌 경험기로 봐주시면 고맙겠습니다.

행복한 개발자는 모순어법인가?

가끔은 고객의 요구를 파악하여 문제없이 술술 진행된 과제도 있었습니다만, 대부분의 과제가 진행 중에 예상하지 못한 어려움 때문에 때론 고통스럽고, 때론 짜증이 나는 경우가 많았습니다. 사실대로 고백하자면 대부분의 과제가 후자쪽이었습니다. 애초 연구소를 처음 만들 목표가 "행복한 개발자들의 놀이터"였기에 힘든 상황에 맞닥뜨리게 되면 많은 갈등을 하게 됩니다. 과연 "행복한 개발자"라는 말은 모순어법인 것인지, 개발이라는 과정 자체는 결코 행복해 질수는 없는 것인지, 뭐가 근본적인 문제인지... 신문지상과 같은 곳에서 성공 사례를 언급하는 개발자들의 개발후기를 보면 달을 밤새고 새벽 별을 보며 퇴근을 한다던 지, 접이식 침대는 연구소의 필수품이요, 커피와 각종 각성제가 들어간 음료수는 무한 공급을 해야 한다는 이야기들을 접하곤 합니다. 이제는 조금은 진부한 표현입니다만 월화수목금금금으로 일하는 개발 과정을 자랑스럽게 이야기하는 기사를 읽다보면 마음 한켠이 어두워집니다. 개발은 정시 퇴근하고, 주말이면 여행도 가고, 영화도 보고, 때론 평일에 조금씩 쉬어가면서 있는 일은 아닌가요? 고행에 가까운 고통을 감내해야지만 쓸만한 제품이 나오는 것일까요? 진부할 수도 있지만 전형적인 땅의 엔지니어라고 생각되는 모습을 그려보겠습니다.

회사에 입사하여 개발팀 팀에 들어가 회사에서 부여하는 업무를 진행하게 됩니다. 소위 프로젝트라는 이름을 붙이고 과제 전체를 담당하는 PM(Project Manager) 잦은 회의를 통해 무엇을 해야 하는지, 언제까지 해야 하는지 업무를 할당 받습니다. 처음에는 있을 것이라 생각했지만 혼자서 일을 하던 학생 때와는 사뭇 다르게 매우 비효율적으로 일을 진행하는 자신의 모습에 놀라곤 합니다. 회로를 설계하는 경우라면 커넥터 하나를 선정하더라도 여러 사람에게 문의해 봐야 하죠. 바로 자리에 모일 있는 경우라면 쉽게 결정이 되겠습니다만, 대부분의 경우가 그렇지는 못하죠. 경우 메일로 문의하는데 답신이 오는데 하루 이상 걸리곤 합니다. 경험상 하루 만에 답신이 와서 결정이 된다면 상대적으로 매우 효율적인 과제에 속합니다. 혼자서 한다면 10분안에 끝났을 커넥터 선정이 하루가 지나도 결정이 되는 경우가 있죠. , 핸드폰이 있다구요? 좋습니다. 어떤 상의할 상황이 생길 때마다 핸드폰으로 해당 결정자에게 묻는다고 합시다. 개발자마다 다르겠습니다만 경우는 어떤 일을 하고 있을 핸드폰 전화를 받으면 바로 집중이 깨져버립니다. 3 정도 통화로 상대방은 뭔가 문제가 해결되었을지 모르겠지만 다시 원래 하던 일에 몰입하기 위해서는 최소 20~30분은 소요되곤 합니다. 문제는 이런 전화가 시도 때도 없이 걸려오면 하루 종일 통화만 하다가 정작 해야 하는 가장 중요한 일은 진도가 나가지 않는 경우가 있다는 점입니다. 고객 중 이런 분이 있으셨는데, 시시콜콜한 사항부터 매우 오랜 시간 동안 논의해야 하는 문제까지 핸드폰 통화로 해결했기에 하루에 스무 번 이상 통화를 한 적도 있고 어떨 때는 두 시간 이상 통화를 한 적도 있습니다. 문제는 많은 통화를 통해 뭔가 결정된 사항들이 시간이 지나면 서로 잊고 있거나 구두로 전달하는데 실수가 들어가 서로가 당연히 알고 있을 것이라 생각했던 부분에 심각한 오류가 있곤 했었습니다. 어쨌건 핸드폰 또는 메일을 통해 커넥터를 결정했다손 치더라도 진행 중에 전혀 엉뚱한 이유로 초기의 결정사항들이 뒤집히곤 합니다. 그러면 설계 변경이 발생하겠죠. 문제는 항상 모든 일에는 마감 기일이 있기에 이러한 설계 변경은 절대 달가울 수가 없습니다. 처음에는 나름 여유 있는 일정이라 생각했지만 전체 일정의 50% 지났을 때는 대부분의 항목들이 지연되고 있음을 발견합니다. 회로 설계는 진작 끝나 PCB 만들어지고 있어야 하는데, 아직도 부품 선정도 안되어 있습니다. 테스트 코드는 뭔가 작성해서 잔뜩 테스트는 하고 있는 같은데, 정작 타겟 보드에서는 아직 테스트를 봤기에 어떤 문제가 발생할지는 아직 아무도 모르는 상황입니다. 슬슬 일정에 대한 압박감을 느끼기 시작하며 야근을 하며 개발의 속도를 내려고 하지만 갑자기 개발 속도가 빨라질 리는 만무합니다. 그러다 보니 면밀히 검토하지 못한 채 일단 진행하는 회로와 코드들이 늘어나죠. 컴파일해서 일단 간단한 테스트 케이스를 통과하면 면밀한 검토는 우선 제쳐두고 다음 단계로 진행합니다. 회로 설계도쪽은 분초를 다투며 쪼임을 당하고, 결국은 의심적은 부분이 있지만 PCB제작에 착수합니다. 코드쪽도 점점 복잡해지고 있고, 어디선가 문제가 조금씩 터져 나오지만 어떻게든 대충 디버깅이 되면 계속 진도를 뽑습니다. 결정적인 문제는 항상 과제 마감 전쯤 터집니다. 설계한 보드는 우스꽝스런 결정적인 실수가 있어 애초 목표했던 기능을 100% 구현 없습니다. 코드는 사용자의 편의성이나 심미안적인 아름다움은 저 멀리 안드로메다로 사라진 지 오래고, 그저 개발자 관점에서 디버깅하기 편한 구조와 형태로 짜여져 있을 뿐입니다. 그럼에도 불구하고 개발자는 "일단 기능하는 것이 중요하다"라고 항변하며 일정을 늘리는 요구에는 짜증부터 내기 시작합니다.

결국 애초에 생각했던 마감일 일주일 전에 전체 미팅을 통해 일정은 변경되고 목표 스펙 또한 변경되곤 합니다. 상황에 따라서는 새로운 맴버가 투입되기도 합니다. 일정이 늘어났으니 비용은 초기 계획보다 늘어나는 것을 피할 없겠죠. 지금부터는 요일도 없고 퇴근 시간도 없는 죽음의 행진이 시작됩니다. 이렇게 해서 애초 계획보다 최소 30% 이상, 심지어는 두 배 이상 지연된 시점에서 과제가 종료됩니다. 놀라운 사실은 이러한 진행 패턴이 과제비가 백만원짜리든 백억짜리든, 세명이 투입된 과제건 십 명이 투입된 과제건 대동소이 하다는 점입니다. 이는 극복할 없는 과제의 특성일까요?
 

프로젝트의 정의

앞서 소개한 프로젝트의 종류나 규모에 상관없이 일정 관리에 어려움을 겪는 이유 하나는 프로젝트라는 단 정의에서 찾을 있습니다. 프로젝트의 정의는 여러 가지로 내릴 있겠습니다만, 프로젝트 관리 분야에서 표준이라고 있는 PMI에서는 프로젝트란 새로운 제품, 서비스 또는 결과를 창출하기 위해 수행하는 일시적인 노력(Temporary endeavor undertaken to create unique product, service, or result)이라고 하고 있습니다. 정의에서 핵심 키워드는 새로운 일시적입니다. 아무리 비슷한 프로젝트라 지라도 프로젝트만의 고유한 새로운 부분이 있기 마련입니다. 그러한 새로운 부분은 불확실성으로 작용하게 되어 일정 관리에 어려움으로 작용하게 됩니다. 달리 생각해 보면  전에 했던 작업과 100% 동일하다면 그건 프로젝트라 부를 없기에 프로젝트는 항상 경험하지 못했던 부분이 포함됩니다. 번째 키워드인 일시적 달리 표현하면 마감 시한을 가지고 있다는 뜻이 됩니다. 이처럼 프로젝트는 그 특성상 항상 해결책이 무엇인지 모르는 새로운 부분이 들어가고, 이러한 부분을 주어진 시간 안에 해결해야 하기 때문에 우리는 항상 불확실한 계획으로 마감 시간이 다가올 일정에 압박을 받는 것이죠.

이러한 프로젝트의 일정 관리를 위한 기법들은 매우 많이 연구가 되었습니다. 서점에 보시면 프로젝트 관리 기법류의 책들이 무척 많이 있는 것을 발견할 있을 겁니다. 또한 이러한 관리 기법을 도와주는 프로그램 도구들도 많이 나와있죠. MS Project Primavera 대표적인 프로그램입니다. MS Project 프로그램을 접해보지 못한 분들도 계실 있겠습니다만, 놀랍게도 MS사에서 출시한 수 많은 제품 중에서 번째로 출시한 제품입니다. MS 번째 제품은 1981 DOS였고, 번째가 1982 EXCEL, 번째가 1983 WORD 였습니다. MS Project 1984년도에 출시되는데 MS 사에서는 프로젝트 관리 도구를 다른 중요해 보이는 제품들보다 먼저 출시한 것일까요? 그만큼 MS 사에서도 프로젝트 관리가 중요하다는 것을 인지하고 있었다는 반증이기도 합니다. 이러한 프로그램을 소개하는 것이 원고의 목적은 아니기에 간단히 제품명만 소개하는데 그칩니다. 프로그램 사용법에 대한 소개는 서점에 무척 많은 책들이 대신해 것입니다. 그런데 아쉽게도 전산학에서 널리 통용되는 표현을 그대로 쓰자면 "은탄환(silver Bullet) 없습니다". 만병통치약처럼 어떤 소프트웨어 도구를 사용한다고 해서 문제가 해결되는 것은 아니라는 뜻입니다. 위드로봇에서도 괜찮다는 방법은 이것저것 도입해서 적용해 보았습니다만 결과적으로 대부분 실패로 끝났습니다. 분명 이러한 도구들은 유용하고 필요합니다. 하지만 근본적인 문제의 원인을 해결해 주는 것은 아니라는 뜻입니다. 위드로봇에서는 나름대로 가지 답을 찾았다고 생각하기에 부분을 공유하고자 이 글을 씁니다.

 

고객의 요구를 들어주려고 하지 말고 욕구를 들어주어라

개발자들이 과제에 참여하면 초기에 하는 중에 하나가 기능 구현을 위한 요구 사항 명세서 입니다. 소위 말하는 스펙이죠. 백이면 모든 개발자들이 과제 초기에 스펙을 정해 달라고 하는데, 재미있는 사실은위드로봇에서 지난 3년 반 동안 진행했던 60여건의 프로젝트 중에서 스펙이 과제 진행 중에 변경되지 않은 적이 번도 없었다는 점입니다. 뒤집어 말하면 고객이 개발자에게 무엇인가를 개발해 달라고 요구할 자신도 요구사항을 정확하게 파악하고 있지 못하거나 정확하게 파악하고 있더라도 정확하게 전달하지 못한다는 입니다. 또한 아무리 시간을 많이 들여 고객의 요구 사항을 청취하고 이를 문서화하였더라도 과제 진행 중에 요구 사항이 바뀌는 것을 경험하였습니다. 그럼 어차피 요구 사항은 바뀌니 대충 스펙을 잡고 진행하면서 바로 잡아가면 될까요? 이럴 경우는 재앙을 가진 프로젝트로 변질하곤 합니다. 전산학 쪽에서 매우 유명한 만화로 설명해 보죠. 여러 가지 버전이 있습니다만 위드로봇에서는 "프로젝트는 어떻게 망가지나?"라는 이름으로 설명하곤 합니다(출처: http://www.projectcartoon.com). , 보면서 설명해 보겠습니다.


강조하고 싶은 부분은 고객은 어떤 욕구가 있어 개발자를 찾아온 점이라는 것입니다. 욕구에 의해 도출된 요구 사항들을 개발자에게 설명합니다만, 설명은 충분할 없을 뿐더러 충분하더라도 전달 과정에서 왜곡되기 쉽습니다. 요구 사항들은 명백한 공학적인 용어로 정의돼서 전달되는 것이 아닌 매우 추상적인 언어 표현될 것이기 때문입니다. 대표적인 것이 "가능한", "충분히"라는 단어입니다. 만화에서는 아마도 고객은 아이들이 신나게 있는 놀이 기구를 만들고 싶었을 것입니다. 복잡하고 세세한 기능이 있는 놀이 기구가 아닌 아이들이 손쉽게 매달려 놀 수 있는 단순한 놀이기구였겠죠. 이를 개발자에게 설명하다 보니 끈이 나무에 매달려 있고, 끝에는 아이들이 앉을 있는 장치가 있어야 하고, 아이들이 다치지 않도록 충분히 안전해야 한다는 요구를 했을 것입니다. 때론 설명하다 보니 개발자가 수용하기 어려운 기능을 요구했을지 모릅니다. 아이들이 쉽게 매달릴 있도록 특별한 받침대가 있어야 한다든지, 가능한 뒤로 넘어지지 않도록 안전 장치가 있어야 한다든지 하면서 말이죠. 개발자는 이러한 요구 사항들을 열심히 수집하면서 " 이러한 요구 사항이 나오게 되었는지 근본적인 욕구를 읽어내야" 합니다. 욕구를 읽어내지 못하면 과제 진행 기간 동안 내내 스펙이 변경되어 했던 일을 다시 엎고 처음부터 시작해야 하는 과정을 반복하게 것입니다

그럼 욕구는 어떻게 읽어낼 있을까요? 다른 사진 장에서 이야기를 시작해 보겠습니다.


멋진 사진은 미국의 요세미티 국립공원에 있는 해발 900 미터 높이의 수직암벽인 El Capitan 입니다. 거대한 화강암 돌기둥은 암벽 등반가들이 세계에서 가장 좋아하는 정복대상 하나라고 하네요. 한때는 등반이 불가능한 것으로 여겨지던 El Capitan 암벽이 지금은 거대암벽 등반가들의 표준 코스가 되었습니다. 국내에서도 많은 등반가들이 정복한 과정을 블로그나 기사에서 찾아 보실 있을 겁니다. 올라가는 경로는 여러 종류가 있지만 가장 인기 있고 역사적으로 유명한 등반 경로는 'Nose' 불리는, 암벽면 사이의 돌출부를 따라 올라가는 경로입니다. Nose 암벽의 최초 등반은 1958 Warren Harding 팀에 의해 이뤄졌는데 무려 45일이나 걸렸다고 합니다. 중간 중간 벽에 못을 박고 그물을 친 다음 이곳에서 먹고 자면서 올라갔다고 하네요. 그런데 50여년이 지난 2010 11월에는 Dean Potter Sean Leart 2시간 36 45초만에 올라갔다고 합니다. 50 전에는 45일이 걸리던 경로가 불과 두어 시간 만으로 줄었다니 사이 장비가 좋아진 것일까요? 체력이 좋아진 것일까요?

재미있게도 바뀐 것은 장비도 체력도 아닌, "계획"입니다. 1958 초기에 등반한 등반가들은 워낙 험준하고 힘들어 보이기에 한 달 이상의 일정으로 계획하고 배낭에 셔츠, 음식, 물과 같은 것들을 잔뜩 짊어지고 등반을 하였습니다. 그래서 오르는데 시간이 많이 소요되었고, 중간중간 캠핑을 해야 했죠. 2000년대 들어와서는 기존 고정 관념을 깨는 계획을 작성하기 시작했습니다. 암벽을 하루 안에 등반할 계획이라면 짊어지고 올라갈 장비 양을 크게 줄일 있을 것이고, 두어 시간 안에 올라갈 계획이라면 음식이나 따위도 필요 없이 몸으로 올라갈 있을 것입니다. 이제는 아무것도 짊어지지 않은 채 최대한 빨리 정상으로 올라가는 데 집중하기에 두어 시간 만에 등반할 수 있게 되었습니다. 이야기에서 얻을 있는 정보는 (1) 고정 관념에서 탈피하라, (2) 가능한 많은 정보를 얻어라 (3) 가능한 몸을 가볍게 하고 짧고 실천 가능한 계획을 작성하라 입니다.

다시 앞의 놀이기구 프로젝트 만화로 돌아가 볼까요. 프로젝트를 성공하기 위해 개발자는 고객으로부터 가능한 많은 정보를 얻은 가능한 빠른 시일 내에 자신이 이해한 내용을 프로토 타입으로 구현하여 고객에게 보여주었으면 좋을 걸 그랬습니다. 다른 경우를 들어볼까요? 어떤 프로그램을 작동하는 UI라면 어떻게 하시겠습니까? 가장 일반적인 경우는 Visual Studio에서 기능은 컨트롤들만 배치한 보여주는 것이겠죠. 30점입니다. 조금 똑똑한 개발자라면 PPT에서 그려서 보여줄지 모르겠습니다. 50점입니다. VISIO 멋진 GUI 스텐실들이 있습니다. 이를 이용하면 빨리 프로토 타입을 만들 있습니다. 70점입니다. 종이에 연필로 그려가며 자리에서 빠르게 요구 사항들을 정리하며 고객의 욕구를 파악하면 100점에 가깝습니다. 이러한 기법을 사용자 인터페이스 연구 분야에서는 "paper prototyping"이라고 합니다(http://www.uie.com/browse/paper_prototyping).

우리는 고정 관념에서 탈피하여 짧은 시간 안에 고객의 욕구를 파악해야 합니다. 뭔가 대단히 멋진 것이 필요한 것이 아닙니다. 짧은 시간에 프로토 타입을 만들려면 힘든 방법을 택해서는 안됩니다. 등산 가방에 자꾸 뭔가를 넣으려고 하지 마세요. 회의하는 자리에서 프로토 타입이 나올 있으면 가장 좋습니다. 프로토 타입은 고객의 욕구를 파악하는 용도이기에 욕구를 파악하고 나서는 바로 파기되는 운명이므로 가능한 힘을 들이지 않고 구현할 있어야 합니다. 굳이 스포츠에 비교하자면 고객과 개발자는 테니스를 치는 보다는 탁구를 치듯이 빠르게 공을 주고 받으며 요구와 그에 따른 결과물을 확인하며 다시 피드백을 주어야 성공할 있습니다. 그래야 서로가 다르더라도 빠르게 수정하여 합의점을 찾아낼 있기 때문입니다.

프로젝트는 고객이나 개발자 모두 새로운 일이기에 암벽을 올라가는 것과 같습니다. 가능한 많은 정보를 얻기 위해 고정 관념에서 탈피하여 빠르게 프로토 타입을 만들어 서로의 머리 속에 있는 욕구를 정확하게 파악한다면 45 걸리던 일을 2시간만에 끝낼 수도 있습니다. 하지만 서로가 무엇을 요구하는지 파악하지 못한다면 90일이 걸려고 못 올라가고 그만 포기할 수도 있습니다.

 

정리

여러 가지 이야기를 두서없이 늘어놓았습니다. 이제 앞에서 이야기한 내용을 간략히 정리 시간입니다.

(1) 개발자들은 항상 일정에 쫓기고 변덕스런 고객에 치를 떱니다.

(2) 프로젝트라는 속성상 항상 새로운 일에 도전하는 것이기에 일정이 계획대로 진행되지 않는 리스크를 내포하고 있다고 설명했습니다.

(3) 이러한 리스크를 최소화하기 위해 우리는 고객을 필요가 있습니다.

(4) 고객은 초기에 이러저러한 요구 사항들을 설명할 것이지만, 추상적인 단어로 설명되기에 근본적으로 원하는지 알아내긴 힘듭니다.

(5) 그래서 개발자는 최대한 힘을 들이지 않는 방법으로 고객이 요구하는 바를 확인할 있는 프로토 타입을 만들어 고객의 욕구를 파악해야 합니다.

되었을까요? 가지가 있습니다. 개발자 또한 인간이기에 시간이 흐르면 자꾸만 예전 일들은 잊습니다. 예전 경험들을 기억하는 가장 좋은 방법은 기록하는 것입니다. 개발하기 바쁘기에 개발 과정을 기록한다는 것이 매우 비효율적으로 보일 있습니다만, 무슨 복잡한 정리를 하라는 것이 아닙니다. 노트 사서 퇴근 하기 전 대여섯 정도만 그날 있었던 일들을 정리하는 정도라면 누구든지 있을 것입니다. 그날 일을 대표하는 블록 다이어그램으로 그려놔도 무척 좋습니다.

노트가 힘을 발휘하는 순간은 과제가 힘들어질 때입니다. 경우 뭔가 돌파구를 찾지 못하고 있을 노트를 펼쳐서 처음에는 어떤 생각을 했는지, 어떤 흐름으로 일을 진행했는지 읽다 보면 해결책이 보이는 경우가 많이 있었습니다. 과제 노트를 때마다 놀라는 점은 당시에는 너무나도 중요했다고 생각했던 점들이 과제가 진행되면서 중요하지 않게 되는 경우가 비일비재하며, 오히려 간과하고 넘어갔던 점들이 과제가 진행되면서 중요하게 되는 것을 확인할 있습니다. 그리고 불과 2, 3개월 전의 일들이 너무나 쉽게 잊혀지기에 과제 중반 이후로는 처음의 생각과 전혀 반대의 결론을 내리기도 한다는 점입니다. 특히 중요한 과제를 맡은 PM일수록 이러한 노트의 필요성은 중요해집니다. 다시 강조합니다. 인간은 망각의 동물입니다. 뭔가 내가 기억하고 있다고 생각하지만 중요한 부분을 잊고 있는 경우가 많습니다.

추천 도서

프로젝트 관리에 관한 내용은 짤막한 편으로 전달될 내용은 아닙니다. 다행히 좋은 책들이 많이 나와있어 책을 통해 다양한 정보를 수집하실 있습니다. 책을 추천하는 것은 편으론 쉬운 방법이지만 편으론 매우 조심스럽기도 합니다. 책이라는 것이 읽는 사람에 따라 전혀 다른 정보를 주기도 하기 때문이죠. 그럼에도 불구하고 널리 회자되는 책들을 위주로 소개하는 것은 크게 부담이 되지 않는다고 생각하여 추천 도서 목록을 뽑아봅니다. 

·       프레더릭 브룩스, "맨먼스 미신," 케이앤피북스 은탄환은 없다라는 명언이나 프로젝트 말기에 새로운 인력을 투입하지 말라 등은 책에서 나온 말입니다. 혹시 책을 아직까지 읽지 않았다면 읽어보기 바랍니다. 놀랍게도 1975년에 쓰여진 책이며 아직까지도 널리 읽히고 있습니다. 제가 인상 깊었던 문구를 인용해 봅니다. 각 문구 앞에 있는 숫자는 해당 챕터를 뜻합니다.

o   1.1 프로그래밍 시스템 제품은 개인사용을 목적으로 독자적으로 작성된 컴포넌트 프로그램보다 9 만큼 노력이 필요하다. 제품화하려면 3배가 것으로 예상된다. 컴포넌트를 설계하고 통합하고 테스트하여 일관된 시스템으로 만드는 데는 3배의 비용이 필요하다. 그리고 비용 요소들은 본질적으로 서로 독립적이다.

o   2.1 날짜에 쫓겨 프로그래밍 프로젝트가 실패하는 경우가 다른 모든 실패 원인을 합친 경우보다 많다.

o   3.3 적은 수로 구성된 똑똑한 팀이 최고다 - 가능한 머리수가 적을수록.

o   3.4 리더를 포함해서 사람으로 팀이 두뇌를 최고로 활용하는 경우가 많다.

o   4.5 시스템의 개념적 무결성을 얻으려면, 개념을 통제할 사람이 필요하다. 이는 변명의 여지없이 분명한 귀족정치다.

o   7.16 조직의 목적은 필요한 커뮤니케이션 조정 양을 줄이는 것이다.

o   7.19 하나의 조직에서 모든 종류의 특수한 조직 메커니즘이 트리 구조를 가진 조직의 커뮤니케이션 부족을 극복할 있게 고안되게끔 커뮤니케이션 구조는 트리 모양이 아니라 네트워크형이어야 한다.

o   10.5 작은 프로젝트라 할지라도 관리자는 처음부터 그런 일련의 문서들을 정식화하여야 한다.

o   10.6 작은 문서들을 준비하는 과정에서 생각을 정리하고 토론을 정제한다. 작문을 하려면 수많은 작은 결정을 내려야 한다. 바로 작은 결정들이 있기 때문에 명쾌하고 정확한 정책들이 애매한 정책들과 뚜렷이 구별되는 것이다

o   10.7 중요 문서 각각을 유지 관리하다 보면 상황 감시와 경보 메커니즘이 갖춰지게 된다.

o   11.3 대부분 프로젝트에서 번째 구축된 시스템은 거의 사용할 없다. 너무 느리거나, 너무 크거나 사용하기 어렵거나, 아니면 가지 모두에 해당되기 때문이다.

o   11.6 그러므로 하나쯤은 내버릴 각오를 하고 계획을 세워라. 어떻게 하든 결국 그렇게 밖에 없다.

o   14.2 참사보다 매일 조금씩 일정이 지체되는 것은식하기도 예방하기도 그리고 만회하기도 훨씬 어렵다.

o   14.3 정부가 발주하는 대형 프로젝트를 수행하는 도급업체들의 견적 행동 양식에 대한 연구 결과를 보면, 격주로 신중하게 고친 활동시간 견적은 시작 시점이 다가와도 크게 변하지 않으며, 활동 중에는 과다견적이 꾸준히 나타난다는 것을, 그리고 과소견적은 완성 일정을 3 정도 남겨놓기 전까지는 달라지지 않는다는 것을 있다.

o   14.11 번째로 만들어지는 표는 언제나 형편없다. 그리고 다음 번 표를 만들 때는 고안에 고안을 거듭하게 된다.

·       엘리 골드윗, " ," 동양북스 - 찬반이 너무나도 극명하게 나뉘는 책입니다. 저는 buffer 관리하라는 메시지를 핵심으로 봅니다만 다른 부분을 비판하시는 분들도 많습니다.

·       조엘 스폴스키, "조엘 소프트웨어," 에이콘 출판 - 야근을 하는 것이 생산성에 전혀 도움이 안 되는지, 개발자들이 진정 원하는 것이 무엇인지를 설명하는 책입니다.

·       제프리 페퍼, "휴먼 이퀘이션," 지샘 - 권과는 조금 다른 성격 인적 경영 관리의 책입니다만 팀장급 개발자라면 도움이 되는 내용을 많이 얻으실 있을 것입니다.

 

글을 마치며

행복한 개발자가 되기 위해 위드로봇 연구소에 있는 개발자들은 오늘도 답을 찾고자 헤매고 있습니다. 아마 글을 읽으시는 독자 여러분들도 마찬가지일 것이라 생각합니다. 분명 좋은 방법, 핵심인 내용이 있을 것입니다. 블로그(http://withrobot.tistory.com/281) 글의 전문을 올려 놓을 테니 댓글 형태로 적어주셔서 다른 분들과 공유해 주셨으면 합니다. 그래서 우리 모두가 행복한 개발자가 되었으면 합니다.

저작자 표시
신고
Posted by getcome
의도적으로 학교 개학하는 날에 맞춰 위드로봇 사업 개시일을 잡았습니다. 그러다 보니 기억하기도 쉽네요.

벌써 3년이나 흘렀나 싶습니다. 엔지니어들이 행복하게 일할 수 있는 일터는 없는가 고민하다가 그게 정말 힘든 일인지 한 번 직접 몸으로 부딪히며 겪어보자는 치기어린 마음 하나로 만든 연구소입니다. 3년이 지난 이 시점에서 과거를 돌아보면 어려웠던 점, 재미있었던 점, 아쉬운 점, 바보같이 굴었던 부분들이 머리를 스쳐갑니다. 미숙하고 부족함에도 불구하고 여기까지 올 수 있었던 것은 모두 다 주변 분들 덕분입니다.

무엇인가 해 냈겠다는 결과 위주보다는 어떻게 갈 것인가 과정을 중요시여기자며 만든 연구소이다보니 외형은 아직도 보잘 것 없고, 뭔가 딱히 해 낸 것도 없습니다. 하지만 오늘도 내일도 조금씩 조금씩 앞으로 가고 있을 것입니다. 

아래 사진은 성수동으로 사옥을 이전하면서 첫 업무를 시작하는 날 옥상에 올라 뜨는 해를 찍은 사진입니다.
저 해를 보며 위드로봇 맴버 모두가 건강하고, 행복하길 바랬으며, 우리로 인해 많은 분들이 행복해지길 빌었었습니다. 3살 생일을 맞이하여 다시 한 번 더 태양을 보며 초심을 유지하겠습니다.

저작자 표시
신고
Posted by getcome
치솟는 유가 덕분에 조금이나마 기름 소비를 줄여볼까 싶어 외부 출장이 없는 경우는 지하철로 출근하고 있습니다. 걸어서 출근은 조금 날씨 따뜻해지면 하라는 악마의 유혹에 넘어갔죠. 신발은 열심히 신고 다니고 있습니다. ^^;

목요일(10일) 꽤나 붐비는 2호선을 타고 연구실까지 왔습니다. 앞에서 옆에서 마구 밀치는 여느때에 비해 무지무지 붐비는 출근 길이였습니다. 

연구실에 도착해서 여느 때처럼 노트북을 꺼내 전원을 켰는데...
처음에는 바탕화면이 바뀐 것인줄 알았습니다. 화면을 잠시 바라보다... 가슴이 철렁 내려 앉더군요... 이런.... LCD가 깨졌다!



91년부터 노트북을 썼으니 20년 넘게 노트북을 써온 셈인데, 나름 터프하게 굴리며 써도 LCD가 깨져보긴 이번이 처음입니다. 노트북 가방에 고이 넣어 온 것이데... 노트북 구매한지 6개월도 안지났구요... T_T; 눈물이 앞을 가립니다.

부팅은 되는데 이대로 쓰기는 문제가 있습니다. ASUS 서비스 센터에 연락했더니 수리비는 30만원이고 당장은 LCD 재고 가 없답니다.  일주일 이상 기다려야 할지 모른다고 하네요. 노트북 데이터를 꺼내서 다른 컴퓨터에서 작업을 하자니 이것저것 신경써야 할 일이 많네요. 어떻게 해야 하나 고민하다 그냥 하루 컴퓨터 없이 한 번 지내보기로 하였습니다.
.
.
.

OTL... 정보화 시대에 대한 무지한 도전이었을까요? 11일부터 15일까지 비효율적인 업무처리에 패닉 상태까지 몰려야 했습니다. 밀린 업무 생각에 밤에 잠이 안 올 정도의 두통에 시달려야 했구요.

두손두발 들고 다른 노트북을 밤새 셋팅해서 16일부터 다시 작업을 시작했습니다만 아무래도 불편합니다. 뭐 하나 열면 프로그램 하나 설치해야 하고, 뭐 하나 작업할려면 자꾸 다운되고, 느리고, 버벅대고...

이드는 10일에 매우 비싼 출근을 하였고, 그 후유증으로 시름시름 앓고 있습니다.
저작자 표시
신고
Posted by getcome
거금들여 워킹 슈즈를 사고, 막상 걸을려다 보니 심심합니다. (이전 글)
거리도 잘 모르겠고, 어느 정도 속도로 걷고 있는지도 궁금하구요.

안드로이드 어플을 뒤져보니 카디오트레이너 라는 프로그램이 가장 인기가 있는 프로그램이더군요. 제작자는 한국인!

낼름 받아 설치해보니 오호~ 개념있는 프로그램입니다.
수요일부터 이 프로그램을 이용하여 집에서부터 회사까지 한강변을 통해 걸어가는 과정을 기록해 봤습니다. 집에서 회사까지 약 6.4km 정도되는데 목요일에는 조작 실수로 걸어가는 중에 동작이 멈추었었습니다. 그래서 더 짧게 나와있네요.


의외로 제가 빨리 걷더군요. 성인 남자 평균 보행 속도가 시속 4km로 알고 있었는데, 저는 6km 정도를 한시간만에 주파하는군요. GPS 데이터로 궤적도 나옵니다.

올림픽 대로에서 시작해서 영동대교까지 50분만에 주파하는 모습을 보실 수 있습니다.
아, 위 스크린 샷은 프로요로 업데이트를 했더기 기본으로 들어있는 스크린캡쳐 기능을 이용한 것입니다. 업데이트 되서 가장 좋아하는 기능 중에 하나입니다.

문제는!!!
3일을 연속 이 속도로 걸었더니 금요일 오후에 발등이 좀 아프더군요.
급기야는 워킹 슈즈를 신기만 해도 발등에 통증이 오는 상황까지 진행되었습니다.
신기한 것은 오히려 구두를 신으면 안 안프다는 사실...

주말에 열심히 주무르고 쉬었습니다만, 아직도 아픕니다.
결국은...

월요일 오전에는 병원에 들려야 할 것 같습니다.

뭐든 천천히 해야 하는데 골프칠때는 갈비뼈가 부러지더니 그나마 가장 쉽다는 걷기 운동에서도 어딘가를 다치는군요.
저작자 표시
신고
Posted by getcome
위드로봇이 사옥을 서초동에서 성수동으로 이전하였습니다. 덕분에 집에서 회사까지는 6km 정도가 되었습니다. 성인 보행 속도가 4km/h 이니 열심히 걸으면 한 시간 이내에 주파할 수 있는 거리죠.

상판식 하는날 걸어가 보았더니 예상대로 한 시간만에 도착할 수 있었습니다. 지하철을 타면 25분 소요되고 승용차로 오면 40분이 소요되니 걸어서 운동한다고 생각하면 시간 낭비도 심하지 않은 편입니다.

막상 하루에 두 시간씩 걸으려니 구두 신고 걷기는 뭐하고, 운동화는 없고 해서 요즘 유행하는 프로스펙스의 워킹 슈즈를 구매했습니다.


구매한 모델은 W Power 309 모델. 말 그대로 워킹 슈즈 중에서 가장 많이 걷는 헤비워커를 위한 모델입니다. 가격은 무려 122,000원... 그나마 129000원이 정가인데 7천원 깎아준 가격입니다.

생각해 보니 하루에 왕복 지하철 요금이 2천원이니 61일간 출퇴근을 걸어서 하면 본전 뽑는 셈입니다. 한달에 걸어서 출근할 날이 후려쳐 절반이라고 하면 11일 정도이니 꼬박 6개월은 걸어다녀야 본전을 뽑겠군요.

6개월 후에 포스팅하겠습니다. 본전을 뽑았는지 어땠는지...
그리고 몸무게 변화도 측정해야 겠네요. ^^;
저작자 표시
신고
Posted by getcome
바쁘다...

위드로봇 연구실을 만들고 나서 나를 정의하는 단어 중 맨 앞에 오는 단어가 되어버렸다.
여유있게 천천히 가자고 만든 연구소가 내 등을 떠밀고 내 의지대로 할 수 없는 괴물이 되었다. 괴롭고 고통스러운 시간이 계속되었고, 문제를 해결해 보려고 여러 가지 방법을 다 써보았지만 효과는 없었다.

멀리 돌아 돌아 찾은 답은 박사과정 훈련소에 있을 때 주말 사찰에 갔다가(불교도는 아니지만 다들 빵과 콜라에 교회를 선택하길래 떡을 준다는 인기없는 절에 한 번 가봐야겠다는 생각에 갔던) 들었던 '일체유심존'...

모든 것은 맘먹기 나름이다.

여유 있다고 생각하면 여유가 있는 것이고, 바쁘다고 생각하면 바쁜 것이겠지.

뜬금없이 다시 블로그에 와서 끄적거리는 것은 그래도 이렇게 글 쓸때가 좋았던 것 같았기에 다시 여유를 찾고자 써 본다.
저작자 표시
신고
Posted by getcome