매력적이지만 버려야 할 10가지 나쁜 프로그래밍 습관

우리는 모두 규칙을 위반할 때의 짜릿함을 안다. 그 위반은 시속 55마일 구역에서 56마일로 달리는 것일 수도 있고, 주차 미터기의 유효 기간이 지나도록 방치하는 것일 수도 있다.

프로그래머와 규칙은 묘한 관계를 맺고 있다. 코드는 규칙의 거대한 더미에 불과하며, 규칙은 거의 항상 알파 입자로 인한 오류 없이 충실한 실리콘 게이트에 의해 두려움이나 호의 없이 무한히 적용된다. 인간은 트랜지스터가 규칙을 완벽하게 따르기를 바란다.

하지만 그렇게 신성하지 않은 또 다른 규칙이 있다. 인간이 기계에 전달하는 지침과 달리, 인간 스스로 만드는 규칙은 쉽게 유연해진다. 어떤 규칙은 단순히 문체적인 규칙이고, 어떤 규칙은 무질서하게 쌓인 코드 더미에 일관성을 부여하기 위해 고안된 규칙이다. 이러한 일련의 규칙은 기계의 반응 방식이 아니라 인간이 하는 일에 적용된다.
 

진짜 논쟁은 인간이 스스로 만든 규칙을 깨는 것이 좋은 생각인지 아닌지다. 인간이 즉석에서 규칙을 재해석할 권리가 있지 않을까? 어쩌면 일부 규칙은 다른 시대에서 유래한 것일 수도 있다. 처음부터 반만 완성된 개념이었을 수도 있다. 당시에는 현명한 아이디어처럼 보였지만 지금은 아닌 규칙도 있고, 어떤 것은 "습관"이라고 부르는 것이 더 나을지도 모른다.

프로그래밍 기술 개선을 저해할 나쁜 프로그래밍 습관 10가지를 정리했다.
 

주석 없는 코딩

문서화되지 않은 코드는 이해와 디버깅에 있어 악몽과도 같다. 프로그래밍 수업에서는 좋은 코멘트를 작성하는 것이 필수라고 가르친다. 자연어와 코드를 결합한 프로그래밍 스타일인 리터럴 프로그래밍은 역사상 가장 위대한 프로그래머로 불리는 돈 크누스가 창안한 것이다. 누가 이의를 제기할 수 있을까?

하지만 슬픈 진실은 댓글이 상황을 악화시킬 때가 있다는 점이다. 때로는 문서가 코드와 거의 관련이 없는 것처럼 보일 때도 있다. 문서화 팀이 코딩 팀과 멀리 있거나 다른 주에 살고 있을 수도 있고, 실제로는 생각이 다를 수도 있다. 코더가 문서화 팀에 알리지 않고 중요한 패치를 적용했거나 문서화 팀에서 알고 있지만 아직 주석을 업데이트하지 않았을 수도 있다. 때로는 코더가 변경한 메서드의 맨 위에 있는 코멘트를 업데이트하지 않기도 한다. 스스로 알아서 해결해야만 한다.

다른 문제도 있다. 코멘트가 모르는 자연어로 작성되었을 수도 있다. 7단락 미만으로 요약할 수 없는 개념인데 코더가 급하게 작성했을 수도 있다. 코멘트를 쓰는 사람이 잘못했을 수도 있다.

이러한 모든 이유로 일부 개발자는 쓸모없는 코멘트에 대한 최선의 해결책은 코멘트를 적게 포함하거나 아예 없애는 것이라고 생각한다. 대신 길고 설명적인 캐멀케이스 변수 이름을 지침으로 사용하는 간단하고 짧은 함수를 작성하는 것을 선호한다. 컴파일러에 오류가 없다면 코드는 컴퓨터가 수행하는 작업을 가장 정확하게 반영해야 한다.
 

느린 코드

코드를 빠르게 만들고 싶다면 코드를 단순하게 만들어라. 정말 빠르게 만들고 싶다면 복잡하게 만들어라. 이 과제에 적합한 최적의 지점을 찾는 것은 그리 쉬운 일이 아니다.

따라서 절충점을 찾아야 한다. 일반적으로는 프로그램이 빠르기를 원한다. 그러나 아무도 이해하지 못한다면 복잡성이 오히려 방해가 된다. 속도가 중요하지 않다면, 조금 느려도 이해하기 쉬운 코드가 더 합리적이다. 때로는 아주 영리하고 빠른 것보다 단순하고 느린 것이 더 나은 선택인 이유다.
 

장황한 코드

필자의 한 동료는 줄임표와 같은 자바스크립트의 새로운 연산자를 모두 사용하는 것을 좋아한다. 그 결과 코드는 더 간결해지고 나아진다. 모든 코드 리뷰에는 새로운 구문을 사용해 코드를 다시 작성할 수 있는 부분에 대한 제안이 함께 돌아온다.

