천객만래 [千客萬來] (It has an interminable succession of visitors)



'SW 마에스트로' 연수생 구글 본사 방문… 선배들과 간담회

2011년 01월 07일

"좋은 소프트웨어(SW) 개발자의 조건은 명문대 졸업여부가 아니라 창의력과 문제에 접근하고 해결하는 능력이다.", "초가집을 수 백 채 지어봤다고 63빌딩을 건설할 수 없다. SW 개발도 우선 역량을 크게 키워야 한다."

실리콘밸리를 방문한 한국의 SW 꿈나무들에게 미국 구글 본사에서 근무하고 있는 한국인 SW 엔지니어들은 창의력을 바탕으로 더 높은 곳으로 비상해야한다고 조언했다.

5일(현지시간) 지식경제부, 정보통신산업진흥원, 한국정보산업연합회 등이 주관하는 SW 마에스트로 미국 연수의 일환으로 구글을 방문한 학생들은 직원들의 언제든 즐길 수 있는 게임기와 카페테리아 등 자유로운 업무환경을 돌아봤다. 이어진 구글 본사에서 근무하고 있는 한국인 SW엔지니어들과의 간담회에서는 선배들의 조언이 쏟아졌다.

SW엔지니어인 전지운 씨는 "코딩과 프로그래밍 능력은 물론 창의력과 문제에 접근하고 해결하는 능력이 중요하기 때문에 미국에서는 SW 개발자를 뽑는데 창의력과 문제 해결 능력 등에 중점을 두고 평가한다"며 "알고리즘과 자료구조 등이 중요한데 책만 본다고 이런 능력이 생기는 것이 아니므로 프로젝트를 하면서 문제 해결 능력을 배양해야 한다"고 말했다.

김용성씨는 "초가집을 수 백 채 지어봤다고 63빌딩을 지을 수 있는 것이 아닌 것처럼 SW 도 SW를 잘 개발하는 역량이 있는 기업에서 배워야 한다"며 "SW 마에스트로 과정을 통해 큰 프로젝트들을 진행해 보는 것도 도움이 될 것"이라고 조언했다.

SW 마에스트로 연수단 학생들은 구글의 SW 개발 여건에 많은 관심을 나타냈다.

이에 대해 김용성 구글 SW엔지니어는 "미국과 한국의 SW 개발 환경의 차이는 관리 대상이 다르다는 것"이라고 설명하고 "한국에서는 SW를 개발할 때 사람을 대상으로 관리하는데 구글 등 미국에서는 일의 성과를 중심으로 관리한다는 점이 다르다"고 말했다. 또 "구글 등 미국 기업들의 자율적인 SW 개발 환경에 대해 동경하는 이야기가 많은데 실제 일의 강도와 업무는 한국보다 더 높다"며 "이는 업무를 믿고 맡겨서 밀어주는 환경이 업무 집중도를 높여주기 때문"이라고 설명했다.

한국인 구글 SW엔지니어들은 후배 개발자들에게 문제 해결 능력을 배양하는 것이 중요하다고 입을 모아 말하고 시야를 넓게 갖고 큰 꿈을 가지라고 충고했다

출처 : http://www.dt.co.kr/contents.html?article_no=2011010702010660739004




실제로 사회에서 개발자로 직장을 다닌다는건 .. 학생 때와는 다르게 프로다운 마음가짐이 필요합니다.
신입일 때는 내가 못하면 위에서 봐주면서 대신 처리해주지만 갈수록 책임감이 늘어갑니다.
즉, 문제가 주어졌을 때 해결해야한다는 것이죠. 차선책이라도 꼭 만들어야 한다는 겁니다.
가정의 가장일 경우도... 책임감은 날로 늘어가면서 가정을 지키기 위해서는 문제가 있을 때마다 해결해야한다는
압박감이 큽니다. 개발자이건 아니건 문제해결능력이라는건 그사람의 역량과도 직결되는 문제이니 간과해서는 안됩니다.


Posted by SB패밀리

얼마전 개발자가 보면 암 걸리는 동영상이라면서

SNS에 올라온 동영상이 있다.


모든 미팅이 이렇지는 않겠지만 프로젝트를 구성하는 여러 구성원이 모이면

개발자가 전지전능한 신처럼 여겨지는 경우가 있다.


물론, 강요에 의해서


여하튼 한 번이상은 이런 상황을 겪은 개발자(엔지니어)가 있다고 본다.


자, 아래 동영상을 감상하면서 공감해 보자.... 


다들 연기력이 좋지만, 엔지니어 역할 표정연기 너무 실감난다.
The Expert (Short Comedy Sketch)




The Expert (Short Comedy Sketch) - 엔지니어에게는 난감한 미팅!

(한국어 자막 지원됩니다 ^^)


Posted by SB패밀리

[개발] 나는 과연 개발자로서 자질을 갖추고 있는가?


◈ 나는 과연 개발자로서 자질을 갖추고 있는가?

--------------------------------------------------------------

1. 다른 사람과 경쟁하길 좋아한다.

2. 성공을 위하여 보상에 관계없이 격렬하게 경쟁한다.

3. 조심하면서 경쟁하지만 가끔 허세를 부린다.

4. 장래 이득을 얻기 위해선 주저하지 않고 위험을 무릅쓴다.

5. 업무를 잘 처리하여 확실한 성취감을 얻는다.

6. 전통에 얽매이길 싫어한다.

8. 먼저 일을 시작하고 나중에 의논하는 경향이 있다.

9. 칭찬이나 보상보다는 업무수행 자체를 중시한다.

10. 타인의 의견에 구애받지 않고 내 방식대로 한다.

11. 과오나 패배를 잘 인정하지 않는다.

12. 자발적이며 남의 말을 듣지 않는다.

13. 좀처럼 좌절하지 않는다.

14. 문제가 있으면 스스로 해결책을 찾는다.

15. 호기심이 강하다.

16. 남이 방해하는 것을 참지 못한다.

17. 타인의 명령을 듣기 싫어한다.

18. 비판을 받고도 참을 수 있다.

19. 일 완성되는 것을 보겠다고 고집한다.

20. 동료나 부하들이 나처럼 열심히 일하기를 바란다.

21. 개발에 관한 지식을 넓히기 위해 독서를 한다.


------------------------------------------------------------



My Desk @ SimpleGeo SF
My Desk @ SimpleGeo SF by Jon Rohan 저작자 표시




측정 방법 : 서술내용과 나의 행동이 일치하면 3 점, 
항상 일치하지는 않으나 상황에 따라 일치하면 2점, 
일치하지 않으면 1점

평가 방법 : 총점이 63점이면 완벽, 52 ~ 62 점이면 우수, 
42 ~ 51 점이면 보통, 41 점 이하면 열등






Posted by SB패밀리


아래의 글은 개발자가 되어 5년정도 개발하고 있게 되면... 자주 고뇌하게 되는 내용인 듯 싶다.

개발자의 미래는 무엇일까?

개발자로서 남을 수 있을까?

개발자는 관리자로 전향해야하나?

한 번 개발자는 영원한 개발자인가?

개발자는 치킨집을 목표로 삼아야 하나?


대부분의 칼럼에서 보면 우리나라에서는 개발자로 남는다는 것이 무척이나 어렵다고들 한다.

실제로... 10년차가 넘어서면 회사에서는 개발관련 업무 보다 개발 관리 업무를 원하기 시작하고

인력을 관리해주기를 바란다.

그러면서 많은 개발자들이 고민을 하게 되는데....







출처: http://techit.co.kr/7496


개발자의 미래, 당신의 선택은 무엇입니까?


Software개발이 좋아서 개발자가 된 사람들도 한 5~7년 개발을 하다 보면 미래에 대해 걱정을 하게 되고 불확실한 미래를 불안해하게 된다. 대부분의 회사에서 개발자의 Career Path를 보장해주지 않기 때문에 막연히 팀장이 되고 관리자가 되고, 또는 다른 직종으로 옮기기도 한다.

그러다 보니 전문성 있고 실력 있는 개발자의 경험과 지식이 묻혀버리기 일쑤이고 회사에서는 기술력이 축적되지 못하게 된다.

