http://www.hani.co.kr/section-010100001/2004/03/010100001200403231910292.html

















■주민등록번호 수집금지 추진배경
공인인증서로 본인확인 가능
번호유출꺼려 도용 악순환
외국선 주민번호 요구 안해


우리나라에서는 인터넷 사이트 회원으로 가입하려면 반드시 주민등록번호를 입력해야 한다. 거부하면 회원으로 받아주지 않는다. 한국정보보호진흥원이 지난해 7월 448개 사이트를 조사했더니, 447곳이 주민등록번호를 입력하지 않으면 회원 가입을 할 수 없는 것으로 나타났다. 최근 확인해 보니, 나머지 한 곳도 같은 방식으로 바꿨다.



인터넷 사이트 운영자들은 회원들의 주민등록번호를 수집하는 이유를 “본인 확인을 위해서”라고 설명하지만 정작 “인터넷을 이용하는 데 왜 본인 확인이 필요하냐”고 물으면 제대로 된 답변을 내놓지 못한다.


하지만 네티즌들은 주민등록번호를 제공하는 것을 꺼림칙하게 생각하고 있다. 유출되거나 엉뚱한 목적으로 이용될 수 있다고 걱정한다. 정보보호진흥원이 지난해 10월 네티즌 500명을 대상으로 설문조사를 했더니, 응답자의 91.8%가 제공하기 꺼려지는 개인정보로 주민등록번호를 꼽았다.


정현수 정보보호진흥원 개인정보침해신고센터 팀장은 “인터넷 사이트는 요구하고, 내 것을 제공하기에는 꺼림칙해하는 상황이 주민등록번호 도용 문제를 일으키고 있다”고 지적했다. 정보보호진흥원 설문조사에서도 12%가 타인 주민등록번호를 도용하고 있다고 응답했다.


■ 주민등록번호 도용을 막는 조처=인터넷 사이트의 회원 주민등록번호 수집을 금지시키기로 한 정보통신부 방침은 주민등록번호 도용을 막기 위한 것이다.


김남철 정통부 정보이용보호기획담당 사무관은 “주민등록번호는 행정 편의를 위한 것이지, 인터넷 업체들의 회원 관리용이 아니다”라며 “도용을 막는 수단으로, 주민등록번호를 입력하지 않아도 회원 등록을 할 수 있게 하는 방안을 마련하고 있다”고 말했다.


실제로 정보보호진흥원이 지난해 2~10월 개인정보침해신고센터에 신고된 개인정보 침해 사례를 분석한 결과를 보면, 56.4%에 이르는 4400건이 주민등록번호 도용과 관련된 것으로 나타났다. 정보보호진흥원은 “인터넷 사이트마다 회원 등록 때 주민등록번호를 요구하는 게 번호 도용을 부추기고 있다”고 풀이했다.



정보보호진흥원이 지난해 10월 네티즌 500명을 대상으로 실시한 설문조사를 보면, 네티즌들은 인터넷 사이트나 서비스 회원으로 가입하기 위해 남의 주민등록번호를 도용할 때, 친구나 가족 것을 우선 생각하는 것으로 나타났다.


비경험자 중에는 72.7%가 필요하다면 가족 것을 도용하겠다고 밝혔다. 61.8%는 주민등록번호 생성기를 통해 만들어서, 56.8%는 본의 아니게 알게 된 타인 것, 54.8%는 친구 것, 26.8%는 직장 동료 것을 이용하겠다고 응답했다.


네티즌들이 흔히 경험하는 주민등록번호 도용 사례로는, 인터넷 사이트에 회원 등록 신청을 했을 때, 이미 등록돼 있다는 메시지가 나오는 경우다. 누군가가 주민등록번호를 도용해 회원 등록을 한 것으로 볼 수 있다.


정통부는 인터넷 사이트 운영자들에게 회원들의 주민등록번호를 수집하지 못하게 하는 대신, 회원의 본인 확인이 필요하면 공인인증서를 이용하도록 권할 방침이다. 또 성인 인증이나 연령에 맞는 마케팅을 위해 필요한 경우에는, 생년월일을 받아 이용하도록 권하기로 했다.


김 사무관은 “게임업체 넷마블이 정부의 권고를 받아들여 미성년자 회원을 등록할 때는 주민등록번호 대신 생년월일을 입력하게 하고 있는데, 서비스 제공에 아무런 문제가 없다”고 말했다.


■ 외국에서는?=우리나라의 주민등록번호처럼 국민에게 식별번호를 부여하는 나라는 많다. 하지만 한번 받은 번호는 평생 바꿀 수 없게 하면서 인터넷 사이트 회원 등록 때 입력하게 하는 곳은 우리나라밖에 없다.



미국은 국민들에게 사회보장번호를 부여한다. 하지만 사회보장번호 공개는 법으로 금지돼 있다. 따라서 인터넷 사이트에서도 이를 요구하지 않는다. 사회보장번호를 제공하지 않는다고 인터넷 사이트 회원 등록이나 서비스 제공을 거부하지도 않는다.


일본도 주민기본대장카드가 있지만, 이곳에 입력되는 주민표 코드의 민간 이용은 금지된다. 또 주민표 코드는 해당 주민의 신청에 따라 언제든지 변경할 수 있다.


정현수 팀장은 “주민등록번호는 인터넷에 흩어져 있는 개인정보를 통합시키는 열쇠말 구실을 한다”며 “주민등록번호를 이용한 사생활 침해를 막기 위해서는 지금이라도 인터넷 사이트의 회원 주민등록번호 수집을 금지시켜야 한다”고 지적했다.


김재섭 정보통신전문기자 jskim@hani.co.kr





[유춘희의 IT 눈대목] 죽으라고 일만 하시는 분들에게 드림











유춘희 (Golf for Women 편집장)

2004/02/27











align="left" valign="top" border="0" hspace="4">정보기술(IT) 기자 생활을 하면서 알고 지냈던 사람 중 한 분과 엊그제 만났다. 대기업 SI 업체 출신인 그는 우리나라 네트워크 산업의 산증인이라고 불러도 좋을 만큼 인정받던 사람이다. 기술자로서 네트워크에는 척척박사였다. 그런데, 다니던 외국계 회사에서 자의반 타의반 나왔다고 했다. 막상 나오고 보니 어찌해야 할지 몰랐단다. 닿고 닿아 필자와 연락이 된 것이다. 필자 역시 그와 최근에 만난 게 3년은 족히 넘었지 싶다.



그는 “내가 헛살았다”고 말했다. 자신의 현재 처지를 얘기하고 도움을 청할 사람이 정말 없더라는 것이다. 오죽했으면 지금은 골프 잡지를 만들고 있는 나에게까지 연락을 하였을까. 술만 입에 댔다 하면 얼굴이 빨개지는 통에 술친구도 없다. 영업사원이 아니어서 밖의 사람들과 어울릴 기회가 없었다. 오로지 일밖에 몰랐다. 어렴풋한 기억이, 언젠가 축구 한일전을 보기 위해 저녁식사 겸 음식점으로 향할 때 그는 관심도 없다는 듯 회사를 지켰다.



회사와 집밖에는 몰랐다니…



그렇게까지는 생각을 못했는데 그는 회사와 집밖에는 몰랐다고 했다. 학교 다닐 때도 집과 학교밖에 몰랐다는 것이다. 대학교 들어와서 처음으로 영화 구경을 했다고 하니 누가 믿겠는가. 남들이 출근하기 전에 이미 회사에 나오고 별 특별한 일이 없으면 회사에서 일을 더 하고 집으로 갔다. 정말 회사와 집밖에 몰랐다! 이쯤 되면 그의 성격에, 아니 취향에 좀 문제가 있다고 해야 할지도 모르겠다.



어찌 됐든, 지금까지 그를 지탱한 것은 바로 일에 대한 집착과 열정이었다. 그런 열정이 그를 전문가로 만들었을 것이다. 그나마 몇 안되는 친구도 만나지 않을 만큼 일에 몰두하는 그의 취향이 성공의 원동력이었다. 기술적으로 부족한 기자들에게 언제라도 정열적으로 조언을 해주고, 원고가 ‘빵꾸’나면 마감 몇 시간 전이라도 훌륭하게 메워주는 역할도 종종 해주었다.



나와 얘기 도중 그는 손을 몹시 떨고 있었다. 손이 떨리고 온몸에 피곤이 몰려오고 기운이 떨어지는 증상, 갑상선 질환을 앓고 있다고 했다. 심할 때는 떨리는 손이 잔을 건드려 탁자 밑으로 떨어뜨린 적도 있고, 물을 마실 때 컵 안의 물이 출렁거릴 때도 있단다. 누가 볼까 봐, 자신이 약해 보이는 게 싫어서 회사 동료들과 멀리 떨어진 곳에서 차를 마시곤 했다는 얘기를 듣고 마음이 아팠다. 그가 회사를 그만둔 이유 중에는 그런 것도 있었다.



나 자신이 그 사람과 같은 라이프스타일과 대인 관계로 살지 않아서인지, 나보다 연장자인데도 불구하고 그에게 오히려 나의 살아온 내용을 조언해주듯이 말했다. 언제나 멀게 느껴졌던 다른 사람들과 지금이라도 저녁도 함께 먹으며 우애를 쌓으라고 권했다. 그리고 걱정하지 말라고 했다. 성공을 위해 달려온 만큼 당신은 성공을 이뤘고, 지금 상황에 실망할 게 아니라 평정을 찾고 있는 과정이라고 생각하라고 했다. 그러나…



