[ Study Log ] Design Thinking 에 관하여

Design Thinking

개발자에서 아키텍트로 - 예스24

이 내용은 "개발자에서 아키텍트로" 책을 읽고서 내용을 정리해본 내용입니다. 내돈내산! 좋은내용 정리!

 

Background Knowledge(배경지식)

나는 아키텍처에 대한 관심이 많다. 담당하는 프로젝트의 아키텍처를 이해해야 올바른 개발을 해낼 수 있다 생각하기 때문이다. 그래서 나는 소프트웨어 아키텍처의 특성과 다양한 설계에 대한 공부를 진행했다. 하지만 공부를 하고 실제 업에서 적용해볼 기회가 생겼을 때, 나는 어떤 아키텍처가 최적의 아키텍처이고 어떻게 결정을 해야할지 판단을 하기가 어려웠다.
이런 고민을 가진 상황에서 "개발자에서 아키텍트로" 라는 책을 읽으며, 디자인 싱킹(Design Thinking) 이라는 것을 처음 알게 되었다. 디자인 싱킹은 문제를 해결하려는 과정이라기 보다는, 문제와 해결책 그리고 이에 영향을 받는 사람들의 관점에 대해 생각하는 방식이라고 이야기 할 수 있다.
 
추가적으로 이후로 나오는 디자인 마인드 셋(생각-실행-확인) 에대한 내용도 굉장히 도움이 많이될 듯 하여, 기록하여 정리하면 좋을 것 같다.

Preliminary Questions(사전질문)

• 디자인 싱킹의 기본 원칙은 무엇인가?
• 디자인 싱킹은 기존의 문제 해결 접근 방식과 어떻게 다른가?
• 실제 프로젝트나 업무 환경에 디자인 싱킹을 적용하려면 어떤 단계를 밟아야 하는가?

---

Contents

디자인 싱킹(Design Thinking)에 대하여

소프트웨어 시스템을 설계하는 일은 문제 해결을 하는 동시에 아직 발견되지 못한 문제를 찾아가는 일이다. 그리고 이 일은 결코 쉬운 일이 아니다. 그러나 이 때, 디자인 싱킹(Design Thinking) 을 활용한다면 큰 도움이 될 수 있다.
디자인 싱킹이란 문제 해결의 모든 기준을 인간에게 두고, 창의적이고 분석적으로 문제를 풀어나가는 접근법이다. 인간의 초점을 중심으로한 방법을 통해 설계에 대한 의사결정 과정 중 문제의 본질에 보다 더 집중할 수 있다.

• 해결법을 찾을 때마다 소프트웨어의 만드는 목적이 사람을 돕는 일이라는 것을 일 깨워 줄 수 있다.

 

디자인 싱킹의 원칙

디자인 싱킹은 문제 해결과정은 아니지만, 설계 활동에 대한 규칙은 존재한다. 이 원칙은 크리스토프 마이넬과 래리 라이퍼의 Design Thinking(Springer, 2013) 에서 언급되었다. 그리고 이 원칙은 소프트웨어 아키텍처 뿐만아니라 세부적인 프로그램 설계, UI 디자인 등 어떤 분야에도 적용할 수 있다.

• 인간 중심 원칙(human rule): 모든 디자인은 사회적이다.
• 모호함의 원칙(ambiguity rule): 모호함을 유지하라.
• 재디자인의 원칙(redesign rule): 모든 디자인은 다시 디자인 한 것이다.
• 촉각의 원칙(tangibility rule): 손에 잡히는 디자인이대화를 이끌어 낸다.

 

인간 중심원칙(human rule): 모든 디자인은 사회적이다.

디자이는 본질적으로 인간 중심적인 노력이다. 우리는 사람을 위해 소프트웨어를 디자인하며, 사람들과 함께 소프트웨어를 디자인 한다.

