새벽세시

알람이 서른다섯 번 울렸고, 진짜 고장은 「정상」으로 적혔습니다

9월 19일 새벽 1시. 폰이 울렸습니다. 급속냉동실이 두 시간째 설정 온도에 못 미친다는 알림이었습니다. 저는 읽고 껐습니다. 같은 알림이 9월 들어서만 스무 번 넘게 왔고, 아침이면 대개 정상으로 돌아와 있었습니다.

그 새벽은 아니었습니다. 아홉 시간 반 뒤 그 방은 영하 0.1도였습니다. 설정은 영하 30도입니다.

스물닷새 동안 점검 2,983번, 알람 35통

8월 28일부터 9월 22일까지 온도 감시는 2,983번 돌았고 알람을 서른다섯 통 보냈습니다. 하루 한 통보다 잦습니다.

서른다섯 통이 서른다섯 건은 아니었습니다. 사건으로 묶으면 열네 건이고, 그중 두 건이 스무 통을 만들었습니다. 나머지 열두 건이 열다섯 통입니다.

9월 15일이 그 두 건 중 하나입니다. 성에 제거 운전이 학습된 시간보다 길어졌다는 알람이 14시 20분부터 20시 20분까지 일곱 통 갔습니다. 방이 잠깐 차가워지면 알람이 풀리고, 조금 뒤 다시 걸렸습니다. 한 사이클이 일곱 통이 됐습니다.

열한 통은 한 시간 안에 저절로 꺼졌습니다

서른다섯 통 중 열한 통은 한 시간 안에 스스로 정상으로 돌아왔습니다. 손댄 사람은 없습니다. 그중 일곱 통이 9월 15일 그 제상입니다.

헛울림을 줄이려고 그 사이 규칙을 네 번 고쳤습니다. 9월 8일에 온도가 내려가는 중이면 알람을 보류하게 했고, 9월 9일에 온도가 정체하면 그 보류를 거부하는 규칙을 덧댔습니다. 9월 14일에 데이터 두절을 15분 만에 알리게 했고, 9월 15일에 업무 중 제상은 기준을 늦췄습니다.

9월 14일 저녁에 온 세 통은 이유가 달랐습니다. 온도가 아니라 데이터가 끊겼습니다. 16시 57분을 끝으로 기록이 멈췄고, 다시 들어온 것은 다음 날 8시 35분입니다. 열다섯 시간 반 동안 감시는 아무것도 못 봤고, 그 세 통은 그 사실만 알렸습니다.

알람은 그래도 하루 한 통씩 왔습니다. 제 손에 남은 습관은 화면을 보고 끄는 것이었습니다.

9월 18일 17시 25분

두 번째 사건의 첫 알람이 온 시각입니다. 급속냉동실 영하 15.2도, 다섯 시간 동안 설정 대역에 한 번도 못 들어갔다는 내용이었습니다.

그날 저녁 업무 기록에는 이렇게 남았습니다. "급속냉동실 온도 상승 점검 완료 — 대량 입고와 청소로 인한 일시적 정상 현상으로 확인."

온도는 계속 올랐습니다. 19일 1시에 영하 9.2도, 4시에 영하 7.1도, 10시 30분에 영하 0.1도. 설정 대역으로 돌아온 것은 20일 5시 50분, 첫 알람에서 서른여섯 시간 뒤입니다. 이 한 건으로 알람이 열세 통 갔습니다.

원인은 21일에 나왔습니다. 천장 배관 용접부에 미세 누수가 있었습니다. 냉매가 새고 있었고, 수리하고 보충하고 나서야 온도가 잡혔습니다. 입고도 청소도 아니었습니다.

배운 것

하나. 헛울린 알람은 불편이 아니라 판단을 바꿉니다. 스물닷새 동안 "괜찮았던 알람"을 서른네 번 배운 사람은 서른다섯 번째를 볼 때 이미 결론을 갖고 봅니다. 그 결론이 업무 기록에 「정상」으로 적혔습니다.

둘. 서른다섯 통이 오는 동안 사건은 열네 건이었습니다. 서른다섯과 열넷은 다른 숫자입니다. 제상 한 사이클이 일곱 통을 보내는 동안 이틀짜리 진짜 고장은 열세 통이었습니다. 받는 화면에서는 둘이 같아 보입니다.

