□ Frontend Architecture
1. Frontend Architecture란?
- Web Application의 구조적 설계
; 코드 구성, 컴포넌트 설계, 데이터 흐름, 상태 관리 등
2. Architecture가 중요한 이유?
- 확장성: 규모 확장 및 기능 추가 용이
- 유지보수성: 코드 이해도↑
- 개발자 경험: 일관된 코드 구조 제공, 협업 원활화
- 성능↑
3. 잘 설계되지 않은 Application은?
- 유지보수가 점점 어려워지고
- 기능 추가 및 변경이 어려워짐
□ Monolithic Architecture
1. Monolithic?
- 단일 코드베이스로 구성된 F/E Application
- 하나의 Application 내에 모든 기능 통합
- 단일 빌드 프로세스와 배포
2. Monolithic 장점
- 개발 단순성: 단일 코드베이스 -> 개발 · 배포 편함, 일관된 개발 환경
- 쉬운 디버깅: 전체 Application 흐름 추적 용이
- 초기 개발 속도 빠름: 빠른 프로토타이핑 및 개발 가능
- 간편 배포: 하나의 단위로 빌드 및 배포
3. Monolithic 한계
- 확장성 제한: 코드베이스 증가에 따른 복잡성 증가
- 기술 유연성↓: 전체 Application이 동일한 스택 사용
- 배포 속도↓, 확장성↓
4. Monolithic 관리 전략
- 컴포넌트 재사용: 중복 최소화를 위한 공유 컴포넌트 설계
- 점진적 업그레이드: 부분적 개선
- 모듈화: 내부적으로 명확한 모듈 경계 설정
5. 적합한 사용 사례
- 기술 복잡도가 낮은 소규모 프로젝트
- MVP 수준의 단일 비즈니스 도메인
- 빠르고 간단하게 기능 개발 및 배포가 필요한 경우
□ F/E MSA (Micro Frontend Architecture)
1. Micro Frontend?
- Application을 작은 독립 모듈로 분할하여 각 모듈이 독립적으로 개발, 배포
- 각 모듈은 독립적으로 동작
2. Micro Fronted 장점
- 독립적인 개발/배포: 자율성 증가, 배포 주기 단축
- 기술 유연성↑: 모듈별 독립적인 기술 스택 적용 가능
- 확장성↑: 전체 시스템의 복잡성↓
- 유지 관리 안정성↑
3. Micro Fronted 한계
- 개발 복잡성↑: 통합 매커니즘 관리 필요
- 성능 이슈: 중복 코드, 모듈 간 통신으로 인한 추가적인 네트워크 오버헤드
- 초기 개발 속도↓
4. 적합한 사용 사례
- 기술적 복잡도가 높은 대규모 Application
- 명확한 비즈니스 도메인 경계가 있는 서비스
- 점진적 마이그레이션이 필요한 레거시 시스템
□ F/E Architecture 주요 패턴
1. F/E Architecture 패턴?
- Application의 구조를 정의하는 설계 방식
- 데이터 흐름, 상태관리, UI 랜더링과 같은 핵심적인 문제들을 해결하는데 도움
2. MVC/MVVM/MVP
- MVC(Model-View-Controller): 데이터, UI, 비즈니스 로직 분리
- MVVM(Model-View-ViewModel): 양방향 데이터 바인딩, UI 상태 관리 용이
- MVP(Model-View-Presenter): View와 로직의 분리, 테스트 용이성↑
3. Flux Architecture
- 단방향 데이터 흐름을 강조하는 패턴
- Action -> Dispatcher -> Store -> View의 단방향 사이클
- 상태 예측 가능성↑, 디버깅 용이성↑
- Redux, Vuex 등
4. 컴포넌트 기반 Architecture
- UI를 독립적이고 재사용 가능한 컴포넌트로 분해
- 컴포넌트 계층 구조로 Application 구성
- 재사용성↑, 테스트 및 유지보수 용이성↑
- React, Vue, Angular 등
5. JAMstack Architecture
- JavaScript, API, Markup
- 빌드 시점에 정적 파일 생성, CDN으로 배포
- 보안성↑, 성능↑, 확장성↑
- Gatsby, Next.js, Nuxt.js 등
6. Island Architecture
- 정적 HTML 내 상호작용 가능한 ‘섬(Island)’ 배치
- 필요한 부분만 Hydration 적용
- 초기 로딩 성능↑, 번들 크기↓
- Astro, Marko 등
□ Repository 구조
- 코드의 일관성 유지, 개발 속도 향상, 배포 효율성에 큰 영향
1. Monorepo?
- 모든 모듈을 단일 저장소에서 관리
- 코드베이스가 물리적으로 한곳에 위치, 논리적으로 분리
- 공통된 빌드 시스템, 의존성 관리, 테스트 환경 공유
2. Monorepo 장점
- 의존성 공유, 모든 모듈을 같은 Repository에서 관리
- 환경 통일성: 모든 모듈이 동일한 개발 환경 공유
3. Monorepo 한계
- 모듈 간 의존성↑, 독립적인 배포 어려움
- 확장성 제한: 모듈이 증가할수록 의존성 충돌 및 빌드 시간↑
4. Multirepo?
- 각 모듈이 독립된 저장소에서 관리
- 각 모듈이 분리된 코드베이스, 빌드 시스템, 배포 파이프라인 보유
- 모듈간 의존성이 명시적으로 관리
5. Multirepo 장점
- 모듈 독립성↑: 각 모듈의 자율성 보장
6. Multireop 한계
- 통합 복잡성↑: 여러 repository 통합 과정의 복잡
- 의존성 관리 어려움: 모듈 간 의존성 추적 및 버전 관리 복잡
□ Architecture 선택 가이드
1. Architecture 선택 기준
- 프로젝트 규모와 복잡도
- 비즈니스 요구사항과 도메인 특성
- 기술 스택 선호도 및 팀 경험
- 유지보수 및 확장성 요구사항
2. F/E Architecture trend
- 서버 컴포넌트와 하이브리드 렌더링
- Hydration 최적화
- 타입 안정성 강화
- 상태관리 간소화
- 빌드 도구 고도화
□ 결론: Architecture는 진화하는 것
- 처음부터 완벽한 Architecture 설계 보다는 점진적 개선
- 비즈니스와 기술 환경 변화에 따라 유연하게 대응
- 정기적인 리뷰와 리팩토링을 통한 지속적인 개선
- Architecture는 목적이 아닌 수단
⭐발표자 : 이현주님
□ Frontend Architecture
1. Frontend Architecture란?
- Web Application의 구조적 설계
; 코드 구성, 컴포넌트 설계, 데이터 흐름, 상태 관리 등
2. Architecture가 중요한 이유?
- 확장성: 규모 확장 및 기능 추가 용이
- 유지보수성: 코드 이해도↑
- 개발자 경험: 일관된 코드 구조 제공, 협업 원활화
- 성능↑
3. 잘 설계되지 않은 Application은?
- 유지보수가 점점 어려워지고
- 기능 추가 및 변경이 어려워짐
□ Monolithic Architecture
1. Monolithic?
- 단일 코드베이스로 구성된 F/E Application
- 하나의 Application 내에 모든 기능 통합
- 단일 빌드 프로세스와 배포
2. Monolithic 장점
- 개발 단순성: 단일 코드베이스 -> 개발 · 배포 편함, 일관된 개발 환경
- 쉬운 디버깅: 전체 Application 흐름 추적 용이
- 초기 개발 속도 빠름: 빠른 프로토타이핑 및 개발 가능
- 간편 배포: 하나의 단위로 빌드 및 배포
3. Monolithic 한계
- 확장성 제한: 코드베이스 증가에 따른 복잡성 증가
- 기술 유연성↓: 전체 Application이 동일한 스택 사용
- 배포 속도↓, 확장성↓
4. Monolithic 관리 전략
- 컴포넌트 재사용: 중복 최소화를 위한 공유 컴포넌트 설계
- 점진적 업그레이드: 부분적 개선
- 모듈화: 내부적으로 명확한 모듈 경계 설정
5. 적합한 사용 사례
- 기술 복잡도가 낮은 소규모 프로젝트
- MVP 수준의 단일 비즈니스 도메인
- 빠르고 간단하게 기능 개발 및 배포가 필요한 경우
□ F/E MSA (Micro Frontend Architecture)
1. Micro Frontend?
- Application을 작은 독립 모듈로 분할하여 각 모듈이 독립적으로 개발, 배포
- 각 모듈은 독립적으로 동작
2. Micro Fronted 장점
- 독립적인 개발/배포: 자율성 증가, 배포 주기 단축
- 기술 유연성↑: 모듈별 독립적인 기술 스택 적용 가능
- 확장성↑: 전체 시스템의 복잡성↓
- 유지 관리 안정성↑
3. Micro Fronted 한계
- 개발 복잡성↑: 통합 매커니즘 관리 필요
- 성능 이슈: 중복 코드, 모듈 간 통신으로 인한 추가적인 네트워크 오버헤드
- 초기 개발 속도↓
4. 적합한 사용 사례
- 기술적 복잡도가 높은 대규모 Application
- 명확한 비즈니스 도메인 경계가 있는 서비스
- 점진적 마이그레이션이 필요한 레거시 시스템
□ F/E Architecture 주요 패턴
1. F/E Architecture 패턴?
- Application의 구조를 정의하는 설계 방식
- 데이터 흐름, 상태관리, UI 랜더링과 같은 핵심적인 문제들을 해결하는데 도움
2. MVC/MVVM/MVP
- MVC(Model-View-Controller): 데이터, UI, 비즈니스 로직 분리
- MVVM(Model-View-ViewModel): 양방향 데이터 바인딩, UI 상태 관리 용이
- MVP(Model-View-Presenter): View와 로직의 분리, 테스트 용이성↑
3. Flux Architecture
- 단방향 데이터 흐름을 강조하는 패턴
- Action -> Dispatcher -> Store -> View의 단방향 사이클
- 상태 예측 가능성↑, 디버깅 용이성↑
- Redux, Vuex 등
4. 컴포넌트 기반 Architecture
- UI를 독립적이고 재사용 가능한 컴포넌트로 분해
- 컴포넌트 계층 구조로 Application 구성
- 재사용성↑, 테스트 및 유지보수 용이성↑
- React, Vue, Angular 등
5. JAMstack Architecture
- JavaScript, API, Markup
- 빌드 시점에 정적 파일 생성, CDN으로 배포
- 보안성↑, 성능↑, 확장성↑
- Gatsby, Next.js, Nuxt.js 등
6. Island Architecture
- 정적 HTML 내 상호작용 가능한 ‘섬(Island)’ 배치
- 필요한 부분만 Hydration 적용
- 초기 로딩 성능↑, 번들 크기↓
- Astro, Marko 등
□ Repository 구조
- 코드의 일관성 유지, 개발 속도 향상, 배포 효율성에 큰 영향
1. Monorepo?
- 모든 모듈을 단일 저장소에서 관리
- 코드베이스가 물리적으로 한곳에 위치, 논리적으로 분리
- 공통된 빌드 시스템, 의존성 관리, 테스트 환경 공유
2. Monorepo 장점
- 의존성 공유, 모든 모듈을 같은 Repository에서 관리
- 환경 통일성: 모든 모듈이 동일한 개발 환경 공유
3. Monorepo 한계
- 모듈 간 의존성↑, 독립적인 배포 어려움
- 확장성 제한: 모듈이 증가할수록 의존성 충돌 및 빌드 시간↑
4. Multirepo?
- 각 모듈이 독립된 저장소에서 관리
- 각 모듈이 분리된 코드베이스, 빌드 시스템, 배포 파이프라인 보유
- 모듈간 의존성이 명시적으로 관리
5. Multirepo 장점
- 모듈 독립성↑: 각 모듈의 자율성 보장
6. Multireop 한계
- 통합 복잡성↑: 여러 repository 통합 과정의 복잡
- 의존성 관리 어려움: 모듈 간 의존성 추적 및 버전 관리 복잡
□ Architecture 선택 가이드
1. Architecture 선택 기준
- 프로젝트 규모와 복잡도
- 비즈니스 요구사항과 도메인 특성
- 기술 스택 선호도 및 팀 경험
- 유지보수 및 확장성 요구사항
2. F/E Architecture trend
- 서버 컴포넌트와 하이브리드 렌더링
- Hydration 최적화
- 타입 안정성 강화
- 상태관리 간소화
- 빌드 도구 고도화
□ 결론: Architecture는 진화하는 것
- 처음부터 완벽한 Architecture 설계 보다는 점진적 개선
- 비즈니스와 기술 환경 변화에 따라 유연하게 대응
- 정기적인 리뷰와 리팩토링을 통한 지속적인 개선
- Architecture는 목적이 아닌 수단
⭐발표자 : 이현주님