Talk about Software with hani

팀장의 고백  목차

• 게으른 PL이 프로젝트 일정을 지연시킨다.
• 개발명세서? 그 귀찮은 짓을 왜 하지?
• 개발계획은 팀장의 것? 팀원의 것? (오늘의 Post)
• 팀장! 당신은 진정한 Nego를 할 수 있는가?
• 형상 관리, 그까이거 그냥 폴더에 보관하면 되지
• UnitTest! 미완의 시도
• 인수테스트, 북치고 장구치고
• Trac을 통한 품질 관리
• 진정한 프로젝트의 가치는 어디에서 오는 것일까?

프로젝트 일정과 나비효과

프로젝트의 일정을 100% 지키는 가장 좋은 방법은 무엇일까? 답은 간단하다. 프로젝트를 하지 않는 것이다. ^^ 프로젝트를 하지 않는다면 어떤 일이 벌어질까? 개발자나 팀장인 경우 월급을 못 받기 때문에 (모아 놓은 돈이 없다면) 당장 카드 결재에 빨간 불이 들어올 것이다. 특히 가장으로써 가족을 책임지고 있다면 문제가 더 심각하다. 몇 달 프로젝트가 없어 직장에서 짤리는 날이면 가족 해체의 위기까지 몰릴 수 도 있다. 아이들은 가출하고 부인은 새로운 삶을 찾아 떠나고, 좌절한 남편은 Homeless로 전락 하고… 단지 프로젝트 일정을 지키기 위해서 프로젝트를 하지 않았을 뿐인데 인생이 망한다.(조금은 오버다~)

그렇다면 회사 입장에서 프로젝트를 하지 않는다면 어떤 문제가 있을까? 톰 디마르코, 티모시 리스너의 리스크 관리(Waltzing with Bears, 인사이트)에서는 프로젝트의 Risk와 사업의 기회를 다음의 예로 설명하고 있다.

메릴 린치(Merrill Lynch)의 초기 온라인 트레이딩 시장 지연이 그 대표적인 사례다. 메릴 린치의 입장에서 소위 온라인 트레이딩이라는 것은 어렵고 먼 이야기처럼 느껴졌기 때문에 그들은 이를 무시하기로 결정했다. 그들은 증권 중개 풀 서비스(높은 중개 수수료와 중개인들이 고객들을 영속적으로 유지하는 형태)의 시대가 다시 돌아오기를 희망했으며 … 오늘날, 증권 중개 풀 서비스는 과거 주유소의 풀 서비스와 같이 전락했다. 그리고 지금은 메릴 린치도 고객들에게 저렴한 수수료의 온라인 트레이딩 서비스를 제공한다. 그러나 이렇게 되기까지 10년 가까이 낭비했다. 메릴 린치는 가장 늦게 변화를 받아들인 증권회사였다. … 이트레이드를 비롯한 몇몇 회사는 신생 회사였으며, 이러한 환경의 변화를 기회로 여기고 이를 이용하려는 목적으로 설립되었다. 그러므로 설사 온라인 트레이딩이 단지 한때의 유행으로 지나가 버리고, 이트레이드가 도산했다고 해도 이미 리스크를 감안해서 투자된 자본 외에는 더 손해볼 게 없을 것이다. 반면 피델리티나 슈왑의 상황을 달랐다. 그들은 업계에서 이미 자리를 잡은 회사들이었으로, 상대적으로 잃을 것도 많았다. … 그럼에도 피델리티와 슈왑은 기꺼이 리스크를 감수하는 선택을 했다.

프로젝트는 본질적으로 위험한 것이다. 그럼에도 불구하도 프로젝트는 해야 한다. 개발자는 먹고 살기 위해서, 회사는 새로운 비즈니스의 기회를 잡기 위해서… (그러나 프로젝트 자체는 위험한 것이기 때문에 위험관리를 해야한다. 위험 관리는 이 post의 주제가 아니기 때문에 다음 기회에 다루도록 하겠다.) 이런 위험에는 어떤 종류가 있을까? 위험의 종류는 크게 시간의 위험과 비용의 위험으로 나눌 수 있다. 비용의 위험이란 쉽게 말해 프로젝트의 결과가 쓰레기가 될 때 투입한 비용이 공중에 날아갈 위험이다. 이에 반해 시간의 위험은 프로젝트가 제 때에 끝나지 못할 위험이다. 프로젝트가 제 때에 끝나지 못한다는 것은 사업 기회를 선점할 가능성이 낮아지고, 결국에는 프로젝트를 먼저 완료한 다른 기업에게 선수를 뺏길 수 있다는 뜻이다. 비용 위험은 특히 고객이 안고 가는 것이라면, 시간 위험은 프로젝트 수행 주체가 가져가야할  것이다.

