콘텐츠로 이동

테스트·품질

웹빌더의 핵심 일이 HWP·PDF 같은 문서를 그대로 웹으로 옮기는 건데, 그 안에 표와 폰트가 정확히 보존되는지는 눈으로만 봐서는 판단하기 어려워요. AI가 내놓는 응답도 마찬가지예요. 말이 그럴듯한지가 아니라 '정답과 얼마나 일치하는지'를 숫자로 잴 수 있어야 신뢰할 수 있죠.

그래서 우리 테스트 전략은 크게 두 갈래예요. 기능이 제대로 도는지(회귀·통합·E2E)와 결과물이 얼마나 정확한지(문서 보존률·AI 정확도)를 각각 다른 도구로 확인합니다. 둘을 섞지 말고, 역할에 맞는 도구를 골라 쓰는 게 이 카테고리의 중심이에요.

상태 배지

이 위키에서는 기술마다 적용 정도를 배지로 표시합니다.

  • 🟢 운영 — 제품에 실제로 돌아가고 있는 기술
  • 🔵 적용 — 도입했거나 적용 중인 기술
  • ⚪ 역량 — 팀이 다룰 줄 알지만 제품엔 아직 안 쓰는 기술

Playwright와 Lighthouse는 🟢 운영, K6는 🔵 적용 상태로 보고 있어요. 성능 지표(LCP·INP·CLS)는 모든 웹 작업에 걸쳐 적용되는 기준이에요.

하위 기술 딥 페이지

테스트·품질의 핵심 두 기술은 각각 별도 페이지로 정리했어요.

  • Playwright (🟢 운영) — 브라우저를 직접 조작해 사용자 흐름을 재현하는 E2E 테스트 도구예요. 실제 화면에서 클릭하고 입력하면서 '사용자가 하는 일'을 그대로 돌려봐요.
  • Lighthouse (🟢 운영) — 웹페이지 성능·접근성·SEO를 한 번에 측정해 점수로 보여주는 도구예요. 실제 개선 전후를 수치로 비교하기 좋아요.

함께 쓰는 기술 (목차)

딥 페이지는 따로 없지만 같은 자리에 묶여 쓰는 기술들이에요.

  • K6 (🔵 적용) — 가상 사용자를 많이 흘려보내 서버가 버티는지 보는 부하 테스트 도구. 스크립트를 코드로 짜서 CI에도 얹기 좋아요. 공식 문서
  • Unit / Integration / E2E (🟢 운영) — 테스트를 세 층으로 나눠 다루는 방식. 함수 단위(Unit), 모듈 간 협력(Integration), 사용자 시나리오 전체(E2E) 순서로 범위가 커져요.
  • API Test / A/B 테스트 (🟢 운영) — 화면을 거치지 않고 백엔드 응답을 확인하는 API 테스트와, 두 버전을 실제 사용자에게 나눠 보여주고 지표를 통계로 비교하는 A/B 실험이에요.
  • JMeter / nGrinder (⚪ 역량) — 오래된 대표 부하 테스트 도구와 NHN의 Groovy 기반 도구로, 제품엔 아직 안 쓰고 다룰 줄 아는 상태예요.
  • AI 자동 평가 (🔵 적용) — AI 응답을 사람이 일일이 채점하는 대신 정답과 일치하는지 자동으로 채점하는 방식이에요.

실제 적용

HWP·PDF 변환 기능의 품질은 레이아웃 보존률로 판정하고, 회귀는 Playwright E2E가 밤마다 잡아요. 성능은 K6로 트래픽을 흘려보내 P95 지연을 확인하고, 프론트는 Lighthouse로 LCP·A11y 점수를 주기적으로 기록하죠. 자세한 흐름은 각 딥 페이지와 기술 스택 허브에서 이어집니다.

더 알아보기