개발자에서 아키텍트로 3차 스터디

금일 개발자에서 아키텍트로 3차 스터디를 진행했다.

 

오늘은 7~10장까지 읽고 느낀 부분을 공유하는 시간을 가졌는데, 7,8 장은 다양한 아키텍트와 장단점을 알 수 있었고,

동시에 아키텍트를 조합할 때, 어떤 부분을 주의해야 하는지에 대해서도 알 수 있었다.

 

9, 10장에서는 아키텍처 디자인 스튜디오에 대한 정보와 설계를 시각화하는 방법에 대해 이야기를 했고,

나는 그동안 워크숍 뿐 아니라 회의나 스터디에서도 어떤 부분을 참고하면 좋을지 생각하는 계기가 되었으며,

마감 시간을 설정하고 추가 토론 세선을 운영해야 겠다는 생각을 하게 되었다.

 

나의 경우에는 7,8장에서 배경지식이 별로 없어서 크게 느낀부분이 없었으나,

아키텍트 디자인 스튜디오(워크숍) 을 어떻게 운영하는 것이 좋을지와, 10장의 범례에 대한 내용을 보며

전체적으로 나에게 당연한 것들을 당연하다고 생각하지 않고 이해관계자에게 설명해야겠다는 생각을 하게 되었다.

---

현재 백엔드에서 일하시던 분은, 아키텍처가 하나의 테마로서 익숙했다고 하셨으며,

책을 읽으면서 추가로 느꼈던 점은 어떤 패턴을 결합하여 프로그램이 동작했는지에 대해 알게 되었다고 하셨다.

---

또 다른 개발자분은 7~10장을 읽으면서 워크숍에 참여했을때 어떤 역할을 할수 있을지 고민했으며,

이해관계자, 반대 역할의 사용자를 초대한다고 하는데, 나는 어떠한 역할을 할수 있을지? 

개발 가능여부에 대해 비평할 수 있을지에 대해 이야기하고 짧은 시간에 얼마나 이야기해볼 수 있을지 질문하셨다.

 

백엔드 개발자분은 다양한 기능 개발에 대한 워크숍에서 비교적 보수적으로 워크숍에 참여했으며
주어진 시간에 어떻게 개발이 가능한지와 다양한 이해관계자와 커뮤니케이션을 통해서
설계에 대한 러프한 이미지를 그리는 동시에 UX 개선에 대해 참여하려고 노력했다고 경함을 공유해주셨다.

 

QA분은 앞단의 개발쪽보다는 참여시점이 늦어 중간중간 가장 많이 피그마와 같은 툴을 많이 도입했으나

QA로서는 툴을 사용할 수 있는 부분이 어려워서 요구사항 분석 단계에서 참석할 수 있도록

연동 부분에 대한 피드백도 해야하다 보니, 다이어그램이나 대시보드의 형식을 많이 사용하게끔 이야기를 했다고 하셨다.

---

나는 아키텍처의 개념에 대해 잘 알지 못해서 백엔드 개발자분께 현재 사용하고 있는 아키텍처가 무엇인지?

그리고 이 책을 통해서 느낀점이 무엇인지 좀더 상세하게 공유해주실 수 있냐고 요청드렸다.

 

백엔드 개발자분은 한창 예전엔 마이크로서비스 패턴 등이 트렌드였는데, 과연 회사에 맞을까? 하는 생각을 많이 했고

서비스 지향 아키텍쳐 패턴, 고유데이터 패턴 등 여러 아키텍처를 조합하여 그림을 그렸던 것 같다.

아키텍처의 극과 극을 무논리식과 마이크로서비스 패턴으로 들 수 있는데, 그 사이에서 아키텍처를 정할 수 있다.

 

다만, 이 책이 특정 기준으로 아키텍처를 정리한 것이 아니라, 못하면 헷갈릴 수도 있겠다는 생각을 했다고 하셨다.

---

QA분은 8장에서 나온 `설계 수준에서 테스트를 수행할 수 있다`의 부분이 일반적으로 개발자분들이 담당하는데,

이와 관련하여 실제로 앞단에서 어떤 역할들을 실제로 하고 계시는지 궁금하다고 물어보셨다.

 

이와 관련하여 개발자분들은 기능 구현 전에, 기능을 다른방식으로 실행해볼 수 있는 방식이 있는지? 에 대해 생각하고,

실제로 설계 수준에서 테스트를 진행한다기 보다는 프로토타입을 만든다는 의미로 해석했다고 말씀하셨다.

---

나는 추가로 9장에서 언급한 `아키텍처 디자인 스튜디오`에서 워크숍을 해본 경험이 있는지 물어봤다.

 

QA분은 테스트케이스 작성할 때 워크숍같은 형식을 많이 사용해봤던것 같다고 말씀하셨고,

개발자분은 예전, 사이드 프로젝트할 때 참여해봤는데, 포스트잇을 사용하여 의견을 써서 붙이고

대체할 수 있는건 없는지 등에 대해 작업을 했던 경험이 있다고 공유해 주셨다.

추가적으로 `이벤트 스토밍 워크숍` 의 경험을 공유해주셨으며 이때, 개발보다는 기능적으로 이야기를 했다고 하셨다.

 

이와 관련하여 나는 테스트케이스에서 어떤 워크숍 형식을 진행했는 지 여쭈어봤고,

QA분은 개발 시작 전 기획 리뷰를 받은 뒤 테스트 시나리오를 작성할 때, 실제 유저 시나리오를 참고하면

시나리오만으로는 예측하지 못한 이슈를 발견한 경험이 있으며, 관련하여 TC리뷰를 여러번 할수록 도움이 되었다고 했다.

 

동시에 과거 에이전시 테스터분들과 협업할 때, TC를 이해하지 못하는 피드백을 많이 받아서

에이전시와 함께 TC와 관련하여 회의를 통해 난이도 별로 TC를 작성하거나 참여시키는 회의를 진행하였고,

이런식으로 개발 단계마다 TC에 대한 피드백을 받고 커뮤니케이션을 받는것이 긍정적인 결과를 도출했다고 하셨다.

---

오늘은 범위가 많은만큼 이야기를 많이 나누었는데, 일하는 분야마다 인상깊게 느낀 부분이 달랐다는 것이 신기했고,

현직에 있었다면 내가 맡은 서비스는 어떤 아키텍처를 맡았을지, 그리고 이와 관련하여

QA로서 어떤부분에 기여할 수 있을지에 대해 고민했을 것 같다.

 

다만 `아키텍처`라는 부분에 대해서는 아직까지 붕 떠있는 듯한 느낌을 받고 있는데,

7~8단원을 복기하고 다른 정보를 추가로 검색함으로서 아키텍처에 대한 배경지식을 점차 늘릴 계획이다.