벡터DB 없이 실시간으로 사이트를 읽는 챗봇 — 경복대학교 안내 챗봇 해부

문서를 미리 청크로 잘라 벡터 DB에 쌓아두지 않아도, AI Agent가 질문을 받을 때마다 실제 웹페이지를 열어 그 내용으로 답하는 챗봇을 n8n으로 만들 수 있습니다. 경복대학교가 지금 실제로 운영 중인 안내 챗봇이 이 구조입니다. HTTP Request Tool 노드 3개가 학교소개·공지사항·학과입학 페이지를 그때그때 읽어와 AI Agent에게 넘겨주는 것이 전부이고, 별도의 벡터 스토어나 임베딩 파이프라인은 없습니다.

이 워크플로우 하나로 보여줄 수 있는 것

이 시리즈 32편의 RAG 챗봇은 문서를 미리 청크로 잘라 벡터로 바꿔 저장해두고, 질문이 오면 그 공간에서 검색했습니다. 이번 워크플로우는 저장 단계가 아예 없습니다. 질문이 들어올 때마다 AI Agent가 실제 페이지를 직접 불러옵니다. 같은 "AI Agent가 도구를 부른다"는 그림이지만, 도구가 벡터 검색이 아니라 살아있는 웹페이지라는 점에서 완전히 다른 설계입니다.

이 구조를 만들어보면 다음을 설명할 수 있게 됩니다.

• HTTP Request Tool로 에이전트에게 실시간 조회 능력 주기 — toolDescription이 왜 에이전트의 판단 근거가 되는지
• 웹페이지에서 본문만 걸러내는 스크래핑 설정 — responseType, onlyContent, elementsToOmit로 nav·header 같은 잡음을 걷어내는 실전 값
• 토큰 예산 관리 — truncateResponse로 페이지 하나가 컨텍스트를 통째로 잡아먹지 않게 막는 법
• 환각 방지 규칙 설계 — 도구 결과에 없는 내용은 지어내지 말라는 지시를 시스템 프롬프트에 박아두는 이유

무엇보다, 사전 임베딩과 실시간 조회 중 어느 쪽을 골라야 하는지를 사례로 설명할 수 있게 됩니다.

배경

경복대학교는 남양주캠퍼스와 포천캠퍼스를 운영하는 대학입니다. 이 챗봇은 학교 홈페이지(kbu.ac.kr) 안내를 목적으로 만들어졌고, 워크플로우 상태가 active: true로 되어 있어 실제로 켜져서 운영 중인 프로덕션 워크플로우입니다. 이 시리즈에서 다룬 워크플로우 대부분이 교육용 예제였던 것과 달리, 이 편은 실제로 서비스되고 있는 사례라는 점이 다릅니다.

이런 안내 챗봇을 만들 때 첫 번째 결정은 "학교 정보를 챗봇에게 어떻게 알려줄 것인가"입니다. RAG 챗봇 편은 문서를 미리 청크로 잘라 벡터로 바꿔 Supabase에 저장하고, 질문이 오면 그 공간에서 검색하는 방식이었습니다. 문서가 안정적이고 검색 정확도가 중요할 때 강력하지만, 청크 분할·임베딩·벡터 DB라는 구축 단계가 하나 더 필요합니다.

경복대학교 챗봇은 다른 길을 택했습니다. 참고 페이지가 학교소개·공지사항·학과입학 세 개뿐이고, 특히 공지사항은 학교가 수시로 갱신하는 콘텐츠라 미리 임베딩해두면 금방 낡은 정보가 됩니다. 이런 조건에서는 벡터 DB를 구축하는 비용을 아예 건너뛰고, 질문이 들어올 때마다 AI Agent가 해당 페이지를 직접 여는 쪽이 더 간단합니다.

구조 — Trigger / Task / Target

• Trigger — 공개 채팅 위젯(Public), 응답은 streaming 모드로 토큰이 오는 대로 바로 화면에 표시
• Task — AI Agent가 질문을 보고 세 도구 중 필요한 것만 골라 호출하고, 최근 10턴은 Simple Memory로 기억
• Target — 채팅 위젯에 스트리밍 응답. 별도 DB 적재는 없습니다

만들기

1. HTTP Request Tool — 도구인지 아닌지를 가르는 것은 연결선

이 워크플로우의 세 도구(Fetch School Introduction, Fetch Notices, Fetch Departments and Admissions)는 일반 HTTP Request 노드가 아니라 httpRequestTool 노드입니다. 같은 HTTP 요청이지만 연결선이 ai_tool 타입으로 AI Agent에 붙는다는 점이 다릅니다. 이 연결 덕분에 세 노드는 고정된 순서로 실행되지 않고, Agent가 질문을 읽고 "이번엔 이 도구가 필요하다"고 판단할 때만 호출됩니다.

