사내 챗봇은 지식 검색 도구가 아니라, 업무 흐름을 바꾸는 입구여야 합니다
사내 AI 챗봇을 만들 때 가장 먼저 떠오르는 그림은 보통 문서 검색입니다.규정집, 매뉴얼, FAQ, 공지사항, 업무 가이드 문서를 연결해 두고 직원이 질문하면 답을 찾아주는 방식입니다. 물론 이것만으로도 일정한 효과는 있습니다.반복 문의를 줄일 수 있고, 흩어진 문서를 찾는 시간을 줄일 수 있습니다.신입 직원이나 다른 부서의 업무를 잘 모르는
kubernetes 환경에서 프론트엔드·백엔드·챗봇 에이전트 서버는 어떻게 구성하는 것이 효율적인가?
부제: 챗봇 서버를 프론트엔드에서 직접 호출할 것인가, 백엔드 프록시를 거칠 것인가 요약 Kubernetes 환경에서 프론트엔드, 백엔드, 챗봇 에이전트 서버를 함께 운영할 때 자주 나오는 고민이 있다. “프론트엔드에서 챗봇 서버를 직접 호출하는 것이 좋을까, 아니면 백엔드 서버를 프록시처럼 거쳐서 챗봇 서버를 호출하는 것이 좋을까?” 이 질문은 단순히 네트워크 경로의 문제가 아니다.
RAG는 더 이상 “문서 검색 챗봇”이 아니다
RAG는 더 이상 “문서 검색 챗봇”이 아니다 AI 챗봇을 업무에 적용한다고 하면 가장 먼저 떠올리는 방식이 있습니다. 사내 문서, 매뉴얼, FAQ, 정책 문서를 넣어두고 사용자가 질문하면 관련 내용을 찾아 답변해주는 방식입니다. 보통 이것을 RAG라고 부릅니다. RAG는 Retrieval-Augmented Generation의 약자입니다. 쉽게 말하면, LLM이 혼자 기억에 의존해 답변하는 것이 아니라, 외부
30년 개발 경험을 AI 업무자동화와 레거시 시스템 개선으로 다시 연결하려 합니다
초기 인터넷 붐이 시작되던 시기에 저는 개인 프로젝트로 포털 서비스 프로토타입을 만들었습니다. 그 프로젝트는 이후 네띠앙 서비스로 이어졌고, 저는 개발 총괄로서 서비스를 1,000만 명 규모까지 성장시키는 경험을 했습니다. 그 후 드림위즈를 공동창업하고 개발 책임자로 참여하면서 또 한 번 대규모 포털 서비스를 구축했습니다. 이 시기 저는 대규모 서비스의 코어 개발,
Coming soon
This is GGUT Studio Blog, a brand new site by Jokyun Jeong that's just getting started. Things will be up and running here shortly, but you can subscribe in the meantime if you'd like to stay up to date and receive emails when new content is