Detailed Portfolio · QA Operations

자동화율보다, 사람이 더 많은 품질판단을 할 수 있는 구조를 만듭니다.

기능 실행을 모두 스크립트로 바꾸는 것이 항상 빠르지는 않습니다. 변화가 잦은 SI·레거시·실장비 환경에서는 사람이 실제 사용자처럼 판단하고, 시스템이 반복 실행·데이터 비교·스크린샷·Jira·CI Gate를 맡는 편이 전체 피드백 루프를 더 빠르게 만듭니다. 이 페이지는 그 경계를 어떻게 정하고, Agent가 편한 길로 도망가지 못하게 어떻게 완료조건을 설계했는지를 설명합니다.

2,641자동화된 TC

30d → 21d월간 테스트기간

20m → 3m이슈 처리시간

300+사전 차단 데이터 이슈

01 보고서 회귀 02 QA 피드백 루프 03 시각 검증 04 Agent·Validator·CI 05 현장·실장비 QA

SPC 환경은 보고서 종류만 37개였고 옵션·언어·컬럼·데이터 조건을 조합하면 출력 경우의 수가 1,382종에 달했습니다. 전면 UI 자동화만 하면 화면은 열리지만 보고서 안의 값이 DB 원본과 같은지 확인할 수 없고, 반대로 DB만 비교하면 레이아웃·언어팩·컬럼 위치 오류를 놓쳤습니다.

1. 테스트 단위를 “클릭”이 아니라 “출력 결과”로 정의

UI 자동화는 보고서 조건을 만들고 출력하는 손발로 사용했습니다. 검증 기준은 HTML 보고서를 파싱한 결과와 DB 원본의 값·컬럼·정렬·언어를 비교하는 것이었습니다.

2. 자동화 가능한 46%를 먼저 잠금

모든 TC를 자동화하지 않았습니다. 데이터가 결정적으로 비교되고 화면 조작이 안정적인 경로 2,641건을 반복 회귀로 전환했습니다. 광학결과의 의미판단, 장비상태, GPU 렌더링처럼 신뢰할 수 없는 범위는 수동 QA로 남겼습니다.

3. 데이터 정합성 이슈를 구조적으로 차단

HTML과 DB를 직접 비교하면서 X/Y 컬럼 오출력, 언어팩 미적용, 조건별 컬럼 누락 등 300건 이상의 문제를 릴리즈 전에 발견했습니다. 화면상 “보고서가 열렸다”는 성공과 데이터가 맞다는 성공을 분리했습니다.

4. 사람이 보는 범위를 위험 기반으로 재배치

정상 반복은 자동화가 처리하고, 사람이 봐야 하는 신규 옵션·광학결과·애매한 차이만 예외 목록으로 올렸습니다. 자동화가 사람을 대체한 것이 아니라 사람의 검토 우선순위를 바꾼 것입니다.

결과: 월간 릴리즈 평균 테스트기간을 30일에서 21일로 줄이고, 반복 회귀를 2영업일에서 0.5일로 단축했습니다. 데이터 관련 VOC는 월 7건에서 1건으로 감소했습니다.

테스트 자동화를 논의할 때 가장 먼저 버튼 클릭을 자동화하려는 경우가 많습니다. 그러나 변화가 잦은 환경에서는 사람이 클릭하는 30초보다 이후 스크린샷 정리, 파일명, TC 연결, 제목·본문, Severity, Jira 첨부에 10~20분이 더 들었습니다.

1. QA가 빠르게 판단할 여섯 가지

분류	QA가 판단하는 질문	시스템이 후속으로 하는 일
실행불가	프로그램·기능이 켜지지 않는가	핵심흐름 차단으로 즉시 발사
데이터	원본과 화면·보고서 값이 다른가	DB 근거·영향범위 연결
업무단계	다음 단계로 진행할 수 없는가	사용자 여정 위치와 우회 가능성 반영
금전	금액·수량·정산에 영향이 있는가	최상위 우선순위 후보로 분류
시각	기능은 되지만 잘림·가림·대비 문제가 있는가	Screenshot과 viewport를 증적화
이탈	핵심 CTA를 찾지 못해 사용자가 포기할 수 있는가	단순 UI가 아닌 고객여정 결함으로 승격

2. Agent가 회사 규격으로 변환

QA가 남긴 압축된 판단을 제품·버전·컴포넌트·기존 TC·유사 Jira와 결합해 사전조건, 재현절차, Actual, Expected, 발생빈도, 우선순위 근거와 증적을 구성했습니다. 최종 QA 승인 전에는 Jira에 쓰지 않았습니다.

3. 자동화의 손익분기점

