[ AWS x Girls In Tech Mentoring Program ] 회고

 

도입

이번 AWS(Amazon WEB Service)와 Girls In Tech에서 주최한 멘토링 프로그램에 멘티로 선발되었다.

 

8월 4일 오리엔테이션을 기점으로 9월 8일 전체 마무리까지 총 5주 동안 프로그램이 진행되었다.

 

우리 팀의 경우 8월 12일부터 9월 9일까지 하여 매주 목요일 모임을 가졌으며, 총 4회의 팀 모임과 1회의 개인 면담을 진행하였다.

 

5주 간의 멘토링 진행이 너무 좋았어서 오늘은 그 내용을 정리할 겸 회고록을 공유하고자 한다.

 

 

1주차 (08.12)

처음 모임을 가진 날이었다. 크게 공부 방법, 포트폴리오에 대한 이야기를 해주셨다.

 

공부 방법

우선 GitHub 레포지토리 등에 많은 개발자들이 기술 면접에 자주 등장하는 질문 및 지식들을 정리해두었는데, 이런 기출 문제를 공부하는 게 취업 뿐만 아니라 기술적인 내용을 공부할 때 많은 도움이 된다. 아래는 기술 면접 질문 모음 중 가장 유명한 레포지토리 중 하나다.

 

신입 개발자를 위한 기술 면접 가이드라인

GitHub - JaeYeopHan/Interview_Question_for_Beginner: Technical-Interview guidelines written for those who started studying progr

 

다음으로 AWS Summit 등과 같은 컨퍼런스나 AWS 내의 소모임 등을 찾아 가입하여 모임(Meet-up)에 참여하는 걸 추천한다. 본인이 재직 중인 회사가 아니더라도 다른 기업의 컨퍼런스 영상을 많이 보고, 또 모임에 참여하면 기술적 트렌드를 익히기 좋기 때문이다. 좋은 개발자, 시니어 개발자로 성장하는 과정에는 단순히 기술적인 깊이 뿐만 아니라 비즈니스 자체에 대한 이해도 필요하기 때문에 해당 도메인 지식을 얻기 위해 기술 공부 뿐만 아니라 비즈니스와 연관된 거시적 시야를 기르기 위해 본인이 속해 있는 산업, 넓게는 다른 산업 분야까지도 공부하고 익힐 필요가 있다. 그리고 이를 위한 가장 좋은 방법 중 하나는 컨퍼런스 또는 소모임 등에 참여하는 것이다.

 

개발 도서의 경우 나오는 데 시간이 조금 소요되기 때문에 최신 트렌드라 할 수는 없지만 많은 책이 공통적으로 하는 이야기를 통해서 안정적으로 요구되는 기술 트렌드를 익히기에 좋다. 또한 책은 하나의 주제에 대해 본인의 페이스로 공부하기에 제일 좋은 방법이다.

 

그리고 오픈 소스, 책에 나와 있는 샘플 코드, 강의 등을 통해서 실제 실습을 진행하여 프로젝트를 진행해보는 게 좋다. 그리고 이때 엔드 투 엔드(End-to-end) 구현을 직접 간단하게라도 한 번 해보는 게 좋다.

 

취업을 준비할 때 트렌드 공부 만큼 중요한 것이 기초 컴퓨터 공학 지식 등의 기본적인 기술적 지식을 공부하는 것이다. 트렌드는 매번 바뀔 수 있지만, 시간이 지나더라도 변하지 않는 근본적인 개념들이 있기 때문이다. 제너럴리스트나 스페셜리스트나 공통적으로 인프라에 대한 전반적인 지식은 알고 있어야 하기 때문에 이를 익히기 위해 <그림으로 배우는 ... > 시리즈와 같은 책을 통해 공부하는 걸 추천한다. 아래는 해당 시리즈 중 하나인 <그림으로 배우는 클라우드> 도서다.

 

<그림으로 배우는 클라우드>, 하야시 미사유키, 서재원, 영진닷컴, 2020.08.25

그림으로 배우는 클라우드 2/E - 교보문고

 

포트폴리오 준비

