MSA에서 정합성 보장은 누가 하나요?
MSA 기술과 적용 연구 17
지난 글에서 다수의 서비스가 공용 RDBMS를 사용하는 구조는 대표적인 가짜 MSA라고 했다. 합리적인 주장일까? 지난 글의 제목 <MSA는 서비스 병행 운영을 추구한다>가 내가 제시한 근거다.
서비스 바깥의 변화도 알아야 하면 프로그램을 못 고친다
문장으로 써놓고 보니 당연한 것인데, 아직도 많은 조직에서 무시하는 이치이다. 이유는 여러 가지가 있겠지만, 개발 프로젝트라고 하면 당연히 외주 개발에 의존했던 긴 세월이 만든 관행일지도 모르겠다. 프로그램을 발주한 갑사는 프로그램이 제대로 짜여져 있는지 블랙박스로 확인한다. 설사 당장 잘 작동한다고 화면 등의 출력물만 보고 판단을 했다고 하더라도 프로그램에 오류가 있는지 판단한 능력이 없다. 외주 개발 이후에 이를 유지보수를 하는 개발자가 있다고 해도 최초 개발자가 작성한 의도를 몰라 수정을 못하거나 잘못 수정하는 경우를 흔히 볼 수 있었다. (지금도 볼 수 있지만)
10 여년 전 일이지만, 복수의 이커머스 조직의 개발 조직에서 발견한 패턴이 있었다. 주문 코드 고치는 일은 쉽지 않았다. 한 곳에서 필자가 직접 회원 영역과 주문 영역의 코드 행을 헤아려봤는데 백엔드 코드만 대략 1:20 정도였다. 주문코드가 단순히 산술적으로 회원 로직의 20배의 분량이었다. 복잡도 역시 엄청난 차이가 났다.
주문 코드에는 장바구니 처리나 카드 프로모션에 대한 재무 전처리 등을 모두 포함하고 있어 '주문'이라고 부르는 것조차 합리적인가 싶을 정도였지만, 결국 주문 데이터베이스 만들 때 중요한 처리를 모두 위임하는 탓이었다.
기술 부채와 관행을 담은 레거시
이렇게 불공평한 직무 분배로 인해 결국 주문 개발자는 결과적으로 코드 수정이 거의 없는 운영을 두 곳에서나 관찰할 수 있었다. 반면에 주문 개발자는 모든 운영 행사에 대해 영향도 파악을 위해 여기저기 불려다니곤 했다. 하는 일만 보면 과연 개발자인가 싶은 정도였다.
나는 이런 현상이 대표적인 기술 부채 효과라고 말하고 싶다. 비단 프로그램에 오류가 있거나 낡은 프로그래밍 방식을 방치해둔 것만이 기술 부채가 아니다. 사실 기술 부채와 이를 낳는 조직이나 그 구성원의 관행은 경계를 구분하기가 매우 어렵다.
개발 현장에서 경험이 많은 사람은 대체로 도움이 되지만 그가 갖고 있는 과거의 경험이나 기술이 무비판적으로 수용되는 일도 자주 발견할 수 있다. 어떤 면에서는 인간의 삶에서 어쩔 수 없이 벌어지는 일이기 때문에 함께 일하며 성장할 수 있는 조직 문화가 필요하다. 이에 대해서는 <함께 성장하며 함께 일하기 위한 3가지 필수 조건>편에서 구체적으로 내 생각을 밝힌 바 있다.
데이터 모델 전문가라는 레거시
한때 시스템 튜닝을 데이베이스 전문가에게 의존하던 시절이 있었다. 튜닝으로 유명했던 어떤 회사는 전사적 데이터 모델링을 강조하기도 했다. 외주 개발 맥락이나 단기 효율로는 효과적인 전략이다. 다만, 외주 개발에 더해 개발 결과물을 지배하는 데이터 모델은 또 다른 별도의 전문가에게 의존한다니, 외주에 외주를 더한 최악의 시스템 관리 방식이다.
DB 모델링도 못하는 신입 개발자가 더 나은 코드를 만들더라
코로나가 잠잠해지면서 있었던 회식 자리에서 CTO가 무용담처럼 한 말이다. 무슨 말인지 언뜻 이해가 가지 않아 부연을 요구했더니, 요즘은 AWS 상에서 클라우드 서비스 형태로 프로그램을 만드는 일이 당연해서 구글링을 통해서 꼭 필요한 기술만 찾아 빨리 개발하는 친구들의 결과물이 더 낫다는 말이었다.
낫다는 말은 비교의 결과물인데 무엇보다 낫다는 말일까? 아마도 자기가 아는 지식에 갇혀서 AWS라는 실행환경에 맞지 않는 프로그래밍 방식을 쓰는 구식(?) 개발자일지도 모른다. (CTO에게 묻지 않은 개인 뇌피셜이다.)
중요 기술을 외부 제품에 의존했던 관행
<축적의 시간>을 읽고 감격했던 순간이 떠오른다. 개발자 입장에서도 스프링(Spring) 프레임워크는 원천 기술로 가져다 써야지 우리가 만들 필요가 없었던 시절이 있다.
지금도 굳이 있는 것을 다시 개발할 필요는 없다.(Don't reinvent the wheel) 하지만, 원천 기술에 대한 정의가 우리의 비즈니스(도메인) 현실에 따라 달라질 수 있다. 솔루션을 밖에서 가져오는 대신에 패턴만 채용하여 직접 만들어야 할 수도 있다.
다른 것은 몰라도 사업의 확장 속도 자체가 중요한 경쟁력으로 작용할 때, 시스템 구성을 자유롭게 바꿀 수 있는 힘은 엄청난 위력이 아닐까 싶다. 어쩌면 우리는 그러한 전개속도가 갖는 힘은 과소평가 하고 있는 지도 모른다.
아무튼 이제는 응용 프로그램의 정합성을 다루는 일이 개발자의 중요 덕목이 되어야 할 시간이 아닌가 싶다. 여기까지 쓰고 보니 페메로 받은 고등학생의 질문을 담은 <MSA에서 정합성 보장은 어떻게 하나요?>는 꽤 유용한 질문이다. 그리고 질문자뿐 아니라 생업이 개발자인 분들은 자신이 그걸 할 수 있는 역량을 확보할 때가 되지 않았나 싶다. 요즘처럼 개발자 몸값이 높고 기회가 높은 시절이니 그 정도 역량을 갖추면 기회를 얻기는 쉬울 듯하다.
