안녕하세요? 객체지향 이야기의 저자 전병선입니다.
많은 개발자들이 직면하고 있는 현재의 상황은 혼란스러움 그 자체입니다. 이 혼란의 시기에 여러분은 무엇을 공부하고 무엇을 준비해야 하나요? 이것을 결정하는 것은 결코 쉽지 않습니다.
저는 여러분들께 이 질문에 대한 해답을 제시하고자 이책을 썼습니다. 그 해답은 이들 기술의 혼란스러운 변화 속에서도 변하지 않는 것을 찾는 것입니다. 그리고 그것이 바로 "객체지향" 입니다.
이 책은 크게 두개의 이야기로 구분됩니다.
첫번째는 객체지향의 개념을 이야기합니다. 많은 개발자들이 이 개념이 너무 어렵다고 이야기합니다. 그래서 생활 속에서 찾을 수 있는 예를 들어 나름대로는 가장 쉽게 설명했습니다. UML 을 사용하여 보이지 않는 개념을 눈으로 볼 수 있게 했습니다.
C++, 자바, C#, VB.NET 언어에서 이 개념을 구현하는 방법을 제시했습니다. 이들 언어를 모두 사용한 것은 여러분에게 결코 또 다른 혼란스러움을 주기 위한 것이 아닙니다. 오히려 그 반대입니다. 아마 여러분은 이들 언어들이 모두 똑같은 방법으로 객체지향 개념을 구현하고 있는 것을 찾을 수 있을 것입니다.
결국 그 기반이 되는 개념이 같기 때문에 이들 언어들의 구현 방법도 같을 수 밖에 없는 것이지요. 서로에게는 약간의 차이점이 있습니다. 그 차이점만 알면 이들 언어를 모두 정복할 수 있는 것입니다.
두번째는 객체지향 개념을 활용한 기술들의 변천사를 이야기합니다. 윈도우 프로그래밍에서의 객체지향 개념의 도입, 너무나 객체지향적인 자바 언어에서의 객체지향 개념의 활용, COM/DCOM, CORBA, RMI, EJB 등 분산 객체 기술에서의 객체지향 개념의 실현, 그리고 마이크로소프트가 완성시킨 분산 객체 기술인 COM+ 와 닷넷 프레임웍.
이들 이야기를 자세히 설명하려한다면 도무지 책 한권으로는 역부족입니다. 이 책에서 이들 기술들을 빠르게 짚어나간 것은 결국 숲을 보자는 것입니다. 이들 기술들에서 객체지향 개념이 어떻게 적용되었는지를 살펴봄으로써 지금 우리가 단단히 다져놓아야 할 기초가 바로 객체지향 개념임을 깨닫게 하는데 목적이 있습니다.
그래서 앞으로 어떤 새로운 기술들이 나와 우리를 혼란스럽게 한다고 해도 결코 당황하거나 두려워 하지 않게 하는 것이 이야기의 목적입니다. 또한 여러분이 이책을 자세히 읽어본다면 COM/DCOM, CORBA, RMI, EJB 등의 분산 객체 기술 사이의 유사점을 발견할 수 있을 것입니다.
또 서로의 약간의 차이점도 발견할 수 있습니다. 또 다시 그 유사점과 차이점을 알면 우리는 어떤 기술이든 자유자재로 사용할 수 있게 되는 것이지요. 그것이 두번째 이야기의 목적입니다.
저는 의도적으로 객체지향 기술과 객체지향 모델링에 대해 세부적인 자세한 사항의 설명을 배제했습니다. 이들 기술의 세부 사항을 자세히 이야기한다면 오히려 이책을 읽는 사람들에게 커다란 혼란만을 가져다 줄 것이기 때문입니다.
분명히 사람이 이해하고 받아들일 수 있는 범위가 있습니다. 따라서 객체지향 개념의 추상화 원칙에 따라
필수적이고 중요한 사항의 이야기에만 집중하는 것이 이들을 이해하는데 보다 더 효과적이라고 생각했기 때문입니다.
하지만 그 기반이 되는 객체지향 개념에 대한 이야기는 그 어느 것보다도 상세하고 쉽게 설명하기 위해 최선을 다했습니다. 그것은 객체지향 개념에 대한 이해가 그것을 기반으로 하는 많은 기술들을 이해하는 열쇠가 되기 때문이라고 생각하기 때문입니다.
아무쪼록 "객체지향 이야기"가 여러분에게 커다란 도움이 되기를 바랍니다. 이 책을 읽는 중에 궁금한 사항이 있으면 제게 메일(bsjun9@kornet.net)을 주십시오. 여러분이 보다 편안하게 이해할 수 있도록 도와드리겠습니다.
감사합니다.
(2002년 4월 29일 알라딘에 보내신 작가 코멘트)
애자일의 등장과 함께 지속적인 통합은 중요한 이슈가 됐다. 지속적인 통합이란 개발 환경 안에서 코드를 통합하고 구축하며 테스트하는 것을 말한다. 그 후, 지속적인 통합은 지속적인 배포, 지속적인 인도 개념으로 확장되며, 생산에 배포할 수 있는 패키지나 아티팩트가 생성된다. 이 개념들이 적용된 자동화로 인해 새로운 기능에 대한 아이디어를 개념화하는 것에서부터 생산에 배포될 때까지의 시간이 대폭 단축된다. 여기까지는 아직 운영 관점에서 시스템을 바라본다.
개발 관점에서도 시스템을 구축하는 방법에 많은 변화가 있었다. 특히 최근의 핵심 키워드는 확실히 마이크로서비스다. 넷플릭스에서 이 아키텍처가 성공한 이후 전 세계로 급속히 확산됐다. 이전 SOA 아키텍처의 서비스보다 훨씬 작기 때문에 더 빠르고 테스트와 패키징, 배포하는 시간도 적게 걸린다.
마이크로서비스는 도커 컨테이너에 탑재돼 수송된다. 컨테이너는 설계된 기능을 제공하는 분리되고 불변적인 이미지로 API를 통해서만 접근할 수 있다. 그리고 마이크로서비스가 어떤 환경에서든 안정적으로 실행될 수 있게 한다. 더욱이 컨테이너는 환경 사이에 일관적인 신뢰성을 제공하고, 노력을 들이지 않고도 확장할 수 있으며, 실패 시에 만회할 수 있게 한다. 더 나아가 코드로 인프라를 구성할 수 있는 코드로서의 인프라(infrastructure as code)를 가능하게 하며, 결국 데브옵스가 추구하는 개발과 운영이 결합될 수 있는 기반이 된다.
따라서 지속적인 인도와 배포, 마이크로서비스, 도커 컨테이너 이 세 가지가 결합돼 개발자와 운영자가 각기 다른 목표로 인해 갈등하던 시대에서 개발자도 운영을 이해하고, 운영자도 개발을 이해하며, 같은 목표 하에 협력하는 데브옵스의 시대를 이끌어가게 되는 것이다.
이 책은 이러한 관점에서 형상 관리 도구로 자동 프로비저닝된 서버에 지속적으로 테스트 및 배포된 마이크로서비스를 불변적인 컨테이너로 패키징해 소프트웨어를 좀 더 효율적으로 설계하는 데 도움이 되는 다양한 기술을 설명한다. 전체 마이크로서비스 개발과 배포 라이프사이클에서 도커(Docker), 쿠버네티스(Kubernetes), 앤서블(Ansible), 우분투(Ubuntu), 도커 스웜(Docker Swarm), 도커 컴포즈(Docker Compose), 컨설(Consul), etcd, 레지스트레이터(Registrator), confd, 젠킨스(Jenkins) 등의 도구를 사용하는 방법을 체계적이고 실제적으로 설명한다. 아무쪼록 이 책을 통해 데브옵스를 실천적으로 수행하는 기반을 갖춰 실무에서 활용할 수 있기를 희망한다.
30년간의 소프트웨어 개발 경험 속에서 갖고 있는 하나의 신념은 '아키텍처가 튼튼한 시스템이 결국엔 성공한다.'는 것이다. 아키텍처가 튼튼한 시스템은 결합성이 적고 응집력이 강한 시스템이다. 이처럼 튼튼하게 아키텍처가 설계된 시스템을 구현하는 것은 결코 실패하지 않으며, 적어도 문제를 최소화할 수 있다. 업무 로직이 변경되는 경우라도 쉽게 대응할 수 있어 생명력이 긴 소프트웨어 시스템을 만들어낼 수 있다. 이러한 신념을 바탕으로 집필한 『CBD, What & How』(와우북스, 2008)와 『SOA, What & How』(와우북스, 2008)에서 각각 제시한 CBD와 SOA 방법론은 모두 튼튼한 아키텍처 설계를 강조하고 있다. 소프트웨어 아키텍처를 문서화하는 것은 아키텍트나 개발자들에게 어려운 작업일 수 있다. 그러나 소프트웨어 아키텍처를 올바르게 문서화하는 일은 다양한 관점을 갖고 있는 모든 이해당사자가 시스템의 소프트웨어에 대해 같은 이해를 공유하게 한다는 점에서 아주 중요하다.
이 책은 초판의 연장선상에 있으면서도 문서화 체계를 변경시켰다. 뷰 타입과 스타일, 뷰로 구분하던 것을 스타일과 뷰로 간결하게 바꾼 것이다. 이것은 『소프트웨어 아키텍처 이론과 실제, 개정 3판』(에이콘, 2015, 전병선 역)을 반영한 결과다. 이 책에서 설명한 소프트웨어 아키텍처 문서화 방법론의 이름은 뷰와 그 너머(View and Beyond)다. 특별히 이번 판은 근래에 많이 적용하고 있는 애자일 개발 프로젝트에서의 아키텍처 문서화 방법도 함께 설명하고 있다. 이 책에서 뷰와 그 너머 방법론과 애자일 철학은 중심점에서 완전히 일치한다고 단정한다. 즉, 정보가 필요 없다면 문서화하지 않는다는 것이다. 많은 애자일 프로젝트에서 소프트웨어 아키텍처 문서화를 무시하는 경향이 있지만, 이 책을 읽고 여러분은 애자일 프로젝트에서도 소프트웨어 아키텍처 문서화가 필요하다는 것을 깨닫게 될 것이다. 특별히 이번 판에서는 U ML을 사용해 소프트웨어 아키텍처의 다양한 뷰를 표현하는 방법도 포함하고 있으며, 웹 기반의 서비스지향 시스템을 문서화하는 예제도 제공한다.
30년 가까운 소프트웨어 개발 경험 속에서 갖고 있는 하나의 신념은 '아키텍처가 튼튼한 시스템이 결국엔 성공한다'는 것이다. 아키텍처가 튼튼한 시스템은 결합성이 적고 응집력이 강한 시스템이다. 아키텍처가 튼튼하게 설계된 시스템을 구현하면 결코 실패하지 않으며, 적어도 문제를 최소화할 수 있다. 또한 업무 로직이 변경되는 경우라도 쉽게 대응할 수 있어 생명력이 긴 소프트웨어 시스템을 만들어낼 수 있다. 이러한 신념은 이 책의 2판을 읽고 나서 더욱 커졌다. 그 이후로 내가 집필한 『CBD, What & How』(와우북스, 2008)와 『SOA, What & How』(와우북스, 2008)에서 각각 제시한 CBD와 SOA 방법론은 모두 튼튼한 아키텍처 설계를 강조하고 있다.
이 책은 2판에 비해 더 체계적인 내용을 담고 있다. 핵심 개념인 품질 속성에 대해 좀 더 상세하게 설명하고 있으며, 소프트웨어 개발 라이프사이클에서 아키텍처의 역할과 해야 할 일에 대해 단계적으로 설명한다. 특히 애자일 접근 방법에서 아키텍처의 역할을 설명한 장은 애자일 방식을 따르는 사람들이 반드시 이해해야 할 좋은 내용을 담고 있다.
개발자들을 위해 이 책을 해설하는 가칭 『개발자를 위한 소프트웨어 아키텍처 해설』을 집필하고 있던 중에 출판사로부터 이 책의 번역을 의뢰 받았다. 이 책의 번역본이 빨리 출간되었으면 하는 바람을 갖고 있던 터라 흔쾌히 수락하고 번역에 착수했다. 이 책의 번역이 어쩌면 내 인생에서 가장 힘들고 보람된 작업이 아니었나 싶다. 이미 이 책을 읽으면서 정리해둔 것이 있어서 가능한 일이긴 했지만, 그래도 평균적으로 하루 20쪽 이상을 번역하는 작업은 그렇게 녹록한 일이 아니었다. 하지만 덕분에 이 책을 처음부터 끝까지 빠짐없이 읽을 수 있었기에 더할 나위 없이 보람된 작업이었다.
이미 여러 책을 집필하고 번역했기 때문에 책을 쓰고 번역하는 일이 낯설지 않았지만, 그래도 이 책을 번역하면서 어려움이 많았다. 사실 이 책이 소프트웨어 엔지니어링을 공부하는 사람들에게는 교과서와 같은 책이어서, 실무뿐만 아니라 학문적으로도 손색이 없도록 번역해야 한다는 부담감이 있었다. 그럼에도 불구하고 이 책의 번역이 실무자를 향해 있음은 부인할 수 없다. 이 책의 번역 용어는 가능한 한 실무를 반영해 선택했으며, 옮긴이 주석은 이 책을 읽는 데 이해하기 쉽도록 도움을 주는 정도로만 한정했다. 실무 개발자들에게 좀 더 쉬운 해설을 제공하기 위해 향후 『개발자를 위한 소프트웨어 아키텍처 해설』 책을 집필할 계획이다.
