얼음꽃의 일지

[항해99 9기] 항해 일지 본문

항해 일지

[항해99 9기] 항해 일지

얼음꽃 2022. 12. 23. 10:16
728x90

2022.09.19 : 항해 시작! + OT

 

항해 스타트를 했습니다! OT를 시작하고 팀원들과 어색어색한 시간을 가졌습니다!

 

프로젝트의 주제를 정하고 그 프로젝트를 관련해서 S.A를 만들었습니다!

 

https://iceflower.tistory.com/27

 

[Chapter 1] 5조 S.A(Starting Assignment)

1. 프로젝트명 타임뮤직 (탐뮤) 2. 소개 그 시절 우리가 좋아했던 음악 음악은 언제나 우리와 함께였지..☆ 지구 뿅뿅 음악실 그 시절 우리가 좋아했던 노래 3. 와이어프레임  3 - 1) 메

iceflower.tistory.com

 

2022.09.20 : 미니 프로젝트 01

 

기본적인 뼈대를 만들고, 회원가입, 로그인, 메인페이지, 댓글 & 좋아요 로 나눠서 시작했습니다.

저는 좋아요 & 댓글을 담당했습니다!! 

 

기본 뼈대 작업은

 

- 회원가입 후 로그인 된 고유 ID 값을 가져와서 그 고유값을 가져온 아이디를 토대로 댓글을 달 수 있도록 함

- 고유 ID 값을 가져온 상태로 내가 좋아요 누른 것과 상대가 누른 좋아요 구분하고 숫자를 올림 ( 싫어요도 포함 )

 

app.py 를 통해서 POST , GET  API를 받고 각 필요한 .html 구성을 Ajax으로 연결입니다!

 

근데 마음처럼 될지 모르겠네요...

 

2022.09.21 : 미니 프로젝트 02

 

기본 뼈대를 잡아놨으나 메인 페이지를 받고 연결을 하려다 코드 자체가 연결이 달라서 연결을 실패하게 되었습니다.

 

그래서 메인페이지를 받은 토대로 다시 연결을 했습니다...

 

새로운 값을 받아서 연결을 했지만 페이지 분리가 안되기때문에 모든 값이 똑같은 페이지에 열리는 상황이 발생했습니다.

 

그래서 댓글, 좋아요 연결하기 전에 다른 페이지 부터 연결을 성공하자라고 생각해서 제가 하고자 하는 부분은 보류를 하고

 

나머지 코드들을 다 합치기 시작했습니다. 이 부분도 확인하는데 오래 걸렸네요.

 

 

2022.09.22 : 미니 프로젝트 마무리

 

메인페이지, 회원가입, 로그인을 모두 연결 한 후 다시 댓글&좋아요를 만들어서 했는데 여전히 페이지가 안되기때문에

 

댓글은 한부분만 받을수 있도록 바꿨습니다. 바꿨지만, 나름 성공적인 프로젝트를 진행했습니다!

 

https://github.com/talli0505/HangHae99_Chapter1_Team5

 

GitHub - talli0505/HangHae99_Chapter1_Team5

Contribute to talli0505/HangHae99_Chapter1_Team5 development by creating an account on GitHub.

github.com

 

https://youtu.be/C4Hyd2ncRRg

2022.09.23 : 새로운 팀과 새로운 주제 시작

풀스택 미니 프로젝트가 끝나고 새로운 팀원과 같이 알고리즘 문제 푸는 주로 시작하였습니다.

 

알고리즘을 풀기 이전에, 자바스크립트를 복습하는 시간을 가지게 되었습니다. 자바스크립트에 기본이 되는 부분과 간단

 

한 문제를 풀어 보는 시간을 가졌습니다. 이론을 새로 확인하고 작성하면서 부족한 부분이 많이 보였고, 더 많이 공부해야

 

겠다는 생각이 들었습니다.

 

https://iceflower.tistory.com/29

 

[항해 99기 9기] 2주차 JavaScrip 과제

JavaScript의 자료형과 JavaScript만의 특성은 무엇일까? 1. 느슨한 타입(loosely typed)의 동적(dynamic) 언어 JavsScript의 변수는 어떤 특정 타입과 연결되어 있지 않습니다. 그 뜻은 변수가 어떤값을 받는 그.

iceflower.tistory.com

 

 

2022.09.24 : 항해를 시작하고 첫 주말!

항해를 시작하고 첫 주말을 맞이했습니다. 

 

이전에는 정말 쉬는 날이어서 쉬어야지 했는데 토요일까지 달리다보니 그냥 평일 처럼 지내게 되었습니다.

 

주말동안 최대한 많은 알고리즘 문제를 풀어보려고 했고, 헷갈리는 부분도 있고 잘 풀리는 부분도 있고, 못 건드는 문제도 

 

있었습니다. 그래도 최대한 풀어보려고 노력하고, 안되면 계속 도전해봤습니다. 이러한 도전을 해본게 몇년많이라 익숙하

 

지는 않지만 최대한 유지해보려 했습니다.

 

문제 푼 곳

 

https://school.programmers.co.kr/

 

프로그래머스

코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요.

programmers.co.kr

 

2022.09.25 : 꿀같은 주말! 그러나..

일요일 정말 쉬자 라는 느낌으로 있었지만, 막상 게더에 출석하는 사람들보고, 아 그럼 나도 공부해야지 라는 기분이 들어서 WIL(Week I Learn)을 작성하면서 푼 알고리즘 문제를 조금 복습했습니다. 그래도 평일처럼 시간에 쫓기는 듯한 느낌보다는 편히 쉬면서 할 수 있었습니다.

 

https://iceflower.tistory.com/30

 

9.19~9.25 WIL

JWT ▶ JWT개념 - JSON Web Token의 줄임말로 , JSON 객체를 사용해 정보를 안정성 있게 전달하는 웹표준 - 세션/쿠키와 함께 모바일, 웹의 인증을 책임지는 대표주자 - 세션/쿠키 방식과 유사하게 사용

iceflower.tistory.com

 

2022.09.26 : 2주차 월요일 시작

금요일부터 주말까지 풀었던 문제를 복습하는 시간을 많이 가졌습니다. 그러면서 다른 분들이 물어보는 질문을 받으면서 코드의 다양성과 코드를 볼때 어느 부분이 문제가 되는지 어느 부분을 바꾸는게 좋을지가 보이게 되었습니다. 그러면서 코드를 파악 하는 부분에 대한 요령도 생겼습니다. 예를 들어서 각각 부분에서 console.log를 찍으면 그 변화를 감지하고 혹시 그 부분에서 문제가 생기면 바로 처리가 가능하기 때문에 코드를 다 썼을때의 오류가 많이 줄었습니다.

 

 

