아프니까 개발자다

자동화의 두 층 — OpenClaw는 '언제 깨울지', Hermes는 '깨어난 여럿이 어떻게 나눌지'

타이젠 개발자, 윤진 — Sun, 26 Jul 2026 21:00:07 +0900

개인 AI 어시스턴트 OpenClaw를 다룰 때, 그 자동화(Automation)의 핵심은 "에이전트를 언제 깨우느냐"였다. 정해진 시각에 깨우는 cron(예약 실행), 외부 이벤트가 찌르면 깨우는 webhook(외부 요청 수신), 특정 순간에 끼어드는 hook(개입 지점), 그리고 "이건 알아서 해도 된다"를 상시로 정의해 두는 standing orders(상시 명령) — 이 네 가지 트리거로 봇을 자동으로 깨운다. 그리고 대체로 거기서 멈춘다. 깨어난 에이전트는 대개 혼자 일을 하고 끝낸다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 kanban(칸반) 도구를 뜯어보니, 정확히 그다음 층의 문제를 풀고 있었다. 자동화에는 서로 다른 층이 있다 — "언제 깨우나"라는 트리거 층 위에, "깨어난 여럿이 한 작업을 어떻게 나누나"라는 오케스트레이션(orchestration, 여러 에이전트의 협업 조율) 층이 얹힌다. OpenClaw의 자동화가 앞 층에서 단일 에이전트를 깨우는 데 집중한다면, Hermes의 칸반은 뒷 층에서 깨어난 여러 에이전트가 큰 일을 분담하게 만든다. 둘은 직접 대응하는 경쟁 기능이 아니라 자동화의 다른 층이다 — 이 글은 그 갈림길 하나만 따라간다.

같은 문제, 갈라지는 결정 — 자동화의 어느 층에서 멈추고 어디서 시작하나

두 시스템 다 "사람이 안 붙어 있어도 일이 돌아가게" 하려는 자동화다. 그런데 그 자동화가 다루는 층이 다르다. 한쪽은 실행의 시작점(언제)을 관리하고, 다른 쪽은 실행된 뒤의 분업(어떻게 나누나)을 관리한다.

▲ OpenClaw — 단일 에이전트를 '언제' 깨울지의 층

위 다이어그램은 OpenClaw 자동화가 서는 층을 한 칸으로 요약한 것이다. 예약 시각·외부 요청·개입 지점·상시 명령이라는 네 가지 트리거가 에이전트를 깨우는 조건을 관리하고, 깨어난 에이전트는 대체로 혼자 일을 처리한다. 여기서 자동화의 난이도는 "무엇을, 언제, 무슨 사건에 반응해 시작할 것인가"에 몰린다 — 여러 에이전트가 한 작업을 어떻게 나눠 맡느냐 하는 물음은 이 층에 아예 등장하지 않는다.

▲ Hermes — 깨어난 '여럿이 어떻게 나눌지'의 층

위 다이어그램은 Hermes 칸반이 서는 층을 보여준다. 여기서는 트리거가 아니라, 이미 일을 시작한 여러 에이전트가 하나의 공유 작업판을 가운데 두고 큰 작업을 잘게 쪼개 나눠 맡는다. OpenClaw 자동화가 "언제 깨울까"에서 멈춘 바로 그 지점 뒤에 이 층이 붙는다 — 깨어난 에이전트가 하나가 아니라 여럿일 때, "누가 무엇을 맡고 어떤 순서로 진행하느냐"라는, 트리거 층에는 없던 물음이 새로 생긴다. 흔한 오해가 두 도구를 나란히 놓고 "어느 쪽이 더 나은 자동화냐"를 묻는 것인데, 애초에 겨루는 층이 다르다.

깨어난 다음의 문제 — 한 작업을 여럿이 어떻게 쪼개나

"리서치하고, 분석하고, 보고서를 써 줘" 같은 요청을 생각해 보자. 트리거 층의 관심사는 "이 요청을 언제 시작하느냐"까지다. 하지만 이건 성격이 다른 세 가지 일이다 — 자료를 찾는 일, 찾은 걸 종합·판단하는 일, 사람이 읽을 글로 다듬는 일. 한 에이전트에게 통째로 맡기면 세 가지를 한 맥락(context, 모델이 한 번에 들고 있는 대화·메모리) 안에서 섞어 처리하느라 길을 잃기 쉽고, 중간에 프로세스가 죽으면 처음부터 다시 해야 한다. Hermes 칸반이 다루는 건 정확히 이 "깨어난 다음"의 분업이다.

위 다이어그램은 하나의 요청이 어떻게 보드 위의 여러 카드로 흩어지는지 보여준다. 한 문장짜리 요청이 공유 작업판으로 들어가면, 성격이 다른 세 가지 일이 각각 별도 카드가 되고 카드마다 담당 프로필(profile, 서로 다른 성격·모델·도구·기억을 가진 독립 에이전트 설정)이 붙는다. 핵심은 "한 모델이 다 한다"가 아니라 "작업판이 진실의 원천이고, 카드 단위로 전문가에게 배분된다"는 점이다. 이건 OpenClaw 자동화가 손대지 않는 결정이다 — 트리거 층은 "이 일을 시작하라"까지만 말하지, "이 일을 셋으로 나눠 각기 다른 전문가에게 맡기라"는 지시는 하지 않기 때문이다. 지금은 "큰 일이 카드로 쪼개진다"까지만 잡으면 된다.

쪼개는 것보다 어려운 건 순서다. 어떤 카드는 앞 카드가 끝나야 시작할 수 있고, 어떤 카드는 동시에 해도 된다. Hermes는 이 순서를 프롬프트의 말이 아니라 데이터 구조로 강제한다. 카드를 만들 때 "이 카드들이 부모"라고 지정하면, 그 카드는 부모가 전부 완료될 때까지 대기 상태에 머물다가 부모가 다 끝나는 순간 자동으로 진행 가능 상태로 올라간다.

위 다이어그램은 여러 갈래로 퍼졌다가(팬아웃) 다시 한 점으로 모이는(팬인) 작업 그래프를 보여준다. 비용 비교와 성능 비교 두 리서치 카드는 서로 의존하지 않아 부모 없이 만들어지고, 분배기가 둘을 동시에 병렬로 띄운다. 종합 카드는 그 두 리서치 카드를 부모로 지정했기 때문에 둘 다 끝나기 전에는 진행 가능 상태가 되지 않는다. 메모 작성 카드는 다시 종합 카드를 부모로 둔다. 이 패턴의 가치는 병렬화와 순서 보장을 동시에 얻는다는 것이다 — 독립적인 일은 동시에 빨리 처리하고, 진짜 의존 관계만 순서로 묶는다. 바로 이 대목이 OpenClaw 자동화와 가장 선명하게 갈리는 지점이다. 트리거 층에는 여러 카드를 병렬로 분배하거나 카드 사이의 선후 관계를 자동으로 푸는 개념 자체가 없다 — 그 층의 일은 "언제 깨우나"까지이고, "깨어난 여럿을 어떤 순서로 엮나"는 온전히 이 오케스트레이션 층의 몫이기 때문이다.

접점은 하나 — 죽어도 살아남는 작업 상태

서로 다른 층을 다루지만, 두 시스템이 손을 맞대는 접점이 딱 하나 있다. 바로 작업 상태의 영속화(persistence)다. OpenClaw의 예약 트리거는 SQLite(파일 기반 관계형 데이터베이스)에 저장돼 봇을 재시작해도 예약과 실행 기록이 남고, Hermes의 칸반 카드도 하나의 SQLite 파일(~/.hermes/kanban.db)에 저장돼 프로세스가 죽어도 카드와 진행 상태가 디스크에 그대로 남는다.

위 다이어그램은 다른 층을 다루는 두 시스템이 어떻게 같은 뿌리로 모이는지 보여준다. 한쪽은 "언제 깨울지"의 예약 정보를, 다른 쪽은 "누가 무엇을 어디까지 했는지"의 분업 상태를 저장하지만, 둘 다 그 상태를 메모리가 아니라 디스크의 관계형 데이터베이스에 두었다는 점에서 만난다. 그래서 두 시스템 모두 프로세스가 갑자기 죽어도 예약이나 진행 중인 카드를 잃지 않고, 다시 떠오른 뒤 회수하거나 재시도할 수 있다. 정직하게 말하면 이건 기능의 직접 대응이 아니다 — 다른 층의 서로 다른 대상을 저장할 뿐이다. 다만 "자동화가 신뢰받으려면 프로세스의 생사와 무관하게 작업이 살아남아야 한다"는 요구가 층을 가리지 않고 똑같이 작동한다는 것, 그 하나가 겹친다.

정리 — 자동화의 서로 다른 층

결국 두 시스템은 자동화라는 한 단어 안에서 서로 다른 층을 맡는다. OpenClaw는 "혼자 일하는 에이전트를 언제 깨울까"라는 앞 층을 트리거로 풀고, Hermes 칸반은 "깨어난 여럿이 한 일을 어떻게 나눌까"라는 뒷 층을 보드로 푼다.

	OpenClaw Automation	Hermes kanban
다루는 층	트리거 — 단일 에이전트를 '언제' 깨우나	오케스트레이션 — 깨어난 '여럿이 어떻게' 나누나
공통 접점	예약 트리거를 SQLite에 영속화	카드·진행 상태를 SQLite에 영속화

어느 쪽이 더 낫다기보다, 자동화 파이프라인에서 맡는 자리가 다르다. OpenClaw의 트리거는 "혼자서도 알아서 시작하는" 에이전트를 만드는 데 강하고 — 정해진 때·외부 사건에 봇을 깨우는 일이라면 이 층이 딱 맞다. Hermes의 칸반은 "깨어난 여럿이 큰 일을 안전하게 나눠 맡는" 데 강하고 — 성격이 다른 전문가가 여럿 필요하거나, 크래시·재시작을 견디며 이어져야 하거나, 사람이 중간에 끼어들 수 있어야 하는 작업이라면 이 층이 필요하다. 자동화를 끝까지 밀어 보면 결국 두 층이 다 필요해진다 — "언제 깨우나"를 앞에서 풀고, 깨어난 다음 "여럿이 어떻게 나누나"를 뒤에서 잇는 식으로.

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.

AI가 긴 작업에서 계획을 어디에 두나 — OpenClaw는 맥락 속에, Hermes는 외부 목록에

타이젠 개발자, 윤진 — Sat, 25 Jul 2026 23:00:37 +0900

개인 AI 어시스턴트 OpenClaw를 다룰 때, 그 봇은 사람이 시킨 여러 단계짜리 일을 메신저 채널에서 이어 처리했다. 그런데 도구 목록을 아무리 뒤져도 "긴 작업의 계획을 따로 적어 추적하는" 전용 도구는 없었다. 가장 가까운 것이 message 도구인데, 이건 에이전트가 채널로 결과를 능동 발신하는 도구지 계획을 붙들어 두는 도구가 아니다. 그래서 OpenClaw에서 "다음에 뭘 할지"라는 계획은 늘 대화 그 자체 — 즉 AI가 한눈에 보는 맥락 창(context window — 모델이 한 번에 입력으로 받는 대화·문서의 최대 분량) 안에 암묵적으로만 존재했다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 내부를 뜯어보니, 정확히 이 지점에 전용 도구를 하나 박아 두었다. 이름은 todo — AI가 자기 할 일 목록을 대화 밖 별도 저장소에 적고 지워 가며 일하는 도구다. 여기서 한 가지 축이 선명하게 갈린다. 긴 멀티스텝 작업에서 '계획'을 어디에 두느냐다 — 휘발성 맥락 안에 그냥 두느냐(OpenClaw, 전용 장치 없음), 아니면 도구가 관리하는 영속 외부 상태로 빼서 붙드느냐(Hermes todo). 이 글은 그 갈림길 하나만 따라간다.

같은 문제, 갈라지는 결정 — 계획을 맥락에 둘까, 외부 목록으로 뺄까

두 봇이 마주한 문제는 똑같다. AI 에이전트가 하는 일은 대부분 "이 저장소를 클론해 테스트를 돌리고, 실패 항목을 고친 뒤 PR을 올려라" 같은 여러 단계로 이뤄진 긴 작업이다. 한 번의 응답으로 끝나지 않고, 명령을 여러 번 실행하고 중간 결과를 읽으며 수십 턴을 이어 간다. 이때 "전체 계획"을 어디에 보관하느냐에서 두 봇의 결정이 갈린다.

