오래전 openseed.net을 운영할 때 이미 스크린캐스트에 도전한 적이 있었다. 방법은 내가 아이디어를 냈고 진행과 제작은 물개선생으로 잘 알려진 승권이가가 맡았다.
이 스크린캐스트는 좀 독특하다. 보통 스크린캐스트는 한명의 발표자가 음성과 화면조작을 함께 수행하고 그것을 그대로 레코딩 하는 방식을 사용한다. 가끔 두명 이상이 같이 앉아서 대화를 하면서 하는 경우도 있긴하다.
그런데 이 OpenSeed 스크린캐스트는 지리적으로 멀리 떨어진 곳에 있는 세명이 Skype와 NetMeeting 같은 원격협업툴을 이용해서 교육과 실습을 진행하고 그것을 실시간으로 레코딩 한 것이다. 리더인 물개는 대전에서, 다른 두 사람은 (후에 한사람만 남은 것 같지만) 서울에 각각 다른 곳에서 진행한 것으로 알고 있다.
내용은 간단하다. 하이버네이트의 기초와 당시 사용하던 OSAF 1.0버전의 간단한 샘플을 만들어보는 것이다. 어떤 사람들은 왜 OSAF 공개를 안하냐고 투덜거리지만, 사실 이 스크린캐스트와 관련 샘플들을 통해서 이미 완전 공개됐었다.
요즘 많이 등장하는 멋진 편집화면의 스크린캐스트에 비해서 조금 초라해보일지 모르지만, 당시로는 상당히 최신기법을 이용한 흔치 않은 시도였다. 안타깝게도 오픈시드 사이트에 공개한 이 스크린캐스트에는 별로 관심있는 사람이 없었고, 별다른 피드백도 없이 그냥 소리 없이 오픈시드와 함께 사라져버렸다.
얼마전 서버를 정리하면서 발견한 이 스크린캐스트 자료들을 다시 한번 공개해본다.
내용보다는 원격 학습과 스크린캐스트를 통한 공유라는 두가지를 한꺼번에 도전한 물개와 참여자들의 용기에 한번쯤 박수를 보내주면 좋을 것 같다. 오픈소스의 나눔이라는 정신을 살리기 위해서, 나름 많은 준비와 노력을 통해서 이런 좋은 컨텐트를 생성한 물개의 노력이 다시금 인정받기를 바라는 마음에서 이렇게 다시 공개하기로 했다.
사실 혼자서 모니터 보면서 레코딩 하는 것은 조금 어색한데, 이렇게 인터렉티브한 교육을 진행하는 내용이라서 그런지 더 활기차고 재미있다. 지금은 유능한 금융컨설턴트로 이름을 날리고 있지만, 오랜동안 탁월한 강의 실력과 재치있는 말솜씨로 유명한 물개의 발표를 들어보는 것도 좋을 것이다. 요즘 developerworks에서 재밌는 시리즈을 맡아서 진행하던데, 그것도 스크린캐스트로 한번 만들어보면 어떨까 싶다.
- 하이버네이트 기초1
- 하이버네이트 기초2
- 첫날
- 둘째날
- OSAF 1
- OSAF 2
- OSAF 3
- OSAF 4
- OSAF 5
- OSAF 6
- OSAF 7
- OSAF 8
- OSAF 9
- OSAF 10
- OSAF 11
- OSAF 12
- OSAF 13
- OSAF 14
내용이 여러개로 쪼개져 있는데, 이유는 당시에 사용하던 스크린캐스트 제작툴이 버그인지 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를 만들어 쓰면 좋은 이유
"다들 열심히 해봅시다". 이런 목표는 대부분 "하든가 말든가"라는 식의 반응 밖에 못 끌어낸다.
스스로 목표를 정하거나 또는 다른 사람에게 어떤 일을 맡기거나 요청을 할 때는 가능한 구체적일 수록 좋다. 구체적인 것이 좋은 이유는 그만큼 구체적으로 생각해볼 수 있기 때문이다.
KSUG의 "포럼운영진모집"에 관한 영회의 공지를 보면서 들었던 생각이다.
이런 식의 모집 또는 공고가 얼마나 서로를 쉽게 오해하게 만들고 피곤하게 하는지는 openseed.net을 운영하면서 많이 경험해 보았다.
만약 어떤 회사가 연봉, 근무조건, 해야 할 일과 책임에 대해서 전혀 설명하지 않은채 "우리 회사에 와서 열심히 일할 개발자를 모집합니다. 열심히 하면 회사경영에 일정 참여하도록 해주겠습니다."라고만 한다면 과연 누가 선듯 나서겠는가.
텍스트로 글을 작성하는 것은 사실 쉬운 일이 아니다. 사람의 타이핑은 아무리 빨라도 말하기 보다 느리며, 또 그렇기 때문에 생각의 자연스러운 흐름을 따라서 글 쓰기는 쉽지 않다. 생각보다 타이핑 속도가 느리다 보니 생각의 흐름이 끊긴다는 말이다. 그래서 글은 쓰다보면 항상 비는 부분이 있는데 그게 아마 그 끊기는 부분을 꼼꼼히 이어나가지 못해서인 듯 하다. 그래서 나는 차라리 말하기가 편하고 더 자연스럽다. 물론 생각이 정리가 안되서 그보다 더 디게 흘러가면 그때는 말하는 것도 버벅댈 수 밖에 없겠지만.
그래서 앞으로 짧은 글이 아니고 주제를 가지고 이야기 하는 것은 스크린캐스트/동영상을 이용할 생각이다. 음성만 있는 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를 써야 하나.
Prev
Rss Feed
