박종훈 기술블로그

안전하고 아름다운 소프트웨어 만들기 (이상호 교수님)

10월 10일 스타트업 리딩클래스 라는 프로그램을 통해 충남대학교의 이성호 교수님께서 우리 회사(lucentblock)에 방문해주셔서 강연을 해주셨다. 우리 회사 사람들 외에도 다양한 분들이 오셔서 강연을 들으러 오셨었다.

그동안 계속 정리해야겠다 마음은 먹었는데, 시간이 나지 않아서 정리하지 못하고 있다가 이제서야 정리를 할 수 있게 되었다.

사실 솔직히 이야기 해서 처음에는 강연자에 대한 정보도 없이 제목만 전달 받았을 때는 크게 기대하고 있지 않았다. “안전하고 아름다운 소프트웨어 만들기” 라는 제목만 들었을 때는 ‘도대체 안전하고 아름다운 소프트웨어 라는게 무엇을 의미하는가?’ 라는 생각이 들었었다. (참여의 강제성이 있었기 때문에 그 부분에서 조금 더 부정적인 인상이 있었던것 같다.)

근데 막상 들으니 그런 부정적인 인상이 싹 사라질 정도로 정말 유익했던 이야기를 많이 해주셨다. 구글에서 겪은 이야기들도 해주셔서 재미있었다.

그 중 정리한 내용들을 간단하게 기록을 위해 남긴다.


소프트웨어 결함과 비용

소프트웨어 결함은 늦게 발견될수록 더 많은 비용을 초래한다.

graph of 'cost to repair'

Applied Software Measurement: global analysis of productivity and quality

고객에게는 실망을, 조직원에게는 어려움을 유발하여 충성도가 하락되게 한다. 특히, 배포 후에는 결함으로 인한 생명, 재산 피해가 발생하여 브랜드 이미지에 타격이 생긴다.

소프트웨어 오류를 방지하는 두 가지 방법

소프트웨어 품질 보장을 위한 방법들

방법AssuranceCost
formal verification높음높음
static & dynamic analysis중간중간
testing and code review낮음낮음

소프트웨어 검사 기법 (수동 vs 자동)

수동 분석

정형 검증 (formal verification)

코드 리뷰

자동 분석

동적 분석

정적 분석

소프트웨어 분석 기법의 특성

soundness vs completeness

출처 : https://courses.cs.washington.edu/courses/cse403/16au/lectures/L15.pdf

프로그램 테스팅

좋은 테스트 작성하기

테스트 품질 평가하기

휴리스틱
불충분한 시간이나 정보로 인하여 합리적인 판단을 할 수 없거나, 체계적이면서 합리적인 판단이 굳이 필요하지 않은 상황에서 사람들이 빠르게 사용할 수 있게 보다 용이하게 구성된 간편추론의 방법 - 위키 -

퍼즈 테스트 (fuzzing)

프로그램 정적 분석

Google 소프트웨어 개발 적용 사례

마무리