66 Embedded World

UEST ARTICLEG

코드 품질을 높이기 위한 정적 분석과 지속적인 통합(CI)- Vol. 1

소개

최근에는 SW가 복잡해지고 고품질의 SW가 요

구되는 반면, 개발팀은 짧은 개발 기간과 지리적

으로 멀리 떨어져 있는 등 여러 가지 도전과제에

직면해 있다.

이 글은 크게 두 부분으로 나눠져 있는데, 첫 번

째 부분에서는 지속적 통합의 원리에 대해 다룬

다. SW 개발 주기를 어떻게 간소화하고 정적 분

석이 어떻게 적용되는지에 대해 설명한다. 두 번

째 부분은 특정 도구를 통해 실제로 어떻게 적용

되는지 알아보겠다. 이것은 Jenkins CI와 PRQA

의정적 분석 도구들(QA·C, QA·C++ and

QA·Verify)을 이용하여 이 도구들이 어떻게 통

합이 되고 어떤 정보를 생성하는지 알아보겠다.

SW 공학에 있어 지속적인 통합(Continuous Integration)은 개발팀의 각 멤버에게 수정된 코드가 통합, Build, 테스트가 제대로 되었는지 확인시켜

주는 기술이다. 지속적인 배포(Continuous Delivery)는 코드가 모든 테스트를 통과하여 배포 가능한 품질을 갖도록 하는 것을 목표로 한다. 정적

분석(Static Analysis)은 코딩 규칙에 입각하며 버그를 줄여 코드의 품질을 향상시킬 수 있는 자동화된 분석이다. 이 세 가지 프로세스와 기술(CI,

CD, 정적 분석)을 함께 적용함으로써 코드 품질을 향상시키고 개발 비용을 절감할 수 있으며 프로젝트 예측을 용이하게 할 수 있다.

원저 : Programming Research Ltd. / Jason Masters, R&D Director번역 : 김관식 / MDS테크놀로지

66-71_Guest Article-MDS.indd 66 14. 3. 27. �� 8:12

www.embeddedworld.co.kr 67

Part 1: 지속적 통합과 지속적 배포

지속적 통합(CI)과 지속적 배포(CD)라는 용어는

보통 같이 사용된다. CD의 궁극적인 목표는 버

전 관리 시스템 저장소에 있는 코드를 확인하고

검증하는 것에 있다. 코드는 모든 요구되는 테스

트들(코딩 규칙 만족, 단위, 테스트, 코드 커버리

지, 인수 테스트, 배포 테스트 등)과 검증 단계를

모두 통과할 것이다. 이런 이유로 언제 코드를 배

포할지에 대한 결정은 개발 또는 엔지니어링측면

에서 결정 될 것이 아니라 제품 매니저로부터 이

루어져야 한다.

하나의 생산된 제품에 하나의 SW를 의미하는 임

베디드SW 부문에서는 지속적으로 배포 가능한

SW라는 것이 관련 없어 보이지만, 이 글에서는

중요한 장점을 말하고 있다.

특히 사용자가 구매 이후 업그레이드가 가능한

SW를 탑재한 제품(필자가 최근에 구매한 LCD

TV에서 소리 문제를 해결하기 위해 SW를 업그

레이드 했다)에 대해서는 더욱 관련이 깊다. SW

는 제품의 가치를 높일 뿐만 아니라 SW에 새로운

기능을 추가하는 것은 영업 전략의 하나가 될 수

있다. SW의 특성 및 기능을 추가하는 것은 소비

자에게 기존의 제품 출시 주기보다 훨씬 더 정기

적으로 업데이트를 제공한다. CI는 개발 단계 중

골칫거리인 통합 과정을 자동화하여 CD를 성공

적으로 수행하는 것을 돕는 기술이다.

문제점

전통적인 개발 모델들은(예: 폭포수, V-모델, 애

자일) ‘단계(phase)’들로 구성되어있다. CI와 관

련 있는 단계는 개발자들이 각자 맡은 파트에 대

한 코드를 작성하는 코딩 단계부터 시작된다. 코

딩 단계를 거쳐 개발이 진행됨에 따라, 개발자들

은 저장소에 그들이 수정한 내용에 대해 commit

을 하겠지만 보통 다른 개발자들의 수정된 코드

를 업데이트 하지 않는다.

일반적으로 나중에 자신이 맡은 부분의 코드가

개발되면 SW Build를 할 목적으로 개인 개발자의

모든 변경사항을 통합단계에서 통합한다.

통합 단계의 시작 날짜는 예측 가능하지만 종료

