Halt and Catch Fire - 잊혀진 CPU 명령어가 알려주는 시스템의 본질

HCF, 컴퓨터를 멈추는 명령어

혹시 HCF(Halt and Catch Fire) 라는 말 들어보셨나요? 직역하면 "멈추고 불을 잡아라"인데, 이게 진짜로 옛날 CPU에 있었던(또는 있다고 전해지는) 명령어 이름이에요. 1970년대 모토로라 6800 같은 초기 마이크로프로세서에는 문서화되지 않은 명령어들이 있었는데, 그 중 일부가 CPU를 완전히 멈춰버리는 상태로 만들어서, 다시 시작하려면 전원을 껐다 켜야 했어요. 어떤 경우엔 칩이 과열돼서 정말로 연기가 나기도 했다고 해요. 그래서 엔지니어들이 농담 반 진담 반으로 HCF라는 별명을 붙였죠.

이번에 unstack.io에 올라온 글은 이 HCF를 출발점 삼아 "우리가 만드는 시스템들도 결국 어떤 식으로든 멈춘다" 는 이야기를 풀어내요. 단순히 옛날 하드웨어 향수 이야기가 아니라, 현대의 분산 시스템과 클라우드 인프라에도 똑같이 적용되는 통찰을 던지거든요.

시스템은 왜 멈추는가

글쓴이가 짚는 첫 번째 포인트는 "모든 시스템에는 정의되지 않은 동작(undefined behavior)이 있다" 는 거예요. HCF가 그랬듯이, 설계자가 의도하지 않은 조합의 입력이나 상태에 시스템이 빠지면 예측 불가능한 일이 일어나요. 단순한 CPU에서는 그게 "멈춤"이었지만, 복잡한 클라우드 시스템에서는 "무한 재시도 폭주", "캐시 스탬피드", "리트라이 폭풍" 같은 형태로 나타나죠.

예를 들어 Kubernetes에서 Pod가 죽으면 자동으로 재시작하잖아요. 그런데 어떤 이유로 Pod가 시작 직후에 계속 죽으면, 시스템이 계속 재시작을 시도하면서 클러스터 전체에 부하를 줘요. 이걸 CrashLoopBackOff 라고 하는데, 일종의 현대판 HCF예요. 시스템이 멈추는 게 아니라 "의미 없는 동작을 반복하면서 자원만 태우는" 상태로 들어가는 거죠.

추상화의 두 얼굴

글의 또 다른 핵심은 추상화가 우리를 보호하는 동시에 위험하게 만든다는 점이에요. 옛날에는 CPU를 직접 다뤘으니까 HCF 같은 위험도 직접 보였어요. 그런데 지금은 컨테이너 안에서, VM 위에서, 다시 클라우드 위에서 코드가 돌아가요. 우리는 추상화의 가장 윗단만 보고 "이건 안전해"라고 생각하지만, 사실은 그 아래에 우리가 모르는 수많은 HCF 같은 위험이 깔려 있어요.

좋은 예가 AWS의 us-east-1 리전 장애예요. 수많은 회사들이 "우린 클라우드를 쓰니까 장애로부터 안전해"라고 믿었지만, 한 리전이 흔들리니까 전 세계 서비스가 무너졌죠. 추상화의 가장 아랫단에서 문제가 생기면, 위에서 아무리 잘 만들어도 소용없어요. HCF는 단일 CPU의 이야기였지만, 이제는 글로벌 인프라 전체에서 비슷한 일이 일어나요.

우아하게 멈추는 법

그럼 어떻게 해야 할까요? 글쓴이가 제안하는 건 "잘 멈추도록 설계하자" 는 거예요. 시스템이 절대 안 멈추게 만들 수는 없으니까, 멈출 때 우아하게 멈추도록 만들자는 거죠. 이게 뭐냐면 회로 차단기(circuit breaker) 패턴, 백오프 전략, 헬스체크, 그리고 명확한 페일 모드 같은 거예요.

회로 차단기 패턴은 전기 회로의 두꺼비집과 똑같은 원리예요. 어떤 의존성(예: 외부 API)이 계속 실패하면, 그 호출 자체를 잠시 막아버리는 거예요. 그러면 우리 시스템이 실패한 외부에 매달려서 같이 죽는 걸 막을 수 있어요. Netflix의 Hystrix가 이걸 대중화시켰고, 지금은 거의 모든 마이크로서비스 환경의 기본기로 통해요.

또 하나 중요한 게 결정론적 페일오버(deterministic failover) 예요. 시스템이 망가질 때 어떤 상태로 들어갈지 미리 정해두는 거죠. 데이터 일관성을 포기하고 가용성을 살릴지(AP), 가용성을 포기하고 일관성을 지킬지(CP) 같은 CAP 정리의 선택을 명확히 하는 거예요. 이걸 모호하게 두면, 장애 때 시스템이 자기도 어떻게 해야 할지 몰라서 진짜 HCF 상태에 빠져요.

업계 흐름에서 보면

이런 "실패를 디자인하자"는 사고방식은 사실 SRE(Site Reliability Engineering) 문화의 핵심이에요. 구글이 SRE 책을 통해 대중화시켰고, 지금은 Netflix의 Chaos Engineering, Amazon의 Cell-based Architecture, 그리고 카오스 몽키 같은 도구들로 발전했어요. 일부러 시스템을 망가뜨려보면서 어떻게 망가지는지 학습하는 거죠.

최근에는 "deterministic simulation testing"이라는 흐름도 떠오르고 있어요. FoundationDB가 유명하게 만든 기법인데, 시스템 전체를 결정론적 환경에서 시뮬레이션 돌려서 모든 가능한 실패 시나리오를 미리 탐색하는 방식이에요. TigerBeetle, Antithesis 같은 회사들이 이 방향으로 가고 있어요. HCF의 교훈을 가장 진지하게 체화한 사례라고 할 수 있어요.

한국 개발자에게 주는 시사점

실무에서 우리가 가장 자주 마주치는 "멈춤"은 아마 데이터베이스 커넥션 고갈, 메모리 누수로 인한 OOM 킬, 외부 API 응답 지연으로 인한 스레드 풀 포화 같은 것들일 거예요. 이런 것들이 다 작은 HCF예요. 코드가 멈추는 게 아니라 의미 없는 일을 무한히 하면서 자원만 태우는 상태죠.

주니어에서 시니어로 넘어가는 결정적인 지점 중 하나가 바로 "실패 모드를 상상하는 능력"이에요. 코드를 짤 때 "이게 잘 동작하면"만 생각하지 말고, "이게 망가지면 어떻게 망가질까"를 함께 생각하는 습관을 들이세요. 타임아웃은 걸려 있나? 재시도는 백오프가 들어가 있나? 의존성이 죽으면 우리 서비스는 어떻게 페일하나? 이런 질문들이 결국 운영 가능한 시스템과 그렇지 않은 시스템을 가르거든요.

그리고 모의 장애 훈련(game day)을 한번이라도 해보세요. 의도적으로 DB를 죽이거나 네트워크를 끊어보면서 시스템이 어떻게 반응하는지 보는 거예요. 책으로 백 번 읽는 것보다 한 번 직접 경험하는 게 훨씬 와닿아요.