세계는 지금 애자일한 진화 중

2005년 캘리포니아의 서니베일에 위치한 야후 본사에서 개발자 생활을 시작하면서 애자일이라는 생소한 용어를 처음 접하게 되었습니다. 마침 야후가 전문 컨설턴트를 영입하여 전사적으로 스크럼과 애자일을 도입하기 위한 시도를 하고 있을 무렵이었습니다. 

그때까지만 해도 미국 본사와 15개국의 해외 지사에서 공식적으로 사용하던 SW 개발 프로세스는 PDP(Product Development Process)였습니다. 2002년에 전사적으로 도입되었던 이 폭포수모델 기반의 프로세스가 무겁고 느리다는 이유로 서서히 개발팀들의 외면을 받자 야후 경영진이 고심 끝에 애자일이라는 특단의 조치를 선택한 것입니다.

야후는 2004년 12월 스크럼의 창시자인 Jeff Sutherland를 초청해 산업계에 성공적으로 스크럼을 도입한 사례를 공유한 것을 계기로 2005년 2월에 사내에서 스크럼 파일럿 프로젝트를 시작합니다.

4개의 프로젝트팀이 참여를 희망했고 우선순위에 집중, 자발적인 팀 협업 장려, 고객 참여 확대, 점증적인 제품 출시 등가장 기본적인 스크럼 프레임워크부터 적용이 시작되었습니다. 두 달 뒤 파일럿 프로젝트 팀의 반응은 긍정적이었고 이를 시작으로 점점 더 많은 팀이 스크럼과 일부 XP 프랙티스를 포함하는 야후 애자일을 적용하게 되었습니다.

2005년부터 매년 야후 애자일 지원 부서에서 시행하고 있는 사내 만족도 조사를 살펴보면 해마다 평균 80% 이상이 애자일을 계속 사용하겠다는 긍정적인 반응을 보이고 있습니다.

이처럼 해외 선진국의 경우 중소기업은 물론, 마이크로소프트, 구글, IBM, HP, 모토롤라 등 대부분의 대기업이 일찌감치 애자일을 성공적으로 활용하고 있습니다. 포레스터리서치가 2009년 Q3에 1298명의 IT 개발자를 대상으로 실시한 설문조사에 따르면, 35%의 응답자가 애자일 방법론을, 21%의 응답자가 반복점증 방법론을, 13%의 응답자가 폭포수 방법론을 주로 사용하고 있으며, 나머지 30.6%의 응답자가 정형화된 방법론을 사용하지 않는다고 응답했습니다. 단일 방법론으로 보면 스크럼이 11%로 가장 인기가 높았고 전통적인 폭포수 방법론이 8.4%로 그 뒤를 이었다. 가트너 역시 Gartner Predicts 2010에서 2012년까지 SW 개발 프로젝트의 80%가 애자일 개발 방법론을 사용할 것이라는 다소 파격적인 예측을 내놓았습니다.

최근의 동향은 기존에 사용되고 있는 표준 방법론에 애자일 기법을 효과적으로 접목하는 것입니다. 즉, 프로젝트 참여 인원, 응용 분야, 중요성, 혁신성 등의 프로젝트 환경에 따라 기존의 방법론과 애자일방법론은 공생하는 관계에 있으며 프로젝트 상황에 맞게 위험 수준을 분석하고 그 결과에 따라 이 두 가지 방법론을 적절하게 조합하여 이용하는 전략이 요구됩니다.

애자일은 프로젝트 가시성이 높아 현업에서 부담으로 작용할 수도 있습니다. 하지만 이를 사용해본 개발팀의 과반수 이상이 지속적인 사용을 원하는 이유는, 사람이 기본적인 개발 주체인 소프트웨어 프로젝트에 엄격하고 한정된 프로세스를 적용하기보다는 변화의 가능성을 열어두고 환영하는 애자일 철학이 비즈니스 성공과 더불어 개인 능력의 향상에도 큰 도움을 주기 때문입니다.

그렇다면 국내에서 애자일의 도입과 적용이 늦은 이유는 무엇일까.

