잭 갠슬은 임베디드 프로젝트가 흔들리는 이유를 꼽았다

잭 갠슬(Jack Ganssle)은 2002년 5월 실패 원인을 순위로 꼽았습니다. 《Embedded Systems Programming》에 실린 글은 10위부터 1위까지 매겼고, 1위는 비현실적인 일정입니다. 저는 순위의 정연함보다, 이를 뒷받침할 비교 실험이 없다는 점이 더 눈에 들어옵니다. 숫자가 붙으면 경험에서 나온 판단도 측정 결과처럼 읽히기 쉽습니다.

GCC와 Clang이 기본 설정에서 asm을 확장 키워드로 인식한다는 논의는 컴파일러의 C 확장을 짚습니다. 갠슬의 칼럼은 정적 분석과 코드 검사 같은 검증 관행, 일정 설계까지 시선을 넓힙니다.

이 글에서 반가운 대목은 C 자체를 실패의 원인으로 몰지 않는 점입니다. 정적 분석(static analysis) 도구와 코드 검사로 예상 밖의 상황을 찾아내자는 제안입니다. 언어를 바꾸기보다 검증 습관을 바꾸라는 말입니다. 개발 과정에서 바로 손댈 곳을 짚는다는 점이 좋습니다.

이 글은 2002년 칼럼이며, 열 가지 순위를 비교 실험으로 뒷받침하지 않습니다. 따라서 이 순위만으로 오늘 프로젝트의 가장 큰 실패 원인이 일정이라고 단정할 수는 없습니다. 기능별 소요 시간을 근거로 일정을 잡고, 마감이 고정되면 기능 범위를 조정하라는 제안은 현재 계획에 대입할 수 있습니다.

오늘 맡은 기능 하나를 골라 예상 시간과 실제 소요를 나란히 적어 보십시오. 마감일까지 남은 시간으로 요구 기능을 감당하기 어렵다면, 추정치를 감추지 말고 줄일 기능을 팀과 정하십시오.

지금 맡은 프로젝트라면 일정 추정과 테스트 계획 가운데 무엇을 먼저 확인하시겠습니까?