AI 두 개가 같은 checkout을 쓰자 branch가 바뀌었다 — Shared workspace concurrency 사고
서로 다른 작업을 수행하던 Claude와 Codex 세션이 같은 mutable checkout을 공유하면서 branch context가 바뀌고 한 세션의 변경이 잘못된 checkout에 들어갔다. AI 병렬 실행에서 workspace 자체가 shared mutable state라는 사실을 정리한다.
TOPIC / AI-Native Engineering
AI-Native Engineering
이 주제와 연결된 구현, 운영, 설계 결정과 회고를 모아 봅니다.
AI가 매번 같은 코드를 다시 쓰게 하지 않기로 했다 — 개인 소프트웨어 자산화의 기준
프로젝트가 늘어나자 AI에게 같은 controller, DTO, cache adapter, UI 구조를 반복 생성시키는 비용이 보이기 시작했다. 모든 것을 generic framework로 만들지 않으면서 재사용 자산을 쌓는 기준을 정리한다.
기록을 많이 남겼는데 더 찾기 어려워졌다 — 파일을 옮기지 않고 Retrieval Layer를 만든 이유
History가 커지자 기록 부족보다 검색 비용이 문제가 됐다. 원문을 프로젝트별로 재배치하는 대신 provenance를 보존하고 catalog, query, purpose-specific projection을 위에 얹은 과정을 정리한다.
프로젝트가 많아서 힘든 게 아니었다 — 아키텍처를 그려보고 알게 된 인지 부하의 정체
PaaS, PhotoGram, CharaWeave, Workspace Ops를 한꺼번에 아키텍처로 펼쳐보니 문제는 프로젝트 개수가 아니었다. 서로 다른 상태 모델과 authority를 머릿속에서 반복해 재구성하던 비용이 실제 병목이었다.
AI가 만든 작은 예외는 어떻게 새로운 아키텍처가 되는가
문제는 Python 자체가 아니었다. 작은 구현 편의가 현재 코드에 남고, 다음 AI가 그것을 정상 아키텍처로 해석하면서 Human이 승인하지 않은 선례가 누적되는 과정을 정리한다.
AI 프롬프트를 77% 줄였는데 입력 비용은 왜 줄지 않았을까
실행 프롬프트와 handoff를 크게 줄인 뒤 실제 context 비용도 줄었는지 측정했다. 결과는 단순했다. 전송량을 줄이는 것과 모델이 다시 읽는 정보량을 줄이는 것은 다른 문제였다.
AI와 개발하면서 내가 직접 코드를 덜 쓰게 된 대신 더 많이 하게 된 일들
코드를 직접 쓰는 시간은 줄었는데 개발한다는 감각은 오히려 강해졌다. CharaWeave와 workspace-ops를 만들던 하루를 돌아보며 AI가 구현량을 맡은 뒤 내가 더 많이 하게 된 일을 정리했다.
여러 AI를 쓴다고 AI Gateway가 필요한 건 아니었다
여러 AI를 하나의 최적 응답으로 수렴시키는 대신, 서로 다른 관점을 의도적으로 보존하고 충돌시킨 뒤 실제 실행 단계에서 강하게 통제하는 개발 방식을 정리한다.