2017.06.12

기업 앱 개발이 실패하는 5가지 이유와 '타산지석' 사례

Ryan Faas | Computerworld
기업 테크놀로지의 미래는 앱, 그 중에서도 온라인, 데스크톱, 모바일을 막론하고 모든 플랫폼에서 같은 기능을 제공하는 모바일 앱에 달렸다. 그럼에도 불구하고, 레거시 프로세스나 십여 년도 넘은 앱 포트폴리오 등의 과거가 미래로 나아가는 길목을 가로막을 수도 있다.

앱 포트폴리오의 현대화는 결코 쉬운 일이 아니지만, 제대로만 한다면 기업의 (또는 학교나 기타 기관의) 생산성을 높이고 직원 참여와 고객 만족도를 끌어올리는 촉매가 될 수 있다.

여러 기관에서 주기적으로 모바일 솔루션을 출시하고 있는데, 보통 이런 솔루션들은 클라우드에서의 디플로이먼트를 목적으로 개발된다. 하지만 모든 앱이 다 성공을 거두는 것은 아니다. 직원이나 고객이 새 앱을 거부하는 경우도 있고, 사용자가 앱을 사용하지 않고도 목적을 달성하는 우회로를 선택할 수도 있다.

이렇게 앱이 실패할 때는 그만한 이유가 있다. 간단히 말해, 이는 새로운 시도를 하는 IT 업체와 기업 개발자들이 한발 먼저 앞서 계획하는 데에 실패했기 때문이다.

앱 개발이 실패하는 5가지 이유를 살펴보고, 어떻게 하면 이들을 사전에 미리 방지할 수 있을지 알아보자.

1. 서드 파티 솔루션을 활용하지 않는 것
기업 앱 개발 전략을 세울 때 가장 많이 오해하는 것 중 하나가 모든 것을 인하우스에서 직접 개발해야 한다고 생각하는 것이다. 기업 고유의 내부 프로세스 필요에 맞춘 커스텀 앱을 제작해야 한다는 생각은 아주 오래된 고정 관념이다. 지난 몇 년, 어쩌면 십 년도 넘게 이러한 인하우스 개발은 선택이 아니라 필수로 여겨졌다. 서드파티 솔루션을 이용할 수 있을 때조차 불필요한 커스터마이징을 원한 결과, 아직까지도 많은 기업들이 앱 개발에 있어 서드파티 요소를 전혀 허용하지 않고 있다.

하지만 이것은 불필요한 고집이다.

모바일 중심, 클라우드 기반 앱 개발 환경에서 이러한 접근은 구식이라고밖에 표현할 수 없다. 자체 API및 SDK를 제공하는 강력하고 유연한 클라우드 서비스들을 활용한다면 기존의 앱을 이용해 훨씬 더 짧은 시간 안에 새로운 솔루션을 고안해 낼 수 있다. 여기서 가장 핵심은 ‘사용자의 워크플로우를 얼마나 완벽하게 꿰뚫고 있는가’다.

또한, 최소한의 커스터마이징만을 거친 채 출시할 수 있는 앱도 있다. 클라우드 기반 지출 관리 솔루션 컨커(Concur)나 ADP, 혹은 구글의 툴 수트 등은 모바일 앱 전략에 간편하게 사용할 수 있는 준비된 솔루션들이다. 이미 충분히 이용 가능한 도구가 준비되어 있고 주기적으로 업데이트도 되는 상태에서 굳이 모든 것을 기초 공사부터 시작할 필요는 없다.

2. 창대한 시작과 미약한 끝
배치할 앱을 결정할 때는 최대한 작은 규모로 사고해야 한다. 그래야만 실수가 대규모로 발생하는 것을 막을 수 있다. 많은 기업이 가장 사용률이 높고 중요한 앱을 모바일 및 클라우드로 먼저 이전하려고 하거나, 한번에 너무 많은 앱을 개발 하려 한다. 둘 다인 기업도 있다. 하지만 이렇게 해서는 안 된다. 처음 시작은 간결하고 간소한 것이 좋다. 그래야만 개발자, IT팀 및 최종 사용자가 변화에 서서히 적응하며 배워갈 수 있고, 문제가 생겼을 때에도 사소한 문제부터 해결해 나갈 수 있다. 처음부터 감당할 수 없는 규모의 문제에 직면하지 않아도 된다는 장점도 있다.

