꿈을 꾸다~!!

« 2024/05 »
일	월	화	수	목	금	토
			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	31

▣ HTML5로 무엇을 하고 싶은가? - S/W tip - 2011. 7. 18. 11:00

출처 : http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&keywords=%C0%D0%C0%BB%B0%C5%B8%AE&page=2&wr_id=37493

대체(바꿈)’라는 말은 지금 사용하고 있는 무언가를 다른 것으로 대신한다는 의미이다. 예를 들어 자동차를 가지고 출퇴근을 하다가 건강과 환경을 위해 자전거로 출퇴근을 한다면 자동차를 대체하는 교통수단이 자전거가 된다. 집에서 사무실까지 이동하는 것을 지원한다는 본질적인 목적에 대한 수단이 자동차에서 자전거로 바뀌는 것이다. 프로젝트로 인해 서울에서 대전으로 출퇴근을 해야 한다면 자전거로 이동은 가능하겠지만 10시간 이상(시속 15km 기준인 경우) 소요되는 경로를 매일 출퇴근할 수는 없는 노릇이다. 건강과 환경이라는 취지는 좋지만 무모한 일이 될 수 있다. 오히려 대전역까지 자동차나 열차로 이동을 하고 대전역에서 자전거를 이용해서 사무실로 출퇴근하는 것이 효율적일 것이다.

자동차가 자전거를 대체한다고 해서 시속 80km의 성능과 안락한 의자, 최적의 음향 시스템을 지원할 수 있다는 것은 아니다. 같은 자동차라는 표현에도 최대시속 300km 이상의 수퍼카와 다른 차들과는 분명한 차이가 있다. 대체를 결정하는 기준이 의도한 목적을 달성하느냐 여부가 아니라 가지고 있는 것이 무엇이고 무엇을 하고 싶은지가 되어야 한다. 원하는 목적지에 빠르게 도달하는 것이 하고 싶은 것이라 할지라도 가지고 있는 것(도로교통법, 예산)에 제약이 있다면 수퍼카를 선택하는 것이 최적의 선택은 아니라는 것이다.

<그림 1> Rocket Bike - 출처 : popsci.com

하지만 유행에 민감한 한국적인 정서는 기술 분야에서도 예외는 아니다. 가지고 있는 것에 대한 명확한 인식이 없이 유행을 따라가거나 상급부서의 지침을 무작정 따라가곤 한다. 그래서 자전거가 필요한 공간에 수퍼카를 배치하기도 하고 자동차가 필요한 시점에 자전거를 가져다놓고 개발팀에 무리수를 요구하기도 한다. 안 되는 걸 알면서도 개발팀에서는 무리수를 두고 개발을 완료한다. 그럼 ‘세상에 이런 일이‘에 나올만한 제품이 나오기도 한다. 퍼포먼스나 데모를 위해 만들어진 것이라면 모르겠지만 그렇지 않다면 프로젝트를 마무리하고 유지하기 위한 비용이 더 들어갈 수도 있고 결국에는 제품을 버려야 하는 시점이 올 수도 있다(물론 실용적인 제품이 될 수도 있다. 전동 자전거나 가솔린 엔진을 달고 있는 자전거도 그런 아이디어에서 나온 것이다. 하지만 아직은 가격대가 만만치 않다). 예측할 수 없는 미래에 대응하기 위해서는 새로운 것에 과감히 도전하는 혁신적이고 창의적인 정신이 필요하지 않느냐는 반론이 있을 수 있다.

도전’과 ‘무리수’는 묘하게 수준을 조절하기 힘들기 때문이다. 명확한 정의는 아니지만 유사한 내용의 컬럼을 인용하면 ‘도전’은 약간 힘들어지긴 하지만 어느 정도 성공을 보장할 수 있고 이로 인한 성취감을 가질 수 있어야 한다고 한다. 도전의 수위는 관련된 팀의 능력이나 주변 맥락을 보면서 결정해야 한다는 것이다. 인기 있는 TV 프로그램인 ‘무한도전’의 아이템을 보면 도전의 수위를 어떻게 조절하느냐에 따라 이슈가 되기도 하고 재미없는 프로그램이 되기도 한다.

HTML5와 관련된 이슈도 마찬가지로 접근할 수 있다. 웹과 관련된 기업의 HTML5에 대한 접근은 현 시점에서 볼 때는 무리수인 것처럼 보이지만 장기적인 관점에서 바라볼 때 손익을 하나하나 챙기고 있을 것이다. 현실세계에서 가지고 있는 것이 무엇이고 무엇을 하고 싶은지 다시 한 번 생각해보고 있을 것이다.

다시 찾아온 네트워크 컴퓨터
네트워크 컴퓨터는 특정 목적을 가지고 만들어졌다. 기존 개인용 컴퓨터에 불필요한 장치를 없애고 서버에 올라와 있는 애플리케이션을 실행시킬 수 있는 기능과 통신 기능을 강화했다. 불필요한 요소를 제거했기 때문에 장비의 가격을 내릴 수 있었고 특히 기업 입장에서는 정보의 보안이나 관리 비용 등의 측면에서 획기적인 개념이었다. 하지만 이런 개념이 처음 나왔을 때가 1995년이었고 당시 네트워크 환경은 아직 모뎀을 주로 사용하던 시절이었기 때문에 머릿속에 있는 아이디어를 그대로 실현하기에는 어려운 환경이었다. 같은 시기 출시된 윈도우 95는 운영체제 부분에서 엄청난 점유율을 차지하며 향후 독점적인 지위의 기반을 만들게 되는 시기였다. PC 제조업체 입장에서 윈도우와 연합으로 지속적인 PC 업그레이드 수요를 확보할 수 있게 됐지만 네트워크 컴퓨터는 저렴한 비용에 관리적인 측면에서도 이슈를 만들지 못하게 돼 부정적인 입장을 취했을 수도 있다.

네트워크 컴퓨터는 환경적인 요인과 범용적인 확장 실패로 더 이상 진행되지 못했지만 인터넷 접속기기라는 이름으로 다양한 기기들이 2000년대 다시 등장하기 시작했다. PC 보급의 확대와 인터넷 이용자 수의 지속적인 증가는 이러한 예측을 긍정적으로 바라보게 했다. 넷플라이언스의 아이오프너(i-opener)와 같은 제품은 원가의 3분의 1 수준의 가격으로 단말기를 판매하였고 주요 업체에서 앞 다투어 신제품을 선보였다. 하지만 1년이 채 못 돼 넷플라이언스는 해당 사업을 철수했으며 다른 기업들도 급격한 적신호가 켜지면서 관련 사업을 정리했다. 이런 배경에는 여러 가지가 있지만 우선 도입기의 시장에 너무 많은 업체가 참여하면서 경쟁이 과열됐고 특정 ISP와 연계해서 저렴하게 제공하던 시스템이 단순한 해킹시도로 다른 ISP와 호환할 수 있다는 것이 알려지면서 월단위 과금이라는 서비스 기반이 무너지기도 했다.

<그림 2> i-opener