▲ OpenClaw — 계획을 붙드는 전용 도구 없이, 대화 맥락 안에 둔다

위 다이어그램은 OpenClaw가 계획을 두는 자리를 요약한 것이다. 계획을 따로 관리하는 도구가 없으니, "다음에 뭘 할지"는 명령 실행 결과나 로그와 나란히 대화 맥락 안에 평범한 문장으로 얹힌다. 즉 계획이 다른 대화 내용과 동등한 취급을 받는다. 이건 결함이 아니라 설계 선택에 가깝다 — OpenClaw는 사람과 메신저로 주고받는 상호작용에 무게를 뒀고, 그 결과 계획 추적을 위한 별도 장치를 두지 않았다.

▲ Hermes — 계획을 도구가 쥔 외부 목록으로 빼 둔다

위 다이어그램은 Hermes가 같은 계획을 어디에 두는지 보여준다. 할 일 목록은 대화 안이 아니라 TodoStore라는 대화 밖 별도 저장소에 살고, AI는 todo 도구를 통해서만 그 목록을 읽고 쓴다. OpenClaw와의 결정적 차이가 여기서 갈린다 — 한쪽은 계획을 휘발성 맥락에 얹었고, 다른 쪽은 도구가 관리하는 외부 상태로 떼어 냈다. 왜 이 차이가 중요한지는 다음 두 장면에서 드러난다.

맥락에만 둔 계획은 압축을 못 넘는다 — OpenClaw가 감수하는 것

대규모 언어 모델(LLM, 사람의 말로 대화하고 작업을 수행하는 AI)의 맥락 창은 사람으로 치면 "한눈에 들어오는 책상 위 면적"이다. 대화가 길어지면 이 책상이 꽉 차고, 오래된 종이는 책상 밖으로 밀려난다. 계획을 그 책상 위 문장으로만 적어 둔다면, 계획도 오래된 종이와 똑같은 운명을 맞는다.

위 다이어그램은 계획을 맥락에만 둔 구성이 긴 작업에서 길을 잃는 과정을 보여준다. 다섯 단계짜리 지시를 한 단계씩 실행하다 보면 명령 결과와 로그가 책상을 빠르게 채우고, 어느 순간 한눈에 담을 분량을 넘긴다. 그 시점부터 가장 오래된 내용 — 처음 받은 전체 지시와 이미 끝낸 단계들 — 이 시야에서 사라진다. 함정은 이게 모델이 멍청해서가 아니라 구조적으로 일어나는 일이라는 점이다. 더 똑똑한 모델을 써도 책상이 좁으면 오래된 종이는 똑같이 밀려난다. 계획을 위한 전용 도구가 없는 OpenClaw식 구성은, 긴 자율 작업에서 바로 이 흐름에 그대로 노출된다.

결정타는 맥락 압축(context compression — 대화가 너무 길어졌을 때 오래된 내용을 짧은 요약으로 줄여 책상 공간을 비우는 작업)이다. 압축이 일어나면 상세한 대화 기록이 요약으로 쪼그라드는데, 계획을 대화 문장으로만 적어 뒀다면 그 계획도 요약에 뭉개져 사라진다. Hermes가 굳이 계획을 도구로 떼어 낸 이유가 여기 있다.

Hermes의 답 — 계획을 도구가 쥔 외부 목록으로 뺀다

Hermes의 todo 저장소는 대화 한 세션당 하나씩 생성되고, 각 할 일 항목은 세 가지 정보만 갖는다.

# 할 일 항목 하나의 구조 (todo_tool.py)
# id      : 항목을 가리키는 고유 식별자 (AI가 직접 정함)
# content : 할 일 내용 (짧은 작업 설명)
# status  : 진행 상태 — 아래 네 가지 중 하나
VALID_STATUSES = {"pending", "in_progress", "completed", "cancelled"}
#   pending     = 아직 안 함
#   in_progress = 지금 하는 중
#   completed   = 끝냄
#   cancelled   = 취소함(실패했거나 불필요해짐)

코드 설명. 할 일 항목 하나가 어떤 모양인지 보여준다. 식별자, 내용, 상태 — 딱 세 칸이다. 핵심은 상태가 네 단계로 명시적이라는 점이다. "아직 안 함 / 지금 하는 중 / 끝냄 / 취소함"을 AI가 항목마다 표시하므로, 목록만 보면 전체 진행 상황이 한눈에 잡힌다. 계획이 대화 문장으로 흩어져 있던 OpenClaw 쪽과 달리, 여기서는 진행 상태가 데이터로 못 박혀 있다. 완료와 취소를 굳이 나눈 이유도 있는데, 실패해서 접은 항목을 끝낸 항목과 똑같이 두면 AI가 "이건 했네"라고 착각하기 때문이다.

압축을 타고 살아남는다

진짜 핵심은 이 목록이 맥락 압축을 견디고 살아남는다는 데 있다. 압축이 일어나 상세한 대화 기록이 사라지는 바로 그 순간, Hermes는 todo 목록을 압축된 대화 뒤에 다시 끼워 넣는다.

# 맥락 압축 직후 — 할 일 목록을 다시 주입 (conversation_compression.py)
todo_snapshot = agent._todo_store.format_for_injection()
if todo_snapshot:
    # 압축된 대화 기록 뒤에 할 일 목록을 user 메시지로 덧붙임
    compressed.append({"role": "user", "content": todo_snapshot})

코드 설명. 대화를 압축해 책상을 비운 직후, 별도 저장소에 살아 있던 할 일 목록을 꺼내 압축된 대화 뒤에 다시 붙이는 장면이다. 다른 모든 게 짧은 요약으로 쪼그라들어도 계획만큼은 온전한 형태로 책상 위에 다시 놓인다. 이게 앞 장면의 "계획이 압축에 뭉개진다"는 문제를 정면으로 푸는 지점이다 — 계획을 대화와 분리해 뒀기 때문에, 대화가 압축돼도 계획은 그 운명을 따라가지 않고 매번 새로 주입된다. 즉 todo 목록은 압축이라는 파도를 타고 넘는 부표처럼 동작한다. OpenClaw처럼 계획을 맥락에만 뒀다면 이 파도에 계획이 함께 쓸려 갔을 자리다.

주입할 때 한 가지 영리한 선별이 들어간다. 끝냈거나 취소한 항목은 빼고, 아직 안 한 것과 하는 중인 것만 다시 넣는다.

위 다이어그램은 압축 후 어떤 항목만 골라 되돌리는지 보여준다. 아직 안 한 항목과 지금 하는 중인 항목만 책상 위로 올리고, 이미 끝냈거나 취소한 항목은 일부러 뺀다. 끝낸 항목까지 매번 다시 보여 주면, AI가 압축 직후 "어 이것도 해야 하나?" 하며 이미 마친 일을 다시 하는 사고가 생기기 때문이다. 직관과 반대인데 — 완료한 일을 계속 보여 주는 게 친절해 보이지만, 실제로는 그게 중복 수행을 부르는 덫이다. "보여 주지 않음"이 오히려 안전한 설계다.

인스턴스가 새로 떠도 계획은 복구된다

Hermes의 게이트웨이(텔레그램·디스코드 같은 메신저 메시지를 받아 AI에 넘기는 입구)는 메시지가 올 때마다 AI 인스턴스를 새로 만든다. 그러면 메모리에 살던 todo 저장소도 매번 텅 빈 채로 시작한다 — 계획을 맥락에만 뒀다면 매 메시지마다 계획이 리셋되는 셈이다. Hermes는 이 빈틈도 외부 상태로 막는다.

위 다이어그램은 매번 새로 태어나는 AI가 어떻게 직전 계획을 되찾는지 보여준다. 새 인스턴스의 할 일 저장소는 비어 있으므로, 지난 대화 기록을 가장 최근 쪽부터 거꾸로 훑어 마지막으로 남긴 todo 응답을 찾아낸다. todo 도구는 호출될 때마다 항상 목록 전체를 응답으로 남기기 때문에, 그 최신 응답 하나만 찾으면 계획의 완전한 스냅샷이 통째로 잡힌다. 그걸 저장소에 다시 채우면 계획이 복구되고, AI는 끊김 없이 작업을 이어 간다. 계획이 대화 맥락이 아니라 되찾을 수 있는 외부 상태로 존재하기에 가능한 복구다.

정리 — 계획을 어느 층에 맡겼나

결국 두 봇은 "긴 작업을 끝까지 추적하라"라는 같은 요구를, 계획을 어디에 두느냐라는 결정 하나로 전혀 다르게 감당한다. OpenClaw는 계획을 휘발성 맥락에 두고 전용 장치를 두지 않았고, Hermes는 계획을 도구가 쥔 영속 외부 상태로 떼어 냈다.

	OpenClaw	Hermes
계획이 사는 곳	맥락 창 안 — 전용 도구 없이 대화 문장으로	대화 밖 todo 목록 — 도구가 상태로 관리
맥락 압축·인스턴스 재시작 때	계획도 함께 휘발·리셋될 수 있음	미완 항목만 자동 재주입·복구

어느 쪽이 옳다기보다, 각자 강한 자리가 다르다. OpenClaw는 사람과 메신저로 주고받는 상호작용에 무게를 뒀고, 결과를 채널에 능동 발신하는 message 같은 도구가 그 강점이다 — 대신 긴 자율 작업에서 계획을 붙드는 장치는 감수하지 않았다. Hermes의 todo는 화려한 기능이 아니라 "AI가 긴 작업의 전모를 잊지 않게 붙들어 주는 외부 기억 장치"다. 사람도 복잡한 일을 할 때 머릿속에만 담아 두지 않고 종이에 할 일을 적어 하나씩 지워 나간다. 맥락 창은 좁고 대화는 압축되며 인스턴스는 매번 새로 뜨는데, 그 모든 휘발을 견디고 살아남는 한 장의 목록이 있느냐 없느냐가 "다섯 단계짜리 작업을 끝까지 해내는 에이전트"와 "세 단계쯤에서 길을 잃는 에이전트"를 가른다.

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.

AI가 나를 오래 기억하는 두 방식 — OpenClaw는 검색으로 회상하고, Hermes는 늘 머릿속에 둔다

타이젠 개발자, 윤진 — Sat, 25 Jul 2026 22:00:14 +0900

개인 AI 어시스턴트 OpenClaw를 다룰 때, 그 봇이 나를 세션 너머로 기억하는 방식은 마크다운 파일에 사실을 쌓아 두고, 대화 도중 필요해지면 그때그때 꺼내 오는 것이었다. 기본적인 LLM(Large Language Model, 대량 텍스트로 학습한 언어 모델 — ChatGPT·Claude 같은 것의 엔진) 대화는 한 세션이 끝나면 그 안의 기억이 통째로 증발한다 — 어제 "코드 설명은 짧게 해줘"라고 말해도 오늘 새 창을 열면 또 장황하게 답하는 식이다. 이 글이 다루는 "기억"은 바로 이 세션의 경계를 넘어 지속되는 장기 기억(long-term memory, 영속 기억)이다. 대화 도중에만 컨텍스트에 떠 있다가 세션과 함께 사라지는 단기 기억이나, 특정 사건 하나하나를 시점과 함께 기록하는 에피소드 기억이 아니라, "어제 한 말을 오늘도 아는" 지속성 그 자체를 말한다. OpenClaw는 그 사라진 기억을 파일에 남겨 두고, 회상할 때 임베딩 기반 시맨틱 검색(semantic search — 단어가 달라도 뜻이 비슷하면 찾아내는 의미 검색)으로 되살렸다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 memory 도구의 내부를 뜯어보니, 정확히 반대편에서 같은 문제를 풀고 있었다. Hermes는 기억을 검색으로 꺼내지 않는다. 대신 두 개의 아주 작은 파일(합계 약 3,600자 상한)에 욱여넣고, 매 세션 시작마다 그 전부를 시스템 프롬프트에 통째로 상주시킨다 — 찾을 필요 없이 늘 머릿속에 둬 버리는 것이다. 이 글은 그 갈림길 하나만 따라간다 — 장기 기억을 '항상 상주'시키느냐, '필요할 때 검색'해 회상하느냐. 나머지 차이는 전부 여기서 파생된다.

같은 문제, 갈라지는 결정 — 늘 상주시킬까, 검색으로 꺼낼까