2022.09.27 : 아주 어려웠던 부분

Map이라는 매서드를 안써봐서 제대로 어떻게 돌아가는 몰랐었습니다... 그래서 시행착오를 가지기 위해서 값을 다 집어넣어보면서 까지 확인을 하고, 그래도 이해가 안되어서 기술 매니저님께 질문하게 되었습니다. 역시! 매니저님께 직접 들어보니 이해가 잘 됐고, 잊어버리지 않게 작성을 해두었습니다. ( 일주일 치 적느라 아직 끝나지 않아서 비번걸려있습니다. 10월 2일 끝나면 풀겠습니다. )

 

https://iceflower.tistory.com/31

 

9.26~10.02 WIL

 

iceflower.tistory.com

 

 

2022.09.28 : 화요일날 푼 모의고사 문제 정리

화요일날 알고리즘 모의고사를 풀고 나서 어디가 부족했는지, 틀린 부분이 있었는지 확인하고 풀이하는 시간을 가졌습니다. 그리고 비슷한 문제도 찾아서 풀어보았습니다.  [문제에 대한 출처는 스파르타코딩클럽, 항해99 입니다.]

 

https://iceflower.tistory.com/32

 

[항해9기] 알고리즘 모의고사 문제

[ 이 문제에 대한 출처는 스파르타코딩클럽, 항해99입니다. ] ▶ 숫자 거꾸로 더하기 예를 들어 숫자가 123456 으로 주어졌을때 결과 값은 6+5+4+3+2+1 = 123456의 합 으로 나와야 합니다. function solution(n)

iceflower.tistory.com

 

2022.09.29 : 알고리즘 테스트!

일주일간 공부하고, 문제를 풀었던 알고리즘을 토대로 항해99에서 낸 문제를 푸는 테스트 시간을 가지게 되었습니다.

화요일날 본 모의고사의 시간에 2배인 4시간을 주고 문제를 풀었는데요. 막상 딱 풀기 시작하니깐 머리가 백지가 되면서 어버버하게 되더라구요... 그래서 시간 많으니깐 천천히 풀어보자 해서 푼문제가 3문제중 2개뿐이었네요... 각 문제에 난이도가 적혀있긴했지만 과연 그 난이도가 맞나? 라는 생각이 들긴했습니다. 그게 끝나고 밍글데이라고해서 한 주가 끝난 기쁜 마음으로 팀원들과 게임을 하는 시간을 가졌습니다.

 

 

2022.09.30 : 드디어 주특기 시작

드디어 가장 무섭지만 호기심을 가지는 주특기 시간이 되었습니다. 또 다시 새로운 조원들과 정말 정말 새로운 부분을 배우게 됐는데 어우.. 양이 뭔가 심상치 않았습니다. 기본적으로 JavaScript를 사용하지만, 1주차에 배운 Ajax, API를 좀 더 진화 시킨듯한 느낌이 들더군요.. 제가 잘할수 있을까... 많이 나가떨어진다는데.. 라는 마음을 많이 받았습니다. 그렇지만 으쌰으쌰 한다는 마음으로 조원들과 화이팅하면서 달려보겠습니다.

 

2022.10.01 : 달이 바뀌고... 내 마음도 바뀌고...

달이 딱 바뀌는 시점에 새벽까지 공부를 하다보니.. 와.. 새벽까지 잡고있는데 왜 양이 안줄지..? 라는 느낌을 먼저 받았습니다. 그래도 첫날이지.... 괜찮아 할 수있어! 이런 마음으로 계속 하고있습니다. 1,2주차보다 이 하루가 엄청나게 더 길다고 느껴지더라구요 혹시라도 항해를 하시는 분들은 3주차부터는 마음 단단하게 드셔야 할거 같습니다.

 

2022.10.03 : 3주차 월요일

오늘 개인 과제 만든걸 다 확인 후 배포를 하기 위해서 AWS랑 연결 했습니다. 그런데 AWS 연결에서 계속 연결이 안되어서 와.. 몇번이나 했는지 모르겠습니다.. 이상한 부분 계속 에러나서 4시간동안 잡았나... 여러번 하다보니 순서까지 외워버렸습니다.

 

순서

1. git bash 들어가서 ssh -i AWS키 ubuntu@공개ip주소

2. 연결 후에 git clone 깃허브 주소

3. cd로 app.js까지 가서 npm install

4. sudo -s가서 npm pm2 설치

5. 그리고 pm2이용해서 계속 열고

 

손이 자동적으로 움직이더라구요... 이게 진짜 직접 막 틀리고, 오류나니깐 오히려 더 찾게되니, 더 공부하게 되더라구요...

 

2022.10.04~10.05 : 질문 무한리필

화,수는 개인과제 마무리가 다가와서 많은 분들에게 질문이 들어왔습니다. 알고리즘때도 느꼈지만, 질문이 들어와서 저와 다른 방식 혹은 같은 방식인데 어디가 잘못됐는지를 확인하면 시야가 넓어지면서 금방 금방 코드에 잘못된 부분을 확인하게 되더라구요... 나중에 혹시 항해를 하시는 경우라면 진짜 서로 도와가면서 질문 받거나 혹은 하면서 했으면 좋겠습니다.

 

2022.10.06 : 주특기 입문 시험

첫 주특기의 입문 시험을 치르는 날이었습니다. 많은 연습을 했지만 그래도 불안한 마음이 들더라구요. 열심히 했으니 괜찮겠지하고 문제를 봤는데, 그렇게 어렵지는 않아서 다행이었습니다. 문제를 풀고 나오면서 사람들에 물어봤는데 열심히 해서 그런지 오히려 쉬웠다는 느낌을 많이 받았다고 하네요. 딱 시험끝나고 나서는 이제 다음 발제는 뭐일까 점점 다가오는 그 기분이 무서우면서 묘하더라구요.. 숙련때는 잘해야지... 잘해야지.. 하지만 과연 잘할수 있을까 라는 의문을 가지게 되지만, 매니저님들께서 말씀하셨습니다. 과거의 너보다 잘하고 있으니깐 앞으로 더 열심히만 하면 된다구요!

 

2022.10.07 : 4주차 주특기 숙련 시작!

주특기 입문이 끝나고 숙련이 시작되었습니다. 역시 예상한거처럼 양이 엄청나더라구요... 새로운 걸 배운다는 기대감도 있지만, 내가 이번것도 잘 할 수 있을까 라는 두려움도 섞여있었습니다. 그래도 이왕 해야하는거면 재밌고 즐겁게 하자라는 마음으로 시작했습니다! 입문에서 했던거에 추가적인 내용이 들어갔지만, 사용하는 프로그램이 변하면서 쉬워지면서도 어려워지는 느낌이 있었습니다.

 

2022.10.08 : 4주차 주말시작

토요일이 되었지만, 이제 4주차 정도 되니 토요일 휴일이 아니라 그냥 평일 같아요... 몸이 익숙해져서 괜찮긴 하지만 빨리 끝나고 주말이 다시 돌아왔으면 하는 마음이 점점 더 생깁니다. 내용이 조금 헷갈리기때문에 새롭게 배운 내용을 정리해서 블로그에 작성해서 나중에 헷갈리지 않도록 해야겠습니다.

 

2022.10.10 : 처음보는 프로그램들...

이번 숙련 내용에서는 JWT 연결 및 몽구스 사용했던 것을 SQL로 바꾸는 작업에 기본 게시글 및 댓글 작업에 좋아요까지 하는 걸 구현하는 주가 되었습니다. JWT와 쿠키, 세션부터 시작해서 지금까지 몽구스를 썼다가 SQL로 갑자기 바꾸려고 하니 너무 어려웠습니다. 그래서 SQL로 작업하기 이전에 몽구스로 먼저 작업을 해보자 해서 작업을 해봤습니다.

 

2022.10.11 : 몽구스로 작업 완료

몽구스로 좋아요까지 작업을 다 완료한 후 이제 SQL로 바꾸려고했는데, 몽구스에서는 필요한 schema가 있으면 바로바로 추가도 가능하고 인식도 바로 되지만, SQL은 한번이라도 틀리면 표를 삭제하고 그다음에 표를 다시 생성하는 작업을 추가로 진행해야했습니다. 그래서 처음에 ERD Diagram을 제대로 짜놓지 않으면 엄청나게 고생길을 걷는 길이 될거 같았습니다. 그래서 최대한 ERD Diagram을 잘 짜려고 노력했습니다.

 

https://drawsql.app/teams/blog-2/diagrams/blog/embed

 

https://drawsql.app/teams/blog-2/diagrams/blog/embed

 

drawsql.app

 

2022.10.12 : SQL로 작업 완료

ERD를 토대로 SQL로 바꿔서 새로운 문법을 통해 작성하기 시작했습니다. 어우... 근데 막상 사용해보니, 문법이 비슷하면서 다르고, ERD를 열심히 짰지만, 조금씩 다른 부분이 있어서 또 추가했다가, 삭제했다가 반복작업을 많이 했습니다. 그래도 열심히 해서 완성을 했습니다.

 

https://iceflower.tistory.com/36

 

게시글, 댓글, 좋아요 형태 만들기

이 글은 Mongoose가 아닌 mySQL 로 작업을 했으므로 이 점 미리 알고 계시기 바랍니다. 밑에 링크는 ERD Diagram을 보기 쉽게 만들었습니다. https://drawsql.app/teams/blog-2/diagrams/blog/embed https://draws..

iceflower.tistory.com

 

2022.10.13 : 숙력주차 테스트

목요일은 거의 항상 테스트를 보는 날이어서 이 날도 테스트를 보게 되었습니다. 지금 배운걸 토대로 얼마나 잘 이해하고 있는지를 확인하는 부분인데 시험을 보면서 아직도 난 많이 부족하구나... 열심히 해야겠구나 하는 마음이 많이 들었습니다. 문제를 풀다가도 막히는 부분이 많이 있었고, 최대한 시간을 활용해서 최선을 다했지만.. 끝나고 나서 여전히 찝찝한 마음이 있었습니다. 그 이후에는 저녁에 그 테스트 관련 해설이 있어서 열심히 들었습니다.

 

2022.10.14 : 5주차 심화주차 시작

이제 기초, 숙련 주차를 보내고 나서, 이제 주특기 마지막 주차인 심화과정에 들어서게 되었습니다. 심화과정에서는 개인 과제로 하는게 아닌 팀 과제로 하게 되었습니다. 다음주 부터이제 협업이 있기때문에 그 부분을 위해서 미리 준비하려고 심심화 주차에 팀 과제를 하도록 한게 아닌가라는 생각이 들었습니다. 또 새로운 내용들이 많이 나와서 엄청나게 어려워 보였지만, 최대한 달렸습니다.

 

2022.10.15 : 5주차 주말

5주차 내용을 들여다보면서 어우... 왜이렇게 내용이 어렵나.. 라는 생각과 약간 부실한 내용이 많이 보였습니다.. 이전에도 계속 구글링하면서 찾아보긴 했지만 이번에는 많이 힘들었습니다... 그래도 주말동안 시간이 있으니 차근차근 봤습니다.

 

 

2022.10.16 : 새로운 내용 Layered Architecture 및 테스트 코드

처음 보는 애들이 또 등장했습니다. 한 주 한주 지나면서 새로운 내용들이 나오니 배우면서 너무너무 새롭습니다!!! 제 두뇌 또한 백지가 되는 느낌이네요... 그래도 계속해서 꾸역꾸역 넣으려고 노력을 했습니다. 근데 어우.. 너무 새로워서 코딩을 하다가 delete버튼을 누르게 되는 느낌이 계속 들더라구요 제 코드에 대한 확신이 없어서... 

 

2022.10.17 : 필요한 내용들 완성

일단 기본적으로 저번주에서 배운 내용을 3계층 아키텍처로 나누어서 작업을 하여 좀 더 가독성을 좋게 만들어서 하는 부분이었는데 객체지향 부분도 오랜만에 사용해보고, controller & service & repository를 나누면서 계속 파일을 왔다갔다하면서 보게 되니깐 어지러웠습니다. 그래도 이전에 배운 게시글 CRUD, 댓글 CRUD, 좋아요를 다 분리를 """잘"""" 시키면 되는거라 엄청난 시간을 소비하지는 않았습니다. 이제 그 나눈 부분에서 연결를 잘 해서 되는지도 체크해 봐야겠습니다..

 

2022.10.18 : 내용들 추가

기본적인 틀에 따른 코딩을 완료했으나 나중에 협업을 하게 될때 필요한 암호화 및 프론트가 백엔드가 사용한 코딩을 어떻게 잘 돌아가는지 보여주는 Swagger를 작업을 해보려고 공부를 하였습니다. 먼저 암호화를 하였는데, 원래 데이터베이스 상에서 비번을 보여주거나 혹은 암호화가 안된 상태로 가지고 있으면 그것도 불법이 될 수 있고, 그 상태로 해킹이라도 당하게 되면 엄청난 문제가 생기기 때문에, 암호화를 Crypto로 진행을 하게 되었습니다.

 

https://nodejs.org/api/crypto.html

 

Crypto | Node.js v19.0.0 Documentation

 

nodejs.org

 

https://zinirun.github.io/2020/12/02/node-crypto-password/

 

Node.js - 바람직한 비밀번호 암호화 (crypto) | zinirun

비밀번호를 있는 그대로 데이터베이스에 저장하는 개발자는 테러리스트와 같다. 로컬 환경에서 테스트할 목적이라면 모르겠지만, 외부에 배포되는 순간 회원가입 로직이 있다면 무조건 암호화

zinirun.github.io

 

2022.10.19 : 내용들 추가2

이제 암호화 작업을 끝내고, Swagger 작업을 들어갔습니다. Swagger에는 두 종류가 있는데 처음부터 끝까지 생으로 코딩을 하거나 아니면 오토를 이용해서 기본 틀을 만들고 그 안에만 채워지는 방법이 있었습니다. 저는 이번에 처음이기 때문에 기본저인 틀이 있는 상태에서 시작을 해보았습니다. 

 

https://swagger.io/specification/

 

OpenAPI Specification - Version 3.0.3 | Swagger

OpenAPI Specification Version 3.0.3 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RF

swagger.io

https://llshl.tistory.com/m/49

 

[NodeJS] Swagger 자동 생성 라이브러리 swagger-autogen

또또 너무 오랜만에 글을 쓴다. 퇴근하면 왤케 피곤한걸까. 기존에 사용하던 stoplight에서 swagger로 전환하는 작업을 했다. 왜? 코드 안에서 바로 수정할 수 있기에 더 간편해서. 근데 한땀한땀 핸

llshl.tistory.com

 

2022.10.20 : 주특기 심화 마무리 단계

swagger 내용을 토대로 드디어 주특기 심화를 마무리 하게되었습니다. 심화과정때는 이제 백엔드끼리만 협업을 했다면, 이번에는 프론트랑도 같이 협업을 시작하게됩니다. 내일부터 당장 미니 프로젝트를 들어가는데 설렘반, 무서움반이 있는거 같습니다. 백엔드와 하는 협업을 제외하고 프론트랑 하는건 잘 할 수 있을지, 혹은 소통이 잘 될지 그런 부분에서 생각이 많이 들었지만, 부딪히지 않으면 알 수 없기에 그냥 부딪혀 보기로 했습니다.

 

2022.10.21 : 미니프로젝트 시작

미니프로젝트 발제가 시작 되었고, 새로운 팀도 정해졌습니다. 역시 어색함이 있었고, 주제를 정하는 부분도 매우 어려움이 있었습니다. 진짜 어떤걸 하더라도 스타트를 잡는게 가장 힘들다고 느꼈집니다. 이런 저런 얘기를 하다가 오류 코드 관련해서 공유하고자 하는 웹사이트를 만들게 되었습니다. API 설계 및 와이어 프레임을 작성 후, 각자가 맡은 파트를 시작했습니다. 저는 게시글 쪽 담당이라 그 부분을 만들었습니다.

 

2022.10.22 : 미니프로젝트 시작된 주말

이게 항해를 하다보면 금, 토가 가장 힘든 날입니다. 그 전까지 발표를 위해서 엄청나게 달려오다가 금요일 발제 받으면, 그때 힘이 빠지고, 토요일날 에너지를 좀 충전을하고 일요일 저녁부터 달리는 느낌입니다. 저도 많이 지쳐서 금요일은 회의를 한 후 조금씩 하다가 토요일 저녁부터 맡은 부분을 달린듯한 느낌이 들었습니다. 백엔드는 보통 추가작업이 없으면 CRUD가 대부분이라 큰게 어려움이 없었고, 프론트 분들이 가장 할 일이 많아 보였습니다.

 

2022.10.24~26 : 미니프로젝트 중간 단계

이제 프론트 분들의 틀이 어느정도 잡히고 백엔드는 서버 연결을 하는데 오류가 펑! 나기 시작했습니다. 처음 시작된 오류는 CORS 부분이었고 이 부분을 풀어주니 프론트쪽에서 잘 받기는 했으나 가끔 url이 인식되지 않는 문제가 생겼습니다. 알고보니 직접 받거나 혹은 .env를 사용할때 약간의 문제였더라구요.. 그 이후로는 순조롭게 가다가 필요한 수정 및 오류가 있었으면 바꿔주었습니다.

 

2022.10.27 : 미니 프로젝트 마무리 단계

드디어 미니 프로젝트 마무리 단계까지 왔습니다. 팀원들과 처음 협업에서 그래도 성공적으로 마무리 할 수 있었다는 마음이 가장 컸습니다.  이번 협업에서 느꼈는데 진짜 남한테 피해를 주지 않으려면 열심히 해야한다는 느낌이 매우매우 컸습니다. 프론트 분들을 보면서 와 정말 앞에 보여주는 부분을 만드는데 시간이 엄청 걸리는 구나.. 라는 생각이 많이 들었습니다.

 

https://youtu.be/84J1rsEbkOc

 

https://github.com/talli0505/6week_mini_back

 

GitHub - talli0505/6week_mini_back

Contribute to talli0505/6week_mini_back development by creating an account on GitHub.

github.com

 

2022.10.28 : 클론 프로젝트 시작

실전 하기전 마지막 프로젝트인 클론이 시작되었습니다. 각 조 별로 클론 하고자 하는 웹사이트를 생각해서 하게 되었는데 제가 있는 조에서는 "정육각"이라는 고기 웹사이트를 하기로 했습니다. 이전 기수들이 한거 보면 대체로 인스타그램, 트위터, 틴더, 당근 마켓등 비슷한 것들이 많아서 조금 색다른 걸 해보자 해서 이 웹사이트를 고르게 되었습니다. 프론트와 백이 각자 무엇을 할지 나누는 시간을 가지게 되었습니다. 

 

2022.10.31 : 클론 프로젝트 진행

제가 맡은 부분은 회원가입, 로그인 관련 부분이었습니다. 기본적인 회원가입, 로그인 형태는 비슷해서 괜찮았는데 새로운 도전인 refresh token을 해보기위해 여러 자료들을 찾아보았습니다. 

 

