최근 재미있는 글을 봤다. C 언어로 모바일을 위한 API 서버를 만들었는데, 이에 대해 댓글의 토론이 가관이 아니다. 물귀신들이 들러 붙고 난리도 아니다.

  1. 아파치 모듈로 개발된 API 서버, 이음 베이론을 소개합니다.
  2. C언어로 API 서버 개발, 생각보다 나쁘지 않아요

글의 결론은 ‘모바일 API 서버를 C 언어로 만드니 성능이 좋네요’.. 이에 대항하는 물귀신들은 ‘나를 납득시킬만한 근거를 대라’, ‘C언어로 만들었다고 자랑질이냐’ 등등…



모든 사람이 경험도 다르고, 깊이도 다르니 글쓴이야 모든 눈높이에 맞춰 대응하기도 힘들겠다. 그냥 나는 내 생각대로 얘기하자면…

  • 글쓴이가 모바일 API를 C언어로 만든 글은 필자가 보기에 자랑질도 아니고, 이런 사례를 만들었는데 놀랍더라.. 정도인 것 같은데, 글쓴이가 무슨 비윤리적인 짓을 한 것 마냥 댓글러들의 오두방정이 지나치다. C언어로 만들어서 만족한다는 데 왜 주변에서 C로 만들었냐고 오두방정일까… C언어로 만들면 우리나라 박대통의 창조경제에 어긋나기라도 하나?

  • DB 부하가 가장 많은 상태에서 C언어로 API 성능을 극대화 한 것 자체 무용론… 댓글러들은 무슨 ’하드웨어 스팩을 대라..!’는둥, 저렇게 차이가 나는데 ‘프로파일링을 해봤느냐.. 당연히 해봐야 하는거 아닌감?’ 하는 뉘앙스들… 글쓴이가 자기들 따까리도 아니고… 프로파일링 해봤는 지 궁금하면 직접 자바가 왜 느린지 프로파일링 해보는 게 더 빠르지 않을까 생각드는데…

  • C는 시스템 프로그래밍에 적합한 로우레벨, 자바나 트랜드한 스크립트 언어들은 고급언어… 정말 욕 한 바가지 하고 싶다. 정말 지랄 옆차기도 제대로 헛발이다. 초기에 어느 정도 프레임과 API가 정의되면, API 코딩하는 건어느 언어로 하던 그 표현력은 거의 비슷하다. 10줄 짜리 1줄로 표현한다고 생산성이 좋고, 유지보수, 리팩토링까지 좋은 건 아니다. 언젠가 요구 사항으로 인해 1줄 짜리를 10줄로 풀어낼 날이 올거다.

  • C/C++/Objective-C 등 C 계열의 언어로 만들어진 라이브러리가 없다고들 하는데 C 계열의 오픈 소스가 가장 많다. (근거는 직접 찾아보세요) 이제 슬슬 트랜드의 정점을 찌르는 파이썬, 루비, 자바스크립트 등의 스크립트 언어들의 오픈 소스를 다 합쳐도 C 계열을 추월하지 못한다. 물론 댓글러들의 눈높이에 맞는 C 계열 오픈 소스는 그리 많지 않을 뿐이다.

  • 모바일 API 서버에 대한 글이라 웹 개발자만 우루루 죽자고 달라 붙는다. C언어로 만든 API 서버가 자바 서버 10대를 5대로 줄인거면 좋은 성과 아닌가? 100대라면 산술적으로 무료 50대나 줄일 수 있는데도… C언어로 만들면 마치 유지보수 헬게이트라고 하는데, 필자는 JavaScript가 최고의 헬게이트 아닌가 뼈저리게 느낀다.

  • 나는 개발자들이 포지셔닝된 트랜드를 어느 정도 따라갈 수 있으면, 더 이상 죽자살자 트랜드를 쫓지 않길 바란다. 그래봐야 빨리 은퇴하는 길이고, 나이들면 더 할게 없어질거다. 트랜디한 기술은 치고 올라오는 귀염둥이 신입들에게 넘기고…

    그때가 되어도 귀염둥이들과 트랜디한 기술 가지고 ‘그거 써봤니?’, ‘써보니 어떻드라’, ‘버그 있더라’ 농담 따먹고 놀 순 없지 않는가…?
 
 본격적으로 개발을 하던 시점에서 트랜드는 천천히 따라가고, 점점 그 이전 기술을 공부할 필요가 있다고 본다. 소프트웨어 공학도 공부하고, C 언어, 그리고 어셈블리어, 그리고 운영체제까지… 그럼 댓글러들이 하는 토론보다 더 발전적인 이야기와 비전이 보일거다.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. jh.l 2014.01.23 06:59 Address Modify/Delete Reply

    언어는 언어일뿐

  2. jongwook 2014.01.23 11:06 신고 Address Modify/Delete Reply

    안녕하세요 귀여워해주셔서 감사합니다!

  3. sebatyler 2014.01.23 11:53 Address Modify/Delete Reply

    좋게 봐주셔서 감사합니다.

  4. 전호진 2014.01.23 15:16 Address Modify/Delete Reply

    승리한 병신이 되라!
    멋져요..

  5. snail 2014.01.24 01:12 Address Modify/Delete Reply

    분명 생산성 좋다는 언어인데도 코드를 스파게티로 만들어두는 사람 보면서 느낀게, 역시 잘 짜는 사람은 뭘 해도 이쁘게 짜겠구나더라고요..

  6. Tae-Ho 2014.10.14 18:09 신고 Address Modify/Delete Reply

    ㅎㅎ c를 괜히 저평가하려는 개발자들이 좀 있습니다. 그들에겐 이유란 없습니다. 이유가 있다면 자기가 안해봤다는거...

  7. 조제 2016.01.25 12:40 Address Modify/Delete Reply

    좋은글 잘 읽었습니다

아마 IT 트랜드에 관심이 많거나 이 분야에서 일하시는 분이라면 관심 있게 볼 수 있는 TV 프로그램이 있다. LIVE SMART SHOW의 "직설 IT 수다" 프로그램이다. 이 프로그램은 IT 트랜드에 대한 주제를 놓고 4명의 고정 게스트가 여러 가지 의견을 나누고 여러 각도로 주제를 재조명하는 재미있는 프로그램 중 하나라고 할 수 있다.











이번 MS OFFICE 2013에 대해 뜨거운 감자로 '과연 MS OFFICE가 시장을 지속적으로 영위할 수 있을 것인가' 에 대한 것이다. Microsoft의 킬러 앱이라고 하면 단연 "Microsoft Office(MS OFFICE)"라고 할 수 있는데, 이 자리를 노리는 많은 웹 서비스가 있고 그것이 대안이 될 수 있다는 것에 잠시 초점이 맞추어졌다.

 

구글 Docs, 에버노트의 웹 서비스가 MS OFFICE 시장을 빼앗을 수 있을까?

필자는 답부터 말하면 "No" 라고 말하고 싶다.

대표적으로 구글 Docs와 MS OFFICE의 가장 큰 차이점이라고 하면, 구글 Docs는 웹 서비스이고, MS OFFICE는 데스크탑 응용 프로그램이다. 그리고 최근 MS OFFICE는 SaaS(Software As a Service) 형태를 띄며 '공유, 모바일' 그리고 클라우드까지 서비스 영역을 확장하는 시도를 하고 있다. (이미 클라우드와 제한적인 연동을 지원한다.)

여기에서 뜨거운 감자로 떠오르는 것이 굳이 MS OFFICE를 대체할 수 있다는 것이다. 구글 Docs를 써보면 충분히 웹 브라우저를 이용하여 웹에서 문서를 편집하고 공유할 수 있다. 웹이라고 하는 용이한 접근성으로 PC에 설치를 해야 하는 MS OFFICE를 구매할 필요성이 점차 낮아지고 있다는 점을 지적하고 있다.

필자는 이 점을 공감하고 있다. MS OFFICE는 라이선스를 구매해야 하며, PC에 설치해야 하며, 로컬 컴퓨터를 주요 스토리지로 사용한다는 점에서 구글 Docs에 비해 단점이라고 할 수 있다. 그리고 간단한 문서를 작성하거나 편집하기 위해서는 구글 Docs의 웹 서비스를 사용하는 것이 훨씬 이득이다. 그리고 온라인상에서 여러 사람과 동시에 문서를 작성/편집하는 등 책이나 출판을 목적으로 구글 Docs를 사용하는 경우도 있다.

MS OFFICE는 이름에서도 알 수 있듯이 사무자동화(OA) 업무에 사용하기 편리하다. OUTLOOK, EXCEL, WORD, POWERPOINT, SHAREPOINT WORKSPACE, ONENOTE 등의 소프트웨어들이 MS OFFICE 제품으로 엮인다. 그리고 SKYDRIVE의 클라우드 저장소와 연동이 되며, SKYDRIVE에서 문서를 열거나 만드는 경우 웹에서 직접 문서를 작성/편집이 가능하다. 웹에서 MS OFFICE 기능을 제공하는 것을 "Web App" 이라고 하는데, SHAREPOINT를 사용하는 경우 인트라넷에서 웹에서 OFFICE의 대부분의 기능을 제공한다. 데스크탑 오피스를 웹으로 고스란히 옮겨놓은 것이라고 보아도 무방할 정도의 퀄리티이다.

아래와 같이 필자는 크롬 브라우저를 이용하여 SKYDRIVE에 저장해 놓은 POWERPOINT 문서를 열어보았다. 완벽하게 애니메이션까지 재생이 된다. WORD, EXCEL 등의 문서 포멧을 지원한다.

 













하지만, 사람들마다 성향이 다르듯이 필자는 구글 Docs를 쓰려고 노력해봐도, 에버노트를 쓰려고 노력해봐도 불편함부터 느껴진다. 단지 언제든지 불의의 사고로 복원이 필요한 경우를 대비하여 아이폰, 아이패드 동기화 용도로만 쓸 뿐이다.

 

"구글은 당신이 지난 여름에 한 일을 알고 있다"

구글은 정말 많은 무료 서비스를 제공한다. 그 중에서 메일 서비스(GMAIL) 또한 구글의 강력한 킬러 서비스 중 하나인데, 예전에 구글 메일과 관련된 일화가 있다. 친구와의 하와이 여행을 위해 구글 메일로 하와이에 대한 이야기를 주고 받았는데, 어느 날 구글 메일 페이지 내의 광고에서 "하와이…" 에 대한 맞춤 광고가 떴다는 것이 주요 골자이다.

그 밖에 일화도 있다. "[영상]"구글 메일이 당신의 사생활을 훔쳐본다"

구글이 내놓은 모든 무료 서비스는 구글에게 가장 가치 있는 "키워드"라는 정보를 수집할 필요가 있다. 이 키워드는 트랜드를 반영하기도 하며, 이슈 또는 비전을 제시할 수 있다. 또 한가지는 구글 메일은 강력한 스팸 차단 기술을 보유하고 있다. 필자가 써본 메일 중에 스팸 차단이 가장 잘 된다고 느낀다. 스팸 차단 기술은 기본적으로 차단된 제목 또는 일부 내용이 차단된 키워드를 포함하고 있는 경우 스팸으로 분류하기도 하고, 특히 구글 메일은 이보다 더 효과적이고 강력한 알고리즘을 사용한다. 그럼에도 불구하고 많은 벤처 기업과 중소 기업은 구글 메일을 기업 메일로 도메인을 연결하여 사용하기도 한다.

구글은 당신의 이메일이나 구글Docs 의 정보를 스캔한다고 보면 된다. 극단적으로 구글이 당신의 정보를 스캔하지 않는다고 해도, 이미 당신의 정보는 더 이상 당신의 정보가 아니다. 왜냐하면 당신이 원하는 만큼 제어할 수 없는 곳인 구글 서버에 당신의 정보가 저장이 되어 있기 때문이다.

이제는 굳이 구글을 해킹을 하지 않더라도 개인정보를 훔치는 것은 생각보다 쉬워졌다. 국내에서는 이미 옥션, 넥슨, 네이트온, KT 에서 우리나라 전체 인구인 약 5천만보다 수 백배가 많은 개인 정보가 노출이 되었고, 이 정보로 타인의 개인정보에 접근이 쉬워졌다. 쉽게 말하면, 만약 우리나라 대통령 "이명박" 각하가 옥션, 네이트온, KT에 가입되었다면 해킹된 정보만으로도 "이명박" 각하의 보안 정보에 접근할 수 있는 정보가 충분히 제공된다.

 

다시 원점으로 돌아가보자. 최신 운영체제는 파일에 강력한 보안을 적용할 수 있는 기능을 제공한다. 무료/유료로 제공되는 인트라넷의 자원을 통합하여 관리할 수 있는 소프트웨어도 있다. (유료 소프트웨어 중 SHAREPOINT가 대표적). 그리고 전사적인 자원을 통합 관리, 보안, 제어할 수 있는 Active Directory와 같은 기술도 있다.

