인생은 아름다워

maven Build 후 wAS 구동시 아래와 같은 오류가 발생.

java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener

구글링 하면 Dependency 설정 문제라고 함.

이클립스의 Deployment Assembly 에서 Dependency 추가하라는 글이 대부부임.

저의 경우 복합적인 문제가 있었음.

1. POM 에 Dependency 설정이 누락이 있었음.  (maven build 시 왜 오류가 안나지?)

2. JAVA_HOME 설정에도 문제가 있었음. ( Path 설정) 이건 Eclipse 가 실행안됨.

3. CATALINA_HOME 설정에 오타가 있었음.

결론은 참조하는 Dependency에 문제가 없는지 확인 철저.

Windows 10 64Bit.

Java 1.8 -> 1.7로Down  함.

재부팅하면 JAVA_HOME 설정이 자꾸 1.8로 변경됨. (환경변수에 1.8이 없는데도..)

환경변수의 Path에서 Java_home을 삭제하고 재부팅후 다시 추가히니 재부팅해도 1.7로 됨.

"독일 4차산업혁명, 핵심은 사람이다"

"4차산업혁명은 지멘스와 보쉬 같은 기업들에게 새로운 기회가 될 수 있습니다. 제조업과 사물인터넷(IoT)이 결합돼 생산성을 높이고, 맞춤형 제조를 통해 더 큰 부가가치를 창출할 수 있기 때문입니다."

제4차산업혁명을 전 세계의 화두로 만든 건 세계경제포럼(WEF)이었다. WEF는 지난 해 1월 스위스 다보스에서 열린 포럼에서 사물인터넷(IoT)과 인공지능이 주도할 4차산업혁명 시대에 대비해야 한다는 메시지를 내놨다.

하지만 독일은 WEF보다 훨씬 먼저 4차산업혁명을 부르짖고, 또 대비해 왔다. 독일은 "변하지 않으면 미국과 중국에게 종속될 수 있다"는 절박한 위기감에 제조업 혁신 프로젝트인 '인더스트리 4.0'을 추진해 왔다.

기자는 인더스트리 4.0에 대한 자세한 얘기를 듣기 위해 독일 현지에서 클라우스 마인처 뮌헨 공대 교수를 직접 만났다. 마인처 교수는 인공지능(AI) 석학이면서 독일 인더스트리 4.0 전문가로 유명하다.

■ "4차산업혁명은 모든 사람들을 위한 움직임"

"4차산업혁명은 고등교육을 받은 고소득 소비자를 위한 것이 아닌, 모든 사람들을 위한 움직임이라고 할 수 있습니다."

4차산업혁명을 얘기할 때 가장 많이 거론되는 것이 인공지능과 IoT다. 특히 인공지능으로 인해 많은 일자리가 사라질 것이란 경고를 하는 사람들이 많다. WEF의 4차산업혁명 관련 보고서의 핵심 메시지도 '일자리의 미래'다.

하지만 마인처 교수는 “독일의 4차산업혁명은 '사람'을 빼놓고 논할 수 없다”고 잘라 말했다.

그는 특히 “4차산업혁명 시대에 일자리가 줄어들겠지만, 그에 맞춰 교육을 받은 사람들이 새로운 일자리를 만들어 낼 수 있다"면서 "그렇게 하기 위해서는 직업 교육이 무엇보다 중요하다"고 강조했다.

마인처 교수는 독일을 대표하는 제조업체 지멘스를 사례로 설명했다. 지멘스는 인더스트리 4.0 프로젝트에 따라 제조업을 뛰어넘어 소프트웨어 공급자로 진화했다. 특히 지멘스는 전통 제조공장을 스마트 팩토리로 전환했다.

하지만 그 과정에서 지멘스는 노동자를 감축하지 않고도 생산성을 8배나 높였다. 근로자와의 소통과 재교육을 통해 이뤄진 결과다.

마인처 교수는 전문가들이 앞다퉈 미래에는 일자리가 없어질 것이라 예측하지만, 일자리는 우리가 걱정하는 것처럼 바로 없어지지는 않을 것이라고 말했다. 그는 4차산업혁명 시대에 맞는 새로운 일자리가 생기고, 산업이 변하면서 전문 분야 바뀌게 될 것이라고 내다봤다.

특히 마인처 교수는 직업 교육의 중요성을 거듭 강조했다. 교육이 바뀌지 않으면 사라지는 직업을 속수무책으로 지켜볼 수 밖에 없기 때문이다.

마인처 교수는 독일 직업학교에 대해 자부심을 갖고 말했다. 그는 "기초적인 교육도 중요하지만, 직업교육이 어떻게 이뤄지는가에 따라서 4차산업혁명을 잘 대비할 수 있을 것"이라며 "4차산업혁명은 고등교육을 받은 사람을 위한 것도 아닌, 우리 모두를 위한 것이어야 하기 때문이다"라고 강조했다.

■ 독일, 제조업과 IT 융합으로 4차산업혁명 이끈다

인더스트리 4.0의 핵심은 제조업과 첨단 IT산업의 융합이다. 사물인터넷(IoT)을 통해 기계가 서로 소통하게 만들어, 높은 부가가치를 창출하는 쪽에 초점을 맞췄다.

이런 전략은 독일의 처절한 현실인식에서 나온 것이다. 제조업이 강한 반면 IT산업 경쟁력이 미국과 중국에 뒤처진 독일이 21세기에 경쟁력을 회복하기 위한 전략인 셈이다.

세계 2차대전 이후 제조업을 발전시켜 왔던 독일은 여전히 화학이나 철강, 자동차, 건설 등 전통적인 산업에서 강점을 보이고 있다. 그러나 IT분야에선 취약한 것이 사실이다.

마인처 교수는 "독일에는 미국처럼 IBM과 애플, MS, 페이스북과 같은 IT기업이 부족하다"며 “이는 인더스트리 4.0이라는 개념이 더 절실했던 이유이기도 하다"라고 설명했다.

