‘강결합’이 되어있다 보니 기능을 딜리버리 하는 개발자 입장에서 “지금 어떤 부분이 강결합되어있어서 기능 개발하는데 좀 어려움이 있을 것 같아요.” 또는 “강결합 때문에 시간이 조금 많이 필요할 것 같아요.”라는 식의 이야기해왔어요. 이를 해결하기 위해 MSA에 대한 이야기를 하고 전환 중에 있어요.
예를 들어 지원자 정보에 대한 ‘기본 정보’가 있고 ‘학력 사항’, ‘자격증 정보’ 등 다양한 것들이 있는데 기존에는 기본 정보를 바꾸기 위해 학력사항, 자격증 정보 등을 다 체크해야 해요. 하지만 모듈화를 하면 고쳐야 하는 부분만 고칠 수 있기 때문에 굉장히 효율적이라 볼 수 있어요.
하지만 당시의 문제를 해결하는 데 꼭 필요한 아키텍처는 아니었고 오히려 모놀리식 아키텍처가 효율적이기도 했어요. 최근 반년 정도 전부터 MSA로 전환하지 않았기에 발생하는 강결합으로 인해 유저가 원하는 기능 개발을 빠르게 하지 못하는 상황이 올 수도 있겠다 생각이 들었어요. 저희의 가치인 빠른 실행, 고객이 사랑하는 서비스를 만들기 위해 MSA로 전환은 불가피하다고 생각해 24년 목표로 잡게 되었어요.
그리고 회사의 비용 측면에서도 만약 고객이 10명이라 가정했을 때 모놀리식 아키텍처이면 서버 1개면 충분하지만 MSA라면 서버를 5개를 쓰는 등 과하게 비용을 지출해야 하는 단점도 있었기 때문에 초기에는 모놀리식 아키텍처를 사용한다고 말씀드릴 수 있어요.
이 과정이 끝난 이후에는 팀 내부적으로 MSA로 전환하려면 어느 정도 좋은 Practice가 필요하다 생각하는 데 이를 만들기 위해 어떤 기술력이 필요하고 어떤 컨벤션(Convention)이 필요한 지 등을 논의하며 방향성을 잡았어요.
현재 진행 상황은 방향성을 잡고 코드적인 개편과 그리팅 서비스 중 어떤 특정 부분은 MSA 전환된 부분으로 기능 배포가 될 예정이에요. 하지만 이제 시작인 거죠 (웃음)
그래서 아직 넘어야 할 산은 굉장히 많다고 생각해요. 디벨롭하면서 더 좋은 방법을 찾고 그리팅에 맞는 최적의 MSA 전환을 하려고 해요.
비단 PO/PM 분들뿐만 아니라 백엔드 엔지니어, 프론트 엔지니어 모두가 그 문제에 대해 더 정확하고 쉽게 해결할 수 있는 방법을 다 같이 논의하고 그 결과를 도출해 내기에 그러한 회사의 팀들에 비해 ‘문제해결력’이 좋다고 생각합니다.
물론 큰 서비스의 일부를 지속적으로 담당하기에 해당 분야에 전문성과 히스토리 트래킹이 쉽다는 장점이 있을 것 같아요. 하지만 그만큼 다른 기능이나 서비스를 경험하기 어려운 환경이지 않나 생각해요. 저희 팀에 합류하시면 특정 기능만 담당하지 않고 사일로에 따라 그리팅의 다양한 부분을 개발해 볼 수 있어 서비스 자체를 만드는 경험을 해보실 수 있다고 생각해요. 또한 누군가가 ‘저 이 기능 개발을 담당하고 싶어요’라고 했을 때 얼마든지 할 수 있도록 장려하는 것도 되게 큰 장점이라 생각해요.