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

[경영/리더십] 회사 내에서 발견되는 각종 오류들 



공감가는 부분이 많습니다.

하지만 다르게 생각해보면.. 

우리회사...내가 일하고 회사 이미지를 만들어가는 곳에서 일어나는 일인 만큼

나몰라라 할 수는 없습니다. 

회사가 욕 먹는 다는건 곧 내가 욕 먹는다는거.




======================================

출처: http://www.infuture.kr/1150


일반회사를 다니다가 컨설턴트 일을 한 지 이제 14년 가량이 됐습니다(아니 벌써!). 그 동안 여러 기업을 보면서 '이건 좀 이상하다'고 느낀 경영상의 오류들이 많습니다. 제가 발견한 오류가 경영의 모든 오류를 포괄하지는 못하겠지만, 아래의 내용들은 직장을 다니는 분들이라면 피부로 느끼고 있을 겁니다. 간혹 아프게 꼬집는 오류가 있더라도 '잘해보자'는 의미로 받아들이면 좋겠네요. 

여러분도 추가하고 싶은 오류가 있으면 댓글로 남겨 주세요. 나중에 혹시 이 글을 책에 싣게 되면 출처를 밝히고 여러분이 제시한 오류를 넣겠습니다. 저도 더 생각나면 계속 추가하겠습니다.

즐거운 주말 되세요.



'인력의 오류' : 사장님 눈에는 인력이 남고, 직원들 눈에는 인력이 모자르다. 항상.


'경쟁의 오류' : 경쟁사와 경쟁할 생각은 하지 않고 직원들을 서로 경쟁시킨다. 내부경쟁이 외부경쟁력을 높인다고 착각한다.


'운영전략의 오류' : 그저 운영인데 거창하게 '전략'이란 말을 갖다 붙인다. 누구와 운영을 놓고 싸우는데?


'가격 협상의 오류' : 한번 거래를 트면 계속 이어지니 가격을 깎아 달라고 말한다. 물론 그 다음 거래는 없다.


'업무공유의 오류' : 공유할 마음이나 필요도 없으면서, 문제만 생기면 업무공유가 안 됐기 때문이라고 말한다.


'회식의 오류' : 윗사람만 좋아한다.


'등산의 오류' : (특히 사장님) 자신이 등산 좋아하면 다른 사람들도 좋아하는 줄 안다.


'핵심인재의 오류' : 우리 회사에서 핵심인재라고 뽑힌 자들은 업계 최고가 아니다. 우리 회사에서도 최고가 아니다.


'예산의 오류' :예산을 아끼면 욕 먹는다. 그리고 다음엔 깎인다.


'위기 관리의 오류' : 나쁜 일이 일어나지 않도록 대비한 사람은 보상 받지 못한다. 그 일이 일어나지 않았으니까. 보상은 나쁜 일이 일어난 후에 수습한 사람이 받는다.


'확판의 오류' : 고객이 아니라 직원들에게 판다. 직원들에게 팔아오라고 할당한다.


'비전의 오류' : 어느 날 갑자기 선포된다. 액자로 걸리고 홈페이지에 오른다. 직원들은 바로 잊는다.


'사장님 비서의 오류' : 많이 논다. 하지만 자를 수 없다. 그들은 '신성한 소'이므로.


'회의록의 오류' : 문제가 생길 때만 찾아본다. 회의록을 항상 말단이 쓰는 이유가 있다.


'신년사의 오류' : '금년'이 위기가 아닌 때가 없다.


'보고서의 오류' : 보고서의 생존기간은 보고서가 처음 만들어진 후부터 보고가 완료되기까지이다.


'이면지의 오류' : 회사가 어려워지면 가장 먼저 이면지를 찾는다. 그러면서 왜 꼭 종이로 봐야 하는지 생각하지 않는다.


'리모콘의 오류' : 빈 자리가 있으면 버튼을 추가하려 한다. 1년에 한 번 쓸까말까한 기능으로.


'혁신의 오류' : 그저 개선을 혁신이라 부른다. 아니, 개선이든 개악이든 새로 만들었다 해서 혁신이라 부른다.


