블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

좋은 개발자가 되고 싶어요. 서버 개발자는 어떻게 되나요?


조대협 (http://bcho.tistory.com)


블로그를 운영하면서 자주 받는 질문들이 "좋은 개발자가 되고 싶어요." "아키텍트는 어떻게 되나요?" "서버 개발자가 되려면 어떻게 해야 하나요?" 라는 질문들인데, 일일이 답변을 드리기가 어려워서 생각을 정리해봅니다.





사실 답은 저도 잘 모르겠습니다. 아직 좋은 개발자가 아닌거 같아서요. 그래도 그간 IT를 경험하면서 나름의 생각을 정리해 보면 다음과 같습니다.


좋은 개발자가 되는 방법은 학교에서 다 배웠다.


사실 좋은 개발자가 되는 방법은 학교에서 다 배웠습니다. 대학교 과정에는 IT 개발에 필요한 필수 이론들을 다 배웁니다. 자료구조, OS, 소프트웨어 공학론 등등. 다들 중요한 내용이지만 학교 다닐때는 정작 깨닫지 못하고 소홀해지는 경우가 많습니다.

대학교때 빠졌던 잘못된 생각중의 하나가 "요즘 누가 C를 쓰냐. MFC나 Visual C가 대세 아냐?", "자료 구조는 모하러 배워. 이미 라이브러리들이 다 있는데.." 와 같이 기본을 중요시 하지 않았던 기억이 있습니다.

결국 들어가면 들어갈 수 록 기본으로 가게 되더군요. 다시 공부하려면 시간이 엄청 들져... 얼마전에 빅데이타 공부하겠다고 통계학고 수학책을 사놓고 행렬과 벡터를 다시 파고 있었던 기억이 납니다.


비단 컴퓨터에 대한 전공 수업뿐 아니라, 수학, 법률, 인문학, 경영학등 모든 것이 다 중요하다고 봅니다. 결국 소프트웨어는 이런 것들을 위해서 만들거나 이런것들을 활용해야 하는 것들입니다. 사용자 대상의 서비스를 만들때, 화면 배치 응답 시간에 대한 결정은 인문학과 심리학적으로 사람을 이해하는데 기반하며, 협업을 함에 있어서 상대를 이해하고 스토리 텔링을 하면서 설득하는 것들도 대인 관계 기법과 철학등에서 배워올 수 있습니다. 한비자나 마키아벨리의 군주론이나 노자의 사상들은 팀을 운영하는데 있어서 도움이되는 내용들을 제공합니다.


결국 학교에서의 시간을 소홀하게 하면 안된다는 이야기 입니다.


소프트웨어는 기술이 아니라 협업이다.


근래의 소프트웨어 개발은 기술의 발전 속도가 배우빠르고, 기술의 종류가 많아서 이제는 도저히 한사람이 다 배워서 커버를 할 수 없는 분량입니다. 예전에는 Unix/C만 알아도 대충 왠만한 서버는 개발을 했고, EJB시대만 해도 자바, EJB, 오라클 정도면 대충 서버를 만드는데는 크게 문제가 없었지만, 근래에는 쏟아지는 오픈소스, 스크립트 언어등 기술이 너무많아서 몇가지 기술로만 한다는건 무리입니다. 거기에 빅데이타, 클라우드, IOT, VR, 미디어 서비스등 도메인도 많아져서 혼자서 감당할 수 없는 지식들을 협업으로 풀어야 합니다. 즉 인간관계와 소통과 같은 소프트 스킬이 중요해집니다.


혼자서 모든 개발을 하지 않을거라면, 커뮤니케이션과 협업 방식을 키우는게 대단히 중요 합니다.


알고리즘에 대한 공부는 지속적으로


근래에 소프트웨어 개발에서의 변화는 알고리즘의 중요성이 점점 더 올라간다는 겁니다. 데이타를 저장하고 보여주는 것이 예전의 일반적인 소프트웨어 였다면 근래에는 머신러닝을 이용한 추천, 이미지 인식등 AI 영역을 곁들인 서비스들이 융합이 되고 있습니다. 데이타도 점점 많아지면서 빅데이타를 이용한 분석등이 많이 사용되고 있습니다.

 이러한 AI나 데이타 분석은 기본적으로 데이타 구조나 알고리즘에 기반을 합니다. 그래서 요즘 많은 IT 기업들이 입사 시험에 코딩 테스트나 알고리즘 테스트를 추가하는 것도 일맥 상통하다고 봅니다. 물론 이런 주류를 잘못 이해한 임원들이 기획자나, 프로젝트 메니져, 인프라 엔지니어에게까지 알고리즘 문제를 요구하는게 문제이기는 합니다만

전체적인 큰 흐름으로 봤을때 알고리즘 능력 배양은 앞으로도 점점 중요해질것이라고 봅니다.

 그런데 이러한 알고리즘 문제는 계속해서 접하지 않으면 쉽게 까먹습니다. 미적분을 잘하던 고등학생이 나중에 대학생 되면 다 잊어먹는것과 같은 선상이라고나 할까요. 

지속적으로 알고리즘 문제에 대한 감을 유지하는 것은 중요한 일이 아닐까 합니다.


좋은 환경과 사수를 만나라


조금 실무적인 이야기로 들어가면, 사실 좋은 개발자로 크기 위해서는 좋은 사수와 개발 환경을 만나는게 대단히 중요합니다.

열심히 공부해서 좋은 기업에 입사해서 일년동안 복사만 한 친구와, 직접 Production 시스템에 소스코드를 Commit하고 문제를 해결한 사람 하고는 성장 속도 자체가 다르져.. 그래서 직접 코딩을 하고, 운영 시스템에 반영을 하면서 이에 대한 결과를 모니터링하고 문제를 해결할 수 있는 환경을 접하는게 중요합니다. 


또한 환경이 아무리 잘되더라도, 여러 실패나 실수를 줄일 수 있게 최적의 배움의 경로를 제시해줄 수 있는 좋은 사수가 있는 곳이 가장 좋을것 같습니다. 


물론 스펙이 좋은 회사에 들어가서 커리어를 쌓으면 다음 이동시에 또 좋은 회사로 갈 수 있는 장점이 있지만, 스펙도 좋고 직접 운영 코드에 손도 데고, 좋은 사수를 만날 수 있는 곳은 찾기는 어렵습니다만 분명히 있습니다...


저는 입사를 생각하는 사람들에게는 다른 것은 알아서들 잘 생각들을 하니, 직접 같이일할 사수를 만나보라고 권하고 싶습니다.


직접 짜봐라


소프트웨어 개발은 결과적으로 코드를 짜고 이를 개선해 나가는 작업입니다. 이걸 잘하려면 해봐야져.

직접 무언가를 만들어봐야 합니다. 예전과는 다르게 요즘은 오픈소스 생태계가 좋아서 오픈 소스 생태계에 참여해서 글로벌 개발자들과 협업을 해볼 수 도 있고, 앱 스토어등을 통해서 앱을 직접 퍼블리슁해볼 수 있습니다.

계속해서 무언가를 만들어 나가면 많은 경험이 쌓입니다. 특히나 운영 시스템을 경험해본 사람의 경험치는 남다르다고 할 수 있습니다.  제일 좋은건 몬가 앱을 만들어서 배포 하고 운영해보는게 제일 좋지 않나 싶습니다.


기술의 흐름을 읽어라


마지막으로 기술의 변화를 잘 추적하는게 중요합니다. 항상 그때 그때 마다 기술의 주류가 있습니다. 이런 기술의 흐름을 민감하게 모니터링 해야 남보다 앞서 나갈 수 있는데, 페이스북의 타임 라인에서 자주 언급되는 기술들이나, InfoQ, Dzone과 같은 개발자 사이트에서 자주 언급되는 기술들을 보면 대략 주류라고 생각하면 됩니다. 서버 개발자가 되고 싶다면 서버 개발에 관련된 글들의 흐름을 보고, 앱 개발자면 앱 관련 기술들의 흐름을 보면 됩니다.


그리고 오프라인 커뮤니티 모임에 많이 나가보길 권장합니다. 생각보다 많은 정보를 얻을 수 있고, 나의 위치가 어느정도 되는지 뒤돌아 볼 수 있는 기회가 되기도 합니다.


어떻게 보면 일반론 적인 이야기가 될 수 도 있겠지만, 직군이나 또는 직급에 따라서 집중해야 하는 분야만 차이가 있을 듯 근본은 똑같다고 봅니다. 누가 그러더군요. "물은 물이되 산은 산이로다..". 서버 개발이건, 아키텍트, 프론트 앤드건.. "개발은 개발입니다."


궁금해하시는 분들께 어느정도 도움이 되었으면 합니다.





저작자 표시 비영리
신고

About self organized team

IT 이야기/IT와 사람 | 2015.06.09 18:00 | Posted by 조대협

https://www.scrumalliance.org/community/articles/2013/january/self-organizing-teams-what-and-how

Five essentials of self-organizing teams 


  • Competency: Individuals need to be competent for the job at hand. This will result in confidence in their work and will eliminate the need for direction from above. 
  • Collaboration: They should work as a team rather than as a group of individuals. Teamwork is encouraged. Motivation: Team motivation is the key to success. Team members should be focused and interested in their work. 
  • Trust and respect: Team members trust and respect each other. They believe in collective code ownership and are ready to go the extra mile to help each other resolve issues. 
  • Continuity: The team should be together for a reasonable duration; changing its composition every now and then doesn't help. Continuity is essential for the team. - See more at: 


https://www.scrumalliance.org/community/articles/2013/january/self-organizing-teams-what-and-how#sthash.jKfDKnB5.dpuf

저작자 표시 비영리
신고

소프트웨어를 잘하고 싶으시면 개발자를 그만 뽑으세요.




<사진 : 태극기 휘날리며(영화)中>


간만의 포스팅입니다. 요즘 일도 너무 바쁘고 여유가 안생겨서, 그동안 포스팅을 거의 못했네요. 평소에 생각하던 내용인데, 요즘 들어 소프트웨어니, 서비스니 하면서 여기저기서 사람 뽑는 글들이 많아서 올려봅니다.


"소프트웨어를 잘하고 싶은데, 개발자를 뽑지 말라니??" 의아하게 생각하실지도 모르지만, 낚시 타이틀이 아니라 진정으로 드리고 싶은 이야기 입니다.

제가 해외 개발자들이나 엔지니어들과 일해봤을때, 한국 개발자가 실력적으로 그렇게 밀린다고 생각하지는 않습니다. 문제는 관리입니다.!!

아무리 똑똑한 개발자를 뽑아 놓는다 하더라도, 개발자들이 만들어야 할 소프트웨어의 구조를 잡을 아키텍트가 없고, 프로젝트를 위한 계획과 엔지니어에 대한 배치를 제대로 하지 못하면 개발은 제대로 이루어지지 않습니다.

좋은 아키텍트가 있고, 좋은 프로젝트 메니져와, 프로덕트 오너가 있는것은 두번째 조건이라고 생각합니다. 일단 있어야 합니다.

아키텍트가 기술적으로 실력이 떨어지더라도 아키텍트는 기술적 설계만이 본업이 아닙니다. 비지니스와 개발간을 연결하고 개발자간을 연결해서 전체 시스템에 대한 기술적인 그림을 보고 조율을 합니다.

프로젝트관리자 역시, 프로젝트 일정에 따라서 끊임없이 위험요소를 관리하고 우선순위를 조정해야 하며, 개발자원을 적절하게 투입해야 합니다.


즉 정리해서 말하면, 개발자보다는 제대로된 리더쉽을 갖추는 것이 중요합니다. 외부에서 좋은 리더쉽을 데리고올 수도있지만, 그런 리더쉽이 역할이 있는 팀 구조를 만드는 것이 선행되야하고 그 다음으로 그런 리더쉽을 가지고 있는 사람을 데려다가 배치해야 합니다.


국내 기업들이 소프트웨어를 강화하기 위해서 개발자 모시기에 여념이 없고, 내부적으로 개발자를 키우기 위한 프로그램도 진행하고, 뽑을때 미국 처럼 코딩 시험도 보는데.. 그건 그거고...

전쟁 나가는데 사병만 1000명 뽑으면 모합니까?? 통솔한 분대장도 필요하고 장군도 필요하고... 소총분대 분대장, 박격포 부대 분대장.. 기갑부대 분대장등 각 역할에 따라서 적절한 리더들을 잘 뽑는게 중요하지 않을까 싶습니다.


이제 개발자 그만 뽑으시고, 제대로된 program manager, product manager, architect,scrum master 등등 리더쉽 인력에 눈을 돌려봐야할 시기가 아닌가 싶습니다. 특히나 요즘 처럼 리모트 개발이 용이해지고 인건비 문제로 인해서 중국이나 인도 인력을 많이 사용하고 신기술은 미국에 있는 개발자들과 협업을 하는 지금 이러한 사람들을 잘 아울러서 관리하여 제대로된 소프트웨어를 만들어 낼 수 있는 조율자(Coordinator-코디네이터)의 역할이 앞으로 점점 더 중요해질 것 같습니다.


요즘 개발자 채용 트렌드를 보면 총든 병사들만 가지고 전쟁을 하려고 하는게 아닌가 싶습니다.... (인해전술도 아니고.. )


저작자 표시
신고

개발자의 잉여력

IT 이야기/IT와 사람 | 2013.03.14 23:42 | Posted by 조대협




오늘은 개발자의 잉여력에 대한 이야기를 해보려고 합니다.

잉여력이란... 남는 시간입니다. 근무시간도 좋고 집에서 쉬는 시간도 좋습니다.

개발자라는 특성상, 모두는 아니지만 대부분은 적어도 기술에 대한 흥미를 가지고 새로운 것을 접하는 것을 좋아 하는 특성상, 남는 시간에는 새로운 기술을 접하고 공부하고, 때로는 새로운 것을 만들어내기도 합니다.


이런 잉여력의 산실이 오픈소스와 블로그등입니다.

오픈소스는 누가 시켜서 하는 것도 아니고, 돈을 벌기 위해서도 아니고, 그냥 남는 시간에 재미있으니까는 하는일입니다.

개발자는 꼭 몬가를 시키지 않아도 스스로 공부를 합니다. 

왜 갑자기 이런 이야기를 하는가 하면, 국내 기업의 경우, 개발자의 잉여력을 발휘할 시간이 없습니다. 항상 바쁘기 때문이지요. 사실 문화적인 차이도 있는데, 미국이나 캐나다 같은 국가의 경우 개발자들이 밤샘 근무를 하거나 일이 많은 경우가 한국에 비하면 상대적으로 없습니다.

외국에 계신 분들 이야기를 들어보면 우스게 소리로 "한국 사람이 하루면 할일을, 여기서는 3일동안 한다."라고 하시더군요. 그렇지만 결과적으로 봤을때, 3배 느리게 일하면서도 전세계 IT 선두는 북미권에서 하고 있습니다.

구글도 근무 시간의 20%를 자체 연구나 프로젝트를 할 수 있도록 하는 것을 보면, 잉여력이 개발자와 같이 끊임 없는 공부와 창의력을 요구하는 분야에서 얼마나 중요하게 생각하는지를 알 수 있습니다.


한국 IT 문화도 많이 바뀌어 가고 있습니다. SKP나 KTH 같은 경우 개발자를 위한 많은 행사나 내부적으로 개발자를 중요하게 생각하는 문화가 생겨 나는 걸 봐도 그렇습니다. (KTH는 이제 그런 문화를 계속 볼 수 있을지 모르겠네요..)


일도, 생산성도 좋지만,개발자의 잉여력이 조금 더 발휘될 수 있는 문화가 되었으면 하는 생각에 몇자 적어봅니다.


저작자 표시
신고
요즘 예전의 해왔던 일의 경험을 최대한 쏟아 부어서 열정적으로 일을 하고 있습니다.
서비스도 기획해보고, 분석도 해보고, 딜 네고도 해보고, 사람도 뽑고, 예산 관리도 하고, 일정 조정도 하고 사람 관리도 하고, 테스트도 하고,튜닝도 하고, 설계도 하고, 설득도하고... 코딩 빼놓고는 대부분 다하는 군요..

시점이 바뀌다 보니까는 사람을 보는 눈도 조금 바뀌지 않았나 싶습니다.
요즘 IT 인력, 특히 개발자가 없다 보니까는 개발자 단가는 올라가고, 일의 강도도 쉽게 높일 수 없어지는 것 같습니다. 이제야 제대로 IT 인력들이 대접받기 시작하지 않나 싶은데, 아마 많은 시니어 개발자들이 IT의 길을 떠나거나 앱쪽으로 전향을 하고, 새로운 주니어 인력의 충원이 적기 때문에 한참 노련한 30대 중반 개발자들이 시장에 별로 없습니다.

개발자들이 제대로 된 대우를 받기 시작한것은 고무적인 일이지만
반대로 개발자들에 거품과 허영이 생기는 시기가 아닌가 싶습니다.
프리로 들어와서 일하지 않거나, 무조건 NO라고 이야기 하면서 방어적이거나...
야근... 안하는게 좋습니다. 저도 야근 개인적으로 무지 싫어합니다. 그런데 이런 사람들이 하는 이야기들을 보면 "미국에는 야근 안한다... 월급 많이준다... 등등입니다..."
미국.. 야근 잘~~ 안합니다만 필요하면 합니다... 예전 M社나 O社에 있을때도 같이 야근을 하거나 밤샘을 한일도 많았고, 이 친구들은 일을 조절을 하는 거지 않하는게 아닙니다. 집에 가서도 Conf Call로 회의를 할때가 잦고 문서 만들어와서 아침에 회의하자고 덤벼듭니다.

즉, '일'을 합니다. 자기 일에 대한 프라이드와 Owner ship이 있는데, 한국 개발자들은 떠넘기기, 방어하기에 바쁜것 같고.... 제대로 테스트가 되지 않은 코드로 QA를 밤새게 만들고, 튜닝에 들어가지 않아도 될 비용이 들어가게 합니다.

프로라면 실력을 가지고 자신이 맏은일에 필요한 역량을 발휘해야 하고, Commit한 목표에 대해서 ownership을 가지고 일하는 자세가 필요합니다.

요즘 IT 환경이 조금씩 변화되는 느낌을 받습니다만, 개발자들고 조금 더 프로스럽게 전향하는 모습들이 보였으면 합니다.
아마추어가 환경만 선진화 된것을 원하는 것은 부끄러운 일이 아닌가 싶습니다.

저작자 표시
신고
TAG 개발자

요즘 느끼는 한국 IT의 변화

IT 이야기/IT와 사람 | 2011.04.28 22:15 | Posted by 조대협
근래에 느끼는 것인데, 근래에 한국 IT 가 조금씩 바뀌어가는 것 같다.

첫번째는 대우? 또는 인력의 변화인데.
삼별전자가 기술 내재화를 목적으로 벤더의 협력사 엔지니어나, 벤더 엔지니어, 포탈 개발자들을 닥치는 데로 연봉 올려주면서 데리고 가고 있다. K티는 클라우드 한다고 하더니, 열심히 하는 클라우드 벤처와 망해가던 벤쳐(T?)에 있던 선수들을 데리고 가서 기술을 내재화하는 노력들을 하고 있다. (좋은 현상들입니다.!! 연봉 많이들 올려서 데리고 가세요..)
그리고 요즘 프로젝트를 해보면 SI사 인력들도 다르다... 지금 일하는 SI社 사무실에만 봐도.. 다들 영어 다 잘한다.. 외국 컨설턴트도 종종 보인다.. 영어만 잘하는 것이 아니라 논리적인 사람들이 많아졌다. 한마디로 꼰대님들은 안보이신다는.... ( 옛날에는 나 정도면 그럭 저럭 영어 하는 건데.... 경쟁력 저하.. ㅜㅡ )
이래저래 연봉을 알아보면, 벤더보다 많이 받는 사람들도 부지기수다.. 외국계 회사가면 돈 많이 받는다는 것은 이제 점점 바뀌어 가는듯...

두번째는.. 기술 적응력 향상.
얼마전만 해도 아범이나 에이취!!피!! 등의 벤더 기술들을 선호하던 댁업이 1~2년전부터 오픈소스에 맛을 들이기 시작했는데, 이것이 일시적인 현상으로 보이지 않는다. 물론 벤더 기술을 써야 하는데... 완성도 낮은 오픈 소스를 쓰시고 삽질하시는 어리석은 분들도 많으십니다만.. (필요할때는 써야 됩니다. 저라도 씁니다. 오픈 소스가 만능은 아님..)
여하튼.... 해외에서 어느정도 유행하는 기술들은 어줍지 않게라도 한국에 어느 기업에 적용되어 있다. (잘 적용된건 못봤슴다..)

세번째는... 서비스 문화에 대한 인식 변화..
아직 일반 개발자분들은 느끼지 못하는 부분일 수 도 있는데...(개발자 커뮤니티 사이트들을 보면..)
보통 벤더에서 제품을 구매하면, 엔지니어나 기술지원을 무료로 받을려는 성향이 강했다.
그런데. 1~2년 간 약간 변화가 보이는 듯 하더니, 작지만 서비스는 돈이라는 개념이 조금씩 정립되어 가는 것 같다.
엔지니어가 원래 제품 하루 설치하러가면 보통 100~150정도를 받는다.
예전에는 오히려 성을 내는 사람들이 많았는데.. 요즘은 그려려니 하거나. 좋은 엔지니어를 미리 시간을 사두는 경우도 있다.

제가 느끼는 작은 변화지만..그 오랜 기간 동안 안변화하다가 그나마 근래에 조금이라도 변화가 보입니다. 몇몇 제대로된 생각이 박히신 분들이.. 대기업(갑)에 경력으로 들어가면서 꾸준히 만들어낸 문화의 변화라고 봅니다.

우리도 쉴때 쉬고. 일할때 일하고. 대접받을 때 대접받으면서...
극한의 아이디어와 기술을 짜낼 수 있는 환경이 왔으면 좋겠습니다.
그렇게 될거 같아요..

저작자 표시
신고
트위터에 개발자당 오픈했습니다.
검색하셔서 "#개발자당_" 찾으시면 되구요.아니면 간편하게 http://bit.ly/a7xxk7 링크 클릭하셔도 됩니다.  IT 관련 소식들 같이 공유했으면 합니다.
많이 Follow 부탁드립니다. :)
IT관련 뉴스들 제가 매일 올리고 있으니.. 무한 RT부탁합니다.
신고