회사에 충성을 다한 결과가 결국…



“정말 지쳤어. 이젠 어디 취업하겠다는 생각조차 안해. 돈은 쓸 만큼 번 것 같고…” 그리고 “지금이라도, 이제까지 만나지 못한 사람들 하나씩 만나고, 골프도 배워야겠다”고 덧붙였다. 그러고는 좋은 골프클럽 좀 추천해주고 골프에 관해서 도움 좀 달라고 지나가는 듯이 말했다. 이제야 그는 주위를 둘러보며 인생에 관심을 가져야 할 다른 것들이 많다는 사실을 깨달은 것처럼 보였다.



지금 그는 일을 떠나, 세상과 소통하는 방법을 배우려고 한다. 이제까지 외부로부터 자신을 차단시켜왔던 그가, 이제 어딘가에 열정적으로 집중하려고 한다. 그게 골프가 됐든, 친구들이 만든 술자리에 적극적으로 나가는 것이든, 자신이 자리를 만들어 아는 사람을 부르든 간에. 바깥 세상을 열었다 닫았다 하는 방법을 빨리 체득해서, 그의 인생이 가을에서 봄으로 바뀌었으면 하는 바람이다.



올림픽 유도 경기에서 금메달을 딴 선수가 이런 얘기를 한 적이 있다. “꼭 이겨야 되겠다는 생각보다 매트 위에서 경기를 즐기겠다는 생각으로 임했다”고. 참 어려운 얘기다. 내 가족의 생계를 위해 회사와 사장의 명령이기에 어쩔 수 없이 하는 일은 당장 나에게 도움이 되지 않는다. 가족과 친구들까지 돌보지 못하면서 일에 빠지지는 말자.



만약 지디넷 독자들 중에 회사에 충성을 다한 결과가 이 사람처럼 나타났다면 어떻게 할 텐가. 돈을 벌었다는 것 빼고. 아니 돈을 벌었다고 쳐도. 직접적인 원인이었는지는 몰라도 그는 병까지 얻었다. “당신이 이제까지 회사에서 달성한 여러 가지 것들을 자랑스러워해야 하시라”는 것뿐 누가 그걸 알아줄까. 그의 육체적 노동과 정신력 노력들, 덧붙여 그의 독특한 인간 관계는 그에게서 너무 많은 것을 앗아갔다.



도대체 우리 직장인들이 일을 ‘즐기면서’ 할 수 있는 날은 언제나 올까. 진정한 삶의 의미를 찾으려면 일과 사회 생활을 적절하게 병행할 줄 알아야 하는 것 같다. @
ZDNet : 마이크로스프트웨어 에서 읽은 내용임.














S/W 개발 방법론의 반항아「익스트림 프로그래밍」














전통적인 소프트웨어 개발 방법론과는 달리 문서를 강조하지 않고 변경을 장려하며, 개발 초기부터 테스트를 병행할 것을 강력히 권고하는 새로운 방법론이 있습니다. 바로 '익스트림 프로그래밍(eXtreme Programming ; XP)'이라는 방법론으로, 우리나라에서는 대략 3년 전부터 관심을 끌기 시작했습니다.











김기주 (마이크로소프트웨어)

2004/02/16














컴퓨터가 발명되고 소프트웨어가 개발되기 시작한 이래로, 시간이 흐르면 흐를수록 소프트웨어는 점점 더 그 규모가 커지고 복잡해지기만 합니다. 초창기에는 컴퓨터 시스템 개발비용의 대부분이 하드웨어 개발비였으나, 요즘은 하드웨어 개발비용보다 소프트웨어 개발비용의 비율이 더 높다고 합니다. 소프트웨어 개발의 비중이 높아지면서 소프트웨어 개발 방법에 대해서 많은 사람들이 고민했고, 그 결과로 여러 가지 소프트웨어 개발 방법론이 제안됐습니다.



소프트웨어 개발의 각 단계를 나타내는 라이프사이클(lifecycle) 모델로 대표적인 폭포수 모델(waterfall model, <그림 1>)도 제안됐고, 요즘은 이를 개선한 나선형 모델(spiral model, <그림 2>)이 많은 지지를 받고 있기도 합니다. 폭포수 모델은 소프트웨어 개발의 각 단계를 구분했고, 각 단계에서 해야 하는 일을 명확히 했습니다. 하지만 개발 과정을 단순하게 나타내는 단점이 있고, 이전 단계에서 한 일에 대한 오류가 나중 단계에서 밝혀질 경우 이를 바로잡기 위한 작업을 나타내지 못하는 문제가 있습니다.



<그림 1> 폭포수 모델
<그림 2> 나선형 모델


이에 비해 나선형 모델은 전체 시스템이 갖춰야 할 특성을 단계별로 나누어, 각 단계별로 폭포수 모델에서 제시한 것과 비슷한 단계들을 밟아 조금씩 시스템의 완성도를 높여가는 방식의 소프트웨어 개발 과정을 그리고 있습니다. 나선을 따라 한 바퀴 돌 때마다 이전 단계에서 미흡했던 부분을 보완할 수 있고, 개발 일정을 모두 마쳤을 때에만 구현된 소프트웨어를 볼 수 있었던 폭포수 모델과는 달리, 각 바퀴를 돌 때마다 부분적으로 완성된 시스템을 볼 수 있다는 장점이 있습니다.



익스트림 프로그래밍

우리나라에서는 대략 3년 전부터 관심을 끌기 시작한 것으로 보이는데요, 이 방법론이 만들어진 것은 1990년대 중반이라고 합니다. 위원회에서 만들어진 알골(ALGOL)보다 개발자에 의해 만들어진 C 언어가 더 널리 쓰이게 된 것을 생각하면, 연구소 등에서 만들어진 기존의 다른 방법론보다 아마도 회사에서 경험적으로 만들어진 익스트림 프로그래밍(XP)이 개발자들에게 좀 더 가깝게 다가올 것 같기도 합니다. 지금부터 XP에 대해서 알아보겠습니다.



1996년 켄트 백(Kent Back)과 워드 커닝험(Ward Cunningham)은 함께 다임러 크라이슬러 프로젝트를 진행하면서 새로운 소프트웨어 개발 방법을 정리하게 되는데, 그것이 XP 방법론입니다. XP는 고객이 원하는 소프트웨어를 고객이 원하는 시기에 제공하는 것을 목표로 하며, 프로젝트 막바지에도 나올 수 있는 요구사항 변경에 더욱 잘 대처할 수 있도록 합니다.



소프트웨어 프로젝트를 개선하기 위해 켄트 백은 네 가지 요소가 중요하다고 했는데, 이것은 의사소통(communication), 단순성(simplicity), 피드백(feedback), 그리고 용기(courage)입니다. XP 개발자들은 고객 및 동료 개발자들과 의사소통을 잘 해야 하고, 개발하는 소프트웨어에 대해 개발 첫 날부터 유닛 테스트를 통해 피드백을 받습니다. 개발 중인 시스템을 최대한 빨리 고객한테 보여줌으로써 고객들이 원하는 변경 사항을 빨리 도출할 수 있으며, XP 개발자들은 이러한 기초 위에서 요구사항이 계속 바뀌더라도 용감하게 나아갈 수 있습니다.



<그림 3> 전통적인 변경 비용 곡선
<그림 4> 켄트 백의 변경 비용 곡선


지금까지 XP의 탄생과 중요시하는 요소(value)에 대해 알아보았습니다. 이제부터 XP의 대표적인 작업들을 따라가며 XP가 구체적으로 어떻게 이뤄지는지 알아보겠습니다.



<그림 5> 익스트림 프로그램 프로젝트


유저 스토리

XP를 이용해서 프로젝트를 시작한다면 먼저 유저 스토리(user story)를 모아야 합니다. 유저 스토리는 일종의 요구사항(requirement)입니다. 폭포수 모델이나 나선형 모델에서 ‘Requirements Process’나 ‘Software Requirements’ 단계를 거치는 것과 비슷합니다. 유저 스토리는 UML(Unified Modeling Language)의 유스 케이스(<그림 6>)와 같은 목적으로 만들어지지만 형식이 없고(informal) 고객에 의해 작성된다는 것이 다릅니다.



<그림 6> 유스 케이스 다이어그램


유저 스토리는 시스템이 고객을 위해 해야 하는 일들을 담고 있고, 유저 인터페이스 외의 요구사항도 포함할 수 있으며, 개발자의 말이 아니라 고객의 말로 쓰여야 합니다. 유저 스토리를 가지고 개발 일정(release plan)을 잡게 되고, 뒤에 설명할 승인 테스트(acceptance test)를 만드는 토대가 됩니다.



유저 스토리가 전통적인 소프트웨어 개발 방법론의 요구사항 명세(requirement specification)와 크게 다른 것은 유저 스토리에는 요구사항 명세처럼 세세한 것까지 적지 않는다는 것입니다. 유저 스토리에는 그것을 구현할 때 얼마나 걸릴 것인가를 예측할 수 있을 정도로만, 그것의 구현에 있어 주요한 어려움(risk)이 어떤 것이 있을지를 살펴 볼 수 있을 정도로만 적으면 됩니다.



