Victor

[연재] 봇이 여섯이 되자 뭐가 도는지 안 보였다 — 현황판을 만든 이유

연재 · 2026-09-13

260건이 통째로 사라졌는데, 로그는 깨끗했습니다

 

8월 3일 하루에 사고를 셋 겪었어요. 셋 다 아무도 몰랐다는 게 사고였습니다.

 

첫째. 키보드 스위치 자료를 주 1회 갱신하는 일이 있는데, 그날 최저가 260건을 통째로 날렸습니다. 구조가 이래요. 기존 캐시를 먼저 비우고, 그다음에 가격을 새로 받아옵니다. 그런데 받아오는 쪽 API가 죽어 있었어요. 지우기는 성공하고 채우기는 실패한 거죠. 결과는 0건입니다.

 

문제는 그다음입니다. 로그는 깨끗했고 종료코드도 0이었어요. 프로그램 입장에서는 아무 일도 안 일어났거든요. "지우기 완료" 찍고 "받아오기 완료" 찍고 정상 종료했습니다. 받아온 게 0건이라는 건 아무도 안 물어봤고요. 게다가 화요일에만 도는 일이라 그 사이에 다시 돌 일도 없었습니다.

 

둘째. 같은 날 인스타에 올라가야 할 10시 회차가 통째로 빠졌습니다. 재시도를 다 쓰고 실패한 건데, 다음 회차가 성공하면 그 실패 자국은 로그 꼬리에서 밀려 사라져요. 저는 로그 끝만 보니까 늘 마지막 성공만 보게 됩니다.

 

셋째. 쇼핑 API 하나가 에러 코드를 뱉으며 죽어 있었습니다. 이것도 아무도 안 물어봤으니 아무도 몰랐고요.

 

셋을 나란히 놓고 보니 공통점이 하나였습니다. 전부 물어봐야만 알 수 있는 것들이었어요. 그리고 그 답은 어렵지도 않았습니다. 파일 하나 열어서 몇 건인지 세면 되고, 로그에서 오늘 몇 번 돌았나 세면 됩니다. 전부 이미 디스크에 있는 값이었어요.

 

물어봐야 아는 상태 자체가 비용입니다. 이 편은 그 비용을 없애려고 화면 하나를 만든 이야기예요.

 

 

지금은 이렇게 생겼습니다. 브라우저에서 주소 하나 치면 뜨는, 제 컴퓨터 안에서만 도는 화면이에요.

 

여섯 개가 되니까 못 따라가겠더라고요

 

처음엔 이런 게 필요 없었습니다. 자동으로 도는 게 하나였을 땐 터미널 한 번 열어보면 끝이니까요.

 

그런데 사이트를 만들고, 매일 아침 배포를 걸고, 쇼츠를 만들어 유튜브랑 인스타에 올리기 시작하니까 정해진 시각에 알아서 도는 일이 여섯 개쯤 됐어요. 여기에 며칠씩 걸리는 작업이 하나둘 붙고요.

 

이쯤 되니 "지금 뭐가 도는지"를 알려면 이런 걸 해야 했습니다.

 

터미널 열기 → 돌고 있는 프로그램 목록 보기
로그 파일 열어서 끝부분 읽기
결과 폴더 열어서 파일 몇 개 생겼나 세기

 

세 군데를 열어야 답이 하나 나옵니다. 그것도 매번요. 그러니까 안 물어보게 돼요. 안 물어보면 260건이 0이 돼도 일주일을 모릅니다.

 

그래서 7월 27일 오전에 이 화면을 다시 지었습니다. 원래도 비슷한 게 있긴 했는데, 그 화면은 "도구 하나에 카드 하나"였어요. 제가 알고 싶은 건 그게 아니었습니다. 저는 늘 이게 궁금했거든요.

 

"지금 이 창이 뭘 붙잡고 있지?"

 

그래서 화면의 주어를 터미널로 바꿨습니다. 창 하나가 세로 칸 하나가 되고, 그 안에 그 창이 만지는 것들이 들어가는 구조예요.

 

 

맨 윗줄이 창입니다. 어느 창인지, 어떤 모델을 쓰는지, 기억을 얼마나 먹었는지(481k/1.00M 같은 것), 이번 주에 얼마나 썼는지가 한 줄에 있어요.

 

 

