2024 9월 4째 주 (결제 도메인의 추상화 보존기)

결제 도메인의 추상화 보존기 

- 비효율적 연동 구조에서의 교훈: 소통 비용과 인터페이스 개선 경험

 

 

결제 서버는 여러 서비스들이 연동되는 플랫폼이다 보니 
당연하게도 어떤 설계를 디자인할 때 추상화에 많은 신경을 쓰게된다. 

다만, 이번에 진행하고 있는 프로젝트에서 각 서비스들의 리소스가 부족하다보니 
특정 데이터를 전달받을 때, 각 서비스에서 이미 사용하고 있던 API 를 전달받게 되었다. 

우리가 원하는 타입 A로 전달받지 않으니 서비스 별 서로 다른 응답값들을 A 타입으로 조합 및 가공해야하는 추가 공수가 발생했고, 
이는 하기 2가지의 문제가 있었다. 

 

1. 결제 도메인에서 불필요한 서비스 도메인 지식을 알아야 한다는 점
   1. 서비스 종속 코드 증가
2. 서비스 지식을 알기 위한 상호간 소통 비용이 증가하는 점
   1. 모든 응답 케이스를 샘플로 받아볼 수 없으니, 응답 값 활용 방식의 불확실성
   2. 불충분한 응답 데이터로 데이터 추가 요청

이런 문제를 안고 작업하다 보니, 테스트 코드에 더 목을 매게되었고, 
그마져도 실상 응답으로 올 것으로 예상되는 가데이터를 가지고 테스트했기 때문에 서비스에서 그 값으로 주지 않으면, 문제가 됐다. 

물론, 모든 케이스를 알기 위한 소통 과정도 비용이었다. 

작업 초반에는 각 서비스에서 일손이 부족하다보니 전환 작업 정도는 안고가야할 것으로 보았으나, 
추후 다른 서비스들이 추가 연동될 때도 고려했을 때, 지금부터 잡고가야할 문제라는 판단이 섰다. 

그리고 놓인 문제들과 개선 방향을 제안드렸고, 현재 놓인 문제들에 충분히 공감하고 계신 상태로 원만하게 합의가 진행되었다. 

돌이켜 보면, 이미 해당 인터페이스가 정해진 상태로 프로젝트로 투입되었고, 리소스도 부족하다는 이야기를 들어서, 이게 맞나? 싶으면서도 쉽게 제안드릴 수 없었던 것 같다.  
먼저 빠르게 제안드렸다면, 불필요한 소통 비용 등이 발생하지 않았겠지만.. 이번의 경험이 훗날의 의사 결정에 좋은 거름이 되겠지 : )