MSA구조에서의 기획자의 역할

API와 데이터의 이해가 더 중요해졌다.

MSA로 구성한 이커머스 구축이 끝났다.

프로젝트가 끝나고 안정화기간을 걸쳐 운영모드로 접어들었다. 이제 좀 한숨 돌리나 싶지만 이제 100일 정도 된 아가 사이트에 기존 몇년된 사이트의 모든 기능뿐 아니라 더 많이 원하는 판에 말도 많고 탈도 많다.

리뉴얼 구축을 끝내고 느끼는 것은 항상 현업의 요구사항은 예전하던대로 해달라거나 아니면 기존에도 못하던것이 이제는 되겠지하며 재시도하거나 그렇다.

그런데 이번에는 또 하나가 다르다. 시스템을 MSA구조로

 짜다보니 기존과 달리 DB가 분리되어 있어 하나의 서비스를 할 때 여러 DB와 기능조직으로부터 API로 데이터를 주고 받아서 처리해야할 것이 너무나도 많다. 물론 프로덕트가 횡적으로 MSA를 만드느냐 아니면 기능 종적으로 MSA를 구성했느냐에 따라 다르겠지만 현재 종적으로 쪼개놓은 구조에서 이커머스를 만들면서 기획자로서도 느낀 점이 많다.

종적으로 짜여진 MSA가 어떤 의미냐면 이커머스로 치면 상품을 등록하고 저장하고 상품상세를 보여주는 DB와 주문을 처리하고 결제를 생성하여 저장한 DB, 그리고 배송데이터를 처리하기 위한 DB가 모두 다르다는 의미다. 이런 구조에서 우리는 상품에서 주문, 주문에서 배송으로 진행될 때 각 단계에서 필요데이터를 API로 조회해서 불러오고 생성한 데이터를 다음 단계의 MSA로 BATCH처럼 정해진 시간에 진행되는 ETL이나 Message QUEUE방식으로 전달해주도록 구성했다. ETL은 DB간 정해진 데이터를 가공하여 전달하는 방식이고, 메시지큐는 선입선출 방식으로 쌓여있는 데이터를 처리하는 방식을 의미한다. 어플리케이션에서 처리시 API호출을 최소화 하려면 앞단계에서 ETL해올 때 필요정보를 구분하여 미리 앞단계 MSA로부터 복사해서 저장시켜두어야한다.

 앞에서 말한 정방향은 좀 복잡도가 낮은 편이다. 문제는 내가 담당한 클레임의 경우에 많았다. 클레임 처리시에는 복사되서 넘어온 데이터만 볼 뿐 아니라 취소, 반품, 교환 등에서  분산된 각 MSA를 호출하여 현재 데이터 상태를 확인해야할 경우도 많았기 때문이다.

