자바 30주년 - 기술을 바꾼 코드의 천재, 제임스 고슬링 인터뷰

• 제임스 고슬링은 자바의 창시자이자, 30년간 현대 컴퓨팅에 영향을 끼친 실용적 천재로 평가됨
• 가난한 환경에서 쓰레기 더미 속 부품으로 컴퓨터를 조립하며 프로그래밍을 배웠고, 이 자기주도적 학습은 이후 언어 설계 철학에도 반영
• Sun Microsystems에서 장난과 혁신이 공존했던 시절은 고슬링 특유의 창의성과 기술 문화 조성의 기반이 됨
• 최근 그는 생성형 AI 도구와 AI 붐에 대해 강한 회의감을 드러냈으며, 프로그래밍 교육의 중요성은 오히려 커졌다고 강조
• 자바의 생존 비결은 화려함이 아닌 안정성, 하위호환성, 개발자 생산성을 철저히 지향한 실용주의적 설계 철학 덕분이었음

---

Java at 30: The Genius Behind the Code That Changed Tech

• 자바는 5월 23일로 30주년을 맞이하는 범용 고수준 객체지향 언어로, 오늘날에도 다양한 규모의 시스템을 구동하는 핵심 기술임
• 자바가 존재할 수 있었던 근본에는 제임스 고슬링의 실용적 기술 감각과 창조적 직관력이 자리함
• 고슬링은 쓰레기통에서 부품을 모아 컴퓨터를 조립하던 캐나다 출신의 자립심 강한 십대에서 출발해 세계적 프로그래머로 성장함
• ‘한 번 작성하면 어디서나 실행된다’는 철학은 자바의 상징이며, 이는 곧 소프트웨어 개발 방식에 근본적 전환을 이끈 언어 철학으로 이어짐
• 고슬링은 커리어 내내 기술적 탁월성과 장난기, 그리고 뚜렷한 윤리 의식을 조화시키며 현대 컴퓨팅 문화 형성에 지속적 영향을 준 개발자상을 구현함

James Gosling: The Brilliant Mind Behind Java

• 제임스 고슬링은 단순한 ‘자바의 아버지’가 아니라, 복잡한 개념을 직관적으로 설명할 줄 아는 겸손한 천재임
• 자바를 만든 지 30년이 지난 지금, 그는 기술 여정을 되돌아보며 언어와 개발 문화의 진화 과정을 되짚는 시간을 가짐

The Path To Programming: Resourceful Beginnings

• 어린 시절 극도로 가난한 환경 속에서 고슬링은 쓰레기통에서 텔레비전을 주워 기술적 창의력을 키운 경험을 가짐
• 첫 컴퓨터는 전화국의 폐기 릴레이 랙으로 조립했으며, 이는 이른 시기부터 드러난 기계적 감각과 조립 능력을 상징함
• 캘거리 대학의 컴퓨터 센터를 방문하며 화면, 깜빡이는 불빛, 테이프 장치 등에 매료되어 프로그래밍에 대한 평생의 호기심이 시작됨
• 그는 펀치카드를 뒤져 비밀번호를 얻는 방식으로 독학했으며, 고등학생 시절 대학 물리학과에서 위성 데이터 분석 프로그램을 만들어 돈을 받으며 프로그래밍을 즐긴 경험을 축적함
• 그의 초기 프로그래밍 경험은 IBM 메인프레임의 PL/1, Fortran, PDP-8 어셈블리어, CDC 6400 코드에 걸쳐 있음. 특유의 절제된 어조로 "여름엔 COBOL 컴파일러를 개발하는 아르바이트를 했다"고 가볍게 언급했는데, 이는 많은 노련한 프로그래머들이 감당하기 어려워하는 작업이었음

Academia to Industry: Finding His Way

• 고슬링은 학계를 “대학원생을 값싼 인건비로 활용하는 연구소”라고 표현하며, 이론보다 실용을 중시하는 직설적 관점을 드러냄
• 카네기멜론 박사과정 중에도 스타트업에서 근무하며 현실적 경험을 쌓고, 이후 학위 과정을 마치는 산업과 학계를 병행한 유연한 진로 선택을 실현함
• 첫 직장은 IBM 리서치였지만, “자기 발을 쏘는 데 헌신적인 회사”라는 평가를 남기며 기업 운영과 기술 전략에 대한 냉철한 분석 태도를 유지함
• 이러한 초기 경험들은 이후 Sun Microsystems에서의 활동 방식에 영향을 준 현실 중심의 조직문화 이해 기반이 됨