그 아래에 그 창이 만진 것들이 쌓입니다. 초록 테두리가 지금 만지는 중, 회색이 잠잠한 것이고요. 빨간 것 보이시죠. 오류가 나면 오류 문구를 그대로 화면에 띄웁니다. 로그를 열러 가지 않아도 뭐가 없다는 건지 바로 읽히거든요.

 

여기까지가 제가 눈앞에서 시키는 일들입니다. 이 편의 본론은 그 아래, 제가 안 보고 있을 때 도는 것들이에요.

 

회차마다 네모를 하나씩 그렸습니다

 

정해진 시각에 도는 일은 카드 하나가 됩니다. 그리고 회차마다 네모가 하나씩 그려져요.

 

 

이건 사이트 배포입니다. 하루 한 번 아침 9시에 돌아서, 그날 날짜가 된 예약 글을 내보내요. 네모가 하나인 건 하루에 한 번 돌기 때문입니다.

 

색은 넷이에요.

 

회색아직 안 함
노랑도는 중
초록됐음
빨강실패

 

여기까지는 흔한 얘긴데, 하나를 더 넣었습니다. 네모 안에 숫자를 두 줄로 넣었어요. 위는 돌기로 한 시각, 아래는 실제로 돈 시각입니다.

 

 

이렇게요. 왼쪽은 09:30 에 돌기로 했는데 09:31 에 돌았고, 빨간색이니까 그 회차에서 오류가 났다는 뜻입니다. 오른쪽은 16:30 예정에 16:30 정각, 초록이고요.

 

이 두 줄이 은근히 값을 합니다. "됐다"만 보면 늦은 걸 못 잡거든요. 아침 9시 배포가 9시 5분에 돌았으면 그건 정상이지만, 어느 날 9시 40분에 돌기 시작했다면 그건 뭔가 밀리고 있다는 뜻입니다. 두 줄이 나란히 있으면 그게 눈에 걸려요.

 

하루에 여러 번 도는 일이면 네모도 여러 개가 한 줄로 섭니다.

 

 

유튜브 업로드는 하루 다섯 번이라 네모가 다섯 개예요. 아래 5/5 완료가 오늘치 성적표입니다. 그 밑에는 실제로 뭐가 올라갔는지 제목이 줄줄이 남고요.

 

 

인스타는 하루 세 번이라 세 개고요. 10:00 예정에 10:01, 16:00 예정에 16:01, 22:00 예정에 22:01. 1분씩 늦는 건 정상입니다. 크론이 정각에 시작해서 파일을 올리는 데 그 정도 걸리는 거예요.

 

 

만들어만 두고 아직 안 올린 것들도 순서대로 보입니다. 언제, 어느 갈래가, 어떤 제목으로 나가는지요. 이게 있으니까 "내일 뭐 올라가지?"를 안 물어보게 됐어요.

 

그런데 이 신호등이, 만들고 나서 세 번이나 거짓말을 했습니다. 아래가 그 이야기입니다.

 

초록불인데 실패였습니다

 

8월 14일에 이 화면을 따로 훑어봤어요. 만든 지 좀 됐으니 제대로 보고 있는지 확인해보자는 거였습니다. 그랬더니 이게 나왔습니다.

 

로그에 실패가 찍혀 있는데, 봇 신호등도 초록이고 건강 검사도 정상이라고 했다.

 

실패한 걸 성공이라고 보고하고 있었던 겁니다. 이게 제일 나쁜 종류의 고장이에요. 화면이 없는 것보다 나쁩니다. 없으면 의심이라도 하는데, 초록불이 켜져 있으면 안 봅니다.

 

원인은 셋인데, 셋 다 "로그에서 이번 회차가 어디부터 어디까지인가"를 가르는 자리에 있었어요.

 

하나, 회차를 닫는 줄을 새 회차의 시작으로 읽었습니다. 로그는 회차마다 ═══ 날짜 시각 ═══ 같은 머리줄로 시작하는데, 끝날 때도 비슷한 모양의 줄을 하나 찍거든요. 그 닫는 줄을 머리줄로 착각한 겁니다. 로그 파일은 대개 그 줄로 끝나니까, "마지막 회차"가 그 28글자짜리 줄 하나가 돼버렸어요. 그 안에 오류가 있을 리가 없죠. 무엇이 들어 있든 늘 초록이었습니다.

 