포트폴리오는 곧 본인이 무엇을 할 줄 아는지 상대방이 알게 하는 것이다. 그러나 주니어 개발자의 경우 본인이 무엇을 할 줄 아는지 역량을 보여줄 방법이 마땅히 없기 때문에 이러한 이유로 GitHub과 블로그 관리가 중요하다. 한 마디로 기록이 무척 중요한 것이다.

 

기타

공부할 때 가장 중요한 것 중 하나는 본인의 영역 뿐만 아니라 다른 영역, 이를 테면 소프트웨어 아키텍처 성능 등과 같은 부분에 대해서도 꾸준하게 관심을 가지고 공부해야 한다는 것이다. 결국 프로그래밍에 대한 이해가 중요하지, 하나의 언어 자체에 대한 이해는 그렇게까지 중요하지 않기 때문이다. 이와 관련해서는 도서 <함께 자라기> 도서에 나오는 내용 중 프로그래밍 언어 학습에 대한 부분을 더 자세히 살펴보면 좋다. 아래는 도서 <함께 자라기>다.

 

<함께 자라기>, 김창준, 인사이트, 2018.11.30

함께 자라기 - 교보문고

 

질의 응답

질문

나는 컨퍼런스 영상을 시청하거나 기업의 기술 블로그에 올라온 글을 읽을 때면 해당 내용을 이해할 수 없을 때가 많았다. 그래서 멘토님께서 말씀하신 트렌드를 익히기 위한 컨퍼런스 영상 시청이나 기술 블로그 지식을 읽는다는 게 어떤 맥락에 관한 것인지 궁금했다. 이해하지 못하더라도 보면서 대략적인 용어 정도만 익히는 게 중요한 것인지 아니면 차라리 기술 공부를 더 하고 어느 정도 알아들을 수 있을 때 보면 좋은지 궁금했다.

 

답변

컨퍼런스 영상들은 대게 난이도를 함께 표시한다. AWS의 경우 100레벨부터 400레벨까지 존재하는데, 100-200레벨 영상들이 주니어 개발자가 이해할 수 있는 수준이다. 따라서 처음에는 이러한 수준의 내용들을 접하는 걸 추천한다.

 

또한 트렌드를 익히라는 의미는 면접을 자주 보라는 의미와 일맥상통하는 것으로 시장에서 필요로 하는 기술을 파악하고 그것이 본인의 분야와 어떤 상관이 있는지 생각해야 한다. 그리고 이러한 과정을 반복하면서 공부의 우선 순위를 정하고 동기부여를 받을 수 있다.

 

그 외에도 타인과의 소통을 위해 용어를 이해하는 게 무척 중요한데 컨퍼런스 영상을 시청하거나 기술 블로그 글을 읽으며 이러한 용어를 배우고 이해할 수 있다. 이런 맥락에서 서점에서 여러 권의 책을 훑어보라는 의미이다. 최신 기술을 다루는 책이 아니더라도 기본적 개념을 습듭해서 소통을 원할하게 하는 능력은 필수이기 때문이다.

 

질문

컴퓨터 공학에 관한 지식을 어느 정도의 수준으로 익혀야 하는지 궁금했다. 

 

답변

컴퓨터 공학 지식은 지금부터 몇 년 동안 계속해서 공부해야 하는 부분으로 단기간에 끝나지 않기 때문에 T자형으로 범위를 넓혀 나가면서 본인의 핵심 분야에 관한 기본기를 다지면서 심화 공부를 진행하고, 계속해서 그 주변부를 넓혀가며 공부하여 기본을 다져나가야 한다고 답해주셨다.

 

느낀점

무엇보다 컴퓨터 공학의 지식을 익히는 게 중요하다는 걸 다시금 상기할 수 있었다. 그리고 컨퍼런스 영상이나 개발 관련 도서 혹은 기술 블로그에 올라온 글들을 읽는 게 왜 중요한지 그 명확한 이유를 알 수 있어서 좋았다.

 

더욱이 처음 개발 공부를 시작할 때 엔지니어는 필수적으로 스페셜리스트가 되어야 하는 줄 알았는데 제너럴리스트로도 충분히 멋진 엔지니어가 될 수 있다는 걸 깨달았다. 나는 관심 있는 분야가 넓고, 호기심이 많기 때문에 스페셜리스트보다는 제너럴리스트를 꿈꾸고 있다. 굳이 스페셜리티를 뽑아보자면 소통이나 문서화에 대한 능력이라 생각했는데 이는 누구나 가질 수 있고, 어느 정도 최소 요건으로 요구되는 역량이기 때문에 제너럴리스트로 준비하는 게 더 좋을 것 같다는 생각이 들었다. 결국 여러 분야에 흥미를 가지고, 비즈니스를 포괄하는 거시적인 시각으로 기술적 구현에 들어가는 걸 좋아하기 때문이다.

 