구현하기 위해 필요한 세부사항은 해당 유저 스토리를 구현할 때 고객을 만나 다시 들으면 된다는 것이죠. ‘시간과 돈이 충분한 프로젝트는 없다’는 말이 있습니다. 주어진 고객의 요구사항을 모두 구현한다는 것이 거의 불가능하다면, 구현하지도 않을 요구사항을 자세히 명세하느라 시간을 낭비하느니 간략하게 적어서 전체 일의 크기만 가늠하고, 실제 구현할 것만 그때그때 자세히 알아보는 것도 좋은 생각인 것 같습니다.



스파이크 솔루션

유저 스토리가 만들어지면 그 가운데 어려워 보이는(risky) 문제에 대해 스파이크 솔루션(spike solution)을 만듭니다. 스파이크 솔루션은 기술적 또는 설계상의 어려운 문제를 해결하기 위한 것입니다. 스파이크 솔루션은 숨어 있을 수 있는 문제를 찾아내기 위한 아주 간단한 프로그램입니다.



처리해야 하는 문제 외의 다른 조건들은 모두 무시하고 프로그램을 만듭니다. 대부분의 스파이크 솔루션은 계속 두고 쓸 정도로 좋지는 않으므로 조만간 짜야 합니다. 스파이크 솔루션을 만드는 목적은 기술적인 문제를 줄이고 유저 스토리를 가지고 추정한 개발 일정에 대한 신뢰도를 높이는 것입니다.



주기 계획

각 주기가 시작될 때마다 주기 계획 회의(iteration planning meeting)를 합니다. 각 주기는 1~3주 정도입니다. 각 주기에 처리할 유저 스토리는 고객이 고릅니다. 고객에게 가장 가치있는 부분을 가장 먼저 만들기 위함입니다.



처리할 유저 스토리는 이를 구현하기 위한 프로그램 과제(programming task)로 나눠집니다. 유저 스토리를 고객의 말로 적는 데 비해 과제는 개발자의 말로 적습니다. 각 과제를 개발자에 할당하고 소요기간을 예측하게 되는데, 같은 일이라도 소요기간은 사람마다 다를 수 있기 때문에 예측은 반드시 담당 개발자가 합니다.



각각의 과제는 하루에서 사흘까지 걸리게 됩니다. 하루가 안 걸리는 과제는 몇 개를 묶어서 하나로 만들고, 사흘보다 더 걸리는 과제는 더 잘게 나눕니다. 각 주기에 할 일이 너무 적거나 너무 많으면 처리할 유저 스토리를 더하거나 뺍니다. 유저 스토리를 가지고 예측했던 소요시간은 과제를 가지고 예측한 것으로 보완합니다.



계획에 포함되어 있지 않는 기능을 추가하려고 하면 안됩니다. 계획되지 않은 기능을 추가하려다보면 계획된 개발 기간을 초과하게 됩니다. 추가하고 싶은 기능이 있으면 그에 대한 유저 스토리를 추가하고 다음 주기를 기약합니다.



<그림 7> Iteration


주기 개발

각 주기의 길이를 비슷하게 유지하는 것이 좋습니다. 각 주기의 길이가 일정하면 프로젝트 진행에 대한 측정과 계획이 쉽고 믿음직스럽게 됩니다. 프로그램 과제를 미리 스케쥴하면 안됩니다. 각각의 주기에 해야 할 일은 해당 주기가 시작될 때 주기 계획 회의를 통해 결정합니다. 고객의 요구사항은 계속 바뀌기 때문에 미리미리 계획해두지 않는 것이 좋습니다.



주기 데드라인을 엄수해야 합니다. 주기 중 진척상황을 확인해서 데드라인을 넘길 것 같으면 주기 계획 회의를 다시 소집해서 일부 과제를 빼야 합니다. 다른 과제를 구현 안 된 채로 남기더라도 고객이 고른 가장 중요한 과제에 집중합니다.



승인 테스트

주기가 시작되면 주기 계획 회의에서 골라진 유저 스토리를 가지고 승인 테스트를 만듭니다. 여기서도 고객이 참여해 구현될 코드를 검사할 시나리오를 만들게 됩니다. 승인 테스트는 블랙박스 테스트입니다. 고객은 승인 테스트가 올바르게 만들어졌는지를, 그리고 실패한 테스트의 중요도를 확인합니다. 승인 테스트는 또한 나중에 리그레션 테스트(regression test)로도 쓰입니다.



승인 테스트를 통과해야 유저 스토리에 대한 처리가 완료됩니다. 승인 테스트를 자동화해서 자주 테스트하는 것이 좋습니다. 승인 테스트를 통과한다는 것은 고객의 요구사항을 만족한다는 뜻입니다.



유닛 테스트

개발을 하다보면 종종 한 두 사람이 맡고 있는 부분이 늦어져서 전체 프로젝트를 지연시키는 수가 있습니다. 이 경우 다른 사람들이 도와줄 수 있다면 좋을 것입니다. XP에서는 집단 코드 소유(collective code ownership, <그림 8>)라고 하는데, 필요하면 누가 어떤 코드든지 고친다는 뜻입니다. 이렇게 하기 위해서는 유닛 테스트(unit test)가 필요합니다.



유닛 테스트는 XP의 초석(cornerstone) 가운데 하나입니다. 유닛 테스트는 자주 실행할 수 있도록 자동화돼야 하고(JUnit과 같은 유닛 테스트 프레임워크를 이용하기도 합니다), 모든 모듈을 테스트할 수 있도록 만들어져야 합니다. 그리고, 될 수 있으면 코드를 작성하기 전에 유닛 테스트를 작성하는 것이 좋습니다. 유닛 테스트는 코드와 함께 코드 저장소(code repository)에 저장됩니다.



프로젝트를 진행하게 되면 언제나 시간이 모자라기 때문에 유닛 테스트를 만드는 시간이 아깝게 느껴지기 쉽습니다. 하지만 자동화된 유닛 테스트는 문제점을 찾아내는 데 있어서 훨씬 더 많은 시간을 절약해 주는 것으로 알려져 있습니다.



<그림 8> 집단 코드 소유


찻길 한복판으로 걸어가면 사고가 난다

얼마 전까지만 해도 XP는 문서작업을 강조하지 않고, 컴퓨터 한 대를 놓고 두 사람이 짝 프로그래밍(pair programming)을 하며, 리팩토링(refactoring)이란 방법으로 끊임없이 코드를 고치는 개발 방법론으로 알고 있었습니다. 물론 이런 것들도 XP의 요소이기는 하지만 이것보다는 앞에서 얘기한 전반적인 절차가 XP를 더 잘 설명하는 것 같습니다.



XP는 애자일 방법론(agile methodology) 가운데 하나입니다. 애자일 방법론은 고객에게 고객이 원하는 소프트웨어를 빨리 전달하는 것을 목표로 합니다. 1~3주 내에 구현할 수 있는 수많은 요구사항(유저 스토리) 가운데 고객이 가장 중요하게 생각하는 것을 먼저 구현합니다. 시간이 모자라면 유저 스토리 가운데도 고객이 가장 중요시하는 과제를 먼저 구현합니다.



프로젝트가 예측한 시일 안에 끝날 수 있도록 1~3주마다 진행상황을 점검하고 다음 1~3주 동안 할 일을 계획합니다(주기 계획 회의). 유닛 테스트를 통해 구현된 코드가 유저 스토리를 만족한다는 것을 확실히 합니다. 유닛 테스트를 이용함으로써 틈틈이 리팩토링을 통해 코드의 질도 높일 수 있습니다.



짝 프로그래밍은 개발자 사이에 의사소통을 원활히 하는 한 방법이고, 코드와 동떨어지게 되거나 그렇지 않아도 읽어 볼 사람이 없는 문서라면 만들지 않습니다. 심지어 요구사항 분석이나 구현 일정도 당장 구현할 내용이 아니라면 자세히 만들지 않습니다. 요구사항은 종종 바뀌고 미리 만든 계획은 쓸모없어지기 때문입니다.



하지만 XP를 도입하고자 할 경우 주의해야 할 것들이 있습니다. 사람이란 원래 편하고 쉬운 것을 택하고 불편하고 어려운 것은 버리고자 하는 경향이 있기 때문에, 문서를 만들지 않는다든지, 미리미리 계획하지 않는다든지, 세세하게 설계하지 않는다든지 하는 것은 받아들이기 쉽지만, 코드를 작성하기 전에 유닛 테스트를 만든다든지 틈틈이 리팩토링을 한다든지, 고객과 자주 만나 주기 계획 회의를 한다든지 구현이나 승인 테스트를 위한 세부 스펙을 정한다든지 하는 것은 등한시하기 쉽습니다.



예전에 어떤 무술 영화에 이런 말이 나옵니다. “길 이쪽 편으로 다니면 안전하고, 길 저쪽 편으로 다녀도 안전하다. 하지만 찻길 한복판으로 걸어가면 사고가 난다.” 기존의 방법론을 제대로 사용해도 효율은 떨어질지 모르지만 안전하게 프로젝트를 수행할 수 있고, 새로운 방법론을 제대로 익혀 사용해도 프로젝트를 안전하게 수행할 수 있습니다. 하지만 새로운 방법론을 어설프게 따라하다가는 프로젝트를 위험에 빠뜨리게 됩니다.