물론 한번 Software 개발자였다고 해서 평생 개발만 해야 하는 것은 아니다. 개발자가 선택할 수 있는 직종은 상당히 많다.
개발자가 Career Path 상에서 어떠한 직종을 선택할 수 있는지 알아보자. 자신의 역량과 성향에 따라서 Path를 정하면 좋을 것이다. 물론 회사에서 그리고 사회 전체적으로 개발자의 Career Path를 보장해 주는 방향으로 변하는 것이 우선이다.

Senior Engineer, Chief Scientist
한마디로 고참개발자이다. 개발을 계속하고 싶은 사람들이 선택하는 Path이다.
신참 때는 주로 코딩을 많이 하고 버그를 잡았으면 이제는 분석, 설계에 더 많은 시간을 소비하고 Peer Review에 많이 참석한다.
자신의 팀의 프로젝트만 관심을 가지는 것이 아니고 다른 팀의 프로젝트 리뷰에도 참석하여 기여를 한다.
흔히 Architect라고 불리기도 하고 여전히 코딩도 한다.
외국에서는 60세가 넘는 Software엔지니어를 볼 수 있기도 하다.
제대로 된 엔지니어라면 Domain과 상관없이 어느 분야로든지 이직이 가능하다.

CTO
회사의 최고 기술 책임자이며 많은 개발자들의 Role model이다.
회사의 경영에 관여를 하지만 관리는 하지 않는다.
장기기술전략, 실행전략, 아키텍처, 구현, 인프라구조 정립, 프로세스 등 개발에 관하여 기술적인 것이라면 모두 책임진다.
왕년에 코딩을 했다는 것으로는 CTO가 될 수 없다. CTO라면 현재도 코딩을 할 수 있어야 한다. 바쁘고 코딩의 Value가 낮기 때문에 안하는 것뿐이지 분석/설계/코딩을 현재도 모두 할 수 있어야 한다.
소프트웨어 회사의 최고봉이라고 할 수 있다.

SCM, Build and Release Engineer
소프트웨어 회사에는 몇가지 전문적인 분야가 있다. 형상관리, 빌드, 릴리즈, 팩키징 등이 그것이다. 처음에는 개발자들이 개발과 더불어 이런 업무도 같이 수행하지만 회사가 커지면 전문적인 업무로 떨어져 나온다. 몇 명이 전담을 해도 될 만큼 일의 양도 많고 취미로 해도 될 만큼 쉬운 일도 아니다. 또한 개발 능력도 상당히 필요해서 개발자 출신이 아니면 하기 어렵다. 대단히 전문적인 업무이고 이러한 개발 외의 환경이 잘 되어 있어야 개발자들이 개발에 집중할 수 있고 업무 효율이 오르게 된다.
개발자 중에는 프로젝트보다 이러한 전문적이고 SW공학적인 업무에 관심을 가지는 사람들이 있다. 이 영역에서 실력을 닦으면 이직 시에도 이 전문성을 활용할 수가 있다.

Technical Marketer
제품을 기획할 때는 비즈니스적인 요소, 기술적인 요소가 모두 고려된다. 그 중에서 기술적인 부분은 일반 기획자들이 속속들이 알기가 어렵다. 따라서 기술을 아주 잘아는 Technical Marketer가 기술적인 부분을 담당하게 된다. 경쟁사의 제품을 분석할 때도 단순히 기능이 되는지 O, X만 체크 하는 것이 아니고 기술적인 부분까지 검토를 해서 적용된 기술도 파악할 수 있다.
새로 기획하는 제품의 기술적인 비전을 수립하고 마케팅과 개발자의 연결고리 역할도 수행한다.

Technical Supporter
개발자 중에는 진득하게 않아서 개발하는 것을 좀쑤셔 하는 사람들이 있다. 여러 경쟁 제품을 써보기를 좋아하고 새로운 제품이 나오면 먼저 써보려고 하고 동료들의 시스템에 문제가 생기면 누구보다 빠르게 해결해 주는 능력을 가지고 있다.
이런 경우 개발 경력과 지식을 활용하여 기술지원업무를 수행할 수 있다. 회사의 제품에 대해서 기술적으로는 누구보다 속속들이 잘 알기 때문에 수준 높은 지원도 가능하다.
외향적인 사람들에게 어울리는 직종이다. 이직 시 비슷한 분야로 이직이 가능하며 선택의 폭도 상당히 넓다.

QA Engineer/Manager
개발자 출신으로 QA 엔지니어나 관리자가 될 수 있고 개발 능력을 활용하여 테스트 관련 툴을 개발할 수 있다. 개발 경험이 있는 것은 장점으로 작용하면 계획적인 삶을 살 수 있는 장점도 있다. 물론 우리나라에서는 똑같이 무지막지한 야근을 해야 하는 경우가 많다. Domain에 상관없이 이직이 가능하다.

Project Manager
기술자 트랙과 관리자 트랙의 중간쯤 되는 포지션이다. 프로젝트를 책임지고 맡아서 관리하는 역할로서 General Manager가 되는 중간 과정이 될 수도 있다. 개발자 출신으로 Project Manager가 되면 개발의 이해도가 높아서 문제 해결 능력이 뛰어나고 관리에 도움이 많이 된다. 프로젝트 관리 전문가 과정이 도움이 된다. 이직 시 선택의 폭이 매우 넓다.

General Manager
기술과는 관련이 없는 일반 관리자다. 기술에서는 손을 떼는 것이다. 우리나라의 개발팀장과는 다르다. 개발팀장이 된지 오래되어서 더 이상 개발을 하지 않고 관리만 하고 있다면 General Manager라고 볼 수 있다. 기술적인 결정은 하지 않는다. 하지만 과거에 개발 좀 해 봤다고 기술적인 결정을 자기가 해버리면 월권이라고 할 수 있다.
일단 일반 관리자로 넘어오면 다시 엔지니어로 돌아가는 것은 불가능 하다. VP Engineering으로 성장하는 트랙이다.

VP Engineering
우리말로는 “기술부사장”, “연구소장” 정도가 되겠다. CTO와는 완전히 다르다. CTO는 관리를 하지 않지만 VP Engineering은 관리자다. 개발관리 총책임자 쯤 된다. 개발자나 CTO가 하는 기술적인 얘기의 용어들을 거의 알고 있고 개발프로세스가 어떻게 돌아가는지도 잘 안다. 하지만 기술적인 결정을 하지는 않고 관리만 한다. 우리나라에서는 흔히 VP Engineering을 CTO라고 불러서 오해를 하는 경우가 많다.

Domain Expert
소프트웨어 개발 역량보다는 업무 지식에 치중하는 사람들이다. 증권사, 은행, 회계, 토목, 건설, 기계, 예술 분야의 소프트웨어를 개발하려면 해당 영역의 지식과 경험이 많이 필요하고 소프트웨어 기술도 어느 정도 알아야 한다. 개발 경험을 가지고 해당 산업 지식을 쌓으면 도메인 전문가가 될 수 있고, 이 경우 해당 분야로만 이직이 가능하다.

Restaurant Owner
소프트웨어 개발에 염증을 느끼거나 비전을 찾지 못하면 소프트웨어 업계를 완전히 떠나는 것도 한 방법이다. 흔히 통닭집 주인이라고 한다.

Posted by SB패밀리

과학자와 엔지니어의 차이점....

 딱히 모르고 있었다...

 가장 간단히 이야기 하면

 과학자는 어떤 가설을 세우거나 존재하는 가설을 증명하는 사람이고

엔지니어는 증명된 가설이나 이론을 실제에 효율적으로 적용(응용)하는 사람이다.

 소프트웨어 개발자는 방법론적인면을 많이 공부해서 실무에 적절히 적용하는 법을 배워야 할 것이다

Posted by SB패밀리

프로그래머, 개발자, 엔지니어, 코더, 아키텍트, 디자이너, 예술가… 전산학과, 컴퓨터 공학과, 6개월 마스터 과정 학원 교습까지… 과연 개발자의 세계는 어디까지일까. 개발자의 세계를 설명하는 수많은 용어의 홍수 속에, 지금의 시점에서 개발자로서 자신이 가야할 길이 어디인지 고민하는 이들을 위한 길잡이를 제시하고자 한다.

 

