Three-tier Architecture

1. Presentation Tier
   - 사용자에게 보이는 부분을 담당
   - React, Native App ...
   - Frontend, Mobile
2. Application Tier
   - 서비스와 관련된 기능과 정책 등등 비지니스 로직을 담당
   - Spring, Django
   - Backend
3. Data Tier
   - 데이터를 저장, 관리, 제공 역할
   - MySQL, Oracle, MongoDB
   - DBA

Three-tier Architecture는 각 계층의 목표는 분명하다.

Presentation Tier

Presentation Tier는 사용자와 상호작용하는 계층이다. 이 영역에 해당하는 개발자는 Frontend, Mobile 개발자가 될 수 있다. 이 영역에서의 가장 중요한 목표는 사용자와의 상호작용을 적절히 처리하고, UI / UX를 통한 고객경험을 높이는 것이다.

이 영역에서 주의할 점은 Application Tier에서 처리해야 할 비지니스 로직을 과도하게 위임하지 않는 것이 중요하다. 추가로 이 영역에서 발생하는 네트워크 I / O는 인터넷을 통해 발생하므로 불필요한 I / O는 발생시키지 않도록 하는 게 중요하다. (여러 번 인터넷을 통한 네트워크 I / O를 발생시키지 않고 한 번에 서버에서 처리할 수 있는 방안을 고민하는 것이 중요하다.)

Application Tier

Application Tier는 서비스의 비지니스 로직을 처리하는 중요한 계층이다. 이 영역에 해당하는 개발자는 백엔드 개발자가 될 수 있다. 이 영역에서의 가장 중요한 목표는 서비스의 비지니스 로직을 처리하는 것이다. 그렇다면 비지니스 로직이란 무엇일까 비지니스 로직은 여러 서비스와의 소통, 데이터베이스와 소통을 복합적으로 수행하여 현실세계의 문제(도메인)를 해결하는 로직을 말한다. 즉, 백엔드 개발자는 이러한 사실을 이해하고 비지니스의 특정 기능에 맞게 여러 복합적 요소의 절차를 논리적으로 작성하는 것이 중요하다. 이러한 관점에서 백엔드 개발자는 비지니스를 잘 이해하고 비지니스에서 발생하는 데이터의 성격을 잘 이해하는 것이 매우 중요하다.

외부와 상호작용은 그냥 우리어지는 것이 아니라 여러 복합적인 환경 설정과 보조로직에 의해 이루어진다. 즉, 비지니스 로직은 보조로직의 집합체로 해석할 수 있다. 여기서 이야기하는 보조로직은 외부의 서비스와 통신, 명령하기 위한 코드, DB와 통신, 명령하기 위한 코드(Ex) SQL)를 이야기한다. Hexagonal Architecture로 해석하면 외부의 Out Adapter에 해당한다. 비지니스로직은 특정 비지니스의 기능이 올바르게 수행할 수 있는 논리를 책임지고, 보조로직은 실질적인 성능을 책임진다고 할 수 있다. 비지니스 로직의 논리가 옳다고 성능이 향상되는 것은 아니다. 성능을 향상시키기 위해서는 비지니스의 논리를 올바르게 보존하고 쿼리튜닝과 같은 보조로직의 튜닝에 집중해야 한다. 예를 들어 JPA N + 1문제가 생겨도 비지니스의 기능은 수행된다. 결론적으로 우리 백엔드 개발자는 비지니스 논리를 올바르게 작성하는 것과 성능을 향상시키는 것은 다르다는 것을 인지해야 한다.

위의 단락에서 이야기한 관점을 잘 이해하면 관심사 분리의 중요성을 알 수 있다. 관심사 분리가 잘 되어야 무엇이 문제이고 무엇에 집중하여 개선할지가 분명해지기 때문이다. 관심사 분리를 잘하기 위해서 원칙이 필요하고 이러란 원칙을 지키기 위한 토대가 아키텍쳐라 할 수 있다. 개인적으로 서비스의 로직과 성능의 관심사에 대해 분리를 잘한 Architecture는 Hexagonal Architecture라 생각한다. 기회가 된다면 Hexagonal Architecture를 참고해보면 좋을 거 같다.

추가로 이 영역에서 주의할 점은 I / O를 최대한 최소화 시킬 수 있는지 확인하고, I / O를 짧게 끊어줄 수 있으면 짧게 끊어주는 것이 매우 중요하다. 그리고 Presentation Tier은 한 명의 사용자에게 개인화된 특징이 있는 반면 서버는 개인화된 여러 다수 사용자가 동시에 수많은 요청을 할 수 있다는 점을 이해하고 대응하는 것이 중요하다. 이 부분은 CPU, RAM, Thread의 지표를 잘 확인하여 특정 문제가 되는 지표에 대해 분석하여 튜닝을 진행하고 추가로 Infra 영역에서 Scale-In, Scale-Out으로 해결을 기대할 수 있다. 더 나아가 Blocking I / O, NonBlocking I / O의 관점을 도입해서 해결을 기대할 수 있다.

Data Tier

실질적으로 데이터를 저장, 관리, 제공하는 역할을 담당하는 부분이다. 이 영역이 어떠한 행위를 할 것인지에 대한 방향성을 Application Tier에 의해 결정되지만 실질적으로 수행하는 부분이기 때문에 이 부분에 대한 튜닝 (Ex) Indexing)을 잘하면 단기적인 성능 향상을 기대할 수 있다. Application Tier에서 보조로직을 튜닝을 했을 때 성능 향상을 기대할 수 있는 이유이기도 하다. Application Tier와 Data Tier의 관계는 Application Tier가 Data Tier에 방향성을 알려주고 이러한 수행은 Data Tier에서 이루어진다. Application Tier의 구조를 리팩토링 했을 때 당장 성능향상을 기대할 수 없지만 점진적인 성능향상을 기대할 수 있는 이유이기도 하다. 일관적이고 구조적인 Application Tier는 올바른 방향성을 Data Tier에 더 잘 알릴 수 있기 때문이다.

이 영역에서 우리 백엔드 개발자가 주의해야 할 점은 우리가 방향성을 알렸을 때 실질적으로 DBMS에서는 어떠한 동작이 이루어지는지 잘 확인해야 한다. 예를 들어 JPA를 사용한다고 해도 실제 어떠한 SQL이 DBMS에 전달되고 이 쿼리를 수행하는 Optimizer가 Full Scan인지 Index Scan 인지 어떠한 Index를 사용하는지 Join은 어떠한 Join을 걸고 복합적으로 확인하여 판단하는 것이 중요하다.

소통

작은 스타트업에서 백엔드 개발자는 Application Tier, Data Tier, Infra와 관련하여 모두의 역할을 수행할 수 있어야 하겠지만, 만약 규모가 있는 회사에는 각 직군의 개발자가 있을 것이다. 각 직군의 개발자는 각각의 Tier에서 집중하고자 하는 역할에 맞게 임무를 수행하고 있을 것이다. 이러한 경우 우리 백엔드 개발자는 비지니스를 가장 잘 알고 중앙에서 소통해야 하는 역할이라는 점을 이해하고 의사결정을 할 수 있어야 한다.

예를 들어 특정 테이블에 여러 Index가 필요할것이다. 그리고 이러한 Index를 DBA 관계자분께서 Index에 대해 관리하고 있을 것이다. 그렇다면 백엔드 개발자는 어떤 비지니스 상황에서 Index가 필요하고 필요 없는지 정확히 알고 필요하다면 요청을 할 수 있어야 하고, 현재 삭제를 하면 안 되는 이유를 말할 수 있어야 한다. 또한 필요 없다면 필요 없는 이유를 정확히 전달하여 DBA 분께서 명확한 근거로 삭제할 수 있도록 도와야 한다.

인프라 관점에서는 만약 특정 시간에만 트래픽이 몰린다고 가정해보자. 현재 띄어져 있는 서버 Instance 수로 그 특정 시간에는 감당하기 힘들다는 지표를 확인하면 이러한 지표를 근거로 특정시간에 추가로 Instance를 띄울 수 있는지에 대한 설명을 Infra 담당자분께 하여 조정할 수 있어야 한다.

마무리

Application Tier에 속한 백엔드 개발자는 무엇보다도 비지니스를 잘 이해해야 한다. 세상은 변하고 비지니스도 변한다. 그러니 꾸준한 비지니스 (도메인)에 대한 이해를 하는 노력이 매우 중요한 것 같다. 또한 요즘은 AI를 이용해 개발을 많이 진행한다. AI의 효용성을 생각해보면 AI는 특정 기능을 작성하는데 있어서는 탁월하다고 생각하다 그러나 AI는 비지니스를 모른다. 비지니스는 개발을 하는 개발자가 더 잘 안다. 모든 맥락과 상황을 AI가 파악할 수 없기 때문이다. 즉, 융합은 사람이 더 잘한다. 이러한 관점을 봤을때도 백엔드 개발자는 비지니스의 논리, 데이터를 매우 잘 이해해야 한다는 사실은 분명한 사실인 거 같다.

1. RESTful API 설계를 잘 지키서 잘 예측할 수 있도록 하자.

우리가 핸드폰을 사용할 때 핸드폰 안에 수많은 부품과 장치가 있는 것은 알지만 우리가 정확히 핸드폰 안의 어떠한 부품이 존재하지 모르는 것처럼 모바일 개발자도 백엔드 내부 구성을 정확히 알 수 없다. 나또한 모바일 개발을 할 때 서버의 구성 전체를 알 수 없었다. 내가 알 수 있는 사실은 API 스팩과 어떠한 응답을 받을 수 있는지가 전부였다. 이러한 사실을 토대로 모바일 개발을 할 때 API 스팩 (METHOD, URL, Parameter)을 보고 내부에서 어떠한 동작이 일어날지 어떠한 값을 받아올 수 있는지에 대해 잘 예측하는것이 중요했다.

서버 개발을 할 때 이러한 사실을 알고 있기에 반대로 클라이언트에게 API를 제공할 때 내부의 동작을 잘 예측할 수 있게 METHOD, URL을 구조적이고 일관되게 정의하고 직관적인 파라미터명을 사용하는 방향으로 개발하고 있다. 또한 응답을 할때 정의와 일맥상통하는 충분한 응답값을 내리는것에 집중하고 있다. 이러한 원칙을 잘 적용하는 방법에는 RESTful API가 있다. 이러한 사실을 인지하고 더더욱 RESTful API를 설계할 때 사용자가 잘 사용할 수 있을지 원칙이 잘 지켜지는지 응답이 적절하지 다시 한번 확인하며 개발하자.

2. Http Status Code, Body를 잘 내려주자

모바일 개발을 할 당시 Http 통신에 성공, 실패해도 Http Status Code를 2xx으로 내려받았던 적이 있다. 이때 성공과 실패를 Body에서 정의한 상태코드로 구분하며 로직을 작성하였는데, 이 당시 이러한 방식이 회사의 컨벤션이어서 이에 맞춰 개발했으나, 백엔드 개발을 하며 다시 이 부분을 회고했을 때 이러한 방식보다는 Http Status를 명확히 구분하고 Body에서 이에 따른 세부 정보를 내려주는 것이 클라이언트에서 더욱 명확하고 효율적인 대응이 가능하다고 판단된다.

모바일에서는 서버와 요청, 응답에 대응하는 코드는 공통으로 구현한다. 공통 부분에는 1차적으로 Http Status Code를 확인하고 이에 따라 Body를 파싱하는 로직이 작성되어 있다. 모바일에서는 이렇게 확인된 정보를 토대로 서버와의 통신이 성공적으로 이루어 졌을 때, 성공적으로 이루어지지 않을 때의 로직이 작성된다. 성공하면 Response에 대한 정보를 연관된 Component에 전달하고, 실패하면 모달을 띄우거나, 토스트를 띄우는 등 UI / UX 로직이 처리되며 추가로 연관된 Component에 실패 정보를 넘겨준다. 이렇게 넘겨받은 값을 토대로 각 연관된 Component에서는 적절한 처리를 한다.

우리 개발자들은 Http Status Code에 대해서 2xx, 3xx, 4xx, 5xx이 어떠한 의미를 가지는지 알고 있으며, Http Status Code로 여러 상황에 대한 풍부한 표현이 가능하다. 즉, 클라이언트는 Body에서 상태코드를 구분하지 않아도 1차적으로 Http Status Code만 보고 어떠한 대응을 할지 알 수 있으며 공통 부분에서는 이러한 사실을 근거로 Http Status Code에 대한 일반적인 대응이 가능하다. 결과적으로 모바일에서 공통으로 구현한 부분에서는 Http Status Code를 통해 1차 적으로 일반적인 대응을 하도록 하고, 추가로 특정 기능에서 우리가 정의한 상태코드를 통한 로직이 작성되어야 한다고 하면(Ex) USER_PASSWORD_NOT_MATCH ..) Component에서는 넘겨받은 실패 정보를 토대로 대응하는 것이 적합하다. 이렇게 하면 더욱 구조적인 프로그램이 가능하고, 불필요한 클라이언트의 역직렬화를 줄일 수 있어 효율적인 프로그램이 가능하다.

3. 어떻게 잘 내려줄까

클라이언트에게 응답값을 내려줄 때 기본적으로 성공에 대한 응답값, 실패에 대한 응답값을 구분하고 일관적, 구조적으로 내려주는 것이 핵심이다. 우리 서버에서 공통으로 응답값을 정의한 것을 토대로 클라이언트도 공통으로 어떠한 응답값을 받을지 정의한다. 이러한 관점을 기반으로 서버에서 클라이언트가 공통구조를 잘 설계할 수 있도록 먼저 방향성을 잘 잡아주자.

변수명은 스네이크 케이스보다는 카멜케이스로 내려주자. Java, Kotlin, Swift에서는 변수를 정의할 때 스네이크 케이스로 정의하지 않는다. 카멜케이스로 정의한다. 만약 스네이크 케이스로 내린다고 하면 엄격하게 이러한 컨벤션을 지켜야 하는 경우 파싱할 때 변수를 카멜케이스로 바꾸는 작업을 해야 한다. 실제로 나도 이러한 작업을 했을 때 여간 번거로운 작업이 아니었다. 그럼으로 서버에서는 이러한 사실을 잘 이해하고 카멜케이스로 내려줄수 있도록 하자.

클라이언트는 서버에서 내려주는 응답 DTO를 정의할 때 JSON Parsing Exception을 피하고자 서버에서 정의한 JSON Filed Name을 그대로 DTO 변수명으로 사용하는 경우는 흔한 일이다. 즉, 서버에서 변수명을 대충 정해주거나, 알맞지 않게 정해줘서 내려주면 클라이언트도 이러한 변수명을 그대로 사용할 여지가 충분하다. 이러한 사실을 이해하고 서버에서 클라이언트에 전달할 변수명을 신경 써서 잘 전달할 수 있도록 하자.

서버에서 배열의 값을 내릴 때는 null로 내리지 않고 빈배열로 내린다. 그러나 회사의 컨벤션에 따라 배열 이외의 변수 타입에 대해서는 null을 내리기도 한다.

요즘 클라이언트 언어는 null safety 한 언어가 많다. (iOS - Swift, Android - Kotlin) null safety 한 언어에는 nullable 변수가 존재하는데, 이 nullable 변수에 접근할 때는 null safety 접근 연산자를 사용해야 한다. (?.) nullable 한 변수와 null safety 연산자를 사용하면 NullpointException을 발생시키지 않아 Application의 안정성을 매우 높여주지만 사용을 하는 입장에서는 일반 연산자보다 null safety 연산자가 추가로 null 처리를 매번 해줘야 하므로 여간 번거로운 일이 아니다.

그런데 만약 배열의 값을 내릴 때 null로 내리지 않고 빈배열로 내리는것처럼 다른 타입도 값을 내릴 때 null로 내리지 않는다고, 사전에 정의하면 null safety 한 언어를 사용하는 클라이언트에서 서버와 통신을 통한 값을 받을 때 타입을 nullable로 정의하지 않아도 된다. 이는 개발의 생산성을 높일 수 있다는 장점이 있다. 그러나 nullable로 선언하지 않는 타입에 null 값이 들어오면 JsonParsingExcepion이 발생한다는 단점이 있다. 이 부분은 이러한 사실을 이해하고 안정성과 편의성 둘을 고려하여 각 회사의 룰에 맞는 전략을 잘 따른는 것이 중요하다고 판단된다.

4. API를 요청하는 효율적인 시점 생각하기

모바일에는 여러 LifeCycle이 존재한다. Application의 LifeCycle도 존재하고, 각 화면에 따른 LifeCycle도 존재한다. 앱을 다시 켰을 때의 시점, 앱을 껐을 때의 시점, 화면의 뷰가 모두 로딩이 완료되었을 때 시점, 화면이 다시 보여졌을 때 시점 등.. 다양한 시점을 LifeCycle이 정의한다. 그리고 이러한 LifeCycle은 사용자의 특정 행위와 더불어 서버의 API를 호출하는 Trigger가 될 수 있다. 이러한 사실을 잘 이해하고 RESTful API를 설계할 때 언제 이 API를 사용하는가에 대한 시점을 생각하는 것은 매우 중요하다.

예를 들어보자. 사용자가 앱을 켜면 모바일에서는 버전 체크 API를 요청한다. 버전 체크가 완료되면 모바일에서는 앱을 사용하기 위해 초기에 반드시 필요한 사용자 정보, Static 한 데이터를 전달받기 위해 서버에 Init API를 요청한다. 모바일에서는 이렇게 요청한 API를 토대로 사용자의 인증정보를 확인하여 어떠한 화면으로 이동할지 결정한다. 이 모든 것은 사용자의 행위로 이루어 지는 것이 아니라 LifeCycle에 의해 이루어진다. 즉 서버 개발자는 각 시점을 잘 이해하고 각 시점에 필요한 적합한 API를 요청하도록 설계하는 것이 중요하다.

5. 여러번 클라이언트에 요청하지 않도록 특정 행위에 대한 응답값 잘 내려주기

모바일은 Stack 기반으로 화면이 관리가 된다. 즉, 화면이 전환되면 각 화면이 FIFO으로 화면이 쌓이게 된다.

어떤 앱에서 디테일 페이지에 들어간다고 하면 이 전에 리스트를 먼저 표현했을 것이고 리스트중 특정 아이템의 ID를 통해 디테일 페이지에 진입했을 것이다. 그런데 만약 디테일 페이지에서 어떠한 행위로 이 아이템의 데이터가 서버에서 변경되었다고 하자. 그러면 이전의 리스트에서도 이 상태를 업데이트해야 할 것이다. 방법은 2가지가 있다. 디테일 페이지에서 아이템의 값을 변경하는 API를 요청하고 요청이 완료되었을 때 이전의 리스트를 받아오는 API를 요청할 수 있고, 처음에 API를 요청했을 때 받아온 응답값을 통해 리스트를 업데이트하는 방법이 있다. 효율성을 고려했을 때 두 번째 방식이 API 요청을 최소화하는 방식이기 트래픽의 관점으로 해석하면 두번째 방식이 효율적이겠다. 이러한 사실을 이해하고 서버에서는 클라이언트가 충분히 업데이트할 수 있도록 데이터를 잘 내려주는 것이 중요하겠다.

(단, 첫 번째 방식으로 구현하는것은 코드를 작성하는 데 있어 상대적으로 더 효율적이다. 또한 다시 한번 서버의 데이터를 받아오는 방식이므로 서버와 클라이언트의 정합성을 확실히 유지할 수 있다는 장점이 있다. 그리고 리스트를 업데이트하여 새로운 정보를 표현할 수 있다는 장점이 있으므로 이러한 방식은 기획과 각 비지니스 상황에 따라 적절하게 고려하는것도 중요하다. 또한 각 화면에서 표현된 데이터들의 너무 상이한 도메인에 대한 데이터들이라고 한다면 여러 API를 호출하는 것도 구조적으로 고려해야 한다.)

6. 모바일 인증 방식

모바일에서는 WebView를 사용하지 않는다면, 쿠키와 세션 기반으로 서버에 인증할 수 없다. 일반적인 Native 앱이라고 한다면 JWT 기반으로 서버에 인증을 하는 것이 일반적이다. 로그인한 사용자는 JWT를 내부 저장소에 저장하고 이 토큰이 존재한다고 하면 로그인을 사전에 실시한 것으로 간주하고 서버에 만료되지 않은 사용자인지 요청을 하여 인증을 진행하고, 만약 만료가되었다면 401 상태코드를 확인하여 로그아웃 (JWT를 내부 저장소에서 없애고, 로그인 화면으로 전환)을 진행한다. 유효하다면 이 유효한 토큰을 기반으로 서버와 여러 통신을 진행한다.

프로젝트에서 필자의 역할은 아키텍처 설계, Common System 개발, Product-service 개발을 담당하고 있다. 오늘은 평소에 필자가 생각한 MSA 아키텍처 구성과 배달의 민족 마이크로 서비스 여행기 영상을 보고 연구 / 분석한 아키텍처 구성에 대해 이야기하는 시간을 가져보도록 하겠다.

Team Lucycato Github

• https://github.com/lucycato-backend/lucycato-e-commerce

배달의 민족 마이크로 서비스 여행기

• https://www.youtube.com/watch?v=BnS6343GTkY&t=1635s

Three Tier Architecture

