QA ENGINEER PORTFOLIO
송윤섭
Yunseob Song
QA ENGINEER PORTFOLIO
Yunseob Song
컴즈 주식회사 · QA Engineer · 2025.02 – 현재
소개

송윤섭
QA Engineer · 컴즈 주식회사
완벽한 대비는 불가능하지만, 확실한 성장은 가능합니다.
경력
컴즈 주식회사
QA Engineer2025.02 – 현재
KB국민은행 KB스타뱅킹 여신 QA
대출(여신) 파트 · 운영 결함 검증2026.02 – 현재
LG CNS 글로벌 이커머스 배포 QA
주 2회 운영 배포 리드2025.02 – 2026.02
자격
ISTQB CTFL2025.06
AICE Basic2024.12
기술
요약
LG CNS 글로벌 이커머스 배포 QA
60→30분
장애 대응 시간
확인 절차를 표준화해 단축
LG CNS 글로벌 이커머스 배포 QA
100+
배포 점검 항목
STG · Alpha · 운영 3단계 검증
KB국민은행 KB스타뱅킹 여신 QA
13건
Major 운영 결함 재현 · 조치 완료
계열 6개 서비스 OS별 점검
QASS 증적 수집 시스템
235→100분
증적 수집 반복 공수
보수적 추정
PRD2TC 테스트 케이스 생성기
약 30분
기획서 1건당 TC 초안 단축
사람의 검토 시간 포함 측정
Postman · Newman API 검증
100%
1,000요청 성공률 · p95 171ms
ISO/IEC 25010 · Apdex 기준
프로젝트
컴즈 주식회사
2025.02 – 현재
LG CNS 글로벌
이커머스 배포 QA
2025.02 – 2026.02
KB국민은행
KB스타뱅킹 여신 QA
2026.02 – 현재
단독 설계 · 개발
2025 – 진행 중
QA 자동화 시스템
One Target · Four Tools
PRD2TC
테스트 케이스 생성기
네이버 로그인
API 테스트
실무 프로젝트 01

글로벌 이커머스 서비스의 운영 배포 전 점검과 배포 후 장애 대응을 맡았습니다. UI·BE·DB 변경과 어드민 설정값을 함께 추적해 배포 여부를 판단했습니다.
60→30분
장애 대응 시간
100+
배포 점검 항목
주 2회
운영 배포 리드
실무 · LG CNS 글로벌 이커머스 배포 QA
결과
60→30분
장애 대응 시간
원인 확인 순서를 정리해, 다른 담당자도 같은 순서로 확인할 수 있도록 절차를 표준화했습니다.
한 일
원인 추적의 첫 단계를 개발자가 아닌 배포 담당자가 맡도록 변경
환경(AEM · Magento · GitLab)과 원인 유형(스택 오버플로 · 문법 · 시스템 오류)별로 정리
GitLab 변경 이력으로 원인을 찾아 개발자에게 전달하고, 재배포까지 관리
AEM 결함은 Adobe에 티켓을 발행하고 기술 문의로 추적
업무 범위
주 2회 운영 배포 · AEM · Magento · GitLab 배포 환경

실무 · LG CNS 글로벌 이커머스 배포 QA
결과
100+
배포 점검 항목
3단계
STG · Alpha · 운영 검증
배포 여부를 감이 아니라 점검 결과로 판단했습니다.
한 일
UI·BE·DB 변경 사항과 어드민 설정값을 하나의 체크리스트로 관리
STG → Alpha → 운영 3단계로 기능 · 시나리오 · 예외 케이스 점검
스모크 테스트와 환경 변수 점검 결과로 배포 여부 결정
릴리즈 점검 진행 상황을 전 세계 법인 담당자에게 공유
개인 프로젝트로 연결
같은 판단 기준을 개인 프로젝트 QA 자동화 시스템의 CI 통과 기준으로 옮겼습니다.


실무 프로젝트 02

