1. 급할 수록 돌아가라~ 거의 절대 명제라고 생각합니다.

사회에서 업무를 진행하는데는 어떤 한계점이 있습니다. 그게 직장동료이건, 자신이건, 협력업체건 퍼포먼스를 올리는데 한계점이라는 것이 분명 존재하지요. 한국 사회는 그 한계점을 인정하지 않는 분위기가 팽배한 것 같습니다.

한참 야자가 유행(?)일때 친구들은 아침 7시에 학교에 가서 저녁 10시까지 책상앞에 앉아 있다가 옵니다. 물론 점심 시간과 쉬는 시간을 제외 하더라도, 한가지 일에 묶여 있는 시간이 길다고 그들이 일에 집중 할 수 있을까?

제가 가장 이해가 안되는 것중 하나가 TV에서 상사가 부하직원을 질타 하면서

‘이거 내일까지 다시 해와!’

라고 하는 겁니다. 그 몇일간의 작업을 완전히 무시하면서 어떤 잘못 인지도 알려주지 않고, 그 긴 시간의 작업을 불과 다음날 이라는 한정된 시간내에 다시 해오라는 비 논리적인 이야기의 전형입니다. 그건 그냥 자기 비위를 마춰달라, 그럴 듯한 모양세를 가춰와라, 내용은 중요하지 않다. 라는 말 밖에 되지 않습니다.

그렇게 나온 결과물에는 ‘아이디어’, ‘성의’, ‘제대로’, ‘일하는 즐거움’란 것들이 빠져있습니다.

2. 우리의 문제점

‘대한민국은 사람이 자원인 나라’라고 외치면서 그 자원을 제대로 활용할 생각을 안하는 나라, 활용할 수 있는 시스템엔 관심조차 없는 나라. 인 것 같습니다.

저도 업무 강도가 심하여(대부분의 영세 자영업 하시는 분들이 그렇겠지만..), 평균 4-6시간(어..의외로..많이 자네..) 수면을 취하지만, 반드시 틈틈히 휴식을 취합니다. 음악을 듣던지, 영화를 보던지, 사람을 만나던지, 그리고 같이 일하는 분들에게도 늘 강조합니다. 힘들면 힘들다, 안되면 안된다고 먼저 말해달라. ‘사람이 일이란게 늘 뜻대로만 되지 않는 것이고, 그러므로 일정은 조율(배째라는게 아니라..)하라고 있는 것이다.’ 라고 말합니다. 그렇게 할 때에만이 일에 대해 깊이 생각 할 수 있고, 일에 대한 흥미, 즐거움 등을 계속 유지할 수 있는 것을 많이 경험해 보았습니다.

갑자기 와서는 밑도 끝도 없이 ‘이거 다음주까지 해와’ 라는 말을 들을때 얼마나 힘이 빠지십니까? 막무가내로 밀어붙이는 불도저식 업무진행? 그건 그 뒤를 그리고 그 사람들의 앞으로의 의욕,생활,업무에 대한 집중도를 담보잡힌채 당장의 성과만을 바라보는 방법입니다.

3. 큰일입니다만..

쉬엄쉬엄 일하지 않을 때에 대한 폐혜는 인터넷을 조금만 검색해봐도 엄청 쏟아지는데 이런 것들을 커버 할 시스템에 대해서는 구체적인 논의가 없는 것 같습니다. 이런 분위기를 바꿀만한 방법은 없을까요? 직장생활 잘하는 선배들을 보면 이런저런 요령들을 가르쳐 주지만, 그것이 근본적인 해결책은 아닌 것 같습니다. 아니란 걸 알면서도 어쩔 수 없이 그렇게 되어져가는 이 굴레를 벗어날 방법은 없을까요? 급할 수록 돌아가야 한다고 말로만 떠들지 말고 실천하게 하려면 어떻게 해야 할까요? 구글/MS 같은 회사가 좀 더 많아지려면 어떻게 해야 할까요? 어떻게 하면 사람들의 인식이 바뀔 수 있을까요? 어떻게 하면 난 좀 더 일을 잘 할 수 있을까요?

답은 이미 알고 있는데 무언가 무서워서 실천 못하는 건 아닐까요? 쉬지않고 일하려면 쉬엄쉬엄 일해야 해요. 조차 지키기가 힘든 건 왜 일까요?