시간이 모자랄 때 구현하지 않게 될 지도 모를 부분을 미리 자세히 설계해 둘 필요가 없다는 말이지 스펙이 닥치는 대로 일단 코딩부터 하고 보면 된다는 것은 아닙니다. 읽지 않을 문서를 만드느라 시간과 노력을 낭비하지 않는 대신 소스 코드에 충실한 코멘트를 달아야 합니다. 함께 일하는 사람이 꼭 읽어야 할 문서가 있다면 반드시 만들고 언제나 소스 코드와 일치하는 정보를 지니도록 갱신해야 할 것입니다. 참고자료를 보면 XP를 도입하고자 하는 사람들이 주의해야 할 사항들이 잘 정리되어 있습니다.



새로운 방법론을 대할 때에는 확실히 공부하고 정말 중요한 것이 무엇인지 잘 생각해서 받아들여야 합니다. 개발 일정에 쫓겨 프로젝트에 대한 통제력을 잃고 있다면, XP와 같은 새로운 방법론도 공부해 보고 현재의 개발 관행에 대해서도 다시 한번 돌아보기 바랍니다. @





ZDNET [박민우의 e-Simple] 디지털 컨텐트에서 디지털 자산 관리로?



http://www.zdnet.co.kr/anchordesk/todays/mwpark/article.jsp?id=67055&forum=1
















[박민우의 e-Simple] 디지털 컨텐트에서 디지털 자산 관리로?











박민우 (메타와이즈 사장)

2004/02/11











align="left" valign="top" border="0" hspace="4">‘디지털 컨텐트’란 무엇일까? 사전에서 디지털 컨텐트에 대한 정의를 찾아보면 다음과 같다.



"인터넷이나 컴퓨터 통신 등을 통하여 제공되는 각종 정보나 그 내용물"



백과사전에서 ‘디지털 컨텐트’를 찾아보면 좀 더 구체적으로 설명하고 있다.



"유무선 전기 통신망에서 사용하기 위하여 문자·부호·음성·음향·이미지·영상 등을 디지털 방식으로 제작해 처리·유통하는 각종 정보 또는 그 내용물을 통틀어 이르는 개념이다. 컨텐트는 본래 문서·연설 등의 내용이나 목차·요지를 뜻하는 말이었다. 그러다 정보통신 기술이 빠르게 발달하면서 각종 유무선 통신망을 통해 제공되는 디지털 정보나 그러한 내용물을 총칭하는 용어로 널리 쓰이게 되었다."



이제는 거의 일반 명사화 된 디지털 컨텐트란 용어를 다시 되새기는 이유는 디지털 자산(Asset)에 대한 설명을 하기 위함이다. 사전적 의미를 빌리지 않더라도 디지털 컨텐트는 이미 우리 주변에서 생활의 일부가 되었다. 그리고 비용을 지불하고 컨텐트를 구매하는 것이 이제는 낯설지 않게 되었다.



유선과 무선에서 디지털 컨텐트에 대해서 비용을 지불하는 방식의 차이가 있다. 유선의 경우 정액제가 대부분을 차지한다. 월사용료를 지불하고 해당 컨텐트를 무제한으로 이용하는 방식이다. 각종 텍스트로 된 컨텐트뿐만 아니라 이미지, 동영상, 음악 스트리밍까지 보편화된 컨텐트 타입들이다. 하지만 무선에서는 정액제 보다는 건당 과금이 주류를 이룬다. 그림친구, 벨소리, 컬러링, 게임 등이 그렇다. 즉 유선에서는 월사용료를 내고 컨텐트를 임대하는 형식으로 서비스를 받고 있지만 무선에서는 파일을 비용을 지불하고 소유(보통 컨텐트 유효기간이 들어있으므로 일정기간 소유하게 됨)하게 되는 방식이므로 디지털 자산 관리는 무선에서 매우 중요한 화두가 될 것으로 보인다.



그렇다면 디지털 자산이란 무엇인가?

필자가 얘기하고자 하는 디지털 자산의 개념은 무선에서 컨텐트를 건당 과금으로 구매를 하면서 자연스럽게 생기게 된 소비자의 요구사항의 한 형태라 말할 수 있다. 예를 들면 사용자가 500원을 주고 벨소리를 다운 받게 되면 다운 받은 벨소리는 디지털 컨텐트이자 본인의 디지털 자산이기도 하다. 이렇게 비용을 지불하고 구매한 개개의 파일들은 라이선스 문제가 해결된 개인 소유의 자산인 것이다.



하지만 디지털 컨텐트 유통을 맡고 있는 무선 포탈 사이트들과 이동통신사들은 이렇게 개인들의 디지털 자산이 된 디지털 컨텐트에 대한 인식이 매우 부족한 것이 현실이다. 비용을 지불하고 구매한 벨소리가 휴대폰의 용량이 부족하여 더 이상 다운 받을 수가 없게 되었을 경우 사용자는 휴대폰의 다른 벨소리나 또는 게임과 같은 기 구매된 디지털 자산을 삭제해야 한다.



하드웨어의 한계로 인해 스스로 자산을 소멸시키는 것에 대해서는 이의가 없다. 하지만 동일한 컨텐트를 사용자가 필요시에는 재구매를 해야 한다는 사실이다. 컨텐트 유통을 맡고 있는 서비스 업체에서는 기 구매한 사용자임을 이미 알고 있음에도 불구하고 여러가지 비논리적인 핑계로 자산에 대한 권리를 인정하지 않고 있는 것이다.



물론 각종 휴대폰 제조사에서 디지털 컨텐트들(MOD, VOD 등은 현재 제외)을 백업 받을 수 있는 PC용 솔루션을 제공하고 있다. 하지만 대부분의 솔루션들이 휴대폰 제조사에 종속적이며 해당 업체에서 제공하는 PC-휴대폰 케이블을 이용해야만 한다. 하지만 이 케이블을 이용하기 위해서는 적지 않은 인내와 IT 지식이 필요하다.



앞으로는 점점 컨텐트에 대한 소비욕구와 시장이 커지면서 디지털 자산 관리에 대한 필요성도 높아질 것으로 보인다. 많은 제조사들이 쉽고 편하게 디지털 자산을 관리 할 수 있는 도구를 제공하고 있지만 필자는 궁극적으로 컨텐트 제공사와 컨텐트를 유통하는 이동통신사에서 책임감을 가지고 지원을 해야 된다고 생각한다.



이미 대부분의 멀티미디어 컨텐트들은 단말기에 종속적이기 보다는 이동통신사에 종속적인 상태이다. 016용 벨소리와 011용 벨소리는 호환이 될 수 없지만 같은 011 번호 사용자들은 삼성 휴대폰이든 큐리텔 휴대폰이든 큰 문제가 없다. 따라서 디지털 자산에 대한 관리도 이동통신사 무선인터넷 서비스 별로 관리 돼야 한다.



디지털 자산에는 비용을 지불하고 구매한 디지털 컨텐트도 해당이 되지만 본인의 주소록, 이메일, 카메라폰 사진들까지도 자산으로 볼 수 있으므로 제한된 저장 공간의 한계를 가지는 휴대폰은 고질적인 문제를 안고 갈 수 밖에 없는 상황이다.



물론 고용량의 휴대폰들이 출시가 되겠지만 하드웨어 비용 상승에 대한 부담도 간과할 수는 없다. 현재로서 가장 좋은 방법은 컨텐트를 유통하는 무선포탈 서비스 업체들이 이미 구매한 사용자에 대한 히스토리를 활용해 동일한 컨텐트를 재구매시에는 추가 비용을 지불 하지 않도록 구매 시스템에 대한 수정 변경이 이루어져야 한다. 비용을 지불하지 않은 주소록, 일정, 이메일, 사진들은 해당 이동통신사에서 WAP 디스크와 같은 형태로 휴대폰 내 디지털 자산들을 웹사이트나 PC로 옮겨줄 수 있도록 하는 방법을 제공해 주어야 한다.



이미 이동통신 시장은 음성통화 시장에서 무선컨텐트 시장으로 많은 전환이 이루어진 상태이다. 이동통신사는 통화품질 뿐만 아니라 소비자의 디지털 자산에 대한 권익까지 보호해주고 지원해 줄 수 있어야 진정한 무선 컨텐트 유통 서비스 기업으로 거듭날 수 있을 것이다. @


정말로 멋진 생각인것 같다.



http://www.dkbnews.com/bbs/view.php?id=headlinenews&no=1169














‘거지 같은’ 작태와 작별할 날은?


2004-02-09 19:39 | VIEW : 2,374




도쿄(東京) 신주쿠(新宿)역 근처 길을 지나다 ‘빅 이슈 재팬’이란 잡지를 팔고 있던 50대의 일본인 남성을 만났습니다. 집이 없이 떠돌아다니기에 옷이 조금 지저분할 뿐인 ‘홈리스’입니다. 구걸하는 거지가 아니라 잡지를 파는 홈리스입니다. 근사한 집에 살면서도 돈을 구걸하다시피하는 ‘거지같은’ 한국의 몇몇 정치가를 떠올려보았습니다.



▽홈리스와 거지

실직 등으로 집이 없어져 신주쿠 등 지하철역 주위 지하보도, 우에노 공원, 스미다가와 강 주변 등에 종이상자나 판자로 움막을 짓고 자는 이들이 ‘홈리스’입니다.

스미다가와 강가에서 본 움막은 목공기술을 가진 홈리스였는지 여기저기서 구한 판자로 근사하게 지어진 것이었습니다. 그림 그리는 재주를 가진 홈리스는 방 안을 캔버스로 삼아 멋진 그림을 그려놓고 삽니다. 여름철 우에노공원에서 세탁물을 빨래줄에 말려놓고, 나무 사이에 쳐진 그물침대 위에 누워, 라디오 음악을 크게 틀어놓고 독서를 즐기는 로맨티스트 홈리스를 발견하는 일도 그렇게 드물지 않습니다.



하지만 남에게 돈을 구걸해 얻어먹는 ‘거지’하고는 뜻이 다르지요. 실제 모습도 다릅니다.

서울의 지하철 역 주변이나 시내버스에서 구걸하는 이들과 달리 이들은 일을 합니다. 주로 재활용 폐지나 빈 깡통을 수집해 도매상에 넘기거나 읽고 버린 주간지와 만화책등을 주워 싼 값에 되파는 수입으로 끼니를 해결합니다.



아니면 밤 늦게 빵집이나 스시집 등에서 음식을 얻습니다. 당장 먹는데 아무 문제가 없지만 내일은 팔 수 없어 버릴 수 밖에 없는 음식이지요. 주인들도 이들에게 제공하는 편이 쓰레기로 버리는 것보다 낫기 때문에 기꺼이 제공합니다.



▽잡지 ‘빅 이슈 재팬’

이 남성도 홈리스이지만 지금은 어엿한 ‘잡지 판매원’입니다. 얼굴사진이 들어있는 ID카드를 목에 걸고 행인이 많은 길에서 잡지를 들고 서 있는 것이 일입니다.



다가가서 두 권을 산 뒤 그에게 오늘 몇권이냐 팔았는지 물어봤습니다.

“아침부터 38부 팔았습니다. 저녁까지는 아마 60부쯤 팔 것 같습니다”

이 정도 돈이면 끼니 걱정은 하지 않아도 되지요. 그래선지 약간 웃더군요.



월 1회꼴로 발행되는 30쪽 안팎의 잡지 ‘빅 이슈 재팬’은 지난해 9월부터 오사카의 시민단체가 ‘홈리스’들에게 일자리를 마련해주기 위해 처음 발행했습니다.

1991년 영국 런던에서 존 버드라는 사람이 비슷한 취지에서 처음 만든 잡지 ‘빅 이슈’의 일본판이지요.



홈리스가 잡지판매 희망자로 등록을 마치면 한 부 200엔의 잡지 10부를 처음에 무료로 받습니다. 이걸 팔아 생기는 2000엔이 ‘자본금’이 됩니다. 이후에는 90엔에 사서 200엔에 팔아 권당 110엔(약1100원)의 수입을 얻게 됩니다.



최신호인 4호 주요 내용을 보면 일본의 인기 여배우 인터뷰, 사교육비에 멍드는 한일 사정 등 국내외 화제성 소식과 함께 스포츠, 영화, 패션 등 비교적 시의성에 관계없는 이슈들이 대부분입니다. 월 2회 발행을 목표로 했지만 번역, 기사작성, 편집, 인쇄 등을 모두 자원봉사자가 해결해야 하기 때문에 아직 월1회 발행에 머물고 있지요.



▽진정한 시민단체

오사카 사무국에 전화를 해보았습니다.

한 자원봉사자는 “현재 잡지 판매인으로 등록해 신분증을 발급받은 사람은 180명이나 이중 실제로 판매종사자는 130명 가량”이라면서 1인당 평균 한달에 500~600부를 팔고 있다고 말했습니다.



“가장 추운 12월과 1월에 7만부 이상 팔렸기 때문에 날이 따뜻해지면 판매부수도 늘고 판매희망자도 늘어날 것으로 봅니다”

그의 목소리는 희망에 찬 것이었습니다.

현재 7만4000부의 발행부수가 열 배로 늘어날 것을 기원합니다.



정기구독을 하고 싶다고 하자 그는 인터넷 주소를 통해 신청하라고 하더군요.

빅 이슈 재팬’의 인터넷 홈페이지는 http://www.bigissuejapan.com/ 입니다.

그는 조심스레 덧붙였습니다.

“정기구독은 사실 요금이 비쌉니다. 그래서인데 가능하다면 판매원을 만나면 그때 직접 사 주는 것이 좋을 것 같군요.”



편하자고 정기구독하려던 제가 한방 먹은 셈입니다. 정기구독자를 늘려 사무국 재정을 안정시키는 것 보다, 잡지판매를 하는 홈리스를 만났을 때 사람들이 200엔 짜리 잡지를 사주는 것이 원래 그들의 활동 취지에 더 부합하는 것입니다. 홈리스를 만날 수 없는 지방에 산다던가 하는 사정상 연간 1만5000엔(약 15만원)을 내고 정기구독을 하는 사람도 100여명 있다고 하였습니다.



이 단체에는 격려의 엽서가 쏟아지고 있다고 합니다. 특별찬조금을 내놓은 사람도 적지 않다고 합니다.

수천명에 이르는 일본의 홈리스. ‘빅 이슈 재팬’ 잡지 한 권이 그들의 문제를 해결해 줄 수 없는 것은 명확합니다. 그렇지만 집은 없으나 구걸하지 않고 자립을 위해 애쓰는 일본의 홈리스와 그들을 헌신적으로 돕는 이들 시민단체의 뜻은 높이 살 만합니다.



그들의 활동을 취재하며 자꾸 떠올리는 모습이 있었습니다.

‘대궐 같은’ 집에 살면서도 기업에 ‘정치자금’이란 근사한 이름으로 돈을 구걸하다시피하는 한국의 일부 정치인, 그럴듯한 이름의 ‘봉사단체’를 만들어서는 일 할 생각은 뒷전이고 정부나 지자체에, 기업에 손부터 벌리려는 이들의 모습이 그것입니다.

한마디로 ‘거지 같은’ 이런 작태와 작별할 날은 언제일까요.



도깨비뉴스 리포터 지안 jian@dkbnews.com

http://phpschool.com/bbs2/inc_view.html?id=87005&code=talkbox2


글쓴이:D.E.A.  JAVA

글들을 읽다가 JAVA 관련 내용이 있어 글을 씁니다.

저도 별 수 없었는지 처음에는 c 에 있던 포인터가 없다는 둥 하는 핑계만 대기 바쁘다가
JAVA 가 아닌 OOP 라는 것의 느낌을 어느 정도 알아가기 시작하니까 저절로 고개가 끄덕여지는
부분들이 생겼습니다.

그 느낌을 그대로 전달해 드릴 수 있으면 좋겠지만 그 역시 아무나 할 수 있는 일은 아닌가 봅니다.
누구를 가르친다는 것, 혹은 시중에 나와 있는 수많은 책들 같은 것을 저술한다는 것이... 이 책은
너무 구리다 하고 쉽게 말하지만 그런 시도조차 못 하는 사람이 여기서 이 글을 쓰고 있네요.

포인터가 없다는 점? 진짜 없지는 않지만 아무튼 직접적인 메모리 주소 접근은 자유롭지 못합니다.
이게 개념없는 사람한테는 좋을 지 몰라도 c 를 상당히 능숙히 다룰 수 있는 사람에게는 정말 답답
하기 그지없게 보일 수 있습니다.

이미 준비되어 있는 수많은 클래스들? 기본 API 에서조차 c 를 배울 때 정말 무슨 소리인지 모르겠고
어디에 쓰는지조차 몰랐던 linked-list 가 이미 훌륭한 클래스로 존재하고 있습니다. 물론 c 에 있어
서는 표준은 아닐 지라도 너무나 방대한 라이브러리들이 존재하고 있는 것 또한 사실입니다.
게다가 JAVA 그 자체는 퍼포먼스에 있어서 불리할 뿐만 아니라 정작 표준(?) API 소스들을 열어 보아도
정작 중요한 부분은 JNI 로 구현되어 있어 그 내막을 알 수가 없습니다. 대표적인 것이
java.lang.Object 겠죠. 실제 JAVA 가 작동되는 양상은 물론 JVM 소스를 보면 알 수 있습니다만...
"그럴 필요가 없다" 라는 것이 대부분의 경우입니다.

JAVA 로 프로그램을 만들건, c 로 만들건 중요한 것은 아닙니다. JAVA 장점, 즉 OOP 의 장점을 100%
활용할 수 있느냐가 중요한 문제입니다. 그런 점에 있어서 JAVA 가 OOP 를 구현하는데 상당한 장점을
제공하기에 JAVA 를 쓴다고 생각합니다.

c 같은 전통의 언어를 쓰더라도 나름대로 정말 잘 모듈화된 설계를 할 수도 있습니다. 퍼포먼스 측면을
생각하면 c 의 손을 들어 줄 수도 있습니다만 솔직히 요즈음 PC 는 그 옛날 악명높던 dos 시절의
640kb 메모리 제한 문제도 없습니다.

중요한 것은...
디자인 패턴이라고 해야 할까요, 대부분의 JAVA 책에서 언급하는 객체지향의 장점... 캡슐화, 재사용성
등 JAVA 로 말하면 JAVA 답게 설계하는 것이 중요한 문제입니다. JAVA interface source 작성 자체는
너무나도 쉽습니다. 아무런 기능도 없는 method 들만 써 넣는 것은 것은 그야말로 초등학생이 아닌
유치원생들도 할 수 있는 일입니다. 그러나 '제대로 된' interface 의 작성, abstract class 의 작성
등은 정말로 어렵습니다. 배우고자 마음먹고 당장 책을 집어들어도 그게 그리 중요한 것인지 바로 알 수
있는 사람은 정말 드물 것입니다. 사람마다 차이가 있겠지만, 당장 코드 몇 줄 짜는 것은 사실 누구나
쉽게 할 수 있지만 제대로 된 객체지향성을 구현할 수 있게 되기까지는 상당한 시일이 걸리며 대부분
어설프게 흉내내다가 그마저도 못 하게 됩니다.

