AI를 통한 가이드 작성 중입니다.

바로 적용 가능한 기업용 AI챗봇 만들기 1 — 에이전트는 회사 데이터를 어떻게 쓰는가

이 글의 질문. 기업 챗봇에 모델 API를 연결했다. 이제 회사 자료를 어떻게 만들고, 질문할 때 어떻게 찾아서, 어떤 결과를 기억하게 할 것인가? 여기서는 실제 에이전트의 공식 자료를 먼저 읽는다. OpenClaw는 대화에서 기억을 선별하고 검색한다. Codex와 Claude Code는 도구를 통해 필요한 자료를 찾아 작업한다. OpenAI가 공개한 사내 데이터 에이전트는 여러 원천의 의미를 정리해 검색용 맥락을 만들고, 최신 값은 다시 조회한다. 이 흐름을 기업 상담에 적용해 본다.

이번 글의 공식 자료 · 2026년 9월 23일 확인
① OpenAI Agents API 발표 · 2026.9.10 · Codex 하네스 설명 · 2026.7.29
② OpenAI 사내 데이터 에이전트 · 2026.1.29 · Codex 문서 운영 사례 · 2026.2.11
③ Anthropic Managed Agents 구조 · 2026.4.8
④ OpenClaw 현재 메모리 문서 · 현재 검색 엔진 문서
발표 글은 2026년 자료로 제한했다. 지속 갱신되는 제품 문서는 확인일 기준의 내용이다. 아래에서 실제 구현과 이 글의 설계 제안을 구분한다.

모델 주위의 ‘하네스’가 하는 일

하네스(harness)는 모델 호출을 둘러싼 실행 구조를 가리킨다. 사용자 요청을 받고, 필요한 도구를 고르고, 결과를 모델에 돌려주고, 후속 조회·검사·기록을 수행한다. OpenAI의 하네스 설명은 Codex가 한 요청 안에서 코드·사고 기록을 찾고, 파일을 고치고, 테스트를 실행하는 여러 차례의 모델·도구 호출을 예로 든다. OpenClaw 런타임 문서에도 에이전트 루프, 도구 연결, 프롬프트 조립, 작업 공간과 세션 저장소가 명시돼 있다.

내가 생각하는 기업 챗봇도 이 구조에서 시작한다. 질문마다 사용자 권한을 확인하고, 회사 문서·상품 DB·업무 API·과거 대화 중 필요한 것을 고른다. 모델은 가져온 결과의 조건을 비교해 답한다. 서버는 실제 조회와 쓰기 작업, 권한 판단, 사용량 기록을 맡는다. 챗봇의 품질을 좌우하는 부분은 이 선택과 검증 과정이다.

2026년 9월 발표된 OpenAI Agents API는 작업·모델·도구·환경을 지정하면 Codex 계열 하네스가 긴 세션의 문맥 압축과 필요한 도구 정의의 선택적 로딩을 처리한다고 설명한다. 기업별 지식과 도구는 개발자가 연결한다. 자체 NestJS 서버를 택하더라도 도구 목록을 전부 매번 모델에 싣지 않고 필요한 정의와 검색 결과를 선택하는 원리는 적용할 수 있다. 이 글은 LangChain을 구현 전제로 두지 않는다. 다만 어떤 프레임워크가 항상 가장 비효율적인지는 동일 업무·모델·검색 자료로 측정해야 판단할 수 있다.

OpenClaw는 대화에서 어떤 데이터를 만드는가

OpenClaw 메모리 공식 문서를 보면, 작업 공간의 파일이 기억의 원본이다. 안정적인 사용자 선호는 USER.md, 오래 쓸 사실·결정은 MEMORY.md, 자세한 관찰과 대화 맥락은 날짜별 memory/YYYY-MM-DD.md에 둔다. 날짜별 메모를 매번 전부 모델에 넣지는 않는다. 검색해서 관련 내용을 가져온다. 장기 기억 파일이 커지면 모델에 주입되는 사본은 예산에 맞춰 잘릴 수 있다.

기억 생성 시점도 구체적이다. 대화가 길어져 문맥을 압축하기 전에 메모리 플러시가 남길 내용을 파일에 기록한다. 날짜별 기록에서 오래 쓸 항목을 선별해 장기 기억으로 옮기는 백그라운드 과정도 있다. 기본 메모리 엔진은 파일 내용을 에이전트별 SQLite에 나누어 색인한다. FTS5 키워드 검색은 기본으로 동작하고, 임베딩 공급자가 있으면 의미·혼합 검색을 쓴다. 검색 색인은 파일에서 다시 만들 수 있는 파생 데이터다.

