가장 무너진 날에, 가장 무거운 입력을 요구하고 있었습니다

들어가며 — 구멍이 보이면 메우고 싶어집니다

개인적으로 굴리는 프로젝트가 하나 있습니다. 매일의 기록을 받아 추세를 보고 판단을 도와주는 작은 도구인데, 만드는 과정에서 만난 장면 하나가 업무에 그대로 옮겨지는 종류라 적어 둡니다.

이 도구의 핵심은 입력을 가볍게 만든 것이었습니다. 매일 숫자를 재서 적게 하면 며칠 만에 무너진다는 걸 알고 있었으니까요. 그래서 미리 정해 둔 항목을 체크만 하면 되게 했습니다. 체크 한 번이 곧 기록이 되도록요.

그러다 막혔습니다. 예외가 터진 날은 어떻게 하지?

미리 정해 둔 항목 밖의 일이 벌어진 날입니다. 체크리스트에 없는 것들이 잔뜩 들어온 날이요. 그날은 기록이 텅 빕니다. 데이터에 구멍이 생깁니다.

그래서 저는 곧바로 그 예외를 입력받는 기능을 만들려고 했습니다. 구멍이 보이면 메우는 게 본능이니까요.

1. 만들려던 기능이, 도구를 죽이는 기능이었습니다

키보드에 손을 올린 채로 잠깐 멈췄습니다. 그 기능이 요구하는 게 뭔지 계산해 보니 이랬습니다.

가장 정신없고 여력 없는 날에, 가장 손이 많이 가는 입력을 하라는 것.

평범한 날에는 체크 한 번이면 끝나는데, 예외가 터진 날에만 항목을 직접 적고 양을 재서 넣으라는 요구입니다. 하필 그날에요.

두 선이 만나는 자리에서 기록이 끊깁니다. 대부분의 기록 시스템이 하필 그 지점에서 입력을 늘립니다.

이게 무슨 결과를 낳는지는 뻔합니다. 그날 기록이 안 됩니다. 그리고 한 번 끊긴 기록은 대개 돌아오지 않습니다. 다음 날에는 “어제 것부터 채워야 하는데”가 부담으로 얹히고, 이틀이 밀리면 그때부터는 도구를 안 엽니다.

여기서 중요한 건 이게 의지의 문제로 보인다는 점입니다. 기록이 끊기면 우리는 사용자가 게을렀다고 결론 내립니다. 그런데 실제로 벌어진 일은 시스템이 하필 가장 약한 지점에서 요구를 늘린 것입니다.

이 구조는 업무 시스템에서 훨씬 자주 보입니다. 나중에 다시 다루겠습니다.

2. 질문이 틀렸습니다

한참 붙들고 있던 질문은 이거였습니다. “예외가 터진 날의 양을 어떻게 저장하지?”

그런데 이 질문 자체가 틀렸습니다. 제가 진짜로 알아야 하는 건 그날 얼마였는지가 아니라 그날이 어떤 종류의 날이었는지였습니다.

양을 재는 것은 측정입니다.
예외가 터졌다는 것은 사건입니다.

같은 데이터를 분류만 바꾸니 문제가 사라졌습니다. 그날 저장하는 건 숫자가 아니라 “예외가 있었다 + 언제 + 무엇”입니다. 입력은 체크 한 번보다 가볍고, 정보는 오히려 더 쓸모 있습니다. 왜냐하면 판단에 필요한 게 정확히 그거였거든요 — 얼마나가 아니라, 얼마나 자주.

막혀 있던 게 “어떻게(how)“였는데, 실제로 풀린 건 “이건 무슨 종류인가(what kind)“였습니다. 다시 만들기 전에 다시 분류하는 게 먼저였습니다.

3. 확인 — 판단 규칙은 이미 그 구멍을 우회하고 있었습니다

그래도 걱정이 남았습니다. 그날 숫자를 안 재면 데이터가 부정확해지는데, 판단이 틀어지지 않을까.