정해진 프로젝트 일정, 바꿀 수 없나?

그런데 프로젝트 기간은 종종 사업적인 이유로 D-day가 정해진다.따라서 프로젝트 수행 주체가 기간을 조정할 수 있는 여지가 매우 적다.  이것은 프로젝트 수행 주체로써 매우 우울한 사실이다. 현실적으로 보아도 프로젝트 계약 단계에 프로젝트를 수행할 프로젝트 관리자라던지, 개발자의 의견이 많이 반영되지 못하고 있다. 정확한 프로젝트의 일정을 산정하기 위해서 완결되어야 하는 사전 작업은 설계 작업이다. 설계 작업은 소프트웨어 개발을 위해서 기본적인 자료를 제공해 주기 때문에 하기도 하지만, 설계 작업을 해야지만 개발 작업을 할당할 수 있다. 즉, 설계는 소프트웨어 개발을 할 때 일의 분량을 산출하고 산출된 일을 나누기 위한 사전 작업인 셈이다. 그런데 대부분의 프로젝트는 영업에서 따오거나 기획에서 기획을 끝낸 후 개발팀에게 몇월 몇일까지 프로젝트를 완료해달라고 부탁한다.(물론 이렇지 않은 조직도 있다… 그 수가 얼마나 많은지는 모르지만) 그런데 이것은 좋은 방식이 아니다. 정확한 프로젝트 기간을 산정하기 위해서는 프로젝트 구간을 크게 두구간으로 나누는 것이 바람직하다. 이와 관련된 이야기는 아래의 post를 참고하길 바란다.

아버지는 말하셨지, “공짜 점심은 없단다!”

이제야 본론이다. 오늘 이야기의 출발점은 설계 작업이 어느 정도 끝나고 실제 개발 인력이 투입되서 개발을 진행할 때다. 개발을 진행하기 위해서는 반드시 개발 일정 계획이 필요하다는 사실에는 누구나 동의할 것이다. 그렇다면 합리적인 개발 일정은 어떻게 작성할 수 있을까? 우선 정확한 개발일정을 산출하기 위해서는 합리적인 판단을 도와줄 수 있는 기본 자료가 필요하다. 다음은 정확한  프로젝트 일정 산정을 위해서 필요한 데이터다.

• Software의 상세 설계안
• 유사 프로젝트 투입 공수
• 개발자의 능력

그렇다면 이 세가지가 어떻게 조합 되서 정확한 프로젝트 일정을 산정할 수 있는지 살펴보자.

Software 상세 설계안

우선 개발하고자 하는 software의 상세한 설계가 나와야 한다. 이 상세 설계안이 나오지 않는다면 무엇을 개발할지 모른다. 예를 들어서 상세 설계안이 “사용이 편리한 웹 하드 개발”이라고 해보자. 이것은 상세 설계가 아니다. 개발 명세서 단계도 지나지 않은 단순한 고객 요구 사항이다. 그러나 이런 수준의 설계를 가지고 개발을 하기도 하는게 우리나라 SI의 현실이기도 하다. 도대체 “사용이 편리한 웹 하드 개발”은 무엇을 말하는가? Drag & Drop 기능을 제공해야 하는지? P2P 방식인지 서버/클라이언트 방식인지? 사용이 편리하다는 말 뒤에는 빙산의 일각처럼 너무나 많은 고객 요구 사항이 있기 때문에, 이 설계안을 가지고 개발을 시작하면 칡뿌리 캐듯이 숨은 고객 요구 사항이 발생한다. 그렇기 때문에 이 설계안을 가지고 산정한 개발일정은 아무런 의미가 없다. 정확한 설계안이 나올 수 없다면 XP에서 사용하는 Story card 수준의 고객 요구라도 작성해야 한다. XP에서 설계를 안하는 것처럼 보이지만 사실 Story card는 일종의 고객 요구 분석인 셈이다. 따라서 정확한 개발 일정 산출을 위해서는 반드시 어느 수준 이상의 상세 설계나 고객 요구 분석이 선행되어야 한다.

유사 프로젝트 투입 공수

