애자일(Agile)은 '문서 면제권'이 아니다. 노대리의 감리 후기

엥? 우린 “애자일” 이라 스프린트 보고서가 전부인데요..?

개발 5년 차, 나에게도 소위 ‘개발자 곤조’가 있었다. 특히 애자일 방법론에 심취해 있었다. 애자일 선언문에 나오지 않는가. “포괄적인 문서보다는 작동하는 소프트웨어를.”

그래서 요구사항 정의서니, 추적표니 하는 것들을 ‘Waterfall의 잔재’ 취급했다. “Jira 티켓 끊고 스프린트 돌려서 기능 보여주면 그게 문서지, 굳이 엑셀 작업을 또 해야 하나?”라고 생각했다.

수원국 클라이언트가 기능을 빨리 내놓으라고 닥달할 때, 이 논리는 내 게으름을 합리화하기 딱 좋은 방패였다.

하지만 설계 감리 첫 날, 내 생각이 아예 틀려 먹었다는 것 깨달았다.

감리사님은 내 ‘작동하는 소프트웨어’를 보며 차갑게 물었다.

“이 소프트웨어가 계약된 요구사항에 맞게 설계되고 개발되었다는 것을 알 수 있는 문서가 준비된 게 하나도 없는데요? 스프린트 회고록이 계약 이행의 증거가 될 순 없습니다.”

그때 깨달았다.

애자일은 일하는 방식일 뿐, SI 프로젝트는 결국 증빙에 의한 납품으로 끝난다는 사실을.

RTM은 ‘개발의 지도’이자 ‘영수증’이다

내가 작성한 WBS는 단순한 일정표였고, RTM(요구사항 추적표)은 구색 맞추기용 엑셀이었다.

감리사의 지적은 명확했다.

• 불일치: 요구사항 ID -> 설계 ID -> WBS ID -> 테스트 ID가 1:1로 매핑되지 않았다.
• 결과: “이 코드는 어떤 요구사항을 구현한 겁니까?”라는 질문에 답할 수 없었다.

RTM은 단순한 엑셀이 아니라 청구서의 상세 내역이었다.

이 흐름이 끊기면 내가 짠 코드는 ‘청구할 수 없는 노동’이 된다.

결국, 역공학으로 문서를 다시 짜 맞추며 WBS 전체를 갈아엎어야 했다.

100페이지 캡처 보고서가 필요한 이유

설계 감리가 논리의 싸움이었다면, 현장 테스트 감리(Field Test)는 물리적인 증빙의 싸움이었다. 그리고 그 충격은 더 컸다.

나름대로 꼼꼼히 작성한 ‘테스트 결과서’를 제출했지만, 감리사는 이를 채택하지 않았다.

대신 현장에서 직접 시연(Demo)을 요구하고, 그 결과를 즉시 캡처하여 보고서로 만들 것을 지시했다.

그 자리에서 기능 실행 -> 화면 캡처 -> 문서화 작업을 무한 반복하여 100페이지가 넘는 보고서를 즉석에서 만들어냈다.

처음엔 “눈앞에서 봤으면 됐지, 왜 이런 노가다를 시키나” 싶어 억울했다.

하지만 작업이 끝나고 감리사님이 해준 말이 뇌리에 박혔다.

“감리는 ‘믿음’으로 하는 게 아니라 증빙으로 하는 겁니다. 제가 떠나고 나서 시스템에 문제가 생겼을 때, 오늘 이 기능이 정상이었다는 걸 증명할 수 있는 건 이 캡처 문서뿐입니다.”

그제야 이해가 됐다. 이 100페이지 보고서는 나를 괴롭히기 위함이 아니라, 나와 감리사 모두를 보호하기 위한 가장 확실한 보험이었다.

텍스트로 된 “Pass”는 누구도 책임져주지 않지만, 스크린샷은 거짓말을 하지 않으니까.

리스크 관리와 보안

이 혹독한 과정을 겪으며, 5년 차 개발자로서 놓치고 있던 기술적인 디테일들도 챙기게 되었다.

1. 리스크 관리: 요구사항 ID의 ‘원자성(Atomicity)’ 5년 차가 되도록 몰랐던 사실이 있다. 요구사항 ID를 어떻게 정의하느냐가 프로젝트의 성공률 통계를 결정한다는 것이다.

그동안 관습적으로 REQ-01: 게시판 기능처럼 뭉뚱그려 정의해왔다.

하지만 이번 감리를 통해, 이런 방식이 리스크 관리에 얼마나 취약한지 알게 되었다.

• Before: 게시판에서 ‘첨부파일’ 기능 하나가 오류가 나면, 게시판 전체가 ‘부적합’ 판정을 받는다. (실패율 100%)
• After: 조회, 등록, 수정, 삭제, 첨부파일로 ID를 쪼개면, 첨부파일 하나가 터져도 나머지 4개는 적합이다. (실패율 20%)

이는 꼼수가 아니다.

기능의 단위를 명확히 하여 문제의 범위를 축소(Isolation)시키는 것, 그것이 바로 엔지니어링이었다.

