210913-19 1주차 항해99

0. 처음맞는 일요일

시간이 증발했다.

항해 시작 전부터 지금까지 느껴지는 시간개념이 이상하다

항해시작 전 일요일 - 으아아아아 어? - 항해시작 후 첫 일요일

대강 이런느낌.

프로젝트 하는 동안 분명히 날짜도 요일도 바뀌었는데,

월화수목금요일이 너무 하루같은 연속성이어서 '지난 일주일' 이라고 생각하는게 어색하다.

 

TIL은 그래도 어느정도 쓰는게 익숙해졌는데,

뭔가 데일리로 구분지었던 걸 다시 위클리로 하려니 아직은 좀 머릿속이 모호하다.

아마 책한권에 챕터하나의 줄거리를 정리하는 느낌일까 싶다.

어쨌건 써본다.

써놓은 TIL들을 보면서 쓰다보면 또 한번 복기가 되겠지!

그리고 오늘은 그나마 길게 쓸 수 있는 마지막 일요일이 아닐까.....

 

 

1. 지난 일주일간 배운것들

 

< git에 익숙해져야 한다. >

모든 개발일지와 소스코드들의 관리, 협업이 git에서 이루어진다.

git의 기능을 아직은 다 제대로 능숙하게 활용하지 못하지만,

최근에 git의 계정정보 관리가 기존의 패스워드 형식이 아니라, 시리얼넘버 같은 토큰 형식으로 대체되고 있다는 건 확실히 배웠다.

이것 때문에 내가 팀장이었음에도 불구하고, git 을 활성화 시키지 못해서 4시간 넘게 고생했었다.

그리고 패스워드를 입력하라고 나왔을때,

'패스워드니까 패스워드 겠지, 근데 왜 안되지? 뭐가 문제지?' 했던 내 고정관념과

'잘 모르는데 아무거나 건드렸다가 이거 더 돌이킬수 없어지는거 아닐까?' 했던 처음에 대한 두려움이

아-주 훌륭한 시너지를 내주는 덕분에 아주 고생고생을 하핳.

마지막에 '에라 모르겠다, 어떻게든 되겠지' 라며 토큰 키를 패스워드로 입력했더니 해결.

고정관념 박살 + 처음에 대한 두려움 박살 = 일단 해보고 에러잡자

고작 git 계정 활성화도 배운거라고 적기가 참 부끄럽지만 사실은 사실이니까.

 

< 항상 임포트와 헤드부분을 꼼꼼히 확인하자. (+ 환경관리) >

코드 입력이 잘못된 에러보다 임포트와 헤드 CDN 등 기본 환경관리가 제대로 되지 않았을때 에러가 더 골치아팠다.

대부분 내가 입력하고 수정하고 코드를 치는 부분에 시간적으로 많이 할애하다보니, 오류가 났을때 당연히 그쪽을 먼저 봤었다.

왜냐,

패키지 임포트는 그렇다치고, 특히 클라이언트쪽에서 CDN 개념이나 CDN을 한줄한줄 이게 뭔지 뜯어보고 확인한적이 없었기 때문.

그러니까 비유하자면,

종이도 제대로 준비해놓지 않고, 펜에는 잉크가 잘 들어있는지 확인도 안한채로 쓰고 그린걸 보여주면서 '자 이대로 해봐' 라고 한것 같은.

(당연히 되는게 없겠지)

심지어 CDN의 경우는 로드 되는 순서도 중요하다.

예를들어, 부트스트랩의 CDN이 JQuery의 CDN 보다 윗순서에 로드되고 있으면 에러가 난다.

그래서 나는 이렇게 생각하기로 했다.

클라이언트와 서버가 서로 정보를 주고 받고 최종적으로 사용자의 브라우저에 렌더링을 하기까지의 순서에 맞춰서 정리하자.

이 임포트나 헤드가 왜 최상단에 위치하는지 진짜 정말 절실히 깨달았다.

정말 환경설정이 얼마나 중요한 것인지, 비슷한 맥락에서 또 에러에 흠씬 맞았던 게 2일차였다.

로컬에서는 아무 이상이 없는데, 왜 왜 똑같은 걸 웹서버야 너는 못하니. 

'왜 읽질 못하니. 소스코드를 가져왔는데 왜 읽지를 못하니.'

