(번역) 좋은 코드/나쁜 코드란? 프로그래머가 아닌 사람들을 위한 예시

이 글은 Medium에 있는 Todd Gillies의 What is good/bad code? An illustrated example for non-programmers을 허락받고 개인적인 학습 목적으로 번역한 내용입니다. 

번역에 문제가 있는 경우 댓글로 알려주시면 감사하겠습니다.

---

옛날 어디선가 다음과 같은 내용을 담고 있는 인용문을 읽은 적이 있습니다:

"현대 세계의 많은 사람들의 삶은 대형 여객기를 제어하는 시스템 와 같은 소프트웨어에 의존하고 있지만, 소프트웨어 개발 분야는 대부분 규제를 받고 있지 않습니다. 누구든지 독학으로 소프트웨어 개발자가 될 수 있지만, 높은 건물을 세우는 엔지니어나 신경외과와 같은 중요한 직업처럼 자격증이나 엄격함이 없습니다. 이 분야는 위험할 정도로 규제를 받지 않았고, 특수한 경우에는 나쁜 코드 몇 줄로 사람의 목숨을 앗아갈 수 있습니다.

 

저는 이 문구를 유명한 출판물에서 봤던 걸로 기억하고 있습니다. 그리고 그 기사의 제목은 "나쁜 코드를 조심하세요, 그것은 당신을 죽일 수 있습니다, 아 하지만 잠시만요, 이를 볼 수 없으니깐 신경 쓰지 마세요!"였습니다. 독자들을 위한 메시지라고 생각이 들지 않나요? 이 기사는 단순히 독자층을 늘리기 위해 점점 우리를 둘러싸고 있는 여객기, 기차, 자율주행 차량에 숨어 있는 "나쁜 코드"를 선정적으로 부각하는 걸 수도 있습니다. 

 

비전문가의 입장에서 "나쁜 코드"는 무엇일까?

매일 5시간씩 쓰고, 리뷰하고, 리팩토링 (코드를 더 간결하고 재사용이 가능한 방식으로 수정하는 의미)하는 사람으로 , 코드가 뭐인지 알고 있습니다 (그리고 나쁜 코드가 무엇인지도요!). 때때로 사람들이 코드에 대한 개념을 가지고 있지 않다는 사실을 잊어버립니다. 

 

그런 분들을 위해 이 질문을 드리고 싶습니다 "만약 당신이 코딩하는 사람이라면, 무엇을 할 건가요?":

 

"저는 다양한 구성과 다양한 방식으로 열고 닫히는 작은 출입문의 조립품을 만들 겁니다. 출입문이 열리면 전자들이 통과할 수 있지만 닫혀 있으면 통과를 할 수 없습니다. 이 출입문들은 너무 작아 손으로 만들 수 없기 때문에, 컴퓨터로 만들 수밖에 없습니다. 컴퓨터에 입력되는 단어에서 따라서, 저를 대신해 다양한 종류의 작은 출입문들을 만들어 줍니다. 

 

위에 있는 답변에서도 알 수 있듯이 소프트웨어 개발/코더/프로그래머 들은 실제로 물리적으로 존재하지만 너무 작아 볼 수 없는 것들을 만들고 있습니다 (작은 출입문의 조립품으로 생각할 수 있음). 방금 그 말을 상상이라도 할 수 있게 된다면, 축하드립니다 "코딩"이 무엇인지에 대한 개념적인 이해를 이루어 냈습니다! 이제 이 섹션의 주제로 돌아가봅시다 - "나쁜 코드란?"

 

방금 비유를 계속해보면, 나쁜 코드란 너무 많은 출입문을 가지고 있거나, 불필요하게 반복적이거나 복잡한 방식으로 배열했다고 할 수 있습니다.

 

지금 이 비유를 계속 사용하기에는 시각화하거나 설명하기 어렵기 때문에, 다른 비유를 아래에 제시하고자 합니다. 

 

다른 손잡이를 돌리는 손잡이를 만들어 주세요!

다른 손잡이를 돌리는 손잡이를 만든다고 가정해 봅시다. 손잡이를 돌리면 다른 위치에 있는 손잡이도 같이 돌아가게 만듭니다. 제품 요구사항은 아래와 같습니다. 한 손잡이를 돌리면 일정 거리 떨어져 있는 다른 손잡이도 함께 회전을 시킵니다: 

