추가 적립 안내

당신의 코드는 레거시인가?
오늘도 레거시가 될 코드를 작성했나?
레거시가 코드의 진정한 운명인가?
레거시가 아닌 소프트웨어 자산이 되는 코드와 설계!

개발자는 책으로 공부한다.
인기 있는 책들은 이상적인 모델을 설명한다.
그들은 실제 대규모 시스템을 운영하고 있지 않다.
진짜 대규모 시스템을 30여 년 가까이 운영하는 저자의 설계론!

당신이 오늘 작성하는 코드는 레거시이고, 내일 작성하는 코드는 모던 코드인가? 차세대 프로젝트가 나오면 사라져야 하는 레거시 코드인가? 소모적인 코드 갈아엎기 대신 소프트웨어 자산으로 축적하고 성장하는 방법은 없을까?
개발자는 책으로 공부한다. 책에서 설명하는 이론적인 방법을 신봉하고야 만다. 그러나 소프트웨어는 복잡하다. 복잡한 현실 세계를 소프트웨어로 담아내다 보면 이상적인 이론은 무너지고 만다. 이론을 넘어 물리적인 세계에 실제로 적용할 수 있는 아키텍처를 배워보자.

대규모 소프트웨어의 복잡성에 대응하기 위한 절차와 아키텍처

대규모 소프트웨어 프로젝트를 위한 아키텍처 원칙
신뢰성과 유지보수성을 갖춘 코드를 작성하는 일은 어렵다. 대규모 소프트웨어 개발이라면 더 많은 도전 과제가 주어진다. 대규모 시스템을 만들려면 대부분의 인기 있는 교재에서 다루는 이론적 개념을 넘어 논리적 디자인에 대한 실용적인 이해가 필요하다. 기업 규모에서 성공적이려면 개발자 또는 고급 개발자에게조차 생소할 수 있는 소프트웨어 엔지니어링의 물리적 디자인도 다뤄야 한다.
기업의 생존을 책임지는 대규모, 미션 크리티컬한 엔터프라이즈 시스템을 30년 이상 현장에서 구축하면서 쌓은 실무 경험을 기반으로 저자, 존 레이코스는 소프트웨어 자본을 만들고 성장시키는 방법을 보여준다. 이 책은 어떤 규모의 프로젝트라도 적용 가능한 기초를 구축하고, 성공적인 현실 세계 대규모 개발에 필요한 절차, 방법, 기술 및 도구를 보여준다.
23년만의 개정을 통해 최신 정보를 반영했다. 견고한 엔지니어링을 강조하면서 구체적인 예제와 기본 디자인 개념을 설명한다. 어떤 경험 수준의 개발자라도 다음과 같은 방법을 이해함으로써 디자인 및 개발 접근 방식을 혁신적으로 변화시킬 수 있는 인사이트를 얻을 수 있을 것이다.

ㆍ 인프라 및 응용 프로그램 개발 간의 차이를 활용하여 생산성 향상
ㆍ 피드백 및 계층적 재사용을 통한 기하급수적인 생산성 향상 달성
ㆍ 컴포넌트를 논리 및 물리적 디자인의 기본 단위로 받아들이기
ㆍ 컴파일 및 링크의 기본적인 특성이 컴포넌트 디자인에 어떻게 영향을 미치는지 분석
ㆍ 적절한 크기의 물리적 집합에 논리적 콘텐츠를 효과적으로 분할하기
ㆍ 충분한, 완전한, 최소한의 및 기본 소프트웨어 간의 중요한 차이를 내재화
ㆍ 캡슐화, 안정성 및 성능을 동시에 최적화하는 솔루션 제공
ㆍ 주기적인 물리적 종속성을 피하기 위해 아홉 가지 수립된 수준화 기법 활용
ㆍ 전통적인 계층 구조의 "무거움"을 피하기 위해 적절한 측면 설계 사용
ㆍ 컴파일 타임 결합을 제거하기 위한 적절한 아키텍처 격리 기법 사용
ㆍ 컴포넌트 기반 방법을 사용하여 대규모 시스템을 디자인하는 다차원 프로세스를 숙달하기

