작업이 끊겨도 처음부터 다시 하지 않는 법 — 에이전트 인계와 재개의 구조

“기능은 거의 끝났고 테스트도 통과했어요. 남은 부분을 이어서 마무리해 주세요.”

처음에는 이 정도면 인계라고 생각했어요. 앞선 실행자가 많이 해뒀다는 사실도 전하고, 다음 실행자가 해야 할 방향도 얼핏 보였으니까요. 막상 작업을 다시 열면 질문이 한꺼번에 생겼어요. 어디까지가 실제 구현이고 어디부터가 계획인지, 테스트는 어느 시점의 소스에서 돌았는지, 무엇을 바꾸면 안 되는지, 첫 수정 뒤 어떤 검증을 다시 해야 하는지 알 수 없었어요.

긴 작업은 컨텍스트가 끝나거나 사람이 결정을 위해 자리를 비우면서 자연스럽게 끊겨요. 중단보다 비싼 것은 다음 실행자가 이전 작업을 다시 해석하는 일이었어요. 저희가 바꾼 것은 요약의 길이가 아니라, 인계를 읽은 뒤 고를 수 있는 첫 행동의 정확도였어요.

이전 인계는 진행률을 말했지만 기준점은 말하지 않았어요

실제로 남기던 인계의 골격을 공개 가능한 표현으로 줄이면 이랬어요.

이전: 기능은 대부분 구현됐고 전체 검증도 한 번 통과했어요. 남은 화면을 다듬고 테스트를 확인해 주세요.

짧고 긍정적이지만 재개에는 필요한 정보가 거의 없어요. “대부분”은 구현과 계획의 경계를 가리지 못하고, “한 번 통과”는 어떤 소스와 환경에서 얻은 결과인지 말하지 않아요. “화면을 다듬는다”는 말도 승인된 구조를 보존해야 하는지, 다시 설계해도 되는지 정하지 못해요.

이런 문장을 받은 실행자는 보통 두 가지 중 하나를 택했어요. 안전해 보이는 자료를 전부 다시 읽거나, 눈에 잘 띄는 화면부터 고쳤어요. 전자는 앞선 탐색 비용을 반복했고, 후자는 제품의 불변식을 건드릴 위험이 있었어요.

Called Up에서는 그 불변식이 결정론이었어요. 시뮬레이션을 수정할 때 새 임의성이 기존 난수 흐름을 밀어버리면 같은 시작 조건과 선택 기록으로 같은 커리어를 재현할 수 없어요. 화면상 변화가 작아도 과거 커리어 재현과 서버 저장 검증이 함께 흔들릴 수 있었어요. 그런데 “콜업 시스템을 이어서 개선해 주세요”라는 문장만으로는 이 변경 금지선을 알 수 없었어요.

Project Whisper에서는 시간축이 문제였어요. 초기 기획, 승인된 설계, 현재 코드, 릴리스 당시 검증 기록이 모두 남아 있었지만 같은 현재를 말하지 않았어요. 초기안보다 실제 구현이 앞선 부분도 있었고, 세부 설계는 있어도 아직 현재 기능으로 말하면 안 되는 부분도 있었어요. 자료를 많이 넘길수록 이 구분이 저절로 생기지는 않았어요.

바꾼 인계는 다음 행동이 아니라 다음 판단까지 제한했어요

같은 상황을 다음과 같이 바꿨어요.

이후: 이 인계는 현재 확인되는 구현을 기준으로 써요. Called Up의 다음 변경에서는 기존 난수 흐름과 서버 재실행 계약을 보존해야 해요. Project Whisper의 승인된 중심 배치는 다시 설계하지 않고, 바깥 영역의 표현부터 확인해요. 릴리스 당시 자동 검증과 패키지 기반 검증은 통과했지만 현재 환경에서는 같은 검증을 재실행하지 못했어요. 먼저 변경 대상과 연결된 검증을 현재 환경에서 실행할 수 있는지 확인하고, 불가능하면 과거 통과 기록을 현재 보증으로 바꾸지 않은 채 사람에게 확인해요.

길이는 조금 늘었지만 차이는 분명했어요. “거의 완료”라는 진행률 대신 현재 기준을 밝혔고, 제품별 변경 금지선을 남겼어요. 과거 검증과 현재 검증을 갈랐고, 바로 코드를 고치기 전에 확인할 첫 행동과 중단 조건을 정했어요.

여기서 Project Whisper의 검증 문장은 일부러 자세히 남겼어요. 마지막 릴리스 인계에는 자동 검증과 실제 패키지를 사용한 검증이 통과한 기록이 있었어요. 하지만 작업을 넘겨받은 현재 환경에는 같은 검증을 다시 실행할 도구가 없었어요. 따라서 “모든 테스트가 통과해요”라고 쓰면 안 됐어요. 정확한 상태는 릴리스 당시에는 통과했고, 현재 환경에서는 재실행하지 못했어요였어요.

이 차이는 표현상의 신중함이 아니에요. 다음 실행자가 과거 기록을 현재 코드의 보증으로 사용하지 못하게 막는 실행 조건이에요. 검증을 다시 돌릴 수 없다면 그 사실을 위험으로 남기고, 결과를 요구하는 변경 앞에서 멈춰야 해요.

