AI agent에게 일을 맡기면 결과물이 빠르게 나온다. 하지만 빠르게 나온 결과물이 실제로 맞는지는 별개의 문제다.
여러 프로젝트를 진행하면서 느낀 것은 간단하다. 좋은 agent workflow는 “무엇을 만들었는가”보다 “무엇을 확인했는가”를 잘 남긴다.
내가 쓰는 역할 분리
AI 도구를 하나로 보지 않고 역할을 나눠서 생각한다.
- repo 구현과 코드 수정은 Codex/Claude Code 같은 coding agent가 잘한다.
- 브라우저, GUI, 로컬 앱 조작은 OpenClaw/Hermes 같은 local operating layer가 더 맞다.
- 여러 프로젝트를 병렬로 굴릴 때는 repo와 worktree 경계를 먼저 나누는 것이 중요하다.
- 모바일에서 이어받을 때는 긴 세션 자체보다 짧은 handoff가 더 안정적이다.
이 구분을 해두면 “AI에게 맡겼다”가 아니라 “어떤 종류의 일을 어떤 도구에게 맡겼다”가 된다.
남겨야 하는 것
- 어떤 명령을 실행했는지
- 어떤 테스트가 통과했는지
- 브라우저에서 어떤 흐름을 확인했는지
- 배포나 preview가 실제로 어떤 commit을 가리키는지
- 실패했을 때 어떤 조건에서 재현되는지
경계도 필요하다
agent에게 모든 것을 맡기는 것보다 작업 경계를 작게 자르는 쪽이 낫다. 한 번에 제품 전체를 맡기면 검증도 흐려진다. 반대로 글 하나, 테스트 하나, 릴리즈 체크 하나처럼 경계를 작게 잡으면 결과를 확인하기 쉽다.
실제로 효과가 있었던 패턴
Dessert Rush에서는 Godot smoke test, Web export, Toss build, integration test, browser QA를 하나의 릴리즈 흐름으로 묶었다. Oracle에서는 preview URL만 보지 않고 deployed commit과 readiness API를 따로 확인했다. Cat Rescue에서는 web editor와 Godot/Toss 쪽을 같은 JSON 레벨 포맷으로 연결하려고 했다.
공통점은 하나다. 결과물을 사람이 눈으로 훑는 것에서 끝내지 않고, 다음에도 같은 기준으로 확인할 수 있게 명령과 문서로 남겼다.
실패하기 쉬운 지점
- 세션이 너무 길어져 모바일에서 열리지 않는다.
- agent가 만든 상태와 실제 배포 상태가 다르다.
- 로컬 repo가 여러 개라 active repo를 착각한다.
- 테스트는 통과했지만 브라우저에서 기본 flow가 깨진다.
- 작업 기록은 있는데 사용자가 이어받기 어렵다.
그래서 긴 스레드를 살리는 것보다 짧은 replacement handoff를 만드는 편이 나을 때가 많았다. 특히 모바일 이어받기에서는 “어디까지 됐고, 다음에 무엇을 하면 되는지”만 남기는 게 더 실용적이었다.
이 블로그도 그런 기록을 남기기 위한 장소로 쓸 생각이다.