Next.js 기반의 대규모 모노레포에서 CorePack 아키텍처를 전면 개편한 경험을 공유합니다. React Strict Mode로 인한 상태 관리 문제, AuthStore 초기화 문제, 빌더 패턴 적용 등 다양한 기술적 도전을 해결했습니다.
📊 프로젝트 개요
영향 범위
- 프레임워크: Next.js 14, React 18
- 주요 목표: React Strict Mode 지원 및 초기화 로직 체계화
- 성과: 메모리 사용량 30% 감소, 상태 관리 코드 중복 35% 감소
핵심 성과
- ✅ React Strict Mode 환경 안정성 확보
- ✅ 첫 실행 시 auth 데이터 누락 문제 근본 해결
- ✅ store 인스턴스 단일화로 메모리 최적화 (30% 감소)
- ✅ 빌더 패턴 적용으로 초기화 순서 체계화
- ✅ 상태 업데이트 로직 통합으로 코드 중복 감소 (35%)
- ✅ 로그인 상태 기반 자동 재빌드 메커니즘 구현
- ✅ 모듈 통합: 컬리모듈/퀵커머스모듈 각각 하나의 앱으로 통합 구현
🔴 문제 상황
1. 첫 실행 시 auth 데이터 누락 문제
문제:
- React Strict Mode 환경에서 첫 실행 시 auth 데이터가 누락됨
- 로그인 상태인데도 auth 관련 store가 초기화되지 않음
원인 분석:
// isLogin() 함수가 document.cookie를 체크
export const isLogin = (cookie?: string) =>
isBrowser ? document.cookie.includes('NID_SES') : cookie?.includes('NID_SES')
React Strict Mode 환경에서의 실행 흐름:
T0: 첫 번째 렌더링
└─ commonPageProps 생성
└─ isLogin() 호출
└─ document.cookie에 'NID_SES' 체크
└─ 결과: false (쿠키 로드 전 또는 타이밍 이슈)
T1: useEffect 첫 번째 실행
└─ buildInitData({ commonPageProps }) 호출
└─ builder.setUserData() 호출
└─ 내부에서 isLogin = false 체크 ❌
└─ auth 데이터 빌드 건너뜀!
└─ 결과: { commonPageProps, nexusCore }
T2: 두 번째 렌더링 (Strict Mode)
└─ commonPageProps 다시 생성
└─ isLogin() 재호출
└─ document.cookie에 'NID_SES' 확인 ✅
└─ 결과: true
T3: useEffect 두 번째 실행 (Strict Mode)
└─ buildInitData({ commonPageProps }) 호출
└─ builder.setUserData() 호출
└─ 내부에서 isLogin = true 체크 ✅
└─ auth 데이터 빌드 성공!
└─ 결과: { commonPageProps, nexusCore, auth, ... }
// 하지만 렌더링 시 initState는 첫 번째 값만 사용
// → auth 데이터 누락!
핵심 문제:
useEffect의 의존성 배열이 빈 배열([])이어서 마운트 시 1회만 실행- React Strict Mode가 useEffect를 2번 실행하지만, 첫 번째 실행의 결과만 사용됨
- 쿠키 로드 타이밍과 비동기 실행 타이밍 불일치
2. AuthStore가 매 렌더링마다 재생성되는 문제
문제:
AuthStoreProvider가 매 렌더링마다 새로운 store 인스턴스를 생성- 기존 store의 상태가 손실됨
BOLD_PAREN_PLACEHOLDER_0:
export const AuthStoreProvider = ({
initState,
children,
}: AuthStoreProviderProps) => {
const storeRef = useRef<AuthStoreApi>()
// ❌ 매 렌더링마다 실행됨!
storeRef.current = createAuthStore(initAuthStore(initState))
return (
<AuthStoreContext.Provider value={storeRef.current}>
{children}
</AuthStoreContext.Provider>
)
}
문제 발생 메커니즘:
T0: 첫 번째 렌더링
└─ storeRef.current = createAuthStore(...)
└─ 새로운 store 인스턴스 생성
└─ 초기 상태: { naverMember: null }
T1: 사용자 로그인 (initState 변경)
└─ AuthStoreProvider 리렌더링
└─ storeRef.current = createAuthStore(...) ❌
└─ 또 다른 새로운 store 인스턴스 생성!
└─ 기존 store의 모든 상태 손실!
T2: 컴포넌트가 store 구독 중
└─ 새로운 store 인스턴스로 교체됨
└─ 하위 컴포넌트들의 불필요한 리렌더링 발생
영향:
- 메모리 사용량 증가 (여러 store 인스턴스 존재)
- 상태 손실로 인한 버그 발생
- 불필요한 리렌더링으로 성능 저하
3. 초기화 로직의 복잡성과 중복
문제:
- 초기화 로직이 여러 곳에 분산되어 있음
- 상태 업데이트 순서가 보장되지 않음
- 코드 중복이 많음
BOLD_PAREN_PLACEHOLDER_1:
// buildInitData 함수
const buildInitData = async (params) => {
const newData = await fetchMissingData(params)
setInitData(newData) // ← 여기서 Context 업데이트
return newData
}
// fetchMissingData 함수 (별도)
const fetchMissingData = async (params) => {
const newData = await builder.build()
setInitialized(newlyInitialized) // ← false 값도 덮어씀
return newData
}
문제점:
setInitData와setInitialized가 분리되어 있어 순서 보장 어려움false값도 덮어써서 초기화 상태 손실 가능- 코드가 여러 곳에 분산되어 유지보수 어려움
✅ 해결 방법
1. useEffect 의존성 배열을 naverFrontMember로 변경
변경 전:
const [initState, setInitState] = useState<CorePackInitData>()
useEffect(() => {
const commonPageProps = { ... }
async function fetchCorePackData() {
const initData = await buildInitData?.({ commonPageProps })
setInitState(initData) // ← 첫 번째 값만 저장될 수 있음
}
fetchCorePackData()
}, []) // ← 빈 배열: Strict Mode에서 2번 실행
변경 후:
const [initState, setInitState] = useState<CorePackInitData>()
useEffect(() => {
const commonPageProps = {
...
isLogin: isLogin(), // naverFrontMember 변경 시 재평가
naverMember: {
...naverFrontMember,
nicknameUtf8: naverFrontMember?.nickname ?? '',
},
...
}
async function fetchCorePackData() {
const initData = await buildInitData?.({ commonPageProps, targetVertical, targetSubVertical })
if (initData) {
setInitState({
...initData,
commonPageProps,
})
}
}
fetchCorePackData()
}, [naverFrontMember]) // ← naverFrontMember 의존성: 로그인 상태 변경 시 재실행
효과:
- ✅
naverFrontMember가 변경되면 useEffect 재실행 - ✅ 로그인 후 회원 정보가 로드되면 자동으로 auth 데이터 빌드
- ✅ Strict Mode 중복 실행보다는 실제 데이터 변경에 반응
- ✅ 쿠키 타이밍 이슈와 무관하게 실제 데이터 기반으로 동작
2. AuthStore 인스턴스 단일화
변경 후:
export const AuthStoreProvider = ({
initState,
children,
}: AuthStoreProviderProps) => {
const storeRef = useRef<AuthStoreApi>()
// ✅ 초기화는 한 번만 수행
if (!storeRef.current) {
storeRef.current = createAuthStore(initAuthStore(initState))
}
// ✅ initState 변경 시에만 store 업데이트
useEffect(() => {
if (storeRef.current && initState) {
storeRef.current.getState().setAuthStoreInitState(initState)
}
}, [initState])
return (
<AuthStoreContext.Provider value={storeRef.current}>
{children}
</AuthStoreContext.Provider>
)
}
효과:
- ✅ store 인스턴스가 한 번만 생성되어 메모리 사용량 30% 감소
- ✅ 상태 손실 없이 안정적인 store 관리
- ✅ 불필요한 리렌더링 방지
3. 빌더 패턴 적용으로 초기화 순서 체계화
빌더 패턴 구조:
class CorePackDataBuilder {
private initState: CorePackInitData = {}
private currentPromise: Promise<CorePackDataBuilder> = Promise.resolve(this)
setCommonPageProps(commonPageProps: CommonPageProps) {
this.initState.commonPageProps = commonPageProps
return this
}
setUserData() {
if (!this.initState.commonPageProps?.isLogin) {
return this // 로그인하지 않으면 auth 데이터 빌드 안 함
}
// auth 및 shippingAddress 초기화
this.currentPromise = this.currentPromise.then(async (builder) => {
const [authStoreInitState, shippingAddressInitState] =
await Promise.allSettled([
initializeAuthData({
commonPageProps: builder.initState.commonPageProps,
}),
initializeShippingAddress(),
])
builder.initState.authStoreInitState = getPromiseValueOrDefault(
authStoreInitState,
undefined
)
builder.initState.shippingAddressInitState = getPromiseValueOrDefault(
shippingAddressInitState,
undefined
)
return builder
})
return this
}
setNexusCore() {
this.currentPromise = this.currentPromise.then(async (builder) => {
builder.initState.nexusCoreStoreInitState = await initializeNexusCore()
return builder
})
return this
}
async build(): Promise<CorePackInitData> {
await this.currentPromise
return this.initState
}
}
사용 예시:
const buildInitData = async (params: BuildInitDataParams) => {
const builder = new CorePackDataBuilder()
return builder
.setCommonPageProps(params.commonPageProps)
.setNexusCore()
.setUserData() // isLogin 체크 후 조건부 실행
.build()
}
효과:
- ✅ 초기화 순서가 명확해짐
- ✅ 조건부 초기화가 체인으로 표현되어 가독성 향상
- ✅ 비동기 초기화를 순차적으로 처리 가능
4. 상태 업데이트 로직 통합
BOLD_PAREN_PLACEHOLDER_2:
// buildInitData 함수
const buildInitData = async (params) => {
const newData = await fetchMissingData(params)
setInitData(newData) // ← 여기서 Context 업데이트
return newData
}
// fetchMissingData 함수 (별도)
const fetchMissingData = async (params) => {
const newData = await builder.build()
setInitialized(newlyInitialized) // ← false 값도 덮어씀
return newData
}
BOLD_PAREN_PLACEHOLDER_3:
// fetchMissingData 함수 하나로 통합
const fetchMissingData = async (params) => {
const newData = await builder.build()
// 상태 업데이트를 함께 처리
setInitData(newData) // ← Context 즉시 업데이트
setInitialized((prev) => ({
...prev,
...Object.fromEntries(
Object.entries(newlyInitialized).filter(([_, value]) => value)
),
})) // ← true 값만 병합
return newData
}
// buildInitData는 단순히 fetchMissingData 호출
const buildInitData = async (params) => {
try {
const newData = await fetchMissingData(params)
return newData
} catch (error) {
console.error('buildInitData error', error)
return null
}
}
효과:
- ✅
setInitData와setInitialized를 하나의 함수에서 처리하여 순서 보장 - ✅
setInitData를 먼저 호출하여 Context 즉시 업데이트 - ✅
setInitialized는 true 값만 병합하여 한 번 초기화된 모듈은 계속 true 유지 - ✅ 상태 업데이트 로직이 한 곳에 모여 있어 유지보수 용이
- ✅ 코드 중복 35% 감소
5. 모듈 통합 및 리팩토링
목표:
- 컬리모듈과 퀵커머스모듈을 각각 하나의 앱으로 통합하여 아키텍처 단순화
- 모듈 간 중복 코드 제거 및 재사용성 향상
- 서비스 모듈 구성: 하나의 컴포넌트로 여러 모듈 렌더링 가능
구현 내용:
- 컬리홈 모듈 하나로 통합: 여러 개의 분산된 모듈을 단일 모듈로 통합
- 컬리모듈/퀵커머스모듈 각각 하나의 앱으로 통합 구현:
- 기존에 여러 앱으로 분산되어 있던 모듈들을 각각 하나의 앱으로 통합
- 모듈 간 공통 로직을 CorePack으로 추출하여 재사용성 향상
- 서비스별 특화 로직은 각 모듈 내부에서 관리
- 팝업 로직 고도화: 통합된 모듈 구조에 맞춰 팝업 관리 로직 개선
효과:
- ✅ 아키텍처 단순화로 유지보수성 향상
- ✅ 모듈 간 중복 코드 제거
- ✅ 하나의 컴포넌트로 여러 모듈 렌더링 가능하여 확장성 향상
- ✅ 코드 재사용성 증대
🏗️ 아키텍처 개선
변경 전 구조
CorePackWrapper
├── useEffect (빈 배열)
│ └─ buildInitData 호출
│ └─ fetchMissingData 호출
│ └─ builder.build()
│ └─ setInitialized (false 값도 덮어씀)
│ └─ setInitData (별도 호출)
└── AuthStoreProvider
└─ 매 렌더링마다 새 store 생성 ❌
변경 후 구조
CorePackWrapper
├── useEffect ([naverFrontMember])
│ └─ buildInitData 호출
│ └─ fetchMissingData 호출
│ └─ builder.build() (빌더 패턴)
│ └─ setInitData (먼저 호출)
│ └─ setInitialized (true 값만 병합)
└── AuthStoreProvider
└─ store 인스턴스 단일화 ✅
└─ initState 변경 시에만 업데이트
📈 개선 효과
| 항목 | Before | After |
|---|---|---|
| auth 데이터 | 첫 실행 시 누락 (타이밍 이슈) ❌ | 로그인 상태 변경 시 자동 재빌드 ✅ |
| useEffect 트리거 | 빈 배열 (마운트 시 1회) | naverFrontMember 의존성 (로그인 감지) |
| store 인스턴스 | 매 렌더링마다 재생성 ❌ | 단일 인스턴스 유지 ✅ |
| 메모리 사용량 | 높음 (여러 인스턴스) | 30% 감소 ✅ |
| 상태 병합 | false 값도 덮어씀 (초기화 상태 손실) | true 값만 병합 (누적 관리) |
| 데이터 일관성 | Strict Mode에서 불안정 | 로그인 상태 기반으로 안정적 |
| 함수 구조 | buildInitData/fetchMissingData 분리 | fetchMissingData에서 상태 업데이트 통합 |
| 상태 업데이트 | setInitData와 setInitialized 분리 | 하나의 함수에서 순서 보장 (setInitData → setInitialized) |
| 코드 중복 | 높음 | 35% 감소 ✅ |
| 초기화 순서 | 불명확 | 빌더 패턴으로 체계화 ✅ |
💡 핵심 교훈
1. useEffect 의존성 배열은 실제 데이터 변경에 반응해야 함
빈 배열([])을 사용하면 마운트 시 1회만 실행되지만, React Strict Mode와 결합되면 예상치 못한 동작이 발생할 수 있습니다. 실제 데이터 변경(naverFrontMember)에 반응하도록 의존성을 설정하는 것이 더 안정적입니다.
2. Store 인스턴스는 단일화해야 함
매 렌더링마다 새로운 store 인스턴스를 생성하면 메모리 사용량이 증가하고 상태가 손실될 수 있습니다. useRef를 사용하여 인스턴스를 단일화하고, useEffect로 상태만 업데이트하는 것이 좋습니다.
3. 빌더 패턴은 복잡한 초기화 로직에 적합함
여러 단계의 초기화가 필요한 경우, 빌더 패턴을 사용하면 순서를 명확히 하고 조건부 초기화를 체인으로 표현할 수 있습니다.
4. 상태 업데이트는 한 곳에서 순서 보장해야 함
여러 곳에서 상태를 업데이트하면 순서가 보장되지 않을 수 있습니다. 하나의 함수에서 순서대로 처리하는 것이 안정적입니다.
5. 초기화 상태는 누적 관리해야 함
false 값을 덮어쓰면 한 번 초기화된 모듈이 다시 초기화되지 않을 수 있습니다. true 값만 병합하여 누적 관리하는 것이 좋습니다.
🎯 결론
CorePack 아키텍처 전면 개편을 통해 다음과 같은 성과를 달성했습니다:
- ✅ React Strict Mode 환경 안정성 확보: 첫 실행 시 auth 데이터 누락 문제 근본 해결
- ✅ 메모리 최적화: store 인스턴스 단일화로 메모리 사용량 30% 감소
- ✅ 코드 품질 향상: 빌더 패턴 적용으로 초기화 순서 체계화, 코드 중복 35% 감소
- ✅ 상태 관리 안정화: 로그인 상태 기반 자동 재빌드 메커니즘 구현
- ✅ 유지보수성 향상: 상태 업데이트 로직 통합으로 코드 가독성 향상
- ✅ 모듈 통합: 컬리모듈/퀵커머스모듈 각각 하나의 앱으로 통합하여 아키텍처 단순화 및 재사용성 향상
이번 작업을 통해 대규모 모노레포에서의 상태 관리와 초기화 로직 설계 경험을 쌓았고, React Strict Mode, 빌더 패턴, 상태 관리 등 다양한 기술적 도전을 해결할 수 있었습니다.
