AI 둘에게 나눠 맡기면 전체 시간이 줄까? 측정하지 못한 이유와 비교 전 확인할 것들

준비하고 합치고 다시 고치는 시간까지 넣으면, AI 두 세션에 나눠 맡길 가치가 있을까? 이를 비교하려고 작은 목록 앱을 준비했지만 실제 AI 작업자를 투입한 측정 실행은 한 번도 하지 않았다(NOT RUN). AI 세션을 실제로 실행할 방식에서 작업본 접근 제한, 사용량과 중단 통제, 실제 브라우저 검증을 확보하지 못해 비교 전에 멈췄다. 이 글은 속도에 대한 답 대신, 그 답을 얻으려면 무엇을 확인해야 하는지와 오프라인 준비에서 확인한 한계를 다룬다.

완료의 기준부터 함께 적는다

준비한 과제는 여섯 행짜리 목록에 검색·분류 필터와 CSV 내보내기를 붙이는 일이었다. CSV는 표 데이터를 텍스트 파일로 저장하는 형식이다. 두 기능의 공통 약속은 화면에 보이는 행만, 같은 순서로 내보내는 것이다. 검색 결과가 없으면 CSV에는 머리글만 남고, 조건을 지우면 전체 목록이 돌아와야 한다.

전체 검사 요구는 이 요약보다 넓었다. 검색어 앞뒤 공백을 지우고 대소문자와 관계없이 항목 이름의 어느 위치에서든 찾으며, 분류는 정확히 일치해야 하고 두 조건을 모두 만족해야 했다. 값 0·한글·따옴표·줄바꿈의 보존, CSV의 줄 끝 형식(CRLF)과 문자 저장 방식(BOM 없는 UTF-8), 입력·검사 파일 보존, 실제 다운로드와 콘솔 오류 확인도 포함했다.

여기에 구조상의 요구도 두었다. 화면과 내보내기가 ‘보이는 행을 고르는 함수’를 함께 쓰도록 했다. 같은 내용의 규칙표 두 장을 따로 베끼는 것과, 규칙표 한 장을 함께 참조하는 것은 다르다. 예시 몇 개의 출력이 같아도 같은 함수를 쓴다는 증거는 아니다. 동작 검사와 코드 구조 확인을 구분해야 한다.

이 공통 약속이 중요한 이유는 작업 폴더를 나눠도 나중에 합칠 지점이 남기 때문이다. 이번 설계에서는 두 역할 모두 같은 app.js 파일을 고칠 수 있었고, 화면과 내보내기가 같은 행 선택 함수를 써야 했다. Git의 worktree는 한 저장소에 여러 작업 디렉터리를 두는 기능이며, 일부 저장소 정보는 공유한다. Git 공식 문서 따라서 이 설계에서는 폴더를 나눴다는 사실만으로 다른 작업본에 대한 접근까지 막았다고 보지 않았다.

파일이 충돌 없이 합쳐져도 기능은 어긋날 수 있다. 텍스트 충돌과 합친 뒤의 빌드·검사 실패를 구분한 연구도 있다. 다만 사람의 소프트웨어 협업을 다룬 연구이므로, 여기서 AI의 오류 빈도나 소요 시간을 가져올 수는 없다. Brun 등의 2011년 연구

비교하려던 방법: 같은 검사를 통과할 때까지

설계에서는 한 세션이 필터 다음 내보내기를 만드는 조건과, 별도 복사본에서 두 세션이 각각 만드는 조건을 비교하려 했다. 장비 목록과 독서 목록 두 벌을 준비하고, 첫 목록은 순차→병렬, 둘째는 병렬→순차 순서를 정했다. 목록 두 벌에 순차·병렬을 각각 적용하는 네 조건 모두 미실행이다.

완료는 작업자의 “끝났다”는 답변이 아니라 같은 검사 전체의 통과로 정했다. 검색·초기화, 화면과 파일의 일치, 실제 다운로드, 기존 동작 보존까지 포함한다. 통과 전에 한도에 닿으면 완료 시간이 아니라 중단까지의 시간과 미해결 검사를 기록하고, 네 조건의 실패·미실행도 모두 남기기로 했다. 조건당 최대 30분 안에서 수정은 회당 재검사를 포함해 최대 3분, 두 차례로 제한하며, 좋은 결과를 얻기 위한 대체 실행은 하지 않기로 했다.