기본적으로 access token은 사용자가 웹사이트를 로그인 할때 주어지는 토큰인데 이  access token의 만료 시간이 길게 되면 나쁜 사람이 token자체를 탈취 했을때, 그 남은 시간동안은 무엇이든 할 수 있게 됩니다. 따라서 그것을 방지하고자 refresh token이라는 개념을 도입하여 access token 시간을 매우 짧게 만들고 만료가 되면 refresh token이 존재하는 기간 동안에는 계속 해서 새로운 access token을 전달해주게 됩니다. 이렇게 되면 access token 만료 시간이 짧아서 탈취 당했을때의 문제를 보안 할 수 있고 refresh token은 따로 저장하기 때문에 보안적인 문제도 없앨 수 있습니다. ( 물론 refresh token을 뺏기면 아주 큰일이 나긴 합니다... ) 이 내용을 가지고 코딩에 대입해보려고 했으나 처음 써보는 내용이라 조금 어려웠습니다.

 

2022.11.01 : access, refresh 완료

시간을 써가면서 성공적으로 완료했습니다. 대신 프론트 부분에서 어떻게 받는지 연결을 시켰는지 잘 몰라서 멍한 눈으로 쳐다보고 있었습니다..  response 받는 부분은 보이게끔 했는데 그 이후에 소식이 끊겨 버렸습니다.. 나중에 로그인 시 잘 돌아가는건 확인했는데 만료 뒤에 새롭게 받는걸 못봤네요... ㅜㅜ

 

 

2022.11.02~03 : 클론 프로젝트 마무리 및 회고발표

모든걸 연결 잘 하고 마무리 잘 짓고 회고 발표를 하게되었습니다. 회고 발표때도 만족스럽게 말씀해주셔서 좋았습니다. 

 

https://youtu.be/Zn_fDpCPy6s

 

 

 

https://github.com/talli0505/7week_Clone_coding_back

 

GitHub - talli0505/7week_Clone_coding_back: meatmania

meatmania. Contribute to talli0505/7week_Clone_coding_back development by creating an account on GitHub.

github.com

 

2022.11.04 : 대망의 실전 프로젝트 시작

이제 항해99 마지막인 실전 프로젝트를 시작했습니다. 6주간 함께할 사람들과 같이 주제를 정했습니다. 진짜 언제나 생각이 드는 부분이지만, 코드를 짜는 것보다 주제를 정하는게 가장 어렵다고 느껴졌습니다. 그래도 참신한 주제를 발견해서 재밌는 6주가 될 듯 합니다. 주제는 보드게임카페를 골라서 모르는 사람들과 매칭이 되어 같이 가서 즐기는 것입니다. 이 주제를 가지고 얼마나 잘 될지는 모르겠지만 최대한 노력해보려고 합니다.

 

2022.11.07 : 실전 프로젝트 베이스 만들기

기본 베이스를 잡고 시작을 했습니다. 저는 회원가입/로그인 부분을 맡아서 했기에 CRUD 작업 및 암호화를 진행하였습니다. 기본 베이스는 이전껄 그대로 사용이 가능했으나 회원가입 시 필요한 사전 정보가 많고, 암호화도 crypto에서 bycrpt로 변경 시키면서 좀 더 보안을 강화 했습니다. 그 이후에는 프론트와 얘기를 하면서 수정할 부분을 수정하였습니다.

 

2022.11.08~11:11 : 실전 프로젝트 메인

CRUD를 수시로 확인해가면서 수정할 부분을 수정하고 소켓 I.O에 대한 공부를 시작했습니다.

 

HTTP 가 있기전에는 터미널 창에서 사용하다 HTTP가 등장하고 시각적이고, 정보량으로 엄청난 내용들을 주고 받을 수 있게되었습니다. 그대신 HTTP는 사용자가 URL요청시에만 그 페이지를 꺼내줄수있습니다.

 

이 뜻은 무조건 창을 열려면 요청이 필요하게 됩니다. 이걸 보안하고자 서버와 통신을 AJAX가 나오게 되었고 이걸 사용하게 되면서 웹페이지 -> 웹페이지 이동방식이 아닌 동일한 웹페이지 내에서 DOM을 바꾸는 형식으로 바뀌게 되었습니다.

 

그런데 AJAX도 HTTP로 서버와 통신하는 것이기때문에 클라이언트의 요청이 있고 그 다음 서버로부터 음답을 받는 이 한계를 벗어나지 못했습니다. 그래서 상호작용이 쉽게 돌아 갈 수 있는 폴링 방식을 찾게되었고, HTML5 개발 과정에 들어간 것이 WebSocket 방식입니다. 

 

웹 소켓은 브라우저와 서버 사이의 양방향 연결 채널을 구성해주는 것인데 이게 있으면 하나의 HTTP 에서도 양방향이 가능해집니다. 그 대신 웹 소켓은 HTML5 기술 이기 때문에 옛날 웹브라우저에서는 웹소켓을 지원하지 않습니다. 따라서 이 결 해결하기 위해서 만든게 Socket.io이고 이 Socket.io를 가지고 거의 모든 웹, 앱 에서 실시간 소통이 가능하기때문에 사용이 용이 합니다.

 

Socket.io는 클라이언트에서 발생하는 이벤트의 명을 자유자재로 정할 수 있고, 귓속말, 쪽지, 채팅 등등 전체 혹은 특정 사람한테만 메세지를 송신하는 방식 등 여러가지가 가능해집니다. 

 

1. io.emit : 접속된 모든 클라이언트에게 메세지 전송

2. socket.emit : 메시지를 전송한 클라이언트에게만 메시지 전송

3. socket.broadcast.emit : 메세지를 전송하는 클라리언트 제외하고 나머지에게 메시지 전송

4. io.on : 연결이 됐는지 안됐는지 실행

5. socket.on : 클라이언트에서 지정한 이벤트가 emit되면 수신 실행

6. 프론트쪽에서는 <script src = "/socket.io/socket.io.js"></script> 해서 사용할 수 있게함

 

2022.11.14~11:15 : 소켓 진행하다 생긴 문제...

프론트 분과 기본적으로 소켓을 연결을 했습니다. polling 방식 (한번씩 주고 받는 형식) 으로 했을때 1대1 채팅은 정상적으로 진행되는 것 처럼 보였으나.... 프론트 console에서는 WebSocket connection failed 형식이 계속 뜨게 되었습니다. 이게 websocket이 기본적으로 연결되었다고 생각했으나 그게 아니었습니다. 계속 연결 차제가 끊겼다가 붙었다가 끊겼다가 붙었다가 하는 형식이 생기게 되었고, 이게 해결이 안되면서 join하고 메세지를 보내는 순간 속도가 엄청나게 느리게 되었습니다.

 

그래서 여러가지 내용을 찾아본 결과 socket.io 공식 사이트에 올라온 내용을 보게 되면

 

