1. 포럼운영자로 합류한 계기와 참여한 이유?
장기적으로 스프링과 같은 사상을 공유할 수 있는 지속 가능한 커뮤니티를 만들어보고자 하던 생각이 있었는데 이게 서로 맞게 된 것이 계기였습니다. 이유라면, 일단 한 손이라도 거들어야죠. 기술 카테고리의 커뮤니티인 만큼 KSUG는 포럼이 중심이 될 것 같습니다. 저는 기본적으로 커뮤니티가 양질의 정보를 가지고 있어야 한다고 생각합니다. 하지만 몇몇 개인의 한 때의 지식과 열정에만 의존하는 것은 바람직하지 않다고 보고 있으며, 많은 분들의 경험과 지식이 뭉치기를 바라고 있습니다.

그리고, 요즘 토비님의 퀴즈가 대세인데,  스프링에 관해 이야기하려고 해도 듣는 사람도 없고 하면 재미 없거든요. 노래방에서 곡 선택 끊긴 것 같은 거죠. 인터넷이랄 것 까지는 없어도 위키와 같은 미디어를 사용하면서 느낀 것은 꼭 무엇에 대한 모범답안을 단번에 실수 없이 내놓는 것은 구시대적 관습이라는 것입니다. 좀 틀려도 좋은 것, 이것이 서로 소통하는 문화가 아닌가 싶습니다. 온라인을 지향하는 커뮤니티로서 글로 참여하는 것이 전부인 만큼, 원활한 소통을 할 수 있도록 돕겠습니다.

마지막으로, 여러분들에게 바라는 점이 있다면, 혹여 당장 혼자서 열매를 키우지는 못하더라도 너도나도 조금씩 힘을 보태서 키워가다보면 풍성한 열매를 나누게 될 것이라는 희망을 같이 하고 싶습니다.

