달력

09

« 2010/09 »

  •  
  •  
  •  
  • 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
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
  •  
소프트웨어 테스팅의 중요성에 대한 각성

이란 글에 잘 나와 있듯이
지금이라도 테스트의 중요성을 깨닫고 시행을해야 한다고 생각합니다.

아주 작은 수의 기업이지만,
이미 몇몇 기업에서는 "소프트웨어 테스트"를 도입하고 있습니다.

위의 글의 나와있는 예들 중 하나는 제가 몸담았던 회사에서 했던 프로젝트입니다.
그 기업에는 제도적으로 '테스트' 과정을 도입하였고 시행을 하고 있었습니다.

어떤과정을 거쳤는지 정확히 알길은 없지만,
제도적으로는 존재하기 때문에,
그 프로젝트 역시 어떤식으로든 '테스트'의 과정은 거쳤을 것이라 봅니다.

그런데도, 문제가 터졌습니다.


그 이유는 소프트웨어 테스트에 대한 잘못된 인식 입니다.


소프트웨어 테스트라고 하면 제조업의 품질 검사 과정을 떠올리게 됩니다.
이 둘은 제품의 기능 점검이라는 목적에서는 동일하지만, 차이가 보입니다.

제조업에서 품질 검사과정은 "검수" 이고, 소프트웨어 테스트는 "검증"입니다.

소프트웨어는 하드웨어와 부품의 조합이 아니라,
'논리'의 조합이기 때문에 당연히 검수가 아니라 검증을 해야합니다.


따라서 소프트웨어의 테스트에는
기능 테스트도 포함되어 있지만,
더 중요한 것은
논리 오류의 가능성찾아내고 그것을 검증하는 일
입니다.



그런데, 소프트웨어 테스트를 '제품검수'하듯하니
효과가 전혀없는 것이죠.
(오히려 개발에 부담만 주고 있습니다)


소프트웨어 테스터들은 초보자는 불가능하며 어느 정도 수준이 갖추어야 합니다.

의혹이 있는 부분을 찾아야하고 검증또한 해야하기 떄문에 당연한 거죠
(외국의 경우 개발자와 테스터는 직군이 다르며, 최소 경력이 3~5년은 되어야 테스터로서 입문이 가능하다고 들었습니다)

그런데, 우리나라의 경우를 테스트를 도입한 기업 경우도 전문 테스터를 두는 경우는 찾기가 매우매우 힘듭니다.

제가 있었던 한 프로젝트에서도 테스트 과정을 도입하며 테스팅을 전문으로 하는 조직도 만들었지만, 정작 테스터로 지정된 인력은 웹디자이너  2년차였습니다. -_-;

이 역시 소프트웨어 테스트를
제조업의 '검수' 정도로 생각하는 인식 때문에 그런 것입니다.


현재로써는 제대로 된 테스터를 구하는 문제도 어렵습니다.

이미 누차 지적왜곡된 소프트웨어 개발 시장 구조 때문에 테스터로써 성장할 길이 전혀없기 때문입니다.

지인의 말을 빌리면 새로 시작하는 구글 코리아의 경우
우리나라에서 테스터로써 일할 만한 인력이 구할 수 없어
개발된 코드 테스트를 미국으로 보내서 한다는 군요
(그들은 테스트를 합니다!!!)


소프트웨어 사고들이 터지는 것을 보면 아무래도 기분이 좋지는 않습니다.

그런데, 이 글의 끝에서 처럼 매번 사고의 원인을 소프트웨어 개발자에게 모든 책임을 돌리는 것은 보면 분노가 치밉니다.

바보가 아닌 이상
한 두 번이야 그럴 수도 있겠거니 하겠지만, 매번 그런다면 개발자가 아니라 프로세스상 문제가 있다고 보는 것이 맞습니다.

이러한 문제는 '소프트웨어 테스트'를 도입하지 않아 생기는 문제입니다.


소프트웨어 테스트를 도입하길 권유합니다.
하지만, 소프트웨어 테스트를 제조업의 검수와 착각하여
오히려 부담만 가중시키고 효과는 전혀없는 어리것은 짓은 하지 않기 바랍니다.