'옆집 로컬이는 똑같은 소스코드로도 잘만 하던데, 웹서버 너는 왜 못하니.'

왜냐,

로컬이랑 환경이 달랐기 때문.

로컬에서 임포트된 패키지나 라이브러리 같은 기본 환경 설정을

웹서버에도 똑같이 해줘야 하는데, 이렇게 환경 관리도 제대로 안해주고 해내라고 했으니.

웹서버 입장에서는 '아니 뭐 그냥 주면 뭐 어쩌라고 이걸 니가 하라는대로 하려면 똑같이 할 수 있게 만들어주던가' 였겠지.

그래서, 내가 임포트된 패키지나 헤드를 딱 보자마자 알아차릴 수준이 되기 전까지,

난 무조건 이제 소스코드 첫줄(환경)부터 확인한다.

 

< 콘솔의 생활화 >

이제 에러가 뜨거나, 내가 원하는대로 안되거나하면 우선 에러코드 읽어보고,

응 알겠어 우클릭 검사하고 엘리먼츠.. 콘솔.. 어플리케이션...

에러 잡는데 가장 중요한건 에러에 대한 접근 방식인 것 같다.

에러가 왜 발생했을지 API의 어떤 흐름에서 막힌건지 생각해보고,

최대한 구체화 해야 구글로 해결하는 것도 원활하다.

비슷한 오류 해결 방식들 중 나랑 어떤 디테일이 다른지 확인하고 그 디테일로 파보고 파보고 파보다보면 거의 다 해결.

 

< JWT >

사실 개념의 이해는 항해에서 제공된 강의로 어느정도 가능했다.

내 나름대로 정리했을 때, 

'유저가 서버측에 제공하는 계정정보를 받고 검증하여 인증된 정보를 JSON 데이터 구조로 표현한 토큰으로 제공, 클라이언트 측에서는 받은 토큰을 쿠키에 저장 후 서버와 정보를 주고 받을 때 별도의 인증과정없이 해당 토큰정보로 인증할 수 있게하는 서버-클라이언트간의 인증방식. '

이런 토큰 방식이 아니더라도 쿠키/세션 방식을 사용하는 경우도 있었다.

하지만 내가 학습한 내용대로라면, 쿠키/세션 방식은 인증과 검증에 필요한 고유 ID 값을 담아둘 세션 저장소가 필요한데,

그렇게 되면 자연스럽게 서버측에서 저장소 세션을 위해 일부를 할당해야하고, 그게 곧 서버의 부하로도 이어질 수 있다는 단점이 있었다.

또, 유저가 해당 웹을 사용하고 있으면 그걸 유지해야하기 때문에 서버의 확장이나 관리 측면에서도 토큰방식에 비해 아쉬운 부분이 있다.

반면에 토큰 방식의 경우에는 아직까지 나도 활용해보진 못했지만, 토큰을 사용하여 다른 서비스의 권한도 공유할 수 있다는 걸 알게되었다. 예를 들면, 어떤 웹서비스를 이용할때, 네이버로 로그인, 페이스북으로 로그인 등 이런 방식도 토큰이기에 가능하다고 배웠다.

 

그런데, 여기서 또 하나 배운것이 있다.

JWT 방식의 경우 토큰을 인코드 하는 과정에서 외부에 공개되지 않아야 할 SECRET_KEY 값이 필요한데,

이 SECRET_KEY 값이 노출 되면 악용될 수 있는 가능성이 그냥 열려버린다는 것.

그말은 곧, 이 SECRET_KEY 값의 보안 관리가 철저해야 한다는 것.

기존에는 대부분의 소스코드에 이 값들을 그대로 노출시키고 있었는데, 

위의 환경관리 측면과 비슷한 맥락으로 이어지지만, 

SECRET_KEY 값이나, db 정보 등 외부에 노출 되어선 안되는 환경 설정을 별도 파일로 구분해서 관리해야 한다는 것. 

생각해보면 너무나도 당연한 이야기지만, 그룹멘토링을 진행해주신 멘토님의 제안이 없었다면 생각하지도 못했을 것이다.

이 환경 분리는, 내가 학습한 바로는 두가지 방법이 있는데,

서버시스템 자체에서 환경변수를 사용해서 접근하는 방식과

config 파일(별도 관리 파일)을 만들어 관리환경을 분리 시키는 방식 (이 경우에는, git에 공개되지 않도록 gitignore로 분류하여 관리)

