Younghoe.Info v3

"들을 만한 스프링 교육"이 없다고 많은 사람이 이야기한다.
시장수요에 따라 국내 교육기관이 개설한 스프링 강좌는 있다.
하지만, EJB의 기술적 제약 극복을 위한 노하우를 쌓아온 교육 기관이 아니라면
하루아침에 높은 수준의 스프링 교육을 만들 수 없을 것이다.

레퍼런스를 통해 익힌 사용법 정도만 익혀도 교육을 만들 수는 있지만
그 정도라면 시중에 나와 있는 책이나 인터넷에서 찾을 수 있는 내용을 참조하여
실습을 하면서 고민과 시행착오를 겪는 일로 대신할 수 있다.

생업이 있어 스프링만 연구할 수는 없고 우리나라에도 쓸만한 스프링 교육이 있었으면 하는 마음에
작년 JCO 컨퍼런스에 맞춰 SpringSource 컨설턴트를 초청해 스프링 공식 교육을 시도했었다.
당시 환율 상황도 안 좋아서 4일에 300만 원(?) 정도였던 교육은 최소 수강인원(6명) 미달로 열리지 못했다.

이제는 개인적으로나 기술 수요측면에서나 때가 되었다는 생각에 스프링 교육을 다시 시도하려고 한다.
단순히 스프링 사용법이 아니라 응용력에 초점을 맞춘 첫 번째 시도를 슬슬 기획하면서
소통을 하고 싶어 글을 올렸더니 의미 있는 댓글이 달려 생각을 더 풀어놓는다.


충분히 공감하지만 당장은 스프링에 대한 응용력 교육이 선행되어야 한다는 생각이다.
4월 첫 번째 스프링 교육을 기획하는 지금 처음 이프릴 세미나를 준비할 때가 떠오른다.
90분 라이브 코딩을 위해 연습할 때 가졌던 긴장감이 필요한 시점이다.

오랜만에 다시 스프링에 대한 글을 시작한다.

스프링과 AOP(Aspect-Oriented Programming) 관계는 다음 그림이 잘 설명해준다.



AOP는 기괴하다 싶을 용어와 함께 하기로 유명하다. 그래서, 비유적으로 이야기를 끌어가 보자. 위 삼각형을 도원 탁자라고 해보자. 탁자 위에는 사발과 술병이 올려 있을 법하다. 물론 탁자를 앞에 두고 유비, 관우, 장비가 앉아 있다. 스프링의 중추인 IoC는 유비에 비유할만하다. 하지만, 스프링이 EJB를 잠재우는 데에는 관우격인 Portable Service Abstractions의 공이 크다. 이제 하나 남은 AOP는 장비라 하자.

AOP는 장비만큼이나 다루기 어렵다. 보통은 으뜸가는 장수로 일당백을 한다. 하지만, 감정에 휘말려 자칫 실수를 범한다. 비유가 기막히게 들어맞는다. 보통 스프링을 처음 쓸 때는 AOP를 쓰는지도 모르고 사용한다. 레퍼런스를 따라 하다 보면, 필수 기능인 트랜잭션 처리 과정에서 자연스레 쓰이기 때문이다.

이제 비유는 접어두고 스프링 삼각형의 한 축을 이루는 AOP의 역할을 한마디로 정의하면 다음과 같다.


하지만, 스프링은 반드시 AOP를 쓰도록 강제하진 않았다. IoC 컨테이너와 AOP 기능은 소위 말하는 "loosely-coupled" 연결을 맺고 있다. AspectJ와 통합하면서 점차 강력해지긴 했지만, 초창기 Spring은 AOP에 대한 별다른 지식이 없이도 AOP를 활용할 수 있게 했다. 스프링은 AOP 적용에 있어서도 늘 그렇듯 다양한 선택을 준비했다. 그래서, 새로운 기술을 무리하게 도입하기보다는 점진적으로 활용할 수 있는 토대를 제공한다.


