‘좋은 걸 어떡해’··· 손이 가는 프로그래밍 일탈 10가지

나쁜 프로그래밍 습관 No. 6 : 요요 코드(Yo-yo code)
프로그래머들이 ‘요요 코드’라고 부는 것이 있다. 먼저 그 값들은 ‘strings’로 저장된다. 그런 다음 그들은 정수(integers)로 구문 분석된다. 그리고 나서 그들은 다시 스트링으로 변환된다. 그것은 대단히 비효율적일 수 있다. 당신은 모든 추가적인 부하 하에서 CPU의 고군분투를 느낄 수도 있을 것이다. 빠른 코드를 쓰는 똑똑한 프로그래머들은 변환을 최소화하도록 그들의 아키텍처를 설계한다. 그들의 코드는 그들의 계획 때문에 더 빠르게 실행된다.

하지만 믿거나 말거나, 때로는 요요 코드가 합리적이다. 때때로 당신은 독점적인 블랙박스 안에서 수십 억 개의 지능적인 것들을 해내는 훌륭한 라이브러리를 가지고 있다. 때때로 사장은 그 블랙박스 안에 있는 모든 천재들에게 라이선스를 주기 위해 100만 달러가 넘는 수표를 쓰기도 했다. 만약 라이브러리가 스트링으로 된 데이터를 원한다면, 당신은 그것을 최근에 정수로 변환했더라도 스트링으로 라이브러리에 보낸다.

물론, 변환을 최소화하기 위해 당신의 모든 코드를 다시 쓸 수도 있지만, 그렇게 되면 시간이 걸릴 것이다. 코드를 다시 작성하는 데 훨씬 더 많은 시간이 걸릴 수 있기 때문에 때로는 코드가 1분, 1시간, 하루 또는 심지어 1주일 더 추가적으로 실행되는 것도 괜찮다. 그렇다. 때로는 기술 부채를 늘리는 것이 애초에 제대로 구축하는 것보다 더 싸다.

종종 라이브러리가 독점적인 코드가 아닐지언정 오래 전에 당신이 직접 쓴 코드인 경우가 있다. 때때로 데이터를 한 번 더 변환하는 것이 그 라이브러리에 있는 모든 것을 다시 쓰는 것보다 더 빠를 때가 있다. 그렇기 때문에 당신은 계속 진행하여 요요 코드를 쓴다.  그것도 좋다. 우리 모두가 그렇게 해봤었다.

나쁜 프로그래밍 습관 No. 7 : 나만의 데이터 구조 작성(Writing your own data structures)
표준 규칙 중 하나는 데이터 구조 과정을 갓 마친 프로그래머가 데이터 저장을 위한 코드를 작성해서는 안 된다는 것이다. 다른 누군가가 우리가 필요로 할 모든 데이터 구조를 이미 작성했고, 그들의 코드는 수년 동안 테스트되고 다시 테스트됐다. 그것은 언어와 함께 묶여서 아마 무료일 것이다. 당신의 코드에는 버그가 가득할 수 있다. 

그러나 때로는 데이터 구조 라이브러리가 약간 느리기도 한다. 때때로 그들은 우리를 표준적이지만 우리의 코드에 맞지 않는 구조로 강요하기도 한다. 또 그 라이브러리는 우리가 그 구조를 사용하기 전에 우리의 데이터를 재구성하도록 몰아붙이기도 한다. 일부 라이브러리에는 쓰레드 잠금과 같은 기능이 있는 뛰어난 보호들이 포함되곤 하는데, 우리의 코드는 그것들을 필요로 하지 않는다.

그러한 일이 발생하면, 우리만의 데이터 구조를 쓸 때이다. 경우에 따라 훨씬 더 빠르다. 그리고 때로는 데이터를 정확하게 다시 포맷하기 위한 추가 코드를 모두 포함하지 않기 때문에 코드를 훨씬 더 깨끗하게 만든다.

나쁜 프로그래밍 습관 No. 8 : 구식 루프(Old-fashioned loops)
오래 전에, C언어를 만든 어떤 사람은 하나의 간단한 구성으로 모든 추상적 가능성(abstract possibilities )을 요약하기를 원했다. 처음부터 해야 할 일도 있었고, 루프를 통해 매번 해야 할 일도 있었고, 모든 일이 언제 끝났는지 알려주는 방법도 있었다. 당시에는 무한한 가능성을 포착하기 위한 완벽하게 깨끗한 구문처럼 보였다.

그러나 시대가 다소 달라졌다. 문제를 일으킨다고 지적하는 이들이 최근 나타났다. 진행되는 일이 너무 많을 수 있다. 좋은 것에 대한 모든 가능성이 똑같이 나쁠 수도 있다. 그것은 읽기와 공감(grokking)을 훨씬 더 어렵게 만든다. 루프가 없고, 단지 목록에 적용되는 기능과 어떤 데이터에 매핑된 연산 템플릿이 있는 더 기능적인 패러다임을 좋아하는 이들이 나타났다.

