[좋은 코드, 나쁜 코드 review] 2장 추상화 계층

목차

2.1 널값 및 의사코드 규약
2.2 왜 추상화 계층을 만드는가?
2.3 코드의 계층
2.4 마이크로서비스는 어떤가?
요약

---

2장은 다음과 같은 내용을 다룬다.

• 깔끔한 추상화 게층을 통해 하위 문제로 세분화하는 방법
• 추상화 계층이 코드 품질의 요소를 달성하는 데 어떻게 도움이 되는지
• API 및 구현 세부 사항
• 함수, 클래스 및 인터페이스를 사용해 코드를 추상화 계층으로 나누는 방법

2.1 널값 및 의사코드 규약

많은 프로그래밍 언어에는 값(또는 참조/포인터)이 없다는 개념을 가지고 있다. 이 개념을 표현하기 위해 프로그래밍 언어는 널null값을 사용한다. 하지만 널값은 너무 많은 장단점이 있다.

• 값이 제공되지 않거나 함수가 원하는 결과를 반환할 수 없는 경우가 자주 발생하기 때문에 "값이 없다" 또는 "부재하다"는 개념은 요용하지만
• 값이 널일 수 있더나 혹은 널이면 안 되는 경우가 항상 명백한 것은 아니기 때문에 문제가 발생한다. 또한 개발자들은 변수에 액세스하기 전에 널값인지 확인하는 것을 자주 잊고 이 경우 오류가 발생하는 경우가 많다.

다행스럽게도 최근 몇 년 동안 널 안전성null safety 혹은 보이드 안정성void safety에 대한 생각이 중시되고 있다. 이렇게 하면 널값이 가능한 변수나 반환값을 그에 맞게 표시해야 하고 컴파일러는 반드시 널값 여부 확인을 할 수밖에 없도록 만든다.

최근 몇 년간 새로 등장한 중요한 언들 대부분은 널 안전성을 지원한다. 또한 C#과 같은 언어는 최신 버전에서 선택적으로 사용할 수 있으며, 자바에서도 이것을 사용할 수 있는 방법이 있다. 사용 중인 언어가 널 안전성을 지원한다면 사용하는 것이 좋은데 사용 중인 언어가 널 안전성을 지원하지 않는다면, 널값을 사용하는 대신 옵셔널Optional 타입을 사용하는 것이 좋다.(자바, 러스트, C++ 등의 언어에서 지원)

기본적으로 변수, 함수의 매개변수 및 반환 유형은 모두 널값을 가질 수 없다. 그러나 데이터 유형 이름의 끝에 "?" 기호가 붙어 있으면 널값을 가질 수 있다는 의미이고 이때는 널값 여부를 확인하지 않고서는 사용할 수 없도록 컴파일러가 강제한다.

 

2.2 왜 추상화 계층을 만드는가?

코드 작성은 복잡한 문제를 계속해서 더 작은 하위 문제로 세분화하는 작업이다. 이것을 설명하기 위해 사용자의 어떤 장치에서 실행되면서 서버에 메시지를 보내는 코드를 작성한다고 가정해보자. 코드는 단 세 중리고 다음과 같은 네 가지 간단한 개념만 다루면 된다.

• 서버의 URL
• 연결
• 메세지 문자열 보내기
• 연결 닫기

HttpConnection connection = 
	HttpConnection.connnect("http://example.com/server");
connection.send("Hello server");
connection.close();

이것은 실은 간단한 문제가 아니다. 클라이언트 장치에서 서버로 'Hello server'라는 문자열을 보내는 데는 다음과 같은 일이 일어난다.

• 전송할 수 있는 형식으로 문자열 직렬화
• HTTP 프로토콜의 모든 복잡한 동작
• TCP 연결
• 사용자의 장치가 와이파이 혹은 셀룰러 네트워크에 연결되어 있는지 여부 확인
• 데이터를 라디오 신호로 변조
• 데이터 전송 오류 및 수정

이 예는 서버에 메시지를 보내야 한다는 상위 수준의 문제가 있다. 그러나 이를 위해 (위에서 나열한 것 등) 해결해야 할 하위 문제가 많다. 다행스럽게도 다른 개발자들이 이 모든 하위 문제를 이미 해결했기 때문에 우린 그것들을 인식할 필요도 없어졌다.