JEE7 ??

IT 이야기/IT와 사람 | 2009.06.19 09:18 | Posted by 조대협

J2EE 시절까지는 자바 개발의 주류가 JEE Spec에 기술된 기술 위주였다.
JDBC,JTS,JTA,JMS,EJB,Servlet/JSP etc
그런데, 오픈소스의 활성화와 Spring의 판도 변화로 이것이 완전히 바뀌어 버렸다.
어제 자바스터디 현재 운영자가 번역했다고 보내준 Spring 2.5 책을 쭈욱 읽어봤는데, 이러한 확신은 더 드는 듯 하다.

JEE5.0에서 들고 나온
JSF,EJB3.0,JDO 등은 국내에서는 거의 사용되지 않고
JSF/Spring MVC/Struts,Sping DI & AOP , IBatis,Hibernate와 같은 오픈 소스 조합의 개발이 가장 널리 쓰이는 조합이다.
이런상태에서 JEE6,7등의 스펙이 나오는 것이 더 이상 의미가 있을까?

벤더드링 Spring등을 흡수해서 살을 덧 붙여 나가는 것이 옳지 않을련지..
표준은 많은 사람들이 쓰는 것이 표준이.. 만들어놓고.. 써!! 하는 것은 표준이 아닐것 같은데..

JEE7은 암암리에 개발자들끼리의 표준인 Spring과 오픈소스들의 조합이 아닐까?


