클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 5부 : 아키텍처 (29장)

[29장] 클린 임베디드 아키텍처

"소프트웨어는 닳지 않지만, 펌웨어와 하드웨어는 낡아 가므로 결국 소프트웨어도 수정해야 한다." - 더그 슈미트

→ 소프트웨어는 닳지 않지만, 펌웨어와 하드웨어에 대한 의존성을 관리하지 않으면 안으로부터 파괴될 수 있다.

임베디드 엔지니어가 아닌 당신도 코드에 SQL을 심어 놓거나 개발하는 코드 전반에 플랫폼 의존성을 퍼뜨려 놓는다면, 본질적으로 펌웨어를 작성하는 셈이다.

오래전부터 소프트웨어를 하드웨어로부터 분리할 필요성을 느끼고 또 이해하고 있었지만...

엔지니어와 프로그래머에게 전하는 메시지는 분명하다. 펌웨어를 수없이 양산하는 일을 멈추고, 코드에게 유효 수명을 길게 늘릴 수 있는 기회를 주어라.

 

[앱티튜드 테스트(App-titude test)]

켄트벡은 소프트웨어를 구축하는 세가지 활동을 다음과 같이 기술했다.

-먼저 동작하게 만들어라

-그리고 올바르게 만들어라

-그리고 빠르게 만들어라

대다수의 앱들도 코드를 올바르게 작성해서 유효 수명을 길게 늘리는 데는 거의 관심 없이, 그저 동작하도록 만들어진다.

앱이 동작하도록 만드는 것을 나는 개발자용 앱-티튜드 테스트라고 부른다. 프로그래밍에는 단순히 앱이 동작하도록 만드는 것보다 중요한 것이 훨씬 많다.

 

[타깃-하드웨어 병목현상]

임베디드가 지닌 특수한 문제 중 하나는 타깃-하드웨어 병목현상(target-hardware bottleneck)

 

<클린 임베디드 아키텍처는 테스트하기 쉬운 임베디드 아키텍처다>

몇 가지 아키텍처 원칙을 임베디드 소프트웨어와 펌웨어에 적용하여 타깃-하드웨어 병목현상을 줄이는 방법

 

(계층)

소프트웨어 / 펌웨어 / 하드웨어

하드웨어는 시스템의 나머지 부분으로부터 반드시 분리되어야 한다.

소프트웨어와 펌웨어가 서로 섞이는 일은 안티 패턴이다. 이 안티 패턴을 보이는 코든느 변화에 저항하게 된다. 변경하기 어려울 뿐 아니라 변경하는 일 자체가 위험을 수반하여, 때로는 의도치 않은 결과를 불러온다.

 

(하드웨어는 세부사항이다)

소프트웨어와 펌웨어 사이의 경계는 하드웨어 추상화 계층(Hardware Abstraction Layer, HAL)이라고 부른다. HAL은 자신보다 위에 있는 소프트웨어를 위해 존재하므로, HAL의 API는 소프트웨어의 필요에 맞게 만들어져야 한다.

소프트웨어 / HAL / 펌웨어 / 하드웨어

 

<HAL 사용자에게 하드웨어 세부사항을 드러내지 말라>

HAL을 제대로 만들었다면, HAL은 타깃에 상관없이 테스트할 수 있는 경계층 또는 일련의 대체 지점을 제공한다.

 

(프로세서는 세부사항이다)

모든 소프트웨어는 반드시 프로세서에 독립적이야 함이 분명하지만, 모든 펌웨어가 그럴 수는 없다.

클린 임베디드 아키텍처라면 이들 장치 접근 레지스터를 직접 사용하는 코드는 소수의 순전히 펌웨어로만 한정시켜야 한다. 이들 레지스터를 알고있는 것은 모두 펌웨어가 되어야 하며, 따라서 실리콘 칩에 종속된다.

 

(운영체제는 세부사항이다)

작성한 코드의 수명을 늘리려면, 무조건 운영체제를 세부사항으로 취급하고 운영체제에 의존하는 일을 막아야 한다. 소프트웨어는 운영체제를 통해 운영 환경이 제공하는 서비스에 접근한다. OS는 소프트웨어를 펌웨어로부터 분리하는 계층이다.

소프트웨어 / OS / 펌웨어 / 하드웨어

클린 임베디드 아키텍처는 운영체제 추상화 계층(Operating System Abstraction Layer, OSAL)을 통해 소프트웨어를 운영체제로부터 격리시킨다.

소프트웨어 / OSAL / OS / HAL / 펌웨어 / 하드웨어

기존의 복잡한 코드 덩어리를 수정하는 일과, 정의된 인터페이스와 행위에 맞게 새로운 코드를 작성하는 일 중 어떤 일을 하고 싶은가? 답이 뻔한 질문이다. 나라면 후자...

제대로 만든 OSAL은 타깃과는 별개로 테스트할 수 있도록 해주는 경계층 또는 일련의 대체 지점을 제공한다.

 

[인터페이스를 통하고 대체 가능성을 높이는 방향으로 프로그래밍하라]

HAL을 추가하거나 때로는 OSAL을 추가해야 할 뿐만 아니라, 모든 주요 계층(소프트웨어, OS 펌웨어, 하드웨어) 내부에는 이 책에서 설명한 원칙들을 적용할 수 있다. 이들 원칙은 관심사를 분리시키고, 인터페이스를 활용하며, 대체 가능성을 높이는 방향으로 프로그래밍하도록 유도한다. 계층형 아키텍처(Layered Architecture)는 인터페이스를 통해 프로그래밍하자는 발상을 기반으로 한다.

경험법칙에 따르면 인터페이스 정의는 헤더 파일에 해야 한다. 헤더 파일에는 함수 선언과 그 함수에서 사용하는 상수와 구조체 이름만 포함시켜야 한다. 오직 구현체에서만 필요한 데이터 구조, 상수, 타입 정의들로 인터페이스 헤더 파일을 어지럽히지 말라. 결국 원치 않는 의존성을 만들어낼 것이다. 구현 세부사항은 변경될 거라고 가정하라. 세부사항을 알고 있는 부분이 적을수록 추적하고 변경해야 할 코드도 적어진다. 클린 임베디드 아키텍처에서는 모듈들이 인터페이스를 통해 상호작용하기 때문에 각각의 계층 내부에서 테스트가 가능하다.

 

[DRY(Don'y Repeat Yourself) 원칙 : 조건부 컴파일 지시자를 반복하지 말라]

코드를 반복하는 일은 반복하지 말라(DRY)

 

[결론]

모든 코드가 펌웨어가 되도록 내버려두면 제품이 오래 살아남을 수 없게 된다. 오직 타깃 하드웨어에서만 테스트할 수 있는 제품도 마찬가지다. 클린 임베디드 아키텍천느 제품이 장기간 생명력을 유지하는 데 도움을 준다.