문제 제기

일단 의견은 내지 않겠습니다.

스터디든 다른 형태로든

현 상태의 교통 정리를 위해서

1,2,3 기 모든 분들의 의견을 받습니다.

기수별로 따로 스터디나 여타 다른 활동을 하든
모두 모여서 통합 스터디를 하든
파일럿 프로젝트를 하든
시험준비를 하든,,,
몇개의 팀으로 재 조직을 하든,,,,

모든 의견 다 받습니다.

소중한 의견 부탁 드립니다.

글쓴이 : 장회수

다양한 의견들

김형준

제가 요즘들어 많이 느끼는 것은 단순히 프로그램과 관련된 기술적인 부분에 대한 학습보다는 IT의 여러 분야중 한 분야에 집중하는 것도 좋지 않나 생각합니다.
저 같은 경우만 봐도 10년 정도 개발을 했지만 어디 하나 딱히 내세울게 없는게 현실입니다. SI 프로젝트 여기저기 다녀보 고, 기타 등등 많은 시스템을 만들어 봤지만 그래도 나름대로 주특기가 있어야 한다는 것입니다. 자바, 웹 이런거는 주특기라고 할 수 없죠. 시대의 흐름에 따라 지나가는 거죠.
제가 요즘 분산컴퓨팅보면서 느끼는 것은 정말로 IT라는 것이 할것도 많고 영역도 넓다는 것입니다. 이런 넓은 바다에서 시원하게 헤엄쳐 다닐수 있는 자신들만의 주특기를 쌓기 위한 기본 지식을 습득하는 방법을 하는 것을 제안합니다.
너무 추상적이라면 간단한 예로 "검색엔진", "네트워크 프레임워크", "메모리기반 데이터베이스", "파일시스템", "보안", "ITSM", "CMM" 등 다양하겠죠. 프로그램은 이런 것들을 하기 위한 도구라고 생각합니다.
이상 생각나는데로 좀 적어 봤습니다.

장회수

이런 방향은 어떻습니까?

파일럿이나 여타 다른 형태는 제쳐두고

일단 스터디를 한다고 생각한다면
같은 내용을 가지고 몇개의 팀으로 나눠서 스터디를 하는거요.

물론 주제는 모두 모여서 토론 해 봐야겠지만,
제 생각은 조금더 추상적인 영역도 괜챦고
조금더 기초적인 내용도 괜챦으리라 생각이 됩니다만,

의견 빨리 빨리 많이 많이 올려주세요.

강현수

사람에 따라 선호하는 것과 처해 있는 상황이 모두 다르니
스터디, 파일럿 프로젝트, 형준이가 제안한 한 분야의 지식 습득 등
모든 문을 다 열어놓았으면 합니다.

스터디를 한다면 어떤 것이든 기초부터 심화학습이 되었으면 좋겠고
파일럿 프로젝트라고 하면 정말 실무에서 바로 적용할 수 있는 제대로된 프로젝트를
목표로 해보는건 어떨까 싶습니다.
새로운 분야의 지식 습득이라고 하면 보다 길게 계획을 잡고 기초부터 심화까지
일관성있는 학습을 해보면 좋겠습니다.

김민재

스터디 모임에서 스터디가 가장 중요하겠지만, 투명한 운영에 대한 룰이 멤버의 공감대로 이어지는 부분 또한 중요합니다.
다른 기수는 모르겠지만, 3기의 경우 일관된 정책(회비 사용 문제 등)이 다소 미흡하지 않았나 반성해 봅니다.
잭 웰치 자서전 "끝없는 도전과 용기"를 읽고 있는데요.. 'Superficial Congeniality(피상적인 일체감)'를 드러내고 개선해야 한다고 봅니다.
또한 자바지기 한사람의 컨디션이 자바지기 사이트의 건강에 대한 바로미터가 여전히 되고 있다고 보는데, 커뮤니티를 형성하는 멤버들이 모두가 제 목소리를 낼 수 있도록 유도하는 방안이 필요하다고 봅니다.
오픈 커뮤니티에 관심을 가지는 사람들은 기본적으로 마음이 열려 있습니다. 하지만 potential로만 남아 있으면 안될거라는 생각이 드네요.

이상협

대부분 다음 스터디에 대한 생각은 비슷할 거란 생각이 듭니다.
김형준님(인사를 제대로 못해서 아직 형이라고 부르기가ㅎㅎ 담에 만나면 인사하고 형이라고 부르겠습니다^^)께서 이야기하신 방법에 플러스를 하여 이루어질 수 도 있을거란 생각이 듭니다.
그러던 중에 생각난 것이 있어 적어봅니다.
먼저, 프로젝트 팀을 관심별로 만들어(기수별로 해도 괜찮을거 같습니다) 중간에 발표 및 진행 사항에 대해서 위키에 올립니다.
그리고 마지막 쯤에 프로젝트 팀별로 발표를 통해서 나름대로의 순위를 붙여 분기별 정도로 시상식도 하는 겁니다.
그래서 정말 좋은 프로젝트이고 잘 진행되었다면 오픈소스로 발전을 시키는 계기가 될 수 있을거도 같고, 다양한 분야의 지식과 기술을 배울 수 있지 않을까? 생각해 보았습니다^^

김형준

또 접니다. ^^
Web2.0이라고 요즘 많이 회자되고 있는데 Web2.0을 우리 개발자들은 기술적인 관점으로만 바라보고 있지만 개발자들보다 돈을 더 많이 벌고 있는 기획, 마케팅 하는 친구들은 다른 측면에서 바라보고 있습니다. 그것은 웹을 사용하는 사용자들의 적극적인 참여와 토론, 재미, 집단 지성 등등... 웹이 아닌 사회학적으로 측면으로 바라보고 있는 것입니다.
여러분들이 경이로운 또는 참여하고 싶어하는 오픈소스 프로젝트 역시 이런 맥락과 같이 한다고 볼 수 있습니다. 눈팅으로만 읽고 지나가시는 분들이 있다면 한줄이라도 자신의 의견을 적어 보시기 바랍니다. 그런 작은 의견, 기술, 생각들이 활발하게 온라인 상에서 주고 받을 수 있어야 스터디가 활성화 된다고 봅니다.
지금같은 이런 온라인 문화에서는 어렵다고 생각합니다. 직장에 얽메여 있는 특성상 많은 부분을 온라인에서 해결해야 하는데 이런 상황에서는 어렵다고 봅니다.
이 글을 읽으신 분이라면 위에 있는 Edit 탭을 꾹 누르세요 끝.

류성희(다찌)

(흐음.. 횡설수설하지 않고 잘 정리해서 말씀을 드려야 할 터인데용.. 홍홍홍)

가장 먼저 생각해볼 문제는, 커뮤니티에 참여하시는 분들의 열정은 재쳐 두고라도 커미터의 역할을 할 수 있는 만큼의 실력과 시간이 있느냐는 것입니다. 프로젝트를 진행한다는 것은 결코 쉬운 일이 아닙니다. 또한, 프로젝트의 특성상 몇몇 주도적인 사람들을 중심으로 운영되기 쉽지 않다는 것을 많은 분들이 공감하실거라 생각합니다. 한두주의 차이가 더이상 프로젝트에 발을 담그지 못할 정도의 차이를 만들어 낼 수도 있습니다. 모든 분들이 100% 공감하고, 100% 참여해 주신다면 그만큼 훌륭한 케이스도 없겠으나 다들 바쁘시니깐요. ^^;

두번째.. 잘 알지 못하는 스킬을 프로젝트에 접목시키려다 자초되기 쉽상이라는 것이죠. 물론, 한번이라도 코딩을 해보는것이 가장 빠른 길이겠지만, 예제를 코딩해보면서 원리를 꿰뚫어 가는것과, 무작정 프로젝트에 접목시키는 것은 큰 차이가 있습니다. 말그대로 막코딩이 되는 것이고, 강제성이 없는상태에서 무한한 열정없이 프로젝트를 마무리 짖기란 어렵지 않을까요? 적어도, 예제코드는 충분히 숙지한 다음 프로젝트로 진행되는 것이 맞지 않을까라고 생각합니다. 때문에 "심화학습"에 대한 스터디 주제를 강력히 주장하는 바입니다.

세번째.. 다른 오빠들 말씀처럼.. 스터디의 주제와 정체성입니다. 이 부분은 결국 스터디를 이끄시는 주인어른이신 재성오빠의 몫이라고 생각하는데요. 다들.. 별 말씀이 없으신것은.. 최초 발제자의 의견을 들어보고 싶어서 일지도 모릅니다. 발제자의 의견에 동감하는 사람은 스터디에 남아 그 뜻을 따를 것이고, 동감하지 않지만 함께 하고자 하시는 분들은.. 왜 동감하지 못하는지 자신의 의견을 필히 남겨주시리라 생각합니다. 커뮤니티 발제자가 어떠한 방향을 원하는지 먼저 밝혀 주심도, 공동 주체자들이 의견을 좀더 쉽게 게재 할 수 있도록 하는 하나의 방법이 될수도 있습니다.

솔직히 의견을 말씀드리는 저도 이건가 저건가.. 헛갈리네요. 프로젝트를 하자고 하시는 건가.. 아님.. 1,2,3기 통합 스터디를 하자고 하시는 건가.. 아님.. 다시 기수별로 하자는 말씀이신건가.. 라는 거죠. 저 뿐이겠냐.. 싶습니다. 솔직히.. ^^; 다들 좋은 분이시고, 이 모임이 계속 이어지기를 바라는 마음입니다. 형태가 어떤 형태가 되었든.. 최대한 끝까지 함께 하고 싶은 마음인거죠.
초석을 다지는 기간에는, 끌어주시는 분들의 어려움이 많다는 것을 알고는 있지만, 말 그대로 초석을 다지는 기간이므로 아직까지는 이 모임이 어떻게 흘러가는지 지켜보고 선택하고자 하시는 분들도 있으실 겁니다. 주체적이지 못하다하여, 열정이 없다는 건 아니라고 봅니다. 열정이 분출되는 각자의 시기가 조금씩 다를 뿐이라고 생각하구요. ^^ (으흐흐흐.. 2기분들 모두.. 스터디를 이어가고 싶어 하십니다용~ ^^*)

마지막으로, 다찌의 의견을 정리해 보자면...
"프로젝트는 아직 이른거 같다. 좀더 집중적으로 심화학습을 단행한 다음에 프로젝트를 해도 늦지 않다.
허나, 다수의 의견이 프로젝트라면 그것도 좋다. 뭐든 함께 하고 싶은게 결국 나의 속마음이다."
라는 의견과
"주인장님께서는 하루빨리 커뮤니티의 주제와 정체성을 밝혀달라"
입니당~ ^^*

장회수

몇가지 생각하고 있던 안이 있습니다.
프로젝트를 수행하는 형태로 한다.... 제 개인적으로는 땡기지 않습니다.
제 개인적인 성향은 토론문화를 좋아하는 겁니다. 그 와중에 제가 가지고 있는 공격적인 성향을 고치기위함도 있겠죠.. ^^
2년정도 전부터 하고 싶었던 모임이 있었습니다.
스터디 그룹을 결성하는 거였죠.
1년정도의 커리큘럼을 가지고 쭈욱 가보는 거였습니다.
열정적으로.
다만 제 능력의 capablity가 되지 않아서 주저주저 하고 있었던 거죠... 언젠간 꼭 하고야 말겁니다. ^^
티칭 그룹을 결성하든, 스터디 그룹을 결성하든,, 흐흐흐

자바지기 1기 스터디의 경험을 통해 매우 많은 것을 느꼈습니다.
그리고 개개인으로 인해서 배운점도 많았습니다.

지금까지 몇가지 의견이 나왔는데요.
제 생각을 말씀드리자면,

1. 팀단위로 무언가를 한다는 것중...
가상 프로젝트를 수행한다... ^^ 말씀드렸듯이 개인적으로는 힘들어서 별로 땡기지 않습니다.

2. 심화학습을 한다.... 이부분에 대해서는 매우 해야 할 일들이 많다고 생각이 됩니다.
먼저, 현재 이렇게 간단하게 의견을 묻는 글 하나에도 답변글이 이렇게 없는 것을 보면 시도해도 전혀 호응이 없을것으로 보입니다.
두번째, 각 모임을 제기하는 이들도 있어야 하겠고 그 모임을 구축해 나가는 데 있어서 현재와는 새로운 패러다임 이므로 조금더 많은 이들의 열정이 필요하리라 보입니다.
세번째, 그에 따라 희생도 있어야 하겠죠. 물론 하는 이들은 희생한다고 생각하지 않는 분위기가 중요 할테구요.

3. 올해 말까지라고 제가 박았으므로 이 말에 대한 책임을 끝까지 지고 나가도록 하겠습니다.
2007년이 되는 시점에서 나온 의견중에서 다수의 의견( 다수결이라.. 좀 그렇죠? ㅋㅋ) 을 채택하여 무작정 공지 하겠습니다.
이것이 싫으시다면 1기, 2기, 3기 분들중에서 다른 의견과 계획이 있으시다면 말씀하여 주시기 바랍니다.

개인적으로 심화학습 내지는 커리큘럼을 가지고 하는 롱타임 스터디를 사랑합니다. 흐흐흐.

Kenny

이쪽에는 잘 안남겼었지만.. 지나가다가 한마디 남깁니다.
1-3기 스터디를 "구경만" 한 사람 입장에서는.. 뭐랄까.. 관심과 집중 부분에 있어서, 좀 산재한 느낌입니다.
Spring을 잘 쓰는건 좋지만, 한정된 시간 안에 Spring 보랴, Hibernate 보랴, 익숙하지 않은 JMX보랴.. 잘 사용하지도 않을 JMS 보랴..
제 관점에서는.. 저작권법 위반이겠지만서도, 관심 있으신 분들 (특히 1기 분들) 끼리 모여서, 스터디용 교재를 한번 만들어 보시는건 어떨까 합니다.
2007년 3~5월 정도 까지 6개월 정도의 커리큘럼으로, 좋은 책들의 좋은 부분(모든 책을 다 볼 수는 없으니까요.)을 모아서, 짜집기 형태로 스터디 교재를 한번 만드시고,
교재를 업데이트 해 나가면서, 다음번 스터디에서는 직접 만든 교재를 가지고 진행을 하시는것도 방법일 듯 합니다.
교재라는게, 결국은 책 같은 거라, 어디서 부터 어디까지, 기한은 이정도 라는 선을 가지고 만든다면, 그것도 보통 오래 걸리는게 아닐테니까요.
그런 작업을 하면서 범위와 집중, Framework을 논할건지, BDD같은 기법을 논할건지, XP같은 방법론을 논할건지에 대해서 좀 더 깊게 생각해 볼 수 있을 듯 합니다.
스터디 멤버들의 자부심 같은 것도 높일 수 있을듯 하고요.

어제 OKJSP 송년회의 여파로... 횡설수설이네요.. ^^;;

장회수

공부 하려고만 하면~~~

주제들은 얼마든지 있습니다. 그렇죠 좋은 책이 얼마나 많은데요~

정신병원에서 뛰쳐나온 디자인 ( http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200408250003 )
소프트웨어 프로젝트에서의 리스크 관리 ( http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200409040001 )
데드라인 : 소설로 읽는 프로젝트 관리 ( http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200402190001 )
Rapid Development : 프로젝트 쾌속 개발 전략 ( http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200307150010 )
테스트 주도 개발 : Test-Driven Development ( http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200412020003 )
Refactoring(마틴 파울러, 대청, 2002)
테스트 주도 개발(Test-Driven Development by Example) (켄트벡, 인사이트, 2005)
Refactoring Workbook(William C. Wake, Addison Wesley, 2004)
Refactoring to Patterns (Joshua KErievsky, Addison Wesley, 2005)
이클립스 활용 가이드 : 원리와 패턴 그리고 플러그인
Prefactoring
개발자도 알아야할 소프트웨어 테스팅 실무
오브젝트 디자인(http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200404060001)
DDD(http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200306050028)
Holup On Pattern( http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200607180006 )
POSA1(http://kangcom.com/common/bookinfo/bookinfo.asp?sku=199903270017)
Rapid Development : 프로젝트 쾌속 개발 전략 ( http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200307150010 )
Working Effectively with Legacy Code ( http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200410110002 )
Implementation Patterns ( http://www.amazon.com/gp/product/0321413091/ref=pd_ys_cs_all_2/002-2087185-6422421 )

등등 주제꺼리 될만한
토론꺼리 또는 학습주제 또는 기술중심의 좋은 책들은 얼마든지 있습니다.

다만, 우리에게 필요한것은

열정과 하고자 하는 의지 이고
무엇보다 절실한 것은 방향성의 결정입니다. ^^