https://socket.io/docs/v4/using-multiple-nodes/

 

Using multiple nodes | Socket.IO

When deploying multiple Socket.IO servers, there are two things to take care of:

socket.io

고정  세션을 활성화 시키지 않으면 세션이 알수없는 상황이 생기고 활성화가 되어있어야 socket 세션의 수명 동안 여러 http 요청을 보내는게 가능해 집니다.

 

그래서 nginx 기본 구성 요소를 socket.io에 맞춰서 바꿔주니 뜨던 에러가 사라지게 되었고, 채팅과 join자체도 끊김 없이 잘 진행이 되었습니다.

 

* 참고로 저는 http 형식은 nginx 서버를 켤때 계속 오류가 났기 때문에 server 부분만 썼습니다.

 

2022.11.16 : 이상하다.. 분명 해결된거라 생각했는데....

어제까지는 join 및 채팅이 되던 부분은 잘 진행이 되었으나... 한사람, 혹은 많은 사람이 동시에 막 채팅을 올리거나 혹은 도배를 하게 되면 백 서버가 살아있어도 프론트와 연결이 끊겼다가 진정이 되면 다시 붙는 현상이 생겼습니다. 이게 도배를 하더라도 몇십개는 버틸줄 알았지만, 13~14개 넘어가는 순간 엄청나게 끊기게 되었습니다.

 

보통 Nginx를 보통 사용한 이유가 도메인을 연결하고 cerbot을 깔아서 단순히 https 형태로 바꿔주기 위한 작업이라고만 생각했었는데 이번 socket.io를 하면서 Nginx를 더 들여다 보게 되었습니다.

 

https://brunch.co.kr/@alden/11

 

nginx upstream 성능 최적화

Linux Performance | Java, Ruby 등 다양한 언어를 이용해서 서비스를 개발할 때 보통 Framework를 많이 활용하게 됩니다. Play , RoR, Spring 등등 언어 별로 지원되는 다양한 Framework들이 있죠. 이런 Framework 들을

brunch.co.kr

 

https://hodolman.com/16

 

Nginx에서 upstream서버 keealive 설정

Nginx upstream 웹 애플리케이션 서버를 (Spring, flask..) Container 자체적으로 실행하는 경우는 거의 없고 대부분 nginx에서 proxy 하는 경우가 많다. 이렇게 하면 ssl, auth, cache 등의 요구사항을 쉽게 적용,

hodolman.com

 

2022.11.18~20 : 소셜로그인 작업

이전까지는 해왔던 부분이 프론트에서 다 해결하거나 혹은 백에서 다 해결하는 형식의 소셜로그인 작업을 해왔었는데요 이번에는 프론트와 백과 같이 연결 하는 방법을 사용하여 연결을 했습니다. 기본적으로 passport 모듈을 사용하게 되면 프론트와 백의 코드가 한 곳에 같이 있지 않으면 redirect가 불가능하여 passport를 사용하지 않고 정석적인 방법으로 하게 되었습니다. 

 

정석적인 방법은 다음과 비슷하다고 봅니다.

 

1. 프론트에서 카카오에게 인가코드 요청

2. 받은 인가코드를 백에게 전송

3. 백은 그 인가코드를 카카오에게 보내어 토큰 요청

4. 토큰을 가지고 정보요청

5. 필요한 정보만 받아서 그걸 토큰으로 변환

6. 변환된 토큰을 프론트에게 전달

7. 프론트는 그 토큰을 받아서 이용

 

이 형식을 이용해서 소셜로그인을 구현했습니다. 참고자료는 다음과 같습니다.

 

https://han-py.tistory.com/417

 

[React/Nodejs] 카카오 로그인 연결하기

카카오 로그인을 진행해 보자. 기본적인 작동 방식은 여기를 눌러서 확인하자. 기본 셋팅은 할수 있다 판단하고 글을 적어보겠다. 사실 쉽게 사용하기 위해 만들어진 라이브러리도 많다. 그러나

han-py.tistory.com

 

 

2022.11.21~22 : 코드 잔 작업

소셜 로그인이 연결되는거를 확인을 했으니 이제 소셜 로그인 진행시 받아오는 유저정보 + 로그인과 동시에 회원가입이 진행 되도록 설정되었을때 받아오는 값들을 DB에 저장이 되도록 하였고 랭킹 시스템을 준비하기 위한 point 및 totalPoint 작업을 하였습니다. 그리고 필요없다고 생각되는 부분들을 지우고 코드 단순화 작업을 조금 진행하였습니다. 코드가 점점 늘어다나보니깐 보는대 조금 힘들고, 어? 이거 필요없겠는데 하는 부분도 많이 생겼기에 그러한 부분도 잘 처리해줘야 할것 같아서 해줬습니다.

 

 

2022.11.23~24 : sms 인증 작업

회원가입, 아이디 찾기, 비밀번호 변경 시 단순히 로그인하는 것 보다는 sms 인증을 통하여 하는게 좋을거 같고 혹시나 다른 문제 생길시에 그 번호로 전체 메시지 및 문제 사항을 보낼 수 있기 때문에 전화번호를 받아 사용하는게 좋을거 같아 적용시켰습니다. 여러가지 방법을 찾아봤다가 네이버 센스를 이용하는게 가장 효율적인거 같아 이걸 이용하게 되었습니다. 

인증 관련해서 다음 링크를 참고했습니다.

 

https://well-made-codestory.tistory.com/25

 

[Cloud] SENS Service를 이용한 문자 인증 API 구현하기

[Naver Cloud] SENS Service를 이용한 문자 인증 API 구현 개요 Naver Cloud의 서비스 중 하나인 SENS(Simple & Easy Notification Service)를 이용하여 문자 인증 API를 구현한다. 목차 NAVER CLOUD PLATFORM 회원가입 및 기본

well-made-codestory.tistory.com

 

https://g-song-ii.tistory.com/3

 

네이버 SENS API와 Node.js로 휴대전화 SMS 인증하기

안드로이드에서 받아온 유저의 휴대폰 번호를 Node.js 서버로 넘겨 네이버 SENS API로 인증 문자를 보내려고 합니다. 먼저 제가 현재 졸업작품으로 개발 중인 프로젝트는 이더리움 블록체인을 이용

g-song-ii.tistory.com

 

2022.11.25 : 중간발표회