덧붙여  동시에 소프트웨어 테스트를 위해  왜곡된 소프트웨어 시장을 바로 잡아 소프트웨어 테스터를 육성하려는 노력도 같이 기울여야 할 것입니다.



(덧글)

위의 글에서 나와 있는 예들도, 일반적인 상황에는 문제가 없지만,
어떤 특정한 조건에 대해 논리적 허점(논리 오류)이 발생하여,
생긴 문제들입니다.
( 마치 백조는 모두 희다고 생각했다가, 검은백조를 마주쳤을 때와 같죠.-성급한 일반화의 오류   이 논리 오류들 을 무의식 중에 지나치듯, 소프트웨어 개발 과정 중에도 그런 일이 종종 일어납니다)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 행복찾기 HappySeeker
소프트웨어 강국의 근간이기 위한 프로그래머의 조건

안철수 (안철수연구소)

2003/11/25


필자가 프로그래밍을 처음 시작한 지도 벌써 20년이 지났다. 우연인지 모르겠지만 필자가 막 컴퓨터 공부를 시작할 때 창간된 잡지가 마소였으니 필자의 컴퓨터 경력과 마소의 나이가 같은 셈이다.

처음 개발을 시작할 당시에는 지금처럼 많은 사람들이 컴퓨터를 쓰게 될 것이라고는 상상조차 못했었다. 8비트 컴퓨터인 애플 컴퓨터를사용하던 시절이었으니 가정에서 취미로 가지고 노는 정도였지, 업무용으로 사용한다는 생각은 하지 못할 상황이었다. 그러나 20년이지난 지금은 인터넷이 보편화되면서 가정마다 없어서는 안될 필수품으로 자리잡게 되었다.

그에 따라 개발 문화도 많이달라졌다. 당시 PC 개발자는 먹고 살 수 있는 직업이 아니었다. 초기에는 개발 자체에 재미를 느끼는 마니아들이 주축을이루었지만 생계를 위해서 다른 직업을 가지고 있는 경우가 많았다. 지금은 개발자도 어엿한 직업으로 자리잡았지만 열정이라는측면에서 보면 당시의 개발자들에게 지금의 개발자들이 배워야 할 점이 많지 않을까 생각된다.

초창기 국내 개발자들은많은 어려움을 겪어야 했다. 필자의 경우에도 자료를 구하는 데 무척이나 애를 먹었다. 인터넷도 없었고 주위에 물어볼 사람이 있는것도 아니었다. 혼자서 모든 것을 분석하고 풀리지 않는 모든 문제들을 스스로 해결해야 하는 상황이었다. 당시 국내에는 IT서적들도 별로 없었고 원서를 구하기도 만만치 않았기 때문이다.

80년대 후반부터는 컴퓨터 통신을 활용하여 미국통신망에 접속할 수가 있었다. 아무리 연구를 해도 도저히 풀리지 않는 경우에만 국제 전화를 걸어서 미국 사람들에게 물어보고자료도 받곤 했다. 당시 요금이 1분에 1000원이었으니까 1시간에 6만원 정도였는데, 당시에 필자 월급이 30만원 정도였던것과 비교해보면 엄청나게 비싼 요금이었다. 그밖에는 모두 직접 분석해서 알아냈고 롬바이오스나 운영체제도 어셈블리어 수준에서분석했다.

바이러스 분석도 마찬가지로 참고자료 없이 직접 분석해서 동작 원리를 알아냈다. 그러다 보니 그동안 공부한것과 경험을 토대로 바이러스 관련 책을 쓸 때는 참고서적 한 권도 없이 필자의 자료와 기억만을 가지고 완성할 수 있을 정도였다.이에 비해 요즘은 오히려 자료의 홍수 시대라고 할 만하다. 이제는 자료를 구하지 못해서 개발을 하지 못하는 경우는 거의 없는 것같다. 그런 점에서 예전에 비하면 개발 환경은 엄청나게 좋아진 것임에는 틀림없다.

코더와 아키텍트

예전보다는 나아졌지만 개발자에게 불리한 환경은 여전히 남아 있다. 국내 개발 환경의 특성과 한계 때문이다. 최근 이공계열 기피가심각한 문제가 되면서 개발자라는 위치 역시 다소 위축된 것처럼 보인다. 또한 우리나라에서는 전문가라고 할지라도 나이가 들면관리직이 되어야 성공했다는 사회적 통념 때문에 개발자가 선택할 수 있는 미래가 제한적이며, 개발자의 생명도 짧은 편이다.

