금융보안과 한국 소프트웨어 미래의 심각성

아래 기사는 필자가 안철수연구소의 부사장/CTO 였던 거의 9년전인 2006년에 연두기자회견때 기자들과 인터뷰했던 내용이었다. 필자도 금융권을 해킹할 수 있다는 내용일 만큼 파격적이어서 그 당시에는 여러군데 기사가 나왔었다. 당시에 잠깐 큰 이슈가 되었었지만 내용의 심각성때문인지 곧 덮어졌다. 아마도 이해관계가 얽힌 다양한 기득권층에게 이익이 되지 않기 때문이었으리라고 추측한다.

요새 농협의 증발해 버린 돈 사건에서 처럼 중국 해커들이 돈을 인출해 가는 것은 필자가 기자회견에서 예견했듯이 너무 뻔한 인과의 결과이기 때문에 앞으로도 계속 발생할 것이며 억울한 피해자가 속출할 것이다. 금융보안의 문제는 고객의 편리함을 제공한다는 명분아래 필연적인 보안의 취약점이기에 피하기도 어렵다. 시작이 잘못된 것이다.

금융권에서의 보안 불감증의 문제보더도 더 중요한 것이 소프트웨어 산업의 멸망이다. 사회에 만연된 불감증으로 지금대로 가다가는 한국 소프트웨어 산업도 금융 문제와 같이 깊은 늪에 빠질 것이다. 필자가 그동안 여러 저서를 통해 얘기해 왔지만 8년 전의 금융 보안에 대한 경고와 같이 미래 10년 후의 한국 소프트웨어가 암울해 보이는 것은 사실이다. 근본적인 변화는 없이 얼굴화장이나 하는 정도의 소극적인 변화로는 현재 처한 한국 소프트웨어의 문제는 해결되지 않는다.

아인슈타인이 다음과 같이 말했다.
"같은 일을 반복해서 되풀이하면서 다른 기대를 소망하는 것은 미친 짓이다."
"Insanity: doing the same thing over and over again and expecting different results."

이제 탁상공론은 그만하고 기득권도 내려놓고 근원적인 개혁을 시작하지 않으면 한국 소프트웨어는 없다.

아래는 8년전 기사이다.

안철수 연구소 “대한민국은 사이버전쟁 전야…중국해커에 노출 무방비” [기사원본가기]
기사입력 2006-03-20 21:28 | 최종수정 2006-03-20 21:28 0




[쿠키인터넷] “대한민국은 사이버전쟁 전야같다.”

안철수연구소의 김익환 최고기술책임자(CTO) 겸 부사장은 20일 서울 세종로 프레스센터에서 열린 ‘안철수연구소 창립 11주년 기념’ 기자간담회에서 “보안불감증이 심각하다”며 이같이 말했다.

김 부사장은 “기업이나 은행,기관 모두 마음만 먹으면 공격할 수 있고 막을 방법은 없다”며 “나 역시도 지금 당장 해킹할 수 있을 만큼 보안이 취약하다”고 덧붙였다.

그는 중국 해커들이 가장 두려운 대상이라고 언급한 뒤 “한국은 아직까지 폐쇄적인 구조라 금전적 이득을 얻기 힘들기 때문에 공격을 감행하지 않고 있는 것 같다”고 설명했다. 인터넷뱅킹을 예로 들면 미국은 외화의 송금 및 반입이 자유로운 오픈타입인 반면 한국은 외화 거래가 자유롭지 않은 폐쇄타입이라는 것.

공개키기반구조(PKI)와 관련해서도 의문을 제시했다. 일각에서 PKI는 공격할 수 없는 최상의 장치라고 얘길 하지만 실제로는 ‘뚫린다’는 게 김부사장의 얘기다. 그는 “PKI는 숫자 두개를 곱해서 나온 조합으로 얼마든지 해킹할 수 있다”며 “다만 시간이 오래 걸려 못 뚫는다는 얘기가 나오는 것”이라고 덧붙였다.