그 판단의 유일한 근거가 toolDescription 필드입니다. 원본에는 이렇게 적혀 있습니다.

• 학교소개: "경복대학교 학교소개 페이지를 조회한다. 학교 개요, 설립이념, 비전, 연혁, 총장인사말 관련 질문에 사용. 파라미터 없음."
• 공지사항: "경복대학교 공지사항 목록 페이지를 조회한다. 최신 공지, 학교 소식, 안내사항 관련 질문에 사용. 파라미터 없음."
• 학과·입학: "경복대학교 학과안내/입학안내 페이지를 조회한다. 학과 목록, 전공, 입시, 지원 방법 관련 질문에 사용. 파라미터 없음."

Agent는 도구의 내부 구현(어떤 URL을 부르는지)은 보지 않고 이 설명 문장만 보고 고릅니다. toolDescription을 대충 쓰면 Agent가 엉뚱한 도구를 고르거나 필요한데도 안 부릅니다. 시스템 프롬프트에도 "학교소개·연혁은 Fetch School Introduction, 최신 공지는 Fetch Notices, 학과·입학은 Fetch Departments and Admissions로 조회한다"는 규칙이 한 번 더 박혀 있어 이중으로 도구 선택을 안내합니다. Agent 노드의 maxIterations는 10으로, 한 턴에 도구를 반복 호출할 수 있는 최대 횟수를 제한해둡니다.

2. responseType: html + onlyContent + elementsToOmit — 본문만 남기고 버리기

세 도구는 모두 같은 응답 처리 설정을 씁니다. responseType을 html로 두면 페이지를 JSON이 아니라 HTML 그대로 받아옵니다. 여기에 onlyContent: true를 켜면 본문 영역만 남기고, elementsToOmit에 script, style, nav, header, footer, iframe을 나열해 스크립트·스타일·내비게이션·머리말·꼬리말·iframe을 걷어냅니다.

이 설정이 없으면 Agent에게 페이지 전체 HTML(메뉴, 로고, 자바스크립트 코드까지)이 그대로 넘어가 토큰만 잡아먹습니다. 실전 스크래핑에서는 "무엇을 가져올지"보다 "무엇을 버릴지"를 정하는 게 더 중요한 이유가 여기 있습니다.

3. truncateResponse — 페이지 하나가 컨텍스트를 다 먹지 않게

truncateResponse: true와 maxLength: 8000을 함께 설정해, 본문이 걸러졌어도 최종적으로 8,000자를 넘기지 않게 자릅니다. 공지사항 목록처럼 글이 많이 쌓인 페이지는 정제해도 여전히 길 수 있는데, 상한선이 없으면 페이지 조회 때마다 토큰 비용과 응답 지연이 예측 불가능해집니다.

4. 시스템 프롬프트 — "도구 결과에 없으면 지어내지 말 것"

RAG 챗봇 편의 한계로 꼽았던 것이 "시스템 메시지가 기본값이라 Agent가 벡터 스토어에서 못 찾은 내용도 자기 지식으로 채워 답할 수 있다"는 점이었습니다. 경복대학교 챗봇은 이 규칙을 시스템 프롬프트에 직접 넣어뒀습니다.

2. 도구 결과나 기본 정보에 없는 내용은 지어내지 말고 "공식 사이트(https://www.kbu.ac.kr) 또는 대학 대표 창구 문의"를 안내한다.
3. 개인정보(학적, 성적, 등록금 납부 내역 등) 질문에는 답하지 않고 공식 창구를 안내한다.
5. 답변은 한국어로 간결하게 작성하고, 근거가 된 페이지 URL을 함께 제시한다.
6. 도구 조회에 실패하면 잠시 후 재시도를 권하거나 공식 사이트 방문을 안내한다.

이 규칙이 실시간 조회 방식에서 특히 중요합니다. 벡터 RAG는 임베딩해둔 문서가 "정답의 원천"으로 고정돼 있어, 검색이 비면 결과가 비어 있다는 게 비교적 명확합니다. 반면 이 워크플로우는 매번 페이지를 새로 불러오기 때문에 사이트가 바뀌면 자동으로 최신 정보를 반영하는 대신, 페이지 구조가 바뀌어 onlyContent가 엉뚱한 내용을 걷어오거나 요청이 실패하면 그 빈틈을 Agent가 자기 지식으로 채우기 쉬운 조건이기도 합니다. "모르면 공식 사이트를 안내하라"는 규칙은 이 실패 지점을 막는 안전장치입니다.

원본 캔버스에 남아 있는 흔적

캔버스의 스티키 노트에는 이렇게 적혀 있습니다.

Chat Trigger(호스팅 채팅) → AI Agent(Gemini) 도구 3종(실시간 사이트 조회): 학교소개 / 공지사항 / 학과·입학 응답은 streaming 모드로 채팅 위젯에 직접 전송.

