[AWS 멘토링] AWS & GIT 멘토링 후기

[Girls in Tech X AWS]  Mentoring Program 멘티 모집 | 원티드

와아아아!! 좋아하는 지인분께서 너무너무 좋은 프로그램을 추천해주셔서 운 좋게 AWS 멘토링이라는 프로그램에 참여할 수 있게 되었다.

총 멘티의 인원은 100명이 넘어가는 인원이었고, 멘토님 당 3~4명의 멘티를 담당하고 있기 때문에 멘토님들도 엄청 많으셨다.
멘토님들은 AWS 직원분들이시고, 멘티들의 지원서를 토대로 멘토-멘티가 매칭되었다.
항상 무언가를 새로 도전하고 시작하는 일은 설레는 것 같다. 두근두근..!

'김종일'멘토님과 매칭되었다!
멘토님께서는 클라우드 기반으로 애플리케이션을 올릴 때 어떻게 하면 최적화 된 애플리케이션으로 올릴 수 있는지 컨설팅을 해주는 업무를 하고 계신다고 했다.
 멘티는 나를 포함 4명이었고 신기하게도 2명 2명 비슷한 직무/고민을 가진 사람들끼리 모여있었다!!!
멘티 중 2명은 스타트업에서 일을 하며 CTO로써의 역할을 하고 계셨고 관리자 입장으로서 고민을 가지고 계셨다. 나를 포함한 2명은 개발자였고 하나의 기술에 집중하기보다는 다양한 기술스택을 접하고 있어서 이에 대한 커리어고민을 가지고 있었다.
멘토링 기간인 5주 후에 각자 어떤 Goal을 달성하고 싶은지를 이야기 했고 멘티 4명 각자의 Goal을 기반으로 멘토님께서 아래와 같이 앞으로 5주동안 어떻게 우리의 Goal을 달성하는 것이 좋을지 Impact Mapping이라는 마인드맵을 통해 정리해주시고 공유해주셨다.

A2PIC조의 ImpactMapping

그리고 조 이름은 A2PIC으로 정해졌는데, 이는 멘토님과 멘티 4명의 이름 이니셜 하나씩을 가져와서 만든 이름이다. (수진님 아이디어❤️)

벌써 멘토링을 한지 5주가 다 되어단다. A2PIC조는 멘티의 구성이 개발자(직원)와 CTO(관리자) 입장에서 둘 다 생각해볼 수 있어서 너무 너무 좋았다. 시야가 굉장히 넓어진 느낌이라고 해야할까?! 예를들어 이력서 피드백을 받을 때에도 관리자 입장에서는 이런 고민이 있구나! 그렇다면 나는 지원자의 입장에서 이것도 고려를 해봐야겠다 등등을 생각해볼 수 잇었다.
멘토님 또한 개발 뿐만 아니라 애자일이라던지 비즈니스 관점이라던지 내가 개발 이외에 잘 생각해보지 못했던 부분들에 대해서 너무 잘 알고 계시고 그것들을 우리에게 너무 잘 알려주셔서 깨닳은 것이 참 많았다.
개발자라고 기술만을 알아서도 안되고 좀 더 다양한 분야를 공부하고 시야를 넓혀 생각할 필요가 있다는 것을 깨닳았다.
큰 깨달음 중 하나는 "영어공부"이다. 영어가 가능해졌을 때 우리가 얼마나 넓은 곳에서 경험을 할 기회가 생기게 되는지도 알게되었다. 그동안은 외국에서 개발일을 도전해보고 싶어도 '내가 되겠어..?' 라는 생각으로 포기를 한 상태에 가까웠는데 멘토님의 이야기를 듣고보니 '그냥 못해도 한번쯤은 도전해봐도 되겠는데?' 라는 생각으로 바뀌었다. 한국에서 원하는 회사에 한 번 가본 뒤에는 워킹홀리데이를 한번 쯤 해보고 싶다.
지금부터는 멘토링을 하면서 새로 접하거나 알게된 개념들을 정리해보도록 하겠다.

Outcome

Output과 Outcome은 둘 다 '결과' 라는 뜻이지만, Output과 Outcome은 전혀 다르다.
Output은 결과 그 자체를 나타내지만, Outcome은 결과 그 자체 뿐만 아니라 어떤 변화를 발생시켰는지를 의미한다.
예를들어 내가 5주동안 멘토링을 한 Output은 "수료증을 얻었다"라고 예를 들면, Outcome은 "커리어에 대한 고민을 AWS 리쿠르터와의 만남, 멘토님과 멘티들과의 네트워킹, 육각형 개발자 저자와의 만남을 통해 ~~~게 해결할 수 있겠다는 인사이트를 얻었다" 가 될 수 있다.
인생을 살면서 어떤 일들을 할 때 항상 Output보다는 Outcome이 무엇일까를 고민해봐야겠다.
 

VAST Cycle

관리자로써 직원들이 심리적 안정감을 느낄 수 있도록 하는 것이 중요하다고 한다.
이런 심리적 안정감을 느끼게 하기 위해서는 먼저 관리자 자신이 취약점을 드러내는 것 부터 시작되어야 한다.
상대방에게 나의 취약점을 드러냄으로써 공감대를 형성하고 신뢰를 형성하면서 안정성을 느끼게 된다고 한다.
이것이 바로 VAST Cycle 이라는 것이다.
 

분석 마비 (Analysis Paralysis)

분석마비란 지나친 생각 때문에 결정을 내리지 못하는 것을 말한다. 개발자들은 개발 이전의 설계 단계에서 모든 것을 완벽히 설계하려다가 분석 마비에 빠져 제 시간에 개발을 끝내지 못하곤한다.
소프트웨어 개발에서 분석 마비란 일반적으로 프로젝트 계획, 요구사항 수집, 설계 및 데이터 모델링등의 긴 단계가 포함된 폭포수 모델을 통해 나타난다.
이런 분석 마비에 빠지지 않기위해 애자일 방법론이 필요하기도 하고 내가 분석마비에 빠져있는 것은 아닌지 돌아봐야 한다.
 

