클라우드 바우처 지원으로 최대 1000만원 지원받고, 아드리엘 대시보드 솔루션 사용해보세요!
클라우드 바우처 지원으로 최대 1,000만원 지원받고, 아드리엘 대시보드 솔루션 사용해보세요!
클라우드 바우처 지원으로 최대 1,000만원 지원받고, 아드리엘 대시보드 솔루션 사용해보세요!
지원 신청하기
최근 생성형 AI가 점점 실체화되면서 이로부터 파생되는 다양한 기술들이 생겨나고 전파되고 있습니다. 그 중 특히 RAG(Retrieval-Augmented Generation) 기반의 AI Agent가 현업에서 접목 시, 효과적이고 쓰이기 좋다는 사례가 많이 있었습니다. RAG는 간단히 말해 방대한 데이터에서 필요한 정보를 검색하고 정리해주는 기술인데, 최근 기술 흐름을 따라가던 중 이를 QA 사이드에서 접목시켜보면 꽤 큰 업무 효율을 이끌어 낼 수 있을 것이라는 아이디어가 떠올랐습니다.
하지만, 단순히 새로운 기술이라고 바로 접목시키고 활용하기보다는, 내부에서 이것이 왜 필요한 상황이었는지에 대한 이해와 합의가 필요했습니다. 저희 아드리엘은 전세계적으로 사용되는 글로벌 마케팅 비즈니스 인텔리전스(BI) 프로덕트를 제공하고 있습니다. 서비스 사용자가 국내뿐만 아니라 해외 여러 국가에 분포해 있고, 프로덕트가 성숙해짐에 따라 요구사항도 다양하고 복잡도가 올라가며 관리해야 할 기능과 이슈들이 점점 더 많아지고 있었습니다. 이에 QA팀 입장에서도 기존 방식만으로는 다채널 커뮤니케이션과 점진적으로 늘어나는 이슈, 히스토리 관리가 어려워졌고, 좀 더 체계적이고 효율적인 관리 방법이 절실했습니다. 그래서 과거에 쌓아둔 버그나 기능 배포 히스토리를 더 효과적으로 활용하기 위해 AI Agent를 도입하게 된 것입니다.
이번 아티클에서는 아드리엘 QA팀이 AI Agent를 어떤 고민으로 시작해서, 어떻게 만들었는지, 그리고 실제 업무에서 어떻게 사용하고 있는지, 개발 과정부터 활용 사례까지 빠짐없이 공유해 보겠습니다.
본격적인 프로젝트로 진행하기 전에 우선 간단한 프로토타입을 만들어서 실제 업무에 효용성이 있는지를 빠르게 확인하는 POC(Proof of Concept)를 진행했습니다. 처음에는 Local 환경에서 Python을 이용해 LangChain과 RAG 기술을 활용한 초기 버전을 개발했습니다. 사실 이 조합은 이미 여러 블로그와 기술 문서에서 검증된 방식이라 구현 자체는 크게 어렵지 않았습니다.
처음 결과는 일부 다듬을 필요가 있었지만, 꽤나 유용했습니다. 이슈에 대한 증상을 키워드 또는 문장으로 질의로 넣으니, 사내 데이터에 의거하여 ‘정황/외부레퍼런스/추론’이 깔끔하게 나오는 것이었습니다. 물론 해당 템플릿은 사전에 명명한 프롬프트에 따라 절차대로 이행된 것이지만요.
이로써 초기 결과물의 품질이 예상보다 높다는 평가와 주변 동료 분들의 피드백을 통해 실제 업무에 충분히 활용 가능하다는 판단을 하게 되었습니다. 특히 CTO와 CEO의 적극적인 관심과 지원 덕분에 QA팀은 이 프로토타입을 기반으로 본격적인 프로젝트로 발전시키기로 결정했습니다.
아드리엘 QA팀은 총 4명으로 구성되어 있습니다. 이번 프로젝트는 코드 작성에 탁월한 역량을 가진 특정 팀원에게 할당하여 개별적으로 진행할 수도 있었지만, 이제는 생성형 AI를 활용하면 학습 허들에 진입 장벽이 낮아 누구나 쉽게 학습하고 조인할 수 있을 거라 판단했습니다. 또한 무엇보다 QA 엔지니어라 할지라도 AI 역량을 반드시 챙겨야하는 시대적 흐름을 고려했을 때, 모든 팀원이 AI 기술의 내부 구조까지 이해하며 업무에 접목하는 것이 중요하다고 생각했습니다. 특히 AI 기반의 툴을 사용할 때 내부 구조를 전혀 모르는 블랙박스 상태보다는 최소한 그레이박스 수준으로 이해하고 활용할 수 있다면 실무에서 더 큰 효과를 발휘할 수 있다고 믿었습니다. 그래서 저희는 QA팀원 모두가 참여하는 방식으로, 팀장은 프로젝트 총괄, 팀원 3명은 세부 태스크를 나누어 각각의 파트를 드릴 다운하는 방식으로 담당하기로 했습니다. 팀 내 역할 분담은 다음과 같이 구성했습니다.
1) 데이터셋 구축 - A 멤버
2) 데이터셋 전처리 - A, B 멤버
3) LLM/데이터 모델 리서치 - B, C 멤버
4) 데이터셋 저장 및 처리 - B, C 멤버
5) 인프라 및 Agent 구현 - C 멤버
이번 프로젝트는 RAG가 주축이었기에 가장 기본적이면서도 중요한 작업은 신뢰할 수 있는 양질의 데이터를 확보하는 것이었습니다. 초기 스크리닝 단계보다 정확하게 이슈 정황을 파악하고, 히스토리를 통해 업무 효율화를 이루는 것을 목표로 삼았습니다. 그렇기에 기존 이슈 데이터와 기능 배포 히스토리를 체계적으로 정리하는 작업부터 시작했습니다. 먼저 Slack에서 운영 중인 버그 리포팅 채널의 데이터를 수집했습니다. 이 채널에는 고객 및 사내에서 보고된 다양한 버그 리포트가 올라와 있었는데요. 메인 메시지뿐만 아니라 댓글까지 포함한 모든 메타 정보를 Slack URL과 함께 추출했습니다. 또한 기능 배포가 이루어졌을 때 공지하는 채널에서는 메인 메시지와 날짜, 메시지 URL도 수집했습니다.
데이터 수집 범위는 최근 2년(2023~2025)으로 정했습니다. 이는 스타트업의 특성상 제품/기능의 생명주기도 비교적 짧은 간격으로 유지되기 때문에 레거시한 데이터는 현재 시스템과 관련성이 떨어질 수 있고, 관리해야 할 데이터 양도 고려해야 하기 때문입니다.
데이터 수집은 Slack API를 통해 이루어졌으며, 수집한 데이터를 보다 편리하게 관리하기 위해 Google Apps Script를 활용했습니다. Apps Script는 비교적 간단한 스크립팅으로 데이터 처리와 자동화를 할 수 있는 클라우드형 플랫폼이며, Google Sheets와 연동으로 데이터 핸들링이 용이했습니다. 또한 트리거를 활용한 스케줄링을 지원하기에 매일 정해진 시간에 자동으로 실행되도록 설정하여 데이터의 최신성을 지속적으로 유지했습니다.
앞 단계에서 데이터를 모았다고 해서 바로 사용할 수 있는 것은 아니였습니다. Slack 메시지의 경우 이모지, 코드 블록, 링크 등 데이터로 사용하기 전 불필요한 메타 데이터를 적절히 수정할 필요가 있었습니다.
우선 Slack 히스토리 데이터 시트를 기반으로, 주요 정보가 담긴 컬럼을 정리하여 학습에 사용할 수 있는 형태로 재구성했습니다. 먼저 언어 통일성을 확보했는데요. QA팀은 외국인 개발자와의 소통을 위해서 Slack 내에서 영어를 사용하고 있지만, 일부는 한국어로 작성된 메시지들도 있어 일관성을 위해 모든 문자열을 영어로 통일했습니다. 이 작업 또한, Apps script를 통해 Google Sheets를 다루는 방식으로 비교적 쉽게 해결했습니다. 이를 통해 AI Agent가 보다 정확하고 일관된 데이터를 기반으로 학습하고 작동할 수 있는 환경을 구축할 수 있었습니다.
그리고 가장 중요한 보안과 관련해서, 초기에는 데이터 보안을 위하여 난수화하는 작업을 위해 리서치 및 일부 진행을 착수하였는데, Agent를 구현 및 활용하는 단계에서 사용되는 OpenAI API는 클라이언트의 비즈니스 데이터를 자사 모델 학습에 활용하지 않는다는 점을 확인했고, 이에 따라 데이터 보호를 위한 난수화 작업이 불필요하다고 판단해 해당 작업을 중단했습니다.
LLM 모델 및 자연어 처리 모델을 선정할 때에는 LLM 리더보드 2025를 참고하여 현존하는 Claude, Gemini 등 다양한 모델 들의 벤치마크 및 옵션을 심도 있게 검토했습니다. 주요 리서치 & 평가 기준으로는 모델의 성능, 비용, 맥락 이해력, 정보 추출 정확도, 응답의 일관성 등을 설정하였습니다.
초기 후보군으로 GPT-4o-mini와 같은 경량화 모델을 고려하였으나, 테스트 결과 일반적인 수준의 컨텍스트조차 제대로 파악하지 못하거나 검색 쿼리 생성에서 부족한 모습을 보였습니다. API를 이용한 구현에서 GPT-4o는 특히 준수한 응답 품질과 안정성을 보였으며, 가장 범용적인 모델로서 활용 가능성이 높다고 판단했습니다. 코드 작성에 뛰어난 Claude의 Sonet 모델도 고려했으나, 현재 Agent가 스크립트를 직접 생성하고 실행할 케이스가 없다고 판단하여 제외했습니다.
GPT-4o보다 상위 모델군의 경우 가격 측면에서 예상 질문의 복잡도 대비 과한 비용을 발생시키는 것으로 판단하여, 비용 효율성을 고려할 때 GPT-4o가 본 프로젝트의 요구사항과 목표에 가장 적합하다고 결론 내렸습니다.
텍스트 데이터를 임베딩하는 과정에서는 OpenAI의 text-embedding-ada-002 모델을 선택했습니다. 이는 데이터 양이 많지 않아서 고성능의 임베딩 모델이 꼭 필요하지 않았고, 특히 로컬에서 모델을 다운받고 실행할 필요 없이 API를 통해 손쉽게 처리가 가능했기 때문입니다. 또한 LLM 또한 OpenAI의 모델로 사용하기로 결정했기 때문에 이와 함께 API 사용량을 모니터링하기 용이하다고 판단했습니다.
벡터 데이터베이스(VectorDB) 선택은 생각보다 많은 고민이 필요했습니다. Pinecone, Chroma, Qdrant 등 여러 옵션을 비교했습니다. 결국 Qdrant를 선택했는데, 주요 이유는 아래와 같습니다.
사실 초기에는 Pinecone도 강력한 후보였습니다. 많은 RAG 튜토리얼에서 사용되고 있고 안정성이 검증된 서비스였기 때문입니다. 하지만 Qdrant의 현재 티어가 우리 규모에 충분했고, 관리 인터페이스가 더 직관적이라 최종 선택되었습니다.
처음 벡터 DB를 구축할 때는 적지 않은 시행착오가 있었습니다. 특히 벡터 차원 설정이나 인덱싱 최적화 같은 부분은 문서를 꼼꼼히 읽고 여러 번 테스트해야 했으며, 임베딩된 벡터를 이해하는 것이 추상적으로 느껴졌기 때문입니다. 다만, Qdrant에서 시각적으로 제공해주는 UI 내 Point 개념을 필두로, Payload & Vectors를 이해하며 기본기를 다잡을 수 있었습니다.
AI Agent를 도입하면서 가장 중요하게 고려한 점은, 실제 업무 환경에 자연스럽게 녹아들 수 있는 시스템을 구축하는 것이었습니다. 사용하기 쉽고 접근성이 높아야 팀원들이 거부감 없이 활용할 수 있다고 판단했기 때문입니다. 초기에는 평소 QA팀에서 필요한 툴, 자동화를 적재하고 사용해왔던 방식인 Streamlit 타입의 별도 웹을 띄우는 방식도 고려해봤지만, 결국 저희가 선택한 건 Slack bot입니다. 그 결과, 구축과 활용하는 두 측면에서 많은 베네핏을 챙길 수 있었습니다.
현재 저희 Agent는 LangGraph 기반의 멀티 에이전트-수퍼바이저 패턴을 따르고 있습니다. 이 패턴은 복잡한 질의응답 과정을 여러 단계로 분리하고, 각 단계가 효율적으로 처리될 수 있도록 도와주는 것이 특징입니다. 물론 아직은 이전 데이터들의 히스토리를 참조하여 답변을 생성하고 가벼운 추론을 하는 Agent만 존재하지만, 근미래에는 다양한 역할을 수행하는 Agent를 부가적으로 생성하고 통합시킬 예정입니다.
아키텍처(Overall)는 아래에 소개드립니다.
1. 사용자 질문 입력(Slack): 아드리엘 멤버가 Slack 채널에서 봇을 멘션하여 쿼리를 입력합니다.
예) "Let me know about budget issue of Instagram connection"
2. Slack Bot(AWS Lambda): 사용자의 쿼리가 Lambda로 전달됩니다. 이때 해당 람다는 질문을 파싱하고 AI Agent로 라우팅하는 역할을 합니다.
3. AI Agent(AWS Lambda): 여기서 실제 쿼리 처리가 이루어집니다. 두 가지 주요 작업을 수행합니다:
4. Qdrant(벡터 DB): S3에서 가져온 지식 베이스가 벡터 형태로 저장되어 있습니다. 질문과 의미적으로 유사한 정보를 찾아 AI Agent에 제공합니다.
5. Amazon S3: 모든 지식 베이스의 원본 데이터가 저장되는 공간입니다. 여기에는 Slack 대화 기록, Notion 문서, Hubspot 데이터 등이 포함됩니다.
6. 지식 소스(Slack, Notion, Hubspot 등): 회사 내 다양한 지식 소스에서 데이터가 주기적으로 S3로 수집됩니다. 이렇게 수집된 데이터는 벡터화되어 Qdrant에 저장됩니다.
7. OpenAI: AI Agent가 Qdrant에서 찾은 관련 정보와 함께 질문을 OpenAI에 전달하면, 자연어 형태의 응답이 생성됩니다.
8. 응답 전달: 생성된 응답이 다시 Slack Bot을 통해 사용자에게 전달됩니다.
Agent의 모니터링의 경우에는 LangSmith를 이용했습니다. LangSmith는 LangChain 기반 AI 애플리케이션의 성능과 비용 효율성을 분석 및 개선할 수 있도록 지원하는 플랫폼입니다. 저희 팀은 이를 통해 내부 사용자들이 주로 처리하는 질의의 패턴을 수집하고 분석하여 Agent의 개선 방향을 구체화하고 있으며, 특히 개발 과정에서 과도하게 토큰을 사용하는 케이스를 조기에 식별하고 수정해 비용 및 리스크를 사전에 완화할 수 있었습니다.
실제 Agent를 활용한 사례는 아래와 같습니다. 프로덕트 이슈, 사용 문의가 인입되었을 때, 1차적으로 과거 데이터를 통해 유사/중복 케이스 여부를 판별하여 스크리닝이 수월했으며, Agent가 전달해주는 관련 레퍼런스를 참조하여 DEV & PM 의사결정을 도모하는데에 일조할 수 있었습니다. 또한 QA가 부재이거나 퇴근 이후에도 글로벌 측의 CSM/Sales 부서에서도 Agent를 직접 활용하여 고객 응대를 원활하게 수행하는 등 업무의 지속성을 확보할 수 있었습니다.
무엇보다 글로벌 시장의 빠른 요구에 따른 제품의 고도화가 지속되는 가운데, 직접 릴리즈에 참여하지 않은 담당자라도 티켓을 처리하는 과정에서 심리적 부담을 크게 덜어주는 점이 가장 큰 이점이라고 생각합니다.
하지만 현재의 Agent 구축과 활용 과정이 녹록치는 않았습니다. 프롬프트 설계, 모델별 AB테스트, 높은 데이터 품질 유지 등 다양한 실험이 요구되었으며, 최적화를 위해 개선에 개선을 거듭해 나가는 과정에 리소스가 소비되었습니다.
AI를 활용한 Agent의 여정은 이제 첫 페이지를 넘긴 단계라고 생각합니다. 앞으로도 더 나은 업무 효율성과 완결성을 지니는 그날까지 지속적인 관심과 개선을 통해 ‘쓰기 좋은, 쓰고 싶은’ AI Agent로 발전시킬 것입니다. 또한, 단순히 Testing을 수행하는 역할에 그치지 않고, 제품과 비즈니스를 깊이 이해하고 파고드는 품질 엔지니어로 더 다양한 영향력을 발휘할 수 있도록 끊임없이 고민하고 성장해 나가고자 합니다.
감사합니다.
- 아드리엘 QA팀 -
%20(1).svg){kind=small}
%20(1).svg){kind=small}
.svg)