• 설계에 대한 모든 의사결정은 사람이 이해할 수 있어야 하고 다른 사람들과 공유할 수 있어야 한다.
• 아키텍처를 설계할 때에는 모든 이해관계자들과 공감대를 형성해야 한다.
• 소프트웨어를 설계할 때는 팀의 여러 사람들과 협업해야하며, 사람을 존중하는 마음가짐으로 의견을 경청하고 긍정적인 의지를 표현하고 인간 중심적인 설계 방법을 활용해야 한다.
• 직접적이든 간접적이든 시스템 설계에 관여했던 사람들 한 명 한 명을 신경 쓸수록 더 나은 설계자이자 커뮤니케이터 이자 리더가 될 수 있다.

 

모호함의 원칙(ambiguity rule): 모호함을 유지하라.

엔지니어링에서 모호함은 곧 위험이다. 설계에 대한 의사결정을 내릴 때에는 정확하고 명료해야 한다. 하지만 설계를 확정하기 전까지는 모호함을 나두는 방법이 유용할 수 있다. 모호함을 유지하여 주변 상황이 바뀌더라도 소프트웨어를 제때 공급할 수 있기 때문이다.

• 요구사항, 설계 조건, 모호한 의견들을 애매하게 내버려두면 프로젝트는 완전히 망할 수 있다.

소프트웨어 아키텍처의 목적은 품질 속성을 끌어 올릴 수 있도록 여러 구조를 정리하는 것이다. 그리고 이와 관련하여, 이를 달성하기에 좋은 방법은 최소한의 아키텍처(minimalist architecture) 를 만드는 것이 좋다.

• 최소한의 아키텍처는 당성해야 하는 가장 중요도가 노퓨은 품질 속성만 제시해 이 품질 속성을 방해하는 위험 요소는 줄이며, 그 이외의 설계에 대한 모든 의사결정은 하위 설계자들이 알아서 결정하게 하는 방법을 말한다.
• 최소주의(minimalism) 은 책임 있는 범위만큼만 설계에 대한 의사결정을 하겠다는 의미이다.
• 품질 속성에 직접 영향을 미치지 않거나 소프트웨어를 제때 공급하지 못하는 위험은 소프트웨어 아키텍처보다는 설계상의 세부사항에 해당한다.

 

재디자인의 원칙(redesign rule): 모든 디자인은 다시 디자인 한 것이다.

"다시 디자인 한다." 는 의미는 과거의 디자인에서 패턴을 찾고 고찰해보는 것이다. 소프트웨어를 만들수록 더 나은 소프트웨어를 만드는 지식도 발전한다. 지금 겪는 문제는 어떤 팀이 이미 겪은 문제일 수 있으며, 이에 대해 문서화를 했다면 그 문서를 기반으로 설계를 시작할 수 있다.

• 소프트웨어 아키텍처를 설계할 때 바닥부터 새롭게 만드는 것 보다 현재의 설계를 갈고닦는 데에 더 많은 시간을 사용하는 것이 효율적이다.
• 과거에 존재했던 시스템을 무시하는 것은 몹시 비효율적인 방법 중 하나라고 말할 수 있다.

 

촉각의 원칙(tangibility rule): 손에 잡히는 디자인이대화를 이끌어 낸다.

소프트웨어에서 아키텍처는 코드로 작성되어 있지만, 코드는 읽기 어렵고, 품질 속성이나 크게 나눈 컴포넌트, 설계의 논리적 근거나 의사결정에 대하여 토론하기 어렵다.

• 아키텍처를 손에 잡히게 하기 위해 그림으로 그리고, 코드로 구현하는 것이 좋다.
• 프로토 타입을 만들어 사람들이 품질 속성과 아키텍처를 직접 경험할 수 있도록 해야한다.
• 단순한 모델을 통해 아키텍처의 한 부분을 보여주고, 공감할 수 있는 메타포를 만든다.
• 시스템 흐름의 일부를 직접 동작한다.

---

Study Reflection

Answers to Preliminary Questions(사전 질문에 대한 답변)

디자인 싱킹의 기본 원칙은 무엇인가?