글을 쓰거나 할 때는 늘 출처와 근거를 남겨야 하는 습관(or 시스템)이 되어야 하는데, 회사 업무나 학회의 연구활동 이외에는 이런 습관, 행동, 시스템이 전무한 것 같습니다.(사실 학회에서도 그런 습관이 잘 or 제대로 되어 있는지 모르겠다…)

모든 정보는 ‘사람’이란 메개체를 거치면서 어떤 방법으로든 왜곡되기 마련이고, 그 왜곡된 정보는 다시 왜곡된 정보를 퍼트리게 됩니다. 이 모든 일련의 과정들이 따지고 보면 ‘사람’의 문제인 듯 합니다.

시작한 화두는 정보의 책임이지만 고민을 거듭하다보니, 실상은 사람과 사람사이의 커뮤니케이션 방법의 문제인 듯 합니다. 인류가 사회와 문명이란걸 이루면서 살아온 긴 시간 동안의 고민이 오늘 날을 사는 이들에게 ‘정보의 책임’이란 저 포스팅으로 다시 묻고 있습니다.

각 시대와 문명에는 나름의 해결책과 문제점들이 있었을 터, 대충 생각해봐도 찾은 시대와 문명(메소포타미아,중국,로마,그리스등..)은 흥할 것이요, 그러지 못하면 쇄하는 것인데, 좀 더 일상에 적용해보면 삶을 살아가면서 고민하는 문제의 대다수가 저런 류에서 벗어나지 못하는 듯 합니다.

어딘가 문제가 생기셨습니까? 사람들 사이에 관계에 문제가 있어 기분이 썩 좋지 않으신가요? 하던 일들을 잠시 잠깐 멈추고 고민해보는 것도 좋을 듯 합니다. 어떻게든 스스로에 해결책과 문제점을 찾아야 할 부분들 인 것 같습니다.

사실 지금 제가 그 문제에 있어 좀 절박합니다.

저는 국내 점유율 1,2위의 메신져를 모두 사용하며 계정도 몇개씩 됩니다.(업무용..)

주 용도는 업무용 채팅(항상 로그를 남기는 편입니다. 저랑 대화하실 때 주의.) 및 잡담. 그리고 파일 전송 정도 되겠는데요.

메신져들의 탭들을 잘 살펴보면 우리가 모르는 다양한 기능들이 많이 있습니다.

네이트온을 일례로 들어보면 그 안에서 화상채팅, 원격제어, 파일방(이건 완전 공유용 서비스) 서비스들이 쉽게 사용가능하도록 배치되어 있습니다. MSN 메신져도 그 안에서 화상채팅, 게임같은 것들을 같이 할 수 있게 되어 있습니다.

예나 지금이나 대화의 상대가 어디에 주로 분포해 있느냐? 도 중요하지만, 같이 무엇을 할 것이냐? 도 중요해지고 있는 듯 합니다.

A: ‘너 그 파일 있어?’

B: ‘어 어디어디 들어와 나 거기 공유해놓았어’

A: ‘나 거기 ID없는데?’

B: ‘그냥 하나 만들어.’

같은 이야기들은 흔히 나누는 이야기입니다.(주로 파일방,원격제어 기능이 있는 네이트온 쪽 이야기겠죠) 사용할 줄 아는 사람은 이미 다 사용할 줄 아는 이야기들 입니다.

메신져를 좀 더 즐겁게 사용 할 수 있는 방법들 중 몇가지를 생각해 봤는데요.

원글의

보통의 블로그/카페보단, 미투데이/트위터 같은 마이크로 블로그 서비스와 싸이월드 같은 간단한 정보들을 남길 때에는 꽤 유용하지 않을까 생각됩니다. 이런 종류의 ‘기록’이 아니라, ‘알림’의 기능만으로는 기록이 가능한 대부분의 웹서비스에서도 접목 가능할 것 같은데… 단순히 어떤 특정한 서비스보다는, 훨씬 범용적으로 사용할 수 있도록 기반 기술이 갖춰진다면 좋을 것 같습니다.

의 내용의 역발상입니다. 대화 할때 자신의 블로그,카페,미투데이/트위터,  같은 곳의 기록이나 뉴스 사이트의 링크 쉽게 붙여 넣을 수 있게 된다면 어떨까요?

A: 야. 너 2008, 대한민국 메신저 이야기 란 글 어떻게 생각해?

B: (바로 클릭해보고) 좋네..야 난 그래도 ICQ써..

A: 야..나 안습이다.

B: 지못미..ㅠ_ㅠ