총 경과 시간에는 조건별 준비, 대기, 합치기, 검사, 수정과 재검사를 넣기로 했다. 공통 데이터와 검사 도구를 만드는 준비 시간은 별도로 공개한다. 총 경과 시간, 작업 구간의 실제 경과 시간, 각 작업자의 시간을 더한 값은 구분한다. 총 경과 시간에는 작업 밖의 준비·통합·검사도 들어간다. 병렬 작업의 시간 합에는 겹친 구간이 중복되므로, 그 합만으로 실제 겹침을 판단할 수 없다. 두 결과를 합칠 조정자, 즉 이번 설계의 AI 도구 Codex가 한 일도 사람의 수동 개입 시간과 구분하기로 했다.

시간이 짧아져도 사용량은 늘 수 있다는 가능성을 고려했다. 그래서 확인 가능한 사용량은 단위와 확인 범위를 붙여 시간과 별도로 기록하고, 보이지 않는 사용량은 ‘미노출·미확인’으로 남기기로 했다. 측정된 증가량이나 배수를 뜻하지 않는다.

두 창이 열렸다는 사실만으로 병렬 작업을 인정하지 않기로 했다. 두 세션의 작업 구간이 겹치고, 그 구간 안에서 양쪽의 실질적인 진행 기록이 있어야 한다는 기준을 설계했다. 이것도 서버 내부에서 동시에 계산했다는 증명은 아니다. 기록 지연이나 대기 때문에 유효한 겹침을 확인할 수 없으면 병렬 비교는 미실행으로 남기되, 이미 시작한 작업은 중단까지의 시간·사용량과 함께 보존하기로 했다. 겹침을 만들려고 인위적으로 기다리게 하지 않는다.

순차 세션은 앞 작업의 맥락을 이어받고, 병렬 세션은 서로의 기록과 결과를 보지 않은 채 별도로 시작하도록 설계했다. 다만 두 세션 모두 전체 동작 요구사항을 받는다. 조건 순서를 뒤집어도 순차 작업과 통합에서 필터 다음 내보내기라는 순서는 고정했다. 순서 반전은 맥락 차이, 조정자가 앞 실행에서 요령을 익히는 효과, 서버 부하, 캐시와 데이터셋 영향을 없애지 않는다. 통합을 맡은 조정자의 숙련도도 초보자가 같은 절차를 옮겨 쓸 때의 한계다.

오프라인 준비에서 드러난 검사 도구의 빈틈

실제로 만든 것은 합성 데이터 두 벌, 정답 예시와 기준 구현, 작업 지시문, 검사·기록 도구였다. 2026년 10월 13일 초기 도구의 자체 테스트 19개는 통과했다. 그러나 별도 검토 단계에서 기준 구현의 별도 복사본마다 오류 한 종류씩, 데이터셋당 여덟 종류를 심자 각각 네 종류만 걸러냈다. 골라 심은 오류의 결과이지 일반적인 오류 검출률이나 AI 실패율은 아니다.

예를 들어 ‘항목 이름 중간에 있어도 찾기’를 ‘맨 앞에 있을 때만 찾기’로 바꿔도 통과했다. 준비한 검색 예시가 둘을 구별하지 못했기 때문이다. 전달받은 행 대신 고정된 여섯 행을 쓰는 코드도 빠져나갔다. 통과해 버린 네 종류는 접두사만 찾기, 전역의 고정 행 사용, 코드에 박아 둔 고정 행 사용, 초기화 때 입력 조건을 지우지 않기였다. 반면 내보낼 행을 잘못 고르기, 함수의 입력 형식 바꾸기, 행 순서 뒤집기, 값 0 누락은 거부됐다. 검사 자체의 테스트가 통과했다는 기록만으로, 잘못된 앱을 충분히 가려낸다고 판단할 수는 없었다.

