[연재] × "다 됐습니다"라고 말한 뒤에 — 무엇을 보고 됐다고 할 것인가

"7건 중 5건 성공" — 저는 열 건을 맡겼는데요

8월 9일이었어요. 새 도메인을 검색엔진에 알리는 일이 밀려 있었습니다. 주소를 하나씩 넣고 색인 요청 단추를 누르는, 손만 있으면 되는 일이었죠. 판단할 게 하나도 없으니 딱 넘기기 좋은 모양이었습니다. 그래서 열 건을 맡겼어요.

한참 뒤에 보고가 올라왔습니다.

"7건 중 5건 성공"

읽고 잠깐 멈췄습니다. 열 건을 맡겼는데 왜 일곱 건 이야기가 올라오지?

목록을 하나씩 짚어봤어요. 같은 주소 하나가 두 번 적혀 있었고, 하나는 아예 빠져 있었습니다. 그러니까 일곱 줄이 적혀 있어도 실제로 다룬 주소는 여섯 개였고, 열 개 중 넷은 손도 안 댄 상태였던 거예요.

그래도 다섯 건은 됐다니까, 그중 하나를 직접 열어봤습니다. 서치콘솔에 들어가서 그 주소의 색인 요청 이력을 봤어요.

요청이 들어간 기록 자체가 없었습니다.

먼저 하나 못 박고 갈게요. 이 편은 도우미를 흉보는 글이 아닙니다. 저 보고를 만든 쪽은 시킨 대로 했고, 자기가 본 것을 자기가 이해한 대로 적었어요. 틀린 건 도구가 아니라 그걸 확인 없이 받아 쓴 쪽입니다. 저요.

그리고 이 편이 이 부(관제)의 마지막이라, 결국 이런 질문 하나로 모입니다. "다 됐습니다"라는 말을 받았을 때, 무엇을 봐야 진짜 된 걸로 칠 수 있나.

왜 요청이 안 들어갔나 — 글자가 깨져서 없는 주소로 갔습니다

원인을 캐 들어가니 엉뚱한 데서 나왔어요. 한글이 깨져 있었습니다.

브라우저 주소창에 글자를 넣을 때, 자판을 한 글자씩 두드리는 방식으로 넣고 있었거든요. 영문은 멀쩡한데 한글이 뭉개졌어요. 얼마나 뭉개졌냐면 이렇습니다.

• 내돈내산 → 내도내산
• 쏠쏠투플러스 → 잣주주플러스

잣주주플러스요. 저런 글이 세상에 있을 리가 없죠. 그러니까 존재하지 않는 주소에 색인 요청을 넣고 있었던 겁니다. 화면에는 "색인 생성 요청 거부됨"이 떴고요.

고친 방법은 단순했습니다. 자판을 두드리지 말고 입력칸에 값을 통째로 밀어 넣고, 넣은 뒤에 화면에 뜬 글자를 눈으로 확인하는 것. 지금도 한글을 브라우저에 넣을 때는 이 순서를 지킵니다.

여기서 중요한 건 방법이 아니라 순서예요. 넣었으면 화면을 본다. 이 한 줄이 없으면, 넣는 데까지는 성공이고 그다음은 아무도 모릅니다.

그리고 저는 그걸 "할당량 초과"라고 했습니다

이 편에서 제일 부끄러운 대목이 여기예요.

"요청 거부됨"이 뜬 걸 보고 저는 이렇게 결론 내렸습니다. "하루 요청 할당량을 다 썼나 봅니다." 그럴듯하죠. 검색엔진에는 실제로 하루 제출 한도가 있으니까요. 그리고 저는 그 결론을 그대로 밖으로 내보냈습니다.

없는 벽을 있다고 말한 겁니다. 진짜 벽은 할당량이 아니라 제가 깨뜨린 글자였어요.

이게 왜 무서우냐면, 저 오진은 더 캘 이유를 없애버리기 때문입니다. 할당량이 문제면 내일 다시 하면 되니까 오늘은 손을 놓게 되죠. 원인을 잘못 짚으면 일이 안 끝나는 게 아니라, 끝난 줄 알고 자리를 뜨게 됩니다.

보고서를 검사하면, 보고서의 거짓말을 그대로 물려받습니다

이날 이후로 규칙을 하나씩 만들었는데, 첫 번째가 이겁니다.

