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

[웹] 웹퍼블리셔(Web Publisher)란



웹퍼블리셔(Web Publisher)란

웹표준 및 DOCTYPE를 인지하지 못하는 개발자가 작업하여 나오는 결과물이 IE와 그 외 브라우저에서 특정한 부분만 인식하는 스크립트와 그렇지 않은 스크립트, XHTML과 HTML 태그 사용법 등을 미리 선정하여 큰 문제가 없도록 최대한 디자인을 살려 개발 영역을 넓혀줄 수 있는 역할을 하는 것이 퍼블리셔이다.

 

수행직무)

퍼블리셔는 코더의 역할 뿐만이 아니라, 전체적인 프로젝트의 인식, 그리고 웹 접근성과 크로스미디어, 크로스 브라우저 같은 좀 더 많은 사용자에게 퍼블리싱(인쇄 , 출력)을 할 수 있는 환경을 제공하고자 하는 것에 좀 더 초점이 맞추어져 있다. HTML과 CSS를 활용한 효율적이고 빠른 그리고 수정 용이한 코드 작성을 목적으로 한다.

 

변화를 읽는 자기계발, 흐린 취업시장에서 성공의 길!

뜨는 IT 직종, 웹 퍼블리셔

 

IT 관련 직종의 수명이 짧아지면서, 새로운 직종에 속속 등장하고 있다. 올해 채용시장에 가장 두드러진 직종으로 평가되는 분야는 웹퍼블리셔.

4 11장애인차별금지 및 권리구제에 관한 법률(장차법)’의 시행에 따라 모든 공공기관과 종합병원, 복지시설, 특수학교 및 장애전담 보육시설 등의 홈페이지에 대한 장애인을 위한 웹 접근성이 갖춰지도록 의무화 되었고, 정부 공공기관의 웹 접근성 개선사업이 크게 늘면서 각 취업사이트마다 웹퍼블리셔를 모집하는 공고가 넘쳐나고 있다.

 

웹퍼블리셔는웹 표준 및 웹 접근성 전문가라고 정의할 수 있으며 웹 표준과 그 주변의 다양한 웹 관련 기술에 전문성을 지니고 있는 웹의 구현(출판)을 담당하는 새롭게 부각되는 업무를 행하는 사람을 지칭하기 위한 용어이다.
웹퍼블리셔가 웹표준 구현을 위하여 갖추어야 할 스킬은 아래와 같다.
• HTML, CSS, Javascript
에 대한 관심
• XHTML
마크업 및 W3C DOM을 사용한 자바스크립트 개발 역량
• XHTML
CSS로 구조와 표현 분리 개발 방법에 대한 이해
웹접근성 및 웹표준에 대한 이해
개발자와 디자이너, 컨텐츠 설계자와의 원할한 커뮤니케이션 역량
사용자 중심의 UI에 대한 관심과 이해
소수 사용자를 배려하는 마음

 

급격한 수요 증가에 대응하기 위해 강좌를 개설한 미즈 평생교육원에서는 웹표준/웹접근성 전문강좌를 개설하여 새로운 인터넷 환경을 이끌어갈 인력을 배출하고자 수강생을 모집하고 있다

Posted by SB패밀리

1. 자신의 기술(cratf)에 관심과 애정을 가져라.
 : 소프트웨어 개발을 잘 해보려는 생각이 없다면 왜 인생을 그 일을 하면서 보내는가?

2. 자신의 일에 대해 생각하면서 일하라!
 : 자동 조종 장치를 끄고 직접 조종하라. 스스로의 작업을 지속적으로 비판하고 평가하라.