다른 손잡이를 돌리는 손잡이 이게 저희한테 필요한 시스템입니다,

 

나쁜 코드는 현재 손에 들어와 있는 문제만 생각합니다, 그리고 이를 해결하기 위한 가장 쉬운 솔루션을 제안합니다 - 반유 연한 봉으로 연결된 두 개의 손잡이. 초기 단계에서는 나쁜 코드가 더 좋아 보입니다. 좋은 코드는 고무벨트와 2개의 바퀴로 구성하여 지금처럼 쉬운 요구사항에는 과한 것처럼 보입니다. 

 

요구사항 변경! 손잡이 위치가 바뀝니다!

개발 주기에서 고객이 제품에 대한 요구사항을 변경하는 경우가 거의 항상 일어납니다. 이 예시에서 고객은 이제 아래와 같이 손잡이들의 위치를 바뀌고 싶어 합니다, 바로 뒤에 있는 손잡이 아닌, 뒤에 그리고 측면에 있는 손잡이를 돌리고 싶어 합니다. 

이런! 요구사항 변경!

 

나쁜 코드의 경우에는 몇 가지 불안정한 구성을 추가해야 하므로, 시스템 전체가 더욱 불안정해지고 오류에 취약해집니다. 좋은 코드의 경우에는 더 긴 고무벨트로 바꾸는 사소한 조정만 하면 새로운 요구사항을 해결할 수 있습니다.

나쁜 코드의 경우에는 불안정한 제품이 되었다

 

요구사항 변경! 손잡이가 느리게 돌아야 한다!

마지막으로, 저희 고객이 손잡이들을 서로 다른 속도로 돌아가길 원합니다. 손잡이를 조금만 돌려도 연결된 손잡이가 크게 돌아야 한다. 

 

이 새로운 요구사항을 위해서 나쁜 코드는 제품에 더 많은 구성을 추가해야 돼서 더 복잡하게 만든다. 그와 반대로, 좋은 코드는 더 큰 바퀴로 변경하는 사소한 조정만 하면 된다:

 

예시를 든 후: 결론은?

위에서 본 것처럼, 좋은 코드는 요구사항이 간단할 때는 과해 보이지만, 고객의 요구사항이 변경될 때마다 그 진가를 보여줍니다 (항상 그렇듯이). 즉, 확장 및 변화에 유연합니다. 반면, 나쁜 코드는 단순해 보이고 간단한 문제에는 훌륭한 것처럼 보이지만, 시스템이 바뀌거나 복잡성이 증가하면 개발자한테 악몽이 됩니다. 

 

하지만 지금 이렇게 생각하실 수도 있습니다, "위에 나와 있는 두 가지 시스템 모두 같은 결과를 내니깐 둘 다 성공한 게 아닌가?"

 

혼자 코딩하거나 취미로 프로젝트를 하는 경우에는 문제가 없습니다. 저 혼자서 수 만 줄의 나쁜 코드 (저 같은 경우 Vanilla JS)를 써도 문제가 없었고 유지보수하거나 코드를 추가하는데 문제를 겪었던 적은 없었습니다 (여기 이 www.python-gui-builder.com 사이트를 위한 2,422줄의 코드를 확인해 보세요). 코드가 작동하여 릴리스를 했고 그 뒤로 다시 확인한 적이 없습니다.

 

하지만, 전문적인 코딩의 본질은 공동 작업이며, 여러분들이 작성한 코드는 의심할 여지없이 현재나 미래에 다른 개발자가 지속적으로 읽고 추가로 개발할 것입니다. 코드가 읽기 쉬울수록 다른 개발자들은 더 쉽고 효율적이게 일을 할 수 있습니다.

1. "여기 바퀴 2개와 벨트로 구성된 다른 손잡이를 돌리는 손잡이가 있어", 아니면
2. "이 걸이가 연결을 위한 봉을 고정하고, 이게 연결을 위한 봉이고 이 봉을 이 끝에 있는 작은 걸이에 넣어야 돼...."

당신이 주니어 개발자로서 시니어 개발자로부터 코드를 받을 때 어떤 말을 더 듣고 싶으신가요? :)