다른 환경적인 요인도 있었지만 네트워크 컴퓨터가 혁신적인 시도에도 불구하고 성공을 거두지 못했던 것은 가지고 있는 것 중 무엇인가가 부족했던 것이다. 이와 반대로 2000년대 초반 소개된 X-인터넷과 RIA가 지금까지 착실히 성장해 온 배경에는 서버/클라이언트 시스템과 인터넷만으로는 부족했던 무언가를 하나로 적절하게 제공해주겠다는 것이 명확했기 때문이다. 현재 시점에서 사용 가능한 자원을 적절하게 활용할 수 있었고 도전 가능한 명제에 접근했던 것이 사용자의 요구사항을 뒷받침해 줄 수 있었다. 처음부터 경쟁 우위에 올라서기 위해 3D와 같은 기능을 내세웠다면 구현은 가능했겠지만 범용적인 사용자 확보에 실패하고 기억 속에서 사라졌을 것이다. 어도비나 마이크로소프트가 PC 시장에서 그래픽 카드의 성능이 어느 정도 확보됐다고 파악된 시점에 해당 제조업체와 공동의 마케팅을 펼치는 것은 그동안 여러 차례 실패를 교훈삼아 만들어낸 결과라고 할 수 있다.

공식적인 판매 일정을 발표한 구글의 크롬북은 이전의 네트워크 컴퓨터나 인터넷 접속기와 비슷한 개념인 것 같지만 아이패드와 같은 스마트패드가 익숙한 세대를 위한 디바이스로 안착할 수 있을지 많은 기대를 모으고 있다. 안정적인 제조업체의 지원과 기업용 시장에서 기존 솔루션들을 크롬 기반으로 제공할 수 있는 목록을 확보하고 있음을 발표해 크롬북을 가지고 무엇을 할 수 있는지 명확하게 보여주고 있다.

Write once, run everywhere
‘Write once, run everywhere’라는 표현은 자바의 크로스 플랫폼 지원을 가장 잘 표현하는 문구로 알려져 있다. 물론 자바 자체의 아이디어보다는 그 이전에 만들어진 아이디어를 인용한 것이다. RIA 플랫폼 중에서도 이런 개념을 일찍이 사용한 오픈소스 플랫폼이 있었는데 바로 오픈라즐로(OpenLaszlo)가 그 주인공이다. 2000년대 중반부터 하나의 애플리케이션이 웹브라우저뿐 아니라 주요 운영체제에서 동작하고 데스크톱 클라이언트 단독으로 실행하거나 모바일 디바이스까지 지원할 수 있는 개념을 만들어놓고 있었다. 국내에서도 오픈라즐로 기반으로 쇼핑몰이 만들어졌고 커뮤니티가 어느 정도 활성화될 듯 보였으나 오픈소스 자체에 대한 신뢰가 부족했고 타 플랫폼에 비해 빠른 대응을 하지 못해 국내에서는 더 이상 레퍼런스나 자료를 찾기 힘들게 됐다. 하지만 2007년 4.0 버전을 발표하면서 하나의 애플리케이션을 플래시와 DHTML로 컴파일할 수 있는 구조를 만들었다.

<그림 3> 오픈라즐로

얼마 전 애플에서 플래시에 대한 이슈를 제기했을 때 Gliffy라고 하는 웹 기반 다이어그램 도구를 서비스하는 회사에서는 플래시를 지원하지 않더라도 오픈라즐로 기반으로 애플리케이션이 구성되어있어 언제든지 어떤 디바이스든 서비스를 할 수 있다는 글을 블로그에 남기기도 했다(하지만 아직까지 별도의 아이패드용 앱이나 사이트를 제공하지는 않는다).

오픈라즐로가 이렇게 멋진 개념에도 불구하고 성공을 하지 못했던 이유는 워크플로우를 사로잡지 못했다는 것이 가장 큰 벽이었다. 기획 → 디자인 → 개발 → 테스트로 이어지는 가장 대중적인 개발 프로세스에서 모두가 만족할 수 있는 도구를 제시하지 못한다면 쉽게 받아들여지지 않는다. HTML5가 등장하면서 몇몇 업체에서 기존 콘텐츠를 HTML5로 변환하는 기술이 등장했다. 이런 기술은 초기에 흥미를 유발할 수 있겠지만 임시적인 방편일 뿐 그 자체가 프로세스가 될 수는 없기 때문에 크게 주목받지 못하고 있다. 변환 기술보다는 하나의 코드로 관리할 수 있는 오픈라즐로의 접근 방식을 택한 기업들은 비교적 안정적인 코어(최근 방송을 타고 있는 운동 가이드 프로그램에서 몸의 중심을 잡는 속 근육을 나타내는 말이다. 플랫폼에서도 마찬가지로 중심을 잡아 줄 수 있는 무언가가 필요하다)를 가지고 있기 때문에 장기적으로 유연한 정책을 택할 수 있으며 환경의 변화에 쉽게 적응할 수 있다.

어도비 역시 오픈 스크린 프로젝트를 기반으로 everywhere와 비슷한 anywhere라는 이슈를 내세우고 있다. 작년 5월 어도비 사이트에는 공동창립자이며 이사회 회장인 척 게쉬케(Chuck Geschke)와 존 워녹(John Warnock)의 글을 보면 ‘모바일 디바이스의 수가 컴퓨터의 수를 앞지르게 될 것이며 모든 사용자가 퍼블리셔가 될 수 있고 콘텐츠를 언제 어디에서나 액세스할 수 있는 등 웹이 지향해야 하는 미래’라고 표현하면서 개방적인 시장 안에서 웹상에서 제공하는 선택의 자유를 누릴 수 있게 해야 한다고 주장하고 있다. 최근 공개된 CS5.5 버전에서는 모바일 개발 지원 대상을 확대하고 다양한 시나리오에 따른 효율적인 워크플로우를 제공하고 있어 이러한 주장을 뒷받침하고 있다.

하지만 anywhere에서의 경험이 모두 동일한 것은 아니다. 현재 제공되고 있는 플래시 플레이어 10.3이 동작하려면 안드로이드 2.2 버전을 지원해야 하며 특정 기준에 적합한 디바이스를 필요로 한다. 어도비에서는 내부적으로 DCTS(Adobe Device Certification Test Suit)를 거치도록 제안하고 있다. 그럼에도 플래시 플레이어와 같은 하나의 인터페이스를 유지할 수 있다는 것은 최대 강점이 될 수 있다. 물론 잦은 버그나 보안 이슈로 인해 플래시 플레이어의 코드를 개방하라는 압력을 받고 있지만 단편화를 막기 위해서라도 플레이어만큼은 놓지 않을 것이다.

<그림 4> Pidion 산업용 단말기

엔터프라이즈에서 HTML5
기업 내부 사용자들이 활용하는 디바이스가 다양해지면서 예전처럼 통제하기가 어려워졌다. 단체로 디바이스를 구매하고 개발 시 해당 디바이스가 표준이 될 수 있었던 시절에는 요구사항에 대한 수용이 어느 정도 가능했다. 하지만 최근의 상황은 1년에도 몇 차례 새로운 디바이스가 선보이면서 예전처럼 최적화된 요구사항에 대한 수용은 불가능해졌다.

얼마 전 SAP에서 진행된 기술 컨퍼런스에서 ‘대기업들은 2년 뒤면 비즈니스 소프트웨어를 여러 단말기 환경에서 제공하기 위해 대부분 HTML5를 사용할 것’이라는 발언이 나왔다. 그리고 구글 크롬북 프로젝트에 SAP을 비롯한 비즈니스 벤더들이 깊이 관여하고 있어 이러한 발언을 뒷받침해주고 있다. 이런 이야기가 언론에 노출되면 많은 이들이 기업용 시장도 HTML5로 가야겠다 싶어 모든 걸 버리고 HTML5에 올인할 수도 있다.

