Andrew Ford 헌정 강의: 『Modeling the Environment』 Chapter 2: Joe의 질문: “코드 작성은 언제 하나요?”

2월 26, 2025

Box 2.1에서, Joe는 한 가지 고민을 털어놓습니다.

“벤자민 박사님, 제가 요즘 공부하는 모델링 과제들은 죄다 드래그 앤 드롭(Drag & Drop) 방식이잖아요.
제 룸메이트는 프로그래머가 하루에 수십 줄의 코드를 쓴다는데,

난 왜 코드를 안 쓰고 있지? 이렇게 해서 과연 실력이 늘까요?”

이는 실제로 시스템다이내믹스(SD) 수업을 들은 학생들이 자주 하는 질문이기도 합니다.
프로그래밍 언어(예: Fortran, C, Python 등)로 직접 시뮬레이션 코드를 짜 본 적이 있거나,
“프로그래머는 매일 코드를 써야 한다”는 인식을 가진 분들이라면 “SD 모델링은 왜 코드가 없지?” 하고 의아해할 수 있죠.

“SD 모델링은 ‘코드’보다 ‘구조’가 핵심”

Andy가 책에서 말하듯, 시스템다이내믹스의 핵심 활동은 “피드백 구조를 파악하고, 모델의 기본 가정을 명확히 한 뒤, 이를 소프트웨어(예: Stella, Vensim)로 구현”하는 것입니다.

소프트웨어가 제공하는 저량-유량 지도(Stock & Flow Diagram)와 인과순환지도(Causal Loop Diagram) 등 시각적 도구를 통해, 코드를 직접 타이핑하지 않고도 모델(방정식)을 생성할 수 있습니다.
Joe 같은 학생 입장에서는, “정말 이렇게 마우스 클릭만으로도 모델이 만들어지는 게 가능한가?” 하고 당황할 수 있죠.

그러나 Box 2.1에서 Andy가 강조하는 것은,

“시스템다이내믹스는 프로그래밍 언어를 배우는 수업이 아니다.”
“실무에서 가장 중요한 일은 컴퓨터 앞이 아니라, 사람들과 문제의 본질을 논의하는 과정이다.”

다시 말해, SD 모델링에서 ‘코드 작성’은 핵심이 아니라, 필요하다면 방정식을 직접 살펴볼 수는 있지만,
대체로 소프트웨어가 코드 생성과 수치 해석을 도맡아 해 주기 때문에,
우리는 "모델 구조와 가정”에 더 많은 시간을 쏟게 된다는 겁니다.

그래도 “코드”는 존재한다

재미있는 건, Andy가 “코드가 아예 없는 건 아니다”라고 지적하는 부분입니다.

“(중략) But the equations do exist, as you can verify in the concluding exercises.”

— Andrew Ford, Box 2.1

즉, Stella나 Vensim에서 ‘방정식 리스트(equation view)’ 형태로 실제 코드를 보여 주는 기능이 있다는 것입니다.

다만 Joe가 미리 만들어둔 그림(Stock & Flow, Converter, Connector 등)을 기반으로 소프트웨어가 “뒤에서” 코드를 자동 생성하고 관리하기 때문에,
사용자가 굳이 코드 파일을 수정하거나 수식 전체를 타이핑할 일이 드물다는 것이죠.

“프로그래머”와 “모델러”의 차이?

Box 2.1은 전형적으로 ‘프로그래밍 수업’과 ‘시스템다이내믹스 모델링 수업’의 관점 차이를 보여 줍니다.

프로그래밍 수업:
- 언어 문법, 디버깅, 컴파일 등의 기술적 과정을 배움
- “얼마나 많은 코드를 작성했느냐”가 실력 척도처럼 여겨질 수 있음
SD 모델링 수업:
- “어떤 구조가 이 현상을 만들어 내는가?”를 고민
- 사람들과 인터뷰, 토론하며 시스템의 경계와 인과관계를 명확히 잡아가는 과정이 중요
- 소프트웨어가 방정식 입력과 시뮬레이션을 돕는 역할을 하지만, 모델러는 정책 시나리오, 민감도 분석 등에 초점을 맞춤

Joe가 느끼는 “코드를 안 써서 괜찮을까?”라는 불안은,
“모델러로서의 역량은 코드를 많이 작성해서가 아니라, 시스템을 제대로 이해하는 능력에서 나온다”는 사실을 아직 낯설게 받아들이고 있다는 뜻입니다.

실제 현장에서 코드보다 중요한 것: 사람들의 생각·가정·피드백 구조

Andy가 밝히듯이,

“Most of their time (modelers) is spent away from the computer, talking with people about the nature of the dynamic problem.”

이는 현장에서 정책 결정자, 이해관계자, 기술 전문가 등 다양한 사람들과 토론하며,

“무엇이 핵심 변수인가?”
“어떤 가정이 현실적인가?”
“피드백 루프는 어떻게 연결되어 있는가?”
…등을 탐색하는 과정이 SD 모델링의 진짜 본질임을 보여 줍니다.

결국 “몇 백 줄 코드를 썼다”가 중요한 게 아니라,
“이 모델이 현상을 얼마나 잘 반영하는지, 정책 대안을 어떻게 실험할 수 있는지, 그리고 의사결정자에게 의미 있는 통찰을 주는지”가 평가 기준이 됩니다.

마무리: Joe의 깨달음

Joe는 이 질문을 통해, “코드 작성 = 생산성”이라는 과거 인식에서 벗어나,
SD 모델링은 ‘시스템 구조를 시각화하고, 시뮬레이션을 통해 학습하는 활동’이라는 걸 깨닫게 됩니다.
그리고 마지막에는 “방정식이 보이지 않는다고 해서 존재하지 않는 게 아님”을 알게 되죠.
필요하면 소프트웨어가 생성한 방정식 뷰를 확인할 수 있지만,
- 코드 수정보다는 가정 수정, 피드백 루프 조정, 시뮬레이션 결과 해석 같은 모델링 프로세스가 더 중요하다는 결론에 이릅니다.

Box 2.1은 이렇게 짧은 일화를 통해, 시스템다이내믹스가 어떤 방향으로 설계되었고, 어떤 역량이 중요한지를 상징적으로 보여 주는 사례라 할 수 있습니다.

결론:
“SD 모델링은 코드를 많이 작성하기보다, 구조적 사고와 대화, 실험적 접근이 핵심이다.”

Joe 같은 초심자들에게도 안심하라는 Andy의 메시지가 담긴 유쾌한 에피소드입니다.

이 블로그 검색

정창권 박사의 시스템사고 블로그