다음에 고칠 것은 알림의 등급입니다. 한 시간 안에 스스로 돌아오는 상태는 깨우지 않고 아침에 묶어서, 세 시간 넘게 못 돌아오는 상태는 사람을 깨우는 쪽으로.

다음 글은 알림 전체를 세어 본 이야기입니다. 열나흘 동안 650통이 왔고, 그중 제가 실제로 손을 댄 것이 몇 통인지 세어 봤습니다.

이 글의 날짜와 온도는 감시 기록과 업무 기록에서 확인했습니다. 화면은 실제 캡처가 아니라 기록을 바탕으로 다시 그린 것입니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/thirty-five-alarms.html?ref=disquiet

아홉 날 동안 열여덟 번, 감시 장치가 멀쩡한 서버를 껐습니다

9월 5일 오후. 폰에서 대화창이 또 끊겼습니다. 안정화하려고 붙인 장치가 오히려 불안정하게 만드는 것 같다는 생각이 들어, 그날 기록을 전수로 뒤졌습니다.

8월 27일부터 9월 5일까지 아홉 날. 폰과 PC를 잇는 중계 서버는 스물한 번 껐다 켜졌습니다. 제가 시킨 건 세 번입니다. 열여덟 번은 감시 장치가 혼자 판단했고, 그중 여섯 번은 멀쩡한 서버를 고장으로 읽은 오판이었습니다.

틀린 신호 위에 예외를 쌓았습니다

감시 장치는 인증 파일이 새로 쓰이면 열쇠가 바뀐 것으로 봤습니다. 열쇠가 바뀐 직후에 통로가 자주 죽으니 미리 껐다 켜자는 논리였습니다.

그 파일은 열쇠가 바뀔 때만 쓰이는 게 아니었습니다. 폰에서 대화창이 하나 뜰 때마다 항목이 하나씩 붙어 다시 쓰였습니다. 쌓인 항목이 309개였습니다. 폰을 많이 쓴 날일수록 감시 장치는 열쇠가 자주 바뀐다고 읽고 더 자주 껐습니다.

사고가 날 때마다 규칙을 하나씩 덧댄 것도 저였습니다. 8월 29일에 억제 규칙, 9월 4일에 판정 마커, 9월 5일에 갱신 즉시 조치, 같은 날 자기갱신 예외. 예외의 예외가 생긴 자리에서 신호가 틀렸다고 봤어야 했습니다.

토요일 낮에 열다섯 번

9월 6일이 가장 나쁜 날입니다. 11시 01분부터 51분까지 10분 간격으로 여섯 번, 15시 32분부터 16시 30분까지 일곱 번. 그날 하루 열다섯 번이고 제가 시킨 건 없습니다.

사유는 "가동 5분 뒤 대화창 0개"였습니다. 서버는 떠 있는데 대화창이 하나도 없으면 창을 못 만드는 상태라고 본 것입니다. 토요일 낮에 제가 폰을 안 잡았을 뿐이었습니다. 아무도 안 쓴 것과 고장 난 것을 이 신호로는 못 가릅니다.

진짜 원인은 숫자 하나였습니다

9월 5일 14시 50분에 원인이 나왔습니다. 중계 서버에는 동시에 살아 있는 대화창 개수에 상한이 있고, 기본값이 32였습니다. 상한에 닿으면 새 창이 안 열립니다. 화면은 그 사실을 알려주지 않고 그냥 옛 창을 보여줍니다.

오래된 창 여덟 개를 정리하자 바로 열렸습니다. 상한을 100으로 올리고, 매일 새벽 4시 반에 하루 넘게 잠든 창을 치우게 했습니다. 아홉 날 동안 스물한 번을 껐다 켰어도 이 증상은 한 번도 안 없어졌습니다.

감시 장치에서 스위치를 뺐습니다

9월 10일 9시에 마지막 오판이 나왔습니다. 시험용으로 띄운 창의 로그에 인증 오류가 한 줄 찍혔다고, 새 창이 죽는 상태라는 알림이 갔습니다. 22분 뒤 제가 직접 연 창은 같은 오류를 두 줄 남기고도 대화를 끝까지 끝냈습니다.

