이 질문은 너무 추상적입니다. 질문이 너무 추상적이어서 답하기 어려울때는 좋은 질문 하기를 하면 좋습니다. 우리가 이 질문을 통해서 얻고자 하는 것은 무엇일까요? 프로그래머로서 우리는 왜 좋은 코드를 만들어야 하나요?

우리는 코드로 제품을 만듭니다. 그리고 사용자는 돈을 지불하고 제품을 구매하거나 서비스를 구독합니다. 우리가 코드를 작성하는 궁극적인 이유는 사용자가 돈을 지불하고 소비할만한 가치를 전달하기 위해서 입니다. 고객 만족이라고 말할 수 도 있습니다.

그렇다면 이 목적을 달성하게 해주는 코드가 좋은 코드라고 말할 수 있습니다. 그러면 질문을 이렇게 바꿔볼 수 있겠죠.

질문이 구체적이 되었지만 이 질문 역시도 쉽게 답할 수 있는 질문은 아닙니다. 어떤 고객인지, 어떤 제품인지에 따라서 다양한 답이 나올 수 있겠죠. 프로젝트의 환경에 따라서 다른 질문과 다른 답이 나올 수 있습니다. 하지만 프로젝트마다 가진 고유함이 있다고 해도 일반적인 IT 제품이라면 공통적으로 갖는 특징도 있을 수 있겠죠.

프로젝트를 떠나서 필수적으로 지은 기능이 동작하는 소프트웨어를 만드는 것입니다. 코드 품질과 상관 없는 당연한 얘기처럼 들릴 수도 있지만 현실에서는 이 당연한 벽을 넘지 못해서 기준 미달이 되는 경우가 많습니다. 너무 당연한 것이라서 오히려 주의하지 못하는 것이죠. 고객의 니즈를 충족시키는 기능인지, 기능대로 동작하고 있는지 충분히 확인하지 않은 채 구현 방법이나 코드 설계에만 몰입하는 실수를 저지릅니다. 그래서 유저에게 필요한 기능을 유저가 원하는 방식으로 잘 제공하는 것만으로도 평균 이상의 성과를 낼 수 있습니다.

동작하는 소프트웨어를 만들기 위해서는 가장 필요한 스킬은 무엇일까요? 그것은 뛰어난 설계 역량이나 언어나 운영체제에 대한 깊은 이해가 아닙니다. 바로 테스트입니다. 고객의 입장에서 테스트 케이스를 만들고 꼼꼼하게 테스트하는 것입니다. 자신이 구현한 코드가 고객에게 가치를 제공하는지 검토하고 버그나 불편함 없이 예상대로 동작하는지 확인하는 것입니다.

동작하는 소프트웨어. 이 당연한 단계를 넘어서지 못하면 깔끔한 코드나 설계는 아무 의미를 갖지 못합니다. 그러나 현실에서는 테스트에 많은 주의를 기울이는 프로그래머가 적고, 그 결과 열심히 일 하고도 좋은 평가를 받지 못하는 경우가 많습니다.

소프트웨어가 의도대로 동작한다고 전제할때, 좋은 코드는 어떤 가치를 추가로 제공할 수 있을까요?

좋은 코드는 개발시간을 단축합니다. 기능을 추가 변경할 때 고민할 것이 적고 다른 기능을 헤치지 않고 버그가 적게 나옵니다. 팀원 누구라도 작업할 수 있어서 인적 리소스를 효율적으로 배치할 수 있습니다.

좋은 코드는 개발시간을 예상 가능하게 합니다. 예상치 못한 문제나 버그는 개발을 지연시킵니다. 개발 시간이 지연되면 릴리즈 일정이나 스펙에 영향을 주고 매출까지 영향을 줍니다. 발맞추어 진행되던 파이프라인이 어그러지면서 가져오는 비효율이나 감정적 손실도 큽니다.

좋은 코드는 더 많은 스펙을 가능하게 합니다. 어떤 기능을 주어진 시간안에 구현할 수 있는지 여부는 코드 구조에 영향을 많이 받습니다. 또 기능이 많아질수록 코드는 비약적로 복잡해지기 때문에 코드 품질은 구현 가능성이나 버그의 측면에서 더 큰 영향을 줍니다. 많은 기능을 빠른 시간에 버그없이 제공할 수 있다면 고객에게 더 많은 가치를 제공할 수 있겠죠?