원인을 짐작으로 정하면 공사비가 샙니다 — 개발기 23 오류 29건의 시각을 맞추고 공사를 멈췄습니다

2026년 9월 23일 저녁, 제 맥 화면에 같은 경고 창이 계속 떴습니다.

「응용 프로그램이 예기치 않게 종료되었습니다.」 20시 39분부터 22시 57분까지, 두 시간 남짓 동안 충돌 보고서가 29건 남았죠.

그런데 처음 세운 원인은 기록과 맞지 않았습니다. 그 원인대로라면 새 런처를 만들고 검사 경로 여러 곳을 고치는 공사를 해야 했거든요. 여러분이 카드값이 불어난 달을 “요즘 많이 써서”라고 정리해 본 적 있다면, 오늘 글은 그 짐작이 공사비를 새게 만드는 자리 이야기입니다.

3초에 6건 몰리면, 누구라도 ‘한꺼번에’를 떠올립니다

죽은 프로그램은 테스트용 크롬이었습니다. 제가 만드는 짧은 영상은 화면이 제대로 나오는지 자동으로 찍어 보는 검사를 여러 번 거치는데, 그때 쓰는 전용 인터넷 창입니다.

검사 스크립트마다 이 창을 새로 띄웁니다. 그런 스크립트가 10개가 넘었습니다.

오류 기록을 먼저 읽은 건 제 주식 봇 쪽을 맡은 AI였습니다. 그 AI가 짚은 대목은 이랬습니다. 21시 34분 24초부터 27초 사이, 3초 안에 6건.

진단은 자연스러웠습니다. 창을 한꺼번에 여럿 띄우니 맥이 버티지 못한다는 판단이었습니다. 닫히지 않고 남은 창도 있었습니다. 20시 39분에 뜬 창 하나가 두 시간 넘게 살아 있었거든요.

그럼 이제 무엇을 지으면 될까요.

도면은 커졌고, 검토를 거치니 더 커졌습니다

설계를 맡은 AI가 그린 도면은 이랬습니다. 크롬을 띄우는 길을 한 곳으로 모은다. 동시에 두 개까지만 띄우게 줄을 세우고, 끝나면 반드시 닫고, 남은 창은 치우고, 실패하면 한 번 더 띄운다.

쉽게 말하면 이런 겁니다. 주차장 입구가 막힌다니까 차단기와 번호표 기계, 견인차까지 새로 들이는 계획이죠.

이 도면을 코드 검토를 맡긴 다른 AI에게 보였습니다. 돌아온 건 막아야 할 곳 6건이었습니다.

6건 모두 옳은 지적이었습니다. 남은 창을 치울 때 엉뚱한 프로그램을 죽이지 않게 하라, 실패를 조용히 삼키지 마라 같은 것들이었거든요. 첫 코드 검토의 차단 여섯 건은 주로 설계안의 위험을 짚었습니다. 그 사이 도면은 새 런처 둘에 기존 검사 경로 수정까지 더해, 파일 여섯 개짜리 공사로 커졌습니다.

설계를 맡은 AI도 원인은 아직 확인하지 못했다고 적고, 그날 로그를 봐 달라고 요청해 두었습니다.

그럼 땅은 누가 봤을까요.

시계를 맞춰 보니, 29건 모두 제한된 코드 수정 작업 중에 났습니다

이후 도면 검수에서, 공사를 챙기는 역할의 AI가 짓기 전에 한 가지를 했습니다. 오류 보고서 29건을 전부 열어 분 단위 시각을 뽑고, 그 시각에 무엇이 돌고 있었는지를 옆에 적었습니다.

여기서 울타리 안 작업이 무엇인지 풀어야겠습니다. 저는 코드를 고치는 일을 다른 AI에게 맡기는데, 그때 그 AI를 울타리 안에 넣고 돌립니다. 아무 파일이나 건드리지 못하게 가둬 두는 작업장이죠. 이 울타리를 개발자들은 샌드박스라고 부릅니다.

그날 저녁 울타리 안 작업은 여섯 번 돌았습니다. 9월 23일 도면 검수 기록은 충돌 보고서 29건의 시각이 그 여섯 번의 실행 시간과 전부 겹쳤다고 적었습니다.

반대로 울타리 밖에서는요. 사실 확인을 맡은 AI와 공사를 챙기는 AI가 같은 크롬을 수십 번 띄웠는데, 그 시간엔 오류가 한 번도 없었습니다.

바꿔 말하면 3초에 6건이 몰린 이유는 “한꺼번에”보다 그 3초가 울타리 안 작업 시간이었기 때문일 가능성이 더 커 보였습니다. 크롬은 켜질 때 맥에 “나 켜졌다”고 등록하는 첫 단계를 거치는데, 오류가 바로 그 단계에서 났습니다. 울타리가 그 등록을 막은 것으로 보입니다. 다만 울타리의 규칙 자체를 열어 확인하지는 못했어요. 시각이 29건 중 29건 맞았다는 데서 내린 판단이고, 동시 실행의 영향을 따로 떼어 비교한 시험은 아닙니다.

울타리 안 작업자는 매번 보고서에 “크롬 실행 실패”를 적어 두기도 했습니다. 그때 떨어진 화면 검사들은 울타리 밖에서 다시 돌리니 전부 통과했죠. 크롬 충돌은 자리 문제로 보였습니다.

다만 검토 중에 검사가 화면을 읽지 못해도 판정을 이어가던 별도 결함을 발견했고, 그건 다른 작업으로 넘겨 수정했습니다. 그럼 공사는 어디까지 줄어들 수 있었을까요.

파일 6개짜리 공사가 지시문 한 줄로 바뀌었습니다

원인 판단이 바뀌니 처방도 바뀌었습니다. 이 판단이 맞다면 줄 세우기 장치를 지어도 울타리 안 크롬은 똑같이 죽을 테니까요.

남아 있던 것도 정리했습니다. 남아 있던 테스트 크롬 프로세스 3개를 종료하니, 도우미를 포함한 관련 프로세스 수가 19개에서 0개로 줄었습니다.

그리고 확인이 남았죠. 그날 밤, 한 줄을 넣은 채로 다음 코드 수정 작업을 한 번 돌렸습니다. 그 작업이 도는 동안 새 오류 보고서는 0건이었습니다.

처음 그린 공사 도면은 버리지 않고 보류로 넣어 뒀습니다. 울타리 밖에서도 크롬이 죽는 날이 오면, 그날 그 도면을 바닥으로 다시 엽니다.

개발기 21에서는 원인이 아닌 자리를 세 번 고친 뒤에야 멈췄습니다. 이번엔 짓기 전에 멈췄습니다. 차이는 딱 하나, 시계를 먼저 본 것이었어요. 이 시계 보기는 카드 명세서 앞에서도 그대로 통합니다.

카드값이 불어난 달에도 같은 함정이 있습니다

여러분 통장으로 치면 이런 자리입니다.

어느 달 카드값이 평소보다 확 늘었습니다. 명세서를 훑어보면 한 주에 결제가 몰려 있습니다. 그러면 “그 주에 너무 많이 썼구나”로 정리하기 쉽습니다. 3초에 6건을 보고 “한꺼번에”를 떠올린 것과 같은 모양이에요.

그런데 날짜를 하나씩 맞춰 보면 다른 게 보일 때가 있습니다. 1년에 한 번 빠져나가는 결제나, 무료 기간이 끝나고 붙은 정기 결제처럼 날짜에 묶인 돈이 그 주에 겹쳤을 수 있거든요.

“그럼 어차피 아껴 쓰면 되지 않나요?” 물론 아껴 쓰는 건 손해가 아닙니다. 다른 지출을 줄이면 총액은 달라질 수 있지만, 연간 결제나 새 정기 결제가 겹쳤다면 그 결제의 주기와 금액은 따로 확인해야 합니다.

오늘 제가 아직 못 잰 것

이번 편은 잘 끝난 이야기지만, 다 확인됐다고 닫지는 않겠습니다.

울타리가 왜 크롬의 등록을 막는지, 그 규칙은 아직 열어 보지 못했습니다. 동시 실행의 영향도 따로 재지 않았어요. 시각이 29건 맞았다는 것이 지금 가진 근거의 전부예요. 그리고 울타리 밖에서 오류가 한 번도 안 난 것은 그날과 그 뒤 몇 번의 기록일 뿐입니다.

여러분, 지난달 카드 명세서에서 가장 큰 결제 세 건, 며칠에 빠져나갔는지 기억나시나요? 기억이 안 난다면 규칙을 조이기 전에 날짜부터 한 번 맞춰 보시길 권합니다.

이번 크롬 충돌 대응에서는 코드를 고치지 않았습니다. 충돌 보고서 29건의 시각을 옆에 나란히 적은 표 한 장이 전부였어요. 그 한 장 덕분에 파일 6개짜리 공사가 지시문 한 줄로 바뀌었고, 그 뒤 첫 작업에서는 새 오류 보고서가 없었습니다. 원인에 가까이 갈수록 수리는 이렇게 작아집니다.

※ 이 글은 자동매매 시스템과 블로그 자동화를 만들며 겪은 과정을 기록한 개발기입니다. 특정 종목이나 매매 방법을 권유하지 않으며, 본문의 시각·횟수는 작업 기록과 오류 보고서에 적힌 값을 옮긴 것입니다. 카드 결제일·정기 결제 조건은 카드사와 상품마다 다르므로 개별 사안은 해당 기관에 확인하셔야 합니다. 투자 판단과 그 책임은 본인에게 있습니다. 2026.09 기준 정보·교육·참고용으로만 봐 주세요.