AI로 뭔가를 만들어 본 사람이라면 하네스(harness)를 안 만들 수 없다. 모델 혼자 두면 엉뚱한 데로 새니까, 앞뒤로 뭔가를 덧대게 된다. 출력 포맷을 강제하고, 단계를 쪼개고, 검증을 붙이고, 실패하면 다시 부른다. 그렇게 덧댄 것들이 쌓여서 하나의 구조물이 된다.문제는 이 구조물이 영원히 자산으로 남지 않는다는 점이다. 어떤 하네스는 6개월 뒤에 짐이 되고, 어떤 하네스는 5년 뒤에도 필요하다. 이 둘을 구분하지 못하면, 없어져도 되는 걸 붙들고 유지보수하면서 정작 필요한 건 아무도 안 적어두는 상태가 된다.구분선은 의외로 단순하다. 모델이 못해서 만든 하네스인가, 우리가 안 정해서 만든 하네스인가. 실행 하네스: 모델의 부족함을 메우는 것실행 하네스는 모델의 능력 부족을 보완하려고 만든 것들..

들어가며: 우리는 모델을 키우는 시대를 지나왔다몇 년 전까지 AI 성능 이야기는 곧 모델 크기 이야기였다. 파라미터를 더 키우고, 데이터를 더 먹이고, 더 큰 GPU를 붙이는 것. 그런데 지금 실무에서 LLM을 다뤄본 사람이라면 누구나 같은 벽에 부딪힌다. 모델은 충분히 똑똑한데, 우리 회사의 현실 앞에서는 자꾸 헛소리를 한다는 것.이 문제를 푸는 두 가지 흐름이 지금 가장 뜨겁다. 하나는 개발자 커뮤니티에서 유행하는 하네스 엔지니어링(harness engineering), 다른 하나는 팔란티어가 20년에 걸쳐 밀어붙인 **온톨로지(Ontology)**다. 표면적으로는 전혀 다른 세계의 이야기처럼 보이지만, 들여다보면 둘은 놀랍도록 같은 깨달음 위에 서 있다. 이 글은 그 둘을 같은 무대에 올려놓고 비교..

최신 LLM과 기법을 통해 AI 에이전트를 구축해봐도 어딘지 조금 멍청하게 동작을 했던 경험이 있을 것입니다. 2026년 5월 현 시점에서 내 부족한 AI에이전트에게 무엇을 추가하면 성능이 급격히 상승할까요? 이미 만들어진 전문영역 AI Agent에게 더 성능좋은 LLM, AI Agent 설계 변화, 다양한 테스트를 통한 오작동 감소 등으로 큰 변화를 이룰 수 있을까요? 저는 현시점에서 지식그래프를 활용한 '온톨로지' 구축이 가장 자신있게 내놓을 수 있는 답 같습니다. 현 시점에서 AI 기술은 '도구'에 가깝고, 중요한 것은 이 도구들을 기존 전문화된 데이터와 어떻게 연결학고 활용하여, 내 비지니스 문제를 해결하는 것이라고 생각합니다. 개인이 AI시대에 생존할 수 있는 꽤 괜찮은 방법 중 하나가 자신이..

안녕하세요! 오늘은 데이터 관리와 AI 서비스 기획에서 아주 중요한, 하지만 종종 오해받곤 하는 '온톨로지(Ontology)'에 대해 이야기해보려 합니다. 본 내용은 패스트캐퍼스에 '온톨로지 기반 프로덕트 레벨 AI Agent 서비스 구축' 공부하고 남긴 글입니다. 많은 분이 "데이터베이스(DB)가 있는데 왜 굳이 온톨로지를 써야 하나요?"라고 묻습니다. 결론부터 말씀드리면, 데이터베이스는 '사실'을 저장하는 도구이고, 온톨로지는 그 사실의 '의미'를 정의하는 모델링 철학이기 때문입니다.1. DB가 대답하지 못하는 질문들우리가 흔히 쓰는 DB는 "무엇이 있는가(What)"를 찾는 데는 최고의 도구입니다. 하지만 사용자의 모호한 의도가 담긴 질문에는 당황하곤 하죠.사용자: "새벽에 쓰기 좋은 가벼운 노트북..

AI 기술이 발전하면서 우리는 AI에게 단순히 질문을 던지는 것을 넘어, AI가 스스로 코드를 짜고 복잡한 업무를 수행하는 '에이전트(Agent)' 시대를 맞이하고 있습니다. 하지만 AI 에이전트가 똑똑해질수록 새로운 고민이 생깁니다. "어떻게 하면 이 강력한 AI가 내 의도대로, 실수 없이 끝까지 일을 완수하게 만들 수 있을까?"이 질문에 대한 해답으로 최근 주목받는 개념이 바로 **하네스 엔지니어링(Harness Engineering)**입니다. 오늘은 프롬프트 엔지니어링의 한계를 짚어보고, 왜 우리가 하네스 엔지니어링으로 넘어가야 하는지, 그 핵심 철학과 적용 방법에 대해 알아보겠습니다. 참고로 블로그를 작성하면서 참고한 유튜브 영상을 공유합니다.https://youtu.be/DrekqeDlO1w?..