디자인 싱킹(Design Thinking)는 인간 중심 원칙을 중심으로 창의성과 분석적 문제 해결을 강조하는 방법론이다. 여기에는 인간의 관점에 초점을 맞추고, 필요한 경우 모호성을 유지하며, 지속적인 프로세스로 재디자인을 수용하고, 효과적인 의사소통을 위해 디자인을 실체화한다.

디자인 싱킹은 기존의 문제 해결 접근 방식과 어떻게 다른가?

전통적인 문제 해결과 달리 디자인 사고는 선형 프로세스를 따르지 않는다. 이는 보다 반복적이고 공감적이며 협력적인 접근 방식을 추구한다. 초기 단계에서 모호함을 유지하고, 지속적인 재설계를 하며, 더 나은 이해를 위해 디자인을 실체화하는 것을 중요하게 생각하는 방법이다.
 

실제 프로젝트나 업무 환경에 디자인 싱킹을 적용하려면 어떤 단계를 밟아야 하는가?

디자인싱킹을 실제적으로 적용하려면 디자인 싱킹의 원칙을 준수하면 좋다.

• 의사결정 과정에 이해관계자를 참여시키는 인간 중심 디자인을 강조한다.
• 솔루션을 탐색할 때 모호함을 유지한다.
• 피드백과 진화하는 요구 사항을 기반으로 지속적으로 재설계하며, 기존의 설계를 적극 활용한다.
• 효과적인 커뮤니케이션을 위해 프로토타입을 통해 디자인을 실체화한다.

이러한 원칙을 통합함으로써 소프트웨어 아키텍처 및 설계에 대한 의사 결정을 향상 시킬 수 있으며, 디자인 싱킹을 적용할 수 있다.
 

Evolving Thoughts

최근 새로 입사한 회사에서 기존 프로젝트의 리팩터링(사실상 리뉴얼)의 이야기를 들었다. 아키텍처가 변경되고, 중점으로 생각하는 개발론이 바뀔정도로 큰 변경이 예정되어 있었다. 이 과정에서 내가 알고 있는 아키텍처 및 코드 설계에 대한 지식을 공유하면서 도움이 되고자 했는데, 제안까지는 몇가지 어려움이 있었다.

• 각 선택에 대한 비교는 할 수 있으나, 결국 어떤 걸 선택해야할지 몰랐다.
  • 우리만의 아키텍처를 설계하는 것 VS 전통적인 아키텍처를 선택하는 것
  • 여러 프로그래밍 방법론 중 우리에게 더 알맞은 방법론을 선택하는 것
  • 다양한 프로그래밍 언어와 프레임워크 중 적절한 것을 선택하는 것
• 결론에 도달하는데 있어서 개인적인 성향이 추가되는 경향을 보였다.

언급한 어려움 외에도 추가적인 고민이 존재하였고, 이를 극복하기위해 많은 시간 고민하였다. 그러다, 디자인 싱킹이라는 것을 알게되었고, 이것이 생각보다 큰 도움이 될 것 같다.

• 내가 어려움을 느낀 부분들에 대하여 도움이 되는 부분이 많았다.
  • 현재 전달 받은 리팩터링 방안에 대하여, "내가 기여할 수 있는 부분은 무엇일까?" 에 대한 고민이 많았으나, 좋은 아키텍처는 함께 디자인 할 때 더 좋은 아키텍처가 될 수 있음을 이해할 수 있었다.
  • 나는 요구사항(목적)과 상황을 분명하게 한 뒤에서야 우리가 작업을 진행할수 있을 것이라고 생각했다. 이로 인해 작업 속도가 생각보다 더뎠다. 나는 이 부분을 개선하고 싶었고, 최소한의 아키텍처를 설계하고, 프로토 타입, 그림 와 같은 다양한 시각화 자료를 만들어 이 문제를 극복해 낼 수 있음을 알게 되었다.
  • 정형화된 계획 -> 실행의 선형 프로세스가 아닌 반복적인 프로세스를 선택함으로써, 보다 빠르고 효율적인 작업 프로세스를 구축할 수 있음을 알게되었다.