어느 정도 설계가 끝났다면 각각의 기능을 개발하기 위해서 일정을 산출해야 한다.  결국 프로젝트 전체 일정이라는 것은 각각의 개발 기능의 일정의 합이기 때문에 기능의 일정을 산출하는 것이 중요하다. 그런데 각 기능의 개발 기능을 알 수 있는 가장 좋은 방법은 과거 진행한 유사 프로젝트의 투입 공수를 살펴 보는 것이다. 하지만 우리나라 현실 상 프로젝트 과거 이력을 충실히 갖춘 회사는 드물다고 생각한다. 물론 PSP(Personal Software Process) 수준을 바라는 것은 아니지만, 적어도 해당 프로젝트에 투입되 시간들은 기록해 두어야지만, 다음 프로젝트에서 그 데이터를 활용해서 새로 시작하는 프로젝트가 얼마의 기간에 끝날 수 있을지 알 수 있다. 만일 이 데이터가 없는 경우 프로젝트 리더의 감으로  각 기능의 개발 기능을 산출할 수 밖에 없다.

개발자의 능력

아무리 상세 설계안이 잘 나오고, 기존 프로젝트를 통해서 어느 정도 개발 기간이 투입될지를 예상해도, 개발자의 실력이 받쳐 줄지 못한다면 개발 계획은 아무런 의미가 없다. 따라서 유사 프로젝트를 통해서 가늠한 프로젝트 일정은 표준으로써 역할을 하는 것이고, 최종적인 개발 일정은 개발자의 능력에 따라서 결정된다. 개발자의 레벨을 가장 손쉽게 평가할 수 있는 것은 개발경력이라고 생각한다. 물론 개발 경력을 토대로 개발자의 정확한 능력을 판가름할 수는 없지만 개발 경력은 어느 정도 정량적인 지표를 제공한다. 그래도 이것은 평균에 관한 이야기다. 현실은 다양한 산포가 존재하고 당신 팀에 배치될 개발자의 수준은 천차만별이다. 따라서 나는 개발 계획을 작성할 때, 개발자가 직접 작성하는 것이 바람직하다고 생각한다. XP의 방법론을 따라서 Story card가 나왔건, 일반적인 waterfall 방식의 프로세스를 따라서 HLD(High Level Design)가 나왔건, 반드시 일의 양을 산출할 수 있는 고객 요구나 설계가 나온 후 이것을 토대로 개발자에게 기능을 개발할 때 얼마의 시간이 걸릴지를 직접 작성하게 만드는 것이다.

개발계획은 팀장의 것? 팀원의 것?

물론 프로젝트의 일정은 정해져 있고, D-day를 지키고 싶지 않는 팀장은 없다. 그러나 이것은 바램일 뿐이다. 물론 프로젝트에는 여러가지 역학 관계가 존재하지만, 그래도 개발 품질과 일정에 가장 큰 영향을 미치는 것은 개발자의 역량이다. 따라서 개발자만이 자신이 어느정도의 효율성을 가지고 개발할 수 있을지 안다. 만일 당신 팀에 소속된 개발자가 당신과 여러 번의 프로젝트를 했다면, 어느 정도의 능력을 가지고 있는지 짐작할 수 있다. 그래도  주어진 기능에 대한 일정은 해당 개발자만이 산출할 수 있다. (특히 과거 유사 프로젝트의 데이터가 없는 경우는 개발자의 말에 의지할 수 밖에 없다.) 또 한가지 사실은 개발일정을 개발자에게  산출하게 함으로써 일정에 대한 확신과 더불어 Owernship을 부여할 수 있다. 따라서  팀장이 정한 프로젝트 일정에 끌려 가는 것이 아니라 스스로의 계획 아래 일이 진행된다는 Pride를 심어 줄 수 있기 때문에 프로젝트 일정을 팀원에게 돌려 주는 것이 여러모로 좋다. 현재 몸담고 있는 회사에서는 수 많은 프로젝트가 진행되었지만 과거 프로젝트 데이터를 현업에서 사용할 수 있도록 정리된 것이 거의 없다. 아쉽지만 상세 설계안과 이를 토대로 개발자가 일정을 작성하여 프로젝트 개발 일정을 산출하였다. 이 때 사용한 포맷은 다음과 같다.(프로젝트 내용 부분은 기업 비밀이기 때문에 삭제하고 공유하는 것을 이해하길 바란다.)

프로젝트 개발 일정표

그림에서 보는것과 같이 Excel을 이용하여 프로젝트 개발 일정을 작성하였다. 예전 프로젝트에서 MS Project로 일정을 산출하고 관리를 하기도 했으나, MS Project를 사용하면서 몇가지 불편한 점이 있어서 Excel로 프로젝트 일정 관리를 변경하였다. Excel을 사용한 이유는 조엘 온 소프트웨어(Joel On Software, 에이콘)에서 언급한 내용으로 대처한다.

