레거시 시스템 개편의 기술 - 배달 플랫폼에서 겪은 N번의 개편 경험기

 

 

한샘 2차 면접 준비를 앞두고, 레거시를 마이그레이션할때 어떻게 해야하는지 궁금했고 재직자분께 해당 섹션을 추천받아서 보게 되었다.

(혹시 이미지와 관련하여 문제가 되는 부분이 있다면 삭제하겠습니다.)

---

 

• 📣 발표자 : 우아한형제들 권용근님

1. 레거시 개편은 왜 일어나는가?

 

레거시 시스템이란?

간단하게 말해서 낡은 시스템을 말한다.

 

• 현재는 비주류인 기술
  • 많은 사람들이 좋아하고 선호했던 기술이 시간이 지나면서 잊혀지거나 시대를 역행하는 아키텍처라고 판단되서 비주류가 되는 기술

• 현재는 성능이 부족한 시스템
  • 과거에는 요청을 다 처리했지만, 트래픽도 늘어나고 새로운 요구사항을 하면서 성능적인 챌린지도 하다보니 성능적으로 부족한 시스템

• 새로운 요구사항을 대응할 수 없는(어려운) 시스템
  • 과거의 요구사항은 주어진대로 잘 수행했지만, 현재 가지고 있는 구조로는 더 이상 새로운 요구사항을 대응할 수 없는 시스템

레거시 시스템은 항상 개편이 되어야 하는가?

 

• 현재는 비주류인 기술 → 시간을 더 들인다
  • 현재는 비주류인 기술도 개발자를 갈아내서 시간을 어떻게든 투자하면 어떻게서든 할 수 있다.
• 현재는 성능이 부족한 시스템  →  비용을 들인다
  • 스케일 아웃이든 스케일 업이든 비욜을 더 지불해서 해결할 수 있다
• 새로운 요구사항을 대응할 수 없는(어려운) 시스템  → 새로운 시스템을 만든다

그럼 개편은 어떻게 결정이 되는가?

 

투자자본수익률(ROI)

 

즉, 가성비가 배경에 있어야 한다. 우리가 노력을 들인 대비 얻을 수 있는게 어느 정도인가를 측정해야 한다

 

소수인원을 갈아내거나, 비용을 투입하거나, 새로운 시스템을 만드는 데 드는 복잡한 비용을 측정하는게 있을 것이다.

여기서 비용은 시스템을 운영하는데 들어가는 비용을 말하는데, 이것 외에도 많은 기회비용이 발생한다.

 

만약에 새로운 언어나 프레임워크를 선택해서 개편하게 된다면 그로 인해 들어가는 학습 비용도 비용이 되고,

개편하게 되면 빅뱅이든 점진적 개편이든, 비즈니스를 처리할때 사용했어야 할 리소스가 개편에 들어가기 때문에 비즈니스적인 지원도 있고, 비주류인 기술을 계속 사용하다보면 채용적으로도 비용이 들어가서 퇴사나 리스크 아니면 시스템이 버틸 수 있는 한계치 같은것들까지 모두 고려해서 계산해야 한다.

 

결국에는 이렇게 어렵게 산출한 비용을 결정권자들에게 넘기게 되는데, 이러한 비용 측정을 현재 시점으로만 보면 도움이 되지 않는다.

 

 

비용과 시간 그래프를 보면 기존 시스템을 계속 운영하게 되면 운영에 들어가는 유지 보수 비용이 계속 점점 늘어날거고, 개편을 한다고 하면 개편에 들어갈 때 비용은 약간 올라가겠지만 이전보다 운영에 들어가는 비용의 시간 대비 그 기울기가 줄어들게 된다.

 

적당한 시기에 개편을 하게 되면 적은 비용을 들여서 계속 시스템을 운영할 수 있겠지만, 개편을 조금 늦게 했다고 하면 기존 대비해 많은 비용을 쓰게 될 것이다. 이 비용이 어떤 비용일지 생각해봐야 하는데, 이 비용은 서비스를 지속시킬 수 있는지, 성장시킬 수 있는지 결정할 수 있을만한 비용이다.

 

적절한 시기에 개편하지 못하고 유지보수하는데만 치우지고, 시장이 발전하는 속도와 타이밍을 따라가지 못하게 되면 결국 뒤쳐지거나 도대퇴서 서비스가 무너지게 된다.

 

 