Agile - Definition of done

애자일 방법론을 통해 일을 할 때에는 Task별로 빠르게 자주 산출물이 나오기 때문에, Done에 대한 정의가 애매하게 되어있으면 서로간의 오해가 생기거나 버그가 발생하곤한다.
그렇기 때문에 Done에 대한 정의를 잘 해놓는 것이 중요한다. 이러한 정의를 유저스토리에 미리 해놓는 것은 다시 똑같은 일을 해야하는 일이 발생하는 것을 방지할 수 있고 고객들에게 더 만족스러운 제품을 제공할 수 있다.
 

Agile - Why Split Task

• 하나의 업무를 받으면 작은 단위로 태스크를 나누는 것이 애자일에서 중요하다. 태스크를 나누는 것은 단지 업무 계획을 세우기 위함 뿐만 아니라 다양한 이유가 있다.
• 업무 시작 전에 태스크를 나눠봄으로써 해당 업무가 얼마나 걸릴지 예상할 수 있으며 구현 가능 여부를 미리 생각해볼 수 있다.
• 태스크를 쪼갬으로써, 내가 다른사람의 업무를 도와줄 수 있고 다른사람이 나의 업무를 도와줄 수 있다. 태스크 단위로 나누어 업무를 진행하지 않으면, 업무를 분담하기 어려워지며 다른 사람이 자신의 일을 빨리 끝내더라도 나의 일을 도와주기 어려워진다.
• 내가 하는 일을 투명하게 보여주는 것이 애자일에서 중요하다고 한다.
• 만약 태스크를 30분동안 나눴는데도 잘 나눠지지 않으면, 그것은 명확하지 않은 업무이기 때문에 다시 이야기 해봐야 한다.

 

Project To Product - Business-minded developer

개발을 할 때 개발자들은 Project가 아닌 Product를 생각해야 한다.
Project를 만들기위해 요구사항을 정의하고 나면 Product는 사라지게된다. 왜냐하면 개발자들이 정의한 Project 요구사항에는 기술만 가득하기 때문이다. 즉, 이 제품을 사용할 사용자들이 어떤 것을 원하고 어떤 니즈를 가지고 있는지를 정의하지 않은채 이 기능을 구현하려면 "SSO 인증을 써야돼", "JAVA로 개발해야돼" 등 만을 생각하기 때문에 Product는 사라지게 된다.
Project를 잘 수행하기 위해 사람들은 항상 "계획"을 세운다. 그러나 어떤 불확실성이 있을지 계획을 세울 때에는 알 수 없기 때문에 항상 제 시간안에 개발을 완료하지 못하고 Project를 진행할수록 비즈니스 요구사항이 변경되면 해당 Project를 변경하는 비용은 점점 커진다. 이렇게 일정이 중요하고 변화를 수용하기 어려운 특성으로 인해 개발자들은 항상 PUSH를 받으며 압박감을 가지게 된다.
그러나 Project가 아니라 Product를 만드는 것으로 변경하게 되면 먼저 사용자가 원하는 Outcome을 정의하게 된다. PO가 유저가 원하는 Outcome에 대해 개발자에게 알려주고 개발자는 그것을 기반으로 어떤 요구사항들이 필요하지 정해야 한다. (사용자가 원하는 Outcome이 요구사항 정의는 아니기 때문에 요구사항 정의는 따로 진행해야 한다.) 이렇게 되면 개발자는 항상 사용자의 Outcome이 무엇인지 고민하며 개발하기 때문에 능동적인 자세로 개발에 참여할 수 있다(PULL 문화를 가짐). 이렇게 Outcome을 기반으로 개발을 진행할 때에는 최대한 작은 단위로 개발을 진행해보면서 사용자가 어떤 기능에 좋은 반응을 보이는지 살필 필요가 있다. 그럼 개발의 크기가 작은 단위로 나누어지게 되고 비즈니스 요구사항을 유연하게 받아들일 수 있다. 결국 DevOps가 요즘 뜨고있는 것도 사용자들의 Outcome을 충족시키기 위해서이다. DevOps를 통해 빠르게 기능을 배포하고 제거할 수 있어야지 사용자들이 어떤 기능에 반응하는지 빠르게 알 수 있기 때문이다. 이것이 바로 Product이다. (+ 페르소나를 나눠보는 것이 중요하다)
Product를 설계하기 위해서는 아래와 같은 방법론들이 있으며 자세한 개념에 대해서는 이후에 찾아볼 예정이다.

Custom Experience Map
Custom Journey Map
Imapct Mapping
Wardley Mapping
Eventstorming
User Story Mapping

 

기타

• 제텔카스텐 메모 방법을 위한 툴 - 옵시디언
• 책 추천
  • 육각형 개발자
  • 파이브 라인스 오브 코드
  • 콰이어트
  • 제품의 탄생
• 기술부채는 없애는 것이 아니라, '컨트롤'하는 것이다
• 좋은 아키텍처란 현재 상황에서의 모든 단점들이 가장 적은 것 (상황에 따라 다르다) - MSA를 사용할지 모놀로지를 사용할지 등

 
https://nyeongnyeong.tistory.com/363

[AWS 멘토링] AWS & GIT 멘토링 - AWS 리크루터님과의 만남

https://nyeongnyeong.tistory.com/362

[AWS 멘토링] AWS & GIT 멘토링 - (전 MS 부사장/ 전 Adobe 사장 / 현 AWS Korea Sales instructor) 우미영님과의