Paul Rubens | CIO

파레토 법칙에 따르면, 어떤 사건에서든 20%가 전체를 결정한다. 80:20 법칙으로 알려진 이 법칙은 사람과 관련된 거의 모든 분야에 설명력을 가진다.

소프트웨어 개발 분야에 이 법칙을 적용한다면, 몇 가지 잘못된 코딩 관행이 대다수 문제에서 원인이 된다고 정리할 수 있다. 즉 이런 잘못된 부분을 줄이거나 없애면 업무가 훨씬 쉬워지고, 생산적이 될 것이다. 가장 나쁜 코딩 실수 10가지를 정리했다.

1. 코드에서의 오탈자

놀랄 만큼 빈번히 저지르는 실수다. 프로그래밍 능력과는 아무런 관련이 없다는 점에서 '어이 없는' 실수이기도 하다. 단 하나의 변수나 기능의 명칭을 잘못 적어 코드 전체가 망가질 수 있다. 더 큰 문제는 이를 발견하기가 쉽지 않을 수 있다는 것이다.

해결책은 뭘까? 좋은 IDE(Integrated Development Environment)나 프로그램 전용 텍스트 에디터를 이용하면 오자를 크게 줄일 수 있다. 또 다른 방법도 있다. 쉽게 맞춤법에 따라 쓸 수 있도록 신중하게 변수나 기능의 명칭을 선택한다. 그러면 철자를 잘못 쓴 경우에도 쉽게 발견할 수 있다. 'recieve'로 잘못 쓸 확률이 높은 'receive' 같은 단어는 사용하지 않는 것이다.

2. 코드를 들여쓰기 또는 서식화하지 않는 실수

코드를 들여쓰기(indenting) 또는 다른 방식으로 서식화(formatting) 해야 한다. 그래야만 한 눈에 확인하면서 실수를 파악하기 쉽다. 또 다른 사람들이 코드 작업을 할 때도 도움을 준다. 코드가 일관된 형식으로 구성되어 있기 때문이다.

코드를 자동 서식화하지 않는 IDE를 쓰고 있다면, 자신이 정한 규칙에 따라 서식화 작업을 해주는 'Uncrustify' 같은 코드 뷰티퍼(Beautifer) 툴을 통해 코드 서식화를 하는 것을 검토한다.

3. 코드를 모듈화 하지 않는 것

코딩에 있어서는 좋은 관행 중 하나는 단 한 가지만 수행하는 기능을 쓰는 것이다. 코딩을 이해 및 유지관리가 쉽게 간략히 만드는데 도움을 준다. 긴 기능들에는 이를 통과하는 경로가 많을 수 있다. 따라서 테스트가 힘들어진다.

이를 위한 첫 번째 원칙은 '특정 한 기능이 화면 하나 이상의 공간을 차지하지 않도록 하는 것이다.' 두 번째 원칙은 '만약 if가 10개 이상이라면 너무 복잡하다는 의미이기 때문에 코드를 다시 쓰는 것이다.'

4. IDE를 지나치게 믿는 실수

코드 완성 (Code Completion) 기능을 제공하는 IDE 등의 툴들은 생산성 측면에서 '환상적'이다. 타이핑한 내용을 바탕으로 변수 등을 제시해 주기 때문이다. 그러나 이런 툴이 초래하는 위험 하나가 있다.

자신이 원하는 바를 정확히 완성시키기 위해 필요한 노력 대신, 보이는 무언가를 선택하게 되는 위험이다. 이 툴이 대신 '생각'해줄 수는 있지만 모든 부분에 이상이 없도록 만전을 기해야 하는 것은 자신의 책임이다.

그리고 당신 대신 생각을 해주는 과정에 위험이 초래될 수 있다. 코드 완성 툴은 오식 같은 실수를 줄여주고, 생산성을 높여준다. 그러나 방심을 한다면 '코드 완성' 오류가 초래될 수 있다.

5. 패스워드 하드코딩

