iOS 앱에서 다운로드 결과는 요청한 화면에 돌려주고, 로그인 상태 변경은 여러 화면에 알려야 합니다. delegate·완료 클로저·Notification을 어떤 기준으로 나누나요?

세 방식은 구독자 수만으로 고르는 문법 선택이 아니라, 누가 누구를 알고 있어야 하는지와 결과의 수명·재생 필요성을 정하는 설계 선택입니다. 한 객체가 특정 협력자와 여러 이벤트를 주고받고 협력자의 결정을 다시 받아야 하면 delegate를 우선합니다. 한 번 시작한 작업의 성공·실패·취소 결과를 호출자 가까이에서 처리하면 완료 클로저가 알맞습니다. 발신자가 수신자 목록을 몰라도 여러 독립 객체가 같은 사건에 반응해야 하면 Notification을 검토합니다. 선택 뒤에는 호출 횟수, 취소, 수신자 해제, 놓친 사건의 복구를 명시하겠습니다.

관계가 선명하면 delegate입니다

예를 들어 다운로드 컴포넌트가 진행률·인증 요구·완료·실패를 순서 있게 전달하고 화면이 인증서 선택이나 재시도 여부를 돌려줘야 한다면 프로토콜 기반 delegate가 계약을 드러냅니다. 메서드 목록과 필수 응답을 컴파일러가 확인할 수 있고, 이벤트가 늘어나도 한 협력 관계 안에서 상태를 관리하기 쉽습니다. 다만 컴포넌트가 delegate를 강하게 소유하고 화면도 컴포넌트를 소유하면 순환이 생길 수 있으므로 delegate는 보통 weak로 둡니다. delegate가 하나라는 전제는 구현 편의가 아니라 API 계약이므로, 여러 수신자가 필요해지면 멀티캐스트의 해제·순서·실패 전파 규칙을 새로 정의해야 합니다.

단일 요청에 결과 하나를 돌려주는 상황에서는 호출부에 completion을 넘기는 편이 간결합니다. 이미지 한 장을 조회해 해당 셀에 표시하는 작업처럼 결과 소비자가 호출 시점에 정해지고, 완료가 한 번이라는 계약을 만들 수 있을 때 적합합니다. 그러나 작업 객체가 클로저를 오래 보관하고 클로저가 작업 객체나 뷰 컨트롤러를 강하게 캡처하면 순환이 생깁니다. [weak self]를 사용하더라도 화면이 사라진 뒤 결과를 버려도 되는지부터 정해야 합니다. 성공·실패·취소가 중복 호출되지 않고, 취소 뒤 늦은 완료를 무시하는 원자적 상태가 있어야 합니다. 반복 이벤트나 여러 소비자가 필요해진다면 클로저 하나를 재호출하는 대신 delegate, AsyncSequence, 명시적 상태 저장소로 관계를 재설계하겠습니다.

방송은 결합도를 낮추지만 계약을 숨깁니다

로그인 상태 변경처럼 세션 화면, 프로필 화면, 캐시 무효화기가 각자 독립적으로 반응해야 하고 발신자가 이 객체들을 직접 알 필요가 없으면 Notification이 맞습니다. 발신자와 수신자를 분리하는 이 방식은 발행-구독(publish-subscribe)이라고 부릅니다. 하지만 컴파일러가 전체 구독자를 알려 주지 않고 호출 순서·중복 수신·스레드가 코드 한 곳에 드러나지 않습니다. 등록 토큰의 수명을 관찰자 수명에 맞추고, 메인 스레드에서 UI를 바꾸는지 확인하며, payload에 비밀번호나 불필요한 개인정보를 싣지 않겠습니다.

Notification은 과거 사건을 저장하거나 새 구독자에게 재생하지 않습니다. 앱이 로그인 알림을 놓친 뒤 나타난 화면이 최신 사용자를 보여야 한다면 알림을 현재 상태의 원천으로 삼지 말고 세션 저장소에서 상태를 읽어 화면을 구성한 다음, 알림은 무효화·갱신 신호로만 사용하겠습니다. 필요한 경우 Notification은 사건을 전달하고 저장 모델은 상태를 보존하는 식으로 분리합니다.

실제 검증에서는 다운로드 완료를 두 번 보내거나 취소 직후 완료를 보내는 경우, 화면 해제 후 콜백이 도착하는 경우, 로그인 알림 등록 전 상태가 바뀐 경우를 재현합니다. delegate는 한 협력자의 다단계 계약, 클로저는 짧은 작업의 단발 결과, Notification은 독립 소비자의 사건 방송이라는 첫 판단을 하고, 수명과 복구가 그 판단을 뒤집는지 확인하겠습니다.