외국의 애자일 서적을 보면 애자일 기법을 책에서 가르치는 대로 따르지 말라고 합니다. 그만큼 애자일은 가볍고 유연하며 모든 가능성에 대해 열려있습니다. 그런데 많은 국내 개발자들이 책에서 애자일을 배우고 현업에서 부분적으로 적용을 시도하다가 난제를 만나면 커뮤니티에 와서 공유하는 식의 열악한 투쟁을 지속하고 있습니다. 효과적인 애자일 도입을 위한 전략은

첫째, 적절한 시간, 외부 코치, 교육자료, 내부 지원 그룹 등의 전사적인 지원 계획, 

둘째, 프로젝트 도메인, 규모, 특성 등을 반영한 단계별 도입을 포함하는 유연한 도입 모델,

셋째, 전문성을 갖춘 자발적인 팀에 대한 권한 위임,

넷째, 협업을 돕는 각종 도구의 사용이다. 

2000년대 초반에 국내에 상륙한 애자일이 아직까지도 개발자 커뮤니티와 일부 대기업에서의 실험적인 적용 단계 수준에 머무르고 있는 현실을 보면 전사적 차원의 체계적이고 일관된 지원의 중요성을 다시금 확인할 수 있다.

자세히 보기 →

Product Line Engineering 생산라인 공학

소프트웨어 개발은 거대해지고 복잡한 산업으로 변해가고 있습니다. 대부분의 기업은 이럴 때 자신들이 개발하는 소프트웨어를 특화시키려 노력합니다. 주요 내용은 비용, 품질, 출시 등 동시대에 다양한 산업현장에서 성과를 입증한 조직적이고 완성된 상품을 개발하는 생산라인 공학에 대해 살펴볼 것입니다.

1. 생산라인 공학(Product Line Engineering)의 필요성

기업들은 소프트웨어 유형에 초점을 맞추는 동시에 다양한 고객들의 여러 가지 요구 사항과 복잡한 시장 요소들에 의해 보다 더 넓은 범위로 확대되는 다양한 변화를 함께 반영해야 합니다. 결과적으로 기업들은 생산물들의 다양한 범위를「단순히 시간을 넘어서는 것이 아닌 동시다발적으로」 증가시켜 개발하게 되는 것입니다. 이는 특정한 분야에 의존하지 않는 자연적인 현상으로, 임베디드 시스템에서든 ERP 시스템에서든 마찬가지입니다. 이것은 재사용의 문제로 규정지어질 수 있는데, 그렇다면 우리는 기존의 최적화된 생산품을 위해 개발된 소프트웨어가 새로운 환경에서 완전히 재사용될 수 있을지를 생각해봐야 합니다.

2. 생산라인 공학(Product Line Engineering)이란?

생산라인 공학의 주 아이디어는 시스템적으로 공통적인 생산라인 인프라를 개발하고, 그로부터 반 자동적인 시스템 방식에 의한 다양성을 파생시키는 것입니다. 여기에는 생산라인의 전체를 파악하는 전략적 접근이 요구됩니다. 조직에 이와 같은 방식으로 소프트웨어 개발에 새로운 방향을 제시하기는 쉽지 않겠지만, 결국 이런 경험들은 기업에게 중요한 자산이 될 것입니다.

개별적인 생산을 하는 공학에서 완성된 생산라인 개발로 이루어지는 초점의 변화는 소프트웨어 공학의 모든 레벨에서 중요한 결과를 가져옵니다. 이는 조직과 개발 프로세스, 도구의 종류에 영향을 끼칠 뿐만 아니라 아키텍처, 코딩, 테스팅들이 어떻게 실행되는지를 알 수 있으며, 이러한 영향력은 다음과 같은 원리로 요약될 수 있습니다.

① Minimal duplication

② Strategic Development

③ Variability Management

④ Architecture-centric approach

⑤ Two Life-Cycles