결국 레거시 시스템 개편은 개편의 복잡한 비용을 계산하고 예측해서, 적절한 시기에 서비스를 지속, 성장 시키기 위해 일어난다.

 

 

2. 경험한 개편은?

 

배달의 민족을 사용하려면 로그인하고, 가게 목록 들어가고, 메뉴를 골라서 주문하고, 결제를 하는 플로우인데,

발표자이신 권용근님께서 해당 플로우를 역순으로 결제 시스템, 주문시스템, 가계노출, 회원 시스템 개편하셨다.

 

2018년도는 배달의 민족이 거의 2~3배씩 성장하던 시기였는데, 기존 대비 너무 많은 성장을 하다보니 데이터적인 한계가 와서 결제시스템에다가 데이터베이스를 파티셔닝하는 결정을 해야 했다.

주문 시스템도 성장이 가파르다보니까 가지고 있는 데이터 모델링 자체가 더 많은 트래픽이나 주문을 받을 수 없는 상황이라고 판단해서 데이터 모델링을 바꾸고 도메인까지 완전히 뜯어고치는 개편을 했다.

 

가계 노출 시스템 개편은 새로운 비즈니스를수용하려고 예전에 Monday라는 큰 프로젝트를 했었다. 해당 프로젝트는 새로운 비즈니스를 수용하기 위한 거였는데, 그쪽에서 광고라든지 가게라든지 하는 시스템들도 똑같이 개편이 되었는데 노출 서버 쪽도 당연히 개편이 필요하기 때문에 개편이 들어갔고, 이때 당시 가지고 있는 프레임워크와 언어가 다르게 쓰이고 있었다. 그래서 좀 유지보수 하기 힘든 상황이었던 프로젝트였고 결국 데이터 모델링부터해서 프로젝트 자체를 아예 새로 만드는 개편이었다.

 

비즈니스 확장이랑 회원이라는 도메인이 크게 관련이 없다고 생각할 수도 있다. 그래서 2021년까지 오래 버텨준 시스템이 인프라 한계치를 사용하고 있었다. AWS 비용의 한계치를 상요하면서 더이상 스케일 아웃이나 스케일 업을 할 수 없는 상황까지 가서 개선하기 위해 개편을 했다. 회원이라는 도메인과 인증이라는 도메인이 같이 있었는데 그 도메인을 분리해서 더 회원은 회원답게 인증은 인증답게 처리 했다.

3. 개편의 기술

 

1) 의존성을 한 방향으로 정리하라

common모듈을 사용했을때 스파게티 코드, 스파게티 의존성때문에 힘들었던 때가 있었다.

객체나 컴포넌트에 의존이 참조하는 방향이 되게 복잡하게 꼬여 있어서 그 모양이 좀 스파게티 면 같다고 해서 스파게티 의존성이라고 부르는데, 주문 시스템에서 좀 심각하게 갖고 있던 상황이었다.

 

개편을 할때 코드를 수정하게 되는데, 코드를 수정했을 때 발생하는 사이드 이팩트를 측정해야 하는데, 수백개의 컴포넌트들이 스파게티 의존성을 갖고 있는 경우에는 어떤 곳에서 문제가 발생할지 측정하기가 굉장히 힘들다.

맨 처음에는 흰 도화지에 기능을 만들어 나갈때, 재 사용성을 따라서 B서비스에서 뭔가하려고 했더니 기존에 A서비스에서 했던 일인 것 같은데 하면서 A서비스의 코드를 재사용할 수 있을 것이다. 또는 새로운 요구사항이 B컨트롤러에 들어왔는데 C서비스에 구현되어있네? 저거 써야지 하면서 기능을 따라서 계속 개발이 되다보면 어느새 스파게티 코드가 되어있는걸 발견하게 된다.

 

개편을 할때는 이런 스파게티 의존성이 있는 상태로는 리스크 관리가 너무 어려워서 할 수없게 된다.

그래서 스파게티 코드를 어떻게 풀 수 있을까? 의존성을 한 방향으로 설정해야 한다.

B컨트롤러에서 새로운 기능을 다시 개발할때 B서비스에서 A서비스를 의존하는 방향이 있었는데, 이렇게 했을때는 위에 설정한 오른쪽에 의존성 한 방향이 어긋나기 때문에 잘못된거라고 할 수 있다.

기준이 필요한데, 그 기준은 계층이나 아키텍처가 적용되면 좋겠지만 그런 상황이 어렵다면 의존성의 깊이를 그 기준으로 한번 삼아보면 도움이 될 것이다.

