Talk about Software with hani

며칠 전에, 지구 온난화 때문에 북극곰이 멸종할 위기에 처했다는 뉴스를 봤습니다. 뉴스 화면에서 유빙 위에서 난감한? 표정을 짓는 북극곰을 보여줬는데, 참 처연하더군요. 효과적인 프레젠테이션 방법으로써, 가장 좋은 것은 말을 많이 하는 것보다 감정을 불러일으킬만 그림을 보여주는 것이라고 하죠. 그런 논리로써, 유빙 위에 애처로운 북극곰은 참으로 강렬한 임.팩.토를 선사했습니다.

야! 저 북극곰 신세가 내 신세가 되는 거 아니야? 당장 온실 가스를 줄여야 해!

But

실제로 지구온난화 때문에 북극곰이 멸종 위기에 처하지 않았다면 어떨까요? 어떤 사안을 정치적 아젠다로 만드는 가장 좋은 방법은, ‘정치 구호화’하는 것입니다. 복잡한 논리적인 설명 없이, 강렬한 이미지나 선동으로써 ‘정치 구호’를 만들고, 그게 우리사회에서 논의할 아젠다로 바뀌는 것만큼 효과적인 정치방법은 없죠. 다만, 효과적인 만큼 폐해가 많습니다. 구호가 나오는 논리과정을 생략하기 때문에, 합리적인 토론을 하기 어렵습니다.

아울러, ‘정치 구호화’가 되면 이미 더 이상 사고의 영역이 아닌, 행동의 영역이 되기 때문에… 이런 선동형태의 정치는 좌우, 양극단으로 흐르는 경향이 있습니다. 바로, 지구온난화 문제가 그런 종류의 문제라고 비외른 롬보르씨가 ‘쿨 잇‘에서 주장합니다.

다시 북극곰 문제로 돌아와서, 지구온난화 때문에 생존 위기에 닥친 북극곰도 존재하는 것도 사실의 일부이지만, 다른 측면에서 바라봤을 때 지구온난화 때문에 대다수의 북극곰은 영향을 받지 않는다는 것도 사실이라고 합니다. 물론 지구온난화가 문제가 아니라는 뜻은 아니죠. 이성이 사라진 채, 지구온난화라는 과장된 공포로써 효과적이지도 않은 지구온난화 대책을 세우려는 데 문제가 있다고 지적합니다. 즉, 저자가 책에서 주장하는 바는 다음과 같습니다.

1. “지구 온난화는 현실이며 인간이 일으켰다.” 현세기 끝 무렵에는 결국 인간과 환경에 심각한 영향을 끼칠 것이다.

2. “지구 온난화가 가져올 격렬하고, 불길하며, 코앞에 닥친 결과에 대한 주장은 심하게 과장된 경우가 많다.” 그런 과장으로부터 좋은 정책이 나올 것 같지는 않다.

3. 비록 좋은 의도일지라도 터무니없이 노력하기보다는 “지구 온난화에 대해 더 단순하고 더 현명하며 더 효율적인 해결책을 마련해야 한다.” 현재 실행하는 대규모의 값비싼 이산화탄소 감축 정책은 먼 미래까지도 파급 효과가 적거나 미미한 수준에 그칠 것이다.

4. “지구 온난화보다 훨씬 더 중요한 문제가 많다.” 균형 감각을 되찾아야 한다. 세계에는 기아, 가난, 질병 같은 심각한 문제가 무척 많다. 수조 달러를 퍼부어 과감한 기후 정책을 추진하느니 다른 문제를 해결하는 편이 더 많은 사람을 더 저렴한 비용으로 도울 수 있을뿐더라 성공할 가능성도 훨씬 높다.

from 쿨 잇

