Clean Architecture 1장을 보고
토끼와 거북이
"Clean Architecture: A Craftsman's Guide to Software Structure and Design"을 보다가 말았었는데 오늘 다시 읽어봤다. 5장까지 읽었는데 그중 1장이 가장 와 닿는 게 많아 여기에 짧게 정리하고 내 상각도 조금 추가해 본다.
Architecture란
몇 가지 정의를 살펴보면 아래와 같다.
Architecture: low level details에서 분리된 high level에 대한 것
사용자의 요구 사항을 만족시키기 위한 기능 요구 사항과 거의 무관(어떤 아키텍처로도 S/W 구축 가능)
비기능 요구 사항에 대한 것 = 품질 속성(“-bilities”, eg. maintainability, extensibility, testability, scalability)
Design: low level의 결정과 구조에 대한 것
SW Architecture의 목적: 요구되는 시스템을 구축하고 유지 보수하는데 요구되는 인적 리소스(human resource)를 최소화하는 것
설계 품질: 고객의 요구사항을 만족시키는 노력으로 측정. 지속적으로 낮게 유지된다면 좋은 설계, 노력이 릴리즈를 할 때마다 증가한다면 나쁜 설계.
Case Study
어떤 회사의 경우를 예로 아키텍처와 생산성에 대한 관계를 살펴본다.
릴리즈가 증가함에 따라 개발 리소스가 증가함
릴리즈가 증가함에 따른 생산성(LOC)이 더 이상 증가하지 않음(수렴함)
릴리즈가 증가함에 따른 라인당 비용(Cost / LOC)이 계속 증가함(첫 번째 릴리즈에 비해 8번째 릴리즈의 비용이 거의 40배)
엉망진창(Mess)의 징후
Big Ball of Mud
뚜렷한 아키텍처 없이 구현된 시스템. 이것이 Mess와 유사함
위 그림은 구글 검색에서 Big Ball of Mud로 검색하고 찾은 이미지이다.
이 그림을 보면서 엉클 밥이 말한 좋은 아키텍처가 없을 때의 상황을 읽어보자.
릴리즈(가로축) 진행에 따른 생산성첫 번째 릴리즈에서는 100%의 생산성으로 시작
릴리즈가 진행됨에 따라 점점 생산성 저하. 8번째 릴리즈에서는 거의 0에 수렴
개발자들의 노력은 새로운 기능을 구현하는 데 사용되지 않고, mess를 관리하는데 소비됨
개발자들의 업무는 한 곳에 있는 mess를 다른 곳으로 옮기고, 또 다른 곳으로, 또 다른 곳으로 옮기는 데 사용됨
개발자들은 더 이상 새로운 기능을 추가할 수 없게 됨
경영진의 관점: 릴리즈가 증가함에 따라 소요되는 개발자 월급이 증가(생산성은 저하 ㅠㅠ)
문제가 뭘까? - "토끼와 거북이"
이솝 우화 "토끼와 거북이"는 자만심의 바보스러움(foolishness of overconfidence)에 대한 것이다.
엉클 밥은 요즘의 개발자들은 토끼와 비슷하고, 유사한 자만심 보인다고 함.
대부분의 요즘의 개발자들은 죽어라 일한다. 하지만 그들의 뇌의 일부는 잠을 잔다 - 잠자는 뇌는 좋은 , 깨끗한, 잘 설계된 코드와 중대한 관계가 있다.
이러한 개발자들은 유사한 거짓에 속는다.
우리는 나중에 깨끗하게 고칠 수 있다. 우리는 단지 상용화를 먼저 해야 할 뿐이다.
물론 후에 깨끗해지지 않는다, 새로운 기능 추가, 기존 기능 변경 등이 절대 줄어들지 않기 때문이다.
그래서 개발자들은 클린 코드 모드로 전환하지 못한다. 그리고 mess가 만들어지고, 생산성은 지속적으로 0을 향해서 저하, 수렴한다.
사실 클린 모드로 전환하여 개선할 역량들은 모두들 갖추고 있는지도 의문이다. 나는 실제로 시간만 주어지면 잘할 수 있다고 말하는 개발자들에게 시간을 준 적도 있었지만, 별로 나아지지는 않았었다("아는 것, 할 수 있는 것, 하는 것" 참고).
토끼가 속도에 자만했던 것처럼 개발자들은 생산성을 유지할 수 있는 능력에 자만한다.
개발자들이 잘 속는 거대한 거짓말은 messy 한 코드를 작성하면 단기간은 빠르게 나갈 수 있고 단지 장기적인 관점에서만 느려진다는 것이다. 이 거짓을 수용하는 개발자들은 빨리 mess를 만들고 모드를 전환해서 미래에 이 mess를 깨끗하게 할 수 있는 능력을 가졌다고 생각하는 점에서 토끼의 자만심을 보인다. 이들의 범하는 오류는 mess를 만드는 것은 깨끗한 상태를 유지하는 것보다 언제나 느리다는 것이다.
이 부분이 참 와 닿는다.
깨끗하게 못 만들지만 일정을 준수해야 하기 때문에 이번에만 이렇게 하고, 나중에 고치겠다고 말하는 경우를 정말 많이 봤다.
하지만 시간이 지나서 좋아지는 코드는 본 적이 거의 없는 것 같다. 대부분은 처음보다 더 나빠지는 경우가 더 많았다.
지식과 경험이 부족해서 깨끗하게 만들지 못할 수 있다. 이 경우에 깨끗하게 만들겠다고 하루 종일 공부하고 몇 줄의 코드만을 작성하는 개발자들도 본 적이 있다. 이건 아닌 것 같다.
일정을 준수하면서 최대한 덜 더럽게 작성하는 것이 맞는 것 같다(이게 어쩌면 그 개발자에게는 깨끗한 코드일 것이다). 그러면 코드 리뷰 등의 협업을 통해 조금씩 나아질 수 있겠지만, 깨끗하게 만들겠다고 일정을 무시하면 같이 일하기 힘든 사람이 될 테니 말이다.
* 고년차 역량이 뛰어난 개발자가 할 수 있는 수준을 저년차의 주니어가 한 번에 따라 할 수는 없다. 그게 가능하다면 주니어가 절대 찾아볼 수 없는 천재이거나 고년차의 역량이 별 것 아닌 수준일 것이다. 열심해 공부하고 실무에 활용하려고 노력해도 절대적인 시간이 필요하다. 고년차 뛰어난 개발자가 그랬던 것처럼...
SW 개발의 단순한 진리
The only way to go fast, is to go well.
이게 경영진이 갖는 딜레마에 대한 답이다. 생산성 저하와 비용 증가를 뒤집을 수 있는 유일한 방법은 개발자들이 더 이상 토끼처럼 자만심을 가지고 생각하지 않고 그들이 만든 mess에 대한 책임을 갖기 시작하도록 하는 것이다.
개발자들은 아마 처음부터 다시 만들고 전체 시스템을 다시 설계하는 것이 답이라 생각할 수 있다. 하지만 이런 생각은 또다시 토끼의 자만심이 된다. 이러한 mess를 유발한 자만심이 이제는 다시 만들면 잘할 수 있다고 말하는 것이다. 실제는 그렇지 않다.
“그들의 자만심은 본래의 프로젝트와 동일하게 같은 mess로 설계하도록 유도한다”
CONCLUSION
모든 경우에 대한 개발 조직의 최선은 자만심을 인식하고 피해서 SW 아키텍처의 품질에 대해서 신중하게 대하는 것이다(내가 모르는 것을 인정해야만 배울 수 있다).
SW 아키텍처를 신중하게 받아들이기 위해서 어떤 것이 좋은 SW 아키텍처인지 알아야만 한다. 노력을 최소화하고 생상성을 최대화할 수 있는 아키텍처와 설계를 갖는 시스템을 구축하기 위해서 시스템 아키텍처의 어떤 속성들을 그 목적으로 인도하는지 알아야만 한다.
이 책이 이러한 것들에 대한 것이다.
이러한 내용의 글은 주기적으로 내게 와 닿는 것 같다. 한번 치렀다고 생각하는데 다시 찾아오는 느낌이다. 한번 극복했다고 생각했는데 반복적으로 이런 일이 일어나면 어떨 때는 불가한 것이니 현실과 타협해야 하나 하는 생각에 무기력해진다. 하지만 아직도 부족해서 그런 것이고, 부족한 점이 나아질 수 있다고 생각하면 힘이 난다.