간소하게 시작할 때의 또 다른 장점은 손쉽게 개발 역량에 대한 신뢰를 얻을 수 있다는 것이다. 비교적 해결하기 쉬운 단순한 문제, 특히 개선 시 사용자의 생활을 눈에 띄게 개선해 줄 수 있는 문제점을 골라 공략한다면, 앱 개발 역량과 함께 모바일 우선적 비즈니스 접근도 성공적으로 해내고 있음을 보여줄 수 있다. 이렇게 얻은 정치적 자본은 향후 더 큰 규모의 프로젝트에 대한 지지와 금전적 지원을 받는 데 결정적인 밑거름이 된다.

3. 사용자를 고려하지 않은 앱 개발
사용자들이 직접 테크놀로지를 활용해 자신만의 솔루션과 워크플로우를 생성하는 것은 IT소비자화의 한 단면이다. 이는 모든 앱 프로젝트에서 최종 사용자들이 가장 중요한 역할을 맡고 있음을 의미한다. 이유는 간단하다. 앱이 사용자의 요구사항에 맞추지 못하거나 불편한 사용자 경험을 제공할 경우 사용자이 더는 그 앱을 사용하지 않기 때문이다. 설상가상으로, 이 경우 보안에 취약하고 다른 솔루션과 통합이 안 되는 솔루션을 이용하려 할 것이다.

앱 개발 시 사용자를 고려한다는 것은 대단한 것을 의미하는 게 아니다. 개발 회의에 일반 사용자를 한 두 차례 동석하게 하는 것만으로도 충분하다. 사용자가 맡은 직무, 업무에 요구되는 사항, 겪고 있는 어려움(앱 개발을 통해 풀어나가야 할 부분), 그리고 워크플로우 등을 이해할 수 있으면 된다. 일주일 가량 사용자와 함께 다니며 궁금한 점을 질문하고 이들의 요구사항을 파악한다면 최소한 사용자에게 외면 받는 앱을 만들 일은 없을 것이다.

앱 개발 단계에서 사용자의 요구를 반영하는 또 다른 방법은, 데스크톱에서 개발중인 앱에 해당하는 어플리케이션의 오리지널 사양을 참조하는 것이다. 이미 검증된 데스크톱 솔루션의 특성을 파악함으로써 사용자가 필요로 하는 것이 어떤 부분인지 알 수 있고, 추상적으로 사용자의 이야기만 듣거나 관찰하는 것보다 훨씬 더 앱 개발에 필요한 부분을 구체적이고 효과적으로 알려줄 수 있다.

4. 백엔드 시스템과 인프라가 앱을 감당할 수 있는지 확인하지 않는 것
모바일, 데스크톱, 웹 앱을 막론하고, 앱 디플로이먼트 시 자주 하는 실수가 바로 백엔드와 인프라를 점검하지 않는 것이다. 앱과 연결되는 백엔드 시스템이 온 프레미스인지, 프라이빗인지, 퍼블릭 클라우드인지, 외부 업체인지 관계 없이, 백엔드 시스템이 새로운 사용자 로드를 감당할 수 있는지 확인해야 한다. 또한, 앱 때문에 발생할 추가 트래픽을 감당할 만큼 무선 인프라가 튼튼한지도 확인해야 한다. 이때 가장 좋은 것은 선별된 사용자 그룹이 각기 다른 시간대에 액세스를 부여 받는 단계적 롤아웃 방식이다. 이러한 접근은 트래픽 요구사항을 쉽게 파악하고 필요할 때마다 인프라스트럭처를 수정할 수 있다는 장점이 있다.

