애자일을 활용한 모바일 개발 프로세스

Ⅰ. 모바일 앱 시장의 성장과 현실

전세계적으로 모바일 사용이 확산되면서 모바일 어플리케이션(이하 앱) 시장의 규모도 급격하게 증가하고 있다. 시장조사기관인 가트너에 따르면 모바일 앱 시장 규모가 지난해 52억 달러에서 2014년 580억 달러로 10배 이상 성장할 것으로 예상하고 있다. 이는 애플, 구글, MS와 같은 기존 모바일 플랫폼 사업자들의 오픈마켓뿐만 아니라 아마존과 페이스과 같은 컨텐츠 및 서비스 기업들도 새로운 시장을 만들어나감에 따라 더욱 다양한 모바일 서비스가 가능해지고 이를 이용하는 사용자도 같이 확대되어 갈 것이기 때문이다.

모바일 앱 시장이 급격하게 성장하고 있지만 워낙 많은 앱들이 시장에서 치열하게 경쟁하다보니 사용자에게 주목받기란 매우 어려운 일이다. 모바일 앱 마켓에서 상위에 링크된 경우 높은 인기를 누리지만 나머지는 거의 미미한 이용률을 보이고 있다. 애플 앱스토어의 경우, 상위 5위에 등록된 앱은 절반 이상의 사용자가 이용하는 반면에 나머지는 2% 정도의 사용자만을 갖는다고 한다. 따라서 모바일 앱 시장은 소위 “부익부 빈익빈” 현상이 매우 극명한 곳이라고 할 수 있다. 한국콘텐츠진흥원에서 발표한 “모바일 애플리케이션 비즈니스 현황과 전망”, 이라는 보고서에 따르면, 국내에서 모바일 앱을 등록한 업체의 70% 정도가 20명 이하의 중소기업이며 종업원 1인당 년간 매출액은 1,200만원에(2011년 기준) 불구하다고 한다. 특출난 1인 개발자나 대규모 온라인 및 게임사를 제외하고는 생존하는 것조차 쉬운 일이 아니다.

Ⅱ. 모바일 앱 개발의 특성과 이슈들

경쟁이 치열한 모바일 앱 시장에서 성공하기 위해서는 기존의 소프트웨어 개발방식과 서비스 전달이 아닌 모바일만의 개발환경과 사용특성을 고려하는 것이 중요하다. 즉, PC에서 잘 돌아가던 서비스를 모바일로 옮겨 전달하는 방식으로는 성공하기 어렵다는 점이다. 모바일 앱 개발은 기존의 소프트웨어를 개발하는 것과는 개발환경에서 차이점이 많다. 우선, 다양한 모바일 OS기반 위에 수많은 디바이스들이 개발되다보니 해상도나 OS 버전과 같은 단편화(fragmentation) 이슈가 심각하다. 개발자가 다양한 디바이스의 특성에 맞춰 기능을 조정하고 일일이 테스트를 거치는 과정은 큰 부담이 될 수밖에 없다. 또한 각각의 플랫폼별로 개발언어와 도구가 다르기 때문에 개발자가 이를 배우는데 많은 시간과 노력이 요구된다. 모바일은 PC보다 작은 화면에서 모든 조작과 정보를 이루어져야 하기 때문에 단순하고 편리한 사용자 인터페이스(UI)와 모바일 단말의 하드웨어적인 제약사항도 반드시 고려되어야 한다.

그러나 모바일 개발환경의 차이점보다 더욱 어려운 점은 하루가 다르게 변화하는 바일 비즈니스 환경에 발빠르게 대응할 수 있어야 한다는 점일 것이다. 사용자들에게 해당 카테고리에서 “First App”으로 선점되지 못하면 외면당하기 마련이다. 애플 앱스토어에는 하루 평균 앱 700~800여개의 앱이 등록된다고 한다. 그 많은 앱 중에서 사용자가 다운로드를 하더라도 주기적으로 사용되는 앱은 25% 이하에 불과한 실정이다. 모바일 앱이 그저그런 단순한 기능만을 제공하는 경우, 새로운 앱들에 밀려 그대로 삭제되어 버릴 것이다. 모바일 앱이 개발되어 선택된 이후에도 지속적인 업그레이드와 개선이 필요한 이유이다. 이러한 점들은 사용자의 요구사항이 비교적 분명하고 완성도 있게 제품을 개발하면 별 문제가 없는 한 꾸준하게 이용되던 기존의 소프트웨어와는 매우 다른 특성이라고 할 수 있다.

Ⅲ. 모바일 개발환경에 적합한 개발방법