신승근 (데브 CEO 겸 수석 컨설턴트 )
   2001년 4월호

 

  "아무도 걸어가지 않은 길을 걷는다는 것은 쉬운 일은 아니지만, 가치있는 일입니다. 누군가가 내 뒤를 따라오기 때문입니다."
  개발자에 대해 나온 책들이 몇 권 있지만, 언어를 가르치거나 형식적인 면에 그치는 경우가 많아서 이번 기회에 개발자에 대한 글을 써보기로 했다. 개발자에 대한 분석이나 자료들이 거의 없어 자료를 찾는 일과 명상에 많은 시간을 투자했음을 밝힌다.
  모두가 잠든 새벽, 키보드 자판을 두드리는 한 명의 남자, 옆에는 식은 커피잔과 어질러진 서류들, 부시시한 머리에 이글거리는 눈동자. 나라를 위협하는 전자 장비나, 바이러스 소프트웨어를 몇 시간만에 만들기도 하고, CD롬에 저장된 정보를 몇 분만에 분석해 스파이를 찾아내고….
  앞에 묘사한 것은 영화에 나오는 해커나 소프트웨어 개발자의 모습이다. 실제 개발자의 모습과 비슷한 부분도 있지만, 사실과는 동떨어진 묘사도 있다. 그렇다면 실제 개발자의 모습은 어떤 것일까.
  개발자를 알기 전에 개발자가 만드는 소프트웨어(프로그램)에 대해 먼저 살펴봐야 한다. 소프트웨어를 모른다면 개발자도 알 수 없기 때문이다. 우선 프로그램이라는 단어에 대해 알아보자. 신문을 펼치면 'TV 프로그램 안내'를 쉽게 찾을 수 있다. TV 프로그램 안내는 TV 순서 안내와 같다. 즉 프로그램이란 '순서'를 뜻한다. 그러나 이 설명만으로는 뭔가 부족한 듯하다. 좀더 자세히 알아보자.
  소프트웨어를 알면 개발자가 보인다 우리는 연극의 3요소, 희곡의 3요소 등을 학교에서 배웠다. 소프트웨어를 알기 위해서는 그런 요소들을 살펴보는 것이 제일 빠른 방법이 아닐까. 소프트웨어(프로그램)의 3요소는 무엇일까. '소프트웨어의 3요소'란 정의는 없지만, 대신에 70년 이후 프로그램에 대한 묘사(?)를 정리하면서 끌어낼 수 있다.
  대부분의 소프트웨어 공학 책에 나와있는 프로그램의 원론적인 정의는 <그림 1>과 같다. 입력을 받고 처리해 결과를 내놓은 것이 프로그램이라는 표현은 명확하지만, 이 정의는 프로그램의 요소 중에서 프로세스(처리)만 강조를 하고 있는 정의라 할 수 있다. 70년대에 만들어진 프로그램은 대부분 이 정의에 입각해 입력과 출력, 처리에 관한 기술을 하고 있다. 당시의 프로그램들은 업무의 범위도 매우 작았고, 극히 작은 메모리와 매우 느린 CPU에서 실행되므로 이런 정의는 매우 정확했다.
  소프트웨어 공학에서는 프로그램에 대한 다른 의미로 '실세계를 컴퓨터에서 처리하기 위해 모델링(코드화)한 것'이라는 표현(<그림 2>)도 사용한다. 이것은 프로그램이라는 것은 실세계의 투영체에 불과하다는 개념에서 비롯된 것이다. 현재는 소프트웨어가 실세계의 반영를 넘어서고 있으므로 하나의 다른 세상을 보여주고 있다. 따라서 이런 정의는 부분적인 설명에 그치고 있다.
  한편, 파스칼을 설계한 스위스 쮜리히의 공과 대학 교수인 니클라우스 워스(Niklaus wirth)는 그의 저서(Algorithm + Data Structure = Program)에서 프로그램에 대해 다음과 같이 설명했다.


알고리즘 + 자료구조 = 프로그램


 

이런 정의는 70년대 초부터 80년대 말까지는 적절한 설명이었다. 당시 프로그램들은 구조적 설계에 의해 개발되고 있었으므로 구조적 설계에 의해 프로세스와 필요한 데이터 구조를 파악하고 이를 구현하는 것이 하나의 프로그램 개발 방법이었기 때문이다. 그래서 지금까지도 대학에서는 자료구조와 알고리즘을 가르치고 있는 것이다.
  90년대 초에 그래디 부치(Grady Booch)는 객체지향적인 시각에서는 프로그램을 구성하는 객체들의 합이라고 설명했다(Program are organized as cooperative collection of objets; Object Oriented Analysis and Design second edition, Benjamin Cummings Pub, Grady Booch, 1995). 그는 니클라우스 워스의 구조적 사고에서 일보전진한 객체적 사고에서 프로그램을 구성하는 최소 단위를 객체를 선택한 것이다.


데이터 + 메쏘드 = 객체

객체 + 객체 = 프로그램


 

  그렇다면 요즘 소프트웨어 불법 사용 단속이 한창인데, 저작권법 측면에서 보면 프로그램이란 무엇일까. 컴퓨터프로그램보호법 제2조 1항에 의하면 프로그램을 저작물로 인정해 다음과 같이 설명한다.
  '컴퓨터프로그램저작물'이라 함은 특정한 결과를 얻기 위해 컴퓨터 등 정보처리능력을 가진 장치(이하 '컴퓨터'라 한다)내에서 직접 또는 간접으로 사용되는 일련의 지시·명령으로 표현된 창작물을 말한다.
  저작권법에 의해 보호받는 범위까지 고려하면 프로그램 창작물의 범위는 문서까지 확잔된다. 프로그램 그 자체 뿐만 아니라 매뉴얼, 설명서도 프로그램 저작물이 되는 것이다.


알고리즘 + 자료구조 + 문서 = 프로그램

 

  6년 전부터 필자는 다음과 같은 주장을 강력히(?) 펼치고 있다. 앞으로 소프트웨어를 개발함에 있어 외부의 드러나는 사용자 인터페이스와 내부의 프로그래밍 인터페이스가 점차 중요하게 부각될 것이며, 또한 소프트웨어를 개발하는 방법론은 프로그램의 개발에서 가장 중요한 부분을 차지하게 되리라는 이야기다.


알고리즘 + 자료구조 + 인터페이스 + 문서 + 방법론 = 프로그램


 

  이제 소프트웨어가 무엇인지 이해되는가. 지금 살펴본 프로그램의 정의는 입장에 따라서 표현은 다르지만, '어떤 절차에 의해 기술된 코드로서 컴퓨터에서 실행될 수 있는 것'이라는 사실에는 변함이 없다.
그런데 절차라는 것이 프로그래머를 다소 융통성 없는 사람으로 만들어왔다. '절차적으로 매일 작업을 하는데, 삶 자체가 그렇지 않겠어'라는 생각에서, 프로그래머는 일반인으로부터 시간관념이 매우 명확하고 절차적으로 일을 처리하는 매우 답답한 사람으로 인식돼온 게 사실이다.
  앞의 글에서 프로그램과 소프트웨어라는 단어를 혼용해 사용하고 있는데, 프로그램과 소프트웨어의 차이점은 무엇일까. 프로그램은 절차적인 진행만을 강조하는 표현이고, 소프트웨어는 하드웨어의 반대적 입장에서 제품적인 성격을 표현한 것이라 할 수 있다. 그러나 결국은 동일한 것을 가리킨다.
  개발자 명칭에 이렇게 깊은 뜻이 개발자가 누구인지 알았지만, 우리는 개발자라는 직업에 대해 더 살펴볼 필요가 있다. 이를 통해 개발자에게 한 발자국 더 가까이 다가갈 수 있는 것이다. 소프트웨어를 개발하는 직업에 대한 명칭은 크게 코더, 프로그래머, 개발자로 구분을 한다. 각 용어마다 조금씩 차이가 있다. 이 구분은 누군가가 정해놓은 것이 아니라, 개발자의 세계에서 사용되는 경우를 좀더 세밀하게 구분해 본 것이다.