3. 어설픈 변명을 만들지 말고 대안을 제시하라.
 : 변병하는 대신 대안을 제시하라. 그 일은 할 수 없다고 말하지 말고, 무엇을 할 수 있는지
   에 대해 설명하라.

 4. 깨진 창문을 내버려두지 말라.
 : 눈에 뜨일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라.

 5. 변화의 촉매가 되라.
 : 사람들에게 변화를 강요할 수는 없다. 대신, 미래가 어떤 모습일지 그들에게 보여주고 미래를 만드는 일에 그들이 참여하도록 도우라.

 6. 큰 그림을 기억하라.
 : 주변에 무슨 일이 일어나는지 점검하는 일을 잊어버릴 정도로 세부사항에 빠지지 말라.

 7. 품질을 요구사항으로 만들어라.
 : 프로젝트의 진짜 품질 요구사항을 결정하는 자리에 사용자를 참여시켜라.

 8. 지식 포트폴리오에 주기적으로 투자하라.
 : 학습을 습관으로 만들어라.

 9. 읽고 듣는 것을 비판적으로 분석하라.
 : 벤더, 매체들의 야단법석, 도그마에 흔들리지 말라.

   여러분과 여러분 프로젝트의 관점에서 정보를 분석하라.

 10. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
 : 효과적으로 전달하지 못한다면 좋은 생각이 있어봐야 소용없다.

 11. DRY - 반복하지 마라(Don't Repeat Yourself)
 : 어떤 지식 한 조각도 하나의 시스템 안에서는 모호하지 않고, 귄위 있고, 단 하나뿐인 표현을 가져야 한다.

 12. 재사용하기 쉽게 만들라.
 : 재사용하기 쉽다면, 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들라.

 13. 관련 없는 것들 간에 서로 영향이 없도록 하라.
 : 컴포넌트를 자족적이고, 독립적이며, 단 하나의 잘 정의된 목적만 갖도록 설계하라.

 14. 최종 결정이란 없다.
 : 돌에 새겨진 것처럼 불변하는 결정은 없다.
   그렇게 생각하는 대신, 모든 결정이 해변의 백사장 위에 쓴 글자와 같다고 생각하고 변화에 대비하라.

 15. 목표물을 찾기 위해 예광탄을 써라.
 : 예광탄은 이것저것을 시도해보고 그것들이 목표와 얼마나 가까운 데 떨어지는지 보는 방법으로 목표를 정확히 맞추게 해준다.

 16. 프로토타입을 통해 학습하라.
 : 프로토타이핑은 배움의 경험이다. 프로토타이핑의 가치는 만들어낸 코드에 있지 않고,
   여러분이 배운 교훈에 있다.

 17. 문제 도메인에 가깝게 프로그래밍하라.
 : 사용자의 언어를 사용해서 설계와 코딩을 하라.


18. 추정을 통해 놀람을 피하라.
 : 시작하기 전에 추정부터 하라. 잠재적인 문 제점들을 미리 찾아내게 될 것이다.

 19. 코드와 함께 일정도 반복하며 조정하라.
 : 구현하면서 얻는 경험을 이용해서 프로젝트의 시간 척도를 세밀히 조정하라.

 20. 지식을 일반 텍스트로 저장하라.

 : 일반 텍스트 형식은 시일이 지났다고 못쓰게 되는 일이 없다.

   일반 텍스트 형식은 여러분의 작업을 활용하고 디버깅과 테스팅을 쉽게 만드는 데 도움이 된다.

 21. 명령어 셸의 힘을 사용하라.
 : 그래픽 사용자 인터페이스로는 할 수 없는 일에 셸을 이용하라.

 22. 하나의 에디터를 잘 사용하라.
 : 에디터를 마치 손의 연장으로 자유자재로 다루어야 한다.

   여러분이 사용하는 에디터는 설정를 바꿀 수 있고, 확장가능하고, 프로그램 가능해야 한다.

 23. 언제나 소스코드 관리 시스템을 사용하라.
 : 소스코드 관리는 여러분 작업을 위한 타임머신이다. 언제라도 과거로 돌아갈 수 있게 해준다.

 24. 비난 대신 문제를 해결하라.
 : 버그가 여려분 잘못인지 다른 사람 잘못인지는 별로 중요하지 않다.

   그것은 여전히 여러분의 문제이며, 여전히 고쳐야 할 필요가 있다.

 25. 디버깅을 할 때 당황하지 마라.
 : 숨을 깊게 들이 쉬고, 무엇이 버그를 일으키는지 '생각하라!'

 26. 'select'는 망가지지 않았다.
 : OS나 컴파일어의 버그를 발견하는 일은 정말 드물게 일어나며, 심지어 써드파티 제품이나 라이브러리 일지라도 드문 일이다. 버그는 애플리케이션에 있을 가능성이 가장  크다.

 27. 가정하지 마라. 증명하라.
 : 진짜 데이터와 경계 조건이 있는 실제 환경에서 여러분이 내렸던 가정들을 증명하라.

 28. 텍스트 처리 언어를 하나 익혀라.
 : 여러분은 하루 가운데 많은 시간을 텍스트와 씨름하며 보낸다. 왜 여러분 대신 컴퓨터
   가 그 일의 일부를 하게끔 만들지 않는가?

 29. 코드를 작성하는 코드를 작성하라.
 : 코드 생성기는 생산성을 증가시키며 중복을 막는 일에도 도움이 된다.  

 30. 완벽한 소프트웨어는 만들 수 없다.
 : 소프트웨어는 완벽할 수 없다. 피할 수 없이 나타나는 에러로부터 여러분의 코드와 사용자
   들을 보호하라.

 31. 계약에 따른 설계를 하라.
 : 코드가 실제로 하기로 한 것을 문서화하고 검증하기 위해 계약을 사용해라.

 32. 일찍 작동을 멈추게 하라.
 : 보통은 죽은 프로그램이 절름발이 프로그램 보다 해를 훨씬 덜 끼친다.

 33. 단정문을 사용해서 불가능한 상황을 예방하라.
 :  단정은 여러분이 세운 가정을 검증해준다.
    확실한 것이 없는 세상에서 여러분의 코드를 보호하려면 단정문을 사용하라.

 34. 예외는 예외적인 문제에 사용하라.
 : 예외를 잘못 쓰면 고전적 스파게티 코드의 모든 가독성과 유지보수 문제를 그대로 겪을지도 모른다. 예외는 예외적인 일들만을 위해 남겨두어라.

 35. 시작한 것은 끝내라.
 : 가능하다면, 리소스를 할당한 루틴이나 객 체가 해제도 책임져야 한다.

 36. 모듈간의 결합도를 최소화하라.
 : 디미터 법칙을 적용하고 '부끄럼 타는(shy)' 코드를 작성해서 결함이 생기는 일을 피하라.

 37. 통합하지 말고 설정하라.
 : 애플리케이션에서 기술 선택을 설정 옵션으로 구현하고, 통합하거나 만들어 넣지 말라.

 38. 코드에는 추상화를, 메타데이터에는 세부 내용을.
 : 프로그램은 최대한 일반화해서 만들고, 세부사항들을 가능하면 컴파일된 코드 기반 바깥으로 빼라.

 39. 작업흐름 분석을 통해 동시성을 개선하라.
 : 사용자의 작업흐름이 허용하는 동시성을 최대한 활용하라.

 40. 서비스를 사용해서 설계하라.
 : 서비스, 곧 잘 정의되고 일관성 있는 인터페이스를 통해 의사소통하는 독립적이고 동시성 있는 객체들의 관점에서 설계하라.

 41. 언제나 동시성을 고려해 설계하라.
 : 동시성이 가능하도록 설계하면, 더 적은 가정만 내리고서도 더 깔끔한 설계를 할 수 있다.

 42. 모델에서 뷰를 분리하라.
 : 애플리케이션을 모델과 뷰의 관점으로 설계 해서 적은 비용만 들이고도 유연함을 얻어 내라.

 43. 칠판을 사용해 작업흐름을 조율하라.
 : 참여하는 요소들의 독립성(independence)과 고립성(isolation)을 유지하면서도 개별적인 사실과 에이전트를 잘 조율하려면 칠판을 사용하라.

 44. 우연에 맡기는 프로그래밍을 하지 말라.
 : 정말 믿을 만한 것만 믿어야 한다. 우발적인 복잡함을 조심하고, 우연한 행운을 목적 의식을 가지고 만든 계획과 착각하지 말라.

 45. 여러분의 알고리즘의 차수를 추정하라.
 : 코드를 작성하기 전에, 실행 시간이 대략 얼마나 걸릴지 감을 잡아 놓아라.

 46. 여러분의 추정을 테스트하라.
 : 알고리즘의 수학적 분석이 모든 것을 다 알려주지는 않는다.

   실제 대상 환경에서 코드의 수행 시간을 측정해보라.

 47. 일찍 리팩터링하고, 자주 리팩터링하라.
 : 정원의 잡초를 뽑고 식물 배치를 조정하는 것과 똑같이, 코드도 필요할 때면 언제라도 다시 작성하고 다시 작업하고 다시 아키텍처를 만들라. 문제의 근원을 해결하라.

 48. 테스트를 염두에 두고 설계하라.
 : 코드를 한 줄이라도 쓰기 전에 테스팅에 대해 생각하기 시작해야 한다.

 49. 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스하게 될 것이다.
 : 가차 없이 테스트하라. 사용자가 여러분을 위해 버그를 찾게 만들지 말라.

 50. 자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.
 : 마법사는 엄청난 양의 코드를 만들 수 있다.
   그것들을 프로젝트에 통합해 넣기 전에 그 코드 내용을 전부 이해하는지 확실히 해놓도록 하라.

 51. 요구사항을 수집하지 말고 채굴하라.
 : 요구사항이 지면에 놓여져 있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치의 지층들 속 깊이 묻혀 있다.

 52. 사용자처럼 생각하기 위해 사용자와 함께 일하라.
 : 시스템이 정말로 어떻게 사용될 지 통찰력을 얻을 수 있는 가장 좋은 방법이다.

 53. 구체적인 것보다 추상적인 것이 더 오래간다.
 : 구현 말고 추상에 투자하라. 추상은 서로 다른 구현이나 새로운 기술의 출현 때문에 빗발치듯 생기는 변화를 견뎌내고 살아남을 수 있다.

 54. 프로젝트 용어사전을 사용하라.
 : 프로젝트에서 쓰이는 특정 용어와 어휘들의 유일한 출처를 만들고 유지하라.

 55. 생각의 틀을 벗어나지 말고, 틀을 찾아라.
 : 해결이 불가능해 보이는 문제와 마주쳤을 때, 진짜 제약 조건을 찾아라.

   스스로에게 이렇게 물어보라. '정말로 반드시 이런 방식으로 해야 하는 일인가?

   꼭 해야만 하는 일이긴 한 건가?

 56. 준비가 되었을 때 시작하라.
 : 여러분은 살아오면서 경험을 쌓아왔다. 자꾸 거슬리는 의혹을 무시하지 말라.

 57. 어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다.
 : 명세의 나선에 빠지지 말라. 언젠가는 코딩을 시작해야 한다.

 58. 형식적 방법의 노예가 되지 마라.
 : 여러분의 개발 실천방법과 개발 능력의 맥락 안에 넣어보지 않고, 맹목적으로 어떤 기법을 채택하지 말라.

 59. 비싼 도구가 더 좋은 설계를 낳지는 않는다.
 : 벤더들의 과장, 어떤 분야의 도그마 그리고 가격표의 휘광에 넘어가지 말라.

   도구 자체의 장점만 갖고 판단하라.

 60. 팀을 기능 중심으로 조직하라.
 : 설계자와 코더를, 테스트 담장자와 데이터 모델 담장자를 분리시키지 말라.

   코드를 만드는 방식에 맞춰 팀을 만들어라.

 61. 수작업 절차를 사용하지 말라.
 : 셸 스크립트나 배치 파일은 똑같은 명령을, 똑같은 순서로, 어느 때라도 반복해서 실행 해준다.

 62. 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
 : 매번 빌드할 때마다 실행되는 테스트가 책꽂이의 테스트 계획보다 훨씬 효과적이다.

 63. 모든 테스트가 통과하기 전에 코딩이 다 된 게 아니다.
 : 뭐 더 할 말 있나?

 64. 파괴자를 써서 테스트를 테스트하라.
 : 코드의 별도 복사본을 만들고, 그 복사본에 고의로 버그를 넣은 다음 테스트가 잡아내는지 검증하라.

 65. 코드 커버리지보다 상태 커버리지를 테스트하라.
 : 중요한 프로그램 상태들을 파악해서 테스트하라.

   단지 많은 코드 줄 수를 테스트 범위 안에 넣는 것만으로는 충분하지 않다.

 66. 버그는 한 번만 잡아라.
 : 인간 테스터가 버그를 찾아내면, 그 때가 인간 테스터가 그 버그를 찾는 마지막 순간이 되어야 한다. 그 순간 이후부터는 자동화된 테스트가 그 버그를 담당하도록 만들라.

 67. 한국어도 하나의 프로그래밍 언어인 것처럼 다루라.
 : 코드를 작성하는 것처럼 문서도 작성하라.
   DRY 원칙을 존중하고, 메타데이터를 사용 하고, MVC 모델을 쓰고, 자동 생성을 이용 하고 등등.

 68. 문서(document)가 애초부터 전체의 일부가 되게하고, 나중에 집어넣으려고 하지 말라.
 : 코드와 떨어져서 만든 문서가 정확하거나 최신 정보를 반영하기는 더 힘들다.

 69. 사용자의 기대를 부드럽게 넘어서라.
 : 사용자들이 무엇을 기대하는지 이해한 다음, 그것보다 약간 더 좋은 것을 제공하라.

 70. 자신의 작품에 서명하라.
 : 옛날 장인들은 자신의 작업 결과물에 서명 하는 일을 자랑스럽게 여겼다. 여러분도 마찬가지여야 한다.

 

<출처 : 실용주의 프로그래머>

Posted by SB패밀리

프로그래머를 위한 잠언(aphorism)
 
 
다음은 세상의 지혜, 발라사르 그라시안 지음, 이동진 옮김을 참고하여 프로그래머에 맞추어 재구성한 것입니다. 필자가 추가한 것도 있고 패러프래이즈 한 것도 있습니다. 세상의 지혜 책에는 300가지의 지혜가 있고 해설도 잘 되어 있으므로 프로그래머 여러분들께서 구입해서 한 번쯤 꼭 읽어보시기 바랍니다. 책 가격을 하는 좀처럼 드문 책임에 틀림없다고 생각합니다. 존칭은 편의상 생략합니다. 너그러운 양해를 구합니다.

1. 컴퓨터 프로그래머는 최고의 직업임을 알라.
2. 컴퓨터 프로그래머는 노가다 직업임을 인정하라.
3. 프로그래밍의 성공 열쇠는 자신감이다.
4. 산은 넘어봐야 안다.
5. 산을 넘지 않고 넘어봐야 안다는 말하는 사람들을 가까이 하지 마라.
6. 언제나 진실되게 행동하라.
7. 프로그래밍은 진실의 반영이다.
8. 프로그래밍은 고도의 논리적 사유를 요구한다.
9. 개발툴은 기술적이기보다는 기능적이다.
10. 완전한 프로그램을 만드는 것만큼 자신을 완전하게 만들어라.
11. 컴퓨터를 이해하고 프로그램 구조를 이해하는 것만큼 자신을 알고 이해하라.
12. 팀웍을 위해서 일하라.
13. 팀웍의 활성화를 위해서는 스터디 모임이 효과적이다.
14. 팀 내에서 나서는 사람이 되기보다는 없어서는 안될 사람이 되어라.
15. 프로그래밍 지식이 실체화되려면 용기가 있어야 한다.
16. 소프트웨어 기술과 소질을 잘 살려서 최대한 도로 자신의 능력을 완숙한 경지로 향상시켜라.
17. 팀원들이 당신을 존중하고 신뢰하도록 만들라.
18. 팀장에게 반항하거나 그를 능가하려고 하지 말라.
19. 팀 내에서의 불만을 자기 것으로만 생각하지도 말고 퍼뜨리지 말라.
20. 프로그램 개발 시 발생하는 고통은 누구에게나 있는 것이다.
21. 가능한 한 자신의 결점을 노출시키지 말라.
22. 항상 배우도록 하고 자신에게 멘토가 되어줄 사람을 찾아라.
23. 동료 팀원들을 스승으로 삼아라.
24. 재능은 누구에게나 주어지지만 그 재능이 숙련적인 기술로 발전하기 위해서는 노력이 필요하다.
25. 프로그램 완성을 위해서는 WHY 보다는 HOW가 더 중요하다.
26. 버그를 한 번에 잡으려고 하지마라. 긴장을 갖고 있으되 한편으로는 여유로움을 간직하라.
27. 프로그래밍이란 지성과 감성 그리고 용기와 박력의 결합이다.
28. 자신의 주변에 우수한 인재들이 모이도록 자신을 향상시켜라.
29. 프로그램 개발은 풍부한 기술지식과 풍요로운 마음가짐을 요구한다.
30. 팀 내에서 그리고 회사 내에서 그리고 어디에서든 적을 만들지 말라.
31. 적을 만들지 않기 위해서는 항상 자신을 새롭게 하라.
32. 근면은 프로그래머가 프로그래밍을 하는데 있어서 근간을 이룬다.
33. 자신이 작성한 프로그램에 자부심을 갖되 대단한 기대는 갖지 말라.
34. 직장에서 퇴출될 수 없는 자신만의 노하우를 가져라.
35. 운이 안 좋아도 배움을 늦추지 말라. 운이 안 좋을때 배우는 것이 더 많을 수 있다.
36. 장황한 지식이 아닌 실질적인 지식을 갖추어라.
37. 소프트웨어 기술 지식을 적시 적소에 사용하는 방법을 배워라.
38. 프로그래머는 소프트웨어 개발을 위한 마법사임을 깨달아라.
39. 자신의 결점을 숨기려고 하지 말고 결점을 고치려 하되 안 되면 무시하라. 가능한 한 떳떳하고 당당하게 살아가라.
40. 팀 내에서 다른 팀원의 결함을 찾아내려고 하지 마라.
41. 프로그램 개발에서부터 팀웍에 이르기까지 매사에 긍정적으로 생각하고 행동하라.
42. 사유와 상상은 다르다. 상상할 때와 사유할 때를 구별하라.
43. 팀 내의 전체적인 분위기를 읽을 줄 알아라. 회사가 돌아가는 분위기를 인식하라.
44. 경쟁 프로그래머가 있을 경우 그를 존중하고 그로부터 배우려고 노력하라.
45. 교만하고 자만해 있는 사람이 팀원으로 있다면 자신의 마음에 그러한 요인이나 인자가 없는지 잘 내면을 살펴라.
46. 소프트웨어 프로그래머의 실력은 소프트웨어가 얼마나 성능이 좋은가에 판가름난다.
47. 누구나 할 수 있는 프로그래밍 기술도 갖추되 자신만의 프로그래밍 기술도 갖추어라.
48. 프로그래밍에 대한 자신의 주관을 져버리지 말라. 자신의 철학을 지켜라.
49. 팀원으로부터 인기를 얻으려고 하지 말라.
50. 프로그램 상에 존재할 수 있는 미심쩍은 오류나 버그에 대해서는 즉각 조치를 취하라.
51. 운이 좋은 프로그래머와 실력이 좋은 프로그래머들을 주변에 많이 두어라.
52. 위기에 처했을 때는 마음으로 자신이 선망하는 고수들에게 기도하라.
53. 자신의 기술지식을 팀원에게 베풀거나 그들과 공유하라.
54. 자신의 능력을 20%~30%는 숨겨라.
55. 팀원이나 팀장의 요청을 무조건 받아들이려고 하지 말라. 거절할 줄도 알라.
56. 자신의 기술지식이나 기술소질에 있어서 가장 뛰어난 부분을 더욱 발전시켜라. 자신의 장점을 최대한 발전시켜라.
57. 프로그램의 구조와 설계 전반에 관하여 조용하고 맑은 정신으로 깊이 사유하는 시간을 가져라.
58. 구루나 마스터가 되기 전까지는 프로그래밍을 짜기 전에 3번 생각하고 한 줄의 코드를 작성하는 습관을 가져라.
59. 짠 코드를 다시 고치거나 지우는 것을 아깝게 생각하지 말라.
60. 프로그램이 완전히 완성되기에는 시간이 필요함을 알라. 모든 사사물물은 완성하는 데에는 시간이 요구된다.
61. 자신을 비난하는 자가 3번을 비난하면 두 번은 침묵으로 무시하나 한 번쯤은 진실한 말로 그렇지 않음을 이야기하라.
62. 운이 좋다고 느껴질 때 열심히 일하고 많은 것을 배워라.
63. 팀원들이 자신을 좋아하도록 해라. 팀원에게 친절하고 베풀어라.
64. 모자란 실력에 대해 자신이 실력 있다고 뻥 튀겨 부풀리지 말라.
65. 자신의 능력을 지나치게 믿지 말라.
66. 팀의 흐름을 따르라.
67. 행운이 자신에게 언제 찾아오는지 명리학자에게 자문을 구하라. 그러나 행운보다 노력과 배움이 더 중요함을 인지하라.
68. 원대한 포부와 야망 그리고 비전을 가진 사람이 어떻게 그것을 현실화시키는지를 알라.
69. 프로그래밍 기술지식이 풍부한 사람을 사귀라.
70. 교묘한 프로그래밍 기술 노하우(TIP)를 많이 습득하라.
71. 프로그램의 제어 흐름과 데이터 흐름을 잘 관찰하라.
72. 자신이 작성한 프로그램은 자신의 분신임을 깨달아라.
73. 프로그래밍을 통해서 일상생활에 대한 자신의 논리적 판단력을 증진시켜라.
74. 팀원을 미워하지 말고 자신을 사랑할 줄 알라. 애증을 버려라.
75. 팀 내에서 나서서 무엇을 하려고 하지 말라. 시키지 않은 일을 하지 말라.
76. 팀 내에서 알 수 없는 신비감과 심오함으로 자신을 포장하라.
77. 팀 내에서 자신과 타인의 자존심에 상처를 주지 않도록 주의하라.
78. 논쟁을 삼가되 논쟁을 하게 되면 서로를 존중하는 기반 하에서 논쟁을 하라.
79. 인생은 선택의 연속이다. 올바른 선택을 하라. 그러나 틀린 선택을 해도 후회하지는 마라.
80. 팀 내에서 누군가 자신을 비난해도 당황하거나 화를 내지 마라. 너그러운 마음으로 사태를 분석하고 진지하고 진솔하게 사실을 이야기 하라.
81. 프로그래밍은 빨리 한다고 능사가 아니다. 시간이 해결해 줄 수 있음도 인정할 줄 알라.
82. 진지함과 즐거움을 동시에 갖고 프로그래밍을 하라.
83. 팀 내에서 싸움은 가급적 피해 되 싸움에서 이기되 패배를 통해서 배우는 자세도 길러라.
84. 싸움은 배짱으로 하는 것이지 머리로 하는 것이 아니다. 머리를 텅비우고 배에 힘을 주어라.
85. 팀 내에서 자신을 나약하게 생각하거나 무시하는 사람에게는 자신이 힘이 있고 위엄이 있음을 보여주라.
86. 싸워서 질 경우 참고 견디는 인내의 마음을 길러라.
87. 프로그래밍할때는 항상 주의를 기울여서 실수와 오류가 프로그램 상에 들어가지 않도록 노력하라.
88. 항상 깨어있는 의식 상태로 프로그래밍을 하라.
89. 항상 버그가 언제 어디서든지 발생할 수 있음을 인식하고 있으라.
90. 팀웍을 원활하게 유지하려면 주변의 사람들의 수준과 자신의 수준을 일치시키도록 하라. 나서지도 말고 주눅들지도 말라.
91. 프로그램의 완성도는 바둑처럼 끝내기를 잘하는데 있다.
92. 프로그래밍을 통해서 지식과 지혜를 길러라.
93. 어려운 문제를 해결해 낼 수 있는 실력을 길러라. 소프트웨어 업계에서 장인이라고 호칭되려면 남들이 해결하지 못하는 프로그램 문제를 고칠 수 있어야 한다.
94. 어려운 문제가 발생할 경우 자신이 해결해야만 한다면 그 문제를 우회할 수 있는 길을 모색하라.
95. 자신의 능력을 100%활용해도 안 되면 휴먼 네트워크를 활용하라.
96. 팀 내의 팀원들에게 좋지 못한 소식은 전하지도 말고 들으려고 하지도 말라.
97. 프로그래밍은 판단력을 기르는데 매우 요긴한 도구이다.
98. 소프트웨어 개발은 결과로서 평가 받는다. 결과가 좋으면 과정도 좋은 것이다.
99. 자신만 잘하려고 하지 말고 팀 내의 팀원들이 판단을 잘하도록 도와주라.
100. 프로그램 개발 시에 모든 것을 혼자 다하려고 하지마라. 팀원들과 함께 일하라. 물론 부당한 요구는 거절할 줄 알아라.
Posted by SB패밀리

그린컴퓨터 최중구님의 글입니다. http://greenpc.co.kr/programmer.htm
-----------------------------------------------------------------
프로그래머의 글
1) 글을 시작하면서

