자바스크립트

초기의 웹은 읽기만 하는 문서였습니다. HTML로 화면에 무엇이 있는지 적고 CSS로 그것이 어떻게 보일지 정하면 그것으로 끝이었습니다. 두 언어 모두 화면을 그려 놓는 일만 할 뿐, 사용자가 무언가를 누른 다음에 무슨 일이 일어날지는 적을 수 없었습니다.

그래서 아주 작은 판단에도 서버를 한 번 다녀와야 했습니다. 회원가입 화면에서 비밀번호를 여섯 자만 적고 확인을 누르면, 그 값이 서버까지 갔다가 "비밀번호가 너무 짧습니다" 한 줄이 박힌 새 페이지가 통째로 내려왔습니다. 화면이 하얗게 한 번 깜빡이고, 앞서 채워 둔 이름과 이메일은 대개 비어 있었습니다. 글자 수를 세는 일 하나에 왕복 3초가 들고 사용자는 처음부터 다시 입력했습니다.

자바스크립트는 이 왕복을 없애려고 브라우저 안에 넣은 언어입니다. 화면을 적는 언어 옆에 화면이 반응하게 만드는 언어를 하나 더 둔 것이고, 그 덕분에 판단의 일부가 사용자 쪽 컴퓨터에서 곧바로 일어나게 됐습니다. 1995년에 브라우저를 만들던 회사가 열흘 남짓 만에 초안을 내놓은 언어입니다.

자바스크립트가 맡는 일은 셋이고, 셋 다 화면이 뜬 다음에 벌어집니다.

1. 화면 고치기. 브라우저는 읽어 들인 문서를 DOM이라는 객체 덩어리로 바꿔 두는데, 자바스크립트는 그 덩어리를 직접 고칩니다. 댓글 한 줄을 목록 맨 위에 끼워 넣거나, 숨어 있던 오류 문구를 드러내는 일이 여기 속합니다.
2. 사용자 동작에 반응하기. 클릭·입력·스크롤 같은 동작이 일어날 때 실행할 코드를 미리 걸어 둡니다. 비밀번호가 여덟 자를 넘었는지 세는 일은 이제 타자를 치는 동안 그 자리에서 끝납니다.
3. 서버와 주고받기. 페이지를 새로 받는 대신 API만 따로 호출합니다. API 는 프로그램끼리 무엇을 주고받을지 약속해 둔 창구입니다. 목록 끝에 닿았을 때 다음 20건만 받아 와 이어 붙이는 무한 스크롤이 이 방식으로 돌아갑니다.

셋이 한 언어 안에 들어 있다는 점이 브라우저에서 이 언어가 사실상 유일한 선택지가 된 이유입니다. 브라우저가 직접 읽어 실행하는 언어는 오랫동안 이것 하나뿐이었고, 사용자가 따로 설치할 것도 없어서 페이지를 여는 것만으로 코드가 내려와 돌아갑니다.

쓰이는 자리는 그 뒤로 넓어졌습니다. 브라우저 밖에서 자바스크립트를 실행해 주는 런타임이 나오면서 서버 코드도 같은 언어로 쓰게 됐습니다. 커진 화면을 컴포넌트라는 재사용 단위로 쪼개 다루는 방식도, 쪼갠 파일을 배포용으로 묶는 번들러도 모두 이 언어 위에 얹힌 도구입니다.

브라우저 안에서 자바스크립트를 통째로 대신하는 언어는 아직 없습니다. 그래서 실무에서 대안이라고 부르는 것은 보통 셋 중 하나입니다.

