06 Apr 2009
웹 기획자나 디자이너도 조금만 노력을 들이면 웹 프로그래밍을 할 수 있는 개발 꾸러미가 있다. 내 생각엔 이 꾸러미가
- 디자이너들이 능숙하게 다루는 포토샵보다,
- HTML과 CSS로 만든 문서가 여러 웹브라우저에서 똑같거나 비슷하게 보이게 하는 것보다도,
- MS 엑셀보다도 쉽다.
- 어쩌면 자신의 윈도 운영체제에 깔린 바이러스(로 통칭되는 모든 나쁜 무른모(software)들)나 Active-X로 설치된 보안 도구들(n-protect 등)을 깨끗하게 지우는 것보다 이 개발 꾸러미를 익히는 것이 더 쉬울지도 모른다.
그 꾸러미는 바로 파이썬이라는 프로그래밍 언어와 Django 라는 웹 프레임워크이다. 내가 개발에 관심이 있다손 치더라도 기획자가 일주일만에 익혀서 간단한 뭔가를 만들만큼 쉽고 편하며 유연하다. 이 좋은 걸 접했는데 가만 있을 내가 아니다. 사회총지식을 늘리고자 약 10주 동안 엉덩이 두 쪽에 땀띠 생길 정도로 열심히 Django 강좌를 썼다. 하지만, Django나 파이썬을 깊이 이해한 상태에서 쓴 것이 아니어서 여러모로 부실한 부분이 많이 드러나서, 뜻하지 않게 잘못된 지식을 퍼뜨려 아쉬움이 많이 일었다. 다행인 점은 여러 분들께서 지적을 해주셔서 강좌가 개선되었다는 점이고, 불행인 점은 우리나라에 이 강좌처럼 우리말로 웹서비스 하나를 시작부터 끝까지 만드는 과정을 다루는 자료가 없어서 이 부실한 강좌가 여전히 주요 자료로 읽히고 있다는 점이다.
하지만, 이 불행은 며칠 뒤면 끝날 예정이다. 인사이트 출판사에서 “쉽고 빠른 웹 개발 Django”라는 책을 내기 때문이다. “Learning Website Development with Django”라는 원서를 스파이크님께서 번역하신 책인데, 아마존닷컴에서도 호평을 받고 있는 책이다. 난 번역된 책을 사전 읽기(Beta reading)로 접했는데 저러한 호평에 적극 동의한다.
그렇다면 이 책은 누가 읽으면 좋을까? 파이썬이나 Django에 관심이 있지만 영문 자료가 부담스럽고, 내가 쓴 강좌도 어딘가 허술해보여서 못미더웠다면 이 책을 사면 만족할 것이다.
웹 개발 입문자에게도 좋다. 웹 개발자는 웹 개발에 필요한 각 부분을 익힐 필요도 있지만, 개발 공정을 이해하는 것이 무엇보다 중요하다. 경력자와 새내기(신입)을 구분짓는 주요 요소 중 하나가 전체 공정 경험인데, 새내기들은 전체 공정을 겪거나 이해할 경험을 얻기가 쉽지 않다. 그래서 난 개발방법론을 익히는 걸 권하는데, 이론만 접하지 말고 실습도 해야 감각이 는다. 그러한 감각을 늘리는 데에 Django 만큼 좋은 도구도 드물다.
아직 나오지도 않은 책으로 설레발 치는 것 같지만, 앞서 말했듯이 난 이미 읽어보았고 허공에 팔다리 파닥이며 추천할 만하다고 생각하고 있다. 자바나 c# 처럼 다소 덩치 큰 언어를 익히느라 큰 그림을 겪는 데 너무 많은 힘 쏟지 말고, 쉽고 편한 파이썬과 Django를 시작하길 권해본다.
덧쓰기 : 참고로 파이썬은 교육용으로 만들어진 언어이다. 그리고 Django는 파이썬이라는 언어 철학을 잘 담아낸 파이썬스러운 도구라는 평을 듣는다.
덧쓰기 : 원서는 Django 0.96판을 기반으로 하지만, 이 번역서는 스파이크님께서 1.0.2판을 기반으로 다시 쓰셨다고 한다. 꽤 많이 바뀐 점을 생각해보면 번역서 수준을 넘어서는 것이나 마찬가지이다.
01 Apr 2009
문제, 문제, 문제
- 대체 왜 기획자는 개발자가 필요로 하는 내용을 기획서에 담지 않는지,
- PM은 왜 툭하면 시연 등을 요청하여 개발 일정을 뒤틀어 놓는 것인지,
- 개발자는 함께 일정을 잡아놓고선 만날 야근하고도 일정을 지키질 않는지,
- 다른 조직의 개발자는 이틀이면 된다는 일을 왜 우리 팀 개발자는 일주일짜리 일이라고 하는지,
- 왜 그리도 개발자는 하드디스크가 잘 고장나서 소스 파일을 날려먹는 일이 여느 사람보다 훨씬 많은 것인지,
- 기껏 다 만들었더니 왜 요구한대로 만들지 않았냐고 사장님이 버럭 화를 내시는 것인지,
- 우리는 우리대로 손해보고, 고객은 고객대로 사기 당한 것 같은 얼굴을 보이는 일은 왜 그리도 잦은지.
해결을 하는 것이 문제
프로젝트를 진행하면서 이러한 상황을 종종 볼 수 있다. 경력이 많은 사람일수록 설화인지 전설인지 구분하기 어려운 무용담, 아니 개발담을 많이 갖고 있다. 그리고, 이런 상황을 해결할 수 있는 방법은 경력자 수만큼, 혹은 서점에 있는 책 개수만큼 많다. 예를 들면, 개발자에게 필요한 내용이 기획서에 제대로 나와있지 않다면 화술이나 대인관계론을 공부하여 기획자를 효과있게 구박하거나 기획자에게 개발 공부를 시켜서 상황을 해소하는 식이다.
이런 방법들이 틀린 것은 아니다. 그러나, 여러 톱니바퀴가 맞물려 돌아가는 상황에서 어딘가 이빨이 맞물리지 않아서 문제가 발생했다면, 각 톱니바퀴를 절대 망가지지 않는 초합금으로 만들고 금테를 두르는 것만으로는 문제를 해결하기 어렵다. 톱니바퀴 자체가 아니라 톱니바퀴가 맞물려 돌아가는 전체 흐름, 즉 개발 공정을 봐야 한다.
훌륭한 소프트웨어 개발을 위한 방법을 쉽고 재미있게 배우자
Head First Software Development 는 개발 공정을 주제로 하는 방법론을 다루고 있다. 개발 공정 중 일부에 대해서, 혹은 방법론을 깊이 다루지 않는다. 소프트웨어 개발의 전체 흐름, 그리고 개발할 소프트웨어와 관계된 이해당사자에 대해 이야기를 하고 있으며, 이러한 내용을 가상으로 프로젝트를 시작하고 완료하는 공정에 비추어 친절하게 설명한다.
책 이름이 개발자를 위한 것 같지만, 실은 기획자나 프로젝트 관리자(PM)도 함께 봐야 할 책이다. 이들이 숙지해야 할 내용이 있기 때문에 그렇기도 하지만, 다정하고 친절하게 개발 공정을 설명하는 책이기에 그렇기도 하다. 마치 이야기 구성이 잘 짜여진 소설을 읽듯이 프로젝트 시작부터 완료까지 개발 공정 이야기를 편안하고 쉽게 읽을 수 있다.
내용 구성
책은 크게 계획, 업무 정의(사용자 스토리, 태스크), 이터레이션, 버전 관리, 테스트, 버그 관리에 대해 다루고 있다.
계획 과정에서 고객의 요구사항 파악 및 우선순위 도출을 하고, 사용자 스토리를 기반으로 업무(task)를 정의한다. 이 업무는 조직의 개발 속도 등을 감안하여 이터레이션(iteration)을 나누어 진행하며 마일스톤으로 향한다. 물론, 각 이터레이션에는 협업 환경에서 필수인 버전 관리 체계 따르기, 테스트 기반 개발(TDD : Test Driven Development), 그리고 버그 추적 및 관리를 하여 품질 관리 과정이 녹아 있다.
이 책은 이러한 각 과정을 12장(chapter)에 걸쳐 꼼꼼하고 친절하게 다루고 있다. 좀 더 자세히 말하자면, 책 구성과 내용이 주제보다는 독자에 기준을 두고 쓰여졌다는 생각이 들 정도이다. 이야기 전달력(스토리텔링)이 높다. 다른 기술서에선 한 두 단락으로 다룰 내용을 이 책은 내용 전달을 위해서 여러 쪽에 걸쳐 최대한 쉽게 풀어쓰고 각종 그림을 동원하기도 하고, 400장이 넘는 내용을 한 두 쪽짜리 연습문제로 내며(460쪽~463쪽) 깔끔하게 정리해서 책 이해를 돕는다.
이 정도면 불친절하고 꺼칠한 사수보다 Head First 책들이 더 낫다는 생각이 들지 않을까? :)
아쉬운 점
좋은 점이 참 많은 책이다. 하지만 아쉬운 점도 있다.
우선 책을 읽으면서 이러한 친절이 좀 과하다고 생각이 드는 점을 들 수 있다. 그림이나 사진 등으로 전달력을 높이는 건 좋은데, 오히려 시선을 흩뜨려서 집중을 해치는 경우도 간혹 있다. 나는 책에 줄을 긋거나 생각을 적으며 책을 읽는데, 이 책에 그러면 정돈되지 않아 산만해지는 꼴이 되어 버린다.
두 번째는 심심치 않은 오탈자이다. 다행히 뜻을 해치는 수준은 아니므로, 옥에 티가 뭍은 수준이라 할 수 있다.
서평을 마무리하며
앞서 말했듯이 난 이 책을 개발자 뿐만 아니라 기획자나 PM도 꼭 읽어야 한다고 생각한다. 책은 자바(Java)나 C#, C++ 같은 프로그래밍 언어를 알아야 한다고 하지만, 프로그래밍을 몰라도 충분히 소화할 수 있다. 그만큼 쉽게 이해하도록 쓰여져 있다.
설령 프로그래밍 언어를 몰라서 내용을 이해하기 어렵더라도 개발자에게 모르는 걸 물어보며 개발 공정을 이해하도록 노력해야 한다고 생각한다. 개발 공정이라면 마땅히 개발이 어떤 공정으로 흐르는지 알아야 하는데, 기획자나 PM은 “공정”에 자신만의 관점과 생각을 반영하여 개발 과정에서 소통 차질을 일으키곤 한다. 이런 문제는 개발 공정 중 “개발”에 지식을 쌓으면 어느 정도 해소되지만, “개발 공정”을 이해하여 개발과 공정 모두를 잡을 수도 있다. 물론, 프로그래밍이나 그래픽 디자인처럼 기획을 구현하는 “개발” 영역을 이해한다면 금상첨화이다.
이제 글을 열며 제기한 문제들을 해결하는 방법 하나를 꼽으며 글을 닫으려 한다. 이 책을 곁에 두고 읽으며 실천해보는 것이다. :)