어느 조직이나 회사건 모든 업무에 걸쳐 발생하는 일이 있다. 기획, 영업, 구매, 회계, 총무, 경영지원 등 기능과는 다른 영역이 있다. 예를 들어 청소나 기반 제품 납품과 유지보수 같은 일은 어떤가? 최근에는 본질적 기능 외에는 전문 업체에 외주(Out-sourcing)를 줘서 전체 비용(TCO)을 줄인다.

AOP는 이러한 지혜를 순수 기술 차원에 포팅했다. 그 이름도 유명한 제록스(Xerox)가 해냈다. 지금은 다른 엔지니어와 조직에서 계승했다.

하지만, 태생적으로 본질 업무(OOP)와 다른 면이 있어서 오브젝트(object)가 아닌 애스펙트(aspect) 혹은 어드바이스(Advice)로 구분한다.

너무 비유로 흘렀는데 Professional Java Development With The Spring Framework 에 따르면 다음 사항이 AOP 적용을 통해 이익을 볼 수 있는 전형적인 사례다.

• 특정 인터페이스를 구현하는 모든 메소드(혹은 Operation)가 각기 다른 트랜잭션 안에서 수행해야 할 때
• 결과 반환에 자원 소모가 많은 경우에 빠른 응답을 위해 일정 기간 캐시(cache)를 써야 할 때
• 공유하는 DB 필드(field) 값인지라 한 쓰레드에서 변경이 발생하면, DB Lock을 걸고 바로 반영하여 I/O를 발생하기보다는 메모리에서 처리하고 필요할 때 혹은 노는 시간(idle time)에 반영하기
• 한 달간 진행하는 판촉행사를 위한 코드를 현행 코드 여기저기에 끼워 넣고 나중에 빼버리는 실수하기 위한 작업이 아니라 명확하게 구분하여 관리할 수 있게 하기

한국 스프링 사용자 모임(KSUG)을 너무 떠벌리고 다녔을까? 종종 KSUG를 존재감 있는 커뮤니티로 인정하는 말을 듣는다. 어떤 사람들은 '스프링 고수 집단'으로 보기도 하고, 더러는 '자바서비스넷'과 같은 온라인 자바 커뮤니티의 일종으로 이해한다. 전자는 토비님을 비롯한 몇몇의 면모를 통해 KSUG를 규정했고, 후자는 KSUG를 잘 모르지만 기존 체계를 이용해 규정하는 것이라 짐작할 수 있다. 흔한 경우는 아니지만, 우리를 스프링 프레임워크 개발자 커뮤니티와 동일시하는 사람을 만나기도 한다. 자기 중심적으로 세상을 좁게 보는 사람이다.

다시 측면에서 보면 아직 KSUG는 정체성을 갖고 있지 않다. KSUG를 함께 설립한 토비님이 쓴 글, KSUG는 커뮤니티인가에 나타난 고민은 여전히 유효하다. 정체성은 약한데, 존재감은 커진다. 프로그램으로 비유하면 코드는 늘어나고 기능은 커지는데, 아직 응집력 있는 클래스로 명확하게 구분하지 못해 내부적으로는 가칭의 클래스로 진화하는 꼴이다.

한 때, 나는 잘못 생각하여 존재감을 더 키워 무기로 삼고자 했다. 그 중 하나가 포럼 가입자 수에 대한 집착이었다. 후원을 받아 무언가 일을 하려면, 어느 정도의 회원수를 요구했다. 그런데 회원 수가 늘어날수록 오히려 의구심이 들었다. 비전 설정이나 현실 인식 모두가 적절하지 못했다.

이유는 달랐지만 비슷한 시점에 토비님과 나는 포럼을 버리기로 마음 먹었다. 2009년 4월 17일부로 포럼은 읽기 전용으로 묶고 메일링 리스트로 이전했다. 1400 여명의 가입자를 뒤로 하고 물갈이(?)한 결과 딱 한 달이 지난 지금 76명을 찍고 있다.

