저번주 월요일 부터 다우 교육원에서 강성재 과장과 함께 Visual C++ 2008 부트 캠프를 진행하고 있다. 총 4회 걸쳐서 Visual C++ 개발자들에게 Visual C++ 2008 의 새로운 기능 소개와 더불어 향후 로드맵과 비전에 대해 말씀 드리고, Visual C++ 2008 을 사용해서 쉽고 편리하게 따라해 볼 수 있도록 실습 과정도 짧은 시간이나마 넣었습니다.

저는 세션1과 세션4를 진행하고 있습니다. 세션1에서는 Visual Studio 2008 의 전반적인 특징과 로드맵에 대해 말씀 드리고 데모를 보여 드립니다. 그리고 세션4에서는 현업에서 가장 많이 부닥칠 Visual C++ 6.0 에서 Visual C++ 2008로 마이그레이션 하는 방법과, 32비트에서 64비트로 마이그레이션 하는 방법에 대해 설명하고 실습을 간단히 해 봅니다.

발표자료와 데모 소스에 대해 다음과 같이 공개하오니 하시는 업무에 도움이 되시기를 바랍니다. 그리고 궁금한 사항이 있다면 댓글 부탁 드립니다.

• 세션1 : Visual Studio의 과거, 현재 그리고 미래(발표자료)
• 데모1: WPF Application - Otto Store (중간에 OTTO-STORE INSTALLIEREN 버튼 클릭)
• 데모2: WCF Application - MSMQ_Reliability_Test
• 데모3: WF Application - OrderStateWorkflows
• 데모4: LINQ Application - SimpleLinqToXml
• 세션4 : MFC 마이그레이션(Migration) 및 상호 운용성(Interoperability)(발표자료)
• 실습1 교재 - Visual C++ 6.0 에서 Visual C++ 2008로 마이그레이션 하는 방법
• 실습1 소스 - Visual C++ 6.0 실습본, Visual C++ 2008 완성본
• 실습2 교재 - 32비트에서 64비트로 마이그레이션 하는 방법
• 실습2 소스 - 32비트 실습본, Visual C++ 2008 완성본   

어제 홍은동 힐튼 호텔에 무려 2천명이 넘는 많은 분들이 Heroes Happen Here 행사에 참여해 주셔서 감사드립니다. 저도 맨 마직막 시간에  “Visual Studio 2008 에서 Mobile Client Software Factory를 이용한 기업용 모바일 아키텍처” 라는 주제로 발표를 했지요!!

참석하신 분들은 어땠나요? 계속해서 이 분야도 많은 발전을 거듭합니다. 발표가 끝나고 나서 한 고객이 저에게 왜 .NET Compact Framework 로 꼭 기업용 소프트웨어 개발을 해야 하느냐고 물어 봤습니다. 고객 회사에서는 Win32 API로 개발하신 다고 했습니다.

우선 Visual Studio 2008 에서는 Win32 API 또는 MFC로 개발하는 방법과, .NET Compact Framework를 통한 C# 과 VB.NET 언어로 두 가지 방법이 있습니다. 주로 Win32 API나 MFC는 Windows Embedded Application 이나 하드웨어에 종속되는 장치 드라이버 프로그램 개발이 많이 사용하고 있고, .NET 컴팩트 프레임워크는 아무래도 .NET 개발자가 기업용 응용 프로그램 개발을 할 때 사용하기가 아주 편합니다. 그래서 생산성과 재활용성 측면에서 아주 좋은 효과를 거둘 수 있습니다. 그렇다고 Win32 나 MFC로 기업용 응용 프로그램을 못 만들지는 않습니다. 다만 유지보수나 데이터베이스, COM을 핸들링하기에는 .NET Compact Framework 보다  좀 까다로울 겁니다.  

발표한 자료와 데모 샘플 들을 아래에 공개하오니 하시는 업무에 큰 도움이 되었으면 합니다.  

• Visual Studio 2008 에서 Mobile Client Software Factory를 이용한 기업용 모바일 아키텍처
• Microsoft Mobile Client Software Factory 소스 공개

        Visual Studio 2008 과 Visual Studio 2005 에서 모두 컴파일 가능 합니다.

• Unit Test For Devices 소스 공개

        어저께 본 내용이 너무 빨라 이해할 수 없다는 분은 여기를 눌러 영어 리스닝 공부 한판 해 주세요~!!