이슈가 1~3건이면 사람이 직접 쓰는 편이 더 빠릅니다. 하루 30건 이상 발견되는 기간에는 문서 작성으로 약 3시간이 사라졌고, 그 시간을 추가 10개 이슈 탐색이나 패치 재검증에 쓸 수 있었습니다. 따라서 자동화를 상시 강제하지 않고 업무량에 따라 사용했습니다.

4. MRLS 문제와 사격통제

행정 병목이 사라지자 개발팀에 실제 이슈가 한꺼번에 보였습니다. 모든 결함을 동일한 속도로 발사하면 중요한 이슈가 묻혔기 때문에 아래 정책을 추가했습니다.

Critical·보안·데이터손상·금전·핵심여정 차단: 즉시 개별 발사
우회 가능한 기능·성능·조건부 결함: 정기 배치
공통 UI·문구·레이아웃: 원인 또는 화면 단위 묶음
개인 취향 가능성·의도 불명확: 개선 제안으로 보류

5. 최종 KPI는 문서시간이 아니라 피드백 루프

이슈 발견

즉시 구조화

개발 패치

재설치·재검증

Pass / 재오픈

AI가 보고서를 쓴 덕분에 사람은 패치를 한 번 더 설치하고 검증할 수 있었습니다. 릴리즈에 필요한 것은 티켓 수가 아니라 하루에 몇 번 수정–검증 루프를 닫을 수 있는지였습니다.

결과: Jira 이슈 처리시간을 약 20분에서 3분으로 줄였고, 하루 최대 139건·2일 231건을 동일 형식으로 구조화했습니다. 특정 대량 배치의 최대 처리량은 51건/h였으며 평균 성능으로 과장하지 않고 배치 최대치로 관리했습니다.

DOM에는 버튼이 있고 클릭 이벤트와 API도 정상인데, CTA 배경과 텍스트가 주변 배경과 같은 색이라 사용자가 버튼을 발견할 수 없는 사례가 있었습니다. 기능 테스트만 보면 Pass지만 고객에게는 버튼이 없는 것과 같았습니다.

False Pass 예시

Functional Result: Pass · API 200 · 다음 상태 생성
Visual Result: Fail · CTA 식별 불가
Customer Journey Result: Fail · 가입/결제 다음 단계 이탈 가능
Overall Result: Fail

1. 왜 프롬프트 한 줄로 해결되지 않았나

“스크린샷을 보라”고 한 번 지시해도 세션이 길어지면 Agent가 효율을 이유로 DOM 검사만 남기고 시각 검증을 생략했습니다. 권고가 아니라 완료조건에 넣어야 했습니다.

2. Skill 계층

UI 검증은 DOM·접근성 트리·네트워크만으로 완료할 수 없으며 주요 상태 전환과 최종 화면의 Screenshot을 수집하고 실제 렌더링을 확인해야 한다고 정의했습니다.

3. Agent 실행 절차

1. 페이지 진입 2. DOM·접근성·네트워크 확인 3. 사용자 행동 수행 4. 상태 변화 확인 5. 렌더 안정화 대기 6. Screenshot 촬영 7. 식별성·겹침·잘림·대비·반응형 검증 8. 기능·시각·고객여정을 함께 판정

4. Validator 계층

스크린샷 파일, viewport, 시각 판정, 핵심 CTA 식별성, 실제 이미지 존재를 검사했습니다. Pass인데 Visual Result가 없거나 파일 경로만 있고 이미지가 없으면 완료를 거부했습니다.

5. 왜 화면과 DOM을 모두 봐야 하나

투명 Overlay가 버튼을 덮지만 DOM bounding box는 정상일 수 있습니다.
모바일에서 고정 Footer가 CTA를 가릴 수 있습니다.
다크모드에서 색상 상속이 반대로 적용될 수 있습니다.
텍스트는 DOM에 있지만 말줄임으로 행동 의미가 사라질 수 있습니다.
Skeleton이 남아 데이터가 렌더됐어도 사용자에게 보이지 않을 수 있습니다.

결과: “기능적으로 존재하고 클릭된다”를 UI Pass 조건에서 제거하고, 사용자가 실제로 보고 다음 행동을 이해할 수 있는지를 완료조건에 포함했습니다.

Agent가 피곤한 것은 아니지만 긴 세션에서는 최근 작업 맥락이 초반 규칙보다 강해지고, 완료 확률이 높은 최소 행동을 선택하는 경향이 있었습니다. “이번 변경은 단순해서 DOM 확인으로 충분하다” 같은 자체 예외를 허용하지 않도록 워크플로를 설계했습니다.

