리워드 발급 구조 개선

배경

리워드 시스템을 고도화하며 발급 정책을 추가하는 작업이 필요하게 되었다.

분석하다 보니 기존 시스템은 발급 구조에 대해 여러가지 잠재적인 이슈가 있는 것으로 보여 보다 안전한 구조로 개선하기로 했다.

 

 

현황 분석

아래 구조는 실제 구조는 아니고 생략할 부분은 생략하고 일부는 변형해서 비슷한 예시를 만들어보았다.

리워드 발급 구조

기존의 리워드 발급 구조는 위와 같다.

1. 클라이언트에서 가지고 있는 정책 코드를 기준으로 서버에서 정책에 대한 세부 내용을 요청한다.

2. 1에서 응답받은 리워드 수량만큼 리워드 발급 요청한다.

 

예를 들면 특정 컨텐츠에 댓글을 달면 리워드를 발급하는 기능이 있다고 가정해보자.

이 경우 클라이언트 영역에서는 댓글 등록 API를 호출하여 성공 응답을 받고 난 뒤, 댓글 등록에 대한 정책 코드 "0001"로 리워드 발급 정책을 조회한다.

이에 대한 응답으로 10개라는 발급 갯수를 받았다면, 10개의 리워드를 발급해달라는 리워드 발급 API 요청을 보내어 처리하게된다.

 

위와 같은 리워드 발급 구조에는 아래와 같은 여러 가지 취약점이 내포되었다고 판단되었다.

 

기존 구조의 취약점

1. 정책 코드를 클라이언트에서 관리

클라이언트, 서버의 역할에 대한 정의는 조직 내에서 정한 룰이 있다면 따르는 것이 맞겠지만, 이와 같은 경우에 대한 명확한 룰이 존재하지 않았다.

따라서 클라이언트는 화면 구성, 서버에서는 데이터 및 비즈니스 로직 처리라는 일반적으로 통용되는 원칙에 따라서 클라이언트에서 관리되지 않아도 될 정책 코드가 클라이언트에서 관리되는 취약점이 존재하였다.

실제로 어드민 페이지에 정책을 추가하게되면 프론트엔드 영역에서 관리되는 정책 코드도 하나가 추가되어야하는 구조였다. (유지보수에 유연하지 못한 구조)

 

2. 하나의 비즈니스 로직에 불필요한 두 번의 통신 발생

여러 가지 발급 트리거에 따라서 항상 위와 같은 두 번의 통신이 발생했다.

네트워크 비용은 굉장히 부하를 많이 잡는다는 점을 고려한다면, 이처럼 구현되어 있는 부분도 하나의 API만으로 구현함으로써 최적화할 수 있을 것이라고 생각했다.

 

3. 요청에 대해서 검증없이 발급

리워드 발급 API는 요청 파라미터의 발급 갯수를 검증하지 않는다.

따라서 정해진 클라이언트가 아닌 다른 엔드포인트에서 리워드 발급 API의 요청에 임의의 숫자를 입력한다면 그만큼 리워드가 발급되는 구조였다. 이 부분은 보안적으로 취약한 부분이기 때문에 꼭 조치를 해야하는 부분이었다.

 

 

조치 사항

1. 두 개의 API를 하나의 API로 통합

우선 두 번 발생하는 API를 하나의 API로 통합하는 것이 최적화 측면에서 더 좋은 방향이라고 생각이 들었다.

그리고 두 개의 API에 파편화되어 있는 비즈니스 로직이 하나의 API안에 캡슐화되어서 구현된다는 점이 더 안정적이라는 생각이 들었다.

 

2. 정책별 API 구성

하나의 정책에 하나의 API라는 규약을 정했다. (OCP 적용)

예를 들면 특정 컨텐츠에 댓글을 달면 리워드를 발급한다고 가정했을 때, 클라이언트에서는 댓글 등록 API 성공 응답 후 댓글 리워드 발급 API를 호출하게 될 것이다.

리워드 발급 정책이라는 비즈니스 로직은 생각보다 빠르게 변하기 때문에 변화에 유연해야한다는 특징을 가지고 있다. 해당 정책이 사용되지 않는다면 클라이언트에서는 해당 API만 찾아서 제거하면 된다. 반대로 새로운 정책이 추가되면 신규 API를 호출해야한다.

 

3. 검증 로직 추가

요청에 대한 검증없이 리워드가 발급된다는 보안적인 취약점을 개선하기 위해 꼭 작업이 필요한 부분이었다.

그러나 하나의 API 내에 비즈니스 로직이 캡슐화되었기 때문에 이 안에서 추가적인 비즈니스 로직을 추가하는 작업은 보다 간단해졌다.

서비스 레이어의 비즈니스 로직이 시작되는 부분에 검증 로직을 추가하여 유효한 요청의 경우에만 정상적으로 처리되도록 개선했다. (일별 중복 발급 체크 등)

 

 

개선된 구조

개선된 리워드 발급 구조

위와 같이 하나의 API로 리워드가 발급되도록 개선되었으며 아래와 같은 장점을 얻을 수 있었다.

1. 두 번 호출하던 API를 하나로 합쳐서 네트워크 비용 감소

2. 정책별 API를 구성하여 정책별 비즈니스 로직을 서버 사이드로 일원화

3. 리워드 발급에 제약이 없던 보안적 취약점 조치