9월 12일에 정했습니다. 감시 장치는 감지하고, 대화창을 실제로 하나 띄워 시험하고, 알리는 데까지만 합니다. 끄고 켜는 건 사람이 폰 버튼으로 합니다.

근거는 관찰 일주일 치입니다. 자동 재기동이 실제 장애를 고친 건 0건, 시험 없이 내린 재기동이 2건, 오판이 3건 이상이었습니다. 맞바꾼 위험은 새벽 장애가 아침까지 방치되는 것이고, 그 값은 버튼 한 번입니다.

바꾸고 사흘 동안 서버는 한 번 껐다 켜졌습니다. 9월 14일 11시 14분, 제가 눌러서.

배운 것

하나. 감시자가 사용자보다 자주 서비스를 끊으면 감시자가 장애입니다. 열여덟 대 세 번이면 셈은 끝난 것이었고, 저는 아홉 날 동안 그 셈을 안 했습니다.

둘. 상태를 바꾸는 자동 조치는 옆 흔적이 아니라 직접 해 본 결과를 근거로 삼습니다. 파일이 쓰인 시각, 프로세스 번호, 응답 코드 200은 힌트입니다. 창이 열리는지 알려면 창을 열어 봐야 합니다.

다음 글은 같은 질문을 사람 쪽에서 본 이야기입니다. 알림이 하루 한 건꼴로 오는데, 다섯에 하나는 한 시간 뒤 저절로 정상으로 돌아와 있었습니다.

이 글의 날짜와 횟수는 감시 기록과 코드 변경 이력에서 확인했습니다. 화면은 실제 캡처가 아니라 기록을 바탕으로 다시 그린 것입니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/eighteen-restarts.html?ref=disquiet

감시 장치가 세 번 거짓말을 했습니다

8월 10일 월요일 아침. 주간 회고가 올라왔습니다. "냉동 창고 온도 감시, 지난주 15건 반복 실패. 모니터링 경로 미반영 의심." 회고는 사람이 아니라 봇이 씁니다. 저는 그대로 믿고 감시 코드를 열었습니다.

열다섯 건은 전부 정상이었습니다. 온도가 기준을 넘어 경고를 보낸 것뿐이었고, 경고를 보낼 때 프로그램은 0이 아닌 숫자로 끝나게 돼 있었습니다. 실패 기록장은 0이 아니면 실패로 적었습니다. 잘 작동한 열다섯 번이 실패 열다섯 건이 됐습니다.

기록장을 만든 이유가 먼저였습니다

그 기록장은 열흘 전에 만든 것이었습니다. 그전까지 감시는 알림 한 번 울리고 사라졌습니다. "이 자동화가 이번 달 몇 번 죽었나"를 볼 방법이 없었고, 실패를 적는 코드는 146개 중 5개에만 있었습니다. 그래서 한 줄씩 쌓는 장부를 만들었는데, 장부가 첫 회고에서 오진을 냈습니다.

고친 건 한 줄입니다. "정상인데 0이 아닌" 코드를 작업마다 등록하고, 그건 실패로 안 적기.

두 번째: 이미 실행 중이라는 거짓말

8월 18일에 자동화 55개가 각자 들고 있던 안전장치를 한 곳으로 모았습니다. 배치 파일 35개에 손으로 배선하다 보니 빠뜨리는 게 생겨서였습니다. 같은 작업이 두 번 돌지 않게 잠금도 넣었습니다.

닷새 뒤, 한 작업이 17시간 동안 "이미 실행 중"이라며 건너뛰었습니다. 실행 중인 게 없었습니다. 죽은 프로세스의 번호를 다른 프로그램이 물려받았고, 잠금은 번호만 보고 살아 있다고 판단했습니다. 번호에 이름과 시작 시각을 붙였습니다.

세 번째: 성공률 100%

이 얘기는 첫 글에 썼습니다. 좌석 감시가 한 번도 좌석을 못 잡아도 장부는 전부 성공입니다. 종료 코드는 "돌았다"만 말하지 "뭘 남겼다"는 말하지 않습니다. 작업마다 "이게 돌면 이 파일이 생겨야 한다"를 적어 두고, 회고가 그걸 대조하게 했습니다.