마이크로소프트 프로젝트는 과업 사이에 존재하는 의존성을 밝히느라 뛰어다니는 과정에서 많은 시간을 소비해야 할 경우에만 우용합니다. 의존성은 과업 2개를 동시에 수행할 때, 특정 과업을 시작하기 전에 다른 과업이 반드시 끝나야 함을 의미합니다. 소프트웨어 부문에서는 과업 사이의 관계가 너무나 명백함으로, 이런 의존성을 공식적으로 추적하는 과정에 노력을 들일 필요가 없다고 생각합니다. … 사람들이 버튼 하나로 일정을 ‘다시 조율’할 수 있는 기능을 오용하는 것입니다. 필연적으로 이런 기능은 과업을 재배열하고 서로 다른 사람에게 각각의 임무를 다시 할당하게 만듭니다. 하지만 소프트웨어 개발자는  기본적으로 업무를 상호교환이 불가능하기 때문에, 소프트웨어에서 이런 작업은 의미가 없습니다. … 윈속 문제를 해결하는 데 GUI 프로그래머를 투입한다면, GUI 프로그래머는 작업을 멈추고 윈속 프로그래밍에 익숙해질 때까지 시간을 허비하게 됩니다.

개발 일정 작성 방법

이번 프로젝트는 총 3개의 모듈을 개발했으며 그 중 한 모듈에서 작성한 프로젝트 중간 단계의 개발 일정표다. 이 모듈의 개발 계획은 다음과 같이 작성하였다. 인터뷰를 통하여 고객의 개략적인 요구 분석을 작성했으며, 이를 토대로 GUI 설계를 마쳤다. GUI 설계를 마친 후 이를 두고 고객, 프로젝트 리더(나) 그리고 개발자 3명이 모듈의 세부 기능을 추출했다. 상세 개발 기능이 어느 정도 확정된 다음 개발 일정을 산출하였다. 개발자도 약 한 달동안 고객과 협의를 하면서 모듈의 상세적인 기능을 파악한 상태였기 때문에, 개발자에게 일정을 작성하도록 하였다. 단 개발 계획 작성 시 약간의 Guide line과 템플릿을(위의 엑셀 파일) 제공해 주었다. 우선 템플릿은 작업 id, 작업에 관한 간략한 설명, 시작일, 예상시간, 수정 예상 시간, 실제 투입 시간, 완료일, 완료 여부로 구성되어 있다. 하루는 8시간으로 계산해야 하나 고객 Site의 특성 상 하루를 9.5시간으로 계산하였다. 일정 계획 시 중요한 것은 반드시 하루 작업 시간을 9.5가 넘지 않도록 하는 것이다. 수정 예상 시간은 예상 시간 내 작업이 끝나지 않는 경우 변경된 시간을 적도록 하였다. 실제 투입 시간은 하나의 작업이 완료된 후 실제 투입한 시간을 적도록 하였으며, 이 때 완료일도 같이 입력하였다.

하나의 작업은 최소 1일에서 최대 3일이 넘지 않는 범위에서 일정을 산출하도록 했다. 이 부분이 일정 산정 시 매우 중요한 부분이다. 작업 시간을 시간 단위로 산출하게 되면 작업이 너무 산만해진다. 이에 반해 작업 기간을 3일 이상으로 잡으면 그 작업 내는 숨은 고객 요구 사항이나 예상치 못한 문제점이 도사리고 있기 때문에 일정이 지연된다. 따라서 몇 시간 단위로 작업이 산출되었다면 작은 작업을 모아서 하루치 분량으로 만든다. 이에 반해 4일 이상의 작업이라면 잘게 쪼개서 1~3일 분량의 일로 만들어야 한다. 이렇게 작성된 프로젝트 일정은 팀장과 개발자의 협의를 통해 프로젝트 일정에 문제점이 없는 최종 확인한 후 결정한다. 그런데 프로젝트 일정을 점검할 때 팀장의 역할이 중요하다. 일정을 산출할 때 여러가지 목적이 있지만 앞서 지적하였듯이, 개발자가 개발의 주체가 되도록 해야 한다. 즉, 개발자를 밑에서 일을 하는 사람이 아니라 동료로써 생각하고 있다는 신뢰를 주어야 한다. 따라서 애써 작성한 개발 일정이 프로젝트 일정에 치명적이라 하더라도 개인의 판단에 의해 작성한 것이기 때문에, 일정이 늦어지는 이유를 합리적으로 해결해야 한다. 즉, 일정이 합리적인 이유로 길어진 것이라면 여분의 Resource를 지원하거나, 만일 투입이 불가능한 경우 고객과의 협의를 통해서 고객 요구 사항을 조절해야 한다. 고객 요구 사항을 Nego하는 것은 팀장의 주요 역할이다. 이것은 다음 post에서 다루도록 하겠다.

