- 다시 본론으로 돌아가, 이런 의문이 생긴 이유는 hook의 deps에 object를 넣는 일이 생겼다. object를 넣었을때는 어떤 경우에 콜백 함수가 실행될까라는 의문이 들었다. object 내부의 프로퍼티가 바뀌었을때도 감지해서 콜백 함수가 실행될까? 혹은 key, value가 같은 object로 바뀌었을때는 콜백함수가 실행될까라는 의문이 들었다.
- 결론적으로 설명하면, objectA !== objectB가 성립되면 콜백 함수가 실행되었다. 즉 내부의 프로퍼티 변경을 감지하는 것이 아닌 단순히 객체의 주소 값만을 비교하고 달라지면 콜백 함수를 실행하는 것이였다.
- 따라서 당연한 이야기겠지만, 테스트를 해 보았을때 objectState의 프로퍼티를 변경하거나, 프로퍼티를 변경한 후 그 객체를 다시 setState 해줘도 콜백함수는 실행되지 않았다.
동작 원리
- 물론 여기까지만 봐도 짐작으로 deps의 변화를 어떻게 감지하는지 유추가 되지만, 정확히 어떻게 돌아가는지 확인하고 싶어서 찾아보기 시작했다. 처음에는 TypeScript에 정의된 deps의 타입을 찾아보았다. deps의 타입은 dependencyList라고 나오고 배열 안에 값이 들어가는 것만 확인할 수 있었다.
- 그 다음으로 찾아본 것은 React의 GitHub 코드를 찾아보았지만 너무 방대한 나머지 처음에는 찾다 포기를 하였다.
- 이에 관련된 글이 있을까 싶어 찾아보다가 믿음직하고 설명도 잘 되어 있는 글을 찾았다. 바로 netlify의 기술 블로그?였다.
제목도 뭔가 외국 도서인데 한 2003년에 출시되었는데 번역된 느낌이라서 끌리지 않았는데.. 놀랍게도 한국인 저자에 2018년도 초판 발행이었다.
지금부터라도 천천히 읽으려고 펴봤는데, 내용이 정말 좋아서 정리하려고 한다.
뭔가 부캠에서 마스터(멘토)분들이 많이 해주신 말씀이 있는데, 그 때도 와닿는 내용들이었는데, 지금 보니까 더 강하고 새롭게 와닿아서 이 책 내용들을 읽으며 본 내용 및 내 생각들을 정리해보려한다.
2021/7/20
회고하자.
- 부캠에서 많이 듣고 하던 것들이었는데, 막상 일을 시작하고는 거의 하지 못했다.
- 회고를 하며 내가 하는 일들을 더 개선할 수 있는 방법들을 생각하고 실천해서 다음에 할 땐 실수를 덜 하고, 더 효율적으로 효과적으로 작업을 해야겠다.
즐기자.
- 취업 전에는 취미로 개발을 할 정도로 즐겼는데, 이상하게 취업을 하고 나서는 퇴근하고 개발 공부를 예전만큼 하지는 않는 것 같다.
- 입사 후 3개월까지도 열심히 했는데 뭔가 코로나의 여파인지, 아니면 이제 무의식적으로 일이라고 여겨서인지, 예전만큼 즐기지 못하는 것 같다.
- 일이라고 생각하지말고 예전처럼 즐겨야겠다. (근데 출근할 때는 좀 즐거운데), 이상하게 집에서 할 때는 스트레스를 받는 기분이다.
- 집에서 개발을 하면 뭔가 일과 삶이 섞이고 무너지는 기분이라서 그런 것 같기도 하다.
- 부캠할 때, 개발은 장거리 마라톤이라고, 그리고 일과 일이 아닌 것을 분리해야한다고, 그래서 재택하더라도 출근/퇴근하는 것처럼 밖을 한바퀴 돌고 들어오라고 하셨는데, 이제 그 말의 의미를 알 것 같다.
- 취미는 취미로 내버려두고, 전업으로 하고 싶지 않다는 사람들의 말을 이제는 조금은 이해할 수 있을 것 같다.
- 그래도 즐겁게 개발을 지속가능하게, 오래오래할 수 있는 방법을 찾아야 할 것 같다.
발전하자
- A라는 일을 하기 위한 B라는 일을 하고, B라는 일을 개선하기 위한 C라는 일을 하자
- 이 말의 의미를 부캠할 때는 크게 못 느꼈는데, 요즘은 많이 느끼는 것 같다.
- 더 잘하기 위한 방법을 더 잘하기 위한 방법을 더 잘해보자 ㅎㅎ
- 블로그도 이제 좀 다시 써봐야겠다.
2021/7/22
어려운 일을 해라
- 이 말은 어려운 개발을 해라라는 의미보다, 사람들과 소통하는 등의 업무를 하라는 뜻이다. 코파일럿이 나온 지금 더욱더 중요한 말인 것 같은데, 주어진 스펙을 개발하는 개발자가 아니라 요구사항을 분석하고, 요구를 이해하고 오히려 제안하는 등 컴퓨터가 하기 힘든 일을 잘하는게 중요한 것 같다.
- 이말은 간단히 말하면 답이 있는 문제, 측량이 가능한 그런 문제가 아닌, 답이 없는 문제, 측정이 어렵고 당장 눈에는 안 보이지만 어려운 것들을 하라는 말이다.
- 조금은 논점에서 벗어나지만, 이 부분을 읽으면서 예전에 대학생 때 프로젝트하면서 요구하면 '다 해주는 개발자'로 불렸던게 기억난다. 요구사항을 들고오면 다 구현해주었다. 물론 실력이 모자랐기에 아주 깔끔하고 완벽하게 개발해주지는 못했지만...그 때 기억나는게, 돌아가는 예시 사이트를 들고오면 그대로 해주겠다고 했었는데...참 패기로웠던 것 같다.
- 물론 또 다시 생각해보면, 요구사항을 다 들어주지는 않았다. 요구 사항을 들고오고, 예시 사이트를 들고오면, 어떤 부분이 적용되길 바라는지, 왜 이 부분을 넣고 싶은지, 이런 저런 이야기를 해주면서 요구사항을 디벨롭하며 필요 없는 부분은 쳐내고, 필요한 부분은 더 발전시켰던게 생각나서, 나름 잘 살았던 것 같다. 정말로 논점에서 벗어난 이야기인 것 같지만..
계속 의식하면서 일해라
- 이 부분은 더 읽어봐야 알겠지만, 간단하게 말하면 양치질 30년한다고 양치 전문가가 되지 않듯이 의식하면서 일을 해야한다!
2021/10/17
사실 이 책을 다 읽은지는 꽤 되었다. 근데 블로그 관리를 하지 않아서...ㅠ
책 내용이 괜찮아서 나중에 생각날때 다시 읽겠지만 기억나는 요점은 간단히 정리하자면
애자일하게, 결과를 짧게 짧게 낼 수 있도록 하고, 그에 대한 회고를 하며 단점을 보완해서 나아지자! 라는게 이 책의 핵심인 것 같다.
여기서 의문이 시작됐다. JavaScript에서 Object와 Map은 어떻게 이루어져있을까?? 물론 인터프리터, 컴파일러, 엔진에 따라 다르겠지만,내가 자주 쓰는 Node를 기준으로 어떻게 되어있는지 궁금했다. 이에 대해 개인 Notion에 러프하게 정리했었는데, 블로그에 깔끔히 정리해보려한다.
Map과 HashMap
먼저 Map과 HashMap에 대하여 알고 있어야 이해하기가 편할 것 같다.
HashMap = unordered Map
HashMap은 key 와 value 를 hash 알고리즘에 의해 구현
Hash 알고리즘으로 넣으므로 전체가 어떤 특정한 규칙으로 정렬이 되어 있지 않다.
hash_map은 find에 이상적으로 O(1)의 시간을 소요한다.
하지만 hash_map은 실제로는 hash table의 크기에 반비례하는 O(n)의 시간을 소요한다.
예를 들어 1000개 저장하는데, 테이블 크기가 100이라면, 시간은 10만큼 걸릴 것이다.
Map ( Tree Map ), Ordered Map
Map( Tree Map)은 보통 red-black tree 알고리즘을 이용하여 구현
Tree의 규칙대로 들어가므로, Order되어 있다, 즉 정렬되어 있다.
Map( Tree Map )을 쓰는 경우, 최악의 경우 O(n), 최상의 경우 O(logn)의 시간복잡도
동일 출처 정책(same-origin policy)은 어떤출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식입니다. 동일 출처 정책은 잠재적으로 해로울 수 있는 문서를 분리함으로써 공격받을 수 있는 경로를 줄여줍니다.
간단하게 설명하자면 a.com이라는 사이트에서는 a.com에서만 정보를 가져올 수 있다는 것이다. 즉 프론트 서버는 a.com으로, 백앤드 서버는 b.com으로 분리하면 안되고, 둘 다 a.com에 존재해야 데이터를 주고 받을 수 있다는 것이다.
교차 출처 리소스 공유(Cross-Origin Resource Sharing,CORS)는 추가 HTTP 헤더를 사용하여, 한출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.
즉 간단하게 말하면, HTTP 헤더에 정보를 추가하여, 다른 Origin끼리도 데이터를 주고 받을 수 있게 한다!라는 것이다.
a.com에서 b.com의 데이터를 요청한다면,
클라이언트에서 서버로 요청할 때 http header에 { Origin : a.com } 이렇게 요청하는 곳의 출처를 넣고,
서버에서 클라이언트로 응답할 때는 { Access-Control-Allow-Origin : 허용할 주소 } 이렇게 응답을 보낸다.
그리고 만약 내가 요청한 주소가 허용할 주소에 포함되어 있다면, 데이터를 받아서 화면에 뿌려준다.
그렇지만 반대로 요청한 주소가 허용할 주소에 포함되어 있지 않다면, CORS 오류가 발생한다.
CORS 오류 해결 방법
이 문제를 해결하기 위해서는 서버 측에서 응답할 때 http header 내에 있는 {Access-Control-Allow-Origin : 허용할 주소}에 a.com을 넣어주면 CORS 오류는 발생하지 않게 된다.
혹은 어느 사이트에서 요청할지 모르니, {Access-Control-Allow-Origin : *} 로, 모든 주소를 허용하면 편하게 해결할 수 있다. 물론 이렇게 된다면 보안상 문제가 생길 수 있다.
만약 내가 서버를 건들일 수 없다면, 이 문제는 브라우저에서 막아서 발생하는 문제이므로, 프록시 서버를 하나 만들어서, 프록시 서버에서 정보를 받아온 후, 클라이언트에 {Access-Control-Allow-Origin : 허용할 주소}를 허용하여 문제를 해결할 수 있다.
이 부분은 시간이 되면 그림과 함께 자세히 다루어보려고 한다.
그리고 클라이언트 쪽에서 문제를 해결하는 방법을 찾아보려한다.
CORS의 보안 문제?? 어디가??
사실 이 윗부분은 CORS를 구글에 검색하면 나오는 보편적인 내용이다. CORS를 검색하면 가장 위에 나오는 MDN을 한 번 읽어본기만 해도 이해할 수 있는 내용이다. 만약 이 글이 이해가 안된다면, MDN에는 친절하게 그림과 함께 설명되어 있고, 친절하게 설명되어 있는 블로그들이 많다.
하지만 이 글을 적게 된 이유는 나처럼 이 글들을 읽고 이해가 안되는 부분이 있는 사람이 있을 것 같아서이다.
내가 이해가 안되는 부분은 보안상 문제라는 부분이었다.
처음에 나는 보안상 문제라고 하여,
허가 받지 않은 클라이언트가 서버의 정보를 몰래 빼오려고 요청하는 것을 막는 것인줄 알았다.
API를 만들어서 내 사이트에만 뿌리고 싶은데, 다른 사용자들이 맘대로 가져가서 사용하려고하는 것을 막으려는 건 줄 알았다.
하지만 이렇게 이해를 하면 막히는 부분이 생긴다.
서버에 정보를 요청하면 정보는 보내주지만, 단지 http header에 {Access-Control-Allow-Origin : 허용할 주소} 를 넣어서 보내고,
이 http header를 클라이언트의 브라우저에서 확인한 후, 자신이 허용할 주소가 아니라면 정보를 클라이언트에게 보여주지 않는 것이다.
서버에서 정보는 잘 보내줬는데 클라이언트에서 막을까?라는 생각과 내가 생각한 보안 문제가 아닐 것이라는 의심을 하였다.
그리고 그 이유를 찾아보았고, 맞는지는 모르겠지만 어느 유튜브에서 그 이유를 들을 수 있었다. 유튜브의 출처는 글 맨 하단에 작성하였다.
내가 알게된 CORS 정책의 이유를 예시를 들어서 설명하면,
내가 서비스를 만들었는데, a.com이라는 사이트를 만들고, b.com이라는 WEB API를 만들었다고 가정하자.
a.com에서는 로그인 한 후, 그 정보를 이용하여 b.com에서 데이터를 가져올 수 있다.
이런 상황에서 Trudy라는 정보를 탈취하고 싶은 사람은 t.com이라는 나쁜 사이트를 만들었다.
t.com에 사용자가 접속하면, b.com으로 정보를 요청해서 받아온다.
이 때, 클라이언트에 저장되어 있는 쿠키 같은 정보를 이용하여 사용자가 로그인되어 있는 상태로 요청하여 정보를 캐올 수 있다.
이 때 b.com에는 a.com만 허용하는 CORS 설정을 해놓았다면,
t.com에서 b.com으로 요청해서 받아오는 정보는 CORS 오류가 발생하게 되어 t.com한테 정보를 탈취당하지 않을 수 있다.
맥락과 흐름이 이렇게 이루어져, CORS는 이런 보안을 위하여 존재하는 정책이고,
이 부분도 시간이 난다면 그림과 함께 자세하게 설명하겠다.
[회고] CORS에 대한 공부를 하고,,,
CORS에 대해 공부를 하며, 생각보다 보안의 의미가 크고, 글을 읽으며 내가 네트워크 보안이라는 과목을 듣지 않았다면 이해를 한 번에 할 수 없었을 것이라 생각이 들어, 전공에 대한 기초 지식의 중요성을 느꼈다...
그리고 문제를 해결할 때, 문제가 해결되었다고 끝내는 것이 아니라, 해결할 때 들었던 의문점들을 제대로 해소해야되겠고, 왜라는 의문을 더 깊게 해야되겠다는 생각이 들었다.
