AI / Data / Business

기업 AI의 진짜 병목은 모델이 아니라 ‘온톨로지’다

환각을 줄이고, 에이전트가 사고 치지 않게 만드는 AI 시대의 데이터 운영체제

LLM을 도입한 기업들이 가장 먼저 부딪히는 문제는 대개 비슷합니다. 처음에는 “우리 회사 데이터만 넣으면 AI가 알아서 잘 답하겠지”라고 기대합니다. 그런데 막상 써보면 답이 그럴듯하긴 한데, 결정적인 순간에 틀립니다. 더 큰 문제는 틀린 답을 아주 자신 있게 말한다는 거예요.

이 문제를 우리는 보통 환각 hallucination이라고 부릅니다.

그런데 에이전틱 AI와 피지컬 AI의 시대에는 환각이 단순한 불편함으로 끝나지 않습니다. 챗봇이 잘못 답하는 정도가 아니라, AI가 실제 업무를 실행하고, 장비를 움직이고, 의사결정을 자동화하는 순간부터는 잘못된 데이터 하나가 재앙으로 이어질 수 있습니다.

예전에는 이렇게 말했죠. Garbage in, garbage out. 쓰레기를 넣으면 쓰레기가 나온다. 하지만 에이전틱 AI 시대에는 이 문장이 조금 더 무거워집니다.

바로 여기서 다시 주목받는 개념이 있습니다. 온톨로지 Ontology입니다. 온톨로지는 AI의 성능을 마법처럼 올려주는 비법 재료가 아닙니다. 오히려 더 정확히 말하면, 기업 AI가 위험한 결정을 하지 않도록 만드는 데이터의 가드레일에 가깝습니다.

온톨로지는 AI가 이해할 수 있는 ‘개념 지도’다

Q. 온톨로지라는 단어부터 어렵습니다. 쉽게 말하면 뭔가요?

온톨로지는 원래 철학에서 온 단어입니다. 뜻은 존재론입니다. 무엇이 존재하는지, 그것이 어떤 성격을 갖는지, 서로 어떤 관계를 맺는지를 다루는 영역이죠.

하지만 AI와 정보 시스템의 관점에서 보면 조금 더 실용적으로 설명할 수 있습니다.

예를 들어 “서울”이라는 단어를 생각해봅시다. 사람은 서울이라는 말을 들으면 자연스럽게 서울은 도시이고, 대한민국의 수도이며, 인구와 행정구역과 교통망을 가진다는 맥락을 떠올립니다. 하지만 컴퓨터에게 서울은 그냥 문자열일 수 있습니다.

서울은 도시다.
도시는 사람이 사는 공간이다.
도시는 인구를 가진다.
도시는 행정구역을 가진다.
서울은 대한민국의 수도다.

즉, 온톨로지는 단어를 저장하는 것이 아니라 단어가 의미하는 개념과 관계를 저장합니다.

Q. 그럼 LLM도 이런 걸 이미 알고 있지 않나요?

어느 정도는 알고 있습니다. 요즘 LLM은 “서울은 대한민국의 수도다” 같은 질문에 잘 답합니다. 하지만 중요한 차이가 있습니다. LLM은 답을 확률적으로 생성합니다. 온톨로지는 개념과 관계를 명시적으로 정의합니다.

쉽게 말해, LLM이 말 잘하는 사람이라면 온톨로지는 그 사람이 참고해야 하는 사내 업무 규정, 용어 사전, 판단 기준, 관계도에 가깝습니다.

지식 그래프는 빵이고, 온톨로지는 빵틀이다

Q. 온톨로지와 지식 그래프는 같은 말인가요?

비슷하게 쓰이지만 엄격히 보면 다릅니다. 김학래 교수는 이 차이를 “빵틀과 빵”으로 설명합니다.

온톨로지 = 빵틀
지식 그래프 = 빵

예를 들어 전 세계 도시 정보를 정리한다고 해봅시다. 먼저 “도시란 무엇인가”를 정의해야 합니다. 도시는 이름을 가지고, 국가에 속하며, 인구와 면적을 가집니다. 이런 틀이 온톨로지입니다.

그다음 이 틀에 실제 데이터를 넣습니다. 서울, 런던, 뉴욕 같은 실제 도시와 그 속성들이 연결되면 그것이 지식 그래프가 됩니다.

Q. 구글 검색의 오른쪽 정보 패널도 이런 원리인가요?