오늘 이 글을 통해 혼란한 국내 소프트웨어 개발(프로그래머) 직종을 이해할 수 있는 설명을 하고자 합니다. 더 나아가 프로그래머라는 직종을 이해하는 것을 시작으로 프로그래머의 길을 걷고자 하시는 많은 분들이 밟아 올라가야할 방향을 제시할 수 있기를 바라는 마음에서 이 글을 적어봅니다.

2) 프로그래머에 대한 아마추어적인 발상

최근들어 인터넷이 사회적인 이슈로 떠오르면서 자연히 소프트웨어 개발에 대한 관심이 증대되고, 자연히 프로그래머라는 직업을 갖고싶어 하는 사람들이 늘고 있습니다. 하지만 소프트웨어 개발에 대한 잘못된 시각때문에 전문 직종으로 분류되어야할 프로그래머가 일반 직종으로 분류되고 있는 기현상을 보이고 있는 점은 프로그래머가 되고자 노력하고 있는 한 사람으로서 가장 걱정되는 부분입니다.

프로그래머라는 직업을 의사라는 직종을 예로들어 비교를 해본다면, 의사가 되기 위해서는 의대의 정규과정을 이수한 후 국가공인 자격시험을 통해 인턴/레지던트/전문의 순서를 밟아야 합니다. 이 처럼 의사라는 직종은 분야도 확실하게 나뉘어져 있을뿐만 아니라 의사로서의 자질을 평가하는 제도적인 체계가 정확하게 잡혀있습니다. 하지만, 프로그래머라는 직종은 그렇지 못합니다. 전산과를 나온다고해서 프로그래머가 되는 것도 아니고, 대학을 나오지 않았다고 해서 프로그래머가 되지말라는 법도 없습니다. 정보처리 관련 국가공인 자격증을 갖고있다고 해서 프로그래머가 되는 것은 더더욱 아니고 분야 또한 정확하게 구분할 수 없는 것이 프로그래머라는 직종입니다.