그럼에도 깊이 있게 가져가야 할 전문 분야는 필요하기 때문에 이것을 무엇으로 할지 결정해야 할 것 같다. 백엔지 엔지니어로 첫 커리어를 시작하고 싶기 때문에 우선은 컴퓨터 공학 관련 지식들을 익히는 데 치중해야겠다.

 

2주차 (08.19)

간단하게 멘티들끼리 서로 어떤 상황인지 공유했다.

 

이 과정에서 처음 입사했을 때 본인을 성장시킬 수 있는 방법에 관해서 이야기해주셨다.

 

첫 번째는 본인이 클라이언트 개발자이거나, 서버 개발자이거나 상관 없이 엔드 투 엔드(End-to-end) 기능 구현을 경험해보는 게 좋다는 것이었다. 사이드 프로젝트 개념으로 간단하게 클라이언트부터 서버까지 하나의 플로우를 구현해보며 본인의 분야 뿐만 아니라 다른 분야에 대한 지식 및 시야를 넓힐 수 있다.

 

다음으로 입사하여 팀원과 친하게 진해는 게 중요하다. 왜냐하면 본인이 모르는 분야에 관해 팀원을 통해 배울 수 있기 때문이다. 무엇인가를 모를 때 해답을 찾을 수 있는 방법은 검색, 책, 강의 등이 있는데 가장 좋은 방법 중 하나는 사람에게 직접 질문하는 것이다. 그리고 질문을 통해 해답을 얻는 것보다도 중요한 건 모르는 문제에 봉착했을 때 그것을 해결할 수 있는 방법을 모색하는 것이다.

 

끝으로 어차피 매번 새로운 기술이 나오기 때문에 끝없이 공부해야 한다. 그리고 끊임 없이 공부하는 과정에서 어떤 특정 분야를 잘 하고 싶다는 욕심이 생기는 순간 해당 분야를 더 깊이 있게 공부하면 된다.

 

느낀점

백엔드 개발 관련 학습만 했었기 때문에 사이드 프로젝트를 할 때 항상 백엔드 관련 역할만 담당했었다. 개인으로 간단하게 프로젝트를 진행하더라도 프론트엔드 관련 지식을 빠르게 학습해서 엔드 투 엔드(End-to-end) 기능을 한 번 구현해봐야겠다.

 

실제 프로젝트를 진행할 때도 프론트엔드 개발자와 소통할 때 React.js 지식이 없어 프론트엔드 개발자가 회의에 참여하지 못했을 때 기획자 또는 디자이너의 질문에 답변해주지 못해 답답한 순간들이 있었는데 엔드 투 엔드(End-to-end) 기능을 구현해보면서 전체적인 시야를 익히면 소통하는 데 이전보다 원활해질 수 있는 것은 물론 전반적인 시야를 익힐 수도 있을 것 같다.

 

 

반응형

 

728x90

 

3주차 (08.25)

멘토님과 개인 면담을 진행했다.

 

아래는 내가 멘토님께 드렸던 질문과 이에 대한 멘토님의 답변을 요약한 것이다.

 

질문

우선 제너럴리스트와 스페셜리스트 사이에서 고민이 많았다. 엔지니어의 길을 걸으며 기획이나 디자인 부분을 추가적으로 학습하는 경우를 보지 못했기 때문이다. 나는 단순히 기술적인 부분 외에도 소통(Communication)이나 팀 리딩 등에 관심이 많아서 스페셜리스트보다는 제너럴리스트 쪽에 가깝다는 생각이 들었는데 과연 이런 상황으로도 엔지니어로 커리어를 시작하여 계속해서 발전해 나갈 수 있을지 고민이었다.

 

