언어 모델은 글을 읽고 이어질 글을 만들어 내는 AI 모델이고, 도구는 파일 읽기나 검색처럼 모델이 불러 쓰는 기능입니다. AI 모델 Claude를 만드는 Anthropic도 에이전트는 사람의 명령이나 사람과 나눈 대화로 일을 시작하고, 할 일이 분명해지면 스스로 계획을 세워 움직이되 필요하면 사람에게 돌아와 정보나 판단을 구한다고 설명합니다(Anthropic, 2024년 12월).

혼자 끝낼 수 있는 일의 길이에도 한계가 있습니다. AI 평가 기관 METR가 2026년 9월 8일에 더는 갱신하지 않는다고 밝힌 공개 측정표에서 가장 앞선 모델인 Claude Mythos Preview 초기 버전은, 주로 소프트웨어 개발, 기계 학습, 사이버 보안 분야의 과제 가운데 절반의 확률로 끝낼 것으로 추정되는 과제의 길이가 사람 전문가 기준 약 17시간이었지만, 80%의 확률로 끝낼 것으로 추정되는 과제의 길이는 약 3시간이었습니다(METR, 2026).

AI 에이전트는 무엇으로 이루어지나요?

AI 에이전트는 글을 읽고 쓰는 언어 모델과, 그 모델에게 지시와 도구를 건네고 모델이 고른 동작을 실제로 실행하는 하네스로 이루어집니다. 그래서 AI 에이전트는 언어 모델에 도구와 규칙을 묶어, 사람의 요청이나 정해 둔 시각·사건에 따라 여러 단계의 일을 이어 처리하는 프로그램이라고 정리할 수 있습니다.

Anthropic은 검색과 도구, 기억 장치를 더한 언어 모델을 에이전트 시스템의 기본 부품으로 보고, 에이전트를 대개 주변 환경에서 돌아온 결과를 보며 도구를 되풀이해 쓰는 언어 모델이라고 설명합니다. 에이전트는 단계마다 도구가 돌려준 결과나 코드를 실행한 결과로 실제 상황을 확인하며 다음 동작을 고릅니다(Anthropic, 2024년 12월). 모델을 감싸는 하네스가 무엇을 가리키는지는 "하네스 엔지니어링이란"에서 다룹니다.

같은 글은 에이전트라고 불리는 시스템을 둘로 나눠 봐야 한다고 설명합니다. 언어 모델과 도구가 미리 짜 둔 순서대로 움직이는 것은 워크플로이고, 언어 모델이 어떤 순서로 어떤 도구를 쓸지 스스로 정하는 것이 에이전트입니다. Anthropic은 둘을 모두 에이전트 시스템이라고 부르되 구조는 구별합니다(Anthropic, 2024년 12월).

AI 에이전트가 스스로 일하는 것처럼 보이는 까닭은 무엇인가요?

AI 에이전트가 스스로 일하는 것처럼 보이는 까닭은 일을 시작하는 계기가 사람이 매번 손대지 않아도 이어지게 짜여 있기 때문입니다. 계기는 사람의 요청, 정해 둔 시각, 정해 둔 사건의 세 가지이고, 에이전트가 낸 결과가 다시 다음 사건이 되기도 합니다.

코드 저장소 서비스 GitHub에서 Claude Code를 실행하는 공식 도구가 세 가지 계기를 모두 보여 줍니다. 사람이 이슈나 코드 변경 요청의 댓글에 @claude라고 적으면 그 요청에 답하고, 지시문을 미리 넣어 두면 새 코드 변경 요청이 열리는 것 같은 GitHub의 사건에 맞춰 실행되며, 크론 표현식 "0 9 * * *"을 넣으면 매일 협정 세계시 9시에 보고서를 만듭니다. 이 도구는 다른 봇이 Claude를 부르면 기본적으로 실행을 거절하는데, 봇끼리 서로를 불러 실행이 끝없이 반복되는 일을 막기 위해서입니다(Claude Code GitHub Actions 문서).

정해 둔 시각에 깨우는 방식에는 하트비트와 크론이 있습니다. 개인용 AI 에이전트 OpenClaw의 문서는 하트비트를 기본값으로 30분마다 돌아가는 주기적인 작업으로, 크론을 정확한 시각에 에이전트를 깨우는 내장 예약 기능으로 설명합니다. 그리고 매일 오전 9시 정각에 보고서를 보내는 일처럼 시각이 정확해야 하면 크론을, 대략적인 시각으로 충분한 주기적 확인이면 하트비트를 쓰라고 안내합니다(OpenClaw 자동화 문서).

그래서 에이전트를 스스로 일감을 찾아 나서는 존재로 보기보다, 계기와 처리가 이어지는 구조로 보는 편이 실제에 가깝습니다. 어떤 계기에 무엇을 하게 할지는 사람이 미리 정해 둔 것입니다.

AI 에이전트는 얼마나 긴 일을 혼자 끝낼 수 있나요?

METR가 2026년 9월 8일부터 갱신하지 않는 측정표에서 가장 앞선 모델인 Claude Mythos Preview 초기 버전은, 주로 소프트웨어 개발, 기계 학습, 사이버 보안 분야의 과제 가운데 사람 전문가가 약 17시간 걸리는 과제를 절반의 확률로 끝낼 것으로 추정되었지만, 80%의 확률로 끝낼 것으로 추정되는 과제는 약 3시간짜리였습니다(METR, 2026). METR는 과제의 길이를 사람 전문가가 끝내는 데 걸리는 시간으로 재고, AI 에이전트가 절반의 확률로 성공하는 과제 길이를 50% 시간 지평이라고 부릅니다(METR, 2026).

이 값은 METR의 측정 방식 Time Horizon 1.1로 잰 결과입니다. 50% 시간 지평은 약 17시간 25분이었지만 95% 신뢰구간이 약 8시간 30분에서 55시간까지로 넓었고, 80% 시간 지평은 약 3시간 6분이었습니다(METR 측정 자료, 2026). 같은 일을 열 번 가운데 여덟 번 이상 해내야 한다면, 맡길 수 있는 일의 길이는 절반을 기준으로 할 때보다 훨씬 짧아진다는 뜻입니다.

이 길이는 빠르게 늘어 왔습니다. METR는 2025년 3월 19일 이 지표가 지난 6년 동안 약 7개월마다 두 배로 늘었다고 발표했고, 당시 모델들은 사람이 4분 안에 끝내는 과제는 거의 모두 성공했지만 4시간이 넘는 과제는 10% 미만만 성공했습니다(METR, 2025). 지금의 측정 자료로 2023년 이후 모델만 보면, 16시간이 넘는 추정값을 빼고 계산한 두 배 시간은 약 129일이었습니다(METR 측정 자료, 2026).

다만 METR의 과제는 대부분 소프트웨어 개발, 기계 학습, 사이버 보안 과제이고, METR 스스로 이 과제들이 실제로 돈을 받고 하는 일보다 훨씬 깔끔하며 AI 에이전트는 더 지저분한 과제에서 성적이 낮았다고 밝힙니다(METR, 2026). 회사의 문서 업무처럼 조건이 흩어져 있는 일에서도 같은 길이를 기대할 수는 없습니다.

AI 에이전트에게 맡기기 좋은 일은 무엇인가요?

AI 에이전트에게 맡기기 좋은 일은 필요한 단계 수를 미리 정하기 어렵지만, 결과가 맞는지 확인할 방법이 분명한 일입니다. Anthropic은 단계 수를 예측하기 어려운 열린 문제에 에이전트를 쓸 수 있다고 보면서도, 그 판단을 어느 정도 믿을 수 있어야 하고 자율적으로 움직이는 만큼 비용이 들며 오류가 쌓일 수 있다고 설명합니다(Anthropic, 2024년 12월).

같은 글은 코딩을 에이전트가 잘 맞는 분야로 꼽으며, 코드는 자동 시험으로 맞는지 확인할 수 있고, 에이전트가 그 시험 결과를 받아 고칠 수 있으며, 문제의 범위가 잘 정해져 있고, 결과의 품질을 객관적으로 잴 수 있다는 네 가지 까닭을 듭니다. 그래도 해법이 시스템 전체의 요구에 맞는지 확인하는 데는 사람의 검토가 여전히 중요하다고 덧붙입니다(Anthropic, 2024년 12월). AI가 만든 결과도 사람이 만든 결과처럼 실제로 실행해서 확인해야 한다는 뜻입니다.

반대로 순서가 늘 같은 일은 굳이 에이전트로 만들 필요가 없습니다. Anthropic은 가장 단순한 방법부터 찾고 필요할 때만 복잡도를 올리라고 권하며, 서로 기대지 않는 하위 작업으로 나눌 수 있는 일은 여러 모델에게 동시에 맡겨 속도를 높이는 방식도 소개합니다(Anthropic, 2024년 12월). 예시로 거래처 수백 곳의 계약서에서 만료일을 찾아 표로 모으는 일은, 계약서마다 따로 처리할 수 있고 결과를 원문과 맞춰 보기도 쉬워 이런 방식에 맞습니다.

AI 에이전트를 쓰면 사람은 무엇을 하나요?

사람은 무엇을 맡길지 정하고 일을 분명하게 설명하며, 에이전트가 되묻는 판단에 답하고 결과를 검토합니다. Anthropic의 설명에서도 에이전트는 할 일이 분명해진 뒤에야 스스로 움직이고, 정해 둔 확인 지점이나 막히는 곳에서 멈춰 사람의 의견을 받을 수 있습니다(Anthropic, 2024년 12월).

일을 분명하게 설명한다는 것은 사람의 머릿속이나 회의에만 있던 맥락을 에이전트가 읽을 수 있는 글로 옮긴다는 뜻이기도 합니다. 에이전트가 실행 중에 읽을 수 없는 지식은 그 에이전트에게 없는 것과 같다는 공개 사례는 "하네스 엔지니어링이란"에, 모델이 읽을 정보를 고르는 일은 "컨텍스트 엔지니어링이란"에 정리했습니다.

AI 에이전트에 관해 더 알아보려면 무엇을 읽으면 되나요?

에이전트를 감싸는 하네스는 "하네스 엔지니어링이란? 뜻과 설계 대상, 대표적인 실패"에서, 여러 에이전트를 함께 쓸 때 생기는 오류는 "멀티 에이전트에서는 언제 오류가 커지나요?"에서 다룹니다. 다른 질문은 AX 가이드의 에이전트와 하네스에서 찾을 수 있습니다.

여기서 AI 모델은 글을 읽고 이어질 글을 만들어 내는 언어 모델을 말하고, 컨텍스트는 모델이 답을 만들 때 함께 읽는 글 전체를 말합니다. AI 모델 Claude를 만드는 Anthropic은 2025년 9월 29일 공개한 글에서 컨텍스트를 언어 모델이 답을 만들 때 넣는 토큰(모델이 글을 잘게 나눠 읽고 쓰는 단위)의 묶음으로, 컨텍스트 엔지니어링을 그 토큰의 가장 알맞은 묶음을 고르고 유지하는 전략으로 정의했습니다(Anthropic, 2025년 9월).

넣는 정보가 많다고 답이 좋아지지는 않습니다. 벡터 데이터베이스 회사 Chroma가 2025년 7월 14일 공개한 보고서에서는, 긴 대화를 기억하는지 묻는 시험 LongMemEval의 질문 306개를 여러 언어 모델에 물었더니, 답에 필요한 부분만 추린 약 300토큰의 입력이 관련 없는 대화까지 담은 약 11만 3천 토큰의 전체 입력보다 시험한 모든 모델에서 뚜렷이 나은 결과를 냈습니다(Chroma, 2025).

컨텍스트 엔지니어링에서는 무엇을 컨텍스트로 넣나요?

컨텍스트로 넣는 것은 모델에게 주는 지시문, 모델이 쓸 수 있는 도구의 설명, 외부에서 가져온 자료, 앞선 대화처럼 모델이 이번 답을 만들 때 읽는 모든 글입니다. Anthropic은 시스템 지시, 도구, MCP(AI가 외부 도구와 자료에 연결되는 방식을 정한 공개 규약), 외부 데이터, 대화 기록을 그 예로 듭니다(Anthropic, 2025년 9월).

시스템 지시는 시스템 프롬프트라고도 하며, 모델에게 매번 먼저 건네는 기본 지시문입니다. 도구는 파일 읽기나 사내 시스템 조회처럼 모델이 불러 쓰는 기능이고, 모델은 도구마다 붙은 설명을 읽고 어떤 도구를 쓸지 고릅니다. 외부 데이터에는 사내 문서에서 찾아온 글이나 도구가 돌려준 결과가 들어갑니다.

이 이름이 널리 쓰이기 시작한 2025년 6월, AI 연구자 안드레이 카르파티(Andrej Karpathy)는 컨텍스트 엔지니어링을 다음 단계에 꼭 맞는 정보로 컨텍스트 윈도우를 채우는 일로 설명하고, 그 재료로 작업 설명과 해설, 몇 가지 예시, RAG로 찾은 자료, 관련 자료, 도구, 작업의 상태와 기록, 압축 등을 꼽았습니다(Willison, 2025). 컨텍스트 윈도우는 모델이 한 번에 다룰 수 있는 글의 한도이고, RAG는 질문과 관련된 문서를 찾아 모델이 함께 읽게 하는 방식입니다.

예시로 설비 담당자가 "펌프의 정비 주기가 얼마인가요?"라고 물었다고 해 봅시다. 프롬프트 엔지니어링은 "답에 근거 문서의 쪽수를 붙여라" 같은 지시문을 다듬는 일입니다. 컨텍스트 엔지니어링은 그 지시문과 함께 펌프 매뉴얼의 어느 판을 넣을지, 지난 정비 기록을 넣을지, 정비 일정을 조회하는 도구의 설명을 넣을지를 고르는 일입니다.

컨텍스트 엔지니어링과 프롬프트 엔지니어링은 무엇이 다른가요?

프롬프트 엔지니어링은 모델에게 주는 지시문을 쓰고 다듬는 일이고, 컨텍스트 엔지니어링은 그 지시문을 포함해 모델이 읽는 정보 전체를 고르는 일입니다. Anthropic은 지시문 쓰기를 따로 떨어진 한 번의 작업으로, 컨텍스트 엔지니어링을 모델에게 무엇을 넘길지 정할 때마다 되풀이하는 작업으로 나누고, 컨텍스트 엔지니어링을 프롬프트 엔지니어링이 자연스럽게 발전한 단계로 봅니다(Anthropic, 2025년 9월).

이 이름은 2025년 6월 전자상거래 플랫폼 Shopify의 CEO 토비 뤼트케(Tobi Lütke)가, 과제를 언어 모델이 풀 수 있을 만큼 필요한 맥락을 모두 건네는 일이 핵심 기술이고 컨텍스트 엔지니어링이라는 말이 그 기술을 더 잘 설명한다고 쓰고, 카르파티가 이에 동의하면서 퍼졌습니다. 개발자 사이먼 윌리슨(Simon Willison)은 많은 사람이 프롬프트 엔지니어링을 챗봇에 글을 입력하는 일 정도로 짐작했다며, 말의 뜻은 사람들이 짐작한 쪽으로 굳는데 컨텍스트 엔지니어링은 짐작한 뜻이 의도한 뜻에 훨씬 가깝다고 보았습니다(Willison, 2025).

지시문을 다듬는 일이 쓸모없어진 것은 아니지만, 어디에나 통하는 지시문 공식은 기대하기 어렵습니다. 2024년 학회 ICLR에서 발표된 연구는 내용은 그대로 두고 구분 기호나 띄어쓰기 같은 형식만 바꿨는데도, 예시 몇 개를 함께 주고 묻는 방식에서 LLaMA-2-13B 모델의 정확도가 최대 76%포인트까지 달라졌다고 보고했습니다. 어떤 형식이 잘 통하는지도 모델끼리 약하게만 일치했습니다(Sclar 외, 2024).

Anthropic도 시스템 프롬프트에서 흔한 실패를 두 가지로 듭니다. 하나는 원하는 동작을 정확히 끌어내려고 복잡하고 깨지기 쉬운 규칙을 지시문에 하나하나 적어 넣는 것이고, 다른 하나는 모델이 따를 구체적인 신호 없이 막연한 방향만 주는 것입니다. 알맞은 지시문은 행동을 이끌 만큼 구체적이면서, 모델이 판단에 쓸 원칙을 줄 만큼 유연해야 한다는 설명입니다(Anthropic, 2025년 9월).

스킬은 컨텍스트와 무엇이 다른가요?

스킬은 특정 작업에 쓸 지시와 자료를 모델 밖에 묶어 둔 꾸러미이고, 컨텍스트는 그 가운데 이번에 모델이 실제로 읽는 부분입니다. Anthropic이 2025년 10월 16일 공개한 에이전트 스킬(Agent Skills)은 지시문과 스크립트, 참고 자료를 정리해 둔 폴더이며, 스킬마다 SKILL.md라는 문서 하나가 중심이 됩니다(Anthropic, 2025년 10월).

스킬은 단계적 공개(progressive disclosure)라는 방식으로 컨텍스트를 아낍니다. 에이전트는 시작할 때 설치된 스킬마다 이름과 짧은 설명만 시스템 프롬프트에 넣어 두고, 지금 일에 맞는 스킬이라고 판단하면 그때 SKILL.md 전체를 읽으며, 딸린 파일은 필요할 때만 열어 봅니다. 그래서 Anthropic은 스킬 하나에 담을 수 있는 내용의 양에 사실상 한계가 없다고 설명하고, 같은 해 12월 18일에는 에이전트 스킬을 여러 제품에서 함께 쓸 수 있는 공개 표준으로 내놓았습니다(Anthropic, 2025년 10월). AI 에이전트는 언어 모델에 도구와 규칙을 묶어, 사람의 요청이나 정해 둔 시각·사건에 따라 여러 단계의 일을 이어 처리하는 프로그램입니다.

다만 처음부터 읽히는 이름과 설명은 스킬이 늘수록 함께 늘어납니다. 설명만 보고 서로 구별되지 않는 선택지가 많아지면 모델이 맞지 않는 것을 고르기 쉬워지는데, 이 문제는 "하네스에 기능을 많이 넣으면 AI가 더 잘 고르나요?"에서 다룹니다.

컨텍스트를 많이 넣을수록 AI의 답이 좋아지나요?

그렇지 않습니다. 컨텍스트에 든 토큰이 늘수록 모델이 그 안의 정보를 정확히 떠올리는 능력은 떨어지며, Anthropic은 이 현상을 컨텍스트 부패(context rot)라고 소개하면서 성능이 어느 길이에서 갑자기 무너지기보다 서서히 낮아진다고 설명합니다(Anthropic, 2025년 9월).

Anthropic은 그 까닭을 모델의 구조에서 찾습니다. 지금의 언어 모델이 쓰는 트랜스포머 구조에서는 모든 토큰이 다른 모든 토큰을 참고할 수 있어 토큰 n개 사이에 n²개의 짝이 생기고, 글이 길어질수록 모델이 이 관계를 제대로 파악하는 능력이 떨어진다는 설명입니다. 그래서 Anthropic은 컨텍스트를 넣을수록 얻는 이득이 줄어드는 한정된 자원으로 보고, 원하는 결과가 나올 가능성을 가장 높이는 가장 작은 토큰 묶음을 찾으라고 권합니다(Anthropic, 2025년 9월).

Chroma의 같은 보고서는 질문과 비슷해 보이지만 답은 아닌 문장, 즉 방해 문장을 하나만 섞어도 성능이 기준보다 떨어졌다고 보고했습니다(Chroma, 2025). 긴 입력의 가운데에 놓인 정보를 앞이나 끝의 정보보다 잘 쓰지 못하는 현상은 "컨텍스트 윈도우란? AI가 긴 대화와 긴 문서에서 놓치는 것"에서 다룹니다.

그래서 무엇을 넣고 뺄지 정하는 일은, 이번 일에서 무엇이 중요한지와 어떤 정보끼리 사실상 같은 내용인지를 정하는 일이 됩니다. 예시로 같은 사내 규정의 2판과 3판이 함께 들어가면, 모델은 어느 판이 지금 유효한지 모른 채 두 판의 문장을 섞어 쓸 수 있습니다. Anthropic이 가장 가볍고 안전한 압축으로 꼽은 도구 결과 지우기도, 대화 기록 깊숙이 남은 도구의 원래 출력을 에이전트가 다시 볼 필요는 없다는 판단에 기댑니다(Anthropic, 2025년 9월).

예시를 넣을 때도 같은 원칙이 적용됩니다. Anthropic은 지켜야 할 예외를 지시문에 줄줄이 늘어놓는 방식을 권하지 않고, 기대하는 동작을 잘 보여 주는 다양하고 대표적인 예시를 골라 넣으라고 권합니다(Anthropic, 2025년 9월).

AI가 필요한 정보를 스스로 찾아 읽게 할 수도 있나요?

네, 할 수 있습니다. 자료를 미리 골라 넣는 대신 파일 경로나 저장해 둔 검색 조건, 웹 링크 같은 가벼운 식별자만 건네고, 모델이 도구로 필요한 내용을 그때그때 찾아 읽게 하는 방식을 Anthropic은 필요한 때에 맞춘(just in time) 방식이라고 부릅니다(Anthropic, 2025년 9월).

Anthropic의 코딩 도구 Claude Code가 이 방식을 씁니다. 큰 데이터베이스를 분석할 때도 데이터 전체를 컨텍스트에 싣지 않고, 파일 이름의 패턴으로 찾는 glob, 글자로 찾는 grep, 파일의 앞부분과 뒷부분만 보는 head와 tail 같은 명령으로 필요한 부분만 찾아 읽습니다. 모델은 이렇게 찾아 읽으며 무엇이 필요한지 단계적으로 알아 갑니다(Anthropic, 2025년 9월).

대가도 있습니다. 실행 중에 찾아 읽는 방식은 미리 계산해 둔 자료를 꺼내는 방식보다 느리고, 안내가 부족하면 에이전트가 도구를 잘못 쓰거나 막다른 길을 쫓느라 컨텍스트를 낭비할 수 있습니다. 그래서 Claude Code는 프로젝트 안내 문서인 CLAUDE.md는 처음부터 컨텍스트에 넣고, 나머지는 필요할 때 찾아 읽게 하는 혼합 방식을 씁니다(Anthropic, 2025년 9월).

문서를 미리 조각으로 나눠 색인해 두고 질문과 가까운 조각을 골라 넣는 RAG는, 모델이 찾아 읽는 방식과 달리 고르는 일을 모델을 부르기 전에 끝내 둡니다. RAG가 답을 만드는 순서는 "RAG란? 검색 증강 생성의 뜻과 작동 순서, 한계"에서 다룹니다.

RAG(검색 증강 생성)는 AI가 답을 쓰기 전에 관련 자료를 찾아 함께 읽게 하는 방식이고, 지식 그래프는 대상을 점으로, 대상 사이의 관계를 선으로 이어 사실을 담은 자료입니다. 이 방식을 제안한 Microsoft 연구진의 논문은 2024년 4월 처음 공개되고 2025년 2월 고쳐졌으며, 약 100만 토큰과 170만 토큰 규모의 자료 두 묶음으로 방법을 시험했습니다(Edge 외, 2024). 토큰은 모델이 글을 잘게 나눠 읽고 쓰는 단위입니다.

그래프가 모든 질문에 나은 것은 아닙니다. 같은 조건에서 두 방식을 비교하고 2026년 3월에 고친 판을 낸 연구는 한 문단에 답이 있는 세부 사실 질문에서는 일반 RAG가, 여러 문서를 건너야 하는 질문에서는 GraphRAG 계열이 나았다고 보고했고, 언어 모델이 만든 그래프에는 정답이 되는 대상의 약 65.8%(HotpotQA)와 65.5%(Natural Questions)만 들어 있었다고 밝혔습니다(Han 외, 2026).

GraphRAG는 일반 RAG와 무엇이 다른가요?

GraphRAG는 근거로 찾아 쓰는 대상이 일반 RAG와 다릅니다. 일반 RAG는 질문과 뜻이 가까운 문서 조각을 고르고, GraphRAG는 문서에서 뽑은 대상과 관계의 그래프, 그리고 그래프에서 가깝게 이어진 대상의 묶음마다 미리 써 둔 요약을 근거로 씁니다.

Microsoft 연구진은 "이 자료의 주요 주제는 무엇인가?"처럼 자료 전체를 묻는 질문에 일반 RAG가 약하다는 점에서 출발했습니다. 이런 질문은 답이 한 조각에 들어 있지 않기 때문입니다. GraphRAG는 묶음마다 써 둔 요약으로 각각 부분 답을 만든 뒤, 그 부분 답들을 다시 요약해 최종 답을 씁니다(Edge 외, 2024).

Microsoft가 공개한 GraphRAG 도구는 질문의 종류에 따라 검색 방식을 나눕니다. 전역 검색은 묶음별 요약으로 자료 전체에 관한 질문에 답하고, 지역 검색은 특정 대상에서 출발해 이웃한 대상과 관련 개념으로 넓혀 가며 근거를 찾으며, 기본 검색은 일반 RAG처럼 가까운 조각 몇 개를 고릅니다(Microsoft GraphRAG 문서).

정리하면 두 방식은 미리 만들어 두는 것과 잘 맞는 질문이 다릅니다.

GraphRAG의 그래프는 누가 만드나요?

GraphRAG의 그래프는 대개 언어 모델이 문서를 읽고 만듭니다. Microsoft의 GraphRAG는 자료를 분석 단위인 글 조각으로 나누고, 조각마다 대상과 관계, 핵심 주장을 뽑아 그래프를 만든 뒤, 라이덴(Leiden) 알고리즘, 즉 그래프에서 촘촘히 이어진 점끼리 묶어 내는 방법으로 그래프를 여러 층의 묶음으로 나누고 아래 묶음부터 요약을 씁니다(Microsoft GraphRAG 문서).