3. setq라는 아이디는 무슨 뜻이고, 어디서 유래한건지?
먼 옛날 천리안 가족 아이디 만들면서 급조된 거라, 사실 별 의미가 있다기보다는 형님이 elisp를 조금 하셔서 제걸 그냥 그렇게 등록하셨는데, 오래 쓰다보니 굳어져버렸습니다. 정작 저는 lisp할 줄 모르는데 오토캐드 하시는 분들이 많이 오해하시더군요. (그래서 본인도 뜻을 모른다고 하시네요. 대략의 의미는 http://www.rattlesnake.com/intro/Using-setq.html 에서 보실 수 있습니다.)

1. 간단한 자기 소개와 KSUG 포럼 개설에 대해서 할 말이 있다면?

이름은 안세원이고, 주로 사용하는 아이디는 kingori 입니다. 제작년까지는 개발을 했고, 현재는 SE 기반의 IT 컨설팅 업체에서 컨설턴트로 근무하고 있습니다. 프로세스, 테스팅, 방법론과 관련된 일을 주로 합니다.

KSUG 홈페이지는 알고 있었지만, 포럼이 생긴 것은 우연히 구글 검색을 하다 알게 되었습니다. 발등에 불이 떨어진 상태에서 도움의 손길을 간절히 원하고 있던 시점에 정말 나이스 타이밍으로 포럼이 생긴것이 저에겐 너무나 행운이었습니다. 항상 느끼는 것이지만 웹에서 검색되는 절대 다수의 내용이 매우 간단한 예제수준이라 조금만 더 실전적으로 들어가기 시작하면 벽을 느끼기 시작합니다. 포럼이 이런 실전적인 문제에 대한 토론 & 공유의 장이 되었으면 합니다. 아울러 KSUG 포럼 관계자분들에게감사를 드리고, 포럼의 많은 발전을 기원합니다.
학습중이라면 저렇게 열심히 질문을 하지 않겠죠 ^^;;

프로젝트에 적용중입니다. 프로젝트는 현재는 중형이지만 상당히 전략적이고 장기적인 plan으로 보고있기 때문에 계속적으로 규모가 커질 것으로 생각합니다.. Spring Framework은 유연성등의 기술 자체의 뛰어남 + 개인적인 욕심 + 요즘 인기있는 fancy한 기술(뭔가 있어보이는!) 로 선택하게 되었습니다. 다행히 기술 선정에 있어서의 제약사항이 없었기 때문에 최신 버젼인 2.5를 도입하였습니다. annotation 기반의 controller 를 써 보니 이거 원 너무 좋네요!
웹 개발 Framework에 대한 관심은 지속적으로 가지고 있었습니다. 전 개발을 시작한 초기부터 계속 Struts를 써왔었고, 이 외의 다른 Framework, 또 MVC 말고 ORM 쪽의 Framework에 대해서도 관심이 있었습니다. 스프링을 접하게 된 초기의 계기가 무엇인지는 잘 기억은 나지 않는데, 아마도 ZDNet등의 뉴스레터가 아니었나 생각합니다. 그러다 toby님의 블로그를 찾게 된 것이 기름을 부은 격이었죠.

현재는 개발이 주 업무가 아니기 때문에 개발 생산성과 같은 측면보다는 IoC, AOP 등의 개념이 도입된 것이 무척 흥미로웠습니다. 거기에 @Override 정도로만 쓰고 있던 어노테이션의 엄청난 활용 등 Java의 새로운 측면을 보게 된 것도 흥미로웠구요. 이런점이 스프링을 공부하게 하는 원동력인 것 같습니다.
지금은 개발이 주 업무가 아니기 때문에 사실 개발에 대해 포스팅할 내용이 거의 없어요. 지금 프로젝트는 개발과 아주 밀접하게 돌아가기 때문에 제가 직접 프로젝트 골격을 짜고, 샘플을 만들고는 있지만 다른 프로젝트의 경우는 프로세스 관련 업무를 주로 했습니다. 그러다보니 블로그에 어느새 개발내용이 무척 적어지게 되었네요. 프로세스 관련된 내용도 흥미로운 주제가 많겠지만, 게을러서 결국 신변잡기적인 내용만 남게 된 것 같습니다. ^^;

독서와 영화는 개발과도 많은 관계가 있다고 봅니다. 일단 IT책들을 읽어야 하는 것은 당연한 것이고, 그 외의 다른 책들도 기술로 지친 몸과 마음을 refresh하는 데 도움이 됩니다. 읽을 책도 무궁무진한데 게을러서 너무 안읽고 있으니 부끄럽네요.
"서브 기술"이 정확하게 무엇을 지칭하시는 지 잘 모르겠어요. 일단 Reference에 나온 모듈을 보면 다음의 내용이 무척 매력적이었습니다.

1. 선언적 Transaction 기술: 아직 JDBC connection 이상의 transaction 에 대한 고민을 하지는 않았지만, DB단 작업만으로도 선언적 Transaction 방법이 엄청 매력적입니다. 일일이 exception catch 해서 rollback하는 수고를 덜 수 있다는게 너무 좋네요.

2. DAO, ORM: iBatis와 연동하여 사용하고 있는데 DB작업이 이리 편할 수가 없네요. 또한 DB 관련한 JUnit
테스트도 이렇게 편할 수가 없습니다. Transaction에 해당하는지, DAO쪽에 해당하는 지 애매하지만 테스트 후 자동 rollback되는 것을 보고 감동의 눈물을 흘렸습니다. T_T

3. MVC: 다른 것도 좋지만 특히나 2.5에서의 annotation 기반 controller 가 너무 좋습니다. 기존 Struts 테스트하다가 httprequest, httpresponse 씨름하다 귀찮아서(^^;) 관두었던 기억과 비교해보면 지금의 POJO 기반 controller는 무지무지 테스트하기도 편하고, 유연하네요.

1. 스프링 공부는 얼마나 그리고 어떻게 하고 있나?
스프링이 내가 하는 일과 무관할 때는 많은 시간을 할당했다. 일종의 오락으로 삼았던 것 같다. 당시 학습 방법은 Spring MVC컨트롤러 탐험기 안내에 흔적이 남았다. 레퍼런스와 API 중심으로 공부하다가 이해가 안가는 부분은 소스코드를 분석해서 정리하는 방법을 취했다. 꽤 효과적인 방법이라고 생각한다.

아 이러니하게도 직업적으로 스프링과 관계를 맺은 이후로 학습 시간은 줄고 있다. 역할이 프로젝트 관리자이기도 하고, KSUG 대표란 자리도 행정적인 일을 많이 하게 되어있다. 하지만, 토비형이 주기적으로 푸시를 하는데다 내 역할이 공부를 안할 수 없으니만큼 손을 놓고 있지는 않다.

2. 스프링을 도입하려고 할 때 가장 큰 장애물은 무엇이었나?
지금은 고객들이 도입해달라고 하니까 장애물을 논하기 힘들고, 최초 도입할 때를 떠올려보겠다. 2년 전 쓴 글에 달린 댓글에 생생한 흔적이 남아있다. 관성 혹은 기득권이라고 해야 하나. EJB를 안쓴다고 하니까 무작정 반대하는 사람이 꽤 많았다. 위 댓글을 보면 당시 분위기를 느낄 수 있다.

3. KSUG 활동은 왜 하고 있나?
이 글에 서 얼핏 언급했듯이 꼬집어서 이유를 말할 수는 없다. 피부에 와닿는 이유를 대라고 하면, 토비형을 비롯한 다른 사람들과 유대를 갖는 것이 좋아서다. 아직은 그 외 다른 분들과 지속적인 유대가 약하긴 하지만, 포럼 개설을 계기로 나아질 것이라고 본다. 그리고, 무언가를 만들어내고 다른 사람고 나누는 행위 자체가 에너지를 솟게 하기도 한다.

4. 가장 좋아하는 스프링의 서브 기술 3가지와 이유를 대라.
이제는 굳이 서브 기술로 인식하지도 않을 만큼 익숙해진 DI(Dependency Injection)를 첫번째로 꼽겠다. 내가 스프링을 접한 계기는 스프링(Spring)이 객체지향 모델링이 구현으로 자연스럽게(seamlessly) 이어질 수 있는 J2EE 기술로 당시에 유일했기 때문이다. 비슷한 이유로 아직 잘 모르긴 하지만, 배포관점에서 CBD(Component-based Development)를 가능하게 할 Spring Dynamic Modules에 눈길이 간다. 그리고는 Spring Web MVC가 마음에 든다. RIA 기술의 부상으로 MVC만으로는 한계가 많다. 그러나, Web MVC 패턴 구현체로는 Spring Web MVC가 최고라고 생각한다. Spring Web MVC 소스코드는 WAF¹ 나 Struts 설계 개선 사례를 보여주는 교재로도 최고다.

5. 국내 SI에 스프링이 도입되면서 생기는 장점과 단점은 무엇인가?
장점을 요약하면 베스트 프랙티스의 보급이다. 단순히 좋은 프레임워크나 라이브러리로써 쓰이는 것 외에도 애니프레임 공개 등과 같이 문화적인 변화도 함께 도입되고 있다.

단점은 글쎄... 스프링 도입에 따른 단점은 아니고, 급작스런 보급으로 인해 책 보고 공부하면서 프로젝트에서 중요한 설계 결정을 내리는 경우가 종종 있는 걸로 안다. 소수의 결정으로 인해 많은 사람이 고통을 겪을 수 있다는 점만 명심했으면 좋겠다. 그러나, 이 문제는 스프링 보급에 국한한 문제라기 보다 신기술 도입시에 볼 수 있는 전형적인 안티패턴이다.