두 봇이 푸는 문제는 똑같다. "세션이 바뀌어도 사용자를 기억하라." 그런데 그 목표에 도달하는 첫 결정에서 갈린다. OpenClaw는 기억을 넉넉히 쌓아 두고 필요한 순간 의미로 검색해 꺼내는 쪽을 택했고, Hermes는 소수의 핵심만 골라 매 세션 처음부터 머릿속에 상주시키는 쪽을 택했다. 두 스택을 나란히 보면 결정의 방향이 반대라는 게 한눈에 드러난다.

▲ OpenClaw — 파일에 쌓아 두고, 필요할 때 의미로 검색

위 다이어그램은 OpenClaw가 기억을 다루는 흐름을 한 줄기로 요약한 것이다. 사실을 마크다운 파일에 계속 쌓아 두되, 그것을 매 대화에 통째로 들고 있지는 않는다. 대신 의미 색인을 미리 만들어 두고, 대화 도중 과거 정보가 필요해지는 순간에만 검색으로 꺼내 온다. 여기서 "기억"은 곧 "필요할 때 잘 찾아내느냐"의 문제로 환원된다 — 평소에는 기억이 대화 밖 창고에 잠들어 있고, 호출당할 때만 깨어난다.

▲ Hermes — 두 작은 파일을 매 세션 통째로 머릿속에

위 다이어그램은 Hermes가 같은 문제를 반대편에서 푸는 방식이다. 기억을 딱 두 개의 작은 파일로 나눠 담는다 — 하나는 환경 사실·프로젝트 관례를 적는 에이전트의 개인 노트, 다른 하나는 이름·역할·말투 선호를 적는 사용자 프로필이다. 둘을 합쳐 약 3,600자라는 좁은 칸에 가두고, 세션이 시작될 때마다 그 전부를 시스템 프롬프트(system prompt — AI에게 주는 기본 지침문, 매 대화 맨 앞에 고정으로 붙는다)에 통째로 끼워 넣는다. 검색이라는 단계가 아예 없다 — 기억은 늘 대화 첫머리에 떠 있으므로 찾을 필요 없이 즉시 참조된다. 대신 그 대가로, 담을 수 있는 양이 이 좁은 칸으로 못 박힌다.

상주의 값 — 즉시 참조되지만, 칸이 작다

기억을 늘 머릿속에 두는 쪽의 이득은 분명하다. 검색이라는 왕복이 없으니 지연도 실패도 없고, AI는 매 순간 사용자 선호를 이미 알고 있다. 그런데 "매 세션 통째로 주입"에는 미묘한 트레이드오프가 하나 숨어 있다. 저장한 기억이 방금 세션에는 왜 안 보이는지를 보면 그 값이 드러난다.

위 다이어그램은 "늘 상주"를 값싸게 유지하는 장치를 보여준다. 세션 시작 시 기억 파일을 읽어 시스템 프롬프트에 한 번 박아 넣고(스냅샷), 세션 도중 AI가 기억을 추가·수정하면 디스크 파일은 즉시 바뀌지만 시스템 프롬프트 스냅샷은 끝까지 고정한다. 왜 이렇게 하냐면 prefix cache(접두 캐시 — 프롬프트 앞부분이 매 턴 똑같으면 모델이 그 부분의 계산을 재활용해 응답을 싸고 빠르게 내는 최적화) 때문이다. 상주 기억을 세션 중간에 바꾸면 이 캐시가 깨져 매 턴 처음부터 다시 계산해야 한다. 놓치기 쉬운 점은 "기억을 저장했는데 AI가 바로 모르네?"라는 의문인데, 디스크엔 분명히 적혔고 다음 세션부터 스냅샷에 반영된다.

대신 상주 기억은 크기를 키울 수 없다. 매 세션 통째로 시스템 프롬프트에 들어가는 만큼, 칸이 커지면 그대로 매 세션의 토큰(token — LLM이 텍스트를 처리하는 최소 단위, 비용·속도가 토큰 수에 비례) 비용이 된다. 그래서 Hermes는 칸을 일부러 3,600자로 좁혀 두고, 그 좁은 칸이 가득 차면 오래된 항목을 소리 없이 밀어내지 않고 저장을 거부해 AI에게 정리를 시킨다 — 겹치는 항목을 한 줄로 합치거나 낡은 항목을 지워 다시 담게 한다. 상주 방식의 값은 이렇게 "즉시 참조되지만, 무엇을 넣을지 매번 세밀하게 큐레이션해야 한다"로 요약된다.

검색의 값 — 무한정 쌓지만, 설정이 필요하다

반대편 OpenClaw는 기억을 대화에 상주시키지 않으므로, 칸 크기를 걱정할 이유가 없다. 파일에 얼마든 쌓아 두고 필요할 때만 꺼내면 된다. 대신 "필요할 때 잘 꺼내는" 능력 자체를 따로 갖춰야 한다.

위 다이어그램은 검색으로 회상하는 쪽의 이득과 대가를 함께 보여준다. 가장 큰 강점은 의미로 찾는다는 점이다 — 사용자가 저장할 때 쓴 단어와 물어볼 때 쓴 단어가 달라도, 뜻이 가까우면 끌어올린다. 비용 구조도 상주 방식과 정반대다. 기억이 대화에 늘 실려 있지 않으니 평소 토큰 비용은 0이고, 실제로 검색하는 그 순간에만 약간의 지연이 든다. 대가는 준비물이다 — 의미 검색은 텍스트를 벡터로 바꾸는 임베딩(embedding — 문장을 뜻이 담긴 숫자 배열로 변환하는 것) 모델을 갖춰야 돌아가고, 회상이 얼마나 정확한지는 그 모델과 설정에 달려 있다. 상주 방식이 "칸 관리"라는 숙제를 진다면, 검색 방식은 "검색 엔진 준비"라는 숙제를 진다.

정리 — 기억을 어디에 두었나

결국 두 봇은 "세션을 넘어 사용자를 기억하라"라는 같은 목표를, 기억을 어디에 두느냐 하나로 정반대 층에서 푼다. Hermes는 소수의 핵심을 대화 첫머리에 늘 상주시켜 검색 없이 즉시 꺼내 쓰고, OpenClaw는 방대한 기록을 대화 밖 창고에 쌓아 두고 필요할 때 의미로 검색해 꺼낸다.

	Hermes	OpenClaw
회상 방식	시스템 프롬프트에 늘 상주 — 검색 없이 즉시 참조	마크다운에 쌓아 두고 의미로 검색해 회상
대가	매 세션 토큰 비용 고정 · 칸이 작아 세밀한 큐레이션 필요	용량 걱정은 없으나 임베딩 모델 설정·품질에 의존

어느 쪽이 옳다기보다, 강한 자리가 다르다. 기억을 소수의 핵심으로 좁혀 늘 곁에 두고 즉시 반응하게 하고 싶다면 Hermes의 상주 방식이 강하다 — 대신 무엇을 그 좁은 칸에 넣을지 부지런히 관리해야 한다. 대화 기록을 넓게 쌓아 두었다가 나중에 "단어가 달라도 뜻으로" 회상하고 싶다면 OpenClaw의 검색 방식이 강하다 — 대신 임베딩 모델을 갖추고 검색 품질을 챙겨야 한다. "어제 한 말을 오늘도 아는" 연속성은 자율 에이전트의 진짜 전제 조건이지만, 그 연속성을 늘 머릿속에 둘 것인가, 필요할 때 찾아올 것인가가 이 두 봇을 가르는 첫 갈림길이었다.

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.

AI에게 파일 수정을 맡길 때 — OpenClaw는 어긋나면 멈추고, Hermes는 어긋나도 고친다

타이젠 개발자, 윤진 — Sat, 25 Jul 2026 21:00:22 +0900

개인 AI 어시스턴트 OpenClaw를 다룰 때, 그 봇은 파일을 통째로 다시 쓰지 않고 바뀔 부분만 골라 고치는 도구(apply_patch)를 AI에게 쥐여 줬다. 방식은 unified diff(통합 diff — 없앨 줄 앞에 -, 추가할 줄 앞에 +를 붙여 변경분만 적는 표기)다. 그런데 이 도구에는 완고한 규칙이 하나 있다 — -로 적은 원본 줄이 실제 파일에 그대로 있지 않으면, 곧장 충돌로 보고 수정을 거부한다. "네가 없앤다고 적은 그 줄이 지금 파일엔 없는데?"라며 멈춰 서는 것이다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 파일 도구를 뜯어보니, 정확히 같은 문제를 반대편에서 풀고 있었다. 두 봇 다 파일 능력을 4개 도구(읽기·전체 덮어쓰기·부분 수정·검색)로 쪼갠다는 출발점은 똑같다. 갈림길은 딱 한 지점에서 생긴다 — "AI가 기억으로 재현한 원본 문자열이 실제 파일과 미세하게 어긋날 때 어떻게 할 것인가." OpenClaw는 멈추고 다시 읽으라 하고, Hermes는 너그럽게 흡수해 그냥 성공시킨다. 이 글은 그 갈림길 하나만 따라간다.

같은 문제, 갈라지는 결정 — 부분 수정에서 원본이 어긋날 때

AI가 파일을 "부분만" 고치려면 먼저 바꿀 위치를 파일 안에서 찾아야 한다. 그런데 LLM(대형 언어 모델 — 자연어로 명령을 받아 행동하는 AI)이 "이 줄을 저 줄로 바꿔"라고 지시할 때, 그 "이 줄"은 AI가 기억으로 재현한 문자열이라 원본과 들여쓰기 한 칸, 따옴표 한 종류만 달라도 어긋나기 일쑤다. 두 봇은 이 어긋남을 정반대로 대한다.

▲ OpenClaw — 원본이 어긋나면 멈추고 다시 읽게

위 다이어그램은 OpenClaw가 부분 수정 요청을 받았을 때 거치는 관문을 보여준다. 핵심은 가운데 판정 하나다 — AI가 "없앤다"고 적은 원본 줄이 지금 파일에 글자 그대로 존재하는지 대조하고, 존재하면 적용하고 아니면 충돌로 보고 거부한다. 이 설계의 의도는 "불확실하면 손대지 말라"다. AI가 가진 원본이 실제 파일과 다르다는 건, AI의 기억이 낡았거나 그새 파일이 바뀌었다는 신호일 수 있으니, 억지로 밀어붙이는 대신 멈춰서 다시 읽게 만든다. 거부가 끝이 아니라 "다시 읽고 새 diff를 만들라"는 다음 행동으로 이어진다는 점이 중요하다.

▲ Hermes — 원본이 어긋나도 너그럽게 찾아 성공

위 다이어그램은 같은 상황을 Hermes가 어떻게 다루는지 보여준다. 정확히 일치하는 곳이 있으면 바로 치환하지만, 어긋나면 OpenClaw처럼 멈추지 않는다. 대신 퍼지 매칭(엄격한 정확 일치 대신, 사소한 차이를 너그럽게 봐주며 찾는 방식)으로 기준을 한 단계씩 풀어 가며 "그래도 여기가 맞겠지" 싶은 자리를 찾아낸다. 어지간해서는 수정이 성공한다. 두 그림을 나란히 놓으면 태도 차이가 선명하다 — 한쪽은 어긋남을 멈춰야 할 신호로 읽고, 다른 쪽은 흡수해야 할 잡음으로 읽는다. 아래 두 섹션에서 각자가 왜 그렇게 정했는지를 하나씩 뜯어본다.

Hermes의 길 — 어긋남을 관대히 흡수한다 (퍼지 매칭 8단계)

Hermes의 부분 수정 도구는 "바꿀 문자열"을 찾을 때 정확 일치를 고집하지 않는다. 실패할 때마다 기준을 한 칸씩 느슨하게 푸는 8단계 사다리를 순서대로 밟는다. 처음부터 느슨하게 찾지 않고 단계적으로 너그러워지는 게 이 설계의 요령이다.

위 다이어그램은 바꿀 문자열을 찾는 시도가 점점 너그러워지는 사다리를 보여준다. 가장 안전한 정확 일치부터 시작해, 실패할 때마다 한 칸씩 기준을 푼다 — 줄 앞뒤 공백을 무시하고, 연속된 공백을 하나로 보고, 들여쓰기 깊이를 유연하게 맞추고, 따옴표 이스케이프와 유니코드 표기 차이를 정규화하고, 끝내 안 되면 바꿀 덩어리의 첫 줄과 끝 줄만으로 범위를 추정한다. 왜 처음부터 느슨하게 찾지 않을까? 느슨한 잣대를 먼저 들이대면 엉뚱한 곳을 잘못 잡을 위험이 크기 때문이다 — 그래서 정확 일치를 먼저 시도하고, 정말 안 될 때만 한 단계씩 위험을 감수한다. 놓치기 쉬운 함정도 하나 챙긴다. 너그러운 단계로 찾았을 땐 AI가 보낸 새 내용을 그대로 박으면 들여쓰기가 깨질 수 있어, 원본의 들여쓰기에 맞춰 다시 정렬한다. 그리고 8단계가 전부 실패해도 그냥 "실패"가 아니라 "파일을 다시 읽어 현재 내용을 확인하라"는 안내와 비슷한 구간 제안을 붙여, AI가 낡은 기억으로 같은 실패를 반복하지 않게 한다. 요컨대 Hermes는 어긋남을 극복할 대상으로 본다.