◆ 코더(Coder) : 약간은 개발자를 비하하는 용어이기도 하지만, 이미 정해진 루틴에 따라 프로그램을 입력하는 오퍼레이터로 보면 된다. 외국의 경우 파워빌더와 같은 개발툴을 사용할 때, 업무 컨설턴트가 분석한 내용에 따라서 주부들이 코더로 소프트웨어를 개발한다는 이야기도 들었다.
  아무래도 일정한 패턴을 따르는 분야에서는 인건비가 저렴한 코더를 많이 사용한다고 한다. 소프트웨어 분야의 개발 자동화 시스템의 발달로 난이도 있는 개발을 할 수 있는 프로그래머는 점점 사라지고, 단순한 개발을 맡을 수 있는 코더들이 할 수 있는 일이 늘어날 것이라는 전망도 나오고 있다. 한국에서는 '이 코더 수준 밖에 안되는 놈'이라는 표현에 자주 등장하면서 비하하는 의미로 생각하는 개발자도 있기 때문에 함부로 사용하기 어려운 용어다.

◆ 프로그래머(Programmer) : 개발자라는 명칭을 사용하기 전부터 사용해오던 명칭이다. 이전에는 소프트웨어라는 단어보다는 프로그램이라는 단어가 더 널리 사용됐고, 프로그램(Program)을 만드는 사람이라는 어미(er)가 붙어 프로그래머(Programmer)가 사용됐다. 까마득한 옛날에는 프로그래머의 주요 작업이 순서도를 만드는 것이었다. 따라서 세간에는 자에 잰 듯한 생활로 고리타분한 직업의 대명사이기도 했다.

◆ 개발자(Developer) : 프로그래머보다는 일보 진보된 개념으로서 연구를 해서 제품을 만드는 사람을 의미하는 단어인데, 최근 5년 전부터 많이 사용되기 시작했다. 널리 사용되는 제품을 만들기 위해서는 이전처럼 순서도에 입각한 작업보다 더 많은 지식과 이해가 필요하므로 단순 프로그래머가 아닌, 연구자로서의 자질과 승부근성까지도 필요하게 됐다. 따라서 유명한 소프트웨어 개발자들은 프로그래머 차원이 아닌 제품의 개발자로 표현되고 싶어한다.
  프로그래머와 개발자의 차이를 억지로 구분해본다면, 프로그래머란 이미 주어진 환경 속에서 일부 모듈을 코딩하는 자를 뜻하지만, 개발자란 새로운 것을 창조해낼 수 있는 능력까지도 갖고 있는 자를 의미한다. 일부 회사에서는 프로그래머는 순서도에 입각해 코딩하는 직원으로, 개발자는 새로운 제품을 만드는 직원으로 분류하기도 한다. 이런 분류와 관계없이 프로그래머와 개발자는 혼용해 사용되고 있으나, 실제로는 현재 개발자라는 명칭을 더 선호하는 듯 하다.
  개발자는 어떻게 만들어지는가 '어떻게 해야 개발자가 될 수 있을까요'라는 질문을 많이 받는다. 기고를 많이 하다보니, 어떤 학생들은 임금을 받지 않고 일을 배울테니, 1년간만 함께 있게 해달라는 경우도 있었다. 어떻게 하면 개발자가 될 수 있는지에 대한 궁금증이 많다는 사실에 놀라게 된다.
  대개의 경우, 학원에서 3∼6개월 과정을 마치고, 소규모의 개발회사에서 1∼2년쯤 지내면 충분히 소프트웨어 개발자로 자리잡을 수 있다고 생각을 한다. 그러나 아쉽게도 그런 방법으로 자리잡은 경우에 3∼5년 이내에 개발자보다는 시스템 관리나 다른 분야의 일을 하는 경우를 많이 봤다.
  프로그래밍이란 앞서 말했듯이 논리적인 순서의 나열이며, 데이터를 조작해 사용자가 원하는 처리를 하는 것이다. 10년 전까지만 해도 개발 규모가 매우 작았으나, 1995년을 넘어서면서 그 규모가 엄청나게 커지기 시작했다. 따라서 이제는 개발이란 개인의 단위가 아니라 최소한 팀 단위다.
  규모가 커졌기 때문에 팀 단위 프로젝트의 진행에 있어서나, 다음 버전의 개선을 위해서도 개발자는 거추장스런 방법론을 싫어한다는 것을 알아야 한다. 고객을 위한 품질 관리를 위해서는 최소한 ISO 9000과 ISO 12207이라는 규격 정도는 소프트웨어 개발사에서 인증받아야 한다. 특히 해외에 소프트웨어를 납품하기 위해서는 필수조건이다.
  또한 미국 국방성에 납품하려면 CMM 레벨 3 인증을 받아야 한다. 우리 나라의 업체 대부분이 레벨 1 정도이고 이제 겨우 3개 업체만 CMM 레벨 2를 받았다고 한다. 레벨 1을 올리는데 수십 개월 이상 소요됐다는 연구 결과를 접하면 국내 기업이 1년 내에 CMM 레벨 3을 받는 것도 매우 어려운 일이다.
  팀 단위, 개발도구, 그리고 지속적인 관심과 노력 개발도구 역시 이제는 만만한 일이 아니다. 비주얼 베이직의 경우를 예로 들어 살펴보더라도 객체지향적인 개발을 위해서는 OOP와 UML 정도는 익혀야 한다. 보통 OOP와 UML을 습득하는 데만 1년 이상이 소요된다는 점을 생각하면 이 역시 쉬운 일이 아니다.
  ADO와 액티브X 기술에 대한 것들, MTS(Microsoft Transaction Server), MMQ(Microsoft Message Queue) 등을 배우는 일도 개인적으로, 혼자하기에는 한계가 있는 것이다. 비주얼 베이직에 대한 도움말만 보더라도 그 분량이 매우 엄청나다. 보기만 해도 기가 질릴 정도이다.
  즉, 이제는 개발을 하기 위해서는 소규모가 하나의 완성된 제품을 내놓기 위한 다양한 요소가 필요하다. 이를 습득하기 위해서는 참으로 오랜 기간이 필요하다. 모든 것을 습득한 뒤에 개발을 하기 위해서는 2∼3년을 공부만 한다 해도 시간이 부족하다.
2∼3년 뒤에는 또 다른 것이 나올 것이다. 비주얼 베이직 닷넷(VB.NET)만 해도 비주얼 베이직 6.0과는 전혀 다른 완전 OOP의 구조를 하고 있다. 지금까지 비주얼 베이직 개발자들이 소홀히 하던 객체지향개념을 모두 배워야 하며 게다가 XML이나 SOAP 등도 이해를 해야 하니, 산너머 산이다.
  이처럼 지속적인 관심과 노력이 매우 필요한 직업이 개발자다. 물론 회사에서 주어지는 일들만을 처리하겠다는 마인드를 가지는 개발자도 있겠지만, 2년만 새로운 기술 습득에 게으름을 피우면 2년 뒤에는 어떤 프로젝트에도 참여하기 어렵게 될 것이다.
