[아키텍처] 모바일 앱 아키텍처 설계 방법

성공적인 앱을 개발하기 위해서는 매력적인 UI 디자인만으로는 부족하다.
편리한 기능과, 빠른 속도, 보안, 구조적 뛰어남이 있어야 하고 치명적인 에러가 없어야 한다.
다시 말해서, 신중하게 모바일 앱 아키텍처를 설계해야 한다.

 

모바일 앱 아키텍처란?

 

모바일 앱 아키텍처는 모바일 어플리케이션을 개발하는 방법에 대한 규칙들, 기술들과 패턴들의 본질이다.

즉, 아키텍처 설계는

• 기술 스택이 어떤지,
• 구조가 어떻게 이루어져 있는지,
• 데이터를 어떻게 관리할 것인지

에 대한 고민들을 포함한다.

 

사용자의 요구사항 파악 (요구 공학)

 

아키텍처를 설계할 때 소프트웨어 개발자들이 따라야 할 세 종류의 원칙이 있다:

 

1. SOLID - 유지 보수가 쉽고 확장성이 좋은 앱을 만들기 위한 객체 지향 설계의 5가지 원칙

2. KISS - 에러를 최소화하기 위해 시스템과 코드를 간단하게 만드는 원칙

3. DRY - 불필요하게 장황해지는 것을 피하기 위해 소프트웨어 패턴에서 반복을 줄이는 원칙

 

+이에 더해서 클린 아키텍처에 초점을 맞추어야 한다. 앱의 각 계층이 다른 계층이나 외부 프로그램에 의존하지 않아야 한다는 뜻이다. 독립적인 계층들 사이의 전환이 바운더리들을 통해 이루어진다면, 서로 다른 계층 영역을 연결짓기 위해서는 의존성 주입을 사용한다. 여기서 바운더리란 계층 간에 데이터를 옮길 때 사용할 수 있는 입/출력 포트를 말한다.

 

아키텍처 패턴 정의

가장 유명한 아키텍처 패턴은 3계층 아키텍처이다. Presentation 계층, Business 계층, Data 계층으로 이루어져 있다.

스프링에서의 3 계층 아키텍처

• Presentation 계층
  • 모바일 앱을 사용하는 사용자가 직접 보고 느끼는 부분을 말한다. 구현 과정이 UI 와 UX 디자인에 집중되어 있는 계층이다. UX/UI 디자인은 폰트, 테마, 색, 앱 네비게이션 직관성, 앱과 연결할 수 있는 주변기기 등을 포함한다.
• Business 계층
  • 데이터를 주고받고 앱이 동작하는 것을 책임지는 계층이다. 이 계층은 데이터 검증, 캐싱, 로깅, 예외 처리 그리고 그 외 다른 작업들의 구현에 집중되어 있다. 이외에도 비즈니스 규칙, 복잡한 비즈니스 과정, 규제를 구현한다.
• Data 계층
  • 데이터의 보안과 유지 보수를 담당한다. 데이터에 접근하는 요소들, 서비스 도구들, 그리고 유틸리티들로 이루어져 있다. 이 계층을 구축할 때에는 미래에 비즈니스 요구사항에 따라 확장될 수 있다는 것을 염두해야 한다. 또 잘못된 데이터 입력과 기능들로부터 안전할 수 있도록 데이터 접근과 검증에 대한 올바른 기술을 선택해야 한다.

 

모든 아키텍처들은 하나의 목표를 지향한다; 바로 관심사의 분리이다.

 

앱의 종류에 따른 아키텍처 설계

 

모바일 앱을 개발할 때에 일어나는 다양한 선택들의 기준으로는 대상 고객, 배포되는 플랫폼, 앱에 포함하고자 하는 특성들과 기능들, 앱 개발에 투자할 수 있는 시간과 재정, 그리고 개발 팀의 기술력이다.

앱 아키텍처를 정의하는 몇 개의 주요 앱 종류가 있다:

 

1. 네이티브 앱

 

네이티브 앱이란 스마트폰에 기본으로 내장되어 있는 앱들이나, 게임과 같이 특정 플랫폼 (안드로이드 또는 IOS) 에서만 작동하도록 개발된 앱을 말한다.

• 장점
  • 오프라인에서도 작동하며, 사용자 친화적이고 빠르다.
  • 플랫폼이 제공하는 여러 네이티브 앱들에 대한 접근성이 높다. (예. 카메라, 마이크, GPS 등)