이미 웹기반으로 그룹웨어를 서비스하는 몇몇 업체들은 모바일 기반 서비스를 제공하고 있다. 간단한 인증만으로 이메일, 일정관리, 결재 등의 항목을 통합 관리할 수 있도록 서비스를 제공하고 있다. 첨부된 파일을 직접 열어볼 수 없는 경우에는 이미지로 변환해서 보여주거나 팩스나 인터넷 전화를 연동할 수 있는 기능을 제공한다. 하지만 동일한 서비스를 받고 있다고 할지라도 모바일 디바이스의 종류에 따라 제공되는 서비스가 달라질 수 있다. 예를 들어 ‘실시간 알림 서비스는 갤럭시 S에서만 지원됩니다’와 같은 안내문이 제공된다면 분명히 디바이스에 따라 사용자 경험이 달라질 수 있다는 것이다. 모바일 디바이스에서 결재를 진행할 수 있다는 것은 동일하지만 새로 받은 메시지를 즉시 확인할 수 있는지의 여부는 업무 성격에 따라 무척 중요한 목적이 될 수 있다.

무엇을 하고 싶은지에 대한 질문을 던져보면 기업 내에서 HTML5를 어떻게 수용해야 할지 다시 한 번 고민해보게 된다. 바코드 리더기를 생각해보자. 최근 유행처럼 사용하는 QR 코드는 대부분의 스마트폰 카메라로 인식할 수 있다. QR 코드만이 아니라 바코드 역시 내용을 인식하고 특정 상품 정보를 바로 보여주기도 한다. 그럼 기존 바코드 리더기를 스마트폰이 대체할 수 있을까? 대체는 할 수 있겠지만 하고 싶은 것은 아닐 것이다. 길을 지나가다가 영화포스터를 보고 포스터에 있는 QR 코드를 인식해서 정보를 보는 것은 가능한 일이지만 마트에서 물건을 계산하기 위해 스마프폰의 카메라를 동작시키고 코드를 인식시켜 데이터를 단말기에 연동시키는 것은 결코 추천할만한 일은 아니다.

기업 내 시스템의 복잡성도 새로운 기술의 도입을 어렵게 하는 측면이 있다. 브라우저에서 HTML5 기술을 적용하기 위해서는 IE9 이상의 브라우저가 설치되어야 하고 이를 위해서는 윈도우 비스타 이상의 운영체제로 업그레이드가 되어야 한다. 하지만 기존에 사용하던 장비(더 이상 생산되지 않으며 당장 다른 것으로 대체할 수 없는)에서 지원하는 운영체제가 XP까지라면 어떻게 해야 할까? IE외의 다른 브라우저를 선택할 수 있겠지만 그 또한 다른 시스템의 제약 때문에 어려울 수 있다. 일반 사용자는 몰라서 새로운 기술을 받아들이지 못한다면 기업 사용자는 여러 가지 제약으로 새로운 기술을 만나지 못할 수 있다는 것이다.

그럼에도 미래의 환경에서는 HTML5를 좀 더 자연스럽게 받아들일 수 있을 것이다. 이를 위해 많은 기업들이 기존의 기술과 어떻게 적용하고 융합시킬지 고민하고 있다. 당장은 하나로 합치기 어려우니 선택하는 것이 하이브리드라는 전략이다.

하이브리드가 최선의 선택일까?
하이브리드는 잡종이나 혼합물을 의미하는 단어이다. 비슷한 단어로 퓨전이란 단어도 많이 사용이 된다. 서로 같은 의미인 것 같지만 차이가 있다. 하이브리드는 특정한 목표를 달성하기 위해 두 개 이상의 요소가 함께 공존하는 것이다. 최근 출시되는 자동차 중에서 많이 들을 수 있는 것이 하이브리드이다. 아예 ○○ 하이브리드와 같은 식으로 제품이 출시되기도 한다. 주행 상태에 따라 가솔린 기관과 전동 기관이 적절하게 작동하는 것이다. 하이브리드 자동차는 탁월한 연비와 배출가스 감소, 가속성, 승차감 등의 장점을 가지고 있으며 여러 업체들의 선의의 경쟁으로 하이브리드가 가지는 단점을 지속적으로 보완하고 있다. 퓨전은 서로 다른 물체가 녹아 처음과 전혀 다른 특성을 보이는 것이다. 이전과 전혀 새로운 기능이 생기는 것이다. 융합 기술이라고 이야기하는 것들과 퓨전 음악에 사용되는 악기나 음악 자체를 이야기할 수 있다.

<그림 5> 하이브리드 자동차 작동원리 - http://k5.kia.co.kr

모바일 애플리케이션 개발에서 하이브리드를 이야기하는 것은 기존의 콘텐츠 개발 기술을 그대로 활용하면서 디바이스의 기능을 활용하려는 특정한 목표를 달성하기 위해 두 가지 기술을 적절하게 조합시키려 하기 때문이다. 하이브리드 애플리케이션 개발을 지원하기 위한 API를 공통으로 사용할 수 있으며 개발자는 콘텐츠와 비즈니스 영역에 좀 더 집중할 수 있게 된다.

투비소프트의 엑스플랫폼도 하이브리드형 통합 개발 플랫폼을 표방하고 있다. 데스크톱, Ajax, 모바일 애플리케이션 개발을 하나의 플랫폼에서 구현하고 적절하게 배치할 수 있는 구조를 제시하고 있다. 하나의 프로젝트 내에서도 필요한 업무 요구사항에 따라 적합한 기능을 제안할 수 있다. 웹의 미래는 HTML5인데 HTML5만 가지고 구현하면 안될까? 물론 가능하다. 하이브리드 차량 역시 하이브리드 따위는 버리고 전기만으로 움직이는 자동차를 만들면 된다. 전기 자동차는 아직까지 배터리를 최적화하는 이슈가 남아있다. 조만간 다가올 미래의 선택은 전기 자동차가 될 수 있지만 현재 가지고 있는 것을 기준으로 보았을 때 효율적인 선택은 하이브리드라는 것이다. 개발 플랫폼에 있어서 하이브리드도 마찬가지이다. Ajax나 HTML5 기술을 기반으로 구현할 수 없는 것이 아니라 그에 따른 비용, 성능, 최적화, 외부 기기와의 연동 등과 같은 다양한 이슈가 있을 수 있다는 것이다. 다시 한 번 강조하지만 가지고 있는 것이 무엇인지, 하고 싶은 것이 무엇인지 생각해보아야 한다.

여러 가지 논란 속에서도 빛을 내고 있는 TV 프로그램 중에 ‘나는 가수다’라는 서바이벌 프로그램이 있다. 흥미롭게도 시청자의 관심은 서바이벌 자체보다도 ‘같은 노래가 저렇게 다가올 수 있구나’라는 놀라움이다. 같은 코드를 가지는 노래지만 편곡 과정과 어떤 가수를 만나는지에 따라 전혀 다른 노래로 다가오기도 한다. 그럴 때면 이 노래는 이 사람이 불렀어야 하는데 하는 아쉬움을 이야기하기도 한다. 하지만 ‘적합한’이라는 말은 기술이 사용되는 시점의 여러 가지 맥락에 영향을 받는다는 것을 잊지 말아야 한다. 오래 전에 촬영된 뮤직비디오를 지금 보면 우습게 보이겠지만 그 당시에는 얼마나 그 모습에 열광했었는지 기억해보자. 지금 우리 팀이 가지고 있는 것과 하고 싶은 것을 다시 한 번 생각해보자.

▣ SW 개발방법론의 함정 - .NET/OOP - 2011. 7. 18. 10:58

