오늘 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님의 조언을 거쳐 더 간결하고 직관적으로 변한 시퀀스 다이어그램
이러한 전문가분들과 소통하는데 있어서 단순히 말로 설명하는게 아니라 내가 생각하는 것을 타인도 동일하게 생각할 수 있게끔 문서로 작성하는 훈련이 많이 동반되었다.
물론 이러한 문서가 중요함은 이미 알고있었다. 하지만, 이번 기회만큼 시퀀스 다이어그램의 중요성을 알게된 것은 처음이다.
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분들과 많은 고민, 생각, 그리고 개발에 착수하며 생각하는 그 흐름을 따라가다 보니 이 분들은 정말 너무 멋있다. 나도 이렇게 되고 싶다.
그래서 꾸준히 도전해보려고 한다.
