입력값을 받고, 기존 데이터와 동일할 경우 로그인 성공 처리를 해주면 끝나는 것처럼 보인다.

그런데 여기서 더 깊게 생각해보면 미처 생각하지 못한 부분이 생긴다.

"로그인 성공 이후에는 어떻게 로그인 상태를 유지시키지?"

로그인 요청을 계속 보내는 건 불친절한 기능이다. 한 번의 요청으로도 서비스는 계속 나를 로그인한 사용자로 알아봐야 한다.

그럼 서버가 어떻게 사용자를 기억하게 만들어야 할까?

웹의 기본 통신 방식인 HTTP는 기본적으로 이전 요청을 기억하지 못한다.

즉, 요청 하나가 끝나면 다음 요청은 완전히 새로운 요청처럼 처리된다.

그렇다면 로그인 상태를 유지하기 위해서는 사용자를 기억하기 위한 별도의 방법이 필요하다.

그리고 이 문제를 해결하기 위해 등장한 대표적인 방식이 바로 세션(Session)과 토큰(Token) 기반 인증이다.

1. 원래 상태를 기억 못하는 HTTP

로그인 상태를 유지하는 방식을 이해하려면 우선 HTTP의 기본 구조부터 알아야 한다.

웹에서 클라이언트와 서버는 HTTP 요청(Request)와 응답(Response)을 주고받는다.

브라우저가 서버에게 요청을 보내면, 서버는 그에 맞는 응답을 반환한다.

그런데 여기서 중요한 특징이 하나 있다.

HTTP는 기본적으로 상태(State)를 기억하지 않는다.

즉, 요청 하나와 응답 하나가 끝나면 연결은 죵료되고, 다음 요청이 들어왔을 때 서버는 그 요청이 이전 요청과 같은 사용자의 요청인지 알 수 없다.

예를 들어

1. 사용자가 로그인 요청을 보낸다.
2. 서버가 로그인 성공 응답을 보낸다.
3. 이후 사용자가 다시 API 요청을 보낸다.

사용자 입장에서는 "아까 로그인했으니까 당연히 로그인된 상태겠지"라고 생각할 수 있지만, 서버 입장에서는 아니라는 말이다.

새로운 요청이 들어왔을 뿐이고, 그 요청이 이전에 로그인했던 사용자의 요청인지 자동으로 알 수 있는 방법이 없다.

즉, HTTP만으로는 로그인 상태를 유지할 수 없는 구조라는 뜻이다.

이런 특징을 상태(State)를 저장하지 않는다는 의미로 Stateless라고 부른다.

그래서 웹 서비스는 사용자를 기억하기 위한 별도의 방법이 필요했고,

그 과정에서 등장한 대표적인 방식이 세션(Session)과 토큰(Token) 기반 인증이다.

2. 를 해결하고자 등장한 세션 기반 인증

앞서 말했듯, HTTP는 기본적으로 상태를 기억하지 못한다.

즉, 로그인 요청이 끝난 이후에는 서버가 사용자를 계속 기억할 방법이 없다.

그래서 등장한 방식이 바로 세션(Session) 기반 인증이다.

세션 방식의 핵심은 단순하다.

서버가 직접 사용자의 로그인 상태를 기억하는 것

로그인 요청이 성공하면 서버 내부에 사용자의 로그인 정보를 저장한다.

예를 들어

• 어떤 사용자인지
• 언제 로그인했는지
• 어떤 권한을 가지고 있는지

같은 정보들을 서버가 보관하게 된다.

그리고 이때 서버는 해당 사용자를 구분하기 위한 고유한 ID도 함께 만든다.

이 ID를 세션 ID(Session ID)라고 한다.

그런데 문제는 여기서 끝나지 않는다.

서버는 세션 정보를 저장했지만, 다음 요청에서 어떤 사용자가 어떤 세션의 주인인지 다시 알아야 한다.

그래서 브라우저가 세션 ID를 가지고 다니게 된다.

이때 사용되는 것이 쿠키(Cookie)다.

서버는 로그인 성공 이후 세션 ID를 쿠키에 담아 브라우저로 전달하고, 브라우저는 이후 요청마다 해당 쿠키를 함께 전송한다.

그러면 서버는

1. 전달받은 세션 ID를 확인하고
2. 저장된 세션 정보와 비교한 뒤
3. 로그인된 사용자임을 판단하게 된다.

즉 세션은 서버에 저장되고 쿠키는 세션 ID를 전달하는 역할을 한다.

쿠키와 세션은 같은 개념이 아니라, 쿠키는 단순한 저장 공간이고, 세션은 서버가 사용자를 기억하기 위한 인증 방식에 가깝다.

이 부분이 핵심이자, 많이 헷갈리는 부분이라고 한다.

이렇게 세션 기반 인증은 HTTP가 상태를 기억하지 못한다는 문제를 해결하기 시작했다.

3. 의 점차 다가오는 한계

세션 기반 인증은 HTTP가 상태를 기억하지 못한다는 문제를 해결해줬다.

하지만 서비스 규모가 커지기 시작하면서 세션 방식도 점점 한계를 드러내기 시작한다.

가장 큰 이유는 세션 정보가 서버에 저장된다는 점이었는데, 사용자가 늘어날수록 서버가 저장해야 하는 세션 데이터도 함께 증가하게 된다.

즉, 로그인한 사용자가 많아질수록 서버는 더 많은 상태를 직접 관리해야 했다.

처음에는 큰 문제가 아니었지만 서비스 규모가 커지고 트래픽이 많아지면서 상황이 많이 달라지기 시작했다. 특히 서버를 여러 대 운영하기 시작하면 문제가 더 복잡해진다.

예를 들어 A 서버에서 로그인했는데, 다음 요청은 B 서버로 들어가는 상황이 생길 수도 있었다. 그런데 세션 정보가 A 서버에만 저장되어 있다면, B 서버는 해당 사용자가 로그인한 상태인지 알 수 없다.

결국 여러 서버가 같은 세션 정보를 공유해야 하는 문제가 생긴다.

그래서 세션 저장소를 따로 두거나 Redis 같은 외부 저장소를 사용하거나 세션 클러스터링을 구성하는 방식 등이 등장하게 된다.

즉, 세션 방식을 통해 해결된 인증 자체보다 그 세션들을 관리하기 위한 추가적인 구조가 필요해지기 시작한 것이다.

그리고 웹 환경 자체도 점점 변하기 시작했다.

과거에는 서버가 화면까지 함께 렌더링하는 구조가 많았다면, 점점 프론트엔드와 백엔드가 분리되기 시작했고,

SPA(Single Page Application)나 모바일 앱 환경도 늘어나기 시작했다.

이런 환경에서는 서버가 상태를 직접 기억하는 방식보다, 클라이언트가 직접 인증 정보를 들고 다니는 방식이 더 유리해지기 시작했다.

그래서 이런 흐름 속에서 등장한 방식이 바로 토큰(Token) 기반 인증이다.

4. 를 해결하고자 등장한 토큰 기반 인증

세션 방식은 서비스 규모가 커지고, 서버가 여러 대로 분산되고, 프론트와 백엔드가 분리되기 시작하면서 점점 서버가 상태를 직접 저장하는 방식에 부담이 생기기 시작했다.

그래서 등장한 방식이 바로 토큰(Token) 기반 인증이다.

토큰 방식의 핵심은 세션과 반대로, 세션은 서버가 사용자를 기억했다면, 토큰 방식은 클라이언트가 인증 정보를 직접 들고 다닌다.

로그인 요청이 들어오면 서버는 먼저 사용자의 정보를 확인한다. 그리고 로그인이 성공하면 사용자를 증명할 수 있는 토큰(Token)을 발급한다.

브라우저는 이 토큰을 저장하고, 이후 요청마다 함께 전달한다.

대표적으로 Authorization 헤더, Bearer Token 방식 등을 사용한다.

예를 들어 이런 형태다.

Authorization: Bearer eyJhbGciOi...

그러면 서버는 요청이 들어올 때마다 토큰이 유효한지 검증하고, 검증이 완료되면 해당 사용자가 로그인된 사용자라고 판단하게 된다.

즉, 세션 방식처럼 서버가 로그인 상태를 직접 저장하지 않아도 되는 구조다.

특히 서버 입장에서는 세션 저장소를 계속 관리할 필요가 줄어들기 때문에 서버 확장이나 프론트/백엔드 분리 구조에서 더 유리해지기 시작했다.

그리고 이런 흐름 속에서 대표적인 토큰 기반 인증 방식으로 떠오른 것이 JWT(JSON Web Token)다.

JWT는 사용자 정보와 만료 시간 등을 포함한 데이터를 하나의 토큰 형태로 만들어 전달하는 방식이다.

덕분에 서버는 별도의 세션 저장소 없이도 토큰 자체를 검증하는 것만으로도 사용자를 확인할 수 있게 되었다.

하지만 토큰 방식 역시 완벽한 방식은 아니었고, 편리한 만큼 새로운 보안 문제와 관리 문제도 함께 가져오게 된다.

5. 의 점차 보이는 단점

토큰 기반 인증은 세션 방식의 한계를 해결한 건 사실이다. 하지만 이것 역시도 시간이 지나면서 여러 단점이 드러나기 시작했다.

가장 대표적인 문제는 토큰이 탈취되었을 때의 위험성이다.

세션 방식은 서버가 상태를 직접 관리하기 때문에 특정 세션을 서버에서 강제로 만료시키는 것이 비교적 쉽다.

하지만 JWT는 클라이언트가 토큰 자체를 들고 다니는 구조다.

즉, 토큰이 유효한 동안에는 서버 입장에서 해당 사용자를 정상 사용자로 판단하게 된다.

만약 토큰이 외부에 노출되거나 탈취된다면, 다른 사용자가 그대로 인증된 사용자처럼 동작할 수도 있다는 뜻이다.

그리고 JWT는 흔히 오해하는 것처럼 데이터를 암호화하는 방식이 아니다.

JWT의 Payload는 Base64 방식으로 인코딩되어 있을 뿐이며, 토큰 자체를 열어보는 것은 어렵지 않다.

이는 곧 민강한 정보를 토큰 내부에 그대로 담는 것은 위험할 수 도 있다는 문제로 직결된다.

또 다른 문제는 로그아웃 처리다.

세션 방식은 서버에서 세션을 제거하면 즉시 로그아웃 상태로 만들 수 있다. 하지만 JWT는 이미 클라이언트에게 발급된 토큰이다.

서버가 토큰을 강제로 회수하기 어렵기 때문에, 만료 시간이 끝나기 전까지는 계속 사용할 수 있는 문제가 생긴다.

그래서 등장한 개념이 바로 Access Token과 Refresh Token 구조다.

Access Token은 짧은 시간만 사용하고, Refresh Token으로 새로운 토큰을 재발급받는 방식이다.

즉, 토큰 기반 인증은 세션 방식의 한계를 해결하기 위해 등장했지만, 그 과정에서 또 다른 보안 문제와 관리 문제를 함께 안게 된 것이다.

결국 인증 방식은 "무조건 더 좋은 방식"이 등장하는 흐름이라기보다, 환경 변화에 따라 장단점이 다른 방식들이 계속 발전해온 과정에 가깝다고 볼 수 있다.

6. 세션과 토큰의 차이

세션과 토큰은 결국엔 둘 다 HTTP가 상태를 기억하지 못한다는 문제를 해결하기 위해 등장한 방식이다.

세션의 어느 문제가 있고, 토큰에 어느 문제가 있고, 결국 인증의 역할을 똑똑히 하고 있다.

하지만 분명한 차이점이 있다. 먼저 사용자를 기억하는 방식에서부터 차이가 있다.

세션 방식은 서버가 사용자의 로그인 상태를 직접 저장한다. 브라우저는 세션 ID만 전달하고, 실제 로그인 정보는 서버 내부에서 관리된다.

반면 토큰 방식은 클라이언트가 인증 정보를 직접 들고 다닌다. 서버는 별도의 로그인 상태를 저장하기보다, 전달받은 토큰이 유효한지만 검증한다.

이렇게 각각 장단점이 다르기 때문에 서비스 구조에 따라 더 잘 어울리는 환경도 달라진다.

세션 기반 인증은 아래와 같은 서비스에서 여전히 잘 쓰이고 있다.

• 전통적인 서버 렌더링 기반 웹 서비스
• 관리자 페이지
• 금융 서비스
• 보안이 중요한 내부 시스템

그런 전통적인 서비스에서 쓰이는 반면 토큰 기반 인증은 비교적 최신 서비스에 쓰인다.

• SPA(Single Page Application)
• 모바일 앱
• 프론트엔드 / 백엔드 분리 구조
• MSA(Micro Service Architecture)

그런데 프로젝트와 별개로 진행하던 스프린트 미션에서는 MongoDB 를 사용하고 있었다.

멘토님은 스프린트 미션 코드리뷰도 함께 진행해주시고, 초급 프로젝트 방향까지 같이 봐주시는데, 그러다 보니 자연스럽게 “초급 프로젝트도 MongoDB를 쓰고 있겠구나” 하고 잠깐 오해하신 상황이 있었다.

그 작은 해프닝을 계기로 이런 궁금증이 생겼다.

• MongoDB와 PostgreSQL은 정확히 뭐가 다를까?
• 어떤 상황에서 서로 다른 DB를 선택하게 될까?
• 그리고 DB를 공부한다면, 결국 무엇을 깊게 파야 할까?

팀원분도 비슷한 질문을 멘토님께 드렸고, 돌아온 답변은 꽤 인상적이었다.

현업에서는 하나만 정답처럼 쓰이지 않는다. 서비스 성격과 상황에 따라 정말 다양한 DB가 사용된다.

그 말을 듣고 나니 단순히 “MongoDB vs PostgreSQL” 비교를 넘어서, 세상에는 어떤 종류의 데이터베이스가 있고, 각각 어디에 쓰이는지 정리해보고 싶어졌다.

그래서 이번 글에서는 다양한 데이터베이스의 종류와 특징, 그리고 어떤 상황에서 선택되는지를 중심으로 정리해보려고 한다.

1. 다양한 종류의 데이터베이스, 왜?

처음 데이터베이스를 접했을 때는 그냥 “데이터를 저장하는 공간” 정도로만 생각했었다.

그래서 왜 스프린트 미션에서는 MongoDB 를 사용하고, 초급 프로젝트에서는 PostgreSQL 를 사용하는지 크게 의문을 가지지도 않았다.

그런데 이번 기회에 조금 더 찾아보면서 데이터베이스는 생각보다 훨씬 다양한 종류가 존재한다는 걸 알게 됐다.

모든 데이터가 같은 모습일까?

아니다. 이게 어쩌면 이번 섹션에 핵심으로 작용된다.

예를 들어 데이터를 보면

• 사용자 정보처럼 구조가 명확한 데이터
• 게시글처럼 자유롭게 형태가 바뀌는 데이터
• 친구 관계처럼 연결 구조가 중요한 데이터
• 로그처럼 계속해서 대량으로 쌓이는 데이터

등이 존재한다.

즉, 데이터마다 다루는 방식과 성격 자체가 다르다는 뜻이다.

하나의 방식에서 생기는 한계

이런 데이터를 모두 하나의 방식으로 처리하려고 하면 분명 문제가 생긴다.

어떤 경우에는 구조가 지나치게 엄격해지고, 어떤 경우에는 성능이 떨어지며, 어떤 경우에는 데이터 관리 자체가 복잡해진다.

결국 데이터의 성격에 따라 더 적합한 저장 방식이 필요해지기 시작한 것이다.

그래서 등장한 것이 바로 각각 다른 방식으로 데이터를 저장하는 다양한 데이터베이스들이다.

데이터베이스를 나누는 대표적인 기준

정답은 바로 위에서 다뤘다.

데이터를 어떤 형태로 저장하느냐

이 기준에 따라 데이터베이스는

• 테이블 형태로 정리해서 저장하는 방식
• JSON 문서 형태로 묶어서 저장하는 방식
• key-value 형태로 빠르게 저장하는 방식

등으로 나뉘게 된다.

그리고 이 저장 방식의 차이가 각 데이터베이스의 특징과 사용 목적을 결정하게 된다.

2. 데이터를 저장하는 방식

앞에서 말했듯이 데이터베이스를 이해하는 가장 큰 기준 중 하나는

데이터를 어떤 방식으로 저장하느냐

이다.

이 기준으로 보면 데이터베이스 종류들이 왜 나뉘는지 조금 더 명확하게 보이기 시작한다.

데이터를 "정리해서" 저장하기

가장 익숙한 방식은 데이터를 정해진 구조 안에서 관리하는 방식이다.

데이터를 정해진 구조 안에 넣어서 관리하는 방식이다.

이 방식이 바로 관계형 데이터베이스(RDBMS)이며, 대표적으로 이번 초급 프로젝트에서 채택했던 PostgreSQL, MySQL이 있다.

선 구조 후 데이터

관계형 데이터베이스는 흐름이 비교적 명확하다.

1. 테이블 구조를 먼저 정의
2. 정의된 구조에 맞게 데이터 저장

예를 들어

• 사용자 테이블
• 습관 테이블
• 기록 테이블

처럼 데이터를 역할별로 나누고, 각 테이블을 관계로 연결해서 관리한다.

장점

관계형 데이터베이스의 가장 큰 특징은 데이터의 정확성과 일관성을 유지하기 쉽다는 점이다.

예를 들어

• 존재하지 않는 사용자에 대한 기록 생성
• 잘못된 타입의 데이터 입력
• 관계가 맞지 않는 데이터 저장

같은 문제들을 데이터베이스 단계에서 방지할 수 있다.

즉, 데이터 구조를 엄격하게 관리하는 대신 안정성을 높이는 방식이라고 볼 수 있다.

단점

다만 구조를 엄격하게 관리하는 만큼 설계와 관리가 상대적으로 복잡해진다.

테이블을 나누고, 관계를 연결하고, 여러 데이터를 함께 고려해야 하기 때문이다.

그래서 데이터를 저장하거나 수정하는 과정이 비교적 무겁게 느껴질 수 있다.

데이터를 "묶어서" 저장하기

반대로 데이터를 하나의 문서처럼 저장하는 방식도 존재한다.

이 방식이 바로 문서형 데이터베이스이며, 대표적으로 MongoDB 가 있다.

선 데이터 후 구조

문서형 데이터베이스는 관계형 데이터베이스보다 훨씬 유연하다.

예를 들면 아래처럼 JSON 형태에 가까운 구조 자체를 그대로 저장할 수 있다.

{
  "user": "명곤",
  "habits": [{ "name": "공부", "done": false }]
}

하나의 문서 안에 필요한 데이터를 함께 넣어서 관리하는 방식이다.

장점

문서형 데이터베이스는 구조를 엄격하게 미리 정의하지 않아도 된다는 특징이 있다.

그래서

• 빠르게 개발 가능
• 구조 변경에 유연함
• 데이터를 한 번에 저장 가능

같은 장점을 가진다.

특히 데이터 구조가 자주 바뀌거나 빠른 개발 속도가 중요한 서비스에서 자주 사용된다.

단점

다만 유연한 만큼 데이터 관리 책임이 개발자 쪽으로 많이 넘어온다.

관계형 데이터베이스처럼 강하게 관계를 검증하지 않기 때문에

• 데이터 중복
• 일관성 문제
• 복잡한 관계 관리 어려움

같은 문제가 발생하기 쉽다.

특히 규모가 커질수록 같은 데이터가 여러 곳에 퍼지면서 어떤 값이 실제 기준 데이터인지 헷갈리는 상황도 생길 수 있다.

SQL vs MongoDB

MongoDB와 SQL 계열 데이터베이스를 비교할 때 자주 나오는 말이 있다.

MongoDB는 쓰기가 빠르고, SQL은 느리다.

하지만 이 표현은 조금 단순화된 이야기라고 한다.

관계형 데이터베이스는 데이터를 저장할 때

• 관계 확인
• 데이터 검증
• 제약 조건 검사

등을 함께 수행한다.

반면 문서형 데이터베이스는 상대적으로 자유로운 구조 안에서 데이터를 저장한다.

그래서 체감상 문서형 데이터베이스가 더 가볍고 빠르게 느껴질 수 있는 것이다.

MongoDB가 무조건 더 뛰어난 성능을 가진다기보다는 저장 방식 자체가 다르기 때문에 체감 차이가 발생하는 것에 가깝다.

결국 중요한 건 어떤 데이터와 어떤 서비스 구조에 더 잘 맞느냐이다.

3. 속도를 위해 태어난 데이터베이스

앞에서 본 관계형 데이터베이스와 문서형 데이터베이스는 결국 데이터를 저장하고 관리하는 것이 핵심 목적이었다.

• 관계형 데이터베이스 → 구조를 나눠서 저장
• 문서형 데이터베이스 → 데이터를 묶어서 저장

그런데 서비스 규모가 커지면 단순히 “저장”만 잘한다고 끝나지 않는다.

예를 들어 서비스에서는 아래 같은 요청이 정말 자주 발생한다.

• 로그인 상태 확인
• 오늘의 습관 조회
• 토글 상태 확인
• 자주 조회되는 데이터 불러오기

이런 요청마다 매번 메인 데이터베이스에 접근하게 되면 점점 성능 부담이 커지기 시작한다.

그래서 등장한 방식이 바로

데이터를 엄청 빠르게 꺼내는 데 집중한 데이터베이스

로, 대표적으로 Redis가 있다.

Key-Value 방식

이 방식은 구조 자체가 굉장히 단순하다.

key → value

예를 들면

• user:1 → 명곤
• habit:3 → false

처럼 key 하나에 value 하나를 연결해서 저장한다.

구조가 극단적으로 단순한 이유는 하나다.

오직 속도를 위해서다.

어떻게 이런 속도가?

핵심은 크게 두 가지다.

1. 메모리 기잔 저장

일반적인 관계형 데이터베이스는 주로 디스크 기반으로 데이터를 저장한다.

반면 Redis는 데이터를 메모리(RAM)에 저장한다.

• 디스크 → 상대적으로 느림
• 메모리 → 매우 빠름

즉, 물리적인 접근 속도 자체에서 차이가 발생한다.

2. 구조 자체가 단순함

Redis는 복잡한 관계를 거의 고려하지 않는다.

• 조인 없음
• 관계 관리 없음
• 복잡한 쿼리 최소화

그냥 key 하나로 바로 데이터를 찾는다. “빠르게 찾기”에만 집중한 구조인 것인데, 어떻게 느릴 수 있겠는가 ...

빠른 속도가 필요한 사용처

중요한 건 Redis가 보통 메인 데이터베이스 역할을 하지는 않는다는 점이다.

대신 아래 같은 곳에서 많이 사용된다.

• 로그인 세션 저장
• 캐시(Cache) 저장
• 조회 결과 임시 저장
• 실시간 데이터 처리

예를 들어 오늘의 습관 조회 결과를 Redis에 저장해두면,

1. 첫 요청 → 메인 DB 조회
2. 조회 결과를 Redis에 저장
3. 다음 요청 → Redis에서 바로 반환

처럼 동작할 수 있다.

즉, 매번 데이터베이스를 조회하지 않아도 되기 때문에 서비스 속도가 훨씬 빨라질 수 있다.

실제로 서비스 고도화 과정에서 캐시 전략으로 자주 고려되는 방식이라고 한다.

단점

물론 빠르다고 해서 모든 상황에 적합한 건 아니다.

Redis 같은 Key-Value 방식은

• 데이터 유실 가능성
• 복잡한 관계 표현 어려움
• 데이터 일관성 관리 한계

같은 단점이 존재한다.

그래서 보통은

메인 데이터베이스를 보조하는 역할

로 많이 사용된다.

4. 관계를 저장하는 데이터베이스

앞에서 다룬 관계형 데이터베이스는 테이블을 나누고, 관계를 연결한 뒤 필요한 순간에 JOIN으로 데이터를 가져오는 방식으로, 관계를 간접적으로 표현하는 구조에 가깝다.

그런데 세상에는 관계 자체가 핵심인 데이터들도 존재한다.

예를 들면

• 친구의 친구 추천
• 팔로우 관계
• 추천 시스템
• 네트워크 분석

같은 경우들이다.

이런 데이터들은 연결이 계속 늘어나고, 관계 구조도 점점 복잡해진다.

관계형 데이터베이스의 한계

관계형 데이터베이스에서도 이런 구조를 구현할 수는 있다.

다만 관계가 많아질수록

• 테이블 수 증가
• JOIN 증가
• 쿼리 복잡도 증가

같은 문제가 발생하기 시작한다.

특히 “연결을 따라가며 탐색”하는 작업이 많아질수록 성능과 관리 복잡도가 함께 커질 수 있다.

그래서 등장한 방식이 바로

관계 자체를 중심으로 저장하는 데이터베이스

이다.

대표적으로 Neo4j 가 있다.

그래프 데이터베이스

그래프 데이터베이스는 데이터를 아래처럼 표현한다.

• 노드(Node) → 데이터
• 엣지(Edge) → 관계

여기서 중요한 건

관계 자체가 하나의 핵심 데이터로 다뤄진다는 점

이다.

예를 들어 관계형 데이터베이스에서는

• 유저 테이블
• 팔로우 테이블

처럼 관계를 별도 테이블로 관리한다.

반면 그래프 데이터베이스는 연결 자체가 구조가 된다.

A --- 친구 --- B
|
팔로우
|
C

“누가 누구와 연결되어 있는가”

를 굉장히 자연스럽게 표현하는 방식으로 볼 수 있다.

장점

그래프 데이터베이스의 가장 큰 장점은 관계 탐색에 특화되어 있다는 점이다.

예를 들어

“A의 친구의 친구 찾기”

같은 작업을 수행한다고 하면,

관계형 데이터베이스에서는

• 여러 JOIN 수행
• 복잡한 쿼리 작성
• 관계 깊어질수록 성능 부담 증가

같은 문제가 생길 수 있다.

반면 그래프 데이터베이스는

• 연결된 노드 따라가기

방식으로 탐색이 가능하다.

관계를 따라 이동하는 작업 자체에 최적화된 구조인 것이다.

관계 탐색이 필요한 사용처

그래프 데이터베이스는 보통

• 친구 추천 시스템(SNS)
• 콘텐츠 추천 알고리즘
• 네트워크 분석
• 경로 탐색

