최영선의 블로그

시리즈를 따라오며 웹의 흐름, 브라우저, HTTP, Frontend와 Backend, 인증, 데이터베이스, 배포, 성능까지 각각 따로 보았습니다. 이제는 이 조각들을 하나의 앱 안에 묶어 볼 차례입니다. 지식은 작은 결과물을 직접 만들어 볼 때 비로소 자기 것이 됩니다.여기서는 Todo 앱 하나를 만들면서 HTML, Flask, SQLite, 환경 변수, 헬스 체크, 컨테이너 실행까지 한 흐름으로 연결하겠습니다.먼저 던지는 질문앞선 아홉 개 개념은 한 앱 안에서 어떻게 연결될까요?작은 풀스택 프로젝트는 어떤 폴더 구조로 시작하면 좋을까요?Frontend, Backend, 데이터베이스는 어떤 API 계약으로 묶일까요?왜 마지막 글이 중요한가개념을 따로 아는 것과 하나의 제품 흐름으로 엮어 보는 것은 다릅니..

서비스가 느리다는 말은 흔하지만, 어디가 느린지는 생각보다 자주 흐립니다. 서버가 느린지, 브라우저가 느린지, 이미지가 큰지, 데이터베이스 조회가 많은지, 캐시가 전혀 없는지 구분하지 않으면 최적화는 방향을 잃습니다. 성능은 감각보다 측정과 구조가 먼저입니다.여기서는 측정의 출발점, HTTP 캐시와 CDN, lazy loading과 code splitting, 데이터베이스 인덱스와 N+1 문제를 함께 보며 느린 웹앱을 빠르게 만드는 기본 원칙을 정리하겠습니다.먼저 던지는 질문느린 페이지를 만나면 어디서부터 봐야 할까요?브라우저 캐시와 CDN은 각각 어떤 역할을 할까요?lazy loading은 무엇을 늦추고 왜 유용할까요?왜 성능은 측정부터 시작하는가빠른 사이트는 사용자 만족뿐 아니라 전환율, 검색 순위,..

로컬에서 잘 돌아가는 앱을 세상에 보여 주는 순간부터 개발은 운영과 연결됩니다. 내 노트북에서는 되는데 서버에서는 안 되는 이유, 환경별 설정이 왜 갈리는지, 비밀 값은 어디에 둬야 하는지, 같은 코드를 어떻게 반복 가능하게 배포할지 모두 배포에서 드러납니다.여기서는 환경 분리, 환경 변수와 비밀 관리, 빌드 산출물, PaaS와 IaaS의 차이, 그리고 기본적인 CI/CD 흐름을 함께 정리하겠습니다.먼저 던지는 질문노트북에서만 돌던 앱을 어떻게 운영 환경으로 옮길까요?개발, 스테이징, 운영 환경은 왜 나눌까요?환경 변수와 비밀 값은 왜 저장소 바깥에서 관리할까요?왜 배포를 따로 배워야 하는가수동 배포는 자주 사고를 냅니다. 누가 어느 서버에 어떤 파일을 복사했는지 남지 않고, 테스트를 건너뛰기 쉽고, 롤..

웹앱은 화면만으로 끝나지 않습니다. 사용자 정보, 게시글, 주문, 결제 기록처럼 남아야 하는 데이터는 결국 데이터베이스에 들어갑니다. 서버가 메모리만 믿고 있으면 프로세스가 재시작되는 순간 상태가 사라집니다. 그래서 웹앱에서 데이터베이스 연결은 거의 항상 핵심 경로입니다.여기서는 SQL의 기본 작업, ORM의 역할, 연결과 연결 풀, 트랜잭션이 왜 필요한지 정리하면서 웹앱이 데이터를 오래 보관하는 방식을 봅니다.먼저 던지는 질문웹앱은 왜 파일이 아니라 데이터베이스를 쓸까요?SQL의 네 가지 기본 작업은 무엇일까요?ORM은 어디서 편하고 어디서 한계가 생길까요?왜 이 주제가 중요한가웹앱의 거의 모든 상태는 데이터베이스에 있습니다. 사용자 수가 조금만 늘어나도 연결을 잘못 다루는 서버는 금방 느려지거나 멈춥..

이 글은 Web Development 101 시리즈의 여섯 번째 글입니다.HTTP는 상태를 기억하지 않는 프로토콜입니다. 요청 하나가 끝나면 서버는 다음 요청이 같은 사용자인지 자동으로 알지 못합니다. 그런데 실제 서비스는 로그인 상태, 권한, 장바구니, 내 정보 같은 사용자 맥락을 계속 이어 가야 합니다. 이 간극을 메우는 도구가 인증과 세션입니다.여기서는 인증과 인가의 차이, 쿠키와 세션의 동작 방식, JWT와 OAuth의 역할, 그리고 자주 놓치는 보안 기본기를 함께 정리하겠습니다.먼저 던지는 질문인증과 인가는 무엇이 다를까요?상태가 없는 HTTP 위에서 서버는 사용자를 어떻게 기억할까요?쿠키와 세션은 어떤 식으로 맞물릴까요?왜 이 주제가 중요한가거의 모든 앱에는 로그인 기능이 들어갑니다. 여기가 ..

