👨💻 그룹 활동
chosimhe 살려....
드디어!! Let's Encrypt의 인증서 발급 제한이 풀려 성공적으로 프로젝트를 배포할 수 있게 되었다. 링크는 아래와 같다
그룹 프로젝트 4주차는 그 어느 때보다 바빴던 것 같다. 다음주는 더 바쁠 예정.. 최대한 빠르게 기능을 만들기 위해 매일같이 야근을 진행했다. 다들 새벽 1, 2시까지 컴퓨터 앞에 앉아 분투했다. 민경이는 면역력이 떨어졌는지 감기에 걸렸다. 하루는 몸이 너무 안 좋다고 재택근무를 했는데, 집에서도 쉬지 않고 열심히 해줬다. 다들 많이 힘들텐데 최선을 다하는 모습을 보며 나도 힘을 얻었다.
팀회고
Keep
- 스스로 구현하고 공부한 것들을 블로그나 노션에 잘 정리하기, 또 이것들을 공유하기
- 무지성으로 질문하지 않는다! 질문하기 전에 고민해보고 정보도 찾아본 다음에 질문하자! 타이밍을 잘 맞춰서 질문하자.
- 리뷰를 열심히 적어보고 있다. 내가 개발한 내용도 상세하게 적으려고 노력하고, 다른 사람의 코드도 꼼꼼히 보려고 하고 있다.
- 무엇을 얘기하든 이유(Why)를 생각하고 얘기하려고 한다.
- 풀리지 않는 문제를 혼자 고민하지 않고 다른 사람과 소통하며 문제를 해결하기
- 즐겁게 하기!
Problem
- 무지성 Approve가 남발될 때가 있다.
- 개발을 할 때 문서화를 열심히 하자고 다짐했었지만 구현에 급급해 문서화를 하지 못했다.
Try
- 구현으로 바쁘더라도 코드 리뷰를 꼼꼼히 해보자.
- 퇴근하면 오늘 진행한 내용을 정리하고 문서화하는 습관을 가지자(퇴근길 지하철에서?!?), 삽질한 것 문서화 잘 해두자
💳 멤버십 일상
겨울이 갑자기 와버렸다.. 으으.. 너무 추워
이번 주는 죽음의 행군이었다. 생활이 챌린지 때로 돌아갔다. 이번 주는 매일 새벽 2시에 자서 7시 30분에 일어나 신도림으로 출근하는 일상이 반복되었다. 3주 동안 기획 및 설계, CI/CD, Docker 세팅, HTTPS 배포 등으로 바빴기 때문에 기능 구현이 거의 되어있지 않은 상황이라 계획을 빡빡하게 잡았다. 월요일에 시작할 때는 많이 못할 거라고 생각했지만 생각보다 많이 했다. 야근한 보람이 있다.
4주차 데모 링크: chosimhe 4주차 데모
11/28(월) - Week4 day1
오랜만에 1시30분까지 야근을 했다. 저번 주까지만 해도 nest가 너무 낯설어 모든 것이 다 어려웠었고 마음대로 코드가 돌아가지 않아 스트레스도 받았다. 이제 어느정도 적응이 된 것 같다. 명일이가 팀내 기술공유에서 발표해준 덕분에 생명주기에 대해 조금은 이해하게 되었고, 계속 살펴보다보니 코드도 눈에 익게 되었다. 잠에 들기 전 다음 날이 너무 기대가 되었다. 내일은 어떤 코드를 만들고 있을까? 어떤 것을 공부하고 더 배우게 될까?
이력서에 뭘 쓸까 고민이 되어 유튜브를 찾아봤다. “신입 개발자 이력서”라고 검색하니 좋은 정보들이 엄청 많았다. 가장 인상 깊었던 피드백 내용은 나와 처지가 비슷한 사람에 대한 이야기였다. 학점만 높고 보여줄 수 있는 프로젝트는 부족한 상황이었다. 그 분의 이력서에는 프로젝트 설명과 어떤 기술을 사용했는지 정도가 들어있었다. 심지어 이력서 내용도 나와 비슷.. 여기에 대한 피드백 다음과 같았다.
‘신입 개발자들은 어차피 다 거기서 거기이다. 모르는 게 많을 수 밖에 없다. 결국 채용하는 입장에서 가장 신경쓰는 것은 그 사람의 성장 가능성인데 이것을 어필하는 것이 좋을 것 같다. 프로젝트에서 본인이 어떤 역할을 했고, 어떤 문제를 겪었는지 또 무엇을 배웠는지 소감같은 것을 넣으면 좋을 것 같다.’
이 피드백을 보면서 그동안 코드리뷰하면서 주고 받았던 소통 과정을 블로그에 정리에 링크로 올려두면 좋을 것 같다고 생각했다! 이상한 곳을 삽질하고 있던 나를 잡아준 팀원들, 질문에 답을 달면서 내가 아는 것들을 잘 정리했던 기억 등을 잘 정리하면 좋지 않을까?? 블로그에 정리해보자!
11/29(화) - Week4 day2
드디어 애증의 HTTPS를 끝냈다. 승찬이가 만들어놓은 NextJS를 위한 NGINX 캐싱을 도커 환경에 적용하는 것까지 완벽히 마쳤다!! 배포와 이 친구때문에 일주일을 고생했었는데 떠나보내니 뭔가 시원 섭섭했다. 하나하나 만들어가고, 공부하고, 고민하고 시간은 오래 걸렸지만, 배운 점은 많았다.
설계를 빡세게한 덕분인가? 물론 명일이가 이제 API를 만드는 것에 속도가 붙는 것 같다. 그런데 예기치 못한 버그를 만났을 때 삽질이 길어지는 것 같다. 승찬이가 이미지 업로드 API를 사용하려고 Swagger를 확인했는데 이미지 업로드의 Body가 비어있었다. 급하게 브랜치를 만들어 @ApiBody 를 사용해 Body의 추가하려고 했다. 무슨 짓을 해도 죽어도 안 들어갔다. 내 접근 방식이 잘못된 것도 한 몫했지만 Swagger를 한 번밖에 접해보지 못한 나로서는 아는 것이 하나도 없었다. 1시간 동안 삽질하던 걸 명일이가 나서더니 5분 아니 1분만에 뚝딱해내버렸다.
작년에 복수전공을 시작해 학교에서 수업들을 때까지만 해도 클래스에서 1등을 하는게 일상이었고 나 정도면 잘하나보다라고 생각하고 있었다. 하지만 우물 안 개구리였다. 뭘 공부해야 하는지도 전혀 모르고 있었고 스스로 찾아서 공부할 줄도 몰랐던 것 같다. 나무에 달린 열매를 따먹는 사람이 아닌 땅에 떨어진 뭉개진 열매나 주워먹던 놈이었던 것 같다. 나에 대해 반성을 해보자면, “아는 게 없다”가 가장 많이 드는 생각이고 “고민도 부족하다”가 그 다음이다. 나는 항상 마음만 급했던 것 같다. 예전에 내가 개발을 공부하는 방식을 생각해보면 그저 빨리빨리 겉핥기만 했던 것 같다. 부스트캠프를 하기 전까지 (개발에 한해서는) 단 한 번도 “딥다이브”한 적이 없었다. 그동안 내가 해왔던 건 개발이 아니라 복사 붙여넣기였다.
아직도 예전에 공부하던 습관을 완전히 버리진 못했지만, 그래도 많이 나아졌다. 부캠 챌린지, 멤버십의 경험을 하기 전과 후가 천지차이다. 찾아서 공부하는 능력도 많이 늘었고, 고민도 전과 비교하면 많이 깊어졌다. 진짜 개발의 재미도 깨달아가고 있다. 요즘은 머리 속에 개발 생각밖에 없다. 출퇴근하면서도 개발서적을 읽고 유튜브도 개발 유튜브를 본다. 심지어 개발을 모르는 누군가와 얘기할 때도 개발 이야기를..
11/30(수) - Week4 day3
다른 사람과 일한다는 것은 그 사람과 코드스타일을 맞춰야한다는 것과 똑같은 말이다. 오늘도 여느 때와 같이 정신없이 코드를 만들고 있었는데 명일이가 코드 리뷰를 하더니 급제동을 걸었다. 컨벤션의 문제였다. 나도 명일이의 코드를 읽어봤는데 둘의 코드스타일이 전혀 맞지 않아보였다. 미루지 않고 그 때 만들고 있던 내 코드를 명일이의 코드스타일에 맞춰보기로 했다. 남의 스타일에 맞춰서 코드를 적는 게 쉬운 일은 아니었다.
명일이가 만든 엔티티 메소드를 재사용해 꽤 괜찮은 코드를 만든 것 같다. 물론 스스로 사용한 것은 아니고 코드리뷰를 할 때 알게된 것이다. 나는 절차지향적으로 코드를 만들고 있는 편이었고, 명일이는 객체지향적으로 짜고 있었다. 명일이가 이것을 캐치해냈고 자신의 코드 구조를 나에게 알려주기 시작했다. 이를 응용해 내 코드에 적용시켜봤다. 객체들이 역할을 분담하고 있으니 확실히 코드가 간결해지고 예뻐졌다. 클린 코드의 덕도 어느 정도 있는 것 같다. 근데 다른 사람이 보기에도 가독성이 좋은 지는… 이 경험을 통해 팀 단위로 프로젝트를 진행할 때는 코드를 파악하는 것이 제일 중요하다는 것을 깨닫게 되었다. 아는만큼 예쁜 코드를 만들 수 있다! 내가 취업을 하게된다면 아마 만들어져있는 코드를 파악하고 그것을 유지보수하는 작업을 하게될 것이다. 그걸 알면서 팀 프로젝트에서는 코드를 파악하는 것에 큰 노력을 기울이지 않았던 같다.
개발자는 문서로 일한다는 마스터 조은 님의 말을 이제야 이해하게 되었다. 문서의 단어 하나 차이가 엄청 큰 차이를 만들어낸다. 그 단어 하나 차이로 해석이 갈리고, 지금까지 만들어놓은 코드를 갈아엎어야할 수도 있다.
테스트 코드의 필요성을 절실히 느낀 날이었다. 코드를 바꿀 때마다 직접 다시 테스트해보는 작업이 생각보다 비용이 많이 든다. 테스트를 작성해놨다면 발생하지 않을 비용이었다. 이렇게까지 테스트 코드를 짜고 싶었던 적은 없었다. 코드 스타일이 중요하다, 협업은 뭐다, 개발자는 문서로 일한다, 테스트가 중요하다 등등 이론으로만 알고 있던 내용들을 몸소 느끼고 있다. 체험으로 배우는 개발! 이렇게 배워가는 건가??
생각보다 예외처리해야할 부분이 굉장히 많다. 내가 놓친 부분이 생각보다 많았고, 감사하게도 명일이가 코드 리뷰를 통해 이를 보충해주었다!! 야근 플러스
오늘 멘토링도 상당히 즐거웠다~~ 클린 코드를 다 읽었다고 말씀드리니 새로운 책을 추천해주셨다. 바로 구매했다. 오늘 운좋게 멘토님한테 코드리뷰를 받을 수 있는 기회가 있었다. 왠지 면접을 체험해보는 느낌이었다. async/await, Promise에 대한 질문을 하셨을 때 알고 있었는데도 왠지 우물쭈물하게 되었다. 요즘 실력에 대한 자신감이 많이 떨어지다보니 나 자신에 대한 확신도 줄어든 것 같다. "Promise Pending 어쩌구저쩌구.. 맞나요..? 사실 잘 모르겠습니다. 하하"라고 하니 멘토님이 설명을 해주시기 시작했다. 역시 알고 있는 거였다. 이래서 면접가서 잘 할 수 있을까..? 멘토링이 끝난 후 슬랙으로 멘토님한테 도커를 왜 사용하냐는 기습 질문이 들어왔다. 한참을 고민한 이후에 아래와 같이 질문에 답변했는데 맞는 답을 한 건지는 모르겠다. 그래도 내가 생각했을 때 도커가 필요했던 이유는 다 적었다.
12/1(목) - Week4 day4
챌린지, 학습스프린트를 할 때까지만 해도 취업에 대한 자신감이 넘쳤는데 지금은 완전 땅바닥이다. 팀프로젝트를 진행하면서 내 부족함도 많이 알게되었고, 시장 상황이 좋지 않다는 불안감도 있다. 오늘은 이력서 특강이 있는 날이었다. 이력서가 미완성되어 제출할 수 없었지만 다른 캠퍼들의 피드백을 듣는 것만으로도 충분했다. 명일이와 승찬이의 이력서가 피드백을 받았는데 굉장히 칭찬을 많이 받았다.
이력서때문에 고민이 많은데 명일이가 발벗고 나서서 스토리까지 만들어줬다. 좋은 아이디어여서 바로 적용해봤다. 오늘 내 생에 처음으로 N+1 문제를 직접 겪어봤는데 자료도 조사해보고, 해결 방법을 정리해서 블로그에 적어봤다. 이력서에 링크로 걸어볼 생각이다. 요즘 명일이한테 벽을 느끼고 있다. 고민의 질이 다르다. 명일이는 서비스를 만들어내고 있지만, 나는 옆에서 소꿉장난하고 있는 거 같다. 내가 모르는 문제들과 예외들을 명일이가 쪽집게처럼 다 집어준다. N+1 문제도 그렇고, 도커컴포즈, Swagger, Typeorm IsNull() 등등 캐치하지 못하거나, 알지 못하는 것들이 셀 수 없이 많았다. 민망하게도 기본적인 실수들도 너무나 많이 한다. 명일이도 고쳐주는 재미에 내 코드보는 맛이 있지 않았을까…? 나도 1인분을 하고 싶다.. 넓은 관점에서 코드를 보지 못하고 있다. 내가 만든 코드가 우리 서비스에 어떤 영향을 미칠지 전혀 생각하지 못하고 있다. 심지어 우리 코드의 구조도 100% 파악하고 있지 못하는 것 같다.
12/2(금) - Week4 day5
기술공유 발표에 당첨되었다. 이전부터 작성해왔던 코드 리뷰 === 나의 성장 === 프로젝트 완성도 ? 라는 글을 이용해 발표를 진행했다. 기술 공유를 마치고 팀원들과 피그마에서 만나 팀회고를 작성해봤다. 소소한 재미로 팀원들과 갤러리를 꾸며봤다.
🕺 이번 주의 커뮤니티 행사
이력서 특강 <이력서가 뭐라고 생각하세요?> (aka. 샤빱두비두밥~)
강의는 굉장히 즐거웠다. 연사님이 팩트폭격기셨다. 한마디 한마디가 기억에 남을정도로 강려크했다. chosimhe에서 2명의 친구가 피드백을 받았는데 둘 다 칭찬을 많이 받았다. 명일이의 이력서가 특히 돋보였던 것 같긴하다. 연사님도 아주 잘썼다고 칭찬 일색이었다. 역시 인프런 합격자의 이력서...
면접과 이력서는 뗄레야 뗄 수 없는 존재이다. 결국 면접도 많이 해봐야, 이력서는 많이 써봐야 느는 것이기 때문에 시도를 많이 해볼 수록 좋다고 얘기해주셨다. 하지만, 한 번 탈락할 때마다 심적이 데미지가 생각보다 크다고 말씀해주셨기 때문에 어느정도 완급조절은 필요한 것 같다.
- 면접을 봐야 이력서를 잘 작성할 수 있다.
- 면접을 보려고 이력서를 쓰는 것도 맞지만, 여러분들은 이력서를 쓰기 위해 면접을 봤으면 좋겠습니다
- 이제는 직접 만들자.
- Top 100 Front-End Interview Qeustion
- Top 100 Backend-End Interview Qeustion
- 면접은 무조건 녹음하세요!
녹음하고 공유하시면 큰일납니다.- 내 이력서에서는 이것만 보면 좋아하더라, 칭찬받는 것들이 있다면 ⇒ 이력서 상단으로 옮겨야 한다.
- 내 이력서에서는 이것만 보면 흠을 잡고, 욕을 하고, 뭐라고 하더라 ⇒ 이력서에서 하단으로, 또는 삭제해야한다.
- 이력서를 두 벌쓰는 경우도 있다.
- 이런 회사는 이런 이력서를 좋아하더라
- 저런 회사는 저런 이력서를 좋아하더라
- 면접을 보면서 이력서를 끝없이 분석해야한다.
- 나중에는 내가 넣어본 회사들을 분석해볼 수 있다.
- 고치고 또 고치고 고치고 하다보면 괜찮아진다. 공부도 지속적으로 해야한다.
연사님은 4단 구성을 가장 좋아하신다고 하셨다. Why, How, Result, Prize의 4단 구성이다. 특히 수치적인 성과를 가장 강조하셨다.
인상적인 얘기들
Q.팀원과 페어 프로그래밍으로 같이 했는데 그냥 자기가 한 걸로 적어도 되나요?
A. 내가 한 거 맞아요 고민할 필요 없어요. 어차피 면접가서 대답 못하면 내꺼 아니에요. 내가 한 거 아니어도 면접에서 대답할 수 있으면 내꺼에요.
Q. 수치적인 성과가 없는데 어떻게 할까요?
A. 그럼 지금 바로 라이트하우스 찍어보면 되는 거 아닐까요? 가장 쓰레기일 때 지표를 찍어야 드라마틱 합니다. 지금하고 빨리 개선합시다. 신입들한테 성능 최적화 질문하는 회사 너무 많습니다. 이력서 고칠 시간에 하나라도 더 개선합시다.
그런데 개선할 상황도 아닌데 개선하는 것도 악영향이 있습니다. 그러니 왜 해야했는지 잘 적어놓으시면 굉장히 좋습니다.
Q. 비전공자인데 개발을 시작한 계기를 넣는게 좋을까요?
A. 애매하다. 울림을 줄 수 있는 내용이라면 넣는게 좋아요 괜히 트집만 잡힐 거 같으면 넣지 마세요
Q. 공백기를 어떻게 설명해야할까요?
A. 공백기는 중요하지 않습니다. 실력이 중요합니다. 결과론적인 측면이 많아요. "면접을 잘보면 역시 공백기가 아니었네. 그 시간에 공부했구나"라고 생각합니다. 면접을 못보면, "역시 공백기는 공백기네"라고 생각하죠. 공백기로 고민하지 맙시다. 공백기에 대해 걱정을 가지고 있으면 괜히 말실수하게 됩니다. 말실수, 방어기제, 물어보지도 않았는데 먼저 얘기하게 된다던가 실수를 하게 됩니다.
A. 도그 푸딩 관점에서 이력서를 작성하는 방법
- 너를 위해 이런 걸할게 나는 이런걸 할 수 있어(0)
- 너네 요즘 이런 거 한다면서? 나도 이런 경험있고 할 수 있어(0)
- 너네 회사 문화가 좋아서 지원했어(x)
첫 직장이 별로면 어차피 내년에도 내후년에도 좋은 회사 못간다는 말, 다 어불성설입니다.
첫 직장이 안 좋으면 그 회사에서 가장 잘하는 개발자가 되면 됩니다.
그 회사에서 중간정도만 해서 문제에요.
그러니 경력을 쌓는게 아니라 3년 후에 네이버가는거면 3년 후에 네이버 3년차 수준의 개발자 실력을 만들면 되는 겁니다. 경력은 숨만 쉬어도 쌓이는 건데, 경력 쌓이면 좋은 회사 간다. 아닙니다.
