MacOS JDK 설치 및 인텔리제이 세팅하기(feat 빌드 프로세스)

설치한 JDK의 아키텍처와 시스템 아키텍처간의 불일치 문제

개발을 하다보면 설치해야 하는 툴이 많습니다.

여태까진 수동적으로 남들이 제공하거나 설치하라는 툴을 설치하곤 했는데 막상 아래와 같은 문제가 생겼을 때 어떻게 해결해야 할지 백지가 되는 저를 보며 문제의식을 느꼈고 이번 기회에 현재 저의 노트북은 어떤 사양이며 제 사양에 맞는 JDK를 설치하고 기존 프로젝트의 구조를 설치한 JDK로 변경하는 과정을 공유드리고자 합니다.

우선 인텔리제이가 알림으로 제공하는 경고 메시지를 분석해보면 프로젝트의 SDK로 선택한 JDK Eclipse Temurin 17.0.14 버전의 x86.64버전의 아키텍처가 현재 저의 노트북의 아키텍처와 맞지 않아 경고를 하는 것으로 보입니다.

해당 문제를 해결하려면 우선 제 노트북의 사양을 확인할 필요가 있을 것 같습니다.

내 노트북 사양 확인하기

저는 현재 맥북 M2 Pro를 사용하고 있는데 해당 내용은

•  애플 로고 클릭 → "이 Mac에 관하여"

에서 빠르게 확인할 수 있습니다.

여기서 Apple M1/M2/M3의 경우 Apple Sillicon 프로세서 기반이고 2019년 이전 맥북 모델의 경우 Intel 프로세서 기반이라고 생각하시면 됩니다.

• Apple Sillicon 프로세서의 경우 CPU 아키텍처가 ARM64이고
• 인텔 프로세서의 경우 x86_64를 사용합니다.

더욱 자세한 상세 아키텍처를 확인하기 위해선 명령줄에서 명령어를 통해 확인해야 합니다.
다음 명령어를 실행하여 맥북의 하드웨어 및 아키텍처 정보를 더욱 상세히 확인할 수 있습니다.

프로세서 아키텍처 확인 명령어

uname -m 

위의 명령어를 실행해보면 저의 경우 arm64를 출력합니다.

아키텍처 정리 및 비교

1) AArch64 (ARM64) vs ARM (AArch32)

제 노트북의 아키텍처인 AArch64 (ARM64)는 ARM의 64비트 아키텍처입니다. 주로 최신 스마트폰, 서버, Apple Silicon (M1, M2, M3)에서 사용되는 아키텍처라고 합니다.
64비트 CPU 연산을 지원하고 전력 효율을 유지하면서 성능을 높이는 구조를 가집니다.

ARM (AArch32)는 ARM(Advanced RISC Machine)에서 개발한 32비트 아키텍처라고 합니다. 주로 스마트폰, 태블릿, 임베디드 시스템에서 사용하고 저전력 및 고효율이라는 모바일 기기에 특화된 특성을 가진다고 합니다.

툴 설치할 때 AArch64랑 ARM 아키텍처 버전을 모두 제공하는 경우가 많은데 ARM만 확인하고 AArch64 아키텍처 버전으로 설치해야 되는데 다른 아키텍처 버전으로 설치하거나 반대의 상황을 꼭 주의하시길 바랍니다!!(제가 바로 그런 사람입니다...ㅎ)

2) x86 vs x86_64

x86은 1980년대부터 사용된 인텔 기반 32비트 아키텍처입니다. 구형 PC, 일부 임베디드 시스템에서 사용되고 현재는 거의 사용되지 않는다고 합니다.

x86_64 (AMD64)는 인텔과 AMD에서 만든 64비트 아키텍처입니다. 현재 Windows, Linux, Mac(Intel) 대부분이 사용하는 아키텍처로서 대부분의 데스크탑, 서버, 고성능 컴퓨팅에서 사용되고 있고 인텔 기반의 아키텍처이기 때문에 Apple Sillocon 프로세서를 사용하고 있는 맥북의 경우 해당 프로세서를 사용하는 것을 지양할 필요가 있습니다.

사양에 맞는 아키텍처를 사용해야 하는 이유

아키텍처가 다른 소프트웨어를 실행해도 정상적으로 동작은 됩니다. 그 이유는 Apple Silicon의 경우 Rosetta 2라는 변환 레이어를 사용하여 x86_64 프로그램을 실행하기 때문입니다.

즉, 아키텍처가 다르더라도 실행은 되지만 문제는 성능 저하가 발생할 가능성이 높습니다. 즉 인텔리제이가 저에게 경고했던 내용과 일치하는 부분이라고 할 수 있습니다.

조금만 생각해보면 당연하게도