처럼 “연결 관계”가 핵심인 서비스에서 많이 사용된다.

단점

다만 모든 상황에서 좋은 건 아니다.

그래프 데이터베이스는

• 일반적인 CRUD 작업에는 비효율적일 수 있고
• 단순 데이터 저장에는 과한 구조가 될 수 있으며
• 학습 난이도와 설계 난이도가 높은 편

이라는 특징도 존재한다.

그래서 보통은

관계 탐색이 핵심인 특정 문제를 해결하기 위해 사용하는 데이터베이스

라고 볼 수 있다.

5. 데이터를 분석하기 위한 데이터베이스

앞에서 살펴본 데이터베이스들은 공통적으로

서비스를 운영하기 위한 데이터 저장

에 초점이 맞춰져 있었다.

예를 들면

• 사용자 정보 저장
• 습관 데이터 저장
• 로그인 상태 관리

같은 작업들이다.

그런데 서비스 규모가 커지면 단순히 데이터를 저장하는 것을 넘어 데이터를 분석하려는 요구가 생기기 시작한다.

예를 들어

• “유저들이 어떤 기능을 가장 많이 사용할까?”
• “하루 평균 습관 완료율은 얼마일까?”
• “이번 주 활동량은 지난주보다 늘었을까?”

같은 질문들이다.

데이터를 저장하는 것을 넘어 데이터를 통해 흐름과 패턴을 분석하려는 단계로 넘어가는 것이다.

운영 데이터베이스로 분석하면?

물론 기존의 PostgreSQL 같은 관계형 데이터베이스에서도 분석 자체는 가능하다.

하지만 데이터 규모가 커질수록

• JOIN 증가
• 복잡한 집계 쿼리 증가
• 대량 데이터 조회 발생

같은 문제가 생기기 쉽다.

그리고 운영 중인 데이터베이스에서 무거운 분석 작업까지 함께 수행하면 실제 서비스 성능에도 영향을 줄 수 있다.

그래서 대규모 서비스에서는 종종

운영용 데이터베이스와 분석용 데이터베이스를 분리

해서 사용하기도 한다.

컬럼 기반으로 저장하는 방식

이런 분석 작업에 특화된 방식 중 하나가 바로

컬럼형(Column-oriented) 데이터베이스

이다.

대표적으로 Apache Cassandra 같은 계열이 자주 언급된다.

기존 데이터베이스와의 차이점

기존 관계형 데이터베이스는 보통 행(Row) 단위로 저장된다.

id | name | age | habit

즉, 한 줄 안에 하나의 데이터 정보가 모두 들어간다.

반면 컬럼형 데이터베이스는 같은 컬럼끼리 묶어서 저장한다.

id   → [1, 2, 3]
name → [A, B, C]
age  → [20, 25, 30]

같은 종류의 데이터들을 연속적으로 저장하는 구조인 것이다.

장점

이 방식은 특정 데이터만 대량으로 분석할 때 굉장히 강력하다.

예를 들어 “전체 유저 평균 나이 계산” 같은 작업을 수행한다고 하면,

행 기반 저장에서는 모든 row를 읽으면서 필요한 데이터를 꺼내야 한다.

반면 컬럼형 데이터베이스는 age 컬럼만 읽기만 하면 된다.

분석에 필요한 데이터만 빠르게 가져올 수 있기 때문에 대규모 집계와 통계 작업에 정말 유리하다.

분석이 필요한 사용처

이런 데이터베이스는 보통

• 로그 분석
• 통계 처리
• 데이터 시각화
• BI(Business Intelligence)
• 대규모 집계 시스템

같은 분야에서 사용된다.

서비스 기능 자체보다는 데이터를 기반으로 의사결정을 내리기 위한 영역에서 많이 활용된다.

단점

물론 일반 서비스 운영에는 잘 맞지 않는 부분도 존재한다.

• 실시간 CRUD 작업에는 상대적으로 약하고
• 일반적인 서비스 구조와는 사용 방식이 다르며
• 데이터 수정이 잦은 환경에는 비효율적일 수 있다.

그래서 운영 DB랑 분리해서 사용해야 한다.

슬랙, 지라, 리니어 같은 작업 관리 도구부터 프리티어, 린트, 허스키처럼 코드 스타일과 규칙을 관리하는 도구까지.

사실 나는 거의 처음 들어보는 것들이었다. 프리티어 정도만 "저장하면 코드 예쁘게 정리해주는 도구"로만 알고 있었을 뿐이다.

솔직히 충격이었다.

“PR 형식을 자동으로 맞출 수 있다” “컨벤션이 안 맞으면 push 자체가 막힌다”

컨벤션이 안 맞으면 push 자체가 막힌다니. 우린 코드리뷰에서 하나하나 확인하고 알려주기로 했었는데 ...

물론 코드리뷰가 단순히 컨벤션만 보는 과정은 아니지만, 이 부분을 자동으로 처리할 수 있다는 건 꽤 큰 차이라고 느껴졌다.

특히 “push를 막는다”는 표현이 인상적이었다. 단순히 권장하는 수준이 아니라, 아예 지키지 않으면 다음 단계로 못 넘어가게 만든다는 의미니까.

그러던 중 또 다른 팀장님이 이런 말씀을 하셨다.

“나는 자동사냥처럼 돌아가는 구조를 만들어두는 걸 좋아한다”

사실 이번에 처음 듣는 말은 아닌데, 지금 다루려는 협업 도구들이랑 꽤 어울리는 말 같아서 인용해왔다.

나 또한 그렇다. 자동화가 가능하면 몸이 덜 고생하지 않겠는가 !

그런 나에게 이런 "자동으로" PR 형식을 맞춘다거나, 컨벤션이 안 맞으면 "자동으로" push 자체를 막는다거나 정말 매혹적인 말이 아닐 수가 없다.

그래서 그런 도구가 어떤 도구인지 살펴보고 그 외에 또 어떤 도구가 있나도 살펴보고 싶어서 이렇게 블로그 주제로 잡아왔다.

1. 작업 흐름을 보이게 만드는 도구

이번 프로젝트에서는 역할을 비교적 명확하게 나누고, 매일 데일리 스크럼을 진행하면서 작업 상황을 공유했다.

덕분에 협업이 크게 꼬이는 경험은 하지 않았다.

다만 느낀 건, 이 흐름을 사람이 계속 직접 관리하고 있었다는 점이다.

누가 어떤 작업을 하고 있는지, 어디까지 진행됐는지, 막힌 부분은 없는지 이런 것들을 매번 대화를 통해 확인해야 했다.

협업 도구는 이 과정을 시스템으로 대신해준다.

작업을 이슈 단위로 나누고, 진행 상태를 시각적으로 보여주고, 누가 무엇을 맡고 있는지 한눈에 파악할 수 있게 해준다.

즉, 매번 묻고 확인하지 않아도 흐름 자체가 자연스럽게 공유되는 구조가 된다.

물론 소통을 통한 방식도 충분히 협업을 굴릴 수 있고, 팀 분위기를 만드는 데에도 중요한 역할을 한다.

다만 이 흐름을 전적으로 사람에게만 의존하게 되면 상황에 따라 관리가 어려워질 수 있다.

그래서 이런 과정을 도구가 함께 담당해준다면 더 안정적이고 효율적인 협업이 가능해진다.

결국 협업 도구는 단순한 편의 기능이 아니라,

작업 흐름 자체를 관리해주는 역할을 한다.

GitHub Issues

이번 프로젝트에서는 GitHub의 Issues 기능을 활용해서 작업을 관리했다.

각자 해야 할 일을 이슈 단위로 정리하고, 관련된 PR을 연결하는 방식으로 작업을 진행했다.

코드를 관리하는 GitHub 안에서 바로 사용할 수 있다는 점이 편리했고, 이슈와 PR이 자연스럽게 연결되기 때문에 작업 흐름을 따라가기도 쉬웠다.

다만 첫 프로젝트였던 만큼 이 기능을 충분히 활용하지는 못했던 것 같다.

작업 흐름을 관리하기보다는 칸반 보드처럼 간단히 정리하거나 기록을 남겨두는 용도로 사용하는 데에 더 집중했던 느낌이었다.

다음은 보다 체계적으로 작업 흐름을 관리할 수 있는 도구들을 다뤘다.

Jira

지라는 이러한 이슈 기반 작업 관리를 더 체계적으로 확장한 도구다.

작업을 단순히 나열하는 것이 아니라, 진행 상태를 단계별로 나누고 보드 형태로 시각화해서 팀 전체 흐름을 한눈에 파악할 수 있게 해준다.

또한 스프린트 관리나 자동화 기능 등 협업을 위한 다양한 기능을 제공한다는 점에서 보다 구조적인 작업 관리 도구라고 볼 수 있다.

Linear

리니어 역시 이슈 기반으로 작업을 관리하는 도구다.

지라와 유사한 역할을 하지만, 보다 가볍고 직관적인 사용성을 강조한 도구로 알려져 있다.

복잡한 설정 없이도 빠르게 작업을 관리할 수 있어서 소규모 팀이나 스타트업에서 많이 사용되는 편이다.

결국 지라와 리니어는 작업을 ‘흐름’으로 관리한다는 점에서는 동일한 도구들이다.

Slack

이슈 기반으로 작업을 관리하는 것과 별개로, 팀원 간의 소통을 담당하는 도구도 필요하다.

슬랙은 채널을 통해 대화를 주제별로 나눌 수 있어 공지, 작업 공유, 질문 등을 구분해서 관리할 수 있다.

이 덕분에 대화가 뒤섞이지 않고, 필요한 정보를 빠르게 찾을 수 있다.

결국 슬랙은 팀의 소통을 구조화해주는 도구라고 볼 수 있다.

2. 코드 스타일을 맞춰주는 도구

협업을 하다 보면 생각보다 자주 부딪히는 문제가 하나 있는데, 바로 코드 스타일이다.

같은 기능을 구현하더라도 들여쓰기, 세미콜론, 따옴표, 변수명 등 사람마다 코드 스타일이 조금씩 다르다.

이 차이가 쌓이면 코드를 읽기 어려워지고, 리뷰 과정에서도 불필요한 피드백이 반복되게 된다.

물론 컨벤션을 정해서 맞출 수는 있고, 우리 또한 이러한 코드 컨벤션을 정해놓고 프로젝트를 시작했다.

하지만 문제는 서론에서도 말했듯이 이걸 사람이 계속 지켜야 한다는 점이다.

실수로 놓칠 수도 있고, 사람마다 기준이 다르게 적용될 수도 있다.

그래서 등장하는 것이 코드 스타일을 자동으로 맞춰주는 도구다.

Prettier

프리티어는 코드 포맷터다.

쉽게 말하면 코드를 ‘자동으로 정리해주는 도구’다.

저장을 하거나 명령을 실행하면 들여쓰기, 줄바꿈, 따옴표 스타일 등을 미리 정해둔 규칙에 맞게 자동으로 수정해준다.

덕분에 사람이 일일이 신경 쓰지 않아도 코드 스타일이 항상 동일하게 유지된다.

ESLint

ESLint는 코드 검사 도구다.

단순히 스타일을 맞추는 것을 넘어서 코드가 정해진 규칙을 지키고 있는지 확인해준다.

예를 들어 사용하지 않는 변수, 잘못된 문법, 위험한 코드 패턴 등을 미리 잡아낼 수 있다.

즉, 프리티어가 코드를 ‘보기 좋게’ 만들어준다면,

ESLint는 코드를 ‘올바르게’ 유지하도록 도와준다.

3. 규칙을 ‘지키게 만드는’ 도구

드디어 이 파트다. 사실 이 파트가 이번 포스팅의 메인이다.

앞에서 Prettier와 ESLint를 통해 코드 스타일과 규칙을 자동으로 맞출 수 있다는 걸 알게 됐다.

이제 더 나아가 그걸 항상 지키게 만들어야 할 때다.

아무리 좋은 규칙이 있어도 사람이 실수로 놓치거나, 검사를 건너뛰고 넘어가는 상황은 충분히 발생할 수 있다.

결국 중요한 건 규칙을 만드는 것보다, 지키게 만드는 것이다.

이 역할을 해주는 도구가 바로 Husky다.

Husky

Husky는 Git hook을 활용해서 특정 시점에 원하는 작업을 자동으로 실행할 수 있게 해주는 도구다.

예를 들어 코드를 push 하기 전에

• Prettier 실행
• ESLint 검사

같은 작업을 자동으로 돌릴 수 있다.

그리고 만약 이 과정에서 컨벤션이 맞지 않거나 오류가 발생하면

push 자체를 막을 수 있다 !

즉, 단순히 “검사해주는 도구”가 아니라 규칙을 지키지 않으면 다음 단계로 못 넘어가게 만드는 장치다.

4. 더보기

앞에서 살펴본 도구들은 협업에서 자주 사용되는 기본적인 도구들이다.

하지만 찾아보면 이 외에도 협업을 더 효율적으로 만들어주는 도구들이 정 말 많다.

GitHub Actions

GitHub Actions는 코드를 push 하거나 PR을 생성했을 때

• 테스트 실행
• 빌드
• 배포

같은 작업을 자동으로 수행할 수 있게 해주는 도구다.

즉, 사람이 직접 실행하지 않아도 코드가 올라가는 순간 자동으로 검증과 배포가 이루어진다.

이 도구와 밑에서 다룰 Commitlint는 다른 팀장님이 알려줬던 도구는 아닌데, 이 도구가 정말 너무 충격적이었어서 어떤 식으로 흘러가는 건지 더 알아봤다.

1. 이벤트 발생

먼저 코드 push 혹은 PR 생성과 같은 상황이 생기면 시작된다.

2. 가상 컴퓨터를 하나 띄우기

GitHub가 아무것도 없는 깨끗한 상태의 "임시 서버"를 하나 만들어준다.

3. 코드 가져오기

말 그대로 내 레포 코드를 그 서버에 복사한다.

4. 테스트 / 검사

여기서 패키지 설치, ESLint 검사, 테스트 실행이 이뤄진다. 하나도 실패하면 워크플로우가 중단되고, PR에 빨간 X 표시가 된다.

5. 빌드

React는 정적 파일로 변환하고, Next는 서버 코드와 번들을 생성한다.

즉 서비스로 돌릴 수 있는 형태로 만드는 과정이다.

6. 배포 (배포 플랫폼 호출 / 서버에 직접 업로드)

이건 방식이 두 가지가 있는데,

Actions가 명령 실행하면 배포 플랫폼이 받아서 배포하는 방식과 직접 서버에 파일 던지는 방식으로 진행된다.

Commitlint

Commitlint는 커밋 메시지가 정해진 규칙을 따르고 있는지 검사하는 도구다.

예를 들어 feat: 로그인 기능 추가 같은 형식을 강제할 수 있다.

이렇게 하면 커밋 로그만 봐도 어떤 작업이 이루어졌는지 한눈에 파악할 수 있다.

5. 협업: 자동화 돌리기

앞에서 살펴본 도구들을 실제로 어떻게 연결되는지 얼마나 자동화로 돌려먹을 수 있는지 한 번 정리해보면 이렇다.

1. 작업 정의

GitHub Issues 생성해서 작업 단위를 나눈다.

2. 개발

브랜치를 생성하고 코드 작성한다.

3. commit 단계 (1차 필터)

Husky를 실행하여 Prettier와 ESLint 자동 실행한다.

문제 있으면 commit 자체가 안 된다.

4. PR 생성

협업을 시작한다.

5. GitHub Actions (2차 필터)

GitHub Actions 실행하여

• 패키지 설치
• lint 검사
• 테스트 실행
• build

같은 작업이 자동으로 수행한다.

이 과정에서 하나라도 실패하면 PR에 오류가 표시되고 머지를 할 수 없다.

6. 자동 머지 (옵션)

조건을 만족하면 자동 merge 가능하다.

7. 자동 배포

Vercel / Render 연결하여 완전 자동으로 배포하거나 GitHub Actions 안에서 배포까지 진행해 서버까지 직접 제어한다.

협업 도구를 제대로 구성하면, 개발자는 코드 작성과 PR 생성만 하면 되고 나머지 과정은 모두 자동으로 처리된다.

commit 단계에서 한 번, GitHub Actions에서 한 번 검증을 거친 뒤, 문제가 없을 경우 자동으로 배포까지 이어지는 구조다.

6. 협업은 결국 ‘흐름’을 만드는 일이다

이번에 협업 도구들을 살펴보면서 느낀 건 협업은 단순히 같이 일하는 것이 아니라, 하나의 흐름을 만드는 과정이라는 점이었다.

이슈로 작업을 나누고, 코드 스타일을 맞추고, 규칙을 자동으로 검사하고, 필요한 순간에 자동으로 배포까지 이루어지는 구조.

이 모든 과정이 연결되면서 하나의 자연스러운 흐름이 만들어진다.

그리고 협업 도구들은 이 흐름을 사람이 아닌 시스템이 관리할 수 있도록 도와준다.

물론 도구만으로 협업이 완성되는 것은 아니다.

하지만 최소한 사람이 계속 확인하고 관리해야 하는 부담을 줄여주고, 더 안정적인 협업 구조를 만들 수 있게 해준다.

우린 이러한 관리 외에도 집중해야 할 일이 많으니까 !

리스트를 다루는 기능을 구현하면서 생성, 수정, 삭제 요청을 각각 나눠서 처리해야 하는 상황이 있었다.

처음에는 단순하게 생각했다. 요청을 하나씩 순서대로 보내는 것보다, 한 번에 묶어서 처리하면 더 깔끔하고 효율적일 것 같았다.

특히 생성, 수정, 삭제가 모두 비동기 요청이었기 때문에 이걸 병렬로 처리하면 속도도 더 빨라질 거라고 생각했다.

그래서 자연스럽게 여러 작업을 동시에 처리할 수 있는 방법을 찾게 되었고, 그 과정에서 Promise를 떠올리게 됐다.

예전에 한 번 간단하게 배워본 적은 있었지만, 실제 기능 구현에 제대로 써본 건 이번이 처음이었다.

그래서 이번 기회에 생각나서 생성, 수정, 삭제를 모두 Promise로 묶어서 처리했었고, 하면서 발생했던 일들과 함께 Promise를 다시 한 번 짚고 가려고 한다.

2. Promise 되짚기

Promise는 비동기 작업의 결과를 다루기 위한 객체다.

지금 당장은 결과를 알 수 없지만, 나중에 완료될 작업의 상태를 가지고 있다고 보면 이해하기 편하다.

이 작업은 크게 세 가지 상태로 나뉜다.

• pending: 아직 처리 중인 상태
• fulfilled: 작업이 성공한 상태
• rejected: 작업이 실패한 상태

이 상태에 따라 이후 실행 흐름이 결정된다.

그래서 Promise를 사용한다는 건 단순히 비동기 코드를 작성하는 게 아니라

작업이 끝난 이후 흐름을 어떻게 이어갈지를 정의하는 것에 가깝다.

여기까지는 기본적인 개념이고, 내가 Promise를 떠올리게 된 이유는 조금 달랐다.

나는 이걸 “비동기 처리”보다는 여러 요청을 한 번에 처리할 수 있는 방법으로 먼저 인식했다.

생성, 수정, 삭제 요청을 각각 분기해서 진행해야 하니까 한 번에 묶어서 처리하면 더 효율적일 것 같았고, 그 과정에서 자연스럽게 Promise를 사용하게 됐다.

즉, 처음에는 Promise를 병렬 처리를 위한 도구로 생각하고 접근했던 것이다.

3. Promise와 생긴 일

Promise를 사용해서 생성, 수정, 삭제 요청을 한 번에 묶어서 처리했다.

처음에는 별생각 없었다. 코드도 깔끔히 설계했던 대로 분기해서 처리하고, 처리 속도도 병렬로 처리하니까 빨라졌을 것이다.

그런데 이상한 문제가 발생하기 시작했다.

분명 내가 입력한 순서대로 생성 요청을 보냈는데, 실제로 반영된 결과를 보면 생성 순서가 매번 뒤죽박죽으로 섞여 있었다.

처음에는 단순히 정렬 문제라고 생각했다.

그래서 데이터를 가져온 뒤에 sort를 적용해서 순서를 맞춰보기도 했고, 다른 방식으로 정렬 기준을 바꿔보기도 했다.

하지만 아무리 정렬을 바꿔봐도 근본적인 문제는 해결되지 않았다.

정렬의 문제가 아니라, 생성 자체가 꼬이고 있었던 것이다.

그렇게 거의 두 시간을 헤매면서, 이게 왜 안 되는지 정확한 원인을 잡지 못한 채 로그만 계속 찍어내고 있었다. 근데 코드를 좀 멀리서 보기 시작하면서 문제가 보였다.

세부적인 로직에서의 문제가 아닌 이걸 어떻게 처리를 하냐로 시야를 멀리 잡았을 때,

그때 문득 떠올랐던 게 Promise였다.

여러 요청을 Promise로 묶어서 실행하면 각 요청이 동시에 실행되고, 먼저 끝난 요청이 먼저 반영되는 구조가 된다.

즉, 내가 보낸 순서와는 상관없이 서버에서 처리되는 순서가 달라질 수 있다는 뜻이었다.

결국 문제는 여기였다.

나는 단순히 요청을 “같이 보냈다”고 생각했지만, 실제로는 각 요청이 독립적으로 경쟁하면서 처리되고 있었던 것이다.

그래서 확인을 위해 생성만 Promise에서 제외하고, 수정과 삭제만 Promise로 처리하도록 구조를 바꿔봤다.

그 결과는 바로 드러났다.

이전까지 계속 꼬이던 생성 순서가 정상적으로 유지되기 시작했다.

그제서야 확실하게 이해할 수 있었다.

생성은 순서가 중요한 작업이었고, 그걸 병렬로 처리하면서 문제가 발생했던 것이다.

4. 수정과 삭제와는 다른 생성

생성만 Promise에서 제외하고 나서야 왜 문제가 발생했는지가 조금 더 명확하게 보이기 시작했다.

겉으로 보면 생성, 수정, 삭제 모두 같은 “비동기 요청”처럼 보였지만, 실제로는 성격이 완전히 다른 작업이었다.

먼저, 생성은 순서 자체가 의미를 가진다.

사용자가 입력한 순서대로 데이터가 쌓이길 기대하기 때문에 이 순서가 깨지면 결과가 어색해질 수밖에 없다.

반면 수정과 삭제는 다르다.

이미 존재하는 데이터를 대상으로 값을 바꾸거나 제거하는 작업이기 때문에 처리 순서가 크게 중요하지 않다.

즉, 생성은 순서가 중요하고, 수정과 삭제는 이미 순서가 정해져 있으니 크게 중요하지 않았다.

이 차이를 고려하지 않고 모든 요청을 동일하게 Promise로 묶어버린 것이 문제였다.

5. 이번에 알게 된 점

이번 경험을 통해 하나 분명해진 게 있다.

Promise는 병렬로 처리해준다고 사용할 도구가 아니라 작업의 성격을 고려해서 선택해야 하는 도구라는 점이다.

정리해보면 기준은 이렇게 나눌 수 있다.

순서가 중요한 작업은 순차적으로 처리하고 서로 독립적인 작업은 병렬로 처리한다.

그리고 가장 크게 느꼈던 건 이거였다. 사실 어떻게 보면 간단한 문제다.

그저 생성에서 순서까지는 미처 생각하지 못해 일어난 문제였다.

아무튼 이번에 나에게 있어 Promise는 코드를 병렬로 처리할 수 있도록 하는 도구가 아니라, 실행 흐름을 어떻게 설계할지 결정하는 도구였다.

우선 팀 프로젝트에서 API base URL를 정했는데, 우리 팀은 이 URL이 /api/~ 로 시작한다.

그래서 fetch를 받을 때 아무 생각도 없이 그냥 /api/~ 로 받아버렸다.

연결을 시도해보니 문제가 발생했다. API 요청을 보냈는데, 원하는 JSON 데이터가 아니라 전혀 다른 응답이 돌아온 거다.

처음에는 백엔드 문제라고 생각했다.

서버가 켜져 있는지 확인하고, 라우팅이 잘못된 건 아닌지 확인해보고.

하지만 서버도 정상 실행에 해당 API 라우트가 제대로 정의되어 있었고 Postman으로 직접 요청을 보내서 응답도 확인해봐도 Postman에서는 정상적으로 JSON 응답이 잘 내려오고 있었다.

그럼에도 불구하고 프론트에서 요청을 보내면 정상적인 응답이 오지 않았다. 네트워크 탭을 열어서 응답을 확인해보니, 내가 받고 있던 건 API 응답이 아니라 HTML 파일이었다.

이 부분에서 해결 방법이 뭔지 찾아보다가, vite.config 파일과 proxy 설정을 건들게 되었다.

2. proxy 설정, 알고 계셨나요?

Vite 개발 서버는 기본적으로 프론트 요청을 처리하기 때문에, /api처럼 백엔드로 보내고 싶은 요청은 별도로 전달해주는 설정이 필요하다.

그게 바로 proxy였다.

server: {
  proxy: {
    '/api': 'http://localhost:8080',
  }
}

설명을 보면, /api로 시작하는 요청을 지정한 백엔드 서버(localhost:8080)로 전달해준다는 의미였다.

정확한 동작 원리를 이해한 상태는 아니었지만, “이걸 적용하면 해결된다”는 흐름을 보고 그대로 적용해봤다.

결과는 바로 나타났다.

이전까지 HTML이 돌아오던 요청이 정상적으로 JSON 데이터를 반환하기 시작한 것이다.

이때는 단순히 문제가 해결됐으니 넘어가자는 생각 뿐이었다.

코드 리뷰를 통해 이 부분에 대한 질문을 받으면서, 그제서야 내가 적용한 방식에 대해 다시 생각해보게 됐다.

사실 우리가 지금까지 학습해온 방식은 풀 URL을 사용하는 방식이었고, 현재 팀 프로젝트 환경에서도 proxy 설정 없이 충분히 동작하는 구조였다.

결국 나는 팀 기준에 맞춰 다시 풀 URL 방식으로 코드를 수정했다.

이 과정을 통해 느낀 건, proxy 설정이 잘못된 접근이었다기보다는 상황에 따라 선택할 수 있는 방식 중 하나였다는 점이다.

