Mac에 숨겨진 시한폭탄 - 정확히 49일 후 폭발합니다

 

 

진짜입니다. 공포 영화 이야기가 아닙니다.

 

맥북이나 Mac을 재부팅 없이 딱 49일 17시간 2분 47초 켜두면...

갑자기 인터넷 연결이 완전히 마비됩니다.

그런데 더 놀라운 건, 핑(ping)은 멀쩡하게 된다는 것!

마치 맥이 "나 살아있어요~" 하면서 실제로는 아무것도 못 하는 상태가 되는 거죠.

 

이게 도대체 어떻게 된 일일까요?

 

 

어떻게 이 버그를 발견했을까요?

 

발견의 시작은 꽤 황당했습니다.

 

AI 챗봇 서비스를 운영하는 Photon이라는 회사가 있습니다.

이 회사는 iMessage, WhatsApp, Telegram 등에서 AI 에이전트를 돌리기 위해 Mac 여러 대를 서버처럼 24시간 켜두고 있었는데요.

 

어느 날 갑자기...

멀쩡하던 Mac 몇 대가 아무런 이유도 없이 네트워크 연결을 받지 못하는 상태가 됐습니다.

새로운 접속 요청을 아예 거부하는 것처럼요.

 

근데 이상한 점이 있었습니다.

 

"기존에 연결된 것들은 계속 잘 되고 있고, 핑도 정상인데... 왜 새 연결만 안 되지?"

 

시스템 로그를 아무리 뒤져봐도 원인을 찾을 수 없었습니다.

결국 어쩔 수 없이 재부팅을 했고...

그러자 언제 그랬냐는 듯 멀쩡해졌죠.

 

이 팀은 포기하지 않고 원인을 끝까지 파고들었고, 마침내 충격적인 진실을 발견합니다.

 

 

범인은 바로 '숫자 그릇이 넘쳐버린 것'!

 

이 버그의 핵심 원인은 32비트 정수 오버플로우(Integer Overflow) 입니다.

 

조금 쉽게 설명해 드릴게요.

 

컴퓨터는 내부적으로 숫자를 비트(0과 1)로 저장합니다.

32비트 숫자 그릇은 최대 약 43억(4,294,967,295)까지 담을 수 있습니다.

이 숫자를 넘으면? 0으로 다시 돌아갑니다. 마치 자동차 주행거리 계기판이 999,999km를 넘으면 000,000으로 돌아오는 것처럼요!

 

macOS의 XNU 커널(macOS의 핵심 엔진) 내부에는 `tcp_now` 라는 TCP 타임스탬프 카운터가 있습니다.

 

이 카운터는 시스템이 켜진 순간부터 1밀리세컨드(ms)마다 1씩 증가합니다.

 

그리고 딱 49일 17시간 2분 47초가 되는 순간...

이 카운터가 32비트의 최대값 4,294,967,295에 도달합니다.

 

보통 이런 상황이면 숫자가 0으로 돌아가고 계속 카운트가 이어져야 하는데,

Apple의 XNU 커널은 이 처리를 잘못 구현했습니다.

 

카운터가 최대값에 도달한 순간, 숫자가 완전히 멈춰버립니다.

 

 

카운터가 멈추면 왜 인터넷이 죽나요?

 

TCP 연결이 어떻게 동작하는지 간단히 볼게요.

 

인터넷에서 데이터를 주고받을 때는 TCP(전송 제어 프로토콜)이라는 규칙을 씁니다.

여러 개의 연결을 동시에 관리하다 보면, 오래된 연결을 정리해줘야 합니다.

 

이때 `TIME_WAIT` 상태라는 것이 있는데요.

"이 연결은 이제 끝났으니, 잠깐 기다렸다가 없애줘"라는 뜻입니다.

보통 일정 시간이 지나면 자동으로 정리됩니다.

 

그런데 `tcp_now` 카운터가 멈추면 어떻게 될까요?

 

"이 연결 만료됐어?" → "현재 시간과 비교해볼게..." → "어? 시간이 안 흐르는데? 아직 안 만료된 것 같은데?"

 

결국 `TIME_WAIT` 상태의 연결들이 영원히 정리되지 않습니다.

 

그러면 연결에 쓰이는 포트 번호(ephemeral port)가 점점 소진되기 시작합니다.

포트는 컴퓨터의 "창구"같은 건데요.

Mac이 쓸 수 있는 창구가 모두 막혀버리면... 새로운 연결을 더 이상 받을 수도, 만들 수도 없게 됩니다.

 

 

더 혼란스러운 증상들

 

이 버그가 특히 까다로운 이유는 증상이 아주 이상하기 때문입니다.

 

- 핑(ping)은 된다 → "컴퓨터는 살아있네?"