하나의 문제가 있을 때 이 문제와 하위 문제에 대한 해결책이 일련의 층을 형성하고 있는 것으로 생각할 수 있다. 최상위 계층에서는 HTTP 프로토콜이 어떻게 구현되는지 알 필요가 없이 서버에 메시지를 보내는 것만 신경을 쓰면서 코드를 작성할 수 있다. 이와 비슷하게 HTTP 프로토콜을 구현하기 위한 코드를 작성한 엔지니어는 데이터가 무선 신호에 변조되는 방법에 대해 아무것도 몰라도 문제가 없었을 것이다. HttpConnection 코드를 구현한 개발자는 물리적인 데이터 전송을 추상적인 개념으로 생각할 수 있었고, 우리 역시 HTTP 연결을 추상적인 개념으로 생각할 수 있다. 이것을 추상화 계층layers of abstraction이라고 한다. 

좀 더 일반적으로 말해서 어떤 문제를 하위 문제로 계속해서 나누어 내려가면서 추상화 계층을 만든다면, 같은 층위 내에서는 쉽게 이해할 수 있는 몇 개의 개념만을 다루기 때문에 개별 코드는 특별히 복잡해 보이지 않을 것이다. 소프트웨어 엔지니어로서 문제를 해결할 때 이것이 목표가 되어야 한다.

2.2.1 추상화 계층 및 코드 품질의 핵심 요소

깨끗하고 뚜렷한 추상화 계층을 구축하면 1장에서 살펴본 코드 품질의 네 가지 핵심 요소(가독성, 모듈화, 재사용성 및 일반화성, 테스트 용이성)을 달성할 수 있다. 그 이유는 다음과 같다.

가독성
개발자들이 코드베이스에 있는 코드의 모든 세부 사항을 이해하는 것은 불가능하지만 몇 가지 높은 계층의 추상화를 이해하고 사용하기는 상당히 쉽다. 깨끗하고 뚜렷한 추상화 게층을 만드는 것은 개발자가 한 번에 한두 개 정도의 계층과 몇 개의 개념마 다루면 된다는 것을 의미하기 때문에 코드의 가독성이 크게 향상된다.

모듈화
추상화 계층이 하위 문제에 대한 해결책을 깔끔하게 나누고 구현 세부 사항이 외부로 노출되지 않도록 보잘할 때, 다른 계층이나 코드의 일부에 영향을 미치지 않고 계층 내에서만 구현을 변경하기가 매우 쉬워진다. 모듈화가 잘 되어 있다면 상위 수준의 코드에서는 다양한 상황에 대처하기 위해 어떤 특별한 작성을 수행할 필요가 없다.

재사용성 및 일반화성
하위 문제에 대한 해결책이 간결한 추상화 계층으로 제시괴면 해당 하위 문제에 대한 해결챗을 재사용하기가 쉬어진다. 그리고 문제가 적절하게 추상적인 하위 문제로 세분화된다면, 해결책은 여러 가지 다른 상황에서 유용하게 일반화될 가능성이 크다. 

테스트 용이성
신뢰할 수 있는 코드를 작성하고자 한다면, 각 하위 문제에 대한 해결책이 견고하고 제대로 작동하는지 확인해야 한다. 코드가 추상화 계층으로 깨끗하게 분할되면 각 하위 문제에 대한 해결책을 완벽하게 테스트하는 것이 훨씬 쉬어진다.

 

2.3 코드의 계층

실제로 추상화 계층을 생성하는 방법은 코드를 서로 다른 단위로 분할하여 단위 간의 의존 관계를 보여주는 의존성 그래프를 생성하는 것이다. 대부분의 프로그래밍 언어는 코드를 다른 단위로 나누기 위해 몇 가지 언어 요소를 자유롭게 사용할 수 있다. 대체적으로 그 요소는 다음과 같다.

• 함수
• 클래스(및 구조체나 믹스인과 같이 클래스와 비슷한 요소도 가능)
• 인터페이스(또는 이와 동일한 요소)
• 패키지, 네임스페이스, 모듈

2.3.1 API 및 구현 세부 사항

코드를 작성할 때 고려해야 할 측면이 두 가지 있다.

• 코드를 호출할 때 볼 수 있는 내용:
  • 퍼블릭 클래스, 인터페이스 및 함수(메서드)
  • 이름, 입력 매개변수 및 반환 유형이 표현하고자 하는 개념
  • 코드 호출 시 코드를 올바르게 사용하기 위해 알아야 하는 추가 정보(예: 호출 순서)
