신규 시스템 구축하기 (feat. MSA, 백오피스)

2023년, 팀 내부에서는 `팩토리` 라고 부르는 신규 시스템을 구축했습니다.

개발자로의 경력이 많지는 않지만, 가장 경험이 좋았던 프로젝트였고, 처음으로 프로젝트 다운(?) 프로젝트를 진행했던 것 같습니다.

 

작년 상반기 지독한 개발 번아웃을 겪었기에, 프로젝트 초기에는 매우 소극적으로 임했던 것 같습니다.

하지만 프로젝트를 진행하며 어느 정도 번아웃을 회복하고, 점차 적극적으로 참여하며 일정은 빠듯했지만 굉장히 재밌고 즐겁게 했었는데요, 관련하여 간단히 정리해 보고자 합니다.

 

신규 시스템 배경

금액권 - 스타벅스 (20,000원 권)

금액권이라고 불리는 기프티콘은, 정해진 금액 내에서 여러 번 사용이 가능한 상품입니다.

위 스타벅스를 예로 들자면 20,000원 한도 내에서 자유롭게 사용이 가능한 스타벅스 금액권 상품입니다.

 

하지만 현재 금액권 관련해서는 외부 시스템에 의존되어 있기에 여러 제약이 존재합니다.

따라서 외부와의 의존성을 제거하고, 팀 내부 시스템의 통합을 위한 기반 확보, 쿠폰 발급 개선, 사업 확장을 고려한 설계 등의 배경을 가지고 신규 시스템을 구축하게 되었습니다.

 

기존 시스템 상황

기존에 팀에서 운영중인 시스템은, 오래전 구축되고 난 후 개편이 이루어지지 않은 상태였기에 굉장히 거대한 프로젝트가 된 상태입니다.

• UI의 경우 XPlatform 프레임워크를 사용하고 있고, 관련 자료가 많이 존재하지 않습니다.
• 1번과 유사하게, 프레임워크 개발에 대한 문서 등이 내부적으로 따로 존재하지 않아 개발 인원에 따라 스타일이 제각각입니다.
• UI 개발을 위한 IDE 에서는 자동 완성, compile 에러 체크 불가능 등으로 인해 개발 생산성을 낮춥니다.
• UI 개발은 윈도우 환경에서만 가능하기 때문에 VDI 를 접속해야 하는 번거로움이 존재합니다.
• 내부 로직은 분기 처리를 위한 각종 if 문이 굉장히 많이 존재하여 비즈니스 로직을 파악하기가 어렵습니다.
• 수천~수만 라인의 java 파일이 꽤나 많이 존재합니다.

 

신규 시스템 구축

위와 같은 문제들이 존재하기에 신규 시스템은 완전 밑바닥부터 진행했습니다.

물론 초기 설계, 서버 구축 등을 직접 진행하지는 않았지만 옆에서 이것저것 보면서 많이 배울 수 있었습니다.

 

신규 시스템은 상품, 발급, 쿠폰, 승인 등 각각의 서비스를 분리하여 마이크로 서비스로 구축하게 되었는데, 개발을 진행하면서 굉장히 많은 어려움을 겪었지만, 결과적으로는 많은 것을 경험할 수 있었습니다. (다신 못해)

• 각 서비스의 호출에서 예외가 발생하면 어떻게 처리해야 할지,
• 발급 처리 후 API 서버에서 실패가 발생하면 재처리는 어떻게 처리해야 할지,
• 분산 서비스에서 데이터 추적은 어떻게 해야 할지,
• Spring Cloud 생태계의 초기 학습 비용,
• 디버깅의 어려움 등등...

응답 관련된 커스텀 클래스를 만들고 관리하며, 재처리의 중복을 제거하고자 요청 ID, 글로벌 트랜잭션 ID 등 유니크한 값을 통해 멱등성을 보장하도록 구현하였습니다.

 