둘, 로그를 꼬리 2,000자만 봤습니다. 한 회차가 그보다 길면 머리줄이 창 밖으로 밀려나요. 그럼 회차를 가를 수가 없습니다. 그래서 머리줄이 있는 로그는 20,000자까지 넓혀서 보게 고쳤습니다.

 

셋, 머리줄 모양을 너무 좁게 박아놨습니다. ═══ 를 세 개로 못 박아뒀는데, 어떤 로그는 네 개(════)를 쓰고 있었어요. 그래서 그 로그는 "머리줄이 아예 없는 로그"로 취급됐습니다. 제대로 적어둔 쪽이 손해를 본 거죠.

 

여기서 재미있는 게 하나 나왔어요. 둘째를 고쳤더니 다른 카드가 헛빨갛게 켜졌습니다. 머리줄이 없는 로그는 창을 넓힌 만큼 지난주 것까지 오늘 것으로 읽게 되거든요. 이미 하루 전에 고쳐놓은 오류가 다시 살아난 겁니다. 그래서 넓힌 창은 머리줄이 있는 로그에만 쓰기로 다시 갈랐어요.

 

고친 다음엔 되짚어 확인했습니다. 그날 아침 로그를 그대로 넣어봤을 때 고치기 전 코드는 "정상", 고친 코드는 "오류". 이걸 안 해보면 고쳤는지 안 고쳤는지 모릅니다. 화면만 보면 둘 다 그럴듯해 보이거든요.

 

고쳐도 안 꺼지는 빨간 등이 있었어요

 

같은 자리에서 그 전에 겪은 게 하나 더 있습니다. 이건 반대 방향이었어요.

 

어느 날 자동 실행 하나가 빨갛게 떴습니다. 로그를 열어보니 진짜 오류가 있었어요. 폴더를 옮기기 직전 마지막 실행이 옛 경로에서 권한에 막힌 거였습니다. 이미 사라진 경로 얘기였죠.

 

원인을 고쳤는데 등이 안 꺼졌습니다.

 

그때는 판정을 로그 꼬리 2,000자로 하고 있었는데, 그 로그가 통째로 1,655바이트였어요. 사흘 전 오류가 계속 꼬리 안에 있었던 겁니다. 어제 고쳤든 오늘 고쳤든 그 파일이 커지기 전까지는 계속 빨간불이에요.

 

안 꺼지는 빨간 등은 정보가 아니라 소음입니다. 며칠만 지나면 아무도 안 봐요. 그리고 안 보게 되면 다음에 진짜 깨졌을 때도 안 봅니다.

 

세 가지를 고쳤습니다.

 

1. 판정을 마지막 회차 하나로만. 로그 전체가 아니라 이번에 돈 회차 안에서만 오류를 찾습니다. 2. 같은 규칙이 두 군데 있던 걸 찾았어요. 신호등 쪽만 고쳤더니 봇 카드가 여전히 옛 오류를 물고 있었습니다. 화면을 보고 "아직 떠 있는데"라고 해서 알았어요. 한 규칙이 두 곳에 적혀 있으면 반드시 하나만 고치게 됩니다. 3. 깨진 회차를 눌러서 끌 수 있게 했습니다. 지우는 게 아니에요. 그 회차는 정말로 깨졌고 로그에 남아 있습니다. 누르면 가 붙고 회색으로 죽을 뿐이에요. 이미 손본 일이 매일 빨갛게 있으면, 다음에 진짜 깨졌을 때 눈이 안 가니까요.

 

고장이 아닌 멈춤을 고장으로 읽었습니다

 

8월 19일에 또 하나 나왔어요. 이번엔 좀 결이 다릅니다.

 

매일 정해진 시각에 도는 일 중에 이런 게 있어요. 자료가 모자라면 억지로 진행하지 않고 멈춥니다. 대신 "이건 자료가 없어서 못 했습니다, 이것 좀 알려주세요" 하고 질문을 남겨두죠. 억지로 채워서 만든 결과물보다 하루 비는 게 낫다고 봤거든요.

 

그런데 그 멈춤을 로그에 로 적어놨습니다. 신호등은 를 보고 빨간불을 켰고요.

 

고장이 아닌데 고장으로 보이는 겁니다. 이게 왜 나쁘냐면, 진짜 고장 났을 때 구별이 안 되기 때문이에요. 매일 빨간불이 하나 켜져 있으면 그건 배경이 됩니다.

 