• 코드를 호출할 때 볼 수 없는 내용: 구현 세부 사항

서비스를 구축하거나 호출하는 등의 작성을 해본 적이 있다면 애플리케이션 프로그래밍 인터페이스application programming interface, API라는 용어에 익숙할 것이다. API는 서브를 사용할 때 알아야 할 것들에 대한 개념을 형식화하고, 서비스의 모든 구현 세부 사항은 이 API 뒤에 감춘다.

작성한 코드를 다른 코드들이 사용할 수 있도록 미니 API를 노출하는 것으로 생각하면 유용할 때가 있는데 개발자들은 종종 클래스, 인터페이스, 함수들을 'API 노출'이라고 말하곤 한다. 아래 그림은 클래스의 다양한 측면을 어떻게 공개 API의 일부와 구현 세부 사항으로 나눌 수 있는지 예시를 보여준다.

API는 호출하는 쪽에 공개할 개념만 정의하면 되고 그 이외의 모든 것은 구현 세부 사항이기 때문에 코드를 API의 관점에서 생각하면 추상화 계층을 명확하게 만드는 데 도움이 된다. 코드의 일부를 작성하거나 수정할 때, API에 이 수정 사항에 대한 구현 세부 정보가 새어 나간다면 추상화 게층이 명확하게 구분되어 이루어진 것이 아니다.

2.3.2 함수

어떤 로직을 새로운 함수로 구현하면 대부분 유익하다. 각 함수에 포함된 코드가 짧은 문장처럼 읽히면 이상적이다. 너무 많은 개념을 동시에 다루게 되면 코드가 이해하기 어렵다. 또한 단일 함수 내에서 너무 많은 작업을 수행하면 깊이 중첩된 if 문과 같이 코드를 이해하기 어렵게 만드는 문제가 발생할 수 있다.

함수가 하는 일을 다음 중 하나로 제한하면 이해하기 쉽고 단순한 문장으로 표현되는 함수를 작성하기 위한 좋은 전력이 될 수 있다

• 단일 업무 수행
• 잘 명명된 다른 함수를 호출해서 더 복잡한 동작 구성

이 두 가지 사항이 정확하고 과학적인 것은 아니다. '단일 업무'라는 것이 해석하기 나름이고, 다른 함수를 호출해서 더 복잡한 동작을 구성할 때에도 여전히 (if문 이나 for 루프와 같이) 약간의 제어 흐름이 필요하기 때문이다.

일단 함수를 작성했으면 작성된 코드를 문장으로 만들어보면 좋다. 문장을 만들기 어렵거나 너무 어색하면 함수가 너무 길다는 것을 의미하고 더 작은 함수로 나누는 것이 유익할 것이다.

함수를 작게 만들고 수행하는 작업을 명확하게 하면 코드의 가독성과 재사용성이 높아진다. 코드 작성을 일단 마치고 코드 검토를 요청하기 전에 자신이 작성한 코드를 비판적으로 다시 한번 살펴보는 것이 좋다. 함수를 한 문장으로 표현하기 어렵게 구현했다면 로직의 일부를 잘 명명된 헬퍼 함수로 분리하는 것을 고려해봐야 한다.

2.3.3 클래스

개발자들은 단일 클래스의 이상적인 크기에 대해 논의하고 다음과 같은 많은 이론과 경험 법칙을 제시한다.

• 줄 수number of lines: 때때로 '한 클래스는 코드 300줄을 넘지 않아야 한다'와 같은 가이드라인을 접하는 경우가 있다.
  • 300줄보다 긴 클래스는 너무 많은 개념을 다루므로 분리해야 한다는 것은 (항상은 아님) 아주 많은 경우에 사실이지만 이것이 무조건 적절한 크기임을 뜻하지는 않는다. 이것은 어떤 것이 잘못되었을지도 모른다는 경고의 역할만 할 뿐, 어떤 것이 옳다는 보장은 아니다. 그러므로 이와 같은 규칙은 실제로 사용하기에는 상당히 제한적이다.
• 응집력cohesion: 이것은 한 클래스 내의 모든 요소들이 얼마나 잘 속해 있는지를 보여주는 척도로, 좋은 클래스는 매우 응집력이 강하다. 어떤 것들이 어떻게 결속되어 있는지 분류할 수 있는 방식이 많이 있는데 다음은 이에 대한 몇 가지 예다
  • 순차적 응집력: 이것은 한 요소의 출력이 다른 요소에 대한 입력으로 필요할 때 발생한다. 
  • 기능적 응집력: 이것은 몇 가지 요소들이 모여서 하나의 일을 성취하는 데 기여할 때 발생한다. 
• 관심사의 분리separation of concerns: 이것은 시스템이 각각 별개의 문제(또는 관심사)를다루는 개별 구성 요소로 분리되어야 한다고 주장하는 설계 원칙이다. 이것의 실제적인 예는 게임 콘솔이 TV와 동일한 제품으로 함께 묶이지 않고, TV와 분리되는 방식에서 찾아볼 수 있다.

응집력과 관심사의 분리에 대해 생각할 때는 서로 관련된 여러 가지 사항을 하나의 사항으로 간주하는 것을 어느 수준에서 해야 유용할지 결정해야 한다. 이것은 매우 주관적일 수 있기 때문에 종종 보기보다 까다로울 수 있다. 

'클래스는 응집력이 있어야 하고 한 가지 일에만 관심을 가져야 한다' 라는 말을 알고 있지만 여전히 많은 개발자들은 너무 큰 클래스를 작성한다. 단일 클래스 내에 얼마나 많은 다른 개념이 들어가 있는지, 그리고 어떤 로직이 재사용이나 재구성에 적합한지에 대한 개발자가 신중하게 생각하지 않으면 클래스는 종종 너무 커진다. 따라서 기존 코드를 수정할 때나 완전히 새로운 코드를 작성할 때 클래스가 너무 커지는 것은 아닌지 주의해야 한다.

2.3.4 인터페이스

계층 사이를 뚜렷이 구분하고 구현 세부 사항이 게층 사이에 유출되지 않도록 하기 위해 사용할 수 있는 한 가지 접근법은 어떤 함수를 외부로 노출할 것인지를 인터페이스를 통해 결정하는 것이다. 그 다음 이 인터페이스에 정의된 대로 클래스가 해당 계층에 대한 코드를 구현한다. 이보다 위에 있는 계층은 인터페이스에 의존할 뿐 로직을 구현하는 구체적인 클래스에 의존하지 않는다.

하나의 추상화 계층에 대해 두 가지 이상의 다른 방식으로 구현하거나 향후 다르게 구현할 것으로 예상되는 경우 인터페이스를 정의하는 것이 좋다. 이를 통해 코드를 더욱 모듈화할 수 있고 재설정도 훨씬 쉽게 할 수 있다.

모든 것을 위한 인터페이스?

주어진 추상화 게층에 대해 한 가지 구현만 있고 향후에 다른 구현을 추가할 계획이 없더라도 여전히 인터페이스를 통해 추상화 계층을 표현해야 하는가는 여러분과 여러분의 팀이 결정할 사안이다. 몇몇 소프트웨어 공학 철학은 이 상황에서도 여전히 인터페이스를 사용할 것을 권고한다. 이 접근 방식은 몇 가지 장점이 있다.

• 퍼블릭 API를 매우 명확하게 보여준다: 이 계층에서 사용해야 하는 기능과 사용하지 말아야 하는 기능에 대해 혼동할 일이 없다.
• 한 가지 구현만 필요하다고 잘못 추측한 것일 수 있다: 단지 몇 개의 단락을 생략하는 것으로 텍스트를 요약하는 것이 그다지 효과적이지 않다는 것을 깨닫고, 완전히 다른 방식으로 텍스트를 요약하는 알고리즘을 실험하기로 할 수도 있다.
• 테스트를 쉽게 할 수 있다: 예를 들어 구현 클래스가 특별히 복잡하거나 네트워크 I/O에 의존하는 작업을 수행한다면 테스트 중에 목mock이나 페이크 객체로 대처할 수 있다.
• 같은 클래스로 두 가지 하위 문제 해결 가능: 한 클래스가 두 개 이상의 서로 다른 추상화 게층에 구현을 제공할 수도 있다. 이렇게 하면 코드의 일반화 가능성을 크게 높일 수 있다.

하지만 인터페이스를 정의할 때 다음과 같은 단점도 역시 존재한다.

• 더 많은 작업이 필요하다: 인터페이스를 정의하려면 코드를 더 작성해야 한다(파일도 새로 필요할 것)
• 코드가 복잡해질 수 있다: 다른 개발자가 코드를 이해하려고 할 때, 논리를 탐색하는 것이 어려울 수 있다. 어떤 하위 문제가 어떻게 해결되고 있는지 이해하기를 원한다면, 단지 하위 계층을 구현하는 클래스로 직접 이동하는 대신, 인터페이스로 먼저 이동한 다음 그 인터페이스를 구현하는 구체적인 클래스를 찾아야 한다.

 

2.3.5 층이 너무 얇아질 때

코드를 별개의 계층으로 세분화하면 장점이 많지만 다음과 같은 추가 비용이 발생한다. 

• 클래스를 정의하거나 의존성을 새 파일로 임포트하려고 반복적으로 사용하는 코드로 인해 코드의 양이 늘어난다. 
• 로직의 이해를 위해 파일이나 클래스를 따라갈 때 더 많은 노력이 필요하다.
• 인터페이스 뒤에 계층을 숨기게 되면 어떤 상황에서 어떤 구현이 사용되는지 파악하는 데 더 많은 노력이 필요하다. 이로 인해 로직을 이해하거나 디버깅하는 것이 더 어려워질 수 있다.

코드를 서로 다른 계층으로 분할해서 얻는 장점과 비교하면 이 비용이 상당히 낮은 것이지만, 분할을 위한 분할은 의미가 없다는 것을 명심해야 한다. 비용이 이익보다 더 큰 시점이 올 수 있으므로 상식에 맞게 적용하는 것이 좋다.

코드 계층의 규모를 올바르게 결정하는 것은 중요하다. 코드베이스에 의미 있는 추상화 계층이 없으면 전혀 관리할 수 없는 코드가 된다. 계층이 있더라도 각 계층을 너무 크게 쪼개져야 할 여러 추상화가 한 계층으로 병합되어 결국은 모듈화되지 않고, 재사용할 수 없으며, 가독성이 낮은 코드가 된다.

반면 계층을 너무 얇게 만들면 단일 게층으로 만들어도 될 것을 둘로 분해한 것이고, 이것은 불필요한 복잡성을 초래할 수 있다. 또한 인접한 계층들이 원래 되어야 하는 대로 잘 분리되지 않았음을 의미할 수도 있다. 일반적으로 너무 많은 일을 하는 계층은 너무 적은 일을 하는 계층보다 더 문제가 될 수 있다.

따라서 어떤 것이 더 나을지 확실하지 않다면, 너무 많은 계층을 남용하는 결과를 가져오더라도 계층을 여러 개로 나누는 것이 한 계층 안에 모든 코드를 집어넣는 것보다는 낫다.

 

2.4 마이크로서비스는 어떤가?

마이크로서비스 아키텍처에서는 개별 문제에 대한 해결책이 단지 단일 프로그램으로 컴파일되는 라이브러리 수준이 아니라 독립적으로 실행되는 서비스로 배포된다. 즉, 시스템이 여러 개의 소규모 프로그램으로 분할되어 특정 작업만 전문적으로 수행한다. 이런 소규모 프로그램은 API를 통해 원격으로 호출할 수 있는 전용 서비스로 배포된다. 

마이크로서비스는 간결한 추상화 계층을 제공하기 때문에 마이크로서비스를 사용할 때 코드 구조를 만들고 코드에 추상화 계층을 만드는 것은 중요하지 않다. 즉, 내부의 코드가 어떻게 구성되고 나눠지는지는 중요하지 않다는 것이다.

마이크로서비스는 시스템을 분리하여 보다 모듈화할 수 있는 매우 좋은 방법이지만, 서비스를 구현하기 위해 여러 하위 문제를 해결해야 한다는 사실은 바뀌지 않는다. 올바른 추상화 및 코드 계층을 만드는 것은 여전히 중요하다.

 

요약

• 코드를 깨끗하고 뚜렷한 추상화 계층으로 세분화하면 가독성, 모듈화, 재사용, 일반화 및 테스트 용이성이 향상된다.
• 특정 언어에 국한된 기능뿐만 아니라 함수, 클래스 및 인터페이스를 사용하여 코드를 추상화 계층으로 나눌 수 있다.
• 코드를 추상화 계층으로 분류하는 방법을 결정하려면 해결 중인 문제에 대한 판단과 지식을 사용해야 한다.
• 너무 비대한 계층 때문에 발생하는 문제는 너무 얇은 계층 때문에 발생하는 문제보다 더 심각하다. 확실하지 않은 경우에는 남용의 위험에도 불구하고 게층을 얇게 만드는 것이 좋다.