HTTPS를 처음 켜본 사람이라면 한 번쯤 같은 장면을 거칩니다. 인증서를 사려고 검색하다 보니 1년에 몇 만 원짜리부터 수십만 원짜리까지 등급이 나뉘어 있고, 어떤 걸 골라야 할지부터 막막한데요. 사이드 프로젝트 하나 띄워보자고 비싼 인증서를 사기는 부담스럽지만, HTTP로 두자니 브라우저가 "안전하지 않음"이라고 경고를 띄웁니다. 이 진입 장벽을 거의 무너뜨린 것이 Let's Encrypt입니다. ISRG(Internet Security Research Group)라는 비영리 단체가 운영하는 무료 인증 기관인데, 발급 절차를 자
웹 API를 호출하거나 외부 서비스와 통신해야 하는 상황은 어떤 언어로 개발하든 빈번하게 마주치게 됩니다. Rust에서는 이런 HTTP 통신을 위해 reqwest라는 크레이트가 사실상 표준처럼 사용되고 있는데요. Python의 requests 라이브러리처럼 직관적인 API를 제공하면서도 Rust답게 타입 안전성과 비동기 처리를 지원하는 것이 특징입니다. 이 글에서는 reqwest 크레이트의 기본적인 사용법부터 실무에서 자주 쓰이는 패턴까지 예제와 함께 살펴보겠습니다. reqwest란? reqwest는 Rust 생태계에서 가장 널리
웹 개발을 하다 보면 한 가지 의문이 드는 순간이 있습니다. 버튼 하나 클릭했을 때 서버에서 데이터 받아와서 화면 일부만 바꾸고 싶은데, 꼭 React나 Vue 같은 프레임워크를 써야 할까? 간단한 검색 폼이나 좋아요 버튼 하나 만드는데 JavaScript를 수십 줄씩 작성하는 게 과연 맞는 걸까? 이런 고민은 사실 꽤 오래전부터 있었어요. SPA(Single Page Application)가 대세가 되면서 JavaScript 코드는 점점 늘어났고 빌드 도구도 복잡해졌고 번들 크기도 커졌죠. 그런데 정작 만들고 싶었던 건 "클릭하면
웹 개발자라면 200, 404, 500과 같은 HTTP 상태 코드에 대해 한 번쯤은 들어보셨을텐데요. 경험을 통해서 이렇게 자주 보이는 코드에 대해서 막연히 감은 있으시지만, 실제로 내가 HTTP 상태 코드에 대해서 잘 알고 있는지에 대해서 스스로 의문이 들 때가 있으실 것입니다. 혹시 HTTP 메시지 구조나 버전 변천이 궁금하다면 HTTP 한눈에 보기에서 큰 그림을 먼저 살펴보시는 것도 좋습니다. 특히 백엔드 개발자라면 요즘에 웹이나 Rest API 개발을 간편하게 해주는 프레임워크가 워낙 잘 나와있다보니, 어떤 상태 코드를 응답
“사용자 인증을 할 때 쿠키를 사용하면 위험하고요 서버에 데이터를 저장하는 세션을 사용하는 것이 안전해요.” 사용자 인증에 대해서 논할 때 자주 듣게 되는 얘기인데요. 과연 이 말이 맞는 말일까요? 저한테는 굉장히 모순된 얘기로 들리는 것 같습니다. 많은 분들이 쿠키(cookie)와 세션(session)을 서로 대립하거나 세션이 쿠키를 대체하는 기술로 오해하는 것 같은데요. 사실 쿠키와 세션은 상호 보완을 하는 기술이라고 보는 것이 더 맞을 것입니다. 지난 포스팅에서는 서버가 브라우저에 쿠키를 어떻게 저장하고 쿠키라는 기술의 한계에
"쿠키는 클라이언트에 저장되고... 음,,, 보안에 좋지 않습니다." 😅 개발자 면접을 볼 때 쿠키에 대해서 물어보면 가장 흔하게 들을 수 있는 대답인데요. 완전히 틀린 말은 아니지만 뭔가 알맹이가 빠진 느낌이 듭니다. 쿠키가 왜 등장했는지를 이해하려면 HTTP가 무상태(stateless) 프로토콜이라는 점을 먼저 떠올려보면 좋습니다. "그럼 보안을 위해서 쿠키는 안 쓰는 게 좋겠네요?" 라고 반문을 하면 오랫동안 웹 개발을 한 분들도 머뭇거리시는 경우가 많은데요. 아무래도 대부분의 서버 프레임워크에서 쿠키를 직접 다루지 않아도
requests는 파이썬으로 HTTP 통신이 필요한 프로그램을 작성할 때 가장 많이 사용되는 라이브러리입니다. 특히 원격에 있는 API를 호출할 때 유용하게 사용할 수 있는데요. 이번 포스팅에서는 requests 라이브러리를 사용하는 방법에 대해서 알아보겠습니다. 패키지 설치 파이썬의 패키지 매니저인 pip를 이용해서 requests 패키지을 설치합니다. 설치가 잘 되었는지 파이썬 인터프리터를 실행하여 확인해봅니다. requests 라이브러리로 구글에 접속을 해보니 상태 코드 200이 응답이 되는 것을 볼 수 있습니다. 🎉 API
JavaScript, API, Markup를 근간으로 하는 JAM stack이 모던 웹 개발의 새로운 트랜드가 되고 있습니다. 이에 따라, 예전처럼 서버 단에서 대신 API를 호출해주기 보다는 클라이언트 단에서 직접 API를 호출하는 경우가 많아지고 있습니다. (이렇게 브라우저에서 직접 비동기로 HTTP 통신을 하는 것을 한 때 소위 Ajax라고도 일컬었죠...) 이번 포스팅에서는 원격 API를 간편하게 호출할 수 있도록 브라우저에서 제공하는 fetch() 함수에 대해서 살펴보겠습니다. 라이브러리? 원격 API 호출하면 제일 먼저
웹 페이지를 두 번째 열 때 첫 번째보다 훨씬 빨리 그려지는 경험을 한 번쯤 해보셨을 겁니다. 어딘가에서 그 자원을 미리 들고 있다가 다시 꺼내준 결과인데, 이 "미리 들고 있다"가 곧 캐시이고요. 브라우저, 회사 프록시, CDN, 원본 서버 앞 모두 캐시가 자리할 수 있어 한 자원이 여러 곳에 사본을 가질 수 있는 셈입니다. 문제는 이렇게 흩어진 캐시들이 서로 다른 규칙으로 동작하면 곤란하다는 점입니다. 한 캐시는 1시간을 보관하고 다른 캐시는 영원히 보관하는 식이면 운영자가 원하는 정책을 만들 수가 없죠. 그래서 HTTP는 모든
로컬에서 혼자 웹 앱을 개발하던 사람이 회사 운영 환경을 처음 만지면 꼭 듣게 되는 말이 있어요. "앞단에 nginx를 둘 거예요"라든지, "프록시 통해서 바깥으로 나가야 해요" 같은 문장인데요. 두 쪽 다 "프록시"라는 단어가 들어가는데, 가리키는 대상이 아예 반대입니다. 앞의 것은 리버스 프록시, 뒤의 것은 포워드 프록시예요. 이 글에서는 두 프록시가 어떻게 다른지, 왜 같은 이름을 쓰면서 역할은 서로 반대인지, 실무에서 어디에 어떻게 배치되는지를 차근차근 풀어보려 합니다. 프록시가 대체 뭐였죠? 프록시(proxy)라는 단어는
웹 개발을 하다 보면 브라우저 개발자 도구에서 HTTP 요청 헤더를 뜯어볼 일이 종종 있잖아요? 그때 Host, Origin, Referer... 이 세 녀석이 나란히 있는 걸 보면 "이거 다 비슷한 거 아닌가?" 싶을 때가 있는데요. 헤더 자체가 처음이라면 HTTP 메시지가 어떻게 생겼는지부터 보고 오시면 흐름이 더 잘 잡힙니다. 셋 다 URL이나 도메인 정보를 담고 있으니까 대충 같은 역할처럼 보이거든요. 그런데 막상 CORS 문제를 디버깅하거나 보안 설정을 건드려야 할 때 이 헤더들의 차이를 정확히 모르면 삽질을 피할 수가 없
처음 웹 서버를 돌릴 때는 한 대만 잘 띄워 두면 충분합니다. 그런데 사용자가 늘고 트래픽이 점점 무거워지면, 어느 순간 한 대로는 감당이 안 되는 시점이 옵니다. 사양을 키우는 방법(스케일 업)도 있지만, 한 대를 더 띄워서 일을 나누어 시키는 방법(스케일 아웃)이 더 자연스러운 선택일 때가 많은데요. 이 분산을 책임지는 도구가 로드 밸런서입니다. 이름 그대로 트래픽이라는 부하를 여러 서버에 나눠 주는 장치인데, 막상 들여다보면 "어떤 기준으로 나누느냐", "어느 계층에서 동작하느냐", "한 대가 죽으면 어떻게 알아채느냐"처럼 결
브라우저 주소창에 작은 자물쇠 아이콘이 켜져 있으면 우리는 별다른 의심 없이 정보를 입력합니다. 비밀번호를 치고, 카드 번호를 넣고, 메시지를 보내는데요. 이 자물쇠 한 칸이 사실은 HTTP 위에 한 겹의 보호막을 덧씌운 결과인 셈입니다. HTTPS는 이름에서도 짐작되듯 HTTP에 보안(Secure)을 보탠 형태입니다. 정확히 말하면 HTTP를 TLS라는 암호 통신 위에서 흘려보내는 구조인데요. 이번 글에서는 평문 HTTP가 왜 위험한지, TLS가 그 위에 무엇을 더하는지, 그리고 우리가 평소에 보는 인증서와 자물쇠가 어떻게 신뢰를
웹 페이지 하나를 여는 일을 한 줄로 요약하면 "브라우저가 서버한테 뭔가 달라고 부탁하고, 서버가 그걸 보내준다"입니다. 이 단순한 부탁을 둘 사이에서 약속된 모양으로 주고받게 만든 것이 HTTP입니다. 이름이 길어 보이지만 풀어보면 HyperText Transfer Protocol, "문서를 주고받기 위한 약속" 정도로 옮길 수 있죠. 그런데 한 가지 호기심이 생깁니다. 이렇게 단순한 약속이 오랫동안 살아남으면서, 뒷자리 숫자만 1.0에서 1.1, 2, 3까지 바뀌어 왔다는 점이죠. 같은 이름을 달고도 토대를 TCP에서 UDP로