인터넷 임시파일과 갱신에 대한 미확인 추측

그냥 추론해보고 있는데요. 프록시 환경이라 그렇다고 알고 있는데 다른 원인도 있나 싶네요. 가끔 테마 제작후 변경사항이 바로 화면에 안뜰때가 있죠. 이 경우 웹브라우저에서 저장한 인터넷 임시파일 지우고 쿠키도 지우라고 하는데 워프의 경우 transient 관련 DB 설정도 비워줘야 하고 페이지나 포스트 캐시도 지워야 하는데요.

개발적으로 안들여다봤지만, HTTP/2 구현을 위해 만든 매커니즘이 처리의 복잡도가 높아지고 여러 설정이나 구현들이 중첩되면 서로 상충되어 예기치 못한 오류가 나서 화면 갱신이 안되는게 아닌가 판단이 될때가 있네요. HTTP/2 뿐아니라 웹브라우저 구현 방식, HTML이나 CSS, 자바스크립트, PHP 등의 복잡다단한 소스코드 상태 등등이 기본적으로 문제 없이 작동하게 된게 모종의 이유로 혼돈 상태까지도 이어지네요.

breeze 같은 워프 플러그인은 따로 웹브라우저의 캐싱 기능에 책임을 부여할 것인지 결정하는 메뉴 항목도 있구요. 이런 옵션이 있다는 것은 구현체들간의 조합에 의해서 있는 예기치 못한 문제가 있다는 것을 개발자들도 인지하는 경우가 있다는 것이구요. 문서들은 기술적이라 신뢰가능한데 이경우 포괄적인 기준을 잘 배치해서 논리적이면 옳다고 여겨지기도 하죠. 이 포괄적인 것이 매커니즘 처리의 복잡도가 높아지고 여러 설정이나 구현들이 중첩되면 서로 상충되어 오류가 나기도 하는 것 같습니다. 논리를 이탈하는 현상이 연이어 일어나면 개발자들도 표현고르기가 애매하고 중첩된 상태에 따라서는 딱 잘라 말하는게 오히려 틀리게 되는 경우가 있네요.

여러 단의 설정이 필요하겠지만 HTTP/2 책을 참고하다보니 빠른 페이지 갱신을 위해 연결 통로를 우선 주목해서 HTML 수준에서 해결법의 하나가 되는 태그 지정 방법도 설명하던데요. PC가 복잡다단화되면서 여러 매커니즘과 구현들이 중첩되면 이역시도 시도해보는 선에서 그치기도 할때가 있는 것 같애요. 방법을 고안해서 해내도 해결된 문제가 슬그머니 다시 일으켜지기도 하고…

여기에 오픈소스 체제로 만든 소프트웨어면 즉시 패치를 해도 그 패치가 예기치 못한 작동을 보이기도 한다거나… 등등.

제작사가 아주 잘 포착해서 해법을 내놓아도 다른 구현들과 조합이 완전하게 일치가 안되는 등등.

제 경우 프록시 환경에서 인터넷을 해서 이것도 영향주는 것 같애요. 테마 제작할때 로컬이 아니면 이상작동이 되면서 고치는 것이 불가능할때도 있구요. 쿠키 구현인지 HTTP/2 관련 prefetch 문제인지, 네이버 카페 게시판도 조회수 업데이트가 세번이상 리프레싱해야 되기도 하네요. 물론 이 리프레싱 필요한 현상은 그 순간만 놓고 보면 동시간대에 활동하는 회원분들이, 제가 웹브라우저 세번 리프레싱할때 글을 그 타이밍에 읽으셔서 그런지는 미상. IT 현상도 패턴적이라, 정확하게 측정안하면 패턴이 유사할때 판단이 그르쳐지네요.

특수한 조건에서는 메모리 인젝션이나 고약하게 여러 문제가 중첩되어 문제의 원인은 대략 짐작해도 해결법을 고안하는게 이행안함 상태가 되기도 하네요.

오랜 옛날에는 제작 업체에서 보수적으로 제작과 패치를 하고 표준을 정했는데 요즘은 보다 더 급진적으로 하도록 된 기분도 듭니다.

잡담을 주절대봅니다. 문제 유형이나 해법을 논의하려면 다시 관련 문헌을 봐야 하는데 이번 글은 추측에 기반했습니다. 이유있는 추측이네요. 알려진대로 사고해서 조치하다보면 헛수고가 되는 기분도 드는게 임시파일 삭제와 갱신 문제 같애요.