논문의 시험에서는 팟캐스트 대본 약 100만 토큰을 600토큰 조각 1,669개로 나눴고, 앞뒤 조각이 100토큰씩 겹치게 했습니다. 이 그래프를 만드는 데 GPT-4-turbo로 281분이 걸렸습니다. 대상을 뽑는 지시문에는 그 자료의 분야에 맞춘 대상 종류와 예시를 넣었습니다(Edge 외, 2024).

뽑히는 대상의 수는 조각의 크기에 따라 달라졌습니다. 같은 논문이 HotPotQA 질문 모음의 표본으로 시험해 보니, GPT-4는 조각이 600토큰일 때 2,400토큰일 때보다 대상을 가리키는 표현을 거의 두 배 많이 뽑았고, 연구진은 놓친 대상을 다시 찾도록 이미 뽑은 대상 목록을 모델에게 돌려주는 단계도 두었습니다(Edge 외, 2024). Microsoft의 문서도 기본 설정을 그대로 쓰면 자기 자료에서 가장 좋은 결과가 나오지 않을 수 있다고 안내합니다(Microsoft GraphRAG 문서).

GraphRAG는 어떤 질문에 강하고 어떤 질문에 약한가요?

GraphRAG는 자료 전체를 아우르는 질문과 여러 문서를 건너 이어지는 질문에 강하고, 한 문단에 답이 있는 세부 사실 질문에서는 일반 RAG가 나을 때가 많습니다.

2024년 4월 처음 공개된 Microsoft 연구진의 논문은 팟캐스트 자료와 뉴스 자료에서 질문 125개씩을 두고 두 방식의 답을 언어 모델에게 판정하게 했는데, 자료 전체를 요약해 답하는 전역 방식은 답이 필요한 내용을 얼마나 빠짐없이 담았는지를 따진 비교에서 일반 RAG를 각각 72~83%, 72~80%의 비율로 이겼고, 답이 얼마나 다양한 관점을 담았는지를 따진 비교에서는 각각 75~82%, 62~71%의 비율로 이겼습니다(Edge 외, 2024). 반면 질문에 가장 곧바로 답한 쪽은 일반 RAG였습니다. 다만 언어 모델 평가자는 두 답의 순서만 바꿔도 판정이 달라질 수 있습니다. 이 치우침은 "멀티 에이전트에서는 언제 오류가 커지나요?"에서 다룹니다.

세부 질문에서는 결과가 달랐습니다. 앞의 비교 연구는 일반 RAG가 한 문단에서 답을 찾는 세부 사실 질문에서 앞섰고, 그래프를 쓰는 방식은 여러 문서를 건너야 하는 질문에서 앞섰다고 보고했습니다. 같은 연구는 요약을 대상으로 한 검색이 비교 질문과 시간 순서를 묻는 질문에서 도움이 될 수 있다고 적었습니다(Han 외, 2026). Microsoft도 일반 RAG는 특정 사실을 묻는 질문에 강하고, 자료 전체를 묻는 질문에는 GraphRAG의 전역 검색이 필요하다고 설명합니다(Microsoft Research, 2024).

예시로 "지난 3년 동안 불량의 주된 원인은 무엇이었나요?"는 여러 보고서를 아울러야 하므로 GraphRAG의 전역 검색이 맞고, "펌프의 정비 주기는 몇 시간인가요?"는 매뉴얼 한 문단에 답이 있으므로 일반 RAG로 충분합니다.

GraphRAG의 그래프가 틀리면 답은 어떻게 되나요?

그래프에 빠졌거나 잘못 이어진 사실은 답에서도 빠지거나 틀립니다. GraphRAG의 답은 그래프와 그 그래프로 쓴 요약을 근거로 삼기 때문입니다.

빠지는 사실은 생각보다 많을 수 있습니다. 앞의 비교 연구에서 언어 모델이 만든 그래프에는 정답이 되는 대상이 HotpotQA 질문 모음에서 약 65.8%, Natural Questions 질문 모음에서 약 65.5%만 들어 있었습니다(Han 외, 2026). 나머지 대상을 묻는 질문은 그래프만으로는 답할 수 없다는 뜻입니다.

같은 대상이 다른 이름으로 뽑히는 문제도 있습니다. Microsoft의 논문은 이름이 글자 그대로 같을 때만 같은 대상으로 합쳤다고 밝히고, 더 느슨하게 맞추는 방법도 쓸 수 있으며, 중복된 대상은 대개 같은 묶음에 모여 요약되므로 GraphRAG가 중복에 대체로 잘 견딘다고 적었습니다(Edge 외, 2024). 다만 특정 대상에서 출발하는 지역 검색에서는, 예시로 「한빛기계」와 「한빛기계(주)」가 두 점으로 나뉘면 그 회사에 관한 근거도 두 곳으로 흩어질 수 있습니다. 같은 대상을 가리는 기준이 왜 필요한지는 "지식 그래프란? 뜻과 시소러스·택소노미와의 차이"에서 다룹니다.

묶음별 요약도 언어 모델이 쓰므로, 요약에 섞인 오류는 그 요약을 근거로 쓴 답에 그대로 들어갈 수 있습니다. Microsoft의 논문도 답에 지어낸 내용이 섞인 비율을 비교하면 분석이 더 탄탄해질 것이라고 한계로 적었습니다(Edge 외, 2024).

문서가 바뀌면 그래프를 다시 만드는 비용도 생각해야 합니다. 앞의 비교 연구에서 MultiHop-RAG라는 질문 모음의 색인을 만드는 데 걸린 시간은 일반 RAG가 135초였고, 그래프를 쓰는 방식은 묶음별 요약을 만드는 방식이 5,560초, 지식 그래프에서 근거를 찾는 방식이 7,702초였습니다(Han 외, 2026). Microsoft는 이런 비용을 줄이려고 2024년 11월, 색인 비용을 일반 RAG와 같은 수준이자 원래 GraphRAG의 0.1%로 줄인 LazyGraphRAG를 발표했습니다(Microsoft Research, 2024).

RAG의 기본부터 보려면 무엇을 읽으면 되나요?

RAG가 답을 만드는 순서와 한계는 "RAG란? 검색 증강 생성의 뜻과 작동 순서, 한계"에, 그래프에 담기는 지식 그래프의 뜻은 "지식 그래프란? 뜻과 시소러스·택소노미와의 차이"에 정리했습니다. 다른 질문은 AX 가이드의 지식 구조에서 찾을 수 있습니다.

연구자 18명이 학술지 ACM Computing Surveys에 실은 개론 논문은 지식 그래프를 실제 세계의 지식을 모으고 전하기 위한 데이터의 그래프로 정의합니다. 이 그래프에서 점은 관심 있는 대상을, 선은 대상 사이의 관계를 나타냅니다. 같은 논문에 따르면 지식 그래프라는 말은 적어도 1972년부터 문헌에 나오지만, 지금 쓰는 뜻은 2012년 구글의 발표에서 비롯되었습니다(Hogan 외, 2021).

구글은 2012년 5월 16일 검색에 지식 그래프를 도입하며 이를 「문자열이 아니라 사물」을 찾는 일로 소개했고, 당시 이 그래프에는 5억 개가 넘는 대상과 그 대상들에 관한 35억 개가 넘는 사실과 관계가 들어 있었습니다(Google, 2012).

택소노미와 시소러스는 지식 그래프와 무엇이 다른가요?

택소노미는 개념을 「~의 한 종류다」 같은 상하 관계로 나눈 분류 체계이고, 시소러스는 그 위에 같은 뜻의 다른 이름과 관련된 말까지 적은 용어 체계입니다. 둘 다 개념과 용어를 정리한 것인 반면, 지식 그래프는 실제 대상 사이의 여러 관계를 사실로 담는다는 점이 다릅니다.

예시로 「부동산 아래 주택, 주택 아래 아파트」로 나눈 것은 택소노미입니다. 여기에 「고객사」를 대표 이름으로, 「매출처」를 같은 뜻의 다른 이름으로 적고, 「거래처」를 그보다 넓은 말로 적어 두면 시소러스가 됩니다.

웹 표준을 만드는 국제 단체 W3C는 시소러스와 택소노미, 분류표, 주제어 목록을 공유하려고 SKOS라는 어휘를 2009년 8월 18일 권고안으로 냈습니다. SKOS에서는 대표 이름을 prefLabel, 같은 뜻의 다른 이름을 altLabel, 더 넓은 개념을 broader, 관련된 개념을 related로 적습니다. SKOS 입문서는 이런 체계를 반(半)형식적인 지식 조직 체계라고 부르고, 논리를 엄밀하게 적는 OWL 같은 온톨로지 언어와 느슨한 태그 사이를 잇는 기술로 설명합니다(W3C SKOS 입문서, 2009).

시소러스의 상하 관계가 늘 「~의 한 종류다」인 것은 아닙니다. 같은 입문서는 broader가 전체와 부분의 관계도 나타낼 수 있고, 기본 SKOS는 상하 관계의 종류를 나누지 않는다고 적습니다(W3C SKOS 입문서, 2009). 예를 들어 「설비」 아래 「펌프」는 종류 관계이지만, 「펌프」 아래 「임펠러」는 부품 관계입니다. 한편 한국에서 택소노미를 검색하면 2021년 말 환경부가 내놓은 한국형 녹색분류체계(K-택소노미)를 다룬 글이 많이 나오는데, 이 글의 택소노미는 개념을 상하 관계로 나눈 분류 체계를 뜻합니다.

지식 그래프는 무엇으로 이루어지나요?

지식 그래프는 대상을 나타내는 점, 관계를 나타내는 선, 그리고 그 선이 어떤 관계인지 알려 주는 이름으로 이루어집니다. 예시로 「A산업은 펌프를 공급한다」는 사실은 A산업과 펌프라는 두 점을 「공급한다」라는 이름의 선으로 이은 것입니다.

W3C의 데이터 형식 RDF는 사실 하나를 주어, 술어, 목적어의 세 부분으로 적고, 이렇게 적은 사실의 묶음을 RDF 그래프라고 부릅니다(W3C RDF 1.1, 2014). 앞의 예에서 A산업은 주어, 「공급한다」는 술어, 펌프는 목적어입니다. 2014년 권고안인 RDF 1.1의 다음 판 RDF 1.2는 표준이 되기 전 단계인 후보 권고안으로, 2026년 4월 7일 판이 공개되어 있습니다(W3C RDF 1.2, 2026).

앞의 개론 논문은 지식 그래프를 담는 그래프의 형식으로, RDF처럼 선마다 이름이 붙은 방향 있는 그래프와, 점과 선 자체에 「설립 연도」 같은 속성을 덧붙일 수 있는 속성 그래프 등을 소개합니다(Hogan 외, 2021). 어느 형식으로 담든 점과 선이 무엇을 가리키는지가 정해져 있어야 사실로 읽힙니다.

지식 그래프에도 설계도가 필요한가요?

필요합니다. 어떤 종류의 대상과 관계를 쓰고, 이름이 달라도 같은 대상인지 무엇으로 가릴지 정해 두어야, 사실이 쌓일수록 그래프가 쓸모 있어집니다. 이런 틀을 컴퓨터가 읽을 수 있게 정의한 것이 온톨로지입니다.

예시로 영업팀은 거래하는 회사를 「고객사 A산업」으로, 회계팀은 같은 회사를 「매출처 (주)A산업」으로 적었다면, 설계도 없이 두 기록을 합친 그래프에는 회사가 두 점으로 갈립니다. 그러면 계약 기록은 한 점에, 매출 기록은 다른 점에 이어져 「이 회사와의 거래 전체」를 물어도 절반만 나오고, 고객 수는 하나 더 많게 셉니다.

그래서 지식 그래프의 표준에는 같은 대상임을 적는 방법이 있습니다. 앞의 개론 논문은 W3C의 온톨로지 언어 OWL이 정한 sameAs(같음) 속성으로 두 점이 같은 대상이라고 적으면, OWL의 규칙에 따라 두 점의 데이터를 합쳐 볼 수 있다고 설명합니다(Hogan 외, 2021). 온톨로지와 지식 그래프의 관계는 "온톨로지란? 뜻과 구성 요소, 데이터베이스와의 차이"에서 따로 다룹니다.

옵시디언의 그래프 보기도 지식 그래프인가요?

겉모습은 같지만 담는 내용이 다릅니다. 메모 프로그램 옵시디언(Obsidian)의 그래프 보기는 노트 사이의 링크를 그린 그림이고, 기본 그래프 보기의 선에는 두 노트가 「공급한다」인지 「경쟁한다」인지 같은 관계의 이름이 없습니다.

옵시디언 도움말에 따르면 그래프 보기는 보관함 안의 노트 사이의 관계를 보여 주는 기능으로, 원은 노트를, 선은 두 노트 사이의 내부 링크를 나타내며, 어떤 노트를 가리키는 노트가 많을수록 그 원이 커집니다. 현재 노트와 이어진 노트만 보는 로컬 그래프와, 링크가 하나도 없는 노트를 보일지 정하는 설정도 있습니다(Obsidian 도움말).

그래서 그래프 보기로는 어떤 노트가 많이 이어졌는지, 어떤 노트가 다른 노트와 이어지지 않았는지는 알 수 있지만, 노트에 적힌 사실을 AI가 근거로 찾아 쓰게 하려면 RAG나 GraphRAG 같은 장치를 따로 만들어야 합니다. 노트에서 대상과 관계를 뽑아 그래프로 만들고 질문에 쓰는 방식은 "GraphRAG의 뜻과 일반 RAG와의 차이"에서 다룹니다.

지식 그래프와 네트워크 분석은 무엇이 다른가요?

지식 그래프는 사실을 담아 두는 자료이고, 네트워크 분석은 그래프의 연결 구조를 계산해 중심이 되는 점이나 촘촘히 이어진 무리를 찾아내는 분석 방법입니다. 그래서 지식 그래프 위에서 네트워크 분석을 할 수도 있습니다.

앞의 개론 논문은 그래프 분석이 그래프 이론과 네트워크 분석의 기법을 가져다 쓴다고 설명하며, 가장 중요한 점이나 선을 찾는 중심성, 안쪽끼리 더 촘촘히 이어진 무리를 찾는 커뮤니티 탐지, 연결성, 점 사이의 유사도를 대표 기법으로 듭니다. 예를 들어 교통 연결 그래프에서 중심성으로 주요 환승 거점을 찾을 수 있습니다(Hogan 외, 2021).

두 가지는 겉보기에 같은 그래프 그림으로 나타나서 자주 섞여 불립니다. 하지만 네트워크 분석은 선이 몇 개이고 어떻게 이어졌는지를 보고, 지식 그래프는 선 하나하나가 무슨 사실인지를 담습니다. GraphRAG가 그래프를 여러 묶음으로 나눌 때 쓰는 라이덴 알고리즘도 커뮤니티 탐지 기법의 하나입니다.

온톨로지와 GraphRAG도 함께 보려면 무엇을 읽으면 되나요?

지식 그래프의 설계도인 온톨로지는 "온톨로지란? 뜻과 구성 요소, 데이터베이스와의 차이"에서, 문서에서 뽑은 대상과 관계로 지식 그래프를 만들어 질문에 답하는 GraphRAG는 "GraphRAG의 뜻과 일반 RAG와의 차이: 그래프로 근거를 찾는 방식"에서, 데이터와 업무 동작까지 묶는 팔란티어의 온톨로지는 "팔란티어 온톨로지는 일반 온톨로지와 무엇이 다른가요?"에서 다룹니다. 다른 질문은 AX 가이드의 지식 구조에서 찾을 수 있습니다.

신경망은 사람의 신경 세포가 이어진 모양을 본떠, 많은 데이터에서 입력과 출력 사이의 관계를 스스로 익히는 계산 모형입니다. 이 분야를 개관한 논문은 뉴로 심볼릭 연구를 신경망의 탄탄한 학습 능력과 기호 표현의 추론 능력, 설명 가능성을 함께 갖추려는 연구로 설명합니다(Garcez·Lamb, 2020).

잘 알려진 예는 구글 딥마인드가 2024년 1월 17일 발표한 AlphaGeometry입니다. 신경망 언어 모델이 증명에 필요한 보조선 같은 새 작도를 제안하고 기호 추론 엔진이 그 작도를 써서 증명을 따지는 이 시스템은, 국제 수학 올림피아드 기하 문제 30개 가운데 25개를 정해진 시간 안에 풀었습니다. 같은 기하 문제 30개 가운데 이전 최고 방법은 10개를 풀었고, 금메달을 딴 사람들은 평균 25.9개를 풀었습니다(Google DeepMind, 2024).

기호주의 AI는 무엇인가요?

기호주의 AI는 사람이 세상의 개념과 관계를 기호와 규칙으로 직접 적어 넣고, 컴퓨터가 그 규칙을 따라 추론하게 하면 지능을 만들 수 있다고 보는 AI 연구의 흐름입니다. 앨런 뉴얼과 허버트 사이먼은 1975년 튜링상 수상 강연을 1976년 논문으로 내면서, 기호를 다루는 물리적 체계가 일반적인 지능 행동에 필요하고도 충분한 수단을 갖췄다는 가설을 내놓았습니다(Newell·Simon, 1976).

예시로 「한빛아파트 101동 1203호는 아파트다」, 「아파트는 주택의 한 종류다」, 「주택은 부동산의 한 종류다」라고 적어 두면, 컴퓨터는 적혀 있지 않던 「한빛아파트 101동 1203호는 부동산이다」를 끌어냅니다. W3C의 RDF 1.1 의미론은 이런 추론을 규칙으로 정해 두었는데, 어떤 것이 한 종류에 속하고 그 종류가 더 넓은 종류에 속하면 그것도 더 넓은 종류에 속한다는 규칙(rdfs9)과, 종류의 상하 관계가 이어진다는 규칙(rdfs11)입니다(W3C RDF 1.1 의미론, 2014).

전문가 시스템은 무엇이었나요?

전문가 시스템은 한 분야 전문가의 지식을 「이런 조건이면 이렇게 판단한다」 같은 규칙으로 옮겨 적고, 추론 엔진이 그 규칙을 적용해 전문가처럼 판단하게 한 기호주의 AI의 대표적인 응용입니다. 1970년대와 1980년대에 의학, 화학, 설비 구성 같은 분야에서 많이 만들어졌습니다.

스탠퍼드 대학 연구진이 만든 MYCIN은 감염병 환자에게 쓸 항생제를 고르는 전문가 시스템이었습니다. 1979년 학술지 JAMA에 실린 평가에서는 수막염 환자 10명의 사례를 두고, 이 분야 전문가 8명이 누가 처방했는지 모른 채 MYCIN의 처방과 사람 9명의 처방을 평가했습니다. 수막염 사례 10개를 두고 전문가 8명이 매긴 이 평가에서, 받아들일 만하다는 판정을 받은 비율은 MYCIN의 처방이 65%였고 교수진 전문의 5명의 처방은 42.5%에서 62.5% 사이였습니다(Yu 외, 1979).

그러나 규칙을 사람이 적고 고쳐야 했기 때문에, 성공한 전문가 시스템도 운영 비용이 커졌습니다. 컴퓨터 회사 DEC의 주문 구성 시스템 XCON 같은 초기의 성공 사례는 1990년대 초에 이르러 유지하기에 너무 비싸졌고, 전문가 시스템은 예상하지 못한 입력에 터무니없는 실수를 하는 「깨지기 쉬운」 시스템이라는 평가를 받았습니다(위키백과 「AI winter」).

연결주의 AI는 무엇인가요?

연결주의 AI는 사람이 규칙을 적어 넣지 않고, 서로 이어진 수많은 계산 단위로 이루어진 신경망이 데이터에서 관계를 스스로 익히게 하는 AI 연구의 흐름입니다. 지금의 언어 모델을 이루는 딥러닝과 트랜스포머 구조가 이 흐름에 속합니다.

여러 층으로 쌓은 신경망을 학습시키는 방법인 역전파를 널리 알린 논문은 1986년 학술지 Nature에 실렸고(Rumelhart 외, 1986), 지금의 언어 모델이 쓰는 트랜스포머 구조는 2017년에 발표되었습니다(Vaswani 외, 2017).

연결주의는 성능이 뛰어나지만, 신경망 안에서 무엇과 무엇을 어떻게 이었는지 사람이 들여다보기 어렵고, 확률로 다음 낱말을 고르므로 같은 질문에도 답이 달라질 수 있습니다. 같은 입력에 늘 같은 결론을 내는 기호주의의 추론과 정반대의 성질입니다.

Cyc 프로젝트는 왜 기대에 못 미쳤나요?

Cyc는 사람의 상식을 사람이 직접 적어 넣는 방식이 감당하기 어려울 만큼 많은 지식과 시간을 요구한다는 것을 보여 주었습니다. 1984년에 더글러스 레나트(Douglas Lenat)가 시작한 Cyc의 처음 계획은 상식 규칙 약 100만 개를 손으로 적어 두면 그다음부터는 컴퓨터가 글을 읽고 배우며 지식을 스스로 늘려 가는 것이었지만, 레나트와 인지 과학자 게리 마커스(Gary Marcus)가 2023년에 함께 쓴 논문에 따르면 40년 가까이 지난 뒤에도 Cyc의 지식은 대부분 사람이 손으로 적고 확인한 것이었습니다(Lenat, 1995; Lenat·Marcus, 2023).

레나트는 1995년 논문에서 그동안 약 100인년(한 사람이 100년 동안 일한 양)의 노력으로 일반 개념 약 10만 개와 상식 규칙 약 100만 개를 손으로 적어 넣었다고 밝히며, 이 지식을 바탕으로 1990년대 중반부터는 자연어 이해와 기계 학습으로 지식을 더 모으려 했다고 설명했습니다. 1984년에 시작할 때 성공할 가능성이 낮다는 것을 알았다고도 적었습니다(Lenat, 1995).

같은 2023년 논문에 따르면, 지금의 Cyc 지식 베이스는 논리학자와 프로그래머로 이루어진 팀이 40년 동안 약 2,000인년을 들여 만든 것이고, 사람이 직접 쓴 수천만 개의 주장으로 이루어져 있으며, 규칙 하나하나를 사람이 확인한 뒤에 넣습니다. 팀을 더 크게 늘렸을 때는 오히려 전체 생산성이 떨어졌다고도 적었습니다(Lenat·Marcus, 2023).

Cyc는 AI 침체기를 부른 원인이 아니라, 두 침체기 사이에 시작한 프로젝트입니다. AI 연구가 투자와 관심을 크게 잃은 침체기는 대략 1974~1980년과 1987~2000년의 두 번이었고, 첫 번째에는 1973년 영국의 라이트힐 보고서가 영국의 AI 연구를 크게 줄이는 계기가 되었습니다. 두 번째는 1987년 AI 전용 하드웨어 시장이 무너지고 전문가 시스템이 기대에 못 미치면서 왔습니다(위키백과 「AI winter」). Cyc가 시작한 1984년은 전문가 시스템이 한창 주목받던 때였습니다.

「쓰라린 교훈」은 무엇을 말하나요?

「쓰라린 교훈(The Bitter Lesson)」은 사람의 지식을 시스템에 넣는 방법보다, 계산 능력이 커질수록 함께 좋아지는 일반적인 방법이 결국 이긴다는 주장입니다. 강화 학습 연구자 리처드 서튼(Richard Sutton)이 2019년 3월 13일 쓴 짧은 글의 제목이며, 서튼은 이것을 70년 AI 연구에서 읽을 수 있는 가장 큰 교훈이라고 했습니다(Sutton, 2019).

서튼은 1997년 체스 세계 챔피언 카스파로프를 이긴 방법이 사람이 아는 체스의 구조가 아니라 대규모의 깊은 탐색이었고, 1970년대 미국 국방 연구 기관 DARPA가 연 음성 인식 경쟁에서도 낱말과 음소, 사람의 발성 기관에 관한 지식을 넣은 방법보다 은닉 마르코프 모형 같은 통계적 방법이 이겼다는 예를 듭니다. 그리고 계산이 커져도 계속 함께 좋아지는 방법은 탐색과 학습 두 가지라고 정리했습니다(Sutton, 2019).

서튼은 이 교훈이 쓰라린 까닭도 적었습니다. 연구자가 지식을 넣는 방법은 짧게 보면 늘 도움이 되고 만족스럽지만, 길게 보면 정체되거나 발전을 막고, 돌파는 결국 계산을 키우는 반대쪽 방법에서 왔다는 것입니다(Sutton, 2019). 다만 이 글은 서튼의 관점을 담은 에세이이고, 실험으로 증명한 결과는 아닙니다.

온톨로지 추론은 무엇인가요?

온톨로지 추론은 온톨로지에 적어 둔 개념의 관계와 규칙에서, 적혀 있지 않지만 논리적으로 따라 나오는 사실을 추론기라는 프로그램이 계산해 내는 일입니다. 기호주의의 추론을 오늘날의 표준 언어로 하는 방식이라고 볼 수 있습니다.

예시로 「가동률이 90% 이상인 생산 라인은 효율적인 라인이다」라는 규칙과 「라인 A는 생산 라인이고, 가동률은 93%다」라는 사실을 OWL로 적어 두면, 추론기는 「라인 A는 효율적인 라인이다」를 끌어냅니다. OWL은 W3C가 정한 온톨로지 언어이고, 추론기가 내놓을 결론은 OWL 2의 형식 의미론으로 미리 정해져 있습니다(W3C OWL 2 입문서, 2012). 이 추론이 데이터를 바꾸는 업무 시스템과 어떻게 다른지는 "팔란티어 온톨로지는 일반 온톨로지와 무엇이 다른가요?"에서 다룹니다.

왜 지금 기호주의와 연결주의를 합치려 하나요?