드디어 3주간 얼마나 진행됐는지 확인하기 위한 중간발표회가 있었습니다. 정말로 두려움이 90% 긴장이 10%로 였던거 같습니다. 얼마나 질문을 받고, 얼마나 타격을 받을지 처음이어서 가늠이 안되더군요.... 다른 조가 하고 있을때는 질문들을 들어보면서.. 와.. 이거 압박 면접이다.. 대답못하면 큰일난다.. 죽었다...이런 느낌을 가지게 되었고 저희 조 차례가 되었을때는... 멘붕이 심하게 왔습니다... 사전 질문받은것도 힘겹게 찾았었는데 갑잡스런 부분에서 질문이 날라오지 미칠거같았습니다. 질문 내용은 상상에 맡기도록 하겠습니다.

 

로고

 

다음 그림은 중간 발표회 까지 사용했던 아키텍처를 나타낸 부분입니다.

mongoose, mongodb : 저장소 역할
amazon ec2 : 서버
node express : 사용하는 모듈

jwt : 토큰 생성

pm2 : 오류 생겨도 서버 안꺼지도록 해주는 project manager

nginx : 동시접속 처리를 위한 프로그램

bcrypt : 암호화

certbot : http에 보안을 씌워서 https 변경

socket.io : 채팅에 사용하기 위한 프로그램

sens : sms 인증

social login : passport가 아닌 정석 방법 이용한 것

 

2022.11.28 : 내용 정리 1

코딩을 하다가 아직 기본적인 개면에 대해서 많이 부족한거 같아 정리하기 시작했습니다. 물론 오류를 계속 수정하면서 말이죠. 일단 가장 기본적인 DB 자체를 구분짓는 요소 부터 파악해보기로 했습니다. 

 

https://iceflower.tistory.com/43

 

RDMS 와 NoSQL은 무엇인가?

NoSQL : No + SQL 이 아니라 Not Only SQL 이라는 뜻으로 SQL뿐만 아니라 라는 의미가 있습니다. 즉, SQL 뿐만 아니라 다른 데이터베이스도 존재한다라는 뜻입니다. SQL(관계형 데이터베이스)은 대표적으로

iceflower.tistory.com

 

2022.11.29 : 내용 정리 2

DB를 정리하다보니 DB안에서의 트랜잭션이 조금 궁금해지더라구요. 그래서 그 부분에 대하여 조금 공부를 해봤습니다.

 

https://iceflower.tistory.com/44

 

[DB] 트랜잭션의 ACID

트랜잭션 : 여러 개의 작업을 하나로 묶은 실행하는 것입니다. 좀 더 자세히 말하자면 데이터베이스에서 트랙재션은 데이터베이스 관리 시스템 또는 유사한 시스템에서 상호작용의 단위입니다.

iceflower.tistory.com

 

2022.11.30 : access token refresh token 해결

이전에 사용한 방법으로 access token이 만료가 되면 DB에서 refresh token을 찾아서 있으면 자동적으로 access token을 다시 주는 방식으로 했습니다. 그런데 이렇게 하다보니 치명적이 오류가 하나 있었습니다. 만약 access token 자체가 탈취가 되는 경우라면 단순히 만료된 access token으로 요청을 해서 계속 해서 새로운 token을 받을수 있었습니다. 

 

이 부분에 대한 해결법으로는 로그인시 프론트에게 access, refresh token을 다 넘겨주고 나서 access 토큰이 만료가 됐을경우 프론트 쪽에서 access token을 백으로 보내주어 그게 가지고있는 것과 같은지 체크를 하고 난 후에 access token을 넘겨주는 방식을 이용했습니다. 이렇게 하면 refresh 까지 탈취가 되어서야 확인할 수 있습니다. 그러나 access, refresh 토큰은 둘다 탈취 가능성이 생긴 것이기 때문에 httponly나 다른 곳에 숨겨서 탈취가 안당하게끔 해놔야합니다.

 

2022.12.01 : 내용정리 3

코드를 기본적으로 계층형 형태로 하여 역할을 나누어 코드를 쉽게 쉽게 변경 할 수 있도록 해놓았습니다. 항해에서 배운걸 토대로 만들었는데 잘 모르고 사용하는거 같아 다시한번 정리하게 되었습니다. 

 

https://iceflower.tistory.com/45

 

계층형 아키텍처 패턴

아키텍처 패턴이란? - 소프트웨어의 구조를 구성하기 위한 가장 기본적인 토대를 제시 - 각각의 시스템들과 그 역할이 정의되어 있고, 여러 시스템 상이의 관계와 규칙 등이 포함되어 있음 - 검

iceflower.tistory.com

 

2022.12.02 : 런칭하기전 코드 정리

4주차 멘토링 하기전 처리해야할 부수적인 기능 및 오류를 최대한 처리하고 모르는 부분을 따로 정리를 해두려고 했습니다. 그러다가 token문제를 해결하고 sms인증에서 똑같은 인증코드로만 계속 와서 무슨 문제인지 이걸처리하느라 시간이 오래걸렸지만, 여전히 처리를 못했습니다. 그래서 멘토링을 통해 질문을 하고 처리를 해볼 예정입니다. 그 이외에는 부수적인 부분으로 프론트와 맞혀서 처리를 하였습니다.

 

2022.12.05 : 런칭 전 수정해야되는 부분이 더 보이는 문제...

원래라면 오늘 런칭을 해야하는 부분이지만 어째서인지 런칭하기 직전에 꼭 수정할 부분이 더 보이게 되었습니다. 갑자기 게시물이 안보이거나, 검색 및 필터링에 잔 오류가 생기거나 받아와지는 값이 조금 문제 있거나 이런거여서 그걸 최대한 해결하는데 시간을 사용하게 되었습니다. 그래도 해결된 부분이 많아서 다행이라고 봅니다.

 

조금씩 내용 정리하던 게시물 중 하나입니다.

 

https://iceflower.tistory.com/46

 

PM2

서버를 돌리다보면 이런 생각 듭니다. 개발중에서는 로컬을 켜서 돌려가지고 오류 생겨서 멈추면 오류 확인하고 고치고 다시 돌려보고 할 수 있지만, 다 만들고 배포를 하게되면 그때는 오류로

iceflower.tistory.com

 

2022.12.06 : 드디어 런칭

런칭을 시작하게되었습니다. 런칭을 하면서 피드백도 계속 받고 있는 상태인데 역시 만드는 입장과 사용해보는 입장의 차이는 큰거 같다고 봅니다. 사람들이 사용할때마다 오류가 어디서 나오고 상상도 못한 부분에서 문제가 생기는 경우도 있었습니다. 확실히 직접 겪어보니 아.. 프론트나 백이나 그 사이트혹은 앱을 만들었을때 이런일 발생하면 멘붕오거나 힘들겠다라는 생각을 많이하게 되었습니다. 그래도 이렇게 피드백을 받으면서 점점 코드를 고쳐가니 이렇게하면 좋은 방식이 되겠구나 이 부분은 하면 안되겠구나 라는부분도 많이 느꼈습니다.

 

