"나쁜 습관을 만드는" 개발자의 7대 죄악

욕망 : 개발 도구, 기법을 모두 다 알아야 한다 최신 프로그래밍 언어들은 업데이트를 통해 기능이 계속 추가되는 경향이 있다. 적절한 사용 방법을 배우기 위해 시간을 들인다는 전제하에, 코드 가독성과 재사용성을 목적으로 설계된 새로운 키워드와 구조체가 추상화 계층 위에 겹겹이 쌓여간다. 동시에, 프로그래밍 수련법도 수년간 변해왔다. 몇 개월마다 한 번씩 개발자의 신으로 만들어주겠다는 누군가가 새로운 개발 방법론을 들고나온다. 그렇지만, 좋아 보이는 것이 성과로 반드시 이어지는 것은 아니며, 뭔가를 할 수 있다고 해서 당연히 해야 하는 것은 아니다. 도구에 집착하는 개발자들은 필연적으로 큰 그림을 보지 못하게 되고, 보기에는 가장 간단해 보이는 프로젝트에서조차 개발 지옥에 빠질 수도 있다. 치기 어린 충동을 억제하고 도움이 되는 도구에만 충실해야 한다.

폭식 : 모든 기능을 한 번에, 빠르게 구현해야 한다는 믿음 소프트웨어를 출시하는 것보다도 더 좋은 것은 없다. 제대로 동작하는 제품을 내놓고 나면, 다른 기능을 추가하려는 유혹을 강력하게 느낀다. 어떤 기능을 새로 넣을까? 첫 출시일에 구현하지 못한 기능에는 무엇이 있을까? 모든 기능을 완벽하게 구현해서 프로그램을 내놓는 일은 거의 있을 수 없다는 사실은 쉽게 잊진다. 그 결과, 반복적인 개발로 기능들은 쌓여가기만 하고, 개발자들은 효과적으로 관리하기에는 지나치게 비대해진 취약한 코드 베이스를 만들게 된다. 새로운 기능을 연이어서 탑재하려는 욕심을 억제해야 한다. 기존 코드의 질과 정비 용이성을 평가해야 한다. 개발 라운드마다 예산 청구 항목에 코드 재작성 청구 항목에 넣길 바란다.

탐욕 : 개발 팀원끼리 경쟁하고 예산을 낭비한다 부와 권력에 대한 과한 욕망. 자신의 동료와 경쟁하는 개발자의 심정을 어떻게 설명해야 할지 모르겠다. 갑자기 어떤 팀이 다른 팀이 이미 개발해놓은 기능의 절반 이상을 재구현하는 라이브러리는 작성하는 상황이 벌어지기도 한다. 개발팀이 악의를 가지고 쓸데없는 부분에 시간을 낭비하는 일은 거의 없지만, 명확하게 정의된 목표가 없으면 절대적으로 필요한 것보다 훨씬 더 광범위한 책임을 떠맡으려 하기 십상이다. 그 결과 중복 노동으로 인해 예산을 낭비하는 것은 물론, 불필요하고 다루기 힘든 코드 베이스만 남게 된다. 개발 프로젝트 관리에서 최우선 과제 가운데 하나는 팀원마다 다른 팀원이 어떤 일을 하고 있는지를 알고 있는지 확인하는 것이다. 모든 팀이 공통의 목표를 향해 잘 나아가고 있는지를 확인해야 한다. 균등하게 배분하는 것이 좌우명이 되어야 할 것이다.