아마존에서 읽은 서평 가운데 이런 게 있네요. “이산화탄소를 줄이자고 주장하는 사람은 1907년에 유방암 걸린 사람을 도우려는 사람과 비슷하다.” 과연 지구온난화 문제가 1907년에 유방암을 대하는 자세인지 아닌지, 이 책을 읽으실 분들은 책 제목처럼 ‘회의적인’ 자세로 의문을 품으시면 읽으시길요.

* 덧 : 1퍼센트의 승부였습니다. 도민이기 때문에 무구유언이지만요. 계급의식이 있는 사람, 자기 이익에 충실한 사람이 세상을 바꾸는 듯합니다.

프로젝트 완료일을 달력 위에 동그라미 친 날짜로 생각하는 경향이 있습니다. 물론 작업명세서(SOW, statement of work)나 계약서에 적어 놓은 완료일, 아니면 MS Project에서 산출되는 작업완료일도 특정한 날짜이니. 그다지 틀린 이야기도 아닙니다. 지금 맡고 있는 프로젝트에서도 특정 날짜를 프로젝트 완료일로 정해 놓았고, 팀원도, 고객도, 기타 관련자도 모두 그렇게 생각합니다. 물론, PM인 저도 그날 프로젝트가 끝나야 한다고 믿습니다.*

제가 사랑하는존경하는 톰과 티모시 아저씨가 지은 ‘리스크 관리‘에서, 프로젝트 완료일을 일종의 확률 분포로 봐야한다고 말씀하십니다. 즉, ‘프로젝트 완료일을 산출하는 작업’은 ‘달력 위에 동그라미 그리는 미술숙제’가 아니라 ‘100번 동전을 던져서 앞면이 몇 번 나올지 맞추는 산수문제’라는 것이죠. 톰과 티모시 아저씨의 말씀에 따라서 프로젝트 완료일을 그려보면 다음과 같습니다.

흔히 프로젝트 완료일이라고 하는 부르는 날짜는, 프로젝트를 끝낼 확률이 다소 높은 날짜일 따름이죠.# ‘계약서에 적힌 날짜에 끝날 확률’은 프로젝트 시작일부터 계약서 날짜까지 확률분포 곡선을 적분한 값입니다. 위의 그림에서 ‘계약서에 적힌 날짜’에 끝날 확률은 대략 70퍼센트가 넘는 듯합니다. 반대로 프로젝트 완료일을 지키지 못할 확률이 무려 30퍼센트나 된다는 뜻입니다.

오  마이 갓.

30퍼센트라는 숫자는 고객이나 프로젝트 관리 조직(PMO, Project Management Office)에서 아는 날이면 난리가 날 정도로 높은 숫자입니다. 하하하. 물론 이 확률이 얼마나 맞냐고 물으신다면, 먼산만 쳐다볼 따름입니다. 즉, 확률분포 곡선이 얼마나 정확한지를 먼저 증명해야 하는데, 그게 쉬운 일도 아니고 그마저도 논란이 많은 일이기 때문이죠.

제가 여기서 말하고 싶은 것은, 이런 확률이 맞냐 그르냐의 문제가 아닙니다. 즉, 확률분포 곡선이 어떻게 되든지, 프로젝트 완료일을 지키지 못할 확률… 즉, 위험(risk)은 어떤 프로젝트에서든 존재한다는 사실입니다. 결국, 톰과 티모시 아저씨가 ‘리스크 관리’라는 책에서 하는 이야기로 돌아가야 합니다. 즉, 프로젝트 완료라는 것만 놓고 봐도 완료를 지키지 못할 위험이 존재하기 때문에, 프로젝트 관리를 제대로 하기 위해서, 프로젝트 관리자는 항상 위험관리를 해야 합니다.

자! 비현실적인재미있는 책 이야기는 옆으로 치워두고, 현실로 돌아와보죠. 현실에 있는 수많은 프로젝트(제가 몸 담은 프로젝트를 포함해서)에서 얼마나 위험을 잘 관리할까요? 제가 프로젝트마다 다니면서 현실을 보지 못했으니까, 다 알 수 없지만. 지난 제 경험을 돌이켜보면 위험을 관리하기보다 위험 때문에 발생한 사건을 처리하기 바뻤죠.