'칭찬의 오류' : "잘했어. 하지만....", "훌륭한 보고서야. 하지만....", "좋은 아이디어야. 하지만..." 칭찬 듣는 사람의 마음엔 '하지만'만 남는다.


'윤리경영의 오류' : 오직 직원들만 지켜야 한다. 회장님과 사장님은 예외다.


'근태관리의 오류' : 지각 출근만 뭐라한다. 야근은 뭐라하지 않는다.


'사업타당성 분석의 오류' : 그 사업을 '하는 방향'으로 분석한다. 사장님이 알아보라고 했기에.


'대안의 오류' : 2안은 항상 1안보다 못하다.


'IT의 오류' : IT시스템이 많아질수록 업무량이 많아진다. 기대와 반대다.


'임원회의의 오류' : 임원회의 준비를 위한 회의를 한다. 정기 임원회의는 이메일로 대체해도 별 문제 없다.


'교육의 오류 1' : 교육을 안 시켜준다고 말한다. 하지만 교육 갔다 와도 달라지는 건 별로 없다.


'교육의 오류 2 : 일 잘해서 바쁜 사람보다 한가한 사람이 교육을 더 많이 받는다.


'팀장 선임의 오류' : 한번 팀장이면 계속 팀장이다. 팀장이 팀원이 되는 법이 없다.


'컨설팅의 오류' : 종종 컨설턴트를 교육시켜 준다. 비싼 돈을 주면서까지.


'동기부여의 오류' : 팀장이 팀원에게 동기부여하라고 한다. 팀장은 누가 동기부여해주나?



Posted by SB패밀리

[기획/마케팅] 대접받는 외국 컨설턴트, 푸대접 받는 우리나라 컨설턴트
2011.06.22
출처: http://www.talk-with-hani.com/archives/1375

외국 회사와 일을 해보신 분들은 아시겠지만, 특히 선진국이라고 하는 서양 엔지니어와 일을 하려면 업무 범위를 명확하게 해야 합니다. 일단 귀한 그분들을 바다 건너 먼 곳에 있는 우리나라로 불러서 일을 같이 하게 하려면, 컨설팅 비용과 더불어 체류비를 지불해야 합니다. 컨설팅 비용도 무척 비싼데 체류비까지 합하면, 흔히 말하는 우리나라의 고급 기술자에 해당하는 한달 치 비용이 외국 컨설팅 한명의 하루 일당으로 지불해야 하죠.

이렇게 몸값이 비싸다 보니 이분들한테 일을 줄려면 매우 명확하게 정의해서 줘야 합니다. 일을 명확하게 정의해서 주려다 보니까, 우리나라에서는 몇 마디로 될 요구사항 정의도 번듯한 문서로 만들어서 전달해야 하기 때문에, 담당자 입장에서 외국 컨설턴트와 일하는 게 쉽지 않죠. 그리고 컨설팅 범위가 조금이라도 늘어나면 전체 범위를 다시 이야기해야 하기 때문에, 이것도 담당자 입장에서 고충입니다.

제대로 대접받고 있는 그분들을 보고 있자면, 대한민국 국적을 달고 컨설턴트로 일한다는 것은, 어떤 의미가 있나하는 생각이 들기도 하죠. 즉 대한민국 국적의 컨설턴트로서 제대로 대접을 받는 것 같지도 않고 프로젝트 시작 전에 정한 범위는 프로젝트 시작과 더불어 바뀌어서 안 해도 될 일을 하려고 야근과 특극을 할 때가 많죠. 그분들의 제대로된 대우 때문에 자괴감이 들기도 하지만, 반대로 그분들이 그런 대우를 받는 이유가 뭘까,를 고민해 보면 동서양의 문화 차이를 확실히 알 수 있습니다.