예를 들면 두번째 계층에서 첫 번째 계층을 의존하는 것은 방향이 생겼으니까, 명확하게 역방향인것을 알 수 있을 것이다. 그리고 B서비스에서 A서비스를 의존한 것은 같은 층을 의존하는 것도 다른방향이라고 할 수 있다.

그러면 해당 문제를 어떻게 해결할까? A서비스에서 재사용하려는 코드를 적절하게 분리해서 두 서비스가 모두 우전할 수 있는 그런 계층에다가 옮겨서 작성하는 방법이 있다. 이런식으로 의존성을 한 방향으로만 잘 관리해도 스파게티 코드를 피할 수 있다. 이 상태에서 코드를 수정하면 어디서 사이드 이펙트가 발생했는지 측정할 수 있게 된다.

 

2) 변경 대상에 대한 경계를 나눈다

1번 해결방법과 비슷한 맥락인데, 사이드 이펙트를 관리하게 될 수 있는 장점도 있지만, 의존성이 한 방향으로 잘 관리되면 변경 대상을 좀 더 수월하게 나눌 수 있다.

실제로는 위의 그림보다 관계가 복잡할 텐데, 의존성이 한 방향으로 잘 정리가 되어 있는 코드라면 실제로 변경에 영향을 받는 코드를 탐색해 볼 수 있다. 문제가 있는 상태라면 여러 계층에 분포할 가능성이 크다. 책임과 역할이 제각각이라고 표현 했는데, 이 말이 어떤 의미냐 하면 계층이 분포한 모양이 다르다.

 

예를 들어, 4계층에 있는 객체는 1,2,3 계층을 거쳐서 4계층까지 들어왔을 거니까 저 앞에서 뭔가 역할과 책임이 일부 분리되면서 4계층까지 왔을 것이다. 그런 계층이 있기 때문에 아마 4계층보다 2계층이 더 많은 책임을 가지고 있다고 할 수 있다.

 

스프링 기준으로 얘기했을때, 컨트롤러, 서비스, 레포지토리 정도는 기본적으로 가지고 있을 텐데 이 코드들이 이렇게 분포가 되어 있다고 생각해볼 수 있다. 2계층은 컨트롤러이고, 3계층과 4계층이 서비스, 5계층이 레파지토리인데 이때 우리가 생각해볼 건 컨트롤러와 서비스, 레포지토리가 각각 해야하는 일을 명백하게 알고 있을 것이다.

우리가 변경해야할 코드가 레파지토리 쪽에만 있었다면 명백히 DB관련된, 영속계층 관련된 개편이 진행된다고 예측할 수 있겠지만. 지금 처럼 너무 여러 계층에서 저런 코드들이 몰려있게 되면 책임과 역할이 제각각이라서 변경 범위를 파악하기 어려웠을 것이다.

이런 상황에서 솔루션은 바로 변경 대상에 대한 경계를 나누는 방법이다.

 

일단 계층을 다시 허물고 나눠버린 다음에 패키지나 모듈로 나눌 수도 있을 것이다. 그 다음 나눠진 변경 대상을 우리가 하나의 계층이라고 정의하는 것이다. 그래서 하나의 계층이 되면 그 계층에 지금 우리가 필요로 하는 개편이 어떤 개편인지 생각해보고 실제로 변경되는 코드들이 뭔지 생각해보고 이 계층의 책임이랑 역할을 다시 한번 우리가 정의해볼 수 있다.

 

예를 들어, 결제 시스템 개편할때 데이터베이스 파티셔닝 얘기를 했는데, 이때 당시 변경 대상에 대한 코드를 모두 뽑아봤을 때 명백하게 DB를 수정하는 코드들이 완벽하게 다 물려있었다. 그래서 그 코드들을 분리해서 하나의 계층을 이뤘더니, 이 계층은 우리가 원래 다뤘어야 할 인프라 스트럭처 레이어이구나 라고 정의를 했었고, 주문 시스템 개편에서도 비슷한 상황이긴 한데 인프라를 분리하고 나서 인프라 계층에서도 한 번도 책임 과 역할을 좀 분리하다보니까 도메인 계층이구나 라고 알 수 있었다.

 

그래서 개편에서 다뤄야 할 계층을 이런식으로 실제로 해야되는 역할과 책임을 좀 명백하게 정의해보는 것이다. 이 개편에서 다뤄야할 계층을 확보했다는 것은 소프트웨어에서 다뤘어야 할 그런 계층인데, 제대로 응집을 하지 않아서 다루지 못하고 있었던 그런 계층이라는 것을