이처럼 프로그래머에 관한 정확한 정의가 내려지지 못하고 있는 상황에서 사회적 분위기는 소프트웨어 인력시장에 있어 큰 혼란을 초래하고 있는 것이 사실입니다. 때문에 프로그램 공부를 시작하려는 많은 사람들에게 혼란을 주고 있는 것이라 생각되는군요. 분야와 개인의 노력여부에 따라 틀리겠지만, 단순히 학원에서 몇 개월 과정을 이수한 것이나 프로그램 몇가지를 개발해본 경력으로 자신을 프로그래머라 칭하고 또 인정하는 사회적인 분위기에는 문제가 있습니다. 저도 올해로 프로그램을 시작한지 15년째고 실무경력은 15년 이지만, 지금도 저 자신을 프로그래머라 부르기에는 부끄러운 점이 많습니다. 사실 프로그래머라는 직종은 전문직에 속하는 것입니다. 의사보다는 훨씬 못하겠지만 그에 못지 않게 오랜 기간동안 공부하고 경험을 쌓아야만 비로소 프로그래머가 될 수 있는 것인데, 프로그래머라는 직종을 보는 일반적인 시각은 너무 쉽게 생각하는 경향이 있지 않는가 하는 생각이 들 때가 많습니다.

3) 풍요속의 빈곤