‘생각의 지도’란 책이 있죠. 동양과 서양의 차이점을 다룬 책입니다. 이 책에서 영감을 얻은 EBS에서 ‘동과 서’라는 제목의 다큐멘터리를 만들었고, 동명의 책도 출판했습니다. 저는 원전도 읽고 다큐멘터리도 보고, 얼마전에 동명의 책도 읽었습니다. 왠만해서 복습을 하지 않는 제가 이렇게 반복적으로 읽고 시청한 것은, 원전을 재미있게 읽고 다큐를 흥미롭게 봤기 때문입니다.

‘생각의 지도’에서 주장하는 동양과 서양의 문화 차이는 무엇일까요? 다양한 사례가 나오지만 요약을 하자면, 서양은 객체에 중심을 둔 문화이고 동양은 관계에 중심을 둔 문화라는 것이죠.

이런 이유로 객체를 중심에 둔 서양은 객체를 설명하는 명사가 발달했고 동양은 관계를 설명하는 동사가 발달했습니다. 이 이야기는 번역을 다룬 포스트에서 몇 번 다루었죠. 예를 들자면 이런 것이죠. 친구에게 차 한잔을 더 권할 때 영어에서는 “more coffee?”라고 묻고 한국어에서는 “더 마실래?”라고 합니다.

객체 중심과 관계 중심이 무슨 차이가 있냐고 반문하시는 분들이 있겠지만, 이 차이 때문에 동서양은 완전히 다른 반대의 길로 근대역사를 만들어왔죠. 서양에서는 객체 중심이기 때문에 개인주의가 발달했고 객체를 쪼개서 객체의 본질을 파악하는 분석, 즉 과학이 발달했습니다.

이에 반해 동양에서는 관계가 중요하기 때문에 커뮤니티 속에서 원활한 관계를 형성하는 게 중요해서 개인보다 조직의 발전을 중심으로 두었고, 어떻게 하면 관계 속에서 제대로 된 역할을 할까를 고민했기 때문에 윤리학이나 철학이 발달했습니다.

길게 동서양의 차이를 이야기했는데요. 이게 어떻게 동서양의 컨설팅 문화를 다르게 했을까요? 서양의 컨설턴트는 컨설팅 목표가 있다면 컨설팅 목표라는 객체 중심으로 프로젝트를 인식합니다. 그렇기 때문에 컨설팅 목표가 무엇이고 아니고를 명확하게 하는 게 중요하죠. 따라서 컨설팅 업무 밖의 일은 자신이 관여할 것이 아니기에, 컨설팅 초반에 업무를 명확하게 정의하고 자기 영역이 아닌 일은 안 합니다.

이에 반해 동양에서는, 즉 우리나라에서는 컨설팅 목표보다는 고객과 컨설팅 회사의 관계가 더 중요하죠. 그렇기 때문에 컨설팅 목표는 명확하지 않게 됩니다. 즉 일단 컨설팅을 시작하면 고객과 컨설팅 회사는 좋은 관계를 유지하는 게, 초기에 설정한 컨설팅 목표를 달성하는 것보다 더 중요합니다. 따라서 컨설팅 목표와 범위가 수시로 바뀌죠. 이런 이유로 우리나라 컨설턴트는 밤낮으로 격무에 시달린 가능성이 높습니다.

동서양의 컨설팅 문화가 다른 이유를 길게 적어 봤는데요. 결론을 내리자면 제대로된 컨설턴트로 대접을 받고 일을 하고 싶다면, 확실히 동양의 문화보다 서양의 문화가 낫죠. 반대로 컨설팅의 능력보다 고객과의 관계를 형성하는 데 자신이 있는 컨설턴트나 회사는 동양의 문화가 더 좋을 겁니다. 하지만 우리가 좋아하는 글로벌 회사가 되려면, 서양의 문화를
번성하게 하는 편이 컨설턴트나 고객 모두 좋겠죠.

