그림으로만 그리던 시스템 모델을 실행해볼 수 있어요
“우리 서비스 사용자는 왜 늘다가 정체될까?”, “버그 백로그는 왜 안 줄지?” 같은 질문을 받으면 보통 화이트보드에 화살표를 그려가면서 설명하잖아요. 그런데 그 그림은 그 자리에서 끝나요. 숫자를 넣어서 “그래서 6개월 뒤엔 어떻게 되는데?”를 확인하려면 엑셀을 따로 열어야 하죠.
Meadows는 이 빈틈을 메우려고 나온 작은 언어예요. 텍스트로 스톡-플로우 다이어그램을 정의하면 그게 그림으로도 나오고, 시간에 따라 실제로 실행되는 시뮬레이션도 돼요. 이름을 들으면 시스템 사고(Systems Thinking) 분야의 고전 『Thinking in Systems』를 쓴 도넬라 메도즈(Donella Meadows)가 떠오르는데요, 그만큼 시스템 다이내믹스 전통에 뿌리를 둔 도구예요.
스톡과 플로우가 뭐냐면
메도즈가 즐겨 쓴 비유가 욕조예요. 지금 욕조에 담긴 물의 양이 스톡(Stock)이에요. 어느 시점에 쌓여 있는 양이라는 뜻이죠. 수도꼭지에서 들어오는 물은 유입 플로우(Inflow), 배수구로 빠져나가는 물은 유출 플로우(Outflow)고요. 스톡은 이 둘의 차이만큼 시간에 따라 변해요. 들어오는 물이 나가는 물보다 많으면 차오르고, 적으면 줄어들죠.
개발 현장에 대입해보면 바로 와닿아요.
- 사용자 수(스톡) = 신규 가입(유입) − 이탈(유출)
- 버그 백로그(스톡) = 새로 들어온 버그 리포트(유입) − 수정 완료(유출)
- 기술 부채(스톡) = 급하게 짠 코드(유입) − 리팩터링(유출)
텍스트로 쓰면 어떤 느낌일까
아래는 Meadows의 실제 문법이 아니고, 이런 언어가 어떤 개념을 표현하는지 보여주려고 쓴 의사코드예요.
stock 사용자 = 1000
flow 가입 = 사용자 0.05 (1 - 사용자 / 시장규모)
flow 이탈 = 사용자 * 0.02
매 시간 단계마다: 사용자 += 가입 - 이탈
실행 엔진이 하는 일은 생각보다 단순해요. 시간을 하루 단위처럼 잘게 쪼개고, 단계마다 플로우를 계산해서 스톡에 더하고 빼는 걸 반복해요. 이걸 수치 적분(오일러 방법)이라고 부르는데요, 쉽게 말하면 아주 짧은 간격으로 가계부를 계속 업데이트하는 거예요. 이렇게 돌려보면 사용자 수가 S자 곡선을 그리다가 시장 규모 근처에서 멈추는 걸 눈으로 확인할 수 있어요.
기존 도구들과 비교하면
시스템 다이내믹스는 1950년대 MIT의 제이 포레스터(Jay Forrester)가 시작한 분야예요. 1972년 『성장의 한계(The Limits to Growth)』 보고서로 널리 알려졌고요. 도구로는 Stella, Vensim 같은 상용 데스크톱 소프트웨어가 오래 쓰였어요. 그 밖에 웹에서 무료로 쓰는 Insight Maker, Vensim 모델을 파이썬에서 돌려주는 PySD, 인과 루프를 장난감처럼 가지고 놀 수 있는 Nicky Case의 Loopy도 있어요.
이 도구들은 대부분 마우스로 박스와 화살표를 그리는 GUI 중심이에요. 그런데 Meadows처럼 텍스트가 원본이면 얘기가 달라지거든요. Git으로 버전을 관리하고, 코드 리뷰에서 diff로 변경점을 보고, LLM한테 “이 모델에 채용 지연을 추가해줘” 같은 요청을 하기도 쉬워요. Mermaid나 D2 같은 “Diagrams as Code” 흐름의 연장선인데요, 그 도구들이 정적인 그림만 만든다면 Meadows는 움직이는 모델을 만든다는 게 차이예요.
한국 개발자에게 어떤 쓸모가 있을까
솔직히 당장 실무 코드에 들어갈 도구는 아니에요. 대신 생각을 검증하는 도구로는 꽤 쓸모가 있어요. 예를 들어 “개발자 두 명을 더 뽑으면 일정이 당겨질까?”를 모델링해보면, 온보딩하는 동안 기존 인원의 생산성이 떨어져서 단기적으로는 오히려 느려지는 구간이 보일 수 있어요. 유명한 브룩스의 법칙을 시뮬레이션으로 직접 체감하는 거죠.
인프라 쪽에서 보면 큐(Queue)도 스톡이에요. 메시지 유입률과 컨슈머 처리율을 넣으면, 트래픽이 몰릴 때 적체가 얼마나 쌓이고 언제 풀리는지 미리 그려볼 수 있어요. 제품 회의에서 리텐션 개선과 신규 유입 확대 중 뭐가 더 효과적인지 논쟁이 붙었을 때도, 숫자로 돌려본 그래프 하나가 긴 토론을 확 줄여줄 거예요.
마무리
핵심 한 줄: 화이트보드에 그린 화살표를 실행 가능한 코드로 바꿔보면 직관이 틀리는 지점이 보여요.
여러분 팀에도 “분명 이렇게 될 줄 알았는데 반대로 간” 경험이 있나요? 그 상황을 스톡과 플로우로 그려보면 어떤 루프가 숨어 있었을까요?
🔗 출처: Hacker News