처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
GitHub 2026.08.11 45

[심층분석] AI의 결정에 git blame을 달다 — '오픈소스 팔란티어'를 표방하는 Semantica

GitHub 원문 보기

혹시 회사에서 LLM 기반 챗봇이나 에이전트를 만들어보신 적 있나요? 데모까지는 정말 잘 돌아가요. 그런데 실제 서비스에 올리려고 하면 꼭 이런 질문이 날아오거든요. 'AI가 왜 그렇게 판단했는지 설명할 수 있어요?' 여기서 대부분 말문이 막혀요. LLM은 확률적으로 답을 생성하는 모델이라 같은 질문에도 매번 다른 답이 나올 수 있고, 그 답이 어떤 근거에서 나왔는지 추적하기가 정말 어렵거든요.

오늘 소개할 Semantica는 바로 이 문제를 정면으로 겨냥한 오픈소스 프로젝트예요. 스스로를 'AI 에이전트를 위한 오픈소스 팔란티어(Palantir)'라고 소개하는데요. 팔란티어가 뭐냐면, 미국 정부 기관과 대형 금융사들이 쓰는 데이터 분석 플랫폼 회사예요. 조직 곳곳에 흩어진 데이터를 하나의 의미 체계로 묶어서 의사결정에 쓰게 해주는 걸로 유명한데, 가격이 어마어마하고 완전히 폐쇄적이죠. Semantica는 그 핵심 아이디어를 오픈소스로, 그것도 AI 에이전트 시대에 맞게 다시 만들겠다는 프로젝트인 거예요.

'임베딩이 아니라 의미를 저장한다'는 게 무슨 말일까요

Semantica의 문제의식은 한 문장으로 요약돼요. '대부분의 AI 에이전트는 흔적 없이 행동한다. 의미가 아니라 임베딩을 저장하기 때문에, 설명할 수 없는 컨텍스트와 감사할 수 없는 결정만 남는다.'

이게 뭐냐면요. 지금 널리 쓰이는 RAG(검색 증강 생성) 방식은 문서를 잘게 쪼개서 벡터, 그러니까 숫자 배열로 바꾼 다음 질문과 '비슷한 느낌'의 조각을 찾아 LLM에게 건네주는 구조예요. 비유하자면 도서관 사서가 '이 책이랑 분위기 비슷한 책들'을 감으로 찾아주는 거죠. 빠르고 편하지만, '이 저자가 저 책을 인용했고, 그 책은 이 시리즈의 2권이다' 같은 정확한 관계는 몰라요. 벡터 유사도는 '가깝다'는 것만 알려주지 '왜 관련 있는지'는 설명하지 못하거든요.

Semantica는 여기에 지식 그래프(Knowledge Graph)와 컨텍스트 그래프(Context Graph)를 도입해요. 지식 그래프가 뭐냐면, 정보를 점(개체)과 선(관계)으로 저장하는 방식이에요. '김대리 —[소속]→ 여신심사팀', '이 대출 —[담보]→ 이 아파트'처럼요. 이렇게 저장해두면 나중에 'AI가 이 대출을 승인한 근거가 뭐야?'라고 물었을 때, 그래프의 연결을 따라가며 근거를 하나하나 짚어줄 수 있어요. 느낌이 아니라 구조로 답하는 거죠.

아키텍처: LLM '아래'에 깔리는 결정론적 인프라

Semantica가 스스로를 설명하는 방식이 재밌는데요, LLM이나 벡터 스토어, 에이전트 프레임워크를 대체하는 게 아니라 그 아래에 깔리는 인프라 레이어라고 해요. 파이프라인은 대략 이런 흐름이에요.

  • 수집(Ingest): 사내 문서, DB 같은 엔터프라이즈 데이터를 받아들이고
  • 추출(Extract): 그중 의미 있는 개체와 관계를 뽑아내서
  • 그래프 구축: 컨텍스트 그래프와 지식 그래프를 만들고
  • 추론과 분석: 그 위에서 그래프 분석과 인과 추론(causal reasoning)을 돌리는데
  • 결정 이력(Decision Provenance): 이 모든 과정이 처음부터 끝까지 추적 가능하게 기록돼요
  • 여기서 눈여겨볼 설계 철학이 두 가지예요.

    첫째, 그래프 구축과 추론에 LLM이 필수가 아니에요. 요즘 나오는 GraphRAG류 도구들은 대부분 LLM에게 '이 문서에서 개체와 관계를 뽑아줘'라고 시키는데, 이러면 그래프 자체가 확률적으로 만들어져요. 오늘 만든 그래프와 내일 만든 그래프가 다를 수 있다는 거죠. Semantica는 결정론적(deterministic), 그러니까 같은 입력이면 항상 같은 결과가 나오는 방식을 기본으로 해요. 감사(audit)가 필요한 환경에서는 이게 굉장히 중요하거든요. LLM 호출이 줄어드니 비용 면에서도 유리하고요.

    둘째, 결정 이력이 기본 내장이에요. 개발자에게 익숙한 비유로 하면, AI의 의사결정에 git blame을 붙이는 거예요. README가 드는 예시가 대출 심사인데요. 심사 에이전트가 내린 승인 결정은 몇 달 뒤 규제 당국이 '왜 승인했죠?'라고 물었을 때 살아남아야 해요. 금융권에서 이건 불편함이 아니라 컴플라이언스 리스크, 즉 법적 문제거든요.

    기술적으로는 RDF와 LPG를 둘 다 지원하는 '폴리글랏 그래프 저장소'를 표방해요. RDF는 W3C 표준으로 '주어-술어-목적어' 세 쌍(트리플)으로 지식을 표현하는 방식이고, LPG는 Neo4j 같은 그래프 DB가 쓰는 '속성이 붙은 노드와 엣지' 방식이에요. 표준·학계 진영과 실무 진영에서 각각 주류인 두 방식을 모두 품겠다는 건데, 상호운용성 면에서 꽤 실용적인 선택이에요. 설치는 pip install semantica 한 줄이고, 저장소를 보면 MCP 서버, 그래프를 시각적으로 탐색하는 Knowledge Explorer, 각종 프레임워크 연동, 예제 모음(cookbook)까지 갖춰져 있어요.

    업계 맥락: 왜 지금 '컨텍스트 그래프'일까요

    비슷해 보이는 기술들과 비교해보면 포지션이 선명해져요.

  • Microsoft GraphRAG와 비교하면: GraphRAG는 검색 품질을 높이기 위한 '기법'에 가깝고, 그래프 생성 자체를 LLM에 맡겨요. Semantica는 결정론적 생성을 기본으로 하고, 검색을 넘어 거버넌스와 감사까지 포괄하는 '인프라'를 지향해요.
  • LangChain, LlamaIndex와 비교하면: 이들은 오케스트레이션 프레임워크예요. 오케스트레이션이라는 건, 쉽게 말해 여러 단계의 작업을 순서대로 지휘하는 거고요. Semantica는 그 프레임워크들 아래에서 컨텍스트와 데이터를 책임지는 층이라, 경쟁이 아니라 조합 관계에 가까워요.
  • Neo4j와 비교하면: Neo4j는 그래프를 담는 데이터베이스 그 자체예요. Semantica는 DB 위에 온톨로지 관리, 추론 엔진, 결정 이력까지 얹은 플랫폼이고요. 온톨로지가 뭐냐면, 우리 조직에서 '고객', '계약', '담보' 같은 개념이 정확히 뭘 의미하고 서로 어떤 관계인지 정의해둔 '개념 사전'이에요.
  • 팔란티어와 비교하면: 방향성은 비슷한데 오픈소스, 셀프호스팅, 벤더 종속 없음이라는 정반대의 배포 전략을 택했어요.