태만 : 입력 데이터 유효성 검증을 하지 않는다 입력 데이터 유효성 검증은 특히 각별한 관심이 필요한 부분이다. 사실 경험이 많은 개발자가 작성한 코드에서 왜 여전히 아마추어와 같은 오류가 발견되는지는 이해할 수 없는 부분이다. 그런데도 불구, 버퍼 초과에서부터 SQL 인젝션 공격에 이르기까지, 아주 흔한 보안 취약점은 올바른 포맷인지를 검증하지 않은 사용자 입력에 근거한 코드가 직접적인 원인이다. 최신 개발 언어들은 이와 같은 상황을 방지하기 위해 개발자에게 다양한 도구를 제공하지만, 제대로 사용할 필요가 있다. 입력을 검증하기 위해 자바스크립트를 사용하는 웹 양식은 브라우저에서 자바 스크립트를 비활성화하거나 액세스하기 위해서 브라우저를 전혀 사용하지 않음으로써 쉽게 배제할 수 있다는 점을 명심해야 한다. 입력 검증은 UI가 아닌, 애플리케이션 핵심 기능으로 집어넣어야 한다. 그 이하의 어떤 것도 그저 직무태만일 뿐이다.

분노 : 코드 주석을 생략한다 코드에 주석을 달지 않는 것만큼 동료 직원들을 심각하게 골탕먹이는 일도 없을 것이다. 잘 작성된 코드는 그 자체가 최고의 문서다. 그러나 개발자들은 오늘 작성한 코드가 직장을 떠난 지 한참 뒤에도 남아있을 수 있다는 가능성을 배제하는 경향이 있다. 그들을 대신할 개발자들이 각각의 코드 스니펫이 실제로 무엇을 의지하는지 이해해야 하는 달갑지 않은 작업이 떨어질 때가 많다. 그러니 제발, 자비를 베풀어서 몇 가지 힌트라도 남겨주길 바란다. 그렇지만 이해할 수 없는 주석이나 너무 많은 주석은 주석을 전혀 달지 않는 것만큼이나 좋지 않다는 것을 명심해야 한다. '절대로 건드리지 말 것' 또는 '작동하지 않음'과 같은 주석은 누구에게도 별 도움이 되지 않는다. 코드는 코드의 기능을 설명하는 최소의 문서다. 그 이유를 설명하기 위해서는 당연히 주석이 있어야 하지 않을까.

질투 : 개발 버전 관리 따윈 없다 개발자의 워크스테이션에 존재하는, 서로 조금씩은 다른(얼마나 차이가 나는지는 아무도 모른다) 개발 버전들이 사무실 여기저기에 흩어져 있다. 프로젝트 버전 관리를 구현하지 않는 이유가 있을 수는 있다. 소규모로 시작했다가 과도하게 커진 것일 수도 있다. 그러나 강력하고 효과적인 버전 관리 시스템을 무료로 사용하는 등 얼마든지 그 대안은 있다. 작은 프로젝트일지라도 프로젝트의 첫 단계 중 하나로 코드 저장소를 생성하지 않을 이유가 없다. 본인 이외의 그 누구도 코드 변경 사항을 저장소에 커밋하는 꼴을 볼 수 없는 경우가 아니라면 말이다.

오만 : 단위 테스트 따위도 없다 성공적인 개발 작업에 대해 스스로 칭찬하고 싶은 유혹을 느낄 때가 있을 것이다. 그렇지만, 따지고 보면 비교 대상이 없는데 잘했는지를 어떻게 평가하겠는가? 특정 사례와 비교해서 코드를 검증하는 것이 아닌 이상, 광고했던 것처럼 동작할지, 완벽하게 결함이 없는지는 전혀 알 길이 없다. 그렇지만 상당히 많은 개발자들은 자신의 코드에 대한 단위 테스트조차 시행하지 않는다. 이들은 테스트에 낭비한 시간은 기능 구현에 쓰는 시간이 아니라고 주장한다. 실제로 일부 개발자들은 QA 테스트를 프로젝트 예산에 포함하지도 않는다. 결함이 있는 코드가 발주가 될 때면, 실수를 되돌리기에는 너무 늦을 것이다. 코드가 출시되기 전에 더 많은 단위 테스트를 계획할수록 나중에 나비효과처럼 불어날 피해에 대한 대책을 마련할 수 있다.