이 책에서 다루는 원칙과 아키텍처는 언어에 특화되지 않고 대규모 소프트웨어 시스템을 개발하면서 발생할 수 있는 공통적인 문제에 대한 해결책을 제시한다. C++에 중점을 둔 책이지만, 자바, 파이썬 등 다른 언어의 개발자들도 대규모 소프트웨어 프로젝트에서의 아키텍처 설계와 절차에 대한 이해를 향상시키는 데 도움을 받을 수 있을 것이다.

[역자 서문]
10여 명에서 2,000여 명에 이르는 다양한 규모의 소프트웨어 개발 조직에서 개발자로 또는 관리자로 일을 해오고 있습니다. 수십 또는 수백 명 수준의 서드 파티 업체에 외주 과제를 주기도 하고 사내 해외 연구소와 개발 업무를 나눠서 해보기도 했습니다. 업종 또한 반도체 장비, 웹 솔루션에서부터 일반 소비자용 전자제품까지 다양했습니다.
한 가지 공통된 현상으로, 개발자가 늘어날수록 조직의 커지는 기대와 달리 생산성은 오히려 떨어지는 문제가 있었습니다. 경험적으로 개발자가 20~30여 명을 넘어가면 뭔가 다른 법칙이 적용되기 시작합니다. 개발자가 많아진 만큼 더 많은 기능과 더 복잡한 소프트웨어를 개발할 수 있어야 하는데, 이상하게도 일상적인 유지보수만으로도 벅차기 시작합니다. 며칠이면 충분했을 작업이 몇 주씩 걸리기 시작하고, QA를 아무리 거쳐도 비슷한 고객 문제가 반복해서 발생합니다. 소모적인 야근과 휴일 근무에 지쳐가는 것뿐만 아니라 개발자들 간의 책임소재 갈등도 심화됩니다. 그리고 많은 개발자가 투입되는 큰 과제는 기획하는 것 자체가 무서워집니다.
이런 고민들을 하고 있을 때 이 책의 저자인 존 레이코스를 CppCon 세미나로 처음 만났습니다. 아쉽게도 세미나로 전달된 내용은 당연하고 좋은 말만 있을 뿐 그의 유명세에 비해 알맹이가 부족했습니다. 한동안 잊고 지내다가 나중에 그의 저서, 바로 이 책을 보고 생각이 완전히 달라졌습니다. 왜 한 시간짜리 세미나에서는 그 정도로밖에 얘기될 수 없었는지 이해되었습니다. 수십 년에 걸친 경험과 고민, 실전 대책을 각각의 구체적인 배경 맥락 아래에서 코드 수준으로 음미해야만 전달할 수 있는 내용들이었습니다.
이 책은 월스트리트 금융 소프트웨어 개발의 실전 경험을 바탕으로 합니다. 금융 상품의 빠른 변화에 대응하면서도 천문학적인 금융거래에 요구되는 고도의 신뢰성을 갖추고, 금융사 간 경쟁을 위한 최고 성능까지 필요한 터프한 환경에서의 경험이 담겨 있습니다. 저자의 스타일상 다소 호흡이 긴 문장과 중언부언이 있지만, 20여 년이 넘는 경험을 체계적으로 정리했다는 것은 이 책의 가장 큰 강점입니다. 이론적인 이상향만 다루는 여타의 소프트웨어 디자인 서적에서 목마름을 느꼈다면 이 책은 시원한 사이다입니다.
이 책은 개발자와 팀이 협업하는 방법, 논리적 설계와 물리적 코드 배치의 유기적 연계, 그렇게 해야 하는 내재된 원리, 그리고 언젠가 ‘버리고 싶은 레거시 코드’가 아니라 든든한 소프트웨어 자산을 쌓아가는 방법에 대해 자세히 다루고 있습니다. 이 책을 10년 전에 접했다면 개발자로서의 인생이 꽤 다르게 흘렀을 것이라고 믿습니다.
이제 소프트웨어 개발에 발을 들인 초심자라면 이 책을 통해 소프트웨어 디자인과 협업 방법에 대한 통찰을 얻을 수 있을 것이며, 현업에서 대규모 개발에 어려움을 겪고 있는 개발자나 관리자라면 이 책이 장기적인 돌파구에 대한 구체적인 실마리를 제공해 줄 것으로 기대합니다.