서비스의 가장 큰 아키텍처는 보통 Three-Tier Architecture로 구성이 되어 있다고 할 수 있다. 그리고 백엔드 개발자는 로직을 처리하는 Application Tier와 데이터의 저장 및 공급을 담당하는 Data Tier와 밀접하게 관련이 되어 있다. Application Tier와 Data Tier에 대해 좀더 세부적으로 확장해보자.

하나의 서버, 하나의 DB

서버와 DB를 하나로 구성한 그림은 아래와 같다. 보통 작은 서비스, 초기 스타트업의 구조는 아래와 같은 구조로 되어 있을 확률이 높다. 그러나 이 구조에는 큰 문제가 있다. 서버 or DB가 죽으면 정상적인 서비스 운용을 할 수 없다. 이 문제를 해결하기 위해 좀더 확장해보자.

MSA 단일 DB 서버 구성

하나의 서버로 운용을 했을때 서버가 죽으면 서비스를 정상적으로 운용을 못해 아래와 같은 구조로 확장했다. 관심사 분리의 기준은 각 도메인을 기준으로 Admin 서버와, App 서버로 분리했다. 이렇게 했을때 장점은 권한에 대해 각각의 서버에서 관리할 수 있다는 장점이 있다. 그러나 Admin과 App 각각의 서버를 각각 개발하다 보면 Read, Write에 대한 로직 중복이 많이 발생하여 오버헤드를 발생시키는 단점이 있다. 이 문제를 해결하기 위해 CQRS를 도입하여 Query (Read), Write (Command)를 기준으로 서버를 분리했다. 이렇게 서버를 구성했을때 장점은 2가지 관점의 Applcation을 운용할 수 있어, scale-out에 좀더 유리해지는 것(성능 효율성 향상)과 Command 서버가 죽어도 조회는 가능하다는 장점이 있다. (완전히 서비스가 마비되지는 않는다.) 처음 구조보다 조금더 회복성을 높인 구조라고 할 수 있다.그러나 DB 서버가 죽으면 전체 서비스가 마비되는 문제는 여전이 남아 있다. 이 문제를 해결하기 위해 조금더 확장해보자.

MSA 복합 DB 서버 구성

하나의 DB로 운용을 했을때 DB 서버가 죽으면 서비스를 정상적으로 운용 하지 못하는 문제로 아래와 같은 구조로 확장했다. 이때 DB 서버는 각 서비스의 특징에 맞게 선택한다. 예를 들어 데이터를 입력하는 Command 서버와 통신하는 DB는 데이터의 무결성과 정합성이 중요하므로 엄격한 스키마에 의해 데이터가 관리되는 RDB를 선택한다. Qeury 서버와 통신하는 DB 서버는 정합성이 떨어지더라도 강한 조회 성능을 발휘할 수 있는 NoSQL(Redis, MongoDB, DynamoDB)를 선택하여 조회 성능을 높인다. 이렇게 했을때 장점은 각각의 특성에 맞게 서버를 구성하여 전략적인 (효율적인) scale-out이 가능하다는 장점을 지닌다. 결정적으로 여러 DB 서버를 운용함으로서 회복성이 많이 좋아진다. Command 서버, RDB 서버 및 Command 서버가 죽어도 서비스는 완전히 죽지 않는다. 그러나 이렇게 서버를 구성하면 데이터의 정합성에 대한 문제가 생긴다. 이러한 문제를 해결하기 위한 방법을 살펴보자. * 중요) 주문과 같은 중요한 사용자와 관련된 Command 서버는 죽는다면, 또는 사용자와 많이 직결된 쿼리 서버가 죽는다면 어떻게 해야 될까? 결론은 주문과 같이 사용자와 관련된 Command 서버와 쿼리 서버는 죽으면 안된다. 배달의 민족 영상에서도 모든 서버가 현실적으로 대용량 트래픽일 수 없다고 한다. 즉, 경중에 따라 서버를 전략적으로 운용하는게 다르다는 뜻이다. 어떤 서버는 자원을 풍부하게 할당하고 철저한 대비를 할 수 있지만 어떤 서버는 상대적으로 그렇지 않다고 할 수 있다. 결론적으로 이러한 구조에서도 Command 서버가 죽거나, 쿼리 서버가 죽으면 치명적이기 때문에 경중이 중한 서버는 상대적으로 철저히 운용할 필요가 있다.

MSA 복합 DB 데이터 정합성

데이터의 정합성을 맞추는 과정은 Kafka와 같은 이벤트 스트리밍 플랫폼으로 해결할 수 있다. 첫번째 사진을 참고해보자. Write 작업을 Command 서버에서 처리를 하고 DB에 데이터를 저장한다. 데이터 저장이 완료 되면 Kafka의 특정 Topic을 기준으로 이벤트를 발행한다. 이 이벤트를 식별할 수 있는 키값만 전달한다. Query 서버에서는 이 키에 대한 정보를 Consume해서 Command 서버에 사전에 정합성을 위해 Fit한 데이터를 주는 API를 키값으로 호출한다 최종적으로 키값을 통해 응답받은 데이터를 자신이 담당하는 DB 서버에 저장한다.

중요하게 언급해야 될 부분중에 하나는 Application 서버의 모델이다. Query 서버는 빠른 검색과 응답이 중요하다 이러한 서버에 어울리는 모델은 Event Loop를 사용하며, Non Blocking I/O 모델을 기반으로 한 WebFlux라고 할 수 있다. MVC에 비해 좀 더 복잡한 프로그래밍 모델이며 개발 검증이 복잡하고 안정성이 떨어질 수 있지만 빠른 응답을 요구하는 Query 서버에 적합다고 할 수 있다. 또한 Command 서버는 기본적으로 MVC를 사용한다. 예를 들어 B2C 서비스라고 가정할때 플렛폼을 사용하는 사용자는 Command 요청 보다 쿼리 요청을 많이 발생시키고, 데이터를 넣어주는 작업 즉, Command는 어드민(Back Office)에서 일어날 확률이 높다. 이러한 상황을 고려했을때 Command 서버는 빠른 응답보다는 안정성이 더 중요하다. 어드민 관리자가 데이터를 넣을때 조금 느리더라도 안전하게 데이터를 넣는것이 서비스 전체적으로 안정적이기 때문이다. 좀더 설명을 하자면 어드민이 서비스 사용자의 100만명, 1000만명의 사람에게 영향을 줄 수 있다는 말이다..!! 이러한 근거로 상대적으로 안정적인 MVC가 더 적합하겠다.

이렇게 구성하면 전략적인 운용이 가능하나, Data Sink 문제가 발생한다 어떻게 해결하면 좋을까 좀더 살펴보자. * 추가설명) B2C 서비스라고 가정할때 Command가 어드민에서 일어날 확률이 높지만 플렛폼 사용자에 의해 Command가 많이 일어날 수 있는 도메인과 상황이 있다. 이럴때는 속도의 강점을 WebFlux를 고려해 볼 수 있다. 더 나아가 안정성과 속도를 챙겨야 되는 상황이라면 아래에 언급한 Fast Command, Stable Command 구성도 고려해 볼 수 있다.

• 참고)

MSA 복합 DB Data Sink 문제 해결

Data Sink 문제가 발생한다고 했을때 대략적으로 1초 ~ 3초 정도의 걸린다고 한다. 그런데 만약 사용자가 요청을 보내고 1초 ~ 3초 사이에 쿼리 서버에 데이터를 요청하면 어떻게 될까? 이럴 경우 아직 데이터가 저장이 안된 상태여서 사용자에게 데이터를 로드 할 수 없을것이다. 그러나 정말 중요해서 보여야 된다면 어떻게 해야 할까 필자가 생각한 방법은 Redis를 사용하는 것이다. Command 서버에 값을 저장하면 해당 데이터에 대한 Key값을 Redis에 저장한다. 이렇게 하고 1초 ~ 3초 사이에 데이터를 쿼리 서버에 요청을 하면 쿼리 서버에서는 기존에 약속한 Protocol에 의해 Redis에 키값이 존재하는지 묻는다. 만약 존재한다면 Command 서버에 쿼리를 요청하여 데이터를 받고 만약 존재하지 않는다면 DB에서 데이터를 가지고 온다. 이렇게 함으로써 중요한 데이터에 대한 Data Sink 문제를 해결할 수 있다.

* 추가설명) Redis는 Application 관점에서 봤을때 전역성을 띈다. 즉 Command와 Query간의 변수를 공유하도록 할 수 있다.

* 추가설명) 모든 데이터에 대해서 이러한 과정을 적용해야 할까 모든 데이터에 이러한 방식을 적용하면 안정적이라고 할 수 있으나 상대적으로 Data Sink가 발생해도 서비스에 큰 문제가 없는 데이터의 경우 개발의 효율성을 떨어트릴수 있기 때문에 상황과 맥락에 따라 적용하면 좋을 방법인거 같다.

* 추가설명) 왜 Command 서버에 요청을 하는가? 이유는 원본 데이터를 가지고 있는 서버이기 때문이다.

* 추가설명) Redis에 해당하는 Key는 데이터를 쿼리 서버 DB에 저장을 하면 없애주는 방식으로 개발을 해도 좋고, TTL을 걸어서 자동 소멸 하게 하는 방식 2가지가 있을것이다.

• 참고)

서버 확장

다시 Three-Tier Architecture를 살펴보자. Three-Tire Architecture에서는 어떻게 서버를 확장 할 수 있는지 방향성을 제시한다. 바로 Application의 확장과 Data Tier의 확장이다. 서버를 Infra Level에서 확장하면 최종적으로 서버 구성의 모습은 아래와 같다고 할 수 있다.

마이크로 서비스 도입

영상에서 마이크로 서비스의 도입은 개발, 시스템의 숙달과 무관하게 서비스 생존을 위해서 도입했다고 나오고 있다. 또한 영상 마지막에서도 마이크로 서비스를 개발하는 것은 기존의 하나의 서비스와 DB를 운용하는 것보다 많은 개발 비용이 든다고 언급한다. 즉, 마이크로 서비스를 도입할때는 각 상황과 맥락을 파악하고 정말 필요에 의한 도입인지를 많이 고민해야 된다는 말이다. 모호한 근거에 도입을 하는것은 옳지 않을것이다.

또한 마이크로 서비스를 구성한다고 했을때 정답은 없다 각 서비스와 시스템의 상황을 고려하여 우리 서비스에 가장 적합한 마이크로 서비스 아키텍처를 구성하는게 가장 중요하다. 그리고 개발자는 이러한 사실을 이해하고 적합한 마이크로 서비스를 개발하기 위한 노력과 생각을 할 수 있어야 한다. 이렇게 할 수 있는 개발자가 진정한 실력있는 개발자라고 생각한다.

주요 주제였던 개발 안정성에 대해

예전에 읽었던 토스의 유난한 도전에서 어떤 개발자가 리팩토링 도입 문제에 대해 이야기한 글을 봤다. '언제 없어질지 모르는 제품인데, 리팩토링은 지옥에서나 하라' 지금 생각해도 직설적인 문장이다. 그러나 개발자로서 생각해볼 가치가 충분한 문장이였다. 필자는 이 문장을 읽고 비지니스와 개발의 안정성에 대해 고민한적이 있었는데, 이번에 더 나은 아키텍처 설계를 위해 참고한 배달의 민족 마이크로 서비스 여행기에서 이 주제에 대해 이야기를 하여 다시 한번 생각을 정리해보고자 한다.

비지니스가 있기에 개발이 존재한다. 또한 개발이 안정적이여야 비지니스가 존재한다. 즉, 비지니스와 개발 안정성은 상호보완적인 관계라고 할 수 있다. 상호보완적인 관계이지만 경중을 따지면 비지니스가 더 중요할 것이다. 비지니스가 없으면 서비스 개발도 없기 때문이다.

'기술만으로는 충분하지 않다. 우리 가슴을 뛰게 하는 것은 인문학과 결합된 기술이다' 같은 말처럼 개발자는 비즈니스와 개발의 교차점을 기억하며 비지니스를 생각하며 개발을 할 수 있어야 한다. 또한 배달의 민족 마이크로 서비스 여행기에서 핵심적으로 이야기하는 점진적 개선의 관점도 탑재해 비지니스의 각 상황과 맥락을 판단해 그에 대응하여 개발할 수 있는 개발자가 되어야 한다.

비지니스의 중요성을 먼저 이해했다면 개발의 안정성과 비지니스의 상호 보완적인 관계를 이해하여 개발의 안정성을 점검하고 검증할 수 있어야 한다. 더 나아가 현재 서비스와 시스템을 지속적으로 이해하여 서비스의 도전적 과제를 점검하고 미래를 대비할 수 있어야 한다. 마지막으로 이 모든것을 하는 행위는 비지니스와 서비스의 성장을 위한 일임을 명심해야 한다.

최종적으로 비지니스와 개발의 안정성을 챙기는 방법에 마법의 요술 램프는 존재하지 않는다는 것을 인정하고 평소 비지니스, 프로젝트 기술의 각 상황과 맥락을 잘 이해하고 이에 대응 할 수 있는 실력과 태도를 갖춰야 한다.

진정으로 실력있는 개발자가 되고 싶어 평소 여러 관점에 대해 많은 생각을 하고있다. 이번 포스트의 핵심 논지인 서비스 성능 및 장애대응과 관련하여 평소 중요하게 생각한 생각을 정리할 수 있어서 기쁘다.

긴 글 읽어주셔서 감사합니다😀

Three-tier Architecture
1. Presentation Tier
   - 사용자에게 보여지는 부분을 담당
   - React, Native App ...
2. Logic Tier
   - 서비스와 관련된 기능과 정책 등등 비지니스 로직을 담당
   - Spring, Django
3. Data Tier
   - 데이터를 저장, 관리, 제공 역할
   - MySQL, Oracle, MongoDB

MSA를 통한 분리/분해로 인해 생긴 문제

Presentation Tier는 사용자에게 보여지는 부분을 담당한다. 즉 사용자와의 상호작용 및 표현을 담당하는 중요한 부분이다. Presentation Tier는 무엇에 집중해야 되냐 묻는다면 사용자와의 상호작용과 표현에 집중해야 한다고 말하는것이 올바를것이다.

개발의 자원과 시간은 유한하다 무한하지 않다. 이말은 Presentation Tier를 담당하는 개발자의 수와 개발을 하는 시간은 유한하다는 뜻이다. Presentation Tier를 담당하는 개발자가 Business Logic 처리에 과중한 집중을 하다 보면 서비스의 성패를 좌우하는 UI/UX 개발에 집중하지 못할 수 있다. Three-tier Architecture 관점에서 비지니스 로직은 Logic Tier(백엔드)에 집중시키고 Presentation Tier(프론트엔드, Native App)에서는 UI/UX 개발에 집중하여 역할과 책임을 분명히 하여 각 레이어에서 최대 장점을 발휘하는 개발과 그 목적성에 부합하는 개발을 하여 서비스 전체의 퀄리티를 올리는것이 적합하다.

그러나 서버 구성을 MSA로 구성하여 각 서버를 비지니스와 도메인에 따라 분리/분해 하면 발생하는 문제가 있다. 각 서버의 도메인은 특정 클라이언트가 아닌 모두를 만족하는 응답을 내린다. 즉, 도메인 속성을 내린다. 각각의 클라이언트 (모바일, 앱, 서버)는 이 응답값을 자체적으로 필요에 의한 로직으로 처리해야 한다. 즉, 서버에서 처리해야 할 비지니스 로직을 UI/UX에 집중해야 할 Presentation Tier의 클라이언트가 처리하는 문제가 발생 할 수 있음을 야기한다.

이 외에도 발생하는 문제가 있다. 비지니스 능력과 도메인을 기준으로 서버를 분리하다 보면 특정 페이지를 완성하기 위한 API를 Aggregate하여 완성하기 힘든 경우가 있다. 이럴때는 클라이언트가 서버에 요청을 물리적으로 여러번 해야 하는 경우가 생긴다. 클라이언트에서 여러번 물리적 통신을 여러번 하는것은 성능 문제를 야기할수 있다. (로컬망에서의 통신보다 네트워크를 통한 통신이 더욱 느리기 때문이다.)

문제 해결 BFF

MSA에서 이 문제를 해결하는 방법 중 하나가 BFF (Backend For Frontend)이다.

BFF는 Presentation Tier를 위한 백엔드라고 할 수 있다. 즉, 각각의 Presentation Tier에 최적화 되어 있어 각각의 페이지와 기능에 맞게 응답값을 내려줄수 있다. 또한 서버의 분리 / 분해로 인해 클라이언트가 물리적으로 여러번 서버를 호출해야 하는 문제도 해결 할 수 있다.

그렇다면 BFF는 만능인가?

BFF Troubleshooting

1. BFF에 너무 많은 책임을 위임하지 말자.

   GET teachers/{teacherId}
   RESPONSE: Teacher
   

GET courses?teacherIds= RESPONSE: List

GET text-books?teacherIds= RESPONSE: List

![](https://velog.velcdn.com/images/will_d/post/7fbab8d3-560b-4839-9859-67af3679af8c/image.png)

GET teachers/{teachdrId} RESPONSE: Teacher

GET teachers/{teacherId}/courses RESPONSE: List

GET teacher/{teacherId}/text-books RESPONSE: List

특정 선생님의 페이지를 완성한다고 가정하자. 선생님 페이지에는 선생님의 정보와, 선생님의 강의 정보, 선생님의 교재 정보가 필요하다.

필자는 처음에 BFF 서버에서 모두 Aggregate 하기 때문에 얽힘 없이 순수하게 필요한 데이터를 요청하여 Aggregate 하는것이 적합하다고 생각했다. 그러나 이렇게 얽힘 없이 순수하게 데이터를 가져와 비지니스 로직을 처리하면 비지니스 로직이 복잡해지고 BFF가 커진다는 사실을 알게되었다. 이는 너무 많은 책임을 부여하여 유지보수를 어렵게한다.

그래서 두번째와 같은 방식을 통해 도메인과 도메인이 특정 관계를 가지면 관계를 맺어주고 이렇게 맺어진 데이터를 기반으로 비지니스 로직을 처리하도록 구성을 바꿨다. 이렇게 하면 BFF에 로직 처리 부담을 줄이고 BFF의 크기를 줄일수 있다. 

각 도메인 서버에서는 각 상황과 맥락을 충분히 고려하여 도메인과 도메인의 관계를 명확히 하여 이와 관련한 응답을 주는 Endpoint을 제공 할 수 있도록 하자. 

[* 참고) REST API 설계](https://velog.io/@will_d/멘토님을-통해-다시-생각한-RESTful-API-그리고-객체지향)

``
참고) BFF는 각 페이지의 복잡한 요구사항을 충족하기 위해 여러 서버를 호출하여 Aggregate 하는 특징을 지닌다.
이러한 특징으로 인해 BFF 서버를 Spring Framework로 구성한다면 Non Blocking I/O를 모델로한 WebFlux를 사용한다.
``

--------------------------------------------------------------------------

2. 작은 서비스에서 BFF는 오히려 유지보수의 비용을 증가 시킨다.

  특정 페이지와 기능을 완성하기 위해 연관성이 낮은 도메인과 도메인이 많이 역여있는 큰 서비스에서 BFF는 적합 할 수 있다. 그러나 작은 서비스, 연관성이 낮은 도메인과 도메인이 적게 역여있는 서비스에서는 BFF는 오히려 관리 포인트를 증가 시킬 수 있다. 이러한 경우에는 BFF의 도입은 적합하지 않을 수 있다. 

  이럴 때는 각각의 도메인에서 클라이언트의 요구사항을 처리하는것이 적합할 수 있다. 서비스의 요구사항과 각 도메인의 관계를 종합적으로 판단하여 BFF 도입을 할 수 있도록 하자.


### Next.js
최근 Chrome 개발자 모드를 통해 API를 확인해보면 .../_next/data/...와 같은 API를 볼 수 있다. 이는 Next.js에서 백엔드를 구성하여 API를 만든것이다. Next.js에서 백엔드 서버는 BFF 서버로 활용될 수 있다. 그리고 각 회사의 상황에 따라 Next.js 서버는 프론트엔드 개발자가 개발할 수 있다.

이러한 상황까지 복합적으로 고려를 하여 프론트엔드 개발자가 UI/UX에 더욱 집중할 수 있도록 위에서 언급한 BFF에 너무 많은 책임을 위임하지 말자.
![](https://velog.velcdn.com/images/will_d/post/dd4ff901-560d-4463-9555-c978da4b8534/image.png)

설계의 중요성

멘토님과 만났을때 나도 멘토님처럼 생각하고 싶어서 어떻게 생각하시는지 관찰했다. 여러 대화를 해보면서 특징을 곰곰이 생각해봤다. 내가 발견한 특징은 아래와 같다.

여러 시간에 걸쳐 많은 코드를 작성하며 좋은 코드와 나쁜 코드를 경험하고, 많은 경험과 지식이 쌓이면 자신의 코드를 보며 반성할 수 있다. 반성을 할 수 있으면 머리속으로 중요한 원칙과 경험을 근거로 머릿속에서 각 경계의 코드를 작성하며 생각의 사냥을 할 수 있다. 생각의 사냥을 하며 끊임없이 머릿속에서 작성한 코드의 정당성과 타당성을 스스로 설명하고 결정한다. 이 과정을 빠르고 정확하게 할 수 있다면 코드의 품질은 높을 수 밖에 없고, 체계적인 코드를 작성할 수 있다.

나는 내가 관찰한 특징을 토대로 앞으로 이렇게 해야겠다고 생각했다. 그리고 추가로 질문했다.

👨🏻‍💻 그렇게 할 수 있다면 무엇에 집중해야 하나요?

멘토님은 설계라고 답변해주셨다. 그리고 위 과정은 설계하는 과정이라고 할 수 있다. 즉, 설계는 코드의 품질을 높이고 지속가능한 시스템의 초석이 되는 체계적인 코드 작성의 시작이라고 할 수 있다.

REST API 기본

백엔드 설계의 시작은 Endpoint(ex) Controller)에서 시작된다고 할 수 있다. 무엇을 개발할지(집중할지) 알아야 무엇을 개발할지 알 수 있기때문이다. 많은 API 설계 기법이 있지만 오늘은 대표적인 API 설계 기법중 하나인 REST API에 대해 설명해보자 한다.

