Jenkins 가이드

젠킨스 (Jenkins)는 지속 빌드 및 배포 공개 소프트웨어 시스템이다. 소프트웨어 프로젝트를 지속적으 로 빌드 및 테스트 하도록 해주는 자동화 도구이며, 배포에 필요한 프로세스를 통합하여 제공한다.

• 빌드 프로젝트의 구성, 관리
• 프로젝트의 구축, 테스트, 배포 및 자동화를 지원하는 다양한 플러그인과 연동 제공
• Linux , Windows OS 지원
• war 파일로 간단하게 배포 및 간편한 Web GUI 제공

Jenkins 가이드를 목차를 확인하고 관련 자료를 다운받을 수 있다.

1. 설치
2. 기본 설정
3. 플러그인 설정: gcov , cppcheck , xUnit, NSIQ , Sonarqube

자료 다운로드 >>>

SW 테스트 전략

품질은 결코 우연으로 얻어질 수 있는 결과가 아니다. 많은 노력과 공수, 지식의 축적과 스킬들의 집합체다. 높은 품질은 표준과 SW 프로세스, 철학과 의지의 결과물이기도 하다. 지속되는 개발은 소스코드 분석과 위험 기반의 테스트, 커버리지 측정에 따른 자동화 모듈, 통합테스트를 통해 얻게 된다.

애자일 등 오늘날의 SW개발은 점점 더 방법론 기반의 개발에 의존하고 있는 상황이다. 결과물은 품질보증의 새로운 도전에서 비롯된다. 고품질 제품은 역동적인 목표의 정의와 짧은 개발 사이클을 통해 만들어 지고 지속적인 테스트와 고객의 피드백을 통해 성공의 포인트를 확인할 수 있다.

애자일 방법론의 경우 테스트 가능한 SW는 단계이전에 반드시 수행도록 권고하고 있다. 이러한 지원을 통해 좀 더 낳은 통합 테스트를 프로세스 단계에 포함시킬 수 있게 되는 것이다. 납기가 충분하지 않을 경우 고객의 요구사항을 만족시키기 위해 고객과의 피드백 프로세스와 팀 능력을 통해 이를 해결하기도 한다.

< SW Quality 5seps to excellence >

자료 : Quality is never an Accident, ’13. 3

테스트 전략은 단기 및 장기 테스트 요구사항 및 비즈니스 위험을 프로파일링 하고 개발자와 리소스 등의 환경 요소와 조직적 요구를 포함하는 테스트 전략을 개발하고 다양한 관점에서 평가할 수 있도록 수립해야 한다.

< SW테스트 관점별 전략 개발 요소 >

웹기반 테스트 전략은 일반적으로 코드인스펙션, 유닛 테스트, 통합테스트, 시스템 테스트 등이 수행되며 각각의 테스트 기법들은 설계, 코딩, 품질보증, 제품의 관점에서 시행된다.

< 단계별 결함 해결 비용 >

애자일 테스트 전략의 경우 애자일 방법론과 프로젝트에서 주어진 다양한 상황에 맞추어 테스트를 추진해야 한다.

< 애자일 생명주기에서의 테스팅 전략 >

자료 : Scott W. Ambler, 2006-2009

< 애자일 결함관리 프로세스 >

자료 : Scott W. Ambler, 2006-2009

< 애자일 개발과정에서 테스트 비용과의 관계 >

자료 : Scott W. Ambler, 2006-2009

SW 품질보증

SW품질보증은 SW가 이미 정의된 요구사항과 일치하는가를 확인하는데 필요한 전반적인 계획과 체계적인 작업을 의미한다. SW품질보증 활동은 SW개발 초기에 SW의 특성과 요구사항을 파악하여 품질목표를 설정하고 개발단계에서는 정형기술 검토를 통하여 품질 목표의 충족 여부를 체크하고 테스트 과정을 거치게 된다.

대부분의 SW품질보증 활동은 테스트 계획, 절차, 범위, 방식, 방법 등에 대한 활동이 전부였다고 해도 과언이 아니다. 이러한 테스트 중심의 품질보증활동들은 SW개발 과정중 품질을 제한적으로만 확인할 수 있어 SW개발 과정 중에 품질을 추가하거나 강화하는데 여의치 않았던 것은 사실이다.

SW의 품질보증 활동은 최종결과물의 테스트나 확인을 통해서 수행되는 것이 아니라 SW개발 전단계에 적용해야 한다. 물론 SW의 결함을 제거하고 해결하는 일이 SW의 품질보증을 위해서 중요한 일이지만 이보다 중요한 것은 사전에 결함이 발생되지 않도록 예방하는 활동을 의미한다.

