MacBook Air M1의 처절한 생존기 (w/ Clickhouse)

들어가기

고수는 장비 탓을 하지 않는다고 하지만, 저는 고수가 아니기 때문에 장비 탓 좀 하겠습니다. 노트북이 항상 최신 맥북 프로면 당연히 좋겠지만, 현실적인 비용 문제로 쉽게 교체하기가 어렵습니다.

제가 사용하는 노트북은 MacBook Air M1 · 8GB RAM으로 아주 훌륭하진 않지만 Kafka, Flink, Redis, Serving API, ClickHouse 정도는 Docker로 충분히 띄울 수 있습니다.

문제는 띄우는 순간 굉음이 시작된다는 겁니다. 마치 비행기 이륙할 때처럼요… 굉음이 너무 심해 이어폰을 껴보기도 했지만, 노트북 키보드를 사용하다 보니 발열이 손끝으로 고스란히 전해지더군요.

“이렇게 시달릴 수는 없어!”라는 생각이 들어 애플 공홈을 들어가 봤다가, 가격을 보고 다시 시달리기로 결정했습니다. 하지만 이 발열을 그대로 두면 배터리 성능은 녹아내릴 테고… 어떻게 해야 할까 고민하다 보니 이런 결론에 도달했습니다.

“아, 노트북을 바꿀 돈은 없으니 이 파이프라인 시스템을 최적화해야겠다. 안 되더라도 그냥 한번 해보자.” 이런 목표가 생긴 것이죠. 쾌적한 로컬 개발 환경을 사수하기 위해, 옆구리 살 같은 Redis와 Serving API를 제거하며 다이어트해 본 경험을 공유합니다.

1. 문제의 시작 : “내 노트북 팬이 멈추지 않는건 내 실력이 부족한 탓인걸까?”

개인 프로젝트로 CTR 데이터 파이프라인 시스템을 구축하고 이것저것 실험을 이어가던 중, Docker를 올릴 때마다 무서워졌습니다. 기본적으로 한 사이클을 돌려보기 위해서는 단 하나의 컨테이너도 빠짐없이 올려야 하는데, 올릴 때마다 팬 돌아가는 소리가 너무 괴랄했거든요..

기존 시스템 아키텍처는 이렇게 구성되어 있습니다.

flowchart LR
    P[Producers] -->|Events| K[Kafka]
    K --> F[Flink Job]
    
    subgraph "Local Docker Resources"
    F -->|Hot Data| R[(Redis)]
    F -->|History| C[(ClickHouse)]
    R --> API[Serving API]
    C --> Client2[분석 시스템]
    end
    
    API --> Client1[관련 부서]
    
    
    style R fill:#ff9999,stroke:#333,stroke-width:2px
    style API fill:#ff9999,stroke:#333,stroke-width:2px

Kafka로부터 조회수와 클릭수 이벤트를 수신받아 집계하고 저장하는 과정에서 ClickHouse와 Redis에 데이터를 저장하고, ClickHouse는 분석용으로, Redis + Serving API는 관련 부서에 데이터를 전달하는 용도로 사용하고자 했습니다.

그런데 이렇게 구성해 보니 세 가지 Pain Point가 생겼습니다.

리소스 부족 : Redis + Serving API 컨테이너가 차지하는 Memory와 CPU 때문에 정작 중요한 Flink Job이 OOM으로 죽는 경우도 있었습니다.
관리 포인트 증가 : 집계 결과 변경으로 스키마가 바뀌면 Flink를 수정하고, Redis 데이터를 초기화한 뒤, API 코드까지 수정해야 해서 혼자 개발하는데도 Context Switching 비용이 너무 컸습니다.
네트워크 오버헤드 : 로컬 환경임에도 불구하고 Flink → Redis → API 과정에서 불필요한 직렬화/역직렬화 비용이 계속 발생했습니다.

가만히 생각해 보니 API를 조회하는 주요 고객을 ML 팀으로 가정했는데, 만약 사내 팀에서 ClickHouse로 직접 조회하는 것이 가능하다면 Redis와 Serving API를 제거할 수 있겠다는 판단이 들었습니다.