영상버전 : https://youtu.be/4N0v9QUGD_I 얼마전 태국 개발팀이 만들고 운영하던 서비스를 인수인계 받았는데요.. 인수인계를 받으면서 서비스 회사의 대표에게서는 태국 개발자들의 대응이 너무 느리다고 불만이 많았고, 태국 개발자들은 일이 많은데 알아주지 않는다고 불만이 많았습니다. 저야 인수인계를 받는 입장이다보니 양쪽 비위를 맞추어 최대한 잘 받아내야 하므로 이런저런 불만을 계속 들어주면서 어르고 달래서 최대한 받아냈죠.. 인수인계를 받고 한달 남짓.. 아직도 이 서비스를 100% 이해를 못했습니다. 하지만, 점점 양쪽의 입장을 이해하기 시작했습니다. 일단은 구조를 보시죠.. 이 구성도 역시 타이 개발자들이 준게 아니라 그냥 디플로이 매뉴얼과 어카운트 정보 표를 보고 하나하나 들어가서 보면서 만든겁니다. 즉, 아직도 빠진게 있을지도 모른다는 것.. 구조를 보면 이상한 툴들이 많이 보이죠? 대부분의 대규모 경험을 한 사람일 수록 리스크 포인트를 줄이기 위한 노력을 합니다. 그 결과가 단순화, 그리고 장애시 빠른 복구가 가능한 구조, 확장이 편리한 구조를 많이 생각하죠. 이 말은 이 서비스는 MSA가 되어있느냐를 항상 질문하게 되죠. MSA는 아주 작은 단위로도 독립적인 서비스로서 기동이 가능하게 만들어야 하구요.., 그 기능들끼리 API등으로 연결해서 장애시 장애 포인트의 확인이 쉽고, 병목이 발생하면 그 부분만 확장이 가능한 구조를 가져가게 됩니다. 그렇게 하면 쉽게 확장이 되고, 운영이 간단하죠. 즉, 특정 모듈이나 솔루션, 미들웨어를 설치할 때, 이것 없이 더 단순화 할 수 있는지를 계속 물어가면서 만들어야 하구요, 개발 공수보다 이 모듈을 넣는게 낫겠다면, 그 모듈을 넣고나서 운영을 어떻게 편리...