========================================================
댓글
  1. 게렉터 Says:

    앞부분의 컨설팅 행태 차이에 적극 동의합니다만, 후반부에 동서양의 근본적인 문화 차이라는데에는 저는 생각이 다릅니다.

    동양 문화의 특징이 “관계중심”이라는 것도 좀 의아스럽습니다만, 그런 특징이 있다고 해도 그게 굳이 컨설팅 산업에만 특별히 크게 발현될 이유가 있다는 생각하지 않습니다. 그저, 선진국에서는 자유로운 사업을 하기를 바라는 우수 전문가들이 컨설턴트가 되어 기용되는 반면에, 후진국에서는 안정적인 조직에 속하지 못하고 잔류하게된 지식/기술 인력들을 임시 용역 형태로 활용하던 과거 산업 구조의 폐습에 갇혀 있기 때문 아닌가 생각 합니다.

  2. Hani Says:

    좋은 의견 감사합니다.
    말씀하신 것처럼, 동양의 관계중심의 비즈니스,
    서양의 목표(객체)중심의 비즈니스가
    꼭 컨설팅 영역에서만 국한된다고 생각하지
    않았습니다.
    흔히 말하는 프로젝트성 성격에서 골고루 발현된다고
    생각하죠. 다만 컨설팅의 업무 성격에 맞춰서
    설명을 집중적으로 했습니다.

    동양문화의 관계중심에 관한 설명은,
    본문에서 짧게 다루었기 때문에…조금
    설명이 부족한 것 같습니다. 시간이 되신다면
    언급한 다큐나 책을 읽어 보시면
    깊게 잘 아실 수 있습니다.

    말씀하신 선진국 컨설턴트와 후진국 컨섵턴트와의
    차이가, 제 경험으로 부연 설명이 될지 모르겠는데요.
    이런 경험을 한 적이 있습니다.

    능력 있는 컨설턴트였는데 한국 회사에 있을 때
    상당한 격무에 시달렸는데, 외국 회사로 옮기면서
    일은 비슷한 수준이었지만, 그분을 대하는 고객의
    태도가 많이 바뀌었습니다.
    아마도 우리나라 회사들이 외국계 회사와 일을
    하다 보니 그들의 문화적 습성을 많이 인정해
    주고 그런 게, 제가 아는 분의 사례에서
    발현된 게 아닐까 합니다.

  3. gt1000 Says:

    안녕하세요.
    저도 첫번째 댓글 다신 분의 말씀에 전적으로 동의 합니다.

    후진국에서는 안정적인 조직에 속하지 못하고 잔류하게된 지식/기술 인력들을 임시 용역 형태로 활용하던 과거 산업 구조의 폐습에 갇혀 있기 때문 아닌가 생각 합니다

    이게 가장 근본적인 이유 같습니다.

  4. Hani Says:

    의견 감사합니다!
    컨설팅이 용역의 폐습에 문화에 갇혀 있다는
    의견이 맞다고 가정해 보겠습니다.

    앞의 댓글에서 말씀드렸지만, 동서양의
    일 범위를 정하는 것은 단지 컨설팅 문제에
    국한되어 있다고 생각하지 않습니다.
    컨설팅 사례를 들어서 설명 드리는 것이고요.

    제가 경험한 해외 용역과 국내 용역 사례로
    말씀드리죠.
    일단 해외에 용역을 주려면, 제가 몇 번 일한
    경험으로 단순 개발이라 하더라도 스펙을 명확하게
    하지 않으면 계약이 어려웠습니다. 그쪽에서는
    정확하게 어디까지 해야 되는지 정해달라고 했고,
    그 기대에 맞춰 작업하는 게 쉽지 않았습니다.

    제가 관리한 국내용역 사례로, 제가 pm을 맡아서
    첫 번째로 한 프로젝트였는데요. 외주 개발이
    있었습니다. 처음 pm을 하다보니까, 일을 정확하게
    하고 싶어서 흔히 당시에 사용하는 외주관리
    기법인 ‘알아서 해줘’에서 탈피하고자 개발 사양서를
    무척 상세하게 작성했습니다. 약 100페이지 정도
    됐습니다. 저처럼 요즘 일하시는 분도 있겠지만,
    대개 국내 외주 용역을 알아서 해 가지고 와가
    일반적인 상황이죠.

    일단 제가 일한 방식은 외국 용역 업체를 관리하는
    방식인데, 윗분들은 뭘 그렇게 힘들게 일하냐는
    멘트를 날리셨습니다. 그냥 갑을의 관계를 활용하라고
    하셨죠.

    뭐 이런 연유로 전, 외국기업 즉 목표(객체)를
    중요하게 여기는 것과, 갑을의 관계처럼 관계중심으로
    접근하는 방법이 있다고 생각합니다. 어느 게
    좋냐?는 일단 판단을 유보하겠습니다.

    따라서 전… 말씀하신 부분에 일정부분 동의하나
    컨설팅 업무가 용역의 폐습에 갇혀 있다하더라도..
    그건 용역이냐 컨설이냐는 본질은 아니라고
    생각합니다. 일을 어떻게 접근하느냐가 핵심이죠.

  5. Hani Says:

    부연하자면,
    그런 일을 접근하는 건 개인의 문제라기보다
    문화의 문제죠. 즉 개인의 활동이 발현되는 것은
    그 근본이 문화라고 생각하기 때문입니다.
    그랬을 때, 그 차이가 뭘까를 생각하면…



    ==================================================

    내가 생각하기에는 글을 쓰신 Hani님의 해외와 국내의 일에 대한 접근법이 객체와 관계가
    맞다는 생각입니다. 우리나라는 관계, 정이라는 것을 유지하기 위해서 관리자들은 항상
    적당히, 좋게좋게, 알아서, 다음에도, 주고받기 식으로 일을 많이 합니다.
    그래서, 이러한 관계 유지를 위해서 실무자들은 정해진 스펙이나 기획이 아니라 수시로 변화무쌍한
    스펙을 가지고 힘들게 일하고 있다는 생각을 많이 해봅니다. 모든 회사가 그렇다는 건 아니지만
    중소기업에 있으면 누구나 한 번쯤은 공감하는 이야기 인 것 같습니다.

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패밀리

