영상으로 읽기: Omni의 에이전틱 분석 하네스

Claude 채널의 Omni 분석 하네스 사례를 읽는 비디오 노트입니다. 이 영상은 Omni가 Claude 모델과 Claude Code를 활용해 분석 플랫폼 안에 에이전틱 하네스를 어떻게 넣었는지 보여줍니다.

중요한 제한이 있습니다. yt-dlp로 확인한 결과 이 영상에는 요청 언어의 자막이 없어 transcript 기반 인용을 만들 수 없었습니다. 따라서 아래의 근거 블록은 자막 인용이 아니라, yt-dlp가 수집한 영상 제목, 설명, 공식 챕터 메타데이터에 기반한 메타데이터 근거입니다.

---

1. Omni의 속도 문제: 분석 제품에서 하네스가 왜 필요한가

메타데이터 근거 · 00:00. 공식 챕터 제목은 Engineering velocity at Omni입니다. 영상 설명은 Omni가 Claude 모델로 구동되는 분석용 에이전틱 하네스를 만들었고, 플랫폼 코드의 99%를 Claude Code로 작성했다고 소개합니다.

해석

이 도입부의 핵심은 단순히 “AI로 코드를 많이 썼다”가 아닙니다. 분석 제품에서는 사용자가 묻는 질문, 데이터 모델, SQL, 시각화, 검증 기준이 계속 바뀝니다. 그래서 개발 속도만 빠른 도구보다, 질문을 안전하게 데이터 실행으로 바꾸는 운영 하네스가 더 중요해집니다.

Omni의 사례는 하네스를 제품 바깥의 개발 보조 장치가 아니라, 제품 안쪽의 분석 실행 계층으로 넣는 방향을 보여줍니다. 이것은 Claude Code를 잘 쓰는 이야기이면서 동시에, 분석 워크플로우를 에이전트가 다룰 수 있는 구조로 다시 설계하는 이야기입니다.

---

2. AI semantic layer: 데이터베이스와 언어 모델 사이의 중간층

메타데이터 근거 · 03:16. 공식 챕터 제목은 Building an AI semantic layer입니다. 영상 설명은 Chris Merrick이 multi-agent system의 architecture와 tool sizing을 설명한다고 밝힙니다.

해석

분석 에이전트가 곧바로 데이터베이스에 붙으면 위험합니다. 자연어 질문은 모호하고, 데이터베이스 스키마는 거칠며, 사용자가 원하는 지표 정의는 조직마다 다릅니다. semantic layer는 이 간극을 줄이는 번역 계층입니다.

여기서 semantic layer는 단순한 BI 모델링 용어가 아니라, 에이전트가 안전하게 사고할 수 있는 bounded context입니다. 모델은 전체 데이터베이스를 무작정 들여다보는 것이 아니라, 질문과 관련된 개념, 테이블, 지표, 도구 사용법을 제한된 문맥으로 받아야 합니다. 이 제한이 있어야 SQL 생성도, 결과 해석도, 재시도 루프도 안정됩니다.

---

3. Blobby agent: 분석 질문을 실행 가능한 흐름으로 바꾸는 작업자

메타데이터 근거 · 07:16. 공식 챕터 제목은 Developing the Blobby agent입니다.

해석

이 챕터의 이름만으로도 구조가 드러납니다. Omni는 범용 챗봇을 분석 화면에 붙인 것이 아니라, 분석 도메인에 맞춘 agent를 만들고 있습니다. 이름이 무엇이든, 이 agent의 역할은 사용자의 질문을 제품 안에서 실행 가능한 단위로 바꾸는 것입니다.

여기서 중요한 설계 질문은 “모델에게 얼마나 많은 자유를 줄 것인가”입니다. 분석 agent는 질문을 이해해야 하지만, 마음대로 모든 도구를 쓰면 안 됩니다. 테이블 탐색, metric 선택, SQL 작성, 결과 검토, 사용자에게 되묻기 같은 행동을 잘게 나누고, 각 행동이 언제 허용되는지 정해야 합니다. 이것이 하네스의 실제 내용입니다.

---

4. Agent logic 다듬기: 좋은 답보다 좋은 실패 경로가 먼저다

메타데이터 근거 · 13:07. 공식 챕터 제목은 Refining agent logic입니다.

해석

에이전트 로직을 다듬는다는 것은 프롬프트를 예쁘게 고치는 일이 아닙니다. 분석 업무에서는 실패의 형태가 다양합니다. 질문이 모호할 수 있고, 필요한 지표가 없을 수 있고, SQL은 실행되지만 답이 잘못된 방향일 수 있고, 결과가 맞아도 사용자에게 설명하는 방식이 틀릴 수 있습니다.

따라서 좋은 agent logic은 성공 경로보다 실패 경로를 먼저 설계합니다. 언제 질문을 되물어야 하는가, 언제 더 작은 SQL로 쪼개야 하는가, 언제 결과를 신뢰하지 말고 검산해야 하는가, 언제 사람에게 넘겨야 하는가를 명시해야 합니다. 이 지점에서 하네스는 “모델을 더 똑똑하게 만드는 장식”이 아니라 “모델이 틀릴 수 있다는 전제 위의 운영 규칙”이 됩니다.