OpenClaw의 길 — 어긋남을 충돌로 읽고 멈춘다

OpenClaw의 apply_patch는 정반대 전제 위에 선다. AI가 없앤다고 적은 원본 줄이 실제 파일과 다르다면, 그건 억지로 맞춰 줄 사소한 오차가 아니라 "내가 아는 파일이 지금 파일이 아니다"라는 경고라는 것이다. 그래서 관대하게 찾아 주는 대신 충돌로 처리하고 멈춘다. 언뜻 불편해 보이는 이 완고함이, 뜻밖에 동시 편집 방어 역할까지 겸한다.

위 다이어그램은 여러 작업이 같은 파일을 건드리는 상황에서 이 완고함이 어떻게 안전장치가 되는지 보여준다. 내가 파일을 읽은 뒤 아무도 그 파일을 손대지 않았다면, 없앨 줄이 그대로 남아 있으니 패치가 곧장 적용된다. 그런데 그새 다른 작업이 같은 파일을 고쳤다면, 내가 없앤다고 적은 원본 줄은 이미 사라졌거나 달라져 있어 대조가 어긋나고, 그 순간 충돌로 거부된다. 별도의 잠금 장치나 버전 추적 없이, diff의 대조 규칙 자체가 "네가 본 파일은 이미 낡았다"를 자동으로 감지하는 셈이다. 대가는 분명하다 — 원본이 조금만 어긋나도 실패하니, AI가 다시 읽고 diff를 새로 만드는 왕복이 잦아진다. 그러나 그 왕복이야말로 OpenClaw가 원하는 바다. "확실할 때만 쓴다"는 규율을 도구 차원에서 강제하는 것이다.

정리 — 어긋남을 신호로 볼까, 잡음으로 볼까

결국 두 봇은 파일을 4개 도구로 쪼갠다는 같은 출발점에서, 부분 수정의 원본이 어긋나는 한 지점에서 정확히 갈라진다. 한쪽은 어긋남을 멈춰야 할 신호로, 다른 쪽은 흡수해야 할 잡음으로 읽는다.

	OpenClaw (apply_patch)	Hermes (patch)
원본이 어긋날 때	충돌로 보고 즉시 거부 → 다시 읽게 유도	퍼지 매칭 8단계로 흡수해 수정 성공
어긋남을 읽는 관점	"파일이 바뀌었다"는 신호 — 보수적	"사소한 차이"인 잡음 — 실용적

어느 쪽이 옳다기보다, 잘 맞는 환경이 다르다. Hermes의 관대한 퍼지 매칭은 혼자 순차적으로 파일을 고치는 상황에서 강하다 — AI의 기억이 조금 부정확해도 매번 다시 읽는 왕복 없이 술술 진행되니, 마찰이 적고 빠르다. 반대로 OpenClaw의 충돌 거부는 여러 AI 작업이 같은 파일을 동시에 건드리는 상황에서 빛난다 — 남이 바꾼 파일을 낡은 기억으로 덮어써 최신 변경을 조용히 날리는 사고를, 도구가 알아서 충돌로 걸러 내기 때문이다. 그래서 "어느 쪽이 더 나은가"의 답은 결국 하나로 수렴한다 — 여러 작업이 같은 파일을 얼마나 자주 동시에 건드리는 환경이냐. 동시 편집이 드물면 관대함이 이득이고, 잦으면 완고함이 안전이다. 같은 문제 앞에서 두 봇이 내린 반대 결정은, 각자가 상정한 작업 환경이 서로 달랐다는 뜻이다.

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.

봇의 두뇌를 어디에 둘 것인가, 두 갈래 — OpenClaw는 봇 성격에 붙박고, Hermes는 화면에서 갈아끼운다

타이젠 개발자, 윤진 — Fri, 24 Jul 2026 23:00:40 +0900

개인 AI 어시스턴트 OpenClaw를 다룰 때, "이 봇은 어떤 LLM 모델(거대 언어 모델 — 텍스트를 이해하고 생성하는 AI)로 생각하는가"는 따로 떼어 고르는 항목이 아니었다. 모델은 봇 하나하나에 딸린 정책 묶음의 한 조각이었다 — 모델, 사고 깊이, 쓸 수 있는 도구, 스킬, 기억이 한 덩어리로 묶여 그 봇의 "성격"을 이룬다. 그래서 가족용 봇은 가벼운 모델을 달고, 프로젝트용 봇은 고급 모델을 달고, 메시지는 채널 라우팅으로 제 성격에 맞는 봇에게 흘러간다. 모델을 봇에 붙박아 둔 덕에 봇 성격의 일관성이 지켜지는 구조다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 대시보드를 뜯어보니, 정확히 반대편에서 같은 문제를 풀고 있었다. Hermes는 모델을 봇 성격에 묶지 않는다. 오히려 모델 전환의 자유 자체를 핵심 가치로 삼아, "Models"라는 독립된 대시보드 화면에 모델 선택을 따로 빼놓고 언제든 프로바이더·모델을 갈아끼우게 만든다. 이 글은 딱 그 한 가지 갈림길 — "모델 선택을 봇 성격의 일부로 붙박을 것인가, 아니면 갈아끼우는 자유로 떼어낼 것인가" — 만 따라간다.

같은 문제, 갈라지는 결정 — 모델을 어디에 두는가

두 봇 다 "이 에이전트는 어떤 모델로 사고하는가"라는 같은 질문 앞에 선다. 그런데 그 답을 어디에 적어 두느냐에서 갈린다. OpenClaw는 답을 봇 정의 안에 넣어 성격의 일부로 굳히고, Hermes는 답을 봇 바깥 독립 화면으로 빼내 언제든 바꾸게 한다.

▲ OpenClaw — 모델은 봇 성격을 이루는 한 조각

위 다이어그램은 OpenClaw가 모델 선택을 두는 자리를 보여준다. 하나의 봇 정의 안에 모델·사고 깊이·도구·스킬·기억이 한 묶음으로 딸려 있고, 모델은 그중 한 조각일 뿐이다. 설정 파일(openclaw.json)에서 봇마다 모델 키를 따로 달 수 있고, 전역 기본값을 깔아 두면 봇별로 필요한 것만 덮어쓴다. 핵심은, 모델이 봇 성격에 붙박여 있다는 점이다 — 가족용 봇은 늘 그 가벼운 모델로 대답하고, 프로젝트용 봇은 늘 그 고급 모델로 대답한다. 모델을 함부로 갈아끼우는 게 목적이 아니라, 봇이 일관된 성격을 유지하는 게 목적이기 때문이다.

▲ Hermes — 모델은 언제든 갈아끼우는 독립 화면의 값

위 다이어그램은 Hermes가 모델 선택을 두는 자리다. 봇 정의가 아니라 Models라는 독립 화면에 모델이 얹혀 있고, 사용자가 화면에서 프로바이더와 모델을 고르면 그 선택은 ~/.hermes/config.yaml 설정 파일의 한 줄로만 기록된다. 코드를 한 줄도 건드리지 않고, 다음 세션부터 에이전트는 새 모델로 생각한다. README가 이를 그대로 못 박는다 — "Use any model you want … Switch with hermes model — no code changes, no lock-in." OpenClaw가 모델을 봇 성격에 붙박아 바꾸기 어렵게(대신 일관되게) 만들었다면, Hermes는 모델을 봇 바깥으로 떼어 바꾸기 쉽게 만든 것이다. 두 그림을 같은 축에서 겹쳐 보면 차이가 선명하다 — 한쪽은 모델을 성격에 가두고, 다른 쪽은 성격에서 풀어놓는다.

전환 자유가 실제로 작동하는 법 — 프로바이더 하나가 수백 개 모델을 품는다

모델을 봇 바깥으로 빼놓기만 해서는 "자유"가 완성되지 않는다. 프로바이더(모델 API를 파는 회사·서버)를 바꿀 때마다 새 키를 받고 연결을 다시 걸어야 한다면, 화면에서 고른다는 것도 결국 번거로운 일이 된다. Hermes가 권하는 두 출처 OpenRouter와 Nous Portal은 이 번거로움을 없앤다 — 둘 다 수백 개 모델을 하나의 API·구독으로 묶어 파는 집계 게이트웨이(aggregator)다. README에 따르면 OpenRouter는 200여 개 모델을 한 API로, Nous Portal은 300여 개 모델을 한 구독으로 제공한다.

위 다이어그램은 Hermes의 전환 자유가 어떻게 값싸게 유지되는지 보여준다. 사용자는 통합 게이트웨이 한 곳(예: OpenRouter)에 API 키 하나만 등록해 두면, 그 아래 수백 개 모델 사이를 손가락 하나로 오간다. 여기에 집 서버의 GPU가 놀고 있다면 로컬 모델도 같은 화면에 끌어들일 수 있다 — vLLM(고성능 추론 서버)이나 Ollama(손쉬운 로컬 실행 도구)로 모델을 띄우면 OpenAI와 같은 형식의 주소가 생기고, 이걸 Custom Endpoint(직접 엔드포인트)라는 특수 프로바이더로 등록하면 클라우드 모델과 완전히 똑같이 고를 수 있다. 어느 경우든 모델을 바꿔도 바뀌는 건 설정 파일의 모델 이름 한 줄뿐이다. 이게 README의 "no code changes, no lock-in"이 실제로 도는 메커니즘이고, Hermes가 봇 성격 대신 전환의 마찰 없음을 최우선에 둔 결과다.

같은 자유가 짊어지는 대가 — 성격의 일관성은 스스로 지켜야 한다

모델을 봇 바깥으로 빼내 자유롭게 갈아끼우게 만든 대가는, OpenClaw가 공짜로 얻던 것을 Hermes는 스스로 챙겨야 한다는 데 있다. OpenClaw에서는 모델이 봇에 붙박여 있으니 "가족용 봇은 늘 가벼운 모델", "프로젝트용 봇은 늘 고급 모델"이라는 성격이 저절로 유지됐고, 채널 라우팅이 메시지를 제 성격의 봇에게 흘려보내면 그만이었다. 반면 Hermes에서 모델은 전역 값에 가깝다 — 화면에서 한 번 바꾸면 그 에이전트 전체의 두뇌가 바뀐다. 봇마다 다른 성격을 고정해 두는 일은 이 설계에서 기본으로 주어지지 않는다.

대신 Hermes는 그 자유를 다른 방향의 절약으로 되돌려 받는다. 에이전트는 사용자와 추론·대화하는 메인 작업 말고도, 이미지를 읽고 긴 대화를 압축하고 웹페이지를 요약하고 세션 제목을 짓는 보조 작업(auxiliary task)을 끊임없이 한다. 모델이 봇 바깥의 독립 값이라 나누기 쉬운 덕에, Hermes는 메인 슬롯과 보조 작업용 슬롯을 따로 두고 작업마다 다른 모델을 꽂을 수 있다 — 세션 제목 한 줄에 최고급 모델을 부르는 낭비를 막고, 문서 표현대로 "빠른 채팅 모델이면 1/50 비용으로 같은 일을" 시킨다. OpenClaw가 봇 성격을 묶어 일관성을 얻었다면, Hermes는 모델을 풀어놓은 자유를 작업별 최적화로 환전한 셈이다.

정리 — 자유를 사면 일관성을 내주고, 일관성을 사면 자유를 내준다

결국 두 봇은 "이 에이전트는 어떤 모델로 생각하는가"라는 같은 질문을, 그 답을 어디에 두느냐 하나로 정반대로 푼다. OpenClaw는 모델을 봇 성격에 붙박아 일관성을 사고 전환의 자유를 내줬고, Hermes는 모델을 독립 화면으로 떼어 전환의 자유를 사고 성격의 일관성을 내줬다.

	OpenClaw	Hermes
