(1년 전쯤에 리눅스 서버에서의 JDK/Web/WAS 표준화를 마무리했던 것을 작성해보려고 한다. 함께 같이 고민했던 분들이 기억이 난다. 서로 배려해주고, 이해해주고 회사의 장래에 대한 깊은 고민을 같이 했던 분들을 그 때 많이 만난 것 같다. 정말 고마운 분들 ^^)
표준화를 진행하는 것은 상당히 부담스럽다. 무엇이 표준인가? 라는 답에 대답하기가 쉽지 않다. (표준어가 교양 있는 서울 말인가? 하는 고민과 비슷할 수도 있다. )
네이버에 따르면, 표준은 두가지 의미가 있다. 기준 또는 평균 (영어로도 standard, average, norm이다 )이다.
(출처 : http://krdic.naver.com/detail.nhn?docid=40783400)
나는 단어 사전의 의미보다는 사회과학의 ‘표준’의 정의가 마음에 들었다. 단순화와 통일화를 도모하는 방법으로 배치,절차, 방법에 대해서 설정된 기준 정도로 했다.
(출처 : (http://terms.naver.com/entry.nhn?docId=473521))
자유롭게 하지 않고 왜 표준화냐? 에 대한 부분은 공감이 필요할 것 같다.
만약 팀 단위에서 모든 일이 해결한다고 가정하면 이런 표준에 대한 의미가 없을 수 있다. 그러나 점점 버그와 보안 문제로 인한 오픈 소스 거버넌스와 문제, 트러블 슈팅과 같은 기술지원이 빈번해지면서 필요성을 느낄 수 밖에 없었다. 특히 나는 기술지원이나 트러블 슈팅해주다 보니 , 같은 디렉토리를 서로 다른 디렉토리를 쓰다 보니 늘 혼란스러웠다.
어떤 사람은 소스로 설치하고 어떤 사람은 자동 배포(apt-get, yum)으로 하고. 서로 다른 것들로 싸여 있었다. 그렇게 때문에 naming 때문에 고민하기도 했다. 많은 개발자들이 직감적으로 이해할 수 있게 하려고 했다.
웹 서비스가 처음 개발하게 되면 그 상태로 계속 가능 경향이 있었다. 특히 리눅스를 잘 다루는 개발자가 리눅스에서 jdk/web/was를 셋팅한다. 몇 개월 또는 몇 년이 지나 그 환경을 인수인계 받은 사람은 대부분 신입들이 그 자리를 차지한다. 리눅스를 잘 다루면서 코딩까지 자유롭게 하는 사람은 그리 많지 않다. 문제가 생기는데 해결하는 것이 어려워지면서 기술지원팀에 요청하게 되면서 점차 요구사항이 커졌던 것 같다.
코딩은 자유롭게 하되, 리눅스의 환경을 동일하게 맞춘다면 개발자나 시스템 엔지니어가 어떤 팀으로 이동해도 학습 비용은 절감될 수 있을 것이라 믿었다. 또한 root 계정에 쉽게 사용하지 않게 함으로서 보안을 높일 수 있는 믿음이 있었다. 우리가 하향 평준화가 아닌 상향 평준화가 되면 좋겠다는 믿음이 있었다. (잘하는 사람에게는 상당한 부담이 될 수 밖에 없었다. ) 마지막으로 일반적인 개발자 입장에서는 표준화된 환경에서 대부분 코드에 집중함으로서 생산성을 높일 수 있는 시간을 줄 수 있도록 하고 싶었다. 그래서 pc나, 리눅스 개발환경의 표준은 일부러 정하지 않고 배포된 서버(release)중심으로 정했다.
<배경>
1. 소프트웨어 버전,설치 방법은 개인역량에 따라서 달라졌다. 웹 서비스 자체를 운영 한다면 다양한 스크립트가 양산되는데, 사람의 역량에 너무 의존한 부분이 있었다. 누구는 perl, csh, bash, python, ruby…. 개념은 같고 먼가 복잡성이 거의 없다. 사실 한번 잘 만들면 더 이상 수정하지 않는 특성이 있다.
2. 부서 이동이 많아지면서 웹 서비스를 지탱하는 소프트웨어나 버전을 정확히 답변하는 사람이 드물었다. 기술 지원하려면 시간이 불필요하게 소요되지 않게 하는 표준화가 필요했다.
3. 일반적인 웹 서비스 개발자는 리눅스 자체가 두려움이 대상이 되어 잘 모르면 다칠 수 있다는 것이 있다. 많이 리눅스를 접하고 리눅스 환경에서 익혀본 개발자가 아닌 어플 개발자의 입장에서는 상당히 곤혹스러울 수 있다. jdk, web, was 설치 자체가 번거롭다.
4. 처음부터 오픈 소스 거버넌스(보안, 버그)로 검증된 표준화된 jdk/web/was가 설치된 상태로 서버가 개발자에게 전달하면 바로 웹 어플리케이션만 배포하면 되니. 속도가 빨라질 수 있다.
5. 처음 웹 서비스 개발하는 사람에게는 리눅스 환경을 전혀 알 수가 없다. 따라서 비슷하게 작업하는 공통의 스크립트과 환경 설정을 모아서 물리 서버에 배포하면 웹 서비스를 처음 하는 사람에게 쉽게 노하우를 전파받을 수 있을 것이다.
<진행>
초안(워드)를 작성해서 같은 TF사람들/ 웹 어플 배포팀 / 보안 팀 / 시스템 엔지니어 와 함께 협의 하며 진행했다. 300페이지가 넘는 ‘설치가이드’,’노하우가 담긴 설정 가이드’,’예제/체크가이드’ 문서를 작성했다. 우리 모두를 위한 서비스를 위한 jdk/web/was 환경이 담겨있었다.
기본적으로 root 계정이 아닌 임의의 계정으로 통일하고, 기본 디렉토리, 좋은 스크립트, 불필요한 설정 제거, history/psacct, jdk 이슈등에 대한 정보와 web 서버인 apache http와 모듈 정보, was인 tomcat, mod_jk에 대한 상세 설정을 작성했다.
내가 가지고 있는 지식과 직접 소스를 파며 얻었던 지식들을 많이 넣었다. (많이 부족한 사람이 쓴 거라 누군가가 더 좋은 글로 탄생해줄 것이라 믿는다.)
책에는 없는 설명들, 운영하면서 중요하게 생각한 팩터들, 장애 및 보안에 대한 깊은 이해와 노력을 넣었다. 기본적인 트러블 슈팅에 대한 정보를 넣었다. 단편적인 인터넷 문서나 너무 많은 jdk/web/was 매뉴얼의 단점을 보완하고 꼭 필요한 내용으로 작성한 문서였다.
PPT를 작성해서 한 눈에 보면 디렉토리 구조와 심볼링 링크를 따라갈 수 있게 했고, 전체적으로 빨리 볼 수 있게 했다.
<마치며…>
저말 개발자에게 도움이 되는 좋은 표준안이 되기를 진심으로 바랬던 마음으로 쓰려고 했다. 한편 다른 마음으로는 그 시간에 코딩을 하고 싶었다. 지금 돌아보니 나의 욕심 대신 개발자를 섬긴 시간들이 소중했던 것 같다. 겸손함과 진지함, 상대방에 대한 존중을 배웠던 것 같다.
'철학' 카테고리의 다른 글
기술 블로그 (Tech Blog) 기획/철학 (1) | 2013.01.11 |
---|---|
FOSS 거버넌스 (Free Open Source Software Governance) 업무하면서 들었던 생각들 (0) | 2011.12.14 |
북셀렉터 1기 회고하면서 (디자이너, 기획자, 서비스 개발자에게 운영체제를 이해시키기) (0) | 2011.12.13 |
삼성의 S급 인재 걷어찬 기사 (0) | 2011.08.11 |
jni를 최대한 안쓰는 게 잘하는 것 (0) | 2011.05.27 |