• REST API ```

1. 자원(URI), 행위(Method), 표현(Representation)을 통해 클라이언트와 서버 간의 통신 방식을 규정
2. 자원, 행위, 표현을 통해 클라이언트와 서버가 어떻게 식별하고, 조작하며, 데이터를 주고 받을지를 정의 ```

• REST API 대표적인 Design Guide ```

1. URI는 정보의 자원을 표현
2. 자원에 대한 행위는 HTTP Method 표현 (GET(발급), POST(생성), PATCH((일부)수정), DELETE(삭제))
3. (/)는 계층 관계를 나타내는 데 사용
4. Domain 표현은 복수 사용 (teachers, lectures)
5. 하이픈 사용, 언더바 사용 X, 명사 사용, 소문자 사용
6. 확장자는 URI 포함 x, 헤더에 표현
7. 적절한 HTTP 응답 상태 코드 발급 ```

• REST API 특징 ```

1. 자원(URI)

• 자원은 고유한 URI를 통해 식별

2. 행위(Method)

• 자원에 대한 특정 행위 (GET, POST, DELETE, PUT) 정의

3. 표현(Representation)

• 자원의 상태나 데이터를 표현 (JSON, XML)

4. 상태 무결성 (Statelessness)

• 각 요청은 독립적, 서버는 클라이언트의 상태를 유지하지 않는다.
• 클라이언트는 필요한 모든 정보를 요청에 포함

5. 캐싱 (Caching)

• 응답이 캐시 가능하도록 설정 가능
• HTTP 헤더를 통해 캐시 제어 가능

6. 계층화 시스템 (Layered System)

• 클라이언트는 중간 서버(프록시, 게이트웨이)를 통해 서버와 상호작용 가능

• RESTful API

  REST API의 정의 및 특징과 REST API Design Guide를 잘 따른 API를 RESTful 하다고 표현한다.

  REST API 설계 표준은 없다. 즉, 정답은 없다. 그러나 REST API의 정의 및 특징, 잘 알려진 설계 기법들, 각 팀에서 정한 일관성 있는 설계를 따른다면 RESTful 하다고 할 수 있을것이다.

REST API 설계 with 객체지향

필자는 REST API 정의, 대표적인 REST API Guide와 함께 REST API를 객체지향에 집중해 설명해 보도록 하겠다.

필자는 멘토님의 말씀과 매달 플레이를 하는 유저의 수가 1억명이 넘는 Riot Games Open API를 기반으로 연구 / 분석을 실시했다. https://developer.riotgames.com/apis

URI 의미 해석

1. 깊이: REST API에서 URI는 깊이를 나타낸다. ``` 예시) GET teachers

• 설명: 모든 선생님 GET teachers/{teacherId}
• 설명: 특정 선생님

2. 도메인 관계: REST API에서 URI는 도메인 간의 관계를 나타낸다.

• 1:1

  설명: 특정 도전(challenges/{challengeId})의 설정(config)
  RESPONSE: 단수 (ChallengesConfigInfoDTO)

  추가설명
  Collection: 집합 데이터 ex) challenges
  - REST API 에서 집합 데이터를 나타내는 도메인은 복수로 명시한다.
  Document: 단건 문서 (데이터) ex) config
  - REST API 에서 단건 문서를 나타내는 도메인은 단수로 명시한다.

• N:1

  설명: 모든 도전(challenges)의 설정(config)
  RESTPONSE: 복수 (List<ChallengesConfigInfoDTO>)

  GET teachers/events/{eventId}
  설명: 모든 선생님(teachers)의 특정 이벤트 (events/{eventId})
  RESTPONSE: 복수 (List<TeacherEvent>)
  해석: 같은 이벤트를 가지는 여러 선생님들의 이벤트 리스트를 주세요.

• 1:N

  설명: 특정 도전(challenges/{challengeId)의 모든 백분위수(percentiles)
  RESTPONSE: 복수 (Map<Level, Double>)

  GET /teachers/{teacherId}/courses
  설명: 특정 선생님의 (teachers/{teacherId}) 모든 강의(courses)
  RESPONSE: 복수 (List<TeacherCourse>)

• N:M

  설명: 모든 도전(challenges)의 모든 백분위수(percentiles)
  RESTPONSE: 복수(Map[Long, Map[Integer, Map<Level, Double>]])

  GET /teachers/courses
  설명: 모든 선생님의 (teachers) 모든 강의 (courses)
  RESPONSE: 복수 (List<TeacherCourse>)

3. 책임: URI 역할, 책임을 나타낸다.

   GET users/{userId}/coupons
   설명: 특정 유저에 대한 모든 쿠폰 
   추가설명: 이는 유저와 관련한 요청과 응답에 대한 책임을 가지는 UserController에 속하는것이 적합한다.
   RESTPONSE: List<UserCoupon>
   class: UserController

   GET coupon/{couponId}/users
   설명: 특정 쿠폰에 대한 모든 유저들
   추가설명: 이는 쿠폰에 관련한 요청과 응답에 대한 책임을 가지는 CouponeController에 속하는것이 적합하다.
   RESTPONSE: List<CouponUser>
   class: CouponController

   GET courses?teacherId=?
   설명: 모든 강의 그 중 특정 선생님
   추가설명: 이는 강의에 관련한 요청과 응답에 대한 책임을 가지는 CourseController에 속하는것이 적합하다.
   RESTPONSE: List<Course>
   class: CourseController

   GET teachers/{teacherId}/courses
   설명: 특정 선생님의 강의들
    추가설명: 이는 선생님에 관련한 요청과 응답에 대한 책임을 가지는 TeacherController에 속하는것이 적합하다.
   RESTPONSE: List<TeacherCourse>
   class: TeacherController

   각 상황과 맥락에 따라 도메인들은 충분히 얽히고 섥힐수 있다. 또한 URI의 관계를 어떻게 표현하느냐에 따라 무엇에 집중해야 할지가 달라진다. 즉, 책임과 역할이 달라진다고 할 수 있다. 결론적으로 URI를 통해 역할과 책임을 파악 할 수 있다.

결론

기획 -> 도메인 -> 도메인 간의 관계 -> URI 표현 -> REST API를 객체지향 적으로 설계

특정 서비스를 개발하기 위한 기획서가 있다. 개발자는 기획서를 읽고 도메인을 추산할 수 있다.
이렇게 추산된 도메인은 각각 관계를 가진다. 각 상황과 맥락에 따라 도메인의 관계는 다르게 표현이 된다.
즉, 책임과 역할이 달라진다. 이를 통해 우리는 객체지향적으로 REST API를 설계할 수 있다.

아래는 REST API를 객체지향적으로 설계한 예시다.

REST API 객체지향 설계 예시

• POST: reviews

  설명: 리뷰 등록
  Response: Review
  Class: ReviewController

• GET: reviews

  설명: 리뷰 리스트 조회
  Response: Review
  Class: ReviewController

• POST teachers/{teacherId}/reviews

  설명: 특정 선생님의 리뷰 등록
  Response: TeacherReview
  Class: TeacherController

• GET teachers/{teacherId}/reviews

  설명: 특정 선생님의 리뷰 정보 리스트
  Response: List<TeacherReview>
  Class: TeacherController

• POST courses/{courseId}/reviews

  설명: 특정 강자의 리뷰 등록
  Response: CourseReview
  Class: CourseController

• GET courses/reiews

  설명: 모든 강의의 리뷰 리스트
  Response: List<CourseReview>
  Class: CourseController

• GET courses/{courseId}/reviews

  설명: 특정 강의의 리뷰 리스트
  Response: List<CourseReview>
  Class: CourseController

• GET courses/by-teacher/{teacherId}/reviews

  설명: 선생님의 아이디를 기반으로 한 특정 강의의 리뷰 리스트
  Response: List<CourseReview>
  Class: CourseController

Path Parameter vs Query Parameter (Optional)

- Path Parameter: Require 
설명: 반드시 필요한 값들에 대해서는 Path Parameter를 통해 값을 받는다.
1. PK O
    ex) courses/{courseId}
    설명: PK는 by keyword를 path로 명시하지 않는다.
2. PK X
    ex) courses/by-teacher/{teacherId}
    설명: PK가 아닌 값은 by keyword를 path에 명시하여 작성한다.

- Query Parameter: Optional
설명: 선택적으로 필요한 값들에 대해서는 Query Parameter를 통해 값을 받는다.
    ex) teachers?page=&perPage=&isEncrypt=

이유: 1번 사진과, 2번 사진과 같이 검색을 하기 위해 여러 개의 값을 모두 받아야 검색이 가능한 경우가 있다.
     이럴때 Query Parameter 보다 Path Parameter를 통해 클라이언트에게 의도를 분명히 할 수 있다.
     또한 3번의 사진과 같이 여러개의 값을 받지 않더라도 필수 값에 대해 명확한 의도를 제시해야 하는 경우
     Path Parameter를 사용한다. 그 외의 선택적 조건을 통한 검색은 Query Parameter를 통해 값을 받는다.

     위의 정의를 다시 한번 살펴보고 아래의 예시를 다시한번 살펴보며 차이점을 이해해보자.
     ex 1) active-shards/by-game/{game}/by-puuid/{puuid}
     ex 2) active-shards?game=&puuid=
     ex 3) teams/{teamId}
     ex 4) teams?teamId=

추가적으로 필자가 Design한 REST API

대표적으로 제시된 REST API Design Guide와 함께 개발을 하면서 필요하다고 생각을 한 부분에 대해 추가적으로 설계한 부분에 대해 정리하면 아래의 예시와 설명과 같다.

[1. open-api or api] / [2. app or admin or 생략] / [3. service_name] / [4. API version] / [5. 자원의 깊이, 관계, 책임] /

• 예시

  POST api/admin/product/v1/teachers
  POST api/app/product/v1/course/{courseId}/reviews
  GET open-api/product/v1/teachers/{teacherId}/reviews

• 설명

  1. open-api or api: 공개 API인지 보호된 API인지 구분
  2. app or admin or 생략: 보호된 API일때 클라이언트 권한 구분
  3. service_name: 서비스 이름 명시 (user, product, notification)
  4. API version: API 버전 명시 (v1, v2)
  5. 자원의 깊이, 관계, 책임 명시 (/teachers, /course/{courseId}/reviews)

  • 단, POST, GET, DELETE, PATCH를 통해 행위를 설명하기 불가능하거나 애매한 경우 행위를 명시한다.

        ex)
        POST lecture/{lectureId}/move
        설명: 강좌의 순서를 바꾸고 싶을때 사용
        Response: Lecture
        Class: LectureController
    
        이유: 행위를 명시하는 것은 특정 REST API 가이드에서는 위배되는 조건이다. 그러나 필자가 생각했을때
        REST API의 제일 중요한 원칙은 클라이언트와 서버 간의 통신이다. 즉, 직관적으로 API의 URI 및 메소드를
        보고 어떠한 행위가 일어나고, 어떠한 자원을 식별할 수 있다는것이 중요하다. 그래서 설명이 불가능하거나
        애매한 경우 행위를 명시하는 것으로 Design 했다.

이번 시간에는 MSA 환경에서 어떻게 통신을 하면 좋을지에 대해 이야기 하는 시간을 가져보도록 하겠다.

외부와의 통신에 대해 크게 로직 처리 순서가 중요한 통신, 로직 처리 순서가 중요하지 않고 처리 효율성이 중요한 통신 2가지로 나눌수 있다. 각 통신의 효용성은 각 비즈니스의 상황에 따라 결정된다.

• ** 로직 처리 순서가 중요한 통신 **
  • ex) MVC HttpClient, RestTemplate, WebFlux WebClient

• ** 로직 처리 순서가 중요하지 않고 처리 효율성이 중요한 통신 **
  • ex) Message Queueing: Kafka, Rabbit MQ

로직 처리 순서가 중요한 통신

HttpClient (MVC)

• MVC 기반으로 개발 할때 우리가 개발하는 특정 도메인에서 순서가 중요한 비지니스 로직이 있을 수 있다. 이럴때는 순서를 보장해주는 HttpClient를 기반으로 통신을 하여 처리하는게 적합하다.
• CommonHttpClient MSA 환경에서 우리 서비스 및 서버와 통신하기 위한 보조로직을 HttpClient 기반으로 Mapping한 Class다. MVC 기반으로 특정 서비스를 개발하고 있다면, 우리 서비스 및 서버와 통신할 때는 CommonHttpClient를 사용한다.

  ** 주요 기능 **

  1. JWT Context 유지 (with Local Thread)
     2. Exception Handling
  2. 값 변환

WebClient (WebFlux)

• WebFlux 기반으로 개발을 할때 Async, NonBlocking 기반으로 외부와 통신해야 한다. WebFlux에서 병목 현상은 시스템에 치명적인 성능저하를 유발하기 때문이다. (참고: MSA 심장부를 설계하다: Theme3. MVC, WebFlux 경계) 그래서 WebFlux에서는 Async, NonBlocking Client인 WebClient를 지원하고, 이를 사용한다. WebClient가 Async, NonBlocking Client이긴 하나 이를 사용하는 효용성은 HttpClient를 사용하듯이 특정 비지니스의 순서가 중요한 로직에서 사용하는게 적합하다.
• CommonWebClient MSA 환경에서 우리 서비스 및 서버와 통신하기 위한 보조로직을 WebClient 기반으로 Mapping한 Class다. WebFlux 기반으로 특정 서비스를 개발하고 있다면, 우리 서비스 및 서버와 통신할 때는 CommonWebClient를 사용한다.

  ** 주요 기능 **

  1. JWT Context 유지 (with Reactor Context)
  2. Exception Handling
  3. 값 변환

로직 처리 순서가 중요하지 않고 처리 효율성이 중요한 통신

Message Queueing (with Kafka)

Message Queueing에 대한 설명은 Kafka를 기반으로 설명하도록 하겠다. 이커머스에서 특정 상품을 주문했을 때 재고에 대한 업데이트가 필요하며, 주문이 정상적으로 성공했을때 사용자에게 알림을 보내야 한다고 가정해보자. 이때 서버에서 로직처리를 할 때 재고가 모두 업데이트 되는 상황에 대해 응답을 받고 알림이 보내졌다는 응답을 모두 확인 한 후 사용자에게 최종 결과를 응답하는 것은 효율적일까? 이러한 방식으로 응답을 내리는것이 틀린 것은 아니지만 더 효율적인 방법이 있을거 같다. 정상적으로 사용자의 주문 요청이 완료 되면 바로 응답을 내리고 재고 처리와, 알림은 비동기적으로 처리하는것이다. 이러한 상황에서 우리는 비동기 통신을 활용할 수 있다. 이러한 절차를 기반으로 처리했을때 이점은 아래와 같다.

1. 요청 - 응답 속도 향상 (사용자 경험 향상)
2. 부하 / 분산을 통한 효율적 자원 활용

결론적으로 우리의 서비스가 효율적인 자원활용과 빠른 처리가 필요할때 생각할 수 있는 방법이다.

** * 참고) ** 부하 / 분산을 통한 효율적 자원 활용 및 성능 개선 이외에도 Kafka를 기반으로 통신하면 브로커 서버를 중심으로 각 서비스가 통신하여 서비스간의 결합도를 낮춰 더욱 확장성있는 프로그래밍을 가능하게 하는 장점도 있다. 이를 기반으로 한 아키텍처 EDA (Event Driven Architecture)가 있고 기회가 된다면 EDA에 대해 소개하는 포스팅을 남기도록 하겠다.

Kafka 운용

1. 각 도메인을 기준으로 Topic을 나눈다.
2. 각 도메인의 특성과 처리량을 고려하여 Patition의 갯수를 정한다. (* Partition은 Kafka 운용에서 병렬처리에 대한 지표로서 중요한 역할을 한다.)
3. Producer를 통해 Kafka Broker 서버에 값을 발행할때는 Topic을 기준으로 아래와 같은 Json Data를 발행한다.
4. Partition의 갯수를 기반으로 Consumer Group에 Consumer를 배치하고, Topic을 기준으로 구독하여 Producer에서 보낸 값을 소비한다. (* Consumer Group에 배치된 Consumer들은 각각 특정 Partition을 할당받아 병렬 처리를 진행한다.)

** 부가 설명) *

• Topic을 생성하는 기준은 각 도메인을 기반으로 생성한다. notification-service가 비동기 통신이 필요하면 이에 관한 Topic을 생성하고, product-sevice가 비동기 통신이 필요하면 이에 대한 Topic을 생성한다.
• Consumer Group내의 Consumer들은 하나의 Topic을 공유할 수 있다. 이 말은 각 Consumer는 각각의 Partition을 할당 받아 각 Partition의 레코드를 처리한다. 이때 Consumer Group내의 Consumer들은 병렬처리를 진행한다. 즉, Partition은 병렬처리를 위한 중요한 성능 지표고 각 도메인의 특성을 고려하여 갯수를 잘 정하는것이 중요하다.
• Producer는 우리가 정한 Protocol을 기반으로 값을 발행한다. Consumer 또한 이 Protocol을 이해하고 있다. 즉, Consumer는 Producer가 값을 발행하면 우리가 정한 Protocol을 기반으로 데이터를 해석하여 특정 비지니스 로직을 실행하는 Trigger 역할을 한다.

코드를 통해 자세히 이해해보자

통신을 안정적으로 운용하는 방법

동기적으로 통신을 하던, 비동기적으로 통신을 하던 통신에 대원칙이 있다. 한번 떠나간 요청은 다시 회수할 수 없다. 이미 떠나간 요청을 막는 방법은 없다. 이러한 특성을 고려하여 실패 상황에 대한 대응은 통신을 안정적으로 운용하는데 있어 매우 중요한다.

• 순서가 보장된 통신에서는 실패에 대한 응답을 확일 할 수 있다. 실패에 대한 응답을 기준으로 보상트랜잭션 (Rallback API)와 같은 처리를 통해 정합성을 맞출수 있다.
• 순서가 보장되지 않는 통신에서는 실패에 대한 응답을 확일 할 수 없다. 만약 Kafka를 통해 이벤트를 발행하여 특정 서버에서 이 처리를 하다 실패를 했을때 추후 대응을 위해 실패에 대한 요청을 관리해야 한다. 이 관리를 통해 데이터의 정합성을 맞출 수 있다.

필자는 가끔 산책을 하며 견고하고 안전하게 잘 지어진 건축물을 바라보며 감탄 하는 경우가 종종 있다. 어떻게 저렇게 시간이 지나도 안전하게 사람들에게 가치를 제공할 수 있는지, 어떠한 설계 원칙과 생각을 가지고 건물을 짖는지 등 여러 생각과 함께 소프트웨어 개발에 대해 생각할 때가 있다.

'지속가능한 소프트웨어 구축'은 개발자에게 가장 중요한 덕목이라고 해도 과언이 아니다. 사계절이 변하며 비가 오고 눈이 와도 사람들에게 안전한 공간과 가치를 건축물이 제공하듯 시스템 또한 세상이 변하고 비즈니스가 변해도 견고하고 안전하게 가치를 제공할 수 있어야 한다. 오늘은 지속가능한 시스템 구축에 있어 빼놓을 수 없는 예외처리에 대해 이야기 하는 시간을 갖도록 하겠다.

MSA 환경에서 예외를 처리하는 원리

다수의 서버가 분리 / 분해된 MSA 환경에서 예외 처리 또한 이전 포스팅 (MSA 심장부를 설계하다: Theme4. MSA JWT 전달 전략 like Fractal)에서 언급한 무한 프랙탈 구조와 닮아 있다. 특정 요청에 대한 예외를 발생시킨 서버에서 에러 메세지를 전달하고 전달받은 서버에서 이 에러메세지를 전달 받아 또 전달하는 구조이다.

** 🚨Tip)** 필자는 계속해서 무한 프랙탈 구조에 대해 언급하고 있다. 개인적으로 필자가 MSA 설계를 하며 느끼는 감정은 무한히 반복되는 느낌이다. 즉, 무한 프랙탈 구조는 MSA에 대한 감각을 이해하는데 중요한 예시라고 할 수 있다. 이 글을 읽는 독자분들도 이 감각을 잘 알면 좋을거 같다.

더 자세히 원리에 대해 알아보자

클라이언트는 응답 서버에 요청을 보낸다. 응답 서버의 특정 로직에서 만약 Exception이 발생한다면 Common에 구축된 Exception Handler의 원리에 의해 클라이언트에 Exception 정보를 내려준다. 응답을 받는 서버는 Exception을 Catch하며 위와 같은 응답 구조를 알 수 있다. 응답을 받는 서버는 2가지 선택지가 있다. 응답을 주는 서버가 내린 Exception을 그대로 내릴지 특정 로직을 처리후 자신이 원하는 응답을 내릴지 선택해야 한다. 이러한 원리를 계속해서 반복함으로서 여러 서버가 분리 / 분산된 MSA 환경에서 Exception을 Handling 할 수 있다.

