DEVOCEAN

1. Intro: 에이닷 4.0의 큰 변화

에이닷은 일상의 다양한 순간을 함께하는 SK텔레콤의 AI 비서 서비스입니다.

이번 4.0 버전은 단순 업데이트가 아니라, 에이닷의 ‘두뇌’를 바꾸는 수준의 전면 개편이었습니다.

• 뮤직, 증권, 에이닷 대화방 등 N개의 대화방 → 원 에이전트로의 변화

• 대화의 자연스러움 → GPT 기반 LLM으로 고도화

• 맛집, 일정, 뉴스, 날씨 등 15개 이상 도메인 동시 응답 가능

• 새로운 UX 흐름, 메모리/Rewrite구조 개선, 멀티턴 대응 등의 대규모 변화

이처럼 에이닷이 더 ‘사람처럼’ 진화하면서, 품질검증 방식도 바뀌어야 했습니다.

QE팀은 “버튼을 눌러 기능을 확인하던 시대”를 넘어, 이제는 AI가 잘 말하고 있는지를 평가하는 역할까지 맡게 된 것입니다.

이런 변화 속에서, 우리는 어떻게 에이닷의 품질을 담보했을까?

지금부터, 에이닷 QE팀의 뒷 이야기를 풀어보겠습니다.

2. QA는 처음부터 함께 시작합니다

프로세스 변화의 노력

올해 초부터, 에이닷 조직 내에서는 Dev존 구축, 기획자 Sanity Test 도입을 통해 프로세스를 개선 노력을 시작했습니다.

Sanity Test란?

기획자가 본인이 작성한 기획안이 실제 화면 흐름과 구현 방향에 맞게 반영되고 있는지를 직접 확인해보는 단계입니다.

이번 4.0 개편에서는 이 Sanity Test가 본격적으로 작동하면서, 기획/디자인/개발/QA가 초기부터 함께 품질을 확보 했습니다.

• 화면 전환 흐름에 UX 충돌이 생기는 경우

• 기획 누락이나 중복되는 도메인 동작

• 기획 의도가 사용자 맥락에서 오해될 수 있는 부분 등

이런 이슈들을 실제 구현되기 전에 걸러낼 수 있었고, 덕분에 본 QA 단계에서는 ‘예상 못한 오류’ 없이 검증에만 집중할 수 있었습니다.

Shift Left QA의 첫 걸음: 노트, 일정 도메인 참여 사례

이번 개편에서는 특히 변경 폭이 컸던 ‘노트’, ‘일정’ 도메인에 대해 QA가 기획 단계부터 참여했습니다.

• 기획 회의에 QA가 참여해 도메인별 흐름/사용자 케이스를 함께 정의

• 어떤 경우에 문제가 발생할 수 있을지 선제적으로 리스크를 제기

• 부족한 시간이지만, 기획/개발 검토 시점에 같이 확인하며 테스트케이스 설계 준비

• 출시 직전엔 QA가 도메인의 ‘내부자’처럼 작동

이러한 선제적 개입은 개발 효율성 향상은 물론, QA가 단순 테스터에 그치지 않고 제품 완성도를 함께 설계하는 역할로 자리매김할 수 있는 계기가 되었습니다.

이렇게 QA는 기획 초기에 개입하여 방향을 잡고, 릴리즈 직전에는 치밀하게 점검하며,

서비스 출시 이후에도 피드백을 기반으로 개선점을 추적하는 제품 생애주기 전체의 동반자로 진화하고자 노력하고 있습니다.

3. 버튼을 누르지 않고도 테스트할 수 있을까?

이번 버전부터 에이닷은 LLM 기반 멀티모달 플랫폼 위에서 동작합니다. 특히 두 가지 주요 변화가 품질 검증 방식까지 바꾸는 계기가 되었습니다.

1. 메모리 도입

   • 사용자와의 대화를 이전 맥락까지 기억하며 이어갈 수 있게 됨

   • 예: “그 영화 예고편 보여줘” → 직전 대화에서 영화 제목 기억 후 이어 응답

2. Rewrite

   • 사용자의 발화를 LLM이 내부적으로 재작성하여 의도를 명확히 파악하고

   • 적절한 기능(도메인)으로 연결해주는 Rewrite 도입

   • 예: “엄마 생일 선물 추천해줘” → ‘메모리에 저장된 엄마가 좋아하는 정보 기반으로 발화를 Rewirte → "엄마 생일 선물 추천해줘. 엄마는 자잘한 꽃무늬가 들어간 것들을 좋아해."

이처럼 LLM이 ‘추론(reasoning)’하는 구조로 진화하면서, QA 역시 단순 클릭 테스트가 아닌 언어와 맥락을 이해하고 응답을 판단하는 테스트로 바뀌었습니다.

