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

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

사용자 관점의 클라우드 서비스
최근에 알려진 클라우드 서비스라면 스마트폰이나 스마트패드를 들고 다니며, 인터넷 상에서 음악을 듣고, 동영상 보던 것을 집에 있는 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).

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

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

더보기

소프트웨어공학 조직을 도입하기 위한 준비 사항 또는 필수 사항

Q: 소프트웨어공학 조직을 도입하기 위한 준비 사항 또는 필수 사항은 무엇이 있을까요? 

최초 소프트웨어공학 조직의 활동에서 가장 어려웠던 점은 습관의 변화에 대한 반감이었습니다. 소프트웨어 공학의 적용은 조직의 문화를 바꾸는 일이고, 이 이야기는 즉 구성원들 각자가 그 동안 해오던 자신들만의 노하우 또는 습관들을 버리고 표준화된 프로세스에일원화 된다는 의미가 되기 때문입니다.

따라서 가장 어려웠던 일은 구성원들을 설득하는 작업이었으며, 이를 성취하기 위한 필수 사항은 바로 CEO의 의지라고 할 수 있습니다. 대표자의 명확한 비전과 목표가 있고, 이를 이루기 위한 방법이 소프트웨어공학을 통한 올바른 소프트웨어 사업 수행 프로세스의정립을 목표로 지속적인 지원이 있지 않는다면 매우 힘들었을 것이라고 생각됩니다.

조직의 문화를 바꾸는 일은 매우 어려운 일입니다. 특히 오래된 조직일수록 더욱 그 강도는 높습니다.

이러한 의지가 확고하다면, 소프트웨어공학 조직을 성공적으로 도입하기 위한 반 이상은 준비가 되었다고 생각됩니다. 그 다음으로는모든 구성원들이 불편하다고 생각하는 부분과 현재 기업이 발전을 하는데 방해가 되는 요소들을 적절하게 캐치해 낼 수 있는 인터뷰어가 중요하다고 생각합니다.

물론 전체 소프트웨어 개발을 가장 효율적으로 할 수 있는 많은 소프트웨어공학 기법들 중 가장 알맞은 기법을 선택할 수 있는 연구는필수적입니다.

Q: 효과적인 소프트웨어공학 조직의 도입은 기업의 전체적인 생산성의 증가 뿐 아니라 내재적인 가치 향상에도 상당한 도움이 될 수 있다는 말씀으로 정리됩니다. 이번 이야기의 마무리를 부탁드립니다. 

소프트웨어공학의 도입은 소프트웨어를 개발하는 많은 회사들에게 효율성과 기업의 가치를 극대화 시킬 방법을 분명하게 제시할 것입니다. 하지만 이러한 소프트웨어공학 조직의 구성과 도입은 그 결과를 얻을 수 있을 때까지 많은 고통을 강요할 수도 있습니다. 수 많은사람들의 설득과 불필요한 언쟁 등으로 인한 감정적인 소모가 동반될 수도 있습니다.

하지만 분명한 것은, 기업의 입장에서는 어떠한 사람이 업무를 수행하더라도 즉각적으로 대응할 수 있는 표준화된 업무 프로세스와 각구성원의 최상의 퍼포먼스를 보장하기 위한 알맞은 조직 및 업무의 분장은 반드시 필요합니다.

이러한 고통을 인내하고 견디어 낼 수 있는 강한 의지와 명확한 목표가 존재한다면, 소프트웨어공학 조직의 도입은 반드시 어떠한 IT기업이든 간에 상당한 이점을 제공할 것이라고 생각합니다.

더보기

핀테크 서비스에서 필요한 보안 품질

핀테크 서비스로 인한 금융 서비스의 환경 변화에 따라 보안 환경도 많은 변화가 일어나고 있다. 사용자 편의성이 요구되고 있고 기술과 정책 관점의 보안 사항은 배제하려는 가급적 추세다. 그리고, 핀테크 서비스는 모바일과 온라인 기반이기 때문에 액티브X나 공인인증서와 같이 국내에서 독특하게 쓰이는 보안 도구는 글로벌 표준으로 변경하는 것이 좋다. 그림7은 금융보안원에서 제시하는 핀테크서비스 보안 분야별 핵심 고려사항을 나타낸다.

<그림7> 핀테크 서비스 보안 분야별 핵심 고려사항

 

출처 : 금융보안원

핀테크 서비스도 보안은 기본이자 필수다. 효과적으로 보안을 강화하기 위해 스스로 방법의 전환이 필요하다. 사전 인증은 간소하게 진행되어야 하며, 보안 방식과 절차는 서비스 업체에서 사용자에게 선택권이 넘어가는 것이 바람직하다. 그리고, 사용자는 핀테크 서비스이용시 보안 위협에 대해 충분히 인지한 후 주의를 기울이는 것이 좋다.

더보기

핀테크 보안 사례연구

대내외 적인 인터페이스로 핀테크 보안 요소를 만족시킨다.

핀테크 보안 3요소인 효율성, 편의성, 안정성 적용을 살펴보기 위해 C사의 핀테크 프레임워크 사례를 연구한다. 비즈니스 관점의 보안을 위해서는 기존 금융 서비스는 건드리지 않고 핀테크 서비스와 연결할 수 있는 방법을 적용해야 한다. 여기서 보안 문제가 발생하지않도록 구성해야 한다(그림 3).

<그림 3> 핀테크 용 프레임워크 사례

 

출처 : Cocoon

기존 금융 서비스에서는 사용자 인증부터 서비스 처리까지 사용자와 서버간 통신이 많았다. 하지만, 그림 3의 ①에서 사용자 인증과UI/UX 부분은 모두 자체적으로 처리되도록 되어있다. 보안 역시 ①에서 자체적인 보안 관리를 수행하게 된다. 그림 3의 ②에서는 기존금융 서비스를 독자적으로 운용되도록 했기 때문에 보안 문제는 발생하지 않도록 되어 있다. 기존 금융 시스템과 표준 Adapter를 통해쉽게 인터페이스를 할 수 있고, 향후 채널 확장시 표준 API 호출만으로 쉽게 적용되도록 하고 있다. 사용자(①)와 서버 간에 발생할 수있는 보안 문제를 해결하고, 기존 업무를 재사용(②)하여 추가 개발로 인한 보안 문제도 해결할 수 있다. 그리고, 안정성이 보장된 플랫폼과 단말간의 데이터 암호화/압축, 접근/권한 제어를 통해 보안성이 제공된다. 사용자 측의 보안 기술은 아래 사이트를 참고한다.

더보기