조금씩 내용 정리하던 게시물 중 하나입니다.

 

https://iceflower.tistory.com/47

 

WebSocket 과 Socket.io

WebSocket 과 Socket.io는 사용하는 방향성에 따라 차이가 있으나, 이게 무조건 좋아 , 저게 무조건 나빠라는 부분은 없습니다. 그러나 Socket.io가 WebSocket보다는 평안한 부분이 있는건 사실입니다. Websoc

iceflower.tistory.com

 

2022.12.07~09 : 런칭 후 오류들

런칭하고나서는 진짜 여러가지 오류들이 많이 나온거 같습니다. 기본적으로 필터 및 검색부터해서 아바타가 안나오거나 혹은 포인트 해킹까지.. 좋은 말씀 해주시는 분들도 많았고, 조금 더 열심히 하라는 의미로 오류도 세세하게 다 적어주신 분들도 계셨습니다. 현재 까지느 사용해주신분이 90명정도, 응답 받은건 33개정도인데 인원에 비해서 적긴하지만 그래도 응답을 받았다는거에 감사함을 느낍니다. 처음에는 아무도 안써주면 어떡해야하나 라는 생각을 많이 했거든요. 아직 런칭 기간이 며칠 더 남았지만 많은 응답이 왔으면 합니다.

 

https://iceflower.tistory.com/48

 

방탄 Helmet

Helmet은 Express로 만들어진 웹 사이트의 보안을 강화하기 위해 사용되는 모듈입니다. npm install helmet const helmet = require("helmet"); // 헬멧의 모든 기능 사용 app.use(helmet()); // 헬멧의 특정 기능 사용 app.u

iceflower.tistory.com

 

https://iceflower.tistory.com/49

 

소셜 로그인(카톡, 구글, 네이버)

소셜 로그인 without Passport 기본적인 순서 1. 프론트에서 인가코드를 받는다 2. 인가코드를 백에게 전달한다 3. 받은 인가코드로 백은 소셜로그인 하는 곳에 토큰을 요청한다 4. 받은 토큰을 가지고

iceflower.tistory.com

 

2022.12.12~13 : 유저테스트 완료

1주일간의 유저테스트가 끝이 났습니다. 총 116명 정도의 유저분들이 참여해주셨고 응답은 약 50개 정도 받은거 같네요.

웹페이지, 모바일 두 환경에서 다 사용하도록 만들었는데 이제 슬랙에 홍보를 하다보니 대부분의 사람들이 웹페이지에 많이 들어오셨습니다.

 

만족도는 정말 다양하게 나왔던거 같습니다. 초반에는 오류가 많아서 점수가 낮은 경우도 존재 했는데, 오류를 차근차근 고쳐나가면서 그 이후에 사용해주신 유저분들에게는 좋은 점수를 받았습니다.

 

가장 만족도가 높았던 부분은 아바타 부분이었던거 같습니다.

포인트를 얻어서 자기만의 아바타를 꾸미는게 확실히 끌리는 부분이었나봐요. 저도 이 부분이 만족스러웠습니다.

그 이외에도 사진을 보여드리면 다음과 같습니다.

처음 해본 실전 프로젝트로는 정말 만족을 많이 했습니다. 프론트 분들과 협력해나가는 부분과 새로운 주제를 가지고 도전해보는 재미도 있었습니다.

 

2022.12.14~15 : 최종발표회 전 마지막 준비

이제 발표회가 한걸음 다가왔습니다. 최종발표회를 위해 마지막까지 오류들을 고치고 영상 및 깃허브를 정리를 하였습니다. 발표괴가 다가온다고 하니 정말 끝나가는 구나 라는 생각이 많이 들었습니다. 그런 생각을 하면서 아 조금만 더 해볼껄 새로운 기술들도 적용시켜볼껄 이라는 생각도 가지게 되었습니다. 면접도 준비도 해야하기때문에 계속해서 블로그도 같이 작성하게 되었고, 면접에 대한 두려움이 많이 있어서 떨겠지만 최대한 준비해보려고 합니다.

 

2022.12.16 : 최종발표회

드디어 최종발표회를 했습니다. 뭔가 엄청나게 힘들지는 않았지만 여러 사람들의 프로젝트와 협력사 분들의 세션을 연속으로 듣다보니 정식적으로 힘들었던거 같습니다. 재밌고 다양한 프로젝트도 있었고 협력사 들과 같이 얘기하는것도 좋았습니다. 사실 협력사 분들이 하나하나 돌아다니기 힘드시기에 직접 찾아서 모셔오는 경우가 대부분이었지만요. 정말 우리 반 고생 많이 했습니다.

 

2022.12.19~22 : 면접 준비

최종발표회가 끝난 후, 이제 면접준비를 하게되었습니다. 면접 준히를 하기위해서 항해에서 준 여러 자료를 이용해서 준비를 했고, 관련되 내용은 블로그에 정리를 많이 하면서 공부했습니다. 이제 진짜 수료식을 앞두고 있는 상황인데 99일이라는 시간이 이렇게 빨리 지나가서 얼떨떨했습니다. 마지막 글은 이제 최종 공부한 시간과 함께 올리겠습니다.

 

 

2022.12.23 : 마지막 항해 수료식 날

드디어 마지막 날 항해가 되었습니다. 지금까지 출석체크를 얼마나 했는지 그 주와 시간을 올려놨습니다.

이렇게 보니 정말 많이 공부했네요... 처음에는 단순히 100시간만 넘기자 라는 생각으로 공부했는데 그걸 이룰수있어서 좋았습니다. 마지막은 이제 항해끝나는 시점으로 출석체크가 멈춰서 100시간은 못채운게 아쉽지만 그래도 3개월동안 해왔던 습관을 그대로 계속 유지할 수 있도록 노력하면서 취업에 성공하겠습니다. 끝까지 버텨온 항해99 9기 수료생 분들과 저희 E반 모두 수고하셨습니다! 이제 꽃길만 걸을수 있도록 해봅시다!

728x90

'항해 일지' 카테고리의 다른 글

사용자 패스워드를 전송/보관  (0) 2022.12.21
트랜스파일러와 번들러  (0) 2022.12.19
Node.js === single-thread || multiple-thread??  (0) 2022.12.19
JWT  (0) 2022.12.19
깊은 복사 와 얕은 복사  (0) 2022.12.19