work-pool 7인 패턴이 깨지지 않는 조건

큰 작업은 7 명의 에이전트로 나눠서 돌립니다.

kmbti·saju 규모 이상의 도구를 만들거나 119 개 사이트를 한 번에 손볼 때, 한 명의 에이전트로 처리하면 컨텍스트가 너무 길어져서 후반의 정확도가 떨어집니다. 그래서 7 인 패턴을 박아두고 있습니다. 5 명이 work, 1 명이 review, 1 명이 lead 역할입니다.

구조 자체는 단순합니다.

깨지는 조건이 따로 있어서 그 조건을 매번 확인하지 않으면 7 명이 5 명보다 느려집니다. 7 명을 띄웠는데 5 명이 같은 파일을 동시에 건드리면, 마지막에 합치는 단계에서 충돌이 쌓입니다. 7 인 패턴의 효율은 분담의 정확도에 거의 전부 걸립니다.

분담을 정확히 하려면 세 가지를 미리 정해둡니다.

첫째, 파일 경로를 5 명에게 겹치지 않게 나눠줍니다. work 1 은 src/components 아래, work 2 는 src/pages 아래, work 3 은 infra 디렉토리, 이런 식입니다. 두 명이 같은 디렉토리에 들어가면 거의 항상 같은 파일을 만지게 됩니다.

둘째, 컨텍스트를 5 명이 공유하지 않게 합니다. work 1 이 알아야 할 정보와 work 2 가 알아야 할 정보를 분리해서 각자에게 따로 전달합니다. 5 명에게 같은 250 줄의 컨텍스트를 한꺼번에 던지면, 에이전트가 자기 영역 밖의 파일도 건드리기 시작합니다. 자기 영역만 알고 있어야 자기 영역만 만집니다.

셋째, sequential dependency 가 없도록 자릅니다. work 2 가 work 1 의 결과를 기다려야 한다면 7 인 패턴이 작동하지 않습니다. 5 명이 동시에 출발해서 동시에 끝나야 시간이 단축됩니다. dependency 가 있는 작업은 순차 흐름으로 빼두고, 7 인 패턴에는 독립적인 작업만 넣습니다.

이 세 조건 중 하나라도 깨지면 7 인 패턴은 단일 흐름보다 느려집니다.

review 와 lead 의 역할도 적어둡니다. review 는 5 명의 work 가 끝난 뒤에 합쳐진 결과를 한 번 봅니다. 5 명이 각자 잘 했어도 합쳐졌을 때 컴포넌트 명명이 사람마다 다르거나, 같은 helper 함수가 다섯 곳에 따로 적힌 경우가 있습니다. review 가 그 일관성을 정리합니다.

lead 는 5 명에게 작업을 분배하기 전에 분담 자체를 설계합니다. 어떤 파일을 누가 만질지, 컨텍스트를 어떻게 자를지, dependency 가 어디 숨어 있는지를 먼저 정리합니다. 이 단계가 부실하면 5 명이 출발한 뒤에 충돌이 따라옵니다. lead 의 짧은 작업 시간이 7 인 패턴의 효율 대부분을 결정합니다.

이 구조를 박아두고 한 해를 굴려보면서 알게 된 게 있습니다.

7 인 패턴이 가장 잘 작동하는 작업은 사이트 119 개를 동시에 손보는 종류입니다. 사이트마다 독립적이라서 dependency 가 없고, 파일 경로가 사이트별로 깔끔히 갈리고, 컨텍스트도 사이트 단위로 분리됩니다.

반대로 잘 안 맞는 작업은 한 사이트의 깊이 있는 개선입니다. 컴포넌트들이 서로 참조하고 있어서 dependency 가 따라오고, 컨텍스트가 사이트 전체에 걸쳐 있어서 잘라내기 어렵습니다. 이런 작업은 1 명의 에이전트로 길게 가는 쪽이 결과가 정확합니다.

작업의 구조가 7 인에 맞는지 한 명 깊이에 맞는지를 먼저 확인하고, 그 다음에 7 인 패턴을 띄울지 결정합니다. 이 확인을 건너뛰면 7 명을 띄우고 5 명만큼 일하는 결과가 자주 나옵니다.