출처 : http://butterflyland.co.kr/entry/%EC%A0%84%EA%B7%9C%ED%98%84-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C%EB%B0%A9%EB%B2%95%EB%A1%A0%EC%9D%98-%ED%95%A8%EC%A0%95

[전규현]소프트웨어 개발방법론의 함정

월간 마이크로소프트웨어 제공

2009.11.29 / PM 06:08

[지디넷코리아]체계화된 프로세스와 산출물들로 무장한 개발방법론은 회사에 필요한 이상적인 무기를 제공해줄 것 같지만, 개발방법론을 도입해 크게 효과를 본 회사를 찾기는 쉽지 않다. 개발방법론이 개발을 더 지연시키고 개발자들을 번거롭고 힘들게 한다고 하기도 하고 개발방법론을 도입해서 사용하다가 포기하고 다른 방법들을 기웃거리기도 한다. 왜 이렇게 성공적으로 개발방법론을 도입하는 것이 어렵고, 개발방법론을 효과적으로 소프트웨어 개발에 적용하기 위해서는 어떻게 해야 하는지 알아보자.

독자들 중에서도 개발방법론들을 경험해 본 사람들이 꽤 있을 것이다. 실제로 개발방법론을 경험해 봤다면 그 개발방법론이 실제 소프트웨어를 개발하는 데 얼마나 도움이 되었는지 묻고 싶다. 즉, 이전에 나름대로의 방법으로 알아서 개발하던 때와 비교하면 얼마나 나아졌는지 묻고 싶다. 진짜 개발이 더 빨라지고 생산성이 높아졌는지? 아니면 개발은 오히려 느려졌고 과거보다 번거로울 뿐이지만 그래도 문서를 남겨야 나중에 정보 공유가 가능하니까 따르는 것인지 묻고 싶다.

필자는 소프트웨어 개발 컨설턴트로서 여러 개발자들이 이러한 질문에 답변하는 내용을 들을 기회가 많다. 그 중에 개발방법론은 고객이 요구하기 때문에 어쩔 수 없이 적용한 경우가 많았고, 실제로 개발하는 데는 필요도 없는 문서를 많이 만들어야 했으며, 그로 인해 개발에 더 많은 시간이 소요되었다는 얘기를 종종 듣게 된다. 하지만 회사에서 시키기 때문에 억지로 하곤 한다고 말한다. 시중에 개발방법론은 넘쳐나는데 왜 개발방법론을 적용해 큰 효과를 봤고 개발 생산성이 크게 향상되었던 경험을 접하기가 어려운 것일까?

■개발방법론은 필요하다

회사가 작을 때는 소프트웨어를 개발하는 데 있어서 대부분 확실한 개발 체계 없이 시작한다. 대부분의 경우 이렇게 주먹구구식으로 또는 가내수공업 형태로 소프트웨어 개발을 시작해도 별 문제가 없다. 체계가 없다는 것은 소프트웨어를 개발하는 데 문서를 제대로 만들지도 않고, 정형화된 프로세스 없이 개발자들의 경험에 의해 주먹구구식의 절차를 통해 별도의 개발 시스템 없이 순전히 개발자들의 기억력과 약간의 기록만 가지고 개발하는 것을 의미한다.

그렇게 개발하더라도 대부분 큰 문제에 봉착하지 않는다. 대부분의 정보라는 것도 그리 방대하지도 않아서 개발자들의 머릿속에 잘 저장되어 있고, 시스템도 그리 복잡하지 않아서 몇몇 소수의 개발자들이 머리를 맞대고 개발해도 별 문제가 없다. 또 충성심 가득한 개발자들은 회사에 언제까지나 있을 것 같고, 문제가 발생하면 특공대처럼 문제를 빠르게 해결한다.

이러한 시기에는 오히려 주먹구구 방식이 훨씬 빠르고 비용이 적게 든다고 생각할 수 있다. 실제로 이런 개발 방법이 여타 개발방법론을 적용한 개발 방법보다 효율이 더 높은 경우도 있다. 소수의 개발자에게 너무 많은 부분을 의존하고 있는 이런 방식은 장점인 것처럼 보이지만, 사실은 대단히 큰 위협요소가 된다.

성장하는 회사는 조직이나 소프트웨어의 규모가 점점 커지고, 개발해야 하는 제품의 수와 개발자는 점점 늘어가고, 더 이상 주먹구구식으로는 개발이 어려워진다. 회사는 점점 성장하는데 여전히 주먹구구식으로 개발하고 있다면 개발 과정은 점점 혼란스러워지고 설상가상으로 대부분의 정보를 머릿속에 담고 있는 개발자가 퇴사를 하기도 한다.

개발방법론은 이렇게 소수의 개발자에 편중되어 있는 대부분의 리스크를 시스템적으로 커버할 수 있도록 한다. 문서도 만들어야 하고, 프로세스도 따라야 하기 때문에 당장에는 기존의 주먹구구식의 방식보다는 시간도 많이 들어가고 비용도 많이 들어가는 것처럼 보이지만, 그 대가로 리스크를 줄일 수 있다.

모험심이 가득한 벤처 회사라면 얼마든지 리스크를 감수할 수 있겠지만, 회사가 점점 커지면 리스크보다는 비용을 선택하게 되어 있다. 따라서 주먹구구식으로 시작한 소프트웨어 회사라도 규모가 커지면 자연스럽게 개발방법론에 눈을 돌리게 된다.

이렇게 개발방법론을 시도해보기 위해 개발방법론 도입을 도와주는 컨설팅회사에 의뢰를 하기도 하지만, 대부분은 인터넷이나 책을 통해 개발방법론을 배워보려고 시도한다.

■개발방법론을 공짜로 배울 수 있을까?

개발자들은 인터넷에서 수많은 소스 코드 샘플을 보고 개발에 활용해 왔듯이, 개발방법론도 인터넷에서 특정 개발방법론의 템플릿과 샘플 그리고 프로세스를 가져와서 따라하면 개발방법론을 그럴싸하게 흉내 낼 수 있을 것으로 생각하기도 한다.

하지만 실제로 따라해보면 생각만큼 잘 되지 않는 것이 사실이다. 일단 기존에 주먹구구식으로 개발하던 개발자들은 개발방법론에서 제시하는 템플릿을 보게 되면 생전 처음 보는 내용도 많을 뿐더러 왜 그러한 것이 필요한지 진짜 의미를 이해하기 어렵고, 어떻게 작성해야 하는 것인지 파악이 잘 안 되는 것이 일반적이다. 그리고 이것이 정말로 자신의 회사에서 필요한 것인지 또는 필요 없는 것인지 판단이 안 되기도 한다.

그래서 일단 이것저것 시도를 해보고 효과가 신통치 않으면 나중에 “그거 해봤는데 별로더라”라는 자신만의 편협한 평가를 내리기도 한다. 이러한 서투른 시도는 개발방법론에 대한 나쁜 인식만 키워주기 때문에 아니 한 만 못하다.

여러 개발방법론에서 제시한 문서들이 작성하기 부담스럽다고 문서를 적게 작성해도 된다는 XP, 애자일(Agile) 등에 쉽게 눈을 돌리곤 하는데, 이 또한 너무 쉽게 접근해 실패하는 경우도 많다. XP 방법론이 모든 종류의 소프트웨어를 커버하는 것은 아니지만, 나름대로 적절하게 쓰이면 훌륭한 개발방법론인 것은 사실이다. 하지만, 왠지 간편해 보인다고 만만하게 접근하다간 큰 코 다칠 수 있다.

