들어가기에 앞서
Backend for Frontend?
2010년대 소프트웨어 서비스의 흔한 양상 하나는 웹으로 시작한 서비스가 모바일로 서비스를 확장하는 것이었습니다. 이 때, 웹 백엔드로 모바일 서비스까지 지원하려다 보면 백엔드가 일반화되고 개별 웹 또는 앱 서비스의 니즈에 맞춰주기 어려워집니다. 이를 해결하기 위해 공통적인 도메인 서비스들을 분리해내고, 각 프론트엔드 서비스를 위한 전용 백엔드 - Backend for Frontend - 를 두어 이 백엔드에서 필요한 비즈니스 로직을 호출하고 결과를 가공해서 프론트엔드로 전달하도록 하는 패턴이 BFF 패턴입니다.
발단
Monolith to Microservices
회사 시스템 중 하나의 큰 business domain을 담당하던 monolith service가 규모가 커짐에 따라 더 작은 단위의 service로 분리하게 되었습니다.
New BFF Layer
비즈니스 응집도에 맞춰 3개 도메인으로 분리하였는데, 여기에 기존 monolith service를 이용하던 클라이언트가 일일히 각 service와 직접 API통신을 하지 않고 단일 백엔드에 붙을 수 있도록 backend for frontend 역할을 하는 레이어가 추가되었습니다.
전개
"팀의 사정"이라는 것
항상 사정이라는게 생깁니다. 이 케이스에서는 나눠진 도메인팀의 리소스에 일시적인 불균형이 생기면서 특정 도메인팀에 업무가 가중되었습니다. 어떻게 보면 당연한 일입니다.
조직의 선택
다만, 이에 대한 대응이 기술적으로 적절하지 않았습니다. 회사에서는 더 빠르게 일을 추진하기 위해 도메인 팀에 있어야 할 비즈니스 로직의 일부를 BFF 레이어에서 담당하는 방향으로 이야기가 진행되었습니다.
대안으로는 BFF 레이어의 개발자를 해당 도메인 팀에 임시로 투입한다던가 일정을 조정하는 방법 정도가 있었겠지만, 피쳐 릴리즈 날짜만 놓고 본다면 이 방법이 제일 빠르고 간단했을 것이라는 점에는 저도 동의합니다.
얻은 것과 잃은 것
조직은 당장 더 속도를 낼 수 있었습니다.
그리고 원칙을 어긴 점에 대한 부채를 쌓아가기 시작했습니다.
위기
원칙
MSA의 대전제는 구성하는 마이크로서비스들이 상호배제적 & 전체포괄적 (MECE) 해야 한다는 것입니다.
도메인 서비스와 BFF 레이어 양쪽에 (심지어 클라이언트에도) 도메인 로직이 존재하게 되면서, 이 팀은 도메인 로직은 오직 해당 도메인 서비스에서 담당해야 한다는 MSA의 원칙을 어겼습니다.
한번 어긴 원칙은 계속 어기기 마련
이미 물꼬는 트였습니다.
한번 이 조정을 성공적이라고 판단한 기획자들 및 일부 엔지니어들은 언제고 BFF 레이어에 도메인 로직을 분담시켜 피쳐를 개발하는 것을 검토하였습니다.
엔지니어들이 좋지 않은 방향이라고 항변하더라도, 그때는 됐는데 왜 지금은 안되냐는 주장에 강하게 반발하기 어렵습니다. 당장 어떤 지표에 악영향이 드러나는 것은 아니기 때문입니다.
그렇게 관성이 된다
시간이 지나, 어느 순간부터 당연하다는듯 원칙을 어기며 이렇게 말을 합니다.
"저희 원래 그렇게 해왔는데요?"
결말
예견된 재앙
특정 비즈니스 도메인... X 라고 하겠습니다.
X는 더이상 단일 시스템 속에서 파악할 수 없습니다.
X는 복수의 서비스에서 담당하게 되어 그로부터 비롯되는 피쳐 추가/변경의 전체적인 개발 공수 및 커뮤니케이션 비용이 격리가 잘 된 타 도메인에 비해 말도 안 될 정도로 커졌습니다.
X는 사고에 취약합니다.
X를 담당하는 복수의 팀의 엔지니어들은 X 관련 작업에 추가적인 스트레스를 받습니다.
돌이키기에는 너무나 큰 작업이 되었습니다.
원칙을 어기며 아꼈던 일정이나 리소스의 몇곱절을 투입해야 합니다.
이 상황을 예견했던 사람들은 이 점에 대해서 언급하지 않습니다.
이야기 해봐야 마음만 아플 뿐입니다.
이 상황을 예견하지 못했던 사람들은 여전히 잘 이해하지 못합니다.
아는만큼 보이는 것이라, 어쩔 수 없습니다.
마치며
혹시 발단 끝의 따옴표에서 소름이 돋으셨을까요? 너무 담백해서 빌드업이 부족했나 싶지만, 저는 스스로 쓰면서도 소름이 돋아서 만족합니다.
엔지니어로서 참 마음아픈 상황입니다. 창업을 해봤기 때문에 time to market 의 중요성은 너무 잘 알지만, 대부분의 비개발자는 엔지니어링 원칙을 어기는 것이 어떤 의미인지 정확하게 이해하지 못합니다.
이는 기술부채 중에서도 굉장히 굵직한 종류로, 중장기적으로 펀더멘털을 심각하게 훼손하는 행위임을 꼭 아셔야 합니다.
