소프트웨어 엔지니어에게 기대되는 품성과 능력


들어가며

이 글은 IT업계로 뛰어드는 후배들에게 하고 싶은 이야기일 뿐 아니라본인 스스로에게 다짐하고자 하는 목적으로 쓰는 글입니다.

최근 IT업계에서 엔지니어들에 대한 부당한 대우가 이슈가 많이 되고있습니다.

그 원인이 엔지니어에게 있다고 말하려는 것은 아닙니다. 또한 그 환경에대한 논의는 다음 기회에 하겠습니다.

다만 제가 제기하고 싶은 것은 열악한 외부의 요인 때문에 자질기준을 스스로 깍아내려도 되는가?라는 것입니다.

 

SE 는누구인가?

l       프로그래머, 개발자, 소프트웨어 엔지니어
프로그래머나 개발자라는 말 대신 소프트웨어 엔지니어란 용어를 쓰는 것은, 개인적으로 '엔지니어'라는단어를 좋아하기도 하거니와 '프로그래머' '개발자'라고 할 때는 '코더'라는 좁은 의미로 사용되는 경우가 많기 때문입니다.
이 글에서 '소프트웨어 엔지니어(Software Engineer 이하 SE)' (요구사항)분석가, 아키텍트/설계자, 코더를 모두 포함하지만 기술영업이나 IT컨설턴트, 프로젝트 관리자는 포함하지 않습니다.
(SE
System Engineer의 약자로 사용되기도 하지만 여기서는 Software Engineer의 의미로 사용하겠습니다)

l       SE를 정의한다면
SE
컴퓨터와 사람 사이의 통역가입니다.
위의 정의에서 '사람'은 고객, 기획자, 설계자, 동료SE 혹은 본인일 수도 있습니다.
통역가는 양쪽 언어의 '이해' '표현'에 모두 능란해야 합니다.
특히 사람-사람 사이의 의사소통은 정보누락 혹은 왜곡이 쉽게 발생하기 때문에 '해석' '유추'를 통한 의역을 해야 할 경우가 많으며 심지어 감정이 개입되기도 하기 때문에 사람-컴퓨터의 대화보다 훨씬 어렵습니다.

요구사항분석가의 경우 통역의 능력보다는 토크쇼 혹은 정치토론 사회자와 같은 의사소통 진행능력이 더 필요합니다.
저는 소프트웨어 구축 프로젝트는 일련의 통역 과정이라고 봅니다. 다행인 사실은 실시간 통역을해야 하는 경우는 별로 없다는 점입니다.

 

SE에게필요한 품성

l       책임감
약속(혹은 계약)은 반드시 지켜야 합니다. 지키지 못할 약속이라면 하지 말아야 합니다. 작업 진행 중에 약속을지키지 못하리라 판단된다면 최대한 빨리 상대에게 알려야 하며 이때 최대한 불이행의 이유와 함께 대안을 제시해야 합니다. 
SE
가 하게 되는 약속은 크게 기능약속, 일정약속, 품질약속 3가지가 있으며 암묵적으로 약속되기도 하고 세부사항이 애매한 경우가 많으므로 주의해야 합니다.

l       고객(의 입장)에대한 이해
"
감정이입이야 말로 자신이 도움을 주는 관계를 움직여 나가는 데 있어서 중심이 되는 기술이다."(펜실베니아 주립의대 E.A. Vastyan 교수. '생각의 탄생' )

l       정직
정직은 신뢰의 바탕입니다. 신뢰는 협력의 필요조건입니다.협력 없이 혼자 할 수 있는 일은 아주 적습니다.
일정이 초과될 것 같다고 말하십시오. 내 소스에 버그가 있다고 시인하십시오. 고객의 비용을 절감할 수 있는 다른 방법이 있다고 고백하십시오.
양심은 정치인, 법조인에게만 필요한 것이 아니라 엔지니어에게도 필요합니다.

l       프로정신, 장인정신
엔지니어는 프로페셔널입니다. 프로는 계약에 의해 움직입니다. 프로는 제공하는 시간이 아니라 만들어내는 결과(output)에 대해 금전적 대가를 받습니다.

 

SE에게필요한 능력

l       추상화, 모델링 능력
SE
라면 코더로 시작하여 나중에는 분석/설계업무를 하게 됩니다. 분석/설계는 문제 (혹은업무)에 대한 추상화와 모델링과정이라 할 수 있습니다. 이것은 작업의 순서와 조건을 다루는 코딩작업과는 다른 유형의 사고를 요구하는데 이런 사고는 부단한 훈련을 통해서만 얻을 수 있습니다.

l       의사소통능력
프로그래머에게는 100마디 말보다 슈도코드pseudocode 를 보여주는 편이 낫습니다.
고객에게는 슈도코드 pseudo code 보다 다이어그램을 보여주는 편이 낫습니다.
대상에 따라 효과적인 표현방법을 선택할 줄 아는 능력이 의사소통능력입니다.

l       기술력
프로그래머들은 계속 공부를 해야 하기 때문에 직업적으로 힘들다라고 말하는 사람들이있습니다. 그러나 소프트웨어 공학적 지식들을 모두 암기할 필요는 없으며 또 현실적으로 불가능합니다.
JSP
의 내장객체에 무엇이 있는지 알고 있습니까? 저는 잘 모릅니다. 그러나 내장객체가 있다는 것은 알고 있으며 그것은 Servlet API에 명시되어 있다는 것을 알고 있습니다.
하지만 JSP에 내장객체가 있다는 사실은 반드시 알고 있어야 합니다. 그렇지 않다면 그것을 구현하느라 삽질을 해야 할지도 모릅니다.


l       창의력
문제를 해결하는 방법은 여러가지입니다.

l       응용력
같은 문제를 매번 새롭게 대하지는 않습니까?
내림차순 정렬을 할 수 있다면 오름차순 정렬도 할 수 있어야 합니다.

l       영어
직접 외국인 고객이나 엔지니어를 상대하기 위해 필요할 수도 있지만 사실 그런 경우는 거의 없다고 봅니다.
영어를 해야 하는 이유는 외국어사이트 검색을 위해서입니다.
그래서 SE들에게는 듣기/읽기능력보다는 독해능력이먼저 필요합니다.
정보를 찾기 위해 국내의 묻고 답하기 서비스를많이 이용하지만 절대 과신해서는 안됩니다.
왜냐하면 잘못된 정보도 있으며 무엇 보다 양이 적기 때문입니다. 기술력이 향상되면 향상될수록그곳에 자신이 원하는 정보의 양은 줄어든다는 것을 느끼게 될것입니다.
SE
를 하다 보면 반드시 부딪히게 될 문제이므로 평소에 미리 준비해야 합니다



- -



Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

마이크로소프트 Hero 블로그

mechanic VS operator VS engineer
  • 산골소년 2008/01/09 20:32 # 삭제 답글

    오랜경험이 담아있는 유익한 포스팅 잘 읽었습니다. ^ ^
  • 2008/03/18 01:18 # 답글 비공개

    비공개 덧글입니다.