웹 개발을 배우다 보면 Frontend와 Backend를 서로 다른 기술 묶음처럼만 보기 쉽습니다. 하지만 실무에서 더 중요한 것은 도구 이름이 아니라 책임 경계입니다. 누가 데이터를 보여 주고, 누가 저장하고, 누가 권한을 검증하는지 구분되지 않으면 작은 서비스도 금방 지저분해집니다.여기서는 Frontend와 Backend의 역할을 나눠 보고, SPA와 SSR이 어떤 차이를 가지는지, 두 세계를 잇는 API 계약이 왜 중요한지 정리하겠습니다.먼저 던지는 질문Frontend와 Backend의 일은 어디서 갈릴까요?데이터의 진실은 어느 쪽이 가져야 할까요?SPA와 SSR은 무엇이 다를까요?왜 이 경계가 중요한가한 사람이 양쪽 코드를 모두 짜더라도 책임 경계가 흐려지면 코드가 빠르게 무너집니다. Fronte..

웹 개발을 하다 보면 결국 가장 많이 읽고 쓰는 것은 HTTP 메시지입니다. 브라우저가 페이지를 요청할 때도, JavaScript가 JSON 데이터를 가져올 때도, 모바일 앱이 서버와 통신할 때도 바닥에는 HTTP가 놓여 있습니다. 요청과 응답의 모양을 정확히 모르면 디버깅은 금방 추측 게임으로 바뀝니다.여기서는 HTTP 요청과 응답이 어떤 형태를 가지는지, method와 status code와 header가 각각 어떤 의미를 가지는지, API 호출이 페이지 요청과 무엇이 다른지 정리하겠습니다.먼저 던지는 질문클라이언트와 서버는 실제로 무엇을 주고받을까요?HTTP 요청과 응답은 어떤 요소로 구성될까요?GET, POST, PUT, DELETE는 각각 어떤 의미일까요?왜 이 구조를 알아야 하는가웹 개발의 절..

브라우저는 HTML 파일을 그대로 화면에 붙이지 않습니다. 텍스트를 읽고 구조를 만들고, 스타일을 계산하고, 위치를 정하고, 픽셀을 그린 뒤에야 우리가 보는 페이지가 완성됩니다. 여기에 JavaScript의 이벤트 처리까지 얹히면 비로소 클릭 가능한 화면이 됩니다.여기서는 브라우저가 HTML을 DOM으로 바꾸고, 렌더링 파이프라인과 이벤트 루프를 통해 살아 있는 화면을 만드는 과정을 정리하겠습니다.먼저 던지는 질문DOM은 정확히 무엇이며 어떻게 만들어질까요?브라우저 렌더링 파이프라인은 어떤 단계로 이어질까요?JavaScript는 DOM을 어떻게 읽고 바꿀까요?왜 이 모델이 중요한가DOM에 대한 감각이 없으면 페이지가 왜 느린지 설명하기 어렵습니다. HTML, CSS, JavaScript가 모두 정상처럼 ..

웹 페이지를 처음 만들 때는 세 언어가 왜 따로 존재하는지 잘 와닿지 않습니다. 화면 하나를 만들 뿐인데 구조용 언어, 스타일용 언어, 동작용 언어가 따로 있다는 사실이 오히려 번거롭게 보이기도 합니다. 하지만 규모가 조금만 커져도 이 분리가 왜 중요한지 금방 드러납니다.여기서는 HTML, CSS, JavaScript가 각각 무엇을 맡고, 왜 세 층을 분리하는 편이 유지보수와 협업에 유리한지 정리하겠습니다.먼저 던지는 질문웹 페이지는 왜 세 가지 언어로 나뉠까요?HTML, CSS, JavaScript는 각각 무엇을 책임질까요?세 언어가 함께 동작할 때 어떤 연결 지점이 생길까요?왜 이 구분이 중요한가세 언어가 한 파일 안에서 뒤엉키면 한 줄을 고칠 때마다 다른 영역이 흔들립니다. 디자인 수정이 동작 버그..

웹 개발을 처음 배울 때는 HTML, CSS, JavaScript, API 같은 단어가 따로따로 보입니다. 그런데 장애를 잡거나 성능 문제를 읽으려면 이 조각들을 하나의 흐름으로 묶어 이해해야 합니다. 주소창에 URL을 넣고 Enter를 누른 뒤 화면이 보이기까지, 실제로 어떤 단계가 지나가는지 머릿속에 그려져야 합니다.여기서는 브라우저, DNS, HTTP, 서버, 렌더링이 어떤 순서로 맞물리는지 전체 지도를 먼저 잡겠습니다.먼저 던지는 질문URL을 입력한 뒤 화면이 보일 때까지 어떤 단계가 지나갈까요?DNS와 HTTP는 각각 어떤 역할을 맡을까요?서버가 응답을 보내면 브라우저는 그 데이터를 어떻게 화면으로 바꿀까요?왜 이 흐름이 중요한가웹 개발자는 전체 그림을 알아야 합니다. 한 층만 잘 알아도 기능은..