여기에 신뢰 경계가 붙는다. OpenClaw는 색인 항목에 소유자·에이전트·신뢰할 수 없는 입력 등의 출처 분류를 별도로 기록한다. 기억의 출처와 삭제 문서는 특정 대화에서 파생된 기억을 지워도 원 대화 기록이나 모든 수동 사본이 자동 삭제되지는 않는다고 설명한다. 개인용 에이전트의 기억 구조를 기업 상담에 가져오려면 고객별 권한, 승인, 정정, 삭제 범위를 더 명확히 관리해야 한다.

Hermes의 공식 파일 구분도 참고할 만하다. USER.md는 사용자 프로필, MEMORY.md는 에이전트가 배운 사실, AGENTS.md는 프로젝트 지침이다. 반복 절차는 필요할 때 읽는 스킬로 남긴다. “고객은 짧은 답을 선호한다”는 개인 기억이고, “환불 전에 주문 소유권을 확인한다”는 운영 절차다. 서로 갱신·승인 방식이 달라야 한다.

에이전트의 자료 층	공식 자료에서 확인한 방식	기업 챗봇에 적용할 설계
현재 작업	현재 대화와 필요한 도구 결과만 문맥에 넣음	질문과 무관한 고객 기록은 전달하지 않음
지속 기억	OpenClaw의 선별된 장기·일일 메모	근거가 있는 선호·진행 중인 일만 저장하고 만료·정정을 관리
반복 절차	Hermes의 필요 시 로딩되는 스킬	주문 조회·환불 접수의 순서와 실패 처리를 버전 관리
검색 색인	원본 파일에서 만든 키워드·의미 검색 자료	원본 버전 변경 때 갱신하고 원본 위치를 보존

Codex와 Claude Code는 자료를 어떻게 읽는가

OpenAI는 Codex를 위한 저장소 운영 사례에서 짧은 AGENTS.md를 상세 문서의 안내도로 사용한다고 공개했다. 세부 지식은 버전 관리되는 저장소 문서에 두고 에이전트가 필요한 파일을 찾아 읽는다. 모든 내용을 하나의 긴 지시문에 실으면 문맥을 차지하고 오래된 규칙이 섞이기 쉽다는 관찰도 담겼다.

Anthropic의 2026년 Managed Agents 구조 설명은 세션을 모든 사건의 지속 로그, 하네스를 Claude 호출과 도구 전달을 맡는 루프, 샌드박스를 실제 실행 환경으로 나눈다. 전체 세션 기록과 모델에 넣는 현재 문맥도 구분한다. 필요할 때 세션의 특정 사건을 다시 읽을 수 있다. 기업 챗봇에는 상담 원문을 보존하면서, 현재 질문에 필요한 대화 부분만 읽는 설계가 적합하다. 이 마지막 문장은 공개 구조를 상담 서비스에 적용한 나의 제안이다.

이 글을 조사할 때 나는 질문에 맞는 공식 페이지를 검색하고 관련 부분을 열어 비교했다. 별도의 벡터 색인을 직접 만들지는 않았다. 검색 서비스 내부에서 어떤 색인을 쓰는지까지 확인한 것은 아니다. 사용자에게 답할 자료가 검색 결과에 들어온 다음에는 조건과 출처를 모델이 읽고 판단한다. 이 단계가 빠지면 검색 결과가 좋아도 잘못된 약속을 할 수 있다.

실제 기업 데이터 에이전트는 ‘쓸 수 있는 자료’를 어떻게 만드는가

OpenAI의 사내 데이터 에이전트 공개 사례가 이 질문에 가장 직접적이다. 이 시스템은 DB 스키마·테이블 계보, 과거 쿼리의 사용 패턴, 담당자가 적은 비즈니스 설명, 코드에서 파악한 데이터 생성 방식, 사내 문서, 사용자의 정정을 서로 다른 맥락 층으로 다룬다. 문서에는 접근 권한과 메타데이터가 붙는다. 매일 실행하는 처리 과정에서 여러 설명을 정규화한 검색 자료로 만들고 임베딩으로 색인한다. 질문을 받으면 관련 설명만 검색하고, 낡았거나 빠진 정보는 데이터 창고를 실시간으로 조회한다.