두 흐름의 약점이 서로의 강점과 맞물리기 때문입니다. 언어 모델은 사람이 규칙을 다 적지 않아도 글과 상황을 유연하게 다루지만 근거 없는 내용을 사실처럼 쓰거나 같은 질문에 다르게 답할 수 있고, 기호 체계는 규칙을 다 적기 어렵지만 같은 입력에 늘 같은 결론을 내고 그 결론에 이른 단계를 보여 줄 수 있습니다.

AlphaGeometry가 그 예입니다. 딥마인드는 착상을 빠르게 내는 언어 모델과 차근차근 따지는 기호 추론 엔진의 결합을, 빠른 생각과 느린 생각으로 사람의 사고를 나눈 「생각에 관한 생각(Thinking, Fast and Slow)」의 구분에 견주어 설명했습니다. 이 시스템은 사람이 풀어 보인 풀이 없이, 직접 만든 1억 개의 합성 학습 예제로 학습했습니다(Google DeepMind, 2024).

Cyc를 만든 레나트도 2023년 논문에서, 믿을 수 있는 범용 AI라면 언어 모델의 방식과 더 형식적인 방식을 섞어야 한다고 주장했습니다(Lenat·Marcus, 2023). 언어 모델이 근거 없는 내용을 쓰는 까닭은 "할루시네이션이란? AI 환각의 뜻과 원인, 문서 업무에서 나타나는 모양"에서 다룹니다.

온톨로지와 지식 그래프부터 보려면 무엇을 읽으면 되나요?

기호주의의 지식을 담는 틀인 온톨로지는 "온톨로지란? 뜻과 구성 요소, 데이터베이스와의 차이"에서, 사실을 점과 선으로 담는 지식 그래프는 "지식 그래프란? 뜻과 시소러스·택소노미와의 차이"에서 다룹니다. 다른 질문은 AX 가이드의 지식 구조에서 찾을 수 있습니다.

여기서 멀티 에이전트는 여러 AI 에이전트가 일을 나눠 맡고 결과를 주고받으며 하나의 목표를 처리하는 구성이고, AI 에이전트는 언어 모델에 도구와 규칙을 묶어, 사람의 요청이나 정해 둔 시각·사건에 따라 여러 단계의 일을 이어 처리하는 프로그램입니다.

반대로 서로 기대지 않는 조사를 나눠 맡긴 시험에서는 여러 에이전트 구성이 단일 에이전트보다 나았습니다. AI 모델 Claude를 만드는 Anthropic은 2025년 6월, 조사 일을 나눠 맡긴 자사 멀티 에이전트 시스템이 단일 에이전트보다 내부 조사 평가에서 90.2% 높은 성적을 냈다고 밝혔습니다(Anthropic, 2025년 6월).

어느 쪽이 될지는 맡기는 일의 성격에 달려 있습니다. 2026년 4월에 고친 판이 나온 한 연구는 에이전트 구성 260가지를 비교했는데, 단일 에이전트 대비 성적의 변화가 나눠 풀 수 있는 금융 추론 과제의 80.8% 상승부터 차례로 이어지는 계획 과제의 70.0% 하락까지 걸쳐 있었다고 보고했습니다(Kim 외, 2026).

멀티 에이전트 시스템은 무엇인가요?

멀티 에이전트 시스템은 여러 AI 에이전트에게 일을 나눠 맡기고, 한 에이전트의 결과를 다른 에이전트가 받아 쓰거나 모아서 하나의 답을 만드는 시스템입니다. 에이전트마다 지시문과 도구가 다를 수 있고, 같은 모델을 여러 개 실행해 쓰기도 합니다.

Anthropic의 조사 시스템에서는 주 에이전트가 질문을 분석해 조사 전략을 세우고, 여러 하위 에이전트를 만들어 질문의 여러 측면을 동시에 찾게 한 뒤 결과를 모읍니다. 이 구성에서 주 에이전트는 Claude Opus 4, 하위 에이전트는 Claude Sonnet 4였고, 비교 대상은 Claude Opus 4 하나로 된 단일 에이전트였습니다(Anthropic, 2025년 6월).

오류가 어떻게 번지는지는 에이전트끼리 결과를 주고받는 방식에 따라 달라집니다. 앞 에이전트의 결과를 다음 에이전트가 이어 받는 차례형 구성에서는 앞의 오류가 뒤로 넘어가고, 서로 다른 부분을 따로 맡긴 구성에서는 한 에이전트의 오류가 다른 에이전트의 일에 바로 섞이지는 않습니다.

멀티 에이전트에서 오류는 언제 단계마다 불어나나요?

앞 단계의 결과를 뒤 단계가 확인하지 않고 그대로 쓸 때 오류는 단계마다 불어납니다. 단계마다 맞을 확률이 p이고 오류가 서로 따로 생기며 뒤 단계가 걸러 내지 못한다면, n단계를 거친 결과가 맞을 확률은 p를 n번 곱한 값이 됩니다.

그래서 단계마다의 정확도가 조금만 낮아도, 단계가 늘면 전체 정확도는 크게 떨어집니다. 아래는 같은 가정으로 계산한 예시입니다.

실제 시스템은 이 가정과 다릅니다. 뒤 단계가 앞의 오류를 잡아내면 전체 정확도는 계산보다 높아지고, 앞의 오류가 뒤 단계의 판단을 다른 방향으로 끌고 가면 더 낮아집니다. Anthropic은 에이전트가 앞의 상태를 이어 가며 일하므로 오류가 쌓이고, 작은 변화가 큰 동작 변화로 번지며, 한 단계가 실패하면 에이전트가 전혀 다른 경로로 일을 풀어 가기도 한다고 설명합니다(Anthropic, 2025년 6월).

결과를 책임져야 하는 일인지에 따라 이 누적의 무게도 달라집니다. 여러 초안을 많이 만들어 사람이 그중 하나를 고르는 일이라면 일부가 틀려도 감당할 수 있지만, 계약서나 시험 성적서처럼 틀린 문장 하나가 비용이 되는 문서에서는 단계마다 쌓인 오류가 그대로 위험이 됩니다.

멀티 에이전트가 단일 에이전트보다 나은 일은 무엇인가요?

서로 기대지 않는 여러 방향을 동시에 찾아야 하는 넓은 조사에서 멀티 에이전트가 나았습니다. Anthropic은 자사 조사 시스템이 이런 넓게 퍼지는 질문과 병렬로 나눌 수 있는 일에서 특히 강하다고 밝혔고, 정보 기술 업종 S&P 500 기업의 이사회 구성원을 모두 찾는 질문에서 단일 에이전트는 느린 순차 검색으로 답을 찾지 못했지만 멀티 에이전트는 일을 나눠 맡겨 맞는 답을 찾았다고 소개했습니다(Anthropic, 2025년 6월).

대가는 비용입니다. Anthropic이 2025년 6월에 공개한 같은 글에 따르면 에이전트는 일반 채팅보다 토큰(모델이 글을 잘게 나눠 읽고 쓰는 단위)을 약 4배, 멀티 에이전트 시스템은 약 15배 썼습니다. 같은 글에서 Anthropic이 웹 탐색 평가 BrowseComp의 결과를 분석한 바로는, 성적 차이의 80%를 토큰 사용량 하나가 설명했습니다(Anthropic, 2025년 6월). Anthropic은 모든 에이전트가 같은 컨텍스트를 공유해야 하거나 에이전트 사이에 기대는 부분이 많은 일은 아직 멀티 에이전트에 맞지 않고, 대부분의 코딩 과제는 조사보다 병렬로 나눌 부분이 적다고 덧붙였습니다(Anthropic, 2025년 6월).

여러 에이전트가 서로의 답을 읽고 고치는 방식이 나았던 연구도 있습니다. MIT와 구글 브레인의 연구진은 ChatGPT 계열 모델로 에이전트 셋이 두 차례 토론하게 했더니, 단일 에이전트보다 산수 정답률이 67.0%에서 81.8%로, 초등 수학 문장제 모음 GSM8K의 정답률이 77.0%에서 85.0%로 올랐다고 보고했습니다. 컴퓨터 과학자 524명의 약력을 쓰게 한 시험에서도 실제 약력 항목과 맞게 쓴 비율이 66.0%에서 73.8%로 올랐습니다(Du 외, 2023).

AI가 다른 AI의 답을 평가하면 어떤 치우침이 생기나요?

AI 평가자는 답의 순서와 길이에 따라 판정이 기울 수 있고, 자기가 쓴 답을 더 좋게 볼 가능성도 지적되었습니다. 언어 모델을 평가자로 쓰는 방식을 분석한 2023년 연구는 이 세 가지를 순서 치우침, 장황함 치우침, 자기 우대 치우침이라고 불렀습니다(Zheng 외, 2023).

언어 모델을 평가자로 쓰는 방식을 분석한 2023년 연구에서 질문 80개마다 비슷한 답 두 개를 만들어 순서만 바꿔 다시 물었을 때, 같은 판정을 유지한 비율은 GPT-4가 65.0%, GPT-3.5가 46.2%, Claude-v1이 23.8%였고, Claude-v1은 75.0%의 경우에 먼저 놓인 답을 골랐습니다(Zheng 외, 2023). 새 정보 없이 목록을 말만 바꿔 한 번 더 붙인 답 23개를 원래 답보다 낫다고 판정한 비율은 Claude-v1과 GPT-3.5가 91.3%, GPT-4가 8.7%였습니다(Zheng 외, 2023).

자기 우대는 덜 분명했습니다. GPT-4는 자기 답의 승률을 사람보다 10%, Claude-v1은 25% 높게 보았지만 다른 모델의 답도 높게 본 경우가 있었고 GPT-3.5는 자기 답을 우대하지 않아, 연구진은 자료가 적어 자기 우대가 있다고 단정할 수 없다고 적었습니다. 같은 연구는 GPT-4 같은 강한 평가자가 사람의 선호와 80% 넘게 일치해 사람끼리 일치하는 수준에 이르렀다는 결과도 함께 보고했습니다(Zheng 외, 2023).

멀티 에이전트의 오류가 커진다는 것은 어떤 연구로 확인되었나요?

공개된 멀티 에이전트 시스템 7종의 실행 기록을 분석한 연구는 이 시스템들의 실패율이 41%에서 86.7%에 이르렀고, 실패가 모델의 한계만이 아니라 일을 나누고 조율하는 설계에서도 많이 나왔다고 보고했습니다(Cemri 외, 2025).

이 연구는 1,600건이 넘는 실행 기록에 실패 유형을 표시해, 실패를 시스템 설계, 에이전트 사이의 어긋남, 결과 확인의 세 범주와 14가지 유형으로 나눴습니다. 가장 흔한 유형은 같은 단계를 되풀이하는 것(15.7%), 추론과 실제 행동이 어긋나는 것(13.2%), 일이 끝났는지 알아채지 못하는 것(12.4%)이었고, 결과를 잘못 확인하거나(9.1%) 확인하지 않거나 덜 확인하는 것(8.2%)도 있었습니다(Cemri 외, 2025).

앞의 260가지 구성을 비교한 연구는, 단일 에이전트의 성적이 이미 높은 일에서는 에이전트를 더 붙여도 얻는 이득이 줄어든다고 보고했습니다(Kim 외, 2026).

운영 중에 드러난 실패도 있습니다. Anthropic은 초기 조사 시스템에서 단순한 질문에도 하위 에이전트를 50개나 만들거나, 있지도 않은 자료를 찾아 웹을 끝없이 뒤지거나, 에이전트끼리 지나치게 잦은 진행 보고로 서로를 방해하는 일이 있었다고 밝혔습니다. 주 에이전트가 하위 에이전트들이 모두 끝날 때까지 기다리는 글을 쓸 당시의 방식은 조율이 단순한 대신, 실행 도중에 방향을 바꾸거나 하위 에이전트끼리 맞춰 볼 수 없어 병목이 된다고도 적었습니다(Anthropic, 2025년 6월).

AI 에이전트의 기본부터 보려면 무엇을 읽으면 되나요?

에이전트가 일을 시작하는 계기와 맡기기 좋은 일은 "AI 에이전트는 스스로 일을 찾아서 하나요?"에서, AI가 근거 없는 내용을 사실처럼 쓰는 현상은 "할루시네이션이란? AI 환각의 뜻과 원인, 문서 업무에서 나타나는 모양"에서 다룹니다. 다른 질문은 AX 가이드의 에이전트와 하네스에서 찾을 수 있습니다.

언어 모델은 앞에 놓인 글을 보고 이어질 낱말을 고르는 방식으로 글을 쓰는 AI 모델입니다. 그래서 지시문에 적힌 낱말은 뒤에 「하지 마」가 붙어 있어도, 그 낱말과 관련된 글이 이어질 가능성을 높이는 단서가 될 수 있습니다.

2024년 2월 공개된 연구에서 대화 중에 특정 대상을 말하지 말라고 지시하자, 모델의 답 가운데 그 대상을 언급한 답의 비율이 지시가 없을 때의 33~34%에서 OpenHermes-7B는 36%로 오히려 올랐고, OpenHermes-13B는 34%로 그대로였으며, Llama-2-13B-Chat은 25%, GPT-4는 13%로 내려갔습니다(Castricato 외, 2024).

하지 말라고 한 내용이 오히려 답에 나오는 까닭은 무엇인가요?

모델이 「하지 마」라는 부정 표현은 놓치고, 금지한 낱말은 다음 글의 단서로 쓰기 때문입니다. 앞의 연구진은 이 현상을, 무언가를 떠올리지 말라고 하면 오히려 그것을 떠올리게 되는 심리학의 「분홍 코끼리 효과」에 견주어 「분홍 코끼리 문제」라고 불렀습니다(Castricato 외, 2024).

이 시험에서 모델이 금지한 대상을 언급했는지는 GPT-4가 판정했고, 연구진이 일부를 직접 확인한 결과 사람의 판정과 94.5~98.5% 일치했습니다. 연구진은 언급을 피하도록 따로 학습시킨 OpenHermes 모델에서 지시 뒤의 언급 비율을 15~17%로 낮췄는데, 이는 지시문만으로는 잘 고쳐지지 않는 행동을 학습으로 고친 결과입니다(Castricato 외, 2024).

더 작은 예전 모델에서도 같은 경향이 보였습니다. 2020년 학회 ACL에서 발표된 연구는 BERT 같은 사전 학습 언어 모델이 「새는 날 수 [ ]」와 「새는 날 수 없[ ]」처럼 부정 표현만 다른 빈칸 문제를 잘 구별하지 못하고, 「말하다?」처럼 앞에 엉뚱한 낱말 하나를 붙이기만 해도 그 낱말을 따라 엉뚱한 답을 내기 쉽다고 보고했습니다(Kassner·Schütze, 2020). 연구의 원래 예는 영어 문장 「Birds can [MASK]」와 「Birds cannot [MASK]」, 「Talk? Birds can [MASK]」입니다.

하지 말라는 지시를 해야 할 일로 바꿔 쓰면 무엇이 달라지나요?

모델이 단서로 쓰는 낱말이, 원하지 않는 결과를 가리키는 말에서 원하는 결과를 가리키는 말로 바뀝니다. AI 모델 Claude를 만드는 Anthropic의 프롬프트 안내도 「응답에 마크다운을 쓰지 마」 대신 「응답은 자연스럽게 이어지는 산문 문단으로 써」라고 쓰라고 권합니다(Claude 프롬프트 안내). 마크다운은 글에 제목 기호나 목록 기호를 붙여 형식을 꾸미는 표기법입니다.

같은 안내는 지시문의 형식이 응답의 형식에 영향을 줄 수 있다며, 지시문에서 마크다운을 빼면 응답의 마크다운도 줄어들 수 있다고 설명합니다. 또 「말줄임표를 절대 쓰지 마」라고만 쓰기보다 「응답은 음성 합성 프로그램이 소리 내어 읽으므로, 그 프로그램이 읽지 못하는 말줄임표는 쓰지 마」처럼 까닭을 함께 주면 모델이 그 설명에서 일반화할 수 있다고 적었습니다(Claude 프롬프트 안내).

예시로 「껄렁껄렁하게 쓰지 마」는 「단정하게 써」로, 「전문 용어를 쓰지 마」는 「중학생도 아는 낱말로 쓰고, 꼭 필요한 용어는 처음 나올 때 한 문장으로 풀어 써」로 바꿀 수 있습니다. 피하고 싶은 모습을 꼭 설명해야 한다면, 금지한 낱말만 적기보다 그와 반대되는 모습을 함께 적어야 모델이 따를 단서가 분명해집니다.

AI는 왜 「아니다」와 「다르다」라는 말을 특히 어려워하나요?

「아니다」는 문장의 뜻을 뒤집는 부정이라 낱말 하나를 놓치면 정반대로 읽히고, 「다르다」는 무엇과 다른지를 말해야 하는데, 그 기준이 되는 낱말이 다시 단서가 될 수 있기 때문입니다.

부정을 다루는 일은 모델이 커진다고 저절로 나아지지 않았습니다. 2022년 연구는 1억 2,500만~1,750억 개의 매개변수를 가진 OPT와 GPT-3 모델을 원래 지시와 그 지시를 부정으로 바꾼 지시로 각각 시험했는데, 부정한 지시에서는 모델이 클수록 성적이 오히려 떨어지는 역전 현상이 나타났다고 보고했습니다. 지시를 따르도록 더 학습시킨 InstructGPT를 포함해 시험한 모델들의 평균 성적은 원래 지시와 부정한 지시 모두에서 사람보다 크게 낮았습니다(Jang 외, 2022). 매개변수는 모델 안에서 학습으로 정해지는 숫자이고, 그 수가 클수록 대개 큰 모델입니다.

「다르다」를 직접 잰 연구는 찾지 못했지만, 앞의 연구들에서 본 것처럼 지시에 나온 낱말은 다음 글의 단서가 되기 쉽습니다. 예시로 「A사의 광고와 다른 문구를 써 줘」라고 하면, 새 문구에 A사 광고의 낱말과 분위기가 섞여 나올 수 있습니다. 다른 문구를 원할 때도 새 문구가 어떤 모습이어야 하는지를 적어 주어야, 모델이 기준으로 든 광고를 덜 따라 씁니다.

이미지 생성 도구의 네거티브 프롬프트 칸은 대화형 AI에게 주는 지시와 무엇이 다른가요?

이미지 생성 도구의 네거티브 프롬프트 칸은 문장으로 읽히는 지시가 아니라, 생성 과정에서 결과를 그 내용에서 멀어지게 하는 기준으로 따로 계산되는 입력입니다. 그래서 본 프롬프트에 「코끼리 없이」라고 쓰는 것과 네거티브 프롬프트 칸에 「코끼리」를 넣는 것은 다르게 작동합니다.

이미지 생성 모델 Stable Diffusion을 실행하는 공개 라이브러리 diffusers의 문서는 이 칸을 이미지에 넣지 않을 것을 이끄는 프롬프트로 설명하고, 안내 강도(guidance scale)를 1보다 크게 두어 이 안내 방식을 쓸 때만 효과가 있다고 적습니다(Hugging Face diffusers 문서). 이 안내 방식은 프롬프트를 넣고 계산한 결과와 넣지 않고 계산한 결과의 차이로 생성 방향을 정하는 「분류기 없는 안내」에 바탕을 둡니다(Ho·Salimans, 2022).

언어 모델과 대화하는 창에는 이런 별도의 칸이 없으므로, 대화형 AI에게 무언가를 피하게 하려면 앞의 방법처럼 할 것을 적는 편이 낫습니다.

AI가 지시를 따르지 않는 다른 까닭은 무엇인가요?

지시가 긴 입력의 가운데에 묻히면 모델이 그 지시를 덜 반영하는 것도 한 가지 까닭입니다. 이 현상은 "컨텍스트 윈도우란? AI가 긴 대화와 긴 문서에서 놓치는 것"에서 다룹니다.

모델이 읽을 정보를 고르는 일은 "컨텍스트 엔지니어링이란? 뜻과 프롬프트 엔지니어링과의 차이"에서 다룹니다. 다른 질문은 AX 가이드의 AI가 틀리는 이유에서 찾을 수 있습니다.

여기서 데이터셋은 표 형태로 모아 둔 자료이고, 오브젝트는 직원이나 항공편처럼 실제 대상이나 사건 하나를 나타내는 데이터입니다. 속성은 그 대상의 특징을, 링크는 두 오브젝트 사이의 관계를 나타냅니다. 액션은 오브젝트를 바꾸는 정해진 절차이고, 함수는 코드로 적은 업무 로직입니다. OWL은 웹 표준을 만드는 단체 W3C가 정한 온톨로지 언어이며, 추론기는 적어 둔 규칙과 사실에서 논리적으로 따라 나오는 사실을 계산하는 프로그램입니다.

팔란티어(Palantir Technologies)는 데이터 운영 플랫폼 Foundry와 AI 플랫폼 AIP를 만드는 회사이고, 이 온톨로지는 Foundry를 이루는 중심 요소입니다(Palantir AIP 개요; 플랫폼 개요). 팔란티어 AIP는 AIP Logic 같은 개발 도구로, AI를 쓰는 업무 흐름과 에이전트(언어 모델에 도구와 규칙을 묶어 여러 단계의 일을 이어 처리하는 AI 프로그램), 함수를 이 온톨로지 위에서 만들 수 있게 합니다(Palantir AIP 개요).

팔란티어 온톨로지는 무엇으로 이루어지나요?

팔란티어 온톨로지는 오브젝트, 속성, 링크라는 의미 요소(semantic)와 액션, 함수, 동적 보안이라는 동작 요소(kinetic)로 이루어집니다. 의미 요소는 데이터가 현실의 무엇을 가리키는지 정하고, 동작 요소는 그 데이터를 누가 어떤 절차로 바꿀 수 있는지 정합니다(Palantir 온톨로지 개요).

오브젝트 유형은 실제 대상이나 사건을 정의한 틀이고, 오브젝트는 그 틀에 따른 사례 하나입니다. 팔란티어 문서는 이 구성을 데이터셋의 구조에 견주어, 오브젝트 유형은 데이터셋에, 오브젝트 하나는 행 하나에, 속성은 열에, 속성 값은 칸에 든 값에, 링크 유형은 두 데이터셋을 같은 값으로 이어 붙이는 조인에 해당한다고 설명합니다(Palantir 핵심 개념).

문서의 예에서 항공편 오브젝트 유형은 출발일, 도착일, 승객 수를 속성으로 두고, JFK 공항에서 SFO 공항으로 가는 항공편 하나가 출발일 2021년 2월 24일, 도착일 2월 25일, 승객 수 150명이라는 속성 값을 가진 오브젝트가 됩니다. 이 항공편과 배정된 항공기 「Boeing 737-123」을 잇는 관계 하나는 링크입니다(Palantir 속성; 링크 유형).

온톨로지 개요 문서는 동적 보안을 따로 풀이하지 않지만, 온톨로지 시스템 문서는 사용자와 에이전트마다 볼 수 있는 데이터의 행과 열, 그리고 구매 주문을 내는 일처럼 실행할 수 있는 동작을 세밀한 권한으로 나눈다고 설명합니다(Palantir 온톨로지 시스템).

팔란티어 온톨로지는 OWL로 적는 전통적인 온톨로지와 무엇이 다른가요?

OWL 온톨로지는 개념의 뜻을 논리로 적어 두고 추론기가 거기서 새 사실을 끌어내게 하는 문서이고, 팔란티어 온톨로지는 실제 데이터셋에 연결되어 액션으로 그 데이터를 바꾸는 시스템이라는 점이 다릅니다.

OWL 2는 W3C가 2009년 10월 27일 권고안(W3C가 표준으로 확정한 문서)으로 발표하고 2012년 12월 11일 제2판을 낸 언어입니다. 이 언어는 문장의 뜻이 수학적으로 엄밀하게 정의되어 있고, 클래스(개념의 종류), 속성, 개체(인스턴스라고도 부르는 개별 대상), 데이터 값으로 온톨로지를 적게 하며, 이렇게 적은 온톨로지는 주로 RDF(사실 하나를 주어, 술어, 목적어로 적는 형식) 문서로 주고받습니다(W3C OWL 2 개요, 2012). 그래서 OWL 문서 하나에는 개념의 틀과 그 틀을 채운 개별 사실이 함께 담길 수 있는데, "온톨로지란? 뜻과 구성 요소, 데이터베이스와의 차이"에서는 틀만 온톨로지라고 부르고 틀을 채운 사실은 지식 그래프로 나눠 설명합니다.

OWL 2 입문서에 따르면 OWL은 프로그래밍 언어가 아니라 상황을 논리적으로 기술하는 선언형 언어(처리 절차 대신 성립하는 사실을 적는 언어)이고, 추론기가 그 기술에서 더 많은 정보를 끌어냅니다. 예시로 「가동률이 90% 이상인 생산 라인은 효율적인 라인이다」라는 규칙과 「라인 A는 생산 라인이고, 가동률은 93%다」라는 사실을 적어 두면, 추론기는 적혀 있지 않던 「라인 A는 효율적인 라인이다」를 끌어냅니다. 추론기가 내놓는 이런 결론은 형식 의미론(문장이 언제 참인지 수학적으로 정한 규칙)으로 미리 정해지며, 입문서는 그 의미론을 따르는 구현만 OWL 2에 맞는다고 봅니다(W3C OWL 2 입문서, 2012).

팔란티어 문서는 반대로 Foundry 온톨로지가 추상적인 데이터 모델이 아니라 각 개념을 조직의 실제 데이터에 대응시킨다고 밝히고(Palantir 액션 유형 개요), 온톨로지는 「의미 레이어(semantic layer)」가 아니며, 데이터와 로직, 액션, 보안을 함께 묶어 운영하는 일은 얇은 의미 레이어로는 할 수 없다고도 적습니다(Palantir 온톨로지 시스템). 의미 레이어는 회사 데이터를 흔히 쓰는 업무 용어로 나타내, 사용자가 스스로 데이터를 찾아 쓰게 돕는 층을 말합니다(위키백과 「Semantic layer」).

