복잡한 상태를, 명확한 사용자 경험으로

문제

기존 상품과 결제·이용 상태가 달라 UI와 로직을 그대로 재사용할 수 없었습니다. 상태가 섞이면 잘못된 CTA, 결제 승인 상태 오판과 이벤트 누락이 함께 발생할 수 있었습니다.

선택한 방법

• 서버 값을 렌더링 조건문에 직접 연결하기보다 도메인 상태에서 화면 상태·행동 가능 여부로 이어지는 계약을 먼저 정리했습니다.
• 이용권·결제·진행률·공개·환불·마감 조건을 분리하고, 결제를 준비·결제창·승인·활성화 단계로 나눴습니다.

구현과 확인

• GraphQL/Relay 기반 구현 참여 범위에서 React·TypeScript로 화면 상태와 CTA 규칙을 반영했습니다.
• 약 10단계 퍼널의 실패 위치·오류 유형을 나눠 이벤트 요구사항과 검증 포인트를 남겼습니다. 성공·실패·취소 지표의 누락 위험도 함께 확인했습니다.

문제

CI/CD 실행에 13분이 걸려 작은 변경도 배포 결과를 확인하는 비용이 컸습니다. 운영 중인 네 프로젝트의 호환성과 배포 안정성을 함께 지켜야 했습니다.

선택한 방법

• Bun 벤치마크와 프로젝트별 호환성을 확인한 뒤 점진적 전환을 선택했습니다.
• 설치·이미지 빌드·배포 단계를 나눠 병목과 실패 범위를 좁혔습니다.

구현과 확인

• npm/yarn을 Bun으로 전환하고 Docker 3-stage 병렬 빌드와 캐시 레이어 재사용을 적용했습니다.
• GCloud Action을 갱신하고 GitHub Actions에 pre-merge 테스트를 추가해 실행 시간과 배포 상태를 함께 확인했습니다.

문제

저사양 기기의 채팅방 진입 시 앱이 종료됐습니다. 일시적인 캐시 삭제로 끝내기보다 원본 이미지가 스크롤 중 누적되는 경로를 찾아야 했습니다.

선택한 방법

• 같은 기기와 행동 순서를 고정하고 Crashlytics 로그·반복 재현·DevTools 프로파일링을 대조했습니다.
• 입력 이미지 크기, 캐시 보존량과 정리 시점을 각각 제한하기로 했습니다.

구현과 확인

• 표시 크기에 맞춘 이미지 다운샘플링, LRU 캐시 정책과 메모리 임계치 기반 선제 정리를 적용했습니다.
• 같은 조건에서 변경 전후 메모리를 비교하고, Crashlytics로 같은 흐름의 크래시가 다시 발생하는지 별도로 확인했습니다.

문제

외부 화상 도구와 인터뷰 피드백을 연결하는 반복 업무가 흩어져 있었습니다. 짧은 일정 안에 구현·배포와 운영팀이 사용할 실패 대응 경로를 갖춰야 했습니다.

선택한 방법

• UI·API·에러 케이스를 먼저 문서화하고 성공 결과와 실패 오류 형식을 정리했습니다.
• Server Actions + Result 패턴으로 화면마다 흩어질 수 있는 오류 흐름을 일원화했습니다.

구현과 확인

• Next.js로 기능을 구현하고 PM2로 배포했습니다. 로그·장애 대응·보안·알림·기기·네트워크 확인을 배포 후 체크리스트로 연결했습니다.
• 출시 후 인터뷰 편집·검사·합격 처리와 탈락자·중복 신청 취소 스케줄러까지 후속 업무의 자동화 범위를 넓혔습니다.