# 병렬 도구 호출은 코딩 에이전트의 신뢰성을 어떻게 바꾸나요? > 병렬 도구 호출은 독립 읽기의 latency를 낮추지만 상태를 공유하거나 순서에 의존하거나 쓰기를 수행하면 신뢰성을 떨어뜨립니다. 명시적 dependency graph, resource lock, idempotency key, 결정론적 결과 병합을 사용하세요. 병렬 도구 호출은 스케줄링 제안이지 모든 작업을 한꺼번에 시작하라는 허가가 아닙니다. 두 repository 검색은 대개 겹칠 수 있습니다. 파일 편집과 formatter는 아닐 수 있습니다. Dependency install과 test run은 같은 설치 전 상태에서 시작해서는 안 됩니다. Concurrency가 리소스와 dependency 모델을 따를 때 신뢰성이 높아집니다. 실행기가 호출 배열을 독립성의 증거로 취급하면 신뢰성이 낮아집니다. ## 효과에 따라 호출을 분류하세요 Registry의 각 도구에 scheduler가 강제할 수 있는 동작을 표시하세요. | 효과 유형 | 예시 | 기본 정책 | |---|---|---| | 순수 읽기 | source file 두 개 읽기 | 병렬 허용 | | 외부 읽기 | API 두 개 조회 | 제한 내 병렬 | | 로컬 쓰기 | 파일 편집 | 리소스별 직렬화 | | 전역 쓰기 | dependency 설치 | 전역 직렬화 | | 비가역 동작 | Publish 또는 send | 명시적 gate 필요 | 도구 이름만 믿지 마세요. `inspect` 명령도 cache를 만들 수 있고 테스트도 snapshot이나 database를 쓸 수 있습니다. Side effect를 registry에 문서화하세요. ## 실행 전에 dependency graph를 만드세요 호출을 node, 필요한 순서를 edge로 표현하세요. 선행 node가 성공하고 리소스가 사용 가능할 때만 호출을 시작합니다. ```text read_config ----+ +--> build --> test read_source ----+ search_docs ---------> summarize ``` 처음 두 읽기는 함께 실행할 수 있습니다. Build는 둘 다 기다리고 test는 build를 기다립니다. 문서 검색이 build input에 영향을 주지 않으면 repository 작업과 겹칠 수 있습니다. 모델이 dependency를 주지 않으면 도구 metadata와 인수에서 보수적으로 추론하세요. 모호한 쓰기는 직렬 실행합니다. ## 에이전트 전체가 아니라 리소스를 잠그세요 전역 단일 호출 lock은 신뢰할 수 있지만 느립니다. 리소스 수준 lock은 안전한 concurrency를 보존합니다. 경로를 비교하기 전에 정규화하세요. `src/a.ts` 편집은 `src` formatting과 충돌하고 lockfile 생성은 다른 package 작업과 충돌합니다. Database, browser session, terminal, remote record도 리소스 모델에 포함하세요. | 리소스 | Lock 범위 | |---|---| | Source file | 정규 경로 | | Directory formatter | 디렉터리 하위 트리 | | Package manager | Workspace와 lockfile | | Browser session | Tab 또는 인증 workflow | | Deployment | Environment와 service | ## 스트림 전체에서 호출 ID를 보존하세요 여러 호출이 교차된 인수 조각을 낼 수 있습니다. Call ID별로 buffer하고 각 호출이 완료 이벤트를 받은 뒤 실행하세요. Output 위치를 영구 ID로 사용하지 마세요. 동일한 opaque call ID로 결과를 반환하세요. 완료 순서가 달라도 원래 호출 순서처럼 결정론적인 방식으로 표시합니다. Atlas Cloud는 OpenAI Chat Completions에서 도구 기능을 공개한 모델에 `tools`, `tool_choice`, `parallel_tool_calls`를 전달합니다. 모든 경로가 병렬 호출을 지원한다고 가정하지 말고 [LLM 프로토콜 가이드](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-parallel-tool-calls-change-coding-agent-reliability)에서 모델과 프로토콜을 확인하세요. ## 부분 실패 정책을 정의하세요 병렬 batch에는 성공과 실패 외 상태가 있습니다. 하나는 완료되고, 하나는 검증에 실패하며, 하나는 여전히 실행 중일 수 있습니다. 효과에 따라 정책을 고르세요. * 성공한 독립 읽기는 보존하고 실패한 읽기를 보고합니다. * Prerequisite 실패 뒤 대기 중인 종속 호출을 취소합니다. * Idempotency key 없이 완료된 쓰기를 retry하지 않습니다. * 도구가 명시적으로 지원할 때만 보상을 사용합니다. * 구조화된 batch result를 모델에 반환합니다. Retry는 전체 batch를 재생하지 말고 실패 node만 대상으로 해야 합니다. ## Concurrency를 제한하고 backpressure를 적용하세요 독립 호출도 filesystem, API, test runner, rate limit을 과부하시킬 수 있습니다. 도구와 리소스별 concurrency 제한을 두고 초과 작업을 queue에 넣으며 취소를 지원하세요. 가장 느린 호출, queue 시간, retry 수, 중복 억제, 최종 작업 성공을 측정합니다. 출력이 정확할 때만 더 짧은 시간이 의미가 있습니다. ## 출력뿐 아니라 스케줄을 테스트하세요 Race bug는 특정 완료 순서에서 사라질 수 있습니다. 같은 fixture에 지연을 넣어 다른 스케줄을 강제하세요. | 테스트 | 강제 순서 | 기대 결과 | |---|---|---| | 읽기 두 개 | A 후 B, B 후 A | 병합된 증거 동일 | | 읽기와 쓰기 | 쓰기 대기 | 읽기가 정의된 버전 확인 | | 같은 파일 쓰기 두 개 | 어떤 제안 순서든 | 하나의 직렬 계획 | | 오류와 느린 호출 | 오류 먼저 | 종속 호출 취소 | | 쓰기 후 연결 끊김 | 응답 손실 | 쓰기 중복 없음 | CI가 timing 운에 의존하지 않고 스케줄을 재현하도록 fake executor를 사용하세요. ## 직렬 실행이 더 나은 경우를 정하세요 Migration, package install, 공유 파일 편집, publish 단계, rollback이 불분명한 작업은 직렬 실행이 적합합니다. Repository 탐색, 독립 문서 읽기, 격리 lint check, 분리된 test shard는 병렬화에 적합합니다. [Atlas Cloud LLM 카탈로그](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-parallel-tool-calls-change-coding-agent-reliability)의 모델이 여러 호출을 제안해도 실제로 동시 실행할 수 있는지 결정하는 책임은 실행기에 있습니다. ## 결론 작업이 독립적이고 읽기 중심일 때 병렬 호출은 코딩 에이전트를 빠르게 합니다. Side effect, 숨은 리소스, 순서를 무시하면 신뢰성이 떨어집니다. 도구를 분류하고 dependency graph를 만들며 공유 리소스를 잠그고 call ID를 보존하고 개별 idempotent node만 retry하며 여러 스케줄을 테스트하세요. 모델이 concurrency를 제안해도 실행기가 안전을 강제해야 합니다. ## FAQ ### 어떤 코딩 에이전트 도구 호출을 안전하게 병렬 실행할 수 있나요? 서로 다른 리소스에 대한 독립 읽기 전용 호출이 가장 안전합니다. Cache, 임시 파일, 공유 세션을 변경하지 않는지 확인하세요. ### 파일 편집을 병렬 실행해도 되나요? 소유 범위가 분리되고 merge가 결정론적일 때만 가능합니다. 같은 파일, 생성 artefact, lockfile, 공유 build state는 직렬 실행이 안전합니다. ### 병렬 호출 하나가 실패하면 어떻게 하나요? Orchestrator에 명확한 정책이 필요합니다. 종속 호출 취소, 성공한 읽기 보존, 완료된 쓰기 보상 또는 idempotent 호출만 retry하는 방식입니다. ### 결과를 모델에 어떻게 반환해야 하나요? 각 call ID를 보존하고 성공, 오류, 취소 상태를 명시한 채 결정론적 순서로 결과를 병합하세요. ### 병렬 호출이 에이전트 비용을 줄일 수 있나요? 경과 시간을 줄일 수 있지만 token 사용, 중복 작업, retry를 늘릴 수도 있습니다. 완료 작업 비용과 정확성을 latency와 별도로 측정하세요. ### 모든 모델이 병렬 도구 호출을 지원하나요? 아닙니다. 선택 모델과 프로토콜을 확인하세요. 도구는 지원하지만 같은 턴의 다중 호출은 지원하지 않는 경로도 있습니다.