종적 MSA가 기획자에게 요구하는 것

 위의 말을 읽으면서 무슨 말인지 하나도 모르겠다는 생각이 드는 기획자라면 MSA환경에서 기획하라고 할 때 난관을 겪게 된다.  적어도 이 정도에 대한 이해가 없다면 엄청나게 많은 난관에 부딪히기 때문이다.

 과거 모놀리티 환경에서는 기획자는 최초 데이터의 저장 위치에 대해서 전혀 신경쓰지 않았다. 데이터가 어디에 있든 있다고만 하면 기획에서는 그걸로 충분했다. 개발에서 필요한 데이터가 존재하는지만 확인되면 두개의 전혀 다른 테이블에 있어도 DB는 같으니까 데이터 테이블 2개를 조인(join)해서 기획자가 원하는 정보를 얼마든지 만들어줄 수 있었기 때문이었다. 모놀리티 환경에서는 데이터 테이블의 규칙만 정확히 파악하고 기존 데이터를 컨닝해서 얼마든지 수정 개발도 할 수 있었다.

 그런데 이제 개발자들도 각각의 MSA에 대해서 연결고리를 모두 파악하기 어렵다. 그런 이슈는 기획자에게도 넘어온다. 뭔가 만들기 위해 이러저러 조건을 작성해 가면 개발자는 이렇게 말해온다.

 '해당 원데이터가 다른 MSA에 존재하기 때문에 호출해올 수 있는 API를 그 쪽이랑 협의해서 만들어줘야해요'

 그리고 오류가 발생해서 오류신고를 하면 이런 대답도 돌아온다.

 '저희 MSA에서는 제대로 호출했는데 저쪽에서 정상 값을 반환해주지 않아서 처리가 되지 않았어요'등등.

  이 문제를 해결하기 위해서 기획자는 최소 어느 MSA가 어떤 데이터를 보유하고 있는지를 알아야한다. 구현의 문제는 개발에서 주로 책임을 지겠지만 정책의 범주가 문제다. 다른 기능모듈에서 설계한 정책과 상이한 정책은 나중에 서로 연결할 때 문제를 일으킨다. MSA 구조의 개발에서 전체적인 흐름을 봐줄 사람이 필요하듯 기획도 마찬가지다.

 이런 이유로 기획시 기획자간 정책 협의 과정에서도 실제 MSA내 쌓인 데이터에 대한 지식이 필요해진다. 우린 뭐가 필요한지 그리고 어떤 데이터여야만 되고 실시간이어야하는지 시차가 있어도 되는지 등등의 정책적 부분에 UI보다 중요한 것이 굉장히 많아졌다.

 그리고 이런 변화는 UI설계에도 영향을 미친다. UI의 동작순서는 각 MSA의 데이터 호출하는 연산 순서와 동일하기 때문이다. 그리고 복사해온 데이터는 원데이터와 분명 차이가 발생할 수 있다는 것도 인정해야한다. 그니까 현재 시점 기능을 처리할 때 어느 시점의 데이터를 사용할 것인지 정책적 결정이 되어 있어야 한다. 이런 정책들이 개발자도 히스토리를 미리 생성해서 조회 시 특정 시점을 기준으로 할 것인가를 고려할수 있다.

 예외 처리에 대한 기준에 데이터가 없는 것뿐아니라 MSA간 통신장애로 인한 부분도 고려해줘야한다. 외부 솔루션과 API 통신 시에 문제가 발생하는 오류에 대해서 처리방법과 고객 소통 방법을 고민해야한다. 고객은 지금 처음 MSA른 다루는 기획자보다 훨씬 더 뭔 소린지 모를테니까.

 그리고 DBA의 영역일 수 있지만 데이터가 MSA간 ETL이 많기 때문에 상태값이나 공통으로 사용할 코드는 가능한 정제작업없이 그대로 쓸 수 있도록 정의되어야 한다. 중간 정제과정이 들어가야하도록 서로 MSA별 기획자가 다르게 정의해버리면 우리 모두와 고객까지 고통받을 수 있다. 서로 안맞을 때 오류원인찾기가 지독히 어려워지기 때문이다.

  요약해보면 종적 MSA가 기획자에게 요구하는 것은 이렇다.

 어떤 MSA가 어떤 데이터를 가지고 있는지 알아야한다

각 MSA가 동일한 비즈니스에 맞는 정책대로 개발되어 있는지 알아야하고 전체 흐름에서 차이나는 부분이 없는지도 생각해야한다.

MSA간 API호출에 대한 정의와 고객편의를 동시에 기준에 두고 UI순서를 함께 고려해야한다.

오류에 대해 정의할 때 MSA간 호출에 대한 이해도를 갖고 접근해야한다

항목값이나 상태값을 정할 때 MSA간 연결을 고려하여 가능한 통일성 있게 만들어야 한다.

횡적 MSA였다면 어떨까?