그래서 QE팀은 기존의 기능 테스트를 넘어서, 각 LLM 응답 품질 확인을 위해 다음과 같은 방식으로 검증을 수행했습니다.

사용자 발화 기반 시나리오 작성

QA는 각 도메인의 기능을 검증하기 위해, 실제 사용자가 할 법한 발화를 중심으로 발화셋을 구성했습니다.

• 단순 텍스트 입력이 아닌, 위치, 시간, 맥락을 고려한 실제 사용자 발화 기반 테스트

• 기능 동작뿐 아니라 응답 자연스러움, 불필요한 정보 여부까지 평가

LLM 응답 평가 : SPeCTRA

QA팀은 AI 응답을 평가하기 위한 내부 기준 SPeCTRA를 발전시킨 2.0을 도입했습니다.

SPeCTRA 2.0이란?

AI 응답을 판단 하는 5가지 핵심 요소

QE팀은 위에서 생성한 발화셋을 기반으로 대규모 자동화 테스트를 실행하고, 모델이 생성한 응답을 수집하여 SPeCTRA 기준에 따라 평가했습니다.

응답 결과는 항목별로 채점 하여 모델 배포시마다 평가 점수를 공유하여 현재 품질 현황을 알렸고, 필요한 경우 문제점을 리포트하여 개선할 수 있도록 했습니다.

이러한 구조 덕분에 모델 구조가 변경되거나 Rewrite가 개선될 때에도 수천 건의 응답을 단시간에 검토할 수 있어 수정 배포 영향성을 빠르게 파악할 수 있었습니다.

4. QA는 언제나 품질의 마지막 보루

에이닷 4.0은 기능 구조와 모델 응답 방식이 함께 개편된 대규모 프로젝트였지만, 그에 비해 주어진 일정은 결코 넉넉하지 않았습니다.

개발이 진행될수록 기능 이슈와 모델 응답 이슈가 동시에 발생했고, 무엇부터 어떻게 점검하고 정리해야 할지에 대한 전반적인 품질 가이드가 절실한 상황이었습니다.

QE팀은 프로젝트 후반부에 접어들면서 daily report를 도입했습니다.

실제 daily report 발송 내용

매일 아침, 현재까지 발견된 이슈들을 유형별로 분류하고, 모델 응답 관련 문제는 어떤 항목에서 주로 발생하고 있는지 기능 영역 중 남아있는 이슈는 몇 건인지

전반적인 통과율과 영향도를 종합적으로 정리해 모든 구성원이 직관적으로 품질 상태를 파악할 수 있도록 했습니다.

이러한 리포트는 단순한 수치 나열이 아니라, 그날그날 가장 중요한 품질 포인트를 짚고 우선순위를 명확히 공유하는 도구로 활용됐습니다.

덕분에 실무자 모두가 같은 기준을 갖고 움직일 수 있었고, 이슈 개선 속도에도 눈에 띄는 변화가 생겼습니다.

QA는 제품을 ‘확정짓는’ 마지막 프로세스에 존재하기 때문에 기한이 촉박하거나, 모든 준비가 완벽하지 않은 상황에서도 최종 품질을 책임질 수밖에 없습니다.

때로는 반복적인 요청이나 일정 압박으로 인해 채찍질처럼 느껴질 수밖에 없었던 순간도 있었지만,

그 모든 과정의 바탕에는 사용자에게 더 나은, 더 유의미한 에이닷을 제공하겠다는 공통의 목표가 있었다고 생각합니다.

그 목표를 끝까지 놓지 않고 함께 달려온 결과, 지금의 에이닷 4.0이 완성될 수 있었습니다.

5. 마무리: AI 품질은, 사람이 만든다

에이닷 4.0의 QA는 단순히 기능을 점검하는 테스트에 그치지 않았습니다.

기획 초기 단계부터 참여해 사용자 시나리오를 함께 검토하고, 모델 응답을 실제 발화 기반으로 평가하며, 매일 변화하는 품질 상황을 공유하고 방향을 조율하는 과정까지,

AI가 신뢰할 수 있는 응답을 하기 위해 필요한 모든 과정을 사람의 손으로 다듬어 왔습니다.

이번 프로젝트를 통해 QA는 더 이상 ‘마지막 점검자’가 아니라, 기획과 개발 사이에서 품질의 기준을 제시하고, 테스트 흐름과 우선순위를 정리하며 프로세스를 주도해 나갔습니다.

에이닷 4.0을 통해 축적한 경험을 바탕으로, QE팀은 더 고도화된 테스트 전략과 자동화 체계, 그리고 실 사용자 관점의 평가 기준으로 품질을 확보하여 더 발전해나가겠습니다.

QE팀의 여정 지켜봐주세요.

[참고] 에이닷 4.0 출시 관련 기사

https://news.sktelecom.com/214319