문서가 안내하는 대로 앞의 생산 라인 규칙 같은 업무 규칙을 데이터 파이프라인(자료를 정해진 순서로 가공하는 흐름)의 규칙이나, TypeScript·Python 코드로 쓴 함수로 적으면, 판정은 추론기가 아니라 그 코드가 내립니다(Palantir 플랫폼 개요; 함수 개요).

대상을 구별하는 방식도 달라서, OWL은 이름이 달라도 같은 대상일 수 있다고 보지만 팔란티어는 오브젝트마다 겹치지 않는 고유한 값 하나로 대상을 가립니다. 그래서 OWL에서는 두 이름이 서로 다른 개체임을 분명히 하려면 differentFrom(다름) 같은 문장으로 따로 적어야 하고, 같은 개체라는 것은 sameAs(같음)로 적을 수 있습니다. 입문서는 OWL의 이런 방식이 여러 기관이 서로 모르는 채 같은 대상에 다른 이름을 붙이는 웹에 맞는다고 설명합니다(W3C OWL 2 입문서, 2012).

OWL 2에도 키(HasKey)가 있어서, 클래스에 키 속성을 정해 두면 추론기는 그 클래스에서 키 값이 같은 두 개체를 같은 개체로 봅니다(W3C OWL 2 구조 명세, 2012). 반면 팔란티어에서는 모든 오브젝트 유형에 기본 키(오브젝트 하나를 가리키는 고유한 값)가 반드시 있어야 하며, Object Storage v2라는 저장소에서는 데이터셋에 같은 기본 키 값이 두 번 이상 나오면 데이터 반영 작업이 실패합니다(Palantir 오브젝트 유형 만들기).

정리하면 OWL 온톨로지는 개념의 뜻을 표준 언어 OWL로 적어 공유와 추론에 쓰는 문서이고, 팔란티어 온톨로지는 실제 데이터와 업무 동작을 한 플랫폼 안에서 묶는 체계입니다. 두 가지를 나란히 놓으면 다음과 같습니다.

팔란티어 온톨로지가 「행동」까지 담는다는 것은 무슨 뜻인가요?

팔란티어 온톨로지에서 행동은 액션 유형을 말하며, 오브젝트와 속성 값, 링크를 한 번에 바꾸는 방법과 그때 함께 일어날 알림 같은 부수 동작을 정해 둔 것입니다(Palantir 핵심 개념). 온톨로지가 데이터를 읽는 틀에 그치지 않고, 데이터를 고치는 절차까지 맡는다는 뜻입니다.

문서의 예에서 「직원 배정」 액션은 직원 오브젝트의 직무 속성을 바꾸는 방법과, 새 관리자 오브젝트와의 링크를 자동으로 만드는 규칙을 정합니다. 여기에 이전 관리자와 새 관리자에게 변경을 알리는 부수 동작을 붙이고, 인사 담당자처럼 권한이 있는 직원만 실행하게 할 수 있습니다. 문서는 액션을 사용자가 정한 로직에 따라 하나 이상의 오브젝트를 바꾸는 단일 트랜잭션(한꺼번에 반영되거나 한꺼번에 취소되는 변경 단위)이라고 설명합니다(Palantir 액션 유형 개요).

액션에는 제출 조건(사용자가 액션을 실행해 변경을 반영하려면 맞아야 하는 조건)도 붙일 수 있습니다. 문서의 항공사 예에서는 항공편에 배정된 항공기를 바꾸는 액션을, 지정된 그룹에 속한 사용자가 아직 운항 중인 항공기를 고를 때만 제출할 수 있게 합니다(Palantir 제출 조건).

액션으로 바꾼 내용은 모든 사용자 애플리케이션에 반영됩니다(Palantir 액션 유형 개요). 액션에 웹훅(다른 시스템에 요청을 보내는 장치)을 붙이면 Salesforce나 SAP 같은 외부 시스템의 데이터도 바꿀 수 있습니다. 웹훅을 writeback 방식으로 설정하면 다른 변경보다 먼저 외부 요청을 보내고 그 요청이 실패하면 온톨로지도 바꾸지 않으며, 부수 동작 방식으로 설정하면 온톨로지를 먼저 바꾼 뒤에 요청을 보냅니다(Palantir 웹훅).

팔란티어 문서는 결정의 결과를 온톨로지에 남기면 조직이 그 결정에서 배우고 개선할 수 있다고 설명합니다(Palantir, 온톨로지를 만드는 이유). 플랫폼 개요도 모든 결정을 데이터, 로직, 액션으로 나눌 수 있다고 보고, 액션을 기업의 「동사」라고 부릅니다(Palantir 플랫폼 개요).

형태가 다른 자료는 팔란티어 온톨로지에서 어떻게 한 틀에 담기나요?

팔란티어 온톨로지는 들어오는 주기와 형식이 다른 자료도 같은 틀의 오브젝트와 속성, 링크로 옮겨 담습니다. 문서에 따르면 온톨로지는 데이터셋과 스트리밍 데이터(끊임없이 이어서 들어오는 자료)를 모두 오브젝트의 원천으로 읽고, 원천이 바뀌면 오브젝트도 최신 상태로 맞춥니다(Palantir 온톨로지 아키텍처).

예시로 한 도시의 교통 상황을 다루는 온톨로지라면, 들어오는 주기도 믿을 만한 정도도 다른 자료를 도로 구간과 역, 제보라는 세 오브젝트 유형에 나눠 담을 수 있습니다. 몇 초마다 바뀌는 도로의 통행 속도는 도로 구간의 시계열 속성(시간에 따라 잰 값을 차례로 담는 속성)으로 담고, 팔란티어의 시계열 속성은 데이터셋이나 스트리밍 데이터에서 값을 받을 수 있습니다(Palantir 시계열). 몇 분마다 들어오는 지하철 운행 정보는 같은 주기로 다시 만드는 데이터셋에서 값을 받는 역 오브젝트의 속성으로 담습니다. 맞을 확률이 20% 정도로 평가된 사고 제보는 「확률 0.2」라는 속성 값을 가진 제보 오브젝트로 만들고, 제보가 가리키는 역이나 도로 구간과 링크로 잇습니다.

이 예에서 온톨로지는 자료의 형식을 하나로 바꾸지 않고, 서로 다른 자료가 같은 도로와 역을 가리키게 이어 줍니다. 담당자가 현장을 확인한 뒤 「제보 확인」 액션으로 제보의 상태를 바꾸면, 그 판단도 제보 오브젝트에 남습니다.

팔란티어 AIP는 온톨로지와 어떤 관계인가요?

팔란티어 AIP의 AI 기능은 온톨로지 위에서 만들어지고, AI 에이전트가 다룰 수 있는 데이터와 도구는 온톨로지의 액션에 붙은 세밀한 권한이 제한합니다(Palantir AIP 개요; 플랫폼 개요).

AIP의 도구 가운데 AIP Logic은 LLM(대규모 언어 모델) 기반 함수를 코드 없이 만들고 시험하고 배포하는 환경입니다. 이 함수는 온톨로지 오브젝트나 글을 입력으로 받아 결과를 돌려주거나 온톨로지를 편집할 수 있고, 함수를 자동으로 실행되게 하면 그 편집을 바로 적용하거나 사람이 검토하도록 대기시킬 수 있습니다(Palantir AIP Logic 개요).

플랫폼 개요는 대부분의 사용 방식에서 AI 에이전트가 데이터를 직접 바꾸지 않고 제안을 만들며, 담당자가 그 제안을 다듬고 의견을 붙여 결정할 수 있다고 설명합니다(Palantir 플랫폼 개요).

국내 기업은 팔란티어 플랫폼을 어디에 도입했나요?

공개 기사로 확인한 국내 사례로는 현대중공업그룹의 조선 해양 부문(2022년 Foundry 도입 계약)과 포스코퓨처엠의 영업·마케팅 부문(2026년 Foundry·AIP 도입 계약)이 있습니다. 기사들은 온톨로지를 따로 언급하지 않았지만, 두 제품은 온톨로지를 중심으로 짜인 플랫폼입니다(Palantir 플랫폼 개요).

현대중공업그룹은 2022년 9월 21일, Foundry를 조선 해양 부문 전 계열사에 도입하는 본 계약을 맺었다고 밝혔습니다. 회사는 Foundry로 2030년까지 스마트 조선소로 전환하는 FOS(Future of Shipyard) 프로젝트에 속도를 내겠다고 했고, 기사는 이 프로젝트의 목표가 설계부터 생산까지 전 공정에 디지털 트윈(현실의 설비와 공정을 데이터로 옮겨 둔 모형)을 구현하는 것이라고 전했습니다(머니투데이방송, 2022).

포스코퓨처엠은 2026년 10월 21일 계약을 맺었고, 먼저 영업·마케팅 부문에 적용하고 성과를 검증한 뒤 적용 범위를 단계적으로 넓히는 방안을 검토하겠다고 밝혔습니다(더트래커, 2026). 두 기사는 계약과 계획을 전한 것이며, 도입한 뒤의 효과를 잰 자료는 아닙니다.

온톨로지의 뜻부터 보려면 무엇을 읽으면 되나요?

온톨로지라는 말의 뜻과 유래, 지식 그래프와의 차이는 "온톨로지란? 뜻과 구성 요소, 데이터베이스와의 차이"에 정리했습니다. 온톨로지를 만드는 순서는 "온톨로지 구축 방법: 기술 문서와 실험 기록을 지식으로 바꾸는 5단계"에서 다루고, 다른 질문은 AX 가이드에서 찾을 수 있습니다.

이 글은 컨텍스트 윈도우(context window)를 재는 단위인 토큰, 대화가 길어질 때 앞의 내용이 사라지는 이유, 긴 입력의 가운데를 놓치는 현상, 지난 대화를 요약해 줄이는 압축이 잃는 것을 차례로 설명합니다. 그리고 할루시네이션(AI가 쓴 답이 실제 사실이나 사용자가 건넨 지시와 자료에 맞지 않는 현상) 가운데 모를 때 추측한 내용을 사실처럼 쓰는 경우처럼, 윈도우로는 설명되지 않는 실수를 따로 나눠 봅니다.

토큰은 무엇이고 컨텍스트 윈도우와 어떤 관계인가요?

토큰은 AI 모델이 글을 잘게 나눠 읽고 쓰는 단위이고, 컨텍스트 윈도우의 크기는 이 토큰의 개수로 정해집니다. 같은 글이 몇 토큰이 되는지는 언어와 모델마다 달라서, 크기가 같은 윈도우라도 담기는 글의 양이 다릅니다.

토큰 하나는 낱말 하나일 수도 있고, 낱말의 일부나 글자 하나일 수도 있습니다. 글을 토큰으로 자르는 규칙을 토크나이저라고 하는데, Anthropic은 Claude 4.7 이후 모델의 새 토크나이저가 같은 글을 이전 모델보다 약 30% 많은 토큰으로 나눈다고 밝혔습니다(Claude 문서). Google은 Gemini 모델에서 100토큰이 영어 낱말 60~80개쯤이라고 안내합니다(Google 문서).

영어를 중심으로 만든 토크나이저에서는 같은 내용이라도 한국어가 토큰을 더 많이 씁니다. 위키백과 문장 2,000개를 200개 언어로 옮긴 자료로 잰 2023년 연구에서, 당시 ChatGPT와 GPT-4가 쓰던 토크나이저는 한국어 문장에 같은 뜻의 영어 문장보다 2.38배 많은 토큰을 썼습니다. 연구진은 이런 차이가 서비스 비용과 처리 시간, 모델에게 건넬 수 있는 글의 양에도 영향을 준다고 지적했습니다(Petrov 외, 2023).

윈도우를 차지하는 것은 질문만이 아닙니다. 시스템 프롬프트(대화 전에 모델에게 주는 지시문)와 지난 대화, 첨부한 이미지와 문서, 도구(모델이 불러 쓰는 검색이나 계산 같은 기능)의 정의와 결과, 그리고 모델이 그 차례에 쓰는 출력까지 모두 윈도우에 들어갑니다(Claude 문서). 이미지도 토큰으로 세어서, Google은 가로와 세로가 모두 384픽셀 이하인 이미지 한 장을 258토큰으로 셉니다(Google 문서).

대화가 길어지면 AI가 앞의 내용을 잊는 이유는 무엇인가요?

모델이 기억을 잃어서가 아니라, 윈도우 한도에 가까워지면 모델을 부르는 대화 프로그램이 오래된 대화를 빼거나 요약해서 보내기 때문입니다. 윈도우 안에 남은 대화도 길어질수록 모델이 덜 정확하게 활용하는데, 이 현상은 다음 소제목에서 다룹니다. 모델은 요청마다 받은 글만 보고, 지난 대화를 모아 다시 보내는 일은 대화 프로그램이 맡습니다.

Anthropic의 API(프로그램이 모델을 부르는 창구) 문서는 API가 앞선 요청을 기억하지 않으므로 대화 기록 전체를 매번 보내야 한다고 설명합니다(Claude 문서). OpenAI의 문서도 요청 하나하나가 서로 독립적이며 상태를 저장하지 않는다고 적고, 대화를 이어 가려면 지난 메시지를 함께 보내거나 API가 대화 상태를 대신 저장해 두는 기능을 쓰도록 안내합니다(OpenAI 문서). 이렇게 모델을 감싸서 부르고 대화 기록과 도구를 관리하는 프로그램을 하네스라고 하며, 자세한 뜻은 "하네스 엔지니어링이란? 뜻과 설계 대상, 대표적인 실패"에서 다룹니다.

윈도우가 차면 무엇을 남길지는 하네스가 정합니다. Claude의 컨텍스트 윈도우 문서에 따르면 API는 입력만으로 윈도우를 넘는 요청을 처리하지 않고 오류를 돌려주며, claude.ai 같은 채팅 화면은 먼저 들어온 대화부터 내보내는 방식으로 윈도우를 관리할 수도 있습니다. 오래된 대화를 버리는 대신 요약으로 바꿔 넣는 압축 기능도 있습니다(Claude 문서). 어느 쪽이든 모델이 다음 답을 쓸 때 보는 것은 하네스가 남긴 글뿐입니다.

긴 문서의 가운데를 놓친다는 「Lost in the Middle」은 사실인가요?

네, 조건을 통제한 실험에서 확인된 현상입니다. 필요한 정보가 입력의 맨 앞이나 맨 끝에 있을 때 정답률이 가장 높고 가운데로 갈수록 떨어져서, 자리별 정답률을 이으면 U자 모양이 됩니다(Liu 외, 2024).

문서 20개(약 4천 토큰)를 넣었을 때 GPT-3.5-Turbo의 정답률은 정답이 든 문서가 1번째이면 75.8%, 10번째이면 53.8%, 20번째이면 63.2%였습니다(Liu 외, 2024). 스탠퍼드 대학 등의 연구진은 질문 하나와 위키백과에서 뽑은 짧은 문서 여러 개를 함께 주고, 정답이 든 문서 하나의 자리만 바꿔 가며 정답률을 쟀습니다. 2023년에 공개되어 2024년 학술지 TACL에 실린 이 논문의 제목은 「Lost in the Middle: How Language Models Use Long Contexts」입니다.

윈도우가 큰 모델이 이 현상을 피한 것도 아닙니다. 입력이 두 윈도우에 모두 들어갈 때, 윈도우가 4천 토큰인 GPT-3.5-Turbo와 1만 6천 토큰인 GPT-3.5-Turbo(16K)는 자리별 정답률이 거의 겹쳤습니다. 검색해 넣은 문서를 20개에서 50개로 늘려도 정답률은 GPT-3.5-Turbo가 약 1.5%, Claude-1.3이 약 1% 오르는 데 그쳤습니다(Liu 외, 2024). 관련 자료를 찾아 질문과 함께 넣는 방식인 RAG에서도 근거를 많이 넣는다고 답이 꼭 좋아지지는 않는 이유입니다.

연구진은 모델의 구조, 질문을 문서 앞뒤에 함께 두는 방식, 지시를 따르도록 하는 추가 학습이 원인인지 예비 조사로 살폈습니다. 이 추가 학습을 거치기 전의 기본 모델도 U자 모양을 보였고, 연구진은 이 모양을 사람이 목록의 처음과 끝 항목을 가장 잘 기억하는 심리학의 계열 위치 효과에 견주었습니다(Liu 외, 2024). 실험한 모델은 2023년 모델이지만, 2026년 10월 31일에 확인한 Claude 문서도 토큰이 늘수록 정확도와 재현율(넣어 둔 정보를 찾아내는 정도)이 떨어지는 현상을 컨텍스트 부패(context rot)라고 부르며, 윈도우에 글을 많이 넣는다고 자동으로 더 좋아지는 것은 아니라고 적습니다(Claude 문서).

컨텍스트 압축은 대화가 길어질 때 무엇을 잃나요?

압축은 오래된 대화를 요약 한 덩어리로 바꾸므로, 요약에 들지 못한 세부는 그 뒤의 대화에서 모델이 다시 볼 수 없습니다. Anthropic은 압축을 지나치게 하면 중요성이 나중에야 드러나는 미묘하지만 중요한 맥락을 잃을 수 있다고 설명합니다(Anthropic, 2025).

컨텍스트 압축(compaction)은 대화가 윈도우 한도에 가까워졌을 때 지난 대화를 요약하고, 그 요약으로 새 윈도우를 시작하는 일입니다(Anthropic, 2025). 모델이 알아서 하는 일이 아니라 하네스나 API가 모델에게 요약을 요청하고 그 요약으로 지난 대화를 대신하는 기능이며, Claude API에도 오래된 턴(사용자와 모델이 한 번씩 주고받는 차례)을 서버에서 쓴 요약으로 바꾸는 베타 기능이 있습니다. Claude의 압축 문서는 최근 몇 턴을 원문 그대로 남기는 방식과, 기본 요약이 뒤에 필요한 내용을 빠뜨릴 때 요약 지시문을 직접 쓰는 방식도 안내합니다(Claude 문서).

무엇이 남을지는 요약의 기준이 정합니다. Anthropic의 코딩 에이전트(코드를 대신 쓰고 고치는 AI 프로그램)는 압축할 때 설계 결정과 해결하지 못한 버그, 구현의 세부는 남기고 중복된 도구 출력과 메시지는 버립니다(Anthropic, 2025).

이 손실은 책을 요약하며 긋는 밑줄에 빗대어 볼 수 있습니다. 요약하는 모델이 책 전체를 꿰뚫는 문장이라서 긋는 밑줄과 설명이 마음에 들어서 긋는 밑줄을 같은 무게로 다루면, 요약에는 무엇을 다뤘는지만 남고 왜, 어떻게, 무엇이 달랐는지는 빠질 수 있습니다. 이 비유는 압축 기능이 실제로 무엇을 고르는지 잰 결과가 아닙니다.

컨텍스트 윈도우로 설명되지 않는 AI의 실수는 무엇인가요?

할루시네이션 가운데 모를 때 추측한 내용을 사실처럼 쓰는 경우와, 학습이 끝난 뒤에 생긴 사실을 모르는 문제는 윈도우의 크기나 자리로 설명되지 않습니다. 두 실수의 원인은 윈도우 밖, 곧 모델을 학습시키고 평가하는 방식과 학습 자료가 끝나는 시점에 있습니다.

2025년 9월에 공개된 연구는 사전 학습(대량의 글로 다음 낱말을 예측하게 하는 첫 학습)을 거친 모델의 할루시네이션이 참과 거짓을 가르는 분류의 오류에서 생기고, 학습과 평가가 모른다고 답하기보다 추측하는 쪽에 점수를 주기 때문에 사라지지 않는다고 분석했습니다(Kalai 외, 2025). 원인과 문서 업무에서 나타나는 모양은 "할루시네이션이란? AI 환각의 뜻과 원인, 문서 업무에서 나타나는 모양"에서 다룹니다.

모델이 아는 사실에도 끝이 있습니다. Anthropic은 모델마다 지식이 가장 넓고 믿을 만한 마지막 시점과 학습에 쓴 자료의 범위를 따로 적어 둡니다(Claude 문서). 그 뒤의 사실은 질문과 함께 윈도우에 넣어 줘야 모델이 쓸 수 있으며, 관련 자료를 찾아 함께 넣는 RAG가 이 일을 합니다.

윈도우에 들어가기 전에 생기는 실수도 있습니다. 아모프 창업팀이 2026년 9월 24일 논문 한 편을 PDF와 학술지 XML(논문의 제목, 절, 표를 구조째 담는 파일 형식)로 각각 읽었을 때, PDF에서는 표의 한 줄이 숫자만 이어진 글 조각이 되고 열의 머리글은 다른 조각으로 떨어졌지만 XML에서는 표 11개가 행과 열 그대로 남았습니다(논문 PDF의 표와 AI). 구조가 풀린 채 들어간 표는 윈도우를 넓혀도 원래의 행과 열로 돌아오지 않습니다.

정리하면 대화와 입력이 길어서 생기는 실수는 윈도우로 설명되지만, 학습과 평가 방식이나 학습 자료가 끝나는 시점, 구조가 풀린 표에서 생기는 실수는 윈도우로 설명되지 않습니다. 여섯 가지를 나란히 놓으면 다음과 같습니다.

입력 토큰과 출력 토큰의 값은 왜 다르게 매기나요?

가격표가 이유를 밝히지는 않지만, 출력 토큰은 모델이 하나씩 차례로 만들어야 해서, 한꺼번에 계산하는 입력 토큰보다 시간이 오래 걸리고 계산 장치(GPU)도 효율적으로 쓰지 못합니다(Kwon 외, 2023). 2026년 10월 31일 Anthropic의 가격표에서는 실린 모든 Claude 모델의 출력 단가가 입력 단가의 5배였습니다(Claude 가격표).

입력은 모든 토큰이 미리 주어져 있어 한꺼번에 계산하지만, 출력은 앞서 만든 토큰에 기대어 다음 토큰을 만들므로 여러 단계를 동시에 계산할 수 없고 요청 하나에 걸리는 시간의 대부분을 차지합니다(Kwon 외, 2023). OpenAI의 지연 시간 안내서도 출력 토큰을 절반으로 줄이면 지연 시간이 절반쯤 줄어들 수 있지만, 아주 긴 문서나 이미지를 넣는 경우가 아니라면 입력을 절반으로 줄여도 지연 시간은 1~5%쯤 줄어드는 데 그칠 수 있다고 설명합니다(OpenAI 문서).

다른 회사의 가격표도 출력이 비쌌습니다. 같은 날 백만 토큰당 가격으로 Google의 Gemini 2.5 Pro는 입력이 20만 토큰 이하일 때 입력 1.25달러, 출력 10달러로 8배였고, OpenAI의 gpt-5.6-terra는 입력이 27만 2천 토큰 이하일 때 표준 요금이 입력 2달러, 출력 12달러로 6배였습니다(Google 가격표, OpenAI 가격표). 답을 내기 전에 모델이 생각하며 만드는 토큰도 출력 토큰으로 청구됩니다(Claude 문서).

윈도우와 비용은 함께 움직입니다. API가 앞선 요청을 기억하지 않으므로 대화가 길어질수록 매 요청에 지난 대화가 다시 입력 토큰으로 들어가 청구됩니다. 자주 되풀이되는 앞부분을 저장해 두고 싸게 다시 읽는 프롬프트 캐싱은 그 토큰의 값을 낮출 뿐, 윈도우에서 차지하는 자리는 줄이지 않습니다(Claude 문서).

모를 때 답하지 않게 하면 틀린 답을 줄일 수 있지만(Kalai 외, 2025), 틀린 답이 모두 사라지지는 않으므로 틀렸을 때 사람이 알아챌 수 있게 하는 장치도 함께 필요합니다. 이 글은 원인과 종류에 이어, 출처를 붙인 답과 긴 대화, 그리고 규격서나 논문처럼 조건과 수치를 적은 기술 문서에서 이 현상이 나타나는 모양과 확인할 것을 정리합니다.

할루시네이션은 왜 생기나요?

할루시네이션은 AI가 많은 글을 읽으며 다음 낱말을 예측하도록 먼저 학습하는 단계(사전 학습)에서 규칙 없이 드물게 나오는 사실을 정확히 익히지 못하고, 그 뒤에는 맞힌 수만 세는 평가에서 점수를 잘 받도록 다듬어지면서 모를 때 추측하는 경향이 남기 때문에 생깁니다(Kalai 외, 2025). 앞에서 소개한 OpenAI 논문이 든 두 원인입니다.

언어 모델은 글을 읽고 쓰도록 학습한 AI 모델로, ChatGPT 같은 서비스의 바탕입니다. 사전 학습은 글에서 다음 낱말이 나올 확률을 학습 자료에 맞추는 것을 목표로 하는데, 논문은 학습 자료에 오류가 하나도 없어도 이 목표 때문에 틀린 답이 생긴다고 설명합니다. 맞춤법처럼 규칙이 일정한 것은 모델이 정확하게 익히지만, 어떤 사람의 생일처럼 규칙이 없는 사실은 글의 모양만으로 짐작할 수 없기 때문입니다(Kalai 외, 2025).

논문이 든 예에 따르면, 학습 자료에 딱 한 번만 나오는 생일 사실이 전체의 20%일 때 사전 학습만 마친 모델은 생일 사실의 적어도 20%에서 할루시네이션을 일으킬 것으로 예상됩니다(Kalai 외, 2025). 기술 문서에 한 번만 적힌 제품별 시험값도 규칙으로 짐작할 수 없는 사실이므로, 모델이 기억에 기대어 답하면 같은 문제가 생길 수 있습니다.