날짜는 통합이 얼마만큼 걸리는 지에 따라 달라

지기 때문에 예측하기가 매우 어렵다. 개발자들

은 통합 시 충돌이 발생할 수 있는 코드들을 작

성했을 수도 있다. 각 개발자들이 작성한 코드들

은 단독으로는 정상적으로 동작하겠지만 코드들

이 통합 할 때는 각기 변경된 사항들 때문에 호

환성 문제가 발생할 수 있다. 이 충돌들은 반드

시 해결해야 한다.

통합은 중요한 작업이며 극단적인 케이스로 애

초부터 충돌을 제거하는 노력이 코드를 작성하는

데 드는 노력보다 더 많이 소모될 수 있다. 이러

한 문제를 수정하고 노력을 들여야 하는 것이 개

발자들이 저장소로부터 업데이트하는 것을 꺼리

는 이유이다. 다른 개발자의 코드와 다른 개발자

에 의해 발생한 문제를 해결하는데 시간을 낭비

하고 싶지 않은 것이다.

이러한 충돌을 해결하는 데는 몇 가지 방법이 있

다.

한 가지 방법은 개발 프로세스를 변경하는 것이

다. 순서대로 한 명의 개발자만이 저장소에 코드

를 commit하는 방법이다. 코드가 저장소에 com-

mit되면 문제는 즉시 해결될 수 있다. 이것은 한

명 이상의 개발자가 commit하는 것을 포함할 수

있다. 이 결과는 저장소에 충돌을 주지 않지만 비

용 측면에서 문제가 있다.

한 명의 개발자가 commit 중일 때는 저장소 독점

권한을 가져야 한다. 충돌을 제거할 때까지 기다

렸다가 commit를 해야 한다.(또는 전체 commit을

다시 시작해야 할 수도 있다.)

독점권한은 병목현상을 야기할 수 있다. 또한 강

요하기가 쉽지 않다. 몇몇 회사는 commit권한에

대한 순서를 재배치해야 한다. commit할 코드가

없다면, commit을 할 수 없기 때문이다. 위에 열

거한 것들에 대해 많은 개발자가 있는 팀 또는

물리적으로 거리가 있는 팀의 경우에는 관리하

기가 어렵다.

통합 단계의 결과로 실행 가능한 프로그램이 나

오며 그 다음 단계인 테스트 단계로 넘어간다.

그 종류는 다양한데 예를 들면 코딩 규칙 만족

도, 단위, 통합, 시스템, 커버리지, 인수 테스트,

배포가 있다.

코드 품질을 높이기 위한 정적 분석과 지속적인 통합(CI)- Vol. 1

66-71_Guest Article-MDS.indd 67 14. 3. 27. �� 8:12

68 Embedded World

UEST ARTICLEG

각 테스트 단계에서 실패의 의미는 코드는 다시

수정되고 통합되고 테스트되어야 한다는 의미이

다. 잠재적인 문제는 개발자가 코드를 작성하고

다시 코드 작성하는 시간이 얼마나 차이가 나는

지에 따라 발생한다. 시간의 간격이 클수록 그들

의 코드에 익숙해지는데 오랜 시간이 걸리며 다

시 작업하는 시간은 그 만큼 더 오래 걸릴 수밖

에 없다. 다시 작업 하는 것 때문에 프로젝트 기

간은 더 늘어난다.

근본적인 문제는 개발을 단계별로 나눴다는 것이

다. 코드 작성은 여러 단계 중 하나가 아니며 코

딩단계는 통합단계가 시작했다고 끝났다는 의미

가 아닌 것이다. 병렬적으로 일할 수 있는 여러

명의 개발자들에게 개발 작업을 나누고 쪼갠 후

할당하는 것이 상대적으로 쉬워 보이지만 통합의

성격자체로 보았을 때 그 자체가 연속적이며 여

러 명의 개발자에게 동시에 업무를 할당하는 것

은 더 어려운 일이다.

해결방안

하나의 해결법으로 CI는 과거 코딩 단위 테스트,

통합, 시스템 테스트와 인수 테스트 단계를 그림

1로 설명하는 작은 연속적인 단계를 대체한다. 코

딩, 단위 테스트, 통합 테스트, 시스템 테스트, 인

수 테스트로 각 단계가 구성되어 있다. 각 단계

들은 개발자들이 저장소에 변경사항을 commit할

때 마다 실행된다. 모든 변경사항이 통합되고, 테

스트되고, 검증되어 통과된 테스트들은 commit