위에서 살펴본 모바일의 개발환경과 사용특성들을 고려해 볼 때, 모바일 소프트웨어 개발에는 기존 소프트웨어 개발방법보다는 애자일(Agile) 개발방법이 보다 적합하다는 것을 알 수 있다. (아래 표 1 참조) 애자일 개발방식은 소프트웨어 개발 과정에서 빠른 변화를 수용하며 협업을 강조하는 가벼운 개발 프로세스들을 통칭하는 말이다. 애자일 개발방법은 애자일 헌장(The Agile Manifesto)을 특징으로 삼고 있으며 XP(Extreme Programming), 스크럼(Scrum), 린 (Lean) 개발방법 등이 비교적 널리 알려져 있다.

애자일 헌장 (The Agile Manifesto)

  • 개인과 상호 작용이 공정과 도구보다 중요하다.
  • 작동하는 소프트웨어가 포괄적인 문서화보다 중요하다.
  • 고객과의 협력이 계약 협상보다 중요하다.
  • 변화에 응대하는 것이 수립된 계획을 준수하는 것보다 중요하다.
사용자 삽입 이미지
<표 1> 모바일 개발 환경과 애자일 특징
애자일 개발방식의 두드러진 특징으로 점진적(incremental)이고 반복적(Iterative)인 개발방식을 들 수 있다. 점진적 개발이란 하나의 완전한 아이디어를 구상하고 한번에 하나씩 구현해 나가는 것이라면, 반복적 개발은 모호한 아이디어에서 출발하여 점차 이를 구체화하고 검증하여 완성도를 높여가는 것이다. 이처럼 점진과 반복은 서로를 보완하며 프로젝트를 목표를 향해 유연하게 이끌어준다. 애자일 개발에서 점진은 무엇을 먼저 내놓고 어떻게 진화할 것인가에 대한 전략적이고 큰 사진(big picture)적 방향이라면 반복은 무엇을 어떻게 구체화시키고 검증할 것인가에 대한 방법적이고 교정적인 내용이라 할 수 있다.

사용자 삽입 이미지
<그림 1> 점진적 (Incremental) 개발
사용자 삽입 이미지
<그림 2> 반복적 (Iterative) 개발
애자일 개발방식과 전통적인 개발방식인 폭포수(waterfall) 개발방식에서 큰 차이점은 의사소통 차원에서 발생된다. 가령, 폭포수 개발방식은 기획이 완성되고 설계가 끝나야 개발자에게 스펙이 전달되는 수직적이며 동기화 주기가 매우 긴 의사소통 구조를 갖게 된다. 따라서 개발과정에서 스펙 상의 문제점이 발견되고 다시 기획과 설계의 수정을 거치다보면 일정지연은 불가피할 수밖에 없다. 짧은 반복개발을 통해 프로젝트 팀원이 매일 협업을 하게 되는 애자일 개발방식은 의사소통이 수평적이고 잦은 동기화가 이루어지기 때문에 위험을 낮추고 시너지를 높일 수 있다는 것이 장점이다. 아래 <그림 3>은 전략에서 화면까지 계층적인 개발 구조가 수직적으로 이루어지는 순차적 과정(from abstract to concrete)이 아니라 반복과 점진을 통하여 수평적으로 분할하여 개발되는 애자일 개발과정을 보여준다.

사용자 삽입 이미지
<그림 3> 애자일 개발에서의 점진과 반복개발
그럼 애자일을 모바일 개발에 구체적으로 적용하는 방법을 한번 살펴보자. <그림 4>는 스크럼을 위주로 XP개발 프랙티스를 활용하여 모바일 애플리케이션을 개발하는 프로세스 살례이다. 일반적으로 10명을 넘지 않는 작은 규모로 팀을 이루며 설계/개발/테스트가 포함되는 2~4주 이내의 짧은 개발주기를 반복하며 제품/서비스를 개발해 나가게 된다. 각 주기마다 스프린트 리뷰라는 회고(retrospect)를 통해서 잘된 점과 수정할 사항을 토론하고 협의해 나가는 것도 중요한 활동이다.

사용자 삽입 이미지
<그림 4> 애자일을 적용한 모바일 개발 프로세스 사례 (Yahoo사례)
모바일 개발에서 최상의 사용자 경험을 제공하기 위한 사용자 인터페이스(UI) 설계와 여러 단말에서의 동작과 성능을 확보하기 위한 테스트는 어려운 과제 중 하나로 떠오른다. 애자일 개발 프로세스에서 계획과 설계, 테스트의 기준이 되는 중요한 작업 중 하나가 사용자 스토리(user story)작성이다. 사용자 스토리는 사용자(as a user)가 해당 기능(feature)에서 무엇을 하고 싶어하고(want to) 어떤 것을 기대하는지(result)를 기술하는 문서이다. 애자일에서는 사용자 스토리에 기반하여 스토리 점수(story score)를 부여하고 일정을 추정하여 작업의 우선순위를 결정하는 것뿐만 아니라 사용자 인터페이스 화면과 네비게이션 그리고 최종적인 테스트 승인을 위한 기준으로도 활용한다. 사용자 화면 설계는 디자인 워크샵과 같은 프로젝트 공동 작업을 통하여 아이디어나 프드백을 수렴하는 과정을 통해 구현해 나간다. 초기에는 간단하게 백지에 동작을 스케치를 하는 종이 프로토타입이나 HTML Mockup을 통해 사용자 경험을 미리 확인해 보는 것이 요령이다.