최소한 개발도구와 언어에 대해서는 전문가가 되자. 개발도구에 대해서 전문가가 되기 위해 필요한 시간은 6개월 정도면 충분하다. 다양한 원서와 외국 저널, 외국 컨퍼런스 자료들을 공부하기에 6개월은 충분한 시간이다. 필자가 자주 가는 VBITS에서 한국 사람은 거의 찾기 어렵다. 중국인이나 일본인은 상대적으로 많이 볼 수 있다. 넓게 보면 그만큼 국내의 IT 기술에 대한 투자가 미약하다고 할 수 있다.
  그리고 많은 프로그램을 작성해보기를 권하고 싶다. 필자만 하더라도 비주얼 베이직을 처음 배울 때 500개의 예제를 혼자 만들어 비주얼 베이직의 모든 것을 직접 손으로 눈으로 머리로 체험을 했다. 500개의 예제를 만들어 연구해보는데, 필요한 기간은 고작 3개월이었다.
  대학에서 C 언어와 C++을 공부할 때도 약 30여권의 C언어 책을 읽고, 1000개의 예제를 만들어봤다. 이때 약 6개월 정도가 소요됐다. 이런 노력들은 다른 것을 습득할 수 있는 기본적인 능력을 배양을 해준다. 이런 노력 없이 전산학원을 다니거나, 전산과 전공을 한다 해도 그것은 크게 도움되지 않을 것이다.
  이런 과정을 통해 개발도구나 언어에 익숙해지면 프로그램을 개발할 수 있는 기본기는 충분히 갖춘 셈이다. 이제는 개발하면서 효과적인 개발에 대해 관심을 가져야 한다. 대부분의 개발자들이 개발의 결과에만 집착한다. 소프트웨어는 그 특성상 성능과 기능 개선이 지속적으로 진행되지 않는다면 그 생명력을 잃는데, 개발한 소스가 체계적으로 개발돼 있지 않다면 다음 버전은 새로운 출발을 해야 한다.
  따라서 개발자가 좋은 소프트웨어 개발에 대해 관심을 갖게 되면 방법론과 소프트웨어 공학에 대해 새로운 시각을 가지게 되는 것이다. 소프트웨어 공학이나 방법론은 이론으로만 배운다면 적용하기도 어렵고 적용 자체가 피상적이므로 좋은 효과를 얻을 수가 없다.
  학원 교육과 자격증 취득의 허실 혼자 공부하기 어렵다면서 학원을 추천해달라고 필자를 찾는 경우가 많았다. 그러나 국내에서 프로그래밍을 제대로 가르칠 수 있는 학원은 거의 없다고 할 수 있다. 이렇게 단정짓는 이유는 학원의 교과과정이 개발도구에 치우쳐 있거나 기초적인 이론에만 치우쳐 있기 때문이다.
  이것은 학원이 상대적으로 많은 비용을 차지하는 강사 비용을 줄이기 위해 주당 강의 시간을 줄이기 때문이다. 또한 유능한 강사의 경우 그 비용이 만만치 않으므로 그보다는 다소 지도 능력이나 경험이 떨어지지만 강의료가 덜 비싼 강사들을 선호하므로 더욱더 강의의 내용이나 질은 떨어진다.
  그래서 필요한 과목별로 제대로 가르치는 강사들을 찾아다니면서 배우는 것이 다소 비용이 들더라도 효과적인 방법이 아닐까라는 생각도 해본다. 문제는 능력(?) 있는 강사를 찾아내는 것이긴 해도, 도전해볼만한 가치는 있다.
실제로 필자는 국내에서 유명한 S사의 M학원에서 오라클에 대한 교육을 받은 적이 있다. 단기간의 프로젝트를 진행하기 위해 오라클에 대한 지식을 단기간에 얻을 수 있는 좋은 방법이라고 생각해 교육을 받았는데, 강사는 유창한 영어발음으로 책만 내내 읽으며 질문을 해도 질문 자체를 이해하지 못하거나 매우 형식적인 답변으로만 일관했다. 굴지의 M학원에서 이 정도라면 다른 학원들은 말할 나위도 없다.
  또한 M학원의 소프트웨어 전문가 과정을 졸업하면 MCSE와 MCSD를 취득하는 놀라운 실적을 보여주고 있지만, 실제 자격증 취득자를 면접한 결과 가장 기초적인 프로그래밍 상식조차 없는 경우도 있었다. 페이퍼 자격증의 폐해를 그대로 보여주는 것이다. 외국에서는 경력 없는 자격증은 인정조차 안되므로 학생이나 무경력자가 자격증을 취득하는 일은 그리 많지 않다고 한다.
MCSE란 최소한 2∼3년의 경력을 보증하는데, MCSE를 취득하고도 NT 설치가 안되면 그 원인을 파악하지 못하니 자격증이 보증하는 것이 도대체 무엇인지 모르겠다. 특히 국내에서는 고등학생들도 MCSE 자격증을 가지고 있다고 하니 외화낭비라는 생각까지 든다.
  빌게이츠와 스티븐잡스를 생각하라 개발자라면 가장 기초적인 전산의 학문에 대해서도 소양을 갖춰야 한다. 예를 들어서 알고리즘이나 데이터구조, 데이터베이스, 객체지향프로그래밍, 소프트웨어공학, 컴파일러 이론 등에 대해서는 기초지식을 습득해야 한다.
  유명한 개발자들은 대부분 기초학문에 있어서는 상당한 이론가임을 알 수 있다. 그런 기초가 없다면 모래 위에 집을 짓는 것과 같다. 필자가 큐(Queue)를 작성하는데 걸리는 시간은 30분 정도다. 동일한 작업을 전산과 4학년에게 시켰더니 약 5일이 걸렸다.
그 간단한 프로그램을 디버깅하는데 그렇게 오랜 시간이 걸리다니! 기초 학문에 대한 몰이해와 프로그래밍에 대한 연습이 부족하다면 충분히 발생할 수 있는 일이다. 이런 수준으로는 전산과를 나왔다고 말하기가 창피한 수준이다.
  '개발자 동의보감'에서도 이야기했듯이 개발자가 되겠다고 교육을 받아도 일부만이 개발자로 성장하고, 대부분은 다른 직업을 찾는다. 실제로 프로그래밍을 해보니, 그 과정이 '생 노가다'나 '허드렛 일'이어서 금방 실증이 나고, 시간 낭비로 치부해 버린다.
그러나 잘 생각해보면 미술가는 붓질을 통해 예술품을 만들고 소설가는 펜대를 굴려 베스트 셀러를 만들어낸다. 소프트웨어 개발로 성공한 빌게이츠와 스티븐잡스를 생각해보라, 그들이 한 생 노가다가 이뤄낸 결과를 바라보라.
  앞으로 나의 길은 어디에 소프트웨어 개발에 대해 대학이나 학원에서 배우고 나면, 그 다음 행로는 어디인가. 개발자가 가야할 길은 소프트웨어 개발뿐인가, 아니면 다른 길들도 있단 말인가. 개발자들의 역할은 어디까지인가 이런 내용들을 설명하기 위해서 가상적으로 소프트웨어 개발 회사(부서)를 세우고, 이 개발 회사에 필요한 인력들의 배치도를 만들어 소프트웨어에 관련된 직업들을 찾아보겠다. 직업별로 업무 영역이 구분되므로 배워나가야 할 방향도 다르다.
  개발업체에 따른 분류 먼저 회사를 세우려면 회사의 특징을 명확히 세워야 한다. 개발자가 근무하게 되는 회사의 종류를 명확히 나누기는 어렵지만, 근무하는 부서는 크게 네 가지 유형으로 나눌 수 있다. 어떤 회사는 이런 유형의 부서를 모두 갖추고 있는 경우도 있다.


  전산실(업무 개발실)

  패키지 개발(제품 개발실)

  외주개발(시스템 통합)

  IT 컨설팅


  전산실 전산실은 일반적인 기업의 내부에 있다. 자사의 업무를 파악해 필요한 시스템을 개발한다. 기업의 전산실은 다소 안정적이지만, 기업의 활동에 초점이 맞춰있어 기존 시스템의 유지 보수에 치우친 일이 많다.
  따라서 중소기업의 전산실은 새로운 기술을 도입하거나 습득하기 어렵고, 기업의 전산화를 위해 경영진을 직접 설득해야 하는 어려움에 부딪혀 좌절하는 경우가 많다고 한다. 경험자의 증언(?)에 의하면 대기업의 전산실도 외주 관리를 주로 하거나, 주어진 업무만을 담당하므로 역시 새로운 기술 습득에는 어려움을 겪고 있었다.
  특히 전산실에서 가장 핵심적인 인력은 업무를 아는 전산인력이므로, 제조업의 전산실의 경우 정규 전산을 배운 사원보다는 3년 이상의 업무 경험자가 특정한 기회에 전산을 배워 전산실로 발령난 사람들이 많다고 한다.
  패키지 개발 패키지 개발 업체는 패키지 제품(박스 제품)을 만들고 그 매출로 운영을 한다. 따라서 충분한 자금이 없는 경우가 많고, 개발 기간이 상대적으로 오래 소요되므로 운영에 매우 큰 어려움을 겪는다.
  그러나 상대적으로 인력들 사이에 유대관계가 좋고, 패키지가 시장에서 좋은 반응을 얻게 되면 판매가의 20% 정도의 높은 수익을 올릴 수 있으므로 소프트웨어 개발에 자신의 모든 것을 바치는 경우가 많다. 급여는 가장 낮은 편이지만, 대개 일에 만족하는 경우가 높다. 통상 개발자라고 할 때 패키지 개발 업체의 프로그래머를 가리키기도 한다.
  패키지 개발 업체는 제품이 갖는 한정된 범위의 기술과 내용에만 관심을 가지므로 의사결정의 범위가 다소 좁은 경우가 많다. 이것은 관심 밖의 기술들은 시장이 원할 때만 습득하게 되는 원인이 될 수 있다. 따라서 신기술의 습득보다는 기존 제품의 기술을 그대로 유지하려는 성격이 강할 수 있다.
  외주개발 외주개발을 주로 하는 업체는 인력파견 업체 또는 시스템통합 업체라고도 한다. 대형 프로젝트는 대기업이 수주를 해 인력관리만을 맡고, 실제 개발은 인력파견업체의 개발자들이 작업을 한다.
  예를 들어 대기업에서 M/M 비용을 600만원에 프로젝트를 수주하면 브로커업체에게 400만원에 하청을 줘서 5개정도의 인력파견업체를 모으도록 한다. 브로커업체는 다시 인력파견업체에 200∼300만원을 주고 인력공급을 받는다.
  급여의 수준은 인력파견업체가 높은 편이다. 대형 프로젝트의 경우 유지보수, 후속 개발 등의 작업들이 많으므로 개발자의 투입율이 100%를 넘어서 150%(한 사람이 1.5개의 프로젝트에 참여)인 경우들이 많으므로 충분한 자금 회전이 가능하기 때문이다.
