"세상에서 가장 깨끗한 설계가 4년 묵은 플랫폼 버그한테 져. 플랫폼이 안 된다고 하면, 논쟁 안 해 — 실제로 열린 문을 찾아."
됐어야 할 계획
깨끗한 설계는 어디나 push 였어: 플러그인에서 backend 로 secure WebSocket, 작업실에서 backend 로 secure WebSocket, 전반에 걸친 실시간 양방향 메시징. WebSocket 은 라이브하고, 밀고, 저-latency 인 통신에 옳은 도구고, 아키텍처가 우아했어. 그러더니 플러그인의 outbound secure WebSocket 이 그냥 연결 안 됐어 — 대상 운영체제에서, 조용히 실패했어, server 쪽 연결 시도도 없고 쓸모 있는 에러도 없이.
진단: 너 아니라 플랫폼이야
spike 가 원인을 격리했어: 그 OS 의 플러그인 sandbox 가 outbound secure WebSocket 연결을 완전히 거부해, 앱 통제 아래 레이어에서. 코드 버그도, 틀린 flag 도, 빠진 permission 도 아니었어 — 수년 열려 있던 vendor issue 에 문서화된, 오래된, 여전히 열린 플랫폼 레벨 결함이었어. 어떤 똑똑한 클라이언트 코드도 그걸 못 고쳐, 실패가 어떤 클라이언트 코드도 닿을 수 있는 데보다 아래서 일어나니까.
열려 있던 문
같은 spike 가 통하는 길을 확인했어: 플러그인의 secure WebSocket 이 막힌 동안, 플러그인의 HTTPS 요청은 완벽하게 정상 작동했어. 그래서 플러그인이랑 backend 사이 bridge 가 WebSocket 에서 떠나 HTTPS request/response 로 옮겨갔어. 플러그인이 capture 랑 상태를 backend 로 POST 하고; backend-to-플러그인 메시지엔, 플러그인이 backend 가 command 가 있는 순간 답하는 long-poll 요청을 열어둬. 그게 plain request/response 배관 위로 push 같은 전달을 보존해.
uniform 아니라 hybrid
결과가 의도적으로 비대칭이야: 플러그인-to-backend 링크는 HTTPS(거기선 그게 되니까)고, 작업실-to-backend 링크는 secure WebSocket 으로 남아(거기선 그게 잘 되니까). 두 링크, 두 transport, 각자 하나의 uniform 답으로 강제되는 대신 자기 실제 환경에 골라짐. 깔끔함 위해 모든 걸 같은 transport 로 만들고 싶은 유혹이 환경이 진짜로 다를 때 정확히 틀린 본능이야.
미래를 위해 문에 표시 남겨
마지막 규율 하나: workaround 가 특정 플랫폼 버그에 묶여, spike 재실행 없이 막힌 transport 를 재도입 말라는 노트와 함께, workaround 로 문서화돼. 버그가 미래 플랫폼 릴리스에서 고쳐질 수도 있어 — 그러면, hybrid 가 왜 존재하는지랑 도로 단순화할 수 있는지 어떻게 테스트하는지 정확히 알고 싶어. 왜 존재하는지 기억 없는 workaround 는 아무도 감히 안 건드리는 영구 cruft 가 돼.