코드를 통해 더 자세히 이해해보자

MVC 원리

CommonHttpClient는 응답 값을 리턴 하기 전에 응답 서버에서 내린 status code를 통해 요청에 대해 성공인지 실패인지 판단한다. 실패라면 (응답을 내리는 서버에서 Exception이 발생) ApiExceptionImpl에 statusCode와 Result를 전달하여 ApiExceptionImpl Exception을 던진다. 이때 요청 서버에서는 그대로 Exception을 내릴지 아니면 특정 처리를 해서 내릴지 선택한다. 만약 그대로 내린다면 응답을 내리는 서버에서 Exception Handler를 통해 Exception을 내리듯이 똑같은 원리에 의해 Exception을 내릴수 있다.

WebFlux 원리

WebClient는 응답을 내리는 서버에서 Exception이 발생하면 WebClientResponseException이 발생한다. 이 Exception을 Catch 하여 MVC와 똑같은 과정으로 Exception을 처리한다.

이러한 과정이 각 서버와 서버 사이에서 계속 반복해서 이루어질 것이고 이를 통해 분리 / 분산된 MSA 환경에서 Exception Handling을 처리 할 수 있다.

마무리

재능인가 노력인가, 개발자로 살아가다 보면 주변에서 개발 재능이 너무 띄어나 절대 따라잡지 못한다는 말을 종종 듣는거 같다. 어떤 이들은 노력해도 따라 잡지 못한다고 한다. 정말 그럴까? 필자는 재능보다 더 중요한게 있다고 생각한다. 바로 '태도'다. '지속가능한 소프트웨어를 구축하겠다.', '더 탁월하고 훌륭한 소프트웨어를 구축하겠다. 과연 내가 작성한 코드는 탁월한가, 옳은가, 적합한가?!'라는 태도를 가진 진중한 개발자라면 재능이 있는 개발자 보다 그 끝에는 더 잘할것이라고 믿는다. 즉, '재능만으로 일류가 된 사례는 없다. 태도만이 유일한 일류가 되는 길이다.'라는 말처럼 휼륭한 태도가 훌륭한 개발자를 만들고 탁월한 소프트웨어 및 비지니스를 만들것이다. 이 말은 지속가능한 소프트웨어의 구축에서 빼놓을 수 없는 Exception Handling에 대해 구축 할때 꼭 말하고 싶었다... 그러니 다들 할 수 있다!!!

긴글 읽어주셔서 감사합니다☺️

위키 백과에서는 프랙탈 구조를 위와 같이 정의한다. 프랙탈 구조는 쉽게말해 무한히 반복되는 구조다. MSA 환경에서도 이러한 구조를 직면할 수 있는데 각 서버에 JWT 정보를 전달하는 전략을 구축할때 이러한 구조를 마주할 수 있다.

이번 MSA 심장부를 설계하다 4번째 시리즈에서는 분리 / 분산된 서버 환경에서 어떻게 JWT Context를 전달하는지에 대한 설명을 준비했다. 그리고 더 나아가 Passport 전략에 대해서도 간단히 언급하는 시간을 가지도록 하겠다.

API Gateway

MSA 개발 환경에서는 분리 / 분산된 서버를 조직적으로 관리하기 위해 하나의 진입점을 둔다. 이러한 단일 진입점을 API Gateway 서버라 부른다. API Gateway 서버는 각 서비스에 접근하기 위한 모든 요청을 수용하고 트래픽을 분리 / 분산 시킨다. 각 서비스에 분리 / 분산 하기전 API Gateway 서버는 Auth 서버와의 통신을 통해 인증 / 인가를 거친 후 JWT 정보와 함께 트래픽을 각 서버에 할당한다.

요청 Endpoint(Controller) 도달 흐름

API Gateway 서버로 부터 요청을 할당 받은 하나의 서버의 Endpoint 도달 과정을 살펴보면 위 그림의 오른쪽 사진과 같다. API Gateway 서버는 파싱한 JWT 정보를 Object 형태로 만든후 JSON 형태로 직렬화하여 Header에 주입해 정보를 전달한다. 이때 각 서버의 Filter에서는 Local Thread (MVC) or Reactor Context (WebFlux)에 이 값을 저장하여 유지하고, Resolver에서는 이 값을 다시 역직렬화 하여 Controller에 값을 주입 할 수 있는 상태를 구현한다. 더 자세한 내용은 아래를 살펴보자.

🚨 주의) WebFlux를 기반으로 Web Application Server를 구성한다면 특정 Context 정보를 Local Thread에 저장하면 안된다. 이유는 WebFlux는 하나의 요청에 대한 작업에 여러 Thread가 관여하여 Thread의 전환이 빈번하게 일어나기 때문이다. 자세한 내용은 이전에 작성한 MSA 심장부를 설계하다: Theme3. MVC, WebFlux 경계글을 참고 부탁드린다.

Local Thread, Reactor Contex JWT 주입 및 전달 원리

위의 그림을 보면 Filter에 저장된 값이 다시 뽑아져 다른 서버와 통신하면서 JWT Context를 전달하는 흐름을 알 수 있다. 실제 구현 코드는 아래의 코드를 참고 부탁드린다.

*👨🏻‍💻 질문) 왜 이렇게 JWT 정보를 Local Thread, Reactor Context에 저장하고 뽑아내는 전략을 구축한것인가요? * 우리가 API Gateway에서 본 그림을 보면 자원서버는 Private Network 환경에 있다는것을 알 수 있다. 즉 API Gateway를 통과하여 특정 자원서버로 도달했다는 말은 인증 / 인가에 대해 원활하게 수행했다고 해석할 수 있다. 그렇다면 내부의 자원 서버간의 통신을 할때 또 인증 / 인가를 거치는 것은 적합한가? 필자는 실제로 이 고민에 대해 깊게 했다. 필자의 결론은 이미 Gateway를 통과했다면 내부에서는 더이상 인증 / 인가를 거치지 않고 JWT 정보를 연속적으로 전달하는것이 더욱 효율적이고 Private Network 환경이니 안정하다 판단했다.(물론 이 방법도 정답은 아닐것이다. 오히려 보안 레벨을 높여야 되는 상황이면 내부에서 통신 할때도 인증 / 인가를 거치는것이 적합할 수 있다.) 즉, Filter에서 Header의 JWT JSON 값을 뽑아내 JWT JSON 정보를 Local Thread, Reactor Context에 저장하고 우리 서버와 통신할때는 같은 방식으로 Header에 값을 저장하여 전달한다. 위에서 서두에 프랙탈 구조에 대해 이야기 했는데 이렇게 하면 계속 해서 반복적인 구조로 Context가 유지되어 프랙탈 구조를 만들 수 있다. 필자도 처음에 이 구조를 다 구현해서 완성했을때 뭔가 프랙탈 구조를 구현한거 같아서 너무 기분이 좋았다 ㅎㅎㅎ...

* MVC (Local Thread 사용) 요청을 담당하는 CommonHttpClient에 Local Thread의 값을 뽑아내는 코드를 구현하여 JWT Context를 외부의 서버에 전달했다.

* WebFlux (Reactor Context 사용) 요청을 담당하는 CommonWebClient에서 Reactor Context의 값을 뽑아내는 코드를 구현했다. 이가 가능한 이유는 Filter CommonWebClient를 사용하는 시점에는 Filter에서 Context값을 저장하는 시점과 비교했을때 Up Stream이기 가능한 코드이다. 이러한 원리를 통해서 WebFlux에서도 JWT Context를 유지했다.

Endpoint(Controller) JWT 주입 및 전달 원리 With Resolver

Argument Resolver에서도 Header에서 JWT JSON 값을 뽑아 역직렬화 하여 Controller에 주입하는 코드를 구현한다. 👨🏻‍💻 질문) 이미 위에서 JWT Context 정보를 저장하였는데 왜 Resolver 까지 사용하는 건가요? 서버와 서버간의 JWT Context 유지는 Filter, Local Thread, Reactor Context를 통해서 실현하고, 비지니스 로직에 필요한 JWT 값을 전달하는 역할은 Resolver에서 주입한 값을 통해 실현하는것이 경계를 분명히 하여 클린 코드를 유지하는 방식이기에 이러한 구조를 채택하였다. 예를 들자면, Resolver를 구현하지 않아도 비지니스 로직을 구현할때 JWT 정보가 필요하다면 Context에서 값을 뽑아내 직렬화 하여 충분히 사용할 수 있다. 그러나 JWT의 어떤 특정 값만 사용하는 것인데 모든 정보를 뽑아내는것이 과연 타당한가? Controller에서 비니지스 레이어에서 필요한 특정 값을 넘겨주어 비지니스 레이어의 경계를 분명히 하는것이 더 타당하지 않을까? 그래서 Resolver를 구현했다. 추가적으로 Filter를 구현하지 않아도 충분히 서버와 서버간의 JWT Context 유지를 Resolver를 통해 가능하다 그러나 이 또한 비지니스 레이어에 불필요한 데이터를 넘겨주는 것과 같다. 위와 같은 이유로 경계를 분명히 하기 위해 Filter, Local Thread, Reactor Context 전략을 구축했다. 이렇게 함으로서 비지니스 레이어를 지키고 클린 코드를 작성할 수 있다. (이 부분은 필자도 정말 많이 고민하고 고민한 부분이다. 혹시 이해가 잘 안되는 분이 계신다면 과감하게 댓글 남겨주시면 감사하겠습니다😀) 실제 Resolver 주입 코드는 아래와 같다.

*** MVC Resolver **

*** WebFlux Resolver **

*** Endpoint **

흐름 정리

흐름을 다시 한번 정리해보면, API Gateway에서 전달된 JWT 정보는 Auth를 거처 validate 되어 Object로 만들어 지며, 이 Object는 또 직렬화 되어 Header에 값이 저장될것이다. 이러한 과정을 거쳐 API Gateway 서버에서 특정 서버에 요청을 Route 할것이고 이 요청을 받은 서버는 위에서 설명한 원리로 계속해서 JWT Context를 유지해 나간다.

Passport 전략

이 원리를 더욱 확장한다면 Passport 전략까지 구축을 할 수 있다. 즉 JWT 토큰 정보를 기반으로 사용자 정보를 User 서버에 요청하여 JWT 정보가 아닌 User 정보의 Context를 유지하는것이다. 그렇다면 왜 User Context를 유지하는 것인가 B2C 서비스는 사용자를 중심으로 비지니스가 수행된다. 즉 이말을 우리가 비지니스 로직을 작성할때 사용자 정보를 기반으로한 비지니스 로직을 매우 많이 작성한다는 말이다. 그리고 다시 이 말을 해석하면 그많큼 많은 서비스가 User 서비스에 수많은 요청을 한다는 것이다. 그렇다면 하나의 요청에 대해 매번 각 서비스에서 User 서버에 User의 정보를 요청하는 것이 아닌 한번만 요청하여 이 정보를 계속 유지할 수 있다면 더욱 효율적이고 User 서버의 트래픽을 낮출수 있지 않을까? 그래서 나온 방식이 Passport 방식이라고 할 수 있겠다. Passport 방식을 통한 서버 전체 최적화 글은 다른 포스트에서 작성하도록 하겠다.

마무리

MSA 구조는 개발하다 보면 가끔 아름답다는 생각이 든다. 이번 MSA 심장부를 설계하다: Theme4. MSA JWT 전달 전략 like Fractal 글에서는 그 아름다움을 다시금 느끼는 계기가 되었다. 긴글 읽어주셔서 감사합니다😀

1. spring-web-mvc: Sync, Blocking 기반
2. spring-webflux: Async, NonBlocking 기반

두 방식은 서로 다른 모델을 기반으로 Web Application Server를 개발 할 수 있도록 한다. 서로 다른 두 모델의 차이점을 이해하고 MSA 프로젝트에서 어떻게 경계를 나눠 사용하는지 알아보자.

Spring Web MVC 동작 방식

• 기본 설명 Spring Web MVC는 기본적으로 서블릿 컨테이너인 Tomcat을 기반으로 Sync, Blocking 방식으로 작업을 수행한다. Spring Web MVC에서는 효율적인 Thread 관리를 위해 Thread Pool을 운용하며, 하나의 요청에 대해 Thread Pool에서 관리중인 하나의 Thread를 할당하고 Thread Pool의 최소 Thread 갯수를 넘어 그 이상의 요청이 들어온다면 Thread를 생성하여 각각의 요청에 대해 Thread를 할당한다. (단, Tomcat은 Thread Pool에서 기본적으로 관리할 최소 Thread의 갯수를 정하고 동시에 다량의 요청이 들어왔을때 추가로 생성하여 대응할 최대 Thread의 갯수를 설정을 통해 관리한다. 즉, 이 최대 Thread의 갯수가 초과 되면 더이상 Thread를 생성하지 않고 나머지 요청을 대기상태로 진입시킨다. 또한 최대 Thread의 갯수를 초과할 만큼의 다수의 요청이 끝나고 일정 시간이 지나면 Thread를 회수하여 Thread Pool에 최소 Thread의 갯수를 유지하여 자원을 효율적으로 관리한다.) Spring Web MVC에서 단일 요청을 담당하는 Thread는 특정 요청의 작업이 모두 완료될때 까지 기본적으로 순차적으로 작업을 진행하고 작업을 진행하는 동안 이외의 작업을 수행할 수 없다. 즉, 요청을 처리하는 Thread는 Blocking 상태가 된다.

• 요약
  • Spring Web MVC는 효율적인 Thread 관리를 위한 Thread Pool 운용
  • Spring Web MVC는 설정을 통해 Thread Pool에 기본적으로 관리할 최소 Thread 갯수 지정
  • Spring Web MVC는 설정을 통해 Thread Pool에서 관리할 최대 Thread 갯수 지정
  • 최소 Thread의 갯수를 넘는 요청이 발생하면 추가로 Thread를 생성하여 대응하고 최대 Thread를 초과하는 다량의 요청이 들어오면 더이상 Thread를 생성하지 않고 나머지 요청은 대기 상태로 진입
  • 최대 Thread 갯수를 초과하는 다량의 요청이 모두 종료 되고 일정시간이 지나면 Tomcat은 효율적인 자원관리를 위해 최소 Thread 갯수만 Thread Pool에 유지
  • 하나의 요청에 대해 하나의 Thread를 할당하며 특정 요청에 할당된 Thread는 기본적으로 작업을 순차적으로 진행하며 작업이 모두 완료 될때 까지 Blocking 상태를 유지

Spring WebFlux 동작 방식

• 기본 설명 Spring Webflux는 기본적으로 Netty와 Reactor(Reactive Streams 구현체)를 기반으로 Async, NonBlocking 방식으로 작업을 수행한다. WebFlux는 요청이 들어 오면 Boss Event Loop Group(소수의 Thread로 구성이 되어 있다. 이해를 위해 하나라고 생각해도 좋을거 같다.)에서 이 요청을 수락하고 Chanel을 통해 Worker Event Loop Group(기본적으로 컴퓨터 코어수를 기반으로 Thread가 생성이 된다.)의 특정 Woker Thread에 이 요청을 할당한다. 특정 요청을 할당 받는 Worker Thread는 NonBlocking I/O 모델을 기반으로 Reactive Stream인 Mono, Flux의 구독을 진행하고 구독이 된 Reactive Stream(Mono, Flux)은 다양한 Scheduler를 통해 Async, NonBlocking 모델을 기반으로 실질적인 작업을 처리한다. WebFlux는 MVC와 다르게 각각의 요청에 대해서 Thread를 할당하지 않고 Event Loop를 기반으로 소수의 Thread로 다수의 요청들에 대해 비동기적으로 작업을 처리한다. 그 결과 WebFlux는 적은 자원(소소의 Thread)을 활용하여 고성능, 고효율의 성능을 발휘할수 있다.

• 요약
  • WebFlux는 효율적인 자원 활용을 위해 Event Loop 기반으로 동작
  • 요청을 수락하는 Boss Event Loop Group은 소수의 Thread로 구성
  • NonBlocking I/O 모델을 기반으로 Worker Thread는 Reactive Stream(Mono, Flux)를 구독
  • Worker Thread는 기본적으로 CPU 코어수를 기반으로 생성
  • 다수의 요청에 대해 각 Thread가 할당되는 방식이 아닌 Event Loop를 기반으로 저자원 고성능, 고효율 발휘

Spring Web MVC vs Spring WebFlux

Spring Web MVC

• ** 명령형 프로그래밍**
  • 행위를 중심으로 프로그램 개발을 진행하는 방식이다.
  • 기본적으로 동기적으로 프로그래밍 개발한다.
• 메모리 효율성
  • 하나의 Thread에는 독자적인 메모리 영역이 할당되는데 Thread Pool을 운용하는 Tomcat은 기본적으로 다수의 Thread를 생성해 놓으며, 필요에 의해 다수의 Thread를 추가로 생성한다. 즉, 생성된 Thread의 갯수 만큼 독자적인 메모리 영역이 할당될것이고 이는 메모리 효율성을 저하 시킬 여지가 있다.
• CPU Bounds: 시스템의 성능이 CPU의 처리 능력에 의해 제한되는 경우
  • Spring Web MVC는 하나의 요청에 대해 하나의 Thread를 할당한다. 즉, 시스템의 CPU 코어수를 초과하는 다수의 Thread가 생설될 수 있음을 암시한다. 이러한 상황은 CPU에 큰 부하를 주는 다량의 Context Switching을 발생 시켜 CPU Bounds를 발생 시킬 여지가 있다.
• I/O Bounds: 시스템의 성능이 I/O 작업에 의해 제한되는 경우
  • Spring Web MVC는 Blocking I/O 모델을 기반으로 작업을 수행한다. 즉, 하나의 요청에 대해 할당된 Thread는 현재 수행 중인 작업 이외의 작업을 수행 할 수 없다. 이렇게 특정 작업에 묶여 있는 다수의 Thread가 존재하는 것은 대기상태인 Thread가 다수 존재할 수 있음을 암시하고 이것은 I/O Bounds를 발생 시킬 여지가 있다.

Spring WebFlux

• 반응형 프로그래밍
  • 데이터를 중심으로 프로그램 개발을 진행하는 방식이다.
  • 기본적으로 Stream을 통해 비동기적으로 개발을 진행한다.
  • Reactive Stream의 형태는 선언형 프로그램의 형태를 띈다.
• 메모리 효율성 소수의 Thread를 운용하는 철학을 가진 WebFlux는 상대적으로 많은 수의 Thread를 생성하지 않는다. 이는 상대적으로 Thread 자체적인 메모리 할당이 많지 않다는 뜻이므로 효율적으로 메모리를 사용한다고 할 수 있겠다.
• CPU Bounds: 시스템의 성능이 CPU의 처리 능력에 의해 제한되는 경우 소수의 Thread를 운용하는 철학을 기반으로 다수의 Thread를 생성하지 않아 다수의 Context Switching이 발생할 여지가 많이 줄어 CPU Bounds가 상대적으로 덜하다고 할 수 있다.
• I/O Bounds: 시스템의 성능이 I/O 작업에 의해 제한되는 경우 하나의 요청에 대해서 NonBlocing I/O 모델을 기반으로 작업을 수행한다. 하나의 요청에 대해 작업을 처리하는 Thread는 상황에 맞게 효율적으로 다수의 작업을 진행할 수 있음을 암시한다. 즉, 병목현상이 발생하지 않는다는 말이다. 이는 I/O Bounds가 상대적으로 덜하다고 할 수 있다.

  주의점 위의 설명과 차이점을 비교해보면 WebFlux를 사용하는 것이 무조건 더 나은 성능을 발휘한다고 생각할 수 있겠다. 그렇다면 진짜 무조건 WebFlux가 MVC보다 무조건 더 나은 성능을 발휘할까? 결론은 그렇지 않다. 적은 수의 Thread를 운용하는 WebFlux의 가장 큰 약점은 병목현상이다. 개발자의 실수 또는 환경으로 인해 병목현상이 발생하면 특정 Thread는 그 작업에 묶이게 되고 적은 수의 Thread를 운용하는 WebFlux의 성능은 현저히 떨어진다. 실제 병목 현상이 발생하면 Spring WebFlux가 Spring Web MVC 보다 더 낮은 성능 퍼포먼스를 보인다. 그러니 WebFlux를 사용할때는 항상 병목현상을 주의하고 병목현상에 대한 테스트를 반드시 진행해야 한다.

MSA 프로젝트 MVC Module, WebFlux Module 경계 설정

우리는 위의 설명을 통해 Spring Web MVC와 Spring WebFlux의 차이를 이해하고 서로다른 두 모델을 이해했다. 그렇다면 실제로 코드를 작성하는 개발자 입장에서는 어떠한 차이점이 있을까? 결론은 Spring WebFlux는 Reactive Programming을 기반으로 Reactive Stream(Mono, Flux)을 구현해야 한다. 그 결과 아래의 4가지 기술을 구현하는 방식이 달라진다. 이를 근거로 하여 mvc module과 webflux module을 분리했다.

• Exception Handler
• Resolver
• Filter
• Client

질문 👨🏻‍💻) 리액티브 스트림이 뭔가요 간단히 설명해서 리액티브 스트림은 데이터를 중심으로 행위의 흐름을 나타내는 집합이라고 할 수 있다. 이러한 여러 스트림의 상화작용을 통해 우리는 논리를 완성하고 기능을 구현한다. 그리고 이것을 복합적으로 Reactive Progamming이라고 할 수 있겠다.