• 단점
  •  잦은 업그레이드를 요구하고, 개발하는데 막대한 비용과 시간이 들어간다.
  • 특정 플랫폼에 한정되어 있어서 사용된 코드는 다른 플랫폼에서 같은 서비스를 제작하더라도 사용할 수 없다.

 

대표적인 두 개의 플랫폼: Android 와 IOS

안드로이드와 IOS 는 모바일 앱 플랫폼 분야의 양대 산맥과 같다.

	안드로이드	IOS
아키텍처 구조와 사용 근거	많은 시행착오를 거쳐서 안드로이드 앱에는 클린 아키텍처가 가장 적합하다는 결론에 도달했다. 그 이유는 아키텍처 계층을 서로 분리해 두었기 때문이다. 각 계층은 독립적이지만 동시에 서로 상호작용이 가능하다.	애플 사에서 제공하는 가이드라인에 따르면 MVC 모델을 기반으로 한 아키텍처가 가장 적합하다.
구조의 구성요소	- Entities - Use Cases, Interactors - Interface Adapters - Frameworks and Drivers	- Model - View - Controller (제어기)

 

클린 아키텍처와 MVC 모델 (왼쪽부터)

 

Note
클린 아키텍처는 각 계층들과 그 사이의 관계를 중첩된 원들로 나타낸다. 각 계층은 독립적이기는 하지만 영역이라는 개념을 사용해 계층 간의 소통에 필요한 인터페이스 - 입력 포트와 출력 포트로 이루어진 - 를 제공한다.

2. 하이브리드 앱

사실 하이브리드 앱은 웹 기반 기술을 네이티브 앱으로 감싼 것이라고 생각하면 된다. 웹 기반 기술을 사용해서 하나의 플랫폼에 종속되지 않을 수 있다. 앱의 내용은 웹 서버로부터도 접근이 가능하게 된다. 웹 어플리케이션을 네이티브 앱의 화면에 담은 것이라고 생각하면 된다.

• 장점
  • 네이티브 앱에 비해 개발 비용이 저렴하며 유지보수가 쉽다.
  • 웹으로부터 온라인 상에서 접근하지만 디바이스의 네이티브 앱들 (카메라, GPS 등) 에 접근 가능하다.
• 단점
  • 오프라인에서는 작동하지 않고, 네이티브 앱에 비해서는 매우 느리다.
  • 디바이스에 따라 자원을 활용할 수 있을 수도, 없을 수도 있다.
  • 두 플랫폼 (안드로이드와 IOS) 모두에서의 성능이 높고 동일하기를 기대하기는 어렵다.

Note
하이브리드 앱 개발자는 두 플랫폼 모두에게 적합한 코드를 작성하고자 하는 목표가 있다. 이를 위해 네이티브 앱의 코드와 웹 어플리케이션 코드를 섞는다. 정확하게는 웹 기반으로 앱을 만든 후 이를 wrapper 를 사용해서 모바일 OS 의 API 와 상호작용하도록 만든다.

3. 모바일 웹 앱

모바일 웹 앱은 사실상 디바이스에 설치되는 것이 아니라 브라우저에 URL 을 통해 접속되며 스마트폰 배경화면의 아이콘에  링크를 걸어두고 북마크로 사용한다.

• 장점
  • 웹 어플리케이션이기 때문에 다른 고지나 승인 없이 자동적으로 업데이트를 할 수 있다.
  • 브라우저를 통해 동작하기 때문에 플랫폼의 제약 없이 사용할 수 있어서 넓은 범위의 사용자를 타겟할 수 있다.
  • 어플리케이션의 유지보수가 쉽고 비용이 저렴하다. 브라우저만 있으면 모두 하나의 앱으로 접속하기 때문이다.
• 단점
  • 화면 크기에 따라 최대한 동적으로 바뀌도록 만들겠지만, 모든 화면에서 적절한 크기로 보여지지는 않을 것이다.
  • 디바이스의 네이티브 앱들에 접근 권한이 없다.

출처 

https://docs.google.com/document/d/1ZoYNFFs6SQWdxRe3g8PtAxTF9MNrAQ21fBTgG250ey4/edit

기능 정의서 ex

https://scand.com/company/blog/the-ultimate-guide-to-mobile-application-architecture/

Mobile App Architecture How to Choose the Right One | SCAND