브라우저의 location 객체는 무엇이고 언제 어떻게 써야 할까
프론트엔드 개발을 하다 보면 window.location을 직접 다뤄야 하는 순간이 생각보다 자주 옵니다.
- 현재 URL의 path를 읽고 싶을 때
- query string을 확인하고 싶을 때
- 특정 페이지로 이동시키고 싶을 때
- 새로고침이나 강제 리다이렉트를 해야 할 때
- hash를 바꿔 특정 섹션으로 보내고 싶을 때
그런데 location은 이름은 익숙해도, 막상 쓰려고 하면 조금 헷갈립니다.
href만 바꾸면 되는지assign()과replace()는 무엇이 다른지pathname,search,hash는 각각 어디까지를 의미하는지history.pushState()나 SPA 라우터와는 어떤 관계인지
이 글에서는 location 객체를 단순 속성 나열보다 아래 흐름으로 정리해보겠습니다.
- 무엇인지
- 어떤 정보를 담고 있는지
- 주요 속성과 메서드는 무엇인지
- 실제로 언제 쓰는지
- SPA나 Next.js/React 환경에서는 무엇을 조심해야 하는지
한눈에 보면
먼저 짧게 정리하면 이렇습니다.
location은 현재 브라우저 주소를 나타내는 객체입니다.- 현재 URL을 읽을 때도 쓰고, 다른 주소로 이동시킬 때도 씁니다.
href,origin,pathname,search,hash를 가장 자주 보게 됩니다.assign()은 일반 이동,replace()는 히스토리를 남기지 않는 이동,reload()는 새로고침입니다.- 다만 SPA에서는 무조건
location으로 이동시키기보다 프레임워크 라우터를 먼저 검토하는 편이 좋습니다.
즉, location은 "URL 문자열 하나"라기보다 현재 문서의 주소와 이동 동작을 다루는 브라우저 기본 API에 가깝습니다.
location은 정확히 무엇일까?
가장 단순하게 말하면 location은 현재 페이지의 URL 정보를 담고 있는 객체입니다.
브라우저에서는 보통 이렇게 접근합니다.
console.log(window.location);
console.log(location);브라우저 환경에서는 window.location과 location이 같은 대상을 가리킵니다.
예를 들어 현재 주소가 아래와 같다고 해보겠습니다.
https://example.com/posts/123?tab=comments&page=2#latest그러면 location 객체는 이 URL을 여러 조각으로 나눠서 읽을 수 있게 해줍니다.
- 전체 주소
- origin
- path
- query string
- hash
즉, location은 주소창에 있는 문자열을 구조적으로 읽고 다룰 수 있게 해주는 기본 진입점입니다.
가장 자주 보는 속성들
실무에서 특히 자주 보는 것은 아래 여섯 가지입니다.
1. href
전체 URL 문자열입니다.
console.log(location.href);
// https://example.com/posts/123?tab=comments&page=2#latest현재 주소를 통째로 보고 싶을 때 가장 직관적입니다.
그리고 이 속성은 읽기만 하는 것이 아니라, 값을 바꾸면 실제 이동도 일어납니다.
location.href = '/login';즉, href는 "현재 전체 주소"이면서, 동시에 "새 주소로 이동시키는 가장 단순한 방법"이기도 합니다.
2. origin
프로토콜, 호스트, 포트까지를 포함한 기준 주소입니다.
console.log(location.origin);
// https://example.com이 값은 아래를 포함합니다.
- protocol
- hostname
- port
예를 들어 API base URL을 비교하거나, 같은 origin인지 확인할 때 유용합니다.
3. pathname
도메인 뒤 path 부분입니다.
console.log(location.pathname);
// /posts/123이 값은 보통:
- 현재 어떤 페이지인지 간단히 분기하고 싶을 때
- 특정 path 패턴인지 확인하고 싶을 때
- 라우팅 맥락을 읽고 싶을 때
자주 보게 됩니다.
즉, pathname은 query string이나 hash를 제외한 리소스 경로 자체에 가깝습니다.
4. search
query string 전체입니다.
console.log(location.search);
// ?tab=comments&page=2여기서 중요한 점은 ?까지 포함된다는 것입니다.
이 값은 보통 URLSearchParams와 함께 씁니다.
const searchParams = new URLSearchParams(location.search);
const tab = searchParams.get('tab');
const page = Number(searchParams.get('page') ?? '1');즉, search는 query string을 읽는 출발점이고, 실제 파싱은 URLSearchParams로 넘기는 패턴이 가장 흔합니다.
5. hash
URL의 # 뒤 부분입니다.
console.log(location.hash);
// #latest이 값도 #를 포함합니다.
보통 아래처럼 많이 씁니다.
- 문서 특정 섹션으로 이동
- 탭/섹션 상태를 가볍게 표현
- 앵커 링크 처리
예를 들어:
if (location.hash === '#comments') {
openCommentsPanel();
}즉, hash는 서버 조회 조건보다 문서 내부 위치나 가벼운 클라이언트 상태와 더 잘 맞습니다.
6. protocol, host, hostname, port
이 속성들은 도메인 관련 세부 값이 필요할 때 씁니다.
console.log(location.protocol); // https:
console.log(location.host); // example.com
console.log(location.hostname); // example.com
console.log(location.port); // ''짧게 차이를 보면:
host: hostname + porthostname: 도메인 이름만port: 포트만
실무에서는 자주 쓰는 편은 아니지만, 환경 분기나 외부 링크 정책을 다룰 때 가끔 필요합니다.
location으로 이동시키는 방법들
location은 읽기만 하는 객체가 아닙니다. 실제 이동도 일으킬 수 있습니다.
여기서 가장 많이 비교되는 것이 href, assign(), replace()입니다.
1. location.href = ...
가장 직관적인 방식입니다.
location.href = '/login';이 코드는 브라우저를 해당 주소로 이동시킵니다.
특징은:
- 이해하기 쉽고
- 동작이 단순하며
- 히스토리에 현재 페이지가 남습니다
즉, 사용자가 뒤로 가기를 눌렀을 때 이전 페이지로 돌아올 수 있습니다.
2. location.assign()
의미상으로는 href 대입과 거의 비슷합니다.
location.assign('/login');이 방식도:
- 새 페이지로 이동하고
- 현재 페이지를 브라우저 히스토리에 남깁니다
그래서 일반적인 이동이라는 점에서는 href와 거의 같은 감각으로 볼 수 있습니다.
3. location.replace()
이 메서드는 중요한 차이가 있습니다.
location.replace('/login');이동은 하지만 현재 페이지를 히스토리에 남기지 않습니다.
즉, 사용자가 뒤로 가기를 눌렀을 때 방금 전 페이지로 돌아오지 못하게 하고 싶을 때 유용합니다.
대표적인 예시는:
- 로그인 후 이전 로그인 페이지를 히스토리에서 없애고 싶을 때
- 잘못된 접근 경로를 대체 페이지로 바꿔치기할 때
- 중간 리다이렉트 페이지를 뒤로 가기 흐름에 남기고 싶지 않을 때
즉, replace()는 "이동"이라기보다 현재 엔트리를 다른 주소로 교체하는 이동에 가깝습니다.
reload()는 언제 쓸까?
location.reload()는 현재 페이지를 다시 불러옵니다.
location.reload();이 메서드는 단순하지만, SPA 환경에서는 생각보다 신중하게 써야 합니다.
왜냐하면 reload는:
- 메모리 상태를 날리고
- 현재 문서를 다시 로드하고
- 클라이언트 상태를 모두 초기화할 수 있기 때문입니다
그래서 보통은:
- 정말 전체 문서를 다시 받아야 할 때
- 인증 상태가 꼬여 완전 초기화가 필요할 때
- 브라우저 수준 새로고침이 의도와 맞을 때
에만 쓰는 편이 좋습니다.
단순히 데이터만 다시 가져오고 싶은 상황이라면 reload()보다 데이터 패칭 라이브러리의 refetch나 프레임워크 라우터의 refresh 계열 기능이 더 적절할 때가 많습니다.
location과 URL 객체는 어떻게 다를까?
이 부분도 자주 헷갈립니다.
location은 현재 브라우저 문서의 주소와 이동 동작을 다룹니다.URL은 특정 URL 문자열을 파싱하고 조작하는 일반 객체입니다.
예를 들어 현재 주소를 구조적으로 다루고 싶다면 이렇게 쓸 수 있습니다.
const currentUrl = new URL(location.href);
console.log(currentUrl.pathname);
console.log(currentUrl.searchParams.get('tab'));이 방식의 장점은:
location의 현재 주소를 기반으로URL과searchParamsAPI를 더 구조적으로 활용할 수 있다는 점입니다
즉, 실무에서는 location으로 현재 주소를 얻고, 세밀한 조작은 URL 객체로 넘기는 흐름도 자주 나옵니다.
query string과 hash를 읽을 때는 어떤 패턴이 좋을까?
예를 들어 현재 URL이 아래와 같다고 해보겠습니다.
/products?category=shoes&sort=latest#reviews이럴 때 가장 기본적인 읽기 패턴은 아래처럼 갈 수 있습니다.
const searchParams = new URLSearchParams(location.search);
const category = searchParams.get('category');
const sort = searchParams.get('sort');
const section = location.hash.replace('#', '');이 패턴의 장점은:
- query string은
URLSearchParams - hash는
location.hash
로 역할을 분리해서 읽을 수 있다는 점입니다.
즉, location 하나로 모든 것을 처리하기보다, URL의 각 조각을 성격에 맞는 API와 함께 다루는 편이 더 깔끔합니다.
실무에서는 언제 직접 location을 쓸까?
생각보다 흔한 사례는 아래와 같습니다.
1. 현재 주소 기반 분기
if (location.pathname.startsWith('/admin')) {
enableAdminLayout();
}라우터 바깥 영역이나 순수 브라우저 스크립트에서 간단히 path를 분기할 때 씁니다.
2. query string 읽기
const searchParams = new URLSearchParams(location.search);
const modal = searchParams.get('modal');딥링크나 필터 초기값을 읽을 때 자주 나옵니다.
3. 외부 페이지 리다이렉트
location.assign('https://example.com');프레임워크 라우터보다 브라우저 레벨 이동이 더 자연스러운 경우가 있습니다.
- 외부 사이트 이동
- OAuth 로그인 이후 복귀
- 파일 다운로드 엔드포인트 이동
이럴 때는 location이 직접적입니다.
4. 뒤로 가기 흐름을 남기고 싶지 않은 이동
location.replace('/onboarding');중간 페이지를 히스토리에 남기고 싶지 않을 때 잘 맞습니다.
5. hash 기반 섹션 이동
location.hash = 'faq';간단한 문서 페이지에서 특정 섹션으로 이동시키는 용도로 쓸 수 있습니다.
React나 Next.js에서는 무엇을 조심해야 할까?
여기가 실무에서 특히 중요합니다.
location은 브라우저 전역 객체이기 때문에:
- 서버 렌더링 중에는 바로 접근할 수 없고
- 프레임워크 라우터 상태와 따로 움직일 수 있으며
- 불필요한 전체 페이지 이동을 만들 수 있습니다
즉, React나 Next.js에서는 "location을 쓸 수 있는가?"보다 "정말 브라우저 레벨 이동이 필요한가?" 를 먼저 따져보는 편이 좋습니다.
1. 서버 환경에서는 바로 쓸 수 없다
예를 들어 window.location은 브라우저에서만 존재합니다.
그래서 SSR 환경이나 서버 컴포넌트에서는 아래처럼 바로 접근하면 문제가 됩니다.
console.log(window.location.href);이런 코드는 브라우저 실행 시점에만 안전합니다.
즉, React에서는:
- effect 안에서 읽거나
- 이벤트 핸들러 안에서 읽거나
- 클라이언트 전용 컴포넌트에서만 사용하는 식으로
경계를 분명히 해야 합니다.
2. SPA 내부 이동은 라우터가 더 자연스러울 수 있다
예를 들어 React Router나 Next.js App Router를 쓰는 앱에서 내부 페이지 이동을 매번 location.href로 하면:
- 전체 문서 이동이 일어나고
- 클라이언트 상태가 끊기고
- 프레임워크가 제공하는 라우팅 최적화를 놓칠 수 있습니다
그래서 내부 라우팅은 보통 프레임워크 라우터가 우선입니다.
- Next.js:
Link,router.push(),router.replace() - React Router:
Link,navigate()
반대로 아래 상황은 location이 여전히 자연스럽습니다.
- 외부 URL로 이동할 때
- 브라우저 리로드가 꼭 필요할 때
- 프레임워크 라우터 바깥 스크립트에서 현재 주소를 읽을 때
3. replace()와 라우터의 replace()를 구분해야 한다
이름이 같아서 자주 헷갈리지만, 의미 층위가 다릅니다.
location.replace(): 브라우저 레벨 이동- 라우터
replace(): SPA 라우팅 맥락 안에서 히스토리 교체
즉, 프레임워크 안에서는 먼저 라우터 API가 더 맞는지 보는 편이 좋습니다.
자주 하는 실수
정리하면 아래 실수가 정말 자주 나옵니다.
pathname,search,hash의 경계를 섞어 생각한다- 내부 라우팅까지 전부
location.href로 처리한다 replace()를 써야 할 상황에서assign()을 써서 뒤로 가기 흐름이 어색해진다- SSR 환경에서
window.location을 바로 읽는다 - 단순 데이터 갱신 문제를
reload()로 해결하려 한다
즉, location은 쉬워 보이지만, 브라우저 이동과 앱 라우팅의 경계를 헷갈릴 때 버그나 UX 어색함이 쉽게 생깁니다.
실무 체크리스트
실제로 적용할 때는 아래 질문으로 빠르게 점검하면 도움이 됩니다.
- 지금 필요한 것이 단순 URL 읽기인가, 실제 이동인가?
- 이동이라면 브라우저 레벨 이동이 필요한가, SPA 라우팅이면 충분한가?
- 뒤로 가기 히스토리를 남겨야 하는가?
- query string은
URLSearchParams로 파싱하고 있는가? - 서버 환경에서
window.location을 읽고 있지는 않은가?
이 기준을 먼저 세우면 href, assign(), replace(), reload() 중 어떤 선택이 맞는지도 훨씬 선명해집니다.
정리하면
location 객체를 한 줄로 줄이면, 현재 브라우저 주소를 읽고, 필요하면 그 주소를 바꿔 이동시킬 수 있게 해주는 기본 브라우저 API입니다.
실무 기준으로 기억할 핵심은 이렇습니다.
href,pathname,search,hash를 가장 자주 보게 되고assign()은 일반 이동,replace()는 히스토리 교체,reload()는 새로고침이며- query string 파싱은
URLSearchParams와 함께 보는 편이 좋고 - SPA에서는 무조건
location보다 프레임워크 라우터가 더 적합한지 먼저 판단해야 합니다
location은 자바스크립트에서 브라우저 URL을 다루는 가장 기본적인 출발점입니다. 그래서 이 객체를 잘 이해하면 단순 주소 읽기뿐 아니라, query string, hash, 리다이렉트, 브라우저 히스토리까지 훨씬 자연스럽게 연결해서 볼 수 있습니다.