지금은 풀 URL을 사용하고 있지만, 이번 경험 덕분에 proxy 설정, 그리고 vite.config에 관해 찾아보게 됐다.

3. proxy가 필요한 상황

그럼 proxy 설정은 언제 사용하는 걸까?

이걸 이해하려면 요청이 어떻게 흐르는지를 먼저 생각해봐야 한다.

프론트는 Vite 개발 서버 위에서 동작하고 있고, 내가 보내는 API 요청도 일단 이 서버를 거치게 된다.

이때 /api처럼 상대 경로로 요청을 보내면, 그 요청은 기본적으로 백엔드가 아니라 프론트 개발 서버로 먼저 전달된다.

그리고 Vite는 이 요청을 백엔드로 넘겨주지 않는다. 별도의 설정이 없다면, 해당 요청을 프론트에서 처리하려고 시도하게 된다.

이 상황에서 등장하는 게 proxy 설정이다.

proxy는 특정 경로(/api)로 들어온 요청을 백엔드 서버로 전달해주는 역할을 한다.

즉,

• /api/... 요청 → 프론트 서버에서 받음
• proxy 설정 → 백엔드(localhost:8080)로 전달

이 흐름이 만들어지는 것이다.

그래서 proxy는 다음과 같은 상황에서 유용하다.

• 프론트와 백엔드를 각각 다른 서버에서 개발할 때
• 상대 경로(/api)를 유지하면서 API를 호출하고 싶을 때
• 개발 환경에서 CORS 문제를 우회하고 싶을 때

반대로,

