핵심 개념 지도35분
웹 플랫폼 핵심 개념 지도: URL에서 렌더링과 보안까지
웹 개발을 프레임워크 이름으로만 배우면 기술이 바뀔 때마다 지식도 함께 낡아 보입니다. 하지만 브라우저가 주소를 해석하고, 서버와 통신하고, 문서를 파싱하고, 픽셀을 그리는 기본 과정은 훨씬 천천히 바뀝니다. React, Vue, Svelte와 Next.js도 이 과정 위에서 서로 다른 개발 방식을 제공합니다.
웹 개발을 프레임워크 이름으로만 배우면 기술이 바뀔 때마다 지식도 함께 낡아 보입니다. 하지만 브라우저가 주소를 해석하고, 서버와 통신하고, 문서를 파싱하고, 픽셀을 그리는 기본 과정은 훨씬 천천히 바뀝니다. React, Vue, Svelte와 Next.js도 이 과정 위에서 서로 다른 개발 방식을 제공합니다.
클라우드와 DevOps를 제품 목록으로 익히면 비슷한 기능을 가리키는 이름이 계속 늘어납니다. 가상 머신, 컨테이너, 서버리스, CI/CD와 Kubernetes는 같은 층의 대안이 아닙니다. 어떤 것은 실행 환경이고, 어떤 것은 배포 흐름이며, 어떤 것은 원하는 상태를 유지하는 제어 시스템입니다.
컴퓨터 공학을 처음 접하면 자료구조, 운영체제, 네트워크, 데이터베이스가 서로 다른 과목처럼 보입니다. 실제 시스템에서는 이 개념들이 한 요청 안에서 동시에 움직입니다. 사용자가 버튼을 누르면 프로그램의 명령어가 CPU에서 실행되고, 운영체제가 메모리와 소켓을 관리하며, 네트워크 패킷이 서버로 이동하고, 데이터베이스 트…
이 글에서 직접 구현할 LLM 서버는 모델 가중치를 GPU에 올리는 추론 서버가 아닙니다. 여러 외부 또는 내부 모델 엔드포인트 앞에서 인증, 모델 선택, 스트리밍, 장애 처리, 사용량 기록을 담당하는 애플리케이션 계층의 LLM Gateway입니다. 모델 추론 자체는 vLLM 같은 별도 엔진이나 상용 API가 담당한다고…
LiteLLM을 단순한 멀티 모델 호출 라이브러리로만 이해하면 현재 모습의 절반만 보게 됩니다. 출발점은 Python 애플리케이션 안에서 여러 AI 모델 제공자를 같은 방식으로 호출하는 일이었지만, 지금은 조직의 모델 접근을 한곳에서 통제하는 AI Gateway까지 범위가 넓어졌습니다. 이 변화는 이름만 커진 것이 아니…
Vercel은 흔히 "Next.js를 배포하는 곳"으로 알려져 있습니다. 현재의 결합을 보면 자연스러운 설명이지만, 제품의 출발점은 프레임워크 호스팅보다 단순했습니다. 명령어 하나로 애플리케이션을 인터넷에 올리고, 배포마다 고유한 주소를 부여하는 것이 첫 문제였습니다.
EAS를 eas build 명령어의 이름으로만 이해하면 서비스의 절반만 보게 됩니다. EAS는 Expo Application Services의 약자입니다. 소스 코드를 앱 바이너리로 만들고, 스토어에 전달하고, 이미 설치된 앱에 호환되는 업데이트를 보내는 모바일 배포 과정을 여러 서비스로 나눈 플랫폼입니다.
Expo를 설명할 때 가장 자주 붙는 말은 "React Native를 쉽게 쓰게 해 주는 도구"입니다. 틀린 설명은 아니지만 지금의 Expo를 이해하기에는 범위가 너무 좁습니다. Expo는 미리 만들어진 앱에서 JavaScript를 실행하던 초기 경험을 출발점으로 삼았고, 지금은 네이티브 프로젝트 생성과 모듈 개발, 라…
Supabase와 Neon을 처음 보면 둘 다 관리형 PostgreSQL 서비스처럼 보입니다. 실제로 두 서비스 모두 표준 PostgreSQL 연결 방식과 SQL 생태계를 활용합니다. 그래서 기능표만 훑으면 가격과 무료 용량 정도만 비교하게 됩니다.
실시간 소셜 룸은 접속자 목록에 사용자를 추가하고 제거하는 기능만으로 유지되지 않습니다. 모바일 네트워크가 잠시 끊기거나 앱이 백그라운드로 가면 연결 종료 이벤트가 늦게 도착할 수 있고, 재접속한 사용자가 기존 아바타와 별도 참가자로 생성될 수도 있습니다.
Unity 가상공간은 첫 화면에 필요한 UI와 사용자가 입장할 공간의 에셋이 다릅니다. 모든 Scene과 아바타, 텍스처를 시작 시점에 함께 로드하면 진입 시간이 길어지고 사용하지 않는 공간까지 메모리를 차지합니다.
Unity에서 원격 아바타의 위치를 네트워크로 받아 Transform에 바로 적용하면 움직임이 쉽게 끊깁니다. 화면은 매 프레임 렌더링되지만 위치 패킷은 더 낮은 빈도로 도착하고, 각 패킷의 간격도 일정하지 않기 때문입니다.
처음 만들려고 했던 것은 크리스천 작명 앱이었습니다. 이름의 뜻과 신앙적 가치를 함께 살피는 도구를 생각했습니다. 그런데 방향을 구체화할수록 작명의 범위를 한 분야에만 묶을 이유가 없다는 쪽으로 생각이 바뀌었습니다.
커넥티드 카 앱의 차량 상태는 한 번 조회하고 끝나는 데이터가 아닙니다. 도어, 공조, 충전과 차량 온라인 상태는 앱 밖에서도 계속 바뀝니다. 사용자가 원격 명령을 실행하는 동안에도 이전 상태 이벤트와 새로운 조회 응답이 다른 순서로 도착할 수 있습니다.
커넥티드 카 앱에서 도어 잠금이나 공조 시작 버튼을 누르면 요청은 여러 시스템을 통과합니다. 앱이 서버 요청에 성공했다고 차량 기능까지 실행된 것은 아닙니다. 명령이 차량에 도착하고 제어 장치가 결과를 반환해야 비로소 실행 여부를 판단할 수 있습니다.
BLE는 차량과 휴대폰이 가까이 있을 때 작은 데이터를 주고받는 데 적합합니다. 디지털 키, 근거리 도어 제어와 차량 식별처럼 연결 시간이 짧고 배터리 소비를 줄여야 하는 기능에서 자주 사용됩니다.
블록체인 지갑에서 전송 버튼을 누른 뒤 발생하는 일은 단순한 API 요청과 다릅니다. 앱은 사용자의 의도를 트랜잭션 데이터로 만들고, 현재 네트워크 상태에 맞춰 수수료와 nonce를 채우고, 개인키로 서명한 결과를 노드에 전파해야 합니다.
블록체인 지갑의 잔액 화면은 서버 데이터베이스의 한 행을 읽어 보여 주는 화면이 아닙니다. 공개 주소를 기준으로 여러 블록체인 상태를 조회하고, 토큰 단위와 거래 확정 상태를 해석해 만든 하나의 읽기 모델입니다.
블록체인 지갑은 코인을 앱 내부에 보관하지 않습니다. 자산과 거래 기록은 블록체인에 남고, 지갑은 해당 자산을 움직일 수 있는 개인키를 관리합니다. 따라서 지갑 앱의 보안 경계는 화면 잠금이나 API 인증이 아니라 개인키가 생성되고 저장되고 사용되는 전체 과정에 놓입니다.
블로그에는 이미 canonical, sitemap, robots.txt, 글별 Open Graph 이미지, 구조화 데이터가 들어가 있었습니다. RSS와 Atom, JSON Feed도 있었고 관련 글 링크도 붙어 있었습니다. 그래서 처음에는 큰 구멍보다는 메타 설명을 조금 다듬는 정도를 예상했습니다.