정형기술검토 FTR로 개발 산출물 결함을 앞당겨 찾는 법

결함이 다음 단계로 넘어가기 전에 검토한다

정형기술검토(Formal Technical Review, FTR)는 소프트웨어 개발 생명주기(SDLC)에서 만들어지는 산출물을 공식적으로 검토해 기술적 결함을 이른 시점에 찾아 제거하는 정적 테스트 방법론이다. 요구사항 명세서, 설계서, 소스 코드가 대표적인 검토 대상이며, 실행을 전제로 하는 동적 테스팅보다 앞서 수행된다.

오류를 운영 단계에서 발견하면 수정 범위가 넓어지고 비용도 커진다. 페덱스의 법칙(FedEx Law), 즉 1:10:100 Rule은 결함을 발견하고 고치는 시점에 따른 비용 격차를 설명한다. 예방·설계 단계의 비용을 1로 볼 때, 개발·테스트 단계에서는 약 10배, 유지보수·운영 단계에서는 초기 대비 최대 100배 이상의 손실이 발생할 수 있다.

⤢✕

검토 회의가 결함 찾기에 집중되려면

FTR은 회의 자체가 목적이 되지 않도록 운영해야 한다. 참여자는 회의 전에 검토 대상물을 충분히 읽어야 하며, 회의에서는 미리 정한 범위와 안건에서 벗어나지 않아야 한다.

참여 인원은 3명에서 5명 내외의 전문 인력으로 구성해 의사결정 속도를 확보한다. 작성자를 평가하거나 비난하는 자리가 아니라 제품의 결함을 찾는 자리로 유지하는 것도 중요하다. 대안을 길게 토론하기보다 결함을 식별하고 기록하는 데 집중해야 소모적인 반박을 줄일 수 있다.

FTR이 품질과 개발 흐름에 남기는 효과

초기 검토는 논리 오류와 명세 불일치를 빨리 식별해 재작업 시간을 줄인다. 페덱스의 법칙이 보여 주듯 결함을 늦게 수정하는 비용을 피할 수 있어 전체 개발 비용 감소에도 연결된다.

검토를 통해 잔존 결함 밀도를 낮추면 시스템의 안정성과 신뢰성을 높일 수 있다. 팀 차원에서는 기술적 노하우를 공유하고 코딩 표준 준수 여부를 확인하는 과정이 되므로, 개발 역량을 함께 끌어올리는 효과도 있다.

계획부터 후속 확인까지 이어지는 검토 흐름

FTR은 즉석 회의가 아니라 역할과 순서가 정해진 프로세스다. 검토 대상과 참여자, 일정부터 정하고, 수정된 결과가 제대로 반영됐는지 확인한 뒤 종료한다.

⤢✕

계획 단계에서는 검토 대상을 고르고 중재자, 검토자, 서기 등의 역할과 일정을 정한다. 시작 단계에서는 산출물의 전반적 내용, 검토 범위, 기준을 참여자에게 공유한다.

개별준비 단계에서 각 검토자는 체크리스트를 사용해 사전에 결함을 찾는다. 이후 Review 미팅에서는 중재자가 논의를 이끌며 발견된 결함을 분류하고 기록하면서 필요한 의사결정을 한다. 작성자는 Rework 단계에서 지적된 사항을 수정·보완하며, 후속처리 단계에서 수정이 완전한지 확인한 후 검토 프로세스를 마친다.

검토 방식은 공식성과 역할에 따라 달라진다

워크스루(Walk Through)는 작성자가 이끄는 비공식 검토다. 개발 참여팀을 중심으로 진행하며, 설계 의도를 나누고 아이디어를 공유하거나 교육하는 목적에 적합하다. 자유로운 분위기에서 잠재 결함을 탐색할 수 있다.

리뷰(Review)는 요구사항 명세서와의 일치성을 확인하는 더 공식적인 회의다. 개발자, 관리자, 사용자, 외부 전문가 등이 참여해 비즈니스 가치와의 부합 여부를 확인하며, 프로젝트 진행 상황 점검과 의사결정권자의 승인도 포함한다.

인스펙션(Inspection)은 FTR 가운데 가장 엄격한 방식이다. 훈련된 중재자(Moderator)가 진행하고, 전문 지식을 지닌 팀이 역할 기반(Role-based)으로 참여한다. 체크리스트 사용이 필수이며, 통계적 데이터를 축적할 수 있고 가장 높은 결함 발견율을 기대할 수 있다.

운영 체계가 갖춰져야 검토가 지속된다

검토 항목을 카테고리별 체크리스트로 분명히 해 두면 중요한 결함을 빠뜨릴 가능성을 줄일 수 있다. 특히 인스펙션에서는 회의 흐름을 조절하고 갈등을 관리하는 중재자의 역량이 검토 품질에 직접 영향을 준다.

결함 지적이 인사 고과로 이어지지 않는다는 신뢰도 필요하다. 그래야 참여자가 문제를 숨기지 않고 드러낼 수 있다. 검토 기록과 이력을 관리할 협업 도구(Code Review Tool 등)를 함께 도입하면 반복되는 문제를 추적하고 검토 활동을 운영 체계로 유지할 수 있다.

Sources

소프트웨어 공학: 품질 보증 및 정적 분석 기법 (Software Engineering Standard)
IEEE Std 1028-2008 Standard for Software Reviews and Audits
프로젝트 관리 및 품질 관리 방법론 가이드라인