• 풀 URL(http://localhost:8080/...)로 직접 요청을 보내는 경우라면
• proxy 없이도 충분히 동작할 수 있다

결국 proxy는 필수 설정이 아니라, 개발 환경에 따라 선택할 수 있는 방식 중 하나라고 볼 수 있다.

4. vite.config에서 추가로 다루는 설정들

proxy 설정을 적용하면서 처음으로 vite.config 파일을 제대로 찾아보게 됐는데, 생각보다 다양한 설정들을 만질 수 있었다.

그중에서 몇 가지 설정만 간단히 정리해보면 다음과 같다.

먼저, 개발 서버 포트를 지정하는 설정이다.

server: {
  port: 5173,
}

기본 포트가 정해져 있긴 하지만, 여러 프로젝트를 동시에 실행할 경우 포트를 직접 지정해야 할 상황이 생길 수 있다.

다음은 서버 실행 시 브라우저를 자동으로 열어주는 설정이다.

server: {
  open: true,
}

개발할 때 매번 주소를 입력하는 번거로움을 줄일 수 있어서, 작지만 편의성을 높여주는 설정이다.

또 하나는 import 경로를 정리할 수 있는 alias 설정이다.

resolve: {
  alias: {
    '@': '/src',
  },
}

상대 경로를 계속 이어서 쓰는 대신, @ 같은 별칭을 사용해서 경로를 더 깔끔하게 관리할 수 있다.

마지막으로, 배포 시 경로를 설정하는 base 옵션이 있다.

base: '/my-app/',

로컬에서는 크게 체감되지 않지만, 배포 환경에서는 리소스 경로를 맞추기 위해 필요한 설정이다.

이처럼 vite.config는 단순한 설정 파일이 아니라, 개발 환경 전반을 조정하는 역할을 한다.

그런 나서는 사람이 아니라 굉장한 부담이 함께하는데, 이 또한 성장 중 하나려니 싶어서 부담이고 자시고 모두 안고 가려고 한다.

본론으로 돌아가서 일정 및 R&R을 비롯한 계획서를 작성하고 멘토님께 피드백을 받았는데 멘토님께서 페어 프로그래밍에 대해 언급해주셨다.

그래서 주제로 잡고 한 발자국 나아가려고 한다!

1. 혼자 개발하는 방식에서 벗어나기

혼자 개발할 때의 한계

처음엔 강의도 혼자 듣고, 과제도 혼자 풀면서 당연히 혼자 개발하는 게 기본이다.

근데 어느 순간부터 이상한 느낌이 온다.

• 이 코드가 맞는지 확신이 없음
• 더 좋은 방법이 있는지 모르겠음
• 그냥 "돌아가니까 OK" 상태가 됨

이게 반복되면 뭐가 생기냐면 성장이 멈춘 느낌을 받게 된다.

한계의 이유

혼자 개발하게 되면 아래와 같은 구조를 갖게 된다.

1. 내가 생각
2. 내가 작성
3. 내가 검증

이게 문제로 작용한다.

누가 틀렸는지 체크해주는 사람이 없고, 다른 시각이 들어올 틈이 없다.

비유해보자면 혼자 시험 보고, 혼자 채점하는 상황이다. 틀려도 모르고, 맞아도 왜 맞는지 모른다.

그래서 등장한 방식이 페어 프로그래밍이다.

혼자 하는 게 아니라 처음부터 같이 생각하고 같이 만드는 방식이다.

2. 같이 코딩처럼 보이는 오해

처음 들으면 그냥 이렇게 생각하기 쉽다

둘이 앉아서 같이 코딩하는 거 아닌가?

둘이 같은 내용을 각자 나눠서 코딩하는 방식이라면 그건 오히려 비효율적인 중복 작업에 가깝다.

실제로 모습만 보면 비슷하게 오해할 만하다.

하지만 서로의 역할이 확실하게 구분된다.

페어 프로그래밍은 한 명이 키보드를 잡고 코드를 작성하고, 다른 한 명이 옆에서 화면을 보며 함께 진행하는 구조다.

그냥 같이 있는 게 아니라 역할이 나뉘어 있다는 것이 포인트다.

Driver / Navigator 역할

페어 프로그래밍은 기본적으로 역할이 두 개다.

• Driver → 직접 코드 작성하는 사람
• Navigator → 옆에서 방향 잡는 사람

여기서 많이 오해하는 게 있는데

Driver는 단순히 코드만 작성하는 사람이 아니라

왜 이렇게 작성하는지 설명하면서 코드를 짜야 한다.

Navigator도 그냥 구경하는 사람이 아니고

• 이 방식이 맞는지
• 더 좋은 방법이 있는지
• 놓친 부분이 없는지

이걸 계속 생각해야 하는 역할이다.

중요한 건 역할이 아니라 "생각의 흐름"

여기서 진짜 중요한 포인트가 하나 있다.

둘이 코드를 나눠서 만드는 게 아니라

생각을 같이 끌어내는 구조다.

혼자 할 때는 머릿속에서만 생각하고 끝났던 것들이 말로 설명되고 바로 피드백 받고 다시 수정되는 흐름이 생긴다.

이게 핵심이다.

이런 구조로 인한 변화

이 구조 때문에 생기는 변화가 있다.

• 애매하게 알고 있던 게 바로 들킨다.
• 그냥 감으로 짜던 코드가 설명 가능한 코드로 바뀐다.
• 선택 하나하나에 이유가 붙기 시작한다.

결국 코드 퀄리티보다 먼저 생각하는 방식 자체가 바뀐다.

3. 실제 진행 방식

한 기능을 같이 끝까지

페어 프로그래밍은 중간에 나눠서 하는 방식이 아니다.

하나의 기능을 처음부터 끝까지 같이 만든다.

예를 들어 상품 등록 기능을 하나 만든다면 API 설계부터 UI까지 전부 같이 진행하는 구조다. 이 과정 자체가 페어 프로그래밍의 핵심이다.

시작은 항상 "같이 생각"부터

바로 코드부터 치지 않는다.

먼저 어떻게 만들지, 어떤 방식이 좋을지 같이 이야기하면서 방향을 잡는다.

이 과정이 없으면 그냥 둘이 앉아 있는 혼자 개발이랑 다를 게 없다.

코드 작성도 혼자가 아니라 같이

코드를 작성하는 순간에도

한 명만 생각하는 게 아니다.

코드를 작성하면서 왜 이렇게 짜는지 설명하고 옆에서는 계속 질문하고 체크한다.

이게 계속 반복된다.

중간중간 계속 수정되는 방향

혼자 개발할 때는 한 번 정한 방향을 끝까지 밀고 가는 경우가 많다.

근데 페어 프로그래밍은 다르다.

• 더 좋은 방법이 나오면 바로 바꾸고
• 놓친 부분이 있으면 바로 잡는다.

즉 계속 방향을 조정하면서 진행한다.

처음 하면 느껴지는 특징

처음 하면 대부분 이렇게 느낀다.

• 느리다
• 답답하다
• 혼자 하는 게 더 빠르다.

근데 이게 정상이다.

왜 이렇게 만드는지 이해하고 그 과정을 공유하는 게 목적이다.

그래서 결과적으로는 코드를 만드는 과정 자체가 달라진다.

4. 해보면 얻을 수 있는 것들

강제로 넓어지는 시야

혼자 개발할 때는 내가 아는 방식 안에서만 선택하게 된다.

근데 페어 프로그래밍을 하면 다른 사람이 생각하는 방식을 계속 보게 된다.

• 같은 문제를 다르게 접근하는 방식
• 내가 생각 못한 구조
• 더 단순한 해결 방법

이게 계속 들어온다.

그래서 자연스럽게 "내 방식 하나"에서 "여러 선택지"로 바뀐다.

바로 들춰지는 애매한 이해

혼자 할 때는

• 대충 아는 상태
• 감으로 짠 코드

이게 그냥 넘어간다.

근데 페어 프로그래밍은

• 왜 이렇게 짰는지
• 이게 어떻게 동작하는지

이걸 말로 풀어야 한다.

즉 설명을 해야 한다.

이 순간 모르면 바로 티가 난다.

코드에 이유가 생기기 시작한다.

혼자 개발하면 "일단 되게 만드는 코드"가 많다.

근데 페어로 하면

• 이 구조 왜 썼는지
• 이 선택이 맞는지

계속 확인을 받는다.

그래서 모든 코드에 이유가 붙기 시작한다.

줄어드는 실수

혼자 개발하면 내가 놓친 건 끝까지 놓친다.

근데 둘이 보면 한 명이 놓친 걸 다른 한 명이 잡는다.

이게 생각보다 크다.

결국 바뀌는 건 코드가 아닌 사고방식

페어 프로그래밍을 하면 단순히 코드 퀄리티가 좋아지는 게 아니라 생각하는 방식 자체가 바뀐다.

설명 가능한 코드만 쓰게 되고 선택에 근거를 붙이게 되고 더 나은 방법을 계속 고민하게 된다.

이게 핵심이다.

5. 페어 프로그래밍 시작하기

처음부터 완벽 X

페어 프로그래밍이라고 해서 규칙 완벽하게 지키고 역할 정확하게 나누고 이상적인 방식으로 시작하려고 하면

시작도 못한다.

처음은 그냥 "같이 해본다" 수준이면 충분하다.

기능 하나 잡고 같이 해보는 게 시작

가장 현실적인 시작 방법은 이거다.

• 작은 기능 하나 정한다.
• 둘이 같이 붙어서 구현해본다.

예를 들어

• 상품 목록 가져오기
• 검색 기능
• 간단한 폼 처리

이런 것부터 시작하면 된다.

처음엔 어색한 게 정상

처음 하면 무조건 이상하다.

말하면서 코딩하는 게 어색하고 옆에서 보는 것도 어색하고 서로 타이밍도 안 맞는다.

이게 정상이다.

속도보다 "같이 이해하는 경험"에 집중

혼자 하면 더 빠른 건 사실이다.

근데 페어 프로그래밍은 빠르게 만드는 게 목적이 아니다.

왜 이렇게 만드는지 서로 어떻게 생각하는지 이걸 맞춰가는 과정이 핵심이다.

부담을 가지는 순간 오히려 어려워진다.

많이들 여기서 막힌다.

• "내가 못하면 어떡하지?"
• "민폐 아닐까?"

근데 이 구조 자체가 서로 부족한 걸 드러내는 구조다.

그래서 오히려 모르는 걸 말하는 게 맞는 방향이다.

결국 중요한 건 경험

페어 프로그래밍은

설명으로 이해하는 게 아니라 해봐야 이해된다.

한 번만 제대로 해보면 왜 느린지 왜 필요한지 뭐가 달라지는지 바로 체감된다.

실제로 스프린트 강사님이 따라오기 어려운 인원들을 모아 각자의 화면을 공유하면서 함께 실습을 진행하시는데

나는 내 모습이 드러나는 게 부담스러워 쉽게 참여하지 못했다. 그런데 돌아보니 그 방식이 페어 프로그래밍과 꽤 비슷했다.

결국에 내가 애매하게 알고 있는 모습들을 다 들춰내기 위한 방식이었고 내 애매함이 들춰지면 그건 또 성장으로 이어질 것이다.

그래서 멘토님이 페어 프로그래밍 방식을 추천하셨던 것 같다.

그러던 와중에 궁금한 점이 하나 생겼다.

...
const [page, setPage] = useState(1);
const [orderBy, setOrderBy] = useState("recent");
const [keyword, setKeyword] = useState("");

useEffect(() => {
  async function loadProducts() {
    const res = await fetch(
      `https://.../products?page=${page}&pageSize=${pageSize}&orderBy=${orderBy}&keyword=${keyword}`
    );
  }

  loadProducts();
}, [page, pageSize, orderBy, keyword]);
...

위 코드는 useState를 활용한 코드다. 근데 이제 위 코드를 useSearchParams를 활용한 코드로 바꿔보면

...
const [searchParams, setSearchParams] = useSearchParams();

const page = Number(searchParams.get("page")) || 1;
const orderBy = searchParams.get("orderBy") || "recent";
const keyword = searchParams.get("keyword") || "";

useEffect(() => {
  async function loadProducts() {
    const res = await fetch(
      `/products?page=${page}&orderBy=${orderBy}&keyword=${keyword}`
    );
  }

  loadProducts();
}, [page, orderBy, keyword]);
...

이런 식으로 쓰이고, fetch 요청 형식이 똑같다. 그래서 의문이 들었던 게 있었다.

이러면 useSearchParams는 굳이 왜 있는거지?

그래서 옳거니 하고 바로 블로그 주제로 잡았다.

1. 요청 코드가 아니라 상태의 위치 차이

useState를 사용하든, useSearchParams를 사용하든, 결국 fetch 요청을 보면 이렇게 된다.

/products?page=${page}&orderBy=${orderBy}&keyword=${keyword}

서버에서 보내는 요청 형식은 똑같다. 그래서 처음에는 이렇게 생각했다.

둘 다 결국 같은 요청을 보내는 거면 그냥 useState만 써도 되는 거 아닌가?

그런데 여기서 중요한 건 요청 형식이 아니라 값이 어디에서 관리되고 있느냐였다.

useState로 관리하는 경우

const [page, setPage] = useState(1);
const [orderBy, setOrderBy] = useState("recent");
const [keyword, setKeyword] = useState("");

이 값들은 어디에 저장되어 있을까?

정답은 컴포넌트 내부 상태다.

즉 이 값들은 이 컴포넌트가 살아있는 동안만 존재하고 페이지를 새로고침하면 초기화되고 URL 주소에는 아무 정보도 남지 않는다.

이 상태는 컴포넌트 내부에서만 유지되는 상태다.

useSearchParams로 관리하는 경우

const [searchParams, setSearchParams] = useSearchParams();

const page = Number(searchParams.get("page")) || 1;
const orderBy = searchParams.get("orderBy") || "recent";
const keyword = searchParams.get("keyword") || "";

이번에는 값이 어디에 있을까?

이 값들은 컴포넌트 내부 상태가 아니라 URL 쿼리스트링에 저장되어 있다.

주소창을 보면 이렇게 바뀐다.

/products?page=2&orderBy=price&keyword=phone

즉 상태가 컴포넌트가 아니라 URL에 존재하게 된다.

정리하면 차이는 fetch 요청 코드가 아니라 상태가 어디에 저장되는지에 있다.

• useState → 상태가 컴포넌트 안에서 관리됨
• useSearchParams → 상태가 URL 쿼리스트링에서 관리됨

이 차이 때문에 페이지 동작 방식이 완전히 달라진다.

• 새로고침
• 링크 공유
• 뒤로가기
• 앞으로가기
• 북마크
• 탭 복사

이 모든 동작이 URL을 기준으로 동작하기 때문이다.

그래서 검색, 정렬, 페이지 번호 같은 값들은 컴포넌트 상태보다 URL 쿼리스트링으로 관리하는 것이 더 자연스럽다.

2. 컴포넌트 안에만 있으면 생기는 문제

앞에서 정리한 것처럼

• useState → 상태가 컴포넌트 안에서 관리됨
• useSearchParams → 상태가 URL 쿼리스트링에서 관리됨

여기까지 보면 단순히 저장 위치만 다른 것처럼 보일 수 있다. 그런데 이 저장 위치 차이가 실제 동작에서 큰 차이를 만든다.

특히 검색, 정렬, 페이지 번호 같은 값들은 컴포넌트 안에만 있으면 여러 문제가 생긴다.

새로고침하면 사라지는 상태

예를 들어

1. 검색어 입력
2. 정렬 선택
3. 3페이지까지 이동
4. 새로고침

useState로 관리하고 있었다면 상태는 전부 초기화된다.

• 검색어 → 초기화
• 정렬 → 초기화
• 페이지 → 1페이지로 돌아감

왜냐하면 useState는 컴포넌트 내부 메모리에 있는 상태라서 페이지가 새로 로드되면 다시 처음부터 시작하기 때문이다.

반대로 URL에 이렇게 남아 있다면

/products?page=3&orderBy=price&keyword=phone

새로고침을 해도 브라우저는 같은 URL을 다시 요청하고, 컴포넌트는 URL에서 값을 다시 읽어오면 된다.

즉 상태가 유지된다.

링크 공유 불가

이건 실제 서비스에서 중요한 부분이다.

예를 들어 어떤 상품을 검색해서 필터 + 정렬 + 페이지 이동까지 한 상태라고 해보자.

검색어: phone
정렬: 가격순
페이지: 3

이 화면을 다른 사람에게 보여주고 싶어서 주소를 복사해서 보내면 어떻게 될까?

• useState → 상대방은 기본 화면이 뜬다
• useSearchParams → 같은 검색 결과 화면이 뜬다

왜냐하면 상태가 컴포넌트 안에 있느냐, URL에 있느냐의 차이이기 때문이다.

그래서 실제 쇼핑몰, 게시판, 검색 페이지 같은 곳에서는 검색 조건, 정렬, 페이지 번호를 URL 쿼리스트링으로 관리하는 경우가 많다.

뒤로가기 / 앞으로가기 동작 불가

페이지 이동 흐름을 생각해보자

• 1페이지 + 2페이지 → 3페이지

이 상태에서 뒤로가기를 누르면 사용자는 보통 이렇게 기대한다.

• 3페이지 → 뒤로가기 → 2페이지

그런데 상태가 useState에만 있으면 브라우저는 상태 변화를 기억하지 못한다.

왜냐하면 브라우저는 URL 이동 기록만 기억하기 때문이다.

반대로 URL이 이렇게 바뀌고 있었다면

/products?page=1
/products?page=2
/products?page=3

뒤로가기를 누르면 URL이 바뀌고, 우리는 URL에서 page 값을 다시 읽으면 된다.

그래서 뒤로가기와 앞으로가기 동작이 자연스럽게 동작한다.

검색, 정렬, 페이지 번호 같은 값들은 단순히 화면을 위한 상태가 아니라 현재 어떤 페이지 상태를 보고 있는지를 설명하는 상태다.

그래서 이 값들은 컴포넌트 상태가 아니라 페이지 상태라고 볼 수 있다.

그리고 페이지 상태는 컴포넌트 안이 아니라 URL과 함께 움직이는 것이 더 자연스럽다.

그래서 여기서 useSearchParams를 사용하게 되는 거다.

즉 useSearchParams는 단순히 값을 저장하는 도구가 아니라, 페이지 상태를 URL과 동기화하기 위한 도구라고 볼 수 있다.

3. useSearchParams의 존재 이유

앞에서 정리한 내용을 한 번 이어서 생각해보자.

useState로 관리해도 fetch 요청은 만들 수 있다. 그래서 처음에는 useSearchParams가 왜 필요한지 잘 느껴지지 않을 수 있다. 그런데 검색, 정렬, 페이지 번호는 화면 상태가 아니라 페이지 상태다. 페이지 상태는 URL과 함께 관리되는 것이 더 자연스럽다. 그래서 이런 페이지 상태를 관리할 때 useSearchParams를 사용한다.

여기서 중요한 건

useSearchParams는 fetch 요청을 쉽게 만들기 위한 훅이 아니다. URL에 상태를 저장하기 위한 훅이다.

이게 거의 이 글의 핵심이다.

useState vs useSearchParams

여기서 가장 중요한 차이는 useState는 화면(UI)을 위한 상태를 저장하고, useSearchParams는 페이지 상태를 저장한다는 점이다.

언제 무엇을 쓸까

useState를 쓰는 경우

• 모달 열림 / 닫힘
• 드롭다운 열림 / 닫힘
• input 입력값
• 탭 선택
• 체크박스
• 토글 버튼
• hover 상태

→ 화면(UI) 안에서만 필요한 상태

useSearchParams를 쓰는 경우

• 검색어
• 정렬 방식
• 페이지 번호
• 필터 조건
• 카테고리 선택
• 보기 방식 (grid/list)

→ 현재 어떤 페이지 상태를 보고 있는지 설명하는 상태

여기서 기준 문장 하나로 정리하면 좋다.

이 값은 화면 안에서만 필요한 값인가? 아니면 현재 페이지를 설명하는 값인가?

이 질문으로 대부분의 경우 어떤 상태 관리 방법을 써야 할지 결정할 수 있다.

useState와 useSearchParams의 차이는 기능의 차이가 아니라 상태를 저장하는 위치의 차이다.

컴포넌트 내부 상태는 useState로 관리하고, 페이지 상태는 useSearchParams로 관리한다.

처음에는 useState로도 충분히 동작하는 것처럼 보여서 주제를 잡았다. fetch 요청만 보면 useState와 useSearchParams는 큰 차이가 없어 보이기도 한다.

하지만 차이는 요청 방식이 아니라 상태가 어디에 저장되는지에 있었다. 검색, 정렬, 페이지 번호 같은 값들은 단순히 화면을 위한 상태가 아니라 현재 어떤 페이지 상태를 보고 있는지를 설명하는 상태였다.

그래서 이런 값들은 컴포넌트 안이 아니라 URL과 함께 관리되어야 했고, 그 역할을 하는 것이 useSearchParams였다.

결국 React에서 상태를 관리할 때 중요한 것은 어떤 훅을 사용할 것인가가 아니라 이 상태를 어디에 저장해야 하는지를 먼저 생각하는 것이었다.

이전 글에서 살펴봤듯이 React에서 렌더링은 컴포넌트 함수가 다시 실행되는 과정이고, 이 자체는 생각보다 큰 비용이 들지 않는 작업이다.

그렇다면 여기서 자연스럽게 하나의 질문이 생긴다.

그럼 실제로 성능에 영향을 주는 건 무엇일까?

핵심은 렌더링 자체가 아니라, 렌더링 이후 실제 화면을 업데이트하는 과정, 즉 DOM을 다루는 작업이다.

DOM이 왜 문제일까

JavaScript에서 변수 하나 바꾸는 건 가볍다. 하지만 DOM은 다르다.

DOM을 변경하는 순간 브라우저는 단순히 값만 바꾸는 게 아니라 화면을 다시 계산하는 과정을 거친다.

예를 들어 생각해보면 이런 느낌이다.

• JS 연산 → 계산만 하고 끝
• DOM 변경 → 계산 + 화면 다시 그리기

즉 DOM을 건드린다는 것은 단순히 값을 바꾸는 것이 아니라, 브라우저에게 화면을 다시 계산하고 그리도록 요청하는 것과 같다.

그래서 생기는 문제

만약 DOM을 계속 직접 조작하게 되면 어떻게 될까?

element.textContent = "A";
element.textContent = "B";
element.textContent = "C";

이렇게 여러 번 바꾸면 브라우저는 그때마다 화면을 다시 계산하려고 한다.

결과적으로 불필요한 작업이 계속 발생한다.

그럼 단순하게 DOM을 덜 건드리면 되는 게 아닌가 싶은 생각이 들 수 있다. 그래서 이 지점에서 React의 방식이 등장한다.

2. 그래서 등장한: Virtual DOM

앞에서 본 것처럼 문제는 렌더링이 아니라 DOM을 직접 자주 변경하는 것이었다.

그렇다면 해결 방법은 단순하다.

DOM을 바로 건드리지 말고, 한 번 모아서 처리하자

이 아이디어에서 등장한 것이 바로 Virtual DOM이다.

Virtual DOM?

Virtual DOM은 말 그대로 실제 DOM이 아니라, 메모리 위에 만들어진 DOM의 표현(추상화된 구조)다.

React는 상태가 변경되면 새로운 Virtual DOM을 생성하고 이전 Virtual DOM과 비교하여 변경 사항을 계산한다.

구조를 보면 다음과 같다.

1. 컴포넌트 실행
2. 새로운 Virtual DOM 생성
3. 이전 Virtual DOM과 비교
4. 바뀐 부분만 실제 DOM에 반영

이 구조의 존재 가치

핵심은 하나다.

비싼 작업은 최소화하고, 싼 작업은 여러 번 해도 된다

• Virtual DOM 비교 → JS 연산 (가벼움)
• 실제 DOM 변경 → 브라우저 작업 (무거움)

그래서 React는 Virtual DOM을 통해 변경 사항을 여러 번 계산하고 실제 DOM 변경은 필요한 부분에만 최소한으로 적용하는 방식을 선택한 것이다.

이번에도 공사로 비유할 수 있다.

직접 DOM을 건드리는 방식은 수정할 때마다 바로 공사하는 느낌이다. 벽 하나 바뀌면 공사, 창문 하나 바뀌면 또 공사하는 방식이라면,

Virtual DOM은 설계도를 먼저 수정한 뒤, 필요한 부분만 실제 공사에 반영하는 방식이다. 설계도에서 바뀐 부분을 정리하고 실제 공사는 필요한 부분만 진행하는 방식이다.

즉 Virtual DOM은 화면을 그리기 위한 것이 아니라, 변경 사항을 계산하기 위한 중간 단계라고 볼 수 있다.

3. React는 어떻게 최적화하는가

Virtual DOM을 쓴다는 건 알았다. 그럼 중요한 건 이거다.

어떻게 비교하고, 어떻게 최소 변경만 반영할까?

이전 결과 vs 새로운 결과

React는 상태(state)나 props가 변경되어 렌더링이 발생할 때 새로운 Virtual DOM을 만든다.

그리고 그 이전 Virtual DOM과 새로운 Virtual DOM을 비교해서 달라진 부분을 찾는다.

이 과정을 보통 diffing이라고 한다.

diffing?

비교 과정에서 React는 단순히 전체를 바꾸지 않고, 어디가 바뀌었는지를 찾는다.

예를 들어

<h1>Hello</h1>

에서

<h1>Hello World</h1>

로 바뀌었다면

<h1> 요소 자체를 교체하는 것이 아니라 내용만 변경한다고 판단한다.

실제 DOM 반영 (Reconciliation)

diffing으로 변경된 부분을 찾았으면 이제 그걸 실제 DOM에 반영한다.

이 과정을 Reconciliation이라고 한다.

핵심은 필요한 부분만 업데이트한다는 것이다. 요소 타입이 같으면 내부 내용과 속성을 업데이트하고, 요소 타입이 다르면 기존 요소를 제거하고 새로 생성한다.

이 방식 때문에 React는 전체를 다시 그리지 않고 필요한 부분만 변경한다.

즉 다음과 같은 구조가 된다.

1. 렌더링 (계산)
2. Virtual DOM 비교
3. 변경된 부분만 실제 DOM 반영

이게 가능한 이유는 렌더링 과정은 대부분 JavaScript 계산 작업으로 비교적 가볍고, 실제 DOM 변경은 브라우저의 레이아웃과 화면 업데이트 과정이 포함되어 비용이 크기 때문이다.

그래서 React는 렌더링을 다시 수행하여 Virtual DOM을 만들고 변경 사항을 비교하는 과정은 여러 번 수행하되, 실제 DOM 변경은 필요한 부분에만 최소한으로 적용하는 전략을 선택했다.

결국 React는 화면을 바로 변경하는 방식이 아니라, 먼저 Virtual DOM을 통해 변경 사항을 계산하고, 이전 결과와 비교하여 바뀐 부분만 실제 DOM에 반영하는 방식으로 화면을 업데이트한다.

즉 React의 렌더링 구조는 렌더링 → 비교 → 실제 DOM 반영 이라는 단계로 이루어져 있다고 볼 수 있다.

4. 핵심 정리

• DOM을 직접 자주 변경하면 브라우저가 레이아웃 계산과 화면 업데이트를 반복하게 되어 성능 비용이 커진다.
• React는 실제 DOM을 바로 수정하지 않고, Virtual DOM이라는 메모리 위의 DOM 구조를 사용해 변경 사항을 먼저 계산한다.
• 상태(state)나 props가 변경되면 새로운 Virtual DOM이 생성되고, 이전 Virtual DOM과 비교하여 달라진 부분을 찾는다.
• 이 비교 과정은 diffing, 변경된 부분을 실제 DOM에 반영하는 과정은 reconciliation이라고 한다.
• React는 전체 화면을 다시 그리는 것이 아니라 변경된 부분만 실제 DOM에 반영하는 방식으로 동작한다.
• React의 핵심 전략은 렌더링 계산은 여러 번 수행하되, 실제 DOM 변경은 최소화하는 것이다.
• 정리하면 React의 화면 업데이트 과정은 렌더링 → Virtual DOM 비교 → 실제 DOM 반영 단계로 이루어진다.

흔히 아는 렌더링

보통 "렌더링"이라고 하면 화면을 다시 그리는 것이라고 생각하는 경우가 많다.

예를 들어 버튼을 눌렀더니, 화면이 바뀌고 뭔가 새로 그려지는 느낌이다.

그래서 자연스럽게 렌더링은 화면이 바뀐다라고 받아들이게 된다.

React에서의 렌더링

React에서의 렌더링은 조금 다르게 정의해야 한다.

컴포넌트 함수가 다시 실행되는 것

예를 들어 이런 코드가 있다고 해보자.

function App() {
  console.log("렌더링 실행");

  return <h1>Hello</h1>;
}

이 컴포넌트는 처음 실행될 때 한 번 실행되고 끝나는 것이 아니라,

상태가 바뀔 때마다 다시 실행된다.

결과적으로는 화면이 바뀌는 것처럼 보이기 때문에 렌더링을 화면을 다시 그리는 것 정도로만 오해하기 쉽다.

하지만 React 내부에서는

1. 함수 실행
2. 결과 생성
3. (이후 과정 존재)

이 흐름을 먼저 가져간다.

렌더링을 설계도를 만드는 과정으로 생각하면 훨씬 쉬워진다.

• 컴포넌트 실행 = 설계도 다시 만듦
• 화면 변경 = 설계도 실제 반영

즉 렌더링은 화면을 바꾸는 단계가 아니라 결과를 만드는 단계다.

2. React는 언제 다시 실행될까

렌더링이 컴포넌트 함수 실행이라는 것을 알았으니 중요한 질문이 하나 남는다.

그래서 컴포넌트는 언제 다시 실행될까

state가 바뀌면

가장 기본이자 핵심이다.

const [count, setCount] = useState(0);

여기서

setCount(1);

이 순간 컴포넌트 함수가 다시 실행된다.

state를 화면을 결정하는 재료라고 생각하면 편하다. 재료가 바뀌게 된다면 결과를 다시 계산해야 한다.

그래서 화면을 결정하는 state가 바뀌면 컴포넌트 함수가 다시 실행된다.

props가 바뀌면

부모에서 자식으로 데이터를 내려줄 때

<Child value={count} />

부모에서 count가 바뀌면 새로운 props가 전달되면서 자식 컴포넌트도 다시 실행된다.

구조적으로 이런 식이 된다.

1. 부모 실행
2. 새로운 props 전달
3. 자식도 다시 실행

부모가 렌더링되면 자식도 같이

꼭 props가 바뀌지 않아도 실행된다.

예를 들어

function Parent() {
  const [count, setCount] = useState(0);

  return <Child />;
}

여기서 setCount 호출하면 Parent가 다시 실행되고, 그 과정에서 Child도 함께 다시 실행된다.

왜냐하면 React 입장에서는

Parent를 다시 실행되면 그 안에 있는 Child도 다시 실행된다.

이렇게 보는 것이다.

정리하자면 렌더링 트리거는 다음 세 가지로 볼 수 있다.

• state 변경
• props 변경
• 부모 컴포넌트 렌더링

3. 렌더링이 발생하면 벌어지는 일

컴포넌트 함수는 결국 JSX를 반환한다.

function App() {
  return <h1>Hello</h1>;
}

이 코드를 실행하면 결과로 JSX 형태의 구조가 만들어진다.

JSX는 UI를 선언적으로 표현하기 위한 문법이다.

이렇게 보면 된다.

<h1>Hello</h1>

이건 "이런 UI를 만들겠다"라는 설계도에 가까운 표현이다.

이 과정을 정리해보면 다음과 같다.

1. 컴포넌트 실행
2. 새로운 JSX가 생성됨

4. 화면을 업데이트하는 방식

우선 다시 떠올려야 할 것이 있다.

• 렌더링 ≠ 화면 변경
• 렌더링 = 결과 계산

즉 state가 변경되어 컴포넌트가 실행되고, JSX가 생성된 지금 상태는 다음과 같다고 말할 수 있다.

새로운 UI 설계도는 만들어졌는데 아직 실제 화면에는 반영 안 된 상태

필요한 부분만

React는 새로운 결과를 바탕으로 실제 화면을 업데이트한다. 여기서 중요한 건 전체를 다 갈아엎지 않는다는 것이다.

우리가 생각하는 렌더링은 화면 전체를 다시 그리는 방식이다.

하지만 React에서의 렌더링은 결과를 만든 뒤 필요한 부분만 반영하는 과정에 가깝다.

설계도로 다시 비유하자면

• 렌더링 = 새 설계도 작성
• 화면 변경 = 공사

근데 공사를 할 때 건물 전체를 부수는 게 아니라 바뀐 부분만 공사한다.

React도 같은 방식으로 렌더링 이후 이전 결과와 비교해 바뀐 부분만 화면에 반영된다.

5. 렌더링이 많으면 문제가 될까?

많은 사람들이 헷갈리는 부분이다.

렌더링이 많이 발생하면 성능이 나쁜 것 아닐까?

직관적으로는 맞는 말 같다.

자주 실행되고, 많이 반복되면 비효율적이라고 오해하기 쉽다.

React 기준에서 보기

React 기준에서 렌더링 자체는 큰 비용이 드는 작업이 아닐 수 있다.

왜냐하면 렌더링은 기본적으로 컴포넌트 함수 실행 과정이기 때문이다.

진짜 비용이 큰 건 실제 화면(DOM)을 바꾸는 작업으로, 이게 훨씬 무겁다.

그래서 구조는 다음과 같이 봐야 한다.

• 렌더링 (가벼움)
• 실제 화면 변경 (무거움)

그래서 React는 렌더링은 다시 수행하되, 실제 DOM 변경은 최소화하는 방향으로 동작한다.

6. 핵심 정리

• 렌더링은 컴포넌트 함수가 다시 실행되는 것이다.
• state, props, 부모 렌더링에 의해 발생한다.
• 렌더링 결과로 새로운 JSX 구조가 생성된다.
• 이 시점에서는 아직 화면이 바뀌지 않는다.
• 이후 실제 화면이 업데이트되는 과정이 따로 존재한다.
• 렌더링 자체보다 중요한 것은 실제 화면 변경 비용이다.

이번 글의 시작은 "대회에서 멘헤라야차서비스 만든 썰" 라는 게시글이었다.

주제부터 너무 유쾌하고 신박해서 쭉 보다가, 우연히 jQuery와 React를 비교하는 글을 보게 됐다.

사실 아직 나는 개발을 막 시작한 입장에서 두 기술 모두 익숙하지 않다.

jQuery는 스프린트 팀에서 현업 경험이 있으신 분이 주로 사용하셨다고 해서 "이런 게 있구나" 정도로 알고 있었고,

React는 요즘 웹 개발에서 많이 사용되는 UI 라이브러리이며, Next.js와 같은 프레임워크와 함께 사용되는 경우가 많다는 정도만 알고 있었다.

(해당 자료는 해당 링크에서)

근데 이제 통계 자료를 봐도 2026년 1월 1일 기준으로

jQuery는 약 70%, React는 약 6.2%의 웹사이트에서 사용되고 있었다.

물론 React는 상승세이고, jQuery를 포함한 일부 라이브러리는 사용 비율이 감소하는 추세지만 ...

이 숫자만 보면서 자연스럽게 한 가지 의문이 생겼다.

그럼 React보다 jQuery가 더 중요한 기술 아닌가?

이러한 의문이 들어서 두 라이브러리를 조금 더 깊게 알아보게 되었다.

1. 사용률이라는 숫자의 의미

얼마나 쓰이냐 X 얼마나 깔려있냐 O

우리가 처음 통계를 봤을 때는 이렇게 생각하기 쉽다.

jQuery가 70%니까 지금 제일 많이 쓰는 기술이네?

사실 나도 이렇게 생각해서 이 주제를 잡게 됐지만 사실 이 해석은 살짝 빗나갔다.

여기서 말하는 사용률은 현재 개발에서 얼마나 쓰이는가가 아니라 웹사이트에 포함되어 있는가를 의미한다.

왜 이런 차이가 생기는가

웹 서비스는 다른 소프트웨어 분야보다 상대적으로 유지 기간이 긴 편이다.

예를 들어 하나의 사이트가 만들어지면 1~2년 쓰고 버리는 게 아니라 5년, 10년 이상 유지되는 경우가 많다.

특히

• 기업 홈페이지
• 쇼핑몰
• 워드프레스 사이트

이런 것들은 한 번 만들면 계속 유지, 부분 수정하는 구조를 갖는다.

계속 남게 되는 jQuery

과거 웹 개발은 거의 HTML + CSS + jQuery와 같은 구조였다.

이 시기에 만들어진 사이트들이 아직도 살아있기 때문에 jQuery는 계속 통계에 잡힌다.

반대로 React는 비교적 최근에 등장한 기술이기 때문에, 과거에 만들어진 웹사이트에는 포함되어 있지 않은 경우가 많다.

중요한 건 지금 활발하게 쓰고 있어서가 아니라 이미 만들어져 있어서 남아있는 것 이라는 점이다.

비유로 보면 이런 느낌이다.

도로 위 자동차 통계

2005년 아반떼 → 아직도 엄청 많음
최신 전기차 → 점점 늘어나는 중

그래서 통계를 보면 옛날 차가 훨씬 많다고 착각할 수 있다.

하지만 실제 흐름은 신규 프로젝트에서 최신 기술이 주로 선택된다는 점이다.

실제 개발에서는

지금 새로 만드는 웹 서비스는 대부분 이렇게 간다.

• React
• Next.js
• Vue

jQuery로 새 프로젝트를 시작하는 경우는 거의 없다.

즉

• jQuery → "남아있는 기술"
• React → "현재 신규 프로젝트에서 주로 선택되는 기술"

이렇게 보는 게 맞다.

(해당 자료는 해당 링크에서)

이건 또다른 통계자료로 npm 패키지 다운로드 수를 비교한 자료인데, React 관련 패키지의 다운로드 수가 더 높은 흐름을 보이고 있다.

2. 숫자가 다르게 보이는 이유

글을 마무리하고 업로드하려는 과정에서 통계를 보면서 한 가지 더 궁금한 점이 생겨 내용을 보완하기 위해 중간에 섹션을 추가했다.

npm 패키지 다운로드 수를 보면 React가 훨씬 높고, jQuery는 오히려 그보다 낮은 경우가 많다.

그런데 왜 웹사이트 사용률에서는 jQuery가 압도적으로 높게 나오는 걸까?

이건 두 지표가 서로 다른 기준을 가지고 있기 때문이다.

jQuery는 npm을 사용하지 않고도 사용할 수 있다. HTML 파일에서 <script> 태그로 불러오기만 해도 바로 사용할 수 있으며, 이 방식은 과거부터 지금까지 계속 유지되고 있다.

그래서 오래된 웹사이트나 워드프레스 같은 환경에서는 npm을 사용하지 않고도 jQuery가 포함된 경우가 많다.

반면 React는 일반적으로 npm 기반으로 사용된다. 프로젝트를 생성할 때부터 설치가 필요하고, 빌드 과정에서도 계속 사용되기 때문에 다운로드 수가 크게 증가한다.

결국 npm 다운로드 수는 지금 얼마나 활발하게 개발에 사용되고 있는지를 보여주고,

웹사이트 사용률은 이미 웹에 얼마나 많이 포함되어 있는지를 보여주는 지표다.

이 차이를 이해하고 나니 두 통계가 왜 다르게 보이는지 납득할 수 있었다.

따라서 사실상 두 라이브러리를 동일한 기준으로 직접 비교하기는 어렵다. 하지만 웹이 변화하면서 그에 맞는 개발 방식이 바뀌고 있다는 건 뚜렷하기에, React의 사용 흐름이 증가하고 있다는 점은 확인할 수 있다.

3. 지금 만들어지는 웹

아까까지는 웹 전체를 기준으로 통계를 봤다.

그래서 jQuery가 훨씬 많이 쓰이는 것처럼 보였다.

그런데 기준을 지금 새로 만들어지는 웹으로 바꾸면 완전히 다른 흐름이 보이기 시작한다.

예전 웹 vs 지금 웹

과거의 웹은 지금처럼 복잡하지 않았다.

페이지를 이동하면서 내용을 보여주고, 필요할 때 일부 DOM을 수정하는 정도였다.

하지만 지금의 웹은 완전히 다르다.

버튼을 누르면 일부 UI만 바뀌고, 데이터가 바뀌면 화면이 갱신되며, 상태에 따라 화면이 계속 변한다.

이제 웹은 단순한 페이지가 아니라 하나의 애플리케이션처럼 동작한다.

이러한 변화는 개발 방식 자체에도 영향을 주었다.

예전 웹(jQuery) vs 지금 웹(React)

필요한 부분만 직접 찾아서 수정하는 jQuery 방식은 예전 웹에선 크게 문제가 없었다.

하지만 웹의 구조가 점점 변화하면서 jQuery처럼 DOM을 하나씩 직접 수정하는 방식은 수정할 곳이 계속 늘어나고 상태를 관리하기 어려워지고 코드가 점점 복잡해진다.

즉 규모가 커질수록 관리가 어려워진다.

그래서 등장한 방식이 React다.

React는 개발자가 직접 DOM을 조작하기보다는, 현재 상태를 기준으로 UI를 선언적으로 표현하고 상태 변화에 따라 필요한 부분만 업데이트한다.

이때 중요한 것은 상태(state)를 중심으로 UI를 관리한다는 점이다.

즉 상태가 바뀌면, 그 변화에 맞게 UI가 다시 계산되어 화면이 업데이트된다.

정리하면 jQuery는 DOM을 직접 조작하는 방식이고, React는 상태를 기반으로 UI를 선언적으로 구성하는 방식이다.

4. 핵심 정리

• jQuery의 높은 사용률은 현재 활발히 사용된다는 의미가 아니라, 과거에 만들어진 웹이 계속 유지되고 있기 때문이다.
• 사용률 통계는 얼마나 많이 쓰이는가보다 얼마나 포함되어 있는가에 가까운 지표다.
• npm 다운로드 수와 웹사이트 사용률은 서로 다른 기준을 가진 지표이며, 각각 현재 개발 흐름과 누적된 사용 현황을 보여준다.
• 기준을 웹 전체가 아니라 지금 새로 만들어지는 웹으로 바꿔보면 흐름이 완전히 다르게 보인다.
• React는 상태 기반으로 UI를 관리하는 방식이며, 복잡한 인터페이스를 다루기 위해 등장했다.
• 현재 웹 개발은 React와 같은 상태 기반 UI 방식으로 발전하는 흐름을 보이고 있다.
• 결국 기술을 선택할 때는 단순한 사용률이 아니라, 현재의 흐름과 방향을 기준으로 판단해야 한다.

어떻게 보면 당연한 흐름이었다.

기술이 발전하면서 웹사이트에서 요구되는 사항이 많아졌을 것이고, 이에 따라 기존에 사용되던 기술들도 확장이나 변화가 필요해졌을 것이다.

jQuery도 꾸준히 업데이트되고 있지만, 기존 방식의 한계가 있었을 것이다.

React처럼 기존 방식과는 다른 접근이 필요했기에 이러한 변화가 나타나지 않았을까 싶다.

하지만 jQuery의 높은 사용률 통계에 이목이 끌렸고, 이 주제를 깊게 살펴보지 않았다면, 사용률만 보고선 왜 React가 현재 주요 선택지인지 이해하기 어려웠을 것이다.

두 기술을 잘 모르는 상태에서 비교해보는 과정 자체가 의미 있는 학습이 되었다.

근데 영 아닌 거 같아서 이번 글부터 바로 철회했다 ... ...

1. 브라우저가 요청을 보내는 방법

앞선 글에서는 웹이 요청(Request)과 응답(Response) 구조로 동작한다는 것과 브라우저와 서버가 HTTP를 통해 데이터를 주고받는다는 흐름을 살펴봤다.

하지만 그 설명은 어디까지나 통신 구조에 대한 이야기였다.

이제는 한 단계 더 들어가서 JavaScript 코드로 실제 서버 요청을 보내는 방법을 알아볼 차례다.

브라우저에서 서버에 요청을 보내는 방법은 여러 가지가 있지만 현대 웹 환경에서는 fetch API가 기본적인 방식으로 사용된다.

fetch("https://example.com/data");

이 코드 한 줄이 의미하는 것은 단순하다.

이 주소로 요청을 보내라.

브라우저는 이 코드를 실행하면 다음과 같은 일을 한다.

1. JavaScript
2. 브라우저가 HTTP 요청 생성
3. 서버로 요청 전송
4. 서버가 응답 반환

즉 fetch는 단순한 함수처럼 보이지만 실제로는 브라우저에게 서버 요청을 보내라고 지시하는 명령이다.

여기서 중요한 점 하나가 있다.

fetch는 요청을 보내는 것까지만 담당한다.

서버가 어떤 데이터를 보내는지, 응답이 성공인지 실패인지, 데이터를 어떻게 읽어야 하는지는 그 다음 단계에서 처리해야 한다.

그래서 fetch를 사용하면 다음과 같은 흐름이 자연스럽게 이어진다.

1. 요청 보내기
2. 응답 받기
3. 응답 데이터 읽기
4. 필요한 형태로 사용

다음 파트에서는 fetch가 서버 응답을 어떤 형태로 반환하는지를 살펴보자.

바로 Response 객체 이야기다.

2. fetch는 데이터를 바로 주지 않는다

fetch를 실행하면 서버로 요청이 보내진다. 그렇다면 서버가 데이터를 보내주면 바로 사용할 수 있을까?

실제로는 그렇지 않다.

const data = fetch("https://example.com/data");

console.log(data);

이 코드를 실행하면 우리가 기대하는 데이터가 아니라 다음과 같은 값이 출력된다.

Promise { <pending> }

여기서 중요한 사실 하나가 있다.

fetch는 데이터를 바로 반환하지 않는다.

대신 Promise 객체를 반환한다.

이 말은 즉, fetch는 서버 요청을 보내고 Promise를 반환하는 비동기 작업이라는 뜻이다.

그래서 fetch의 기본 구조는 보통 이렇게 사용된다.

fetch("https://example.com/data").then((response) => {
  console.log(response);
});

여기서 response는 서버가 반환한 응답 객체(Response)다.

하지만 여기서 또 하나 헷갈리는 부분이 있다.

response 안에는 우리가 원하는 데이터가 바로 들어있지 않다.

예를 들어 서버가 다음과 같은 JSON 데이터를 보냈다고 가정해보자.

{
  "name": "Alice",
  "age": 25
}

하지만 response를 그대로 출력하면 이 데이터가 바로 보이지 않는다.

그 이유는 서버 응답이 Response 객체 형태로 전달되기 때문이다.

즉 구조는 이렇게 된다.

1. fetch
2. Promise 반환
3. Response 객체 도착
4. JSON 데이터 추출

그래서 우리는 한 번 더 작업을 해야 한다.

바로 응답 데이터를 JSON으로 변환하는 과정이다.

fetch("https://example.com/data")
  .then((response) => response.json())
  .then((data) => {
    console.log(data);
  });

여기서 중요한 포인트가 하나 있다.

response.json() 역시 Promise를 반환한다.

그래서 구조는 사실 이렇게 동작한다.

1. fetch 요청
2. Response 객체 도착
3. JSON 파싱
4. 실제 데이터

그래서 코드에서는 .then()이 두 번 등장한다.

fetch(url)
  .then((response) => response.json())
  .then((data) => {
    // 실제 데이터 사용
  });

처음 보면 이 구조가 조금 이상하게 느껴질 수 있다.

왜냐하면 우리는 보통 이렇게 생각하기 때문이다.

요청 → 데이터

하지만 실제로는 다음과 같은 단계가 존재한다.

1. 요청
2. 응답 객체
3. 데이터 파싱
4. 사용

이 구조를 이해하면 fetch를 사용할 때 왜 .then()이 여러 번 등장하는지 자연스럽게 이해할 수 있다.

3. 데이터를 가져오는 가장 기본적인 요청: GET 요청

서버와 통신할 때 가장 먼저 사용하게 되는 요청은 바로 데이터를 가져오는 요청이다.

REST API에서는 이 역할을 GET 요청이 담당한다.

예를 들어 게시글 목록을 가져오는 API가 있다고 가정해보자.

https://example.com/posts

이 주소로 요청을 보내면 서버는 게시글 데이터를 반환한다.

이 요청을 JavaScript 코드로 작성하면 다음과 같다.

fetch("https://example.com/posts")
  .then((response) => response.json())
  .then((data) => {
    console.log(data);
  });

이 코드의 흐름을 보면 다음과 같다.

1. fetch 요청 전송
2. Response 객체 반환
3. JSON 데이터로 변환
4. 데이터 사용

여기서 중요한 점은 GET 요청은 별도의 옵션 없이 사용할 수 있다는 것이다.

fetch("https://example.com/posts");

이렇게 작성해도 기본적으로 GET 요청이 보내진다.

즉 fetch의 기본 요청 방식은 GET이다.

그래서 데이터를 조회할 때는 보통 다음과 같은 구조를 사용하게 된다.

async function getPosts() {
  const response = await fetch("https://example.com/posts");
  const data = await response.json();

  return data;
}

이렇게 함수를 만들어 두면 다른 코드에서는 다음처럼 사용할 수 있다.

const posts = await getPosts();
console.log(posts);

즉 데이터 조회 요청을 하나의 함수로 정리하면 코드를 훨씬 깔끔하게 관리할 수 있다.

하지만 실제 애플리케이션에서는 여러 개의 요청을 동시에 보내야 하는 상황이 자주 발생한다.

예를 들어

• 게시글 목록
• 사용자 정보
• 댓글 목록

같은 데이터를 동시에 가져와야 할 수도 있다.

이때 사용하는 방법이 바로 다음 파트에서 알아볼 Promise.all이다.

4. 여러 요청을 함께 처리하기: Promise.all

앞에서 살펴본 것처럼 fetch는 Promise를 반환하는 비동기 작업이다. 그래서 서버 요청이 하나일 때는 비교적 단순하게 처리할 수 있다.

하지만 실제 애플리케이션에서는 여러 데이터를 동시에 가져와야 하는 상황이 자주 발생한다.

예를 들어 페이지를 구성하기 위해 다음과 같은 데이터를 가져와야 할 수도 있다.

• 게시글 목록
• 사용자 정보
• 댓글 목록

이때 요청을 하나씩 순서대로 보내면 각 요청이 끝날 때까지 다음 요청을 기다리게 된다.

const posts = await fetch("/posts").then((res) => res.json());
const users = await fetch("/users").then((res) => res.json());
const comments = await fetch("/comments").then((res) => res.json());

이 코드는 동작하지만 실제로는 다음과 같은 흐름으로 실행된다.

1. posts 요청 → 응답 대기
2. users 요청 → 응답 대기
3. comments 요청 → 응답 대기

즉 요청이 순차적으로 실행된다.

하지만 이 세 요청은 서로 의존하지 않는다. 그렇다면 굳이 순서대로 기다릴 필요가 없다.

이럴 때 사용하는 것이 Promise.all이다.

const [posts, users, comments] = await Promise.all([
  fetch("/posts").then((res) => res.json()),
  fetch("/users").then((res) => res.json()),
  fetch("/comments").then((res) => res.json()),
]);

이 코드의 실행 흐름은 다음과 같다.

1. posts, users, comments 요청 동시에 시작
2. 모든 요청이 완료될 때까지 대기
3. 모든 응답이 도착하면 결과 반환

즉 Promise.all은 여러 비동기 작업을 동시에 실행하고, 모든 작업이 완료되면 결과를 반환한다.

그래서 서로 의존하지 않는 요청이라면 순차 요청보다 훨씬 빠르게 데이터를 가져올 수 있다.

여기서 Promise.all의 결과는 배열 형태로 반환된다.

그래서 보통 다음과 같이 구조 분해 할당을 사용해 값을 꺼낸다.

const [posts, users, comments] = ...

이렇게 하면 각각의 데이터에 바로 접근할 수 있다.

5. 서버에 새로운 데이터를 보내기: POST

앞에서는 서버에서 데이터를 가져오는 요청(GET)을 살펴봤다. 하지만 실제 서비스에서는 데이터를 조회하는 것만으로는 충분하지 않다.

예를 들어 다음과 같은 상황을 생각해보자.

• 새로운 게시글 작성
• 회원가입
• 댓글 작성

이런 기능들은 모두 서버에 새로운 데이터를 보내는 작업이다.

이때 사용하는 요청이 바로 POST 요청이다.

fetch로 POST 요청을 보내려면 단순히 URL만 전달하는 것이 아니라 옵션 객체를 함께 전달해야 한다.

fetch("https://example.com/posts", {
  method: "POST",
});

여기서 method는 HTTP 요청 방식을 의미한다.

하지만 실제로는 새로운 데이터를 생성해야 하기 때문에 서버로 데이터를 함께 보내야 한다.

그래서 보통 다음과 같은 형태로 작성한다.

fetch("https://example.com/posts", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    title: "새로운 게시글",
    content: "내용입니다",
  }),
});

