개요
최근에 좋은 기회가 되어 개발 스터디를 시작하게 되었다. 단순 코드만 읊는게 아닌, 개발의 본질적인 부분에 대해서 많이 생각해볼 수 있도록 첫 주제로 클린 아키텍처를 선정하였고, 이를 위해 로버트 C. 마틴이 저술한 `클린 아키텍처 - 소프트웨어 구조와 설계의 원칙` 이라는 책을 읽고 내용을 정리하고자 한다.
1장. 설계와 아키텍처란?
- 아키텍처: 저수준의 세부사항과는 분리된 고수준의 무언가
- 설계: 저수준의 구조 또는 결정사항 등을 의미할 때가 많음
소프트웨어에서 이 둘의 경계는 뚜렷하지 않고 고수준에서 저수준으로 향하는 의사결정의 연속성만 존재할 뿐이다.
좋은 소프트웨어 설계의 목표는 무엇이 되어야 할까??
> 필요한 시스템을 만들고 유지보수하는 데에 투입되는 인력을 최소화하는 것이다.
배포가 진행될수록 투입되는 리소스는 늘어나지만 생산성은 줄어드는 경우, 설계가 잘못 되었다는 뜻이다.
빨리 가는 유일한 방법은 제대로 가는 것이다.
본인의 실력을 자만한다면, 재설계한다고 하더라도 원래의 프로젝트와는 크게 달라지지 않는다.
2장. 두 가지 가치에 대한 이야기
모든 시스템 소프트웨어가 이해관계자에게 제공하는 두 가지 가치는 행위(behavior), 구조(structure) 이다.
> 기능 구현, 클린 아키텍처로 대변될 수 있다.
소프트웨어는 soft + ware = 부드러운 제품 이라는 뜻으로, 기계(프로그램)의 행위를 쉽게 변경할 수 있어야 한다.
이 행위(기능)을 변경할 때에 드는 어려움은 변경되는 범위(Scope)에 비례해야 하며 변경사항의 형태(Shape)와는 관련이 없어야 한다.
따라서 개발 비용의 증가는 요청된 변경 사항의 크기에 비례한다.
아키텍처가 특정 형태를 다른 형태보다 선호할 수록 새로운 기능을 이 구조에 맞추는게 더 힘들어진다. 따라서, 아키텍처는 형태(Shape)에 독립적이어야 하고, 그럴수록 더 실용적이다.
소프트웨어 시스템이 동작하는게 중요한가, 더 쉽게 변경할 수 있게 하는게 더 중요한가??
> 동작은 하지 않지만 변경이 쉬운 프로그램이 있다면, 돌아가도록 수정할 수 있고 그러면서 여전히 기능 추가가 용이하다.
요구사항은 다음 우선순위를 가진다.
- 긴급하고 중요한
- 긴급하지는 않지만 중요한
- 긴급하지만 중요하지 않은
- 긴급하지도 중요하지도 않은
위의 항목에서 행위(Behavior)는 긴급, 구조(Structure)는 중요에 해당한다.
행위는 1,3순위에 있지만 구조는 1,2순위를 차지하므로, 당연히 구조가 더 우선시되어야 한다.
3장. 패러다임 개요
- 구조적 프로그래밍: 제어 흐름의 직접적인 전환에 대해 규칙을 부과
- 객체 지향 프로그래밍: 제어 흐름의 간접적인 전환에 대해 규칙을 부과
- 함수형 프로그래밍: 할당문에 대해 규칙을 부과
각 패러다임은 프로그래머에게서 권한을 박탈하고, 프로그래머가 직접적으로 무엇을 해야하는지보다 무엇을 하면 안되는지를 말해준다.
> 이것은 해당 권한을 각 패러다임이 사용하지 못하게 한 것이 아니라, 프로그래밍 언어의 내장 기능으로 고정시켜서 프로그래머에게서 권한을 박탈하였다는 뜻으로 보는 것이 옳은 듯 하다.
- 구조적 프로그래밍: GOTO 명령문
- 객체: 함수 포인터
- 함수형: 할당문
이러한 패러다임들을 각각 활용해서 소프트웨어를 구축하는 것이 아니라, 각 패러다임의 장점을 모두 활용해서 구축하는 것이 옳은 소프트웨어 구축의 길일 것이다.
- 객체지향: 아키텍처의 경계성을 넘나들기 위한 메커니즘으로 다형성을 이용
- 함수형: 데이터의 위치와 접근 방법에 대해 규칙을 부과
- 구조적: 모듈 기반의 알고리즘
마무리
3장까지 읽어보았는데, 특히 3장에서 패러다임이 프로그래머에게서 권한을 박탈한다는 뜻을 약간이나마 이해하고 나니 각 패러다임으로 짜여진 언어들이 왜 그렇게 짜여졌는지 조금이나마 파악되는 느낌이다. 아마 다음 주가 되겠지만, 각 패러다임에 대한 더 상세한 내용들을 얼른 읽어보고 싶다는 생각이 들었다.
'Clean Architecture' 카테고리의 다른 글
| Clean Architecture - Intro (0) | 2022.12.28 |
|---|