이현명 Frontend Engineer

게시글 발송 로직 통합

4곳 수정을 1곳으로

Situation

알림장·공지사항·앨범·투표 4개 발송 화면이 업무시간 판단을 각자 갖고 있어, 정책이 바뀌면 4곳을 모두 수정해야 했습니다. 같은 정책을 PC 웹에도 적용해야 했는데, 기획 문서가 모바일 기준이라 PC에 없는 화면 요소와 기능이 섞여 있었습니다.

Action

• 화면마다 따로 있던 업무시간 판단을 공통 모듈 하나로 통합하고, 학부모·교사·원장 역할별 정책 차이는 모듈 내부에서 처리
• 모바일과 PC의 정책 차이와 제외 범위를 정리해 기획·QA와 공유
• 역할·시간대·진입 지점 조합 16개 시나리오 표로 앱과 PC 동작을 검증

Result

정책 변경 반영 지점이 4곳 → 1곳으로 줄었고, 앱과 PC가 같은 규칙으로 동작하는 상태로 출시했습니다.

Tech

TypeScript, React, Custom Hooks, react-i18next

퀵계좌이체(토스 PG) 연동

웹뷰 복귀 플로우 설계

Situation

앱 웹뷰에서 토스 인증·결제 화면을 다녀오면 이동 기록이 쌓여, 흐름이 막히거나 만료된 화면이 다시 나타나는 문제가 있었습니다. 공식 문서에는 인증·결제 후 웹뷰 복귀 구간의 안내가 없어 직접 설계가 필요했습니다.

Action

• 같은 화면에서 인증하면 이동 기록을 사후에 정리해야 하므로, 인증·결제를 별도 웹뷰에서 처리하고 끝나면 즉시 닫아 끝난 화면 재노출을 방지
• 정기결제 등록·단건 결제·정기 첫결제·정기결제 관리 4종 결제 플로우에 퀵계좌이체 연동
• 복귀 시 결제수단 목록을 다시 조회하고 등록 여부를 이어받는 흐름을 직접 설계

Result

단건 결제부터 정기결제까지 연동해 계좌 기반 결제수단을 확장했고, 2026년 4월 배포 이후 프론트엔드 추가 수정 없이 운영하고 있습니다.

Tech

TypeScript, React, Toss Payments SDK, WebView, Custom Hooks

애니메이션 조정 도구

디자인 확정 과정의 개발자 의존 제거

Situation

이전 애니메이션 작업에서 디자이너의 느낌을 수치로 맞추느라 수정이 반복됐던 경험이 있어, 게시글 공감 파티클 애니메이션에서도 같은 상황이 예상됐습니다.

Action

• Canvas 파티클 애니메이션을 공통 모듈로 구현해 알림장·공지·앨범 상세 화면에 적용
• 수치 대신 연출 결과를 보고 고를 수 있도록, 속도·중력 등 물리값을 느림·기본·빠름 선택지로 제공
• 실제 화면에서 선택지를 바꿔 바로 재생해 볼 수 있는 조정 패널 제작

Result

값 조정의 주체를 개발자에서 디자이너로 전환해, 요청 → 수정 → 재확인 대신 디자이너가 패널에서 바로 확정합니다. 확정한 선택지가 그대로 코드에 반영되어 전달 과정의 해석 차이를 없앴습니다.

디자이너용 튜닝 패널 · 수치 조절 → 실시간 효과 변화

리액션 선택 시 재생되는 화면 효과

Tech

TypeScript, React, Canvas

배포 파이프라인 재구성

2단계 배포 → 1단계 배포

Situation

배포가 1단계(새 버전 빌드·업로드)와 2단계(서비스를 새 버전으로 전환)로 나뉘어 있어, 1단계가 끝나길 기다렸다가 2단계를 따로 실행해야 했습니다. 2단계를 빠뜨려도 아무 알림이 없어, 새 버전을 올리고도 구버전이 106분간 그대로 서비스된 적이 있었습니다.

Action

• 빌드·업로드와 서비스 전환을 하나의 GitHub Actions 워크플로우로 묶어, 1단계가 끝나면 전환이 자동 실행되도록 재구성
• 배포 환경 하나만 선택하면 실행되도록 절차 단순화

Result

배포 리드타임(사람 대기 포함) 중앙값 4.2분 → 1.4분, 최대 106분이던 편차 7분 이내. 전환 누락에 따른 구버전 방치 가능성을 제거했습니다.

Tech

GitHub Actions

신규 서비스 분리 구축

Lighthouse 30점대 → 80점대

Situation

Java·jQuery 기반 사이트에 모든 기능이 한 덩어리로 묶여 있어 유지보수가 어려웠고, 메인 화면은 Lighthouse 성능 점수가 30점대에 머물렀습니다.

Action

• 기존 사이트의 기능과 UI를 기준으로 React·TypeScript 기반 신규 사이트 구축
• 로그인 후 계정 유형에 따라 기존 사이트와 신규 사이트로 나눠 진입하도록 연결
• 초기 로딩 병목을 8개 iframe 일괄 렌더링으로 특정하고, 신규 사이트에서는 iframe을 실행할 때만 로드하도록 설계 (화면 단위 코드 분할·이미지 지연 로딩 병행)
• 개발·운영 환경 분리 및 Nginx·Jenkins 기반 빌드/배포 프로세스 구축

Result

같은 기능을 담은 메인 화면 기준으로 Lighthouse 성능 점수가 기존 사이트 30점대에서 신규 사이트 80점대로 측정됐고, 신규 사이트는 별도 빌드·배포 환경에서 레거시와 독립적으로 배포되는 구조가 됐습니다.

Tech

TypeScript, React, Nginx, Jenkins