일기 항목을 다시 읽을 때 원격 이미지가 다시 로드될까?
일반적으로 이미지 URL이 포함된 일기 항목은 앱이나 브라우저가 해당 항목을 표시할 때 그 이미지를 요청하도록 할 수 있습니다. 하지만 그렇다고 해서 항목을 열 때마다 원격 서버에서 매번 이미지를 새로 다운로드한다는 뜻은 아닙니다. 유효한 브라우저 캐시에서 이미지를 가져올 수도 있고, 앱이 다른 방식으로 이미지를 처리할 수도 있습니다. 가장 먼저 실질적으로 확인해야 할 사항은 해당 항목이 웹 URL을 가리키고 있는지, 아니면 일기와 함께 저장된 이미지를 가리키고 있는지 여부입니다. 오프라인 테스트를 통해 단서를 얻을 수는 있지만, 네트워크 요청이 전혀 발생하지 않았음을 증명할 수는 없습니다.
마크다운의 이미지 링크는 무엇을 의미할까?
표준 마크다운에서 ``과 같은 이미지 문법은 URL을 통해 이미지를 식별합니다. [CommonMark 이미지 튜토리얼](https://commonmark.org/help/tutorial/08-images.html)에서는 완전한 웹 URL이 올바른 이미지 경로임을 명시적으로 보여줍니다. 문법 자체만으로는 이미지가 일기 내부로 복사되었거나 로컬에 저장되었음을 의미하지 않습니다.
리더가 해당 항목을 표시할 때, 소프트웨어는 해당 URL을 이미지 소스로 렌더링할 수 있습니다. 웹 페이지에서는 [MDN의 `<img>` 레퍼런스](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img)에 설명되어 있듯이 브라우저의 `<img>` 요소가 문서에 이미지를 임베드하며, `src` 속성이 표시할 리소스를 식별합니다. 실제로 요청이 원격 서버에 도달하는지 여부는 캐싱 처리 방식과 특정 앱, 브라우저 및 네트워크 경로에 따라 달라집니다.
일기를 읽을 때마다 브라우저가 서버에 접속할까?
매번 이미지를 새로 가져와야 한다는 고정된 규칙은 없습니다. 브라우저는 요청을 보낼 때 HTTP 캐시를 확인합니다. 일치하고 유효한 캐시 응답이 있다면, 브라우저는 해당 이미지에 대해 원본 서버에 접속하지 않고 이를 재사용할 수 있습니다. [web.dev의 HTTP 캐시 가이드](https://web.dev/articles/http-cache)에서는 신선도(freshness)가 응답 캐싱 정보에 따라 달라지며, 캐시된 응답은 신선도가 유지되는 동안 재사용될 수 있다고 설명합니다.
캐시된 응답이 만료(stale)되었거나 유효성 검증(validation)이 필요한 경우, 브라우저는 저장된 사본이 여전히 유효한지 확인하기 위해 서버에 접속할 수 있습니다. 서버가 해당 사본이 여전히 유효함을 확인해주면, 이 검증 과정에서 전체 이미지를 다시 다운로드하지 않아도 됩니다. [MDN의 HTTP 캐싱 가이드](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching)에서는 신선도, 유효성 검증 및 응답을 캐시하지 않아야 하는 경우를 다룹니다. 캐시 삭제, 만료, 변경된 URL, 앱 동작 또는 캐시 설정 모두가 나중에 다시 읽을 때 일어나는 동작을 바꿀 수 있습니다.
따라서 신중하게 답하자면 다음과 같습니다. 원격 이미지를 표시하는 작업은 네트워크 요청으로 이어질 수 있지만, 볼 때마다 이미지 바이트를 매번 전송하거나 원본 서버에 반드시 접속하는 것은 아닙니다. 캐시를 통한 표시와 새로 데이터를 가져온 표시는 화면상에서 완전히 똑같아 보일 수 있습니다.
URL과 저장된 첨부 파일은 어떻게 구분할 수 있을까?
이미지 참조 경로를 살펴보거나, 앱에서 제공하는 경우 첨부 파일 정보를 확인하세요. `https://` 또는 `http://`로 시작하는 경로는 원격 웹 주소를 가리킵니다. 상대 경로나 앱 전용 첨부 파일 이름의 경우 추가 확인이 필요합니다. 웹 페이지에서 상대 경로는 다른 웹 주소로 해석될 수 있으므로, 해당 파일이 기기 로컬에 존재함을 증명하지는 않습니다. 일기 앱의 저장 및 렌더링 규칙이 최종 대상을 결정합니다. 마크다운 문법 자체만으로는 로컬처럼 보이는 참조가 다른 기기로 이동 가능한지(portable) 혹은 파일이 항목 내부에 저장되어 있는지 보장하지 않습니다.
유용한 구분 기준은 무엇이 계속 유지되어야 하는가입니다. 원격 URL은 원격 리소스가 계속 존재하고 접근 가능해야 유지되며, 로컬 첨부 파일은 앱이 예상하는 위치에 관련 파일이 존재해야 유지됩니다. 일기 사진 파일을 보존하려면 앱 자체의 내보내기 또는 백업 지침을 따르세요. 이 글의 초점은 원격 로딩이라는 별도의 문제에 있으며, 특정 앱의 저장 방식을 보장하는 것은 아닙니다.
오프라인 비교 테스트로 무엇을 확인할 수 있을까?
안전한 확인을 위해 민감하지 않은 이미지 URL을 임시 테스트 항목에 넣어보세요. 온라인 상태에서 해당 항목을 본 다음, 기기의 네트워크 연결을 끊고 항목을 다시 열어보세요. 오프라인 상태에서도 이미지가 표시된다면 캐시된 사본이나 다른 로컬 사본을 사용할 수 있는 상태와 부합합니다. 이미지가 나타나지 않는다면 앱이 해당 시점에 원격 리소스를 필요로 할 수 있지만, 그 결과 자체만으로 정확한 원인을 알 수는 없습니다.
이러한 비교 테스트가 일반적인 온라인 읽기 상태에서 네트워크 요청이 발생하지 않는다는 사실을 증명하지는 못합니다. 연결이 끊기기 전에 브라우저가 요청을 이미 마쳤거나, 서비스 워커나 애플리케이션 캐시를 확인했거나, 이미 로컬에 저장된 이미지를 표시했을 수 있습니다. 마찬가지로 오프라인에서 이미지가 보인다고 해서 해당 항목의 마크다운에 첨부 파일이 포함되어 있음을 증명하는 것은 아닙니다. 앱이 원격 응답을 캐시해 두었을 수도 있기 때문입니다. 브라우저 기반 일기의 경우, 온라인 상태에서 브라우저의 네트워크 개발자 도구를 사용하여 요청 동작을 관찰하고 이미지 요청 및 캐시 상태를 확인해 보세요. 그 결과는 해당 테스트 환경을 설명할 뿐, 이후의 모든 읽기 작업이나 다른 기기에서의 동작까지 설명하지는 않습니다.
실용 체크리스트
항상 예측 가능한 방식으로 표시되어야 하는 항목의 경우, 이미지 참조를 확인한 다음 로컬에 있어야 하는 이미지라면 해당 로컬 첨부 파일이 존재하는지 확인하세요. 원격 URL인 경우 가용성과 업데이트 동작은 호스트 및 캐싱 설정에 따라 달라질 수 있음을 염두에 두어야 합니다. 온라인 상태의 네트워크 패널을 사용해 요청을 관찰하고, 오프라인에서 다시 열어보는 방식을 제한적인 비교 수단으로 활용하세요. 각 결과는 테스트한 앱, 브라우저 및 캐시 상태에 대한 단서로만 취급해야 하며, 절대적인 보장으로 여겨서는 안 됩니다.