0장 동기
__0.1 목표: 더 빨리, 더 좋게, 더 싸게!
__0.2 애플리케이션 vs 라이브러리
__0.3 뒤엉킨 협업 vs 재사용 가능한 소프트웨어
__0.4 계층적 재사용 소프트웨어
__0.5 소프트웨어의 가변성 vs 안정성
__0.6 물리적 설계의 핵심 역할
__0.7 물리적으로 균일한 소프트웨어: 컴포넌트
__0.8 계층적 재사용의 정량화: 비유
__0.9 소프트웨어 자산
__0.10 투자의 확대
__0.11 주의/경계의 필요성
__0.12 요약

1장 컴파일러, 링커 그리고 컴포넌트
__1.1 아는 것이 힘이다: “악마는 디테일에 있다”
__1.2 C++ 컴파일과 링킹
__1.3 선언, 정의, 링키지
__1.4 헤더 파일
__1.5 인클루드 지시자와 인클루드 가드
__1.6 단순한 .h/.cpp 쌍에서 컴포넌트로
__1.7 표기법과 용어
__1.8 종속 관계
__1.9 암시된 종속성
__1.10 계층 번호
__1.11 실제 종속성 추출
__1.12 요약

2장 패키징과 설계 규칙
__2.1 큰 그림
__2.2 물리적 연합
__2.3 논리적/물리적 일관성
__2.4 논리적 이름, 물리적 이름의 응집성
__2.5 컴포넌트 소스 코드의 조직화
__2.6 컴포넌트 설계 규칙
__2.7 컴포넌트 private 클래스와 하위 컴포넌트
__2.8 패키지
__2.9 패키지 그룹
__2.10 패키지와 패키지 그룹의 네이밍
__2.11 부속 패키지
__2.12 레거시, 오픈 소스, 서드 파티 소프트웨어
__2.13 애플리케이션
__2.14 계층적 테스트 가능성
__2.15 개발에서 배포까지
__2.16 메타데이터
__2.17 요약

3장 물리적 설계와 인수분해
__3.1 물리적으로 생각하기
__3.2 부실한 물리적 모듈화 피하기
__3.3 논리적으로 묶인 것을 물리적으로 묶기
__3.4 링크 타임 순환 종속성 피하기
__3.5 계층화 테크닉
__3.6 과도한 링크 타임 종속성 피하기
__3.7 수평적 아키텍처와 수직적 아키텍처(레이어링)
__3.8 부적절한 링크 타임 종속성 피하기
__3.9 물리적 상호운용성의 확보
__3.10 불필요한 컴파일 타임 종속성 피하기
__3.11 아키텍처적 격리 테크닉
__3.12 컴포넌트 기반 설계
__3.13 요약
__3.14 결론

부록 퀵 레퍼런스
A.1 정의
A.2 따름정리
A.3 설계 필수 요건
A.4 설계 규칙
A.5 가이드라인
A.6 관찰