맞습니다. 구글에서 어떤 인물이나 도시를 검색하면 오른쪽에 별도의 정보 박스가 뜹니다. 이걸 Knowledge Panel이라고 부릅니다. 예전 검색이 문자열을 찾는 방식이었다면, 지식 그래프 이후의 검색은 그 문자열이 가리키는 실제 대상과 의미를 파악하는 방향으로 바뀌었습니다.

구글이 말했던 “string이 아니라 thing을 검색한다”는 표현도 이 맥락입니다.

기업 AI에 필요한 것은 더 큰 모델이 아니라 더 명확한 맥락이다

Q. 기업들이 LLM을 도입했는데 성능이 잘 안 나오는 이유도 온톨로지 때문인가요?

많은 경우 그렇습니다. 기업에서 쓰는 단어는 일반 상식과 다릅니다. 같은 단어라도 회사마다 의미가 다릅니다.

예를 들어 “재고 부족”이라는 표현을 생각해봅시다. A기업에서는 현재 재고가 7일치 미만이면 재고 부족일 수 있고, B기업에서는 현재 재고가 3일치 미만이면서 다음 입고 예정이 48시간 이후일 때만 재고 부족일 수 있습니다.

이런 기준은 LLM이 학습으로 알아서 추론하면 안 됩니다. 기업의 업무 기준은 명시적으로 정의되어 있어야 합니다. 온톨로지는 바로 이 기준을 제공합니다.

Q. 그럼 범용 챗봇에 온톨로지를 붙이면 되는 건가요?

현실적으로 온톨로지는 범용 상식 전체에 적용되기보다, 특정 도메인이나 기업 환경에서 더 큰 효과를 냅니다. 전 세계의 모든 상식과 개념을 하나의 온톨로지로 정리하는 것은 거의 불가능에 가깝기 때문입니다.

기업 AI에 필요한 것은 모든 것을 아는 AI가 아닙니다. 우리 회사의 언어와 기준을 정확히 이해하는 AI입니다.

RAG 다음은 Graph RAG다

Q. RAG를 쓰면 환각이 줄어든다고 하잖아요. 온톨로지는 RAG와 어떤 관계인가요?

RAG는 LLM이 답을 만들기 전에 외부 문서를 검색해서 참고하게 만드는 방식입니다. 이 방식은 환각을 줄이는 데 도움이 됩니다. 하지만 일반적인 RAG에도 한계가 있습니다.

문서를 그냥 검색해서 넣어주는 방식은 여전히 “문서 조각” 중심입니다. 문서 안의 개념과 관계를 정확히 이해하는 것은 별개의 문제입니다.

기업 AI가 단순 질의응답을 넘어 실제 업무 판단을 하려면, 문서 검색보다 한 단계 더 깊은 구조가 필요합니다. 그 구조가 지식 그래프이고, 그 지식 그래프의 틀이 온톨로지입니다.

팔란티어가 말하는 온톨로지는 단순한 데이터 사전이 아니다

Q. 팔란티어가 온톨로지로 유명한 이유는 뭔가요?

팔란티어는 온톨로지를 단순히 데이터를 정리하는 도구로 보지 않습니다. 기업의 실제 의사결정과 실행을 연결하는 운영 레이어로 봅니다.

1. Semantic Layer  — 개념을 정의한다
2. Kinetic Layer   — 개념들이 시스템 안에서 어떻게 움직이는지 본다
3. Dynamics Layer  — 실제 액션과 의사결정을 가능하게 한다

이 레이어가 있으면 온톨로지는 정적인 데이터 사전이 아니라, 기업 운영을 움직이는 동적 시스템이 됩니다. ERP, CRM, SCM 같은 기업 시스템을 연결하고, 그 위에서 의사결정과 실행이 이어지도록 만드는 것이 핵심입니다.

온톨로지는 성능 향상 도구가 아니라 리스크 보험이다

Q. 온톨로지를 도입하면 AI 성능이 좋아지나요?

좋아질 수 있습니다. 하지만 그게 핵심은 아닙니다. 진짜 가치는 리스크를 줄이는 것에 있습니다.

기업 AI에서 가장 위험한 상황은 AI가 잘못된 데이터를 읽고, 잘못된 맥락으로 판단하고, 그 판단을 바탕으로 실제 업무를 실행하는 것입니다. 과거에는 데이터가 잘못되면 잘못된 보고서가 나왔습니다. 하지만 에이전틱 AI 시대에는 잘못된 데이터가 잘못된 실행으로 이어집니다.

Q. 실제 사례로 보면 어떤 문제가 생길 수 있나요?

영상에서는 미국 유통기업 Target의 캐나다 진출 실패 사례가 언급됩니다. 시스템 자체는 강력했지만, 짧은 시간 안에 많은 사람이 데이터를 입력하면서 단위와 규격이 뒤섞였습니다. 그 결과 매장에는 재고가 없는데 시스템에는 재고가 많다고 표시되는 문제가 생겼습니다.

기존 ERP 환경에서도 이런 데이터 오류는 큰 손실을 만들었습니다. 그런데 AI 에이전트가 자동으로 발주, 가격 조정, 고객 안내, 물류 배정을 실행한다면 오류는 더 빠르게, 더 크게 증폭됩니다.

기업은 온톨로지를 어디서부터 시작해야 하나

Q. 온톨로지가 중요하다는 건 알겠는데, 구축 비용이 너무 크지 않나요?

맞습니다. 온톨로지는 쉽게 만들 수 있는 것이 아닙니다. 도메인 전문가와 온톨로지 전문가가 함께 들어가서 개념을 정의하고, 관계를 설계하고, 데이터를 태깅해야 합니다.

온톨로지 프로젝트가 실패하는 가장 큰 이유는 기술이 어려워서만이 아닙니다. 기업 데이터가 이미 사일로로 쪼개져 있기 때문입니다.

Q. 그러면 현실적인 시작점은 뭔가요?

처음부터 회사 전체를 온톨로지화하려고 하면 실패할 가능성이 높습니다. 대신 가장 먼저 봐야 할 것은 참조성이 높은 골든 데이터입니다.

고객 마스터 데이터
제품 마스터 데이터
재고 기준 데이터
계약 조건 데이터
설비/부품 데이터
가격 정책 데이터
리스크 판단 기준

기업이 처음 해야 할 질문은 이것입니다. 우리 회사에서 AI가 반드시 정확히 이해해야 하는 개념은 무엇인가?

지금 당장 시작할 수 있는 체크리스트

기업에서 온톨로지를 거창하게 시작할 필요는 없습니다. 먼저 아래 질문부터 던져볼 수 있습니다.

• 우리 회사에서 가장 자주 쓰는 핵심 개념 20개는 무엇인가?
• 부서마다 다르게 쓰는 용어는 무엇인가?
• AI가 잘못 이해하면 가장 큰 사고가 나는 데이터는 무엇인가?
• 여러 시스템에서 반복적으로 참조되는 골든 데이터는 무엇인가?
• 제품, 고객, 재고, 계약, 설비 같은 핵심 객체의 관계가 명시되어 있는가?
• RAG에 넣는 문서들이 단순 텍스트인지, 구조화된 지식인지 확인했는가?
• AI가 답할 때 반드시 따라야 하는 회사의 판단 기준은 어디에 정의되어 있는가?

AI 네이티브 기업은 모델을 많이 쓰는 회사가 아닙니다. AI가 읽을 수 있는 회사를 만드는 조직입니다. 온톨로지는 그 출발점입니다.

AI / Data / Architecture

온톨로지가 당신 회사에 필요 없을 가능성이 큰 이유

GraphDB, GraphRAG, VectorDB, RAG가 한 문장 안에서 섞일 때 놓치기 쉬운 것들

요즘 기업 AI 문맥에서 온톨로지라는 단어가 자주 등장합니다. 팔란티어가 강조하고, GraphRAG가 유행하고, “AI 시대의 진짜 context layer”라는 표현까지 붙습니다. 그래서 어느 순간 온톨로지는 데이터 문제를 한 번에 해결해주는 장미칼처럼 보이기 시작했습니다.

하지만 여기에는 중요한 함정이 있습니다. 많은 글이 RAG, VectorDB, GraphDB, GraphRAG, 온톨로지를 한데 섞어 설명합니다. 이 다섯 개는 서로 연결될 수는 있지만 같은 것이 아닙니다.

RAG는 VectorDB가 아니다

Q. 기존 RAG의 한계가 곧 VectorDB의 한계라는 말은 맞나요?

정확히는 아닙니다. RAG는 외부 검색 결과를 LLM 컨텍스트에 넣는 패턴입니다. 검색 백엔드는 벡터DB일 수도 있고, BM25일 수도 있고, SQL이나 ElasticSearch, GraphDB일 수도 있습니다.

RAG = Retrieval Augmented Generation
= 외부 근거를 찾아 LLM에게 넣는 방식

검색 backend = BM25 / VectorDB / SQL / GraphDB / metadata filter / reranker

