글로벌 칼럼 | 자바를 위험에 빠뜨리는 것은 오라클의 폐쇄정책

자바(Jave) 보안 업데이트가 끝없이 계속되고 있다. 가장 최근 패치에는 취약점을 보완하기 위한 여러 중요한 디자인 변경이 포함됐지만 앞선 수정 시퀀스 역시도 중요했다. 몇몇 전문가들이 올초 지적한 것처럼 자바의 보안 문제들은 수정하기가 까다롭다. 그 문제들이 근원적 설계 결정, 특히 자바의 브라우저-기반 활용을 지원하는 코드와 연관되어 있기 때문이다.

보안 전문가들을 걱정스럽게 하는 것은 연루된 상호 서브시스템의 하위 부분이다. 이것은 단일 서브시스템의 결함이라기보다는 서브시스템 상호작용의 결과라고 하는 것이 더 정확할 것이다.

오라클은 이 문제를 해결하기 위해 고군분투하고 있고 그 노력은 분명 평가할 만하다. 그러나 필자와 이야기를 나눈 개발자들은 오라클이 다수의 보안취약점을 보완했지만 새로운 보안취약점이 계속 등장하고 있고 여전히 악의적인 크래커들의 움직임이 활발하다는 것이다.

오라클의 자바 기술 책임자는 최근 자바 보안 문체 때문에 최신 버전 개발 일정이 늦어지고 있다고 인정했다. 그는 “다시 대두된 보안 문제 때문에 자바 8과 GA의 9월초 공개 일정은 불가능해졌다"고 말했다.

썬으로 돌아가보자
사실 이 문제는 원래 오라클에서 시작된 것이 아니다. 수년 전부터 처음엔 썬(Sun)에서, 나중엔 오라클에 이르기까지 축적되어 온 문제다. 이 문제는 지금까지 계속해서 뒤로 미뤄지기만 했고 '시급하다'는 미명하에 개발자들의 초점을 비즈니스 고려사항에 우선 맞추게 했다.

필자는 이 문제를 과거와 현재 자바 개발팀의 핵심 인사들을 포함한 여러 사람들과 논의해왔고, 그들 모두 이 문제가 자바의 오래된 '기술적 부채'의 결과라고 이야기했다. 썬이 책임을 지고 있는 동안 이 문제가 드러났을 수도 있지만 썬 팀은 (오라클에 인수됨으로써) 운 좋게도 그런 상황을 피해갔다.

기술적 부채와 씨름하는 것은 시간이 많이 걸리는 일이지만, 하나씩 하나씩 프로젝트를 통해 해결돼야 한다. 몇몇 베테랑 프로젝트들은 이런 유형의 잡동사니로부터 그만큼 고통받지 않는 것처럼 보이지만, 그 핵심은 커뮤니티에 있다.

상용 프로젝트들은 종종 코드를 깨끗이 유지하는 지루하고 고된 일보다는 고객의 요구사항과 마케팅 일정을 우선시하고, 이 기능에만 초점을 맞추도록 강요받는다. 반면 대규모의 건강한 커뮤니티를 갖춘 오픈 소스 프로젝트들은 커뮤니티 구성원들이 종종 밀린 일을 해결하는데 열정과 전문성을 쏟아붓기 때문에 기술적 부채 문제에서 비교적 자유롭다.

리브레오피스가 기술적 부채를 해결한 방법
대표적인 것이 리브레오피스(LibreOffice)의 사례다. 프로젝트 초기만 해도 리브레오피스는 커다란 기술적 부채를 오픈오피스(OpenOffice)로부터 물려받았다. 일부에서는 리브레오피스를 가리켜 '문제를 일으키지 않기 위해 기능이 개선되지 않고 버그가 해결되지 않은 15살짜리 코드'라고 비판하기도 했다. 그러나 현재 개발자 커뮤니티의 리브레오피스에 대한 자신감은 이전보다 훨씬 커졌다.

