설계를 바라보는 관점 (feat. 소통의 일부)

안녕하세요. yeTi입니다.
최근에 설계적 관점에 대해서 트리거를 받은 계기가 있어 스스로 가지고 있는 개념에 대해 공유해보고자 합니다. (feat. 소프트웨어 설계 20년 해보고 깨달은 '좋은 설계'의 조건)

좋은 설계

사실 좋다라는 단어는 상대적인 용어입니다. 저에게 있어서 좋은 설계란 실용적으로 활용할 수 있는의 의미가 큰 거 같습니다.

좋은 설계하기 (feat. 의사소통) 편에서도 공유했듯이 저에게 있어서 설계란, 표현에 그치는 수단이었고 문서작업이었으며 신뢰할 수 없는 정보였습니다.

그래서 어떻게하면 유의미하고 쓰임새있는 설계를 할 수 있을지가 항상 숙제였고, 우연치 않은 계기로 나름대로의 개념을 잡아나갈 수 있었다고 생각합니다.

설계의 의미

IT서비스를 만들어나감에 있어서 궁극적으로 필요한 부분은 코드(code)입니다.

비즈니스를 만들어나가고 비즈니스의 성장을 만들어 나가는데 가장 기초가 되는 표현은 코드(code)입니다. 결국 비즈니스의 유연성을 따라가고 폭팔적인 성장을 수용할 수 있는 본질은 코드(code)로 부터 나오는 것입니다.

그렇다면 설계의 목적은 무엇일까요? 가장 효율적인 방법은 서비스의 본질인 코드부터 만들면 됩니다.

저는 협업을 위해 설계라는 과정이 필요하다고 생각합니다. 개발자가 아닌 다양한 사람들과 생각을 공유하기 위해 표현하는 방식들이 설계입니다. 동일한 문제를 보더라도 해결방식은 저마다 다를 수 있고 가장 효율적인 해결방식 또한 논의를 거쳐 나올 수 있기 때문에 가장 쉬운 표현식을 활용하여 최적의 결정을 해나가는 과정이 설계라는 활동이라고 생각합니다.

활용

저는 실무에서 설계라는 활동을 간략하게 수행합니다.

도메인 스토리텔링은 무엇인가?에서 영감을 받아 업무관점에서 서비스를 이해하고 도메인 정보를 식별하여 간략한 API 스펙을 정의합니다. (이부분에 대한 상세 예시는 컨텐츠로 준비중입니다.)

이렇게 하면 장점은 설계가 구체화되는 설계문서이지만 개발자가 아닌 누구와도 협업이 가능한 자료라는 점입니다.

결론

나름대로 생각을 정리하고 소프트웨어 설계 20년 해보고 깨달은 '좋은 설계'의 조건을 다시 읽어보니 딱히 궁금한 부분이나 이견이 없을 정도로 납득이 되는 글이었습니다.

다만 협업을 통하여 설계를 잘 활용한다고 가정했을 때 팀의 의사결정에 접목할 수 있는 기술적 요건들에 대한 부분을 공유해주시면 어떨까하는 생각이 들었습니다.