예상 시간을 수정한 경우 작업 소요시간이 3일을 넘지 않는 경우에는 큰 문제가 없으나,  만일 수정 시간이 3일을 넘는 경우 대부분 새롭게 수정한 예상 시간도 어기게 된다. 즉, 3일 이상 작업이 지연된 경우 작업 내용이 명확히 정의되지 않았다는 뜻이다. 따라서 이 경우에는 단순히 시간만 수정해서는 안되고, 해당 작업을 다시 정의해서 작업을 나누어야 한다. 일정 산출 시 가장 조심할 점은 월화수목금금금의 황우석 시간표는 피해야 한다. 황우석 시간표를 만들게 되면 이미 그 프로젝트는 D-day를 맞출 수 없다고 선언하는 것과 동일하다. 사람은 기계가 아니다, 아무리 D-day를 준수해야 한다고 하루 12시간 씩 코딩하고 일주일의 하루도 쉬지 않고 일하면 결국 생산성이 떨어지지 때문에 예초에 하루씩 쉬고 8시간만 일했을 때와 결과는 마찬가지일 때가 많다. 또한 일정 계획은 아무리 완벽하게 세운다고 해도 여러가지 돌발 변수로 인해 지연될 수 밖에 없다. 따라서 만일의 사태에 대비하기 위해서 주말 시간은 반드시 Buffer로 비워 두어야 한다.

끝내면서…

물론 계획을 잘 세운다고 해도 성공적으로 일정을 준수하기란 쉽지 않다. 그렇다고 현실을 무시한 채 일정만 맞추라고 개발자에게 강요할 수도 없다. 개발 계획 수립을 개발자에게 돌려 준다는 것은 개발자를 부하 직원이 아니라 동료로써 인정한다는 선언이다. 따라서 팀장 어깨에만 놓여진 프로젝트의 책임감을 개발자와 공유할 수 있는 방안이기도 하다. 이것으로 오늘 post를 마치고 다음에는 팀장의 nego 능력에 대해서 살펴 보도록 하겠다.

작년 계획

작년에 못 이룬 수 많은 계획이 있지만, 그 중에서 일본어와 중국어를 중도에 그만둔 것이 너무나 아쉽다. 일본어는 대학 때 Animation과 영화 보는 재미에 빠져서 아름 아름 공부하다, 취업 때문에 중도에 포기했다. 다시 회사에 들어 와서 대학 때 감을 찾을 때 쯤 프로젝트가 바빠지는 바람에 또 포기했다. 그리고 작년에는 회사 생활이 한가해지면서 공부를 다시 시작했지만, 역시 프로젝트가 종반으로 접어들면서 일본어와 멀어졌다. 우리나라 민족은 3의 민족이다. 3번해서 안되는 것은 왠만하며 하지 말아야 한다. 그러나 7전8기라는 말도 있다는 사실을 잊어서는 안된다.

일본어 공부를 시작하면서 생긴 욕심에 중국어에도 도전했었다. (작년에는 무척 한가했나 보다.) 어렵사리 독학으로 초급 교재 하나를 떼기는 했지만, 역시 프로젝트가 바빠지면서 중국어도 손을 놓게 되었다. 아름 아름한 공부로 일본어 조금, 중국어 조금 알지만 가뭄에 콩 나듯이 일본사람이나 중국사람을 만날 때면 짝사랑하는 애인을 만난 것처럼 가슴이 콩닥콩닥 뛸 뿐 제대로된 말 한마디 못 하고 뒤돌아섰다. 그런데 돌아서고 나면 막상 몇 마디 생각날 때마다 공부를 그만 둔 것이 한스러웠다.

리얼딕 RD9000-MP

최근 들어서 외국어 공부에 활력을 불어 넣을 수 있는 방법을 고민하다 전자 사전을 하나 사서 틈나는 대로 단어라도 외워 보자는 생각이 들었다. 물론 연장 때문에 일 못한다는 말처럼, 사전 없다고 외국어 못한다는 변명이 궁색하기는 하지만… 그래도 새로운 시도를 해 보자는 생각에 전자 사전 구매를 결심하였다. 며칠을 고민하다가 SHARP 리얼딕 RD9000-MP를 샀다. 택배로 받은 리얼딕을 몇 시간 만져보고 느낀 소감 몇마디를 적어본다. 

Black과 Red의 조화

