웹툰 일러스트와 이메일 기능으로 사용자 경험 개선
목차
한 릴리즈에서 시각적 개선, 새 기능, 정책 반영을 동시에 진행했다. 웹툰 일러스트 통합, 리딩 이메일 발송, 그리고 특정 정책 적용이 한 커밋에 담겼다. 이렇게 여러 변화를 함께 배포할 때 팀과 어떻게 협의하고 관리하는지가 중요하다.
여러 개선사항, 함께 배포해야 했던 이유
원칙적으로 기능별로 커밋을 나누는 게 맞다. 하지만 현실에서는 릴리즈 일정, 정책 변경, 의존성 제약이 함께 움직인다. 이번 경우 웹툰 일러스트 UI 개선과 리딩 이메일 기능, 청월당 결 정책이 같은 주기에 나가야 했던 것 같다.
팀 관점에서 이런 결정을 할 때 고려해야 할 점:
- 배포 리스크: 여러 변화가 동시에 가면 이슈 원인 파악이 어려워진다
- 롤백 전략: 한 기능만 제거하고 싶어도 어려울 수 있다
- 코드 리뷰 복잡도: 리뷰어가 에셋, 의존성, 로직을 모두 검토해야 한다
그럼에도 함께 배포하기로 했다면, 그건 이 세 가지 변화가 함께 나가야 서비스의 의도가 완성되기 때문일 거다. 예를 들어 이메일 기능이 새로운 일러스트를 소개하거나, 정책 변경이 이메일 발송 시점에 영향을 줄 수 있다.
작업 내용: 세 가지 변화
1. 웹툰 일러스트 통합
Day Master 10종과 Master Haneul을 새로 추가했다. public/dm/ 디렉토리에 이미지들(byeong.jpg, eul.jpg, gap.jpg, gi.jpg 등)이 들어갔다.
일러스트 에셋 추가는 단순해 보이지만, 팀 내에서 여러 고려사항이 뒤따른다:
- 이미지 최적화: 포맷(JPG vs WebP), 해상도, 파일 크기. 사용자 로딩 성능에 직결
- 반응형 대응: 모바일/데스크톱에서 각각 어떻게 보일 건지
- 캐싱 전략: 기존 사용자에게 새 일러스트가 제때 로드되는지
내 입장에서는 디자인팀이 준 에셋을 받아서 public 폴더에 배치하는 식이지만, 사실 그 뒤에는 로딩 성능, 브라우저 캐시, CDN 배포 등이 연쇄한다. 에셋 하나 추가가 크기가 크면 전체 페이지 로딩을 느리게 할 수 있다.
2. 리딩 이메일 발송 기능 추가
사용자에게 주기적으로 또는 특정 이벤트에 이메일을 보내는 기능이다. 사용자 재참여, 정보 전달, 서비스 재방문을 목표로 한다.
이 기능을 위해서는:
- 이메일 템플릿: HTML/텍스트 템플릿 작성
- 발송 스케줄: 언제, 누구에게 보낼지 로직
- 개인화: 사용자 정보 기반 이메일 커스터마이징
- 결과 추적: 발송 성공/실패 모니터링
package.json 수정은 아마도 이메일 라이브러리나 스케줄링 도구를 추가했다는 뜻이다. 의존성이 늘어나는 건 코드 리뷰 시 주의해야 할 포인트다. 새 라이브러리가 정말 필요한지, 혹은 기존 것으로 대체 가능한지 확인해야 한다.
3. 청월당 결 정책 반영
"청월당 결"이라는 특정 요구사항을 이번 버전에 반영했다. 사용자 정책 변경, UI 일관성, 혹은 내부 지침일 수 있다. 이런 정책은 보통 전역 설정, 데이터 처리, UI 로직 곳곳에 영향을 미친다.
정책 변경이 여러 파일에 퍼져 있으면 코드 리뷰가 더 복잡해진다. 내가 만약 이 PR을 리뷰한다면, "청월당 결"이 정확히 어디서 어떻게 적용되는지 확인하는 데 시간을 들여야 한다.
| 변경 항목 | 역할 | 기술적 영향 |
|---|---|---|
package.json / package-lock.json |
의존성 관리 | 이메일 발송 라이브러리 추가 가능, 팀원 설치 시 일관성 보장 |
public/dm/*.jpg |
웹툰 일러스트 에셋 | 페이지 로딩 성능, 브라우저 캐싱, CDN 배포 영향 |
| (정책 반영 코드) | 청월당 결 적용 | 여러 파일에 산재, 테스트 커버리지 필수 |
여러 변화를 함께 배포할 때 주의점
코드 리뷰 전략
이런 상황에서 PR을 리뷰할 때 나는 다음처럼 한다:
- 커밋 메시지부터 정확히 읽기. "왜 이걸 함께 배포하는가"가 명확해야 한다
- 변화별로 파일 그룹화: 에셋 변경, 의존성 변경, 로직 변경을 따로 검토
- 특히
package.json변경은 함께 추가된 모든 라이브러리를 확인. 보안, 라이선스, 크기 다 본다 - 정책 변경이 모든 필요한 곳에 반영됐는지 검토. 누락된 부분이 있으면 버그가 될 수 있다
배포 후 모니터링
함께 배포되는 변화들은 배포 직후 모니터링이 중요하다:
- 이메일 발송 오류는 없는가? (사용자 불만으로 이어질 수 있음)
- 새 일러스트가 제때 로드되는가? (이미지 배포 지연 확인)
- 정책 변경이 예상 동작을 하는가?
만약 한 부분에서 오류가 나면, 전체를 롤백할지 말 지 빠르게 판단해야 한다.
회고
이번 작업을 통해:
- 릴리즈 주기와 기술 부채의 균형: 여러 개선사항을 한 릴리즈에 담으면 속도는 나지만, 리스크도 커진다. 팀과 함께 이 트레이드오프를 인식하는 게 중요하다
- 에셋도 코드처럼 관리해야 한다: 이미지 파일도 성능, 최적화, 배포 전략이 필요하다
- 의존성 추가는 신중하게: 새 라이브러리 하나가 번들 크기, 보안 취약점, 유지보수 부담을 늘린다
- 정책 변경은 문서화와 함께: 코드만 바뀌고 왜 바뀌었는지 기록이 없으면 나중에 유지보수할 때 혼란스럽다
개인적으로, 다음에 비슷한 상황이 생기면 커밋을 나누되 같은 PR 안에 담는 방식을 고려해볼 것 같다. 그러면 리뷰어가 전체 맥락을 이해하면서도 각 변화를 독립적으로 검토할 수 있다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.