따라서 “VectorDB가 약하다 → RAG가 약하다 → GraphRAG나 온톨로지가 답이다”라는 삼단논법은 조심해야 합니다. 실전 production RAG는 이미 BM25, vector, metadata filter, reranker를 섞는 hybrid 구조로 운영되는 경우가 많습니다.

Q. 그럼 VectorDB는 단순한 유사도 검색이라 별로인가요?

그것도 아닙니다. 비정형 텍스트에서 사전 합의 없이 의미를 끌어내는 데에는 embedding 기반 검색이 여전히 강력합니다. “두통”으로 검색했을 때 “headache” 문서를 찾거나, “계약 해지 조건”으로 검색했을 때 “termination clause”를 찾는 일은 과거 키워드 검색만으로는 매우 어려웠습니다.

VectorDB의 가치는 바로 여기에 있습니다. 조직 전체가 먼저 용어를 합의하지 않아도, 의미 기반 retrieval을 만들 수 있게 해줍니다.

온톨로지는 합의를 전제로 한다

Q. 온톨로지는 그냥 GraphDB에 노드와 엣지를 넣는 것 아닌가요?

아닙니다. GraphDB는 저장소이고, 온톨로지는 모델입니다. Neo4j에 고객, 제품, 주문 노드를 넣었다고 자동으로 온톨로지가 생기지는 않습니다. 반대로 온톨로지가 꼭 GraphDB에 저장되어야 하는 것도 아닙니다.

온톨로지가 잘 맞는 영역은 보통 합의가 이미 있거나, 합의 비용보다 합의의 ROI가 훨씬 큰 영역입니다. Gene Ontology, SNOMED CT, ICD/KCD, FHIR, HS code, 도서관 통제어휘 같은 것들이 그렇습니다.

Q. 일반 회사 내부 지식에는 왜 위험한가요?

회사 내부의 의미는 생각보다 자주 흔들립니다. 부서마다 같은 단어를 다르게 쓰고, 시간이 지나며 기준이 바뀌고, 예외가 생기고, 특정 캠페인이나 고객군에 따라 해석이 달라집니다.

온톨로지는 의미 합의를 기록 시점에 고정합니다. 그런데 실무 데이터는 기록 이후에 합의가 바뀝니다. 이 차이가 커지면 모델은 점점 복잡해지고, 클래스와 관계가 계속 추가되고, 결국 아무도 자신 있게 고치지 못하는 구조물이 됩니다.

그래프 그림은 멋있지만, 결재 근거가 되어서는 안 된다

Q. 그래프 시각화가 설득력 있어 보이는 건 사실 아닌가요?

맞습니다. 가운데 고객 노드가 있고, 제품, 계약, 티켓, 문서, 담당자가 빛처럼 연결된 화면은 강력합니다. 임원 회의에서 이런 그림은 검색 품질 개선표보다 훨씬 멋있어 보입니다.

하지만 운영 환경에서는 사용자가 그래프를 직접 보는 경우가 많지 않습니다. 대부분의 사용자는 검색 결과, 답변, 알림, 업무 화면을 봅니다. 실제 query도 1~2 hop이면 SQL JOIN과 metadata filter로 더 빠르고 정확하게 해결되는 경우가 많습니다.

그래프가 필요 없는 것은 아닙니다. 사기 탐지, 자금세탁, 권한 전파, 공급망 리스크처럼 깊은 관계 탐색 자체가 비즈니스 로직인 영역에서는 그래프가 강합니다. 다만 “멋있다”와 “최선의 운영 해법이다”는 다른 문장입니다.

먼저 해야 할 일은 더 작고 지루하다

Q. 그럼 회사는 어디서부터 시작해야 하나요?

대부분의 회사가 지금 해야 할 일은 거대한 온톨로지 구축이 아닙니다. 더 작고 지루한 일입니다.

• 원문 문서를 잃지 않게 저장한다.
• 권한과 tenant boundary를 검색 단계에서 강제한다.
• BM25, vector, metadata filter를 함께 쓴다.
• reranker로 근거 후보를 줄인다.
• 정답 세트를 만들고 검색 품질을 측정한다.
• 실제 사용 로그에서 실패 질문을 모은다.
• 반복적으로 안정되는 의미만 좁은 schema로 승격한다.

핵심은 모든 의미를 처음부터 고정하지 않는 것입니다. 먼저 원문을 보존하고, 검색으로 근거를 모으고, 질의 시점에 설명하게 합니다. 그다음 안정적으로 반복되는 부분만 모델 레벨로 올리면 됩니다.