The Sun Days: Innovation and Pranks

• Sun에서 가장 즐거웠던 기억으로 고슬링은 매년 진행된 대규모 만우절 장난 프로젝트를 꼽으며, 창의성과 유쾌함이 공존했던 조직문화를 회상함
• 대표적 장난 사례로는 연못 위 플랫폼에 페라리를 띄워놓는 작업이 있었고, 이는 공학적 문제 해결 능력과 팀워크를 활용한 유머 감각을 보여주는 사례였음
• CEO 사무실에 인공 잔디, 벙커, 워터 해저드를 갖춘 1홀 골프장을 조성한 장난은 기술과 놀이가 결합된 독창적 시도로 언급됨
• 고슬링은 Sun을 “기술적 탁월성과 장난기 어린 창의성이 동시에 허용되는 보기 드문 환경”으로 기억하며, 이는 그의 전반적 문제 해결 방식과 기술에 대한 태도 형성의 기반이 되었음

Java: Creating a Legacy That Changed Everything

• 자바 30년의 여정은 고슬링에게 있어 가장 대표적인 성취이자 기술 인생의 결정적 전환점임
• 거리에서 “자바 덕분에 커리어를 얻었다”는 인사를 받을 때마다 느끼는 개발자 생태계에 남긴 영향력에 대한 깊은 만족감이 언급됨
• 람다와 제네릭 같은 기능은 처음부터 넣고 싶었지만, “틀린 방식으로 넣지 않겠다”는 설계 철학에 따라 도입 시점을 조절함
• Oracle의 자바 관리에 대해서는 “기대보다는 잘했다”고 평가하며, 실제로는 커뮤니티의 지속적 참여와 기여가 핵심 역할을 했다는 점을 강조함
• 자바는 클라우드 환경에 최적화되며 발전해왔고, 멀티코어 지원, 메모리 처리, GC 개선 등에서 “정말 굉장한 수준”이라는 기술적 완성도에 도달함

Beyond Java: Ventures After Sun

• Sun이 Oracle에 인수된 이후 고슬링은 잠시 휴식을 취한 뒤 Google에 입사했으나, 6개월 만에 퇴사 후 Liquid Robotics로 이직함
• 그곳에서 자율 해양 로봇 제어 시스템을 개발했으며, 하와이에서 스노클링이 필요한 업무 환경 등 기술과 자연이 결합된 독특한 근무 조건을 경험함
• 북극과 남극의 해양 온도를 모니터링하는 프로젝트에 참여했으나, 환경 연구는 자금이 부족해 VC 기반 스타트업 구조와의 충돌을 겪음
• 국방 분야로의 전환 압박이 이어지자 윤리적 이유로 퇴사하고, AWS에서 Greengrass 프로젝트와 개발 도구 관련 작업에 참여하며 기술적 흥미와 윤리 기준을 함께 고려한 커리어 선택을 이어감

On Open Source and Industry Trends: Cutting Through the Hype

• 오픈소스는 단순한 협업 도구를 넘어서, 개발자 관계, 마케팅 전략, 바텀업 채택 모델로 작동하는 복합적 생태계로 설명됨
• 로우코드·노코드 트렌드에 대해서는 COBOL 시절부터 반복된 주장이라며, 복잡한 도메인에 적용 시 한계를 갖는 특화형 접근 방식으로 회의적인 입장을 표명함
• AI와 머신러닝은 기술보다 명칭이 문제라며, ‘고급 통계 기법’이란 표현이 본질에 더 부합한다는 용어 비판을 제기함
• AI는 도구일 뿐이며 자율적 존재로 오해되어선 안 되며, 인간 노동을 위협하기보단 보조하는 고차원적 도구로 봐야 한다는 입장을 밝힘

Developer Tools and Preferences: Embracing Progress

• 고슬링은 NetBeans IDE를 주요 개발 도구로 사용하며, Apache 라이선스 기반의 오픈소스와 활발한 커뮤니티에 대한 지지 입장을 보임
• 여전히 Vi나 70~80년대 도구에 집착하는 개발자들을 향해 기술 진보를 거부하는 태도에 대한 아쉬움을 드러냄
• Vi는 어디서나 실행 가능하다는 이유로 가끔 사용하지만, 본격적인 개발 환경에선 현대적 IDE 사용을 강력히 지지함

