Engineering
NOL QA, 한계를 넘다 — 24시간 일하는 신입사원 ‘Q-pid’ 채용 스토리
2025년 11월 21일
원문에서 보기 ↗
이 이미지는 생성형 AI를 활용해 제작하였습니다.
안녕하세요, NOL QA팀입니다!
지난번 포스트맨에서 젠킨스까지: QA 팀의 API 테스트 자동화, 파란만장 성장기에서 Postman과 Jenkins로 API 테스트 자동화를 구축하며 겪었던 파란만장한 여정, 다들 기억하시나요? 😉
오늘은 바로 그 후속편! QA팀의 업무 방식을 또 한 번 혁신한 아주 특별한 ‘신입사원’ 이야기를 들려드리려고 해요. 24시간 지치지 않고, 모든 질문에 ‘칼답’하며, 업무 효율을 극대화하는 역대급 인재랍니다! 바로 QA팀이 직접 개발한 리소스 관리 AI 비서, ‘Q-pid(이하 큐피드)’입니다.
● Q-pid: QA팀의 모든 질문(Question)에 큐피드의 화살처럼 빠른(Quick) 피드백(Feedback)을 제공한다는 의미를 담고 있습니다.
단순하고 반복되는 문의에 더 이상 시간을 낭비할 수 없다! 이 업무를 전담할 AI 동료를 ‘채용’하기로 한 QA팀의 고민과 그 기술적인 해결 과정을 생생하게 들려드릴게요. 자, 그럼 저희의 ‘신입사원 큐피드 채용기’ 속으로 또 한 번 풍덩 빠져볼까요?
1. 왜 큐피드를 ‘채용’할 수밖에 없었나?
API 테스트 자동화로 기술적인 효율은 얻었지만, QA 팀에겐 또 다른 ‘시간 도둑’이 기다리고 있었어요. 바로 PM, 개발팀 등 다양한 협업 부서로부터 쏟아지는 ‘QA 리소스 및 일정’ 관련 문의였죠. 이 문제를 해결해 줄 전문가, 즉 AI 비서의 채용이 시급했답니다.
“혹시 QA 리소스 투입이 가능할까요?”의 굴레
- 쉴 새 없이 울리는 문의 알람 😵: “~~기능 개발 프로젝트를, ~~일자에 QA 시작할 수 있나요?” PM과 개발팀에서 수시로 들어오는 이 질문, 단순해 보이지만 리더 입장에서는 즉답하기가 정말 어려웠어요. 왜냐하면 이 한마디에 답하려면, QA 리더는 팀원 개개인의 현재 업무 현황, 예정된 다른 프로젝트의 QA 일정, 휴가 계획, 그리고 예상치 못한 긴급 이슈까지 모두 파악하고 있어야 했거든요. 단순 문의 하나가 리더의 집중력을 흩트리고, 결국 복잡한 상황 분석이 필요한 고된 업무로 바뀌는 순간이었죠.
- 흩어진 정보, 느려지는 의사결정 ⏳: QA 리소스 현황은 Jira, 팀 공유 캘린더, 개인별 업무 현황표 등 여러 곳에 흩어져 있었어요. 실시간 변동 사항까지 완벽하게 동기화되지 않는 경우가 많아, 정확한 가용 리소스를 파악하는 데 시간이 꽤 걸렸죠. 결국 요청부서에서는 답변을 기다리며 다음 계획을 세우지 못하고, QA 리더는 정확한 답변을 위해 여러 채널을 오가며 시간을 허비해야 하는 비효율이 반복됐답니다.
- ‘운영’에 발목 잡히는 리더십 🏃: 이런 즉흥적인 문의 응대는 QA팀이 주도적으로 테스트 계획을 수립하고 리스크를 관리하는 ‘Proactive’한 업무가 아닌, 들어오는 요청을 처리하기에 급급한 ‘Reactive’한 조직으로 만들었어요. 장기적인 품질 전략이나 프로세스 개선보다, 당장의 ‘일정 조율’이라는 운영 업무에 매몰될 수밖에 없었죠.
이런 문제들을 겪으면서, 모든 상황을 즉시 파악하고 답변해 줄 수 있는 존재가 필요하다는 결론에 이르렀어요. 그래서 매번 여러 시스템을 뒤져 조율해야 했던 리소스 문의 업무를 전담할 AI 동료, 큐피드를 ‘채용’하기로 결심했답니다!
2. 기술로 빚어낸 새로운 동료: 코드에 ‘판단력’을 불어넣었어요!
QA 팀의 고충을 해결하기 위한 여정은 ‘어떻게 하면 가장 빠르고 정확하게 리소스 현황을 파악할 수 있을까?’라는 질문에서 시작됐어요. 복잡한 시스템을 덕지덕지 붙이는 대신, Jira 와 OpenAI API라는 단순하고 강력한 조합을 선택해서, 팀의 작업 방식을 실질적으로 혁신하는 데 집중했죠.
2.1. 큐피드, 이렇게 생겼어요. (LLM 중심의 2-Step 프로세스)
큐피드는 여러 모듈을 복잡하게 엮는 대신, 똑똑한 LLM(대규모 언어 모델)의 능력을 극대화하는 간결한 2단계 파이프라인 구조를 채택했어요.