라고 말할때 모종의 연결고리가 있어서 쉽게 링크가 된다던지 하는 건 어떨까요? 현재 네이트에도 마케팅 용어에 바로 링크가 걸리는 것들을 발견 할 수 있는데요. 그런 것들의 연장선으로 개인간의 커뮤니케이션을 좀 더 즐겁게 해줄만한 기능이 아닐까 싶습니다.

사실 평소에 이런 저런 쉬운 퍼가기/링크(미투데이에 영향을 받은) 기능을 고민하다가 문득 떠올라서 트랙백으로 남겨둡니다.

p.s 한마디 하는데 본인포함 블로그에는 거품이 많다는거..
조낸 무식한 본인이 보기에도 열에 아홉은 설계와 쥐뿔 관계없는
상상의 나라 얘기, 개발의 일부 얘기, 아니면 무슨책 몇페이지 얘기;;
블로그 이미지 뻥튀기 마케팅이 참 대단하다고 해야할 지 뭐라 해야 할 지;;

그리고 툴, 코드, 프레임워크 등으로 운좋게 권력을 획득해서
잘 모르고, 확신없이 책과 여기저기서 주워들은 것으로도
설계에 대한 가이드가 종종 먹혀 들어가는 경우도 꽤 많은데..
줏어들은 설계로 개발자에게 완전 헛삽질시키는거 자주 봄.. 블로그에서도 자주 봄;;
똘똘한 고객에 걸려서 줏어들은거로 응대하려다가 논리부족에 피보거나,
신경질적 대응으로 압도하려다가 잘 안통해서 개피보는 경우도 보고;;  애도;;

아아..이거 완전 제 이야기입니다. 깊이 반성합니다. 실패한 이야기야 여기저기 수백개 올라와 있으니 검색엔진 한번만 돌리셔도..(아니 조금만 여기저기 신경써서 찾으셔도..) 나올 듯 하네요.

줏어들은 설계로 개발자 헛삽질 시킨 것도 해봤고…(몇번씩이나..ㅠ_ㅠ), 똘똘한 고객에 걸려서 줏어들은거로 응대하려다 피본것도 해봤습니다.(먼산..), 신경질적인 대응은 아직 안해봤습니다만.. 어째든 이런 현실을 경험하게 되는 이유가 뭘까요?(물론 제가 능력이 부족해서 그런 것 일수도 있습니다만..)

생각해보면 방법론을 선택하는 것, Process를 정리하는 업무 자체가 인정받지 못하는 Software 업체의 풍토(아 또 남탓하기 시작..)가 문제인 것 같습니다. 인정받지 못함으로 가치 없는 으로 보이고 자연스러 그런 것들에 집중하지 못하는 분위기를 만드는 것 같습니다.

먼저 관리자 분들의 문제. 관리자급이신 분들의 인식. Process, 방법론, 설계, 요구사항분석등등… 이런 것들이 왜 필요한지 전혀 인식을 못하고 계십니다. 그분들에게 필요한건 성과, 멋진 결과물, 실적 이런 것들이 필요하시죠. 그런 성과, 멋진 결과물, 실적같은 것들을 지속적으로 내기 위해선 잘 구성된 Process, 방법론 같은 것들이 필요하다고는 생각하시질 않습니다. 사실 이건 Software 업계 뿐 아니라 IT라는 것을 도입하려는 곳 모두의 문제가 아닐까 합니다. 아직 인식과 저변이 확대되어 있지 못하죠.

그리고 실제 업무에 종사하시는 분(개발자)들 마저 그런 필요에 대해 인지를 하지만 실제 누군가가 ‘이런 것들이 있다’라고 보여주면, ‘그런거 실제론 필요없어요’라는 반응을 보인다는 것입니다. 형상관리를 도입(해서 제대로 활용하면)하면 좀 더 제대로 소스코드를 관리할 수 있고, 백업도 덜 귀찮죠, 일한 티도 더 낼 수 있고..(노는 티도 더 나고..) 라고 해봐야 실제로 도입해서는 그냥 백업, 최신 버젼 공유 정도의 역활 밖에 못하는 때가 많습니다. 왜 그런걸까요?

ORM이다, Framework다 설계가 중요하다~ 떠들어봐야 그런 것들에 도전해보고 경험해 볼 용기와 열정 그리고 희생(그렇습니다. 희생입니다. 현실적인 표현이겠죠.)없이는 좀 더 멋진(?) 개발자의 일상, 즐거운 관리업무~ 같은건 현실로 다가 오지 않을겁니다.

