소프트웨어 QA 서비스 소개서 · 2026

IXC는 소프트웨어 QA 부문에서 여섯 가지를 제공합니다. QA 아웃소싱은 테스트 전략 수립부터 실행과 결함 관리, 출시 판단 근거 정리까지 전담 팀이 이어서 맡습니다. 출시 전 QA 검수는 릴리스 후보 빌드 하나를 합의된 범위에서 검증하고 판정을 문서로 남깁니다. 테스트 자동화는 배포마다 되풀이되는 회귀를 자동 테스트 자산으로 옮겨 파이프라인에서 계속 돌립니다. 성능·부하 테스트는 실제 사용 패턴을 부하 모델로 옮겨 시스템이 어디까지 버티는지 확인합니다. QA 프로세스 구축은 품질 기준과 출시 게이트, 자동화 범위를 정해 개발 과정 안에서 돌아가는 체계를 세웁니다. 바이브코딩 검증은 생성형 AI 도구로 만든 서비스에서 빠진 요구사항과 예외 흐름, 변경이 건드리는 회귀 범위를 확인합니다. 여섯 가지는 진단·컨설팅과 실행 대행, 자동화 세 갈래로 묶이고 한 프로젝트에서 이어집니다. 진단으로 세운 판정 잣대를 실행이 그대로 쓰고 실행에서 쌓인 케이스가 자동화 대상이 되므로, 갈래가 바뀔 때마다 자료를 새로 만들지 않습니다.

맡는 것은 실행해서 확인한 동작과 그 결과의 판정입니다. 테스트 전략과 범위 설계, 수동·탐색적 테스트 실행, 결함 분류와 재현 조건 정리, 출시 준비 상태 보고가 여기에 들어갑니다. 맡지 않는 것도 같은 무게로 적습니다. 코드를 읽어 품질을 평가하는 일은 하지 않습니다. 보안 인증이나 컴플라이언스 적합성은 판정하지 않습니다. 결함을 찾아 심각도와 재현 조건까지 붙여 넘기지만 제품 코드를 수정하는 일은 개발 조직의 몫으로 남깁니다. 경계를 앞에서 그어 두지 않으면 검수에 기대한 일과 실제로 한 일이 달라집니다. 종료 시점에 양쪽이 서로 다른 문서를 들고 마주 앉습니다. 확인하지 못한 영역도 결과와 같은 문서에 적습니다. 검증하지 않은 자리를 비워 두면 통과율이 실제보다 넓게 읽힙니다. 판정 잣대는 착수 전에 합의합니다. 무엇이 출시를 막는 결함인지 먼저 정해 두면 같은 결함을 두고 개발과 사업이 다르게 읽는 일이 줄어듭니다.

일하는 순서는 넷입니다. 리스크 진단에서는 제품 흐름과 출시 일정을 함께 검토해 실패 영향이 큰 지점을 착수 5영업일 안에 추려내고 리스크 맵과 검증 우선순위를 전달합니다. 검증 증거 설계에서는 요구사항과 테스트, 결함, 출시 판단을 하나의 추적표로 잇고 판정 잣대를 착수 2주 안에 확정해 테스트 전략서와 함께 넘깁니다. 실행과 개선에서는 합의한 잣대로 검증을 수행하고 주 1회 같은 양식으로 결함과 잔여 리스크를 보고하며 실행 리포트와 결함 대장을 남깁니다. 인수와 정착에서는 테스트 자산과 운영 방식을 내부 팀에 인계하고 인계 후 4주간 질의 대응을 이어갑니다. 리포트는 문서 파일과 원본 데이터를 함께 전달하고 테스트 케이스와 자동화 스크립트는 저장소 접근 권한과 함께 넘깁니다. 네 단계는 계약 형태에 따라 폭이 달라집니다. 빌드 하나를 보는 검수는 네 단계를 짧게 밟고 여러 릴리스를 이어 맡는 계약은 실행과 개선이 반복되면서 자산이 쌓입니다.

출시 판정 어휘는 셋으로 고정합니다. READY, READY WITH CONDITIONS, HOLD입니다. 세 값이 문서에 미리 정의돼 있어야 회의에서 해석이 갈리지 않습니다. 판정 문서에는 시나리오별 결과와 확인하지 못한 영역, 임시 우회 수단과 남은 리스크를 같은 양식으로 적습니다. 연기를 권할 때도 무엇이 갖춰지면 다시 판단하는지를 함께 적습니다. 자동화가 실행 범위를 넓히더라도 판정에는 사람이 책임을 집니다. 검증 결과와 제외 범위, 전제와 잔여 리스크를 검토한 뒤 신민규 CTO가 릴리스 메모에 서명합니다. 2016년부터 제품 개발과 QA를 해 왔고 Tricentis와 Unity 싱가포르, Capgemini 싱가포르, 쏘카를 거쳤습니다. 승인권자는 이 한 장을 회의 자리에서 그대로 읽습니다. 판정 근거는 흩어지지 않게 잇습니다. 요구사항 항목에는 테스트 케이스를, 테스트 결과에는 결함과 조치를, 결함 조치에는 승인 기록을 붙여 한 줄로 따라갈 수 있게 남깁니다.

원격 수행이 기본이고 필요하면 상주도 맡습니다. 사내망에서만 열리는 테스트 환경이라면 계정 발급 범위와 반출 금지 항목을 먼저 정한 뒤 상주 인원과 기간을 정합니다. 인원과 기간은 프로젝트마다 다릅니다. 검증 대상 플랫폼과 단말 조합의 수, 배포와 회귀의 주기, 출시일까지 남은 기간, 자동화 자산의 유무를 보고 정합니다. 인원을 처음부터 끝까지 같은 규모로 두지는 않습니다. 리드 한 명은 계약 기간 내내 고정하고 실행 인력은 구간마다 규모를 조정해 대규모 회귀 구간과 안정화 구간에 맞춥니다. 도구는 검증 대상에 따라 다릅니다. 웹은 Playwright와 Selenium, 모바일은 Appium, 부하 생성은 JMeter를 쓰며 제품의 기술 구성에 맞춰 고릅니다. 내부 QA 조직이 있는 경우에는 책임 경계를 먼저 문서로 나누고 결함 심각도 잣대와 보고 양식을 하나로 맞춥니다. 반복 실행은 자동화와 개발자 테스트로 넘깁니다. 내부 인력은 리스크 설계와 탐색적 검증처럼 판단이 필요한 일을 맡습니다.