3. 생산라인 공학(Product Line Engineering)의 이점
이와 같은 접근방식은 특히 고객의 입장에서 볼 때 최적의 상황은 아닌 것처럼 보일 수도 있겠지만, 실제로는 소프트웨어 개발 조직과 고객 모두에게 매우 경제적입니다. 생산라인 공학은 넓은 범위에서의 재사용을 유도하고 있어 성공적인 생산라인 조직은 80% 혹은 그 이상의 재 사용률 보이고 있습니다. 이것은 또한 노력과 비용을 절감할 수 있는 요소가 된다. 일부 생산 라인 조직은 평균적으로 50% 이상의 비용절감 효과를 보았고, 이러한 효과는 고객에게도 상당히 환영받고 있다고 밝혔습니다. 이러한 업무의 감소는 또한 시장으로 출시되는 기간이 감소하는 것을 의미하기 때문에 재사용의 높은 수준은 소프트웨어 품질을 증진시키는 직접적인 중요 요소로 나타납니다. 구성요소들은 많은 상품에 공유되기 때문에, 만약 고객에 의해 결함이 발견되면 그들은 공유된 구성요소를 제거함으로써 모든 고객을 위한 품질 향상을 이끌어 냅니다. 결국, 다양한 요소들이 공유되기 때문에 유지보수 활동은 오직 한 번만 실행되는 것입니다. 이러한 이로운 점은 Simens, Nokia, Cummins, Thales 등 많은 대기업뿐만 아니라 크고 작은 적용 도메인 범위를 가지고 여러 설정을 통해 적용되는 중소기업들에서도 성공적으로 이루어져 오고 있습니다.

자세히 보기 →

소프트웨어 아키텍쳐 트렌드

소프트웨어 아키텍쳐는 고수준(high-level)의 소프트웨어 시스템과, 그들 사이의 관계, 그리고 그로인한 특성에 깊이 관련되어 있습니다. 이러한 고수준의 구조는 계산능력, 커뮤니케이션, 그리고 구축을 반영한다. 물론 여기에는 긴급 동작, 성능, 신뢰성, 보안성, 유지보수성과 같은 일반적인 특성들도 함께 포함됩니다.

훌륭하게 디자인된 아키텍쳐는 시스템 설계자가 요구사항의 만족성과 절조있는 공학적 균형(tradeoffs)을 제시할 수 있도록 해줍니다. 그러한 아키텍쳐는 각 컴포넌트들의 동작 분배에 대한 확실한 원리, 개념적 통일성에 대한 원칙 수립, 그리고 시스템의 수명에 걸친 반복작업의 상당한 감소를 제공할 수 있습니다. 또한 아키텍쳐적인 설계 특징과 패턴들을 재사용할 수 있도록 해주고, 생산 라인에 접근함으로써 개발 비용을 감소시키며, 그 시스템의 장래의 유지보수자들을 위한 가이드를 제공합니다. 

지난 10년간 소프트웨어 아키텍쳐를 표현하고 사용하는 방법과 아키텍쳐적 설계의 분류에 있어서 놀라운 발전이 있어왔습니다. 결과적으로 우리는 다음과 같은 뛰어난 테크닉들을 얻어낼 수 있었습니다.

(가) 아키텍쳐를 정확하고 분명하게 문서화하는 테크닉,

(나) 소프트웨어 아키텍쳐가 얼마나 잘 시스템의 주 요구사항을 드러내고 있는 지 결정할 수 있도록 평가하는 테크닉

(다) 아키텍쳐적 패턴과 스타일의 재사용에 대한 테크닉 

(라) 생산 라인과 프레임워크를 생성하는 테크닉

(마) 소프트웨어 엔지니어들이 뛰어난 아키텍트가 되도록 가르치는 테크닉 

이 테크닉들의 대부분들은 성공적으로 그들의 요구사항을 만족시키는 효율적인 시스템을 생성하는데 성공한 조직들의 실제 모습에서 공통적으로 발견됩니다. 그러한 조직들은 "아키텍쳐적으로 성숙합니다".

자세히 보기 →

미래 경쟁력 , 이제부터 SW품질이다

SW품질은 선택이 아닌 필수

IT 융합시대를 살고 있는 지금, 산업경쟁력의 핵심은 하드웨어에서 소프트웨어로 이동했고, 소프트웨어의 융복합화로 산업 환경에 급속한 변화가 진행되고 있습니다. 소프트웨어의 활용분야가 산업 여러분야로 다양해짐에 따라 소프트웨어 품질의 중요성이 더욱 대두되고 있는 현실입니다.

소프트웨어 품질은 발주자가 제시한 소프트웨어의 기능에 대한 요구사항 뿐만 아니라 소프트웨어 운영상황에 대한 내재된 요구사항을 충족할 수 있는 소프트웨어 특성의 총체를 말합니다. 산업에서 소프트웨어의 역할이 다양해짐에 따라, 소프트웨어 품질에 대한 의미도 협의의 의미에서 벗어나 광의의 의미로 해석하고 관리할 수 있는 능력이 필요하게 되었습니다.

소프트웨어 품질의 의미는 고객이 요구하는 성능의 소프트웨어를 공급하는 능력정도인 성능 및 적합 차원의 품질인 협의의 의미로 우선적으로 이해됩니다. 소프트웨어가 주어진 기능을 만족하며 결함없이 운영되는 경우 일차적으로 소프트웨어 품질이 달성되었다고 생각할 수 있습니다. 그러나 최근의 산업 환경은 자동차, 항공기, 의료장비, 통신기기 등 사람이 이용하는 많은 기기가 소프트웨어 활용 없이는 작동하지 않기에, 소프트웨어 시스템은 더 높은 수준의 확실성, 안전성, 보안성, 신뢰성 등을 보장해야 합니다.

소프트웨어는 모든 산업분야에서 비즈니스 수행에 없어서는 안되며 많은 도움을 줄 수 있는 중요한 역할을 수행함으로, 소프트웨어 품질은 그 중요성 및 파급 효과가 매우 중대해졌습니다. 이러한 산업의 변화는 소프트웨어 품질을 소프트웨어의 성능을 신뢰할 수 있고 고객지향 만족 서비스를 의미하는 신뢰 및 고객만족 차원의 광의의 의미로 확대하도록 했습니다.

특정 제품에 소프트웨어의 활용을 통해 고객지향 만족을 위한 새로운 가치와 차별화된 비즈니스 기회가 창출되고, 제품의 완성도 및 신뢰도가 높아짐으로 기업은 소프트웨어 품질 이상의 또 다른 비즈니스 명성을 얻을 수 있게 되는 상황입니다. 최근의 도요타 자동차나 스마트폰 앱스토어가 이러한 상황을 대변합니다.

이제 소프트웨어 품질은 비즈니스의 성공을 위한 선택이 아닌 필수가 되었습니다. 융합 소프트웨어 환경 하에서 비즈니스의 성공 및 부가가치 극대화를 위해서는 소프트웨어의 품질경쟁력이 매우 중요합니다. 소프트웨어를 통한 무한의 가치 창출을 위해 품질 개선을 위한 노력 즉 품질 경영이 필요합니다.

무한가치 SW품질

신뢰할 수 있는 소프트웨어 시스템을 위해서는 소프트웨어 개발과정에서의 결함을 발견하고 제거하는 것 이상으로, 시스템 운영과정 중 발생할 수 있는 부정확하거나 바람직하지 않은 동작을 감지하는 것을 필요로 합니다. 소프트웨어 시스템이 의도한 대로 사용자의 기대를 만족시키며 사용하기에 충분하도록 하기 위해, 기업들은 소프트웨어 개발과정에서 다양한 소프트웨어공학 기법을 적용하여 궁극적으로 소프트웨어 품질을 강화하기 위한 노력을 해왔습니다.

Edsger Dijkstra(1972)가 “시험은 오류의 존재만을 보이는 것이지 오류가 존재하지 않는다는 것을 보일 수는 없다.“라고 한 것처럼 결함이 전혀 없는 시스템은 있을 수 없기에, 결함 제거를 통한 소프트웨어 신뢰 향상을 위해 다양한 측면에서 소프트웨어 공학적 노력이 적극적으로 필요합니다. 소프트웨어 시스템의 품질은 제조업에서의 품질과는 다른 것으로, 고객이 원하는 기능의 만족 뿐만아니라 명세화 되지 않은 비기능적 요소나 모호한 품질특성까지도 만족시켜야만 소프트웨어의 품질이라 할 수 있습니다.