The JVM Vision: From Academic Concept to Global Standard

• 자바 가상머신(JVM)의 초기 개념은 고슬링의 대학원 시절에 구상된 아키텍처 중립적 배포 포맷 실험과 명령어 번역 기술 연구에서 출발함
• 이는 훗날 자바뿐 아니라 여러 언어가 다양한 하드웨어에서 실행될 수 있는 범용 실행 플랫폼 기술로 발전함
• ‘Write once, run anywhere’ 철학은 처음엔 박사 논문 주제로는 수학적 기반이 부족하다는 이유로 기각되었지만, 세계 소프트웨어 개발 환경을 뒤바꾼 실용 기술로 자리잡음

More Recent Work: Bridging IoT Gaps at AWS

• 고슬링은 AWS에서 IoT 애플리케이션 프레임워크인 Greengrass 개발에 참여하며 복잡한 문제를 우아하게 단순화하는 기술 접근 방식을 구현함
• OTA 업데이트, 원격 제어, 텔레메트리, 네트워크 신뢰성, 보안, 인증 관리 등 배포와 운영 사이의 반복적 보일러플레이트 작업을 추상화함
• 디바이스 측 코드가 오픈소스로 공개되어 RISC-V 같은 Amazon 비우선 플랫폼에 대한 커뮤니티 기반 포팅 기여를 유도함
• 이후 참여한 또 다른 개발 도구 프로젝트는 AI 붐에 휘말려 중단되며, 기술 진정성보다는 유행 중심의 혼란 속 문제점을 시사함

AI Skepticism

• 고슬링은 최근 인터뷰에서 AI 혁명에 대해 “대부분 사기”라는 표현을 사용하며, AI를 유독성 마케팅 용어로 규정하는 회의적 시각을 드러냄
• 수학적으로 인상적인 기술인 것은 인정하면서도, AI라는 이름이 실제 기술적 실체인 고급 통계 기법의 본질을 흐리는 문제를 지적함
• 벤처캐피털이 주도하는 AI 열풍은 “사기꾼과 과대광고꾼들의 집결지”라며, 실제 유용한 기술보다는 엑싯 중심의 단기 수익 추구 경향을 강하게 비판함
• 대부분의 AI 투자금은 결국 “블랙홀로 빨려 들어갈 것”이라며, 지속가능성 없는 유행 중심 자금 흐름에 대한 경고를 제시함

Is It a Vibe? AI Coding Tools: Impressive Demos, Limited Utility

• 생성형 AI 코드 도구는 초기 인상은 강렬하지만, 조금만 복잡해져도 실패하는 한계적 구조를 가짐
• 이 도구들은 기존 코드 샘플을 스크랩해 반복할 수 있을 뿐이며, 진짜로 흥미로운 문제는 항상 새롭기 때문에 복제 기반 도구와 맞지 않음
• 전문가용 개발 환경에서는 패턴화된 코드가 라이브러리로 수렴되므로, AI의 코드 생성은 현실 개발 요구와 구조적으로 충돌함
• 고슬링은 AI의 진짜 쓸모를 “아무도 쓰고 싶어하지 않는 문서화 작업을 대신하는 검색 도구”로 정의하며, API 사용법 설명에 특화된 보조 도구로서의 가치를 강조함

Java’s Evolution: Language Features and Runtime Improvements

• 최근 자바 언어의 변화 중 타입 추론과 배열 선언 방식 개선 등은 개발 편의성을 높인 유용한 기능 확장으로 평가됨
• 그러나 고슬링은 자바의 가장 인상적인 발전은 JVM 실행 환경과 표준 라이브러리의 품질 향상에 있다고 강조함
• 최신 JVM은 코드 품질, 스레드 성능, 가비지 컬렉션 측면에서 “놀라운 수준”에 도달한 실행 성능을 보여줌
• 메모리 관리와 성능 예측 가능성 측면에서 malloc 기반 C 언어보다 효율적이며, GC 일시 중단 시간을 수 밀리초로 줄이는 튜닝 가능성도 언급됨
• 지금의 JVM은 터무니없이 큰 메모리 공간도 안정적으로 처리할 수 있는 고성능 런타임 환경으로 평가됨

Programming Languages for Critical Infrastructure

