아마 이 글을 읽고 계신 개발자라면 한번쯤은 이런 고민을 해봤을 것이라고 생각합니다.

내가 작성하고 있는 코드의 품질은 어떨까? 잘 짜여진 코드라고 할 수 있을까?

과연 좋은 품질의 소스 코드, 좋은 품질의 소프트웨어란 무엇일까요? 그리고 좋은 품질의 소프트웨어를 만들기 위해서는 어떠한 노력을 해야할까요?

소프트웨어 품질의 정의

우선 소프트웨어 품질의 정의에 대해서 먼저 얘기해보겠습니다. 소프트웨어 공학에서 품질은 두 가지 부분에서 구분되는 개념을 가지고 있습니다.

  • 소프트웨어 기능 상의 품질 (Software Functional Quality)은 기능 요건이나 사양에 기반하여 주어진 설계를 얼마나 잘 충족하고 있는지를 반영한다. 이러한 특성은 소프트웨어의 목적이 부합하는지, 또 가치가 있는 상품으로서 시장의 경쟁작들과 비견할만한지를 기술할 수 있습니다.
  • 소프트웨어 구조 상의 품질 (Software Structural Quality)은 기능 요건의 전달을 지원하는 비기능 요건을 어떻게 충족하는지를 가리키는데, 이를테면 소프트웨어가 올바르게 개발될 수 있는지를 가늠하는 척도로서 내구성이나 유지 보수성을 들 수 있습니다.

소프트웨어 품질은 소프트웨어 내부 구조, 소스 코드, 기술 수준, 시스템 수준의 분석 과정이나 소프트웨어 기능 테스트를 통해 측정할 수 있습니다.

ISO/IEC 25000

