Polpid's Pensieve

올해 초부터 시작했던 Google Cloud Study 가 어느덧 3번째 과정이 끝났다. 

2018/05/15 - [Development/Tech&Seminar] - Google Cloud Study Jams 후기

맨 처음에는 Qwiklabs 을 통해서 공부를 했었다. 그리고 두번 째 Advanced 과정에서는 Coursera 에 있는 GCP 과정을 수강을 했다. 

Qwiklabs 이나 Coursera 과정에 분명 실습 과정이 있긴 했지만 실습이 끝난 후에는 기억이 나지 않았다. ^^;;; 그래서 아쉬움이 많이 남긴 했었는데 이번에는 정말 사용해야 할 만한 이유가 생겼다.

바로 3번째 과정이 Cloud Hackathon 이라는 이름으로 프로그램을 직접  GCP 에 올려서 진행을 해야 했기 때문이다. 

우선 처음에 한숨이 나왔다.. 주제는 Bigdata 와 Kubernetes를 이용한 Microservice 구현 이었다. 먼저 선택은 Kubernetes를 이용한 Microservice 를 구현하는것으로 정했지만.. 뭐부터 해야할지 막막했다. 

기간은 총 6주. 충분한 시간이긴 했지만 정말.. 아무것도 할 수가 없었다. 갑자기 회사일은 바뻐지고. 덕분에 체력은 바닥나고. 명절에는 당연히 못하고.

그래도 결론적으로 거의 극적으로 구현까지는 했다. 그래서 지난 10월 6일 모든 팀들이 모여서 만든것을 소개하는 시간이 있었다. 

우리 팀에서 제출 한 것은 간단한 회원 가입을 Microservice 로 나누어서 GCP 의  Kubernetes에 올려서 동작을 확인해보는 것이었다. 만들긴 했지만 완성도가 많이 떨어졌다. 중간중간 exception처리나 message queue도 넣으려고 했는데 못 넣었다. 언제나 그렇지만 시간이 좀더 있었다면이라는 생각을 많이 했다. (그런데.. 시간이 많이 있었으면 좀더 나았을까 라는 질문도 던져봤다. -_-;;;)

다른 팀들 발표도 계속 진행이 되었고 독특한 아이디어로 구현한 모습들이 많았다. 약간 부끄러웠다. ㅠㅠ

기념품으로 후드 짚업과 여행용 짐정리 가방(?) 을 받았다. 

그리고 이런 인증서도 받았다. 좀더 잘 할 걸 이라는 후회가 되었지만 아무튼 좀 뿌듯했다.

그리고 이번 3차 과정 수료로 또 하나 모은 배지. 드디어 3개를 모았다. 

총 4개를 모으면 하나의 모양을 만들어내는 배지이다. 이제 마지막 1개가 남았다. 

그리고 공개된 마지막 4단계 최종 과정. 5번째는 개인별로 직접 지원(?) 이기 때문에 일단 4단계에서 최종 마무리가 된다. 그리고 주어진 미션은 이번달 10월 25일에 열리는 Google Summit 에서 개발자 라운지(?) 라는 곳에서 이번에 발표한 내용을 그곳에서 발표하는 것이다. ㅡ,,ㅡ;;;;; 망했다..

25일에 열리는 Google Summit 은 참석을 하려고 신청은 미리 하긴 했었는데 이런 형태로 참석을 해야 될줄은 몰랐다. 앞으로 남은 기간은 2 주 정도. 지금 만들어놓은 것을 어떻게 해서든지 다듬어야 하는데 과연 그게 가능할 지 모르겠다. 지금껏 했는데 마지막 하나를 포기하자니 정말 아쉽고, 발표를 하자니 눈앞이 깜깜하다. 

이번 Hackathon 과정이 끝나면 뭐가 기다릴지 굉장히 궁금했는데 이런게 있을 줄이야. 한숨 돌릴 수 있을 줄 알았는데 더 바쁘게 생겼다. ㅠㅠ

구글에서 대용량 아키텍쳐 설계 에 대한 2일짜리 워크샵을 진행한다고 해서 신청을 했다. 신청한 사람 중에 일부만 참석할수 있는 워크샵 이어서 선정이 안될까 봐 조마조마 했다. 워크샵 내용은 아래 표처럼 이틀동안 강의도 듣고 실습도 해볼수 있는 일정이었다. 교육은 "대용량 아키텍처와 성능 튜닝" 의 저자인 조대협님께서 직접 해주셨다.