2007년 금융위기가 왔을 때도 독일은 쉽게 무너지지 않았다. 중소기업이 탄탄한 버팀목이 됐기 때문이다. 인더스트리 4.0이 대기업과 중소기업 간의 상생 생태계를 강조하는 건 자연스러운 귀결이다.

마인처 교수는 "중소기업이 성장하는 것이 중요하다"며 "인더스트리 4.0은 독일 공학한림원(acatech)이라는 비영리 조직에서 학계와 산업계, 시민단체(근로자)가 함께 논의하며, 아카텍은 정책적인 부분을 정부에게 조언하는 역할을 한다"고 설명했다.

사물인터넷을 활용한 사이버물리시스템 개념도. (사진=독일 인더스트리4.0 최종 보고서)

사물인터넷을 활용한 사이버물리시스템 개념도. (사진=독일 인더스트리4.0 최종 보고서)

대기업이나 정부가 중심이 돼 인더스트리 4.0을 이끌고 있는 것이 아니라, 관련 전문가들이 모두 참여해 공동의 이익을 추구하는 있다는 말이다.

공학한림원은 기술과 과학 분야의 새로운 인재를 육성하는 것을 목표로 하는 동시, 독일 정부에 정책을 제안하고 대중과 소통하는 포럼을 개최하는 등 인더스트리 4.0에서 중요한 역할을 하고 있다.

공학한림원을 이끄는 핵심 인력 중 한 명이 해닝 카거만이다. SAP 회장 출신인 카거만은 공학한림원 공동 회장으로 인더스트리 4.0의 기초를 닦았다. 인더스트리 4.0 워킹그룹이 지난 2013년 최종 보고서를 내놓을 때 공동 회장 역할을 맡았다.

?

해닝 카거만 회장은 오는 29일 지디넷코리아와 국회 4차산업혁명초럼이 공동 주최하는 '독일 인더스트리 4.0을 통해 본 한국형 4차산업혁명 모델' 컨퍼런스에서 기조 발제를 할 예정이다. 카거만 회장은 기조 발제에서 독일 인더스트리 4.0의 추진 과정에 대한 생생한 얘기를 들려줄 예정이다.

헤닝 카거만 공학한림원 회장.

헤닝 카거만 공학한림원 회장.

■ “IT강국인 한국…IT인프라 강점 살려야”

마인처 교수는 한국 산업만의 강점을 살려 4차산업혁명 시대를 대비하는 것이 중요하다고 조언했다.

그는 "한국은 아날로그적인 독일보다 IT기술이 3~4년 더 앞서 있다고 생각한다"며 "한국 사람 대부분은 IT기기를 다루는데 능숙하고, IT인프라도 매우 뛰어난 나라"라고 말했다.

이어 그는 "이같은 환경은 매우 4차산업혁명 시대에 큰 장점이라고 할 수 있다"며 "로보틱 분야에선 강국이고 기술적으로 매우 뛰어난 나라인 한국이 중소기업과 함께 4차산업혁명을 추진해 나가야 한다”고 말했다.

마인처 교수는 트럼프가 내세우는 보호무역주의에 대해서도 강하게 비판했다. 그는 "미국은 IT강국이지만, 트럼프의 관심은 실리콘밸리보다는 공장(제조업)"이라며 "제조업 경험이 부족한 미국이 60년대로 돌아가 제조업을 부흥시키겠다고 하지만 잘못된 생각"이라고 꼬집었다.

그는 "미국이 잘 할 수 있는 IT산업을 키우는 것이 바람직하다"고 말했다.

원문보기:

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20170309174304&lo=z35#csidxc06a8dfd5e439aca8ac0998d4e90a81

구글이 제시한 '관리자의 자격'

2002년 무렵 구글에는 관리자가 없었다. 당시의 구글은 개발자에 의한, 개발자를 위한, 개발자의 회사였다. 그들은 철저히 개발자 중심 문화를 가지고 있었기 때문에 관리자가 필요없다고 생각했을 것이다. 코드를 생산하는 개발자 중심 문화에서 관리자는 잘하면 필요악, 그렇지 않으면 개발자에게 기생하는 부차적 존재로 취급되었을 것이다.

​

개발자 중심의 문화는 구글만의 이야기가 아니다. 2002년에 국한되는 이야기도 아니다. 지금도 미국에서는 코딩 실력이 좋은 개발자가 관리자가 되기를 거부하거나 마음속으로 관리자의 업무를 불필요하게 생각하는 일이 드물지 않다. 지위가 올라가도 코드를 생산하지 않으면 부차적 존재라는 자괴심을 느낄 수밖에 없는 문화다. 그렇기 때문에 좋은 관리자들은 기술로부터 멀어지지 않기 위해서 부단한 노력을 기울인다. 최근 칼럼에서 언급한 개발자 무정부주의(developer anarchy)는 이런 개발자 중심 철학과 문화의 연장선에 놓여있다.

​

관리자의 필요성을 인정하지 않은 구글은 2008년에 한 걸음 더 나아가서 관리자 무용론을 실제로 증명하기 위한 연구를 진행했다. 그걸 증명까지 해야할까 싶지만, 아벨 아브람이 최근 인포큐에 기고한 글에 의하면 구글의 연구는 기대했던 것과 반대의 결론을 도출했다고 한다. 관리자가 쓸모없는 존재가 아니라 팀의 생산성을 담보하기 위한 중요한 요소라는 뜻밖의(!) 결과가 나온 것이다. 

[아벨 아브람 기고 원문 바로가기]

​

팀에 마이너스가 되는 엉터리 관리자가 많은 것은 사실이지만 팀의 생산성을 높이는데 결정적인 역할을 수행하는 좋은 관리자가 존재하는 것도 사실이다. 이것은 우리의 상식이나 경험에 비추어봐도 이해하기 어려운 일이 아니다. 그럼 팀에 도움이 되는 좋은 관리자는 어떤 사람인가? 구글의 연구팀은 좋은 관리자가 가져야 하는 8가지 덕목을 다음과 같이 정리했다.