되고 그 결과는 배포대상에 점점 더 가까워진다.

통합작업을 전체 개발 단계로확장하는 것은 통합

의 부담이 나뉘어져 더 관리할 수 있는 작업으로

변한다는 의미다. 통합 단계에서 초기에 문제들

이 발견되고 개인적으로 처리할 수 있는 기회를

가질 수 없다. 이것이 CI다. 이 접근법은 대다수의

테스트 프로세스와 작업이 자동화될 수 있을 때

적용 가능하다. 모든 저장소에 점진적인 commit

이 수동으로 이뤄진다면 명백하게 불가능하다.

Commit 전 테스트

CI모델의 문제 중 하나는 본질적으로 작업하지

않았거나 이상한, 혹은 호환성이 없는 코드가 저

장소에 들어가지 못하게 막을 수 없다는 것이다.

commit된 코드에 대해서는 문제를 거의 찾아내

66-71_Guest Article-MDS.indd 68 14. 3. 27. �� 8:12

www.embeddedworld.co.kr 69

코드 품질을 높이기 위한 정적 분석과 지속적인 통합(CI)- Vol. 1

지 못한다. 개발자들은 이 정보들을 처리하는 법

과 문제를 수정하는 것에 대해 교육을 받아야 한

다.

CI 모델의 문제 중 하나는 작업하지 않았거나 이

상한, 혹은 호환성이 없는 코드가 저장소에 들어

가는 것을 본질적으로 막을 수 없다는 것이다. 일

단 commit되는대로 발견할 수 있을 뿐이다. 개발

자들은 이 정보들을 처리하는 법과 문제를 수정

하는 것에 대해 교육을 받아야 한다.

Commit 전 테스트는 문제없이 작업되고 테스트

된 코드만 중앙저장소에 저장할 수 있게 하는 방

법론이며, 다시 말해 Central to CD프로세스 방

법론이다.

배포 가능한 코드만 저장소에 저장하는 방식인

것이다. 그러므로 코드가 commit되기 전 반드시

모든 테스트를 통과해야 한다. 물론 다양한 방식

으로 만족할 수 있겠지만, 공통 테마는 테스트되

기 전에 코드는 중앙 저장소에 직접 접근해서는

안 되는 것이다.

하나의 방법은 중앙저장소 전에 나란히 단계저장

소(Staging Repository)를 사용하는 것이다.

개발자가 어떤 코드를 저장소에 저장하려 할 때

자동적으로 실제 저장소에 가는 것이 아니라 단

계저장소로 간다. 이 동작은 개발자에게 분명히

나타나는데 마치 실제저장소에 저장되는 것처럼

commit이 이루어진다.

CI 서버는 단계저장소에서 checkout하여 build

및 코드를 테스트하며, 모든 테스트를 통과하면

실제저장소에 이름과 로그기록을 남기며 commit

된다. 이 동작 또한 개발자에게 보여진다. 실제저

장소에 commit된 것처럼 보여진다.

코드가 모든 테스트를 통과하지 못하면 단계저

장소에 남아있게 된다. 그 문제를 수정하기 위해

필요한 액션들을 개발자에게 통보해 준다. 그리

고 실제저장소에 있는 코드는 변경되지 않는다.

이 프로세스는 테스트들은 자동화되어 있어야 하

고, 명확하게 정의되어 있어야 한다.

프로젝트가 진행됨에 따라 테스트도 변경될 수

있다. 예를 들어 베타 테스트는 출시 예정 후보

에 적용되는 엄격한 기준과 함께 기본적인 기능

에 초점을 맞출 수도 있고 유지보수 기간에는 새

로운 기능에 대한 테스팅에 초점을 맞출 수 있

기 때문이다.

CI Systems

테스트 단계에서 자동화는 CI의 핵심이다. 한번

분석이 자동화 되면, CI 시스템은 적절한 테스트

를 실행하며 그 결과를 바탕으로 적절한 행동을

취한다. 따라서 CI 시스템은 컴파일과 테스팅 프

로그램을 실행함으로써 정교한 스케줄러로 생각

될 수 있다.

CI 시스템의 간단한 핵심 요구사항은 아래와 같

은 자동화 기능이다.

▶ 코드가 commit 되었는지 검출

▶ 저장소로부터 필요한 Build와 테스트 도구가

있는 서버로checkout을 받았는지 여부

▶ 코드 build

▶ Build 후 생성된 실행 가능한 파일에 대해 모

든 테스트를 실행

▶ Build와테스트 결과를 리포트

