임베디드 월드 2021로 가는 길에서: 에피소드 4

편집자 주: 임베디드 월드 2021(Embedded World 2021)을 앞두고 마련된 블로그 시리즈(총 5편) 중 에피소드 1에서는 임베디드 월드를 간략히 소개했습니다. 에피소드 2에서는 Randall과 함께 C 프로그래밍 언어 지식을 살펴보았습니다. 에피소드 3에서는 객체 지향 프로그래밍을 사용하여 복잡성을 줄이는 방법에 대해 다뤘습니다. 이번 에피소드 4에서는 빌딩 블록을 다시 구현하지 않고도 변화하는 요구 사항에 따라 재구성할 수 있어야 본질적으로 우수한 설계로 인정받을 수 있는 이유를 알아봅니다. 마지막 블로그인 에피소드 5에서는 Randall의 임베디드 월드 2021 기조 발표에 앞서 운영 체제에 계속해서 더 많은 공간이 필요한지를 점검하고 시스템 분해에 관해 간략히 알아봅니다.

지금까지 소프트웨어가 현재의 객체 지향으로 발전해 온 과정과 객체 지향과 전자 기기의 유사점에 대해 말씀드렸습니다. 객체 지향의 관점에서 생각해 보면 실제 물건, 즉 객체의 대리 모델을 만들 수 있습니다. 객체 지향 프로그래밍(OOP)의 속성과 이러한 모델의 품질을 평가하는 방법도 알아보았지만 모델을 구축하는 방법에 관해서는 아직 이야기하지 않았습니다. 이는 시스템을 유용한 모듈과 빌딩 블록으로 분해하는 방식과 연관이 있습니다. 1970년대 초반에 작성된 설계 방법론 분야로, 여기에서 얻은 교훈 중 일부가 현재 재조명되고 있습니다.

시스템을 분할하는 가장 흔한 방식은 기능에 따라 분할하는 것입니다. 시스템에 빌딩 블록으로 필요한 모든 기능을 항목화하고 개발자가 이러한 요소를 구현하도록 하는 방식입니다. 하지만 이러한 방식이 시스템을 설계하는 가장 효과적인 방법은 아니었습니다. 여러 단점으로 인해 유연성이 떨어지고 개발자의 작업량이 늘어납니다. 기능별 분해를 통해 설계되는 시스템은 잘 작동하지만 더욱 효과적인 방식이 있습니다. 다른 방식은 시작하고 이해하기가 더 어려운 것이 사실입니다. 초반에는 더 많은 시간이 소요되지만 이후에는 개발이 더 원활히 진행되고 시스템이 변화를 더 쉽게 수용하게 됩니다.

David L. Parnas, 출처: Wikipedia (https://en.wikipedia.org/wiki/David_Parnas)

1971년 카네기-멜론 대학(Carnegie-Mellon University)의 David Parnas는 시스템 설계와 모듈성에 대한 여러 논문을 발표했습니다. 이 논문들을 통해 이전 블로그에 언급했던 결합도와 응집도의 개념을 확립할 수 있었습니다. 그중 하나는 1971년 2월에 발표된 “Information Distribution Aspects of Design Methodology(설계 방법론의 정보 분배 측면)”라는 제목의 논문입니다. 짧은 논문이지만 설계 방법론이 무엇인지 매우 면밀히 설명합니다. Parnas 박사는 “시스템 구조에 대한 다양한 가능성을 배제하는 결정을 통해 설계가 얼마나 진행되었는지 알 수 있습니다.”라고 언급했습니다. 여러 가능성을 배제함으로써 다음 결정 사항의 근거가 확립된다고 하며 이러한 주장을 뒷받침하는 예시를 들고 있습니다. 이러한 각 방법론은 해결책으로 귀결됩니다.

Parnas 박사는 다음의 3가지 접근 방식을 소개했습니다.

1. ‘우수한’ 외부 고려사항 확보

2. 프로젝트 착수와 완료 사이의 시간 간격 단축

3. 쉽게 변경할 수 있는 시스템 확보

접근 방식 1은 “하향식” 접근 방식과 관련이 있습니다. 접근 방식 2를 사용하면 제품의 최종 사용성에 대한 영향을 고려하지 않을 수 있는 모듈화에 관한 선택이 이루어질 수 있지만 개발자의 개발 시간이 단축됩니다. 접근 방식 3은 변경될 가능성이 가장 낮은 요인을 파악하여 가장 일반적인 정보가 먼저 사용됩니다.

Parnas 박사는 하향식 접근 방식을 사용하면 변화를 가져오는 요인보다 외부 요인에 따라 의사결정이 이루어지기 때문에 시스템을 변경하기 더 어려워집니다. Parnas 박사는 논문의 이 섹션을 마무리하며 이러한 접근 방식에 따라 내려지는 의사결정의 순서가 일관적이지 않기 때문에 모든 접근 방식을 동시에 만족하는 것은 불가능하다고 덧붙입니다. 이러한 입장은 곧 소개할 Parnas 박사의 다음 논문에서 계속되지만 우선 첫 번째 논문에 대한 제 의견을 말씀드리겠습니다.

유능한 프로그래머에 대한 Parnas 박사의 설명이 흥미롭습니다. “유능한 프로그래머는 주어진 가용 정보를 활용합니다.”라고 말합니다. 그는 계속해서 유능한 프로그래머는 현명하고 문서화되지 않은 정보를 사용할 줄 알며 이로 인해 하나의 블록에 변경 사항이 발생하면 다른 블록도 변경해야 한다고 말합니다. 이것이 바로 이전 게시글에서 언급했던 ‘Connascence’라는 개념이며 접근 방식 3과 일치합니다. 첫 번째 논문의 결론은 정보 은닉이 바람직하다는 것입니다. 즉, 시스템 설계자가 꼭 필요한 사람에게만 설계 정보를 공유해야 한다는 것입니다.

Parnas 박사는 계속해서 1971년 8월 “On the Criterion to Be Used in Decomposing Systems into Modules(시스템을 모듈로 분해하는 데 사용되는 기준에 관하여)”라는 논문을 발표했습니다. 이 논문은 많은 혹평을 받았으며 이제 다시 재조명되고 있습니다. 바로 이 논문에서 Parnas 박사는 변화 가능성에 따라 시스템을 설계하는 방식, 즉 이전 논문의 접근 방식 3을 입증합니다.

Parnas 박사의 목표는 총 개발 시간을 단축하면서도 시스템 유연성과 포괄성을 개선하는 것이었으며 이러한 목표를 달성한 예시를 들고 있습니다. 정보 은닉을 기반으로 코드를 모듈화하면 변경 관리를 바탕으로 시스템을 모듈화하게 됩니다. 변경 사항은 더 적은 수의 모듈로 분리되어 변경이 필요한 경우 시스템에 변경 사항을 적용하고 재구성하기 용이해집니다. 기능별로 분해하든 변경 사항을 분해하든 시스템은 작동할 수 있지만 정보 은닉을 기반으로 높은 응집도를 확보하면 시스템의 유연성, 포괄성이 향상되고 개발 시간이 단축됩니다.

정해진 구조를 가진 잘 알려진 항목이 메모리에 저장된 경우를 생각해 봅시다. 시스템이 기능별로 분해되면 일부 또는 모든 모듈이 이렇게 분해된 시스템에서 실행될 수 있습니다. 구조가 변경되면 이 구조에 액세스하는 모든 모듈이 변경되어야 합니다. 하지만 액세스 제공을 담당하는 모듈이 구조를 관리한다면 구조에 대한 액세스를 필요로 하는 모든 모듈을 변경하지 않아도 구조를 변경할 수 있습니다. 중요한 점은 이 방법론에서는 설계자가 처음부터 변경될 가능성이 높은 대상을 파악한다는 점입니다. 각 방법론이 제공하는 기능은 동일하지만 모듈성이 다릅니다. Parnas 박사는 변경에 따른 모듈성이 기능에 따른 모듈성보다 설계 결정을 더 효과적으로 반영하기 때문에 시스템이 더욱 명료해집니다.

정보 은닉을 기반으로 한 모듈화에도 위험성이 없는 것은 아닙니다. Parnas 박사는 이러한 방식으로 설계된 시스템은 비효율적일 수 있지만 시스템이 확대됨에 따라 정보를 은닉하는 것이 더 중요해진다고 주장합니다. 위험성에 대해서는 다음 달 마지막 게시글에서 알아보겠습니다.

가장 본질적인 것은, 기능성 재사용률을 높이려면 해당 기능에 대한 인터페이스에 최소한의 정보만을 공개해야 합니다. 아인슈타인의 말대로 “모든 것을 더 단순하게가 아니라 가능한 한 단순하게 만들어야” 합니다. 이 경우에는 “모든 것”을 “인터페이스”로 바꾸어야 합니다. 이러한 작업은 임베디드(Embedded) 엔지니어에게 적합합니다. 임베디드 엔지니어는 다양한 기법에 대한 교육을 받기 때문에 기술이 없는 사람에 비해 설계의 모든 단계에서 작업할 수 있습니다. 이러한 엔지니어의 설계는 다수의 사용자, 즉 고객이 사용하는 경우 사용이 가능한 한 간편해야 합니다.

출처: https://rightingsoftware.org/

위에 언급했듯이, Parnas 박사의 연구는 현재 재조명되고 있습니다. Juval Löwy의 저서 “Righting Software”와 함께 Parnas 박사의 논문에 관해 자세히 알아보고자 하는 모든 분을 초대합니다.

Löwy가 Parnas 박사 덕분에 확립한 접근 방식은 잠재적인 변경의 휘발성을 고려하여 시스템을 분해하는 방식으로 시스템을 설계하고 빌딩 블록 내에서 이러한 잠재적인 변경을 수용하는 것입니다. 그리고 시스템에 필요한 동작이 이러한 빌딩 블록 간 상호작용으로 구현됩니다. 성공적인 설계는 최소한의 빌딩 블록 집합으로 모든 사용 사례를 충족합니다. 이는 말처럼 쉽지 않습니다.

Löwy는 핵심 사용 사례를 파악해야만 가능하다고 말합니다. 이 사례는 약 1~3가지이며, 여기에 일반적으로 수반되는 구성 요소는 12개 미만으로 많지 않다고 덧붙입니다. 12개 요소의 구성 및 상호작용 수는 매우 큽니다. 악기에서 12개의 음으로 구성될 수 있는 다양한 노래와도 같습니다. 다양한 선율과 각 음의 길이를 생각해 보면 Löwy의 주장이 맞는다는 생각이 듭니다.

Löwy는 계속해서 20만 년 전에 살았던 사람의 사례가 현재 사례와 다르지 않다고 말합니다. 이 경우 사용 사례는 생존이며, 채집 및 취합을 통해 이를 가능하게 하는 아키텍처는 소프트웨어 엔지니어가 살아갈 수 있게 해주는 아키텍처와 동일(동일한 구성 요소 사용)합니다. Löwy는 코끼리와 쥐의 아키텍처도 이와 동일하지만 설계가 더 세부적이라는 점이 다르다고 주장합니다. 매우 설득력 있는 주장입니다.

그래서 빌딩 블록을 다시 구현하지 않고도 변화하는 요구 사항에 따라 재구성할 수 있어야 본질적으로 우수한 설계로 인정받을 수 있습니다. 성공적인 분해는 과거, 미래, 알 수 있는 요소와 알 수 없는 요소라는 모든 요구 사항을 충족합니다. 심층적인 주제로, 연구할 만한 가치가 있습니다.

마지막 게시글에서는 언급한 바와 같이 개발한 기능을 더 많은 사람이 사용하도록 지원하면서 발생한 문제와 시장 확대를 위해 이러한 문제를 감수해야 하는 이유를 알아보겠습니다.