​

1. 좋은 코치(coaches)다.

2. 팀에게 권한을 양도하며 마이크로매니지를 하지 않는다.

3. 팀원의 성공에 관심을 표명하며 개인적 삶에도 관심을 기울인다.

4. 생산적이며 결과를 중심으로 사고한다.

5. 훌륭한 커뮤니케이션 능력을 가지고 있다.

6. 팀원들이 경력을 키워나가도록 도움을 준다.

7. 팀을 위한 명확한 비전을 가지고 있다.

8. 팀에게 조언을 해주기에 충분한 기술적인 능력을 갖추고 있다.

​

좋은 코치는 스스로 뛰는 사람이 아니라, 선수가 원하는 포지션에서 마음껏 뛰게 해주는 사람이다. 기술 관리자(technical manager) 중에는 자신의 기술적 역량과 판단을 팀원의 것보다 우위에 놓고 시시콜콜하게 명령을 내리는 사람이 있다. 이런 태도는 다음 항목인 마이크로매니지와 연결된다. 팀원이 아니라 자신의 기술력에 의존하기 때문에 팀원을 스스로 생각하는 창의적인 개발자가 아니라 자신의 명령을 오차없이 수행하는 병사로 취급한다. 이런 관리자 아래에서 일하는 개발자가 건강한 동기부여를 가질 리 없다.

​

■ 진정한 개발자 세계에서 관리자는 '상관'이 아니다

​

사소한 부분을 일일이 간섭하고 통제하는 마이크로매니지는 관리자의 그릇과 연결된 문제다. 넷플릭스는 이걸 “통제(control)가 아니라 문맥(context)"이라고 표현했다. 좋은 관리자는 팀원을 통제하는 것이 아니라 팀원에게 필요한 일의 전후맥락을 설명한 후, 믿고 맡긴다. 사소한 통제에 집착하는 관리자는 문맥을 제시할 능력이 없기 때문에 그렇게 하는 것이며, 따라서 관리자로서의 역량이 부족한 것이다. 관리자의 마이크로매니지는 개발자의 생산성을 저해하는 치명적인 독이다.

​

팀원의 개인적 삶에 관심을 갖는 것은 관리자 자신의 취향과 스타일에 달려있는 문제다. 하지만 팀원의 성공에 관심을 갖는 것은 좋은 관리자가 갖춰야 하는 필수 덕목이다. 최근에 나는 회사에서 자신의 팀원과 '경쟁'하는 관리자를 발견하고 전후맥락을 살핀 다음 인사조치를 단행한 경험이 있다. 자기가 가진 권력적 우위를 이용해서 팀원의 아이디어를 자신의 아이디어로 둔갑시키는 관리자를 발견한 것이다. 이건 관리자가 가질 수 있는 모습 중에서 최악이다. 좋은 관리자는 팀원을 이용해서 자기를 돋보이게 만드는 것이 아니라 진심으로 팀원의 성공을 위해서 봉사해야 한다.

​

결과를 중심으로 사고하는 것도 반드시 필요하다. 개인적인 호불호, 지연이나 학연, 아부, 허황된 장담, 소문, 감정에 휘둘리는 관리자는 관리자로서의 자격이 없다. 누가 좋은 품질의 코드를 생산하는가, 얼마나 빠르고 정확하게 일을 마치는가, 어려운 문제를 해결하기 위한 좋은 아이디어를 제안하는가, 다른 사람과 잘 협업하는가, 스스로 할 일을 찾아서 적극적으로 행동하는가, 의사소통을 잘 해서 자기가 하는 일을 투명하게 만드는가. 이런 구체적인 결과만으로 판단을 해야한다. 출퇴근 시간, 휴가, 재택근무, 병가 같은 근태 역시 결과 중심의 사고에 영향을 주지 않아야 옳다.

​

관리자가 좋은 커뮤니케이션 능력을 가져야 한다는 것은 상식이다. 다만 여기에서 말하는 커뮤니케이션은 말을 뉴스앵커처럼 또박또박 유려하게 하라는 뜻이 아니다. 투명하고 솔직해야 한다는 뜻이다. 공감(empathy)하고 공명(resonance)해야 한다는 뜻이다. 아무리 역량이 뛰어나고 성실한 관리자라고 해도 타인의 이야기에 공감할 줄 모르면 팀원에게 고통을 준다. 공감. 8개의 항목 중에서 이게 제일 중요하다. 팀원의 입장과 처지를 자기 것처럼 이해하고, 고민하고, 아파하고, 억울해하고, 분노하고, 노력하고, 기뻐하는 것. 관리자가 가져야 하는 덕목 중에서 제일 중요한 것은 공감능력이다. 이게 핵심이며 여기에 비하면 다른 능력은 모두 부차적이다.

​

명확한 비전과 기술적 능력은 관리자 자신의 역량 문제다. 있으면 좋고, 없으면 아쉽지만 그렇다고 해서 관리자로서의 결정적인 결격사유는 아니다. 비전은 더 위에 있는 디렉터나 CTO에게 빌릴 수 있고, 기술적 능력이 부족하면 팀원들에게 빌릴 수 있기 때문이다(비전을 남에게 빌릴 수 없는 CTO나 임원급 간부는 면도날처럼 날카로운 비전을 스스로 가지고 있어야 한다. 이 주제는 나중에 다루겠다).

​

이상 구글 연구진의 발표내용을 중심으로 관리자의 자격을 살펴보았다. 불만을 품은 직원은 회사를 떠나는 것이 아니라 관리자를 떠난다는 말이 있다. 관리자의 역할이 그만큼 중요하다는 뜻이다. 진정한 개발자 세계에서 관리자는 '상관'이 아니다. 수행하는 일의 기능(function)이 서로 다를 뿐이다. 관리자는 개발자가 개발에 집중할 수 있도록 옆에서 봉사하는 사람이지 개발자를 상대로 명령하거나 독단적으로 판단하는 권력을 가진 사람이 아니다. 좋은 관리자는 이런 사실을 이미 잘 알고 있다. 행여 관리자라는 타이틀을 봉사가 아니라 권력으로 착각하는 사람이 있으면 이 글을 읽고 생각을 바꾸기 바란다. 관리자의 자격은 그 착각이 없는 사람으로 국한되기 때문이다.