(수습 큐피드의 첫 화면)
● 사용자 인터페이스 (Web UI): 모든 팀원이 언제 어디서든 쉽게 접근할 수 있도록 친숙한 웹 페이지 형태로 만들었어요. Python의 Flask 프레임워크가 웹 요청을 처리하고, HTML과 Tailwind CSS로 깔끔한 UI를 구성했죠.
“Tailwind CSS는 미리 디자인된 다양한 스타일 클래스를 제공하여, 개발자가 직접 CSS 코드를 작성하지 않고도 빠르고 일관된 디자인을 적용할 수 있게 도와주는 도구입니다.”
● 1단계: 질문의 ‘의도’ 파악하기: 사용자가 질문을 입력하면, 백엔드는 첫 번째로 OpenAI API를 호출해요. 이때 AI에게 주어진 임무는 딱 하나, 바로 ‘질문 의도 파악’ 이예요. “이 질문이 리소스(Jira 티켓으로 관리하는 QA의 분석/수행 일정) 조회에 관한 건지, 일반적인 질문인지, 아니면 지원하지 않는 내용인지 판단해!” 라는 것이었죠. 이 단계 덕분에 큐피드는 마치 사람처럼 다음에 무엇을 해야 할지 스스로 결정한답니다.
● 2단계: ‘데이터’ 기반으로 ‘분석’하고 ‘답변’하기:
- 데이터 조회 (Retrieval): 질문이 ‘Jira 리소스 조회’로 판단되면, 큐피드는 requests 라이브러리를 통해 실시간으로 Jira API를 호출해요. QA팀이 작업리소스와 휴가를 Jira 티켓으로 관리하고 있기 때문에 JQL을 사용해 현재 진행 중인 모든 QA 업무와 휴가 티켓 정보를 즉시 가져올 수 있어요. 가져온 티켓 정보에서는 assignee, summary, startDate, endDate, status 정보를 추출하여 답변을 위한 핵심 기반 데이터로 활용해요.
- 데이터 분석 및 답변 구성 (Augmented Generation): 그 다음, 조회된 최신 Jira 데이터를 질문과 함께 두 번째 OpenAI API에 전달해요. 이때 AI에게는 “너는 우리 팀의 리소스 매니저야. 이 데이터를 분석해서 투입 가능 인원을 찾아내!” 라는 구체적인 역할과 분석 지침을 부여한답니다. 이 과정을 통해 AI는 단순히 정보를 나열하는 걸 넘어, 주어진 데이터를 ‘해석’하고 ‘판단’해서 최종 답변을 만들어내요.
이 구조는 LLM을 단순한 ‘대화 모델’이 아닌, ‘의사결정 엔진’과 ‘데이터 분석가’로 활용하는 큐피드의 핵심 전략이랍니다!
2.2. 핵심 기술 스택 및 구현 상세
Python을 주 언어로, Flask와 OpenAI API라는 두 개의 큰 축을 중심으로 큐피드를 구현했어요.
- 웹 서버와 UI (Flask): Flask를 사용해 간단한 웹 서버를 구축하고, 사용자가 질문을 입력할 수 있는 index.html 페이지를 제공해요. render_template 함수가 이 역할을 수행하죠.
# qpid.py
from flask import Flask, request, jsonify, render_template
app = Flask(__name__)
@app.route('/')
def index():
return render_template('index.html')
- 프론트엔드에서는 fetch API를 사용해 백엔드와 비동기적으로 통신하며, 로딩 상태를 보여주는 등 사용자 경험도 세심하게 챙겼답니다.

