근본 원리적 사고: Async Queue 기반 설계에 의문을 제기하는 방법

I’m happy to help translate the article, but I need the full text you’d like translated. Could you please provide the content (or paste the article) that should be translated into Korean? Once I have the text, I’ll keep the source link at the top unchanged and translate the rest while preserving all formatting, markdown, and code blocks.

면접관이 비동기 큐에 대해 묻는 이유

면접관은 여러분이 Kafka, SQS, RabbitMQ를 알고 있는지를 평가하는 것이 아니라, 여러분이 다음을 할 수 있는지를 평가합니다:

• 시간에 대해 생각하기
• 실패에 대해 생각하기
• 순서에 대해 생각하기
• 사용자 경험에 대해 생각하기

기본 원칙 사고

• 해결책부터 시작하지 말 것.
• 정확성을 가정하지 말 것.
• 모든 시스템이 답해야 하는 기본적이고 피할 수 없는 질문을 하라.

비동기 큐는 차단을 없애기 때문에 올바르게 보이지만, 직관만으로 정확성이 보장되지는 않는다. 우리는 특정 제품이 아니라 이 추상적인 패턴에 대해 논의할 것이다:

User → API → Storage → Queue → Worker → Storage

도메인 가정은 필요하지 않다. 이는 다음과 같은 용도로 사용할 수 있다:

• 채팅 메시지
• 이메일
• 결제
• 알림
• 이미지 처리

질문 과정은 동일하게 유지된다.

Source: …

질문 과정

1. 시스템이 응답하기 전에 완료해야 하는 책임은 무엇인가?

이것은 시스템 설계에서 가장 중요한 질문이다. 요청 경계, 지연 시간 기대치, 그리고 책임을 결정한다.

“작업이 큐에 넣어지면 요청이 완료된다.”

이는 작업이 끝난 후에 요청이 완료되는 동기식 설계와 다르다.

2. 요청이 끝난 뒤에 수행되는 작업은 어느 부분인가?

Answer: 워커 처리.

시스템은 작업을 시간에 따라 분리했다. 시간 분리는 강력하지만 새로운 질문을 만든다.

3. 시스템은 어떤 출력이 어떤 입력에 해당하는지 어떻게 알까?

시간이 분리될 때는 작업과 결과를 연결할 방법이 필요하다.

• Typical answer: 작업 페이로드에 포함된 ID(요청 ID, 엔터티 ID).
• New invariant: 각 입력은 정확히 하나의 올바른 출력을 생성해야 한다.

4. 워커가 처리 중에 충돌하면 어떻게 되는가?

현실적인 답변:

• 작업이 재시도된다.
• 작업이 다시 실행될 수 있다.
• 출력이 두 번 생성될 수 있다.

비동기 큐는 보통 at‑least‑once이며 exactly‑once가 아니다. 이는 도구의 문제가 아니라 분산 시스템의 근본적인 특성이다.

5. 동일한 작업이 두 번 처리되면 어떻게 되는가?

결과:

• 중복된 출력
• 중복된 부수 효과
• 충돌하는 상태

이는 앞서 정의한 불변식(“입력당 정확히 하나의 출력”)을 위반한다. 이 시점에서 발견한 것은 성능 문제가 아니라 정확성 문제이다.

6. 처리 순서는 무엇에 의해 정의되는가?

큐 순서 ≠ 비즈니스 순서. 서로 다른 워커가 서로 다른 속도로 처리하므로 나중에 들어온 입력이 먼저 끝날 수도 있다.

정확성이 순서에 의존하는가?
만약 그렇다면(많은 시스템이 그렇다) 비동기 큐만으로는 충분하지 않다. 이 문제는 순서를 명시적으로 질문할 때 비로소 드러난다.

7. 사용자는 작업이 끝났음을 어떻게 알 수 있는가?

가능한 답변:

• 폴링
• 추측
• 타임아웃

각 답변은 문제를 드러낸다:

• 폴링은 자원을 낭비한다.
• 추측은 신뢰할 수 없다.
• 타임아웃은 부하가 걸릴 때 실패한다.

이는 핵심 시스템 원칙을 위반한다: 사용자는 맹목적으로 기다려서는 안 된다.

예시: 사진 처리 파이프라인

1. 사용자가 사진을 업로드합니다.
2. API가 메타데이터를 저장합니다.
3. 작업이 대기열에 추가됩니다.
4. 워커가 사진을 처리합니다.
5. 결과가 저장됩니다.

질문을 적용해 보면:

이러한 문제들은 이미지 자체와는 관련이 없으며, 시간, 실패, 정체성, 가시성에 관한 것입니다.

비동기 큐가 해결하는 문제 vs. 도입하는 문제

이러한 트레이드오프를 이해하는 것이 중요합니다. 도입된 문제들을 이해하고 처리한다면 설계는 건전할 수 있습니다.

비동기 큐 설계에 필요한 다섯 가지 핵심 질문

1. 요청을 누가 완료합니까?
2. 무엇이 나중에 실행됩니까?
3. 두 번 실행되면 어떻게 됩니까?
4. 어떤 기준으로 순서를 정의합니까?
5. 사용자는 완료를 어떻게 관찰합니까?

다섯 가지 질문에 모두 명확히 답할 수 없다면 설계가 불완전한 것입니다.

비동기 시스템은 시간 결합을 없애지만 기본적으로 인과 관계를 파괴합니다. 엔지니어로서의 역할은 “큐를 무조건 사용한다”가 아니라 정확성을 명시적으로 복원하는 것이며, 이것이 면접관이 찾는 핵심 포인트입니다.