결론적으로 하고 싶은 말은…정말 늘 듣던 그런 말들입니다. 넓게 보고, 실패를 두려워 하지말고 도전해보자! 입니다. 콜롬부스는 서쪽으로 가기만 했고(고생 무지 했지만..), 돈 키호테는 풍차를 향해 돌진 한 것 밖에 없지만 그 둘(응?)은 이름을 얻고 두고두고 회자되는 인물입니다. 용기있는 자가 미인을 얻습니다.

에 이어…조금 다른 관점..에서 문득 생각난 것들을 적어보려고 합니다. 유행처럼 스쳐지나갔던 XP도 떠오르고 요즘 읽고 있는 장자도 생각나고, 이전에 참 충격적으로 읽은 유목민이 본 세계사의 내용도 겹쳐지나갑니다.

지금 홍대 탐엔탐스에 앉아 있는데 옆자리에 앉은 남여(커플은 아닌듯)의 이야기도 귀에 스칩니다.(한마디로 제 정신이 아니란 이야기입니다.)

IT에 대해, 좀 더 정확히 말하면 컴퓨터 프로그래머, 혹은 그 유사 직종을 달고 일하는 그 분들 말입니다. 열악한 환경에서 밤샘을 밥먹듯이 하고, 하루종일 컴퓨터를 보면서 키보드를 두드리며 남들이 이해하지 못할 그 무언가를 만들어내며 희열에 찬 표정을 지어내는 여러분들… 그러다 보면 어느세 나이는 들어가고 체형은 ET처럼 되고 연애도 못해보고 여기서 내가 뭘 하고 있나 라는 생각을 하시는 분들.

우린 불평할 만한 것들이 많습니다. 말안 통하는 기획자, 말도 안되는 일정을 강요하는 PM, 잠깐 바꾸면 되요 라고 기껏 마춰둔 UI 뒤집는 디자이너, 야근도 벅찬데 아침일찍 출근해서 자리지키라는 사장님, 무조건 빨리 나와야 한다고 맨날와서 눈치주고 윽박지르는 마케터 등등등… 구글에서 검색하면 수십페이지 뜨는 그런 불평거리들 말고.. 조금 생각을 바꿔 이야기 해보았으면 좋겠습니다. 기왕에 컨설턴트란 직종도 달고 기분좋은 트랙백도 받고, 글도 여기까지 왔으니 여러분께 뭔가 제안해 보려고 합니다. 컨설턴트에게 제안이란게 늘 그럿듯 선택은 여러분의 몫입니다.

뭐 대단한 제안을 하나? 라고 생각하고 여기까지 부질없는 글 읽어주신 분들께 죄송하지만, 1분당 1000타 코딩할 수 있는 비법도, 프로그래밍 설계 스파르타 6주과정 같은 것도 아닙니다. 그저 조금 덜 피곤해지기 위한 몸부림(수 많은 다른 분들과 마찬가지로..)을 쳐 본 경험에서 몇가지 권고드리는 것 뿐입니다. 시간이 시간(새벽 4시 홍대는 정말 불야성을 방불케 하는군요…)이니 만큼 생각나는데로(좀 난잡하게) 몇가지 제안드리겠습니다.

1. Pair Programming을 하십시요. 작성하신 Logic이 잘 동작하지 않으십니까? 아무리 봐도 풀리지 않으십니까? 간단한 문법오류 일수도 있고, 치명적인 Logic상의 문제 일 수도 있습니다. 그런데 잘..안보이시죠?.. 부끄러워 마시고 동료분에게 같이 Code를 보자고 하십시요. 설사 여러분의 동료가 여러분보다 경력이 일천할 지라도 그렇게 해보시길 권합니다. 저는 Programming을 거의 처음 접하는 분과 서로 Code Review를 하다 제가 처음부터 잘 못 인식하고 생각했던 것들을 발견한 적이 자주 있습니다.

2. 기록을 하시고 그것을 남기십시요. 형상관리를 도입하셔도 좋고, 그냥 아이디어 스케치 수준에서 끄적거리던 것들도 좋습니다. 여러분이 작업한 것들은 모두 기록으로 남기는 습관을 가지시는 것이 좋습니다. 남들에게 나 이만큼 일했어! 하고 보여주기에도 용이하고, 어떻게 일했는가 스스로를 돌아보는데도 큰 도움이 됩니다. 사실 한번 짠 Code 다시보는 일 잘 안합니다.(맨날보는 건데 걸 왜 또 보나 하는 생각들죠!) 그런데 형상관리의 로그나 끄적거렸던 문서들은 한번 보게 됩니다. 그런 싸이클을 억지로라도 반복하다 보면 어느사이엔가 Code 작성에 대한 스스로의 생각이나 Logic을 짜는 요령등에 대해 더 생각하고 있는 스스로를 발견 하실 수 있을 겁니다.

