레거시 테스트 플랫폼 2년 — 대시보드 · UI 개편 · 자동화

01 · 배경 — 백엔드가 없는 프론트엔드

별도의 애플리케이션 서버 없이 브라우저가 BaaS(Parse Server)의 여러 컬렉션을 직접 조회하는 구조였다. 현황을 시각화하려면 다수 컬렉션을 각각 조회한 뒤 클라이언트에서 조인·집계해야 했다. 프레임워크도 없었다. 상태 관리, 렌더링, 데이터 흐름을 전부 직접 설계해야 했다.

팀은 FE 2명. 이 환경에서 2년간 세 단계의 일을 했다.

02 · 대시보드 구축 (2023)

고객사가 요청한 테스트 현황 대시보드. 레이아웃부터 데이터 정제까지 담당했다.

• Parse REST API(where / order / limit)로 다중 컬렉션 조회, 클라이언트에서 프로젝트·기간별 집계 및 정제 로직 구현
• Chart.js로 추이 · 분포 · 비교 등 차트 27개를 요구사항에 맞게 커스터마이징. 문서를 처음부터 읽고 옵션을 하나씩 실험하며 구현
• XMLHttpRequest 래퍼 기반 콜백 비동기 로딩 흐름
• Excel 추출 — exceljs로 테스트 결과를 내보내고, 조건에 따라 셀 스타일 적용(예: Fail → 빨간색 강조)
• 일일 메일 리포트 — 서버에서 Linux Chrome으로 대시보드를 열어 로딩 대기 후 캡처, 크론으로 매일 발송. 초기 구축은 팀장, 이후 리팩토링과 유지보수를 담당

운영 중 문제 하나가 설계 교훈으로 남았다. 대시보드에 기능과 무거운 UI가 계속 추가되면서 클라이언트 집계 시간이 늘어 페이지 로딩이 10초를 넘겼고, 캡처 시점에 차트가 다 그려지지 않은 채 메일이 나가는 일이 생겼다. 대기 시간을 늘리는 건 미봉책이었다. 근본 원인은 집계가 브라우저에 있다는 구조였고, 이 경험이 통합 플랫폼에서 리포트 화면을 서버 집계로 전환하는 계기가 됐다.

03 · UI 전면 개편 (2024.01 ~ 07)

낙후된 테스트 자동화 플랫폼 UI를 테스트 생성부터 결과 모니터링까지 이어지는 흐름으로 재설계했다. 레거시 버그 수정을 병행.

• 조건부 필드 폼 — 입력값에 따라 분기되는 필드를 순수 DOM 조작으로 제어. 폼 데이터 수집과 유효성 검증을 독립 유틸로 모듈화해 화면 간 재사용
• 대량 데이터 그리드 — 테스트 결과 상세 테이블 · 페이지네이션 · 히스토리 내역 렌더링
• Parse Server 비동기 통신 — POST/PUT/DELETE 흐름과 예외 처리를 분리해 데이터 생성 파이프라인 정리
• 권한별 화면 분기 — 사용자 권한에 따라 라우팅과 관리자 전용 화면 렌더링을 클라이언트에서 분기 (데이터 접근 제어는 Parse 대시보드 설정과 병행)

1인이 분석·디버깅과 신규 개편을 동시에 해야 했기 때문에, 'UI 렌더링'과 '데이터 질의·처리' 영역을 분리하고 코드를 논리 단위 모듈로 나누는 것이 우선이었다.

보안 정책상 개편 전후 화면은 공개하지 않는다.

04 · 업무 자동화 (2024.08 ~ 12)

사내 실무자와 고객사의 반복 업무를 분석해 입력 프로세스와 리포팅을 자동화했다.

• '이전 티켓 결과 불러오기' · '다중 항목 일괄 입력' — 테스트 담당자가 디바이스·브라우저별 결과를 매번 수동 입력하면서 오타·누락이 반복됐다. 이슈 트래커의 이전 티켓 히스토리를 API로 조회해 응답 객체를 현재 입력 폼 DOM에 매핑하는 기능을 구현
• 고객사 맞춤 리포트 자동 발송 — 고객사가 요구하는 테스트 지표와 차트 데이터를 추출해 사내 메일 시스템과 연동
• 기존 대시보드와 사내 사이트의 신규 요구사항 반영, 이슈 트래커 연동 데이터 모니터링

05 · 무엇을 배웠나 — 다음 프로젝트로 이어진 것

이 프로젝트에서 겪은 한계는 그대로 통합 플랫폼의 설계 기준이 됐다.

순수 JavaScript로 DOM과 상태를 직접 다루면서 상태 기반 렌더링과 선언적 프로그래밍이 왜 필요한지 체감했고, 이것이 2025년 React · FSD 도입을 팀에 제안할 때의 근거가 됐다.