그래서 판정을 이렇게 갈랐어요. 로그에 "자료가 없어 쓰지 않습니다" 나 "질문을 남겼습니다" 가 있으면 빨강도 초록도 아닌 '모름' 으로 둡니다. 그리고 건강 검사에 줄을 하나 새로 만들었어요. "답을 기다리는 질문 몇 건" 이라고요. 기다리는 중이라는 걸 알아야 "오늘 왜 안 나왔지"가 아니라 "아, 내가 답을 안 했구나"가 되니까요.

 

여기서도 세는 범위 때문에 한 번 틀렸습니다. 질문 개수를 로그 꼬리에서 통째로 셌더니 1건이 44건으로 부풀었어요. 지난 회차에 이미 답한 질문까지 다 더해진 거죠. 이것도 마지막 회차 하나만 보게 고쳤습니다.

 

같은 실수가 반복되는 게 보이시죠. "어디까지가 이번 것인가"를 안 정하면 숫자든 색이든 다 틀립니다.

 

'도는 중'을 짐작으로 판정하고 있었어요

 

8월 14일에 화면에 "지금 도는 중" 표시를 붙였습니다. 로그는 끝나야 찍히니까, 도는 도중에는 로그만 봐서는 알 수가 없거든요. 그래서 실제로 돌고 있는 프로그램 목록을 봅니다.

 

처음 만든 방식은 이랬어요. 크론에 적힌 명령에서 스크립트 이름을 글자로 뽑아내고, 돌고 있는 프로그램들의 명령줄에 그 글자가 들어 있나 봅니다. 자연스럽죠. 그런데 이건 규칙이 아니라 어림짐작이었고, 짐작이라 두 번 틀렸습니다.

 

  • bash 가 스크립트 이름으로 뽑혔습니다. 그랬더니 제 컴퓨터에서 도는 아무 셸에나 "도는 중"이 붙었어요.
  • 두 봇이 둘 다 refresh.sh 라는 이름의 파일을 돌리고 있었습니다. 이름이 같으니 구별이 안 됩니다. 한쪽이 돌면 양쪽 다 초록이 됐어요.

 

둘 다 화면을 보고서야 알았습니다. 규칙을 따져서 안 게 아니에요. "어? 얘가 왜 지금 돌지?" 하고 이상해서 들여다본 겁니다.

 

답은 처음부터 있었어요. 크론 줄에는 어느 폴더에서 실행하라가 적혀 있고, 돌고 있는 프로그램에도 지금 어느 폴더에 있나가 있습니다. 그 둘을 글자 단위로 맞추면 짐작할 게 없어요. 이름이 같아도 폴더가 다르면 다른 일이니까요.

 

그리고 하나 더 정했습니다. 폴더를 못 물어봤을 때는 안 붙입니다. 권한이 없거나 그 사이 프로그램이 끝나버리면 폴더를 못 알아낼 수가 있는데, 그때 이름만 보고 "아마 이거겠지" 하고 붙이면 엉뚱한 카드에 초록불이 켜져요. 모를 때는 아무것도 안 하는 게 맞습니다.

 

이 화면은 AI를 안 부르는, 규칙만으로 도는 물건이에요. 그러면 판정도 규칙이어야 합니다. 짐작으로 채운 규칙은 규칙이 아니고요.

 

안 보이는 것은, 안 도는 것과 구별이 안 됩니다

 

같은 날 하나 더 알았습니다. 크론에서 부르면 안 되는 일이 있었어요.

 

맥에서 크론으로 프로그램을 돌리면 로그인 계정의 열쇠고리(키체인)를 못 읽습니다. 실제로 확인해봤더니 접근이 거부되더라고요. 거기에 자격 증명을 두는 도구는 크론에서 부르면 늘 "로그인 안 됨"이 됩니다. 손으로 실행하면 되는데 크론에서만 조용히 실패하는 거죠.

 

그래서 그 일을 크론이 아니라 맥의 다른 예약 방식(LaunchAgent)으로 옮겼습니다. 문제는 옮기는 순간 현황판에서 그 카드가 통째로 사라졌다는 거예요. 화면이 크론표만 읽고 있었으니까요.

 

여기서 규칙을 하나 세웠습니다.

 

안 보이는 것은 안 도는 것과 구별이 안 된다.

 