원문보기: 

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20170227091914#csidx38d71a6a429c429b2ac9f36c2f2fe9b 

차근차근 살펴볼 만한' 프로젝트 관리 툴 12선

초창기 ABT의 프로젝트 워크벤치(Project Workbench)를 비롯해 소수에 불과했던 프로젝트 관리 도구는 이제 일일이 검토하기도 힘들 만큼 다양해졌다. 사실 모든 프로젝트 관리 도구 검토해 하나의 추천 리스트를 작성하기란 사실상 불가능할 정도다. 그러나 프로젝트 관리자와 팀이 직면하는 여러 니즈와 과제를 해결할 수 있는 PM 도구로 어떤 것들이 있는지 제한적이나마 조명할 필요가 있다. 살펴 볼 가치가 있는 제품 12종을 정리했다. 

Image Credit : Getty Images Bank

- 라이크(Wrike)
- 뷰패스(Viewpath)
- 다펄스(dapulse)
- 프라이어리티 매트릭스(Priority Matrix)
- 프로워크플로우(ProWorkflow)
- 프로젝트 인사이트(Project Insight)
- 업랜드 소프트웨어(Upland Software)
- 프로젝트플레이스(Projectplace)
- 코마인드웨어 프로세스(Comindware Process)
- 프로젝트 포트폴리오 오피스(Project Portfolio Office)
- 오피스 타임라인(Office Timeline)
- 셀로식스(Celoxis)

라이크(Wrike)
라이크(Wrike)는 프로젝트 관리와 협업을 위한 도구를 다양하게 갖춘 애자일(Agile) 업무 관리 플랫폼이다. 라이크는 프로젝트 데이터의 SSOT(Single Source of Truth, 단일 소스 저장소)로 볼 수 있다. 한 조직이 추진하는 여러 프로젝트의 태스크(과업), 마일스톤(중간 목표), 데드라인(마감 기한), 파일, 대화, 상태에 관한 정보를 처리한다. 웹 브라우저나 모바일 장치에서 정보에 액세스 할 수 있다. 또 이들 정보를 유즈 케이스에 맞게 맞춤화 할 수 있는 대시보드와 보고서로 제공한다.

라이크의 강점은 팀 및 역할에 맞춰 정보를 선택적으로 공유할 수 있도록 하는 '선택적 가시성’(Selective visibility) 기능이다. 사용자가 상황에 맞게 아주 개방적으로 또는 내밀하게 조직 체계(Organizations)를 만들 수 있다. 이렇게 체계를 만들면서, 높은 수준에서 프로젝트를 구축하고, 진행 상황을 모니터 할 수 있다. 또 맞춤화 한 상태 보고서를 지원하고, 간트 차트나 표 같은 도구를 이용해 상세하게 정보를 처리해준다.

라이크가 기존 프로젝트 관리 시스템과 다른 점은 '사람이 중심이 되는 협업'이다. 간단히 말해, 라이크는 팀의 작업공간(Workspace)이다. 작업자는 라이크에서 태스크를 생성, 자신 또는 다른 사람에게 할당하고, 이 작업에 관해 체계적으로 대화를 할 수 있다.

전반적으로 라이크는 사용자 경험을 강조하면서, 고객들의 가치 창출 시간을 줄이는데 목표를 두고 있다. 경영진이 볼 만한 추가적인 가시성을 제공하는 한편, 작업자들에게는 업무를 관리하고, 협업하고, 진행 상황을 공유할 수 있도록 하는 유용한 도구다. 종합적인 프로젝트에 쉽게 사용할 수 있다.

뷰패스(Viewpath)
뷰패스(Viewpath)는 프로젝트 활동과 리소스 할당을 하나의 '완전한 그림'으로 관리할 수 있도록 해주는 온라인 애플리케이션이다. 뷰패스의 스케줄링 엔진은 빠른 성능과 엔터프라이즈급 확장성을 제공하며, 또 세일즈포스나 구글 드라이브 같이 흔히 사용되는 앱과 통합돼 있다. 게스트(Guest)와 옵저버(Observer)도 안전하게 무료로 액세스 할 수 있는 기능을 제공하기에 프로젝트 팀이 다른 조직과 쉽게 협업할 수 있도록 해준다.

아울러 뷰패스 고유의 유연성은 폭포수(Waterfall)나 애자일(Agile) 방식으로 손쉽게 프로젝트 활동을 계획을 추적 관리할 수 있도록 지원한다. 또 상태(현황)를 통합된 보고서와 대시보드로 제공한다. 이와 함께 이 앱은 조직 내 어떤 직급의 인물이라도 협업과 워크플로를 단순화할 수 있도록 해주는 계층화 된 기능성을 갖추고 있다. 즉 하나의 과업을 완수해야 하는 개인이나 여러 프로젝트의 일정을 관리해야 하는 팀 리더 모두 유용하게 이용할 수 있다.

다펄스(dapulse)
다펄스(dapulse)는 특히 '다재다능'한 도구 중 하나다. 전세계의 프로젝트 매니저에게 '스위스 아미 나이프'처럼 쓰일 수 있다. 많은 사람들이 다펄스를 프로젝트 관리 도구로 생각한다. 하지만 이를 CRM으로 분류하는 사람들도 있다. 아마 활용 용도가 수백 가지에 달할 것이다. 기획에서 버그 추적 관리, 광고 캠페인 관리, 생산 추적 관리, 고객 프로젝트에 이르기까지 다양한 종류의 업무에 다펄스를 활용하는 기업들도 있다.

