사진은 몇주전 제주도 놀러갔을 때 바다가 이뻐서 찍은 사진... ㅎ 블로그 글을 참 오랜만에 쓰는 것 같다. 예전 블로그도 직접 만들어서 글도 많이쓰고 공부한 내용도 많이 올렸는데, 바보같은 실수로 데이터베이스는 백업을 해뒀는데, 데이터 안에 사진들은 모두 url로 저장해놓고 사진들을 백업하지 못해서 이전 글들을 다 날리게 되었다. 그래서 블로그 개발은 순조롭게 끝났는데, 멘탈이 터져서 이제서야 첫 글을 쓰게 되었다. 올해는 개인적인 스터디도 많이하고, 여행도 많이 다니고, 바쁘게 사는게 목표이다. 그래서 블로그를 다시 리뉴얼해서 오픈하게 되었고, 글도 많이 쓸 예정이다. (간단한 글부터... ㅎㅎ..) 특히 블로그 만들면서 많은 트러블슈팅 사례를 겪게 되어 그런 부분들을 많이 기록하려고 한다. (+여행 일지) 아직 기존 페이지중에 블로그만 리뉴얼을 해서 오픈을 했는데, 개인적인 사이드프로젝트를 올리는 playground 역할을 하는 페이지나, 내 소개를 하는 페이지 등,

일단, DataLoader가 뭔지 설명하기 전 GraphQL에서 발생할 수 있는 n+1 문제를 이해해야 한다. n+1 문제란? query { posts { id title contents user {...} } } 다음과 같이 posts라는 데이터를 조회하는 쿼리가 있을 때, posts 데이터를 가져오는 쿼리 1개, 그리고 각각의 posts 별로 가지고 있는 user라는 데이터를 가져오는 쿼리가 n개가 필요하며 이를 N + 1 문제라고 한다. 즉, 내부 객체를 얻기 위해 외부 객체에서 N개의 쿼리를 만드는 경우를 말한다. 다음과 같은 N+1 문제를 해결하기 위해서는 보통 세 가지 구성 요소가 필요하다. Data Source: 일괄 가져오기를 지원 Data Loader: 요청을 batch Data Fetcher: 데이터 요청에 필요한 컨텍스트를 전달 (id값 같은 고유 식별자) 이제 이 구조에서 사용하는 Data

글을 쓰는 지금 시점에서 개발 공부를 시작하고 약 1년 반 정도가 지났다. 길다면 길다고 볼 수도 있고, 짧다면 짧다고 볼 수도 있는데, 나름 열심히 노력해서 네이버에 개발자로 취업하게 되었다. 오늘은 그 과정에 대해 간략하게 나의 후기를 적어보려고 한다. 제목이 "부스트캠프부터 네이버 개발자가 되기까지"인 이유는 과정 자체에서 부스트캠프에서 교육받은 기간도 길었고, 네이버에 입사할 수 있었던 핵심적인 역할을 했다고 생각했기 때문이다. (게다가 이 블로그도 부스트캠프에 포트폴리오 하나는 제출하고 싶어서 개발했었다) 부스트캠프 이전 부스트캠프 이전에는 평범한 4년제 대학 학부생이었다. 다만, 개발을 공부하던 공대생은 아니었고 정보보호학과에서 보안관련 수업을 듣고있었다. 우연히 안드로이드 앱 개발 관련 강의를 듣고 개발 자체에 관심이 생겨서 찾아보던 중 웹 개발을 제일 해보고 싶어서 개발 공부를 시작했다. 처음에는 백엔드, 프론트엔드라는 개념으로 나누어져 있다는 것도 잘 몰랐다.