저작자 표시
신고
지금까지 delivery한 프로젝트를 생각해보니, 문제가 없이 잘 되었던 프로젝트는 어떤 이유에건간에 (자의든 타의든) 1~2개월정도의 프로토타입핑 시간을 가졌던 것으로 기억된다.
물론 지금 하고 있는 프로젝트 역시 Prototyping을 진행하고 있다.

이 과정에서는 
1.고객의 요건을 분석한후
2.요건을 패턴화 하여 분리한후
3.패턴별로 프로토 타입을 구현한다.
4.그리고 기능/비기능 테스트를 통해서 프로토 타입을 검증한다.

이 과정이 끝나면 아키텍쳐나 시스템에 대한 디자인은 어느정도 이상의 완성도를 가지게 되고, 그 다음부터는 패턴에 따라서 찍어내기만 하고, Task 에 대한 스케쥴 관리만 원할하게 하면 된다.

결국 프로젝트의 성공 여부는 얼마나 검증되고 안정된 아키텍쳐를 초기에 잘 뽑아내는가인거 같다.
오늘 간단한 프로토타입 검증을 하나 하고 나니까는 전에 했던 프로젝트도 생각이 나서...
정리해본다.

저작자 표시
신고
요즘 프로젝트가 바쁘다 보니, 블로그에 포스팅할 시간이 없다.
REST, ROA (Resource Oriented Architecture), Collaboration, Code Review등 포스팅 하고 싶은 것들이 많은데.. 그나마 시간내서 쓰던 포스팅들도 이번달에는 거의 힘든 상태가 되었다. 아마도 다음달이나 되야, 포스팅들이 올라가지 않을까?

이번 글은 어제 저녁에 써놨던 아키텍트,PM,개발자의 차이 중 2번째로 아키텍트에 대해서 이야기 해보고자 한다.

아키텍트

아키텍트는 전체 시스템을 디자인하고 설계하는 역할을 가지는 사람이다.
아키텍처링은 크게 두가지로 나뉘어 지는데 첫번째는 비지니스 아키텍쳐, 다음은 테크니컬 아키텍쳐이다.
비 지니스 아키텍쳐랑, 해당 시스템이 비지니스적으로 어떤 의미를 갖는지에 대한 내용으로 사업 전략,비젼,요구사항 분석과 같은 범주와 관련이 된다. 시스템의 구현 목적은 어떤 비지니스의 목적을 달성하기 위함이다. 사업 전략이야 COO 분들이나, 아니면 비지니스 컨설턴트가 진행을 하기는 하지만, 비지니스 요건을 어떻게 시스템으로 구현하여 효과를 낼지는 IT 아키텍트의 역할이다. 그래서, 비지니스에 대한 아키텍쳐링도 매우 중요하다.
다음이 테크니컬 아키텍쳐인데, 전체 시스템의 그림을 그리고, 비지니스 요건을 충족하기 위한 기술적인 설계를 하는 역할이다.
 강조하고자 하는 바는 비지니스 요건을 잘 이해해야 한다는 것이다.
예를 들어 분산 트렌젝션 요건이 있다고 하자. "주문과 결재" 두가지 기능을 묶어야 할경우, 여러가지 선택이 있다.
XA기반의 분산 트렌젝션을 사용하는 방법, 보상 트렌젝션 처리, 로깅을 통해서 유실분에 대한 처리, 아니면 유실되는 것 데로 놔두는 것...
고급 기능과 아키텍쳐에는 돈이 든다. 물론 XA기반으로 구현하면 좋겠지만, 해당 시스템이 느린 경우 LOCK 경합 문제가 발생할 수 도 있고, 복잡도가 높아지는 만큼 테스팅에 대한 코스트도 높아진다.
 유료 회원 가입 프로세스 경우 차라리 에러가 나는데로 놔두는 것이 비용 측면에서 훨씬 유리할 수 있다. 공짜로 가입되었다고 Complain할 사람은 그리 없으니까는.
 즉. 완벽한 보안 장치를 하기 위해서, 서랍에 자물쇠를 하느냐 몇천만원짜리 지문 인식 장치를 하느냐가 아닐까?