두 번째 원인은 평가의 채점 방식입니다. 평가는 여러 모델에게 같은 문제를 풀게 해 점수로 견주는 시험인데, 논문이 살펴본 널리 쓰이는 평가는 대부분 맞으면 1점을 주고 틀리거나 "모르겠다"고 하면 똑같이 0점을 줍니다. 이런 채점에서는 모르겠다고 답하는 쪽이 언제나 손해이므로, 모델은 객관식 시험에서 모르는 문제를 찍는 학생처럼 추측하게 됩니다(Kalai 외, 2025).

OpenAI의 GPT-5 시스템 카드(2025년 8월)에 실린 SimpleQA 결과에서, 웹 검색 없이 답한 gpt-5-thinking-mini는 정답 22%, 오답 26%였고 OpenAI o4-mini는 정답 24%, 오답 75%였습니다(OpenAI, 2025). SimpleQA는 답을 정답, 오답, 답하지 않음의 셋으로 채점하므로(Wei 외, 2024), 나머지인 52%와 1%가 답하지 않은 비율입니다. 정답률만 보면 o4-mini가 2%포인트 앞서지만, 틀린 답은 세 배 가까이 많았습니다.

그래서 논문은 할루시네이션만 재는 평가를 늘리기보다, 널리 쓰는 평가의 채점을 바꿔 틀린 답에 감점을 주고 그 기준을 지시문에 밝히자고 제안합니다. 예를 들어 "90%보다 더 확신할 때만 답하라. 맞으면 1점, 틀리면 9점 감점, 모르겠다고 하면 0점이다"라고 밝혀 두면, 확신이 낮을 때 답하지 않는 모델이 손해를 보지 않습니다(Kalai 외, 2025).

할루시네이션에는 어떤 종류가 있나요?

할루시네이션은 답이 실제 세계의 사실과 어긋나는 사실성(factuality) 할루시네이션과, 사용자가 준 지시나 자료와 어긋나거나 답 안에서 앞뒤가 맞지 않는 충실성(faithfulness) 할루시네이션의 두 가지로 나뉩니다(Huang 외, 2023). 대형 언어 모델(LLM)의 할루시네이션을 다룬 여러 연구를 모아 정리한 개관 논문이 쓰는 분류입니다.

충실성 할루시네이션은 지시한 일과 다른 일을 하는 경우, 건넨 문서나 글과 다른 내용을 쓰는 경우, 답 안에서 앞뒤 논리가 맞지 않는 경우의 세 가지로 다시 나뉩니다(Huang 외, 2023). 문서를 건네고 묻는 업무에서는 둘째 경우가 가장 직접적인 문제이며, 건넨 문서에 없는 값이 섞이면 문서를 근거로 답하게 한 목적이 사라집니다.

할루시네이션이라는 말은 어디에서 왔나요?

할루시네이션이라는 말은 영상을 다루는 컴퓨터 비전 분야에서 먼저 쓰였고, 처음에는 오류가 아니라 2000년 Baker와 Kanade의 연구처럼 해상도가 낮은 얼굴 영상을 고해상도로 바꾸는 기술을 가리켰습니다. 글을 만드는 AI에서는 원문과 맞지 않거나 뜻이 통하지 않는 글을 만드는 오류를 가리키게 되었습니다(Ji 외, 2022).

출처를 붙인 AI 답에도 할루시네이션이 생기나요?

생깁니다. 스탠퍼드 대학 연구진이 2023년에 출처 링크를 붙여 답하는 AI 검색 서비스 네 곳의 답을 사람이 평가했더니, 네 곳을 평균해 답 문장의 51.5%만 붙은 인용으로 완전히 뒷받침되었고 인용의 74.5%만 그 인용이 붙은 문장을 뒷받침했습니다(Liu·Zhang·Liang, 2023).

이런 서비스를 생성형 검색 엔진이라고 부르며, 웹을 검색해 읽은 내용으로 답을 쓰고 답 안에 출처 링크(인용)를 함께 붙여 줍니다. 연구진은 2023년 2월 말부터 3월 말까지 Bing Chat, NeevaAI, perplexity.ai, YouChat에 각각 질문 1,450개를 묻고, 답의 문장 하나하나가 붙은 인용으로 뒷받침되는지와 붙은 인용 하나하나가 그 문장을 뒷받침하는지를 평가자가 판정하게 했습니다(Liu·Zhang·Liang, 2023).

이 연구에서는 답이 도움이 되어 보인다는 점수가 높은 서비스일수록 인용이 부정확했습니다. 평가자가 1점부터 5점까지로 매긴 이 점수의 평균은 붙은 인용이 문장을 뒷받침한 비율이 가장 높았던 Bing Chat(89.5%)에서 가장 낮았고(4.34점), 그 비율이 가장 낮았던 YouChat(63.6%)에서 가장 높았습니다(4.62점). 연구진이 네 서비스의 평균값으로 잰, 인용이 문장을 뒷받침한 비율과 도움이 되어 보인다는 점수 사이의 상관계수(두 값이 함께 움직이는 정도를 −1부터 1까지로 나타낸 값)는 −0.96이었습니다. 다만 견준 서비스가 네 곳뿐이라 일반적인 법칙으로 보기는 어렵습니다. 연구진은 출처의 문장을 거의 그대로 옮긴 답은 인용이 맞지만 질문과 덜 맞고, 출처에서 벗어난 답은 질문에 맞고 도움이 되어 보이지만 인용이 틀리기 쉽다고 해석했습니다(Liu·Zhang·Liang, 2023).

이 결과는 출처 링크가 붙어 있다는 것만으로 답이 맞는지 알 수 없다는 뜻입니다. 질문과 관련된 자료를 찾아 AI에게 함께 읽히는 RAG(검색 증강 생성)도 마찬가지이며, RAG가 어느 단계에서 틀리는지는 "RAG란? 검색 증강 생성의 뜻과 작동 순서, 한계"에 정리했습니다.

대화가 길어지면 할루시네이션이 늘어나나요?

늘어날 수 있습니다. 언어 모델은 낱말을 하나 쓸 때마다 앞의 대화와 자기가 방금 쓴 글까지 다시 읽고 다음 낱말을 고르므로, 한 번의 답 안에서도 첫머리에서 틀리게 정한 내용을 뒤의 설명이 이어받기 쉽습니다(Zhang 외, 2023).

워싱턴 대학 등의 연구진은 2023년 실험에서, GPT-4가 답의 첫머리에서 9677이 소수(1과 자기 자신으로만 나누어떨어지는 수)가 아니라고 단정한 뒤 13 × 745 = 9677이라는 틀린 근거를 이어 쓰는 것을 보였습니다. 이 실험에서 답의 첫 낱말이 "예"나 "아니요"인 경우는 GPT-4에서 95.67%, ChatGPT에서 98.40%였습니다. 그런데 따로 물었을 때 GPT-4는 13이 9677의 약수가 아니라는 것을 아는 것으로 보였습니다. 소수 판별, 미국 상원의원 찾기, 항공편 연결의 세 가지 질문 묶음으로 2023년에 시험한 ChatGPT와 GPT-4는 자기 답에 들어간 틀린 주장 가운데 각각 67%와 87%를 따로 물었을 때 틀렸다고 알아보았습니다(Zhang 외, 2023). 연구진은 앞의 실수에 맞추려다 실수가 더 늘어나는 이 현상을 hallucination snowballing(눈덩이처럼 불어나는 할루시네이션)이라고 불렀습니다.

여러 차례 주고받는 대화에서도 비슷한 일이 생깁니다. Microsoft Research와 Salesforce Research의 연구진이 2025년에 언어 모델 15개로 대화 20만 건 이상을 모의 실험했더니, 지시를 한 번에 다 주지 않고 여러 차례에 나눠 주었을 때 코드 작성, 수학, 요약 같은 여섯 가지 작업의 성능이 평균 39% 떨어졌고, 이 하락은 두 차례만 주고받는 대화에서도 나타났습니다(Laban 외, 2025). 이 연구는 할루시네이션만이 아니라 작업 성능 전체를 쟀지만, 모델이 앞쪽 차례에서 섣불리 가정해 답을 내놓은 뒤 그 답에 지나치게 기댄다는 설명은 앞의 실험과 같은 방향입니다.

대화가 아주 길어질 때 앞의 내용을 놓치는 문제는 AI가 한 번에 읽고 쓸 수 있는 글의 범위인 컨텍스트 윈도우와 관련이 있으며, "컨텍스트 윈도우란? AI가 긴 대화와 긴 문서에서 놓치는 것"에서 따로 다룹니다.

기술 문서 업무에서 할루시네이션은 어떤 모양으로 나타나나요?

기술 문서 업무에서 눈여겨볼 할루시네이션은 수치와 출처의 오류입니다. 원문에 있는 값에 틀린 위치를 근거로 붙이는 일과 없는 참고 문헌을 지어내는 일은 아래처럼 실제로 확인된 예가 있고, 시험 조건이 다른 값을 옮겨 쓰는 일도 생길 수 있습니다.

아모프 창업팀이 2026년 9월 22일에 시제품을 시험할 때, AI가 논문의 13번째 줄에만 있는 수치를 설명에 쓰면서 근거로는 14번째 줄만 인용한 일이 있었습니다. 수치는 논문에 실제로 있는 값이었지만, 붙은 근거만으로는 그 수치를 되짚을 수 없었습니다. 내용이 맞아도 출처가 틀리면 사람이 그 내용을 원문에서 확인할 수 없다는 점에서, 앞의 생성형 검색 엔진 연구가 잰 잘못 붙은 인용과 같은 종류의 오류입니다.

미국의 두 연구자가 2023년에 발표한 연구에서 ChatGPT의 GPT-3.5와 GPT-4에게 42개 주제로 짧은 문헌 검토 글(한 주제의 기존 연구를 모아 정리한 글) 84편을 쓰게 하고 참고 문헌 636개를 확인했더니, 존재하지 않는 문헌이 GPT-3.5에서 55%, GPT-4에서 18%였습니다. 실제로 있는 문헌 가운데서도 GPT-3.5의 43%, GPT-4의 24%에 중대한 인용 오류가 있었습니다(Walters·Wilder, 2023).

시험 조건이 다른 값을 옮겨 쓰는 오류는 인용만 확인해서는 드러나지 않습니다. 예시로, 시험 성적서에 "23 °C에서 측정한 인장 강도 45 MPa"라고 적혀 있다고 해 봅시다. 인장 강도는 재료를 잡아당길 때 끊어지기 전까지 견디는 단면적당 힘이고, MPa(메가파스칼)는 그 단위입니다. AI가 이 값을 80 °C의 인장 강도를 묻는 질문의 답으로 쓰면, 숫자는 원문에 글자 그대로 있어도 답은 틀립니다. 논문 PDF의 표를 AI가 읽을 때 생기는 문제는 "AI는 논문 PDF의 표에서 수치를 제대로 읽을 수 있나요?"에 따로 정리했습니다.

할루시네이션을 줄이려면 무엇을 확인하나요?

AI의 답에서 할루시네이션을 줄이고 가려내려면 인용한 문장이 원문에 글자 그대로 있는지, 수치의 단위와 시험 조건이 질문과 같은지, 모를 때 답하지 않아도 되도록 지시했는지를 확인합니다.

첫째, 인용은 원문을 열어 그 문장을 직접 찾아봅니다. 2023년 생성형 검색 엔진 연구에서 네 곳을 평균해 인용의 4분의 1가량이 붙은 문장을 뒷받침하지 못했기 때문입니다(Liu·Zhang·Liang, 2023).

둘째, 수치는 숫자만 맞춰 보지 말고 단위와 시험 조건을 함께 봅니다. 앞의 인장 강도 예시처럼 숫자가 원문에 그대로 있어도 조건이 다르면 다른 값입니다.

셋째, 모를 때 답하지 않아도 되도록 했는지 봅니다. 답하지 않는 것과 틀린 답을 똑같이 0점으로 다루면 추측이 유리해진다는 것이 앞의 분석이므로(Kalai 외, 2025), 예시로 "근거를 찾지 못하면 찾지 못했다고 답하라"처럼, 모를 때는 답하지 않아도 된다고 지시문에 적어 둡니다. 같은 이유로 AI 도구를 견줄 때 맞힌 수만 세면, 추측을 많이 하는 도구가 더 정확해 보일 수 있습니다.

다만 모를 때 답하지 않게 해도 틀린 답이 모두 사라지지는 않습니다. OpenAI의 SimpleQA 결과에서 질문의 절반 넘게 답하지 않은 gpt-5-thinking-mini도 전체 질문의 26%에서 틀린 답을 냈으므로(OpenAI, 2025), 답에 붙은 근거를 사람이 원문에서 되짚을 수 있어야 틀린 답을 알아챌 수 있습니다.

여기서 언어 모델은 글을 읽고 이어질 글을 만들어 내는 AI 모델이고, AI 에이전트는 언어 모델에 도구와 규칙을 묶어, 사람의 요청이나 정해 둔 시각·사건에 따라 여러 단계의 일을 이어 처리하는 프로그램이며, 코딩 에이전트는 코드를 쓰는 AI 에이전트입니다.

같은 모델이라도 하네스에 따라 결과가 크게 달라집니다. 에이전트 개발 도구를 만드는 LangChain은 2026년 2월 17일, 모델(gpt-5.2-codex)은 그대로 두고 하네스만 고쳐서 자사 코딩 에이전트의 Terminal Bench 2.0(89개 과제로 이루어진 코딩 평가) 점수를 52.8%에서 66.5%로 올렸다고 밝혔습니다(LangChain, 2026년 2월).

하네스 엔지니어링에서 하네스는 무엇을 가리키나요?

하네스(AI 하네스)는 언어 모델을 감싸서 모델에게 지시문과 도구를 건네고, 모델이 고른 동작을 실제로 실행해 그 결과를 다시 모델에게 돌려주는 프로그램과 설정을 가리킵니다. 그 프로그램이 AI 제품 안에 있는지, AI로 개발하는 작업 환경에 있는지에 따라 가리키는 범위가 달라집니다.

첫째는 AI 제품 안에서 모델을 감싸는 하네스입니다. LangChain의 트리베디(Vivek Trivedy)는 하네스를 모델이 아닌 모든 코드와 설정, 실행 논리로 정의하고, 시스템 프롬프트, 도구와 스킬 그리고 그 설명, 샌드박스 같은 실행 환경, 일을 나누고 넘기는 실행 흐름, 대화 압축이나 코드 검사처럼 정해진 때에 자동으로 실행되는 처리를 예로 듭니다(LangChain, 2026년 3월). 시스템 프롬프트는 모델에게 매번 먼저 건네는 기본 지시문이고, 도구는 파일 읽기처럼 모델이 불러 쓰는 기능이며, 스킬은 특정 작업에 쓸 지시와 파일을 묶어 둔 것이고, 샌드박스는 프로그램을 바깥과 격리해 실행하는 공간입니다.

트리베디가 하네스의 예로 든 압축(compaction)은 대화가 길어질 때 앞부분을 요약해 줄이는 기능입니다(LangChain, 2026년 3월). 모델이 답을 만들 때 함께 읽는 글을 컨텍스트라고 하고, 모델이 쓰는 답까지 합쳐 한 번에 다룰 수 있는 글의 한도를 컨텍스트 윈도우라고 합니다(Claude 컨텍스트 윈도우 문서). AI 모델 Claude를 만드는 Anthropic의 코딩 도구 Claude Code는 한도에 가까워진 대화 기록을 모델에게 넘겨 요약하게 하고, 그 요약과 최근에 연 파일 다섯 개로 일을 이어 갑니다(Anthropic, 2025년 9월). 한도가 찰 때 생기는 일은 컨텍스트 윈도우란 글에서 따로 다룹니다.

둘째는 AI에게 개발을 맡긴 팀이 꾸리는 작업 환경입니다. ChatGPT를 만드는 OpenAI가 2026년 2월 11일 공개한 글에 따르면, 엔지니어 세 명으로 시작한 팀이 5개월 동안 사람이 코드를 한 줄도 직접 쓰지 않고 코딩 에이전트 Codex만으로 내부 베타 제품을 만들었고, 그동안 저장소(코드와 문서를 보관하는 곳)에는 애플리케이션 코드와 인프라, 도구, 문서를 합쳐 약 100만 줄이 쌓였습니다. 이 팀은 엔지니어의 주된 일이 코드를 쓰는 일에서 환경을 설계하고 의도를 명시하며 피드백 루프(결과를 다시 받아 다음 작업을 고치게 하는 구조)를 만드는 일로 바뀌면 무엇이 달라지는지 알아야 했다고 적었습니다. 그리고 실제로 팀의 주된 일은 에이전트가 쓸모 있는 일을 하도록 돕는 것이 되었다고 밝혔습니다(OpenAI, 2026).

기술 컨설팅 회사 Thoughtworks의 엔지니어 뵈켈러(Birgitta Böckeler)는 코딩 에이전트의 하네스 가운데 시스템 프롬프트 같은 일부는 이미 도구에 들어 있고, 사용자는 그 바깥에 자기 업무에 맞춘 바깥 하네스(outer harness)를 만든다고 나눠 설명합니다(Böckeler, 2026). 우아한형제들 기술 블로그도 AI 코딩 도구에 프로젝트 규칙을 매번 다시 설명해야 했던 문제를, 팀 전용 규칙과 스킬로 만든 하네스로 다룬 사례를 소개했습니다(이재홍, 2026).

하네스 엔지니어링은 프롬프트·컨텍스트·루프 엔지니어링과 무엇이 다른가요?

하네스 엔지니어링은 지시문이나 입력 한 번이 아니라 모델을 둘러싼 실행 환경 전체를 설계한다는 점에서 다릅니다. 프롬프트 엔지니어링은 모델에게 주는 지시문을, 컨텍스트 엔지니어링은 모델이 한 번에 읽는 정보 전체를, 루프 엔지니어링은 목표에 닿을 때까지 에이전트를 되풀이해 실행하는 구조를 설계합니다.

네 가지의 경계는 서로 겹칩니다. Anthropic은 컨텍스트 엔지니어링을 모델이 답을 만드는 동안 읽는 토큰(모델이 글을 잘게 나눠 읽고 쓰는 단위)의 가장 알맞은 묶음을 고르고 관리하는 전략으로 정의하고, 프롬프트 엔지니어링이 자연스럽게 발전한 단계로 봅니다(Anthropic, 2025년 9월). 뵈켈러는 코딩 에이전트의 사용자가 하네스를 만드는 일을 컨텍스트 엔지니어링의 한 형태로 봅니다(Böckeler, 2026). 그래서 네 이름은 서로를 대신하는 기술이라기보다, 같은 시스템을 어디까지 넓게 보고 설계하느냐에 따라 붙는 이름에 가깝습니다.

정리하면 네 가지는 설계 대상과 다루는 단위가 다르고, 대표적인 실패도 각자 다루는 단위에서 생깁니다.

AI 에이전트와 하네스는 같은 말인가요?

같은 말이 아닙니다. AI 에이전트는 언어 모델과 하네스를 합친 전체이고, 하네스는 그 가운데 모델을 뺀 나머지 부분입니다.

트리베디는 "에이전트 = 모델 + 하네스"라는 식과 "모델이 아니면 하네스"라는 말로 이 관계를 정리했고, 뵈켈러는 이 식을 인용하며 하네스가 AI 에이전트에서 모델 자체를 뺀 모든 것을 한마디로 부르는 말로 자리 잡았다고 적었습니다(LangChain, 2026년 3월; Böckeler, 2026). Anthropic은 에이전트가 대개 환경에서 돌아온 결과를 보며 도구를 되풀이해 쓰는 언어 모델이라고 설명하고(Anthropic, 2024년 12월), 에이전트를 만드는 개발 도구 묶음인 Claude Agent SDK를 범용 에이전트 하네스라고 부릅니다(Anthropic, 2025년 11월). 하네스에 모델을 연결하면 곧바로 에이전트로 움직이므로, 같은 제품이 하네스로도 에이전트로도 불립니다.

예시로 쇼핑몰 상담 에이전트를 보면, 고객의 질문을 읽고 답을 쓰는 것은 언어 모델이고, 주문 조회 기능을 모델에게 알려 주고 실제로 조회해 결과를 돌려주는 것은 하네스입니다. 에이전트가 언제 일을 시작하고 어디까지 혼자 끝낼 수 있는지는 "AI 에이전트는 스스로 일을 찾아서 하나요?"에서 다룹니다.

하네스에 기능을 많이 넣으면 AI가 더 잘 고르나요?

그렇지 않습니다. 기능의 설명만 읽고 서로 구별할 수 없을 만큼 선택지가 많아지면, AI는 질문에 맞지 않는 기능을 고르기 쉬워집니다.

Anthropic의 개발 문서는 2026년 10월 31일 기준으로, 쓸 수 있는 도구가 30~50개를 넘으면 Claude가 알맞은 도구를 고르는 능력이 떨어진다고 설명합니다(Claude 도구 검색 문서). OpenAI의 개발 문서도 2026년 10월 31일 기준으로, 모델이 한 차례 응답을 시작할 때 쓸 수 있는 함수, 즉 도구를 20개 미만으로 두라고 가볍게 권합니다(OpenAI 함수 호출 문서). Anthropic은 가장 흔한 실패 가운데 하나로 기능을 너무 많이 담았거나 어느 도구를 쓸지에 대한 판단을 모호하게 만드는 도구 묶음을 꼽고, 사람 엔지니어도 어느 도구를 써야 할지 확실히 말하지 못한다면 AI 에이전트가 그보다 잘하기를 기대할 수 없다고 적었습니다(Anthropic, 2025년 9월).

설명을 위해 지어낸 예시로 보겠습니다. 쇼핑몰 상담 AI에 "이 옷 사이즈가 어떻게 되나요?"라는 질문이 들어왔는데, 사이즈 정보 조회와 환불 정보 조회처럼 설명이 비슷한 조회 기능이 20~30개 붙어 있다고 해 봅시다. 설명만으로 어느 기능이 맞는지 가려지지 않으면 AI는 그럴듯한 기능을 아무것이나 고를 수 있고, 같은 질문에도 답이 그때그때 달라질 수 있습니다. 고를 기능이 몇 개뿐이고 설명만으로 확실히 갈린다면, AI가 맞는 기능을 고를 가능성이 높아집니다.

기능이 많을 수밖에 없다면, 모델이 도구 목록을 검색해 필요한 몇 개만 불러오는 도구 검색 기능을 두 회사의 문서가 안내합니다(Claude 도구 검색 문서; OpenAI 함수 호출 문서).

하네스를 잘못 설계하면 어떤 실패가 생기나요?

공개된 사례에 보고된 실패로는 AI가 지켜야 할 규칙을 놓치거나, 읽을 수 없는 곳에 있는 지식을 모른 채 일하거나, 일을 다 끝내기 전에 끝났다고 판단하는 일이 대표적입니다. OpenAI는 초기 진행이 더뎠던 까닭을 Codex의 역량이 아니라 제대로 갖춰지지 않은 환경에서 찾았고, Anthropic은 Claude가 보인 실패 경향을 보완하려고 첫 실행에서 작업 환경을 갖추는 단계와 지시문, 검사 도구를 더했습니다(OpenAI, 2026; Anthropic, 2025년 11월).

• 지침을 파일 하나에 몰아넣었더니 에이전트가 주요 제약을 놓쳤습니다. OpenAI 팀은 에이전트용 안내 파일 AGENTS.md 하나에 지침을 다 담았더니 지침이 작업과 코드, 관련 문서가 들어갈 컨텍스트를 차지했고, 모든 것이 중요하다는 지침은 아무것도 중요하지 않은 지침이 되었으며, 파일은 금세 낡았다고 적었습니다(OpenAI, 2026).
• 읽을 수 없는 지식은 없는 것과 같았습니다. 같은 글은 실행 중에 컨텍스트 안에서 접근할 수 없는 것은 에이전트에게 사실상 존재하지 않는다며, 구글 문서나 채팅 스레드, 사람의 머릿속에 있는 지식을 예로 들었습니다(OpenAI, 2026).
• 에이전트는 이미 있는 패턴을 그대로 따라 했습니다. Codex는 저장소에 있는 패턴을 최적이 아닌 것까지 복제했고, 팀은 한때 일주일의 20%인 매주 금요일을 질 낮은 AI 결과물을 정리하는 데 썼습니다(OpenAI, 2026).
• 에이전트가 한 번에 너무 많이 하려 하거나 일을 너무 일찍 끝냈습니다. Anthropic의 실험에서 긴 작업을 맡은 에이전트는 앱 전체를 한 번에 만들려다 도중에 컨텍스트가 바닥나 반쯤 만든 기능을 기록 없이 남겼습니다. 나중에 시작한 에이전트는 진행된 흔적만 보고 일이 끝났다고 선언했고, 기능이 끝까지 동작하는지 확인하지 않은 채 완료로 표시하는 경향도 보고되었습니다(Anthropic, 2025년 11월).
• 모델이 좋아지자 하네스에 담긴 가정이 낡았습니다. Anthropic은 하네스의 부품마다 모델이 혼자서는 못 한다는 가정이 담겨 있다며, Claude Sonnet 4.5를 위해 넣었던 컨텍스트 초기화(컨텍스트를 비우고 새 에이전트가 정리된 인계 내용을 받아 일을 이어 가게 하는 장치)를 Claude Opus 4.5에서는 뺐다고 밝혔습니다. Sonnet 4.5는 컨텍스트 한도에 가까워졌다고 여기면 일을 서둘러 마무리하는 경향이 강했지만, Opus 4.5에서는 그 경향이 거의 사라졌기 때문입니다(Anthropic, 2026년 3월).

스킬을 잘못 골랐을 때 모델에게 다시 생각하게 하는 것만으로는 바로잡기 어려울 수 있습니다. 스킬 선택을 직접 시험한 연구는 아니지만, 추론 문제에서 외부의 피드백 없이 같은 대화 안에서 언어 모델에게 방금 낸 자기 답을 다시 검토해 고치게 하자, 제대로 고치지 못했고 오히려 성능이 떨어지기도 했다는 연구가 있습니다(Huang 외, 2024).