나는 후자를 택했다. 

이유는, 내가 이해하고 실행하기에 후자의 경우가 훨씬 직관적이었고, 환경변수 의 경우 일부 웹서버에서는 사용할 수 없는 방식이라는 걸 확인했기 때문.

프로젝트를 종료하고, 우선 별도 파일을 만들어 환경분리를 시키는 방식에 대해서는 멘토님이 좋은 접근 방식이라는 의견을 주셨다.

그리고 이런 방식을 응용해서, 

예를 들어, 중복되는 코드를 자주반복해서 써야한다면,

그 변수도 환경분리 하듯 모듈화하여 임포트 해서 사용할 수 있다.

아마 이런 활용방식을 이해시키기 위해 한 스텝 더 나아갈 수 있는 제안을 주셨던 것 같다. 그리고 이게 습관화 될 수 있도록 하는것도.

 

<API>

API, API, API, API, API, API

아마 제일 많이 들은 단어인것 같다. 이 개념을 이해하고 나서는, 앞으로도 그럴 것 같다는 생각을 했다.

처음에는 도대체 API가 뭔지,

아주 아주 어렴풋이 느낌은 오는데 개념이 잡히지 않아서 검색했다.

(이럴땐 유튭이지)

유튭을 보고 바로 이해했다.

백엔드와 프론트엔드 간의 소통(넓은 의미에서)을 할 수 있게 하는 매개체, 사용 규칙을 제공하는것.

모 유튜브에서 얘기 하기로는,

예를 들어 내가 컴퓨터와 소통하기 위해서는 키보드가 필요하다.

그 키보드가 바로 백엔드와 프론트엔드 사이의 API이다.

와, 이걸로 한번에 이해하기 끝.

그 말은 곧,

내가 지금까지 서버와 클라이언트를 연결하고 서로 정보를 주고받을 수 있게 코드를 입력한 모든 기능적 요소들이 API 였던 것.

(지금은 이렇게 이해했지만, 틀린 부분이 있을수도 있고 나중에는 좀 더 개발자 스럽게? 이해하고 설명할 수 있겠지)

 

 

2. 쓰다보니 길어졌다.

위의 이번주에 배운것에 추가 할까 하다가,

좀 더 써두고 싶은 이야기가 있어서 이건 별도로 쓰려고 한다.

사람들에 대한 이야기

항해에는 정말 진심인 사람들의 밀집도가 높은 것 같다.

프로그램을 제공하고 운영해주는 항해측 스태프분들도 그렇지만,

특히 참가자들.

난 이전의 TIL에도 적었지만, (적어놓고 부끄러워서 비공개로 닫아뒀었지만)

정말 사람들에게 많이 배웠다.

누구나 그럴 것이다.

각자 살아가는 방향이나 철학이 있고, 그것을 충분히 행하면서 살고자 하지만,

과연 내가 그렇게 살아가고 있는가.

내가 살아가고자 하는 방향이나 철학은 눈에 보이는 것이 아니기때문에 거울에 비춰볼 수가 없어서 드는, 끊을 수 없는 의문이라고 생각한다.

항상 지혜롭고 용기 있는 삶, 누군가를 도울 수 있는 보람있는 삶, 누군가의 먼지만한 희망이라도 될 수 있는 삶을 살고 싶었다.

항해 프로그램을 통해서 만난 사람들은 다음과 같았다.

정말 새로운 출발을 위해 용기 있는 결정을 한 사람들,

모르는 것에 대한 끊임없는 탐구를 하는 사람들,

배움에 대한 일말의 거리낌이 없는 사람들,

나누는 것에서 보람을 느끼는 사람들,

공동체의 성장 가치를 이해하는 사람들(우리 팀원들)

이런 사람들의 모습을 보고 이야기나누다 보니,

내 모습과 겹쳐보이는 것들이 많아서

내가 살아가고자 하는 삶을 잘 살아가고 있구나 하는 생각을 하게 됐다. 조금은 안심이었다.

많은 사람들을 만난다는 건, 때로는 그 사람들을 거울삼아 나를 비춰볼 수 있다는 점에서 항상 흥미롭고 행복한 일이다.

 

항상 마지막에 하는 말이지만,

자 이번주는 정말정말 지난주보다 최소 7만큼은 성장한것 같다!