다펄스는 프로세스에 초점을 맞춘다. 특정 프로젝트나 태스크에 대해 더 많은 정보를 체계적으로 전달하면(다음 태스크에 다시 이용할 수 있게끔), 관리와 커뮤니케이션의 모든 측면이 개선될 수 있다는 생각에 기반하고 있다.

대다수 프로젝트 관리 도구의 경우 자신의 구조에 사용자의 니즈를 맞추라고 요구한다면, 다펄스는 사용자의 니즈에 맞게 시스템을 구성할 수 있도록 한 직관적이고, 시각적이며, 유연한 플랫폼이다.

프라이어리티 매트릭스(Priority Matrix)
프라이어리티 매트릭스(Priority Matrix)는 업무 능률을 실제로 높이도록 도움을 주는 드문 프로젝트 관리 도구 중 하나다. 단순한 인터페이스 덕분에 마이크로소프트 프로젝트 같이 무거운 도구에 대한 좋은 대체재가 된다. 채팅과 협업 기능이 내장되어 있어 이메일과 미팅을 줄일 수 있다. 또 매니저는 실시간 가시성을 바탕으로 더 효과적으로 업무를 볼 수 있다.

프라이어티 매트릭스의 차별화된 장점은 정말이지 쉽게 사용할 수 있는 프로젝트 관리 솔루션이라는 것이다. 생산성 향상 트레이닝을 제공하고, 아웃룩 및 지메일을 통합 지원한다. 또 맥과 윈도우, 앱, 모바일 모두에서 효과적으로 협업 할 수 있도록 하는 우수한 프로젝트 관리 솔루션이다. 프라이어티 매트릭스는 이 밖에 조직과 팀, 프로젝트 활동을 평가한 생산성 인사이트 보고서 또한 제공한다. 간트, 캘린더, 우선순위를 기준으로 정보를 확인할 수 있다. 전반적으로 팀원들이 원하는 방식으로 일을 할 수 있도록 해주는 유연성 높은 제품이다.

원문보기: 
http://www.ciokorea.com/news/30036#csidx28a17dc86f9330e8f8676a000ed2ad1 

55세 개발자가 막내인 개발팀

- 전규현

얼마전 미국 소프트웨어 회사인 P사의 호주 지사에서 일하고 있는 엔지니어를 만나서 얘기를 나눴다. P사는 본사가 캘리포니아에 있고 전체 개발자 수는100여명이다. 그리 크지 않은 회사지만 20년동안 꾸준히 성장을 해왔고, 소프트웨어 개발자라면 알만한 시스템을 개발하는 회사다.

​

그 회사의 제품군을 알고 있는 사람들은 100여명 밖에 안되는 개발자들이 일하고 있다는 것에 놀랄것이다. 우리나라 소프트웨어 회사라면 20년간 커왔고 전 세계 많은 나라 기업들에서 사용하고 있는 시스템을 만든다면 개발자가 수백명에 육박할 것이다. 하지만 매우 적은 인원으로 효율적으로 개발하고 있다는 것은 놀라운일이다. 그런데 이렇게 효율적인 소프트웨어 회사가 우리나라 밖에는 엄청나게 많다.

​

P사 제품의 코어엔진을 만드는 팀에는 7명의 개발자가 일하고 있다. 그중 제일 고참이 60세라고 한다. 막내는 55세다. 또 관리자의 나이가 가장 어리다. 60세 개발자는 회사 초창기부터 20년간 근무했다. 대충 짐작해도 35년은 엔지니어로 일하고 있는 것으로 보인다. 비단이 회사에만 이런 할아버지 개발자들이 있는 것은아니다. 개발자 본인이 원하고 실력이 된다면 20년, 30년 원하는 만큼 개발자로 일을할 수 있다.

​

우리나라에서는 한 분야에서 오랫동안 한가지 제품만 개발하고 있는 개발자들의 걱정이 있다. 다양한 분야를 접하지 못하다 보니 경험이 제한되고 시야가 좁아지고 엔지니어로서의 가치가 떨어지는 것이 아닌가 하는 우려를 한다. 실제로 금융분야에서 10여년 일한 개발자를 보면 사용하고 있는 프레임워크만 알고 기계적인 코딩밖에 하지 못하는 경우를 종종 본다. 다른 분야도 마찬가지다. 그럼 한 분야에서만 일한 미국의 30년차 개발자도 그럴까? 물론 개인차가 있겠지만 개발하는 문화나 방식이 좀 다르기 때문에 상황은 다르다.

​

P사에서 개발하는 방식을 보자. 눈에 띄는 것은 개발 방법론이 어찌됐건간에 제품을 꾸준히 업그레이드하면서 코딩을 하기 전에 스펙 문서를 자세히 작성해서 전세계 많은 관련자와 세밀하게 리뷰를 한다. 스펙에는 아키텍처도 포함되어있다.  스펙은 개발자끼리만 리뷰를 하는 것이 아니다. 애플리케이션 개발자와 리뷰도하지만 QA엔지어와도 리뷰를하고 기술 지원 엔지니어 등 거의 모든 분야 관련자들과 리뷰를한다.

​

리뷰는 그냥 훑어보는 것이 아니다. 자신이 담당하거나 전문인 분야의 지식을 총동원한 후 검토를 해서 향후 발생할 문제 등을 면밀히 분석하는 것이다. 이 과정에서 아주 기술적인 세밀한 부분까지 토론하고 논쟁한다.

​

이런 과정을 거치면 제품의 완성도는 훨씬 올라가고 아키텍트는 튼튼해진다. 이런 얘기를 들으면 우리도 시간이 충분하면 이렇게할 수 있다고 한다. 하지만 이런 생각은 착각이다. 이렇게 개발을 하기 때문에 적은 인원으로 더 빨리 개발을 하는 것이다. 논어에는 세명이 길을가면 그중에는 반드시 내 스승이 있다고 했다. 철저한 리뷰는 더 좋은 제품을 만들기도 하지만 리뷰를 통해서 많은것을 배운다. 개발자는 본인의 직접적인 경험과 책만으로 배우는 것은 한계가 있다. 여러 개발자와 또 개발자가 아니라도 여러분야의 전문가와 토론하면서 많은것을 배우게 된다.