KSUG를 만들고, 첫 세미나가 2007년 6월이니 아직 채 2년도 지나지 않았다는 사실에 새삼 놀랐다. 꽤 긴 시간동안 정체성 확립조차 하지 못했다고 채근했는데, 생업에 쓰고 남은 자투리 시간을 이용했다는 점을 고려해보면 2년 동안 그래도 한 일이 적지 않았다. 좀체 보기 힘들었던 양질의 세미나를 했고, 활성화라고는 할 수 없지만 포럼도 운영했다. 기술 웹진 실험도 했고, 밀도 있는 스터디도 만들어냈다.

그리고, 새로 시작하는 느낌을 갖는 지금은 좀 더 밀도 있는 논의를 할 수 있는 토대를 쌓고 있다. 근자에 읽은 나는 빠리의 택시운전사에서 마음에 드는 표현을 찾았다. '택시운전사들 사이의 집단 연대감'. 토비님과 KSUG를 만들 때부터 우린 'User Group' 혹은 '사용자 모임'을 표방했다. 스프링 사용자는 영구적인 직업이 아니기 때문에, 스프링 사용자로서의 삶만으로는 연대감을 만들긴 힘들다.

그치만 스프링은 그저 하나의 프로그램에 지나지 않는 것은 아니다. 매년 2차례의 국제적인 컨퍼런스를 열고, 주류로 부상한 프레임워크이기도 하지만, 새로운 프로그래밍 모델, 배포 모델, 운영 모델을 논하는 이들의 위상은 과거 SUN이 J2EE 커뮤니티를 통해 하고자 했던 역할 모델을 실현한 모습이다. 하지만 스프링의 산업에서의 위상은 나에게 그리 큰 의미를 주지는 않는다. 스프링의 성공이 나의 성공은 아니니까. :)

나에게 있어 스프링은

• 한 방을 노리기 보다 끈질기고 치밀한 노력을 통해 만들어낸 결과를 보여주는 스승이고
• 일관성을 지키면서도, 지속적으로 향상하는 것이 가능함을 알려주는 표상이며
• 지금 있는 자리에서 너도 스스로의 솔루션을 찾으라는 지엄한 꾸짖음이며
  
• 심지어 언제라도 돌아갈 수 있는 편안한 안식처

이기도 하다.

KSUG에 모인 사람들은 모두 각자의 다른 삶을 살고 있고, 스프링에 대한 이해와 관심도가 모두 다르다. 우리사회의 관성을 반영하여 굳이 이를 획일화 할 필요는 없다. 오히려 차츰 서로 생각을 나누고, 각자의 '스프링'을 둘러싼 삶의 단편을 공유하다 보면 연대를 만들 수 있을 것이다.

이야기를 하다보니 감상적이 되었는데, 거창한 뜻을 가지고 메일링을 만든 것은 아니다. 그저 일상이 모여 내려진 자연스런 판단을 따랐을 뿐이다.

연대를 꿈꾸는 스프링 사용자들은 메일링을 함께 하길 바란다:
http://groups.google.com/group/ksug

아마 다음 달에 처음으로 KSUG 이름으로 스프링 교육을 할 예정이다. 계획 안은 2, 3가지가 있지만 현재 그 중 하나가 실현 단계에 있다. 유명 교육 기관에서 수행하는 스프링 교육이 만족스럽지 못하다는 이야기를 많이 들어 양질의 교육을 내놓고 싶은 욕심이 있었다. 하지만, 강사료가 적어서 고민했는데 박찬욱군이 나서서 결국은 개설하기로 했다. 강사료가 적어도 스프링 교육에선 국내 최고가 아닐까 싶다. 교육 과정은 찬욱군과 함께 내가 직접 만들었다. 노동부 지원을 통해 중소기업 재직자 대상으로 무료로 교육할 예정인데, 주말 시간에 진행할 듯하다.

