Please enable JavaScript to view the comments powered by Disqus.AWS EBA party
Search
🎈

AWS EBA party

Created
2022/11/11
Tags
AWS
EKS
EBA
pulish
오늘 AWS와 함께한 EBA party 가 끝났다. 그간 EKS를 학습하기 위해 AWS의 SA분들과 신나게 달려왔다. 아쉽게도 나는 중간에 프로젝트 우선순위가 다른것으로 바뀌어 제대로 마무리에 참가하지 못했지만, 상당히 좋은 경험이었다.
이 EBA(Experience Based Acceleration)는 AWS의 숙련 SA분들과 특정 주제에 대해 6~8주 정도의 기간동안 학습하면서 스프린트를 경험한다.
먼저 K8S의 전반적인 내용을 다루고(거의 책 1권 분량) AWS EKS 에서 어떻게 구현 되었는지 학습 후에 실제로 dev, stg 까지 배포를 해본다.
ㅎㅏ..
그런데 AWS 분들과 함께 시간을 보내면서 EKS 혹은 AWS의 이해도가 높아진 것 뿐만 아니라 개인적으로 성장한 부분이 많다.
그중 가장 크게 배운점은 Sequence diagram 을 직접 그려보는 것이다.
부끄럽지만 처음 그린 시퀀스 다이어그램
SA님의 조언을 거쳐 더 간결하고 직관적으로 변한 시퀀스 다이어그램
여태 Google Gsuite를 사용하면서 draw.io 와 그닥 친숙해지지 못했는데 이번 기회에 굉장히 익숙해졌다.
이러한 전문가분들과 소통하는데 있어서 단순히 말로 설명하는게 아니라 내가 생각하는 것을 타인도 동일하게 생각할 수 있게끔 문서로 작성하는 훈련이 많이 동반되었다.
물론 이러한 문서가 중요함은 이미 알고있었다. 하지만, 이번 기회만큼 시퀀스 다이어그램의 중요성을 알게된 것은 처음이다.
SA 한 분과 함께 시퀀스 다이어그램을 그리는데, 내 논리의 빈틈이 어디인지 찾아낼 수 있었다. (물론, 대화 하면서 시퀀스 다이어그램을 그리려면 내가 내 코드를 어느정도 외우고 있을 필요가 있다.)
또한 반복적으로 계속 그림을 그려서 이제는 코드리뷰를 위해 코드를 읽거나 기획서를 읽을 때 머리속에 저절로 sequence diagram이 그려진다.
일단, 이 시간을 지나면서 가장 크게 달라진 점은 다음과 같다.
1.
코드를 작성할 때 예전에는 일단 테스트코드 부터 작성하고 구현을 시작했는데, 이제는 시퀀스 다이어그램을 그려보면서, 테스트 코드에 뭐가 들어가야 할지 특정할 수 있다.
2.
무엇을 문서로 남겨야 할지도 명확해진다.
3.
패킷이 우리의 네트워크로 들어올 때 세세하게 어떠한 리소스를 통해 들어오는지 정리해둘 수 있다.
그래서 결론적으로 나의 시스템에 대한 이해를 깊게 가져가고, 또한 ownership 을 더 가질 수 있었다.
이 방법을 협업하는 동료에게 소개하니 무엇을 정리하고, 무엇을 고민해야 할지 특정하기 쉬워졌다고 한다.
이것도 추억이다.
이것과 별개로 이제 내가 무언가 정리할 때, 혹은 어떠한 일을 해야할때 STAR method 를 사용한다.

STAR method

노션에 사용하는 STAR method 템플릿
Star method 란 다음과 같은 기준으로 현 상황을 정리하는 것이다.
Situation
자신이 처한 상황이나 달성해야 하는 과제에 대한 설명.
Task
달성하고자 하는 목표
Action
상황을 해결하기 위한 행동
어떠한 조치를 취했는가?
팀으로 작업한 경우 조치에 내가 무엇을 하였는가?
Result
이 행동에 대한 결과
무엇을 이루었는가? 무엇을 배웠는가? 그래서 프로젝트는 어떻게 끝났는가?
Metric, Data 등등
현재 회사로 오기전에 AWS에 면접을 준비했던 적이 있다. 나한테 개발을 가르쳐준 형이 현재 AWS에서 레벨5인가 하는걸로 알고있는데 면접 예상 문제를 받고 포기했었다. (와 진짜 이런걸 면접에서 물어본다고?)
그런데 이 기간동안 SA분들과 많은 고민, 생각, 그리고 개발에 착수하며 생각하는 그 흐름을 따라가다 보니 이 분들은 정말 너무 멋있다. 나도 이렇게 되고 싶다.
그래서 꾸준히 도전해보려고 한다.