그리고 고치는 장치가 못 고쳤습니다

8월 말에 실패 62건을 다시 봤습니다. 상위는 전부 감시·조회형이었고 원인은 대부분 로그인 만료나 일시 장애처럼 다시 돌리면 되는 것들이었습니다. 그런데도 아침마다 사람이 알림을 보고 손으로 다시 돌리고 있었습니다. 15분마다 실패한 작업을 다시 돌리고, 안 되면 진단하고, 코드가 원인이면 고쳐서 검증까지 하는 층을 붙였습니다.

9월 5일에 보니 재실행이 아홉 개 작업에서 하나도 안 되고 있었습니다. 스케줄러가 저장해 둔 실행 경로에 따옴표가 두 겹으로 들어가 있었습니다. 복구 장치가 조용히 실패하고 있었고, 그걸 잡은 건 복구 장치의 장부였습니다.

배운 것

하나. 감시 장치도 자동화입니다. 그러니 감시 장치도 조용히 고장 납니다. 기록장이 오진하고, 잠금이 오판하고, 복구가 못 돌았습니다. 각각 한 번씩, 전부 만든 지 열흘 안에.

둘. 장치는 장치를 감시해야 합니다. 기록장의 오진은 회고가 잡았고, 잠금의 오판은 기록장이 잡았고, 복구의 실패는 복구의 장부가 잡았습니다. 하나만 있었으면 셋 다 못 잡았습니다.

다음 글은 반대 경우입니다. 감시 장치가 너무 부지런해서, 멀쩡한 걸 아홉 날 동안 열여덟 번 껐다 켠 이야기입니다.

이 글의 날짜와 건수는 실행 기록과 코드 변경 이력에서 확인했습니다. 화면은 실제 캡처가 아니라 기록을 바탕으로 다시 그린 것입니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/silent-guards.html?ref=disquiet

봇 하나에 회사를 다 넣었더니, 냉동 창고 온도가 돌아왔습니다

7월 22일 낮 12시 14분. 폰으로 봇에게 냉장 제품 주문량을 물었고 답을 받았습니다. 이어서 "냉동은 어느 정도 써?"라고 짧게 물었습니다. 돌아온 답은 냉동창고 온도였습니다. 영하 20도 안팎, 이상 없음.

틀린 답은 아닙니다. 물은 게 아니었을 뿐입니다.

여섯 번째 대화에서 기억이 지워졌습니다

봇은 속도를 위해 여섯 번 대화할 때마다 기억을 비우게 돼 있었습니다. 주문량 답이 여섯 번째였고, "냉동은?"이 일곱 번째였습니다. 새 기억으로 시작한 봇에게 남은 단어는 "냉동" 하나였고, 회사 규칙집에서 그 단어가 걸리는 항목은 창고 온도였습니다. 사람이면 "아까 그 얘기"로 알아듣는 걸, 기계는 문맥이 0이면 규칙집을 뒤집니다.

이틀에 걸쳐 넷을 고쳤습니다. 기억 비우는 주기를 여섯에서 열로. 비울 때 직전 문답 한 쌍은 남기기. 사진만 먼저 오면 30초 기다렸다가 뒤따르는 질문과 묶기. 주제가 바뀐 질문은 새 서랍으로 자동 분리하기.

그런데 진짜 원인은 방이 하나였다는 것

고치고 나서 보니 봇 하나에 서랍이 열아홉 개였습니다. 회사 매출, 창고 온도, 수입 서류, 그리고 제 항공권 마일리지까지 한 방에 있었습니다. 어느 서랍을 열지 맞히는 정확도가 떨어질 수밖에 없었습니다.

7월 31일에 봇을 둘로 나눴습니다. 회사 일 하나, 개인 일 하나. 나누는 데 든 건 개인 업무 스크립트 열세 개 맨 위에 "알림은 개인 봇으로"라는 한 줄을 넣은 것이 전부였습니다.

더 잘게 나누자는 안은 그날 기각했습니다. 매출은 재무인지 판매인지, 경계가 겹치는 순간 "어느 봇에 말하지"가 새 비용이 됩니다.

세 번째 봇, 그리고 27분

8월 18일에 세 번째를 붙였습니다. 이번엔 업무가 아니라 성격으로 나눴습니다. 굴리는 일과 만드는 일. 새 자동화를 만드는 대화는 길고 실험적이라, 운영 봇의 짧은 명령들과 섞이면 서로를 밀어냅니다. 이 경계는 겹치지 않습니다.

같은 날 사고가 났습니다. 봇을 재시작하라고 시켰는데, 그 명령이 한 봇의 자식 프로세스로 실행되면서 새로 뜬 것도 그 봇의 일꾼이 됐습니다. 그 봇은 멀쩡히 답했고, 나머지 둘은 27분 동안 조용했습니다. 하나였을 때는 "다 죽었다"가 전부였는데, 셋이 되니 "일부만 죽었는데 모른다"가 생겼습니다.

재시작 명령이 부모의 환경을 물려받지 않게 고쳤고, 기동 확인에 "일꾼 셋이 다 살아 있나"를 넣었습니다.

2월에 못 넘긴 그 등록 업무

지난 글에서 미뤄 둔 이야기입니다. 파일은 만드는데 화면에 올리지 못하던 매주 할인 행사 등록은 지금 사람 손 없이 돕니다. 다만 완전히 맡기진 않았습니다. 7월 말에 한 줄을 더 넣었습니다. 할인 폭이 정해진 선을 넘는 건이 있으면 등록 전에 멈추고 저에게 묻습니다. 틀리면 돈이 나가는 자리라, 멈추는 지점 하나는 남겨 뒀습니다.

배운 것

하나. 봇을 나누는 기준은 업무가 아니라 경계입니다. 경계가 겹치면 사람이 판단 비용을 냅니다. 겹치지 않는 경계(회사와 개인, 굴리기와 만들기)만 나눴습니다.

둘. 나누면 고장의 모양이 바뀝니다. 전부 멈추는 고장은 눈에 띕니다. 일부만 멈추는 고장은 안 띕니다. 나눈 날 감시도 같이 나눠야 합니다.

다음 글은 그 "안 띄는 고장"을 잡으려고 만든 장치들, 실패 원장과 작업 러너와 워치독 이야기입니다.

이 글의 시각과 날짜는 봇 로그와 코드 변경 기록에서 확인했습니다. 화면은 실제 캡처가 아니라 로그를 바탕으로 다시 그린 것입니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/three-bots.html?ref=disquiet

AI를 세 개 돌려봤는데, 남은 건 제일 똑똑한 것이 아니었습니다

지난 글은 2월 25일에 폴더를 정리하고 끝났습니다. 열여드레 동안 일곱 번 방법을 바꾸고도 마지막 한 칸을 못 넘긴 이야기였습니다. 그 뒤 석 달 동안 저는 도구를 세 번 바꿨습니다. 정확히는 두 번 갈아탔고, 한 번은 십 분 만에 접었습니다.

이번에 그 석 달의 기록을 다시 열어보니, 제가 기억하던 "성능 좋은 걸로 갈아탔다"는 말이 틀려 있었습니다. 마지막에 남은 기준은 성능이 아니었습니다.

3월 4일, 한 시간 만에 옮겼습니다

폴더 정리 일주일 뒤, 커뮤니티에서 배포하는 작은 도구를 받았습니다. 코딩용 AI 에이전트를 메신저에 연결해 주는 것이었는데, 압축을 풀고 봇 토큰을 넣으니 점심 전에 첫 대화 스레드가 생겼습니다. 기록상 11시 51분입니다.

전 도구와 다른 점은 하나였습니다. 답이 아니라 행동이 돌아왔습니다. 파일을 읽고, 고치고, 결과를 보고했습니다. 열여드레 동안 안 되던 "마지막 한 칸"이 어떻게 됐는지는 뒤에 나옵니다. 일단 그날은 옮기는 데 한 시간이 안 걸렸다는 것만 적어 둡니다.

닷새 뒤, 십 분짜리 시도

