Essays#

여기는 Notes 안에서 생각/의견/관찰/회고/방향성 성격의 글을 모아두는 곳입니다.

• 사건이나 현상에 대한 개인적인 의견
• 블로그/일/삶에 대한 방향성 정리
• 짧은 관찰부터 긴 에세이까지

LLM Wiki, 직접 열어보니 — ‘자동 기억’이라는 오해와 몇 줄짜리 스키마#

2026-06-28

지난 글 하네스 스킬이라 부르기로 했다에서, 필자는 닫아 두었던 문을 열어 외부의 검증된 패턴을 하나씩 들여다보기로 했습니다. 그리고 침습도가 낮은 것부터 흡수하겠다고 적었습니다. 그 첫 번째 대상이 LLM Wiki였습니다. 이번 글은 그 다짐을 실제로 옮긴 기록입니다. 개념만 알던 것을 직접 저장소에 적용해 보았고, 그 과정에서 두 가지 오해를 바로잡게 되었습니다.

LLM Wiki가 뭐였더라#

LLM Wiki는 Andrej Karpathy(안드레이 카파시)가 2026년 4월에 제안해 화제가 된 패턴입니다. 한 줄로 말하면 “원본 문서 더미를, LLM이 직접 관리하는 위키백과로 바꿔 두는 것” 입니다.

AI 도구 지식 지도 — 업무 프로세스 개선 컨설팅을 위한 재료 나래비#

2026-06-14

들어가며#

필자는 한동안 막연한 갈증을 느껴 왔습니다. AI 도구는 매주 쏟아지는데, 정작 “어떤 도구가 있고, 각각이 무엇이며, 언제 어떤 조합으로 쓰는 것이 좋은가"를 머릿속에서 한 장으로 펼치지 못하고 있었습니다. 개별 도구는 쓰고 있지만, 그것들을 지도(map) 위에 올려놓고 보지는 못했던 것입니다.

이 갈증에는 목적이 있습니다. 필자는 AI를 활용한 업무 프로세스 개선을 누군가에게 제안하고 컨설팅할 수 있는 수준에 이르고 싶습니다. 그러려면 가장 먼저 해야 할 일은 화려한 전략이 아니라, 재료를 나래비(나열)하는 것입니다. 어떤 도구들이 있는지, 각각이 어떤 성격의 도구인지부터 손에 잡혀야 그 위에 조합과 전략을 세울 수 있습니다.

하네스 스킬이라 부르기로 했다 — 잘하고 있다는 착각을 깨고 내 하네스를 열기까지#

2026-06-08

이름 없는 것들 앞에서#

LLM Wiki라는 것을 처음 봤을 때, 그리고 GStack을 봤을 때, 필자가 가장 먼저 한 생각은 의외로 “이걸 뭐라고 불러야 하지?” 였습니다.

둘 다 AI 에이전트를 더 잘 다루기 위한 수단이라는 점은 분명했습니다. 필자가 이전 글에서 정리한 하네스 엔지니어링, 즉 AI 에이전트를 안전하고 안정적으로 운용하기 위한 인프라 설계 분야의 관점에서 보면, 이런 것들은 명백히 “하네스를 만들 때 가져다 쓰는 도구"였습니다.

노트북을 접어도 일하는 에이전트: Lightsail, Hermes, Discord로 만든 원격 개발 환경#

2026-06-01

문제는 노트북이 접히는 순간 시작되었습니다#

필자는 한동안 Hermes Agent를 로컬 노트북에 설치해서 사용했습니다. 로컬에서 바로 저장소를 열고, 파일을 수정하고, 테스트를 실행하는 경험은 빠르고 직관적이었습니다. 하지만 생활 패턴과 맞지 않는 문제가 있었습니다. 노트북을 접어서 가방에 넣는 순간 에이전트도 함께 멈췄습니다.

AI 에이전트를 쓰는 이유는 사람이 자리를 비운 동안에도 일을 맡기기 위해서입니다. 그런데 실행 환경이 로컬 노트북에 묶여 있으면, 이동 중에는 모바일로 확인만 할 수 있고 실제 작업은 이어가기 어렵습니다. 특히 긴 테스트, 의존성 설치, 저장소 분석처럼 시간이 걸리는 작업은 노트북이 켜져 있어야만 진행됩니다.

AI 에이전트 웹서비스에 코딩 런타임을 붙이는 방법#

2026-04-19