다만 위 목록의 다섯 가지 실패와 그 대처는 모두 각 회사가 자사 에이전트로 한 실험의 보고입니다. OpenAI도 에이전트가 프롬프트 한 번으로 버그를 재현하고 고친 뒤 검증해 저장소에 반영하기까지 해내는 동작은 그 저장소의 특정 구조와 도구에 크게 기댄 것이라, 적어도 아직은 비슷한 투자 없이 일반화할 수 있다고 가정해서는 안 된다고 적었습니다(OpenAI, 2026).

RAG는 Retrieval-Augmented Generation의 머리글자로, 찾아온 글(검색)로 보태어(증강) 답을 만든다(생성)는 뜻입니다. 이 이름은 Facebook AI Research와 유니버시티 칼리지 런던(UCL), 뉴욕 대학교의 연구진이 2020년 인공지능 학회 NeurIPS에서 발표한 논문에서 나왔습니다(Lewis 외, 2020).

언어 모델은 글을 읽고 쓰도록 많은 글로 학습시킨 AI 모델이고, 색인은 필요한 글을 빨리 찾도록 미리 정리해 둔 자료입니다. RAG 논문은 언어 모델이 학습하며 모델 안의 수많은 숫자(매개변수)에 담은 지식을 "매개변수 기억"이라고 부르고, 모델 밖에 둔 위키백과 색인을 "비매개변수 기억"이라고 불렀습니다(Lewis 외, 2020). 사내 문서로 RAG를 만드는 단계는 "RAG 구축 방법: 출처를 밝히며 답하는 AI를 만드는 5단계"에서 따로 다룹니다.

RAG는 어떤 순서로 답을 만드나요?

RAG는 문서를 조각으로 나눠 색인해 두었다가, 질문이 들어오면 질문과 가까운 조각을 골라 질문과 함께 언어 모델에 넣고, 모델이 그 글을 읽고 답을 쓰게 합니다. 색인은 질문이 들어오기 전에 미리 만들어 두고, 나머지 단계는 질문마다 되풀이합니다.

1. 문서를 청크라는 조각으로 나누고, 조각마다 글의 뜻을 여러 개의 숫자로 나타낸 목록인 벡터를 만들어 색인에 저장합니다. 글을 벡터로 바꾸는 이 일을 임베딩이라고 합니다.
2. 질문이 들어오면 같은 방식으로 질문도 벡터로 바꿉니다.
3. 질문의 벡터와 가까운 조각부터 순서대로 몇 개를 고릅니다.
4. 고른 조각을 질문과 함께 언어 모델의 입력에 넣고, 모델은 그 글을 읽고 답을 씁니다.

벡터를 저장해 두고 질문의 벡터와 맞춰 보는 저장소를 벡터 데이터베이스(벡터 DB)라고 합니다(AWS). 두 벡터가 얼마나 가까운지는 같은 자리의 숫자끼리 곱해 모두 더한 값(내적) 등으로 계산하며, RAG 논문은 위키백과 조각마다 벡터를 만들어 두고 질문 벡터와의 내적이 큰 순서대로 조각을 골랐습니다(Lewis 외, 2020).

벡터 검색은 질문의 낱말이 든 글을 찾는 낱말 검색(대표적인 방식이 BM25)과 달리, 낱말이 달라도 뜻이 가까운 글을 찾을 수 있습니다. RAG 논문의 검색기인 DPR을 처음 발표한 논문은 "Who is the bad guy in lord of the rings?"라는 질문을 예로 듭니다. 답이 든 글이 bad guy 대신 villain(악역)이라고 적고 있으면 낱말 검색은 그 글을 찾기 어렵지만, 벡터 검색은 두 낱말을 가깝게 볼 수 있다는 것입니다(Karpukhin 외, 2020).

RAG를 써도 AI가 틀리나요?

네, 틀릴 수 있습니다. 질문과 어긋난 조각을 고르는 검색 단계와, 답이 든 조각을 받고도 제대로 쓰지 못하는 읽기 단계에서 모두 오류가 생기며, 출처를 붙인 답도 예외가 아닙니다.

검색 단계의 대표적인 오류는 질문과 문서가 같은 내용을 서로 다른 말로 적을 때 생깁니다. 정보 검색 분야는 이를 어휘 불일치라고 부르며 핵심 과제 가운데 하나로 꼽습니다(Nogueira 외, 2019). 예시로, "3분기 공정별 생산량"을 물었는데 문서에는 "7~9월 라인별 산출 실적"이라고 적혀 있다면, 검색기는 "공정"이라는 낱말과 주제가 겹치는 "반도체 공정이란 …" 같은 정의 문단을 더 가깝게 볼 수 있습니다.

벡터 검색은 드문 이름이 든 질문에도 약할 수 있습니다. 2021년 자연어 처리 학회 EMNLP에서 발표된 연구는 위키데이터(위키미디어 재단이 운영하며 여럿이 함께 편집하는 지식 데이터베이스)의 사실을 정해 둔 질문 틀에 넣어 "아르베 푸르세트(Arve Furset)는 어디에서 태어났나요?" 같은 단순한 질문을 만들고, 이렇게 만든 질문으로 검색기를 시험했습니다. 이 시험에서 상위 20개 조각 안에 답이 든 조각이 있었던 질문의 비율은 Natural Questions라는 질문 모음으로만 학습한 DPR이 평균 49.7%, 질문 모음 네 개로 함께 학습한 DPR이 56.7%, BM25가 72.0%였습니다(Sciavolino 외, 2021). 연구진은 DPR이 위키백과에 자주 나오는 대상을 묻는 질문에서는 잘 찾았지만, 드문 대상일수록 정확도가 빠르게 떨어졌다고 보고했습니다. 아르베 푸르세트가 태어난 곳을 물었을 때 Natural Questions로만 학습한 DPR이 첫째로 고른 조각은, 아르베 푸르세트가 아니라 전설 속 족보에 나오는 Gard Agdi라는 다른 인물에 관한 글이었습니다.

읽기 단계에서는 답이 든 조각이 입력에 들어가도 그 위치가 가운데이면 놓치기 쉽습니다. 2023년에 공개되어 2024년 학술지 TACL에 실린 연구에서 GPT-3.5-Turbo에 위키백과 조각 20개를 주고 답이 든 조각의 위치만 바꿔 물었더니, 정답률은 그 조각이 맨 앞일 때 75.8%, 10번째일 때 53.8%, 맨 끝일 때 63.2%였습니다(Liu 외, 2024). 같은 연구에서 답이 든 조각이 10번째에 있을 때 GPT-3.5-Turbo가 낸 정답률은, 조각을 하나도 주지 않고 물었을 때의 정답률 56.1%보다도 낮았습니다. 이 현상은 컨텍스트 윈도우를 다룬 글에서 자세히 다룹니다.

실제 RAG 시스템에서는 오류가 생기는 곳이 더 다양합니다. 연구, 교육, 생명 의학 분야에서 RAG 시스템을 만든 사례 세 건을 정리한 2024년 연구는 실패 지점을 일곱 가지로 나눴고, 그 가운데 넷은 다음과 같습니다(Barnett 외, 2024).

• 질문이 문서 내용과 관련은 있지만 문서에 답이 없을 때, "모르겠다"고 답하지 않고 답을 내놓을 수 있습니다.
• 답이 든 문서가 있지만 순위가 낮아, 돌려주는 상위 몇 개 안에 들지 못합니다.
• 답이 든 문서가 검색되었지만, 많은 결과를 추려 입력을 만드는 과정에서 빠집니다.
• 입력에 답이 있어도 잡음이나 서로 어긋난 정보가 많으면, 모델이 답을 꺼내지 못합니다.

나머지 셋은 요청한 형식을 어긴 답, 너무 막연하거나 세세한 답, 정보 일부를 빠뜨린 답입니다(Barnett 외, 2024).

출처가 붙은 답이라고 해서 출처가 맞는 것도 아닙니다. AI가 쓴 답이 실제 사실이나 사용자가 건넨 지시와 자료에 맞지 않는 현상을 할루시네이션이라고 하며, 답에 붙은 출처가 틀리는 경우와 그 원인은 할루시네이션을 다룬 글에서 설명합니다.

RAG에서 청크와 청킹은 무엇인가요?

청킹은 검색할 단위로 문서를 잘게 나누는 일이고, 그렇게 나눈 조각 하나하나가 청크입니다. RAG 논문은 위키백과 글을 겹치지 않게 100낱말씩 끊어 청크 2,100만 개를 만들었습니다(Lewis 외, 2020).

DPR 논문은 위키백과 글에서 표와 정보 상자, 목록을 먼저 지운 뒤 본문만 100낱말 단위로 나눴습니다(Karpukhin 외, 2020). 앞뒤 조각이 겹치도록 자르는 방식은 겹치지 않게 자른 쪽보다 낫지 않았다고 적었습니다.

청크를 얼마나 크게 자를지는 정해진 답이 없는 설계 값입니다. IBM은 청크 크기를 RAG 시스템의 중요한 하이퍼매개변수(사람이 미리 정해 주는 설정 값)라고 설명하고(IBM), RAG 시스템 세 건을 만든 앞의 연구도 청크 크기와 청킹 방식, 검색 방식, 입력의 길이를 맞춰야 하고 운영 중에도 계속 다시 맞춰야 한다고 적었습니다(Barnett 외, 2024).

청크의 경계가 내용의 구조와 어긋나면 값과 그 값의 뜻이 서로 다른 청크로 갈라집니다. 아모프 창업팀이 2026년 9월 24일 같은 논문을 PDF와 학술지 XML(논문의 절과 표를 구조째 담은 파일)로 읽어 보니, PDF에서는 표의 한 줄이 숫자만 이어진 글 조각이 되고 열의 머리글은 다른 조각으로 떨어졌지만, XML에서는 표 11개가 모두 행과 열을 유지했습니다. 이런 조각을 그대로 청크로 쓰면, 숫자만 남은 청크에는 질문에 쓰인 낱말이 거의 없어 검색되기 어렵고, 검색되더라도 어느 숫자가 어느 열의 값인지 확실히 알 수 없습니다. 이 비교는 논문 PDF의 표를 다룬 글에 정리했습니다.

조각 대신 요약을 검색하는 RAG는 무엇이 다른가요?

원문 조각을 그대로 검색하지 않고, 언어 모델이 조각마다 미리 써 둔 요약이나 예상 질문을 검색 대상으로 삼는다는 점이 다릅니다. 그래서 질문과 원문의 표현이 달라도 맞는 조각을 찾을 가능성이 커지지만, 요약이 빠뜨리거나 잘못 쓴 내용은 그 내용을 물어도 찾기 어려워집니다.

조각마다 예상 질문을 만들어 붙이는 방식은 검색 분야에서 문서 확장이라는 이름으로 RAG 이전부터 시험되었습니다. 2019년 Doc2Query 연구는 문서마다 사람들이 물을 법한 질문을 모델로 만들어 문서 끝에 붙인 뒤 BM25로 검색했고, MS MARCO 검색 시험의 개발용 질문 모음에서 순위 점수(MRR@10, 정답 문서가 위에 나올수록 높은 점수)를 18.4에서 21.5로 올렸습니다(Nogueira 외, 2019). Doc2Query 연구진이 아주 흔한 낱말을 빼고 세어 보니, 모델이 만들어 붙인 질문의 낱말 가운데 31%가 원래 문서에 없던 낱말이었습니다.

요약을 여러 층으로 쌓는 방법도 있습니다. 2024년 학회 ICLR에서 발표된 RAPTOR는 비슷한 청크를 묶어 요약하고, 그 요약을 다시 묶어 요약하는 일을 되풀이해 요약 트리(아래층에서 위층으로 갈수록 더 넓은 범위를 요약한 나무 모양의 구조)를 만든 뒤, 질문에 맞는 글을 트리의 여러 층에서 찾게 했습니다(Sarthi 외, 2024). 저자들은 RAPTOR 검색을 GPT-4와 함께 썼을 때 긴 글 독해 시험인 QuALITY의 최고 정확도를 20%포인트 높였다고 보고했습니다.

요약에도 오류가 섞일 수 있습니다. 같은 연구진이 GPT-3.5-Turbo가 쓴 요약 가운데 이야기 40편에서 무작위로 고른 150개를 사람이 확인했더니, 6개(4%)에 원문에 없는 내용이 섞여 있었습니다. 연구진은 이 오류가 대체로 사소했고 위층 요약으로 번지지 않았으며, 질문에 답하는 성능에도 뚜렷한 영향이 없었다고 적었습니다(Sarthi 외, 2024). 다만 요약만 검색하는 구성에서는 요약이 빠뜨린 세부를 묻는 질문에 그 청크가 걸리지 않을 수 있고, 색인을 만들 때 청크마다 언어 모델을 불러야 하므로 문서가 많을수록 시간과 비용도 늘어납니다.

RAG와 파인튜닝은 무엇이 다른가요?

파인튜닝은 이미 학습된 모델을 특정 자료로 더 학습시켜 모델 안의 숫자를 바꾸는 방법이고, RAG는 모델 밖의 문서를 답할 때마다 찾아 읽게 하는 방법입니다. 그래서 RAG에서는 문서를 고치는 것만으로 모델이 답에 쓰는 지식을 바꿀 수 있습니다. 다만 RAG를 처음 제안한 논문도 질문을 벡터로 바꾸는 부분과 답을 쓰는 생성 모델을 과제에 맞춰 함께 파인튜닝했고, 모델을 그대로 둔 것은 학습을 마친 뒤 색인만 바꾼 실험이었습니다(Lewis 외, 2020).

RAG 논문은 2016년과 2018년 사이에 바뀐 각국 지도자 82명을 "페루의 대통령은 누구인가요?" 같은 질문으로 물었습니다. 색인이 2016년판 위키백과일 때 2018년 지도자를 맞힌 비율은 4%였지만, 모델은 그대로 두고 색인만 2018년판으로 바꾸자 68%가 되었습니다(Lewis 외, 2020). 같은 논문은 지식을 매개변수에만 담은 모델은 세상이 바뀌면 다시 학습해야 한다고 설명합니다.

다만 RAG도 문서가 바뀌면 그 문서의 임베딩을 실시간으로 또는 주기적으로 다시 만들어 색인을 갱신해야 합니다(AWS).

새 사실을 넣는 일에서는 RAG가 나았다는 비교도 있습니다. 2024년 EMNLP에 실린 연구는 정답이 붙지 않은 문서를 그대로 더 학습시키는 비지도 파인튜닝과 RAG를 비교해, 학습 때 본 지식과 처음 보는 지식 모두에서 RAG가 꾸준히 앞섰고 모델이 비지도 파인튜닝으로는 새 사실을 익히기 어려웠다고 보고했습니다(Ovadia 외, 2024). 두 방법은 함께 쓸 수도 있습니다(IBM).

GraphRAG는 일반 RAG와 무엇이 다른가요?

GraphRAG는 질문과 가까운 조각을 찾아 읽는 일반 RAG와 달리, 언어 모델이 문서에서 사람, 장소, 조직 같은 대상과 관계를 뽑아 지식 그래프(대상과 관계를 점과 선으로 이은 자료)를 만들고, 가깝게 이어진 대상의 묶음마다 요약을 미리 써 두는 방식입니다. Microsoft 연구진이 2024년에 제안한 이 방식은 "이 자료 전체의 주요 주제는 무엇인가?"처럼 문서 전체를 묻는 질문에 일반 RAG가 약하다는 점을 겨냥했고, 묶음별 요약으로 부분 답을 만든 뒤 다시 요약해 최종 답을 씁니다(Edge 외, 2024). 어떤 질문에 강하고 그래프가 틀리면 어떻게 되는지는 "GraphRAG의 뜻과 일반 RAG와의 차이: 그래프로 근거를 찾는 방식"에서 다룹니다.

이 다섯 단계는 아모프 창업팀이 만든 지식 AI 시제품의 설계와 시험에서 내린 결정을 순서대로 정리한 것입니다. 창업팀은 2026년 9월부터 10월까지 기술 문서와 공개 논문을 읽고 사람이 확인한 내용만 지식으로 쌓는 이 시제품을 만들었습니다. 시제품은 한 컴퓨터에서 실행되며, 공개 논문과 시험용 문서로 시험했을 뿐 실제 회사의 업무에 쓴 결과가 아닙니다.

1단계: 온톨로지로 답할 질문을 먼저 정합니다

온톨로지의 틀을 정하기 전에, 그 지식으로 답해야 할 질문부터 적습니다. 아모프 창업팀은 "이 조건에서 무엇이 보고되었는가"를 묻는 질문과 "조건을 바꾸면 무엇이 예상되는가"를 묻는 질문을 나눠서 답하도록 시제품을 설계했습니다.

답해야 할 질문의 목록을 먼저 적어 온톨로지의 범위를 정하는 방법은, 스탠퍼드 대학의 노이와 맥기니스가 쓴 온톨로지 입문 안내서에도 첫 단계인 범위 정하기의 한 방법으로 나옵니다(Noy·McGuinness, 2001). 이 안내서는 이런 질문을 역량 질문(competency question)이라고 부르고, 나중에 온톨로지가 그 질문에 답할 만큼 정보를 담았는지 확인하는 시험으로 씁니다.

시제품은 질문에 답하는 방식을 다음 세 가지로 나눴습니다.

• 기록에서 답을 찾는 조회
• 시료(실험에 쓰는 재료의 견본)와 분석법, 측정 기준, 운전 방식(설비를 돌리는 방식)이 서로 맞는지 따지는 적용 가능성 판단
• 등록된 계산 모형으로 하는 예측(시제품에는 아직 구현하지 않았습니다)

2단계: 기록의 종류와 같은 기록인지 판단할 기준을 정합니다

문서에서 읽을 사실을 시료, 실험, 관측 같은 기록의 종류로 나누고, 두 기록이 같은 대상인지 판단할 식별 기준을 정합니다. 시제품은 두 기록이 같은지를 문장이 얼마나 비슷한지가 아니라, 미리 정한 식별 기준으로만 판단합니다.

여기서 관측은 무엇을 재거나 보고한 값 하나를 담는 기록이고, 식별 기준은 두 기록이 같은 대상을 가리키는지 판단할 때 비교하는 항목입니다. 두 논문에 같은 시료 이름이 나와도 같은 시료라는 보장은 없으므로, 같은 대상인지 가르는 기준을 먼저 정하지 않으면 이름만 같은 다른 시료의 값이 한 기록으로 섞입니다.

• 논문처럼 고유한 식별 번호가 붙은 자료는 그 번호로 출처를 구별하는 편이 안전합니다. DOI는 논문 같은 자료에 하나씩 붙어 그 자료를 고유하게 가리키는 식별 번호이며(DOI Foundation), 국제 표준 ISO 26324로 정해져 있습니다.
• 시험 성적서는 제품이나 재료를 시험한 결과를 적은 문서입니다. 이 글의 시제품을 시험할 때 쓴 규격과 성적서는 시험용으로 지어낸 자료였습니다.

3단계: 값마다 출처와 성격을 나눠 적습니다

같은 숫자라도 논문이 보고한 값과 직접 잰 값은 서로 다른 사실이므로, 값마다 둘 가운데 어느 쪽인지 구분하고 측정한 값인지 다른 값에서 계산한 값인지도 따로 적습니다. 원문에 실험 날짜가 없으면 논문의 출판일로 채우지 않고 "미상"으로 둡니다.

• 출처의 종류에 따라 근거로 삼을 수 있는 기록이 다릅니다. 예를 들어 뉴스 기사는 규격이나 실험 기록의 근거로 삼기 어렵습니다.
• 설정한 온도와 실제로 잰 온도는 서로 다른 기록으로 둡니다.
• 단위는 바꾸지 않고 원문 그대로 둡니다. 시간을 h(시간)로 적은 기록과 min(분)으로 적은 기록처럼 단위가 다르면 값을 비교하지 않고 "판정불가"로 답합니다. 판정불가는 근거가 부족하거나 단위나 시험법이 달라서 기준을 충족하는지 판단할 수 없을 때, 충족과 미충족 대신 내는 세 번째 답입니다.
• 논문의 표에서 수치를 읽는 방법은 "AI는 논문 PDF의 표에서 수치를 제대로 읽을 수 있나요?"에서 설명합니다.

4단계: 표준 어휘에 대응시킵니다

기록의 종류와 칸마다 공개된 표준 어휘에서 같은 뜻을 가진 개념을 찾아 대응표를 만듭니다. 표준 어휘는 표준 단체나 비영리 단체가 개념과 관계에 이름을 붙여 공개한 목록이어서, 여러 기관의 자료를 같은 뜻으로 맞춰 읽는 기준이 됩니다.

기록에 자주 쓰는 표준 어휘와 관련 용어는 다음과 같습니다.

• SOSA/SSN은 센서와 관측, 관측 방법, 관측 대상, 시료, 관측한 성질을 기술하는 온톨로지입니다. 웹 표준을 만드는 국제 비영리 단체 W3C와 지리 공간 정보의 표준을 만드는 국제 단체 OGC가 함께 만들었고, W3C는 2017년 10월 19일 이를 표준 문서인 권고안으로 발표했습니다(W3C·OGC, 2017).
• PROV-O는 데이터를 만드는 데 관여한 대상과 활동과 사람, 즉 데이터의 출처와 이력을 기술하는 W3C의 표준 어휘입니다(W3C, 2013).
• QUDT는 측정 단위와 물리량의 종류를 기계가 읽을 수 있게 정의한 공개 어휘이며, 비영리 단체 QUDT.org가 관리합니다(QUDT.org).
• OWL은 온톨로지를 적는 W3C의 표준 언어이고(W3C OWL 2 개요, 2012), 추론기는 OWL로 적은 내용에서 새 정보를 끌어내는 도구입니다(W3C OWL 2 입문서, 2012).

세 어휘는 다루는 대상이 서로 달라서, 관측은 SOSA/SSN, 출처와 이력은 PROV-O, 물리량과 단위는 QUDT처럼 기록의 성격에 맞는 어휘를 골라 씁니다.

세 어휘의 대표 개념은 다음과 같습니다.

이미 있는 어휘를 다시 쓰는 일은 앞의 안내서가 둘째 단계로 권하는 일이기도 합니다. 안내서는 다른 시스템과 자료를 주고받아야 한다면, 그 시스템이 이미 쓰는 어휘를 따르는 일이 꼭 필요할 수도 있다고 설명합니다(Noy·McGuinness, 2001).

5단계: 사람이 확인한 것만 기록하고, 부족한 지식은 사람에게 묻습니다

AI가 제안한 기록 후보는 인용과 수치를 원문과 대조하는 검사를 통과한 뒤에도, 담당자가 원문 인용과 그 위치를 확인하고 확정 버튼을 눌러야 지식 원장에 들어갑니다. 지식 원장은 사람이 확인한 기록만 시간 순서대로 덧붙여 쌓는 데이터베이스입니다.

시제품은 정의가 없는 용어나, 이름은 같은데 설명이 다른 지식을 찾으면 같은 대화 안에서 사람에게 보충을 요청합니다.

• 채팅에서 "맞다"고 답하는 것만으로는 아무것도 기록되지 않습니다.
• 확정 기록에는 누가 어떤 역할로 확정했는지가 함께 남아야, 나중에 그 기록을 누가 책임지는지 되짚을 수 있습니다.
• 설명이 서로 다르면 어느 하나를 지우지 않고, 두 출처를 나란히 보여 줍니다. 문헌마다 재료와 실험 조건이 달라서 두 설명이 모두 맞을 수 있기 때문입니다.
• 전문가가 값을 바로잡아도 논문이 보고한 원래 값은 지우지 않고 정정 기록을 덧붙이며, 그 값을 근거로 기록해 둔 답을 다시 계산합니다.
• AI가 제안한 기록은 틀릴 수 있습니다. 2026년 9월 22일 창업팀이 공개 논문을 외부 AI 모델에게 읽혔을 때, AI가 제안한 기록 후보 3건은 모두 원문 위치를 틀리게 적었습니다.

AI의 제안을 원문과 대조하는 검사는 "RAG 구축 방법: 출처를 밝히며 답하는 AI를 만드는 5단계"의 2단계에서 설명합니다. RAG(검색 증강 생성)는 AI가 답을 쓰기 전에 관련 문서를 찾아 근거로 삼게 하는 방식입니다(Lewis 외, 2020).

온톨로지와 지식 그래프는 무엇이 다른가요?

온톨로지는 어떤 종류의 대상과 관계가 있는지 정한 틀이고, 지식 그래프는 그 틀에 따라 실제 사실을 이어 놓은 자료입니다.

자세한 차이는 "온톨로지란? 뜻과 구성 요소, 데이터베이스와의 차이"에서, 지식 그래프의 뜻과 구성은 "지식 그래프란? 뜻과 시소러스·택소노미와의 차이"에서 설명합니다.

온톨로지 구축에는 어떤 도구를 쓰나요?

온톨로지를 OWL 파일로 직접 편집할 때는 스탠퍼드 대학이 만든 무료 오픈 소스(소스 코드가 공개된) 편집 도구 Protégé가 널리 쓰입니다(Stanford Protégé). 기록을 관계형 데이터베이스(자료를 행과 열로 이루어진 표에 저장하는 데이터베이스)에 쌓는 시스템이라면, 표의 칸과 표준 어휘의 개념을 잇는 대응을 따로 적어 두는 방법도 있습니다.

관계형 데이터베이스의 표를 표준 어휘와 잇는 방법은 "온톨로지란? 뜻과 구성 요소, 데이터베이스와의 차이"의 데이터베이스 스키마(자료를 저장할 표와 칸의 구조) 절에서 설명합니다.

만든 온톨로지로 무엇을 답할 수 있나요?