뭐, 사랑하는 애인의 과거도 중요하지 않은 마당에, 지난 프로젝트의 과오를 온 세상에 알려서 뭣 하겠습니까? 다만, 우리에게 필요한 것은 과거의 실수를 되풀이 하지 않는 배움과 실천의 자세죠. 그렇기 때문에, 지금부터라도 위험관리를 제대로 하면 됩니다.

하지만, 위험관리를 제대로 할려면 여러가지 문제에 부딪힙니다. 프로젝트 안에서 처리하지 못하는 위험도 있고, 예산 때문에 완화계획을 실행하지 못하는 경우도 있습니다. 그러니 위험을 식별하고, 분석하고, 완화계획을 세운다고. 그냥 한나절 문서작업으로 끝날 때가 많습니다. 그렇다고 좌절해서, 스나미처럼 몰려오는 위험을 목도할 수만은 없습니다.

그래서, 산전수전 공중전까지 치룬 베테랑 관리자가 아닌, 초보 관리자분께 도움이 될만한 팁 하나 알려 드립니다. 위험 관리가 어렵다고 느끼신다면 위험, 이슈, 문제로 분리해서 관리해 보세요. 사실, 위험, 이슈, 문제는 모두 위험이라고 말할 수 있습니다. 다만 세 가지에서 차이는 발생확률에 있습니다.

위험 : 발생하지 않은 것으로 프로젝트에 영향을 줄 수 있는 것입니다. 예를 들어, 2달 후 팀에 합류할 개발자가 정해지지 않았다면, 개발자의 역량에 따라서 개발 속도가 달라져 개발이 지연될 수 있는 게 위험입니다.

이슈 : 팀원이 사용하던 노트북이 고장나서, 당장 조치를 취하지 않으면 개발을 못하는 상황이 바로 이슈입니다. 즉, 위험이 현실화되서 악영향을 줄 수 있는 상황입니다.

문제 : 역량이 떨어진 개발자가 투입되고, 고장난 노트북이 빨리 수리되지 않아 팀원이 며칠째 노는 상황입니다. 위험이 현실화되고, 이슈가 실제로 악영향을 주는 상황입니다.

위험은 아직 발생하지 않은 것이고, 이슈는 위험이 발생해서 당장 조치를 취하지 않으면 프로젝트에 문제를 일으키는 것입니다. 문제는 말 그대로 일정이 지연되고 품질이 떨어지고 비용을 초과한 상태죠. PM은 세 가지 것을 모두 관리해야 합니다. 특히, 위험관리를 잘 한다면, 이슈나 문제를 고민하지 않아도 되죠. 하지만, 현실이란 위험관리를 잘해도 예상하지 못한 문제가 발생하기 마련입니다.

초보관리자가 위험을 식별해서 완화계획을 세우는 게 쉽지 않습니다. 위험이라는 게 확률 문제이기 때문에, 경험이 없다면 예측을 잘 하지 못하기 때문이죠. 따라서 초보관리자에게 위험관리란 약간 피상적으로 느껴질 수 있습니다. 이런 경우, 이슈관리를 중심으로 문제를 해결하는 방법을 체득한 뒤, 어떤 위험이 존재하는지 경험을 쌓은 다음 위험관리로 넘어가는 게 좋습니다.@

자! 그렇다면 이슈관리는 어떻게 하는 게 좋을까요? 팀원과 효과적인 의사소통을 해서, 팀원이 어떤 이슈를 가지고 있는지 파악해야 합니다. 의사소통을 잘 하는 형식적인 방법으로써, 스탠드업 미팅이 좋습니다. 짧은 시간이지만 공적인 회의 자리에서, 자신에게 있는 이슈나 팀에 있는 이슈를 말할 수 있기 때문이죠. 아울러 팀원과 커피를 마시면서, 팀원이 고민하고 있는 부분도 들어보는 것도 좋은 방법이죠. 물론 고민이 모두 이슈는 아니지만. 비공식적인 대화채널도 이슈를 파악하는 좋은 수단입니다.