사용자 삽입 이미지
<그림 5> 애자일에서의 사용자 인터페이스 개발 과정
모바일에서의 파편화 이슈와 기능 개선 등으로 잦은 코드 수정이 불가피한만큼 테스트 활동도 증가하게 된다. 애자일에는 지속적 통합(Continuos Integration), 테스트 주도 개발(TDD), 짝 프로그래밍(pair programming) 등과 같은 프랙티스를 통해 개발과 테스트가 함께 진행한다. 소프트웨어 개발에서 결함이 나중에 발생될수록 이를 수정하는데 드는 개선비용도 급증한다는 1:10:100의 이론적 배경도 결함의 조기 발견이 품질개선에 중요함을 잘 뒷받침해준다. 개발자가 성장하는데 빠른 피드백만큼 중요한 입력(input)이 없는 만큼 애자일의 테스트 활동은 학습의 연장으로 이해해도 무리가 없다고 생각한다. 모바일에서 모든 단말에서 실제 동작을 확인하기는 현실적인 어려움이 많기 때문에 OS 및 브라우저 업체가 제공하는 시뮬레이터 환경을 이용 하는 것이 일반적이다. 그러나 실제 단말과의 하드웨어적인 차이점으로 전적으로 결과를 신뢰할 수 없다. 최근에는 다양한 단말에서의 실제 테스트 결과를 제공해주거나 각 브라우저별로 웹 표준 적합도를 평가하고 문제되는 코드를 리포트해주는 서비스들이 있어 잘 활용한다면 테스트 비용을 절감하는데 많은 도움을 받을 수 있다.

사용자 삽입 이미지
<그림 6> 모바일 앱 단말 테스트 및 웹 표준 평가도구

Ⅳ. 마치는 글

빠르게 변화하고 더욱 복잡해지는 모바일 개발환경에서 한 사람의 천재개발자가 해낼 수 있는 일은 한계는 점점 커지게 마련이다. 서로 간의 협업을 통하여 프로젝트 팀의 성과를 높여가는 노력이 중요해질 수 밖에 없는 시점이다. 다행인 것은 글로벌 기업뿐만 아니라 국내에서도 많은 기업들이 애자일을 도입하는 사례가 증가하고 있다는 것이다. 지난해 9월에 오픈한 모바일 교보문고 앱은 처음부터 애자일을 적용하여 성공한 케이스로 알려져 있다. 약 5개월동안 대형 SI업체와 교보문고는 30여명의 프로젝트 팀을 구성하여 스크럼을 적용한 것으로 알려져 있다. HTML5라는 익숙하지 않은 기술을 도입하면서도 프로젝트가 목표했던 최종 일정을 준수할 수 있었던 성공요인으로 의사소통과 팀워크, 명확한 목표, 타당한 로드맵, PM의 리더십을 언급하였다. 누구나 다 아는 얘기지만 소프트웨어 개발은 사람이 한다. 사람이 중심이 되어 서로 간에 연결이 되고 원활한 소통이 이루어질 때 시너지가 나는 것은 당연한 일이다. 애자일은 사람이 중심에 되어 서로 협력하고 소통을 위한 방법이다.다만 특정 개발방법이 모든 문제점을 해결해 줄 수는 없다. 고객에게 보다 나은 가치를 제공하기 위해서 새로운 것을 받아들이고 함께 발전해 나가려는 끊임없이 노력이 성공의 비결이자 애자일의 핵심이다.

< 참고문헌 및 사이트 >
1. “글로벌 기업들의 플랫폼 전략과 개발 기술 사례 : Yahoo 사례”, 12th SW Quality Insight,
컨퍼런스 발표 자료, 황순삼, 2012
2. “모바일 애플리케이션 비즈니스 현황과 전망”, 한국콘텐츠진흥원(KOCCA) 포커스 2011-20호,
이양환, 2011
3. “모바일 웹앱 최신 기술동향 및 전망”, 전략 및 개발 워크샵 2011 발표자료, 황순삼, 2011
4. 모바일 컨텐츠 이야기, http://www.mobizen.pe.kr
5. Agile methods for better and faster UX solutions, Agile 2008 workshop in Toronto, Dan
Harrelson, LeahBuley, adaptive path.
6. [Case study] 모바일 교보문고 프로젝트, 전자신문 (2012년,2월9일 기사)
7. “Mobile software development – the business opportunity for today”, Pekka Abrahamsson,
Proceeding of the International Conference on Software Development, 2005, pp 20-23.

<본 글은 SW공학센터 웹진의 SW공학 트렌드 동향분석에 기고한 글을 편집하여 올린 것입니다.>

글: 황순삼
출처: http://swprocess.egloos.com/2869605

%d bloggers like this: