이번 기회에 회고록을 처음 써보려고 한다. 그래서 어떻게 써야할지 고민하고 있는데,(카페에서 1시간째 멍만 때리고있다...😂😂) 답이 안나온다.
의식의 흐름 기법으로 진솔하게 써봐야겠다.
2020년, 전공을 살려 취업을 시도한 두 개의 기업 최종면접에서 탈락하고 2021년을 맞이하였다. 나에게 남아있는건 위태위태하게 붙잡고 있는 42서울이라는 나무였다.
최종면접 탈락 후 2021년 맞이하기 전 일주일동안 많은 고민을 하였다. 전공을 살려 다시 취업에 도전하기엔 대학생활을 체계적으로 하지 못했고 쌓아왔던 능력이 부족했다고 느꼈다. 근데 후회해서 뭐하나,,, 나에겐 남은게 없다고 생각하니까 그제서야 내 적성에 대해 생각해보게 되었다. 내 먼 미래를 그려보기로 했다.
그 와중에도 42서울이라는 나무를 붙잡기 위해 밀린 과제(printf함수 구현..😱)를 부랴부랴 진행했다.(42서울 SW교육프로그램은 주어진 과제를 게을리하면 SW교육을 받을 수 있는 자격을 박탈당한다ㅜ) 어라? 과제를 진행할 때에는 다른 잡생각이 떠오르지 않았고, 그 과제를 어떻게 풀어나가야할지만 하루죙~일 생각하고 있었다. 지겹지가 않았다. 이 과제처럼 기능을 구현하고 프로그램을 만드는 일을 직업으로 삼는다면 삶의 질이 정말 윤택해질 것 같았다. 지금 나에게 왜 개발자를 꿈꾸게 되었냐고 다시 물어봐도 그냥 재밌더라구요.
라고 답변할 것 같다.
그래서 나는 2021년에 개발 세계에 발을 내딛었다. 🎉🎉
2021년은 미지의 개발 세계를 밝게 비춰본 한 해였다. 깜깜하게만 보였던 개발자들의 세계를 다양한 경험을 통해 밝게 비춰보았다. 내 길을 명확하게 볼 수 있게 된 것이다. djeon의 2021년을 상반기, 하반기로 나누어 키워드로 요약해보자면 상반기는 생존
, 방황
, 하반기는 도약
이다.
상반기에는 42서울의 밀린과제를 진행하면서 좋은 사람들과 함께할 수 있는 42서울에서의 생존
을 위해 노력했다. 그리고 IT 기업의 채용과정을 직접 체험해보고, 멘토링을 받는 것을 통해 방황
하고 있던 나 자신을 올바른 방향으로 인도하였다.
하반기에는 42서울 주관의 오픈프로젝트
행사에 참여하여 주니어개발자로 도약
을 할 수 있었다.
상반기에는 밀린 42서울 과제인 ft_server, cub3D, libasm, ft_services, push_swap, Minishell, philosophers를 수행했다. 악착같이 동료들과 함께 과제를 수행한 끝에 42서울에서 생존
할 수 있었다...
하지만 생존하기 위한 42서울 과제에서도 배울 수 있는 것이 많았다.
[2021.01. ~ 02.]
ft_server 과제는 Docker Container 환경에 여러 서비스를 배포해보는 과제이다. cub3D 과제는 openGL 기반의 MiniLibX 라이브러리를 활용하여 3D 게임의 초석인 Wolfenstein의 게임을 구현해보는 과제이다.
두 과제를 수행하면서 내가 과제에 접근하는 방법이 잘못되었다는 것을 알게되었다. 당시엔 과제의 요구사항을 충족하는 데만 급급했다. 그래서 어디서부터 뭘 공부해야할 지 파악조차 되지 않았고, 앞서 과제를 수행했던 다른 동료들의 코드를 참고하여 과제를 진행하였다.
그러다보니 남는게 없었다. 남들이 짠 코드를 그대로 갖다가 쓰고 그 코드를 공부하는 방식으로 과제를 진행하다보니까 프로그램이 어떻게 구성되는 지는 설명할 수 있었지만, 이 프로그램에서 왜 이런 알고리즘을 사용했고, 왜 이런 라이브러리, 함수 등을 사용했는지 설명이 안되는 것이다.
과제는 어째저째해서 통과는 했지만, 정말 찝찝했다.🤢🤢
[2021.02. ~ 03.]
libasm 과제는 어셈블리어에 대해 이해하고 몇 가지 간단한 함수를 어셈블리어로 구현해보는 과제이다. 이번 과제는 앞선 과제를 수행하면서 느꼈던 찝찝함🤢을 다시 느끼지 않기 위해 학습방향을 바꿔보았다.
먼저 과제에서 요구하는 지식을 top down 방식으로 파악하였다. 그 결과, 레지스터에 대한 지식과 어셈블리어의 활용법을 익혀야함을 알 수 있었다. 그리고 부수적인 부분(어셈블리파일 link, 어셈블러 nasm)들은 같이 과제를 수행했던 동료들에게 자문을 구해서 공부할 수 있었다.
libasm 과제가 앞서 수행했던 과제보다 쉬웠지만, 다른 코드를 참고하지 않고 오로지 내 힘으로 코드를 짰다는 것에 뿌듯함을 느꼈다.
[2021.04. ~ 05.]
ft_services 과제는 Kubernetes(k8s)를 활용하여 다양한 서비스를 배포해보는 과제이다. k8s를 활용하기 위해서는 앞서 진행했던 ft_server 과제에서 Docker와 Container에 대한 개념을 확실하게 파악했어야 했는데... 딥하게 공부하지 않았기 때문에 어려움이 많았다ㅜ
ft_services 과제 역시 Top down 방식으로 필요한 지식을 쌓아나가려고 했다. k8s 관련 유튜브 영상과 블로그 글들을 활용하여 k8s의 원리와 활용법을 파악했다. 그런데 과제에 적용을 못하겠더라... ft_server 과제에서의 설정 그대로 nginx만 k8s에 배포하려고 했는데도 잘 되지 않았다.
주변 동료에게 도움을 받아서 k8s에서의 디버깅 방법을 배웠고, 어떤 문제인지 확인해봤더니 k8s문제가 아니라 Docker image 문제였다. image에서 기반으로하는 OS의 차이 때문에 발생한 문제였다.(ft_server에선 Debian OS를 활용했지만, 본 과제에서는 alpine OS를 활용했다.) 이 문제도 Docker에 대한 확실한 이해가 전제가 되어있었다면 금방 해결할 수 있는 문제였다.
다양한 툴들을 활용해야 하는 과제였다. 시간 관계상 어떤 툴들을 활용할 지는 다른 동료들의 코드를 참고하여 결정하였다.
그리고 같은 실수를 반복하기 싫었다. ft_services과제는 시간을 좀 들여서 확실하게 하고 넘어가기로 했고, TCP/IP부터 시작해서 기초적인 개념부터 하나씩 다져나갔다. 그래도 k8s는 너무 어렵다...
[2021.05. ~ 06.]
push_swap 과제는 주어진 동작을 활용하여 최대한 효율적으로 프로그램에 입력된 숫자를 오름차순 정렬하는 프로그램을 작성하는 과제이다. ft_services 처럼 방대한 지식을 요하는 과제가 아니고, 논리적 사고를 요하는 과제였기 때문에 몰입하여 재밌게 진행했던 과제였다.👍👍
42서울 동료인 minckim님의 push_swap 가이드를 참고하여 정렬 알고리즘을 구성하였다. 이런 종류의 과제는 자신이 있었기 때문에 크게 어려움 없이 해결했던 것 같다. 다만, 아쉬웠던 점은 히든 테스트케이스로 프로그램을 테스트 해봤을 때, 프로그램이 터지거나 정렬이 제대로 안되는 오류가 생겼던 것이다. 꼼꼼함이 필요하다고 생각되었다.
[2021.06. ~ 07.]
minishell 과제는 팀을 구성하여 가벼운 shell 프로그램을 만들어 보는 과제이다. 처음으로 팀을 구성하여 하나의 프로그램을 만드는 과제를 할 생각에 설레었다. 다른 개발자들처럼 협업이란 걸 하면서 프로그램을 만들다니... 감개무량했다.
5명의 팀원과 함께하기 위해서는 효율적으로 분업할 필요가 있다고 생각했다. 과제 설명을 읽어보고 먼저 과제를 수행하신 다른 교육생분들의 minishell 프로그램 다이어그램도 참고하였다. 그리고 분업은 parsing, pipe, redirection, builtin 함수 구현으로 파트를 나누면 될 것 같았다.
이제 각 파트를 어떤 방식으로 연결할 지가 문제였다. 각 기능별로 모듈화가 제대로 이루어지려면 어느 정도의 골격이 갖추어 져야한다고 생각했고, main문과 간단한 pipe 로직을 구성하여 팀원들에게 제공하였다. 그 후, 위에서 파트를 나눈대로 팀원들에게 역할을 부여하였다.
이제 각 파트별로 구현을 진행하는데, 유난히 한 팀원이 평소와 같지 않게 의욕이 떨어진 모습을 보였다. 그렇다... 난 의욕만 앞섰던 것이다. 코딩을 하는 데 있어서 각자 나름의 코딩 스타일이 있고, 어떤 식으로 프로그램을 구성하면 될지에 대한 생각도 있었을텐데, 그런 의견들은 들어보지도 않고 혼자서 골격을 다 짜버리고 이제 각자 모듈을 구현하면 될 것 같다고 말했으니...
그래서 그 이후로는 의욕을 좀 절제하고 팀원들의 의견을 최대한 수용하여 남은 부분을 구현하는 데 힘을 썼고, 과제를 성공적으로 마칠 수 있었다.
이 minishell 과제를 통해 팀 프로젝트를 수행할 때에는 사소한 것 하나하나 다른 팀원의 의견을 들어보는 것이 팀원들의 적극성을 유도하는 데 도움이 된다는 것을 다시 한번 깨달을 수 있었다.
[2021.07. ~ 08.]
philosophers 과제는 스레드와 프로세스를 나타내는 철학자가 공유자원을 나타내는 포크를 활용하여 굶어 죽지 않고 끊임 없이 식사하는 C언어 프로그램을 작성하는 과제이다. 이 과제 역시 프로그램 구현 과제였기 때문에 몰입하여 재밌게 수행할 수 있었고, 앞서 운영체제 스터디를 통해 멀티 스레딩에 대한 개념도 파악해놓은 상태였기 때문에 자신도 있었다.
스터디를 통해 운영체제를 공부했었지만, 공부한 지 시간이 꽤 지난 상태라서 양희재 교수님의 운영체제 강의를 다시 한번 수강하여 프로세스와 스레드, 기아상태, 교착상태, Context Switching, Mutex, Semaphore에 대한 개념을 다시 익혔다. 그리고 과제에서 주어진 프로세스와 스레드 관련 함수들에 대해 공부하였다.
프로그램은 금방 만들었다. 하지만 문제가 생겼다. 생성한 스레드가 많아질수록 시간 오차가 크게 생기는 것이다. 뭐가 문젠지 알아보기 위해 printf로 시간들을 직접 찍어보았다. 스레드나 프로세스를 잠깐 대기시키는 usleep함수에서 오차를 발생시키고 있었다. 잦은 Context Switching이 발생하여 usleep 함수에 오차가 발생한 것으로 추측했다. 그리고 동료에게 조언을 구하였다. 동료는 작은 시간동안만 대기시키는 usleep 함수를 while loop 안에 넣고, 해당 while loop가 함수의 입력으로 주어진 시간만큼 돌아가면 빠져나오는 방식으로 함수를 구현하면 usleep의 오차를 방지할 수 있다고 하였다.
문제가 하나 더있었다. 위 대로 함수를 만들어 usleep 함수를 대체하였는 데도 스레드가 100개 이상 생성되면, 오차가 발생하여 스레드가 죽는 문제가 있었다. 이 문제에 대한 원인은 아직 파악하지 못했다 ㅜ 하지만 해결은 했다. while loop 속 usleep 함수의 입력 값을 50에서 500으로 늘렸더니 해결되었다. 아마 빈번한 usleep 함수의 실행도 별로 좋지 않은 것 같다.
[2021.03. ~ 04.]
IT 기업의 채용과정은 내가 알고있는 채용과정과 차이가 있었다. IT 기업 대부분은 인적성검사를 시행하지 않고 코딩테스트를 본다. 우리나라 대표 IT 기업 네카라(네이버, 카카오, 라인)는 서류전형이 없고 코테부터 보는 것 같았다. 또한, 특정 기업에 한해서는 CS 지식을 검증하기 위해 따로 필기시험을 치는 곳도 있다.
이런 복잡한 채용과정에 적응하기 위해서는 부딪치는 수밖에 없다고 생각했다. 경험을 미리미리 쌓아놔야 실전에서 바로 경쟁력을 보여줄 수 있다고 생각했기 때문이다.
그래서 나는 오산마(오늘만 산다는 마인드) 알고리즘 스터디에 참여했다. 새롭고 재밌었다. 원래도 특정 함수를 만들고 프로그램을 만드는 것에 흥미가 있었는데, 코테를 대비한다는 명목 하에 알고리즘 문제만 주구장창 푸니까 공부할 맛이 났다. 그리고 좋은 사람들과 함께해서 더 좋았다. 외롭게 혼자 공부하지 않아서 좋았고, 서로의 코드를 보고 피드백 하는 과정도 너무 유익했다. 어떤 문제에 어떤 알고리즘(DFS, BFS 등)이 필요하다고 판단되면 해당 알고리즘에 대해 다같이 공부하고 설명해보는 방식도 좋았다. 이 때, 나는 집단지성의 힘을 처음 느꼈던 것 같다.
목표는 3월 말에 예정되어 있는 LINE 코딩테스트 였다. 체험삼아 본 것이라서 부담은 없었지만, 그래도 심혈을 기울여서 풀었다. 결과는 4문제중 3솔이었다. 실력이 정말 많이 향상된게 느껴졌다. 하지만 3솔 했음에도 불구하고 떨어진 것 보면 히든케이스들을 놓친 것이 분명하다. 얻은 자신감을 기반으로 더욱 노력하여 코딩테스트를 통과하리라 다짐했다.
[2021.04.]
알고리즘 스터디 멤버 그대로 운영체제를 공부하는 스터디를 진행하기로 했다. 형님이자 나보다 경험이 훨씬 많으신 동료의 도움을 많이 받았다. 코테를 통과하는 것도 중요하지만 기본적인 CS(Computer Science)지식도 굉장히 중요하다고 조언해주셨다. 많은 CS 지식(운영체제, 네트워크, 자료구조, 컴퓨터구조 등)이 있지만, 그 중에 제일 중요하다고 생각되었던 운영체제를 스터디에서 공부하기로 했다.
먼저 같이 수강할 강의부터 선정했다. 선정한 강의는 양희재 교수님의 운영체제 강의였다. 인터넷에서 무료로 제공해주는 강의였고, 쉽게 설명해주시고 강의 퀄리티도 괜찮았기 때문에 선정했다. 그리고 하루에 한 강의씩 수강하고 스터디 시간에 배운 것을 공유하는 방식으로 스터디를 진행했다. 내가 습득한 지식을 스터디원에게 설명해줌으로써 다시 상기시키고, 내가 놓쳤던 개념도 익힐 수 있어서 매우 유익한 시간이었다. 이런 방식으로 운영체제의 역사 및 개념, CPU 스케줄링 방식, 멀티 스레딩 및 프로세싱, Mutex 및 Semaphore, Context Switching에 대해 확실하게 공부할 수 있었다.
[2021.04.]
42서울 과제인 ft_services가 예상 외로 난제라서 42서울 교육 박탈의 위기에 처했다. 그 때, 블랙홀 멘토링이라는 것을 받으면 블랙홀 기간을 추가해주어 생명을 연장시킬 수 있다는 소리가 내 귀에 들려왔고, 첫 멘토링을 받을 수 있었다.
사실 블랙홀 기간을 늘리려고 신청한 멘토링이었지만, 그대로 이번 기회를 활용해서 내 불확실한 진로를 바로잡고 싶었다. 그래서 블랙홀 기간을 관리하지 못한 이유를 솔직하게 털어놓고, 어떤 진로에 관심있는 지를 말씀드렸다.
멘토님은 IT 기업들의 종류와 특성들을 자세하게 설명해주셨다. 예를들어, 금융권 같은 경우는 돈 관리에 대한 프로그램을 만들어야 하기 때문에 꼼꼼함과 신중함이 요구되고, 네이버 같은 서비스회사는 빠르게 장애 대응을 하고 요구사항을 처리할 수 있는 능력이 필요하다고 말씀해주셨다. 그리고 이러한 기업들의 특성과 나의 성향을 잘 고려해서 기업을 선택하는 것이 중요하다고 말씀해주셨고, 내 희망 진로를 스스로 정리해볼 것을 추천해주셨다.
또한, 성장가능성이 보이는 개발자의 특징에 대해 설명도 해주셨다. 이러한 개발자들의 특징은 자신의 성장을 위해서라면 무엇이든 할 수 있는 적극성이 있다고 말씀해주셨다. 가령, 성장에 목말라 있는 학생은 멘토님들께 뭐 하나라도 빼먹을 게 없을지 항상 궁리하는 것처럼 보인다고 말씀해주셨다. 그리고 동기가 확실하다고 했다. 말로만 어떤 문제를 해결하고 싶다고 떠드는 것이 아니라 실제 행동으로 옮긴다고 한다.
반성을 많이 하게 되었다. 아무리 작년 취준 실패라는 그럴듯한 핑계가 있을지라도 개발에 몰두하지 못해 블랙홀 관리가 안된 것은 사실이었다.
부끄러웠다. 42서울 교육에 진심으로 참여하여 성장을 갈구하는 학생들이 있는 반면에 나는 고작 취준 실패를 대비한 보험정도로만 생각해왔었다.
가벼운 마음으로 멘토링을 신청했지만, 정말 얻는 것이 많았고 나를 다시 돌아볼 수 있는 계기가 되었다. 적극성있게 행동하며 끊임없이 성장을 갈구하는 개발자가 되리라 다시한번 다짐하였다.
[2021.06.]
KT sat에서 개발 인턴을 채용하고 싶다고 42서울 교육을 진행하는 이노베이션 아카데미에 찾아왔다. 백엔드 개발 인턴을 모집하는 것이었고 나는 백엔드 개발에 대한 경험을 쌓으며 배우고 싶었다.
이를 위해 이력서를 작성해야 했다. 부랴부랴 재단에서 제공하는 템플릿에 내 이력과 자소서를 채워 넣은 후에 만든 이력서를 멘토님께 보여드렸다.
일단 개발 이력서에는 보통 자기소개서를 넣지 않는다고 말씀해주셨다. 하지만 난 넣을만한 개발관련 경험이 부족하기 때문에 자소서를 빼지 않고 가독성 있게 수정하는 방식으로 이력서를 구성하였다.
그리고 이력서 검토는 눈에 띄는 내용이 있는지 한번 훑는 다고 한다. 처음부터 하나씩 읽어보지 않는다고 한다. 눈에 띄게 이력서를 구성해야 했다. 가장 중요한 부분인 프로젝트 경험을 맨 앞으로 땡겼고, 가독성 좋게 문장을 구성하였다. 자기소개서 역시 가독성 좋게 적절하게 띄어쓰고 첨삭하였다.
그리고 백엔드 개발직무를 희망하는데 DB에 CRUD해본 경험이 없다는 것이 아쉽다고 말씀해주셨다. 추후엔 꼭 관련 경험을 쌓겠다고 다짐했다.
[2021.06.]
KT sat에 내 이력서를 제출하고 1주일 정도 지난 후에 면접을 보자고 연락이 왔다. 부랴부랴 면접 국룰질문에 대한 답변을 준비하고, 자기소개서 기반의 질문을 대비하면서 면접을 준비했다.
그리고 대망의 면접 당일, 잘 못봤다 ㅜ
면접관님들께 신뢰를 못준 것이 가장 컸다. 개발관련 경험이 거의 없다보니까 자신감을 확인하기 위한 질문인 "3개월을 주고 웹을 만들라고 하면 만들 수 있는지?"에 대한 답변도 확실하게 못했다. 그리고 이어서 들어온 기술질문에 대해서도 제대로된 답변을 못했다. 사실 42서울 과제만 성실히 잘 했어도 대답할 수 있는 질문이었는데, 내 과제 진도가 너무 느렸다 ㅜ
당연히 떨어졌다. 기대를 안해서 실망도 안크다. 앞으로 더 열심히 해야겠다는 생각밖에 안들었다. 오히려 좋았다. 각성하게 된 계기였다. 프로젝트 경험의 중요성을 크게 느끼게 된 계기였다.
[2021.07.]
여느 때처럼 IT 기업의 채용과정에 대한 경험을 쌓기 위해 지원했던 현대오토에버 서류전형에 합격하고, 코딩테스트까지 통과해서 면접 기회를 얻었다. 내 첫 코테 통과 기업이었다. 감개무량했다.
백엔드 관련 경험이 없지만, 면접기회를 얻었고 서류통과된 특별한 이유가 있을 것이기 때문에 후회안하도록 면접을 준비하였다.
하지만 이번 면접 역시 이변은 없었다. 기술 질문이 들어오는 족족 다 생소했기 때문에, 대답을 못하거나 횡설수설하기 일쑤였다. 그리고 면접이 진행될수록 자신감 역시 떨어져서 면접관님들께 신뢰를 못줬고, 일관성있는 대답도 하지 못했다. (학과 부회장 경험이 있는데, 리더형보단 팔로워형이라고 대답하였다...)
결과는 안봐도 비디오였다. 면접을 볼 때마다 죽쑤는 이유는 근본적으로 백엔드 관련 경험이 없는 것이라고 판단했다. 관련 경험이 없기 때문에 기술질문이 들어오면 대답도 못하고 면접관에게 신뢰도 못주는 것이었다. 뿐만 아니라 자신감있게 대답도 못하는 것이다. 관련 경험을 쌓는 데 사활을 걸어야할 시점이 온 것이다.
[2021.08.]
8월 초, 재단 유튜브 미팅에서 오픈프로젝트에 대한 얘기가 나왔다. 8월 중순부터 오픈프로젝트 참여 신청을 받는다고 하였다. 오픈프로젝트는 12월까지 약 3개월동안 42서울 교육생들의 팀 프로젝트를 지원해주는 행사이다. 지원항목은 AWS 서버비를 비롯하여 Apple 개발자 계정, 학습에 필요한 교재, 기자재 대여 등이었고, 우수 작품에 한해 수상을 한다고 했다. 대신 행사에 참여하는 교육생들은 계획 발표, 중간 발표, 최종 발표까지 세 번의 발표를 의무적으로 진행해야 했다.
기회를 잡고 싶었다. 난 프로젝트 경험을 절실하게 원하고 있었다.
먼저 내 주변 동료들을 위주로 팀원을 모집했다. 세 명의 동료들이 참여하기로 했다. 하지만 세 명의 동료들 모두 프론트엔드 담당을 희망했다. 나 혼자 백엔드를 담당할 수도 있었지만 나는 백엔드 경험이 없기 때문에 프로젝트 진행에 차질이 생길 것이 우려되었다. 추가적으로 팀원을 모집하기로 결정했다. 재단에서 팀원 모집을 위한 자리를 마련해주었고, 채팅관련 프로젝트에 백엔드로 참여하기를 원하는 동료가 보였다. 그 동료는 42서울의 공통과제를 모두 끝낸 동료였기 때문에 백엔드 경험이 있을 것이라 생각했다. 그래서 팀 참여 제의를 했고, 해당 동료는 흔쾌히 수락해주었다. 나를 포함하여 5명의 팀원이 모였다.
오픈프로젝트에 참여하려면 프로젝트 계획에 대해 발표를 해야했기 때문에 하루 빨리 프로젝트 주제를 선정해야 했다. 그래서 2~3일에 한번씩 아이디어 회의를 진행하고, 서로 생각해온 아이디어를 공유하고, 투표를 통해 아이디어를 선정하였다. 만장일치로 42doproject가 선정되었다.
선정된 주제를 활용하여 어떤 방식으로 프로젝트 기획단계를 거칠지에 대한 멘토링을 받았다. 받았던 많은 조언중 가장 중요한 것은 화면->서버->DB를 구성해보면서 시행착오를 겪어보라는 것이었다. 또한, 필수적인 기능부터 하나씩 구현해보라는 것이었다.
우리 팀의 대부분의 팀원이 웹 초심자라서 프로젝트의 기획 단계를 거치기엔 무리가 있다고 판단했고, 멘토링도 고려하여 프로젝트 기획 단계를 거치지 않고 바로 필수 기능부터 구현하기로 결정했다.
[2021.08.]
프로젝트의 백엔드 파트에서 사용될 기술로 TypeScript와 Express 프레임워크를 활용하기로 했다. 그렇기 때문에 JavaScript에 대한 심층적인 이해가 필요했다. 하지만 당시에 나는 JavaScript에 무지했기 때문에 프로젝트에서 기능을 구현하기 전에 JavaScript에 대한 기본적인 이해가 선행되어야 했다.
JS piscine은 42서울 교육생들이 자체적으로 만든 JavaScript 교육과정이다. 지금 다시봐도 과정이 체계적으로 잘 짜여져 있다고 생각한다. 해당 과정에서 주어진 과제를 해결하기 위해 유튜브 강의와 구글링을 적극적으로 이용했고, 이를 통해 Node.js 활용법부터 시작해서 JavaScript 문법, DOM 조작 방법, 비동기 프로그래밍, Express 활용법에 대해 배울 수 있었다.
[2021.08. ~ 2021.09.]
오픈프로젝트 준비를 끝내고 참여신청서를 냈다. 팀원을 모집하고 주도적으로 다른 행정업무까지 수행하다보니까 자연스레 팀장이 되었다. 사실 팀장이 되고 싶었다. 학부생때 몇 번의 리더경험이 있었기 때문에 팀을 잘 운영할 자신이 있었고, 나만의 팀 운영 방식을 적용해보고 싶었기 때문이다.
나만의 팀 운영 방식은 팀원들이 개발에만 몰두할 수 있는 환경과 활발한 의견 개진 환경을 조성하는 것이고, 이를 위해 나는 팀장으로서 발표와 기타 행정업무를 맡아서 했다. 또한, 회의 때마다 사소한 것이라도 팀원들에게 의견을 물어 팀 운영에 최대한 팀원들의 의견을 반영하도록 했다. 이렇게 하면 팀원들의 적극성을 끌어올릴 수 있겠다고 생각했다.
팀의 개발 방식에 대한 회의를 거쳤다. 일주일에 두 번씩 프로젝트를 진행하면서 발생한 이슈들에 대해 공유하기로 했고, 새로운 아이디어가 있을 때마다 공유하기로 했다.(나중엔 일주일에 두 번도 부족해서 그냥 매일 진행했다.) 그리고 기본적으로 모든 회의를 비대면으로 진행했다. 각 팀원 나름의 사정이 있어서 대면으로는 프로젝트를 진행할 수 없다고 판단했고, 메타버스 플랫폼인 게더타운을 활용하여 회의를 진행했다.
프로젝트의 버전 관리는 GitHub를 활용하기로 했다. 각 팀원의 할 일이나 버그가 발생하면 issue로 등록해놓고, pull request 후 팀원들에게 코드리뷰를 받고 merge시키는 방식으로 버전 관리를 진행하기로 했다.
부수적으로 회의록이나 API 명세 등과 같은 팀원들이 공유해야 할 정보들은 notion에 기록하기로 했고, 사이트 초안은 Figma로 제작하여 프론트엔드와 백엔드 간 소통의 부재로 인한 오해를 최소화 시키려고 노력했다.
[2021.09. ~ 10.]
여기서 언급할 위기는 내 개인적으로 겪었던 위기이다. 사실 큰 어려움 없이 프로젝트를 진행했다. 같이 프로젝트를 진행하던 백엔드 팀원이 나보다 관련 경험이 많아서 도움을 많이 줬기 때문이다. 그럼에도 겪었던 어려움들이 있다.
첫째는 Sequelize 활용 미숙에 따른 어려움이다. Sequelize는 nodejs에서 활용되는 ORM이고, 이번 프로젝트를 진행하면서 처음 다뤄볼 수 있게된 툴이다. 공식 레퍼런스와 구글링을 활용하여 Sequelize에 익숙해지고 있는데, 프로젝트 리스트의 필터링 기능을 구현하는 와중에 어려움에 직면했다. MySQL의 Data type이 JSON인 데이터와 일반 데이터(String, Integer) 타입이 비교가 안되는 것이다. 통상적으로 JS에서 비교하려는 데이터들의 타입이 서로 다르면 서로 다른 데이터로 간주가 되고, 데이터 타입이 아닌 값을 비교하려면 데이터 타입을 통일시켜준 후에 값을 비교해야 정확한 비교가 이루어진다. 하지만 일반 데이터 타입(String, Integer)을 JSON 타입으로 어떻게 통일시켜준 후에 비교를 할 지에 대한 방법을 몰랐다. 구글링을 통해 파악하면 되겠지만, Sequelize라는 툴은 대중화가 되어있지 않아서 자료가 많지 았았다. 그래도 포기하지 않고 에러메시지 구글링을 거듭한 끝에 Sequelize 깃헙 레포의 issue에 나와 같은 문제에 봉착한 사례가 등록되어 있던 것이다. 그리고 그 issue의 답변에는 해결방안이 달려있었는데, 해결방안은 Sequelize 함수에 JSON 함수를 인자로 넣어서 JSON 데이터로 통일시켜준 후에 JSON 데이터끼리 비교하게끔 하는 것이었다. 이 방법을 내 코드에 적용하여 문제를 해결할 수 있었다.
둘째는 AWS와 GitHub 활용 미숙에 따른 어려움이다. AWS에 서버를 배포하게 되면 절대 노출되면 안되는 access key와 secret key가 발급된다. 발급된 키는 .env 파일에 저장해놓고 사용했는데, github 레포에 push하는 과정에서 습관적으로 모든 파일을 push해버려서 AWS key가 노출이 된 것이다. AWS측으로부터 메일이 와서 문제를 인식하게 됐는데, git의 커밋기록을 삭제해야 했다. 하지만 삭제 방법을 몰랐다. 구글링을 거듭하여 삭제 방법을 파악하고 삭제를 했는데, 삭제할 필요가 없는 이전 커밋 기록들까지 삭제된 것이었다. 너무 당황해서 팀원들에게 이실직고하여 도움을 요청하였다. 다행히 팀원분들중 한분이 커밋기록을 백업해두셔서 GitHub 레포를 복구할 수 있었다. 이렇게 당황했던 경험을 통해 팀원들과 같이 작업하는 레포나 코드에 문제가 발생할 경우, 나 혼자 해결하려고 하지말고 최대한 팀원들에게 먼저 알려야겠다고 뼈저리게 느꼈다.
[2021.11. ~ 12.]
결론부터 말하자면 성공적이었다. 팀원들이 너무 잘 도와줘서 잘 끝낼 수 있었다.
수상을 위한 결선발표와 이노콘 때의 부스 및 발표를 준비해야 했다. 이노콘 부스 자료를 제출 5일 전에 공지를 해줘서 적지 않게 당황했지만, 역할 분담부터 차근차근 일정을 진행했다. 메인 배너와 사이드 배너, 영상을 제작해야 했는데, 프론트를 담당하는 팀원 중 디자인에 능한 팀원이 있어서 배너 제작에 힘을 써주셨다. (사실 나를 비롯한 다른 팀원도 배너 제작에 참여를 했지만 투표에서 밀렸다.) 그리고 영상 제작 경험이 있으신 팀원 분이 또 계셔서 영상 제작을 맡아주셨고, 결과적으로 퀄리티 높은 부스 자료를 제작할 수 있었다. 정말 능력자 분들만 모인 것 같아 든든했다.
이제 결선발표를 준비해야 했다. 발표는 팀장인 내가 맡았다. 이노콘 참여 자격과 수상이 달린 발표였기 때문에 부담이 되었지만, 침착하게 준비를 했다. 먼저, 발표자료 초안을 제작했다. 발표 틀을 구성한 후에 어떤 내용을 발표하면 좋을 지 생각했다. 그리고 회의 때, 만든 자료를 팀원들에게 보여주었고 자료와 발표 내용에 대한 팀원들의 의견을 모두 종합하여 다시 발표자료와 내용에 반영하였다. 그리고 발표자료의 디자인 역시 디자인을 담당해주시는 팀원이 해결해주셨다. 동일한 발표내용이라도 디자인에 따라 정말 차이가 컸다.
그리고 대망의 결선발표 날, 나는 발표를 하게 되면 염소목소리도 나고 굉장히 떨지만 게더타운에서 비대면으로 발표를 진행했기 때문에 덜 긴장할 수 있었다. 또한, 대본을 보면서 했기 때문에 무난하게 발표를 할 수 있었다. 그리고 며칠 지나 발표에 대한 결과가 통보되었는데, 영광스럽게도 20팀중 2등을 하여 42서울 학장님 상을 받게 되었다. 우리 팀원들이 자랑스러웠고 너무 뿌듯했다. 42서울 스탭이신 SongPD님이 교육생 평가에서 좋은 평가를 받았다고 말씀해주셔서 아마 프로젝트의 퀄리티도 좋았지만, 프로젝트 진행 동기가 더 좋게 평가가 된 것 같았다.
그리고 마무리로 이노콘 때 부스에서 이노콘에 참여해주신 높으신 분들(학장님을 비롯한 높으신 공무원분들..)께 간략히 프로젝트에 대해 소개드릴 수 있었고, 오프라인 프로젝트 발표를 마무리 지음으로써(발표는 살짝 아쉬움이 남지만...) 오픈프로젝트의 공식 일정을 모두 마무리할 수 있었다.
42doproject는 많은 것을 느끼게 해준 프로젝트였다.
기능을 구현하기 전, 기획 및 설계 단계의 중요성을 깨닫게 되었다. 앞서 설명했다시피 우리 팀은 기획단계를 생략하고 바로 기능 구현을 시작했다. 그리고 발생한 문제점들은 다음과 같다.
첫째, 일정관리가 힘들었다. 구현할 대표적은 기능으로 프로젝트, 프로필, 채팅, 검색, 라운지 기능을 선정했고, 이를 3개월 안에 구현할 것을 목표로 세운 후에 우선순위가 높은 프로젝트 관련 기능부터 구현하기 시작했다. 처음엔 모두 구현할 수 있을 것이라 생각했지만, 일정을 진행할수록 무리를 느껴서 프로젝트 진행 중간에 일정관리를 위해 구현이 필요한 기능을 나열한 후에 우선순위를 매겼었다. 역시나 구현할 기능이 너무 많았고, 기존에는 디버깅과 배포를 위해 한달을 투자할 계획이었지만, 이를 위해 따로 빼둔 한달도 기능 구현에 써야할 상황에 닥친 것이다. 이런 경험을 통해 확실한 기획단계를 거쳐야 일정관리도 쉽다는 것을 깨달았다.
둘째, 기능 구현에 대한 팀원간 통일이 되지 않았다. 라벨관련 기능을 구현하는 도중 오해가 생겼었다. 백엔드를 담당했던 다른 팀원은 인덱스에 따른 라벨은 프론트엔드에서 따로 관리해주기로 하고, db에는 인덱스만 저장하는 방식으로 라벨링 기능을 구현했다. 반면에 나는 라벨 테이블을 따로 만든 후에 라벨 테이블의 인덱스와 라벨링이 필요한 테이블에 연결하는 방식으로 라벨링 기능을 구현했다. 그리고 프로젝트 진행 도중 통일할 필요성을 느꼈고, 어느 방식이 더 효율적인지 고려했다. 그리고 팀원들과 상의 끝에 내 방식이 아닌 다른 백엔드 팀원의 방식이 더 효율적이라 판단해서 내가 구현한 라벨링 방식을 다른 팀원의 라벨링 방식으로 수정하였다. 이런 경험을 통해 기획 단계에서 특정 기능을 어떤 방식으로 구현할지 명시한다면 이런 오해가 발생하지 않았을 것이라고 생각했다.
문서화의 필요성을 많이 느꼈다. 기능을 구현하면서 그때그때 공부하고 배운 것들을 문서화하지 않으면 기억이 나지 않을 뿐더러 기억이 난다고 해도 문서화할 것이 많이 밀려있기 때문에 한꺼번에 하는 것이 힘들다.(사실 지금 회고록 작성도 벅차다...) 공부한 것과 배운 것들을 블로그에 기록하는 시간이 아깝다고 생각했는데, 시간을 들일만한 가치가 있는 것 같다.
[2021.12.]
친구따라 강남간다고 친구따라 지원했다가 면접기회까지 얻게 되었다. 멘토님들께서 회사에서 배우는 것이 더 많을 것이라고 말씀하시기도 했고, 돈도 빨리 벌고싶어서 이번 면접에 사활을 걸었다. SI 기업이라는 게 살짝 아쉽긴 했다. 그래도 큰 회사의 개발문화를 배우고 싶고, 신입 대상의 체계적인 교육을 경험하고 싶었다.
KT ds 면접은 크게 PT 면접과 임원면접을 진행한다.
PT 면접은 사전에 PT 주제를 제시하고 주제에 맞는 발표자료를 한시간 내에 제작해서 제출한다. 그리고 면접 당일에 PT 발표를 제출한 자료를 토대로 5분 내외로 발표한 후에 발표에 대한 질의를 받고 자소서 기반의 질문을 받는다. PT 면접은 잘 못봤다고 생각했는데 합격한거 보면 PT 관련 질문은 내 의견에 대한 근거가 있는지? 사업성과 연계할 수 있는지를 확인하는 것 같고, 자소서 기반 질문은 내용의 진위 여부와 프로젝트에 어느정도 기여했는지를 확인하는 것 같았다.
임원면접은 정말 잘 봤다고 생각했다. 회사에 대해 얼마나 알고 있는지와 나의 인성적인 강점을 확인하는 느낌이었다. 나는 강점으로 협업능력을 어필했고 실시간으로 잘 대답했다고 느끼면서 자신감도 충만해졌다. 다만, 회사에 대해 얼마나 잘 알고있는 지는 답변을 잘 못한 부분도 있어서 살짝 찝찝하긴 했는데 전체적으로 잘 본 면접이었다.
결과는 최종합격이었다.
앞으로 하고싶은 것이 많다.
일단 내년엔 우선적으로 사내 업무에 적응할 것이다. 에이스가 되어야지...
JAVA와 Spring에 대해 공부할 것이다. 대규모 트래픽을 경험하기 위해서는 유니콘 기업이나 대기업인 서비스 기업으로 이직을 해야한다. 이런 기업들은 대부분 JAVA Spring을 활용한다고 한다.
오픈소스를 만들거나 기여를 해볼 것이다. 팀 프로젝트나 사이드 프로젝트를 진행하면서 모듈화시킬 수 있는 부분을 오픈소스로 만들어 볼 것이다. 그리고 오픈소스를 활용하면서 불편했던 점이 있다면 개선해서 기여도 해보고싶다. 일단 백엔드 코딩 역량을 키우는 것이 선행되어야 한다.
다양한 컨퍼런스에 참여해볼 것이다. 컨퍼런스나 특강은 올해 11월부터 조금씩 참여했었는데, 개발에 대한 내 인사이트가 달라지는 느낌이었다. 반드시 내 성장에 도움이 될 것이라고 생각한다. 여태까진 따로 기록을 해두진 않았지만, 내년부턴 특강이나 컨퍼런스에 참여하게 되면 따로 기록을 할 계획이다.
TDD에 대해 공부해볼 것이다. 42서울 과제를 하거나, 코딩테스트 준비, 프로젝트를 하면서 공통적으로 느낀 점은 히든 테스트케이스를 잡는 것에 서투르다는 것이었다. TDD에 대해 공부해서 개발에 적용해볼 계획이다.
내년엔 더 성장한 내 모습을 기대하며...