다른 사람의 모델링은 형상의 차이를 확인할 수 있는 기회입니다. (feat. 좋은 설계)
안녕하세요. yeTi입니다.
오늘은 안영회 대표님께서 포스팅한 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?를 읽고 느낀 점들을 빠르게 기록하고자 합니다.
나에게 모델링이란?
모델링이라는 것에 잣대가 생긴 때는 조영호님의 객체지향의 사실과 오해 를 읽은 시점이었습니다.
후기 : 객체지향의 사실과 오해 독서 후기 (feat. OOP)
책을 읽고 감명깊게 다가왔던 부분은 모델링을 하는 이유는 추상화를 하기 위함이고, 추상화를 하는 이유는 인지 과부하를 줄이기 위해서입니다.
인지 과부하는 왜 줄여야 할까요?
인간의 인지 능력에는 한계가 있기 때문에 현실의 모든 정보를 생각으로써 한 번에 담을 수 없습니다. 그렇기 때문에 우리는 말이라는 개념에 의미를 담아 추상적으로 정보를 주고 받고 있고, 이러한 활동을 모델링이라는 단어로 개발이라는 도메인에서 사용하고 있는 것입니다.
게다가 모델링이라는 것이 UML이라는 표기법과 연결되면서 시각화 단계로 확장되어 사용하기 시작했다고 생각합니다.
나에게 설계란?
2012년 개발이라는 활동을 하면서 설계라는 활동을 시작하게 되었습니다.
당시에 설계는 검수를 받기 위한 산출물을 작성하는 활동이었고 개발을 시작하는 시점에는 어느정도 참고는 했지만 시간이 지남에 따라 설계라는 문서는 실용성이 떨어지는 것을 느꼈습니다.
이것을 인식한 순간부터 효용성이 있는 설계를 알고 싶었고 아직까지 찾아가고 있는 과정입니다.
최근에 확신을 얻은 관점은 하나 있습니다.
설계는 개발의 피드백을 빠르게 받으며 개선해나가야 한다는 것이고, 설계는 목적을 달성하기 위해 형상을 만드는 과정이라는 것입니다. 여기서 만든다는 의미는 상황에 따라 육체적인 활동이 될 수도 있고 정신적인 활동이 될 수도 있습니다.
인식의 차이를 줄여나가는 과정
이제부터 글을 읽으며 느낀 점들을 풀어보고자 합니다.
최근의 경험들로 인해 중요한 인식이라는 생각이 든 문장(포기말)을 인용합니다.
모델러는 프로그램 전체를 그와 같은 형상으로 인식하고 있다는 사실 말이죠.
설계 혹은 업무적인 문서를 검토라는 자리를 만들게 되면 각자가 자신의 주관에서 의견을 내기에 바쁘지 그 문서가 가지는 의미에 대해 생각해보지는 않는 것 같습니다.
그러나 인용문을 인식하게 되면 검토라는 자리에서 중요한 것은 그 문서를 작성한 사람이 그 문제를 인식한 형상을 알 수 있다는 것입니다.
그리고 이렇게 인식을 하게 되면 검토의 시간은 문서를 지적하기 위한 것이 아니라 상대의 형상과 나의 형상을 비교하여 우리가 나아갈 수 있는 중간점을 찾을 수 있다는 것입니다.
이를 설계라는 활동에 비유해보면 설계라는 것은 목적을 달성하기 위해 형상을 만드는 과정인데 이것이 둘 이상의 사람이 얽히게 되면 일을 해나가기 위해서 서로간의 인식하는 형상을 조율하는 과정으로 볼 수도 있습니다.
상대방이 따르는 표준을 활용하라
서로간의 인식을 줄여나가는 과정에서 표현적인 부분에 매몰되면 우리가 풀어야하는 본질에서 벗어날 확률이 높아집니다. 개취인정
이는 켄트 벡의 XP 에서도 효율을 높이려면 내가 좋다고 생각한 것을 상대방에게 강요하지 말고 상대가 원하는 형식에 맞춰주는 것이 효율성이 높아진다고 말하는 것도 같은 의미로 다가옵니다.
설계라는 활동에서 상대방의 표준을 따라야하는 이유는 우리가 풀어나가야하는 것은 문제라고 인식한 현상이지 시각화된 자료의 표현 형식이 아니기 때문입니다.
우리가 표현 형식에 매몰되기 시작하면 감정에 매몰되어 시간을 허비할 확률이 높아집니다.
결론
안영회 대표님님께서 피드백을 말씀하셔서 간단한 답변보다는 이번 기회에 스스로도 설계를 인식하는 것을 명시적으로 정리하는 것이 좋다고 생각하여 빠르게 글을 작성해봤습니다.
이번 기회까지 스스로 정의한 설계 활동을 정의하면 이렇습니다.
- 개발의 피드백을 빠르게 받으며 개선하는 활동
- 목적을 달성하기 위해 형상을 만드는 과정 (만듬이란 육체적이거나 정신적)
- 서로간의 인식한 형상을 조율하는 과정
- 형식이 아닌 문제를 보는 과정
마지막으로 제가 설계라는 관점을 바꿀 수 있도록 도와준 문장(포기말)을 인용하고 글을 마무리합니다. 도메인 모델, Ongoing 설계 그리고 정원관리
Diagrams are not designs
아키텍처는 의사소통에 관한 문제다.