휴.. 이제 끝이다.

영회의 계략에 넘어가 KSUG운영자금 마련을 위한 스크린캐스트 제작을 시작한지 6개월. 이제 내 3회째 분량을 다 찍고 끝이다.

그러고 보니 지난 2회는 블로그에 올리지도 않았네.

2회는 SpringDM의 서비스 다이나믹스를 설명하려고 한 것인데.. 이번 여행 떠나기 전날 새벽2시까지 피곤한 가운데 간신히 제작해서 그런지 다시 보면 살짝 아쉬움이 남는다.

http://www.ibm.com/developerworks/kr/library/dwcod/20081125/

 

마지막 3회는 미국 여행중인 지금 호텔방에서 노트북으로 만들었다. 기선이 쫒아내고 30여분간 레코딩 해서 끝. SpringDM의 매력인 OSGi 인테그레이션 테스트와 SpringDM을 이용한 웹 애플리케이션 개발에 대해서 간단히 설명했다.

12월 말쯤에 공개될 예정이다.

SpringDM은 공부하면 할 수록 사실 어렵다. OSGi가 그만큼 만만치 않은 분야고, 그것을 극복하고 Spring과 JEE의 기존 방식에 최대한 가깝게 개발, 배포할 수 있게 물밑에서 엄청난 작업을 해대는 SpringDM도 그다지 간단치 않기 때문이다.

OSGi/SpringDM쪽은 하면 할 수록 툴의 중요성이 점점 크게 느껴진다. IDE와 연동된 편리한 툴의 제공 없이는 엔터프라이즈 영역을 파고드는데 어려움이 있을 것이 분명하다. Maven에서 많은 것을 지원하고 할 수 있기는 하지만 사실상 Maven사용자들이 많지 않고, 막상 제대로 Maven을 공부하고 쓰려고 해도 그 자체로 또 상당한 학습과 적용의 어려움이 있기 때문이다.

SpringDMServer가 나와서 배포에는 상당한 편리함을 제공하고 있지만, 아직 admin 기능이나 툴의 지원이 부족하다. 이번 S1A의 키노트에서 Rop Harrop이 줄줄 나열한 앞으로 SpringDM의 발전내역을 떠올려보면, 그만큼 아직은 부족하다는 생각이 들기도 한다. 갈 길이 멀다. 하지만 그리 오래 걸리지는 않을 듯. 적어도 올해초 OSGi와 한참 씨름할 때와 비교하면 지금은 엄청나게 편해진 것이 사실이니까. 여기서 한 단계쯤 더 발전하면 그야 말로 기존 JEE와 맞짱을 떠볼 수 있겠다 싶다.

 

집에 돌아가면 이제 개인적으로 제작한 이런 저런 스크린캐스트들을 좀 많이 올려볼 생각이다.

그나저나 영회는 11월에 한다고 큰 소리친 웨비나를 올해를 넘길 작정인가보다.

지난 주에 레코딩한 SpringDM  for OSGi의 첫번째 스크린캐스트가 IBM DeveloperWorks에 공개됐다. 영회의 OSGi 기초 시리즈(part1,part2,part3)에 이은 SpringDM 시리즈 3개중 첫번째이다. OSGi나 SpringDM모두 생소한 개념이고 기술적인 설명을 하자면 엄청난 분량이 요구된다. 그것을 제한된 시간의 스크린캐스트 내에서 설명하기 위해서 간결하지만 가장 핵심적인 개념과 그 구현코드를 시연하는 것을 목표로 삼았다.

첫번째 시리즈의 주제는 OSGi Dynamic Service와 SpringDM의 관계이다. 어쩌면 SpringDM이 왜 필요한가에 대한 설명일 수도 있겠다. 핵심은 POJO 프로그래밍이다. 내용은 스크린캐스트를 보면 잘 나와있다. 이번에 하고 싶은 얘기는 Spring이 OSGi의 부족한 부분을 어떻게 보완해주는 가이다. 다음번에는 반대로 스프링 입장에서 OSGi의 필요성을 어떻게 SpringDM이 충족시키는가에 대해서 설명할 생각이다.

내용에도 나오지만 기본 OSGi 번들과 서비스에 대한 개념이 필요하다. SDM/OSGi를 처음 접한다면 영회의 part1,2,3을 반드시 먼저 보도록. 혹시 부족함을 느낀다면 영어로 된 자료로 http://www.theserverside.com/tt/articles/article.tss?l=OSGiforBeginners 도 볼만하다. 내가 가장 자주 권장하는 기초 OSGi tutorial인 http://neilbartlett.name/blog/osgi-articles/ 도 적극 추천한다.