Called Up의 사례는 같은 인계 구조가 왜 제품마다 다른 내용을 담아야 하는지도 보여줬어요. 시뮬레이션 변경이면 결정론과 서버 재실행을 함께 확인해야 하고, 문구 변경이면 지원하는 언어의 키와 금지 표현을 확인해야 해요. “테스트를 돌린다”가 아니라 어떤 변경이 어떤 검증을 다시 열어야 하는지를 남겨야 했어요.

Project Whisper의 화면과 아트도 마찬가지였어요. 자동 검증이 통과했다고 미감까지 승인된 것은 아니었어요. 반대로 이미 검수된 중심 구도를 다음 실행자가 선의로 다시 디자인해서도 안 됐어요. 인계에는 기계가 확인할 축과 사람의 승인이 필요한 축을 함께 남겨야 했어요.

재개 가능한 인계는 다섯 항목이면 충분했어요

인계를 길게 만드는 것보다 빠뜨리면 안 되는 칸을 고정하는 편이 효과적이었어요. 저희가 남긴 최소 단위는 작업 목적, 소스 기준점, 상태 분리, 검증 상태, 다음 안전 행동 다섯 가지예요.

작업 목적에는 무엇을 만들었는지보다 어떤 문제를 없애려는지 써요. 구현 방식이 바뀌어도 다음 판단의 기준이 남기 때문이에요.

소스 기준점에는 어느 시점의 코드와 문서, 결정을 보고 썼는지 남겨요. 실제 내부 인계에서는 같은 상태를 복원할 수 있어야 하지만, 공개 글에 내부 식별자나 경로를 옮길 필요는 없어요. 기준점 이후의 변경은 인계에 자동으로 포함되지 않는다는 사실도 함께 적어요.

상태 분리에서는 구현, 승인된 결정, 계획과 미완, 위험을 섞지 않아요. “할 예정이에요”와 “들어가 있어요”, “그때 확인했어요”와 “지금도 유효해요”를 한 문장에 넣지 않아요. 보존할 불변식과 사람 승인이 필요한 경계도 이곳에 붙여요.

검증 상태에는 명령 이름만 나열하지 않아요. 어떤 기준점과 환경에서 무엇을 실행했고 결과가 어땠는지, 실행하지 못한 검증은 무엇이며 왜 못 했는지 남겨요. 실패가 있다면 실패한 축과 우회하면 안 되는 조건을 숨기지 않아요.

마지막에는 할 일 목록 전체가 아니라 첫 행동 하나를 써요. 성공을 어떻게 확인할지와 어떤 조건에서 멈추고 질문할지도 함께 적어요. 첫 행동이 작고 검증 가능해야 재개가 추측이 아니라 실행이 돼요.

# 작업 인계

## 1. 작업 목적
- 해결하려는 문제:
- 완료 조건:

## 2. 소스 기준점
- 기준으로 확인한 코드·문서 시점:
- 이 기준점 이후 포함되지 않은 변경:

## 3. 상태 분리
- 현재 구현됨:
- 승인된 결정과 보존할 불변식:
- 계획·미완:
- 열린 위험과 사람 승인이 필요한 경계:

## 4. 검증 상태
- 실행한 검증과 결과:
- 실행 시점·환경:
- 실행하지 못한 검증과 이유:

## 5. 다음 안전 행동
- 첫 행동:
- 성공 확인 방법:
- 이 조건이면 멈추고 질문:

이 템플릿을 채운 뒤에는 새 실행자의 입장에서 읽어봐요. 지금 사실로 믿어도 되는 것, 과거 기록이라 다시 확인해야 하는 것, 가장 먼저 해도 안전한 행동이 각각 보이면 재개할 수 있어요. 하나라도 흐리면 아직 인계가 아니라 진행 상황 요약에 가까워요.

인계가 좋아진 뒤 달라진 것은 시작 속도보다 되돌림이었어요

다음 실행자는 긴 대화 전체를 같은 무게로 읽지 않게 됐어요. Called Up 작업에서는 화면보다 결정론을 먼저 변경 금지선으로 잡았고, 시뮬레이션을 건드릴 때 서버 재실행 검증까지 함께 열었어요. Project Whisper 작업에서는 초기 초안과 현재 코드를 갈라 읽고, 릴리스 당시 통과 기록을 현재 보증으로 복사하지 않았어요.

인계가 모든 판단을 대신한 것은 아니에요. Called Up의 선택 재미와 밸런스, Project Whisper의 발견감과 장소감은 자동 검증으로 승인할 수 없어요. 대신 인계는 기계가 확신해도 되는 범위를 제한하고, 사람 판단이 필요한 곳에서 멈추게 해요. 결정론이나 저장 진행처럼 반복 확인할 수 있는 것은 사람의 기억에 맡기지 않고요.

에이전트가 바뀌어도 작업이 이어지는 이유는 새 에이전트가 이전 에이전트처럼 생각해서가 아니었어요. 같은 기준점에서 시작하고, 보존할 불변식을 알고, 변경에 맞는 검증을 다시 통과하기 때문이었어요.

이제 작업 한 구간의 끝은 “결과를 냈어요”만으로 정하지 않아요. 다음 실행자가 과거를 재해석하지 않고 첫 행동을 안전하게 고를 수 있을 때 끝났다고 봐요. 좋은 인계는 지난 일을 잘 요약한 문서가 아니라, 다음 행동의 위험을 줄인 작업 상태예요.