OH SU JINFrontend Engineer

사내 서비스운영 중Lighthouse 100

Lab Dashboard

커밋 이력과 태스크 데이터를 묶어 보여주는 사내 대시보드.

담당
설계 · 프론트엔드 · 수집 파이프라인 · 배포 전담
팀
백엔드 1 · 프론트 1(본인)
기간
2026.08

커밋 이력과 태스크 데이터를 묶어 보여주는 사내 대시보드. 수집 파이프라인부터 화면·배포까지 전담했다. 성능 점수는 모바일·데스크톱 모두 100점이었지만, 점수가 문제를 가리고 있었다.

배포
사내망 전용 — 외부 접근 불가
스택
Next.jsApp RouterReact Server ComponentsTypeScript strictAuroraLambdaEventBridge

주요 작업

  • 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건