그는 또 “10년전만 해도 재미로 해킹하던 ‘매시브 어택(massive attack)’이 주를 이룬 반면 현재는 금전적 이득을 얻기 위한 피싱 등 무작위 공격이 기승을 부리고 있다”며 “미래에는 특정대상을 겨냥한 전세계 어떤 업체도 못 막는 공격이 자행될 것”이라고 경고했다.

2004년 3월 안철수 연구소에 영입된 김 부사장은 서울대 공대를 나와 미국 산호세주립 대학에서 전산학을 공부한뒤 실리콘밸리의 모체인 스탠포드 대학에서 컴퓨터공학 석사 학위를 받았다. 그는 GE를 거쳐 선마이크로시스템즈에서 현재 구글의 최고경영자인 에릭 슈미트와 함께 근무하는 등 쟁쟁한 IT전문가들과 함께 실무 경력을 쌓았으며 1995년부터 9년간 실리콘밸리에 소프트웨어 회사인 스탠포드 소프트웨어사를 설립해 운영했다. 저서로는 ‘대한민국에는 소프트웨어가 없다’가 있다.

국민일보 쿠키뉴스 이경선 기자 bokyung@kmib.co.kr

SW 개발자 대우 - 10년 전과 달라졌나?

아래 글 "SW 개발자가 우대받는 사회를 만들자"는 필자가 10년 전인 2004년에 정부의 요청으로 기고한 기사였다. 필자가 "대한민국에는 소프트웨어가 없다"라는 책을 출판 한 때가 2003년 이었으니까 그 다음 해이다. 그 때도 SW 개발자를 우대하자는 취지였는데 10년 동안 전혀 변한 것이 없다는 것을 증명한다. 지금도 필자가 비슷한 기사를 쓰는 것을 보면 10년 전과 복사판이다. 전체적인 분위기는 더 악화된 것 같은 생각도 든다. 그만큼 정부, 학계, 기업이 전혀 변하지 않았다. 10년 동안 우리는 무엇을 했는가? 그럼 앞으로 10년이 더 지난다고 변할 수 있는가? 공자님이 2천년 전에 하신 말씀도 아직까지도 따라하지 못하는데 과연 무엇을 바랄 수 있을까 하는 생각도 든다. 지금도 수 많은 탁상공론들이 난무한다. 10년 동안 변하지 않았다는 것을 명심하고 공멸하지 않기 위해서는 모두 기득권을 내려놓고 진심으로 변화하기를 바란다.

SW 개발자가 우대받는 사회를 만들자

한국의 소프트웨어 산업이 발전하기 위해서는 여러 가지 요소가 필요하다. 현실감 있는 정부의 정책도 있어야 하고, 회사도 적합한 환경을 제공해야 되고 소프트웨어 개발자들의 열정도 있어야 한다. 그 중에 개발자들의 열정은 회사나 정부정책에 많은 영향을 받을 수 밖에 없다. 현재는 여러 가지 이유로 소프트웨어에 종사하는 개발자들이 좋은 대우를 받지 못한다. 개발자들이 좋은 대우를 받지 못하니 그 길을 선호할 리 없다. IT 거품이 일어났을 때 몇 년간을 제외하고는 모두가 기피하고 희망이 없는 직종이 되어 버렸다. IT 거품이 꺼지면서 시장수요가 줄었다고는 하나 근본 원인은 다른 곳에 있다.

필자가 소프트웨어분야에 오랫동안 기술자로 근무하면서 새로운 기술을 습득하기 위한 방법중의 하나가 컨퍼런스나 세미나에 가는 것이다. 지금부터 수년 전 미국에서 돌아온 지 얼마 되지 않았을 때였다. 어느 소프트웨어 신기술 세미나에 참석한 적이 있는데 20대나 30대로 보이는 젊은 층밖에 없는 것이었다. 나와 같은 연령대의 사람은 한명도 없었다. 왜 40대, 50대의 기술자는 없는 것인가 생각해 보았다. 미국과 같은 분위기를 생각하고 갔다가 앉아 있기가 민망해서 중간에 나와 버렸다. 그러면서 생각해 보니 미국에서는 빌 게이츠 같은 최고 경영자들이 제품데모도 하고 프리젠테이션도 직접 하는데 한국에서는 최고경영자가 직접 프리젠테이션 하는 경우를 본적이 없다. 그럴 수 있는 능력도 없을 것이다. 높은 직위에 있는 사람들은 보고 받고 결정만 하지 실제 경험은 하지 않기 때문이다.