나중에 시스템에 들어갈 수 있는 비밀 계정이나 패스워드를 하드코딩 하려는 유혹에 빠지기 쉽다. 이런 실수를 저질러서는 안 된다. 물론 편리할 수 있다. 그러나 다른 사람들 또한 쉽게 소스코드에 접근할 수 있다.

하드코딩 한 패스워드가 최초 당신의 의도보다 더 널리 알려질 수 있다는데 큰 문제가 있다. 이렇게 되면 큰 보안 문제가 초래된다. 그리고 이를 고치기 위해 큰 수고를 해야 한다.

6. 보호된 데이터를 제대로 암호화 하지 않는 실수

네트워크를 따라 이동하는 중요한 비밀 데이터에는 암호화가 필요하다. 네트워크를 이동하는 도중에 가로채기를 당할 위험이 있기 때문이다. 이는 그저 좋은 아이디어에만 머무는 것이 아니다. 법이나 규정에 따라 지켜야 할 의무사항이다.

암호화 없이 데이터를 전송하면 안 되는 것처럼 독자적인 암호화나 난독화 체계를 사용해서도 안 된다. 독자적으로 안전한 암호화 시스템을 개발하기란 아주 어렵다. WEP 사례를 보면 알 수 있다. 따라서 산업에서 입증된 표준 암호화 라이브러리를 정확히 도입해 사용해야 한다.

7. 너무 이른 코드 최적화

전설적인 프로그래머인 도널드 커누쓰(Donald Knuth)는 "프로그래머들은 프로그램에서 중요하지 않은 부분을 고심하느라 많은 시간을 낭비한다. 문제는 이런 효율성을 위한 노력이 디버깅이나 유지보수가 필요할 때 부정적인 영향을 초래한다는 것이다"고 말한 바 있다.

즉 코드가 더 빨리 실행되도록 천재성을 발휘했지만, 이것이 디버깅과 유지보수를 더 어렵게 만들 수 있는 것이다. 이를 위한 좋은 전략이 있다. 일단 깔끔하게 코드를 작성한다. 그리고 성능 향상을 위해서 최적화가 꼭 필요한 부분만 손을 본다.

8. 앞서 생각하지 못하는 실수

프로젝트의 목적은 무엇일까? 어느 정도 확장이 필요할까? 사용자 수는 얼마나 될까? 얼마나 빨리 실행될 수 있어야 할까? 이런 질문에 대한 답이 확실하지 않을 수 있다. 그러나 추정해야만 한다. 그래야만 이들 요건을 충족할 수 있는 애플리케이션 개발에 필요한 적당한 프레임워크를 선택할 수 있다.

트위터(Twitter)는 이런 미래의 요건들을 과소평가했을 때 직면할 수 있는 문제들의 본보기를 제시한다. 트위터는 루비(Ruby)와 레일스(Rails)를 포기하고, 스칼라(Scala)와 다른 기술을 이용해 코드의 상당 부분을 다시 개발해야 했다. 최초 채택한 루비 코드로는 고속 성장하는 사용자 기반에 맞춰 확장을 할 수 없었기 때문이다.

9. 프로젝트에 인력을 추가시키면서 시간을 낭비

대다수의 소프트웨어 프로젝트는 일정을 맞추지 못한다. 프로젝트에 인력을 추가시키면 다시 정상궤도에 올라설 것처럼 보인다. 그러나 이는 가장 많이 저지르는 실수 중 하나다. 실제로는 프로젝트에 새 인력을 추가할 경우 전반적인 생산성이 저하되는 결과가 초래된다.

10. 잘못된 시간 (일정) 추정

동시에 프로젝트에 인력을 추가하지 않고도 나중에 일정을 앞당기면 된다는 '유혹'에 빠져 들어서는 안 된다. 일정에 뒤쳐진 이유는 시간 또는 일정에 대한 추정이 잘못됐기 때문이다. 잘못된 것으로 밝혀진 프로젝트 일정을 무턱대고 고수하지 말고, 새로 다시 추정해야 한다는 의미다.

<출처: CIOKorea>