2월 4, 20262026-02-04
필자는 소프트웨어 엔지니어이자 AI 엔지니어로서, 중장기적으로 무엇을 신경 쓰고 무엇을 목표로 삼아야 하는지, 그리고 어떤 마인드로 살아가야 하는지를 자주 고민합니다. 요즘처럼 기술 변화가 빠른 시기에는, 계획이 흔들리는 것 자체가 자연스러운 일이라고 생각합니다. 그런데 자연스럽다고 해서 가볍게 넘길 수 있는 것은 아닙니다. 흔들림은 결국 제 행동을 바꾸고, 행동은 결과를 바꾸기 때문입니다.
얼마 전 OpenClaw라는 개인 에이전트 개념이 등장했고, 예상보다 훨씬 많은 사람들이 폭발적으로 반응하는 모습을 봤습니다. “대박이다 / 신기하다” 같은 감정도 있었지만, 그보다 먼저 든 생각은 “새로운 개념이 너무 빠른 속도로 나온다”였습니다. 그리고 그 속도는 곧바로 제 질문으로 이어졌습니다. 내가 지금 맞는 방향으로 잘 걷고 있는가 입니다.
2월 8, 20262026-02-08
Claude Cowork라는 기능이 나왔습니다. (나온 지는 좀 됐는데, 필자가 이제서야 들여다 봤습니다.) 아래에 주저리주저리 더 이야기를 할 텐데요, 바쁘신 분들을 위해 먼저 짧게 요약해 보겠습니다.
Cursor(AI 기반의 코드 에디터)로 개발 작업을 하다 보니, 이 방식을 개발이 아닌 다른 업무에도 활용할 수 있지 않을까 생각했었습니다. 그런데 Cursor가 태생적으로 소프트웨어 개발 도구이다 보니, 비개발 업무에 맞게 사용하기엔 진입 장벽이 있었습니다. 그래서 ChatGPT나 Claude에서 비개발 업무를 더 자연스럽게 처리할 수 있는 형태의 애플리케이션이 나오지 않을까 내심 기대하고 있었는데, Claude에서 Cowork라는 기능이 먼저 나왔습니다.
3월 11, 2026요즘 개발자 커뮤니티에서 OpenClaw를 모르는 사람을 찾기가 더 어려울 정도입니다. GitHub 스타가 30만 개를 넘겼고, 출시 첫 주에만 200만 명이 방문했습니다. X(Twitter), Discord, Reddit 할 것 없이 온통 OpenClaw 이야기입니다.
OpenClaw는 한마디로 내 컴퓨터에서 돌아가는 개인 AI 에이전트 플랫폼입니다. 원래 2025년 11월에 “ClawdBot” 이라는 이름의 주말 프로젝트로 시작했다가, 상표권 이슈를 거쳐 “Moltbot” 을 지나, 2026년 1월에 지금의 OpenClaw로 정착했습니다. 이름에 담긴 뜻은 단순합니다. “Claw” 는 프로젝트의 마스코트인 바닷가재(🦞)를 상징하고, “Open” 은 오픈소스와 커뮤니티 주도 개발을 의미합니다.
4월 4, 20262026-04-04
필자는 여러 프로젝트에서 AI 에이전트(Cursor, Claude Code 등)를 적극적으로 활용하고 있습니다. 처음에는 에이전트가 코드를 작성해 주는 것만으로도 충분히 놀라웠지만, 실제로 프로젝트에 깊이 적용하다 보니 반복적으로 부딪히는 문제들이 있었습니다.
이 문제들의 본질은 에이전트의 지능이 부족한 것이 아니라, 에이전트를 둘러싼 환경이 제대로 갖춰지지 않은 것이었습니다. 2026년에 들어서면서 이 문제의식이 업계 전체로 확산되었고, “하네스 엔지니어링"이라는 이름으로 체계화되기 시작했습니다.
4월 12, 20262026-04-12
2026년 4월 8일, Anthropic이 Claude Managed Agents를 퍼블릭 베타로 출시했습니다. 에이전트 루프, 샌드박싱, 도구 실행 인프라를 직접 구축하지 않아도, 에이전트를 선언만 하면 Anthropic이 오케스트레이션을 처리해주는 호스팅형 실행 환경입니다.
필자는 현재 두 가지 에이전트 시스템을 운영하고 있습니다. 하나는 Claude Code + 하네스 기반의 로컬 작업 환경(이하 “로컬 에이전트”)으로, 운영자가 실시간으로 AI와 대화하며 업무를 처리합니다. 다른 하나는 Strands + AWS Bedrock AgentCore 기반의 멀티에이전트 시스템(이하 “시스템 에이전트”)으로, 사람 없이 자동으로 모니터링, 진단, 리포트를 수행합니다.
4월 19, 2026
4월 19, 20262026-04-19
개인적으로 AI 에이전트 기반의 웹서비스를 구상하거나 개발할 때, 꽤 빠르게 부딪히는 질문이 있습니다.
“이 서비스의 에이전트가 정말 일을 하게 만들려면, 코딩 능력을 어디서 가져와야 할까?”
아이디어를 처음 잡을 때는 흔히 이렇게 생각하기 쉽습니다. 모델 API를 붙이고, 파일 편집 기능을 만들고, 셸 명령을 실행하고, 테스트를 돌리고, 결과를 정리하면 되지 않을까. 하지만 조금만 깊게 들어가 보면, 그 안에는 생각보다 많은 것이 들어 있습니다.
6월 8, 20262026-06-08
LLM Wiki라는 것을 처음 봤을 때, 그리고 GStack을 봤을 때, 필자가 가장 먼저 한 생각은 의외로 “이걸 뭐라고 불러야 하지?” 였습니다.
둘 다 AI 에이전트를 더 잘 다루기 위한 수단이라는 점은 분명했습니다. 필자가 이전 글에서 정리한 하네스 엔지니어링, 즉 AI 에이전트를 안전하고 안정적으로 운용하기 위한 인프라 설계 분야의 관점에서 보면, 이런 것들은 명백히 “하네스를 만들 때 가져다 쓰는 도구"였습니다.