사회에 잘못된 통념이 있다. 어느 회사나 왜 승진하려면 꼭 관리가 되어야 하는 것일까. 나이 들면 젊은 사람들과 신기술에서 경쟁하기 어렵다고 한다. 나는 동의하지 않는다. 이유는 다른 곳에 있다. 기술습득에 시간을 소비하지 않고 관리업무에 시간을 소비하기 때문이다. 관리업무도 하고 기술습득도 하려면 뒤떨어 질 수 밖에 없다. 실제 소프트웨어 회사의 현황을 살펴보자. 회사의 종류를 살펴보면 단발성의 프로젝트를 주로 하는 SI 업체를 제외하면 정말 경쟁력 있는 패키지 소프트웨어를 만드는 기업은 몇 손가락에 꼽힌다. SI 업체는 수 많은 단발성의 프로젝트를 하므로 관리쪽이 더 중요하다. 기술자는 찬밥신세가 되기 쉽다. SI 업체가 아니고 패키지를 개발하는 소프트웨어회사에서도 소프트웨어 엔지니어로 시작해서 능력 있는 사람들은 대부분이 서서히 관리직으로 넘어가게 된다. 관리직으로 넘어가지 못하면 도태되어 회사를 그만 두는 수 밖에 없다. 사농공상의 전통문화와 굴뚝산업에 익숙한 경영진들의 경영방식 때문에 소프트웨어산업은 악순환을 거듭할 수 밖에 없다. 전문가의 가치를 모르니 전문가가 생겨나기 어렵고 전문가가 없으니 좋은 제품을 만들 수가 없고 그러니 경쟁력이 떨어져 장기적으로 성공하기 어렵게 된다.

미국의 소프트웨어회사를 방문하게 되면 주시해 볼 것이 있다. 주요 기술직에 있는 사람을 만나게 될 때 잘 주시해 보면 대개 나이가 많은 사람들임을 알게 될 것이다. 40대에서 50대 60대 까지도 있다. 그런 사람들의 명함에는 보통 “Fellow Engineer”, “Chief Engineer”, “Chief Scientist” 라고 쓰여 있다. 이러한 사람들이 회사에서 하는 역할은 기술적 업무와 중요한 결정을 담당하게 되는데 관리쪽 일은 전혀 안 하는 경우가 대부분이다. 관리쪽 일을 하게 되면 이미 기술자로서의 능력을 조금씩 상실하게 된다. 회의에서 만나더라도 이런 사람들의 결정이 가장 중요하다는 것을 명심해야 한다. 새 제품을 기안하는 사람은 마케팅부서 같은 기획조직에서 시작할 지 모르나 그 기안을 승인하는 것은 기술적인 면에서는 이런 최고 기술자가 한다. 기술적으로 승인이 안 나면 프로젝트는 취소될 수 밖에 없다. 기술적으로 안 된다는데 무대포로 밀어 붙일 수는 없다. 이런 기술자는 회사의 운명을 좌우할 수 있는 직위이다. 비슷한 명칭으로는 기술이사나 아키텍트라고도 할 수 있다.

