SK C&C의 전자정부 모바일 프레임워크 활용

모바일 소프트웨어는 모바일에 직접 설치되어 사용되는 앱 형태의 소프트웨어와 모바일 브라우저를 이용해 서비스하는 웹 형태의 소프트웨어다. 모바일 앱은 클라이언트/서버 어플리케이션처럼 항상 처음부터 새롭게 소프트웨어를 만들어야 하지만, 모바일에서도 브라우저를 통해 서비스되는 모바일 웹은 PC의 웹 기반 서비스처럼 브라우저를 통해 서비스를 제공하기 때문에 html 위주로 소프트웨어를 만든다. 이 경우, PC 혹은 모바일에 따른 UI 측면만 고려한다면 PC나 모바일에서 소프트웨어 개발 방법이 크게 달라질 필요가 없다. 따라서 최근에는 모바일 서비스를 브라우저를 통해 하는 경우도 많이 나타나고 있다.

모바일 앱이나 모바일 웹은 각각의 장단점이 있기 때문에 두가지 모두를 사용하는 경우도 종종 있다.  이러한 것을 하이브리드 앱이라고 한다. 하이브리드 앱은 모바일 앱과 모바일 웹의 장점을 적절히 섞어서 사용하게 된다(그림5).

<그림5> 모바일 앱(Native)과 모바일 웹(Web)

출처: Workight - Native Web or Hybrid Mobile App Development

SK C&C에서는 모바일 표준프레임워크를 활용하여 모바일 앱 스타일의 사용자경험(UX)를 제공하고, 범용 모바일 브라우저에서 같은 접근성을 제공하는 것을 목표로 국세청 전자세금계산서 모바일, 행안부 행정업무 모바일 구축 프로젝트 등을 수행하였다.

모바일 웹으로만 구현하는 경우에 위치정보 등 모바일 디바이스에서 제공하는 고유 기능을 활용하기 어렵기 때문에 하이브리드 앱 형태로 개발하여, 자바스크립트를 활용하여 모바일 디바이스의 고유 기능을 실행하도록 구현하였다(그림6).

<그림6> 전자정부 모바일 표준 프레임워크 기반의 하이브리드 앱

출처: SK C&C

더보기

모바일 프레임워크 기반의 개발에서 주의할 점

프레임워크는 자주 사용되거나 중요한 부분을 블랙 박스(Black Box) 형태로 만들고 이것을 재사용 하는데 가장 큰 목적이 있다. 따라서 개발자가 프레임워크를 구현하거나 사용할 때 아래와 같이 몇 가지 기억해야할 것들이 있다.

① 개발 표준화가 선행되어야 한다.

UI, 비즈니스, 데이터 등 각 레이어 별로 수행하는 기능이 다르기 때문에 다양한 개발자가 참여하게 된다. 따라서 다양한 개발자가 개발을 해도 빠르고 정확하게 개발될 수 있도록 각 레이어 별로 개발 표준이 있는 것이 좋다. 해당 개발 표준으로 개발자 간 커뮤니케이션을 할 수 있고, 이로 인해 원활한 인터페이스를 유지할 수 있다. 모바일 개발의 경우에는 특히 다양한 모바일 디바이스를 다루기 때문에 개발 표준에 대한 중요도가 더 높다.

② 개발 생산성을 고려하여 프레임워크를 사용한다.

좋은 프레임워크라고 소문이 났더라도 반드시 모든 곳에 좋은 것은 아니다. 프레임워크의 볼륨, 사용방법, 그리고 추가 개발 범위 등을 고려하여 최적의 생산성이 나오는 프레임워크를 고른다. 모바일의 경우, 모바일 디바이스에 따라 실행환경, 개발환경, API 구성이 변화가 적은 것을 골라야 하며, 반대로 변화가 거의 없더라도 개발 시 너무 많은 것을 설치해야 하는 것은 아닌지, 범용을 위한 모듈의 볼륨이 너무 크지 않은지도 확인한다.

③ 유지보수가 용이하도록 개발한다.

다양한 서비스 확장을 위해서 표준화된 프레임워크를 사용한다. 따라서 추가되는 모듈도 프레임워크의 가이드에 맞춰 유지보수가 가능하도록 개발해야 한다. 유지보수는 모바일이나 일반적인 프레임워크 모두 중요한 요소이지만, 서비스 중심인 일반적인 프레임워크와는 달리 모바일은 모바일 디바이스도 고려해야 환경 변화에 쉽게 대응할 수 있다.

더보기

전자정부 모바일 프레임워크

전자정부에서는 표준프레임워크를 기반으로 모바일 서비스 제공을 위해 필요한 사용자경험(UX), 모바일 공통컴포넌트를 추가한 모바일 표준프레임워크를 제공하고 있고(그림2), 이를 전자정부 표준프레임워크 차기 버전으로 공지한 상태다.