이러한 잘못된 사회적 통념이 굳어져 가고 있는 우리나라의 프로그래머 인력시장의 구조를 살펴보면 그 문제점을 가장 단적으로 알 수 있습니다. 우리나라 소프트 업계의 인력시장의 구조는 초보자로 부터 시작해 고급자로 균형이 있게 올라가는 정상 피라미드와는 많은 차이가 있습니다. 초급에 해당하는 아래부분은 비정상적 포화상태를 띠고있는 반면에 중급자 및 고급자들은 거의 찾아보기 힘든 구조를 나타내고 있습니다.

이러한 현상은 프로그래머라는 직종에 단순한 흥미와 사회적 분위기에 휩쓸려 뛰어드는 사람들은 많지만, 체계적인 교육과 평가 방법의 부재 및 영세한 국내 소트웨어 업계의 투자부족으로 인하여 중급이상으로 발전하는 프로그래머 지망생이 없기 때문에 나타나는 현상으로 볼 수 있습니다.

이와는 별도로 외국기술과 객관적으로 비교해 봤을때 훨씬 뒤진 기술조차 공유하는 것을 꺼려하고 있다는 점 또한 국내 소프트웨어 업계의 발전을 저해하는 요소로 지적할 수 있습니다. 하루가 다르게 변모하고 있는 세계적인 소프트웨어 업계와 경쟁하려는 생각은 하지 않고 오히려 지금 갖고 있는 지금까지 해왔던 일들만 편하게 하려는 안일한 생각들은 물론이고 그 보잘것 없는 기술을 통해 기득권을 유지하려는 잘못된 생각이 가장 큰 문제점이라 할 수 있습니다.