아키텍트의 능력 중에서 중요한 것은

숲을 보는 능력
아키텍트는 전체 시스템을 보는 능력이 매우 중요하다. 개개의 시스템과 구현 방법에 대해서는(나무를 보는 능력) Senior Developer만으로도 충분하다. 전체 시스템을 조망하고, 그 방향을 잡는 조타수의 역할이 아키텍트이다.

기술에 대한 폭 넓은 지식
제대로 된 설계를 하기 위해서는 어떤 기술이 적절한지 장단점과 위험 요소는 무엇인지를 파악해서 적재 적소에 알맞은 기술을 배치해야 한다. 아니면. 결국 벤더 영업이나 마케터 손에 놀아나게된다. 마치 피라미드 그룹에 걸린것 처럼.

현실을 인지하는 능력
아키텍쳐는 현실적이라야 한다. 아무리 좋은 아키텍쳐라도 금액과, 수행하는 팀원의 능력에 맞지 않으면 말짱 도루묵이다. 적절한 시간과 Learning Curve에 드는 시간도 충분히 고려되어야 한다.

그리고 인맥
왠 갑자기 인맥이냐라고 할 수 있지만. 아무리 뛰어난 아키텍트라도 여러 프로젝트를 경험해보기는 쉽지 않다. 인맥을 통해서, 경험을 공유하고, 문서 템플릿, Reference Architecture, Delivery methodology등을 수집할 수 있는 것은 좀더 안정적이고 성숙된 아키텍쳐를 설계할 수 있는 빠르고 확실한 방법을 제공한다.

커뮤니케이션
아키텍쳐는 기존의 아키텍쳐나 이해관계, 또는 새로운 도전등에 대한 반감에 부딪히기 쉽다. 이를 논리적으로 설득하고, 함께 일할 수 있는 협업 분위기를 만드는것 역시 아키텍트의 역할이다.

프로젝트를 하다보면 많은 AA (Application Architect)를 만난다. 프로젝트의 꽃이자 기술의 마지노선이 AA이다.
그런데 국내 AA를 보면, 숲보다는 나무를 보는 경우가 많고, 중반 이후에는 아키텍쳐에 대한 책임을 지지 않으려는 방어적인 자세로 가는 경우를 종종 봐 왔다. 실제적으로 AA에 대한 시간 배정과 역할에 대한 이해가 부족한 면도 있고. AA 들 자체가 좀더 전략적인 사고 를 가질 필요가 있다.

저작자 표시
신고

아키텍트,PM,개발자의 차이...(1)

IT 이야기/IT와 사람 | 2008.12.23 09:39 | Posted by 조대협
PM,아키텍트,개발자.. 모두 프로젝트에서 없어서는 안될 사람들이다.
IT 생활을 하다보니 각자의 역할이 명확하게 다르고 거기에 요구 되는 능력도 다르다는것을 알게 되는데.
반대로 제역할을 못하는 사람들과 일을 하게 되면 참으로 고달퍼 지는건 사실이다.

* 프로젝트 메니져
프로젝트 메니져의 역할은 어떻게든 프로젝트를 성공적으로 끝내는 것이다.
인원이나 일정에 대한 관리뿐만 아니라, 특히 돈 (Budget)과 위험요소(Risk)에 대한 관리가 중요하다.
무엇보다 중요한것은 Communication이다. 고객과의 의사소통과 팀원들과의 의사소통이 가장 중요한 역할이다.
그 과정에서 RISK들이 자연스럽게 도출되고, 각자의 능력을 최대화해줄 수 있는 방법을 찾을 수 있게 된다.

경험상 많은 프로젝트 관리자들을 보면, 정작 자신이 해야할 무언가를 외면하고 엉뚱한것에 매달려서 집착하는 경우를 많이 봤다. 마치 자신의 능력이 부족함을 다른데서 메워 보여 주려는 듯이..
일정 관리는 MS-PROJECT를 그려놓고 일정이 늦었네 마네 하는 것이 아니라, 매주 단위로 각 개발인원의 일정과 작업량을 체크하고 요건의 변화나 위험요소에 따라서 탄력적으로 일정이나 Scope를 조정하는 것이다..
야근 안한다고 쪼는게 아니란 말이지~~

그리고 RISK 관리... 정말 하는 사람들 많이 못봤다. 많은 기법과 쉬운 관리 방법들이 있는데도 불구하고 말이다.
또 다른 PM의 역할중의 하나는 정치와 고객의 요건 변화에서 팀원을 보호하는 일이다. 요건 변화를 무조건 거절하라는 말이 아니라. 요건 변화에서 오는 일정 변경에 대해서 적절하게 평가하고 자원을 할당하라는 말이다.

적어도 내 경험상으로는 그렇다. 야근이 절대 프로젝트 품질에 도움이 되지 않는다.
피치못할 일정때문에 야근은 분명 있을 수 있다. 동감한다. 그런데 그런 집중 근무 기간이 2주가 넘게 되면 생산성에 심각한 문제가 온다.

예전에 시스템 테스트를 45일간 진행한적이 있다. 9시 출근해서 보통 11시~1시 사이에 끝나는 일정이 한달반동안 계속되었다.
처음 2주는 그럭저럭 버텼지만, 그 다음부터 지각하는 사람들이 늘어나고, 일정 진행에 있어서 꼭 있어야할 사람들이 아침에 지각을 하게 되고, 보통 안늦어도 10시정도에 출근들을 하게 되었다. 고객측에서도 야근에 의한 피로로 생각해서 납득을 해줬지만 지친 몸 상태에서 업무를 정작 시작할 수 있는 시간은 11시가 넘어서였고 한 30분정도 업무를 보면 점심 식사 시간이 되었기 때문에, 결과적으로 실제 업무는 1시부터 시작되었다.
그렇게 저녁 늦게 까지 또 야근을 하다보면. (사실 야근이 모든 인원에게 필요한것은 아니었지만. 한국 IT의 이~~상한 문화때문에.... 앉아 있는 일이 많았다.) 몸의 피로도도 올라가고 사기도 저하가 된다. 결국에는 야근을 안하는만 못하다는.. 결과는 내겠지만 그 품질이 보장이 될까?

고객은 항상 무리한 일정으로 무언가를 요구한다... "우린 이 시스템의 성능 테스트를 하고 싶습니다!! 단 3일만에 말이지요.." 당신이라면 받아 들이겠습니까? 안 받아 들이겠습니까?

어떤 TASK를 할때 현재 가용한 RESOURCE를 가지고 프로젝트에 필요한 VALUE를 낼 수 있는지 없는지가 결정의 포인트가 되어야 하리 않을까?