---

5. SQL generation으로 전환: 자연어 답변에서 실행 가능한 쿼리로

메타데이터 근거 · 16:23. 공식 챕터 제목은 Transitioning to SQL generation입니다.

해석

분석 agent가 제품에서 가치를 내려면 결국 실행 가능한 형태가 필요합니다. 자연어 답변만으로는 데이터 제품이 되기 어렵고, SQL만 던져도 사용자는 검증하기 어렵습니다. 이 챕터의 전환은 자연어 의도와 SQL 실행 사이를 어떻게 연결할 것인가의 문제입니다.

SQL generation은 가장 위험하면서도 가장 강력한 지점입니다. 모델이 만든 SQL은 문법적으로 맞아도 의미적으로 틀릴 수 있습니다. 그래서 schema context, metric definition, query preview, 실행 결과 검증, 설명 생성이 한 루프로 묶여야 합니다. SQL을 생성하는 모델보다 더 중요한 것은 SQL을 생성해도 되는 조건과 그 결과를 확인하는 하네스입니다.

---

6. Architecture and evals: 하네스는 평가 루프 없이는 완성되지 않는다

메타데이터 근거 · 19:11. 공식 챕터 제목은 System architecture and evals입니다. 영상 설명도 multi-agent system의 architecture, tool sizing, effectiveness evaluation을 다룬다고 밝힙니다.

해석

이 영상에서 가장 중요한 챕터는 아마 여기입니다. 에이전트 하네스는 도구 목록과 프롬프트만으로 만들어지지 않습니다. 어떤 역할이 어떤 도구를 쓰는지, 도구 하나의 크기는 어느 정도가 적절한지, 모델의 응답을 무엇으로 평가할지까지 포함해야 합니다.

특히 분석 제품의 eval은 단순한 정답률 문제가 아닙니다. 질문 의도 보존, SQL 의미 정확성, 지표 정의 일치, 결과 설명의 투명성, 위험한 실행의 차단 여부를 함께 봐야 합니다. 평가 루프가 없으면 agent는 데모에서는 멋있지만 운영에서는 불안정합니다. 반대로 eval이 있으면 모델, 도구, 프롬프트를 바꿔도 품질을 비교할 수 있습니다.

---

7. Demo and conclusion: 하네스는 결국 제품 경험으로 검증된다

메타데이터 근거 · 22:17. 공식 챕터 제목은 Live demo and conclusion입니다.

해석

하네스 논의가 추상적으로 끝나지 않으려면 live demo가 필요합니다. 에이전트가 실제 제품 화면에서 사용자의 질문을 받고, 필요한 context를 잡고, 도구를 쓰고, 결과를 설명하는 흐름을 보여줘야 합니다. 그래야 하네스가 “문서화된 방법론”인지 “실제로 사용자 경험을 바꾸는 시스템”인지 드러납니다.

여기서 데모의 의미는 기능 자랑보다 연결성 검증에 가깝습니다. semantic layer, agent logic, SQL generation, eval loop가 따로 존재하는 것이 아니라 하나의 분석 경험으로 이어져야 합니다. 좋은 하네스는 사용자가 하네스를 의식하지 않아도, 질문이 안전하게 답으로 변환되도록 뒤에서 작동합니다.

---

내 생각

이 영상은 내게 “AI 분석 제품의 중심은 모델이 아니라 경계 설계”라는 문장으로 남습니다. Claude 모델이 강력하고 Claude Code가 빠르다는 사실보다 더 중요한 것은, Omni가 그 능력을 분석 제품의 semantic layer, tool boundary, SQL generation, eval loop 안에 넣었다는 점입니다.

LLM Wiki 관점에서 보면 이 사례는 지식 노드가 실행 노드로 내려가는 장면입니다. 사용자의 질문은 하나의 느슨한 노드이고, semantic layer는 그 질문을 조직의 데이터 언어로 연결합니다. agent는 그 연결을 실행 계획으로 바꾸고, SQL은 계획을 검증 가능한 명령으로 내립니다. eval은 다시 결과를 지식 구조로 되돌립니다.

내 작업에도 바로 적용할 점이 있습니다. 블로그 자동화, 성적표 OCR, 뉴스 큐레이션, 책 노트 생성 모두 결국 같은 문제를 겪습니다. 모델에게 “잘해줘”라고 말하는 대신, 입력을 제한하고, 도구를 작게 만들고, 중간 결과를 검증하고, 실패 시 되묻는 루프를 만들어야 합니다. 하네스는 AI를 묶어두는 줄이 아니라, AI가 제품 안에서 책임 있게 움직일 수 있게 하는 작업장입니다.

출처

• 원본 영상: Building the best agentic analytics harness: Powered by Claude, built with Claude Code
• 채널: Claude
• 메타데이터 수집: yt-dlp, 2026-07-06 확인
• 자막 상태: 요청 언어 en-orig,en 기준 transcript 없음