클라이언트와 서버가 통신할 때 토큰을 사용할 경우 토큰을 탈취당할 우려가 있기 때문에 보통 API에 접근할 때 사용하는 Access Token과 Access Token을 재발급 받는 Refresh Token으로 구성하는 경우가 많다. Access Token은 API에 접근할 때 사용하지만 탈취당할 경우 서버에서 접근을 막기가 어렵기 때문에 토큰의 유효기간을 짧게 두고 Refresh Token을 통해 주기적으로 재발급받으며 인증을 처리한다. 하지만 서비스를 이용하는 도중에 Access Token이 만료된다면 요청이 실패하게 된다. 그렇기 때문에 토큰 만료로 인한 에러로 요청이 실패한다면 자동으로 토큰을 재발급 받아 이전에 실패한 요청을 재요청하게 되면 사용자 경험이 향상되게 된다. 내 블로그의 토큰 재발급 과정 내 블로그는 토큰을 쿠키에 보관한다. 서버에서 로그인 시 쿠키에 토큰을 담아 반환해주기 때문에 클라이언트에서는 따로 토큰을 컨트롤 하지 않아도 되도록 구성했다. 내

부스트캠프 멤버쉽 과정이 끝난지 3주 정도 지난 것 같은데 이제야 후기를 작성하게 되었다. 아무래도 취업 준비로 가장 바쁜 시기이기 때문에 미루다 미루다 오늘이야 작성하게 되었는데, 부스트캠프 과정 자체가 내 인생에서 무척 기억에 남게 되었고 많은 것도 얻게 된 소중한 추억이기 때문에 꼭 기록으로 남겨두고 싶었다. 사실 부스트캠프 교육 과정에 대해 자세한 내용은 보안상 발설할 수 없기 때문에 공개된 과정의 내용이나 느낀점 위주로 후기를 작성하려고 한다. 학습 스프린트🏃 말 그대로 스프린트, 전력 질주를 하며 웹에 대한 학습을 하는 과정이었다. 한 미션당 2주씩 총 6주동안 진행되었는데, 이 때 바닐라 JS에 대해 정말 많이 알게 되었다. 사실 평소에 리액트를 사용한 개발을 주로 하다보니 바닐라 JS를 사용한 웹 개발은 익숙하지 않은 부분이 많았다. 그런데 이 기간에 라이브러리를 거의 사용하지 않고 요구하는 거의 모든 기능을 개발하며 짧은 시간 내에 많이 성장했다는 느낌을

자바스크립트라는 언어는 싱글 쓰레드 언어라고 알려져있다. 보통 싱글 쓰레드라고 하면 한 번에 하나의 작업만 수행할 수 있다고 생각한다. 그렇다면 자바스크립트를 주로 사용하는 웹 사이트에서는 어떻게 한번에 여러 요청을 받을까? 그리고 여러 요청이 오갈 수 있는 자바스크립트는 왜 싱글 쓰레드일까? 오늘은 이 주제에 대해 알아보려고 한다. 자바스크립트는 정말 싱글 쓰레드일까? 맞다, 정확하게 말하면 자바스크립트의 메인 쓰레드인 이벤트 루프가 싱글 쓰레드이기 때문에 자바스크립트를 싱글 쓰레드 언어라고 부른다. 하지만 이벤트 루프만 독립적으로 실행되지 않고 웹 브라우저나 NodeJS같은 멀티 쓰레드 환경에서 실행된다. 즉, 자바스크립트 자체는 싱글 쓰레드가 맞지만 자바스크립트 런타임은 싱글 쓰레드가 아니다. 싱글 쓰레드로 어떻게 한번에 여러 요청을 처리할까? 기존 동기식 요청은 코드를 한줄 한줄 차례대로 실행한다. 그래서 하나의 작업에 걸리는 시간에 관계 없이 첫 번째 코드가 실행 된

렌더링이란? 단어 그대로 렌더링이란 HTML, CSS, JavaScript 등 개발자가 작성한 문서들을 브라우저가 화면에 그려주는 동작을 말한다. 각 브라우저는 렌더링을 하기 위해 각각의 렌더링 엔진을 가지고 있으며 브라우저마다 종류가 다를 수 있다. 브라우저의 기본 구조 브라우저의 렌더링 과정을 이해하기 전에 일단 브라우저가 어떻게 구성되어 있는지 주요 기본 구성 요소를 살펴보자! 각 구성 요소는 다음과 같은 역할을 하고 있다. 물론 구조는 브라우저마다 조금씩 다를 수 있다. 사용자 인터페이스: 주소 표시줄, 이전/다음 버튼, 북마크 등 페이지 뷰 이외의 다른 부분 브라우저 엔진: 사용자 인터페이스와 렌더링 엔진 사이 동작 제어 렌더링 엔진: HTML, CSS를 파싱해 화면에 요청한 컨텐츠를 표시 통신: HTTP요청과 같은 네트워크 호출에 사용됨 JS 엔진: 자바스크립트 코드를 해석하고 실행 UI 백엔드: 기본적인 위젯(콤보 박스 등)을 그림 자료 저장소: 자료를 저장