그러나 수주한 프로젝트가 새로운 기술 요구 사항이 많고 단기간에 종료돼야 하므로 개발자의 스트레스가 매우 심한 편이다. 그래서 인력파견업체의 개발자는 하나의 프로젝트가 종료되면 회사를 옮기거나 프로젝트 도중에 그만두는 경우가 많으므로 인력의 이동이 심한 편이다.
  IT 컨설팅 IT 컨설팅 업체는 기술 컨설팅, 업무 컨설팅, 감리 컨설팅으로 구분될 수 있다. 업무 컨설팅 분야는 해당 분야의 업무 경력(대개는 MBA, CPA등 요구)이 필요하므로 개발자가 쉽게 도전하기 어렵고 기술 컨설팅이나 감리 컨설팅 분야는 도전해볼만 하다. 컨설팅은 상담과 브리핑을 통해 고객에게 필요한 것을 파악해 리포트 형태로 제공하는 업종이다.
연봉은 일반 개발 회사에 비해 2∼3배를 받는다. 대부분의 개발자가 꿈꾸는 직업이기는 하지만, 이런 회사들은 정확한 발음, 다소 높은 학력을 요구하는 편이서 취업이 쉽지 않다.
  개발 분야에 따른 분류 회사나 부서별 특성을 대략 이렇게 파악할 수 있지만, 개발 분야는 다른 이야기가 될 수 있다. 패키지 개발 업체라고 하더라도 유틸리티를 만들 수도 있고, 개발도구를 만들 수도 있기 때문이다. 그래서 개발 분야에 대해서도 알아야 한다.
개발 분야는 크게 나누면 <표 1>처럼 7가지 정도로 나눠볼 수 있다. 프로그램의 예는 출시 연도나 구성요소에 따라 약간씩 변할 수 있다. 예를 들어 웹 브라우저의 경우 인터넷 익스플로러는 시스템 프로그래밍에 가깝지만, 동일한 성격이라도 오페라는 유틸리티의 성격에 가깝다.
  우리 나라는 90년대초 K-DOS 이후에 운영체제에 대한 연구가 거의 진행되지 않다가 최근 다시 리눅스를 대상으로 한 바람이 크게 불고 있다. 개발툴 분야도 몇몇 제품이 나오기는 했으나 세계적인 제품으로 성장하지는 못했다.
  나모 웹에디터가 세계 시장에서 좋은 반응을 얻고 있다고 하니 좋은 소식을 기대해본다. 유틸리티 분야는 거원의 제츠오디오가 외국에서 폭발적인 인기를 얻어 널리 사용되고 있다. 다른 분야에서는 이렇다할 제품이 나오지 못하고 있거나 이제 시작 단계다.
업무에 따른 분류 지금까지 회사와 개발제품에 대해 알아봤는데, 소프트웨어 개발 업체라 해서 무조건 개발자로 근무하는 것은 아니다. 그 안에도 여러 가지 업무가 있고, 업무에 따라 다양한 직업이 있다. 여기서는 국내 컴퓨터 분야의 직업 뿐만 아니라 외국의 예도 함께 넣었다. 다만, 명칭은 국내의 명칭으로 통일했다. 참고로 디자인 분야의 다양한 직업을 반영하면 훨씬 더 많은 직업이 있겠지만, 여기서는 웹 디자이너에 한정시켰다.


제품개발자 : 박스로 팔리거나 다운로드 형태로 팔리는 패키지 제품을 개발한다.

시스템통합개발자 : 외주 개발에 참여하는 개발업무를 담당한다.

시스템프로그래머 :드라이버나 운영체제 기능의 일부를 개발한다.

품질관리자 ː 최근 2∼3년 사이에 나타난 대형 SI 프로젝트의 소프트웨어 품질관리 책임자를 말한다. 세부 업무를 보면 형상관리,

 

위험관리 등의 업무를 맡고 있다. ISO 9000, ISO 12207에 대한 연구를 별도로 해야 한다.

업무분석가 ː 주로 기업의 회계나 운영 시스템에 대한 업무를 컨설팅해 해당 조직에 맞는 설계를 내놓는 역할을 한다. 업무능력과

IT 능력을 어느정도 겸비하면 상대적으로 많은 연봉을 받을 수 있기 때문에 경영, 회계, 산업공학을 전공자가 많이 지원을 하는 분야다. 국내에 있는 외국계 컨설턴트들은 대개 업무분석가 또는 업무 컨설턴트인 경우가 많다.

프로젝트관리자 ː 프로젝트 진행의 모든 책임을 맡고, 예산부터 최종 결과물을 일정에 맞춰 진행하도록 감독한다. 현재는 경력 5년 이상인 개발자가 맡는 경우가 많은데, 프로젝트 관리를 제대로 하려면 SPICE나 CMM에 대한 학습이 필요하다.

전문테스터 ː 전문테스터는 아직 국내에서는 정착되지 않은 직업이다. 보통 개발자로서는 능력이 부족하지만, 개발을 이해할 수 있는 자가 그 역할을 담당하거나 신입사원이 담당하는 경우가 많다. 외국에는 개발자 1명당 테스터가 2명이라는 말이 있을 정도로 프로그램의 테스터에 대한 중요성을 인식하고 있지만, 국내에서는 개발자가 테스트까지 전부 맡아하는 경우가 많다. 그러나 이 분야도 앞으로는 품질관리가 중요해지면서 전문화될 가능성이 크다.

시스템엔지니어 ː 개발된 소프트웨어의 설치와 설치시에 발생하는 문제점, 운영시에 발생하는 문제에 대한 대책을 기술 지원하는 역할을 맡고 있다. 대개는 시스템엔지니어링 교육을 받거나, 운영체제를 잘 다루는 개발자가 맡기도 한다.

웹 디자이너 ː 웹 디자이너는 웹에서 필요로 하는 이미지 제작 업무 외에 DHTML과 자바 스크립트를 사용해서 홈페이지를 구성할 수 있는 능력을 갖춰야 한다. 웹 디자이너를 보면 이미지 도구에 의존적인 경우와 스스로 이미지를 창조하는 능력을 가진 경우로 나뉘는데, 창조력이 없다면 이미지 제작은 한계에 부딪히게 된다.

