정형기술검토로 소프트웨어 결함을 앞단에서 잡는 법

결함이 비용으로 번지기 전에 검토한다

정형기술검토(Formal Technical Review, FTR)는 요구사항 명세서, 설계 문서, 코드처럼 개발 과정에서 만들어지는 산출물을 체계적으로 읽고 결함을 찾아 수정하는 품질 보증 활동이다.

이 활동은 테스트 이전에 문제를 드러내는 데 의미가 있다. 개발 단계가 뒤로 갈수록 결함 수정 비용은 커지며, IBM 연구에서는 그 비용이 단계별로 5-10배씩 증가한다고 설명한다. 검토는 품질을 높이는 수단인 동시에 팀 안에서 기술 지식과 기준을 공유하는 장치가 된다.

검토 방식은 목적과 공식성에 따라 달라진다

인스펙션은 가장 공식적이고 구조화된 방식이다. 체크리스트를 사용하며 리더, 검토자, 기록자 역할을 명확히 나눈다. 사전 준비, 회의, 수정, 확인의 흐름으로 진행되고, 결함의 원인과 개선 방안을 논의하는 데 초점을 둔다.

워크스루는 인스펙션보다 덜 공식적이다. 개발자가 산출물을 설명하고 참석자가 질문하는 방식이며, 결함을 찾는 일뿐 아니라 대안을 제시하고 팀의 이해를 넓히는 데도 쓰인다.

기술 검토는 기술적 일관성과 품질을 확인하는 데 무게를 둔다. 전문가가 문서의 기술적 내용이 서로 맞는지, 정해진 표준을 따르는지 검토한다.

동료 검토는 동료 간에 비교적 유연하고 빠르게 피드백을 주고받는 방식이다. 페어 프로그래밍과 코드 리뷰가 여기에 포함된다.

검토는 수정 완료 확인까지 이어져야 한다

FTR은 회의 한 번으로 끝나는 활동이 아니다. 대상과 참여자를 정하고, 각자가 사전에 자료를 읽은 뒤, 발견 사항을 기록하고 수정 결과를 다시 확인하는 흐름이 필요하다.

⤢✕

계획 단계에서는 검토 대상을 고르고 검토 리더, 기록자, 검토자 같은 역할을 배정한다. 참여자는 3-7명 정도가 권장된다. 일정과 장소도 이때 정한다.

사전 준비에서는 검토 회의 최소 2-3일 전에 자료를 배포한다. 참가자는 개별적으로 산출물을 읽고 체크리스트를 이용해 결함, 질문, 이슈를 정리한다.

회의에서는 저자가 산출물을 짧게 소개한 뒤 발견된 결함과 이슈를 다룬다. 기록자는 논의 내용과 결함을 남기고, 결함의 심각도를 분류한다. 해결 방안은 논의할 수 있지만 실제 문제 해결은 회의 밖에서 처리한다.

이후 저자는 합의된 내용을 반영해 재작업한다. 검토 리더는 수정 사항을 확인하고 필요하면 추가 검토를 진행한다. 마지막 검증에서는 최종 산출물이 품질 목표를 충족하는지 확인한다.

역할을 나누면 검토의 책임도 분명해진다

⤢✕

검토 리더는 회의를 진행하고 일정과 전체 프로세스를 관리한다. 저자 또는 개발자는 검토 대상 산출물을 만들고 설명과 질문 응답을 맡는다.

검토자는 결함을 식별하고 대안을 제시하며 표준 준수 여부를 확인한다. 기록자는 회의 내용과 결함 사항을 남기고 검토 보고서를 작성한다. 관리자는 필요할 때 참관하고 리소스와 지원을 제공한다.

산출물별로 확인할 질문을 달리한다

요구사항에서는 명확성, 완전성, 검증 가능성, 일관성, 추적성, 우선순위, 이해관계자 요구 반영 여부를 확인한다.

설계 검토에서는 요구사항과의 일치, 설계 표준 준수, 인터페이스 정의의 명확성, 모듈 간 결합도와 응집도, 확장성과 유지보수성을 살핀다.

코드 검토에서는 코딩 표준, 알고리즘 효율성, 예외 처리, 보안 취약점, 주석과 문서화 수준을 점검한다. 같은 체크리스트를 기계적으로 통과시키기보다 산출물의 성격에 맞는 질문으로 사용해야 한다.

검토가 작동하는 팀의 조건

검토 범위가 지나치게 크면 집중력이 떨어지고 발견 사항도 흐려진다. 회의는 2시간 내외로 제한하고, 코드 검토라면 200-400 LOC 정도를 다루는 편이 적절하다.

분위기도 결과에 영향을 준다. 검토 대상은 사람이 아니라 산출물이라는 원칙을 분명히 해야 한다. 비난보다 개선에 초점을 두면 저자의 방어적 태도를 줄일 수 있다.

참가자는 사전에 자료를 읽고 체크리스트와 관련 표준, 지침을 준비해야 한다. 발견된 결함은 수정 여부까지 추적하고 검토 이력을 관리해야 반복되는 문제 패턴도 확인할 수 있다.

금융 시스템 현대화에서의 적용

A 금융사의 코어뱅킹 시스템 개발 프로젝트에서는 대규모 레거시 시스템을 현대화하면서 FTR을 적용했다. 100명 이상의 개발자가 참여했고, 엄격한 규제 준수가 요구되는 환경이었다.

아키텍처 설계 단계에는 보안, 성능, 확장성을 중심으로 외부 전문가가 참여하는 인스펙션을 적용했다. 상세 설계 단계에서는 모듈별 설계와 인터페이스 일관성을 확인하기 위해 워크스루를 사용했다. 코딩 단계에서는 일일 코드 리뷰와 주간 주요 모듈 정형 검토를 병행했다.

그 결과 테스트 단계의 결함 발견은 60% 감소했고, UAT(User Acceptance Test) 단계 결함은 80% 감소했다. 릴리스 후 1개월 내 중대 결함은 제로였으며, 최종 사용자 만족도는 92%를 달성했다.

이 사례에서는 체계적인 검토 프로세스, 검토 결과의 데이터베이스화와 분석, 검토 역량 교육, 경영진 지원이 핵심 조건으로 작용했다.

애자일과 DevOps 흐름에 맞추는 방법

애자일 환경에서는 스프린트 계획에 검토 활동을 포함하고, 백로그 아이템의 완료 정의에 검토 통과를 넣을 수 있다. 페어 프로그래밍과 풀 리퀘스트 기반 코드 리뷰는 경량화된 지속 검토 방식으로 활용된다.

DevOps 환경에서는 자동화된 코드 품질 검사 도구와 CI/CD 파이프라인을 검토 흐름에 연결할 수 있다.

⤢✕

시간 부담이 크다면 산출물의 중요도에 따라 검토 수준을 구분하고 회의를 효율적으로 운영해야 한다. 체크리스트 확인만 반복하는 형식적 운영은 검토 효과성을 측정하고 프로세스를 계속 개선하면서 피할 수 있다.

클라우드와 마이크로서비스처럼 기술 환경이 바뀌면 검토 체크리스트와 방법론도 갱신해야 한다. FTR의 핵심은 특정 형식을 고수하는 일이 아니라, 결함을 조기에 드러내고 수정이 완료될 때까지 책임 있게 추적하는 데 있다.