336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
개발자는 '생산성'이라는 단어를 무척이나 즐겨 사용합니다. 또한 '생산성 향상'이라는 말도 매우 좋아하는 것 같습니다. 누군가가 "이러이러한 방법으로 생산성을 향상시켰습니다"라고 감격에 차 말하면 개발자는 그 사람에게 진심으로 박수를 보냅니다.

그런데 이 생산성 향상이라는 것을 개발자 중심의 시각에서 생각해보면 어떨까요? 아래는 관련해서 제가 써본 글입니다.
자바를 이용하여 개발한다는 것은 일반적으로 JVM 위에서 대다수의 일들이 이루어진다는 것을 뜻합니다. JVM은 운영체제로부터 개발자를 분리시켜 줍니다. 예를 들어 JVM으로 인해 개발자는 운영체제 원리에 대해 깊히 알 필요가 없어졌습니다. JVM과 JVM을 한번더 감싸고 있는 Java API가 개발자가 내린 명령을 대신 실행해줍니다. 소프트웨어 아키텍쳐적인 시각으로 보았을 때 JVM의 이런 개념은 멋진 개념일 것입니다.

이러한 JVM의 멋진 개념은 여러 가지면에서 소프트웨어 산업계에 긍정적인 기여를 했다고 생각합니다. JVM으로 인해 '높은 이식성'을 가지는 웹 애플리케이션이나 GUI 클라이언트와 같은 소프트웨어를 쉽게 작성할 수 있게 되었고, 개발자들은 운영체제에 대한 깊은 지식 없이도 견고한 애플리케이션을 만들 수 있게 되었습니다. 위 두 가지 유익으로 인해 개발 생산성이 높아진 것은 두말할 나위가 없습니다.

그럼 이것이 개발자들에게 좋은 일인가요? 제가 볼 땐 아닙니다. 이것은 개발자들보다는 소프트웨어 산업과 기업에 좋은 일입니다.

예를 들어 A라는 기업의 개발팀에서 이식성이 좋지 않은 언어B을 이용하여 개발한 GUI 애플리케이션을 유닉스와, 맥, 윈도우에 배포하고 있었다고 가정해봅시다. 언어B을 이용해서 개발할 때는 운영체계의 특징에 따라 포팅 작업이 필요했습니다. 따라서 주요 기능을 개발한 후에 릴리즈를 하기 위해 포팅 작업에 시간을 쏟곤 했습니다.

그런데 어느날 자바가 나왔습니다. A기업의 CTO는 자바를 면밀히 검토했습니다. 그리고 자바는 이식성이 B언어에 비해 훨씬 좋기 때문에 그 동안 포팅 작업이 소요되던 개발 시간을 단축시킬 것이라 판단했습니다. 그는 곧 CEO에게 제안을 하여 허락을 받았고, 그의 지휘 아래 개발팀은 모든 것을 자바 기반으로 바꾸기 시작했습니다.

1년뒤 A기업의 CEO는 자바 도입으로 몇가지 희생도 있었지만 어쨋든 개발 생산성이 향상된 것을 알 수 있었습니다. 갈 길 바쁜 기업으로써는 좋은 일이였지요.

그렇다면 개발자들은 어떻게 되었을까요?

개발자들은 1년전과 다름없이 바쁘게 일하고 야근을 했습니다. 단지 차이라면 예전에 포팅 작업을 했을 시간에 다른 일을 하게 된 것입니다. 예, 아쉽게도 아무것도 달라지지 않았습니다.
또한 포팅 작업을 하며 운영체제간에 미묘한 차이점에 대한 경험 쌓는 것을 즐거워 하던 개발자A씨는 퇴사를 하려고 준비하고 있습니다. 이제는 자신이 회사에서 경험할 수 있었던 기술적 도전과제가 사라졌다고 느꼈기 때문입니다.


WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
예전에 JVM(Java Virtual Machine) 옵션 튜닝에 빠져 관련문서를 열심히 보던 때가 있었습니다. JVM 옵션을 튜닝하면 뭔가 그럴싸한 성과를 낼 수 있을 것이라 생각했었습니다. JVM 옵션 튜닝에 대해 뭔가 큰 환상이 있었습니다. 그러던 중, 꽤 큰 시스템을 대상으로 JVM 옵션을 튜닝해볼 수 있는 기회가 주어졌습니다. 기쁜 마음으로 다양한 실험을 해보았습니다. 하지만 결과는 만족스럽지 않았습니다. 가비지 콜렉션 시간을 약간 줄이고, 자바 프로세스가 시스템의 물리 메모리를 좀 더 천천히 가져가게 하였습니다. 안타깝게도 이게 전부였습니다. 가시적으로 눈에 확 띄는 효과가 없었습니다. JVM 옵션 튜닝에 대해 가졌던 환상이 깨졌고 많이 아쉬웠습니다. 하지만 남는 것이 있었습니다. 여러 옵션들의 사용법에 대해서 배울 수 있었던 것입니다.

당시 배웠던 옵션 중에는 JVM이 구동될 때 클라이언트 혹은 서버 모드를 선택할 수 있게 해주는 옵션이 있습니다. 실행 시 -client 옵션을 주면 클라이언트 모드로 구동되고, -server 옵션을 주면 서버 모드로 구동이 됩니다. 각 모드는 각각의 고유한 특징이 있습니다.
클라이언트 모드의 경우에는 빠른 시작과 적은 메모리 사용을 위해 최적화 되어 있습니다. 클라이언트 모드에서는 바이트 코드를 기계어로 컴파일 할 때 복잡한 최적화 기법을 이용하지 않습니다. 덕분에 코드를 분석하고 컴파일하는 시간이 서버 모드에 비해 훨씬 줄어들게 됩니다. 그래서 보다 빨리 시작되며, 컴파일 할 때 메모리도 적게 쓸 수 있습니다.
서버 모드의 경우에는 오랜 시간동안 실행되는 서버 애플리케이션에 최적화 되어 있습니다. 그렇기 때문에 C++ 컴파일러에서 쓰던 최적화 기법뿐만 아니라 더 진보된 많은 컴파일 최적화 기법들을 이용하여 컴파일을 합니다. 그래서 초기에는 컴파일 하는데 클라이언트 모드에 비교하여 좀 더 시간이 걸립니다. 대신 컴파일이 완전히 종료되면, 컴파일 된 코드에 실행에 대해서는 더 나은 속도를 보장하게 됩니다.

저는 이 옵션에 대해서 알게 된 이후로 제가 맡고 있는 모든 웹 애플리케이션 시스템을 서버 모드로 돌렸습니다. 일반적인 웹 애플리케이션은 구동된 후 같은 기능이 오랜 시간 동안 여러번 실행되기 때문에 주요 코드들은 반복적으로 자주 이용됩니다. 따라서 서버 모드가 적합하였습니다. 그 후로도 JVM이 구동되는 곳이라면 어디든지 서버 모드를 사용했습니다. 마치 버릇처럼 되어버렸습니다. GUI쪽의 애플리케이션을 만들지 않는 이상 클라이언트 모드를 사용할 만한 곳은 없다고 스스로 생각했습니다.

그 런데 어느날이였습니다. 로컬 개발 환경을 구성하다보니 새로운 생각이 떠올랐습니다. 그것은 로컬 개발 환경에서는 서버 모드 대신 클라이언트 모드를 사용하는 것이 더 좋을 것 같다라는 생각이였습니다. 클라이언트 모드가 더 좋을거라 생각한 근거는 톰캣이 일반적으로 짦은 시간 동안만 사용되며 자주 재시작이 되기 때문입니다. 저의 로컬 개발 환경을 예로 들어보겠습니다. 저는 톰캣을 씁니다. 기능에 대한 코드를 작성하고 톰캣을 띄웁니다. 그리고 알맞은 URL에 들어가 테스트를 해봅니다. 버그가 발견 됩니다. 버그를 고칩니다. 버그 수정본을 반영하기 위해 서버를 재시작(리로딩)합니다. 이런 과정을 하루에도 수십번 반복합니다. 이런 경우라면 주요 코드라 할지라도 몇번 호출되지 않습니다. 새로운 코드 반영을 위해 금방 톰캣이 꺼지기 때문이죠. 그래서 빠른 시작과 빠른 컴파일이 더 유용하다고 생각했습니다.

이 후 로컬 환경에는 클라이언트 모드를 사용하고 있습니다만, 사실 속도차를 체감하진 못합니다. 그래도 서버 모드보다는 나을 것입니다. 필요없이 복잡한 최적화를 하지 않을테니까요. :)


WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

,