OAuth OAuth 2.0은 인증(Authentication) 자체보다 권한 부여(Authorization) 를 위한 프레임워크입니다. 즉, 제3자 애플리케이션이 리소스 소유자의 비밀번호를 직접 받지 않고도, 제한된 범위(scope)의 접근 권한을 얻도록 설계되었습니다. 네이버/카카오/구글 로그인에서 자주 보이는 흐름도 이 개념을 기반으로 하지만, “로그인(신원 확인)” 자체는 보통 OpenID Connect(OIDC) 같은 상위 프로토콜이 함께 쓰입니다. ...

서론 서버가 교차 출처 요청을 아무 기준 없이 허용하면, 민감한 응답 데이터가 의도치 않게 노출될 수 있습니다, 브라우저는 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의 가장 큰 단점 몇 가지를 해결할 수 있습니다. ...

서론 HTTP/1에서 HTTP/1.1로 업데이트되면서 많이 바뀌습니다만, 아직 남은 이슈들을 HTTP/2이 개발되었고 여기에는 프레임, 멀티플렉싱 등이 추가되었죠. HTTP/1 문제점들 HTTP/1에서 HTTP/1.1로 업데이트하면서 HTTP Pipelining이 추가되었지만, 이 HTTP Pipelining에서 동시성 문제가 발생했습니다. HTTP Pipelining은 HTTP/1.1에서 응답 순서 보장을 위해 사용되었는데, 이 때문에 요청이 연달아 들어오면 서버는 요청 순서대로 응답해야 하는 특징이 있어 뒤 요청은 대기 상태가 되는 문제가 생깁니다. ...

개요 1-1. Go 동시성, 정말 장점일까? - 주요 언어 성능 비교 GoLang의 사용처를 묻는 질문이 들어온다면 블록체인, 게임서버, 네트워크, 실시간 데이터 처리, 고성능 API 등 중에서 아마 대답이 나올 겁니다. 결국 고루틴(goroutine) 기반의 강력한 동시성을 GoLang의 핵심으로 보고 이를 장점으로 이야기 하는 것이죠. 이는 GoLang에 대해 공부하면 경량화된 쓰레드 자체 특징에 더해 채널, 락관리 등도 매우 편리하게 할 수 있는 걸 알고 있죠. ...

Gophercon 2025 올해 처음으로 고퍼콘에 참여하여 여러 세션을 들으며 다양한 인사이트를 얻을 수 있었습니다. 웰컴 티셔츠도 무료로 주셔서 감사한 마음으로 받고 관련 굳즈들(후드티, 뱃지, 키캡)과 스티커들을 왕창 얻을 수 있었네요. Gophercon 2025 세션은 다음과 같았어요 ...

문제 상황 프로젝트 배경 지금 다루고 있는 서비스는 안과의사 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 구현 활용) 운영 필수 도구 ...

기본 지식 Gno.Land가 무엇인지 알기 위해서는 몇 가지 사전 지식을 알아야 이해할 수 있습니다. 블록체인 블록체인과 암호화폐를 혼동하기 쉬운데, 블록체인은 기술이고 암호화폐는 그 기술 위에서 돌아가는 서비스입니다. 인터넷과 이메일의 관계가 블록체인과 암호화폐의 관계와 같다고 볼 수 있죠. 이메일도 인터넷 위에서 돌아가는 서비스잖아요. ...

0. 개요 CMS는 대부분의 개발자가 가장 먼저 접하는 친숙한 구조입니다. CRUD를 기반으로 한 패턴으로 어떤 기술을 배우든 자연스럽게 마주하게 되죠. 라프텔, 넷플릭스, 네이버 쇼핑, 다음 웹툰, 링크드인까지 우리가 쓰는 대부분의 서비스도 사실상 CMS의 확장 버전이라 볼 수 있습니다. ...