업무 시스템을 모바일 앱으로 만들어야 합니까, 반응형 웹이면 됩니까?

갈림길은 「기기에 얼마나 기대는가」입니다

앱이냐 웹이냐를 정할 때 「앱이 더 제대로 된 시스템처럼 보인다」는 인상이 판단을 이끄는 경우가 있습니다. 그러나 사내 업무 시스템에서 사용자는 이미 정해져 있고, 앱스토어에서 발견될 필요도 없습니다. 판단 기준은 인상이 아니라 업무가 휴대폰의 기능에 얼마나 기대는가입니다.

웹 쪽의 한계로 꼽히던 알림은 상당 부분 해소됐습니다. WebKit 팀은 iOS·iPadOS 16.4부터 홈 화면에 추가한 웹 앱이 웹 푸시를 받을 수 있다고 발표했습니다. 다만 사용자가 먼저 웹 앱을 홈 화면에 추가해야 하고, 알림 권한 요청은 사용자의 직접적인 동작에 응답해서만 띄울 수 있습니다. 직원에게 처음 한 번 설치 안내를 해야 한다는 뜻입니다.

비용은 만드는 시점보다 운영하는 기간 동안의 차이가 더 큽니다. 앱은 운영체제가 해마다 새 버전을 내놓을 때마다 동작을 확인해야 하고, 스토어 정책이나 개발자 계정 갱신 같은 관리 업무가 계속 따라옵니다. 웹도 브라우저 변화에 대응해야 하지만 관리할 코드가 한 벌이라는 점에서 부담의 크기가 다릅니다. 견적을 비교할 때는 구축 금액과 함께 이 운영 부담을 누가 어떻게 맡는지도 확인하십시오.

앱이 맞는 업무

다음 조건 가운데 하나라도 업무의 핵심이라면 앱을 진지하게 검토할 때입니다. 핵심이 아니라 가끔 쓰는 부가 기능이라면 웹으로 시작해도 충분한 경우가 많습니다.

• 창고·지하·현장처럼 통신이 끊긴 채 오래 입력해야 하는 업무
• 카메라로 바코드를 연속해서 대량으로 읽어야 하는 입출고 업무
• 앱이 닫혀 있어도 위치를 기록해야 하는 배송·방문 업무
• 블루투스 프린터·계측기 같은 현장 장비와 연결해야 하는 업무
• 기기 분실 시 원격 잠금처럼 기기 관리 정책과 묶어야 하는 업무

이 기능들도 브라우저에서 일부 지원되는 경우가 있지만, 지원 범위가 브라우저와 운영체제마다 다릅니다. 그래서 결론을 내기 전에 실제 직원이 쓰는 기기에서 웹으로 그 기능을 먼저 시험해 보는 것이 가장 확실합니다. 시험해서 되면 웹으로, 안 되면 그 기능만 앱으로 가는 순서입니다.

중간 선택지도 있습니다. 하나의 코드로 두 운영체제용 앱을 함께 만드는 크로스플랫폼 방식은 앱이 꼭 필요하지만 유지 부담을 줄이고 싶을 때 검토할 만합니다. 또 웹 화면을 앱 껍데기 안에 담고 카메라나 장비 연결처럼 꼭 필요한 기능만 앱이 맡는 구성도 있습니다. 어느 쪽이든 앱으로 가는 이유가 된 기능이 그 방식에서 제대로 동작하는지를 먼저 확인해야 합니다.

사내 앱 배포는 스토어 공개가 아니어도 됩니다

앱을 택하면 「스토어에 공개해야 하나」를 걱정하는 경우가 많지만, 조직 내부 배포 방법이 따로 있습니다. Apple은 대부분의 조직에 일반 Apple Developer Program을 권하며, 그 안에서 Apple Business나 Ad Hoc 배포로 직원에게 맞춤 앱을 비공개 배포하고, TestFlight로 베타 버전을 시험할 수 있다고 안내합니다. 직원 전용 앱을 직접 배포하는 Apple Developer Enterprise Program은 직원 100명 이상의 법인만 신청할 수 있고, 다른 방법으로 해결되지 않는 특정한 경우에만 쓰도록 하며 별도 심사를 거칩니다.

Android 쪽은 관리형 Google Play의 비공개 앱으로 특정 조직에만 앱을 배포할 수 있고, 관리자가 기기 관리 콘솔에서 사용자에게 배포합니다. 어느 쪽이든 계정 명의는 개발사가 아니라 회사 명의로 만들어야 나중에 개발사가 바뀌어도 앱을 계속 업데이트할 수 있습니다.

기기를 회사가 지급하는지, 직원 개인 휴대폰을 쓰는지도 배포 방식을 정합니다. 회사 지급 기기라면 기기 관리 솔루션으로 앱 설치와 분실 시 잠금까지 한 번에 관리할 수 있지만, 개인 휴대폰에 회사 관리 도구를 설치하는 것은 직원의 동의와 사생활 보호 문제가 함께 따라옵니다. 개인 기기 사용이 많은 회사라면 그 점만으로도 웹이 유리해집니다.

웹은 이 절차가 모두 필요 없습니다. 배포 경로가 단순하다는 것은 업무 시스템에서 생각보다 큰 장점입니다. 수정 사항을 바로 반영할 수 있고, 직원마다 설치된 버전이 달라 생기는 문의도 없습니다. 퇴사자의 접근을 막는 일도 계정 하나를 정지하는 것으로 끝납니다.

판단 순서

1. 기기 의존 기능 표시업무 목록에서 카메라·위치·오프라인·장비 연결이 필요한 항목에 표시합니다
2. 대상 기기에서 웹으로 시험직원이 실제로 쓰는 휴대폰에서 그 기능이 웹으로 되는지 확인합니다
3. 안 되는 기능만 앱 후보로웹으로 안 되는 기능이 업무의 핵심인지 다시 따져 봅니다
4. 서버와 API는 한 벌로웹과 앱이 같은 서버 기능을 쓰도록 설계해 이중 개발을 피합니다
5. 배포와 기기 관리 방식 결정회사 명의 계정, 내부 배포 경로, 분실 대응 절차를 정합니다

넷째 단계가 특히 중요합니다. 웹으로 시작하더라도 서버 기능을 화면과 분리해 두면, 나중에 현장용 앱이 필요해졌을 때 서버를 다시 만들지 않고 앱 화면만 더할 수 있습니다. 처음부터 앱과 웹을 모두 만들 필요는 없지만, 나중에 앱을 붙일 수 있는 구조로 시작하는 것은 부담이 작은 대비입니다.

웹이든 앱이든 접근성은 함께 봅니다

방식과 관계없이 확인할 것이 하나 있습니다. 장애인차별금지법 제21조는 정보통신망으로 정보나 서비스를 제공할 때 웹사이트뿐 아니라 스마트폰에 설치되는 응용 소프트웨어도 장애인이 동등하게 이용할 수 있도록 정당한 편의를 제공하도록 정하고 있고, 시행령이 정한 단계에 따라 2024년 7월 28일부터는 상시 근로자 100명 미만 사업자까지 그 대상에 들어왔습니다. 직원용 시스템이라도 화면 낭독, 글자 확대, 충분한 명도 대비 같은 기본 요소를 처음 설계부터 넣어 두면 나중에 고치는 비용이 크게 줄어듭니다.

참고 자료

• WebKit Blog — Web Push for Web Apps on iOS and iPadOS
• Apple Developer — Apple Developer Enterprise Program
• Google Play Help — Managed Google Play private apps
• 장애인차별금지 및 권리구제 등에 관한 법률 제21조 — 국가법령정보센터