「통과」라는 두 글자가 감추는 것 — 개발기 ⑲ 고장은 죽었는데, 죽인 건 제 검사가 아니었습니다

제 자동 발행 기록 하나에 이런 문장이 남아 있습니다. “산출물이 0인데 종료코드가 0이라 실패가 안 보입니다.”

그런데 그 문장을 적은 작업이 글을 한 편도 못 내놓고 끝났습니다. 마지막 줄엔 정상 종료라고 찍혔고요.

여러분도 초록불 하나를 보고 그냥 넘어간 적이 있으실 텐데요, 제 경우엔 그 기록이 하필 오늘 이 글을 쓰라고 적어 둔 기록이었습니다. 자기가 진단한 병에 자기가 걸린 채 초록으로 남은 겁니다.

개발기 ⑮에서는 검사가 재려던 것에 손도 안 댄 이야기를, ⑱에서는 기록은 예쁜데 도착을 아무도 안 센 이야기를 했습니다. 오늘은 그다음 칸입니다. 심어 둔 고장은 진짜로 죽었고, 바깥에서 집계하는 자가 화면에 “잡았다”까지 찍었어요. 그런데 죽인 건 제가 물으려던 검사가 아니라 엉뚱하게 난 오류였습니다. 죽은 것은 맞는데 죽인 자가 딴 자였고, 집계하는 자가 그걸 성공으로 적은 겁니다.

세 번 다 화면은 똑같이 초록이었습니다. 그래서 세 번 다 저는 다음 일로 넘어갔죠. 무엇이 달랐는지는 한참 뒤에 하나씩 뜯어보고서야 알았습니다.

고장은 분명히 죽었는데, 왜 제가 물으려던 검사는 한 줄도 안 돌았을까요

여기서 등장하는 자가 셋인데, 그동안 저는 셋을 다 “검사”라는 한 낱말로 불렀습니다. 오늘은 이름을 따로 붙이겠습니다. 바깥에서 집계하는 자(코드를 오려 실행하고 결과를 화면에 적는 쪽), 제가 물으려던 검사(이 고장을 잡으라고 만들어 둔 두 개), 그리고 엉뚱하게 난 오류입니다.

집계하는 자가 코드를 오려 보는 기준을 “띄어쓰기 여덟 칸”으로 못박아 뒀기 때문입니다.

봇이 제대로 작동하는지 보려고 저는 코드에 일부러 고장을 심습니다. 검사가 그걸 잡으면 검사가 살아 있는 거고, 못 잡으면 그 검사는 이름만 검사인 셈이죠.

그날 심은 고장 하나가 화면에 “잡힘”으로 찍혔습니다. 기록에는 그 뒤가 이렇게 적혀 있어요. 실제로 뻗은 이유는 전혀 다른 오류였고, 이 고장을 잡으라고 만들어 둔 검사 두 개는 한 번도 실행되지 않았다.

집계하는 자는 코드 뭉치에서 필요한 구간만 오려 내서 봅니다. 그 끝나는 자리를 “여덟 칸 들여쓴 줄”로 지정해 뒀는데, 제가 심은 고장이 그 뭉치를 한 겹 안쪽으로 밀어 열두 칸이 됐어요.

끝 표시가 사라진 겁니다. 집계하는 자는 뒤쪽 코드까지 통째로 삼킨 조각을 들고 실행하다가, 있지도 않은 이름을 부르며 넘어졌습니다. 이게 엉뚱하게 난 오류예요.

고장이 죽인 게 아니라 집계하는 자가 스스로 넘어진 거죠. 그런데 집계하는 자에게는 이 둘이 똑같이 생겼습니다. 죽었다는 사실만 세고 있었으니까요.

여기서 제일 아픈 대목은 “잘못 찍혔다”가 아닙니다. 그 표시를 보고 저는 그 자리를 다 봤다고 여기고 지나갔다는 점입니다. 그날 이후로 그 자리에 진짜 구멍이 생겼어도 저는 몰랐을 겁니다.

그럼 화면에 무엇을 한 줄 더 적어야 “죽었다”와 “제가 죽였다”가 갈릴까요.

“죽었다”와 “제가 죽였다”는 왜 다른 말일까요

죽인 사유를 안 적으면 화면에서 그 둘이 구별되지 않기 때문입니다.

비유하자면 이렇습니다. 화재경보기를 시험하려고 성냥을 켰는데, 마침 옆에서 주전자가 끓어 김이 올라와 경보가 울린 겁니다. 소리는 났으니 시험은 통과예요. 그런데 그 경보기가 연기를 감지할 수 있는지는 여전히 아무도 모릅니다.