3월 9일 저녁 6시 56분에 이전 도구의 작업 폴더를 통째로 압축했습니다. 백업 파일 이름에 그 시각이 박혀 있습니다. 그리고 7시 1분에 다른 회사의 코딩 에이전트를 설치했습니다.

설치 폴더에 남은 대화 기록은 한 건입니다. 제가 보낸 말은 "hello" 한 마디. 7시 10분에 마지막 파일이 저장됐고, 그 폴더는 오늘까지 한 번도 다시 열리지 않았습니다. 십 분입니다. 같은 날 그 에이전트용 메신저 연결 도구도 내려받았는데, 압축을 푼 흔적만 있고 봇은 만들지 않았습니다.

왜 십 분 만에 접었는지는 기록이 없습니다. 기억으로 메우자면, 첫 도구가 이미 돌고 있는데 두 번째를 같은 자리에 세울 이유를 못 찾았던 것 같습니다. 그때는 "비교"라는 생각 자체가 없었습니다.

봄 내내 둘을 같이 썼습니다

접은 건 세 번째 후보였고, 실제로는 봄 내내 두 개를 같이 썼습니다. 새로 온 코딩 에이전트와, 그 전부터 쓰던 대화형 AI입니다.

역할이 자연스럽게 갈렸습니다. 대화형 쪽은 3월 7일부터 매일 아침 제 메일로 전날의 통화와 메시지를 정리해 보내는 일을 맡았습니다. 이건 지금도 같은 엔진으로 돌고 있습니다. 코딩 에이전트 쪽은 서류를 데이터로 바꾸는 일, 표를 분석하는 일, 그리고 3월 22일 기록에 이렇게 적혀 있습니다 — "기획과 구조 설계는 이쪽을 선호. 데이터 분석과 기초 작업은 이쪽이 우수."

4월 22일에 제가 커뮤니티에 남긴 말이 있습니다. "이쪽만 쓰고 있었는데 저쪽도 고민해 봐야 할 정도로 잘 뽑네요." 엿새 뒤에는 이렇게 썼습니다. "비교해서 돌려 보면 같은 프롬프트여도 나랑 잘 맞는 게 나와요." 성능표를 본 게 아니라 같은 일을 시켜 보고 고른 겁니다. 그 방식은 지금도 안 바뀌었습니다.

4월 12일, 남의 도구 위에 내 것을 얹었습니다

받은 도구를 그대로 쓰는 데는 한 달을 못 갔습니다. 4월 12일에 제 폴더를 새로 팠습니다. 설치 스크립트, 상태 점검 스크립트, 켜고 끄는 조작판. 그리고 나흘 뒤에 2월의 실패한 폴더에서 살릴 것만 골라 옮겼습니다. 판매 채널 스크립트 아홉 개와 업무 지식. 성격 파일과 영혼 파일은 안 가져왔습니다.

이 시점부터 "도구"라는 말이 조금 달라졌습니다. 엔진은 남의 것인데 그 위에 쌓이는 지침 파일과 스크립트는 제 것이었습니다. 이게 뒤에 결정을 가르게 됩니다.

6월 초, 진짜 병행

5월 중순에 커뮤니티 도구가 큰 업데이트를 했습니다. 두 회사의 에이전트를 봇 하나씩에 붙여 동시에 돌릴 수 있게 됐고, 리눅스 호환 계층 위에서 돌아갔습니다. 저는 5월 29일에 "이쪽을 메인으로 쓴다"고 써 놓고도 그걸 받았습니다. 궁금했던 것 같습니다.

6월 1일 밤 설치가 실패했습니다. 종료 코드 125. 저는 그 설치 폴더를 이미 쓰고 있던 코딩 에이전트에 물려서 "왜 안 되는지 찾아 달라"고 했고, 원인 보고를 커뮤니티에 올린 뒤 잤습니다. 다음 날 설치가 됐습니다. 봇 두 개를 만들어 하나에는 이쪽 엔진, 하나에는 저쪽 엔진을 붙였습니다. 6월 2일 기록에 두 봇의 첫 스레드가 나란히 있습니다.

