설계 요소의 사분면
한국의 마틴 파울러가 되기
이 글은 최근 있었던 회의에서의 한 장면의 의미를 곱씹어 보며 남기는 글입니다.
지금 내가 말하려는 설계는 무엇인가?
동료에게 했던 '설계'란 말에 대한 오해를 풀기 위해 내가 의도한 의미를 그리고 설명한 기록입니다.
그 상황에서 '설계'는 무엇을 말하는 것이었나에 대한 답이라고 할 수 있습니다. 글을 쓰며 곱씹어 보니 '상황'과 '맥락'이 어떤 차이가 있는지 평소 따지지 않았다는 점이 떠올라 찾아보았습니다.
상황과 맥락의 차이
상황이란 단어는 맥락과는 상당히 다른 뉘앙스의 개념이었습니다. 반면 맥락은 제가 '설계'란 말을 부연하는 기반을 말하는 듯하여 이 상황과 잘 어울리는 표현인 듯합니다.
얼마 전에 썼던 글에서 다룬 '대상과 조건'이 떠오르기도 합니다.
객체가 실행하기 위한 조건은 의존성(dependecies)이라고도 한다. 조건은 대상으로 식별한 다양한 객체들의 조합이다.
어떤 맥락의 설계인가?
질문을 다시 바꿔 보았습니다. 제가 쓴 메모(인용한 이미지)에 대한 제목이라고 할 수 있습니다.
설계와 잘 연결되지 않는 말일 수도 있는 '법(法)'이란 단어를 쓴 배경에는 동료가 설계 근거에 대해 '객관화하기 어렵다'라는 말을 한 탓입니다. 저는 우리가 하려는 일의 맥락에서 '객관화'는 아직 필요한 접근이 아니라 어떤 규정을 만들어야 한다고 설명했습니다. 그것은 구체적인(Specific) 프로토콜의 형태일 수 있다는 가정을 한다는 사실을 설명했습니다.
그러한 규정을 따라 얻을 수 있는 효능은 우리의 자산과 연결할 수 있다는 점입니다. 연결하여 기 구축한 효익을 누리기 위해 따라야 할 것을 분명하게 하기 위한 설계를 상상한 것이었다는 사실을 글을 쓰면서 더 분명하게 깨닫습니다.
이와 구분하고 싶은 또 다른 설계 목표가 있습니다. 이는 자산의 확장을 위해 우리 팀이 아닌 구성원이 만든 코드의 품질을 검증할 수 있는 능력입니다. Quality Control의 약자로 QC라고 썼습니다. KS는 '마치 KS 마크를 찍는 행위처럼'이라는 메타포를 표현한 내용입니다.
이게 설계의 전부인가? 여집합은 없는가?
우리의 맥락에서 위에 설명한 요소가 '설계'의 전부인지를 따져 보았습니다. 그간 경험으로 두 가지가 떠올랐습니다. 하나는 '도메인 스토리텔링'이라는 용어로 묶어서 살펴보았던 업무 규칙의 공유 방법입니다. 가장 효과적인 것은 구두로 하는 일이지만, 이미 자산화된 이후에도 계속 구두로 할 수는 없기에 어떤 형태 혹은 어떤 조합(코드와 문서)이 최적인지 알고 싶은 욕망이 있습니다.[1]
두 번째는 작업량을 판단하기 위한 작업 단위에 대한 부분입니다. 아직 가정이지만 <형상 구성단위로 TestCase 유용할까?>편을 쓸 때 고민한 요소죠.
설계 요소의 사분면
즉흥적이지만 이렇게 뽑아낸 요소를 두 개의 축으로 나눠 보았습니다. 그러고 나서 HBR의 따라 사분면을 만들어 보았습니다.
앞으로 이 가설이 효용성이 있는 확인하는 일을 사후 루틴으로 만들어 봐야겠네요.
주석
[1] 물론, 알고자 하는 욕망 충족 이전에 효용 가치부터 확인해야겠죠.
지난 한국의 마틴 파울러가 되기 연재
2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기