​

우리나라 개발자들은 흔히 토론, 리뷰에 약하다. 토론의 경험도 적고 막상 토론을 하면 직급으로 누르거나상대방을 공격해서 상처를 주거나 논리적으로 진행되지 않는 경우가 많다. 한두번 이런 일을 겪고 나면 이런 자리는 자연스럽게 피하게 된다. 결국 혼자서 땅굴을 파는 것에 편하게 되고 그렇게 오랜시간 개발을 하다 보면 한 분야의 전문가는 될 수 있어도 다양한 경험과 통찰력을 가진 개발자로 발전하기는 힘들게 된다.

​

또, 주목할만한 것은  소프트웨어 선진국에서는 아주 흔한 근무형태지만 재택근무가 아주흔하다는 것이다. 위에 언급한 모든것의 진행이 온라인 시스템과 화상회의로 이루어진다. 장소에 구애 받지 않고 일하고 회의도 화상회의 시스템을 많이 이용하고 꼭 필요할 때만 회사에 나가도 된다. 이런 재택근무 문화는 개발자에게 일할 기회를 제공한다기보다는 장소에 구애받지 않고 회사가 뛰어난 엔지니어의 도움을 받을 수 있다고해석하는 것이 좋겠다.

​

리뷰도 어차피 대양을 건너 세계 각국 많은전문가와 진행하는 것이기 때문에 한자리에서 같이 일할 필요는없다. 이렇게 뛰어난 엔지니어들이 모이면 서로의 성장에 도움이 된다. 온라인이 아니면 이런 엔지니어들이이렇게 같이 일을할 수 있겠는가?

​

이글을 읽는개발자라면 우리도 환경이 되면 이렇게할 수 있다고 생각할 수 있겠지만 막상 쉽지는 않다. 대부분의 엔지니어가 문서 작성을 코딩하는 것처럼 익숙해져 있고 잘 작성해야 한다. 이런 온라인 협업은 시스템과 문서로 진행이 되기 때문에 문서작성역량은 매우 중요하다. 많이 자세히 작성하는 것이 잘하는 것은아니다. 효율적으로 필요한 핵심 내용을 적절히 작성해야 한다. 고참 엔지니어가 될수록 문서작성능력은 더욱더 중요하다. 나뿐만 아니라 내 주변의 수많은 개발자들 이렇게 일을 할때 30년 이상 개발자로 즐겁게 일할 수 있을 것이다.

원문보기:
http://www.zdnet.co.kr/column/column_view.asp?artice_id=20150326174940#csidx64ddeb08e22380b97797012884d0f26

늙은 개발자의 노래

-임백준

국내에서 개발자의 나이가 40을 넘을 수 없다는 말은 새로운 이야기가 아니다. 주변을 둘러보면 실제로 그런 것 같다. 팟캐스트 방송을 진행하면서 다양한 개발자들을 만날 기회가 있는데 40세가 넘는 사람을 만나는 경우는 거의 없는 것처럼 보인다. 그래서 궁금해졌다. 프로그래밍에 젊음과 열정을 바친 사람들은 40세 생일을 맞이한 이후에 모두 어디로 가서 무엇을 하는 것일까?

​

한국에서 20, 30대를 프로그래밍에 바친 사람들이 40세 이후에 들어갈 수 있는 문은 두 개가 존재한다. 하나는 관리자, 임원, CTO 등으로 나아가는 문이고, 다른 하나는 자영업이나 업종전환으로 나아가는 문이다. 첫 번째 문으로 들어간 사람들도 얼마 뒤에는 두 번째 문을 다시 만난다. 그래서 소수를 제외한 대부분의 사람이 두 번째 문 뒤에 놓여있는 쓸쓸한 세상에서 만나도록 되어있다. 암울한 풍경이다.

​

오랫동안 미국에서 개발자로서의 삶을 살아가고 있는 입장에서 문득 미국의 현실도 궁금해졌다. 미국에서도 개발자에게 40세는 특별한 의미가 있는 것일까? 이러한 질문과 관련해서 유명한 책인 '클린코드'의 저자 로버트 마틴이 자신의 블로그에 '내 잔디밭(My Lawn)'이라는 제목의 명쾌한 글을 올린 바 있다.

​

이 그래프는 마틴이 자신의 글에 인용한 것으로 원본은 피터 네고라는 사람이 운영하는'Peter's Blog'라는 곳에서 확인할 수 있다. 이 그래프에서 파란색 막대기는 스택오버플로우에서 활동하는 프로그래머들의 나이가 분포되어 있는 양상을 나타낸다. 약간 왼쪽으로 치우친 정규분포처럼 보인다. 빨간색 막대기는 해당 나이에 속하는 개발자들의 명성(reputation)의 수치를 나타낸다. 명성은 스택오버플로우가 사용하는 일종의 포인트다. 다른 사용자들에게 “좋아요”를 많이 받을수록, 질문을 올린 사람에게 정답으로 인정받는 답을 많이 올릴수록 점수가 올라간다고 생각하면 된다.

​

그래프에서 볼 수 있는 바와 같이 대학을 갓 졸업한 20대 초반에서 30대 초반에 이르는 나이에 가장 많은 숫자가 분포되어 있고, 30대 후반, 40세 정도의 나이를 전후해서 개발자의 숫자가 눈에 띄게 줄어든다. 미국에서도 개발자들은 40세를 전후해서 두 번째 문을 열고 씁쓸한 풍경으로 걸어 들어가는 것처럼 보인다. 이런, 미국도 한국과 마찬가지인 것일까.

​

마틴은 이 그래프를 통해서 두 가지 중요한 사실을 지적한다. 하나는 40세 이상의 개발자가 급속도로 줄어드는 것처럼 보이는 것이 사실은 20대 개발자의 수가 폭발적으로 늘어나고 있기 때문에 나타나는 일종의 착시효과라는 점이다. 즉, 40세가 된 프로그래머가 개발을 포기하거나 전업하는 것이 아니라 업계로 진출해 들어오는 젊은 프로그래머의 수가 빠르게 늘어나고 있다는 것이다.