SW품질보증 활동은 조직의 목표와 특성이 반영되어야 한다. SW개발을 추진하는 조직은 SW를 이용하는 조직보다 설계와 테스트과정에 더 많은 공수를 투입해야 하며 SW를 활용하는 조직은 형상관리 및 코드관리, 시험기준 및 획득활동에 더 많은 노력을 해야 한다. SW품질보증의 본질은 결함을 사전에 방지, 제거를 통해 SW의 사용성과 유지보수성을 높이는데 있다.

SW품질 판단기준은 SW품질보증 프로세스와 활동에 따라 결정되며 품질목표가 없는 프로세스는 품질을 확보하기 어렵다. SW품질목표를 설정하기 위해서는 필요에 따라 리스크분석을 활용하여 리스크와 영향도의 관계에 따라 품질보증 항목을 결정하고 활동들을 정의하기도 한다. SW품질목표는 정의를 통해 측정가능하게 도출한 후 추진해야 한다. 품질의 측정은 크게 비용관점과 요구사항 적합성 관점에서 접근하게 된다.

SW비용측면의 관점은 예방비용, 평가비용, 실패비용으로 정의하여 도출하고 개발 전부터 고려하여 목표를 설정해야 한다. 예방비용의 경우 컨설팅 비용이나 계획수립비용, 방법론 도출비용, DB 계획수립, 표준과 요구사항의 정의 등을 포함하며 평가비용은 테스트 계획 수립, 테스트, 검토, 리뷰 등을 포함한다. 실패비용은 프로젝트 재작업 및 클레임, 유지보수 추가 작업 등을 포함하여 고려하여야 한다.

요구사항적합성 관점은 정의된 요구사항이 제대로 반영되었는지에 대한 부분으로 Correctness, Reliability, Efficiency, Integrity, Reusability, Usability, Maintainability, Testability, Potability, Inter-operability, Flexibility, Survivability 등 SW품질요소를 고려하여 추진하며 SW품질기준과의 조율을 통해 산출물의 품질을 확보하도록 추진하여야 한다.

< SW품질요소와 SW품질기준과의 관계 >

SW 품질비용

품질이란 경영자의 마인드 또는 잘못된 판단에 따라서도 좌우되고, 총무나 회계직원의 말 한마디에 의해서도 좌우된다. 구매되는 부품의 품질과 교육 주관부서에서의 교육계획, 그리고 설계 컨셉과 잘못된 설계서 등에서도 품질의 차이는 발생할 수 있다. 즉 품질의 70% 이상은 개발이 아닌 설계나 기타 부문에서 좌우된다는 것이다. 그렇기 때문에 전사적 활동이 되지 않는다면 품질을 확보할 수 없게 되는 것이다.

비용의 의미로 COPQ(Cost of Poor Quality)라는 단어를 제창하였던 QC 선구자 Juran 박사에 따르면 품질비용에서 실제 드러나 보이는 비용은 일부분이며 보이지 않는 부분(Hidden factor)인 숨겨진 품질비용 즉 기회손실비용을 찾아내 분석하고 줄이는 활동에 따라서 품질비용을 효과적으로 관리할 수 있다고 한다.

품질비용이라면 무조건 줄이려고만 하는 것은 위험한 생각이다. 좋은 SW를 만들려면 설계실수도 없애야 하고, 도구를 사용하고 개발자에 대한 교육비용도 투자해야만 한다. 무조건 줄이는 것이 아니라 예방비용을 적절히 투자하여 향후 발생되는 평가비용과 실패비용을 줄이고 나아가 보이지 않는 부분들도 줄여나가야 한다.

과거 전통적인 관점에서 보면‘품질을 높이려면 비용이 많이 든다’라는 개념이 있었다. 하지만 현대적인 관점에선‘품질을 높이면 비용이 줄어든다’라는 개념으로 바뀌고 있다.
“고객에 납품하는 제품에 결함이 없고, 조직 내에 특별한 품질활동이 없다면 품질비용은 사라질 것이다.”(Frank M Gryna) 바로 이 말의 의미인 것이다.

SW예산삭감은 비즈니스 분석가와 테스팅 그룹을 대상으로 하는 경우가 많다. 이러한 환경은 품질결과에 위험이 된다. SW개발 산출물이나 전사전반에 영향을 미치는 품질비용은 SW와 고객을 대상으로 한 예방비용임에도 불구하고 단순히 비용측면에서 접근하여 이를 이행하려고 한다.