도요타자동차 대량 리콜사태 이후 기업인식 조사 결과에 따르면, 20.6% 기업이 ‘경영방침에 변화가 있었다‘고 답했고, 절반가량인 52.4%는 ’특별한 변화는 없었지만 품질과 안전문제에 대한 인식이 강화되었다‘고 밝혔습니다. 구체적인 경영방침의 변화로는 완성품의 품질？안전관리 활동 강화(52.6%)가 절반 이상을 차지했습니다. 또한 ’이러한 사태가 우리 기업에게도 일어날 수 있다고 보느냐‘라는 질문에 64.4% 기업은 충분히 일어날 수 있다고 대답했습니다. 

자세히 보기 →

소프트웨어(SW)개발은 공학적 접근방법이 필요하다

1. 우리가 사는 세상은 SW공학을 필요로 한다.

지금 우리는 디지털 시대에 살고 있습니다. Smartphone, Facebook, Twitter, Cyworld 등 효과적인 커뮤니케이션 전달수단을 통해 사회 전반적으로 새로운 휴먼 네트워크 문화를 구축하고 있습니다. 이와 같은 디지털 시대 중심에 바로 소프트웨어(이하 SW로 명명함)가 자리잡고 있습니다. SW가 없는 우리의 삶은 상상 할 수 없을 정도로 불편할 것입니다. 이제 SW는 글로벌 경쟁력을 위하여 신경써야 할 핵심자산으로 자동차, 조선, 전자 분야 등 국가 전략산업의 가치혁신을 견인하고 있습니다.

이와 같이 우리의 삶에 필수불가결한 요소로 자리잡은 SW를 개발하는데 있어서 체계적인 절차와 방법이 필요한 것은 당연한 것입니다. 초등학교의 수학 학습과 SW공학을 비교하여 설명해보자. 요즘 어린이들은 초등학교 1학년이면 구구단 정도는 이미 알고 있다고 합니다. 이것은 아이들이 살아가면서 부딪힐 일상에서의 생활 수학에 대한 중요성과 필요성에 대한 교육결과입니다. 이때 가장 중요하게 배우는 것이 수의 개념입니다. 자연법칙인 것입니다. 이를 통하여 우리는 미지의 세계와 보이지 않는 것들에 대한 계산과 예상을 해낼 수 있으며, 더 높은 수준의 과학적용과 경쟁력의 밑거름이 됩니다.

우리의 SW개발 상황들은 어떠한가? 이미 다양한 언어들, 플랫폼, 통신기술, 기기제어기술 등 매우 복잡하고 고난이도의 개발기술들이 존재하며, 개별적인 기술들을 구현하고, 발전시키려는 수많은 노력들을 하고 있습니다. 정보의 규모, 학습할 대상의 규모 면에서, 이미 외워서 될 일이 아닌 것입니다. 체계적인 절차와 방법이 정립된 공학적 개념이 필요한 것입니다. 즉, 초등학교 학생들에게 수의 개념이 필요하듯이, 우리 생활에 깊게 파고든 SW를 위해서는 발주처, SW관련 기업 등 이해관계자들에게 SW공학적 개념이 필요한 것입니다.

지난 1990년대 초반 IT열풍과 함께 SW인력에 대한 양적인 성과를 이루어 냈습니다. 이후 SW관련 취업관문에서 ‘SW개발’은 간단한 ‘XX언어 2주 완성’이라는 책 한권을 보거나, ‘속성 XX개발자 1개월 과정’을 이수하면 할 수 있다고 생각하는 많은 사람들이 있습니다. 이것은 마치 주어진 몇 개의 덧셈 문제를 외우려 노력하는 것과 같습니다. 이렇게 출발한 SW개발은 결국 수많은 시행착오와 반복되는 작업, 결과적으로 통제가 불가능한 SW개발 상태, 즉 SW위기를 초래하기가 쉽습니다.