시제품은 기록에서 답을 찾는 조회와, 시료, 설비, 조건이 서로 비교할 수 있는지 따지는 적용 가능성 판단까지 답합니다. 등록된 계산 모형으로 하는 예측은 아직 구현하지 않았습니다.

시제품은 실험마다 시료와 설비, 실험 조건을 함께 기록해 두고 질문의 조건과 맞춰 봅니다. 그래서 질문한 온도가 실험한 온도 범위 안에 든다는 이유만으로 다른 설비에서 나온 결과를 적용하지 않고, 판단에 필요한 정보가 없으면 무엇이 부족한지 함께 보여 줍니다. 보고된 실험이 없는 조건을 물으면 값을 지어내지 않고 "보고된 실험이 없다"고 답합니다.

아모프가 하지 않는 것

아모프는 기록을 짐작으로 채우거나 임의로 바꾸거나 합치지 않습니다. 창업팀이 이를 위해 시제품에 둔 규칙은 다음 네 가지입니다.

• 보고된 값 사이를 짐작해 채우거나, 여러 문헌의 값을 평균 내거나 다수결로 고르지 않습니다.
• 단위를 임의로 바꾸지 않습니다.
• 문장이 비슷하다는 이유로 두 기록을 합치지 않습니다.
• 원문에 없는 실험 날짜를 출판일로 채우지 않습니다.

XML은 글의 각 부분에 태그라는 이름표를 붙여 구조를 표시하는 파일 형식이며, 학술지 XML(JATS)은 논문의 제목, 절, 문단, 표를 구조째 담는 XML 형식으로 미국 표준 ANSI/NISO Z39.96으로 정해져 있습니다(NISO). 이 비교는 아모프 창업팀이 논문 한 편을 PDF와 학술지 XML로 읽고 PDF 표 찾기 도구 하나를 시험한 결과여서, 모든 PDF와 모든 논문 분석 AI에 그대로 적용되지는 않습니다.

PDF 논문의 표는 왜 구조가 깨지나요?

PDF는 쪽마다 글자와 선을 어느 자리에 그릴지 적어 두는 형식이어서, 표의 행과 열을 구조 정보로 따로 표시하지 않은 PDF에서는 읽는 도구가 글자의 위치나 선을 보고 행과 열을 짐작해야 하기 때문입니다.

PDF 표준은 쪽의 내용을 "쪽에 그릴 그래픽 요소를 설명하는 명령의 연속"으로 나타내도록 정하고, 표를 Table, TR(행), TH(머리 칸), TD(데이터 칸) 같은 구조 요소로 표시하는 방법을 따로 정해 두었습니다. 다만 이런 구조 정보를 넣을지는 PDF를 만드는 프로그램이 정하며, 표준 문서도 머리글과 행, 열의 관계는 보통 읽는 프로그램이 짐작해서 정한다고 적고 있습니다(ISO 32000-1, 2008).

아모프 창업팀이 2026년 9월 24일 그 논문의 PDF를 누구나 내려받아 쓸 수 있는 공개 파이썬 라이브러리 pypdf로 쪽마다 읽어 줄 단위로 나눴을 때, PDF 전체가 글 조각 1,195개로 나뉘었습니다. 파이썬 라이브러리는 프로그래밍 언어 파이썬으로 만든 프로그램이 가져다 쓰는 코드 묶음입니다. 글 조각은 PDF에서 뽑은 글을 나눈 한 단위이며, 이 비교에서는 쪽마다 뽑은 글의 한 줄을 글 조각 하나로 셌습니다. 표의 한 줄은 숫자만 이어진 글 조각 하나가 되었고, 열의 머리글은 다른 글 조각에 들어갔습니다.

같은 날 아모프 창업팀이 PDF를 다루는 다른 공개 파이썬 라이브러리 PyMuPDF 1.27.2의 표 찾기 기능을 기본 설정으로 실행했더니 표를 하나도 찾지 못했고, 글자의 위치로 행과 열을 짐작하는 설정으로 바꾸자 본문 전체를 표 하나로 인식했습니다. 이 기능의 기본 설정은 쪽에 그려진 선과 도형으로 표의 칸 경계를 찾고, 다른 설정은 글자의 위치로 가상의 행과 열 경계를 만듭니다(Artifex의 PyMuPDF 문서). 흔히 "PDF 표 추출"이라고 부르는 이 작업은, 같은 도구에서도 설정에 따라 결과가 이렇게 달랐습니다.

위 그림의 예로 보면, 머리글이 "조건 | 값 1 | 값 2 | 값 3"이고 한 줄이 "A | 12.5 | 3.1 | 48"인 표가 학술지 XML에서는 행과 열이 그대로 남습니다. PDF에서는 머리글이 "조건 값 1 값 2 값 3"이라는 글 조각 하나가 되고 그 줄은 "A 12.5 3.1 48"이라는 다른 글 조각이 되어, 칸 경계 없이 두 조각으로 나뉩니다. 머리글의 낱말 수와 값의 수도 맞지 않으므로, 글만 보고는 12.5가 어느 열의 값인지 확실히 알 수 없습니다.

학술지 XML(JATS)로 읽으면 무엇이 달라지나요?

학술지 XML에는 표의 행과 열, 제목, 각주가 구조로 들어 있어서, 같은 논문을 학술지 XML로 읽었을 때 표 11개가 모두 행과 열로 읽혔습니다.

JATS의 표 요소는 표의 행과 열, 제목, 각주를 한데 묶어 담고, 행 요소는 한 줄에 속한 머리 칸과 데이터 칸을 모두 담습니다(미국 국립의학도서관 JATS 1.4 태그 설명서). 아모프 창업팀은 2026년 9월 24일 그 논문의 학술지 XML에서 표 11개가 모두 행과 열로 읽히는 것을 확인했습니다. 다만 학술지 XML로 읽을 때도 다음 세 가지는 따로 다뤄야 합니다.

• 여러 칸을 합친 칸이 있으면 줄마다 칸 수가 달라지므로, 합친 칸을 어떻게 펼칠지 먼저 정해야 합니다.
• 값 뒤에 붙은 각주 표시는 값의 숫자와 섞이기 쉽습니다. 예를 들어 12.5 뒤에 각주 표시 2가 붙어 있으면, 글자만 이어 붙인 결과는 12.52가 됩니다.
• 표의 제목과 머리 줄, 각주에도 단위와 조건이 적혀 있으므로, 본문 줄과 따로 읽어 위치를 남겨야 합니다.

같은 논문 한 편을 두 형식으로 읽어 보니, PDF에서는 표가 줄 단위의 글로만 남았고 학술지 XML에서는 표 11개의 행과 열이 그대로 남았습니다(아모프 창업팀, 2026년 9월 24일).

학술지 XML은 어디에서 구하나요?

누구나 무료로 읽을 수 있게 공개된 오픈 액세스 논문 가운데 생명과학이나 의학 분야의 논문이라면, 논문 저장소 PubMed Central(PMC)에서 학술지 XML을 받을 수 있는지 먼저 확인해 보세요. PMC는 재사용을 허락한 논문의 본문 전체를 NISO JATS 형식의 XML로 내려받을 수 있게 제공합니다(NCBI PMC). 다른 분야의 논문은 출판사 누리집에서 XML 파일을 함께 내려받을 수 있는지 확인해 보세요.

PMC는 미국 국립보건원 산하 국립의학도서관이 운영하는, 생명과학과 의학 분야 학술지 논문의 본문 전체를 무료로 모아 둔 저장소입니다(NCBI PMC). 다만 PMC에 있는 논문이라도 모두 재사용할 수 있는 것은 아니고 이용 조건이 논문마다 다르므로, 논문에 적힌 이용 허락을 먼저 확인해야 합니다(NCBI PMC).

CC BY 4.0은 출처를 밝히고 이용 허락 문서의 링크를 달고 바꾼 점을 표시하면, 상업적 목적을 포함해 자료를 복제하고 배포하고 고쳐 쓸 수 있게 한 이용 허락입니다(Creative Commons). 아모프 창업팀이 비교에 쓴 논문도 이 조건으로 공개된 논문입니다.

AI가 읽은 수치가 맞는지 어떻게 확인하나요?

AI가 제안한 수치가 인용한 표의 같은 줄, 같은 열에 실제로 있는지, 그리고 단위와 실험 조건이 맞는지를 다시 대조해야 합니다. 인용문을 글자 그대로 대조하는 것만으로는 부족한데, 표의 한 줄을 인용하면 그 줄에 있는 다른 열의 값도 모두 인용 안에 들어 있기 때문입니다.

• 인용한 줄이 머리 줄이 아니라 표의 본문 줄인지, 값이 놓인 열의 머리글이 기록할 측정 항목과 맞는지 확인합니다.
• "<10"처럼 적힌 값은 한 점의 값이 아니라 상한으로 읽습니다.
• 단위가 표 제목이나 열의 머리글에 있는지, 그 줄이 가리키는 실험 조건이 기록할 실험과 같은지 확인합니다.
• 논문의 각주가 다른 값을 빼서 구했다고 밝힌 열의 값은 측정값이 아니라 계산값입니다.

인용을 원문과 대조하는 기준은 "RAG 구축 방법: 출처를 밝히며 답하는 AI를 만드는 5단계"의 2단계에서 설명합니다.

XML이 없는 논문은 어떻게 하나요?

아모프는 XML이 없는 논문의 표 수치를 사람이 PDF의 표를 직접 보고 확인한 뒤에 기록하도록 권합니다. 앞에서 본 것처럼 PDF에서는 표의 구조가 사라지기 쉽고, 표 찾기 도구도 설정에 따라 표를 하나도 찾지 못하거나 본문 전체를 표 하나로 읽었기 때문입니다.

논문과 함께 공개된 엑셀이나 CSV 같은 데이터 파일이 있다면, 표 구조가 남아 있는 그 파일에서 수치를 확인하는 편이 안전합니다. 본문 문장에 든 수치는 표보다 뜻이 모호한 경우가 많습니다. 한 문장에 같은 단위의 수가 여럿 있거나 "about"이나 "more than"처럼 어림값이나 한쪽 범위를 나타내는 말이 붙은 수는, 어느 값이 무엇을 가리키는지 글만으로 가리기 어려우므로 사람이 표에서 확인하는 편이 안전합니다.

엑셀로 받은 연구 데이터는 무엇을 조심해야 하나요?

수식 칸에 계산 결과가 저장되어 있지 않을 수 있으므로, 값을 읽기 전에 수식 칸을 따로 확인해야 합니다.

2026년 9월 아모프 창업팀이 공개 연구 데이터셋 하나의 엑셀 통합 문서를 읽어 보니, 수식 칸 2,375개가 모두 계산 결과 없이 저장되어 있었습니다. 데이터셋은 연구에서 모은 자료를 파일로 묶은 것이고, 통합 문서는 시트 여러 장을 담은 엑셀 파일 하나를 말합니다. 저장된 값만 읽는 방식이었다면 이 칸들은 통째로 빈칸이 되었을 것입니다.

이런 칸을 만나면 수식을 다시 계산할지, 수식 글을 그대로 근거로 남길지를 값을 읽기 전에 정해야 합니다. 이 결과는 데이터셋 하나에서 본 것이어서, 연구용 엑셀 파일이 대부분 이렇다는 뜻은 아닙니다.

그럼 무엇부터 해야 하나요?

먼저 갖고 있는 논문을 학술지 XML을 구할 수 있는 것과 PDF만 있는 것으로 나누고, PDF만 있는 논문의 표 수치는 사람이 확인하는 단계를 따로 두세요. 연구소의 논문과 실험 기록을 근거와 함께 쌓으려면, 기록의 종류와 출처를 정하는 "온톨로지 구축 방법: 기술 문서와 실험 기록을 지식으로 바꾸는 5단계"와 출처를 밝히며 답하는 "RAG 구축 방법: 출처를 밝히며 답하는 AI를 만드는 5단계"를 함께 보세요.

이 글의 다섯 단계는 아모프 창업팀이 2026년 9월부터 10월까지 만든 지식 AI 시제품에 적용한 방법입니다. 이 시제품은 한 컴퓨터에서 실행하는 형태이며, 공개 논문과 시험용 문서로 시험했을 뿐 실제 회사의 업무에 쓴 결과가 아닙니다.

1단계: 문서를 원문 위치가 남도록 읽습니다

문서를 조각으로 나눠 읽을 때 조각마다 원문 위치를 함께 저장해야, 나중에 답의 근거를 원문에서 다시 찾아 확인할 수 있습니다. 시제품은 한글 문서(HWPX), 워드 문서(DOCX), PDF, 엑셀 파일(XLSX), CSV, 텍스트 파일과 학술지 XML을 읽고, 조각마다 "1구역 2표 3행 2열"처럼 원문 위치를 붙입니다.

CSV는 표의 칸을 쉼표로 나눠 글자로 적은 파일이고, XML은 글의 각 부분에 태그라는 이름표를 붙여 구조를 표시하는 파일 형식입니다. HWPX는 워드프로세서 한글로 만든 문서를 국가표준 KS X 6101(OWPML)에 따라 XML 형식으로 저장하는 파일 형식입니다(한글과컴퓨터). 학술지 XML(JATS)은 논문의 제목, 절, 문단, 표를 구조째 담는 XML 형식으로, 미국 표준 ANSI/NISO Z39.96으로 정해져 있습니다(NISO).

한글과 워드 문서, 학술지 XML은 표의 칸이나 줄까지 위치를 남길 수 있지만, PDF는 쪽과 그 쪽에서 읽힌 글 조각의 차례까지만 남깁니다.

PDF의 "2문단"은 실제 문단이 아니라 그 쪽에서 읽힌 글 조각의 차례이므로, 원문과 맞춰 볼 때 주의해야 합니다. 엑셀 파일은 XLSX 형식만 받고, CSV 파일은 UTF-8로 저장한 것만 받습니다. UTF-8은 한글과 영문을 비롯한 여러 나라의 글자를 한 가지 규칙으로 저장하는 표준 방식이며, 엑셀에서는 저장할 때 "CSV UTF-8"을 고르면 됩니다. 옛 HWP나 XLS 파일, UTF-8이 아닌 CSV 파일을 올리면 HWPX, XLSX, "CSV UTF-8" 가운데 맞는 형식으로 다시 저장해 올리라는 이유를 보이며 거절합니다.

2단계: 인용과 수치를 원문과 대조합니다

AI가 문서에서 뽑은 기록 후보는 인용이 그 위치의 원문에 글자 그대로 있을 때만 검사를 통과하고, 표에서 읽은 수치는 같은 줄과 같은 열, 같은 실험 조건에 있을 때만 통과합니다. 기록 후보는 AI가 문서에서 읽어 냈지만 아직 사람이 확정하지 않은 기록을 말합니다. 이 검사는 다음 단계에서 사람이 확정하기 전에 돌아가므로, 검사를 통과하지 못한 후보는 확정할 수 없습니다.

이런 대조가 필요한 이유는 출처가 붙은 답에도 출처가 뒷받침하지 않는 문장과 잘못 붙은 인용이 자주 섞이기 때문입니다. 생성형 검색 엔진은 질문에 대한 답을 문장으로 쓰면서 출처를 함께 붙이는 검색 서비스입니다. 2023년에 발표된 한 연구에서 당시 널리 쓰이던 생성형 검색 엔진 네 곳의 답을 사람이 평가했더니, 평균적으로 답의 문장 가운데 51.5%만 인용으로 완전히 뒷받침되었고, 인용 가운데 74.5%만 그 인용이 붙은 문장을 뒷받침했습니다(Liu·Zhang·Liang, 2023).

아모프 창업팀도 같은 문제를 겪었습니다. 2026년 9월 22일 시제품에서 AI가 논문의 13번째 줄에만 있는 수치를 설명에 쓰면서, 근거로는 14번째 줄만 인용한 일이 있었습니다. 그 수치 자체는 논문에 실제로 있는 값이었지만, 기록 후보에 붙은 근거만으로는 되짚을 수 없었습니다. 출처가 붙어 있다는 것만으로는 그 출처가 문장을 뒷받침하는지 알 수 없으므로, 설명에 쓴 수치가 인용한 원문에 실제로 들어 있는지도 따로 확인해야 합니다.

• 적힌 위치가 원문에 실제로 있는지, 인용한 글이 그 위치에 글자 그대로 있는지 확인합니다.
• 뜻이 비슷한 말로 바꾼 문장은 인용으로 보지 않습니다.
• "<10"처럼 상한만 보고된 값은 한 점의 값이 아니라, 상한이 10인 범위로 읽습니다.
• AI가 고쳐 쓴 설명은 원문과 구별해 표시합니다.

3단계: 근거로 쓸 지식을 사람이 확정합니다

AI가 문서에서 읽은 내용은 바로 검색 대상이 되지 않습니다. AI가 뽑은 기록 후보가 검사를 통과한 뒤 담당자가 원문 인용과 위치를 보고 확정해야 지식 원장에 들어가며, 그때부터 다른 대화에서도 찾아 쓰는 근거가 됩니다.

지식 원장은 사람이 확인한 기록만 시간 순서대로 덧붙여 쌓는 데이터베이스입니다. 이미 들어간 기록은 고치거나 지우지 않고, 바뀐 내용은 정정 기록으로 덧붙입니다.

• 채팅창에서 "맞다"고 답하는 것만으로는 아무것도 기록되지 않고, 확정 버튼을 눌러야 기록됩니다.
• 검사를 통과하지 못한 후보에는 확정 버튼이 생기지 않습니다. 검사 방법은 2단계에서 설명했습니다.
• 확정되지 않은 후보와, 더 이상 쓰지 않기로 표시한 철회된 지식은 지식 검색에서 빠집니다.

어떤 종류의 기록을 어떤 출처와 함께 확정할지는 "온톨로지 구축 방법: 기술 문서와 실험 기록을 지식으로 바꾸는 5단계"에 정리했습니다.

4단계: 질문에 맞는 확정 지식을 찾아 AI에게 건넵니다

질문이 들어오면 사람이 확정한 지식 가운데 질문과 관련된 기록을 골라, 출처와 함께 AI의 문맥에 넣습니다. 근거를 몇 개 넣을지는 문서와 질문의 종류마다 따로 정해야 하는 설계 값입니다.

문맥(컨텍스트)은 AI가 답을 쓸 때 함께 받아 읽는 참고 글입니다. 2023년에 공개되어 2024년 학술지 TACL에 실린 연구에서는 필요한 정보가 입력의 처음이나 끝에 있을 때보다 가운데에 있을 때 AI가 더 자주 놓쳤으므로(Liu 외, 2024), 근거를 많이 넣는다고 답이 꼭 좋아지지는 않습니다. 입력의 가운데에 놓인 정보를 놓치는 이 현상은 "컨텍스트 윈도우란? AI가 긴 대화와 긴 문서에서 놓치는 것"에서 자세히 다룹니다.

• 넣지 못한 관련 기록이 있으면 그 사실을 AI에게 알려야, AI가 목록 밖의 기록을 없다고 단정하지 않습니다.
• 맞는 기록이 없으면 이유와 함께 빈 결과를 돌려주고, 비슷해 보인다는 이유로 없는 근거를 만들어 넣지 않습니다.
• 확정되지 않은 자료를 함께 보여 줄 때는 확정된 지식과 구별해 표시합니다.

아모프 창업팀이 2026년 9월 24일에 마친 시험에서는 공개 논문 두 편을 읽어 시험용 지식 원장에 지식을 확정한 뒤, 논문을 올리지 않은 새 대화에서 관련 용어를 물었습니다. 시제품은 확정된 지식을 출처와 함께 다시 찾아 AI에게 건넸고, 이 대화로 지식 원장이 바뀌지는 않았습니다. 이 시험의 확정은 실제 사용자가 한 것이 아니므로, 실제 사용자의 승인으로 기록하지 않았습니다.

5단계: 계산이 필요한 답은 정해진 절차가 씁니다

기준을 충족하는지처럼 계산이 필요한 답은 AI의 문장이 아니라 시제품에 정해 둔 계산 절차가 쓰므로, AI가 쓴 문장이 계산값을 바꿀 수 없습니다. 이런 답에는 근거가 된 값과 문서 이름, 원문 위치가 함께 표시됩니다.

보고된 실험이 없는 조건을 물으면 값을 지어내거나 주변 실험값으로 짐작하지 않고 "보고된 실험이 없다"고 답하며, 단위나 시험법이 달라 비교할 수 없으면 "판정불가"로 답합니다. 판정불가는 "충족"과 "미충족"에 이은 세 번째 답으로, 근거가 부족하거나 단위나 시험법이 달라서 기준을 충족하는지 판단할 수 없을 때 냅니다.

• 값이 "<10"으로만 보고되었는데 기준이 "5 이하"라면, 그 값이 기준을 충족하는지 판단할 수 없으므로 판정불가로 답합니다.
• 시제품은 단위를 임의로 바꾸지 않으므로, 시간 단위 h(시간)와 min(분)이 섞이면 판정불가로 답합니다.
• 답에 필요한 조건이 질문에 빠져 있으면 판정한 것처럼 답하지 않고, 필요한 조건을 되묻습니다.

아모프의 시제품도 RAG인가요?

네. 질문이 들어올 때마다 사람이 확인한 지식을 찾아 AI에게 함께 건네므로 RAG에 속합니다. 다만 문서 조각 전체가 아니라, 사람이 확정한 지식만을 찾는 범위로 삼는다는 점이 다릅니다.

RAG라는 이름을 붙인 연구의 모델은 위키백과를 벡터 색인으로 만들어 두고, 미리 학습시킨 AI 검색 모델로 질문에 맞는 글을 찾아 답을 쓰는 모델에 건넸습니다(Lewis 외, 2020). 색인은 빨리 찾을 수 있도록 미리 정리해 둔 자료입니다. 벡터 색인은 글마다 그 뜻을 숫자 목록인 벡터로 나타내 저장해 두고, 질문의 벡터와 가까운 글을 찾는 데 쓰는 색인입니다.

PDF와 HWP 문서의 표는 어떻게 처리하나요?

HWP 문서는 HWPX로 다시 저장하면 표의 칸마다 위치를 붙여 읽을 수 있습니다. PDF의 표는 행과 열 구조가 사라지기 쉬우므로, 표의 수치는 학술지 XML이나 원래의 엑셀 파일처럼 표 구조가 남은 형식에서 확인하는 편이 안전합니다.

옛 HWP 파일은 내용을 XML처럼 글자로 적지 않고 프로그램 전용 데이터로 저장하는 이진 형식이며(한글과컴퓨터), 시제품은 이 형식을 직접 읽지 않습니다. 같은 논문을 PDF와 학술지 XML로 읽어 비교한 결과는 "AI는 논문 PDF의 표에서 수치를 제대로 읽을 수 있나요?"에 정리했습니다.

같은 문서를 넣으면 AI가 매번 같은 결과를 내나요?

아니요. 2026년 9월 29일 아모프 창업팀이 같은 논문을 같은 외부 모델에게 세 번 읽게 했을 때, 정해 둔 목록 형식으로 읽어 낼 수 있었던 답은 세 번 가운데 한 번뿐이었습니다.

외부 모델은 다른 회사가 인터넷으로 제공하는 AI 모델입니다. 나머지 두 번은 답의 원문이 남지 않아 원인을 확인하지 못했지만, 같은 입력에서도 결과가 실행마다 달랐으므로 AI가 읽은 결과는 기록하기 전에 사람이 원문과 대조해야 합니다.

RAG와 파인튜닝은 무엇이 다른가요?

파인튜닝은 이미 학습된 모델을 특정 작업의 자료로 더 학습시키는 방법이고, RAG는 답할 때마다 모델 밖의 자료를 찾아 모델에게 건네는 방법입니다. 그래서 RAG에서는 문서가 바뀌어도 모델을 다시 학습시키지 않고, 찾는 자료만 바꿔 답의 근거를 바꿀 수 있습니다. 두 방법을 비교한 연구는 "RAG란? 검색 증강 생성의 뜻과 작동 순서, 한계"에서 다룹니다.

사내 문서를 외부 AI로 보내지 않고 RAG를 만들 수 있나요?

문서를 읽고 정해진 형식의 문장에서 수치를 확인하는 일은 외부 AI 없이도 할 수 있지만, 자유로운 질문에 답하려면 회사 안에 둔 서버 컴퓨터에 언어 모델을 설치해야 합니다. 언어 모델은 글을 읽고 쓰도록 학습된 AI 모델이며, 이렇게 문서를 회사 밖으로 보내지 않고 만드는 RAG를 흔히 로컬 RAG라고 부릅니다.

시제품은 실행 환경에서 외부 AI 호출을 허용하고 화면에서 외부 모델을 고른 경우에만 그 모델을 부르며, 고른 뒤의 요청부터 질문과 함께 그 대화에 올린 문서의 글과 확정 지식이 그 모델로 전송됩니다.

회사 안에 설치한 모델로 이 시제품을 시험한 결과는 없습니다.

RAG를 만들 때 하지 않는 것

아모프는 근거를 되짚을 수 없는 답을 줄이기 위해, RAG를 만들 때 다음 다섯 가지를 하지 않습니다.

• 뜻이 비슷한 말로 바꾼 문장을 인용으로 인정하지 않습니다.
• AI가 옮겨 적은 글을 원문인 것처럼 근거로 보여 주지 않습니다.
• 문서 안에 숨은 지시문을 AI가 따르더라도, 파일이나 지식 원장이 바뀌는 길을 열어 두지 않습니다. 문서나 웹 페이지에 지시를 숨겨 AI를 조종하는 공격을 프롬프트 인젝션이라고 하며, 소프트웨어 보안 자료를 공개하는 비영리 재단 OWASP는 대형 언어 모델(LLM) 애플리케이션의 10대 위험 2025년판에서 이를 첫째 위험으로 꼽았습니다(OWASP, 2025).
• 모델 호출이 실패하면 다른 모델의 답으로 바꾸지 않고, 실패했다고 알립니다.
• AI가 읽어 내지 못한 표의 줄을 조용히 빠뜨리지 않고, 어느 줄이 빠졌는지 알립니다.