그래서 제가 쓰고 있던 판단 규칙을 열어 봤습니다. 그랬더니 그 규칙의 결정 변수가 개별 날짜의 숫자가 아니라 며칠 단위의 추세였습니다. 예외가 터진 날의 영향은 며칠 뒤 추세에 자동으로 나타납니다. 즉 그날의 숫자는 애초에 판단에 안 들어가고 있었습니다.

메우려던 구멍이, 사실은 아무 데도 안 뚫려 있었던 겁니다.

여기서 얻은 게 이 글에서 제일 실용적인 부분입니다.

막혔을 때, 새 기능을 설계하기 전에 내 판단 규칙부터 열어 보십시오. 그 규칙이 정말 그 데이터를 쓰고 있습니까. 안 쓰고 있으면 그 구멍은 메울 필요가 없습니다.

데이터에 구멍이 보이면 우리는 반사적으로 수집을 늘립니다. 그런데 그 데이터를 실제로 쓰는 규칙이 뭔지 확인하는 게 먼저입니다. 대개 우리가 모으는 것보다 규칙이 쓰는 게 훨씬 적습니다.

4. 업무 시스템은 이 실수를 훨씬 크게 합니다

이제 옮겨 보겠습니다. 같은 구조가 회사 안에 널려 있습니다.

프로젝트 관리 도구 — 일정이 밀리기 시작하면 지연 사유, 대책, 재산정 일정을 적으라고 요구합니다. 가장 바쁜 사람에게, 가장 바쁜 주에.
CRM — 계약이 깨진 건에 대해 실패 사유를 상세히 입력하라고 합니다. 영업사원이 가장 쓰기 싫은 순간입니다.
업무일지·주간보고 — 평온한 주에는 쓸 게 없고, 사고가 난 주에는 쓸 게 폭증합니다. 그런데 사고가 난 주에 보고서 쓸 시간이 제일 없습니다.
경비·근태 — 예외 처리(출장 중 야근, 대체 휴무)일수록 입력 항목이 늘어납니다.

전부 같은 모양입니다. 정상 상태에서는 입력이 가볍고, 예외 상태에서 입력이 무거워집니다. 그리고 우리가 정작 알고 싶은 건 예외 쪽인데, 데이터는 거기서만 비어 있습니다.

그래서 회의실에서는 이런 말이 나옵니다. “현업이 입력을 안 해서 데이터가 없어요.” 사실은 입력을 못 하게 설계해 놓고 안 한다고 말하는 것에 가깝습니다.

처방은 같습니다. 예외 상태에서는 요구를 늘리지 말고 줄이십시오. 숫자와 서술 대신 분류 하나만 받으십시오. “지연 — 자재”, “실패 — 가격”, “예외 — 고객 요청”. 그리고 상세한 설명은 그 주가 지나고 여력이 돌아왔을 때 받거나, 아예 받지 마십시오.

이건 데이터의 쓸모는 쓸 때가 아니라 모을 때 정해진다에서 다룬 이야기의 반대편 짝입니다. 그 글이 “어떻게 모을지를 미리 설계하라”였다면, 이 글은 “어디서는 안 모으기로 정하라”입니다. 수집 설계에는 두 종류의 결정이 다 들어갑니다.

마무리 — 안 만들기로 한 기능이 남긴 것

이 작업에서 최종적으로 늘어난 코드는 없습니다. 기능 하나를 안 만들기로 했으니까요.

그런데 도구는 그때부터 안 끊겼습니다. 예외가 터진 날에도 기록이 남고, 오히려 그 기록이 판단에 더 쓸모 있게 들어옵니다.

AI에게 뭔가를 만들라고 시키면 대개 만들어 줍니다. “예외 입력 기능 추가해 줘”라고 했으면 그 자리에서 깔끔하게 만들어 냈을 겁니다. 시켰으면 됐을 거고, 됐으면 저는 그게 옳은 줄 알았을 겁니다.

AI가 대신 못 해주는 건 “이건 만들지 말자”는 판단입니다. 그 판단은 그 일을 실제로 해본 사람한테서만 나옵니다. 요구사항 문서에는 절대 안 적혀 있고요.