• x86_64 명령어를 ARM64 명령어로 변환하는 과정이 추가적으로 발생하여 실행 속도가 느려지고,
• CPU 사용률이 증가하여 성능이 떨어질 수밖에 없을 것 같습니다.
• 그리고 변환 과정에서 캐시와 메모리를 더 많이 사용할수밖에 없고
• 최적화가 어려워 가능하다면 아키텍처를 맞춰주는 것이 필요해보입니다.

JDK 버전 확인 및 변경

이제 저의 노트북 아키텍처도 파악했고 왜 사양에 맞는 아키텍처를 지원하는 툴을 설치해야 하는지 알게되었으니 현재 제가 설치한 JDK 버전을 확인하고 x86_64 (AMD64) 버전의 아키텍처를 설치해서 변환하는 과정을 진행해보고자 합니다.

현재 설치된 JDK 확인 명령어

/usr/libexec/java_home -V

위의 명령어를 실행하면 현재 macOS에 설치된 JDK 목록과 버전을 확인할 수 있습니다. 이때 아래의 명령어 출력 내용과 같이 해당 JDK의 아키텍처도 함께 확인할 수 있습니다.

명령어 출력

Matching Java Virtual Machines (2):
    23.0.1 (arm64) "Oracle Corporation" - "Java SE 23.0.1" /Library/Java/JavaVirtualMachines/jdk-23.jdk/Contents/Home
    17.0.14 (x86_64) "Eclipse Adoptium" - "OpenJDK 17.0.14" /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/jdk-23.jdk/Contents/Home

/usr/libexec/java_home 명령어는 macOS의 디폴트 JDK 경로인 /Library/Java/JavaVirtualMachines/만 조회하므로 만약 JDK를 임의의 경로에 설치하셨다면 java_home 명령어로는 JDK를 찾을 수 없으므로 JDK 경로를 직접 확인후 JAVA_HOME을 직접 설정해줘야 합니다.

저는 현재 OpenJDK LTS 17.0.14 버전 JDK를 주로 사용하고 있는데 해당 버전의 아키텍처가 x86_64임을 확인할 수 있습니다.

LTS(Long-Term Support)란?

• LTS 버전은 장기적으로 안정적인 지원을 제공하는 버전입니다.
• 최신 Java는 6개월마다 릴리스되지만, LTS 버전은 3년 이상 지원한다는 장점이 있습니다.
• 기업 및 대규모 프로젝트에서는 주로 LTS 버전을 사용한다고 합니다.

LTS 버전으로 JDK 8, JDK 11, JDK 17, JDK 21이 있는데 저는 가장 최신은 아니지만 최신 기능을 지원하면서 보안 패치를 지속적으로 제공하며 Gradle, Spring Boot등의 주요 프레임워크가 해당 버전을 권장함에 따라 해당 버전을 사용하고 있습니다.

문제는 아키텍처를 잘못 선택하여 빌드 성능상 문제가 있는 것이기 때문에 따라서 다시 AArch64 (ARM64)으로 설치하고자 합니다.

저는 Adoptium 프로젝트에서 제공하는 무료 OpenJDK 배포판을 사용하려고 하는데요, 그 이유는 Oracle JDK의 대체재로 기업 환경에서도 많이 사용된다고 해서 연습차 해당 JDK를 사용해서 앞으로의 실습과 프로젝트를 진행해보고자 하기 위함입니다.

[Open JDK 설치 경로]
https://adoptium.net/download/

위의 경로에서 운영체제, 아키텍처, 버전을 자신의 하드웨어 사양과 상화에 따라 선택해서 설치하면 됩니다. .

.pkg 파일과 .tar.gz 파일의 차이점

참고로 패키지 설치(.pkg) 방법과 압축 파일(.tar.gz) 설치 방법이 있는데

• macOS 패키지 관리 시스템을 통해 자동으로 JDK를 정해진 위치에 설치하고 싶다면 pkg 파일로 설치해서 실행시키면 되고
• 설치 프로그램 없이 수동으로 JDK를 원하는 위치에 설치하고 싶다면 .tar.gz 파일을 설치한뒤 압축 해제 후 원하는 위치에 jdk를 이동시킨 후 환경 변수를 직접 설정하면 됩니다.

JDK 변경 과정

저는 AArch64 (ARM64) 아키텍처를 지원하는 LTS 17 버전 openJDK를 .pkg 파일로 설치하여 실행하였습니다.

새로 설치한 JDK가 잘 설치되었는지 확인해보려면 /Library/Java/JavaVirtualMachines 디렉토리를 확인해 보면 됩니다. 위에서 설명했던 내용과 같이 Homebrew가 아닌 웹 브라우저로 설치할 시 해당 경로에 자동으로 JDK가 설치되기 때문입니다.

현재 설치된 JDK 목록 확인