쉽게 유지보수할 수 있는 대규모 소프트웨어 시스템은 저절로 만들어지지 않는다. 개발자 한 명이 자신만을 위해 사용하는 방법이, 많은 정합 작업이 수반되는 대규모 소프트웨어에서도 같은 효과가 있기를 기대하기는 어렵다. 이 책은 대규모 소프트웨어 개발을 위한 엔지니어링(engineering) 방법론 및 소프트웨어의 종류나 규모와 상관없이 공통적으로 적용할 수 있는 테크닉과 요령을 다룬다. 그러한 테크닉과 요령은 한 번 학습하고 나면 본능처럼 각인되어 추가적인 노력과 시간을 들이지 않아도 된다. 각인된 테크닉과 요령은 이해하고, 검증하고, 유지보수하기 쉬운 잘 조직화된 시스템을 만들어 내는 데 반복적으로 기여한다.
__26p

이제 소프트웨어 개발의 최종 결과물인 소프트웨어 자체를 생각해 보자. 시간이 지남에 따라 소프트웨어는 계속해서 커진다. 미래의 프로젝트에 기존 소프트웨어의 상당 부분을 재사용할 수 있다면 생산성을 무한정 높일 수 있다. 즉, 소프트웨어를 오래 개발할수록 새로운 요구 사항이 생겼을 때 그냥 가져다 쓰기만 하면 되는 경우가 많이 생긴다. 문제는 “소프트웨어를 어떻게 구조화해야 효과적으로 재사용할 수 있는가?”다.
__29p

애플리케이션 개발은 단편적이고 목적 지향적인 경우가 많다. 이 때문에 여러 애플리케이션을 개발하는 큰 조직에서는 중복 코드와 상호 의존적인 애플리케이션을 쉽게 볼 수 있다. 개별적으로 문제가 없지만 전체적인 코드 베이스는 엉망이 되기 때문에 코드를 수정하거나 새롭게 추가하는 일이 점점 더 어려워진다. 이러한 현상은 너무나 흔해서 디자인 패턴 분야에서 별도로 이름(Big Ball of Mud)을 붙였을 정도다.
코드 베이스에는 어떤 구조화된 구심점이 없음은 물론, 조직 전체에 이용될 것으로 계획된 코드임에도 너무 주관적으로 일반화되어 있거나, 특정 애플리케이션에 과도하게 종속적이다. 그러한 코드들에 의존해서는 마스터 코드를 빠르게 변경하는 일이 너무나 위험해진다. 그럼에도 속도가 사업의 성공에 핵심적인 경우가 많기 때문에 전통적인 리팩터링 관례나 인터페이스 설계 방법론 같은 것은 사치스러운 것으로 치부된다. 급하게 대충 작업하면 단기적으로는 필요한 애플리케이션을 만들 수 있겠지만 장기적으로는 심각한 유지보수 부담으로 돌아온다. 시간이 흐를수록 코드 베이스에 개선이 없는 것은 당연하고, 유지보수 비용이 감당할 수 없을 정도로 계속 불어난다.
__29p

재사용 가능한 소프트웨어는 애플리케이션을 개발했다고 해서 저절로 생기지 않는다. 애플리케이션의 좁은 관점과 짧은 개발 일정 때문에 여러 애플리케이션에 걸친 공용 부분을 분리하여 코드를 작성할 여유는 없다. 라이브러리 전담 개발자(참조: 0.10절)가 있으면 좋겠지만 그런 경우는 극히 드물다. 이러한 현상은 애플리케이션 개발자의 탓이 아닌 현실적인 경제적 압력 때문에 일어난다. 애플리케이션 개발팀의 성공 여부는 주어진 시간과 예산 범위에서 필요한 비즈니스 요구를 만족시킬 수 있느냐에 달려 있다. 코드 재사용 때문에 비즈니스 목표를 달성하지 못한다면 상을 받기는커녕 일자리 자체가 위태로워질 수 있다. 장기적으로 미래의 적기 시장에 대응하기 위해 애플리케이션 개발자가 자발적으로 본인의 고유 업무를 넘어서서 다른 모듈에서의 재사용을 고려한 일반화된 코드를 작성하는 일은 극히 드물다.
__31p

소프트웨어 엔지니어링이라는 용어는 사람들마다 다른 의미로 받아들인다. 재능 있고 열정적인 개발자는 소프트웨어를 창조하는 일을 예술이라 생각한다. 안타깝게도 이러한 개발자는 모두에게 이익이 되는 것이 분명한 것이라도 무언가 제약이 주어지면 숨막혀 한다. 하지만 이런 태도는 비정형적인 것을 산재하게 하고 소프트웨어 개발 과정 전반에 걸쳐 효율성을 해친다. 개인이 아닌 조직으로서 최고 수준의 생산성에 도달하려면 물리 법칙과 같은 어떤 기초 규칙을 지켜야 한다고 믿는다. 이 장의 내용은 이러한 믿음을 바탕으로 한다.
__254p

여기서 제안하는 것은 충분히 적은 수의 아키텍처 설계 규칙 집합이다. 이 규칙들은 컴포넌트 기반 소프트웨어를 조직화하기 위한 물리적 프레임워크를 구성한다. 물론 컴포넌트 기반이 아닌 레거시 모듈, 오픈 소스, 서드 파티 소프트웨어와 함께하는 방법도 포함한다. 이 규칙은 본격적인 기업 규모의 소프트웨어가 효과적인 설계, 개발, 테스트, 배포를 가능하게 한다. 단순한 네이밍 관례나 코딩 표준과 달리 이러한 아키텍처 차원의 규칙은 언어의 기능을 초월하여 개발 확장성과 효과적인 재사용에 무게를 두고 무엇이 중요한지에 집중한다. 여기서 제안하는 소프트웨어 조직화 방법론은 단지 그럴듯한 것이 아닌 오랜 기간 현업과 시장에서 검증되어 온 것이다.
__254p

애플리케이션 개발자들은 자연스럽게도 애플리케이션 중심적이다. 애플리케이션이 물리적 계층의 최상위라고 할 때 각 애플리케이션 개발자는 다른 애플리케이션과 완전히 독립적으로 자기만의 관점에서 개발할 수 있다. 하지만 큰 개발 조직에서는 많은 애플리케이션들이 동시에 개발될 때가 많다. 이러한 애플리케이션들은 결과적으로 많은 버전을 갖게 된다. 애플리케이션 개발을 관리하는 일관된 방법론의 프레임워크가 있으면 대규모 애플리케이션 개발에 큰 도움이 될 수 있다.
__385p

역사적으로 소프트웨어 설계는 논리적 설계에 국한되는 것으로 치부되어 왔다. 하지만 이 책의 컴포넌트 기반 방법론은 구조와 방향 차원(수직적, 수평적 모두)을 추가하여 물리적 설계라는 개념을 제시한다. 물리적 설계는 컴포넌트 간 상대적 위치에 의미를 부여한다. 인터페이스와 구현의 상대적인 물리적 위치를 교환하는 등의 물리적 설계 테크닉으로 더 유연하고 안정적인( 예 수평적) 설계를 달성할 수 있다.
__758p

테스트하기 어려운 시스템은 테스트가 덜 수행되고 신뢰성이 떨어질 수밖에 없다. 따라서 유지보수 작업이 더 많이 소요된다. 재사용될 소프트웨어가 재사용되지 못하고, 사용처가 적어 검증이 덜 되고 또다시 신뢰성이 떨어진다. 재사용이 덜 된다는 것은 중복 코드가 많다는 뜻이기도 하다. 따라서 불필요한 유지보수 부담을 발생시킨다. 같은 작업을 하는 데 코드가 더 많다는 것은 실행 파일의 크기가 크다는 뜻이고, 그에 따라 캐싱에 불리해지는 등 런타임 성능에도 악영향을 미친다. 마지막으로 낮아진 수정 용이성은 무언가를 바꾸는 데 비용이 더 많이 듦을 의미한다.
__769p