장규범 · Seoul, Korea
품질은 배포 직전에 검사해서 만들어지지 않는다고 생각합니다. 기획서를 읽는 순간부터 무엇이 위험한지를 정하고, 그 기준을 팀이 함께 쓰게 만드는 일까지가 QC의 몫이라고 봅니다.
커머스·B2B 서비스 네 곳의 정기 배포를 맡고 있습니다. 릴리스마다 위험도 순으로 검수 범위를 정하고, 결과를 리포트로 남겨 다음 릴리스의 기준으로 씁니다. 같은 결함이 두 번 나오면 테스트 케이스가 아니라 프로세스를 고칩니다. 어느 단계에서 걸러졌어야 했는지 되짚어 체크리스트와 가이드에 반영합니다.
프론트엔드 개발 경험이 있어 컴포넌트 상태와 API 응답을 직접 확인합니다. 덕분에 결함 리포트를 "버튼이 안 눌려요"가 아니라 "이 조건에서 이 요청이 이 응답을 받고 이 상태로 남습니다"로 적을 수 있고, 고치는 쪽과 확인하는 쪽이 한 번에 끝납니다.
반복되는 확인은 자동점검으로 넘기고, 판단이 필요한 자리는 남겨둡니다. 그렇게 아낀 시간은 자동화가 잡지 못하는 곳에 씁니다. 스크립트는 정해둔 것만 확인하니, 기획 의도와 다르게 동작하거나 흐름이 어색한 구간은 결국 사람이 찾아야 합니다.
나무처럼 꾸준히 가지를 뻗어, 결국 열매를 맺는 사람이 되고 싶습니다.
English
Quality isn't created by inspecting a build the day before release. From the moment the spec is written, someone has to decide what is risky and get the whole team using that same standard. That is what I think QC is for.
I own the release cycle for four commerce and B2B services. Each release, I scope verification by risk, then publish a report that becomes the baseline for the next one. When the same defect shows up twice, I fix the process rather than the test case, and trace back which stage should have caught it.
Having written production frontend code, I read component state and API responses myself. So a defect report says "under this condition this request returns this response and leaves this state," not "the button doesn't work" - which means the person fixing it and the person verifying it are both done in one pass.
Repetitive checks go to automated runs; judgment calls stay with people. The time that frees up goes where automation can't reach. A script only checks what it was told to, so a screen that technically works but behaves against the spec is still something a person has to catch.
| 영역 | 대상 | 범위 |
|---|---|---|
| Release QC | 애드콘 · 애드콘비즈 · 비즈애드콘 · 애드웰 | 정기 배포 검수, 운영 환경 핵심 시나리오 점검, HTML QC 리포트 발행 |
| External QA | 외부 고객사 WEB / MOBILE | 테스트 계획서, 결함 관리, 품질 통계 대시보드 |
| Automation | 서비스 자동점검 · 회귀 스위트 | Playwright · Python 검증 스크립트 |
| AI × QC | AI가 생성한 TC | 중복률·커버리지 측정 후 검수 목록 편입, 기준 미달 케이스 폐기 |
위험한 것부터 봅니다. 기능 목록 순서로 테스트하면 시간이 모자랄 때 하필 마지막 항목이 잘립니다. RBT(Risk-Based Testing) 분류 체계를 만들어, 틀리면 되돌리기 어려운 구간을 먼저 확인하고 그 다음을 잘라냅니다.
반복되는 확인은 자동으로 넘깁니다.
회귀 검증 사이클을 16시간 → 6시간 으로 줄였습니다. 스위트를 병렬로 쪼개고, 매번 같은 순서로 클릭하던 구간을 Playwright 자동점검으로 옮긴 결과입니다.
검수는 정해진 순서로 돕니다. 기획서 분석 → 요구사항 도출 → TC 생성 → 수행 → 재테스트 → 탐색 테스트 → 회귀 테스트 → 자동화 → 리포트 발송. 이 9단계를 가이드와 온보딩 문서로 남겨, 신규 입사자가 첫 배포 검수에 바로 들어갈 수 있게 했습니다. 순서가 고정되어 있어 누가 맡아도 같은 범위가 나옵니다.
검수하면서 반복되는 병목은 도구로 만듭니다. 기획서에서 테스트 케이스를 뽑는 일과, 그 케이스를 실행해 결함까지 추적하는 일을 두 축으로 나눠 AI 기반 QC 플랫폼을 개발하고 있습니다.
사내에서 운영 중이며, 저장소는 비공개입니다.
TC 생성 엔진 - 기획서와 Figma를 입력으로 테스트 케이스를 만들고, 만든 것을 다시 검사합니다. 중복은 임베딩 유사도로 걸러내고, 임베딩을 쓸 수 없는 환경에서는 문자 3-gram 자카드 유사도로 대신합니다. 커버리지는 요구사항 추적 매트릭스(RTM)로 계산하고, 기획서와 Figma가 어긋나는 구간은 갭으로 따로 뽑아 사람이 채웁니다.
실행 · 결함추적 워크플로 - TC 실행부터 결함 추적, 역할별 대시보드까지. 14단계 TC 상태 머신을 서버에서 검증해 임의 전이를 막고, 결함 상태와 자동으로 연동합니다.
| 영역 | 내용 |
|---|---|
| 백엔드 | FastAPI · SQLAlchemy · Alembic - 서비스 93개, 모델 45개, 마이그레이션 84단계 |
| 프론트엔드 | Next.js App Router · TypeScript · Zustand · React Query |
| 테스트 | pytest 2,500여 개, Playwright E2E, pre-commit(ruff · eslint · gitleaks) + CI |
| LLM | Claude - 호출 진입점을 단일 서비스로 묶어 프롬프트·모델 교체와 실패 처리를 한 곳에서 관리 |
QC 도구를 직접 만들면서 배운 것은, 상태 머신처럼 규칙이 많은 영역일수록 문서가 아니라 코드가 단일 진실원이어야 한다는 점입니다. 검수 기준을 사람이 외우게 하는 대신 서버가 거절하게 만들면, 그 기준은 팀이 바뀌어도 남습니다.
| 기간 | 소속 | 역할 |
|---|---|---|
| 2025.04 ~ | 다우기술 품질관리팀 | QC - 커머스·B2B 서비스 배포 검수, 자동점검, AI TC |
| 2022.12 ~ 2023.06 | aaant 개발팀 | Frontend - React · TypeScript |
| 2021.06 ~ 2021.08 | 시너지 개발팀 | Frontend (인턴) |
| 분류 | 스택과 쓰임 |
|---|---|
| 테스트 자동화 | Playwright, Python - 회귀 스위트와 서비스 자동점검 스크립트 |
| 협업 · 관리 | Redmine, Notion, Slack, Excel |
| 프론트엔드 | TypeScript, React, Next.js, React Query, Recoil, Emotion, vanilla-extract |
이력서는 Notion에 정리해두었고, 커피챗과 문의는 LinkedIn으로 받습니다. 공부한 것은 트리규의 개발 블로그에 쓰고 있습니다.