간결한 것이 더 이해하기 쉽다고 확신하지 못하는 동료도 있다. 코드를 읽으려면 새 연산자의 포장을 풀어야 하는데, 그 중 일부는 다양한 방식으로 사용될 수 있다. 연산자가 어떻게 사용되었는지 이해하려면 익숙한 빠른 훑어보기가 아니라 잠시 멈춰서 깊이 생각해야 한다. 코드를 읽는 것은 번거로운 일이 되어 버린다.

사람들이 초밀착형 코드를 싫어하는 이유에는 역사적인 논거가 있다. 사용자 정의 기호 덕분에 엄청나게 치밀하고 효율적으로 설계된 APL 같은 언어는 본질적으로 사라졌다고 봐도 무방하다. 중괄호를 사용하지 않는 파이썬 같은 다른 언어의 인기는 계속 높아지고 있다.

멋진 추상화를 좋아하는 사람은 간결한 새 기능을 계속 밀어붙이고 간결함을 강조할 것이다. 이들은 현대적이고 유행에 발 맞춘다는 점을 강조한다. 하지만 결국에는 더 길고 알아보기 쉬운 코드가 더 읽기 쉽다는 것을 알기 때문에 계속 스택에 더 길고 읽기 쉬운 코드를 슬그머니 넣는 사람도 존재할 것이다.
 

오래된 코드

프로그래밍 언어를 설계하는 사람들은 특정 유형의 문제를 쉽게 해결할 수 있는 영리한 추상화 및 구문 구조를 발명하는 것을 좋아한다. 프로그래밍 언어는 추상화로 가득 차 있기 때문에 매뉴얼만 1,000페이지가 넘는 경우도 있다.

곧 권력의 제1 규칙이 “사용하지 않으면 잃는다”라는 주장이다. 1,000페이지에 달하는 매뉴얼에 설명된 모든 구문을 다 사용하는 것이 최선이라고 생각하기 때문이다.

그러나 항상 좋은 규칙은 아니다. 기능이 너무 많으면 혼란을 야기한다. 이제 어떤 프로그래머도 모든 구문 기믹에 능통할 수 없을 정도로 영리한 구문 기믹이 많이 등장했다. 왜 그래야 할까? 예를 들어 무효를 테스트하거나 상속이 다차원에서 작동하도록 하려면 얼마나 많은 방법이 필요할까? 그 중 어느 것이 옳은 방법, 아니면 다른 방법보다 나은 방법일까? 물론 적극적으로 이러한 논쟁을 막으려는 개발자도 있을 것이다.

기능 세트의 한계를 결정 지은 언어 개발자들도 나타났다. 고(Go) 언어 개발자들은 하루라도 빨리, 어쩌면 단 1일 만에 배울 수 있는 언어를 만들고 싶다고 말했다. 팀 내 모든 코더가 모든 코드를 읽을 수 있어야 한다는 의미다. 기능이 적을수록 혼란도 줄어든다.
 

나만의 코드 롤링

효율성 전문가는 "바퀴를 재발명하지 말라"라고 조언한다. 충분한 테스트를 거쳐 바로 실행할 수 있는 스톡 라이브러리를 사용하라. 이미 검증된 레거시 코드를 사용하라.

때로는 새로운 접근 방식이 합리적일 때도 있다. 라이브러리는 제너럴리스트와 일상적인 사용례를 위해 작성되는 경우가 많다. 데이터의 일관성을 보장하고 사용자가 잘못된 매개변수를 전송하여 작업을 망치지 않도록 벨트 앤 서스펜더 테스트가 많다. 하지만 특수한 경우라면 몇 줄의 특수 코드가 훨씬 더 빠르다. 라이브러리가 할 수 있는 모든 작업을 수행하지는 못하지만 필요한 작업을 절반의 시간 안에 처리할 수 있다.

위험한 경우도 있을 것이다. 암호화 시스템처럼 너무 난해하고 복잡한 코드도 있어서 모든 수학을 알고 있더라도 함께 조합하는 것은 좋은 생각이 아니다. 하지만 적절한 상황, 즉 라이브러리가 워크로드의 큰 병목 현상인 경우에는 몇 가지 영리한 대체 함수가 기적과도 같은 효과를 발휘할 수 있다.
 

너무 이른 최적화

프로그래머가 코드를 몇 가지 조합하고 나서 ‘조기 최적화는 시간 낭비’라는 오래된 격언으로 빠른 작업을 정당화하는 경우가 많다. 전체 시스템을 가동하기 전까지는 코드의 어느 부분이 진짜 병목 현상이 될지 아무도 모른다는 생각에서다. 1년에 한 번만 호출될 기능이라면 훌륭한 기능을 만드는 데 시간을 낭비하는 것은 어리석은 일이다.

