rel=noopener, noreferrer, nofollow가 실제로 하는 일
브라우저 보안, 리퍼러 개인정보 보호, 검색 엔진 신호라는 서로 매우 다른 역할을 하는 세 가지 작은 링크 속성입니다.
목차
- 짧게 요약하면
- rel=noopener는 reverse tabnabbing을 방지합니다
- noopener가 SEO에 영향을 주나요?
- rel=noreferrer는 참조한 페이지를 숨깁니다
- noreferrer가 유용한 경우
- 분석상의 트레이드오프
- rel=nofollow는 검색 엔진을 위한 것이지 브라우저를 위한 것이 아닙니다
- nofollow를 사용해야 하는 경우
- nofollow가 하지 않는 일
- 일반적인 조합
- 새 탭에서 열리는 외부 링크
- 유료 게재
- User-generated link
- 내부 링크
- 팀을 위한 실용적인 정책
- 실제 동작을 테스트하는 방법
- 결론
짧게 요약하면
링크의 rel 속성은 현재 페이지와 링크된 페이지 사이의 관계를 설명합니다. 추상적으로 들리지만, 일상적인 웹 작업에서는 세 가지 값이 끊임없이 등장합니다.
<a href="https://example.com" target="_blank" rel="noopener noreferrer nofollow">
External resource
</a>
이 세 토큰은 마치 하나의 일을 하는 것처럼 함께 붙여 넣어지는 경우가 많습니다. 하지만 그렇지 않습니다.
noopener는 브라우저 보안 제어입니다.noreferrer는 개인정보 보호 및 분석 제어입니다.nofollow는 검색 엔진 신호입니다.
함께 사용할 수는 있지만, 각 값이 왜 들어가는지 알고 있어야 합니다. 모든 외부 링크에 세 가지를 모두 추가하는 것이 항상 틀린 것은 아니지만, 대개는 게으른 방식입니다.
rel=noopener는 reverse tabnabbing을 방지합니다
rel="noopener"는 새로 열린 페이지가 window.opener를 통해 원래 페이지에 접근하지 못하도록 브라우저에 지시합니다.
이는 주로 target="_blank"를 사용해 링크를 새 탭이나 새 창으로 열 때 중요합니다.
<a href="https://external.example" target="_blank" rel="noopener">
Open external site
</a>
noopener가 없으면 대상 페이지가 다음과 같은 JavaScript를 실행할 수 있습니다.
window.opener.location = 'https://phishing.example';
이 공격은 일반적으로 reverse tabnabbing이라고 불립니다. 사용자가 정상적인 링크를 클릭해 다른 사이트로 이동한 뒤, 원래 탭이 조용히 가짜 로그인 페이지나 다른 악성 목적지로 이동되는 방식입니다.
최신 브라우저는 이 부분을 개선했습니다. 현재 브라우저 동작에서는 target="_blank"가 일반적으로 rel="noopener"가 있는 것처럼 처리됩니다. 좋은 변화지만, 명시적인 속성이 무의미해지는 것은 아닙니다. 명시적인 noopener는 여전히 유용합니다.
- 의도를 문서화합니다.
- 오래되었거나 특이한 브라우징 환경을 보호합니다.
- 모든 임베디드 web view가 최신 데스크톱 브라우저처럼 동작한다고 가정하지 않게 합니다.
- 코드 리뷰를 더 쉽게 만듭니다.
새 탭에서 열리는 외부 링크에는 rel="noopener"를 기본값으로 사용하는 것이 합리적입니다.
noopener가 SEO에 영향을 주나요?
아니요. 의미 있는 방식으로는 영향을 주지 않습니다. noopener는 브라우저 동작을 위한 것입니다. 검색 엔진에 어떤 페이지를 추천하는지, 링크 자산을 전달해야 하는지, 링크가 유료인지 알려주지 않습니다.
SEO 정책에서 noopener를 순위 지정 지시문처럼 다루고 있다면, 그 정책은 수정이 필요합니다.
rel=noreferrer는 참조한 페이지를 숨깁니다
rel="noreferrer"는 사용자가 링크를 따라갈 때 Referer HTTP 헤더를 보내지 말라고 브라우저에 지시합니다.
맞습니다. 이 헤더는 역사적으로 Referer라고 철자가 잘못 굳어졌습니다. 속성은 noreferrer라고 씁니다.
일반적으로 사용자가 내 페이지에서 다른 사이트로 가는 링크를 클릭하면, 대상 사이트는 방문이 어디에서 왔는지 보여주는 referrer 값을 받을 수 있습니다. 사이트의 Referrer-Policy에 따라 전체 URL일 수도 있고, origin만일 수도 있으며, 아무것도 아닐 수도 있습니다.
예를 들어 대상은 다음을 볼 수 있습니다.
Referer: https://www.example.com/pricing?plan=enterprise
또는 다음만 볼 수도 있습니다.
Referer: https://www.example.com/
rel="noreferrer"를 사용하면 브라우저는 해당 이동에 대해 이 헤더를 보내지 않아야 합니다.
<a href="https://external.example" rel="noreferrer">
External site
</a>
실제로 최신 브라우저에서 noreferrer는 noopener처럼도 동작합니다. noreferrer를 사용한다면, 일반적으로 같은 링크의 보안을 위해 noopener를 별도로 쓸 필요는 없습니다. 그래도 많은 팀은 명확성을 위해 둘 다 적습니다.
<a href="https://external.example" target="_blank" rel="noopener noreferrer">
External site
</a>
괜찮은 방식입니다. 중복이지만 읽기 쉽습니다.
noreferrer가 유용한 경우
현재 페이지 URL이 대상에 노출되면 안 될 때 noreferrer를 사용하세요.
일반적인 예는 다음과 같습니다.
- 비공개 대시보드의 링크
- 공개되지 않은 preview 환경의 링크
- 민감한 query parameter를 포함한 URL의 링크
- admin 도구, moderation queue, CRM 화면, 고객 지원 시스템의 링크
- 대상이 정확한 출처 페이지를 알 필요가 없는 링크
마지막 항목은 항상 비밀 유지에 관한 것만은 아닙니다. 때로는 데이터 최소화에 관한 문제입니다. 대상이 참조 URL을 알 필요가 없다면 보내지 마세요.
이는 개인정보 보호를 의식한 웹 설계의 더 넓은 흐름과도 맞닿아 있습니다. 브라우저, 사용자, 규제 기관 모두 기본적으로 덜 많은 주변 데이터를 보내는 방향으로 움직여 왔습니다. 이 영역을 다시 살펴보고 있다면, 2026년에 쿠키에 무엇이 바뀌었고 무엇을 해야 하는지에 관한 글에서 같은 일반적인 변화를 다룹니다. 보이지 않는 추적은 줄이고, 데이터 흐름은 더 의도적으로 만드는 방향입니다.
분석상의 트레이드오프
noreferrer는 링크 대상 사이트의 attribution을 깨뜨릴 수 있습니다. 해당 사이트의 analytics는 방문을 referral traffic이 아니라 direct traffic으로 분류할 수 있습니다.
그것이 당신의 1차 문제는 아니지만, 파트너십, affiliate 관계, 고객 여정, 내부 cross-domain 생태계에서는 중요할 수 있습니다. 마케팅 팀이 파트너 사이트에서 당신의 도메인으로부터 온 referral traffic을 보기를 기대한다면, 일괄적인 noreferrer는 혼란을 만들 수 있습니다.
많은 일반적인 editorial 링크에서는 모든 곳에 noreferrer를 추가하는 것보다 사이트 전체 Referrer-Policy 헤더를 설정하는 편이 더 낫습니다. 예를 들면 다음과 같습니다.
Referrer-Policy: strict-origin-when-cross-origin
이 정책은 same-origin 이동에는 전체 URL을 보내고, 보안 cross-origin 대상에는 origin만 보내며, HTTPS에서 HTTP로 이동할 때는 referrer를 보내지 않습니다. 많은 사이트에 실용적인 기본값입니다.
프로덕션에서 헤더가 어떻게 동작하는지 확인해야 한다면, analytics dashboard를 보고 추측하는 것보다 raw HTTP 확인이 더 명확한 경우가 많습니다. 프로덕션에서 redirect와 HTTP header를 디버깅하기 위한 작은 toolkit의 workflow는 referrer-policy 디버깅에도 그대로 적용됩니다.
rel=nofollow는 검색 엔진을 위한 것이지 브라우저를 위한 것이 아닙니다
rel="nofollow"는 링크된 페이지를 추천한다는 의미를 전달하고 싶지 않다고 검색 엔진에 알려줍니다.
<a href="https://external.example" rel="nofollow">
User-submitted link
</a>
원래 nofollow는 댓글 스팸에 대응하기 위해 도입되었습니다. 아이디어는 단순했습니다. 댓글의 링크가 ranking credit을 전달하지 않는다면, 스패머가 블로그와 포럼을 도배할 유인이 줄어든다는 것이었습니다.
오늘날 Google은 nofollow를 절대적인 지시문이 아니라 hint로 취급합니다. 이 구분은 중요합니다. 검색 엔진이 일부 맥락에서 해당 링크를 discovery나 ranking system에 사용할 수도 있지만, 당신은 그 링크가 일반적인 editorial endorsement로 취급되어서는 안 된다는 신호를 분명히 보내는 것입니다.
nofollow를 사용해야 하는 경우
링크는 걸지만 대상에 대해 보증하고 싶지 않을 때 nofollow를 사용하세요.
합리적인 예는 다음과 같습니다.
- 신뢰할 수 없는 user-generated link
- 공개 댓글이나 프로필의 링크
- 나쁜 행동의 사례로 언급된 사이트에 대한 링크
- 추천이 아니라 참고 목적으로 포함된 링크
- moderation이 제한적인 영역의 링크
유료 또는 sponsored 링크에는 rel="sponsored"를 선호하세요. user-generated content에는 rel="ugc"를 선호하세요. 필요하다면 값을 조합할 수 있습니다.
<a href="https://example.com" rel="ugc nofollow">
User profile link
</a>
공개 form, 댓글, directory, profile page를 운영한다면, 링크 속성은 abuse 문제의 한 부분일 뿐입니다. 스팸은 보통 제출 흐름의 더 앞 단계에서 시작됩니다. contact form이 가장 큰 spam liability인 이유에 대한 별도 분석이 있으며, 여기에도 같은 교훈이 적용됩니다. 약한 moderation을 nofollow가 보완해 줄 것이라고 기대하지 마세요.
nofollow가 하지 않는 일
nofollow는 사용자가 링크를 클릭하는 것을 막지 않습니다. 브라우저가 referrer를 보내는 것도 막지 않습니다. 대상이 보이지 않게 숨기지도 않습니다. target="_blank"를 안전하게 만들지도 않습니다.
또한 어떤 URL이 절대 crawled되지 않는다고 보장하지도 않습니다. 검색 엔진이 다른 곳에서 그 URL을 발견하면 여전히 crawl할 수 있습니다. indexing을 막아야 한다면, 다른 사람의 링크에 nofollow 속성을 붙이는 것이 아니라 대상 페이지에서 noindex 같은 적절한 robots control을 사용하세요.
일반적인 조합
새 탭에서 열리는 외부 링크
<a href="https://external.example" target="_blank" rel="noopener">
External resource
</a>
이것이 기본선입니다. 새 browsing context를 열면서 생기는 보안 문제를 다룹니다.
referrer data도 보내고 싶지 않다면 다음과 같이 씁니다.
<a href="https://external.example" target="_blank" rel="noopener noreferrer">
External resource
</a>
유료 게재
<a href="https://sponsor.example" rel="sponsored">
Sponsor site
</a>
새 탭에서 열린다면 noopener를 추가할 수 있습니다.
<a href="https://sponsor.example" target="_blank" rel="sponsored noopener">
Sponsor site
</a>
유료 링크를 공개하기 위한 모호한 대체재로 nofollow를 사용하지 마세요. 검색 엔진에는 이제 이를 위한 더 구체적인 값이 있습니다. 바로 sponsored입니다.
User-generated link
<a href="https://user-submitted.example" rel="ugc nofollow">
User-submitted site
</a>
이는 검색 엔진에 해당 링크가 사용자가 기여한 것이며 일반적인 editorial vote로 취급되어서는 안 된다고 알려줍니다.
내부 링크
대부분의 내부 링크에는 이 값들 중 어느 것도 필요하지 않습니다.
일상적인 sculpting tactic으로 내부 링크에 nofollow를 추가하지 마세요. 보통 이득보다 혼란을 더 많이 만듭니다. 어떤 페이지가 index되면 안 된다면 그 문제를 직접 처리하세요. 어떤 페이지가 crawl되면 안 된다면 robots rule, authentication, canonicalization, site architecture를 신중히 생각하세요.
새 탭에서 열리는 내부 링크라면 noopener는 여전히 해롭지 않으며 적절할 수도 있습니다. 하지만 더 나은 질문은 애초에 내부 링크가 왜 새 탭을 필요로 하느냐입니다.
팀을 위한 실용적인 정책
간단한 house style만 있어도 대부분의 실수를 막을 수 있습니다.
target="_blank"가 있는 링크, 특히 외부 링크에는rel="noopener"를 추가합니다.- 출처 URL을 숨기는 것이 의도일 때만
noreferrer를 추가합니다. - 대상을 추천하지 않을 때만
nofollow를 추가합니다. - 유료 링크에는
sponsored를, 사용자가 제출한 링크에는ugc를 사용합니다. - 링크 속성을 access control, moderation, indexing rule의 대체재로 사용하지 않습니다.
중요한 것은 의도입니다. rel의 모든 토큰은 구체적인 질문에 답해야 합니다.
- 보안: 새 페이지를 opener로부터 격리해야 하는가?
- 개인정보 보호: 대상이 referrer information을 받아야 하는가?
- SEO: 이 링크를 editorial reference로 추천하는가?
팀에서 아무도 이 질문에 답할 수 없다면, 그 속성은 아마 cargo cult HTML일 가능성이 큽니다.
실제 동작을 테스트하는 방법
noopener의 경우 링크를 열고 대상이 window.opener에 접근할 수 있는지 확인하세요. 통제된 test page에서 noopener가 활성화되어 있으면 window.opener는 null이어야 합니다.
noreferrer의 경우 대상 측에서 network request를 검사하거나 test environment에서 request logger를 사용하세요. Browser DevTools는 outgoing request header를 보여줄 수 있지만, server-side log가 더 신뢰할 만한 경우가 많습니다.
nofollow의 경우 브라우저 동작이 아니라 검색 엔진 해석이기 때문에 테스트가 덜 즉각적입니다. 가장 좋은 확인 방법은 source inspection입니다. 렌더링된 HTML에 기대한 rel 값이 포함되어 있는지 확인하세요. frontend framework가 링크를 다시 작성한다면 template만 보지 말고 최종 DOM을 검사하세요.
결론
이 속성들은 작지만 보안, 개인정보 보호, SEO가 만나는 지점에 있습니다. 서로 바꿔 쓸 수 있는 것처럼 다루면 나쁜 습관이 생깁니다.
새 탭 링크에는 noopener를 넉넉히 사용하세요. referrer privacy가 중요할 때는 noreferrer를 의도적으로 사용하세요. 추천 여부에 대해 검색 엔진을 향한 신호를 보내는 경우에는 nofollow를 사용하세요. 그리고 링크가 유료이거나 사용자가 생성한 것이라면 더 구체적인 최신 값인 sponsored와 ugc를 사용하세요.
대부분의 사이트에는 이 정도면 충분합니다. 목표는 모든 링크를 장식하는 것이 아닙니다. 목표는 각 링크가 브라우저와 검색 엔진에 정확히 필요한 것을 말하게 하는 것입니다.