개인적으로 AI 에이전트 기반의 웹서비스를 구상하거나 개발할 때, 꽤 빠르게 부딪히는 질문이 있습니다.

“이 서비스의 에이전트가 정말 일을 하게 만들려면, 코딩 능력을 어디서 가져와야 할까?”

아이디어를 처음 잡을 때는 흔히 이렇게 생각하기 쉽습니다. 모델 API를 붙이고, 파일 편집 기능을 만들고, 셸 명령을 실행하고, 테스트를 돌리고, 결과를 정리하면 되지 않을까. 하지만 조금만 깊게 들어가 보면, 그 안에는 생각보다 많은 것이 들어 있습니다.

Hermes Agent — Agent계의 명품인가? 직접 써보고 정리한 첫인상#

2026-04-19

들어가며#

요즘 주변에서 Hermes Agent 이야기를 자주 듣습니다. 그중에서도 같은 팀 동료에게서 직접 들은 운영 사례가 가장 인상적이었습니다. 그 동료는 Hermes를 회사 슬랙에 연결해 팀원들이 슬랙에서 @Hermes 한 줄로 데이터 조회, 작업 의뢰, QnA를 처리할 수 있는 환경을 이미 만들어두고 있었습니다. 필자도 바로 감을 잡아보고 싶어, 오늘 하루 동안 다음 세 가지를 한꺼번에 진행했습니다.

Claude Managed Agents — 기존 에이전트 시스템을 대체할 수 있을까?#

2026-04-12

들어가며#

2026년 4월 8일, Anthropic이 Claude Managed Agents를 퍼블릭 베타로 출시했습니다. 에이전트 루프, 샌드박싱, 도구 실행 인프라를 직접 구축하지 않아도, 에이전트를 선언만 하면 Anthropic이 오케스트레이션을 처리해주는 호스팅형 실행 환경입니다.

필자는 현재 두 가지 에이전트 시스템을 운영하고 있습니다. 하나는 Claude Code + 하네스 기반의 로컬 작업 환경(이하 “로컬 에이전트”)으로, 운영자가 실시간으로 AI와 대화하며 업무를 처리합니다. 다른 하나는 Strands + AWS Bedrock AgentCore 기반의 멀티에이전트 시스템(이하 “시스템 에이전트”)으로, 사람 없이 자동으로 모니터링, 진단, 리포트를 수행합니다.

Codex는 어디서 써야 할까: CLI, App, Cursor, Claude Code 정리#

2026-04-12

요즘 Codex가 좋다는 이야기가 자주 들립니다. 그런데 막상 써보려고 하면 바로 헷갈리기 시작합니다.

• Codex CLI로 쓰는 것이 맞는지
• Codex App이 따로 있는지
• Cursor 안에서 Codex 확장을 깔아 쓰면 되는지
• 아니면 Cursor 채팅에서 그냥 Codex 모델만 고르면 되는지
• Claude Code에 플러그인으로 붙이는 것이 맞는지

필자도 비슷한 궁금증이 생겨서 공식 문서를 기준으로 하나씩 정리해 봤습니다. 이 글은 개발자뿐 아니라, AI 코딩 도구가 어떻게 구성되는지 잘 모르는 분도 따라올 수 있도록 최대한 쉽게 설명하려고 했습니다.

하네스 엔지니어링 — AI 에이전트를 안전하게 운용하기 위한 실전 가이드#

2026-04-04

이 글을 쓰게 된 이유#

필자는 여러 프로젝트에서 AI 에이전트(Cursor, Claude Code 등)를 적극적으로 활용하고 있습니다. 처음에는 에이전트가 코드를 작성해 주는 것만으로도 충분히 놀라웠지만, 실제로 프로젝트에 깊이 적용하다 보니 반복적으로 부딪히는 문제들이 있었습니다.

• 새 세션을 열 때마다 에이전트가 프로젝트 컨벤션을 잊어버립니다
• 어제 해결한 문제와 같은 실수를 오늘 또 반복합니다
• 에이전트가 생성한 코드의 품질이 세션마다 들쭉날쭉합니다
• 프로젝트가 여러 개가 되면 각각에 같은 설정을 반복해야 합니다

이 문제들의 본질은 에이전트의 지능이 부족한 것이 아니라, 에이전트를 둘러싼 환경이 제대로 갖춰지지 않은 것이었습니다. 2026년에 들어서면서 이 문제의식이 업계 전체로 확산되었고, “하네스 엔지니어링"이라는 이름으로 체계화되기 시작했습니다.