회사 컴퓨터가 느려진 원인은 새로 켠 게 아니라 안 끈 것이었습니다 — 자동화를 늘릴수록 대표가 먼저 정할 「끄는 규칙」

컴퓨터가 느려지면 개발자도 대표도 같은 곳을 봅니다.
「일을 너무 많이 시켰나.」

9월 11일 오후, 저희 상시 가동 컴퓨터가 그랬습니다. 램 32GB에 코어 10개짜리 기기인데 부하 수치가 86에서 126 사이를 오갔습니다. 코어 10개면 10 안팎이 정상이니 10배입니다.

실측을 하고 나니 답이 달랐습니다. 새로 켠 것이 아니라 안 끈 것이 문제였습니다. 그날 겪은 순서 그대로 적습니다.

증상부터 숫자로 적습니다. 스왑 22.5GB 중 21GB를 쓰고 있었고, 디스크는 초당 약 1,000회를 읽고 썼습니다.
램이 모자라 디스크를 램처럼 쓰는 상태입니다.

그런데 CPU 사용량 합은 약 700%뿐이었습니다. 코어 10개면 1,000%까지 쓸 수 있는데 그 아래입니다. 부하 126의 나머지는 일을 하는 게 아니라 메모리를 기다리는 줄이었습니다.

메모리를 누가 쥐고 있는지 세니 세 덩어리가 나왔습니다. 같은 백엔드 서버가 같은 폴더에서 5벌, 파일 변경을 지켜보는 감시기 3개가 3일 21시간에서 4일 6시간째, 그리고 컨테이너 도구가 실제 필요 3.2GB에 한도 10GB를 쥔 채였습니다.

부모가 없는 프로세스, 그러니까 띄운 주인이 이미 사라진 것만 모아도 9.8GB였습니다. 램 32GB의 3분의 1을 주인 없는 것이 쥐고 있었습니다.

저희는 AI 에이전트 세션을 하루에 십여 개 돌립니다. 코드를 고치는 세션은 확인을 위해 개발 서버를 백그라운드로 띄웁니다.
그 세션이 끝나면 서버도 같이 꺼질 것 같지만, 아닙니다.

세션이 끝나면 그 서버는 운영체제의 기본 관리자(macOS의 launchd)가 넘겨받아 계속 돕니다. 부모가 사라진 프로세스가 고아가 되어 살아남는 것입니다. 재부팅이 없는 상시 가동 기기라 쌓이기만 합니다.

같은 폴더에 5벌이 생긴 이유도 같습니다. 세션이 서버를 다시 시작할 때마다 이전 것을 죽이지 않고 새것을 하나 더 띄웠습니다. 이틀 동안 다섯 번이면 다섯 벌입니다.

세션마다 붙는 도구 연결도 복제됩니다. 세션 11개가 각자 도구 연결(MCP) 약 21개씩을 띄워 234개였습니다. 지침상 안 쓰는 도구까지 모든 세션에 떠 있었습니다.

이 구조는 상담에서 자동화를 설계할 때도 그대로 나옵니다. 매일 도는 자동화는 켜는 순간부터 「언제 멈추나」가 같이 정해져야 합니다.

매일 수백 개를 확인하는 자동화는 매일 무언가를 띄웁니다. 띄운 것을 누가 내리는지 적혀 있지 않으면, 그 자동화는 켜는 규칙만 있고 끄는 규칙이 없는 상태로 돌아갑니다.

전부 끄지는 않았습니다. 살아 있는 세션이 쓰고 있을지 모르는 것은 남기고, 이틀 넘은 것만 골랐습니다.
같은 폴더의 백엔드 5벌과 감시기 3개, 묶음으로 19개 프로세스였습니다.

끄기 전에 하나를 더 확인했습니다. 이 8개 묶음이 포트를 쥐고 있는지입니다.
하나도 없었습니다.

서비스 포트는 이미 다른 것이 쓰고 있었고, 이 8개는 아무도 접속하지 않는 채로 메모리만 쥐고 있었습니다.

19개 중 12개는 정상 종료 신호를 무시해 강제 종료가 필요했습니다. 끝나고 나니 스왑이 16.8GB에서 15.4GB로 내려왔고, 살아 있어야 할 서비스의 상태 확인은 그대로 200이었습니다.

컨테이너 도구는 한도를 10GB에서 5GB로 줄였습니다. Docker 공식 문서에 따르면 이 한도의 기본값은 컴퓨터 램의 50%입니다. 32GB 기기면 16GB를 내주는 셈이고, 실제 컨테이너가 쓰는 양은 3.2GB였습니다.

부하는 90대에 남았습니다. 남은 것은 쓰레기가 아니라 다른 세션이 실제로 하는 일이었습니다. 안 끈 것을 걷어내고 나서야 진짜 용량 문제가 얼마인지 보였습니다.

이 글에서 가장 중요한 칸은 여기입니다.
컨테이너 도구의 한도를 바꾸려면 도구를 다시 시작해야 했고, 그 재시작이 다른 세션이 돌리던 운영 백엔드의 배포 빌드를 끊었습니다.

재시작 전에 본 것은 컨테이너 목록이었습니다. 22개 전부 정상이었습니다.
보지 않은 것은 그 도구 위에서 지금 진행 중인 빌드였습니다.

빌드 단계에서 끊겨 운영 서비스는 무사했지만, 그 세션은 배포를 처음부터 다시 돌려야 했습니다.

정리 작업이 운영 사고가 되는 지점이 정확히 여기입니다. 목록은 「무엇이 떠 있나」를 보여 주지 「누가 지금 그것을 쓰고 있나」는 보여 주지 않습니다.

