차세대 mWiSE 프로젝트가 시작되었다.
새로운 mWiSE에 대해 내가 고민하고 있는 포인트는 아래와 같다.
팀의 스킬셋
사내 앱이라는 특수성
앱 운영 구조
기존 레거시 시스템
직원들의 연령대(?)
앱 배포 환경과 현실
이 모든것이 한데 어우러져 폭발하는 기술 전략 회의가 잦다.
일단 프로젝트를 착수하기 전에 현실과 타협하는 설계가 필요하다.
국장님의 은퇴
기존 mWiSE는 네이티브 플랫폼(껍데기지만)으로 개발되었다.
iOS → Swift, AOS → Kotlin
로그인 이후에 외부 브라우저로 이동하기는 했지만 어찌됐든 몇몇 페이지만큼은 네이티브로 개발된 앱이었다.
하지만 문제는 우리팀에 (나를 제외한) 네이티브 개발자가 한 명도 없었다.
게다가 내가 존경하는 이국장님이 은퇴를 하시면서 "네이티브 지식"은 우리팀에서 존재하지 않았다.
반면 우리 팀은 2024년 선거 리빌딩 프로젝트를 하면서 React에 대한 스터디와 방향성을 잡았고, React 기반 프레임워크로 나아가려는 시도를 하고 있었다.
이 흐름속에서 자연스럽게 나온 결론이 "React Native가 답이 아닐까?"
하지만 내가 회의에서 다뤘던 RN의 리스크는 매우 많았다.
네이티브 모듈 직접 개발이 필요할수도 있다
OS별 UI 차이
WebView와 RN 사이의 통신 구현
성능 이슈
그래서 나는 팀 회의에서 RN의 장점 뿐만 아니라 단점과, 미래의 잠재적인 위험성까지 모두 테이블 위로 올렸고 팀장님과 2~3번의 토론이 이어졌다.
팀장님 : "그래도 지금 팀에서 네이티브 2개를 가져갈 수가 없지 않니?"
나 : "그렇긴 한데, RN으로 하면 이런 저런 문제가 분명히 있습니다"
팀장님 : "그래서 너를 믿는다"
나 : "???"
그렇게 어쩌다보니 RN으로 간다는 결정이 내려졌고, 자연스럽게 RN은 내가 책임지는 기술 스택이 되어버렸다.
사내앱이라는 특수성
사실 나는 앱 전체를 RN 네이티브로 UI를 구현하고 싶었다. 앱이니까 앱답게 만들고 싶었고, 원래 네이티브 앱 개발을 했었기 때문에 자신도 있었다.
하지만 현실적인 문제들이 있었다.
#1. 잦은 화면 교체와 긴급 대응
우리 사내앱은 의외로 잦은 요청에 의한 변경사항이 발생한다.
방송의 날 행사
특정 부서 요청으로 메인 화면 변경
일시적 공지 팝업
긴급 메시지 표현
이걸 만약 네이티브 앱 빌드로 인하우스 배포를 한다면, → 빌드 + 테스트 + 배포 FTP → 사용자 업데이트 단계가 훨씬 늘어나고 복잡해진다.
하지만 웹의 경우는 웹만 배포하면 끝이다.
물론 Github Action으로 위 과정을 구축할 수 있지만, 제한된 시간에 배포까지 설계하고 개발하기는 어려울 것 같다.
#2. 사내 엔터프라이즈 앱은 '업데이트'가 가장 어려운 일
mWiSE는 스토어 배포가 아닌 엔터프라이즈 인하우스 앱으로 배포한다.
그래서 앱을 업데이트하는 과정이 생각보다 누군가에게는 복잡하고 어려울 수 있다.
특히 연차가 높은 선배님들에게는 앱을 처음에 설치하거나, 새로 설치해야하는 경우 "앱 다운로드 링크를 누르시고, 다시 다운 받으시고, 무시하고 설치 누르시고..."의 과정이 큰 스트레스다.
새로운 배포 공지가 나가면 하루종일 우리 팀은 전화가 쉴 틈이 없다.
"앱 업데이트 하라고 계속 나오는데 버그아니냐?"
"링크 어디로 들어가야하냐?"
"앱 설치가 안된다"
"안드로이드 보안에 걸린다"
그래서 네이티브 앱 업데이트는 되도록 피하고 싶었다. 그래서 결론은
외부 브라우저로 나가지 않고 RN에서 웹뷰를 이용해서 웹앱을 개발하자
이 조합은 극도로 현실적인 선택이었지만 동시에 어려운 길이기도 하다.
RN과 WebView 간 상태 관리, 로그인 세션 동기화, 쿠키 처리 같은 문제를 해결해야한다.
기존 mWiSE는 기능이 너무 많았다. 10년 넘게 기능이 쌓이다보면 "메뉴의 박물관"이 되어버렸다.
우리는 "다시 다 만들자"라는 욕심 대신에 데이터를 기반으로 핵심 기능만 먼저 만든다는 전략을 선택했다.
DB에서 mWiSE 사용자 로그를 분석한 후, 월간/연간 메뉴 사용량을 확인하고, 부서별로 사용하는 메뉴를 정리했다.
위 데이터를 바탕으로 "직원들이 정말로 사용하는 기능" TOP 14를 선정했다.(ex. 식단조회, 시청률, 휴가신청.)
이 기능들을 RN + WebView 방식으로 구현하고 나머지는 추후 확장하는 방식을 택했다.
하지만 mWiSE가 사용하는 API는 DB2 + Domino 기반의 레거시임을 생각해야했다.
만약에 선배들과 스프링으로 API를 새로 만든다면, 스키마 정리 + 비즈니스 로직 재구성 + 검증 + 테스트 과정이 필요한데.
이 과정만 앱 개발전에 족히 3개월은 걸릴 것 같았다.
상상하기 어렵겠지만 급여와 관련한 API는 하나의 파일만 해도 코드가 4~5000줄인 코드가 있다.
그리고 이렇게 크리티컬한 API의 경우에는 수정하기가 훨씬 어렵다.
기존 API의 경우 유지보수는 매우 어렵고 불가능하지만...
이미 수십년간 운영되면 안정성이 검증
많은 API가 서로에게 의존
갑자기 바꾸면 무슨일이 생길지 모름
이런 상황에서 API까지 개발하는것은 위험한 모험이었다. 그래서 결론을 기존 API를 존중하며 그대로 사용하는 방향으로 잡았다.
이처럼 우리가 내린 결론은 기술적 우월함이 아닌, 사내 환경·운영 방식·사용자 특성·팀 역량을 모두 고려한 가장 현실적인 선택이다.
기술선택은 결국 "현실과의 싸움"이다.
끝