훌륭한 컨설턴트가 되기 위한 세 가지 口訣
글/이정규/안랩코코넛 대표이사
 
필자는 한 때 컨설턴트 직업에 대한 지향을 가진 적이 있었다. 10년 전 까지만 해도 IT 컨설턴트는 업계 경험이 적어도 20년은 넘어야 명함을 내밀 수 있다는 것이 일반적인 생각이었다. 그러나 최근에는 젊은 프로페셔널도 컨설턴트의 직함을 새겨 다니는 것을 보면 컨설팅 업무의 모델이 많이 변화된 것 같다.

필자의 경험에서 배움의 열망이 컷 던 시절인 90년 중반, 일본에서 미국의 D.H. Brown에서 온 두 명의 컨설턴트로부터 교육을 들었다. 일본 수강생들과 함께 영어로 수업을 들었는데, 영어에 대한 핸디캡인지 일본 수강생들은 거의 질문도 없었고, 강의 후에 강사를 심심하게 만들었다. 필자는 강사들에게 수업 후 세션을 제안했고, Pub 바에서 맥주를 겸한 저녁식사를 같이 하게 되었다.

맥주를 몇 잔 하자 분위기가 화기애애해졌고, 필자는 한 컨설턴트들에게 질문을 던졌다. “훌륭한 컨설턴트가 되려면 무엇이 필요한가? 당신은 25년 이상 컨설팅하면서 깨달은 중요한 것들이 무엇인지 전수해 줄 수 있는가?”. 질문은 받은 그는 씩 웃으며 “오늘 맥주 값 당신이 내겠소?”라고 묻자 나는 선뜻 “그렇다.”고 했다. 골똘히 ? 珝▤求?그는 다음과 같은 이야기를 해주었다.

훌륭한 컨설턴트 혹은 프로젝트 매니저는 다음의 세가지 지침을 잘 지키면 된다는 것이다. 이 지침은 너무 심오하고, 일반인들에게는 오해를 불러 일으키는 말이니, 필자만 알고 있고 절대로 제3자에게는 노출시키지 말라는 것이었다. 필자는 그의 말을 냅킨에 메모하고 오늘날까지 기억하고 또한 명심하고 있다.