ls -l /Library/Java/JavaVirtualMachines/

출력 결과

drwxr-xr-x⠀System Administrator⠀wheel⠀96⠀Jan 10 10:38:35⠀⠀jdk-23.jdk/
drwxr-xr-x⠀System Administrator⠀wheel⠀96⠀Jan 22 08:27:03⠀⠀temurin-17.jdk/

출력 결과를 보면 17 버전의 JDK가 설치되어 있는 것을 확인할 수 있는데 제 예상으론 이전에 이미 17 버전의 JDK를 설치했었으므로 AArch64 (ARM64) 아키텍처를 지원하는 JDK가 추가적으로 설치 될 것으로 예상했던과 다르게 한개의 17버전 JDK만 남아있어 설치가 정상적으로 안되었나라는 생각이 먼저 들었습니다.

그래서 JDK 아키텍처를 확인하기 위해 다음 명령어를 추가적으로 실행해봤습니다.

JDK 목록 및 아키텍처 확인

/usr/libexec/java_home -V

출력 결과

Matching Java Virtual Machines (2):
    23.0.1 (arm64) "Oracle Corporation" - "Java SE 23.0.1" /Library/Java/JavaVirtualMachines/jdk-23.jdk/Contents/Home
    17.0.14 (arm64) "Eclipse Adoptium" - "OpenJDK 17.0.14" /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/jdk-23.jdk/Contents/Home

출력 결과를 보면 놀랍게도 기존 x86_64에서 arm64로 아키텍처가 변경되어 있는 것을 확인할 수 있습니다.
즉 새로 설치한 JDK는 정상적으로 설치된 것이고 기존 x86_64 JDK가 삭제된 것입니다.

왜 이렇게 된건지는 추후에 알아보는 것으로 하고 우선 새로 설치한 JDK로 프로젝트 구조를 변경하는 작업을 진행하고자 하는데 생각해보면 새로운 버전의 JDK가 아니라 아키텍처만 다른 JDK를 설치한 것이므로 개별적으로 변경해야할 것이 없습니다.

그 이유는 위와 같이 인텔리제이 프로젝트 설정에서 확인할 수 있습니다.
IntelliJ를 열고, 상단 메뉴에서 File → Project Structure (⌘ + ;) 클릭하면 인텔리제어 프로젝트 구조로 들어올 수 있는데 Project 섹션에서 Project SDK를 확인하고 변경할 수 있습니다.

이때 기본 경로가 바로 위에서 계속 확인했던/Library/Java/JavaVirtualMachines/입니다. 이미 위에서 해당 경로에 설치된 JDK는 한 개의 17버전의 JDK임을 확인할 수 있었고 따라서 경로 기반으로 JDK를 인지하는 인텔리제이는 새로 생성한 JDK를 프로젝트의 JDK로 자동으로 인지하게 되는 것입니다.

아키텍처 변경 이후의 달라진 점

우선 아키텍처를 변경하니 인텔리제이가 경고창을 띄우지 않는다는 것으로 아키텍처가 변경되었고 인텔리제이가 이를 인지하고 있음을 확인할 수 있고 자바 코드를 로컬에서 실행하는 과정에서 비교할 수 없을 정도로 빠르게 실행되는 것을 확인할 수 있습니다.

이는 위에서 언급했던 내용과 맞물려 생각해보면 Rosetta 2 없이 네이티브로 실행되는 과정에서 컴파일 속도와 실행 속도 모든 면에서 성능이 향상된것으로 추론 해 볼 수 있습니다.

참고로 IntelliJ IDEA를 사용하여 실행하는 것이 Gradle이나 Maven을 사용하여 실행하는 것보다 훨씬 빠르게 실행됩니다. 그 이유는 변경된 코드만 즉시 반영하여 수정된 코드만 컴파일하여 불필요한 작업을 줄여주기 때문입니다.

사실 Gradle도 Maven과 달리 변경된 부분만 다시 빌드하는 Incremental Build(증분 빌드) 기능을 제공합니다. 다만 Gradle이나 Maven을 사용할 경우 추가적인 프로세스를 시작해야 하는것과 비교하여 IntelliJ IDEA를 사용할 경우 자체적인 빌드 시스템(JPS, JetBrains Project System)을 백그라운드에서 실행하여 빠른 실행이 가능합니다.

그렇다면 왜 Gradle, 'Maven'과 같은 빌드 시스템을 사용해야 할까?

1. 수작업 없이 자동화된 빌드 가능
   Java 프로젝트에서는 단순히 컴파일과 실행만 하는 것이 아니라, 여러 추가적인 작업(패키징, 테스트, 의존성 관리, 배포 등)이 필요합니다. Gradle 같은 빌드 시스템이 없으면 매번 수동으로 javac, jar, java 등을 실행해야 합니다. Gradle은 이러한 과정(코드 컴파일 → 테스트 → 패키징 → 배포)을 자동으로 수행하는 기능을 제공합니다.

