Java 10에서 도입된 var 키워드는 로컬 변수의 타입을 컴파일러가 자동으로 추론하도록 도와주는 문법이다. 명시적인 타입 선언을 제거함으로써 코드의 장황함을 줄이고, 개발자가 비즈니스 로직에 더 집중할 수 있도록 설계되었다. 하지만 모든 편의 기능이 그렇듯, 장점과 단점은 명확하며 무분별한 사용은 오히려 가독성을 해칠 수 있다.
var 키워드와 타입 추론의 역할
var 키워드의 핵심은 타입 추론이다. 개발자가 타입을 직접 작성하지 않아도 컴파일러가 초기화 표현식을 기준으로 정확한 타입을 결정한다. 이는 특히 제네릭 타입이나 중첩된 자료구조를 다룰 때 큰 이점을 제공한다.
예를 들어 Map, List, 제네릭이 중첩된 구조를 변수로 받을 때, 기존 Java 문법에서는 타입 선언 자체가 코드의 대부분을 차지하는 경우가 많았다. 이런 상황에서 var를 사용하면 코드의 관심사를 데이터 구조가 아닌 “무엇을 계산하는가”에 집중하도록 도와준다.
Service 계층이나 Facade 패턴에서 var 키워드는 특히 효과적이다. 메서드의 책임이 명확하다면, 반환 타입이 무엇인지보다 그 결과로 어떤 판단을 하는지가 더 중요해진다. 이때 타입 선언은 오히려 독해를 방해하는 요소가 될 수 있다.
또한 체이닝 메서드, 스트림 API, DSL 스타일 코드에서는 var 키워드가 자연어에 가까운 흐름을 만들어준다. 이는 함수형 스타일이 확산되는 최근 Java 코드 트렌드와도 잘 맞는다.
var 키워드 컴파일 타임 타입 결정
많이 오해되는 부분 중 하나는 var 키워드가 런타임에 타입이 결정된다는 생각이다. 하지만 var는 철저히 컴파일 타임에 타입이 확정된다.
컴파일러는 변수의 초기화 식을 분석하여 정확한 타입을 추론하고, 바이트 코드에는 해당 타입의 FQN(Fully Qualified Name)이 그대로 기록된다. 즉 var는 문법적 편의일 뿐, 동적 타입 언어처럼 동작하지 않는다.
import 구문이 사라지는 것처럼 보이지만, 실제로는 컴파일러가 참조 타입을 모두 파악하여 바이트 코드에 명확하게 기록한다. 디컴파일 시 import가 다시 나타나는 이유도 사람이 읽기 쉽게 복원해 주기 때문이다.
이러한 특성 덕분에 메서드의 반환 타입이 변경되더라도, 호출부에서 var를 사용하고 있다면 수정 범위를 최소화할 수 있다. 리턴 타입과 매개변수 타입이 일관성만 유지된다면, 클라이언트 코드는 영향을 받지 않는다.
즉 var 키워드는 타입 안정성을 해치지 않으면서 변경에 유연한 코드를 작성할 수 있도록 돕는다.
var 키워드 사용 주의점과 한계
var 키워드는 모든 상황에서 좋은 선택은 아니다. 가장 대표적인 주의점은 타입 가시성 저하다. 초기화 표현식이 복잡하거나 메서드 이름이 모호하다면, 해당 변수의 타입을 추론하기 위해 정의부를 다시 찾아가야 하는 비용이 발생한다.
특히 삼항 연산자와 함께 사용할 경우 주의가 필요하다. 서로 관련 없는 타입을 반환하는 경우, 컴파일러는 공통 상위 타입인 Object로 추론한다. 이로 인해 오버로딩된 메서드 호출이 컴파일 단계에서 실패할 수 있다.
또한 var는 로컬 변수에만 사용할 수 있다. 필드, 메서드 파라미터, 반환 타입에는 사용할 수 없으며, 이는 API의 명시성을 유지하기 위한 Java의 의도적인 설계다.
실무에서는 조직의 컨벤션이 무엇보다 중요하다. 모든 변수를 var로 통일하는 것도, 아예 금지하는 것도 극단적인 선택이다. 타입이 명확하고 관심사가 타입 자체가 아닐 때만 선별적으로 사용하는 것이 가장 이상적이다.
var 키워드는 코드를 짧게 만드는 도구가 아니라, 읽기 좋은 코드를 만들기 위한 선택지라는 점을 항상 염두에 두어야 한다.
마무리 정리
var 키워드는 Java가 더 표현력 있는 언어로 진화하고 있다는 신호다. 타입 안정성을 유지하면서도 개발자의 사고 흐름을 방해하지 않는 방향으로 문법이 개선되고 있다.
중요한 것은 문법이 아니라 의도다. 어디에 var를 쓰는지가 아니라, 왜 쓰는지를 설명할 수 있어야 한다. 그럴 때 var 키워드는 가독성과 유지보수성을 동시에 높여주는 강력한 도구가 된다.