처음엔 이렇게 생각했어요. "보고가 틀렸으니, 보고를 한 번 더 검사시키면 되겠다." 그래서 맡긴 일의 결과 보고서를 다른 쪽에 넘겨서 "이거 맞는지 봐 달라"고 했습니다.

소용이 없었습니다. 당연하죠. 보고서에는 "성공"이라고 적혀 있고, 검사하는 쪽이 볼 수 있는 것도 그 "성공"이라는 글자뿐이거든요. 거기서 나올 수 있는 답은 "성공했다고 하네요"밖에 없습니다.

보고서를 검사하면 보고서의 거짓말을 그대로 물려받습니다.

그래서 규칙을 바꿨어요. 검사하는 쪽은 보고서를 보지 않습니다. 화면, 파일, 실제 주소, 원문 — 실물을 직접 엽니다. 서치콘솔에 그 주소가 실제로 들어갔는지는 서치콘솔을 열어야 알 수 있지, 보고서를 백 번 읽어도 안 나와요.

실물을 줘도 못 잡습니다 — 자신 있는 말투에 넘어가거든요

그런데 실물만 쥐여주면 되는 게 아니더라고요. 이게 두 번째 규칙이 생긴 이유입니다.

원자료를 통째로 주고 "이 결과가 맞는지 확인해 달라"고 하면, 놀랍도록 자주 "맞습니다"가 돌아옵니다. 왜냐면 확인하는 쪽도 결국 글을 읽고 판단하는데, 앞의 보고서가 자신 있는 말투로 딱 떨어지게 쓰여 있으면 그 확신에 끌려가거든요. "완료했습니다", "정상 처리되었습니다" 같은 문장은 사람도 잘 못 의심합니다.

"확인해 봐라"는 지시는 지시가 아니었어요. 무엇을 무엇에 맞대야 하는지가 안 적혀 있으니까요.

그래서 검사 지시에는 비교의 양변을 문장으로 적기로 했습니다.

왼쪽은 판단을 통째로 넘기는 말이고, 오른쪽은 대조할 대상을 손에 쥐여주는 말입니다. 차이가 별것 아닌 것 같은데 결과가 완전히 다릅니다.

덧붙여 두 줄을 더 적습니다. "미묘해 보인다고 넘어가지 마라"와 "말투를 근거로 삼지 마라". '성공', '완료' 같은 표현은 증거가 아니에요. 증거는 상태가 바뀐 흔적입니다 — 날짜, 파일, 응답 코드, 화면에 새로 생긴 줄.

"이 수치가 원문에 그대로 있는지 찾아봐라" — 그랬더니 두 개가 없었습니다

이 규칙이 처음으로 값을 한 게 같은 날 오후였습니다.

일을 어떻게 나눠 시키는 게 나은지 알아보려고 논문 조사를 시켰어요. 여러 편을 훑어서 결론과 수치를 뽑아 오는, 넓고 얕은 일이라 넘기기 좋은 종류였습니다. 실행 세 갈래에 검사 한 갈래를 붙였고, 검사 쪽에는 위 규칙대로 적어 보냈습니다. "보고서 말고 원문을 열어라. 여기 적힌 수치가 초록에 글자 그대로 있는지 찾아라."

돌아온 답이 이랬습니다. 수치 두 개가 원문에 없습니다. 하나는 퍼센트, 하나는 배수였는데 둘 다 논문 어디에도 없는 숫자였어요. 그럴듯하게 생긴 자리를 그럴듯한 숫자로 메꾼 겁니다.

이게 이 연재에서 계속 나오는 그 사고예요. 이 연재 맨 앞에서 다뤘던, 매장 사진을 주고 리뷰를 시켰더니 사진에 없는 장면("직원이 외국어로 말하니 화면에 자막이 떴다")을 써낸 것과 똑같은 모양입니다. 자료가 애매하면 빈자리를 그럴듯한 것으로 채웁니다.

그리고 이날 처음으로, 그걸 사람이 아니라 검사 갈래가 잡았습니다. 규칙 한 줄 바꾼 값이 그거였어요.

세는 일은 아예 안 맡깁니다

세 번째 규칙은 제일 짧습니다. 개수·중복·누락은 사람도 도우미도 세지 않습니다. 짧은 프로그램이 셉니다.

