제2회

월드 스마트그리드 산업대전

편집부_ press@ntrex.co.kr

지난 11월 16일부터 18일까지 사흘간 서울 삼성동 코엑스에서 ‘월드 스마트그리드 산업대전’이 열렸다. 국내대표 국내유일의 스마트그리드 종합 전문 전시회로서, 스마트그리드 대국민 홍보와 이해를 확산시키고 새로 개발된 스마트그리드 기술 및 관련 제품 전시를 통한 기술교류확대를 통해 비즈니스 기회를 새롭게 창출할 수 있는 기회를 제공하였다. 총 85개사 350부스가 참여한 이번 전시회는 크게 대기업과 중소기업으로, 전기자동차 분야와 배터리 분야로 나뉘어 진행되었다.

종합기업관의 대기업부스들

LS에서 선보인 전기차 충전 시스템 시연장

삼성전자에서는 태양열 등을 활용하여 가전 제품과 생활기기 등을 작동하는 솔루션을 소개하였다.

중소기업관의 관련 기업 부스들. 오른쪽은 남전에서 선보인 무정전단자대.

LS에서 선보인 전기차 충전 시스템 시연장

Smart Mobile! Smart Enterprise!

Smart Life!

RFID/USN KOREA 2011

편집부_ press@ntrex.co.kr

지난 11월 16일부터 18일까지 서울 삼성동 코엑스에서 「Smart Mobile! Smart Enterprise! Smart Life ! 」란 주제로 제7회 RFID/USN Korea 2011 국제 전시회 및 컨퍼런스가 열렸다. 다양한 RFID/USN 제품 및 솔루션과 적용된 사례를 통해 산업 및 공공부문의 IT 융복합 서비스 도입 촉진과 일반인 대상 체험 서비스 기회를 제공하여 RFID/USN 및 IT융합 서비스에 대한 대국민 인식 제고를 통해 RFID/USN 시장 창출과 활성화를 위한 다양한 행사가 개최되었다.

RFID/USN KOREA 전시회에 걸맞게 모든 업체 부스에 설치되어 있었던 RF 태그 방식 방명록	메가박스에서 선보인 NFC존 시연 모습. 이제 극장에서도 손쉽게 발권에서부터 간식 구매까지 모바일로 쉽고 편하게 할 수 있는 세상!

㈜CEST에서 전시한 전자 가격표시 시스템(ESL : Electronic Shelf Label) – 대규모 네트웍이 가능한 ZigBee 기술을 적용하여 유통 매장 내 상품 가격의 실시간 변경 및 관리와 광고, 홍보, 판매를 위한 정보 전송 등 다양한 서비스 제공이 가능하다.

전자부품연구원에서 선보인 산업 플랜트용 USN(Ubiquitous Sensor Networks) 패키지 시스템 기술

이동 통신사 간의 불꽃 튀는 경쟁!

전기자동차 교통안전융합체계 연구단의 Smart e-Bus System

ETRI에서 선보인 USN 기반 동작인식 체감형 게임, 배구 경기를 실감나게 해볼 수 있었다.	HF RFID 다량/적층 태그 인식 시스템 – BLACKJACK 게임의 쌓인 칩의 갯수를 알 수 있다.

 로보월드 

     참관기 2011

글 | 이원영 기자_richard@ntrex.co.kr
사진 | 이용세 기자_edgar@ntrex.co.kr

지난 10월 27일부터 10월 30일까지 킨텍스에서 올해로 6회째를 맞이하는, “로보월드2011”이 열렸다. 올해는 작년에는 없었던 “로봇市” 공간을 따로 만들어 실생활과 밀접하게 연관되어 있는 로봇들을 많이 선보였다.

다양한 교육용 로봇

요즘은 학교에서 특별활동 등으로 다양한 로봇 교육이 많다보니, 다양한 업체의 다양한 교육용 로봇들이 많이 선보이고 있었다.

로보트론과 로보링크의 교육용 로봇들

