알라딘

헤더배너
상품평점 help

분류

이름:마이클 나이가드 (Michael Nygard)

최근작
2023년 11월 <Release의 모든 것>

저자의추천 작가 행사, 책 머리말, 보도자료 등에서 저자가 직접 엄선하여 추천한 도서입니다.
이 분야에 1개의 상품이 있습니다.
옵션 설정
25개
1.
프로그래밍 원리, 설계 방법, 아키텍처 방식, 심지어 언어의 기능조차 모두 (변화에) 적응하면서도 복잡성을 조직화하는 일과 관련돼 있다. 나는 2009년에 불변 데이터(immutable data)와 프로그램의 일부를 프로그램 자체 내부 데이터로 전환하는 두 가지 특성 때문에 클로저(Clojure)에 이끌렸고, 같은 이유로 최근에는 예호나탄 샤르빗이 쓴 이 책에 이끌렸다. 2005년에는 좋아하는 사람들과 함께 좋아하는 프로젝트 중 하나를 수행했다. 그 프로젝트는 자바 프로젝트였는데, 당시 자바 세계에서 일반적이지 않은 두 가지를 시도했다. 먼저, 핵심 데이터값을 불변으로 만들었다. 쉽지 않았지만, 효과가 아주 좋았다. 많은 클래스의 clone과 deepClone 메서드를 직접 작성했는데, 그로 인한 이득은 대단했다. 한 가지 예로, 사용자마다 개별화할 템플릿 문서가 필요하다고 가정하자. 전체 객체 트리의 복사본을 만들 수 있다면 객체 스스로는 자신이 템플릿 데이터인지 개별화된 데이터인지 알 필요가 없다. 결정은 그 참조를 가진 객체에 달렸다. 또 다른 큰 이점은 비교할 때다. 값이 불변이므로, 식별자가 동일하다는 것은 곧 값이 동등하다는 것을 의미한다. 따라서 동등성 확인을 매우 빠르게 할 수 있다. 두 번째 기법은 (예호나탄이 이 책에서 보인 정도까지는 아니지만) 범용 데이터(generic data)를 활용하는 것이었다. 어떤 계층에 클래스 계층 구조가 있다고 할 때, 인접한 계층은 이 클래스를 좀 더 일반적인 클래스의 인스턴스로 표현한다. 한 계층의 멤버 변수는 다른 계층에서 맵에 담긴 필드로 서술될 수 있다. 이런 방식은 분명히 팀에서 몇몇 사람이 잡담처럼 가볍게 제안한 의견에 영향을 받은 것으로 보인다. 이 또한 바로 이득이 됐다. 다양한 구성으로 객체를 조합하고 재조합할 수 있었기 때문이다. 이와 같이 데이터 지향 프로그래밍(DOP, Data-Oriented Programming)은 우발적 복잡도(accidental complexity)를 줄이고 작업하는 추상화의 수준을 높일 수 있다. 클래스에 범용 함수(generic function)를 만들어 넣은 결과, 프로그램의 반복되는 동작이 자연스럽지 않아 보일 것이다. 범용 함수가 있는 클래스는 프로그램 내부 값의 특정 부분 집합을 전담하는 작은 이름 공간(namespace) 같은 역할을 한다. 프로그램의 거의 모든 값은 맵과 리스트로 접어 넣을 수 있다. 객체 멤버의 이름(리플렉션 API를 사용해야 겨우 얻을 수 있는 데이터)은 맵의 키로 바꿀 수 있다. 이렇게 하면 코드가 조금씩 사라지는데, 이것이 깨달음의 첫 단계다. 이쯤 되면, 컴파일러가 컴파일하면서 멤버 이름을 사용해 코드에 오류가 없는지 확인하지 않느냐며 반대하는 사람이 있을 수 있다. 실제로 그렇다. 하지만 예호나탄이 컴파일 시점의 확인은 값에 오류가 없는지 확인하는 방법의 작은 하위 집합일 뿐이라는, 깨달음의 다음 단계로 우리를 안내할 것이니 믿어보자. 오류 확인 자체도 데이터로 만들 수 있다. 스키마를 프로그램 내부 값으로 만들 수 있을 뿐 아니라, 타입 시스템(type system)의 최전선에 있는 연구자들이 여전히 알아내려고 노력 중인 규칙도 적용할 수 있다. 이것이 두 번째 단계의 깨달음이다. 데이터 지향 프로그래밍은 특히 웹 API로 일할 때 빛난다. 통신에는 타입 시스템이 없으므로 요청에 포함된 데이터를 도메인 클래스에 그대로 매핑하려고 하면 구현이 복잡해질 뿐 아니라 쉽게 깨진다. 데이터를 데이터로 남겨두면 코드가 더 단순해지고 수백 메가바이트 크기의 프레임워크 라이브러리를 사용할 필요가 대폭 줄어든다. 그렇다면 캡슐화, 상속, 다형성이라는 객체지향 프로그래밍(OOP, Object-Oriented Programming)의 미덕은 이제 쓸모없는 것일까? 이 세 가지를 나눠 마치 ‘일품요리’처럼 각각 따로 맛볼 수 있다는 사실이 밝혀졌다(내 생각에 구현 상속은 이 중에서 가장 중요하지 않다. 종종 가장 먼저 배운 것임에도 그렇다. 나는 이제 프로토콜과 공유된 함수 서명을 통한 인터페이스 상속을 선호한다). 데이터 지향 프로그래밍은 전통적인 유형의 다형성을 제공한다. 첫 번째 인수의 자료형에 따라 여러 함수 중 하나로 디스패치(dispatch)하는 것이다(객체지향 언어에서 this는 암묵적인 메서드의 첫 번째 인자다. 생략된 첫 인자가 점(.) 앞에 올 뿐이다). 하지만 데이터 지향 프로그래밍은 스키마 확인처럼 더 많은 역동성을 허용한다. 처음 두 인자의 자료형에 따라 디스패치한다고 생각해보자. 또는 인자에 오늘 날짜가 들어가 있는 ‘생일’ 필드가 있는지에 따라 디스패치된다고 상상해보자. 이것이 깨달음의 세 번째 단계다. 캡슐화는 여전히 프로그램을 조직하는 논리에 적용해야 한다. 우리는 값이 아닌 하위 시스템을 캡슐화한다. 이 캡슐화는 데이비드 파나스(David Parnas)의 설계 결정 은닉(design decision hiding)을 구현한다. 하위 시스템 내부에서는 클래스가 강요하는, 단절된 이름 공간으로 데이터를 나누는 것을 그만둘 수 있다. 앨런 펄리스(Alan Perlis)는 “자료구조 열 개에 함수 열 개가 동작하는 것보다 자료구조 하나에 함수 100개가 동작하는 것이 더 낫다”고 말했다. 엔트로피와의 끝없는 전투 중에는 데이터 지향 프로그래밍으로 코드양을 줄여 싸움을 계속할 수 있고 추상화 수준을 높여 프로그램의 논리와 의미를 정확하고 명료하게 만들 수 있다. 데이터 지향 프로그래밍으로의 여정을 즐기고, 새로운 고원에 도착할 때면 잠시 멈춰 전망을 즐기면서 스스로에게 “데이터일 뿐이야!”라고 말하자.
가나다별 l l l l l l l l l l l l l l 기타
국내문학상수상자
국내어린이문학상수상자
해외문학상수상자
해외어린이문학상수상자