자바 유료화 오해와 2018년 대한민국 CIO의 요건

* 이 글은 11월 22일 있을 JetBrains Day 서울 2018 행사에서 기조연설로 필자가 발표할 내용과 연관이 있습니다.

모처럼 내용이 있는^[1] IT 기사가 올라왔다. 오라클의 자바 유료화? 그 진실과 거짓이라는 ZDNet의 기사인데, 눈에 띄는 내용은 아래 문장이다.

한 버전을 오랜 기간 유지해야 하는 수요를 위해 ‘롱텀서포트(LTS)’란 버전이 3년마다 오라클에서 출시된다. 지난 9월 출시된 오라클 JDK 11이 LTS 버전이다. <중략> 오라클은 JDK 11 버전부터 공식 바이너리 코드를 제공하고 있다. 이는 오픈JDK와 오라클JDK가 완전히 동일하다는 의미다. 오픈JDK나 오라클JDK는 최신 버전의 퍼블릭 릴리스 기간 동안 100% 상호호환된다. 이 상호호환성은 6개월 공개지원 기간 동안 유지된다. 오라클은 이 기간동안 오픈JDK와 오라클JDK에 동일한 패치를 제공한다. 반대로, 공개지원 기간 종료 후부터 오픈JDK와 오라클JDK는 전혀 다른 패키지로 상존한다는 뜻이기도 하다.

흔히 말하는 아재(?) 자바 개발자라면 알 수 있는 내용이다. 자바가 생겨날 때와 달리 컴퓨팅 환경도 많이 바뀐 상황에서 자바는 주류 언어 입장에서 새로운 언어의 강력한 도전에 맞서야 하는 상황이다. 간단히 훑어 봐도 자바 1.4, 1.5 로 불리던 시절에는 클라우드나 스트리밍 방식의 고도의 분산 프로그래밍이 흔히 쓰이지 않았다. 새로운 언어와 기술의 도전을 받으면서 자바 개발 진영은 새 버전 출시 기간을 줄이면서 횟수도 늘리겠다는 혁신적인 방안을 내놓았다. 이러한 약속을 지키는 동시에 모든 버전을 패치하면 지원하기는 어려울 것이고 이에 따른 오라클의 현실적 기술 지원 전략으로 짐작할 수 있다.

개발을 최근에 배운 사람, 자바가 생소하거나 혹은 개발 경험이 없는 사람이라면 인용한 기사 내용이나 필자가 대강 풀이한 정황 해석을 알기 어려울 수 있다. 그런 분이라면 한 가지만 기억하시면 좋겠다. 오라클의 JDK 지원 정책이 바뀐 사실에서 골자는 개발자들이 자바를 매력적으로 여겨서 쓸 수 있게 하기 위해 시장의 논란을 무릅쓰고 속도감 있는 출시를 선택했다는 점이다. 최근 몇년과 같은 더딘 출시 속도로는 자바가 설 땅은 점차 줄어들 것이다. 매력적이고 실용적인 새로운 언어들이 많이 등장했고 발전하고 있기 때문이다. JDK는 자바 개발자를 위한 키트_Kit 이고, 곧 개발자들이 사용자인 터라 그들에게 어필해야 하는 것이다.

계속해서 코드를 수정한다는 의미는 무엇인가?

코드가 시장에서 쓰이며 살아남기 위해서는 필연적으로 계속 수정되어야 한다. 그런데, 모든 코드를 한번에 수정하는 것은 아니다. 대개는 아주 일부만 고치고 배포한다. 배포 이후에 어떤 프로그램은 과거 형태 그대로 돌아가고, 일부 프로그램은 새로운 코드로 돌아간다는 의미다. 간단한 일처럼 보이지만, 오래 유지하며 여럿이 개발하는 코드라면 결코 간단한 일이 아니다. 개발자는 평면적인 파일 형태로 코드를 작성하지만, 코드가 널리 쓰이고 덩치가 커질수록 방대한 연관성을 갖는다. 이 과정에서 내가 작성한 코드와 작성하지 않은 코드가 연관을 맺는 일이 발생하고, 연관관계가 너무 복잡해져서 코드를 수정할 수 없는 수준이 되지 않도록 끊임 없이 다듬어야 한다. 이 과정이 다수의 협업으로 이뤄지는 경우라면, 현재 작성하는 코드가 다른 코드에 의존하는 내역을 통제하는 다양한 도구^[2]가 필수적이다. 무려 8조원에 팔린 깃헙github이 바로 계속해서 코드를 수정하기 위한 도구 중에 하나다. 길게 설명했지만 사실 개발자에게는 너무나도 당연한 일상이다.