​

그가 지적하는 또 하나의 사실은 나이가 많을수록 스택오버플로우의 명성 포인트가 더 높다는 점이다. 그는 이것을 근거로 해서 개발자가 나이가 많을수록, 즉 경험이 많을수록 올바른 판단을 내릴 가능성이 높으며, 따라서 질문을 올린 사람이나 후배 개발자에게 가르쳐줄 내용을 많이 보유하고 있다고 주장한다.

​

내 경험에 따르면 나이와 실력 사이에 직접적인 함수관계가 존재하는 것 같진 않다. 특별히 열정을 품고 노력하는 사람이 아니라면 일한 햇수와 상관없이 실력은 언제나 제자리를 맴돌기 때문이다. 하지만 열정을 잃지 않고 끊임없이 노력하는 사람이라면 실력은 나이에 비례해서 상승할 수밖에 없다. 그렇기 때문에 노력하지 않는 사람에게 나이는 짐이고, 노력하는 사람에게 나이는 훈장이다.

​

미국에서 컨퍼런스나 밋업 모임에 참석해보면 할아버지처럼 보이는 개발자들이 많다. 손자뻘인 친구들과 신기술에 대해서 대화를 나누고, 노트북을 끼고 카페에 앉아 코딩을 하기도 한다. 그리고 직장에서는 어린 개발자들에게 경험을 나누어주며 팀을 리드하는 역할을 맡는다. 내가 꿈꾸는 내 미래의 모습이기도 한데, 특별히 예외적인 모습이 아니기 때문에 ‘꿈’이라고 말할 것도 없다. 미국에서 소프트웨어 프로그래밍은 육신의 건강이 허락하는 한 정년을 두려워하지 않으면서 원하는 일을 할 수 있는 꿈의 직장이다.

​

다시 한국으로 돌아가 보자. 마틴이 보여주는 (파란색 막대) 그래프를 한국의 데이터를 이용해서 다시 그리면 겉보기로는 비슷한 분포가 나타날 것이다. 하지만 20대 개발자의 수에 비해서 40대 개발자의 수가 급격히 줄어드는 이유는 미국에서처럼 젊은 개발자가 시장에 유입되기 때문이 아니라 40세 이상의 개발자가 실제로 시장에서 사라지기 때문일 것이다. 마음속에 열정을 품고 부단히 노력하는 사람이 한국에 미국 이상으로 많다는 사실을 고려하면 이것은 국가적 손실이다. 40세 이상의 개발자는 자기가 쌓아온 실력을 다른 사람에게 나누어줄 기회가 없기 때문에 손실이고, 젊은 개발자들은 곁에서 보고 배울 롤모델이나 현명한 지혜를 가르쳐줄 리더가 없기 때문에 손실이다.

​

어린 학생들에게 SW 교육을 실시한다는 이야기가 나올 때마다 나는 그것보다 더 시급하고 중요한 일이 있다고 말해왔다. 늙은 개발자의 노래 소리가 들리게 만들어라. 온 세상에 큰 소리로. 노래 소리가 충분히 크게 들리면, 아이들은 자연스럽게 SW에 관심을 갖고 모여들 것이다. 나이 든 개발자들은 노래를 부르면서 어린 아이들에게 코딩을 가르치고, 젊은 개발자들에게 지혜를 나누어줄 것이다. 진짜 SW 교육은 그런 것이어야 한다.

​

우리나라에서도 이제 40세 이상의 개발자들이 선택할 수 있는 세 번째 문이 있어야 한다. 평생 개발을 하면서 후배들에게 지혜를 나눠주는 길로 통하는 문이다. 코딩을 하면서 노래를 부르는 문이다. 그렇게 늙은 개발자들의 노래 소리가 들려야, 대한민국이 살 수 있다.

원문보기:
http://www.zdnet.co.kr/column/column_view.asp?artice_id=20150709081046#csidx23cb1051f1b6f1e8c4f7caa130d947b

멘토는 없다 -임백준

가끔 이메일을 받는다. 책이나 칼럼을 읽은 독자 혹은 팟캐스트 청취자다. 메일을 크게 두 개의 그룹으로 나눌 수 있는데 하나는 가벼운 응원의 메시지고, 다른 하나는 장문의 고민상담이다. 후자를 보내오는 사람은 대개 졸업을 앞둔 대학생이거나 전역을 앞둔 군인이다. 미국에서 유학을 마치고 취업을 목전에 둔 사람도 있고, 고등학생도 있다.

​

고민을 토로하는 메일이 대부분 비슷하다는 사실이 흥미롭다. 우선 자기가 어디에서 무엇을 하는 누구라는 소개에서 시작한다. 그리고 요즘 무슨 고민을 하고 있고, 왜 메일을 적는지에 대한 설명이 길게 이어진다. 요지는 취업과 적성에 대한 고민이다. 밤에 메일을 적었는지 갈림길을 마주한 영혼의 불안함이 고스란히 드러난다.

​

그리고 질문을 던진다. 저의 멘토가 되어 주시겠습니까?

​

메일을 받으면 최대한 답장을 보내는 편인데, 이런 메일을 대해서는 침묵한다. 누군가의 멘토가 되고 싶은 생각이 없기 때문이다. 메일을 보낸 진심과 성의는 정말 고맙지만 이런 상담이 나는 불편하다. 이러저러한 분야의 전망은 어떨 거라고 생각합니까. 이런 준비를 해서 저런 회사에 들어가려고 하는데 괜찮을까요. 이런 질문을 받으면 답답하다. 질문에 대해서 대답해줄 능력이 내게 없기도 하지만, 자신의 삶이 걸려 있는 문제를 다른 사람에게 묻는 태도를 받아들일 수 없기 때문이다.