이러한 비정상적 인력시장 구조 속에서 정말 필요로 하는 프로그래머를 찾기란 하늘의 별따기와도 같으리라는 점은 누가 봐도 자명한 사실입니다. 풍요속의 빈곤이라는 용어가 어울릴정도로 프로그래머로 일하려는 사람은 많은 반면 정말 실력있는 프로그래머는 손에 꼽는 현상이 나타나는 것입니다.

4) 프로그래머가 갖추어야할 자질

프로그래머가 되기 위해 갖추어야할 자질에는 여러가지가 있습니다. 그 모두가 천재적인 재능을 필요로 한다기 보다는 끊임없는 노력을 통해 얻어질 수 있는 것이라 할 수 있는 것들입니다.

첫째, 집요하고 꼼꼼해야 합니다.

프로그래머의 직업병이라고도 할 수 있는 집요함이 있어야 합니다. 문제점을 찾아내고 해결하기 위해서 집요하게 들러 붙어 있을 수 있는 근성이 필요합니다. 차분하고 꼼꼼하면서 끈질긴 성격을 가진 분들은 어디가나 성공하시겠지만 프로그래머에게는 필수조건이라고 할 수 있습니다. 차분한 성격은 타고나는 것도 있겠지만 훈련을 통해 개발될 수도 있는 것입니다. 예를 들면, 마인스위퍼를 한다던가~ ^^퍼즐등을 통해서 키워질 수 있겠죠.

