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

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

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

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

1. '포럼에서 삭신이 쑤시도록 놀았다 하셨는데' 간단한 자기 소개와 KSUG 포럼 개설에 대해서 할 말이 있다면?
자바, JEE 영역만 한지도 벌써 5년째 돼 가고 있습니다. 그렇다고 해서 다양한 아키텍쳐의 현장을 접해보지는 못했습니다. 차라리 오픈소스 스프링 프레임워크를 보면서 많은 것을 정리하게 된 것 같습니다. 지금은 회사 내에서 프레임워크 기술 지원을 하고 있습니다. 개발은 잘 못하지만 손발이 편한 것은 추구합니다. 스프링을 비롯해서 많은 도구들 (특히 오픈소스)이 그런 데 있어 여러 모로 도움을 준다고 생각합니다. 하지만 온라인으로 무엇인가를 준다는 생각은 못해본 것 같습니다. 기껏해야 남의 등 떠밀어서 위키사이트 오픈한 것 밖에는 없습니다. 인터넷 첫 걸음이라고 한 꼬릿말 처럼 저에게 인터넷은 아직도 생경한 존재입니다.

기술인력이라고 단순하게 몰아가는 암울한 분위기 속에서, 명료한 표현 방법을 가진 사상가들은 그 존재만으로도 그들을 접하는 사람들에게는 동경의 대상이 되고 큰 힘이 되는 것 같습니다. 그리고 그 사상가들 주변에는 수많은 실천가들이 또 있지 않겠습니까? 그래서 참여할 뿐입니다. 에르되쉬 수와 비슷한 맥락이라고 볼 수 있겠습니다.
자바를 처음 접했다고 해야 하나, 자바 웹 애플리케이션을 처음 본 게, 외산 솔루션 패키지를 커스터마이징하면서 팔아먹을 때였습니다. 마침 그 때 본 것이 서블릿 코드 안에 프리젠테이션과 컨트롤러가 들어가 있는 구조였고, 모델은 별도의 바이너리로 패키징되어 있었습니다. 패키징이나 라이센스 문제에 대해서 조금씩 인지하게 됐던 때라고 볼 수도 있겠습니다. 자바 자체도 처음 보는 것이어서 Java Language spec을 참 많이도 들여다 봤습니다. 그러다가 자체 솔루션을 하나 만들 일이 있어서 프레임워크를 갈아치웠는데, 이 때 Struts1.1이 있었고 Spring 1.0이 나오려고 하던 때였던 것 같습니다. JDBC API를 직접 쓰는 코딩 스타일만 보아 오다가 Spring에서 홍보하는 주요 부분이 그것에 관련되어있고 일단 깔끔하고 튼튼해보여서 집어들었습니다.

스프링을 처음 접할 때는 수많은 오픈소스 프로젝트 중의 하나였습니다. 물론 지금도 그렇습니다. 아직 구글쪽의 행보도 관심있게 보고 있습니다. 마땅히 국내에서는 물어볼 곳도 없긴 하지만 문서들이 잘 나와있는 편이고, 특히 레퍼런스 문서는 예술입니다. 그 외 특이사항들에 대해서는 구글링을 통해서 빠르게 문제를 해결해나갈 수 있었습니다. 소스 코드도 노출을 의도한 부분들은 참 읽기 쉽고 깔끔하게 작성되어 있습니다.

도입 과정은 직접 사이트 들어가서 개요를 재빨리 살펴본 다음 배포본을 받고 가이드 문서를 탐독하면서 필요한 것을 하나씩 적용시키는 식으로 진행했습니다. 스프링의 특이한 점은 다른 오픈소스 프레임워크나 인프라스트럭쳐 모듈들을 딱딱 잘도 갖다 붙인다는 것이었습니다. 덕분에 모르던 것도 많이 들여다보게 됐습니다. 한동안 골치였던 오픈소스 라이브러리 선택과 관리의 문제도, 스프링 배포본이 워낙 잘 되어있기 때문에 개인적으로 위임시켜놓은 상태입니다.

하지만 그중에 가장 중요한 건 매일 급박하게 돌아가는 프로젝트 속에서도 여유를 즐겼던 게 가장 핵심이 아니었나 싶습니다.아직은 없고요, 이제 곧 쓰게 될 것 같습니다. 그것도 개발 형태가 아닌 컨설팅으로 말이죠. 사실 적잖이 난감한 부분입니다. 포럼에도 남겼듯이 모 프로젝트에서 그쪽 관련 JEE 스펙이나 공개된 모듈이 마땅한 게 없어서 그냥 가내수공업으로 만든 경우는 있습니다. 일이 진행되면서 배치라는 부분에 대해서 개념적으로 공감대가 많이 형성되지는 않았다는 것을 느꼈습니다. 저도 아직 구분이 명확하지는 않는다는 게 문제이긴 하지만 대체로 스케쥴링 솔루션하고 자꾸 헷갈려하시는 듯한 인상이었습니다.
그 전에 잠깐 말씀하실 때 보니 "배포"에 대한 맥락이 서로 달랐던 것 같은데 답이 될지 모르겠네요. 상황은 이랬습니다. 동일한 웹 애플리케이션 패키지를 빌드해서 백 여개 사이트에 바이너리 배포해야 했었습니다. 일부 회선은 또 무지 느렸습니다. 일부 모듈만 바뀌는 경우에 빠르게 변경사항을 적용할 수 있어야한다는 점도 문제가 됐고요. 사실 당시에는 스프링은 별 도움 안됐습니다. 도리어 빌드 / 배포에 신경 무지하게 쓰게 만들었다고 해야 할까요. 통합 빌드 할 때마다 개발자 전체가 밤을 새더군요. 빌드 스크립트 작성해놓고 CI 돌려놓고 모니터링만 시켜놓으니 언제 그랬냐는 듯이 지나가더군요. 자꾸 옛날 문서만 뒤지는 것 같지만 Sun의 자바 패키징에 관한 문서가 많이 도움이 됐습니다.

아무 생각 없이 IDE에서 컴파일 된 대로 was 에 파일 복사해서 실행하던 데서 벗어나서 패키징 및 버저닝의 필요성을 느끼게 된 때가 이 때였습니다. 모듈화에 대한 욕심도 생겼고요. 지금 한다면 SpringDM을 이용했을 것 같습니다만, 그 때는 클래스로더를 새로 만들어서 어떻게 해볼까 고민했지만 답이 안나오더군요.
어이쿠 이건 저희 팀 장차장님이 얘기하셔야할 부분 같은데. JCF의 J는 자바고 F는 프레임워크의 앞글자이긴 한데, 지금은 활동 범위를 이름에 제약받지는 않으려고 하고 있습니다. 간단히  말씀드리자면 프레임워크 부문은 지금의 애니프레임과 같은 모양을 구상하고 있었습니다. 우연인지 모르겠지만 사용하는 도구도 하고많은 것 중에 저희와 동일한 것들을 많이 이용하더군요. 어찌나 친숙한지. ^^

하지만 요즘은 뭔가 코드를 남긴다는 것 자체는 별 의미가 없는 것 같고 개발 활동에 필요한 갖가지 환경을 제공하는 것으로 현재 방향을 잡고  있다는 것만 말씀드릴 수 있겠습니다.