마무리

필자는 원래 iOS, Android를 개발한 Mobile 개발자였다. 지금도 회사에서 백엔드를 메인으로 개발을 진행하고 있지만 iOS, Android 개발도 필요하면 진행하고 있다. (ex) WebView Mapping, fcm 기능, DynamicLink 기능) iOS, Android 개발을 할때 필자는 RxSwift, RxKotlin을 사용한다. 이 Rx 시리즈들은 Reactor과 같이 Reactive Streams의 구현체다. 필자는 모바일 개발을 할때 Reactive Progreamming을 기반으로 많은 프로그래밍을 했고 많은 학습을 진행했는데 WebFlux를 다시 봤을때 너무 반가웠다. 다시 고향으로 돌아온 느낌이였다.

그런데 갑자기 본질적인 질문이 머릿속에 떠올랏다. 왜 Spring 사단에서는 Reactive Programming이 대중화 되어 있지 않을까? (실제 Mobile 사단에서는 Reactive Programming은 기본이다.) 러닝 커브 때문인가? 아니면 Reactive Programming을 사용하는 것은 오버스팩이고 사용할 필요가 없어서 사용하지 않는것인가? 모바일도 그렇고 백엔드도 그렇고 다른 Framework이나 기술들을 살펴보면 확실히 비동기 프로그래밍의 중요성, 이를 기반으로 한 Publish, Subject 개념은 대두되고 있다. (이는 복잡한 세상의 비지니스를 해결하기 위한 노력과 하드웨어의 발전사(더 많은 CPU 코어수)와 관련이 있을것이다.) 즉, 이 두 개념을 기반으로 한 Reactive Progamming은 시대의 발전과 함께 가고 있다. 그렇다면 왜 적극적으로 이 시대의 흐름을 반영하지 않는것인가.

백엔드의 시스템은 방대하다. 하나의 시스템이 몇년 길게는 10년을 넘길 수 있다. 이렇게 긴 수명으로 유지된 시스템의 본질과 근간을 바꾸는 것은 쉽지 않을것이다. 효율성이 떨어진다고 해도 올바르게 동작하는 시스템을 개혁해서 위험 부담을 지는것은 옳지 않은 판단이다. 그래서 변하기 쉽지 않구나, 트랜드를 바로 반영하기 쉽지 않구나 생각했다. 또한 이러한 흐름을 기반으로 개발한 다수의 개발자들은 이 기조를 기반으로한 기술에 특화되어 있을것이다. 시스템을 개발하는 대상의 Pool또한 여기에 맞춰질 수 밖에 없다. 그러니 시대의 흐름이 아무리 변하고 더 좋은 기술이 나와도 신중해질수 밖에 없다.

하지만 필자는 미래에 모두 Reactive Programming으로 개발할 것이라고 생각한다. 개발자에게 여러 중요한 덕목이 있지만 그중 가장 중요한 덕목은 항상 자원을 낭비하지 말고 효율적으로 사용하자는 것이다. WebFlux도 그렇고 모든 Reactive Programming이 자원을 효율적으로 사용하자는 철학을 근거로 한다. 또한 기술의 발전이 이를 중심으로 발전하고 있다. 지금 현재는 복잡하고 어려워 오버스팩이라는 소리를 듣지만, 모두가 익숙해지는 날이 오고 위의 아름 다운 철학과 시대의 흐름이 잘 녹여진다면 기본이 되고 표준이 될것이라고 생각한다.

긴글 읽어주셔서 감사합니디.☺️

Hexagonal Architecture - 훌륭한 아키텍처는 코드를 보는 좋은 눈을 길러준다.

Architecture의 중요성에 대해 이전 Hexagonal Architecture글에서 많이 언급한거 같다. 이번 시간에는 MSA의 환경에서 Hexagonal Architecture의 효용성과 어떻게 코드를 작성하면 좋을지 이야기 하는 시간을 가져보겠다.

'외부로 부터 비지니스를 지키고 집중하자'는 핵심 철학을 가진 Hexagonal Architecture의 시각적 그림은 위와 같다. 그러나 위의 그림을 보고 Hexagonal Architecture를 이해 하는것은 무리가 있다. 조금더 실전적인 그림을 보자

Hexagonal Architecture 시나리오

이 그림은 필자가 핵사고날 아키텍처를 직접 사용하면서 정리한 시나리오다. 이 시나리오를 만들면서 생각한 생각을 공유하고자 한다.

1. In Adapter 동작

• 외부 호출에 대한 상호작용을 담당하는 In Adapter의 대표적 사례로는 Controller, Kafka Consumer, Spring Batch가 있다. In Adapter에서는 결국 In Port(UseCase)를 통해 Business를 담당하는 Service를 호출 할 것이다. 이때 요청과 함께 받아온 데이터 AsyncTask, Request Body, Header를 Command로 변환하여 호출한다.

👨🏻‍💻질문) Command로 변환해서 호출하는 이유가 뭔가요?

• Command는 Service의 함수를 호출하는 실행 단위이다. Command를 만든 이유는 크게 2가지다. 첫째, 어떠한 값 요청이 들어오든 결국 Command로 변환해서 호출 해야 되니 Validation Check를 Command에서만 하면 된다. 즉, Validation Check의 시점을 하나로 모는 효과를 가진다. 둘째, 필자는 Header로 부터 전달 받은 값을 서비스 로직에서 사용하기 위해 SuvletHttpRequest를 Service에 전달하는 코드를 본적이 있다. 이 코드는 테스트 코드를 작성할때 문제가 된다. 테스트 코드는 외부의 의존성으로 부터 자유로워야 하고 순수해야 하는데 SuvletHttpRequest에 의해 외부 제약이 생긴다. 이러한 문제를 예방하고자 필자는 Command를 만들었다. Command를 통해 외부 의존성으로 부터 자유롭고 순수해질 수 있다. 그렇다면 flat하게 데이터를 Service에 전달하면 되지 않냐는 반문을 받을 수 있다. 그러나 이 방법은 첫번째 의도를 지킬 수 없다.

2. 여러개의 In Port와 Service

• 하나의 도메인에서 관심사에 따라 여러개의 서비스가 분리될 수 있다는 점을 강조하기 위해 여러개의 UseCase와 Service를 그렸다.

👨🏻‍💻질문) 하나의 도메인에 존재하는 여러 서비스가 서로가 서로를 참조해도 되나요?

• Hexagonal Archiecture에서 Service가 외부와 상호작용 한다면 반드시 Port를 통해 상호작용해야 한다는 중요한 원칙에 위배 되기에 필자는 이 부분에 있어서 참조하면 안된다고 생각한다. 원칙을 위배 하는 행위는 지속가능한 개발을 막는 요소 중 하나다. 우리가 원칙을 배워야 하는 이유이기도 하다. 그럼 무엇이 중요할까? Service를 나눈다면 경계를 분명히 하여 잘 나누자.

3. Out Port, Out Adapter

• Out Port는 Service가 외부의 의존성(Out Adapter)을 호출하기 위한 접합부다. Out Port의 특징중 하나는 추상화 되어 있다는 점이다. 즉, Service 입장에서는 어떠한 외부(Out Adapter)와 통신하는지 모른다. Persistence일 수 있고, Service일 수 있다.

👨🏻‍💻질문) Out Port를 호출할때 flat하게 값을 파라미터로 전달하는 이유는 뭔가요?

• 위에서 Command에 대한 얘기를 했다. Command는 분명히 Validation Check라는 효용성이 있다. 있었기에 Command를 만들었다. 그러나 Out Port를 호출할때 값 객체를 만들어 봤을때 큰 효용성이 없다. 없어서 만들지 않았다.

👨🏻‍💻질문) Port와 상호작용한 결과를 Response로 정의한 이유는 무엇인가요?

• Service는 어떠한 외부와 통신하는지 모른다. 그저 추상화된 Port를 통해 외부와 상호작용을 하는것이 전부다. Response를 만든 이유는 만약 특정 의존성의 종속적인 값을 리턴 받는다면 외부의 의존성이 변하는 순간(ex) Spring Data JPA -> Spring Data MongoDB) Service의 비지니스 로직에 영향을 준다. Hexagonal Architecture에서는 Business를 잘 지키고 집중하는 것이 목표다. 즉, Open-Closed Principle을 지켜 비지니스를 지키기 위해 Response를 만들었다.

Package 구조

그렇다면 실제 프로젝트에서는 어떻게 package가 구성되는지 살펴보자. Package 구조는 아래와 같다. 아래와 같은 package 구조를 통해서 위에서 설명한 효용성을 이룰 수 있다.

확장성

각자 도메인에 대해 위의 시나리오를 기반으로 개발하면 여러 육각형들이 생겨날 것이다. 각각의 육각형들은 각각의 Business를 담당하고 필요에 의해 서로 상호작용 할 것이다. 원칙을 준수한 시나리오를 기반으로 각각의 육각형들을 확장해 나갔다. 분명 원칙을 지켜나갔다면 유지보수를 넘어 지속 가능한 소프트웨어가 될것이라 기대한다.

마무리

왜 갑자기 MSA 심장부를 설계하다 (MSA Common) 시리즈에서 Hexagonal Architecture를 설명했는지 의아해 하시는분이 있을것 같다. 일관성은 지속가능한 소프트웨어를 구축하는데 가장 중요한 덕목이다. 일관성을 지키기 위해서 우리는 원칙을 지켜야 한다. Architecture는 이러한 원칙을 지키게 한다. Common을 설계하는 이유가 중복된 코드를 줄여 효율성을 높이자는 것도 맞는 말이지만 더 중요한 사실은 팀의 원칙을 설계하는것이 아닐까? 이러한 관점에서 필자는 Architecture가 진정한 Common이라 생각했다. 그래서 이번 시리즈에 반드시 설명해야 하는 부분이라고 생각하여 글을 작성해 봤다.

긴글 읽어 주셔서 감사합니다😀

질문 🧑🏻‍💻) 공통으로 Api Result를 설계 하는것은 타당한가 MSA 환경은 쉽게 말해 서로다른 여러 서버가 존재 할 수 있다는 말이다. 즉 클라이언트 입장에서 서로 다른 여러 서버와 소통해야 한다. 소통을 해야 하는데 응답 값이 각 서버마다 다르다고 한다면 Client는 서로 다른 응답 값에 대해 관리하고 대응해야 한다. 이 말은 관리 포인트가 많아진다는 얘기다. 필자는 이러한 상황을 적합하지 않다고 판단했다. 통합된 응답 값이 관리 포인트를 낮추고 일관되게 만들어 준다. 그럼으로 공통으로 API Result를 설계하는 것은 적합한 행위다.

질문 🧑🏻‍💻) 더 나아가 MSA 환경에서 Common을 구현하는 것은 적합한가 독립적으로 개발하고 배포하는 것을 목표로 하는 전통 MSA를 지향하는 관점에서 사실 Common은 적합하지 않을 수 있다. 결합도를 높이기 때문이다. 그럼에도 불구하고 필자는 MSA 환경에서 Common을 만들고 이것을 MSA 심장부라 부른다. 비지니스 로직을 구현하기 위한 보조기능들에 대해 첨예하게 관리가 가능하고, 팀 규칙으로서 일관된 프로그래밍을 가능하게 하기 때문이다. 즉, 최종적으로 Common은 규율과 원칙의 기준이 되고 더 철저한 유지보수를 가능하게 한다. 결합도를 높이는 단점이 있지만 Common을 잘 이해하고 관리한다면 장점이 더 탁월하기에 Common을 구현하는 것은 적합하다 생각한다. MSA에도 정답은 없다. 각 팀의 상황, 각 비지니스 상황을 이해하고 그에 맞는 전략과 기준을 세워 프로젝트를 구축하는게 훌륭한 개발자의 덕목이지 않을까?

어떻게 내리고 싶은가

API Success

• httpStatusCode: 2xx
• httpBody:

  {
   result: {
       "code": String,
       "reason": String,
       "Message": String
    }, 
    body: { 
        <T>
    }
  }

API Fail

• httpStatusCod : 4xx, 5xx
• httpBody:

  {
    result: {
      "code": String,
      "reason": String,
      "frontMessage": String
    },
    body: { }
  }

필자의 MSA 프로젝트에서 내리고 싶은 API Result는 결론적으로 위와 같다. 구현해보자.

설명

1. Result Api Result의 meta-data의 정보를 담는 class이다. 추가로 필자는 clientUseMessage라는 field를 추가했다. 서버에서 각 상황에 필요한 client use message를 내려주기 위함이다.
2. ErrorCode 서버 개발을 하다보면 각 도메인, 각 상황에 따른 예외 상황이 존재한다. 이 예외 상황에 대한 정보를 추상화한 interface이다. ErrorCode interface의 추상화 함수는 getter에 대한 함수이고, 실질적으로 이를 구현하는 enum의 field 역할을 한다. ErrorCode는 Result에 예외 상황에 대한 정보를 전달하는 역할을 담당한다. Result.java 파일의 public static ERROR() 함수를 참고하면 된다.
3. Api Result의 정보와 Body 정보를 담는 역할을 한다. public static OK(), public static ERROR() 함수를 통해 성공에 대한 Api Result, 예외 상황에 대한 Api Result를 전달 할 수 있도록 설계했다.
4. ApiException Exception을 발생할때 ExceptionHandler에게 전달할 정보를 가지는 interface이다. 이 interface의 추상화 함수도 실질적으로 구현체의 getter에 대한 함수이며, 구현체의 field 역할을 한다.

아래의 코드를 천천히 살펴보길 바란다.

@Getter
@NoArgsConstructor
public class Result {
    private static final String SUCCESS_CODE = "lucycato";
    private static final String SUCCESS_REASON = "success";
    private String code;
    private String reason;
    private String clientUseMessage;

    public static Result OK() {  
        Result result = new Result();  
        result.code = Result.SUCCESS_CODE;  
        result.reason = Result.SUCCESS_REASON;  
        result.clientUseMessage = "";  
        return result;  
    }  

    public static Result ERROR(ErrorCode errorCode) {  
        Result result = new Result();  
        result.code = errorCode.getCode();  
        result.reason = errorCode.getReason();  
        result.clientUseMessage = errorCode.getClientUseMessage();  
        return result;  
    }  

    public static Result ERROR(ErrorCode errorCode, String reason) {  
        Result result = new Result();  
        result.code = errorCode.getCode();  
        result.reason = reason;  
        result.clientUseMessage = errorCode.getClientUseMessage();  
        return result;  
    }  
}

public interface ErrorCode {
    Integer getHttpCode();

    String getCode();  

    String getReason();  

    String getFrontMessage();  
}

@Getter
@NoArgsConstructor
public class Api {
    private Result result;
    private T body;

    public static <T> Api<T> OK(T body) {  
        Api<T> api = new Api<>();  
        api.result = Result.OK();  
        api.body = body;  
        return api;  
    }  

    public static Api<Object> ERROR(Result result) {  
        Api<Object> api = new Api<>();  
        api.result = result;  
        api.body = new Object();  
        return api;  
    }  

    public static Api<Object> ERROR(ErrorCode errorCode) {  
        Api<Object> api = new Api<>();  
        api.result = Result.ERROR(errorCode);  
        api.body = new Object();  
        return api;  
    }  

    public static Api<Object> ERROR(ErrorCode errorCode, String reason) {  
        Api<Object> api = new Api<>();  
        api.result = Result.ERROR(errorCode, reason);  
        api.body = new Object();  
        return api;  
    }  
}

public interface ApiException {
    Integer getHttpCode();

    Result getResult();  
}

사용

• Success 예외 상황 발생 없이 end-point의 함수가 정상적으로 호출이 되어 위의 코드와 같이 return을 하면, 우리가 말한 위와 같은 Api Result 규격으로 잘 내려갈 것이다.
• Fail 위의 코드와 같이 예외를 던진다면 ExceptionHandler에 예외 정보를 전달할 것이다. 즉, 우리가 말한 위와 같은 Api Result 규격으로 사용자에게 잘 내려갈것이다.
  • MSA Handle Execption에 대한 내용은 추가 포스팅에서 설명하도록 하겠다.

마무리

클라이언트와 잘 소통하는 것은 서버의 중요한 덕목이다. 이번 글에서는 우리의 소통 약속을 정하고 어떻게 하면 클라이언트와 잘 소통하는지에 대해 이야기 했다. 다음 시간에는 spring-web-mvc, spirng-webflux 두개의 큰 관심사에 대해 경계를 잘 나누어 어떻게 module로 분리하면 좋을지에 대해서 이야기 하는 시간 가지도록 하겠다.

연구가 진행 되어될 부분

질문 🧑🏻‍💻) 예외 상황에서는 클라이언트에게 body 값을 내려주지 않는다. 이렇게 설계를 하는것은 올바른가 예외 상황에서 값을 내려준다고 하면 어떠한 상황이 예외상황에서 body를 내려주는것이 적합한 것인가

• Api.java 파일의 ERROR 함수를 보면 body를 무조건 Object로 내리는 것을 확인할 수 있다. 즉, 지금 설계한 구조는 예외상황이 발생했을때는 body의 값을 받을 수 없다는 얘기이다. 이는 타당한가. 현재 필자는 이 부분에 대해 분석 / 연구를 진행하고 있다. 연구가 끝다면 다시 글을 쓰도록 하겠다. 감사합니다. 😀

요구사항 정리

1. MSA 프로젝트 전반에서 사용할 공통 기능을 구축해주세요.
2. sync, blocking I/O를 기반으로 한 spring-web-mvc를 기반으로 service를 개발할 수 있도록 해주세요.
3. async, non-blocking I/O를 기반으로 한 spring-webflux 기반으로 service를 개발할 수 있도록 해주세요.

필자에게 주어진 요구사항을 크게 3가지로 정리하면 위와 같다.

'질문의 질이 답의 질을 결정한다.' 올바른 답으로 나아가기 위해 올바른 질문을 해야 한다는 중요한 교훈이 담긴 말이다. 스스로 질문해보자. 무엇을 설계해야 하는가, 각 프로젝트에서 공통으로 무엇을 대응해야 하는가, 공통으로 비지니스 로직을 구현하기 위한 수단(보조 로직)은 어떤 것들이 있는가, spring-web-mvc, spring-webflux의 경계는 어떻게 나눌것인가

설계

1. Hexagonal Architecture
2. API Result
3. mvc module, webflux module 경계
   • Tomcat vs Netty
   • CPU Bounds
   • I/O Bounds
     • Spring Web MVC vs Spring WebFlux
4. MSA JWT 전달 전략 like Fractal
   • Local Thread, Reactor Context
   • MSA Resolver
   • MSA Filter
5. MSA Handle Exception
6. MSA 통신 전략
   • CommonHttpClient
   • CommonWebClient
   • Kafka

위에서 한 질문을 기반으로 6가지 기준을 산정해서 설계했다. 'No Silver Bullet'이라는 말이 있듯 개발에 정답은 없다. 이 설계도 정답은 아닐 것이고, 지속적으로 다듬고 발전시켜 나가야 한다.

마무리

개발에 정답은 없지만 각 시점에서 자신의 연구하고 정리한 궁극은 있다. 최근에 정말 많은 고민과 생각을 했다. 어떤 날은 코드를 작성하는 시간보다 생각을 하는 시간이 더 많은 날도 있었다. 각 경계를 머릿속으로 그리며 이렇게 내가 코드를 작성하고 설계 했을 때 과연 팀원들이 납득 하면서 사용할지 일관되게 사용할 수 있는지, 이러한 구조로 코드를 작성하는 것은 타당하고 올바른지 생각의 사냥을 멈추지 않았다. 머릿속의 코드가 수십 번 지워지고 다시 작성되었다. 그렇게 나의 궁극이 탄생 되었다. MSA 심장부를 설계하다 시리즈는 어떻게 MSA 프로젝트의 공통부를 설계해야 하는가에 대한 현재 나의 궁극이다.

가끔 이러한 질문을 받을때가 있다. '저는 회사에서 Layered Architecture로 코드를 짜는데 굳이 Hexagonal Architecture을 알아야 할까요?' 나의 답변은 항상 일관되었다. 회사에서 Hexagonal Architecture을 쓰지 않더라도 Hexagonal Architecture의 철학과 효용성을 이해하고 다시 Layered Architecture를 본다면 코드를 보는 눈이 달라질 것입니다.

필자는 원래 iOS 개발자였다. 모바일 개발을 할때 다양한 아키텍처에 대해 학습을 하게 되었는데 그 중 많은 학습 시간을 들였던 MVVM 디자인 패턴을 기반으로한 Clean Architecture는 코드를 보는 눈을 한단계 향상시켜줬다. 규율과 원칙하에 코드를 작성해야 하는 이유들에 대해 배웠고 규율과 원칙하에 내가 작성한 코드가 잘못되었음을 알게되었다. 반성할 수 있게 되니 코드를 보며 생각이 더욱 깊어졌고 코드의 디테일을 보는 눈이 생겼다. 그렇게 하나씩 원칙을 지키고 수정하다보니 일관되어졌고 일관된 코드는 시간이 지난 내가, 다른 누군가 봤을때 큰 흐름을 이야기 해줬다. 그렇게 큰 문맥을 지닌 코드의 힘은 말로 설명할 수 없었다. 미래의 내가 편했고 미래의 누군가가 편했다. 그렇게 나는 아키텍처의 힘에 빠져들었다.

