Operating Systems: Three Easy Pieces - Concurrency: An Introduction

Process vs Thread 멀티 스레드는 단일 Program Counter(PC)와 달리 **각 스레드가 자신만의 Program Counter(PC)와 스택(Stack)**을 가집니다. 이로인해서 멀티 프로세스와 달리 다음 차이점들이 발생합니다. ※ Program Counter(PC): 다음에 실행할 명령어의 주소를 저장하는 레지스터 하나의 프로세스에 두 개의 스레드(T1, T2)가 있다고 가정해보면, T1에서 T2로 넘어갈 때 스레드 간 컨텍스트 스위치가 일어납니다. 이 과정은 프로세스 간 컨텍스트 스위치와 비슷하게 현재 실행 상태를 저장하고 다음 실행 상태를 복원한다는 점에서 유사합니다. ※ Context Switching: CPU/코어에서 실행 중이던 프로세스/스레드가 다른 프로세스/스레드로 교체되는 것 예를 들어, T1의 레지스터 상태를 저장한 뒤 T2를 실행하기 전에 T2의 레지스터 상태를 복원합니다. 프로세스는 이런 상태를 PCB(Process Control Block)로 관리하고, 스레드는 TCB(Thread Control Block)로 관리하는 차이도 있지만 ...

April 28, 2026 · 10 min · DSeung001

Django 6.0 Introduction Summary

서론 해당 글은 Laravel, Spring, Gin 등 다양한 프레임워크를 사용해 본 입장에서 Django를 살펴보며 정리한 메모입니다. Django 6.0 기준으로 Introduction은 다음과 같이 구성되어 있습니다. Django 훑어보기 빠른 설치 가이드 장고 앱 작성하기, part 1 ~ 8 심화 튜토리얼: 재사용 가능한 앱을 만드는 법 다음에 읽을 내용 장고에 처음으로 기여하기 Django 훑어보기 튜토리얼이 아닌 제목 그대로 Django의 동작 방식에 대해 설명하고 있습니다. Model 처음은 모델과 ORM(object-relational mapper)으로 시작하며, Django의 Model을 먼저 보여줍니다. Reporter와 Article로 모델 클래스의 관계를 다음처럼 표현합니다. 파이썬의 __str__ 매직 메서드로 모델 객체의 표시 형태도 지정합니다. ...

April 24, 2026 · 32 min · DSeung001

RFC 6749 — The OAuth 2.0 Authorization Framework

OAuth OAuth 2.0은 인증(Authentication) 자체보다 권한 부여(Authorization) 를 위한 프레임워크입니다. 즉, 제3자 애플리케이션이 리소스 소유자의 비밀번호를 직접 받지 않고도, 제한된 범위(scope)의 접근 권한을 얻도록 설계되었습니다. 네이버/카카오/구글 로그인에서 자주 보이는 흐름도 이 개념을 기반으로 하지만, “로그인(신원 확인)” 자체는 보통 OpenID Connect(OIDC) 같은 상위 프로토콜이 함께 쓰입니다. ※OpenID Connect(OIDC): OAuth 2.0 프로토콜을 기반으로, 웹과 모바일 앱에서 표준화된 방식으로 사용자의 신원을 확인(인증)하는 현대적인 인증 레이어입니다. OAuth가 널리 쓰이기 전에는 제3자 앱이 사용자 자격 증명을 직접 보관/전송하는 방식이 많았고, 이는 과도한 권한 부여와 자격 증명 유출 위험을 키웠습니다. OAuth 2.0은 이 문제를 “비밀번호 공유 없이 위임"하는 모델로 바꿉니다. ...

April 23, 2026 · 7 min · DSeung001

RFC 6454 — The Web Origin Concept