AutoGrowth 같은 시스템에는 어떤 구조가 맞을까

Q. 에이전트가 도메인 지식을 써야 하는 시스템에서는 온톨로지가 필요 없나요?

필요 없다는 뜻은 아닙니다. 순서가 다르다는 뜻입니다. 에이전트가 마케팅 운영, 크리에이티브 판단, 성과 해석, 고객 맥락을 다루는 시스템에서는 강한 ontology-first보다 evidence-first, retrieval-first, schema-later가 더 안전합니다.

0. Raw Evidence      — 원문, 성과, 인터뷰, 리뷰, 운영 로그
1. Retrieval Index   — BM25, vector, metadata, reranker
2. Working Memory    — 현재 캠페인/클라이언트 맥락
3. Stable Schema     — 반복 검증된 개념만 승격
4. Decision Surface  — 근거 있는 제안과 실행 경계

광고 소재가 왜 먹혔는지, 고객 심리가 어떻게 움직였는지, 어떤 메시지가 브랜드와 맞는지는 시점과 맥락에 따라 바뀝니다. 이런 영역은 원문과 근거를 보존하고 에이전트가 질의 시점에 해석하도록 두는 편이 낫습니다.

반대로 metric 정의, 승인 경계, 제품의 불변 사실, 금지 claim, 예산 변경 rule처럼 반복성과 재현성이 필요한 부분은 작은 schema로 승격할 수 있습니다.

AI / Agents / Software

Claude Code가 ‘도구’에서 ‘작업자’로 넘어가는 순간

Code with Claude 2026 Opening Keynote에서 내가 가장 관심 가질 만한 라이브 영상 하나를 고르면, 답은 Routines와 Managed Agents가 나온 이 키노트다

Threads 스레드는 Anthropic이 개발자 컨퍼런스를 유튜브 라이브 미디어 패키지로 풀기 시작했다는 점을 짚고 있었습니다. 그중에서 하나만 고르라면 저는 Code with Claude 2026: Opening Keynote를 고릅니다. 이유는 단순합니다. 이 영상은 Claude Code를 “코딩 보조 도구”로 소개하지 않습니다. 예약되고, 이벤트를 듣고, PR을 열고, 실패를 고치고, 자기 경험을 메모리로 남기는 작업자 시스템으로 소개합니다.

왜 이 영상이 제일 맞는가

스레드에 등장한 후보들은 여러 갈래입니다. Anthropic 브랜드 캠페인, Claude FM 같은 문화 콘텐츠, 기업 사례 영상, Claude Code 신기능 세션, 메인 키노트가 있죠. 그중 이 키노트가 가장 흥미로운 이유는 제품 발표와 작업 방식의 변화가 한 화면에 같이 들어 있기 때문입니다.

사용자가 관심 가질 지점은 “AI가 개발자를 얼마나 도와주느냐”가 아닙니다. 더 중요한 질문은 이것입니다.

사람이 매번 지시하지 않아도
에이전트가 입력을 감지하고,
맥락을 읽고,
작업을 실행하고,
검증하고,
실패를 고치고,
다음 실행을 더 잘하게 만들 수 있는가?

이 키노트는 그 답을 Claude Code Routines, Managed Agents, multi-agent orchestration, outcomes, dreaming, CI AutoFix라는 이름으로 보여줍니다.

1. Claude Code는 터미널에서 control plane으로 이동 중이다

영상 후반부에서 Claude Code 팀은 사용 표면이 CLI → IDE → Desktop으로 확장됐다고 설명합니다. CLI는 여전히 파워유저용 최소 인터페이스입니다. IDE는 코드 변경을 따라가고 싶은 사람을 위한 표면입니다. Desktop은 한 단계 더 나아가 여러 Claude Code 세션을 동시에 관리하는 control plane입니다.

중요한 것은 UI가 예뻐졌다는 점이 아닙니다. Claude Code가 한 세션짜리 채팅창이 아니라, 여러 로컬·원격 세션을 동시에 띄우고, 어떤 에이전트가 막혔는지, 어떤 세션이 PR을 열었는지, 어떤 작업이 사람 입력을 기다리는지 보는 작업 오케스트레이션 레이어가 됐다는 점입니다.

2. Routines는 higher-order prompt다