사실 프로젝트 메니져의 커뮤니케이션과 RISK관리 능력에 대해서 정리를 해보려고 했는데.
쓰다보니 야근 이야기에서 욱!! 하는 바람에 이야기가 삼천포로 빠져 버렸다.. ^^;
다음 이야기는 또 나중에 이어서...




저작자 표시
신고
국내 개발자 처우가 그리 좋지 않고.. 일이 힘들다는것들은 다들 공감하실텐데.
이런것들을 고치기 위해서 협회나 정부 또는 갑들이 해야할 일이 무엇이 있을까요?
의견 한번 여쭙고 싶습니다.
신고

IT를 하면서 필요한것...

IT 이야기/IT와 사람 | 2008.07.25 08:50 | Posted by 조대협
언제 한번 시간 나면 정리할려고 했던건데..
마소에서도 요청이 왔었고....
후배 개발자들을 위해서 필요한것들...

VIew & Vision
보는 시야가 틀려져야 한다..
구멍가게 시스템만 개발하다 보면 구멍 가게에 필요한 비젼과 시야만을 가지기 때문에 발전할 수 없다.
한국 개발자들도 세계에서 맹활약하는 사람들이 많다. 결코 한국 엔지니어가 세계 시장에서 뒤떨어지지 않는다..
특유의 성실함과 집요함은 아마 세계 최고가 아닐까?

Passion
열정... 열정없이 하는 일이 재미있고 제대로 될리가 없다..
열정이 가장 중요하지 않을까? 하려고 하는 의지만 있다면 결국은 하게 된다.
연금 술사라는 책에서 나와 있듯이.. "우주는 자신이 간절히 바라는 방향으로 움직이게 된다."

Exprience
경험 역시 매우 중요하다. 특히 IT에서는 기술이나 지식도 중요하지만 이를 실제로 필드에 적용하기 위해서는 여러가지 RISK를 피해가기 위한 경험과 노하우가 중요하다.

Effort
그리고 노력...!!
'못하는 것은 용서해도 안하는 것은 용서 못한다.." 열심히 노력하고 하고자 하는 의지가 없다면 모든 일은 '입으로만 떠드는 것일뿐..' 실행력은 노력에서 나온다.

나중에 시간나면 제대로 글로 한번 정리해봐야 겠다..
신고
들은건 많고 좋은것을 많이 알고 있을때...
RESOURCE (시간과 인력)은 확보하지 않고 기능과 요건만 추가할때...

열역학 제 1 법칙 에너지 보존의 법칙
"우주의 총 에너지 합은 변하지 않는다..."

고로 요건을 추가하고 RESOURCE가 변화하지 않을때, 소프트웨어의 품질은 떨어진다.
프로젝트를 망치기 가장 쉬운방법은 RESOURCE 에 상관없이 많이 욕심을 부리면 됩니다.
신고
어느나라나 개발에서 무리한 야근이 있는것은 자명한 사실인것 같고...
그래서 다음과 같은 오픈소스 정책이 있었으면 좋겠다..

==
이 소프트웨어는 상용이든 무슨 목적으로던지 사용할 수 있으며
단 이 소프트웨어를 개발하는데 사용된 리소스에 대해서 개발 조직이 야근을 할 경우에는
해당 개발자 시간당 수당의 * 1.2를 한 금액을 개발자에게 야근 수당으로 지불해야 하며 주말 근무의 경우에는 *2배의 금액을 지불해야 한다.
 만약 이러한 라이센스 규약을 위반이 적발된 경우 개발자 임금을 소급적용하여 지불하고... 본 소프트웨어의 LIST PRICE의 10배 금액을 배상한다..
등등등
==

이런걸 Apache랑 GPL 라이센스에만 적용해줘도... 개발자들이 살만하지 않을까?
ㅎㅎ

금주에 있을 빡쎈 야근 모드를 생각하면서 아침에 잡담 한줄..

신고

HP 비리...

IT 이야기/IT와 사람 | 2008.02.04 10:07 | Posted by 조대협
드디어 걸렸다.
IT 업계에서 비리 뇌물, 단합이 하루이틀일이 아닌데..
HP가 제일 먼저 걸렸네. 몇년전에 IBM에서도 이런일이 있었는데..
그나마 깨끗하고 룰을 지켜가며 일하는 HP가 이정도였다니.. 나름 충격이네..
한국에서 골프장 사용고객층의 가장 많은 부분이 IT쪽이라니.. 할말 다한거 아닌가?
이글을 보면서.. 내가 영업쪽이 아니라 기술쟁이인것이 한편으로는 다행이고..
이런 비리에 무감각해져있던 내 모습을 되돌아보면서... 자칫하면 큰일나겠다도 싶다..

항 상 이야기 하지만 공급업체가 바뀌어야 하겠지만.. 무엇보다 고객이 가장 많이 바뀌어야 하지 않을까? 아직도 고객 회식자리에는 영업이 회식비 내주러 오는 경우가 종종 있으니.. 이런걸 미안해 하지도 않고 당연시 하는 문화가 이런일들을 계속 만들어 가는게 아닐까?

요즘 들어 고객이 조금씩 더 똑똑해지고 합리적이 되기도 하지만.. 그러나.. 아직도 기술에 중점을 두는 것이 아니라.. 편한것에 중점을 두는데...
해외에 컨퍼런스를 가더라도. 컨퍼런스에는 관심 없고.. 골프장 가는것과 여행에만 관심이 있는것이.. 한국 IT가 젊은 기술자들은 많은데... 결국 발전하지 못하는 것이 아닐까 싶다...

IT는 기술이고, 사람이고 관리이다... 좀더 공부하고.. 좀더 잘할려고 하자.. 밥그릇은 최선을 다하고 공부를 하면 자연히 따라온다... IT는 정치가 아니란 말이다.


==
IT납품비리 수면 위로…HP, 글로벌 명성에 먹칠

세계적인 글로벌 IT 기업이자, 세계 최대 PC 제조사인 휴렛팩커드(HP)의 한국 법인 '한국HP'가 납품을 대가로 총판업체로부터 금품을 받았다가 경찰에게 덜미가 잡혔다.

특 히 납품 비리의 중심에 있는 한국HP 총판 ‘정원엔시스템’을 비롯해 무려 38명이 줄줄이 연루되면서 IT 관련 업계에 파문이 만만치 않을 것으로 예상된다. 또한 투명성이나 윤리 면에서 상대적으로 높은 수준이라고 알려졌던 다국적 IT기업들에 대한 사회적인 평가에도 악영향을 줄 것으로 보인다.

경찰청 사이버테러대응센터는 전산시스템 납품과 관련해 총판업체로부터 금품을 받은 혐의(배임수재 등)로 전(前) 한국HP 공공사업본부장 심모(50)씨를 구속해 검찰에 송치했다고 31일 밝혔다.

또한 경찰은 롯데정보통신 전 대표이사 권모(54)씨와 한국신용정보 전 정보기술(IT)본부장 정모(60)씨 등 2명에 대해 체포영장을 발부받아 전국에 지명수배 했다.

