스터디 모임으로서의 개발팀 |
 |
 김재석 shinvee@lunant.net
현재 Lunant 야간개발팀을 운영하며 취향 공유 서비스 VLAAH(http://vlaah.com/)를 만들고 있다. 좋은 서비스를 즐겁게 개발할 수 있게 도와주는 개발 방법론에 관심을 두고 있다.
2009년 9월 15일 |
|
|
|
뭔가 만들어보고 싶긴 한데, 불안해서 말이지
얼마 전 절친한 친구가 내게 상담을 요청해왔다. 이 친구는 나름 개발 경험도 있고 공부도 많이 했지만 아쉽게도 뚜렷한 경력이 없었다. 이 친구는 나처럼 친구와 함께 개발팀을 만들어 무언가를 개발해 보고 싶어했지만, 그 일에 드는 시간에 대해 부담을 느끼고 있었다. 친구 자신뿐 아니라, 설령 친구가 하고 싶다고 해도 같은 이유 때문에 주변에 모이는 사람도 없다는 점이 문제였다.
요즘처럼 취업이 어려운 시기에 다른 친구들이 하는 것들을 따라가기도 벅찬데, 시간 허비가 아닌가 하는 걱정이 드는 게 그다지 이상한 일은 아니다. 이번 글은 이러한 고민을 해결하는 데 도움을 주는 글이 되었으면 좋겠다.
개발팀이라기보다 스터디 모임이라고 생각하면 어떨까?
필자는 이런 고민이 있는 사람들에게 항상 개발팀이 아니라 스터디 모임으로 생각해보라고 전해준다. 취업난 속에서 특별한 능력을 얻으려고 많은 사람이 스터디 모임을 결성해 다양한 학습을 함께 한다. 다국어 학습 스터디, 사례 분석 스터디 등 다양한 스터디 모임이 있는데, 개발팀도 이처럼 실전 개발을 대비하는 스터디로 바꿔 생각하는 것이다. 이전 글에서도 짧게 전달했던 내용이지만, 내가 참여하는 야간개발팀 역시 스터디 모임으로서의 개발팀 형태로 출발한 셈이다.
스터디 모임으로서의 개발팀은 일반 개발팀과는 방향이 조금 다르다. 스터디 모임에 참여하면서 잃는 것보다 얻는 것이 항상 큰 것처럼, 개발팀 참여도 잃는 것보다 얻는 것이 더 커야 한다. 이를 위해선 단순히 아는 지식과 기술을 이용하는 선에서 끝내는 것이 아니라, "새로운 지식을 배우고 그것을 적용한다는 흐름"이 기본이 된다. 그래야 개발팀이 만든 작품의 성공/실패 여부를 떠나 잃는 것이 없기 때문이다.
스터디 모임으로서의 개발팀은 어떤 장점이 있을까? 첫째로 일반적인 스터디 모임의 장점을 모두 이어받으면서, 더 효과적인 학습을 할 수 있다. 보통 이론 학습을 진행하다 보면 책으로만 읽고 넘겨 해당 지식을 단편적으로 받아들이기 때문에 실제 상황에서 간혹 활용하지 못하는 일이 발생하지만, 개발팀에선 공부 후 이를 바로 실전에 적용하므로 훨씬 깊이 있는 학습을 할 수 있다.
그러면서 일반적인 스터디 모임보다 차별화되는 점은 개발하는 작품의 실용성에 있다. 스터디 모임으로서의 개발팀은 일반 기술 스터디 모임보다 더욱 개발 대상에 신경을 쓴다. 이는 조금 더 많은 집중이 필요하지만 그에 대한 대가는 비교할 수 없이 크다. 만든 작품을 공개하고 나면 공부하는 당사자들의 자기만족을 넘어 사용자의 피드백을 통해 더 큰 보람과 자극을 얻기 때문이다. 개발한 작품이 유료라면 이를 통해 수익을 획득하여 공부하면서 되려 돈을 버는 행복한 상황을 맞이하기도 한다.
마지막으로 스터디 모임으로서의 개발팀 활동은 많은 대학생의 궁극적 목표인 취직에서도 이득이 된다. 단순 공부용으로 만든 작품은 포트폴리오에 넣기 어려운 경우가 많지만, 개발팀의 실용적 작품은 넣기 쉽기 때문이다. 특히, 만든 작품을 입사를 원하는 기업의 일원들이 이용 중이라면 우리의 포트폴리오는 훨씬 주목 받을 것이다. 이쯤 되면 조금 과장하여 일 타 몇 피인지 세기도 어려워진다.
물론 신경 써야 할 일도 많다.
필자가 제안하는 형태가 항상 그러하듯이, 이 같은 형태가 장점만 있는 것은 아니다. 하지만 단점을 알고 이를 적용한다면 충분히 얻을 것이 많으리라 확신한다. 첫째로, 개발이 정말 중요한 시점이라면 학습을 반드시 해야 하는 형태는 방해요소가 된다. 그러므로 학습 목표에 벗어나는 부분은 적절히 아는 지식 안에서 해결하는 융통성이 필요하다.
둘째로 개발 대상을 선정하는 데 있어 견해차가 벌어지는 경우가 있다. 각자 만들고자 하는 것이 다를 때 꽤 자주 부딪히는 일이다. 이에 대해서는 중요한 시작 아이디어를 내는 사람을 한정하는 것이 좋다. 애초에 팀을 모으기 이전부터 중심 인원이 기본 아이디어를 구체화해 놓는 것이 그 예가 되겠다. 독립개발팀으로서 배우면서 참여하기 좋은 아이디어를 찾는 방법은 이후의 칼럼에서 좀 더 자세히 다루겠다.
특히 팀을 운영하는 처지라면 이 개발팀이 스터디 모임의 관점으로 볼 때 어떠한 공부를 할 수 있는지를 구체적이고 지속적으로 전달해주는 노력이 필요하다.
실제 응용 사례
현재 필자가 속한 야간개발팀의 일원 중 미국에서 공부 중인 친구[1]가 지난 학기 수업 중 맥 OS X에서 코코아(Cocoa)를 이용한 애플리케이션 개발에 대해 배울 기회가 생겼다. 이 수업의 기말 과제로 OS X이나 아이폰용 애플리케이션을 개발해야 했는데, 우리 팀에선 좀 더 목표를 높게 잡아 과거 필자가 개발했던 CQube라는 퍼즐 게임을 아이폰으로 이식하는 것을 제안했다. 다른 팀원의 약간의 도움을 더해 친구는 CQube를 아이폰으로 훌륭하게 이식했고, 아래와 같은 이득이 있었다.
- 수업에서 상당히 높은 점수를 받았다.
- 앱스토어에 데모 버전을 올려 전 세계의 아이폰 사용자에게 CQube를 유통했다.
- CQube 아이폰의 정식판을 준비 중인데, 이를 통해 작은 수익을 기대할 수 있게 되었다.
- 학습에 대한 성과를 인정받아, 같은 학교의 동료와 아이폰 애플리케이션 개발 회사를 설립했다.
- 현재 이 회사를 통해 학교와 공동 프로젝트로 아이폰 애플리케이션을 개발하고 있다.
이와 같은 사례가 있다면 함께 공유해 보자. :)
주
[1]변수민, http://blog.sumin.us (블로그)
이 문서 북마킹 하기
 [지난 developerWorks Column 보기]
|
