논문 실측 5단계 · 정책 시뮬레이션과 결과

목표

수집한 실측 기록 하나로 세 정책(기다리기·재시도·전환)을 썼다면 결과가 어땠을지 다시 계산해 비교한다.

A. 비교한 정책

정책	동작	사용하는 기록
기다리기	응답이 올 때까지 대기	gemini_1
재시도	T초 안에 안 오면 끊고 같은 API로 다시 호출	gemini_1 + gemini_2
전환	T초 안에 안 오면 끊고 다른 AI로 호출	gemini_1 + openai

대기시간 = 사용자가 답을 받기까지 걸린 시간 (끊기 전 T초 포함)
정책마다 따로 호출하지 않고 한 번의 기록으로 세 정책을 계산 → 비용·시간 절약

B. 코드 `sim.py` (맥 `~/paper2-data/`)

def simulate(rows, policy, T):
    lat, ok, extra = [], 0, 0
    for r in rows:
        g1, g2, o = r["gemini_1"], r["gemini_2"], r["openai"]
        if policy == "wait" or (g1["ok"] and g1["sec"] <= T):
            t, success = g1["sec"], g1["ok"]
        elif policy == "retry":
            t, success = T + g2["sec"], g2["ok"]
            extra += 1
        else:  # switch
            t, success = T + o["sec"], o["ok"]
            extra += 1
        ok += success
        if success:
            lat.append(t)
    ...

1차가 T초 안에 오면 세 정책 모두 같은 결과. T를 넘거나 실패하면 재시도는 T + 2차 시간, 전환은 T + OpenAI 시간
실행: python3 sim.py 또는 python3 sim.py 2.5 3 4 (타임아웃 직접 지정)

C. 중간 결과 (10.8 11:03 ~ 10.14 01:50, 805회)

	p50	p95	p99	최대
Gemini 기다리기	2.40초	2.75	3.46	4.96
재시도 (T=2.5초)	2.40	5.17	5.35	5.90
전환 (T=2.5초)	2.40	7.17	8.29	26.26
재시도·전환 (T=5초)	2.40	2.75	3.46	4.96 (발동 0회)

Gemini 실패 0회. OpenAI 실패 6회는 모두 max_tokens 400 (측정 설정 문제, 4단계 트러블슈팅 1)
처음 계획한 타임아웃 5/10/20초는 가장 느린 응답(4.96초)보다 길어서 한 번도 발동 안 함 → p95·p99 근처 값으로 바꿈
정상 상황에서는 기다리기가 가장 나음. 타임아웃을 p95보다 짧게 잡으면 곧 올 답을 버리고 다시 기다려서 오히려 약 2배 느려짐
OpenAI는 10.20 오전~~점심에 응답이 20~~40초로 느려진 구간이 있었음 (평소 약 4초) → 전환 대상도 느려질 수 있다는 근거
최종 숫자는 10.21~10.25 재수집 데이터를 합쳐서 갱신

D. 최종 결과 (1,528회)

데이터: 1기간 10.8 11:03 ~ 10.14 02:30 (806회) + 2기간 10.21 10:21 ~ 10.26 10:30 (722회)
402(크레딧 소진) 구간 1,057회는 결제 문제라 제외 (4단계 트러블슈팅 2)

	p50	p95	p99	최대
Gemini 1차	2.42초	2.80	3.22	5.85
OpenAI	4.09초	5.84	8.59	23.76

Gemini p95가 1기간 2.75초, 2기간 2.82초로 거의 같음 → 기간이 달라도 꼬리 지연이 안정적
OpenAI 실패 13회는 모두 max_tokens 400 (측정 설정 문제)

정책별 결과

정책	타임아웃 T	성공률	p95	p99	추가 호출
기다리기	-	99.93%	2.80초	3.22초	0%
재시도	2.5초	99.93%	5.19	5.38	35.6%
전환	2.5초	99.54%	7.44	9.22	35.6%
재시도	3.0초	99.93%	2.80	5.47	1.7%
전환	3.0초	100%	2.80	7.30	1.7%
재시도	3.5초	99.93%	2.80	3.22	0.65%
전환	3.5초	100%	2.80	3.22	0.65%

T가 p95보다 짧으면 오히려 느려짐: 요청의 35.6%가 추가 호출되고, 끊기 전 기다린 2.5초가 더해짐
T를 p99보다 조금 길게(3.5초) 두면 추가 호출은 1% 미만이고 지연은 기다리기와 같음
실제 장애 1회: 10.22 00:00 Gemini 1·2차 모두 SSL 오류, 같은 시각 OpenAI는 4.49초에 성공 → 전환만 복구. 같은 회사에 다시 보내는 재시도로는 못 피함
- SSL 오류는 모두 자정에 발생, 원인은 확인 못 함
이 환경에서는 T=3.5초 전환이 지연을 늘리지 않으면서 장애도 복구한 유일한 조합
10.20 OpenAI가 20~40초로 느려진 구간은 402 제외 구간에 들어가서 최종 표에는 반영 안 됨

E. 한계

실제 장애가 1회뿐이라 "실패 대응" 효과는 일반화하기 어려움. 주로 "느린 응답 대응" 비교
재시도는 1차가 끝난 뒤 부른 2차 기록으로 흉내 냄
OpenAI 답은 약 250토큰, Gemini는 약 10토큰 → 전환이 느린 게 모델 차이인지 답 길이 차이인지 구분 안 됨
측정 장소 1곳(집 네트워크), 약 11일치

목표

A. 비교한 정책

B. 코드 sim.py (맥 ~/paper2-data/)

C. 중간 결과 (10.8 11:03 ~ 10.14 01:50, 805회)

D. 최종 결과 (1,528회)

정책별 결과

E. 한계

B. 코드 `sim.py` (맥 `~/paper2-data/`)