• FAA 항공 관제 시스템을 어떤 언어로 재작성할 것인가에 대해 고슬링은 “망치를 고르며 집을 짓는 격”이라며 질문의 전제를 거부함
• 먼저 통신 시스템, 국제 규정, 비행 경로 및 충돌 회피 등 문제 도메인의 속성을 명확히 이해한 후 기술을 선택해야 한다는 점을 강조함
• 다만 신뢰성이 중요한 대규모 시스템에는 자바가 강력한 후보가 될 수 있다는 가능성도 부연함

The Future of Programming in an AI World

• AI가 발전하더라도 프로그래밍은 여전히 필수 기술이라는 점에서, 고슬링은 자녀가 있다면 무조건 코딩을 가르치겠다는 입장을 밝힘
• AI가 인간 개발자를 대체할 것이라는 빅테크 경영진들의 주장은 노동 강도를 높이기 위한 자기방어적 협박에 불과하다고 비판함
• 시스템을 제대로 이해하기 위해선 프로그래밍 역량이 필요하며, 기계가 대신하더라도 인간의 기술적 이해 기반은 지속돼야 한다는 주장을 전개함

Java’s Longevity Secret

• 자바가 30년 이상 살아남을 수 있었던 이유로 고슬링은 실제 문제 해결력, 사용자 존중, 하위호환성, 생산성 향상, 신뢰성 중심 철학을 제시함
• 언어의 유행보다 일관된 실용성을 강조해왔으며, 스타일보다 결과에 집중한 현실 중심 설계 철학이 엔터프라이즈 환경에서 특히 효과적이었음
• 소프트웨어는 “항상 제대로 작동해야 한다”는 관점에서, 자바는 정직하고 실용적인 엔지니어링 도구로 남아 있음

Oracle’s Stewardship: Better Than Expected

• 고슬링은 Sun Microsystems 인수 이후 Oracle의 자바 운영에 대해 “생각보다 훨씬 잘했다”며 예상을 뛰어넘은 성과에 놀라움을 표함
• 초기에는 과거 행보 때문에 '강탈과 약탈'을 우려했으나, 실제로는 자바 팀을 방해하지 않고 보호한 점에서 독립성과 기술 중심 운영에 긍정적 평가를 내림
• 재정 지원은 부족했다고 지적했지만, 기업 간섭 없이 기술팀의 자율성이 보장된 구조가 유지되었다는 점에 높은 점수를 부여함

Crab Lovers Unite!

• 고슬링은 함께 식사하고 싶은 사람과 일하고 싶다고 말해왔으며, 사람 중심의 협업 기준을 중시하는 태도를 보여줌
• 기자는 샌프란시스코의 게 요리 전문점 Thanh Long에서 우연히 고슬링과 마주쳤고, 기술계 거물이 평범한 일상 속에서 발견되는 순간을 기록함
• 이후 두 사람은 함께 게 요리를 먹으며 대화를 나누었고, 다음 만남을 같은 장소에서 하자는 약속을 통해 기술을 넘어선 인간적인 교류의 따뜻함을 전함

[3ae3ae]

자바가 개발자 생산성을 중시했다는 말은 동의하기 힘드네요
자바만큼 ide에 깊게 의존하게 발전한 언어가 또 있나요?

[ahwjdekf]

c++ > c# >= java

[GN⁺]

Hacker News 의견

