wrapper 패턴으로 라이브러리 의존성 관리하기 (feat. expo-av deprecated)

🤔 도입부

react-native로 모바일앱을 개발하고 있었는데, 이번 프로젝트는 expo로 개발하기로 했다. 개발 속도를 최대한 단축하고 싶었기 때문이다.

오디오 기능을 사용하기 위해서, expo-av라는 라이브러리를 사용하게 되었는데, ai가 제안한 코드를 보았을 때 처음보는 패턴을 보았다. 그것은 외부 라이브러리를 그대로 쓰지 않고 hook으로 한 번 더 감싸서 사용하는 패턴이었다.

나는

왜 굳이 wrapper를 쓰면서, 코드의 분량을 늘리는거지?

라는 생각을 했다.

그런데, 생각보다 빨리 그 이유를 알 수 있었다.

💣 문제상황: expo-av is deprecated

앱을 만들다가 expo-av가 deprecated된 것을 뒤늦게 발견했다. 따라서 expo-audio라는걸 대신 사용해야 한다고 한다.

AI랑 작업하느라 공식 문서 확인을 소홀히 한 실수였다.

✅ 솔루션: wrapper 덕분에 10분 만에 해결

만약 이 때 프로젝트 전체에 expo-av를 직접 import 했다면, 10개의 파일을 하나하나 찾아가며 수정해야 했을 것이다.

다행히 wrapper 덕분에 10분만에 마이그레이션을 완료할 수 있었다.

// 라이브러리 직접 사용
import { Audio } from 'expo-av';
const sound = await Audio.Sound.createAsync(...);

// wrapper hook 사용
import { useAudioPlayer } from '@/hooks/useAudioPlayer';
const { play, pause } = useAudioPlayer();

wrapper를 쓰면

• 라이브러리가 바뀌어도 useAudioPlayer.ts 파일 하나만 수정
• 나머지 코드는 건드릴 필요 없음
• 테스트할 때 useAudioPlayer만 mock 하면 됨

내 wrapper 코드

// ... import

/**
 * useAudioPlayer.ts
 * 오디오 재생 관련 훅 및 설정 함수
 */

interface UseAudioPlayerReturn {
  isPlaying: boolean;
  play: () => void;
  pause: () => void; 
  // ... 기타 메서드
}

// expo audio에서 필요한 함수를 정의하는 훅
export const useAudioPlayer = (initialSource?: string): UseAudioPlayerReturn => {
  const player = useExpoAudioPlayer(initialSource);
  const status = useAudioPlayerStatus(player);

  const loadTrack = (track: Meditation) => {
    player.replace(track.audioUri);
  };

  const play = () => {
    player.play();
  };

  const pause = () => {
    player.pause();
  };

  const stop = () => {
    player.pause();
    player.seekTo(0);
  };

  const seekTo = (positionSeconds: number) => {
    player.seekTo(positionSeconds);
  };

  return {
    isPlaying: status.playing,
    isLoaded: status.isLoaded,
    currentTime: status.currentTime,
    duration: status.duration,
    play,
    pause,
    stop,
    seekTo,
    loadTrack,
  };
};
...

💬 그렇다면 wrapper는 언제 써야 할까?

wrapper가 필요한 경우:

• 핵심 비즈니스 로직과 연관된 라이브러리: 결제, 인증, 오디오/비디오 같은 핵심 기능
• 변동 가능성이 있는 라이브러리: deprecated 위험, 활발한 개발로 API 변경 가능성
• 여러 곳에서 사용되는 라이브러리: 3개 이상 파일에서 쓰면 wrapper 고려

wrapper 없이 써도 되는 경우:

• 안정적이고 표준인 라이브러리: lodash, date-fns 같은 유틸리티
• 한두 곳에서만 쓰는 라이브러리: 굳이 wrapper 만들 필요 없음
• React/React Native 코어 기능: useState, useEffect 같은 기본 hook

🤞 마무리: wrapper의 trade-off

장점:

• 라이브러리 교체가 쉬움 (내 경험처럼)
• 유지보수 비용 감소
• 테스트 용이

단점:

• 초기 작업 시간 추가 (wrapper 만드는 시간)
• 코드 한 단계 추가 (wrapper layer)

한줄 요약:

핵심 기능에 가까우면 wrapper 만들고, 아니면 필요할 때 리팩토링하기로