1. 작업 시작 전 저장소의 기억을 검색

새 작업에 바로 코드를 쓰지 않고 AGENTS, Skill, Validator, 과거 실패 기록, 통과한 선례를 먼저 검색하게 했습니다.

중복 규칙은 비효율이 아니라 과거에 서로 다른 계층으로 도망간 이력을 막는 Defense in Depth였습니다.

2. 단계 전환마다 재동기화

구현 시작 전: 관련 Skill·실패사례·완료조건 재확인
테스트 시작 전: 증적 요구조건과 실행환경 재확인
완료 선언 전: 실제 파일 존재·Validator·Git 상태 확인

3. “완료했습니다”의 구조화

완료 보고에는 변경 파일, 실행 테스트, 기능 결과, 시각 결과, Screenshot 경로, Validator 결과, 미검증 범위와 남은 리스크가 모두 있어야 했습니다. 하나라도 없으면 완료라는 표현을 허용하지 않았습니다.

4. GitLab이 잡은 로컬 착시

Agent가 로컬에서 빌드와 실행이 된다고 푸시했지만 GitLab Clean Runner에서 DLL 누락으로 실패했습니다. 로컬 bin에 과거 빌드 산출물이 남아 있었고 Git에는 포함되지 않았습니다.

교훈: 로컬에서 된다가 아니라, 깨끗한 환경에서 restore·build·test하고 필요한 DLL과 Artifact가 저장소·패키지에 실제 포함됐을 때만 완료입니다.

5. 방어 계층

계층	역할	막는 도주
Skill	무엇을 반드시 해야 하는지 정의	규칙 자체를 모르는 문제
Agent Procedure	실행 순서와 증적 수집 강제	중간 절차 생략
Local Validator	완료 산출물의 형식과 파일 존재 확인	말로만 완료
GitLab Pipeline	Clean Runner에서 빌드·테스트·Artifact 검증	캐시·환경·누락 DLL 의존
Smoke	실제 배포 후 핵심경로 확인	빌드 성공과 운영 성공 혼동

결과: 모델을 신뢰해서 품질을 유지한 것이 아니라, 모델이 기억을 잃거나 편한 경로를 선택해도 완료할 수 없는 시스템을 만들었습니다.

현장 장애는 “소프트웨어 버그” 한 종류로 들어오지 않습니다. 네트워크 지연, 컨베이어 조립, 광학 환경, 펌웨어, PC 온도·진동·클럭, 데이터 동시수정이 같은 증상으로 보일 수 있어 HW·SW·네트워크를 빠르게 분리하는 능력이 필요했습니다.

1. AOI 레거시 랜덤 다운

공유 메모리 기반 프로그램의 랜덤 다운에 대해 전체 장비를 재시작하는 대신 외부 UI Wrapper와 Watchdog으로 실패 프로세스만 부분 재시작하도록 제안·검증했습니다. 고객사 시스템 다운 VOC는 월 3~4건에서 0건으로 감소했고 대형 고객의 쉽백 클레임 취소에 기여했습니다.

2. 네트워크 스토리지 실패 시뮬레이터

고객 환경에서만 발생한다는 이유로 재현을 포기하지 않고 file lock, partial read/write, concurrent modify, freeze 상태를 Python으로 만들었습니다. 총 92종의 장애 케이스를 확보하고 61종에 대해 예외처리 개선을 요청했습니다.

3. 고객 승인 실제 PCB 기반 검증

글로벌 Tier-1 고객 공장장과 보안 책임자의 서면 승인을 받아 민감부품과 좌표정보를 제거한 PCB 4종 12개를 국내에 반출했습니다. 실제 보드로 컨포멀 코팅 알고리즘을 반복 실행하던 중 메모리 누수로 장비가 다운되는 문제를 발견해 고객 시스템 연동 패치에 수정본을 함께 반영했습니다.

4. 직접 수행한 장비 업무

SW 설치와 현장 패치
컨베이어 벨트·모터·광학계 교체
광학계 캘리브레이션과 정밀 계측
보드 펌웨어 업데이트
산업용 PC 선정과 온도·진동·클럭·동작 검증

QA의 역할 정의

마지막에 버튼을 누르며 버그를 세는 사람이 아니라, 고객이 기대한 결과가 실제 환경에서 안정적으로 나오지 않을 모든 경로를 찾아 닫는 사람으로 일했습니다.

결과: 운영환경 재현 불가, 장비 랜덤 다운, 실제 샘플 부족을 테스트 불가 사유로 두지 않고 시뮬레이터·부분복구·정식 샘플 확보로 검증 가능한 입력으로 바꿨습니다.