또한 우리는 SW개발 과정 속에서 단순 반복적인 일들과 복잡하고 방대한 작업들의 비효율적인 대처 방법에 대하여 의문을 갖게 됩니다. 체계적으로 접근해서 보다 빠르고, 신뢰성 있는 개발 결과물을 도출하고 싶은데, 현실은 항상 납기 시간에 쫓기면서 비효율적으로 작업을 하고 있는 것입니다. 이와 같은 것을 극복하기 위하여 SW공학이 존재하며, SW공학은 SW개발 프로젝트의 품질과 생산성을 높이기 위한 뼈대가 되는 것입니다.

유비쿼터스 시대에 살고 있는 우리는 생활 곳곳에서 SW를 이용하고 있으며, 우리 생활의 일부분으로 자리잡은 SW의 품질과 생산성을 높이기 위해서 SW공학 적용은 선택이 아니라 필수인 것입니다. 즉, 우리가 사는 세상은 SW공학을 필요로 하는 것입니다.

2. 이제 SW공학의 세계로…

SW공학이란 용어는 1960년 후반에 ‘SW 위기’라는 것을 토론하기 위해서 열린 국제 회의에서 제안되었습니다. 3세대 컴퓨터 하드웨어의 소개로 이전의 시스템 개발 방법을 큰 SW시스템에 적용하는 것이 불충분하게 되면서 SW 위기가 대두되었던 것입니다. SW공학은 컴퓨터 시스템들의 SW를 개발하는데 필요한 방법, 도구에 관심을 두고 있다1). 좀 더 SW공학을 이해하기 쉽게 방송 제작 프로세스와 SW개발 프로세스를 비교하여 설명하면 다음과 같습니다.

모 방송사의 인기 버라이어티 프로그램의 제작과정을 한번 살펴보자. 제작진과 출연진이 구상한 프로그램의 각 코너들은 자체적으로 수많은 검토와 검증, 리허설을 거쳐 무대에 오르게 됩니다. 무대에 오르게 된다고 해도 반드시 방송에 나가는 것은 아닙니다. 현장의 반응을 살펴 바로 편집되는 경우도 있으며, 방송 후에는 시청자의 반응에 따라 코너가 폐지되기도 하고 반응이 좋을 경우 새롭게 다듬어져서 장수코너로 자리 잡기도 합니다. 장기간 제작진과 출연진이 끊임없이 바뀌어 왔지만 인기프로그램으로 존속할 수 있는 이유는 바로 이러한 체계를 엄격하게 유지해 왔기 때문이라고 볼 수 있습니다.

3. 우리의 미래는 SW공학이다

앞에서 SW 중요성을 반영하여 SW공학의 실체를 설명하고자 하였으며, SW공학의 필요성, 우리나라와 선진외국과의 SW공학 수준 차이, SWEBOK의 소개, SW공학 기술 적용 성공사례를 통해 SW공학에 대하여 체계적으로 접근하고자 하였습니다.

그 동안의 수많은 SW 개발 프로젝트를 통해 성공사례와 실패사례가 존재합니다. 우리는 지속적으로 SW공학을 적용하지 못해 실패한 SW개발 프로젝트들을 쉽게 찾아 볼 수 있습니다. 이들 사례를 보면, 비용, 기간 등 현실적인 문제 때문에 SW공학 적용이 결코 쉬운 것만은 아니다. 그러나, 장기적인 관점에서 SW개발비용 절감, 적기개발, 품질개선을 위해서 SW개발 프로젝트에서 SW공학을 적용해야 하는 것도 주지의 사실입니다. 이에 발주자 측면, 기업 측면, 인프라 측면에서 SW개발 시 효과적인 공학 적용 방향에 대하여 정리하면 다음과 같습니다.

첫째, SW개발기업 뿐만 아니라 발주자도 SW공학 사상을 인지하고 성공적인 SW개발 프로젝트가 되기 위해서 SW요구사항 제시부터 SW인수까지 양질의 SW가 생산되도록 노력해야 합니다.