이와 이어지는 이야기로 현재 커뮤니티 웹앱 서비스 프로젝트를 진행하며 직접 팀을 꾸리고 리딩하고 있다. 이 과정에서 소프트웨어 설계 방법론이나 사용자 스토리 맵 등과 같은 팀 리딩과 기획 관련 지식을 학습하고 있는데, 현재 재미를 느끼고 도전해보고 싶은 분야가 이러한 기획과 PO(Product Owner) 또는 PM(Project Manager) 관련 내용이었기 때문이다. 걱정되는 부분은 이러한 경험이 혹시 커리어에 있어 불필요한 시간 낭비가 되는 것이었다. 

 

답변

제너럴리스트와 스페셜리스트는 사실 중요한 구분이 아니다. 주변에서 이와 관련된 이야기를 해보더라도 모든 직군의 사람들이 기술 분야를 T자 형태로 가지고 있다. 만약 그렇지 않은 사람이 있다면 오히려 일을 깊이 있게 하지 않는 사람이다. 결국 이를 통해 알 수 있는 사실은 제너럴리스트, 스페셜리스트 구별과 상관 없이 모든 사람이 T자 형태로 성장해야 하는데 대신 머리가 큰 T의 형태로 발전할 것인지 아니면 깊이가 깊은 T의 형태로 발전할 것인지 차이만 존재한다. 그리고 이 차이는 본인의 흥미에 따라서 커리어를 쌓아가는 과정에서 결정된다. 또한 PO 및 PM은 기술 직군으로 분류를 안 하기 때문에 엔지니어와 완전히 다른 분야로 이를 제너럴리스트와 스페셜리스트로 구별하는 건 조금 어색한 부분이 있다.

 

결론적으로 제너럴리스트와 스페셜리스트를 극단적으로 나눠 이야기하기는 쉽지 않으며 PO 및 PM 중에서도 비즈니스에 대한 개념 및 이해가 강한 사람과 오히려 기술에 대한 이해가 강한 사람으로 나뉠 수 있다. 따라서 본인이 어디에서 어떤 업무를 수행하는 지에 따라 방향성은 달라질 수 있다. 이때 '어디에서'의 의미는 지금까지 본인이 한 업무를 바탕으로 결정되는 것이다.

 

커리어도 결국 본인 인생의 일부분이기 때문에 본인이 누구인지 알아가는 과정이다. 따라서 직무를 확실하게 정하는 것보다 본인이 무엇을 좋아하고 잘 할 수 있는지 생각해보며 계속해서 직군을 바꿔보는 것도 하나의 방법일 수 있다.

 

이러한 맥락에서 본인이 좋아하는 분야를 찾는 고민과 과정은 어떤 목표점에 도달하기까지 좀 오래 걸릴 수 있어도 건강하고 좋다.

 

추가적으로 전반적인 IT 관련 지식을 익힐 수 있는 책 두 권을 소개한다. <비전공자를 위한 이해할 수 있는 IT 지식>과 <IT 좀 아는 사람>이다. 두 권의 책을 통해 소프트웨어에 대한 거시적인 시야를 익히는 데 무척 도움이 될 것이다.

 

<비전공자를 위한 이해할 수 있는 IT 지식>, 최원영, 티더블유아이지, 2020.07.14

비전공자를 위한 이해할 수 있는 IT 지식 - 교보문고

 

<IT좀 아는 사람>, 닐 메타&아디티야 아가쉐&파스 디트로자, 김고명, 월북, 2021.01.20

IT 좀 아는 사람 - 교보문고

 

느낀점

지금까지 제너럴리스트와 스페셜리스트에 대한 오해가 있었다는 걸 알게 됐다. 그리고 내가 최종적으로 지향하는 지점이 무엇인지 다시 한 번 고민해 볼 필요가 있을 것 같다. 나는 어떤 엔지니어가 되고 싶은지 한 번 고민해보는 시간을 가져야겠다.

 

무엇보다 커리어 또한 본인의 인생의 일부라는 멘토님의 답변이 무척이나 따듯하고 감사했다. 내 인생 가치관 또한 커리어에 우선 순위가 있지 않았기에 평생 공부를 끝없이 해야하는 엔지니어의 삶이 조금은 맞지 않을 수도 있겠다는 고민을 했었는데, 지금 당장 재미가 있기에 포기하고 싶지 않았었다. 개인 면담을 통해 이러한 작은 고민들도 함께 해결되고 큰 용기를 얻을 수 있어 좋았다.

 