소프트웨어를 개발하는 데 있어서 가장 어려운 것 중에 하나가 무엇을 만드는지 결정하는 일이다. XP 방법론에서는 이러한 스펙 작성의 어려움을 덜고자 다른 접근을 하는데, 이것이 마치 스펙을 작성하지 않아도 되고, 문서를 적게 만들어도 되기 때문에 개발자들에게는 최고의 개발방법론인 것처럼 생각할 수도 있지만, 그리 만만한 것은 아니다. 스펙 대신 테스트를 이용하고 있지만, 이 또한 공짜로 되는 것은 아니다. 기존에 이미 분석 능력을 가지고 있고, 유닛 테스트(Unit test)에 능통한 경우라면 무리 없이 받아들일 수 있지만, 주먹구구 방식에 익숙한 경우라면 이 또한 어려운 도전이 될 수 있다.

즉, 그냥 쉽게 배우고 프로세스, 템플릿을 좀 익혀서 개발방법론을 제대로 적용해 보기는 어렵다. 공짜로 배워보기에는 개발방법론은 그리 만만하지 않다.

■몸에 맞지 않은 개발방법론이 문제

그렇다고 컨설팅을 통해 개발방법론을 도입하는 경우도 그렇게 쉬운 것은 아니다. 여기에는 몇 가지 함정들이 도사리고 있다. 자칫하면 이론에 치우치기 쉽고 회사의 역량이나 규모에 걸맞지 않은 무거운 개발방법론을 도입하게 되기도 한다. 개발방법론을 도입하려는 회사는 어떤 개발방법론이 자신의 회사에 알맞은지 직접 판단하기 어려우므로 외부의 전문가의 판단에 의존하는데 외부의 전문가가 실전 경험이 부족한 경우 회사의 특징과 역량 수준을 고려하지 않고 거대 개발방법론을 기계적으로 도입할 수 있다.

이 경우 큰 Learning Curve를 겪게 되고 결국 이를 극복하지 못하고 실패할 가능성이 높다. 따라서 자신의 회사에 알맞은 수준의 개발방법론을 선택해야 하는데, 이렇게 몸에 딱 맞는 개발방법론을 선택하는 것도 쉬운 일은 아니다.

또, 개발방법론을 하나 정해 놓고 회사의 모든 프로젝트에서 그 개발방법론을 무조건 따르게 하는 것도 문제다. 모든 프로젝트는 그 성격이 다른데, 하나의 개발방법론을 무조건 따르게 되면 간단한 프로젝트에서도 과도한 비용을 지불해야 한다. 이는 개발방법론이 자칫 관료화되는 것을 조심해야 한다는 뜻이다. 애초에 개발방법론을 도입한 이유를 망각하고 관리자나 프로세스 부서에서는 무조건적인 강요로 효율성을 떨어뜨리는데, 애초에 개발방법론을 도입할 때 유연하게 적용을 할 수 있는 여지를 남겨 둬야 할 것이다.

■방법론의 목적은 효과적인 개발

소프트웨어 개발방법론의 근본 목적은 소프트웨어를 빠른 시간 안에 적은 비용을 들여 요구되는 품질의 소프트웨어를 만들어내는 것이다. 이런 과정에서 개발자들이 혹사되어서는 안 되며 개발자들은 자연스럽게 소프트웨어 전문가로서의 능력이 향상되어야 한다. 즉 프로젝트도 성공하고 개발자에게도 도움이 되어야 진정한 방법론인 것이다.

그렇지 않고 단순히 절차를 지키기 위한 방법론, 개발자는 희생하면서 프로젝트만 어떻게든 성공하기 위한 방법론은 반쪽짜리일 뿐이다. 그럼에 불구하고 개발방법론은 왠지 무겁고 형식적이고 소프트웨어를 개발하는 데 진짜 도움은 되지 않는다는 생각들은 개발방법론 시도 실패에 대한 반작용으로 생겨난 경험담들 때문이다.

■국내 현실은 도 아니면 모

국내 대부분의 소프트웨어 회사는 소프트웨어를 개발하는 방법에 있어서 아래 세 가지의 부류로 나눌 수 있다.

첫째, 주먹구구식으로 소프트웨어를 개발하는 회사. 특별한 프로세스 없이 개발자들의 경험에 의존해 자체적으로 약간의 문서를 만들면서 소프트웨어를 개발하고 있는 회사. 주로 작은 회사들이며 개발자가 100명 이상인 중견 기업들도 상당히 많은 회사들이 이 단계에 머물러 있다.

둘째, 거대 방법론을 도입해서 흉내 내는 회사. 이 경우도 상당수가 내부적으로는 주먹구구이나 형식적으로는 방법론을 따라하고 있다. 주로 대기업에 해당하며 이들 기업은 개발 효율성보다 리스크 감소에 더 관심이 많으며 개발자들보다 회사의 힘이 압도적으로 크므로 추진력 강하게 이러한 개발방법론을 도입할 수 있고, 이러한 무리한 도입 과정에서 벌어지는 비효율성은 개발자들이 요령껏 편법을 이용해 피해가는 경우가 많다. 즉, 내용보다는 형식에 치우친 경우라고 할 수 있다. 이 경우 리스크는 줄어드나 개발 효율성도 따라서 줄어들어 일정 수준 이상을 넘을 수가 없다.

셋째, 거대 방법론이 회사에 맞지 않음을 깨닫고, 다시 주먹구구 개발방법으로 되돌아 온 회사. 그러면서 다른 방법이 없을까 고민하고 있는 회사들이다. 이런 실패의 경험이 반복될수록 내부에 불신이 쌓여가므로 쉽게 새로운 시도를 못하고 주먹구구와 개발방법론 사이를 떠도는 경우이다.

물론 이 세 부류에 속하지 않은 회사들도 있다. 그런 회사들은 스스로를 잘 알고 있으므로 별도로 언급할 필요가 없을 것이다. 그리고 그런 회사는 그리 많지 않다. 첫째와 셋째는 ‘도’에 해당하고 둘째는 ‘모’에 해당하는 경우이다. ‘도’도 바람직하지 않고 ‘모’도 소프트웨어를 개발하는 데 비효율적이다. 가장 좋은 경우는 ‘개’나 ‘걸’처럼 회사의 규모와 개발자들의 역량이 같이 성장해 나가면서 그 단계에서 딱 필요한 것들을 차근차근 하나씩 도입해 나가면서 내재화시켜 나가는 것이다.

■뭐든지 단계가 있는 법

뭐든지 배우려면 그 단계가 있고, 차근차근 배우고 익혀나가야 한다. 예를 들어서 골프를 배우고 싶다면 어떻게 될까? 소프트웨어를 취미로 개발하고 있는 것은 아니므로 골프로 프로 선수가 되는 것을 목표로 삼는 경우를 예로 들어보자.

골프를 처음 배워나가면서 타이거 우즈가 공을 치는 방법이 가장 완벽하다고 해서 그 방법을 그대로 따라하기란 불가능하다. 타이거 우즈가 그렇게 공을 치기까지는 십 수 년의 훈련이 필요했고, 타이거 우즈에 가장 알맞은 방법으로 진화해 온 것이다.

그런데 타이거 우즈가 그 방법으로 세계에서 가장 골프를 잘 치는 사람이 되었다고 그것을 그대로 흉내 내는 것은 어리석은 짓이다. 사실 그대로 흉내 내는 것 자체도 불가능하다. 타이거 우즈와 똑같이 치는 방법을 책을 쓰면 책 한 권은 넘을 것이다.