5. 한두 가지 기기에서만 앱 테스트를 진행하는 것
앱을 여러 가지 기기에서 테스팅 해보지 않을 경우 골치 아픈 문제가 생길 수 있다. 앱을 새로 개발하거나, 기존 앱을 배치할 때, 테스트는 아주 중요한 부분이다. 데스크톱 사용 시절에는 테스팅이 어렵지 않았다. IT가 완벽히 통제할 수 있는 워크스테이션 설정이 정해져 있었고 적합한 데스크톱에서 테스트하기만 하면 아무런 문제가 없었기 때문이다.

모바일 및 BYOD 트렌드는 이런 관행을 완전히 바꾸어 놓았다. 이제 기업들은 다양한 하드웨어 사양, 화면 사이즈, 운영체제 버전, 사용자 설치 앱, 통신사, 네트워크, 액세서리 등 각양각색의 특징을 지닌 기기를 대상으로 테스트를 진행해야 한다. BYOD 및 혼합 사용 디바이스의 경우 사용자 행동과 디바이스상의 개인 데이터도 문제가 될 수 있다. 그러면서 테스트는 한층 더 중요해졌다.

이 문제는 특히 안드로이드 기기에서 심각한데, 바로 이런 이유로 기업 환경에서 iOS가 더 많이 사용되기도 한다. 안드로이드 OS의 파편화로 방대한 범위의 OS 버전이 사용되고 있고(아직까지도 안드로이드 킷캣을 사용하는 기기도 있다), 제조사도 통신사도 제각각에 엄격한 업데이트 프로세스까지 겹치면 앱 테스트는 생각보다 아주 복잡한 문제가 된다. 현재 수천 가지가 넘는 안드로이드 OS 베리에이션이 존재하며, 따라서 앱을 개발한다 해도 픽셀이나 갤럭시 등 대중적으로 사용하는 기기에서는 잘 작동하는 것들이 오래된, 혹은 로우 엔드 모델에서는 제대로 기능하지 않을 수 있다.

기기 수가 한정되어 있고 애플이 직접 운영체제 업데이트를 제공해 모든 아이폰 및 아이패드가 최신 버전의 OS를 구동하는 iOS 기기의 경우 이보다는 조금 상황이 낫다(지난주 WWDC에서 애플은 iOS 기기의 86%가 iOS 10을 구동한다고 발표했다). 그렇다고 해도, 아이폰 기기 중에서도 화면 사이즈나 하드웨어 사양이 다른 구형 제품에서는 앱을 사용할 때 문제가 발생할 수 있다.

안드로이드와 iOS, 두 가지 운영체제 외에 윈도우 10 모바일이나 윈도우 10 태블릿도 있다. 사용자 수는 그렇게 많지 않지만, 가능하다면 윈도우 모바일을 대상으로도 앱 테스트를 해 보는 것이 좋다.

즉, 가장 이상적인 것은 앱 테스팅 시 모든 최신 스마트폰과 가장 널리 사용되는 주요 제조사의 디바이스, 그리고 일부 초급 사양 기기까지 포함하는 것이다. 또, 최소 지난 3년 이내의 모든 운영체제 버전과 각각 다른 하드웨어 설정을 대상으로도 테스트해 보아야 한다.

글을 마치며
기업 앱 개발은 막대한 잠재성을 지닌 기대감을 일으키는 분야이다. 더 효율적이고 새로운 태스크 수행 방식을 제안하고, 생산성, 효율성을 높이며, 직원과 고객의 참여를 촉진한다. 하지만 그 이면에는 극복해야 할 문제들도 있다. 앱이 사용자의 요구를 충족하지 못하거나 제대로 기능하지 못한다면 직원들이 소외될 위험이 존재한다. 앞서 소개한 다섯 가지 실수를 하지 않도록 주의할 때, 성공적인 앱 개발도 어려운 일만은 아닐 것이다. editor@itworld.co.kr  