• Java 성능이 최고 수준은 아니지만 C/C++에 이어 3위 수준으로 나쁘지 않다는 인식, Go보다도 빠르고 Python이나 Ruby보다는 10배 이상 앞서는 점에 만족함, Java 문법이 완벽하진 않지만 일관되고 예측 가능한 점이 장점, Idea나 Eclipse 같은 툴을 쓰면 생산성 걱정이 없는 환경, 메모리 관리 방식이 유닉스 철학과는 다르지만 이해하면 괜찮은 절충안임을 느낌, 이런 트레이드오프를 통해 얻는 게 속도와 메모리 안전성이면서 동시에 동적 호출과 hotswap 등의 이점까지 함께 얻는 실용성에 만족
  • Java용 IntelliJ 같은 툴이 타 언어 대비 독보적으로 뛰어난 환경임을 실감, Go 커뮤니티가 동시성 자료구조 컨테이너 개발에는 별로 열정적이지 않은 이유가 궁금, Java의 동시성 코딩은 훌륭한 컨테이너를 권장하는 문화라 부럽고 가끔 java.util.concurrent나 JCTools가 그리움
  • 대학을 막 졸업한 초기엔 Java가 만능이라고 여겼으나 사실 JVM과 Java App Server 툴링이 시대를 앞서 있었던 요소였음을 나중에 깨달음, 언어 자체는 2006~2007년 생산성이 향상되기 전엔 실망감을 줬음, 요즘 JVM에서 돌아가는 JRuby, Clojure, Scala, Groovy, Kotlin 등 다른 언어에 관심, 그 중 JRuby가 성숙한 생태계를 두 개 사용 가능해서 흥미로움, Project Loom으로 JVM에서 Ruby의 Fiber를 쓸 수 있게 된 것이 양쪽 모두에 득, Charles Nutter의 업적이 저평가됨
  • Java가 Go보다 빠르다고 하지만 실제론 Go가 더 빠르거나 2~10배 적은 메모리 사용하는 경우가 많기에 비슷한 수준, Go의 value type 덕분에 최적화가 쉬움, Go를 특별히 언급하는 점이 인상적이고, C#이 Java보다 빠른 점을 들어 Java는 3위가 아니라 5위쯤이라고 판단
  • 최근 Java에 도입된 sealed class, switch expression, project Loom, records가 기존 문법에 자연스럽게 녹아든 점을 높이 평가, heap dump 분석기와 GC 분석기 등 Java의 진단 도구도 최고 수준임을 느낌
  • 언어 성능 순위는 무엇을 포함시키고 비교하느냐에 따라 달라지는 점을 지적, 제공한 벤치마크 링크를 참고
• Java(JVM)는 한동안 좋다고 소문난 다른 언어/생태계를 써 본 후 오히려 더 높이 평가하게 된 경험, 실제론 “남의 떡이 더 커 보이는 착각”이라는 느낌이 반복, Rust만은 정말 많이 진보된 언어라고 느껴졌고 쓰는 즐거움이 있었음, 요즘 Java가 스타트업에서 ‘쿨’한 언어로 취급받지 못하는 점이 안타깝고, 생산성 격차도 거의 사라졌다고 생각
  • Rust를 두 달간 풀타임으로 써 봤는데, 적어도 서버 개발에선 Java랑 비교해서 ‘기쁨’이 있다는 표현이 이해 안됨, Rust는 lifetime 문제에 깜짝 놀라며 생산성에 저하가 생기는 순간이 너무 많고, 타입 안전성 느낌은 확실히 있지만 전체적으로 정말 즐거운 경험이라고 하긴 어려움
  • C#이 Java보다 훨씬 앞서 있고, 의미 있는 방식들(예: 훨씬 낫게 구현된 제네릭, 오래전부터 존재한 value type, 편리한 FFI)로 차별점이 큼, Unity 외엔 사람들이 별로 신경 안 쓰고, Microsoft가 옛날에 대중적 인지도 확보에 실패했다고 봄
  • 이 느낌은 프로젝트 규모가 다르기 때문이라고 생각, 보통 10년짜리 Java 레거시 대형 프로젝트에서 “새로운” hello-world 수준 프로젝트로 넘어가면 당연히 좋아 보임, 대규모 리라이트(rewrite)는 보안 검토에도 좋지만 보통 기업은 그럴 여유가 없고 Google 같은 예외만 있음
  • 똑같이 느낌, Go는 실망스러웠음, 모든 걸 약속하면서 결과적으로 Java와 비슷하거나 오히려 스택트레이스 없는 에러 등으로 더 퇴보한 느낌
  • 거의 30년 경력 중반에 JVM 아닌 언어로 프로젝트를 시도한 2년이 경력 중 최악의 시기였음
• James Gosling의 업적에 감사함, Java World Tour를 계기로 ‘Java consultant’ 검색 1순위로 떠서 원격 근무로 시골에서 안정적으로 생계 유지한 경험, Java 덕분에 삶에 긍정적 영향을 받은 수많은 사람들 존재, Clojure 팀의 JVM 기반 훌륭한 생태계 개발 업적에도 감탄
  • 자신도 James Gosling에게 감사, 1995년 Taligent에서 C++로 일하다가 Java를 처음 써보고 새로움에 감탄, 이후 Taligent가 해체된 뒤로 Java와 관련 소프트웨어에 길게 몸담음
  • James Gosling(Java)과 Rich Hickey(Clojure)는 각각의 시대에 프로그래밍 세계에 신선함을 불어넣은 창조자라 평가