물론 처음부터 모든 구색을 갖추고 시작하는 벤처나 기업이 없는 경우가 더 많다. 하지만, 무료로 제공되는 여러 가지 클라우드 서비스는 서비스 제공자에게 있어 "무료가 아닐 수 있다". 왜냐하면 많은 클라우드 서비스는 "당신이 지난 여름에 한 일을 알고 있기 때문이다." 우리가 무료 웹 서비스를 즐길 수 있는 댓가를 무료 웹 서비스에게 지불한다는 점을 항상 잊어서는 안된다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 아크몬드 2012.08.03 09:50 Address Modify/Delete Reply

    재밌게 읽고 갑니다.

개발자와 프로그래머는 말로 설명하거나 회의를 통해 결론을 이끌어내는 능력이 매우 부족한 것이 필자의 경험입니다. 바로 개발자나 프로그래머는 내향적인 성향을 가진 사람이 많더군요. 누군가와 함께 고민해서 결론을 이끌어 내는 것 보단, 이러한 공유되는 정보 없이 스스로 해결하기를 바라니까요.

   

세계를 이끌어가는 리더는 내향적인 성향의 사람이 많다.

가장 대표적인 인물이 버럭 오마바와 빌 게이츠일 것입니다. 특히 빌 게이츠는 유아기 시절에 '자폐증'을 의심할 정도로 매우 소극적이지만, 현대에 들어서 세계적인 글로벌 기업인 Microsoft 최전방에서 이끌었던 리더가 되었습니다. 과연 어떻게 내향적인 빌 게이츠가 세계적인 리더가 되었을 까요?

여러분들이 잘 아는 '주의력 결핍증'은 주의가 산만하며, 점차적으로 폭력적으로 변하는 사회적으로 문제가 되는 병 중의 하나 입니다. 주의력 결핍증은 외적으로 도를 넘어선 외향성을 보이며, 잠시도 가만히 있질 못하고 주위가 산만하며, 사회적으로 적응력이 부족한 사람이라는 인식이 강합니다.

주의력 결핍증의 대표적인 인물은 누구일까요? 바로 토마스 에디슨(Thomas Alva Edison) 입니다. 어떻게 주의력 결핍증인 에디슨이 높은 집중력을 요구하는 과학계에서 역사에 남는 과학자가 되었을까요?

주의력 결핍증은 매우 사회적으로 심각한 정신병에 해당되지만, 실제로는 그렇지 않습니다. 단지 사회적인 관념과 반대될 뿐이지만, 개인적인 능력을 발휘하기에 매우 훌륭한 병이 '주의력 결핍증'입니다. 주의력 결핍증은 평소 관심의 대상을 쉽게 실증 내며 주위가 산만하지만, 자신에게 관심이 있는 부분에서는 매우 놀라는 집중력을 보여줍니다.

조금은 다르지만, 자폐적인 증상을 보였던 빌 게이츠가 어렸을 땐 사회적으로 곱지 않은 시선인 '자폐증' 의심 증상의 아이였지만, 지금은 이미 세계적으로 이름을 널리 알린 인물입니다. 어려서 컴퓨터 프로그래밍을 즐겼고, 하버드 대학 수학과에서 SAT ( 미국대학 수학능력시험) 에서 800점을 받을 정도로 영재였습니다. 여러 기종의 BASIC 언어를 만들었고, IBM 개인용 컴퓨터 시대에서 16비트 프로세서용 BASIC 과 QDOS 를 개량한 MS-DOS 운영 체제를 만든 천재 프로그래머이기도 합니다. 또한 내향적이었던 사람이지만 Microsoft 기업을 세계적인 기업으로 만들어 놓은 인물이기도 합니다.

   

개발자는 대부분 내성적인 사람이더라.

필자의 경험상 대부분의 개발이나 IT 계통의 사람들이 내성적인 성향을 띈 사람들이었습니다. 작은 모임이나 오프라인 스터디를 진행하거나 참석해본 필자로써 대부분 내향적인 사람이 대부분이었습니다. 먼저 발표를 하거나 의견을 내기 보다는 그 사람의 이야기를 듣거나, 발표를 하더라도 매우 비중이 낮기도 합니다.

외형적인 사람은 낯선 사람과 쉽게 친해지고 사교적이지만, 경험상 내향성이 높은 사람들이 더 많았던 것 같습니다.

미국에서 진행한 어떤 실험에서 '대한민국'은 매우 내향성이 강한 국가였습니다. 반대로 미국은 '외향성'이 강한 국가로써 80%가 외향적인 사람이며, 20%가 내향적인 사람이라는 놀라운 결과가 나오기도 하였습니다.

더불어, 우리 나라의 개발자는 시끄럽거나 활기찬 개발 환경을 선호하기도 하지만, 자신의 직무 분야에 집중할 수 있는 환경을 선호하기도 합니다. 주변이 시끄러운 환경에서는 업무 능률이 오르지 않고, 되려 스트레스를 받는 악영향이 미치기도 합니다.

필자 또한 예전 회사에서, 규정된 업무 시간(오후 6시) 이후에, 휘파람을 불거나 음악을 크게 틀어 놓고 일하는 사람 때문에 너무 스트레스를 받은 경험이 있습니다. 그 사람이 싫은 것이 아니라, 시끄러운 환경이 업무에 악영향을 미쳤기 때문입니다. 이런 이유 때문에 저는 이어폰의 음악 또한 꺼려했었죠. 좋아하는 음악을 이어폰으로 귀에 꼽아 보았지만 집중력을 분산시키는 것 조차 업무에 방해가 되었기 때문입니다.

반대로 하루 종일 가만히 앉아서 일하는 외향성이 높은 사람은 대부분의 사람이 퇴근한 뒤에 영화를 감상하면서 소리를 크게 틀어놓거나, 좋아하는 음악을 아랑곳하지 않고 크게 틀어놓기도 합니다. 아마도 자신의 억압된 스트레스를 푸는 방법일겁니다.

 

  

외향성

내향성

성향

적극적이다

소극적이다

환경

활기차다

조용한 것을 좋아한다

집중력

산만하다

집중력이 뛰어나다

사교성

친구가 많다

친구가 적다

사교성의 깊이

친구가 많지만, 서로 소중한 친구라고 생각하는 사람이 적다

친구가 적지만, 서로 소중한 친구라고 생각하는 삶이 많다

이해관계

말로 하거나 메신저로 하는 것이 편하다

글로 표현하는 것이 편하다

표현력

말로 적극적으로 표현한다

글로 적극적으로 표현한다

   

왜 사회는 외향적인 사람을 선호하는가?

대부분 여러분들은 면접 경험이 있을 것입니다. 특히 공채에서 강한 사람들이 외향성을 띈 사람들입니다. 반면 내향성이 강한 사람은 면접에 매우 약하기도 합니다.

이는 고등학교 실험에서도 드러납니다. 외향적인 선생님의 교육은 학생의 발표를 유도하고, 재미있는 분위기를 만들어 갑니다. 하지만 내향적인 학생은 외향적인 선생님의 지도에 매우 부담을 느낀다는 결과가 나왔습니다. 외향적인 선생님의 교육은 주변이 시끄러우며(또는 활기차며) 적극적인 발표를 유도해냅니다. 내향적인 학생에겐 선생님이 천천히 다가와 얘기를 걸 땐 말을 잘하지만, 지목해서 발표를 시킬 때 내향적인 학생은 엄청난 스트레스를 받는다고 합니다. 물론 외향적인 학생은 그런 것을 재미있어 하고 즐기겠죠.

반대로, 내향적인 선생님의 교육에서는 외향적인 학생이 매우 따분함을 느끼지만, 내향적인 학생은 교육 방식에 매우 만족하는 결과가 나왔다고 합니다.

 

외향적인 사람 : 자신을 드러내거나 알리는 것을
즐깁니다.

내향적인 사람 : 면접에서 자신의 순서가 올 때까지의
시간이 무척 긴장되며, 자신을 적극적으로 표현하는데
서툽니다.

왜 기업은 외향적인 사람을 선호하는가? 사실 필자는 내향성을 지닌 사람들에 대한 "편견"이라고 말하고 싶습니다. 이런 인간의 성향은 외적으로 판단하기 쉽지만, 내적으로 판단하기 매우 어려운 문제입니다. 그렇기 때문에 외향적인 사람을 선호하는 것 같습니다. 그리고 기업은 외향적으로 대인관계가 좋은 사람에게 부족한 지식을 가르치는 비용은 적지만, 내향적인 소극적 사람의 지식이 높아도, 대인관계나 성향을 바꾸는데 높은 비용이 들기 때문이라고 하기도 합니다.

그래서 내향성이 높은 사람이 살아가기 힘든 사회이기도 합니다. 재미있는 결과 중에 회사에서 "내향적"인 사람들이 "외향적"인 사람들 보다 능력이 뛰어나다고 생각한다고 합니다. 외향적인 사람은 표현을 하지만, 내향적인 사람은 그들의 이야기를 듣고 그들의 능력의 깊이를 잰다는 것이죠.

   

   

하지만 외향적이어야 한다

필자는 처음 세미나를 진행했던 것이 "온라인"을 대상으로 촬영한 세미나였습니다. 나에게 뭐라 할 사람도 없지만 손 까지 떨어 마우스가 떠는 것까지 느낄 정도로 카메라가 부담스러웠습니다. 이를 대비해, 1년 정도 혼자 동영상 강좌를 촬영했지만, 마이크와 화면 캡춰가 완료되는 순간 식은 땀이 줄줄 흘러 내렸습니다. 큰 연습의 성과가 없었던 거죠^^;

많은 글로벌 CEO 들은 내향적인 사람이 많지만, 내향적인 장점을 바탕으로 외향적을 극복하는 산 증인과도 같습니다. 개발 실력도 중요합니다. 개발을 위해 분석하고 결론을 추론하는 것도 중요합니다. 그리고 그것을 해결하는 것이 중요합니다.

하지만 이런 여러 가지 활동에 외향적인 성격이 부족하다면 서로 간에 이해를 좁히는 것에는 실패할 것입니다. 많은 글로벌 CEO 들이 내향적이지만 외향적으로 노력을 했기 때문에 성공한 사례라고 할 수 있습니다.

서울과학고등학교의 성향 측정 결과, 일반 고등학생들보다 정보의 자각 능력과 분석, 관찰 능력이 뛰어나다고 합니다. 그만큼 영재의 성향은 내향적인 경우가 많다고 합니다.

성향의 평균 60~70%는 선천적이지만, 20~30%는 후천적으로 성향이 형성된다고 합니다. 그래서 기존의 자신의 성향을 바꾸는 것은 매우 힘들고, 그런 사례 또한 매우 적습니다. 내향성의 특징인 높은 집중력과 분석력이 장점이지만, 이것을 공유하고 개선하고자 하는 의지가 없다면 내향적인 성향은 조직과 팀에서 의미가 없기 때문입니다.

조직과 사회는 외향성을 원합니다. 이것을 바꾸는 것은 매우 힘들지만, 분명 당신에게는 도움이 될 수 있는 노력임은 틀림이 없습니다. 다른 사람들이 알아 주길 기대하지 마시고, 스스로의 노력이 자신을 알아보고 허들을 넘을 수 있는 중요한 것임을 분명히 기억하시기 바랍니다.

누군가 자신의 실력을 알아주고 떡 하나 더 주길 기다리는 사람은 감 나무에서 감이 떨어지길 기다리는 곰과도 같습니다. 분명 내향성이 높은 사람에게 주어지는 이점이 있으나, 그 이점을 활용하기 위해서는 외향성의 비중이 필요합니다. 반드시 외향성이 필요한 것은 아니지만, 내향성의 단점을 슬기롭게 극복하는 것은 앞으로 한 걸음을 도약하는데 내향성의 사람에게 주어진 과제가 아닐까 생각합니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 망벨 2010.09.29 12:06 Address Modify/Delete Reply

    재미있는 글입니다. 뭐 저도 개발 회사에 있다보니 주변 사람들을 많이 보지만 내향적인 사람들이 많더군요. 하지만 꼭 그사람의 성향이 개발실력에 영향을 미치는 것은 아니라고 봅니다. 하지만 회사생활을 함에 있어 분명 외향적인 성향은 필요하지요. 좋은 의도의 글 잘 읽었습니다.

심리학은 인간의 잠재적인 내면을 이해하는 매우 중요한 학문입니다. 여러 가지 질병을 이해하고 치료함에 있어서 심리학은 치료를 목적으로 하는 것이 아닌, 그 근본을 이해해야 하는 매우 섬세하고 중요한 것이 틀림이 없습니다. 그리고 심리학에서 최초 인간의 성향을 두 가지로 분류를 하였고, 이를 바탕으로 개발자의 성향을 알아보고 그리고 앞으로 나아갈 방향을 제시해 보고 싶네요.

   