DeveloperWorks의 스크린캐스트 플레이어가 좋긴한데 화면 사이즈가 작다. 기본 사이즈에서는 1024×768화면에서 레코딩된 코딩 시연은 보기가 불가능하다. 플레이어의 Full 버튼을 이용하면 크게 볼 수 있다. 다만, 사용하는 해상도에 따라서 지나치게 커져서 역시 폰트가 뭉개지는 현상이 있을 수 있다는 것이 조금 아쉽다. 혹시 깨긋한 원본사이즈로 보고 싶은 분들이 있다면 "퍼가기"메뉴의 링크주소 안에 나와있는 동영상파일을 바로 다운 받아서 플래쉬 무비플레이어(flvplayer)나 곰플레이어 등으로 보는 방법도 있다.

SpringDM과 관련된 궁금증이 있다면 KSUG의 포럼에 오면 이런 저런 SDM/OSGi 전문가들이 있으니 좋은 정보를 얻을 수 있을 것이다.

오래전 openseed.net을 운영할 때 이미 스크린캐스트에 도전한 적이 있었다. 방법은 내가 아이디어를 냈고 진행과 제작은 물개선생으로 잘 알려진 승권이가가 맡았다.

이 스크린캐스트는 좀 독특하다. 보통 스크린캐스트는 한명의 발표자가 음성과 화면조작을 함께 수행하고 그것을 그대로 레코딩 하는 방식을 사용한다. 가끔 두명 이상이 같이 앉아서 대화를 하면서 하는 경우도 있긴하다.

그런데 이 OpenSeed 스크린캐스트는 지리적으로 멀리 떨어진 곳에 있는 세명이 Skype와 NetMeeting 같은 원격협업툴을 이용해서 교육과 실습을 진행하고 그것을 실시간으로 레코딩 한 것이다. 리더인 물개는 대전에서, 다른 두 사람은 (후에 한사람만 남은 것 같지만) 서울에 각각 다른 곳에서 진행한 것으로 알고 있다.

내용은 간단하다. 하이버네이트의 기초와 당시 사용하던 OSAF 1.0버전의 간단한 샘플을 만들어보는 것이다. 어떤 사람들은 왜 OSAF 공개를 안하냐고 투덜거리지만, 사실 이 스크린캐스트와 관련 샘플들을 통해서 이미 완전 공개됐었다.

요즘 많이 등장하는 멋진 편집화면의 스크린캐스트에 비해서 조금 초라해보일지 모르지만, 당시로는 상당히 최신기법을 이용한 흔치 않은 시도였다. 안타깝게도 오픈시드 사이트에 공개한 이 스크린캐스트에는 별로 관심있는 사람이 없었고, 별다른 피드백도 없이 그냥 소리 없이 오픈시드와 함께 사라져버렸다.

얼마전 서버를 정리하면서 발견한 이 스크린캐스트 자료들을 다시 한번 공개해본다.

내용보다는 원격 학습과 스크린캐스트를 통한 공유라는 두가지를 한꺼번에 도전한 물개와 참여자들의 용기에 한번쯤 박수를 보내주면 좋을 것 같다. 오픈소스의 나눔이라는 정신을 살리기 위해서, 나름 많은 준비와 노력을 통해서 이런 좋은 컨텐트를 생성한 물개의 노력이 다시금 인정받기를 바라는 마음에서 이렇게 다시 공개하기로 했다.

사실 혼자서 모니터 보면서 레코딩 하는 것은 조금 어색한데, 이렇게 인터렉티브한 교육을 진행하는 내용이라서 그런지 더 활기차고 재미있다. 지금은 유능한 금융컨설턴트로 이름을 날리고 있지만, 오랜동안 탁월한 강의 실력과 재치있는 말솜씨로 유명한 물개의 발표를 들어보는 것도 좋을 것이다. 요즘 developerworks에서 재밌는 시리즈을 맡아서 진행하던데, 그것도 스크린캐스트로 한번 만들어보면 어떨까 싶다.

내용이 여러개로 쪼개져 있는데, 이유는 당시에 사용하던 스크린캐스트 제작툴이 버그인지 20-30분 이상되면 PC성능에 따라서 음성이 끊기는 문제가 있어서 작게 나누어 편집했기 때문이다.

Update:
학습에 참여했던 기선이의 도움으로 당시 진행하면서 작성했던 학습노트를 함께 공개한다.

1-1. 프로젝트 관련 라이브러리 다운로드 (2)
1-2. 필요한 라이브러리들 추가
1-3. 기본 설정 하기 (2)
1-4. 모델 만들기
1-5. 모델 사용하기
1-6. 모델 클래스 수정하기
1-7. 레코드 update 하기
1-8. Hibernate Application 에서 사용되는 객체의 상태

