고객이 적어 준 답과 기계가 가진 사실

한 줄 요약

인테이크 답변은 고객의 기억이고 시스템은 사실이다. 첫 주의 일은 답변을 믿는 것이 아니라 칸마다 대조해 어긋난 칸과 답이 없는 칸을 목록으로 만드는 것이다.

왜 이게 필요했나

현장에 들어가기 전에는 보통 질문지를 보낸다. 버전이 무엇인지, 로그를 며칠 보관하는지, 어디와 연동되는지, 백업은 얼마마다 도는지. 답이 돌아오면 그걸 전제로 일정과 접근 권한과 이관 계획을 짠다. 그리고 들어가 보면 절반쯤이 다르다.

거짓말을 한 것이 아니다. 답을 적은 사람은 대개 그 시스템을 3년 전에 설치한 사람이고, 그 뒤로 누군가 보존 기간을 줄였고, 누군가 연동을 하나 더 붙였고, 백업 주기는 장애 뒤에 바뀌었다. 답변은 그 사람의 머릿속 시스템이고, 우리가 만나는 것은 지금의 시스템이다. 문서는 시스템보다 늦게 늙는다.

문제는 어긋남 자체가 아니라 어긋남을 모르는 채로 계획을 세우는 것이다. 로그가 30일 남아 있다고 믿고 "2주 전 사건을 재구성하겠다" 고 약속했는데 실제 보존이 14일이면, 그 약속은 이미 깨져 있다. 깨진 것을 아는 시점이 착수 첫날이냐 보고 전날이냐가 이 일의 성패를 가른다.

어떻게 동작하나

대조를 눈으로 하면 반드시 샌다. 칸이 스무 개를 넘어가고, 어떤 칸은 "대충 맞다" 로 보이고, 어떤 칸은 잴 방법이 없어 건너뛰게 된다. 그래서 대조는 규칙을 코드로 굳히고 기계가 돌리게 한다. 규칙은 칸마다 "어떻게 비교할 것인가" 하나만 정하면 된다.

• 정확히 일치(exact) — 버전 문자열, 시간대 이름처럼 한 글자만 달라도 다른 값.
• 범위 안(range) — 고객이 애초에 범위로 답한 칸. "80일 부터 100일 까지" 라고 답했으면 잰 값이 그 안에 들어오는지만 본다.
• 어림수 허용(tolerance) — 고객이 "하루 1,200건쯤" 이라고 답한 칸. 몇 퍼센트까지를 같은 것으로 볼지 숫자로 정해 둔다. 이 숫자는 규칙 파일에 적혀 있어야 하고, 적혀 있지 않으면 그것은 판정이 아니라 기분이다.
• 목록 비교(set) — 연동 대상처럼 순서가 뜻이 없는 칸. 순서를 섞어 적었다고 틀린 것이 아니다.

여기까지는 맞고 틀림의 이야기다. 실제 현장에서 더 중요한 것은 나머지 둘이다.

• 답이 없는 칸(unanswered) — 질문지의 그 칸이 비어 있다. 잴 수 있든 없든, 그 칸을 정하는 사람이 누구인지부터 찾아야 한다.
• 확인 불가(unverifiable) — 답은 있는데 시스템에서 확인할 자리를 못 찾았다. 복구 목표 시간(RTO), 대기 인원, 계약상 SLA 같은 것이 여기 온다.

이 둘을 "일치" 로도 "불일치" 로도 적지 않는 것이 핵심이다. 확인 못 한 것을 맞다고 적으면 나중에 아무도 그 칸을 다시 보지 않고, 틀렸다고 적으면 고객과 쓸데없이 다툰다. 모르는 것은 모른다고 적어야 목록에 남는다.