그 결과 매 6개월마다 팀을 다른 방향에 전념하게 했던 썬의 관리 시절에는 불가능했을 코드에 대한 투자가 이뤄졌다. 몇몇은 아주 지루한 일이었는데 예를 들어 수만 개의 코멘트를 독일어에서 영어로의 번역하는 작업 때문에 제2 언어로 영어를 쓰는 개발자들이 협업을 하는 별도 작업을 진행하기도 했다.

디펑트(defunct) 운영체제 지원 제거, 객체 모델 리팩터링, 대화 레이아웃 메카니즘의 최신 업데이트 등 다른 개선사항들도 이뤄졌다. 회귀(regressions)의 급속 해결을 위해 고안된 '바이너리 바이섹트'(binary bisect) 같은 새로운 QA 기법도 적용됐다.

리브레오피스 커뮤니티는 그 빚을 청산하기 위해 많은 시간을 투자하기로 선택했지만, 동시에 중요한 신기능에도 상당히 공을 들였다. 최신 버전의 신기능은 매우 다양한데 마이크로소프트 웍스 임포트 필터(Mmicrosoft Works Import filters), 비지오(Visio), 마이크로소프트 퍼블리셔(Microsoft Publisher), CMIS 지원 같은 기능이 대표적이다.

그렇다면 오라클이 자바를 오픈소스로 하겠다고 다시 공언해야 할까? 오픈JDK(OpenJDK)로 유지한다는 약속을 지키는 한 자바의 오랜 기술적 부채를 해결하는 이 투자는 일회성 비용으로, 자바가 미래에도 방해 받지 않고 발전할 수 있도록 해 줄 것이다.

과거 레드햇의 오픈JDK 버전에 대한 지원도 참고할 만한 사례가 될 것이다. 오픈JDK 6를 유지하겠다는 결정은 썬에 의해 시작된 자바 코드 시작의 열매다. 오픈소스가 됨으로써 레드햇은 오라클에 의해 공석이 된 프로젝트 리더의 자리를 차지할 수 있었다. 오픈JDK 커뮤니티의 도움과 함께, 레드햇은 여전히 널리 사용되는 코드를 유지할 수 있길 희망한다.

오라클의 적은 오라클이다
보안 협업에 관련되어 문제는 여전히 남는다. 마이SQL과 같이 오라클은 보안 문제에 있어서 다른 커뮤니티 구성원들을 동일하게 대하길 거부하고 자바와 관련해 포괄적인 보안 팀을 조직하지도 않았다. 대신 보안 문제는 비밀리에 해결되는데 가장 신뢰받는 파트너들조차 어떤 작업이 진행되는지 겨우 힌트만 얻을 정도다.

특히 오라클은 보안 수정을 최종사용자와 커뮤니티 파트너들에게 동시에 공개해 이를 검증하거나 변화를 통합할 시간적 여유를 주지 않는다. 이런 보안 협업의 부재가 페도라(Fedora)와 오픈수스 리눅스(OpenSuse Linux) 프로젝트 등이 MySQL 대신 마리아DB(MariaDB)를 사용하게 만든 이유이며 오픈JDK 커뮤니티에게도 문제가 된다.

오라클의 강력한 내부 보안 정책은 자체 오픈 소스 프로젝트의 공개 움직임을 계속해서 차단하고 있는데 역설적으로 오라클 역시 이런 비타협적 태도의 비용을 톡톡히 치르고 있다.

보안 작업의 성과가 점진적으로 알려지겠지만 오라클의 접근방식은 진단, 수정, 테스팅의 부담을 전적으로 회사의 부담으로 남기겠다는 의미다. 자바 차기버전 출시 연기에 대한 블로그 글에 격렬한 댓글 토론이 벌어지고 있지만 연기의 이유보다는 공개 일정에 기능을 맞추는 작업을 우려하는 목소리가 더 높다.

자바의 보안 실패는 장기적인 기술적 부채를 상환하기 위한 피할 수 없는 과정이다. 그러나 오라클이 이 문제들을 계속해서 폐쇄적으로 진행해 나간다면 (어쩌면 막을 수 있는) 미래의 사고들까지 고스란히 당할 수밖에 없을 것이다.