2. 보안 조언: 로그(Log)는 거짓말을 하지 않는다 이번엔 지적받지 않았지만, 쉬는 시간에 기술사님께 들은 조언은 섬뜩했다. “다음 보안 감리 때는 로그 파일부터 열어볼 겁니다.”

개발 편의를 위해 찍어둔 디버깅 로그에 비밀번호나 개인정보가 평문으로 남아있다면? 기능이 아무리 완벽해도 그 즉시 중대 결함이다.

코드는 거짓말을 할 수 있어도(UI로 속일 수 있어도), 로그는 시스템의 민낯을 그대로 보여준다.

다음 프로젝트부터는 Logger 설정부터 다시 볼 생각이다.

감리 통과를 위한 필수 문서 리스트

감리 현장에서 식은땀 흘리며 깨달은, 그리고 기술사님께 직접 컨펌받은 감리 필수 문서 리스트를 정리한다.

애자일이건 워터폴이건, 감리 받으려면 이건 무조건 있어야 한다. 미리미리 챙기자.

(나처럼 나중에 만들면 지옥을 본다.)

1. 계획 및 분석 단계 (뼈대)

사업수행계획서: 프로젝트 전체의 일정, 인력, 범위를 정의.

WBS (작업분해구조도): 단순 일정이 아니라, RTM과 매핑될 수 있는 작업 단위 ID 포함 필수.

요구사항 정의서 (SRS): ★가장 중요. 기능/비기능 요구사항을 ‘원자 단위’로 쪼개서 ID 부여.

요구사항 추적표 (RTM): 요구사항 ID부터 테스트 ID까지 1:1 매핑된 엑셀 파일.

2. 설계 단계 (설계도)

아키텍처 설계서: SW/HW 구성도, 인터페이스 현황 등.

화면 설계서 (UI/UX): 기획서. 메뉴 구조도(IA) 포함.

데이터베이스 설계서: ERD, 테이블 정의서, 코드 정의서.

인터페이스 정의서 (API Spec): 송수신 데이터 포맷, 연계 방식 정의.

3. 구현 및 품질 단계 (증빙)

소스코드 및 빌드 산출물: 형상관리(Git) 이력 포함.

테스트 계획서: 테스트 환경, 범위, 일정, 인력 정의.

테스트 시나리오/케이스 (TC): 입력값, 예상 결과, 수행 절차. (RTM과 매핑 필수)

테스트 결과 보고서: ★감리 현장 테스트 핵심. 단순 Pass/Fail이 아닌 수행 화면 캡처가 포함된 증빙 문서. (이걸 보고 직접 해보시고, 보고서를 쓰신다.)

결함 조치 보고서: 발견된 버그와 조치 내역, 조치 후 재테스트 결과. (나한테 진짜 딱 2시간 주더라 화면단 조치할 수 있는 거 해서 주면 조치 완료라고 해준다고… 덕분에 점심도 못 먹고 이슈 수정만 했다.)

4. 보안 및 성능 (비기능)

시큐어코딩 진단 보고서: 정적 분석 툴 결과 및 조치 내역.

성능 테스트 결과 보고서: JMeter 등 부하 테스트 결과 (응답속도, 임계치 증빙).

개인정보 영향평가: (해당 시) 개인정보 처리 방침 및 암호화 적용 내역.

5. 운영 및 이관 (마무리)

사용자 매뉴얼: 최종 사용자를 위한 가이드.

운영자 매뉴얼: 시스템 설치, 백업, 장애 조치 가이드.

인수시험 확인서: 고객이 최종적으로 OK 했다는 사인.

경험치가 쌓인다는 것

수원국의 독촉 때문에 어쩔 수 없었다고 생각했지만, 돌이켜보면 그것은 핑계였다. 문서를 나중에 만드는 것은 시간을 버는 것이 아니라, 미래의 나에게 고리의 이자를 쳐서 빚을 넘기는 행위였다.

설계 감리에서 논리를 배우고, 테스트 감리에서 증빙의 무게를 배웠다.

100페이지 보고서를 만들며 손목은 아팠지만, 나름 경험치를 진짜 많이 먹었다고 생각했다.

“개발은 코드를 짜는 행위이고, 엔지니어링은 그 코드를 증명하는 과정이다.”

마치며

이번 프로젝트 감리는 나에게 일종의 ‘전직 시험’ 같았다.

메이플에서 암흑 구슬인가? 그걸 모으는 건 정말 귀찮고 시간 아까워도 하고 나면 더 멋있는 스킬을 쓰고 강해지는 것처럼 이번 감리도 암흑 구슬(뭐, 한 200배 정도 더 어려운 거 같긴 하지만..)을 야무지게 모아서 갖다 주면서 얻는 것이 꽤나 많았다.

단순히 기능을 구현하는 주니어의 시각에서 벗어나, 프로젝트 전체의 품질과 리스크를 관리하는 시니어의 시각을 갖게 되었다.

이제 알 것 같다. WBS를 왜 짜는지, 테스트 케이스가 왜 꼼꼼해야 하는지.

이 모든 과정이 결국은 안전하고 견고한 시스템을 만들기 위한 필연적인 빌드업 과정임을.

마침.