흥미로운 지점이 하나 있습니다. 스티키 노트와 워크플로우 설명 모두 "AI Agent(Gemini)"라고 적어뒀는데, 실제 연결을 보면 Agent의 언어모델 슬롯에 붙은 노드는 OpenAI Chat Model(모델값 gpt-5.4-mini) 하나뿐이고 Gemini 노드는 JSON 어디에도 없습니다. 메모와 실제 연결이 어긋나 있는 흔적인데, 워크플로우의 모델을 나중에 바꾸면서 캔버스 설명은 그대로 남겨두는 일이 실제로 이렇게 생긴다는 걸 보여줍니다.

사전 임베딩(#32) vs 실시간 조회(#42) — 언제 어느 쪽을 고르나

기준	RAG(사전 임베딩)	실시간 조회(HTTP Request Tool)
저장 시점	업로드할 때 한 번 청크·임베딩해 저장	저장하지 않음, 질문마다 새로 요청
정보 최신성	문서가 바뀌면 재임베딩해야 반영	사이트가 바뀌면 다음 질문부터 바로 반영
구축 비용	벡터 DB, 임베딩 파이프라인 필요	HTTP Request Tool 노드만 있으면 됨
적합한 대상	문서 다수, 콘텐츠 안정적, 검색 정확도 중요	페이지 소수, 콘텐츠가 자주 바뀜
실패 지점	청크 경계, 임베딩 누락	사이트 구조 변경, 요청 실패
응답 속도	벡터 검색이라 빠르고 일관적	매번 페이지를 불러오므로 사이트 응답 속도에 좌우

경복대학교 챗봇처럼 참고할 페이지가 서너 개뿐이고 그마저 공지사항처럼 자주 바뀐다면, 벡터 DB 구축 비용이 오히려 낭비입니다. 반대로 문서가 수백 페이지고 콘텐츠가 안정적이라면 매번 통째로 불러오는 방식은 느리고 토큰 비용도 커져 사전 임베딩이 맞습니다. 자주 바뀌는 정보는 실시간 조회로, 고정 문서는 벡터 검색으로 나눠 한 Agent에 같이 붙이는 것도 가능합니다.

한계

• 페이지 3개로 고정 — 새로운 정보 유형이 생기면 도구를 하나씩 더 추가해야 하고, 도구가 너무 많아지면 Agent가 어떤 도구를 쓸지 헷갈리기 쉬워집니다.
• 사이트 구조 변경에 취약 — elementsToOmit은 고정된 태그 목록이라, 학교 홈페이지 개편으로 다른 방식의 메뉴·광고 영역이 추가되면 본문에 잡음이 섞여 들어올 수 있습니다.
• 캐시가 없어 매 질문이 사이트 응답 속도에 종속 — 같은 질문을 두 번 해도 매번 새로 페이지를 불러오므로, 학교 서버가 느리면 챗봇도 느려집니다.
• 개인정보 조회 기능 자체가 없음 — 시스템 프롬프트가 학적·성적 질문을 아예 막아둬서 개인화된 답변을 만들 수 없습니다.

포트폴리오·면접 포인트

포트폴리오에는 회사나 학교 홈페이지처럼 자주 갱신되는 사이트를 골라 이 구조로 안내 챗봇을 만들어보는 걸 권합니다. 벡터 DB를 세팅하지 않아도 되니 RAG 챗봇보다 빠르게 완성할 수 있고, "왜 벡터 검색 대신 HTTP Request Tool을 썼는가"라는 질문에 바로 답할 근거가 생깁니다.

면접에서 "RAG랑 뭐가 다른가요?"라는 질문이 오면 저장 시점의 차이로 답하면 됩니다. RAG는 질문이 오기 전에 이미 벡터로 저장돼 있고, 이 구조는 질문이 온 순간에 페이지를 읽습니다. RAG는 검색이 빠르고 일관되지만 문서가 바뀌면 다시 임베딩해야 하고, 이 구조는 항상 최신이지만 사이트가 느리거나 구조가 바뀌면 그대로 영향을 받습니다. 여기에 "그래서 어떤 상황에 어느 쪽을 고를지"까지 설명하면, 개념으로만 아는 사람과 실제로 둘 다 만들어본 사람의 차이가 드러납니다.

다음 액션

다음 편에서는 n8n을 정적 웹서버처럼 운영하는 사례로 넘어갑니다. 수료증 발급 시스템인데, 같은 배치를 실수로 두 번 돌려도 수료증이 중복 발급되지 않게 만드는 멱등 처리가 핵심 주제입니다. AI Agent가 도구를 스스로 고르는 이번 편과 달리, 정해진 규칙대로 안전하게 반복 실행하는 법을 다루는 편입니다.