모델을 두는 자리	봇 정의 안 — 정책 묶음(모델·도구·스킬·기억)의 한 조각	봇 바깥 — 독립된 Models 대시보드 화면의 값
그 자리가 사는 것	봇 성격의 일관성 — 봇마다 고정된 두뇌	전환의 자유 — 언제든 프로바이더·모델을 갈아끼움

어느 쪽이 옳다기보다, 지키려는 것이 다르다. OpenClaw의 붙박이 방식은 "가족용 봇엔 가벼운 모델, 프로젝트용 봇엔 고급 모델"처럼 봇마다 역할이 고정된 운영에서 강하다 — 성격이 흔들리지 않는다. Hermes의 갈아끼우기 방식은 모델 경쟁이 한 달이 멀다 하고 뒤집히는 지금, 더 나은·더 싼 모델로 자주 갈아타며 실험하는 사람에게 강하다 — 두뇌를 부품처럼 교체한다. 봇을 봇답게 만드는 두뇌를 어디에 둘 것인가, 그 한 결정이 이 두 봇을 가르는 갈림길이었다.

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.

봇은 대화를 어떻게 기억하나 — OpenClaw는 격리로, Hermes는 통합검색으로

타이젠 개발자, 윤진 — Fri, 24 Jul 2026 22:00:27 +0900

개인 AI 어시스턴트 OpenClaw를 다룰 때, 세션(대화 기록)은 에이전트별로 격리돼 있었다. 봇마다 자기 대화 저장소가 따로 있고, 세션 도구가 들여다볼 수 있는 범위는 tools.sessions.visibility(self / tree / agent / all) 설정으로 잠긴다. 한 서버에서 여러 봇을 굴려도 서로의 기억이 새지 않게 정책으로 벽을 세우는 방식이다.

또 다른 오픈소스 AI 에이전트 Hermes Agent는 같은 "대화를 어떻게 기억하느냐" 문제를 정반대로 푼다. 벽을 세우는 대신 벽을 허문다 — 터미널·텔레그램·디스코드·예약작업(cron)에서 들어온 모든 대화를 단일 데이터베이스 한 곳에 모으고, 그 위에 전문 검색 색인을 얹어 에이전트가 스스로 자기 과거 전체를 뒤지게 한다. 이 글은 그 한 가지 갈림길 — "기억을 격리해 지킬 것인가, 통합해 검색할 것인가" — 만 따라간다.

같은 문제, 갈라지는 결정 — 기억을 나눌 것인가 모을 것인가

두 봇 다 같은 벽에 부딪힌다. 대화가 휘발되면 봇은 매번 "처음 보는 사람"처럼 군다. 그래서 둘 다 대화를 저장한다. 문제는 그다음 — 저장한 대화를 어떻게 배치하느냐에서 갈린다. OpenClaw는 에이전트마다 저장소를 나눠 가시 범위를 정책으로 통제한다. Hermes는 입구를 가리지 않고 한 곳에 합쳐 통째로 검색 가능하게 만든다.

▲ OpenClaw — 봇마다 기억을 나누고 정책으로 잠근다

위 다이어그램은 앞서 다룬 OpenClaw의 세션 구조다. 봇마다 대화 저장소가 분리돼 있고, 세션 도구가 어느 저장소까지 들여다볼 수 있는지는 가시 범위 설정이 결정한다 — 자기 것만, 자기 계통만, 특정 에이전트만, 아니면 전부. 이 설계가 겨누는 상황은 명확하다 — 한 서버에 여러 봇·여러 사용자가 얹혀 돌 때, 한 봇이 실수로 다른 대화를 참조해 기억이 새는 사고를 정책으로 원천 차단한다.

▲ Hermes — 모든 입구를 한 DB로 합치고 통째로 검색한다

위 다이어그램은 Hermes의 정반대 선택이다. 네 입구(터미널·텔레그램·디스코드·예약 작업)에서 들어온 대화가 전부 단일 SQLite 파일(state.db) 하나로 흘러들고, 거기에 FTS5(SQLite 내장 전문 검색 엔진 — 책 뒤 색인처럼 단어가 어느 메시지에 나오는지 미리 정리해 즉시 찾는다) 색인이 얹힌다. OpenClaw와의 결정적 차이는 마지막 칸이다 — Hermes의 에이전트는 session_search라는 도구를 손에 쥐고 자기 과거 전체를 스스로 뒤진다. OpenClaw가 "어디까지 볼 수 있나"를 정책으로 좁혔다면, Hermes는 "전부 볼 수 있게" 열어 두고 검색 속도로 승부한다.

Hermes가 통합을 택한 대가 — 검색과 충돌을 스스로 풀어야 한다

기억을 한 곳에 모으면 검색은 쉬워지지만, 대신 두 가지 숙제가 새로 생긴다. 하나는 "수백 개 대화 속에서 그것을 어떻게 빨리 찾나", 다른 하나는 "여러 입구가 같은 파일에 동시에 쓸 때 충돌을 어떻게 막나"다. Hermes는 단일 DB 안을 세 표로 나눠 이를 푼다.

위 다이어그램은 통합 저장소 안이 어떻게 나뉘는지 보여준다. 대화 묶음의 요약 정보(출처가 텔레그램인지 예약 작업인지, 제목, 쓴 모델, 토큰 수)를 담는 표, 실제 주고받은 메시지 본문 표, 그리고 그 본문을 빠르게 뒤지기 위한 검색 색인이다. 점선이 핵심이다 — 메시지가 본문 표에 들어갈 때마다 트리거(특정 변경이 일어나면 자동 실행되는 DB 장치)가 색인을 자동 갱신하므로, 사람이 따로 "색인 다시 만들기"를 할 필요가 없다. 동시 쓰기 충돌은 WAL 모드(읽기와 쓰기가 서로를 막지 않는 SQLite 저널 방식)와 무작위 재시도로 직렬화해 막는다 — OpenClaw는 저장소가 격리돼 이 충돌을 이런 형태로 겪지 않지만, 통합을 택한 Hermes는 반드시 풀어야 하는 숙제다.

기억을 스스로 되살리는 봇 — session_search

통합 검색이 만드는 진짜 차이는 사람이 아니라 에이전트 쪽에서 드러난다. 사용자가 "우리 저번에 이거 했잖아"라고 운을 떼면, Hermes의 봇은 되묻는 대신 session_search 도구로 과거 세션을 FTS5로 뒤져 "목표 → 매치 → 결론"에 해당하는 메시지 묶음만 골라 읽고 맥락을 되살린다. LLM 호출도, 요약도 없이 DB에서 실제 메시지를 그대로 가져온다.

위 다이어그램은 Hermes의 봇이 자기 과거를 스스로 참조하는 흐름이다. 사용자가 흘린 한마디를 단서로 에이전트가 검색 도구를 직접 부르고, 색인으로 관련 세션을 찾아 그 실제 메시지를 통째로 맥락에 되살린다. 여기서 OpenClaw와의 철학 차이가 정점을 찍는다 — OpenClaw에서 "무엇을 참조할 수 있나"는 운영자가 정책으로 미리 정하지만, Hermes에서 "무엇을 참조할까"는 에이전트가 검색으로 그때그때 스스로 정한다. 통제의 주체가 사람이냐 봇이냐가 갈린다.

정리 — 여럿을 지킬 것인가, 하나를 깊게 쓸 것인가

두 봇은 "대화를 어떻게 기억하느냐"라는 같은 문제를, 기억의 배치라는 첫 결정 하나로 갈라 푼다.

	OpenClaw	Hermes
기억 배치	에이전트별 격리 저장소	모든 입구를 단일 DB로 통합
참조 통제의 주체	운영자 — visibility 정책으로 범위를 미리 잠금	에이전트 — session_search로 전체를 스스로 검색

어느 쪽이 낫다기보다, 겨누는 환경이 다르다. 봇 하나를 깊게 쓰는 개인 서버라면, 입구를 가리지 않고 전 대화를 통째로 검색하고 봇이 스스로 맥락을 회수하는 Hermes의 통합 방식이 강하다. 반대로 여러 봇·여러 사용자를 한 서버에 안전하게 얹어야 한다면, 기억 접근 범위를 운영자가 명시적으로 통제하는 OpenClaw의 격리 방식이 강하다. 매번 0에서 시작하는 봇은 도구일 뿐이고 지난주의 맥락을 기억하는 봇이라야 "조수"에 가까워진다는 목표는 같지만 — 그 기억을 열어 검색으로 풀지, 나눠 정책으로 지킬지가 이 두 봇을 가른다.

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.

봇을 안 죽게 만드는 두 갈래 — OpenClaw는 프로세스 하나로, Hermes는 감독관을 세워

타이젠 개발자, 윤진 — Fri, 24 Jul 2026 21:00:11 +0900

개인 AI 어시스턴트 OpenClaw를 다룰 때, 그 봇은 게이트웨이 프로세스 하나가 채널·브라우저·미디어를 전부 끌어안고 도는 구조였다. "봇이 24시간 안 죽고 떠 있게 하는" 문제도 그 한 프로세스를 잘 살려 두는 문제로 좁혀졌다 — 설정이 바뀌면 재시작 없이 핫 리로드로 흡수하고, 외부 요청 실패는 타임아웃·폴백으로 삼키는 식이다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 내부를 뜯어보니, 정확히 반대편에서 같은 문제를 풀고 있었다. Hermes는 프로세스를 하나로 모으지 않는다. 오히려 게이트웨이·대시보드·예약작업(cron)을 여러 개의 오래 사는 프로세스로 쪼개 한 컨테이너에 욱여넣고, 그 위에 전담 감독관을 한 명 앉힌다. 이 글은 딱 그 한 가지 갈림길 — "생존을 앱 한 프로세스에서 풀 것인가, 아니면 OS 감독 계층에서 풀 것인가" — 만 따라간다. 나머지 차이는 전부 여기서 파생된다.

같은 목표, 갈라지는 첫 결정 — 프로세스가 하나인가 여럿인가

두 봇 다 목표는 똑같다. "사람이 안 지켜봐도 알아서 살아 있어라." 그런데 그 목표에 도달하는 첫 결정에서 갈린다. OpenClaw는 단일 게이트웨이를 중심에 두고 그 하나를 오래 살리는 데 집중한다. Hermes는 애초에 여러 프로세스가 동시에 떠 있어야 하는 구조를 전제로 깔고 시작한다.

▲ OpenClaw — 게이트웨이 한 프로세스가 전부

위 다이어그램은 앞서 다룬 OpenClaw의 뼈대를 한 칸으로 요약한 것이다. 게이트웨이 프로세스 하나가 메신저 채널, 브라우저 조작, 미디어 처리를 모두 자기 안에서 끌어안는다. 여기서 "생존"은 곧 "이 한 프로세스를 어떻게 오래, 재시작 없이 유지하느냐"로 환원된다 — 프로세스가 하나뿐이니 감독이라는 개념 자체가 필요 없고, 대신 설정을 어떻게 바꿔 끼우느냐가 핵심 난이도가 된다.

▲ Hermes — 한 컨테이너 안에 오래 사는 프로세스가 여럿

위 다이어그램은 Hermes가 전제로 까는 구조다. 컨테이너 하나 안에 메시지 수신 게이트웨이, 예약 작업 실행기, 웹 대시보드가 나란히 떠 있고, 게이트웨이는 일을 하려고 git·ssh·npm·브라우저 같은 자식 프로세스를 수시로 낳는다. OpenClaw와의 결정적 차이가 여기서 이미 드러난다 — 프로세스가 하나가 아니므로, "그중 하나가 쓰러지면 나머지를 누가 지키느냐"라는, OpenClaw에는 아예 없던 질문이 생긴다. 흔한 오해가 "컨테이너 하나면 프로세스도 하나"라는 가정인데, Hermes는 그 반대를 택했고 그 대가로 감독 문제를 떠안았다.

여럿을 택한 대가 — 단일 프로세스 모델의 세 가지 사고

Hermes가 만약 OpenClaw처럼 "게이트웨이 하나를 컨테이너의 메인으로" 띄웠다면 어떻게 될까? 컨테이너는 메인 프로세스가 죽으면 같이 종료된다(이게 컨테이너의 기본 규약이다). 여러 프로세스를 이 단순 모델에 억지로 담으면 세 가지 사고가 터진다.