6월 20일 개설하는 이번 교육을 필두로 KSUG는 여력이 되는 한 부끄럽지 않은 스프링 교육을 내놓을 예정이다. 교육을 하려는 마음은 직작부터 있었는데, 생업 탓에 여력이 없어 덮어 두었는데 '스프링 유행에 편승하여 만들어진 엉터리 스프링 교육에 피해를 본 여친'과 '내 이름과 KSUG 이름을 팔아먹는 교육이 있다는 첩보'가 결정적인 계기가 되었다.

참! 그리고 조만간 번개가 있을 예정입니다.

오랜만에 서점에 가서 책을 훑어 보는데 2가지 책이 눈에 띄었다.

하나는 ray님 추천도서 목록에서 봤던 이클립스 프로젝트 필수 유틸리티 : subversion, Ant, JUnit, Trac 이다. 필요할 때 딱 맞춰서 나온 좋은 책이다. 말 그대로 필수 유틸리티를 잘 정리했다. 책을 훑어보니 초심자가 반드시 알아야 할 내용을 적절한 수준으로 정리했다.


책에 대한 아쉬움은 아니지만, 좀 더 깊이 있는 내용을 원하거나 실무에서 문제 해결을 위해 참조하려는 독자를 위한 내용으로는 다른 책이 필요할 듯하다. 과연 그런 책이 나온다고 해도 얼마나 팔릴 수 있을지 의문이지만...

두 번째 눈에 띈 책은 SPRING 2.5 실무 프로그래밍이다. 스프링 2.5 책이라곤 하나밖에 없는 줄 알았는데 처음 보는 책이다. 전체적으로 초보자가 접근하기 좋은 흐름으로 구성했다. 저자 약력을 보니 강의 경험이 많은 베테랑인 듯하다. 예제도 어렵지 않아 처음 따라 해보기엔 좋을 듯하다. 내가 못 찾았는지 모르지만, 2.5 고유한 기능에 대한 설명은 없고, 설정은 모두 xml을 이용했다. 출판 시점에 맞춰서 판매 촉진을 위한 2.5를 붙여둔 듯하다.


서점을 나서면서 막연히 생각해봤다. 이런 책을 통해 천천히 예제를 따라 해보는 방법이 효과적인지. 배우는 이의 성향 문제가 중요하겠지만, 영어 읽기가 가능하다면 스프링 배포 파일에 들어 있는 예제를 돌려보면서 분석하는 방법을 권하고 싶다. 아마 그 정도를 해보면 위 책의 내용과 비슷한 수준의 지식을 얻을 수 있다. 물론, 영어 읽기, 스프링 레퍼런스 찾아보기, 왜 이렇게 만들었을까 고민해보는 인내의 시간을 감당해야 한다.

지인의 블로그를 보니 내가 위 책을 폄하하는 듯이 느낄 수도 있을 듯 하여 사족을 단다. 나는 이 책을 스프링을 공부하는 가까운 지인에게 추천한 바 있다. 하나의 시스템이 여러 개의 인터페이스를 갔듯 사람마다 다른 책을 원할 수 있다. 나는 스프링을 학습하는 방법으로 책과는 다른 방식을 조언했다. 위 책에서 불편하게 느껴지는 부분은 단 하나다. 스프링 2.5 고유의 내용을 살펴보기 힘든데, 2.5 라고 붙어 있어서 잠재적인 독자/스프링 사용자의 오해를 조금이나마 막고 싶었다.

이글은 SDS SW 센터 뉴스레터에 기고한 글을 허락을 얻어 공개하는 것입니다.

스프링을 통해 진화하기

요즘은 스프링 프레임워크에 대해 말하는 사람들을 흔히 만날 수 있습니다. 한동안 오픈 소스 소프트웨어에 대한 미신으로 스프링 도입이 어려웠던 상황을 생각해보면 흐뭇한 일입니다. 하지만, 아무리 좋은 도구라도 목적에 맞게 사용해야 제 구실을 합니다. 그래서, 스프링을 적용하고 있거나 배우는 분이라면 다시 한번 목표를 점검해보는 것이 어떨까요?