휴머노이드 로봇

사람과 같은 형태의 로봇들이 서비스시장과 의료분야 등 다양한 분야에 활용되면서, 다양한 휴머노이드 로봇들도 전시되어 있었다.

로보티즈에서 선보인 휴머노이드 로봇(좌)과다양한 휴머노이드 로봇들(우)
곧 디바이스마트에서 판매예정인 동부로봇의 호비스(HOVIS) 시리즈들

물고기 로봇과 방사능 탐사로봇, 그리고 로봇市에 전시된 로봇들

여러 업체에서 각종분야에 활용되고 있는, 안내로봇 및 의료용 로봇등을 가지고 하나의 도시처럼 꾸며놓고 있었다.

에스알시㈜의 물고기 로봇	로보닥(ROBODOC)-정형외과에서 사용되는 수술로봇
로보쓰리에서 선보인 “트랜스포머로봇”	원자력 연구원의 방사능 탐사로봇
원자력 연구원의 방사능 탐사로봇	현대중공업의 산업용 로봇

디바이스마트 이전식

김형준 기자_ episode@ntrex.co.kr

올 가을들어 가장 추웠던 지난 11월 24일, 인천으로 이전한지 두달여 만에 지금까지 함께 노력한 임직원들과 많은 도움을 주셨던 협력업체분들 및 내외빈들을 초대하여 새로운 도약, 새로운 출발을 알리기 위한 이전식이 진행되었다.

인천정보산업진흥원의 조성갑 원장님을 비롯하여, 한국로봇산업협회 정낙균 전무님, 인천산업단지 5, 6공단 안성기 지사장님 외 각 협력업체 관계자분들이 이전식에 참석해주셔서 자리를 빛내주셨다.
이번 이전식에는 그간 엔티렉스가 걸어왔던 회사 연혁 소개를 시작으로 대표님의 환영사, 내빈 대표님들의 축사 및 소개와 함께 사업번영을 위한 고사와 만찬순으로 진행이 되었다.

환영사를 하고 계신 오상혁 대표님과 회사 연혁 소개중이신 박경철 상무님
인천정보산업진흥원 조성갑 원장님, 한국로봇산업협회 정낙균 전무님

비록 이전식에 모시지는 못했지만, 지금까지 저희의 성장과 발전에 많은 도움과 사랑을 주셨던 디바이스마트 고객님들께도 이 지면을 빌어 감사의 인사를 드립니다.

 대한민국 이공계 기(氣)살리기 프로젝트

제2회 디바이스마트

캡스톤 디자인 공모전

수상작 발표회

정현진 기자_ blue7563@ntrex.co.kr

올해로 2회째를 맞는 디바이스마트 캡스톤 디자인 공모전이 약 5개월간의 제작기간 끝에 지난 11월 11일 막을 내렸다. 1회 대회의 성공적인 개최에 힘입어 2회에는 더 많은 팀들이 참가신청을 하였으며, 그 중 우수한 3팀을 선정, 5개월동안 프로젝트를 수행하였다. 11월 11일 선정된 3팀의 최종 발표회가 있었는데, 이번 대회에는 심사결과 아쉽게도 최우수상팀은 없었으며, 우수상 1팀과 입선 2팀이 선정되었다.

우수상에 선정된 서울과학기술대학교 Finale 팀의 발표모습,보행보조기구 작품의 시연장면, 그리고 수상 모습.

입선팀인 조선대학교 I.M.F 팀의 탐사주행로봇. 새로운 이동 메커니즘을 적용하여 장애물에 구애받지 않고 주행할 수 있도록 설계하였다고 한다.

인천대학교 여학우 3명으로 구성된 삼인삼색팀. 자동 볼륨 조절이되는 MP3와 헤드셋을 합쳐 여러 가지 편의성을 부여한 작품. 수상 모습.

각 프로젝트에 대한 자세한 내용은 디바이스마트 매거진에서 천천히 만나보기로하고, 더욱더 발전된 모습의 3회 대회를 기약해본다.