웹 쪽으로 특화시켜서 얘기해 보겠습니다. JSP 나 PHP 나 차이가 없습니다. 둘 다 '스크립트' 언어입니다.
심지어는 그냥 JSP 만 해서는 PHP 보다 단점이 많을 수 있는 경우도 생깁니다. JSP 를 하고자 한다면,
먼저 Servlet(HttpServlet) 를 제대로 이해하고 접근하는 것이 좋습니다. 그렇다고 서블릿만 죽어라고
하다가 JSP 를 해야 한다는 것은 아닙니다. 그렇지만 Servlet 혹은 HttpServlet 을 정말 제대로 이해하려면
'객체지향' 개념 그 자체부터 어느 정도는 이해를 할 수 있어야 비로소 감을 잡을 수 있게 됩니다.
interface, ClassCasting 부터 시작해서 thread 작동 방식 등...이쯤 되면 아무리 허접하더라도 간단한
'웹 서버 프로그램' 을 만드는 것까지 가능한 수준에 도달할 수 있습니다. ( 실제 구현해 보며 좋아할
수 있는 여건이 되는가 하는 문제는 별개입니다. 그럴 수 있는 상황이 오면 정말 행복한 경우겠지요. )

저도 JAVA 가 언제까지 살아남을 수 있을지는 모르겠습니다. 그럼에도 불구하고 JAVA 는 정말 잘 설계된
언어라고 생각하며 실질적으로도 현재까지는 많이 쓰이는, '주류'인 것도 사실입니다. 더 중요한 것은...

사족으로 흘러 버립니다만... ^^;

제 전공이 기초학문이라 그런 것인지 몰라도, 사장이 되어 버리건 말건 이런 '개념' 자체를 창조하는
시도 역시 우리 나라도 이제는 조금씩 해 보아야 할 때가 아닌가 합니다. 실제로 JAVA 처럼 성공한
사례보다 실패한 사례가 더욱 많을 것입니다. 언제까지 우리는 PHP 플머는 허접하다느니 하는 것으로만
싸울 것인지... 코드 몇 줄 짜는 것은 PHP 를 쓰건 JAVA 를 쓰건 똑같습니다. c 란 개념 자체를 만드는
것, SQL 이란 것을 제안하는 것, OOP 란 개념을 만들고 구현하는 것, RSA 암호화 알고리즘 같은 것들을
제안하는 것...
이런 것들 뿐만 아니라 주변에 안경쓰고 있는 사람들 많고 나름대로 우리나라도 좋은 안경테 만드는
곳은 많다고 하지만 '좋은 렌즈' 를 만들 수 있는 곳은 없다고 알고 있습니다.

제로보드란 거... 정말 잘 만든 것 같은데 '제로보드' 가 기술력은 아닙니다. 제로보드를 만드는 데
사용된 PHP 라는 언어가 바로 기술이라고 생각합니다.

그런데... 높으신 분들도 모르지는 않을 것이라 믿고 싶지만 그것보다도 우리 나라의 상황이 아직 그럴
여력이 없다는 슬픈 현실 또한 무시 못하겠더군요. 살다 보니까.
http://www.inews24.com/php/news_view.php?g_serial=107335&g_menu=090334

























[SW산업을 살리자 - 2] 주먹구구식 기술개발, 기초 체력 저하의 악순환
김상범기자 ssanba@inews24.com
2004년 01월 18일
 

국내 SW산업이 경쟁력을 확보하지 못하고 있는 이유는 어디에서 비롯된 것일까. 제품 자체의 경쟁력이 떨어지고, CEO의 경영능력 부재도 원인으로 꼽힐 것이다. 제품을 만들어도 제값받고 팔 수 없는 왜곡된 시장구조와 소프트웨어에 대한 사용자들의 '공짜' 인식도 여전하고, 이를 제어하고 관리해야 할 법과 제도의 부실함도 지적의 대상이다.

'바로 이것이다'라고 한 두가지를 꼽기가 어려운 상황이다. 다양한 요인들이 복합적으로 얽혀있는 총체적인 부실 구조라고 할 수 밖에 없다.

이 가운데 우선 SW 자체의 질적인 경쟁력 부분에 청진기를 대본다. 가장 기본적이고 원초적인 경쟁력이기 때문이다.

우리의 현실을 짚어보고 문제를 진단하는 것은 바람직한 대안을 위한 첫걸음이다.

과연 우리나라 SW는 외국의 SW와 비교해 제품의 경쟁력을 갖추고 있는가. 이 부분은 우리나라 소프트웨어 개발 환경과 문화의 차이를 점검하는데서 시작된다.

◆ 세계 최고의 '코딩' 능력

"우리나라 개발자들의 개발능력은 세계 최고 수준이다."

흔히 하는 얘기다. 프로그램 개발 능력만큼은 어디에 내놔도 뒤지지 않을 것이라는 데 SW 업계는 대체로 공감한다.

하지만 '우리나라 SW의 경쟁력은 있는가'라는 부분에서는 선뜻 공감하지 못한다. 아니, 고개를 좌우로 흔들 수 밖에 없다. 세계 최고수준의 개발능력은 공감하면서도 세계 최고 수준의 제품에는 자신없어 하는 이유는 무엇인가.

지난해 국내 소프트웨어 업체 가운데 처음으로 해외 매출 1천만달러를 돌파하는 기록을 세웠던 핸디소프트. 미국 현지법인 핸디소프트글로벌 설립 5년만에 약 1천500만달러의 현지 매출을 올렸다.

이 회사가 해외에서 주력하고 있는 BPM(Business Process Management) 솔루션은 세계적인 시장 조사업체 가트너로부터 시장의 주요 제품으로 주목을 받기도 했다. 제품의 경쟁력을 인정받고 있다는 얘기다.

핸디소프트는 미국 현지법인 설립 초기, 현지화 전략에 따라 개발진들도 거의 현지인들도 꾸렸다. 그러나 미국 진출 5년이 지난 현재, 핸디소프트글로벌의 개발진 30여명은 거의 모두 한국인 개발자들로 구성돼 있다.

김규동 핸디소프트 사장은 "프로그램 개발 부분에서는 우리나라 개발자들이 월등하다는 것을 알게 됐다. 프로그램 생산성만 보면 미국 개발자들이 상대가 안된다"고 잘라 말했다. 김 사장은 또 "한때 인도의 유력 아웃소싱 업체에 소프트웨어 아웃소싱을 의뢰한 적도 있었지만 결국 그만두었다. 역시 기대했던 성능에 못미쳤기 때문이다"고 말했다.

이런 점을 들어 김 사장은 우리나라 소프트웨어 개발자들의 프로그램 개발능력은 '세계적'이라고 잘라 말한다.

그렇다면 미국에서의 성과는 우리나라 개발진들의 우수한 개발능력에서 비롯된 것일까.

김 사장은 "개발 능력은 뛰어나지만 문제는 설계 부분이다. 이 부분은 우리 개발자들이 많이 부족한 게 사실"이라고 평가했다. 그래서 핸디소프트글로벌의 개발인력은 설계 부분을 담당하는 현지인과 프로그램 개발을 담당하는 한국인 프로그래머로 구성돼 있다는 설명이다.

미국 시장에서 주목받기 시작한 핸디소프트 BPM 솔루션의 경쟁력은 미국인 설계자와 한국인 프로그래머의 조화를 통해 얻어낸 것이라는 얘기다.

국내 이미징 솔루션 시장에서 제품 경쟁력만으로도 글로벌 SW 기업을 위협하는 기업이 있다. 설립된지 7년된 얼라이언스시스템이 주인공. 금융권을 중심으로 이미징 솔루션 시장에서 외산 솔루션과 당당히 경쟁을 벌이고 있는 이 회사의 제품 경쟁력은 어디서 나오는 것일까.

이 회사 조성구 사장은 그 비결을 미국 현지법인에서 찾는다. 이 회사가 설립한 미국 현지법인은 국내 대부분의 기업들처럼 마케팅이나 영업을 위해 설립한 것이 아니다. 철저히 연구개발만을 담당하는 말 그대로 ‘현지연구소’다.

조 사장은 "경험이 많은 현지 개발자들 중심으로 구성된 미국 법인의 연구진들은 이미 미국 현지 전문컨설팅 업체들로부터 공인을 받았을 만큼 인정을 받고 있다. 이 개발진들이 우리 회사 솔루션의 경쟁력"이라고 말했다.

조 사장은 또 "이들은 지금 차세대 제품을 설계하고 있다. 무엇보다 장기적인 관점에서 제품을 설계하는 능력은 국내 개발자들이 따라가기 힘든 부분"이라고 강조했다.

소프트웨어 개발이라고 하면 우리는 흔히 프로그램 코딩을 떠올린다. '개발 = 코딩'이라는 인식이 강하다.

하지만 소프트웨어 개발은 크게 분류해도 설계와 디자인, 코딩 등으로 나눠진다. 각 영역을 담당하는 개발인력도 아키텍트, 소프트웨어 엔지니어, 프로그래머로 나뉜다.