그래서 화면이 맥의 예약 설정도 같이 읽어서 크론 줄과 똑같은 모양의 글자로 바꿔 내놓게 했어요. 그 아래에 있는 신호등이나 건강 검사는 한 줄도 안 고쳤습니다. 뭘로 예약했든 화면 입장에서는 그냥 "몇 시에 도는 일"이면 되니까요.

 

로그가 깨끗해도 망가집니다 — 그래서 결과를 봅니다

 

이제 맨 처음 얘기로 돌아갑니다. 260건이 0이 된 사고요.

 

신호등은 로그에 오류 글자가 있나를 봅니다. 그런데 그 사고는 로그가 깨끗했어요. 그러니 신호등으로는 영원히 못 잡습니다. 그래서 탭을 하나 더 만들었습니다.

 

 

맨 윗줄에 이렇게 써놨어요. "로그가 아니라 결과를 봅니다."

 

보는 건 다섯 가지입니다.

 

  • 결과물이 신선한가 — 돌기는 했는데 아무것도 안 만든 경우
  • 결과물이 줄지 않았는가 — ★ 260건이 0이 되는 걸 잡는 항목입니다
  • 바깥 API가 살아 있는가 — 조용히 죽습니다
  • 한 번도 안 돌아본 예약이 있는가
  • 오늘 돌았어야 할 회차가 다 돌았는가

 

화면을 보시면 항목마다 "몇 시간 전 · 몇 건" 이 붙어 있죠. 스위치 최저가가 39.9시간 전 526건, 이어폰 자료가 16.6시간 전 2,517건 하는 식이에요. 건수를 같이 적는 게 핵심입니다. 신선하기만 하고 0건이면 그게 바로 그날의 사고니까요.

 

 

아래쪽은 예약된 일들이 오늘 몇 번 돌았나입니다. 오늘 5/5회 는 다섯 번 돌았어야 하는데 다섯 번 돌았다는 뜻이에요. 인스타 10시 회차가 통째로 빠졌던 사고가 여기 걸립니다. 실패해도 다음 회차가 성공하면 로그에서는 안 보이지만, 횟수를 세면 하나가 빕니다.

 

여기에 원칙을 하나 박아뒀어요. 값을 못 재면 '모름'입니다. 초록도 빨강도 아니에요. 키가 없어서 못 물어본 걸 통과로 세면 검사가 있으나 마나 해지거든요. 지금 화면 맨 위에 나쁨 0 · 모름 0 · 정상 37 이라고 뜨는데, 저 '모름' 칸이 있는 것과 없는 것은 전혀 다른 화면입니다.

 

최근에 하나 더 붙였습니다. 외장 디스크가 꽂혀 있나를 봐요. 사진이랑 영상 원본을 외장으로 옮기고 바로가기를 걸어뒀는데, 이게 빠지면 "자료가 없다"가 아니라 "자료가 0건" 인 상태로 배포와 업로드가 돌아버립니다. 앞의 260건이랑 똑같은 모양이죠. 그래서 크론 앞에 문지기를 세워 막고, 이 탭에서는 오늘 문지기가 몇 번 막았는지까지 같이 봅니다. 막힌 걸 모르면 "오늘 왜 안 올라갔지"로만 보이거든요.

 

며칠씩 도는 일 — 늘릴 때 코드를 안 고칩니다

 

마지막 칸입니다. 크론도 아니고 제가 앉아서 시킨 것도 아닌, 그냥 며칠씩 도는 일들이에요. 자료를 모으거나 변환하는 것들요.

 

 

카드는 딱 세 가지만 답합니다. 어디까지 갔나 · 뭐가 돌고 있나 · 언제 끝나나.

 

여기서 제일 신경 쓴 건 다른 겁니다. 작업을 하나 더 붙일 때 프로그램을 안 고치게 만드는 것.

 

작업 하나 추가할 때마다 코드를 고쳐야 하면, 다음 작업 때 또 코드를 고쳐야 해요. 그럼 결국 안 붙이게 되고, 안 붙인 작업은 다시 "물어봐야 아는" 상태로 돌아갑니다. 그래서 무엇을 보고 진행을 세는지까지 등록표에 글로 적고, 프로그램은 그 글대로 세기만 하게 했어요. 이렇게 생겼습니다.

 

"이름": {
  "note":  "화면에 적을 한 줄",
  "unit":  "편",
  "log":   "로그 파일 위치",
  "total": { "file": "전체 목록 파일", "how": "len" },
  "bars":  [{ "label": "잰 편", "count": {"file": "결과 파일", "how": "sum_len:tracks"} }]
}

 

