AI ENGINEER NIGHT Q&A 총정리

안녕하세요. 채널팀 Developer Relations 소마입니다. 👋

지난 6월 10일, 채널톡 오피스에서 AI ENGINEER NIGHT를 진행했습니다. 이번 행사에서는 채널톡 AI팀이 Product AI를 만들며 실제로 부딪히고 고민한 이야기와 인사이트를 나누었는데요. 현장에서 다 답변드리지 못한 주요 질문에 대해 도움이 될 수 있도록 채널톡 AI팀 제이크, 카오루이자 이번 AI ENGINEER NIGHT 발표자인 두 분과 꼼꼼하게 답변을 정리해 보았습니다.

RAG, 어떻게 만들고 있나요

Q. RAG를 하실 때 한 청크를 넘어가는 표나 이미지, 그래프 처리는 어떻게 하셨나요?

적재 쪽에서는 문서 구조를 최대한 살려서 자르려고 해요. 아티클의 경우 제목과 본문의 위치, 내용이 바뀌는 지점 같은 구조를 파악한 상태로 청킹하는데, 고정 길이로 기계적으로 자르는 방식보다 표나 리스트가 중간에 끊기는 문제가 확실히 줄어들더라고요. PDF처럼 구조를 사전에 특정하기 어려운 경우엔 OCR 모듈로 전처리합니다.

생성 쪽에서는 검색된 top-k가 통째로 컨텍스트로 들어가고, 부족하면 에이전트가 인접 문서를 추가로 탐색하는 구조라서 표가 한 청크에 다 안 담겨도 어느 정도 보완이 돼요. 다만 솔직히, 에이전트가 아무리 잘 탐색해도 비정형 문서(PDF, 웹페이지)는 검색의 천장이 있다고 느껴요. 그래서 결국에는 표 안의 상품이나 가격 같은 엔티티를 미리 추출해서 구조화해두고, 검색이 아니라 조회로 푸는 방향으로 고도화하려고 합니다.

Q. BM25 스코어가 Vector보다 낮아 보이는데, 형태소 분석기나 사용자 사전은 별도로 구축하셨나요?

솔직히 말씀드리면 별도로 구축하지 않았어요. 저희가 2,000개가 넘는 고객사를 받고 있는데, 고객사마다 도메인 용어가 달라서 채널별로 사전을 만들고 유지하는 방식은 스케일이 안 나온다고 판단했거든요. 고객사가 늘수록 운영 비용이 같이 늘어나는 구조라서요.

그래서 검색 한 번의 정확도보다는 검색이 빗나갔을 때 전략을 바꿔서 다시 시도하는 능력에 투자했어요. BM25는 주문번호나 모델명 같은 리터럴 매칭을 보완하는 역할로 쓰고, 첫 검색이 부족하면 에이전트가 쿼리를 바꾸고 검색 범위를 조정해서 재탐색합니다. 토크나이저 튜닝을 아예 닫아둔 건 아닌데, 지금까지는 우선순위에서 밀렸다는 게 솔직한 표현인 것 같아요.

Q. 폴더를 선정하는 오케스트레이션 전략이 궁금합니다.

지식센터의 전체 폴더 구조와 메타데이터를 컨텍스트로 주고, 어디를 볼지 무엇을 검색할지를 tool-calling으로 매 턴 스스로 판단하게 합니다. 검색 결과를 보고 더 탐색할지도 에이전트가 직접 결정하고요. 코딩 에이전트가 파일시스템을 탐색하는 패러다임을 차용한 건데, 한 번에 다 펼치지 않고 필요한 만큼씩 열어가는 progressive disclosure 패턴이라고 보시면 돼요.

에이전트, 어떻게 설계하나요

Q. 모델이 발전할수록 Harness가 불필요해지는 순간이 올까요? 모델 발전으로 Harness 노력이 무의미해진 경험도 있었나요?

솔직히 아직은 모호한 영역이라고 생각해요. 프롬프트 엔지니어링에서 컨텍스트 엔지니어링, 하네스 엔지니어링으로 빠르게 진화하고 있고, 최근엔 루프 엔지니어링이라는 개념까지 나오고 있죠. 기술이 발전하면서 기존에 불가능했던 것들이 빠르게 해결되는 건 맞고요.

다만 저희는 기술 흐름과 비즈니스 요구사항을 같이 봐야 한다고 생각해요. Cursor나 Claude Code 같은 코딩 에이전트는 RAG 대신 파일시스템이나 grep을 활용하는 경우가 많지만, 상담 서비스는 고객과 실시간으로 소통해야 하는 영역이라 레이턴시 때문에 그 방식을 그대로 적용하기 어렵거든요. 성급하게 대체하기보다 기존 RAG에 계층적(Hierarchical) 구조를 도입해서 성능을 극대화하는 방향을 선택한 이유이기도 합니다.

