개발자에서 아키텍트로 - 2.3 생각-실행-확인하기

매일 소프트웨어 만드는 일을 할수록 새롭게 알게 되는 소프트웨어 지식도 많아 집니다. 새로운 지식으로 더 나은 아키텍처를 만들고 또 이를 이용해 새로운 정보를 창출할 수 있습니다. 이 선순환을 계혹하려면 설계할 때 빠른 피드백 순환 고리를 만들어서 지속적인 변화로 기회를 만들어야 합니다. 그 3단계가  생각 - 실행 - 확인 하기 입니다.

생각 - 실행 - 확인하기

2.3.1 지속적인 학습을 위한 선순환

• 생각 : 무엇을 배우고 싶은가? 어떤 질문에 대한 답을 구해야 하는가? 현재 제일 위험한 요소는 무엇인가? 생각하기 단계는 무엇을 배울지 계획하는 것을 포함합니다. 구체적인 질문에 대한 답을 생각해보거나 위험요소를 줄이는 방법을 생각해 봅시다.
• 실행 : 계획한 바를 실천합니다. 순에 잡히는 결과를 만들어보며 필요한 정보를 파악하거나 아이디어를 공유합니다.
• 확인 : 실행하기 단계에서 했던 항목들을 비판적으로 평가해보고 다음 목표를 설정 합니다. 그리고 다시 생각하기 단계로 돌아가서 반복 합니다.

소프트웨어 시스템을 만드는 데에 중단이란 없습니다. 릴리즈만 계속 할 뿐 입니다. 

2.3.2 어떤 상황에서든 4가지 마인드셋을 활용하자

• 이해하기 : 이해관계자들이 필요로 하는 바를 요구사항으로 구체화하는 방법에 집중합니다.
• 탐색하기 : 문제를 패턴, 기술 등 여러 수단으로 파악해본 후 해결 방법을 브레인스토밍 합니다.
• 실현하기 : 시스템을 모델링해 구체적인 결과물을 공유 합니다.
• 평가하기 : 결과물이 요구사항에 맞는지 테스트 합니다. 

마인드셋은 빠른 템포로 다음 단계로 넘어가야 합니다. 단순한 1:1 대화에서도 마인드셋을 여러번 바꿀 수 있습니다. 

2.3.3 실전연습 마인드셋과 생각-실행-확인 하기

마인드셋과 선순환을 활용하는 구체적인 예를 들어보겠습니다. 어느 날 이애관계가자 새로운 제약을 줬고 이 때문에 아키텍처상 만족할 만한 성능이 나올 수 없는 위험이 생겼다고 가정하였습니다. 

1차 과정

• 생각 : 성능이 중요하다는 것은 누구나 알지만 좋은 성능이 무엇을 의미하며 그것으로 어떤 점이 좋아지는지는 잘 모릅니다. 더 정확한 정보를 알기 위해 '이해하기' 마인드셋을 적용해봅시다. 
• 실행 : 성능과 관련된 시나리오를 브레인스토밍하고 문서로 납깁니다.
• 확인 : 팀과 이해관계자가 모여서 시나리오를 살펴보고 피드백을 받습니다.

2차 과정 - 새롭게 알아낸 정보로 정확한 위험요소 파악 후 선순환 2차 시작

• 생각 : 품질 속성을 달성할 수 있을지 알아보기 위해 '평가하기' 마인드셋을 가져와봅니다. 제약 때문에 성능에 어떤 문제가 생갈지 작은 실험을 계획 합니다.
• 실행 : 간단한 스크립트를 만들어서 소프트웨어 시스템에 부하를 주고 데이터를 수집 합니다.
• 확인 : 수집된 데이터로 100여 밀리초 정도의 성능 저하를 확인 할 수 있었습니다.

3차 과정 - 성능 저하 확인. 심각한 수준은 아니라고 판단. 결과를 공유하고 새로운 구현 방법 모색

• 생각 : '실현하기' 마인드셋을 이용해 아이디어를 실체화하고자 합니다. 도표만으로는 부족하다고 생각하므로 이해관계자 제약으로 생기는 영향을 직접 체험할 수 있게 하고 싶습니다.
• 실행 : 프로그램의 흐름과 여러 가정에 따라 성능 차이를 시뮬레이션할 수 있도록 일회용 프로토타입을 만듭니다.
• 확인 : 프로토타입을 이해관계자들에게 전달하고 여러 변수에 따른 성능 차이를 설명 합니다. 수치상 100밀리초 정도는 작다면 작은 차이이지만 직접 체험해본 이해관계잗르은 받아들일 수 없다고 했습니다.

프로토타입을 만들어 직접 체험하게 하니 이해관계자들도 문제를 가볍게 생각하지 않고 새롭게 인식 할 수 있었습니다. 다음으로 '이해하기' 마인드셋을 적용하여 요구사항을 개선 할 수 있었습니다. 곧바로 '탐색하기' 마인드셋을 이용해 이해 관계자들에게 시현했던 회의에서 잠깐의 시간을 할애해 개선한 요구샇ㅇ이 현실적으로 적합한지 평가할 수 있습니다. 이런식으로 꾸준히 순환하는 것 입니다.