전체적인 외관은 Red와 Black을 사용해서 고급스러운 느낌을 준다. 이런 고급스러움을 주기 위해서 사용한 Cover의 Black panel은 일명 개기름이라고 불리는 유분이 잘 묻는다. 포장을 뜯고 조심스럽게 사용했지만, 잠깐 사용하는 동안 Black panel에 상당 양의 유분이 묻었다. 또한 LG 초코렛폰에서 문제점으로 많이 지적되었던 생활 기스 문제가 이 Black panel 부위에서도 생길거 같았다. Cover를 열 때는 약간 뻣뻣했으나 불편하다는 느낌보다 안정적이라는 느낌을 주었다. 반대로 닫을 때는 본체와 일정 각도가 되면 자동으로 닫히는데, 내리 찍는 느낌을 주었다. 본체와 Cover의 Hook를 체결하기 위해서 이렇게 설계하지 않았을까 생각이 들었지만 1%정도 부족한 느낌을 주었다. 외관에서 가장 아쉬운 점은 이어폰과 전원 연결부를 감싸는 보호 Cap이다. 보호 Cap은 본체와 분리되는 마개 구조로 되어 있기 때문에, 이어폰을 연결하기 위해서 Cap을 분리했을 때는 분실의 위험이 있었다. 물론 단순 포장용으로 Cap을 씌웠다면 문제가 없겠지만, 만일 보호용으로 Cap을 만들었다면 아쉬움이 남는 설계다. Cap 부분만 제외한다면 RD9000-MP의 외관은 만족스러웠다.

고급스러운 외관. 그러나, 지문과 생활 스크래치의 압박이 염려됨

리얼딕의 SHARP 로고

리얼딕의 Sㅅ라인

사용성, 약간의 아쉬움

5인치의 대형(?) LCD기 때문에 가독성이 좋다. 또한 저반사 LCD로 도서실과 같은 고도 조명 환경에서도 충분한 가독성을 제공해 줄거 같았다. 키패드는 qwerty 타입으로 키보드와 동일한 입력감을 제공해 주지만, space를 누르기 위해서는 왼쪽 shift와 오른쪽에 있는 pgdn 키를 조합해야 하기 때문에 약간 불편했다. 익숙지 않아서 종종 오타를 입력했지만 키 간격이 넓어서 수첩모드에서 장문의 메모를 작성할 때 유용하게 사용할 수 있을거 같았다. 입력과 관련해서 한가지 아쉬운 점은 키입력 시간이 느리다는 점이다. 물론 전자 사전이 분당 300타의 입력을 요구하지는 않지만, 느린 키입력 때문에 입력 오류가 종종 생겼다. 발음 기능을 살펴 보면 예전에 비해서 많이 좋아졌다고는 하지만 영단어 발음 시 연음 부분이 어색하였다. 본체에 내장된 스피커로 들을 때는 잘못 느꼈지만, 이어폰을 통해서 들을 때는 연음 부분이 사람의 발음과 차이가 많이 낫다. 특히 문장을 들을 때는 본체 스피커를 통해서 들어도 어색함이 느껴졌다. 여러가지 기능 중에서 가장 마음에 들었던 것은 단어 바로 가기였다. 본몬 검색 중 다른 언어로 단어를 찾고 싶은 때는 단어 선택 후 ‘입력’ 버튼을 누르면 연결된 여러 언어의 단어가 출력되고 번호를 누르면 해당 단어로 바로 연결되었다. 여러 언어를 동시에 학습할 때 상당히 유용한 기능이라고 생각된다.

5인치 LCD와 qwerty 키패드

참고서 샀다고 갑자기 학습 능력이 높아지는 것은 아니지만, 이를 계기로 꺼져가는 외국어 학습 의욕에 약간의 불이 붙는 것 같다. 이 불씨를 살려서 내년 이 때 쯤이면 4번째 실패를 맛보지 않기를 바란다.

이것으로 짧은  SHARP의 리얼딕 RD9000-MP의 사용기를 마친다.

당신이 생각하는 일하기 가장 좋은 직장은 어딘가요?

일하기 좋은 회사 두 군데

저는 이 질문을 받으면 서슴없이 Google이라고 답할 것입니다. 인터넷과 서적을 통해서 접한 사실을 근거로한 생각이기 때문에, Google이 일하기 좋은 직장이라는 제 생각은  편견일 수 있습니다. 아래에 Google에서의 직장 생활을 엿볼 수 있는 Post를 모아 두었습니다.(편견일 수도 있는 이런 생각을 하게된 이유를 대신합니다.)

• 배려 그리고 열정
• Google은 강아지들의 일(?)터
• 한주를 마감하는 바베규 파티
• Google의 신입사원, 인사드리겠습니다 

