Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
이 글은 에이전트 기반 개발의 진화 과정을 다룹니다. 단순한 모델 지능을 넘어, 업무 기억과 개발 습관, 도구 사용법 등을 연결하는 '오케스트레이션'이 핵심입니다. 저자는 Hermes Agent를 활용하여 개인화된 복구 로직과 운영 규칙을 갖춘 에이전트를 구축하며, 이 과정에서 직접 코드를 수정하고 개선한 경험을 공유합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 X AI 사용법/팁의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기통찰력이 엄청나다.
[국문 버전]
본문 @simonkim_nft
< 우리는 같은 미래를 업데이트받지 않을 것이다 >
나는 텔레그램 창을 열어 에이전트에게 개발을 시킨다. 어차피 코드는 보지 않게 된지 오래됐고, 사무실이나 집 밖 어디서나 가장 간편하고 반응속도 높게 개발할때 아직 이보다 효율적인 셋업은 찾지 못했다.
내가 무엇을 만들려는지, 지금 결과에서 무엇이 마음에 걸리는지, 어디까지 확인돼야 끝난 것인지를 입력하는 루프만 반복하면 된다. 공공장소가 아니면 손가락 타이핑도 거의 하지 않는다. 마이크 버튼을 누르고 생각을 목소리 그대로 쏟아낼 뿐이다. “아니… 방금 그건 취소하고 이쪽으로.” 혼잣말처럼 번복한 흔적까지. 말로 입력하는 쪽이 타이핑보다 3배 이상 빠르기도 하지만, 말끔하게 정돈된 문장보다 정리되기 전의 의식을 들려줄 때 에이전트가 내 생각의 흐름을 더 잘 따라오는 장점도 있다.
나는 Hermes Agent와 함께 개발한다. 반복되는 일이 자동으로 스킬로 형성되는 구조 덕분에, 지난달에는 여러 문장으로 설명해야 했던 일을 오늘은 한 문장으로 시킬 수 있다. 이 구조적 장점 덕분에 OpenClaw를 누르고 에이전트 사용량 1위에 올랐을 것이다.
작년 말까지 Claude Code나 Codex를 터미널에 바로 띄워 개발하던 때와 지금의 에이전틱 개발이 가장 크게 달라진 지점은 모델의 지능이 아니다. 모델 위에 내 업무 기억과 개발 습관, 도구와 그 사용법, 완료 기준, 실패했을 때의 복구법이 미리 연결돼 있다는 점이다. 한 번의 실행 안에서 어떤 모델과 도구를 부를지, 어떤 전문 에이전트에게 일을 넘길지, 어떤 맥락을 함께 건넬지, 어디서 멈춰 내게 확인받을지를 조정한다. 업계에서 오케스트레이션이라 부르는 실행 제어다.
모델이 두뇌라면 이 층은 오늘 어떤 기억을 안고 깨어날지, 무엇을 경계하고 어디서 멈출지를 정한다. 더 좋은 모델은 나올 때마다 갈아 끼울 수 있다. 반면 함께 일하며 생긴 방식은 그렇게 쉽게 교체되지 않는다. 개인화의 무게중심은 모델이 아니라 모델 바깥에 쌓인다.
그래서 내가 에이전트에게 가장 자주 하는 말은 새 기능을 만들어 달라는 말이 아니다.
“방금 실수한 부분을 다음에는 실수하지 않게 구조적으로 고쳐.”
그러면 에이전트는 틀린 답 하나만 고치지 않는다. 기억이 부족했는지, 규칙이 모호했는지, 완료 조건이 허술했는지 되짚는다. 메모리와 스킬을 손보고 회귀 테스트를 붙인다. 어느 순간부터 내 에이전트는 자신의 운영 규칙과 복구 로직을, 때로는 Hermes의 핵심 코드까지 직접 뜯어고치기 시작했다.
올해 봄 OpenClaw를 쓰다 Hermes로 건너왔을 때, 제온과 시온, 미온, 사노, 라온으로 부르는 내 다섯 에이전트를 각자의 텔레그램 봇에 연결할 방법이 없었다. 그래서 하나의 게이트웨이가 여러 프로필을 나눠 맡도록, 봇마다 서로 다른 성격과 메모리와 세션을 불러오도록 코드를 직접 고쳤다. 잘못된 계정이 들어오면 다른 봇으로 넘기지 않고 응답 자체를 막았다. 기억이 한 번 섞이면 개인화의 전제가 무너지기 때문이다. Hermes의 공식 구현은 6월 18일에 공개되어 다음 날 릴리스에 포함됐다. 지금은 공식판에서도 옵션을 켜면 한 게이트웨이가 여러 프로필의 봇을 함께 관리한다. 결국 같은 방향으로 만났지만, 그사이 내게 필요했던 기능은 내 코드가 메웠다.
여러 프론티어 모델을 동시에 부르는 도구도 바꿨다. 한 모델이 늦었다고 전체가 멎지 않도록 호출마다 제한시간을 두고, 먼저 도착한 답은 버리지 않고 남겼다. 일이 남았는데 끝났다고 착각하는 문제에는 미완료 항목이 있으면 완료를 선언하지 못하는 장치를 붙였다. 긴 작업이 중간에 끊길 때는 판단 이유와 중간 결과를 반드시 남기게 했다. 같은 실패를 겪을 때마다 기억만 늘어난 게 아니라, 다음 실패를 다루는 코드가 달라졌다.
이런 수정을 수없이 거듭한 지금, 내가 쓰는 Hermes는 순정 Hermes와 상당히 멀어졌다. 같은 씨앗에서 출발했지만 내 잔소리와 시행착오를 먹고 자란 다른 계통이다. 직접 만든 에이전트 메모리 시스템 MemKraft도 무엇을 결정했는지만 저장하지 않는다. 왜 그렇게 판단했는지, 결과는 어땠는지, 그 정보를 언제까지 믿어도 되는지를 함께 남긴다. 내가 리뷰하는 것도 코드 자체보다 변경의 이유에 가깝다.
이러한 흐름 속에서 소프트웨어 개인화라는 단어의 정의는 크게 달라질 것이다. 지금까지의 개인화는 완성된 소프트웨어 안에서 아이콘 배치나 배경색, 단축키 따위를 고르는 일이었다. 에이전트와 함께 지내면 경험이 기억으로만 남지 않는다. 그 기억이 규칙을 바꾸고, 검증할 테스트와 새 도구를 만들고, 복구 로직과 코드베이스 자체를 갈아엎는다. 설정에는 취향이 남지만 코드에는 한 사람이 실패하고 회복한 방식이 남는다.
그래서 오케스트레이션이라는 말만으로는 부족하다.