역할이 셋으로 나뉘어 있다
앞 편에서 브라우저가 서버에게 파일을 받아 화면을 그린다고 했다. 그 받아 오는 파일이 이 셋이다.
HTML은 무엇을 보여 줄지를 적는다. 이 화면에 제목이 있고 목록이 있고 로그인 버튼이 있다는 식이다. CSS는 어떻게 보일지를 적는다. 그 버튼이 오른쪽 위에 있고 배경은 노란색이고 글자는 몇 픽셀이라는 식이다. JavaScript는 눌렀을 때 무슨 일이 일어나는지를 적는다. 이 버튼을 누르면 영상이 재생된다는 식이다.
브라우저가 여럿인데도 같은 화면이 나오는 이유가 여기 있다. Chrome이든 Edge든 Firefox든, 이 세 종류의 파일을 받으면 정해진 약속대로 조합해 화면으로 그린다는 점은 같다. 예전에는 브라우저마다 해석이 달라 같은 CSS가 다르게 보이는 일이 흔했지만 지금은 거의 사라졌다.
HTML — 무엇이 있는가
<button class="btn">로그인</button>
CSS — 어떻게 보이는가
.btn { background: #ffcc00; font-size: 16px; }
JavaScript — 누르면 무슨 일이 나는가
document.querySelector('.btn').addEventListener('click', ...)CSS는 왜 따로 떨어져 나왔나
흔한 설명 하나를 바로잡고 간다. CSS는 HTML이 스타일을 표현할 수 없어서 생긴 것이 아니다.
HTML 안에서도 스타일을 줄 수 있다. 태그마다 style 속성을 붙이면 된다. 문제는 그렇게 하면 문서가 감당 못 하게 길어진다는 것이다. 버튼 하나에 색과 크기와 여백과 테두리를 다 적고, 그런 요소가 수백 개면 문서를 읽을 수 없게 된다.
그래서 스타일만 따로 떼어 냈다. 무엇이 있는지는 HTML에, 어떻게 보이는지는 CSS에 두는 분리다. 같은 스타일을 여러 요소에 재사용할 수 있다는 이득도 여기서 나온다.
스타일이 안 먹힐 때 문법부터 의심하지 않는다
CSS에서 처음 크게 막히는 지점은 우선순위다. 같은 요소 하나에 여러 규칙이 동시에 걸릴 수 있기 때문이다.
버튼을 가리키는 방법이 여러 가지다. 태그 이름으로 button이라고 쓸 수도 있고, 클래스 이름으로 .btn이라고 쓸 수도 있고, button 안의 span처럼 더 좁혀서 쓸 수도 있다. 이 규칙들이 같은 요소에 동시에 걸리면 더 좁게 특정한 쪽이 이긴다.
그래서 색이 안 바뀔 때 문법 오류부터 찾으면 시간을 버린다. 대개는 문법이 맞는데 다른 곳에 있는 더 좁은 규칙이 이미 이기고 있는 것이다. 브라우저 개발자 도구에서 그 요소를 클릭하면 어떤 규칙이 이겼고 어떤 규칙이 밀려 취소선이 그어졌는지 그대로 보인다.
에이전트에게 고쳐 달라고 할 때도 이 구분이 유용하다. 색이 안 바뀝니다보다 이 클래스에 준 배경색이 다른 규칙에 밀리는 것 같습니다가 훨씬 빠르게 끝난다.
| 가리키는 법 | 예시 | 좁기 |
|---|---|---|
| 태그 이름 | button { } | 넓다 |
| 클래스 이름 | .btn { } | 중간 |
| 관계로 좁힘 | button span { } | 좁다 |
TypeScript는 JavaScript의 다른 이름이 아니다
JavaScript는 원래 화면을 움직이려고 만들어졌지만 프로그래밍 언어이기 때문에 서버 쪽 일에도 쓰이기 시작했다. 계산하고 값을 저장하고 반복할 수 있으면 언어라고 부르는데, JavaScript는 그 조건을 갖췄다. HTML은 화면 구성을 적을 뿐이라 언어가 아니라 마크업이라고 부른다.
그런데 다루는 일이 커지자 문제가 드러났다. 어떤 값이 숫자인지 글자인지를 미리 정해 두지 않아서, 잘못된 값이 들어가도 실행하기 전에는 아무도 모른다.
그래서 위에 규칙을 한 겹 얹었다. 이 값은 숫자다, 이 값은 글자다를 못 박아 두고 어긋나면 실행 전에 잡아 준다. 그게 TypeScript다. 별개의 언어를 새로 배우는 것이 아니라 JavaScript에 형태 선언을 추가한 것이다.
바이브 코딩에서 만들어지는 프로젝트가 대부분 TypeScript인 것도 이 때문이다. 사람이 아니라 에이전트가 코드를 쓸수록, 실행 전에 어긋남을 잡아 주는 장치의 값이 커진다.