• Compact WCF 실행 예제

        데모를 실행하실 때 반드시 아래의 주의 사항을 지켜 주셔야 합니다.

첫째, WCF_Server 소스는 Console 용으로써 http://localhost:8000/Calculator 로 웹 주소를 맞추어 놓았습니다. 따라서 만일에 Windows Vista 나 Windows Server 2008 에서 IIS 와 Windows Activation Service가 없다면 먼저 설치를 하시고 진행하셔야 합니다.  

둘째, WCFServer 를 실행하신 다음 WCFClient 를 컴파일 해 주십시오. Service IP 텍스트 박스에 여러분의 PC에 있는 IP 주소를 적어 주셔야 동작합니다. 이것은 원격 PC IP를 말하고 My IP가 바로 Windows Mobile 에뮬레이터에서 할당 받은 가상 IP가 됩니다.

셋째, 배포하기 전에 WCF는 웹 접속이 필요합니다. 따라서 Windows Mobile 에뮬레이터에서 웹 접속을 먼저 실행시켜 줘야 합니다. Tools 메뉴의 Device Emulator Manager 에서 실행시키고자 하는 에뮬레이터를 Connect 하셔야 합니다. 이때 자동적으로 Windows Mobile Device Center 나 ActiveSync 가 연결되었다는 메시지를 보실 수 있습니다. (만일 나오지 않는다면 잘못 설치하실 수 있습니다.)

그리고 더욱이 중요한 것은 웹 연결을 하려면 한 가지 더 해줘야 하는 데 Connect 한 에뮬레이터에서 Cradle 실행을 해줘야 비로소 인증을 한 다음 사용할 수 있습니다.   

위의 모든 데모 소스는 Visual Studio 2008 Professional Edition 이 필요합니다. 특히, Unit Testing For Device 를 실험해 보실려면 Visual Studio 2008 Team Suite for Team System 이 필요합니다. 혹시 실행하시다가 안 되시면 여기에 댓글 부탁 드립니다.

이번 주 부터는 날씨가 한결 좋아 졌습니다. 답답한 사무실에 있기에는 몸이 근질근질 거리지 않습니까? 시리즈의 마지막회를 시작하려고 합니다. 조금 긴 길이지만 앞으로 소프트웨어 개발자를 꿈꾸는 사람들에게 도움이 되었으면 하는 바램입니다.

자~ 시작 해 볼까요? 

혹자는 요즘과 같은 시대를 '개인 브랜드(Personal Brand)' 시대라고 부르기도 합니다. 브랜딩(Branding) 이란 말은 원래 마켓팅 에서 나온 말로서 기업의 심볼이나 가치에 대해 나타냅니다. 예를 들어 마이크로소프트 하면 세계 최고의 소프트웨어 회사라고 여러분들은 머리 속에 쉽게 떠오를 것 입니다. 이것이 바로 그 기업의 브랜드 입니다. 그렇다면 개인 브랜딩 이란 무엇일까요? 각자 개인을 떠 올릴 때의 캐릭터적인 스켈레톤(?) 또는 상징되는 심볼이나 가치를 말하는 것 입니다. 그렇다면 더 더욱 궁금해 지는 것은 나만의 브랜드를 어떻게 만들 것인가에 대해 더 궁금해 여길 것 입니다. 여러가지 방법이 있습니다만 저는 4가지 정도를 압축해서 말씀 드리고자 합니다.

첫째, 브랜드 관점에서 볼 때 가장 우선적으로 표현해야 할 것은 어떤 일에 대해 얼마만큼 성능을 내었는 가에 대해 누군가에 설명할 수 있어야 합니다. 그리고 그것에 대한 최고로 잘 된 점과, 잘못된 점이나 어려웠던 점, 그리고 그것에 대해 배운 점에 대해 말할 수 있어야 합니다. 

