앱을 만들어 넘기고 운영은 다른 팀이 하는 계약이 있습니다. 그 계약에서는 스택이 출시 날에 최적화됩니다. 비엔코드가 적는 AIO는 반대입니다. 개발, 스토어 출시, 유지관리를 한 팀이 보면, 고치기 어려운 구조는 견적 단계에서 탈락합니다. 스택 선택의 숨은 조건이 여기 있습니다.
그래서 크로스플랫폼을 자주 고릅니다. 안드로이드 버그 수정을 iOS에 한 번 더 포팅하는 구조는, 유지보수가 같은 팀일 때 비용이 두 번 청구되는 것과 같습니다. React Native나 Flutter로 목록과 폼을 공유하고, 기기 전용 화면만 나누면 야간 수정이 한 커밋이 됩니다. Unity로 장면을 만든 제품도 같습니다. 장면을 아는 사람이 출시 후에 남아 있어야 수정이 됩니다.
서버도 출시 기준으로만 만들지 않습니다. 관리자 권한, 비밀 분리, 마이그레이션을 되돌리는 방법, 오류 알람을 받을 주소. 이것들이 기능 티켓과 같이 닫혀야 인도가 끝납니다. 파이랩이 자사 서비스에서 지키는 배포 습관과 같은 문장입니다. SI라고 예외가 되지 않습니다.
의뢰하는 쪽에서 확인할 질문도 단순합니다. 출시 다음 달의 문구 수정과 작은 상태 변경을 누가 어느 저장소에 넣는가. 답이 메일 첨부라면 스택이 아직 운영을 모릅니다. 답이 미리보기 주소와 롤백이라면 그 팀은 유지보수까지 설계한 것입니다.
