Process vs Thread 멀티 스레드는 하나의 Program Counter(PC)만 갖는 단일 스레드와 달리 각 스레드가 자신만의 Program Counter(PC)와 스택(Stack) 을 가집니다. 이로 인해 멀티 프로세스와 달리 다음 차이점들이 발생합니다. ※ Program Counter(PC): 다음에 실행할 명령어의 주소를 저장하는 레지스터 하나의 프로세스에 두 개의 스레드(T1, T2)가 있다고 가정해보면, T1에서 T2로 넘어갈 때 스레드 간 컨텍스트 스위치가 일어납니다. 이 과정은 프로세스 간 컨텍스트 스위치와 비슷하게 현재 실행 상태를 저장하고 다음 실행 상태를 복원한다는 점에서 유사합니다. ...
서론 해당 글은 Laravel, Spring, Gin 등 다양한 프레임워크를 사용해 본 입장에서 Django를 살펴보며 정리한 메모입니다. Django 6.0 기준으로 Introduction은 다음과 같이 구성되어 있습니다. Django 훑어보기 빠른 설치 가이드 장고 앱 작성하기, part 1 ~ 8 심화 튜토리얼: 재사용 가능한 앱을 만드는 법 다음에 읽을 내용 장고에 처음으로 기여하기 Django 훑어보기 튜토리얼이 아닌 제목 그대로 Django의 동작 방식에 대해 설명하고 있습니다. Model 처음은 모델과 ORM(object-relational mapper)으로 시작하며, Django의 Model을 먼저 보여줍니다. Reporter와 Article로 모델 클래스의 관계를 다음처럼 표현합니다. 파이썬의 __str__ 매직 메서드로 모델 객체의 표시 형태도 지정합니다. ...
OAuth OAuth 2.0은 인증(Authentication) 자체보다 권한 부여(Authorization) 를 위한 프레임워크입니다. 즉, 제3자 애플리케이션이 리소스 소유자의 비밀번호를 직접 받지 않고도, 제한된 범위(scope)의 접근 권한을 얻도록 설계되었습니다. 네이버/카카오/구글 로그인에서 자주 보이는 흐름도 이 개념을 기반으로 하지만, “로그인(신원 확인)” 자체는 보통 OpenID Connect(OIDC) 같은 상위 프로토콜이 함께 쓰입니다. ※OpenID Connect(OIDC): OAuth 2.0 프로토콜을 기반으로, 웹과 모바일 앱에서 표준화된 방식으로 사용자의 신원을 확인(인증)하는 현대적인 인증 레이어입니다. OAuth가 널리 쓰이기 전에는 제3자 앱이 사용자 자격 증명을 직접 보관/전송하는 방식이 많았고, 이는 과도한 권한 부여와 자격 증명 유출 위험을 키웠습니다. OAuth 2.0은 이 문제를 “비밀번호 공유 없이 위임"하는 모델로 바꿉니다. ...
서론 서버가 교차 출처 요청을 아무 기준 없이 허용하면, 민감한 응답 데이터가 의도치 않게 노출될 수 있습니다, 브라우저는 Same-Origin Policy를 기본으로 적용하고, 서버는 CORS 헤더를 통해 특정 Origin에 한해 접근을 허용하는 방식으로 이를 대응합니다. Same-Origin Policy: 웹 브라우저가 보안을 위해 한 출처(Origin)에서 가져온 문서나 스크립트가 다른 출처의 리소스와 상호작용하는 것을 제한하는 핵심 보안 메커니즘 CORS: 브라우저가 다른 도메인(출처)의 서버 자원에 접근할 때, 보안상 제한(동일 출처 정책, SOP)을 해제하고 합법적으로 데이터를 공유하도록 서버가 허가해 주는 HTTP 응답 헤더 기반 메커니즘 Origin의 정의와 직렬화, 그리고 HTTP Origin 헤더를 규정한 RFC 6454를 정리합니다. Origin 개념을 이해하면 다른 출처 접근이 어떤 기준으로 허용/차단되는지, 그리고 이를 통해 서버 자원을 어떻게 보호하는지 명확하게 볼 수 있습니다. ...
서론 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는 스트림마다 손실·재전송을 처리하므로, 한 스트림에서 손실이 나도 다른 스트림이 전부 멈추지는 않습니다. ...
서론 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 파이프라인에서는 응답을 순서대로 처리하다 보니 불가피하게 블로킹이 발생했습니다. ...
개요 1-1. Go 동시성, 정말 장점일까? - 주요 언어 성능 비교 GoLang의 사용처를 묻는 질문이 들어온다면 블록체인, 게임서버, 네트워크, 실시간 데이터 처리, 고성능 API 등 중에서 아마 대답이 나올 겁니다. 결국 고루틴(goroutine) 기반의 강력한 동시성을 GoLang의 핵심으로 보고 이를 장점으로 이야기 하는 것이죠. 이는 GoLang에 대해 공부하면 경량화된 쓰레드 자체 특징에 더해 채널, 락관리 등도 매우 편리하게 할 수 있는 걸 알고 있죠. 하지만 한 번더 꼬리물기 질문을 한다면? 진짜 이게 장점일까? 다른 언어에 비해 월등히 좋을까? Rust도 좋다고들 하던데 Rust 보다도 좋을까? Python은 느리다던데 유의미한 퍼포먼스 차이가 있을까? 이런 질문들에 대해서는 실제로 해본적은 없으니 “메모리 사용량은 약간 적고 실행 속도는 더 빠를 것”이라는 막연한 생각만이 떠오릅니다. 그래서 이번 포스트는 여러 언어들에서 동시성 로직을 다룰 때 무슨 특징들이 있는 지를 다뤄볼겁니다. ...
Gophercon 2025 올해 처음으로 고퍼콘에 참여하여 여러 세션을 들으며 다양한 인사이트를 얻을 수 있었습니다. 웰컴 티셔츠도 무료로 주셔서 감사한 마음으로 받고 관련 굳즈들(후드티, 뱃지, 키캡)과 스티커들을 왕창 얻을 수 있었네요. Gophercon 2025 세션은 다음과 같았어요 Go 로 만든 AI 주식 추천 및 자동매매 시스템 동시통역 Go로 만들기 - 실시간 AI 인퍼런스, WebRTC 프레임워크냐, 아니냐: 그것이 net/http로다 Effect-ive Go: 완전히 Go 다운 함수형 프로그래밍 Test Reality Not Mocks: Reliable Go Tests in the AI Era Dev in Go way (Go스러움) Go로 밑바닥부터 맨 땅에 헤딩하듯 만드는 P2P 블록체인 네트워크 sync 패키지를 활용해서 강력한 버퍼링 만들기 / 부제: 실제 사례로 살펴보는 Go의 간편한 동시성 프로그래밍 이 중에서 몇 개는 QnA를 하느라 못 들은 점이 아쉽네요. 들은 세션중에 인상 깊었던 것을 정리하면 아래와 같아요. ...
문제 상황 프로젝트 배경 지금 다루고 있는 서비스는 안과의사 PC에서 돌아가는 온프레미스 서비스입니다. 장비 들에서 찍은 데이터들을 토대로 의사들이 정확한 진료를 내릴 수 있도록 도와주는 온프레미스 의료 데이터 통합 웹 툴이죠. 이 서비스에서 장비와의 데이터 통신 부터 받은 데이터에 대한 파이프라인, 프론트 작업과 퍼블리싱 작업까지 넓게 맡고 있습니다. 해당 글에서 다룰 이슈는 다음과 같습니다. 특정 장비에서 부터 일정 양 이상의 데이터를 받으면 데이터베이스가 죽어버린다는 문제가 발생하였습니다. 장비의 데이터를 안정적으로 수신하여 의사한테 정확한 데이터를 보여줘하는 서비스 특징 상 매우 큰 이슈였습니다. ...
Go언어 프로젝트 가이드 A-Z 주된 내용 프로젝트의 크기가 Feather 단위에서 Enterprise 단위까지를 이룰 때 Application 개발을 GoLang으로 할 경우 어떻게 접근하는지에 대한 구조도 규모에 맞춰 아래와 같이 나눠서 접근 초기(스타트업/MVP 단계) 사용자 검증을 위한 빠른 개발에 집중 불필요한 라이브러리 최소화, 표준 라이브러리 활용 기능 단위로 간단히 구현, HandlerFunc 중심의 빠른 개발 패턴 활용 서비스 확장 단계(유니콘/중간 규모) 기능이 많아지고 의존성이 복잡해지므로 이 시기부터 패턴의 중요성 커짐 단순 HandlerFunc에서 Handler 패턴으로 전환하는 시기로 특히 상태 관리, 의존성 명확화가 필요 Handler 패턴: 구조체에 의존성을 주입할 수 있게 하고, ServeHTTP를 구현하게 해서 어디든 사용 가능하게 해서 확장성을 챙김 type PingHandler struct { DB *sql.DB } func (h *PingHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) { // DB 같은 의존성 명확하게 사용 가능 w.Write([]byte("pong with DB")) } 기능 단위에서 서비스 단위 아키텍처로 확장 엔터프라이즈 단계 DDD(Domain-Driven Design) 적용을 통해 기능 중심에서 비즈니스 도메인 중심으로 분리 Bounded Context로 경계 정의 데이터 흐름을 확실히 나눔 API 모델과 내부 도메인 분리 (Presenter 패턴 활용) 각 레이어 분리로 테스트 용이 (Fake 구현 활용) 운영 필수 도구 ...