method

method: "POST";

요청의 종류를 POST 요청으로 지정한다.

headers

headers: {
  "Content-Type": "application/json"
}

서버에게 어떤 형식의 데이터를 보내는지 알려주는 부분이다.

여기서는 JSON 형식으로 데이터를 보낸다는 의미다.

body

body: JSON.stringify({...})

실제로 서버로 전달되는 데이터다.

여기서 JSON.stringify()를 사용하는 이유는 JavaScript 객체를 JSON 문자열 형태로 변환하기 위해서다.

즉 GET 요청이 데이터 조회라면 POST 요청은 데이터 생성을 담당한다.

하지만 데이터를 생성하는 것만으로는 충분하지 않다.

이미 존재하는 데이터를 수정하거나 업데이트해야 하는 상황도 있다.

6. 데이터를 수정하는 요청: PUT과 PATCH

서버에 데이터를 생성할 때는 POST 요청을 사용한다. 하지만 이미 존재하는 데이터를 수정해야 하는 상황도 자주 발생한다.

예를 들어 다음과 같은 경우다.

• 게시글 내용 수정
• 사용자 정보 변경
• 할 일 목록 상태 변경

이처럼 기존 데이터를 업데이트할 때 사용하는 요청이 PUT과 PATCH다.

두 요청이 모두 데이터 수정이라는 목적은 같지만 수정 방식에서 차이가 있다.

전체를 교체하는 PUT

PUT 요청은 기존 데이터를 새로운 데이터로 전체 교체하는 방식이다.

예를 들어 서버에 다음과 같은 데이터가 있다고 가정해보자.

{
  "id": 1,
  "title": "게시글 제목",
  "content": "내용"
}

이 데이터를 PUT 요청으로 수정하면 기존 데이터를 완전히 새로운 데이터로 덮어쓴다.

fetch("https://example.com/posts/1", {
  method: "PUT",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    title: "수정된 제목",
    content: "수정된 내용",
  }),
});

이 경우 서버는 기존 데이터를 새로운 데이터로 전체 교체하게 된다.

일부만 수정하는 PATCH

PATCH 요청은 데이터의 일부만 수정할 때 사용한다.

예를 들어 제목만 수정하고 싶다면 모든 데이터를 다시 보낼 필요는 없다.

fetch("https://example.com/posts/1", {
  method: "PATCH",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    title: "수정된 제목",
  }),
});

이 경우 서버는 기존 데이터에서 title만 수정하고 나머지 값은 그대로 유지한다.

PUT과 PATCH의 차이

정리하면 다음과 같다.

• PUT → 전체 교체
• PATCH → 일부 수정

그래서 API 설계에 따라 PUT만 사용하는 경우도 있고, PATCH를 함께 사용하는 경우도 있다.

마지막으로 남은 것은 데이터를 삭제하는 요청이다.

7. 데이터를 삭제하는 요청: DELETE

애플리케이션에서는 더 이상 필요하지 않은 데이터를 삭제해야 하는 상황도 자주 발생한다.

예를 들어 다음과 같은 경우다.

• 게시글 삭제
• 댓글 삭제
• 할 일 목록 삭제

이때 사용하는 요청이 바로 DELETE 요청이다.

fetch로 DELETE 요청을 보내는 방식은 비교적 단순하다.

fetch("https://example.com/posts/1", {
  method: "DELETE",
});

이 요청은 다음과 같은 의미를 가진다.

/posts/1 데이터 삭제 요청

서버는 이 요청을 받으면 해당 ID의 데이터를 찾아 삭제 처리를 하게 된다.

DELETE 요청은 보통 삭제할 데이터의 식별자(ID)를 URL에 포함하는 방식으로 사용된다.

예를 들어

/posts/1

이라는 주소는 "ID가 1인 게시글"을 의미한다.

그래서 삭제 요청은 보통 이런 형태로 작성된다.

async function deletePost(id) {
  await fetch(`https://example.com/posts/${id}`, {
    method: "DELETE",
  });
}

이렇게 함수를 만들어 두면 다른 코드에서는 다음과 같이 사용할 수 있다.

await deletePost(1);

즉 서버에게 "ID가 1인 데이터 삭제" 라는 요청을 보내는 것이다.

여기까지 살펴보면 우리는 서버 데이터를 다루는 기본적인 작업을 모두 이해하게 된다.

• GET → 데이터 조회
• POST → 데이터 생성
• PUT → 전체 수정
• PATCH → 부분 수정
• DELETE → 데이터 삭제

이 다섯 가지 요청은 서버 데이터를 관리하는 가장 기본적인 패턴이며 보통 CRUD 작업이라고 부른다.

하지만 실제 서버 통신에서는 요청이 항상 성공하는 것은 아니다.

네트워크 문제나 서버 오류로 인해 요청이 실패하는 상황도 충분히 발생할 수 있다.

8. 요청이 항상 성공하는 것은 아니다: 에러 처리

지금까지는 서버 요청이 정상적으로 동작하는 상황을 기준으로 살펴봤다. 하지만 실제 네트워크 통신에서는 요청이 항상 성공하는 것은 아니다.

예를 들어 다음과 같은 상황이 발생할 수 있다.

• 존재하지 않는 주소로 요청한 경우
• 네트워크 연결이 끊어진 경우
• 서버 내부 오류가 발생한 경우

이처럼 요청이 실패할 가능성이 있기 때문에 서버 통신 코드를 작성할 때는 에러 처리를 함께 고려해야 한다.

fetch를 사용할 때 가장 기본적인 방법은 try...catch를 사용하는 것이다.

async function getPosts() {
  try {
    const response = await fetch("https://example.com/posts");
    const data = await response.json();

    return data;
  } catch (error) {
    console.error("요청 중 오류가 발생했습니다:", error);
  }
}

이 코드에서 try 블록은 정상적인 요청 흐름을 담당한다.

1. fetch 요청
2. 응답 받기
3. JSON 변환
4. 데이터 반환

만약 이 과정에서 오류가 발생하면 catch 블록이 실행된다.

하지만 여기서 한 가지 더 중요한 점이 있다.

fetch는 HTTP 오류를 자동으로 에러로 처리하지 않는다.

예를 들어 서버가 404 Not Found나 500 Internal Server Error를 반환해도 fetch 자체는 성공한 요청으로 처리된다.

그래서 응답 상태를 직접 확인해야 한다.

async function getPosts() {
  const response = await fetch("https://example.com/posts");

  if (!response.ok) {
    throw new Error("서버 요청 실패");
  }

  const data = await response.json();
  return data;
}

여기서 response.ok는 응답 상태 코드가 성공 범위(200~299)인지 확인하는 속성이다.

즉 구조는 이렇게 된다.

1. 요청 전송
2. 응답 도착
3. 응답 상태 확인
4. 데이터 파싱
5. 사용

이 과정을 통해 요청 실패 상황을 보다 안정적으로 처리할 수 있다.

9. 반복되는 fetch를 정리하면: API 함수

지금까지 fetch를 사용해 다양한 서버 요청을 살펴봤다.

하지만 실제 코드에서 매번 이런 요청을 직접 작성하면 코드가 금방 복잡해질 수 있다.

예를 들어 게시글 데이터를 가져오는 코드가 여러 곳에서 필요하다고 가정해보자.

const response = await fetch("https://example.com/posts");
const data = await response.json();

이 코드를 페이지 곳곳에서 계속 작성하게 되면 다음과 같은 문제가 생긴다.

• 같은 코드가 여러 곳에 반복된다
• API 주소가 바뀌면 모든 코드를 수정해야 한다
• 요청 로직을 관리하기 어려워진다

그래서 보통은 서버 요청 코드를 하나의 함수로 정리해서 사용한다.

async function getPosts() {
  const response = await fetch("https://example.com/posts");
  const data = await response.json();

  return data;
}

이렇게 정리해두면 다른 코드에서는 훨씬 간단하게 사용할 수 있다.

const posts = await getPosts();

이 방식의 장점은 명확하다.

먼저 코드 중복을 줄일 수 있다.

서버 요청 로직을 한 곳에 모아두면 같은 코드를 반복해서 작성할 필요가 없다.

또한 유지보수가 쉬워진다.

만약 API 주소가 변경되더라도 함수 내부만 수정하면 된다.

마지막으로 코드 구조가 훨씬 명확해진다.

데이터를 가져오는 코드와 화면을 렌더링하는 코드를 분리할 수 있기 때문이다.

그래서 실제 프로젝트에서는 이런 서버 요청 함수들을 모아서 보통 API 모듈 형태로 관리한다.

api
⎿ getPosts
⎿ createPost
⎿ updatePost
⎿ deletePost

이렇게 요청 로직을 정리하면 애플리케이션 전체에서 일관된 방식으로 서버 통신을 관리할 수 있다.

10. 핵심 정리

• 브라우저는 fetch를 사용해 서버에 요청을 보낼 수 있다.
• fetch는 데이터를 바로 반환하지 않고 Promise를 반환한다.
• 서버 응답은 Response 객체 형태로 전달되며 response.json()으로 데이터를 읽을 수 있다.
• 데이터를 조회할 때는 GET 요청을 사용한다.
• 여러 요청을 동시에 처리할 때는 Promise.all을 사용할 수 있다.
• 데이터를 생성할 때는 POST 요청을 사용한다.
• 데이터를 수정할 때는 PUT(전체 수정)과 PATCH(부분 수정)을 사용한다.
• 데이터를 삭제할 때는 DELETE 요청을 사용한다.
• 서버 요청은 실패할 수 있으므로 에러 처리가 필요하다.
• 반복되는 fetch 코드는 API 함수로 정리하면 관리하기 쉬워진다.

JavaScript에서 값을 저장하려면 변수에 값을 할당(assignment)해야 하며, 이를 위해 먼저 변수를 선언(declaration)한다. 그리고 JavaScript에는 변수를 선언하는 세 가지 방법이 있다.

• var
• let
• const

지금은 대부분 let과 const를 사용하지만 JavaScript가 처음 등장했을 때는 var 하나만 존재했다.

즉 초기 JavaScript에서는 모든 변수를 이렇게 선언했다.

var name = "Alice";
var age = 20;

당시에는 문제가 없어 보였지만 프로그램 규모가 커지면서 var가 여러 문제를 만들기 시작했다.

JavaScript 초창기: var

JavaScript는 원래 웹페이지에 동적인 동작을 추가하는 것이었다. 웹페이지에 간단한 동작을 추가하는 것이 목적이었기 때문에 변수 선언 방식도 단순하게 설계되었다.

그래서 변수 선언은 사실상 var 하나로 통일되어 있었다.

var count = 1;
var message = "hello";

하지만 시간이 지나면서 JavaScript는 단순한 스크립트 언어를 넘어 대규모 애플리케이션을 만드는 언어로 발전했다.

이 과정에서 var의 설계가 여러 문제를 만들기 시작했다.

ES6에서 등장한 let과 const

이 문제를 해결하기 위해 ES6(ECMAScript 2015)에서 새로운 변수 선언 방식이 추가된다.

• let
• const

이 두 가지는 단순한 문법 추가가 아니라 스코프와 변수 재선언 문제를 개선하기 위해 도입된 새로운 변수 선언 방식이다.

정리하면 현재 JavaScript에는 다음 세 가지 선언 방식이 존재한다.

• var → 과거 방식
• let → 재할당 가능한 변수
• const → 재할당 불가능한 변수

그리고 현대 JavaScript에서는 대부분 다음과 같은 방식으로 사용된다.

const name = "Alice";
let count = 0;

즉 기본은 const, 값이 바뀌어야 할 때만 let을 사용한다.

var는 과거 코드에서만 볼 수 있는 경우가 많고 새로운 코드에서는 거의 사용하지 않는다.

변수 선언 방식의 변화 이유

핵심 이유는 하나다.

var가 예측하기 어려운 동작을 만들었기 때문이다.

특히 다음과 같은 문제들이 있었다.

• 함수 스코프
• 중복 선언 가능
• 호이스팅

이 문제들이 실제 개발에서 버그의 원인이 되는 경우가 많았고 이를 해결하기 위해 let과 const가 등장하게 된다.

2. var가 만들었던 문제들

초창기 JavaScript에서 var는 유일한 변수 선언 방식이었지만 프로그램 규모가 커지면서 여러 예측하기 어려운 동작을 만들기 시작했다.

대표적으로 다음과 같은 특징들이 이해를 어렵게 만들 수 있다.

• 함수 스코프
• 중복 선언 가능
• 호이스팅

이 세 가지 때문에 코드의 동작을 직관적으로 이해하기 어려워졌다.

블록이 아닌 함수 기준으로 동작하는 스코프

많은 현대 프로그래밍 언어에서는 {} 블록 단위로 스코프가 결정되는 블록 스코프(block scope)를 사용한다.

하지만 var는 그렇지 않다.

var는 블록이 아니라 함수 기준으로 스코프가 결정된다.

if (true) {
  var message = "hello";
}

console.log(message); // hello

if 블록 안에서 선언했는데도 블록 밖에서 변수에 접근할 수 있다.

왜냐하면 var는 블록 스코프가 아니라 함수 스코프이기 때문이다.

그래서 코드가 길어질수록 변수가 어디서 생성된 것인지 파악하기 어려워지는 문제가 생긴다.

같은 변수를 여러 번 선언할 수 있다.

또 하나의 문제는 중복 선언이 가능하다는 것이다.

var name = "Alice";
var name = "Bob";

console.log(name); // Bob

같은 이름의 변수를 다시 선언해도 에러가 발생하지 않는다.

결과적으로 기존 변수는 그냥 덮어쓰이게 된다.

이런 상황에서는 실수로 변수를 다시 선언해도 프로그램이 그대로 실행된다.

즉 버그가 발생해도 바로 알아차리기 어려워진다.

코드 위로 끌어올려지는 호이스팅

var의 또 다른 특징은 호이스팅(hoisting)이다.

호이스팅은 변수 선언이 실제 코드 위치와 관계없이 해당 스코프의 시작 부분에서 선언된 것처럼 동작하는 JavaScript의 동작 방식이다.

console.log(count);

var count = 10;

이 코드는 에러가 나지 않는다.

실제로 JavaScript 엔진이 내부적으로 코드를 다음처럼 처리하기 때문이다.

var count;

console.log(count);

count = 10;

그래서 결과는 undefined가 나온다.

변수가 선언되기 전에 사용했는데도 에러가 발생하지 않고 undefined가 출력된다.

이런 동작은 코드의 실행 흐름을 직관적으로 이해하기 어렵게 만든다.

점차 드물어지는 var

정리하면 var는 다음과 같은 문제를 가지고 있었다.

• 블록이 아닌 함수 기준 스코프
• 중복 선언 가능
• 호이스팅으로 인한 예측 어려움

JavaScript가 점점 대규모 애플리케이션을 만드는 언어로 발전하면서 이 문제들은 실제 개발에서 큰 혼란을 만들었다.

그래서 ES6에서는 이러한 특성으로 인한 혼란을 줄이기 위해 let과 const라는 새로운 변수 선언 방식이 도입되었다.

3. let: 블록 스코프의 등장

var의 특징 중 하나는 스코프가 블록이 아니라 함수 단위로 결정된다는 것이다.

이 문제를 해결하기 위해 ES6에서 등장한 것이 바로 let이다.

let의 가장 중요한 특징은 블록 스코프(block scope)다.

블록 단위로 관리되는 변수

블록 스코프란 {} 블록 안에서 선언된 변수는 그 블록 안에서만 사용할 수 있는 것을 의미한다.

if (true) {
  let message = "hello";
}

console.log(message);

이 코드는 에러가 발생한다.

ReferenceError: message is not defined

왜냐하면 message는 if 블록 안에서만 존재하는 변수이기 때문이다.

이것이 var와 가장 큰 차이다.

var와 let의 스코프 차이

두 코드를 비교해 보면 차이가 더 분명해진다.

if (true) {
  var a = 10;
}

console.log(a); // 10

var는 블록을 무시하고 함수 전체에서 접근 가능하다.

반면 let은 다음과 같다.

if (true) {
  let b = 10;
}

console.log(b); // ReferenceError

let은 블록을 벗어나면 접근할 수 없다.

즉 변수의 사용 범위를 더 안전하게 제한할 수 있다.

재할당은 가능하지만 재선언은 불가능

let은 값을 다시 할당하는 것은 가능하지만 같은 이름으로 다시 선언하는 것은 불가능하다.

let count = 1;
count = 2; // 가능

하지만 다음 코드는 에러가 발생한다.

let count = 1;
let count = 2; // SyntaxError

이 덕분에 실수로 같은 변수를 다시 선언하는 문제를 미리 막을 수 있다.

let이 해결한 문제

let은 var의 설계로 인해 발생할 수 있는 혼란을 줄이기 위해 도입된 변수 선언 방식이다.

• 블록 스코프 지원
• 중복 선언 방지
• 더 예측 가능한 코드 구조

그래서 현대 JavaScript에서는 새로운 코드에서 var 대신 let과 const를 사용하는 것이 일반적인 관례가 되었다.

하지만 여기서 한 가지 질문이 생긴다.

재할당이 가능한 변수라면 값이 바뀌지 않는 변수는 어떻게 관리해야 할까?

이 질문에 대한 답이 바로 const다.

4. const: 변하지 않는 변수

let이 등장하면서 var의 많은 문제가 해결되었지만 여전히 한 가지 고민이 남아 있었다.

값이 절대 바뀌지 않는 변수는 어떻게 표현할까?

이 문제를 해결하기 위해 ES6에서는 const라는 새로운 변수 선언 방식이 추가되었다.

const는 재할당이 불가능하다

const는 한 번 값을 할당하면 다시 재할당할 수 없는 변수다.

const name = "Alice";

name = "Bob"; // 에러 발생

이 코드는 다음과 같은 에러가 발생한다.

TypeError: Assignment to constant variable

즉 const는 재할당이 불가능한 변수다.

선언과 동시에 값 할당

const는 선언할 때 반드시 초기값을 함께 작성해야 한다.

const count = 10;

다음 코드는 에러가 발생한다.

const count; // SyntaxError

왜냐하면 const는 재할당이 불가능한 변수이기 때문에 선언 시점에 초기값이 반드시 필요하기 때문이다.

객체와 배열에서는 조금 다르게 동작한다

여기서 많은 사람들이 헷갈리는 부분이 하나 있다.

const로 선언한 객체나 배열의 프로퍼티나 요소는 변경할 수 있다.

const user = {
  name: "Alice",
};

user.name = "Bob"; // 가능

이 코드에는 에러가 발생하지 않는다.

이유는 const가 객체 내부 값까지 보호하는 것이 아니라 변수의 참조 자체를 변경하지 못하게 하는 것이기 때문이다.

즉 다음 코드는 에러가 발생한다.

const user = { name: "Alice" };

user = { name: "Bob" }; // 에러

객체 자체를 새로운 객체로 바꾸는 것은 불가능하다.

기본이 되어버린 const

현대 JavaScript에서는 변수를 선언할 때 다음과 같은 사용 패턴이 널리 사용된다.

• 기본은 const
• 값이 바뀌어야 할 때만 let
• var는 거의 사용하지 않음

const name = "Alice";
let count = 0;

이 방식은 코드의 의도를 더 명확하게 만든다.

const로 선언된 변수를 보면 "이 값은 바뀌지 않는다"는 것을 바로 알 수 있기 때문이다.

5. 실제로 쓰이는 방식

지금까지 var, let, const의 특징을 살펴봤다면 다음으로 중요한 것은 실제 코드에서 어떻게 사용하는가다.

현재 JavaScript에서는 보통 다음과 같은 기준을 사용한다.

• 기본은 const
• 값이 바뀌면 let
• var는 사용하지 않음

즉 변수 선언의 기본 출발점은 항상 const다.

기본은 const

대부분의 변수는 한 번 값이 정해지면 프로그램 실행 동안 다시 바뀌지 않는 경우가 많다.

예를 들어 이런 값들이다.

const API_URL = "https://api.example.com";
const MAX_COUNT = 10;
const userName = "Alice";

이런 값들은 프로그램 중간에 변경될 필요가 없다.

그래서 처음부터 const로 선언하는 것이 기본적인 방식이다.

값이 바뀌어야 하면 let

반대로 값이 바뀌는 경우에는 let을 사용한다.

예를 들어 카운트 값이나 반복문 변수 같은 경우다.

let count = 0;

count = count + 1;
count = count + 1;

또는 반복문에서도 자주 사용된다.

for (let i = 0; i < 5; i++) {
  console.log(i);
}

이처럼 값이 변하는 변수는 let을 사용한다.

var는 사실상 사용하지 않는다

현대 JavaScript에서는 새로운 코드에서 var를 사용하는 경우가 거의 없다. 이유는 이미 살펴본 것처럼 var의 특성이 코드 이해를 어렵게 만들 수 있기 때문이다.

• 블록 스코프가 없다
• 중복 선언이 가능하다
• 호이스팅으로 예측이 어렵다

그래서 대부분의 코드 스타일 가이드에서는 var 사용을 금지하거나 권장하지 않는다.

현재 JavaScript의 변수 선언 기준

정리하면 현재 JavaScript에서 변수 선언은 다음과 같은 기준으로 사용된다.

const userName = "Alice"; // 기본
let count = 0; // 값이 바뀌는 경우

즉 개발자는 보통 이렇게 생각한다.

이 값이 바뀔까?

• 바뀌지 않는다 → const
• 바뀐다 → let

이 방식이 코드의 의도를 가장 명확하게 표현할 수 있기 때문이다.

6. 핵심 정리

• JavaScript에는 세 가지 변수 선언 방식이 있다: var, let, const
• 초기 JavaScript에서는 var만 존재했지만 여러 설계 특성으로 인해 현대 코드에서는 사용이 줄어들었다
• var는 함수 스코프, 중복 선언 가능, 호이스팅 등의 특징 때문에 예측하기 어려운 코드를 만들 수 있다
• ES6에서 등장한 let과 const는 이러한 특성으로 인해 발생할 수 있는 혼란을 줄이기 위해 추가되었다
• let은 블록 스코프를 가지며 재할당은 가능하지만 재선언은 불가능하다
• const는 재할당이 불가능하며 선언과 동시에 초기화가 필요하다
• 객체나 배열을 const로 선언해도 프로퍼티나 요소 수정은 가능하지만 참조 자체를 바꾸는 것은 불가능하다
• 현대 JavaScript에서는 기본적으로 const를 사용하고, 값이 변경될 경우에만 let을 사용한다
• var는 과거 코드에서 주로 볼 수 있으며 새로운 코드에서는 거의 사용하지 않는다

JavaScript를 공부하다 보면 한 번쯤 이런 상황을 만나게 된다.

const user = { name: "Alice" };

const copy = user;

copy.name = "Bob";

console.log(user.name); //Bob

코드를 보면 user를 copy에 복사한 것처럼 보이지만 실제로는 같은 객체를 참조하게 된다.

그래서 많은 사람들이 이렇게 생각한다.

copy를 수정했으니까 copy만 바뀌겠지?

하지만 실제 결과는 그렇지 않다.

copy.name을 "Bob"으로 바꾸면 같은 객체를 참조하고 있기 때문에 원본인 user.name도 "Bob"으로 바뀐다.

즉 이런 상황이 된다.

• user → name: Bob
• copy → name: Bob

여기서 자연스럽게 이런 질문이 생긴다.

왜 복사했는데 같이 바뀔까?

JavaScript에서 복사는 어떻게 동작하는 걸까?

이 질문의 답을 이해하려면 먼저 JavaScript에서 데이터가 어떻게 저장되는지를 알아야 한다.

특히 중요한 포인트는 하나다.

JavaScript에서 객체 변수에는 객체 자체가 저장되는 것이 아니라 객체를 가리키는 참조 값이 저장된다.

이 개념을 이해하면 왜 이런 일이 발생하는지 바로 보이기 시작한다.

2. JavaScript의 객체 저장법

앞에서 봤던 예제를 다시 보면 이런 코드였다.

const user = { name: "Alice" };
const copy = user;

copy.name = "Bob";

