두 일꾼이 같은 일을 동시에 잡을 때 — 진행 중 충돌을 미리 막은 이야기

팀에서 같은 일을 두 사람이 동시에 맡으면 어떻게 될까. 각자 열심히 하고, 각자 완성하고, 나중에야 “아 너도 하고 있었어?”가 된다. 다섯 대의 기기를 함대처럼 묶어 일을 분배하다 보면 똑같은 일이 기계 사이에서도 일어난다. 이 글은 그 충돌을 사후가 아니라 진행 중에 잡아낸 하루의 기록이다.

나는 다섯 대의 컴퓨터를 묶어서 일을 시킨다. 각각의 기기가 할 일 목록에서 일을 집어, 제 방식대로 처리하고, 결과를 “검토해 주세요”라는 제안서 형태로 올린다. 나는 그 제안서를 보고 본문서에 합칠지 말지를 판단한다.

대부분의 경우엔 잘 돌아간다. 그런데 가끔 아찔한 순간이 생긴다. 두 대가 같은 일을 동시에 집어 각자 제안서를 올리는 것이다. 이번에 그게 실제로 일어났다. 번호로 치면 31번과 32번 일감을 두 기기가 서로 모르게 병렬로 진행하다가, 제안서를 각각 셋이나 열어 버린 날이었다.

결과가 나온 뒤에야 아는 것

이전까지는 이런 충돌을 “결과”를 보고 나서야 알았다. 두 대가 각자 제안서를 올리고 나면, 나 또는 관리 기기가 “어, 이거 두 개네” 하고 처음으로 인지하는 것이다.

물론 한쪽을 닫으면 그만이다. 그렇게 나쁘지 않다. 그런데 이미 다 만든 제안서를 닫는다는 건, 한 대가 쏟은 시간과 연산이 통째로 날아간다는 뜻이다. 한 번이야 괜찮지만, 다섯 대가 하루 종일 돌아가는 환경에서 이게 반복되면 낭비가 쌓인다. 더 나쁜 경우도 있다. 두 제안서가 같은 파일을 서로 다른 방향으로 바꿔 놓아, 어느 쪽을 합쳐도 한쪽이 망가지는 상황이 생길 수 있다.

증거를 먼저 보는 게이트

그래서 이번에 만든 건 일을 집기 직전에 “이미 누군가 이 일을 잡고 있나?”를 1회 확인하는 관문이다.

원리는 단순하다. 기기가 어떤 일감을 막 집으려는 순간, git과 제안서 목록을 실제로 들여다본다. “지금 이 일과 관련된 제안서가 열려 있지는 않은가?” 이 질문 하나를 던지고, 열려 있으면 집지 않는다.

중요한 건 추측을 안 한다는 점이다. 기억에 저장된 상태 정보나 기기끼리의 대화가 아니라, 그 순간의 git 기록과 제안서 목록을 직접 읽는다. 이유가 있다. 상태 정보는 오래되면 낡는다. 낡은 정보를 보고 “지금 아무도 안 잡고 있다”고 판단하면, 정작 실제로는 잡혀 있는 일을 또 집는 사고가 생긴다. 그 확인 도구 자신이 낡아서 또 다른 충돌을 만드는 역설이다. 그래서 매번 원본을 직접 읽게 했다.

충돌을 진행 중에 잡는다는 것

기존에는 충돌을 잡는 방법이 두 가지였다. 하나는 사람이 보고 나서 닫는 것, 다른 하나는 결과를 합칠 때 충돌을 발견하고 되돌리는 것. 둘 다 일이 끝난 뒤다.

이번에 추가한 건 세 번째 시점 — 집기 직전이다. 두 대가 각자 완성해서 제안서를 올리기 전에, 한 대가 이미 제안서를 열었다는 사실을 나머지가 알아차리는 것이다. 이 한 발 앞선 감지 덕에, 중복 작업이 시작조차 안 된다.

실제로 같은 날 이 감지를 거슬러 올라가 기존 제안서들을 검사했더니, 15개 중 진짜 충돌은 2건뿐이었다. 나머지 13건은 여러 단계로 나뉜 일의 정상적인 흐름이었다. 이건 그냥 숫자가 아니다. 게이트가 충돌을 막으면서도 정상 작업을 지나치게 막지 않는다는 뜻이다. 지나치게 좁은 문은 일 자체를 막는다.

같은 파일을 동시에 손댈 때

비슷한 문제가 파일 단위에서도 있었다. 기기 여러 대가 같은 관리 파일에 상태를 기록하는데, 동시에 쓰면 한쪽이 다른 쪽 내용을 덮어 써 버린다. 먼저 쓴 쪽 기록이 사라지는 것이다.

이건 잠금 구조로 해결했다. 기기가 파일에 쓰기 직전에 잠금을 걸고, 쓰고 나면 잠금을 해제한다. 다른 기기는 잠금이 풀릴 때까지 기다린다. 이제 두 기기가 같은 줄을 동시에 덮어쓰는 일은 물리적으로 일어나지 않는다.

제안서 감지와 파일 잠금, 방향이 달라 보이지만 뿌리는 같다. 하나의 자원을 여러 주체가 동시에 다룰 때, 순서를 강제하는 것. 먼저 집은 사람이 끝내야 다음 사람이 집는다. 협업에서 가장 오래된 규칙 중 하나다.

팀에서도 같은 일이 일어난다

이건 기계만의 문제가 아니다. 사람 팀에서도 “그거 나도 하고 있었는데”는 흔한 장면이다. 회의록 한 줄로 담당자를 정했는데 두 사람이 각자 처리하고, 나중에야 서로 알아차리는 것. 혹은 같은 문서를 동시에 열어서 한쪽 편집이 날아가는 것.

그 고전적인 사고를 막는 법도 원리는 같다. 시작하기 전에 “이미 누가 하고 있나?”를 한 번 확인하는 것. 직접 물어보거나, 할 일 목록에 이름을 적거나, 문서 잠금 기능을 쓰거나 — 수단은 다르지만, 집기 직전에 상태를 확인한다는 행동은 동일하다.

이번에 기계로 만든 건 그 확인을 자동화한 것뿐이다. 사람 팀에서 회의 시작 전에 “이 일 담당 정해졌어요?”를 묻는 것과 다르지 않다.

진짜 낭비는 조용한 중복이다

눈에 보이는 낭비는 고치기 쉽다. 두 사람이 같은 일을 다 끝내고 나서 “우리 둘 다 했네”를 아는 순간, 그 낭비는 이미 드러나 있으니까. 닫으면 된다.

더 무서운 건 조용한 중복이다. 한쪽이 고치고, 다른 쪽도 고치고, 합칠 때 충돌이 나거나 — 혹은 충돌을 모른 채 한쪽 변경이 덮어씌워지는 것. 아무도 낭비를 인지하지 못한 채 결과물만 어긋나 있는 상태다. 이걸 나중에 발견하면 원인을 추적하는 데 시간이 두 배로 든다.

그래서 감지를 “끝난 뒤”가 아니라 “집기 직전”으로 당긴 것이다. 낭비가 일어나기 전에 자르는 게, 낭비가 일어나고 나서 처리하는 것보다 항상 싸다.

여럿이 일을 나눌 때, 가장 중요한 순간은 일을 끝낸 뒤가 아니라 시작하기 직전이다. 집기 전에 한 번 — “이미 누가 잡고 있나?”

— 강대종