(열일중인 큐피드의 답변 생성중 화면)
💡 실수 방지 Tip #1: 민감 정보 관리, AI 프로젝트 협업의 첫걸음
큐피드 개발 초기, 여러 API 키와 계정 정보가 얽히면서 테스트 환경에서 키가 꼬이는 작은 해프닝이 있었습니다. 이때 .env 파일을 활용한 환경변수 분리가 단순히 ‘보안’을 넘어, ‘안정적인 협업 환경’을 위한 필수 규칙임을 깨달았습니다. 각자 다른 API 키를 사용하더라도 동일한 코드베이스로 작업할 수 있게 해주어, 팀 개발의 안정성을 크게 높여주었죠. AI 프로젝트처럼 여러 외부 서비스를 연동할 때는 특히 더 중요하답니다.
또한, 초기 코드는 기본적인 기능만 있었지만, Gemini에게 “이 함수에 네트워크 오류, HTTP 에러, 데이터 누락에 대한 예외 처리를 추가해서 더 안정적으로 만들어줘” 라고 요청하여 아래와 같이 견고한 코드로 리팩토링할 수 있었습니다.
# qpid.py
def execute_jql_query(jql_query: str):
"""
주어진 JQL 쿼리를 사용하여 Jira API를 호출하고 이슈 목록을 반환합니다.
"""
# 1. API 호출 및 네트워크 오류를 잡기 위한 try...except 블록
try:
# requests.get()으로 Jira API에 실제 요청을 보냅니다.
response = requests.get(search_url, headers=headers, params=params, auth=auth)
# 만약 HTTP 상태 코드가 4xx나 5xx이면 여기서 에러를 발생시킵니다.
response.raise_for_status()
data = response.json()
issues = data.get('issues', [])
formatted_issues = []
for issue in issues:
fields = issue.get('fields', {})
# 2. 데이터가 비어있을(None) 경우를 대비한 방어적 코드
# 'assignee'가 없거나 None이어도 프로그램이 멈추지 않고 '미배정'으로 처리됩니다.
formatted_issues.append({
"key": issue.get('key'),
"summary": fields.get('summary'),
"status": (fields.get('status') or {}).get('name'),
"assignee": (fields.get('assignee') or {}).get('displayName', '미배정'),
# ... (이하 생략) ...
})
return {"success": True, "issues": formatted_issues}
# API 호출 실패 시 실행될 코드 블록
except requests.exceptions.RequestException as e:
error_message = e.response.text if e.response is not None else str(e)
app.logger.error(f"Jira API 호출 중 오류: {error_message}")
return {"error": f"Jira API 호출 오류: {error_message}"}
# 그 외 예측하지 못한 다른 모든 종류의 에러를 처리하는 코드 블록
except Exception as e:
app.logger.error(f"예상치 못한 Jira 처리 오류 발생: {e}")
return {"error": f"Jira 데이터 처리 오류: {str(e)}"}
💡 AI API 활용 Tip #2: 외부 데이터는 절대 믿지 마세요! 처음엔 Jira API가 항상 명세대로 완벽한 데이터를 줄 것이라 기대했습니다. 하지만 현실은 달랐죠. 특정 프로젝트 티켓에서는 assignee 필드가 아예 없거나, 커스텀 필드(startDate 등)가 비어있는 경우가 예상보다 잦았습니다. 이런 예외 하나 때문에 큐피드 전체가 멈추는 아찔한 경험을 한 뒤, (fields.get(‘assignee’) or {}).get(‘displayName’, ‘미배정’) 같은 방어적 코드를 추가했습니다. AI에게 깨끗한 데이터를 주기 위한 ‘데이터 전처리’ 단계에서 이런 방어적 코드는 선택이 아닌 필수였습니다.
● LLM 연동 (requests, OpenAI API): 큐피드의 두뇌 역할을 하는 OpenAI API 연동도 requests 라이브러리로 직접 구현했어요. 핵심은 두 번에 걸쳐 목적이 다른 프롬프트를 구성하는 거랍니다.
- 1단계 (의도 파악 프롬프트): AI가 반드시 정해진 {“action”: “jira_query”} 같은 JSON 형식으로만 답하도록 response_format을 지정해서, 다음에 할 행동을 명확하게 제어해요.
# qpid.py
initial_prompt_messages = [
{"role": "system", "content": """
당신은 AI 챗봇입니다. 사용자 질문 의도를 파악하여,
다음 세 가지 액션 중 하나를 선택하여 유효한 JSON으로만 응답해야 합니다.
1. Jira 티켓 정보 필요시: {"action": "jira_query"}
...
"""},
{"role": "user", "content": user_question}
]
payload_initial = {
"model": GPT_MODEL,
"messages": initial_prompt_messages,
"response_format": {"type": "json_object"} #JSON출력
}
💡 AI API 활용 Tip #3: AI를 ‘예측 가능한 동료’로 만드는 마법 response_format={“type”: “json_object”} 옵션이 없던 초기 버전의 큐피드는 마치 기분파 신입사원 같았습니다. 어떨 땐 “네, Jira를 조회하겠습니다.”라고 친절하게 답했지만, 질문자가 원하는 {“action”: “jira_query”}는 빼먹기 일쑤였죠. 이 때문에 프로그램이 다음 행동을 결정하지 못하고 멈추는 일이 반복됐습니다. 이 옵션은 AI의 자유도를 제어하여 ‘의사결정 엔진’이라는 비즈니스 로직을 안정적으로 구현하게 해준 핵심 기능이었습니다. AI를 시스템의 일부로 편입시키려면, 이처럼 예측 가능한 출력값을 받아내는 것이 무엇보다 중요합니다.
- 2단계 (분석 및 답변 생성 프롬프트): 1단계에서 가져온 Jira 데이터를 프롬프트에 통째로 넣어(RAG, Retrieval-Augmented Generation) AI가 이 정보를 기반으로 추론하게 만들어요.
# qpid.py
final_answer_messages = [
{"role": "system", "content": f"""
당신은 NOL QA 팀의 리소스 매니저 '큐피드'입니다.
주어진 Jira 티켓 목록을 분석하여 사용자의 리소스 질문에 답변하세요.
**제공된 Jira 작업 티켓 정보:**
{issues_text_tasks} # <-- QA팀 리소스관리 티켓 정보
**제공된 Jira 휴가 티켓 정보:**
{vacation_text} # <-- 휴가 일정도 추가로 고려하도록 제공
"""},
{"role": "user", "content": user_question}
]
2.3 좌충우돌 큐피드 길들이기: 프롬프트 엔지니어링의 힘!
큐피드의 성능은 복잡한 모델 튜닝이 아닌, 정교한 ‘프롬프트 엔지니어링’을 통해 확보했어요. 이건 AI에게 ‘어떻게 생각하고 행동해야 하는지’ 알려주는 업무 매뉴얼을 꼼꼼하게 써주는 것과 같답니다. 저희가 겪었던 수많은 실패와 개선의 순간들을 통해 그 비법을 공개할게요!
1) 명확한 역할 부여: ‘알아서 잘’은 없었다
AI의 능력을 너무 믿고 처음에는 간단하게 지시를 내렸습니다. 하지만 AI에게는 신입사원에게 업무를 알려주듯 구체적인 역할과 프로세스를 알려줘야 한다는 것을 깨달았죠.
- 실패 😭: 두루뭉술한 지시 초기 프롬프트는 “사용자가 날짜를 물어보면, Jira에서 그날 가능한 사람을 찾아서 알려줘.” 같이 단순했어요. 결과요? AI는 ‘가능한 사람’의 기준을 몰라 이미 다른 업무를 하는 사람을 추천하거나, 심지어 “팀원들에게 직접 물어보시는 건 어떨까요?” 같이 눈치 없는 답변을 했습니다.
- 개선 ✨: 명확한 ‘역할’과 ‘업무 프로세스’ 부여 큐피드에게 **’NOL QA 팀의 리소스 매니저’**라는 명확한 역할을 부여하고, 따라야 할 업무 절차를 프롬프트에 상세히 적어주었습니다.
실제 적용 프롬프트: 당신은 NOL QA 팀의 리소스 매니저 입니다. 당신의 임무는 주어진 Jira 티켓 목록을 분석하여 사용자의 리소스 관련 질문에 구체적인 답변을 제공하는 것입니다. 사용자의 질문에서 ‘9월 3주차’와 같은 날짜 범위를 정확히 파악하세요. 제공된 Jira 티켓 목록을 바탕으로 각 팀원의 일정을 확인합니다. (이하 구체적인 분석 지침)
이렇게 구체적인 행동 지침을 주니, 큐피드는 더 이상 헤매지 않고 주어진 프로세스에 따라 정확하게 리소스를 분석하기 시작했어요!
2) 비즈니스 로직 주입: “그건 우리 팀 국룰인데!”
AI는 QA 팀의 문화나 눈에 보이지 않는 규칙(국룰)까지 알지는 못했습니다. 코드로 구현하기 복잡한 팀의 규칙을 자연어 프롬프트로 녹여내는 것이 중요했죠.
- 실패 😭: 우리 팀의 ‘암묵적인 룰’을 모를 때 “9월 3주차에 QA 가능한 사람 1명 알려줘.” 라는 질문에 큐피드는 자신 있게 “네, OOO님이 가능합니다!” 라고 답했습니다. 하지만 저희 팀엔 ‘중요한 프로젝트의 QA는 파트장이 최우선 담당한다’는 암묵적인 룰이 있었죠. 이 규칙을 모르는 큐피드는 단순히 일정이 비어있는 다른 팀원을 추천해버린 거예요.
- 개선 ✨: ‘암묵적인 룰’을 명문화해서 주입하기 이 문제를 해결하기 위해 코드를 고치는 대신, 팀의 규칙을 프롬프트에 명시했습니다.
실제 적용 프롬프트: 파트장 우선순위 적용: ‘파트장 리소스 활용 우선순위는 최상위’ 원칙을 반드시 적용하세요.
이 한 줄의 규칙 덕분에, 큐피드는 복잡한 코드 변경 없이도 팀의 워크플로우를 완벽하게 이해하는 ‘진짜’ 동료가 될 수 있었답니다.
3) 출력 형식 제어: “그래서 결론이 뭔데?”
초기 큐피드는 정보를 요약하고 구조화하는 능력이 부족했습니다. 사용자가 원하는 답변 구조를 구체적으로 지시해서 정보의 가독성을 높여야 했죠.
- 실패 😭: TMI 대잔치 “9월 3주차 QA 리소스 현황 알려줘.” 라는 질문에 큐피드는 Jira에서 가져온 모든 티켓 정보를 결론 없이 장황하게 늘어놓았습니다. 보고서가 아니라, 그냥 데이터 뭉치를 받은 느낌이었죠.
- 개선 ✨: 보고서 양식을 지정해주기 TMI 대잔치를 막기 위해, 답변의 ‘양식’까지 구체적으로 지정해주었습니다. 신입사원에게 보고서 템플릿을 주는 것과 똑같았죠.
실제 적용 프롬프트: 두괄식으로 [결론], [분석내용], [현황] 영역을 구분해서 보기 좋게 대답해주세요.
이 지시 덕분에 큐피드의 답변은 한눈에 쏙 들어오는 깔끔한 보고서 형태로 바뀌었고, 정보의 가독성이 극적으로 향상되었습니다.
4) 환각 현상(Hallucination) 제어: 뇌피셜은 이제 그만!
마지막으로 AI가 없는 사실을 지어내지 않도록, 답변의 신뢰도를 확보하는 것이 중요했습니다. 이를 위해 RAG(Retrieval-Augmented Generation) 기술을 적극 활용했어요. 실시간 Jira 데이터라는 명확한 근거 자료를 프롬프트에 함께 주고, 아래와 같이 명확하게 지시했답니다.
실제 적용 프롬프트: 오직 주어진 정보만으로 답변해야 합니다. 만약 주어진 정보에 내용이 없다면, 절대 추측해서 답변하지 말고 모른다고 솔직하게 말하세요.
이 규칙 덕분에 큐피드는 항상 데이터를 기반으로 한 신뢰도 높은 답변만을 제공하게 되었습니다.
이처럼 수많은 테스트와 실패를 거치며 큐피드의 ‘업무 매뉴얼(prompt)’을 정교하게 다듬었어요. 이 과정은 마치 신입사원을 에이스로 키워내는 것과 같았죠. 이젠 정말 든든한 동료가 되었답니다!