답변 칸 하나   ├─ 답이 없다                  → unanswered   (누가 정하는 값인지부터 묻는다)   ├─ 답은 있는데 잴 자리가 없다  → unverifiable (어디를 보면 되는지 묻는다)   └─ 답도 있고 잰 값도 있다        ├─ exact      같으면 match_exact        ├─ range      범위 안이면 match_in_range        ├─ tolerance  허용 오차 안이면 match_in_range        └─ set        집합이 같으면 match_exact                      아니면 전부 mismatch

규칙에 우선순위를 두는 이유도 같다. 답이 비어 있으면서 잴 자리도 없는 칸은 둘 다에 해당하는데, 이때 무엇으로 적을지 미리 정해 두지 않으면 사람마다 다르게 적는다. 이 실습은 답이 없는 쪽을 먼저 본다. 잴 수 없다는 사실보다 "이 값을 정하는 사람이 없다" 는 사실이 더 위험하기 때문이다.

현장에서 만나는 모습

첫째, 대조 결과를 지적 목록으로 쓰면 관계가 상한다. 열두 칸이 틀렸다는 표를 들고 가면 고객은 방어부터 한다. 같은 내용을 질문으로 바꿔 내면 대화가 된다 — "로그 보존이 30일이라고 적어 주셨는데 지금 서버에는 14일치가 있습니다. 어느 쪽이 맞는 값입니까?" 이 문장은 판정이 아니라 확인이고, 답하는 사람도 방어할 것이 없다. 그래서 이 실습은 대조기가 질문 문장까지 만들어 내게 한다.

둘째, 잰 값에는 근거가 붙어 있어야 한다. "로그 14일" 이 어디서 나왔는지 적혀 있지 않으면, 고객이 "우리는 아카이브에도 보관한다" 고 답했을 때 대화가 멈춘다. 근거가 "site/logs 디렉터리의 파일 이름 범위" 라고 적혀 있으면 곧바로 다음 질문으로 넘어간다 — 아카이브는 어디 있고 거기서는 며칠치를 볼 수 있는가.

셋째, 한 번 대조하고 끝내면 소용이 없다. 답변은 프로젝트 중간에도 갱신된다. 규칙과 대조기를 파일로 남겨 두면 2주 뒤에 같은 명령을 다시 돌려 그 사이 무엇이 바뀌었는지 볼 수 있다. 눈으로 한 대조는 다시 돌릴 수 없다.

넷째, 허용 오차를 쓰지 않으면 표가 온통 빨강이 된다. "하루 1,200건" 이라는 답과 "잰 값 1,104건" 을 불일치로 적으면, 진짜 문제인 백업 주기(24시간이라고 답했는데 실제는 6시간)가 같은 색으로 묻힌다. 어림수 칸에 오차를 허용하는 것은 봐주는 것이 아니라 신호를 살리는 일이다.

실무에서 진짜 중요한 것

• 답변은 증거가 아니다. 답변은 물어볼 자리를 알려 주는 지도이고, 증거는 시스템에서 잰 값이다.
• 판정 규칙을 먼저 정하고 대조한다. 대조하면서 규칙을 정하면 자기가 보고 싶은 결과가 나온다.
• 모르는 칸을 목록에 남긴다. 확인 불가는 결론이 아니라 다음 질문의 자리다.
• 결과는 질문 문장으로 낸다. 표는 우리가 보고, 고객에게는 질문을 준다.

다음 실습에서 할 것

(가상) 한빛물류의 인테이크 답변 9칸과 그 회사의 실제 시스템을 손에 쥔다. 시스템을 직접 재어 사실 파일을 만들고, 칸마다 판정 규칙을 정해 파일로 굳히고, 대조기를 만들어 정확히 일치·범위 안·불일치·답이 없음·확인 불가 다섯 가지로 판정한다. 채점기는 매번 다른 값으로 만든 답변과 사실을 여러분의 대조기에 넣어 실제로 실행하고 판정을 하나씩 대조한다. 마지막에는 어긋난 칸마다 다시 물어볼 질문을 기계가 만들게 하고, 그 결과를 보고서 네 절로 낸다.