IT/모바일
제공 : 한빛 네트워크
저자 : chromatic
역자 : 임성진
원문 : Artificial Complexity and Internet Applications
다양한 언어를 사용하는 프로그래머
프로그래밍을 한 25년 동안, 나는 24개의 프로그래밍 언어를 사용해왔다 -- 아마도 10개에서 20개 정도는 매우 중요한 프로그램을 작성하기 위한 것이었다. (나는 Perl 6와 Parrot 작업의 일부로 최소한 10개 언어를 사용했던 적도 있었다. 대부분의 Parrot 작업에는 대개 두 세 개의 언어를 사용한다.) 또한 나는 중요한 프로젝트에 여러 마크업 언어를 사용하기도 했다.
훌륭한 프로그래머는 결국 다양한 언어를 사용하는 프로그래머로 되는 것 같다. ‘실용주의 프로그래머’ 책에서는 해마다 새로운 언어를 배우길 권한다. 새로운 언어를 배우게 됨으로써 여러분은 다른 문법과 패러다임으로 안목을 확장할 수 있으며, 이는 다른 언어의 특징이 어떤 문제를 더 쉽게 해결하거나 어렵게 만들 수 있는지 확인해 볼 수 있는 아주 좋은 방법이기도 하다.
도메인의 언어
리스프(Lisp), 스킴(Scheme), 스몰토크(Smalltalk), 포스(Forth) 프로그래머들은 상향식(bottom-up) 프로그래밍 방식을 이야기하는데, 사실상 이 방식에서는 여러분이 문제 도메인을 기술하는 어휘(vocabulary)를 만들고, 그와 같은 어휘들을 재사용함으로써 문제를 해결한다. 비록 많은 개발자들이 도메인에 특화된 언어(domain-specific language)에 관해 굉장히 잘못 알고 있지만, 종종 성공적인 소프트웨어는 개체와 API를 비롯한 기타 소프트웨어 구조물의 이름에 문제 도메인에 특화된 언어를 사용할 것을 요구한다.
어떤 의미에서, 소프트웨어 개발은 공감마술과도 같다.
공감할 수 없고 어려운 지식
HTML과 CSS에 관해 생각해 보자. 그것들은 문서의 의미 요소를 기술할 의도로 만들어진 선언적인 언어다. CSS를 기술하면 라인은 더 모호해지는데, HTML과 XML의 확장가능한 특성을 이용하면 어느 정도의 맞춤화(customization)가 가능해져 더욱 의미적인 설명을 덧붙일 수 있다(마이크로포맷 참조). 하지만 실수하지 않도록 조심해야 한다. 이것들은 문서와 형식을 기술하기 위해 설계된 언어이다. 여러분이 소방차를 판매하는 사업을 하고 있다면, 여러분은 소방차 차체와 차대, 색상, 사이렌, 모델, 엔진에 대한 관련 도메인 개념을 추가해야 한다.
이미 여러분이 이러한 개념들을 비즈니스 로직에서 표현하고 있다면 나쁘진 않은 편이다.
웹 애플리케이션이라면 이러한 개념들을 기술하고, 종종 SQL과 DDL을 통해 생성하고 유지하기도 하는 관계형 데이터 저장소가 마련되어 있을 것이다. 여러분에게는 몇몇 대중적인 현대적인 언어를 통해 이러한 개념들을 다시 한번 클래스 및 객체의 형태로 기술하는 비즈니스 객체도 있을 것이다. 여러분에게는 HTML과 CSS, 또는 XML과 XSLT을 생성하는 템플릿 시스템도 있으며, 이들을 이용하면 그와 같은 개념들을 조작할 수도 있다. 여러분은 자바스크립트를 다뤄야 할 수도 있는데, 적어도 표현 계층에서는 이러한 업무 개념(business concepts)들을 다시금 어느 정도 이해하고 표현할 필요가 있다.
그것은 세 개의 프로그래밍 언어와 최소한 두 개의 마크업 언어이다.
복잡성은 어디에나 있는 정교한 함정이다
전 세계적인 수준의 문서 기반 분산 컴퓨팅인 HTTP 모델은 자체적인 한계를 극복하는 무한한 이점을 제공한다. 이와 비슷한 방식으로 관계형 모델은 특히 여러 애플리케이션에서 동일한 저장소를 공유할 경우 데이터 저장과 조회에 있어 여러 이점을 제공해 준다. 또한 소프트웨어 개발에서 가장 힘들게 얻게 되는 교훈 중 하나는 바로 관심사의 분리가 한결 더 좋은 생각이라는 것이다. 비즈니스 룰(business rule)과 표현 로직은 별개의 것이다.
그런데 이러한 분리가 너무 지나치게 적용된 것 같다. 아마도 HTTP/REST 모델의 이점을 활용하려는 가운데, 이처럼 곧 무너질 것만 같은 탑의 각 계층들이 마구 뒤섞여 우리가 제시하는 해법을 압도할 것처럼 보일 때까지 우리가 언어 위에 언어를, 패러다임 위에 또 패러다임을 쌓아 올려 시스템의 인공적인 복잡성이 점차 늘어나게 된 것 같다.
나는 우리가 다시 한 가지 언어만을 사용해야 한다고 주장하는 것은 아니다. 오히려 그 반대다! 다만 나는 의아할 따름이다. 현재 웹 애플리케이션을 구축하는 모델은 충분히 단순한가? 아니면 더 낫고, 더 신뢰성 있으며, 더 안정적이고, 더 정확하며, 더 쉽게 구축하고 유지 보수할 수 있는 시스템으로 돌아가고 있는 것인가?
저자 : chromatic
역자 : 임성진
원문 : Artificial Complexity and Internet Applications
다양한 언어를 사용하는 프로그래머
프로그래밍을 한 25년 동안, 나는 24개의 프로그래밍 언어를 사용해왔다 -- 아마도 10개에서 20개 정도는 매우 중요한 프로그램을 작성하기 위한 것이었다. (나는 Perl 6와 Parrot 작업의 일부로 최소한 10개 언어를 사용했던 적도 있었다. 대부분의 Parrot 작업에는 대개 두 세 개의 언어를 사용한다.) 또한 나는 중요한 프로젝트에 여러 마크업 언어를 사용하기도 했다.
훌륭한 프로그래머는 결국 다양한 언어를 사용하는 프로그래머로 되는 것 같다. ‘실용주의 프로그래머’ 책에서는 해마다 새로운 언어를 배우길 권한다. 새로운 언어를 배우게 됨으로써 여러분은 다른 문법과 패러다임으로 안목을 확장할 수 있으며, 이는 다른 언어의 특징이 어떤 문제를 더 쉽게 해결하거나 어렵게 만들 수 있는지 확인해 볼 수 있는 아주 좋은 방법이기도 하다.
도메인의 언어
리스프(Lisp), 스킴(Scheme), 스몰토크(Smalltalk), 포스(Forth) 프로그래머들은 상향식(bottom-up) 프로그래밍 방식을 이야기하는데, 사실상 이 방식에서는 여러분이 문제 도메인을 기술하는 어휘(vocabulary)를 만들고, 그와 같은 어휘들을 재사용함으로써 문제를 해결한다. 비록 많은 개발자들이 도메인에 특화된 언어(domain-specific language)에 관해 굉장히 잘못 알고 있지만, 종종 성공적인 소프트웨어는 개체와 API를 비롯한 기타 소프트웨어 구조물의 이름에 문제 도메인에 특화된 언어를 사용할 것을 요구한다.
어떤 의미에서, 소프트웨어 개발은 공감마술과도 같다.
공감할 수 없고 어려운 지식
HTML과 CSS에 관해 생각해 보자. 그것들은 문서의 의미 요소를 기술할 의도로 만들어진 선언적인 언어다. CSS를 기술하면 라인은 더 모호해지는데, HTML과 XML의 확장가능한 특성을 이용하면 어느 정도의 맞춤화(customization)가 가능해져 더욱 의미적인 설명을 덧붙일 수 있다(마이크로포맷 참조). 하지만 실수하지 않도록 조심해야 한다. 이것들은 문서와 형식을 기술하기 위해 설계된 언어이다. 여러분이 소방차를 판매하는 사업을 하고 있다면, 여러분은 소방차 차체와 차대, 색상, 사이렌, 모델, 엔진에 대한 관련 도메인 개념을 추가해야 한다.
이미 여러분이 이러한 개념들을 비즈니스 로직에서 표현하고 있다면 나쁘진 않은 편이다.
웹 애플리케이션이라면 이러한 개념들을 기술하고, 종종 SQL과 DDL을 통해 생성하고 유지하기도 하는 관계형 데이터 저장소가 마련되어 있을 것이다. 여러분에게는 몇몇 대중적인 현대적인 언어를 통해 이러한 개념들을 다시 한번 클래스 및 객체의 형태로 기술하는 비즈니스 객체도 있을 것이다. 여러분에게는 HTML과 CSS, 또는 XML과 XSLT을 생성하는 템플릿 시스템도 있으며, 이들을 이용하면 그와 같은 개념들을 조작할 수도 있다. 여러분은 자바스크립트를 다뤄야 할 수도 있는데, 적어도 표현 계층에서는 이러한 업무 개념(business concepts)들을 다시금 어느 정도 이해하고 표현할 필요가 있다.
그것은 세 개의 프로그래밍 언어와 최소한 두 개의 마크업 언어이다.
복잡성은 어디에나 있는 정교한 함정이다
전 세계적인 수준의 문서 기반 분산 컴퓨팅인 HTTP 모델은 자체적인 한계를 극복하는 무한한 이점을 제공한다. 이와 비슷한 방식으로 관계형 모델은 특히 여러 애플리케이션에서 동일한 저장소를 공유할 경우 데이터 저장과 조회에 있어 여러 이점을 제공해 준다. 또한 소프트웨어 개발에서 가장 힘들게 얻게 되는 교훈 중 하나는 바로 관심사의 분리가 한결 더 좋은 생각이라는 것이다. 비즈니스 룰(business rule)과 표현 로직은 별개의 것이다.
그런데 이러한 분리가 너무 지나치게 적용된 것 같다. 아마도 HTTP/REST 모델의 이점을 활용하려는 가운데, 이처럼 곧 무너질 것만 같은 탑의 각 계층들이 마구 뒤섞여 우리가 제시하는 해법을 압도할 것처럼 보일 때까지 우리가 언어 위에 언어를, 패러다임 위에 또 패러다임을 쌓아 올려 시스템의 인공적인 복잡성이 점차 늘어나게 된 것 같다.
나는 우리가 다시 한 가지 언어만을 사용해야 한다고 주장하는 것은 아니다. 오히려 그 반대다! 다만 나는 의아할 따름이다. 현재 웹 애플리케이션을 구축하는 모델은 충분히 단순한가? 아니면 더 낫고, 더 신뢰성 있으며, 더 안정적이고, 더 정확하며, 더 쉽게 구축하고 유지 보수할 수 있는 시스템으로 돌아가고 있는 것인가?
TAG :
이전 글 : OS X가 Windows보다 안전한가?
다음 글 : 페도라 10: 업그레이드하기에는 아직 무리
최신 콘텐츠