24.02.04~24.02.11

업무

extension 아키텍처 설계

지난주 업무의 연장!

extension UX 개선본 와이어프레임에 기반해, 애플리케이션 아키텍처를 설계했다.

 

extension service 기준 모듈 구조

extension 개발 특성상 각 서비스 별로 사용되는 자원들이 크게 달랐고

이를 반영해 각 자원들을

background(service worker), content script, pop up, sidepanel의 네 가지 구성 요소로 나누었다.

 

2개 이상의 서비스에서 사용되는 공통 모듈(api, interface, hooks, module, service 등)들을 제외한

나머지 자원들은 해당 서비스 내 폴더에 위치 + 서비스 내부에서만 사용한다는 원칙을 세웠고,

이를 통해 ver 1 extension을 개발할 때 느꼈던

각 서비스 모듈 간 재사용 단위의 구분이 어려워, 개발자 각각의 기준에 의존적인 모듈이 작성되었던 문제를 해결하고자 했다.

 

chrome API 공통 service 작성

extension의 경우 일반적인 웹 개발과 달리

각 서비스에 message를 보낸다거나, extension의 storage에 읽기/쓰기가 발생하는 등

chrome API에 의존적인 기능을 구현할 때가 많다.

 

이전 버전 개발에서는 chrome API를 각 서비스 별 사용처에서 직접 호출해 사용했는데,

이로 인해 API 별로 사용되는 공통 로직이 반복적으로 하드코딩 되고

각 API 들의 입력/반환값 타입 추론이 불가능했으며

특정 기능을 수행하거나, 데이터 조작 시, 어떤 방법을 사용해야하는지 파악하기가 어렵다는 문제가 있었다.

interface StorageUpdateServiceInterface {
  accessToken: (token: string) => Promise<void>;
  phase: (phase: PhaseType) => Promise<void>;
}

/**
 * @description storage내 데이터 업데이트 함수 제공 service
 */
export const storageUpdateService: StorageUpdateServiceInterface = {
  accessToken,
  phase,
};

이를 해결하기 위해, chrome API를 사용하는 기능 별 service 모듈을 작성해 제공했다.

 

API 간 공통 사용 로직은 해당 service 내부에 작성하고

입력/반환값에 대한 타입을 지정하면서

  const handleSave = async () => {
    try {
      storageUpdateService.updatePhase("SHARE_GUIDE");
    } catch (e) {
      storageUpdateService.updatePhase("PENDING");
    }
  };

사용처에서는 해당 service를 import 해, 필요한 기능을 선언적으로 사용할 수 있도록 했다.

 

데이터 flow 설계

애플리케이션 구성 데이터를 크게

1) 각 service별 공유 필요

2) service별 공유 불필요 의 두 가지 성질로 구분했다.

 

'현재 진행 상황', '선택된 요소 id' 등은 각 service별로 공유가 필요했고

이러한 데이터는 chrome storage API를 사용해 모든 service에서 접근할 수 있도록 했다.

(각 데이터 상태를 관리하는 hooks를 작성, chrome storage를 조작하고 이벤트 리스너를 할당했다!)

 

side panel, content script 등에 존재하는 데이터는

state를 통해 해당 컴포넌트 레벨에 상태를 격리하거나,

zustand를 통해 prop drilling을 피하고 해당 service 하위 컴포넌트에서 접근할 수 있도록 했다.

 

Admin 페이지 기능 개발

admin 페이지를 개발했고, 그 중에서도 인증/인가 관련 작업을 진행했다.

 

Cookie를 이용해 server와 access token, refresh token을 공유했고

Next js의 middleware를 통해 각 Next 서버 요청 간 사용자의 인증 여부를 검사했다.

 

회고

변칙은 탄탄한 윈칙 위에서만 유효하다

지난 주 회고!

지난주, 기본 설계 필요성과 관련해 팀원들을 어떻게 설득할 수 있을까 고민했다.

개발뿐만 아니라 다른 직종의 사람들과 이에 대한 고민을 나누었는데...

그중에서도 가장 인상 깊었던 대답 → 변칙은 윈칙 위에서만 유효하다!

 

어차피 변경될 것이니, 전체 설계가 그렇게 중요하지 않다는 팀원의 얘기에 왜 찜찜함이 남았을까?

본질적인 이유는... 그것이 소프트웨어 원칙, 즉 기본 이론에 어긋나기 때문이었다!

 

설계 없는 구현은 무질서함을 낳고, 그 무질서함은 유지 보수의 어려움으로 이어진다.

수많은 소프트웨어 이론들이 이러한 배경 위에서 등장했고...

이를 반대로 말하자면

이러한 이론들을 어기는 순간 선배 개발자들이 겪었던 문제점을 그대로 답습할 가능성은 기하급수적으로 커진다!

 

즉 애플리케이션 정책의 변경 가능성이 크다라는 상황 위에서는

'기초 설계 후 개발한다' 라는 원칙 위에서

'변경 사항 발생 시, 어떻게 유연하게 대처할 것인가'라는 변칙이 등장해야지,

'기초 설계를 하지 않는다'라는 변칙이 등장해선 안된다.

 

물론 기본 원칙(이론)이 100% 정답이라 말할 수는 없다.

하지만 내가 겪은 문제처럼

'이럴 수도 있고 저럴 수도 있는 사항(51% vs 49%)',

'아무도 경험하지 못한 상황' 에서 어떠한 결정을 내려야 할 경우...

그 근거는 반드시 탄탄한 원칙 위에 존재해야만 한다.