또한 Spring Cloud 생태계의 Eureka, Admin, Config, API Gateway 등등 각 서비스를 처음 접하다 보니 어떠한 식으로 처리되는지도 파악하기가 힘들었는데요, 이러한 이해도를 조금 더 높이기 위해 간단하게 개인적으로 만들어보고 있습니다.

• https://github.com/factory-msa/readme

 

백오피스 시스템 구축

백오피스(어드민) 시스템을 처음으로 구축해 봤는데, 개인적으로 회원의 인증/인가 부분을 구현할 때 가장 재밌었습니다.

 

인증/인가 부분은 Spring Security 프레임워크를 주력으로 사용했는데요, 스프링 시큐리티를 처음 접해본 건 대략 3년 전이었습니다.

당시에는 스프링 시큐리티의 굉장히 복잡하고 추상적인 내부 구조에 의해 높은 벽을 체감을 했었는데요..

이번에 다시 구현하면서 내부 구조를 조금 더 깊게 공부하다 보니, 확실히 전보다는 이해도가 꽤나 높아진 것 같아서 신기했었습니다.

 

백오피스 회원 인증/인가 처리

백오피스 시스템에서 회원 관련하여 인증 및 인가 부분을 구현하였는데요, 이와 관련해서 꽤나 많은(?) 이슈들을 접했습니다. 

회원 관련된 기능을 개발하는 것이 처음이어서 초기에는 보안 측면에서도 놓치는 부분이 꽤 많았던 것 같습니다.

 

중복 로그인 처리 관련해서, 로그인은 기본적으로 인증 시 커스텀한 토큰을 만들어서 사용하고 있었습니다.

유저ID 및 토큰을 각각 key/value로 관리하여 중복 로그인 처리를 진행했고, 먼저 로그인이 되어 있는 상황에서 뒤늦게 로그인을 한 유저는 기존 로그인되어 있는 유저의 계정을 강제로 종료할 수 있게끔 처리하여 (물론 토큰 만료시간은 존재합니다만..) 무한정 로그인이 안되는 현상을 예방하고자 했습니다.

 

또한 기본적으로 로그인 횟수에 제한(보안 진단)을 두어야 했기에 로그인 실패 횟수를 컬럼으로 관리하고, 최대 횟수를 초과하면 계정이 잠기게 되는 프로세스입니다.

이는 관리자가 직접 계정을 활성화를 해주거나, 로그인에 성공하게 되면 SuccessHandler 에서 횟수를 초기화를 진행하고요,

 

인증(토큰)의 만료 시간은 최초 생성 시점으로부터 30분으로 설정했으나, 이러한 경우 30분이 지나면 토큰이 삭제되기 때문에 강제로 로그아웃이 되고, 30분마다 계속 로그인해야 하는 번거로움이 발생하여 사용자가 요청한 시간을 기준으로 만료 시간을 30분으로 갱신하도록 합니다. (HttpSession 이 사용하는 방식)

 

대략적으로 인증 처리는 아래의 흐름으로 진행이 됩니다.

Login Process

Spring Security를 적용하여 인증/인가를 구현하여 AuthenticationProvider 구현체를 직접 Custom 하여 작성할 때, authenticate() 메서드가 두 번 호출이 되는 이슈가 존재했는데요, 이로 인해 로그인에 실패하면 위에서 언급했던 로그인 실패 횟수가 중복으로 증가하는 문제가 발생했었습니다.

 

Custom AuthenticationProvider

대략적으로 위의 authenticate() 메서드가 두 번 호출이 되어 카운트가 중복으로 증가합니다.

 

ProviderManager

위는 실제 인증 처리를 진행하는 ProviderManager 클래스의 authenticate() 메서드입니다.

 

위의 parentResult 변수로 인해 최초 인증에 실패하더라도 다시 parent의 authenticate() 메서드를 호출하게 되어 중복 처리가 되는 문제가 발생합니다.

(아마 재처리를 진행할 수 있게끔 만든게 아닌가 싶은데 자세히는 모르겠습니다.)

 