프리셋 기능을 갖춘

PWM 인두 온도 제어기 만들기!

이민주 객원기자

시작글
온갖 휴대전자기기가 쏟아져 나오고 새로운 표준과 기술이 나올 때 마다 밀려나는 구식 표준들… 더 작은 부품, 더 작은 규격, 새로운 규격에만 맞는 전자부품들이 주종을 이루면서 DIY를 하는 사람에게 고민거리가 하나 생겼다. 부품의 크기나 핀 간격이 좁아지면서 납땜하기 불편해졌고 부품에 따라 인두 열량을 조절해야 했던 것. 시중에는 온도 제어 인두기가 많이 출시되었지만, 값이 비싸 아마추어들에게는 구매하기 어려웠고, 큰 마음을 먹고 온도 제어 인두를 구매했다고 하더라도 온도설정이 불편한 것도 사실이다.
필자는 여러 대의 인두를 사용해보면서 온도 설정의 편리성을 최우선으로 하고, PWM제어를 통해 온도가 최대한 일정하게 유지가 되도록 하였으며, FND표시를 적용해 고급 인두기가 부럽지 않도록 제작해 보고자 한다.
인두 핸들은 검증된 HAKKO 907 제품을 사용할 예정이므로, 신뢰성, 성능, 편리성 한 부분 한 부분 모두 만족시켰다.

준비
이번 DIY는 220V를 직접 이용하고 비교적 고전류를 흘려주는 회로이므로 부품의 방향 회로 결선에 주의한다.
또한 프로그램 다운로드할 때에도 퓨즈비트부터 설정해야 한다는 것을 명심하자.
그리고 인두 핸들은 HAKKO 907제품만 사용이 가능하다.
디바이스마트와 필자는 컨텐츠만 제공할 뿐 이 기사를 따라하다 발생한 모든 사고에 대해 일체 책임을 지지 않는다.

먼저 인두 온도 제어기에 들어가는 부품 리스트를 소개한다.

기본적으로 필요한 공구 리스트	인두 온도 제어기 부품 리스트

외관 디자인에 따라 버튼, FND사양은 변경해도 좋으며, 필요시 케이스 제작 공구나 필요한 것들을 융통성 있게 준비하면 된다.
특별히 정해진 케이스를 사용하지 않았으므로 재료는 정하지 않았지만 필자는 포멕스와 아크릴을 이용하기로 했다.
아크릴은 아크릴 접착제로 붙지만 포멕스와 접착할 때에는 순간접착제를 이용한다.

제작 과정

구상한 디자인이 있다면 전체적인 기구 디자인을 고려해 기판을 자른다. PCB 커터가 없으면 페놀기판을 사용하도록 하고, PCB 절단이 가능하다면 에폭시 기판을 사용하자(디바이스마트에서 판매하는 페놀기판은 휘어짐 현상이 없어 어느 것을 사용해도 무방하다).
사용하기 편리하게 하려면 온도표시에 필요한 FND와 조작 스위치, 커넥터를 우선 배치하는 것이 중요하다 하겠다. 역시 기존 인두제어기와 비슷한 위치에 FND와 조작 스위치를 배치하였다.

기판 크기를 적절히 가늠해 FND와 스위치를 끼운다. 가운데 공간이 생기게 만들었는데 가운데 부분에 인두 핸들 커넥터가 위치하도록 할 예정이다.

기판을 뒤집어 납땜한다. 기판을 뒤집을 경우 부품과 PCB사이가 벌어질 수 있으므로 손으로 최대한 밀착하고 납땜한다.

조작부를 수직으로 세울 예정인데, PCB접속용 몰렉스가 있어 사용하였다.

저항을 끼운다. 조작부에 들어가는 저항은 FND 전류제한 저항, FND전원보조 풀업, 스위치 풀업으로 구성된다.