KB스타뱅킹 대출(여신) 파트에서 데이터 정합성이 중요한 핵심 로직을 검증하고, 앱 스토어 리뷰로 들어온 오류 제보를 재현해 운영 결함으로 등록합니다.
13건
Major 운영 결함 조치
6개
계열 서비스 OS별 점검
실무 · KB국민은행 KB스타뱅킹 여신 QA
결과
13건
Major 운영 결함 재현 · 조치 완료
6개
계열 서비스 OS별 점검
기능 테스트 범위 밖의 실사용 문제를 리뷰 제보에서 찾아 재현했습니다.
한 일
앱 스토어 리뷰의 오류 제보를 직접 재현해 JIRA에 등록
리브 모바일 · 리브 똑똑 등 계열 6개 서비스를 OS별로 확인
대출(여신) 파트의 데이터 정합성 핵심 로직 검증
실사용 불편 사항을 정리해 운영팀에 개선 제안
개인 프로젝트로 연결
재현 · 캡처 · 기록의 반복을 줄이는 도구로 QASS를 만들었습니다.


개인 프로젝트 01 · One Target · Four Tools


직접 만든 웹 서비스 QASS를 검증 대상으로 고정하고, 도구 4종이 같은 시나리오(로그인 → 방 입장 → 캡처 확인 → 검색)를 검사합니다. 조건이 같아 도구별 안정성과 관리 비용을 같은 기준으로 비교할 수 있습니다.
CI 실행 방식
| 필수 게이트 | Newman · Playwright | 변경마다 실행 |
| 주기 실행 | Selenium | 주 1회 cron |
| 수동 실행 | Appium | 에뮬레이터 비용 고려, dispatch |
개인 프로젝트 01 · QASS (QA Screenshot System)
결과
235→100분
반복 검증 공수 · 보수적 추정
테스트 케이스 실행과 스크린샷 증적 수집을 자동화했습니다.
구성과 기능
Chrome 확장 프로그램으로 캡처하고 대시보드에서 방별로 검색
캡처 화면에 규칙 기반 1차 검수 (한글 맞춤법 · UI 결함 탐지)
자동화 테스트 4종이 같은 시나리오로 검사하는 대상
Vanilla JS · Cloudflare Pages · Supabase(PostgreSQL)
실무에서 연결
결함을 재현하고 증적을 남기는 실무의 반복 작업을 줄이려고 만들었습니다.



개인 프로젝트 02 · PRD2TC v1.1.0
결과
약 30분
기획서 1건당 TC 초안 작성 시간 단축
7 / 10
모델이 채우는 열 — TC ID는 코드, 결과 · 비고는 사람
더미 기획서로 10회 이상, 사람의 검토 시간까지 포함해 측정했습니다.
구조
기획서(pptx) XML을 문단 단위로 분리
10개 열 구조를 코드에 고정
Gemini API로 7개 열 작성
엑셀 테스트 케이스로 출력
출력 예시 요구사항 3건 → 테스트 케이스 6건 (요구사항마다 기본 동작 1건 + 예외 동작 1건)
실무에서 연결
기획서가 바뀔 때마다 테스트 케이스를 다시 쓰고, 작성자마다 기준이 달랐던 경험에서 시작했습니다.



개인 프로젝트 02 · PRD2TC v1.1.0
기획서에 없는 내용을 확정된 사양처럼 쓰는 문제가 문서마다 반복됐습니다. 오류 위치가 모델과 문서 길이에 따라 달라, 사람의 검토를 필수 단계로 남겼습니다.
한계 01
모델이 쓴 내용이 기획서에 실제로 있는지 확인하지 않고, 형식만 맞춰 옮깁니다.
한계 02
장애 영향도나 사용 빈도가 아니라 기획서 문장의 표현 강도를 따라갑니다.
한계 03
문장을 열로 옮긴 형태라 동등분할 · 경계값 분석을 거친 케이스가 나오지 않습니다.
다음 버전
기획서에 없지만 검토할 가치가 있는 케이스는 따로 분류해 검토합니다.
다음 버전
우선순위처럼 값이 정해진 열은 허용값을 코드에 정의하고 매핑합니다.
다음 버전
동등분할 · 경계값 분석 · 상태전이를 도출 기준으로 프롬프트에 명시합니다.
개인 프로젝트 · API 검증 (QASS API · 네이버 로그인 API)
QASS API 부하 검증 · 개인 프로젝트 01
100%
1,000요청 성공률
171ms
p95 응답 시간
네이버 로그인 API · OAuth 2.0 · 개인 프로젝트 03
8건
토큰 상태별 테스트 케이스
112ms
전 요청 최대 응답 · 기준 200ms