2017.06.12

기업 앱 개발이 실패하는 5가지 이유와 '타산지석' 사례

Ryan Faas | Computerworld
기업 테크놀로지의 미래는 앱, 그 중에서도 온라인, 데스크톱, 모바일을 막론하고 모든 플랫폼에서 같은 기능을 제공하는 모바일 앱에 달렸다. 그럼에도 불구하고, 레거시 프로세스나 십여 년도 넘은 앱 포트폴리오 등의 과거가 미래로 나아가는 길목을 가로막을 수도 있다.

앱 포트폴리오의 현대화는 결코 쉬운 일이 아니지만, 제대로만 한다면 기업의 (또는 학교나 기타 기관의) 생산성을 높이고 직원 참여와 고객 만족도를 끌어올리는 촉매가 될 수 있다.

여러 기관에서 주기적으로 모바일 솔루션을 출시하고 있는데, 보통 이런 솔루션들은 클라우드에서의 디플로이먼트를 목적으로 개발된다. 하지만 모든 앱이 다 성공을 거두는 것은 아니다. 직원이나 고객이 새 앱을 거부하는 경우도 있고, 사용자가 앱을 사용하지 않고도 목적을 달성하는 우회로를 선택할 수도 있다.

이렇게 앱이 실패할 때는 그만한 이유가 있다. 간단히 말해, 이는 새로운 시도를 하는 IT 업체와 기업 개발자들이 한발 먼저 앞서 계획하는 데에 실패했기 때문이다.

앱 개발이 실패하는 5가지 이유를 살펴보고, 어떻게 하면 이들을 사전에 미리 방지할 수 있을지 알아보자.

1. 서드 파티 솔루션을 활용하지 않는 것
기업 앱 개발 전략을 세울 때 가장 많이 오해하는 것 중 하나가 모든 것을 인하우스에서 직접 개발해야 한다고 생각하는 것이다. 기업 고유의 내부 프로세스 필요에 맞춘 커스텀 앱을 제작해야 한다는 생각은 아주 오래된 고정 관념이다. 지난 몇 년, 어쩌면 십 년도 넘게 이러한 인하우스 개발은 선택이 아니라 필수로 여겨졌다. 서드파티 솔루션을 이용할 수 있을 때조차 불필요한 커스터마이징을 원한 결과, 아직까지도 많은 기업들이 앱 개발에 있어 서드파티 요소를 전혀 허용하지 않고 있다.

하지만 이것은 불필요한 고집이다.

모바일 중심, 클라우드 기반 앱 개발 환경에서 이러한 접근은 구식이라고밖에 표현할 수 없다. 자체 API및 SDK를 제공하는 강력하고 유연한 클라우드 서비스들을 활용한다면 기존의 앱을 이용해 훨씬 더 짧은 시간 안에 새로운 솔루션을 고안해 낼 수 있다. 여기서 가장 핵심은 ‘사용자의 워크플로우를 얼마나 완벽하게 꿰뚫고 있는가’다.

또한, 최소한의 커스터마이징만을 거친 채 출시할 수 있는 앱도 있다. 클라우드 기반 지출 관리 솔루션 컨커(Concur)나 ADP, 혹은 구글의 툴 수트 등은 모바일 앱 전략에 간편하게 사용할 수 있는 준비된 솔루션들이다. 이미 충분히 이용 가능한 도구가 준비되어 있고 주기적으로 업데이트도 되는 상태에서 굳이 모든 것을 기초 공사부터 시작할 필요는 없다.

2. 창대한 시작과 미약한 끝
배치할 앱을 결정할 때는 최대한 작은 규모로 사고해야 한다. 그래야만 실수가 대규모로 발생하는 것을 막을 수 있다. 많은 기업이 가장 사용률이 높고 중요한 앱을 모바일 및 클라우드로 먼저 이전하려고 하거나, 한번에 너무 많은 앱을 개발 하려 한다. 둘 다인 기업도 있다. 하지만 이렇게 해서는 안 된다. 처음 시작은 간결하고 간소한 것이 좋다. 그래야만 개발자, IT팀 및 최종 사용자가 변화에 서서히 적응하며 배워갈 수 있고, 문제가 생겼을 때에도 사소한 문제부터 해결해 나갈 수 있다. 처음부터 감당할 수 없는 규모의 문제에 직면하지 않아도 된다는 장점도 있다.

