39장. 백엔드 개발자가 기억해야 할 Kotlin

긴 여정의 마지막 장입니다.

지금까지 문법부터 구조,
그리고 실전 프로젝트까지 달려왔습니다.

이 장에서는 그 모든 것을
여덟 개의 문장으로 압축합니다.

앞으로 코드를 짜다 길을 잃을 때
이 여덟 가지를 떠올리면 됩니다.

39.1 불변성을 기본값으로 사용한다

값은 되도록 바뀌지 않게 만듭니다. (2장)

• 일단 val로 시작하고, 꼭 필요할 때만 var
• 도메인은 copy로 새 상태를 만든다 (9·34장)

바뀌지 않는 값은
추적할 걱정이 없어 버그가 줄어듭니다.

39.2 Null을 타입의 일부로 생각한다

코틀린에서 null은
“타입에 포함된 정보“입니다. (5장)

• String과 String?는 다른 타입이다
• !!는 최후의 수단으로만
• 실패는 ?., ?:로 명확히 다룬다

null을 두려워하지 말고
타입으로 다스립니다.

39.3 데이터와 상태를 명확하게 모델링한다

값과 상태를
정확한 도구로 표현합니다.

• 데이터 묶음은 data class (9장)
• 정해진 값은 enum (10·34장)
• 여러 결과는 sealed (10·24장)

타입이 곧 문서가 되게 만듭니다.

39.4 Interface로 경계를 만든다

구현이 아니라
인터페이스에 의존합니다. (8·35·36장)

• Repository는 인터페이스로 정의
• Service는 인터페이스를 생성자로 받는다
• 덕분에 구현을 자유롭게 교체하고 테스트한다

경계를 잘 그으면
바뀌는 것과 바뀌지 않는 것이 분리됩니다.

39.5 Collection 함수를 활용한다

반복문 대신
컬렉션 함수로 의도를 드러냅니다. (13장)

• filter, map, groupBy, sumOf
• “무엇을 하는지“가 코드에 그대로 보이게

백엔드는 데이터 가공의 연속입니다.
컬렉션 함수는 그 핵심 도구입니다.

39.6 Kotlin 문법을 과도하게 사용하지 않는다

코틀린다운 코드는
문법을 많이 쓴 코드가 아닙니다. (15·38장)

• 스코프 함수를 깊게 중첩하지 않기
• 화려함보다 읽기 쉬움을 택하기

좋은 코드의 기준은 언제나 “읽기 쉬움“입니다.

39.7 Java 생태계와의 연결을 이해한다

코틀린은 자바 위에서 삽니다. (9부)

• 자바 라이브러리를 그대로 쓸 수 있다
• 플랫폼 타입은 방어적으로 다룬다 (6·25장)
• 프레임워크는 리플렉션 위에서 동작한다 (28장)

이 연결을 이해하면
스프링을 배울 때 훨씬 수월합니다.

39.8 테스트하기 쉬운 객체를 만든다

테스트하기 쉬운 코드가
곧 좋은 구조입니다. (30·31·36장)

• 의존성은 생성자로 받는다
• 하나의 객체는 하나의 책임만
• Fake로 빠르고 안정적으로 검증한다

“테스트하기 쉽게“라는 기준 하나가
전체 설계를 좋은 방향으로 이끕니다.

마치며: 다음 여정으로

축하합니다.
이 책의 모든 장을 마쳤습니다.

우리는 웹 프레임워크 없이도
백엔드의 핵심 로직을 코틀린으로 완성했습니다.

• 코틀린 문법을 두루 익혔고
• 안전하게 데이터를 다루는 법을 배웠고
• 객체를 설계하고 테스트하는 법을 익혔고
• 순수 코틀린으로 주문 시스템을 만들었습니다

이제 다음 단계가 남았습니다.
바로 스프링입니다.

지금까지 손으로 만든
DI, 인터페이스, 계층 구조를
스프링은 자동으로 도와줍니다.

그 편리함의 밑바탕에
“왜 그렇게 하는가“가 있다는 것을
이제 여러분은 이미 알고 있습니다.

좋은 코틀린 코드가
좋은 백엔드 개발자의 출발점입니다.

여기까지 온 여러분의 다음 코드를 응원합니다.