외향성과 내향성

융의 심리유형론(Psychological Type Theory) 은 인간의 성향을 처음으로 "외향성"과 "내향성"으로 구분하였습니다. 외형성은 에너지가 외부로 향하는 경향이고, 내향성은 에너지가 내부로 향하는 경향입니다.

특히 재미있는 것은, 동서양을 막론하고 "외향성"과 "내향성" 중, 외향성은 매우 긍정적으로 묘사하고 있으며, "내향성"은 부정적으로 묘사하고 있습니다. 아래의 네이버 사전을 통해 각 성향에 대한 정의를 알아 봅니다.

외향성이란?

내향성이란?

외향성은 능동적이고, 판단이 종합적이고, 명랑하고 적극적이라는 매우 활동적인 단어를 사용하여 묘사를 하고 있습니다. 반면 내향성은 결단적 부족, 실행력 부족, 회의적, 비판적, 친구가 적다는 부정적인 단어들을 사용하여 묘사를 하고 있습니다.

결론은 외향적인 사람은 성격이 좋은 사람이지만, 내향적인 사람은 성격이 안 좋은 사람으로 비춰지기 매우 쉽습니다. 인간을 단 두 가지 성향으로 사람을 구분하는 것도 무리겠지만, 재미있는 것은 일반인들도 "외향적, 내향적"인 상대방의 성향을 판단하기 매우 쉽다는 것입니다.

   

어린이 시절의 외향적, 내향적인 성향

어린이는 이런 성향을 관찰하기 매우 쉬운 집단입니다. 왜냐하면 사회화가 잘 되지 않은 집단이기도 하며, 자신의 성향을 그대로 표출하려는 경향이 많은 집단이기 때문에 이들을 관찰하면 흥미로운 결과를 얻을 수 있습니다.

외향적인 아이의 특징은 활동 수준이 높습니다. 이는 매우 적극적이며, 한 가지 일을 하는 것보다 여러 호기심을 자극시킬 수 있는 여러 활동을 하고 싶어합니다. 내향적인 아이의 특징은 활동 수준이 낮습니다. 이는 소극적이며, 복잡하거나 시끄러운 환경에 놓이게 되면 "엄마, 정신 없어." 라고 하는 아이들의 집단입니다.

 

외향적인 아이 : 주의 집중력이 낮음

내향적인 아이 : 주의 집중력이 높음

위의 아이의 실험에서 알아볼 수 있는 결과로, 외향적인 아이는 주변의 환경뿐만 아니라 성향적으로 주위 집중력이 굉장히 낮다는 것을 알 수 있습니다. 반대로 내향적인 아이는 주위의 간섭을 받겠지만, 주위 집중력이 매우 높은 아이라는 것을 알 수 있습니다.

   

과연 이 아이들의 성향이 선천적일까요? 후천적일까요?

생후 36개월 된 아이의 가정 학습 시간을 관찰한 결과, 외향적인 아이는 쉽게 지루해하며, 어머니와의 공부에 집중을 오랫동안 하지 못합니다. 반면에 내향적인 생후 36개월 된 아이는 주변의 영향을 받지 않고, 어머니와의 공부를 몇 시간 동안 집중하며 할 수 있는 높은 집중력을 보이고 있다고 합니다.

이는 생후 36개월 뿐만 아니라, 생후 30개월 된 아이에게도 똑같은 행동 성향을 보입니다.

이는 "종단 연구" 에 대상이 되는 아이들을 장기적으로 관찰하는 방법으로 실험이 진행됩니다. 종단 연구는 성향으로 분류되는 아이들이 나중에도 성향이 변하는지, 안 변하는지 등을 오랜 시간 동안 관찰하는 연구입니다. 국내에서는 종단 연구는 생후 18개월 된 아이들을 400명을 표본 대상을 모집하여 연구를 진행하였다고 합니다. 생후 48개월 까지는 6차례 관찰을 하며, 48개월 이후로는 1년 동안 한번씩 관찰하는 방법입니다. 즉, 종단 연구는 5년간 아이들을 지속적으로 관찰하여 그들의 성장이 지속적으로 어떻게 변하는지를 연구입니다.

이 "종단 연구"를 통하여 아이들의 성향이 변하는가, 또는 변하지 않는가의 결과는 아래와 같다고 합니다. 즉, 생후 18개월 이후 한번 결정되는 성향은 쉽게 변하지 않는다는 결론을 얻을 수 있습니다.

   

생후 1개월 전의 아이로 보는 성향

재미있는 결과 입니다. 생후 16주가 되는 아이들을 대상으로, '알코올 냄새 반응', '풍선 터트리기 반응' 등으로 연구한 결과입니다. 외향적인 집단의 아기는 알코올 냄새나 풍선 터트리기 등의 반응에 매우 호감을 느끼며, 거부 반응을 느끼지 않지만, 반대로 내향적인 집단의 아기는 이런 검사에 울음을 터뜨리거나 냄새를 피하거나 깜짝 놀라는 등의 거부 반응을 보였다는 것입니다.

이는 생후 48시간 되는 아이들에게도 비슷한 결과가 있다고 합니다. 이 아이에게 간호사들이 몸을 닦거나 머리를 감기는 행동에, 외향적인 아이는 별 반응이 없지만, 내향적인 아이는 매우 거부하거나 울기도 한다고 합니다.

이는 더 거슬러 올라가 뱃속에 있는 엄마의 뱃속부터 타고난다고 합니다. 정말 신기하죠.

태아의 외향적인 성향은 움직임이 태동이 매우 활발하여 심박수가 157회 정도가 되며, 내향적인 아이는 118회 정도라고 합니다.

정말 과연 성향의 연관은 어떤 관계가 있을까요?

뱃속의 태아의 태동으로도 외향적인 아이와 내향적인 아이는 이미 결정되었다고 합니다.

더 재미있는 것은, 아이를 두 번 가져본 산모의 경험으로, 첫 번째 아이는 태동이 매우 활동적이지만, 두 번째 아이는 태동이 비활동적이라는 것입니다. 이를 보아, 성향의 결정은 태아 시절 그 이전 이라는 것을 알 수 있는 대목이기도 합니다. 활동적인 태아는 스포츠나 빠른 음악에 태동이 반응하는 한편, 내성적인 태아는 클래식이나 조용한 분위기에서 아이 엄마는 태동을 느낀다고 합니다.

   

인간의 성향은 DNA 부터 시작된다고 한다.

여러 가지 실험을 바탕으로 학계에서는 인간의 성향이 결정되는 바로 유전적이고 DNA 의 영향을 받는다고 합니다. 이런 가장 확실한 예가, 마약 탐지견입니다. 마약 탐지견을 만들기 위해 용맹성, 적극성, 집중력 등 검사에서 통과해야 하는데, 이런 탐지견을 만들기 위해 한 마리 당 4000만원의 비용이 필요하다고 합니다. 그리고 그것은 기본적인 개가 용맹성, 적극성, 집중력 등의 성향을 만족해야 하는 약 30%의 성공률을 가지고 있었습니다. 하지만 복제를 통해 똑같은 성향의 개를 우리 나라에서 배출했습니다.

통계적으로 인간에게는 60~70%는 선천적인 성향이고, 나머지 30%~40%는 사회적으로 길러지는 성향이라고 합니다. 즉, 내성적인 성향이 외형적 성향이 될 수 있으며, 외형적 성향이 내형적 성향의 집중력의 장점을 갖을 수 있다는 것입니다.

즉, 인간의 성향을 심리학적인 방향 외에 유전학적인 방향으로 연구가 활발하게 진행되고 있습니다.

   

왠 뜸금 없는 인간의 성향과 DNA?

이 내용은 다음 편에 얘기 하고자 합니다. 일반적으로 내향적인 성향보다 외향적인 성향에 매우 관심 있어하며, 사회는 내향적인 성향은 매우 부정적인 시각을 가지고 있기도 합니다.

이것은 비단 사회적인 이슈 뿐만 아니라, 개발 또는 IT 세계에서도 통용될 수 있습니다. 사회는 왜 외향적인 적극적이고 진취적인 사람을 원하는가? 바로 이러한 물음에서 시작된 것입니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 진희쩜넷 2010.08.16 19:45 Address Modify/Delete Reply

    흥미로운 이슈입니다. 다음편이 기대됩니다 ^^

 

오늘 훈스 닷넷에서 조금 짜증이 나는 글을 읽었습니다.

http://www.hoons.kr/board.aspx?Name=free&Mode=2&BoardIdx=32994&Key=&Value=

 

운전하다가 접촉사고가 일어나면 목소리 큰 사람이 이긴다는 하지만, 이 글을 읽으면서 사실 '이건 아니다!' 라는 생각부터 듭니다. "나쁜 관리자" 라는 것이 무엇인지는 감을 잡았지만, 무엇이 나쁘다는 것인지 도저히 저는 이해할 수 없네요.



업계를 보면 관리자의 자격이 전혀 없는 사람이 관리를 맡고 있는 경우가 무척 많다. 나쁜 관리의 비용은 엄청나다. 단지 팀 구성원들의 작업에 지장을 주는 정도가 아니라, 조직의 목표 달성에 해악을 미치며 결국 상당한 대가를 치르게 만들고 프로젝트를 완전히 망치는 경우가 빈번하다.

필자는 단지 관리자를 잘못 배정했기 때문에 수백억 원의 손해를 본 어느 대기업의 프로젝트를 경험한 적이 있다. 팀원들은 모두 유능했고 각자의 마음 속에 일을 잘하고자 하는 열정이 있었지만, 관리자의 무능과 변덕과 학대로 인해 팀원들은 모두 좀비가 되어갔다. 일부는 떠났고 일부는 일을 하지 않았고 일부는 하는 척을 했다. 결국 수년간 프로젝트를 진행했으나 결과는 나오지 않았고 프로젝트는 취소됐다. 몇 가지 추가적인 원인이 없었던 것은 아니지만, 가장 주요한 요인은 ‘나쁜 관리자의 존재’ 그 자체였다.

나쁜 관리자는 팀원들이 무엇을 하고 있는지 알지 못하며(또는 관심이 없으며), 팀원들의 능력을 제대로 파악하지 못한 채로, 원칙 없이 업무를 지시하며, 부적절한 인력을 배치하고, 팀원들과 제대로 대화를 나누지 않으며, 펫프로젝트(pet project, 고위층 또는 자신의 개인적인 관심으로 만들어낸 프로젝트)로 인해 업무 우선순위를 마구 바꾸고, 결과가 나와도 잘했는지 못했는지 제대로 판단하지 못한 채 자신의 기호에 따라 결과를 재단한다. 한마디로 그들은 조직의 목표와 팀원의 성장에는 아무런 관심이 없으며 단지 자신의 안위만 생각하는 사람들이다.

그러한 나쁜 관리자의 존재가 지극히 예외적인 경우라고 생각하는가? 만일 그렇다면 당신은 조직 생활의 경험이 많지 않든가, 아니면 억세게 운이 좋은 경우일 것이다. 그런 나쁜 관리자로 인하여 젊은 시절의 소중한 경험을 빼앗기는 팀원들이 몹시 많다. 나쁜 관리자의 해악은 단지 프로젝트의 실패로 나타나는 것뿐만 아니라, 사람들의 인생에서 그 시기에 필히 겪어야 할 소중한 경험까지 앗아가 버리는 것에 있다. 좋은 관리를 받아보지 못한 사람은 좋은 관리를 할 수가 없다.
[출처:IT컬럼니스트 류한석님 글 일부 발췌]

 

일단 저는 류한석님의 극단적인 내용에 조금 반대 의견이네요 ^^;

일단 이 답글을 적는데, 보시는데 조금 비위가 나쁘다면 일단 양해를 구합니다.

 

프로젝트 관리자란?? 일단, 프로젝트를 발주하는 고객(또는 발주처)와 프로젝트를 구현을 진행하는 개발자들과의 조율이 필요합니다. 엄밀히 R&R 을 따지자면 관리자는 개발자가 무었을 하는지 알 필요가 없습니다. 관리자의 입장에서는 단지, 개발자는 해야할 일을 정확하게 구현을 완료 했는지가 중요합니다. 개발자가 역량에 미치지 못했다면 그 개발자를 뽑은 사람이 잘못이겠지요.

 

프로젝트 개발자란?? 고객에 의해 정의된 요구사항을 순차적으로 구현하는 사람이 개발자입니다. 고객과 관리자는 개발자의 역량을 측정하는 방법은 요구하는 시간내로 기능을 구현했는지가 중요합니다. 가장 좋은 개발자는 재시간에 기능을 구현할 수 있는 역량을 갖춘 사람입니다.

 