1. 주소록 ERD
2. 주소록 ERD 수정
3. 화면 만들기
4. CSS 적용
5. 모델, DAO 까지 개발 공정
   
5-1. 모델 만들기
   
5-2. 간단한 모델 테스트
   
5-3. DAO 만들기
   
5-4. DAO 테스트 만들기 (2)
6. 연관 관계 매핑하기
   
6.1. 모델 간의 연관 관계 파악
   
6.2. 필요한 멤버 변수 추가
   
6.3. 연관 매핑 정보 입력하기 (2)
   
6.4. 연관 관계 처리를 위한 메소드 구현.
   
6.5. DAO 테스트에서 연관 관계 테스팅 (5)
7. Enumeration 사용하도록 리팩터링
   
7.1. MessengerType 클래스 작성.
   
7.2. 기존 코드 수정하기.
   
7.3. 새로운 타입으로 맵핑하기.
8. DAO 기능 구현하기 (4)
   
8.1. DbUnit 사용하기
   
8.2. HQL 공부하기
       
8.2.1. HQL 공부하기 – select절
       
8.2.2. HQL 공부하기 – where절
       
8.2.3. HQL 공부하기 – order by절
       
8.2.4. HQL 공부하기 – inner join
   
8.3. Criteria 공부하기
   
8.4. 기능 구현
9. Tag만들기
   
Tag를 만들어 쓰면 좋은 이유

텍스트로 글을 작성하는 것은 사실 쉬운 일이 아니다. 사람의 타이핑은 아무리 빨라도 말하기 보다 느리며, 또 그렇기 때문에 생각의 자연스러운 흐름을 따라서 글 쓰기는 쉽지 않다. 생각보다 타이핑 속도가 느리다 보니 생각의 흐름이 끊긴다는 말이다. 그래서 글은 쓰다보면 항상 비는 부분이 있는데 그게 아마 그 끊기는 부분을 꼼꼼히 이어나가지 못해서인 듯 하다. 그래서 나는 차라리 말하기가 편하고 더 자연스럽다. 물론 생각이 정리가 안되서 그보다 더 디게 흘러가면 그때는 말하는 것도 버벅댈 수 밖에 없겠지만.

그래서 앞으로 짧은 글이 아니고 주제를 가지고 이야기 하는 것은 스크린캐스트/동영상을 이용할 생각이다. 음성만 있는 podcasting도 나쁘지는 않지만, 실제로 해보면 화면을 함께 기록하며 이야기하는 것이 더 편하다. 왜냐하면 말로 많은 부분을 설명하지 않아도, 눈으로 보이기 때문에 빠르게 진행하는 것이 가능하기 때문이다.

직장 동료나 후배를 옆에 앉혀두고 모니터를 함께 보면서 한 10분쯤 설명하는 것을 글로 적으려면 3시간쯤 걸린다. 화면까지 캡춰해서 붙여넣으려면 더욱 힘들다. 효용면에서는 정말 별로라서, 들이는 정성에 비해서 막상 별 효과가 없다. 나중에 길게 쓰여진 글과 잘 편집된 화면이미지들을 보면서 뿌듯해하는 것 정도라면 몰라도 말이다. 그리고 종종 그 시간을 차라리 내가 공부하는데 쓰는게 낫겠다는 생각이 들기 쉽상이다.

그런면에서 스크린캐스트 + 약간의 참고글 정도가 내가 생각하는 기술정보의 기록과 나눔의 가장 효율적인 방법이다.

물론 스크린캐스트를 준비하는데 많은 시간이 들거나, 자꾸 실수를 연발해서 새로 레코딩을 해야하는 경우라면 그것이 훨신 더 힘들지 모르지만. 그래도 에러도 나고, 실수도 하는 것을 그대로 남기는 것도 그리 나쁘지많은 않은 듯 하다. 재밌으니까. 컨퍼런스 세션 발표 때도 사실 빈틈없이 완벽하게 발표하는 스피커들 보다는, 나름 다양한 예제를 라이브로 코딩도 해가면서, 중간에 실수도 하고 회중들과 함께 디버깅도 하고 그러는 모습이 훨씬 더 인간적으로 보이고 재밌는 경우도 있다. 물론 성의없는 준비때문에 그러거나, 자신도 잘 알지 못하는 내용을 대충 준비해서 하는 것이라면 그건 정말 아니겠지만.

블로그에 이런 저런 편안하게 또는 깊은 생각없이 남기는 글들 말고, 주제를 가지고 지속적으로 남길 것들을 생각한 것이 이런 스크린캐스트를 이용한 스프링에 관한 내용이다.