위 다이어그램은 여러 프로세스를 단일 메인 모델에 담을 때 갈라지는 세 실패를 보여준다. 첫째, 메신저 연결이 잠깐 끊겨 게이트웨이가 죽으면 컨테이너가 통째로 내려가 봇이 먹통이 된다. 둘째, 에이전트가 작업하려고 띄운 자식 프로세스는 일을 마치면 좀비 프로세스(종료됐지만 부모가 회수하지 않아 프로세스 표에 남는 죽은 항목)가 되는데, 메인이 이걸 거둬들이지 않으면 시간이 갈수록 쌓인다. 셋째가 가장 고약하다 — 토큰 하나를 잘못 넣었을 뿐인데 게이트웨이가 즉시 종료되고, 재시작 정책이 다시 띄우고, 또 같은 이유로 죽는 무한 재시작 루프에 빠진다. 주목할 점은, OpenClaw는 프로세스가 하나뿐이라 둘째(자식 회수)와 크래시 전파 문제를 애초에 이런 형태로 겪지 않는다는 것이다. 이 세 사고는 "여럿을 한 컨테이너에 담기로 한" Hermes가 스스로 떠안은 숙제다.

Hermes의 답 — PID 1에 전담 감독관(s6-overlay)을 앉힌다

OpenClaw가 "게이트웨이를 어떻게 안 죽게 유지하느냐"를 애플리케이션 계층에서 풀었다면, Hermes는 같은 문제를 한 층 아래 OS 감독 계층으로 내려 푼다. 컨테이너의 1번 프로세스(PID 1) 자리에 게이트웨이가 아니라 s6-overlay라는 감독관을 앉히는 것이다. s6-overlay는 여러 프로세스를 감독(supervise)하는 경량 도구 모음으로, 리눅스에서 PID 1이 원래 져야 하는 책임 — 자식 프로세스 회수, 신호 전달, 자식 감시 — 을 대신 진다. 비유하자면 건물 관리실을 따로 두는 것과 같다. 입주자(게이트웨이·대시보드)가 하나 쓰러져도 관리실은 안 쓰러지고, 쓰러진 입주자만 다시 일으켜 세운다.

위 다이어그램은 감독관 모델의 핵심 구조를 보여준다. PID 1 자리에 s6-overlay가 앉고, 게이트웨이·대시보드·프로필별 게이트웨이가 감독 대상으로 매달린다. 점선 두 개가 중요하다 — 하나는 끝난 자식 프로세스를 PID 1이 즉시 거둬들여 좀비가 안 쌓이게 하는 흐름이고, 다른 하나는 게이트웨이가 크래시했을 때 감독관이 약 1초 뒤 같은 자리에 다시 띄우는 흐름이다. OpenClaw의 단일 프로세스 모델이 "메인이 죽으면 컨테이너가 죽는다"였다면, Hermes는 "관리실(PID 1)은 절대 안 죽고, 죽은 입주자만 골라 되살린다"로 뒤집었다. 앞서 본 좀비 누적과 크래시 전멸이 이 한 장으로 동시에 풀린다.

무한 재시작 루프를 끊는 법 — "죽지 말고 degrade 하라"

그런데 세 번째 사고(설정 오류 → 무한 재시작)는 감독관을 둔다고 저절로 풀리지 않는다. 오히려 감독관이 부지런히 재시작하니 더 빨리 폭주할 수도 있다. 여기서 Hermes의 선택이 OpenClaw의 정신과 의외로 겹친다 — 실패를 종료가 아니라 축소 운영으로 흡수하는 것이다. OpenClaw가 외부 요청 실패를 타임아웃·폴백으로 삼켰듯, Hermes는 연결할 플랫폼이 하나도 없어도 게이트웨이를 종료시키지 않고 "degraded(축소 운영)" 상태로 계속 살려 둔다. 종료(exit)가 없으면 재시작 루프도 없다.

▲ 순진한 방식 — 실패하면 종료 → 폭주

위 다이어그램은 고치기 전의 폭주 고리를 보여준다. 토큰 오류 같은 한 가지 실패가 곧장 프로세스 종료로 이어지고, 종료를 감지한 재시작 장치가 다시 띄우고, 같은 실패가 또 종료를 부르며 같은 자리를 끝없이 돈다. 이 고리의 함정은 "재시작은 회복 수단"이라는 통념이다 — 일시적 장애엔 맞지만, 원인이 그대로인 설정 오류에는 재시작이 오히려 CPU만 태우는 폭주를 만든다. 감독관을 세운 대가로, Hermes는 이 함정을 반드시 따로 막아야 했다.

▲ Hermes의 방식 — 실패해도 살아서 축소 운영

위 다이어그램은 Hermes가 택한 해법이다. 플랫폼 하나가 연결에 실패해도 게이트웨이는 종료하지 않고, 실패한 그 플랫폼만 빼고 나머지(예약 작업, 정상 연결된 다른 메신저)는 계속 돌린다. 별도 감시 흐름이 주기적으로 재연결을 시도하다가, 사용자가 토큰을 고치는 순간 그 플랫폼만 조용히 되살아난다. 두 그림을 같은 축에서 비교하면 차이가 분명하다 — 순진한 방식은 한 부분의 실패를 전체 종료로 키우고, Hermes의 방식은 실패를 한 부분의 일시 정지로 가둔다.

정리 — 난이도를 어느 층으로 옮겼나

결국 두 봇은 "알아서 살아 있어라"라는 같은 목표를, 첫 결정 하나로 전혀 다른 층에서 푼다. OpenClaw는 프로세스를 하나로 모아 생존을 설정 관리 문제로 바꿨고, Hermes는 프로세스를 여럿으로 쪼갠 대신 생존을 OS 감독 문제로 바꿨다.

	OpenClaw	Hermes
프로세스 구성	게이트웨이 하나가 전부 통합	게이트웨이·대시보드·cron 여러 프로세스 상주
"생존"이 푸는 층	앱 계층 — 설정 핫 리로드로 재시작 최소화	OS 계층 — PID 1 감독관이 죽은 프로세스만 되살림

어느 쪽이 옳다기보다, 떠안는 숙제의 종류가 다르다. Hermes의 s6 감독 트리는 여러 프로세스가 한 컨테이너에 동거하는 복잡한 환경에서 강하지만 그만큼 감독·부팅 순서·degrade 처리라는 숙제를 진다. OpenClaw의 단일 게이트웨이는 감독이라는 개념 자체가 없어 단순하지만, 대신 모든 걸 한 프로세스에 담은 만큼 설정 관리가 핵심 난이도가 된다. "알아서 살아 있는" 자율 에이전트의 전제 조건은 같지만, 그 전제를 어디에 세우느냐 — 애플리케이션이냐 운영체제냐 — 가 이 두 봇을 가르는 첫 갈림길이었다.

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.

'관리만 하던 시니어'의 종말 — 다시 실무로 내려온 그의 팀원은 에이전트다

타이젠 개발자, 윤진 — Thu, 23 Jul 2026 22:00:46 +0900

AI 전환이 깊어질수록 조직에서 관리 계층은 얇아진다. 그런데 이상하게도, 정작 시니어 개발자는 한가해지는 게 아니라 다시 키보드 앞으로 돌아온다. 단 한 가지가 달라졌다 — 이제 그의 팀원이 사람이 아니다. 이 글은 개인 AX(AI Transformation, 개인이 일하는 방식 자체를 AI 중심으로 바꾸는 전환) 관점에서, '관리만 하던 시니어'라는 자리가 왜 사라지는지, 그리고 시니어가 어떻게 "에이전트들의 매니저"로 다시 태어나는지를 풀어 본다. 여기서 에이전트(agent)란 목표만 주면 스스로 계획을 세우고 도구를 써서 일을 끝까지 처리하는 AI 일꾼을 말한다.

관리 계층이 먼저 얇아진다

가장 먼저 무너지는 자리는 직접 만들지 않고 조율과 검토만 하던 중간 관리 계층이다. 공개된 통계가 이 흐름을 분명히 보여준다. 미국 공개 기업의 관리자 수는 2022년 5월부터 2025년 5월까지 6.1% 줄었다. 같은 기간 22~25세 소프트웨어 개발자 고용은 2022년 말 정점 대비 약 20% 감소했다. 엔지니어링 리더의 54%는 앞으로 주니어를 더 적게 뽑겠다고 답했다. 여기서 직관에 반하는 지점이 하나 있다. 줄어드는 건 주니어와 관리자인데, 시니어 채용 공고는 오히려 ChatGPT 등장 이후 추세선 위로 올라갔다. 즉 AI는 '사람을 고르게 줄이는 도구'가 아니라 '계층을 재배치하는 힘'으로 작동한다. 실무를 떠받치던 주니어의 반복 작업은 AI가 흡수하고, 그들을 조율하던 관리 오버헤드도 함께 사라진다. 그 결과 가운데가 비고, 남는 것은 판단하는 시니어와 실행하는 에이전트뿐이다. 그래서 '관리만 하던 시니어'가 위태로워진다. 손은 놓고 회의와 결재로만 존재감을 증명하던 사람은, AI가 실행과 조율을 동시에 가져가는 순간 설 자리를 잃는다. 조직 입장에서는 그 계층을 유지할 이유가 줄어든다.

시니어가 다시 바닥으로 내려온다

그렇다면 능력 있는 시니어는 어디로 가는가. 위로 더 올라가 더 큰 조직을 관리하는 게 아니라, 아래로 내려와 다시 직접 만든다. 단 혼자 손으로 다 짜는 옛날 방식이 아니라, 여러 에이전트를 거느린 채 만든다.

다이어그램 설명. 이 그림은 AI 전환 이전의 전형적인 팀 모양을 보여준다. "관리만 하는 시니어"는 직접 무언가를 만들지 않고, 그 아래 여러 "주니어"가 실무를 떠받친다. "경영진"은 그 시니어를 통해 팀을 내려다본다. 이 구조에서 시니어의 가치는 코드가 아니라 조율과 검토에 있었다. 문제는 그 조율·검토야말로 AI가 가장 먼저 잘하게 된 일이라는 점이다.

다이어그램 설명. 같은 팀이 AI 전환 이후 어떻게 바뀌는지 보여준다. "다시 실무로 내려온 시니어"는 두 종류의 팀원을 둔다 — 자기 일을 대신하도록 "직접 만든 에이전트", 그리고 옆자리 동료가 만들어 공유한 "협업 파트너" 에이전트다. 사라진 주니어 층의 빈자리를 이 에이전트들이 메운다. 그리고 "경영진"은 단순 보고를 받는 대신 이 구조 전환 자체를 지원하는 역할로 바뀐다. 핵심은 시니어가 계층의 꼭대기에서 다시 작업의 한가운데로 내려왔다는 점이다.

내려온 시니어가 일하는 방식은 두 갈래로 나뉜다. 첫째, 자기 일에 필요한 에이전트를 직접 만들어 부린다. 반복되는 빌드·테스트·조사 같은 작업을 떼어 에이전트에게 맡기고, 자신은 설계와 판단에 집중한다. 둘째, 타인이 만든 에이전트를 동료처럼 옆에 두고 일한다. 옆자리 동료가 만들어 공유한 코드 리뷰 에이전트나 문서 정리 에이전트가, 사람 동료가 하던 협업의 일부를 대신한다. 이 변화에는 이미 이름이 붙었다. 업계는 이를 지휘자(conductor)에서 오케스트레이터(orchestrator)로의 전환이라고 부른다. 지휘자는 에이전트 하나를 옆에 끼고 단계를 순서대로 같이 밟는다 — 내가 매 단계에 끼어 있다. 오케스트레이터는 백엔드는 이 에이전트에게, 프런트엔드는 저 에이전트에게, 테스트는 또 다른 에이전트에게 각각 맡기고 한발 물러서서, 여러 작업이 동시에 굴러가게 만든다. "2026년이면 모든 엔지니어가 사람이 아니라 AI 에이전트의 매니저가 된다"는 표현이 업계에서 회자되는 이유다. 이렇게 일하면 specialist 에이전트를 거느린 시니어 3~4명이 혼합 경력 8~10명 팀에 필적한다는 주장도 나온다(벤더 추정). 여기서 한 줄 더 풀어 두면, 시니어가 다시 individual contributor(관리 직책 없이 직접 산출물을 내는 실무자)로 돌아온다는 뜻이다. 차이는 그 실무자가 혼자가 아니라 한 무리의 에이전트를 거느린 실무자라는 데 있다.

야심 있는 주니어는 시니어로 도약한다

