요즘 AI 도구를 쓰다 보면, 예전에는 분명했던 역할 구분이 조금씩 달라지고 있다는 것을 느낍니다. 채팅으로 묻고 답하던 단계에서, 이제는 파일을 읽고 실행하고 반복 작업을 맡기는 단계로 넘어가고 있습니다.
최근 한 사용자가 이런 말을 했습니다.
“연초에는 코워크와 코드 사용이 1:1 수준이었는데, 이제는 거의 코드만 쓰고 코워크가 하던 일은 Hermes Agent로 전부 이관해 자동화했다. 현재 시점에서 코워크는 포지션이 애매하고, 모델들이 버전업되면서 사용량을 많이 소모하게 되어 더 안 쓰게 된다.”
이 발언을 한 개인의 도구 사용 변화로만 치부하면, 그 안에 담긴 더 큰 흐름을 놓치게 됩니다. AI 작업 환경의 중심이 어디로 이동하고 있는가입니다.
이 말은 코워크가 이제 쓸모가 없어졌다는 뜻이 아닙니다. 또 다시 작업의 방식이 바뀌고 있다고 봅니다.
Contents
대화창에서 폴더 작업으로 이동했습니다
처음에는 대화창이 중심이었습니다. 질문을 던지고, 답을 받고, 필요한 부분을 다시 요청했습니다. 파일은 첨부했고, 결과는 대화창에서 받았습니다. 이 방식에서는 AI가 답변자는 될 수 있어도, 작업 환경 안으로 들어오지는 못했습니다.
그다음 단계에서 코워크 같은 환경이 등장했습니다. 옵시디언 폴더를 연결하고, 자료를 읽고, 문서를 만들고, 노트를 정리하는 흐름이 가능해졌습니다. 사용자는 더 이상 매번 파일을 올리지 않아도 되었습니다. AI가 연결된 폴더 안에서 직접 읽고 쓰는 구조가 만들어졌습니다.
이 변화만으로도 작업 방식은 크게 달라졌습니다. 코워크는 비개발자에게 특히 의미가 있었습니다. 터미널을 몰라도 되고, 복잡한 설정을 하지 않아도 됩니다. “이 폴더를 읽고 정리해줘”라는 요청만으로 파일 기반 작업을 맡길 수 있었습니다.
이제는 폴더 작업에서 운영 환경으로 넘어갑니다
그런데 지금은 다시 한 번 이동이 일어나고 있습니다. 대화창에서 폴더 작업으로 이동했던 흐름이, 이제는 상시형 에이전트와 자동화 환경으로 넘어가고 있습니다.
AI 에이전트는 파일을 읽는 데서 끝나지 않습니다. 명령을 실행하고, 결과를 확인하고, 오류가 있으면 다시 수정합니다. 단순한 답변보다 실행과 검증에 가까운 환경입니다. 이 지점에서 코워크와 AI 에이전트의 차이가 생깁니다.
Hermes Agent 같은 환경은 여기에 한 층을 더 얹습니다. 파일 읽기와 쓰기, 터미널 실행, 웹 조사, 스킬 호출, 메모리 유지, 예약 작업을 하나의 흐름으로 묶습니다. 코워크가 “지금 연결한 폴더에서 일하는 손”이라면, Hermes Agent는 “반복되는 작업 방식을 기억하고 다시 실행하는 운영자”에 가깝습니다.
코워크의 포지션이 애매해지는 지점
코워크는 여전히 좋은 진입점입니다. 비개발자가 로컬 폴더를 AI에게 맡기고, 문서를 정리하고, 옵시디언 볼트 안에서 파일을 만들기에는 편한 경로입니다. AI를 파일 작업에 연결하는 첫 단계로는 의미가 있습니다.
하지만 작업이 반복되기 시작하면 기준이 달라집니다. 매번 같은 방식으로 리서치를 하고, 같은 기준으로 글을 쓰고, 같은 구조로 위키 노트를 만들고, 같은 형식으로 검증해야 한다면 코워크의 장점만으로는 부족해집니다. 그때 필요한 것은 대화창이나 폴더 연결이 아니라 절차입니다.
절차가 반복되면 스킬이 됩니다. 스킬이 쌓이면 작업 환경이 됩니다. 작업 환경이 누적되면 자동화의 대상이 됩니다. 이 흐름 안에서 코워크가 담당하던 일부 역할은 Hermes Agent로 전반적으로 에이전트 쪽으로 이동중입니다.
Hermes Agent는 반복 절차를 운영 단위로 바꿉니다
Hermes Agent의 의미는 여기서 분명해집니다. Hermes Agent는 또 하나의 AI 채팅 도구가 아닙니다. 반복되는 작업 절차를 기억하고, 필요한 도구를 호출하고, 결과를 파일과 지식 구조 안에 남기는 환경입니다.
코워크에서는 사용자가 매번 작업을 열어야 합니다. Hermes Agent에서는 반복 절차를 스킬과 메모리, 예약 작업으로 넘길 수 있습니다. 코워크에서는 세션마다 다시 설명해야 하는 부분이 생깁니다. Hermes Agent에서는 사용자의 작업 환경, 선호, 볼트 구조, 위키 운영 원칙이 누적됩니다.
예를 들어 글쓰기 작업을 할 때도 마찬가지입니다. 단순히 “글 써줘”라고 요청하는 것이 아니라, 먼저 LLM 위키에서 관련 W_ 노트를 찾고, 부족한 부분만 리서치하고, 근거를 남긴 뒤, 글쓰기 스킬과 보이스 레퍼런스를 적용합니다. 마지막에는 AI 흔적 제거 기준으로 문장을 점검합니다. 이것은 한 번의 프롬프트가 아니라 하나의 작업 체계입니다.
옵시디언과 LLM 위키는 작업의 기억이 됩니다
이 변화에서 옵시디언과 LLM 위키의 역할이 커집니다. 옵시디언은 단순한 노트 앱이 아닙니다. 에이전트가 읽고 쓸 수 있는 작업 공간입니다. LLM 위키는 단순한 자료 창고가 아닙니다. AI가 매번 처음부터 검색하지 않도록 정제된 외부 기억을 제공합니다.
안드레이 카파시가 말한 LLM 위키 패턴도 이 지점을 짚습니다. 기존 RAG는 질문할 때마다 원문 조각을 다시 찾습니다. 매번 검색하고, 매번 조합하고, 매번 다시 시작합니다. 반면 LLM 위키는 원천 자료를 한 번 정리해 위키 페이지로 만들고, 이후에는 그 위키를 갱신하며 씁니다.
이 구조에서는 AI가 매번 새로 출발하지 않습니다. 작업 환경 자체가 조금씩 정리됩니다. 중요한 자료는 위키에 남고, 반복 절차는 스킬로 남고, 실행 기록은 로그로 남습니다. 시간이 지날수록 도구를 잘 쓰는 것이 아니라, 작업 환경이 정리되는 쪽으로 이동합니다.
모델 사용량 문제도 작업 구조를 다시 보게 만듭니다
최근 모델들은 한 번의 작업에서 더 많은 맥락을 읽고, 더 많은 도구를 쓰고, 더 긴 추론을 합니다. 그만큼 사용량 소모도 커집니다. 이때 매번 대화창에서 처음부터 설명하는 방식은 비용 구조가 맞지 않습니다.
같은 자료를 반복해서 붙여 넣고, 같은 지시를 반복 입력하고, 같은 검증 기준을 다시 설명하는 방식은 오래가기 어렵습니다. 모델이 좋아질수록 오히려 작업 구조가 더 중요해집니다. 무엇을 매번 넣을지보다, 무엇을 위키에 남기고 무엇을 스킬로 고정할지 판단해야 합니다.
이때 필요한 것은 더 긴 프롬프트가 아닙니다. 작업 구조입니다. 내 지식은 옵시디언과 LLM 위키에 쌓고, 반복 절차는 스킬로 남기고, 실행과 검증은 에이전트에게 맡기는 구조입니다.
코워크가 사라졌다는 뜻은 아닙니다. 다만 AI 작업의 중심이 코워크 안에만 머물러 있지 않게 되었다는 뜻입니다. 코워크가 맡아왔던 “폴더 기반 작업”의 일부는 더 넓은 에이전트 환경으로 옮겨가고 있습니다. 간단한 폴더 작업이나 처음 AI 파일 작업을 익히는 단계에서는 여전히 유효하지만, 반복·검증·자동화가 필요한 작업은 Hermes Agent나 코드 에이전트 쪽으로 자연스럽게 이동합니다.