이들의 조화로운 역할 분담을 통해 경쟁력있는 소프트웨어가 만들어진다. 그러나 우리 현실은 설계와 디자인이 거의 생략된 채 코딩에 쏠려있다.

우리가 세계 최고의 개발능력이라고 하는 것은 결국 '세계 최고의 코딩 능력'이라는 얘기다.

◆ 아키텍트가 부족한 현실

"미국에서 만난 사람들 명함을 쭉 깔아놓고 보니 가장 많은 직함이 '아키텍트'였다." 해외출장에서 돌아온 한 소프트웨어 업체 사장의 얘기다.

우리나라 소프트웨어 업체들이 미국 시장 진출을 위해 현지 기업들을 방문하면 만나는 사람들 가운데 상당수가 '아키텍트(Architect)'라는 직함을 가진 개발자들이라고 한다.

아키텍트도 칩 아키텍트, 테크니컬 아키텍트, 소프트웨어 아키텍트 등 다양하다.

아키텍트는 말 그대로 설계자란 뜻이다. 소프트웨어의 기본 구조를 설계하고 필요한 기술을 선정하는 일을 맡는다. 개발자들의 총 사령관인 셈이다.

하지만 우리는 아키텍트가 절대 부족하다. 이유는 소프트웨어 개발의 역사가 짧다는 점을 꼽을 수 있다. 아키텍트는 풍부한 프로그래머 경험을 바탕으로 하기 때문이다.

하지만 우리나라 프로그래머들이 나홀로 익혀, 나홀로 작업하는데 익숙하다는 점도 아키텍트가 자랄 토양을 부족하게 만드는 이유로 꼽을 수 있다.

먹고살기 힘든 우리나라 소프트웨어 개발업체들에게 아키텍트가 '그림의 떡'일 수 있다. 하지만 기본적으로 소프트웨어 개발문화가 프로그램 개발의 전단계를 소홀히 취급하는 것은 사실이다. 또한 대형 SI 업체의 경우에도 프로젝트를 진행하는 과정에서 아키텍트의 존재는 미미하다.

대형 SI업체의 한 프로젝트 팀장은 "명목상으로는 아키텍트가 있다. 하지만 현실은 솔루션 공급업체들이나 개발자들의 관리, 감독을 맡는 PM 수준이라고 보는 것이 맞을 것"이라고 말했다.

소프트웨어는 살아있는 제품이다. 한번 개발을 완료했다고 완제품으로 영원히 지속되지 않는다. 계속 기능이 추가되고 변경돼야 상품으로서 가치를 인정받을 수 있다. 버전업 되지 않는 소프트웨어는 생명력이 없다.

이런 점에서 소프트웨어 개발은 기초 설계가 매우 중요하다. 그리고 설계가 튼튼한 제품을 만들기 위해 아키텍트라는 전문영역이 필요한 것이다.

하지만 우리나라 SW 개발 환경은 어떤가. 무엇을 만들 것인가만 정해지면 바로 개발작업에 들어간다. 이른바 코딩작업에 들어가는 것이다. 설계는 없다. 기능만 충족시키면 오케이다.

기초 설계를 튼튼히 하는 작업은 꽤 지리한 시간이다. 전체 소프트웨어 개발 시간은 늦어진다. 하지만 개발 완료후 유지보수나 기능 보강작업은 훨씬 빨라지고 쉬어진다.

하우리는 지난해 8월 바이러스 백신 엔진을 콤포넌트 기반으로 다시 설계했다. 처음엔 지리한 작업과 자신만의 노하우를 살리지 못할 것이라는 개발자들의 우려때문에 쉽지 않았다고 한다.

하지만 어렵사리 엔진을 재설계한 이후 제품 경쟁력만큼은 한층 강화됐다고 평가하고 있다.

권석철 하우리 사장은 "새로운 바이러스가 나오면 각 OS별로 담당자들이 나와 백신을 개발하고 컴파일해서 플랫폼별로 다시 설치하고 해야 했다. 20여명이 총 출동해야 했다. 하지만 지금은 다르다. 3~4명의 인력만 있어도 된다. 콤포넌트 기반의 엔진 재설계 덕분이다. 처음엔 힘들었지만 재설계의 덕을 톡톡히 보고 있다"고 전한다.

아키텍트는 장기적으로 개발자(프로그래머)들의 미래 진로를 튼튼히 한다는 점에서도 필요하다. 프로그래머가 성장해 올라갈 수 있는 업무영역이 관리자외에 없다면 우리는 기껏해야 4~5년 경력이 최고인 나홀로 프로그래머만 잔뜩 양산할 수 밖에 없을지도 모른다.

◆ 문제는 '커뮤니케이션의 부재'

설계능력의 부족은 소프트웨어 역사가 짧기때문이라고 넘길 수 있다. 시간이 해결해 줄 수도 있다는 얘기다. 하지만 우리나라 개발 문화에서는 시간이 해결해 줄 수 있을지 의문이다.

보험설계사 K씨(35). 대학을 졸업하고 대기업에서 약 7년을 프로그래머로 일했던 K씨는 프로그래머로써 더 이상의 비전이 없다는 결론을 내리고 1년전 보험설계사로 인생의 방향을 틀었다.

새로운 일에 만족하고 있다는 K씨. 하지만 그가 완전히 프로그램 작성에서 손을 놓은 것은 아니다. 그는 지금도 가끔 전 직장으로 달려가 프로그램 개발에 손을 댄다.

"그만두기 직전에 개발해 놓은 프로그램에 문제가 생기거나, 새로운 기능을 추가할 일이 생기면 연락이 오죠. 전화로 설명해주기도 하지만 직접 달려가는 경우도 종종 있어요. 제가 그래도 회계 시스템 쪽에서는 전문가 소리를 들었거든요."

K씨는 이 얘기를 들려주며 은근히 자긍심을 드러냈지만, 사실 K씨의 이야기는 우리나라 SW 개발 문화의 부실한 단면을 고스란히 보여주는 사례다.

나홀로 작업에 익숙한 개발자들이 회사를 떠나게 되면 그 프로그램은 사실상 더 이상의 업그레이드나 수정이 불가능해진다.

K씨가 회사를 그만두고 나오면서 후임자에게 넘겨준 것은 소프트웨어의 소스코드와 데이터 구조를 정의해놓은 워드파일 하나가 전부다.

후임자는 문제가 생기거나, 기능을 수정해야 할 때마다 소스코드를 모두 프린터로 출력해 한줄한줄 해독하는 작업을 벌여야 한다. 그러다 막히면 결국 K씨에게 SOS를 칠 수 밖에 없다.

소프트웨어는 살아있는 제품이며 지속적인 관리가 필요하다. 기초적인 설계를 충분히 해야 하는 것은 물론 각 개발 과정마다 꼼꼼한 문서작업을 통해 미래를 대비해야 한다. 하지만 우리 개발문화는 결과만을 중시한다.

K씨의 사례는 그래도 개발자와 연락이 돼 계속 손을 볼 수 있는 경우다. 다른 많은 경우 한번 개발자가 떠나면 후임자는 아예 프로그램을 새로 개발하는 편이 편하다는 게 일반적인 인식이다.

우리나라 프로그래머의 1세대로 꼽히는 안철수 사장은 우리나라 개발문화의 문제점으로 '커뮤니케이션의 부재'를 꼽았다.

안 사장은 "개발자만 작업해서 되는 것이 아니라 마케팅, 영업, 고객 지원, 기술 지원을 비롯하여, 고객과도 직접 의사소통을 하면서 일을 해나가야 되는 세상이다. 따라서 현대 사회에서는 커뮤니케이션 스킬이 필수적이지만, 대학교를 졸업하고 바로 회사에 들어오는 사람들 가운데는 본인이 생각하는 바를 정확히 말로 표현하지 못하고, 다른 사람이 말하는 것들을 정확하게 알아듣지 못하는 경우가 생각보다 많다"고 지적한다.

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

◆ '현실 탓'으로만 돌려야 하는 현실

설계능력과 커뮤니케이션의 부족. 이는 우리나라 소프트웨어 기업 거의 대부분이 겪고 있는 문제다.

특히 커뮤니케이션의 부족은 우리나라 소프트웨어의 경쟁력을 저하시키는 기본적인 요인으로 작용한다.

대형 SI기업의 K과장(38). 지난해 그는 모두 4개의 프로젝트를 관리했다. 그는 우리나라 SW 업체들의 문제를 '기본이 안돼 있다'는 말로 요약했다.

그는 "이메일 솔루션이 필요해 제안서를 요청했는데 달랑 제품 소개서 한 장 보내더라. 자재설비업체들마저도 대단히 정제된 제안서 템플릿을 갖고 있는데 정말 비교되더라. 정말 한심한 수준이다"고 개탄했다.

K 과장은 "어찌어찌해 제안서를 받아 프로젝트에 들어가도 답답한 것은 마찬가지다. 프로젝트를 하면서 문서작업은 전혀 없다. 문서작업을 하라고 하면 마지못해 시늉만 낸다. 개발을 끝내놓고 매뉴얼을 만드는 것도 일일이 목차를 정해줘야 겨우 정리하는 수준"이라고 꼬집었다.

K 과장은 그러면서도 "어떠한 기능을 만들어내는 코딩 작업만큼은 진짜 우리나라 개발자들이 훌륭하다. 혀들 내두를 정도다. 하지만 그게 전부다. 솔직히 이러다 나중에 문제가 생기면 소스 뽑아서 일일이 체크해야 할 생각에 암담할 때가 많다"고 한숨을 쉬었다.