그래서 처방은 단순했습니다. 죽었는지만 세지 말고 죽인 쪽의 이름까지 함께 찍고, 설계할 때 “이건 이 검사가 잡을 것”이라고 적어 둔 이름과 맞춰 보는 것.

기록에 남은 다른 사례가 이걸 더 잘 보여 줍니다. 원래 빨간 곳이 하나라도 있는 채로 고장을 심으면, 아무것도 안 바꾼 고장까지 전부 “잡혔다”로 뜹니다. 열여섯 번 중 열네 번이 그 상태였다고 적혀 있어요. 잡은 게 아니라 원래 있던 실패가 대신 대답한 겁니다.

물론 이렇게 반문하실 수 있습니다. 어차피 고장은 죽었으니 결과는 맞은 것 아니냐고요. 저도 한동안 그렇게 생각했습니다. 다만 결과가 맞은 이유를 모르면, 그 이유가 사라지는 날도 알 수 없습니다. 여기서는 들여쓰기 한 겹만 바뀌어도 사라졌습니다.

이렇게 이름을 맞춰 보는 검사도 못 보는 자리가 있습니다. 애초에 글자만 보고 넘어가는 검사예요.

글자가 있나만 보는 검사는 무엇을 못 볼까요

부호와 순서와 경계, 그러니까 판단이 실제로 갈리는 자리 전부입니다.

기록에 이렇게 생긴 검사가 있었습니다. 코드 안에 특정 낱말이 적혀 있는지만 확인하고, 정작 비교는 검사가 자기 손으로 다시 계산했어요. 그래서 순서를 정하는 기준의 방향은 아무도 안 봤습니다.

방향을 정반대로 뒤집은 고장을 심었는데도 검사는 전부 통과했다고 적혀 있습니다. 바뀌면 안 되는 값을 두 배로 키운 것도 마찬가지였습니다.

기록에 이런 문장이 있어요. “정적 검사는 쓰기 쉽고 빠르며 검사를 했다는 느낌을 준다. 그러나 문자열 존재는 계약의 아주 얕은 그림자다.” 풀어 쓰면 이렇습니다. 계약서에 그 낱말이 적혀 있다는 것과 그 조항이 지켜진다는 것은 서로 다른 사실입니다.

이런 검사가 특히 위험한 이유는 개수가 많아지기 때문입니다. 쓰기 쉬우니까 자꾸 늘어나고, 늘어난 만큼 화면의 초록불도 늘어나요. 검사 수가 늘었는데 볼 수 있는 종류는 그대로인 상태가 됩니다.

제가 블로그 쪽에서 새로 만든 검사기도 딱 이 계열이었습니다.

그럼 제 블로그 쪽 기록은 왜 초록이었을까요

제가 낸 시험 문제가 제 코드를 그대로 베낀 것이었기 때문입니다.

맨 앞에서 말씀드린 자동 작업 셋이 연달아 빈손으로 끝났는데, 세 기록의 마지막 줄이 전부 정상 종료였습니다. 원인은 그 작업들이 파일을 쓰거나 도구를 돌릴 권한 없이 불려서, 하는 일마다 거절당한 것이었어요.

빈손이 셋 연달아 나왔는데도 그 작업들 자신은 끝까지 초록이었습니다. 각 작업이 마지막에 남기는 값이 “정상” 하나뿐이었거든요. 일을 했는지가 아니라 끝까지 갔는지만 적는 자리였던 겁니다.

나흘 사이에 세 슬롯입니다. 빨간불이 아예 없진 않았어요. 매일 도는 다른 점검표가 “예정된 시각이 지났는데 새 글이 없다”고 나흘 내내 적고 있었거든요. 그런데 그건 다른 화면이었고, 정작 일을 한 작업 자신은 끝까지 초록이었습니다. 저는 초록인 쪽을 보고 있었고요.

그래서 그 거절을 찾아내는 검사기를 새로 만들었습니다. 그런데 제가 코드에 적어 둔 말은 “승인 필요”였고, 실제 기록에 찍히는 말은 “승인이 필요합니다”였습니다. 「승인」 바로 뒤에 「이」 한 글자가 끼어 있었을 뿐인데, 제 검사는 그걸 못 넘었습니다. ⑱에서 겪은 것과 같은 자리인데, 오늘 진짜 문제는 그게 아닙니다.

제 시험이 그 어긋남을 구조상 못 잡았습니다. 시험에 넣을 예시를 제가 지어냈는데, 그 예시의 말투를 제 코드에 적은 낱말 그대로 썼거든요. 문제와 답을 같은 사람이 같은 낱말로 적었으니 만점이 나올 수밖에요.

그래서 쌓여 있던 기록 파일 322개를 옛 문구와 넓힌 문구로 각각 한 번씩 훑어 봤습니다.

