🕺 그룹활동
web37조의 활동
세현 님과 3주 동안 같은 조였기 때문에 같은 콘텐츠를 반복할 수 없어 새로운 프로그램을 준비했다! 내 아이디어는 고갈되지 않지.. 이번 주의 프로그램은 동심퀴즈! 잘못하면 망할 수도 있겠다 싶었는데 다들 재밌게 참여해주셨다~~~ 이번 그룹원들과는 대화를 특히 많이 한 것 같다. 무슨 고민을 하고 있는지, 어떤 사람인지, 무엇을 하면서 살아왔고 현재는 어떤 상태인지 자세히 알아갈 수 있어서 즐거웠다.
3일차에 원판돌리기를 진행했었는데, 나영님과 세현님(내 흑기사)이 부스트로 삼행시가 걸려서 아래와 같이 답변해주셨다! 세현님이 말씀하시면서도 부끄러워해서 웃겼다. 더티유머 그룹활동에서 삼행시가 걸리지 않아 얘기하진 못했지만 블로그에서 남겨본다. 갑자기 부끄러움이 물 밀듯이...
나영님 삼행시
부: 부스트캠프를 하면서
스: 스있지도 못하고 맨날 앉아만 있는데
트: 트러블 없이 잘 마무리했으면 좋겠습니다.
세현님 삼행시
부: 부스트캠프를 하면서
스: 스스로 하는 것을 많이 배웠던 것 같아요. 계속 이어가야죠! 계속 앉아있다보니 소화가 잘 안 되는 것 같네요.
트: 트.....ㄹ....
내가 예비 부캠러에게 전하고 싶은 메시지
부: 부스트캠프!
스: 스응장(성장) 스토리를 만들어나갈 수 있는 곳!
트: 트라이!!! 도전하세요!!
💳 멤버십 일상
이번 주의 초점은 배포자동화였다. 자동화라면 환장을 하는 나에게는 너무 흥미로운 주제였다. 일단 직접 배포 환경에서 수정 및 배포를 하면서 배포자동화의 소중함을 느껴봤다. 지옥에서 온 git과 pm2 막상 배포를 하면 여기저기서 문제가 터져나온다. (CORS 문제부터 시작해서 노드 버전 문제, NGINX 실행 문제, 그 외에도 코드에서 발생하는 문제 등등이 그 내용이다. 무조건 다시 겪게될 문제라는 생각이 들어서 노션에 잘 정리해두었다.) 문제가 발생할 때마다 개발 환경에서 수정하고 push하고, 배포 환경에서 pull을 받아 배포를 다시 시작하는 작업을 수동으로 진행하다보니 시간이 오래 걸렸다.
배포자동화를 위해 필요한 3가지를 중점적으로 공부했던 것 같다. 리눅스 환경에 대한 이해, Github Actions, 셸 스크립트가 그 내용이다. 파트너가 챌린지 2일차 때문에 셸 스크립트 얘기만 들어도 PTSD가 온다고... 직접 해보기 전에는 엄청 어려워보이고 언터처블해보였는데 막상해보니 별 거 없었다. 물론 빌드나 테스트를 제대로 한 것 같아 보이지 않지만 공부해서 해본다면 잘 할 수 있겠다는 막연한 자신감이 생겼달까?? 주말에 보충 공부가 필요하다.
다음 주부터 학습프린트가 끝나고 그룹 프로젝트에 돌입하게 된다. 만약 프로젝트를 시작한다면, CI/CD부터 세팅해 제대로 해보고 싶다고 생각했다. 만들어놓은 게 있으니깐 금방하지 않을까
10/31(월) - P4 day11
쉬지 않고 달려온 탓일까.. 목도 아프고 온 몸 근육통, 관절통으로 아팠다. 몸에서 쉬어야 한다고 신호를 보내고 있었지만 쉬지 못했다. 프로젝트가 3주차로 접어들어 코드를 리팩토링하고 버그를 고치는 시간이 많아졌다. 눈에 보이는 성과는 없고 시간은 더 오래 걸렸지만 즐겁게 했던 것 같다. 과거의 내 코드들을 돌아볼 수 있는 시간이었고, 어떻게 하면 더 좋은 코드를 만들 수 있을까를 고민해봤다. 내 코드가 과연 유지보수하기 좋은 코드인지 의문이 들었다. 요즘 클린코드를 읽고 있는데 이 내용들을 내 코드에 잘 적용하지 못했던 것 같다.
11/1(화) - P4 day12
몸상태가 안 좋아졌다. 컨디션 조절이 필요하다는 판단 하에 세현님께 양해를 구한 뒤 2시간 정도 자고 개발을 시작했다. 개발자 도구를 켰을 때 밀림 현상을 해결하기 위해 몇 시간동안 삽질을 해봤지만 잘 되지 않았다. 끝까지 포기하고 싶진 않았지만, 배포의 중요도가 더 높다고 생각했기 때문에 배포를 하기로 정했다. 파트너 분이 멤버십에서는 아직 배포를 하지 못했다고 하셔서 직접 해볼 수 있게 양보해드렸다. 대신 나는 SQL 서버를 배포하고, 세현님이 서버 배포할 때 네비게이터 역할을 했다. <==훈수 좋아하는 사람
11/2(수) - P4 day13
이번 주중에서 일정이 가장 많았던 날이었다. 서버와 NGINX를 설정하고 배포를 마무리하니 오후 5시쯤 되었고, 그때부터 마스터클래스, 커뮤니티 행사, 그룹 프로젝트 미팅이 진행되었다. 일요일에 그룹원들끼리 모여 오프라인으로 회의를 진행하기로 했고, 가능하다면 멘토님과 같이 보자고 제안해보려고 한다. 모든 일정이 끝나고나니 11시였다. 급하게 세현님과 만나 Github Actions으로 SSH를 통해 서버에 접속하는 것까지 해봤다! 하루를 아주 알차게 보낸 느낌..
11/3(목) - P4 day14
Github 자동화를 완료했다! 자세한 소감과 고민은 위에 참고!
오늘은 명일이의 생일이었다! 명일이한테 기프티콘을 보내고 축하를 해주며 하루를 시작했다. 명일이가 면접을 보는 날이어서 저녁에 잠깐 얘기하려고 챌린지 1주차 채널방에서 허들을 틀었는데 하나둘씩 들어와 그룹 프로젝트를 같이할 멤버들과 모여 얘기를 나누게 되었다. 프로젝트 얘기로 이어졌고, 자연스럽게 프로젝트 리더가 되어버렸다. 발표기계 민경이가 그룹 프로젝트 꿀팁을 리뷰어님한테 여쭤봤다고 한다!! 아래가 그 내용이다.
11/4(금) - P4 day15
이래저래 정신없는 하루였다. 공유 오피스 구하느라 전화도 돌리고, 피어세션 진행도 하고 신경쓸 게 너무 많았다. 학습 스프린트 마지막 피어세션인데 약간 아쉬웠달까.
일정이 끝나고 난 후 그룹 프로젝트 멘토링 킥오프가 진행되었다. 일요일에 그룹 프로젝트 친구들과 모임을 가지기로 했는데 혹시 멘토님도 와주실 수 있냐고 여쭤봤다. 일정 확인해보고 알려주신다고 하셨다!! 9시에 멘토링 킥오프는 끝났지만 멤버들끼리 잠시 남아 10시까지 얘기하고 하루를 마쳤다. 오전 10시부터 오후 10시까지... 거의 하루종일 줌 활동만 하니 진이 다 빠졌다. 오늘은 "프로그래머의 뇌"라는 책을 읽으면서 하루를 마무리했다.
👨🏫 이번 주의 커뮤니티 행사
진유림님의 "개발자, 회사 가기 A to Z 특강"
11/2(수)에 진행된 커뮤니티 행사로 토스 개발자로 유명하신 진유림님이 "개발자, 회사가기"를 주제로 특강을 해주셨다. 유튭에서 몇 번 봤던 셀럽.. 개발자로서 자신의 모양을 얘기하실 때는 엄청 놀랐다. 나와 비슷한 점이 굉장히 많아보였기 때문이었다. 손이 빠른 편이라던지, 문서 읽기보단 부딛치며 익히는 걸 선호하는 모습 등이 그 내용이었다. 아직 나의 모양을 생각해본 적이 없었는데 유림 님의 얘기를 듣고선 조금씩 탐구해 나가야겠다는 생각이 들었다.
인상적이었던 얘기들
첫 취직은 구렁이 담 넘어가듯 취직을 하는 것도 좋습니다! 어느정도 재는 것은 중요하지만, 너무 심하게 재지 마시고, 어떤 회사든 싹 들어가서 빠르게 경험을 쌓는 것을 추천드립니다.
이직하는 이유?
1. 내가 회사랑 안 맞아서 회사에서 나를 원하지 않는다.
2. 내가 회사랑 안 맞아서 내가 회사를 원하지 않는다.
3. 통보받는다. (회상 경영방향 변경, 한국 지사가 사라짐, 권고사직)
4. 고원(plateau)을 만났다.
자유 양식 이력서
- Head: 이름, Email, Github, Blog 링크
- Summary: 2~3줄 이내(여태까지의 경험, 관심사, 하고 싶은 것)
- 경력: 최신 순
- 개인 프로젝트: 직무와 연관성있거나 기술적 난이도가 있는 것 넣기(너무 오래 전에 한 것이나 완성도가 현재 개발하는 것보다 많이 떨어지는 것은 제외)
- 발표 슬라이드 (기술발표 기회 있으면 하기!!!)
- 최대한 한 장에 넣기. 구구절절 절대 필요없다. 제일 중요한 단어 고르기. 면접관도 사람이라 다 읽을 수 없다. 양파같은 사람이 되자!
면접관으로서 보는 이력서
1. 이력서에 사진은 안 넣어주셨으면 좋겠다. 불필요한 input이라고 생각한다.
2. 이력서를 엄청 빨리 읽기 때문에 가장 중요한 게 위에 들어와야 한다.
3. 개인 프로젝트를 봤을 때, 이 지원자가 어디부터 어디까지 할 수 있는지를 파악할 수 있다. (e.g. 배포를 CI/CD를 관리, 디자인을 UI로 뽑아낼 수 있는지)
개인 프로젝트
- 하나를 제대로 하는 것이 좋다. 많을수록 좋진 않다.
- 완결성있는 프로젝트
- 3명, 10밖에 없는 사람이더라도 유저가 있는 것이 Best (github star를 받았다던가, 사람들이 해당 프로젝트 라이브러리를 사용한다든가)
🌟 이번 주의 특별한 일
마스터님들의 코드리뷰
피어세션 도중에 슬랙에서 성은님한테 코드리뷰 지목해도 되겠냐고 DM이 왔다. 살인예고 결국 마스터클래스에서 호명되었고, 마스터 님들께 리뷰를 받아보는 귀한 경험을 하게 되었다. 내 코드리뷰 질문과 답을 정리하자면 아래와 같다.
Q. 프로젝트를 시작하기 전, 리뷰어 님이 전역 상태 라이브러리를 사용해보는 것보다는 context API를 사용해보고 학습해보는 것이 좋을 것 같다고 하셨습니다. 고민해보니, 전역 상태로 관리할 값이 많지 않고, 굳이 학습난이도가 높은 리코일을 먼저할 필요가 있을까하여 Context API를 학습해 사용해봤습니다. 혹시 전역 상태 라이브러리를 사용하기에 앞서 공부해보면 좋겠다고 생각하시는 것들이 있으신가요??
조은님 A. 굳이 따지자면 공부하는 순서가 딱히 정해져있진 않습니다. 다만, Context API와 Recoil의 차이 정도는 짚고 가야되지 않을까 생각이 드네요. 전역 상태 관리가 필요하다고 느끼면 그 때 공부하는 것이 맞는 것 같습니다. Redux, Recoil 등등 다양한 상태 관리 라이브러리가 있지만 Recoil을 가장 처음에 접하는 것이 가장 좋을 것 같다고 생각해 가이드라인으로 드리긴 했습니다.
Q. 비제어 컴포넌트에 대한 질문. 리뷰어 2분의 의견이 달랐던 것을 설명. 마스터 님들은 어떻게 생각하는지 여쭤보았다.
Opinion1. useRef 사용해야한다는 분의 의견: state로 해서 이득될 것이 하나도 없다. 괜히 렌더링만 된다.
Opinion2. useState를 사용해야한다는 분의 의견: ref를 이용하는 이용하면 컴포넌트 생명주기에 관계 없이 컴포넌트를 직접 다룰 때 사용합니다. 따라서 리렌더링이 일어나지 않게 되죠. 하지만 컴포넌트 생명주기에 벗어난다는 것은 개발자가 직접 신경을 써주어야 하는 부분이 늘어난다는 것입니다. 완벽하게 다루지 못한다면 ref를 이용해 컴포넌트를 직접 다루는 것은 비추천해요.
조은님 A. 일단은 unhandled input을 사용하는 경우는 input의 크기가 방대하고, 많은 데이터들이 있어 input 하나하나를 state로 관리하기 어려울 때입니다. state를 사용하게 되면 입력이 발생할 때마다 계속 리렌더링이 발생하기 때문에 자원이 조금 소모되긴 합니다. 그래서 사실 useRef를 사용하는 것과 useState를 사용하는 것은 취사선택의 영역에 가깝다고 생각합니다.
하지만 고민해봐야할 부분은 있습니다. state를 이용해 input을 구성한다고 하면 onChange에 이번트를 만들어서 넣어줘야하고 state도 컴포넌트에서 선언해줘야 합니다. state가 많아질 수록 제어할 것이 많아지기 때문에 프로그램의 복잡도가 높아지긴 하죠. 하지만 입력 단계에서 입력값을 제어하고 싶다면 state를 사용해야 합니다. submit할 때만 제어하면 될 것 같다고 생각이 들면 useRef도 괜찮습니다만 입력 단계에서 입력값을 제어할 수 없다는 단점이 있습니다. 사실 둘 중 어떤 것을 써도 성능적으로 드라마틱한 차이가 발생할 것 같다는 생각은 안 드네요.
한 가지 고치고 싶은 점이 있다면 form을 사용하고 있기 때문에 차라리 form의 submit 이벤트를 잘 활용하는 식으로 바꾸면 좋을 것 같습니다. form이 되게 많은 일을 처리해줄 수 있기 때문에 form에 대해 더 공부해보시면 좋을 것 같다고 생각했습니다.
송요창님 A. 입력값을 제어하라는 요구사항이 붙는 경우가 있을 수 있어요. 패스워드에 영문, 숫자, 특수문자가 포함되어야 한다고 했을 때, 입력 단계에서 제어하지 않고 submit한 후 error를 알려주는 방식도 있을 수 있지만 입력단계에서 밑의 체크박스에서 영문, 숫자, 특수문자를 체크해주는 UI가 있을 수도 있습니다. 이러면 어쩔 수 없이 state를 사용하실 수 밖에 없을 거에요. 요구사항에 따라서 상황이 바뀔 수 있다고 생각합니다. 하지만 요구사항에 없다면 그거대로 취사선택을 잘 하시면 될 것 같습니다.
Q. isLogin 상태값을 전역 상태나 Context API로 관리하는 것에 대해서 어떻게 생각하시는지?
송요창님 A. 예전에 만들었던 서비스에서 isLogin 값을 관리했던 적이 있지만 만드신 프로젝트와는 결이 다른 것 같습니다. 제가 하는 프로젝트는 결제 진행, 페이지 이동 등등 API 호출을 통해 토큰이 유효한지 확인할 수 있는 포인트가 많습니다. 그런데 현재 진행하신 프로젝트는 로그인 후에는 필드에서 돌아다니는 것이 주요 기능이기 때문에 API 콜을 자주 하지는 않는 것 같습니다. 토큰의 유효성을 체크할 수 있는 부분이 많이 부족하다고 생각합니다. 만약 온라인게임처럼 데미지를 넣는 상황이 있다면 로그인이 유지되는 것이 중요하겠지만, 그런 요소 없이 순수하게 돌아다니고 얘기만 가능한 환경에서 로그인이 유지되지 않는다고 해서 불이익이 없기 때문에 로그인 상태를 전역 상태로 관리하는 필요가 없다는 생각이 듭니다.
조은님 A. 만약 중간에 토큰이 유효하지 않게 되면 어떻게 되나요? (내 답변) 상태값에 isLogin이 true이기 때문에 새로고침하지 않는 이상 로그인된 것처럼 서비스를 이용할 수 있습니다.
로그인이 유효한 지 확인하는 방법은 여러가지가 있을 수 있습니다. 요창님이 말씀해주신 것처럼 특정 시간(15분, 30분)마다 API 호출을 실행해 토큰이 유효한 지 확인해보는 방법을 사용할 수도 있습니다. 여기서 고민해봐야할 것은 구현체를 먼저 고민하고 구현해버리면 뻔해진다?(라고 표현하는 게 맞을까요?) 구현체에 스펙을 맞춰서 구현을 진행하게 되버려요. 구현체에 욱여 넣을려고 하게 됩니다. 그렇게 하시기 보다는 구현을 어떻게 할지 스펙을 구체적으로 생각해놓고 구현체에 대해 생각하는 것을 추천드리고 싶습니다. 어떻게든 구현하면 되는 거라고 생각합니다. 방법은 되게 많아요.
가장 인상적이었던 한 마디는 "프로덕트의 스펙을 먼저 구체적으로 생각하고 스펙에 맞춰 구현하는 것이 좋습니다. 구현체에 프로덕트를 맞추는 것은 추천하지 않습니다."이다. 이 말을 듣는 순간, 프로젝트를 생각하는 대로 만들지 않고, 그냥 만들어지는대로 생각을 끼워 맞춰 왔다는 사실을 깨닫게 되었다.
✍ 학습스프린트를 마치면서
멤버십 시작하고 벌써 8주라는 시간이 지나가버렸다. 돌아보니 2달이라는 시간 안에 엄청나게 많은 일들이 있었다. 그 어느 때보다 기술적으로도, 인간적으로도 많이 성장한 나의 모습을 볼 수 있었다. 멤버십에 합격한 후 기뻐서 방방 뛰었던 모습, 즐거운 그룹활동을 위해 프로그램을 기획하고 즐거운 모임을 진행했던 장면들, 월화수목금금금!! 휴일따지지 않고 달려왔던 날들, 컨퍼런스 모더레이터로 활약하고 많은 캠퍼들과 친해졌던 순간들, 개발과 인문학 모임에서 대화하고 힐링하던 추억, 세현님과 페어 프로그래밍하면서 함께 성장해나갔던 시간들, 귀찮았지만 매주 블로그를 꾸준히 써왔던 기억, 그 외의 많은 컷들이 머리 속에 스쳐지나간다.
학습스프린트가 끝난 기념으로 KPT 회고를 한 번 해볼까한다! (용석님 블로그보고 배움)
Keep
- 궁금할 때마다 동료 붙잡고 질문하기
- 매주 블로그에 회고 · 후기 남기기!
- 구현할 때 발생하는 이슈를 그때그때 정리하기
- 동료들과 즐거운 시간을 보내기 위한 프로그램 기획하기
- 그룹원들과 소통하기 위한 시간 만들기
- 동료 간 코드리뷰
Problem
- 학습스프린트 초기에는 캠퍼들이 경쟁 상대로 보였던 적도 있었던 것 같다.
과잉경쟁에 찌들어버린 사람..(지금은 완전 소중한 동료들~) - 번아웃? 늘어짐..
- 마스터 클래스에서 저하되는 집중력
- 떨어지는 체력
- 구현만 빨리빨리 하려고 하는 습관 (그룹 프로젝트에서는 필요할 수도..?)
Try
- 마스터 클래스를 기록하면서 청강하기
- 계획적으로 운동하기 (1시간마다 푸시업 30회씩 하기, 주말에는 산책과 함께 refresh)
- 워~~ 워~~ 필요! 구현체에 매몰되지 않고 생각하기! 돌아보기! 페이스 조절!