3. 추산하십시요. 기획 회의나 프로젝트 의뢰를 받을 때나 버그 수정 지시를 받을 때나 머리속으로 대략적인 작업 범위를 정하시고 필요한 것들을 Check List화 해보시고(하시다 보면 이것도 Coding과 유사한 작업이라고 느끼실 겁니다..) 그런것들을 메모지에라도 끄적끄적 거려 봅니다. 필경 나중에 그 끄적 거린 메모가 큰 도움이 되실 겁니다. 그리고 함부로 일정이나 결과에 대해서 얼마쯤 걸리겠다라고 말하는 습관도 어느정도 줄이실 수 있으리라 생각됩니다.

4. 다같이 회의하십시요. 회의라고 해서 크게 자리 잡아놓고 관련자 전원 다 불러서 프로그램 구조에 대해서 일장연설을 하거나하는 그런 회의(다들 주무시죠..)말고, PM부터 가급적이면 같이 일하면서 부딛히게 될 모든 사람들과 같이 작업하게 될 부분들 그리고 만들어질 Software 전체에 대해서 틈틈히 이야기하고 토론하고 Fact들을 공유하십시요.(그런거 안하는 사람도 있냐구요?..있습니다..) 그리고 꼭 상대방의 이야기를 한번씩 들어주십시요. 일방적인 이야기를 할 때나 회의를 할 때 보다 상대방이 훨씬 더 이쪽의 말에 귀를 기울일 겁니다.

5. 영원한 것은 없습니다. 완벽한 기획서, 여러분이 짜놓은 완벽한 Logic, 변경되면 큰일 나는 ERD, 목숨걸고 지켜야 하는 일정. 그런건 현실속에 없습니다.(그 모든걸 강요하는 회사와 사장님 마저도 영원하지 않죠?) 사람은 실수를 하는 동물이고, 그런 사람들이 모여서 Software를 만들고 각 Process들을 진행하고 각자의 업무를 합니다. 모든것은 바뀔 수 있다 라는 것을 항상 염두에 두시고 개발 업무에 임하시면, 갑님의 말도 안되는 요구에 조금은 더 유연하게 반응 하실 수 있고, 기획자가 ‘죄송한데 이거 좀 바꿔야 될 것 같아요’라는 말이 조금 더 이해되실 수 있습니다.

몇가지 주저리주저리 이야기를 드렸지만, 잘하시는 분들은 이미 잘 하시고 계시고, 어떤 이유에서든 잘 안되시는 분들은 뭔가 잘 안되고 계십니다. 악순환의 고리는 지금 여기서 내가 하나라도 끊지 않으면 반복될 뿐입니다.

요즘 개발쪽 일하시는 분들과 이야기를 하다 보면 리펙토링이나 코드 컴플리트도 중요하지만, ‘IT인으로써 살아가기 - SI편’, 이런거라도 하나 있었으면 좋겠다 싶은 마음입니다.

자. 잘 생각해봅시다. 여러분을 힘들게 하는게 잘 풀리지 않는 Code나 귀찮은 문서화 작업인가요? 아니면 직장동료, 상사, 갑(혹은 을) 업체인가요? 전자라면 스스로 조금 더 노력하면 실마리가 보이겠지만, 후자의 경우는 어떻게 하시겠습니까? 잘 생각해보면 실 생활에서는 후자의 경우가 더 많을 것 이라고 생각합니다.(아니라구요? 그럼 좀 더 노력하셔야죠! ^^), 직업이 Programmer이다 보니 모든 문제를 Programmer의 입장에서 생각하고 해결하려는 성향이 이쪽 종사자 분들에게 있는 것 같습니다. Programmer이기 이전에 우린 ‘사람’인데 종종 망각하는 것 같습니다. Coder다 Programmer다 Architect다 하는 것들은 다른 분들께 큰 의미(그분들껜 우리가 그냥 Computer에 익숙한 날 도와주는 사람일 뿐입니다.)가 있는건 아니죠. 혹여나 스스로를 Code를 벹어내는 Machine이라고 생각하고 계신건 아니신지요?

이만 줄입니다. 편안한 밤 되십시요.