타입스크립트

자바스크립트는 값의 종류를 미리 적지 않는 언어입니다. 변수 하나에 숫자를 넣었다가 글자를 넣어도 문법 오류가 아니고, 함수가 무엇을 받아 무엇을 내놓는지도 코드에 적히지 않습니다. 파일이 스무 개이고 만든 사람이 둘일 때는 이 자유가 빠르게 쓰기에 좋습니다.

규모가 커지면 반대로 작동합니다. 파일이 800개가 되고 만든 사람이 열다섯 명이 되면, 남이 쓴 함수를 부를 때 무엇을 넘겨야 하는지 알 방법이 코드를 따라 읽는 것뿐입니다. 태오가 실제로 이런 일을 겪었습니다. 사용자 정보를 돌려주는 함수를 부르면서 회사 이름을 꺼내려 했는데, 그 값이 어떤 이름으로 들어 있는지 몰라 세 파일을 거슬러 올라가 확인했습니다.

더 나쁜 쪽은 조용히 지나가는 오류입니다. 금액을 더하는 자리에 숫자가 아니라 글자가 들어오면 자바스크립트는 멈추지 않고 두 값을 이어 붙입니다. 3과 5가 8이 아니라 35가 되는데, 이 값이 화면에 뜨기 전까지는 아무도 모릅니다. 사고를 발견하는 자리가 편집기에서 배포 뒤 고객 화면으로 밀려나 있던 것이 문제였고, 타입스크립트는 그 자리를 앞으로 당기려고 만들어졌습니다.

값의 종류를 코드에 적게 하고, 어긋난 자리를 실행 전에 잡아 줍니다. 금액 자리에 글자를 넘기면 저장하는 순간 편집기에 빨간 줄이 그어지고, 그 줄을 지우지 않으면 빌드가 실패합니다. 이 검사는 코드를 돌려 보지 않고 훑어서 문제를 찾는 정적 분석의 한 종류입니다.

실제로 돌아오는 값은 셋입니다.

1. 오류를 만나는 시점이 앞으로 옵니다. 같은 실수를 배포 뒤 문의로 알던 것에서 타이핑하는 중에 아는 것으로 바뀝니다. 고치는 값이 시점에 따라 크게 달라지는 종류의 오류라 이 차이가 큽니다.
2. 함수의 약속이 코드에 적힙니다. 이 함수는 사용자 번호를 받아 이름과 회사명을 돌려준다는 사실이 주석이 아니라 코드로 남습니다. 주석은 낡아도 아무 일이 없지만 이 선언은 어긋나면 빌드가 막습니다.
3. 고치는 작업이 안전해집니다. 사용자 정보에서 회사명 필드의 이름을 바꾸면 그 값을 쓰던 자리 마흔 곳에 전부 빨간 줄이 뜹니다. 한 곳을 빠뜨렸는지 확인하려고 화면을 눌러 볼 필요가 없습니다.

편집기 자동완성도 같은 정보에서 나옵니다. 값의 종류를 알고 있으니 점을 찍는 순간 그 값이 가진 항목 목록이 뜹니다.

한 가지 경계가 있습니다. 적어 둔 종류는 검사할 때만 쓰이고 실행되는 결과물에는 남지 않습니다. 브라우저는 여전히 자바스크립트를 돌립니다. 그래서 서버가 보내 준 값이 선언과 다르게 생겼어도 실행 중에 걸러지지 않고, 밖에서 들어오는 값은 따로 확인하는 코드를 둬야 합니다.

목적이 겹치는 수단이 넷 있고, 넷 다 서로를 대체하기보다 층을 나눠 맡습니다.