스프링 소스코드가 아름다운 이유

스프링의 아버지인 로드 존슨(Rod Johnson)은 최근 올린 글 Our approach to the JCP에서 Spring Source(Interface21의 새로운 회사 이름)가 자바 표준을 만드는 단체인 JCP에 임하는 자세를 기록했습니다. 굵은 글자로 쓰인 Honesty가 유독 눈에 띄었습니다. 예전에 스프링 웹 프레임워크(Spring Web MVC)를 살펴보다가 이해가 안되어서 소스코드를 찾아본 일이 있습니다. 그때 느낀 것이 정직하게 진심을 다해 코드를 작성하면 스프링과 같아지겠구나 싶었습니다.

그림 1. Strategy 패턴을 적용한 스프링 소스코드 일부

그때까지 온갖 패턴을 익히고 블루 프린트(Blue Print)와 프레임워크를 찾아 다니던 제가 그저 평범해 보였던 스프링의 진가를 보기 시작한 순간이었습니다. 동시에 정직하게 하나씩 배워가려고 하지 않고, 새로운 솔루션을 빌어 일거에 해결하려고 했던 마음이 부끄러워졌습니다. 한 순간에 사람이 바뀔 수는 없습니다. 하지만, 그 후로 스프링 곁을 떠나지 못하게 되었습니다. 저마다 다른 이유로 스프링을 대할 것입니다. 저에게 스프링은 개발자의 태도를 말해주는 경전과도 같습니다. (안타깝게도 필자는 그다지 경전에 충실하지는 못합니다. ^^)

스프링을 대규모 사이트에 적용하며