간소하게 시작할 때의 또 다른 장점은 손쉽게 개발 역량에 대한 신뢰를 얻을 수 있다는 것이다. 비교적 해결하기 쉬운 단순한 문제, 특히 개선 시 사용자의 생활을 눈에 띄게 개선해 줄 수 있는 문제점을 골라 공략한다면, 앱 개발 역량과 함께 모바일 우선적 비즈니스 접근도 성공적으로 해내고 있음을 보여줄 수 있다. 이렇게 얻은 정치적 자본은 향후 더 큰 규모의 프로젝트에 대한 지지와 금전적 지원을 받는 데 결정적인 밑거름이 된다.

3. 사용자를 고려하지 않은 앱 개발
사용자들이 직접 테크놀로지를 활용해 자신만의 솔루션과 워크플로우를 생성하는 것은 IT소비자화의 한 단면이다. 이는 모든 앱 프로젝트에서 최종 사용자들이 가장 중요한 역할을 맡고 있음을 의미한다. 이유는 간단하다. 앱이 사용자의 요구사항에 맞추지 못하거나 불편한 사용자 경험을 제공할 경우 사용자이 더는 그 앱을 사용하지 않기 때문이다. 설상가상으로, 이 경우 보안에 취약하고 다른 솔루션과 통합이 안 되는 솔루션을 이용하려 할 것이다.

앱 개발 시 사용자를 고려한다는 것은 대단한 것을 의미하는 게 아니다. 개발 회의에 일반 사용자를 한 두 차례 동석하게 하는 것만으로도 충분하다. 사용자가 맡은 직무, 업무에 요구되는 사항, 겪고 있는 어려움(앱 개발을 통해 풀어나가야 할 부분), 그리고 워크플로우 등을 이해할 수 있으면 된다. 일주일 가량 사용자와 함께 다니며 궁금한 점을 질문하고 이들의 요구사항을 파악한다면 최소한 사용자에게 외면 받는 앱을 만들 일은 없을 것이다.

앱 개발 단계에서 사용자의 요구를 반영하는 또 다른 방법은, 데스크톱에서 개발중인 앱에 해당하는 어플리케이션의 오리지널 사양을 참조하는 것이다. 이미 검증된 데스크톱 솔루션의 특성을 파악함으로써 사용자가 필요로 하는 것이 어떤 부분인지 알 수 있고, 추상적으로 사용자의 이야기만 듣거나 관찰하는 것보다 훨씬 더 앱 개발에 필요한 부분을 구체적이고 효과적으로 알려줄 수 있다.

4. 백엔드 시스템과 인프라가 앱을 감당할 수 있는지 확인하지 않는 것
모바일, 데스크톱, 웹 앱을 막론하고, 앱 디플로이먼트 시 자주 하는 실수가 바로 백엔드와 인프라를 점검하지 않는 것이다. 앱과 연결되는 백엔드 시스템이 온 프레미스인지, 프라이빗인지, 퍼블릭 클라우드인지, 외부 업체인지 관계 없이, 백엔드 시스템이 새로운 사용자 로드를 감당할 수 있는지 확인해야 한다. 또한, 앱 때문에 발생할 추가 트래픽을 감당할 만큼 무선 인프라가 튼튼한지도 확인해야 한다. 이때 가장 좋은 것은 선별된 사용자 그룹이 각기 다른 시간대에 액세스를 부여 받는 단계적 롤아웃 방식이다. 이러한 접근은 트래픽 요구사항을 쉽게 파악하고 필요할 때마다 인프라스트럭처를 수정할 수 있다는 장점이 있다.