이 밖에도 부사장 함모(45)씨, 공공사업팀장 김모씨 등 을 비롯한 한국HP 임직원 9명, 대표 김모(58)씨 등 한국HP 총판업체 정원엔시스템 임직원 11명, 메리츠증권 이사 정모(45)씨 등 시스템 발주업체 임직원 13명, 전 서울지방항공청장 신모(52)씨 등 공무원 2명을 업무상배임, 배임수재, 뇌물수수 등 혐의로 불구속 송치했다.

이번에 발표된 경찰 수사결과는 지난해 6월 진행한 정원엔시스템 압수수색을 시작으로 드러난 것이다. 당시 업계 안팎에선 2004년 세계적인 글로벌 IT기업 ‘한국IBM’이 9개 공공기관을 상대로 수십억 원대 비자금으로 조직적으로 금품로비 등을 벌이다 적발돼 10여명이 구속된 사건을 떠올리며 ‘제2의 IBM 사태’로 번지는 게 아니냐는 관측이 제기됐었다.

31일 경찰이 언론에 배포한 자료에 따르면 심 본부장 등 HP 임직원 7명은 2003년부터 지난해 6월까지 정원엔시스템으로부터 “높은 할인율로 HP 제품을 받아 고정적으로 시스템 발주업체에 납품할 수 있게 해 달라”는 청탁을 받고 명절 인사비, 카드대금 대납, 전세자금, 여행경비, 여행지원비 등의 명목으로 무려 약 12억 원을 받은 혐의를 받고 있다.

또한 부사장 함씨 등 나머지 HP 임직원 3명은 정원엔시스템에 HP 제품 약 10억 원어치를 공급하면서 5700만원을 임의로 더 할인해 주고 해외 골프여행 등 개인 여행 경비를 대납토록 한 혐의다.

메리츠증권 이사 정씨 등 시스템 발주업체 임직원 13명은 정원엔시스템으로부터 납품 청탁을 대가로 모두 8억7000여만 원의 금품을 받은 혐의를 받고 있다.

이 밖에도 이번에 입건된 공무원 2명은 지난해 9월 구속된 항공안전본부 6급 공무원 양모(42)씨 등 또 다른 공무원 4명과 함께 정원엔시스템으로부터 2억4000여만원의 뇌물을 받은 혐의다. 다만 경찰은 이 중 공무원 3명에 대해서는 “금품 수수 액수가 크지 않다”는 이유로 형사입건하지 않고 기관에 ‘통보’ 조치했다.

납품 과정에서 뇌물 공세를 퍼부었던 정원엔시스템 임직원 11명은 1073억원 규모의 시스템 납품 사업에서 유리한 고지를 차지하기 위해 회사 자금 10억5900만원을 영업활동비 명목으로 수령해 유용한 혐의도 함께 받고 있다. 정원엔시스템은 한국HP의 국내 200여개 총판 중 최대 규모였던 것으로 알려지면서 파장이 만만치 않을 것으로 예상된다.

정원엔시스템이 금품을 제공한 발주업체에는 메리츠증권 뿐만 아니라 롯데정보통신 등 알려진 기업들이 대거 포함되어 있다.

==




신고

'IT 이야기 > IT와 사람' 카테고리의 다른 글

프로젝트를 가장 쉽게 망치는 방법  (0) 2008.07.14
이런 오픈소스 라이센스 정책이 있었으면 좋겠다..  (2) 2008.06.23
HP 비리...  (0) 2008.02.04
깨진 창문 이론  (1) 2007.10.30
프로와 아마추어의 차이  (2) 2007.09.06
평가의 방법  (1) 2007.08.21
TAG HP, IT 비리

깨진 창문 이론

IT 이야기/IT와 사람 | 2007.10.30 09:43 | Posted by 조대협
요즘 어찌어찌 하다 보니 앤드류 헌트의 펜이 되어버렸다.
Pragmatic 시리즈의 저자인데,
요즘 유행하는 Agile 방법론등의 시초가 되는 실용주의 방법론을 외치는 사람이다.

형상 관리, 빌드 자동화 책을 보다가 어찌어찌 해서 실용주의 프로그래머라는 책을 읽었는데.
재미있는 글이 하나 있어서 기록해 놓는다.
이른바 "깨진 창문 이론"

깨진 창문 이론이란, 도시에 있는 한 건물에 창문이 하나 깨지게 되면, 그로 인해서 주변이 지저분해지고 낙서도 많아지고 결국에는 그 지역이 할렘화 된다는 이야기이다.
즉 작은 문제 하나를 방치해 놓으면 모르는 사이에 그것들이 점점 커져서 나중에는 대치할 수 없는 문제가 된다는 이야기다.

소프트웨어 개발이나 인생 살이도 다른게 하나 없는것 같다.
사소한 BUG하나가 나중에 DEFECT(결함)으로 발전하거나 후에 프로젝트의 발목을 잡는 이슈가 될 수 있다.

깨진 창문(자잘한 문제)들은 보이는 즉시 즉시 해결하는것이 좋다.
신고

'IT 이야기 > IT와 사람' 카테고리의 다른 글

프로젝트를 가장 쉽게 망치는 방법  (0) 2008.07.14
이런 오픈소스 라이센스 정책이 있었으면 좋겠다..  (2) 2008.06.23
HP 비리...  (0) 2008.02.04
깨진 창문 이론  (1) 2007.10.30
프로와 아마추어의 차이  (2) 2007.09.06
평가의 방법  (1) 2007.08.21

프로와 아마추어의 차이

IT 이야기/IT와 사람 | 2007.09.06 16:16 | Posted by 조대협

프로는 불을 피우고,
아마추어는 불을 쬔다.

프로는 자신이 한 일에 대해 책임을 지지만,
아마추어는 책임을 회피하려고 급급한다.

프로는 기회가 오면 우선 잡고 보지만,
아마추어는 생각만 하다 기회를 놓친다
.

프로는 돌다리도 두드리고 건너지만,
아마추어는 두드리고도 안 건넌다.

프로는 자신의 일에 목숨을 걸지만,
아마추어는 자신 일에 변명을 건다.

프로는 여행가이고,
아마추어는 관광객이다.

프로는 남의 말을 잘 들어주고,
아마추어는 자기 이야기만 한다.

프로의 하루는 25시간이지만,
아마추어의 하루는 24시간뿐이다.

프로는 뚜렷한 목표가 있지만,
아마추어는 목표가 없다.

프로는 행동을 보여 주고,
아마추어는 말로 보여준다.

프로는 너도 살고 나도 살자고 하지만,
아마추어는 너 죽고 나 죽자고 한다.

프로는 자신에게는 엄하고 남에게는 후하지만,
아마추어는 자신에게 후하고 남에게 엄하다.

프로는 놀 때 최고로 놀지만,
아마추어는 놀 줄 모른다.

프로는 리더(Leader)고,
아무추어는 관리자(Manager)다.

프로는 평생 공부를 하지만,
아마추어는 한 때 공부를 한다.

프로는 결과보다 과정을 중시하지만,
아마추어는 결과에 집착한다.