이 사례에서 벡터 검색은 실제로 사용된다. 용도는 수많은 테이블과 사내 설명 중 필요한 맥락을 빠르게 찾는 것이다. 최신 수치나 사용자의 특정 주문 상태까지 임베딩 결과로 대신하지 않는다. 모델은 조회 결과가 비정상적이면 쿼리를 고쳐 재확인한다. 원문의 ‘Table Usage’, ‘Human Annotations’, ‘Codex Enrichment’, ‘Institutional Knowledge’, ‘Memory’, ‘Runtime Context’ 절을 직접 보면 어떤 자료를 사전에 만들고 무엇을 실행 중에 읽는지 구분할 수 있다.

이를 쇼핑몰 상담에 옮겨보자. 교환 정책 PDF, 상품 DB, 고객 대화, 주문 API는 각각 다른 원본이다. PDF의 “A-17 | 주문 제작 | 단순 변심 교환 불가”라는 표 행을 읽었다면 상품=A-17, 예외=단순 변심 교환 불가, 근거=정책 v3의 4쪽, 시행일, 승인 상태를 연결해 저장한다. Docling의 문서 구조 자료처럼 제목·표·본문·원본 위치를 분리해 추출할 수 있다. 스캔본이라면 OCR이 필요하다. 표의 열이 바뀌어 다른 상품에 예외가 붙지 않았는지는 관리자 검수가 맡는다.

원본	미리 만들어 둘 자료	질문 시 다시 확인할 것
교환 정책 PDF	조항·예외·적용 상품·시행일·원본 쪽수	현행 승인판의 원문과 충돌 조항
상품 DB	상품 코드·필드 의미·분류	그 상품의 현재 속성
상담 대화	원문과 출처가 연결된 기억 후보	“지난번 그 제품”의 실제 언급
주문 API	도구 입력·권한·응답 필드 정의	인증 후 그 시점의 주문 상태

Markdown은 사람이 읽고 고치기 편한 형식이다. PDF는 원래 배포 문서의 모양을 보존한다. 둘 다 입력으로 받을 수 있지만 형식만 바꿔서는 시행일·상품별 예외·권한이 생기지 않는다. 기업 운영에서는 원본, 추출된 조항, 승인된 판본, 검색용 표현의 관계를 PostgreSQL 같은 DB에 기록할 수 있다. 검색 색인은 다시 만들 수 있는 파생물로 둔다. 어느 형식으로 들어왔든 답변에 쓰기 전의 추출·연결·검수 과정은 같다.

질문 한 건을 처리하는 실행 순서

다음은 가상 상담 설계 예시다. 일반 정책은 “수령 후 14일 이내 미사용 상품 교환 가능”이고, A-17에는 “주문 제작품의 단순 변심 교환 불가”라는 예외가 있다. 고객이 “지난번에 본 A-17, 다음 주에 받아도 교환돼요?”라고 물었다.

1. 대화의 지시 대상 확인. 현재 메시지와 허용된 과거 대화에서 ‘지난번에 본 상품’을 확인한다. 요약에 A-17이 있더라도 원문 메시지로 재확인한다. OpenClaw의 과거 세션 회상은 허용된 개인 대화의 관련 발췌만 가져오고 그룹·다른 에이전트의 대화를 제외한다.
2. 정확 조회와 정책 검색. 서버가 A-17의 상품 행과 현행 승인 정책을 조회한다. 코드에는 정확 조회, 조항에는 키워드 검색을 우선 쓴다. 내부 문서가 다른 표현을 사용해 결과를 놓칠 때 별칭·혼합 검색을 보탠다. 검색 결과에는 짧은 내용과 원본 ID를 넣는다.
3. 원문과 조건 비교. 모델이 일반 정책과 A-17 예외의 실제 문구를 읽는다. 시행일·적용 상품을 비교한다. 예외가 없거나 충돌하면 교환 가능 여부를 확정하지 않고 확인을 요청한다.
4. 답변 검증. “A-17은 주문 제작 상품이라 단순 변심 교환 대상에서 제외됩니다. 불량은 수령 뒤 상담원이 확인합니다”처럼 답한다. 서버는 근거 ID가 이번 조회에 포함됐는지, 고객이 볼 권한이 있는 자료인지 확인한다.
5. 기억 후보 판단. 이 문의 자체는 장기 기억에 넣지 않는다. 고객이 “앞으로는 짧게 설명해 주세요”라고 명시했다면 사용자 선호 후보가 된다. 구매 사실은 대화의 추측으로 저장하지 않고 주문 시스템에서 다시 확인한다.