아키텍처 ː 소프트웨어에 대한 비전과 미래, 방향을 제시하는 사람으로서 미국의 빌게이츠 회장이 마이크로소프트에서 이 역할을 맡고 있다. 일반적으로 CIO가 전산 정책 결정의 최고 의사결정자라면, 아키텍처는 소프트웨어의 개발 방향 결정자라는 점에서 조금 차이가 있다.

기술컨설턴트 ː IT 관련 기술에 대한 컨설팅을 주업무로 한다. 국내에서는 활동하는 컨설턴트가 몇 명 되지 않는다. 기술 컨설턴트는 이론과 실무를 겸비해야 하므로 30대 초반의 차장급이어야 하는데, 국내에서는 병역문제로 30대 초반에 개발경력 경력 7∼9년차인 차장급이 거의 없기 때문이다.

감리컨설턴트 ː 국내에서 활동하는 컨설턴트의 대부분이 이에 해당하는데, 개발 전에는 업체 평가업무를 개발 후에는 개발된 소프트웨어에 대해 평가하는 역할을 한다. 대개 40대 후반에서 50대 초반에서 많이 활동하는 분야다. 감리 컨설턴트는 ISO 9000 심사관 자격증을 하나 정도는 가지고 있다.

전문기고가 ː 전문기고가는 기술분야의 기고를 업으로 한다. 국내 여건상 기고료가 매우 낮은 편이고, 출판사에서 높은 인세를 꺼려하고 있다. 게다가 책이 많이 팔려야 1만부이고 대부분 2∼3천부 정도만 팔리므로 생계 유지가 어려워 대부분 강사를 겸하고 있다. 외국에서는 전문 기고가는 백만장자들도 많다는 점에서 우리 나라와는 많은 차이를 보인다.
이와 같이 회사, 부서에 따라 요구되는 개발자의 성향도 다르고 같은 회사에서 내에서도 역할에 따라 다양한 직업이 있다는 점을 생각해 진로를 정하기 전에 많은 고려를 할 필요가 있다. 한 번 발을 들이면 분야를 바꾼다는 것은 매우 힘들므로 최소한 5년 앞을 내보다고 진로를 결정해야 할 것이다.

  마지막으로 소프트웨어 분야가 여성적인 직업이라는 점에 주목을 하자. 섬세함과 정교함이 요구되는 분야가 바로 소프트웨어 분야다. 그런데 정작 여성들은 개발자로서의 능력을 인정받는 경우가 매우 드물다. 그보다는 여성스러운 남성, 섬세한 남성들이 더 두각을 나타내고 있다.
  이런 현상은 여성들이 밤낮없는 근무시간과 끝없는 변화의 요구를 수용하기 어렵기 때문으로 보인다. 또한 여성 개발자에 대한 경영자나 관리자의 기피현상도 들 수 있다. 여성 개발자는 프로젝트가 완료되기 전에 그만두는 경우가 왕왕 있고, 서약서를 쓰고서도 계약근무기간을 지키지 않거나, 남자보다는 사소한 이유로 회사를 그만두는 일이 많다는 것이 경영자의 불만이다.
소프트웨어 개발분야는 그 어떤 분야보다 여성이 진출하기 쉬운 분야인데, 몇 가지 장벽으로 그 능력을 제대로 발휘하지 못한다면 국가적인 손실이라고 할 수 있다. 여성이 필요한 곳에 여성이 기피된다는 것은 사회적인 편견도 있겠지만, 소프트웨어 개발사의 근무형태 개선 없이는 여성이 제대로 역할을 하기 어렵다.
  어떤 개발자가 될 것인가 요즘 IT 업계에 사람이 부족하다고 컴퓨터와 관련이 거의 없던 사람들도 프로그램 개발을 배우겠다고 마구잡이로 덤벼들고 있다. 배우는 것도 좋지만, 개발자로서의 가능성에 대해서는 한번쯤 생각해야 할 것이다. 다음과 같이 개발자가 갖춰야 할 다섯 가지 능력을 기준화했다.

  협동심 : 함께 일할 때 얼마나 동료애를 발휘하며 조직 친화적인지를 나타낸다.

  기술력 : 작업의 기술적 능력으로 개발능력을 나타낸다.

  학습력 : 최소한 영어능력과 지속적인 학습이 가능한지를 나타낸다.

  인간성 : 사람됨됨이를 나타내는 것으로 측정하기 가장 어려운 항목이다.

  인내력 : 실증내지 않고, 얼마나 오랫동안 작업할 수 있는가를 나태낸다.

  이 다섯 가지 능력을 5단계로 나누고, 이 단계를 점수화해 선을 연결하면 자신의 개발자로서의 성향을 알 수 있다. 가장 높은 점수가 5이고, 가장 낮은 점수가 1이다. 여기서는 점수별로 해당하는 예시가 없어 점수화가 다소 어렵지만, 대략적으로 3을 평균으로 생각해 상대적으로 값을 매긴다.
  이 방법은 주로 약점을 분석하기 위해 사용되는 방법인데, 개발자의 유형을 파악하는 데에 적용을 해본 것이다. 아마 <그림 3>처럼 거의 정오각형의 유형이 완전한 개발자의 모습일 것이다. 그러나 이 모두를 다 갖춘 사람은 거의 찾기 힘들다. 실제적으로는 <그림 4, 5, 6>과 같은 형태가 나타나게 된다.
  <그림 4>와 같이 마름모가 나타나는 경우에는 개발자보다는 프로젝트 관리자쪽으로 눈을 돌려보는 것도 좋을 것이다. 기술은 다소 떨어져도 사람을 관리하고 작업에 대한 추진력이 높기 때문에 프로젝트 관리쪽으로 매진하면 좋은 결과를 얻을 수도 있다.
<그림 5>와 같이 우측지시자형은 기술력이나 학습력에 강하나 인간성 부분이 부족해 대인관계에는 어려움이 많다는 것을 뜻하므로 IT 컨설팅에 매진하는 것이 좋다. IT 컨설팅의 경우 단체 작업보다는 업체와 컨설턴트가 단독으로 작업하는 것이 많고 컨설팅을 위한 학습력이 매우 많이 요구되므로 우측지시자형에 적합하다.
  <그림 6>과 같은 사다리꼴형은 인내력이나 협동력이 상대적으로 매우 부족하므로 이런 경우에는 개발에 있어 코어라이브러리를 만드는 작업을 할당받는 것이 좋다. 라이브러리는 특성상 작업량은 적으나 꽤 많은 기술력을 요구하므로 누운 사다리꼴의 경우에 적합하다.
  이와 같이 자신을 판단할 수 있는 좋은 척도가 되므로 직접 스스로의 유형을 테스트해보기를 권한다. 나는 개발자로서 어떤 특성을 갖고 있는지 알 수 있다면 업무를 선택하거나 회사를 선택할 때도 도움이 되리라 생각한다.
  개발자란 예술가와 공학도의 야누스 어느 벤처기업의 이야기는 좋은 개발자의 필요성을 온몸으로 느끼게 해준다. K 기업은 지난해에 S대의 재학생에게 음성합성프로그램 개발을 용역을 줬는데, 개발된 프로그램의 성능이 외국에 비해 세 배 이상이었다.
  그러나 프로그램은 더 이상 개선되지 못하고 제품화에도 실패를 했다. 그 이유는 뛰어난 성능의 프로그램임은 분명한데 개발한 학생 외에는 아무도 수정할 수 없었기 때문이다. 학생은 개인적인 이유로 유학을 떠났고, 남은 개발자들이 제품화를 맡았는데, 여기를 수정하면 저기가 에러가 저기를 수정하면 여기에서 에러가 발생하니, 아무도 그 소스를 수정하지 못했다고 한다. 결국 그 기업은 2년간 투자한 사업을 접어야 했다.
 

 뛰어난 개발자들이 많지만, 좋은 개발자가 적은 이유는 무엇일까. 뛰어난 개발자와 좋은 개발자의 차이는 무엇일까. 그것은 단순한 능력 이상의 것이 요구된다는 것이다. 좋은 개발자가 되기 위해서는 최소 3∼5년 이상의 경력을 가지면서도 스스로 제품을 만들기 위한 정열과 제품을 만드는 능력을 갖는 것은 기본이다. 그 능력 외에 품질을 유지하기 위한 마인드가 필요하다. 그런 마인드가 없다면 좋은 소프트웨어를 만들 수 있는 좋은 개발자란 없다.
  국내는 IT 벤처의 열풍으로 수만명의 학생이 전공과는 관계없이 전산을 배운다고 한다. 지난 1년간에 정부에서 전산관련 취업교육에 사용한 비용만 수천억원에 이른다. 학원은 여기저기서 강사 구하기에 바쁘다고 한다. 그러나 속지 말라. 한줌의 지식보다 더 중요한 것은 마인드라는 것을!

  개발자란 예술가적인 정렬과 예리함, 감각을 지녀야할 뿐 아니라 평가하고 측정하고 품질을 유지하는 능력 또한 지녀야 한다. 왜 우리는 전세계적으로 팔리는 소프트웨어가 거의 없느냐의 문제에 대한 답이 아닐까 한다.
  바로 좋은 개발자가 없기 때문이다. 좋은 개발자의 능력을 가진 자가 한국에 있다고 해도 사회적 문화적 환경이 뒷받침되지 못한다면 개발자는 그 빛을 발하기 힘들다. 바로 여러분이 좋은 개발자이길 바란다. 오늘도 '개발의 득도'를 위해 전진해보자.

  정리 : 이종림 nowhere@sbmedia.co.kr