그냥 간단하게 프로젝트 관리자와 개발자를 정의했습니다. 제 상식으로는 위의 류한석님 글을 이해하기에는 부연 설명이나 설득력이 너무 부족하기만 합니다.

 

첫번째로, 자! 제가 정의한 내용에 대해, 과연 개발자의 입장에서 관리자를 평가한 것인지, 관리자의 입장에서 관리자를 평가한 것인지 애매하네요. 프로젝트가 실패하는 원인을 여러가지입니다. 관리자는 고객의 파워나 변덕이 너무 심해 그것을 받아줄 수 밖에 없을 수 있습니다. 반대로 관리자가 고객의 요구에 대해 방어적인 태세만 취한다면 고객의 입장에서는 좋은 프로젝트 관리자가 아닙니다. 즉, 관리자와 고객간의 비하인드 스토리는 전혀없고 단지, 개발자 입장에서만 불평을 나열한 것 같습니다. 잘 아시겠지만, 고객은 자신의 요구하는 정확한 요구사항을 알지 못합니다. 그것을 잘 정의하는 사람이 아키텍처나 설계자가 되겠지요.

 

두번째로, 이미 얘기했지만 엄밀히 따지자면 관리자는 개발자가 무었을 하고 있는지까지 알 수 없고 알 필요도 없습니다. 관리자는 소수이지만 개발자는 다수일 수 있습니다. 부적절한 인력 배치란 무엇인가요? 그리고 왜 프로젝트 관리자(PM) 이 개발자와 이야기를 나누어야 한다고 생각하나요? 실질적인 개발자와 협업하는 사람은 프로젝트 리더(PL) 일 가능성이 큽니다. 즉, 류한석님이 말씀하시는 프로젝트 관리자란 진정 프로젝트 관리자인가요? 아니면 개발팀의 관리자 인가요?

 

세번째, 프로젝트 관리자(PM) 는 프로젝트 전반을 관리하거나 매개체 역활을 합니다. 프로젝트 관리자는 다수의 개발자의 결과물을 보증하는 QA(Quality Assurance) 가 아닙니다. 순차적인 원인은 관리자의 잘못에서 비롯되는 것이 아닙니다. 따지자면 요구사항을 제대로 이해하지 못했거나 변덕스런 요구사항에 짜증이 날만한 개발자로부터 비롯되거나, 제대로 된 기능을 만들지 못한 개발팀 내부적인 문제가 되겠지요. 

 

결국 좋은 프로젝트 관리자란 개발자의 비유에 맞추어야 할 필요가 없습니다. 프로젝트 관리자는 자신의 위치에서 최선을 다하면 될 뿐입니다. 그것을 단지 몇명의 개발팀의 개발자에 의해 평가될 문제가 아닙니다. 아마도 프로젝트 관리자는 단지 개발만 하는 개발자보다 더 많은 고민을 가지고 있을 것입니다.

 

대체적으로 이러한 불만은 개발자인 자신의 요구가 반영이 되지 않거나, 자신의 입지를 넓히려고 하지만 그렇게 되지 않을 경우에 개발자들은 위와 같은 불평을 하게 됩니다. 가령, 동영상 플레이어가 필요하다고 한다면, 동영상을 재생하기 위해 미디어 플레이어 객체로 단지 몇줄로 재생하는 것과, Silverlight 로 동영상 플레이어를 만드는 것은 효율성을 따지면 극과 극입니다. 또는 설계가 일부 잘못되었다고 하더라도 시간 vs 비용 을 따지면 하고 싶어도 못하는 경우가 많습니다.

 

프로젝트 관리자가 일부 소수 인원을 중심으로 움직이지 않는다는 것이 오히려 좋은 프로젝트 관리자인 경우가 많습니다. 제한된 공정에 좋은 소프트웨어를 Delivery 하기 위한 것은 개발자가 프로젝트 관리자를 무언가로 평가하는 것보다 더 좋요하기도 합니다. 즉, 개발자의 입장에서 가장 좋은 대책은 설계대로 프로젝트의 구현을 개발하는 것이고, 그것이 잘못되었을 때는 프로젝트 관리자의 책임을 묻는 것이 맞습니다.

 

프로젝트가 성공하건 실패하건 그것은 단지 한명이 몰빵할 수 없는 문제입니다. 고객, 프로젝트 관리자, 기타 개발 인원이 골고루 잘못된 것이지, 성공과 실패를 프로젝트 관리자에게 몰빵한다는 것은 이미 자신부터 잘못되었다고 해석하는 것이 맞습니다.

 

이해할 수 없는 개발자의 감성만 자극하는 이러한 글을 오히려 개발자에게 프로젝트 관리자에 대해 잘못된 인상만 심어줄 뿐입니다. 이 글을 보니 관리자가 무엇을 잘못했는지 전혀 나타내지 않았군요.

 

만약, 비난의 대상이 프로젝트 관리자(PM) 가 아닌 개발 팀장 등이라고 하더라도 똑같은 비난을 했을 것입니다. 왜냐하면 자신은 잘못이 없다는 것을 전재로 했을테니까요. 오히려 필자는 이러한 문제를 인지하고 있으면서도 슬기롭게 대체하지 못한 개발자에게도 문제의 소지가 다분하다고 생각합니다. 이런 형식의 회고는 전혀 자신과 타인에게 도움이 되지 않을 뿐입니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 한진수 2010.03.26 16:02 Address Modify/Delete Reply

    http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039162121
    http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039164072
    2007년도 지디넷 컬럼의 극히 일부분의 내용으로 괜한 자극을 드린점 사과드리구요.(_-_);; 괜히 타겟 아닌 타겟이 된 류한석님에게도 사과의 말 전합니다. 제가 링크 두개를 드렸는데요. 전체 내용을 살펴보게 되면 그저 좋은관리자, 좋은개발자에 대한 이야기를 하고 싶었던 것으로 보이며, "나쁜 관리자가 프로젝트를 망치고 있다!" 라는 소제목이 "프로젝트를 망치는 것은 나쁜 관리자다!" 라는 것은 아닐 것입니다. 일부 글에 너무 즉각 반응하신것은 아니셨나 하는 생각을 해 봅니다.(^^)

    • 땡초 POWERUMC 2010.03.26 16:00 신고 Address Modify/Delete

      그러게요. 2007년도 글이었네요. ^-^;
      원본을 보니 글의 일부를 게시판에 올리셔서
      오해를 많이 했답니다.

      제가 글을 쓰는 속도가 늘었나보네요. 즉각 반응까지는 아니였는데~ ^_^
      아무튼 좋은 글 보고 갑니다.

  2. 심순덕sjbj 2010.04.02 11:46 Address Modify/Delete Reply

    음~ 글을 논리적을 잘 쓰시네요
    아마도 생각이 깊으신듯....
    우연히지만 좋은 의견 보고 갑니다.

이전 포스트
[UMC/엄씨 생각] - 당신이 생각하는 UX 란?

이전 포스트에서 필자 나름대로 UX 에 대한 여러 가지 생각을 정리하고 나름대로 분류하기를 아래와 같이 정리하였습니다.

  • Web Service UX
  • Desktop UX
  • Mobile UX
  • RIA UX
  • Surface UX
  • Enterprise UX

물론 위와 같이 분류한 장르의 기준은 IT 기준이며, 좀 더 세세하게 분류하지는 않았습니다. 이미 위의 정도의 분류라도 필자 또한 어떻게 재분류를 해야할지 막막하기도 합니다.

하지만, 위와 같이 분류한 UX 의 장르에 대해 문제가 있습니다. 분명 UX 디자이너는 UX 향상을 위해 많은 고민을 했음에도 불구하고 말입니다. 분명 UX 는 기존의 경험보다 나은 경험을 선사하기 위함이지만 혹시 그것은 개발 팀이나 디자인 팀 내부적인 경험이 아닐런지요.

   

UX 의 향상 어떻게 평가하나?

이 질문은 UX 를 하는 사람이라면 누구나 고민해야 할 질문입니다. 이미 이전 포스트에서 언급한 내용이지만, 새로운 기술의 발전으로 RIA 와 같은 기술로 사용자에게 새로운 경험을 줄 수 있지만, 과연 그것을 어떤 기준으로 평가하느냐 입니다. 기존 HTML 을 RIA(Silverlight, Flash 등) 으로 바꾸었다고 과연 사용자 경험이 좋아졌다라는 것입니다.

필자의 간단한 경험을 예를 들어봅니다. 이전의 버튼 방식의 휴대폰과 터치 방식의 휴대폰이 있습니다. 분명 터치 방식의 휴대폰은 사용자에게 커다란 LCD 화면과 직관성을 제공해 줍니다. 그리고 지금의 대부분의 휴대폰은 이런 터치 방식의 휴대폰을 선호합니다. 하지만, 필자는 터치 방식의 휴대폰을 처음 구매하였을 때 분명 좋은 UX 를 얻었지만, 이로 인하여 선호하던 UX 를 잃어버렸습니다.

   

   

바로 터치 방식은 운전하는 사람에게는 치명적인 UX 임이 분명합니다. 예전의 버튼 방식의 휴대폰은 휴대폰 버튼을 보지 않고서도 문자를 충분히 보낼 수 있을 정도였지만, 터치 방식의 휴대폰은 운전 중 전방의 시선을 때지 않고서는 도저히 문자를 보낼 수 없었습니다. 사실 저는 이게 너무나도 불편했습니다. 터치 방식이라 사용성은 편해졌지만, 운전할 때 만큼은 도저히 휴대폰을 쳐다볼 수 없게 만든 UX 이기도 합니다. 또한 기존의 사용자를 전혀 배려하지 않았습니다. 적어도 저희 부모님은 터치 방식의 휴대폰을 전혀 조작할 수 없을 지경이니 말입니다.

 

최근에는 일본 식민지 시절의 문화를 타파하고자 지하철에서 "우측 보행" 을 시행하고 있습니다. 이 정책에 지하철마다 포스터 몇 장과 바닥 안내문이 전부라는 것이죠. 나름대로 잘 지키고 싶지만, 과연 모든 사람들이 그것을 직관적으로 받아들이느냐 입니다. 이미 방송에서 언급했었지만, 이러한 문화가 정착되기까지 충분한 시간이 없었다는 것도 문제일 것입니다.    

마찬가지로, 필자가 이미 언급한 Web Service UX, Desktop UX, Mobile UX 등등 어떤 기준으로 UX 향상을 평가하냐 입니다. 특정 집단은 자신에게 다가온 UX 에 대해 낙관적일지 몰라도, 일부 집단은 오히려 방해만 될 뿐일 수 있다는 것입니다.

   

UX 에 대한 고찰

분명 UX 의 향상은 누군가에게 이로움을 주지만, 누군가에게는 정신적인 스트레스가 될 뿐입니다. 이미 관심있었던 누리꾼이라면 네이버가 2009년도 새해에 개편을 했던 기억을 말입니다.

참고 문헌
http://offree.net/entry/Open-Naver

많은 찬반 세력들이 "예전 네이버 메인을 돌려달라", "다신 네이버 안쓰겠다" 라는 심오한 의문을 남겼지만, 이제는 평화로워졌지만...

즉, UX 를 생각한다면 UX 를 위한 전략이 필요하다는 것입니다.

 

감각형 UX
측정 기준 : 오감(五感) 만족

아마도 가장 사용자가 느끼기 쉬운 UX 입니다. 사람의 인체의 5가지 감각을 이용한 UX 로써 보고, 느끼는 여러 가지 감각적인 활동들이 바로 이 분류에 속할 것입니다. 그리고 감각형 UX 는 디자인 측면에 매우 근접해 있습니다. 그리고 비교적 쉽게 얻을 수 있는 UX 입니다.

하지만 인간은 특히 이런 감각적인 반응에 빠르게 적응한다는 것입니다. 영화 '트랜스포머'가 보여준 변신 로봇의 향수와 영화 '아바타' 가 보여준 판도라 행성의 자극적인 자연의 3D 영상 기술은 시간이 지남에 따라 그 자극이 줄어들 수 밖에 없다는 것이죠.

바꾸어 얘기하면, 언제까지 인간의 이런 자극적인 감각에 의존할 것이냐는 것입니다. 매번 새로운 것을 원하고 자극적인 UX 를 원하는 것이 당연하다고 하지만, 이러한 UX 는 이미 국한된 사용자의 취향에 맞추는 것일 뿐이지, UX 자체의 향상을 가져오기 힘들다는 것입니다.

   

지능형 UX
측정 기준 : 사용자의 피드백, 지표 데이터