요새 한국에서 아키텍트라는 말을 많이 사용한다. 사람마다 의미를 조금씩 다르게 사용한다. 한가지 경우를 살펴보자. 소프트웨어분야에는 많은 요소기술이 있다 J2EE, 닷넷, CBD 등등 많다. 이러한 요소기술 전문가라는 뜻으로 아키텍트라는 명칭을 붙인다. 요소기술 아키텍트는 양성되기가 상대적으로 쉽다. 경험보다는 지식적인 부분이 더 많기 때문에 교육으로 쉽게 양성될 수 있다. 이러한 요소기술 아키텍트보다는 전체 개발 프로세스를 이해하고 어떠한 제품도 처음부터 끝까지 개발할 수 있는 체계와 정책을 수립할 수 있는 경험과 지식을 균형되게 소유한 확장형 아키텍트가 바로 최고의 기술자이며 또 필요한 것이 한국 소프트웨어의 현실이다. 이론적인 요소기술 지식으로서는 세계 어느 나라에도 뒤지지 않는다. 소프트웨어 엔지니어들을 보면 열심히 공부하는 사람들이 많다. 소프트웨어 엔지니어링, UML 방법론 등 책에서 다 익힐 수 있다. 하지만 오케스트라의 지휘자같이 전체적인 측면에서 바라볼 수 있는 경험과 지식을 두루 갖춘 안목있는 확장형 아키텍트가 필요한 것이다.

소프트웨어기술자들이 언론매체에서 앤티 IT라는 말을 만들어 절망적인 상황을 표현했듯이 지금과 같은 기업문화에서는 소프트웨어 엔지니어들의 희망도 없고 아키텍트나 Chief Engineer와 같은 국가발전의 원동력이 될 기술자도 양성되기 어렵다. 모두 관리자의 길로 빠질 수 밖에 없고 전문지식 없이 기술적인 판단을 할 수 밖에 없다. 그렇게 해서는 올바른 결정이 나올 수도 없고 기술적으로 경쟁력 있는 제품이 생산될 리 만무하다. SI 업체와 같이 수주를 받아서 개발해 주는 회사는 되도록이면 저렴한 임금의 초급엔지니어들을 사용해서 이윤을 남기는 것이 최대의 목적이니까 하청업체에다가 헐 값에 넘기게 되고 하청업체는 당연히 값싼 엔지니어를 고용할 수 밖에 없는 것이 소프트업계에 종사하면 누구나 다 아는 현실이다. 이러한 환경에서 회사에서 최고의 연봉과 지위를 보장 받는 아키텍트들을 고용한다는 것은 어려울 수 밖에 없다.

이러한 소프트웨어 문화 때문에 아키텍트라고 불리는 전문기술자 숫자가 절대적으로 부족하다. 이제부터라도 아키텍트를 양성하는 것도 중요하고 그러한 아키텍트들이 살아남을 수 있는 기업의 문화가 중요함은 두말할 나위도 없다. 소프트웨어 기술자들이 기술직에 전념할 수 있는 환경을 기업이 제공해 줄 수 있다면 소프트웨어발전의 기초는 세워진 것이다. 동시에 정부의 정책도 이런 기술자들을 정부관리에 등용할 수 있는 기회를 만들면 현실에 맞는 정책이 수립되지 않을까 생각된다. 소프트웨어가 발전하기 위해서는 천재 경영자가 필요한 것이 아니고 소프트웨어 기술자가 우대 받고 존경 받는 문화가 가장 중요하다. 그러면 좋은 소프트웨어는 저절로 나온다.

SWEBOK - SW 프로세스 #1 소개

SWEBOK SW Process #1 - 2014-11-02

8장 Software Engineering Process (소프트웨어 공학 프로세스)

(*** 필자주석) 1장의 "Requirements"를 끝내고 2장 설계를 설명하는 것이 순서이긴 하지만 국내 소프트웨어 산업에서 가장 많이 유행했던 용어가 "프로세스" 이었기 때문에 순서를 바꾸어 이 Chapter를 먼저 설명하기로 한다. 프로세스는 효용성 면에서 가장 논쟁적인 이슈이기도 하다. 프로세스라는 일반 용어는 수천 년간 사용되어 왔다. 어떤 일을 체계적인 단계를 정해서 각 단계에 시작 상태가 있고, 정해진 행위를 하고, 산출물이 나오는 것을 표준화하는 것이다. 요리를 해도 프로세스가 있고 골프를 치러가도 프로세스가 있다. 하지만 천재 물리학자인 스티븐 호킹이 말하기를 "인간에게 표준은 없다." 라고 했다. 과학에서도 똑같은 시험결과가 나오지 않는 것과 같이 인간 사회에서의 행동 패턴을 어떤 하나의 표준 프로세스로 정의할 수는 없다는 것이다. 인생에도 생로병사의 표준 프로세스가 있다고 생각하면 있는 것이지만 모든 사람의 인생이 다르기 때문에 표준이 없다 라고 말할 수도 있다. 프로세스라는 용어 자체가 극도로 추상적인 단어이기 때문에 증명도 어렵고 반증도 어려운 세계이다. 이런 추상화된 세계의 특성에 따라 자연히 사기꾼들이 성행하게 되니 매우 조심할 일이다.

