Lab Dashboard
커밋 이력과 태스크 데이터를 묶어 보여주는 사내 대시보드.
- 담당
- 설계 · 프론트엔드 · 수집 파이프라인 · 배포 전담
- 팀
- 백엔드 1 · 프론트 1(본인)
- 기간
- 2026.08
커밋 이력과 태스크 데이터를 묶어 보여주는 사내 대시보드. 수집 파이프라인부터 화면·배포까지 전담했다. 성능 점수는 모바일·데스크톱 모두 100점이었지만, 점수가 문제를 가리고 있었다.
- 배포
- 사내망 전용 — 외부 접근 불가
- 스택
주요 작업
100점이 가린 1,548KB
- 총 23건 요청 1,782KB 중 이미지 5장이 1,547.6KB, 전체의 86.8%였다.
- 20×20px로 그려지는 아바타에 최대 458KB 원본이 그대로 내려오고 있었다.
- 아바타가 LCP 요소가 아니라서 점수에 반영되지 않았을 뿐, 저속망과 구성원 증가 구간에서는 그대로 체감된다.
- 설정 화면은 더 심해서 드롭다운을 열면 13장 9,363KB까지 갔다 — 구성원 수에 선형으로 증가하는 구조였다.
- 축소본으로 바꿔 총 전송량을 246KB로 내렸다.
저장하지 않기로 한 것들
- 태스크는 DB에 넣지 않고 프로세스 메모리에 5분 캐싱한다(단일 인스턴스 전제).
- 담당자 이름과 아바타도 저장하지 않는다 — 조회 응답에 딸려 오는 값이고, 저장해 두면 팀 바깥 담당자가 화면에서 빠지기 때문이다.
- 동시 요청은 single-flight로 묶어 추가 호출 없이 처리한다.
공유 순수 로직을 한 곳에
- 웹·Lambda·스크립트가 함께 쓰는 순수 로직을 core/로 분리하고, 서버 I/O는 lib/, 라우트 특수 파일만 app/에 뒀다.
- 코드 리뷰 8패스를 거치며 중복된 산술과 정렬 규칙을 공유 헬퍼로 통합했다.
지금은 괜찮지만 지켜볼 것
- DOM 깊이 17 · 최대 자식 51로 TBT 60ms는 멀쩡하다.
- 다만 태스크가 늘면 선형으로 커지는 구조라, 느려지면 여기부터 본다고 문서에 못박아 뒀다.
- 고칠 것과 지켜볼 것을 구분하는 것도 최적화의 일부다.
- Lighthouse Performance
- 100 / 100
- 모바일 · 데스크톱
- 총 전송량
- 1,782KB246KB−86%
- 이미지 전송량
- 1,548KB5.4KB−99.7%
- TTI
- 4.7s2.1s−55%
- TTFB
- 46ms
- 10회 측정 중앙값
- LCP / CLS
- 1.4s / 0
- 모바일 기준
- HTML gzip
- 294.7KB32.7KB−89%
- 테스트
- 246개
- TypeScript strict
- 수집 데이터
- 21개 저장소 · 1,435건