많은 개발자들은 영원한 개발자로 남고 싶어하며 관리자로서의 변신에 대한 두려움들이 상대적으로 크다. 반면에 하루가 다르게 변하는 기술적 진보로 인해 후배와 동등한 위치에서 새로운 개념의 기술에 적응해야 하는 부담도 많이 느낀다.

개발자가 선택할 수 있는 미래라는 면에서 SI 업체와 패키지 소프트웨어 업체는 상황이 조금 다르다. SI 업체와는 달리 패키지소프트웨어 업체에서는 개발자가 선택할 수 있는 길이 조금 더 다양하다. 특히 패키지 소프트웨어 업체에서는 개발자의 연장선상에서하나의 전문직으로서의 아키텍트가 앞으로 절실히 필요한 상황이 도래할 것이다.

개발자들은 일반적으로 프로그래밍, 더정확하게는 코딩 자체에 많은 재미와 보람을 느낀다. 풀리지 않는 수학 문제를 오랜 고생 끝에 풀었을 때 희열감에 사로잡히고자신이 만든 프로그램이 잘 동작하는 것을 보면서 자신의 분신처럼 애정을 느낀다.

그러나 이러한 것은 개발자의 보람가운데 아주 작은 부분일 뿐이다. 미국에서는 이런 수준의 사람들을 코더라고 부른다. 많은 프로그래밍 경험을 통해서 좀더 수준이올라가다 보면 세부적인 코딩 자체보다는 전체적인 아키텍처, 흐름, 프로토콜 등 설계에 해당하는 일들을 맡게 된다.

그러나 우리나라에서는 (소프트웨어 산업의 역사가 짧아서이겠지만) 코딩하는 재미에 묻혀 있거나 그것이 개발자가 하는 유일한 일로생각하는 사람들이 많다. 물론 훌륭한 프로그래머 또는 아키텍트가 되기 위해서는 코더 시절에 탄탄한 기초를 다지는 것은필수적이지만 어느 정도 실력이 쌓인 후에는 코더 단계를 뛰어 넘으려는 노력이 필요하다.

개발자들이 코더 단계에서만머문 채 그 한계를 벗어나지 못하는 또 다른 이유 중 하나는 국내 패키지 소프트웨어 회사 수가 너무 적고 그 규모도 영세하기때문이다. 일정 규모 이상의 회사가 많다면 각 회사마다 다양한 노하우가 쌓이고 회사간의 제휴나 인력 이동을 통해서 자연스럽게함께 성장해 나갈 수 있겠지만, 숫자가 얼마 안 되고 영세하다 보니 같이 커 나갈 수 있는 여건이 형성되지 못한 것이다.

단적인 예로 현재 국내에서 100명이 넘는 개발자가 일하고 있는 패키지 소프트웨어 회사는 필자의 회사밖에 없다. 사정이 이렇다보니 개발자가 나아갈 길을 적절하게 조언해 줄 수 있는 전문가들이 많지 않은 것이다. 이는 우리나라 개발자들의 불행이자,우리나라 소프트웨어 산업의 불행이기도 하다.

국내 개발자들에게 부족한 점
IT 산업 발전에 따라개발자의 역할에도 변화가 생기고 주위에서 변화를 요구하기도 한다. 특히 전문성에 대한 요구 수준은 갈수록 높아지고 있다. 전문개발자로 남아서 계속 발전하기 위해서는 주위 여건도 여건이지만 개발자 자신의 부단한 노력이 필요하다. 그런 점에서 우리나라개발자들에게는 아직도 부족한 부분들이 많다고 생각한다.

가장 떨어지는 능력 중 하나는 바로 커뮤니케이션 스킬이다.그 이유는 필자를 포함하여 우리나라에서 교육을 받은 사람들은 개인 경쟁력 강화 위주의 공부, 즉 대부분 혼자서 책을 보고 공부를하고, 혼자서 시험 문제를 푸는 교육을 받아왔기 때문이라고 할 수 있다.