프로세스에 관한 한 국내 소프트웨어 업계에서는 미국의 CMMI나 유럽의 SPICE와 같은 인증위주로 진행되어 왔다. 사실 이런 인증들은 돈만 들이고 문서만 적당히 만들어 내면 누구나 인증을 받을 수 있다는 것은 업계의 관계자들이라면 모두 알고 있다. 현실을 반영하기 보다는 조작에 가까운 문서를 작성해서 인증을 받는 경우도 비일비재하다. 그렇게 인증을 받았다고 자랑스럽게 언론기사에 광고할 수도 있지만 그런 인증들은 ISO와 같은 국제 표준도 아니고 사실은 인증도 아닌 등급일 뿐이다. 아래 문장을 읽어보면 그 실체를 조금 더 객관적으로 이해할 수 있다.
 

Organizations can be “Rated” at a Capability or Maturity Level based on over 300 discreet “Specific” and “Generic” Practices. Intended to be broadly interpreted, the CMMI is not a “Standard” (ala ISO), so achieving a “Level” of CMMI is not a certification, but a “rating.”

 

CMMI의 경우 SEI가 자기들이 정한 어떤 기준에 맞으면 그 수준을 인정하는 것이고 그런 인증을 요구하는 소수의 업체들과 비지니스를 하려면 필요하긴 한다. 하지만 인증이 실력으로 가치가 있는지 아닌지를 판단하기 위해서는 자기 이력서에 인증 경험을 적어서 취업에 도움이 된다면 가치가 있다고 보면 된다. 국내 이력서에서 프로세스 경험을 적은 것을 심심치 않게 보았다. 국방이나 자동차산업과 같은 특수한 분야에서는 도움이 될 수 있다. 하지만 실리콘밸리에서는 취업에 도움이 되기 보다는 그게 뭔지를 설명하느라 시간만 낭비할 것이다. 실리콘밸리의 회사에서 면접 시에 프로세스에 대한 질문은 하지 않는다.

프로세스의 진정한 가치는 체크리스트와 같은 형식이 아닌 산출물의 내용에 있고, 그 내용의 충실성을 지속할 수 있는 현실적인 프로세스에 있다. 국내에서는 이벤트용으로 인증 받았으니 언론에 자랑스럽게 내는 것은 이해하지만 그 속을 들여다 보면 대부분 실속은 없고 결론적으로 보면 언론에 기사 내는 것이 가장 큰 혜택 중의 하나이다. 이런 관행이 국내 SW 업계 경영자들의 맹목적인 경영방침을 반영하기도 한다. 이런 점이 기업평가 사이트인 glassdoor.com에서 보듯이 국내 기업의 경영진들이 외국인 엔지니어들에게 전문성이 없다는 평가를 받는 이유이다. 인증을 받고 외국 파트너와 얘기를 시작할 수는 있지만 결국은 품질을 확보할 수 있는 현실적인 프로세스여야 가치가 있다. 실리콘밸리에 가서 SW 엔지니어들에게 CMMI나 SPICE를 아는지 물어보면 대부분 용어도 들어본 적도 없다는 것에 놀랄 것이다. 더욱 놀라운 것은 실리콘밸리의 벤처회사도 국내에서 CMMI의 최고 등급을 받은 회사보다 훨씬 더 현실적으로 좋은 프로세스를 가지고 있고 개발도 더 잘한다는 것이다.

