Why This Work Exists
`struct를 써야 하나, class를 써야 하나`는 자주 나오는데, 기준 없이 고르면 모델이 불필요하게 공유되거나 반대로 객체 identity가 필요한 곳에 값 타입을 써서 구조가 어색해진다.
`struct`와 `class`를 문법 차이로만 외우지 말고, 값처럼 다뤄야 하는지, 하나의 공유 객체로 다뤄야 하는지, 수명주기와 동시성까지 포함해 선택 기준을 정리한 문서다.
2026-04-09
`struct를 써야 하나, class를 써야 하나`는 자주 나오는데, 기준 없이 고르면 모델이 불필요하게 공유되거나 반대로 객체 identity가 필요한 곳에 값 타입을 써서 구조가 어색해진다.
| 상황 | 더 자연스러운 선택 | 이유 |
|---|---|---|
| API 응답 모델, 화면 상태값 | `struct` | 복사 semantics와 불변 설계가 잘 맞고 공유 mutable state를 줄이기 쉽다. |
| 이미지 캐시, 세션 매니저, 서비스 객체 | `class` | 여러 곳에서 하나의 객체를 공유하고 수명주기를 관리하는 게 자연스럽다. |
| identity가 중요한 도메인 객체 | `class` | 값이 같아도 같은 실체인지 구분해야 하는 경우가 있다. |
| 작고 단순한 데이터 묶음 | `struct` | 값처럼 전달하고 테스트하기 쉽다. |
특별한 이유가 없다면 모델은 먼저 `struct`를 검토하고, 공유 identity와 수명주기가 핵심일 때만 `class`를 선택하는 편이 안전하다.
`struct`를 기본 선택으로 보자는 말은 왜 자주 나오나요?
값 타입은 복사된 값처럼 동작해서 공유 mutable state를 줄이기 쉽다. 그래서 예측 가능성이 높고 테스트와 동시성 안전성 측면에서 유리하다. 단, identity와 수명주기가 중요한 객체까지 무조건 `struct`로 밀어붙이면 오히려 설계가 어색해질 수 있다.
그럼 `class`는 언제 꼭 필요하나요?
하나의 인스턴스를 여러 곳이 같이 보고, 그 상태 변화가 모두에게 공유되어야 할 때 필요하다. 예를 들어 캐시, 세션, 서비스 객체, coordinator 같은 것은 같은 객체를 참조하는 편이 자연스럽다.
값 타입은 무조건 스택, 참조 타입은 무조건 힙이라고 외워도 되나요?
그렇게만 외우면 부족하다. 실무에서 더 중요한 것은 메모리 위치보다 동작 semantics다. 값 타입은 복사된 값처럼 행동하고, 참조 타입은 같은 객체를 공유한다는 점을 먼저 이해해야 한다.
동시성에서는 어떤 쪽이 더 유리한가요?
일반적으로는 값 타입이 shared mutable state를 줄이기 쉬워 유리하다. 반면 참조 타입은 여러 task가 같은 객체를 동시에 만질 수 있어 data race 위험이 커진다. 그래서 참조 타입을 써야 한다면 actor나 다른 동기화 전략을 같이 봐야 한다.