SW조직이 프로젝트 품질을 높이기 위해 일정과 예산을 관리하는 것과 더불어 품질비용의 투입은 겉보기에 큰 초기투자로 판단하기 쉽다. 하지만, 적절한 기술, 비즈니스 요구사항이 만족될 수 있도록 지원하는 모든 품질관련 활동, 제어 및 측정을 안내하는 품질계획과 개발자, 효과적인 테스트 전략을 통해 품질을 강화시키고 일정과 예산을 유지할 수 있다.

< SW품질 비용 >

핀테크 보안

핀테크에서는 다양한 보안 기능을 추가하고 있지만 대부분은 새로 만드는 것이 아니라 기존의 보안 기술을 활용하는 것이 많다. 이러한 기술의 특징과 장단점을 잘 파악하여 핀테크와 무리 없이 연동되도록 해야 한다.

핀테크는 다른 서비스에 비해 정책적인 제약이 많기 때문에, 보안에 대해 기술적인 접근과 함께 비즈니스적인 접근을 병행해야 기술과 정책을 조화롭게 구성할 수 있다. 핀테크 보안 기술은 하드웨어적인 요소가 많기 때문에 이를 소프트웨어적으로 변환할 수 있는 방안도 필요하다.

핀테크에서 요구되는 세가지 보안 요소

완벽한 보안은 없다. 다만, "정보의 가치"보다 "정보를 해킹하는 비용"이 더 발생하도록 보안을 구축하는 것이 보안의 최종 목적으로 볼 수 있다.

보안의 3요소는 기밀성, 가용성, 무결성(표 1 참조)이다. 철저한 보안을 위해서는 기밀성과 무결성을 높이면 되지만, 이로 인해 가용성은 떨어지게 된다. 세가지 보안 요소에 중요도를 적절히 배분하는 것이 적정 보안을 유지하는 방법이다.

<표 1> 보안의 3요소

핀테크 보안의 3요소는 조금 다르게 정의된다. 효율성, 편의성, 안전성 등 3가지 요소로 볼 수 있다.(표 2 참조). 불과 몇 년 전만해도 금융은 우리나라만 생각하면 되었지만 금융 서비스가 온라인으로 옮겨가면서 글로벌 표준에 대한 인식이 확대 되었다.

<표 2> 핀테크 보안의 3요소

기존의 금융 서비스는 일관된 서비스만 제공하였지만 다양한 디바이스, 시스템과 연계해야 하는 핀테크는 비즈니스 흐름에 따라 소프트웨어를 구성해야 한다. 보안도 비즈니스 관점으로 접근하여 시스템의 효율성을 높일 필요가 있다.

핀테크는 이용자가 다양해지기 때문에 인증에 대한 보안이 강화되어야 한다. 하지만, 최종 사용자(End User)의 디바이스는 모바일처럼 이동성이 강할 수도 있어 편의성도 고려해야 한다. 더 보기 >>>

2016, 소프트웨어 개발 5대 핫 트렌드

2016년에도 IT 운영, 앱 개발, 데이터 관리가 지속적으로 관심 대상이 될 것으로 보인다. 특히 사물인터넷(IoT) 생태계 주도권 경쟁이 심화되고 이를 기반으로 한 디지털 트랜스포메이션 (Digital Transformation)이 가속화될 것으로 전망된다( IDC FutureScape 2016: Korea Top Predictions). 한국CA에서 바라보는 5대 이슈는 사물인터넷, 컨테이너에 의한 개발 가속, 애자일 보안, 애널리틱스 고객 경험, 블록체인이다. 

사물인터넷(IoT)의 애플리케이션 실용화: 사용자 계정처럼 기기에도 계정이 부여되어 인증과 신뢰를 갖게 하는 사물 계정(Identity of Things)이 확산될 것이다. 이를 위해 계정부여와 접근관리(IAM), 기기간 상호작용, IoT간 상호작용을 위한 소프트웨어 개발이 부상할 것이다. 

컨테이너를 통한 개발 가속화: 기업은 컨테이너와 마이크로서비스를 이용해 복잡한 아키텍처와 소프트웨어 개발을 유연하고 손쉽게 그리고 빠르게 진행할 수 있다. 이런 기술은 애플리케이션 개발·구축·업그레이드 방식을 변화시킬 것이고, 다양한 요구사항을 순발력 있게 처리할 수 있는 체계를 갖추게 될 것이다. 

