410. 프로미스·퓨처 기반 비동기 처리 설계 (Promise/Future)

핵심 인사이트 (3줄 요약)

1. 본질: 프로미스 (Promise)와 퓨처 (Future)는 비동기 결과를 값처럼 다루어 호출자와 실행 주체를 느슨하게 연결하는 설계 장치다.
2. 가치: 대기 시간을 숨기고 병렬 처리를 촉진하여 응답성, 확장성, 장애 격리 수준을 동시에 높일 수 있다.
3. 판단 포인트: 체인 길이, 예외 전파, 타임아웃, 취소 가능성, 컨텍스트 전파와 관찰성 확보 여부를 함께 봐야 한다.

Ⅰ. 개요 및 필요성

프로미스·퓨처 기반 비동기 처리 설계는 외부 연계, 파일 처리, 대용량 계산처럼 완료 시점이 불확실한 작업을 메인 흐름과 분리해 다루는 방법이다. 설계감리 관점에서는 단순히 “비동기면 빠르다”가 아니라, 어떤 작업을 지연시키고 어떤 지점에서 결과를 합성할지 명확해야 한다. 즉 스레드 점유를 줄이면서도 오류, 재시도, 사용자 경험을 함께 통제하는 구조가 핵심이다.

특히 마이크로서비스와 사용자 인터페이스가 동시에 복잡해진 환경에서는 동기 호출만으로 처리하면 응답 스레드가 쉽게 막히고 병목이 전파된다. 반면 프로미스와 퓨처를 적절히 사용하면 선행 작업이 끝나기를 기다리는 동안 다른 업무를 수행할 수 있어 자원 활용률이 높아진다. 기술사 답안에서는 “비동기화의 목적은 속도 자체가 아니라 블로킹 감소와 결합도 완화”라는 점을 분명히 적는 것이 좋다.

┌─────────────┐   ┌──────────────┐   ┌──────────────┐   ┌─────────────┐
│ 요청 발생    │──▶│ 비동기 작업 등록 │──▶│ Promise/Future │──▶│ 결과 합성    │
└─────────────┘   └──────────────┘   └──────────────┘   └─────────────┘

위 구조는 호출 시점과 완료 시점을 분리해도 업무 흐름은 유지된다는 점을 보여 준다. 따라서 감리 시에는 기능 흐름도만 볼 것이 아니라 대기 구간이 어디서 발생하고, 그 대기를 어떤 객체가 책임지는지까지 확인해야 한다.

• 📢 섹션 요약 비유: 택배 접수증처럼 물건은 나중에 오더라도 접수 번호가 있으면 흐름을 잃지 않는다.

Ⅱ. 아키텍처 및 핵심 원리

프로미스·퓨처 아키텍처는 작업 제출, 실행, 완료 통지, 후속 연산의 네 축으로 이해하면 정리된다. 퓨처는 “미래에 도착할 값” 자체에 가깝고, 프로미스는 그 값을 완료시키는 약속 주체라는 관점으로 설명하면 답안의 깊이가 살아난다. 언어나 프레임워크마다 구현 차이는 있으나, 완료 전 상태 관리와 완료 후 체이닝, 예외 처리, 취소 제어라는 공통 원리는 동일하다.

┌──────────┐   ┌──────────┐   ┌────────────┐   ┌────────────┐
│ Caller   │──▶│ Executor │──▶│ Future 값   │──▶│ 후속 체인    │
└──────────┘   └────┬─────┘   └────┬───────┘   └────┬───────┘
                     │              │                │
                     └────예외/취소──┴────타임아웃─────┘

핵심 원리는 세 가지다. 첫째, 완료 전 상태를 안전하게 보관해야 한다. 둘째, 성공 경로와 실패 경로를 동일한 수준의 설계 요소로 다뤄야 한다. 셋째, 체인이 깊어질수록 추적성이 떨어지므로 로깅, 분산 추적, 상관관계 식별자 같은 관찰성 장치를 기본값으로 두어야 한다.

• 📢 섹션 요약 비유: 주방 주문판처럼 누가 조리 중이고 누가 완료되었는지 보여야 음식이 섞이지 않는다.

Ⅲ. 비교 및 연결

시험에서는 프로미스·퓨처를 콜백 (Callback), 메시지 큐 (Message Queue), 반응형 스트림 (Reactive Stream)과 비교해 쓰면 차별성이 선명해진다. 프로미스·퓨처는 “한 번 도착할 결과”를 다루는 데 강하고, 메시지 큐는 시스템 간 비동기 분산에, 반응형 스트림은 다건 이벤트 흐름과 백프레셔 제어에 더 적합하다.