둘째, SW개발 및 유지보수 관련 기업은 지속적인 SW공학 적용에 대한 의지가 반드시 필요하다. 또한, 선행 SW프로젝트의 시행착오 결과를 평가하고 정리한 후 후행 SW프로젝트에서 효율적으로 대처해야 할 것입니다.

셋째, 인프라 측면에서 효율적인 방법론, 자동화된 도구를 사용해야 한다. 복잡해지는 SW아키텍처 특성과 프로젝트 환경을 고려한 SW 개발방법론 및 프로젝트 관리방법론을 적용해야 하며, 자동화된 도구 활용을 통해 SW 컴포넌트의 재사용성을 증대시키고 SW개발 생산성을 향상시켜야 합니다.

자세히 보기 →

사용자 관점의 솔루션 개발 방법과 사례

소프트웨어 개발방법론을 사용하는 대부분의 프로젝트는 사용자의 요구사항을 받아 분석하고 설계한 후, 개발하는 프로세스로 진행된다. 개발방법론은 폭포수 모델에서 OO(Object Oriented) 개발방법론, CBD(Component Based Development) 개발방법론 등으로 계속 발전되었지만, 큰 형태는 요구사항 분석(Requirement Analysis), 분석(Analysis), 설계(Design), 개발(Development), 구현(Release)으로 구성되어 있는 폭포수 모델을 바탕으로 하고 있t습니다.

 이러한 개발방법론들은 어떠한 목적으로 만들어졌던 간에 납품(Delivery)형 소프트웨어를 위한 것으로 볼 수 있습니다. 그러다 보니 요구사항이 원하는 형태로 개발되는가 보다는 계약관계가 잘 이행되고 있는지에 더 초점이 맞춰져 있는 것이 사실입니다. 이러한 이유로 기존의 개발방법론은 대기업 위주의 SI(System Integration)형 프로젝트의 변화에 따라 발전했다고 봐야 할 것입다. 이와는 다르게, 중소규모의 솔루션(Solution)형 프로젝트는 개발자 위주로 개발되다 보니 개발방법론의 필요성 자체를 못 느낀 경우가 많았습니다. 하지만 소프트웨어를 더 체계적으로 개발해야 한다는 필요성은 예나 지금이나 소프트웨어를 개발하는 사람이라면 누구나 공감하는 얘기일 것입니다.

<사용자와 개발자 간의 비전 공유(기능적 측면)>

자세히 보기 →

‘얼랭(Erlang)’을 이용한 서버 프로그램 개발

MMORPG 엔진을 C, JAVA, Ruby, Python, 얼랭(Erlang)으로 개발하여 성능 테스트를 해보면,  얼랭이 상대적으로 퍼포먼스가 좋고, 코드의 양도 JAVA나 C언어에 비해서 3분의 1 수준으로 줄어들어 프로그래밍이 간단하다는 것을 확인할 수 있습니다.

특히, 다른 언어로 짜면 실제 로직과 코드가 달라져서 복잡해지는 부분이 있지만 얼랭은 그대로 표현할 수 있다는 점이 가장 큰 매력이라고 합니다. 아직은 우리나라에 생소한 프로그램 개발 언어인 ‘얼랭(Erlang)’을 2008년부터 사용해온 전문가 의견을 정리했습니다. 

자료 처리를 수학적 함수의 계산으로 취급하는 얼랭과 같은  함수형 프로그램 개발은(Functional Programming) 이해가 용이하기 때문에 개발 속도도 빠르다고 할 수 있습니다. 반면, 기존의 다른 프로그래밍 방식(즉,  상태와 가변 데이터에 중심을 두고 명령형으로 처리하는 개발)에 익숙하다면 얼랭을 사용할 때 어려움을 느낄 수 있습니다. 따라서,  편리하고 빠르며 효율 높은 얼랭을 이용하여 모바일 서버 프로그래밍을 자유자재로 하기 위해서는 부단한 연습만이 정법이 될 것입니다.

얼랭 Cowboy 처리 흐름도(자료: Cowboy 홈페이지)

자세히 보기 →