Forwarded from Watcher Guru
JUST IN: $40 million worth of Bitcoin stolen after 500 'Coldcard' hardware wallets were hacked.
@WatcherGuru
@WatcherGuru
❤2
Forwarded from Simon's Rabbit Crypt - KR
우리는 같은 미래를 업데이트받지 않을 것이다
나는 텔레그램 창을 열어 에이전트에게 개발을 시킨다. 어차피 코드는 보지 않게 된지 오래됐고, 사무실이나 집 밖 어디서나 가장 간편하고 반응속도 높게 개발할때 아직 이보다 효율적인 셋업은 찾지 못했다.
내가 무엇을 만들려는지, 지금 결과에서 무엇이 마음에 걸리는지, 어디까지 확인돼야 끝난 것인지를 입력하는 루프만 반복하면 된다. 공공장소가 아니면 손가락 타이핑도 거의 하지 않는다. 마이크 버튼을 누르고 생각을 목소리 그대로 쏟아낼 뿐이다. “아니… 방금 그건 취소하고 이쪽으로.” 혼잣말처럼 번복한 흔적까지. 말로 입력하는 쪽이 타이핑보다 3배 이상 빠르기도 하지만, 말끔하게 정돈된 문장보다 정리되기 전의 의식을 들려줄 때 에이전트가 내 생각의 흐름을 더 잘 따라오는 장점도 있다.
나는 Hermes Agent와 함께 개발한다. 반복되는 일이 자동으로 스킬로 형성되는 구조 덕분에, 지난달에는 여러 문장으로 설명해야 했던 일을 오늘은 한 문장으로 시킬 수 있다. 이 구조적 장점 덕분에 OpenClaw를 누르고 에이전트 사용량 1위에 올랐을 것이다.
작년 말까지 Claude Code나 Codex를 터미널에 바로 띄워 개발하던 때와 지금의 에이전틱 개발이 가장 크게 달라진 지점은 모델의 지능이 아니다. 모델 위에 내 업무 기억과 개발 습관, 도구와 그 사용법, 완료 기준, 실패했을 때의 복구법이 미리 연결돼 있다는 점이다. 한 번의 실행 안에서 어떤 모델과 도구를 부를지, 어떤 전문 에이전트에게 일을 넘길지, 어떤 맥락을 함께 건넬지, 어디서 멈춰 내게 확인받을지를 조정한다. 업계에서 오케스트레이션이라 부르는 실행 제어다.
모델이 두뇌라면 이 층은 오늘 어떤 기억을 안고 깨어날지, 무엇을 경계하고 어디서 멈출지를 정한다. 더 좋은 모델은 나올 때마다 갈아 끼울 수 있다. 반면 함께 일하며 생긴 방식은 그렇게 쉽게 교체되지 않는다. 개인화의 무게중심은 모델이 아니라 모델 바깥에 쌓인다.
그래서 내가 에이전트에게 가장 자주 하는 말은 새 기능을 만들어 달라는 말이 아니다.
“방금 실수한 부분을 다음에는 실수하지 않게 구조적으로 고쳐.”
그러면 에이전트는 틀린 답 하나만 고치지 않는다. 기억이 부족했는지, 규칙이 모호했는지, 완료 조건이 허술했는지 되짚는다. 메모리와 스킬을 손보고 회귀 테스트를 붙인다. 어느 순간부터 내 에이전트는 자신의 운영 규칙과 복구 로직을, 때로는 Hermes의 핵심 코드까지 직접 뜯어고치기 시작했다.
올해 봄 OpenClaw를 쓰다 Hermes로 건너왔을 때, 제온과 시온, 미온, 사노, 라온으로 부르는 내 다섯 에이전트를 각자의 텔레그램 봇에 연결할 방법이 없었다. 그래서 하나의 게이트웨이가 여러 프로필을 나눠 맡도록, 봇마다 서로 다른 성격과 메모리와 세션을 불러오도록 코드를 직접 고쳤다. 잘못된 계정이 들어오면 다른 봇으로 넘기지 않고 응답 자체를 막았다. 기억이 한 번 섞이면 개인화의 전제가 무너지기 때문이다. Hermes의 공식 구현은 6월 18일에 공개되어 다음 날 릴리스에 포함됐다. 지금은 공식판에서도 옵션을 켜면 한 게이트웨이가 여러 프로필의 봇을 함께 관리한다. 결국 같은 방향으로 만났지만, 그사이 내게 필요했던 기능은 내 코드가 메웠다.
여러 프론티어 모델을 동시에 부르는 도구도 바꿨다. 한 모델이 늦었다고 전체가 멎지 않도록 호출마다 제한시간을 두고, 먼저 도착한 답은 버리지 않고 남겼다. 일이 남았는데 끝났다고 착각하는 문제에는 미완료 항목이 있으면 완료를 선언하지 못하는 장치를 붙였다. 긴 작업이 중간에 끊길 때는 판단 이유와 중간 결과를 반드시 남기게 했다. 같은 실패를 겪을 때마다 기억만 늘어난 게 아니라, 다음 실패를 다루는 코드가 달라졌다.
이런 수정을 수없이 거듭한 지금, 내가 쓰는 Hermes는 순정 Hermes와 상당히 멀어졌다. 같은 씨앗에서 출발했지만 내 잔소리와 시행착오를 먹고 자란 다른 계통이다. 직접 만든 에이전트 메모리 시스템 MemKraft도 무엇을 결정했는지만 저장하지 않는다. 왜 그렇게 판단했는지, 결과는 어땠는지, 그 정보를 언제까지 믿어도 되는지를 함께 남긴다. 내가 리뷰하는 것도 코드 자체보다 변경의 이유에 가깝다.
이러한 흐름 속에서 소프트웨어 개인화라는 단어의 정의는 크게 달라질 것이다. 지금까지의 개인화는 완성된 소프트웨어 안에서 아이콘 배치나 배경색, 단축키 따위를 고르는 일이었다. 에이전트와 함께 지내면 경험이 기억으로만 남지 않는다. 그 기억이 규칙을 바꾸고, 검증할 테스트와 새 도구를 만들고, 복구 로직과 코드베이스 자체를 갈아엎는다. 설정에는 취향이 남지만 코드에는 한 사람이 실패하고 회복한 방식이 남는다.
그래서 오케스트레이션이라는 말만으로는 부족하다. 오케스트레이션은 주어진 실행 안에서 순서와 분기를 조정하는 일이고, 내가 보고 있는 건 그 실행을 감싸는 기억과 규칙과 코드가 경험을 거치며 다음 버전으로 넘어가는 단계다.
나는 이 갈라짐을 개인별 에이전트 계보(Agent Lineage)라고 부르고 싶다. 같은 기반에서 출발한 에이전트가 한 사람의 선택과 실패를 검증되고 되돌릴 수 있는 형태로 번역해 자기만의 계보로 갈라지는 것이다.
그러면 모두가 같은 형태의 에이전트를 쓴다는 전제도 어긋난다. 업데이트는 완성된 새 버전을 통째로 덮어쓰는 일이 아니라, 플랫폼이 고친 공통 기능과 내가 키운 변경을 서로 합치는 일이 된다. 같은 Hermes 2.0을 받아도 누구의 에이전트는 결제 전에 세 번 확인하고, 누구의 것은 일을 더 잘게 나누며, 누구의 것은 모호한 부탁을 받으면 먼저 되묻는다. 화면만 다른 게 아니라 작동 원리의 일부가 다르다.
에이전트 플랫폼의 역할도 전혀 달라진다. 완성품을 배포하는 대신 계보를 키우는 곳이 된다. 공통 기반의 보안 업데이트는 받아들이되 나를 닮아 바뀐 규칙은 지켜야 하고, 개인의 코드와 공식판이 충돌하면 병합해야 하며, 잘못 배운 변화만 골라 되돌리면서 기억은 남겨야 한다. 경쟁력은 기능의 개수보다 수백만 갈래로 갈라진 계보의 상속과 병합, 검증과 롤백을 안전하게 관리하는 능력에서 나올 것이다.
개발에서 먼저 겪은 이 구조는 일상 생활로 번질 것이다. 일정과 관계, 이동과 구매, 건강과 일은 지금 서로 다른 앱에 흩어져 있다. 개인 에이전트는 그 사이를 따라다니며 한 사람의 맥락을 이어 붙인다. 지난 여행에서 싫어했던 동선과 긴 회의 다음 날에는 약속을 잡지 않는 습관이 같은 기억 안에서 만난다. 기억이 쌓이면 행동이 달라지고, 행동이 반복되면 그 사람에게만 맞는 규칙과 코드가 생긴다.
같은 에이전트를 받은 두 사람도 몇 달 뒤면 같은 요청에 전혀 다른 답을 내놓을 것이다. “이번 주말에 내가 좋아할 만한 숙소를 골라줘.” 한 사람의 에이전트는 전망도 없는 구도심의 작은 호텔을 잡는다. 그가 여행에서 오래 기억한 것이 새벽 골목의 빵집과 낡은 서점이었기 때문이다. 다른 사람의 에이전트는 식당 하나 없는 외딴 바닷가 숙소를 고른다. 지난 여행에서 계획을 전부 취소하고 파도 소리만 듣던 오후를 가장 좋아했다고 기억하기 때문이다. 같은 문장 뒤에 서로 다른 생의 기록이 붙자 정답도 갈라진다.
역설적으로 소프트웨어가 사람마다 갈라질수록 공통 기반은 더 중요해진다. 여러 서비스를 오가며 실제로 행동하려면 신원과 권한, 결제와 기록, 감사와 되돌리기의 문법은 같아야 한다. 개인의 코드는 달라져도 서로 만나는 접합부는 단단해야 한다. 지금의 SaaS도 사라지기보다는 화면 뒤로 물러나, 에이전트가 기대는 공식 기록과 책임의 기반이 될 가능성이 크다.
그때 가장 중요한 질문은 어느 모델을 쓰느냐가 아닐 것이다. 나와 함께 변한 규칙과 코드, 실패를 통과하며 만들어진 계보는 누구의 것인가. 플랫폼을 옮길 때 그 전부를 데려갈 수 있는가. 좋은 플랫폼은 가장 똑똑한 에이전트 하나를 파는 곳이 아니라, 사람마다 다르게 자란 계보가 끝까지 그 사람에게 속하도록 만드는 곳일 것이다.
마이크 버튼을 누른다. “아니, 그건 취소하고.” 무심코 덧붙인 망설임 하나가 기억이 되고, 규칙이 되고, 에이전트의 뼈대가 되는 코드 한 줄을 바꿔 놓고 있다.
나는 텔레그램 창을 열어 에이전트에게 개발을 시킨다. 어차피 코드는 보지 않게 된지 오래됐고, 사무실이나 집 밖 어디서나 가장 간편하고 반응속도 높게 개발할때 아직 이보다 효율적인 셋업은 찾지 못했다.
내가 무엇을 만들려는지, 지금 결과에서 무엇이 마음에 걸리는지, 어디까지 확인돼야 끝난 것인지를 입력하는 루프만 반복하면 된다. 공공장소가 아니면 손가락 타이핑도 거의 하지 않는다. 마이크 버튼을 누르고 생각을 목소리 그대로 쏟아낼 뿐이다. “아니… 방금 그건 취소하고 이쪽으로.” 혼잣말처럼 번복한 흔적까지. 말로 입력하는 쪽이 타이핑보다 3배 이상 빠르기도 하지만, 말끔하게 정돈된 문장보다 정리되기 전의 의식을 들려줄 때 에이전트가 내 생각의 흐름을 더 잘 따라오는 장점도 있다.
나는 Hermes Agent와 함께 개발한다. 반복되는 일이 자동으로 스킬로 형성되는 구조 덕분에, 지난달에는 여러 문장으로 설명해야 했던 일을 오늘은 한 문장으로 시킬 수 있다. 이 구조적 장점 덕분에 OpenClaw를 누르고 에이전트 사용량 1위에 올랐을 것이다.
작년 말까지 Claude Code나 Codex를 터미널에 바로 띄워 개발하던 때와 지금의 에이전틱 개발이 가장 크게 달라진 지점은 모델의 지능이 아니다. 모델 위에 내 업무 기억과 개발 습관, 도구와 그 사용법, 완료 기준, 실패했을 때의 복구법이 미리 연결돼 있다는 점이다. 한 번의 실행 안에서 어떤 모델과 도구를 부를지, 어떤 전문 에이전트에게 일을 넘길지, 어떤 맥락을 함께 건넬지, 어디서 멈춰 내게 확인받을지를 조정한다. 업계에서 오케스트레이션이라 부르는 실행 제어다.
모델이 두뇌라면 이 층은 오늘 어떤 기억을 안고 깨어날지, 무엇을 경계하고 어디서 멈출지를 정한다. 더 좋은 모델은 나올 때마다 갈아 끼울 수 있다. 반면 함께 일하며 생긴 방식은 그렇게 쉽게 교체되지 않는다. 개인화의 무게중심은 모델이 아니라 모델 바깥에 쌓인다.
그래서 내가 에이전트에게 가장 자주 하는 말은 새 기능을 만들어 달라는 말이 아니다.
“방금 실수한 부분을 다음에는 실수하지 않게 구조적으로 고쳐.”
그러면 에이전트는 틀린 답 하나만 고치지 않는다. 기억이 부족했는지, 규칙이 모호했는지, 완료 조건이 허술했는지 되짚는다. 메모리와 스킬을 손보고 회귀 테스트를 붙인다. 어느 순간부터 내 에이전트는 자신의 운영 규칙과 복구 로직을, 때로는 Hermes의 핵심 코드까지 직접 뜯어고치기 시작했다.
올해 봄 OpenClaw를 쓰다 Hermes로 건너왔을 때, 제온과 시온, 미온, 사노, 라온으로 부르는 내 다섯 에이전트를 각자의 텔레그램 봇에 연결할 방법이 없었다. 그래서 하나의 게이트웨이가 여러 프로필을 나눠 맡도록, 봇마다 서로 다른 성격과 메모리와 세션을 불러오도록 코드를 직접 고쳤다. 잘못된 계정이 들어오면 다른 봇으로 넘기지 않고 응답 자체를 막았다. 기억이 한 번 섞이면 개인화의 전제가 무너지기 때문이다. Hermes의 공식 구현은 6월 18일에 공개되어 다음 날 릴리스에 포함됐다. 지금은 공식판에서도 옵션을 켜면 한 게이트웨이가 여러 프로필의 봇을 함께 관리한다. 결국 같은 방향으로 만났지만, 그사이 내게 필요했던 기능은 내 코드가 메웠다.
여러 프론티어 모델을 동시에 부르는 도구도 바꿨다. 한 모델이 늦었다고 전체가 멎지 않도록 호출마다 제한시간을 두고, 먼저 도착한 답은 버리지 않고 남겼다. 일이 남았는데 끝났다고 착각하는 문제에는 미완료 항목이 있으면 완료를 선언하지 못하는 장치를 붙였다. 긴 작업이 중간에 끊길 때는 판단 이유와 중간 결과를 반드시 남기게 했다. 같은 실패를 겪을 때마다 기억만 늘어난 게 아니라, 다음 실패를 다루는 코드가 달라졌다.
이런 수정을 수없이 거듭한 지금, 내가 쓰는 Hermes는 순정 Hermes와 상당히 멀어졌다. 같은 씨앗에서 출발했지만 내 잔소리와 시행착오를 먹고 자란 다른 계통이다. 직접 만든 에이전트 메모리 시스템 MemKraft도 무엇을 결정했는지만 저장하지 않는다. 왜 그렇게 판단했는지, 결과는 어땠는지, 그 정보를 언제까지 믿어도 되는지를 함께 남긴다. 내가 리뷰하는 것도 코드 자체보다 변경의 이유에 가깝다.
이러한 흐름 속에서 소프트웨어 개인화라는 단어의 정의는 크게 달라질 것이다. 지금까지의 개인화는 완성된 소프트웨어 안에서 아이콘 배치나 배경색, 단축키 따위를 고르는 일이었다. 에이전트와 함께 지내면 경험이 기억으로만 남지 않는다. 그 기억이 규칙을 바꾸고, 검증할 테스트와 새 도구를 만들고, 복구 로직과 코드베이스 자체를 갈아엎는다. 설정에는 취향이 남지만 코드에는 한 사람이 실패하고 회복한 방식이 남는다.
그래서 오케스트레이션이라는 말만으로는 부족하다. 오케스트레이션은 주어진 실행 안에서 순서와 분기를 조정하는 일이고, 내가 보고 있는 건 그 실행을 감싸는 기억과 규칙과 코드가 경험을 거치며 다음 버전으로 넘어가는 단계다.
나는 이 갈라짐을 개인별 에이전트 계보(Agent Lineage)라고 부르고 싶다. 같은 기반에서 출발한 에이전트가 한 사람의 선택과 실패를 검증되고 되돌릴 수 있는 형태로 번역해 자기만의 계보로 갈라지는 것이다.
그러면 모두가 같은 형태의 에이전트를 쓴다는 전제도 어긋난다. 업데이트는 완성된 새 버전을 통째로 덮어쓰는 일이 아니라, 플랫폼이 고친 공통 기능과 내가 키운 변경을 서로 합치는 일이 된다. 같은 Hermes 2.0을 받아도 누구의 에이전트는 결제 전에 세 번 확인하고, 누구의 것은 일을 더 잘게 나누며, 누구의 것은 모호한 부탁을 받으면 먼저 되묻는다. 화면만 다른 게 아니라 작동 원리의 일부가 다르다.
에이전트 플랫폼의 역할도 전혀 달라진다. 완성품을 배포하는 대신 계보를 키우는 곳이 된다. 공통 기반의 보안 업데이트는 받아들이되 나를 닮아 바뀐 규칙은 지켜야 하고, 개인의 코드와 공식판이 충돌하면 병합해야 하며, 잘못 배운 변화만 골라 되돌리면서 기억은 남겨야 한다. 경쟁력은 기능의 개수보다 수백만 갈래로 갈라진 계보의 상속과 병합, 검증과 롤백을 안전하게 관리하는 능력에서 나올 것이다.
개발에서 먼저 겪은 이 구조는 일상 생활로 번질 것이다. 일정과 관계, 이동과 구매, 건강과 일은 지금 서로 다른 앱에 흩어져 있다. 개인 에이전트는 그 사이를 따라다니며 한 사람의 맥락을 이어 붙인다. 지난 여행에서 싫어했던 동선과 긴 회의 다음 날에는 약속을 잡지 않는 습관이 같은 기억 안에서 만난다. 기억이 쌓이면 행동이 달라지고, 행동이 반복되면 그 사람에게만 맞는 규칙과 코드가 생긴다.
같은 에이전트를 받은 두 사람도 몇 달 뒤면 같은 요청에 전혀 다른 답을 내놓을 것이다. “이번 주말에 내가 좋아할 만한 숙소를 골라줘.” 한 사람의 에이전트는 전망도 없는 구도심의 작은 호텔을 잡는다. 그가 여행에서 오래 기억한 것이 새벽 골목의 빵집과 낡은 서점이었기 때문이다. 다른 사람의 에이전트는 식당 하나 없는 외딴 바닷가 숙소를 고른다. 지난 여행에서 계획을 전부 취소하고 파도 소리만 듣던 오후를 가장 좋아했다고 기억하기 때문이다. 같은 문장 뒤에 서로 다른 생의 기록이 붙자 정답도 갈라진다.
역설적으로 소프트웨어가 사람마다 갈라질수록 공통 기반은 더 중요해진다. 여러 서비스를 오가며 실제로 행동하려면 신원과 권한, 결제와 기록, 감사와 되돌리기의 문법은 같아야 한다. 개인의 코드는 달라져도 서로 만나는 접합부는 단단해야 한다. 지금의 SaaS도 사라지기보다는 화면 뒤로 물러나, 에이전트가 기대는 공식 기록과 책임의 기반이 될 가능성이 크다.
그때 가장 중요한 질문은 어느 모델을 쓰느냐가 아닐 것이다. 나와 함께 변한 규칙과 코드, 실패를 통과하며 만들어진 계보는 누구의 것인가. 플랫폼을 옮길 때 그 전부를 데려갈 수 있는가. 좋은 플랫폼은 가장 똑똑한 에이전트 하나를 파는 곳이 아니라, 사람마다 다르게 자란 계보가 끝까지 그 사람에게 속하도록 만드는 곳일 것이다.
마이크 버튼을 누른다. “아니, 그건 취소하고.” 무심코 덧붙인 망설임 하나가 기억이 되고, 규칙이 되고, 에이전트의 뼈대가 되는 코드 한 줄을 바꿔 놓고 있다.
❤4