지능형 UX 는 아마도 가장 현실적인 지표 데이터가 될 것입니다. 지능형 UX 는 TV 시형률을 조사하는 것과 같이, 특정 집단이나 특정 표준 편자를 감안하여 절대 수치를 얻는다는 것입니다. 즉, 다수결의 원칙이 적용된 가장 UX 에 대해 시각적이고 신뢰할 수 있는 지표 데이터를 제공해 줍니다.

이러한 방식의 UX 는 아마도 설문 조사, 사용자 피드백, 사용자 행동 반경 데이터를 조합하여 얻을 수 있을 것입니다.

특히 지능형 UX 는 UX 향상에 대한 평가 기준이 될 것입니다. 지능형 UX 는 누군가에게 UX 향상에 대해 근거할 수 있는 자료를 지시할 수 있다는 것이기 때문입니다.

   

"기존보다 어떻게 나아졌는데?"

이미 이 질문에서 답은 나왔다고 생각합니다. 누군가 정책의 '결정권자'가 묻는다면 어떻게 하시겠습니까? 바로 지능형 UX 의 정확한 수치적인 데이터를 우선시 할 것입니다.

아마도 대부분의 사용자들은 기존의 UX 를 비판하는 사람은 굉장히 드물기도 합니다. 왜냐하면 자신에게 가장 익숙한 UX 이기 때문입니다. 특히 주의할 것은 자신의 욕심이 오히려 UX 를 망가뜨릴 수 있다는 것입니다. 자신을 위한 UX 인지, 자신이 만든 구렁텅이로 냇물 흐르듯이 사용자가 따라오길 바라는 UX 인지, 진정 사용자를 위한 UX 인지 말입니다.

적어도 필자가 생각하는 UX 는 "사용자는 큰 고민 없이 의도하는 대로 따라가기 쉬운 UX" 가 좋은 UX 가 아닌가 생각합니다. 그것이 지능형 UX 든 감각형 UX 든 상관 없이 말입니다.

하지만 반대로, 이러한 UX 의 향상을 어떻게 표현할 것인지는 누군가에게 "UX 도입의 효과"에 대해서 심각하게 고민할 수 있는 근거 자료가 될 것입니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

우리 회사는 트위터를 오픈하여 회사의 소식과 .NET 뉴스를 전하고 있습니다.

 

http://twitter.com/dxnews

   

저희 이건복 대표 이사님께서 관리하시는 이 트위터를 통해 좋은 정보 많이 얻어가시고, 여러분들과의 좋은 소통의 장이 되길 기대해 봅니다.

'UMC > 엄씨 생각' 카테고리의 다른 글

나쁜 관리자가 프로젝트를 망치고 있다! 정말~?  (3) 2010.03.26
좀 더 UX 에 다가가기  (0) 2010.02.16
.NETXPERT 의 트위터 오픈  (0) 2010.02.09
당신이 생각하는 UX 란?  (8) 2010.02.08
꿈 (Dream)  (0) 2009.03.07
20대 가기전에 취미만들기  (1) 2008.11.03
Posted by 땡초 POWERUMC

댓글을 달아 주세요

※ 아래의 글은 필자의 경험과 필자 나름대로 분류하고 정리한 자료이므로 잘못된 부분은 조언 부탁드립니다. 그리고 필자의 개인적인 견해와 자료는 상업/비상업적인 용도로 인용할 수 없습니다.

 

얼마 전 UX 에 대해 이야기를 나눌 수 있는 기회가 생겼습니다. 그의 이야기를 정리하면 저 또한 아래와 같은 의문이 생기네요.

'같은 UX 일을 하는 사람끼리도 괴리감이 생긴다'    

그럼 이런 의문에서 출발해서 UX 에 대해 다시 한번 고민해 보고, 문제를 분석해 보도록 합시다.

   

UX 란 무엇인가?

많은 사람들은 UX 에 대해 많은 오해가 있는 것 같습니다. UX(User eXperience) 는 직역대로 "사용자 경험"을 향상하기 위함입니다. UX 는 바로 디자인(Design) 요소만의 추구가 아닌, 접근성, 편의성, 사용성 등의 구성 요소가 포함이 됩니다.

하지만, UX 를 접근하려고 시도하는 많은 UX 전문가는 이미 공통된 UX 라는 의미에서 이미 시작점을 잘 찍지 못하기도 합니다. UX 라는 단어는 이렇게 굉장히 많은 요소와 포괄적인 의미를 포함하고 있습니다. 즉, UX 와 관련된 전문적인 일을 하고 있지만, UX 전문가 사이에서도 굉장히 괴리감이 있다는 것입니다.

   

UX 의 잘못된 출발. RIA=UX ?

과연 RIA=UX 인가? 일부 실버라이트(Silverlight) 나 플래시(Flash) 와 관련된 일을 하고 계신다면, 충분히 오해의 소지가 발생할 수 있는 등호식입니다. 이와 유사하게 오해의 소지가 있는 것이 RIA=Silverlight 라는 것이죠. RIA 를 하기 위해서는 실버라이트 또는 플래시 등의 기술이 필요하다는 잘못된 관념을 가지고 있습니다.

 

다시 질문하자면 RIA(Rich Internet Application) 은 무엇인가.? RIA 를 묻는 다면 필자는 트랜드한 용어라고 하고 싶습니다. 이미 예전에 X-Internet 이라는 용어로 인터넷의 접근성, 사용성, 그리고 다양한 디바이스(Device) 를 확장시키기 위한 기술이며, Fat Application 또는 Thin Application 이라고 부르기도 하였습니다. 그리고 .NET 플랫폼의 기술로써 스마트클라이언트(Smartclient) 가 이러한 X-Internet 기술에 포함이 됩니다. 타 플랫폼에서는 X-Internet 기술로 투비소프트(Tobesoft) 의 마이플랫폼(MiFlatform) 과 어도비의 플랙스(Flex) 등이 있지요.

X-Internet 과 RIA 는 무엇이 다를까란 생각을 해보면, 그다지 다른게 없다는 것입니다. 이러한 용어는 시대적인 배경이 따른 것 뿐이지, 추구하고자 하는 목표와 이상은 큰 차이를 보이지 않습니다. 즉, X-Internet 은 기능적인 요소를 초점으로 마케팅했다는 것이고, RIA 는 UX 를 초점으로 마케팅했다는 것 뿐입니다. 새로운 기술을 대중에게 얘기할 때, 무엇을 1번으로 말하느냐는 그 시대와 그 시대의 시장에서 요구하는 것이 달랐다는 것을 알 수 있습니다.

하지만, X-Internet 의 시작은 좋았으나 유행을 일으키지는 못했습니다. 그 대안으로 실버라이트와 어도비(Adobe) 의 기술들은 RIA 와 UX 를 이용하여 마케팅을 함으로써 많은 사용자와 전문가 층에서 각광받고 있습니다. 하지만, X-Internet, RIA, UX 등 이미 범람하는 용어들 속에서 제대로 개념을 찾기란 참 힘들기도 합니다.

   

UX 는 개발과 디자인의 공통 영역?

특히 일부 UX 를 전문적으로 하시는 분의 말을 빌리면, UX 는 개발 영역과 디자인 영역의 공통 분모라고 말을 합니다. 하지만 정말 그럴까요? UX 를 하려면 개발과 다자인을 둘 다 알아야 하는 걸까요? 그리고 UX 를 하려면 개발과 디자인의 올바른 협업이 필요한 걸까요? 다시 한번 UX 에 대해 고민해 볼 필요가 있습니다.

하지만, 필자는 왼쪽 그림과 같은 말을 하는 것부터가 이미 잘못된 UX 개념에 사로잡힌 사람들이라고 말하고 싶습니다. (그렇다고 오른쪽이 정답이라는 말은 아닙니다) 다시 얘기하면, 개발과 디자인 영역간의 협업은 UX 를 수행하는 과정일 뿐이지, UX 자체가 개발과 디자인의 공통 분모가 될 수 없다는 것입니다. 거꾸로, 웹 디자이너가 웹 개발 프로젝트에 투입되었다면 어쩔 수 없이 개발자와 조율하고 협업하는 과정이 불가피 할 테니까요. 

결국, UX 는 너무도 많은 의미를 포괄하고 있고, 자신이 생각하는 UX 에 대해 시작점을 잘못 찍음으로써 UX 의 본질에 대해 다시 원점으로 돌아간다는 겁니다. RIA=UX, UX=RIA 라는 잘못된 개념은 결국 자신의 제한적인 생각의 범위와 제한적인 경험에서 나온 오해일 여지가 큽니다.

UX 가 개발과 디자인의 공통 영역이란 것은 좋은 UX 를 위한 과정일 뿐이지(필요할 수도, 필요 없을 수도), 절대 목표나 의미가 아니라는 의미입니다. 아마도 개발과 다지안의 공통 영역이란 것은 자신의 UX 는 그만큼의 범위 밖에 안된다는 의미겠지요?

일부 UX 세미나를 듣고 있자면, 마치 UX 전문가는 개발 영역과 디자인을 조율해야 하는 선도적이고, 개발 영역 기술까지 알아야 한다는, 다소 권위적인 얘기로까지 들리기도 합니다. 아마도 그런 UX 전문가는 XAML 과 Expression Blend 도구를 이용해서 디자인 해봤다는 말로만 들립니다. XAML(Extensible Application Markup Language) 이 프로그래밍적인 요소의 OOP 와 표현 요소인 Presentation 을 포함하는 기술이니, UX = XAML 로 혼돈하는 것이 아닐까란 생각도 듭니다.

   

UX 도 분석이 필요하다.

일단, 현재 통용되고 있는 UX 라는 의미가 너무 광범위합니다. 좀 더 UX 에 가까이 가기 위해 좀 더 분석이 필요할 것 같네요. 그렇다면 UX 를 좀 더 잘게 쪼개기 위해 우리가 실제로 겪을 수 있는 UX 로 나누어 봅시다.

Web Service UX
쟁점 : 데이터의 효율적 배치, 검색, 직관성
아마도 인터넷을 통해 가장 먼저 접할 수 있는 UX 일 것입니다. 공통된 관심을 집중할 수 있는 방법이나 데이터의 효율적인 배치와 검색 등이 관건일 것입니다. 더불어 서비스에 대해 사용자의 재방문을 유도하기 위해 사용자의 지속적인 좋은 콘텐트와 접근성이 가장 중요할 것입니다.    

Desktop UX
쟁점 : 안정성, 시스템 리소스의 가시성
컴퓨터의 전원을 켜기 시작하면서 경험할 수 있는 UX 입니다. 기본적으로 운영체제(OS) 가 포함이 될 것이고, 운영체제 안에서 돌아가는 브라우저나 보조 응용 프로그램 등, 모든 응용 프로그램이 이 범주에 포함이 될 것입니다.

Mobile UX
쟁점 : 단순함, 직관성, 데이터의 중요도 분리 및 표현
최근 아이폰(iPhone) 의 국내 발매로 불붙기 시작한 UX 입니다. 특히 단순하면서도 복잡하지 않는 UX 가 필요로 할 것입니다. 아마도 필자가 Windows Mobile 6.1 을 쓸 때의 느낌은, "이거 데스크탑 OS 와 비슷한데?" 라는 복잡함을 느꼈다면 적어도 필자에게는 좋은 Mobile UX 가 아니었다는 것입니다.   

RIA UX
쟁점 : 가볍고 빠른 응답성, 상호작용 향상, 표현력
최근 각광 받고 있는 UX 입니다. HTML 로 표현하기 힘은 콘텐트나 데이터, 그리고 화려함을 더해줄 수 있는, 진정한 Rich 함이 필요로 하는 UX 입니다. 잘 알고 있는 Microsoft 의 실버라이트(Silverlight) 와 Adboe 의 플래시(Flash) 가 대표적인 RIA 기술입니다.    

Surface UX
쟁점 : 제한된 입력장치로 사용자 접근성, 효율성
아직은 크게 주목 받고 있지는 않지만, 장차 큰 범주의 UX 가 될 것입니다. 제한적인 입력장치로 인해 특히 사용자의 사용성을 크게 고려해야 할 것입니다. 아마도 필자는 일부 Surface UX 를 경험하면서 '이게 누르는 버튼인건가?', '어떻게 쓰는 거지?' 라는 괴리감을 줄이는 것도 좋은 UX 가 될 수 있는 길일 것입니다.    

Enterprise UX
쟁점 : 데이터의 배치, 복잡성을 단순화할 방안, 데이터 표현의 표준적인 방안
아마도 좋은 UX 를 만들기 가장 힘든 환경이 아닐까 합니다. 특히 데이터 중심의 복잡한 환경에서 데이터를 어떻게 배치할 것인지, 특히 복잡성을 어떻게 줄일 것인지의 고민이 필요합니다. 그리고 데이터와 표현의 올바른 정의가 절실하기도 합니다.

   

올바른 UX 향상을 위하여