• 최근 몇 년간 .NET/C#에서 일했지만 전체적으로 JVM/Java가 경험해본 생태계 중 최고라는 느낌, Java가 해결을 잘한 부분이 훨씬 많음, 예를 들어 Java는 fork/join pool로 작업 분할을 해결했는데 .NET은 그냥 글로벌 쓰레드 풀에 work-stealing 넣으면서 sync-over-async 코드가 전체 deadlock을 쉽게 일으키는 문제가 있음, 대형 코드베이스에서 sync 코드를 async로 전면 변환하라는 건 사실상 불가능, Java 쪽은 라이브러리/프레임워크 수준에서 실수해도 빨리 극복하는 반면, .NET은 표준 라이브러리나 언어, 런타임에서 문제가 생기면 고치기 힘듦, Java가 기준을 잘 잡은 사례가 많음
  • .NET의 thread pool starvation은 매우 짜증나며, 최근엔 영향이 줄어들었다고 들음, thread pool 오용에 면역일 수 있는 구현은 불가능하다고 생각, 할 수 있는 건 쓰레드 늘리거나 작업 순서 스마트하게 조정하기, 자신은 thread pool 전문가가 아니라서 확실하진 않음
  • .NET은 Java 생태계의 성공적인 접근 방식을 모방해온 줄 알았는데, 실상은 다른 점이 많다는 사실에 주목
  • .NET 코드를 전혀 안쓰면서 deadlock 문제를 언급하는 건 공정하지 않으며, 13년 전 블로그를 근거로 삼는 것도 설득력 없다는 지적
• Java는 위대한 성공 사례라는 인식, 하지만 James Gosling은 시작점이었지 실질적 리더는 아님, Java 1.1~1.2 시절부터 Mark Reinhold가 주도적으로 JIT 통합, HotSpot 개발, 1.2의 대규모 클래스 증가, Oracle 인수 이후 동적 언어 지원, 오픈소싱, 빠른 릴리즈, 현대 언어 기능의 기반 등 수많은 혁신을 이끌었음, Java의 강점들은 모두 Mark Reinhold의 리더십 덕분이라고 평가
  • 주요 개발팀 전체가 인상적임, Gosling은 실용적인 언어를 원했고 그 이후 Mark Reinhold, Brian Goetz 같은 이들이 개발자 친화적으로 언어를 발전시켜옴, Oracle을 좋아하진 않지만 뛰어난 그룹을 전진시켜준 점엔 감사
  • Kotlin은 Java처럼 정적 타입의 언어로, 동적 언어 아님을 지적
  • Linus가 git을 단 2주간 해킹해 만들어 spark만 제공했다고 해도 커뮤니티가 확장한 점을 들어, 시작점만으로 평가하는 건 불완전하다는 의견
• 40대 이상의 소프트웨어 엔지니어로서 현실적으로 "일이 잘 되는 도구"를 고르는 게 현명하다고 판단, 오늘날엔 Java나 C#이 그 역할을 충실히 수행, 개인적으로는 C# 쪽이 더 생태계가 잘 통합된 느낌, 어떤 유즈케이스든 C#으로 1분만에 앱을 만들 수 있고, 언어 발전도 빠르고 인력 수급도 안정적, .NET도 크로스플랫폼 지원, 언어 자체의 우아함과 효율성 덕분에 일이 쉬워짐
• 대학에서 OS 코드를 Java로 시뮬레이션 했던 경험, 추상적 알고리즘 공부엔 Java가 복잡성 줄여줘 좋을 수 있다고 이해하지만, 개인적으론 Python이 더 적합했을 것이라는 생각, 산업계 영향으로 대학 초보자 교육에서 무조건 Java를 고수하는 건 동의하기 어려움, 고등학교에선 BASIC, C를 이미 접했기에 Java로 OS 저수준 코드를 시뮬레이션하는 건 한 단계 후퇴처럼 느껴졌음
  • 대학에선 C로 마이크로컨트롤러, Java로 자료구조/OOP, C와 MIPS 어셈블리로 시스템/OS/동시성 개념을 배웠던 경험, 자료구조/알고리즘에선 Python보다 Java가 추상 타입과 구조를 명확히 구분돼 오히려 정확한 개념을 갖기에 나음, 하지만 OS 개념을 Java로 가르치는 건 조금 과하다는 느낌
  • Joel이 언급한 Java 교육의 단점들이 Python 같은 다른 고수준 언어에도 해당한다고 보고, 아이러니하게도 MapReduce(구글이 Java로 만든)이 마이크로소프트보다 앞서간 사례를 강조