맨 처음 사고를 다시 보세요. 열 건을 맡겼는데 일곱 줄이 올라왔고, 그중 하나는 중복이고 하나는 누락이었습니다. 이건 판단이 틀린 게 아니라 셈이 틀린 것이에요.

그런데 셈은 파이썬 세 줄이면 정확하고, 공짜고, 무엇보다 셀 줄 압니다. 맡긴 목록과 결과 목록을 집합으로 만들어서 차집합만 찍어보면 빠진 게 그대로 나와요. 여기에 애매함이 낄 자리가 없습니다.

그래서 지금은 순서가 이렇습니다. 먼저 프로그램으로 세고 → 숫자가 맞으면 → 그다음에 내용이 맞는지를 본다. 검사하는 쪽은 내용만 봅니다. 숫자는 안 물어봐요.

화면이 "끝났다"고 말할 때, 그게 확인인지 짐작인지

53편에서 만든 현황판 이야기를 한 번만 다시 부를게요. 거기서 정확히 같은 문제를 만났거든요.

현황판에는 "지금 뭐가 돌고, 뭐가 끝났나"가 뜹니다. 그 값을 기록 파일에서 읽어오는데, 만들다 보니 이상한 걸 발견했어요. 기록에 "시작했다"는 있는데 "끝났다"가 없는 겁니다.

세어봤습니다. 관련 기록 535줄 중 257줄이 그랬어요. 그리고 실행 520개 중에 시작과 끝을 둘 다 가진 건 0개였습니다. 하나도 없었어요. 뒤로 돌린 일은 끝났다는 자국을 원래 자리에 영영 안 남기는 구조였던 겁니다.

문제는 그 위에 화면을 얹은 방식이었어요. 없는 값을 0과 물음표로 채워서 '끝난 일'로 화면에 내보내고 있었습니다. 화면에 뜬 목록의 절반이 지어낸 값이었던 거죠. 보고서를 그대로 믿은 것과 똑같은 사고를, 이번엔 제가 만든 화면이 하고 있었습니다.

고친 방법이 이 편의 제목에 대한 답에 가장 가깝습니다.

• 끝났는지를 다른 데서 확인합니다. 그 일이 자기 자리에 남기는 기록 파일이 90초 넘게 안 변하면 끝난 것으로 봅니다.
• 그런데 이건 확인이 아니라 짐작이잖아요. 그래서 화면에 물음표를 붙여서 내보냅니다. 끝남?처럼요.

짐작을 안 하는 게 아니라, 짐작을 짐작이라고 표시하는 겁니다. 이걸 안 하면 며칠 뒤의 제가 그 화면을 증거로 삼습니다.

덤으로 하나 더 잡혔어요. 대화가 이어지거나 접히면서 같은 기록이 두 번 들어가는 경우가 있었습니다. 30개 중 2개였는데, 그대로 두면 화면에 두 번 그려지고 쓴 양도 두 배로 잡힙니다. 맨 처음 사고에서 주소 하나가 두 번 적혔던 것과 같은 모양이라, 이것도 세는 프로그램이 잡았습니다.

그래서 틀린 걸 세기 시작했습니다

규칙을 이만큼 손보고 나니 당연한 질문이 옵니다. "그래서 얼마나 나아졌는데?"

이 질문 앞에서 제가 할 수 있는 말이 "좋아진 것 같습니다"뿐이었어요. 그런데 그건, 바로 그날 걸러낸 것과 똑같은 종류의 문장입니다. "성공했습니다"랑 뭐가 달라요.

그날 저녁 16시 12분, 커밋 하나로 사고 원장을 열었습니다. 도구랄 것도 없는 물건이에요. 파이썬 파일 하나에 한 줄짜리 기록이 쌓입니다.

한 건에 적는 건 여섯 가지입니다.

• 무엇이 났나 — 한 줄로
• 어느 자리에서 났나 — 넘긴 쪽인지, 제가 붙어서 결정한 자리인지, 프로그램인지, 바깥 서비스인지
• 어떤 종류인가 — 오보고 · 오진 · 허위성공 · 세기틀림 · 미검증인용 · 입력깨짐 · 설계오류…
• 누가 잡았나 — 만드는 중에 스스로 / 검사 갈래가 / 결과를 받아보고서야
• 밖으로 나갔나 — 틀린 채로 전달됐는지
• 구조적으로 막았나 — 원인 자체를 없앤 경우에만 대책을 적습니다

