# 데이터 지향 프로그래밍의 장점 Advantages Of Data Oriented Programming
Clojure로 작업하면서 제가 발견한 가장 큰 장점 중 하나는 데이터 지향적이라는 점입니다. 궁극적으로 모든 코드는 데이터를 변환하기만 하면 됩니다. 프로그램은 하나의 데이터를 입력으로 시작하여 다른 데이터를 출력으로 생성합니다. 주류 언어는 객체 지향 시맨틱을 사용하여 이를 추상화하려고 시도합니다. 이러한 추상화의 실질적인 가치는 명확하지 않지만, 이러한 접근 방식과 관련된 몇 가지 명백한 문제가 있습니다. OO 스타일을 사용하여 프로그램을 구조화할 때의 몇 가지 단점을 살펴봅시다.
전통적으로 객체는 내부 상태를 나타내는 몇 가지 데이터 필드를 포함하고 이를 조작하기 위한 몇 가지 메서드를 제공하는 일종의 상태 머신으로 생각할 수 있습니다. 객체는 OO에서 가장 작은 구성 단위를 나타내며, 프로그램은 이러한 객체들이 서로의 상태를 조작하여 상호 작용하는 그래프로 구성됩니다.
첫 번째 문제는 각 객체가 임시 DSL이라는 점입니다. 개발자는 객체를 설계할 때 메서드 형태로 API를 정의하고 객체가 수행할 동작을 생각해냅니다. 따라서 각 객체는 고유하며, 하나의 객체가 어떻게 동작하는지 안다고 해서 다음 객체가 어떻게 동작할지 알 수 있는 것은 아닙니다. 리치 히키(Rich Hickey)는 Clojure, Made Simple (opens new window) 강연에서 이 점을 자세히 설명합니다. 더 많은 객체를 정의할수록 더 많은 동작을 머릿속에 기억해야 합니다. 따라서 인지 오버헤드는 프로그램 크기에 비례하여 증가합니다.
프로그램에 변경 가능한 객체가 있으면 개발자는 프로그램의 동작 방식을 알기 위해 객체의 상태를 알아야 합니다. 상호 의존적인 상태 머신의 그래프로 구조화된 프로그램은 추론이 불가능해집니다. 이 문제는 객체들이 서로에 대한 참조를 통해 암시적으로 연결되어 변경 가능한 상태를 공유한다는 데서 비롯됩니다. 이로 인해 참조 투명성이 부족하거나 결여되어 코드에 대한 로컬 추론이 불가능해집니다. 코드가 무엇을 하고 있는지 파악하려면 읽고 있는 코드와 참조를 공유하는 모든 코드를 추적해야 합니다.
이것이 객체 지향 언어에서 코드를 효과적으로 작업하기 위해 정교한 디버깅 도구가 필요한 이유 중 하나입니다. 대규모 프로그램에서 무슨 일이 일어나고 있는지 알 수 있는 유일한 방법은 디버거에서 실행하여 특정 상태로 만든 다음 검사하는 것입니다. 안타깝게도 이 방법은 특정 상태에 도달하는 다양한 경로가 있을 수 있고 모든 경로를 다 다뤘다고 보장할 수 없으므로 휴리스틱에 불과합니다.
객체의 또 다른 주목할 만한 문제는 객체를 직렬화하는 표준 방법이 없어 프로그램 경계에서 추가적인 문제가 발생한다는 것입니다. 예를 들어 웹 서버에서 객체 그래프를 가져와서 클라이언트로 전송할 수 없습니다. 모든 객체에 대해 커스텀 직렬화기를 작성해야 하므로 프로그램에 복잡성과 상용구가 추가됩니다. 이와 관련된 문제는 자체 클래스를 정의하는 라이브러리를 구성할 때 발생합니다.
dmitri [at] fastmail.com