초보자들의 이력서에 보면 "나는 어디에서 몇 남 몇째 아들로써 태어나…. 마음씨는 착하고…. 학교 다닐 때에 무슨 경험으로 컴퓨터와 인연을 맺었으며…". 다시 말해 이력서는 개인 자서전이 아닙니다. 면접관 중에서는 개인 자서전에 대해 관심이 있는 사람은 드물겁니다. 그 사람들은 이 사람이 우리 회사에 와서 얼마나 잘 일을 수행하고 조직에 맞게 성장해 나갈 수 있는 가에 대한 관점으로 여러분을 보게 되지 가족처럼 인간적으로나 개인적으로 여러분을 보지 않을 것 입니다. 그래서 이력서는 짧으면 짧을 수록 좋습니다. 우리나라 사람들은 내용이 짧으면 뭔가 허전하다고 생각하는 데 절대로 그렇지 않습니다. 하나의 시처럼 함축성을 포함해야 합니다. 그러니 단어 하나에 자기가 나타내고자 하는 데 세심히 기울어야 합니다. 

둘째, 자기 만의 브랜드, 쉬운 말로 자기 만의 색깔이 있어야 합니다. 

생각해 보십시오!

무수히 많은 이력서 중에 차별화 할 수 있는 여러분들을 나타낼 것이 무엇인지에 대해서. 그렇다고 해서 컬러 색깔로 남들과 달리 튀게 보이라는 것은 아닙니다. 다시 말해 다른 사람과의 차별성을 가지는 기술이나 능력이 있어야 한다는 말입니다. 대학교만 나온 것은 의미가 없습니다. 왜냐하면 우리나라 대 부분 학생들이 대학교를 나오기 때문입니다. 

만일 여러분들이 이러한 차별화 할 수 있는 뭔가가 없거나 부족하다면 인턴 경험을 쌓는 것도 한 가지 좋은 방법일 수 있습니다. 국내 기업들 중에는 아직 정착화 되진 않았지만 그러나 몇몇 기업들은 이 제도를 시행하고 있습니다. 인턴의 장점은 그 회사에 대한 분위기와 조직 등에 대해 배울 수 있습니다. 당장 나에게 어떠한 일을 시키지 않음에도 불구하고 두루두루 다니면서 살펴 볼 수 있습니다. 운이 좋다면 그 회사에서 발탁되어 취직 할 수 있기 때문에 좋은 제도라고 생각합니다. 얼마전 마이크로소프트 이노베이션 센터에서도 20명 정도가 이 인턴에 참여하여 많은 경험을 쌓았습니다.

셋째, 주어진 문제에 대해 해결 하는 것도 중요하지만 어떠한 문제를 찾아서 해결 하는 능력을 가져야 합니다. 개인적인 견해이지만 우리나라와 다른 나라의 교육의 차이점은 스스로 문제에 대한 해결책 접근 방식이 다르다는 것 입니다. 국내에서는 가르치는 사람이 그러한 모범적인 답안만 가르쳐 줍니다. 다시 말해, '1+1=2' 이라고 한다면 우리나라 학생들은 그것을 외우고 푸는 데 아주 뛰어납니다. 

그러나 환경과 조건이 틀리다면 '1+1=2' 라는 답이 맞을까요? 

상황에 따라 그럴 수도 있고 그렇지 않을 수도 있습니다. 따라서 어떠한 문제를 찾아서 해결 하는 방법 중에 가장 중요한 것은 문제를 확실히 이해해야 한다는 사실입니다. 대부분 인터뷰 과정에서 문제에 대한 파악 조차도 하지 못 합니다. 간단한 문제라면 쉽겠지만 어디 그런 문제만 있을까요?

그리고 그 문제를 풀면 점점 더 어려운 문제를 냅니다. 여러분은 답이 틀릴 수도 있고 모를 수도 있습니다. 그것이 중요한 것은 아닙니다. 그것을 접근해 나가는 방식은 기본적인 문제에 대해 확실히 이해를 하고 이해가 되지 않는다면 힌트가 될 만한 것이 무엇이 있는지를 파악하는 것이 중요합니다. 그리고 몇 가지 떠오른 예를 가지고 시험해 봅니다. 그 중에 한 가지를 알고리즘을 이용해서 풀어 본 다음 그것이 맞는지 테스트를 해 봅니다. 또한 질문에서 어떤 제약 사항이 있는 지에 대해서도 파악해 보면 좋을 것 같습니다.

넷째, 여러분들은 컴퓨터 프로그래밍이나 이 세계에 흥미가 있기 때문에 직업으로서 도전한다고 생각합니다. 한 때 IT 회사들이 잘 나갈 때에는 그런 것에 가리지 않고 많은 이들이 도전했다가 실패하고 다른 일을 찾아서 떠난 사람들이 많습니다. 그러나 그 중에서 그 자리를 묵묵히 지킨 사람들 중에 이야기를 들어 보면 하나를 성취했다면 또 다른 분야를 도전한 사람들입니다.