겉으로 보면 user가 copy로 복사된 것처럼 보인다. 하지만 JavaScript 내부에서는 실제로 복사가 일어나지 않는다.

왜냐하면 객체와 배열은 변수에 객체 자체가 저장되는 것이 아니라 객체를 가리키는 참조 값이 저장되기 때문이다.

원시 타입은 값이 복사된다

먼저 원시 타입을 보자.

let a = 10;
let b = a;

b = 20;

console.log(a); //10

이 경우에는 a의 값 자체가 복사된다.

즉 메모리에서는 이렇게 된다.

• a → 10
• b → 10

그래서 b를 바꿔도 a는 영향을 받지 않는다.

객체는 참조가 복사된다

하지만 객체나 배열은 다르게 동작한다.

const user = { name: "Alice" };
const copy = user;

이때 실제 구조는 이런 느낌이다.

user ─┐
      ├──> { name: "Alice" }
copy ─┘

user와 copy가 같은 객체를 가리키고 있는 상태다.

그래서 copy를 수정하면

copy.name = "Bob";

실제로는 같은 객체를 수정하는 것이 된다.

user ─┐
      ├──> { name: "Bob" }
copy ─┘

여기서 중요한 포인트는 객체나 배열에서 =로 대입하면 객체 자체가 복사되는 것이 아니라 같은 객체를 가리키는 참조 값이 복사된다.

그래서 개발에서는 객체를 "진짜로 복사"하는 방법이 필요해진다.

3. 겉만 복사되는 얕은 복사

앞에서 봤듯이 객체를 단순히 대입하면

const copy = user;

이건 복사가 아니라 같은 객체를 가리키는 것이었다.

그래서 개발에서는 객체를 새로 만들어 값을 복사하는 방법을 사용한다. 대표적인 방법이 바로 Spread 문법(...)이다.

const user = { name: "Alice" };

const copy = { ...user };

copy.name = "Bob";

console.log(user.name); // Alice

이번에는 copy를 수정해도 원본인 user는 바뀌지 않는다.

즉 이번에는 정말로 복사가 된 것처럼 보인다.

하지만 여기서 중요한 포인트가 있다.

Spread로 복사한 것은 완전한 복사가 아니라 "얕은 복사"다.

중첩 객체에서 발생하는 문제

객체 안에 객체가 들어 있는 경우를 보자.

const user = {
  name: "Alice",
  address: {
    city: "Seoul",
  },
};

const copy = { ...user };

copy.address.city = "Busan";

console.log(user.address.city); // Busan

이번에는 다시 원본이 같이 바뀌어 버린다.

왜 이런 일이 생길까?

Spread는 객체의 최상위 프로퍼티만 복사하기 때문이다.

즉 구조는 이렇게 된다.

user
 ├ name → "Alice"
 └ address ─┐
            └ { city: "Seoul" }

copy
 ├ name → "Alice"
 └ address ─┘ (같은 객체)

name 같은 원시 값은 새로운 값으로 복사되지만 address 같은 객체는 참조 값이 복사된다.

그래서 copy.address.city를 바꾸면 같은 객체를 보고 있는 user도 같이 바뀐다.

이처럼 객체의 최상위 프로퍼티만 복사되고 내부 객체는 참조가 공유되는 방식을 얕은 복사 (Shallow Copy)라고 한다.

4. 완전히 분리되는 깊은 복사

앞에서 본 얕은 복사는 객체의 최상위 프로퍼티만 복사된다. 그래서 내부에 객체가 있으면 여전히 같은 데이터를 공유하게 된다.

이 문제를 해결하려면 내부 객체까지 전부 새로 복사해야 한다. 이것을 깊은 복사(Deep Copy)라고 한다.

깊은 복사는 객체 내부에 있는 모든 중첩 객체까지 재귀적으로 복사하여 완전히 새로운 객체 구조를 만드는 것이다.

JSON을 이용한 깊은 복사

가장 흔히 사용되는 방법 중 하나는 JSON을 이용하는 방식이다.

const user = {
  name: "Alice",
  address: {
    city: "Seoul",
  },
};

const copy = JSON.parse(JSON.stringify(user));

copy.address.city = "Busan";

console.log(user.address.city); // Seoul

이 방식은 객체를 JSON 문자열로 변환한 뒤 다시 객체로 변환한다. 이 과정에서 직렬화 가능한 데이터만을 기준으로 새로운 객체가 생성된다.

그래서 이제 구조는 이렇게 된다.

user ──> { name: "Alice", address: { city: "Seoul" } }

copy ──> { name: "Alice", address: { city: "Seoul" } }

두 객체가 완전히 분리된 상태다.

그래서 copy를 수정해도 user에는 영향을 주지 않는다.

structuredClone

최근에는 JavaScript에서 깊은 복사를 위한 내장 함수도 제공한다.

const copy = structuredClone(user);

이 함수는 객체 구조를 깊게 복사하도록 설계된 API다.

그래서 JSON 방식보다 더 다양한 데이터 타입을 지원하며 깊은 복사를 수행할 수 있다.

여기까지 정리해봤을 때 흐름이 이렇게 된다.

• 단순 대입 → 참조 공유
• Spread → 얕은 복사
• structuredClone/JSON 방식 → 깊은 복사

5. 실제 개발에서 복사의 중요성

얕은 복사와 깊은 복사는 단순히 문법 문제가 아니라 데이터의 참조 관계와 변경 방식과 연결된 개념이다.

개발을 하다 보면 객체나 배열의 데이터를 변경해야 하는 상황이 자주 생긴다.

예를 들어 어떤 사용자 데이터를 다룬다고 해보자.

const user = {
  name: "Alice",
  age: 25,
};

이 데이터를 수정하면서도 원본 데이터를 유지해야 하는 상황이 생길 수 있다.

그래서 보통은 기존 데이터를 복사한 뒤 후 복사본을 수정한다.

const updatedUser = { ...user };

updatedUser.age = 26;

이렇게 하면 원본 데이터는 그대로 두고 새로운 데이터를 만들어 사용할 수 있다.

이 방식은 특히 다음과 같은 상황에서 중요해진다.

상태 관리

프론트엔드에서는 상태(state)를 관리할 때 기존 데이터를 직접 수정하지 않는 방식을 많이 사용한다.

대신 기존 데이터를 복사하고 필요한 부분만 수정한 뒤 새로운 상태로 교체한다.

이때 얕은 복사/깊은 복사 개념을 이해하지 못하면 의도하지 않게 원본 데이터까지 바뀌는 버그가 생길 수 있다.

데이터 수정 과정

객체 안에 객체가 있는 구조에서는 얕은 복사로 인해 중첩 데이터가 함께 변경되는 문제가 자주 발생한다.

그래서 데이터를 다룰 때는 얕은 복사로 충분한지, 내부 객체까지 복사하는 깊은 복사가 필요한지 상황에 맞게 판단해야 한다.

6. 핵심 정리

• JavaScript에서 객체와 배열 변수에는 객체 자체가 아니라 객체를 가리키는 참조 값이 저장된다.
• 객체나 배열에서 =로 대입하면 객체 자체가 복사되는 것이 아니라 같은 객체를 가리키는 참조 값이 복사된다.
• Spread 문법(...)은 얕은 복사로, 객체의 최상위 프로퍼티만 복사된다.
• 객체 안에 객체가 있는 경우 내부 객체는 여전히 같은 참조를 공유한다.
• 내부 데이터까지 완전히 분리하려면 깊은 복사가 필요하다.
• JSON.parse(JSON.stringify())나 structuredClone() 같은 방법을 사용하면 중첩 객체까지 새로 복사할 수 있다.
• 데이터를 수정할 때 원본을 유지해야 하는 상황에서는 복사 방식에 대한 이해가 중요하다.

처음 JavaScript를 배우면 보통 이런 것들을 만든다.

• 버튼 클릭 이벤트
• DOM 수정
• 애니메이션
• 입력값 처리

이걸 보면 자연스럽게 JavaScript는 화면을 움직이는 언어라고 생각하기 쉽다.

하지만 실제 웹 서비스는 전혀 다른 구조 위에서 움직인다.

예를 들어 이런 기능들을 생각해보자.

• 로그인
• 게시글 목록
• 댓글 작성
• 좋아요
• 상품 주문

이 데이터들은 브라우저 안에 존재하지 않고 모두 서버에 저장되어 있다.

그래서 브라우저는 항상 이런 행동을 한다.

서버에게 요청
→ 데이터 받아오기
→ 화면에 표시

즉 브라우저는 사실 데이터를 가져오는 창구에 가깝다.

조금 다른 비유로 생각해보면 이해가 쉽다. 브라우저를 식당 손님이라고 생각해보자.

손님(브라우저)
→ 주문 요청
→ 주방(서버)
→ 요리 제작
→ 음식 전달

손님은 요리를 만들 수 없고, 주문하는 것만 할 수 있다.

웹도 똑같다. 브라우저는 데이터를 만들지도 못하고, 저장하지도 못하고, 관리하지도 못한다. 이 역할은 모두 서버가 담당한다.

예를 들어 우리가 어떤 사이트에서 게시글 목록을 본다고 생각해보자.

브라우저는 서버에게 이런 요청을 보낸다.

GET /posts

그러면 서버는 이런 데이터를 반환한다.

[
  { "id": 1, "title": "Hello" },
  { "id": 2, "title": "World" }
]

그리고 브라우저는 이 데이터를 받아서 화면에 렌더링한다.

결국 웹은 우리가 처음 생각했던 것처럼

화면 → 기능

이 구조가 아니라

요청 → 응답 → 화면

이 구조로 움직인다.

그래서 웹을 이해할 때는 화면보다 먼저 통신 구조를 이해하는 것이 중요하다.

이제 자연스럽게 다음 질문이 생긴다.

브라우저는 어떤 방식으로 서버에게 요청을 보내는 걸까?

이 질문의 답이 바로 다음에서 등장하는 HTTP다.

2. 웹은 결국 요청과 응답으로 움직인다

앞에서 브라우저는 데이터를 직접 만들거나 저장하지 못한다고 이야기했다. 그래서 브라우저는 항상 서버에게 요청을 보내고, 응답을 받는 방식으로 동작한다.

이때 등장하는 것이 바로 HTTP다.

HTTP는 HyperText Transfer Protocol의 약자로 브라우저와 서버가 데이터를 주고받을 때 사용하는 통신 규칙이다.

조금 쉽게 말하면 브라우저와 서버가 서로 대화할 때 사용하는 약속된 방식이라고 볼 수 있다.

웹에서 어떤 일이 일어나든 결국 이 구조 안에서 움직인다.

브라우저 → 요청(Request)
서버 → 처리
서버 → 응답(Response)
브라우저 → 화면 표시

이 흐름은 우리가 웹에서 하는 거의 모든 행동에 적용된다.

• 페이지를 열 때
• 데이터를 조회할 때
• 게시글을 작성할 때
• 댓글을 수정하거나 삭제할 때

이 모든 과정은 결국 요청과 응답의 반복이다.

그래서 웹을 이해할 때는 페이지나 화면보다 먼저 통신 구조를 이해하는 것이 중요하다.

그리고 여기서 한 가지 질문이 자연스럽게 생긴다.

브라우저는 서버에게 단순히 요청만 보내는 것이 아니라 여러 종류의 행동을 요청할 수 있다.

예를 들어

• 데이터를 가져오는 요청
• 새로운 데이터를 만드는 요청
• 데이터를 수정하는 요청
• 데이터를 삭제하는 요청

같은 것들이다.

그렇다면 브라우저는 이런 다양한 행동을 어떻게 구분해서 요청할까?

이 질문의 답이 바로 다음에서 등장하는 HTTP 메서드다.

3. 같은 주소 다른 행동: HTTP 메서드

웹에서 서버에게 요청을 보낼 때는 항상 URL이 존재한다.

예를 들어 이런 주소가 있다고 가정해보자.

/posts

이 주소는 게시글과 관련된 자원을 의미한다.

하지만 우리는 이 주소에 대해 여러 가지 행동을 할 수 있다.

게시글 목록을 조회할 수도 있고 새로운 게시글을 만들 수도 있고 게시글을 수정할 수도 있고 게시글을 삭제할 수도 있다.

이때 등장하는 것이 바로 HTTP 메서드다.

HTTP 메서드는 같은 주소라도 어떤 행동을 요청하는지 구분하는 역할을 한다.

GET: 데이터를 가져오는 요청

GET은 데이터를 조회할 때 사용하는 메서드다.

예를 들어 게시글 목록을 가져오는 요청은 이렇게 표현된다.

GET /posts

이 요청의 의미는 단순하다.

/posts에 있는 데이터를 보내주세요

GET 요청은 서버의 데이터를 변경하지 않고 데이터를 조회할 때 사용된다.

POST: 새로운 데이터를 만드는 요청

POST는 새로운 데이터를 생성할 때 사용하는 메서드다.

예를 들어 새로운 게시글을 작성할 때는 이런 요청이 만들어진다.

POST /posts

이 요청은 보통 본문(body)에 데이터를 담아 서버로 보낸다.

{
  "title": "Hello",
  "content": "First post"
}

서버는 이 데이터를 받아서 새로운 게시글을 생성한다.

PUT과 PATCH: 데이터를 수정하는 요청

데이터를 수정할 때는 PUT과 PATCH를 사용한다.

두 메서드는 비슷해 보이지만 역할이 다르다.

• PUT → 데이터를 전체 교체
• PATCH → 일부만 수정

예를 들어 게시글을 수정하는 요청은 이렇게 보낼 수 있다.

PATCH /posts/1

이 요청은 게시글 일부 정보를 수정한다는 의미다.

DELETE: 데이터를 삭제하는 요청

DELETE는 데이터를 삭제할 때 사용하는 메서드다.

예를 들어 게시글 하나를 삭제하는 요청은 이렇게 표현된다.

DELETE /posts/1

이 요청의 의미는 간단하다.

id가 1인 게시글을 삭제해주세요

이처럼 HTTP 메서드는 같은 URL이라도 어떤 행동을 할 것인지 구분하는 역할을 한다.

정리하면 다음과 같다.

• GET: 조회
• POST: 생성
• PUT: 전체 수정
• PATCH: 부분 수정
• DELETE: 삭제

그래서 웹 API를 설계할 때는 URL + HTTP 메서드 조합으로 동작을 정의한다.

이제 여기서 또 하나의 궁금증이 생긴다.

우리가 요청을 보냈을 때 서버는 요청이 성공했는지 실패했는지 어떻게 알려줄까?

이 역할을 하는 것이 바로 다음에서 등장하는 HTTP 상태 코드다.

4. 열려라 상태창: HTTP 상태 코드

요청의 결과를 알려주는 숫자

브라우저가 서버에게 요청을 보내면 서버는 단순히 데이터만 보내는 것이 아니라 요청의 처리 결과도 함께 알려준다.

이때 사용하는 것이 HTTP 상태 코드다.

HTTP 상태 코드는 요청이 성공했는지, 문제가 있었는지, 혹은 다른 처리가 필요한지를 나타내는 숫자다.

브라우저는 이 코드를 보고 요청 결과를 판단한다.

대표적인 상태 코드

예를 들어 어떤 페이지를 요청했을 때 서버는 이런 응답을 보낼 수 있다.

200 OK

이 코드는 요청이 정상적으로 처리되었다는 의미다.

하지만 항상 성공하는 것은 아니다. 요청한 데이터가 없거나, 서버에 문제가 생길 수도 있다.

예를 들어 이런 경우가 있다.

404 Not Found

이 코드는 요청한 자원을 서버에서 찾을 수 없을 때 반환된다.

또는 서버 내부에서 오류가 발생하면 이런 응답이 돌아올 수도 있다.

500 Internal Server Error

HTTP 상태 코드는 요청이 어떻게 처리되었는지 알려주는 신호 역할을 한다.

상태 코드는 보통 첫 번째 숫자로 큰 의미를 구분한다.

• 2xx → 요청 성공
• 4xx → 클라이언트 요청 문제
• 5xx → 서버 오류

그래서 브라우저나 JavaScript 코드에서는 이 상태 코드를 확인해서 성공 처리나 오류 처리를 분기하게 된다.

웹 개발을 하다 보면 이 숫자들을 굉장히 자주 보게 된다. 특히 개발자 도구의 Network 탭에서 쉽게 확인할 수 있다.

그렇다면 서버와 통신할 때 URL은 어떤 기준으로 설계해야 할까?

이 질문에서 등장하는 개념이 바로 REST API다.

5. 로마에선 로마법, URL에선 REST API

규칙 없는 URL, 복잡복잡의 지름길

서버와 통신할 때는 항상 URL을 사용한다.

예를 들어 게시글과 관련된 기능을 만든다고 가정해보자.

규칙 없이 API를 만든다면 URL이 이런 식으로 만들어질 수도 있다.

/getPosts
/createPost
/updatePost
/deletePost

이 방식도 동작은 하지만 URL이 행동 중심으로 설계되어 있어 구조가 점점 복잡해질 수 있다.

기능이 많아질수록

/getUserPosts
/createUserPost
/deleteUserPost

처럼 URL이 계속 늘어나게 된다.

그래서 웹에서는 API를 설계할 때 일관된 규칙을 사용하는 접근 방식이 필요해졌다.

여기서 등장한 개념이 바로 REST다.

자원을 기준으로 URL을 설계하는 방식: REST

REST는 Representational State Transfer의 약자로 웹에서 API를 설계할 때 사용하는 규칙이다.

REST의 핵심 아이디어는 단순하다.

URL은 자원을 표현한다.

예를 들어 게시글 API라면 URL은 이렇게 표현된다.

/posts
/posts/1

여기서 /posts는 게시글이라는 자원(resource)을 의미하고 /posts/1은 id가 1인 게시글을 의미한다.

즉 REST에서는 URL이 데이터의 대상을 표현한다.

행동은 URL이 아니라 HTTP 메서드가 담당

REST 구조에서는 행동을 URL에 넣지 않는다.

대신 HTTP 메서드가 그 역할을 담당한다.

예를 들어 게시글 API는 이렇게 표현할 수 있다.

GET /posts
POST /posts
PATCH /posts/1
DELETE /posts/1

여기서 /posts는 게시글이라는 자원을 나타내고 각 요청의 행동은 HTTP 메서드가 결정한다.

그래서 REST API는 보통 이런 구조로 정리한다.

• URL → 자원
• HTTP 메서드 → 행동

이 방식의 장점은 API 구조가 일관되고 이해하기 쉬워진다는 점이다.

그래서 대부분의 웹 서비스는 이와 같은 REST 방식으로 API를 설계한다.

그렇다면 서버는 이런 요청에 대해 어떤 형식으로 데이터를 응답할까?

이때 등장하는 것이 바로 JSON이다.

6. 서버와 브라우저의 PAPAGO: JSON

서로 다른 환경이 데이터를 주고받는 문제

브라우저와 서버는 서로 다른 환경에서 동작한다.

• 브라우저 → JavaScript
• 서버 → 다양한 언어 (Java, Python, Node.js 등)

서로 사용하는 언어가 다르기 때문에 데이터를 그대로 보내면 서로 이해하지 못할 가능성이 생긴다.

예를 들어 JavaScript 객체는 이렇게 생겼다.

const post = {
  id: 1,
  title: "Hello",
};

하지만 이 객체 구조는 JavaScript 문법이다.

서버가 다른 언어로 만들어져 있다면 이 객체를 그대로 이해하기 어렵다.

그래서 웹에서는 데이터를 주고받을 때 모두가 이해할 수 있는 공통 형식을 사용한다.

이 역할을 하는 것이 바로 JSON이다.

데이터를 표현하는 공통 형식: JSON

JSON은 JavaScript Object Notation의 약자로 데이터를 표현하기 위한 텍스트 기반 데이터 형식이다.

JSON의 구조는 JavaScript 객체와 매우 비슷하다.

예를 들어 이런 JSON 데이터가 있을 수 있다.

{
  "id": 1,
  "title": "Hello"
}

이 구조는 언어와 상관없이 텍스트 형태로 데이터를 표현한다.

그래서 브라우저든 서버든 같은 방식으로 데이터를 읽을 수 있다.

즉 JSON은 웹에서 데이터를 주고받을 때 사용하는 공통 언어라고 볼 수 있다.

서버 응답은 대부분 JSON

웹 API를 호출하면 서버는 보통 JSON 형식으로 데이터를 응답한다.

예를 들어 게시글 목록 요청을 보내면 이런 응답이 돌아올 수 있다.

[
  { "id": 1, "title": "Hello" },
  { "id": 2, "title": "World" }
]

브라우저는 이 JSON 데이터를 받아서 JavaScript에서 사용할 수 있는 형태로 변환한 뒤 화면에 렌더링한다.

그렇다면 여기서 한 가지 궁금증이 생긴다.

JSON은 텍스트 기반 데이터 형식이다.

하지만 JavaScript에서는 보통 객체 형태로 데이터를 다룬다.

그렇다면 우리는 객체와 JSON 변환을 어떻게 해야 할까?

이 역할을 하는 것이 바로 다음에서 등장하는 JSON.stringify와 JSON.parse다.

7. 객체와 문자열 사이를 오가는 두 개의 문

앞에서 JSON은 텍스트 기반 데이터 형식이라고 했다.

하지만 JavaScript에서는 보통 데이터를 객체 형태로 다룬다.

예를 들어 이런 데이터가 있다고 해보자.

const post = {
  id: 1,
  title: "Hello",
};

이 객체는 JavaScript에서는 바로 사용할 수 있지만 서버와 통신할 때는 JSON 문자열 형태로 변환해야 한다.

반대로 서버에서 받은 JSON 데이터는 JavaScript에서 사용하려면 객체 형태로 변환해야 한다.

이 변환을 담당하는 것이 바로 JSON.stringify와 JSON.parse다.

객체를 JSON 문자열로: JSON.stringify

JSON.stringify는 JavaScript 객체를 JSON 문자열로 변환하는 함수다.

예를 들어 이런 객체가 있다고 해보자.

const post = {
  id: 1,
  title: "Hello",
};

이 객체를 JSON 문자열로 변환하면 이렇게 된다.

JSON.stringify(post);

결과는 다음과 같다.

{ "id": 1, "title": "Hello" }

이 문자열은 JSON 형식의 데이터이기 때문에 서버로 전송할 수 있다.

그래서 새로운 데이터를 서버로 보낼 때 보통 이런 코드가 등장한다.

fetch("/posts", {
  method: "POST",
  body: JSON.stringify(post),
});

즉 객체 → JSON 문자열 변환을 담당하는 것이 JSON.stringify다.

JSON 문자열을 객체로 바꾸는 JSON.parse

반대로 서버에서 데이터를 받으면 JSON 문자열을 JavaScript 객체로 변환해야 한다.

이때 사용하는 것이 JSON.parse다.

예를 들어 이런 JSON 데이터가 있다고 해보자.

{ "id": 1, "title": "Hello" }

이 데이터를 JavaScript에서 사용하려면 이렇게 변환한다.

JSON.parse(`{"id":1,"title":"Hello"}`);

그러면 결과는 다시 객체 형태가 된다.

{
  id: 1,
  title: "Hello"
}

그래서 JSON.parse는 JSON 문자열 → JavaScript 객체 변환을 담당한다.

두 함수의 역할 정리

정리하면 이 두 함수는 서로 반대 역할을 한다.

• JSON.stringify : 객체 → JSON 문자열
• JSON.parse : JSON 문자열 → 객체

웹 통신에서는 객체와 JSON 사이의 변환이 반복적으로 발생한다.

• 데이터를 보낼 때 → JSON.stringify
• 데이터를 받을 때 → JSON.parse

이 과정을 이해하면 브라우저와 서버 사이의 데이터 흐름이 훨씬 명확해진다.

이제 실제 통신이 어떻게 이루어지는지 브라우저 개발자 도구에서 직접 확인해보자.

8. 진짜 통신은 Network 탭에

지금까지 HTTP, REST API, JSON 같은 개념을 살펴봤다. 하지만 웹에서 실제 통신이 어떻게 이루어지는지는 브라우저 개발자 도구에서 직접 확인할 수 있다.

요청과 응답을 직접 확인하는 곳

브라우저에는 개발자 도구(Developer Tools)라는 기능이 있다. 여기에는 웹 페이지의 동작을 확인할 수 있는 여러 탭이 있는데, 그중 하나가 Network 탭이다.

Network 탭은 브라우저가 서버와 주고받는 모든 요청과 응답을 기록한다.

예를 들어 어떤 웹 페이지를 열면 브라우저는 자동으로 여러 요청을 보낸다.

• HTML 요청
• CSS 요청
• JavaScript 요청
• 이미지 요청
• API 요청

이 요청들은 모두 Network 탭에 기록된다.

요청과 응답의 정보가 모두 보인다.

Network 탭에서 하나의 요청을 선택하면 서버와 통신하면서 오간 여러 정보를 확인할 수 있다.

대표적으로 다음과 같은 것들이 보인다.

• 요청 URL
• HTTP 메서드
• HTTP 상태 코드
• 응답 데이터

예를 들어 API 요청을 확인하면 서버가 반환한 JSON 데이터도 직접 볼 수 있다.

그래서 웹 개발을 하다 보면 Network 탭은 가장 자주 확인하게 되는 도구 중 하나가 된다.

지금까지 살펴본 것들의 연결고리

지금까지 살펴본 개념들은 사실 모두 Network 탭에서 확인할 수 있다.

예를 들어 어떤 API 요청을 보면 다음과 같은 정보가 보인다.

GET /posts
Status: 200
Response: JSON 데이터

여기에서 우리가 앞에서 배운 것들이 모두 등장한다.

• HTTP 메서드
• HTTP 상태 코드
• JSON 응답

즉 Network 탭은 웹 통신이 실제로 어떻게 이루어지는지 보여주는 창이라고 볼 수 있다.

이제 우리는

• 웹이 요청과 응답 구조로 움직인다는 것
• HTTP 메서드로 요청의 행동을 구분한다는 것
• 상태 코드로 요청 결과를 확인한다는 것
• JSON으로 데이터를 주고받는다는 것

까지 살펴봤다.

9. 핵심정리

웹은 단순히 화면을 보여주는 기술이 아니라 브라우저와 서버가 요청과 응답을 주고받는 통신 구조 위에서 동작한다.

