동시성 제한은 일을 늦게 하려는 게 아니라 시스템을 끝까지 살리려는 장치입니다

동시성 제한은 동시에 실행되는 작업 수를 조절해 DB, 외부 API, 워커가 무너지지 않게 합니다.

작업 1개가 1초 걸린다고 해서 1,000개를 동시에 실행하면 1초에 끝날 것 같지만 실제로는 그렇지 않습니다.
DB 커넥션, CPU, 파일 핸들, 외부 API 제한이 먼저 막힙니다.
어느 순간부터 동시성은 속도가 아니라 혼잡을 만듭니다.

제한은 병목 앞에 둡니다

동시성 제한은 무작정 전체 작업 수를 줄이는 게 아닙니다.
진짜로 약한 자원 앞에 둡니다.
DB 쓰기가 약하면 DB 쓰기 직전에, 외부 API 제한이 문제면 호출 직전에, 이미지 변환이 CPU를 먹으면 워커 풀 앞에 둡니다.
병목을 모르면 제한도 엉뚱한 곳에 걸립니다.

세마포어는 가장 단순한 시작점입니다

한 프로세스 안에서는 세마포어나 워커 풀로 동시에 실행되는 작업 수를 제한할 수 있습니다.
여러 서버가 함께 움직이면 큐, 토큰 버킷, DB 기반 락 같은 도구가 필요할 수 있습니다.
처음부터 분산 제어를 넣을 필요는 없습니다.
실제 병목이 한 프로세스 안에 있으면 작은 제한이 더 낫습니다.

좋은 제한값은 측정하면서 찾습니다

동시성 5가 맞는지 50이 맞는지는 문서만 보고 알기 어렵습니다.
처리량, 지연 시간, 에러율을 보면서 올려야 합니다.
제한을 걸었는데 전체 시간이 조금 늘고 실패가 크게 줄었다면 그건 손해가 아닐 수 있습니다.
시스템은 최고 속도보다 끝까지 완료되는 쪽이 더 중요할 때가 많습니다.

마지막으로 확인할 것은 하나입니다.
이 개념을 외웠는지가 아니라, 실패했을 때 어떤 상태가 남는지 설명할 수 있는지입니다.