원문 </> htmx ~ Complexity Budget

Carson Gross

2020년 10월 29일

모든 SW 프로젝트는 복잡성 예산을 관리하는 것을 포함합니다.

복잡성 예산은 다음과 같이 정의될 수 있습니다:

애플리케이션 전체에 걸쳐 명시적 또는 암묵적으로 할당된 복잡성

여기서 “복잡성”은 주관적으로(공식적이라기보다는) 스튜어트식으로 정의됩니다: 

“보면 안다.”

또는 SW 개발에 더 구체적으로 말하자면: “느껴질때 안다.”

SW 아키텍트의 주요 업무 중 하나는 프로젝트의 복잡성 예산을 관리하는 것입니다:

  • 주어진 기능이 “가치 있는지” 결정하기

  • 주어진 구현이 “가치 있는지” 결정하기

  • 구성 요소 간의 복잡성을 제한하기 위해 적절한 시스템 경계 추가하기

  • 등등

복잡성의 어려운 측면은, 복잡성을 해결하려는 시도가 실제로는 더 많은 복잡성을 추가할 수 있다는 점입니다.

이것의 좋은 경험적 예시는 제가 일했던 회사에서 프로젝트의 증가하는 복잡성을 관리하기 위해 시스템에 OSGi를 추가했을 때였습니다. 합리적인 접근 방식처럼 보였고, 정교한 모듈 시스템을 제공했으며, 새로 고용된 아키텍트가 추천했고, 심지어 “OSGi란 무엇인가” 페이지에는 다음과 같이 쓰여 있었습니다:

OSGi는 개발의 거의 모든 측면에서 복잡성을 크게 줄여줍니다: 코드는 작성하고 테스트하기 더 쉬워지고, 재사용성이 증가하며, 빌드 시스템은 훨씬 더 단순해지고, 배포는 더 관리하기 쉬워지며, 버그는 일찍 발견되고, 런타임은 실행 중인 것에 대한 엄청난 통찰력을 제공합니다.

무엇이 잘못되었을까요?

불행히도, 해당 프로젝트에 OSGi를 추가한 것은, 전체 프로젝트를 사실상 중단시켰습니다: 최고의 엔지니어 몇 명이 1년 이상 일반 애플리케이션 개발에서 벗어나게 했고, 그들이 작업을 마쳤을 때 코드베이스는 시작했을 때보다 훨씬 더 다루기 어려워졌습니다. 이미 위태로웠던 기능 개발 속도는 무너졌습니다.

이것은 OSGi가 보편적으로 나쁘다는 것을 의미하지는 않습니다. 하지만 이 경우, 우리 개발팀의 생산성을 높이기보다는 사실상 끝장내버렸습니다.

훌륭한 SW 아키텍트는 프로젝트의 SW 예산을 명시적으로든 암묵적으로든 효과적으로 관리하는 사람입니다.

복잡성 증가

확실한 증거는 없지만, 제 생각에는 스튜어트식 애플리케이션 복잡성은 애플리케이션의 크기에 따라 대략 기하급수적으로 증가하는 것 같습니다. 숙련된 개발자의 적절한 팩토링은 이 곡선을 한동안 억제할 수 있습니다.

하지만 이것이 어딘가에 복잡성의 벽이 도사리고 있다는 사실을 바꾸지는 않습니다.

그리고 조심하지 않으면 그 벽에 정면으로 부딪혀 개발 속도가 완전히 멈출 것입니다.

저는 이런 경험을 여러 번 했습니다: 어느 날, 설명할 수 없게도, 제가 작업하던 시스템의 개발이 “크지만 관리할 수 있다”는 느낌에서 “이것은 다루기 불가능하다”는 느낌으로 바뀌었습니다.

복잡성 예산을 현명하게 사용하기

복잡성 예산을 관리하기 위한 몇 가지 도구는 다음과 같습니다:

  1. 무엇보다: 관리해야 할 복잡성 예산이 있다는 것을 이해하기

  2. 애플리케이션이 가치를 더하고/또는 차별화되는 영역에 “복잡성 지출”을 집중하기

  3. “아니오”라고 말하기 - 복잡성과의 싸움에서 아마도 가장 쉽고, 가장 좋으며, 또한 가장 어려운 도구일 것입니다.

  4. KISS 원칙을 받아들이기, 비록 자신이 어리석다고 인정하는 것을 의미하더라도 (참고: 시니어 개발자들이 자신도 틀릴 수 있음을 인정하는 것은 조직에 매우 좋은 경우가 많습니다) (Keep It Simple Stupid)

  5. 구성 요소의 적절한 팩토링 - 이것은 예술입니다: 너무 많은 구성 요소는 복잡성을 폭발시킵니다. 너무 적어도… 마찬가지입니다.

  6. 구성 요소에 대한 표현력과 제약의 적절한 균형 선택하기

불행히도, 경험에 따르면 스튜어트식 복잡성을 관리하는 것은 주관적인 노력이며, 많은 재능 있고 경험 많은 개발자들이 특정 결정 지점에서 올바른 행동 방침에 대해 의견이 일치하지 않을 것입니다.

그럼에도 불구하고, SW 프로젝트에서 복잡성 예산의 개념을 명시적으로 만듦으로써, 이러한 대화는 더 생산적이 될 수 있고 궁극적으로 더 나은 SW 결과로 이어질 수 있습니다.

마지막으로

거의 모든 성숙한 애플리케이션은 복잡합니다.

새로운 코드베이스가 “복잡하다”는 것이 모든 것을 해체하거나 공격적인 리팩토링을 하는 변명이 될 수는 없습니다. 우리는 항상 체스터턴의 울타리를 명심해야 합니다.

애플리케이션이 잘 작동하고 있다면 (또는 합리적으로라도) 복잡성 예산이 잘 (또는 적어도 합리적으로) 관리되었다고 가정해야 합니다.

그리고 우리는 불행하게도 자주, 기존의 대규모 애플리케이션에서 복잡성을 해결하려는 큰 시도들이 실패하거나, 안타깝게도 상황을 더 악화시킨다는 것을 항상 기억해야 합니다.

번역 끝.

투자의 관점

코드의 규모가 커질때, 고민해볼법한 복잡성 예산 내용입니다.. “복잡성 예산”을 염두에 두고 개발한 기업을 찾아야 합니다. 너무 복잡한 제품이라면 피해야돼요.

“아니오”라고 말하기, KISS 원칙 너무 좋습니다. 필요할때만 만들어요 (You Ain’t Gonna Need It). 제품을 봤을 때, 필요한 기능만 있으면 투자가치가 높습니다.

쓸모없는 주석, 전혀 타지 않는 분기문은 알고 있는 사람이 잘 지워주면 좋습니다. (체스터턴의 울타리). 무언가 방치된게 고객의 눈에 보인다면, 기술부채가 쌓여있을 가능성이 높습니다.

한번 작성하고 평생 작동하는 프로젝트는 많이 없습니다. 유저100명에 최적화된 코드가 유저100만명이 늘어날땐 엉망이 되고.. 그렇다고 처음부터 유저100만명을 기준으로 최적화하면 오버엔지니어링이 됩니다. 제품의 엔지니어링 수준을 잘 파악해봅시다. 그것이 예술이고, 훌륭한 투자처가 됩니다.