브라우저는 서버에게 요청을 보내고 서버는 요청을 처리한 뒤 응답을 반환한다.

이때 브라우저와 서버가 통신할 때 사용하는 규칙이 HTTP다.

HTTP에서는 같은 URL이라도 HTTP 메서드를 통해 요청의 행동을 구분한다.

대표적으로 다음과 같은 메서드들이 있다.

• GET → 데이터 조회
• POST → 데이터 생성
• PUT → 전체 수정
• PATCH → 부분 수정
• DELETE → 데이터 삭제

요청이 처리되면 서버는 HTTP 상태 코드를 통해 요청 결과가 성공인지 실패인지 알려준다.

대표적인 상태 코드 범주는 다음과 같다.

• 2xx → 요청 성공
• 4xx → 클라이언트 요청 오류
• 5xx → 서버 오류

또한 웹에서는 데이터를 주고받을 때 JSON이라는 텍스트 기반 데이터 형식을 사용한다.

JavaScript에서는 JSON 데이터를 다루기 위해 다음 두 가지 변환을 사용한다.

• JSON.stringify: JavaScript 객체 → JSON 문자열
• JSON.parse: JSON 문자열 → JavaScript 객체

마지막으로 브라우저의 Network 탭을 사용하면 이러한 통신 과정을 실제로 확인할 수 있다.

• 요청 URL
• HTTP 메서드
• HTTP 상태 코드
• JSON 응답

즉 웹은 요청 → 처리 → 응답 이라는 흐름 위에서 움직이며 HTTP, REST API, JSON 같은 개념들은 모두 이 통신 구조를 이해하기 위한 핵심 요소들이다.

이 구조를 이해하면 브라우저와 서버 사이에서 데이터가 어떻게 오가는지 훨씬 명확하게 보이기 시작한다.

동기 실행이란

자바스크립트의 기본 실행 방식은 동기 실행(synchronous)다. 여기서 동기 실행은 코드가 작성된 순서대로 하나씩 실행되는 방식을 말한다.

즉 구조는 이렇게 생각하면 된다.

1. 작업 1 끝
2. 작업 2 시작
3. 작업 2 끝
4. 작업 3 시작

앞에 있는 작업이 끝나야 다음 코드가 실행된다.

console.log("1번 작업");
console.log("2번 작업");
console.log("3번 작업");

코드의 작성 순서는 실행 순서다. 이것이 바로 동기 실행의 가장 큰 특징이다.

동기 실행의 특징

직관적인 흐름

코드를 읽는 순서 그대로 실행되기 때문에 이해하기 쉽다

step1();
step2();
step3();

이걸 보면

1. step1
2. step2
3. step3

순서가 100% 보장된다.

쉬운 디버깅

코드가 순서대로 실행되기 때문에 문제가 생겨도 어디서 문제가 생겼는지 찾기 쉽다.

웹에서 동기 방식이 가지는 문제

문제는 시간이 오래 걸리는 작업이 등장할 때 발생한다.

웹에서는 이런 작업이 굉장히 많은데, 예를 들어

• 서버 요청 (API)
• 파일 읽기
• 타이머
• 사용자 입력

이런 작업들은 몇 ms ~ 몇 초가 걸릴 수 있다.

예를 들어 서버 데이터를 가져온다고 해보자.

const data = fetch("https://api.example.com/data");
console.log(data);

만약 이런 작업이 동기 방식으로 실행된다면 API 요청을 보낸 뒤 응답이 올 때까지 기다려야 한다.

그동안 다른 코드는 실행되지 못한다.

즉 이런 상태가 된다.

• 버튼 클릭 안됨
• 스크롤 안됨
• 화면 멈춤

이처럼 하나의 작업이 전체 실행 흐름을 막아버리는 상황을 블로킹(blocking)이라고 한다.

웹은 항상 사용자와 상호작용해야 하는 환경이다.

• 클릭
• 스크롤
• 입력
• 애니메이션
• API 요청

이런 것들이 동시에 발생하는데 동기 방식만 사용하면 브라우저가 계속 멈추는 상황이 발생한다.

그래서 자바스크립트는 시간이 오래 걸리는 작업은 따로 처리하고 끝나고 알려주는 비동기(asynchronous) 방식을 사용한다.

그렇다면 여기서 하나의 질문이 생긴다.

자바스크립트는 한 번에 하나만 실행한다면서 어떻게 비동기가 가능한 걸까?

2. 한 번에 하나만 실행하는 자바스크립트

싱글 스레드 언어

자바스크립트는 싱글 스레드 언어다. 여기서 스레드는 쉽게 말해 작업을 처리하는 흐름이라고 볼 수 있다.

즉 싱글 스레드는 한 번에 하나의 작업만 실행할 수 있다는 의미다.

예를 들어 이런 코드가 있다고 해보자.

function step1() {
  console.log("step1");
}

function step2() {
  console.log("step2");
}

function step3() {
  console.log("step3");
}

step1();
step2();
step3();

실행 순서는 항상 아래와 같다.

1. step1
2. step2
3. step3

왜냐면 자바스크립트는 동시에 여러 작업을 실행하지 못하기 때문이다. 앞에 있는 작업이 끝나야 다음 작업이 실행된다.

그렇다면 앞서 언급했듯이 이런 의문이 생긴다.

자바스크립트는 한 번에 하나만 실행한다면서 어떻게 비동기가 가능한 걸까?

이걸 이해하려면 자바스크립트 실행 구조를 알아야 한다.

Call Stack (콜 스택)

Call Stack은 현재 실행 중인 함수들이 쌓이는 공간이다.

여기서 스택은 "Last In, First Out" 구조를 갖는다. 쉽게 말하면 나중에 들어온 것이 먼저 나가는 구조다.

예를 들어 이런 코드가 있다.

function first() {
  second();
}

function second() {
  console.log("hello");
}

first();

실행 흐름은 다음과 같다.

1. first()
2. second()
3. console.log()

그리고 실행이 끝나면 역순으로 빠져나온다.

1. console.log 종료
2. second 종료
3. first 종료

Call Stack은 항상 함수가 들어오고 실행된 뒤 빠져나가는 구조로 동작한다.

여기까지는 모두 동기적인 실행 구조다.

그런데 자바스크립트에서는 이 흐름을 깨는 것처럼 보이는 코드가 등장한다.

console.log("1");

setTimeout(() => {
  console.log("2");
}, 0);

console.log("3");

실행 결과는 1 → 3 → 2를 갖는다.

코드를 보면 1 → 2 → 3 순서로 실행될 것 같은데 실제로는 3이 먼저 실행된다.

왜 이런 일이 발생하는지, 여기서 등장하는 게 Web API다.

Web API

setTimeout 같은 기능은 자바스크립트 엔진이 직접 처리하는 게 아니다.

브라우저가 대신 처리한다.

흐름은 다음과 같이 진행된다.

1. setTimeout이 Call Stack에서 실행된다
2. 타이머 작업을 Web API에게 맡긴다
3. 타이머가 끝나면 콜백이 Queue로 이동한다

즉 자바스크립트는 "이거 오래 걸리는 작업이니, 브라우저가 대신 하고 끝나면 알려줘" 라고 말하고 있는 것이다.

Callback Queue

타이머가 끝나면 브라우저는 콜백 함수를 Queue에 넣는다.

이 공간을 Callback Queue라고 한다.

Callback Queue

console.log("2")

근데 여기서 중요한 점이 하나 있는데, 콜백 함수는 바로 실행되지 못한다. 왜냐면 자바스크립트는 한 번에 하나만 실행하기 때문이다. 그래서 대기하고 있다.

Event Loop

여기서 등장하는 게 Event Loop다.

Event Loop는 다음 과정을 반복한다.

1. Call Stack 비어있는지 확인
2. 비어있으면 Queue 확인
3. 콜백을 Stack으로 이동
4. 실행

그래서 아까 코드가 이런 식으로 실행됐던 것이다.

1. 1 출력
2. setTimeout → Web API로 이동
3. 3 출력
4. Call Stack 비어 있음
5. Callback Queue 확인
6. 2 실행

그래서 결과가 1 → 3 → 2가 된다.

3. 콜백 함수의 등장

콜백 함수

콜백 함수는 다른 함수에 전달되는 함수다.

즉 함수가 값처럼 전달되는 상황이라고 보면 된다.

예를 들어 이런 코드가 있다.

function greet(name) {
  console.log("Hello " + name);
}

function processUser(callback) {
  const user = "Alice";
  callback(user);
}

processUser(greet);

실행 흐름을 보면 이렇게 된다.

1. processUser 실행
2. greet 함수 전달됨
3. callback(user) 실행
4. greet("Alice") 실행

즉 greet함수는 직접 호출된 것이 아니라 다른 함수에 전달된 뒤 실행된 것이다.

이게 바로 콜백 함수다.

콜백의 핵심 개념: 제어권 전달

콜백에서 가장 중요한 개념은 제어권 전달이다.

일반 함수는 우리가 직접 실행한다.

greet("Alice");

하지만 콜백 함수는 우리가 실행하지 않는다.

processUser(greet);

여기서는 processUser가 언제 실행할지 결정한다.

즉 함수를 넘겨주면 실행 타이밍은 다른 함수가 결정한다.

이렇게 실행 제어가 다른 함수로 넘어가는 것을 제어권이 넘어갔다고 말한다.

비동기에서 콜백이 필요한 이유

비동기에서는 작업이 언제 끝날지 모른다.

예를 들어 이런 작업들이 있다.

• API 요청
• 파일 읽기
• 타이머

이런 작업들은 몇 ms ~ 몇 초 걸릴 수도 있다.

그래서 자바스크립트는 "이 작업 끝나면 이 함수 실행해줘" 라고 생각한다.

이런 코드를 예로 들 수 있다.

setTimeout(() => {
  console.log("2초 후 실행");
}, 2000);

여기서

() => {
  console.log("2초 후 실행");
};

이 함수가 바로 콜백 함수다.

즉 "2초 타이머 끝나면 이 함수 실행" 이라는 의미를 담는다.

결과 전달과 콜백 패턴

비동기 작업은 보통 결과를 콜백으로 전달한다.

function getData(callback) {
  const data = "server data";
  callback(data);
}

getData(function (result) {
  console.log(result);
});

실행 흐름은 이렇게 된다.

1. getData 실행
2. 데이터 생성
3. callback(data)
4. 전달된 함수 실행
5. result 출력

그래서 비동기 코드에서는

작업 실행 → 작업 완료 → 콜백 실행

이런 구조가 자주 나타난다.

하지만 비동기 작업이 여러 개 이어지기 시작하면 코드는 점점 복잡해진다.

4. 어서 오게, 콜백 지옥에

비동기 작업의 순서 문제

비동기 작업은 앞서 꾸준히 언급했듯이 언제 끝날지 알 수 없다.

예를 들어 이런 작업들이 있다고 생각해보자.

• 사용자 정보 가져오기
• 게시글 가져오기
• 댓글 가져오기

이 작업들은 각각 서버 요청이기 때문에 완료되는 시간이 서로 다를 수 있다.

하지만 실제 프로그램에서는 이런 식으로 순서가 필요할 때가 많다.

1. 사용자 정보 가져오기
2. 게시글 가져오기
3. 댓글 가져오기

즉 앞 작업이 끝난 뒤 다음 작업이 실행되어야 한다.

그래서 보통 이렇게 코드를 작성하게 된다.

콜백으로 순서 제어하기

콜백을 사용하면 작업이 끝난 뒤 다음 작업을 실행할 수 있다.

예를 들어 이런 코드다.

getUser(function (user) {
  getPosts(user.id, function (posts) {
    getComments(posts[0].id, function (comments) {
      console.log(comments);
    });
  });
});

실행 흐름은 이렇게 된다.

1. getUser 실행
2. 사용자 데이터 도착
3. getPosts 실행
4. 게시글 데이터 도착
5. getComments 실행
6. 댓글 데이터 도착

즉 작업이 끝날 때마다 다음 작업을 콜백 안에서 실행하는 구조다.

콜백 지옥 (Callback Hell)

문제는 작업이 많아질 때 발생한다.

콜백 안에 또 콜백이 들어가고 그 안에 또 콜백이 들어간다.

작업이 하나라면 괜찮지만, 작업이 계속 이어지기 시작하면 코드 구조가 점점 복잡해진다.

코드는 이렇게 변한다.

getUser(function (user) {
  getPosts(user.id, function (posts) {
    getComments(posts[0].id, function (comments) {
      getLikes(comments[0].id, function (likes) {
        getNotifications(likes.userId, function (notifications) {
          console.log(notifications);
        });
      });
    });
  });
});

코드를 보면 구조가 계속 오른쪽으로 밀리는 특징을 확인할 수 있다. 그래서 이 구조를 피라미드 형태라고 부르기도 한다.

콜백
⎿ 콜백
    ⎿ 콜백
        ⎿ 콜백
            ⎿ 콜백

이렇게 코드가 점점 깊어지는 구조를 Callback Hell (콜백 지옥)이라고 한다.

콜백 방식의 한계

콜백 지옥이 발생하면 여러 문제가 생긴다.

가독성 문제

코드가 오른쪽으로 계속 밀려서 읽기가 매우 어려워진다.

유지보수 문제

콜백 구조가 깊어지면 어떤 작업이 언제 실행되는지 파악하기 어렵다.

에러 처리 문제

비동기 콜백이 많아질수록 에러 처리 구조도 복잡해진다.

그래서 자바스크립트에서는 이 문제를 해결하기 위한 새로운 방식이 등장한다.

5. 해결사 Promise

Promise

콜백 지옥이 발생하는 이유는 비동기 작업의 흐름을 콜백으로 계속 연결해야 하기 때문이다.

즉 작업이 많아질수록 코드는 이렇게 된다.

getUser(function (user) {
  getPosts(user.id, function (posts) {
    getComments(posts[0].id, function (comments) {
      console.log(comments);
    });
  });
});

코드가 계속 오른쪽으로 밀리는 구조가 된다.

그래서 자바스크립트에서는 이 문제를 해결하기 위해 Promise라는 개념이 등장했다.

Promise는 비동기 작업의 결과를 표현하는 객체다.

즉 "미래에 완료될 작업"을 객체 형태로 표현하는 방식이다.

Promise의 세 가지 상태

Promise는 항상 세 가지 상태 중 하나를 가진다.

1. Pending

아직 작업이 완료되지 않은 상태

2. Fulfilled

작업이 성공적으로 완료된 상태

3. Rejected

작업이 실패한 상태

즉 Promise는 Pending 상태에서 Fulfilled, 또는 Rejected 상태로 변경된다.

resolve와 reject

Promise 내부에서는 resolve 함수와 reject 함수를 사용한다.

예를 들어 이런 코드다.

const promise = new Promise((resolve, reject) => {
  const success = true;

  if (success) {
    resolve("작업 성공");
  } else {
    reject("작업 실패");
  }
});

여기서 resolve는 작업 성공을, reject는 작업 실패를 의미한다.

then/catch/finally

Promise는 작업이 끝났을 때 실행할 함수를 연결할 수 있다.

promise
  .then((result) => {
    console.log(result);
  })
  .catch((error) => {
    console.log(error);
  })
  .finally(() => {
    console.log("작업 완료");
  });

각각의 역할은 다음과 같다.

• then → 성공 처리
• catch → 실패 처리
• finally → 성공/실패 상관없이 실행

Promise 체이닝

Promise의 가장 큰 장점은 비동기 작업을 순서대로 연결할 수 있다는 점이다.

getUser()
  .then((user) => {
    return getPosts(user.id);
  })
  .then((posts) => {
    return getComments(posts[0].id);
  })
  .then((comments) => {
    console.log(comments);
  })
  .catch((error) => {
    console.error(error);
  });

이 코드는 아까 콜백 코드와 같은 작업을 한다.

하지만 코드 구조는 오른쪽으로 밀리는 구조에서 왼쪽 정렬 상태를 유지한다.

그래서 Promise는 콜백 지옥을 해결하는 방법으로 등장했다.

콜백 vs Promise

에러 처리 문제

getUser(function (err, user) {
  if (err) {
    console.error(err);
    return;
  }

  getPosts(user.id, function (err, posts) {
    if (err) {
      console.error(err);
      return;
    }

    getComments(posts[0].id, function (err, comments) {
      if (err) {
        console.error(err);
        return;
      }

      console.log(comments);
    });
  });
});

여기서 특징이 하나 보인다.

if (err)
if (err)
if (err)

에러 처리가 계속 반복된다.

그런데 Promise에서는 이런식으로 바뀐다.

getUser()
  .then((user) => getPosts(user.id))
  .then((posts) => getComments(posts[0].id))
  .then((comments) => console.log(comments))
  .catch((error) => console.error(error));

여기서는 catch 하나로 에러를 처리할 수 있다.

즉 콜백은 에러 처리를 반복하고, Promise는 에러 처리를 중앙화 하는 차이가 생긴다.

코드 흐름 읽기

콜백 코드는 읽을 때 위에서 안으로 파고드는 느낌을 갖는 반면, Promise는 위에서 아래로 흐르는 느낌을 갖는다.

즉 콜백은 구조를 따라 읽어야 하고, Promise는 흐름을 따라 읽으면 되는 차이점도 있다.

이러한 차이를 정리하면 Promise의 장점은 다음과 같다.

• 코드가 오른쪽으로 밀리지 않는다
• 에러 처리가 단순해진다
• 비동기 흐름을 읽기 쉬워진다

하지만 Promise 역시 완벽한 해결책은 아니었다.

6. 이 지옥을 끝내러 왔다: async/await

Promise의 한계

Promise는 콜백 지옥을 해결해 주었다. 비동기 작업을 체이닝 방식으로 연결할 수 있었기 때문이다.

getUser()
  .then((user) => getPosts(user.id))
  .then((posts) => getComments(posts[0].id))
  .then((comments) => console.log(comments))
  .catch((error) => console.error(error));

콜백처럼 코드가 오른쪽으로 밀리지는 않는다.

하지만 Promise에도 아쉬운 점은 있었다.

• .then()이 계속 이어지면 가독성이 떨어진다.
• 동기 코드처럼 읽기 어렵다

그래서 등장한 문법이 async/await이다.

async 함수

async는 비동기 함수를 선언할 때 사용하는 키워드다.

async function example() {
  return "hello";
}

여기서 중요한 특징이 하나 있다.

async 함수는 항상 Promise를 반환한다.

예를 들어

async function example() {
  return "hello";
}

이 코드는 실제로는 이렇게 동작한다.

function example() {
  return Promise.resolve("hello");
}

즉 async 함수는 내부적으로 Promise를 반환하는 함수다.

await 키워드

await는 Promise가 완료될 때까지 기다리는 키워드다.

예를 들어 Promise 코드가 이렇게 있다고 해보자.

getUser()
  .then((user) => getPosts(user.id))
  .then((posts) => console.log(posts));

이 코드를 async/await으로 바꾸면 이렇게 된다.

async function run() {
  const user = await getUser();
  const posts = await getPosts(user.id);

  console.log(posts);
}

코드를 보면 비동기 코드인데 동기 코드처럼 읽히는 특징이 있다. 이게 바로 async/await의 가장 큰 장점이다.

async/await 에러 처리

Promise에서는 보통 이렇게 에러를 처리했다.

getUser()
  .then((user) => getPosts(user.id))
  .catch((error) => console.error(error));

하지만 async/await에서는 try/catch를 사용할 수 있다.

async function loadData() {
  try {
    const user = await getUser();
    const posts = await getPosts(user.id);

    console.log(posts);
  } catch (error) {
    console.error(error);
  }
}

그래서 에러 처리도 동기 코드처럼 작성할 수 있다.

병렬 실행 (Promise.all)

await는 기본적으로 순차 실행을 만든다.

1. getUser 실행
2. getUser 완료
3. getPosts 실행

하지만 작업을 동시에 실행하고 싶다면, Promise.all을 사용할 수 있다.

const [user, posts] = await Promise.all([getUser(), getPosts()]);

이렇게 하면 두 작업이 동시에 실행된다.

7. 핵심 정리

자바스크립트의 기본 실행 방식은 동기 실행이다. 즉 코드는 위에서 아래로 순서대로 실행된다.

하지만 웹 환경에서는

• API 요청
• 타이머
• 파일 처리
• 사용자 입력

처럼 시간이 오래 걸리는 작업이 자주 발생한다.

이런 작업이 동기 방식으로 실행되면 하나의 작업이 전체 실행 흐름을 멈추게 된다.

그래서 자바스크립트는 Event Loop 구조를 통해 비동기 작업의 실행 흐름을 관리한다.

이 과정에서 등장한 흐름은 다음과 같다.

1. 동기 실행
2. 비동기 처리 구조 (Event Loop)
3. 콜백 함수
4. 콜백 지옥
5. Promise
6. async/await

콜백은 비동기 작업이 끝난 뒤 다음 작업을 실행하기 위한 방법이었지만 콜백이 중첩되면서 콜백 지옥 문제가 발생했다.

이 문제를 해결하기 위해 비동기 작업의 결과를 객체로 표현하는 Promise가 등장했다.

그리고 Promise를 더 읽기 쉽고 직관적으로 작성하기 위해 async/await 문법이 추가되었다.

그래서 현재 자바스크립트 비동기 코드는 보통 다음 방식으로 작성된다.

Promise + async/await

이는 비동기 코드를 동기 코드처럼 읽을 수 있게 만드는 방식이다.

현재 대부분의 자바스크립트 비동기 코드는 Promise와 async/await를 중심으로 작성된다.

클로저는 갑자기 등장한 개념이 아니다. 보통 하나의 의문에서 시작된다.

다음 코드를 보자.

function outer() {
  const message = "hello";

  function inner() {
    console.log(message);
  }

  return inner;
}

const fn = outer();
fn();

코드의 실행 흐름을 보면 다음과 같다.

outer 실행
→ inner 반환
→ outer 종료
→ fn 실행

여기서 중요한 질문이 하나 생긴다.

outer() 함수는 이미 실행이 끝났다. 그런데 inner() 함수는 message 변수에 계속 접근한다.

즉 이런 의문이 생긴다.

이미 종료된 함수의 변수에 어떻게 접근할 수 있을까?

보통 함수가 끝나면 그 함수 내부의 변수도 사라지는 것이 정상이다.

하지만 위 코드에서는 message가 계속 유지된다.

이 현상을 설명하기 위해 등장하는 개념이 클로저(Closure)다.

2. 렉시컬 스코프와 클로저

클로저를 이해하려면 먼저 렉시컬 스코프를 떠올려야 한다.

JavaScript에서는 함수의 스코프가 호출 위치가 아니라 선언 위치에 의해 결정된다.

예제를 보자.

function outer() {
  const a = 10;

  function inner() {
    console.log(a);
  }

  inner();
}

outer();

여기서 inner() 함수는 outer() 함수 안에서 선언되어 있다.

그래서 inner()는 자신이 선언된 스코프에 있는 변수 a에 접근할 수 있다.

이 규칙이 바로 이전 글에서 다뤘던 렉시컬 스코프다.

구조를 보면 이렇게 된다.

global scope
⎿ outer
    ⎿ inner

하위 스코프는 항상 상위 스코프의 변수에 접근할 수 있다.

여기까지는 사실 클로저가 아니다.

단순히 스코프 규칙일 뿐이며 이전 글의 복습에 가깝다.

클로저는 조금 다른 상황에서 등장한다.

외부 함수는 종료됐지만 내부 함수가 외부 변수를 계속 사용하는 상황이다.

즉 핵심 상황은 다음과 같다.

outer 함수는 이미 끝났지만 inner 함수는 여전히 outer의 변수를 사용한다.

이때 JavaScript는 외부 스코프를 그대로 유지한다.

이 상태를 클로저라고 한다.

3. 클로저의 개념

보통 클로저는 다음처럼 설명된다.

클로저는 함수와 그 함수가 선언될 당시의 렉시컬 스코프가 결합된 구조다.

즉 클로저는 단순히 함수 하나를 의미하는 것이 아니다.

구조적으로 보면 다음과 같다.

함수
+
함수가 선언될 당시의 스코프
=
클로저

이 말은 JavaScript에서 함수는 실행될 때만 동작하는 것이 아니라 자신이 선언된 환경을 기억한다는 의미다.

그래서 내부 함수는 자신이 선언된 위치의 스코프에 계속 접근할 수 있다.

4. 클로저의 동작 구조

이제 처음 던졌던 질문으로 다시 돌아가 보자.

function outer() {
  const message = "hello";

  function inner() {
    console.log(message);
  }

  return inner;
}

const fn = outer();
fn();

코드의 흐름은 다음과 같다.

outer 실행
→ inner 반환
→ outer 종료
→ fn 실행

일반적으로 함수가 끝나면 그 함수 내부 변수는 메모리에서 제거된다.

하지만 위 코드에서는 message가 계속 유지된다.

그 이유는 inner 함수가 message 변수에 계속 접근해야 하기 때문이다.

그래서 JavaScript 엔진은 outer의 렉시컬 환경을 바로 제거하지 않는다.

대신 inner 함수와 함께 유지한다.

구조적으로 보면 이렇게 된다.

inner 함수
+
outer의 스코프(message)

이처럼 함수와 외부 스코프가 함께 유지되는 상태를 클로저(Closure)라고 한다.

5. 클로저 활용 패턴

클로저는 단순히 개념으로만 존재하는 것이 아니라 실제 코드에서 특정 패턴을 만들기 위해 자주 사용된다.

대표적인 활용 방식은 크게 두 가지다.

상태 유지 (State)

클로저를 사용하면 함수 내부 상태를 유지할 수 있다.

function counter() {
  let count = 0;

  return function () {
    count++;
    console.log(count);
  };
}

const increase = counter();

increase(); // 1
increase(); // 2
increase(); // 3

이 코드에서 중요한 점은 다음과 같다.

• count 변수는 counter 함수 내부에 존재한다
• 외부에서는 count에 직접 접근할 수 없다
• 하지만 반환된 내부 함수는 count에 계속 접근할 수 있다

즉 클로저를 통해 함수 내부 상태가 계속 유지된다.

데이터 은닉 (Encapsulation)

클로저는 외부에서 직접 접근할 수 없는 데이터를 만드는 데도 사용된다.

function createUser(name) {
  let _name = name;

  return {
    getName() {
      return _name;
    },
  };
}

