파이썬을 위한 정적 검사(static analysis) 도구를 찾아 보다 PyChecker 프로젝트를 발견했다. PyChecker는 C의 lint와 유사한 프로그램으로 파이썬 프로그램을 읽어서 실행 전에 다음 오류들을 알려준다.

- 사용된 전역 변수가 정의되지 않았을 때. (예를 들어 import 없이 모듈을 사용)
- 함수/메쏘드/생성자에 넘기는 인자 수가 맞지 않을 때.
- 내부(builtin) 함수/메쏘드에 넘기는 인자 수가 맞지 않을 때.
- 포맷 문자열과 인자가 맞지 않을 때.
- 존재하지 않는 메쏘드나 속성(attribute)을 사용했을 때.
- 메쏘드를 오버라이드할 때 시그너처를 바꾼 경우.
- 같은 스코프에서 함수/클래스/메쏘드를 재정의했을 때.
- 변수를 초기화 없이 사용했을 때.
- 메쏘드의 첫 번째 인자가 self가 아닐 때.
- 사용되지 않은 전역 변수와 지역 변수.
- 사용되지 않은 함수/메쏘드 인자.
- 모듈, 클래스, 함수, 메쏘드에 doc이 없을 때.

사실 이 정도 검사는 별도의 어노테이션 없이 가능한데, 왜 파이썬 인터프리트가 직접 지원하지 않는지는 잘 모르겠다. 저런 뻔한 버그 때문에 몇 번이나 코드를 테스트해야 한다는 것은 엄청난 약점일 것 같은데 말이다.

참고 문서
1. Regular Expressions: Syntax Checking the Scripting Way by Cameron Laird and Kathryn Soraiz
http://www.unixreview.com/documents/s=2426/uni1018986621203/0204h.htm

비슷한 비유가 프로그래밍 언어에도 적용되지 않나 싶다. 보통 새로운 언어가 개발되면, 언어의 장점을 알리기 위해 간단한 문제 몇 가지를 골라 기존의 프로그래밍 언어에 비해서 얼마나 세련되고 아름답게 그리고 짧은 코드로 그 문제를 풀 수 있는지 보여준다. 이런 장난감 프로그램 몇 개만 잘 골라서 보여주면 기존 언어에 식상해 있던 사람들은 금세 그 언어에 열광하게 된다. 파이썬/루비에 열광하는 많은 개발자들은 실상은 이런 코드 단축의 예에 매료되어 해당 언어를 공부하게 되었을 것이다.

스크립트 언어의 특징은 다음과 같다.

1) 인터프리트 된다.

2) 타입 선언이 암묵적이다. (Implicit Declaration)

3) 동적 타입(Dynamic Typing)이다.

4) 정규식(RE)와 문자열 처리 기능이 내장되어 있다.

위4가지의 특징은 스크립트 언어를 강력하게 만들며, 작은 프로그램을 빠른 속도로 프로토타이핑(prototyping)할 수 있게만들어주는 언어의 특징이다. 반대로 이런 특징(특히 1,2,3)은 크고 정교한 프로젝트에는 부정적인 영향을 미치는 요소이기도하다. 파이썬이나 루비가 이런 한계를 뛰어 넘었다면 그 이유는 무엇일까? 회사에서 파이썬이나 루비를 도입하고 싶다면, 직장상사나 팀원들에게 무엇을 근거로 해당 언어의 도입을 이야기할 것인가?

소프트웨어 개발을 업으로 삼고 컴퓨터 공학을 하는 사람이라면, 여기서 한 걸음 다 나아가야 한다. 국내 스크립트 언어 사용 개발자들에게 아쉬운 것은 실제 프로젝트의 적용 사례가 빈약하다는 점이다. 개발자들이 개별적으로 써보니깐 코드도 짧고 가독성도 높고 생산성이 뛰어나서 좋다고 말은 하는데, 실제로 스크립트 언어를 써서 어떤 프로젝트를 성공적으로 수행했는지에 대한 말을 찾아보기가 어렵다.