루프리스 방식이 더 깨끗할 때가 있는데, 특히 단 하나의 깔끔한 기능과 배열만 있을 때는 더욱 그렇다. 그러나 훨씬 더 많은 것을 할 수 있기 때문에 구식 루프가 훨씬 더 단순할 때가 있다. 예를 들어, 첫 번째 매치를 찾는 것은 그것이 발견되는 즉시 멈출 수 있을 때 더 간단하다.

더욱이, 매핑 기능은 데이터에 대해 수행해야 할 여러 가지 것들이 있을 때 더 엉성한 코딩을 권장한다. 당신이 절대값과 각 숫자의 제곱근을 취하고자 한다고 상상해보라. 가장 빠른 해결책은 데이터에 대해 두 번 루핑을 함으로써 첫 번째 함수를 매핑한 다음 두 번째 함수를 매핑하는 것이다. 

나쁜 프로그래밍 습관 No. 9 : 중간에 루프에서 이탈하기(Breaking out of loops in the middle)
어느 땐가 한 규칙 제정 그룹이 모든 루프에는 ‘불변성(invariant)’이 있어야 한다고 선언했는데, 이것은 루프 전체에 걸쳐 진실된 논리적인 진술을 말하는 것이다. 불변성이 더 이상 사실이 아닐 때, 루프는 끝난다. 

이것은 복잡한 루프를 다루는 좋은 방법이지만, 우리가 루프 중간에 리턴이나 브레이크를 사용하는 것을 못하게 하는 것과 같은 말도 안 되는 금지로 이어진다. 이것은 고투 스테이트먼트를 금지하는 규칙의 일환이다.

이 이론은 훌륭하지만 가끔 좀더 복잡한 코드로 귀결된다. 테스트 통과 엔트리와 관련해 어레이를 스캔하는 간단한 케이스를 살펴보자.

while (i<a.length){
   ...
   if (test(a[i]) then return a[i];
   ...
}

루프 불변성 애호가라면, ‘now Found’라고 부를 것이다. 또 하나의 부울 변수(boolean variable)를 추가하는 것 대신 말이다. 아마 이를 다음과 같이 이용할 것이다.

while ((notFound) && (i<a.length){
   ...
   if (test(a[i])) then notFound=false;
   ...
}

만약 이 부울(Boolean)이 잘 이름지어졌다면, 셀프 도큐멘팅 코드의 탁월한 일부일 수 있다. 모든 이들이 잘 이해할 것이다. 그러나 이는 또한 복잡성을 추가한다. 그리고 또 하나의 로컬 변수를 할당하는 것을 의미하며, 컴파일러가 수정하지 못할 수 있는 레지스터 차단을 의미할 수 있다. 

즉, ‘고투’나 점프가 더 깨끗할 수 있다. 


나쁜 프로그래밍 습관 No. 10 : 연산자와 함수 재정의(Redefining operators and functions)
일부 재미있는 언어들은 개발자가 요소의 값를 재정의하는 것 등의 진정으로 비뚤어진 일들을 할 수 있게 해준다. 예를 들어, 파이썬은 최소한 버전 2.7과 그 이전 버전에서 TRUE=FALSE를 입력할 수 있다. 

이러한 시도가 어떤 종류의 논리 붕괴와 우주의 끝을 만들어 내는 것이 아니다. 그것은 TRUE와 FALSE의 의미를 바꾸는 것에 불과하다. 이와 같은 위험한 게임들을 C 프리 프로세서와 몇몇 다른 언어들에서 할 수 있다. 또 일부 언어들은 플러스 부호와 같은 연산자를 재정의할 수 있게 해준다.

이것은 일종의 편법(stretch)이지만, 소위 상수라고 불리는 것 중 하나 이상을 재정의하는 것이 더 빠를 때에 대비한 포인트들이 큰 코드 블록 안에 있을 수 있다. 

때때로 상사는 코드가 완전히 다른 작업을 하기를 원한다. 이 때 당신은 코드를 살펴보고 모든 사건을 바꿀 수도 있고, 아니면 현실을 재정의할 수도 있다. 그것은 당신을 천재처럼 보이게 할 수 있다. 거대한 라이브러리를 다시 쓰는 대신에, 약간 바꿔 주기만 하면 모두가 만족하는 결과가 나타난다.

여기서 글을 마치는 것이 좋을 것 같다. 영리하고 재미있는 시도일 수 있더라도 이것을 실제 비즈니스에 시도해서는 곤란하다. 솔직히 너무 위험하다. 

* Peter Wayner는 오픈소스 소프트웨어, 자율주행 차량, 개인정보 보호 강화, 디지털 트랜잭션, 스테가노그래피(steganography) 등 다양한 주제에 관한 16권 이상의 책을 저술한 저자다. ciokr@idg.co.kr