동시성, 상호작용성, 가변성 — 셋 중 둘만 고르세요

프로그래밍 언어나 시스템을 설계할 때 “전부 다 가질 수는 없다”는 트레이드오프 이야기가 종종 나오는데요. 분산 시스템의 CAP 정리(일관성, 가용성, 분단 내성 중 둘만 고르라는 그 유명한 정리)가 대표적이죠. 최근 한 개발자가 비슷한 구도의 흥미로운 주장을 내놨어요. 바로 동시성(concurrency), 상호작용성(interactivity), 가변성(mutability) — 이 셋 중 둘만 가질 수 있다는 거예요. 언뜻 뜬구름 같지만, 이 프레임 하나로 여러 언어들의 설계 철학이 깔끔하게 설명되거든요.

세 가지 개념부터 짚고 갈게요

각각이 뭐냐면 이렇습니다. 동시성은 여러 작업이 겹쳐서 실행되는 것. 스레드, 고루틴, async 같은 걸 떠올리시면 돼요. 가변성은 데이터를 제자리에서 바꿀 수 있다는 것. 변수에 새 값을 대입하고 리스트에 항목을 추가하는, 우리가 매일 하는 그거요. 마지막으로 상호작용성이 조금 낯설 수 있는데요, 이건 프로그램을 껐다 켜지 않고 실행 중인 상태 그대로 코드를 고칠 수 있다는 뜻이에요. Lisp이나 Smalltalk 계열 언어의 REPL 개발이 대표적이죠. 서버가 돌아가는 채로 함수 하나를 새로 정의하면 즉시 반영되는, 그런 개발 방식이요. 써본 사람들은 “한번 맛보면 못 돌아간다”고 말하는 경험이기도 하고요.

왜 셋이 같이 못 있을까요

문제는 이 셋이 만나는 지점에서 터져요. 실행 중인 프로그램의 코드를 갈아끼우는 순간을 상상해 보세요. 어떤 스레드는 아직 옛날 코드를 실행하고 있고, 다른 스레드는 방금 바뀐 새 코드를 실행해요. 그런데 둘 다 같은 가변 데이터를 만지고 있다면? 옛 코드는 데이터가 예전 구조라고 가정하고, 새 코드는 새 구조라고 가정하니까 상태가 꼬여버리는 거죠. 구조체 정의를 바꿨는데 메모리에는 옛 레이아웃의 객체가 살아있다든가, 락을 잡고 있는 함수를 재정의해서 락이 영영 안 풀린다든가 하는 식으로요. 그런데 셋 중 하나만 포기하면 이 문제가 통째로 사라져요. 그래서 “둘만 고르라”는 겁니다.

실제 언어들은 어떤 선택을 했나

이 프레임으로 보면 언어들의 설계가 선명하게 보여요. Erlang/Elixir는 동시성과 상호작용성(핫 코드 리로딩)을 갖는 대신 가변성을 버렸어요. 모든 데이터가 불변이고 프로세스끼리는 메시지로만 소통하니까, 실행 중에 코드를 갈아끼워도 공유 상태가 꼬일 일이 없거든요. 전화 교환기를 끄지 않고 업데이트해야 했던 에릭슨의 요구가 이 설계를 낳았죠. Common Lisp이나 Smalltalk은 반대로 상호작용성과 가변성을 잡았어요. 살아있는 이미지를 마음껏 주무르는 개발 경험이 일품이지만, 멀티스레드가 얽히는 순간 위험해져요. Rust나 Go 같은 요즘 컴파일 언어들은 동시성과 가변성을 고르고 상호작용성을 포기한 쪽이에요. Rust는 소유권 시스템으로 “가변 참조는 동시에 하나만”이라는 규칙을 컴파일러가 강제하죠. 대신 코드를 바꾸려면 다시 컴파일하고 재시작해야 하고요. Clojure는 흥미로운 절충인데, 불변 자료구조를 기본으로 깔아서 REPL 개발과 동시성을 동시에 챙긴 케이스예요.

우리가 매일 쓰는 도구에도 흔적이 있어요

이 트레이드오프는 사실 프론트엔드 개발자도 매일 겪고 있어요. React의 Fast Refresh나 Flutter의 핫 리로드가 컴포넌트 밖 상태를 리셋해버리거나, 특정 상황에서는 전체 리로드로 후퇴하는 게 바로 이 문제 때문이거든요. 실행 중 코드 교체(상호작용성)를 하려니 가변 상태가 발목을 잡는 거죠. Redux 같은 상태 관리 라이브러리가 불변 업데이트를 고집하는 것도 결국 “가변성을 줄여서 나머지를 얻는” 같은 계열의 선택이고요.

정리하면

언어 논쟁에서 “왜 얘네는 불변성을 강요해?”라거나 “왜 컴파일 언어엔 제대로 된 REPL이 없어?”라는 불만이 나올 때, 이 삼각형을 떠올리면 많은 게 설명됩니다. 어떤 언어가 이상해서가 아니라 셋 중 뭘 버릴지를 다르게 선택했을 뿐이라는 거죠. 여러분이 지금 쓰는 언어는 셋 중 뭘 버렸나요? 그리고 새 프로젝트를 시작한다면 여러분은 어떤 둘을 고르시겠어요?