알 수 있다는것을 의미한다.

 

이런 계층을 확보했다면 계층의 책임과 역할에 의해서 분리가 될 수 있다. 이제 저 계층의 책임과 역할에 맞지 않는 그런 코드들은 이제 다른 계층 바깥쪽으로 빼버리고, 반대로 저 계층의 채깅ㅁ과 역할에 들어와야 할 코드들은 타계층에서 안으로 흡수하면서 코드가 어느정도 정리될 수 있다.

이렇게 함으로써 제각각이던 계층의 역할과 책임의 범위가 하나의 계츠응로 명백하게 모이고, 변경 범위에 대한 가시성을 확보할 수 있다. 변경을 어디를 해야하는지 코드상으로도 명백해질 수 있다. 이런 방법으로 의존성의 층에도 역할이나 책임을 부여하면 진짜 아키텍처가 발견될 수 있다.

 

3) 테스트를 확보한다

잘 정리된 의존성과 변경해야 될 대상이 명확하다면 테스트를 뽑아야 한다. 그래서 테스트 코드를 뽑는다면 변경되는 애들이 저쪽에 다 몰려있으니까 저쪽에 테스트 코드를 뽑으면 될 것이다. 그리고 개편을 하게 되면 인터페이스는 약간 변경이 될 수 있는데, 그쪽 계층에 한 단계 더 위에 계층까지는 테스트커버리지나 테스트 케이스를 꼭 챙겨야 한다.

 

개편할때 테스트를 작성하면 좋겠지만, 현실적으로는 어렵다, 개편은 일정이 정해져있다. 비즈니스랑 직접적으로 연관이 돼 있을 가능성이 있기 때문에 시간이 좀 부족하게 된다.

가게 노출 시스템 개편할때 언어와 프레임워크부터 데이터베이스까지 전부 다 변경이 필요한 상황이었다. 그래서 사용자 인터페이스만 동일한 상태로 시스템이 개편이 되니까 기존에 있던 테스트 케이스를 거의 재사용하기가 힘들게 되었다. 언어랑 프레임워크가 다르다보니 3개월동안 저 테스트를 복사해서 가지고 오는 것만 해도 1달~2달정도 소요가 될것 같았다.

그래서 Json 요청을 Diff를 떠버렸다. 이게 무슨 말이냐하면, 로컬에서 테스트 할때도 결국 E2E테스트를 한건데 엔드포인트를 요청했을때 그 요청이 기존 시스템 요청이랑 똑같은 결과가 나오는지 검증했다. 다행히 저 가게 노출 시스템은 커맨드를 수행하는 시스템은 아니고 쿼리만 수행하는 시스템이라 저런 방식을 사용했다. 원래 로컬에서 이런 테스트는 원칙에 맞지 않다. 테스트는 인터넷이 안돼도 돌아가는 상황이 되어야 하지만 특정 경우에는 이런 방식을 쓸 수가 있다.

또 Ngrinder라는 성능 테스트 도구를 사용했는데, 성능 테스트를 위한 도구이지만 부하를 줄 수도 있는 도구 이다.

그래서 Ngrinder를 이용해서 개편이 3달동안 진행됐다고 하면 한 두달 동안 거의 24시간 동안 갖고 있는 모든 데이터 풀을 계속 욫어하면서 비교하는 것을 개편이 끝날 때까지 계속 유지했다

회원 시스템을 개편할때도 데이터베이스 쪽이랑 시스템의 일부 코드가 변경되었는데, 이때는 테스트 케이스를 재사용할 수 있었다.

완전히 변경되는 부분까지는 가지고 오지 못하더라도 그래도 어느정도는 우리가 테스트 케이스를 가지고 올 수 있을 텐데 여기서 발생한 문제는 바로 테스트 케이스가 거의 없는 상황이었다.

그래서 이 상황에서는 블랙박스 테스트를 이용했다. 블랙박스 테스트란 저 사이에서 어떤 일이 일어나는지 신경쓰지 않겠다는 것을 의미한다. 그래서 E2E테스트인데 블랙박스 E2E테스트라고도 말을 한다. 요청이랑 데이터베이스에 어떤값이 있는지만 가지고 테스트를 전부 수행하는 것이다.