출처: https://en.wikipedia.org/wiki/Git

이러한 도구를 사용해 개발팀이 배포하려는 코드를 분할하여 관리하는 방식 혹은 단위가 코드 브랜치_Branch 같은 방법이다. 한번에 반영하려는 코드의 묶음을 갈래치는_branch^[3] 행위가 프로그래밍에서 차지하는 의미를 이해해야 기사에서 필자가 인용한 부분을 충분히 이해할 수 있다.

개발자 입장에서는 당연한 이야기인 듯 하지만, 개발자가 아닌 사람들이 그 의미를 알 수 있을까 싶다. 아쉽게도 기업에서 시스템에 대해 절대적인 영향을 끼치는 사람들 중에는 개발 경험^[4]이 없는 이들이 많다. 그들은 자신의 기업에 의미있는 형태로 해당 사건을 해석할 수 있을까? 필자가 CIO를 지목하는 이유는 여기에 있다.

자바만 빨리 변해야 사는가?

자바를 개발하는 진영도 경쟁력 있는 출시 속도를 위해서 적절한 수준의 코드 볼륨을 관리한다. 기사를 쭉 읽어 내려가다 보면 흥미로운 부제가 보인다.

빨리 변해야 자바가 산다

자바 언어 등장은 네트워크가 널리 퍼지면서 함께 퍼졌다. 가상머신VM 위에서 돌며 하나의 언어로 다양한 컴퓨터(혹은 운영체제) 위에서 구동할 수 있다는 사상이 세상에 통했다. 그리고, 바로 그 네트워크로 인해 과거에는 하나의 공간에서 머물러야 했던 컴퓨터 자원이 자유로워졌고, 자바는 새로운 시대의 요구에 빠르게 대응하기 위한 진화하는 중이다.

빠른 변화에 대한 적응 요구는 자바만 받고 있나? 대한민국 대기업 정체와 소프트웨어 활용은 관련이 없나? CIO가 없는 회사는 둘째 치고, 누군가 CIO라면 마땅히 아래와 같은 질문을 던질 필요가 있다.

우리 회사는 빨리 변할 준비를 하고 있나?

소프트웨어는 잠시 지나가는 유행이 아니다. 그리고, 한번 구축하면 5년 정도 쓰다가 새로 만드는 장비도 아니다. 항상 형태를 바꿀 수 있는 '바로 그' 소프트 함을 활용해서 기업 경쟁력을 높여야 한다. 소프트 함의 예시는 이런 것이다.

• 창고에 있는 재고와 매장에 있는 재고가 따로 있지만^[5], 정보와 대화 채널을 잘 다루면 가상의 창고에 모여 있는 듯 '소프트 하게' 다룰 수 있다.
• 모두가 사용하는 휴대폰에 프로그램을 탑재하면 다양한 소통을 통해 새로운 거래 양식을 만들 수 있다. (공유 경제 현상)
• 웹 사이트에서 자동으로 모을 수 있는 접근 로그 데이터에서 필요한 내용만 추출해서 업무를 잘 아는 사람이 가공할 수 있으면 노트북 화면으로 세상에 벌어지는 다양한 거래 상황과 바뀐 사용자들의 행태를 이해할 수 있다.

소프트웨어 역량을 높여야 하는 이유는 바론 이런 것이다. 기업의 본래 경쟁력에 더하여 속도와 유연성을 더해준다. 위험한 투자나 새로운 시장 개척을 꼭 하지 않더라도 시간에 비례해서 진화를 이뤄낼 수 있는 강력한 도구를 소프트웨어가 제공한다. 소프트웨어로 우리 기업의 핵심 가치가 만들어내는 부가 가치를 극대화 할 방법을 찾아가야 한다. 위험이 덜한 작은 시행착오를 겪으면서 수행하는 끊임없는 실험으로 경쟁력을 만드는 방식이 소프트웨어가 우리에게 줄 수 있는 선물이다.

CIO가 버전과 브랜치 의미를 알아야 하나?

