정형 기술 검토(FTR)로 초기 결함과 기술 부채 줄이기

결함이 구현 단계로 넘어가기 전에 잡는 검토

자동화된 테스트나 AI 도구가 있어도, 요구사항과 설계의 문제를 구현 전에 발견하는 일은 여전히 중요하다. 정형 기술 검토(FTR: Formal Technical Review)는 이런 초기 결함을 찾고 제거하기 위해 산출물을 계획적으로 검토하는 품질 보증 활동이다.

검토 대상은 요구명세서, 설계서, 소스코드처럼 개발 과정에서 만들어지는 산출물이다. 비정식적인 의견 교환과 달리 FTR은 참여자의 역할, 수행 절차, 검토 기록을 정해 두고 진행한다.

결함증폭 모델(Defect Amplification Model)에서 초기 설계 단계에 남은 오류는 구현 단계로 이동하면서 기하급수적으로 증폭된다. FTR은 이 흐름의 앞단에서 결함을 걸러내는 필터로 작동하며, 시스템 신뢰성을 지키는 장치가 된다.

검토 준비부터 수정 확인까지 이어지는 흐름

개별 검토자가 산출물을 미리 살핀 뒤, 정해진 역할을 가진 참여자가 검토 세션에서 결함을 식별하고 처리 방향을 결정한다. 수정이 필요한 항목은 재작업으로 넘기고, 재확인 후 최종 승인한다.

⤢✕

일정 압박 속에서도 검토를 남겨야 하는 이유

FTR을 건너뛰면 당장의 일정은 짧아 보일 수 있다. 다만 검토하지 않은 결함과 설계상 타협은 이후 단계의 수정 비용과 운영 부담으로 이어진다.

코딩 이전 단계에서 FTR은 결함의 75% 이상을 걸러낼 수 있다. 설계 단계에서 잡은 오류 하나는 테스트 단계에서 발견했을 때보다 수정 비용이 최소 10배에서 최대 100배까지 저렴하다. 결함이 뒤 단계로 갈수록 영향 범위와 수정 난이도가 함께 커지는 결함증폭을 줄이는 이유다.

FTR을 철저히 수행한 프로젝트는 그렇지 않은 프로젝트보다 유지보수 비용이 3배 이상 절감되는 것으로 알려져 있다. 구조가 탄탄하고 읽기 쉬운 코드는 이후 변경 요청에 더 유연하게 대응할 수 있다.

품질을 타협하는 결정은 기술 부채를 남긴다. FTR은 동료 검토를 통해 설계를 부채가 발생하기 전 단계에서 확인하게 해, 시간이 지난 뒤 이자가 불어난 문제를 마주할 가능성을 낮춘다.

검토는 결함만 찾는 자리가 아니다. 팀원은 서로의 설계 방식과 노하우를 접하고, 그 과정에서 기술 전수가 일어난다. 코딩 표준 준수율과 팀의 역량을 함께 끌어올리는 효과도 여기서 나온다.

FTR은 초기 산출물에 시간을 쓰는 활동이지만, 그 시간은 이후 장애 대응과 반복 수정에 쓰일 시간을 줄이는 데 연결된다.

Sources

• Pressman, R. S. (2014). Software Engineering: A Practitioner's Approach. McGraw-Hill.
• Fagan, M. E. (1976). Design and code inspections to reduce errors in program development. IBM Systems Journal.
• Wiegers, K. E. (2002). Peer Reviews in Software: A Practical Guide. Addison-Wesley.