const user = createUser("Alice");
console.log(user.getName()); // Alice

여기서 _name 변수는

• 외부에서 직접 접근할 수 없고
• 내부 함수만 접근할 수 있다

이처럼 클로저는 데이터를 보호하는 구조를 만들 때도 활용된다.

6. 핵심 정리

• 클로저는 함수와 선언 당시의 스코프가 결합된 구조다
• 함수는 자신이 선언된 환경을 기억한다
• 내부 함수가 외부 변수를 사용하면 해당 스코프는 유지된다
• 클로저는 상태 유지와 데이터 은닉을 구현할 때 활용된다

스코프(Scope)는 변수에 접근할 수 있는 범위를 의미한다.

JavaScript에서 변수는 프로그램 어디에서든 사용할 수 있는 것이 아니라 변수가 선언된 위치에 따라 접근 가능한 영역이 결정된다.

즉 코드에는 다음과 같은 접근 범위 구조가 존재한다.

전역 스코프
⎿ 함수 스코프
    ⎿ 내부 함수 스코프

상위 스코프에 선언된 변수는 하위 스코프에서 접근할 수 있지만 하위 스코프에서 선언된 변수는 상위 스코프에서 접근할 수 없다.

let a = 10;

function test() {
  let b = 20;
  console.log(a);
}

test();

이 코드에서 변수의 스코프는 다음과 같다.

• a → 전역 스코프
• b → test 함수 내부 스코프

따라서 test 함수 내부에서는 전역 변수 a에 접근할 수 있지만 전역에서는 b에 접근할 수 없다.

console.log(b); // ReferenceError

이처럼 변수의 접근 가능 범위를 결정하는 개념을 스코프(Scope)라고 한다.

2. 렉시컬 스코프 (Lexical Scope)

JavaScript에서는 스코프가 코드가 작성된 위치에 의해 결정된다. 이러한 스코프 결정 방식을 렉시컬 스코프(Lexical Scope) 라고 한다.

여기서 Lexical은 "코드의 문자적 위치"를 의미한다.

즉 JavaScript는 함수가 어디서 호출되었는지가 아니라 함수가 어디에서 선언되었는지에 따라 스코프가 결정된다.

let x = 10;

function outer() {
  let x = 20;

  function inner() {
    console.log(x);
  }

  inner();
}

outer();

이 코드의 실행 결과는 20이다.

그 이유는 inner 함수가 outer 함수 내부에서 선언되었기 때문이다.

코드의 구조를 보면 다음과 같다.

global
⎿ outer
    ⎿ inner

JavaScript에서는 함수가 선언될 때 자신이 선언된 위치의 스코프를 기준으로 변수에 접근한다.

따라서 inner 함수는 outer의 스코프에 접근할 수 있고 outer에 선언된 x = 20을 참조하게 된다.

이처럼 함수가 선언된 위치를 기준으로 스코프가 결정되는 규칙을 렉시컬 스코프라고 한다.

3. 스코프 체인 (Scope Chain)

JavaScript에서 변수를 사용할 때 엔진은 해당 변수를 현재 스코프에서 먼저 찾는다.

만약 현재 스코프에 해당 변수가 없다면 상위 스코프로 올라가면서 변수를 탐색한다.

이 과정을 스코프 체인(Scope Chain) 이라고 한다.

즉 변수 탐색은 다음과 같은 순서로 이루어진다.

현재 스코프
→ 부모 스코프
→ 전역 스코프

앞서 살펴본 예제를 다시 보자.

let x = 10;

function outer() {
  let x = 20;

  function inner() {
    console.log(x);
  }

  inner();
}

outer();

이 코드의 스코프 구조는 다음과 같다.

global
⎿ outer
    ⎿ inner

inner 함수에서 x를 찾는 과정은 다음과 같다.

1. inner 스코프 확인
2. outer 스코프 확인
3. global 스코프 확인

inner 스코프에는 x가 존재하지 않기 때문에 상위 스코프인 outer로 올라가게 된다.

그 결과 outer에 선언된 x = 20을 찾게 되고 console.log(x)의 결과는 20이 된다.

JavaScript는 현재 스코프에서 시작해 상위 스코프로 이동하며 변수를 탐색한다. 이러한 탐색 구조를 스코프 체인(Scope Chain)이라고 한다.

4. 렉시컬 스코프의 특징

스코프는 코드 구조로 결정된다.

JavaScript에서 스코프는 코드가 작성된 위치, 즉 함수가 선언된 위치에 의해 결정된다.

따라서 함수가 어디에서 실행되었는지가 아니라 어디에서 선언되었는지가 변수 접근 범위를 결정한다.

함수 호출 위치는 스코프에 영향을 주지 않는다.

렉시컬 스코프에서는 함수가 호출된 위치는 중요하지 않다.

함수는 실행되는 위치와 관계없이 자신이 선언된 위치의 스코프를 기준으로 변수에 접근한다.

예를 들어 함수가 다른 스코프에서 실행되더라도 자신이 정의된 환경의 스코프를 기준으로 동작한다.

함수는 자신이 선언된 환경을 따른다.

JavaScript의 함수는 선언될 때 자신이 선언된 스코프를 함께 기억한다.

그래서 함수가 다른 곳에서 실행되더라도 원래 선언되었던 스코프의 변수에 접근할 수 있다.

이러한 특성은 이후 클로저(Closure)라는 개념으로 이어진다.

5. 렉시컬 스코프와 this의 차이

JavaScript에서 렉시컬 스코프와 this는 기준이 서로 다르다.

렉시컬 스코프는 함수가 선언된 위치를 기준으로 결정되지만 this는 함수가 호출되는 방식에 따라 결정된다.

즉 두 개념은 다음과 같은 차이를 가진다.

• 렉시컬 스코프 → 선언 위치 기준
• this → 호출 방식 기준

예를 들어 다음 코드를 보자.

const person = {
  name: "홍길동",
  greet() {
    console.log(this.name);
  },
};

person.greet();

이 코드에서 this는 person을 가리킨다.

그 이유는 greet 함수가 person 객체를 통해 호출되었기 때문이다.

즉 this는 함수가 어디에서 선언되었는지가 아니라 어떤 방식으로 호출되었는지에 따라 결정된다.

반면 렉시컬 스코프는 함수가 선언된 위치를 기준으로 스코프가 결정된다.

이처럼 JavaScript에서는 선언 위치를 기준으로 하는 렉시컬 스코프와 호출 방식을 기준으로 하는 this 규칙이 동시에 존재한다.

이 두 개념은 모두 함수와 관련된 개념이지만 동작 기준이 전혀 다르기 때문에 자주 혼동되는 개념이다.

6. 핵심 정리

• 스코프는 변수에 접근할 수 있는 범위를 의미한다.
• JavaScript는 렉시컬 스코프 규칙을 사용한다.
• 스코프는 함수가 선언된 위치(코드 구조)에 의해 결정된다.
• 변수는 현재 스코프에서 시작해 상위 스코프로 이동하며 탐색되는 스코프 체인 구조를 따른다.
• 렉시컬 스코프는 선언 위치 기준, this는 호출 방식 기준이라는 차이를 가진다.

이로써 JavaScript에서 변수의 접근 범위가 어떻게 결정되고 탐색되는지를 이해할 수 있다.

JavaScript가 웹 페이지에서 실제로 무엇을 하는지 이해하는 것이 이번 파트의 목적이다.

많은 사람들이 처음 웹을 배울 때 이렇게 생각한다.

• HTML → 화면을 만든다
• CSS → 디자인을 한다
• JavaScript → 기능을 만든다

이 설명 자체는 틀리지 않지만, 조금 더 정확하게 말하면 JavaScript는 DOM을 통해 HTML을 조작한다.

즉 구조는 이렇게 된다.

HTML → 브라우저가 읽는다
→ DOM 생성
→ JavaScript가 DOM을 조작한다

여기서 등장하는 개념이 바로 DOM이다.

DOM이란

DOM은 Document Object Model의 약자다.

쉽게 말하면 HTML 문서를 JavaScript가 다룰 수 있는 객체 구조로 변환한 것이다.

예를 들어 이런 HTML이 있다고 가정해보자.

<body>
  <h1>제목</h1>
  <p>문단</p>
</body>

브라우저는 이 코드를 그대로 사용하는 것이 아니라 내부적으로 트리 구조의 객체로 변환한다.

구조는 이렇게 된다.

document
⎿ body
    ⎿ h1
    ⎿ p

이 구조를 DOM Tree라고 부른다.

그리고 JavaScript는 이 트리 구조를 통해 HTML 요소에 접근하고 수정할 수 있다.

JavaScript는 무엇을 하는가

JavaScript는 이 DOM을 이용해 웹 페이지를 동적으로 변경한다.

대표적인 예는 다음과 같다.

내용 변경

document.querySelector("h1").textContent = "새 제목";

페이지에 있는 <h1> 요소의 내용을 변경한다.

스타일 변경

document.querySelector("button").style.color = "red";

버튼의 색상을 바꾼다.

요소 추가

const newDiv = document.createElement("div");
document.body.appendChild(newDiv);

새로운 요소를 만들어 페이지에 추가한다.

이벤트 처리

document.querySelector("button").addEventListener("click", () => {
  alert("클릭됨!");
});

사용자의 클릭 행동에 반응하도록 만들 수 있다.

브라우저가 하는 일

웹 페이지가 열리면 브라우저 내부에서는 다음 과정이 일어난다.

1. HTML 다운로드
2. HTML 파싱
3. DOM 생성
4. JavaScript 실행
5. 화면 렌더링

즉 흐름을 정리하면 다음과 같다.

HTML → DOM 생성 → JavaScript가 DOM을 조작 → 화면 변경

2. DOM 선택

JavaScript는 DOM을 조작할 수 있지만 바로 수정할 수는 없다.

반드시 DOM을 먼저 선택한 뒤 조작해야 한다.

즉 JavaScript는 먼저 어떤 요소를 바꿀지 찾은 뒤 그 요소를 수정한다.

예를 들어 페이지에 이런 HTML이 있다고 가정해보자.

<h1 id="title">안녕하세요</h1>
<button class="btn">버튼</button>

JavaScript가 <h1>을 수정하려면 먼저 해당 요소를 찾아야 한다.

const title = document.querySelector("#title");

title.textContent = "Hello";

여기서 querySelector가 바로 DOM 선택 메서드(Selection Method)다.

DOM 선택의 기본 구조

DOM을 선택할 때는 항상 document 객체를 사용한다.

document.선택메서드();

document는 현재 HTML 문서 전체를 의미한다.

즉 DOM 선택은 기본적으로 "document에서 원하는 요소 찾기"라는 의미를 가진다.

getElementById

가장 기본적인 DOM 선택 방법이다.

document.getElementById("title");

특징은 다음과 같다.

• id 기준으로 요소를 선택한다
• 하나의 요소만 반환한다
• #를 붙이지 않는다

예

const title = document.getElementById("title");

getElementsByClassName

class 기준으로 요소를 선택한다.

document.getElementsByClassName("btn");

특징

• 같은 class를 가진 여러 요소를 반환
• 반환 타입은 HTMLCollection

예

const buttons = document.getElementsByClassName("btn");

getElementsByTagName

태그 이름 기준으로 선택한다.

document.getElementsByTagName("p");

예

const paragraphs = document.getElementsByTagName("p");

이 메서드 역시 여러 요소를 반환한다.

querySelector

현대 JavaScript에서 가장 많이 사용하는 방식이다.

CSS 선택자를 그대로 사용할 수 있다.

document.querySelector("h1");
document.querySelector(".btn");
document.querySelector("#title");

특징

• 첫 번째 요소만 반환
• CSS 선택자 사용 가능

예

const button = document.querySelector(".btn");

querySelectorAll

여러 요소를 선택할 때 사용한다.

document.querySelectorAll(".btn");

예

const buttons = document.querySelectorAll(".btn");

특징

• 여러 요소 반환
• 반환 타입은 NodeList

HTMLCollection과 NodeList

DOM 선택 메서드는 배열처럼 보이는 객체를 반환한다.

대표적으로 두 가지가 있다.

두 객체 모두 배열처럼 보이지만 배열은 아니다.

하지만 차이가 하나 있다.

• HTMLCollection → live collection
• NodeList → static collection

3. DOM 트리와 탐색

DOM을 선택했다면 이제 다음 단계는 DOM 구조를 이해하는 것이다.

DOM 트리란

HTML 문서는 단순히 위에서 아래로 나열된 구조가 아니라 트리(Tree) 구조로 이루어져 있다.

예를 들어 다음 HTML이 있다고 가정해보자.

<body>
  <div class="container">
    <h1>제목</h1>
    <p>문단</p>
  </div>
</body>

브라우저는 이 코드를 그대로 사용하는 것이 아니라 다음과 같은 DOM 트리 구조로 변환한다.

document
⎿ body
    ⎿ div
        ⎿ h1
        ⎿ p

이처럼 HTML 요소들은 서로 계층 구조를 가진다.

부모/자식/형제 관계

DOM 트리에서는 각 요소가 서로 관계를 가진다.

대표적인 관계는 다음과 같다.

• 부모 요소 (parent)
• 자식 요소 (children)
• 형제 요소 (siblings)

예를 들어 위 구조에서는 다음과 같은 관계가 된다.

div → h1의 부모
div → p의 부모

h1 → div의 자식
p → div의 자식

h1과 p → 서로 형제

이 관계를 이용하면 DOM 안에서 요소 간 이동이 가능하다.

탐색 속성들

DOM에서는 부모・자식・형제 관계를 이용해 요소를 탐색하는 속성들이 존재한다.

parentElement

현재 요소의 부모 요소를 찾는다.

const title = document.querySelector("h1");

console.log(title.parentElement);

결과

<div class="container">

children

현재 요소의 자식 요소(element) 들을 가져온다. 텍스트 노드나 공백 노드는 포함되지 않는다.

const container = document.querySelector(".container");

console.log(container.children);

결과

[h1, p]

firstElementChild

첫 번째 자식 요소를 가져온다.

container.firstElementChild;

결과

<h1>

lastElementChild

마지막 자식 요소를 가져온다.

container.lastElementChild;

결과

<p>

nextElementSibling

다음 형제 요소를 가져온다.

const title = document.querySelector("h1");

title.nextElementSibling;

결과는

<p>

previousElementSibling

이전 형제 요소를 가져온다.

const paragraph = document.querySelector("p");

paragraph.previousElementSibling;

결과

<h1>

4. DOM 조작

내용 변경

DOM을 선택하고 탐색했다면 이제 다음 단계는 DOM의 내용을 실제로 변경하는 것이다.

JavaScript는 DOM 객체를 조작하여 웹 페이지의 내용을 동적으로 변경할 수 있다.

예를 들어 다음과 같은 HTML이 있다고 가정해보자.

<h1 id="title">제목</h1>

JavaScript는 DOM을 통해 이 내용을 변경할 수 있다.

textContent

textContent는 요소 안의 텍스트 내용을 변경한다.

const title = document.querySelector("#title");

title.textContent = "새로운 제목";

결과

<h1 id="title">새로운 제목</h1>

textContent는 텍스트만 변경하며 문자열 안의 HTML 태그는 해석하지 않는다.

예를 들어 다음 코드를 실행하면

title.textContent = "<span>제목</span>";

화면에는 실제 태그가 아니라 문자 그대로 다음과 같이 출력된다.

<span>제목</span>

innerHTML

innerHTML은 요소 내부의 HTML 구조 자체를 변경한다.

title.innerHTML = "<span>새 제목</span>";

결과

<h1 id="title">
  <span>새 제목</span>
</h1>

innerHTML은 문자열을 HTML로 해석하여 DOM 구조를 변경한다.

innerText

innerText는 브라우저 화면에 실제로 보이는 텍스트를 기준으로 동작한다.

예를 들어 CSS로 숨겨진 요소가 있다면 innerText는 그 내용을 포함하지 않는다.

element.innerText;

textContent vs innerHTML vs innerText

• textContent: 텍스트만 변경
• innerHTML: HTML 구조까지 변경
• innerText: 화면에 보이는 텍스트 기준

일반적으로 단순한 텍스트 변경에는 textContent를 사용하는 것이 권장된다.

5. 요소 생성과 추가/삭제

요소 생성

DOM을 조작할 때는 기존 요소의 내용을 바꾸는 것뿐만 아니라 새로운 요소를 만들 수도 있다.

이때 사용하는 메서드가 createElement이다.

const div = document.createElement("div");

이 코드는 새로운 <div> 요소를 생성한다.

하지만 이 상태에서는 아직 화면에 나타나지 않는다.

이유는 간단하다.

• 요소 생성 ≠ DOM에 추가

즉 요소는 만들어졌지만 DOM 트리에 아직 연결되지 않은 상태다.

요소 추가

생성한 요소를 화면에 보이게 하려면 DOM 트리에 추가해야 한다.

대표적으로 사용하는 메서드는 appendChild다.

document.body.appendChild(div);

그러면 DOM 구조는 다음처럼 변경된다.

document
⎿ body
    ⎿ div

즉 DOM 트리에 연결되면서 화면에도 나타난다.

요소 삭제

DOM 요소는 제거할 수도 있다.

이때 사용하는 메서드는 remove다.

const title = document.querySelector("#title");

title.remove();

이 코드를 실행하면 <h1> 요소가 DOM에서 삭제된다.

즉 구조는 다음처럼 바뀐다.

삭제 전
<h1 id="title">제목</h1>

삭제 후
(요소 없음)

6. HTML 속성과 스타일 조작

HTML 속성 조작

DOM을 통해 요소의 내용이나 구조뿐만 아니라 HTML 속성(attribute)도 조작할 수 있다.

예를 들어 다음과 같은 HTML이 있다고 가정해보자.

<a id="link" href="https://google.com">이동</a>

JavaScript를 사용하면 이 속성을 수정할 수 있다.

대표적으로 사용하는 메서드는 다음과 같다.

• getAttribute
• setAttribute

getAttribute

getAttribute는 요소의 속성 값을 가져온다.

const link = document.querySelector("#link");

console.log(link.getAttribute("href"));

결과

https://google.com

setAttribute

setAttribute는 속성 값을 변경하거나 추가한다.

link.setAttribute("href", "https://naver.com");

결과

<a id="link" href="https://naver.com">이동</a>

class 조작

HTML 요소의 class는 JavaScript에서 classList 객체를 통해 다룰 수 있다.

class 추가

element.classList.add("active");

class 제거

element.classList.remove("active");

class 토글

element.classList.toggle("active");

toggle은 class가 있으면 제거하고 없으면 추가하는 방식으로 동작한다.

style 조작

JavaScript는 DOM을 통해 CSS 스타일도 변경할 수 있다.

element.style.color = "red";

예

const title = document.querySelector("h1");

title.style.color = "red";

그러면 <h1>의 글자 색이 빨간색으로 바뀐다.

CSS 속성은 JavaScript에서 camelCase 형태로 작성한다.

예

• background-color → backgroundColor
• font-size → fontSize

data 속성

HTML에서는 사용자 정의 속성을 만들 수 있다.

이때 사용하는 것이 data-* 속성이다.

예

<div data-id="10"></div>

JavaScript에서는 dataset을 통해 접근할 수 있다.

element.dataset.id;

7. 이벤트와 이벤트 객체

이벤트

웹 페이지에서는 다양한 사용자 행동이 발생한다.

예를 들어 다음과 같은 행동들이 있다.

• 버튼 클릭
• 키보드 입력
• 마우스 이동
• 폼 제출

이처럼 사용자의 행동이나 브라우저에서 발생하는 동작을 이벤트(Event)라고 한다.

JavaScript는 이러한 이벤트를 감지하고 특정 동작을 실행하도록 만들 수 있다.

이벤트 핸들러

이벤트가 발생했을 때 실행되는 함수를 이벤트 핸들러(Event Handler)라고 한다.

예를 들어 버튼을 클릭했을 때 특정 코드가 실행되도록 만들 수 있다.

<button id="btn">클릭</button>

const button = document.querySelector("#btn");

button.addEventListener("click", function () {
  console.log("버튼 클릭됨");
});

이 코드의 구조는 다음과 같다.

요소.addEventListener(이벤트, 실행할 함수)

즉 위 코드는 "버튼이 클릭되면 함수가 실행된다" 는 의미가 된다.

addEventListener

addEventListener는 특정 이벤트가 발생했을 때 실행할 함수를 등록한다.

element.addEventListener("click", handler);

예

button.addEventListener("click", () => {
  console.log("클릭됨");
});

이 메서드는 여러 개의 이벤트를 동시에 등록할 수 있다는 특징이 있다.

이벤트 객체

이벤트가 발생하면 브라우저는 이벤트에 대한 정보를 담은 객체를 전달한다.

이를 이벤트 객체(Event Object)라고 한다.

button.addEventListener("click", function (event) {
  console.log(event);
});

이 객체에는 이벤트가 발생한 상황에 대한 다양한 정보가 들어 있다.

예를 들어

• 어떤 요소에서 이벤트가 발생했는지
• 마우스 좌표
• 눌린 키
• 이벤트 타입

같은 정보들이다.

대표적으로 자주 사용하는 속성은 다음과 같다.

• event.target
• event.type

preventDefault

일부 HTML 요소는 기본 동작을 가지고 있다.

예를 들어

• <a> → 링크 이동
• <form> → 페이지 새로고침

이러한 기본 동작을 막고 싶을 때 preventDefault()를 사용한다.

link.addEventListener("click", function (event) {
  event.preventDefault();
});

이 코드는 링크를 클릭해도 페이지 이동이 발생하지 않도록 만든다.

8. 핵심 정리

지금까지 살펴본 내용을 정리하면 JavaScript가 웹 페이지를 제어하는 방식은 다음 흐름으로 이해할 수 있다.

DOM 선택 → DOM 탐색 → DOM 조작 → 이벤트 처리

각 단계의 역할은 다음과 같다.

DOM 선택

JavaScript는 DOM을 조작하기 전에 먼저 어떤 요소를 다룰지 선택해야 한다.

대표적인 메서드

• getElementById
• querySelector
• querySelectorAll

DOM 탐색

DOM은 트리 구조이기 때문에 요소 간의 관계를 이용해 이동할 수 있다.

대표적인 탐색 속성

• parentElement
• children
• firstElementChild
• lastElementChild
• nextElementSibling
• previousElementSibling

DOM 조작

선택한 요소의 내용이나 구조를 변경할 수 있다.

대표적인 방법

• textContent
• innerHTML
• innerText
• createElement
• appendChild
• remove

HTML 속성과 스타일 조작

DOM을 통해 HTML 속성과 CSS 스타일도 수정할 수 있다.

대표적인 방법

• getAttribute
• setAttribute
• classList
• style
• dataset

이벤트 처리

JavaScript는 사용자의 행동에 반응하도록 만들 수 있다.

대표적인 개념

• 이벤트(Event)
• 이벤트 핸들러(Event Handler)
• addEventListener
• 이벤트 객체
• preventDefault

결국 JavaScript가 하는 일은 DOM을 조작해 웹 페이지를 동적으로 변화시키는 것이다.

이 구조를 이해하면 웹 페이지에서 발생하는 대부분의 인터랙션을 구현할 수 있다.

this는 함수가 실행될 때 결정되는 객체 참조값이다. 즉, 함수 내부에서 "지금 이 함수를 실행한 주체"를 가리킨다.

this는 함수가 만들어질 때 결정되지 않는다 함수가 호출되는 방식에 따라 결정된다 즉 this는 함수의 위치가 아니라 호출 방식(call-site)에 의해 결정된다.

기본 예제

const person = {
  name: "홍길동",
  greet() {
    console.log(this.name);
  },
};

person.greet();

실행 결과는 홍길동이다. greet()를 person이 호출했기에 this는 person이 된다.

2. this가 결정되는 주요 규칙

JavaScript에서 this는 크게 네 가지 상황으로 이해하는 것이 일반적이다.

일반 함수 호출

function test() {
  console.log(this);
}

test();

출력 결과로는 브라우저 환경 window가 나온다.

객체 없이 그냥 함수로 호출했을 경우, 전역 객체가 this가 된다.

객체의 메서드로 호출

const user = {
  name: "철수",
  sayName() {
    console.log(this.name);
  },
};

user.sayName();

결과는 철수가 된다. user.sayName() 형태로, 점 앞의 객체(user)가 this가 된다.

생성자 함수 (new)

function Person(name) {
  this.name = name;
}

const p = new Person("홍길동");

console.log(p.name);

new로 호출하면 새로운 객체가 생성 되고, this가 그 객체를 가리켜, 객체가 반환된다.

명시적 바인딩 (call / apply / bind)

function greet() {
  console.log(this.name);
}

const user = { name: "영희" };

greet.call(user);

결과는 영희가 나온다. call/apply/bind로 this를 직접 지정할 수 있기 때문이다.

3. this가 헷갈리는 대표 상황 (콜백)

const person = {
  name: "홍길동",
  greet() {
    setTimeout(function () {
      console.log(this.name);
    }, 1000);
  },
};

person.greet();

결과는 undefined로, setTimeout 안의 함수는 일반 함수 호출이기 때문이다. 즉 this는 전역 객체를 가리키게 된다.

4. Arrow Function과 this

Arrow Function은 자신만의 this를 가지지 않는다.

대신 외부 스코프의 this를 그대로 사용한다.

const person = {
  name: "홍길동",
  greet() {
    setTimeout(() => {
      console.log(this.name);
    }, 1000);
  },
};

person.greet();

결과는 홍길동, 바로 전 예제를 Arrow Function으로 바꿨을 뿐이다. Arrow Function이 greet()의 this를 그대로 사용하기 때문이다.

5. 핵심 정리

• this는 함수 내부에서 현재 실행 주체를 가리키는 참조값이다.
• this는 함수가 정의된 위치가 아니라 호출 방식에 의해 결정된다.
• 객체.메서드() 형태로 호출되면 점 앞의 객체가 this가 된다.
• 일반 함수 호출에서는 this가 전역 객체(window)가 된다.
• Arrow Function은 자체적인 this를 만들지 않고 외부 this를 그대로 사용한다.

한 가지 더 짚어서 많이들 착각하는 포인트로, 많은 사람들이 this는 함수가 속한 객체라고 생각하는데, 실제로 this는 함수를 호출한 객체다.