👨💻 그룹 활동
하루하루가 즐거운 chosimhe
이번 주는 다사다난했던 주였다. 원래 가지고 있던 노트북이 도커를 감당하지 못해 거의 이틀 동안 개발을 못하다시피 했던 때도 있었고(너무 답답한 나머지 맥북을 구매해 버렸다. 킹갓맥북... 너무 좋다.) 팀원과 말다툼(?)을 하기도 했었다. 금요일엔 오피스 동지인 web20 OAO팀이랑 조은 님과 회식을 하러 나가기도 했다. 일주일이 참 짧은 것 같으면서도 길었다.
이번주의 KPT 회고
Keep
- PR 올라오면 모든 코드 살펴보기, 다른 팀원이 만든 코드 열심히 읽기
- 이슈가 생겨서 해결한 과정을 문서로 남겨놓기!! 남는 것은 기록이다!
- 잘 웃기! 즐겁게 하기
Problem
- 고민만 너무 많이 한다.
- 할 일을 제 시간에 끝내지 못하고 있다.
- 논의할 얘기가 생기면 생각없이 바로 얘기해버리는 것 때문에 남의 시간을 많이 빼앗는 것 같다.
- 이해했다고 생각했던 것들이 머리 속에 정리되지도 않았고 다 사라져버렸다.
Try
- 고민한 내용을 노션 페이지에 정리하고 공유하자.
- 자기자신을 과대평가하지 않은 상태에서 계획을 세워야할 것 같다.
- 남에게 말로 고민을 꺼내기 전에 다른 자료들을 조사해보고, 스스로 고민한 이후에 생각에 확신이 생기면 논의해보자.(그렇다고 질문을 너무 자제하지는 말자.)
- 흐름을 머리 속에 그려보고 이를 글로 정리해보자.
💳 멤버십 일상
chosimhe의 열정 가득한 일상!
전초전 - 토요일과 일요일
토요일에는 다들 출근했다. 출근해서 저녁먹기 직전까지만 일하다가 내일 12시쯤 다시 만나자며 퇴근했다.
그런데 누구씨가 파토를 내버려서 그냥 재택 근무를 하기로 했다. 재택근무를 하고 있는데 그 누구씨가 아래와 같이 질문을 해줬다. 예전같았으면 대답해주지 못했을 내용들을 내 머리 속에 가지고 있고 이를 나만의 언어로 설명할 수 있다는 사실이 너무 뿌듯했다.
일요일 저녁 8시에 만나 회의를 진행하다가 원래 월요일에 할 일이었던 README 작성을 진행했고 오후 11시에 겨우 끝냈다. 당일 오전 9시부터 안 쉬고 계속 코딩만 했었기에 상당히 지친 상태였던 기억이 있다.
11/21(월) - Week3 day1
약 30분 정도 자전거를 타면서 힐링했다! 주말에 하루종일 코딩만 했는데 잠깐 정도는 자전거타고 돌아다녀도 괜찮을 거 같다고 생각했다. 그런데 프로젝트 진행도가 너무 느리다고 느껴진다. 중간중간 버그도 너무 많이 생기고 버그 잡느라 원래 책정했던 시간의 2~5배가 그냥 지나가버린다.. 이렇게 해서 우리 프로젝트 완성할 수 있니..? ㅋㅋㅋㅋ 원래 세팅하는 게 오래 걸리는 거지..???
뭘하든 처음이 가장 어려운 거 같다. CI/CD, Docker, HTTPS, 오브젝트 스토리지를 통한 이미지 업로드 등등 내가 맡은 일들이 다 처음이다. 사실 Nest도 처음이라 프로젝트를 정해진 시간 내에 다 만들 수 있을지 걱정이 된다. 그래도 하다보면 익숙해지고 속도도 붙지 않을까?? 내 생에 처음으로 도메인을 구매해봤다! 우리 프로젝트 이름을 딴 moyeomoyeo.com , 내가 낳은 자식같은 느낌이다. 만만하게 봤는데 IP 설정도 쉽지가 않다. 오늘 집가서 다 하고 자야지.. 이제는 야근이 당연한 것처럼 느껴진다. 원래 학습 스프린트 아니 챌린지 때부터 당연했지만
요즘 고민이 많다. 나는 프론트엔드 적성일까, 백엔드 적성일까. 학습 스프린트 때는 프론트 위주로 개발을 해왔었고, 그게 너무 재미있어서 프론트엔드 개발자가 되어야겠다고 생각했다. 그런데 그룹 프로젝트에서는 DevOps와 백엔드 쪽을 깊게 파보니 백엔드에 매료된다.. 면접 준비하려면 어느 하나를 정해야할 것 같은데 어떻게 해야할까.
오늘 일하던 도중에 얘기했던 이미지 업로드 구현에 대한 고민
1. Next 서버에서 스토리지로 이미지를 보내는 방법
- 만약 클라이언트가 하나라면 Next 서버에서 하는 것이 훨씬 효율적이다. 아마 2배 가량 효율적일듯(이미지를 한 번 전송하느냐 2번 전송하느냐의 문제이기 때문에)
2. 클라이언트가 서버를 호출하고 또 서버에서 스토리지를 이미지를 보내는 방법
- 하지만 서버에서 보내는 것이 맞는 거 같다. 왜? 사용자 인증을 해야 한다.
- 만약 클라이언트가 여러 개(앱, 웹 등등)라면 양쪽에서 해당 로직을 다 구현해야하기 때문에 차라리 서버에서 구현하는 것이 훨씬 경제적일 수 있다.
11/22(화) - Week3 day2
어제 오전 1시까지 붙잡고 있던 HTTPS를 출근하자마자 성공시켰다!! 그렇게 꽃길만 펼쳐져 있을 줄 알았는데 프론트 HTTPS 설정때문에 너무 애를 먹었다.. 문제를 꼭 해결해내고 싶다는 생각에 시야가 너무 좁아져 있었다.. 오늘 한 일을 생각하면 삽질만 하고 알맹이는 없다. 약간 자괴감이 든달까… 계속되는 에러로 지쳐있었고, 머리는 완전 과부하 상태였다. 항상 출근하기 전에 생각하는 것이 있다. 문제가 풀리지 않을까 한 걸음 뒤로 물러나 다시 생각해보자. 문제에 매몰되지말자. 하지만 그 원칙이 지켜지는 날은 거의 없는 것 같다. 항상 마음이 급하다. 코드를 차근차근히 뜯어보지 않고 그냥 테스트를 돌려버렸다. 근 일주일동안 workflow run 횟수만 330회가 찍혔다. 그동안의 나를 돌아보면 생각하기 귀찮아했던 것 같다. 매일 그러지 말아야지 생각해놓곤 지켜먹지를 않는다.
오늘 인증서를 너무 많이 발급받는 바람에 오후 6시 HTTPS 설정하는 일을 강제 종료 당했다. Let’s Encrypt가 일주일에 50회까지만 인증서를 발급해준다는 사실을 알고 있었는데도 벌어진 사단이다. 명일이도 스크립트를 보고선 계속 인증서를 재발급받는 거냐고 재확인해줬는데도 별 문제 없겠지라고 생각했다. https 설정이 다 끝나고나면 인증서를 영구적으로 보관하면 되겠지라고 생각했지만… 내 미약한 개발 지식으로 50번 안에 끝낼 수 없었고 결국 이 문제가 터지게 된 것이다. 직접 일을 당하고 나서야 부랴부랴 코드를 수정했다.. 다음날 15시까지 요청 금지를 당해서 꼼짝없이 기다려야만 한다는 사실이 많이 답답했다.
오늘 하루는 실패로 가득한 날.. 실패에서 배우는 교훈은 다행히 많았다. 생각하기, 공부하기, 알고 있는 문제는 사전에 처리하기 등등.. 그래도 단순히 클라우드에 돈을 주고 SSL 인증서를 사는 것이 아니라 직접 인증해 https를 설정하는 프로젝트를 만들고 있기 때문에 여러가지 문제를 만나고 있고 또 이를 통해 배우는 점이 많다고 생각한다.
오늘 nginx를 다뤄보면서 괜히 로드밸런싱을 해보고 싶어 콘테이너를 단순히 여러 개 띄어보자고 했다. 그런데 명일이의 의견을 듣고 놀랐다. 도대체 그게 무슨 소용이 있냐고, 괜히 시간만 사용하고 별의미가 없는 것 같다고 했다. 차라리 무중단 배포를 하거나, 쿠버네티스를 통해 오토 스케일링(사실 이걸 하면 내가 하고 싶은 로드밸런싱을 당연히 할 수 있다.)을 하는 것이 더 의미있지 않겠냐고 했다. 역시 아는 만큼 그리고 고민하는 만큼 보인다고.. 내가 아직 모르는 게 너무 많은 것 같다. 준비되지 않은 개발자인가..?라는 생각이 들면서 존심도 약간 상했지만 내가 부족한 걸 누굴 탓하랴…
위의 내용이 chosimhe 노션 회고록에 거의 그대로 적혀 있다. 이 내용을 읽고 명일이가 마음이 쓰였는데 아래와 같이 댓글을 달아주기도 했다.
11/23(수) - Week3 day3
오늘따라 기운이 쪽 빠졌다. 어제 저녁을 안 먹어서 그런가. 사실 개발이 잘 안 풀려서 그런 것 같다. 자신감이 많이 떨어졌다. 모든 게 다 새로워서 재미있긴한데 속도도 너무 느리고 공부해야할 것도 많다. 요즘 느끼는 게 개발 효율이 진짜 안 좋은 것 같다. 일단 노트북이 너무 느리다. 검색하고 노션에 기록하는 것만 해도 한 세월이 걸린다. 도커를 돌리면 노트북이 안 돌아가서 뭘 할 수가 없다. 도커 빌드하는데 6분 걸리는 건 안 비밀..
오늘 개발을 하는데 되는 게 하나도 없었다. 너무 느려서 뭘 할 수 없었다. 팀원들과 개발 환경이 다른 것도 불편한데, 속도까지 느리다니.. 너무 답답하고 화가 났다. 컴퓨터가 맘대로 안 움직이니 여유가 사라지고 시야가 좁아졌다. 마음만 급해서 어느 순간부터 개발을 하는데 공식 문서를 제대로 읽어볼 생각조차 안 하게 되었다. 악순환의 연속이었다. 이대로 가다간 화병나서 죽을 것 같았다. 그래서 충동적으로 맥북을 질러버렸다. 짠돌이 인생 27년동안 이렇게 하루 만에 결정해서 뭔가를 사본 것이 정말 오랜만이다.
내일부터 맥북을 사용한다는 사실이 기대가 되기도 하지만 개발 환경을 세팅하는 비용도 있고, 사용법이 익숙해지는 데에도 시간이 걸릴 것 같아서 마냥 좋지만은 않다. 빨리 HTTPS도 마무리해야하는데… 인생이 내맘대로 되지가 않는다. 멘토링을 받는 날이었다. 멘토님한테 개발 진척이 느리다는 피드백을 받고 위기감이 느껴졌다. 그런데 위기는 나만 느끼는 것 같ㄷ… 다른 친구들은 자신감이 넘친다. 시간 안에 충분히 할 수 있을 것 같다고 한다. 내가 느려서 그런가. 프로젝트의 완성도를 위해 이것저것 하다보면 시간이 많이 걸릴 것 같은데 아닌가.
11/24(목) - Week3 day4
드디어 맥북 첫 사용! 너무 빠르고 좋다.. 신세계다. 그런데 갑자기 당근해온 모니터가 망가졌다.. 여러가지로 일이 잘 안 풀린다. 이미지 업로드를 드디어 구현하기 시작했다. 다른 사람이 세팅해놓은 환경에서 개발하려고 하니 모든 것이 낯설고, 어려웠다. 그룹 프로젝트도 처음이고, 남이 만들어놓은 코드도 스스로 찾아서 본 게 부캠이 처음이었다. 그러니 어려울 수 밖에… 명일이가 만들어놓은 체계적인 코드를 바탕으로 개발하면서, 그동안 내가 코드를 얼마나 일관성 없고 노답으로 만들어왔는지 알게 되았다. 그룹 프로젝트 끝나고 무조건 해야할 일에 나만의 보일러 플레이트 만들기를 추가했다.
아무래도 모든 것이 낯설다보니 시간도 오래 걸리는 문제도 있지만, 코드의 의도를 완전히 파악하지 못했다는 점이 개발을 진행할 때 가장 어려운 점이었다. 내가 놓친 부분이 있을까봐, 명일이한테 계속해서 질문했는데 그 빈도 너무 많아서 (어느 순간에는 1분마다 질문을 했던 것 같다.) 일에 집중하지 못할 지경이었을 것 같다. 명일이도 답답했는지 (내가 느끼기엔) 점점 퉁명스러워졌던 것 같다.
명일이가 만든 코드를 읽어본다고 읽어봤는데, 모든 부분을 이해하려면 너무 많은 시간이 소요되어 내가 구현해야할 부분을 제때에 만들지 못할까봐 100% 이해하지 못하고 넘긴 부분이 많다. 내가 코드의 이해도가 떨어지는 모습을 보고 스스로 생각하고 노력하지도 않고 질문으로만 해결하려고 하는 걸로 보였을 수도 있을 것 같다. 따지고 보면 맞는 말이다. 필요한 정보를 빠르게 캐치해내지 못했고 코드에 대한 고민이 부족했으며 꼼꼼히 보지도 않았다. 내 문제도 스스로 해결해내지 못하는 짐덩어리였다.
구박(?)을 당하고 나서 생각해봤다. 내가 실력이 부족하고, 고민을 적게 한 게 문제겠거니 하고 넘기려고 했다. 그런데 갑자기 울컥했다. 나도 나름 열심히 해본다고 밤늦게 컴퓨터 앞에 앉아서 기능 개발하고 학습했는데, 내 노력이 아무 소용없는 느낌이었고 쓸모없는 사람처럼 느껴졌다. 너무 억울해서 화가 났고 괜히 명일이한테 화를 내기 시작했다. 대충 내용은 다음과 같다. “아예 모르는 내용인데 어떻게 처음부터 잘 할 수가 있냐, 그래도 너랑 코드 스타일을 최대한 맞추려고, 최대한 이해해보려고 그러는 건데 내가 내맘대로 코드 만들고 내맘대로 PR 날린 것도 아니고..” (미안해 명일…) 거의 2년 만에 화를 냈던 것 같다. 이력서에 적을만한 갈등 상황이 생겼어요!!
일이 있고 나서, 다행히도 마음씨 넓은 명일이가 나를 이해해줬고 평소처럼 대해줬다. 금방 화가 사라지고 부끄럽다는 생각이 들었다. 조금만 차분히 감정을 정리해서 얘기해볼 걸 하고 후회했다. 생각해보면 나도 마찬가지로 점점 퉁명스러워지고 있었던 것 같다. 매일같이 야근해서 몸은 피곤하고 일은 잘 안 풀리지, 학습했는데도 이해는 잘 안되지, 이런 상황이 계속되다보니 내 실력에 화가 났고, 자신감은 떨어졌고 마음에 계속해서 생채기가 났다.
쌓아두지 않고 그냥 얘기해버린 것이 더 나은 선택이었던 것 같다. 그 이후로 서로 말을 조심해서 하게 되었고 이해하려고 노력하게 된 것 같다. 앞으로는 질문을 하기 전에 먼저 생각하고, 정리하자. 생각해보고 혼자 해결할 수 있는 문제라면 너무 조급해하지 말고 조금 더 시간 들여서 공부하고 해결해보자.
오늘은 오후 10시쯤 집에 도착해 30분부터 또다시 chosimhe 친구들과 허들에서 만나 데모 발표 준비를 진행했다. 다들 지친 게 티가 났다. 다들 묵언 수행..
11/25(금) - Week3 day5
모니터가 망가지는 바람에 집에서 모니터 하나를 떼어왔다. 오늘 하필 체크인 대신 설문조사를 해야하는 날이라 모니터를 손에 든 상태로 설문을 적어야했는데 팔이 아팠다. 전철도 중간중간 계속 멈춰서 예정 시간보다 10분 늦게 도착했다. 재수도 없지...
오늘은 특별한 날이었다. 12시부터 조은님과 만나 점심을 먹고 일과를 함께 하며 많은 얘기들을 나눴다. 조은님한테 커피, 붕어빵, 훠궈 등등 이것저것 얻어먹었다. 신도림을 오피스를 같이 사용하는 web20조와 함께 다녔다.
저녁에는 대림에 있는 "중경훠궈"라는 곳에 갔는데 굉장히 맛있었다!! 조은님한테 성장과 취업 개발에 대한 여러 조언을 들어볼 수 있어서 더 뜻깊은 시간이었다!! 부캠끝나고 용산에서 또 만나기로 기약하며 오후 11시에 일정을 마무리했다.
🕺 이번 주의 커뮤니티 행사
호눅스 선생님의 <현업에서 겪을 수 있는 DB 이슈> 특강
역시 유명한 교육자다우셨다! 그동안 들어본 개발 관련 강의 중에 가장 재미있었다. 웃음이 끊이질 않았다. 페르시아의 왕자에서부터 시작해 DBMS에 대한 흥미로운 얘기들, B+ 트리 등등 다양한 정보들을 알아갈 수 있어서 좋았다! 내가 아직 많이 부족하다는 사실도 다시 한 번 생각이 들었다. 가장 인상깊었던 얘기 중 하나! "DB 어디까지 알아야하나요? 라고 물어보면 맨날 몰라도 된다고 하잖아요? 코딩 잘 몰라도 되고, 스프링도 잘 몰라도 되고, DB 잘 몰라도 돼라고 하는 그 기준은 적어도 책 한 권은 달달 외우는 수준은 되야한다는 의미이다. 이 정도가 최소 마지노선이다. 그 이상을 알 필요가 없다는 뜻이다. 오해하지 마세요! 개발자는 인성이 중요하지 이런 얘기 매일하는데 코딩은 당연히 잘 한다는 것을 전제로 하는 말이에요.", "학교에서, 부스트캠프에서 내가 제일 코딩 잘 했는데라고 생각하고 현업에 가면 생각이 달라져요. 나말고 다 잘해.. 이렇게 됩니다. 너무 당연한 거니깐, 너무 겁내지도 자만하지 마시고요. 타인이랑 너무 비교하지 마시고, 작년의 나보다 어제의 나보다 천천히 점진적으로 성장해나가시면 됩니다. 포기하지 않고 멘탈 관리 잘하시면 됩니다."
인상적이었던 내용들
Q. 은행은 꼭 오라클만 써야하나요?
A. 네 맞습니다. 우리나라에서는 돈과 관련된 것은 전부 오라클만 사용합니다. MySQL 쓰자고 하면 책임을 져 줄 사람이 없다. 만약 MySQL 장애로 인해 돈이 1조가 증발한다면 그걸 누가 갚아야할까..? 오라클은 선례가 있다고 한다. 카카오뱅크에서 오라클이 아닌 MySQL을 사용했다고 하는 것은 금융을 제외한 나머지를 얘기하는 것이다. 돈과 관련되지 않은 API에만 사용했을 것이다.
Q. 조인 성능이 별로에요.. 조인 몇 개까지 괜찮은가요?
A. 조인이 많아진다고 너무 걱정하지 않아도 괜찮습니다. 수강신청할 때 조인을 몇 번을 할까요? 금융권에서 DB를 사용하면요? 무려 20~30개의 조인을 합니다. 현업에서는 더 많이도 합니다. 그래도 조인이 하나 생길 때마다 성능이 떨어지는 것은 사실입니다. 물론 역정규화를 통해 성능을 개선할 수도 있습니다.
👨🏫 마스터 클래스
인상적이었던 내용을 위주로!
코드의 복잡도는 어디에서 결정되는가? (조은 님)
1. 의도한대로 동작하는가?
a. 추상화되어있는 코드의 이름만 봐도 이 코드가 어떤 동작을 할 지 기대할 수 가 있는가?
b. 추상화되어있는 함수 또는 메서드의 파라미터가 추상화 단계와 어느정도 일치하는가?
2. 어떤 코드의 동작이 어떤 객체 또는 클래스와 결합되어 있는가?
a. 이 동작이 어느 객체에서만 동작하거나 어느 클래스에서만 동작하는 경우에는 유틸로 분리했을 때 오히려 혼란을 야기
b. 이 동작이 지나치게 General한 경우 하나의 용어로 오히려 더 많은 혼란을 가중
3. 추상화가 얼마나 잘 되어 있는가?
프론트엔드 고민 (조은 님)
1. 어떤 로직을 백엔드에서 관리하고 어떤 로직을 프론트엔드에서 관리할 것인가?
a. 백엔드가 CRUD까지만 만들어줄 수도 있고 데이터 컨버젼, 유효성 검사, 갯수 체크, 포매팅 등을 모두 해줄 수도 있는데 프론트엔드에서 관리해야하는 로직은 어떤 것들이 있는가?
2. 컴포넌트를 어떻게 분리할 것인가?
a. API로 내려주는 데이터가 어떤 형태인지(=== 내가 어떤 컴포넌트에서 어떤 API를 찔러서 데이터를 주고받을 것인지)
b. 개별 컴포넌트가 가지고 있어야하는 상태는 무엇인지
3. 스타일 관리는 어떻게 할 것인가?
a. Styled-Component나 emotion??
b. 어떤 액션에 의해서 UI가 바뀌어야하는 경우, 그 UI가 다른 UI에 영향을 미칠 수 있다.
i. 이런 케이스를 고려해 스타일을 관리해야한다.
c. 레이아웃, 애니메이션, 트랜지션, 트랜스폼을 별도로 관리하면 좋다.
d. 레이아웃에 영향이 없는 것들은 개별 관리하는 게 나을 수 있다.
4. 백엔드 개발자랑 많이 협의하세요.
a. API 형태, 배포 주기, 누가 먼저 배포할 것인지
b. 백엔드에서 가능한 영역이 있고, 프론트에서 가능한 영역이 있다.
c. 협의에 따라서 API 형태, 응답을 어떻게 보낼 것인지에 대한 협의가 가능하다.
d. 협의가 잘 안된다 === 죽음뿐이다.