• Java의 성공을 인정하지만 여러 이유로 깊은 거부감이 남아 있음, 대부분 대기업의 장황한 코드, 복잡한 프레임워크, 품질 낮은 코드의 유산 때문, 코드가 “석탄처럼” 찍혀나오고 열정 없이 몰개성화 되는 문화가 싫었음, JVM은 내부가 블랙박스라서 strace, gdb 같은 툴로 디버깅이 어려웠고, 메모리 오버 할당으로 커널이 워크로드를 파악하기 힘들었음, JVM 사용시 전문가 도움 없으면 심각한 문제 발생 위험도 높게 느낌, 그리고 Oracle, 라이선스, JDK 버전 관리, 2025년엔 멋진 이미지가 없음, 레거시 코드가 발목을 잡는 점 등이 아쉬움, 개인적으로 Java는 최대한 피하면서도 경력을 쌓아옴, 요즘은 운영상 복잡성 덜한 정적 컴파일, 작은 실행 파일 기반의 고성능 언어가 많아서 JVM, Python VM 같은 솔루션의 역할도 점점 줄어드는 추세
  • JVM은 세계 최고 수준의 디버깅, 리프레임 재시작, 변수 변경, 예외 브레이크포인트 등 엄청난 동적 디버깅 기능 제공, Idea/Eclipse 같은 IDE의 연동도 타 언어에 비할 수 없음, JMX/JConsole, Java Flight Recorder, jstack, HPROF 등 각종 진단툴도 매우 다양, 라이선스는 오픈소스로 사용 제한 없으며, Oracle JVM 구매는 자유 선택일 뿐이라고 지적, 레거시 코드 문제가 뭔지 반문
  • JAVA가 “멋짐”이 없다는 건 설득력 없는 주장, strace/gdb가 아닌 JDK 툴과 IDE가 압도적으로 성능 좋음
  • 툴이 처음에 겉보기엔 어려워보여도 익숙해지기 쉬움, JVM의 GC 튜닝도 일주일이면 전문가로 성장, GC가 애플리케이션 범위에서 커널보다 더 나은 컨텍스트로 관리해 실제 이점이 많으며 다소 프로비저닝 복잡성은 인정
  • 20년 넘게 Java 썼지만 strace/gdb 전혀 필요 없었고, 디버깅/IDE 지원은 아주 강력, 성능에서 Python과 JVM을 같은 선상에 놓는 건 부적절
  • 실제로 Java를 잘 안써봐서 이런 판단 한 것 같고, Java의 디버깅/진단 툴이 최고임을 재확인
• Gosling이 Sun에 있을 때 NeWS 윈도 시스템을 공동 설계했던 사실, NeWS는 Postscript 기반으로 클라이언트가 서버에 프로그램을 보내는 구조였음, Gosling이 Java를 설계할 때 NeWS가 웹페이지를 프로그래밍 가능한 형태로 보길 원했던 흔적이 보임, 실제로 저자 사인이 담긴 "The Java Programming Language" 책에 “Java가 NeWS의 복수냐”고 묻자, Gosling이 미소로 대답함
  • X에 Wayland, NeWS에 브라우저+JavaScript(PWA, Electron)처럼 후계자가 등장한 상황, 결국 NeWS 방식이 Microsoft 환경에서도 승리한 것 같아 Gosling의 생각이 궁금
  • 이와 유사하게 Display PostScript가 있었음, SPARCStation+SPARCprinter 조합에선 인쇄 논리가 서버에서 전부 처리, 서버나 프린터 중 하나만 고장 나도 전체 시스템 마비, 프린트 서버-프린터 연동이 악몽이 되어 결국 프린터에 대한 불신만 커졌던 경험, SunOS, SPARC 에코시스템이 그립지만 Display PostScript만은 잘 보냈음
• 경력 상당 기간 JVM에서 코딩해옴, 최근엔 Java 대신 Scala, Clojure(선호), Kotlin 등 사용, 최근엔 실직 후 Python 일자리 제안을 받아 수락, JVM 경험에 대한 수요가 줄어드는 게 보임, 어쨌든 월급만 나오면 어떤 언어도 괜찮다는 마음, 현재 개인 프로젝트는 Scala로 진행중