초보 팀장님, 여러분께 조금이나마 도움 되셨으면 좋겠습니다.

* 믿는 것과 현실은 다릅니다. 하하하. 물론, 그날 끝내야 모든 이가 편합니다.

# 물론 계약, 즉 돈이라는 문제가 걸려 있지만, 이것은 논외로 하겠습니다.

@ 위험관리를 완전히 무시해도 된다는 뜻은 아닙니다.

요즘은 휴가기간이지만, 개인적으로 휴가를 반납한 채 열혈 ‘번역 모드’에 빠져 있습니다. 그런 의미로 오늘은 그냥 번역하다가 생각난 몇 가지 팁을 정리해 봤습니다. 이 정도만 지켜도 읽기 쉬운 번역서가 되지 않을까 싶네요.

1. 수동형은 능동형으로

영어는 객체 중심, 국어는 동사 중심의 언어이기 때문에, 영어에서 무생물도 주어가 됩니다. 즉, “The window is broken by a stone.”이 무생물이 주어인 문장이죠. 물론 우리말에도 수동형이 존재하지만, 구지굳이 능동형으로 옮겨도 되는 문장을 ‘원문 충실이라는 함정’에 빠져, 의미를 번역하는 게 아니라 문장형식을 옮길 때가 많습니다.

“The design is implemented by a developer”라는 수동형 문장이 있습니다. 이걸 어떻게 번역하는 게 좋을까요? 어떤 분은 ‘원문에 충실해야 한다’는 논리로 “설계는 개발자에 의해 구현되었다.”로 옮겨야 한다고 말씀하시기도 하죠. 하지만 이렇게 번역해 놓으면, 읽는 사람 입장에서 상당히 거북스러운 문장입니다. 우리말은 수동형보다 능동형을 선호하기 때문에, 이 문장은 “개발자가 설계를 구현했다.”로 옮기는 게 좋습니다.

“원저자의 의도는 ‘The design’을 강조하기 위해서, 수동형을 쓴 게 아니냐”하는 반문을 하시는 분도 있을 듯합니다. 네, 맞습니다. 충분히 그럴 수 있죠. 원저자의 의도를 살리면서도 자연스러운 능동형 우리말로 옮기는 방법이 있습니다. 바로 우리말의 최대 필살기인 ‘은/는’ 조사 신공을 사용하면 됩니다. 그렇다면 원저자의 의도를 살리기 위해 이렇게 옮기는 것은 어떨까요?

설계는 개발자가 구현했다.

옮긴 문장은 능동형을 사용했기 때문에 자연스러운 우리말 분위기가 풍기고, 결정적으로 ‘설계’가 앞으로 나왔기 때문에 원저자의 의도를 충분히 살렸습니다. ‘은/는’과 ‘이/가’를 적절히 사용하면 왠만한 수동형 문장도 능동형 문장으로 옮길 수 있습니다.

이런, 몇 가지 팁을 더 준비했는데 쓰기가 귀찮네요. 죄송해서… 그럼 다음 편을 기약하며.

불만제로라는 프로그램에서 음식물처리기에 대한 소비자 불만을 다루었습니다. 집에서도 루펜이라는 음식물처리기를 사용했지만, 얼마 전부터 사용하지 않습니다(불만제로 프로그램을 보기 전부터죠). 불만제로에서 언급한 냄새가 나고, 잘 마르지 않는다는 등의 문제가 저희 집에서도 반복되었기 때문입니다.

시중에 나온 음식물처리기에는 다양한 문제가 있기는 하지만, 소비자의 불만이 높은 이유 가운데 하나는… 과장광고로 소비자의 기대치를 너무 높여 놓았기 때문입니다. 즉, 성능이 그렇게 나쁘지는 않은 편인데, 그렇다고 구매하기 전에 품었던 기대만큼으로 성능이 좋지 않으니까 문제인 듯합니다.