4주차 (09.02)

영문 이력서 작성 방법에 대한 가이드라인을 제시해주셨다. 멘토님께서 작성하셨던 이력서를 직접 보여주시면서 이야기해주셨기 때문에 개인 정보 문제로 직접적인 내용을 말하기는 어려울 것 같다. 아래는 간단하게 적어본 핵심 내용이다.

 

내용

이력서, 포트폴리오의 핵심 중 하나는 읽는 사람이 누구인지 파악하는 데 있다. 보통 이력서를 읽는 사람은 하루에도 수십 개 이상을 봐야하기 때문에 무척 바쁘다. 따라서 본인의 주소, 성별 등 굳이 넣지 않아도 되는 또는 넣으면 안 되는 불필요한 정보를 빼는 게 중요하다. 또한 Linked In 등을 활용하여 그 사람의 정보를 미리 파악하고, 해당 기업에 소개 사이트에서 직군 명세서(Job Description)를 살펴보며 기업에서 요구하는 인재는 어떤 모습인지 미리 파악하는 게 좋다.

 

경력을 적을 때도 본인이 강조하고 싶은 부분, 해당 기업에서 요구하는 상황에 따라서 더 자세히 적어야 하는 경험이 있고 간단하게 요약해도 괜찮은 경험이 있다. 예를 들면 백엔드 개발자로 취업을 하는데 요구하는 기술 스택이 Python을 통한 마이크로 서비스 아키텍처(MSA, Micro Service Architecture)에 대한 경험이라면 굳이 Spring, Node.js 등과 같은 내용을 핵심적으로 자세하게 적을 필요는 없는 것이다. Python을 통한 정량적인 성능 개선 경험과 마이크로 서비스 아키텍처에 대한 내용이 우선이면 더 매력적이다.

 

또한 언급한 것처럼 정량적인 표현을 적절하게 해주는 게 무척 중요하다. 본인을 역량을 어필할 때 해당 기술을 얼만큼 잘하는지 수치로 표현하면 좋기 때문이다. 이때 수치에 해당할 수 있는 것들은 자격증, 점수, 프로젝트 또는 인턴십 경험을 통한 성능 개선 등이 있다.

 

기타

약어 쓰는 방법 등 여러 가지 상세한 내용들이 있는데 해당 부분들은 다 적지 않겠다. 직접 이력서(Resume)를 검색해서 다른 사람들이 올려 놓은 예시를 살펴보며 본인만의 작성 방법을 익히는 것도 좋을 듯하다.

 

느낀점

실질적으로 이력서 작성과 관련된 내용은 아니고 다른 분께서 해주신 이야기지만, 2-3년 뒤의 이력서를 미리 작성하는 방법이 떠올랐다.

 

들어가고 싶은 기업의 직군 명세서(Job Description)를 읽고 필요한 역량들을 확인한 다음에 몇 년 뒤에 본인이 해당 기업에 이력서를 제출한다고 생각하고 미리 작성해보는 것이다. 그리고 해당 이력서를 통해 알게 된 본인에게 현재 필요한 부분들을 정리하여 지금부터 하나씩 준비해가는 것이다.

 

올해 연말에 2년 뒤 취업을 위해 미리 이력서를 한 번 작성해봐야겠다고 마음 먹었다. 그리고 이력서를 작성할 때 알려주셨던 내용들을 바탕으로 해서 한 번 작성해봐야겠다.

 

5주차 (09.09)

멘티들이 개별 발표를 진행했다.

 

발표 내용

내가 선정한 발표 주제는 <같이 일하고 싶은 개발자가 되는 과정>이었다. 그리고 해당 주제를 풀어내기 위해 <일단은 개발자인데요>라는 제목을 선정했다.

 

나는 작년 7월 20일 위코드 부트캠프를 기점으로 본격적인 개발 공부를 시작했다. 부트캠프 당시 "같이 일하고 싶은 개발자가 되어야 한다"는 말을 자주 들었는데 과연 그런 개발자가 되기 위해서는 어떤 역량이 필요한지 조금은 모호하게 느껴졌고, 당시에는 정확히 그 의미가 받아 들여지지 않았었다.

 

