2025년 10월 04일·7분
스칼라가 JVM에서 함수형과 객체지향을 결합한 방법
스칼라가 JVM 위에서 함수형과 객체지향 아이디어를 결합하도록 설계된 이유, 잘한 점, 그리고 팀이 알아야 할 트레이드오프를 살펴봅니다.
스칼라가 JVM 위에서 함수형과 객체지향 아이디어를 결합하도록 설계된 이유, 잘한 점, 그리고 팀이 알아야 할 트레이드오프를 살펴봅니다.
자바는 JVM을 성공으로 이끌었지만, 동시에 많은 팀이 결국 마주한 기대값도 만들었습니다: 많은 보일러플레이트, 가변 상태에 대한 강한 의존, 그리고 관리하려면 프레임워크나 코드 생성이 필요한 패턴들. 개발자들은 JVM의 속도, 도구, 배포 이야기를 좋아했지만—아이디어를 더 직접적으로 표현할 수 있는 언어를 원했습니다.
2000년대 초반이면 일상적인 JVM 작업은 장황한 클래스 계층, 게터/세터 의례, 그리고 프로덕션으로 흘러들어가는 null 관련 버그를 포함하고 있었습니다. 동시성 프로그램을 작성할 수는 있었지만, 공유 가변 상태는 미묘한 경쟁 조건을 쉽게 만들었습니다. 팀이 좋은 객체지향 설계를 따르더라도, 일상 코드에는 여전히 많은 우연적 복잡성이 남아 있었습니다.
스칼라의 선택은 더 나은 언어가 JVM을 버리지 않고도 그 마찰을 줄일 수 있다는 것이었습니다: 바이트코드로 컴파일해 성능을 "충분히 좋게" 유지하면서, 개발자가 도메인을 깔끔하게 모델링하고 변경하기 쉬운 시스템을 만들도록 돕는 기능을 제공하는 것입니다.
대부분의 JVM 팀은 “순수 함수형”과 “순수 객체지향” 사이를 선택하는 것이 아니었습니다—그들은 마감 기한 내에 소프트웨어를 출시하려고 했습니다. 스칼라는 OO를 필요한 곳(캡슐화, 모듈 API, 서비스 경계)에 사용하면서, 함수형 아이디어(불변성, 표현식 지향 코드, 조합 가능한 변환)를 경계 내부에서 활용해 프로그램을 더 안전하고 이해하기 쉽게 만들고자 했습니다.
그 혼합은 실제 시스템이 종종 구축되는 방식과 닮았습니다: 모듈과 서비스 경계를 객체지향적으로 두고, 그 내부에서 버그를 줄이고 테스트를 단순화하기 위해 함수형 기법을 사용하는 식입니다.
스칼라는 더 강한 정적 타입 검사, 더 나은 조합과 재사용성, 그리고 보일러플레이트를 줄이는 언어 수준의 도구를 제공하는 것을 목표로 했습니다—모두 JVM 라이브러리 및 운영과 호환되는 상태로 유지하면서요.
마틴 오더스키는 자바의 제네릭 작업을 거치며 ML, Haskell, Smalltalk 같은 언어의 장점을 보고 스칼라를 설계했습니다. 스칼라 주위에 형성된 커뮤니티(학계, 엔터프라이즈 JVM 팀, 이후 데이터 엔지니어링)는 이 언어가 이론과 실무 요구를 균형 있게 반영하도록 형성하는 데 도움을 주었습니다.
스칼라는 “모든 것은 객체다”라는 문구를 진지하게 받아들입니다. 다른 JVM 언어에서 “원시값”이라고 생각할 수 있는 값들—예: 1, true, 'a'—도 메서드를 가진 일반 객체처럼 동작합니다. 즉 1.toString이나 'a'.isLetter처럼 프리미티브 연산과 객체 연산 사이를 전환하지 않고도 코드를 쓸 수 있습니다.
자바 스타일 모델링에 익숙하다면, 스칼라의 객체지향 표면은 즉시 알아볼 수 있습니다: 클래스를 정의하고, 인스턴스를 생성하고, 메서드를 호출하며, 인터페이스와 유사한 타입으로 동작을 그룹화합니다.
도메인을 직관적으로 모델링할 수 있습니다:
class User(val name: String) {
def greet(): String = s"Hi, $name"
}
val u = new User("Sam")
println(u.greet())
이 친숙함은 JVM에서 중요합니다: 팀은 기본적인 "메서드가 있는 객체" 사고방식을 포기하지 않고도 스칼라를 도입할 수 있습니다.
스칼라의 객체 모델은 자바보다 더 균일하고 유연합니다:
object Config { ... }), 이는 자바의 static 패턴을 자주 대체합니다.val/var가 되어 필드가 되므로 보일러플레이트가 줄어듭니다.상속은 여전히 존재하고 자주 사용되지만, 경량화된 경우가 많습니다:
class Admin(name: String) extends User(name) {
override def greet(): String = s"Welcome, $name"
}
일상적인 작업에서 이 의미는 스칼라가 사람들이 의존하는 동일한 OO 빌딩 블록—클래스, 캡슐화, 오버라이딩—을 지원하면서 static 과다 사용이나 장황한 게터/세터 같은 JVM 시대의 어색함을 완화한다는 것입니다.
스칼라의 함수형 측면은 별도의 “모드”가 아니라—언어가 일상적으로 유도하는 기본값에서 드러납니다. 두 가지 아이디어가 대부분을 이끕니다: 불변 데이터를 선호하고, 코드를 값을 생성하는 표현식으로 취급하는 것입니다.
val vs var)스칼라에서는 값을 val로, 변수를 var로 선언합니다. 둘 다 존재하지만 문화적 기본값은 val입니다.
val을 쓰면 이 참조는 재할당되지 않을 것이라고 명시하는 것입니다. 이 작은 선택은 프로그램의 숨겨진 상태를 줄입니다. 상태가 적으면 코드가 커질수록 특히 여러 단계의 비즈니스 워크플로에서 값이 반복 변환될 때 놀라움이 줄어듭니다.
var는 여전히 자리를 가집니다—UI 접합 코드, 카운터, 성능이 중요한 구간 등—하지만 var를 사용한다는 것은 자동적 선택이 아니라 의도적인 결정처럼 느껴져야 합니다.
스칼라는 결과를 생성하는 표현식으로 코드를 작성하도록 권장합니다. 이는 대부분 상태를 변경하는 일련의 문(statement)보다 더 낫습니다.
종종 이는 더 작은 결과들로부터 최종 결과를 구성하는 형태로 보입니다:
val discounted =
if (isVip) price * 0.9
else price
여기서 if는 표현식이므로 값을 반환합니다. 이 스타일은 "이 값은 무엇인가?"를 추적하기 쉽게 해주며 여러 할당의 흔적을 추적할 필요를 줄여줍니다.
map/filter)컬렉션을 수정하는 루프 대신 데이터 변환을 사용하는 코드가 일반적입니다:
val emails = users
.filter(_.isActive)
.map(_.email)
filter와 map은 다른 함수를 입력으로 받는 고차 함수입니다. 이점은 학술적인 것이 아니라 명료성입니다. 파이프라인을 읽으면: 활성 사용자를 유지하고 이메일을 추출한다는 작은 이야기로 읽힙니다.
순수 함수는 입력에만 의존하고 부작용(숨겨진 쓰기, I/O)을 갖지 않습니다. 코드의 더 많은 부분이 순수하면 테스트가 간단해집니다: 입력을 주고 출력을 단언하면 됩니다. 추론도 쉬워집니다. 시스템의 다른 곳이 무엇을 변경했는지 추측할 필요가 줄어듭니다.
스칼라가 "어떻게 거대한 클래스 가족을 만들지 않고 동작을 공유할 것인가"에 대한 대답은 트레잇입니다. 트레잇은 인터페이스처럼 보이지만 실제 구현—메서드, 필드, 작은 헬퍼 로직—도 포함할 수 있습니다.
트레잇은 "로그 가능", "검증 가능", "캐시 가능" 같은 능력을 설명하고 여러 다른 클래스에 그 능력을 붙일 수 있게 합니다. 이는 모두가 상속해야 하는 몇몇 과도하게 큰 베이스 클래스 대신 작고 집중된 빌딩 블록을 장려합니다.
단일 상속 클래스 계층과 달리 트레잇은 제어된 방식의 행동의 다중 상속을 위해 설계되었습니다. 클래스에 여러 트레잇을 추가할 수 있으며, 스칼라는 메서드가 어떻게 해석되는지에 대해 명확한 선형화 순서를 정의합니다.
트레잇을 "믹스인"할 때, 행동을 클래스 경계에서 조합하는 것이지 상속 구조를 깊게 파고드는 것이 아닙니다. 유지보수가 더 쉬운 경우가 많습니다:
간단한 예:
trait Timestamped { def now(): Long = System.currentTimeMillis() }
trait ConsoleLogging { def log(msg: String): Unit = println(msg) }
class Service extends Timestamped with ConsoleLogging {
def handle(): Unit = log(s"Handled at ${now()}")
}
트레잇을 사용하세요, 만약:\n
추상 클래스를 사용하세요, 만약:\n
실제 이득은 스칼라가 재사용을 부품 조합처럼 느껴지게 만든다는 점입니다. 운명을 이어받는 것이 아니라 부품을 조립하는 방식이 더 자연스럽습니다.
스칼라의 패턴 매칭은 언어를 강하게 "함수형"처럼 느끼게 만드는 기능 중 하나입니다. 전통적인 가상 메서드의 웹에 로직을 밀어넣는 대신, 값의 형태를 살펴보고 그 모양에 따라 동작을 선택할 수 있습니다.
가장 단순하게 말하면 패턴 매칭은 더 강력한 switch입니다: 상수, 타입, 중첩 구조를 매칭하고 값의 일부를 이름에 바인딩할 수 있습니다. 표현식이기 때문에 자연스럽게 결과를 생성합니다—컴팩트하고 가독성 높은 코드를 만듭니다.
sealed trait Payment
case class Card(last4: String) extends Payment
case object Cash extends Payment
def describe(p: Payment): String = p match {
case Card(last4) =\u003e s"Card ending $last4"
case Cash =\u003e "Cash"
}
sealed trait와 case class로 데이터 모델링위 예시는 스칼라 스타일의 ADT를 보여줍니다:\n
sealed trait는 닫힌 집합의 가능성을 정의합니다.\n- case class와 case object가 구체적 변형을 정의합니다."Sealed"는 컴파일러가 같은 파일 내의 모든 유효한 서브타입을 알 수 있게 해 주므로 안전한 패턴 매칭을 가능하게 합니다.
ADT는 도메인의 실제 상태를 모델링하도록 권장합니다. null, 마법 같은 문자열, 혹은 불가능한 방식으로 결합될 수 있는 불리언 대신 허용되는 경우들을 명시적으로 정의하세요. 그러면 많은 오류 자체가 코드에서 표현될 수 없게 되어 프로덕션으로 흘러갈 수 없습니다.
패턴 매칭은 다음 상황에서 빛납니다:\n
모든 동작이 거대한 match 블록으로 표현되고 코드베이스 곳곳에 흩어지면 남용입니다. 매치가 커지거나 곳곳에서 등장하면 보통 더 나은 분해(헬퍼 함수)나 일부 행동을 데이터 타입 자체에 더 가깝게 옮길 필요가 있다는 신호입니다.
스칼라의 타입 시스템은 팀이 스칼라를 선택하는 큰 이유 중 하나이자, 일부 팀이 떠나는 큰 이유 중 하나입니다. 잘 쓰이면 간결하면서도 강력한 컴파일 타임 검사를 제공하고, 잘못 쓰이면 컴파일러를 디버깅하는 기분이 들게 합니다.
타입 추론 덕분에 대부분의 경우 타입을 일일이 적을 필요가 없습니다. 컴파일러는 문맥에서 타입을 유추할 수 있습니다.
이는 보일러플레이트를 줄여주고: 값이 무엇을 나타내는지에 집중하게 해줍니다. 타입 주석을 추가할 때는 보통 경계(공개 API, 복잡한 제네릭)에서 의도를 명확히 하기 위해 추가합니다.
제네릭은 컨테이너와 유틸리티를 여러 타입에 대해 작성할 수 있게 해 줍니다(예: List[Int], List[String]). 분산(variance)은 제네릭 타입의 파라미터가 바뀔 때 해당 제네릭 타입을 대체할 수 있는지에 관한 문제입니다.
+A)은 대략 "고양이들의 리스트를 동물들의 리스트로 사용할 수 있다"는 의미입니다.\n- 반공변성(-A)은 대략 "동물을 처리하는 핸들러는 고양이를 처리할 수 있는 핸들러로 사용할 수 있다"는 의미입니다.라이브러리 설계에 유용하지만 처음 접하면 혼란스러울 수 있습니다.
given(Scala 3)스칼라는 타입을 수정하지 않고 행동을 추가하는 패턴을 널리 사용합니다. 암시적으로 동작을 전달해 특정 타입에 대한 비교나 출력 방식을 자동으로 선택하게 할 수 있습니다.
Scala 2에서는 이게 implicit로, Scala 3에서는 given/using으로 표현됩니다. 아이디어는 동일합니다: 행동을 조합 가능한 방식으로 확장합니다.
트레이드오프는 복잡성입니다. 타입 레벨 트릭은 긴 에러 메시지를 만들 수 있고, 과도하게 추상화된 코드는 신규 개발자가 읽기 어렵습니다. 많은 팀은 실무 규칙을 채택합니다: 타입 시스템을 API를 단순화하고 실수를 방지하는 데 사용하되, 모두가 컴파일러처럼 생각해야 변경할 수 있는 설계는 피하세요.
스칼라에는 동시성 코드를 작성하기 위한 여러 "차선"이 있습니다. 문제마다 필요한 장비가 다르므로 유용하지만, 팀이 무엇을 채택할지 의도적으로 결정해야 한다는 뜻이기도 합니다.
많은 JVM 앱에서 Future는 작업을 동시 실행하고 결과를 합성하는 가장 간단한 방법입니다. 작업을 시작하고 map/flatMap으로 비동기 워크플로를 구성해 스레드를 차단하지 않고 결과를 결합합니다.
좋은 사고 모델: Futures는 독립적인 작업(API 호출, DB 쿼리, 백그라운드 계산)에 적합하며 결과를 합치고 실패를 한 곳에서 처리하고자 할 때 유용합니다.
스칼라는 for-컴프리헨션을 통해 Future 체인을 더 선형적으로 표현할 수 있게 합니다. 새로운 동시성 원시를 추가하는 건 아니지만 의도를 더 명확히 하고 "콜백 중첩"을 줄여줍니다.
단점: 예를 들어 Future를 기다리며 차단하거나 CPU 바운드와 IO 바운드를 분리하지 않으면 실행 컨텍스트를 과부하시킬 수 있다는 점입니다.
장기간 실행되는 파이프라인(이벤트, 로그, 데이터 처리)의 경우 스트리밍 라이브러리(Akka/Pekko Streams, FS2 등)는 흐름 제어에 초점을 맞춥니다. 핵심 기능은 역압력으로, 소비자가 따라올 수 없을 때 생산자가 느려집니다.
이 모델은 단순히 "더 많은 Futures를 띄운다"보다 더 나은 경우가 많습니다. 처리량과 메모리를 1급 개념으로 다루기 때문입니다.
액터 라이브러리(Akka/Pekko)는 동시성을 메시지로 통신하는 독립 컴포넌트로 모델링합니다. 각 액터는 한 번에 한 메시지를 처리하므로 상태를 추론하기가 쉬워집니다.
장기 실행 상태를 가진 프로세스(장치, 세션, 코디네이터)가 필요할 때 액터가 빛나지만, 단순한 요청/응답 앱에는 과할 수 있습니다.
불변 데이터 구조는 공유 가변 상태를 줄입니다—많은 경쟁 조건의 원인입니다. 스레드, Future, 액터 등을 사용하더라도 불변 값을 전달하면 동시성 버그가 줄고 디버그가 수월해집니다.
단순한 병렬 작업에는 Futures로 시작하세요. 처리량을 제어해야 하면 스트리밍으로 옮기고, 상태와 조정이 디자인을 지배하면 액터를 고려하세요.
스칼라의 가장 실용적인 장점은 JVM 위에서 동작하고 자바 생태계를 직접 사용할 수 있다는 점입니다. 자바 클래스를 인스턴스화하고, 자바 인터페이스를 구현하고, 자바 메서드를 거의 의례 없이 호출할 수 있습니다—대부분의 경우 마치 다른 스칼라 라이브러리를 사용하는 것처럼 느껴집니다.
대부분의 "해피 패스" 상호운용성은 직관적입니다:\n
내부적으로 스칼라는 JVM 바이트코드로 컴파일됩니다. 운영 측면에서는 다른 JVM 언어처럼 동작합니다: 같은 런타임에서 관리되고 같은 GC를 사용하며 친숙한 도구로 프로파일/모니터링됩니다.
마찰은 스칼라의 기본값이 자바와 맞지 않을 때 드러납니다:\n
Null. 많은 자바 API가 null을 반환합니다; 스칼라 코드는 Option을 선호합니다. 깜짝 NullPointerException을 피하려면 자바 결과를 방어적으로 래핑하는 일이 자주 필요합니다.
체크드 예외. 스칼라는 체크드 예외를 강제하지 않지만 자바 라이브러리는 여전히 던질 수 있습니다. 이것은 오류 처리가 일관되지 않게 느껴질 수 있으므로 예외를 어떻게 변환할지 표준화하는 것이 좋습니다.
가변성. 자바 컬렉션과 세터 중심 API는 변이를 조장합니다. 스칼라에서 가변성과 불변성 스타일을 섞으면 API 경계에서 혼란스러운 코드가 될 수 있습니다.
경계를 번역 레이어로 취급하세요:\n
null을 즉시 Option으로 변환하고, 가장자리에서만 Option을 다시 null로 변환하세요.\n- 자바 컬렉션은 팀이 정한 스칼라 컬렉션 타입으로 매핑하세요.\n- 자바 예외는 도메인 오류(또는 단일 오류 모델)로 감싸서 호출자가 예측 불가능한 실패 모드에 대처하지 않도록 하세요.\n- 자바가 소비할 공용 API는 자바 친화적으로 단순하게 유지하고, 내부 스칼라 모듈은 스칼라식으로 유지하세요.잘하면 상호운용성 덕분에 스칼라 팀은 검증된 JVM 라이브러리를 재사용하면서 서비스 내부에서는 스칼라 코드를 더 표현력 있고 안전하게 유지할 수 있습니다.
스칼라의 장점은 매력적입니다: 우아한 함수형 코드를 쓰고, 도움이 되는 곳에는 OO 구조를 유지하며 JVM 위에 남아 있을 수 있습니다. 실무에서는 팀이 단순히 "스칼라를 얻는" 것이 아니라 온보딩, 빌드, 코드 리뷰에서 드러나는 일상적 트레이드오프를 체감합니다.
스칼라는 많은 표현력을 제공합니다: 데이터를 모델링하는 여러 방법, 행동을 추상화하는 여러 방법, API 구조화의 여러 방식. 일단 공동의 마인드셋을 공유하면 생산적이지만—초기에는 팀을 느리게 만들 수 있습니다.
신입은 문법보다 선택에 더 어려움을 겪을 수 있습니다: "이걸 case class로 할까, 일반 클래스나 ADT로 할까?" "상속, 트레잇, 타입클래스, 아니면 그냥 함수인가?" 어려운 부분은 스칼라가 불가능해서가 아니라, 팀이 '정상적인 스칼라'가 무엇인지 합의하는 것입니다.
스칼라 컴파일은 프로젝트가 커지거나 매크로 중심 라이브러리에 의존할수록 더 무거운 경향이 있습니다(Scala 2에서 더 흔함). 증분 빌드는 도움이 되지만 컴파일 시간은 여전히 반복되는 실무 문제입니다: 느린 CI, 느린 피드백 루프, 모듈을 작게 유지하고 의존성을 정리해야 한다는 압박.
빌드 도구도 추가 고려사항입니다. sbt를 쓰든 다른 빌드 시스템을 쓰든 캐싱, 병렬성, 모듈 분할 방식을 신경 써야 합니다. 이들은 학술적 문제가 아니라 개발자 행복과 버그 수정 속도에 영향합니다.
스칼라 도구는 많이 개선되었지만, 정확한 스택으로 테스트해 보는 것이 여전히 중요합니다. 표준화하기 전에 팀은 다음을 평가해야 합니다:\n
IDE가 버거워하면 언어의 표현력이 독이 됩니다: "정확한" 코드이지만 탐색하기 어려운 코드는 유지비용이 높아집니다.
스칼라는 함수형과 객체지향(그리고 많은 하이브리드)을 지원하기 때문에 코드베이스가 여러 언어처럼 느껴질 수 있습니다. 보통 불만은 스칼라 자체 때문이 아니라 일관성 없는 관습에서 시작됩니다.
규약과 린터는 논쟁을 줄여줍니다. 미리 팀이 "좋은 스칼라"가 무엇인지 결정하세요—불변성 처리 방식, 오류 처리, 네이밍, 언제 고급 타입 레벨 패턴을 사용할지 등. 일관성은 온보딩을 부드럽게 하고 코드 리뷰를 행동에 집중하게 합니다.
Scala 3(개발 중에는 "Dotty")는 스칼라의 정체성을 재작성한 것이 아니라—스칼라 2에서 팀들이 마주했던 날카로운 모서리를 부드럽게 하려는 시도입니다.
Scala 3는 익숙한 기본을 유지하면서 코드가 더 명확한 구조로 나아가도록 유도합니다.
중괄호 대신 중요 들여쓰기를 선택적으로 허용해 일상 코드를 현대 언어처럼 읽히게 합니다. 또한 Scala 2에서 "가능하지만 지저분했던" 몇몇 패턴을 표준화합니다—예를 들어 extension으로 메서드를 추가하는 방식이 implicit 트릭 모음보다 깔끔합니다.
철학적으로 Scala 3는 강력한 기능을 더 명시적으로 만들어 독자가 무엇이 일어나는지 암기 없이 파악할 수 있게 합니다.
Scala 2의 implicit는 매우 유연했지만 타입 에러를 혼란스럽게 만들고 "거리에서 작동하는 행동"을 초래할 수 있었습니다.
Scala 3는 대부분의 implicit 사용을 given/using으로 대체합니다. 기능은 유사하지만 의도가 더 분명합니다: "여기에 제공되는 인스턴스가 있다"(given)와 "이 메서드는 그것을 필요로 한다"(using). 이는 가독성을 높이고 FP 스타일 타입클래스 패턴을 더 따라가기 쉽게 만듭니다.
Enums 또한 큰 변화입니다. 많은 Scala 2 팀은 ADT를 모델링하기 위해 sealed trait + case object/class를 사용했습니다. Scala 3의 enum은 동일한 패턴을 전용 문법으로 제공해 보일러플레이트를 줄이면서 동일한 모델링 파워를 제공합니다.
많은 실무 프로젝트는 크로스 빌딩(Scala 2 및 Scala 3 아티팩트 게시)으로 모듈 단위 전환을 합니다.
도구가 도움이 되지만 여전히 작업입니다: 암시적 관련 소스 불호환, 매크로 중심 라이브러리, 빌드 도구 문제 등이 속도를 늦출 수 있습니다. 좋은 소식은 전형적인 비즈니스 코드는 컴파일러 매직에 크게 의존하지 않는 한 더 깨끗하게 포팅된다는 점입니다.
일상 코드에서 Scala 3는 FP 패턴을 더 "일등 시민"처럼 느끼게 합니다: 타입클래스 연결이 더 명확하고, enum으로 깔끔한 ADT, 유니온/교차 타입 같은 더 강력한 타입 도구를 의례적이지 않게 제공합니다.
동시에 OO를 버리지는 않습니다—트레잇, 클래스, 믹스인 조합은 여전히 중심입니다. 차이는 Scala 3가 "OO 구조"와 "FP 추상화" 사이 경계를 더 명확히 보여줘 팀이 코드베이스 일관성을 유지하기 더 쉽게 한다는 점입니다.
스칼라는 JVM 위의 강력한 도구가 될 수 있지만 범용 디폴트는 아닙니다. 가장 큰 이득은 더 강한 모델링과 안전한 조합이 유리한 문제에 나타나고, 팀이 언어를 의도적으로 사용하려 할 때 드러납니다.
데이터 중심 시스템과 파이프라인. 많은 데이터 변환, 검증, 보강(스트림, ETL, 이벤트 처리)을 한다면 스칼라의 함수형 스타일과 강한 타입이 변환을 명시적이고 오류에 덜 취약하게 만듭니다.
복잡한 도메인 모델링. 비즈니스 규칙이 미묘한 경우(가격, 리스크, 적격성, 권한 등) 스칼라의 타입으로 제약을 표현하고 작고 조합 가능한 부품을 만들 수 있는 능력은 if-else 스프로일을 줄이고 잘못된 상태를 표현하기 어렵게 합니다.
JVM에 이미 투자한 조직. 자바 라이브러리, JVM 도구, 운영 관행에 이미 의존하고 있다면 스칼라는 그 생태계를 떠나지 않고 FP 스타일의 편의성을 제공할 수 있습니다.
스칼라는 일관성을 보상합니다. 성공한 팀은 보통 다음을 갖추고 있습니다:\n
이런 것들이 없으면 코드베이스는 따라가기 어려운 스타일 혼합으로 흘러갑니다.
빠른 온보딩이 필요한 작은 팀. 빈번한 인수인계, 많은 주니어 기여자, 빠른 인력 변동이 예상된다면 학습 곡선과 다양한 관용구가 오히려 속도를 늦출 수 있습니다.
단순한 CRUD 전용 앱. 요청-응답과 기록만 하는 단순 서비스라면 스칼라의 이점이 빌드 도구, 컴파일 시간, 스타일 결정의 비용을 상쇄하지 못할 수 있습니다.
물어보세요:\n
대부분에 "예"라면 스칼라는 강한 적합일 가능성이 큽니다. 그렇지 않다면 더 단순한 JVM 언어가 더 빠른 결과를 줄 수 있습니다.
평가 팁: 프로토타입 루프를 짧게 유지하세요. 예를 들어 팀들은 Koder.ai 같은 비브-코딩 플랫폼을 이용해 작은 참조 앱(API + DB + UI)을 채팅 기반 사양에서 빠르게 생성하고, 계획 모드에서 반복하며 스냅샷/롤백으로 대안을 탐색합니다. 프로덕션 목표가 스칼라라 하더라도, 내보낼 수 있는 빠른 프로토타입으로 JVM 구현과 비교하면 "스칼라를 선택해야 하는가" 논의를 워크플로, 배포, 유지보수 측면에서 더 구체적으로 할 수 있습니다.
스칼라는 보일러플레이트, null 관련 버그, 깨지기 쉬운 상속 중심 설계 같은 JVM의 일반적 문제를 줄이면서 JVM의 성능, 도구, 라이브러리 접근성을 유지하도록 설계되었습니다. 목표는 자바 생태계를 떠나지 않고 도메인 로직을 더 직접적으로 표현할 수 있게 하는 것이었습니다.
모듈 경계(API, 캡슐화, 서비스 인터페이스)는 OO로 분명히 정의하고, 그 경계 내부에서는 불변성, 표현식 지향 코드, 순수 함수에 가까운 함수형 기법을 사용해 숨겨진 상태를 줄이고 동작을 테스트하고 변경하기 쉽게 만듭니다.
기본적으로 val을 사용해 재할당을 피하고 숨겨진 상태를 줄이는 것을 권장합니다. var는 성능이 중요한 루프나 UI 연결 코드처럼 국소적인 경우에 의도적으로 사용하세요. 핵심 비즈니스 로직에서는 가능한 한 변이를 피하는 것이 좋습니다.
트레잇은 여러 클래스에 재사용 가능한 “능력”을 제공할 때 유용합니다.
sealed trait와 case class/case object로 닫힌 상태 집합을 모델링하고 match로 각 경우를 처리하세요.
이 방식은 잘못된 상태를 표현하기 어렵게 만들어 많은 오류가 컴파일 단계에서 드러나도록 합니다.
타입 추론은 반복적인 타입 선언을 줄여 코드를 간결하게 해주지만, 경계(공개 메서드, 모듈 API, 복잡한 제네릭)에서는 명시적 타입을 추가하는 것이 가독성과 컴파일 오류의 안정성에 도움이 됩니다. 로컬 변수마다 타입을 적을 필요는 없습니다.
분리된 타입에 대해 제네릭을 설계할 때 하위 타입 관계가 어떻게 전달되는지를 설명합니다.
+A): 컨테이너가 넓혀질 수 있음(예: List[Cat]을 로 볼 수 있음).타입클래스 스타일 설계의 메커니즘으로, 원래 타입을 수정하지 않고 외부에서 동작을 제공할 수 있게 합니다.
implicitgiven / usingScala 3는 제공되는 것과 요구되는 것을 더 명확히 표현해 가독성을 개선합니다.
간단한 규칙: 필요한 수준에 따라 확장하세요.
어떤 경우든 불변 데이터를 전달하면 경쟁 상태를 줄이는 데 도움이 됩니다.
Java/Scala 경계를 번역 계층으로 취급하세요:
null은 즉시 Option으로 감싸고(변환은 에지에서만 되돌리기),공개 API는 Java 사용자를 위해 간단하게 유지하고, 내부 Scala 모듈은 스칼라식 API를 유지하는 것이 좋습니다.
List[Animal]-A): 소비자/핸들러가 넓혀질 수 있음(예: Handler[Animal]을 Handler[Cat] 대신 사용할 수 있음).라이브러리나 API 설계에서 특히 체감하게 됩니다.