디자인 스튜디오는 그룹 협업을 장려하고 팀이 짧은 시간 내에 광범위한 아이디어를 낼 수 있는 프로그램을 말한다.
9.1 아키텍처 디자인 스튜디오 계획하기
디자인 스튜디오를 진행할 때 엄격하게 제한된 시간을 설정하고 시간 안에 다양한 아이디어를 가능한 빠르게 많이 쏟아내게 합니다. 디자인 스튜디오 워크숍은 3F 원칙(빠르고, 효과적이며, 재미있게)으로 운영하며 설계 의사 결정을 만들어 갑니다. 재미는 참여를 도모해 탐색 과정을 효과적이고 빠르게 만들어 줍니다.
디자인 스튜디오를 진행하면 3가지 유형의 아이디어를 도출할 수 있습니다.
- 구체화할 아이디어 : 어떤 아이디어는 유망해 보입니다. 유망한 아이디어는 모델이나 프로토타입을 만들어 세부사항을 구체화합니다.
- 연구가 더 필요한 아이디어 : 어떤 아이디어는 옳아 보이지만, 광범위한 가정으로 구성되거나 중요한 정보가 빠져 있습니다. 실험을 실행하거나 연구를 수행함으로써 이러한 아이디어를 더 자세히 조사해야 합니다. 조사 과정에서 얻은 내용에 따라 일부 아이디어는 절절하지 않을 수 있고, 다른 아이디어는 아키텍처 후보가 될 수 있습니다.
- 질문을 여는 아이디어 : 때로는 문제를 해결하다가 새로운 질문만 얻게 되는 경우도 있습니다. 이는 디자인 스튜디오 워크숍에서 얻을 수 있는 최고의 결과입니다. 몇 주 동안 코딩을 하지 않았을 때보다 현재 시점에는 이런 질문을 얻는 편이 낫습니다. 이해관계자들에게 새로 얻은 질문을 다시 전하고, 그 답으로 문제를 더 잘 이해할 수 있습니다.
- 준비하기 : 탐색할 문제를 파악하고 조사한다.
- 시작하기 : 워크숍의 목표와 해결해야 할 문제를 기술하고 그룹에게 알린다.
- 만들기 : 모델을 만들고 스케치하고 프로토타입을 만든다. 대체로 시간을 정해놓고 진행한다.
- 공유하기 : 만들었던 작업물을 그룹원들이게 발표하고, 설계 결과가 어떻게 목표를 달성할 수 있는지를 설명한다.
- 비평하기 : 그룹원들은 발표를 듣고 목표를 충족했는지에 대해 피드백한다.
- 반복하기 : 위에 3~5단계를 반복한다. 모델을 수정하고 새롭게 만든다. 하나의 목표를 탐색하는데 적어도 세 번 반복한다.
- 대응하기 : 가장 적절한 아이디어나 위험성, 질문 등을 가지고 다음 단계를 결정한다.
9.1.1 워크숍 준비하기
디자인 스튜디오 워크숍을 시작하기 전에 목표를 정하고 누가 참여할지 결정해야 합니다. 직접 탐색해야 할 문제를 부분적으로라도 제대로 이해하지 못한 채 여럿이 모여서 아키텍처를 설계하는 건 다른 사람들의 시간까지 헛되게 보내는 일입니다.
워크숍 준비를 과소평가해서는 안됩니다. 이해관계자들과 대화하고, 연구하고, 비즈니스 목표를 정의해야 합니다. 품질속성을 포함해 아키텍처 핵심요구사항(ASR)을 세부적으로 구분해야 합니다. 하나 또는 두 개의 워크숍 목표를 정의해 그룹원들이 워크숍 동안 무엇을 탐구할 것인지를 명확히 해야 합니다.
워크숍을 준비하는데 며칠 또는 몇 주가 걸릴 수 있습니다. 시작하기 전에 적어도 비즈니스 목표 초안과 아키텍처 핵심 요구사항은 꼭 있어야 합니다. 프로젝트의 맥락을 파악했고 워크숍 표도 합리적이라는 생각이 들면 이제 워크숍을 시작할 수 있습니다.
아래와 같은 목표를 탐구해야 한다면... | 아래와 같이 말할 수 있습니다. |
품질 속성 | "우리에겐 확장성과 신뢰성이 가장 중요한 품질 속성 입니다. 어떻게 해야 둘다 끌어올릴 수 있을까요?"(구체적인 시나리오를 함께 제시한다.) |
컴포넌트 간 인터페이스 | "우리는 API 개발에 REST를 채택하기로 했습니다. 이를 위해 시스템에 어떤 부분을 살펴야 하는지 봅시다"(모두 RESTfull 아키텍처를 이해하고 있다고 가정한다.) |
도메인 모델 | "이해관계자들의 비즈니스를 파악해보니, 시스템에서 공통적으로 추상화 할 수 있는 부분이 있어 보입니다." |
곤란한 상황에서 벗어나기 | "10년 전 시스템을 처음 설계했을 때에는 상상하지 못할 정도의 데이터가 쌓이고 있습니다. 이를 극복할 수 있는 방법을 최대한 많이 찾아봅시다." |
할당 구조 | "시스템을 구분해 최대한 병렬적으로 개발합시다." |
패턴 선택 | "A에서 얻은 데이터를 B로 보낼 때 어떤 방법이 있는지 조사해봅시다. 그 다음 각각의 장단점을 비교해 봅시다" |
가능한 한 많은 아이디어 | "오늘은 최대한 다양한 아이디어를 얻고 싶습니다. 적어도 각자 아이디어를 5개 이상 개진해주세요" |
9.1.2 워크숍 시작하기
워크숍을 시작합니다. 지금까지 파악한 문제점과 아키텍처를 공유해 모두가 같은 맥락을 이해할 수 있도록 합니다. 그리고 탐색해야 할 영역에 연관된 모든 내용을 검토합니다. 그룹원들과 맥락을 공유하는 시간은 그룹원들의 배경지식이 적을수록 오래 걸립니다. 만약 참가자가 비즈니스 목표나 ASR을 모른다면 더 많은 시간을 쏟아서 눈높이를 맞춰야 합니다.
모든 참가자들과 눈높이를 맞췄으면 이제 워크숍 목표를 간략히 설명 합니다. 목표는 워크샵 전체를 관통하며 그룹의 집중력을 유지시킬 겁니다. 그리 하여 워크숍을 진행하는 동안 모든 참가자의 설계작업이 목표를 충족시키도록 집중하게 할 수 있습니다. 또한 설계하면서 도출된 아이디어를 비평할 때도 목표를 염두해 두고 진행할 수 있습니다.
9.1.3 중간 과정 반복하기
워크숍의 대부분은 '만들기 - 공유하기 - 비평하기' 과정의 반복입니다.
만들기
만들기 단계에서 참가자들은 혼자 작업하거나 소그룹으로 모여서 목표로 제시된 문제를 해결할 수 있는 아이디어를 스케치하거나 모델링합니다. 디지털 기기를 동원하지 않고 아날로그 도구를 사용하는 편이 훨씬 좋습니다. 펜이나 보드마커를 사용하면 아이디어에 집중하는 분위기를 만들 수 있습니다. 이 시기에는 정교함이나 완벽함 보다는 아이디어를 더 우선해야 합니다. 시간의 경우 5~7분 정도로 제한합니다.
공유하기
만들기 단계에서 모두 무엇인가를 만들었다면 이제 모두에게 공유할 때입니다. 공유단계는 피치라고도 표현하는데 아이디어를 툭 던져야 하기 때문입니다. 소그룹별로 3~5분씩 공유할 시간을 줍니다. 무엇을 만들었고, 그 설계가 어떻게 목표를 충족시킬 수 있는지를 설명합니다. 핵심만 말해야 하며 모든 내용을 브리핑하지 말아야 합니다. 공유하기 단계에서 참가자들은 듣기만 하고 질문하지 않습니다. 질문을 비롯한 여러 가지 첨언의 기회는 비평하기 단계에서 이루어집니다.
비평하기
공유하기 단계가 끝나면 즉시 다른 참가자들은 아이디어에 대해 비평할 기회를 가집니다. 비평하기 단계에서 오가는 피드백은 오로지 목표에 관한 설계상의 장점에만 초점을 맞춰야 합니다. 이렇게 해야 건설적인 대화를 쌓아 갈 수 있습니다. 예를 들면 이렇게 합니다. " 해당 설계는 어떤 이유로 목표를 충족시키지 못합니까?" "설계가 요구사항을 충족하지 못하는 이유는 무엇입니까?"
비평을 진행하는 동안 모두가 명확하게 사실에만 근거해서 말하도록 노력해야 합니다.
바람직한 비평 | 피해야 할 비평 |
설계 목표와 설계자가 제안한 해결 방식에 집중한다. | 비평을 받을 때 방어적인 자세를 취한다. |
구체적으로 사실에 근거해 말한다. | 개인적인 취향을 말한다. |
문제를 더 명확하게 파악하도록 질문한다. | 문제 해결에 주변만 짚는다. |
위험 요소를 지적하고 설계 때문에 새롭게 바생할 문제에 대해 알려준다. | 악랄하게 군다(다음 희생양은 당신이 될 거야) |
설계상의 이점을 언급한다. | 단점만 파헤친다. |
비평은 설계의 장점을 드러낼 수 있도록 해야 하며, 비평 덕분에 더 발전할 수 있는 비평이 되어야 한다. 나쁜 설계 속에 좋은 아이디어가 숨어 있기도 하고, 최고의 설계에도 발전할 구석은 있기 마련이다. 어떤 설계든, 긍정적인 피트백과 건설적인 비평을 바게 해야 합니다. 모든 그룹이 아이디를 공유했으면 다시 처음부터 반복합니다.
반복하기
'만들기 - 반복하기 - 비평하기'를 반복하면서 아이디어를 빠르게 구분하고 융합합니다. 만들기 단계에서는 새로운 아이디어를 만들고, 공유하기 단계에서는 서로의 아이디어를 섞으며 우연한 영감을 탄생시킵니다. 비평하기 단계에서는 불필요한 요소를 없애고 더 나은 해결 방법을 도출하게 합니다.
새로운 반복 회차마다 그룹 구성원들을 섞어 보세요. 구성원들을 역동적으로 섞을수록 더 폭넓게 탐색할 수 있고 집단에 대한 소속감도 커집니다. 구성원이 홀로 일하고 있다면 짝을 만들어주거나 소규모로 그룹을 지어줍니다. 여럿이 일하고 있다면 다른 그룹 구성원과 섞어 봅니다. 워크숍을 진행할 때 적어도 3번의 온전히 '만들기 - 공유하기 - 비평하기' 과정을 반복하도록 계획해야 합니다.
워크숍 마무리와 다음 계획 세우기
워크샵 마무리는 깔끔하고 탄탄해야 합니다. 마무리 때문에 생산적인 워크숍이었다는 평과 즐겁지만 시간 낭비였다는 평이 갈릴 수 있습니다. 워크숍을 마무리하며 새로운 주제를 나누고 그룹별로 소활 수 있는 시간을 줍니다. 그리고 명확한 실행 아이템을 정합니다. 어떤 아이디어가 유망해 보이고 더 많은 관심을 받아야 하나요? 해결해야만 하는 위험 요소는 해결방법을 찾았나요? 시작해야 할 실험이 있나요?
워크숍에 나온 모든 자료를 사진으로 촬영합니다. 모든 사람의 머릿속에 아이디어가 아직 생생할 때 공유 저장소에 자료를 업로드하면 좋습니다. 무엇보다도 실행 아이템을 기록하고 개인별로 따라다니면서 제대로 수행하고 있는지 확인하는 일이 가장 중요합니다.
'IT > 소프트웨어 아키텍처' 카테고리의 다른 글
개발자에서 아키텍트로 -10. 설계 시각화 하기1 (1) | 2025.01.08 |
---|---|
개발자에서 아키텍트로 - 9. 아키텍처 디자인 스튜디오 운영하기2 (0) | 2025.01.06 |
개발자에서 아키텍트로 - 8. 의미 있는 모델로 복잡도 관리하기2 (0) | 2025.01.04 |
개발자에서 아키텍트로 - 8. 의미 있는 모델로 복잡도 관리하기1 (2) | 2025.01.03 |
개발자에서 아키텍트로 - 7. 패턴으로 기초 만들기2(아키텍처 패턴 - 서비스 지향 아키텍처, 발행/구독 패턴, 공유 데이터 패턴, 멀티 계층 패턴) (0) | 2025.01.02 |