마켓 클 레이스 가이드라인 
 언리얼 엔진 기반 개발 프로세스 에 정적 분석 활용 하 기 
 By Andrey Karpov , PVS - Studio 소속 
 이 글 에 사용 된 코드 조각 은 PVS - Studio 팀 의 일리야 이바노프 ( Ilya Ivanov ) 와 세르게이 바실리예프 ( Sergei Vasilyev ) 가 제공 해 주 셨 습니다 . 
 언리얼 엔진 은 새로운 코드 가 추가 되 고 기존 에 작성 된 코드 가 수정 되 는 식 으로 계속 해서 발전 하 고 있 습니다 . 엔진 이 이런 방식 으로 계속 발전 한다면 현재 이 엔진 을 기반 으로 진행 중 인 프로젝트 에서 는 버그 가 필연 적 으로 발생 하 게 됩니다 . 따라서 프로그래머 들 은 이 처럼 새로 생긴 버그 들 을 가급적 빨리 찾아내 고 싶 을 것 입니다 . 이런 오류 를 줄이 는 방법 중 하나 는 바로 PVS - Studio 와 같 은 정적 분석 툴 을 사용 하 는 것 입니다 . 또한 PVS - Studio 는 단순히 발전 하 는 것 이 아니 라 스스로 끊임없이 새로운 오류 패턴 을 찾 아 학습 합니다 . 이번 포스팅 에서 는 이런 새로운 오류 패턴 들 중 일부 역시 다루 어 볼 예정 입니다 . 코드 의 퀄리티 에 신경 쓰 는 개발자 라면 이 포스팅 을 반드시 읽 어 보 셔야 할 것 입니다 . 
 정적 코드 분석 , 이론 적 설명 
 정적 코드 분석 은 프로그램 소스 코드 내 에서 결함 과 오류 를 찾아내 는 프로세스 를 뜻 합니다 . 자동 화 된 코드 리뷰 프로세스 라 볼 수 있 습니다 . 
 코드 리뷰 는 결함 을 찾아내 는 가장 오래 되 고 유용 한 방법 중 하나 입니다 . 이 프로세스 에 는 소스 코드 의 합동 분석 과 이 에 따른 개선 방법 제안 까지 포함 됩니다 . 이 프로세스 는 나중 에 문제 가 될 수 있 는 오류 나 코드 조각 을 찾아내 는 작업 도 도와 줍니다 . 또한 코드 작성자 는 프로그램 의 특정 부분 이 어떻 게 작동 하 는지 아무런 설명 도 하 면 안 된다는 불문 율 이 존재 합니다 . 알고리즘 은 프로그램 의 텍스트 와 코드 의 코멘트 만 보 고 바로 파악 할 수 있 을 정도 로 깔끔 해야 합니다 . 그렇 지 않 다면 해당 코드 는 수정 되 어야 합니다 . 
 일반 적 으로 코드 리뷰 는 좋 은 효과 를 발휘 하 는데 , 프로그래머 는 자신 이 직접 작성 한 코드 보다 타인 이 작성 한 코드 에서 오류 를 더 쉽 게 찾아내 기 때문 입니다 . 관련 자세 한 정보 는 Steve McConnell 의 뛰어난 저서 , " Code Complete " 을 참고 하 시 기 바랍니다 . 
 하지만 코드 방법론 은 두 가지 단점 을 안 고 있 습니다 : 
 비용 이 극히 높 습니다 . 몇몇 프로그래머 들 이 잠시 자신 의 주요 업무 를 젖혀둔 채 , 변경 사항 제안 을 적용 하 여 다시 작성 했 거나 새로 작성 한 코드 를 리뷰 해야 합니다 . 동시 에 이 프로그래머 들 은 이런 작업 을 하 는 와중 에 도 주기 적 으로 휴식 을 취해야 합니다 . 한 사람 이 큰 규모 의 코드 조각 을 분석 하 려고 한다면 , 집중력 이 급격히 떨어져 리뷰 목적 이 무 의미 해질 위험 이 있 습니다 . 
 새 / 변경 코드 와 직접 적 으로 연관 되 지 않 은 오류 를 찾아내 기 가 힘듭니다 . 새 코드 조각 을 보 면 , 헤더 파일 stdlib . h 가 포함 되 지 않 았 기 때문 에 malloc 함수 가 오작동 하 고 있 다는 사실 을 파악 하 기 가 힘듭니다 . 이런 상황 에 대한 더 자세 한 정보 는 A nice 64 - bit error in C 링크 에서 알아보 실 수 있 습니다 . 또 하나 의 예 를 들 어 보 자면 헤더 파일 의 변수 또는 함수 유형 을 변경 하 는 경우 입니다 . 이상 적 으로 보 자면 프로그래머 는 변경 이 가해진 후 이 함수 나 변수 가 존재 하 는 모든 코드 를 리뷰 해야 하 지만 , 실질 적 으로 따지 면 이 는 시간 을 너무 많이 낭비 하 는 작업 이 기 때문 에 리뷰 작업 은 오직 프로그래머 가 변경 을 가한 지점 의 조각 에 만 한정 되 어 이루어지 게 됩니다 . 
 일각 에서 는 정기 적 으로 코드 리뷰 를 시행 했 으면 좋 겠 다는 의견 도 있 지만 , 이 는 비용 이 지나치 게 비쌉니다 . 여기 서 타협점 으로 등장 한 것 이 정적 분석 입니다 . 정적 분석 툴 은 프로그램 의 소스 텍스트 를 분석 하 고 , 특정 코드 조각 리뷰 와 관련 된 제안 을 프로그래머 에게 제시 합니다 . 이 분석 툴 은 휴식 이 필요 하 지 도 않 고 헤더 파일 내 에서 변경 이 가해진 모든 코드 들 을 분석 합니다 . 물론 정적 분석 이 라고 해서 개발자 들 이 꼼꼼 하 게 시행 하 는 전수 조사 를 완전히 대체 할 수 있 는 것 은 아닙니다 . 하지만 정적 분석 의 가성 비 를 보 면 꽤 나 유용 한 방법 이 라는 것 은 분명 하 기 때문 에 , 지금 도 많 은 기업 들 이 이 방법 을 사용 하 고 있 습니다 . 
 정적 분석 도 다른 오류 분석 방법 들 과 비교 해 보 면 장단점 을 가지 고 있 습니다 . 프로그램 테스트 에 있 어서 이상 적 인 방법 이 란 존재 하 기 않 기 때문 에 , 현재 는 여러 가지 접근 법 들 을 조합 하 여 최고 의 결과 를 얻 어 내 고 있 습니다 . 예컨대 바람직 한 코딩 스타일 , 정적 코드 분석 , 동적 코드 분석 , 유닛 테스트 , 회귀 테스트 등 의 방법 들 을 동시 에 사용 하 는 것 이 죠 . 
 정적 분석 의 중요 한 이점 은 코드 상 에서 발생 하 는 수많 은 오류 들 을 즉시 찾아낼 수 있 기 때문 에 , 수정 하 는 데 큰 비용 이 들어가 지 않 는다는 점 입니다 . 오류 는 빨리 발견 할수록 수정 비용 이 적 게 들어가 니까요 . McConnel 의 저서 " Code Complete " 에 따르 면 테스트 단계 에서 오류 를 수정 하 는 비용 은 코드 작성 단계 에서 오류 를 수정 하 는 비용 보다 10 배 는 더 많이 든다고 합니다 : 
 평균 오류 수정 비용 은 해당 오류 를 언제 발견 했 느냐 에 달려 있 습니다 ( 위 표 의 데이터 는 ' Code Complete ' - S . McConnell 에서 발췌 ) 
 정적 분석 툴 은 수많 은 양 의 오류 들 을 초기 코드 작성 단계 에서 찾아낼 수 있 기 때문 에 , 전체 프로젝트 개발 에 들어가 는 비용 을 획기적으로 감소 시켜 줍니다 . 
 최신 어플리케이션 의 코드 베이스 가 끊임없이 성장 하 고 있 기 때문 에 정적 분석 툴 의 보급 역시 점점 성장 할 것 입니다 . 프로그램 들 은 규모 와 복잡도 가 심화 되 고 있 습니다 . 그 와 동시 에 , 코드 규모 에 따른 오류 밀도 는 단순 정비례 관계 에 있 지 않 습니다 . 
 프로젝트 의 규모 가 커질수록 코드 1000 줄 당 발생 하 는 오류 횟수 역시 증가 합니다 . 다음 표 를 참고 하 시 기 바랍니다 : 
 프로젝트 의 규모 와 전형 적 인 오류 밀도 의 관계 입니다 . 출처 : " Program Quality and Programmer Productivity " ( Jones , 1977 ) , " Estimating Software Costs " ( Jones , 1998 ) . 
 이 데이터 는 아래 그래프 를 통해 보다 확실 하 게 알아볼 수 있 습니다 . 
 프로젝트 의 전형 적 인 오류 밀도 입니다 . 청색 선 은 최대치 , 적색 선 은 평균치 , 녹색 선 은 오류 의 최소치 입니다 . 
 위 그래프 는 프로젝트 의 규모 가 커질수록 프로그래머 들 이 코드 의 퀄리티 를 원하 는 수준 으로 유지 하 기 위해 더 많 은 툴 을 사용 해야 한다는 사실 을 보여 줍니다 . 예전 과 같 은 방법 , 예컨대 대략 8 년 전 에 사용 하 던 방법 으로 는 높 은 퀄리티 의 코드 를 작성 할 수 없 습니다 . 이 는 개발자 들 에게 굉장히 불편 한 진실 이 될 수 도 있 습니다 . 예전 과 같 은 방법 으로 계속 코드 를 작성 하 고 있 는데 , 코드 의 상태 는 갈수록 악화 되 니까요 . 
 기술 의 발전 과 변화 로 인해 예전 의 방법 은 더 이상 유지 하 기 가 힘들 어 진 만큼 , 새로운 방법론 을 찾 아야 할 때 가 왔 습니다 . 여기 서 가장 쓸 만 한 방법 중 하나 는 바로 정적 분석 입니다 . 
 만약 정적 분석 방법 론 에 익숙 하 지 않 은 분 들 은 이번 기회 에 관심 을 높여 보 시 길 바랍니다 . 아래 링크 를 읽 어 보 시 면 관련 정보 를 얻 기 좋 을 것 입니다 : 
 Static Code Analysis - John Carmack 저 . 
 Static Code Analysis - Wikipedia . 
 List of tools for static code analysis - Wikipedia . 
 A Few Billion Lines of Code Later : Using Static Analysis to Find Bugs in the Real World - Al Bessey , Ken Block , Ben Chelf , Andy Chou , Bryan Fulton , Seth Hallem , Charles Henri - Gros , Asya Kamsky , Scott McPeak , Dawson Engler 공저 . 
 Videos about static code analysis - Ekaterina Milovidova 저 . 
 The PVS - Studio 블로그 . 
 이제 언리얼 엔진 4 기반 프로젝트 등 에서 정적 분석 을 활용 하 는 방법 에 대해 이론 부터 실무 까지 알아보 도록 하 겠 습니다 . 
 영광 스럽 게 도 저희 팀 은 언리얼 엔진 코드 작업 을 다시 하 게 되 었 습니다 ! 2 년 전 에 도 같 은 작업 을 했 지만 , 그 당시 에 는 코드 편집 및 개선 과 관련 된 작업 에 주력 했었 습니다 . 2 년 의 공백 후 프로젝트 코드 베이스 를 다시 살펴보 는 것 은 언제나 유용 하 고 흥미 로운 일 입니다 . 그 이유 는 다음 과 같 습니다 . 
 첫 번 째 로 , 분석 툴 에서 거짓 양성 으로 판정 된 것 을 리뷰 하 는 것 에 흥미 가 있 었 습니다 . 이 작업 은 툴 에서 필요 없 는 메시지 수 를 줄여 개선 시키 는 데 도움 이 되 었 습니다 . 거짓 양성 을 걸러 내 는 것 은 모든 코드 분석 툴 개발자 들 이 끊임없이 해결 해 나가 야 할 과제 입니다 . 이 와 관련 된 정보 를 더 얻 고 싶 으시 다면 , " The way static analyzers fight against false positives , and why they do it " 글 을 읽 어 보 시 는 것 을 추천 합니다 . 
 언리얼 엔진 4 의 코드 베이스 에 는 지난 2 년 간 정말 획기 적 인 변화 가 있 었 습니다 . 추가 된 조각 도 있 었 고 , 제거 된 조각 도 있 었 으며 , 이따금 전체 폴더 가 사라져 버린 경우 도 있 었 습니다 . 코드 전체 가 충분 한 리뷰 를 거치 지 못한 이유 는 바로 이것 때문 이 며 , 이 는 곧 PVS - Studio 에게 상당 량 의 작업 이 주어졌 다는 말 이 기 도 합니다 . 
 에픽 게임즈 를 칭찬 합니다 . 코드 관리 를 중요 하 게 여기 고 PVS - Studio 같 은 툴 을 사용 하 니까요 . " 당연히 에픽 게임즈 는 귀사 의 고객 이 니 칭찬 하 고 싶 겠 죠 . " 라고 웃 으실 분 들 도 계실 텐데 , 솔직히 저희 도 에픽 게임즈 의 개발 자 분 들 께 긍정 적 인 피드백 을 남기 고 싶 은 동기 가 충분 하 기 는 합니다 . 하지만 위 칭찬 은 정말로 진심 에서 우러나온 것 입니다 . 에픽 게임즈 가 정적 분석 툴 을 사용 한다는 사실 은 곧 프로젝트 개발 사이클 의 성숙도 뿐 만 아니 라 , 코드 의 안정 성 과 신뢰 성 을 보장 하 고자 하 는 노력 도 보여 주 는 것 입니다 . 
 제 가 이 처럼 PVS - Studio 를 사용 한다면 코드 퀄리티 를 월등 하 게 개선 할 수 있 다고 자신 하 는 이유 는 무엇 일까요 ? 그것 은 바로 PVS - Studio 가 매우 강력 한 정적 분석 툴 이 고 오류 를 잘 찾아내 기 때문 입니다 . 심지어 다음 과 같 은 프로젝트 에서 도 마찬가지 입니다 : 
 GCC ( 버그 ) 
 Clang ( 버그 1 , 버그 2 , 버그 3 ) 
 Valgrind ( 버그 ) 
 GDB ( 버그 ) 
 FreeBSD ( 버그 1 , 버그 2 ) 
 그 외 기타 버그 . 
 PVS - Studio 를 사용 하 면 코드 의 퀄리티 를 한 차원 끌어올릴 수 있 습니다 . 따라서 에픽 게임즈 가 PVS - Studio 를 사용 한다는 사실 은 , 곧 언리얼 엔진 4 로 프로젝트 를 제작 하 는 모든 이 에게 도 신경 을 쓴다는 사실 을 보여 주 는 것 입니다 . 버그 를 하나 찾 을 때 마다 누군가 의 골치 거리 가 줄어드 는 셈 이 니까요 . 
 흥미 로운 오류 
 저희 가 찾아내 어 수정 한 오류 를 전부 다루 어 보 지 는 않 을 것 입니다 . 제 생각 에 좀 더 주의 를 기울일 만 한 오류 들 만 골라 내 어 부각 시켜 보 도록 하 겠 습니다 . 다른 오류 에 도 관심 이 있 으신 분 들 은 깃 허브 ( Github ) 에서 pull 요청 하 여 보 실 수 있 습니다 . 소스 코드 와 특정 pull 요청 에 접근 하 기 위해서 는 , 깃 허브 의 언리얼 엔진 저 장소 접근 권한 이 있 어야 합니다 . 접근 권한 이 없 는 경우 획득 방법 은 이 블로그 를 참고 하 시 기 바랍니다 . 
 PVS - Studio 의 분석 툴 개발 은 새로운 진단 법 을 만드 는 것 뿐 만 아니 라 기존 진단 법 을 개선 시키 는 것 이 기 도 합니다 . 예컨대 변수 가 취할 수 있 는 값 을 평가 하 는 알고리즘 은 언제나 개선 중 인 부분 입니다 . 이 덕분 에 분석 툴 은 1 년 여 전 부터 다음 과 같 은 오류 들 도 찾아내 기 시작 했 습니다 : 
 이 코드 는 다음 과 같이 고칠 수 있 었 습니다 : 
 진단 V 547 은 2010 년 에 작성 되 었 습니다 . 하지만 변수 의 값 을 평가 하 는 메커니즘 이 완벽 하 지 않 았 으며 , 위 오류 를 찾아낼 수 도 없 었 습니다 . 분석 툴 은 DataLen 의 변수 값 을 확인 하 는 데 에 도 혼란 을 겪 어 , 다양 한 조건 하 에서 해당 변수 값 들 이 어떻게 될지 알아낼 수 가 없 었 습니다 . 개발자 가 직접 나섰 다면 이런 코드 는 어렵 지 않 게 분석 해 냈 겠 지만 , 이런 오류 를 찾아내 라는 알고리즘 을 작성 하 는 것 은 간단 한 일 이 아닙니다 . 
 그래서 , 이것 이 PVS - Studio 내부 메커니즘 개선 을 통해 새로운 오류 를 찾아낼 수 있 게 되 었 다는 점 을 보여 주 는 한 예 입니다 . 이런 내부 적 인 개선 을 통해 분석 툴 은 더 정확 하 게 작동 할 수 있 게 되 었 습니다 . 
 또한 C ++ 언어 새 버전 에 출현 한 새로운 구조 를 지원 하 는 외 적 인 개선 역시 일구 어 냈 습니다 . 그렇지만 아직 C ++ 11 이나 C ++ 14 등 의 파싱 방법 을 학습 하 기 에 는 부족 합니다 . 새로운 언어 구조 에서 버그 들 을 찾아내 는 새로운 진단 법 을 구현 하 는 것 못지 않 게 예전 진단 법 을 개선 하 는 것 역시 똑같이 중요 합니다 . 예 를 들 면 진단 V 714 가 잘못 된 범위 기반 루프 를 찾아내 는 프로세스 를 한번 살펴보 겠 습니다 . 언리얼 엔진 에서 V 714 진단 이 가리킨 루프 는 다음 과 같 습니다 : 
 for ( TSharedPtr < SWidget > SlateWidget : SlateWidgets ) 
 PVS - Studio warning : V 714 Variable is not passed into for - each loop by a reference , but its value is changed inside of the loop . vreditorradialfloatingui . cpp 170 
 프로그래머 는 SlateWidgets 컨테이너 에 있 는 모든 엘리먼트 에 nullptr 값 을 할당 하 고 싶 었 습니다 . 그런데 SlateWidget 은 루프 이터레이션 을 매번 새로 시작 하 는 와중 에 생성 되 는 일반 로컬 변수 라는 오류 입니다 . 이 변수 에 값 을 할당 한다고 해서 컨테이너 내 엘리먼트 에 변화 가 생기 지 는 않 습니다 . 따라서 레퍼런스 를 사용 해 코드 가 제대로 작동 하 도록 해야 했 습니다 : 
 for ( TSharedPtr < SWidget > & SlateWidget : SlateWidgets ) 
 물론 저희 는 언어 에 상관 없이 작동 하 는 분석 방법 들 도 추가 했 습니다 . 예 를 들 면 진단 V 767 은 2015 년 당시 저희 가 언리얼 엔진 4 와 관련 된 이 기사 를 작성 할 때 까지 만 하 더라도 존재 하 지 도 않 았 습니다 . 이 분석 방법 은 2016 년 8 월 8 일 에 완성 된 PVS - Studio 6 . 07 에서 나 등장 합니다 . 이 분석 방법 덕분 에 다음 과 같 은 오류 를 찾아낼 수 있 었 습니다 : 
 if ( EdObj ) 
 PVS - Studio warning : V 767 Suspicious access to element of ' SelectedObjects ' array by a constant index inside a loop . skeletonnotifydetails . cpp 38 
 이 루프 는 UEditorSkeletonNotifyObj 유형 을 가진 엘리먼트 검색 을 포함 해야 만 합니다 . 하지만 오타 때문 에 엘리먼트 선택 프로세스 에서 알파벳 i 대신 숫자 0 이 작성 되 고 말 았 습니다 . 
 올바른 코드 는 다음 과 같 습니다 : 
 또 PVS - Studio 6 . 07 에서 새로 추가 된 V 763 분석 방식 도 한 번 살펴보 겠 습니다 . 이 버그 는 꽤 나 재미있 지만 , 꽤 긴 분량 의 RunTest 함수 를 인용 해야 했 습니다 : 
 bool F C r e a t e B P T e m p l ateProjectAutomationTests : : RunTest ( 
 const FString & Parameters ) 
 G ameProjectAutomationUtils : : CreateProjectSet ( Templates , 
 EHardwareClass : : Desktop , 
 EGraphicsPreset : : Maximum , 
 EContentSourceCategory : : BlueprintFeature , 
 OutMatchedProjectsDesk , 
 EHardwareClass : : Mobile , 
 OutMatchedProjectsMob , 
 다음 부분 이 가장 중요 합니다 : 
 프로그래머 는 CreateProjectSet 함수 첫 번 째 호출 도움 을 받 아 OutMatchedProjectsDesk 와 OutCreatedProjectsDesk 변수 들 을 초기 화 하 려 했 습니다 . 
 그리고 CreateProjectSet 함수 의 두 번 째 호출 을 사용 해 OutMatchedProjectsMob 와 OutCreatedProjectsMob 변수 들 을 초기 화 하 려는 시도 가 있 습니다 . 
 그런 다음 이 변수 값 이 조건 에 맞 는지 확인 하 는 검사 가 있 습니다 : 
 이미 리뷰 된 함수 본문 에서 오류 를 찾 지 마세요 . 거기 에 없 습니다 . 이 코드 를 꺼낸 것 은 CreateProjectSet 함수 가 마지막 실제 인수 둘 로 전달 된 값 을 두 변수 속 에 써 넣 을 것 으로 기대 한다는 것 을 보여 드리 기 위한 것 입니다 . 
 이 오류 는 CreateProjectSet 함수 에 숨 어 있 었 습니다 : 
 static void CreateProjectSet ( .... int 32 OutCreatedProjects , 
 int 32 OutMatchedProjects ) 
 여기 서 PVS - Studio 는 두 가지 의 경고 를 출력 합니다 : 
 V 763 Parameter ' OutCreatedProjects ' is always rewritten in function body before being used . g ameprojectautomationtests . cpp 88 
 V 763 Parameter ' OutMatchedProjects ' is always rewritten in function body before being used . g ameprojectautomationtests . cpp 89 
 분석 툴 은 절대 적 으로 옳 습니다 . OutCreatedProjects 와 OutMatchedProjects 인수 값 이 어디 쓰이 지 도 않 았 는데 바로 0 으로 덮 어 쓰이 고 있 다는 경고 입니다 . 
 이 오류 는 간단 합니다 . 프로그래머 가 파라미터 를 참조 전달 하 는 것 을 깜빡 한 것 입니다 . 제대로 고친 코드 는 다음 과 같 습니다 : 
 static void CreateProjectSet ( .... int 32 & OutCreatedProjects , int 32 & OutMatchedProjects ) 
 지금 까지 는 조금 이 라도 주의 를 기울여야 찾아낼 수 있 는 오류 들 을 사례 로 들 어 보 았 습니다 . 하지만 이외 에 도 훨씬 간단 하 고 지극히 평범 한 오류 들 도 있 습니다 . 예 를 들 면 break 문 이 없 다거나 : 
 case EWidgetBlendMode : : Opaque : 
 case EWidgetBlendMode : : Masked : 
 혹은 다수 의 변수 들 이 같 은지 알아보 는 잘못 된 비교 입니다 : 
 checkf ( GPixelFormats [ PixelFormat ] . BlockSizeX 
 자신 이 C ++ 에 익숙 하 지 않 아 위 비교 가 틀렸 다는 이유 를 알 지 못하 겠 다면 , V 709 의 설명 을 참고 하 는 것 을 추천 합니다 . 
 위 오류 들 은 PVS - Studio 가 찾아낸 오류 중 가장 잦 은 것 들 을 보여 드린 것 입니다 . 하지만 이렇게 간단 한 오류 를 어째서 찾아내 지 못한 것 일까요 ? 이 포스팅 이 대상 으로 삼 는 독자 들 에게 보여 드리 기 에 는 너무 원시 적 인 오류 일 정도 인데 말 입니다 . 하지만 실제 어플리케이션 코드 에서 는 이런 오류 들 을 찾아내 기 가 정말 어려운 일 입니다 . 심지어 코드 리뷰 도중 다음 코드 블록 을 보 고 아무 오류 도 발견 하 지 못할 수 있 습니다 . 
 이런 코드 는 너무나 간단 해서 프로그래머 는 아예 제대로 읽 어 볼 생각 도 하 지 않 은 채 , 분명 맞 았 을 것 이 라 치 고 그냥 넘어가 버릴 수 도 있 습니다 . 
 그러면 다음 질문 을 던져 보 겠 습니다 . 과연 우리 가 오류 의 숫자 를 줄일 수 나 있 는 것 일까요 ? 
 이 포스트 에서 다루 었 던 오류 들 은 PVS - Studio 을 사용 해 찾아낸 것 이 며 , 당연 한 말 이 지만 저 는 이 분석 툴 을 사용 할 것 을 추천 합니다 . 예 , 저 는 이 PVS - Studio 정적 분석 툴 을 개발 프로세스 에 도입 하 는 것 을 정말 강력 하 게 추천 합니다 . 코드 를 작성 한 직후 부터 수많 은 버그 를 찾아낼 수 있 는 방법 을 굳이 거부 할 필요 는 없 으니까요 . 하지만 저 는 코드 퀄리티 의 향상 을 논하 는 글 들 에서 잘 다루 지 않 지만 , 그럼에도 아주 중요 한 부분 을 짚 고 넘어가 고 싶 습니다 . 
 개발 팀 의 프로그래머 들 이 자신 들 도 실수 를 ( 심지어 아주 하찮 은 실수 까지 도 ) 저지를 수 있 다는 사실 을 인정 하 기 전 까지 는 , 프로젝트 에 높 은 퀄리티 를 기대 하 는 것 은 불 가능 합니다 . 위 문장 은 아주 당연 하 게 들릴 수 있 지만 , 동시 에 아주 중요 한 문장 이 기 도 합니다 . 프로그래머 가 위 문장 을 제 3 자 가 아니 라 자신 에게 대입 할 수 없 다면 , 그 어떤 툴 이나 방법론 도 효용 을 발휘 할 수 가 없 습니다 . 바꿔 말 한다면 , 프로그래머 들 은 종종 지나친 자부심 으로 인해 퀄리티 있 는 코드 를 작성 하 는 데 필요 한 추가 적 인 툴 이나 방법 을 받아들이 지 않 는 경향 이 있 다는 것 입니다 . 
 모든 프로그래머 들 은 모든 프로그램 에서 오류 가 발생 한다는 사실 을 알 고 있 습니다 . 하지만 이 오류 를 방지 하 기 위한 규칙 , 준수 사항 , 그리고 툴 등 은 자신 과 상관 없 는 것 이 라고 생각 합니다 . 왜냐하면 스스로 가 굉장히 유능 한 개발자 이 기 때문 에 버그 한 마리 없 는 코드 를 작성 한다고 자신 하 기 때문 입니다 . 이것 은 단순 한 과대 평가 의 문제 가 아닙니다 . " The Problem With ' Above Average Programmers '" 에 는 이런 보편 적 오만 함 에 대한 좋 은 설명 이 나와 있 습니다 . 여기 서 한 부분 을 발췌 한다면 : 
 " 자신 의 프로그래밍 기술 이 얼마나 유능 하 다고 평가 하 시 겠 습니까 ? ( 평균 이하 , 평균 , 평균 이상 ) " 
 라는 심리학 적 조사 가 수많 은 집단 에서 진행 되 었 으며 , 대략 90 % 의 프로그래머 들 은 자신 이 " 평균 이상 " 은 되 는 프로그래머 라고 답변 했 습니다 . 이 는 현실 적 으로 불 가능 한 수치 입니다 . 애초 에 집단 내 에서 평균 이상 은 50 % 밖 에 되 지 않 으며 , 나머지 50 % 는 평균 이하일 수 밖 에 없 습니다 . 이런 현상 은 기만 적 우월감 으로 잘 알려져 있 고 수많 은 집단 에서 관찰 되 지만 , 독자 여러분 역시 이 현상 에 대해 들 어 보 지 못했 다면 내심 자신 이 " 평균 이상 " 은 될 것 이 라고 답변 했 을 것 입니다 . 
 이것 이야말로 프로그래머 들 로 하여금 새로운 기술 과 방법론 을 배우 지 못하 도록 가로막 는 장애물 입니다 . 제 가 여기 서 추천 하 고자 하 는 점 은 자신 이 팀 이나 개인 들 과 의 협동 을 대하 는 태도 를 다시 한 번 고려 해 보 라는 것 입니다 . " 나 / 우리 는 정말 완벽 한 코드 를 작성 한다 " 는 태도 는 정말 건설 적 이 지 못한 태도 입니다 . 사람 들 이 실수 를 저지르 는 것 은 당연 합니다 . 이 는 프로그래머 들 에게 도 적용 됩니다 . 진심 으로 이렇게 생각 할 수 만 있 다면 그 즉시 높 은 퀄리티 의 소프트웨어 를 제작 할 수 있 는 가능 성 으로 의 커다란 한 걸음 을 뗀 것 입니다 . 프로젝트 매니저 분 들 은 이 기사 도 한 번 읽 어 보 시 는 것 을 추천 드립니다 . 
 또 다른 유형 의 오류 를 추론 해 내 는 것 에 대해서 도 주의 를 드리 고 싶 습니다 . 정적 , 동적 분석 툴 의 주 기능 은 그저 간단 한 버그 와 오타 만 을 찾아내 는 것 입니다 . 아직 완전 한 인공지능 이 출현 하 지 않 은 한 , 고차원 적 인 논리 오류 같 은 것 을 찾아내 지 는 않 습니다 . 하지만 간단 한 오류 하나 가 큰 오류 를 일으킬 수 도 있 으며 , 이 를 고치 는 데 에 는 정말 많 은 시간 과 비용 , 그리고 노력 이 들어갑니다 . " If the coding bug is banal , it doesn ' t mean it ' s not crucial " 기사 도 한 번 읽 어 보 시 는 것 을 추천 드립니다 . 
 그리고 한 가지 를 덧붙이 자면 , 만병통치약 같 은 것 은 없 으니 찾 지 도 않 는 것 이 좋 습니다 . 대신 다음 과 같 은 요소 들 을 조합 하 는 것 이 더 좋 습니다 : 
 우리 개발 팀 수준 은 평균 이상 은 된다는 오만 을 버립니다 . 
 코딩 표준 을 정해서 팀 내 개발자 들 모두 가 공유 합니다 . 
 코드 리뷰 를 시행 합니다 ( 최소한 중요 한 조각 에 대한 리뷰 및 비 숙련 코더 가 작성 한 코드 는 반드시 리뷰 해야 합니다 ) . 
 정적 코드 분석 을 시행 합니다 . 
 동적 코드 분석 을 시행 합니다 . 
 회귀 테스트 와 스모크 테스트 를 시행 합니다 . 
 유닛 테스트 와 TDD 를 시행 합니다 . 
 그 외 기타 방법 들 을 시행 합니다 . 
 위 에서 제시 한 방법 을 한 번 에 전부 사용 하 기 시작 해 보 시 라는 것 이 아닙니다 . 프로젝트 에 따라 더욱 유용 한 접근 법 이 있 고 , 그렇 지 않 은 것 도 있 습니다 . 요점 은 단 한 가지 의 리뷰 방법 에 모든 희망 을 거 는 것 이 아니 라 , 다양 한 방법 들 을 조합 하 는 합리 적 인 방식 을 활용 하 라는 것 입니다 . 그래야 지만 코드 의 퀄리티 와 신뢰 성 을 높일 수 있 을 것 입니다 . 
 언리얼 엔진 4 개발자 들 은 코드 퀄리티 에 큰 관심 을 쏟 고 있 으며 , PVS - Studio 팀 역시 최선 을 다 하 여 이런 노력 을 돕 고 있 습니다 . 
 PVS - Studio 팀 은 여러분 의 프로젝트 코드 역시 도와 드릴 준비 가 되 어 있 습니다 . 툴 라이선스 와 추가 서포트 는 물론 , 코드 감수 , 코드 마이 그레이 션 등 의 서비스 도 제공 하 고 있 습니다 . . 
 여러분 의 프로그램 에 버그 가 최대한 적어지 기 를 바랍니다 . 
 2018 M 06 13 
 Astragon , Bus Simulator 18 Mod Kit 출시 
 에픽 게임즈 런처 를 통해 출시 된 새로운 언리얼 엔진 4 기반 모드 에디터 , Bus Simulator 18 Mod Kit 로 완전히 새로운 . .. 
 2018 M 06 10 
 선악 의 내 적 갈등 을 주제 로 한 게임 , Vampyr 
 DONTNOD 는 언리얼 엔진 4 의 강력 함 으로 선악 의 기준 이 가장 모호 했 던 1918 년 의 런던 을 창조 해냈 습니다 . 
 언리얼 엔진 4 . 20 프리뷰 1 출시 
 언리얼 엔진 4 . 20 릴리즈 가 다가오 는 가운데 , 그 첫 번 째 프리뷰 빌드 를 에픽 게임즈 런처 에서 다운로드 하 실 수 있 습니다 . 지금 다운로드 . ..