(똑똑해진 큐피드의 최종 답변 화면)
3. 실무 변화의 바람: 새로운 동료가 팀에 불어넣은 혁신
큐피드는 QA팀 내부의 업무 방식, 특히 팀/파트 리더의 업무 효율성에 작지만 큰 변화를 가져왔어요.
3.1. 리더십의 생산성 향상과 전략적 집중
가장 직접적인 변화는 QA 팀 리더의 업무 효율성이 높아지고, 전략적인 업무에 더 집중할 수 있게 된 거였어요.
- 내부 리소스 확인 자동화: 이전에는 팀원의 현재 담당 업무나 향후 일정을 파악하려고 여러 Jira 보드나 캘린더를 뒤적여야 했어요. 이제 큐피드를 통해 이 과정을 즉시 해결할 수 있게 되었죠. 덕분에 리더는 반복적인 현황 파악에서 벗어나, 테스트 전략 수립, 팀원 역량 강화 같은 고부가가치 리더십 업무에 집중할 수 있는 기반을 마련했답니다.
- 신속하고 정확한 의사결정 지원: 특정 기간의 가용 리소스를 확인하거나, 프로젝트별 투입 현황을 파악해야 할 때, 큐피드에게 바로 물어보는 것만으로 통합된 정보를 즉시 얻을 수 있어요. 이는 흩어진 데이터를 취합하는 시간을 없애주어, 의사 결정 및 프로젝트 계획 수립의 정확성과 속도를 눈에 띄게 향상시켜 주었죠.
- 효율적인 팀 내부 온보딩: 신규 팀원이 팀의 리소스 확인 방법이나 업무 현황을 파악하려고 할 때, 큐피드의 사용법을 안내해주는 것만으로도 충분해졌어요. 덕분에 리더는 기본적인 운영 질문 대신, 더 깊이 있는 논의에만 참여하여 커뮤니케이션을 효율적으로 관리하게 되었답니다. 이건 향후 협업 부서로 사용이 확대되었을 때의 기대효과를 미리 보여주는 신호이기도 하고요!
3.2. 우리가 그리는 미래: 투명한 협업 문화 만들기
큐피드의 현재 사용성은 QA팀 내부에 집중되어 있지만, 최종 목표는 팀을 넘어선 투명한 협업 문화를 만드는 거예요.
- 전사적 정보 접근성 확보: 앞으로 큐피드의 사용 범위를 협업 부서로 넓혀서, PM/개발/디자이너 등 누구나 필요할 때 QA 리소스 현황을 직접 확인할 수 있도록 만드는 것을 목표로 하고 있어요. 정보가 투명하게 공유될 때 부서 간의 정보 비대칭성이 해소되고 더 빠른 협업이 가능해질 거예요.
- 주체적인 셀프 서비스 문화 확산: 관련 부서에서 “QA 리소스 확인은 큐피드에게!”라는 인식이 자리 잡게 되면, 각 담당자가 주체적으로 정보를 탐색하고 계획을 세우는 셀프 서비스 문화가 확산될 것으로 기대해요. 이는 리더의 개입을 최소화하고 모두의 업무 효율을 높이는 효과를 가져올 거랍니다.
- 생산적인 커뮤니케이션으로의 전환: 장기적으로 “이때 QA 돼요?” 같은 막연한 질문이, “큐피드에게 물어보니 A, B 님이 가능하던데, 이분들로 요청드려도 될까요?”처럼 데이터를 기반한 구체적인 논의로 바뀌는 것을 지향해요. 이는 불필요한 커뮤니케이션 비용을 줄이고 협업의 질을 한 단계 높여줄 거예요.
4. 다음 이정표: AI챗봇 큐피드와 함께 만들어갈 QA의 미래
큐피드를 한 번 ‘채용’하고 끝내지 않았어요. 이 AI 동료가 더 똑똑하게 일할 수 있도록 지속적으로 ‘교육’하고 있답니다. 처음 gpt-3.5 turbo 모델로 출발한 큐피드는 현재 최신 gpt-5-nano 모델을 적용하면서 눈부시게 성장하고 있습니다.
특히 gpt-5-nano로 업그레이드하면서, 기존 모델 대비 응답 속도가 최대 10배 빨라졌고, 복잡한 추론 능력과 판단 정확도가 크게 향상되었습니다. 덕분에 큐피드가 제공하는 답변의 정확도를 꾸준히 모니터링하고, 새로운 문의 유형이 나타나면 이를 프롬프트에 반영하며 기능을 확장하는 작업이 더욱 효율적으로 이루어지고 있죠.
내부 사용자(QA팀 리더 및 팀원)의 피드백을 주기적으로 수집해서, 부족한 부분을 보완하고 개선하는 데 아주 중요한 자료로 활용하고 있답니다.
앞으로도 이 유능한 AI 동료의 역량을 더욱 고도화할 계획이랍니다.
- 예측형 답변 강화: 사용자의 과거 질문 이력이나 현재 진행 중인 프로젝트 정보를 기반으로, 미리 필요한 정보를 예측해서 제공하는 기능을 추가할 예정이에요.
- QA 온보딩 자동화: 신규 QA 팀원이 입사했을 때, 기본적인 팀 규칙, 테스트 환경, 필수 확인 문서 등을 자동으로 안내하고 교육하는 역할을 하도록 확장할 계획이에요.
NOL QA 팀은 끊임없이 변화하고 성장하는 조직이에요. 저희의 경험이 여러분의 자동화 여정에 작은 영감이 되었으면 좋겠습니다. 궁금한 점이 있다면 언제든지 댓글로 문의해주세요. 함께 더 나은 QA의 미래를 만들어가요! 😊
💬 팀원들의 생생한 후기
“숙박/레저 도메인은 예측하기 어려운 요청이 자주 발생해 리소스 조율이 쉽지 않았습니다.하지만 큐피드를 통해 데이터를 기반으로 빠르게 판단하고 대응할 수 있게 되면서, 단순 조율에 쓰던 시간을 전략 수립과 핵심 테스트에 집중할 수 있게 되었습니다.” — QA 숙박/레저 파트장 랄프
“회원·결제 영역은 각 담당자의 도메인 이해도가 품질에 직접적인 영향을 주기 때문에, 도메인 전문성을 가진 담당자의 리소스를 안정적으로 확보하는 것이 중요합니다. 과거에는 각 담당자들의 WBS 일정을 일일이 확인하며 조율해야 했지만, 이제는 큐피드를 통해 객관적 데이터 기반의 일정 조율이 가능해져, 부담이 줄고 협업 효율이 크게 개선되었습니다.” — QA 회원/결제 파트장 카리나
NOL QA팀의 AI 동료 채용기가 여러분의 자동화 여정에 작은 영감이 되었으면 좋겠습니다. 궁금한 점은 언제든지 댓글로 문의해주세요! 😊

누구나 마음 편히 놀 수 있는 세상을 함께 만들어갈 동료를 찾고 있어요 :)
