Search

키다리스튜디오의 QA 테스트 케이스 생성 자동화 — Amazon Bedrock과 LangGraph 활용 사례

URL
생성 일시
2026/05/06 12:55
최종 편집 일시
2026/05/06 12:55
태그
AWS
파일과 미디어
소개 웹툰/웹소설 플랫폼을 운영하는 키다리스튜디오는 레진코믹스, 봄툰 등 다수의 콘텐츠 플랫폼을 서비스하고 있습니다. 플랫폼의 품질을 보장하기 위해 QA 엔지니어링팀은 매 릴리스마다 수백 개의 테스트 케이스(TC)를 수동으로 작성해왔습니다. 숙련된 QA 엔지니어 한 명이 하나의 페이지에 대한 TC를 작성하는 데 3~4시간이 소요되었고, 이는 빠른 릴리스 주기에 큰 병목이 되고 있었습니다. 키다리스튜디오 AX 개발팀은 이 문제를 해결하기 위해 […] || 소개 웹툰/웹소설 플랫폼을 운영하는 키다리스튜디오는 레진코믹스, 봄툰 등 다수의 콘텐츠 플랫폼을 서비스하고 있습니다. 플랫폼의 품질을 보장하기 위해 QA 엔지니어링팀은 매 릴리스마다 수백 개의 테스트 케이스(TC)를 수동으로 작성해왔습니다. 숙련된 QA 엔지니어 한 명이 하나의 페이지에 대한 TC를 작성하는 데 3~4시간이 소요되었고, 이는 빠른 릴리스 주기에 큰 병목이 되고 있었습니다. 키다리스튜디오 AX 개발팀은 이 문제를 해결하기 위해 Amazon Bedrock의 Claude 모델과 LangGraph 기반 멀티 에이전트 아키텍처를 활용한 테스트 케이스 생성 자동화(Test Case Auto-Creator)를 개발했습니다.  이 시스템은 운영 URL이나 UI이미지, 기획서를 입력받아 QA팀이 즉시 활용할 수 있는 테스트 케이스를 2~5분 만에 자동 생성하며, 초안 커버리지 70~80%를 달성하고 있습니다. 이 블로그에서는 키다리스튜디오가 PoC에서 프로덕션까지 QA 역할을 성공적으로 효율화한 사례와, 그 과정에서 만난 기술적 도전과 해결 방법을 공유합니다 배경: 수동 테스트 케이스 작성의 한계 키다리스튜디오의 QA팀은 다음과 같은 과제에 직면해 있었습니다: 작성 시간: QA 엔지니어가 기획서 한 페이지에 대한 TC를 작성하는 데 평균 2~4시간이 소요 품질 편차: 엔지니어마다 작성 스타일과 커버리지가 달라, 일관된 품질 편차 발생 확장성 제약: 신규 기능이 빠르게 추가되는 환경에서 TC 작성이 릴리스 일정의 병목 이에 AX 개발팀은 “테스트 케이스 작성의 일정 부분은 LLM이 효율적이고 빠르게 생성할 수 있지 않을까?”라는 질문에서 프로젝트를 시작했습니다. PoC: LangChain 기반의 첫 번째 시도 초기 아키텍처 초기 PoC는 LangChain을 활용한 단순한 직선형 파이프라인으로 구성 되었습니다: Slack을 통한 요청 접수: 사용자가 Slackbot에 페이지 링크와 설명 키워드를 전달 Playwright를 통한 이미지 추출: 대상 페이지의 UI 스크린샷을 캡처하고 전처리 Amazon Bedrock (Claude Sonnet 4.0) 호출: 이미지와 질문을 입력으로 LLM에 TC 생성 요청 결과 출력: Google Sheet에 TC를 포맷팅하여 전달, Slack으로 결과 링크를 공유 <그림 1. POC 아키택처> PoC에서 드러난 여러가지 한계 PoC를 통해 LLM 기반 TC 생성의 가능성은 확인했지만, 프로덕션 수준으로 발전시키기 위한 여러 한계가 드러났습니다: 구분 한계점 상세 프로세스 LangChain의 일방향 처리 입력 → 처리 → 출력의 단순 순차 흐름만 지원. 피드백 루프나 조건 분기 구현 불가 LLM 역할 단일 LLM 호출의 한계 UI 분석, 맥락 이해, TC 생성을 하나의 호출로 처리하여 품질 저하 상태 관리 State Management 부재 오류 발생 시 특정 지점부터 재시도 불가, 상태 추적 어려움 출력 포맷 QA팀 표준과 불일치 최종 산출물이 QA팀에서 바로 활용하기 어려운 형태 인프라 온프레미스 테스트 머신 의존 단일 장비 장애 시 전체 서비스 중단, 확장성 부재 프로덕션으로의 진화: LangGraph 멀티 에이전트 아키텍처 LangGraph를 선택한 이유 PoC의 한계를 극복하기 위해 팀은 LangGraph 프레임워크를 도입