▶ 추가적으로 가능하다면, 이전 테스트 결과를

바탕으로 또 다른 테스트를 실행

사실 이러한 자동화는 스크립트와 커맨드라인으

로 실행할 수 있는 도구들로 만족할 수 있으며 많

은 회사들이 도입을 시작했다.

하지만 스크립트를 관리하는 것은 그 자체로 일

이 되며, 개발자에게 코드 작성하는 작업에서 멀

어지게 할 수 있다.

CI 적용

많은 회사들이 업무시간이 끝나고 저장소에서

Build 및 테스트 된 코드를 checkout하며 밤에

Build한다. 이것은 CI 초기버전으로 이해하면 된

다. 이 Build결과는 다음 날 아침에 확인된다.

이 방법에는 제약이 있다.

▶ 우선 check(in과out)와 결과 확인 간 시간 차

이가 있다. 개발자는 Build가 실패된 코드를

아침에 확인할 수 있다. 다시 말해 개발자는

Build가 실패된 코드를 아침에 확인할 수 있다.

▶ 조금 더 심각한 것 일수도 있지만 Build와 테

스트는 일반적으로 잘 짜인 스크립트에 맞춰

서 실행된다.

이런 스크립트는 규칙적인 유지보수가 필요하

며 그 자체가 버그 일수도 있다.

그림 1.

66-71_Guest Article-MDS.indd 69 14. 3. 27. �� 8:12

70 Embedded World

UEST ARTICLEG

큰 조직에서 발생할 수 있는 관련 문제는 밤에

Build한 후 생성되는 결과는 일반적으로 개발자

와 팀장에게만 보여진다.

높은 단계의 관리 프로세스에서는 어떤 코드가

어떤 테스트에서 통과되고 실패했는지 알려준다.

하지만 적당한 높은 단계의 summary 정보를 얻

는 것은 어려운 일이다. 일반적으로 너무 개발자

주관적인 결과값이기 때문이다. 이런 문제에 따

라 관리자는 지난주 테스트 결과보다 오늘의 테

스트 결과가 더 좋다는 것을 알고 싶어 할 것이

다. 이러한 정보는 이전 Build 정보가 다시 쓰일

때 수집이 가능한데 오랜 기간 지속적인 결과의

저장을 의미한다.

CI 상용제품을 사용함으로써 이러한 문제를 해결

할 수 있다. 그림 2는 일반적으로 CI를 어떻게 설

정하는지 보여준다.

일반적인 시스템은 다음과 같은 흐름을 따른다.

1. 개발자는 (단계)저장소에서 코드를 checkout

한다.

2. VCS(버전 관리 시스템)은 CI 서버에 commit이

발생했는지 또는 CI 서버가 저장소에 주기적으

로 commit을 요청하는지 알려준다.

3. CI는 Build서버에서 Build프로세스를 시작한다.

4. 가장 최신으로 commit 된 코드가 build 서버의

저장소에 checkout된다.

5. 미리 정의된 테스트 명령에 대해서 코드가

Build 및 테스트 된다.

6. 그 결과가 중요한 파일들의 결과는 CI 서버

에 보고한다.

7. CI 서버는 Build 최종 결과를 선정한다. 통과 /

실패 / 불안정적. 불안정적은 기능 테스트는 통

과 했지만, 코드 커버리지는 목표에 도달하지

못하는 것을 의미할 수 있다.

8. 만약 Build가 목표에 도달했다면 단계저장소

에서 실제저장소로 check in 한다. 만약 실패

했다면 실제저장소에 check in 하지 않는다.

9. CI 서버는 Build에 관련 있는 지정된 그룹에게

알려준다. 그들은 CI 서버에 로그인하여 상태

와 추가적인 정보들을 확인할 수 있다.

분할 및 정복

코드를 테스트하기 위해 필요한 모든 행동들을

하나의 작업으로 묶어 저장소에 commit하기 위

해 작업을 실행한다. 하지만 보통 이런 작업들은

여러 개의 작은 일로 나누고 연속적으로 실행하

는 것이 최선이 방법이다. 이전의 일의 결과를 바

탕으로 다음 일을 실행할 수 있게 순서를 설정해

야 한다. 테스트 실행의 순서는 잘게 쪼갠 작업

을 몇 개씩 그룹으로 묶어 정교한 순서로 구성

되어야 한다.

테스트를 쪼개는 이유는 테스트가 실패할 때마다

시각적으로 확인하기 위해서이다. 단위 테스트가

이미 실패했는데 코드를 다운받고 코드 커버리지