<그림2> 전자정부 모바일 표준프레임워크

출처: 전자정부 모바일 표준프레임워크 교육자료

전자정부에서는 모바일 웹 구현을 위한 개발 환경도 제공하고 있다. 설치와 동시에 바로 적용 가능할 수 있는 모바일에 최적화된 표준 소스코드를 제공하고, 모바일 템플릿 및 공통컴포넌트 적용을 위한 위저드 방식의 조립식 구현 환경을 제공한다. 마지막으로, 웹 검증 도구를 개발 환경에 내장하여 모바일 웹을 포함한 웹 호환성을 개발과 동시에 검증하는 기능을 제공한다(그림3).

<그림3> 전자정부 모바일 웹 개발 환경

출처: https://www.egovframe.go.kr/

더보기

UX 사례 연구 - 멀티 디바이스의 UX

다른 사용자 그룹을 위한 사용자 경험 공유 

지금까지는 개인 소유의 디바이스를 얘기하고 있지만, 최근에 다른 사용자 그룹 간 다양한 정보나 사회적 공유를 하는 것이 일반화되고 있다. 사회적 관계망(Social Network Service) 등과 같은 서비스를 통해 사용자 경험이 공유되고 있고, 이를 통해 많은 사용자가 서로의 사용자 경험을 공유하고 있다. 

UX 측면에서는 상호작용을 위해 보편화된 UI를 사용해서 UX를 설계하는 것이 좋고, 다른 서비스에서 주로 사용되는 UI와 UX를 반영하는 것이 사용자 입장에서는 편하다. 구글의 웹 사이트를 예로 보면, 구글은 검색이 주 기능이기 때문에 탐색 기능이 눈에 띄게 배치되도록 설계하였다(그림8). 

 <그림8> 구글의 웹 사이트 

출처: Google 

확장 가능한 참조 UX 만들기 

각 디바이스의 유형에 따라 지원 가능한 기능을 확인하고, 디바이스의 인터페이스에 따라 UX 원칙과 패턴을 정의하여 표준 UX를 만든다. 표준 UX에 따라 각 디바이스 별로 참조 UX를 만들어 디바이스에 반영되도록 UX를 설계한다(그림9). 

<그림9> 참조 UX 만들기  

출처: BBC 

모바일 우선 디자인 

소프트웨어는 PC용으로 개발된 후 모바일 용으로 변환되는 것이 일반적이었지만, 제약사항이 많고 사용자 경험에 집중해야 하는 모바일 용을 먼저 만드는 것이 UX 측면에서는 유리하다. 다양한 것을 모두 담을 수 있는 PC와 달리 모바일은 가장 우선순위가 높은 것부터 담을 수 있기 때문이다. 모바일 용을 만든 후에, 추가 기능을 넣어 테블릿이나 PC용으로 변환하는 것이 좋다. 

동기화 

여러 디바이스에서 동일한 서비스가 제공되는 멀티 디바이스의 UX 설계가 끝나고 나면 각 디바이스에 컨텐츠가 올바르게 돌아가는지 모든 디바이스에서 동기화를 확인해야 한다. 대개는 각 디바이스에서만 정상 동작을 확인하는데 멀티 디바이스의 경우는 동기화가 매우 중요한 확인 요소이다. 

기대 효과와 결론 

과거에는 소프트웨어의 중요 요소로 개발 역량을 우선시 했다. 하지만, 최근에는 사용자 경험을 중요시 하면서 소프트웨어의 기능 외에 사용자와의 상호작용을 중요시 하고 있다. 단순히 명령만 내리고 받은 명령만 수행하던 소프트웨어에서, 사용자에게 더 나은 사용자 환경을 제공하려는 요즘은 UX에게 요구하는 것들이 점점 많아지고 있다. 체계적인 UX 설계는 소프트웨어에 대한 사용자의 만족도를 높여주고 심화되는 사용자 경험으로 인해 또 다른 서비스를 창출하는 도구가 되고 있다. 

더보기

DevOps 환경 을 위한 시스템 & 프랙티스

Docker는 무엇인가

•2013년 3월에 등장한 오픈소스 리눅스 컨테이너 프로젝트
•컨테이너 기술을 기반으로 어플리케이션 패키징,설정,배포를 지원하는 경량의 가상화 솔루션

Docker,OpenStack 구글 트렌드 결과

Docker와 VM 비교


Docker 어떻게 패키징/ 배포를 지원하는가

•Image : 읽기 전용 파일 시스템, 바이너리 코드
•Container: 이미지가 실행된 것
•도커는 어플리케이션/서비스를 컨테이너에 넣어서 빌드/배포한다.

더보기

애자일과 전통적 개발방식의 조화

SW개발프로젝트사례-적용성과

