스매싱매거진에서 "나는 어떻게 일하는가?"라는 연재의 첫 주인공으로 더글라스 크록포드를 낙점하면서 그의 인터뷰를 읽었습니다. 그중에서 인상 깊은 내용만 정리해 봅니다.
- 프로그래머는 컴퓨터공학의 역사부터 배워야 한다
기술의 변화 패턴이 역사적으로 반복되기 때문에 그 역사를 알면 기술과 언어에 대한 나름의 철학을 가질 수 있다는 의견으로 이해되더군요. 마치 물리학 첫 학기가 역사수업인 것처럼. 이런 역사감각은 기획자에게도 필요합니다. 사실 요즘 첨단 서비스라고 나오는 것도 과거에 한번쯤은 선보였던 것이 많습니다. 인터넷과 모바일의 유구한(?) 역사를 이해하면 기획의 깊이가 남다르겠죠. 그렇다고 '내가 해봐서는 아는데'라는 편협함은 금물! - 능력이 부족한 프로그래머는 호기심이 부족하다
훌륭한 개발자는 항상 배운다고 합니다. 새로운 기술이 수시로 나오기 때문에 배움은 불가피한 선택일 것입니다. 그러고 보면 기획자도 배워야 할 것 많습니다. 하드웨어와 소프트웨어를 기본적으로 이해해야 하고 네트워크 통신도 알아야 하죠. 심리학 같은 인문학적 소양과 디자인을 보는 미적 감각이 필요하고 경영이나 마케팅 쪽도 이해해야 합니다. 심지어 국어도 잘 해야 합니다. 그래서 저는 사람을 뽑을 때 그간의 경험 보다는 똑똑하고 성실한 사람을 채용해야 한다고 생각하는 쪽입니다. 그런 사람들은 노력해서 뭐든 빨리 배울 수 있으니까요. - 다른 사람들 앞에서 코드를 시연하는 것이 중요하다
프로그래머가 혼자서 코드를 짜고 빌드하여 그 결과물만 내보이는 경우가 많습니다. 이렇게 하면 잘 짠 코드가 공유되지 않고 엉망인 코드가 상용화 되는 일이 생깁니다. 그래서 근래의 개발방법론은 동료리뷰 (peer review)를 강조합니다. 기획자는 자신의 기획안을 다른 사람 앞에서 발표하고 리뷰 하는 것이 다반사이므로 이 부분의 걱정은 없을 것 같습니다. 다만 이런 리뷰를 막판에 한번만 하는 것이 아니라 일을 진행하면서 꾸준히 진행하면 기획안의 수준에 대한 공감대가 형성되고 그 수준도 높아지는 장점이 있습니다. - 사용자를 이해하면 프로그래머가 더 잘 일할 수 있다
개발자는 코드로 말해야 한다는 명언(?)도 있지만 사실 코드는 목적이 아닙니다. 코드가 모여 동작하는 소프트웨어(제품)는 그 나름의 목적에 봉사해야 합니다. 고객이 만족하지 못한 경우 제품과 그 코드는 실패한 것입니다. 전에 트위터의 채용공고에 개발자 직군을 두고 "문제를 해결하는 사람"이라는 문구를 인상깊게 본 적이 있습니다. 프로그래머는 그저 개발만 하는 사람이 아니라 사람들의 삶을 변화시키는 사람이라고 합니다. 이건 사실 업(業)에 대한 비전이죠. 서비스나 제품에만 비전이 필요한 것이 아니라 내가 하는 일에 대한 소명 (higher calling)이 있어야 일을 추진하는 데서 겪는 시련을 이길 수 있고 궁극적으로 보다 멋진 서비스가 나올 수 있습니다.
자바스크립트 구루가 들려준 이야기를 순전히 비개발자 관점에서 마음대로 해석해봤습니다. 무엇보다 이렇게 철학이 있는, 연륜이 있는 개발자가 여전히 현역에서 활동하고 있다는 것이 멋져보였습니다. 우리나라의 개발자도, 기획자도 그러해야겠지요.