K과장은 "우리나라 소프트웨어 기업들은 대부분 개발자 출신이나 대기업 임원 출신들이 CEO다. 이들이 구조적인 개발 문화에 관심이 없는 것 같다. 또 워낙 영세한 기업들이 많아 프로젝트 따내는 데 급급하다보니 그런데 신경쓸 여력이 없고 결국 악순환이 계속되는 것 같다"고 진단했다.

모로가도 서울만 가면된다. 결과만 제대로 나오면 된다는 생각은 중간 과정을 생략 또는 무시해버리는 우리의 개발 문화의 씁슬한 단면이다.

이러한 개발문화는 제품 개발이후 사후서비스의 부실로 곧바로 이어진다는 점에서도 심각하다. 사후서비스의 부실은 다시 기업의 장기적인 생존과도 직결되기 때문이다.

제품 개발인력만 있지 사후서비스 인력은 없다. 프로젝트에 개발인력 투입하고 나면 기존 고객의 사후서비스는 엄두도 못낸다.

사후서비스 문제는 매뉴얼이 부실하다는 데서 단적으로 드러난다. 매뉴얼을 달라고 하면 A4용지 서너장이 전부인 경우도 있다.

웹 솔루션 개발업체인 A사는 일본 시장 진출시 매뉴얼 때문에 큰 곤욕을 치렀다. 제품에 자신은 있다고 믿었지만, 일본 기업은 제품을 검토하는데 거의 1년여의 시간을 끌었다. 매뉴얼을 보고 하나하나 모두 실제 실행해보면서 한달에 한번씩 장문의 검토 보고서를 보내왔다.

어느 부분에서 매뉴얼대로 작업이 안되고, 어떤 부분은 매뉴얼에서 찾을 수 없었다는 내용이 빼곡이 찬 보고서를 받아 매뉴얼을 수정하고 제품을 손보면서 혀를 내둘러야 했다. 결국 일본어 매뉴얼은 한글 매뉴얼의 3배 가까이 두툼해졌고, 그 와중에 제품의 기능도 탄탄해질 수 있었다고 쓴 웃음을 지었다.

품질관리나 매뉴얼 작성도 우리는 대개 개발자들이 직접 한다. 이 때문에 소비자의 관점에서 생각하는 서비스 정신이 부족할 수 밖에 없다. 외국의 기업들은 품질관리나 매뉴얼 작성을 개발자가 아닌 별도의 인력이 담당한다.

프로그램을 전혀 모르는 최종 사용자를 데려다 매뉴얼을 보면서 소프트웨어를 이용하게 해 본다. 그렇게 해서 최종 매뉴얼이 통과된다. 우리 현실에서는 꿈같은 이야기일 수밖에 없다.

소프트웨어 개발 이후가 중요한 것은 사후서비스 부분의 매출이 소프트웨어 기업의 중요한 매출원이자, 안정적인 매출 확보의 원동력이기 때문이다.

유지보수 매출이 안정화됐다는 것은 기업이 안정적인 기반을 다졌다는 말과 같다. 하지만 우리 소프트웨어 업체들 가운데 이런 기업은 거의 찾아보기가 어렵다. 그만큼 SW산업의 기초 체력이 부실하다는 얘기다.

하지만 CEO든 개발자든 모두 '현실때문에...'만 되뇌이고 있다.

CEO는 '당장 먹고 살기 힘든데...', 개발자는 '하고 싶지만 일이 너무 많아서...'

  1. 양해준 2015.07.02 16:26 신고

    잘 읽었습니다. 100% 공감합니다.
    주먹구구식...에 질려서 아키텍트나 PM은 고사하고, 분석설계도 하고 싶지 않습니다. 그냥 코딩 좀 하다가 전업할 생각입니다.
    저는 나이도 있고, 일본 경험도 있고, ... 구질구질한 느낌이네요.
    문득 해 볼까하다가도 아니야하고 반복되어지네요.
    본격적인(?) 엉터리는 되고 싶지 않네요.
    웃픈 현실이네요...

http://www.zdnet.co.kr/anchordesk/todays/jhok/article.jsp?id=65933&forum=1














[옥제환의 Inter-Tainment] 관리, 염두에 두고 있나요?











옥제환 (컬럼니스트)

2003/12/12











align="left" valign="top" border="0" hspace="4">영종도에 으리으리한 시설로 가득 찬 신공항이 처음 생길 때 눈길을 끌었던 것은 바로 인터넷 전화기였다. 공항에 비치된 인터넷 전화기는 인터넷 검색은 물론, 이메일 전송과 동영상 감상까지 가능해 신공항의 등장과 함께 달라지는 미래 세상을 보여주는 이정표 같은 것이었다.



도심 한복판에 관광안내 키오스크가 생겼을 때에도 ‘서울에 처음 온 외국인이나 관광객에게 유용한 도우미가 되겠구나. 참 편리하겠네’라고 생각했었다. 관광 키오스크는 근처의 관광지와 교통안내는 물론 숙박과 환율정보에 이르기까지 편리하게 만들어진 관광도우미로서 곧 광역시마다 들어서게 됐다.



그러나 얼마 전 공항에서 다시 본 인터넷 전화기는 사용되지도 않고, 그나마 몇몇은 고장나 제 기능을 잃은 모습이었다. 게다가 도심 한복판에서는 때가 꼬질꼬질하게 묻고, 전원도 들어오지 않아 작동 조차 되지 않는 흉물스러운 관광 키오스크도 보였다. 너무너무 더러워서 손가락으로 눌러서 조작할 엄두조차 나지 않는 상태로 무뚝뚝하게 시체처럼 서 있는 모습.



곳곳에 잘 계획되고 잘 만들어지고 칭송받는 서비스와 제품들이 있음에도 불구하고, 어떤 것들은 시작의 화려함이 금새 잊혀진 채 뿌연 먼지와 무관심 속에서 나뒹굴고 있다. 훌륭한 제품을 만들기 위해 오랜 시간 땀을 흘려 결실을 이뤄내면서도 탄생한 결과가 좋은 평가를 받는 그 순간 모든 것이 끝나버린 것처럼 무관심 속에서 죽어가고 있는 것이다.



누구든지, 무엇이든지 시작과 끝이 한결같다는 것은 쉬운 일도 아니고 어쩌면 불가능한 것일지도 모른다. 가정에서, 직장에서, 학교에서, 프로젝트에서, 제품 생산에서, 인간관계에서 소위 ‘중간관리’를 한다는 것은 매우 피곤하며 잔손이 많이 가고, 번거로우며 어려운 일이다. 그럼에도 불구하고 중간관리는 새로운 재화의 생산에 준하는 값어치를 가지고 있다.



그렇다면 여기서 질문 하나, “과연 중간 관리를 염두에 두고 시작하나?”



‘maintenance’의 중요성에 대해 우리 사회는 유독 간과하는 모습을 보이고 있다. 새로 생긴 지하철, 버스, 공공시설, 화장실, 자동판매기, 운영자가 사라진 커뮤니티 등, 군대를 제외하고는 ‘maintenance’가 적합하게 이뤄지는 모습은 찾아보기 어렵다.



화려한 플래시 효과를 이용해 처음 방문하는 사람들의 입에서 “오우~”하는 탄성이 나올 정도로 멋지게 만들어진 웹페이지도 업데이트할 엄두를 내지 못내고, 처음 만들어진 내용 그대로 몇 달 동안을 단순히 화려하기만 한 홈페이지로 남는 경우가 비일비재하다.



또한 고객을 끌어모으기 위한 수단으로 한 때 각광받았던 마일리지 제도도 현재 결국 서비스 업체 스스로를 옭아매고 있는 상황이다.



프로그래밍, 디자인, 프로젝트 기획, 제품 설계, 상품 기획, 상품 제작 등 IT에 관련된 전 영역에서 너무 급히 일정에 쫓기고 출시 당시의 품질 관리에만 신경을 쓴 나머지 ‘나는 처음에 만드는 사람이지 관리는 다른 사람이 할거야’라는 무책임한 핑계들들이 난무하는 것은 아닐지.



여러 디자이너, 개발자, 엔지니어, 기획자, 마케터, 경영자들을 만나고 실제로 그들과 함께 일을 해 봤지만 ‘프로젝트를 완성한 이후 관리를 위해 편리한 관리툴과 관리 지침, 마인드, 관리 비용을 고려하는’ 것을 깊이 고민하는 사람들을 쉽게 볼 수 없었다. 오히려 중간관리나 사후관리에 대한 제안을 하면 스스로가 피곤해지는 일이 많이 생기게 될 뿐이다.



제품, 서비스, 소프트웨어를 만들 시 단지 ‘완성’ 자체나 ‘스포트라이트’에 너무 치중하지 않고 어떤 일정과 시스템으로 관리될 것이며 그 관리에 필요한 것이 무엇인지 고려하는 자세가 필요한 것이다.



기업 내부에서도 마찬가지다. 프로젝트를 떠맡고 있는 책임자가 공석이 돼도 후임이 무리 없이 프로젝트를 지속해 나갈 수 있도록 각 시스템이 유기적이면서도 독립적으로 만들어져야 하지 않을까.



직장에서 자신이 사용하는 모니터 위의 먼지를 닦아내는 일, 이런 작은 일들도 어찌보면‘maintenance’의 시작일 것이다. @


+ Recent posts