앱 안에서 새로운 웹서비스를 제공하는 일을 처음 검토했을 때는 구조가 비교적 단순해 보였습니다.

앱에서 WebView를 열고, 웹에서 화면을 만들고, 필요한 기능은 브릿지를 통해 앱에 요청하면 된다고 생각했습니다.

하지만 실제 화면 흐름을 하나씩 살펴보니 기술 스택보다 먼저 정해야 할 것이 있었습니다. 앱과 웹, 서버가 각각 어디까지 책임질 것인지에 대한 기준이었습니다.

작은 기능마다 경계가 드러났습니다

로그인, 화면 이동, 뒤로가기, GNB, 바텀시트, 전자서명은 각각 하나의 기능처럼 보입니다.

그런데 하이브리드 앱에서는 이 기능들이 앱과 웹의 경계에 걸쳐 있었습니다.

로그인 화면은 앱에서 제공하지만 웹은 로그인 결과를 이어받아 원래 업무로 돌아가야 합니다. GNB는 앱이 그리지만 웹 콘텐츠가 가려지지 않도록 레이아웃을 맞춰야 합니다. 전자서명은 앱에서 수행하더라도 서버가 실제 업무 요청과 서명 원문을 다시 확인해야 합니다.

어느 한쪽에서만 결정하면 다른 영역에 예외 처리가 쌓이기 쉬운 구조였습니다.

역할이 불분명하면 화면마다 구현이 달라집니다

기준이 없는 상태에서는 화면 개발자가 필요할 때마다 브릿지를 직접 호출할 수 있습니다.

어떤 화면은 앱 환경을 가정하고, 다른 화면은 브라우저 실행을 고려합니다. 앱 버전에 따라 지원되지 않는 기능을 각 화면에서 따로 처리할 수도 있습니다.

처음에는 빠르게 구현할 수 있지만 화면이 늘어날수록 호출 방식과 예외 처리도 함께 늘어납니다. 문제가 발생했을 때 앱과 웹 중 어디에서 확인해야 하는지도 모호해집니다.

이번 프로젝트에서는 개별 기능보다 먼저 역할을 정리하기로 했습니다.

앱, 웹, 서버의 역할을 나누었습니다

앱은 네이티브 기능과 앱 전체의 일관된 사용자 경험을 담당합니다. 로그인, 전자서명, 앱 화면 이동처럼 단말과 앱 환경이 필요한 기능이 여기에 포함됩니다.

웹은 업무 화면과 콘텐츠를 빠르게 제공하고 변경하는 역할을 맡습니다. 다만 앱 기능을 직접 호출하는 방식은 공통 Wrapper 안으로 감추고, 화면에서는 일관된 인터페이스를 사용하도록 했습니다.

서버는 클라이언트에서 전달된 결과를 그대로 신뢰하지 않고 업무 처리에 필요한 기준을 다시 검증합니다. 인증 상태와 요청 데이터, 전자서명의 원문 관계처럼 신뢰가 필요한 판단은 서버의 책임으로 두었습니다.

이 구분이 모든 상황의 정답은 아닙니다. 다만 현재 구조에서는 각 영역이 잘할 수 있는 일과 반드시 책임져야 할 일을 나누는 기준이 되었습니다.

기술보다 먼저 합의해야 했던 것

WebView 서비스는 웹 화면을 앱에 넣는 방식만으로 설명하기 어려웠습니다.

앱과 웹이 함께 움직이는 순간마다 누가 상태를 관리하고, 누가 사용자 경험을 책임지며, 누가 최종적으로 신뢰를 판단할지 정해야 했습니다.

이 기준이 먼저 정리되자 Bridge, GNB, 로그인, 전자서명 같은 후속 논의도 조금 더 같은 방향에서 이야기할 수 있었습니다.

하이브리드 앱에서 가장 먼저 만들어야 하는 것은 화면이 아니라, 앱과 웹과 서버가 함께 지킬 역할의 경계인지도 모르겠습니다.