자기중심에서 팀 중심으로 확대하기
설계: 생각을 ‘차려’ 물질로 만드는 힘
<내가 아닌 다른 사람은 모델링을 왜 하게 되는가?>를 쓰고 나서 얻은 생각을 추가하는 글입니다.
설계: 어떻게 자기 중심성을 넘어설 것인가?
상당 기간 묻따풀 활동으로 최봉영 선생님께 배운 내용이 있습니다. 자신의 말에는 어쩔 수 없이 자기 중심성이 담길 수밖에 없다는 사실입니다. 말을 쓰는 일이 기본적으로 자기 중심성에서 시작한다면, 설계는 그러한 자기 중심성을 넘어서 팀 중심으로 생각을 확대하는 활동이란 생각이 들었습니다.
계기가 있었습니다. 저에게 다시 한번 설계에 대한 열정을 살리게 해 준 동료들이 있는데요. 다음에 인용한 내용은 그중 한 분이 <설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다>를 읽고 전한 영감 넘치는 피드백입니다.
아마도 이 글을 읽으며 '팀 중심성'이란 단어가 제 머릿속에서 나온 듯합니다. 물론 그전에 '자기 중심성'이 있었기에 대칭적으로 생각이 확장된 것이겠죠. '중심성'을 일종의 라임(rhyme) 혹은 공통분모로 삼아서...
중심 가치를 바꾸기: 나의 가치에서 팀의 가치로
요즘IT 올린 설계에 대한 글을 쓸 때 '설득 또한 설계의 일부다'라는 표현이 마음에 들지 않았습니다. 다만 더 나은 대안이 떠오르지 않아 찜찜한 마음으로 선택한 표현이 '설득'이었습니다. 그런데 이를 설득이라 하지 않고 자기 중심성을 벗어나서 팀 중심성으로 나아가는 일이라고 생각하니 설득이란 말이 주는 찜찜함이 사라지는 듯합니다.
자기 중심성을 벗어나는 길은 우물 안 개구리에서 나오는 능력에 비견할 만합니다. 팀 중심적 사고는 스스로의 확신을 일부나마 포기할 수 있을 때 도달 가능한 상태라고 할 수 있습니다. 한편, 전달하고 싶은 사람이 잘 차려서 팀의 다른 사람도 공감할 수 있도록 확연하게 드러내는 노력해야 합니다. 그게 설득과 비슷해 보여 그렇게 표현했던 듯합니다.
하지만, <설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다>에서 주장한 대로 함께 하려면 서로 합의되는 기반이 필요합니다. 그렇게 보면, 팀의 비전이나 목표가 명확해지는 일이 매우 중요합니다.
도메인이 무엇인가요?
이와 관련해서 전에 모델링에 대한 글을 쓰는 과정에서 이전에 제가 쓴 <도메인이 무엇인가요?>를 발견하고 마지막 다발말(=단락)이 마음에 든다고 생각한 일이 있습니다.
문제는 세상을 보는 창을 제공한다. 무엇을 문제로 삶을 것이냐에 따라 내 시간을 어디에 집중할지 결정할 수 있다. 이때, 문제를 함수라는 시각으로 보면 더욱 단순하게 문제의 핵심에 집중할 수 있다.
UML을 쓰던 시절 많은 문서에서 Problem Domain 그리고 Solution Domain이라는 말을 자주 썼습니다. 소프트웨어 설계가 '생각'을 주된 재료로 하는 활동이라고 한다면 '어디에 집중할 것인가?'라는 질문은 문제 영역(Problem Domain)을 명확하게 하는데 좋은 질문이란 생각이 듭니다.
한편, 모델링에 대해서 글을 쓸 때 발견한 내용 중에 다음 그림도 매우 인상적으로 다가왔습니다.
본보기와 쓰임새
하지만, 또 문제 영역에 대한 정의만으로는 그래서 무엇을 만들자는 것인지가 눈에 들어오지 않을 수도 있습니다. 그래서, 이런 생각이 들었습니다.
쓰임새와 본보기가 주어지면 대강의 윤곽과 방향성이 눈에 들어오겠구나
사실 < 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?>를 쓰는 과정이 없었더라면 떠올릴 수 없는 포기말입니다. 눈에 보이는 예로 도시 공간을 생각해 보면 어느 도시건 항상 랜드마크가 있습니다. 또 다른 예로 운동장에서 줄을 설 때, 기준을 잡아야 했던 것도 떠오릅니다. 그렇게 하면 공간에 방향이나 간격 같은 것들이 의미를 부여받습니다. 생각에 대해 설명을 하려다 보니 자연스럽게 눈에 보이는 요소들을 은유하게 됩니다. 결국 생각의 약점은 눈에 보이지 않아서 전달 혹은 유통에 어려움을 겪는다는 점입니다. 그렇기 때문에 생각이 명확해지려면 어떤 형태로든 눈에 보이게 해야 합니다.
설계란 결국 번역인가?
생각이 여기에 미치자 페북으로 <모델링에 대한 메타 인지: 모델링이라는 생각 차림법>을 소개할 때
페벗님이 주셨던 댓글 내용이 떠오릅니다.
머릿속에 담고 있던 아이디어를 이해관계자 그리고 함께 만들어 갈 동료들과 나누기 위한 작업이 설계이고, 이는 생각의 단위로 알려진 '말'을 타인과 다수가 이해할 수 있도록 '번역'하는 일로 볼 수 있다는 생각에 페벗 님의 댓글에 동의하게 되었습니다. 이에 대해서는 다른 글에서 자세히 다루기로 하겠습니다.
지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재
1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?
4. 설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다
7. Event Driven의 기원과 현실적인 활용 방법
8. 모델링에 대한 메타 인지: 모델링이라는 생각 차림법
10. 업무 분석 과정에서 UML 클래스도를 쓰면 얻는 것