숫자만 보면 세 개가 여섯 개로 늘어난 것이지만, 뜻은 그게 아닙니다. 못 보고 지나간 절반은 그동안 조용히 정상으로 쌓여 있었어요.

그런데 여기서 하나 더 실토할 게 있습니다. 거짓 경보를 줄이려고 “없이·없음”이 든 줄은 빼도록 해 뒀는데, 새로 찾은 셋 중 둘이 하필 그 말투였어요. 그래서 지금 돌고 있는 검사기가 실제로 잡는 건 여섯이 아니라 넷입니다. 오탐을 막으려던 장치가 진짜 사고 둘을 같이 지운 거죠. 이건 아직 안 고쳤습니다.

고친 방법은 예시를 지어내지 않는 것이었습니다. 실제 사고 기록 파일을 그대로 넣어서 재고, 그 파일을 못 찾으면 통과가 아니라 “못 쟀다”로 적게 했습니다. ⑱에서 원칙으로 적어 둔 걸 이번엔 형식으로 박은 셈이에요.

여러분이 받은 “통과”에는 무엇이 적혀 있나요

여기까지가 봇 이야기인데, 이 모양은 우리가 받는 통보에도 그대로 있습니다.

서류를 내고 “이상 없이 처리됐습니다”라는 답을 받으면 우리는 그 문장을 결과로 읽죠. 그런데 그 문장은 무엇을 봤는지는 알려 주지 않습니다. 통과했다는 사실과, 내가 궁금해한 그 칸을 누군가 봤다는 사실은 서로 다른 이야기거든요.

봇에서 제가 겪은 것도 정확히 그 자리였습니다. 화면은 “잡혔다”까지만 알려 주고 누가 잡았는지는 안 알려 줬어요. 그 한 칸이 비어 있는 동안 저는 다 확인했다고 믿었죠.

오해하지 마세요. 통보를 의심하라는 이야기가 아닙니다. 다만 통과의 이유가 함께 적혀 있지 않으면, 나중에 무엇이 흔들렸을 때 어디를 다시 봐야 하는지 알 수 없다는 것뿐입니다.

이게 왜 돈 이야기가 되냐면 이렇게 이어집니다. 근거가 안 적힌 통과는 나중에 조건이 달라졌을 때 무엇이 바뀌어서 달라졌는지를 되짚을 수가 없어요. 나중에 따져 물을 때 들이밀 자료가 남지 않죠.

오늘 딱 하나만 해 보신다면 이걸 권합니다. 최근에 받은 「이상 없음」 하나를 골라, 그게 통과된 이유가 무엇이었는지 한 줄로 적어 보세요. 무엇을 봤는지가 아니라, 왜 통과였는지요.

오늘 제가 아직 못 잰 것

이 글은 “다 고쳤습니다”로 닫지 않겠습니다.

권한 문제는 손으로 돌려서 통하는 걸 확인했습니다. 그런데 정해진 시각에 저절로 깨어나 글이 실제로 나가는 것은 아직 못 봤어요. 그걸 보기 전까지 지금 상태는 “고쳐졌다”가 아니라 “손으로는 됐다”입니다.

이 글 자체도 그렇습니다. 원래는 자동 슬롯이 써서 내보냈어야 할 자리인데, 오늘도 제 손으로 썼습니다.

봇 쪽 사례들도 그렇습니다. 지금 제 손에 있는 건 개발 기록에 적힌 값이고, 그 실행을 제가 다시 돌려 본 건 아닙니다.

그리고 시험에 실제 기록을 넣도록 바꿨지만, 다음 사고가 제가 적어 본 적 없는 말투로 올 가능성은 그대로 남아 있습니다. 그때 제 시험은 또 만점일 수 있고요.

기록에 있던 한 문장으로 닫겠습니다. “검사가 초록이다”와 “재려던 것을 쟀다”는 다른 사건이다. 초록불 자체가 거짓말을 한 건 아니에요. 오늘 하나는 확실히 얻었습니다. 이제 그 옆에 왜 초록인지를 적는 칸이 생겼거든요. 그 칸이 비어 있으면 다음 사람은 초록을 자기 질문의 답으로 읽습니다. 저는 그걸 세 번 겪었습니다.

※ 이 글은 자동매매 시스템과 블로그 자동화를 만들며 겪은 과정을 기록한 개발기입니다. 특정 종목이나 매매 방법을 권유하지 않으며, 본문에서 인용한 봇 쪽 사례는 개발 기록에 적힌 값을 옮긴 것입니다. 각종 심사·접수 통보의 기준과 절차는 기관과 상품에 따라 다르므로 개별 사안은 해당 기관에 확인하셔야 합니다. 투자 판단과 그 책임은 본인에게 있습니다. 2026.09 기준 정보·교육·참고용으로만 봐 주세요.