과일을 무척 좋아하기 때문에 신선한 과일과 시중에서 구하기도 힘든 주스를 마음껏 먹을 수 있다는 점, 피로할 때면 전신마사지도 공짜로 받을 수 있다니 부럽기도 하지만 한편으로 딴나라 이야기라는 생각이 드네요. 먹을 것 때문에 Google이 일하기 좋은 회사라고 생각하는 것은 너무나 무뇌아같은 생각이겠지만, 일단 맛난게 공짜라는 사실은 무척이나 부럽니다.(단순합니다…)

우리나라의 대표적인 IT기업인 NHN의 복리후생도 Google에 비해서 좀 떨어지지만, 괜찮은 편입니다.

NHN의 복리후생 제도

분당 NHN 본사를 딱 한번 방문한 경험이 있습니다. 사무실은 들어가지 못하고 회사 내 Cafe에서 이야기를 나누다고 돌아왔지만, 일단 IT 회사답게 분위기가 자유로운거 같더군요. (무척 짧은 시간이었지만) 편견일 수도 있겠지만 그렇게 느꼈습니다. NHN에서도 눈에 들어왔던 것은 원두 커피와 각종 음료가 무료로 제공된다는 사실입니다. 갑자기 공짜 음식이 제공되면 무조건 좋은 회사로 분류한다는 생각이 듭니다. 또한 출근 시간이 10시부터더군요. 물론 출근 시간이 늦은만큼 퇴근 시간도 늦어지기 때문에 조삼모사일 수 있습니다. 그러나 우리나라 기업 특성과 IT 직업 특성 상 출근을 아무리 일찍해도 퇴근은 밤 8~9시를 훌쩍 넘고는 하죠. 그렇기 때문에 차라리 출근시간이 늦은 편이 좋다고 생각합니다. 출근이 늦더라도 일찍 일하고 싶은 사람은 일하고, 정시 퇴근 시간인 7시에 집에 가면 되니까요…(최근에는 NHN의 인력이 대폭 늘어나고 있기 때문에, 초창기 친밀한 분위기를 규모의 경제에서 어떻게 실현하고 있을까 궁금하군요.)

두 회사만 예를 들었지만, MS, AutoDesk 소위 잘 나간다는 회사들을 살펴보면 한가지 공통점을 발견할 수 있습니다. 바로 개인의 사생활을 최대한 존중해 준다는 점입니다. 굴뚝 산업의 효율성만을 놓고 보는 사고로는 도저히 이해할 수 없지만, 지적인 작업이 중요한 요즘과 같은 시대에는 개인을 억압해서 빛의 속도로 변하는 세상을 쫓아갈 수 없습니다. 경쟁력을 유지하기 위해서 회사는 개인 존중이라는 가치 추구를 통해 창의성과 이익이라는 두가지 이점을 얻을 수 있습니다.

21세기 공통체를 꿈꾸며

법적인 근로 시간을 생각해보면, 우리나라 사람들은 적어도 8시간을 직장에서 보냅니다. 단순 계산을 해 보아도 인생의 3분의 1정도를 일을 하면서 보냅니다. 인생 전체로 보았을 때 적지않은 시간을 직장에서 보내기 때문에, 직장 생활은 당연히 즐거워야 합니다. 책 제목을 잊었지만 오랜 전에 읽었던 책에서는 직장의 정의를 “성인들이 즐겁게 시간을 보내기 위해서 만든 것”이라고 하더군요. 가족을 제외하고 직장은 현대인이 인간적 교류를 할 수 있는 유일한 곳입니다. 만일 획득형질이 존재한다면 현대인들이 일하기 즐거운 직장을 찾는 이유는  과거 농경 사회에서 동료와 교류하던 정서적 교감을 오늘날의 직장에서 찾기 위함입니다.

오늘 동료가 재미있는 기사를 하나를 알려 주었습니다.

당신 때문에 부하직원이 떠난다면… 

직장인이 회사를 옮기는 이유는 여러가지입니다만, 위의 기사가 주는 시사점은 직장인들이 회사에서 얻고자 하는 것은 단순한 “성공”과 “금전적인 만족”만은 아니라는 사실입니다. 기본적인 욕구가 만족된다면 인간은 정서적인 만족을 얻고자 합니다. 정서적 만족은 개인적 자족감과 다른 이와의 정서적 교류를 통한 사람의 정을 느끼는 것입니다.

대략 이상의 이야기로 일하기 좋은 직장은 다음과 같이 정의할 수 있습니다.