둘째, 논리력이 뛰어나야 합니다.

프로그램의 거의 대부분을 차지하는 것은 조건판단, 분기, Loop문을 작성하는 것입니다. 논리력이 없이는 할 수 없는 일들입니다. 일반적으로 남성에 비해 여성이 논리력이 뒤진다는 속설이 있어서 그런지는 모르지만 이 점 때문에 여성 프로그래머가 많지 않다고들 합니다. 집요하면서도 꼼꼼하게 논리를 구축해야 Bug 없는 프로그램을 작성할 수 있다고 봐도 과언이 아닙니다. 논리력 또한 훈련을 통해서 개발될 수 있는 것이죠. 역시 마인스위퍼를 한다던가~ ^^ 논리학등을 공부하고 일상생활에서 논리적인 사고를 하기위해 노력을 함으로써 개발할 수 있겠죠. 전 세가지 다 했습니다.

셋째, 세상을 보는 관찰력과 추상력이 뛰어나야 합니다.

프로그램은 추상화를 기본으로 하고 있습니다. 실세계를 축소해 놓은 것이 프로그램이라고 말해도 과언이 아닐 정도록 현실과 밀접한 관계를 갖고 있는 것이 프로그램입니다. 때문에 관찰력과 추상력이 필요합니다. 실세계의 특징을 찾아내고 단순화 하고 추상화하는 과정은 프로그램의 설계부분에 들어가기 때문에 전체적인 성능을 좌우하는 중요한 요소로 작용하기 때문입니다. 관찰력과 추상력은 경험을 통해서 개발될 수 있을 겁니다. 꼼꼼한 성격도 한몫을 할 수 있겠죠.

이러한 기본 자질들은 상호보완적인 관계속에서 프로그래머의 능력 개발에 도움을 줄 수 있는 것들입니다. 이러한 자질만을 갖고 있다고 해서 프로그래머가 될 수 있는 것은 아닙니다. 기본적인 전산이론은 물론 기타 관련 이론에 대한 공부가 필수적입니다.


첫째, 전산개론

일종의 상식공부라고 할 수 있습니다. 전산의 변천사는 물론 전산의 폭넓은 분야를 아는 것이 지금의 자신의 위치를 알 수 있는 가장 중요한 방법이 되기 때문입니다.

둘째, Hardware의 구조 및 동작원리

프로그래머는 Hardware는 몰라도 된다는 식의 발상은 정확하게 틀린 말입니다.Software는 Hardware상에서 구동되는 것이기 때문에 Hardware의 구조가 어떻고 어떤 원리와 절차에 의해서 구동되는지에 관한 특성을 알지 못하면 Hardware에 맞는 최적화된 Program을 개발할 수 없기 때문입니다. Pentium 계열의 CPU 에서 Pipeline Optimize의 개념을 알지 못한다면 Speed 최적화를 할 수 없는 것과 마찬가지입니다. 고급 프로그래머가 되기 위해서는 결코 등한시 해서는 안되는 점임을 잊지 마시기 바랍니다.

셋째, OS 이론

모든 프로그램은 OS 환경가 제공하는 환경에서 구동되도록 되어 있습니다. HW와의 복잡한 일들을 모두 맞아서 처리해주는 것은 물론 기타 유용한 Service를 제공해주는 OS를 몰라서는 그 OS에서 구동되는 프로그램을 개발할 수가 없습니다. 보다 넓은 시야를 갖고 전체적인 그림을 그리기 위해서는 OS를 어떻게 만들 것인가에 관한 이론들을 아는 것이 중요합니다. OS도 만드는데 다른 프로그램을 왜 못 만들겠습니까?