그리고 가지고 있는 테스트 케이스가 없다 보니까 기획서를 전부 뒤져서 테스트 목록을 만들었고, 앱이 동작하고 있으니까 앱에서 정상 동작하는 그런 액세스로그를 전부 긁어가지고 그걸 기반으로 테스트를 다 작성했다. 이때 설득하는 과정이 있긴 했지만 테스트를 작성 하는데만 0단계라고 되어있다. 0단계의 테스트를 한달 동안 만들기만 하는 시간을 어떻게든 확보해가지고 테스트를 했었다. 이렇게 테스트를 통해 변경되도 괜찮다는 심리적 안정감을 얻을 수 있었다.

1,2,3장은 코드 관련된 부분으로 진행했는데, 이때 얘기했던걸 정리해보면 위와 같은 내용이다. 그런데 과연 이런 내용이 개편에서만 필요할까? 개편이라는 것 역시 굉당한 커다란 유지보수의 작업이다. 유지보수하기 좋은 소프트웨어를 만들려면 저런 원치들을 지키고 있어야 한다. 그래서 꼭 개편을 하지 않더라도 현재 운영하는 시스템이 저런 의존성과 책임과 역할이 다 명백한 그리고 잘 관리되어 있는 유지보수하기 좋은 시스템인지 확인해봐야 한다.

 

4) 프로젝트 가시성 확보

코드적인건 아니고 개편을 잘 성공적으로 마치기 위한 방법이다. 큰 문제를 작은 문제로 만들어서 풀어 나갈때, 그 작은 문제를 좀 더 쉽게 쉽게 해결하다 보면 큰 문제를 해결할 수 있다는 방법이다. 우리가 개편할 때 굉장히 큰 일들이 많았을 텐데, 그 개편에서 해야할 일들을 좀 가시화한다면 우리가 더 좋아지지 않을까라고 생각할 수 있다.

일정에 대해서 예측한다는 것은 항상 리스크이다. 개편할때 이러한 리스크를 더 잘 관리할 수 있게 된다는 점이 큰 장점이 될 것이다.

Jira나 Confluence 이런걸 다쓰고 있는데, 그것 보다 엑셀시트로 관리하는게 좋았다. 그래서 해야할 일들을 상세하게 기준에 맞춰서 나눠서 했는데, 도메인 안에 도메인 안에 또 서브도메인들을 뽑고 서브 도메인 안에서 우리가 만들어 가거나 변경해야될 작업들을 목록화 한다음에 그걸 하나하나 일정을 기록했다. 이거를 진행하면서 하는게 아니라 초기에 먼저 진행했다.

 

이렇게 하면 일정을 관리할 수 있다는 측면에서의 장점도 있지만, 여러명이서 같이 개발을 할텐데, 개발이 아니더라도 다른 팀이랑도 같이 일을 할 텐데 그때 저희가 서로 뭘 하고 있는지 그리고 서로 뭘 하고 있는지 아니까 내 개인 일정을 조금 계획할 수 있는 그런 의미도 됐고 그리고 개편이라는게 좀 장기적으로 갈 수 있다. 그럴때 지칠 수가 있는데, 저런 지표가 우리가 어디까지 왔는지 그리고 얼만큼 더 하면 끝나는지 진행상황을 보여주면 희망지표가 될 수 있다.

우리 구성원 뿐만 아니라 이해관계자들이 있을 것이다. 우리 시스템에 API를 제공해줘야 한다거나, 우리가 API를 제공해줘야 한다거나 아니면 우리 시스템을 일저에 대해서 결정할 수 있는 임원분들을 이해관계자라고 한다. 그분들은 이런 명확한 지표랑 일정이 있다면 우리를 지원하기가 더 수월해질 것이다.

 

부록1. 도메인 이해 공유

개편을 할때 여러 구성원들이 같이 진행할 텐데, 사람마다 우리가 현재 하고 있는 도메인에 대한 이해 수준이 다른 케이스가 존재할 것이다.

도메인이란 주문 시스템 개편을 한다면 주문이란 것 자체, 우리가 서비스가 가지고 있는 주문에 대한 자체의 이해 같은 것을 말한다.

 