이러한 다른 분야로 전위를 하려면 그 기술에 대한 트렌드에 대해서도 잘 알고 있어야 합니다. 소프트웨어 개발자 중에서는 자기 단위 업무만 충실히 하는 사람들이 있습니다. 물론 자기에게 주어진 일을 해내는 것도 중요하지만 세상에 돌아가는 이치도 알아야 미래를 보는 나만의 통찰력이 생기게 됩니다. 

예를 들어, 다른 회사로 옮기거나 회사에서 다른 업무를 맡겼을 때에는 여러분들은 어떻게 하겠습니까? 하기 싫다고 사표를 던질 것 입니까? 아니면 이 일만 하겠다고 고집을 피울 것 입니까? 세상이 빠르게 변하는 만큼 나에게 주어진 업무도 경우에 따라서 변할 수 있습니다. 다시 말해 미래의 수많은 기업들이 멀티 플레이어를 요구하고 있습니다. 공격과 수비를 둘 다 겸비할 수 있는 축구 선수들 처럼 IT에서도 그러한 개발자가 각광을 받게 될 것 입니다.

그렇다면, 이러한 기술에 대한 트렌드와 통찰력은 어떻게 가질 수 있을까요? 

미래를 예견하기 위해서는 반드시 과거의 어떠한 기술들이 쓰여 졌는 지에 대해 알 필요성이 있습니다. 예전에 저는 마이크로 소프트웨어와 같은 IT 잡지를 정기 구독하거나 과 월호를 구입하여 읽으면서 시대의 IT 흐름을 파악해 두었습니다. 그 해의 핫이슈는 무엇이고 어떤 사람이 어떤 사업을 해서 성공을 하거나 기술 구현을 했는지, 공개된 기술은 무엇인지에 대해 한 눈에 볼 수 있습니다. 

왜냐하면 잡지란 그 때의 이슈로 일어나는 트렌드를 뽑아서 기획하기 때문에 적어도 그 해에 무슨 일이 일어났고 기술적인 흐름이 무엇인지 짧은 시간에 파악할 수 있기 때문입니다. 물론 요즘은 블로그나 인터넷에서 수많은 기사들이 존재하기 때문에 그러한 기사들을 모으고 정리하는 일이 쉽겠지만 요즘은 '노하우(Know-How)'도 중요하지만 '노웨어(Know-Where)'도 중요하다고 생각합니다. 그래서 온라인 검색 업체가 떠지 않습니까? 

그리고 마지막으로 그러한 기사들을 읽었다면 자기 만의 의견 게재를 할 수 있어야 합니다. 이러한 것들을 잘 보완해 주는 것이 블로깅이라고 생각합니다. 필자는 1주일 2-3번 정도 블로깅에 대해 적극 권장 합니다. 여러분들은 어떠하세요? 단지 블로깅이 남들에게 알리고 내가 외부의 사람들에게 인기를 누리기 위해서 블로깅을 적는다면 십중 팔구 실패 합니다. 왜냐하면 갈 수록 부담 감을 느끼게 될 것 입니다. 아니면 회사 일도 바쁜데 글을 적을 시간이 어디 있나? 나의 노하우를 쉽게 알려주기란 배 아프다라고 고백할 수도 있을 것 입니다. 또한 요즈음은 기사 중에 '사실(Factor)'에 기반한 글도 있지만 '개인적 견해(Perception)'로 적힌 글들이 많아서 그것을 스스로 분류할 수 있는 분별력도 있어야 합니다.

결론적으로 말해서 하나의 전문가적인 소프트웨어 개발자가 되는 것은 쉬운 일이 아니지만 소프트웨어 개발자 라는 직업은 적어도 자기가 좋아하는 일을 계속할 수 있다는 것 입니다. 그리고 동시에 여러분 자신 만이 미래의 희망이고 스스로 이 길을 택하여 갈 수 있다는 것 입니다. '미래의 예견 하는 일 중에 가장 쉬운 것은 그 미래를 창조하고 개발하는 것이다.' 라는 말을 남긴 스티브 잡스 처럼 여러분 스스로를 개발하고 발전시키면 훗날 행복한 개발자로 뛰어 넘어 영웅(Heroes)로서 우리나라 IT 기업을 발전시켜 나가리라 믿습니다!