지금처럼 복잡한 현대 사회에서는 혼자서어떤 일도 할 수 없다. 개발을 할 때도 여러 개발자들간의 공동 작업이 요구된다. 또한 개발자만 작업해서 되는 것이 아니라마케팅, 영업, 고객 지원, 기술 지원을 비롯하여 고객과도 직접 의사소통을 하면서 일을 해나가야 되는 세상이다.

이처럼 현대 사회에서는 커뮤니케이션 스킬이 필수적이지만 대학교를 졸업하고 바로 회사에 들어오는 사람들 가운데는 본인이 생각하는 바를정확히 말로 표현하지 못하고 다른 사람이 말하는 것들을 정확하게 알아듣지 못하는 경우도 생각보다 많다.

둘째는 여러사람들과 같이 팀으로 일해 본 경험이 부족하다 보니 팀 작업을 할 때 어떤 일을 어떻게 분담해서 하는지, 개발 이외의 다른 분야사람들과 어떻게 일을 나누어 해야 하는지에 대한 훈련이 되어 있지 않아서 프로젝트 진행에 난항을 겪는다. 개발자들이 일정 수준의단계를 뛰어 넘어 성장하기 위해서는, 즉 코더를 벗어나기 위해서는 공동으로 진행하는 큰 프로젝트의 경험이 필수적이다.

여기서 이야기하는 공동의 프로젝트, 큰 프로젝트라는 것은 SI 프로젝트보다는 패키지 소프트웨어 개발 경험이다. 그러나 불행하게도우리나라에서는 SI 업체는 많지만 패키지 소프트웨어 개발 업체가 많지 않다 보니 경험을 쌓고 한 단계 도약할 수 있는 여건이조성되어 있지 않은 것이다.

셋째로 전문 지식 자체도 떨어지는 편이다. 특히 전산학과를 갓 졸업한 사람들 중에는바로 소프트웨어 개발 회사에 투입되어 개발을 할 수 있는 사람은 많지 않은 편이다. 업무에 필요한 지식보다는 학문에 필요한 기초지식만 가지고 있다 보니 이들 간의 간격이 상당히 크다.

대기업이라면 많은 사람들에게 한꺼번에 자체적인 교육을 시킬수 있겠지만 현재 패키지 소프트웨어 업체들은 벤처기업들이기 때문에 교육을 시킬 수 있는 여건이 부족하다. 따라서 결국은 학교를다니면서 스스로의 열정이나 재미에 의해서 개발을 했거나 프로젝트를 했던 사람들을 주로 채용할 수밖에 없다.

미래형 개발자의 요건
시간이 흐를수록 모든 분야가 점점 더 어려워질 것으로 보인다. 미래에는 두각을 나타내려면 최소한 두 분야 이상의 깊이 있는 전문지식을 가지고, 그것들을 바탕으로 다른 사람이 만들어내지 못하는 새로운 것을 만들어 내는 사람, 다른 사람 또는 다른 부서와열린 마음으로 잘 협조할 수 있는 사람, 큰 시야와 창조적인 마인드를 가진 사람만이 성공할 수 있을 것이다.

개발자는미래에도 역시 사회의 가장 중요한 인프라를 담당하는 일꾼이 될 것이다. 전산분야는 모든 분야에서 사용할 수 있는 하나의 툴이자인프라이다. 따라서 자기 전공과 상관없이 지식 경영적인 측면에서 접근하고 전산을 잘 활용하는 사람이 결국은 두각을 나타낼 것이다.

그것은 하나의 전공만 잘한다고 되는 것은 아니다. 따라서 전산 전공자들도 결국은 다른 분야에서 전산을 활용하는 사람들에게 부가가치를 제공해 줄 수 있는 사람이 되지 않는다면 오히려 생존하기가 힘들어질 것이다.

이러한 생각은 자기의 발전을 가로막는 가장 큰 걸림돌이 된다. 다른 분야에 대한 기초 서적을 틈틈이 읽으면서 사고의 폭을 넓히고업무를 하면서 다른 분야 사람들의 이야기를 많이 듣고 그들을 이해하려고 노력한다면 진정한 전문가로 클 수 있는 좋은 뒷받침이 될것이다.

