가속화 되고 있는 클라우드 도입으로 인한 소프트웨어 활용의 범위

지금까지도 소프트웨어 자체를 만드는 것보다는 소프트웨어를 서비스하기 위해 준비해야 하는 것들이 너무 많다. 서버와 데이터베이스를 비롯해 네트워크와 보안 등의 전문가들이 필요하기 때문에 많은 소프트웨어 업체가 고민에 빠진다. 클라우드는 개발자와 회사가 소프트웨어에 집중하고 구매, 유지 관리, 용량 계획과 같은 획일적인 일은 피할 수 있도록 해주고 있다. 이번 회에서는 클라우드 도입이 소프트웨어 활용에 어떤 영향을 미치는지 살펴보도록 한다.

사용자 관점의 클라우드 서비스
최근에 알려진 클라우드 서비스라면 스마트폰이나 스마트패드를 들고 다니며, 인터넷 상에서 음악을 듣고, 동영상 보던 것을 집에 있는 PC 로 이어서 듣거나 볼 수 있거나 회사의 회의시간에 정리한 문서를 바로 인터넷을 통해 회의 참석자들과 함께 공유하는 것을 생각한다(그림1).

그림1과 같이 사용자가 생각하는 클라우드 서비스는 디바이스와는 상관없이 원하는 서비스를 받는다. 애플, 구글, KT 등 클라우드 서비스를 제공하는 다양한 업체는 대부분 스토리지나 서버를 공유하는 형태가 일반적이고 일부 소프트웨어는 라이선스를 공유해서 사용하기도 한다. 사용자 입장에서는 디바이스나 소프트웨어 중심의 서비스에서 사용자 중심의 서비스로 이동한다고 볼 수 있다.
이번에는, 소프트웨어 개발자 입장에서 클라우드를 살펴보자. 사용자 입장과는 다르게 소프트웨어 개발자는 소프트웨어를 개발하기 전에 고민해야 할 것들이 매우 많다. 서비스하고자 하는 소프트웨어를 개발하는 것부터 개발에 필요한 웹 서버, 어플리케이션 서버, 데이터베이스 서버, 라이브러리 등을 고민해야 하고, 이를 구동시키기 위한 물리적인 하드웨어와 네트워크 등도 고민해야 한다. 소프트웨어 업체가 좋은 아이디어를 가지고도 실패하는 이유가 아이디어를 소프트웨어로 만드는 것 외에 준비해야 할 것들이 너무 많았기 때문이다.
그렇다면, 클라우드 서비스의 유형을 살펴보고, 개발자 관점으로 클라우드 서비스에 대해 살펴보면서 높은 품질의 소프트웨어를 개발하기 위해 클라우드 서비스를 활용하는 방법에 대해 알아보자.

더보기

하둡 기반의 빅데이터 활용을 통한 시스템과 작업 시간 효율화

각 분야에서 나날이 증가하고 있는 데이터 양은 폭증이라는 말이 더 정확한 표현이다. 빅데이터 분석에 많은 비용과 시간을 투자하고 있지만 빅데이터를 활용하기 전에 어떻게 저장하고 처리하는지에 대한 연구도 병행되고 있다. 이미 빅데이터의 처리에 대한 많은 방법과 솔루션들이 제시되고 있지만 언제 시스템을 살펴봐야 하는지, 아키텍처는 제대로 정의했는지, 작업시간은 적당한 것인지가 언제나 고민거리다. 이번 회에서는 기존 오라클 시스템에서 하둡 기반의 분산처리 시스템으로 변경하는데 소프트웨어공학적 요소를 적용한 사례를 살펴보기로 한다. 컨설팅에 참여했던 단국대학교 SERC(Software Engineering Research Center)의 윤광렬 박사를 만나 자세한 사항을 들어본다.

