Arex 의 개발일기 Arex 의 개발일기

새 화면의 API 연동을 끝내면 늘 비슷한 질문이 남습니다.지도에 진입했을 때 viewport API는 정확히 한 번만 호출될까?필터를 탭하면 서버가 기대하는 쿼리 파라미터가 붙을까?바텀시트를 크게 펼쳤을 때 detail API가 그 시점에만 호출될까?단위 테스트는 요청 메서드가 호출됐는지 알려주지만, 실제 앱에서 실제 제스처로 서버에 무엇을 몇 번 보냈고 어떤 응답을 받았는지는 충분히 보여주지 못할 때가 있습니다.DDD 13기 사이드 프로젝트 Pickflow에서 지도와 스팟 리스트 API를 검증하며 이 간극을 메우는 워크플로우를 만들었습니다. 프록시 도구 대신 앱의 네트워크 로그를 stdout으로 흘리고, 사람이 시뮬레이터를 한 단계씩 조작하면 AI 코딩 에이전트가 로그를 읽어 명세와 비교하는 방식입니..

AI 코딩 에이전트를 하나만 사용할 때는 터미널 창 하나면 충분하다. 하지만 기능 구현, 리뷰 반영, 빌드 확인을 동시에 맡기기 시작하면 문제가 달라진다.에이전트를 여러 개 실행하는 것 자체는 어렵지 않다. 진짜 어려운 일은 각 에이전트가 서로의 코드를 밟지 않도록 작업 공간을 나누고, 어느 세션이 내 판단을 기다리는지 놓치지 않는 것이다.DDD 13기 사이드 프로젝트 Pickflow에서 iOS 개발을 진행하며 이 문제를 자주 겪었다. Xcode와 Tuist를 사용하는 프로젝트라 브랜치 전환 비용도 컸다. 결국 브랜치를 계속 바꾸는 방식을 버리고, 티켓마다 git worktree를 만들었다.여기에 여러 터미널과 AI 에이전트 세션을 정리하는 cmux를 결합하면 역할이 명확해진다.· git worktree..