spring-security github에서 아래 설정으로 문제를 해결할 수 있다고 하는 것 같은데요, 저는 처리가 되지는 않더군요..

 

 

따라서 최초 인증 처리가 진행되면, authenticate() 메서드에 존재하는 파라미터인 Authentication 객체에 정보가 남고, 이를 통해 인증이 실패했는지 아닌지에 대한 검증이 가능했기에 아래와 같이 구현을 했습니다.

 

근본적인 해결책은 아니기에 조금 찝찝하긴 한데요, 위 이슈를 조금 더 파악해 보고 결론이 나면 다시 공유를 드리겠습니다. 😅

 

추가적으로, Spring Security 에서는 "ROLE_" 를 prefix로 권한을 관리 합니다.

그렇기에 내부적으로 권한 관리를 위해서도 "ROLE_" 을 prefix로 선언하고, 네이밍을 지정해야 하는데요, 권한 관리 테이블의 권한명이 length 가 제한적이기 때문에 "ROLE_" prefix를 선언하면 데이터베이스의 길이 제한 문제가 발생하여 prefix를 제거했습니다.

https://stackoverflow.com/questions/38134121/how-do-i-remove-the-role-prefix-from-spring-security-with-javaconfig

위의 방식대로 설정한 권한은 @RolesAllowed 어노테이션을 사용하여 API 마다 권한 체크를 진행할 수 있습니다.

(Spring Security의 "ROLE_" prefix 를 제거하였기 때문에, 권한 설정을 자체적으로 관리하여 사용할 수 있습니다.)

 

 

스프링 시큐리티에서 인증된 유저를 사용할 때, @AuthenticationPrincipal 어노테이션을 통해 SecurityContextHolder에 저장되어 있는 인증된 유저를 가져올 수 있습니다.

 

실제 SecurityContextHolder에 인증된 유저를 저장할 때 사용되는 객체는 UsernamePasswordAuthenticationToken 클래스로, 해당 클래스에서는 principal, credentials, authorities를 선언할 수 있습니다.

(principal = username, credentials = password 정도로 생각하시면 될 듯 합니다.)

 

하지만, @AuthenticationPrincipal 어노테이션을 사용하여 인증된 유저를 가져올 때는 principal만 가져오기 때문에 권한(authorities) 체계가 달라질 수 있습니다.

 

@AuthenticationPrincipal 어노테이션을 사용했을 때, 값을 가져오는 클래스는 AuthenticationPrincipalArgumentResolver 입니다.

 

@AuthenticationPrincipal 어노테이션은 AuthenticationPrincipalArgumentResolver 클래스의 resolveArgument() 메서드에서 SecurityContextHolder 에 저장되어 있는 인증된 유저를 가져오게 됩니다.

AuthenticationPrincipalArgumentResolver

 

따라서 이 부분도 커스텀을 해 주거나, principal 내부에도 authorities 필드가 존재하기 때문에 같이 설정해 주어야 합니다.

참고 링크

• https://stackoverflow.com/questions/75395651/spring-security-has-authorities-on-authentication-and-on-the-principal-why-and
• https://stackoverflow.com/questions/63772495/duplicate-authorities-in-spring-security-authentication

 

프론트 엔드

화면이 많지는 않지만, 그중 개발했던 화면은 더 적지만... 사실 가장 애먹었던(?) 작업이 프론트 개발이었던 것 같습니다.

특히나 프론트 개발을 해 본 경험이 과거에 거의 없었기 때문에 더욱 어려웠던 것 같습니다.

 

기존 동료분이 세팅해 주신 템플릿을 기반으로 조금씩 수정하며 개발을 진행했는데 몇몇 이슈들은 당연히 있었는데요,

• Router 설정
• 부모, 자식 컴포넌트의 데이터 설정 및 전달
• Error는 아니지만 개발자 도구에 Warning으로 나온 문제들
• 이벤트 처리 후 팝업(Dialog) 처리 및 일관성
• 자바스크립트의 비동기 처리로 인해 예상 결과가 다른 코드들 + (Promise/async&await)
• Vue 라이프사이클 및 부모, 자식 간의 초기화 순서 등등

