"하네스 무용론? 반은 맞고 반은 틀립니다"
a2sys 이동수 대표님(전 네이버 클라우드 EVP)이 하네스에 관한 좋은 글을 올려주셔서 퍼왔습니다.
[하네스 무용론? 반은 맞고 반은 틀립니다]
최근 AI 업계에서 이른바 ‘하네스 무용론’에 대한 이야기가 부쩍 많이 나오고 있습니다. 최근 관련보도에 따르면, OpenAI의 노엄 브라운 부사장은 차세대 모델이 현재 사용되는 하네스의 상당 부분을 쓸모없게 만들 수 있다고 언급했고, Google AI Studio의 로건 킬패트릭 역시 “모델이 점차 하네스를 먹어치우고 있다”는 취지의 발언을 했습니다.
이런 뉴스를 볼 때마다 “설마 이 말을 그대로 받아들이는 사람이 많을까” 싶지만, 실제로는 생각보다 그런 경우가 많습니다. AI 분야는 워낙 변화가 빠르고, 특히 에이전트와 하네스 주변에는 노이즈도 많습니다. 그래서 어떤 말은 맞는 것 같고, 또 어떤 말은 틀린 것 같은 혼란스러운 상황이 자주 생깁니다.
이 기회에 한 번 차분히 정리해볼 필요가 있습니다. 특히 저런 기업들의 발언은 "아 이 기업의 상황을 보면 이런 발언을 하고싶겠구나" 를 포함해서 "그치만 이 기업이라면 이런 말은 하기 어렵겠네" 같은 종류의 말들까지 맥락을 고민하여 엄밀하게 따져볼 필요가 있습니다. 기업들의 발표는 그 기업 입장에서 유리하게끔 이야기하게 되어 있는 점은 항상 염두할 필요가 있습니다.
우선 이 뉴스들은 "반은 맞는 이야기" 입니다. 지금까지 많은 AI application들이 의존해온 프롬프트 기반 하네스, 즉 “모델에게 이렇게 시키면 이렇게 행동한다”는 식의 휴리스틱한 제어 방식은 점차 줄어들 가능성이 큽니다. 실제로 Anthropic도 좋은 에이전트 시스템은 복잡한 프레임워크보다 단순하고 조합 가능한 패턴에서 출발한다고 설명합니다.
하지만 여기서 빠진 핵심이 있습니다. "하네스는 프롬프트 기반 한종류가 아닙니다." 하네스를 모두 같은 것으로 보면 판단이 틀어집니다. 저는 크게 세 가지로 나눠서 봐야 한다고 생각합니다.
첫 번째는 "프롬프트·워크플로우 하네스"입니다. 예를 들어 planner를 따로 두고, executor를 따로 두고, verifier를 붙이고, 실패하면 다시 시도하게 하는 방식입니다. 또는 특정 업무를 위해 프롬프트 체인을 길게 설계하는 것도 여기에 들어갑니다. 이런 종류의 하네스는 상당 부분 모델 안으로 흡수될 가능성이 높습니다. 모델 자체가 더 잘 계획하고, 더 잘 검증하고, 더 잘 도구를 선택하게 되면 굳이 밖에서 복잡하게 조율할 필요가 줄어들기 때문입니다. 이 부분에서 “하네스 무용론”은 꽤 맞는 이야기입니다.
두 번째는 "도구 실행 하네스"입니다. 모델이 어떤 도구를 부를지, 어떤 권한으로 실행할지, 실행 결과를 어떻게 해석할지, 실패하면 어떻게 되돌릴지, 사람이 승인해야 하는 단계는 어디인지 등을 관리하는 계층입니다. 이 부분들은 특징상 모델의 능력과 별 상관이 없습니다 (이 부분 밑줄 치고 싶네요). 아무리 모델이 좋아져도, 고객 정보를 읽어도 되는지, 결제를 실행해도 되는지, 사내 DB에 접근해도 되는지, 장애 대응 명령을 바로 내려도 되는지는 별도의 시스템 문제가 됩니다.
세 번째는 "런타임·메모리·인프라 하네스"입니다. 에이전트가 긴 작업을 수행하는 동안 어떤 정보를 기억할지, 어떤 컨텍스트를 버릴지, 어떤 캐시를 재사용할지, 어떤 모델에 라우팅할지, 비용과 지연시간을 어떻게 줄일지, 보안과 감사 로그를 어떻게 남길지 등이 여기에 들어갑니다. 저는 앞으로 가장 중요한 하네스는 바로 이 영역이라고 봅니다.
실제로 OpenAI도 Agents SDK에서 tool loop, handoff, session, tracing, guardrail, approval flow 같은 기능을 제공하고 있습니다. 이것은 하네스를 없앤다기보다 하네스의 일부를 모델 제공자 플랫폼 안으로 넣는 것으로 해석해야합니다.
아마도 더 정확한 표현은 “하네스가 없어진다”가 아니라 “하네스의 위치가 바뀐다”입니다. 눈에 잘 보이는 프롬프트 하네스는 줄어들고, 눈에 덜 보이는 실행·메모리·보안·인프라 하네스는 더 중요해질 수밖에 없다고 봅니다.
자, 이제 큰 AI 기업들이 할만한 것들을 봅시다. 범용적인 tool calling, 기본적인 agent loop, 간단한 메모리, tracing, guardrail, office workflow 같은 것들은 OpenAI, Google, Anthropic, Microsoft 같은 회사들이 계속 가져갈 것입니다. 상당히 자연스러운 흐름이고 쉽게 예측이 됩니다.
그러나 그런 큰 기업이 이미 하고있는 사업들 때문에 새롭게 도전하기 껄끄럽고 어떤 때에는 불가능한 일들도 분명히 있습니다.
첫째, "업무가 파편화될수록 범용 모델만으로는 부족합니다." Agentic AI라고 해도 실제 업무는 하나의 거대한 범용 시나리오가 모든 태스크를 다룰 수 없습니다. 코딩, 금융, 법률, 제조, 데이터센터 운영, 고객지원, 연구개발은 모두 Agent 운영 규칙이나 최적화 방식등이 다릅니다. 좀 더 세부적으로 보자면 각 업무마다 중요한 정보, 실패 비용, 검증 방식, 허용 가능한 지연시간, 필요한 메모리 구조가 다릅니다. 이런 영역에서는 큰 모델 하나가 모든 것을 자동으로 해결하기 어렵습니다. 혹은 어쩔 수 없는 SI 같은 사업 영역까지 발생하게 되는 시장이 됩니다.
둘째, "여러 모델을 동시에 수용하는 오케스트레이션은 빅테크가 중립적으로 하기 어렵습니다." OpenAI가 Anthropic 모델까지 가장 잘 라우팅해주는 중립적 오케스트레이터가 되기는 어렵습니다. Google이 OpenAI, Anthropic, 오픈소스 모델, 사내 모델을 모두 동일한 조건에서 최적화해주는 것도 현실적으로 쉽지 않습니다. 실제 기업들은 비용, 성능, 보안, 데이터 위치, 규제, 한국어 성능, 내부 모델 사용 여부에 따라 여러 모델을 섞어 써야 합니다. 이 부분들은 관련 논문들이 이미 쏟아지고 있으니 참고 바랍니다. 이때 필요한 것은 모델 중립적인 오케스트레이션 일 것입니다. 게다가 폐쇄형 모델에 기반해서 orchestration하면 서로 다른 모델 내부 (KV cache 등)을 들여다볼 수도 없어서 최적화 여지도 극히 제한적이 됩니다.
셋째, "기업 내부의 권한, 보안, 감사, 데이터 흐름은 회사마다 다릅니다." 모델이 아무리 좋아져도 “이 에이전트가 이 문서를 봐도 되는가”, “이 결과를 외부로 보내도 되는가”, “이 결정은 누가 승인했는가”, “나중에 사고가 났을 때 어떤 경로로 실행됐는가”는 별도의 시스템으로 관리해야 합니다. 이것은 모델 능력의 문제가 아니라 기업 운영의 문제입니다.
맨 위 언급된 뉴스들을 눈여겨 보는 것은 중요하다고 봅니다. 특히 프롬프트 수준에서 뭔가를 조합해 차별화를 만들던 방식은 오래가기 어렵다고 저도 예전부터 생각해 왔습니다. 사실 LLM초반부터 프롬프트만으로 만들어진 차별화는 대개 금방 사라졌습니다. 프롬프트에 의지한다는 것 자체가 본질적으로 휴리스틱하기 때문입니다.
하지만 그렇다고 하네스 전체가 무용해진다고 보는 것은 지나치게 단순한 해석입니다.
앞으로 단순화되는 부분은 분명 많아질 것입니다. 반대로 세분화되고 특화되는 부분도 더 많아질 것입니다. 특히 메모리, 캐시, 보안, 권한, 감사, 비용 최적화, 장기 실행 작업 관리 같은 영역은 굉장히 중요한데 정작 제대로 시작도 아직 못했습니다.
하네스가 무용하다는 분들에게 지금의 서비스 상황을 한번 제대로 논해보자고 하고 싶습니다. 5분 유지되는 캐시, 1시간 유지되는 캐시 정도로 가격을 차별화하는 수준에 만족할 수 있을까요? Agentic AI가 본격화되면 작업은 더 길어지고, 에이전트는 더 많은 도구를 부르고, 중간 상태는 더 많이 생기고, 재사용해야 할 컨텍스트와 메모리는 훨씬 복잡해집니다. 게다가 접근에 관한 policy는 메모리 기술과 서비스 기술이 융합해야합니다. 아직 갈 길이 (매우) 멉니다.
결국 하네스에 대해 이렇게 정리할 수 있다고 생각합니다.
필요 없는 하네스는 빨리 도태될 것입니다. 그러나 정작 필요한 하네스는 아직 충분히 만들어지지도 않았습니다.
프롬프트로 모델을 억지로 조종하던 하네스는 사라질 수 있습니다. 하지만 시스템과 결합된 하네스, 즉 메모리와 도구와 보안과 권한과 비용과 실행환경을 함께 다루는 하네스는 앞으로 매우 중요해질 것입니다.
하네스 무용론을 곧이곧대로 받아들이기보다, 어떤 하네스가 사라지고 어떤 하네스가 남을지 혹은 강화되어야할 지를 구분해서 봐야 합니다.