또한 프로미스·퓨처는 회로 차단기 (Circuit Breaker), 재시도 (Retry), 보상 트랜잭션 (Compensation)과 연결된다. 비동기 설계를 채택했다면 실패를 늦게 발견하는 구조적 특성이 있으므로, 오류 감지와 복구 정책을 반드시 함께 제시해야 한다.

• 📢 섹션 요약 비유: 손님 한 명의 주문표는 프로미스·퓨처이고, 배달앱 전체 주문 게시판은 메시지 큐라고 보면 이해가 쉽다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 외부 API 병렬 조회, 이미지 변환, 보고서 생성, 알림 전송 등에서 프로미스·퓨처가 자주 쓰인다. 다만 모든 업무를 비동기로 바꾸면 오히려 흐름이 보이지 않고, 장애 시 재현이 어려워질 수 있다. 따라서 “사용자 응답 시간을 단축해야 하는가”, “작업 완료가 즉시 필요하지 않은가”, “실패를 늦게 감지해도 업무상 허용되는가”를 먼저 따져야 한다.

기술사 답안에서는 단순히 구현 문법보다 설계 판단 기준을 써야 득점력이 높다. 예를 들어 CPU 집약 작업은 과도한 스레드 증가로 문맥 전환 비용이 커질 수 있고, 데이터 정합성이 강한 업무는 동기 처리나 트랜잭션 메시징이 더 안전할 수 있다. 결국 비동기는 성능 기법이면서 동시에 운영 리스크 관리 기법이다.

판단 체크리스트

• 작업 결과를 즉시 반환할 필요가 없는가?
• 타임아웃, 취소, 재시도, 보상 절차가 명시되어 있는가?
• 체인 추적을 위한 로그, 트레이스, 상관관계 식별자가 설계되어 있는가?
• 스레드풀 크기와 큐 용량이 업무 특성에 맞게 산정되어 있는가?
• 블로킹 코드가 비동기 체인 내부에 숨어 있지 않은가?

감리 관점의 최종 판단은 “비동기화로 얻는 응답성 이익이 운영 복잡도 증가를 상쇄하는가”에 놓인다. 이 문장을 결론부에 넣으면 실무형 답안이 된다.

• 📢 섹션 요약 비유: 놀이공원 패스트패스처럼 기다림을 줄일 수는 있지만, 입장 규칙이 없으면 줄만 더 복잡해진다.

Ⅴ. 기대효과 및 결론

프로미스·퓨처 기반 설계를 올바르게 적용하면 블로킹 감소, 자원 활용률 향상, 병렬 합성 성능 개선이라는 직접 효과를 얻는다. 더 중요한 간접 효과는 호출자와 실행 주체를 분리해 서비스 경계를 유연하게 만들고, 후속 확장이나 장애 격리 전략을 선택하기 쉬워진다는 점이다.

결론적으로 이 주제의 답안 포인트는 “비동기 기법 설명”이 아니라 “비동기 체인의 통제 가능성 설명”이다. 즉 완료 여부를 어떻게 추적하는지, 실패를 어디서 회수하는지, 운영 중 병목을 어떻게 식별하는지까지 써야 설계감리형 답안이 된다.

• 📢 섹션 요약 비유: 미리 받은 교환권처럼 나중에 물건을 찾더라도 추적 번호가 있으면 서비스는 안정적으로 굴러간다.

📌 관련 개념 맵

• 프로미스·퓨처 → 비동기 합성 → 응답성 개선
• 비동기 합성 → 타임아웃·취소·재시도 → 장애 통제
• 실행기 설계 → 스레드풀·이벤트 루프 → 자원 활용 최적화
• 관찰성 → 로그·트레이싱·상관관계 식별자 → 운영 추적성 확보

📈 관련 키워드 및 발전 흐름도

비동기 호출 → 퓨처 → 프로미스 체이닝 → 완료 단계 (Completion Stage) → 반응형 스트림 → 구조적 동시성 (Structured Concurrency)

• 핵심 키워드: 비동기, 체이닝, 타임아웃, 취소, 백프레셔, 관찰성

👶 어린이를 위한 3줄 비유 설명

1. 빵집에서 번호표를 받으면 빵이 나올 때까지 계속 카운터를 붙잡고 있지 않아도 돼요.
2. 번호표는 “나중에 받을 빵”을 약속해 주는 종이라서 다른 일을 하다가 다시 오면 돼요.
3. 대신 번호가 잘 불리는지, 빵이 안 나오면 어떻게 할지 미리 정해 두어야 해요.