how 가 세는 방법이에요. 목록 길이를 세거나, 줄 수를 세거나, 폴더 안에 특정 파일이 있는 것만 세거나, 로그에서 [3/9] 같은 표시를 세거나. 세는 방법을 늘리는 자리는 한 곳이고, 작업을 늘리는 자리는 등록표뿐입니다.

 

남은 시간은 최근 두 시간의 실제 속도로만 계산해요. 밤새 멈춰 있던 시간까지 섞어서 평균을 내면 남은 시간이 몇 배로 늘어나거든요. 그럼 그 숫자를 안 믿게 되고, 안 믿는 숫자는 없는 거나 같습니다.

 

세는 일에서 세 번 틀렸습니다

 

이 칸이 제일 여러 번 틀렸어요. 셋 다 세는 방식 문제였습니다.

 

하나, 껍데기를 거르려다 진짜를 지웠습니다. 프로그램 중에는 다른 걸 감싸기만 하는 게 있어요. 예를 들면 "화면 안 꺼지게 하면서 이걸 실행해줘" 같은 것들요. 이걸 안 거르면 한 개가 두 개, 세 개로 세어집니다. 그래서 걸렀는데, 여기에 bash 를 넣어버렸어요.

 

그랬더니 bash 뒷일.sh 처럼 셸 자체가 일하는 당사자인 경우가 통째로 지워졌습니다. 멀쩡히 돌고 있는 작업이 화면에는 "멈춤"으로 떴어요. 규칙을 이렇게 고쳤습니다. 껍데기는 뒤에 진짜가 있을 때만 껍데기다. 같은 무늬에 걸린 것 중에 껍데기 아닌 게 하나라도 있을 때만 껍데기를 뺍니다.

 

둘, 이름 조각으로 걸렀더니 남의 것까지 셌습니다. 결과 폴더에 앞서 처리한 것들이 같이 들어 있었는데, 이름에 특정 글자가 들어간 것만 세게 해놨거든요. 실제로는 28편인데 화면에는 60편으로 떴습니다. 진행률이 두 배로 부풀어 있었던 거예요. 이름 조각 대신 처리 대상 목록 파일을 읽어서 그 목록에 든 것만 세도록 고쳤습니다.

 

여기 딸린 함정이 하나 더 있어요. 맥은 파일 이름의 한글을 자음·모음으로 쪼개서 저장합니다. 화면에 보이는 글자는 같은데 컴퓨터가 보기엔 다른 글자예요. 그래서 한글이 든 폴더를 이름으로 찾으면 하나도 안 걸립니다. 실제로 0편으로 떴었어요. 비교하기 전에 모양을 맞춰주는 한 줄로 해결했습니다.

 

셋, 못 센 걸 0으로 적었습니다. 외장 디스크를 안 꽂아뒀을 때, 다 끝난 작업이 0% 로 떴어요. 세러 갔는데 폴더가 없으니 0이 나온 거죠.

 

이건 앞에서 나온 '모름'과 같은 얘기입니다. 모르는 걸 0이라고 적으면 사람이 믿어요. 비어 있으면 의심하는데 0은 그냥 읽고 넘어갑니다. 그래서 못 세면 0이 아니라 '못 셈' 으로 적게 했습니다.

 

이 화면은 AI를 한 번도 안 부릅니다

 

마지막으로 이 화면에서 제일 중요한 결정 하나요. 여기는 AI를 한 번도 안 부릅니다.

 

유혹은 꽤 셌어요. AI로 만든 도구들을 보는 화면이니까, 요약도 AI한테 시키면 되잖아요. "이 작업은 지금 3단계 중 2단계를 진행 중입니다" 같은 문장을 예쁘게 뽑아줄 겁니다.

 

그런데 그렇게 만들면 이 화면은 켜놓는 것만으로 계속 돈이 나가는 물건이 됩니다. 3초마다 다시 그리는 화면인데요.

 

그래서 요약도 전부 기록에서 그냥 뽑아 이어 붙였습니다. 문장이 매끄럽진 않은데 대신 틀릴 일이 없어요. 요약이 아니라 그대로 옮긴 거니까요. 진행률도 파일 개수를 세는 게 전부고, 도는 중인지도 프로그램 목록을 보는 게 전부입니다.

 