가장 중요한 발표는 Routines입니다. 키노트에서는 Routines를 “higher-order prompt”에 비유합니다. 개발자가 매번 “이 이슈 처리해줘”라고 입력하는 대신, 한 번 설정한 routine이 GitHub issue, webhook, API call, schedule을 감지해 Claude Code 작업을 자동으로 시작합니다.

기존 방식: 사람이 이슈를 보고 → 프롬프트 작성 → Claude Code 실행
Routine 방식: 이벤트가 발생 → routine이 감지 → Claude Code 실행 → PR 생성

이건 단순한 자동화 기능이 아닙니다. 에이전트 운영의 중심이 사람의 입력창에서 이벤트 스트림으로 옮겨간다는 뜻입니다. 사람이 모든 입력의 병목이 되지 않아도 됩니다. GitHub issue, 고객 버그 리포트, CI 실패, 보안 스캔 결과가 곧 에이전트의 입력이 됩니다.

3. PR은 생성보다 babysitting이 더 비싸다

키노트에서 특히 현실적인 부분은 CI AutoFix입니다. 실제 개발에서 PR을 여는 것보다 귀찮은 일은 PR이 초록색이 될 때까지 지켜보는 것입니다. flaky test, 리뷰 코멘트, 보안 리뷰, merge conflict, rebase 같은 일들이 계속 발생하죠.

Claude Code의 방향은 이 babysitting을 에이전트가 맡는 것입니다. PR을 감시하다가 CI가 깨지면 원인을 진단하고, 리뷰 코멘트가 오면 수정하고, 보안 이슈가 나오면 패치하고, merge conflict가 생기면 rebase하는 흐름입니다.

4. Managed Agents는 에이전트 인프라를 제품화한다

키노트 중반부에서는 Claude Managed Agents가 소개됩니다. Anthropic은 이를 production-grade infrastructure와 결합된 agentic harness로 설명합니다. 단순히 모델 API를 호출하는 것이 아니라, 메모리, 실행 루프, 평가자, 여러 에이전트 조합을 제품 레이어로 묶는 방향입니다.

특히 세 가지 기능이 중요합니다.

• Multi-agent orchestration — 하나의 commander agent가 detector, navigator 같은 하위 에이전트를 독립 context window로 실행하고 결과를 병합한다.
• Outcomes — 성공 기준을 markdown rubric처럼 정의하고, 별도 grader agent가 기준 충족 여부를 평가하며 반복 실행한다.
• Dreaming — 과거 세션을 돌아보고 놓친 skill, 배워야 할 lesson, 반복되는 heuristic을 memory에 써서 다음 실행이 더 나아지게 한다.

이 구조는 사용자가 관심 갖는 “암묵지 자동 축적”과 바로 연결됩니다. 에이전트가 일을 하고, 실패하고, 개선점을 찾아, 다음 실행을 위한 playbook을 스스로 남기는 구조이기 때문입니다.

5. 사람의 역할은 prompting에서 system design으로 이동한다

영상에서 가장 큰 함의는 개발자가 사라진다는 이야기가 아닙니다. 오히려 개발자의 역할이 바뀐다는 이야기입니다. 사람이 매번 프롬프트를 쓰는 운영자가 아니라, 어떤 이벤트가 어떤 routine을 깨우고, 어떤 repo context를 읽고, 어떤 성공 기준으로 평가하고, 어디까지 자동 수정하게 둘지를 설계하는 사람이 됩니다.

Before: 좋은 프롬프트를 쓰는 사람
After: 좋은 루틴, 좋은 권한, 좋은 평가 기준, 좋은 피드백 루프를 설계하는 사람

이 전환은 AutoGrowth 같은 자동화 시스템에도 그대로 적용됩니다. 중요한 것은 대시보드에 버튼을 더 붙이는 것이 아니라, 반복 업무를 이벤트화하고, routine화하고, 검증 기준을 명시하고, 실패 로그를 다음 실행의 memory로 승격시키는 것입니다.

NerdMakr 관점의 정리

이 키노트는 Anthropic의 제품 발표이지만, 더 크게 보면 AI 작업 시스템의 방향을 보여줍니다. LLM이 채팅창에 갇혀 있던 단계에서 벗어나, schedule, webhook, API event, repo context, PR loop, CI, security scan과 연결되는 쪽으로 이동하고 있습니다.

그래서 이 영상을 보고 남겨야 할 질문은 “Claude Code 신기능을 써볼까?”가 아닙니다. 더 좋은 질문은 이것입니다.

그 질문에 답하는 순간, AI 도입은 도구 사용법이 아니라 운영체제 설계 문제가 됩니다.