팔란티어 온톨로지와 하네스 엔지니어링: LLM을 길들이는 두 가지 방법

들어가며: 우리는 모델을 키우는 시대를 지나왔다

몇 년 전까지 AI 성능 이야기는 곧 모델 크기 이야기였다. 파라미터를 더 키우고, 데이터를 더 먹이고, 더 큰 GPU를 붙이는 것. 그런데 지금 실무에서 LLM을 다뤄본 사람이라면 누구나 같은 벽에 부딪힌다. 모델은 충분히 똑똑한데, 우리 회사의 현실 앞에서는 자꾸 헛소리를 한다는 것.

이 문제를 푸는 두 가지 흐름이 지금 가장 뜨겁다. 하나는 개발자 커뮤니티에서 유행하는 하네스 엔지니어링(harness engineering), 다른 하나는 팔란티어가 20년에 걸쳐 밀어붙인 **온톨로지(Ontology)**다. 표면적으로는 전혀 다른 세계의 이야기처럼 보이지만, 들여다보면 둘은 놀랍도록 같은 깨달음 위에 서 있다. 이 글은 그 둘을 같은 무대에 올려놓고 비교한다.

1. 똑같은 출발점: "모델 밖을 엔지니어링하라"

두 접근은 한 문장을 공유한다. 모델 자체를 더 키우거나 다시 학습시키는 것보다, 모델 바깥의 맥락·도구·제약을 잘 설계하는 것이 실전 성능을 좌우한다.

하네스 엔지니어링의 모토는 "모델은 고정값으로 두고, 그 주변을 전부 설계하라"는 것이다. 컨텍스트에 무엇을 넣고 뺄지, 어떤 도구를 언제 쥐여줄지, 출력을 어떤 형식으로 강제할지, 실패하면 어떻게 다시 시도할지를 정교하게 짠다.

팔란티어가 온톨로지를 설명할 때 반복하는 말도 정확히 같은 결이다. "이건 모델 크기에 관한 이야기가 아니라 맥락에 관한 이야기다." 모델을 더 좋은 걸로 바꿔서가 아니라, 모델에게 회사의 구조화된 현실을 쥐여줘서 성능이 올라간다는 것이다.

같은 철학이다. 그렇다면 둘은 그냥 같은 것을 다르게 부르는 걸까? 그렇지 않다. 여기서부터가 흥미롭다.

2. 핵심 통찰: 둘은 경쟁이 아니라 수직으로 쌓이는 두 개의 층이다

많은 사람이 하네스 엔지니어링과 온톨로지를 나란히 놓고 "어느 쪽이 더 나은 방법이냐"를 묻는다. 잘못된 질문이다. 둘은 같은 평면 위의 경쟁자가 아니라, 서로 다른 높이에 쌓이는 두 개의 층이기 때문이다.

하네스는 런타임 제어 층이다. 한 번의 추론, 한 번의 에이전트 루프 안에서 모델을 어떻게 다루느냐를 책임진다. 무엇을 컨텍스트에 넣을지, 어떤 도구를 노출할지, 출력 스키마를 어떻게 강제할지, 루프를 언제 끊을지. 모델로 들어가고 나오는 흐름을 통제한다.

온톨로지는 세계 모델 층이다. 그 하네스가 끌어다 쓰는 맥락이 어디서 오고, 무엇을 의미하고, 무엇과 연결되고, 누가 볼 수 있고, 어떤 행동을 일으킬 수 있는지를 정의한다. 모델이 추론하는 대상 세계 자체의 구조다.

비유하자면 이렇다.

하네스는 숙련된 작업 절차서와 작업대다.
온톨로지는 그 작업이 이뤄지는 공장 도면과 부품 카탈로그와 안전 규정이다.

좋은 작업 절차가 있어도 공장 구조를 모르면 헛돈다. 완벽한 공장 도면이 있어도 작업 절차가 엉성하면 사고가 난다. 둘은 어느 하나를 고르는 문제가 아니라, 위아래로 맞물려야 비로소 돌아가는 한 쌍이다.

3. 팔란티어 AIP는 사실 두 층을 모두 갖고 있다

이 틀을 손에 쥐고 팔란티어 AIP를 다시 보면, 그동안 뭉뚱그려져 있던 것이 또렷하게 갈라진다. AIP는 둘 중 하나가 아니라 둘 다를 한 플랫폼 안에 담고 있다.

AIP에서 "어떤 도구를 LLM에 노출하고, 어떤 순서로 추론을 돌리고, 출력을 어떻게 검증하고, 사람 승인 단계를 어디에 거는가"를 다루는 부분 — 이게 바로 하네스 엔지니어링이다.

가장 좋은 예가 거리 계산이다. "가장 가까운 물류센터가 어디냐"를 LLM에게 직접 묻게 두면 그럴듯한 답을 지어낸다. 그래서 AIP는 좌표 간 실제 거리를 계산하는 함수를 LLM에게 도구로 쥐여준다. 그러면 모델은 거리를 상상하는 대신 그 함수를 호출해 정확한 답을 얻는다. 사람으로 치면, 베테랑 직원이 암산으로 우기지 않고 계산기를 꺼내 드는 것과 같다. 이것이 전형적인 하네스 제어다.

