해결 방법이 셋이라 골라야 했다

외부 API 호출이 자주 실패했고 고치는 방법이 셋 있었는데 어느 것이 나은지 바로 정해지지 않았다.

Open Table of contents

세 가지 방법과 비교 축

재시도 횟수를 늘리는 것과 결과를 담아 두고 실패하면 옛 값을 쓰는 것과 그 값 없이도 되게 화면을 바꾸는 것 셋이었다. 셋 다 증상을 없애기는 한다.

비교할 축을 먼저 정했다. 얼마나 빨리 되는지와 얼마나 오래 가는지와 다른 것에 영향이 있는지와 되돌릴 수 있는지 넷이다.

        빠름   오래감   영향   되돌림
A       빠름   낮음     없음   쉬움
B       중간   중간     있음   중간
C       느림   높음     있음   어려움

축을 정하지 않으면 각자 마음에 드는 것을 고르게 되고, 정하고 나면 상황에 따라 답이 달라진다는 것도 드러난다. 이때는 실패율이 8%이고 화면이 안 뜨는 상태라 급했으므로 빠른 것이 먼저였다.

처음에는 셋 중 하나를 고르려 했는데 성격을 보니 서로 대체하는 것이 아니었다. 재시도는 당장 줄이는 것이고 캐시는 더 줄이는 것이며 구조 변경은 근본을 없애는 것이다.

셋 중 하나가 아니라 어느 순서로였다. 당일에 재시도를 늘려 실패율을 8%에서 2%로 낮추고, 그 주에 캐시를 넣어 0.2%까지 낮추고, 다음 달에 구조를 바꾸는 계획으로 정리했다.

구조를 바꾸고 나면 앞의 둘이 필요 없어질 수 있었다. 재시도는 다른 호출에도 쓰이므로 남기고 캐시는 그 값 자체가 필요 없어지므로 뺀다.

뺄 시점을 미리 정해 두지 않으면 안 쓰는 코드가 그대로 남는다. 실제로 구조를 바꾼 뒤 캐시를 제거했고 그 판단을 그때 새로 하지 않아도 됐다.

검토한 것을 안 고른 것까지 함께 적었다.

A 재시도 늘림      → 함 (2026-04-27)
B 결과 캐시        → 함 (2026-04-30). C 이후 제거 예정
C 화면 구조 변경   → 함 (2026-05-20)
D 다른 공급자 사용 → 안 함. 계약과 규격 변경 필요. 3개월 이상

나중에 다른 공급자는 검토하지 않았느냐는 물음이 나왔을 때 이 기록으로 답했다. 검토했는데 안 고른 것과 아예 생각하지 않은 것은 다르고, 적어 두지 않으면 그 둘이 구분되지 않는다.

각 단계마다 실패율과 화면 오류 건수를 함께 쟀다.

        실패율   화면 오류
전      8%       하루 412건
A 후    2%       하루 102건
B 후    0.2%     하루 8건
C 후    0.2%     하루 0건

마지막 단계에서 실패율은 그대로인데 화면 오류가 0이 됐다. 실패해도 화면이 안 깨지게 한 것이라 그렇다. 두 값을 따로 재지 않았으면 무엇이 좋아졌는지 정확히 말할 수 없었을 것이다.

한편 실패 자체는 상대 쪽 문제였다. 우리가 견디게 만드는 것과 상대가 고치는 것은 다른 일이므로 대응하면서 상대에게도 숫자와 시간대를 정리해 보냈다. 한 달 뒤 그쪽에서 고쳐 실패율이 0.1%가 됐다. 한쪽만 했으면 절반이었다.

순서를 정하고 나서 그 순서를 알렸다. 오늘 재시도로 8%에서 2%까지 낮추고 이번 주에 캐시로 0.2%까지 낮추며 근본 수정은 다음 달이라는 내용이다.

지금 완전히 고쳐지지 않는다는 것을 미리 말한 것이 요점이었다. 말하지 않으면 고쳤다고 들리고 그 뒤에 또 나면 못 고친 것으로 보인다. 단계와 예상 시점을 말해 두니 그 사이에 문의가 와도 그것이 답이 됐다.