킥오프에서 범위를 못 박지 못하면 프로젝트는 끝까지 흔들린다

킥오프 미팅에서 "일단 시작하고 세부 범위는 진행하면서 맞추시죠"라는 말이 나오면 그 프로젝트는 후반에 반드시 한 번 크게 흔들린다. 최근에 그 대가를 다시 치렀고, 같은 실수를 반복하지 않으려고 정리해 둔다.

무엇이 문제였나

문제는 대상 자산의 경계가 모호했다는 점이었다. 웹 애플리케이션 진단으로 계약했는데, 그 애플리케이션이 호출하는 내부 API 게이트웨이가 범위에 포함되는지가 문서에 없었다. 진단 중반에 게이트웨이 쪽에서 흥미로운 동작이 관찰됐고, 여기서 두 가지 선택지가 생겼다.

• 범위 밖이라고 보고 기록만 남긴다
• 고객사에 알리고 범위 확대를 협의한다

결국 후자를 택했지만, 협의에 며칠이 걸리면서 일정이 밀렸다. 애초에 킥오프에서 "IP와 도메인 단위로 인/아웃을 문서에 적자"고 고집했다면 없었을 비용이다.

킥오프 체크리스트

이제는 아래 항목이 문서에 적히기 전에는 진단을 시작하지 않는다.

1. 대상 목록 — 도메인, IP 대역, 앱 패키지명을 표로. "등등"이라는 단어 금지
2. 명시적 제외 대상 — 포함 목록만큼 제외 목록이 중요하다
3. 테스트 계정 — 권한 등급별로 최소 2개씩. 계정 잠김 시 복구 연락처까지
4. 금지 행위 — DoS 성 테스트, 대량 데이터 추출, 운영 중 계정 변경 등
5. 긴급 연락 체계 — 장애 발생 시 몇 분 안에 누구에게 연락하는지
6. 결과물 형식과 납기 — 중간 보고 시점을 포함해서

범위 문서를 코드처럼 다루기

요즘은 범위를 YAML 로 적어 두고 진단 스크립트가 그대로 읽게 한다. 사람이 눈으로 확인하는 것보다 실수가 적다.

scope:
  in:
    - app.example.co.kr
    - 203.0.113.0/26
  out:
    - admin.example.co.kr   # 별도 계약 예정
    - 203.0.113.64/26       # 운영 DB 대역
  windows:
    - "평일 10:00-18:00 KST"

다음에 시도할 것

제안서 단계에서부터 이 체크리스트를 부록으로 붙여 보려 한다. 계약 전에 고객사가 범위를 한 번 더 생각하게 만드는 장치가 되지 않을까 싶다.