썰렁하지 않을까 노파심을 가졌지만 재미있다고 하셔서 용기를 내어 어제 저녁에 이어 2부 순서를 진행하도록 하겠습니다. 아래의 말씀 대로 전자신문 지식방송을 애드리브(Adlib)으로 즉흥적으로 이야기하다가 모두 끝내고 JCO의 옥상훈 차장과, 와이즈 파트너의 고대표님 그리고 전자신문사의 홍원준 대리님과 중국집에서 저녁을 먹으면서 이런 저런 이야기를 나누었습니다.

오늘 시간이 없어서 촬영본을 못 보신 분은 며칠 후에 전자신문의 U-TV에 올린다고 하니 한번 보시기 바랍니다. 그리고 고 대표님의 블로그도 있으니 후기도 읽어 보기 바랍니다.

그렇다면 각설하고 미래의 행복한 소프트웨어 개발자가 되려면 두 번째 시간으로 나의 적성은 어디에 맞는가에 대해 진지하게 고민해 보는 시간을 가졌으면 합니다.

너 자신을 알라!

사실 이 말은 듣기에 따라서 기분이 좋을 수도 있고 나쁠 수도 있을 것이다. 이 말의 의미는 적어도 내가 어떠한 분야를 좋아하는 지 싫어 하는지를 스스로 파악해 보기 바라는 마음에서이다. 필자는 작년 한 해 동안 분기 마다 전국 서울/지방에 있는 대학교를 방문하는 Mix On Campus 라는 행사를 통해 학생들에게 다음과 같이 물어 보았다.

컴퓨터 공학을 전공하는 학생들에게 자기가 어떠한 분야를 좋아하느냐고 물어 보면 진정 스스로 고민해 보고 떳떳하게 말할 수 있는 사람이 그렇게 많지 않은 것에 대해 놀라지 않을 수가 없다. 왜냐하면 하나의 직업을 선택하는 것은 그 사람의 인생에 있어서 1/2, 아니 전체에 영향을 끼칠 만큼 중요하다. 단지 내가 컴퓨터 공학을 전공 했으므로, 또한 대학교를 졸업 했으므로 그 분야로 취업을 해야 한다는 생각은 어불성설이다.

· 나는 아키텍트(Architect)인가? 코��(Coder)인가?

먼저 내 자신이 아키텍처링을 좋아하는 지 아니면 코딩을 좋아하는 지에 대해 파악하기 전에 하나의 소프트웨어가 만들어지는 전체 과정을 알아두도록 하자. 흔히 '고객 요구 사항 분석->제품 기획->설계->코딩->테스트->제품 출시(RTM/RTP)' 과 같은 과정을 거쳐 하나의 소프트웨어든 프로젝트든 끝을 맺는다. 이 중에 고객의 요구 사항을 잘 정리하여 프로젝트에서 위험 관리 및 이슈 등을 관리하여 설계에 반영하는 직업이 바로 소프트웨어 아키텍트다.

국내에서는 아직 소프트웨어 아키텍트(CSA) 라는 직업은 낫설다. 가끔 필자에게 프로젝트/프로그램 관리자와 소프트웨어 아키텍처가 어떠한 차이점이 있는 지에 대해 묻곤 한다. 국내에는 대개 그 프로젝트를 책임하고 관리하는 사람이 아키텍처랑 함께 하고 있다. 그래서 고객들이 헤깔려 하는 것 같다. 예를 들어 프로젝트/프로그램 관리자는 오케스트라에서 전체 음악을 총 지휘하는 사람이라고 한다면, 아키텍처란 그러한 음악이 잘 들릴 수 있도록 악기 및 음향, 공연 무대 등을 배치 하는 사람이라고 이해하면 쉽겠다.

주로 국내에서는 제일 경력이 많은 사람들이 이러한 역할들을 맡고 있다. 또한 코딩 경력이 오래 쌓이면 아키텍트가 자동적으로 된다고 잘못 이해하고 있는 사람들이 많다. 아키텍트는 아키텍트 일뿐, 코더 구루(Guru)는 아니다. 예를 들어, 코더는 그 로직에 대하여 코딩에 책임을 져야 한다.