회사에서 사용하는 개발 언어를 바꾸고 싶다면 언어의 장점을 회사의 생산성 향상과 연결시킬 수 있는 구체적인 숫자를 제시할 수 있어야 한다. 회사 내 혹은 팀 내의 보수적인 개발자들을 설득하고 싶다면 토이 프로그램의 마법만을 보여줄 것이 아니라 구체적인 적용 사례을 보여주고 생산성 증가 정도를 구체적인 숫자로 제시해야 할 것이다. 그런 정보 없이는 만병통치약을 선전하는 약장수와 다를 것이 없게 된다.

컴퓨터 공학과 소프트웨어 개발에 대한 블로그를 운영하다 보니 자연스럽게 다른 개발자들 혹은 컴퓨터공학 전공 학생들의 블로그를 종종 들여다 보게 됩니다. 한국의 소프트웨어 개발자들은 요즘 무슨 문제로 고민하는지, 어떤 기술에 관심을 가지고 있는지 알아보는 것은 늘 즐거운 일이기 때문입니다. 그런데 블로그를 보다 보니 사람들마다 특색도 있지만 또한 상당한 유사성도 있다는 느낌이 들었습니다. 객관적인 통계에 기초하고 있는 것은 아니지만, 요 며칠 블로그를 탐색하면서 받은 제 인상은 다음과 같습니다.


1. 대부분 웹 개발에 종사한다.

블로그 내용의 상당수가 웹 개발과 관련된 이슈를 다루고 있었습니다. 해당 글의 내용으로 미루어보아 상당수가 웹 개발자로 일하고 있음도 알 수 있었습니다. 기술적인 내용으로는 웹 2.0과 AJAX, JSP, PHP 등이 주류를 이루었고, 비지니스적인 고민도 대부분 웹 서비스 모델과 관련된 것들이 많았습니다. 반면에 패키지 소프트웨어나 임베디드 소프트웨어를 개발하는 것으로 보이는 개발자 분은 찾아보기가 힘들었습니다. 임베디드 분야에 종사하는 개발자도 상당수 계실 텐데, 그 분들은 웹(?)과 친하지 않아서인지 블로그가 별로 없더군요.


2. 대안 언어를 찾아 헤맨다.

개발자라면 당연히 프로그래밍 언어를 구사해야 하므로 프로그래밍 언어에 대한 관심도 높을 것입니다. 블로그를 잘 살펴보면 상당수의 개발자가 기존의 개발 언어(C, C++, 자바 등)에서 탈피해 새로운 대안을 모색하고 있는 것으로 보였습니다. 특히 파이썬과 루비에 대한 인기가 가장 높아서 상당수의 블로그가 이들 스크립트 언어를 다루고 있었습니다. 대안 언어의 구사 여부가 개발자의 쿨(cool)함의 정도를 나타내는 지표에 가깝다고 할 정도로 새로운 언어를 추구하시는 블로거가 많이 계셨습니다.


3. 실제 업무에 대한 이야기는 별로 없다.

실제 업무가 없는 학생들은 차치하고 현업에 종사하고 계신 개발자들도 실제 회사에서 개발하는 이슈에 대한 이야기는 거의 하지 않음을 알 수 있었습니다. 언급을 하더라도 피상적인 수준에서 문제점이나 생각들을 언급할 뿐 구체적인 프로젝트나 이슈들에 대한 언급을 찾아보기는 힘들었습니다. 기술적인 면에서 상당히 개방적인 태도를 취하는 서양 엔지니어들과 달리 한국 개발자들은 회사 일은 회사 내부에서만 이야기해야 한다는 생각이 강한 것 같습니다.

4. 유행에 민감하다.

블로그를 돌아보면서 블로그 글들도 상당히 유행에 민감하다는 사실을 알 수 있었습니다. AJAX, 루비 등 몇 개의 기술이나 화두가 거의 모든 블로그에서 논의되는 모습은 다양성 면에서 조금 아쉬운 감이 있었습니다. 유행과 관련 없이 특정 기술이나 주제로 깊이 있는 글을 쓰시는 분들이 많이 있었으면 하는 바램이 있습니다.


글이 상당히 피상적이 되었네요. 한국의 개발자 블로그들이 많이 활성화 되길 바랍니다.