좋은 설계하기 (feat. 의사소통)

안녕하세요. yeTi입니다.
오늘은 설계하는 시각을 바꾸게된 경험을 공유하려고 합니다.

지난 날

지난 시간동안 저에게 설계를 한다는 것은 매우 어려운 일 중 하나였습니다.

폭포수 모델기반 설계

폭포수 모델기반 프로젝트를 진행할 때 UML 을 활용하여 산출물 이라는 것들을 만들곤 했는데요.

UML 을 어떻게 활용해야 유의미한 설계가 되는지는 이해하지 못했습니다. 왜냐하면 설계문서 작성 배정을 받은 다음 검토라는 단계가 없이 승인 및 구현에 들어가 피드백을 받을 수 없었습니다.

또한 구현시에 설계의 부족한 부분이 확인되더라도 설계문서의 수정없이 개발 효율만을 생각하며 개발을 하는 환경이었고, 프로젝트 마지막에 산출물 현행화라는 방식으로 설계문서를 현행화하는 시간을 가졌습니다.

설계는 산출물을 위한 것인가

그렇게 산출물에 대한 회의감 을 가지는 시점에 애자일 이라는 것을 알게 되었고, 애자일을 수행하면 무의미한 산출물이라는 작업을 최소화하면서 실질적인 제품을 만들 수 있다고 생각했습니다.

스크럼에서 설계란?

그렇게 스크럼 이라는 것을 시도허면서 여전히 생각은 폭포수 모델에 갇혀 있었습니다.

개발을 해야하는데.. 전체 틀을 잡아야하지 않을까? 스크럼에는 설계 기간이라는게 없는데? 폭포수 모델에서 사용하던 산출물을 사용해볼까?

그렇게 폭포수+애자일 이라는 변형된 형식에서 의구심만 가진채, 실질적인 개발을 위한 고민만 해나갔습니다.

설계에 대한 생각 바꾸기

이후 설계에 대한 생각을 바로잡아 줄 수 있는 글들을 접하게되었습니다.

Diagrams are not designs

https://brunch.co.kr/@graypool/490

!!!!!
나는 지금까지 어떻게하면 그림을 잘 그려서 설계를 완성할 수 있을까 를 고민했었는데..

지금까지 내가 UML을 잘 몰라서. 혹은 디자인 패턴을 잘 몰라서. 혹은 OOP, TDD 를 잘 몰라서 설계가 어렵게 느껴진다고 생각했습니다.

다이어그램을 잘 그리면 설계를 잘하게 된다고 생각했던 것이죠.

모델의 가치는 추상화인데, 코드와 일대일 대응을 시도하면 그 장점을 모두 훼손된다.

https://brunch.co.kr/@graypool/490

!!!!!
나는 지금까지 설계문서에 코드가 표현되어야하고 뿐만아니라 우리가 고려한 모든것이 표현되면 좋겠다는 생각을 했습니다.

그러다보니 설계문서는 복잡해지고, 관점이 섞이고, 그러다보니 또 어렵고...

반면에 모델이란 내가 표현하고 싶은것을 나타내도록 추상화를 하는것 이라고 생각하니 모든 어려움이 단숨에 해소되었습니다.

아키텍처는 의사소통에 관한 문제다.

https://brunch.co.kr/@graypool/438

!!!!!
한번도 시도해보지 않은 두 단어의 괸계 결합이 충격적으로 느껴졌습니다.

지금까지 설계의 문제를 부족한 자신의 문제로 보던것을 의사소통의 관점으로 돌려보니 설계라는 것이 보다 쉽게 느껴졌던 것입니다.

다이어그램을 그리는데 ,누구와 무엇을 소통하기 위해 그릴까 를 서두에 던져놓으면 적절한 추상화가 가능하고 읽히기 쉬운 표현을 하게 됩니다.

그리고 읽히기 쉽도록 추상화가 되다보니 의사소통이 가능해지고 대화를 이어나가다보니 고려되지 않았던 것들이 보이기 시작하는 선순환 구조 가 됩니다.

