지속적인 빌드와 개발 - 박재성
이 발표는 자바지기님이 쓰신 자바 세상의 빌드를 이끄는 메이븐에 담긴 내용을 요약정리하는 내용이라고도 할 수 있고 얼마전에 올리신 단순 반복 업무에 대한 투자에 대한 고민들도 들어가 있습니다. 저희가 보통 하는 일은 비즈니스 로직을 작성하는 일과 단순반복업무로 나눌 수 있습니다. 단순반복업무에는 서버 셋팅, 빌드, 테스트, 배포등이 있습니다. 비즈니스 로직은 2가지로 나눌 수 있는데 사람밖에 할 수 없는 일이 있고 컴퓨터가 할 수 있는 일이 있습니다. 대개는 컴퓨터가할 수 있는 일은 사람도 할 수 있기 때문에 직접 처리하곤 합니다. 프로젝트 초반에는 비즈니스 로직작성과 단순반복업무를 섞어서 하지만 중반부터는 단순반복업무는 잘 안하고 비즈니스 로직에만 집중하게 됩니다. 프로젝트가 후반에 가면 다시 단순반복업무에 신경쓰기 시작 하지만 많은 것들이 픽스되어 있는 상태라 변경하기가 쉽지 않습니다. 그리고 프로젝트가 완료된 후에는 단순반복업무의 비중이 커지게 됩니다.
이후에는 위키북 프로젝트의 경험을 공유해 주셨습니다. 위키북에 대한 자세한 내용은 자바지기님의 메이븐 책을 참고하면 잘 나와있고 굳이 다른 점이라면 책은 메이븐에 초점이 맞춰져 있지만 발표에서는 전체적인 경험에 대한 이야기 였습니다. 프로젝트 처음에는 JIRA나 SVN/GIT, 데이터베이스등의 개발서버 환경을 셋팅합니다. 개발환경에서는 개발디비를 공유해서 사용하지만 개발 중에 스키마가 변경될 때 개발이 원활하지 않음을 느끼게 됩니다. 누군가 스키마를 변경하면 소스와 싱크가 맞춰질 때까진 나머지 사람은 대기할 수 밖에 없습니다. 그래서 각 개발자 PC에 디비를 설치하도록 했습니다. 이는 개발자들 사이에서 반발이 꽤 심했습니다. 개발을 하면서 배포를 하는데 배포에는 아주 많은 단계가 있습니다. 이를 개발자가 직접하면 빠뜨리는 단계가 생길 수 있기 때문에 쉘 스크립트로 자동화를 합니다. 개발자가 로컬디비로 개발을 하면서 로컬디비와 개발디비의 스키마 차이로 오류가 생기는 경우가 발생해서 동기화를 할 필요가 생겼습니다. 만약 프로젝트가 ORM을 사용한다면 스키마 변경되었을 때 간단하게 자동 업데이트를 할 수 있지만 ORM을 사용하지 않는다면 Carbon FIve가 대안이 될 수 있습니다. Carbon Five는 변경되는 스키마 쿼리를 sql 파일로 관리하고 디비의 schema_version 테이블에서 적용된 파일의 버전을 관리하다가 새로운 버전의 sql파일을 다시 실행합니다. 이는 개발 단계에서 피곤함을 줄 수 도 있지만 실서버 운영에 들어갔을 경우에는 실디비와 스키마 동기화를 해야하기 때문에 미리 연습할 수 있다는 장점이 있습니다.
테스트를 추가해서 빌드시에 테스트를 수행하도록 하였지만 시간이 지날수록 개발자들이 유닛테스트를 @Ignore 처리하는 경우가 발생할 수 있는데 이는 조심해야 합니다. 배포는 Jenkins같은 도구로 자동배포를 합니다. UI 개발자는 데이터베이스는 필요없지만 VCS는 설치해야 합니다. 그리고 새로운 개발자가 투입되었을 경우 환결설정을 해주어야 하는데 이는 무척 지루한 일이고 개선하려는 노력도 잘 하지 않습니다. 이를 위해 설정 스크립트를 VCS로 관리하면 편하고 개발환경에 따라 빌드가 되도록 프로파일 기능을 사용하면 좋습니다. 이후 서비스에 부하가 커지면 WAS를 여러대 사용하게 되고 서버 설정을 반복해야 하는데 이는 Capistrano를 이용하면 여러 대에 쉽게 배포할 수 있습니다.
이러한 과정은 한번에 도입해서 해결한다기 보다는 개발중에 지속적으로 발전시키는 것이 좋습니다. 이를 위해서는 개발자사이에 신뢰관계가 형성되어 있어야 합니다.
메이븐 책을 본 입장으로서는 상당부분은 반복되는 내용이기도 했습니다. 하지만 자바지기님의 발표는 대부분 많은 경험과 노력이 묻어나오는 발표라서 들을때 집중이 되고 도움이 됩니다. 이 발표는 개발경력이 많거나 회사에 프로세스가 잘 갖춰져 있는 개발자들에게는 큰 내용이 아닐수도 있지만 신입이나 아직 개발 프로세스가 정립되지 않은 조직에서는 도입을 고려하거나 생각해 볼 만한 여지를 많이 주는 발표라고 생각합니다.
Event Driven Architecture - 이미남
프로그램에는 Event Driven Architecture라고 나와있었지만 실제 발표의 제목은 The Strategic Platform for EDA (Event-Driven Architecture) Solutions였습니다. 처음에는 이벤트 드리븐 아키텍쳐에 대해서 설명했습니다. 이벤트를 사용함으로써 각 자원의 커플링을 줄일 수 있습니다. EDA에는 사이즈가 작고 이벤트간의 상관관계가 적은 Simple Event Processing부터 사이즈가 크고 상관관계도 높은 Complex Event Processing등의 모델이 있습니다. 과거의 데이터에 근거에서 패턴들을 Complex Event Processing에 넣으면 패턴을 적용해서 예측된 상황을 감지하는 형식입니다.
사실 제가 기대한 세션이 아니었던데다가 무슨 말인지 잘 이해도 못하던 관계로 대충 요약을 마무리 합니다. 저는 Nginx나 Node.js에서 채택하고 있는 최근에 Event Driven의 구조에 대한 세션으로 생각하고 들었습니다만 CEP인지 CQL인지 오라클의 솔루션에 대한 홍보세션이었습니다.(이래서 기업세션을 별로 안좋아합니다만 시간표에는 그런 내용이 제대로 안나와있어서... ㅠㅠ) 이벤트 드리븐 아키텍쳐라기 보다는 어떤 데이터를 프로세싱 모델에 집어넣으면 결과를 예측할 수 있는 엔진같았는데 이벤트 얘기는 왜 끼어든건지 잘 모르겠습니다. 다른 세션으로 이동하려다가 귀찮기도 하고 이미 늦었을 것 같아서 후반부에는 개인적인 일을 했네요.
대용량 고가용성 분산 캐쉬서버(Infinispan)를 활용한 웹서비스 - 이용혁
이 세션은 JBoss의 분산캐시서버인 Infinispan에 대한 발표였습니다. 발표전에 다음 3가지의 의미를 정의했습니다.
- 캐시 : 고속을 위해서 사용한다.\
- 웹서비스 : HTTP만 있다면 원격지의 내용을 공개할 수 있다.
- 캐시+웹서비스 : 소프트웨어 컴포넌트를 고속으로 엑세스 할 수 있다.
Infinispan의 홈페이지의 정의에 따르자면 100% 오픈소스이고 extremely scalable합니다. 이는 scale-out을 이야기 하는데 보통 100대 정도는 작은 규모로 생각할 정도의 규모입니다. 고가용성이 있고 자바로 만들어졌으며 무료입니다. 그리고 메모리에 올라가는 분산 데이터서버로 봐도 무방하답니다. Infinispan은 JSR 107에 있는 JCache를 적용했고 Replicated Mode와 Distribution Mode 두가지 모드로 사용할 수 있습니다. Replicated Mode는 모든 서버에 복사본을 생성하고 Distribution Mode는 최소 몇개의 복사본을 갖을지를 지정해서 사용합니다.
이후에는 Infinispan을 적용하는 데모를 보여주었습니다. 데모는 카테고리별로 뉴스를 모아서 보여주는 간단한 웹사이트로 데모를 위해서 자동으로 텝이 이동되면서 로딩되게 만들어졌습니다. 처음에는 각 페이지를 디비에서 가져와서 보여주도록 만들었고 이후 서비스에 이용자가 많아진 것을 가져와서 캐시를 적용합니다. ConcurentHashMap을 이용해서 로컬캐시를 적용함으로써 디비부하를 줄일 수 있었습니다. 하지만 트래픽이 더 많아지면 자연히 클러스터링을 해야합니다. 클러스터링을 쓰면 세션을 사용할 수 없으므로 서버가 죽게되면 다른 서버로 몰리면서 같이 죽어버리는 경우가 많이 있습니다. 그리고 로컬캐시의 용량이 크기 때문에 메모리를 많이 차지하고 각 서버마다 메모리가 소비되므로 효율적이지 않습니다.
그래서 외부 캐시를 적용하기 위해 Infinispan을 사용합니다. 사용자정보도 세션대신에 Infinispan에 저장함으로써 클러스터링을 할 필요도 없고 Was가 죽더라도 세션은 살아있게 됩니다. 또한 Infinispan은 자바로 만들어졌기 때문에 자바로 사용하면서 List를 통째로 저장하거나 하는 등의 장점이 있습니다.(MemCached같은 경우는 Key-Value만 저장하는 등의 제약이 있답니다.) 이후 Infinispan을 이용해서 로컬캐시보다는 약간 느리지만 디비조회보다는 빠른 데모페이지를 보여주었습니다.(말씀하신 것처럼 발표중에는 Infinispan 서버가 회사에 있어서 네트워크시간이 더 걸리지만 보통은 같은 네트워크상에 있으므로 더 빠를 것입니다.) 그리고 데모마지막에는 브라우저를 닫았다 켜도 로그인이 살아있거나 중복로그인 차단에 대한 시연을 보여주었습니다. 특히 서버 설정에서 Infinisapn 서버를 새로 추가해서 각 서버가 자동으로 서로를 인식하는 과정은 꽤 매력적으로 보였습니다.
마지막으로 Infinispan에 포함되어 있는 데모를 시연했습니다. Infinispan을 다운로드 받으면 데모가 포함되어 있습니다. bin디렉토리에 runGuiDemo를 실행하면(쉘스크립트와 윈도우용 bat을 모두 제공합니다.) 간단한 GUI 데모를 볼 수 있습니다. 분산캐시서버이므로 여러개를 실행하면 여러개가 실행되고 각 윈도우가 하나의 Infinispan 서버가 됩니다. 한쪽에서 데이터를 추가하면 자동으로 다른 서버에도 복사가 되는 것을 볼수 있었는데 Infinispan을 이해하는데 좋았습니다.
이용혁님과는 개인적으로 친분도 있어서 전에 Infinispan을 적용하고 있다는 것을 들어기 때문에 관심이 가서 들었습니다. 요즘같은 트래픽에서는 캐시서버의 중요성이 점점 커지고 있는데다가 전 캐시쪽은 잘 몰라서 최근에 괌심이 많이 갔었는데 한번 써보고 싶을 정도로 인상적이었습니다. 특히 이용혁님의 발표는 작년 MongoDB발표도 그렇고 실무에서 사용하면서의 경험을 바탕으로 하고 있기 때문에 내용이 실용적이고 도움이 많이 됩니다. 마지막 질문 시간에 왜 Infinispan을 선택했냐는 질문에 무료라서... 적용할 지 안할지도 모르는 캐시서버를 회사에서 사줄리가 없기 때문이라는 대답은 웃움이 나면서도 수긍이 가는 인상적인 대답이었습니다. ㅎ
개발자가 알아야할 오픈소스 라이선스 정책 - 박수홍
저작권에는 저작인격권과 저작재산권이 있습니다. 저작인격권은 저작자의 명예와 이익을 지켜주기 위한 것이고 저작재산권은 저작권을 통해서 재산적인 이익을 보장해 주기 위함입니다. 처음에는 오픈소스 라이센스의 역사를 설명했습니다. 과거에는 SW는 HW를 판매하면서 번들로 포함되는 것이었지만 PC가 보급되기 시작하면서 SW의 부가가치가 상승하게 되고 별도로 SW를 판매하기 시작합니다. 그러면서 미국에서 SW를 Copy Right로 보호하기 시작하자 이에 반발하여 그 유명한 리차드 스톨만이 GNU 프로젝트를 시작하고 Free Software Foundation을 설립하고 Copyleft 운동을 시작합니다. 이어서 FSF에서 GPL1.0과 GPL 2.0을 발표합니다.
이후 1998년에 Eric Raymond와 Bruce Perens가 OSI(Open Source Initiative)를 설립하고 Open Source Movemont를 시작하게 됩니다. GPL에는 반환의무가 있는데 이는 소스코드를 변경하면 다시 사회에 내놓으라는 의무입니다. 하지만 반환의무 때문에 원작자의 명예가 흩어지는 현상이 나타났고 오픈소스 운동은 저작자와 개작자를 기록함으로써 그 명예를 유지하는 운동입니다. 공개소프트웨어 라이센스 계약의 특징은 제3자가 가져가서 허락된 어떤 활동을 시작하는 순간 라이센스가 적용되게 됩니다.
GPL은 소프트웨어의 확산을 위한 것이었지만 반드시 공개해야하는 강력한 조항때문에 오히려 잘 안쓰게 되는 역효과가 나타나게 됩니다. 그래서 너무 강력하지 않은 비 CopyLeft 라이센스들이 등장합니다. 비 CopyLeft라이센스는 완전 자유이고 라이센스의 유지의무도 없습니다. 그외 Apache는 상표명만 표시하면 자유롭게 쓸 수 있고 MIT는 정말 맘대로 쓸 수 있습니다. 개발시에 가장 어려운 부분은 양립성의 문제입니다. 양립성의 문제라는 것은 2가지 소프트웨어를 사용할 때 두가지 라이센스를 모두 만족해야 한다는 것인데 이는 무척 어렵습니다.
뒷부분은 회사에서 개발을 할 때 라이센스를 어떻게 검증해야 하는가에 대한 이야기였지만 제 관심사가 아니었으므로 따로 정리하지는 않았습니다. 라이센스는 법적인 부분이라서 꽤 어렵습니다. 과거에 이에 대한 내용을 많이 찾아보았지만 제대로 정리된 내용을 찾기어려웠습니다. 각 라이센스의 세부사항에 대해서는 못 들었지만 전체적인 라이센스의 구분이나 흐름에 대해서 파악할 수 있어서 좋았습니다.(MIT가 짱!!) 개인적으로 라이센스에 대해 궁금증이 생겼을 때 해결할 수 있는 어떤 곳이 없을까 했는데 그에 대한 내용은 듣지 못했습니다.
Epilogue
중간에 한 세션은 다른 볼일이 있어서 한시간 제꼈네요. 평소보다는 여유있게 참관한 느낌이고 작년에는 발표자로 참가해서인지 올해는 약간 다른 느낌이었습니다. 저는 뭐 그럭저럭 만족은 했지만(세션중 단 하나라도 건지는게 있으면 충분하다고 보기 때문에...) 다른 사람 얘기를 들어보면 전체적인 발표의 질을 높여야 할 필요가 있겠다는 생각도 들었습니다. 그리고 무엇보다 최근 컨퍼런스나 세미나에서 느끼는건데 쉬는시간이나 점심시간이 너무 짧다는 생각을 많이 합니다. 커뮤니티 세미나도 아닌 이정도 규모의 커뮤니티에서는 10분의 쉬는 시간은 나와서 다른 세션들으러 이동하기도 버겨운 시간입니다. 많이들 신경 안쓰는 기조연설 중 하나빼고 쉬는 시간을 좀 더 여유있게 주면 다른 개발자하고 커뮤니케이션할 수 있는 시간도 더 주어지지 않을까 합니다. 그리고 발표하는 입장에서 발표를 하기로 결정했을 때 이미 발표자료가 다 만들어 진것이 아니기 때문에 쉽지 않다고 하더라도 참관자 입장에서는 당일날 세션을 변경하는 것이 어려운 일은 아니므로 어느 세션을 들을 지 선택할 수 있는 정보가 좀더 많이 제공되었으면 합니다.
Comments