인두 핸들 접속용 DIN커넥터를 삽입한다. 다리 굵기가 약간 굵어 끼우기가 정말 힘들다. 아예 홀이 크게 뚫린 기판을 사용하던지(그런 기판을 디바이스마트에서 판다.), 기판에 드릴로 구멍을 뚫어야 하는데, 기판을 뚫기 싫어 억지로 끼웠다. 인내심을 갖고 20분 동안 힘을 이리저리 주니 결국 들어갔다. 페놀기판에도 끼워봤는데 1~2분 정도 살살 달래주며 끼워주니 잘 들어갔다.

MCU를 PCB에 그대로 접속하면 고장진단, 수리가 어려우므로 IC소켓을 먼저 끼운다.

필자는 AC트렌스를 사용할 예정이라 브릿지 다이오드를 사용했다. 역시 다리 굵기가 굵은데 손이 아파 이번에는 그냥 드릴로 뚫어 끼웠다. 브릿지 다이오드를 다른 제품으로 대체하려면 6A이상의 제품으로 선택한다.

MCU와 센서, OPAMP는 5V단전원을 사용한다. 입력 전압 범위가 넓고 변환효율이 좋아 발열이 적은 스위칭 레귤레이터를 사용했다.

레귤레이터 근처에 다이오드와 인덕터를 삽입한다.

콘덴서를 삽입한다. 전해콘덴서의 경우 메인 전원-인두커넥터 사이에 연결 하는 것이 좋겠다. 입력쪽 콘덴서는 반드시 35V이상의 제품을 사용한다.

MCU ADC의 안정도를 높이기 위한 인덕터를 사용한다. 굳이 없어도 사용하는데 큰 불편함이나 오류는 없다.

각종 경고, 동작 상태를 알려주는 스피커를 장착한다. MCU에서 PFM제어로 출력되므로 부저가 아닌 스피커를 사용해야 한다.

OPAMP역시 교체가 쉽도록 IC소켓을 사용한다.

인두를 직접 ON/OFF제어할 FET를 삽입한다. FET는 꼭 같은 것을 사용할 필요는 없는데, 다만 N채널 FET이어야 하고, 40V이상, 5A이상을 견뎌야 하며, RDS(on) 저항이 0.1옴 이하로 작은 것이 발열이 적게된다. 참고로 순간전류 4A까지 소모한다.

모노콘덴서를 붙인다.
모노콘덴서는 모노리딕콘덴서로 불리기도 하는데, 전원 안정화나 센서 값의 안정화 목적으로 사용되므로 세라믹콘덴서를 사용해도 상관없다.

몰렉스를 사용해 케이블을 쉽게 탈부착할 수 있도록 한다. 순간 전류는 높지만 원하는 온도에 도달하면 동시에 많은 전류를 사용하진 않으므로 비교적 얇은 전선을 그대로 사용했다. 사실 디바이스마트에서는 몰렉스에 케이블을 끼운 제품을 판매하는데 몰렉스를 제작하기 번거로우므로 완제품 몰렉스를 사용한 것이다.

부품을 모두 배치했으면 기판을 뒤집어 배선한다. 필자는 전원을 우선으로 연결한 뒤 기타 신호선을 가는 테프론선으로 처리했다. 개인적인 생각이지만 테프론선보다 에나멜선이 더 편리한 것 같다.

기판이 완성된 앞 뒤 모습

케이스까지 제작한 후 프로그램을 다운로드 해도 되지만 필자는 케이스 조립 전에 프로그램을 다운받았다. ISP단자를 마련해도 좋고 필자처럼 없앤 후 와이어로 결선 후 다운받아도 무방하다. 공간이 협소해 ISP단자를 생략했다.
프로그램은 www.itstyle.kr/10635에서 다운로드 가능하고 프로그램 다운로드 방법도 설명되어 있다. 해당 자료와 함께 주의사항이 담겨져 있겠지만 반드시 퓨즈비트를 먼저 세팅하고 프로그램을 다운로드해야 한다. 기본 1MHz 내부RC오실레이터로 설정되어 있는데, 이 상태에서 프로그램을 다운로드 하면 스피커에 저주파 펄스가 전달되 MCU나 회로에 무리를 줄 수 있다.

