JEP 444, 485, 506, 519 에 대한 설명과 예제코드를 담았습니다.

이 글은 Google Gemini Pro Deep Research 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

서론: 소프트웨어 개발의 새로운 지평

2026년을 맞이하며 엔터프라이즈 소프트웨어 개발 생태계는 전례 없는 전환점을 맞이하고 있습니다. 인공지능(AI), 특히 대규모 언어 모델(LLM)이 단순한 코딩 보조 도구를 넘어 자율적으로 소프트웨어를 설계, 구현, 수정하는 ‘에이전트(Agent)‘로 진화함에 따라, 우리가 코드를 작성하는 방식과 시스템을 아키텍처링하는 원칙 자체가 근본적으로 재평가되고 있습니다. 과거 10년이 마이크로서비스와 클라우드 네이티브의 시대였다면, 향후 10년은 인간 개발자와 AI 에이전트가 공존하며 협업하는 ‘AI-Native’ 시대가 될 것입니다.

지금까지 Go의 철학, 문법, 에러 처리, 동시성을 살펴봤다. 이제 실제 프로젝트를 시작하는 데 필요한 것들을 다룬다. Maven/Gradle에서 Go Modules로, JUnit에서 testing 패키지로, Spring에서 Go 라이브러리 조합으로 전환하는 방법을 알아보자.

Go의 동시성 모델은 Java와 근본적으로 다르다. Thread, synchronized, ExecutorService에 익숙한 개발자라면 처음엔 낯설겠지만, Go의 방식이 얼마나 우아한지 금방 알게 될 것이다. “공유 메모리로 통신하지 말고, 통신으로 메모리를 공유하라"는 Go의 철학을 이해해보자.

Java 개발자가 Go를 배울 때 가장 큰 패러다임 전환이 필요한 부분이 에러 처리다. try-catch에 익숙한 우리에게 if err != nil의 반복은 처음엔 원시적으로 느껴진다. 하지만 이 방식에는 명확한 철학이 있다. 이번 편에서 그 철학을 이해하고, Go 방식의 에러 처리에 익숙해져 보자.

Part 1에서 Go의 철학과 언제 Go를 선택해야 하는지 살펴봤다. 이제 실제 코드 레벨에서 Java와 Go가 어떻게 다른지 1:1로 비교해보자. Java 문법에 익숙한 개발자가 Go 코드를 읽고 쓸 수 있도록 핵심 차이점을 정리한다.

Java를 수년간 써온 개발자가 Go를 처음 접하면 당혹스럽다. “왜 이렇게 만들었지?“라는 생각이 끊이지 않는다. 이 글에서는 Go의 설계 철학을 이해하고, Java에서 Go로의 전환이 언제 적절한지 판단할 수 있는 기준을 제시한다.

invokeAll 은 ExecutorService 의 메서드로, 여러 제출된 작업을 동시에 시작합니다. ExecutorService 는 스레드 풀에서 플랫폼 스레드를 사용하여 제출된 작업을 실행합니다. 이 비싸고 리소스 집약적인 플랫폼 스레드를 사용하는 대신, 가상 스레드를 사용하여 ExecutorService 에 제출된 작업을 실행할 수도 있습니다. 이 글에서는 invokeAll 메서드를 가상 스레드 (virtual threads), 구조화된 동시성 (structured concurrency) 및 플랫폼 스레드 (platform threads) 와 함께 구현하는 모든 방법을 다룰 것입니다.

면접 중에 한 면접관이 저에게 Java 스레드와 가상 스레드의 성능 차이에 대해 물었습니다. 저는 가상 스레드가 실제로는 JVM이 처리하는 경량 스레드이기 때문에 더 빠를 것이라고 답했지만, 둘 사이의 정확한 성능 차이가 궁금했습니다. 그래서 가상 스레드의 성능 향상을 확인하기 위해 간단한 벤치마크를 수행했습니다.

Java 23은 성능 및 개발자 생산성 향상 추세를 이어갑니다. 기본 타입을 지원하는 패턴 매칭을 개선하고, 더 안전한 메모리 관리를 위해 Scoped Values를 도입하며, 구조화된 API를 통해 동시성을 단순화합니다. Markdown 문서화는 개발자 경험을 개선하고, ZGC가 기본 컬렉터가 되어 더 나은 성능과 낮은 지연 시간을 보장합니다.