위의 여러 가지 UX 의 장르로 구분하였지만, 각각의 UX 는 독립적인 UX 는 아닙니다. 예를 들어, Web Service UX 를 향상하기 위해 RIA UX 가 필요할 수 도 있다는 것입니다. Enterprise UX 에서 복잡한 데이터를 단순화 하기 위해 RIA UX 가 필요한, 즉, 각 UX 는 각 장단점을 보완할 수 있는 UX 라는 겁니다.

아래는 각각의 UX 의 단점을 보완할 수 있는 예 입니다.

  

Web Service UX

RIA UX

Enterprise UX

단점을 보안하기 위해

RIA UX
Mobile UX

Mobile UX
Web Service UX

RIA UX
Web Service UX

그리고 자신의 UX 장르가 무엇을 필요로 하냐는 것입니다. 즉, 각 UX 장르별로 무엇이 UX 를 떨어뜨리는 요인이 되냐는 것입니다. 그 문제의 요인을 제거하는 것이 근본적인 문제이며, 다른 장르의 UX 의 사례를 적용하여 UX 를 향상한다면 더할나위 없을 것입니다.

 

결론적으로, 현재 자신의 UX 위치를 잘 알고 그 UX 를 향상시키기 위해 무엇이 필요하냐는 것이 UX 향상의 쟁점이 될 것입니다. 필자 나름대로, Web Service UX, RIA UX, Enterprise UX 등으로 분류하였지만 자기 나름대로의 큰 범위의 UX 를 정립하기 위해서는 그것을 이루는 구성 요소를 정리, 정의해야만 올바른 UX 향상의 지름길이 될 것입니다.

개발자 출신인 필자도 개발에 필요한 구성 요소의 기반 기술의 이해가 부족할 때는, 스스로의 시야를 자신의 경험에 가려버렸던 적이 많습니다.

많은 UX 전문가에게도 말하고 싶은 것은, 당신이 실버라이트와 플래시를 해서 UX 디자이너, UX 전문가 인가요? 그렇다면 다시 묻겠습니다.

  • UX 란 무엇인가요?
  • 좋은 UX 란 무엇인가요?
  • 좋은 UX 를 위해 무엇이 뒷받침이 되어야 할까요?
  • 그렇다면 좋은 UX 를 위해 무엇을 실천했나요?

위의 물음에 자신만의 올바른 정의가 없다면, UX 가 아닌 당신은 단지 디자이너(Degisner) 일 뿐입니다. 저는 개발자를 분류하길 핵심 개발자(Core Dev), 일반 개발자(Dev) 로 분류합니다.  개발자인 필자의 눈에는 마찬가지로, UX 디자이너와 일반 디자이너 두 가지 밖에 없습니다. 

하지만 다행인 것은, 마치 .NET 기술이 처음 나왔을 때 처럼, UX 또한 아직 많은 정보를 접하기 힘든 황량한 사막과도 같다는 것입니다. 끊임 없는 고민과 노력은 분명 UX 성숙기 시대에 접어들 때, 빛을 발하리라 의심치 않습니다.


다음 글
[UMC/엄씨 생각] - 좀 더 UX 에 다가가기

'UMC > 엄씨 생각' 카테고리의 다른 글

좀 더 UX 에 다가가기  (0) 2010.02.16
.NETXPERT 의 트위터 오픈  (0) 2010.02.09
당신이 생각하는 UX 란?  (8) 2010.02.08
꿈 (Dream)  (0) 2009.03.07
20대 가기전에 취미만들기  (1) 2008.11.03
입문자에게... "프로그램 공부 어떻게 해야 하나요?"  (1) 2008.01.27
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 천상태자 2010.02.08 09:48 Address Modify/Delete Reply

    좋은 내용이네요.
    위에 언급한 내용중에 RIA = Silverlight, RIA = Flash 이렇게 인식하는 사람들 때문에 애를 먹습니다. 물론 Silverlight과 Flash의 기술로 밥 벌어 먹구는 있지만, 이것을 안쓰면 RIA가 아니라는 생각을 가시진 분을 설득하는 것이 참 힘듭니다. 당장 제가 몸 담고 있는 회사에서도 그렇습니다. Javascript로 만들면 완전 무시하기도 하고 화려한 액션이 들어가지 않으면 RIA가 아니다 라고 말씀하기도 합니다. 이런 것들이 쏟아지는 용어를 이용한 업체들의 마케팅 전략에 의한 결과가 아닌가 합니다. 바른 용어의 정착이 우선되어야 할 듯하네요.

  2. 박중석 2010.02.08 10:55 Address Modify/Delete Reply

    막연하게 받아들여지고 있는 부분에 대해서, 좋은 자극이 되는 글 잘보고 갑니다~

  3. 열이아빠 2010.02.08 11:20 Address Modify/Delete Reply

    RIA=UX 라는 개념이 처음 등장했을때에는 그것이 마케팅적으로도 먹혀들어가는 개념이었고 또 기술적으로도 좀 더 쉬운 도구가 등장했던 것이기때문에 정착이 되지 않았나 생각됩니다. 일반 드라이버와 전동 드라이버는 같은 기능을 수행하지만 성능이나 확장성 면에서 차이가 있습니다.
    이제는 시간이 지나면서 다양한 플랫폼들이 등장했지만 트렌드를 선점해버린 업체들때문에 인식을 바꾸기가 힘든 상태가 되어버린것이지요.
    드라이버 비유에서도 이야기했지만 적절한 것을 선택하지 않는다면 나사만 뭉개져 버린다는..^^

  4. 짱묜 2010.02.08 13:00 Address Modify/Delete Reply

    어느 세미나를 들으셨길래 ㅋㅋ
    오히려 제가 참여하는 UX관련 스터디나 세미나에서는 블렌드는 언급을 안하는 경우가 많던데요.
    OS와 툴에 종속적이지 않기 때문에.. 그리고 개발과 디자인의 공통분모가 UX다 라고 생각한다는 것이 좀 이상합니다~ 무튼..ㅋㅋ 잘봤어 오빠~~

  5. 박건태 2010.02.08 15:34 Address Modify/Delete Reply

    제 생각에는 UX는 개발, 디자인 어느 영역의 것도 아닙니다. UX 디자이너 라는 말로 흔히 UX 가 디자이너의 것으로 착각하는 경우도 있지만 여기서 UX Designer 는 그 디자이너가 아니라 설계자라고 해야 맞을 겁니다. 사실 많은 UX Designer 라고 하는 사람들이 단지 UI 디자이너일 뿐일 테고요. UX라는 것은 또한 개발자에게는 더더욱 먼 것입니다. 개발자는 코드의 품질과 생산성에만 관심을 가지면 되는 것입니다. 구지 UX까지 고려해야 할 필요는 없습니다. 현재 우리나라의 많은 디자이너와 개발자들이 UX 에 관심을 가지고 UX에 대해 고려해야 한다고 생각하는 것은 이런 사람들이 대부분 PM 이나 기획의 일을 상당부분 같이 담당하고 있기 때문입니다. 사용자 경험에 맞춘 개발, 사용자 경험에 맞춘 디자인을 하려면 먼저 사용자 경험이 무엇인가부터 알아봐야 합니다. 하지만 "사용자들은 보통 이런게 편할꺼야" 하는 주관적인 생각이 앞서기 쉽죠. 그러면 다시 우리가 생각해야 할 일은 사용자 경험을 어떻게 측정할 것인가로 자연스럽게 Focus가 맞춰지게 됩니다.
    그럼 사용자 경험을 측정하고 측정하는 방법을 연구하고 실제 프로젝트에 적용할 수 있는 사람들은 누구일까요?.. 뭐 답이 구지 한가지는 아니겠지만 최소한 기존의 디자이너,개발자는 아닐 겁니다.
    그리고 우리나라에서는 아직 제대로 UX Designer로 활동하는 사람이 거의 안보이는 것 같습니다. 예전의 Flasher 같은 직업분류가 새로 생겼듯이 앞으로 활동하는 UX Designer 들이 UX 가 제대로 프로젝트에서 성과를 낼 수 있도록 노력해야 하지 않을까 합니다. 그리고 그 이후에야 제대로 UX 라는 말이 단순히 마케팅적으로 남용되는 언어가 아니라 프로젝트에서 꼭 필요한 필수요건으로 대접받을 수 있을 때가 아닐까 싶습니다.

    .. 제가 잠깐 폭주했군요.^^ 요즘에 이부분에 대해 저도 생각이 많다보니..^^ 글 잘 보고 있습니다. 앞으로도 좋은 글 많이 남겨주세요.^^

    • 짱묜 2010.02.08 16:10 Address Modify/Delete

      맞아요~ 저같은 경우에도 사용자 경험에 대한 고민은 기획파트에 서포트 할때 더 많이 했으니까요. 갈길이 멉니다~

꿈 (Dream)

UMC/엄씨 생각 2009. 3. 7. 02:15 |
람은 살면서 많은 꿈을 꾸는 것 같아요. 매일매일 잠자리에서 여러 번의 꿈을 꾼다고 하지만 과학적으로 기억을 못할 뿐이라고 들은 것 같네요. 마치 꿈은 .NET 의 가비지 컬렉션(Garbage Collection)과 같이 기억과 생각을 정리하는 작업이란 느낌이 드네요. 남길 것은 남기고 들어낼 것은 들어내고!
 
꿈은 미래에 대한 자아를 계획하고 실천하게 만드는 것 같습니다.


그림 출처는 여기


하지만 꿈은 자신을 좌절하게 만듭니다. 꿈을 목표 시일 내에 이루지 못했거나 우리나라 속담과 같이 “뱁새가 황새 따라하다 가랭이 찢어진다” 는 것처럼 능력 이상의 꿈을 꾸면 말이죠. 그래서 스스로 좌절합니다. 물론 그 원인은 단지 가랭이가 찢어지는 이유가 아닌 다른 이유가 될 수 도 있겠죠.
 
꿈을 꾸다가 좌절하고 시련을 맞이하기 됩니다. 좌절과 시련이 힘들긴 하지만 분명한 것은 나쁘지 않다는 것이죠. 더 나쁜건 ‘개구리가 더 높이 뛰기 위해 웅크리려다 뒤로 홀라당 자빠지는 것’ 이죠. 이건 저의 케이스입니다. 10년동안 홀라당 자빠져있다가 이제 좀 해보겠다고 바득바득 말이죠^^
 
해답은 누가 쉽게 주지 않아요. 스스로 받아 들이지 않으면 해답이 아니라 오답이니까요. 그래서 저는 우리나라 최고, 아니 그 중간도 안되지만 언제나 “세계 최고가 될 거라고!” 말한답니다. 그래야 그 절반이라도 목표를 이룰 수 있지 않겠습니까? ^^
 
최근 저로 인해 상처받은 분들이 계시면 이 자리를 빌어 사죄의 마음을 전합니다. 그리고 저에게 상처 주신 모든 분들께 더 좋은 원동력이 되어 고마운 마음을 전합니다.
 
언제나 그렇듯 내가 내뱉는 한마디, 내가 듣는 한마디 한마디는 스스로의 에너지를 소비하는 것 같아요. 모든 에너지는 유한하고 한계가 있기에 모두들 좌절하거나 실망하지 마시고 더 발전적인 에너지가 되었으면 합니다.
Posted by 땡초 POWERUMC

댓글을 달아 주세요

당신은 삶에 활력을 느끼고 있나요? 봄이 되면 파릇파릇 자라나는 꽃들이 눈에 보이는지, 이제 곧 겨울이 올 텐데 눈을 보면 몇 일 내로 질퍽질퍽 해지는 땅을 생각하며 짜증이 밀려오지 않나요? 한 살, 한 살 먹을수록 삶의 경험과 지식은 늘어가지만, 마음의 여유는 점점 없어지는 것 같은 생각이 요즘 많이 듭니다.
 
[그림1] 목포에 살 때 우리 집 앞마당
 
위 사진은 제가 예전에 목포에서 거주하고 있을 때, 우리 집 앞마당을 찍은 거랍니다. 목포에서는 저렇게 눈이 많이 오는 일도 드문 일이었고, 무엇보다 나에게 일어나는 모든 일상에 대해 스스로 관심이 많았기 때문에 사진으로 남기고 싶었답니다. 일상이 여유로웠고, 나 자신이 소중했으니까요…
 
[그림2] 이제 두 달 후엔 나도…
 
이제 서울 생활을 한 지도 몇 년 되어 가는 것 같네요. 이제 곧 내 나이 계란 한판이 되어가는데, 서울에 온 이후로는 그렇게 기억에 남는 일도 없는 것 같습니다. 생활도 바빴고, 내 스스로 여유라는 것을 준 적이 없었기 때문입니다. 지금 스스로 많은 것을 하고 싶었고, 또 그렇게 하려고 노력을 했고,,, 하지만 진정으로 남은 것이 무엇인가 생각이 듭니다.
 