국내에서 생각하는 프로세스와 실리콘밸리에서 경험하는 프로세스는 겉모습과 용어는 같을 지 모르지만 속을 들여다 보면 완전히 다르다. 같은 용어라도 모든 회사에게 다 다르게 적용된다. 옳은 것도 아니고 틀린 것도 아니고 적용을 잘해야 하는 것이 프로세스의 어려운 점이다. 손자병법을 읽는 것은 쉬우나 현실에 적용하는 것은 완전히 다르다. 많은 사람들이 손자병법을 읽었지만 손무가 되기는 어렵다. 즉 손자병법을 읽었다는 인증은 받을 수 있지만 소프트웨어 개발이라는 전쟁은 수행하기 쉽지 않다. 아무튼 국내는 소프트웨어 프로세스가 극단적으로 형식적인 면에 치우쳐 적용되고 있는 갈라파고스 섬이다. 대부분의 회사는 프로세스 정립에 돈과 시간을 낭비할 확률이 높지만 시행착오를 하면서 배운다고 위안을 해보자. 단 국내 소프트웨어 산업이 돈과 시간 낭비하다가 외국 경쟁사에 뒤떨어지지 않을 정도만 시행착오를 해 보는 것이 좋겠다.

소개 - SW 공학 프로세스

공학 프로세스는 Resource를 투자해 어떤 Input을 Output으로 변환시키기 위한 일련의 행위를 의미한다. 전기, 기계, 토목, 화학과 같은 전통적인 공학에서는 에너지와 물리적인 형태를 다른 형태로 변환시키는 것이다. 소프트웨어 공학에서는 소프트웨어 엔지니어가 요구사항분석, 설계, 구현, 테스트, 형상관리와 같이 소프트웨어를 개발하고 유지보수하는 일련의 행위와 관련되어 있다. 여기서는 가독성을 위해 "소프트웨어 공학 프로세스"를 그냥 "소프트웨어 프로세스"라고 부르기로 한다.

소프트웨어 공학 프로세스는 다음과 같은 여러 목적을 위해 이용된다.
* 사람들간의 이해, 소통, 협업을 돕고,
* 소프트웨어 프로젝트의 관리를 돕고,
* 소프트웨어 품질을 측정하고 향상시키고
* 프로세스 자체의 개선을 돕고
* 프로세스 실행을 자동화하기 위한 기반으로 이용된다.

소프트웨어 공학 프로세스 지식영역은 다음과 같이 나누어 진다.

1. 소프트웨어 프로세스 정의 (Definition)
1.1 소프트웨어 프로세스 관리 (Management)
1.2 소프트웨어 프로세스 구조 (Infrastructure)

2. 소프트웨어 생명주기 (SW Life Cycles)
2.1 소프트웨어 프로세스의 분류 (Categories)
2.2 소프트웨어 생명주기 모델 (Life Cycle Models)
2.3 소프트웨어 프로세스 적용 (Adaptation)
2.4 현실적인 고려 (Practical Considerations)

3. 소프트웨어 프로세스 평가와 개선( SW Process Assessment and Improvement)
3.1 소프트웨어 프로세스 평가 모델 (Assessment Models)
3.2 소프트웨어 프로세스 평가 방법 (Assessment Method)
3.3 소프트웨어 프로세스 개선 모델 (Improvement Models)
3.4 연속적, 단계적 소프트웨어 프로세스 등급 (Continuous and Staged SW Process Ratings)

4. 소프트웨어 측정 (SW Measurement)
4.1 소프트웨어 프로세스와 제품 측정 (Process and Product Measurement)
4.2 평가결과의 품질 (Quality of Measurement Results)
4.3 소프트웨어 정보 모델 (SW Information Models)
4.4 소프트웨어 프로세스 측정 기술 (Measurement Techniques)

5 소프트웨어 공학 프로세스 도구들 (SW Engineering Process Tools)

위의 5개의 Topic을 다음 Post 부터 하나씩 설명하기로 한다.