오답의 위치를 찾는 법
일반 정책만 검색됐다면 상품 예외의 추출·검색을 확인한다. 두 문서를 모두 가져왔는데도 일반 정책만 답했다면 조건 비교를 확인한다. 지난 대화에서 다른 상품을 찾았다면 회상의 범위와 정확도를 확인한다. 고객의 구매 여부를 추측했다면 주문 조회와 근거 사용 규칙을 확인한다.

벡터 검색은 언제 넣을까

상품 코드, 고객 번호, 시행일, 정확한 조항은 DB 조회·전문 검색이 유리한 출발점이다. 사용자가 “회사 계정으로 로그인”이라고 물었는데 문서에는 ‘SSO’만 쓰여 있다면 별칭 사전이나 의미 검색이 도움이 된다. OpenClaw의 기본 검색 엔진도 키워드와 의미 검색을 혼합할 수 있다. 앞서 본 OpenAI 사내 데이터 에이전트는 방대한 테이블 설명을 찾기 위해 미리 만든 임베딩을 쓴다.

방법은 실제 고객 질문으로 비교한다. 정책·상품·주문·과거 대화 질문 50~100개에 정답 근거를 사람이 붙이고, SQL·키워드 기준선과 혼합 검색을 같은 조건에서 평가한다. 정답 근거가 상위 결과에 들어왔는지, 모델이 예외를 맞게 적용했는지, 응답 지연과 토큰 비용이 얼마인지 기록한다. 2026년 OpenAI 하네스 설명은 한 요청에서 모델·도구 호출이 반복되므로 각 단계의 문맥 크기와 실행 비용이 누적된다고 설명한다.

NestJS·PostgreSQL로 만들 첫 범위

내가 생각하는 출발점은 AWS Lightsail에 Node.js·NestJS API를 두고 PostgreSQL을 연결하는 구성이다. 채팅 화면은 이 API를 사용한다. 첫 읽기 도구는 findPolicy(승인된 정책), getProduct(정확한 상품), getOrder(인증된 고객 주문), findConversation(허용된 과거 대화)로 한정한다. 모델이 도구를 요청하면 서버가 권한을 검증하고 실행한다. OpenAI 함수 호출 공식 문서에도 이 실행 주체의 구분이 설명돼 있다. 환불 실행 같은 쓰기 도구는 승인·감사 흐름을 정한 뒤 추가한다.

DB에는 원본 → 추출 단위 → 승인된 지식 → 검색 색인의 연결을 남긴다. 대화 원문과 선별된 기억 후보는 따로 관리한다. 관리자 화면에서는 문서의 원본 위치·시행일·이전 판본·공개 범위를 확인하고 게시한다. 상담 검토 화면에는 고객 질문, 사용한 도구와 검색 결과, 인용한 자료 버전, 프롬프트·모델 버전, 토큰 사용량, 최종 답변을 묶는다. 삭제 요청은 대화 원문, 요약·기억, 색인, 백업의 처리 범위를 각각 확인해야 한다. OpenClaw의 삭제 경계 문서도 파생 기억과 원본 대화의 삭제 범위가 다르다는 사례를 보여준다.

첫 검증에는 같은 상품의 일반 규정과 예외, 새 정책과 폐기 판본, 내부 약어, 인증이 필요한 주문, 이전 대화의 “그 제품”, 근거가 없는 요청을 포함한다. 질문마다 정답 근거와 허용되는 답을 사람이 적는다. A-17 예외를 찾았는지, Pro 요금제의 최신판을 적용했는지, 주문 소유권 없이 개인정보를 말하지 않았는지, 근거가 없을 때 되묻거나 인계했는지를 검사한다. OpenAI의 평가 가이드는 실제 사용 사례를 모아 변경 후 반복 평가할 것을 권한다. 다음 편에서는 한 업종과 첫 상담 업무를 정하고 이 구조를 구현 단위로 이어가겠다.