소프트웨어 공학에서는 소프트웨어 개발 공정 각 단계에서 산출되는 제품이 사용자 요구를 만족하는지 검증하기 위해 품질 측정과 평가를 위한 모델, 측정기법, 평가방안에 대한 통합한 국제표준을 만들어 관리하고 있습니다. (https://ko.wikipedia.org/wiki/ISO_25000)

ISO/IEC 25000의 제정 목적은 기존 소프트웨어 품질 평가에 대한 혼란을 제거하고 일관성을 제공하는 한편, 품질 요구 명세부터 평가에 이르는 통합된 표준 지침을 제공하기 위함입니다. ISO/IEC 25000에서는 소프트웨어의 기능성 이외의 특성인 신뢰성, 사용성, 이식성, 효율성, 유지보수성을 주요 항목으로 평가합니다.

소프트웨어 품질 관리 목적

그렇다면 소프트웨어의 품질을 관리해야 하는 이유는 무엇일까요? 소프트웨어가 변화의 핵심이 되고, 산업에서 차지하는 비중이 커지면서 소프트웨어 핵심 기술을 확보하는 것만큼이나 소프트웨어를 잘 만드는 것은 중요한 문제가 되고 있습니다.

만약 소프트웨어 품질이 낮다면 어떤 일이 벌어질까요? 우선 고객의 신뢰를 높이기가 어렵습니다. 서비스를 사용하는데 수시로 문제가 생긴다면 고객들은 서비스를 신뢰하지 못하고 이탈할 가능성이 높아집니다. 그리고 발생한 이슈를 처리하기 위한 별도의 비용이 발생합니다. (인적, 물질적, 시간적) 이러한 불필요한 발생 비용을 줄이기 위해서라도 소프트웨어 품질을 유지하기 위한 노력을 지속적으로 행해야 합니다.

QP (Quality Practice) 품질 혁신 활동

앞에서 살펴본대로 소프트웨어 품질을 높이는 것은 분명 중요한 일이고, 개발자 모두가 관심을 가져야 하는 내용입니다. 코드 품질을 높이기 위해서는 코딩 컨벤션, 단위 테스트, 정적 분석 등 여러 가지 방법이 있는데 그 중 몇 가지 내용들을 살펴보겠습니다.

코딩 컨벤션

코딩 컨벤션은 여러 개발자가 동일한 규칙을 가지고 코드를 작성하는 것을 의미합니다. 규칙에는 클래스, 메서드, 변수의 이름을 짓는 네이밍 규칙과 줄 바꿈, 들여쓰기와 관련된 코드 스타일, 주석 작성 방법 등이 포함됩니다.

코드 리뷰

코드 리뷰는 작성한 코드에 대해 다른 사람의 리뷰를 통해 오류를 미리 검출하고 수정하는 것을 의미합니다. 상호간에 코드 리뷰를 수행함으로써 미래에 발생할 사이트 이펙트를 예측하거나 구조적으로 문제가 있는 부분을 찾아서 이를 개선할 수 있습니다. 코드 리뷰는 PR (Pull Request)을 통해 진행하는 방법과 릴리즈 전 리뷰 미팅 일정을 잡아 진행하는 방법이 있습니다.

단위 테스트

각 메서드 단위로 테스트 코드를 작성하여, 구현한 메서드가 기능적으로 문제가 없는지, 실행 시 오류가 존재하는지 검출하고 수정하는 행위입니다. 별도의 테스트 코드를 작성해야 하기 때문에 대부분의 개발자들은 이를 번거로운 작업이라고 생각할 수 있지만 테스트 과정에서 오류를 검출할 수 있기 때문에 굉장히 중요한 작업이라 할 수 있겠습니다. 물론 테스트 코드를 잘못 작성하면 오류를 검출할 수 없는 문제가 발생할 수도 있어 테스트 케이스, 테스트 시나리오 등을 꼼꼼히 확인 후 테스트 코드를 작성할 필요가 있습니다.

코드 커버리지

단위 테스트 시 소스 코드의 각 라인이 몇번 실행되었는지 분석하는 것을 의미합니다. 이를 통해 현재의 단위 테스트가 실제로 테스트하는 코드의 범위를 파악하여 테스트의 취약한 부분을 발견하여 보완할 수 있게 합니다. 만약 단위 테스트를 수행했는데 테스트에 사용된 소스 코드의 범위가 많지 않다면 올바르게 작성되지 않은 테스트 코드라고 볼 수 있고 이를 개선하여 좀 더 견고한 테스트 코드를 작성할 수 있게 됩니다.

정적 분석

정적 분석 도구를 이용하여 소스 코드 또는 바이너리 파일 분석을 통해 잠재적인 결함을 찾아내는 것을 의미합니다. 잠재적인 결함이라 함은 문법 부터 묵시적 형 변환, 성능 등 다양하며 개발자가 확인할 수 없는 정보들을 분석하여 제공해줌으로써 소프트웨어를 개선할 수 있도록 도와줍니다. 정적 분석은 말 그대로 정적 분석이기 때문에 런타임 환경에서 동적으로 처리되는 부분까지 100% 검출하기는 어렵습니다.

중복 코드 제거

소스코드 내에 존재하는 중복 코드를 제거하여, 추후 발생할 수 있는 유지보수 상의 문제점을 방지합니다. 만약 중복 코드가 존재하고 코드에 대한 수정이 한쪽에서만 발생한다면 수정되지 않은 코드는 다른 오류를 야기하거나 예상하지 못한 결과를 리턴 할 수도 있기 때문에 이러한 중복 코드를 제거하여 하나의 코드에서 기능이 동작할 수 있도록 리팩토링 작업을 수행해야 코드의 일관성과 안정성을 유지할 수 있습니다.

마치며

OpsNow 개발팀에서도 코딩 컨벤션 준수, Sonarqube를 통한 정적 분석, Unit Test 등 코드 품질을 높이기 위한 여러 활동들을 수행하고 있습니다. 코드 품질을 높이는 것은 고객에게 더 좋은 서비스를 제공하기 위한 가장 기본적인 행위입니다. 이러한 활동들을 꾸준히 진행하면서 언제나 좋은 코드를 작성하려고 노력하는 것이 개발자로서 보람을 느끼고 좋은 서비스를 만드는 데 기여할 수 있는 가장 최고의 방법이 아닐까 생각됩니다.