상속 없는 언어 Rust에서 상속하는 9가지 방법 — 왜 Rust는 일부러 상속을 뺐을까

'상속이 없다'는 말에 당황하는 사람들

자바나 C++, 파이썬을 쓰던 사람이 Rust를 처음 만지면 꼭 막히는 지점이 있어요. 바로 클래스 상속(inheritance)이 없다는 거예요. class Dog extends Animal 같은 익숙한 문법이 아예 안 통하거든요. 'OOP의 3대 요소(캡슐화·상속·다형성) 중 하나가 통째로 없다고?' 싶어서 당황하게 돼요.

그런데 이건 Rust가 미완성이라 빠진 게 아니라 일부러 뺀 거예요. 전통적인 상속, 특히 여러 부모를 물려받는 다중 상속은 '죽음의 다이아몬드(diamond problem)' 같은 골치 아픈 문제를 낳고, 부모 클래스를 잘못 건드리면 자식 전부가 깨지는 강한 결합을 만들거든요. 그래서 요즘 언어 설계 흐름은 "상속보다 합성(composition over inheritance)" 쪽으로 기울었고, Rust는 그 철학을 언어 차원에서 밀어붙인 거예요.

그럼 상속을 어떻게 대신하나

상속으로 하던 일을 Rust에서는 여러 도구로 나눠서 해결해요. 대표적인 것들을 풀어볼게요.

첫째, 트레잇(trait) 으로 공통 동작 정의하기. 트레잇은 자바의 인터페이스랑 비슷한데, '이런 메서드를 갖춰야 한다'는 약속이에요. 그런데 Rust 트레잇은 기본 구현(default method) 까지 줄 수 있어서, 부모 클래스가 공통 메서드를 물려주던 역할을 대신해요. 여러 타입이 같은 트레잇을 구현하면 자연스럽게 다형성이 생기죠.

둘째, 합성(composition). '개는 동물이다(is-a)' 대신 '개는 동물의 속성을 가진다(has-a)'로 생각을 바꾸는 거예요. Animal 구조체를 Dog 안에 필드로 넣고, 필요한 메서드를 위임(delegate)하면 돼요. 코드가 조금 길어지는 대신 관계가 명확해져요.

셋째, 열거형(enum). 부모-자식 관계가 '정해진 몇 가지 종류 중 하나'라면, enum이 딱이에요. enum Shape { Circle, Square, Triangle } 처럼 만들고 match로 분기하면, 새 케이스를 빠뜨렸을 때 컴파일러가 잡아줘요. 자식 클래스를 만드는 것보다 안전한 경우가 많죠.

넷째, 제네릭과 트레잇 바운드. '어떤 타입이든 이 트레잇만 구현했다면 받아줄게'라고 하면, 부모 타입으로 자식들을 받던 것과 같은 유연함을 정적(컴파일 타임)으로 얻어요. 여기에 더해 Box<dyn Trait> 같은 트레잇 객체 를 쓰면 런타임 다형성(여러 타입을 한 리스트에 담기)도 가능하고, Deref 트레잇을 영리하게 써서 메서드 위임을 자동화하거나, 매크로로 보일러플레이트를 줄이는 기법들까지 더하면 정말 다양한 길이 나와요.

업계 맥락에서 보면

사실 이건 Rust만의 이야기가 아니에요. Go도 상속 없이 인터페이스와 구조체 임베딩으로 풀고, 함수형 언어들도 상속 대신 타입 클래스나 합성을 써요. '상속은 강력하지만 남용하면 독'이라는 인식이 업계 전반에 퍼진 결과예요. Rust는 거기서 한발 더 나아가 트레잇 시스템을 굉장히 정교하게 다듬어서, 상속 없이도 표현력이 부족하지 않게 만들었어요.

한국 개발자에게

Rust로 넘어올 때 '상속이 없어서 불편하다'고 느낀다면, 그건 대개 상속의 사고방식을 그대로 옮기려 해서 그래요. 'is-a로 묶을까'를 먼저 떠올리는 대신 '이 동작(behavior)을 트레잇으로 뽑을 수 있을까', '이걸 필드로 가질까(has-a)'를 먼저 생각하는 습관을 들이면 훨씬 편해져요. 그리고 이 사고 전환은 Rust를 떠나서도 도움이 돼요. 자바나 코틀린 코드에서도 상속을 줄이고 인터페이스+합성으로 짠 코드가 유지보수가 쉽거든요.

핵심은 이거예요: Rust에 상속이 없는 게 아니라, 상속이 하던 일을 더 안전한 여러 도구로 쪼개놓은 것. 여러분의 코드베이스에서 상속을 합성으로 바꿨다면 더 깔끔해질 만한 곳, 혹시 떠오르는 데 있나요?