brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Jan 10. 2023

Kent Beck의 Design Play가 무슨 말인가

메일링 리스트로 받아보는 Kent Beck의 글이 주는 호기심에 반응하여 빠르게 글을 쓴다.


Fooling Around는 무슨 뜻이지?

첫 번째 호기심은 'fool'이란 단어가 어떻게 설계(design)와 연결되는 것일까? 하는 질문이었다. fool around 뜻이 짐작이 안되어서 파파고와 콜린스 사전을 찾았다.

콜린스의 풀이 중에서는 아래 쓰임새가 비슷해 보인다.

If you fool around, you behave in a playful, childish, and silly way, often in order to make people laugh.

웃기려고 까부는 행동이란 말인가? 핵심 설계 기술이? 당최 무슨 말인지 짐작하기 어렵다.


대체 뭐가(어느 구조가) 문제야?

제목 바로 아래에는 또 흥미로운 도식이 있다.

첫 단락에서 내가 포착할 수 있었던 흥미로운 점은 두 가지이다.

하나는 사람들은 바로 눈에 띄는 소프트웨어의 행위와 달리 드러나지 않는 구조에 대해서는 과소 투자한다. 내가 관심을 두고 글로 풀었던 주제 중에 하나인 '기술 부채'가 바로 그 대가로 주어지는 사회적 산물이다.


두 번째는 어떤 구조인가 하는 질문이 바로 디자인 Play의 시작이라는 Kent Beck의 접근이다.


투자 효과에 대한 예측이 어려운 구조 개선

뒤이어 그는 구조 투자에 대한 효과가 예측이 어렵다는 점을 설명한다.

그렇다. <린 분석> 등을 보면 사업 모델에 대해 사용자 유입과 참여 강도, 구매 행위로의 전환 등의 행위적 요소를 측정하여 효과를 평가하는 방법을 설명한다. 그런데, 구조 투자에 대해서는 이와 같이 활용한 참조 모델이 떠오르지 않는다. 참조 모델은 커녕 어떤 변수를 넣어 평가해야 하는지 조차 불분명하다.


파급 효과를 어디까지 고려할 것인가?

두 번째로 그는 너무나 많은 선택지를 지적한다.

나는 이 문제를 부르는 제목을 붙이면서, 단순히 많은 선택지가 아니라 소프트웨어가 본질적으로 갖는 의존성(dependency)에 주목했다. 요즘 소프트웨어 구현에 있어 알고리즘만큼이나 중요한 부분이 의존성 관리라고 해도 무리가 아니다. 선택지가 많은 이유는 서로 무관한 개별적인 고려사항의 숫자가 많은 문제보다는 복합적 혹은 다중적으로 고려해야 하는 문제가 아닐까 싶었다. 그래서, 스스로 파급 효과를 어디까지 고려할 것인지 문제에 따라 복잡도가 달라진다고 보았다.


선택지가 너무나 많고, 예측이 어려우면 합리적 추론으로만 문제를 판단할 수는 없다는 점을 지적한다.

그렇다고 해도 가치에 대한 믿음이 있으면 계속해야 한다.


뜻밖의 자유로움과 기술부채

나 역시 Kent Beck이 말하는 디자인 문제의 자유로움에 대해 경험적으로 매우 익숙하다.

나는 매번 해당 도메인의 상황을 익히면 긴 시간이 걸리지 않아도 중요한 문제 혹은 풀고 싶은 디자인 문제를 발견할 수 있다.[1]


반면에 이때 필요한 의사결정 문제를 그는 일종의 an optimization surface 문제[2] 로 보고 흔히 실수에 빠진다고 말한다.

그로 인해 '기술 부채'가 만들어지는 행동 패턴의 양상을 설명한다. 기술 부채 다시 말해 구조 문제 방치가 임계치에 달하면 전면 재구축을 해야 할 수도 있다. 한국식으로 말하면 '차세대 프로젝트'를 해야 한다.


역설적인 선택권

쳇바퀴 돌듯이 벌어지는 난제에 대해 아이러니하게 존재하는 자유에 대해 다시 설명한다.

이번에 그가 쓴 표현은 'We always have the option to improve the structure.' 이다. 우리는 언제나 구조를 개선할 자유(선택권)를 갖고 있다는 것이다. 다음 문단의 예시는 와닿지 않아 생략한다.


다음 문장을 보면 큰 변화는 위험하다는 지적이다.

Big changes are risky.

이미 차세대 프로젝트가 위험한 일이 된 지는 오래된 사건이다.


Make a habit of playing with structure

외우자.

다행스러운 일은 내가 탐구하던 문제 그리고 제품화하던 회사의 방향과 겹치는 부분이 있다는 점이다. 'developing plasticity of design'에 대해서는 또 호기심이 따른다.

Play라는 말을 알 듯도 하고, 아리송한 부분도 있다. 그러니 더 해봐야겠다.


Design Play = Design Plasticity

읽는 분들에게는 두서없는 글이고, 나에게는 호기심에 반응한 경험만 남을 수 있는 글이다. 즉흥적이라도 결론을 내리는 편이 좋겠다. 가소성(plasticity)이라는 표현이 등장한다. 구조를 개선하는 설계에 대해서는 적절한 시점이라는 것을 말하기 어렵다. 그래서, 노는 듯한 자세를 말한다.


하지만, 기준은 분명하다. 적절한 노력으로 수정이 가능해지는 성질을 가소성(plasticity)이라고 부른다면 그것을 잃지 않는 것이다. 기술 부채 개념을 가져와 설명을 보완할 수 있다. 기술 부채는 가소성의 결여를 말한다. 기술 부채가 임계치에 달했다는 의미는 곧 가소성을 완전히 잃었다는 말이다.


주석

[1] 사실 브런치 도처에 그런 문제에 대한 기록이 넘쳐난다.

[2] 나는 Kent Beck이 말하는 an optimization surface이 지칭하는 바를 정확히 알고 있지 못하다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari