사내 테크 밋업 진행 후기(우아한 세미나 12월)
밋업이 열리게 된 계기
며칠 전 우아콘을 다녀오고나서 마이크로 프론트에 대한 세미나를 듣고 강의 내용들을 정리하여 동료들에게 공유했었는데 보기 드문 주제다 보니 백엔드, 프론트 팀 가리지 않고 매우 흥미를 가지고 이야기를 나눴었다. 그땐 좀 아쉬웠던 건 중 하나가 우아콘에서만 세션을 진행했었기에 나를 제외한 다른 분들은 강의를 듣지 못했고 내가 이해하지 못했던 부분에 대해 제대로 설명드리지 못한 것 같아 아쉬움이 많이 남았었다.
그러다 마침 우아콘에서 백엔드, 프론트에서 가장 인기가 많았던 주문 시스템의 MSA의 전환과 마이크로 프론트엔드 도입에 대해 주제로 온라인 세미나를 주최한다는 것을 프론트엔드 개발자 분을 통해 알게되었다. 방대한 모놀리식에 묶여있는 우리의 시스템은 당장은 마이크로 프론트를 도입하기는 어려웠지만 이러한 기술의 트렌드와 실제 도입 사례는 간접적으로도 많이 도움이 될 것이라는 생각에 밋업을 열어 진행하기로 했다.
주문 시스템 아키텍쳐의 변화
배민은 음식의 주문을 중계해주는 플랫폼이다보니 점심시간과 저녁에 트래픽이 엄청 증가하게 되는 특징을 가지고 있었다. 거기에서 대량으로 발생하는 트랜잭션은 우아한 형제 매출에 핵심이였기 때문에 안정적인 시스템을 필요로 했었다. 그때의 배민은 루비라는 중앙 집중 스토리지에 다양한 서비스들이 붙어있었기에 다른 서비스로 인해 장애가 발생했을 때 전체적으로 장애가 발생하는 문제가 있었다.
이런 문제를 지속적으로 가져가기에는 배민의 고객 경험과 매출에도 악영향을 끼쳤기 때문에 주문 도메인에 대해 완전한 아키텍처 분리를 최우선 과제로 가져갔었다고 이야기를 했었다. 그래서 중앙 집중 스토리지에 저장하는 방식에서 분산 스토리지 시스템으로 개편하고 메시지 큐를 통해 이벤트 기반 통신으로 개편했지만 주문은 배민앱의 핵심 도메인 중 하나였기 때문에 MSA로 분리하는 것 말고도 다양한 요인들을 신경썼어야 했다.
여기서 문제들은 대용량 데이터, 대규모 트랜잭션, 복잡한 이벤트 아키텍처에 대한 문제를 가지고 있었지만 조회 성능을 개선하기 위해 조회용 데이터를 따로 저장하도록 NoSQL을 도입했었고 대규모 트랜잭션에서 발생하는 문제는 주문이 저장될 때 여러 대의 디비에 하나씩 번갈아가면서 균등하게 저장하도록 하여 개선했었다. 그리고 유지보수를 복잡하게 만드는 중구난방인 이벤트 아키텍처는 단일화된 어플리케이션으로 보내도록 개선하여 문제를 해결했었다.
이러한 개선을 하고자 하는 노력들 덕분에 외부 서비스에서 발생하는 장애에 영향을 받지 않도록 격리할 수 있었으며 문제가 발생했을 때 빠르게 발견하고 대응할 수 있게 되었다. 30분 정도되는 세미나로 간단하게 정리하여 설명했지만 그안에는 정말 많은 일들이 있었을 것이다. 배포했을 때 발생할 수 있는 사이드 이펙트와 장애를 어떻게 최소화할 것인지 고려했을 것이고 IT와 관련이 먼 직원들에게도 설득을 하는 과정도들도 거쳤을 것이다. 물론 이런 과정에서 시스템 개편으로 발생하는 버그나 장애에 대해 못마땅한 부분도 있을 것이고 이런 작업들이 왜 중요한지 설득되지 못한 부분들도 있을 것이다.
하지만 두걸음 앞으로 가기위해 한걸음 물러설 수 있도록 믿어주고 지원해주는 우아한 형제들의 조직 문화에 대해서도 대단하다는 생각이 좀 들었었다. 이세션을 듣고나서 우리는 단순히 인사이트를 넘어서 직접 실행해보고 경험한 사례들을 들려줄 수 있을지에 대해 좀 고심하게 되었고 그런 생각들이 스쳐지나갈 때 쯤 다음 세션이 진행되었다.
마이크로 프론트 아키텍처의 도입
가장 메인이 될 수 있는 세션이라고도 이야기할 수 있었다. 그 이유는 현재 우리의 서비스에서 관리자 페이지는 대부분이 서버 템플릿 엔진으로 구성되어 있었고 접근 권한이나 기능에 대해서도 복잡하게 얽혀있었기 때문에 이런 부분을 개선하기 위해서는 도메인이나 사업의 방향을 중심으로 관리자 페이지를 분리해야 된다는 이야기가 나왔기 때문이다.
배민도 우리가 나아가야 하는 기술적 환경은 이미 구축 되어 있었고 거기에서 더 나아가 분리된 도메인 서비스들을 통합하여 관리할 수 있는 어드민 페이지를 고민했다. '통합된 프로젝트로 합쳐서 관리하면 되지 않을까?' 생각할 수 있겠지만 그렇게 된다면 장애의 격리, 독립된 배포, 의존성 없는 개발 등 많은 것을 포기하면서 서로 팀의 커뮤니케이션의 비용도 증가하고 개발 속도도 저하되면서 앞으로 가기위해 후퇴하는 것이 아니라 기술부채를 만드는 방법이기 때문에 각각의 독립된 프로젝트들을 합치지 않고 통합적으로 관리할 수 있는 방법이 필요했다.
배민에서 마이크로프론트를 도입하면서 가장 중요하게 생각했던 부분은 트레이드 오프였는데 프론트에서는 백엔드와 달리 마이크로 프론트의 개념이 나온지도 얼마 안되었었고 높은 러닝 커브 또한 컸기때문에 당장 도입했다가는 오히려 오버 엔지니어링으로 인한 골치아픈 기술부채가 될 수 있었다. 하지만 지금 배민은 유지보수하는데 발생하는 커뮤니케이션의 비용이 증가가 더 컸기 때문에 마이크로 프론트를 도입했다.
마이크로 프론트의 문제
마이크로 프론트의 첫번째 문제점은 서로 다른 프론트 서버끼리 어떻게 정보를 공유하느냐였다. 세미나에 설명해주는 해결 방법은 다음과 같았다.
- Props 활용
- Storage API 활용
- Custom Event 활용
- Custom Event Message Bus 활용
Props를 활용하는 방법은 가장 익숙한 방법이지만 리액트라는 프레임워크에 종속되어 사용하기 때문에 확장성의 불리했고 Storage API는 웹 브라우저 내부 스토리지에 종속되기 때문에 확장이 어렵고 보안에 취약했다. Custom Event는 비동기적으로 호출하기 때문에 확장에 용이했지만 구조화를 시켜서 관리하기 어려운 점이 있었고 그런 문제를 해결하는 것이 구조화된 Message Bus를 활용하는 방법이였다.
호스트 웹 어플리케이션에서 리모트 웹 어플리케이션을 호출하여 동적으로 로드하는 Module Federation을 활용하여 마이크로 프론트를 구축했는데 여기서의 문제점은 아래와 같았다.
- 시스템의 복잡성 증가: dependency, Versioning 관리가 주기적으로 필요. 개발 및 운영 난이도 증가봉
- 보안 취약점: 어플리케이션 간 코드가 동적으로 로드되어 공유되기 때문에 보안 취약점 증가
- 잠재적 성능 장애: 프로덕션 레벨로 활용되어진 사례가 많지 않고 그에따른 레퍼런스도 별로 없다보니 잠재적으로 성능에 이슈가 발생할 가능성이 있음
그외에도 타입스크립트 이슈, 양방향 통신 미지원, 버전마다 다른 버그 해결 방법 등이 있었고 다양한 이슈 해결한 끝에 마이크로 프론트 아키텍처를 전시 서비스를 관리하는데에 성공적으로 도입할 수 있었다고 한다. 그로 인해 얻었던 것은 비지니스의 요구사항과 기술적 욕구를 동시에 충족한 사례를 만들어내면서 개발팀과 비개발팀 모두에게 신뢰를 얻을 수 있었고 잃었던 것은 시스템의 단순함을 포기함으로써 유지보수하는데에 이전 보다 많은 비용이 든다는 점이였다.
우리의 토론 스토리
우리는 세미나를 들었던 내용들을 주제로 토론을 진행했었는데 그 중 토론 중 흥미로웠던 것은 세미나를 듣기 전과 들은 후에 입장이 바뀐채로 동료들이 이야기를 해주었기 때문이다. 그 중 가장 큰 이유 중 하나는 생각보다 높은 러닝커브였다. 다양한 번들링에 대한 지식외에도 Next.js, RollUp.js, Webpack, Module Federation 등이 필요했었고 원활하게 연동하기 위한 다양한 Configuration에 대해 알고 있어야 했기 때문에 현재 우리 프로덕트에 도입하기에는 어려울 것 같다는 의견이 대부분이였다.
그리고 또 거론되었던 것 중 하나는 아직은 자리를 잡고 있는 단계의 기술이였기 때문에 유저들이 사용하는 프로덕트에 도입하기에는 어려움이 있다는 것이였다. 실제로 안정적인 서비스를 제공해야하는 환경에서 아직 자리 잡지 못한 기술스택들을 활용하는 것은 리스크가 컸기에 배민 또한 유저 사이드에는 활용하지 못한 것 같다. 라는 이야기를 나눴다. 이부분에 대해서는 나도 크게 동의하는 부분이였기 때문에 옹호하는 입장이였다.
그렇게 우리는 1시간정도 토론들을 이어갔었다. 현재 우리 서비스의 방대한 기술부채들을 개선하는데 리소스를 할당하기 어려운 상황이다보니 토론이 진행될수록 보람찬 것보다는 아쉬움이 더 커지는 자리였다. 그런 아쉬움을 뒤로 우리는 현재 진행된 밋업에 대해서 후기를 나누는 시간을 가졌고 그런 아쉬움이 커지더라도 이런 자리를 가지는 것은 매우 의미있는 자리라고 이야기를 해주셨다. 결국은 아는 것이 힘이고 알고 못하는 것과 모르고 못하는 것은 차이가 크기 때문에 앞으로도 이런 자리를 만들면 좋을 것 같다. 라고 이야기를 해주셔서 조금은 희망찬 미래를 꿈 꿀 수 있었다.
정리하면서
회사가 커지면서 더 크게 성장하기 위해 프로덕트에 대한 고도화가 필요하고 경제가 어려울 때에는 안정적으로 운영하기 위한 새로운 BM이 필요하다고 말한다. 이런 상황속에서 개발자가 지금 기술부채를 개선하고 리스크를 관리해야된다. 라고 말하는 것은 정말 쉽지 않은 것 같다.
이전에 작은 개발팀에 있을 때에는 소수였기 때문에 각각의 동료들을 설득하고 이해시키는데에는 생각보다 큰 힘과 시간이 들지 않았지만 지금은 팀규모가 더 커지고 이해관계가 엮인 사람들이 많아지면서 이런 기술부채를 해결 해야하는 이유에 대해 설명하여 설득시키고 조율하는 과정이 점점 힘들고 복잡해지면서 개선하는 것보다 모두를 이해시키고 신뢰를 얻는 시간이 더 어려운 것 같다.
하지만 주변에 이런 기술 부채들을 개선하고 우리의 조직 문화를 한층 더 높은 수준으로 끌어올리기 위해 노력하고 있는 동료들이 있기 때문에 손놓고 구경만 할 수는 없을 것 같다. 그래서 신년의 계획은 사이드 프로젝트와 스터디를 통해 다가올 미래를 대비하면서 점진적으로 프로덕트를 개편할 계획이다.