백엔드 동료들과 앞으로의 백엔드 아키텍처를 어떻게 가져가면 좋을지 이야기를 했다. 예전 글을 보니 예전에도 이런 얘기를 했었던 때가 있었다. 멋도 몰랐지만.
2020.01.08 - [개발/고민과 생각] - 기존 모놀로틱에서 MSA 로..?
먼저 지금 현 회사의 백엔드 아키텍처를 얘기하자면 아래 사진과 같다. 별로다. 그런데 내가 입사 때부터 이렇게 돼 있었고 의존성이 너무 강해서 떼어낼려면 너무 대공사였기에 엄두를 내지 못하고 있다.
실제 유저들에게 서비스하고 있는 P, M 서비스가 존재한다. 이 서비스들은 A 라는 도메인을 기반으로 하여 각기 다른 서비스를 제공하고 있다. 그러나 P 서비스에는 매 분마다 M DB 에 존재하는 A 도메인에 대한 데이터를 P DB 로 옮기는 스케줄러가 존재한다. 그래서 본질적으로는 같은 데이터이나 서로 다른 DB 에 존재하고 있다.
처음에 입사했을 때 이런 구조를 보고 경악을 금치 못했다. 퇴사가 하고 싶었지만 병특으로 인해서 퇴사를 하지 못했다. 어쨌든 나는 개발자이기 때문에 새로 들어온 백엔드 개발자들과 이 구조를 개선을 하려고 했다. 물론 백엔드 개발자가 적은 상태에서 서비스 개발을 하지 않고 아키텍처를 개선시키는 것을 경영진분들이 반대하였었다. 나였어도 반대를 했을 것 같긴하다. 우선 지금은 서비스가 잘 돌아가기 때문이다. 결국 P 서비스는 M DB 를 굉장히 의존하고 있는 상태가 유지되었다. (이런 구조로 개발하면 안된다고 경영진분과 얘기하다 난 결국 미움을 받게 됐다)
만약 우리가 이 아키텍처를 개선하고자 한다면 어떤 식으로 개선을 할 수 있을까 고민을 했다. 하나의 회사에서 같은 도메인을 기반으로 하는 2개의 서비스를 제공한다고 했을 때 개선할 수 있는 방법으로 MSA 가 떠올랐다. 서로 다른 P, M 서비스에서 같은 도메인을 이용하고 있기에 이 A 도메인을 다른 서비스로 분리하여 사용한다면 좋을 것 같았다. 이 때 M 서비스를 개발하는 한 개발자가 "만약 분리하게 된다면 분리한 A 서비스를 개발하는 사람은 M 서비스도 개발해야 하는 상황에서 P 서비스도 고려해서 개발해야 하기 때문에 너무 힘들어 질 것 같다" 라고 의견을 냈다. 결국, 2개의 의견으로 갈리었다.
1. 백엔드 개발자가 적은 이 상황에서 앞으로의 아키텍처를 고려해야 한다.
2. 개발자가 적은 이 상황을 전제로 해서 고려하는 것이 아닌 개발자가 더 많아졌을 때를 전제로 고려해야 한다.
나는 두번 째 의견이었다. 현 상황을 전제로 해서 아키텍처를 고려하면 발전할 수 없다고 생각했다. 더 많은 개발자가 들어온다는 전제로 아키텍처를 잡아야 발전을 할 수 있다고 생각했기 때문이다. 물론, 회사에서 채용을 더 이상 하지 않겠다라는 입장이 아닐 때를 전제로 해야 하긴 하지만 회사에서도 백엔드 개발자가 적다 라는 것은 인지하고 있는 상태였다. 물론 첫 번째 의견이 틀리다라는 것도 아니다. 글을 작성하고 있는 지금은 이미 틀어진 아키텍처를 개선해야 하는 상황이기 때문에 두 의견을 조합해서 아키텍처를 설계를 해야하지 않을까 싶다. 이 의견들에 대해 타협점을 잘 정하는게 관건이긴 하다. 이 타협점은 일정, 비즈니스 요구사항에 따라 달라질 것 같기에 자세한 이야기는 하지 않도록 하겠다.
어쨌든 이런 똥밭에서 남은 개발자들이 조금씩 서비스간 의존성을 떼어내고 아키텍처를 개선하는 작업을 하면서 개고생을 하고 있자니 얻은 것이 있긴 있다. 서비스 아키텍처를 설계할 때는 처음에 잘 잡아놓아야 한다는 것이다. 순간의 선택이 몇 년을 좌지우지 하기 때문이다. 이렇게 설계 해 놓은 개발자는 당시에 아마 '우선 고민하면 오래 걸리니 빠르게 개발하고 나중에 개선하자!' 라는 마인드였을 것이다. 하지만 이런 마인드로 인해 남은 개발자들은 똥밭에서 구르게 됐다 (물론 똥밭이 아닌 곳은 없는 것 같다).
책 클린 아키텍처에서는 이렇게 말한다. "나중에 개선한다고 하는 개발자 중 실제로 나중에 개선하는 사람은 보지 못했다."
다시 MSA 로 돌아와서 그렇다면 MSA 로 전환한다 하면 어떻게 개발할건데? 란 생각이 든다. 기존에 A 도메인에 대한 테이블을 join 해서 구현하고 있는 수 많은 기능들이 존재하는데 도메인을 분리하게 된다면 모두 api 요청에 의존하여 구현을 하게 될 것이다. 다른 곳에서도 MSA 전환 시 이러한 문제들은 무조건적으로 따라오게 될 수 밖에 없을 것 같긴 하다. A 도메인에 대한 데이터는 변경이 잦지 않기 때문에 캐싱을 할 수 있는 미들웨어를 중간에 둔다던지, graphql 을 도입한던지 해서 구현을 할 것 같긴하다.
이렇게 정리하면서 든 생각은 개발자는 비즈니스 요구사항을 API 로 구현하는 것만이 아닌 아키텍처 설계 능력이 정말 중요하다라는 것과 남이 싼 똥들을 잘 치울 수 있어야 하는 개발자가 되어야 한다는 것이다. 물론 다음 개발자가 보았을 때도 내가 개발하고 설계해 놓은 것들에 대해서 똥이라고 하겠지..! 그래도 더 나은 똥을 싸도록 노력하도록 하자.