직접 프론트와 백엔드를 같이 개발하다 보니 확실히 어떠한 방식으로 처리가 되는지, 서버에서 어떠한 방식으로 데이터를 넘겨줘야 프론트에서 잘 처리할 수 있을지 등을 고민할 수 있는 좋은 경험이었습니다.

 

보안 처리

서비스에 개인정보(회원)가 추가되면서 보안적인 측면을 고려해야 했습니다.

하지만 기존에 개발을 진행하면서 이러한 부분을 챙긴 적은 크게 없었기에, 이는 고스란히 보안 진단 테스트에서 다 검열이 되었습니다..

 

조금만 생각해 보면 당연한 것들인데, 이러한 케이스를 챙기지 못한 부분이 부끄러웠지만 이번 기회에 확실히 알게 되어서 오히려 다행이라는 생각이 들었습니다. (다음에 동일한 실수를 반복하지 않으면 되니까요 😅😅)

• 로그인 실패 케이스에서 실패 유형에 따라 다른 오류 메시지를 출력하기에 계정이 존재하는지 여부에 대한 유추 가능
• 개인 정보의 마스킹 처리
• 로그인 시도 횟수가 n회 이상일 경우 계정 잠금 처리 (무제한 시도 예방하기)
• 서버에서 권한 처리가 되어있지 않는 경우, 클라이언트에서 권한을 조작하여 계정 권한 상승 가능성
• Vue 2 에서 제공해주는 보안 처리는 링크에 있습니다.

위의 케이스도 개발자가 직접 정할 수 있는 케이스도 있지만, 기획자와 함께 정해야 하는 부분이 있기 때문에 커뮤니케이션이 더더욱 중요한 것 같습니다.

 

QA 처리

QA 처리는 기본적으로 개발이 완료된 후 개발 서버에서 QA 담당자가 작성된 테스트 시나리오를 기반으로 테스트를 진행합니다.

QA는 담당자가 진행하지만 핵심은 "개발자가 컨트롤이 가능해야 한다." 인 것 같습니다.

 

현재 QA는 외주 분들이 진행하시기 때문에 정말 사소한 것도 놓치지 않고 다 확인을 하시는데요, '이런 것까지 필요한가?' 싶을 정도로 정말 잘 찾아내시기 때문에 일정 범위 내에서 적당한 조율이 필요한 것 같습니다.

 

특히 QA를 대비하여 개발을 진행할 때, 어느정도 예상이 가능한 이슈지만 중요도가 높지 않은 기능은 이를 QA에서 발견되더라도 이를 고려하고 일부 미루는 방식도 괜찮은 것 같습니다.

 

정리하며

백오피스 시스템을 구축할 땐 일정이 꽤나 촉박해서 야근(?)을 꽤나 자주 했는데, 개인적으로는 너무 재밌었습니다.

짧은 개발 경험 동안 겪었던 가장 경험이 좋은(?) 프로젝트였고, 같이 진행했던 동료들에게도 굉장히 많이 배울 수 있었습니다.

 

사실, 해당 프로젝트를 진행하기 전에는 협업할 기회도 거의 없었고 너무나 따분한 환경에서 일을 했었다면, 이번 프로젝트를 통해 협업하는 과정에서 함께 성장하는 경험이 굉장히 중요한 요소이고, 일의 재미에도 많은 영향을 미치는 것을 알게 되었습니다.

 

특히 신규 서비스를 작게나마 마이크로 서비스로 구축함으로 다양한 경험을 할 수 있었지만, (개인적으로) 조금 과한 설계가 아니었을까 생각합니다.

다음에 신규 프로젝트를 구축할 기회가 또 생긴다면, 특히나 트레이드오프를 더욱 신경 써야 할 것 같습니다.

 

참고문서

• 지극히 평범한.팩토리 개발 이야기