NASA 안전 크리티컬 소프트웨어 개발 10대 코딩 규칙

대규모 복잡 소프트웨어 프로젝트의 코딩 표준

다양한 코딩 표준과 가이드라인이 코드 구조, 사용/금지 언어 기능 등 기본 규칙 정립. 효과적이려면 규칙 집합이 작고 구체적이어서 쉽게 이해·기억 가능해야 함.

NASA 제트추진연구소(JPL) 수석 과학자 제라드 홀츠만(Gerard J. Holzmann)이 정한 10대 코딩 규칙. 주로 C 언어 중심(로직 모델 추출기, 디버거, 안정적 컴파일러, 강력한 소스 분석 도구, 메트릭 도구 등 툴 지원 풍부). 인간 생명 달린 항공기, 우주선, 원전 제어 소프트웨어 등 안전 크리티컬 경우 필수 적용. 타 언어에도 적용 가능.

10대 규칙 상세

규칙 1: 단순한 제어 흐름

setjmp/longjmp, goto, 직접/간접 recursion 금지.

이유: 코드 명확성 향상, 검증 능력 강화. 재귀 없으면 순환 함수 호출 그래프 없음. 실행 경계가 실제로 보장됨.

규칙 2: 루프 고정 상한

모든 루프에 고정 상한 필요. 검증 도구가 루프 반복 횟수 상한 초과 불가함을 정적으로 증명 가능해야 함. 증명 불가 시 규칙 위반.

이유: 루프 상한 존재+재귀 금지로 폭주 코드 방지. 비종료 반복(프로세스 스케줄러 등) 예외: 종료 불가함 정적 증명 필요.

규칙 3: 초기화 후 동적 메모리 할당 금지

malloc 등 메모리 할당자, 가비지 컬렉터 예측 불가 행동으로 성능 악화. 프로그래머 실수로 메모리 오류 발생(과도 할당, 해제 누수, 해제 후 사용, 경계 초과). 고정 사전 할당 저장 영역 강제로 문제 해결, 메모리 사용 검증 용이. 힙 할당 대신 스택 메모리 활용 한 가지 대안.

규칙 4: 대형 함수 금지

함수 길이 표준 참조 형식(선언/문장당 1줄) 단일 용지 인쇄 분량 초과 금지. 약 60줄 코드 이하 권장.

이유: 과도하게 긴 함수는 구조 불량 신호. 각 함수는 이해·검증 가능한 논리 단위여야 함. 여러 화면 걸친 논리 단위 이해 어려움.

규칙 5: 최소 어설션 밀도

함수당 평균 최소 2개 어설션. 실제 실행서 절대 발생 안 해야 할 비정상 조건 검사. 부울 테스트로 정의. 어설션 실패 시 명시적 복구 조치. 정적 검사 도구가 어설션 실패/성립 불가 증명 시 규칙 위반.

이유: 업계 통계: 단위 테스트 10~100줄당 최소 1개 결함 포착. 어설션 밀도 높을수록 결함 차단 확률 증가. 강력한 방어적 코딩 전략 일환. 선/후조건, 매개변수/반환값, 루프 불변식 검증. 성능 크리티컬 코드 테스트 후 선택적 비활성화 가능.

규칙 6: 데이터 객체 최소 스코프 선언

데이터 은닉 원칙 지원. 모든 데이터 객체 가능한 최소 스코프 수준에서 선언.

이유: 스코프 밖 객체 값 참조/손상 불가. 다중/비호환 목적 변수 재사용 억제(오류 진단 복잡화 방지).

규칙 7: 매개변수와 반환값 검사

비void 함수 반환값 호출자마다 검사, 매개변수 유효성 함수 내부에서 검사. 엄격 적용 시 printf, 파일 close 반환값도 검사.

이유: 에러 대응이 성공 대응과 다를 바 없으면 반환값 명시적 검사 필요. close, printf 통상 해당. 반환값을 void로 명시적 캐스트해 의도적 무시 표시 허용.

규칙 8: 전처리기 제한적 사용

헤더 파일 포함, 매크로 정의만 허용. 재귀 매크로 호출, 토큰 결합, 가변 인자 리스트 금지. 표준 보일러플레이트(중복 헤더 포함 방지) 넘어 조건부 컴파일 지시어 1~2개 초과 시 정당화 필요. 각 사용 툴 기반 체커로 플래그, 코드 내 정당화.

이유: C 전처리기는 강력하고 모호해 코드 명확성 파괴, 텍스트 기반 체커 혼란. 비제한 전처리기 코드 효과 공식 언어 정의 있어도 해독 극히 어려움. 조건부 컴파일도 동일 중요: 10개 지시어로 1024(2¹⁰) 버전 가능, 테스트 노력 증가.

규칙 9: 포인터 제한적 사용

한 단계 이상 역참조 금지. typedef 선언이나 매크로 정의 안에 역참조 연산 숨김 금지. 함수 포인터도 금지.

이유: 전문가도 포인터 오용 쉬움. 데이터 흐름 추적/분석 어렵게 만듦(특히 툴 기반 정적 분석기). 함수 포인터는 정적 분석기 검사 유형 제한. 강력한 정당성 있을 때만 사용. 함수 포인터 쓰면 재귀 부재 증명 거의 불가능, 대체 분석 방법 제공 필요.

규칙 10: 첫날부터 모든 코드 컴파일

개발 첫날부터 모든 코드 컴파일. 컴파일러 경고 최고 엄격 설정 활성화. 경고 없이 컴파일돼야 함. 최첨단 정적 소스 분석기 최소 1개(권장 2개 이상)로 매일 검사, 경고 0개로 통과.

이유: 효과적 소스 분석기 다수 존재(일부 프리웨어). 어떤 코더도 이 가용 기술 활용 안 할 핑계 없음. 컴파일러/정적 분석기 혼란 시 혼란 유발 코드 다시 써서 자명하게 유효하게 만들어야 함.