하지만 음식물처리기라는 제품 컨셉은 훌륭합니다. 맞벌이가 보편화되고, 음식물 처리에 고역을 겪어 본 남편들은 음식물처리기의 구매를 고려하기 마련입니다(주위에서 음식물처리기가 어떻냐고 물어보신 분들은 대부분 남자이기 때문이죠. 하긴 주위에 남자 직원이 대부분이네요).

개인적으로 음식물 처리기에 불만은 냄새가 많이 나고, 가열방식으로 건조를 하기 때문에, 건조된 음식물이 눌어붙어 건조가 끝나서 버릴 때 쉽지 않다는 것입니다. 이런 단점을 해결할 수 있다면, 저처럼 기존 음식물처리기에 불만을 가진 사람들의 구매를 자극하지 않을까요?

그래서 좋은 아이디어가 없을까 잠깐 고민해 봤습니다. 냄새가 나거나 음식물 쓰레기가 눌어붙는 것은, 가열하기 때문이죠. 즉, 가열하는 이유는 음식물에 있는 수분을 증발시키기 위해서죠. 그런데, 음식물에 있는 수분을 제거하기 위해서 꼭 가열을 해야 할까요? 반대로 온도를 낮춰서 수분을 제거하는 방법은 없을까요? 온도가 낮다면 음식물이 부패하지 않기 때문에, 냄새도 나지 않겠죠. 이런 생각을 하니까… 동결건조가 생각나더군요.

동결건조는 수분을 함유한 재료를 얼리면서 동시에 압력을 낮추면, 얼음이 된 물이 액체상태를 거치지 않고 증발하는 현상을 이용해서 수분을 제거하는 방법입니다. 즉, 기존 음식물 처리기는 오븐에다 수분을 배출하는 환풍기가 달린 제품이라면, 제가 말하는 음식물 처리기는 냉장고에 진공펌프가 달린 제품이겠죠.

이 제품이 상품화되려면, ‘소형 동결건조기를 소비자가 구매할만한 가격에 만들 수 있느냐’와 전기료가 관건입니다. 우선 전기료는 기존 음식처리기를 한달 동안 가동했을 때, 성능 좋은 냉장고를 틀어놓은 정도라니… 이 정도 수준으로 전기료가 나온다면 경쟁력이 있을 듯합니다. 마지막으로 가격이 문제인데, 이 분야는 제가 전문이 아니어서 건너뛰어야 겠습니다(아이디어니까요).

동결건조까지 생각하니 이런 생각이 들었습니다. 굳이 음식물 찌꺼기를 건조해야 하나요? 한꺼번에 버릴 수 있도록 음식물 찌꺼기를 상하지 않고 냄새가 나지 않게 보관하면 되지 않을까요? 그렇다면 음식물 처리기가 아니라 음식물 찌꺼기 보관기는 어떨까요? 즉, 소형 냉장고를 디자인을 잘 해서 음식물 찌꺼기 보관기라는 새로운 제품으로 만드는 것입니다. 하하하. 약간 사기성 냄새가 나지만, 음식물 처리의 핵심은 음식물 찌꺼기를 장기간 보관했다가 한꺼번에 처리하자는 것을 상기해 볼 때, 그렇게 비현실적이지 않은 듯합니다.

이런 것들은 기술에 의존한 해결책이고, 저희 집에서 사람과 프로세스에 의존한 해결책으로 음식물 찌꺼기를 처리합니다. 즉, 아침에 가장 먼저 출근하는 가족 구성원이 전날에 나온 음식물 쓰레기를 처리하는 게 일종의 ‘저희 집 음식물 처리 프로세스’인 셈입니다.

문제는 1개이지만, 답은 N개라는…

from http://gloriagraphics.blogspot.com