프로는 독서량을 자랑하지만,
아마추어는 주량을 자랑한다.

프로는 강자에게 강하고,
아마추어는 약자에게 강하다.

프로는 사람을 소중히 하고,
아마추어는 돈을 소중히 한다.

프로는 사람이 우선이고,
아마추어는 일이 우선이다.

프로는 길게 내다보고,
아마추어는 눈앞의 것만 본다.

프로는 해보겠다고 하지만,
아마추어는 안 된다고 한다.

프로는 시간을 관리하고,
아마추어는 시간에 끌려 다닌다.

프로는 구름 위에 뜬 태양을 보고,
아마추어는 구름 위의 비를 본다.

프로는 지는 것을 두려워하지 않고,
아마추어는 이기는 것도 걱정한다.

프로는 번영 의식이 있지만,
아마추어는 편한 의식이 있다.

프로는 "난 꼭 할꺼야"라고 말하지만,
아마추어는 "난 하고 싶었어"라고 말한다.

프로는 메모를 하고,
아마추어는 듣기만 한다.

프로는 "지금 당장"을 좋아하지만,
아마추어는 "나중에"를 좋아한다
.

프로는 꿈을 먹고 살지만,
아마추어는 꿈을 잃고 산다.

프로는 "요령껏, 재주껏" 하지만,
아마추어는 "무조건 열심히"만 한다.

프로는 "me"를 생각하지만,
아마추어는 "me too"를 생각한다.

프로는 only one을 추구하지만,
아마추어는 number one을 추구한다.

프로는 다면 사고를 하지만,
아마추어는 단면 사고를 한다.

프로는 Know-Where를 생각하고,
아마추어는 Know-How를 생각한다.

프로는 질을 생각하고,
아마추어는 양을 생각한다.

프로는 뛰면서 생각하지만,
아마추어는 생각한 뒤 뛴다.

프로의 무대는 그라운드지만,
아마추어의 무대는 관중석이다.

프로는 창조적 괴짜형이고,
아마추어는 노예형이다.

프로는 미래 중심적이고,
아마추어는 과거 중심적이다.

프로는 창조를 하고,
아마추어는 현상을 유지한다.

프로는 발전시키지만,
아마추어는 현상을 유지한다.

프로는 사람에 초점을 두지만,
아마추어는 시스템과 구조에 둔다.

프로는 신뢰를 쌓지만,
아마추어는 통제에 의존한다.

프로는 장기적 관점을 갖지만,
아마추어는 단기적인 전망을 갖는다.

프로는 "왜, 무엇"을 묻지만,
아마추어는 "어떻게, 언제"를 묻는다.

프로는 먼 수평선에 두지만,
아마추어는 시야를 말끝에 둔다.

프로는 자기의 의지에 따라 움직이지만,
아마추어는 현상을 그대로 받아들인다.

프로는 아이디어를 낼줄 알지만,
아마추어는 지적만 할줄 안다.

프로는 존경하는 것을 좋아하지만,
아마추어는 존경받는 것을 좋아한다.

프로는 숲을 보지만,
아마추어는 나무만 존다.

프로는 "올바른 일"만 하지만,
아마추어는 "일을 올바르게" 한다.

프로는 위험을 감수하지만,
아마추어는 위험을 회피한다.

프로는 이끌기 위해 솔선 수범하지만,
아마추어는 주어진 직책에 안주한다.

프로는 삶으로서 영향력을 발휘하지만,
아마추어는 직책으로 영향력을 행사한다.

프로는 사람을 고무시키지만,
아마추어는 기준을 따르라고 한다.

프로는 변화를 추구하지만,
아마추어는 예측과 질서를 추구한다.

프로는 현상에 도전하지만,
아마추어는 현상을 유지한다.

프로는 비전과 전략에 관심을 두지만,
아마추어는 세부적인 계획, 시간표에 관심을 둔다.

프로는 혁신가지만,
아마추어는 행정가이다.

프로는 실질적인 성과에 관심이 있다.
아마추어는 능률에 관심을 둔다.

프로는 철학, 핵심 가치, 공동 목표를 강조하지만,
아마추어는 전술, 시스템, 구조를 강조한다.

프로는 책임부터 생각하고,
아마추어는 권한만을 생각한다.

프로는 공유하려 하고,
아마추어는 독점하려 한다.

프로는 실수를 하고,
아마추어는 실퍠를 한다.

프로는 놀지만,
아마추어는 까분다.

프로는 웃지만,
아마추어는 비웃는다.

프로는 알면서도 모르는 척 해주지만,
아마추어는 모르면서도 아는 척 한다.

프로는 힘들어하지만,
아마추어는 힘들다고 소리친다.

프로는 함께 일하고,
아마추어는 혼자 일한다.

프로는 비판하지만,
아마추어는 비난한다.

프로는 얘기하지만,
아마추어는 떠든다.

프로는 묵묵히 걸어가니지만,
아마추어는 싸돌하다닌다.

프로는 남에게 감사하지만,
아마추어는 남을 감시한다.

그리고,

Pro는 (영락없이) amateur처럼 생겼지만,

Amateur는 (마치) pro처럼 행세한다.


신고

'IT 이야기 > IT와 사람' 카테고리의 다른 글

프로젝트를 가장 쉽게 망치는 방법  (0) 2008.07.14
이런 오픈소스 라이센스 정책이 있었으면 좋겠다..  (2) 2008.06.23
HP 비리...  (0) 2008.02.04
깨진 창문 이론  (1) 2007.10.30
프로와 아마추어의 차이  (2) 2007.09.06
평가의 방법  (1) 2007.08.21

평가의 방법

IT 이야기/IT와 사람 | 2007.08.21 18:46 | Posted by 조대협

오늘 인턴 사원 평가를 했다.
예전 팀장 시절에는 체계가 없어서 제대로된 평가를 한적이 없었는데.
오늘은 인턴사원이지만 평가를 하면서 시니어로써의 무게를 느껴봤다.

하나 얻은 교훈은 "피드백을 할때, 좋은 것을 80%, 나쁜것을 20%" 이야기 하라는 것이다.

맞는말인지, 의미는 잘 모르겠지만, 예전에 내가 평가를 받을때의 느낌을 생각해보면 맞는 말 같다. 사실 피드백에서 나쁜점들이 50%이상 나온다면, 이미 그 사람은 회사에서 존재하기 어려운 사람이 아닐까?
 '칭찬은 고래도 춤추게 한다'고, 업적을 찬양해서 일할 수 있는 동기를 부여하고, 부족한점은 메꿔 나가게 하는것이 메니져로써의 역할이 아닐까?

신고

'IT 이야기 > IT와 사람' 카테고리의 다른 글

프로젝트를 가장 쉽게 망치는 방법  (0) 2008.07.14
이런 오픈소스 라이센스 정책이 있었으면 좋겠다..  (2) 2008.06.23
HP 비리...  (0) 2008.02.04
깨진 창문 이론  (1) 2007.10.30
프로와 아마추어의 차이  (2) 2007.09.06
평가의 방법  (1) 2007.08.21