1.
미리캔버스 에디터: 스마일캣의 코드를 전신으로 만들어진 서비스
2.
미리캔버스 2.0 → 에디터 엔진과 분리
•
기존: 바닐라 자바스크립트와 클래스 컴포넌트로 구성된 리액트로 개발하고 있었음
3.
MFE로의 전환
•
하나의 장애가 모든 서비스 장애로 퍼지지 않도록
4.
SEO 최적화와 frontend server 최적화
•
해외에서도 빠르게 동작하는 서비스를 만들기 위해서 서버사이드에서 동작하는 코드를 만들게 됨
5.
빠르게 성장하면서 겪은 문제들
•
하나의 큰 서비스, 50명이 넘는 개발자
•
CI/CD의 효율 저하, 사이드 이펙트 확장: 레거시를 쌓는 속도가 레거시 해결 속도보다 빠름
•
애자일 조직과 맞지 않는 개발 사이클
•
강결합되는 비즈니스 로직과 복잡도 증가
6.
이를 해결하기 위해서 마이크로프론트엔드로의 전환
•
모노레포 환경으로 변경
•
정적 페이지와 SSR 페이지 구분
•
모듈 분리, 애자일하게 일할 수 있도록 조직구조 개편
•
서비스를 잘 만들 수밖에 없는 구조로 만들자.
•
MFE로 전환하는 동안, 스쿼드에서는 계속 레거시를 쌓음. → 회사에서는 안 기다려줌…
7.
플랫폼 엔지니어링 직군 도입
•
플랫폼 엔지니어링: DX를 향상시킬 수 있게 내부 플랫폼을 구축하고 설계하는 일을 함.
•
점점 복잡해지는 모노레포를 어떻게 관리해야할까
◦
MFE로 전환하자, 수십개의 모듈이 생김.
◦
하나의 모듈을 변경했을 때 다른 모듈로의 전파가 생김
▪
모듈을 만들 때 레이어를 나눠서 개발
◦
하지만 여전히 개발자가 한 모듈을 개발했을 때 어디에 사이드이펙트가 생길지 모름
▪
그래서 CLI로 의존성 전파 트리를 제공
◦
모듈을 작게 유지하지만 배포 단위, 캐싱 단위, 테스트 과정에 대한 가이드를 플랫폼에서 제공
•
점점 복잡해지는 서비스 아키텍처도 관리하자
•
콘웨이 법칙 → 역 콘웨이 법칙: 원하는 시스템 아키텍처를 얻기 위해, 그에 맞는 조직구조를 먼저 설계하고 변화시켜라.
◦
MFE 를 만드는 팀을 만들고 여기서 발생하는 문제를 플랫폼으로 해결하기.
8.
플랫폼 엔지니어링의 목표
•
self service portal
•
문제를 추상화해서 기능으로 제공한다. → 배포를 어떻게 하고, 어떻게 캐싱해야하는지
무엇을 경험했는가
1.
플랫폼 팀 구성 자체가 어려웠음
•
데브옵스 + 프론트엔드
•
플랫폼을 도입하는 이유를 이해시키기 어렵다.
•
프론트엔드 플랫폼으로 채용이 어렵다.
•
수정사항의 영향도가 서비스 전체에 영향을 끼침.
◦
eslint 느림 → biome
◦
observability 제공
2.
효율적으로 변경되는 프로세스
•
변경의 전파가 적어서 CI/CD를 비롯한 모든 게 빨라짐
•
내가 작성한 코드가 발생시키는 사이드이펙트 감소
3.
아직 해결하지 못한 문제
•
서비스의 복잡도를 해결하기 위해 플랫폼을 만들었는데, 이젠 플랫폼 자체가 복잡해짐
•
플랫폼 자체의 블랙박스화
Q&A
•
모듈을 나누는 기준: FSD처럼 레이어 구조를 가지고 있음
◦
feature: 기능. UI가 존재하지 않음 → 레이어 단위에서 변경의 전파를 끊어준다.
◦
fragment: 유저 플로우. UI → 배포 단위
◦
application: feature + fragment 결합
•
모노레포: pnpm workspace + turbo (빌드 최적화)
◦
runtime에 동작하는 모듈까지도 의존성 트리를 그리기 위해서 observability 도구를 직접 만듦
AI가 일을 잘할 수 있는 환경 만들기?!
