string[]과 Array<string>은 같은 타입이야. 전자는 짧고 익숙해서 원소 타입이 단순할 때 잘 읽히고, 후자는 제네릭 문법이라 원소 타입이 긴 유니언이나 복잡한 표현일 때 경계를 분명하게 보여 줄 수 있어.
프로젝트 안에서는 한 기본 스타일을 정하되 가독성이 뚜렷하게 좋아지는 자리에서만 바꿔. 문법 선택 자체에는 실행 성능이나 타입 안전성 차이가 없어. 같은 파일에서 이유 없이 오가면 독자는 존재하지 않는 의미 차이를 찾게 돼.
배열 리터럴의 추론
[1, 2, 3]은 number 배열로, ['a', 'b']는 string 배열로 추론돼. 서로 다른 종류가 섞이면 공통으로 담을 수 있는 유니언을 찾아 (string | number)[]처럼 만든다. 보통은 나중에 값을 더 넣을 수 있도록 리터럴 하나하나보다 넓은 원시 타입으로 추론해.
정확한 값과 길이를 보존하고 싶다면 명시적 튜플 타입이나 as const를 써. 단순 배열과 고정 튜플은 실행 모양은 비슷하지만 타입 계약이 다르다.
메서드가 원소 타입을 이어 간다
배열 메서드는 제네릭 시그니처로 원소 타입을 추적해. User 배열을 filter한 뒤 email을 map하면 결과가 string 배열로 이어져. 콜백 매개변수도 배열에서 문맥적으로 타입을 얻으므로 대부분 따로 표기할 필요가 없어.
filter(Boolean)처럼 실행에서는 값이 줄어들지만 타입 검사기가 정확한 좁히기로 이해하지 못하는 관용구도 있어. null을 제거해 타입까지 좁히려면 타입 술어를 가진 필터 함수를 쓰는 편이 명확해.
다차원 배열과 별칭
number[][]은 숫자 배열의 배열이야. 중첩이 깊거나 원소 타입이 복잡하면 type Matrix<T> = T[][]처럼 의미 있는 별칭을 두는 편이 읽기 좋아. 괄호를 세는 일보다 데이터 구조의 이름을 읽게 해.
단순한 원소에는 T[], 복잡한 원소에는 Array<T>를 고려하되 일관성을 우선해. 타입의 뜻은 같고 선택 기준은 사람의 가독성이야.
피파의 고백
배열 문법 논쟁은 쉽게 커지지만 실제 버그는 대개 배열이 비어 있을 수 있다는 사실이나 인덱스가 범위를 벗어난다는 사실을 놓쳐서 생겨. 철자보다 계약의 구멍을 먼저 봐.