핵심 지표는 딱 하나로 정했어요. 틀린 게 밖으로 나간 건수. 나머지는 그걸 설명하는 값입니다.

이 기준이 마음에 드는 이유가 있습니다. 잡히기만 하면 그건 사고가 아니라 비용이에요. 검사에 돈이 더 들었을 뿐이지 아무도 안 다쳤거든요. 사고는 틀린 채로 나갔을 때만 사고입니다. 그러니 목표가 "틀리지 않기"가 아니라 "틀린 걸 밖으로 안 내보내기"가 됩니다. 훨씬 지킬 만한 목표예요.

그리고 한 가지 장치를 더 넣었습니다. "막았다"고 적어둔 종류가 나중에 또 나오면 경고를 띄웁니다. 대책이 가짜였다는 뜻이니까요. 이게 없으면 대책 목록만 길어지고 사고는 그대로 납니다.

30일치를 뽑아보니, 제일 많이 틀린 건 도우미가 아니었습니다

8월 19일에 최근 30일치를 뽑아봤습니다. 숫자가 이랬어요.

솔직히 좀 아팠습니다. 87건 중 41건이면 절반 가까이가 밖으로 나갔다는 거고, 31건은 그물이 다 뚫려서 마지막에야 걸렸다는 뜻이거든요.

그런데 제일 뼈아픈 줄은 따로 있었어요. 어느 자리에서 났나를 세는 칸입니다.

넘긴 쪽에서 난 사고는 8건입니다. 제가 붙어 있던 자리에서 난 게 70건이고요.

그날 하루만 봐도 그렇습니다. 원장에 열 줄이 남았는데 그중 여섯 줄이 제 판단이 들어간 자리에서 났고, 결과를 보고서야 잡힌 세 건은 전부 그쪽이었습니다. 맡긴 쪽은 오히려 검사에 걸려서 밖으로 안 나갔어요.

이게 이 편에서 제일 하고 싶은 말입니다. 사고 장면은 "도우미가 거짓 보고를 했다"로 시작했지만, 원장을 켜고 한 달을 세니 손이 가장 많이 미끄러진 자리는 판단이 들어간 자리, 즉 제 자리였습니다. 도우미를 못 믿겠다는 결론으로 갔으면 정작 제일 큰 구멍을 못 봤을 거예요.

세 번 다 같은 모양이었어요 — 재놓고도 그 숫자를 안 썼습니다

그날 제 자리에서 난 여섯 건을 다시 읽어봤더니, 세 건이 똑같은 모양이었습니다. 이게 좀 무섭더라고요.

하나. 짧은 영상 제목을 70자로 만들어서 그대로 내보냈습니다. 그런데 저는 그 전에 성과가 좋았던 편들의 제목 길이를 이미 재놨어요. 24~30자였습니다. 근거를 다 넣겠다고 욕심내다가, 제가 재놓은 숫자를 그냥 안 봤습니다.

둘. 만들던 도구 화면에 육각형 타일을 벌집처럼 깔려고 했는데, 세로 겹침을 눈대중으로 -11px 로 뒀습니다. 벌집이 아니라 그냥 줄 세운 육각형이 나왔죠. 규칙은 뻔합니다 — 꼭짓점이 위로 선 육각형은 높이의 3/4마다 한 줄이니까 66px이면 -17px입니다. 높이 값은 제 손에 있었고, 나눗셈 한 번을 안 했습니다.

셋. 같은 도구에서 5레벨 덱에 5코스트 기물을 채웠습니다. 그 레벨 상점에 5코스트가 뜰 확률은 0이에요. 그 확률표는 제가 만든 규칙 파일에 이미 들어 있었습니다.

세 건 다 똑같습니다. 숫자를 재놓고, 그 숫자를 안 썼어요. 몰라서 틀린 게 아니라 재놓고 안 본 겁니다.

그리고 이 중 둘은 시험을 통과했습니다. 육각형 건은 자동 시험 70개가 전부 초록불이었어요. 시험이 못 보는 자리였던 거죠. 화면은 시험이 아니라 눈으로 봐야 합니다.