반면 온톨로지는 그 하네스가 매번 새로 발명하지 않아도 되도록, 검증된 세계 모델을 영속적인 자산으로 미리 깔아둔 것이다. "고객"이 무엇이고, 어떤 계약·송장·창고와 연결되며, 누가 접근할 수 있는지를 한 번 정의해두면, 그 위에 올라가는 모든 에이전트가 그것을 공유한다.

바로 이 지점이 일반적인 하네스 엔지니어링과 팔란티어가 갈라지는 곳이다. 보통의 하네스 엔지니어링은 이 세계 모델을 매 프로젝트마다 임시로 다시 만든다. 컨텍스트에 텍스트를 욱여넣고, 도구를 그때그때 정의하고, RAG 파이프라인을 따로 구축한다. 팔란티어는 그것을 한 번 제대로 만들어 모두가 재사용하는 자산으로 박아둔다.

4. 이 차이가 만들어내는 세 가지 실질적 결과

이 구분은 분류학적 말장난이 아니다. 실무에서 명확한 세 가지 차이를 만든다.

첫째, 재사용이냐 일회성이냐.
순수 하네스 엔지니어링에서 맥락·도구·스키마는 그 워크플로우에만 묶인 일회성 산출물인 경우가 많다. 온톨로지는 한 번 잘 모델링하면 모든 에이전트와 앱이 같은 객체·관계·액션을 공유한다. "고객" 객체를 한 번 정의하면 백 개의 워크플로우가 그것을 그대로 쓴다.

둘째, 권한이 데이터 모델에 내장된다.
일반 하네스에서 권한 제어는 보통 애플리케이션 코드나 검색 필터에 따로 붙인다. 온톨로지는 권한이 객체와 속성 레벨에 박혀 있다. 그래서 어떤 경로로 접근하든 권한이 자동으로 따라온다. 특정 지역의 데이터만 볼 수 있는 직원을 대신하는 AI 에이전트가, 다른 관할권의 기록을 끌어오려 해도 애초에 불가능한 구조다.

셋째, 관계 기반 검색이 공짜로 따라온다.
일반 하네스가 RAG로 의미적 유사도 검색만 할 때, 온톨로지 위의 하네스는 "이 문단이 어떤 계약과 고객에 연결돼 있는지"를 관계 그래프로 타고 들어간다. 검색 공간을 의미 검색 이전에 미리 좁히기 때문에, 엉뚱한 고객의 비슷한 문서가 결과에 섞이는 일이 줄어든다.

이 세 번째 항목은 따로 짚을 가치가 있다. 흔히 "온톨로지가 있으면 RAG가 필요 없다"고 오해하는데, 정확히는 그렇지 않다. 비정형 원문(예: 600페이지짜리 보고서)을 의미 검색하려면 임베딩은 여전히 필수다. 다만 온톨로지는 그 임베딩 벡터를 문서 청크 객체의 한 속성으로 품은 채, 관계와 권한으로 검색 범위를 먼저 구획해준다. 임베딩을 없애는 기술이 아니라, 임베딩을 담아 통합하는 그릇인 셈이다.

5. 공짜 점심은 없다: 영속 자산의 그림자

여기까지 보면 팔란티어 방식이 일방적으로 우월해 보인다. 하지만 가장 큰 강점은 동시에 가장 큰 약점이기도 하다.

세계 모델을 영속적 자산으로 만든다는 것은, 그 자산을 만드는 데 막대한 도메인 전문성과 시간과 비용이 든다는 뜻이다. 화려한 프로토타입은 몇 시간이면 나오지만, 운영 환경에서 믿고 쓸 수 있는 결정론적 동작을 만드는 데는 수개월이 걸린다. "노코드"라는 말은 진입 장벽을 낮춰주지만, 그 밑단의 온톨로지를 잘 까는 작업 자체는 결코 가볍지 않다.

게다가 일단 그 위에 수천 개의 로직을 쌓고 나면, 빠져나오기 어려운 구조적 락인이 생긴다. 반대로 가벼운 하네스 엔지니어링은 그만큼 민첩하고 특정 벤더에 덜 묶이지만, 맥락과 권한과 관계를 매번 새로 떠받쳐야 하는 부담을 진다.

결국 둘의 진짜 갈림길은 기술의 우열이 아니라 "일회성 민첩함이냐, 영속적 자산화냐"의 트레이드오프다.

마치며: 같은 산을 오르는 두 개의 등산로

LLM이라는 산 정상을 향해 가는 두 가지 방법(온톨로지 VS 하네스엔지니어링)

 

하네스 엔지니어링과 온톨로지는 결국 같은 정상을 향한다. 모델 바깥을 설계해서 LLM을 제어하고 현실에 접지시킨다는 정상이다.

다만 한쪽은 매 등반마다 가볍게 장비를 챙겨 빠르게 오르는 길이고, 다른 한쪽은 산 전체에 케이블카와 산장을 미리 깔아두고 누구나 그 위를 다니게 하는 길이다. 어느 길이 옳은지는 당신이 한 번 오르고 말 산인지, 평생 운영할 산인지에 달려 있다.

분명한 것은, AI 성능의 무게중심이 "모델에게 더 많은 데이터를 주는 것"에서 "모델에게 명시적이고 통제된 세계를 주는 것"으로 영구히 이동했다는 사실이다. 하네스든 온톨로지든, 우리는 모두 그 같은 방향을 향해 걷고 있다.