수정 후 10월 18일 독립 검토에서 검사 도구는 보존된 오류 사례 16개, 즉 여덟 종류를 두 데이터셋에 적용한 사례를 모두 거부했다. 이것만으로 모든 중복 구현을 가려냈다는 뜻은 아니다. 별도 오프라인 테스트에서는 예시 출력이 같은 복제 필터도 거부했지만, 전체 코드 구조 확인과 실제 브라우저 검증은 여전히 필요했다. 기준 구현과 오프라인 준비 중 내보낸 A 데이터셋용 제출본도 해당 오프라인 검사를 통과했다. 이 제출본은 측정용 AI 작업자의 결과가 아니며, 통과는 실제 브라우저까지의 전체 검증을 뜻하지 않는다.

독립 검토는 합성 입력으로 중단 상태를 유지하는 로직도 제한된 범위에서 확인했다. 이후 구현자는 제출 파일의 원본 일치, 기록 보존과 합성 감시 로직을 다시 검사했지만, 그 추가 작업의 독립 검토는 남아 있었다. 이 검사는 서비스 쪽 작업이 멈췄거나 실행한 보조 프로그램까지 완전히 정리됐다는 증거가 아니다. 만들어 둔 코드와 합성 입력의 검사이며, AI 앱의 성공률이나 실제 두 세션의 동시 작업 결과가 아니다. 브라우저를 흉내 낸 오프라인 검사가 통과하더라도 실제 입력 조작과 다운로드까지 검증한 것은 아니다.

준비를 더 했는데도 멈춘 이유

10월 18일 기록의 알려진 준비 시간은 기존 약 16분과 후속 60분 준비 한도에서 쓴 47.99분을 합친 약 64분이다. 마지막 작업의 284초도 이 합계에 포함된다. 후속 준비 한도의 잔여는 미기록 조정·실행 컴퓨터 작업 시간을 빼기 전 약 12.01분이었다. 별도로 기록되지 않은 그 시간과 준비 과정의 서비스 사용량은 미확인이었다. 약 64분은 조건별 완료 시간이 아니며, 누구에게나 필요한 준비 시간도 아니다.

남은 문제는 검사 예시를 몇 개 더 넣는 수준이 아니었다. AI를 실제로 실행할 방식에서 다음을 충분히 확인하지 못했다.

• AI가 다른 작업본과 비공개 정답 자료를 들여다보지 못하게 막았는가?
• 실행 중 사용량을 확인해 한도 전에 멈추고, 중단 요청 뒤 서비스 쪽 작업도 끝났음을 확인할 수 있는가?
• 각 진행 기록이 어느 세션의 것인지 연결해 두 작업의 실제 겹침을 확인할 수 있는가?
• 실제 브라우저의 다운로드·오류·예상 밖 네트워크 요청을 검사하고, 실행 중 띄운 보조 프로그램(하위 프로세스)까지 정리할 수 있는가?

당시 준비 기록은 남은 준비 시간 한도 안에서 이 공백을 닫고 측정까지 마칠 근거 있는 계획이 없다고 판단했다. 필요한 최소 시간을 증명한 결과는 아니다. 10월 25일에는 방법을 설명하는 글로 전환했다. 이는 이 비교 설계의 준비 한계다. 특정 제품이 병렬 작업을 지원하지 않는다거나, 나눠 맡기면 손해라는 결론은 아니다. 측정값은 ‘0분’이 아니라 없음이다.

자신의 작업에 옮겨 적을 질문

다음은 같은 모델의 세션과 같은 앱 구조의 데이터 두 벌을 쓰려던 미실행 설계에서 정리한 질문이다. 효과나 다른 작업에의 적용 가능성을 검증한 절차도, 실행 결과표도 아니다.

나눠 맡길 가치가 있었는지는 여전히 답하지 못했다. 이 사례에서 제안하는 출발점은 완료 기준과 함께 실제 실행 방식의 접근 제한·사용량·중단·브라우저 관측을 확인하는 것이다. 그 공백을 닫아도 시작할 수 있는 것은 이 작은 설계뿐이다. 실행했다 해도 경과 시간뿐 아니라 사용량과 실패를 함께 봐야 하며, 다른 작업의 손익까지 답할 수는 없다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조했으며, 작성자가 최종 원고를 검토하고 수정 방향을 결정했습니다.