oh-my-codex의 병렬 워커는 독립적인 코드 영역을 나눌 때 시간을 줄일 수 있습니다. 그러나 같은 인터페이스를 여러 워커가 건드리면 worktree가 있어도 병합과 검증은 자동으로 안전해지지 않습니다. 먼저 변경 의존성과 권한 경계를 나누고, 생성 속도가 아니라 통합까지 걸린 시간과 재작업으로 효과를 판단해야 합니다.
oh-my-codex는 원문 기준 Codex 실행 위에 tmux 워커, Git worktree, 역할별 에이전트와 프로젝트 상태를 얹는 오케스트레이션 레이어입니다. 명령 이름과 내부 훅, 역할 수는 저장소 버전에 따라 바뀔 수 있으므로 아래 내용은 원문 시점의 구조를 판단하는 글입니다.
각 워커가 별도 worktree에서 작업하면 동시에 같은 파일을 덮어쓰는 문제를 피할 수 있습니다. 그러나 두 브랜치가 공통 타입, 데이터베이스 스키마나 잠금 파일을 서로 다르게 바꾸면 병합할 때 충돌하거나 더 위험하게는 텍스트 충돌 없이 의미가 어긋날 수 있습니다.
병렬화 전에 의존성 그래프를 보고 파일과 공개 인터페이스가 겹치지 않는 수직 작업으로 나눠야 합니다. 공통 계약 변경은 먼저 한 워커가 끝내고 병합한 뒤 나머지가 그 커밋을 기준으로 시작하는 편이 낫습니다. 각 작업에는 수정 허용 경로와 통과할 테스트를 명시합니다.
원문은 .omx 아래의 프로젝트 메모리와 작업 노트를 다음 문맥에 다시 주입하는 구조를 설명합니다. 긴 대화 전체를 유지하지 않아도 결정과 진행 상황을 이어 갈 수 있지만, 메모리가 실제 Git 상태보다 오래되면 새 워커가 이미 폐기된 설계를 따를 수 있습니다.
메모리 항목마다 근거 커밋과 갱신 시각을 남기고, 확정 결정과 임시 관찰을 분리해야 합니다. 병합 뒤에는 상태 파일도 단일 작성자가 정리하도록 합니다. 소스 코드, 테스트와 메모리가 충돌할 때 어느 것이 진실의 원천인지도 팀 규칙으로 정해야 합니다.
ralph나 tdd처럼 실패를 보고 다시 수정하는 루프는 단순 오류를 자율적으로 고칠 수 있습니다. ‘포기하지 않는다’는 표현을 운영 원칙으로 삼으면 같은 오류를 반복하며 코드와 비용만 키울 수 있습니다. 최대 시도, 시간, 토큰과 diff 크기를 제한하고 같은 실패가 연속되면 중단해야 합니다.
에이전트가 테스트를 삭제하거나 기대값을 낮춰 통과시키지 못하게 테스트 변경은 별도 검토 대상으로 둡니다. 외부 서비스, 데이터 마이그레이션과 배포는 루프 밖에서 사람 승인을 받아야 합니다. worktree는 파일 공간을 분리할 뿐 자격 증명과 네트워크 권한을 격리하지 않습니다.
작업 카드에는 목표만 쓰지 말고 시작 기준 커밋, 입력으로 삼을 계약 버전, 수정하지 말아야 할 경로와 산출물의 소비자를 기록합니다. API 응답 타입과 이를 쓰는 UI를 두 워커에게 동시에 맡기면 각 브랜치의 테스트는 통과해도 합친 뒤 필드 의미가 달라질 수 있습니다. 이 경우 계약 변경을 먼저 병합하고 생성된 타입이나 고정 fixture를 나머지 작업의 입력으로 배포하는 편이 안전합니다.
텍스트 충돌이 없다는 사실도 성공 신호가 아닙니다. 한 워커가 기본값을 바꾸고 다른 워커가 그 값을 전제로 캐시 키를 만들면 Git은 자동 병합하지만 동작은 깨질 수 있습니다. 공개 API, 데이터베이스 스키마, 잠금 파일, 공용 설정과 테스트 fixture를 ‘공유 변경 집합’으로 표시하고 이 집합은 한 번에 한 작업만 병합하는 큐를 두세요.
독립성은 파일 개수가 아니라 쓰기 집합과 검증 경계로 판단합니다. 문서 두 개가 같은 생성 스크립트의 출력을 바꾸면 독립적이지 않고, 같은 파일을 수정해도 서로 다른 생성 구간이 명확하고 전체 테스트가 빠르면 통합 가능할 수 있습니다. 계획 단계에서 예상 쓰기 경로를 비교하고 겹침이 생기면 한 작업으로 합치거나 선행, 후행 순서를 정합니다.
각 워커가 작업을 끝낸 시점의 브랜치가 아니라 최신 통합 브랜치 위에서 다시 검증된 커밋만 병합 후보가 되어야 합니다. 기준 커밋 고정, 작은 작업별 커밋, 최신 기준으로 재배치, 단위 테스트, 계약, 통합 테스트, diff 검토, 병합 순으로 진행합니다. 두 워커가 서로의 결과를 필요로 한다면 병렬 작업으로 표시하지 않습니다.
병합 실패를 워커가 무제한 자동 해결하게 두지 마세요. 충돌 파일이 허용 경로 밖이거나 공개 인터페이스를 건드리면 통합 담당자에게 되돌립니다. 자동 해결이 가능한 경우도 충돌 전 양쪽 테스트의 의도를 보존했는지 확인할 새 테스트가 필요합니다. 생성 파일은 원본을 병합한 뒤 한 번 다시 생성하면 불필요한 충돌을 줄일 수 있습니다.
롤백 단위도 작업 카드와 맞춰야 합니다. 여러 워커의 변경을 하나의 거대한 커밋으로 합치면 장애가 났을 때 어떤 작업을 되돌릴지 알기 어렵습니다. 기능 플래그나 비활성 기본값을 사용하고, 병합 커밋마다 소유자와 검증 결과를 남기면 배포 뒤 회귀를 좁히기 쉽습니다.
worktree는 Git 파일 공간만 나눕니다. 동일한 사용자 계정으로 실행하면 모든 워커가 같은 SSH 키, 클라우드 자격 증명, 패키지 토큰과 네트워크에 접근할 수 있습니다. 문서 수정 워커가 운영 데이터베이스에 접속할 이유는 없습니다. 작업별 컨테이너나 샌드박스에 읽기 전용 저장소, 허용 명령과 필요한 테스트 서비스만 제공하고 운영 배포 자격 증명은 분리하세요.
외부 패키지 설치, 데이터 마이그레이션, 브랜치 삭제와 원격 push는 일반 편집과 다른 승인 단계로 둡니다. 워커가 낸 셸 명령과 네트워크 호출을 감사할 수 있어야 하며, 비밀처럼 보이는 문자열은 로그에서 가립니다. 테스트를 위해 쓰기 권한이 필요하면 일회성 데이터와 자동 폐기되는 환경을 제공해 실패가 공유 시스템에 남지 않게 합니다.
프로젝트 메모리에도 비밀 값이나 사용자 데이터를 넣지 않는 편이 좋습니다. 여러 워커가 같은 상태를 읽으면 한 워커가 본 자격 증명이 다른 작업의 문맥으로 퍼질 수 있습니다. 결정 이유와 공개 인터페이스만 기록하고, 어떤 정보가 다음 실행에 주입되는지 사람이 확인할 수 있어야 합니다.
중단 조건은 작업 난이도에 따라 수치로 기록합니다. 같은 테스트 오류가 두 번 연속이면 원인 설명을 요구하고, 세 번째에도 같으면 중단하는 식입니다. diff가 허용 경로를 벗어나거나 수정 파일 수가 계획보다 급증해도 재계획해야 합니다. 테스트 성공만 목표로 주면 assertion 삭제나 과도한 mock으로 점수를 맞출 수 있으므로 변경된 테스트와 커버리지 감소를 별도로 검토합니다.
비교 실험에서는 벽시계 시간, 생성 토큰과 모델 호출 비용, 사람이 검토한 분량, 충돌 파일 수, 병합 뒤 결함과 롤백 횟수를 함께 기록합니다. 네 워커가 코드를 절반 시간에 만들었지만 검토와 통합에 두 배가 들었다면 시스템 처리량은 나아지지 않은 것입니다. 문서, 독립 테스트, 서로 다른 모듈은 병렬화하기 쉽지만 하나의 복잡한 버그를 여러 워커가 동시에 수정하면 중복 탐색이 늘 수 있습니다.
운영 기준은 ‘항상 네 워커’가 아니라 대기 중인 독립 작업 수와 통합 담당자의 처리 능력에 맞춰 동시성을 조절하는 것입니다. 작은 실험에서 단일 워커 기준선을 이기고, 충돌과 재작업이 허용 범위 안에 있을 때만 동시 작업 수를 늘리세요.
작업 디렉터리의 동시 덮어쓰기는 줄지만 공통 인터페이스와 스키마의 의미 충돌은 남습니다. 수정 허용 경로와 의존 순서를 정하고 병합 뒤 통합 테스트를 실행해야 합니다.
독립 작업이 충분할 때만 그렇습니다. 완료 시간뿐 아니라 총 토큰, 병합 충돌, 재작업과 테스트 실패를 단일 워커 기준선과 비교해 워커 수를 정해야 합니다.
최대 시도, 시간, 토큰, diff 크기를 미리 제한하고 같은 실패가 반복되거나 테스트를 약화하려 하면 중단해야 합니다. 배포와 데이터 변경은 별도 승인을 유지합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.