하지만 타이거 우즈는 그 방법을 일일이 생각하면서 공을 치지 않는다. 그 방법이 몸에 익었을 뿐이다. 그냥 공을 치면 저절로 되는 것이다. 이를 ‘내재화’가 되었다고 한다. 그 최고의 방법을 모델로 놓고 그대로 따라하고 훈련한다고 해서 그 방법을 익힐 수 있는 것은 아니다. 그러한 단계로 가기 위해서는 기초부터 배워나가는 방법이 따로 있을 것이다. 또 우리 몸에 맞는 모델은 타이거 우즈의 방법이 아닐 수도 있다. 그런데 최고의 방법이 타이거 우즈의 방법이라고 따라하는 것은 무리한 시도이며 대부분 포기하게 될 것이다.

진짜 프로골퍼를 목표로 하고 골프를 배우고 있다면 타이거 우즈가 골프를 치는 것을 그대로 따라하는 것이 좋은 방법이 아님을 누구나 알 수 있을 것이다. 재미로 마구 골프를 쳐보다가는 평생 프로선수가 되지 못할 것이다. 누구나 상식적으로 생각해도 아주 기초부터 차근차근 훈련을 받아나가야 한다는 것을 알 수 있을 것이다.

그런데 소프트웨어 세상에서는 이런 섣부른 시도들이 종종 발생한다. 개발자들의 역량은 아직 기초 수준인데 세계 최고의 방법론들을 도입해서 시도하면 개발자들도 저절로 세계 최고의 역량을 갖출 수 있을 것으로 착각하는 것 같다.

■개발방법론이 가르쳐주지 않는 것

개발방법론은 소프트웨어 회사라면 당연히 갖추고 있어야 하는 것은 가르쳐주지 않는다. 즉, 소스 코드를 어떻게 관리하고, 버그는 어떻게 추적할 것이며, 빌드/릴리즈는 어떻게 할지는 크게 상관하지 않는다.

하지만, 이러한 것들이 아직 체계적으로 갖춰지지 않는 회사가 개발방법론을 도입한다고 하면 따라가기만 하는 것도 벅차고 성공적으로 내재화되기는 어려울 것이다. 축구팀이 기초 체력은 갖추지도 못하고 기본적인 드리블이나 슛 실력이 부족한 상태에서, 다양한 전술과 전략을 익혀봤자 말짱 허사일 것이다. 여기서 말하는 기초 역량은 개발자에게 있어서 설계, 코딩 능력을 말하는 것은 아니다.

우리나라 개발자들의 코딩 능력은 전 세계 어디 내놔도 손색이 없을 만큼 뛰어나다. 여기서 말하는 기초 역량은 소프트웨어 회사라만 기본적으로 갖춰야 할 요소들과 설계, 코딩을 제외한 소프트웨어 전문영역의 다양한 지식들을 말한다. 이러한 것들은 워낙 당연한 것들이기 때문에 개발방법론을 만든 사람들은 소프트웨어 회사라만 당연히 보유하고 있어야 하는 것으로 생각한다.

방법론에서는 그러한 것들은 너무나 당연한 것이라 어떤 방법을 사용하든 별 개의치 않는 경우가 많기 때문에, 그러한 기초조차 제대로 갖추고 있지 않은 소프트웨어 회사라면 현재의 수준을 자각하지 못하고 자칫 그럴듯하게 포장된 방법론만 눈에 들어올지도 모른다. 이런 경우 방법론은 공염불이 되기 십상이다. 방법론을 고민하기보다는 기초부터 다져야 하는 경우이다.

■개발자들의 역량

기초란 회사에만 적용되는 것은 아니다. 개발자들도 개발방법론을 따라 개발하기 위해서는 필요한 역량이 있다. 가장 먼저 방법론 하면 산출물이 떠오르는데 대부분의 개발자들은 문서를 작성하는 데 익숙하지도 않고 그보다 먼저 문서 작성을 싫어한다. 이러한 상황에서 템플릿만 잔뜩 제공하고 이를 만들어내라고 하면 보통 괴로운 일이 아니다.

그럼 이쯤에서 의문이 생긴다. 과연 개발자가 문서를 잘 작성한다는 것은 무엇을 말하는 것인가? 개발자들 스스로도 본인이 문서를 잘 작성하고 또 잘 작성할 능력이 있는지 알지 못하는 경우도 많다. 개발자들의 문서 작성 능력을 한번에 알아내기는 어렵지만, 아래와 같은 질문을 해보고 싶다.

소프트웨어를 개발하면서 문서를 만드는 이유가 무엇이라고 생각하는가?

1. 고객이 원해서
2. 나중에 유지보수를 위해서
3. 개발 시간과 비용을 단축하려고

이 중에서 1이나 2라고 답하는 사람들은 아직 문서를 제대로 작성할 능력이 낮을 가능성이 높다. 그 동안 문서를 형식적으로 작성해 왔거나, 문서 작성을 거의 하지 않고 개발을 해오면서 문서는 거추장스러운 것이라고 생각하고 있는 경우가 많을 것이다.

이런 상태라면 개발방법론은 정말 거추장스러운 방해밖에 될 수 없다. 3번이라고 자신 있게 답할 수 있는 사람들은 개발하면서 문서들도 진정 필요한 시점에서 필요한 내용으로 작성했을 것이고, 그렇게 오랜 시간 훈련이 되어 필요한 문서 작성에 능숙할 것이다. 하지만 이렇게 3번이라고 자신 있게 답할 수 있는 개발자들이 많지 않은 것이 현실이다.

방법론에서 만들어내는 수많은 문서들은 문서 자체가 목적이 아니다. 모든 문서들은 다음 작업을 진행하는 데 필요하기 때문에 만드는 것이다. 따라서 다른 개발자들이 내가 만들어 놓은 문서들을 보고 그 다음 작업을 진행할 수 있어야 한다.

즉, 내가 작성한 스펙문서를 보고 설계를 담당한 개발자는 설계를 할 수 있어야 한다. 또 테스트팀은 테스트 계획과 테스트 케이스를 만들어낼 수 있어야 한다. 그리고 기술문서팀(Techpub)에서는 스펙문서만 보고도 매뉴얼을 작성할 수 있어야 한다. 또한 빌드/릴리즈팀에서는 빌드 준비를 할 수 있어야 한다. 하지만, 분석 역량이 부족한 개발자에게 템플릿만 제공해 스펙문서를 만들어 낸들 제대로 설계가 가능하고 테스트 케이스를 만들어 낼 수 없다.

그리고 방법론을 도입하고 약간의 교육으로 그런 수준까지 역량을 끌어올리기는 어렵다. 오히려 거대한 방법은 역량을 차근차근 끌어올리기에는 거추장스러운 옷처럼 방해 요소가 될 수 있다. 차라리 방법론 전체보다는 각 회사에 필요한 기초적인 부분을 추출해 조금씩 적용하는 것이 좋을 것이다. 그러한 과정을 거치면서 개발자들의 역량도 같이 키워나가야 한다.

여기서 필요한 것은 분석, 설계, 프로세스, 형상관리, 테스트 등 개발에 필요한 다양한 것들이다. 이러한 지식과 경험은 하루 아침에 배운다고 익힐 수 있는 것이 아니고, 회사에서 일하면서 조금씩 쌓아 나가는 것들이다. 또한 개발자 혼자서 스스로 익힐 수 있는 것도 아니고, 회사와 같이 개발 업무를 해나가면서 계속 배우고 익혀나가야 하는 것들이다.

■잘못 사용되는 개발방법론