이와 함께 개발자에게는 '창조적 마인드'가 필수적이다. 인터넷이 확산되면서 기존 것을 그대로 가져다사용하거나 베끼는 것을 갈수록 많이 본다. 예전 같으면 상상도 할 수 없었던 일이다. 옛날에는 소스를 구하기도 어려웠지만 구할수 있더라도 처음부터 끝까지 자신이 직접 만들어 보아야 직성이 풀리는 사람도 많았다.

물론 그러한 방법은 실제프로젝트에 들어가면 시간이 많이 걸릴 수 있겠지만, 이를 통해 자신의 실력을 쌓고 발전시키다 보면 나중에는 아무도 못 푸는문제를 자기가 풀 수가 있는 것이다. 따라서 이 두 가지 방법을 적절하게 활용하는 자세가 필요하다.

마지막으로필자는 우리나라 개발자들이 한마디로 '혼이 있는 개발자'이었으면 한다. 누구나 개발자는 될 수 있다. 그러나 누구나 할 수 있는것이 아니라 오직 나만이 할 수 있다는 자신감과 함께 주어진 일이고 직업이기에 하는 것보다 능동적이고 적극적으로 임하는 '장이'기질이 있어야 한다. 도자기는 누구나 만들 수 있지만 백자나 청자는 아무나 만드는 것이 아니기 때문이다.

전문가 육성을 위한 근본적인 접근이 필요하다
우리나라가 글로벌 시장에서 경쟁력을 갖추려면 지식정보 분야를 집중 육성해야 한다는 목소리가 높다. 지식정보 분야의 핵심은 소프트웨어인데 국내 환경은 전문가를 키우기가 어려운 구조이다.

그렇기 때문에 정부에서는 단기간의 처방보다는 장기적이고 근본적으로 이 사회가 요구하는 진정한 전문가를 키우고 국가 경쟁력을강화하기 위한 제도적인 접근을 해야 한다. 또 학계에서도 업계와 협조하고 피드백을 받아서 현대 사회에 맞는 인재를 양성하기 위해많은 노력을 해야 한다.

전문가형 개발자 육성을 위해서 교육 제도의 개선 노력도 반드시 필요하다. 특히 대학에서가르치는 것과 현장에서 요구되는 것의 간격을 메우기 위한 노력이 일차적으로 필요하다. 교육 과정에 대해서는 인도가 좋은 벤치마크모델이 될 수 있다고 생각한다. 인도 역시 10여 년 전만 하더라도 지금처럼 많은 우수한 개발자들을 배출하는 소프트웨어 강국이될 것이라고는 아무도 생각하지 못했다.

현재 마이크로소프트 본사에서 인도 사람들이 나가버리면 회사가 쓰러질지경이라고 이야기할 정도로 이들의 비중은 높다고 한다. 이는 제도적인 측면에서, 특히 교육 제도적인 측면에서 올바르게 접근했기때문에 가능한 결과라고 생각한다. 우리나라도 인도를 벤치마킹해서 우리 실정에 맞는 제도를 운영한다면 경쟁력 있는 개발자들을 많이배출할 수 있지 않을까 한다.

또한 개발자뿐만 아니라 풍부한 경험을 갖춘 프로젝트 매니저를 육성하기 위한 고민도필요하다. 프로젝트 관리를 잘해서 함께 경험을 쌓고 시행착오를 줄이기 위해서는 프로젝트 매니저의 역할이 필수적인데, 우리나라의패키지 소프트웨어 회사들은 이러한 프로젝트 매니지먼트가 외국에 비해서 상대적으로 취약한 편이다. 국내 소프트웨어 산업이 국가경쟁력의 근간으로 자리매김하기 위해서는 개발자 자신들의 끊임없는 노력은 물론 전문 인력 양성을 위한 개발 환경의 성숙이필수적이다. @

* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다.
크리에이티브 커먼즈 라이선스
Creative Commons License

'관찰일지 > 나누고 싶은 글' 카테고리의 다른 글

창의(創意)란 무엇인가?  (1) 2007/08/06
창조성이란 무엇인가?  (0) 2007/03/27
[안철수 컬럼] 경쟁력 있는 프로그래머의 조건  (0) 2006/10/05
Social Software에 대한 기대감  (0) 2006/10/05
한국대학이 가야할길  (1) 2006/09/08
Why AJAX  (0) 2006/03/23
Posted by 행복찾기 HappySeeker