여러분들이 짜 놓은 코드를 수년이 지나고 나서 본 적이 있는가? 로직에 대하여 최상의 성능과 구조를 가질 수 있도록 늘 코더들은 신경을 써야 한다. 프로젝트가 끝났다고 해서 코딩이 마무리 되는 것은 아니다. 그래서 컴퓨터 공학에서는 데이터 구조론과 알고리즘이 존재하지 않는가? 그냥 .NET 이나 JAVA 프레임워크에 있는 API를 호출하는 수준은 세월이 10년이 지나도 초보 수준에 지나치지 않는다.

아키텍트 또한 앞에서 폼만 잡는 사람이 아니다. 정말로 전체 시스템 상에서 성능과 확장성, 기존의 시스템과의 호환성 등 여러 측면에서 고객이 요구하는 사항들을 관리하고 올바른 방향으로 제시해야 한다. 또한 기존의 버전 1.0 에서 일정이나 리소스가 부족하여 구현 하지 못한 사양(Specification)들에 대하여 현재 완료된 프로젝트와 어떠한 연관 관계가 있는 지 확장 성과 재활용성, 또한 위험 측면에서 먼저 코딩 및 테스트를 해 보고 파악해 두어야 한다.

그래야 이를 믿고 따르는 코더들은 들 삽질(?)을 한다. 그렇지 않으면 대개가 코더들이 구현해보고 거꾸로 문제가 있다고 보고를 한다. 그 때는 프로젝트가 한 참 중반쯤에 치 닿을 때 그러한 문제가 발생한다면 프로젝트 일정이 더 지체가 된다. 물론 완벽한 설계가 어디 있겠는가 만은 사전에 미리 방지할 수 있는 일이나 예견 할 수 있는 일들은 경험의 노하우나 시스템의 관리로써 이를 막는 게 좋다.

· 나는 시스템 개발자인가? 응용 프로그램 개발자인가?

흔히 세상의 프로그래머에는 두 가지의 종족이 있다곤 한다.

첫번째는 그 이름하여 "시스템 프로그래머" 라고 부르는 종속이 있다. 가끔 해커라고들 오용해서 부르지만 주로 커널 이나 드라이버, 컴파일러 등 컴퓨터 시스템이 직접 동작하게 하는 프로그램에 관심이 많다. 그래서 인터넷에서 그러한 것들을 파헤치는 유틸리티나 직접 접근 가능한 소스가 있다면 흡족해 한다.

두번째는 "응용 프로그램 개발자". 흔히, 그 시스템 위의 사용자 인터페이스나 데이터베이스 연결과 같은 미들 웨어 로직을 담당한다. 시스템 플랫폼에 따라 윈도우 클라이언트, 웹 응용 프로그램, 모바일/임베디드 장치 응용 프로그램 개발자로 불리 운다. 가끔 노가다(?) 라고 부르는 화면 위치 수정이나 디자이너가 만들어주는 그림 등을 붙이는 일들을 하며, 프로그래머가 아닌 사람들과 자주 만난다. 그러나 남들과 다른 창조적인 사용자 인터페이스 코딩을 할 수 있다는 것은 축복 받은 일이다. 이들로 인하여 계속하여 응용 프로그램 들이 진보적으로 발전하고 있으며 우리의 눈이 즐거워 지니깐 말이다. 이제 사용자 경험은 비트맵 방식에서 벡터 방식으로, 2D 평면에서 3D 입체 비주얼 방식으로 흘러가고 있지 않은가?

· 나는 디버깅에 능숙한가? 나는 테스팅을 좋아하는가?

만일 여러분들이 마이크로소프트나 구글과 같은 R&D 의 소프트웨어 디벨로퍼 엔지니어(SDE) 로서 지원한다면 프로그램 관리자는 여러분의 이력서를 보고 한 번쯤 이 질문을 던지게 될 것이다. 여러분이 지금까지 학교에서 했던 퀴즈나 텀 프로젝트에서 일어난 일에 대해 어떠한 문제가 발생 했는 지 정의하고 그것을 어떻게 해결 했는 지에 대해 물어 볼 것이다. 그 중 소프트웨어 개발자로 디버깅에 대해서 종종 물어 보는 데, 여러분들은 만일 Visual Studio 와 같은 개발 도구 및 디버깅 도구가 없다면 여러분의 로직(Logic)이 프로그램 상에서 잘 동작하고 있는 지 점검할 수 있는가?