그래서 켜놓는 데 드는 비용이 0입니다.

 

이게 그냥 절약 얘기가 아니에요. 하루 종일 켜놓을 수 있느냐 없느냐를 가르는 조건이었습니다. 비용이 드는 화면은 필요할 때만 켜게 되고, 필요할 때만 켜는 화면은 결국 "물어봐야 아는 것"으로 돌아갑니다. 처음 문제로 되돌아가는 거죠.

 

관제는 더 많이 보는 게 아니라, 묻지 않아도 보이게 하는 것

 

만들 때는 "뭐가 도는지 보려고" 만든 거였어요. 그런데 쓰면서 알게 된 건 좀 다릅니다.

 

이 화면이 준 건 정보가 아니라 질문을 안 해도 되는 상태였어요. 예전엔 "쇼츠 올라갔나?", "어제 배포 됐나?", "그 수집 어디까지 갔지?"를 하루에도 몇 번씩 스스로 확인해야 했습니다. 지금은 안 물어봅니다. 물어볼 필요가 없어서요. 대신 이상한 게 있으면 저쪽에서 눈에 걸려요.

 

이번 편에서 사람이 남은 자리를 꼽으라면 셋입니다.

 

하나, 화면이 거짓말하는 걸 잡은 것. 초록불인데 실패였던 것, 고쳐도 안 꺼지던 빨간 등, 도는 중인데 멈춤으로 뜨던 것, 28편이 60편으로 세어지던 것. 전부 화면을 실제로 쓰다가 잡았습니다. 코드만 봐서는 전부 맞아 보였어요. AI는 "명령줄에 이름이 있으면 도는 중"이라는 규칙을 아주 그럴듯하게 짜줍니다. 그게 bash 하나에 세상 모든 셸이 걸린다는 건 화면을 봐야 압니다.

 

둘, 모른다고 적기로 정한 것. 못 잰 걸 0으로 적을지 '못 셈'으로 적을지, 자료가 없어 멈춘 걸 빨강으로 볼지 '모름'으로 볼지. 이건 코드 문제가 아니라 이 화면을 믿을 수 있게 만들 것이냐의 문제입니다. 편한 쪽은 늘 0으로 적는 쪽이에요. 화면이 깔끔해지거든요.

 

셋, 안 만들기로 정한 것. AI를 안 부르기로 한 것, 진행률을 예쁘게 요약 안 하기로 한 것. 만들 수 있는 걸 안 만드는 결정은 AI가 잘 못 합니다. 물어보면 대개 "만들 수 있습니다"라고 답해요.

 

그래서 관제가 뭐냐고 하면, 저는 이렇게 정리했습니다.

 

더 많이 보는 게 아니라, 묻지 않아도 보이게 하는 것.

 

화면에 항목을 백 개 올리는 건 쉽습니다. 그건 관제가 아니라 그냥 목록이에요. 어려운 건 틀린 초록불을 없애는 것이고, 그건 화면을 만드는 일이 아니라 매번 실제로 확인해보는 일이더라고요.

 

다음 편은 이 화면이 세는 숫자 이야기입니다. 무엇을 세고 무엇을 안 셀지를 정하는 게, 결국 무엇을 중요하게 볼지 정하는 일이었거든요.

 

#현황판 #관제화면 #대시보드 #자동화모니터링 #모니터링 #관측성 #크론탭 #cron #launchd #신호등 #로그분석 #헬스체크 #오류탐지 #진행률 #파이썬 #표준라이브러리만 #로컬서버 #의존성없이 #AI코딩 #클로드코드 #개발자아닌사람 #1인개발 #사이드프로젝트 #휴먼인더루프 #사람이하는일 #자동배포 #유튜브쇼츠 #인스타릴스 #victorhouse #개인홈페이지

댓글

    로그인 없이 쓰는 대신, 등록한 댓글은 직접 지울 수 없습니다. 지워야 할 댓글은 옆의 신고를 눌러주세요.
    네이버 블로그글 원문 보러가기 →유튜브 쇼츠만드는 장면 20초로 보기 →
    관리자 Victor · 문의는 우상단 신고·제안으로 남겨주세요.
    글과 화면은 정적 파일로 만듭니다. 댓글과 조회수만 외부 데이터베이스에 저장합니다 — 개인정보처리방침

    오류 신고 · 제안

    관리자 Victor에게 전달됩니다