한창 스프링의 매력에 빠져 있을 때 실전에서 사용할 수 있는 기회가 왔습니다. 수백 억대 시스템 구축 프로젝트에서 스프링 도입을 허락한 것입니다. 프로젝트 수행업체는 그때 필자가 소속해있던 컨설팅 회사를 전적으로 신뢰했습니다. 그래서, 필자는 많은 부분을 직접 결정할 수 있었습니다. 스프링의 매력에 더하여 고객의 신뢰는 필자에게 엄청난 힘을 주었습니다. 누군가에게 전폭적인 신뢰를 받는다는 것이 어떤 것인지 독자 분들도 잘 아시리라 믿습니다. 그런 신뢰를 받지 못했다면 감히 스프링 적용을 시도하지 못했을지 모릅니다. 물론, 제가 단지 스프링을 좋아해서 결정한 것은 아니었습니다. 기술적인 면에서 보자면, 스프링 채택은 EJB 프로그래밍 모델을 대치하기 위한 것이었습니다. 대규모 사이트에서는 대부분 CBD 방법론을 적용하여 설계를 합니다. 분석까지는 객체 지향 기반으로 잘 끌고 와도 EJB 프로그래밍 모델에 적용시키려고 하면 설계 모델이 너무나도 복잡해지는 것이었습니다. EJB 컴포넌트는 다수의 클래스나 인터페이스로 구성되기 때문이죠. 그 무렵 필자는 TSS(TheServerSide.com)라는 J2EE 커뮤니티에 배포된 ‘The J2EE Architect’s Handbook’에서 소개한 방법을 채용하여 EJB 배포 모델과 애플리케이션 사이 종속성을 제거하는 기법을 사용하여 설계하도록 설계자들을 가이드 했습니다. EJB는 필수라고 여겼던 필자가 스프링에 관심을 가진 것은 스프링 1.2 버전이 준비될 즈음이었습니다. 그림 2. POJO 프로그래밍을 가능하게 하는 스프링의 3대 기술 ‘ The J2EE Architect’s Handbook’에서 제시한 방법보다 진보된 EJB 래핑(Wrapping) 방법을 제시하는 것 만으로도 스프링은 충분히 채택할 가치가 있었습니다. 그런데 스프링은 아예 EJB가 없어도 J2EE 애플리케이션 개발이 가능하게 해주었습니다. 또 한가지 놀라운 사실은 강력한 기능에 비해서 너무나도 쉽게 사용할 수 있다는 것입니다. 물론, 스프링 기반을 이루는 개념을 이해하는 것은 쉬운 일이 아니지만 개발자 모두가 스프링에 정통할 필요는 없으니까요. 필자는 매주 월요일 개발팀을 대상으로 스프링 기반 개발 교육을 했고 개발자들이 마주치는 문제점을 함께 고민하며 해결했습니다. 약 2.5개월로 예상했던 서버 모듈 개발은 한 달로 줄어들었고, 예상 코드 분량의 20%만으로 개발이 가능했습니다. 개발자들 대다수가 자바 개발은 처음이었다는 사실을 고려해보면 정말 놀라운 일입니다. 여러 가지 요인이 있었지만, 스프링이 제공하는 단순한 프로그래밍 모델과 강력한 지원 기능이 한 축을 차지했던 것은 부인할 수 없는 사실입니다. 분명한 목표 설정 자 이제 여러분의 차례입니다. 여러분은 어떤 이유로 스프링을 배우려고 합니까? 스프링이 제공하는 단순하고 강력한 프로그래밍 모델을 활용하여 팀의 생산성을 높이고 싶습니까? 아니면 스프링을 만들어가는 사람들을 닮아가고 싶습니까? 어떤 분 말로는 중국에서는 스프링과 하이버네이트(Hibernate)가 개발자 이력서 필수 기재 항목이랍니다. 유행은 오래가지 않습니다. 그리고, 언젠가는 스프링을 뛰어 넘는 새로운 솔루션이 등장할 것입니다. 중요한 것은 스프링이나 하이버네이트가 아니라 나 자신이 아닐까요? 누구나 스프링을 통해 도움을 얻고 발전하기 위해 스프링을 배우고 사용할 것입니다. 하지만, 목표를 분명히 한다면 보다 영리하게 스프링을 활용할 수 있지 않을까요? 스프링의 놀라운 발전속도를 보면 따라가기에도 벅차 보입니다. 그저 스프링 고수가 되기 위해서 쫓다 보면 곧 지쳐버릴 것만 같습니다. 필자 스스로 그런 생각이 들어서 잠시 멈춰서 자신을 돌아보는 와중에 같은 질문을 여러분에게도 해봅니다. 필자는 구현이 가능한 객체지향 기반의 설계 능력을 키우고 그 방안을 공유하는 것을 내년 목표로 삼았습니다. 그 목표를 위해서 스프링을 적극 활용할 예정입니다. 마치 종교인들이 경전을 읽듯이 스프링의 사상을 담은 책들을 꼼꼼하게 읽어볼 생각입니다. 그리고, 스프링 소스 코드를 통해서 프로그래밍 이디엄(idiom)과 패턴 적용에 대해서 정리해볼 계획입니다. 흥미로운 도전에 대한 계획을 세우니 벌써부터 신이 나는군요. 그림 3. 스프링 배경 철학이 닮긴 로드 존슨의 서적들

접수 페이지 바로 가기

엠파스 블로그를 사용하던 시절에 Spring MVC컨트롤러 탐험기 안내 라는 이름으로 정리를 했었다. 벌써 1년도 훨씬 지났다. 스스로 다시 한번 정리를 할겸 세미나 주제로 정했다. 게다가 지난 세미나에서 가장 많은 분들(57명)이 다음에 다뤄졌으면 하는 내용으로 꼽았다.

아직 발표를 구상할 단계는 아니지만 주로 다음과 같은 내용이 다뤄질 것이다.

• 스프링 웹 MVC가 제공하는 컨트롤러 클래스 각각의 특징
• PropertyEditor의 활용
• Validation
• referenceData() 활용
• DispatcherServlet 작동 및 다른 웹 MVC와의 연동 원리