프로그램을 다운받아 동작이 잘 되는지 확인했으면 케이스를 제작하도록 한다. 케이스 재료로는 아크릴과 포멕스를 이용했다.
참고로 필자는 무게가 나가는 트렌스를 이용할 계획이어서 바닥면은 무거운 무게를 견디도록 5T로 비교적 두꺼운 포멕스를 사용했다.

케이스 조작부는 세밀하게 가공할 필요가 있어 2T짜리 얇은 포멕스를 사용했다. 버튼, FND, 커넥터와 위치를 비교해 가공할 위치를 파악한 후 절단한다.

조작부 뿐만 아니라 모든 모서리 부분은 끌이나 사포같은 거친 물건으로 문질러주면 좀 더 깔끔하게 마무리 된다.

보통 케이스에 서포터를 박고 기판에는 구멍을 뚫어 나사를 체결하지만, 케이스 전면이 2T로 얇아 나사못이 튀어나와 반대로 나사를 박을 수 있도록 너트를 기판에 납땜하는 모습이다. 케이스를 만들 때 이 방법도 참고해 보기 바란다.
후면에는 AC 파워소켓(퓨즈), DC 입력, 전원스위치를 장착할 수 있도록 구멍을 뚫는다.

사진은 가공 중 스위치를 끼워보는 모습이다. 끼우는 것은 케이스가 완성된 후에 끼우면 된다.

바닥면에는 PCB고정 서포터, 트렌스포머 고정 볼트 같은 날카로운 부품들이 있어 책상을 긁을 수 있다.
고무발을 부착한다.

AC 파워라인 배선을 한다. AC 인렛(퓨즈 포함) – 전원 스위치 – 트렌스포머 혹은 SMPS – PCB 순서로 연결된다.
납땜면은 외부에 노출되지 않도록 수축튜브로 보호해야 한다.

이번에는 DC 라인 배선을 한다.
DC 커넥터 – 전원 스위치 – PCB 순서로 연결된다. 역시 납땜 면이 외부에 노출되지 않도록 수축튜브로 보호하도록 한다. DC입력을 만들어둔 이유는 특수한 경우를 위해 사용할 예정인데, 예를 들어 필자의 경우는 전원이 없는 곳에서 차량 시거잭을 사용하여 인두를 사용하기 위함이다. 이 때문에 DC와 AC가 함께 차단되도록 4P짜리 스위치를 사용했다.

주의할 점은 AC가 연결된 상태에서 동시에 DC어댑터나 차량 시거잭을 연결하면 화재로 이어질 수 있으므로 절대 안된다.

완료하고 뚜껑을 제외한 상태.

AC 인렛은 퓨즈박스 일체형으로 편리하다. 특히 예비퓨즈를 수납할 수 있으므로 퓨즈를 두 개 구매해 끼워 넣으면 된다.
시거 잭의 경우는 디바이스마트에서 판매중이거나 시중에 있는 시거 잭이 보통 1~3A정도의 퓨즈를 내장하고 있다. 초기에서 인두에서 많은 전류를 사용하므로 5A정도의 퓨즈로 교체하는 것이 좋다.

사용하기 전에…

HAKKO 907 핸드스틱은 원래 HAKKO 936/937, FX-888같은 모델에 사용되는데 핸들 잭이 빠지지 않도록 잠금장치 같은 것이 있다. 이 잠금장치 때문에 잭에 끼워지지 않는데 잠금장치는 필요 없으므로 잘라버리던지 케이블 타이 같은 것을 끼워 벌려서 빼낸다.

인두팁은 여러 종류가 있으므로 사용자 취향대로 교체할 수 있다.

사실 필자가 많은 경험을 한 것은 아니지만 많은 엔지니어분들, 생산라인, A/S센터등을 봤지만 온도를 정확히 교정해 사용하는 곳은 거의 보지 못했다. 특히 아마추어 분들이 만들어 사용하기에는 온도교정은 의미가 없다고 할 수 있겠다. 인두를 사용하면서 종류에 따라 어느 온도에서 납땜이 잘되는지 정도만 중요하기 때문이다.

팁의 온도를 측정할 수 있는 장비가 있다면, 온도를 측정하면서 보정해도 되고, 그냥 무난하게 사용하고자 한다면 저항 150Ω을 온도센서 핀 위치에 꽂고 450℃가 표시되게 하면 된다.

참고로 같은 종류의 인두라 하더라도 인두마다 센서의 저항 값의 오차가 심하고, 사용함에 따라 많은 오차가 발생할 수 있다.

AC를 사용하게 되면 정류된 전원이 그대로 DC입력으로 나오게 된다. 따라서 AC와 DC입력을 둘 다 꽂았을 경우 고장을 넘어서 화재를 일으킬 수 있으므로 절대 주의한다. 불안하다면 필요한 입력만 적용하는 것도 좋겠다.

기자소개 제작 / 사진 / 글 이민주 객원 기자 현재 원주 한라대학교 전기전자 공학과를 재학중이며, 개인 홈페이지 http://www.itstyle.kr 운영중.

개발자 출신 신출내기 사장의 

프로젝트 관리 표류기

글 : 위드로봇(주) 김도윤 대표

글을 쓰게 된 계기

제가 일하고 있는 위드로봇(주)가 서초동에서 성수동으로 확장 이전한 것을 기념하여 디바이스마트 고객을 대상으로 무료 공개 강좌를 진행한 적이 있습니다. 이 강좌 내용을 디바이스마트 매거진에 지면으로 옮기며 독자 분들과 만난 지 일년이 되어 갑니다.
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)은 없습니다”. 만병통치약처럼 어떤 소프트웨어 도구를 사용한다고 해서 문제가 해결되는 것은 아니라는 뜻입니다. 위드로봇에서도 괜찮다는 방법은 이것저것 도입해서 적용해 보았습니다만 결과적으로 대부분 실패로 끝났습니다. 분명 이러한 도구들은 유용하고 필요합니다. 하지만 근본적인 문제의 원인을 해결해 주는 것은 아니라는 뜻입니다. 위드로봇에서는 나름대로 몇 가지 답을 찾았다고 생각하기에 이 부분을 공유하고자 이 글을 씁니다.

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

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

1. 고객이 찾아와 아이들이 재미있게 놀 수 있는 놀이기구를 만들어 달라고 이렇게 설명했습니다. 2. 해당 과제 PM은 고객의 요구를 이렇게 이해했습니다. 3. 실무진은 이렇게 이해하고 설계를 시작했습니다. 4. 실무진이 구현한 형태는 이렇습니다.

5. 성능 검증을 위해 고객에게 전달되는 초기 버전 모습입니다. 6. 프로젝트 중간 발표는 이렇게 합니다. 7. 프로젝트 진행 중 문서 작업 상태입니다. 8. 최종적으로 구현한 모습입니다.

9. 고객에게 청구되는 비용은 이런 놀이기구를 만들 정도의 비용이 청구됩니다. 10. 추후 지원에 대한 모습입니다. 11. 광고는 이렇게 나가겠죠. iSwing!!! 12. 원래 고객의 머릿속에 있었던 놀이기구는 이거였습니다.

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