•경영진은높아진개발팀의생산성과품질에만족함
•개발팀원들이업무에열정적으로임하면서업무만족도가향상됨
•개발진행상황의가시성이향상
•팀원들간의협력및팀워크가향상
•시장에맞는제품품질및상품성확보

SW개발프로젝트사례–팀원소감

•기존에는전체일정을산정하고개발하는데어려움이있었지만애자일방법적용후에는단기적으로명확한목표를세우고진행할수있었다.
•PM이팀원들과수직적관계에서업무를지시하고전달하는방식에서벗어나팀원들의역량을발휘할수있도록여건조성을하고, 스스로동기부여를하여업무를진행하므로업무수행능력도높아지는점장점을경험하였습니다.
•팀원간의활발한소통이개발에도움이되었음.
•이터레이션계획을상세하게짜서모두어떤일을하는지알게되어좋았다.
•회고를통해문제가되었던부분을해결할수있어서좋았음.
•저마다본인의업무에집중하고서로가서로를배려하게되었습니다.

SW 유지보수적용사례–적용효과

•개발업무진행상황의가시성향상
 –적용전에는개발자들이무슨일에보틀넥이걸려있으며어떤애로사항이있는지알기어려워팀장입장에서업무진행현황을일일이물어보아야파악할수있었는데지금은타스크보드와데일리미팅을통하여일일이물어보지않아도팀원들이어떤문제에애로사항이있으며어떤업무에버틀넥이있는지쉽게알개되었고당면한문제점들을바로바로해결할수있게되었다.
•통합테스트단계에서발생하는결함감소
 –평균적으로QA팀에서개발팀으로매달8~9여건정도의크고작은재작업요청이있었으나애자일을적용하고나서부터는1~2건정도로줄어든상태이며그나마도마이너한작업이되어품질이많이향상되었다. (70% 이상감소)
•개발과정의효율성이높아지고생산성향상
 –상호간의협업증대로월별처리건수향상(50%이상향상)

더보기

원격 개발센터의 장단점 분석

Q: 분석과 설계를 온-사이트에서 하는 방법도 괜찮지 않을까요? 

설계서에는 프로그램명세서가 있어서 개발만 하면 더 편할 수 있을 것 같은데요? 옳은 지적입니다. 그런데, 내부적인 회의에서 개발자가 업무를 모르면 유지보수가 어렵다는 이야기가 나왔습니다. 분석과 설계를 하지 않았기 때문에 업무를 이해하기는 당연히 어렵고, 업무 설명을 위해 한국에서 중간 관리자를 보내는 방안도 고민했는데, 이러다 보니, 아키텍트도 보내고, 품질담당자도 보내고, 인프라 담당자도 보내야 하고, 마치 해외 프로젝트를 하는 것과 똑같더라고요. 본질이 바뀐 겁니다. 그래서, 가장 기본이 되는 것으로 다시 생각하자고 의견을 모았습니다.

<그림3> 원격 개발센터의 이상적 모델의 예 

출처: 한국정보화진흥원 

그림3은 원격 개발센터의 이상적인 모델인데, 온-사이트에서는 요구사항만 명세화하고 원격 개발센터에서 프로젝트를 수행하는 모델입니다. 이러한 모델은 고객이 개발하는 곳을 볼 수 없기 때문에 부가적인 업무가 없어지고 개발자들은 개발에 전문성을 높일 수 있습니다. 하지만, 요구사항 명세서 하나만으로 개발에 필요한 정보를 모두 알 수 없기 때문에 실제 적용하기는 조금 어려운 부분이기도 하지요. 최근에는 이러한 모델에 소프트웨어공학 요소를 포함시켜 해결을 해보자는 노력도 있기는 합니다(그림4). 

<그림4> 소프트웨어공학적 요소가 적용된 원격 개발센터 

Q: 그림4의 경우는 어떠한 요소가 들어갔는지 설명을 부탁 드립니다. 

그림3이 적용되기 어려운 이유는, 첫째 온-사이트와 원격 개발센터 간의 의사소통이 문서만 왔다갔다 하면서 끝난다는 것이고, 둘째는 요구사항 명세서가 매우 불명확할 것이라는 것, 마지막으로 원격 개발센터가 테스트를 마쳐도 온-사이트에서 잘 돌아갈 것인가 하는 것입니다. 이런 부분을 보완하기 위해 애자일을 도입해서 커뮤니케이션과 반복, 점진을 통해 원활한 의사소통이 이루어지도록 하고, 사용자 스토리 워크샵을 적용해 요구사항을 온-사이트와 원격 개발센터 모두에서 이해할 수 있도록 수준을 높이고, 마지막으로 TDD(Test Driven Development)를 통해 온-사이트와 원격 개발센터의 테스트 케이스를 동일화하여 문제 발생 여지를 줄이는 노력을 하게 됩니다. 

더보기