2. 의존성 관리
   Java 프로젝트에서는 외부 라이브러리(JAR 파일)를 자주 사용하는데, 이때 직접 다운로드해서 추가하는 것은 비효율적일 수 있습니다. Gradle은 Maven Central, JCenter 같은 저장소에서 자동으로 필요한 라이브러리를 다운로드하고 관리해주는 기능을 제공합니다.

3. 프로젝트 간 일관된 빌드 환경 제공
   팀에서 개발할 때 각 개발자가 동일한 빌드 환경을 유지하는 것이 중요한데 수동 빌드를 하면 각 개발자의 환경에 따라 빌드 과정이 달라질 수 있습니다. 그런데 Gradle을 사용하면 모든 개발자가 동일한 방식으로 빌드를 수행할 수 있습니다. 이를 통해 팀 내에서 일관된 빌드 환경을 제공하여 빌드 실패 가능성을 줄여줍니다.

4. 테스트 자동화 (JUnit, TestNG)
   소프트웨어를 개발할 때 테스트를 자동으로 실행하는 것이 매우 중요한데 Gradle은 JUnit, TestNG 같은 테스트 프레임워크를 자동으로 실행하고, 테스트 결과를 보고서로 제공하는 기능을 제공합니다.

따라서 로컬 개발에선 IntelliJ 실행을 통해 빠르게 작성한 코드 결과를 확인해서 개발을 진행하고 최종 배포나 전체 빌드가 필요할 땐 빌드 시스템을 필수적으로 사용해야 합니다.

Gradle과 Maven의 차이점

Maven의 장점

1. 높은 빌드 속도
   Maven과 비교하여 Gradle은 위에서 말했듯이 Incremental Build(증분 빌드)를 지원하여 변경된 코드만 다시 빌드하여 실행 속도가 빠르고 병렬 빌드(Parallel Build) 지원하여 여러 작업을 동시에 실행하여 속도를 빠르게 하기 때문에 여러 빌드 시스템중에서도 속도 측면에선 Gradle이 좋은 선택일 수 있습니다.

2. 최신 기술을 적용한 프로젝트
   Gradle은 Kotlin DSL (build.gradle.kts)을 사용할 수 있어 최신 Java/Kotlin 프로젝트에 적합합니다. Spring Boot, Micronaut, Android 프로젝트는 대부분 Gradle을 사용하고 Maven보다 커스텀 빌드가 더 쉽고 유연합니다.

3. 빌드 자동화 & CI/CD 파이프라인 최적화
   Gradle은 CI/CD 환경에서 빠른 빌드가 필요할 때 적합합니다. GitHub Actions, Jenkins, GitLab CI/CD와 쉽게 연동 가능하며 병렬 빌드 기능 덕분에 전체 빌드 시간이 짧다는 장점이 있습니다.
   

Maven의 장점

1. 안정성이 중요한 경우
   Maven은 라이프사이클이 고정되어 있어 빌드 결과가 항상 일정적인 반면에Gradle은 Task 기반으로 동작하기 때문에 설정에 따라 빌드 결과가 달라질 가능성이 있으므로 한 번 빈들한 결과가 동일해야 하는 안정성을 추구하는 기업 환경에선 Maven이 더 적합할 수 있습니다.

2. 보안 및 규제 준수
   기업에서는 소프트웨어 보안 및 규제 준수(Security & Compliance)가 중요합니다. Maven은 중앙 집중식 의존성 관리(dependencyManagement)를 제공하여 보안 취약점을 쉽게 통제 가능합니다. 반면 Gradle은 동적 버전(+ 버전 사용 가능)이 가능하여, 의도치 않게 보안 취약점이 포함될 가능성이 있습니다. 따라서 보안을 우선시하는 기업의 경우 Maven이 더 좋은 선택일 수 있습니다.

3. 오래된 기업 시스템과의 호환성
   대기업은 내부 표준화된 빌드 프로세스를 유지하는 것이 중요합니다. 이미 수년 동안 Maven 기반으로 프로젝트를 구축했기 때문에, 갑자기 Gradle로 변경하는 것은 기업 입장에서 리스크가 클 수 있습니다. 따라서 Gradle이 더 유연하고 빠르더라도, "기업 내부 규정" 때문에 Maven을 유지하는 경우가 많습니다.

따라서 현재 프로젝트의 상황과 목적에 따라 어떤 빌드 시스템을 사용할지 선택해야 하며 배포가 아닌 개발 테스트의 경우엔 인텔리제이로 실행하는 것이 빠르게 실행하고 결과를 파악하여 빠른 개발이 가능할 수 있습니다.