구글에서 대용량 아키텍쳐 설계 에 대한 2일짜리 워크샵을 진행한다고 해서 신청을 했다. 신청한 사람 중에 일부만 참석할수 있는 워크샵 이어서 선정이 안될까 봐 조마조마 했다. 워크샵 내용은 아래 표처럼 이틀동안 강의도 듣고 실습도 해볼수 있는 일정이었다. 교육은 "대용량 아키텍처와 성능 튜닝" 의 저자인 조대협님께서 직접 해주셨다.
우선 기술적인 자세한 내용들은 워낙 방대하고 다 적을수 없어서 여기에다 일일이 적지는 않겠다. 기술적인 내용보다는 첫날 들었던 "아키텍트"는 어떻게 해야 하는지에 대해서 몇가지 인상깊었던 것에 대해 적어보려고 한다.
아키텍트는 전달을 잘해야 한다.
아키텍트는 설계를 하는 사람이다. 아니, 설계만 하는 사람이라고 생각을 했었다. 그런데 그것도 중요하지만 다른 중요한것이 있었다. 바로 커뮤니케이션이다. 아키텍트는 설계를 한후 개발팀이 설계한 것을 보고 개발을 할수 있도록 전달을 해야 한다. 그렇기 때문에 개발팀과의 커뮤니케이션이 정말 중요하다. 보통 설계 문서를 주지만 이건 한계가 있다. 왜냐? 개발자들은 설계문서를 잘 안본다는 안타깝지만 사실에 가까운 팩트이다. 결국 찾아다니면서 설명을 해줘야 한다. 그리고 말보다는 그림이 더 설명을 하기도, 이해를 하기도 쉽다.
위 사진을 한번 살펴보자. 인스타그램 같은 앱에서 사진을 올렸을 경우 사진을 저장하는 절차를 설계한 그림이다. 모바일컨트롤러(MC) 에서 API Gateway를 거쳐서 인증을 받은후 API 서버를 거쳐서 사진을 저장하게 된다. 각각의 흐름에는 번호가 붙어 있다. 각각의 트랜잭션이 일어날때 마다 필요한 DATA 와 받는 Data도 표현을 해준다. 각각의 번호는 하나의 RestAPI 로 설계가 될수 있다. 이런 형태로 하나 하나 다 정의를 해줘야 한다고 한다.(아키텍트는 정말 힘든 직업인것 같다 ㅡㅡ;;)
그리고 커뮤니케이션과 더불어서 개발팀의 능력치 파악도 중요한 포인트이다. 개발팀의 능력에 따라서 일의 양이나 일정을 결정 할 수 있다. 그리고 누구한테 어떤 일을 맡겨야하는것 까지 파악이 된다면 정말 도움이 많이된다. 이런 것들을 잘 파악하기 위해서는 같이 술을 먹어야 한다고...
아키텍처는 상황에 따라서 변한다.
설계 변경이야 늘 있는 일이라서 새삼 놀랍지도 않은 일이다. 아침에 받았던 설계를 점심 이후에 다시 가져와서 수정해야 된다고 들은적이 정말 많다. 그런데 하나의 product를 유지하기 위해 환경이 변화해서 전체 아키텍처가 변경이 된다는 말에서 놀랐다.
처음 product 를 만들 때에는 정해진 feature를 만들어서 제공하기 위한 제품 위주의 아키텍처 였다고 가정해 보자. 제품을 출시하고 나면 다른 경쟁사들에게 뒤쳐지지 않기 위해서 빠르게 개발해서 빠르게 대응할 수 있는 아키텍처가 필요하다고 한다. 이런 형태로 처음 구상했던 아키텍처를 끝까지 가지고 가는게 아니라 변화하는 상황에 빨리 대응하기 위한 형태로 아키텍처를 그때 그때 알맞게 변경을 해야 한다고 한다. 생각해 보면 하루에도 수십개, 수천개씩 쏟아져 나오는 product들 사이에서 살아 남으려면 변화는 필수인것 같다. 그리고 아키텍처도 예외는 아니라는 것이다.
이틀간의 짧은 시간동안 많은 내용을 배웠다. 모든 내용을 다 이해해서 내 머릿속에 담을수 있었으면 더 좋았겠지만 아직은 좀 무리였다. 하지만 앞으로 공부를 더 해나가면 발전할 수 있을거라는 생각은 한다. 오랜만에 다녀온 워크샵에서 좋은 지식과 자극을 같이 얻을수 있어서 너무 좋았다.
'Development > Tech&Seminar' 카테고리의 다른 글
TCC가 뭐지??? (0) | 2018.09.07 |
---|---|
Openssl로 SSL 을 위한 인증서 발급하기 (HTTPS) (2) | 2018.08.22 |
#2 OpenID Connect Flow (0) | 2018.08.14 |
#1 Open ID Connect 가 뭐야??? (0) | 2018.08.07 |
Google Cloud Study Jams 후기 (0) | 2018.05.15 |