Dart 튜토리얼 1편: 언어 철학과 실행 모델

Why#

NOTE

타입을 매번 직접 적기 시작하면, 코드가 빠르게 길어지고 수정 비용도 커집니다.
그래서 “안전성은 유지하면서, 반복 입력은 줄이는 방식”이 필요합니다.

1
// 매번 타입을 직접 적기 시작하면 코드가 금방 길어진다.
2
String name = 'Voyager I';
3
int year = 1977;
4
double distance = 3.7;

What#

NOTE

type inference는 변수의 초기값을 보고 타입을 결정합니다.

How#

TIP

Dart는 type-safe⁷ 언어지만 타입을 일일이 적지 않아도 됩니다.
type inference가 작동해서 변수의 초기값을 보고 타입을 자동으로 결정합니다.
이렇게 하면 코드는 짧아지지만 타입 검사는 그대로 작동합니다.

1
var name = 'Voyager I';       // String으로 추론됨
2
var year = 1977;               // int로 추론됨
3
var distance = 3.7;            // double로 추론됨

이 코드에서 name은 String, year는 int, distance는 double로 고정됩니다.
즉, 이후에는 각 변수에 “그 타입이 아닌 값”을 넣으려고 하면 컴파일 단계에서 막힙니다.

Watch out#

WARNING

타입이 추론된 변수에 다른 타입 값을 다시 넣을 수 없습니다.

1
var year = 1977;
2
// year = '1977'; // 컴파일 오류: year는 int로 추론되었다.

결론: 타입을 명시하지 않아도 컴파일러가 타입 오류를 잡아냅니다.

Why#

NOTE

개발 중에는 “빨리 고치고 바로 확인”하는 반복 속도가 중요합니다.
반대로 배포 후에는 “빠르게 시작하고 일정한 성능으로 동작”하는 것이 중요합니다.

1
# 개발 중: 빠르게 실행해서 확인
2
dart run
3

4
# 배포용: 미리 컴파일해서 실행 파일 생성
5
dart compile exe

What#

NOTE

JIT는 실행하면서 필요한 코드를 즉시 컴파일하는 방식이고, AOT는 배포 전에 미리 컴파일하는 방식입니다.

How#

TIP

Dart는 개발 단계와 배포 단계에 각각 다른 컴파일 방식을 사용합니다.

개발 단계: JIT 컴파일
코드를 수정하면 즉시 반영되는 hot reload⁸가 가능합니다.
Dart VM⁹이 변경된 부분만 빠르게 재컴파일하므로 수정→테스트 사이클이 1초 안에 완료됩니다.
앱 상태를 유지한 채로 UI나 로직을 바로 확인할 수 있어 생산성이 크게 올라갑니다.

배포 단계: AOT 컴파일
앱을 미리 기계어로 컴파일해서 배포합니다.
실행 시작이 빠르고 성능이 일정하며 메모리 사용도 최적화됩니다.
웹 플랫폼에서는 JavaScript¹⁰나 WebAssembly¹¹로 컴파일할 수 있습니다.

1
void main() {
2
  print('Hello, Dart');
3
}
4
// 개발: dart run으로 JIT 실행
5
// 배포: dart compile exe로 AOT 컴파일

Watch out#

WARNING

이 선택은 “코드로 전환하는 기능”이 아니라, 실행/빌드 도구가 결정하는 실행 방식입니다.
즉, 같은 코드라도 개발 실행과 배포 빌드에서 동작 방식(컴파일 시점)이 달라질 수 있습니다.

결론: 개발 속도와 배포 성능을 동시에 확보합니다.

Why#

NOTE

null은 “값이 없음”을 뜻하지만, 체크를 빼먹는 순간 런타임 오류로 이어지기 쉽습니다.
그래서 “어디가 null이 될 수 있는지”를 타입으로 드러내는 규칙이 필요합니다.

1
String? name = null;
2
// print(name.length); // 컴파일 오류: name이 null일 수 있다.

What#

NOTE

sound null safety는 non-nullable¹²로 선언한 값이 runtime에서도 null이 될 수 없게 보장합니다.

How#

TIP

Dart는 sound null safety를 적용해서 null 관련 오류를 runtime에서 컴파일 단계로 이동시킵니다.

기본은 non-nullable
타입 뒤에 ?를 붙이지 않으면 null이 될 수 없습니다.
컴파일러가 이 규칙을 강제하므로 실행 전에 null 할당을 잡아냅니다.

nullable¹³은 명시적으로 표현
null이 필요한 변수에만 ?를 붙여서 의도를 명확히 합니다.
nullable 변수에 접근할 때는 null 체크를 먼저 하도록 컴파일러가 요구합니다.

1
String title = 'Dart';          // null 불가
2
String? subtitle = null;        // null 허용
3

4
// title.length는 항상 안전
5
// subtitle.length는 컴파일 오류 → subtitle?.length로 수정 필요

Watch out#

WARNING

nullable 값은 “사용하기 전에” 반드시 처리 흐름을 정해야 합니다.
가장 단순한 방법은 if로 null 여부를 확인한 뒤 사용하는 것입니다.

1
String? subtitle = null;
2

3
if (subtitle != null) {
4
  print(subtitle.length);
5
}

왜 sound인가
컴파일러가 non-nullable이라고 판단한 변수는 runtime에서도 절대 null이 될 수 없습니다.
디버거로 확인해도 null이 들어있지 않습니다.
이것이 “sound”의 의미입니다.

설계 의도는 다음과 같습니다.

• runtime 오류를 컴파일 단계로 이동시켜 배포 전에 문제를 발견한다.
• null 체크가 필요한 곳과 불필요한 곳을 타입만 봐도 알 수 있다.
• 방어 코드를 줄여서 핵심 로직에 집중할 수 있다.