서론 서버가 교차 출처 요청을 아무 기준 없이 허용하면, 민감한 응답 데이터가 의도치 않게 노출될 수 있습니다, 브라우저는 Same-Origin Policy를 기본으로 적용하고, 서버는 CORS 헤더를 통해 특정 Origin에 한해 접근을 허용하는 방식으로 이를 대응합니다. Same-Origin Policy: 웹 브라우저가 보안을 위해 한 출처(Origin)에서 가져온 문서나 스크립트가 다른 출처의 리소스와 상호작용하는 것을 제한하는 핵심 보안 메커니즘 CORS: 브라우저가 다른 도메인(출처)의 서버 자원에 접근할 때, 보안상 제한(동일 출처 정책, SOP)을 해제하고 합법적으로 데이터를 공유하도록 서버가 허가해 주는 HTTP 응답 헤더 기반 메커니즘 Origin의 정의와 직렬화, 그리고 HTTP Origin 헤더를 규정한 RFC 6454를 정리합니다. Origin 개념을 이해하면 다른 출처 접근이 어떤 기준으로 허용/차단되는지, 그리고 이를 통해 서버 자원을 어떻게 보호하는지 명확하게 볼 수 있습니다. ...

April 22, 2026 · 7 min · DSeung001

RFC 9114 — HTTP/3

서론 HTTP/3는 구글에서 QUIC로 개발하였고 22년 6월에 RFC 9114로 표준화되며 HTTP/3로 변경되었습니다, 참고로 HTTP/3의 기반이 되는 QUIC는 새로운 전송 프로토콜로 RFC 9000으로 표준화되었죠. ※QUIC(Quick UDP Internet Connections): UDP 기반의 차세대 전송 프로토콜로, TCP를 쓰지 않아 TCP 수준의 HOL(head-of-line) 블로킹을 줄일 수 있음 HTTP/3의 필요성 QUIC를 사용함으로써 HTTP/2의 가장 큰 단점 몇 가지를 해결할 수 있습니다. 패킷 손실의 영향 감소: TCP는 순서대로 바이트를 넘기려고 해서, 중간에 패킷이 하나만 유실돼도 그 뒤 데이터 전체가 앱에 전달되기 전까지 막힙니다. HTTP/2는 여러 스트림의 프레임이 한 TCP 연결에 실려 보내지기 때문에 이런 막힘이 연결 위의 모든 스트림에 동시에 걸립니다. (TCP 수준의 HOL), QUIC는 스트림마다 손실·재전송을 처리하므로, 한 스트림에서 손실이 나도 다른 스트림이 전부 멈추지는 않습니다. ...

April 20, 2026 · 9 min · DSeung001

RFC 7540 — HTTP/2

서론 HTTP/1에서 HTTP/1.1로 업데이트되면서 많이 바뀌습니다만, 아직 남은 이슈들을 HTTP/2이 개발되었고 여기에는 프레임, 멀티플렉싱 등이 추가되었죠. HTTP/1 문제점들 HTTP/1에서 HTTP/1.1로 업데이트하면서 HTTP Pipelining이 추가되었지만, 이 HTTP Pipelining에서 동시성 문제가 발생했습니다. HTTP Pipelining은 HTTP/1.1에서 응답 순서 보장을 위해 사용되었는데, 이 때문에 요청이 연달아 들어오면 서버는 요청 순서대로 응답해야 하는 특징이 있어 뒤 요청은 대기 상태가 되는 문제가 생깁니다. 즉 HOL(head of line blocking) 문제가 발생하죠. HOL 문제는 HTTP/1.1 파이프라인에서 응답 순서가 보장되기 때문에, 응답이 크거나 느릴 때 뒤 응답이 대기되는 문제인데 HTTP 파이프라인에서는 응답을 순서대로 처리하다 보니 불가피하게 블로킹이 발생했습니다. ...

April 18, 2026 · 16 min · DSeung001

CMS 기능 Digging

