한땀한땀 코딩하기

신나는 프론트엔드!! 바닐라 자바스크립트로만 코딩을 하다가 리액트를 처음 접했을 때는 엄청난 신세계를 접한 기분이었습니다. 말로만 듣던(?) 컴포넌트를 활용해서 코딩을 해볼 수 있고, 복잡하게 이벤트리스너와 핸들러를 구현할 필요도 없어 보였습니다. 이런 느낌이면 할만하겠는데!라고 생각이 살짝 올라올 때, 슬슬 그것이 찾아왔습니다. 상태 관리 아주 간단한 페이지 구성을 하는데도 props가 미친 듯이 늘어나기 시작하고, 가장 하위 컴포넌트에게 전달하려고 10개가 넘어가는 props를 몇 번에 걸쳐 전달하는 제 코드를 발견하게 되었습니다. 깃허브 이슈 탭 클론 코딩을 할 때였는데, 결국 보다 못한 팀원 분이 Context API와 useReducer를 이용해 제 코드를 완전 해체하고 조립해주셨습니다. 옆에서..

BIG SUR 평소 온갖 알람이나 빨간 alert 딱지를 두고 보지 못하는 저는 그날도 아무 생각 없이 Big Sur가 나왔기에 그저 업데이트를 했는데... 크게 바뀐 게 없다고 생각했지만 아주 큰 문제가 여러 개 생겨 지금도 내적 눈물을 흘리고 있습니다. 대표적으로는 사용하는 로지텍 G813이 자꾸 캡스락으로 언어 변경을 하려고 하면 5초 정도 멈춰버리는 현상인데 이건 도무지 이유를 모르겠습니다. 타이핑을 하다가 계속 한 템포 쉬어가면서 쉼표의 미학 같은 걸 강제당하는 기분이 듭니다. 하지만 이거보다 더 충격이었던 건 Visual Studio에서 글자 색이 싹 날아가버린 문제였습니다. 테마는 잘 적용이 되고 있는데 그 어떤 파일을 들어가도 모든 글씨 색이 검정색으로 출력되고 있었습니다 (심지어 Hack..

프로젝트 지난 3주에 걸쳐 깃헙의 이슈 탭을 클론 코딩하는 프로젝트를 진행하였습니다. 4명이 함께 작업을 했는데, 이 과정에서 제 자신의 협업 스타일, 학습 태도 등에 대해 다시금 돌아보는 기회가 되어 좋았던 거 같습니다. 리액트도 처음 사용해보았지만 단순히 기술적인 습득만이 아니라, '함께' 프로젝트를 하며 느낀 점을 정리해보고 가면 좋을 거 같아 이렇게 기록으로 남겨보려고 합니다. 컨벤션과 기록 한 가지 큰 아쉬움이 남는 건 후반에 바빠질수록 기록에 소홀해진 부분입니다. 크게는 API 명세서부터 작게는 하루하루의 개발일지까지, 실질적인 구현 일정에 맞춰 진행하다 보니 작성하지 못하고 넘어간 것이 많습니다. 사실 오프라인으로 모여서 바로바로 즉석에서 논의를 하면서 진행하면 기록에 할애하는 시간이 조금 ..

오브젝트 스토리지와 이미지 예전에 이미지 데이터를 관리하는 법과 관련하여 오브젝트 스토리지에 대해 간략하게 알아본 적이 있습니다. 이번 글에서는 이 오브젝트 스토리지에 실제로 이미지 파일을 저장하는 방법에 대해 간단하게 적어보려고 합니다. 선택한 스토리지나 사용하고 있는 프레임워크, 언어에 따라 방법은 조금씩 차이가 있겠지만, 큰 흐름 자체는 동일할 거라고 예상합니다. 사용한 기술 및 환경 서버: node JS / Express JS 오브젝트 스토리지: ncloud 오브젝트 스토리지(S3와 연동) 프론트: 리액트 위의 환경을 기반으로 진행되는 순서는 이렇습니다. 프론트(웹)에서 input을 통해 파일을 업로드 → 해당 파일을 express 서버로 전송 → 서버가 파일을 오브젝트 스토리지로 전송 오브젝트 ..

이미지를 어떻게 관리할 것인가 학습의 목적으로 가볍게 이미지를 관리하던 프로젝트만 진행할 때는 단순하게 서버 쪽에 이미지 파일을 넣어두거나, 온라인에서 이미지 링크만 가져와서 사용했습니다. 하지만 서비스 내에서 유저가 유동적으로 이미지를 선택하고, 이 이미지에 대한 조회가 잦아지는 경우 모든 걸 서버에 넣어두기도 어려울 뿐만 아니라, 이후에 관리가 굉장히 어려워질 수 있습니다. 워낙 DB에 대한 지식이 짧다 보니, 이미지를 어떻게 db에 저장할 것인가에 대해 소소하게 검색을 해봤고 일반적으로 추천하는 방식은 이렇습니다. 이미지의 메타데이터(이미지 업로더, 이미지 제목, 분류 등)는 RDBMS에 저장해둔다. 이때 이미지의 링크를 저장할 칼럼도 함께 만든다. 이미지만을 관리하는 별도의 저장소를 만들어서 이미..

HTTP란? 개발을 공부하기 한참 전부터 웹서핑을 하다 보면 HTTP라는 단어는 심심치않게 목격했던 기억이 납니다. 늘 인터넷 주소 앞에 붙어있었지만, 주소창에서나 잠시 보고 넘길 뿐, 실제로 주소는 www로 시작했다 보니 깊게 생각을 하지 않았던 것 같습니다. 웹 공부를 시작하고나서야 HTTP라는 것의 존재가 확 다가오기 시작했는데, 대충 웹 세계에서의 통신 규약/프로토콜 정도로만 간단하게 이해하고 넘어갔던 것 같습니다. 그런데 막상 생각해보니 누군가 제게 http가 뭐야,라고 물었을 때 '그냥 인터넷 통신 프로토콜 중 하나야' 라고 대답을 할 수는 없지 않나 하는 생각이 들어 한번 정리를 하면 좋겠다는 생각에 다다랐습니다. HTTP는 OSI 7 계층과 TCP/IP를 기준으로는 애플리케이션 레이어 속하..

https://webpack.js.org/ webpack webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset. webpack.js.org 프론트, 즉 어떤 웹 서비스의 클라이언트 영역에 해당하는 부분을 제작하다 보면 소스 파일이 점점 증식하는 것을 체험할 수 있습니다. 간단한 페이지라면 하나의 html, js, css 파일로 끝낼 수 있겠지만 하나의 페이지 안에서도 각각의 부분을 컴포넌트로 쪼개서 작업하는 요즘..

개인화된 서비스를 제작하려고 보면 항상 고민이 생기는 부분이 로그인/회원관리인 것 같습니다. 물론 처음부터 너무 본질적인 부분을 제하고 로그인에만 매몰되면 안 되겠지만, 공부를 하다보면 유저를 먼저 생성하고 그 정보가 어떤 식으로 서버에서 돌아다니는지(?) 알고 시작하는 것이 확실히 흐름을 파악하는 데 도움이 되는 것 같습니다. 기존 방식 기존에는 Oauth, jwt 같이 유저를 서버 차원에서 인증하는 별도의 방식 없이 단순히 db에 저장된 유저명, 비밀번호와 대조해서 로그인을 허용하는 식으로 진행을 해왔습니다. 유저가 계정과 비밀번호를 post로 전달하면, 서버에서 db에 저장된 내용과 일치하면 유저가 로그인 했다는 의미에서 세션에 유저 정보를 추가하고, 이 세션 id를 브라우저의 쿠키에 저장해둡니다...

웹 개발과 관련된 JD를 살펴보면, REST API 제작 경험을 요구하는 경우가 종종 있습니다. 서버가 직접 템플릿을 이용해서 필요한 데이터를 넣은 뒤 화면을 출력해주는 SSR(Server-side Rendering)과 반대된다고 말하기엔 무리가 있지만, 아무래도 사용자가 보는 화면을 누가 담당하느냐의 기준에서 차이가 나기에 서로 비교의 대상이 되는 것 같습니다. 간단하게 생각해서 SSR은 서버가 데이터를 직접 찾아 넣어준다면, REST API는 클라이언트와 서버 쪽이 분리되어 서버는 클라이언트가 필요해서 http 형식으로 요청한 내용을 json 같이 약속된 형태로만 전달하고, 이를 가지고 클라이언트는 별도로 작업을 하여 사용자에게 제공하게 됩니다. RESTful API 사실 REST API를 찾아보면 ..

최근 express를 이용해서 클라우드 서버에 올려둔 MySQL DB와 연결을 시도하던 중, 여러 튜토리얼에서 .env를 활용하여 진행하는 것을 발견하게 되었습니다. 지인을 통해서도 한번 들어보긴 했으나, express를 활용해서 백엔드를 직접 구성해본 경험은 없어서 어떤 용도의 것인지 알아보았습니다. 쉽게 생각하면 민감하고 예민한 정보를 은닉해주는 고마운 친구 정도로 요약이 될 것 같습니다. 민감한 정보란 민감하다, 다른 말로는 타인에게 공개되면 위험한 정보입니다. 단순 데이터일 수도 있겠지만, 만약 계정과 비밀번호 등을 알게 된다면 내가 돈을 내고 쓰는 클라우드 서버에 멋대로 접근할 수도 있게 되는 것이죠. 그래서 github과 같은 공개적인 곳에는 이런 정보가 올라가는 것을 막아야 합니다. 예를 들..