여기서 한 가지의 여러분은 오류에 빠지기 쉽다. 여러분이 짜 놓은 코드는 여러분이 짜 놓은 로직 대로만 테스트 하기 쉬워 전혀 다른 방식으로 접근 한다면 예기치 않는 에러가 발생하는 데 이 때문에 전문적인 테스터가 필요하다. 코딩을 하는 것을 즐기는 사람도 있지만 다른 사람이 짜 놓은 프로그램을 점검하는 사람도 있다.

여러분은 어떠한 것을 좋아하는가? 모바일 이나 임베디드 관련 분야에서는 이 테스팅 하는 사람들이 모여 품질 관리 및 인증(Q&A) 팀으로 하나의 부서로 꾸며지게 되는 데, 여기에서 합격하지 않으면 제품 출하를 할 수 없다. 그야말로 강력하게 유닛 테스트, 병합 테스트 및 스트레스 테스트, 사용자 시나리오 별 테스트 등으로 이뤄져 제품 출시를 한다.

지금까지의 질문은 개발자로서의 스타일에 관계된 질문으로서 어떠한 것을 선호하는 지에 대해 알아 보기 위함이다. 이 외에도 하드웨어나 네트워크를 관리하는 업무에 대해 흥미를 느끼고 있는지? 아니면 그림이나 동영상 편집 등을 디자인에 흥미를 느끼고 있는지에 대해서도 생각해 볼 필요가 있다.  어떠한 스타일을 하든 지 간에 사실 이 세상에서는 정답은 없다. 자기가 좋아하고 계속해서 그 일에 대해 노력하는 사람에게 좋은 기회가 더 오더라도 놓치지 않을 것이다.

그러나 이것은 이제 막 깨달음을 안 첫 순간이다.

세번째 이야기는 현재 회사를 다니고 있는 분들에게 경력 관리에서도 도움이 되는 글일 것 입니다. 기대해 주셔서도 좋습니다! 내일 뵙죠~!!

긴급 공지!! 

여러분 제가 오늘 오후 5시 30분 부터 전자신문 지식방송 U-TV에 ".NET 개발자의 현재와 미래" 라는 주제로 방송 출연하게 되었습니다.

혹시 봄날씨에 나르하거나 졸리시는 분!! 아니면 정말로 .NET 개발자의 현재와 미래에 대해 궁금하신 분들은  http://www.ubizcenter.co.kr 로 들어 오셔서 사전 등록도 하시고 참석해 주셔서 제 얼굴이 어떻게 생겼나도 보시기 바랍니다.   

안 그래도 어제 저녁에 "미래의 행복한 소프트웨어 개발자가 되려면" 이라는 컬럼을 게재 했는 데, 이 맥락과 연관지어 .NET 개발자의 현재와 미래에 대해 토론을 해 보도록 하겠습니다!

그럼 있다가 만나요~!!   

지난 2월달 졸업 시즌을 맞이하여 마이크로소프트웨어 2월호에 졸업 하는 학생들을 위해 적은 컬럼 입니다. 우리 같이 한번 생각해 봅시다. 내용이 좀 길어서 몇 부로 짤라서 올립니다. 

해마다 이 맘 때면 그 동안 몸소 수련을 했던 캠퍼스에서 하산해 진정한 나의 실력을 겨누어 보고자 여러 기업에 도전장을 던질 것이다. 적게는 4년에서 6년 동안 한 분야에 대해 전문적인 수련 과정을 밟아 이 사회로 하산하는 날, 작금의 현실은 그러한 도전장 조차도 던질 수 없는 눅눅한 현실이 되어 버린 지 오래다. 통계청 보고서에 의하면 2007년에 신규 취업을 한 사람이 고작 28만 2천명 밖에 되지 않는 다고 이야기한다. 사실 이러한 통계 보고서는 자료를 보지 않고도 우리 주위에서 흔히 볼 수 있는 일이다.

" K군을 보라!! 그는 남부러움 없는 국내 일류 대학교를 졸업했다. 또한 그는 오늘도 어김없이 새벽에 일어나 만원의 지하철을 타고 면접에 필요한 토익 점수를 한 점이라도 올리기 위해 쪽집개 학원으로 향한다.

