안녕하세요. 인프랩 프론트엔드 개발자 고슈입니다. 작년 8월, 인프런의 헤더(GNB… ||
안녕하세요. 인프랩 프론트엔드 개발자 고슈입니다.
작년 8월, 인프런의 헤더(GNB)가 새롭게 단장했습니다! 
인프런의 헤더는 여러 프론트엔드 환경에서 동작해야 하는 복잡한 구조로 이루어져 있어, 기존에도 여러 문제가 있었는데요.
이번 글에서는 인프런의 헤더가 어떻게 동작하고 있는지, 그리고 어떤 과정을 거치며 문제를 해결해 나갔는지를 담아 보았습니다.
1. 헤더를 왜 개편하게 되었는가
기존 헤더
개편된 헤더
인프런의 헤더는 런칭 이래로 변경된 적이 거의 없었는데요.
서비스가 추가될 때마다 기존 구조에 끼워 넣기만 하다 보니, 핵심 서비스가 명확하게 드러나지 않는 상태였습니다.
현재 인프런은 강의, 챌린지, 멘토링, 클립, 커뮤니티를 핵심 서비스로 정의하고 있습니다.
이번 프로젝트의 목표는 이 핵심 서비스들을 헤더에서 명확하게 노출하고, 사용자가 직관적으로 탐색·검색·구매·학습할 수 있도록 개선하는 것이었습니다.
디자인 개편 자체는 이미 완료되었지만, 그 과정이 단순하지만은 않았는데요.
이어지는 내용에서는 이 헤더가 동작하고 있는 MFE 환경의 구조와, 그 안에서 마주한 기술적 문제들을 하나씩 풀어 보겠습니다.
2. MFE 아키텍처와 Module Federation
2-1. 인프랩 팀의 프론트엔드 아키텍처
모놀리식 아키텍처에서 도메인 별로 프로젝트 분리
모놀리식에서 도메인 분리로
초기 인프런은 내부에서 Antman이라 부르는, 자체 자바스크립트 프레임워크 기반의 모놀리식 프로젝트로 서비스를 운영하고 있었는데요.
서비스 규모가 커지면서 개발자 수도 늘고, 빌드 속도도 느려지기 시작했습니다.
가장 큰 문제는 하나의 서버에 프론트엔드와 백엔드가 함께 올라가 있다 보니, 한쪽에서 장애가 발생하면 서비스 전체가 마비된다는 점이었습니다.
이를 해결하기 위해 리액트로 마이그레이션을 진행하면서, 도메인별로 프로젝트를 분리하게 되었습니다.
프론트엔드 기준으로 모노레포도 있고, 폴리레포(싱글레포)도 있고, 형태는 다양하지만 각 도메인이 독립적으로 운영되는 마이크로프론트엔드(MFE)구조입니다.
이렇게 분리된 애플리케이션들은 리버스 프록시를 통해 하나의 서비스로 동작하고 있습니다.
사용자가 접속한 URL 경로에 따라 프록시가 적절한 애플리케이션으로 요청을 라우팅해 주는 방식인데요.
리버스 프록시란, 클라이언트의 요청을 받아 내부의 여러 서버 중 적절한 곳으로 전달해 주는 중간 서버입니다. 사용자는 하나의 도메인에 접속하지만, 실제로는 뒤에 있는 여러 애플리케이션 중 하나가 응답하게 됩니다.
백엔드 역시 서버가 분리되면서 한쪽 장애가 전체로 퍼지는 문제는 해소되었고, 프론트엔드 관점에서도 각 애플리케이션이 독립적으로 빌드·배포되기 때문에 런타임 오류나 배포 실패가 다른 서비스에 영향을 주지 않게 되었습니다.
패키지별로 다양한 환경을 구성할 수 있고, 코드 충돌도 줄어들었습니다.
분리했더니, 더 바빠졌다
하지만 공통으로 사용하는 컴포넌트가 있는 경우엔, 변경할 때마다 모든 패키지에 반영하고 배포해야 한다는 번거로움이 있었는데요.
특히 헤더가 대표적이었습니다.
헤더는 여러 서비스가 추가되고 실험이 이루어지면서 변경이 빈번했습니다.
헤더를 한 번 수정하면 다음과 같은 과정을 거칩니다.
레거시 Antman 쪽 헤더 코드 수정 및 배포
리액트 헤더 공통 모듈 코드 수정 및 배포
공통 모듈을 사용하는 각 도메인 패키지 업데이트 및 배포
즉, 공통 모듈을 사용하는 패키지가 10개라면, 10개 모두 배포해야 하는 셈이었습니다.
이 문제를 해결하기 위해 몇 가지 방법을 검토했습니다.
방법 1: 서버 사이드 컴포지션
프론트엔드 전용 서버를 두고, 그곳에서 헤더와 각 애플리케이션의 결과물을 조합하여 하나의 HTML로 렌더링해 내려주는 방식입니다.
하지만 모든 트래픽이 한 서버에 집중되고, 해당 서버에 장애가 생기면 모든 페이지가 마비된다는 단점이 있었습니다.
방법 2: CI/CD 디스패치를 통한 자동 배
인프런의 헤더는 여러 프론트엔드 환경에서 동작해야 하는 복잡한 구조로 이루어져 있어, 기존에도 여러 문제가 있었는데요.
이번 글에서는 인프런의 헤더가 어떻게 동작하고 있는지, 그리고 어떤 과정을 거치며 문제를 해결해 나갔는지를 담아 보았습니다.
1. 헤더를 왜 개편하게 되었는가
기존 헤더
개편된 헤더
인프런의 헤더는 런칭 이래로 변경된 적이 거의 없었는데요.
서비스가 추가될 때마다 기존 구조에 끼워 넣기만 하다 보니, 핵심 서비스가 명확하게 드러나지 않는 상태였습니다.
현재 인프런은 강의, 챌린지, 멘토링, 클립, 커뮤니티를 핵심 서비스로 정의하고 있습니다.
이번 프로젝트의 목표는 이 핵심 서비스들을 헤더에서 명확하게 노출하고, 사용자가 직관적으로 탐색·검색·구매·학습할 수 있도록 개선하는 것이었습니다.
디자인 개편 자체는 이미 완료되었지만, 그 과정이 단순하지만은 않았는데요.
이어지는 내용에서는 이 헤더가 동작하고 있는 MFE 환경의 구조와, 그 안에서 마주한 기술적 문제들을 하나씩 풀어 보겠습니다.
2. MFE 아키텍처와 Module Federation
2-1. 인프랩 팀의 프론트엔드 아키텍처
모놀리식 아키텍처에서 도메인 별로 프로젝트 분리
모놀리식에서 도메인 분리로
초기 인프런은 내부에서 Antman이라 부르는, 자체 자바스크립트 프레임워크 기반의 모놀리식 프로젝트로 서비스를 운영하고 있었는데요.
서비스 규모가 커지면서 개발자 수도 늘고, 빌드 속도도 느려지기 시작했습니다.
가장 큰 문제는 하나의 서버에 프론트엔드와 백엔드가 함께 올라가 있다 보니, 한쪽에서 장애가 발생하면 서비스 전체가 마비된다는 점이었습니다.
이를 해결하기 위해 리액트로 마이그레이션을 진행하면서, 도메인별로 프로젝트를 분리하게 되었습니다.
프론트엔드 기준으로 모노레포도 있고, 폴리레포(싱글레포)도 있고, 형태는 다양하지만 각 도메인이 독립적으로 운영되는 마이크로프론트엔드(MFE)구조입니다.
이렇게 분리된 애플리케이션들은 리버스 프록시를 통해 하나의 서비스로 동작하고 있습니다.
사용자가 접속한 URL 경로에 따라 프록시가 적절한 애플리케이션으로 요청을 라우팅해 주는 방식인데요.
리버스 프록시란, 클라이언트의 요청을 받아 내부의 여러 서버 중 적절한 곳으로 전달해 주는 중간 서버입니다. 사용자는 하나의 도메인에 접속하지만, 실제로는 뒤에 있는 여러 애플리케이션 중 하나가 응답하게 됩니다.
백엔드 역시 서버가 분리되면서 한쪽 장애가 전체로 퍼지는 문제는 해소되었고, 프론트엔드 관점에서도 각 애플리케이션이 독립적으로 빌드·배포되기 때문에 런타임 오류나 배포 실패가 다른 서비스에 영향을 주지 않게 되었습니다.
패키지별로 다양한 환경을 구성할 수 있고, 코드 충돌도 줄어들었습니다.
분리했더니, 더 바빠졌다
하지만 공통으로 사용하는 컴포넌트가 있는 경우엔, 변경할 때마다 모든 패키지에 반영하고 배포해야 한다는 번거로움이 있었는데요.
특히 헤더가 대표적이었습니다.
헤더는 여러 서비스가 추가되고 실험이 이루어지면서 변경이 빈번했습니다.
헤더를 한 번 수정하면 다음과 같은 과정을 거칩니다.
레거시 Antman 쪽 헤더 코드 수정 및 배포
리액트 헤더 공통 모듈 코드 수정 및 배포
공통 모듈을 사용하는 각 도메인 패키지 업데이트 및 배포
즉, 공통 모듈을 사용하는 패키지가 10개라면, 10개 모두 배포해야 하는 셈이었습니다.
이 문제를 해결하기 위해 몇 가지 방법을 검토했습니다.
방법 1: 서버 사이드 컴포지션
프론트엔드 전용 서버를 두고, 그곳에서 헤더와 각 애플리케이션의 결과물을 조합하여 하나의 HTML로 렌더링해 내려주는 방식입니다.
하지만 모든 트래픽이 한 서버에 집중되고, 해당 서버에 장애가 생기면 모든 페이지가 마비된다는 단점이 있었습니다.
방법 2: CI/CD 디스패치를 통한 자동 배