Notes#
여기는 Books나 Apps에 속하지 않는, 일반 블로그 글을 쓰는 공간입니다.
주로 기술적인 내용들을 정리하겠지만, 가끔은 일상의 이야기나 어떤 현상들에 대한 개인적인 의견도 기록할 예정입니다. 길게 정리한 글부터 짧은 메모까지, 그때그때 공유하고 싶은 내용을 편하게 쌓아갑니다.
다루는 내용#
- 기술 메모: 삽질 기록, 트러블슈팅, 개념 정리, 짧은 팁
- 개인 노트: 일상 기록, 관찰, 느낀 점, 의견
서브 카테고리#
- Essays: 생각/의견/관찰/회고/방향성 같은 글(Notes의 기본 그릇)
- Investments: 투자 수단/전략을 정리하고, 몰랐던 개념을 하나씩 확인해 쌓아가는 공간
참고#
- 내용은 수시로 수정/보완될 수 있습니다.
- 왼쪽 사이드바에서 글 목록을 확인할 수 있습니다.
최신 글
에이전트에게 브라우저를 맡길 때 만나는 두 개의 벽
코딩 에이전트가 브라우저로 직접 검증하게 하는 워크플로우에서 부딪힌 두 가지 문제 — 다중 세션의 크롬 충돌과 구글 로그인 차단 — 의 원인을 분석하고, --isolated 옵션과 attach 패턴으로 해결한 과정을 정리합니다.
AI 에이전트 시대의 컨텍스트 스위칭 — 사람이 스케줄러가 될 때
AI 에이전트가 최종 작업을 대신하는 시대, 사람의 병목은 여러 에이전트 사이를 오가는 컨텍스트 스위칭으로 옮겨왔습니다. 주의 잔류와 재개 지연 연구를 근거로, 알림 즉시 전환 금지·재개 메모·대화형 작업 수 제한이라는 세 가지 운용 규칙을 정리합니다.
활성 사용자 급락의 범인을 찾아서 — 봇, 착시, 그리고 색인 붕괴
Google Analytics 활성 사용자 그래프가 가파르게 떨어졌을 때, 그 숫자를 그대로 믿는 대신 데이터를 한 겹씩 벗겨가며 진짜 원인을 찾은 과정을 정리합니다. 봇 트래픽 판별법, 도메인 이전 후 색인 붕괴 진단, 그리고 색인 다이어트까지의 기록입니다.
코딩 에이전트의 디자인은 왜 비슷비슷한가 — 디자인 스택을 고르기까지의 조사와 결정
코딩 에이전트가 만드는 웹 디자인이 비슷비슷하고 어설픈 이유를 짚고, 이를 해결하기 위한 스킬·MCP·하네스 지침을 조사하여 실제 프로젝트의 디자인 스택을 결정하기까지의 과정을 정리한 에세이입니다.
LLM Wiki, 직접 열어보니 — '자동 기억'이라는 오해와 몇 줄짜리 스키마
Andrej Karpathy가 제안한 LLM Wiki를 실제로 저장소에 적용해 보며 깨달은 것들을 정리했습니다. '알아서 갱신되는 자동 기억'이라는 오해를 바로잡고, 이 패턴의 핵심이 사실은 '몇 줄짜리 스키마'라는 점, 그리고 그것을 어떻게 저장소에 들였는지를 다룹니다.
feature flag는 무엇을 해결하는가 — 단일 브랜치 협업과 구글식 트렁크 개발의 오해
여러 사람이 하나의 브랜치에 직접 push하는 협업 방식의 문제를 feature flag로 풀 수 있는지 검토한 에세이입니다. feature flag가 실제로 해결하는 문제와 그렇지 못한 문제, 그리고 구글식 트렁크 개발이 작동하는 진짜 조건을 정리합니다.
AWS Bedrock은 모델을 중계하는 줄 알았는데, 알고 보니 직접 돌리고 있었습니다
AWS Bedrock이 Claude·GPT 같은 외부 LLM을 어떻게 제공하는지 파고든 기록입니다. 전용선 중계가 아니라 직접 호스팅이며, 암호학적 봉인과 무운영자접근으로 모델 자산을 보호하는 구조를 정리했습니다.
AI 도구 지식 지도 — 업무 프로세스 개선 컨설팅을 위한 재료 나래비
AI를 활용한 업무 프로세스 개선을 컨설팅할 수 있는 수준에 이르기 위해, 시중의 AI 도구들을 카테고리별로 정리하고 각각의 개념과 활용 방안을 짚었습니다. 챗봇부터 코딩 도구, 자율 에이전트, 관리형 AI 플랫폼까지 자주 훑어볼 지식 지도로 삼습니다.
하네스 스킬이라 부르기로 했다 — 잘하고 있다는 착각을 깨고 내 하네스를 열기까지
LLM Wiki, GStack 같은 도구를 무엇이라 불러야 할지 고민하다 시작된 이야기입니다. 표준 용어가 없어 '하네스 스킬'이라 명명하고, 자체 하네스에 대한 자신감이 어떻게 성장의 함정이 되었는지 돌아본 뒤, 널리 쓰이는 대표 하네스 스킬들을 정리했습니다.