12장 대규모 시스템의 설계와 개선

[fkdl0048]

1. 대규모 시스템의 설계와 개선

• 핵심 주제
  • 설계에 대한 여러 가지 결정이 코드베이스의 이해도에 미치는 영향
  • 설계에 대한 여러 가지 결정 사이의 트레이드 오프
  • 더 나은 인지 처리를 위한 기존 코드베이스 설계의 개선

라이브러리, 프레임워크, 모듈에 대해 이야기할 때, 우리는 그것들이 작성된 프로그래밍 언어와 같은 기술적 측면에 대해 이야기 한다.

그러나 코드베이스를 인지적 관점을 통해서도 볼 수 있다.

이 장에서는 인지적 관점에서 코드베이스를 조사하는 기술인 CDN에 대해 논할 것이다.

CDN은 기존의 코드베이스에 대해"이 코드를 사람들이 쉽게 변경할 수 있는가?" 혹은 "이 코드베이스에서 정보를 쉽게 찾을 수 있는가?"와 같은 질문에 답을 찾는 데 도움이 된다.

기술적 관점보다는 인지적 관점에서 코드베이스를 검사하면 사람들이 코드와 어떻게 상호작용하는지 더 잘 알 수 있다.

1.1. 12.1 코드베이스의 특성 조사

프로그래밍 언어를 논할 때, 우리는 종종 기술적 영역, 예를 들어 패러다임(객체 지향, 함수형, 또는 혼합), 타입 시스템 여부, 언어가 바이트 코드로 컴파일 되는지 또는 다른 언어로 된 프로그램에 의해 인터프리터되는지 살펴본다.

언어, 프레임워크, 라이브러리를 실행하는 환경도 확인하곤 한다.

브라우저 또는 가상 머신에서 실행되는가?

이러한 모든 측면은 기술적 영역, 즉 프로그래밍 언어가 할 수 있는 것에 관한 사항이다.

1.1.1. 12.1.1 인지적 차원

CDN을 이 책에서는 좀 더 일반화하여 프로그래밍 언어가 아닌 코드베이스에 대해서도 CDN을 사용하려고 한다.

이 일반화된 버전을 코드베이스의 인지 차원(CDCB)이라고 부르고, 이것을 통해 코드베이스를 검토하고, 코드베이스를 어떻게 이해하고 개선할 수 있을지 살펴볼 것이다.

1.1.1.1. 오류 경향성

첫 번째 차원은 오류 경향성이라고 불린다.

자바 스크립트 및 기타 동적 유형 언어에서는 변수가 생성될 때 데이터 타입이 정해지지 않는다.

런타임에 객체의 타입이 명확하지 않기 때문에, 프로그래머는 변수의 타입에 대해 혼동할 수 있고 이로 인해 오류가 발생할 수 있다.

프로그래밍 언어가 아닌 코드베이스 역시 오류 경향성이 있는데, 예를 들어 일관성 없는 규칙, 문서 부족, 모호한 이름 때문이다.

1.1.1.2. 일관성

일관성은 비슷한 것들은 서로 얼마나 유사한가? 를 말하며, 예로는 이름은 항상 동일한 방식으로 만들어지는가? 를 들 수 있다.

많은 프로그래밍 언어에서 일관성이 있는지 알 수 있는 방법은 함수 정의가 있다.

이런 생각을 해본 적이 없겠지만 내장 함수는 일반적으로 사용자 정의 함수와 동일한 사용자 인터페이스를 가지고 있다.

이름과 규약을 일관성 없이 사용하는 프레임워크나 언어는 인지 부하를 더 많이 가져올 수 있다.

1.1.1.3. 분상성

너무 많은 라인으로 작성되어 있는 긴 메서드는 앞에서 코드 스멜이라는 말로 다뤘다.

메서드를 불필요하게 복잡하게 만들거나 한 메서드에 너무 많은 기능을 쑤셔넣는다면 이는 프로그래머의 잘못일 수 있다.

그러나 일부 프로그래밍 언어는 동일한 기능에 대해 다른 프로그래밍 언어보다 더 많은 공간을 차지한다.

분산성 차원은 이에 대한 것이다.

c++과 파이썬의 반복문을 비교하면 길이도 파이썬이 더 짧고 청크도 파이썬이 더 적다.

1.1.1.4. 숨겨진 의존성

숨겨진 의존성차원은 의존 항목이 사용자에게 어느 정도로 가시적으로 나타나는지를 보여준다.

숨겨진 의존성이 높은 시스템의 예를 들자면 HTML 페이지에 자바스크립트로 제어되는 버튼이 있고 자바스크립트는 다른 파일에 저장되어 있는 경우다.

일반적으로, 다른 함수나 클래스 안에서 어떤 함수가 호출되는지 아는 것과 그 반대의 경우, 즉 주어진 함수를 어떤 클래스나 함수가 호출하는지 아는 것 중에서 전자가 후자보다 더 쉽다.

1.1.1.5. 잠정성

잠정성 차원은 도구를 사용하는 동안 생각하는 것이 얼마나 쉬운지에 대한 것이다.

자신이 무엇을 만들고 있는지 확신하지 못하면 탐구적인 방식으로 프로그래밍을 하게 된다.

코드베이스나 프로그래밍 언어가 매우 엄격하다면 코드를 사용해 생각을 표현하는 것은 어려울 수 있다.

이런 경우 잠정성이 낮다고 말한다.

1.1.1.6. 점도

점도는 특정 시스템을 변경하는 것이 얼마나 어려운가에 대한 차원으로, 잠정성과 관련이 있다.

일반적으로 동작 타입 언어로 작성된 코드를 변경하는 것이 조금 더 쉽다.

코드만 변경하면 되고 모든 해당 타입 정의를 변경할 필요가 없다.

모듈로 이루어지지 않은 코드나 블록으로 된 코드는 직접 변경할 수 있고 함수나 클래스에서 변경할 필요가 없기 때문에 변경이 용이하다.

1.1.1.7. 점진적 평가

점진적 평가 역시 잠정성과 관련이 있다.

이 차원은 주어진 시스템에서 부분적인 작업을 확인하거나 실행하는 것이 얼마나 쉬운지에 대한 것이다.

우리가 살펴본 바와 같이, 잠정성이 높은 시스템은 사용자가 불완전한 아이디어를 스케치할 수 있는 것이 가능하다.

점진적 평가를 통해 사용자는 완성되지 않은 코드나 불완전한 코드를 실행할 수 있다.

1.1.1.8. 역할 표현력

역할 표현력의 차원은 프로그램에서 여러 가지 다른 부분의 역할을 얼마나 쉽게 알 수 있는지를 나타낸다.

역할 표현력의 간단한 예는 file.open()처럼 거의 모든 프로그래밍 언어에서 매개변수가 없는 함수를 호출할 때 여전히 끝에 두 개의 괄호를 가지고 있다는 점이다.

언어 설계자가 매개변수가 없는 함수의 경우 괄호를 생략해도 되게끔 만들 수도 있지만, 괄호가 있음으로 해서 open()이 함수임을 알 수 있다.

함수의 끝에 있는 괄호는 역할 표현력의 일례다.

1.1.1.9. 매핑 근접성

매핑 근접성 차원은 프로그래밍 언어 또는 코드가 문제의 해결 영역에 얼마나 가까운지를 의미한다.

어떤 프로그래밍 언어들은 매핑 근접성이 높다.

예를 들어, SQL은 데이터베이스를 다루는 언어이다.

APL은 수학에 근접성이 높고 현대의 언어들은 범용적 언어이기에 근접성이 낮다.

1.1.1.10. 힘든 정신 활동

어떤 시스템에서 사용자가 시스템의 외부에서 힘든 정신 활동을 수행할 때 생각하는 것이 매우 어려울 수 있다.

예를 들어 하스켈과 같은 언어는 사용자가 모든 함수와 매개변수의 타입을 고려해야 한다.

하스켈에서는 함수의 형식을 무시할 수 없는데 만일 무시하게 되면 실행되는 코드를 작성하는 것은 거의 불가능하다.

마찬가지로 C++는 사용자가 여러 상황에서 포인터를 사용해야 하고 객체보다는 포인터로 추론할 것을 요구한다.

물론 힘든 정신활동이 모두 나쁜 것만은 아니다.

생각하게 하는 것이 성과를 거둘 수도 있다.

예를 들면, 엄격한 타입 시스템에서는 오류 수가 적다던지 포인터를 사용하면 성능이 더 우수하거나 메모리 사용이 더 효율적이다.

1.1.1.11. 보조 표기법

보조 표기법 차원은 프로그래머가 공식 규격에는 없는 의미를 코드에 추가할 가능성을 타나낸다.

가장 일반적인 예로 소스 코드에 주석문을 추가할 가능성이다.

주석문은 프로그램의 동작을 변경하는 측면으로 보면 프로그래밍 언어의 일부가 아니다.

C#의 명명된 매개변수와 같음

1.1.1.12. 추상화

추상화 차원은 시스템의 사용자가 기본적으로 제공되는 추상화만큼 강력한 추상화를 만들 수 있는지 여부다.

대부분의 프로그래밍 언어가 허용하는 추상화의 예로는 함수, 객체, 클래스를 만드는 것이다.

1.1.1.13. 가시성

가시성은 시스템의 다른 부분을 얼마나 쉽게 볼 수 있는지를 나타낸다.

코드베이스가 어떤 클래스로 구성되어 있는지 확인하기 어려울 수 있는데, 특히 코드가 여러 파일로 나뉘어 있는 경우에는 더욱 그렇다.

1.1.2. 12.1.2 코드베이스 개선을 위해 CDCB 사용

지금까지 프로그램이 가질 수 있는 다양한 차원에 대해 살펴보았다.

이러한 차원의 차이는 사람들이 코드베이스와 상호작용하는 방식에 큰 영향을 미칠 수 있다.

예를 들어 코드베이스 점도가 높은 경우 코드베이스에서 작업하는 미래의 개발자는 변경을 꺼릴 수 있다.

이로 인해 코드베이스 구조가 크게 변경되기보다는 패치가 더해져서 코드가 점점 복잡해진다.

1.1.3. 12.1.3 설계 기둥 및 트레이드오프

코드베이스에서 특정 차원을 개선하기 위해 코드베이스를 변경하는 것을 설계 기둥이라고 한다.

예를 들어 코드베이스에 타입을 추가하는 것은 오류 경향성을 개선하기 위한 설계 기동이며, 함수 이름을 코드의 영역에 더 부합하도록 변경하는 것은 매핑 근접성을 개선하는 설계 기동이다.

1.1.3.1. 오류 경향성 vs 점도

라이브러리나 프레임워크의 사용자가 실수하지 않도록 하기 위해 사용자가 추가 정보를 입력하도록 하는 경우가 많다.

이와 같은 오류 경향성을 감소하기 위한 방법 중 가장 잘 알려진 예는 타입을 추가하는 것이다.

컴파일러가 어떤 개체의 타입을 알고 있다면 이 정보를 이용해서 문자열에 리스트를 추가하는 것과 같은 실수를 방지할 수 있다.

그러나 시스템의 모든 항목에 대해 타입을 추가하는 것은 사용자에게 추가 작업의 부담을 준다.

1.1.3.2. 점정성 및 점진적 평가 vs 오류 경향성

잠정성과 점진적 평가가 높은 시스템에서는 미완성되거나 불완전한 코드라도 스케치하고 실행할 수 있다.

이러한 차원은 당면한 문제에 대해 생각하는 데 도움이 될 수 있지만, 프로그램이 완성되지 않은 채 그대로 남아 있거나, 불완전한 프로그램이 개선되지 않은 채 남아 있어 이해하기 어렵고 이는 디버깅하기 어려운 코드로 이어져 오류 경향성에 영향을 미칠 수 있다.

1.1.3.3. 역할 표현력 vs 분산성

명명된 매개변수 같은 문법 요소를 추가하면 역할 표현력이 개선될 수 있다는 것과 추가적인 레이블로 인해 코드가 길어진다는 것은 변수의 역할을 나타내기도 하지만 코드베이스의 크기를 늘리는 타입 애너테이션도 마찬가지다.

1.2. 12.2 차원 및 활동

이전 장에서 다섯 가지 프로그래밍 활동 즉, 검색, 이해, 전사, 증가, 탐구에 대해 알아봤다.

각 활동은 코드베이스가 최적화해야 하는 인지 차원에 서로 다른 제약을 가한다.

1.2.1. 12.2.1 차원이 활동에 미치는 영향

1어떤 활동은 특정 차원이 높아야 하는 반면, 어떤 활동은 특정 차원이 낮을 때 가장 잘 작동한다.

1.2.1.1. 검색

검색할 때 일부 차원은 중요한 역할을 한다.

예를 들어 숨겨진 종속성은 검색 활동에 악영향을 미친다.

분산성은 코드를 더 길게 만들어 검색에 부정적인 영향을 준다.

반면 보조 표기법은 검색에 도움이 된다.

1.2.1.2. 이해

코드베이스의 가시성이 낮으면 클래스와 기능이 서로 어떻게 관련되는지 파악하기 어렵기 때문에 이해에 부정적인 영향을 준다.

반면 역할 표현력은 이해에 긍정적인 영향을 준다. (변수 및 기타 개체의 유형과 역할이 명확하다면 이해하기가 더 쉬워질 것이다.)

1.2.1.3. 전사

전사할 때 일관성 같은 일부 차원은 나빠질 수 있다.

일관된 코드베이스는 이해하기 쉽지만, 새로운 기능을 구현할 때는 코드베이스에 맞춰야 하므로 정신적 노력이 추가로 필요할 수 있다.

1.2.1.4. 증가

코드베이스에 새 기능을 추가할 때 가장 도움이 되는 것은 도메인에 대한 매핑 접근성이다.

코드베이스에서 프로그래밍 개념보다는 코드의 목표를 뚜렷이 알 수 있다면, 새로운 코드를 추가하는 것이 더 쉬울 것이다.

1.2.1.5. 탐구

새로운 설계 아이디어를 탐구할 때 가장 도움이 되는 차원은 잠정성과 점진적 평가이다.

힘든 정신 활동과 추상화하는 프로그래머에게는 높은 인지 부하를 유발하고 문제와 해결 공간을 탐구하는 데 사용되어야 할 부하를 제한하기에 탐구에 악영향을 미칠 수 있다.

1.2.2. 12.2.2 예상 활동에 대한 코드베이스 최적화

여러 다른 활동이 시스템에 서로 다른 제약을 가하는 것을 알아봤다.

따라서 코드베이스에 대해 다른 사람이 어떤 작업을 수행할지 이해하고 있어야 한다.(협업의 기본..!)

상대적으로 오래되고 안정적인 라이브러리는 증가 활동보다는 검색 활동이 더 많이 일어날 가능성이 높은 반면, 새로운 앱은 증가 및 전사 활동이 일어날 가능성이 더 높다.

즉 코드베이스가 유지되는 동안에는 코드베이스에 대해 일어날 가능성이 가장 높은 활동에 맞는 설계 기동이 필요할 수 있다.

1.3. 요약

• CDN은 프로그래밍 언어의 사용자들에게 미칠 인지적 영향을 예측하는 데 도움이 되는 프레임 워크이다.
• CDCB는 코드베이스, 라이브러리, 프레임워크가 사용자에게 미치는 영향을 이해하는데 도움이 되는 CDN의 확장이다.
• 대부분의 경우 서로 다른 차원 간의 트레이드오프가 이루어져야 한다. 한 차원을 개선하면 다른 차원이 감소할 수 있다.
• 설계 기동을 통해 프레임워크의 인지 차원에 따라 기존 코드베이스의 설계를 개선하는 것이 이뤄질 수 있다.
• 코드베이스가 최적화할 대상인 차원에 대한 요구 사항은 수행하려는 활동에 따라 다르다.