$whoami
이상적인 소프트웨어 이론은 다들 안다. 근데 마감이 정해진 프로젝트에선 내 시간만 쓸 수가 없다. TDD의 장점을 인정하면서도, 현실과의 트레이드오프 안에서 내가 잡은 균형. 복구 가능한 에러는 전부 4xx로 명시하고, 그 에러 경로를 빠짐없이 테스트로 막는 이야기.
운영자가 알림 문구 하나 고치려고 매번 배포를 부탁하던 걸 없애고 싶었다. 근데 그 백오피스를 prod에 띄우자니 비밀번호로 막기도, IP로 막기도 애매했다. 결국 슬랙으로 내 IP를 등록해 여는, 비밀번호 없는 문을 만들었다.
같은 사건을 쓴 주니어 장애 회고 두 개. 하나는 AI가 그냥 뽑은 raw 버전, 다른 하나는 'AI 티'를 지워주는 도구로 윤문한 버전이다. 어느 쪽이 손 안 댄 AI인지 가려낼 수 있을까. 정답은 본문에서 드래그하면 드러난다. 한국어 AI 글의 문체 지문을 직접 확인하는 실험이다.
IntelliJ는 env 볼 때나 켜고, 터미널만 네 개 띄워놓고 에이전트를 병렬로 돌린다. 그러다 깨달았다 — 병목은 터미널이었다. iTerm2에서 tmux를 거쳐 cmux로 갈아타며, 에이전트 시대의 터미널이 무엇이어야 하는지 정리한 기록.
잘하지도 못했고, 대회에 나간 적도 없다. 그냥 그 사이트가 있었다.
웹 only 환경에선 httpOnly 쿠키가 정답이었는데, Native · WebView 까지 환경이 셋이 되니 그 답이 깨졌다. body 채널을 왜 망설였는지부터 dual contract 까지, 책임 분담을 다시 따져본 기록.
직접 만든 오케스트레이터에 Playwright MCP를 붙여서 실제 브라우저를 제어했다. 코드 한 줄 안 바꾸고.
MCP 서버가 여러 개가 되는 순간 에이전트는 어디에 요청해야 할지 모른다. 그 문제를 오케스트레이터로 풀었다.
MCP를 클라이언트로만 쓰다가, 직접 서버를 만들어야 하는 상황이 됐다.
블로그를 만들고 나서 추가한 것들. 구글 검색에 노출되게 하고, 댓글이 달리면 이메일로 알림 받기.