그로부터 1년이라는 시간이 지나 지금까지 다양한 프로젝트를 경험해보며 나름대로의 고민을 계속해왔었다. 그리고 현재 내가 개발자로서 중심을 세운 가치관은 '숲을 볼 때와 나무를 볼 때를 구분'하는 것이다. 엔지니어로 기술적 구현을 위해 자세히 나무를 볼 필요성도 있지만, 비즈니스를 위해 거시적인 시각을 숲을 볼 때도 필요하다고 느꼈다. 그리고 이러한 적절한 순간에 시야를 변경하기 위해서는 다른 개발팀의 기술은 물론 비개발직군의 작업 진행 방식에 대해서도 파악할 필요성을 느꼈다.

 

쉽게 말해 소통이 무척 중요하다는 걸 깨달은 것이다. 그리고 이 소통을 위한 방법으로 팀의 가치관이라 할 수 있는 미션과 비전 공유, 모든 팀원이 원활하게 소통할 수 있는 공용 언어로 '데이터'를 선정하는 것, 간결하고 정확한 문서화 등이 필요하다는 생각이 들었다.

 

그래서 이를 위해 기획팀으로 프로젝트를 진행해보며 KPT(Keep Problem Try) 회고 등을 통해 팀원 간의 소통 및 팀 문화에 대한 부분을 시도하고 공부 중이며 개발 공부를 한 번도 해보지 않은 사람들에게 인문학과 프로그래밍을 융합하여 메일리 플랫폼을 통해 매주 한 편 에세이를 발행하고 있다.

 

프로젝트 팀원들과 진행 중인 KPT 회고

 

이렇게 프로젝트를 진행하며 느낀 점과 발전하기 위해 노력 중인 부분에 관해서 발표하였다.

 

피드백

어떤 문제점을 느끼고 이를 해결하는 과정을 풀어낼 때 정량적인 결과물을 함께 제시하여 어떤 효과가 있었는지 서술하면 좋다. 예를 들면 팀원들에게 설문 조사를 돌려 피드백을 받는 것이다.

 

본인이 어떤 노력을 했을 때 그것이 효과가 있는지 반드시 확인해야 할 필요가 있다. 그러한 노력을 한 최초의 목적, 본질적인 목적이 무엇인지 다시 한 번 생각해보며 처음에 세운 가설과 비교하여 실제로 어떤 효과를 얻을 수 있었는지 정리하면 좋다.

 

이때 평가를 하는 방식은 정량적일 수도 있고, 인터뷰나 설문 조사 등을 통해 정성적일 수도 있다. 

 

느낀점

지금까지 어떤 프로젝트를 진행하면서 문제점을 개선할 때 팀원들에게 피드백을 수치화해 본 적이 없었다.

 

단순히 훗날 내 이력서 또는 포트폴리오를 위한 평가의 측면 외에도 실질적으로 해당 노력이 효과가 있었는지 팀원들과 함께 살펴보기 위해 정성적, 정량적 평가가 필수적이었다는 걸 깨닫게 되었다.

 

그래서 이번 프로젝트 때 시도해보고 있는 여러 노력들에 대해 팀원들에게 피드백을 요청해 볼 생각이다. 사용자 경험(UX, User Experience)에는 고객(Customer) 뿐만 아니라 팀 멤버(Team Member) 또한 포함되어야 한다는 걸 잊지 말아야겠다.

 

---

기타

9월 8일에 우리 팀을 포함하여 다른 멘토링 팀까지 다같이 온라인으로 모여 마무리 시간을 가졌다. 

 

해당 마무리 시간에 모임을 주최해주신 김예리 개발자님께서 YouTube [ 세바시 강연 ] 영상 중 <4차 산업혁명의 시대, 자기를 혁신하는 방법>이라는 강연 영상을 추천해주셨다. 멘토에 대한 이야기가 나와서 추천해주셨는데 마무리 모임 시간이 끝나고 영상을 끝까지 시청하며 영상 내용자체가 너무 좋았어서 공유한다.

 

5주 간의 멘토링 시간을 통해 김예리 개발자님, 그리고 우리 팀 멘토님처럼 주변에 선한 가치관과 영향력을 선사하는 엔지니어가 되고 싶어졌다.

 

[ 세바시 강연 ] 4차 산업혁명의 시대, 자기를 혁신하는 방법