Spring 개발을 처음했을때 Layered Architecture를 직면했다. 의존성 주입을 통한 각 관심사에 따른 Layer의 단일 참조 철학은 MVVM을 기반으로 한 Clean Architecture와 비슷했다. MVVM 기반 Clean Architecture에서는 VM에서 비지니스 로직에 집중했고 Repository 영역은 Persistence 영역과 같이 Local Data, Server Data를 제공했다. Layered 아키텍쳐도 Service에 비지니스 로직을 집중했고 Persistance 영역에서는 데이터를 제공했다. 그러나 모바일의 환경과 서버 환경을 비교했을때 서버가 상대적으로 외부의 의존성에 대해서 더 많은 확장을 요구했다. 이러한 문제로 Service의 비지니스 로직이 점점 희석되어 간다는것을 깨닳았다. 즉, 보조로직이 비지니스 로직을 희석시키고 있었다.

비지니스 로직은 다양한 외부와의 복잡한 상호작용을 통해 만들어 진다. 외부의 API를 요청하여 결과 값을 받고 Persistence의 CRUD는 비지니스 로직을 위한 수단이지 그 자체가 비지니스 로직이 아니다. 작은 도메인에서는 그것이 상응할 수 있겠지만 큰 도메인과 여러 시스템이 공존하는 큰 시스템에서는 한계에 부딛힌다.

나는 이러한 문제를 해결하고 싶었다. 나의 바램은 Service Layer를 봤을때 비지니스의 흐름과 원리를 분명하게 파악하고 싶었다. 그렇게 나는 이러한 문제를 해결할 수 있는 방법들에 대해 연구했고 그 중 Hexagonal Architecture는 이 문제를 해결하기 위한 강력한 수단이였다.

Hexagonal Architecture 설명

• Domain / Business
  • Hexagonal Architecture의 중심이다. Hexagonal Architecture의 원리와 원칙은 Domain / Business 영역을 중심으로 이뤄진다. 이 영역에서 작성되는 코드는 서비스의 비지니스와 관련된 원리와 흐름이 작성된다. 그 외 부가적인 것은 작성하지 않는다. Hexagonal Architecture에서 가장 지키고 싶고 소중히 여기는 부분이다. 우리도 소중히 여기자.
• Adapter
  • 외부와 상호작용을 하는 실질적 구현체이다. Endpoint Trigger, CRUD, 외부 API 호출 등... 비지니스 로직을 수행하기 위한 부가적인 로직은 모두 Adapter에서 이루어진다.
• Port
  • 비지니스 로직은 외부의 의존성에 의해 변질되어서 안된다. 그 변질을 막기 위해 Hexagonal Architecture는 Service와의 상화 작용은 반드시 Port를 통해서 상호작용 하도록 원칙을 제시하고 있다. 외부로 부터 유연한 변화와 대응을 가능하게 하는 중요한 연결 접합부다.
• In / Out
  • Domain / Business 영역을 중심으로 외부를 호출하는 것을 Out이라한다. 또한 Domain / Business 영역을 중심으로 안으로 들어오는 것을 in이라고 한다. 이렇게 탄생한 개념으로 in-adapter, in-port, out-port, out-adapter가 있다. 이렇게 만들어진 in-out의 개념을 통해 더욱 분명한 경계를 만들 수 있다. 이렇게 만들어진 분명한 경계는 체계적인 확장 가능함을 야기하고 코드를 작성하는 분명한 원칙을 제시한다.

위의 설명에서 알다 싶이 Hexagonal Architecture는 엄격한 규율과 규칙이 있다. 이러한 규율과 원칙은 반성하게 하고 일관되게 할것이다. 종합적으로 Hexagonal Architecture는 아래와 같은 특징을 지닌다.

Hexagonal Architecture 특징

• 확장성
  • Port를 통해 외부의 변화에 대해 Domain / Business가 변질되지 않는다 했다. 또한 In-Out의 개념을 통해 명확한 기준으로 체계적으로 확장할수 있다고 했다. Hexagonal Architecture는 확장성에 강하다.
  • • 이해를 돕기 위해 예를 하나 들겠다. NotificationPort라는 out port가 있다. 이 out port는 Service의 Field이다. 추후 이 Port를 구현하는 구현체가 Spring Container에 의해 이 변수에 의존성 주입이 될것이다. 그리고 현재 이 Port를 구현하는 Out Adapter는 NotificationPersistenceAdapter이다. 즉 위에서 말한대로 이 PersistenceAdapter가 의존성 주입이 되어 비지니스 로직을 구성할것이다. 그런데 모종의 이유로 Notification이 서버로 분리됬다고 하자. 그리고 이 외부와의 상호작용을 하는 out Adapter를 NotificationServiceAdapter라 하자 이 친구는 Port를 구현한다. 아까와 똑같이 비지니스 로직은 NotificationServiceAdapter를 통해 로직이 구성이 된다. 그러나 Service 입장에서는 변하지 않는다... 즉 외부의 변화로 부터 안전하다. 왜 내가 이름을 NotificationPort라고 했는지 이해가 되는가? 이해가 되면 좋겠다 ㅎㅎ
• 유지보수성
  • Hexagonal은 Domain / Business, Adapter, Port, In-Out이라는 복합적 개념을 통해 명확한 원칙을 제시한다고 했다. 명확한 원칙은 명확한 방향성을 야기한다. 또한 일관성을 야기한다. 명확한 흐름과 일관성은 시간이 흐르고 사람이 바뀌어도 시스템을 유지할 수 있는 유지보수성을 야기한다.
• 테스트 용이성
  • Domain / Business를 지키는것이 Hexagonal Architecture의 중요한 원칙이라 했다. 또한 Domain / Business는 외부의 의존성으로 부터 자유롭다. 그러기에 테스트가 용이해진다. 테스트 용이성 외적으로 한가지 더 말하고 싶은 부분은 철저한 원리와 원칙을 통해서 명확히 경계를 나눈것이 HexagonalArchitecture이다. 즉 이렇게 나뉘어진 명확한 경계는 철저한 테스트를 야기한다.

마무리

'훌륭한 아키텍처는 코드를 보는 좋은 눈을 길러준다.' Hexagonal Architecture는 필자의 경험과 더불어 이 말의 힘을 실어준다. '규율이 곧 자유다.'라는 훌륭한 말이 있듯이 '훌륭한 아키텍처를 지키는 것이 곧 자유다.'

최근에 MSA 프로젝트를 진행하고 있는데 다양한 시스템이 확장되고 상호작용 하는 MSA 프로젝트에서 더욱 안성맞춤이다. 다음 시간에는 실제로 Hexagonal Architecture를 통해 어떻게 코드를 작성하면 좋을지 같이 논의해보겠다. 감사합니다.

kafka는 대량의 데이터를 높은 처리량, 낮은 지연, 안정적 운용을 위해 탄생한 시스템입니다.

Kafka란 무엇일까요? 우리는 가끔 대기업에 관련된 기사를 보면 하청업체에 일을 할당 했다는 기사를 볼 수 있습니다. 대기업은 하청업체에 일을 할당 함으로서 자신들이 집중할 수 있는 일에 더욱 집중 할 수 있게 되고 이로 인해 효율성을 확보 할 수 있습니다. 개발에도 이렇게 역할을 분리하여 일을 할당 시킴으로 효율성을 높이면 굉장히 좋지 않을까요? 이러한 일을 가능하게 만드는 시스템이 Kafka 입니다. 즉 Kafka를 한마디로 표현하면 '하청업체에 일을 할당하는 중간 관리자'라 할 수 있겠습니다.

질문 🧑‍💻) WebFlux도 비동기를 통해 효율성을 향상시키고 Kafka도 비동기를 통해 효율성을 향상시킨다 하는데 무슨 차이가 있나요?

• 같이 일하는 동료분이 이러한 질문을 한 적이 있습니다. Webflux는 하나의 회사에서 여러 직원들을 고용해서 효율성을 높이는 것이고 kafka는 하청업체에 일을 할당함으로서 효율성을 높이는 것입니다. 즉, 내부 인원 충원을 통해 효율성을 높이냐, 회사와 회사간의 협업으로 효율성을 높이냐의 차이가 있겠습니다.

이번 글에서는 Kafka를 사용한다면 어떻게 확장하고 성능을 개선할지, 비동기 통신으로 인한 데이터 정합성 문제를 해결하는지에 대한 사전 준비글을 작성해 보겠습니다.

• 참고 1부: 사전 지식과 청사진 공유 2부: 동영상을 통한 실전 운용 전략 설명

kafka 사전지식

1. Topic

• Kafka 서버는 여러 Topic을 관리한다. 이 토픽은 Kafka 서버에 값을 보내는 기준이 된다. 값을 보낼때는 Key, Value로 값을 보낸다.

2. Producer

• Topic을 기준으로 값을 보내는 주체이다. Producer가 Kafka Server에 값을 보낼때 어떠한 Topic에 어떠한 key, value값을 전달하지 값을 결정해서 보내면 된다.

3. Consumer

• Kafka Sever에서 관리하는 Topic을 구독하고 그 값을 전달 받는 주체이다. Consumer 또한 Producer와 동일하게 Topic을 기준으로 Key, Value 값을 받는다.

4. Consumer Group

• Kafka 서버의 Topic은 여러 Partition(데이터 파이프라인)이 관리가 된다. 여러 Consumer들은 하나의 Group으로 묶을 수 있는데 이렇게 묶인 Cosumer들은 하나의 Topic을 공유한다. 공유 한다는 말은 하나의 토픽의 여러 Partition들의 값을 Group에 묶인 Consumer들이 병렬적으로 값을 처리한다는 말이다. 이것은 kafka Server를 사용하여 성능을 높이는 중요한 척도이다.

5. Kafka Cluster

• 여러 kafka Server의 집단을 kafka Cluster라 부른다. 이렇게 여러 kafka Server를 운용하면 Load Balancing을 통해 데이터 처리의 성능을 높일 수 있다. 이 또한 Kafka 서버를 운용하면서 성능과 효율성을 높이는 중요한 척도이다.

6. kafka Reflication

• Topic을 생성할때 reflication 설정을 통해 여러 복제본을 운용을 할 수 있다. 예를 들어 reflication 설정을 3으로 하면 Topic의 각 Partition들의 복제본이 3개가 생성 되고 이중 한개의 파티션은 Leader Partition이 된다. 나머지 2개의 파티션은 Flow Partition이라 한다. Flow Partition은 지속적으로 Leader 데이터를 복제하여 최신 상태를 유지한다. 만약 Leader에 장애가 발생하여 운용이 불가한 상태가 된다면 내부적으로 복제본 중 리더를 선정하여 장애에 대응한다. 이는 kafka의 안정적 운용을 위한 중요한 척도이다.

  kafka 효율성을 높이는 방법

1. Topic의 Partition의 개수를 늘립니다. 그리고 하나의 Group을 공유하는 여러 Consumer들이 이 Topic을 구독합니다.

2. 물리적으로 Kafka 브로커 서버 여러개를 구축하여 Load Balancing을 통해 효율성을 높입니다.

비동기 통신에서 정합성을 맞추는 운용 전략

1. kafka 서버를 통한 비동기 통신 히스토리를 추적하는 하나의 서버를 준비합니다. (async-task-consumer-server)

2. Kafka Server에 Topic은 2개만 생성합니다.

   • task.topic
   • task.result.topic

3. 비동기 통신이 필요한 각 서버는 AsyncTaskProducer를 통해 값을 전달 합니다. 값을 전달하는 규격은 아래와 같습니다.

   key: {
    "transactionUUID": "",
    "aysncTaskCategory": Enum
   },
   body: {
    <T: Object>
   }

4. async-task-consumer-server에서는 task.topic을 구독하는 AsyncTaskConsumer를 통해 이 값을 전달 받습니다. 전달 받는 값은 async_task_history라는 DB에 업데이트 하여 history를 관리합니다.

• async_task_history의 DB는 Create만 이루어 집니다.
• 이렇게 쌓인 데이터는 추후 transactionUUID를 통해서 정합성을 맞추는 중요한 데이터가 됩니다.

5. history를 DB에 저장하면 AsyncTaskResultProducer를 통해 위와 같은 값 그대로 task.result.topic에 값을 전달합니다.

6. 각 서버는 각자의 관심사에 맞게 Consumer를 구축하고 task.result.topic을 구독하여 값을 전달받습니다. 전달 받은 값을 통해 특정 비지니스 로직을 수행하여 비동기 통신을 완료합니다.

7. 통신의 문제가 생겨 정합성 문제가 생긴다면 async-task-consumer-server에 저장된 고유값(UUID)을 통해 정합성을 맞추는 시도를 합니다.

마무리

다음 시간에는 영상 촬영을 통해 실제 프로젝트를 구축해보면서 어떻게 성능을 높이고 정합성을 맞추는지에 대해 설명 하도록 하겠습니다. 감사합니다.

프로젝트에서 사용된 라이브러리

1. RxSwift
2. RxCocoa
3. Snapkit
4. Then
5. lottie-ios
6. Toast-Swfit
7. PanModal
8. RxGesture
9. UIColor_Hex_Swift

참고할 블로그

• UX는 무엇이 결정 하는가 [1부]
• UX는 무엇이 결정 하는가 [2부]

목차

1. 데이터 통신 및 소통
2. 제공
3. URL 관리
4. 설정

데이터 통신 및 소통

1. Injection

• 설명
  • WKUserScript를 통해서 script와 injectionTime을 정해준다 그리고 webViewConfigure에 등록을 해줬다. 주입이 된 javascript 코드는 웹에서 전역적으로 사용이 가능하다.

2. Get 방식

• 설명
  • Person 객체를 통해서 SwiftUrl 객체를 생성한다. 이 객체는 Person의 정보를 통해 resultUrl을 완성시킨다. CommonWebViewController는 파라미터로 CommonUrlProtocol을 전달 받는데 SwiftUrl은 CommonUrlProtocol을 상속받은 struct 이므로 SwiftUrl을 전달한다.[*** 의존성 주입도 구현해 봤다.] 전달받은 객체를 통해 getUrl(resultUrl을 URL?로 리턴 시켜주는 함수) 함수를 호출하여 load한다.
  • ** 여기서 중요한 점은 3번째 사진과 같이 Person 데이터를 통해서 Get방식으로 데이터를 WebView에 전달했다는 것이다. 이런식으로 Get방식으로 데이터 전달이 가능하다. [*** Web으로 구현된 디테일 페이지를 호출 할때 유용하다.]

3. Bridge

• 설명
  • CommonWebView를 생성할때 bridgeName을 전달하여 웹뷰와 네이트브가 상호작용이 가능하도록 configuration.userContentController.add(_ scriptMessageHandler: WKScriptMessageHandler, name: String)이 함수에 연결을 해준다. 연결한 이름 하나를 통해서만 웹과 네이티브는 통신을 한다. 웹에서 네이티브에 브릿지 요청에 대한 시그널을 주면 func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) 함수가 호출이 되고 이 함수에서는 bridgeDelegate들에게 일괄적으로 functionName과 jsonData를 전달한다 전달받은 bridgeDelegate는 함수이름으로 분기를 하여 JsonData를 파싱하여 작업을 수행한다.
  • ** 이러한 원리를 착안했을때 마지막 두번째 사진과 같이 요청을 받으면 네이티브의 데이터를 브릿지로 넘겨준다. 또한 마지막 사진과 같이 소통도 가능하게 구현한다.

제공

제공을 하는것을 설명하는것은 Native View를 제공하는 것을 중점으로 설명을 하겠다.

• Bridge를 통한 네이티브 View 제공 및 동작 )

• 설명
  • 나는 이전 글 UX는 무엇이 결정 하는가에서 BottomModal, LoadingView에 대해서 정리를 했었다. 나는 이 부분에서 데이터만 잘 맞춰주면 충분히 웹에서도 사용이 가능하다는 발상을 했다. 그리고 이것은 하이브리드 앱에서 강력한 도구가 될것을 직감했다. 원리는 간단하다. 웹에서 bridge를 통해 BottomModal을 사용하기 위한 데이터를 넘겨준다. 자료구조는 첫번째 사진과 같다.(사진에서 보는것에서 알다시피 actions의 갯수에 따라서 선택할 리스트는 동적으로 적용된다.) 이러한 데이터를 넘겨받으면 네이티브에서는 데이터를 파싱하여 BottomModal을 생성 및 표현한다. 웹에서는 특정 기능 동작에 대한 actionId값을 넘겨주는데 네이티브에서는 특정 버튼에 대한 동작을 수행하면 다시 이 actionId를 웹에 전달한다.

    self.webView.evaluateJavaScript("doAction('\(action.actionId ?? "")')")

    이 actionId를 전달받은 앱은 정의된 기능을 수행한다. 이런식으로 다른 Modal, Toast, LoadingView 등의 컨트롤도 수행이 가능하다. 웹에서 네이티브의 View를 사용하므로서 표현에 강한 강점을 가질 수 있고 작업 효율에서도 웹에서 이러한 Component를 만들 필요 없이 네이트브에서만 준비하면 되니 효율적이라 할 수 있다.(단, 웹이 단독으로 존재하지 않는다는 가정에서)

• WebView에 진입할때 LoadingView

• 설명
  • WebView를 사용한다고 진입을 할때 Web에서 로딩을 하는 시간을 고려해야 한다 그럼으로 관장자인 Native에서는 Loading View를 띄어줄 수 있어야 한다. WebViewController에서는 웹이 로딩되는 시점에 생성 및 show()를 하고 로딩이 완료되면 hide 및 제거를 수행한다. 이렇게 해서 Web이 로딩을 할때 빈화면을 처리해서 사용자 경험을 향상시킨다. 네이티브는 이러한 액션에서 제공자의 역할도 하는것은 타당하다.

마무리

좋은 앱을 만들고 싶다. 그리고 내가 지금 만드는 앱은 하이브리드 앱이다. 앱 전반에 걸쳐서 WebView의 역할은 중요한 역할을 한다. 그렇다면 좋은 앱을 만들기 위해서는 더 나은 하이브리드 앱을 만들기 위한 고민을 해야 했다. 웹 개발자 분과 더 좋은 하이브리드 앱은 무엇일까에 대해서 많은 이야기를 나눴다. 우리의 결론은 Bridge에 있다고 답을 내렸고 더 나아가 Native가 관장자로서 하는 역할의 중요성에 대해 이야기 했다. 그리고 생각을 정리하고 코드를 구현했다. 이번 더 나은 하이브리드 앱 그리고 그 지점은 본질적으로 좋은 앱을 만들기 위해서 무엇에 대해 고민해야 되는지에 대한 글이다. 중요하고 소중한 경험이다. 나는 앞으로도 좋은 앱을 만들것이다. 그러기에 노력을 게을리 할 이유가 없다. 전체코드

긴글 읽어 주셔서 감사합니다.

회사의 프로젝트는 WebView를 연결하는 하이브리드 앱이다. 좋은 하이브리드 앱을 만들기 위해서는 어떠한 덕목이 필요할까? 이번 글에서는 좋은 하이브리드 앱을 만들기 위한 나의 고민들에 대한 정리를 작성하겠다.

하이브리드 앱을 만든다고 하면 고민을 해야 되는 주요 지점

1. 데이터 통신 및 소통
2. 제공
3. URL 관리
4. 설정

• 하이브리드 앱을 만들기 위해서 첫번째로 생각해야 되는 지점은 데이터 통신 및 소통을 어떻게 할 것인지 고민해야 된다. 나는 WebView와 소통하는 방식에 대해 아래와 같이 3가지로 분류 하였다. 각 상황과 데이터의 성격에 따라서 알맞게 사용하는 것이 중요하다.

1. Injection
   • WebView에 전역적인 데이터를 넘겨주는데 용이한 방법 (전역적 성격)
2. Get 방식
   • 특정 페이지에만 데이터를 넘겨주는 용이한 방법 (지역적 성격)
3. Bridge
   • Runtime 상황에서 데이터를 넘겨주는 유용한 방법
   • Runtime 상황에서 Native와 WebView 사이의 소통을 하게 해주는 근간
     • ex) 뒤로가기

• 두번째는 잘 제공하는것이다. 왜 제공해야 되는가? 그리고 무엇을 제공해야 하는가? 모바일 환경에서 웹이 단독으로 존재하는 상황과 Native와 소통을 할 수 있는 웹은 분명한 차이가 있다. 네이티브가 존재하는 웹은 네이티브를 통해 더욱 많은 일을 할 수 있다. 즉 네이티브가 관장자의 역할 로서 많은것을 제공해 주기 때문에 가능 한 일이다. 이러한 관점에서 봤을때 네이트브에서 웹뷰를 사용한다고 하면 많은 기능을 제공해야 되는것은 분명하다. 제공을 해야 되는 지점은 아래와 같다.

1. Native 고유 기능 (ex) GPS, 걸음수, 블루투스 등)
   • 웹에서는 사용 할 수 없는 네이티브만이 구현 할 수 있는 고유의 기능들이 있다. 웹에서 할 수 있는것 없는것을 잘 구분해서 네이티브에서 고유의 기능을 잘 제공하는것은 중요한 지점이다.
2. App Life Cycle에서 제공이 가능한 데이터
   • 앱 Life Cycle 전반에서 네이티브가 가지고 있는 값들이 있다. 예를 들어서 초기에 Splash 화면에서 받아서 App Life Cycle 전반에서 가지고 있어야 되는 정보가 있다고 하자 필요에 의해서 Native는 이 데이터도 웹에 제공 할 수 있어야 한다.