오늘 필자가 그 컨설턴트의 무림비급(?)을 전달하지만, 잘못 수련하여 주화입마(走火入魔) 에 빠지는 것은 책임질 수 없다. 무엇보다 그 행간의 의미를 정확하게 파악하는 것을 주지하기 바란다.

첫째, 내일 할 일을 오늘 하지 마라!(Don’t do what you can do tomorrow!)
둘째, 남이 할 수 있는 일을 네가 하지 마라!(Don’t do what others can do!)
셋째, 받은 만큼 일해라(Don’t overwork above what you got paid!)


이 세 가지 지침을 듣는 순간, 필자는 한대 얻어 맞은 것처럼 망연해 졌다. 내용이 “성실과 정직”과는 거리가 멀게만 느껴지는 궤변같이 느껴졌기 때문이다. 설명은 이랬다. ‘첫 번째, 많은 컨설턴트는 내일 할 수 있는 일임에도,! 조바심에 미리 그 일을 앞당겨 하려는 습성을 가졌다. 이는 프로? ㎷?구성 원을 과로에 시달리게 만들고, Man-month 기반 프로젝트의 경우 고객이 서비스 금액에 의문을 갖게 한다는 것이다.

두 번째, 프로젝트팀은 다양한 경력과 스킬(Skill)을 보유한 “다기능팀”이어야 한다. 그런데 남이 맡은 일을 내가 해 버리면 상대방의 존재가치를 떨어뜨림은 물론, 자신의 과업을 위한 시간을 허비하게 되고, 조직의 구성도 최적화되어 있지 않다는 것을 반증한다는 것이다.

세 번째, 서비스 초기에 분명치 않던 고객의 요구사항은 시간이 지나갈수록 더욱 많아지게 마련이고, 협상력이 떨어지는 프로젝트관리자는 추가적인 수익이 없는 과도한 일을 멤버들에게 전가하게 마련인데, 이러한 고객의 요구는 더욱 거세진다. 이는 프로젝트의 납기를 지연시킴은 물론 수익성과 직원의 모럴을 떨어뜨리게 된다. 그는 “때때로, 컨설턴트는 고객의 과제를 즉시 해결할 방법을 제시할 수 있더라도, 계약된 기간에 맞추어 해답을 내는 것이 더욱 현명하다”는 코멘트도 덧붙였다.’

강사의 말을 필자가 잘 이해하였다고 하자, 그는 이야기의 반만 했다고 하며, 위의 원칙은 다음의 세 가지 대응원칙과 균형을 이루어야 한다고 했다! .

첫째, 내일 할 수 없다면, 반드시 오늘 해야 한다.
둘째, 남이 할 수 없다면, 가르쳐서 해내거나 네가 직접 해야 한다.
셋째, 일을 더했다면, 보상을 요구한다.


설명하면 첫 번째, 일정을 맞추기 위하여 오늘 해당과제를 완료해야 한다면 반드시 해내야 한다는 것이다. 두 번째, 타인에게 과업 위임을 할 수 없다면, 해낼 수 있도록 교육을 하거나, 시간에 쫓긴다면 내가 직접 해내야 한다는 것이다. 세 번째, 계약된 공수 이상의 과업을 수행하였다면, 그 대가를 요청하거나 추후 2차 사업에서 보전할 수 있도록 고객을 빚쟁이로 만들어야 한다는 것이다. 당시에 앞 부분의 세 가지 원칙 보다 뒤 부분의 세 가지 대응 원칙이 필자는 이해하기가 쉬웠다. 여러분은 어떠한가? 앞 부분의 세 가지 원칙을 쉽게 이해하였다면 여러분은 분명 내공이 출중한 컨설턴트로서의 자질이 있다 하겠다.

필자 이정규 안랩코코넛 대표이사는 현 정보보호산업협회의 부회장, 정보관리기술사, 미국공인회계사로 IBM과 안철수연구소를 거쳐 안랩코코넛에 이르기까지 22년간 IT 산업에 종사하여온 IT 전문가이다
Posted by SB패밀리