주제는 일단 3가지로 정했다.

첫째는 Spring Internals. 나는 스프링의 소스코드를 읽는 것을 좋아한다. 수십만 라인의 방대한 코드베이스를 가지고 있지만, 매우 정교하고 깔끔하게 설계되어있는 코드이기 때문에 깊은 지식 없이도 차근 차근 살펴보기만 하면 이해하는데 큰 어려움이 없다. 게다가 잘 설계되어있는 API구조나 내부 클래스들을 살펴보는 것은 개발자인 나에게 많은 도움이 된다. 그렇게 발견한 스프링의 내부구조나 좋은 API 클래스들을 가끔 주위의 사람들에게 설명해주곤 하는데 대체로 흥미로워 하는 것 같다. (내가 열심히 설명해주니 억지로 흥미로운 척 하는지도 모르겠다) 그래서 첫번째 주제는 스프링의 내부 설계와 구현, 기능들을 다루는 Spring Internals가 되겠다.

둘째는 OS-JEE-i이다. OSGi의 G(Gateway)는 자바엔터프라이즈의 대안기술로 떠오른 OSGi를 설명하기에는 적절치 못한 단어이다. 그 이름은 OSGi기술이 초기에 주로 가정용게이트웨이에서 사용하기 위해서 만들었기 때문으로 알고 있다. 그래서 최근에 Craig 아저씨가 OS-JEE(Java Entereprise Edition)-i라는 이름을 제안했다. 발음도 비슷하고, 그 뜻을 잘 표현하는 것 같아서 맘에 든다. 올초 JCO 컨퍼런스에서 Spring-OSGi의 발표를 했던 책임도 있고, 실제로 근시일내에 진행하는 프로젝트의 플랫폼을 Spring/OSGi로 전환하려는 연구도 하고 있으니 그 관련된 주제로 이야기 해보는 것도 좋을 듯 하다. 이 것은 또 영회의 제안으로 모 개발기술 사이트에 동영상 서비스로 제공할지도 모르겠다.

셋째는 Agile Spring이다. 애자일이란 이름은 사실 Agile Java에서 따온 것이다. 그 책을 꼼꼼하게 안봐서 왜 Agile이라는 이름을 붙였는지 정확히는 모르겠지만, 내게 있어서 Agile Spring은 테스트를 이용한 스프링학습과 점진적인 코드 발전을 통해서 공부하는 스프링의 원리라는 의미이다. 원래 애자일이라는 뜻과 비슷한지는 솔직이 모르겠다. 그런 (잘난척 할 때 쓰기 좋은) 팬시한 언어들에 대해서 사실 알레르기가 있어서 잘 안쓰는 편인데, 그래도 Agile Java 책을 살짝 보면서 느꼈던 신선한 감이 있어서 스프링 학습에 적용해보고 싶다. 그리고 사실 이건 지금 끙끙거리면서 준비하는 스프링 책의 잠정적인 제목이다. 나는 요즘 평균적인 지식을 가진 자바 개발자들에게 어떻게 스프링을 교육하는 것이 좋을지에 대해서 많은 생각과 실습을 하고 있다. 짧은 기간에 스프링을 이용한 개발을 하게 하는 방법에 대해서는 이미 많은 경험과 아이디어가 있다. 하지만 그것은 스프링을 사용하는 프로젝트에서 개발을 했다는 수준으로 끝나기 쉽상이다. 진정으로 스프링이 지지하는 가치와 개발철학을 이해하고, 그 작동원리를 알고 그리고 그 위에서 개발하는 것과, 그냥 샘플코드와 고정된 아키텍처 속에서 policy만 따라서 코딩하는 것과는 시간이 지나면 또 난이도가 올라갈 수록 큰 차이가 있다고 본다. 스프링을 사용하는 것의 중요한 장점 중의 하나는 스프링에 녹아있는 좋은 개발습관을 개발자들이 자연스럽게 받아들이고, 익숙해지는 만들어 준다는 것이다. 그러기 위해서는 스프링의 학습 방법에 좀 더 창조적인 아이디어가 필요하다. 그런 고민속에서 나름 정리한 생각들과 내용을 적는 공간을 Agile Spring이라고 만들었다.

아침부터 거창하게 소개를 적긴했지만 과연 얼마나 열심히 만들고 글을 쓸지는 모르겠다.

그래도 아무말 안하고 생각만 하는 것보다는 낫겠지.

참, 남은 고민은 시간당 100메가 가까이 되는 스크린캐스트 동영상 파일을 어디다 올릴지이다. 문제는 서버다. Torrent를 써야 하나.

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha