사내 AI 에이전트를 직접 개발하며 배운 점 #1 — '출처가 없는 답변'은 사용되지 않는다 | 부사장・공동창업자 꽌・딘・버

본 시리즈는 SY Partners(베트남 하노이/요코하마. 일본 시장을 대상으로 개발 및 QA를 수행하는 베트남과 일본 두 거점을 통해 총 약 250명의 규모를 가진 회사입니다)에서 사내 AI 에이전트 기반 'SYAgent'를 직접 개발하고 운영하면서 얻은 배움을 공유하는 것입니다. 수치는 모두 사내 실적이며 환경에 따라 다릅니다.

사내용 RAG(Retrieval-Augmented Generation)를 만들 때, '답변에 출처를 붙이는 것'은 자연스러운 요구사항입니다. 저희도 처음부터 그 의도를 가지고 구현했습니다.

하지만 초기 출처 표시는 충분히 기능하지 못했습니다.

예를 들어, AI가 프로젝트 운영 규칙을 설명한 후 다음과 같은 표시를 합니다.

출처: 프로젝트 관리 규정.docx

틀린 것은 아닙니다. 다만, 50페이지짜리 문서 이름만 제시된다고 해서 이용자가 어디를 확인해야 할지 알기 어렵습니다.

출처가 '있다는 것'과 근거를 '검증할 수 있는 것'은 별개의 문제였습니다.

이 글에서는 Microsoft Teams 위에서 작동하는 사내 AI 에이전트 'SYAgent'를 소재로, 출처의 세분성(granularity), 답변할 수 없을 때의 처리 방식, 오래된 지식 관리 등에 대해 저희가 실제로 재검토했던 포인트를 공유합니다.

안녕하세요. SY Partners의 부사장 겸 공동창업자 꽌・딘・버(Nguyen Dinh Ba)입니다. 사내 AI 에이전트 기반 'SYAgent' 개발 및 운영을 통해 얻은 배움을 기술적인 측면에서 공유해 가겠습니다.

SY Partners는 고객사의 시스템 개발 및 QA를 본업으로 하는 회사입니다. 개발 프로세스에도 AI 활용이 진행되고 있으며, 사내 프로젝트의 약 9할에서 어떤 형태로든 AI를 활용하고 있습니다(사내 실적입니다).

하지만 개발자가 개인적으로 AI를 사용하는 것과, AI 에이전트를 조직 업무에 통합하는 것은 별개의 과제였습니다.

고객에게 AI 활용을 제안하는 입장이었기에, 먼저 우리 스스로가 첫 번째 사용자가 되어 어려운 부분까지 경험해 봐야 한다고 생각했습니다. 그리하여 사내 AI 에이전트 기반 'SYAgent'를 직접 개발하게 되었습니다.

SYAgent는 Microsoft Teams 위에서 작동하는 역할별 에이전트 그룹입니다. 현재 프로젝트 관리(PM 지원・PMO) 영역의 베타 버전을 사내 출시하여 여러 실 프로젝트에서 사용하며 개선하고 있습니다. 육성(Tutor）・인재 평가(HR) 영역으로도 확장 중입니다.

본 연재에서는 개발 및 운영을 통해 얻은 배움을 하나씩 다룰 예정입니다. 제1회는 실제로 직면했던 '출처가 있는 답변'의 문제입니다.

시작점에는 두 가지 과제가 있었습니다.

첫째는, 지식이 사람과 장소에 흩어져 있다는 것이었습니다. 개발 표준, 과거 건의 지식(know-how), 프로젝트 최신 정보 등이 Redmine, GitHub, 공유 폴더, 그리고 잘 아는 사람의 머릿속에 분산되어 있었습니다. 필요한 정보를 찾는 것보다 '아는 사람에게 묻는' 것이 더 빠르다는 상황이었습니다.

둘째는, 관리 업무가 현장의 시간을 빼앗고 있다는 것입니다. 진행 보고, 회의 메모, 과제 정리 같은 일들이 PM이나 리더의 시간을 압박하고 있었습니다.

전사적으로 한 번에 전개하기보다는, 가장 문제가 명확했던 프로젝트 관리부터 시작하여 참조 대상을 Redmine, GitHub, 승인된 사내 문서로 한정했습니다.

만들기 전에 팀원들과 다음 네 가지를 원칙으로 정했습니다.

• 실 데이터만을 기반으로 출처와 함께 답변한다 (이번 주제) -
• 권한은 데이터 계층에서 제어한다 (제2회에서 다룰 예정) AI가 제안하고, 사람이 결정한다****측정하고, 수정하고, 다시 측정한다

돌이켜보면, 이 네 가지를 단순한 운영상의 희망이 아니라 처음부터 기능 요구사항으로 생각했던 것이 중요했습니다. 특히 첫 번째는 구현해 보니 상상 이상으로 세밀한 설계 판단을 필요로 했습니다.

Microsoft Teams에서 질문
↓
이용자・참조 권한 확인
...

포인트는 검색 대상을 '승인된' 정보로 한정했다는 것입니다. 지식은 취합 → 검토 → 공개의 플로우로 관리하며, 판수나 기밀도를 메타데이터로 가지고 있습니다. 오래된 문서는 회수합니다.

무엇을 근거로 답변할 수 있을지 인간 측에서 미리 정해둡니다. 에이전트는 그 범위의 정보를 사용하여 답변합니다. 이 생각이 이후 개선에도 이어졌습니다.

출처: 프로젝트 관리 규정.docx

올바른 문서 이름이 표시되어 있어도, 이용자들은 쉽게 확인하러 가지 않았습니다. 50페이지짜리 문서를 직접 열어서 해당 부분을 찾는 것은 너무 많은 수고가 따릅니다.

그래서, 검색을 위해 문서를 분할하는 단계에서 문서명・버전・섹션・기밀도를 각 청크에 포함시켜 답변에 대응하는 참조 위치를 보여줄 수 있도록 했습니다.

아래는 사고방식을 나타내는 설명용 예시이며, 실제 사내 스키마나 규정의 내용은 아닙니다.

document_title: "프로젝트 관리 규정"
version: "3.0"
section: "4.2 진척 보고"
...

답변 화면에서는 다음과 같이 사용자가 확인처를 특정하기 쉬운 형태를 목표로 합니다.

답변: 주간 보고에서는 진척・과제・다음 대응 사항을 확인합니다.
출처: 프로젝트 관리 규정 v3.0 > 4.2 진척 보고

※답변문과 버전・절 번호도 설명용 가상 예시입니다.

중요한 것은, 생성 모델이 출처처럼 보이는 문자열을 자유롭게 쓰도록 두지 않는 것입니다. 검색을 통해 얻은 정보의 메타데이터와 답변을 대응시켜 원본 기술을 확인할 수 있도록 합니다.

섹션 단위까지 출처의 세밀도를 낮춘 후, 출처 링크 클릭률이 확연히 증가했습니다. 단순히 '출처를 달았다'는 것에서가 아니라, '어디서 근거를 찾을 수 있는지'가 알게 되었기 때문이라고 생각합니다.

출처는 붙어 있는 것보다 검증할 수 있다는 것에 의미가 있습니다. 이것이 이번에 가장 큰 배움입니다.

또 다른 문제는, 개정 전의 구 버전 문서가 지식(Knowledge)으로 남아 있었다는 것입니다. 에이전트가 오래된 규칙을, 게다가 출처와 함께 안내해 버렸습니다.

근거가 표시됨으로써 오히려 신뢰할 수 있을 것 같은 점이 골칫거리였습니다.

이 문제를 계기로, 공개 플로우(Publishing Flow)와 대칭되는 회수 플로우(Withdrawal Flow), 그리고 버전 관리 방식을 재검토했습니다.

문서를 가져오기
→ 내용・공개 범위를 리뷰
→ 승인됨으로 공개
...

RAG 운영에서는 문서를 어떻게 추가할지뿐만 아니라, 오래된 정보를 어떻게 검색 대상에서 제외할지도 답변 품질에 직결됩니다.

출처가 붙어 있다고 해서 맞는 것은 아닙니다. 그 출처가 현행 버전인지까지 확인할 수 있어야 합니다.

사내 지식(Knowledge)에 없는 정보를 AI가 추측으로 채워 넣는 것은 피하고 싶습니다.

그렇기 때문에, 얻은 정보에서 확인할 수 없는 경우에는 '해당하는 데이터가 발견되지 않았습니다'라고 답변하도록 생성 프롬프트에 제약을 걸었습니다. 하지만, 프롬프트로 금지했다고 해서 오답이 완전히 사라지는 것은 아닙니다.

릴리스 시의 회귀 테스트(Regression Test)에서는 일반적인 질문뿐만 아니라 다음과 같은 케이스도 확인하고 있습니다.

• 실제로 존재하지 않는 사내 제도에 대해 질문하기
• 접근 권한이 없는 프로젝트 정보에 대해 질문하기

LLM 출력에는 변동성(Fluctuation)이 있기 때문에, 한 번 정상으로 보였더라도 다음 업데이트에서 재발할 가능성이 있습니다. 단 한 번의 정답이 아니라, 지속적으로 품질을 확인하는 것. 이 사고방식에는 저희 회사가 진행해 온 QA 경험이 살아있습니다.

베타 버전을 여러 프로젝트에서 사용하게 되면서, 답변의 유창함(Fluency)만으로는 사용자의 신뢰를 얻을 수 없다는 것을 알게 되었습니다.

출처의 세밀도를 조정한 후, 사용자의 '지속 이용률'도 눈에 띄게 변했습니다. 물론, 사내 제한된 샘플에서의 이야기이며, 다른 환경에서도 같은 결과가 될 것이라고는 할 수 없습니다.

그럼에도 불구하고, 출처 링크 클릭과 지속적인 이용 모두에서 변화가 보인 것은 저희에게 중요한 피드백이었습니다.

개인이 사용하는 챗봇 AI라면, 어느 정도의 추측을 스스로 보완하여 사용할 때도 있을 것입니다. 하지만 조직 업무에 통합하는 에이전트에서는, 근거를 스스로 확인할 수 있는지가 이용을 좌우한다고 생각합니다.

제가 중요하게 여기는 것은, 답변이 자연스러워 보이는지뿐만 아니라, 사용자가 근거로 돌아가서 스스로 판단할 수 있는지라는 점입니다.

• 답변에 제시된 출처가 실제로 그 주장을 뒷받침하는가.
• 원본 자료의 해당 위치에 사용자가 도달할 수 있는가.
• 구 버전이나 권한 외 정보가 검색 대상에 섞이지 않는가.
• 필요한 정보가 없을 때, 무리하게 답을 만들지 않는가.
• 개선된 내용을, 릴리스 후에도 지속적으로 측정하고 있는가.

이것들은 LLM의 성능만으로는 해결할 수 없습니다. 지식 관리(Knowledge Management), 검색, 접근 제어, 테스트를 하나의 시스템으로 생각해야 합니다.

이번 배움은, 단순히 출처를 달면 신뢰받는다는 것이 아닙니다.

출처를 확인할 수 있는 세밀도로 제시하고, 오래된 정보를 제외하며, 답할 수 없을 때는 답변하지 않는다. 그리고, 실제로 사용되었는지 측정하고 계속 고쳐나간다. 거기까지 포함해야 비로소 업무에 통합 가능한 RAG에 가까워진다고 생각합니다.

SYAgent는 현재도 베타 버전으로 개선 중입니다. 완성된 성공 사례로서가 아니라, 실제로 사용하면서 발견한 과제를 공유해 나갈 것입니다.

제2회에서는 “권한은 데이터 계층에서 제어한다”에 대해 다룰 예정입니다. 화면상으로 숨기는 것만으로는 왜 불충분한지, 역할(role) 및 프로젝트 단위의 접근 제어를 검색 단계에 적용하는 내용에 대해 글을 쓸 계획입니다.

*SY Partners / 부사장・공동창업자 응우옌 딘 바 (Nguyen Dinh Ba)

SY Partners는 일본 시장을 위한 시스템 개발, QA, AI 개발을 수행하고 있습니다. 공식 웹사이트(일본어)