오늘 저와 절친한 형과 가볍게 맥주 한잔을 하면서 문득 이런 생각이 들었고, 얘기해 보았습니다.
마치 사는 것이 먹기 위해 살고, 살기 위해 일하는 것 같다”
내가 뭘 하고 있는지 잘 모르겠더군요. 과연 10년, 20년 후에 스스로 정말 잘 살았는가,, 라는 질문을 해보면서 말이죠.
 
[그림3] 출처 : http://www.donga.com/fbin/output?n=200806180226
 
당장 벌어진 일은 어쩔 수 없겠지만, 이제 시간에 쫓겨서 살지 말아야지 하는 생각이 듭니다. 정말 그 동안 한심했던 것은 컴퓨터 빼곤 뭐하나 취미가 없었다라는 것입니다. 주말에 눈뜨면 바로 컴퓨터부터 켜고, 특별한 일 없으면 컴퓨터를 끄면서 침대에 눕게 됩니다.
 
와우!! 딱 한번 뿐인 인생을 컴퓨터만 매달고 살고 싶진 않아요 ^^;
 
그래서 이제 조금은 한 눈을 팔아 보려고 합니다. 영화에서 많이 보는 장면 처럼 “1주일에 xxx 꼭 하기”
 
가령 예를 든다면,
“1 주일에 한번씩 서점가서 여러 종류의 책 읽기”
“1 주일에 한번씩 맛 집 찾아가기”
“1 주일에 한번씩 안가본곳 가보기”
뭐, 아니면 좋은 취미 카페 같은 곳도 좋을 것 같습니다.
 
좋은 취미 있으면 이 불쌍한 중생을 위하여 한가지씩 알려주세요 흑흑;;
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 거대한아기 2011.09.02 03:18 Address Modify/Delete Reply

    좋은 글 잘 봤습니다-
    20대 초반인 저에게 피가되고 살이 되는 글이네요! 문득 왜 살고 있는 가라는 사춘기의 학생들이 생각할만한 주제로 생각해보다가 답이 안나와 답답해서 인터넷에서라도 답을 얻고싶은 마음에 여기저기 들려보네요 ㅠ

몇몇 분들이 이제 .NET 을 시작하고 공부를 하면서 저에게 이런 문의를 하신 분들이 계셨습니다.
 
닷넷 공부를 어떻게 하세요?”
 
사실 공부하는 방법은 학창시절에서부터 사람마다 너무 다양하기 때문에, 마냥 “열심히 하세요”, “외우세요”, “직접 해보세요” 등등 의외로 성의 없는 답변이 될 수도 있을 것 같아요. 그도 그럴 것이, 달달 외워서 잘 하는 사람이 있기도 하는 반면, 매일 골목 뒷 편에서 같이 놀던 친구들도 시험 때면 성적이 상당히 좋은 사람도 있습니다(이런 친구는 수업 때만 잘 들으면 된다 라고 하더군요^^;).
 
부끄럽지만, 저는 사실 학창시설에 공부를 못했습니다. 공부를 어떻게 해야 하는지도 몰랐고, 더욱 중요한건 관심(?)이 없었습니다. 학업을 열심히 하는 것이 학생의 신분이라면, 전 좋은 학생은 아니였나 보네요. 그렇다고 너무 사춘기의 방황이 심해서 관심분야인 컴퓨터 공부도 내팽겨 쳐 버렸으니까요.
 
궁금해 하시는 분들도 계셔서 제가 지금까지 봤던 책을 나열해 봅니다. ( 프로그램과 관련 없는 책은 제외입니다 무작위 순서 )
 
l Taeyo’s ASP.NET V1.0 ( 영진출판사, 김태영 저 )
l ASP.NET 으로 구현하는 블로그 프로그래밍 ( 가남사, 장현희 저 )
l ASP.NET Website Programming ( 정보문화사, 김태역 역 )
l C# 을 이용한 ASP.NET 웹 프로그래밍 ( 크라운출판사, 황인균 저 )
l Effective C# ( 한빛미디어, 김영신 역 )
l 마이크로소프트 ASP.NET AJAX ( ITC, 이광수 역 )
l Visual C# .NET 2005 2nd Edition 실전 프로젝트 ( 영진출판사 최재규 저 )
l C# Programming Bible with .NET Framework 3.0 ( 영진출판사, 최재규 저 )
l XML For .NET ( 정보문화사, 김세현 역 )
l C# 디자인 패턴 ( 정보문화사, 전병선 역 )
l C# Web Sevices ( .NET 리모팅과 ASP.NET 으로 웹 서비스 구현하기 ) ( 정보문화사, 문건웅 역 )
l ASP.NET Distributed Data Application ( ASP.NET 분산 데이터 애플리케이션 ) ( 정보문화사, 강승규 역 )
l Professional ASP.NET Web Services ( 정보문화사, 송영덕 역 )
l 훈스닷넷과 함께하는 .NET Framework 3.0 ( 영진닷컴, 박경훈/서동진 저 )
l PROGRAMMING MICROSOFT WINDOWS WITH C# ( 정보문화사, 김태현/박한돌 역 )
l 찰스페졸드의 WPF ( 에이콘, 최세영/황상철/김인기/신희철 역 )
l Programming WCF Services(한글판) ( ITC, 박경훈 역 )
 
그리 많은 책은 아니지만, 제 경력에 일반적인 책 읽기의 권장량 정도를 본 것 같네요. E-Book(인터넷 PDF 도서)를 포함한다면 더 많은 양이 될 수 도 있습니다. 그렇다고, 이 책의 내용을 모두 독파하고 빠삭하게 마스터 한 것은 아닙니다. 언제나 옆에 끼고, 참고서 처럼 심심할 때 끄집어보고, 생각날 때 보고 하는 책들이 대부분 입니다.
 
1. 입문서는 반드시 마스터 하라.
 
그렇다면, 이 모든 책을 모두 이해하고 정독했느냐? 그렇지 않습니다. 이중에서 입문서 3권만을 6개월 이상 옆에 끼고 살았습니다. 워낙 닷넷에 대한 기초가 없었기 때문에, ASP.NET 과 OOP(객체지향)를 중심으로 공부를 했습니다. BASIC 이나 C 언어에 대해선 어느 정도 수준(?)이 되었으나, 처음 접해보는 OOP 는 내 머리 속을 가장 많이 혼란스럽게 하였고, 더 이상 다른 책들을 보지 못하고 덮어버리게 만든 장본이었답니다.
 
베스트셀러이자 최고의 입문서인 김태영님의 책을 본 후, 스스로 초급 탈출을 외치며 또 하나의 베스트셀러인 장현희님 책을 보았을 때, 너무나도 큰 좌절이었습니다. 장현희님의 책 중반부터 도저히 보고 또 봐도, 이해할 수가 없었기 때문입니다. 바로 이해할 수 없던 이유는, OOP 에 대한 텅 빈 지식 때문이었죠.
 
 
2. 입문서는 눈높이에 맞는 책을 직접 서점에서 골라라.
 
처음으로 김태영님의 책을 인터넷으로 주문하고, 한달 동안 집에 처박혀 공부했습니다. 그리고 두 권의 책을 인터넷으로 주문을 하게 되었죠. 하지만, 이 책 두 권은 OOP 의 기초를 모르고선, 도저히 책의 마지막 장을 찍을 수 가 없었습니다. 바로, 책 한 권으로 모든 것을 마스터한양 자신의 실력을 망각했던 것입니다.
 
당장 서점으로 달려가서 직접 읽어보고 자신에게 맞는 책을 고르세요. 똑같은 수학문제를 놓고, 푸는 방법을 10분 동안 알려준 후, 숫자만 다른 문제를 제시했을 때, 풀지 못하는 사람도 분명 있을 거라고 생각합니다. 또한 응용 문제를 제시했을 때, 손도 대지 못하는 사람도 분명 있을 거라고 생각합니다. 이것은 문제의 답이 중요한 것이 아니라, 문제를 푸는 방법을 배운 10동안 자신에게 맞는 수준으로 배우지 못했기 때문입니다.
 
똑같은 입문서 일지라도, 자신에겐 어렵거나 너무 쉽거나 할 수 있습니다. 어떤 사람은, 책의 글자 크기나, 폰트, 또는 종이 재질, 두께가 마음에 안들 수 도 있습니다. 반드시 입문서는 직접 서점에서 보고, 꾸준히 볼 수 있을 지를 확인사살 후에 구입해도 늦지 않습니다.
 
 
3. 인터넷 검색을 최대한 활용해라.
 
인터넷은 분야를 가리지 않고 많은 정보로 가득차 있습니다. 이 인터넷을 활용하는 두 명의 개발자를 예를 들어 보겠습니다.
 
첫 번째 개발자 - 개발자로서 인터넷을 잘 활용하지 못하는 사람은, 검색을 통해 원하는 답을 찾지 못합니다. 때문에, 옆 사람에게 물어보거나, 커뮤니티 게시판으로 바로 달려가서 질문하는 유형이 되겠습니다.
 
두 번째 개발자 - 인터넷을 잘 활용하는 개발자는 다양한 검색엔진을 통해 자신이 궁금한 질문의 요점을 몇 가지 단어로 추스려내어 검색결과를 통해 문제를 해결합니다.
 
위 두 명의 개발자 중 누가 문제를 빨리 해결할까요? 바로 첫 번째 개발자일 가능성이 큽니다. 단, 옆 사람 또는 자신이 속한 집단의 사람이 그 문제의 해결방법을 알고 있거나, 자신보다 뛰어난 기술을 보유한 사람이어야 할 가능성이 큽니다. 더욱 위험한 것은, 소위 고만고만한 사람들이라면 오히려 잘못된 지식을 배우게 될 가능성이 더 클 수 밖에 없습니다.
 
그럼 인터넷 검색을 어떻게 해야 멋진 해결방법을 얻을 수 있을까요? 만약 “비쥬얼 스튜디오 2008이 제대로 설치가 되지 않습니다” 라는 문제를 얻었을 때, 다양한 단어를 조합하여 검색할 수 있습니다.
 
“visual studio 2008 install error”
“visual studio setup 2008 error”
“vs 2008 install error”
“vs 2008 setup error”
 
좀더 분명한 오류를 유추할 수 있다면, 연상되는(또는 명확한) 단어를 끼워맞춰서 검색하시면 됩니다. 이런 유형의 개발자는 문제 해결의 과정이 오히려 굉장히 느릴 수 도 있습니다. 하지만, 검색을 통해 직접 겪어보지 못한 다양한 문제유형을 간접경험을 할 수 있게 되어, 비슷한 다른 유형의 오류를 보았을 때, 오히려 첫 번째 개발자 보다 빠른 문제해결 능력을 갖출 수 있게 됩니다.
 
참고로 저는 자는 시간 빼고 3일 동안 검색해서 답을 얻은 기억이 있답니다… ㅠ_ㅠ
 
 
4. 관심분야의 RSS FEED 에 가입하라.
 
이쯤 되면, 자신이 어떤 분야에 관심이 있는지, 무엇을 해야 하는지 약간은 명확해 지셨는지요. 인터넷 검색을 통해 원하는 답을 얻는 과정이 반복 되면서 내용이 상당히 유용한 블로그를 자주 접할 수 있을 것입니다. 그러한 블로그는 반드시 즐겨찾기 또는 RSS FEED 를 구독하시기 바랍니다.
 

[그림1] HanRSS 를 카테고리별로 분류하여 사용중인 필자
 
즐겨찾기는 해당 사이트를 방문하기 전에 사이트의 컨텐츠를 확인 할 수 없기 때문에, RSS FEED 를 구독하는 것을 권장합니다. 이렇게 만들어진, RSS FEED 목록은 해당 사이트에 새로운 컨텐츠가 게시되면 자신에게 사이트의 컨텐츠를 통보해 주기 때문에 최신의 내용을 앉은 자리에서 받아 볼 수 있습니다.
 
참고로 저는, 연모를 쓰다가 불편한 감이 있어 HanRss 로 바꾸었답니다.
 
5. 커뮤니티 활동을 하라.
 
이것은 옵션입니다. 이것은 해도 그만, 안해도 그만입니다. 커뮤니티 활동에 적극 참여해도 그만, 눈팅만 해도 그만입니다. 절대 커뮤니티에 목매이지 않아도 됩니다. 오히려 커뮤니티 활동에 너무 적극적이다 보면, 회사 업무에 지장을 초래할 수도 있게 됩니다. 하지만, 커뮤니티 활동을 통해 어떤 이로운 옵션이 있는지 보겠습니다.
 