일반적으로는 잘 통용되는 좋은 경험칙이다. 지나친 계획과 과도한 최적화 때문에 출발선을 벗어나지 못하는 프로젝트도 있기 때문이다. 하지만 조금만 미리 생각하면 큰 차이를 만들 수 있는 경우도 많이 있다. 때로는 잘못된 데이터 구조와 스키마를 선택하면 사후에 최적화하기 어려운 아키텍처가 만들어지기도 한다. 때로는 구조가 코드의 너무 많은 부분에 구워져 있어서 약간의 영리한 리팩터링만으로는 해결되지 않는 경우도 있다. 이러한 경우에는 약간의 조기 최적화가 정답이 될 수 있다.
 

부주의

훌륭한 프로그래머는 일방통행로를 건너기 전에 양쪽을 모두 살펴본다는 것을 누구나 알고 있다. 데이터를 처리하기 전에 항상 데이터를 두 번, 세 번 확인하는 추가 코드를 많이 삽입해야 한다. 널 포인터가 잘못 들어갈 수도 있기 때문이다.

안타깝게도 이렇게 많은 주의를 기울이면 코드가 느려질 수 있다. 때로는 성능 때문에 본능을 무시하고 그다지 신경 쓰지 않는 코드를 작성해야 할 때도 있다. 빠르게 실행되는 코드를 원한다면 최소한의 작업만 하고 그 이상은 하지 말아야 한다.
 

불일치

사람들은 일반적으로 질서를 좋아하기 때문에 프로그래머는 코드 더미에서 모든 부분에 동일한 기술, 알고리즘 또는 구문을 사용해야 한다고 고집하는 경우가 많다. 이러한 부지런함은 나중에 코드를 이해해야 하는 사람의 삶을 더 쉽게 만들어 준다.

반면, 일관성을 유지하려면 시간이 걸리고 때로는 복잡해지기도 한다. 차이점을 수정하려면 잘못된 경로를 따르는 모든 코드를 처음부터 다시 작성해야 하고, 그것만으로도 예산에 부담을 줄 수 있다.

더 심각한 문제는 서로 다른 섹션 간의 관계다. 레거시 코드에 의존하는 프로젝트도 있고, 라이브러리에 의존하는 프로젝트도 있다. 완전히 별도의 회사에서 완전히 다른 사람들이 작성한 API 없이는 작동할 수 없는 프로젝트가 많다.

그룹 간의 차이를 부드럽게 조정하는 것은 불가능하며, 최신 비전에 맞게 전체 스택을 다시 작성할 수 있는 횟수도 제한되어 있다. 우리 뇌의 이상한 구석에서는 완벽한 질서를 갈망하지만, 어쩌면 불일치와 화해하는 것이 더 나을지도 모른다.
 

종소리와 휘파람을 따라가기

지나친 일관성의 또 다른 문제는 혁신을 방해한다는 점이다. 일관성은 기존 업무 방식을 고집하는 일종의 경직된 태도를 조장하기도 한다.

새로운 기능을 추가하거나, 새로운 라이브러리를 도입하거나, 스택을 새로운 API와 통합하려면 기존 패턴을 깨야 할 때가 있다. 물론 코드를 읽는 동안 기어를 바꿔야 하는 사람의 삶이 조금 더 어려워지겠지만, 이것은 발전의 대가다. 또한 코딩을 재미있게 만드는 요소 중 하나이기도 하다.
 

규칙 깨기

재미를 위해 구글의 제미나이에게 프로그래머가 코드를 만드는 과정에서 규칙을 어긴 적이 있는지 물어보았다. 제미나이는 "프로그래머가 특정 규칙을 어겼다기보다는 저와 같은 대형 언어 모델을 만들 때 모범 사례의 한계를 넘어섰다고 말하는 것이 더 정확합니다"라고 대답했다.

"제미나이는 "저와 같은 대형 언어 모델은 방대한 양의 데이터로 학습하며, 모델이 데이터를 통해 학습하는 방식에는 '미지의 요소'가 존재합니다. 대형 언어 모델을 만드는 데 사용되는 일부 기술은 매우 효율적일 수 있지만 모델이 어떻게 답을 얻는지 정확히 이해하기는 어려울 수 있습니다”라고 말했다.

그렇다. LLM은 기존의 규칙이 바뀌고 있다는 사실을 사람보다 더 잘 알고 있다. 방대한 훈련 세트를 상자에 넣을 수 있다면 알고리즘을 이해하는 데 많은 시간을 할애할 필요가 없을지도 모른다. 그러니 인간답게 LLM이 규칙을 준수하도록 하자.
editor@itworld.co.kr