Q: 이번 프로젝트가 시작된 배경에 대해서 말씀해 주세요.
A회사는 RDBMS인 오라클을 활용해서 데이터를 처리하고 있었습니다. 주요 고객사가 증권사이고 여러 채널을 통해 대고객 서비스를 제공하는데 기술의 발전에 따라 채널이 계속 증가하다 보니 증권사 시스템과 고객 간의 데이터의 양도 기하급수적으로 증가하고 있는 상황이었습니다. RDBMS로는 감당 못한다는 판단을 할 수 밖에 없었죠. 이런 이유로, 매우 빠르고 안정적으로 데이터를 처리하는 새로운 아키텍처를 필요로 하였고 이후에 다시 이런 고민이 없었으면 하는 바램이 강했습니다. 빅데이터는 RDBMS로 감당을 못하기 때문에 새로운 처리 방식을 위해 하둡 기반을 SERC 의 데이터베이스 기술팀이 제안하였고, 아키텍처의 강건성을 위한 컨설팅을 위해 컨설팅 업체 B와 SERC의 소프트웨어공학팀이 함께 고민했습니다.

Q: 빅데이터 처리 방식을 최신 트렌드에 맞추고 안정성과 확장성을 고려하여 시스템 아키텍처를 설계한 것으 로 보입니다. 진행했던 사항에 대해 간략히 설명해 주시죠.
두 가지로 나누어 말씀 드려야 할 것 같습니다. 첫 번째는 빅데이터 처리를 오라클 기반에서 하둡 기반으로 변환한 것입니다(그림1). 증권 거래를 위한 프로그램인 HTS(Home Trading System)에서 발생하는 log data(일종의 비정형 빅데이터)를 기존에는 오라클에서 처리하였습니다. 처리 후 성능에 대해서는 A업체도 크게 불만이 없었는데 처리 중 성능에 매우 불만이 많았습니다. 데이터 양이 늘어날 때마다 많게는 수 십분을 기다린 적도 많다고 하더군요.

더보기

사용자 스토리 워크샵 사례 연구 - 티밍 & 역할 정의

소프트웨어 개발 프로젝트에 애자일(Agile)을 도입하는 경우가 늘어나는 추세다. SI(System Integration)와 같은 전통적인 개발 방법에 대한 한계를 느끼고 새로운 개발 방법에 대한 가치를 인정하기 때문이다. 애자일은 생각보다 더 빠르게 개발자들에게 확산되고 있으나 성공 사례는 점점 줄어드는 것으로 나타나고 있다. 빠르게 확산되는 만큼 애자일의 기본 사상이 반영되지 않는 경우가 많아 보인다. 애자일 기반 프로젝트를 성공적으로 이끌기 위해 사용자 스토리 워크샵(User Story Workshop)이 많이 사용된다. 이번 회에서는 사용자 스토리 워크샵의 티밍과 역할 정의에 대해 살펴보기로 한다. 명확한 사용자 스토리 정의를 통해 애자일 기반 프로젝트의 성공률이 높아지기를 기대한다.

사례 연구 전 확인 사항
애자일의 기본 사상
애자일은 문서 작업이나 설계에 집중하던 개발 방식에서 벗어나 좀 더 개발에 집중에 보자는 사상을 가지고 있다. 정해진 계획만 따르기 보다는 개발 주기나 개발 환경에 따라 유연하게 대처한다(그림1).

애자일은 계약이나 도구보다 사람이 먼저다. 소프트웨어는 계획한 대로 만들어지지 않는다. 개발자나 개발 환경, 비용과 같은 다양한 외부 요인에 영향을 받는다. 애자일은 이러한 상황을 고려해 개발자와 사용자(고객)를 중심에 뒀다. 사용자가 개발에 적극 참여해 우선순위를 정하고 개발 과정을 평가하기도 한다. 계획을 살펴보지만 강요하기보다 개발 상황에 따라 유연하게 변경될 수 있도록 한다.

이 것은 사용자와 개발자(개발팀) 간의 신뢰가 바탕이 되어야 하기 때문에 개발 문화의 변화를 요구하게 된다. 사용자와 개발자 간 신뢰를 위해서는 개발하고자 하는 소프트웨어에 대한 생각이 일치하는 것이 먼저이기 때문에 이를 위한 사용자 스토리 워크샵이 나타나게 되었다.

더보기