요즘 내 일상은 하루종일 부스트캠프인것 같다. 😅 격주마다 반복되는 미션을 수행하면서 여러가지 개인 공부도 하고 있었는데 부스트캠프 운영진 분들께서 부스트캠프 Tech Talk라는 내부 행사에 대해 소개해 주시며, 이 행사에서 다른 캠퍼들에게 공유하고 싶은 내용이나 발표하고 싶은 캠퍼가 있다면 지원을 받으셨다. 부스트캠프 Tech Talk는 부스트 캠퍼가 공유하고 싶은 기술이나 공부 방법, 그외 노하우 등을 다른 부스트캠퍼들에게 발표하며 공유할 수 있는 시간이다. 여러 Zoom 회의실에서 컨퍼런스 형식으로 동시에 진행되었으며 각자 관심이 있는 발표 주제를 보고 발표를 보러가면 된다. (발표 영상은 부스트캠프 내부 커뮤니티에 한정적으로 공개되었다.) 지원 계기 지원 포스터를 보고 뭔가 본격적으로 발표해야 할 것 같아 처음에는 겁이 나서 신청을 안했었다. 그런데 슬랙 댓글에 운영진분께서 일단 지원하고 고민하라는 말을 적어주셔서 (나는 말을 잘 듣는 어른이니까😁) 고민 없이

일단 passport와 jwt를 사용하기 전에 이 두가지가 무엇인지부터 알아보도록 하자. JWT란? JWT(JSON Web Token)은 클라이언트와 서버 혹은 서비스간의 통신시 정보를 JSON객체를 통해 안전하게 전송하고 권한(Authorization)을 위해 사용하는 토큰이다. 그렇다면 JWT를 언제 사용해야 할까? Authorization: JWT를 사용하는 주요 이유이다. 사용자가 로그인 하게되면 서버는 사용자에게 JWT를 발급해주고 사용자는 이 JWT를 사용해 해당 토큰으로 허용되는 서버의 서비스에 접근할 수 있다. 정보 교환: JWT는 정보를 주고 받는데도 유용하게 사용할 수 있다. 예를 들어 공개키, 캐인키 쌍을 사용해 JWT에 서명할 수 있으므로 발신자가 자신이 말하는 사람인지 확인할 수 있다. 또한 Header와 Payload를 사용해 서명이 계산되므로 정보가 변조되지 않았는지도 확인할 수 있다. (Header와 Payload에 관한 내용은 바로 다음에 설명

최근 TypeScript 4.0이 새로 발표되었다. 평소에 타입스크립트를 많이 활용하던 나로써는 주요 변경사항에 대해 알아가면 좋을 것 같아 간단하게 발표 내용을 요약, 번역하여 포스트에 작성하게 되었다. 전체적으로 새로운 문법과 추가된 옵션, 개선된 내용을 포함해 많은 내용을 발표 했는데 그 중에서 문법과 옵션, 추가적인 변경 사항으로 그룹을 나눠 정리해보려고 한다. 새로운 문법 가변 열거 타입 TypeScript 4.0에서는 가변 열거 타입에 대한 문법에서 몇몇 달라진 내용이 있다. 첫 번째로 달라진 내용은 열거 형식 구문의 스프레드에 제네릭이 적용된다. 이것은 우리가 실제 사용중인 타입을 모를 때에도 타입 추론이 가능하다는 것을 의미한다. function tail(arr: readonly [any, ...T]) { const [_ignored, ...rest] = arr; return rest; } const myTuple = [1, 2, 3, 4] as con