Posted by SB패밀리
당신이 개발자라면 한 번 이상 생각해보자.
가능한 결론이 날 때까지...
나는 개발자로서 어떤 위치에 있고 사회는 어떤 위치를 원하고 있는지!



SI/SM 의 세계에서 개발자는 Coder < Programmer < Engineer < Architect < Consultant 로 성장하게 된다.

    물론 반드시 그렇지는 않지만, 의미적인 부분을 말하고자 하는 것이니 그것을 이해해주었으면 한다. 분류가 칼로 무 자르듯이 딱 떨어지지 않는 것은 당연한 것이다. 어떤 경우는 Engineer, Architect, Consultant 역할을 동시에 수행해야 하는 경우도 있다.

 

    1. Coder 란 코딩된 소스를 잘 이해하지 못하고 오려붙이기 하면서 단순히 소스를 만드는 사람을 의미한다. 어떠한 요구사항에 의해 프로그램을 만드는 것인지 알지 못하면 Coder 에 해당한다고 보면 된다.

   단순 작업에 해당하며, 고급 개발자도 때로는 이런 단순작업을 하기도 한다.

   Coder 는 고객을 만나지 않으며, PL 로부터 요청된 개발로직에 대해 Coding 업무를 수행한다.

 

    2. Programmer 란 기술적인 요구사항에 대해 스스로 그것을 처리할 수 있는 로직을 만들 수 있는 사람을 의미한다.

    프로그래머는 다양한 언어스킬을 가지고 있어야 하며, 때로는 소스 및 어플리케이션의 효율성을 높이기 위해 몇 개의 언어를 조합하여 사용할 수도 있어야 한다.

    또한, 프로그래머는 라이브러리 등 소스 수준의 것들을 조합하여 원하는 기능을 만들어내기도 한다. 프로그래머는 고객을 만나지 않으며, 기술적이지 않은 용어를 사용한 대화에 대해 익숙하지 않기 때문에 만난다고 하더라도 고객의 요구사항을 이해하지 못한다.

    또한, 자신의 의견을 고객에게 잘 인식시키지 못한다.

    단지, Coder 보다는 좀 더 쉽게 일을 줄 수 있고, 더 좋은 품질의 일은 하지만, 때때로 사람의 특성에 따라 반드시 Output 을 챙겨줘야 하는 경우가 있다.

 

    3. Engineer 는 프로그래밍에 대한 경험 뿐 아니라, 어플리케이션에 관계된 제반 제품(Product)에 대한 해박한 지식이 있어, 보다 완벽한 시스템을 구축하기 위해 이를 활용할 수 있는 사람을 의미한다.

    이 단계의 사람은 "Trouble Shooting"을 할 수 있다. 즉, 어플리케이션이 오작동하거나 에러를 낼 때, 오라클을 튜닝해야 할 지, 서버(H/W)를 튜닝해야 할 지, 웹로직을 튜닝해야 할 지를 알고 대처할 수 있는 사람들이다.

    엔지니어는 시스템의 전체적인 퍼포먼스와 조합을 위하여 부분적인 기능과 성능을 어떻게 해야할 지를 잘 아는 사람이다. 이는 프로그램에 대한 경험과 이해가 없으면 잘 해낼 수 없다.

   통상적으로 엔지니어란 전체적인 조화를 위해 시스템의 필수기능 이 외의 것을 튜닝하는 일을 한다.

   이 직능군의 사람이 없으면, 시스템 개발이 완료가 되더라도 부조화에 의해 시스템이 기존 Legacy 로부터 배척되는 현상이 발생된다.

   엔지니어는 고객 수준의 용어로 쉽게 대화할 수 있으며, 고객의 막연한 불만이 기술적으로는 어떻게 매칭될 수 있는지에 대한 경험을 가지고 있다.

   즉, 그들은 고객이 "웹이 이상해요." 라고 말하면, 어떻게 이상한지 잘 유도해서 묻고, DB나 소스, 아파치 등을 뒤져서 그 이상한 현상이 해결되도록 한다.

 

    4. Architect 란 하드웨어 제품군, 소프트웨어 제품군, 미들웨어 제품군, 데이터베이스 제품군까지에 대한 전반적인 이해를 바탕으로 업무특성에 맞게 어플리케이션을 중심으로 제품군을 배열할 수 있는 그림을 그릴 수 있는 사람을 말한다.

   이 사람들은 인터넷뱅킹처럼 실시간 트랜잭션 처리형(OLTP) 업무를 구현하는데 서버 한 두대를 넣는 구성을 절대 그리지 않는다.

   아키텍트는 고객과 잘 대화하는 수준을 넘어 고객의 사업 및 실무를 잘 이해한다. 즉, 업무가 월말에 한꺼번에 처리되는지, 일정산이 반드시 필요한지 등에 대한 이해를 바탕으로 시스템을 구축한다.

   고객의 업무를 듣고 트래픽 패턴을 분석하고, 소프트웨어 아키텍쳐,어플리케이션 아키텍쳐, 하드웨어 아키텍쳐를 결정하고 구현한다.

   이 직능군의 사람이 없으면, 시스템이 월초마다 이유없이 다운되기도 하거나, HW 증설을 해도 트래픽이 소화되지 않은 현상들이 일어난다. 또한, 용량확장 시 쉽게 이를 구현할 수 없다.

 

    5. Consultant 란 고객이 상상하는 비즈니스 모델을 현실화하기 위해 업무프로세스에서부터 시스템까지 모든 그림을 그려주고 이를 실행시켜주는 사람을 말한다.

    IT 와 함께 고려된 업무프로세스는 전통적인 산업기반에서는 존재하지 않는 것이어서, 언제나 새로 만들어지거나 업그레이드 되어야 하는데, 그들은 고객의 사업을 잘 이해하여 그 사업의 틀에서 서비스를 구현해주는 사람이다.

 만일 당신이 소규모의 온라인 쇼핑몰을 운영하고 싶다면, 컨설턴트는 회계관리에서부터 납품관리 및 홈페이지관리 등 모든 것을 상담하고 거기에 필요한 시스템을 납품하며, 잘 운영하고 있는지 사후관리도 해준다.

   컨설턴트는 "돈이 있는 사람들"을 위해 꿈을 현실로 만들어주는 사람들이다.

   비록 사업 결과에 대해서 책임지지는 않지만, 사업가가 성공할 수 있도록 파트너로서의 역할을 충실히 수행해 낸다. 컨설턴트가 없으면 고객은 처음부터 끝까지 스스로 알아서 해야 하며, 위험한 시기에도 쉽게 외부의 도움을 얻을 수 없다.

Posted by SB패밀리