1. 덜 쓰기. 움직임이 필요 없는 화면은 HTML 과 CSS 만으로 충분합니다. 펼쳤다 접는 메뉴나 탭 전환처럼 예전에는 코드를 붙이던 것 중 상당수가 지금은 CSS 만으로 됩니다. 이 언어를 줄이면 브라우저가 내려받아 해석할 코드가 줄어 첫 화면이 빨리 뜹니다.
2. 자바스크립트로 바뀌는 다른 언어 쓰기. 타입스크립트가 대표적입니다. 값의 종류를 미리 적어 두는 문법을 더한 언어인데, 브라우저는 그것을 직접 읽지 못하므로 실행 전에 자바스크립트로 바꿔 내보냅니다. 갈아 끼우는 것이 아니라 한 겹 덧대는 쪽입니다.
3. 무거운 계산만 다른 것에 맡기기. 웹어셈블리는 브라우저가 실행할 수 있는 또 하나의 형식으로, 영상 편집이나 3D 처리처럼 계산이 많은 부분을 다른 언어로 짜서 끼워 넣을 때 씁니다. 다만 화면을 고치려면 결국 자바스크립트를 거쳐야 해서 전체를 대신하지는 못합니다.

고르는 문제는 대개 2번 안에서 갈립니다. 사람이 둘인 초기 팀은 타입을 적는 시간이 아까워 자바스크립트로 시작하고, 화면과 사람이 늘어 서로의 코드를 고치는 일이 잦아지면 타입스크립트로 옮깁니다. 페이지덱도 첫 6개월은 자바스크립트만 썼고, 개발자가 넷으로 늘고 같은 함수에 다른 모양의 값이 들어가 화면이 깨지는 일이 반복되면서 옮겼습니다.

"이거 자바스크립트 없이도 되지 않나요? CSS 로 접었다 펴면 될 것 같은데요."

같은 동작을 코드 없이 만들 수 있으니 굳이 붙이지 말자는 제안입니다.

"첫 화면에서 받는 자바스크립트가 400KB 넘어요. 안 쓰는 것부터 걷어 냅시다."

기능이 아니라 내려받는 코드의 양이 지금 느린 원인이라는 진단입니다.

"타입스크립트로 옮기는 건 찬성인데, 기존 파일은 두고 새로 만드는 것부터 할게요."

한 번에 전부 바꾸지 않고 두 언어를 당분간 같이 쓰겠다는 뜻입니다.

페이지덱의 문서 편집 화면을 고치는 일은 대부분 이 언어 위에서 벌어집니다. 민서가 "저장하는 동안 버튼에 도는 표시가 있으면 좋겠어요" 라고 하면, 태오는 저장 요청을 보내는 지점과 응답이 돌아오는 지점 두 곳에 코드를 걸어 버튼의 모양을 바꿉니다. 새 화면을 받아 오는 것이 아니라 이미 떠 있는 화면에서 버튼 하나만 고치는 것이라 깜빡임이 없습니다.

반대로 느리다는 이야기가 나오면 같은 언어가 원인으로 지목됩니다. 첫 화면이 늦게 뜬다는 제보가 들어오면 태오가 가장 먼저 재는 것은 브라우저가 처음에 내려받는 자바스크립트의 크기입니다. 한 번도 열지 않는 설정 화면의 코드까지 함께 내려가고 있으면, 그 부분을 필요할 때 받도록 떼어 냅니다.

이름 때문에 자바라는 언어의 친척이라고 짐작하는 경우가 가장 많습니다. 앞 네 글자가 같으니 그럴 만하고, 실제로 이름도 당시 인기 있던 자바의 이름값을 빌리려고 붙인 것입니다. 하지만 문법도 설계도 만든 곳도 다른 별개의 언어입니다. 둘을 같은 계열로 알고 자바에서 익힌 규칙을 그대로 가져다 쓰면 값이 예상과 다르게 움직이는 지점에서 막히고, 원인을 언어의 차이가 아니라 자기 실수에서 찾느라 시간을 씁니다.

브라우저에서만 도는 언어라는 오해도 흔합니다. 배울 때 화면을 만지는 예제부터 보게 되니 그렇게 굳기 쉽습니다. 실제로는 서버, 명령줄 도구, 배포 스크립트까지 같은 언어로 씁니다. 이것을 모르면 백엔드 쪽 일을 하려면 언어부터 새로 배워야 한다고 지레 정하고, 이미 아는 것으로 할 수 있는 범위를 실제보다 좁게 잡게 됩니다.