5. 한두 가지 기기에서만 앱 테스트를 진행하는 것
앱을 여러 가지 기기에서 테스팅 해보지 않을 경우 골치 아픈 문제가 생길 수 있다. 앱을 새로 개발하거나, 기존 앱을 배치할 때, 테스트는 아주 중요한 부분이다. 데스크톱 사용 시절에는 테스팅이 어렵지 않았다. IT가 완벽히 통제할 수 있는 워크스테이션 설정이 정해져 있었고 적합한 데스크톱에서 테스트하기만 하면 아무런 문제가 없었기 때문이다.

모바일 및 BYOD 트렌드는 이런 관행을 완전히 바꾸어 놓았다. 이제 기업들은 다양한 하드웨어 사양, 화면 사이즈, 운영체제 버전, 사용자 설치 앱, 통신사, 네트워크, 액세서리 등 각양각색의 특징을 지닌 기기를 대상으로 테스트를 진행해야 한다. BYOD 및 혼합 사용 디바이스의 경우 사용자 행동과 디바이스상의 개인 데이터도 문제가 될 수 있다. 그러면서 테스트는 한층 더 중요해졌다.

이 문제는 특히 안드로이드 기기에서 심각한데, 바로 이런 이유로 기업 환경에서 iOS가 더 많이 사용되기도 한다. 안드로이드 OS의 파편화로 방대한 범위의 OS 버전이 사용되고 있고(아직까지도 안드로이드 킷캣을 사용하는 기기도 있다), 제조사도 통신사도 제각각에 엄격한 업데이트 프로세스까지 겹치면 앱 테스트는 생각보다 아주 복잡한 문제가 된다. 현재 수천 가지가 넘는 안드로이드 OS 베리에이션이 존재하며, 따라서 앱을 개발한다 해도 픽셀이나 갤럭시 등 대중적으로 사용하는 기기에서는 잘 작동하는 것들이 오래된, 혹은 로우 엔드 모델에서는 제대로 기능하지 않을 수 있다.

기기 수가 한정되어 있고 애플이 직접 운영체제 업데이트를 제공해 모든 아이폰 및 아이패드가 최신 버전의 OS를 구동하는 iOS 기기의 경우 이보다는 조금 상황이 낫다(지난주 WWDC에서 애플은 iOS 기기의 86%가 iOS 10을 구동한다고 발표했다). 그렇다고 해도, 아이폰 기기 중에서도 화면 사이즈나 하드웨어 사양이 다른 구형 제품에서는 앱을 사용할 때 문제가 발생할 수 있다.

안드로이드와 iOS, 두 가지 운영체제 외에 윈도우 10 모바일이나 윈도우 10 태블릿도 있다. 사용자 수는 그렇게 많지 않지만, 가능하다면 윈도우 모바일을 대상으로도 앱 테스트를 해 보는 것이 좋다.

즉, 가장 이상적인 것은 앱 테스팅 시 모든 최신 스마트폰과 가장 널리 사용되는 주요 제조사의 디바이스, 그리고 일부 초급 사양 기기까지 포함하는 것이다. 또, 최소 지난 3년 이내의 모든 운영체제 버전과 각각 다른 하드웨어 설정을 대상으로도 테스트해 보아야 한다.

글을 마치며
기업 앱 개발은 막대한 잠재성을 지닌 기대감을 일으키는 분야이다. 더 효율적이고 새로운 태스크 수행 방식을 제안하고, 생산성, 효율성을 높이며, 직원과 고객의 참여를 촉진한다. 하지만 그 이면에는 극복해야 할 문제들도 있다. 앱이 사용자의 요구를 충족하지 못하거나 제대로 기능하지 못한다면 직원들이 소외될 위험이 존재한다. 앞서 소개한 다섯 가지 실수를 하지 않도록 주의할 때, 성공적인 앱 개발도 어려운 일만은 아닐 것이다. editor@itworld.co.kr  


X