인프런 커뮤니티 질문&답변
작성한 질문수
UI 자체를 DB 에 의존하는 것에 관해
해결된 질문
작성
·
74
1
확장적인 사고를 통해 UI 를 컴포넌트화 했다는 점에서 일종의.. 개발자들의 자동화 욕망을 구현해내신게 아닐까 싶었습니다! 한창 듣는 중인데 너무 부럽기도 하고, 강의 해주셔서 감사하다는 말씀을 먼저 드립니다 ㅎㅎ
(질문)
앱 클라이언트가 매우 적은 역할을 하고 서버에서 모든 것이 그때그때 정의된다면, 마치 하이브리드 앱처럼 앱 업데이트를 개발자가 (거의) 실시간 강제할 수 있는 권한이 생기는 것인가요? 극단적인 예시를 들자면 app id 101 와 102 응답이 서로 바뀌면, 사용자 입장에서는 완전히 다른 앱이 로드되는 것도 이론적으론 가능한 것 같아서요. 생각해보면 은행 앱들이 켤 때마다 새 데이터를 매번 받아오고 무결성 검사를 하는 것 같기도 하고요.. 🤔
이렇게 UI 를 lazy loading(?) 하는 부분에서 구글 쪽 정책에 제한은 없는지, 이런 아키텍처를 설계한 뒤로 느끼신 단점은 없었는지 궁금합니다! 통과는 해두고 출시 후에 완전히 다른 앱으로 바뀔 가능성이 있다면 플레이스토어에서 가만 두지 않을(?) 것 같다는 생각이 들어서요!
(앗 혹시 제가 런타임과 빌드타임 구분된 설명을 전부 런타임으로 오해한 것일까요..? 😅)
답변 1
1
안녕하세요! 좋은 질문 감사합니다.
말씀하신 대로, 제가 구현한 아키텍처에서는 서버의 DB 값만 변경하더라도 앱의 동작과 UI가 크게 달라질 수 있습니다. 예를 들어, App ID 1번으로 출시된 앱의 서버 응답 데이터를 2번과 같이 변경하면, 사용자들은 전혀 다른 앱을 경험하게 될 수 있죠.
하지만 이는 구글 플레이스토어 정책에 위배될 수 있는 부분입니다. 경험상 작은 UI 변경이나 기능 개선 정도는 허용되지만, 앱의 성격이 완전히 바뀌거나 큰 폭의 변경이 있는 경우에는 경고나 앱 삭제 조치를 받을 수 있습니다. (실제로 이런 경험이 있습니다) 그래서 저의 경우 치명적인 버그나 오류가 아닌 이상 한번 설정된 서버 데이터는 크게 수정하지 않으려고 합니다.
그리고 네, 이 아키텍처는 런타임에 해당합니다. 앱이 실행되는 시점에 서버로부터 데이터를 받아와서 UI를 그리는 방식이기 때문입니다. 빌드타임에 결정되는 것이 아니라 실행 시점에 동적으로 UI가 결정된다고 보시면 됩니다. 😄