대모델 비동기 작업 메커니즘 설계
비동기 추론은 동기 요청을 폴링으로 바꾸는 것이 아니다. 백그라운드 모드가 해결하는 것은 실행 생명주기이고, 프런트엔드 수령 메커니즘이 해결하는 것은 사용자가 어떻게 결과를 확실히 받는가다. 백그라운드 모드가 진짜로 해결하는 것은 시스템 신뢰성이지 단순히 인터페이스 타임아웃 회피가 아니다.
어떤 장면이 「장시간 AI 작업」인가
| 장면 | 왜 동기로 기다릴 수 없나 |
|---|
| 리포트 생성 | 소요가 길어 HTTP 요청이 타임아웃 |
| 대용량 파일 분석 | 위와 같음 |
| 코드 실행 | 위와 같음 |
| 여러 도구 호출 | 링크가 길고 불확실 |
| 사람 확인 대기 | 소요를 전혀 예측할 수 없음 |
두 메커니즘이 서로 다른 두 문제를 해결한다
백그라운드 모드 — 실행 생명주기
프런트엔드 수령 메커니즘 — 사용자가 어떻게 결과를 확실히 받는가
백그라운드 모드의 핵심 6요소
| # | 요소 | 역할 |
|---|
| 1 | 작업 ID | 사용자가 떠난 뒤 작업을 다시 찾는 유일한 증표 |
| 2 | 상태 머신 | 실행 과정의 상태 전이 관리 |
| 3 | 결과 저장 | 결과가 프런트 페이지나 메모리에 종속되지 않음 |
| 4 | 권한 검증 | 귀속 사용자만 볼 수 있도록 보장 |
| 5 | 만료 정책 | 결과를 영구 보존하지 않음 |
| 6 | 알림 메커니즘 | 완료 후 사용자에게 도달 |
달성 효과: 사용자가 떠나고, 새로고침하고, 기기를 바꿔도 돌아와서 계속 볼 수 있다. 브라우저 커넥션을 작업 생명주기로 삼지 않고, 결과를 어떤 프런트 페이지 안에만 존재하게 두지도 않는다.
1단계: 작업 상태 머신
- 대기 중
- 실행 중
- 사용자 확인 대기
- 성공
- 실패
- 만료됨
- 취소됨
| 상태 유형 | 대응 동작 |
|---|
| 복구 가능한 실패 | 재시도 |
| 파라미터 부족 | 파라미터 보충 |
| 사람 개입 필요 | 재확인 |
| 복구 불가 | 재제출만 가능 |
2단계: 결과 저장 메타데이터
결과는 메모리에만 있어서도 안 되고, 영구 보존한 채 방치해서도 안 된다.
| 메타데이터 | 용도 |
|---|
| 결과 ID | 결과 위치 특정 |
| 귀속 사용자 | 누구의 작업인지 판단 |
| 가시 권한 | 누가 볼 수 있는가 |
| 보존 기간 | 언제 만료되는가 |
| 다운로드 방식 | 어떻게 가져가는가 |
| 감사 기록 | 사후 추적 |
3단계: 실패 복구와 재해 대비
- 모델 서비스 타임아웃
- 도구 실행 실패
- 사용자 네트워크 단절
- 프로세스 재시작
이 중 어느 것도 작업을 그냥 사라지게 해서는 안 된다. 시스템은 세 가지 질문에 답할 수 있어야 한다:
- 어느 단계에서 실패했는가?
- 재시도 가능한가?
- 재시도하면 외부 동작이 중복 실행되는가? (→ 멱등성)
프런트엔드는 무엇을 하고 무엇을 하지 않는가
| 프런트엔드가 담당 | 프런트엔드가 담당하지 않음 |
|---|
| 작업 생성 | 작업의 진실 저장 |
| 상태 표시 | |
| 결과 수령 | |
| 취소 발기 | |
| 재시도 발기 | |
작업의 진실은 백엔드에 있다. 실행 단계, 모델 호출, 도구 반환, 확인 기록, 최종 산출물을 포함한다. 이렇게 해야 사용자가 기기를 바꿔도 진행 상황을 잃지 않는다.
핵심 통찰
- 「백그라운드 모드」와 「작업 수령 메커니즘」은 같은 층위의 것이 아니다 — 전자는 서버 측의 실행 생명주기 관리이고, 후자는 클라이언트 측의 결과 도달 가능성 보장이다. 둘을 뒤섞는 것이 이 문제의 가장 전형적인 실점 지점이다.
- 비동기화의 진짜 비용은 「폴링으로 바꾸기」가 아니라 그에 따라 도입되는 상태 의미론 한 세트다 — 동기 인터페이스는 「성공/실패」 두 상태뿐이지만, 비동기 시스템은 즉시 7가지 상태와 각 상태에 대응하는 제품 동작으로 팽창한다. 설계자는 먼저 상태 열거를 남김없이 정의한 다음 인터페이스를 논해야 한다.
- 상태 입도가 제품 가용성을 결정한다 — 뭉뚱그린
processing 하나로는 UI가 「재시도 / 파라미터 보충 / 재확인」이라는 차별화된 버튼을 제공할 수 없다. 상태는 제품 동작을 위한 것이지 로그를 위한 것이 아니다.
- 결과는 일급 리소스이지 응답 바디의 부속품이 아니다 — 결과가 ID, 귀속, 권한, 보존 기간, 다운로드 방식, 감사 기록을 필요로 하는 순간, 그것은 「인터페이스 반환값 캐시」가 아니라 독립된 도메인 객체로 모델링되어야 한다.
- 멱등성은 비동기 시스템의 입장권이다 — 「재시도하면 외부 동작이 중복 실행되는가」라는 질문이, 부작용을 가진 모든 단계에 멱등 키가 있어야 함을 결정한다. 멱등 키가 없는 재시도 버튼은 곧 사고 버튼이다.
- 상태 전이는 반드시 서버 측에서 일어나야 하고 프런트는 의도 제출 입구일 뿐이다 — 확인, 재시도, 취소 중 어느 하나라도 프런트 메모리나 URL 상태에 존재하면 새로고침 시 사라진다. 이 원칙 하나가 「기기 변경」과 「사용자 재진입」 두 문제를 동시에 해결한다.
- 비동기 장시간 작업은 태생적으로 데이터 유출면이다 — 결과가 파일/코드/고객 데이터를 담고 있고 + 수령 링크를 공유할 수 있고 + 만료 정책이 없으면 = 데이터 외부 유출이다. 「랜덤 URL이 곧 자격증명」이 가장 흔한 오설계다.
- 신뢰성의 검증 가능한 정의 — 설계 리뷰 체크리스트로 바로 쓸 수 있는 세 가지 판단 기준: 되찾을 수 있는가, 설명할 수 있는가, 중복 실행되는가. 추상적으로 「고가용성이 필요하다」고 말하는 것보다 훨씬 구체적이다.
엔지니어링 실전 Tips
- 브라우저 커넥션을 작업 생명주기로 삼지 말 것. 프런트 새로고침, 네트워크 단절, 페이지 닫기가 작업에 영향을 주면 안 된다. 이것이 비동기 설계의 합격 여부를 가리는 첫 번째 테스트다.
- 작업의 진실은 단 하나이며 백엔드에 있다: 실행 단계, 모델 호출, 도구 반환, 확인 기록, 최종 산출물. 프런트의 어떤 로컬 캐시도 투영일 뿐이다.
- 「사용자 확인 대기」가 가장 설계를 그르치기 쉬운 상태다. 수 시간에서 수일까지 지속될 수 있기 때문이다. 확인 상태는 반드시 서버 측에 영속화해야 하며, 그렇지 않으면 한 번의 새로고침으로 사라진다.
- 재시도 버튼을 상용에 올리기 전에 먼저 「이 단계에 외부 부작용이 있는가」를 물을 것: 메일 발송, 과금, 서드파티 시스템 쓰기 단계에 멱등 키가 없다면 재시도 입구를 노출하지 말 것.
- 결과 보존 기간은 컴플라이언스 요구와 정렬할 것: 기업 장면의 작업 결과에는 고객 데이터가 담기는 경우가 많아 보존 기간은 비용 문제이자 컴플라이언스 문제다.
- 감사 기록은 선택 사항이 아니다: 누가 언제 어떤 결과를 다운로드했는지는 기업 고객의 보안 심사를 통과하기 위한 필수 요구다.
- 폴링 빈도와 상태 입도를 연동할 것: 대기 중에는 저빈도 폴링, 실행 중에는 빈도를 높이고, 확인 대기 상태는 지속적 폴링 대신 푸시/메일로 전환할 것.
- 답변 구조: 먼저 「실행 생명주기 vs 결과 도달 가능성」을 구분 → 6요소 제시 → 멱등 재시도와 사용자 재진입 보충 → 마지막에 「신뢰성 3문」으로 마무리. 이 순서가 명사를 나열하는 것보다 설계 능력을 잘 보여준다.