그 뒤 닷새는 이렇습니다. 6월 3일 업데이트가 연결 오류를 내서 이전 버전으로 되돌림, 호환 계층 안의 로그인 세션이 자꾸 풀림. 6월 4일 응답 지연으로 원격 점검. 같은 날 커뮤니티에 예순 개 작업으로 잰 엔진 벤치마크 표가 올라왔습니다. 저는 그 표를 봤지만 결정에는 안 썼습니다.

6월 5일에 제가 남긴 말이 이렇습니다.

프롬프트가 절반인 것 같아요.
나한테 필요한 md 파일을 구축하는 데 시간이 제일 많이 소비됩니다.
유튜브에서 떠드는 것처럼 자동으로 되는 건 없더라고요.

열흘 만에 하나로

6월 10일, 봇 하나가 제 폴더 쪽으로 옮겨 왔습니다. 커뮤니티 도구 아래에 있던 봇 번호가 그날부터 제 저장소 아래에서 첫 작업(매일 리포트 유지)을 시작합니다. 커뮤니티 도구 쪽의 마지막 작업 스레드는 6월 16일이고, 그 뒤로는 업데이트 알림만 쌓였습니다. 같은 날 커뮤니티에 이렇게 썼습니다. "저는 윈도우에서 코딩 에이전트를 써서 자동화를 세팅하고." 도구는 리눅스 계층 위에서 돌았고, 제 자동화는 윈도우 창과 프로그램을 직접 눌러야 했습니다.

그러니까 수렴은 이랬습니다. 벤치마크에서 이긴 쪽이 남은 게 아니라, 제가 고칠 수 있는 쪽이 남았습니다. 설치가 죽었을 때 원인을 찾아 준 건 이미 돌고 있던 그 에이전트였고, 제 지침 파일이 쌓여 있는 곳도 거기였고, 제 업무가 실제로 일어나는 윈도우 화면에 손이 닿는 것도 거기였습니다. 병행 열흘 동안 저는 봇 두 개, 로그인 두 벌, 되돌리기 한 번을 관리했고, 그 비용이 두 번째 엔진이 주는 차이보다 컸습니다.

남은 것 세 가지

하나. 비교는 표가 아니라 같은 일로 합니다. 3월에도 4월에도 6월에도, 결정은 "같은 걸 시켜 보니 이쪽이 나랑 맞다"에서 났습니다. 벤치마크는 봤고, 참고했고, 쓰지 않았습니다. 지금도 새 모델이 나오면 제 업무 하나를 똑같이 시켜 보고 판단합니다.

둘. 엔진은 갈아타도 지침 파일은 남습니다. 지난 글에서 성격 파일 서른일곱 줄을 쓰고 기억 규칙은 안 만들었다고 했습니다. 이번 석 달의 결론은 그 반대편입니다. 4월 12일 이후 쌓인 지침과 스크립트가 있었기 때문에 6월의 병행이 "이사"가 아니라 "엔진 교체 검토"로 끝났습니다. 엔진에 붙어 있는 자산은 엔진과 함께 사라지고, 파일에 있는 자산은 남습니다.

셋. 병행에는 값이 있습니다. 두 개를 돌리면 비교가 되는 대신 관리가 두 배가 됩니다. 저는 열흘을 썼고, 그 정도가 답을 얻는 데 필요한 값이었습니다. 다만 한 달을 넘겼다면 비교가 아니라 습관이 됐을 겁니다.

그리고 2월에 못 넘긴 "마지막 한 칸" — 파일을 만들어 놓고 화면에 올리지 못했던 그 등록 업무는 이 병행이 끝난 뒤에야 다시 돌기 시작했습니다. 그 얘기는 봇을 세 대로 나눈 이야기와 함께 다음 글에 씁니다.

이 글의 날짜는 설치 폴더와 백업 파일에 남은 시각, 커뮤니티에 제가 직접 쓴 메시지, 매일 아침 오던 정리 메일에서 확인한 것입니다. 3월에서 6월 사이는 그 밖의 기록이 얇아서, 왜 그렇게 판단했는지는 기억으로 메운 부분이 있고 본문에 그렇게 적었습니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.

원문 및 이후 연재 → https://3amdesk.github.io/posts/three-engines.html?ref=disquiet