직전 글에서 다음으로 볼 항목을 이렇게 적었다. review 결과를 findings table로 구조화 transcript replay와 session browser agent-deck-web dashboard 이번에는 앞의 두 개를 먼저 닫았다. 저장소: hoonapps/agent-deck 이번 커밋: e713975 왜 rep...

이전 글의 마지막에 agent-deck 다음 작업으로 적어둔 항목들이 있었다. TUI 안에서 timeout 변경 transcript pause/redaction 3개 이상 agent layout blog-from-transcript 터미널 cockpit polish 이번 커밋에서 이 묶음을 실제로 넣었다. 저장소: hoona...

이전 글에서 agent-deck를 “여러 AI 코딩 에이전트를 한 터미널에서 조율하는 도구”로 정리했다. 오늘은 바로 한 단계 더 밀었다. 저장소: hoonapps/agent-deck 이번 커밋: 7b7d0d8 이번 목표 처음 버전은 여러 agent pane을 한 화면에 두고 메시지를 라우팅하는 데 집중했다. 그런데 실제로 매일 쓰려면 부족한 ...

agent-deck는 내가 로컬에서 여러 AI 코딩 에이전트를 한 터미널 안에서 조율하려고 만든 TUI 도구다. 저장소: hoonapps/agent-deck 왜 만들었나 AI 코딩 에이전트를 실제 작업에 쓰다 보면 한 가지 문제가 반복된다. Codex는 Codex 터미널에서 돌고, Claude는 Claude 터미널에서 돌고, 테스트는 또 다른 ...

수집 시각: 2026-06-16 14:10 KST. 오늘 기준으로 GitHub, Hacker News, 공식 문서에서 다시 확인한 AI Agent 흐름이다. Threads나 X에서 본 링크는 바로 믿지 않고, 공식 문서나 저장소로 한 번 더 확인하는 방식으로 가져간다. 내 블로그의 AI 글은 앞으로 이런 식으로 짧게라도 매일 쌓아갈 예정이다. 관점...

백엔드 글은 프레임워크 사용법에서 멈추기 쉽다. 컨트롤러를 만들고, ORM을 붙이고, Docker로 띄우는 글은 필요하지만 그 자체로 깊이를 만들지는 못한다. 실무에서 중요한 질문은 보통 그 다음에 나온다. 트랜잭션은 정확히 어디까지 보장하는가? 장애가 나면 중복 요청은 어떻게 처리되는가? 큐가 밀릴 때 시스템은 어떻게 느려지는가? ...

Threads나 GitHub에서 AI 도구를 보다 보면 데모는 훌륭한데 실제 프로젝트에 넣기 애매한 경우가 많다. 그래서 오픈소스를 볼 때 확인할 기준을 정리해 둔다. 1. README가 아니라 실행부터 본다 README는 프로젝트가 되고 싶은 모습에 가깝다. 실제 품질은 설치 과정에서 드러난다. 확인할 것: Node, Python, Do...

서비스가 커지면 “DB에 저장하고 이벤트를 발행한다”는 코드가 자주 나온다. 주문을 저장한 뒤 결제 이벤트를 보내고, 사용자 가입을 저장한 뒤 환영 메일 이벤트를 보내는 식이다. 문제는 DB 트랜잭션과 메시지 브로커 발행이 같은 원자성 안에 있지 않다는 점이다. 흔한 코드 await dataSource.transaction(async manager...

AI 기술을 따라가다 보면 링크와 데모가 금방 쌓인다. 모든 도구를 깊게 볼 수는 없으니, 글로 남길 때 확인할 기준을 먼저 정리해 둔다. 수집 수집 채널은 넓게 가져간다. GitHub Trending과 릴리스 노트 모델 제공사의 공식 문서와 changelog Hugging Face, arXiv, Papers with Code H...

블로그를 다시 정리한다. 방향은 단순하다. 기존 영어 글은 남기고, 앞으로의 기준 언어는 한국어로 바꾼다. 새 글은 카테고리를 나눠서 조금 더 찾기 쉽게 관리하려고 한다. 왜 바꾸는가 AI 이후 개발자의 정보 환경은 완전히 달라졌다. 새로운 모델, 에이전트 프레임워크, MCP 서버, RAG 도구, 개발자 자동화 도구가 매일 나온다. 문제는 정보의 ...