객체(object)에서 iframe까지 — 일반적인 임베딩 기술들
임베딩의 짧은 역사
아주 오래전 웹에서는 웹사이트를 만들 때 프레임(frames)을 사용하는 게 유행이었어요. 웹사이트의 작은 부분들을 개별 HTML 페이지로 쪼개어 저장한 다음, 이것들을 프레임셋(frameset)이라는 마스터 문서 안에 임베딩하는 방식이었죠. 테이블의 열과 행 크기를 조절하듯이 화면에서 각 프레임이 차지하는 영역을 지정할 수 있었습니다. 90년대 중후반에는 이게 엄청 멋진 기술로 통했고, 당시에는 네트워크 속도가 너무 느렸기 때문에 웹페이지를 이렇게 작은 덩어리로 쪼개는 것이 다운로드 속도 측면에서 더 낫다는 시각도 있었어요. 하지만 네트워크 속도가 점점 빨라지면서 장점보다는 단점이 훨씬 많아졌고, 결국 지금은 아무도 이 방식을 쓰지 않게 되었습니다.
조금 더 시간이 지나서(90년대 후반~2000년대 초반), Java Applet이나 Flash 같은 플러그인 기술이 엄청난 인기를 끌었습니다. 이 기술들 덕분에 웹 개발자들은 오직 HTML만으로는 불가능했던 화려한 비디오나 애니메이션 같은 풍부한 콘텐츠를 웹페이지에 넣을 수 있었죠. 이런 기술들을 임베딩할 때 바로 <object> 요소나 (조금 덜 쓰이던) <embed> 요소가 사용되었고, 당시에는 정말 유용했습니다. 하지만 지금은 웹 접근성, 보안, 파일 크기 등 수많은 문제 때문에 완전히 유행이 지났어요. 오늘날 주요 브라우저들은 Flash 같은 플러그인 지원을 아예 중단했습니다.
💡 강사의 팁: > 요즘 프론트엔드 면접에서 웹 접근성이나 웹 표준에 대해 물어볼 때, 과거의 Flash나 프레임 방식이 왜 웹 표준에서 도태되었는지(스크린 리더기가 읽지 못하는 문제, 보안 취약점 등)를 언급하시면 아주 깊이 있는 인상을 줄 수 있습니다. 면접 준비하실 때 꼭 챙겨두세요!
마지막으로 나타난 것이 바로 <iframe> 요소입니다. (이 외에도 콘텐츠를 삽입하는 <canvas>나 <video> 같은 요소들도 함께 등장했죠). iframe은 마치 이미지를 넣는 <img> 요소처럼, 아예 통째로 완성된 다른 웹 문서를 현재 문서 안에 집어넣을 수 있는 방법을 제공합니다. 그리고 오늘날에도 아주 활발히 쓰이고 있답니다.
자, 역사 수업은 이쯤 해두고, 직접 실습해보면서 이것들을 어떻게 사용하는지 알아볼까요?
고전적인 임베딩 기술 써보기
이 글에서는 임베딩 기술이 어디에 쓰이는지 바로 감을 잡으실 수 있도록 거두절미하고 실습부터 해볼게요! 온라인 세상에서 YouTube는 아주 친숙한 서비스이지만, 유튜브가 제공하는 공유 기능들을 100% 알고 계신 분들은 생각보다 많지 않아요.
- 먼저 MDN Playground를 열어주세요.
- 이제 유튜브에서
<iframe>을 이용해 우리가 원하는 어떤 페이지에든 비디오를 넣을 수 있게 해주는 방법을 알아볼 거예요.- 유튜브에 접속해서 마음에 드는 영상을 하나 찾아주세요.
- 영상 아래쪽을 보면 공유(Share) 버튼이 있습니다. 이걸 누르면 여러 공유 옵션이 나와요.
- 거기서 퍼가기(Embed) 버튼을 선택하면
<iframe>코드가 나타납니다. 이 코드를 복사하세요. - 열어둔 Playground의 HTML 입력 창에 복사한 코드를 붙여넣고, 출력 화면에 어떤 결과가 나오는지 확인해 보세요!
- 보너스 실습으로, Google Map을 Playground에 임베딩해 보는 것도 좋습니다.
- 구글 지도에 접속해서 원하는 장소의 지도를 찾으세요.
- 화면 왼쪽 위의 "햄버거 메뉴(가로줄 3개 아이콘)"를 클릭하세요.
- 지도 공유 또는 퍼가기(Share or embed map) 옵션을 선택하세요.
- 지도 퍼가기(Embed a map) 탭을 누르면
<iframe>코드가 나옵니다. 복사해주세요. - 마찬가지로 Playground의 HTML 창에 붙여넣고 결과를 확인해 보세요.
실수하더라도 괜찮아요! Playground에 있는 Reset(초기화) 버튼을 누르면 언제든 처음 상태로 되돌릴 수 있습니다.
💡 강사의 팁: > React.js나 Next.js 환경에서 유튜브나 지도 iframe을 넣을 때는 가로 길이를 고정하기보다는 CSS로
width: 100%같은 반응형 처리를 해주거나, 부모 컨테이너의 비율에 맞춰 줄어들게(aspect-ratio 활용) 만드는 것이 모던 프론트엔드 개발의 핵심입니다.
iframe 자세히 알아보기
어때요, 생각보다 쉽고 재밌죠? <iframe> 요소는 현재 문서 안에 다른 웹 문서를 임베딩할 수 있도록 설계되었어요. 이 기능은 내가 직접 관리할 수 없거나, 굳이 내 손으로 똑같이 구현하고 싶지 않은 '서드파티(Third-party) 콘텐츠'를 내 웹사이트에 가져다 붙일 때 아주 훌륭합니다. 예를 들면 외부 비디오 플랫폼의 영상, Disqus 같은 댓글 시스템, 온라인 지도, 광고 배너 등이 있죠. 심지어 여러분이 이 코스에서 사용하고 있는 실시간 코드 편집기(Playground)조차도 내부는 <iframe>으로 구현되어 있답니다!
하지만 <iframe> 요소를 본격적으로 사용하기 전에, 반드시 알아두어야 할 몇 가지 보안 문제가 있습니다.
예를 들어, 여러분의 웹페이지 중 한 곳에 <iframe>을 사용해서 MDN 용어 사전(Glossary) 페이지를 넣고 싶다고 해볼게요. 아마 아래와 같은 코드를 작성하게 될 겁니다.
그런데 이 코드를 페이지에 넣고 나면, 용어 사전 페이지가 짠 하고 나타나는 대신 에러 메시지가 떠서 깜짝 놀라실 수도 있어요.
<iframe
src="https://developer.mozilla.org/en-US/docs/Glossary"
width="100%"
height="500"
allowfullscreen
sandbox>
</iframe>iframe {
border: none;
}여러분의 브라우저 개발자 도구 콘솔을 열어보시면, 대략 이런 에러 메시지가 보일 거예요:
Refused to display 'https://developer.mozilla.org/' in a frame because it set 'X-Frame-Options' to 'deny'.왜 이런 에러가 발생하는지는 아래의 보안(Security) 섹션에서 자세히 다루겠지만, 우선 우리 코드가 어떤 역할을 하고 있는지부터 짚고 넘어갑시다.
위 예제 코드는 <iframe>을 사용하는 데 필요한 아주 핵심적인 요소들만 담고 있어요:
border: none
이 CSS를 사용하면<iframe>주변에 테두리가 없이 깔끔하게 표시됩니다. 이걸 지우지 않으면 브라우저는 기본적으로<iframe>주변에 촌스러운 테두리를 그려버리거든요.allowfullscreen
이 속성을 추가하면, 포함된<iframe>이 Fullscreen API를 사용해 전체화면 모드로 전환될 수 있는 권한을 얻습니다 (API 자체는 이 글의 범위를 조금 벗어나지만요).src
<video>나<img>요소와 마찬가지로, 삽입할 대상 문서의 URL 경로를 적어주는 속성입니다.width와height
iframe이 화면에서 차지할 가로와 세로 크기를 지정합니다.sandbox
비교적 최신 브라우저(IE 10 이상 등)에서 작동하는 속성으로, iframe 내부에 강력한 보안 제한을 걸어줍니다. 다음 섹션에서 더 자세히 알아볼게요.
📝 참고하세요:
페이지 로딩 속도를 높이려면, 메인 콘텐츠가 모두 로드된 이후에 JavaScript를 사용해서 iframe의src속성을 할당해 주는 것이 좋은 전략입니다. 이렇게 하면 사용자가 페이지를 더 빨리 조작할 수 있게 되고, 공식적인 페이지 로드 시간도 단축됩니다. (이는 SEO(검색엔진 최적화) 측면에서도 아주 중요한 지표입니다.)
💡 강사의 팁:
이 '지연 로딩(Lazy Loading)' 개념은 성능 최적화 관련 기술 면접에서 아주 자주 묻는 단골 질문입니다! JavaScript로 조작하는 방법도 좋지만, 최근에는 간단히 태그 안에loading="lazy"라는 속성을 추가하는 것만으로 브라우저가 알아서 화면에 보일 때쯤 로딩하도록 처리해준답니다.
보안 문제 (Security concerns)
위에서 보안에 대한 우려를 잠깐 언급했었죠. 이제 좀 더 자세히 파헤쳐 볼까요? 지금 당장 이 모든 내용을 완벽히 외워야 하는 건 아닙니다. 그저 "이런 위험성이 있구나" 하고 인지해 두셨다가, 나중에 경험이 쌓이고 프로젝트에 <iframe>을 적극적으로 쓰게 될 때 다시 돌아와서 참고하시면 됩니다. 겁먹고 <iframe>을 피할 필요는 전혀 없어요. 조심해서 다루기만 하면 되니까요. 자, 계속 읽어주세요!
브라우저 제작자들과 웹 개발자들은 수많은 시행착오를 통해, <iframe>이 웹의 나쁜 사람들(흔히 해커, 더 정확히는 크래커)에게 아주 좋은 먹잇감(공식 용어로는 공격 벡터(attack vector))이 된다는 사실을 뼈저리게 배웠습니다. 공격자들은 여러분의 웹페이지를 악의적으로 조작하거나, 사용자가 원치 않는 행동을 하도록 속여서 아이디와 비밀번호 같은 민감한 정보를 빼내려 할 때 iframe을 악용하곤 하죠. 이 때문에 스펙(표준) 설계자들과 브라우저 개발자들은 <iframe>을 더 안전하게 지키기 위한 다양한 보안 메커니즘을 만들어 냈고, 웹 개발자들이 지켜야 할 모범 사례들도 정립되었습니다. 아래에서 그중 몇 가지를 살펴볼게요.
📝 참고하세요:
클릭재킹(Clickjacking)은 가장 흔한 iframe 공격 방식 중 하나입니다. 해커가 여러분의 문서 위에 눈에 보이지 않는 투명한 iframe을 겹쳐 놓거나(혹은 해커의 악성 사이트에 여러분의 문서를 임베딩해서) 사용자의 클릭 등 상호작용을 몰래 가로채는 수법이에요. 사용자를 속이거나 민감한 데이터를 훔칠 때 아주 자주 쓰입니다.
일단 앞서 보여드렸던 예제를 다시 확인해 볼까요? 이 코드를 여러분의 브라우저에서 실행해 보세요. — GitHub에 올라와 있는 라이브 페이지를 보셔도 되고 (소스 코드도 확인할 수 있습니다). 아마 여러분이 기대했던 MDN 페이지 대신 "이 페이지를 열 수 없습니다"와 비슷한 뉘앙스의 화면이 보일 거예요. 브라우저 개발자 도구의 Console(콘솔) 탭을 열어보면 그 이유를 정확히 알려주는 메시지가 떠 있습니다. 파이어폭스의 경우 "X-Frame-Options 지시자가 'DENY'로 설정되어 있어 'https://developer.mozilla.org/en-US/docs/Glossary'를 프레임에서 로딩하는 것이 거부되었습니다" 라는 식으로 알려주죠.
이것은 MDN을 구축한 개발자들이 자신의 웹사이트 페이지를 서비스하는 서버에 "우리 사이트가 <iframe> 안에 임베딩되는 것을 허락하지 않겠다"라는 설정을 명시해 두었기 때문입니다 (아래의 CSP 지시자 구성하기를 참고하세요). 생각해보면 아주 당연한 조치입니다. 다른 사람이 MDN 페이지 전체를 가져다 자기 사이트에 띄워놓고 마치 자기 것인 양 행세하거나, 앞서 말한 클릭재킹으로 사용자 데이터를 훔치려고 한다면 정말 끔찍한 일일 테니까요. 게다가 전 세계 사람들이 무단으로 MDN을 iframe으로 퍼가면, 거기서 발생하는 트래픽 비용을 모질라(Mozilla)가 전부 감당해야 할 텐데 그 돈이 어마어마할 겁니다.
꼭 필요할 때만 임베딩하기 (Only embed when necessary)
유튜브 비디오나 지도처럼 서드파티 콘텐츠를 가져다 쓰는 것이 타당할 때도 있지만, 정말 꼭 필요한 상황에서만 외부 콘텐츠를 임베딩하면 나중에 겪을 많은 골칫거리들을 미리 예방할 수 있습니다. 웹 보안에서 명심해야 할 황금률이 하나 있어요. "아무리 조심해도 지나치지 않다. 내가 만든 것도 다시 한번 확인해라. 다른 사람이 만든 것이라면, 그것이 안전하다고 완벽히 증명되기 전까지는 일단 무조건 위험하다고 가정해라."
보안 문제 외에도, 지적 재산권(저작권) 이슈 역시 주의해야 합니다. 오프라인이든 온라인이든 대부분의 콘텐츠에는 저작권이 있습니다. 심지어 Wikimedia Commons에 있는 무료 같아 보이는 이미지들조차 규칙이 있죠. 여러분이 소유한 콘텐츠이거나 저작권자가 명확하게 서면으로 허락하지 않은 이상, 절대로 남의 콘텐츠를 웹페이지에 무단으로 띄우지 마세요. 저작권 침해에 대한 처벌은 생각보다 매우 무겁습니다. 다시 한번 강조하지만, 조심해서 나쁠 건 없습니다.
라이선스가 있는 콘텐츠라면, 반드시 그 라이선스 조항을 따라야 합니다. 예를 들어, MDN의 콘텐츠는 CC-BY-SA 라이선스를 따릅니다. 이 말은, 저희 콘텐츠를 인용할 때는 내용에 큰 수정을 가하더라도 반드시 적절한 출처 표시(크레딧)를 해야 한다는 뜻입니다.
HTTPS 사용하기 (Use HTTPS)
HTTPS는 기존 HTTP의 암호화된 안전한 버전입니다. 여러분은 가능하면 항상 웹사이트를 HTTPS 환경에서 서비스해야 합니다:
1. HTTPS는 외부 콘텐츠가 내 사이트로 전송되는 과정 중간에 누군가에 의해 변조될 가능성을 크게 줄여줍니다.
2. HTTPS는 임베딩된 콘텐츠가 부모 문서(여러분의 사이트)의 내용을 몰래 들여다보는 것을 막아주고, 그 반대의 경우도 막아줍니다.
웹사이트에 HTTPS를 적용하려면 특수한 보안 인증서를 설치해야 합니다. 요즘 많은 호스팅 업체들은 사용자가 직접 복잡한 설정을 할 필요 없이 기본적으로 HTTPS를 지원하는 호스팅을 제공합니다. 하지만 만약 웹사이트에 HTTPS를 직접 설정해야 하는 상황이라면, Let's Encrypt라는 서비스를 이용해 보세요. Apache나 Nginx 등 널리 쓰이는 웹 서버에 맞게 인증서를 자동으로 생성하고 설치해 주는 도구와 가이드를 제공합니다. 과정을 최대한 쉽게 만들었으니, HTTPS 적용을 미룰 핑계는 더 이상 없습니다!
📝 참고하세요:
GitHub Pages를 사용하면 기본적으로 HTTPS를 통해 콘텐츠가 서비스됩니다. 만약 다른 호스팅 업체를 쓰신다면 HTTPS 서비스를 어떻게 지원하는지 꼭 확인해 보세요.
💡 강사의 팁: > 취업을 위한 개인 포트폴리오를 배포하실 때 Vercel이나 Netlify, GitHub Pages 등을 많이 쓰시죠? 이런 모던 배포 플랫폼들은 알아서 HTTPS를 적용해 주니까 너무 걱정하지 않으셔도 됩니다.
항상 sandbox 속성 사용하기 (Always use the sandbox attribute)
해커들이 여러분의 웹사이트에서 나쁜 짓을 할 수 있는 힘(권한)을 최대한 빼앗아야 합니다. 그렇기 때문에 임베딩된 콘텐츠에게는 그 콘텐츠가 제 역할을 수행하는 데 필요한 딱 그만큼의 권한만 부여해야 합니다. (당연히 이 규칙은 여러분이 직접 작성한 코드에도 동일하게 적용되어야 해요). 어떤 코드가 정상적으로 작동하거나 테스트될 수는 있으면서도, 시스템의 다른 코드베이스에는 (실수든 고의든) 아무런 피해를 줄 수 없도록 격리해 둔 공간을 컴퓨터 보안 용어로 샌드박스(Sandbox)라고 부릅니다.
샌드박스 처리가 되지 않은 외부 콘텐츠는 여러분의 사이트에서 마음대로 자바스크립트를 실행하거나, 폼(form) 데이터를 마음대로 제출하거나, 귀찮은 팝업창을 마구 띄울 수 있습니다. 이런 사고를 막기 위해, 기본적으로는 방금 전 예제에서 본 것처럼 매개변수를 아무것도 넣지 않은 sandbox 속성을 사용하여 적용 가능한 모든 보안 제한을 꽉꽉 걸어두는 것이 좋습니다.
만약 외부 콘텐츠가 정상 작동하기 위해 정말 어쩔 수 없이 특정 권한이 필요하다면, sandbox="" 속성의 따옴표 안에 권한을 하나씩 추가해 줄 수 있습니다. 사용 가능한 모든 옵션은 sandbox 레퍼런스 문서를 참고하세요.
여기서 아주 중요한 경고가 하나 있습니다! 절대로 allow-scripts와 allow-same-origin 권한을 동시에 추가하지 마세요. 이 두 개를 같이 넣어주면, 임베딩된 악성 콘텐츠가 외부 사이트 스크립트 실행을 막는 동일 출처 정책(Same-origin policy)을 가뿐히 우회하고, 자바스크립트를 이용해 자신이 갇혀있던 샌드박스 자체를 아예 꺼버릴 수 있습니다!
📝 참고하세요:
샌드박스는 해커가 사용자들을 속여 악성 콘텐츠가 있는 페이지로 직접 접속하게 만드는 상황(iframe외부에서의 접근)에서는 아무런 방어막이 되어주지 못합니다. 사용자가 올린 게시물(UGC)처럼 콘텐츠에 악의적인 코드가 숨어있을 가능성이 단 1%라도 있다면, 그 콘텐츠는 메인 사이트와 분리된 다른 도메인(domain)에서 서비스하는 것이 안전합니다.
CSP 지시자 구성하기 (Configure CSP directives)
CSP는 콘텐츠 보안 정책(Content Security Policy)의 약자입니다. HTML 문서의 보안을 한층 더 끌어올리기 위해 디자인된 HTTP 헤더 세트(웹 서버에서 웹 페이지를 보낼 때 함께 딸려 가는 메타데이터)를 제공하죠. <iframe>을 안전하게 보호하는 관점에서는, 여러분의 서버가 적절한 X-Frame-Options 헤더를 보내도록 설정할 수 있습니다.
이렇게 설정하면 다른 누군가가 허락 없이 여러분의 웹페이지 콘텐츠를 자신들의 웹페이지에 임베딩하는 것을 원천 차단할 수 있습니다. (임베딩을 허용하면 클릭재킹을 비롯한 온갖 골치 아픈 공격에 노출되거든요). 우리가 앞서 에러 화면을 통해 확인했듯이, 이 설정이 바로 MDN 개발자들이 자신들의 문서를 지키기 위해 적용한 방법입니다.
📝 참고하세요:
이 주제에 대해 조금 더 깊은 배경 지식이 궁금하다면 Frederik Braun이 쓴 On the X-Frame-Options Security Header (X-Frame-Options 보안 헤더에 대하여) 포스트를 읽어보세요. 이 글에서 모든 걸 다 설명하기엔 내용이 너무 깊어지니까요.
<embed>와 <object> 요소
<embed>와 <object> 요소는 <iframe>과는 역할이 조금 다릅니다. 이 요소들은 PDF 파일 같은 외부 콘텐츠를 임베딩하기 위해 만들어진 다목적(범용) 임베딩 도구라고 보시면 됩니다.
하지만 현대 웹 개발에서 여러분이 이 두 요소를 마주칠 일은 거의 없을 겁니다. 만약 웹페이지에서 PDF 문서를 보여줘야 한다면, 굳이 페이지 한구석에 끼워 넣는(임베딩하는) 것보다는 그냥 사용자가 클릭해서 열어볼 수 있도록 링크를 제공하는 편이 훨씬 낫거든요.
역사적으로 이 요소들은 Adobe Flash 같은 브라우저 플러그인(Plugin)이 처리해야 하는 콘텐츠를 집어넣을 때 주로 사용되었습니다. 하지만 거듭 말씀드리듯 플러그인 기술은 이제 완전히 수명을 다했고, 최신 브라우저들은 이를 더 이상 지원하지 않습니다.
혹시라도 낡은 레거시 환경에서 플러그인 콘텐츠를 임베딩해야 할 일이 생긴다면, 최소한 아래와 같은 정보들을 설정해 주어야 합니다:
<embed> | <object> | |
|---|---|---|
| 임베딩할 콘텐츠의 URL | src | data |
| 임베딩할 콘텐츠의 정확한 미디어 타입(MIME type) | type | type |
| 플러그인이 통제할 박스 영역의 높이와 너비 (CSS 픽셀 단위) | heightwidth | heightwidth |
| 해당 리소스를 불러올 수 없을 때 보여줄 대체(fallback) HTML 콘텐츠 | 지원하지 않음 (<noembed>는 더 이상 안 씀) | <object> 태그를 열고 닫는 부분 사이에 내용을 넣음 |
자, 그럼 PDF를 웹페이지에 임베딩하는 <object> 예제를 하나 살펴볼까요? (라이브 예제 보기 / 소스 코드 보기):
<object data="my-pdf.pdf" type="application/pdf" width="800" height="1200">
<p>
You don't have a PDF plugin, but you can
<a href="my-pdf.pdf">download the PDF file. </a>
</p>
</object>종이 문서의 시대에서 완전한 디지털 시대로 넘어가는 과정에서 PDF는 꼭 필요한 징검다리였습니다. 하지만 PDF는 웹 접근성 측면에서 수많은 챌린지(어려움)를 안고 있고, 스마트폰처럼 작은 화면에서는 읽기가 고역입니다. 특정 업계나 분야에서는 여전히 PDF를 즐겨 쓰긴 하지만, 웹페이지 안에 억지로 우겨넣기보다는 링크를 걸어서 사용자가 다운로드받거나 별도의 뷰어 페이지에서 읽을 수 있게 해주는 것이 훨씬 더 나은 선택입니다.
💡 강사의 팁: > 최근 프론트엔드 개발에서는
접근성(Accessibility, a11y)이 정말 중요합니다. 스크린 리더기를 사용하는 시각장애인 분들을 위해서라도, 정보를 PDF로 툭 던져주기보다는 의미에 맞는 시맨틱 HTML 태그(Semantic Tags)로 잘 짜인 텍스트로 풀어내는 습관을 들이시면 면접관에게 훌륭한 개발자라는 인상을 줄 수 있습니다. Figma로 디자인하실 때부터 이런 접근성 요소를 챙겨두면 더 완벽하겠죠!