첫 번째, 커뮤니티 활동의 질문답변을 통해 개발자들이 어떤 문제를 겪는지 알 수 있습니다. 특히나, 취업을 앞둔 초보 개발자들이라면 눈여겨 볼 만 합니다. 저 또한 그러했듯이, 실무 개발자들이 부딪히는 문제를 간접 경험할 수 있고, 그것을 해결해 주는 답변 글을 통해 미리 오류 유형을 연습함으로써 미래의(취업후에) 삽질의 시간을 줄여 줄 수 있습니다.
 
두 번째, 온라인, 오프라인을 통해 인맥을 쌓을 수 있습니다. 온라인 게임을 보면, 오프라인이 현실세계라면, 온라인은 가상의 세계라고 합니다. 온라인 게임상 같은 마음으로 뭉친 자신의 집단이 오프라인 모임으로 종종 이어지는 경우가 많습니다. 개발자의 세계도 마찬가지입니다. 여러 사람을 만날 수 있는 기회가 많아질 수 있습니다. 인맥이 왜 중요한지는 더 말 안해도 아실 듯 해서 생략합니다.
 
세 번째, 자신을 PR 할 수 있습니다. 적어도 이 글을 적고 있는 저는, 이왕 이 바닥(?)에 뛰어든 이상 유명해 지고 싶습니다. 평범한 인생은 적어도 저에겐 의미가 없기 때문입니다. 자신이 평범한 개발자로 남길 원하지 않는다면, 반드시 커뮤니티나 블로그를 개설하여 활동하세요. 아마 지금 말한 자기 PR 이 위에 열거한 1~5 번 중에 가장 어렵고 힘들거라 생각합니다. 왜냐하면, 꾸준해야 하기 때문입니다.
 
 
그렇다면 나는 어떻게?
 
위의 5가지 방법은 저의 주관적인 방법입니다. 위의 방법이 도움이 될 사람도 있겠지만, 전혀 그렇지 못한 사람도 있을 겁니다. 자신의 스타일은 자신이 만들어 가는 것이 가장 좋은 공부 방법입니다. 억지로 하는 스터디는 차라리 안하는 것보다 못합니다.
 
무었을 해야할 때, 마음의 준비와 자세가 되어있고, 그것이 잘 되지 않을 때는, 왜 잘 안되는지.. 주변의 어떤 방해요소가 있는 것은 아닌지 살펴보시기 바랍니다. 참고로 어떤 유명하신 분은, 집에 가면 뻘짓을 하게 되어, 회사에 남아서 하고 싶은 것을 하고 막차를 타고 들어간다고 합니다.
 
읽어주시느라 고생 많으셨고요. 새해에 모두 어떤 계획이 있는지는 모르겠지만, 하시는 일 모두 잘 되길 바라면서 이만 줄입니다.
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 박제영 2013.10.31 18:34 Address Modify/Delete Reply

    이제 갖 SI업체에 신입개발자로 취업한 1인입니다..
    비록 게시글은 오래전에 작성된 글이지만 현재 저에게는 피가되고 살이되는 글이군요
    이런 좋은글에 코멘트가 달려있지않아 아쉬운마음에 감사하다는 말 남기고 갑니다.

    4.관심분야의 RSS FEED 에 가입하라.
    즐겨찾기에 추가하였습니다. 종종 들리도록 하겠습니다^^ 현재도 활동하고계신지는 모르겠지만
    앞으로도 좋은글 많이 많이 부탁드려요ㅎㅎ

훌륭한 엔지니어가 좋은 팀장이 되기란 참으로 어렵네요~
다른 개발자에게도 경력이 쌓이고, 이러한 팀장으로의 전환의 시점이 오리라 생각합니다.
그때 힘든 점을 참 잘 묘사하였네요~

기다림의 예술
장점 바라보기 ( 칭찬하기 )
논리와 감성 ( 둘의 적절한 조화 )

살인적인 프로젝트 기간에서의 "기다림의 예술"
1일 짜리 코딩을 1주일 동안 붙잡은 "팀원"

아마 어쩔 수 없을 경우는 좋은 팀장을 포기하고, 못된 팀장이 될 수 밖에 없을 것 같다.
많이 아이러니 하다 ^^;

출처 - http://jamestic.egloos.com/1597503
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 남정현 2010.02.19 19:10 Address Modify/Delete Reply

    훌륭한 엔지니어와 좋은 팀장이라는 두 성분 사이에는 어떻게 보면 전혀 일치하는 공통 분모가 없을지도 모르겠네요. 그래서 더 어려운 것은 아닐까 그런 생각이 드는 글입니다. ^^

2007 DevDays 의 부스에서 정말 신선한 커뮤니티를 발견하였다. 많은 남성 개발자를 설레이게 할 그 이름은 "여자 개발자 모임터" 카페이다.
 
 
이 카폐에 가입을 하기 위해서 엄마나 누나/여동생 주민번호를 도용하는 수 밖에 없을 정도로 남성 개발자의 가입을 철저히 막고 있다. 원래 못하게 하는건 더 하고싶어 지는 법~ ^^
 
간략하게 여자 개발자 커뮤니티에 대해 살펴보자.
 
가입대상 : 여자 개발자 ( 대학생, 신입사원, 직장인 등 )
 
오프라인 활동범위
l BDRS(Beautiful Developer Readership Seminar) : 1년 4회 개최(분기별)
-       책 한권을 선정하여 1박 2일로 공기좋은 펜션에서 건강식을 만들어 먹으며 토론 (추후 실제 코딩 실습예정)
l 주제토론회 - 여자들만의 소수 모임으로 주제토론회를 통하여 스피치 능력을 키움
l 친목도모를 위한 정기적인 정모 및 정팅
 
이곳에 BDRS 후기를 남겨주신 포스팅이 눈에 뛰는군요~
 
이곳에는 주제 토론회 후기를 남겨주신 포스트 입니다.
 
남자임에도 불구하고 여자 개발자 카폐에 가입하고 싶으시다면 아직은 희망이 있어 보입니다.
남성쿼터제를 실시해 달라고 졸라보세요~
 
 
카폐 설립일이 아직 6개월이 안되었지만, 어쨌든 개발자들이 모인지라, 그 열정은 대단해 보인다. 여러 개발 커뮤니티의 오프라인 모임은 주로 남자들이라 선뜻 참여하지 못하는 여성 개발자들이 많으리라 생각한다.
 
그럼 이곳의 문을 한번 두드려 보는건 어떨까??



Beautiful Developer

“여자개발자 모임터”는 여성 특유의 섬세함과 유연성, 감수성을 가지고 있는 스페셜 커뮤니티입니다.



커뮤니티 : 여자개발자 모임터(부제:Beautiful Developer)

설 립 일 :  2007년 5월 24일

◆ 회원인원 : 2007년 11월 20일 현재 780명 이상 



설립 동기

* 개발자라는 직업 속에서 소수의 목소리를 끌어올리기 위해 설립

* 여성개발자들의 커뮤니티 참여율을 높이고자 함

* 회원들과 네트워크를 구축하며 멘토링의 관계를 형성하는 장소

* 여성 특유의 섬세함과 유연성, 감수성을 가지고 있는 스페셜 커뮤니티

* 개발 업무 외에 소소한 일상이야기를 나누는 휴식처


활동 범위

* BDRS(Beautiful Developer Readership Seminar) : 1년 4회 개최(분기별)

   -  책 한권을 선정하여 1박 2일로 공기좋은 펜션에서 건강식을 만들어 먹으며 토론 (추후 실제 코딩 실습예정) 

* 주제토론회 - 여자들만의 소수 모임으로 주제토론회를 통하여 스피치 능력을 키움

* 친목도모를 위한 정기적인 정모 및 정팅

 

우리 커뮤니티는 여자 개발자들을 위한 공간이고 회원들은 대학생, 신입사원, 일명 직장 맘’까지 다양합니다.

대학생들이나 신입 사원들은 경력이 많은 회원들로부터 조언을 받고, 경력자들은 반대로 학생들이나 사회 초년생을 보고 열정을 되찾고자 하는 모임입니다. 각종 세미나 정보 및 여자들만의 정보가 가득한 곳으로 업무 외에도 소소한 일상에 대해 이야기하는 쉼터이기도 합니다.


여자개발자 모임터를 통하여 IT업계에서 마이너리티가 아닌 실력 있는 개발자로 거듭나길 바랍니다.



커뮤니티 주소 : http://cafe.naver.com/womendevel

운영자 블로그 : http://blog.naver.com/mcjura00


Posted by 땡초 POWERUMC

댓글을 달아 주세요

내가 블로깅을 시작하면서 불펌에 대한 인식이 상당히 나빠졌다.
그도 그럴만한것이, 두시간 이상씩 컴퓨터에 바짝 앉아서 열심히 작성한 글이 타인의 불펌에 의해 작성자가 빠져버리고, 검색 사이트로부터 밀려버리면 그 이후엔 더이상 글의 출처가 없어져 버리게 된다.
 
기술적인 문서를 주로 다루게 되는 개발자에게는 특히 타격이 될 수 밖에 없다.
남의 글을 토시 몇 글자 바꾸어서 글쓴이가 바뀌어 버리는 어처구니 없는 상황이다.
 
이전부터 그사람이 그런 행각을 하는지는 알고 있었지만,
최근에는 좀 더 대담한 모습을 보이고 있다.
기술적인 내용을 거의 복사하다시피 작성한 후 자신의 글이 어땠냐고 소감을 남겨달라는 것이다.
 
사건의 내용은 대충 이렇다.
일본 개발자 포털이나 블로그의 글을 그대로 옮기다 시피 한 후 작성자를 바꾸어버린다.
(보기 쉽도록 네이버 재팬으로 번역되는 원문 링크를 걸어놓았다)
 
원문 - http://j2k.naver.com/j2k_frame.php/korean/ufcpp.net/study/csharp/sp3_lazylist.html
도용 - http://blog.naver.com/gboarder/90024126944
 
원문 - http://j2k.naver.com/j2k_frame.php/korean/ufcpp.net/study/csharp/sp3_stdquery.html
도용 - http://blog.naver.com/gboarder/90024126944
 
위의 도용한 사람의 블로그에 보면 상당부분 일본 포털에서 도용된 사실을 알 수 있다.
도용한 문서를 보면 마치 자신이 작성한 것 처럼 제작자와 글이 변형되었다.
 
http://j2k.naver.com/j2k_frame.php/korean/www.atmarkit.co.jp/fdotnet/dotnettips/index/date.html
이곳에 많은 문서들이 자신의 블로그를 통해 자신의 노하우로 둔갑이 되어있다.
 
확인해본 결과 이미 그 사람의 블로그의 대부분의 글이 작성자만 변경된 채, 도용되어 있었다.
 
더욱 뻔뻔한건 기술문서 도용에 앞서 특정 강좌를 시작하겠다는 의지를 드러내기도 했다.
http://www.hoonsbara.com/hoonsboard.aspx?table_name=Free&board_idx=454222&page=2&keyword=&search=&boardmode=2
 
어디선가 본 듯한 글인데.. 라고 생각하다가 네이버재팬을 통해 일본 개발자 포털을 최근 다시 둘러보면서 나에게 덜미를 잡힌 꼴이 되겠다.
 
사실 1~2개의 글이라면 그럴 수 있다고 생각이 되지만, 이렇게 비양심적으로 자신의 블로그를 꾸미고, 커뮤니티 활동은 정말 아니라고 본다.

더욱이 도용된 문서에 대해 저작권을 행사하기도 하였다.

아래의 링크에서 이미
"※ 이 Tip은 제 개인블로그와 훈스닷넷에만 올라옵니다. 만약, 다른 곳에 게시하실 경우에는 출처를 밝혀주시기 바랍니다."
라고 표기하셨더군요~

http://www.hoonsbara.com/hoonsboard.aspx?table_name=cshaptip&board_idx=452642&page=1&keyword=name&search=김영일&boardmode=2

http://www.hoonsbara.com/hoonsboard.aspx?table_name=cshaptip&board_idx=452512&page=1&keyword=name&search=김영일&boardmode=2

http://www.hoonsbara.com/hoonsboard.aspx?table_name=cshaptip&board_idx=452503&page=1&keyword=name&search=김영일&boardmode=2

http://www.hoonsbara.com/hoonsboard.aspx?table_name=cshaptip&board_idx=452500&page=1&keyword=name&search=김영일&boardmode=2
같은 국내 개발자 커뮤니티 회원인지라 차마 말은 못하고 있지만, 이런식으로 여러 사람에게 추앙 받기를 원한다면 결국 제살 깍아먹기 지름길이 아닌가 생각한다.

-- 2007/11/10 Update --
올블로그 메인에 등극 되면서 올블로그와, 마이야후 등 접속이 증가하여 과한 글의 표현을 수정하였다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 미냉이 2012.03.15 16:15 Address Modify/Delete Reply

    정말 면상가죽이 두꺼운 철면피군요 ㅋㅋㅋ