좋은 설계하기

저는 요즘 UML을 사용하지 않습니다.

생각의 동기화

화이트보드 나 노트 필기 를 사용합니다. 왜냐하면 혼자서 그리는 다이어그램과 여럿이 모여 그리는 그림은 생각의 동기화의 수준이 다르다는 것을 현업에 적용해보면서 느꼈습니다.

얘기를 하며 그리는 그림이 생각의 동기화를 빠르게 맞출 수 있고, 그 이후에 나타나는 피드백들은 설계를 보다 탄탄하게 하는게 도움을 줍니다.

스토리단위 설계

제품 전체를 설계하기 보다는 작은 단위의 문제 를 풀 수 있도록 스토리 단위의 설계를 수행합니다.

현업에 적용해본 결과 스프린트 단위의 기능기반 설계를 하게되면 검토량이 믾다보니 설계기간도 길어지게 되고 기획의 지체가 개발에 영향을 많이 줬었고, 기능간 연결성도 놓치는 문제들이 있었습니다.

반면 스토리단위로 작업을 하다보니 기획이 확정되는 것부터 설계를 진행하면 개발까지 순조롭고 빠르게 하나의 스토리가 끝나는 경험을 했습니다.

설계의 때

불확실성을 대응하기위한 고민을 하지 않습니다.

일을 하다보면 다음과 같은 질문을 받습니다.

이렇게 설계하면 나중에 좋을 꺼 같은데요..

그러면 저는 이렇게 답을 합니다.

그 나중이 언제일까요? 그리고 혹시 나중에 예상처럼 변경될 가능성은요?

최적의 설계를 위해 판단의 시기를 늦추 거나 그러지 못할 경우에는 최소한의 설계 가 추후 서비스 개선 비용을 줄이는데 도움이 됩니다.

설계는 대화의 소스이다

설계를 하게되면 다른 구성원에게 의견을 물어봅니다. 이 때, 문서만 던져주고 보세요. 하는것이 아니고 화이트보드에 설명을 합니다.

그렇게함으로써 고려하지 못했던 부분에 대한 피드백 을 받을 수 있어 설계를 보완하는데 도움이 됩니다.

설계는 이쁜 문서가 아니다

설계 문서을 위해 이쁘게 다시 그리지 않습니다.

의사소통했던 공간을 그대로 사진으로 찍어 보관 합니다. 이쁜 그림과의 차이점은 기억을 회상할 수 있습니다. 가령 혼자그린 문서는 회상되는 경우가 거의 없습니다.

반면 같이 토의한 흔적은 다시 보게되면 그 때의 상황이 어렴풋이 기억날 때가 있어 보다 생동감있게 기억을 유지할 수 있습니다.

다양한 구성원이 모이면 좋다

설계를 하다보면 각 분야에 잘 아는 사람들을 초대하여 같이 얘기하는것이 좋습니다.

가령 기획자, DBA, 도메인 전문가, ...

보다 다양한 시각에서 합의된 설계안은 혼자했을 때보다 탄탄합니다.

경험에 기반하여 기획을 무시하지 않습니다.

서비스는 획일적으로 찍어내는것이 아닙니다.

비슷한 서비스의 과거 경험은 존중받아야하고 현 서비스의 초석으로 삼아야함은 마땅하지만,

현재 데이터나 상황은 고려하지 않고, 과거에 그랬으니까 지금도 그래야해 와 같은 생각은 현재 서비스를 만들어감에 있어, 그리고 유기적인 설계를 해나감에 있어 방해요소 라고 생각합니다.

마무리

저처럼 설계가 뭔지도 잘 모르겠고 어렵게만 느껴지시는 분들이 계시다면

문제 해결을 위한 의사소통의 수단으로 설계 라는 것을 활용해보시는것을 추천 드립니다.

설계 뿐만 아니라 많은 부분들이 다르게 와닿기 시작하실 것입니다.