개발방법론을 사용하는 이유가 고객이 해당 개발방법론을 적용하기를 원해서인 경우가 종종 있다. 이러한 경우 고객들도 목적이 개발방법론은 아니지만, 소프트웨어 개발에 대한 전문지식이 모자라므로 회사의 규정에 의해서든 여러 연유로 인해 개발방법론 적용을 요구하게 된다. 이 과정에서 개발방법론을 효과적으로 추려내서 적용하지 못하고 전체를 그대로 적용해 달라고 요청하는 일이 발생한다.

고객은 개발방법론 교과서에 나온 대로 기계적으로 산출물과 프로세스를 요구하고 소프트웨어 개발사는 비효율적인 것을 알아도 고객이 원하므로 울며 겨자 먹기 식으로 무조건 따라야 하는 경우가 많다. 하지만 우리나라 개발자들이 어떤 개발자인가. 모든 난관은 헤쳐 나가는 방법이 있다. 방법론에서 요구하는 문서는 어쨌든 만들어내고 있다.

다양한 편법을 통해 문서를 만들어 내고 있고, 대부분의 경우 문서들이 실제 소프트웨어를 개발하는 데 도움이 되지 않더라도 고객이 요구하는 문서는 충족하고 있다. 이렇다 보니 문서 작업은 소프트웨어를 개발하는 데 도움이 되기는커녕 시간만 축내는 낭비요소가 되곤 한다. 하지만 고객의 요구사항이기 때문에 따르는 수밖에 없다.

그 결과, 이렇게 만들어 낸 산출물은 고객에게도 실제로는 아무런 쓸모없이 책꽂이만 차지하는 경우가 허다하고 개발자들은 방법론에 대한 부정적인 생각만 키워나가게 된다. 이렇게 잔뜩 만들어낸 산출물은 유지보수 시 매우 유용하게 사용될 것으로 홍보하지만, 막상 유지보수 때는 개발에 참여했던 개발자를 찾게 되고 문서보다도 소스 코드를 가지고 유지보수를 하게 된다. 이런 것들이 반복되면 개발자들은 개발방법론이란 형식적이고 실제 소프트웨어를 개발하는 데는 별 도움이 안 된다고 생각하게 되고 진짜 제대로 된 방법을 더욱 더 배우기 어렵게 만든다.

■고객의 무리한 개발방법론 적용 요구

개발 회사는 아무리 개발방법론을 효과적으로 적용하려고 해도 이렇게 고객이 기계적으로 또는 규정에 의해 무리하게 개발방법론을 요구하는 경우에는 어쩔 도리가 없다. 실제로 고객이 개발방법론을 콕 찍어서 **CBD 또는**OOP 방법론을 요구하기도 하는데, 고객을 잘못 만나면 30~40종류 이상의 산출물을 에누리 없이 만들어 내야 하는 경우도 있다. 또 마일스톤마다 산출물을 검사하기도 하기 때문에 프로젝트가 끝나고 밤샘해서 산출물을 만들어 낼 수도 없는 노릇이다.

이러한 경우에는 진짜로 소프트웨어를 잘 개발하기 위해 필요한 문서와 고객의 요구 때문에 어쩔 수 없이 만들어야 하는 문서를 구별할 필요가 있다. 사실 웬만한 규모의 소프트웨어까지는 주요 문서 2, 3개로 충분히 프로젝트를 진행할 수 있고, 그 외의 문서들은 가능하면 최소한의 노력으로 고객의 요구를 만족시켜주는 수준으로만 만들어주는 것이 가장 효율적일 것이다.

이러한 상황에서 진짜 개발에 필요한 문서와 고객의 요구 때문에 어쩔 수 없이 만드는 문서의 구별이 없다면 자칫 모든 문서가 형식적으로 작성될 수도 있다. 이 과정에서 개발자들은 모든 문서에 대한 거부감만 커지고, 방법론을 제대로 적용한 것 같지만 실제 개발은 주먹구구와 다름없게 될 수도 있다. 아니 오히려 주먹구구에다가 문서를 잔뜩 만들어야 하므로 주먹구구만도 못한 경우가 될 수도 있다.

■방법이 목적인 개발방법론

이쯤 되면 개발방법론이 진짜 필요한 것인지 오히려 개발을 방해하는 것인지 헷갈리기도 한다. 하지만 서두에서 말했다시피 개발방법론의 목적은 소프트웨어를 적은 비용으로 짧은 시간에 효과적으로 개발하는 데 있다. 하지만 개발방법론을 만든 사람들의 진짜 목적은 돈을 버는 것이다. 방법론을 팔아서 돈을 버는 회사들은 자신들의 개발방법론을 비싸게 많이 팔아야 한다. 그리고 누구나 쉽게 흉내 낼 수 없게 만들어야 한다.

그래서 자신들의 개발방법론을 다른 방법론들과 차별화하기 위해 노력하고 점점 복잡하게 만들게 된다. 그래야 아무나 따라할 수 없게 되고 또 더욱 비싼 값에 팔 수 있다. 이러다 보니 소프트웨어 업계에는 소프트웨어를 개발하는 수많은 개발방법론들이 넘쳐나고 점점 복잡해지고 있다. 그 반작용으로 간단하다고 어필하고 있는 개발방법론이 출현하기도 한다.

이렇게 되니 대부분의 개발방법론 자체가 잘못된 것은 아닐지라도 우리 회사에 알맞은 개발방법론을 찾기란 쉬운 일이 아니게 돼 버렸다. 오히려 잘못된 함정에 빠지기 쉬운 상황이 된 셈이다.

특히 이전에 어느 정도 경험과 기초가 되어 있는 회사들은 개발방법론을 바라볼 때 어느 정도의 판단 능력을 가지고 자신의 회사에 필요한지 그렇지 않은지 판단할 수 있겠지만, 주먹구구에서 시작한 대부분의 소프트웨어 회사들은 그저 혼란스럽기만 할 것이다.

■어떻게 해야 하나?

필자의 경험에 의하면 국내의 많은 소프트웨어 회사들은 거대 개발방법론을 당장 도입하기에는 아직 적당한 상황이 아니다. 개발방법론을 거론하기 이전에 소프트웨어 회사라면 필수적으로 갖춰야 할 조직과 시스템을 먼저 갖추고 회사에 필수적인 프로세스를 만들어가면서 회사와 개발자 모두 필수 역량을 갖출 때쯤 그리고 회사가 좀 더 크고 복잡해지면 방법론을 생각해보는 것이 좋겠다.

또, ‘자전거’를 만드는 회사에서 ‘우주선’을 만드는 방법론을 사용해서는 안 된다. ‘자전거’ 정도의 소프트웨어를 만드는 수많은 국내 소프트웨어 회사들은 거대 개발방법론이 필요하지 않다. 고객이 요구해서 방법론을 꼭 적용해야 하는 경우가 아니고 자체적으로 소프트웨어를 잘 개발하는 것이 목적이라면, 회사에 알맞은 작고 가벼운 개발방법론이면 충분할 것이다.

럼 소프트웨어 회사가 갖춰야 할 필수 역량에는 무엇이 있는가? 가장 먼저 소스 코드 관리시스템, 버그 관리시스템, 빌드 자동화 등 기본적인 인프라스트럭처 시스템들은 갖춰야 한다. 물론 이것이 그렇게 쉬운 것은 아니다.

실제로 이들을 사용하는 많은 회사들이 기본적인 기능만 사용하고 있음에도, 전혀 이런 시스템들의 도움을 받지 않고 소프트웨어를 개발하고 있는 회사들보다는 훨씬 나은 형편이다. 이런 시스템들을 사용해 개발하다 보면 자연스레 그러한 시스템들에 묻어 있는 소프트웨어 개발 철학을 익히게 되고 기본적인 개발 프로세스도 배울 수 있게 된다.

또, 조직적인 측면으로는 소프트웨어 개발에 필수적인 전문 조직이 기본적으로 필요하다. 대부분의 소프트웨어 회사는 처음 시작하게 되면 개발자들이 전문성을 가리지 않고 온갖 일들을 다하게 된다. 개발도 하고 테스트도 하고 고객지원도 하고, 심지어는 영업을 하기도 한다.

하지만 회사의 규모가 커져 가는데 소수의 개발자들이 개발하던 방식과 똑같이 개발하고 있다면 효율성은 점점 떨어져 간다. 이럴 때는 꼭 필요한 부분부터 전문화된 팀으로 구분하고 전담자를 둬서 해당 분야의 전문성을 높이고 개발자는 개발에 집중할 수 있도록 해줘야 한다. 이러한 대표적인 분야는 테스트와 빌드/릴리즈다. 아직도 테스트를 전적으로 개발자들이 담당하고 있는 회사들이 많다.

개발자 10명만 있는 조직보다는 개발자 7명과 테스터 3명이 있는 조직이 더 효율적인 경우가 많다. 개발자들은 자신이 개발한 소프트웨어를 잘 테스트하지도 못하는데, 해당 소프트웨어의 스펙을 상세히 아는 사람이 개발자 밖에 없고 별도의 테스터를 뽑아도 개발자만큼 제품을 알아서 테스트하기 어렵다고 개발자에게 테스트를 계속 맡기는 것은 잘 하지도 못하는 일을 비싼 인건비를 주고 계속 맡기는 것과 같다.

테스트를 별도의 조직에 맡기는 것이 제품의 품질을 더 높여주고 비용 효율적이며 개발자는 개발에 더 집중할 수 있게 한다. 또 이와 더불어 빌드/릴리즈팀은 빌드/릴리즈 과정을 자동화하고 효율을 높임으로써 그 동안 보이지 않지만 많은 비용을 차지하던 것을 절약하면서도 개발을 더 원활하게 진행하도록 지원한다.

이런 회사의 기본 역량 확보와 더불어 개발자들은 문서를 작성하는 능력, 리뷰하는 능력, 분석 능력, 설계 능력 등 개발자들이 갖춰야 할 코딩 능력 외의 필수 능력들을 쌓아 나가야 한다. 이들은 학교에서 배울 수도 없고, 실무를 통해 오랜 시간에 걸쳐서 차근차근 쌓아 나가야 하는 것들이다.

이렇게 기본적인 조직, 프로세스, 시스템을 갖춰나가면 소프트웨어 회사가 내적으로나 외적으로 기본적인 역량을 갖추게 된다. 이쯤 되면 어떤 개발방법론을 접하더라도 이전보다는 조금 더 잘 이해할 수 있게 된다.

개발방법론을 성공적으로 도입하기 위해서는 소프트웨어 회사와 개발자들이 기초 역량을 갖추고 있어야 한다. 회사가 어느 정도 역량을 갖추고 판단력이 생기면 무작정 좋다고 하는 개발방법론을 도입하기보다는 회사의 수준에 알맞은 방법들을 취사선택해서 조금씩 받아들이는 방법을 택하게 될 것이다.

결국 개발방법론의 목적인 소프트웨어를 빠른 시간 내에 적은 비용으로 효율적으로 개발한다는 것에 좀 더 가까워질 수 있다.

[필자소개]
전규현 gracegyu@gmail.com｜데스크톱, 네트워크, 시큐리티 등 다양한 소프트웨어 개발 분야에서 15년 이상의 경험을 쌓았다. 한글과컴퓨터, 안철수연구소 등에서 소프트웨어엔지니어 및 프로젝트관리자로 지냈다. 현재는 소프트웨어 경영/개발 컨설턴트로서 많은 소프트웨어 회사들에게 소프트웨어의 효율적인 개발 방법을 전파하고 있다. 직접 운영하고 있는 소프트웨어 공학 블로그(http://allofsoftware.net)를 통해 효과적이고 실전적인 소프트웨어 공학 경험을 블로거들에게 공유하고 있으며, 저서로 『소프트웨어 개발의 모든 것(페가수스, 2008)』이 있다.

▣ charcodeAT - .NET/JavaScript - 2011. 7. 18. 10:55

출처 : http://blog.naver.com/dreamid?Redirect=Log&logNo=140060917211

javascript에서 charCodeAt()을 이용하여 글자의 code값을 알아낸 후 막아주면 되는거였어!@~!@~!@~!@ 샤방스런..

아스키값만 나오는줄만 알았더만 유니코드까지 10진수로 변경되서 나오는구만.. -_ㅜ 역시 무식하면 수족관 고생..

○ 코드!!

숫자 0~9     => 48~57

영문 대문자 => 65~90

       소문자 => 97~122

한글 가~힣 => 45032~55203

       자음    => 12593~12622

       모음    => 12623~12643

○ 미적거리며 해결 못했던이유!!

키보드 자판에 있는 !~%&*()_+|... 따위들의 특수문자는 일반 아스키코드표가 흔히 있기 때문에 그것만 막아주면 됐지만

ㅁ,ㄴ,ㄷ... 등의 자음선택후 한자버튼 누름시 나오는 유니코드들을 어떻게 막아야 할지 몰랐다. (키포드의 #과 ㅁ+한자+1의 ＃의 코드값은 엄연히 달랐다.)

처음에 한자키를 막으려 했지만, 분명히!!!! 한자키의 키코드가 25번이라고 여기저기 적혀있었지만 내컴퓨터에서 한자키를 눌러서 event.keyCode를 보면 아무 반응이 없었다 -ㅂ-+ (참고로 한/영키도 반응없음.)

두번째로 처음 방법이 안되자 좌절하며 특수기호들을 배열로 만들어서 그 배열에 맞는 값이 있으면 경고창을 띄워주려 했건만..

특수문자가 한두개냐 -_-+ 어느세월에 다 만들어.

○ 해결 소스!!

function chkchar(obj)
{
var chrTmp;
var strTmp  = obj.value;
    var strLen      = strTmp.length;
var chkAlpha = false;
var resString = '';
    if (strLen > 0) {
        for (var i=0; i<strTmp.length; i++)
        {
            chrTmp = strTmp.charCodeAt(i);
            if (!((chrTmp > 47 && chrTmp < 58) || (chrTmp > 64 && chrTmp < 91) || (chrTmp > 96 && chrTmp < 123) || (chrTmp > 44031 && chrTmp < 55203) || (chrTmp > 12592 && chrTmp < 12644)))
            {
                chkAlpha = true;
            }
            else
            {
                resString = resString + String.fromCharCode(chrTmp);
            }
        }
    }
if (chkAlpha == true)
{
  alert("한글,영문,숫자로만 작성해주세요.");
  obj.value = resString;
  obj.focus();
  return false;
}
}

<input type="text" name="nick" onblur="chkchar(this)">

onkeydown일때 함수를 불러들일경우 "강아지★" <-- 즉 맨마직막문자에서 특수문자를 마우스로 선택할경우(ㅁ+한자+5번째문자 마우스로 선택) 처리가 이러나지 않음.

prev | 1 | ··· | 47 | 48 | 49 | 50 | 51 | 52 | 53 | ··· | 110 | next

꿈을 꾸다~!!

티스토리툴바