주니어에게는 이 변화가 위기처럼 보인다. 사다리의 첫 칸이 사라졌기 때문이다. 그러나 일 전체를 보던, 야심 있고 능력 있는 주니어에게는 오히려 지름길이 열린다. 예전이라면 주니어는 좁은 작업 하나를 오래 반복하며 경력을 쌓아야 시니어가 보던 전체 그림에 닿았다. 지금은 그 반복 작업을 에이전트가 가져간다. 그래서 처음부터 일 전체를 설계하고, 여러 에이전트에게 작업을 쪼개 맡기고, 결과를 판단하는 자리로 곧장 뛰어들 수 있다. 폭넓게 보는 눈을 가진 사람은 더 이상 연차의 계단을 한 칸씩 밟지 않아도 된다. 그는 곧장 "에이전트들의 매니저"가 되어 시니어의 일을 한다. 다만 이 도약은 모두에게 열리지 않는다. 좁은 작업만 잘하던 주니어는 그 작업을 에이전트에게 빼앗기고, 일 전체를 보던 주니어는 에이전트를 부리는 자리로 올라선다. 그 격차가 전보다 훨씬 빨리 벌어진다.

이건 혼자 끌 수 없는 변화다

여기서 가장 중요한 함정이 있다. 개인이 도구를 바꾸는 일은 혼자서도 가능하다. 그러나 일하는 '구조'를 바꾸는 일은 혼자서 끌 수 없다. 시니어가 다시 실무로 내려오려면, 그를 평가하는 기준이 '몇 명을 관리하는가'에서 '무엇을 만들어 내는가'로 바뀌어야 한다. 팀 편성도 사람 중심에서 사람과 에이전트가 섞인 형태로 다시 짜야 한다. 사라진 주니어 자리만큼의 멘토링과 맥락 전달을, 누가 어떻게 메울지도 정해야 한다. 이 모든 것은 한 개인이 자기 자리에서 결정할 수 있는 범위를 넘어선다. 그래서 이 전환에는 경영진의 지원이 필수다. 경영진이 평가·편성·역할의 규칙을 함께 바꿔 주지 않으면, 의욕 있는 시니어 한 명이 아무리 에이전트를 잘 부려도 그 변화는 그 사람의 책상 위에서 멈춘다. 조직의 구조가 바뀌어야 비로소 "에이전트들의 매니저"라는 새 역할이 한 사람의 실험이 아니라 조직의 표준이 된다. 정리하면, AI 전환의 끝에서 사라지는 것은 시니어가 아니라 '관리만 하던 시니어'다. 능력 있는 시니어는 다시 바닥으로 내려와 에이전트를 거느린 실무자가 되고, 일 전체를 보던 주니어는 그 자리로 곧장 도약한다. 이 새 그림을 한 개인의 분투가 아니라 조직의 표준으로 만드는 마지막 한 수가, 결국 경영진의 결단이다.

참고한 공개 자료:

Stack Overflow — AI vs Gen Z: How AI has changed the career pathway for junior developers: https://stackoverflow.blog/2025/12/26/ai-vs-gen-z/
Axios — Middle managers in decline as "flattening" spreads, AI advances: https://www.axios.com/2025/07/08/ai-middle-managers-flattening-layoffs
Lepaya — The Great Flattening: Middle Management Cuts in the AI Era: https://www.lepaya.com/blog/insights-great-flattening-middle-management-ai
O'Reilly Radar — Conductors to Orchestrators: The Future of Agentic Coding: https://www.oreilly.com/radar/conductors-to-orchestrators-the-future-of-agentic-coding/
Addy Osmani — The Factory Model: How Coding Agents Changed Software Engineering: https://addyosmani.com/blog/factory-model/
SoftwareSeni — From Writing Code to Orchestrating Agents: How the Senior Engineer Role Is Changing: https://www.softwareseni.com/from-writing-code-to-orchestrating-agents-how-the-senior-engineer-role-is-changing/
The GitHub Blog — Run multiple agents at once with /fleet in Copilot CLI: https://github.blog/ai-and-ml/github-copilot/run-multiple-agents-at-once-with-fleet-in-copilot-cli/
LangChain — Agentic Engineering: How Swarms of AI Agents Are Redefining Software Engineering: https://www.langchain.com/blog/agentic-engineering-redefining-software-engineering

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.

사용자가 AI라면, 가위 손잡이부터 다시 깎는다

타이젠 개발자, 윤진 — Thu, 23 Jul 2026 21:00:43 +0900

오른손잡이 가위의 손잡이는 사람 손가락 모양을 따라 깎여 있다. 엄지와 검지가 들어갈 구멍, 손바닥에 닿는 곡선까지 전부 "사람이 쥔다"는 전제로 만들어진 것이다. 그런데 같은 가위를 로봇 팔이 쥔다면 이야기가 달라진다. 손가락 구멍은 쓸모가 없어지고, 오히려 평평한 면에 표준 그립 규격이 박혀 있는 편이 훨씬 낫다. 도구를 쥐는 손이 바뀌면, 손잡이부터 다시 깎아야 한다.

우리가 매일 쓰는 업무 시스템과 문서 도구, 관리 화면도 사정이 똑같다. 거의 전부 "사람이 본다, 사람이 클릭한다"는 전제 위에 설계됐다. 그런데 이제 그 도구를 쥐는 손이 바뀌고 있다. 24시간 쉬지 않고 일하는 AI가 사용자로 들어온다. 손잡이를 그대로 둔 채 AI에게 쥐여 주는 게 과연 맞을까.

사람용 화면을 AI에게 클릭시키면 오히려 못한다

직관적으로는 "잘 만든 화면일수록 AI도 잘 다루겠지" 싶다. 실제로는 반대 결과가 나온다. 2024년 한 연구진은 언어 모델 에이전트(스스로 판단해 도구를 부르는 AI 프로그램)를 "고유한 필요와 능력을 가진 새로운 부류의 최종 사용자"로 보자고 제안했다. 사람을 위해 다듬은 화면을 그대로 주는 대신, 에이전트를 위해 따로 설계한 도구 표면을 쥐여 줬더니 성능이 크게 뛰었다. 실제 GitHub 이슈를 풀게 하는 벤치마크에서 한 번에 맞히는 비율이 12.5%까지 올라, 그전까지의 비대화형 모델 최고 기록을 크게 앞질렀다(발표 당시 기준).

왜 그럴까. 사람용 화면은 눈으로 보고 마우스로 짚는 데 최적화돼 있다. 버튼의 위치, 색, 애니메이션은 사람의 시지각을 돕는 장치다. AI에게는 이 모든 게 잡음이다. 버튼이 화면 어디에 찍혔는지, 렌더링이 한 픽셀 밀렸는지에 동작이 휘청인다. 사람 손가락 구멍에 로봇 팔을 억지로 끼우는 셈이다. 그러니 화면을 더 예쁘게 다듬는 일이 AI 사용성을 높여 주지는 않는다.

AI에게 가장 자연스러운 인터페이스는 무엇인가

질문 하나로 좁혀 보자. 사용자가 AI일 때 가장 자연스러운 인터페이스는 무엇인가? 답은 한 청중만 보지 않는다. 24시간 일하는 AI에게는 접근과 조작이 쉬워야 하고, 그 결과를 받아 드는 사람에게는 검증이 쉬워야 한다. 두 청중을 동시에 만족시키도록 모든 구성 요소를 다시 정의해야 한다.

핵심은 발상의 전환이다. 사람용 화면(GUI, 사람이 보고 클릭하도록 만든 그래픽 인터페이스)을 AI에게 대신 클릭시키는 게 아니라, AI가 직접 다룰 수 있는 표면을 따로 설계한다. 연구자들은 이 표면을 에이전트-컴퓨터 인터페이스(agent-computer interface, AI 에이전트가 컴퓨터를 다루도록 별도로 설계한 도구와 상호작용 규칙의 묶음)라고 부른다.

다이어그램 설명. 이 그림은 같은 작업을 AI에게 맡길 때 갈리는 두 갈래를 보여준다. "AI가 직접 다룰 표면이 있는가?"라는 물음에서 시작한다. 그런 표면이 없으면 AI는 사람용 화면을 대신 클릭하는 처지가 되고, 버튼 좌표나 화면 렌더링이 조금만 바뀌어도 동작이 어긋난다. 반대로 AI가 호출할 구조화된 도구가 마련돼 있으면, 결과가 정해진 형식으로 돌아와 사람이 그대로 검증한다. 놓치기 쉬운 지점은 이것이다. 갈림을 만드는 건 "AI를 더 똑똑하게 만들었는가"가 아니라 "AI가 쥘 손잡이를 따로 깎았는가"라는 점이다.

'AI 전용 표면'은 어떻게 생겼나

추상적인 이야기 같지만 설계 원칙은 꽤 구체적이다. 앞의 코딩 에이전트가 쓴 표면을 뜯어보면 세 가지가 눈에 띈다. 첫째, 출력에 경계가 있다. 파일을 보여줄 때 한 번에 약 100줄 윈도우만 띄우고, 검색 결과도 최대 50건처럼 상한을 둔다. 사람이라면 길게 스크롤하면 그만이지만, AI에게는 긴 출력이 곧 컨텍스트(LLM이 한 번에 들고 있을 수 있는 입력 분량) 낭비이자 혼란이다. 둘째, 가드레일을 박는다. 사람이라면 linter(코드의 문법·스타일 오류를 자동으로 잡는 검사 도구)가 띄운 오류를 보고 커밋할지 스스로 판단하지만, 감독 없이 자율로 움직이는 AI에게는 그 판단이 없다. 그래서 표면이 대신 막는다. 편집한 코드가 linter를 통과하지 못하면 변경을 자동으로 되돌리고, 오류 위치를 사람이 볼 알림이 아니라 AI가 다음에 먹을 신호로 돌려준다. 셋째, 결과를 구조화한다. 줄 번호를 붙이고 형식을 고정해, AI가 다음 행동을 정할 좌표를 함께 준다.

# AI 전용 표면 — 사람 화면을 흉내 내지 않고, 도구 하나로 노출한다
def search_file(query: str, path: str) -> str:
    hits = grep(query, path)
    # 1단: 출력을 반드시 잘라 낸다 — 결과가 넘치면 AI가 길을 잃는다
    hits = hits[:50]                        # 결과 상한 50건으로 고정
    # 2단: 줄 번호를 붙여 구조화한다 — 다음 행동을 정할 좌표를 함께 준다
    return render_with_line_numbers(hits)

# 가드레일 — 편집이 문법 검사를 통과 못 하면 자동으로 되돌린다
def apply_edit(path: str, patch: str) -> str:
    backup = read(path)
    write(path, patch)
    if lint(path).failed:                   # linter가 오류를 잡으면
        write(path, backup)                 # 변경을 폐기하고 원상복구한다
        return "거부됨 — 오류 위치와 함께 다시 시도하라"
    return "적용됨"

코드 설명. 두 함수는 "AI가 다루기 쉽게, 사람이 검증하기 쉽게"라는 원칙을 코드로 옮긴 모습이다. 검색 함수는 결과를 무한정 쏟지 않고 50건에서 자른 뒤 줄 번호를 붙여 돌려준다. 편집 함수는 변경을 바로 확정하지 않고, 검사를 통과할 때만 남기고 실패하면 원래 상태로 되돌린다. 이렇게 하면 AI는 짧고 정해진 형식의 응답만 받아 다음 수를 두기 쉬워지고, 사람은 "무엇이 적용됐고 무엇이 거부됐다"를 한눈에 검증한다. 사람용 화면이라면 굳이 필요 없었을 출력 상한과 자동 되돌리기가, AI라는 사용자를 위해 손잡이를 다시 깎은 흔적이다.

표준으로 굳어 가는 방향 — MCP

표면을 도구마다 따로 깎으면, 도구가 늘어날수록 손이 많이 간다. AI 애플리케이션 10개가 외부 도구 100개와 이어지려면 최악의 경우 1,000가지 연동을 일일이 만들어야 한다. 이 조합 폭발을 하나의 규약으로 접으려는 시도가 MCP(Model Context Protocol, AI 모델과 외부 도구·데이터를 잇는 개방형 표준)다. 2024년 11월 한 AI 기업이 공개했고, 이후 다른 주요 AI 제공사들도 채택했다. 2025년 12월에는 리눅스 재단 산하 재단으로 기증돼 특정 회사 소유에서 공용 표준으로 넘어갔다.

