좋은 코드란

좋은 프로그래머는 좋은 코드를 작성한다.

코딩을 처음 시작하고 얼마 안된 시점까지는 아무렇게나 코드를 짜도 실력이 늘었다. 아무 프로그램을 하나 개발해보면 대충 코드를 어떻게 짜야 될지는 감이 잡힌다.

그러나 어느 순간부터 '아무렇게나' 코드를 짠다고 실력이 늘지 않는다는 걸 깨닫는 순간이 온다. 이때부터 성장하기 위해 좋은 코드가 무엇인지에 대한 고민을 하기 시작한다.

왜 좋은 프로그래머는 좋은 코드를 작성할까? 나쁜 코드를 작성해서는 안되는 걸까? 애초에 좋은 코드는 뭐고 나쁜 코드는 무엇일까?

내가 생각하는 좋은 코드에 대해서 정리해 보았다.

왜 좋은 코드를 짜야 할까?

좋은 프로그램을 만들기 위해서이다.

간단한 계산을 위해 코드를 작성하는 경우가 있다. 작성하는 코드의 양이 많지 않고 앞으로 변화에 대응할 일이 많지 않다. 아예 한번 코드를 짜놓고 다시는 보지 않는 경우도 흔하다. 초보적인 수준의 코드이므로 좋고 나쁨을 논할 여지가 적다. 학부 수준의 과제가 그렇다. 학교 과제만 열심히 푼 사람은 좋은 코드에 대해 고민할 이유를 느끼지 못할 것이다.

그러나 소프트웨어는 점점 복잡해지면서 동시에 거대해지고 있다. 이 말은 요구사항이 점점 더 복잡해지고 있다는 말과 같다. 프로그램이 작을 때는 알아차리지 못했던 여러 문제들이 곳곳에서 터질 수 있다. 좋은 코드는 그런 문제들을 줄여준다. 따라서 프로그램을 만들 때 드는 자원(시간, 돈)을 줄일 수 있게 해준다.

좋은 코드란?

좋은 코드는 한마디로 정의할 수 없다. 추상적인 단어이기 때문이다.

그럼 어떤 코드보다 나은 코드에 대해 생각해 보자. 똑같은 요구사항을 구현하는 코드 두 개를 두고 어느 코드가 더 '나은' 코드인지 평가하는 건 기준만 있다면 좋은 코드를 정의하는 것 보다 쉬운 일이다.

따라서 우리는 어떤 코드가 나은 코드임을 확인하는 보편적인 기준을 세울 수 있다. 이렇게 평가된 점수가 일정 수준 이상이라면 우리는 그 코드를 좋은 코드라고 할 수 있다.

그 커트라인이 어느정도인지는 사람마다 팀마다 모두 다르다. 심지어는 어떤 기준을 가지고 평가하는 지도 다를 수 있다. 그래서 프로젝트별로 적절한 합의안이 필요하다.

여기서는 내가 생각하는 좋은 코드와 그 기준에 대해서 이야기한다.

좋은 코드의 기준

좋은 코드의 기준에 대해 생각해 보자.

실행 속도가 빠르다

GoodFirms의 조사에 따르면 웹 페이지를 방문할 때 이탈하는 이유로 느린 로딩을 88.5퍼센트의 사람들이 꼽았다. 비단 웹 페이지 뿐만이 아니다. 느린 프로그램을 사용하고 싶은 사람은 아무도 없다. 프로그램의 동작 속도는 빠르면 빠를 수록 좋다.

모순이 없다.

여기서 모순이란 프로그램에 존재하는 버그, 그리고 코드의 구조를 말한다. 하나하나 살펴보자.

프로그램에 버그가 많으면 유저가 정상적으로 프로그램을 사용할 수 없다. 유저의 사용 경험과 직결된 문제이므로 프로그래머는 버그가 발생하지 않도록 노력해야 한다.

코드의 구조가 잘 짜여있으면 다양한 요구사항을 큰 수정 없이 적용하기 쉽다. 유저는 코드의 구조가 좋은지 나쁜지 알 수 없지만 코드의 구조가 나쁘면 변화에 대응하기 어렵기 때문에 프로그램 혹은 기능 출시 속도에 영향을 미친다.

가독성이 좋아야 한다.

흔히 말하는 클린코드이다. 나는 '깨끗하다' 라는 표현이 직관적이지 않다고 생각해서 가독성이 좋은 코드라고 표현한다.

역시 유저는 코드가 가독성이 나쁜지 알 수 없다. 그러나 코드가 읽기 어려우면 코드를 수정할 때 많은 시간이 소요된다.

기준의 중요성은 상대적이다.

총 세 가지 기준들을(버그와 구조를 분리한다면 네 가지) 살펴보았다. 어떤 기준이 가장 중요하다고 묻는다면 나는 프로젝트마다 다르다고 말한다.

속도에 민감한 프로젝트가 있다. 컴파일러, OS 커널, 게임 서버 같은 것들이 있을 수 있다. 이들은 다른 기준들을 희생해서라도 속도를 최대한 높이려고 한다.

버그를 줄이는 것이 중요한 프로젝트가 있다. 버그가 나면 사람의 목숨이 왔다갔다 하는 것들이 보통 그렇다. 항공기 소프트웨어, 의료기기 펌웨어등이 있다.

가독성은 대부분의 프로젝트에서 중요하게 여긴다. 보통 소규모 프로젝트보단 대규모 프로젝트에서 민감하게 생각하는 편이다.

다만 그렇다고 해서 어느 기준 하나를 아예 무시해서는 안된다. 뭐든지 균형이 중요하다.

좋은 제품 코드

좋은 코드가 좋은 제품에 들어가는 코드를 의미하는 건 아니다. 제품을 만들다 보면 얼마든지 나쁜 코드가 있을 수 있다. 예상되는 추가 기능이 없는 프로젝트에서 가독성이 좋지 않은 코드를 리팩터링하고 있는 건 시간 낭비이다. 그 시간에 더 가치있는 작업을 할 수 있다.

좋은 제품을 만들기 위해서는 어떤 기능,코드에 시간을 더 많이 쏟을 지 잘 결정해야 한다. 자원은 항상 한정되어 있고 그 한정된 자원을 가지고 우수한 결과물을 만들어 내는 프로그래머가 좋은 프로그래머이다.

마치며

최근 다른 개발자들과 이야기할 일이 종종 있었는데, 그 때마다 내가 생각하는 좋은 코드를 바로 설명하기가 어려웠었다. 때문에 글로 정리해보았다. 한번 정리해 보니 이제는 확실히 설명할 수 있을 것 같다.

좋은 코드의 기준을 아직 확립하지 못한 프로그래머에게 도움이 되었으면 좋겠다.