- 이미 연결된 것들은 유지된다 → "네트워크는 되는 것 같은데?"

- 새로운 TCP 연결은 완전히 불가 → "그런데 왜 새 접속이 안 되지?!"

 

이렇게 됩니다. 마치 사람이 눈을 뜨고 숨도 쉬고 있는데, 말도 못하고 움직이지도 못하는 상태라고 할까요?

 

시스템 관리자나 개발자들이 이 증상만 보면 원인을 찾는 게 정말 어렵습니다.

에러 로그에도 아무 메시지가 없으니까요.

 

 

이 버그 언제부터 있었던 거야?

 

Photon 팀의 조사에 따르면, 이 버그는 macOS Catalina(2019년) 시절부터 있었을 가능성이 크다고 합니다.

 

벌써 6~7년 동안 숨어있었던 버그인 셈이죠!

 

왜 이제야 발견됐을까요?

 

사실 Mac은 서버용 OS가 아닙니다.

대부분의 사람들은 노트북 뚜껑을 닫거나, 주기적으로 업데이트를 위해 재부팅합니다.

49일 이상 논스톱으로 켜두는 경우가 거의 없었던 거죠.

 

그런데 요즘처럼 Mac을 서버처럼 24시간 켜두는 케이스가 늘어나면서 비로소 수면 위로 올라온 겁니다.

 

 

RFC 7323 - "이미 해결책이 있었는데..."

 

사실 이런 타임스탬프 카운터 오버플로우 문제는 업계에서 이미 알려진 문제입니다.

 

RFC 7323이라는 인터넷 표준 문서가 있는데요.

TCP 타임스탬프 클럭이 최대값에 도달했을 때 어떻게 처리해야 하는지를 명확하게 규정하고 있습니다.

 

하지만 Apple의 XNU 커널은 이 표준을 잘못 구현했고, 그 결과 카운터가 멈춰버리는 버그가 생긴 겁니다.

표준 문서도 있고, 해결책도 알려져 있는데... 그냥 놓쳐버린 거죠.

 

 

해결 방법은? (현재로서는...)

 

현재 공식적인 수정 패치는 아직 배포되지 않았습니다.

 

Photon 팀이 이 버그를 공개적으로 발표한 건 불과 며칠 전(2026년 4월)의 일입니다.

Apple이 빠르게 패치를 내놓을 것으로 예상되지만, 아직은 재부팅이 유일한 해결책입니다.

 

현재 임시 대응 방법:

- 49일 이전에 주기적으로 재부팅하기

- Mac을 서버용으로 쓰고 있다면 특히 주의!

- macOS 업데이트를 항상 최신으로 유지하기 (패치 나오는 즉시 업데이트)

 

내 Mac의 가동 시간을 확인하고 싶다면?

터미널을 열고 `uptime` 명령어를 치면 됩니다! 혹시 48일 넘었다면...

빨리 재부팅하세요.

 

저도 확인해보니 거의 2일...^^

 

 

이런 버그, 역사 속에 또 있었다!

 

이런 오버플로우 버그가 이번이 처음은 아닙니다.

 

가장 유명한 사례는 "Y2K 버그"죠.

연도를 두 자리로 저장하다 보니 1999 → 2000 넘어갈 때 오작동 우려가 있었던 바로 그 사건입니다.

 

또 2038년에는 "Y2K38 버그"가 예고되어 있습니다.

32비트 유닉스 시스템의 시간 카운터가 2038년 1월 19일에 오버플로우되는 문제인데요.

이건 전 세계가 알고 대비하고 있습니다.

 

그런 맥락에서 보면 이번 macOS의 49일 버그는... 규모는 작지만, 같은 부류의 버그입니다.

숫자 그릇의 크기를 충분히 고려하지 않으면 이런 일이 생깁니다.

 

 

마무리하며...

 

소프트웨어 세계에서는 이런 말이 있습니다.

 

"버그는 사라지지 않는다. 다음에 발견될 때를 기다릴 뿐이다."

 

이번 macOS의 49일 TCP 버그는 그 말을 다시 한번 실감하게 해주는 사례입니다.

6년 넘게 숨어있다가, 24시간 서버처럼 켜두는 사용 패턴이 늘면서 드디어 모습을 드러낸 것이니까요.

 

Apple이 빠르게 수정 패치를 내놓을 거라 기대합니다.

그때까지는... 49일이 되기 전에 재부팅을 습관화합시다!

 

혹시 Mac을 서버용으로 쓰시는 분들, 지금 바로 `uptime` 확인해보세요!

 

 

 

#맥OS버그 #macOS #XNU커널 #TCP버그 #49일버그 #네트워킹버그 #Apple #오버플로우 #인터넷마비 #개발자이야기 #소프트웨어버그 #커널버그