그러나 좀처럼 늘지 않는 영어 실력. 뿐만 아니라 다람쥐 채바퀴 돌듯이 면접을 보는 일. 그는 점심을 먹을 시간도 없이 오늘 인터뷰를 보기로 한 업체에 연락을 받아 한 손에 이력서를 들고 깨끗한 정장 차림으로 집을 나선다.

그러나 이미 나와 같은 쟁쟁한 경쟁자들이 초초한 눈빛으로 서로 말 없이 자리에 앉아 있다. 침묵이 몇 분 흐른 뒤 면접 관이 그의 이름을 부른 순간 조그마한 회의실에 몇몇 분들이 그가 들어오는 모습을 지켜 보고 있다.

그는 자리에 앉은 다음 면접 관들이 묻는 말에 성심껏 답변을 한다. 이윽고 그 ���의실을 떠날 때 며칠 뒤 합격 통보를 알려 주겠다고 말을 듣고 밖으로 나와 긴장했던 몸을 풀기 위해 담배 한 가치를 핀다. 이 번에는 면접관 반응도 좋았고 내가 말하고자 하는 이야기는 모두 다 했다.

그러나 기대가 크면 실망도 큰 법일까? 이렇게 생활한 것도 2년이 다 되어간다. 언제까지 이 생활이 지속될까? 이번에 취업한 친구 녀석은 신입생 환영회를 근사한 와인 바에서 해 주더라는 전화를 받고 약은 오르지만 어쩌겠냐 이 백수의 서러움을.

저녁에 집에 돌아가면 묵묵히 오늘도 수고 했다는 어머니 칭찬에 왠지 미안한 마음에 다음 번에 꼭 합격하여 어려운 집안에 조금이나마 보탬이 되고 기뻐하시는 어머니의 모습을 상상 하면서 다시 그는 반복되는 일상으로 돌아간다."

우리에겐 희망이 없다(?)

오늘도 수많은 학생들이 학교 수업 이외에 미래를 위하여 수많은 투자를 하고 있다. 장기적인 보험과 같이 안정적으로 취직할 수 있는 공무원 시험을 보거나, 초일류 기업에 합격하기 위해 늘지도 않는 영어 점수를 올리기 위해 고3 수험생도 아닌 데, 이 지겨운 학원에서 끓는 청춘을 다 보내고 있다는 현실에 우리에겐 희망이 없다 라고 말할 수 있다.  더욱이 IT관련 기업에 취직하려면 형/누나, 선배 할 것 없이 도시락을 사들고서라도 말린다.

그 이유는 여러분들도 잘 알다시피 잦은 야근과 밤샘, 열악한 처우, 영세성을 탈피하지 못하고 있는 SW 업계, 이공계 기피 현상, 잘못된 개발환경과 관행, 개발자들에 대한 사회적 몰이해 등 지금까지도 블로그스피어에서의 블로거들로 부터 회자되고 있다.

필자도 그 동안 개발자의 길을 걸어 오면서 단 한가지만 빼고 다 경험 해 보았다. 그 한 가지는 제가 대학 시험을 쳤을 때 가장 높은 점수를 받아야 들어 갈 수 있는 분야가 컴퓨터 공학이었다는 사실 외에는 약 15년 동안 여러분들과 똑같이 변화없는 경험을 했다.

그렇다고 해서 내가 이렇게 경험 했으니 여러분들도 경험하라는 이야기는 절대 아니다. 분명 그 누구보다도 이러한 분야는 개선되어야 한다고 믿는다. 적어도 나의 후배들에게는 쓰디쓴 이러한 환경을 되물려 주고 싶지는 않다.

물론 이것은 사회 현상이기 때문에 하루 아침에 변경되지 않는다. 작년 모 대통령 후보처럼 개발자로 취업 한다면 1억을 준다고 해도 IT 산업의 생태계가 올바르게 적립되지 않는 이상 어려운 현실이다.

그렇다고 냉소적인 비관만 할 수 없지 않은가? 언제나 그렇듯이 세상은 공평하지도 않지만 기회가 없는 것은 아니다. 항상 준비된 자에게만 기회가 찾아 왔을 때 잡을 수 있기 때문이다. 그렇다면 어떻게 그 기회가 찾아 왔을 때 잡을 수 있는 준비를 할 수 있는가?

그럼 다음 편에 이어서 계속 하겠다!