• 개인의 사생활을 최대한 존중해 준다.
• 동료와의 정서적 교감을 통해서, 인간의 정을 느끼게 해준다.

당신의 회사는 일하기 좋은 회사가요? 제가 제시한 두가지 기준을 놓고 본다면 ,우리나라에서 일하기 좋은 회사는 별로 없을거 같습니다. 너무나 단정적인가요? 그런데 친구 결혼식이나, 돌 잔치에 가면 오랫만에 만나는 친구들의 화제는 이직입니다. 말 그대로 객관적인 기준에서 본다면 정신나간 놈들이지만, 친구들이 이직을 꿈꾸는 이유는 그 놈의 情 때문인거 같습니다. 예전의 이와 비슷한 주제로 올린 post를 링크하면 오늘의 post를 끝냅니다.

人間

독서의 기쁨을 처음 알게된 것은 대학교 입학후다. 내가 다닌던 학교에는 중앙 도서관과 과학 도서관이 있었다. 중앙 도서관은 문과대 쪽에 위치했기 때문에 많은 장서가 있음에도 불구하고 지리적으로 가까운 과도관(과학 도서관)을 많이 이용하였다. 지금 생각해 보면 전공 서적보다도 무협지와 SF 소설이 더 많았지만 (만화방에서 찾아 볼 수 없던 무협지 전권이 2-3질씩 배치되어 있을 정도였다.) 독서의 기쁨을 알게해 준 소중한 공간이었다.

만일 책읽는 기쁨을 중고등학교 때 알았더라면, 내 인생의 모습은 지금과는 달랐을 것이다. 중고등학교 때 가장 싫었던 과목은 국사와 세계사였다. 독서를 좋아했다면 국사와 세계사를 이해하는데 도움이 커겠지만, 책읽기를 워낙에 싫어했기 때문에 국사와 세계사는 단순 암기 과목으로 분류하였다. 자연스럽게 국사, 세계사 수업 시간에는 다른 과목을 공부하거나 에너지 보충의 시간을 이용했기 때문에 더욱 더  멀어질 수 밖에 없었다.

그러나 이 과목들이 싫다고 해서 시험마저 망칠 수 없는 형편이었다. 평소에 국사와 세계사를 멀리하다 시험 전날 벼락치기를 할 수 밖에 없었다. 따라서 내가 두 과목의 시험 공부 방법으로 선택한 것은 교과서 외우기였다. 특이하게 중고등학교 때 국사, 세계사 선생님들이 시험 내는 방식은 교과서 전체를 알고 있어야지만 좋은 점수를 낼 수 있도록 문제를 출제하였다. 진짜 벼락치기였다. 국사나 세계사 시험 전날은 두 과목을 위해서 전력투구 하면서 교과서를 외웠다. 그리고 시험 때 쏟아내고 모든 것을 깨끗이 잊어 버렸다. 그런데 간혹 가다가 기말 시험 때 중간 고사 범위가 포함되는 경우가 있었다. 죽음이었다. 과목 포기와 교과서 외우기 사이에서 줄 타기하는 심정으로 시험 전날 밤을 보냈다. 따라서 두 과목을 마친 날이면 기말 시험을 마친 기분이 들곤 했다.

국사와 세계사는 내게는 트라우마와 같다. 그래서 역사 이야기에 관심을 가질려고 “로마인 이야기”나, “삼국지” 같이 모든 이들이 인정하는 책을 읽어보았지만, 흥미를 가질 수 없었다. 책장 한 곳에는 그동안 사모은 역사책이 많은 편이지만, 지적인 즐거움을 준 책을 찾기란 쉽지 않다.

몇달 전 우연잖게 이덕일氏의 “사도세자의 고백”(humanist 출판)을 읽게 되었다. 역사 이야기였기 때문에 그렇게 큰 기대를 하지 않고 읽기 시작했지만, 책을 덮는 순간까지 다음 장에 펼쳐진 이야기가 궁금해서 손에서 책을 놓을 수 없었다.  이 책을 높게 평가하는 이유는 명쾌한 문체와 더불어 흥미를 불러 일으키도록 이야기를 구성했다는 점이다. 그러면서도 단순히 흥미 위주로 사도세자의 죽음을 기술한 것이 아니라, 사도세자가 죽음에 이를 수 밖에 없는 당시의 정치적 역학관계, 사도세자와 영조와의 관계, 사도세자 죽음의 역사적 의의들을 쉽게 이해할 수 있도록 설명한 점이다. 이 책을 통해서 역사 트라우마가 치유되지는 않았지만, 역사책 읽기의 즐거움을 알게 되었다.