채팅 코어와 캐릭터 이미지를 함께 프로젝트에 추가한 경험
목차
채팅 코어를 추가하면서 동시에 캐릭터 셀카 이미지를 프로젝트에 정식 자산으로 등재했다. 한 커밋에 기능(코드)과 미디어(자산)를 함께 담으면서, 프로젝트 구조를 한 단계 더 정리한 경험을 정리해본다.
채팅 기능의 기반 구축
package.json과 next.config.ts 변경이 함께 들어갔다. 아마도 채팅을 지탱할 새로운 라이브러리(소켓 통신, 메시징 큐, 실시간 업데이트 관련)를 도입했을 테고, Next.js 설정에서 그 라이브러리를 올바르게 빌드/번들링하도록 조정했을 것 같다. 특히 일반적으로 실시간 통신 라이브러리는 특정 번들러 설정이나 폴리필을 요구하는 경우가 많다.
이 시점에 자주 놓치는 부분이 있다. 기능 개발에만 집중하다 보면, 해당 의존성이 개발 환경과 프로덕션 환경에서 동일하게 작동하는지 검증하지 않는 경우가 있다. 특히 Next.js 같은 메타 프레임워크에서는 클라이언트 사이드 렌더링, 서버 사이드 렌더링, 정적 생성 모드가 모두 다르게 작동하기 때문에, 새 의존성이 추가될 때마다 각 시나리오를 점검하는 습관이 중요하다.
변경 영역 및 목적
package.json, package-lock.json
→ 채팅 의존성 추가/업그레이드
next.config.ts
→ 번들러/트랜스파일 설정 조정
(라이브러리 호환성 확보)
캐릭터 이미지를 정식 자산으로 등재
public/media/char/haru.jpg, public/media/char/minjun.jpg 두 파일이 커밋에 포함됐다. 캐릭터 이미지를 프로젝트 저장소에 직접 포함시킨 것인데, 이건 단순히 "이미지 추가"가 아니라 여러 의사결정이 담겨 있다.
정적 자산을 버전 관리에 포함시키는 선택:
- 장점: 배포 시 별도 CDN/미디어 서버 설정 불필요. 빌드 시점에 모든 자산이 준비됨. 버전 관리가 코드와 일관성 있음.
- 단점: 저장소 크기 증가. 바이너리 파일은 diff/merge 추적 어려움. 이미지 변경이 코드 PR과 섞임.
팀 규모나 배포 구조에 따라 이 선택이 달라진다. 초기 단계일수록 저장소에 포함시키는 게 운영 복잡도를 낮춘다. 규모가 커지면 별도 스토리지로 분리하는 게 나중에 마이그레이션 고통을 줄인다.
.gitignore 조정의 의미
.gitignore 파일이 함께 수정됐다는 건, 캐릭터 이미지를 추가하면서 "뭔가는 제외"하려고 한다는 뜻이다. 예를 들어:
- 로컬 빌드 산출물 추가 (.next, build/)
- 캐릭터 에셋 중 원본/작업본은 무시하고 최종본만 추가
- 환경변수나 설정 파일 조정
이렇게 자산을 추가할 때 .gitignore 를 점검하는 습관은 중요하다. 자칫 불필요한 파일이 누적되거나, 반대로 필요한 파일이 실수로 제외되곤 한다. 특히 다른 팀원들이 첫 클론 후 "왜 이미지가 없지?" 하는 상황을 방지해야 한다.
회고: 기능과 자산을 함께 관리하는 경험
이 커밋의 핵심은 "단계+2"라는 진전 지표다. 아마도 로드맵상 마일스톤 두 개를 함께 진행하거나, 의존성 버전이 메이저 업그레이드되거나, 아니면 팀의 기능 단계가 한 발 더 나아갔다는 뜻일 것 같다.
한 커밋 안에 코드 변경(package.json, next.config.ts)과 자산 추가(이미지 파일)를 섞을 때는, 다음 몇 가지를 점검하는 게 좋다:
- 의존성 변경과 설정의 일관성: 새 라이브러리 추가 → next.config 조정까지 한 세트로 테스트했는가
- 자산의 최적화: 이미지 파일이 프로덕션에 적합한 포맷/해상도인가
- 문서화: 팀원이 같은 구조로 새 자산을 추가할 때 참고할 가이드가 있는가
코드 리뷰 입장에서도, 이런 혼합형 커밋은 "정말 이 모든 게 한 기능과 연관되는가"를 묻는 게 좋다. 불필요하게 큰 커밋은 나중에 문제 추적이나 롤백을 어렵게 한다. 다만 이 경우처럼 채팅 기능의 기반(의존성)과 UI 자산(캐릭터 이미지)이 진정한 한 피처라면, 함께 그룹핑하는 게 오히려 히스토리를 명확하게 한다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.