좋은 디자이너, 나쁜 프로젝트매니저, 이상한 개발자 from 수열 전

 

 

서로서로를 이해하고 있어야 커뮤니케이션이 되는 듯!

저작자 표시
신고

WRITTEN BY
빵군
Web Programmer HOONS닷넷(http://www.hoons.kr) 2011 ASP.NET 시삽 http://about.me/y2kpooh

받은 트랙백이 없고 , 댓글  2개가 달렸습니다.
  1. 잘 보고 갑니다 ^^;
  2. 먼가 딱딱 맞아떨어지는듯..ㅎㅎ 잘보고가요!!
secret

Firefox 4 버전

깨작깨작 2011.03.22 16:50


Firefox 4버전 나와서 설치.
UI가 기존 버전과는 전혀 다른느낌.
속도는 IE9와 비교해서 어느게 빠른지는 아직 모르겠음.

다운로드 : http://www.mozilla.or.kr/ko/firefox/beta/
정식버전 : http://download.mozilla.org/?product=firefox-4.0&os=win&lang=ko


부가기능 : https://addons.mozilla.org/ko/firefox/?browse=featured
저작자 표시
신고

WRITTEN BY
빵군
Web Programmer HOONS닷넷(http://www.hoons.kr) 2011 ASP.NET 시삽 http://about.me/y2kpooh

받은 트랙백이 없고 , 댓글이 없습니다.
secret

ADOBE REFRESH

깨작깨작 2011.03.10 22:54

ADOBE REFRESH (Adobe MAX in Korea) 세미나가 3월 7일 개최되었다고 한다.

직접 세미나를 참석하지 못해 관련기사와 블로그 후기를 찾아봤다.

역시 ADOBE도 많은 기술을 선보였다.

특히 Apple iOS에서 플래시 플레이어의 콘텐츠는 지원이 안된다고 알고 있었으나 Air는 지원이 된다고 한다.

왜 몰랐었는지 원... 

ADOBE 에반젤리스트는 이렇게 말했다.

"HTML5에 대한 어도비의 지원은 계속 확대할 것이다. 하지만 HTML5가 제공하지 못하는 기능이 있기 때문에 플래시는 이 같은 부분을 계속 확장하는데 주력할 것이다."

HTML5의 웹 표준을 지원한다면서도... HTML5가 지원 못하는 기능을 확장한단다... 그 기능이 무엇인지? 훗!

또 한 관계자(?) 갤반 매니저는 "이젠 액션스크립트를 잘 몰라도 어도비 플래시를 누구나 싑게 만들 수 있다"면서 자기 엄마도 Flash 콘텐츠를 만들 수 있다고 비유했다.

플래시 빌더를 이용하여 디자이너가 디자인만 하면 필요한 스크립트 코드가 자동적으로 생성이 된다는 것이다. 한계는 있겠지? 그지? 개발자 먹고 살아야 되니까 ㅋㅋ

또한 ADOBE는 "스마트폰, 태블릿PC, 스마트TV 등 다양한 디바이스에 맞는 콘텐츠 개발을 위한 플랫폼으로는 플래시가 가장 적당하다."라고 밝혔다. 플래시로 개발해 놓으면 특별한 변경 없이 여러 플랫폼에서 이용할 수 있다는 것이다.
얼마전 웹앱컨퍼런스 생각이 난다... 웹 표준이 아닌 Flash, SilverLight는 한계를 지닐 수 밖에 없다.
그래서 HTML5가 대세다라고...

하지만 ADOBE는 그렇지 않다고 말하고 있다. ADOBE 런 타임(AIR) 덕분이라고는 하는데...
윈도우, 리눅스, 맥, 안드로이드, iOS 등에서 모두 구동이 된다고 한다.

역시나 HTML5와 마찬가지로 기존에는 다양한 플랫폼을 위하여 많은 기술을 습득해야 했으나
AIR기반으로 앱을 개발하면 플랫폼과 디바이스를 해결할 수 있다고 얘기하는군...

그리고 ADOBE는 크리에이티브 스위트 제품을 통해 종이 잡지와 웹용 콘텐츠를 손쉽게 변환, 배포할 수 있는 도구를 제공해왔으며... 한번 제작된 콘텐츠를 모바일용 앱으로 손쉽게 변환하고 배포할 수 있는 기능을 제공한다고 한다.

또한 ADOBE FLASH CS5는 아이폰OS 변환기능을 새롭게 선보였으며 몇번의 클릭으로 아이폰, 아이패트둉 네이티브 앱을 변환할 수 있다고 한다. 어떨지 궁금하군요..
또한 CS5에서는 FLA를 image+js+jquery+html로 컨버팅되는 툴이 포함될거라고 한다. 이건 정말.. 대박이다!

그리고 기존 웹사이트 제작도구였던 드림위버의 기능도 강화되었다.
스마트폰, 테블릿용 모바일 화면을 손쉽게 구현할 수 있는 도구로 확장되고 있으며 CS5는 HTML5, CSS3 태그를 모두 지원, 자동완성 기능도 제공한다고 한다.

결국 ADOBE는 HTML5를 팔로우 하는 느낌.

신고

'깨작깨작' 카테고리의 다른 글

Firefox 4 버전  (0) 2011.03.22
ADOBE REFRESH  (0) 2011.03.10
MIX11 행사 등록 시작이 시작되었습니다.  (0) 2011.02.23
WebApps FUTURECON 2011 서울  (0) 2011.02.14

WRITTEN BY
빵군
Web Programmer HOONS닷넷(http://www.hoons.kr) 2011 ASP.NET 시삽 http://about.me/y2kpooh

받은 트랙백이 없고 , 댓글이 없습니다.
secret

원문 : http://msdnpopcon.com/242



마이크로소프트에서는 매해 다양한 행사들이 열립니다. MIX, TechEd, WPC, PDC 등 각각 청중이 다르기 때문에 다루는 기술도 다른 여러 가지 행사가 있습니다.

웹 업계에 종사하는 분들을 위한 큰 행사인 MIX11의 행사 등록이 시작 되었습니다. 그 동안 국내 업체의 사례 소개 및 세션 발표 등이 있었는데요, 올해도 Korea의 기술력을 전세계에 알릴 수 있었으면 좋겠습니다.

행사는 4 12일부터 14일까지 라스베가스에서 열리며, 2 11일까지 등록을 하면 $500 할인 및 호텔 1박을 제공해 주고 있습니다. 또한, 10K로 코드를 만들어서 우승을 하면 무료로 MIX11에 참가할 수 있는 혜택도 예년처럼 주어지고 있습니다.

놀라운 소식들이 소개되는 키 노트는 실시간으로, 모든 세션들은 24시간 안에 업로드 될 예정이니 오프라인 참석을 못하시는 분들께서도 온라인으로 참석을 하실 수 있습니다. MIX11과 관련한 자세한 내용은 아래 공식 사이트를 참고 하세요.

http://live.visitmix.com/

신고

'깨작깨작' 카테고리의 다른 글

ADOBE REFRESH  (0) 2011.03.10
MIX11 행사 등록 시작이 시작되었습니다.  (0) 2011.02.23
WebApps FUTURECON 2011 서울  (0) 2011.02.14
10년째 같은 회사를 다니고 있습니다  (0) 2011.01.31

WRITTEN BY
빵군
Web Programmer HOONS닷넷(http://www.hoons.kr) 2011 ASP.NET 시삽 http://about.me/y2kpooh

받은 트랙백이 없고 , 댓글이 없습니다.
secret

신고

'깨작깨작' 카테고리의 다른 글

MIX11 행사 등록 시작이 시작되었습니다.  (0) 2011.02.23
WebApps FUTURECON 2011 서울  (0) 2011.02.14
10년째 같은 회사를 다니고 있습니다  (0) 2011.01.31
DevDays 2008  (0) 2008.12.02

WRITTEN BY
빵군
Web Programmer HOONS닷넷(http://www.hoons.kr) 2011 ASP.NET 시삽 http://about.me/y2kpooh

받은 트랙백이 없고 , 댓글이 없습니다.
secret
10년째 같은 회사를 다니고 있습니다
View more presentations from devCAT.

난 어떤가??
신고

'깨작깨작' 카테고리의 다른 글

WebApps FUTURECON 2011 서울  (0) 2011.02.14
10년째 같은 회사를 다니고 있습니다  (0) 2011.01.31
DevDays 2008  (0) 2008.12.02
정신병원에서 나온 디자인  (0) 2008.07.18

WRITTEN BY
빵군
Web Programmer HOONS닷넷(http://www.hoons.kr) 2011 ASP.NET 시삽 http://about.me/y2kpooh

받은 트랙백이 없고 , 댓글이 없습니다.
secret

DevDays 2008

깨작깨작 2008.12.02 19:12


그동안 오프라인으로 진행되던 DavDays가 온라인으로 진행된다.

사이트는 역시 실버라이트가 눈에 띄게 많이 사용되었다.

재미난 세션이 많으니 꼭 가서 확인필수!

http://www.microsoft.com/korea/devdays2008/

신고

WRITTEN BY
빵군
Web Programmer HOONS닷넷(http://www.hoons.kr) 2011 ASP.NET 시삽 http://about.me/y2kpooh

받은 트랙백이 없고 , 댓글이 없습니다.
secret

이글을 처음 이방은 MVP님 블로그에서 보고 데브피아에서 퍼왔습니다.
데브피아 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=69&MAEULNo=28&no=10227


회사에 들어온 웹디자이너가 엘런 쿠퍼가 쓴 "정신병원에서 나온 디자인"이란 책을 주더군요.. 뭐 디자인 책 중에서는 가장 좋은 책이라고 생각한다면 말이죠..


읽어 보니까.. 앞의 1/3은 너무나 복잡한 인터페이스를 씹는 내용이고 나머지 1/3은 그렇게 된 이유가 개발자들이 UI, 특히 사용자 인터페이스에 너무 많은 영향력을 행사하기 때문이고 나머지 1/3은 페르소나를 소개하면서 개발자들을 설득하기 위한 전략을 설명하더군요..


제가 알기로는 엘런 쿠퍼 또한 대단히 수준 높은 개발자로 알고 있습니다. 그래서 그런지 마치 거기서 적은 불특정 다수의 개발자에 대한 이야기가 제 이야기 같...더군요..--;


몇 군데 발췌해 보면요



프로그래머들은 소프트웨어를 배우는 데 엄청난 시간과 에너지를 바치기 때문에, 사용자들이 시간을 들여 그의 작품을 이해하려고 하지 않는다는 것은 그들에게 상상도 할 수 없는 일이다. 그는 회사 내에 문제가 있다는 사실은 기꺼이 받아들였지만, 회사 내에서 자신이 맡은 일에 문제가 있다고는 생각하려 하지 않았다.


-Part3 포크로 스프먹기, 테크노 정신병원




침입자가 접근해 오면 그들은 통제권이 무책임한 사람들에게 넘어가지 않도록 조심한다. 대부분 프로그래머들은 아주 책임감이 강한 사람들이며, 외부 컨설턴트나 마케팅 전문가, 경영자들을 종종 무책임하고 무능한 존재로 여기곤 한다.


 프로그래머들에게는 아주 예민한 거짓말 탐지 능력이 있어서, 마케팅 전문가나 관리자들이 '인터페이스를 개선하기 위해' 프로그램을 고치라고 주문했는데 결국 고쳐도 아무런 효과가 없었던 경우를 두어 번 겪고 나면 외부의 간섭에 단련이 돼버린다. 이러한 변경은 바람직한 것이든 아니든 상관없이, 프로그래머에게 추가적인 일을 하게 만든다. 또 변경을 할 때마다 프로그램에 불가피하게 상처와 땜질 자국들을 남기기 때문에 작성된 코드의 품질이 떨어지게 된다. 누군가 '확인' 버튼을 전부 대화상자의 오른쪽 위 구석에 두면 프로그램이 사용하기 쉬워질 것이라고 주장하면, 프로그래머는 자신의 경험과 지혜에 비추어 그것은 그저 시간 낭비라고, 정확하게 말하면 '자신에게' 시간 낭비일 뿐이라고 되뇌일 것이다. 이러한 두려움은 전혀 근거 없는 것이 아니다.


 이런 어이없는 일을 몇 번 겪고나면 프로그래머들은 외부에서 오는 모든 디자인 지시 사항을 그저 충고로만 여기기 시작한다. 잘못 설계된 벽들이 너무 많아 철거해야 하는 건축가와 같은 경험을 한 그들은, 이제 청사진을 아니꼬운 눈으로 바라보며 그것을 있는 그대로 받아들이지 않으리라 결심한다.


-Part3 포크로 스프먹기, 테크노 정신병원




대부분의 사람들이 적당한 수준으로 노력을 기울이는데 별 어려움을 겪지 않지만, 프로그래머들이 대부분의 사람들과 다른 점은 그들이 극도로 복잡성한 시스템을 정복하려는 의지와 능력을 지녔다는 점이다. 서로 인터랙션하는 수많은 요소들로 구성된 시스템을 이해하도록 관리하는 것은 프로그래머라는 직업에서 특히 만족스러운 부분이다.


-Part3 포크로 스프먹기, 호모 로지쿠스




이 책에서 개발자로서 최고의 공감 200%의 단락은...

소프트웨어 엔지니어들은 인테랙션 디자이너들과 목표를 공유한다. 즉, 그들도 제품이 성공적이기를 바란다. 단지 그 성공을 측정하기 위한 그들의 도구와 용어가 디자이너들의 것과는 전혀 다른 것 뿐이다.


 확실한 증거가 없는 상태라면, 프로그래머들은 반드시 자기 자신의 교육과 경험, 본능적인 감각에 의존하려고 할 것이다. 그의 본능은 그에게 가능한 많은 기능을 제공하라고 말한다. 그의 경험은 아마추어들이 일시적인 기분이나 어림짐작으로 민감하고 복잡하고 섬세한 개발 과정을 망치게 내버려 두지 말라고 말한다. 그가 받은 교육은 그에게 자기 자신을 참조하여 인터페이스를 구축하라고 말한다.


인터랙션 디자이너들은 이러한 동기들을 직접적으로 공격할 수 없다. 개발자들은 너무나 이성적이고 합리적인 사람들이라 절대 다른 사람의 의견을 따르기 위해 자신의 경험을 저버리지 않는다. 디자이너는 그들에게 문제를 바라보는 새로운 관점을 제시해야 하며, 그 관점이 효과적이라는 것과 기존의 관점과 양립할 수 있다는 것. 이렇게 2가지를 추가로 입증해야 한다.


-Part 5 운전석으로 돌아가며, 강력함과 즐거움





이 부분이 많이 공감이 가더라구요..


게임의 부담

소프트웨어 엔지니어링이 갖는 강한 문화적 결정 요소 중 하나는 그것이 홀로 이루어진다는 것이다. 프로그래머들은 홀로 책상에 앉아 있다. 한 시점에 단 한 명의 프로그래머만이 코드를 입력할 수 있다. 코드는 컴퓨터 상에서 겉으로 거의 드러나지 않으며, 읽히는 일도 거의 없다. 다른 사람들이 작성한 코드를 읽는 것은, 책을 읽는 것이라기 보다는 본인만 알아볼 수 있게 끄적거린 타인의 강의 노트를 읽는 것에 더 가깝다. 프로그래밍 작업은 아주 복잡해서 한결같이 집중해야 하고 오랜 시간 방해받지 않으면서 일해야 한다. 프로그래머들은 이러한 고립과 그것이 내포하는 의미를 분명히 의식하고 있다. 그 누구도 프로그래머가 자신의 프로그램 속에서 하는 일에 이렇다 할 통제력을 행사할 수 없다. 프로그래머들은 자기 코드의 질이 스스로의 성실함과 양심에 달린 문제라는 것을 알고 있다. 상사는 높은 품질을 요구할 수는 있어도 정말 높은 품질인지 확인하기 위해 팔요한 시간과 노력을 직접 투자하려고 하지 않을 것이다. 프로그래머가 작성한 코드를 해독하는 데는 그것을 원래 작성하는 데 걸린 시간보다 더 많은 시간이 소요될 수 있다. 프로그래머들도 이 사실을 알고 있으며, 그들의 개인적인 결정과 행동이 다른 어떤 고려사항보다도 최종제품과 사용자 만족에 많은 영향을 미치는 것도 안다. 궁극적으로, 그들은 제품 성공 여부에 대해 개인적으로 책임을 져야 할 것이다. 그들은 자신들이 게임에서 많은 부담을 지고 있다는 것을 안다.


프로그래머의 외로운 작업은 프로그래머가 자신의 권한을 강하게 의식하게 만든다. 어떤 프로그래머들은 이런 권한을 불편하게 느끼기도 하지만, 게임에서 적은 부담을 지고 있는 다른 사람에게 권한을 양도하는 것을 그보다 훨씬 더 불편하게 여긴다. 마케팅 담당자나 관리자, 디자이너가 그들에게 충고를 하면, 프로그래머들은 그 제안을 상당히 회의적인 시각으로 본다. 만약 충고를 받아들여 일이 잘못된다면, 조언자들은 이미 사라진 지 오래고 비난은 프로그래머에게 그대로 쏟아지리라는 것을 그들은 알고 있다.


~중략~


한편, 모든 프로그래머들은 자신들처럼 사용자가 원하는 것이 무엇인지 잘 모르는 관리자들이 내린 멍청한 디자인 지시 때문에 좋은 제품이 시장에서 실패했던 끔찍했던 기억을 가지고 있다. 타이핑을 싫어하는 한 고위 임원이 자기 회사의 모든 프로그램을 마우스만으로 조종 가능해야 한다고 요구했던 일이 기억난다. 또, 마우스 사용이 서툰 또 다른 고위 임원은 자기 회사의 모든 프로그램이 키보드만으로 조종되어야 한다고 지시한 사례도 있었다. 이 자신을 기준으로 하는 이 파괴적인 디자인은 두 회사 모두에 절망적인 파문을 불러 일으켰다.


일부러 심술궂게 굴고 파괴적인 성격의 프로그래머들도 있지만, 내가 만나본 많은 프로그래머들로부터 판단하건데 그런 사람들은 극히 드물다. 제트 전투기 조정사들처럼 훈련과 규율이 아주 엄격하기 때문에, 이들이 일단 정상급 능력에 도달하게 되면 프로그래머가 아닌 사람을 능력이 떨어지는 사람으로 여기게 되는 것은 어쩔 수 없는 일이다. 소프트웨어 엔지니어들은 같은 분야 사람들을 존중하지만, 프로그래머가 아닌 사람이 프로그래밍의 세계로 뛰어들면, 무디가 이야기했듯이, 그들을 깔보거나 심지어는 엘리트주의자처럼 군다.


프로그래머는 소프트웨어 개발이라는 첨단 기술 세계에 참견하려는 아마추어들을 비웃을 권리가 충분히 있다. 마찬가지로, 프로그래머가 경리부장실 문을 두드리고 들어가 사업 관련 수치들을 다시 계산하기 시작한다면, 경리부장은 남의 일에 간섭하는 프로그래머의 욕심과 오만함을 비난할 자격이 있다.


문제가 생기는 것은 인터랙션을 디자인하는 것과 이를 구현하는 것이 일반적인 개발 과정에서 너무나 철저히 뒤섞여 있기 때문이다. 관리자는 프로그램의 행동 방식을 변경해 달라고 요구할 수는 있겠지만, 감히 프로그래머에게 다른 코드 작성법을 이용하라고 요구하지는 않을 것이다. 그러나 프로그램의 행동양식과 그 구현은 아주 밀접하게 관련이 있기 때문에, 어떤 것은 반대하면서 다른 것은 반대하지 않는 것이 불가능하다. 이것이 무디가 마이크로소프트 사에서 경험한 어려움 가운데 하나이다.


소프트웨어 기반 제품의 개발에 관여하는 대부분의 사람들은 사용하기 쉽고 편한 제품을 만들고 싶어한다. 결과적으로 그들은 계속해서 프로그래머들을 귀찮게 한다. 개발자들에게는 시간 여유가 거의 없기 때문에 이러한 간섭은 그들을 화나게 할 수 있다. 많은 프로그래머들이 혼자 일하려 하며 프로그래머가 아닌 다른 팀 멤버들과 잘 대화하려 하지 않는다. 테므라 히더쇼-하트는 테크니컬 라이터로 일할 때 프로그래머들로부터 정보를 얻어냈던 이야기를 나에게 해주었다.



---나는 간절히 부탁하는 것보다 뇌물을 주는 것이 훨씬 효과적이라는 사실을 알게 되었다. 나는 주로 초콜릿을 이용하곤 했다. 뇌물 방법은 효과가 너무 좋아서 한번은 엔지니어링 매니저가 제품의 변경 내용을 알려주지 않은 것에 대해 공식적으로 사과를 하기까지 했다.(어쨌든 그는 뇌물을 받긴 받았다.) 어떤 회사에서는 초콜릿에 사족을 못 쓰는 엔지니어 한 사람이 그의 동료들의 변경 내용까지 전부 이야기해주고, 그들 몫의 초콜릿까지 받아간 적이 있었다. 뇌물 방법을 사용하기 전에는 제품에서 무엇이 변경되었는지 알아내기 위해 오랜 시간 초과 근무를 해야 했다. 결국, 나는 초과 근무 시간을 절반 이상으로 줄였다.---



이 일화가 흥미로운 이유는 소프트웨어 개발 사업에 조금이라도 경험이 있는 사람이라면 정말로 그렇다는 것을 알기 때문이다. 만약 어느 회사의 경리부장이 수금 관리 직원에게 오늘의 입금액에 대한 정보를 얻기 위해 초콜릿을 뇌물로 주어야 한다는 이야기를 듣게 되다면, 당신은 놀라워하고 분개할 것이며, 또 믿지도 않을 것이다.





많은 임원들이 그들이 내린 지시나 심지어는 가벼운 제안에 대해서도 부하 사원들이 즉각 따르는데 익숙해져 있다. 그들은 프로그래머들이 기술직이므로 그다지 높은 지위와 권력을 가지고 있지 않으며 상사의 지시에 순종적으로 따를 것이라고 생각한다. 프로그래머의 관점에서 보면, 임원들은 게임에서 아무런 부담도 지고 있지 않기 때문에 과연 순종해야 할지 상당히 의심스러울 수 밖에 없다. 독립심이 강한 소프트웨어 엔지니어는 직위의 고하를 막론하고 다른 사람이 하라고 한다는 이유만으로 자신의 코드를 고치지는 않을 것이다.


기존의 코드를 수정하기를 원한다면, 당신은 우선 프로그래머의 마음부터 바꾸어야 한다. 그는 기존 코드에 대한 기득권뿐이나라 불필요하게 코드를 변경하는 수고로움을 거부할 기득권도 가지고 있다. 그들에게 명령이 아닌 부탁을 해야 하는 것은 물론이고, 변경해야 하는 논리적이고 납득시킬 수 있는 이유도 제시해야 한다. 이는 엔지니어가 이해할 수 있는 용어로 표현되어야 하며, 또 게임에서 부담을 갖는 누군가에 의해 제시되어야 한다.


-Part3 포크로 스프먹기, 그들만의 문화



선배 분들의 생각은 어떠십니까.. 저는 찔리는 구석이 한 두 군데가 아니라서요...ㅡㅡ;

신고

WRITTEN BY
빵군
Web Programmer HOONS닷넷(http://www.hoons.kr) 2011 ASP.NET 시삽 http://about.me/y2kpooh

받은 트랙백이 없고 , 댓글이 없습니다.
secret
원문 : http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39146780,00.htm
작성자 : 류한석(피플웨어 운영자)

소프트웨어 업계는 역사도 짧거니와, 하루가 다르게 혁신한다는 특성을 갖고 있다. 그렇다. 이 업계는 그다지 안정되어 있지 않다. 발전의 속도가 빠르기에, 한정된 지면에 일일이 언급하기 힘들만큼 여러 가지 문제점이 발생하고 있는 것도 사실이다. 하지만 인생의 묘미는 남들이 보지 못하는 기회를 보며, 새로운 것에 대한 두려움을 극복해 나가는 과정에 있것이 아닐까?

다음의 얘기는 주로 개발자를 위해 작성된 것이지만, 기획자나 매니저에게도 그대로 적용할 수 있을 것이다. 소프트웨어 공학적인 관점이 아니라, 주로 커뮤니케이션 관점에서 생각해 보았다.

첫째, 이해관계자 관리 기술을 습득해야 한다. 우리가 하는 모든 일에는 이해관계자들이 존재하며 그들의 이해관계가 복잡하게 얽혀있다. 게 중에는 스마트한 사람도 있고 바보도 있고 정치인도 있고 이상주의자도 있다. 물론 폭군도 있다. 이해관계자 관리 기술의 핵심은 핵심 이해관계자들의 캐릭터를 탐구하고 그들의 욕구를 분별해내는 것에 있다.

그리고 그들이 원하는 것에 대해 진지한 관심을 갖고서 그것을 제공하려고 노력해야 한다. 오스트리아의 심리학자인 알프레드 아들러는 “다른 사람에게 관심을 갖지 않는 자는 고난의 인생을 걷게 되며, 타인에게 커다란 폐를 끼치게 된다”고 말한 바 있다. 정말 그렇다. 사람들은 대개 자신의 문제 해결에만 흥미가 있다.

그러한 경향은 특히 하나의 전문 분야를 탐구하는 엔지니어들에게서 흔히 발견된다. 도통 자신의 주장에만 관심을 가진 나머지, 다른 사람이 원하는 바에 대해서는 진지하게 관심을 갖지 않는 것이다. 안타까운 일이다. 필자 또한 그런 시절이 있었기에 동병상련의 마음을 담아 얘기하고 싶다. 타인의 욕구에 관심을 가져야 하며 원하는 것을 주어야 한다. 그래야 자신이 원하는 것 또한 얻을 수 있게 될 것이다.

둘째, 자기계발의 명확한 계획이 있어야 하며 행동해야 한다. 그때그때 생각날 때 하는 것으로는 부족하다. 가이드를 제시한다면, 한 달 기준 최소 30시간 정도는 자기 계발에 투자해야 한다. 어려운 일이다. 실제 자신이 투자하는 시간을 측정해보라. 타성에 젖기는 너무나 쉽다. 사람은 타인의 게으름에는 지극히 잔인하게 얘기하면서, 자기 자신한테는 무척이나 관대하다.

맡은 일이 너무 많아서 잠시의 여유 시간도 없다고 주장하는 사람도 있을 것이다. 사실 그것은 우리 모두가 언제나 준비하고 있는 변명이다. 하지만 바로 그러한 때야말로 정말로 자기계발이 필요한 순간이다.

그저 바쁜 회사 생활에 휩쓸려 살다가는 몇 년 후, (다른 곳에는 갈 수 없고) 현재의 회사에만 다닐 수 있는 ‘회사 인간’이 되어버린 자신을 발견하게 될 것이다. 그때는 회사에서도 버림을 받는다. 아주 단순한 메커니즘이다. 어디에든 스카우트 될 수 있는 사람이야말로 회사가 원하는 인재이다.

혹자는 이렇듯 끊임없이 시간을 투자해야 하는 이 업계에 환멸을 느낀다고 말한다. 글쎄, 내가 업계에 환멸을 느끼면 업계도 내게 환멸을 느낄 것이다. 자기계발을 억지로 행한다면 고통이 되겠지만, 애정을 갖고서 진정 그러고 싶은 마음으로 행한다면 그만한 축복이 없다. 투자하는 시간이 즐거울 따름이다. 그 이유는 다음과 같다. 가치 있는 자기계발과 통합된 실무 경험은 시간이 지날수록 사물에 대한 강력한 통찰력으로 주어지는데, 그것이야말로 성인(聖人)들이 말한 수련과 다르지 않기 때문이다.

셋째, 커뮤니티 활동에 적극적으로 참여해야 한다. 커뮤니티 리더가 된다면 더욱 좋다. 일찍이 업계에서 인정받은 개발자들은 대부분 커뮤니티에서 먼저 인정받은 사람들이었다. 커뮤니티 활동을 통해 미래의 동료를 만나고 팀원을 만난다. 또한 다양한 분야의 사람들과 어울리면서 지적 호기심에 강한 자극을 받을 수 있다는 중요한 이점도 있다.

아티클 작성, 전문가 답변, 세미나 발표, 서적 집필, 블로그 등 적극적인 커뮤니티 활동을 통해 어느 순간 커뮤니티 리더로 인정받는다면 금상첨화이다. 당신은 이제 일개 회사에서 인정받는 사람이 아니라, 업계에서 인정받는 사람이 되는 것이기 때문이다.

이렇듯 장점이 풍부한 커뮤니티 활동에 대해, 대다수의 업계 종사자들이 별반 관심을 갖지 않는 것을 보면 많이 안타까운 생각이 든다. 지금은 새로운 IT 변혁기를 눈앞에 두고 있는 난세(亂世)이다. 당신이 정말 유능한 사람이라면 자신이 몸 담고 있는 조직만을 구하지 말고, 이 업계와 이 사회를 구해주기 바란다. 커뮤니티야말로 중요한 인재 등용문이다.

넷째, 프레젠테이션 기술을 갖추어야 한다. 개발자에 있어서도 이것은 아주 중요한 사항이다. 단순한 기교를 뜻하는 것이 아니다. 만일 달변이 못 된다고 할 지라도, 말 전반에 진실성을 담고 있으면 그것으로 좋다. 눌변일지라도, 내용에 담긴 진실성과 특유의 호소력으로써 청중에게 감동을 주는 사람도 있으니까 말이다.

언제나 마음에 있는 말을 해야 한다. 그러면 자신의 영혼을 속이는 헛소리는 할 수가 없는 것이다. 마음의 말을 전달하는 사람은 청중에게 감동을 준다. 필자 또한 헛소리를 할 때와 마음의 얘기를 할 때가 있는데, 나 자신과 청중에게 느껴지는 임팩트는 천국과 지옥의 차이만큼 크다.

프레젠테이션이 왜 중요한가 잠깐만 생각해보자. 당신이 한 업무에 대해 평가 받는 중요한 자리가 바로 회의이고 회의의 꽃은 프레젠테이션이다. 당신이 10시간 또는 100시간 이상 준비한 기획 또는 설계 내역에 대해 중역들 앞에서 설명할 시간이 딱 10분 주어졌다고 가정해보자. 그런 일은 1년에 몇 번씩 발생하는 것일 수도 있지만, 어떤 이에게는 몇 년 만에 한번 발생하는 것일 수도 있다.

어떠한 경우에든 바로 그 때가 당신이 평가 받는 때이다. 1년을 일한 내용에 대해 단 1시간에 평가 받는다는 진리를 깨달아야 한다. 억울해할 필요는 없다. 사회란 원래 그런 것이니까. 특히 소프트웨어 업계는 더하면 더했지 결코 덜하지 않다.

다섯째, 나의 챔피언을 확보해야 한다. 이에 대한 기본적인 견해는 필자의 지난 컬럼 ‘챔피언이 있는 사람, 없는 사람’을 참고하기 바란다.

우리는 더 나은 삶을 위해 한 차례 도약할 수 있는 기회를 원한다. 나의 능력을 신뢰하고, 도약의 기회를 주기 위해 여러 후보자들 중에서 나를 지지하는 챔피언의 존재는 참으로 중요하다. 그렇게 되기 위해서는 자신의 보스, 회사의 중역, 또는 중요한 이해관계자에게 먼저 작은 성공을 인정받아야 한다. 그 다음에는 그것보다 좀 더 큰 성공을 성취하고, 그 다음에도 계속하여 그러한 흐름으로 해나간다.

처음의 작은 성공이 큰 성공으로 이어질 수 있는 것이다. 작은 성공조차 없는 사람에게 누가 기회를 주겠는가? 실제로는 그 사람이 대단한 인재라 할 지라도 말이다. 아무도 인정하지 않는 인재란, 아예 성립조차 되지 않는 말인 것이다.

행동은 욕구의 소산이다.
소프트웨어 업계의 환경은 결코 낭만적이지 않다. 예전에도 그랬고 앞으로도 그럴 것이다. 필자가 지침이랍시고 몇 가지 솔루션을 제시하였지만, 자신 스스로가 이 업계의 주요 인물이 되겠다는 목표가 없고 또한 과정 상에 있어 자신의 성장이 기쁘지 않다면 모든 것은 무의미한 일이 될 것이다.

“행동은 욕구의 소산이다.” 소프트웨어 업계에서 생존하기를 바란다면 행동해야 한다. 행동을 하지 못하고 있다면, 자신의 부족한 욕구를 탓해야 한다. 당신의 보스, 회사, 업무 그 모든 것은 그저 환경적으로 그 자리에 있는 것일 뿐 당신을 위해 존재하는 것이 아니다. 당신이 그것에 맞추어야 하는 것이다.

고백하건대, 위에 소개한 지침 중 일부 항목은 필자 스스로 ‘가슴 절절하게’ 깨닫는데 무려 10년이 걸렸다. 독자 여러분은 그러한 어리석은 시행착오를 최대한 줄이기를 기원한다.
신고

WRITTEN BY
빵군
Web Programmer HOONS닷넷(http://www.hoons.kr) 2011 ASP.NET 시삽 http://about.me/y2kpooh

받은 트랙백이 없고 , 댓글이 없습니다.
secret