이 멋진 사진은 미국의 요세미티 국립공원에 있는 해발 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년에 쓰여진 책이며 아직까지도 널리 읽히고 있습니다. 제가 인상 깊었던 문구를 인용해 봅니다. 각 문구 앞에 있는 숫자는 해당 챕터를 뜻합니다.1.1 프로그래밍 시스템 제품은 개인사용을 목적으로 독자적으로 작성된 컴포넌트 프로그램보다 약 9배 만큼 노력이 더 필요하다. 제품화하려면 3배가 들 것으로 예상된다. 컴포넌트를 설계하고 통합하고 테스트하여 일관된 시스템으로 만드는 데는 3배의 비용이 필요하다. 그리고 이 비용 요소들은 본질적으로 서로 독립적이다. 2.1 날짜에 쫓겨 프로그래밍 프로젝트가 실패하는 경우가 다른 모든 실패 원인을 다 합친 경우보다 많다. 3.3 적은 수로 구성된 똑똑한 팀이 최고다 – 가능한 머리수가 적을수록. 3.4 리더를 포함해서 두 사람으로 된 팀이 두뇌를 최고로 활용하는 경우가 많다. 4.5 시스템의 개념적 무결성을 얻으려면, 개념을 통제할 사람이 필요하다. 이는 변명의 여지없이 분명한 귀족정치다. 7.16 조직의 목적은 필요한 커뮤니케이션 및 조정 양을 줄이는 것이다. 7.19 하나의 조직에서 모든 종류의 특수한 조직 메커니즘이 트리 구조를 가진 조직의 커뮤니케이션 부족을 극복할 수 있게 고안되게끔 커뮤니케이션 구조는 트리 모양이 아니라 네트워크형이어야 한다. 10.5 작은 프로젝트라 할지라도 관리자는 처음부터 그런 일련의 문서들을 정식화하여야 한다. 10.6 이 작은 문서들을 준비하는 과정에서 생각을 정리하고 토론을 정제한다. 작문을 하려면 수많은 작은 결정을 내려야 한다. 바로 이 작은 결정들이 있기 때문에 명쾌하고 정확한 정책들이 애매한 정책들과 뚜렷이 구별되는 것이다. 10.7 중요 문서 각각을 유지 관리하다 보면 상황 감시와 경보 메커니즘이 갖춰지게 된다. 11.3 대부분 프로젝트에서 첫 번째 구축된 시스템은 거의 사용할 수 없다. 너무 느리거나, 너무 크거나 사용하기 어렵거나, 아니면 이 세 가지 모두에 해당되기 때문이다. 11.6 그러므로 하나쯤은 내버릴 각오를 하고 계획을 세워라. 어떻게 하든 결국 그렇게 될 수 밖에 없다. 14.2 큰 참사보다 매일 조금씩 일정이 지체되는 것은 의식하기도 예방하기도 그리고 만회하기도 훨씬 어렵다. 14.3 정부가 발주하는 대형 프로젝트를 수행하는 도급업체들의 견적 행동 양식에 대한 연구 결과를 보면, 격주로 신중하게 고친 활동시간 견적은 시작 시점이 다가와도 크게 변하지 않으며, 활동 중에는 과다견적이 꾸준히 나타난다는 것을, 그리고 과소견적은 완성 일정을 약 3주 정도 남겨놓기 전까지는 달라지지 않는다는 것을 알 수 있다. 14.11 첫 번째로 만들어지는 표는 언제나 형편없다. 그리고 다음 번 표를 만들 때는 고안에 고안을 거듭하게 된다.
	· 엘리 골드윗, “더 골,” 동양북스 찬반이 너무나도 극명하게 나뉘는 책입니다. 저는 buffer를 관리하라는 메시지를 핵심으로 봅니다만 다른 부분을 비판하시는 분들도 많습니다.
	· 조엘 스폴스키, “조엘 온 소프트웨어,”에이콘 출판 왜 야근을 하는 것이 생산성에 전혀 도움이 안 되는지, 개발자들이 진정 원하는 것이 무엇인지를 잘 설명하는 책입니다.
	· 제프리 페퍼, “휴먼 이퀘이션,” 지샘 위 세 권과는 조금 다른 성격 인적 경영 관리의 책입니다만 팀장급 개발자라면 도움이 되는 내용을 많이 얻으실 수 있을 것입니다.

글을 마치며

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

위드로봇㈜ 사무실 전경