두 예약이 모두 성공했다고 병렬 실행까지 증명되는 것은 아니다. 앞의 작업이 끝난 뒤 다음이 시작돼도 결과 목록은 둘 다 성공일 수 있다. 예약 대상 보존과 중지의 구조는 별도 글에서 다뤘다. 이번에는 실제로 겹쳐 실행됐다는 주장을 어떤 시험 조건으로 뒷받침했는지 풀어 본다.
같은 절차에 서로 다른 입력을 준다
시험은 하나의 입력·대기·추출 Recipe를 만든 뒤 같은 카탈로그 ID를 다른 프로젝트에도 등록한다. A와 B에는 서로 다른 값과 시작 주소를 준다. 코드를 두 번 만들어 우연히 다른 프로그램을 비교하는 대신 같은 정의가 다른 문맥에서 어떻게 실행되는지 본다.
웹페이지는 소유 HTML 응답으로 대체하고 입력 뒤 완료가 늦게 나타나게 한다. 실제 실행기는 Python 플러그인이지만 외부 서비스의 예약 서버를 시험하는 것은 아니다. 정의 재사용과 프로젝트별 입력 전달을 고정된 조건에서 관찰하기 위한 설계다. 시험 입력에 실제 고객 원고나 로그인 값을 넣을 필요도 없다.
둘 다 running인 순간을 실제로 관찰한다
두 예약에는 같은 at 값을 주고 두 프로젝트 목록을 함께 조회한다. 반복 조회 중 양쪽 상태가 동시에 running인 경우에만 simultaneous를 True로 남긴다. 마지막에 succeeded 두 개를 보는 것 외에 이 값이 실제로 켜졌는지도 assert한다.
이 검사는 물리적인 CPU 명령이 정확히 같은 순간 실행됐다는 뜻은 아니다. 두 업무의 실행 구간이 겹쳤다는 관찰이다. 대기 시간을 둔 이유도 짧은 실행이 조회 사이에 끝나 겹침을 놓치는 일을 줄이기 위해서다. 스케줄러가 항상 정확한 시각에 시작한다는 보장이나 모든 부하에서 동일하다는 성능 지표로 바꾸지 않았다.
성공 뒤에도 탭과 실행 번호를 대조한다
완료하면 두 runId가 다른지 확인하고 각 실행 결과의 tabs가 해당 프로젝트의 원래 탭만 가리키는지 비교한다. A의 결과에 B의 탭이 들어가도 단순 성공 표시는 나올 수 있으므로 대상 관계를 별도로 읽는다. 입력값을 나눈 이유도 결과가 뒤섞였는지 찾기 위해서다.
각 작업의 내부 모델 호출도0인지 확인한다. 이것은 기존 절차를 Python으로 돌린 경로의 근거다. 외부 Codex 대화의 사용량이나 시험 전체의 비용을0으로 만드는 수치는 아니다. 같은 프로그램 정의를 사용해도 실행 번호와 결과 문맥은 별개로 남아야 한다는 조건을 시험에서 다시 확인했다.
사용자가 보고 있는 프로젝트도 바뀌지 않아야 한다
시험은 B를 보고 있는 상태에서 A의 MCP 문맥을 읽고 실행한다. 그 뒤에도 선택된 workspace가B인지 확인한다. 백그라운드 작업이 성공했지만 사용자의 화면을 다른 곳으로 이동시켰다면 독립 작업실의 경험은 깨진다.
이 점은 코드의 projectHost 커서와 interactive 조건에 연결된다. task의 선택과 보이는 창의 선택을 구별하므로 실행 대상 이동이 곧 사용자 포커스 이동이 되지 않는다. 결과 데이터만 검사하는 시험에 보이는 상태의 보존을 더한 이유다. 실제 탭과 커널을 쓰는 시험이어도 사용자의 원래 작업 화면은 별도 소유 프로필 밖에서 보존한다.
두 번의 결과는 환경의 차이까지 남긴다
소스판과 설치판 기록에는 각각15개 확인이 있고 같은 시각 예약의 겹침과 대상 보존이 포함된다. 보고서의 전체 경과 시간은 여러 준비와 복사·UI 검사를 포함하므로 예약 두 개만의 실행 시간으로 읽지 않는다. 같은 이름의 숫자도 어떤 구간을 측정했는지 봐야 한다.
이번 집필은 그 코드와 저장된 결과를 대조했으며 새 예약을 만들지 않았다. 앱이 켜진 동안의 로컬 예약이라는 조건과 종료·절전 중 실행 미지원도 유지한다. 내가 공유하려는 시험의 핵심은 병렬이라는 말을 결과 수로 대신하지 않고 겹침·소유권·화면 보존의 서로 다른 조건으로 나눠 확인한 방식이다. 겹침을 관찰하지 못했다면 두 결과가 성공했어도 해당 주장은 보류해야 한다. 시간 제한과 조회 간격을 바꾼 후속 시험도 원래 결과와 별도 기록으로 남겨야 비교가 가능하다.