그래서 끄기 전 질문이 하나 더 붙습니다. 「지금 이 위에서 진행 중인 빌드나 배포가 있나.」 목록이 아니라 진행 중인 작업을 먼저 봅니다.

이 사고에서 대표가 가져갈 것은 명령어가 아니라 규칙 세 칸입니다.
개발자에게 받아 두면 대표가 직접 돌릴 수 있습니다.

하나. 「느리다」는 말이 나오면 늘리기 전에 셉니다. 부모가 없는 프로세스, 같은 이름이 여러 벌인 것, N일 넘은 것.

이 세 가지를 세는 명령 한 줄을 받아 두고 느려질 때마다 같은 명령을 돌립니다.

둘. 자동화마다 「끝나면 누가 끄나」를 적습니다. 세션이 띄운 것은 세션이 끝날 때 같이 내려가야 합니다.

그게 안 되는 도구는 「이틀 넘으면 종료」 같은 청소 규칙을 기계에 겁니다. 사람이 기억해서 끄는 규칙은 규칙이 아닙니다.

셋. 끄기 전에 「지금 누가 쓰고 있나」를 봅니다. 프로세스와 컨테이너 목록만 보지 말고 진행 중인 빌드와 배포를 먼저 확인합니다.

자동화를 설계할 때 저희가 「전부 자동」 대신 사람이 멈춰 보는 지점을 남기라고 권하는 이유도 같은 자리에 있습니다.

켜는 것은 개발자가 합니다. 언제 멈추고 누가 끄는지는 대표가 먼저 정하는 칸입니다. 그 칸이 비어 있으면 느려짐은 용량 문제로 오해되고, 램을 늘린 뒤에 다시 느려집니다.

정리

경고 신호

• 「느려요」에 대한 첫 대답이 「램을 늘리죠」다

• 자동화가 띄운 것을 누가 끄는지 어디에도 적혀 있지 않다

• 상시 가동 컴퓨터를 재부팅한 지 언제인지 아무도 모른다

• 도구를 재시작하기 전에 진행 중인 빌드·배포를 확인하는 절차가 없다

좋은 신호

• 부모 없는 것·같은 이름 여러 벌·이틀 넘은 것을 세는 명령 한 줄이 있고 느려질 때마다 같은 숫자를 남긴다

• 자동화 목록마다 「끝나면 누가 끄나」 칸이 채워져 있다

• 이틀 넘은 백그라운드 프로세스는 기계가 알아서 종료한다

• 도구 한도가 실제 사용량 기준으로 적혀 있고, 재시작 전에 진행 중 작업을 먼저 본다

개발자에게 오늘 물어볼 네 가지

1. 지금 그 컴퓨터에 부모 없는 프로세스가 몇 개입니까? 세는 명령을 보여 주세요.
   느낌이 아니라 명령의 출력으로 답을 받습니다. 저희는 9.8GB였습니다.

2. 같은 프로그램이 같은 폴더에서 여러 벌 돌고 있지 않습니까?
   재시작할 때 이전 것을 죽이는지 물어봅니다. 저희는 5벌이었습니다.

3. 자동화가 띄운 것은 끝나면 누가 끕니까?
   세션이 끝날 때 같이 내려가는지, 아니면 이틀 넘으면 종료하는 규칙이 걸려 있는지 확인합니다.

4. 도구를 재시작하기 전에 진행 중인 빌드·배포를 어떻게 확인합니까?
   컨테이너 목록이 아니라 진행 중 작업을 보는 명령이 따로 있어야 합니다.

자주 묻는 질문

Q. AI 에이전트가 띄운 서버가 왜 세션이 끝나도 계속 돕니까?

세션이 백그라운드로 띄운 프로세스는 세션이 끝나면 운영체제의 기본 관리자가 넘겨받습니다. 부모가 사라져도 프로세스는 살아남는 구조입니다. 재부팅이 없는 상시 가동 기기에서는 이런 고아 프로세스가 쌓이기만 합니다.

Q. 램을 늘리면 해결되지 않습니까?

안 끈 것이 원인이면 늘려도 다시 찹니다. 저희 실측에서 주인 없는 프로세스가 9.8GB, 컨테이너 도구가 필요량의 3배를 쥐고 있었습니다. 이걸 걷어내고 남는 부하가 진짜 용량 문제이고, 늘리는 결정은 그다음입니다.

Q. 무엇부터 끄면 안전합니까?

이틀 넘은 것 중에서 포트를 쥐고 있지 않은 것부터입니다. 저희는 이 기준으로 19개를 껐고 살아 있어야 할 서비스는 그대로 정상이었습니다. 살아 있는 세션이 쓰고 있을지 모르는 것은 남깁니다.

Q. 정리 작업이 운영 사고가 된 이유는 무엇입니까?

컨테이너 도구를 재시작하기 전에 컨테이너 목록만 보고 그 위에서 진행 중인 배포 빌드를 보지 않았습니다. 빌드가 끊겨 그 세션은 배포를 다시 돌려야 했습니다. 끄기 전에는 목록이 아니라 진행 중인 작업을 먼저 확인합니다.

Q. 컨테이너 도구의 메모리 한도는 얼마로 두어야 합니까?

실제 컨테이너 사용량 기준으로 정합니다. Docker 공식 문서상 기본값은 컴퓨터 램의 50%인데, 저희는 컨테이너 합이 3.2GB인데 한도가 10GB였습니다. 5GB로 줄여도 22개 컨테이너 전부 정상이었습니다.