내가 말하는 횡적 MSA란 기본 레거시는 모놀리티 형태로 만들고 그리고 그 위에 서비스는 MSA로 각각 프로덕트에 맞게 구분한 것이다. 레거시에 통신해서 데이터를 레거시에 쌓는 것은 동일하되 그 외에는 프로덕트에 맞게 DB구조를 설계한 것을 생각해봤다.

 이렇게 되면 레거시나 프로덕트단에서는 모놀리티기 때문에 각각 기획자는 기존 복잡한 다른 MSA의 데이터단까지 고민하지 않아도 되지 않을까??

 이 생각은  최근에 다시 읽은 '플팻폼 레볼루션'에서 말하듯이 플랫폼의 구조는 자유도가 낮은 안정적 레거시와 자유도가 높은 어플리케이션 구조를 지향해야한다고 했다. 더  쉽게 말하면 레거시에서 모든 쓸만한 종류의 API를 만들어놓고 프로덕트 어플리케이션에서 높은 자유도를 가지고 활용하면 되지 않나 하는 것이다.

 종적 MSA에서는 자유도가 떨어지는 고정된 API를 필요시마다 계속 만들어야하다보니 MSA가 무색할 정도로 의존도가 심해서 기획자도 개발구조에 대해 더 깊이 알지 못하면 기획하기가 힘들 정도다. 구축이 끝나고 운영상태에서는 그나마 낫지만 아예 새로 구축할 때는 더더욱 쉽지 않았다.

 하지만 이렇게 말하는 횡적 MSA를 만드려면 전체가 커버가능한 레거시도 만들어야할테고 서비스 단위로 유사기능을 동일하게 만들어야할테니 AWS와 같은 환경에서 기존 모놀리티에 비해 DB유지 비용이 심각하게 많아질 것이다. 굳이 기획자나 서비스 운영효율성을 높이자고 몇명 오지도 않는 서비스를 그렇게 만들 이유는 없어보인다.

아직 설익은 MSA구조의 서비스기획 역량

 국내에서 MSA로 이커머스 구축한 사례는 많지만 찢어놓는 수준은 천차만별이다. 어떤 경우는 그냥 전시와 백엔드만 찢어놓아 거의 모놀리티에 가까운데도 MSA라고도 한다.

 어제 MSA간 정책 이슈로 시작한 회의가 있었다. 다른 모듈로 2달전에 왔다는 개발자는 그 쪽 기획자 요청에 딴라  APi를 수정했는데 API규격을 바꾼 것이 다른 모듈인 내가 담당하는 MSA의 정책과 맞지 않아  큰 문제가 되었다. 예민하게 날이 서서 서로 이렇게는 못맞춘다 거칠게 싸우는 우리들 사이에서 2달되신 그 분의 불안한 눈빛이 보였다. 미안한데 MSA로 구축해서 많이 지쳐서 예민들할텐데 이해하시라고 말했다. 그 분은  잘게 쪼개놓은 구조뿐 아니라 개발 소스도 참고해보기 어렵고 엄청 적응하기 힘들다고 말했다.

 기획도 마찬가지다. 화면과 SB로는 전혀 이해하기 어렵다. 새로 누가 올때마다 앞단의 다른 MSA의 정책과 데이터가 어떻게 넘어오는지 그리고 MSA간 어떤 기준으로 확인하는지 설명하느라 숨이 넘어간다.

 그런데 이게 앞으로의 미래다. MSA는 어쨌든 트렌드고 그 외의 모든 트렌드가 기술 이해를 촉진한다. 적어도 데이터와 알고리즘로직의 순서정도는 알아야한다. 단언컨데  앞으로 기획자가 알아야할 IT에 대한 이해범위가 줄어든다거나 UI만 가지고 싸울 일은 없을 것 같다.  하고싶은 것이 구현가능성도 없는데도 고객위한다고 하고 싶은 것을 말만 하는 기획자도 살아남기 어려울 것 같다.

 PC시절과 확연히 다르다. 난이도가 높기 때문에 알려고 노력해야한다. 공부하는 기획자가 살아남는다.

(근데 자사 시스템에서 모르는게 있으면 도그냥보다 사내 개발자에게 묻는게 정확하다.)