응대와 회고 사이: framing의 시간성

1. 세 가지 책임 분포

2026-05-17. 두 달간 처리했던 결제·주문 동기화 실패 세 건을 다시 펼쳤다. 같은 증상 — 결제 완료된 주문이 한쪽에는 있고 한쪽에는 없다 — 인데 책임 분포가 모두 달랐다. 한 일본 머천트의 Konbini 사례는 머천트 측 3PL이 체크아웃 플랫폼의 승인 태그를 인지하지 못한 것이 원인이었고 코드 변경은 일어나지 않았다. 한 디지털 상품 머천트의 결제 실패는 한쪽 사양이 다른쪽 가정을 깨뜨리는 결합 단계의 결함 — 양쪽 코드 fix가 필요했다. 한 화장품 머천트의 Shop Cash 사례는 Shopify의 신규 결제수단을 우리가 미지원해서 결제가 우회된 product gap이었다.

증상이 같다고 응대도 같으면 첫 1시간이 날아간다. 책임 분포를 먼저 식별하는 것이 빠른 응대로 가는 길.

2. 응대 framing과 회고 framing

회상을 paraphrase 하다 알아챈 게 있었다. Shop Cash 사례 50일 전 회신에서 나는 "by-design + 머천트가 Shop Cash 끄기 결정" 으로 framing했다. 50일 뒤 같은 사실을 다시 정리하면서 그건 "product gap + 주문 sync resilience 부족" 으로 한 단계 위로 옮겨졌다. 두 framing은 틀린 것과 맞는 것이 아니었다 — 둘 다 사실이었지만 시점이 달랐다.

응대 시점에는 머천트가 지금 할 수 있는 액션을 가리지 않는 framing이 안전하다. "Shop Cash를 international에서 끄시면 됩니다." 회고 시점에는 왜 그 상황이 만들어졌는지를 추적하는 framing이 가치가 있다. "Shop Cash 환경에서 우리 integration boundary의 product gap." 두 framing이 다른 건 정상이다 — 응대는 다음 액션을 가능하게 하고, 회고는 같은 일이 다시 일어나지 않게 한다. 이 한 줄이 feedback_response_framing_time_value.md로 코드화됐다.

같은 사실에 대한 framing이 시점에 따라 이동한다는 것을 인정하는 게, 첫 응대의 안정성을 해치지 않는다.