Q. LangChain 같은 프레임워크를 활용하시나요, 아니면 자체 구현하시나요?

PoC나 빠른 가설 검증 단계에서는 LangChain 같은 프레임워크도 적극적으로 씁니다. 업계에서 오랫동안 고민해온 결과물들이라 상황에 맞게 유연하게 가져다 쓰는 게 맞다고 봐요.

다만 핵심 엔진인 ALF는 ReAct 방식을 기반으로 자체 구현해서 운영하고 있어요. 모델 쪽도 처음엔 프론티어 사 API를 활용해 빠르게 서비스를 만드는 데 집중했는데, 최근에는 자체 LLM의 비용 효율성이 많이 개선됐고 그동안 축적된 상담 데이터를 레버리지하면 더 독보적인 가치를 만들 수 있겠다는 판단이 서서 자체 LLM 연구도 함께 병행하고 있습니다.

Q. 비결정적인 에이전트에서 하네스를 수정한 뒤, 같은 실수가 반복되지 않도록 성능을 고정하는 방법이 있을까요?

솔직히 성능을 완벽히 고정하는 건 사실상 불가능해요. 특히 어려운 시나리오일수록 더 그렇고요. 그래서 저희는 한 번의 시도로 합격 여부를 결정하는 pass@1 방식이 아니라, 여러 번 시도해서 평가하는 pass@k 방식으로 접근합니다. 예를 들어 할루시네이션 이슈가 있다면 먼저 근본 원인을 해결하고, 반복 시도 중 최소 80% 이상 통과하는지 검증하는 식이에요.

데이터와 평가, 어떻게 접근하나요

Q. 유저 질문, 응답을 저장할 때 이상한 질문이 쌓여 오히려 성능이 떨어질 수 있지 않나요?

정확한 우려예요. 유저 질문, 응답을 무가공으로 지식에 반영하면 장난성 질문이나 오답이 지식을 오염시킬 수 있거든요. 그래서 실제로 반영될 때까지 여러 게이트를 둡니다. 먼저 유의미한 질문, 응답인지를 다른 상담과 비교해서 노이즈를 제거하고, 그다음 지식 수정/추가 제안을 사람이 직접 검토하고 승인해요. precision을 최대한 높이는 방향을 의도적으로 택한 거예요.

Q. 수많은 상담 데이터를 어떻게 효과적으로 분석하고 평가하나요?

상담이 종료되는 즉시 다양한 메타데이터를 기록합니다. 해결/미해결 여부, 이관 이력 같은 기본 정보는 물론이고, AI를 활용해 상담 맥락 요약, 주제 분류, 상담 품질 점수 같은 깊이 있는 정보까지 함께 저장해요. 이렇게 쌓인 데이터는 채널톡의 통계와 커스텀 리포트 기능을 통해 제공되는데, 고객사가 주요 이슈를 빠르게 패턴화하고 비즈니스 인사이트를 얻을 수 있도록 설계했습니다.

Q. 사용자 만족도와 사실 정확도가 충돌할 때 어떤 지표를 우선하나요?

중요한 지점을 짚어주셨어요. CSAT, CX Score 같은 지표에서 고객 만족도는 항상 핵심 지표로 들어오는데, 사실 만족도는 상담의 정확성과 늘 일치하지 않아요. 구매 후 7일이 지나 환불을 원하는 고객에게 규정대로 환불 불가를 안내했다면, 회사 입장에선 정확한 상담이지만 고객 만족도는 낮게 나올 수 있거든요.

그래서 어느 하나의 지표를 절대 기준으로 삼기보다, 상황에 따라 지표의 우선순위를 유연하게 조정하면서 다각도로 보는 방식을 택하고 있어요.

다음에 또 만나요!

이번 AI ENGINEER NIGHT에서 나온 질문들이 채널톡 AI팀에도 많은 자극이 되었습니다. 비슷한 고민을 하는 분들을 만나서 반가웠고, 더 자주 이야기 나눌 수 있는 자리를 만들고 싶다는 생각도 들었습니다. 글로 다 담지 못한 현장의 열기가 궁금하신 분들은 질의응답 풀영상도 함께 확인해 보세요!

채널톡 AI팀과의 커피챗은 언제나 오픈되어있습니다! 직접 이야기 나누고 싶으신 분들은 언제든지 편하게 커피챗 요청해 주세요! ☕️