https://bori-note.tistory.com/74
config.ts vs .env 차이 및 함께 사용하는 이유config 없이 .env만 써도 기본적인 앱 구성에는 아무 문제 없음 단점 또는 불편함이 생길 수 있어서 config를 함께 쓰는 걸 권장하는 경우 많음
| 항목 | .env 파일 |
config.ts 파일 |
|---|---|---|
| 목적 | 환경 별 설정 분리 (배포 시 변경) | 앱 내부 공통 설정 코드화 |
| 형태 | 문자열 기반 (REACT_APP_API_URL=...) |
코드 기반 (export const BASE_URL = ...) |
| 사용시기 | CI/CD 환경에서 각 환경에 맞게 주입됨 | 앱 내부에서 조건문 등 로직 반영 가능 |
| 장점 | 민감한 값, URL 등을 .gitignore 가능 |
복잡한 설정 관리 용이 (조건 분기 등) |
.env는 환경별 값을 외부에서 관리하고,
config.ts는 그 값을 가져와 쓰되, fallback이나 추가 조건을 적용할 수 있음
// src/config.ts
export const BASE_URL = process.env.REACT_APP_API_URL || '<http://localhost:3000>'
lib/ 폴더의 목적| 용도 | 설명 |
|---|---|
| 공통 기능 | 앱 전역에서 사용하는 공통 코드 (ex. axios, date-utils, logger) |
| 외부 의존성 래퍼 | 라이브러리(axios, dayjs, i18n, sentry 등)를 래핑하여 앱에 맞게 설정 |
| 설정 초기화 | 인터셉터, 글로벌 에러 처리 등 초기 설정이 필요한 모듈 위치로 적합 |
hooks/, features/와 분리 |
기능별(features) 또는 UI별(components)과 구분해서 역할 분명히 함 |
axios 인터셉터(interceptor)는 말 그대로 "요청(request)" 또는 "응답(response)"이 진행되기 전·후에 가로채서 처리하는 로직
| 종류 | 언제 실행됨 | 용도 예시 |
|---|---|---|
요청 인터셉터 (request) |
axios.get(...), axios.post(...) 등이 실행될 직전에 |
- 토큰 자동 추가 |
response) | API 요청의 응답을 받았을 때 (성공/실패 모두) | - 에러 공통 처리 (401, 500 등)❌ 이렇게 하면 위험함 (무조건 헤더 추가)
api.interceptors.request.use((config) => {
const token = getAdminToken()
config.headers.Authorization = `Bearer ${token}` // 토큰이 null이어도 문자열 붙음
return config
})