3. Native View
   • 필요에 의해서 네이티브는의 View도 제공한다 표현에서 경험적으로 판단할때 Native의 View가 더욱 화면 표현에 있어서 우의에 있다. (그리고 작업 효율성 재사용성 측면에서도 이 방법이 우의에 있다.) 예를 들어서 Native의 LoadingView, Modal, BottomModal 등에 대해서 제공이 가능하다. 또한 Native 관장자의 역할이다. 즉 Web이 로드하는 중 빈 화면이 보일때 특정 작업을 처리(LoadingView)해야 되는 역할은 네이티브가 하는것이 적합하다.

• 세번째는 URL을 잘 관리해야 한다. 우리 앱에서는 여러 도메인이 존재하는데 이러한 여러 카테고리의 도메인을 잘 관리하는것, 그리고 이 도메들 path를 잘 관리 해야 했다. 그리고 다른 프로젝트도 이러한 URL을 관리하는 것은 중요한 지점이라 생각한다.

• ex)

• 네번째 설정, WKWebView를 사용하면 WkWebView에 다양한 설정을 할 수 있다는 사실을 안다. 이 설정을 통해 우리 앱에 최적화된 WebView를 잘 붙일 수 있어야 한다. 다양한 설정들이 존재한다 상황에 걸맞게 설정을 잘 찾아 최적화를 시켜주는게 핵심인것 같다.

• ex)

마무리

이번 글에서는 더 나은 하이브리드 앱을 만들이 위한 주요 지점들에 대해서 살펴봤다. 다음 글에서는 데이터 통신 및 소통과 제공에 대해서 어떻게 코드로 구현했는지에 대한 설명을 이어가도록 하겠다.

UX는 무엇이 결정 하는가 [1부]에서는 왜 일관된 UX가 중요한지에 대해서 이야기를 했다. 이번 글에서는 실재 디자인적 일관성을 개발로 어떻게 구현했는지 설명하겠다.

이 프로젝트에 사용된 라이브러리

• RxSwift
• RxCocoa
• RxGesture
• Kingfisher
• Snapkit
• Then
• PanModal
• Toast-Swift
• Lottie-ios

글을 읽기전 참고 블로그

iOS 화면 판단

Modal

• 사용

• 구현부

  class CommonModal : BaseViewController {
    let disposeBag = DisposeBag()
  
    let blurView = UIView().then {
        $0.backgroundColor = .black.withAlphaComponent(0.3)
    }
  
    let parentView = UIView().then {
        $0.backgroundColor = .clear
        $0.layer.cornerRadius = 16
    }
  
    let titleLabel = UILabel().then {
        $0.textAlignment = .center
        $0.numberOfLines = 1
    }
  
    let imageView = UIImageView()
  
    let messageLabel = UILabel().then {
        $0.textAlignment = .center
        $0.numberOfLines = 0
    }
  
    let underLineView = UIView().then {
        $0.heightAnchor.constraint(equalToConstant: 1).isActive = true
    }
  
    let nagativeButton = UILabel().then {
        $0.textAlignment = .center
    }
  
    var nagativeDelegate : (CommonModal) -> Void = { _ in }
  
    let positiveButton = UILabel().then {
        $0.textAlignment = .center
    }
  
    var positiveDelegate : (CommonModal) -> Void = { _ in }
  
  

lazy var buttonStackView = UIStackView(arrangedSubviews: [nagativeButton, positiveButton]).then {
    $0.heightAnchor.constraint(equalToConstant: 44).isActive = true
    $0.distribution = .fillEqually
    $0.axis = .horizontal
}

let pillarLineView = UIView().then {
    $0.widthAnchor.constraint(equalToConstant: 1).isActive = true
}

override init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: Bundle?) {
    super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
    layout()
    bind()
}

required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}


/*
 화연에 표시
 */
func show() {
    /*
     현재 화면의 최상단에 보이는 ViewController가 자기 자신인지 판단.
     */
    if topMostViewController !== self {
        /*
         최상단 ViewController를 통해서 Modal 보여주기
         */
        self.view.backgroundColor = .clear
        self.modalTransitionStyle = .crossDissolve
        self.modalPresentationStyle = .overFullScreen
        topMostViewController?.present(self, animated: true)
    }
}

func bind() {
    nagativeButton.rx.tapGesture()
        .when(.recognized)
        .bind(onNext : { [weak self] _ in
            guard let self = self else { return }
            self.nagativeDelegate(self)
        })
        .disposed(by: disposeBag)

    positiveButton.rx.tapGesture()
        .when(.recognized)
        .bind(onNext : { [weak self] _ in
            guard let self = self else { return }
            self.positiveDelegate(self)
        })
        .disposed(by: disposeBag)
}

private func configure(
    title : String,
    message : String,

    image : UIImage?,
    imageUrl : String?,
    imgWidth : Int,
    imgHeight : Int,

    nagativeButtonStr : String,
    nagativeButtonDelegate : @escaping (CommonModal) -> Void,
    positiveButtonStr : String,
    positiveButtonDelegate : @escaping (CommonModal) -> Void,

    /*
     속성
     */
    titleColor : UIColor,
    messageColor : UIColor,
    nagativeButtonColor : UIColor,
    positiveButtonColor : UIColor,
    modalBackgroundColor : UIColor,
    lineColor : UIColor
) {
    self.titleLabel.text = title

    self.messageLabel.text = message

    /*
     image
     */

    imageView.snp.makeConstraints {
        $0.width.equalTo(imgWidth)
        $0.height.equalTo(imgHeight)
    }

    if let image = image {
        imageView.image = image
        imageView.snp.makeConstraints {
            $0.top.equalTo(titleLabel.snp.bottom).offset(16)
        }
    }

    if let imageUrl = imageUrl {
        imageView.kf.setImage(with: URL(string: imageUrl))
        imageView.snp.makeConstraints {
            $0.top.equalTo(titleLabel.snp.bottom).offset(16)
        }
    }

    /*
     setNavigationButton을 안한다면 숨겨서 positiveButton만 보이게 동작하자...
     */
    self.nagativeButton.isHidden = nagativeButtonStr.isEmpty
    self.pillarLineView.isHidden = nagativeButtonStr.isEmpty

    self.nagativeButton.text = nagativeButtonStr
    self.nagativeDelegate = nagativeButtonDelegate

    self.positiveButton.text = positiveButtonStr
    self.positiveDelegate = positiveButtonDelegate

    /*
     속성
    */
    self.titleLabel.textColor = titleColor
    self.messageLabel.textColor = messageColor
    self.nagativeButton.textColor = nagativeButtonColor
    self.positiveButton.textColor = positiveButtonColor
    self.parentView.backgroundColor = modalBackgroundColor
    self.underLineView.backgroundColor = lineColor
    self.pillarLineView.backgroundColor = lineColor
}

/*
 자신의 Design에 맞게 layout을 배치
 정확히는 설정을 했을때 그릇이 되는 View들에 대해서
 각 상황에 대응하는 layout을 배치하는 것이 핵심
 */
func layout() {
    [
        blurView,
        parentView,
        titleLabel,
        imageView,
        messageLabel,
        underLineView,
        buttonStackView,
        pillarLineView,
    ].forEach {
        view.addSubview($0)
    }

    blurView.snp.makeConstraints {
        $0.edges.equalToSuperview()
    }

    parentView.snp.makeConstraints {
        $0.width.equalTo(270)
        $0.center.equalToSuperview()
        $0.top.equalTo(titleLabel).offset(-16)
        $0.bottom.equalTo(buttonStackView)
    }


    titleLabel.snp.makeConstraints {
        $0.top.equalTo(parentView)
        $0.centerX.equalTo(parentView).inset(16)
    }

    imageView.snp.makeConstraints {
        $0.top.equalTo(titleLabel.snp.bottom)
        $0.centerX.equalTo(parentView)
    }

    messageLabel.snp.makeConstraints {
        $0.top.equalTo(imageView.snp.bottom).offset(16)
        $0.leading.trailing.equalTo(parentView).inset(16)
    }

    underLineView.snp.makeConstraints {
        $0.top.equalTo(messageLabel.snp.bottom).offset(16)
        $0.leading.trailing.equalTo(parentView)
    }

    buttonStackView.snp.makeConstraints {
        $0.top.equalTo(underLineView.snp.bottom)
        $0.leading.trailing.equalTo(parentView)
        $0.bottom.equalTo(parentView)
    }

    pillarLineView.snp.makeConstraints {
        $0.top.bottom.equalTo(buttonStackView)
        $0.centerX.equalTo(buttonStackView)
    }
}

class Builder {
    /*
     ...
     이후 필요한 속성에 대해서 지속적으로 추가하면 된다
     ex) Title, Message, button Font
     */

    /*
     Default 값 설정
     */
    private var title : String = ""
    private var message : String = ""

    private var image : UIImage? = nil
    private var imageUrl : String? = nil
    private var imgWidt : Int = 0
    private var imghight : Int = 0

    private var nagativeButtonStr : String = ""
    private var nagativeButtonDelegate : (CommonModal) -> Void = { _ in }
    private var positiveButtonStr : String = ""
    private var positiveButtonDelegate : (CommonModal) -> Void = { _ in }

    /*
     color 속성
     Default 값 설정
     */
    private var titleColor : UIColor = .black
    private var messageColor : UIColor = .black
    private var nagativeButtonColor : UIColor = .blue
    private var positiveButtonColor : UIColor = .red
    private var modalBackgroindColor : UIColor = .white
    private var lineColor : UIColor = .gray


    func setTitle(_ title : String) -> Self {
        self.title = title
        return self
    }

    func setMessage(_ message : String) -> Self {
        self.message = message
        return self
    }

    func setImage(_ image : UIImage?, width : Int, height : Int) -> Self {
        self.image = image
        self.imgWidt = width
        self.imghight = height
        return self
    }

    func setImageUrl(_ url : String?, width : Int, height : Int) -> Self {
        self.imageUrl = url
        self.imgWidt = width
        self.imghight = height
        return self
    }

    func setNagativeButton(
        _ label : String,
        _ delegate : @escaping (CommonModal) -> Void
    ) -> Self {
        self.nagativeButtonStr = label
        self.nagativeButtonDelegate = delegate
        return self
    }

    func setPositiveButton(
        _ label : String,
        _ delegate : @escaping (CommonModal) -> Void
    ) -> Self {
        self.positiveButtonStr = label
        self.positiveButtonDelegate = delegate
        return self
    }

    /*
     color 속성
     */

    func setTitleColor(_ color : UIColor) -> Self {
        self.titleColor = color
        return self
    }

    func messageColor(_ color : UIColor) -> Self {
        self.messageColor = color
        return self
    }

    func setNagativeButtonColor(_ color : UIColor) -> Self {
        self.nagativeButtonColor = color
        return self
    }

    func setPositiveButtonColor(_ color : UIColor) -> Self {
        self.positiveButtonColor = color
        return self
    }

    func setModalBackgroundColor(_ color : UIColor) -> Self {
        self.modalBackgroindColor = color
        return self
    }

    func setLineColor(_ color : UIColor) -> Self {
        self.lineColor = color
        return self
    }

    func build() -> CommonModal {
        return CommonModal().then {
            $0.configure(
                title: title,
                message: message,
                image: image,
                imageUrl: imageUrl,
                imgWidth: imgWidt,
                imgHeight: imghight,
                nagativeButtonStr: nagativeButtonStr,
                nagativeButtonDelegate: nagativeButtonDelegate,
                positiveButtonStr: positiveButtonStr,
                positiveButtonDelegate: positiveButtonDelegate,
                titleColor: titleColor,
                messageColor: messageColor,
                nagativeButtonColor: nagativeButtonColor,
                positiveButtonColor: positiveButtonColor,
                modalBackgroundColor: modalBackgroindColor,
                lineColor: lineColor
            )
        }
    }
}

}

- 설명
> Builder 클래스는 데이터 세팅 및 CommonModal의 최종 생산(build) 역할을 담당한다. 그리고 CommonModal는 이 데이터를 담는 그릇배치 및 표현(show)의 역할을 담당한다.
[자세한 설명은 주석 참고]

