프로그래머가 알아야 할 97가지 - 두 번째 이야기
by - Edward Garson
Apple II LOGO를 통해 프로그래밍을 접한 후 컴퓨터와 관련된 일에 열정을 쏟아왔다. 지금은 프리 소프트웨어 개발 컨설턴트로 활동 중이고 애자일을 도입하려는 기업을 지원하는 일에 힘을 쏟고 있다. 소프트웨어 아키텍처 설계, 프로그래밍 언어, GNU/Linux에 깊은 관심을 두고 있다. 영국 컴퓨터 학회, 마이크로소프트 아키텍트 협회 등 다양한 콘퍼런스의 열정적인 발표자이기도 하다. '97 Things Every Software Architect Should Know'의 기고자 이기도 하다. 아내 그리고 두 명의 아들과 함께 몬트리올에 살고 있다. 취미는 스키, 등산, 사이클링이다.
요즘 프로그래밍 커뮤니티에서 함수형 프로그래밍에 관한 관심이 다시 높아지고 있습니다. 소프트웨어 업계의 패러다임이 멀티 코어로 발전되어 감에 따라 부수적으로 발생되는 문제들의 해결책이 함수형 프로그래밍의 패러다임과 잘 맞물려 있기 때문이리라 생각됩니다. 물론 중요한 이유이기도 하지만 단지 이 이유 하나만이었다면 일부러 함수형 프로그래밍을 배워야 한다는 취지의 글을 쓰지도 않았을 것입니다.
함수형 프로그래밍의 패러다임을 제대로 이해하면, 그 지식, 그 기술은 멀티코어에 대한 대처뿐만 아니라 폭넓고 다양한 분야에 도움이 될 것입니다. 특히 자신이 작성하는 코드의 품질을 크게 개선시킬 수 있습니다. 무엇보다도 참조 투명성(referential transparency)을 크게 향상시킬 수 있습니다. 참조 투명성이 높다는 뜻은 함수가 언제 어디서 호출되더라도 입력이 같으면 항상 얻는 결과도 같다는 의미입니다. 다시 말해, 함수의 결과가 상태변화에 의한 부작용에 좌우될 가능성이 적다(혹은 전혀 없다.)는 뜻입니다.
절차 지향 프로그래밍에서 자주 발생하는 오류의 원인 중 하나가 가변적인(mutable) 변수에 있습니다. 이 글을 읽는 독자라면 특정 변수의 값이 뜻대로 바뀌지 않아 그 이유를 조사해본 경험이 있을 것이라 생각됩니다. 가시성(visibility semantics)은 이처럼 눈에 띄지 않는 오류를 줄이는 데 도움이 되고, 오류가 발생한 곳을 특정하는 데에도 도움이 됩니다. 하지만 애초에 문제는 변수의 값이 변하도록 허용한 설계에 있습니다. 이러한 설계를 막기 위한 예는 업계 전체를 살펴봐도 참고할만한 것이 눈에 띄지 않는 것이 현실입니다. 객체지향 언어 입문서를 봐도 변수의 값이 변하는 설계를 암묵적으로 조장하고 있습니다. 비교적 수명이 긴 객체들이 서로 값이나 상태를 바꾸는 메서드(mutator methods)를 줄줄이 호출하는 프로그램의 예시가 그림을 통해 설명되어 있습니다. 아주 위험한 예제입니다.
객체가 아닌, 역할 모형을 만든다는 원칙을 유념하여 테스트를 설계하면 불필요한 가변성은 설계 단계에서 배제할 수 있습니다. 중요한 점은 가변적인 멤버 변수를 참조하지 않도록 설계하는 것입니다. 작은 함수를 많이 만들어 각각 한정된 역할만 하도록 하는 것이 더 구체적인 방법입니다. 각각의 함수는 파라미터가 전달되면 작동하도록 설계하면 오류도 줄일 수 있고, 디버그도 간단히 할 수 있게 됩니다. 파라미터로 부적절한 값이 넘어오게 되면 해당 함수에서 오류가 발생하기 때문에 특정하기 쉬워지기 때문입니다. 이러한 설계가 아니라면 어디에서 어떻게 값이 부적절하게 바뀌었는지 한줄한줄 추측하며 추적해야 합니다. 이쯤 되면 참조 투명성이 높은 프로그램을 쓰는 것이 당연하게 느껴질 정도입니다.
물론 참조 투명성을 높이는 것이 모든 면에서 바람직하다고는 할 수 없습니다. 예를 들어 객체지향 시스템에서 이 스타일은 사용자 인터페이스 개발보다 도메인 모델 개발에서(즉, 협업이 비즈니스 규칙의 복잡성을 줄이는 경우) 더 나은 결과를 기대할 수 있습니다.
앞서 말했다시피 함수형 프로그래밍 패러다임을 마스터하면 그 교훈을 다른 영역에도 현명하게 적용해 나갈 수 있을 겁니다. 객체 지향 시스템에서도 이를 적용해 참조 투명성을 높일 수 있다면 아주 큰 이익으로 되돌아올 것입니다. 사실 일각에서는 함수형 프로그래밍과 객체 지향의 장점들은 서로를 상호 보완하는 음과 양의 관계라고 주장하기도 합니다.
by Pixabay.
[출처] プログラマが知るべき97のこと
[라이선스] 이 글은 [CC-by-3.0-US] 에 의해 라이선스 되었습니다.
'97가지이야기시리즈 > 프로그래머' 카테고리의 다른 글
사용자의 행동을 관찰하라 (당신은 사용자가 아니다) (0) | 2021.06.25 |
---|---|
분별 있는 행동 (0) | 2021.06.14 |
댓글