타이밍도 절묘해요. EU AI Act처럼 고위험 AI에 설명 가능성을 요구하는 규제가 현실이 됐고, 업계의 관심도 '프롬프트를 잘 쓰는 법'에서 '모델에게 어떤 컨텍스트를 어떻게 공급할 것인가', 이른바 컨텍스트 엔지니어링으로 옮겨가는 중이거든요. Semantica는 그 흐름의 인프라 쪽 답안인 셈이에요.

한국 개발자에게 주는 시사점

한국은 금융, 의료, 공공처럼 규제가 강한 산업의 IT 비중이 유난히 높은 나라잖아요. 특히 금융권 망분리 환경에서는 외부 SaaS를 못 쓰는 경우가 많아서, 셀프호스팅 가능한 오픈소스라는 점이 실질적인 장점이 돼요.

구체적인 시나리오를 하나 들어볼게요. 지금 사내 규정 문서로 RAG 챗봇을 운영 중인데 '답변 근거를 제시하라'는 요구를 받았다면, 기존 파이프라인을 갈아엎는 대신 Semantica로 규정 문서의 개체와 관계를 그래프로 뽑아두고, 답변할 때 그래프 경로를 근거로 함께 보여주는 구조를 실험해볼 수 있어요. MCP 서버가 포함돼 있으니 Claude 같은 에이전트에 도구로 연결하는 것도 자연스럽고요.

학습 로드맵은 이렇게 제안드려요. ① 그래프 DB 기초부터: Neo4j의 Cypher나 RDF의 SPARQL 중 하나로 그래프 질의 감각을 익히고 ② 온톨로지 개념을 가볍게 훑은 다음 ③ pip install semantica 후 cookbook 예제를 따라 해보고 ④ 기존 RAG 파이프라인의 일부 문서에만 병렬로 적용해 비교해보는 순서예요.

다만 냉정하게 볼 부분도 있어요. 온톨로지 설계는 결국 도메인을 아는 사람이 해야 하는 일이라 초기 모델링 비용이 들고, 벡터 검색만큼 도입이 가볍지 않아요. 아직 신생 프로젝트라 성숙도와 커뮤니티 지속성도 지켜봐야 하고요. '모든 RAG를 그래프로 바꾸자'가 아니라, 설명 책임이 무거운 영역부터 선별 적용하는 게 현실적이에요.

마무리

지난 몇 년이 '더 큰 모델'의 시대였다면, 지금은 '설명할 수 있는 인프라'가 화두로 올라오는 시기예요. AI가 실제 돈과 사람의 권리를 다루는 결정에 개입할수록, '왜'에 답하지 못하는 시스템은 프로덕션에 올라갈 수 없거든요. Semantica가 그 표준이 될지는 지켜봐야겠지만, 임베딩 위주의 컨텍스트 관리에 그래프와 이력이라는 축을 더하려는 방향 자체는 분명 오래갈 흐름이에요.

여러분의 현장은 어떤가요? AI가 내린 답변의 근거를 설명하라는 요구를 받아본 적 있으신가요? 그때 어떻게 대응하셨는지, 그래프 기반 접근이 여러분의 도메인에서 통할 것 같은지 댓글로 이야기 나눠봐요.


🔗 출처: GitHub

이 뉴스가 유용했나요?

이 기술을 직접 배워보세요

AI 도구, 직접 활용해보세요

AI 시대, 코딩으로 수익을 만드는 방법을 배울 수 있습니다.

AI 활용 강의 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.