스스로 세운 규칙을 네 번 고친 이유

지난 두 달 동안 우리는 스스로 세운 규칙을 너무 넓게, 또는 너무 좁게 적용했다가 네 번 고쳤습니다. 출발점은 9월 1일 계획 문서에 적힌 대로, 가게 한 곳의 경영을 한 화면에 모으는 도구였습니다. 이 글은 그 도구가 AI 에이전트용 공개 규격이 되기 전까지, 두 달 동안의 기록입니다.

본 값과 가정한 값을 나눈 날

‘관측하지 않은 금액은 만들지 않는다’는 규칙이 있었습니다. 맞는 규칙이었지만, 우리는 이 규칙을 시뮬레이션에도 똑같이 적용했습니다. 그러자 ‘앞으로 이렇게 되면’을 계산하는 일 자체가 막혔습니다. 그래서 둘을 나눴습니다. 실제 기록에 없는 금액은 비워 두고, 가정으로 하는 계산에는 가정이라고 표시합니다. 이틀 뒤에는 같은 규칙이 사용자가 직접 넣은 값까지 버리고 있다는 것을 알았습니다. 막아야 할 것은 개발자가 코드에 직접 써 넣은 숫자였고, 사용자가 넣은 값까지 막을 이유는 없었습니다. 그래서 규칙의 범위를 다시 좁혔습니다.

정의를 너무 좁게 잡았던 날

이번에는 반대로 정의를 너무 좁게 잡았습니다. 10월 1일, ‘음식점 현금 달력’이라고 적어 둔 정의를 고쳤습니다. 현금은 가장 눈에 잘 띄는 결과일 뿐, 우리가 다루려는 것의 전부가 아니었습니다.

‘올려 주세요’ 대신, 먼저 읽고 묻기

사용자가 파일을 올리면 계산한다는 설계가 있었습니다. 실제로는 사람들이 자료를 다 올리지 않고, 올려도 빈 곳이 많습니다. 그래서 먼저 읽어 보고 이상한 부분을 묻는 쪽으로 바꿨습니다. 같은 무렵, 시험에서 이긴 단순한 방법을 ‘채택’했다고 쓴 문장도 거둬들였습니다. 자료가 가게 한 곳, 1년이 안 되는 기간뿐이었습니다. 그 방법이 좋아서 이긴 게 아니라, 비교할 자료가 모자랐던 것입니다. 그 뒤로는 ‘넘어야 할 기준선’이라고 쓰고, 넘지 못하면 접는다는 조건을 시작하기 전에 적어 둡니다.

느린 이유는 만들 게 많아서가 아니었습니다

10월 중순에는 모든 힘을 결제 화면 하나에 모으자는 계획을 거둬들였습니다. 느려진 이유를 들여다보니 기능이 많아서가 아니었습니다. 설계하고, 검토하고, 다시 고치는 한 바퀴가 오래 걸려서였습니다.

정리하면: 규칙은 만든 사람도 너무 넓게, 또는 너무 좁게 적용합니다. 그래서 우리는 고칠 때마다 날짜와 함께 기록을 남깁니다.