AWS 기술 블로그
키다리스튜디오의 QA 테스트 케이스 생성 자동화 — Amazon Bedrock과 LangGraph 활용 사례
소개
웹툰/웹소설 플랫폼을 운영하는 키다리스튜디오는 레진코믹스, 봄툰 등 다수의 콘텐츠 플랫폼을 서비스하고 있습니다. 플랫폼의 품질을 보장하기 위해 QA 엔지니어링팀은 매 릴리스마다 수백 개의 테스트 케이스(TC)를 수동으로 작성해왔습니다. 숙련된 QA 엔지니어 한 명이 하나의 페이지에 대한 TC를 작성하는 데 3~4시간이 소요되었고, 이는 빠른 릴리스 주기에 큰 병목이 되고 있었습니다.
키다리스튜디오 플랫폼개선팀은 이 문제를 해결하기 위해 Amazon Bedrock의 Claude 모델과 LangGraph 기반 멀티 에이전트 아키텍처를 활용한 테스트 케이스 생성 자동화(Test Case Auto-Creator)를 개발했습니다. 이 시스템은 기획서 URL이나 이미지를 입력받아 QA팀이 즉시 활용할 수 있는 테스트 케이스를 2~5분 만에 자동 생성하며, 초안 커버리지 70~80%를 달성하고 있습니다.
이 블로그에서는 키다리스튜디오가 PoC에서 프로덕션까지 QT 서비스를 성공적으로 자동화한 사례와, 그 과정에서 만난 기술적 도전과 해결 방법을 공유합니다.
배경: 수동 테스트 케이스 작성의 한계
키다리스튜디오의 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 프레임워크를 도입했습니다. LangGraph는 LangChain 위에서 동작하며, 다음과 같은 핵심 기능을 제공합니다:
- 그래프 기반 플로우 아키텍처: 노드 간 조건부 분기(Conditional Edge)와 순환 흐름 지원
- 멀티 에이전트 오케스트레이션: 각 역할에 특화된 에이전트를 독립적으로 구성
- 상태 관리 시스템: LangGraph State 객체를 통한 전역 상태 추적과 에러 핸들링
- Tool Calling: 에이전트가 필요에 따라 외부 도구를 동적으로 호출
멀티 에이전트 설계
키다리스튜디오는 TC 생성 과정을 전문화된 에이전트들의 협업 구조로 재설계 했습니다:
<그림 2. LangGraph 기반 테스트케이스 생성 에이전트 구성도>
각 에이전트의 역할은 다음과 같습니다.
1. Researcher (리서처)
- Playwright를 활용한 웹페이지 접근 및 시각적/텍스트 데이터 수집합니다.
- 일반 링크와 Figma 링크를 구분하여 적절한 처리 로직을 구현했습니다.
- Conditional Edge를 통해 입력 유형(URL, 이미지, 텍스트)에 따라 분기 하도록 합니다.
2. Strategist (전략가) – Human-in-the-Loop
- 리서처의 분석 결과를 바탕으로 TC 생성 영역 구분 및 방향성을 설정 해줍니다.
- 엔지니어가 직접 개입하여 초기 방향성을 검증하여 할루시네이션 문제를 조기 차단할수 있었습니다.
- LangChain v1.0의 미들웨어 기능을 활용한 승인/편집/거부 워크플로우를 구현하였습니다.
3. Director (디렉터)
- 전략가가 설정한 방향에 따라 워커 에이전트에게 구체적인 지시사항 생성
- TC 규모에 따라 워커를 동적으로 확장할 수 있도록 하였습니다.
- 기존 슈퍼바이저 역할을 통합하여 불필요하게 누적되는 Context 를 제거하였습니다.
4. Worker Tool (워커)
- 디렉터의 지시사항에 맞춰 실제 테스트 케이스를 생성합니다.
- 에이전트를 Tool 형태로 구현하여 디렉터가 직접 호출하고 피드백을 받습니다.
5. Finalizer (파이널라이저)
- 모든 워커의 결과를 통합하고 중복을 제거하였습니다.
- QA 엔지니어링팀의 표준 포맷으로 변환하여 Google Sheet에 출력하도록 하였습니다.
핵심 기술적 의사결정
에이전트별 모델 최적 배치 : 비용과 성능의 균형
모든 에이전트가 동일한 모델을 사용할 필요는 없습니다. 키다리스튜디오는 각 에이전트의 업무 경중에 따라 서로 다른 Claude 모델을 배치하여 비용과 성능을 최적화 했습니다.
- Claude 4.6 Opus (Researcher, Strategist) : 복잡한 UI 이미지 분석과 TC 전략 수립은 높은 추론능력이 요구되므로 최상위 모델을 사용하였습니다.
- Claude 4.6 Sonnet ( Director, Worker) : TC 지시사항 생성과 실제 TC 작성은 충분한 품질을 유지하면서도 비용 효율적인 모델인 Sonnet 을 배치하였습니다.
- Claude 4.5 Haiku ( Strategist HITL 과정) : Human-in-the-Loop 단계에서의 간단한 응답 정리와 포맷팅은 경량 모델인 Haiku로도 충분하였습니다.
이처럼 Amazon Bedrock에서 제공하는 다양한 Claude 모델 패밀리를 활용하면, 단일 워크플로우 내에서도 에이전트별로 최적의 모델을 선택할 수 있습니다. 고난도 추론이 필요한 단계에서는 Opus를 , 반복적 생성작업은 Sonnet, 단순 처리업무는 Haiku를 사용함으로써 전체 비용을 절감하면서도 품질을 유지할 수 있도록 하였습니다.
Human-in-the-Loop: 할루시네이션 대응
프로젝트 초기에 LLM이 복잡한 UI 이미지를 분석하면서 아이콘을 오인식하는 등 할루시네이션 문제가 발생했습니다. 이 문제는 초기 단계에서 발생하면, 이후 모든 에이전트의 결과물에 영향을 미쳤습니다.
해결방안으로 LLM 전처리 결과를 엔지니어가 검증하는 Strategist 노드를 추가했습니다.
<그림 3. 할루시네이션 대응 전략>
이를 통해 할루시네이션이 후속 단계로 전파되는 것을 차단하면서도, 엔지니어의 개입을 최소화했습니다.
Context 비효율 제거: 슈퍼바이저 역할 통합
초기 설계에서는 디렉터(지시)와 슈퍼바이저(검수)가 분리되어 있었으나, 두 에이전트 간 Context 전달 과정에서 모호함이 발생했습니다. LangChain v1.0의 create_agent 아키텍처를 활용하여 디렉터가 워커를 Tool로 직접 호출하고 결과를 검수하는 구조로 통합했습니다. 이를 통해 불필요한 Context 읽기/쓰기를 제거하고 효율을 높였습니다.
입력 방식 다각화
기획서 포맷이 팀마다 다양한 점(일반 기획서, 디자인 이미지만 있는 경우, 텍스트만 있는 경우)이 큰 제약이었습니다. 이를 해결하기 위해 **입력 소스 분기 라우터(Router)**를 LangGraph 진입점에 구현했습니다:
- URL 입력: Playwright로 웹페이지 접근 후 이미지/텍스트 자동 추출
- Figma 링크: Figma Token을 활용한 디자인 문서 직접 로드
- 이미지 직접 업로드: Slack을 통해 이미지 파일을 업로드하면 인프라 플로우로 전달
- 텍스트 입력: 기획서 텍스트를 직접 입력
인프라: 온프레미스에서 AWS 클라우드로
기존에는 온프레미스 테스트 머신에서 배치 트리거 방식으로 동작했으나, 단일 장비 장애 시 전체 서비스가 중단되는 문제가 있었습니다. 팀은 다음과 같은 요구사항을 기반으로 AWS 클라우드 인프라를 설계했습니다:
- 운영이 아닌 서포트 프로그램이므로 서버리스(Serverless) 지향
- LangChain, Playwright 등 무거운 라이브러리로 인해 Lambda 단독 활용 불가
- 고정 리소스 소모를 최소화하여 비용 효율성 확보
AWS 클라우드에서 구현된 최종 아키텍처는 다음과 같습니다.
<그림 4. Slack-Ops 환경 구성도>
이미 운영 중이던 AWS EKS 클러스터를 활용하여, Slack에서 요청이 들어오면 API Gateway와 Lambda가 트리거 역할을 하고, 실제 LangGraph 워크플로우는 EKS Pod에서 실행되는 구조를 채택했습니다. 이를 통해 별도의 고정 서버 비용 없이 요청 시에만 리소스를 사용하는 효율적인 운영이 가능해졌습니다. 인증/인가 체계로는 Slack SIGNING_SECRET을 통한 Lambda 내부 인증과 Slack ID 기반 Command Filtering을 적용했습니다.
활용 결과
정량적 성과
| 지표 | 기존 (수동) | TC Auto-Creator | 개선 효과 |
|---|---|---|---|
| TC 작성 시간 | 3~4시간 (숙련 QA 엔지니어 기준) | 2~5분 | 최대 약 120배, 98% 시간 절감 |
| 초안 커버리지 | – | 70~80% | QA팀 블라인드 피드백 기준 |
| TC 1개당 비용 | – | 5원~12원 | 인풋 데이터 크기에 따라 변동 |
| 120개 TC 생성 비용 | – | 600~1,400원 | – |
정성적 피드백 (QA 엔지니어링팀 블라인드 피드백)
“TC 문서 작성 시간 대폭 단축”
“대/중/소 구조 자동 분류 기능이 매우 유용”
“기능 테스트 중심으로 구성되어 실제 테스트 진행에 적합한 구조로 제공됨”
“다양한 케이스가 자동으로 생성되어 예외 상황까지 폭넓게 커버할 수 있음”
나머지 20~30%는 추가 로직을 통한 TC 추가/보완으로 대응하며, 기존 TC 이외의 엣지 케이스 발굴에도 활용되고 있습니다.
개선 과정에서 얻은 교훈
1. 반복적 개선의 중요성
키다리스튜디오의 TC Auto-Creator는 한 번에 완성된 것이 아닙니다. “기술 반영 → 개선 사항 발견 → 고민 → 기술 반영“의 순환을 통해 지속적으로 발전했습니다: 지금까지의 작업들은 아래에서 보시는 바와 같이, 여러단계로 진행되면서 완성도를 높일수 있었습니다.
- PoC: LangChain 기반 단순 파이프라인
- 1차 개선: LangGraph 적용, 멀티 에이전트 구조, AWS 인프라 구축
- 2차 개선: 입력 방식 다각화 (URL/이미지/텍스트), 워커 오케스트레이션 동적화
- 3차 개선: Human-in-the-Loop 도입, LangChain v1.0 업그레이드로 효율화
2. LLM의 한계를 인정하고 사람과 협업하라
할루시네이션 문제를 프롬프트 튜닝만으로 해결하려 하기보다, 엔지니어가 핵심 의사결정 지점에 개입하는 Human-in-the-Loop 설계가 더 효과적이었습니다. 모든 것을 자동화하는 대신, 자동화와 인간 검증의 적절한 균형점을 찾는 것이 중요합니다.
3. 에이전트 역할 설계는 조직 구조를 반영한다
TC 생성 과정을 리서처 → 전략가 → 디렉터 → 워커 → 파이널라이저로 분리한 것은, 실제 QA 조직에서 업무를 분담하는 방식과 유사합니다. 에이전트를 설계할 때 실제 업무 프로세스를 참고하면 더 자연스럽고 효과적인 시스템을 구축할 수 있습니다.
사용된 AWS 서비스
| 서비스 | 용도 |
|---|---|
| Amazon Bedrock | Claude 4.0 Sonnet 모델을 통한 UI 분석 및 TC 생성 |
| Amazon EKS | LangGraph 멀티 에이전트 워크플로우 실행 환경 |
| AWS Lambda | Slack 이벤트 수신 및 EKS 작업 트리거 |
| Amazon API Gateway | Slack Webhook 엔드포인트 |
| Amazon S3 | 작업 결과물 데이터베이스 기록 |
Next Step
키다리스튜디오는 TC Auto-Creator를 더욱 발전시키기 위해 다음 단계를 계획하고 있습니다:
- RAG 기반 테스트 케이스 생성:
- 플랫폼의 레퍼런스 TC와 정책 정보를 지식 베이스로 구축하여, 도메인 특화 TC를 생성
- 피처·시나리오·정책 베이스라인 등을 엔티티 구조로 정형화한 도메인 관계도를 구축하여, 단순 문서 검색 기반 보다 정밀한 컨텍스트를 에이전트에게 주입
- 기능 유형(인증·결제·콘텐츠 등)에 따라 적용해야 할 테스트 차원이 달라지는 점을 반영하여, 기능별로 최적의 테스트 관점을 자동 매핑
- 자연어 기반 테스트 자동 실행:
- 화면의 접근성 트리를 LLM에 함께 전달하여, 동일한 기능의 디자인 변경으로 위치나 모양이 바뀌어도 대응하는 자가 복구 흐름을 구현
단계별 결과를 텍스트 매칭·스크린샷 비교·응답 값·LLM 판단의 다층 구조로 검증하여, 단순 통과/실패가 아닌 신뢰도 기반의 정성적 결과(통과/실패/리뷰 필요)를 제공
- 화면의 접근성 트리를 LLM에 함께 전달하여, 동일한 기능의 디자인 변경으로 위치나 모양이 바뀌어도 대응하는 자가 복구 흐름을 구현
마무리
키다리스튜디오의 사례는 생성형 AI를 단순한 텍스트 생성 도구를 넘어, 복잡한 업무 프로세스를 자동화하는 멀티 에이전트 시스템으로 활용할 수 있음을 보여 줍니다. Amazon Bedrock의 Claude 모델과 LangGraph를 결합하면, 기존에 수 시간이 걸리던 전문 업무를 분 단위로 처리할 수 있습니다. 특히 이 프로젝트는 PoC에서 시작하여 실제 프로덕션 환경에서 QA엔지니어가 사용하는 도구로 발전하여, 키다리 스튜디오 뿐 아니라 키움 그룹사 전반 에서도 의미 있는 AI 적용 사례로 공유되었습니다. 완벽한 자동화 보다는 필요한 지점에서의 엔지니어 개입을 통한 품질 보장, 반복적 기술 개선을 통한 점진적 발전이 이 프로젝트를 지탱해 온 두 축입니다. 조직 내에 반복적이고 전문성이 요구되는 업무가 있다면, 멀티 에이전트 아키텍처를 통한 자동화 워크플로우 구축을 검토해 보시길 권합니다.