핵심 개념 지도22분
애플리케이션 보안 핵심 개념 지도: 위협 모델에서 사고 대응까지
보안 사고는 대개 아무도 모르던 정교한 기법이 아니라, 다들 알고 있었지만 이 자리에는 없을 거라고 생각한 실수에서 시작합니다. 검증하지 않은 입력 하나, 권한 확인을 빠뜨린 엔드포인트 하나, 저장소에 그대로 남은 토큰 하나면 충분합니다. 그래서 보안은 마지막에 붙이는 점검이 아니라 설계할 때 함께 정해지는 성질에 가깝…
보안 사고는 대개 아무도 모르던 정교한 기법이 아니라, 다들 알고 있었지만 이 자리에는 없을 거라고 생각한 실수에서 시작합니다. 검증하지 않은 입력 하나, 권한 확인을 빠뜨린 엔드포인트 하나, 저장소에 그대로 남은 토큰 하나면 충분합니다. 그래서 보안은 마지막에 붙이는 점검이 아니라 설계할 때 함께 정해지는 성질에 가깝…
웹을 만들던 방식 그대로 앱을 만들면 대개 두 지점에서 막힙니다. 하나는 화면이 언제 살아 있고 언제 죽는지 앱이 마음대로 정한다는 것이고, 다른 하나는 만든 것을 바로 내보낼 수 없다는 것입니다. 브라우저에서는 새로고침이 해결하던 문제를 앱에서는 상태 복원과 심사 대기가 대신합니다.
같은 기능을 만드는데 어떤 팀은 이틀에 끝내고 어떤 팀은 두 달을 씁니다. 실력 차이보다는 앞선 결정들이 무엇을 허용하고 무엇을 막아 놓았는지의 차이인 경우가 많습니다. 아키텍처는 화려한 다이어그램이 아니라, 나중에 바꾸기 어려운 결정들의 집합입니다.
새로 만든 서버를 점검하다가 이걸 봤습니다.
하루에 두 번 이 단어들을 만났습니다. 오전에는 터널 설정 화면에서 ingress 를 봤고, 오후에는 데이터베이스 청구 항목에서 egress 를 봤습니다. 몇 년째 둘 다 쓰고 있었는데, 그날에서야 같은 축의 양쪽이라는 게 눈에 들어왔습니다.
데모 사이트 하나가 느렸습니다. 첫 바이트까지 1초가 걸렸습니다. 대시보드를 여는 화면이라 무겁긴 한데, 그래도 1초는 이상했습니다. 앱을 뜯어볼 생각으로 시작했다가, 결국 앱은 한 줄도 안 고쳤습니다.
Vultr와 AWS를 비교하면서 처음에는 같은 vCPU와 메모리를 가진 서버의 월 요금만 표로 만들려고 했습니다. 그런데 이 방식은 시작부터 비교 대상을 잘못 잡은 것이었습니다. Vultr Cloud Compute는 디스크와 전송량이 묶인 VPS형 상품이고, AWS EC2는 컴퓨팅을 중심으로 EBS, 공개 IPv4, 데…
Vultr 인스턴스 생성 화면을 보면 운영체제를 고르는 일이 꽤 단순해 보입니다. 캡처 화면에서도 Operating System과 Ubuntu 26.04 LTS x64가 이미 선택되어 있습니다. 저도 처음에는 최신 LTS가 선택되어 있으니 그대로 진행하면 되겠다고 생각했습니다.
NGINX와 Caddy를 비교해 달라는 요청을 받고 처음 떠올린 답은 단순했습니다. Caddy는 설정이 쉽고 NGINX는 오래되고 강력하다는 구분이었습니다. 공식 문서를 확인하니 이 설명은 방향만 맞고, 2026년의 선택 기준으로 쓰기에는 빠진 내용이 많았습니다.
Neon과 Supabase를 대신할 서비스를 정리해 달라는 질문을 받았습니다. 처음에는 후보를 한 표에 놓고 유명한 순서부터 매기려 했습니다. 공식 문서를 다시 읽어 보니 출발점부터 잘못되었습니다.
Vercel 서울 리전에서 도는 Next.js 앱에 붙일 관리형 Postgres 를 고르는 중이었습니다. 처음에는 두 서비스의 가격표를 나란히 놓고 비교하면 끝날 일이라고 생각했습니다. 실제로는 가격이 아니라, 나중에 되돌릴 수 없는 것들에서 갈렸습니다.
웹 개발을 프레임워크 이름으로만 배우면 기술이 바뀔 때마다 지식도 함께 낡아 보입니다. 하지만 브라우저가 주소를 해석하고, 서버와 통신하고, 문서를 파싱하고, 픽셀을 그리는 기본 과정은 훨씬 천천히 바뀝니다. 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 생태계를 활용합니다. 그래서 기능표만 훑으면 가격과 무료 용량 정도만 비교하게 됩니다.