0. 개요 CMS는 대부분의 개발자가 가장 먼저 접하는 친숙한 구조입니다. CRUD를 기반으로 한 패턴으로 어떤 기술을 배우든 자연스럽게 마주하게 되죠. 라프텔, 넷플릭스, 네이버 쇼핑, 다음 웹툰, 링크드인까지 우리가 쓰는 대부분의 서비스도 사실상 CMS의 확장 버전이라 볼 수 있습니다. 가장 단순해 보이지만, 그만큼 끝 없이 파고들 수 있는 구조로 그동안 당연하게 써왔지만 정리를 해본 적이 없었네요. 이번에 처음으로 쭉 정리해봤습니다, 부족한 점이 있다면 가감 없이 피드백 부탁 드려요 1. 콘텐츠 CRUD 1.1 생성 (Create) SEO용 slug 자동 생성 (핵심 키워드, stop word 제거, 소문자 사용, 특수문자 제거) XSS, SQL Injection 검증 캐시 데이터에 추가 스케줄링 처리: 작은 작업은 cron을, 대용량은 메시지 큐(Kafka, BullMQ)를 사용하여 백그라운드 작업 자동화 테스트: CRUD API가 정상적으로 작동하는 지를 CI/CD 파이프라인에 포함하여 매번 체크 다양한 플랫폼 지원: 부 모바일/TV 앱이 동일 API 사용 가능 형태로 설계 요금제 플랜: Redis를 이용해서 계정마다 현재 접속 수 체크해서 요금제 플랜에 맞게 관리 모니터링: 업로드 실패율, 렌더링 지연, 승인 리뷰 대기 시간, 서버 리소스 등 수치 트래킹 sentry: 모니터링 도구로 실시간 에러 트래킹과 프론트, 백엔드에서 발생하는 예외, 로그, 버그 정보를 수집하여 UI로 시각화 해줌 datadog: 서버, 애플리케이션, 로그, 메트릭, 인프라를 통합 모니터링 툴로 sentry보다 범용적이며 DevOps에서 많이 사용됨 리소스 파일 업로드: 리소스 파일들을 Multipart Upload Protection, 즉 chunk 단위로 업로드해서 악성파일, 과도한 용량문제 해결, 보안 룰 적용 (확장자, MIME 타입, 바이러스 검사) API 문서화: drf-spectacular 같은 걸로 자동 문서화 1.2 읽기 (Read) 상태, 태그와 같은 조건에 따라 필터링된 대용량 데이터에 대한 쿼리 캐시 지원 공개된 데이터는 Redis / Memcached로 select list를 캐싱 변경시는 수동으로 캐시를 지우거나 TTL이 짧다면 자동 갱신 비디오/이미지/정적 리소스는 CDN으로 읽기 비용 감소 발행이 Draft로 콘텐츠여도 미리보기 링크로 확인 가능 1.3 수정 (Update) 업데이트 충돌 방지를 위해, Optimistic Concurrency로 글을 수정을 진행할 때와 가져온 글 버전과 저장할 떄 글 버전이 같아야 함 slug나 파일 링크 변경시 유효한지 검사 변경전 슬러그도 지원하기 위한 alias 기능 콘텐츠 변경시 이전 버전들을 저장해서 글의 버전 관리 비디오 파일이 바뀌면 자동으로 썸네일 재생성 콘텐츠가 업데이트되면 관련 select 캐시나 cdn 캐시 데이터 수정 콘텐츠 수정 시 어떤 Text가 바뀐지를 Diff 뷰로 보여줌 1.4 삭제 (Delete) Deleted At 또는 Disabled로 soft 삭제를 하고, 추후에 관리자나 유저가 DB에서 완전 삭제후 자동 purge soft 삭제로 db 리소스 접근을 최소 화하는 방법으로 좋아요나 이모지 같이 사용자가 장난 칠 수 있는 기능에 적합 연관 데이터, 댓글, 조회수/통계 테이블, 썸네일, 원본 정적 리소스 파일간의 관계 제거 soft 삭제의 경우 복원 가능 누가, 언제, 어떻게 삭제했는 지를 기록 삭제된 콘텐츠로 접근 시 301로 리디렉트하거나 404로 반환 2. 콘텐츠 관리 2.1 콘텐츠 상태 관리 발행 관리: Draft, Published, Scheduled 시간 관리: Updated At, Created At 2.2 동영상 콘텐츠 실시간 방송 스트리밍 (단방향 실시간 통신) 장르, 태그, 시리즈, 년도(분기), 현재 방영 여부, 출시타입(TAV,극장판 OVA)로 영상 콘텐츠 분리 현재 방영 작은 요일별 신작으로 확인 가능하게 분리 원할한 스트리밍 서비스를 위한 캐싱이나 인코딩 처리 필요 2.3 콘텐츠 일정 설정 예약 게시일 등록 콘텐츠에 유효기간이 있다면 만료일도 등록 2.4 팀 기반 콘텐츠 작성자 관리 (PD, 편집자, 운영자) 권한별로 접근할 수 있는 메뉴, 페이지 분리 3. 데이터 보안 3.1 데이터 암호화 암호화 대상: 개인정보 (주민등록번호, 이름, 이메일, 비밀번호 등) 암호화 방법 대칭키 암호화: 암복호화에 같은 키 사용, 빠르고 효율적 대상: 이메일, 주소, 이름 등 자주 조회 및 수정이 필요한 데이터 암호화: AES-256, AES-GCM 비대칭키 암호화: 공개키로 암호화, 개인키로 복호화하고 느리지만 공개 키 배포 가능 대상: 민감한 서명, 토큰, 공개키 기반 인증 구조 (JWT, OAuth, SSH 등) 암호화: RSA 비밀번호는 복호화가 불가능한 해시 알고리즘 채택 (bcrypt, scrypt) 암호화 레이어 별 특징 애플리케이션 레벨: 코드에서 작업하므로 필드 단위로 세밀한 제어가 되지만 코드의 복잡잡도 증가 DB 레벨 (TDE): 전체 테이블/디스크를 설정만으로 암호화가 되지만 필드 제어가 불가능하고 느림 하이브리드: 민감한 데이터는 앱단에서 나머지는 TDE로 진행하면 성능과 보안의 밸런스를 조절할 수 있지만 설정에 복잡도 증가 키 관리: 암호화 키는 별도의 키 시스템으로 관리 ex: AWS KMS 참고 사항: 암호화된 데이터는 로그에 찍으면 안됨 잦은 검색 조건이 있는 건 인덱스 때문에 암호화 지양하고 민간함 정보만 암호화화 환경에 맞게 코드 컨밴션 툴 사용해서 코드 스타일 유지 Python의 black, PEP8 스타일 가이드 준수 Python의 isort, import 정렬기로 black과 같이 사용 4. 동영상 업로드 및 변환 4.1 동영상 업로드 시나리오 업로드 → 인코딩 → 썸네일 생성 → 배포 4.2 인코딩 포맷 MP4: 범용 포멧으로 대부분의 브라우저에서 지원하지만 스트리밍에서 성능이 제한적 HLS(HTTP Live Streaming): Apple 주도로 ios 친화적 스트리밍에 적합하고 현재는 다양한 장치에서 지원 DASH (MPEG-DASH): MPEG 표준, 크롬/안드로이드 친화적이고 유연한 확장성 제공 보통 두 가지 스트리밍 포맷(HLS & DASH)을 생성하고 클라이언트에서 상황에 맞춰 제공 4.3 Resumable Upload (중단 후 다시 업로드) tus(open protocol, 업로드 중단/복원 대응 강력), multipart upload, chunked upload 방식 사용 AWS S3 multipart upload도 해당 기능을 제공하니 클라우드를 활용 클라이언트에서 chunk 관리를 위해 JS 기반 상태 저장 로직 필요 4.4 자동 해상도 변환 (240p~4K) 하나의 동영상을 다양한 해상도 변환해서 저장 (360p, 480p, 720p, 1080p, 1440p, 4K) 자동 트랜스코딩 워크플로우는 큐 기반으로 비동기 처리 4.5 썸네일 자동 생성 프레임 수 기준 중간 지점이나 가장 밝은 장면 등 다양한 조건으로 썸네일 생성 AI 기반 썸네일 추출 기능 관리자 수동 업로드도 지원 4.6 FFmpeg + Redis + Worker 기반 트랜스코딩 큐 업로드된 파일은 곧바로 트랜스코딩하지 않고 큐에 등록 후 비동기 처리 ...

August 1, 2025 · 13 min · DSeung001