테스트를 실행하는 것은 의미가 없다.

그러므로 나누고 정복하는 기법은 CI에 최적화된

테스트 기법이다. SW 현재 단계를 통과했을 때

만 다음 테스트 단계로 넘어가야 한다. 이 방식은

개발자에게 가장 빠르게 피드백을 줄 수 있으며

수정을 더 빨리 할 수 있다.

작은 일 여러 개를 관리하는 것이 큰 묶음의 한

덩어리를 다루는 것 보다 쉽다. 예를 들면 새로

운 테스트를 추가하거나 테스트 순서를 바꿀 때

이다.

그림 3은 어떻게 일의 순서가 실행되는 지 보여

준다. 만약 코드가 테스트를 통과하면 다음 단계

로 넘어가며, 만약 모든 테스트를 통과하면 배포

가능한 코드가 될 수 있다.

그림 2. 그림 3.

66-71_Guest Article-MDS.indd 70 14. 3. 27. �� 8:12

www.embeddedworld.co.kr 71

코드 품질을 높이기 위한 정적 분석과 지속적인 통합(CI)- Vol. 1

Part 2: 정적 분석과 CI

정적 분석은 실제 코드를 Build하거나 실행하지

않고 소스 코드상에서 테스트를 수행하는 넓은

범위의 분석을 포함하는 광의적 의미이다. 정적

분석은 Best Practice를 기반으로 코드의 문제를

확인시켜주며 Undefined Behavior, 잠재적 오류

와 위험뿐만 아니라 문법적 오류는 없지만 언어

를 잘못 사용하고 코드의 명확성을 떨어뜨리는

것에 대해서도 검출한다.

정적 분석은 동적 테스트에서 검출하지 못하는

것을 찾아주며 코드의 유지보수성과 효율성을 높

여주기도 한다. 자동화된 정적 분석은 코드 리뷰

(Code Review)의 필요한 부분이며 다른 어떤 것

으로도 대체할 수 없다.

한 가지 중요한 측면은 정적 분석은 코드의 첫 번

째 줄만 있어도 분석이 가능하다는 것이며, 바로

개발 시작단계에서 적용할 수 있다.

정적 분석을 사용하는 장점은 이전 PRQA 백서

에서 다룬 적이 있다. 그 중 중요한 내용은 프로

젝트 생명주기 중 코드 단계에서 Best Practice을

기반으로 이른 시점에서 수정되는 코드 내 결함

을 검출할 수 있다는 것이다.

방대한 양의 코드를 자동으로 효과적으로 코드

리뷰를 해야 한다.

현재도 개발자가 코드 리뷰를 해야 하는 것이 있

기는 하지만 오랫동안 코드 리뷰에서 자주 검출

되었던 문제들에 대해서는 자동으로 검출할 수

있다. ‘이른 시점에서 그리고 자주’ 코드 리뷰 방

식은 CI 방식과 완벽하게 일치한다. 따라서 큰 장

점은 CI 프로세스에 자동화된 정적 분석을 적용

할 때 확인할 수 있다.

코드 통합단계에서 발생하는 문제들이 코딩 규

칙 적용 때도 발생할 수 있다. 이런 문제들을 코

드가 모두 작성될 때까지 남겨두는 것 또한 문

제가 된다.

전에 적용하지 않은 코딩 규칙을 적용하면 보통

많은 위반사항이 검출된다. 검출된 위반사항을

확인하는 것은 많은 시간이 걸리는 것뿐 만 아

니라 코드를 수정함으로써 코드를 더 나쁘게 만

들 수 있거나 다른 위반사항이 검출되는 위험성

이 있다.

작성된 코드에 대해서 코딩 규칙을 적용하는 것

은 효율적이거나 안전하지 않을 수 있다. 검출된

위반사항에 대해서는 코드를 작성한 개발자가 리

뷰를 해야 한다.

비록 적용할 코딩 규칙을 늘리는 주요 장점은 코

드의 품질을 높이는 것에 있지만 다른 장점들이

있다. 많은 Metrics들은 정적 분석의 한 부분으로

그 값들이 저장될 수 있으며, Metrics값의 변경사

항을 추적하는 것은 분석한 프로젝트의 상태가

어떻게 되는 지 알려주는 척도가 된다.

만약 Metrics가 예상했단 값에서 벗어나기 시작

하면 원래 정상수치로 갈 수 있게 적당한 방법을

취하는 것이 방법이 될 것이다.

66-71_Guest Article-MDS.indd 71 14. 3. 27. �� 8:12