우선 기술적인 자세한 내용들은 워낙 방대하고 다 적을수 없어서 여기에다 일일이 적지는 않겠다.  기술적인 내용보다는 첫날 들었던 "아키텍트"는 어떻게 해야 하는지에 대해서 몇가지 인상깊었던 것에 대해 적어보려고 한다. 

아키텍트는 전달을 잘해야 한다. 

아키텍트는 설계를 하는 사람이다. 아니, 설계만 하는 사람이라고 생각을 했었다. 그런데 그것도 중요하지만 다른 중요한것이 있었다. 바로 커뮤니케이션이다. 아키텍트는 설계를 한후 개발팀이 설계한 것을 보고 개발을 할수 있도록 전달을 해야 한다. 그렇기 때문에 개발팀과의 커뮤니케이션이 정말 중요하다. 보통 설계 문서를 주지만 이건 한계가 있다. 왜냐? 개발자들은 설계문서를 잘 안본다는 안타깝지만 사실에 가까운 팩트이다. 결국 찾아다니면서 설명을 해줘야 한다. 그리고 말보다는 그림이 더 설명을 하기도, 이해를 하기도 쉽다.

위 사진을 한번 살펴보자. 인스타그램 같은 앱에서 사진을 올렸을 경우 사진을 저장하는 절차를 설계한 그림이다. 모바일컨트롤러(MC) 에서 API Gateway를 거쳐서 인증을 받은후 API 서버를 거쳐서 사진을 저장하게 된다. 각각의 흐름에는 번호가 붙어 있다. 각각의 트랜잭션이 일어날때 마다 필요한 DATA 와 받는 Data도 표현을 해준다. 각각의 번호는 하나의 RestAPI 로 설계가 될수 있다. 이런 형태로 하나 하나 다 정의를 해줘야 한다고 한다.(아키텍트는 정말 힘든 직업인것 같다 ㅡㅡ;;)  

그리고 커뮤니케이션과 더불어서 개발팀의 능력치 파악도 중요한 포인트이다. 개발팀의 능력에 따라서 일의 양이나 일정을 결정 할 수 있다. 그리고 누구한테 어떤 일을 맡겨야하는것 까지 파악이 된다면 정말 도움이 많이된다. 이런 것들을 잘 파악하기 위해서는 같이 술을 먹어야 한다고...

아키텍처는 상황에 따라서 변한다.

설계 변경이야 늘 있는 일이라서 새삼 놀랍지도 않은 일이다. 아침에 받았던 설계를 점심 이후에 다시 가져와서 수정해야 된다고 들은적이 정말 많다. 그런데 하나의 product를 유지하기 위해 환경이 변화해서 전체 아키텍처가 변경이 된다는 말에서 놀랐다. 

처음 product  를 만들 때에는 정해진 feature를 만들어서 제공하기 위한 제품 위주의 아키텍처 였다고 가정해 보자. 제품을 출시하고 나면 다른 경쟁사들에게 뒤쳐지지 않기 위해서 빠르게 개발해서 빠르게 대응할 수 있는 아키텍처가 필요하다고 한다. 이런 형태로 처음 구상했던 아키텍처를 끝까지 가지고 가는게 아니라 변화하는 상황에 빨리 대응하기 위한 형태로 아키텍처를 그때 그때 알맞게 변경을 해야 한다고 한다. 생각해 보면 하루에도 수십개, 수천개씩 쏟아져 나오는 product들 사이에서 살아 남으려면 변화는 필수인것 같다. 그리고 아키텍처도 예외는 아니라는 것이다. 

이틀간의 짧은 시간동안 많은 내용을 배웠다. 모든 내용을 다 이해해서 내 머릿속에 담을수 있었으면 더 좋았겠지만 아직은 좀 무리였다. 하지만 앞으로 공부를 더 해나가면 발전할 수 있을거라는 생각은 한다. 오랜만에 다녀온 워크샵에서 좋은 지식과 자극을 같이 얻을수 있어서 너무 좋았다.