높은 품질의 코드를 작성하기 위한 노력
우리는 높은 품질의 코드를 작성하기 위해 테스트 코드를 작성한다. 이런 코드 분석 방식을 동적 분석(dynamic analysis)라고 한다. 동적 분석은 런타임 환경에서 수행된다.
개발자는 개발자가 예상할 수 있는 모든 케이스에 대해 테스트 코드를 작성하고, 테스트 코드를 실행하여 현재 코드가 테스트를 모두 통과하는지 확인한다. 동적 분석 과정을 통해 개발자는 높은 품질의 코드를 작성할 수 있고, 견고한 어플리케이션을 만들 수 있다.
하지만 동적 테스트만으로는 코드의 모든 문제를 발견할 수 없다. 예를 들어 잘못된 입력이 들어와 0으로 나누어 버린다면? 개발자가 이런 케이스를 예상하지 못하고, 테스트 코드를 작성해두지 않았다면 이런 문제를 동적 분석으로는 발견할 수 없을 것이다.
물론 이런 문제들은 개발자가 조금 더 꼼꼼하게 테스트 코드를 작성하면 어느정도 해결할 수 있는 문제일 것이다. 하지만, 기능이 모두 동작한다고 해서 코드가 완벽한 상태일까? 분명 아닐것이다. 분명히 더 개선될 여지가 있다.
소스코드에서 문제를 일으킬 가능성이 농후한 코드의 특징을 코드 스멜(code smell)이라고 불린다. 이런 코드 스멜은 동적 분석으로는 발견할 수 없다.
그렇다면, 우리 개발자 모두가 이런 잠재적인 문제점을 눈에 불을 켜고 찾아다녀야할까? 코드리뷰 문화를 도입하는 것도 방법일 것이다. 하지만 사람은 실수하기 마련이다. 그리고 애초에 사람이 모든 코드 스멜을 찾아내는 것은 큰 리소스 낭비이다.
더 좋은 방법이 없을까? 바로 정적 분석(static analysis)을 사용하는 방법이다.
정적 분석
정적 분석이란 소스 코드의 실행 없이 정적으로 프로그램의 문제를 찾는 과정을 의미한다. 이처럼 동적 분석과 가장 큰 차이는 분석 시점이다. 동적 분석은 앞서 말했듯 런타임 환경에서 코드의 문제를 발견한다. 하지만, 정적 분석은 비 런타임 환경에서 수행된다.
왜 정적 분석을 사용할까?
정적 분석 도구를 사용하면 코드에서 아래와 같이 흔히 코드 스멜(code smell)이라고 불리는 문제들과 보안 취약점 등의 문제를 발견할 수 있다.
- 잠재적으로 버그가 발생할 수 있는 코드
- 안티 패턴
- 코드 스타일(컨벤션) 위반 여부
- 성능 문제
- 오타
- 사용되지 않는 코드
- 잠재적인 보안 취약점
이런 코드 스멜은 이미 많은 현장에서 발생한 문제 사례로부터 많은 규칙화가 되어있다. 정적 분석 도구는 이런 수 많은 개발자들의 경험과 노하우를 사용하여 소스코드를 분석하고 코드 스멜을 발견한다.
또한 정적 분석은 코드 스타일을 위반했는지에 대한 검사도 수행해준다. 따라서 여러 사람이 함께 참여하는 프로젝트에서 코드 스타일을 통일하는데에도 큰 도움이 될 수 있다. 이런 코드 스타일 규칙은 여러 회사에서 코드의 높은 유지보수성과 가독성을 위해 만들어진 모범 사례를 기반으로 만들어졌다. 따라서 반드시 지키는 것이 좋다.
정적 분석은 비 런타임 환경에서 동작하기 때문에 코드가 완성되지 않았다고 하더라도 분석이 가능하다. 문제를 동적 분석보다 이른 시점에 잡아낼 수 있다. 또한 동적 분석 방법은 코드가 늘어날 수록 유지보수 해야하는 테스트 코드도 늘어나는데, 정적 분석은 이런 문제가 존재하지 않다.
높은 코드 품질을 위해서 팀 프로젝트에 동적 분석과 정적 분석을 모두 적용하는 것이 좋을듯 하다.
마치며
처음 우테코 팀 프로젝트 필수 요구사항에서 정적 분석 리포트를 제공하라는 이야기를 들었을 때, 굉장히 생소하다고 생각했었다. 그런데 알고보니 리액트 개발을 할 때 항상 써왔던 ESLint가 정적 분석 도구의 한 종류란 것을 알게되었다. 사실 그렇게 멀게 있던 개념이 아니었던 것이다.
이제 곧 프로젝트에 SonarQube나 Jacoco 같은 정적 분석 도구를 적용하게 될 것 같다. 처음 해보는 것들이라 기대된다.