localStorage 저장 코드를 함수로 분리해보기: 초보 코드 리뷰 Before & After
1. 주제 소개
초보 프로젝트에서 localStorage는 매우 자주 사용됩니다. 다크모드 상태 저장, 최근 검색어 보관, 임시 폼 데이터 유지 같은 기능을 빠르게 만들 수 있기 때문입니다. 문제는 이 저장/조회 코드가 파일 곳곳에 흩어지기 시작할 때 발생합니다. 어떤 곳에서는 `JSON.stringify`를 쓰고, 다른 곳에서는 문자열 그대로 넣고, 키 이름도 제각각이면 버그가 생겨도 원인을 찾기 어렵습니다. 특히 파싱 오류나 null 처리 누락은 화면이 조용히 깨지는 원인이 됩니다.
이번 글에서는 localStorage 코드를 함수로 분리해 안정성과 가독성을 높이는 방법을 Before & After 관점으로 정리합니다. 핵심은 단순합니다. 저장, 조회, 삭제, 예외 처리 규칙을 한곳에 모으고 앱 로직은 그 함수를 호출만 하게 만든다는 원칙입니다. 이 한 단계만 적용해도 중복 코드는 줄고, 데이터 구조가 바뀔 때 수정 범위가 대폭 줄어듭니다.
2. 핵심 내용
첫 번째 기준은 "키 관리 중앙화"입니다. `"theme"`, `"darkMode"`, `"is_dark"`처럼 같은 의미를 다른 키로 저장하면 상태 충돌이 생깁니다. 상수 객체로 키를 한곳에 선언하면 오타와 중복을 줄일 수 있습니다. 두 번째는 직렬화 규칙 통일입니다. 객체/배열은 저장 시 문자열 변환이 필요하므로 `setItem`과 `getItem`을 직접 호출하기보다 `saveJson`, `loadJson` 같은 래퍼 함수로 감싸는 편이 안전합니다.
세 번째는 기본값 처리입니다. 조회 결과가 없거나 파싱에 실패하면 앱이 멈추지 않도록 기본값을 반환해야 합니다. 예를 들어 `loadJson(key, defaultValue)` 형태를 사용하면 호출부에서 null 분기 코드를 반복하지 않아도 됩니다. 네 번째는 에러 처리와 책임 분리입니다. localStorage 접근은 브라우저 환경, 저장 용량, 사용자 설정에 영향을 받을 수 있습니다. 저장소 접근 레이어에서 try/catch를 처리하면 UI 로직이 훨씬 단순해집니다.
추가로 테스트 가능성도 좋아집니다. 저장 로직이 함수로 분리되어 있으면 모킹이 쉬워져서 단위 테스트와 회귀 검증이 수월합니다. 즉 함수 분리는 코드 스타일 취향이 아니라, 기능 안정성을 확보하는 기술적 선택입니다.
3. 적용 방법
실전에서는 먼저 기존 코드에서 `localStorage` 직접 호출 지점을 검색합니다. 다음으로 `storage.js` 또는 `utils/storage.js` 같은 파일을 만들고 `set`, `get`, `remove`, `clear`와 JSON 전용 헬퍼를 정의합니다. 키는 `STORAGE_KEYS` 상수로 통일하고, 호출부에서는 문자열 키 대신 상수를 사용하게 바꿉니다. 마지막으로 기존 페이지에서 직접 접근 코드를 래퍼 함수 호출로 치환한 뒤, 저장/조회/삭제가 정상 동작하는지 확인합니다.
| 정리 항목 | Before | After |
|---|---|---|
| 키 이름 관리 | 파일마다 문자열 키 직접 입력 | STORAGE_KEYS 상수로 중앙화 |
| 직렬화 처리 | 곳곳에서 stringify/parse 반복 | saveJson/loadJson 함수로 공통화 |
| 예외/기본값 | null 분기와 try/catch가 산재 | 스토리지 유틸에서 일괄 처리 |
| 유지보수성 | 데이터 구조 변경 시 수정 범위 큼 | 함수 내부 수정만으로 대응 가능 |
Before 상태에서는 저장 정책이 바뀔 때 화면별로 코드를 찾아다니며 수정해야 합니다. After 구조에서는 저장소 레이어 한곳만 수정하면 전체에 반영됩니다. 또한 호출부 코드가 `saveTheme`, `loadRecentSearches`처럼 목적 중심으로 읽히기 때문에 협업 시 의사소통이 쉬워집니다. 초보 단계에서 이런 구조를 일찍 익히면 API 응답 캐시나 세션 관리처럼 더 큰 주제로 확장하기도 수월합니다.
4. 정리
localStorage 코드를 함수로 분리하는 작업은 규모가 작아 보여도 실전 효율이 매우 높습니다. 키 중앙화, 직렬화 공통화, 기본값/예외 처리 통일이라는 세 가지만 적용해도 버그 발생률과 수정 비용이 함께 줄어듭니다. 중요한 것은 "앱 로직이 저장소 구현을 몰라도 되게 만드는 구조"입니다. 이렇게 경계를 나누면 코드가 단단해지고, 기능 추가에도 흔들리지 않습니다. 좋은 코드는 빠르게 만드는 코드가 아니라, 다음 변경에서도 안전하게 유지되는 코드입니다.
5. 자주 묻는 질문
Q1. 작은 프로젝트인데도 유틸 분리가 필요할까요?
처음에는 과해 보일 수 있지만, localStorage를 두세 곳 이상 쓰기 시작하면 바로 이점이 생깁니다. 중복 제거와 오류 방지를 위해 작은 프로젝트일수록 초기에 분리하는 편이 유리합니다.
Q2. localStorage 대신 sessionStorage를 써도 같은 방식이 가능한가요?
가능합니다. 인터페이스가 비슷하므로 저장소 객체만 교체하거나 옵션으로 분기하면 동일한 래퍼 구조를 그대로 재사용할 수 있습니다.
Q3. JSON 파싱 오류는 어떻게 안전하게 처리하나요?
조회 함수 내부에서 try/catch로 감싸고 실패 시 기본값을 반환하면 됩니다. 호출부가 예외 처리에 끌려가지 않게 만드는 것이 핵심입니다.