넷째, 자료구조/알고리즘 이론

프로그램의 꽃이라 할 수 있는 기본 이론들입니다. 프로그램에서 가장 중요한 부분인 자료의 저장과 처리에 관한 방법론들을 정리해 놓은 이론들로서 반드시 거쳐야하는 난코스라고도 할 수 있습니다. 자료구조/알고리즘을 모른다면 단순 Coder도 못된다는 결론이 날정도로 프로그래머가 되기위한 가장 기본적인 조건입니다.

다섯째, 전산언어론

C/Pascal/Fortran 등의 언어가 없을때는 어떻게 프로그램을 했을까? 라는 질문에 대한 답을 던져줄 수 있는 이론들입니다. Assembler로 부터 4GL까지의 발전사를 알 수 있을 뿐 아니라 C/C++와 같은 언어를 어떻게 만들 것인가를 정리하는 이론들입니다. Compiler 를 어떻게 만들 것인가에 대해 고민해보신적 있습니까? Compiler를 만든다면 그 Compiler가 번역하는 언어는 자유자제를 넘어 신의 경지에 오를 수 있지 않겠습니까?

여섯째, 개발방법론

전산언어론과는 또 다른 개념의 이론들을 모아놓은 것으로써 소프트웨어를 생산에 공학개념을 도입하고자 하는 이론들입니다. 체계화된 방법론을 통해 소프트웨어 개발의 생산성을 높이고자 하는 목적을 갖는 이론들입니다. 생산성을 생각하지 못한다면 경쟁력을 갖지 못하는 것은 당연한 것 아니겠습니까?

일곱째, 전산언어

C/C++과 같은 언어의 문법을 배우는 단계입니다. 가장 처음 프로그래머가 되겠다고 마음 먹은 사람들이 가장 많이 만나는 첫번째 적수이지요. 하지만 전체적인 그림속에서 전산언어가 차지하는 비중은 제일 마지막에 속하고 있다는 점을 유념하시기 바랍니다. 어떤 언어를 사용하는가는 중요하지 않다는 점입니다. 언어는 도구일 뿐이지 목적이 아니라는 점을 다시한번 강조하고 싶군요.

위에 나열된 주제들은 대부분의 전산과 교과목에 포함되어 있는 내용들입니다. 모두 한학기 분량이지만 결코 한학기 안에 끝낼 수 있는 내용들이 아닙니다. 1년 동안 세가지를 끝낸다고 해도 2년이 넘는 시간이 필요하다는 단순계산이 나옵니다. 결코 만만한 일은 아니죠.

여덟째, 실무경험

위의 조건들을 갖춘 대부분의 사람들은 일반적으로 실무경험이 부존한 것이 현실입니다. 단순히 이론적인 것으로만 접근해서는 좋은 프로그램이 나올 수 없습니다. 프로그램의 최종 사용자는 고객입니다. 고객의 입장에서 만들어야 가장 좋은 프로그램이 될 수 있습니다. 고객이 되어 본 사람은 좋은 프로그램을 만들 수 있습니다. 왜냐하면 고객은 그 업무를 가장 잘 알기 때문입니다.

5) 기본위에 쌓여진 경험

2년 안에 위에서 나열한 기본들을 모두 마스터 한다고 해도 Coder로 인정받기란 쉬운 일이 아닙니다. 원론을 그대로 적용해 해결할 수 있는 문제는 하나도 없다는 것은 너무나도 당연한 사실입니다. 책 속의 이론이 내안의 경험으로 쌓일때 비로소 내것이 될 수 있는 것입니다.

지금의 저 또한 그 기본위에 경험을 쌓기 위해 노력중인 사람이라고 말씀드리고 싶습니다. 항상 따라가도 먼저 뛴 사람들은 저만큼 앞서 가고 있다는 걸 느낄때마다 프로그래머라는 직업이 얼마나 피곤한 직업인가를 새삼 깨닫고 있으니까 말입니다.

6) 글을 맺으며... 세상 밖으로...

장황하게 나마 프로그래머라는 직종에 대해 설명을 해보았습니다. 글을 읽다 짜증이나시지나 않았나 모르겠군요. 하지만 이것이 지금의 제가 보고 있는 국내 업계의 현실입니다. 물론 상황에 따라 부분적으로 틀릴 수도 있겠지만 큰틀에서 본다면 제 글에서 벗어나는 것이 없습니다.

그 것은 바로 얼마전까지 워드프로세서를 만들던 한 소프트웨어 업체가 국내 소프트웨어 업계를 대표했었다는 사실만 봐도 알 수 있습니다. 그 폐단은 지금에 와서 더더욱 커지고 있죠. 외국과의 자료교환이 불가능 하다는 결정적인 문제점을 남겨놓고 무책임하게도 사라져버리지 않았습니까? 한국의 빌게이츠라는 말이 창피할 정도로 몰락하고만 기업에서 한동안 일을 했던 경험이 이렇게 더 큰 분노를 만들고 있습니다.

기본을 무시하고 사상누각을 쌓았던 한국병이 이 소프트웨어 업계에도 어김없이 자리잡고 있다는 것을 왜 아무도 지적하지 않는지 모르겠습니다. 밴쳐라는 이름아래 개혁의 면죄부를 받고 있는 기업들이 지금도 많다는 것에 안타까울 뿐입니다.

눈을 한번 돌려보시죠. 어느 나라가 워드프로세서 업체를 자국의 소프트웨어 대표기업이라고 떠들어대는지를...

우리는 아직 멀었습니다
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패밀리