QA, 전략부터 도구까지.
14년간 QA 엔지니어이자 Head of QA로 일하며 릴리즈 리스크를 어떻게 판단하고 QA 조직을 어떻게 세우는지를 다뤄왔습니다. 그 사고방식을 소프트웨어로도 직접 구현합니다. 이 포트폴리오는 QA 접근법 → 조직 빌딩 → 직접 만든 도구 → 지식 공유 순으로, 소프트웨어 QA를 어떻게 설계하는지를 담았습니다.
핵심 성과
- 14년+QA 경력모바일·웹·임베디드
- 0→1QA 팀 빌딩한국·미국
- 93%E2E 테스트 커버리지Openedges · Playwright 전환
- 20%↓이슈 리드타임Riiid · QA 체계 정립 후
- 11.81%↓중복 이슈Openedges · OpenProject 워크플로우 재정의
- 2QA 저서 출간+ QA Korea 발표 3회
- 5직접 만든 QA 도구ReleaseGate · QAlity 등
- ISO 13485의료기기 QMS 인증Asleep · 품질책임자(QMR) 총괄
각 지표는 재직 당시 해당 회사에서 측정·기록한 값입니다.
QA 접근법 · 원칙
릴리즈는 감이 아니라 데이터로
GO/HOLD를 목소리 큰 사람의 직관이 아니라 점수와 근거로 내리도록 릴리즈 게이트를 설계합니다. 여러 조직에서 게이트를 팀 표준으로 세웠고, 그 판단 자체를 ReleaseGate로 도구화했습니다.
위험 기반으로 테스트를 설계
요구사항 리스크를 기준으로 테스트 범위·자동화 투자 지점·릴리즈 차단 조건을 정합니다. 전부 자동화하는 게 아니라 어디에 얼마나 둘지를 결정하는 게 QA 전략의 핵심입니다.
회귀는 자동화, 운영은 관측
핵심 사용자 여정을 E2E로 자동화해 데일리 회귀 파이프라인으로 돌리고, 출시 후에는 Sentry·Datadog·Grafana 모니터링과 온콜로 품질을 운영 단계까지 잇습니다.
테스트는 가설을 좁히는 루프
테스트를 출시 직전의 의례가 아니라 재현 가능한 실험으로 봅니다. 무엇이 왜 깨지는가를 기능 설계 단계에서 함께 보고, 그 QA 감각을 제품 판단으로 옮깁니다.
QA 프로세스
두 원칙으로 돌립니다 - Shift-left(테스트를 설계 단계로 당김)와 위험 기반(리스크가 테스트의 범위·깊이·우선순위를 정함).
- 01Shift-left
요구사항 · 설계 리뷰
기획·디자인 산출물 단계에서 QA가 참여해 모호함과 리스크를 앞단에서 잡습니다. 테스트를 코드 이후가 아니라 명세 단계로 당깁니다.
- 02위험 기반
리스크 평가 · 우선순위
실패 영향도와 발생 가능성으로 리스크를 평가해 테스트 범위·깊이·자동화 투자 지점을 정합니다. 다 테스트하지 않고 리스크 높은 곳에 집중합니다.
- 03
테스트 설계 · 자동화
우선순위 높은 경로부터 케이스를 설계하고 핵심 여정을 E2E로 자동화합니다. 케이스는 Qase로 관리합니다.
- 04
실행 · 회귀 파이프라인
데일리 회귀를 CI에 통합해 자동 실행하고 Allure로 결과를 봅니다. flaky는 진짜 회귀와 구분합니다.
- 05
릴리즈 게이트 (GO/HOLD)
커버리지·미해결 결함·잔여 리스크를 종합해 릴리즈를 판단합니다. 점수와 근거를 함께 봅니다.
- 06
모니터링 · 온콜 → 피드백
출시 후 Sentry·Datadog·Grafana로 관측하고, 실제 이슈를 다음 사이클의 리스크 입력으로 되먹입니다.
QA 조직 빌딩
Riiid (뤼이드)Senior QA → Head of QA
2021.02 - 2022.05 · AI 교육- ·한국 QA 체계를 미국 R&D와 통합 운영하도록 현지화, 자동화·모니터링·온콜의 공통 기준을 양 조직에 정렬
- ·미국 현지 QA 팀 0→1 빌딩 - Lever·HackerRank 채용 전형 설계, QA 엔지니어 다수 채용
- ·QA 체계 정립 후 이슈 리드타임 20% 단축 (SoftBank 2,000억 투자 유치 기간 중 품질 총괄)
Asleep (에이슬립)Head of QA
2022.06 - 2024.02 · 수면 데이터 · 디지털 치료제- ·B2C(앱)·B2B(병원)·B2H(디지털 치료제) 제품군별로 리스크가 달라 각기 다른 QA 전략을 수립·실행
- ·QA 팀 빌딩, 전사 품질 교육 운영, 스프레드시트 테스트 케이스를 Qase 관리 체계로 전환
- ·Sleep Routine Hybrid→Native 전환에 맞춰 모바일·웹 회귀 자동화 프레임워크 구축
규제규제 QA: 의료기기 라인은 ISO 13485 품질경영시스템 설계·운영 + 식약처(MFDS) 인증을 품질책임자(QMR)로 총괄.
Openedges SqaureWeb QA Engineer · 1인 오너
2024.07 - 2025.10 · Web Canvas2D- ·1인 QA 오너로 요구사항→릴리즈 전 구간 품질 전략을 직접 설계·운영
- ·Selenium → Playwright로 E2E 자동화 재설계, 커버리지 93% 달성
- ·OpenProject 워크플로우 재정의로 중복 이슈 11.81% 감소
Day1CompanyQA Engineer · 0→1 오너
2025.11 - 2026.04 · 실시간 교육- ·요구사항 리스크 기반 QA 전략을 0→1로 수립, 티켓·테스트 플로우·릴리즈 게이트를 팀 표준으로 정착
- ·0→1 QA 팀 빌딩 - 역할 정의·협업 프로세스·품질 책임 체계
- ·핵심 사용자 여정 기반 E2E 자동화 프레임워크 구축, 데일리 회귀 파이프라인 운영
직접 만든 QA 도구
QA 도구를 만들며 학습·적용한 스택
- TypeScript
- Zod
- JSON Schema
- OpenAPI 3.x
- vitest
- tsup
- npm
- FastAPI
- React
- PostgreSQL
- OpenAI API
- Python
- OpenAI Embeddings
- Playwright
- Jira REST API
- Vite
- GPT-4o-mini
- Tailwind
- Zustand
- React Query
- i18next
- SQLAlchemy
- Redis
- WebSocket
- pytest
- Locust
- Sentry
- Cloudflare Pages
- Cloudflare Tunnel
- Mac Mini
Adversary
Live스키마 하나에서 "설명이 붙은" 악성 테스트 입력을 뽑아내는 오픈소스 라이브러리 - 경계값·i18n·인젝션, 각 입력이 왜 깨질 수 있는지까지.
QA 문제
입력 검증 코드를 짜는 사람 대부분은 경계값·유니코드·인젝션 케이스를 손으로 다 떠올리지 못한다. `z.string().min(3)` 한 줄을 쓰고 나면, 그 필드가 실제로 받아낼 악성 입력 - 3자보다 한 글자 짧은 값, 11개 UTF-16 코드유닛짜리 가족 이모지, `javascript:`로 시작하는 URL - 을 일일이 테이블로 만드는 건 별개의 일이고, 대개 안 만든다.
구현
- ·스키마에서 설명 붙은 적대적 입력 생성 - 각 값에 technique(BVA·EP·i18n·injection)·family·failureHypothesis·validity 라벨
- ·4개 기법 카탈로그 - 경계값 분석·동등 분할·i18n/유니코드(정규화·grapheme vs code unit·bidi·homoglyph)·인젝션(SQL·XSS·SSTI·CSV 수식·명령어·경로 순회·CRLF·NUL)
- ·타입별 커버리지 - string·number/integer·boolean·enum/literal·array·date/date-time·union, 각 타입의 함정에 맞춘 생성기
QA 검증 관점
- ·생성된 값이 스키마 자신의 제약을 만족하는지(validity: valid/invalid/unknown)를 정확히 라벨링하는가 - i18n·injection은 "통과 여부가 곧 테스트 대상"이라 unknown으로 정직하게 둠
- ·각 failureHypothesis가 기대는 사실이 실제로 참인가 - 217개 테스트가 'ß'.toUpperCase()는 'SS', 가족 이모지는 11 코드유닛, z.url()이 javascript: 통과 같은 사실을 하나씩 고정
- ·JSON이 표현 못 하는 값(absent·NaN·Infinity·-0)이 출력에서 조용히 사라지지 않는가 - 리터럴 문자열/null로 인코딩해 무손실
결과 · 전망
"검증은 안전이 아니다"를 도구로 증명하는 게 가장 분명한 결과였다. z.url()에 javascript:·file://·클라우드 메타데이터 SSRF 주소를 넣으면 전부 safeParse를 통과한다 - 검증을 통과한 값이 그대로 위험하다는 걸 눈앞에서 보여주면, 필드 뒤의 코드가 진짜 방어선이라는 게 설명 없이 전달된다.
학습·적용 기술
- TypeScript
- Zod v4
- JSON Schema
- OpenAPI 3.x
- vitest
- tsup
- npm
Zod 스키마 하나를 "설명이 붙은" 적대적 입력으로 바꾸는 CLI - 각 값에 기법·이유 라벨이 붙는다.
OpenAPI 스펙에서 엔드포인트별 적대적 입력 리포트를 뽑는다 - Zod 스키마 없이, QA가 스펙만으로.
실제 FastAPI 프로젝트(frameboard)의 Pydantic 모델에 적용 - model_json_schema()로 뽑은 JSON Schema를 그대로 adversary에.
ReleaseGate
MVP릴리즈 직전, GO / HOLD를 데이터로 결정하게 해주는 AI 평가 SaaS.
QA 문제
릴리즈 직전 회의에서 "이거 내보내도 괜찮을까"가 매번 감과 목소리 큰 사람의 직관으로 결정된다.
구현
- ·Release Confidence Score (0-100) 설계 - 테스트 커버리지·미해결 결함·변경 위험 영역을 가중합으로 묶음
- ·GO / HOLD 권고와 그 근거가 함께 보이는 리포트 UI
- ·AI 기반 테스트 케이스 초안 생성 - QA 엔지니어가 빈 화면이 아닌 "수정할 초안"부터 시작하게
QA 검증 관점
- ·점수 재현성 - 같은 입력(커버리지·미해결 결함·변경 위험)에 같은 신뢰도 점수가 나오는가(루브릭 결정론)
- ·GO/HOLD 권고와 최종 결정 사람 개입의 경계가 흐려지지 않는가 - 자동 판정으로 오인되지 않게
- ·입력 경계값 - 빈 입력·50,000자 초과 같은 극단 입력에서 안전하게 막히는가(TC-P0-001·002)
결과 · 전망
"릴리즈 결정"이라는 단어가 가진 무게를 한 화면에 담아내는 게 만만치 않다는 걸 확인. 점수 한 줄을 띄우는 건 쉽지만, 회의실에서 그 점수가 받아들여지려면 "어떻게 그 점수가 나왔는지"가 같은 화면에서 즉시 보여야 했다.
학습·적용 기술
- FastAPI
- React
- PostgreSQL
- OpenAI API
Jira 이슈의 제목·본문을 임베딩으로 비교해 중복 후보 쌍을 찾아주는 Python CLI - 엑셀 리포트와 사용량·비용 통계까지.
QA 문제
QA 백로그엔 같은 이슈가 다른 표현으로 여러 번 등록된다. 사람이 일일이 훑어 중복을 찾는 비용은 백로그가 커질수록·사람이 늘수록 커지고, 대개 그냥 방치된다.
구현
- ·Jira API로 이슈를 대량 조회(JQL, MAX_ISSUES 기본 50)하고 [UI] 같은 키워드 이슈는 제외
- ·제목 + 본문을 OpenAI text-embedding-ada-002로 임베딩, 코사인 유사도로 중복 후보 쌍 산출
- ·임베딩을 캐시(issue_embeddings_cache.json)해 재실행 비용 절감
QA 검증 관점
- ·유사도 임계값의 precision/recall - 임계값을 낮추면 오탐(무관 쌍), 높이면 진짜 중복을 놓치는 트레이드오프를 어디에 두는가
- ·오탐 비용 - 중복 아닌 쌍을 중복이라 말하면 사람 리뷰 시간을 되레 늘리므로 그 비용을 인지했는가
- ·임베딩 캐시(
issue_embeddings_cache.json)가 이슈 본문 변경 시에도 낡은 벡터로 오판하지 않는가
결과 · 전망
2025년에 만든 CLI로 보관 중이었던 "묻혀 있던 보석." 14년 QA 경력에서 가장 자주 본 백로그 문제 중 하나가 "중복 이슈"라는 걸 다시 떠올리고, Atlassian Marketplace App화 또는 컨설팅 보조 도구로 부활 검토 중.
학습·적용 기술
- Python
- OpenAI Embeddings
Jira 이슈를 트리거로 Playwright 자동화를 돌리고 결과를 Jira 코멘트로 회신.
QA 문제
수동 회귀 테스트의 "이슈로 만들고 → 돌리고 → 결과 적고 → 상태 옮기는" 루프가 분리돼 있어 일관성이 떨어진다. 실행은 로컬에서, 결과는 사람 기억에, 상태 전이는 나중에 - 이 사이에서 기록이 샌다.
구현
- ·Jira(QAlity) 이슈를 시나리오 단위로 삼아 pytest + Playwright 실행
- ·결과를 ADF(Atlassian Document Format) 코멘트로 Jira에 회신
- ·성공/실패에 따라 Jira 이슈 상태 자동 전이
QA 검증 관점
- ·Jira 왕복 무결성 - 이슈 → 실행 → 코멘트 회신 → 상태 전이가 중간에 누락 없이 끝까지 이어지는가
- ·재실행 멱등성 - 같은 이슈를 다시 돌려도 코멘트·상태가 이중으로 쌓이거나 어긋나지 않는가
- ·강제 실패 케이스(QAP-2)로 성공뿐 아니라 실패도 정확히 회신·전이하는지 확인했는가
결과 · 전망
QA 포트폴리오로 유지. "Jira 이슈를 트리거로 Playwright를 돌리고 결과를 Jira로 돌려준다"는 워크플로우 통합 자체가 14년 QA 경력의 결정이 응축된 자리라 보관 가치가 사업화 가치보다 먼저.
학습·적용 기술
- Python 3.11+
- Playwright
- Jira REST API
CaseMaker (Figma2Checklist)
Archived문서 URL(공개 Notion 페이지)을 넣으면 GPT-4o-mini가 QA 테스트 체크리스트를 초안·그룹핑해주는 풀스택 도구 - "디자인·문서에서 QA로"(shift-left)를 인증·결제까지 얹어 검증한 실험.
QA 문제
디자인·기획 산출물과 QA 사이에 공통 기준이 없다. 명세가 없으면 QA는 테스트 범위 자체를 추론하기 어렵고, 매번 수작업으로 체크리스트를 만들다 보면 누락과 편차가 생긴다.
구현
- ·문서 URL 입력 → 공개 Notion 페이지를 Playwright로 읽어 텍스트 추출(BeautifulSoup) → GPT-4o-mini가 QA 체크리스트 항목을 초안·그룹핑
- ·생성한 체크리스트를 계정별로 저장·불러오기
- ·React + FastAPI 풀스택, 이메일/비밀번호 인증, PostgreSQL, Toss 결제 연동 코드까지 얹은 SaaS 골격
QA 검증 관점
- ·자동 생성 체크리스트의 정확도·누락을 어떻게 측정하고 회귀를 막는가 - 항목이 그럴듯해도 이 검증 없이는 신뢰가 안 선다(이 프로젝트가 못 푼 핵심 난제)
- ·GPT-4o-mini가 같은 문서에도 실행마다 다른 항목·그룹을 낼 수 있어, 회귀 방지 설계 없이는 정확도를 애초에 고정할 수 없다는 게 멈춘 이유였는가
- ·공개 Notion 페이지 파싱(Playwright + BeautifulSoup)이 문서 구조 변화·비공개·빈 페이지에서 견고하게 실패하는가
결과 · 전망
인증·저장·결제 연동까지 갖춘 풀스택으로 세운 뒤 휴면. 실 사용·실 결제로 이어지진 않았고 라이브 URL은 없다. 멈춘 진짜 이유는 기능이 아니라 - 자동 생성 체크리스트의 정확도·누락을 회귀 검증할 설계 없이는 항목이 그럴듯해도 신뢰가 안 선다는 것 - 그 자체가 이 프로젝트가 남긴 QA 교훈이다. 이름(Figma2Checklist)과 실제 구현(Notion 기반)의 간극은 정직하게 그대로 둔다.
학습·적용 기술
- React 19
- Vite
- FastAPI
- PostgreSQL
- GPT-4o-mini
- Playwright
QA Learning 101
Live테스팅 방법론과 자동화를 실습으로 익히는 QA 학습 플랫폼 - 실무를 닮은 연습용 앱에 직접 테스트를 짜본다.
QA 문제
QA 엔지니어 입문자가 "무엇을 어떤 순서로 배워야 하는지"의 지도가 없다. 책은 무겁고, 강의는 일방향이라 손이 안 움직인다.
구현
- ·FastAPI·PostgreSQL 백엔드와 React·TypeScript 프론트로 된 풀스택 학습 앱 (인증·게시판·댓글·할 일·칸반·캘린더·실시간 채팅·파일)
- ·QA Hub - 은행 대시보드·예약 시스템·이커머스·소셜 피드 등 실무를 닮은 연습용 앱을 만들어, 자동화 테스트를 짜볼 대상으로 제공
- ·화면 전반에 CSS·구조와 무관한 data-testid 셀렉터 규칙을 심어 E2E가 리팩토링에 안 깨지게
QA 검증 관점
- ·data-testid 셀렉터가 CSS·컴포넌트 구조 변경에도 안 깨져 E2E가 리팩토링에 견디는가(학습용 표준의 실증)
- ·QA Hub 연습용 앱(은행·예약·이커머스·소셜 피드)이 실무를 닮은 상태·엣지 케이스를 실제로 담고 있는가
- ·학습 콘텐츠 자체의 정확성 - 방법론 설명이나 예제가 틀리면 입문자에게 잘못된 습관이 5년을 가므로 가장 회피할 회귀인가
결과 · 전망
학습 도구로 유지. 사업화 시도는 보류 - 입문자에게 "무엇을 어떤 순서로 배워야 하는지"의 지도가 없다는 14년 QA 경력의 관찰에서 시작한 도구라, 자료로서의 가치가 매출보다 먼저다.
학습·적용 기술
- React
- TypeScript
- Vite
- Tailwind
- Zustand
- React Query
- i18next
- FastAPI
- Python
- PostgreSQL
- SQLAlchemy
- Redis
- WebSocket
- Playwright
- pytest
- Locust
- Sentry
- Cloudflare Pages
- Cloudflare Tunnel
- Mac Mini
지식 공유
저서
- 반드시 알아야 할 품질과 코딩2024.11.27종이책 · eBook
- 아직 잘 알려지지 않은 SQA 엔지니어의 세계2022.04.25eBook · 판매 중단
발표
- QA Korea Conference 4th - Live Q&A Speaker2025.07.05QA Korea Conference
- QA Korea OFF-QA - Lightning Talk Speaker2024.12.06QA Korea Conference
- QA Korea Conference 1st - Speaker2023.01.28QA Korea Conference
핵심 역량
- Test Automation
- Playwright · Selenium · Cypress · Appium · Detox · Espresso/XCUITest · Locust · Lighthouse
- Test Mgmt · Tracking
- Qase · Jira · OpenProject · Allure · Bugzilla
- CI/CD · Monitoring
- GitHub Actions · BrowserStack · Sentry · Datadog · Grafana · OpsGenie
- QA Leadership
- QA 전략 · 0→1 팀 빌딩(KR·US) · 릴리즈 게이트 · 회귀 자동화 · 온콜 · 품질 교육 · ISO 13485/QMR
- AI-assisted QA
- 임베딩 기반 중복 이슈 탐지 · LLM 채점·분석 파이프라인
- Stack
- TypeScript · Python · Java · SQL
도메인 경험
- 플랫폼
- 모바일 앱 · 웹 · 임베디드 · 펌웨어
- 산업
- AI 교육 · 디지털 치료제(의료기기·규제) · 실시간 교육 · 스마트펜 하드웨어 · 다언어 로컬라이제이션 · 의류 사이즈 B2B SaaS
- 제품군
- B2C · B2B(병원) · B2H(디지털 치료제)