지난 몇 년은 개발프로세스랍시고, 오픈소스에서 돌아가는 모습을 흉내(?)내려고 노력을 많이 했습니다. 나름대로, 저와 같이 일한 동료들에게는 방향정도는 잡았다고 생각이 되는데, 그 동안 잃어 버린 것이 있습니다. 이것은 저와 같은 사람의 특성일 것이라 생각됩니다. 감히 일반화하지는 않겠습니다.

처음에는 팀이 일하는 것과 개인이 일하는 것이 다름을 강조하던 시절이 있었습니다.
이런 시절의 모토는 "코딩 컨벤션이 맘에 들지 않아도 팀에서 일한다면 기꺼이 따라야 한다." 였습니다.
물론 지금도 변함없는 모토입니다.

그러다 시간이 지나서, 팀이 일하는 것에 익숙해져있고, 동료간의 리뷰는 스펙, 설계, 코딩 상당히 자주하는 것에 대해 습관적이 되어, 이젠 일상이 되었습니다. 즉, 신선함(?)이 없는 상태가 되었다는 것이고, 다른 말로하면, 개발팀의 체계가 잡혔다는 것입니다.

그러다가 이제 시간이 좀 더 흘렀는데, 회사의 틀은 잡혔다고 생각하지만, 개인의 시간과 다른 관심사로 뭔가 고상한 딴 짓을 하는 것에 점점 무디어지기 시작했습니다. 다른 말로하면, 창의성이 저하되었다는 것이죠. 왜 저하될까요? 이상하게 저하되어 있더라구요.

수수방관할수록 창의성이 발휘되는 인간들이 있습니다. 규모가 작을 때는 그런 사람을 잘만 잡아주면 품질 좋은 제품을 만들어 낼 수 있습니다. 어쩌면 회사의 틀이 잡히기 전부터 그런 것에 관심을 가져, 회사가 줄 수 없는 시스템을 창의적으로 도입하였기 때문에 도입하는 과정 속에 있을 때는 상당히 적극적이 되었던것 같습니다. 그런데 그것이 습관을 바꾸어 놓았고, 창조성에 관련된 기본적인 성향을 스스로 울타리에 가두고 있는 상태가 되어 버린것 같습니다.

해커기질이 잘 발휘되려면, 시스템이 잘 정비된 것에서 한 발자욱 더 진보하여야합니다. 날뛰던 과거로의 회귀가 시스템 상에 있어야합니다. 서두에서는 저와 같은 사람의 특성이라고 하였지만, 개발자들의 기본 성향이 그러할 것 입니다.

짧게 생각해보면, 이런 것들을 도입할 수 있으리라 생각됩니다.

  1. 사내에 공개된 자신이 원하는 1 인 1 프로젝트 의무화
    (svn, 버그트랙, 설계 문서, wiki, forum 을 통해 투명하게 관리)
  2. 외부 공개 프로젝트에 참여하는 것을 회사 업무의 일환으로 평가.
  3. 위 두가지를 회사 제품에 도입할 수 있으면 평가를 잘 줌.
밤이라서 그런지 생각이 더 자라질 않는군요.

가을입니다. 가을엔 어떤 딴 짓을 할 지 설레여야하는데, 머리 속이 너무 조용합니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
2006/09/28 01:09 2006/09/28 01:09
요즘 시간을 들여 생각하는 것이 개발 절차와 관련된 주제이고, 마침 정리해야할 논제도 있고하니, 생각을 풀어 보고자한다.

제목대로 개발 절차와 문서 템플릿이 보안 사항이냐라는 질문에 대해서는 그렇지 않다라고 정리하고 싶다. 그렇게 결론을 먼저 내리는 이유는
  • 개발 절차는 일하는 순서일 뿐이며, 이는 이미 소프트웨어 공학에 나와 있는 것들이다.
  • 개발 절차를 진행하면서 나오는 산출물의 리스트는 그만한 수준은 어느 회사든지 다 가지고 있다.
  • 개발 절차나 템플릿을 입수했다고 해서, 그대로 수행하는 것은 어렵다.
실제 어느 프로젝트의 산출물 리스트가 유출되었다면, 그것은 사람에 따라 민감할 수 있겠다. 하지만 프로젝트를 진행하기 전 템플릿들은 단지 도구일 뿐이다.

진짜 보안은 여기에 있다.
개발 절차와 문서 템플릿을 가지고, 잘 훈련되어 있는 조직에서 처음부터 끝까지를 경험하게 하는것.
그것은 마치 영어 공부를 하는 사람이 영어 쓰는 사람들과 한 번도 얘기 없이 유창하기를 바라는 것과 마찬가지이다.

개발절차와 문서 템플릿이라는 도구를 마음대로 부릴 줄 아는 능력은 말이나 책이 아니라 경험으로 복사되는 것이다.
크리에이티브 커먼즈 라이센스
Creative Commons License
2006/08/31 14:23 2006/08/31 14:23