이 글은 AX의 뜻, AX가 DX와 다른 점, AX라는 약자가 무엇을 줄인 말인지를 먼저 정리합니다. 이어서 기술 문서가 많은 회사가 AX를 무엇부터 시작하면 좋은지를, 아모프 창업팀이 만든 지식 AI 시제품을 시험하며 겪은 일을 바탕으로 설명합니다. 이 시제품은 문서를 근거로 답하고 사람이 확인한 내용만 기록하도록 만든 소프트웨어입니다. 기술 문서는 규격서, 시험 성적서, 논문처럼 제품과 실험의 조건과 수치를 적은 문서입니다. 규격서는 제품이나 재료가 갖춰야 할 조건을 적은 문서이고, 시험 성적서는 제품이나 재료를 시험한 결과를 적은 문서입니다.

AX와 DX는 무엇이 다른가요?

DX(디지털 전환)는 종이와 수작업으로 하던 아날로그 업무 절차를 디지털로 옮기는 데 중점을 두고, AX는 그렇게 디지털로 옮겨 둔 업무 절차를 AI로 지능화하고 자율화하는 데 중점을 둡니다(국토연구원 국토용어해설, 2025). 그래서 AX는 DX를 대신하는 일이 아니라, DX로 쌓아 둔 디지털 자료를 바탕으로 시작하는 다음 단계입니다.

기술 문서 업무로 보면, DX는 문서를 파일로 바꿔 찾기 쉽게 만드는 일이고, AX는 그 파일 속 수치를 근거와 함께 읽어 업무 판단에 쓰게 하는 일입니다. 아래 표의 "기술 문서 업무의 예"는 설명을 위해 만든 예입니다.

AX의 X는 무엇을 뜻하나요?

AX의 X는 전환을 뜻하는 영어 단어 Transformation을 가리키며, AX는 AI Transformation을 줄인 말입니다(국토연구원 국토용어해설, 2025). 디지털 전환을 뜻하는 DX도 Digital Transformation을 줄인 말이어서, 두 약자의 X는 같은 단어를 가리킵니다(KT Enterprise, 2026년 10월 23일 확인).

과학기술정보통신부도 2024년 12월 29일 게시한 보도자료의 제목에서 AX를 "인공지능 대전환(AX, AI Transformation)"으로 풀어 썼습니다(과학기술정보통신부, 2024). 같은 보도자료의 본문 각주는 AX를 "AI+X"로 적고, 특정 분야에 한정된 인공지능 활용을 넘어 산업, 공공, 사회, 지역, 국방에 이르는 국가 전반의 인공지능 대전환이라고 설명했습니다.

"AX 전환"이라는 말도 쓰이는데(김예림, 한빛미디어 공식 블로그, 2026), AX의 X가 이미 전환을 뜻하므로 이 말은 AI 전환과 같은 뜻으로 읽으면 됩니다.

AX와 AI는 무엇이 다른가요?

AI는 글을 읽고 판단하는 일처럼 사람이 하던 지적인 일을 컴퓨터가 하도록 만든 기술의 이름이고, AX는 그 기술로 회사의 업무 절차와 일하는 방식을 바꾸는 일의 이름입니다.

그래서 아모프는 AI 도구를 들여오는 일만으로 AX가 끝난다고 보지 않으며, AI가 맡을 업무 절차와 그 결과를 확인할 사람을 함께 정해야 한다고 봅니다. 예를 들어 문서를 요약하는 AI 도구를 들여와도, 요약한 내용을 누가 확인하고 어디에 기록할지 정하지 않으면 업무 절차는 그대로 남습니다.

기술 문서가 많은 회사의 AX는 무엇부터 시작하나요?

아모프는 AI에게 일을 맡기기 전에, 어떤 문서의 어떤 사실을 회사의 기록으로 삼을지와 그 기록을 누가 확인할지부터 정하기를 권합니다. 기록할 사실과 확인할 사람이 정해져 있어야 AI가 읽어 낸 내용이 맞는지 따질 기준이 생기기 때문입니다.

구체적으로는 아래 네 가지를 차례로 살펴봅니다.

• 문서 형식을 먼저 확인합니다. HWPX는 워드프로세서 한글로 만든 문서의 문단과 표를 XML이라는 구조화된 글 형식으로 담는 파일 형식입니다. 시제품은 HWPX 문서의 표를 칸 위치까지 읽지만, 예전 형식인 HWP 파일은 HWPX로 다시 저장해야 읽습니다.
• PDF의 표는 행과 열이 사라진 글 줄로 읽힐 수 있으므로, 같은 자료를 다른 형식으로 구할 수 있는지 찾아봅니다. 아모프 창업팀이 같은 논문을 두 형식으로 읽어 비교한 결과는 "AI는 논문 PDF의 표에서 수치를 제대로 읽을 수 있나요?"에 정리했습니다.
• 기록의 종류와 확인 담당자를 정합니다. 온톨로지는 업무에서 쓰는 개념과 개념 사이의 관계를 미리 정해 둔 지식 구조이며, 기록을 어떤 종류로 나누고 누가 확인할지는 "온톨로지 구축 방법: 기술 문서와 실험 기록을 지식으로 바꾸는 5단계"에서 다룹니다.
• 외부 모델에 문서를 보내도 되는 범위를 정합니다. 외부 모델은 다른 회사가 인터넷으로 제공하는 AI 모델이며, 이런 모델을 쓰면 질문과 문서의 내용이 그 모델을 제공하는 회사로 전송됩니다.

문서 업무에 AI를 쓰면 어떤 문제가 생기나요?

아모프 창업팀이 시제품을 시험하며 거듭 겪은 문제는 두 가지였습니다. AI가 근거의 위치를 틀리게 적는 일과, 같은 문서를 읽을 때마다 결과가 달라지는 일입니다.

기록 후보는 AI가 문서에서 읽어 내 기록하자고 제안했지만 아직 사람이 확정하지 않은 내용입니다. 아모프 창업팀이 2026년 9월 22일 공개 논문을 외부 모델 하나에게 읽혔을 때, AI가 제안한 기록 후보 3건은 모두 원문 위치를 틀리게 적었습니다.

3건 모두 인용문이 적힌 위치의 원문에 글자 그대로 있지 않아 근거로 인정되지 않았습니다.

아모프 창업팀이 2026년 9월 29일 같은 논문 한 편을 같은 외부 모델에게 세 번 읽게 했을 때는, 정해 둔 목록 형식으로 읽어 낼 수 있었던 답이 세 번 가운데 한 번뿐이었습니다. RAG(검색 증강 생성)는 AI가 답을 쓰기 전에 관련 문서를 찾아 근거로 삼게 하는 방식이며, AI의 답을 원문과 대조하는 순서는 "RAG 구축 방법: 출처를 밝히며 답하는 AI를 만드는 5단계"에 정리했습니다.

두 시험 모두 한 컴퓨터에서 시제품으로 한 것이므로, 다른 모델이나 다른 문서에서도 같은 비율로 문제가 생긴다는 뜻은 아닙니다.

AI가 정리한 내용을 바로 회사 기록으로 써도 되나요?

아니요. 아모프는 AI가 정리한 내용을 담당자가 근거와 함께 확인한 뒤에만 회사의 기록으로 삼기를 권합니다. 시제품에서도 검사를 통과한 기록 후보는 담당자가 확정 버튼을 눌러야 기록되며, 채팅에서 "맞다"고 답한 것만으로는 아무것도 기록되지 않습니다.

시제품이 기록을 남기는 곳은 지식 원장입니다. 지식 원장은 사람이 확인한 기록만 시간 순서대로 덧붙여 쌓는 데이터베이스입니다. 이미 들어간 기록은 고치거나 지우지 않고, 바뀐 내용은 정정 기록으로 덧붙입니다.

아모프가 돕는 AX

아모프는 엔지니어링 회사와 연구소의 기술 문서와 실험 기록을 정리해, 근거를 보여 주며 답하는 AI 소프트웨어를 고객사에 맞춰 개발합니다. 아모프가 제공하는 서비스와 맡지 않는 일은 "엔지니어링 회사와 연구소를 위한 AX 컨설팅"에 정리했습니다.

자주 혼동하는 것

AX라는 약자는 AI 전환 말고 다른 뜻으로도 쓰이므로, 글마다 어떤 뜻으로 썼는지 확인해야 합니다.

• 사용자 경험(UX) 분야의 연장선에서 AX를, 사용자가 AI 에이전트와 어떻게 상호작용하며 어떤 경험을 하는지 설계하는 일을 뜻하는 "에이전트 경험(Agent Experience)"으로 쓰기도 합니다(김예림, 한빛미디어 공식 블로그, 2026). AI 에이전트는 언어 모델(글을 읽고 이어질 글을 만들어 내는 AI 모델)에 도구와 규칙을 묶어, 사람의 요청이나 정해 둔 시각·사건에 따라 여러 단계의 일을 이어 처리하는 프로그램입니다. 같은 글도 실제로는 AI 전환이라는 뜻이 훨씬 많이 쓰인다고 적었으며, 이 글의 AX도 AI 전환을 뜻합니다.
• 회사나 조직의 이름에 AX가 들어 있다면, 그것은 그 조직의 고유한 이름이므로 AI 전환이라는 일반 용어와 구별해서 읽어야 합니다.

여기서 시료는 실험에 쓰는 재료의 견본이고, 관측값은 실험에서 재거나 보고한 값이며, 아래에서는 관측값 하나를 담는 기록을 줄여서 관측이라고 부릅니다. 이 글은 온톨로지의 뜻과 말의 유래, 구성 요소를 정리하고, 온톨로지가 지식 그래프(실제 대상과 사실을 이어 놓은 자료)나 데이터베이스 스키마(자료를 저장할 표와 칸의 구조)와 무엇이 다른지 설명합니다. 온톨로지를 만드는 순서는 "온톨로지 구축 방법: 기술 문서와 실험 기록을 지식으로 바꾸는 5단계"에서 따로 다룹니다.

온톨로지와 지식 그래프는 무엇이 다른가요?

온톨로지는 어떤 종류의 대상과 관계가 있는지 정한 틀이고, 지식 그래프는 그 틀에 따라 실제 대상과 사실을 이어서 쌓은 자료입니다.

연구자 18명이 학술지 ACM Computing Surveys에 실은 지식 그래프 개론 논문은, 지식 그래프를 실제 세계의 지식을 모으고 전하기 위한 데이터의 그래프로 정의합니다. 이 그래프에서 점은 관심 있는 대상을, 점을 잇는 선은 대상 사이의 관계를 나타내고, 온톨로지 같은 지식 표현 방식은 점과 선에 붙은 용어의 뜻을 정의하는 데 쓰일 수 있다고 설명합니다(Hogan 외, 2021).

아모프 창업팀이 만든 지식 AI 시제품에서는 온톨로지가 시료, 실험, 관측이라는 기록의 종류와 그 관계를 정하고, 지식 그래프는 사람이 확인한 기록을 그 틀에 따라 이어서 보여 줍니다. 아직 확인되지 않은 후보는 "확인 대기"로 따로 표시해 확정된 지식과 섞이지 않게 합니다.

정리하면 온톨로지는 틀이고, 지식 그래프는 그 틀을 채운 내용입니다. 두 가지를 나란히 놓으면 다음과 같습니다.

다만 두 말의 경계가 늘 뚜렷하지는 않습니다. 앞의 논문은 지식 그래프가 "모든 수도는 도시다"처럼 여러 대상에 한꺼번에 해당하는 지식까지 담으려면 온톨로지나 규칙 같은 표현 방식이 필요하다고 설명합니다. 그래서 실제 지식 그래프에는 개별 사실과 함께 온톨로지가 들어 있기도 합니다(Hogan 외, 2021).

지식 그래프가 무엇으로 이루어지고 시소러스나 택소노미와 어떻게 다른지는 "지식 그래프란? 뜻과 시소러스·택소노미와의 차이"에서 다룹니다.

온톨로지라는 말은 어디에서 왔나요?

온톨로지는 철학에서 빌려 온 말입니다. 철학에서 온톨로지(존재론)는 존재하는 것에 대한 체계적인 설명을 뜻하며, 컴퓨터 과학에서는 한 분야에 무엇이 있고 서로 어떤 관계인지를 분명하게 적어 둔 명세라는 뜻으로 씁니다(Gruber, 1993).

스탠퍼드 대학의 그루버는 1993년 논문에서 온톨로지를 "개념화의 명시적 명세"로 정의했습니다. 개념화는 관심 있는 분야에 있다고 보는 대상과 개념, 그리고 그 사이의 관계를 단순하게 정리한 세계의 모습이고, 명세는 그것을 여러 사람과 프로그램이 같은 뜻으로 쓸 수 있게 분명하게 적어 둔 설명입니다(Gruber, 1993).

웹 표준을 만드는 국제 비영리 단체 W3C도 온톨로지를 형식을 갖춘 용어의 어휘라고 설명합니다. 이 어휘는 흔히 한 분야를 다루고 한 사용자 집단이 함께 쓰며, 각 용어의 뜻은 같은 온톨로지 안의 다른 용어와 어떤 관계인지를 적어서 정합니다(W3C OWL 2 개요, 2012).

온톨로지는 무엇으로 이루어지나요?

온톨로지는 개념의 종류를 나타내는 클래스, 클래스가 가진 특징을 적는 속성, 속성이 가질 수 있는 값의 종류나 개수를 정하는 제약으로 이루어지며, 개념 사이의 관계도 이 안에서 정의합니다. 여기에 클래스에 속하는 실제 사례인 인스턴스를 더하면 지식 베이스가 됩니다(Noy·McGuinness, 2001).

실험 기록을 다루는 온톨로지를 예로 들면, 각 요소는 다음과 같습니다.

• 클래스는 시료, 실험, 관측 같은 기록의 종류입니다.
• 속성은 관측의 값과 단위, 시험법, 측정한 값인지 계산한 값인지를 적는 산출 방식 같은 칸입니다.
• 관계는 "실험은 시료를 쓴다", "실험에서 관측이 나온다"처럼 기록의 종류 사이를 잇습니다.
• 제약의 예로, 산출 방식 칸에는 "측정", "계산", "미상" 가운데 하나만 적게 할 수 있습니다.
• 인스턴스는 사람이 확인해 확정한 기록 하나하나입니다.

온톨로지와 데이터베이스 스키마는 무엇이 다른가요?

데이터베이스 스키마는 자료를 저장할 표와 칸의 구조를 정하고, 온톨로지는 그 자료가 무엇을 뜻하며 서로 어떤 관계인지를 정합니다.

온톨로지를 적는 W3C의 표준 언어인 OWL의 입문서는, 온톨로지의 용어 정의는 데이터베이스 스키마와, 개별 사실은 데이터베이스의 내용과 비슷하게 볼 수 있지만 둘이 전제하는 바는 다르다고 설명합니다. 데이터베이스는 보통 기록에 없는 사실을 거짓으로 보지만, OWL 문서에서는 적혀 있지 않은 사실도 참일 수 있다고 봅니다. 그러면서도 기술적으로는 많은 온톨로지 중심 시스템에서 데이터베이스가 충분히 쓸 만한 바탕이 된다고 덧붙입니다(W3C OWL 2 입문서, 2012).

그래서 기록은 데이터베이스의 표에 저장하고, 각 칸이 표준 어휘의 어떤 개념에 해당하는지를 따로 적어 두는 방식도 쓰입니다. 표준 어휘는 표준 단체나 비영리 단체가 개념과 관계에 이름을 붙여 공개한 목록입니다. 예를 들어 관측과 센서를 기술하려고 W3C와 지리 공간 정보 표준 단체 OGC가 함께 만든 SOSA/SSN 어휘에는 관측(sosa:Observation)이라는 개념이 있습니다(W3C·OGC, 2017).

RDF는 사실 하나를 주어, 술어, 목적어의 세 부분으로 적는 W3C의 데이터 형식입니다. W3C는 관계형 데이터베이스(자료를 행과 열로 이루어진 표에 저장하는 데이터베이스)의 내용을 RDF로 옮기는 규칙을 적는 언어 R2RML을 2012년에 권고안(W3C가 표준으로 확정한 문서)으로 발표했습니다(W3C R2RML, 2012).

AI를 쓸 때 온톨로지가 왜 필요한가요?

AI가 문서에서 읽은 값이 어느 시료, 어느 실험, 어떤 조건의 값인지 온톨로지라는 정해진 틀에 담겨 있어야, AI가 조건이 다른 값을 섞지 않고 답할 수 있기 때문입니다.

OWL 입문서도 한 분야를 이렇게 정확하게 기술해 두면 사람 사이의 오해를 막고, 소프트웨어가 한결같고 예측할 수 있게 동작하며 다른 소프트웨어와도 잘 연동되게 한다고 설명합니다(W3C OWL 2 입문서, 2012).

아모프 창업팀이 2026년 9월 24일 논문 한 편을 PDF로 읽었을 때는 표의 값과 열의 머리글이 서로 떨어져 읽혀, 글만 보고는 어느 값이 어느 열의 값인지 확실히 알 수 없었습니다. 자세한 비교는 "AI는 논문 PDF의 표에서 수치를 제대로 읽을 수 있나요?"에 정리했습니다. 값과 그 값의 조건을 잇는 틀이 없으면 AI도 조건이 다른 값을 섞기 쉬우므로, 실험마다 시료와 설비, 실험 조건을 함께 기록해 두고 질문의 조건과 맞춰 봐야 합니다. 그래야 질문한 온도가 실험한 온도 범위 안에 든다는 이유만으로 다른 설비에서 나온 결과를 적용하지 않고, 판단에 필요한 정보가 없을 때 무엇이 부족한지도 알 수 있습니다.

팔란티어 온톨로지도 같은 뜻인가요?

낱말은 같지만 가리키는 범위가 다릅니다. 팔란티어(Palantir)의 문서는 자사 플랫폼 Foundry의 온톨로지를, 플랫폼에 통합된 데이터셋(자료 묶음)과 모델 위에 놓여 이들을 실제 세계의 대상과 이어 주는 조직의 "운영 레이어"라고 설명합니다. 또 이 온톨로지가 오브젝트와 속성과 링크 같은 의미 요소에 더해, 액션과 함수 같은 동작 요소까지 담는다고 적습니다(Palantir 문서).

팔란티어 온톨로지가 OWL로 적는 전통적인 온톨로지와 무엇이 다른지는 "팔란티어 온톨로지는 일반 온톨로지와 무엇이 다른가요?"에서 자세히 다룹니다.

온톨로지를 만드는 순서

아모프는 답할 질문 정하기, 기록의 종류 나누기, 값마다 출처 적기, 표준 어휘에 대응시키기, 사람이 확인한 것만 남기기의 다섯 단계로 온톨로지를 만듭니다. 단계마다 무엇을 하는지는 "온톨로지 구축 방법: 기술 문서와 실험 기록을 지식으로 바꾸는 5단계"에 정리했습니다.

온톨로지와 자주 혼동하는 것

온톨로지와 헷갈리기 쉬운 것은 이름이 같은 철학의 존재론과 블록체인 프로젝트 "온톨로지(Ontology)", 그리고 지식 그래프의 한 예인 "구글 지식 그래프"입니다.

• 철학의 존재론은 온톨로지라는 말의 출처이지만, 이 글의 온톨로지는 컴퓨터가 읽는 지식 구조를 뜻합니다.
• 블록체인 프로젝트 "온톨로지(Ontology)"와 그 프로젝트의 암호화폐 ONT는 이름만 같을 뿐, 이 글의 온톨로지와는 관계가 없습니다(Ontology).
• "구글 지식 그래프"는 지식 그래프의 한 예입니다. 구글에서 사람이나 장소, 조직을 검색하면 나오는 정보 상자인 지식 패널은 이 지식 그래프에 있는 대상에 대해 표시됩니다(Google 고객센터).

가이드 보컬은 곡을 부를 가수에게 멜로디와 가사의 느낌을 전하려고 정식 녹음 전에 먼저 불러 둔 참고용 녹음이고, 허밍은 가사 없이 입을 다문 채 멜로디만 소리 내어 부르는 것입니다. 이 글은 의뢰인과 대상 가수의 신원을 밝히지 않고, 의뢰인이 겪은 문제와 해결 방법, 그 결과를 차례로 정리합니다.

남성이 녹음한 허밍을 여가수 목소리로 바꿀 수 있나요?

이번 의뢰에서는 바꿀 수 있었습니다. 아모프 창업팀은 원본의 멜로디와 호흡, 표현을 먼저 분석한 뒤 대상 가수에 맞춘 변환 과정을 설계해, 실제 여가수가 부른 듯한 자연스러운 녹음본을 만들었습니다.

이 답은 이번 의뢰에 한정됩니다. 다른 목소리나 다른 곡에서도 같은 결과가 나온다고 이 사례만으로 말할 수는 없습니다.

문제: 음색과 음역, 발성의 차이가 컸습니다

의뢰인은 남성 목소리로 녹음한 허밍이나 가이드 보컬을 실제 여가수의 목소리로 바꾸고 싶어 했습니다. 음색과 음역, 발성의 차이가 큰 만큼, 원본의 멜로디와 뉘앙스를 유지하면서 자연스러운 결과를 얻는 것이 중요했습니다.

• 음색은 같은 높이의 음을 내도 사람마다 다르게 들리는 목소리의 고유한 특징입니다.
• 음역은 목소리로 낼 수 있는 가장 낮은 음부터 가장 높은 음까지의 범위입니다.
• 발성은 숨과 목을 써서 목소리를 내는 방식입니다.

해결: 멜로디와 호흡, 표현을 먼저 분석했습니다

아모프 창업팀은 원본의 멜로디와 호흡, 표현을 세밀하게 분석한 뒤, 대상 가수의 음색과 발성 특성이 자연스럽게 이어지도록 맞춤형 변환 과정을 설계했습니다.

결과: 남성의 허밍만으로 여가수가 부른 듯한 녹음본을 만들었습니다

아모프 창업팀은 남성의 허밍이나 가이드 녹음만으로도 실제 여가수가 부른 듯한 자연스러운 녹음본을 만들 수 있었습니다.

여성의 가이드 보컬을 남성 가수 목소리로 바꿀 수도 있나요?

아모프 창업팀은 같은 방식으로 여성의 허밍이나 가이드 보컬을 남성 가수의 목소리로 바꾸는 반대 성별 변환도 가능하도록 구성했습니다. 다만 이 사례에서 실제 결과물로 나온 것은 남성의 녹음을 여가수의 목소리로 바꾼 녹음본입니다.

Suno(수노)는 만들고 싶은 노래의 장르와 분위기를 글로 설명하거나 직접 쓴 가사를 넣으면, 보컬과 악기 연주가 갖춰진 노래를 만들어 주는 AI 음악 생성 서비스입니다(Suno 공식 사이트, 2026년 10월 23일 확인). 이 글은 의뢰인과 곡의 정보를 밝히지 않고, 의뢰인이 겪은 문제와 해결 방법, 그 결과를 차례로 정리합니다.

Suno 보컬을 실제 사람의 목소리로 바꿀 수 있나요?

이번 의뢰에서는 바꿀 수 있었습니다. 의뢰인은 상용 도구로 목소리를 덧입혔을 때 쇳소리 같은 잡음이 섞여 어려움을 겪었지만, 아모프 창업팀이 생성된 보컬을 분석해 맞춤형 변환 과정을 개발한 뒤로는 추가 녹음 없이, 생성된 보컬 파일만으로 작업할 수 있게 되었습니다.

이 답은 이번 의뢰에 한정됩니다. 다른 목소리나 다른 곡으로 Suno 목소리 변경을 할 때도 같은 결과가 나온다고 이 사례만으로 말할 수는 없습니다.

문제: 상용 도구로 덧입힌 보컬에 쇳소리와 음이탈이 섞였습니다

의뢰인은 Suno로 만든 노래의 보컬을 실제 인물의 목소리로 바꾸고 싶어 했습니다. 그래서 기존 상용 도구로 목소리를 학습시켜 Suno가 분할한 보컬에 덧입혀 보았지만, 쇳소리나 음이탈 같은 잡음이 섞여 나와 작업에 어려움을 겪고 있었습니다.

• 보이스 클로닝은 어떤 사람의 목소리를 AI에 학습시켜, 그 목소리로 새 음성을 만들거나 다른 음성을 그 목소리로 바꾸는 기술입니다. 의뢰인이 상용 도구로 목소리를 학습시킨 것도 이런 방식이었습니다.
• 분할한 보컬은 완성된 노래에서 보컬만 따로 떼어 낸 파일입니다. 이번 의뢰에서 보컬을 떼어 낸 것은 Suno였고, 아모프 창업팀이 개발한 것은 생성된 보컬을 실제 인물의 목소리로 바꾸는 변환 기술과 작업 과정이었습니다.
• 음이탈은 노래하는 음이 의도한 음높이에서 벗어나는 현상입니다.

해결: 생성된 보컬을 분석해 맞춤형 변환 과정을 직접 개발했습니다

아모프 창업팀은 생성된 보컬의 특성을 정밀하게 분석하고, 실제 인물의 음색과 표현이 자연스럽게 살아나도록 맞춤형 변환 기술과 작업 과정을 직접 개발했습니다.

추가 녹음 없이 생성된 보컬만으로 작업할 수 있게 되었나요?

네. 의뢰인은 번거로운 추가 녹음 없이, 생성된 보컬 파일만으로 편안하게 작업할 수 있는 환경을 갖추게 되었습니다.

이 결과는 아모프 창업팀이 의뢰인을 직접 찾아가 막힌 부분에 대한 이야기를 듣고, 여러 해결 방법을 검토한 끝에 얻은 성과입니다.