피드로 돌아가기
Dev.toFrontend
원문 읽기
Clean Architecture 도입으로 Chrome Extension의 복잡한 컨텍스트 제어 및 심사 통과 달성
We Built a Chrome Extension With Clean Architecture. Here's Why It Was Worth the Extra Effort.
AI 요약
Context
Background Worker, Side Panel, Content Scripts 등 3가지 실행 컨텍스트가 공존하는 브라우저 확장 프로그램의 구조적 복잡성 직면. Chrome API 의존성 및 상태 관리 로직이 혼재되어 테스트 불가능하고 유지보수가 어려운 스파게티 코드 위험 존재.
Technical Solution
- Domain, Application, Infrastructure, Presentation 4개 계층으로 분리하여 의존성 방향을 도메인 중심으로 단방향 설정
- Port-Adapter 패턴 적용을 통해 Chrome API 및 HTTP Client를 인터페이스화하여 구체적인 구현체와 비즈니스 로직을 완전히 분리
- Use Case 중심의 Application Layer 설계로 복잡한 OAuth PKCE 및 Content Script 주입 프로세스를 원자적 단위로 캡슐화
- Result 타입을 통한 명시적 에러 처리 구조를 도입하여 레이어 간 예외 전파를 차단하고 타입 안정성 확보
- Immutability 기반의 AuthSession 엔티티 설계로 비동기 작업 중 세션 상태 변이로 인한 사이드 이펙트 방지
- WXT 프레임워크와 Vitest를 활용하여 인프라 의존성 없는 Use Case 단위의 독립적 테스트 환경 구축
실천 포인트
- 브라우저 API처럼 외부 변경 가능성이 높은 의존성은 반드시 Interface(Port)로 추상화했는가? - 비즈니스 로직이 UI 프레임워크(React)나 플랫폼 API(chrome.*)에 직접 의존하고 있지 않은가? - 에러 처리를 Exception이 아닌 명시적인 Return Type(Result)으로 관리하여 흐름을 제어하고 있는가? - 각 권한(Permission) 요청의 근거를 단일 책임 원칙(SRP)에 따라 특정 어댑터 파일로 매핑할 수 있는가?