Go에서 여러 API를 errgroup으로 호출합니다. 첫 오류가 나면 남은 작업과 큐·동시성은 어떻게 되나요?

errgroup은 고루틴의 완료·오류를 모으고 WithContext를 쓰면 오류에 따른 취소 신호를 연결할 수 있습니다. 하지만 함수가 context를 따르지 않으면 실제 작업은 계속되며 무한 큐나 외부 효과가 자동 정리되지는 않습니다.

동작 원리와 전제

SetLimit 등으로 활성 고루틴 수를 제한할 수 있지만 호출을 기다리는 생산자와 입력 목록 메모리는 별도입니다. 필수 결과와 선택 결과를 나누지 않고 모든 오류를 같은 실패로 처리하면 불필요한 취소가 생길 수 있습니다.

선택과 실패 처리

루프의 입력 캡처는 사용하는 Go 버전·선언 방식에 맞게 확인하고 결과 저장은 인덱스 분리나 동기화로 보호합니다. group이 끝난 뒤 파생 context의 수명을 후속 작업에 그대로 의존하지 않도록 계약을 확인합니다.

구체적인 사례와 검증

하위 API 세 개 중 추천 결과만 선택적이라면 추천 오류를 내부 결과로 바꾸고 필수 계정·주문 조회의 실패만 그룹 실패로 연결할 수 있습니다. 다만 timeout을 무조건 빈 값으로 숨기면 사용자에게 정상 추천 없음과 시스템 장애를 구분하지 못하게 할 수 있어 상태를 명시합니다. 제한된 group에 작업을 넣는 호출 자체가 대기할 수 있으므로 생산자 취소와 전체 입력 크기도 관리합니다. 결과 배열의 서로 다른 인덱스에 쓰는 설계라도 slice 확장을 동시에 하면 헤더·저장소 경합이 생길 수 있어 사전 할당과 소유 범위를 확인합니다. 라이브러리 선택과 실제 공유 상태의 안전성을 따로 검증합니다.

하위 timeout·취소 무시·생산자 중단·부분 결과를 시험합니다. 제한된 동시성 안에서 전체 deadline과 정리 시간을 남깁니다. errgroup이라는 라이브러리 사용 여부보다 부모와 자식의 수명·오류 정책을 명확히 하는 것이 핵심입니다.