### BottomModal
- 사용
![](https://velog.velcdn.com/images/will_d/post/75faad97-bcdc-4de2-952c-5119c7794d82/image.png)
![](https://velog.velcdn.com/images/will_d/post/c6cd3cef-dba6-4de5-88b6-a8988cdc576a/image.png)
- 구현부

struct CommoBottomModalAction { let title : String let titleColor : UIColor let action : (CommonBottomModal) -> Void }

class CommonBottomModal : BaseViewController {

let disposeBag = DisposeBag()

let blurView = UIView().then {
    $0.backgroundColor = .clear
}

var actions : [CommoBottomModalAction] = []

let stackView = UIStackView().then {
    $0.spacing = 5
    $0.axis = .vertical
}

let cancleButton = UILabel().then {
    $0.heightAnchor.constraint(equalToConstant: 56).isActive = true
    $0.backgroundColor = .clear
    $0.clipsToBounds = true
    $0.layer.cornerRadius = 16
    $0.textAlignment = .center
}

func show() {

    /*
     최상단 ViewController가 자기 자신인지 판단
     */
    if topMostViewController !== self {
        topMostViewController?.presentPanModal(self)
    }
}

private func configure(
    _ actions : [CommoBottomModalAction],
    _ actionBackgroundColor : UIColor,
    _ cancelMessage : String,
    _ cancelBackgroundColor : UIColor
) {

    /*
     actionData Label로 변환
     실질 적인 UI/UX를 하는 실재로 변환하는 과정
     */
    let labels = actions
        .map { action in
            UILabel().then {
                $0.text = action.title
                $0.textColor = action.titleColor

                $0.heightAnchor.constraint(equalToConstant: 56).isActive = true
                $0.backgroundColor = actionBackgroundColor
                $0.clipsToBounds = true
                $0.layer.cornerRadius = 16
                $0.textAlignment = .center
            }
        }

    cancleButton.text = cancelMessage
    cancleButton.backgroundColor = cancelBackgroundColor

    /*
     stackView에 추가
     */
    labels.forEach {
        stackView.addArrangedSubview($0)
    }
    stackView.addArrangedSubview(cancleButton)


    [
        blurView,
        stackView
    ].forEach {
        view.addSubview($0)
    }

    blurView.snp.makeConstraints {
        $0.edges.equalToSuperview()
    }

    /*
     actions의 아이템 개수에 따라 stackView의 크기를 동적으로 결정
     */
    stackView.snp.makeConstraints {
        $0.leading.trailing.equalToSuperview().inset(16)
        $0.bottom.equalToSuperview().inset(38)
        /*
         주요 코드
         */
        $0.top.equalTo(labels[0])
    }


    /*
     bind
     */
    blurView.rx.tapGesture()
        .when(.recognized)
        .bind(onNext : { [weak self] _ in
            self?.dismiss(animated: true)
        })
        .disposed(by: disposeBag)

    cancleButton.rx.tapGesture()
        .when(.recognized)
        .bind(onNext : { [weak self] _ in
            self?.dismiss(animated: true)
        })
        .disposed(by: disposeBag)

    /*
     commonActionDelegate에서 정의한 함수 호출
     */
    labels
        .enumerated()
        .forEach { index, label in
            label.rx.tapGesture()
            .when(.recognized)
            .bind(onNext : { [weak self] _ in
                guard let self = self else { return }
                self.dismiss(animated: true) {
                    actions[index].action(self)
                }
            })
            .disposed(by: disposeBag)
    }
}


class Builder {
    /*
     필요한 Design에 맞게 속성 추가
     */
    private var actions : [CommoBottomModalAction] = []

    private var actionBackground : UIColor = .white

    private var cancelMessage : String = "취소"
    private var cancelBackgroundColor : UIColor = .gray


    func setActions(_ actions : [CommoBottomModalAction]) -> Self {
        self.actions = actions
        return self
    }

    func setActionBackgroundColor(_ color : UIColor) -> Self {
        self.actionBackground = color
        return self
    }

    func setCancelMessage(_ message : String) -> Self {
        self.cancelMessage = message
        return self
    }

    func cancelBackgroundColor(_ color : UIColor) -> Self {
        self.cancelBackgroundColor = color
        return self
    }


    /*
     설정을 모두 완료하고 이때 CommonBottomModal 생성
     */
    func build() -> CommonBottomModal {
        return CommonBottomModal().then {
            $0.configure(
                actions,
                actionBackground,
                cancelMessage,
                cancelBackgroundColor
            )
        }
    }

}

}

extension CommonBottomModal : PanModalPresentable {

var showDragIndicator: Bool {
    return false
}

var panScrollable: UIScrollView? {
    return nil
}

var shortFormHeight: PanModalHeight {
    return .maxHeightWithTopInset(0)
}

var longFormHeight: PanModalHeight {
    return .maxHeightWithTopInset(0)
}
var anchorModalToLongForm: Bool {
    return false
}

}

- 설명
> 기본 원리는 CommonModal과 같다. 다른점이 있다면 BottomModal의 경우에 Action의 개수가 다양 할 수있다. 예제 에서는 2개의 액션만 보여지지만 5개가 될 수 도 있다. 이 액션에 대해서 각각의 동작을 정의해 줘야 했기에 CommoBottomModalAction를 구현했고 이를 통해서 각각의 액션을 정의해 Builder에게 전달하는 식으로 개발을 했다.
[자세한 설명은 주석 참고]

### CommonToast
* 사용
![](https://velog.velcdn.com/images/will_d/post/4ed6c38f-79aa-4f56-bb5d-5c94fad7cf40/image.png)
* 구현

class CommonToast : UIView {

private let disposeBag = DisposeBag()

private var onClickDelegate : (CommonToast) -> Void = { _ in }

private let messageLabel = UILabel().then {
    $0.textAlignment = .center
    $0.numberOfLines = 0
}


override init(frame: CGRect) {
    super.init(frame: frame)
    layout()
    bind()
}

required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}

func show() {
    let topMostViewController = (UIApplication.shared.connectedScenes.first?.delegate as? SceneDelegate)?.window?.rootViewController?.topMostViewController
    topMostViewController?.view.showToast(self, duration: 1, position: .bottom)
}

private func bind() {
    /*
     ToastButton을 탭 했을때
     */
    self.rx.tapGesture()
        .when(.recognized)
        .bind(onNext : { [weak self] _ in
            guard let self = self else { return }
            self.onClickDelegate(self)
        })
        .disposed(by: disposeBag)
}

private func configure(
    message : String,
    messageColor : UIColor,
    backgroundColor : UIColor,
    onClickDelegate : @escaping (CommonToast) -> Void
) {
    self.messageLabel.text = message
    self.messageLabel.textColor = messageColor

    self.backgroundColor = backgroundColor

    self.onClickDelegate = onClickDelegate
}


private func layout() {
    [
        messageLabel
    ].forEach {
        addSubview($0)
    }

    messageLabel.snp.makeConstraints {
        $0.center.equalToSuperview()
    }
}


/*
 필요에 의해서 추가 속성 등록 및 사용
 */

class Builder {
    private var message : String = ""
    private var messageColor : UIColor = .black
    private var backgroundColor : UIColor = .cyan
    private var heightSize : CGFloat = 56

    private(set) var onClickDelegate : (CommonToast) -> Void = { _ in }

    func setMessage(_ message : String) -> Self {
        self.message = message
        return self
    }

    func setMessageColor(_ color : UIColor) -> Self {
        self.messageColor = color
        return self
    }

    func setBackgroundColor(_ color : UIColor) -> Self {
        self.backgroundColor = color
        return self
    }

    func setHeightSize(_ height : CGFloat) -> Self {
        self.heightSize = height
        return self
    }

    func setOnClickDelegate(_ delegate : @escaping (CommonToast) -> Void) -> Self {
        self.onClickDelegate = delegate
        return self
    }

    func build() -> CommonToast {
        let rootViewController = (UIApplication.shared.connectedScenes.first?.delegate as? SceneDelegate)?.window?.rootViewController
        return CommonToast(frame: .init(x: 0, y: 0, width: rootViewController?.view.frame.width ?? 0, height: heightSize)).then {
            $0.configure(
                message: message,
                messageColor: messageColor,
                backgroundColor: backgroundColor,
                onClickDelegate: onClickDelegate
            )
        }
    }
}   

}

* 설명
> 원리는 CommoModal과 같다.

### CommonLoadingView
* 사용
![](https://velog.velcdn.com/images/will_d/post/6a29b584-f753-428b-9d8b-9dcda468b47d/image.png)
![](https://velog.velcdn.com/images/will_d/post/52ca8785-ef61-465e-821c-ae8045838ed3/image.png)
![](https://velog.velcdn.com/images/will_d/post/4af15773-4357-4406-b879-299711402290/image.png)

- 구현

/* Lottie를 통한 LoadingView */

class CommonLoadingView {

var loadingView : LottieAnimationView? = LottieAnimationView(name: "lottie").then {

    $0.isHidden = true
    $0.loopMode = .loop
    $0.play()
}


var timer : Timer? = nil
var timeRemaining = 0.8



convenience init() {

    let superView = (UIApplication.shared.connectedScenes.first?.delegate as? SceneDelegate)?.window?.rootViewController?.topMostViewController?.view
    self.init(superView: superView)
}


init(superView : UIView?) {
    superView?.addSubview(loadingView!)
    loadingView?.snp.makeConstraints {
        $0.center.equalToSuperview()
    }
}


func show() {
    /*
     touch 비활성
     */
    let window = (UIApplication.shared.connectedScenes.first?.delegate as? SceneDelegate)?.window
    window?.isUserInteractionEnabled = false

    /*
     타이머가 동작하기 전에는 보여줘서는 안되기 때문에
     loadingView를 숨긴다.
     */
    loadingView?.isHidden = true

    startTimer()
}


func dismiss() {
    hide()
    stopTimer()
    loadingView?.removeFromSuperview()
    loadingView = nil
}

private func hide() {
    /*
     touch 활성
     */
    let window = (UIApplication.shared.connectedScenes.first?.delegate as? SceneDelegate)?.window
    window?.isUserInteractionEnabled = true

    self.loadingView?.isHidden = true
}


private func startTimer() {
    timer = Timer.scheduledTimer(withTimeInterval: timeRemaining, repeats: true) { [weak self] _ in
        guard let self = self else { return }

        self.timeRemaining -= 0.8

        /*
         0.8초가 지나면 호출
         */
        if self.timeRemaining == 0 {
            /*
             loadingView zIndex 최고 레벨 부여
             */
            self.loadingView?.layer.zPosition = CGFloat(Float.greatestFiniteMagnitude)
            self.loadingView?.isHidden = false
        }

    }
}



private func stopTimer() {
    timer?.invalidate()
    timer = nil
}

}

- 설명
> LoadingView는 Lottie-ios를 사용해서 표현했다. 내가 어디서 본지는 기억이 안나지만 사용자가 화면에서 집중력을 잃는 시간이 0.8초라고 들은적이 있다. 나는 이 근거로 화면에 LoadingView를 표시(show)할때 0.8초 전에는 LoadingView를 표시하지 않고 0.8초가 지나면 LoadingView를 표시하도록 로직을 작성해 봤다.
또한 어떤 작업이 진행될때 사용자가 추가 동작을 하면 못하도록 화면의 Touch또한 막아줬다.(이 화면터치는 0.8초와 상관없이 dismiss가 호출될때까지 이루어 진다.)
그리고 어떤 특정 작업(ex) Network)이 완료되면 LoadingView를 화면에서 지운도 그리고 터치도 다시 활성화 한다.(dismiss) 이번 예제에서는 Network 상황은 구현하지 않았고 대신에 timer를 통해 동작이 어떻게 이뤄지는지 구현했다.
[자세한 내용은 주석 참고]


### CommonRetry
* 사용
![](https://velog.velcdn.com/images/will_d/post/fa959bf3-5e6d-4af7-a28d-90a8810f72ed/image.png)
![업로드중..](blob:https://velog.io/ab8341d8-52ff-4ba0-b0f3-a55a063d41b6)
- 구현
#### BaseViewController
![](https://velog.velcdn.com/images/will_d/post/d98fb64a-052f-412b-8464-d8bd4f2924c6/image.png)
#### DetailViewController

class DetailViewController : BaseViewController { let disposeBag = DisposeBag()

let commonRetry = UILabel().then {
    $0.text = "CommonRetry"
}




var loadingView : CommonLoadingView? = nil
var timeRemaining = 2.0
var timer : Timer? = nil


override init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: Bundle?) {
    super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
    layout()
    bind()
}

required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}

... /* BaseViewController retry 함수 오버라이드 */ override func retry() { super.retry() print("HELLO RETRY") } ... }

#### CommonRetryView

class CommonRetryView : UIView { static let EXIST = 1

let disposeBag = DisposeBag()

let titleLabel = UILabel().then {
    $0.numberOfLines = 0
}

let retryButton = UILabel().then {
    $0.textColor = .systemRed
    $0.numberOfLines = 0
}

override var intrinsicContentSize: CGSize {
    let titleSize = titleLabel.intrinsicContentSize
    let buttonSize = retryButton.intrinsicContentSize
    let width = min(titleSize.width, buttonSize.width)
    let height = titleSize.height + 16 + buttonSize.height
    return CGSize(width: width, height: height)
}


override init(frame: CGRect) {
    super.init(frame: frame)
    layout()
    bind()
}

required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}

func show() {
    let topMostViewController = (UIApplication.shared.connectedScenes.first?.delegate as? SceneDelegate)?.window?.rootViewController?.topMostViewController
    let alreadyAdded = topMostViewController?.view.subviews.contains(where: { $0.tag == CommonRetryView.EXIST }) ?? false
    guard !alreadyAdded else { return }

    topMostViewController?.view.addSubview(self)
    self.snp.makeConstraints {
        $0.center.equalToSuperview()
    }
}

func bind() {
    retryButton.rx.tapGesture()
        .when(.recognized)
        .bind(onNext : { [weak self] _ in
            let topMostViewController = (UIApplication.shared.connectedScenes.first?.delegate as? SceneDelegate)?.window?.rootViewController?.depthViewController
            let baseViewController = topMostViewController as? BaseViewController

            /*
             BaseViewController에서 Override한 retry함수 호출
             */
            baseViewController?.retry()

            self?.removeFromSuperview()
        })
        .disposed(by: disposeBag)
}

private func configure(
    _ title : String,
    _ buttonText : String
) {
    titleLabel.text = title
    retryButton.text = buttonText


    /*
     tag 설정
     */
    self.tag = CommonRetryView.EXIST

    /*
     frame 설정
     */
    self.frame = CGRect(origin: .zero, size: intrinsicContentSize)
}


func layout() {
    [
        titleLabel,
        retryButton
    ].forEach {
        addSubview($0)
    }

    titleLabel.snp.makeConstraints {
        $0.top.equalToSuperview()
        $0.centerX.equalToSuperview()
    }

    retryButton.snp.makeConstraints {
        $0.top.equalTo(titleLabel.snp.bottom).offset(16)
        $0.centerX.equalTo(titleLabel)
    }

}

class Builder {
    private var title : String    = ""
    private var retryStr : String = ""

    func setTitle(_ title : String) -> Self {
        self.title = title
        return self
    }

    func setRetryStr(_ retryStr : String) -> Self {
        self.retryStr = retryStr
        return self
    }

    func build() -> CommonRetryView {
        CommonRetryView().then {
            $0.configure(
                title,
                retryStr
            )
        }
    }
}   

}

* 설명
> CommonRetryView에서 재시도 버튼을 누르는 코드를 보면 현재 화면에 보이는 가장 자녀 ViewController를 호출한다. 이 ViewController는 BaseViewController를 상속 받은 ViewController일 것이다. 왜냐 하면 내가 그렇게 설계를 했으니까! 그리고 이 ViewController의 retry를 실행한다. 즉 retry 함수를 override를 하여 각 화면에 맞는 retry 로직을 작성하면 된다. 이렇게 하면 재시도에 대한 원하는 동작을 구현 할 수 있다!!



### 마무리
위와 같이 개발했을때 디자인의 일관성을 구현했는가? 구현했다고 할 수 있다. 이유는 내가 만약 Loading을 표현해야 되고 Modal을 표현 한다고 하면 위의 Component들을 사용할것이기 때문이다. 그리고 이 Component들은 각자의 일관된 설계를 가지고 있기때문에 이렇게 해서 나는 일관된 UI/UX를 구현했다. 한단계 더 나아가 나는 Builder에 속성을 추가만 하면 새롭게 속성을 설정할 수 있도록 확장성 있는코드도 작성해 봤다. [전체코드](https://github.com/learnGrowD/CommonComponentCollection)

네이티브 개발자는 최전선에서 사용자와 상호작용 하는 개발자이다. 
개발자로서 여러 덕목도 있겠지만 좋은 UI/UX를 어떻게 사용자에게 전달해야 되는가 또한 매우 중요한 덕목이겠다. 그런 고민이 있기에 더 좋은 개발이 나올것이라고 믿는다. 앞으로도 나는 사용자에게 좋은 UI/UX를 제공하기 위해서는 어떻게 해야 되는가에대해서 고민하고 개발적으로 풀어나가는 노력을 열심히 할것이다.

나의 업무 중 하나는 주어진 디자인에 대해서 구현을 해야 되는 업무가 있다. 보통 나는 피그마의 작업물을 받아 업무를 하는데 피그마를 전반적으로 살펴봤을때 한가지 문제에 직면했다. 일관된 체계가 없었다. 나는 이 부분에 대해 디자이너분을 설득해야 됐다. 왜 일관된 체계가 필요한가?

고민

왜 앱을 구성하는 요소들의 일관성 왜 중요한가 그리고 왜 이것이 체계화가 되어야 하는가 나는 이 고민을 집중적으로 했다. 이 생각 저생각 해보고 내가 내린 결론의 답은 UX에 있다. 사용자의 핸드폰에는 무수히 많은 앱들이 존재한다. 그리고 앱은 모두 다른 형태의 모습을 갖추고 있다. 사용자가 그 앱을 사용한다는것은 그 앱의 성격에 따라 달라질 것이다 즉 UX가 달라 질 수 있다는 말이다. 그렇다면 사용자에게 우리의 앱의 사용방식에 대해 직관적으로 전달을 해야 되는데 어떻게 잘 전달 할 수 있을까?

결론

지속적이고 일관된 사용방식을 사용자에게 학습을 시키는것이 더 나은 UX와 사용방식을 결정한다. 즉 사용자가 충분히 학습을 할 수 있도록 일관된 UI/UX를 제공해야 된다. 그럼으로 우리는 디자인과 개발을 할때 일관성을 중요하게 생각해야 되고 설계를 해야 되는것이다. 나는 이 논리를 근거로 디자이너분과 대화를 했고 일관된 체계를 잡아갔다. 다음 글에서는 사용자와 상호작용을 하는 대표적인 Component를 기준으로 일관된 디자인을 개발적으로 어떻게 구현했는지에 대해서 작성하도록 하겠다.

사용자와 상호작용을 하는 대표적인 Component 소개

• Modal
• BottomModal
• Toast
• LoadingView
• RetryView

오늘은 앱을 개발할때 자주 사용하는 NavigationBar에 대해서 정리하는 시간을 갖도록 하겠다.

문제

1. NavigationBar Title은 어떻게 처리 할 것인가?
2. NavigationBar의 속성과 Right, Left에 아이콘 배치는 어떻게 할 것 인가.
   • Icon의 Right, Left 여백은 어떻게 할 것인가
   • Icon이 여러개라면 사이의 여백은 어떻게 할 것인가
   • Icon을 탭했을때 이벤트는 어떻게 처리 할 것인가

해결

1. NavigationBar Title 설정

• BaseViewController

• MainViewController

• DetailViewController

BaseViewController는 생명주기 및 ViewController의 속성을 공통으로 관리하는 기반이 되는 ViewController 이다. 이 BaseViewController를 상속 받은 각각의 ViewController에서 자신이 가져야 할 Navigation Title에 대해서 override하여 navTitle을 설정한다.

2. NavigationBar의 속성과 Right, Left에 아이콘 배치는 어떻게 할 것 인가.

• NavigationBar 초기 설정

  import Foundation
  import UIKit
  import RxSwift
  import RxCocoa
  
  
  

class NavigationManager { ...

static func initNavigation(
    _ backImgName : String      = "back",
    _ backgroundColor : UIColor = .white,
    _ itemColor : UIColor       = .black,
    _ fontColor : UIColor       = .black,
    _ fontName : String         = "Helvetica Neue",
    _ fontSize : CGFloat        = 16
) {

    /*
     iOS 애플리케이션 전체에서 UINavigationBar 객체의 속성을
     설정 할 수 있는 인스턴스
     */
    let appearance = UINavigationBar.appearance()

    /*
     UINavigationBar 하단에 불투명한 그림자 표시에 관한 속성
     */
    appearance.shadowImage = UIImage()

    /*
     뒤로가기 이미지에 대한 속성
     */
    appearance.backIndicatorImage = UIImage(named: "back")
    appearance.backIndicatorTransitionMaskImage = UIImage(named: "back")

    /*
     NavigationBar 투명도에 대한 속성
     */
    appearance.isTranslucent = true

    /*
     탭바의 배경화면을 설정하는 속성
     */
    appearance.barTintColor = backgroundColor

    /*
     NavigationBar 탭바의 아이템 색깔을 설정하는 속성
     */
    appearance.tintColor = itemColor

    /*
     title font를 지정
     */
    appearance.titleTextAttributes = [
        NSAttributedString.Key.foregroundColor : fontColor,
        NSAttributedString.Key.font : UIFont(name: fontName, size: fontSize)!
    ]
}
...

}

![](https://velog.velcdn.com/images/will_d/post/89516349-3997-416b-a93d-61b17df94a42/image.png)

> NavigationManager라는 NavigationBar을 관리하는 class를 하나 만들었다 이 중 initNavigation 이라는 static 함수는 NavigationBar Appearance를 통해서 Navigation Bar의 Background Color나 BackButtonImage와 같은 초기 설정을 담당하는 함수이다. 코드는 위와 같다.

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool

이 함수는 앱 초기에 호출되는 application 함수에서 호출 한다.
이 후에 변경하고 싶으면 initNavigation 함수만 관리하면 된다.

- Icon 배치와 버튼 탭 처리

class NavigationManager { var disposeBag = DisposeBag()

...
![](https://velog.velcdn.com/images/will_d/post/01df1f3d-bda4-442a-83c6-4d0b9d279a7f/image.png)

func setItem(
    itemName : String,
    itemSize : Int = 24,
    padding : CGFloat = 0,
    _ tap : @escaping (UIView) -> Void
) -> [UIBarButtonItem] {
    let fixedSpace = UIBarButtonItem(barButtonSystemItem: .fixedSpace, target: nil, action: nil)
    /*
     iOS에서 기본 Right, Left 여백 16
     */
    fixedSpace.width = padding

    let view = UIImageView().then {
        /*
         Icon 사이즈 및 Icon Img 설정
         */
        $0.image = UIImage(named: itemName)
        $0.snp.makeConstraints {
            $0.width.height.equalTo(itemSize)
        }
    }

    /*
     버튼 탭
     NavigationManager을 ViewController의 멤버로 생성한다.
     멤버로 생성하여 ButtonTap의 Observer를 ViewController와 생명주기와 일치 시킨다.
     */
    view.rx.tapGesture()
        .when(.recognized)
        .bind(onNext : { _ in
            tap(view)
        })
        .disposed(by: disposeBag)

    return [fixedSpace, UIBarButtonItem(customView: view)]
}

func setItems(
    itemNames : [String],
    itemSize : Int = 24,
    ltPadding : CGFloat = 0,
    betweenPadding : CGFloat = 0,
    _ tap : @escaping (Int) -> Void
) -> [UIBarButtonItem] {
    if itemNames.count > 1 {
        let fixedSpace = UIBarButtonItem(barButtonSystemItem: .fixedSpace, target: nil, action: nil)
        /*
         iOS에서 기본 Right, Left 여백 16
         iOS에서 기본 Icon 사이의 여백 8
         */
        fixedSpace.width = ltPadding
        var result = itemNames.enumerated().map { index, itemName in
            let view = UIImageView().then {
                /*
                 Icon 사이즈 및 Icon Img 설정
                 */
                $0.image = UIImage(named: itemName)
                $0.snp.makeConstraints {
                    $0.width.height.equalTo(itemSize)
                }
            }

            /*
             버튼 탭
             NavigationManager을 ViewController의 멤버로 생성한다.
             멤버로 생성하여 ButtonTap의 Observer를 ViewController와 생명주기와 일치 시킨다.
             */
            view.rx.tapGesture()
                .when(.recognized)
                .bind(onNext : { _ in
                    /*
                     index를 delegate에 전달한다
                     사용을 한다면 Index를 통해서 어떠한 icon을 선택했는지
                     판단이 가능하다.
                     */
                    tap(index)
                })
                .disposed(by: disposeBag)

            return UIBarButtonItem(customView: view)
        }


        /*
         Icon 사이의 여백을 결정하는 로직
         */
        for i in 0..<result.count + (result.count - 1) {
            if i % 2 == 1 {
                let betweenSpace = UIBarButtonItem(barButtonSystemItem: .fixedSpace, target: nil, action: nil)
                betweenSpace.width = betweenPadding - 8
                result.insert(betweenSpace, at: i)
            }
        }

        result.insert(fixedSpace, at: 0)
        return result
    } else {
        return []
    }
}

}

> Icon 배치와 버튼 탭 처리는 setItem, setItems 함수를 통해서 구현했다. 이 setItem, setItems 함수는
IconSize, IconTap, Icon 오른쪽, 왼쪽 여백, Icon과 Icon 사이의 여백의 값을 조정하는 로직이 존재한다.
실제 사용을 할때는 NavigationItem의 오른쪽에 배치할 것인지 왼쪽에 배치할것인지만 결정해주면 된다. 실제 사용 코드는 아래와 같다. [setItem 사용 방법도 아래와 비슷하다.]![](https://velog.velcdn.com/images/will_d/post/0161d76b-34cd-48a8-b8d1-3ce8049dbf19/image.png)



### 결과
![](https://velog.velcdn.com/images/will_d/post/ebf1ccbc-2471-4639-bbbe-01140ad88c77/image.png)


![](https://velog.velcdn.com/images/will_d/post/070158ff-3985-4521-9952-665224f599a6/image.png)




오늘은 이렇게 iOS에서 자주 사용하는 NavigationBar에 대해서 정리를 해봤다.

위와 같은 방법으로 정리를 해 놓으면 나중에 유지 보수 할떄 좀더 수월 하게 할 수 있을것 같아 정리해봤다.

문제상황

1. View의 배치 및 상태를 결정하는 시점에서 나오는 Snapshot의 문제 (AutoLayout을 통해 배치한다고 하면 더더욱 중요하다.)

2. 어떻게 CustomView의 크기를 동적으로 정할 것 인가.

해결

1. 첫번째 문제

   View의 Layout의 frame이 정해지지 않은 상태에서 View를 캡쳐해서 Marker의 imageIcon에 넣어주면 에러가 난다. 에러 코드는 아래와 같은데 정확한 이유는 알려주지 않는다. 여러 시도를 해보고 추론한 결과 View의 frame이 정해지지 않았으니 제대로 캡쳐를 못한것이다. 나는 이러한 추론으로 frame을 설정해 봤다. 이렇게 하니까 View가 정상적으로 캡쳐가 되어 Marker에 이미지로 잘 표현이 되었다. 그러나 frame으로 정적으로 배치하는것이 아닌 AutoLayout을 통해서 동작으로 배치 할려고 하니까 제대로 캡쳐가 안되고 이상한 Image가 캡쳐 되었다. [첫번째는 비정상, 두번째 정상] 왜 이러는 것일까? 이유는 간단하다 AutoLayout을 통해서 View의 배치과 완료되는 시점과 캡쳐를하는 시점이 맞지 않기 때문이다. iOS의 UIView는 layoutIfNeeded라는 함수를 지원하는데 이 함수의 기능은 View와 그 자식 Vie의 레이아웃을 갱신한다. 나는 이 함수를 통해서 캡쳐를 하는 시점 전에 레이아웃을 갱신하게 했다. 그런다음에 캡쳐를 하니 정상적으로 Marker에 이미지를 표시 할 수 있었다. 해결한 코드는 아래와 같다.

2. 두번째 문제

   매물 수나 정보에 관련한 마커의 글자수는 예측 할 수 없다 즉 표현한다고 하면 동적으로 표현하는게 적합한 표현이다. 마커로 표현한다고 하면 어떻게 표현하면 좋을까. 간단하다 label의 intrinsicContentSize을 통해 동적으로 View의 크기 동적으로 결정한 다음 AutoLayout을 업데이트 해서 캡쳐하면 된다. 해결한 코드는 아래와 같다.

그리고 하나더

마커의 데이터 객체는 MarkerProtocol을 상속 받는다. 그리고 만약 마커를 통해서 발생하는 이벤트(MarkerTap -> Page 전환)는 id를 통해서 분기를 한다고 하면 굳이 아래의 3번째 사진처럼 할 필요 없이 2번째 사진처럼 다형성으로 처리한다. 더욱 깔끔한 코드를 작성해봤다.

또한 CustomMarkerView는 그저 껍데기에 불과하다 매번 객체를 새로 생성하는것 보다 그냥 한번 생성해서 필요에 의해서 이 껍데기에 이미지를 넣어져서 캡쳐하는 방식으로 코드를 수정해 봤다. 코드는 아래와 같다. [첫번째 사진 : 새로 생성, 두번째, 세번째 사진 : 만들고 재사용]

최종 마무리

CusomMarkerView를 만들고 이미지를 shapshot하여 Naver Map에서 CustomMarker를 표현하는 방법에 대해서 알아봤다. 여러 시도가 있었고 여러 문제가 발생했다. 그리고 해결을 하는 과정에서 다시금 생명주기의 중요성에 대해서 깨닫는 시간을 갖게 되었다.

개발자는 항상 문제를 직면했을때 이 문제는 무엇인지에 대해 정의 할 수 있는 사람이여야 한다고 생각한다. 정의를 해야 어떻게 문제를 해결할지에대해서 방향성을 잡을 수 있기때문이다. iOS Naver Map CustomMaker 시리즈 글을 작성하면서 사고의 과정을 중심으로 글을 작성해 봤다. 중요한 지점이고 앞으로도 이러한 능력을 키우기 위해 부단히 노력할것이다. 해결 전체코드

긴글 읽어주셔서 감사합니다.