VIPER

VIPER란?

VIPER는 View, Interactor, Presenter, Entity, Router의 약자로, 각 컴포넌트가 명확한 역할을 가지고 있어 책임 분리와 코드의 재사용성을 높이는 데 목적이 있습니다. VIPER는 클린 아키텍처의 원칙을 따르고 있으며, 코드의 유지보수성을 극대화하기 위해 각 컴포넌트를 독립적으로 나누는 것을 목표로 합니다.

---

 

VIPER의 구성 요소

 

1. View (뷰)

View는 사용자 인터페이스를 담당합니다. 사용자에게 데이터를 보여주고, 사용자의 입력을 받아서 Presenter에게 전달하는 역할을 합니다. 중요한 점은 View는 데이터를 처리하거나 비즈니스 로직을 실행하지 않고, 단지 화면에 나타내는 역할만 합니다.

 

2. Interactor (인터랙터)

Interactor는 비즈니스 로직을 처리하는 곳입니다. 데이터베이스, API 호출 또는 기타 외부 시스템과 상호작용하며, 데이터를 가공한 후 Presenter에게 전달합니다. Interactor는 View에 대한 정보를 가지지 않으며, 오직 Presenter와만 통신합니다.

 

3. Presenter (프레젠터)

Presenter는 View와 Interactor 사이의 중재자 역할을 합니다. Interactor로부터 데이터를 받아 View에 전달하기 전에 적절히 가공합니다. 이때 Presenter는 View의 구체적인 구현에 대해 알지 못하며, View가 Presenter에서 전달받은 데이터를 어떻게 표시할지는 오직 View의 책임입니다.

 

4. Entity (엔티티)

Entity는 애플리케이션에서 사용하는 데이터 모델을 정의합니다. Interactor에서 주로 사용되며, Presenter와 Interactor 간의 데이터를 주고받는 데 중요한 역할을 합니다. 예를 들어, API로부터 응답받은 데이터나 데이터베이스의 데이터를 모델링합니다.

 

5. Router (라우터)

Router는 화면 전환과 모듈 간의 내비게이션을 담당합니다. VIPER에서 Router는 화면 간 전환뿐만 아니라, 특정 화면으로 데이터를 전달하는 역할도 합니다. 각 화면이 독립적일 수 있도록 화면 간의 의존성을 줄이는 데 중요한 역할을 합니다.

 

 

구성요소

 

---

 

 

VIPER의 주요 특징

1. 단일 책임 원칙 (Single Responsibility Principle)
   각 컴포넌트는 단 하나의 책임만을 갖도록 설계되었습니다. View는 UI만 담당하고, Interactor는 비즈니스 로직만 처리하는 식으로 각자 역할이 명확히 나누어져 있습니다. 이를 통해 코드의 복잡성을 줄이고, 변경 시 영향을 최소화할 수 있습니다.
2. 모듈화 (Modularity)
   VIPER의 구조는 모듈 단위로 코드가 분리되어 있어서 독립적으로 개발, 유지보수, 테스트가 가능합니다. 예를 들어 새로운 기능을 추가할 때 특정 모듈만 수정하면 되며, 나머지 코드에 영향을 미치지 않도록 할 수 있습니다.
3. 테스트 용이성 (Testability)
   VIPER는 각 컴포넌트가 독립적이므로, 단위 테스트를 작성하는 것이 용이합니다. 특히 비즈니스 로직을 처리하는 Interactor는 UI와 무관하게 테스트할 수 있어, 기능을 검증하는 테스트 작성에 큰 장점을 제공합니다.
4. 유지보수성 (Maintainability)
   모듈화된 구조 덕분에 코드베이스가 커지더라도 관리가 용이합니다. 수정 사항이 있을 때, 영향을 받는 컴포넌트만 수정하면 되므로 다른 부분에 문제가 발생할 가능성이 적습니다. 이는 특히 대규모 프로젝트에서 매우 유리합니다.
5. 확장성 (Scalability)
   VIPER는 새로운 기능을 추가할 때 기존 코드와 충돌하지 않고 확장할 수 있는 구조를 갖추고 있습니다. 각각의 컴포넌트가 독립적이기 때문에 기능을 추가할 때에도 해당 모듈에만 변경을 가하면 됩니다.

---

 

VIPER의 단점

 

1. 초기 설정의 복잡성
VIPER는 각 컴포넌트가 독립적이기 때문에 처음 프로젝트를 설정할 때 설정해야 할 파일과 코드가 많아 복잡할 수 있습니다. 특히 작은 프로젝트에서는 이 구조가 과할 수 있습니다.

 

2. 코드가 길어질 수 있음
VIPER는 각 기능을 분리하는 것이 장점이지만, 그로 인해 단순한 기능에도 많은 파일과 코드가 필요할 수 있습니다. 이로 인해 코드베이스가 비대해질 수 있으며, 각 컴포넌트 간의 의존성을 신경 써야 하는 부담이 있습니다.

 

---

결론

VIPER 아키텍처는 iOS 앱의 복잡성이 증가할 때, 특히 대규모 프로젝트나 팀 단위로 개발하는 경우 매우 유용한 구조입니다. 모듈화와 단일 책임 원칙을 잘 따르는 VIPER는 유지보수와 확장성을 극대화하며, 코드의 품질을 높이는 데 많은 도움이 됩니다.

하지만 VIPER는 초기 설정이 복잡하고 코드가 길어질 수 있으므로, 프로젝트의 성격에 맞춰 신중하게 선택하는 것이 중요합니다. 하지만 장기적인 유지보수나 확장성을 고려한다면 VIPER도 충분히 좋은 아키텍처 같습니다.

 

이후에 VIPER를 실제로 사용해 보면서 기록해보겠습니다.