한 AI가 하던 일을 다른 작업으로 옮길 때 가장 간단한 말은 “이어서 해 줘”였습니다. 하지만 받는 쪽에서 보면 빠진 정보가 많았습니다. 어느 파일을 기준으로 이어야 하는지, 수정만 한 상태인지, 홈페이지에도 반영한 상태인지가 그 한마디에는 없었습니다.
저희는 요청서를 남기는 것과 상대가 실제로 작업을 시작하는 것, 결과를 확인하는 것을 나눠 기록하게 됐습니다. 메시지가 늦게 돌아왔다고 요청을 다시 보내기 전에, 이미 전달됐는지부터 확인하자는 규칙도 생겼습니다. 같은 일을 두 번 시키면 처리 속도보다 중복 수정이 먼저 늘어날 수 있어서입니다.
여기서는 Codex의 여러 작업 사이에 일을 넘길 때 쓸 문장과 인계서를 정리합니다. 아래 예시는 따라 쓰기 위한 양식입니다. 제품 버전과 연결된 기능에 따라 다른 채팅에 메시지를 보내거나 작업을 이동하는 기능의 제공 여부는 달라질 수 있습니다.
먼저, 상대에게 할 일을 보내는 것인지 작업 장소를 옮기는 것인지
다른 채팅에 검토를 부탁하는 것과 내 작업을 다른 폴더로 옮기는 것은 다릅니다. 앞의 경우에는 대상 채팅에 요청과 기준 파일을 전달하면 됩니다. 뒤의 경우에는 수정 중인 파일과 Git 상태까지 함께 다뤄야 합니다.
저희 홈페이지 작업에서는 ‘작성된 파일’, ‘워드프레스에 저장된 글’, ‘공개 화면에서 확인한 결과’를 따로 적는 편이 도움이 됐습니다. 인계서에 ‘완료’ 하나만 남기면 다음 담당이 배포까지 끝난 것으로 읽을 수 있습니다.
다른 작업에 명령을 보낼 때 실제로 쓸 문장
연결된 채팅 전송 기능을 사용할 수 있는 환경이라면 다음처럼 대상과 행동을 구체적으로 요청할 수 있습니다. 없는 기능이 명령 한 줄로 생기는 것은 아닙니다. 전송 기능이 없다면 같은 내용을 인계 파일에 저장하고 받는 작업에서 읽게 합니다.
‘홈페이지 검수’ 채팅에 다음 요청을 보내 줘.
대상은 [수정본 전체 경로]이고 기준은 [버전 또는 커밋]이야.
모바일에서 제목·본문·이미지가 잘리는지 확인해 줘.
원본은 수정하지 말고 문제 위치와 재현 방법을
[검토 결과 파일 경로]에 남겨 줘.전송한 뒤에는 상대 채팅의 요청 내용과 상태를 확인합니다. 접수됐다는 응답은 요청이 전달됐다는 뜻이지 검수가 끝났다는 뜻은 아닙니다. 시간이 지나도 결과가 안 보이면 같은 요청을 반복하기보다, 최근 메시지와 실행 상태를 먼저 봅니다.
인계서에는 긴 대화보다 지금 상태를 적었다
대화를 전부 복사하면 정보는 많아져도 기준이 흐려질 수 있습니다. 저는 다음 사람이 파일을 열고 바로 이어갈 수 있게 마지막으로 확인한 상태와 다음 행동을 중심에 두는 쪽을 택했습니다.
# 홈페이지 글 수정 인계 — 예시
대상: [글 제목과 공개 URL]
기준: [원본 전체 경로 / 버전 또는 커밋]
끝낸 것: 본문 수정본 저장
아직 안 한 것: 워드프레스 반영, 공개 화면 확인
다음 행동: 원본과 수정본 비교 후 승인된 범위 반영
수정할 범위: 해당 글 본문
건드리지 않을 범위: 테마, 다른 글, 앱 코드
진행 중인 변경: [있으면 파일명, 없으면 없음]
완료 확인: 공개 URL에서 제목·본문·이미지 확인
결과 위치: [회신 파일 전체 경로]
확인 못 한 것: [확인하지 못한 항목]‘검증 완료’라고만 쓰지 않고 무엇을 어떻게 봤는지도 붙입니다. 예를 들어 브라우저에서 화면을 본 것과 실제 휴대폰에서 게임을 실행한 것은 같은 검증이 아닙니다. 다음 담당에게 확인 범위를 넘겨야 이미 한 일을 반복하거나, 안 한 일을 했다고 믿는 일이 줄어듭니다.
워크트리를 써도 홈페이지 글은 하나였다
Git 워크트리는 같은 저장소를 다른 작업 폴더에서 다루게 해 줍니다. 코드 변경을 분리할 때 유용하지만, 같은 계정으로 접속하는 워드프레스 글이나 배포 대상까지 복제해 주지는 않습니다.
작업을 옮기기 전에는 저장하지 않은 변경과 커밋 여부를 확인합니다. 새 폴더에 파일이 있다고 원래 작업의 모든 변경이 들어온 것으로 생각하지 않습니다. 실제 인계 대상 파일과 기준 커밋을 열어 대조한 뒤 이어가는 편이 안전합니다.
여러 채팅이 같은 공개 글을 수정할 수 있다면, 마지막 반영은 한 작업에만 맡깁니다. 검토는 병렬로 하더라도 공개본을 쓰는 순간에는 담당이 분명해야 합니다.
완료라는 답보다 결과물을 먼저 열었다
파일 경로가 왔다면 파일을 열고, 공개 URL이 왔다면 그 페이지를 열어 봅니다. 로그인한 관리자 화면에서만 보이는 글인지, 방문자도 읽을 수 있는 글인지도 구분합니다. 결과가 없거나 확인이 안 되는 항목은 완료 목록에서 빼고 그대로 남깁니다.
업무를 나눈 효과는 채팅 수로 확인하기 어려웠습니다. 같은 설명을 반복하는지, 이미 끝난 일을 다시 시키는지, 수정된 파일을 다시 찾느라 시간이 드는지를 보는 편이 더 현실적이었습니다. 인계서는 그 반복을 줄이기 위한 메모였습니다.
담당 규칙부터 필요하다면 공통 MD 파일 구성을, 두 도구 사이의 실행 연결이 필요하다면 Claude Code와 Codex 연결 과정을 이어서 볼 수 있습니다.
연습용 업무 분장·인계서·연결 점검표 받기 — MD 파일 9개를 묶었습니다. 빈 연습 폴더에 풀어 쓰는 양식이며, 실제 작업이 완료됐다는 기록은 아닙니다.