1. 자바스크립트를 그대로 쓰고 주석으로 약속만 적습니다. 함수 위에 무엇을 받고 무엇을 돌려주는지 적어 두는 방식이라 빌드 단계가 늘지 않고 배우는 값도 적습니다. 대신 강제력이 없어서 주석과 코드가 어긋난 채 몇 달이 지나기 쉽습니다.
2. 린터를 씁니다. 코드 규칙 위반을 자동으로 잡아 주는 도구인데, 선언해 놓고 쓰지 않는 변수나 빠뜨린 예외 처리처럼 위험한 습관을 걸러 줍니다. 값의 종류는 보지 못하므로 타입스크립트와 겹치지 않고, 대개 둘을 같이 씁니다.
3. 실행 중에 값을 검사하는 코드를 둡니다. 서버 응답이나 사용자 입력처럼 밖에서 들어오는 값이 기대한 모양인지 그 자리에서 확인하고, 아니면 거기서 막습니다. 타입스크립트가 못 막는 자리를 정확히 맡는 수단이라 둘 중 하나를 고르는 관계가 아닙니다.
4. 단위 테스트를 늘립니다. 함수 하나에 값을 넣고 결과가 기댓값과 같은지 확인하는 검사입니다. 타입은 값의 모양이 맞는지를 보고 테스트는 결과가 맞는지를 보므로, 막아 주는 것이 서로 다릅니다.

고르는 기준은 규모와 수명입니다. 두 사람이 두 달 쓸 도구에는 설정이 늘어나는 값이 더 크고, 열다섯 명이 3년 고칠 제품에서는 미리 걸러 내는 값이 훨씬 큽니다.

"이 함수 인자 타입이 너무 느슨해요. 어떤 값이 와도 통과합니다."

무엇이든 허용하는 선언을 써서 검사가 사실상 꺼져 있다는 지적입니다.

"새로 만드는 파일은 타입스크립트로 쓰고 기존 파일은 손댈 때 옮기죠."

한 번에 전체를 바꾸지 않고 점진적으로 넘어가자는 제안입니다.

"서버 응답 타입을 선언해 뒀는데 실제 응답에 그 필드가 없었어요."

선언은 검사용이고 실행 중에는 보장되지 않는다는 사실을 확인한 말입니다.

페이지덱은 화면 쪽 코드를 전부 타입스크립트로 씁니다. 태오가 처음 도입할 때 한 번에 바꾸지 않고, 새 파일부터 적용하고 오래된 파일은 다른 일로 열 때 함께 옮기는 방식을 썼습니다. 여섯 달 뒤에 남은 자바스크립트 파일은 열 개가 안 됐습니다.

민서가 디자인 시스템 쪽 값을 고칠 때 이 효과가 가장 잘 보입니다. 버튼 크기 이름을 바꾸면 그것을 쓰던 화면 전부에 빨간 줄이 떠서, 어느 화면을 확인해야 하는지가 목록으로 나옵니다. 전에는 같은 작업에 화면을 하나하나 눌러 보는 반나절이 붙었습니다.

타입을 적으면 버그가 없어진다고 읽는 경우가 가장 많습니다. 빨간 줄이 실제로 많은 실수를 잡아 주니 그 경험이 그렇게 읽히게 만듭니다. 하지만 이 검사가 보는 것은 값의 모양뿐입니다. 할인율을 더해야 할 자리에서 곱하고 있어도 양쪽이 다 숫자면 아무 일도 일어나지 않습니다. 이 오해를 그대로 두면 팀은 타입이 붙었다는 이유로 테스트를 줄이고, 정작 사고는 계산이 틀린 자리에서 납니다.

선언한 종류가 실행 중에도 지켜진다고 아는 것도 흔합니다. 코드에 적혀 있으니 끝까지 따라간다고 생각하기 쉽습니다. 그런데 이 선언은 검사가 끝나면 사라지고 브라우저에 도착하는 것은 자바스크립트입니다. 서버가 보낸 응답에 약속한 필드가 없어도 실행은 그대로 진행되고, 그 값을 쓰는 순간 화면이 빈칸으로 뜹니다. 밖에서 들어오는 값에는 실행 중 검사를 따로 둬야 하는데, 이 오해를 가진 팀은 그 코드를 생략합니다.