넘겼는데 내가 또 하면, 두 배로 뭅니다

원장을 하나 더 열었습니다. 위임 원장이에요. 사고랑 같은 통에 넣으면 두 보고서가 다 흐려져서 따로 뒀습니다. 여기엔 "이 일을 넘겼나 혼자 했나, 얼마나 들었나, 그리고 넘겼는데 내가 또 했나"를 적습니다.

마지막 칸이 핵심입니다. 넘겼는데 결과를 못 믿어서 제가 다시 하면, 넘긴 값도 내고 제 값도 그대로 내는 거잖아요. 두 배로 무는 겁니다.

맨 앞의 색인 요청 열 건이 정확히 그 줄에 들어가 있어요.

두 줄 다 "예"입니다. 첫 줄은 보고가 어긋나서 제가 처음부터 다시 확인했고, 둘째 줄은 재확인을 또 맡겼다가 결국 제가 직접 값을 넣었어요. 확인을 맡겼더니 그 확인을 또 확인하게 된 겁니다.

30일치 위임 원장은 이랬습니다. 결정 13건 중 넘긴 게 6건, 그중 다시 한 게 2건(재작업률 33%). 재작업으로 태운 값이 35만 남짓이었어요.

그래서 지금은 넘길지 말지를 이 한 줄로 가릅니다. "넘긴 결과를 내가 다시 안 봐도 되나?" 다시 봐야 하는 일이면 처음부터 안 넘깁니다. 대신 넘기는 일에는 검사할 문장을 미리 쓸 수 있어야 합니다 — "이 목록과 글자 하나까지 맞춰봐라"처럼요. 그 문장이 안 써지면 그건 손이 아니라 판단이 필요한 일이라 제가 해야 하는 일입니다.

확인은 남에게 못 맡깁니다

이 부의 이야기를 정리하면 이렇게 됩니다.

자동으로 도는 일이 늘면서 제가 직접 하는 일은 확실히 줄었어요. 손이 필요한 자리는 대부분 넘길 수 있게 됐고, 넘기면 실제로 빠르고 쌉니다.

그런데 시키는 일이 늘어난 만큼 확인하는 일이 그대로 남습니다. 아니, 오히려 늘어요. 열 개를 시키면 열 개를 봐야 하니까요.

그러면 확인도 넘기면 되지 않느냐. 실제로 해봤습니다. 그게 위 표의 둘째 줄이에요. 확인을 넘기면 그 확인을 또 확인해야 합니다. 이걸 계속 밀면 끝이 없고, 어딘가에서는 "이건 내가 눈으로 봤다"라고 말할 수 있는 자리가 하나 있어야 그 줄이 멈춥니다.

그 자리가 사람입니다. 잘나서가 아니라, 책임을 질 수 있는 마지막 칸이라서요. "다 됐습니다"라는 문장은 누구나 쓸 수 있지만, 그 문장을 받고 무엇을 보고 됐다고 칠지 정하는 일은 넘길 데가 없습니다.

그래서 제가 정한 답은 결국 세 줄입니다.

1. 보고서 말고 실물을 본다. 화면·파일·날짜·응답. 2. 무엇과 무엇을 맞댈지 미리 문장으로 적는다. "확인해라"는 지시가 아니다. 3. 세는 건 프로그램에 맡기고, 짐작은 짐작이라고 화면에 적는다.

그리고 마지막 한 줄. 틀린 걸 센다. 세지 않으면 "좋아진 것 같습니다"밖에 못 말하고, 그 문장은 우리가 잡으려던 바로 그 문장이니까요.

다음 편이 이 연재의 마지막입니다. 여기까지 오면서 사람이 붙잡아야 했던 자리들을 한자리에 놓고, 결국 사람은 어디에 남는가를 정리해 보려고 합니다.

#AI개발 #클로드 #ClaudeCode #휴먼인더루프 #AI에이전트 #에이전트관제 #사고원장 #오류기록 #검증 #품질관리 #AI검증 #AI환각 #할루시네이션 #서치콘솔 #색인요청 #구글색인 #자동화 #업무자동화 #위임 #재작업 #비개발자개발 #바이브코딩 #개인개발 #사이드프로젝트 #홈페이지제작 #victorhouse #개발일지 #연재 #회고 #AI와사이트만들기