토비님이 발표할 내용은 아직 확정되지 않았지만, 아마도 irene이라는 이름의 프로젝트 스타트킷이 될 것이다. appfuse보다 간결하고, 이클립스에 최적환 된 녀석으로 고안되었다. 오픈시드에서 처음으로 내놓는 오픈소스 프로젝트가 될 것이다. 토비님 블로그에 가보면 irene의 기반으로 사용되는 Maven에 대한 공부가 한창인 것을 확인할 수 있다.

어제 기묘 대표님이 얼핏 사용이 가능한 다른 세미나 장소를 얘기한 것 같은데, 다음에는 화면이 좀 큰 곳에서 할 수 있으면 좋겠다.

세미나를 준비한 입장에서는 참석하신 분들이 어떻게 느끼셨는지 궁금하기 마련입니다. 제가 쓴 후기보다 먼저 혹은 비슷한 시점에 올라온 글들은 역시 자원봉사에 참여했던 '주최측' AJN 친구들이었습니다. 가장 먼저 확인한 글은 후기라기 보다 갤러리였죠. 다음날도 갤러리가 또 올라왔습니다.

예전에 저처럼 엄청난 포스팅을 자랑하는 기선이가 쓴 글에선 테스트를 위한 클래스들의 긴 작명의 의미를 이해하는 기회가 되었다니 흐뭇했습니다. 역시 멀티 포스팅을 보여주는 찬욱이 글을 보곤 화면이 작았다는 아쉬움을 다시 돌아볼 수 있었다. 가장 앞에 앉아서 봤는데 화면이 작았다니...      

이프릴 사이트에서 incoming link로 제일 먼저 확인한 글은 pell님의 글이었다. 사진을 상당히 잘 찍으신다는 것을 대번에 알 수 있었고, 어느 위치에 앉아서 보셨겠구나 하는 추측을 하게 된다. 다른 사람의 시선으로 내 모습을 본다는 것이 새삼 신선했다.

(위치나 카메라로 봐서 동국님 뒤에 있는 분이 pell님이 아닐까? ㅡㅡ*)

그리고 보니, 맨 앞자리에서 캠으로 촬영하던 분이 있었는데... 어디에 활용하시려고 찍은 것인지 무척 궁금하다.

민재님도 포스트를 올려주셨다. 짧막하게 요점이 글쓴이의 관점을 잘 대변한 것이 티가 난다. 열심히 들었다는 반증. :) 미물님의 후기는 왠지 로드 존슨의 서적을 연상(?)케 할 정도로 긴 글로 일목요연하게 세미나 내용이 정리되어 있다.

Max님의 후기에선 토비형 블로그의 글을 보고 미리 예습을 하고 왔다니 놀라웠다. 사실 두 번째 세션은 어느 정도 준비가 없었다면 따라가기 힘든 내용이었는데... 참 그리고 대전에서 올라와서 바쁜 하루를 보낸 물개선생님의 후기는 120%의 호평으로 이루어져 있었다. :)

또 다른 글이 없을까 찾아보다가 대박을 찾아냈다. ^^

세미나 안내를 전날 밤에 onjo님께서 okjsp에 올린 모양이다. 늦은 공지에 대해 익살어린 불평이 미소를 짓게 했다.

• 이런, 오늘이잖아요 (ㅡ_ㅡ)++++ 강혜원 2007-04-21 23:47:11
• 저는 참가신청까지 했습니다,, 좀전에 ㅠㅠ aspt 2007-04-23 09:00:05
• 아짜증나 왜 지나고 난후에 알게되는건지1!! 널차리버릴꺼야 2007-04-23 09:54:1

세미나 끝나고 나서 참가 신청 하신 분도 있는 모양이다. :)

다음번에는 okjsp에 직접 공지를 하거나 kenu님의 협조를 받는 것을 고려해봐야겠다.