설계는 변화에 대한 준비인가?
한국의 마틴 파울러가 되기
즉흥적인 영감에서 시작해서 생각을 짜내기 하는 중입니다. 오래 숙성할 일이 아니니 매끄럽지 않아도 기록을 남기는데 의의를 두려고 스스로를 압박합니다. 그래서, 설계란 무엇인가에 대한 생각을 추가로 남기려고 노력해 보았습니다.
(잠시 후) 그랬더니 지난 글에 쓴 과거 제 기록의 요약에 경험하고 떠올리는 내용 대부분이 담기지 않았을까 싶습니다. 물론, 설계에 대한 하드스킬이나 사례는 담겨 있지 않고 주로 정의에 대한 내용입니다. Part.3로 마무리를 하려고 했는데, 내용이 없네요.
대안으로 Kent Beck의 글이 주는 자극을 담아 글 쓰기를 시도해 봅니다. 정리되지 않은 내용이지만, 기억에 담아 두고 나중에 발전시키기 위해 쓰는 기록이라고 볼 수 있습니다.
설계는 변화에 대한 준비
전형적인 정의와는 조금 다른 Kent Beck의 소프트웨어 설계에 대한 정의(?)가 있습니다.
모두가 동의할 만한 내용이라 생각되지 않지만, X[1]에 올린 글이 현대적인 소프트웨어 설계에 대해 잘 표현했다는 생각이 듭니다.
설계의 경제성과 반복되는 직업 일상을 전제로 한 경우 설계 활동에 대한 가장 중요한 특징을 포착했다고 생각합니다. 그리고 8월 22일 그가 올린 다른 글에도 이런 문장이 있습니다.
Remember that software design is preparation for change.
지난 글에서 인용한 표현 '불확실에 대응하는 전략'과도 일맥상통하는 글입니다.
“the strategy for causing the best change in a poorly understood or uncertain situation within the available resources”
실전에서 활용할 수 있는 설계에 대한 개념적 틀
설계가 변화에 대한 준비라고 한정할 때 불편한 점은 '설계 없는 구현'에 대해 정의할 수 있어야 사라질 듯합니다. 예를 들어 원하는 기능이 돌아가면 설계를 안 했다고 해야 할까요? 아니면 코딩 과정에서 결정한 사항들을 모두 설계라고 해야 할까요? 헷갈릴 때는 사전을 본다는 습관에 따라 위키피디아를 보니 이론적 뉘앙스를 풍기는 정의와 부담스러운 분량의 장구한 설명이 존재합니다.
Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints.
실전에서는 전혀 도움이 되지 않는 듯하다는 생각마저 듭니다. 할 수 없이 스스로의 생각에서 시작해 봅니다. 제가 좋아했던 아름다운 그림을 활용해 봅니다.
일단[2] 즉흥적인 그림으로 생각을 표현합니다.
그릴 때는 몰랐는데 한참 후에 다시 보니 오류네요. Design만 한 것을 실체화Realization 결과라고 할 수는 없으니까요.
기능 요구사항 vs 비기능 요구사항
여러 가지 생각이 뒤엉키는 가운데 또다시 Kent Beck의 글을 탈출구로 사용합니다.
첫 줄만 인용하여 DeepL 합니다.
사람들 머릿속에 맞는 덩어리는 기능 중심으로 찾기가 쉽습니다. 동작이 UI 혹은 결과물로 인해 드러나기 때문이죠. 하지만, 성능을 위한 코드나 중복을 제거하기 위한 작업 같은 것들은 드러나지 않습니다. 소프트웨어 공학에서는 그래서 기능 요구사항과 비기능 요구사항으로 나누는 이분법이 널리 쓰였습니다. 기능 중심이 아니라 사용자 스토리로 뽑는다고 해도 여전히 사용자 관점에서는 보이지 않는 부분이 발생합니다.
그래서 전체 코드를 개념적으로 나눠보면 다음과 같은 식입니다.
현장과 사람 중심의 소프트웨어 개발과 설계
이 상태에서 소프트웨어 설계를 미래를 위한 준비라고 한다면 어떤 행동을 해야 할까요?
제가 마음에 든다고 고백한 Kent Beck의 정의가 반쪽자리라는 느낌을 받지 않으려면 도리어 익숙한 소프트웨어 공학의 개념이나 관계를 벗어나는 일이 필요하단 생각이 듭니다. 그에 대한 대안으로 우리에게 필요한 일이 이미 식별되어 있고 가급적 기록으로 남겨져 있어야 하겠죠. TO DO 리스트를 만들거나 포스트잇으로 식별하거나 JIRA 혹은 두레이로 할 일을 가시화하는 일은 이미 보편적인 일입니다.
이때, 설계의 역할은 무엇일까요? 우선은 업무를 세분화해서 우선순위 높은 일들을 진행하는 것으로 합의를 이루는 팀워크가 중요해 보이는데요. 그랬더니 <개발 팀에 민주적 소통 절차 수립하기>에서 고민한 소통 절차와 다양한 역할과 관심사를 가진 팀원들의 합의와 공감에 대한 중요성이 먼저 떠오릅니다. 하지만, 그중에서 설계만 구분해 보면 어떤 역할을 하나요?
개발자 혹은 프로그래머가 타이핑을 하면서 자연스럽게 혹은 종이에 쓱쓱 그리면서 개발을 하는 경우라면 설계란 활동을 따로 구분할 필요가 없어 보입니다. 반면에 무엇을 개발할지 모르거나 코드를 개선할 방법을 몰라 다른 사람의 개입이나 협업이 필요할 때, '설계'란 활동을 구분할 필요가 있다는 생각이 듭니다.
글이 길어져서 기록하지 못한 생각은 다음 편으로 넘깁니다. Kent Beck의 글이 주는 영감을 따라 생각을 펼쳐서 도달한 마지막 지점은 외부에서 정의한 지식이나 기준이 아니라 현장에서 인식한 할 일을 중심으로 소통을 하는 일이 중요한 인식 전환이란 점입니다. 어쩌면 그것은 제가 도메인 드리븐 혹은 DDD 책을 좋아하는 이유인지도 모릅니다. 또한, 설계가 별도 작업이 아니라 '설계'없이 개발하기 곤란한 경우에 식별하는 '누가 무엇을 설계'하는 일이 될 듯합니다.
주석
[1] 트위터의 바뀐 이름으로 일론 머스크가 이름을 바꾼 것으로 알려져 있습니다.
[2] 엄밀한 정의를 담은 이 그림을 이런 식으로 응용하는 방법에 대해 내적 갈등이 있지만 시도를 해 봅니다.
지난 한국의 마틴 파울러가 되기 연재
2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기
4. 기술 부채를 Code Smell로 관리할 수 있는가?
6. 설계 요소의 사분면
7. 입자와 파동의 이중성을 소프트웨어 설계에 응용하기
