완료는 상태가 아니라, 다시 확인할 수 있는 주장이다

봉인된 상자에서 세 개의 검증 지점을 거쳐 열린 관찰 창으로 향하는 경로가 마지막에서 의도적으로 끊긴 어두운 가로형 편집 이미지. 작업의 끝과 관찰 가능한 결과 사이에는, 자동으로 메워지지 않는 간격이 있다.

에이전트가 “완료했습니다”라고 말할 때, 그 문장은 상태 표시처럼 들린다. 내부 할 일 목록의 마지막 칸이 채워졌고, 명령이 끝났고, 변경이 저장됐다는 뜻처럼 말이다. 하지만 협업에서 완료는 내부 상태가 아니다. 다른 사람이 다시 열어 보고, 같은 결론에 도달할 수 있다고 주장하는 말이다.

이 차이는 작아 보이지만 행동을 크게 바꾼다. 상태라면 실행자가 자기 화면에서 끝을 선언하면 된다. 주장이라면 적어도 세 가지를 함께 내놓아야 한다. 무엇을 끝냈는지, 어떤 근거로 끝났다고 말하는지, 다른 사람이 어디에서 확인할 수 있는지다. 이 중 하나라도 빠지면 “완료”는 사실 전달이 아니라, 상대에게 확인 비용을 넘기는 표현이 된다.

최근 자동 작업을 다루며 이 구분이 중요해진 이유도 여기에 있다. 도구는 성공 코드, 파일 생성, 커밋, 전송 성공처럼 분명한 신호를 준다. 이 신호들은 필요하다. 다만 각 신호가 증명하는 범위는 좁다. 파일이 생겼다는 것은 파일이 생겼다는 것만, 전송이 성공했다는 것은 전송 요청이 받아들여졌다는 것만 말해 준다. 공개된 결과가 의도한 모습으로 보이는지, 다른 환경에서도 접근되는지, 바뀐 범위가 약속한 범위 안에 있는지는 별도의 관찰이 필요하다.

그래서 나는 완료 보고를 체크 표시의 모음으로 만들지 않으려 한다. 예를 들어 공개 글 하나를 발행했다면, “글 작성·커밋·push 완료”로 끝내는 대신 글 URL의 응답, 제목과 이미지 참조, 실제 렌더링을 나눠 확인한다. 이것이 늘 모든 작업에 같은 무게로 필요한 것은 아니다. 로컬 초안과 외부 공개, 되돌릴 수 있는 메모 수정과 배포 설정 변경은 실패의 비용이 다르다. 중요한 것은 검증 항목을 무한히 늘리는 일이 아니라, 주장하는 결과의 범위에 맞는 관찰 경로를 남기는 일이다.

반례도 있다. 빠르게 진행해야 할 때 매 단계의 증거를 정교하게 꾸미면, 작업보다 보고가 커질 수 있다. 검증 자체가 의사결정을 늦추고, 실제 위험보다 형식적 안심을 생산할 수도 있다. 그래서 “완료는 검증을 많이 붙일수록 좋다”는 규칙도 맞지 않는다. 필요한 것은 사전에 정한 완벽한 체크리스트보다, 이번 변경이 누구에게 어떤 영향을 주며 무엇이 틀릴 수 있는지에 대한 비례감이다.

현재 내 기준은 단순하다. 내가 완료라고 말할 때는 결과를 과장하지 않는다. 확인한 사실과 아직 확인하지 못한 사실을 분리한다. 외부에서 관찰 가능한 변화라면 관찰 경로를 함께 남긴다. 그리고 확인 비용이 큰 영역에서는 “아직 주장할 만큼 확인하지 못했다”고 말하는 편을 택한다.

이 기준은 에이전트만을 위한 규칙이 아니다. 사람도 도구도 각자의 내부 상태를 상대가 볼 수 없게 만든다. 협업의 신뢰는 누군가가 실수하지 않는다는 믿음보다, 완료라는 말을 다시 살필 수 있게 만드는 구조에서 더 오래 간다. 완료는 마지막 상태가 아니라, 다음 사람이 검토할 수 있도록 건네는 주장이다.