왜 웹은 자바스크립트로 만드나요?
웹 개발에서 왜 자바스크립트가 표준이 되었을까? 웹 플랫폼이 자바스크립트를 중심으로 발전하게 된 이유를 알아보자.
비전공자 친구가 한번은 진지하게 물어본 적이 있다.
“파이썬 그렇게 쉽고 좋다면서 왜 웹 만들 때는 안 써? 왜 자바스크립트 쓰는 거야?”
굉장히 좋은 질문이라는 생각이 들면서도 막상 설명하려니 생각보다 할 말이 많았다.
(그리고 블로그 컨텐츠로도 좋겠다는 생각이 들었다.)
단순히 “웹은 원래 자바스크립트를 써”라는 답으로는 부족하다.
여기에는 브라우저의 역사, 웹의 구조, 그리고 언어 설계 방식까지 얽혀 있다.
그래서 이 질문을 조금 더 정확하게 바꿔보면 이렇게 된다.
“왜 웹 브라우저는 자바스크립트를 실행하도록 설계되었을까?”
여기에 답변을 해보자.
브라우저가 먼저였다
이 질문의 핵심은 생각보다 단순한데,
자바스크립트는 브라우저를 위해 만들어진 언어이기 때문이다.
1995년, 넷스케이프(Netscape) 브라우저에 처음 탑재된 것이 시작이었다. 당시 웹 페이지는 거의 정적인 문서에 가까웠다. 버튼을 누르거나 폼을 제출하면 항상 서버로 요청을 보내야 했고, 그 결과를 다시 받아와 페이지 전체를 새로고침해야 했다.
이 과정을 조금이라도 줄이기 위해 등장한 것이 바로 브라우저 안에서 실행되는 스크립트 언어, 즉 자바스크립트였다.
한마디로
- 폼 입력값 검사
- 간단한 UI 반응
- 서버 요청 없이 처리 가능한 작은 로직
이런 서버까지 갔다 오지 않아도 되는 간단한 처리를 클라이언트에서 하기 위해서 도입됐다고 보면된다.
이렇게 처음 목적은 굉장히 단순했지만 이후 상황이 빠르게 바뀌었다. 웹 브라우저가 발전하면서 자바스크립트 엔진이 기본 기능으로 들어가기 시작했고, 결국 대부분의 브라우저가 이를 표준처럼 채택하게 된다.
- Chrome
- Firefox
- Safari
- Edge
모든 브라우저가 자바스크립트를 실행할 수 있는 환경을 기본으로 제공하게 된 것이다. 덕분에 웹 페이지는 단순한 문서가 아니라, 사용자와 상호작용하는 동적인 프로그램이 될 수 있었다.
하지만 브라우저는 파이썬을 직접 실행하는 기능을 기본적으로 제공하지 않는다.
아무리 파이썬이 좋은 언어라도, 브라우저 위에서 바로 실행할 수는 없는 것이다.
결국 웹 페이지가 사용자에게 전달된 뒤 브라우저 안에서 직접 실행되는 언어는 사실상 자바스크립트뿐이다.
그래서 웹 개발에서 자바스크립트가 쓰이는 이유는 단순히 “좋아서”가 아니라, 브라우저라는 플랫폼의 구조 때문이라고 보는 편이 정확하다.
서버는 뭐든 쓸 수 있다
아마 많은 사람들이 여기서 헷갈린다.
“웹은 자바스크립트를 쓴다”는 말을 들으면
마치 웹 전체가 자바스크립트로 만들어지는 것처럼 느껴지기 때문이다.
하지만 실제로는 그렇지 않다.
서버(백엔드)는 거의 어떤 언어로도 만들 수 있다.
예를 들어 파이썬만 봐도 이미 다양한 웹 프레임워크가 존재한다.
- Flask
- Django
- FastAPI
이런 프레임워크들은 모두 서버에서 HTML을 생성하거나 API를 제공하는 역할을 한다.
즉 웹 서버를 파이썬으로 만드는 것 자체는 전혀 문제가 없다.
문제는 HTML이 브라우저에 도착한 이후다.
사용자가 버튼을 클릭하거나,
화면에 애니메이션이 실행되거나,
서버에서 데이터를 비동기로 가져와 화면을 업데이트하는 일들은
브라우저 내부에서 직접 코드가 실행되어야 한다.
여기서 등장하는 것이 바로 자바스크립트다.
1
2
3
4
5
6
7
[사용자 클릭]
│
▼
[브라우저: JS가 처리] ← 여기가 JS의 영역
│
▼ (필요할 때만)
[서버: Python/Node/Java 등이 처리]
정리하면 구조는 이렇게 된다.
- 서버 → 어떤 언어든 사용 가능
- 브라우저 내부 실행 → 사실상 자바스크립트만 가능
그래서 웹 개발에서 자바스크립트는 단순한 선택이 아니라
브라우저 환경이 정해놓은 기본 언어라고 보는 편이 정확하다.
Node.js가 등장하면서
2009년, 웹 개발의 흐름을 꽤 크게 바꾼 사건이 하나 있었다.
Node.js의 등장이다.
그 전까지 자바스크립트는 사실상 브라우저 안에서만 쓰는 언어였다.
UI를 조작하고, 이벤트를 처리하고, 간단한 로직을 실행하는 역할 정도였다.
그런데 Node.js가 등장하면서 상황이 달라졌다.
자바스크립트를 브라우저 밖에서도 실행할 수 있게 된 것이다.
즉, 같은 언어로 다음 두 가지를 모두 할 수 있게 됐다.
- 브라우저에서 실행되는 프론트엔드
- 서버에서 실행되는 백엔드
이 변화는 생각보다 큰 영향을 만들었다.
예전에는 보통 이런 구조였다.
1
2
Frontend: JavaScript
Backend: Java / Python / Ruby / PHP
하지만 Node.js 이후에는 이런 구조도 가능해졌다.
1
2
Frontend: JavaScript
Backend: JavaScript (Node.js)
덕분에 프론트엔드와 백엔드를 같은 언어로 개발하는 스택이 등장했다.
대표적으로 많이 언급되는 조합이 있다.
- React (프론트엔드)
- Node.js + Express (백엔드)
스타트업에서 “풀스택 자바스크립트”라는 말이 자주 나오는 것도 이 때문이다.
물론 그렇다고 해서 파이썬이나 자바 같은 언어가 사라진 것은 아니다.
여전히 많은 서비스들이 Python, Java, Go 같은 언어로 서버를 운영한다.
다만 Node.js 이후로 웹 개발에서는 이런 선택지도 생겼다.
“굳이 언어를 두 개 쓸 필요가 있을까?”
그래서 지금의 웹 생태계는
여러 언어가 서버에서 경쟁하고, 브라우저에서는 자바스크립트가 사실상 표준인 구조로 굳어졌다.
브라우저는 왜 비동기 모델을 선택했을까
자바스크립트가 웹에서 살아남은 이유는 단순히 “역사적으로 먼저 들어갔기 때문”만은 아니다.
브라우저라는 환경과 구조적으로 잘 맞는 실행 모델을 가지고 있었기 때문이다.
브라우저는 생각보다 동시에 많은 일을 해야 한다.
예를 들어 한 페이지 안에서도 이런 일들이 계속 일어난다.
- 사용자 클릭 처리
- 스크롤 이벤트 처리
- 애니메이션 렌더링
- 서버에서 데이터 가져오기
- DOM 업데이트
이걸 처리하는 방식은 크게 두 가지가 있다.
1. 멀티스레드 방식
여러 개의 스레드를 만들어 동시에 일을 처리하는 방식이다.
1
2
3
스레드1 → 사용자 입력 처리
스레드2 → 네트워크 요청
스레드3 → 렌더링
겉보기에는 굉장히 효율적으로 보인다.
하지만 브라우저 환경에서는 치명적인 문제가 하나 있다.
DOM 충돌 문제다.
예를 들어 두 개의 스레드가 동시에 같은 버튼의 상태를 수정하면
어떤 값이 최종적으로 반영될지 예측하기 어려워진다.
(이런 문제를 race condition이라고 부른다.)
2. 이벤트 루프 방식
자바스크립트는 다른 접근을 선택했다.
싱글 스레드 + 이벤트 루프 모델이다.
즉, 일꾼은 한 명뿐이지만
기다리는 시간이 생기면 그 사이에 다른 일을 처리한다.
대략 이런 흐름이다.
1
2
3
4
1. 사용자 클릭 이벤트 처리
2. 서버 요청 보내기
3. 응답 기다리는 동안 다른 이벤트 처리
4. 응답이 오면 큐에서 꺼내 실행
이 방식의 장점은 명확하다.
- DOM을 동시에 수정하는 일이 없다
- 동시성 문제를 크게 줄일 수 있다
- 브라우저 구현이 단순해진다
그래서 자바스크립트는 처음부터
이벤트 기반 비동기 모델을 중심으로 발전했다.
그래서 Node.js도 잘 맞았다
이 모델은 서버 환경에서도 의외로 잘 맞았다.
서버 프로그램의 상당한 시간은 사실 기다림이다.
- 데이터베이스 응답 대기
- 파일 I/O
- 외부 API 요청
Node.js는 이런 작업을 기다리는 동안 다른 요청을 처리할 수 있기 때문에
스레드를 많이 만들지 않고도 많은 요청을 처리할 수 있었다.
그래서 한동안 이런 이야기가 개발자 커뮤니티에서 자주 나왔다.
“I/O가 많은 서비스라면 Node.js가 꽤 잘 맞는다.”
물론 오늘날에는 Go, Rust, Java 같은 언어들도
고성능 비동기 서버를 잘 구현한다.
하지만 웹 생태계에서 자바스크립트가 강한 이유 중 하나는
이 이벤트 기반 모델이 처음부터 설계에 포함되어 있었기 때문이다.
“그럼 WebAssembly는요?”
여기까지 이야기를 들으면 이런 질문이 자연스럽게 나온다.
“브라우저가 자바스크립트만 실행한다면
다른 언어를 브라우저에서 실행하게 만들면 되는 거 아닌가?”
실제로 그런 시도가 이미 존재한다.
WebAssembly(WASM) 이다.
WebAssembly는 간단히 말하면
브라우저가 실행할 수 있는 저수준 바이너리 코드 포맷이다.
구조는 대략 이렇게 된다.
1
2
3
4
5
Rust / C++ / Go 코드 작성
↓
WebAssembly로 컴파일
↓
브라우저에서 실행
그래서 이론적으로는 이런 것도 가능하다.
- 브라우저에서 C++ 실행
- 브라우저에서 Rust 실행
- 브라우저에서 Python 실행
실제로 Pyodide 같은 프로젝트를 보면
브라우저 안에서 파이썬 인터프리터를 돌리기도 한다.
그렇다면 질문이 하나 더 생긴다.
“그럼 이제 자바스크립트는 필요 없는 거 아닌가?”
아직은 그렇지 않다.
이유는 크게 세 가지다.
1. 브라우저 API는 여전히 자바스크립트 중심이다
DOM 조작, 이벤트 처리, 네트워크 요청 같은 기능들은
여전히 자바스크립트 API를 통해 접근하는 구조다.
즉 WASM 코드도 결국 JS를 통해 브라우저와 상호작용한다.
2. 생태계 차이
자바스크립트는 이미 수십 년 동안 웹 생태계를 구축해왔다.
- npm
- React / Vue / Angular
- 수많은 라이브러리
이 인프라를 다른 언어가 단기간에 따라잡기는 쉽지 않다.
3. WASM의 역할은 “대체”가 아니라 “보완”
현재 WebAssembly는 주로 이런 경우에 사용된다.
- 게임 엔진
- 이미지/영상 처리
- 3D 렌더링
- 고성능 계산
즉 무거운 연산은 WASM,
웹 UI와 로직은 JavaScript가 담당하는 구조가 일반적이다.
그래서 지금의 웹 구조는 이렇게 보는 게 가장 정확하다.
1
2
UI / 웹 로직 → JavaScript
고성능 계산 → WebAssembly
자바스크립트를 대체하기보다는
성능이 필요한 부분을 보완하는 기술에 가깝다.
결국 왜 자바스크립트인가
이 글의 질문을 다시 정리해보면 이렇다.
왜 웹은 파이썬이 아니라 자바스크립트를 사용할까?
사실 더 정확한 질문은 이것에 가깝다.
왜 브라우저는 자바스크립트를 실행하도록 설계됐을까?
답을 하자면,
- 역사
- 표준
- 생태계
이 세 가지가 겹치면서 지금의 구조가 만들어졌다고 할 수 있겠다.
처음에는 단순한 스크립트 언어로 시작했지만,
브라우저들이 자바스크립트를 공통적으로 지원하기 시작하면서 웹의 기본 실행 언어가 되었다.
그리고 시간이 지나면서 상황이 더 굳어졌다.
- 브라우저 API가 자바스크립트를 기준으로 설계되고
- 프레임워크와 라이브러리가 쌓이고
- 수많은 개발 도구들이 만들어졌다.
그래서 지금은 단순히 “다른 언어가 더 좋아서” 바꿀 수 있는 문제가 아니다.
이미 웹 전체가 자바스크립트를 중심으로 돌아가는 플랫폼이 되었기 때문이다.
물론 앞으로도 변화는 계속될 것이다.
WebAssembly처럼 새로운 기술이 등장하면서
브라우저에서 실행되는 코드의 형태는 점점 다양해지고 있다.
하지만 적어도 지금까지는
웹이라는 플랫폼에서 가장 중심에 있는 언어는 여전히 자바스크립트다.
그래서 친구의 질문에 대한 가장 간단한 답은 이것이다.
웹이 자바스크립트를 선택한 게 아니라
브라우저가 자바스크립트를 표준으로 만들었다.
그리고 그 선택이 30년 가까이 이어져 오면서 지금의 웹 생태계가 만들어졌다.
TL;DR
- 브라우저는 자바스크립트를 실행하도록 설계되어 있다.
- 서버는 Python, Java, Go 등 어떤 언어든 사용할 수 있다.
- Node.js 덕분에 JavaScript로 서버도 만들 수 있게 되었다.
- WebAssembly가 등장했지만 아직 JS를 대체하지는 않는다.