-
위 숫자와 아래 숫자가 다릅니다AI Agent 2026. 7. 24. 09:00728x90반응형

위 숫자와 아래 숫자가 다릅니다 같은 화면에 같은 값이 두 번 나옵니다.
맨 위 요약 카드에 한 번, 그 아래 구간별로 쪼갠 표의 머리줄에 또 한 번.
같은 지표에 같은 이름을 달아놨으니 당연히 같은 숫자여야 했습니다.
그런데 위는 -3.42, 아래는 -2.93이었습니다.
제가 발견한 게 아닙니다.
사용자가 먼저 봤고, 먼저 물었습니다.
"같은 값인데 왜 다르죠?
오류 아닌가요?"위와 아래가 다릅니다
저는 그 제보를 받고 코드부터 의심했습니다.
둘 중 하나가 잘못 더해지고 있겠거니 했죠.
위쪽 요약을 만드는 경로와 아래쪽 표를 만드는 경로를 화면 좌우에 나란히 띄워놓고 한 줄씩 손가락으로 짚어가며 따라 내려갔습니다.
더하는 순서가 어긋났나, 어디서 한 항목을 빠뜨렸나, 부호가 뒤집힌 곳은 없나.
중간값을 일부러 찍어가며 양쪽이 갈라지는 지점을 잡으려고 몇 시간을 뒤졌는데, 갈라지는 지점이 없었습니다.
양쪽 다 멀쩡했어요.
각자 자기 방식대로 한 치도 안 틀리고 계산하고 있었습니다.
한쪽이 그냥 버그였으면 차라리 쉬웠을 겁니다.
둘 다 맞는데 서로 다르다는 게, 그게 진짜 문제였습니다.급한 대로 한쪽을 다른 쪽에 맞춰 끌어오는 수정을 적고 "처리 완료"로 닫았습니다.
화면이 멀쩡해 보이게 만들었으니 끝났다고 생각했죠.
그게 화근이었습니다.
그 수정은 정작 실제 서비스에는 올라가지 못한 채 제 작업 폴더에만 남아 있었고, 저는 닫았다고 믿고 손을 뗐습니다.
닫은 건 제 머릿속이었지 사용자 화면이 아니었습니다.사용자가 가설을 들고 다시 왔습니다
다음 날, 같은 사용자가 같은 화면을 다시 제보했습니다.
숫자만 바뀌어 있었습니다.
위는 +2.10, 아래는 +2.47.
어제 못 올린 그 수정이 그대로 안 올라간 상태였으니 똑같은 증상이 다른 회차에서 또 뜬 거였죠.
그런데 이번엔 제보에 한 줄이 더 붙어 있었습니다."위는 소수점 한 자리 평균이고 아래는 두 자리 평균이라서, 반올림 때문에 달라지는 거 아닐까요?"
사용자가 직접 원인을 추리해서 보내온 겁니다.
솔직히 그럴듯했습니다.
화면에 보이는 구간별 숫자가 죄다 소수점 한 자리로 깔끔하게 떨어져 있었으니까요.
저는 그 가설을 받아 들고 다시 코드로 내려갔습니다.
그리고 정말로, 한쪽 경로는 소수점 두 자리에서 끊고 다른 쪽은 세 자리에서 끊고 있었습니다.
반올림 자리수가 통일이 안 돼 있던 거예요.
"찾았다" 싶었습니다.
사용자가 짚은 데를 코드가 그대로 받쳐주니, 이제 자리수만 맞추면 끝이라고 믿었습니다.확인 삼아 종이에 양쪽 값을 자릿수 안 끊고 날것 그대로 적어 빼봤습니다.
차이가 0.3에서 0.5씩 났습니다.
손이 멈췄습니다.
반올림으로 설명될 차이가 아니었습니다.
둘째 자리에서 끊든 셋째 자리에서 끊든, 끽해야 0.01쯤 흔들릴 일이지 그렇게 큰 격차는 절대 안 벌어집니다.
사용자 가설은 틀렸습니다.
그것도 코드가 절반쯤 받쳐줄 만큼 아주 그럴듯하게 틀렸습니다.
코드 한쪽이 정말로 자리수가 안 맞았으니, 그 작은 사실 하나가 큰 가설을 진짜처럼 보이게 분칠해주고 있었던 거죠.
하마터면 자리수만 맞춰놓고 "해결"이라고 또 닫을 뻔했습니다.둘은 처음부터 다른 숫자였습니다
날것의 값을 한참 노려보다가 그제야 보였습니다.
위 숫자와 아래 숫자는 같은 데이터를 보고 있긴 한데, 서로 완전히 다른 계산을 하고 있었습니다.
위쪽 요약은 회차 단위로 묶어 기준선과 비교한 차이값이었고, 아래쪽 표 머리줄은 거리 구간마다 따로 낸 평균들을 그냥 죽 더한 합이었습니다.
같은 재료를 썼을 뿐 수학적으로 다른 두 음식이었습니다.
둘이 같을 이유가 처음부터 없었던 겁니다.문제는 데이터가 아니었습니다.
'같다'를 아무도 정의한 적이 없다는 거였어요.
화면은 두 숫자에 똑같은 이름을 붙여놓고, 사용자에게 "이 둘은 같은 값"이라고 말없이 약속해버렸습니다.
약속한 적도 없는 약속을요.
그래서 그날 노트에 처음 적은 건 코드 수정안이 아니라same_metric_top_card == same_metric_section_header ?라는 질문 한 줄이었습니다.
반올림이든 시간대 보정이든 빈 칸이든, 우리가 '같다'고 부르는 것의 정체를 한 번도 적어두지 않으면, 검증은 통과를 해도 정의되지 않은 비교를 돌리고 있을 뿐입니다.통과한 검사가 못 잡은 한 칸
제일 서늘했던 건 따로 있었습니다.
그 소동이 벌어지던 사이에 숫자 검증 리포트가 한 번 돌았습니다.
지표 83개 중 83개 통과, 또 다른 점검에선 77개 중 76개 통과.
화면 가득 초록불이었습니다.
그런데 그 리포트는 "위 카드 값과 아래 표 머리줄 값이 같은가"를 단 한 번도 묻지 않았습니다.
숫자 하나하나가 제 산식대로 맞는지는 다 봤는데, 두 숫자가 서로 같아야 한다는 항목 자체가 검사 목록에 없었어요.
사용자 눈에 가장 먼저 띈 그 한 줄이, 우리 검사 시트에는 처음부터 빈 칸이었습니다.
그래서 검사를 다 통과하고도 화면은 틀려 있었습니다.
초록불은 "옳다"가 아니라 "안 물어봤다"는 뜻이었던 거죠.결국 내린 결론도 깔끔하지 않았습니다.
아래 표를 위와 같은 값으로 바꿔 받아오든지, 아니면 "이건 거리 구간 소계라 위와 다른 숫자"라고 이름표를 떼어 다시 붙이든지.
둘 중 뭘 할지 정한 뒤에도 이 건은 그 배포 주기 안에 못 올라갔습니다.
제보 상태는 여전히 '미처리'로 남았고, 사용자 화면에는 지금도 서로 다른 두 숫자가 같은 이름을 단 채 나란히 떠 있습니다.728x90반응형'AI Agent' 카테고리의 다른 글
청구서의 주인공은 제 프롬프트가 아니었습니다 (0) 2026.07.25 데이터에 없는 원인을, AI는 누가 막아둔 칸까지 넘어서 지어냈어요 (0) 2026.07.24 AI는 시키는 대로 다 만들었고, 일곱 시간 뒤에 그걸 지운 건 나였다 (0) 2026.07.23 멈춤 조건은 왜 나한테만 안 걸릴까 (0) 2026.07.23 '삭제 ㄱㄱ'이라 쳤는데 AI가 설명을 채워 넣었다 (0) 2026.07.22