애자일(Agile) 보안: 애자일 방식의 소프트웨어 개발은 증가하고 있고, 이는 시작 단계부터 보안을 고려해야 효과적인 프로젝트를 수행할 수 있음을 의미한다. 여기에는 자주 사용하는 API(Application Programming Interface)에 대한 보안이 강화되면서 신뢰 받는 고객 경험을 이끌어낼 것으로 본다. 

빅데이타와 애널리틱스를 통한 고객 경험 구현: 애널리틱스는 BI(Business Intelligence) 단계에서 최근에는 거래용 데이터와 빅데이터로 발전했다. 고객 경험을 향상 시켜주는 실시간 애널리틱스는 새로운 가치를 창출해줄 것이고 일정한 표준을 제시할 것이다. 특히, ‘1인 가구’ 증가에 따라 기업은 매우 다양한 개인별 맞춤 서비스를 제공해야 한다. 애널리틱스에 의한 의미 있는 인사이트 도출이 필요함을 의미하며 데이터 사이언스 중요성이 높아질 것이다. 

블록체인(Blockchain) 기술: P2P 네트워크을 통한 이중지불 방지에 쓰이던 기술이 바로 블록체인이다. 제3자가 거래를 보증하지 않아도 거래 당사자끼리 가치를 교환할 수 있다는 점이 핀테크와 결부되어 새로운 금융시대를 여는 화두가 되고 있다. 컴퓨터 네트워크 기반으로 하며 프라이버시가 핵심인 블록체인 기술은 고객 대응에서 매우 유연하고 민첩해서 사물인터넷과 결합되어 개인과 기업의 디지털 트랜스포메이션 실현에 매우 중요한 역할을 할 것이다. 

정적 분석과 코드 커버리지에 대한 이해

‘정적 프로그램 분석’ (Static program analysis)은 실제 실행 없이 컴퓨터 소프트웨어를 분석하는 것을 말한다. 다시 말해, 어떤 프로그램을 분석할 때 그 프로그램을 실행시키지 않고 ‘그 자체’를 분석하는 것이라고 해석할 수 있다. 프로그램에 내재한 논리적 오류는 일반적으로 프로그램을 실행하여 확인하지 않으면 찾기가 힘들지만, 정적 분석은 이러한 오류를 찾아내는 데 도움을 줄 수 있다.

대부분의 경우에 분석은 소스 코드의 버전 중 하나의 형태를 가지고 수행되며, 가끔은 최종 바이너리를 가지고 분석한다. 이에 반하여, 프로그램을 실행 하여 분석하는 것을 ‘동적 프로그램 분석’이라고 한다.  

정적 분석은 코드를 실행하지 않고도 모든 프로그램의 구성 요소를 검사하여 다양한 결함을 검출 할 수 있다는 장점이 있다. 또, 테스팅 도구들은 사용자의 적절한 가이드로 중요한 프로그램 구성 요소들을 실행해가면서 그 결과가 예상된 것 인지를 확인할 수 있는 메커니즘을 제공함으로써, 결함들을 검출 할 수 있도록 해준다. 이러한 정적분석이 ‘테스팅을 완전히 대신할 수 있는가’에 대한 의견이 분분한 가운데, 슈어소프트테크의 권민혁파트장을 만나  이에 대한 의견을 들어보았다. 

권민혁 파트장 (슈어소프트테크 시험자동화 연구소)

Q: 요즘 정적 분석기법이 적용된 도구들에 대한 관심이 높아지고 있는데, 이유가 뭘까요?

최근의 소프트웨어 개발 방법론의 흐름을 보면 과거 보다 소프트웨어 정적 분석 기술과 소프트웨어를 동적으로 테스트하는 테스트 자동화 도구에 대한 관심이 높습니다. 현대의 소프트웨어 는 너무나 크고 복잡해서 사람이 직접 프로그램의 모든 동작을 꼼꼼히 확인하기란 매우 어려운 일이기 때문일 텐데요. 소프트웨어의 품질이 중요시되는 경우, 개발자와 품질 관리자는 전문적인 도구들을 필요로 하게 됩니다. 정적 분석 기법이 적용된 도구와 자동화된 테스트 도구들은 이런 요구에 부합하는 도구들이라고 볼 수 있죠.하지만 산업계의 품질과 관련된 다양한 요구만큼, 도구를 도입하거나 사용할 때 발생할 수 있는 오해도 많이 있습니다. 더 읽기