시스템을 '움직이는 그림'으로 본다는 것
AWS의 디스팅귀시드 엔지니어 마크 브루커(Marc Brooker)가 블로그에 'Animations for System Builders'라는 글을 올렸어요. 브루커는 EBS, Lambda 같은 AWS 핵심 서비스를 만들어온 엔지니어예요. 예전부터 “분산 시스템은 머릿속으로만 추론하지 말고, 간단한 시뮬레이션을 직접 돌려봐라”라고 꾸준히 말해왔죠. 'Simple Simulations for System Builders'라는 글도 썼고, 재시도 간격에 무작위성을 섞는 '지터(jitter)'의 효과를 시뮬레이션으로 보여준 AWS 블로그 글 'Exponential Backoff And Jitter'도 그의 글이에요.
이번 글의 화두는 제목 그대로예요. 시스템을 만드는 사람에게 왜 애니메이션이 필요할까? “발표 자료 꾸미는 얘기 아냐?” 싶을 수도 있지만, 생각보다 훨씬 실무적인 이야기예요. 오늘은 이 질문을 실무 관점에서 같이 풀어볼게요.
정적인 그래프가 숨기는 것
대시보드에서 흔히 보는 1분 평균 응답 시간, p99 지연 시간, 에러율 그래프를 떠올려 보세요. 이런 그래프는 '결과'는 잘 보여주지만, 그 결과가 나오기까지의 '과정'은 잘 못 보여줘요.
예를 들어 서버가 잠깐 느려진 사이에 클라이언트들이 한꺼번에 재시도를 했다고 해볼게요. 재시도 요청이 원래 트래픽에 얹히면 큐(대기열)가 길어지고, 큐가 길어지니 타임아웃이 더 나고, 그래서 재시도가 또 늘어나요. 처음 원인은 이미 사라졌는데도 시스템이 스스로 회복을 못 하는 거죠. 이런 걸 메타스테이블 장애(metastable failure)라고 하는데요, 쉽게 말하면 “원인이 없어졌는데도 나쁜 상태가 스스로 유지되는 장애”예요.
1분 평균 그래프로 보면 이건 그냥 “한동안 에러율이 높았다”로만 보여요. 그런데 큐가 차오르고 빠지는 모습을 시간 순서대로 움직이는 그림으로 보면, “재시도가 재시도를 부르는구나”가 한눈에 들어와요. 숫자로는 설명하기 어려운 피드백 루프가 눈에 보이게 되는 거예요.
직접 만들어보면 생각보다 간단해요
거창한 도구는 필요 없어요. 파이썬 matplotlib만 있어도 큐 하나짜리 시스템을 애니메이션으로 볼 수 있어요. 아래 코드에서 '틱'은 시뮬레이션 속 시간 단위예요.
import random
import matplotlib.pyplot as plt
from matplotlib.animation import FuncAnimation
fig, ax = plt.subplots()
line, = ax.plot([], [])
ax.set_xlim(0, 200)
ax.set_ylim(0, 150)
queue, xs, ys = 0, [], []
def update(t):
global queue
# 평소엔 한 틱에 평균 9건 도착
arrivals = sum(random.random() < 0.09 for _ in range(100))
if 50 <= t < 55:
arrivals += 20 # 5틱 동안 트래픽 폭주
queue = max(0, queue + arrivals - 10) # 서버는 한 틱에 10건 처리
xs.append(t)
ys.append(queue)
line.set_data(xs, ys)
return line,
anim = FuncAnimation(fig, update, frames=200, interval=50)
plt.show()
서버는 한 틱에 10건을 처리하고, 평소에는 평균 9건이 들어와요. 이용률(utilization)이 90%인 거죠. 50틱쯤에 트래픽이 몰리면 큐가 쭉 올라가요. 재미있는 건 폭주가 끝난 뒤에도 큐가 아주 천천히 줄어든다는 점이에요. 남는 처리량이 한 틱에 1건 정도라서, 100건 쌓인 걸 비우는 데 100틱 가까이 걸리거든요. “이용률 90%면 아직 여유 있는 거 아냐?”라는 생각이 왜 위험한지, 수식 없이도 바로 체감돼요.
여기에 “큐가 50을 넘으면 요청 일부가 재시도로 한 번 더 들어온다”는 로직을 넣어보세요. 재시도 비율을 조금만 올려도 큐가 영영 줄지 않는 지점이 생기는데, 그게 바로 앞에서 말한 메타스테이블 상태예요.
다른 도구들과 뭐가 다를까
시스템 동작을 검증하는 방법은 이미 여러 가지가 있어요. AWS는 TLA+나 P 같은 형식 검증 도구로 분산 프로토콜이 정확한지 확인하는 걸로 알려져 있어요. FoundationDB나 TigerBeetle은 결정론적 시뮬레이션 테스트로 좀처럼 재현되지 않는 버그를 잡아내고요. 실제 시스템에 트래픽을 쏴보는 부하 테스트도 있는데, 국내에서는 네이버가 공개한 nGrinder나 k6를 많이 써요.
그런데 이 도구들은 주로 “맞냐 틀리냐”, “몇 TPS까지 버티냐”에 답해요. 형식 검증은 정확성은 증명해 주지만 성능에 대한 감은 주지 않아요. 부하 테스트는 실제 숫자를 주지만 시스템을 다 만든 뒤에야 할 수 있고 비용도 크고요. 애니메이션은 바로 그 빈 곳을 채워요. 설계 초기에, 적은 비용으로 직관을 만들어주는 도구인 거죠. 남에게 설명하기 좋다는 것도 큰 장점이에요. 샘 로즈(Sam Rose)가 로드밸런싱과 큐잉을 인터랙티브 그림으로 풀어낸 글들처럼, 움직이는 그림 하나가 긴 문서보다 설득력 있을 때가 많거든요.
한국 개발자에게 주는 시사점
한국 서비스에는 애니메이션으로 보기 딱 좋은 상황이 많아요. 티켓팅, 수강신청, 선착순 쿠폰처럼 정각에 트래픽이 한꺼번에 몰리는 상황이 대표적이죠. 이걸 '썬더링 허드(thundering herd)'라고 부르는데요, 문이 열리자마자 소 떼가 한꺼번에 몰려드는 모습에 빗댄 표현이에요. 대기열이나 재시도 정책을 설계할 때 “지터를 넣어야 해요”라고 말로만 하는 것보다, 지터가 있는 버전과 없는 버전을 나란히 움직여 보여주는 게 훨씬 설득력 있어요.
장애 회고에도 써먹을 수 있어요. “왜 회복이 늦었나”를 타임라인 표로만 정리하지 말고, 당시 상황을 단순화한 애니메이션을 하나 붙여 보세요. 팀 전체가 머릿속에 같은 그림을 갖게 돼요. 요즘은 AI 코딩 도구에 시나리오를 설명하면 시뮬레이션 코드 초안이 금방 나와서, 시작하기도 훨씬 쉬워졌고요.
마무리
한 줄 정리: 평균값 그래프는 결과를 보여주고, 애니메이션은 원인을 보여줘요.
여러분 팀에서는 시스템 동작을 설명할 때 어떤 방법을 쓰나요? 설계 리뷰나 장애 회고에서 시각화로 설득에 성공했던(혹은 실패했던) 경험이 있다면 같이 나눠주세요!
🔗 출처: Hacker News