​

멘토라는 말의 사전적인 의미는 본래 우리말의 스승 혹은 사부에 가깝다. 트로이 전쟁에 참전한 오디세우스는 아들을 친구에게 맡기며 대신 키워달라고 부탁했다. 그 친구의 이름이 멘토였다. 오랜 세월이 흘러 집에 돌아온 오디세우스는 훌륭한 청년으로 성장한 아들을 보고 감격했다. 그는 “역시 멘토답군.”하고 탄복했다. 멘토라는 말은 이렇게 시작되었다. 멘토와 멘티의 관계는 이렇게 깊고 무거운 인연을 가리키는 것이었다.

​

요즘에는 멘토라는 말의 의미가 희석되었다. 아무나 멘토고, 아무나 멘티다. 무엇보다도 나는 진정이 담겨야 하는 인간관계에 자본주의적 틀을 덧씌우는 느낌이 들어서 이 표현을 싫어한다. 그것은 아버지와 아들처럼 전면적이고 총체적인 관계를 의미하는 것이 아니라 가벼운 계약관계를 지칭하는 단어로 변질되었다.

​

멘토와 멘티라는 관계가 발설되는 순간, 두 사람 사이에는 암묵적인 권력관계가 성립한다. 그런 권력관계는 ‘물질적 이득’을 토대로 구축된다. 직간접적으로 수업료를 챙기는 멘토만의 이야기가 아니다. 멘티 역시 멘토와의 관계 속에서 이득을 추구한다. ‘배움’이라는 완곡한 표현으로 포장되긴 하지만 권력관계에 자발적으로 발을 들여놓는 멘티의 속마음도 이익을 얻는데 집중된다. 멘토에 대한 인간적인 존경과 애정이 아니라 “그가 나에게 무엇을 줄 수 있는가”가 관심사다.

​

배우고 가르치는 것이 필요 없다는 이야기가 아니다. 오히려 정반대다. 프로그래머들은 자기가 속한 팀에서 자기가 가장 실력이 낮은 사람이 되도록 애쓰라는 격언이 있다. 배울 사람이 없는 팀에서 오래 머물지 말라는 뜻이다. 프로그래머들은 그만큼 배움에 민감하여 주변 사람으로부터 많은 영향을 받는다. 프로그래밍은 책이나 수업보다 다른 사람의 작업을 어깨너머로 보면서 배우는 것이 왕도이기 때문에 개발자들은 배우고 가르치는 관계에 갈증을 느낀다.

​

그런 갈증은 결코 멘토와 멘티로 표현되는 값싼 계약관계로 해결되지 않는다. 그런 갈증을 느끼는 사람에게 멘토는 아무 도움도 되지 않는다. 자신을 누군가의 ‘멘토’라고 소개하는 사람이 있다면 그는 이익을 추구하는 장사꾼, 심하면 사기꾼일 확률이 높다. 멘토는 없다. 그래서 프로그래머가 갈증을 해소하는데 있어서 중요한 것은 멘토를 찾는 것이 아니다. 스스로 마음을 일으키는 발심(發心)이 핵심이다.

​

발심을 개발자 용어로 달리 표현하면 “코딩신을 영접”하는 것이다. 팟캐스트 <나는 프로그래머다>의 내용을 묶은 책에 쓴 표현을 인용해보면 이렇다.

​

“좋은 개발자가 되기 위해서 프로그래밍을 어디에서 누구에게 배우는가는 큰 의미가 없다. 대학에서 컴퓨터를 전공했는지, 학원에서 속성으로 배웠는지, 아니면 회사에서 제공하는 신입사원 교육 프로그램에서 프로그래밍을 처음 접했는지 하는 것은 핵심이 아니다. 그 분을 영접하는 신내림을 받았는가, 받지 않았는가 하는 것이 핵심이다. 그 경험을 하지 않은 사람에게는 밤샘 코딩이 고문 같은 고통이지만, 그 경험을 한 사람에게는 가슴 뛰는 즐거움이다.”

​

코딩신을 영접한 사람의 눈에는 자기에게 가르침을 주는 친구가 사방에 출몰한다. 즐겁게 배우고 행복하게 코딩에 몰두하다보면 어느덧 자기도 누군가에게 가르침을 주고 있음을 깨닫게 된다. 이런 관계는 자연스럽다. 굳이 누가 가르쳐주고, 누가 배우는지 구별할 필요가 없다. 가르치는 사람이 더 많이 배우기도 하고, 배우는 사람이 가르침을 주기도 한다. 그들은 ‘친구’다. 나이, 학력, 고향, 성별, 종교, 성적기호, 언어, 플랫폼, 정치적 입장, 회사, 경력, 이런 것은 상관이 없다. 코딩신을 영접한 사람은 코딩신을 영접한 사람을 알아본다. 그게 핵심이다.

​

이런 사람은 다른 사람에게 “이런 분야의 전망이 어떨 거라고 생각합니까?”라는 질문을 하지 않는다. 갈림길을 만나면 머리가 계산을 하기 전에 심장이 저절로 움직이기 때문에 다른 사람에게 물어볼 필요가 없다. 이미 행복하기 때문에 전망에 연연하지 않으며, 전망이 없으면 전망을 만들고 길이 없으면 길을 만들겠다는 배짱과 낙관이 충만하다. 사랑하는 사람과 결혼한 신혼부부가 가난한 셋방살이를 해도 행복한 여유가 넘치는 것과 동일한 이치다.

​

공부(工夫)에서 ‘공’은 하늘과 땅을 잇는 것을 표상한다. 그렇게 엄청난 일을 스스로 하지 않으면 누가 대신 해줄 수 있을까. 멘토에게 기대는 것은 자신을 속이는 일이다. 발심하라. 스스로 마음을 일으켜서 코딩신을 영접하라. 그게 진짜다.

원문보기:
http://www.zdnet.co.kr/column/column_view.asp?artice_id=20151012081017#csidx77ce856f2b9b62dbb99a8a71e3d095d