이쯤에서 다시 이렇게 물을 수 있다.

브랜치와 CIO를 연결하는 일은 너무 비약 아닌가?

비약이랄 수도 있지만, 허무맹랑한 연결은 아니다. 글을 쓰면서 찾아보니 한국 자바 생태계가 유료화에 민감한 이유라는 기사에 인용할만한 내용이 있다.

국내 기업 사용자는 애플리케이션을 수시로 바꾸거나 변경하기 힘들다. 신규 개발보다 운영과 유지보수에 익숙하고, 대대적인 빅뱅 방식의 차세대 프로젝트 중심으로 IT시스템을 만들어가는 체계가 확고하게 자리잡았다.

필자가 하고 싶은 말은 소프트웨어 역량은 내재화 해야 한다는 아주 단순한 결론이다. 그런데, 개발자와 그들의 일을 이해하지 못하는 사람이 소프트웨어에 대한 의사결정을 해서야 말이 되겠는가? 즉, 사내 내재화에 있어 CIO 역할은 지대하다. 필자가 브랜치를 예로 들어 상징한 내용은 소프트웨어 개발자라는 특수한 직종에 대한 이해는 CIO의 필수 요건이라는 주장이다.

외주 개발 100% 의존 제발 그만 두자

필자는 그간 차세대 프로젝트의 폐단에 대해서는 그간 몇 차례 글을 썼다. 응용 프로그램은 수시로 바꿀 수 있도록 만들려면 외주 개발을 줄여야 하고, 우리 회사 개발자들의 다룰 수 있는 형태로 프로그램을 발전시켜 가야 한다. 서울에서 외식을 하던 중에 만났던 장면 하나로 외주 개발의 폐해를 설명할 수 있다. 오랜만에 들른 어느 쇼핑몰에서 키오스를 보다가 가장 좋아하는 기능이 사라졌음을 확인했다. 주차장이 넓어서 차번호 뒷자리 4자리만 넣으면 주차위치를 알려주는 기능을 매우 편리했는데 이젠 사용이 불가하다는 알림이다. 필자는 문득 외주 운영 업체가 바뀌었구나 하고 짐작하게 된다. 좋은 기능이지만, 개발자가 빠지고 나선 수정을 못하는 것이다. 개발자 출신인 필자 소견으로 봐서는 간단한 수정일 텐데 말이다.

키오스크에 보이는 주차위치 확인 불가 안내

과거 전산실이 있던 시절처럼 장비를 들여오듯 프로젝트를 하는 일은 터무니없는 행위지만 여전히 벌어지고 있다. 4차산업 운운하는데 사실 이러한 행태는 제조업의 회사 운영 형태와 사고 방식을 그대로 고착화 했다는 점에서 2차산업의 견고한 기반이라 할 수 있다. 소프트웨어를 하드웨어처럼 다루는 조직이란 뜻이기도 하다. 이런 난관을 깨뜨리기 위해서는 개발 역량을 보유한 회사로 혁신할 수 있도록 회사 오너를 설득해야 한다. 그렇지않으면 미래는 사향길이다.

한국 자바 생태계가 유료화에 민감한 이유라는 기사 일부를 다시 인용하면서 글을 마친다.

그는 “지속적으로 변화하는 자바를 사용하고, 적절하게 대응하려면 국내 기업의 IT 접근 방식 자체를 바꿔야 한다”며 “자체 인력 고용을 통해 기술을 내재화해야 빨라진 자바 업데이트에 원활히 대응할 수 있다”고 덧붙였다.

주석

[1] '모처럼 내용 있는'이란 수사를 단 이유는 그만큼 IT 기사가 광고성격이 너무 강하거나 완전히 엉터리인 경우가 많기 때문이다.

[2] Doker, Jenkins, Maven, Dependency Injection 도구, IDE의 참고 관계 추적 도구, JSON/XML 설정 방식, ... (끝도 없다)

[3] 영어 단어 branch는 나무 가지의 뜻이기도 하다.

[4] 과거에 개발을 했더라도 코드 공유가 없던 분업환경에서만 일했거나 네트워크 형태 배포가 없던 시절 개발자라면 이해할 수 없기는 마찬가지다.

[5] 필자가 현재 유통/리테일/커머스 분야에서 일하기 때문에 예가 자연스럽게 그 쪽으로 치우친다.