그래서 구성원들간의 이해가 차이 났을때 도메인 지식이 거의 없거나 약한 사람들은 개편도 해야하는데, 도메인을 이해하는데만 엄청나게 많은 비용을 들여가면서 따라가려고 노력해야하고 더  리스키한 것은 저런 사람들은 의사결정 과정에 참여하기가 힘들어진다. 코더가 된 것 같으 는낌을 받을 수도 있고 주도적으로 할 수 없는 느낌을 받을 수도 있다. 그러면 도메인을 더 잘 알고 있는 사람들은 나을까? 라고 했을때 저 사람들이 맞다라고 하면 그냥 맞다라고 될 수도 있고, 아니다라고 하면 아니다라고 될 수 있기 때문에 굉장히 큰 부담을 갖게 된다.

 이렇게 도메인에 대한 이해 관계가 다른 사람들이 모여서 개편을 하게 되면 똑같은 요구 사항을 볼 때도 굉장히 다르게 이해할 수 있게 된다. 그럼 이때 우리는 같이 일을 하는 과정에서 커뮤니케이션 비용이 굉장히 많이 발생하게 된다. 그렇게 되면 결국 이렇게 도메인 수준이 이해관계가 차이가 나는 사람들이 모여서하게 되면 모두가 힘들어 질 수 밖에 없다.

 

해결하는 방법으로 이벤트 스토밍을 추천한다. TDD에서 전술적 설계라는 부분에서 나오는건데 확실하게 TDD가 아니더라도 무조건 도움이 된다. 참고 영상 링크

 

위키피디아에서 정의를 갖고와보면 이벤트 스토밍은 소프트웨어 프로그램에서 어떤일이 일어나고 있는지, 도메인에서 무슨 일이 일어나고 있는지 빠르게 알아내기 위한 방법이라고 얘기한다. 그런데 도메인이라는 게 용어를 잘 풀어보면 우리가 해결해야될 문제 영역이라고 말한다. 결국에는 이벤트 스토밍은 우리가 어떤 문제를 해결해야 하는지 좀 더 빠르게 가시화하고 알아낼 수 있는 그런 워크숍 기반의 방법이다.

 

이벤트 스토밍을 하게 되면 구성원 전체가 같은 선상에서 도메인을 하나하나 다 가시화 하는 과정을 거치게 된다. 도메인에 익숙하지 않은 구성원들도 어느정도 하나하나 만들어지는 과정에 참여를 할 수 있게 되니까 도메인에 대해서 많이이 배울 수 있을 것이고, 하나하나 만들어지는 과정에서 궁금했던 거나 의문이 제기될 만한 부분을 제기하면서 기본보다 더 좋은 방법으로 개선하거나 그런 부분에도 기여를 할 수 있을 것이고 궁극적으로 같은 방향으로 나아갈 수 있다.

 

 

포스트잇 가지고 할 수도 있고 미로라는 온라인 도구를 통해 이벤트 스토밍을 통해 도메인 지식이 올라갈 수 있었다.

 

부록2. 변화를 측정한다

 

측정이라는 것은 어떠한 관찰 수단을 이용해서 우리가 살펴보는 무엇에 대한 불확실성의 정도를 낮추는 행위라고 하는데, 여기서 무엇이 약간 모호하긴 하다. 개편을 하면서 저렇게 불확실성이 있는 무엇이 어떤게 있을까 생각해보면, 개편 과정에서 많은 트레이드 오프나 도전들이 있었을 것이다.

 

예를 들어, 데이터 베이스 종류에도 A가 있고 B가 있는데 우리가 어떤 이유로 A를 선택했다는 과정이 있을 것이고, 아키텍처라든지 아니면 알고리즘일 수도 있고 아니면 어떤 방식이 될 수도 있다. 그런 무엇을 우리가 분명히 했을 텐데 그거를 측정을 꼭 해야 한다.

 

예를 들면 주문 수 같은 지표가 생길 수 있다. 우리가 이 작업을 하면서 똑같은 시간에 할 수 있는 사용자 경험이 좋아져서 주문 수가 10% 올라왔다 할 수도 있는거고 비용이 10% 줄었다고 할 수 있지만 또 다른 측면에서 좀 안좋은 네거티브한 결과를 나올 수도 있다고 생각한다.

CPU가 올랐어. TPS가 오히려 좀 떨어졌어. 라고 할 수도 있지만 이런 나쁜 지표가 나왔다고 해서 무조건 마이너스가 되는 요소는 아니다.

 

우리가 이거를 위한 어떤 트레이드 오프를 했냐라는게 굉장히 중요하다. 그래서 우리는 그 무엇에 대한 것을 측정 함으로써 좀 불확실한 것을 낮추는 결정을 할수가 있다. 내가 했던 경험을 잘 기록해 놓으면 (측정+공유) 개편에 큰 도움이 될 수 있다.