MCP가 정의하는 표면은 세 갈래다. 도구(tools, AI가 호출해 동작을 일으키는 함수 — 타입이 정해진 인자를 받고 구조화된 결과를 돌려준다), 리소스(resources, AI가 읽기만 하는 맥락 데이터 — 파일 내용이나 데이터베이스 구조 같은 것), 프롬프트(prompts, 반복 쓰는 지시 템플릿)다. 셋 다 사람 화면을 흉내 내지 않는다. 처음부터 AI가 읽고 부르도록 설계된 표면이라는 점이 핵심이다. 가위로 치면, 손가락 구멍을 없애고 모든 로봇 팔이 같은 규격으로 쥘 수 있는 표준 그립을 못 박은 셈이다.

손잡이를 다시 깎는 일은 누구의 몫인가

개인이 AI를 부리는 입장에서 보면 이 관점은 더 또렷해진다. 집의 작은 서버 한 대에 여러 AI를 24시간 돌려 두고 일을 맡기다 보면, "사람이 쓰던 화면을 AI에게 클릭시키는" 방식이 얼마나 깨지기 쉬운지 금방 체감한다. 화면 한 군데가 바뀌면 그날 자동화가 통째로 멈춘다. 반면 AI가 부를 도구를 하나 정의해 두면, 그 도구는 화면이 어떻게 바뀌든 흔들리지 않는다.

그래서 AX(AI Experience, AI가 도구를 다루는 경험)는 UX의 곁가지가 아니라 별도의 설계 축으로 다뤄야 한다. 같은 기능에 손잡이를 두 개 깎는 일이다. 하나는 사람이 보고 검증하기 좋은 화면, 다른 하나는 AI가 직접 쥐고 다루기 좋은 도구 표면이다. 사용자가 사람에서 AI로 넓어진 지금, 가장 먼저 다시 깎아야 할 것은 똑똑한 모델이 아니라 그 모델이 쥘 손잡이다.

참고한 공개 자료:

SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering — https://arxiv.org/abs/2405.15793
Agent-Computer Interface 문서 — https://github.com/SWE-agent/SWE-agent/blob/main/docs/background/aci.md
Introducing the Model Context Protocol — https://www.anthropic.com/news/model-context-protocol
Model Context Protocol — Wikipedia — https://en.wikipedia.org/wiki/Model_Context_Protocol
Specification — Model Context Protocol — https://modelcontextprotocol.io/specification/2025-11-25

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.

AI를 깔아도 AI-native가 아닌 이유 — 회사를 'AI가 읽고 쓸 수 있는' 형태로 다시 세우기

타이젠 개발자, 윤진 — Wed, 22 Jul 2026 23:00:45 +0900

집 서버에 AI 에이전트를 잔뜩 붙여 쓰다 보면, 어느 순간 같은 질문에 부딪힌다. "도구는 다 깔았는데, 왜 우리 조직은 아직 AI로 굴러가는 느낌이 안 들까?" 계정을 나눠주고 챗봇을 붙이는 것만으로는 무언가 부족하다. 이 글은 그 부족함의 정체, 그러니까 AI 도입의 도착지가 어떤 상태인지에 대한 이야기다. 결론부터 말하면, AI-native(AI를 핵심 운영 계층으로 삼아 설계된) 회사는 세 가지 조건을 차례로 만족한다 — 검색 가능(Queryable), 닫힌 루프(Closed-loop), 자기개선(Self-improving). 그리고 이 셋은 따로 노는 항목이 아니라 한 줄로 이어지는 사다리다.

출발점 — 회사는 원래 '사람만 읽도록' 만들어져 있다

지금 거의 모든 조직의 정보와 프로세스는 사람을 전제로 설계돼 있다. 중요한 결정은 회의실의 말로 오가고, 맥락은 개인 메신저와 이메일 속에 흩어지고, "왜 이렇게 했는지"는 누군가의 머릿속에만 남는다. 사람끼리는 이걸로 충분했다. 빈칸은 옆자리에 물어보면 채워졌기 때문이다.

문제는 AI에게는 그 '옆자리에 물어보기'가 통하지 않는다는 점이다. AI 에이전트(주어진 목표를 위해 스스로 도구를 호출하며 일하는 AI)는 기록되지 않은 회의, 누군가의 DM 안에 잠긴 결정, 머릿속에만 있는 이유를 읽을 방법이 없다. 그래서 AI-native로 가는 첫걸음은 거창한 모델 도입이 아니라, 사람만 읽도록 만들어진 회사 정보를 AI도 읽고 쓸 수 있는 형태로 다시 세우는 일이다. 이걸 흔히 machine-readable(기계가 파싱할 수 있는 구조화된 형태) 조직이라고 부른다.

1단계 — Queryable: 작은 결정까지 검색 가능한 기록으로

첫 번째 조건은 회사가 queryable(질의 가능 — AI가 검색해서 참조할 수 있는 상태)해야 한다는 것이다. YC가 공개한 'AI-native 회사 만들기' 플레이북에서 Diana Hu(YC 파트너)는 이걸 한 문장으로 요약한다 — 회사의 모든 중요한 행동이 AI가 학습할 수 있는 디지털 산출물(artifact)을 남겨야 한다.

핵심은 '자료'만이 아니라 회의와 작은 결정까지 포함된다는 점이다. 그가 제안하는 구체적 행동은 이렇다 — 회의는 AI 노트테이커로 자동 기록하고, 개인 메신저와 이메일 사용을 줄여 흩어진 대화를 구조화된 데이터로 모으고, 커뮤니케이션 채널마다 AI 에이전트를 심고, 매출·영업·엔지니어링·채용을 한 화면에서 보는 통합 대시보드를 둔다. 목적은 단 하나다 — 나중에 AI가 "그때 왜 그렇게 정했지?"를 물었을 때 답이 어딘가에 검색 가능한 형태로 남아 있게 만드는 것이다.

여기서 중요한 단어가 한 번 더 나온다. 기록은 사람이 읽을 PDF나 캡처가 아니라, 기계가 그대로 파싱할 수 있는 형태여야 한다. 예를 들어 문서를 AI 에이전트가 읽기 좋게 만들라는 가이드(Vercel 공개 문서)는, 에이전트가 페이지를 가져갈 때 스크립트가 뒤엉킨 HTML이 아니라 깨끗한 마크다운을 받게 하라고 권한다. 같은 회의록이라도 음성 그대로 묻혀 있으면 AI에게는 없는 것과 같고, 텍스트로 전사돼 검색되면 비로소 자산이 된다.

2단계 — Closed-loop: 지난 결과가 다음 시도의 입력이 된다

기록이 검색 가능해졌다고 끝이 아니다. 두 번째 조건은 그 정보가 closed-loop(닫힌 루프)를 돌아야 한다는 것이다. 닫힌 루프란 산출물을 지속적으로 관찰해 다시 AI에 되먹이고, 그걸로 다음 프로세스를 다듬는 구조를 말한다. 반대 개념인 open-loop(열린 루프)는 결과가 한 번 나오면 사람이 일일이 해석해서 끝나 버리는, 정보가 새어 나가는(lossy) 방식이다.

쉽게 비유하면, 자동온도조절기와 비슷한 발상이다. 온도를 한 번 맞춰 놓고 끝내는 게 아니라, 실제 온도를 계속 재서 다시 난방에 반영하는 그 되먹임 고리 말이다. 조직에서는 이렇게 작동한다 — 어떤 시도를 했고 그 결과가 어땠는지가 queryable한 기록으로 남고, 그 결과가 다음 시도를 시작할 때 그대로 AI의 입력으로 들어간다. 지난 분기의 영업 실패 사유, 어제 배포에서 터진 장애, 한 달 전 거절당한 기획의 이유가 흩어져 사라지지 않고 다음 판단의 재료가 되는 것이다.

이 루프가 성립하려면 1단계가 반드시 먼저 깔려 있어야 한다. 결과가 검색 가능한 형태로 남아 있지 않으면 되먹일 것 자체가 없기 때문이다. 그래서 Queryable은 Closed-loop의 전제 조건이지, 별개의 선택지가 아니다.

3단계 — Self-improving: 루프를 돌수록 더 나은 시도

마지막 조건은 그 닫힌 루프를 통해 이전보다 더 나은 시도를 지속적으로 반복하는 것이다. self-improving(자기개선)이란 거창한 자율 AI가 아니라, 같은 실수를 두 번 하지 않고 매 반복마다 조금씩 나아지는 상태를 가리킨다. 루프가 한 바퀴 돌 때마다 직전 결과가 다음 입력의 품질을 끌어올리니, 시도가 쌓일수록 출발선이 높아진다.

다이어그램 설명. 이 그림이 보여주는 핵심은, 세 조건이 병렬 항목이 아니라 한 줄로 이어지는 사다리라는 점이다. "사람만 읽도록 만든 회사 정보와 결정"에서 출발해, 그것을 "기계가 읽을 수 있는 형태로 기록"하는 순간 "AI가 검색하고 참조할 수 있는" 상태(Queryable)가 된다. 여기까지 와야 비로소 "지난 시도의 결과가 다음 시도의 입력이 되는" 닫힌 루프(Closed-loop)가 가능하고, 그 루프를 통해 "이전보다 나은 시도를 지속 반복하는" 자기개선(Self-improving)으로 올라선다. 마지막에서 "지난 시도의 결과가 다음 시도의 입력이 되는" 단계로 화살표가 되돌아가는데, 이 되돌이가 바로 닫힌 루프가 매번 더 높은 출발선에서 다시 도는 모습이다. 놓치기 쉬운 함정은 순서를 건너뛰려는 시도다 — 기록을 기계가 읽을 형태로 만들지 않은 채 자기개선부터 기대하면, 되먹일 재료가 없어 루프 자체가 돌지 않는다.

그래서 무엇이 달라지는가 — human middleware의 소멸

이 사다리를 끝까지 오르면 조직의 모양 자체가 바뀐다. Diana Hu는 회사가 queryable하고 산출물이 풍부하며 AI가 읽을 수 있게 되면 human middleware(사람 중간 계층 — 정보를 위아래로 실어 나르던 중간 관리·조율 역할)가 거의 필요 없어진다고 말한다. 예전에는 정보를 조직 위아래로 비효율적으로 라우팅하기 위해 중간 관리자와 조율자가 필요했지만, 이제는 그 지능 계층(intelligence layer)이 그 일을 대신한다는 것이다. 그는 "사람을 늘리지 말고 토큰을 태우라(burn tokens, not headcount)"는 다소 도발적인 표현까지 쓴다. 다만 한 사람이 1000명 몫을 한다는 식의 수치는 그의 주장이자 비전에 가까우니, 숫자 자체보다 방향으로 읽는 편이 맞다.

왜 이게 개인에게도 중요한가? 나처럼 혼자 집 서버에서 여러 에이전트를 굴리는 사람에게도 똑같은 사다리가 적용되기 때문이다. 작업 로그를 검색 가능한 기록으로 남기지 않으면(Queryable 실패) 어제 실패한 시도를 오늘 또 반복하고, 그 결과를 다음 작업의 입력으로 연결하지 않으면(Closed-loop 실패) 에이전트는 매번 백지에서 다시 시작한다. AI 전환(AX)을 "좋은 모델을 고르는 일"로만 보면 이 사다리를 통째로 놓친다.

도착지는 모델이 아니라 구조다

정리하면 이렇다. AI-native 회사는 더 똑똑한 모델을 산 회사가 아니라, 기록→검색 가능→루프→자기개선의 사다리를 실제로 세운 회사다. 출발점은 화려한 모델 도입이 아니라, 사람만 읽도록 만들어진 회사의 정보와 프로세스를 AI도 읽고 쓰는 형태로 다시 정립하는 그 지루한 첫걸음에 있다. 도구는 언제든 바꿔 끼울 수 있지만, 이 구조를 갖추지 못한 조직은 아무리 좋은 AI를 깔아도 결국 사람이 일일이 정보를 실어 나르는 옛 방식으로 되돌아간다. 도착지는 모델이 아니라 구조라는 점, 그게 이 글의 한 줄 결론이다.

참고한 공개 자료:

Y Combinator, "The Playbook For Building An AI Native Company" — https://www.ycombinator.com/library/OX-the-playbook-for-building-an-ai-native-company
StartupHub.ai, "Build AI-Native Companies with Closed-Loop Systems" — https://www.startuphub.ai/ai-news/artificial-intelligence/2026/build-ai-native-companies-with-closed-loop-systems
IBM, "What Is AI Native?" — https://www.ibm.com/think/topics/ai-native
Vercel Knowledge Base, "Make your documentation readable by AI agents" — https://vercel.com/kb/guide/make-your-documentation-readable-by-ai-agents

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.