tag · 66 posts

#backend

  • experience
  • develop
  • backend
  • infra
  • devops
  • security
  • php
  • cve
  • rce
  • php2shell

PHP2Shell 분석: PHP 엔진의 RCE 취약점 두 건과 대응 방법

PHP 코어의 메모리 관리와 오류 처리에서 나온 CVSS 9.2 취약점 두 건을 분석합니다. 어떤 구조의 결함인지, 어떤 실행 방식이 더 위험한지, 버전과 배포판별로 어떤 수정이 나왔는지를 구분합니다. 패치를 바로 올릴 수 없을 때의 임시 완화책과 패치 이후의 재시작·점검 항목도 담았습니다.

read →
전부 해보는 것과 그러지 않는 것 - 이름과 비용: 알고리즘 ep.00
  • series
  • cover
  • develop
  • frontend
  • backend
  • cs
  • algorithm

전부 해보는 것과 그러지 않는 것 - 이름과 비용: 알고리즘 ep.00

완전탐색을 출발점으로 두고, 탐색 공간을 줄이는 네 가지 근거를 축으로 알고리즘 시리즈의 지도를 그립니다. 그래프 탐색부터 정수론까지 여섯 편의 구성과 서로의 의존 관계를 정리합니다.

read →
문제를 그래프로 바꿔 보기 - 이름과 비용: 알고리즘 ep.01
  • series
  • develop
  • frontend
  • backend
  • cs
  • algorithm
  • graph
  • bfs
  • dfs

문제를 그래프로 바꿔 보기 - 이름과 비용: 알고리즘 ep.01

그래프 표현 두 가지의 선택 기준을 정리하고, 격자와 상태 공간을 그래프로 읽는 방법을 다룹니다. 깊이 우선 탐색과 너비 우선 탐색이 각각 어떤 질문에 답하는지, 너비 우선이 최단 거리를 보장하는 근거는 무엇인지 확인합니다.

read →
탐색 공간을 줄이는 근거 - 이름과 비용: 알고리즘 ep.02
  • series
  • develop
  • frontend
  • backend
  • cs
  • algorithm
  • binarysearch
  • twopointer
  • backtracking

탐색 공간을 줄이는 근거 - 이름과 비용: 알고리즘 ep.02

이분탐색의 전제를 정렬이 아니라 단조성으로 다시 정의하고, 답 자체를 이분탐색하는 파라메트릭 서치로 확장합니다. 경계 조건을 안정적으로 처리하는 템플릿과 투 포인터, 백트래킹의 가지치기, 비트마스킹을 같은 관점으로 묶습니다.

read →
언제 욕심내고 언제 기억하는가 - 이름과 비용: 알고리즘 ep.03
  • series
  • develop
  • frontend
  • backend
  • cs
  • algorithm
  • greedy
  • dp

언제 욕심내고 언제 기억하는가 - 이름과 비용: 알고리즘 ep.03

그리디가 성립하는 두 가지 조건을 정리하고, 증명 대신 반례를 찾는 실용적인 판별법을 다룹니다. 그리디가 깨질 때 동적 계획법으로 넘어가는 과정과 점화식을 세우는 절차, 배낭 문제의 두 변형을 확인합니다.

read →
가중치와 순서와 연결성 - 이름과 비용: 알고리즘 ep.04
  • series
  • develop
  • frontend
  • backend
  • cs
  • algorithm
  • graph
  • dijkstra
  • unionfind

가중치와 순서와 연결성 - 이름과 비용: 알고리즘 ep.04

가중치가 있는 그래프의 최단 경로를 다익스트라로 풀고, 음수 간선과 전체 쌍 최단 거리라는 변형을 확인합니다. 연결 여부만 필요할 때의 유니온 파인드, 최소 비용 연결을 만드는 최소 신장 트리, 순서 제약을 처리하는 위상정렬까지 신호별로 정리합니다.

read →
문자열 안에서 패턴 찾기 - 이름과 비용: 알고리즘 ep.05
  • series
  • develop
  • frontend
  • backend
  • cs
  • algorithm
  • string
  • kmp
  • trie

문자열 안에서 패턴 찾기 - 이름과 비용: 알고리즘 ep.05

나이브 문자열 매칭이 버리는 정보가 무엇인지 짚고, KMP의 실패 함수가 그 정보를 어떻게 저장하는지 다룹니다. 해시로 비교하는 라빈카프와 접두사를 공유하는 트라이까지 문자열 전용 구조를 정리합니다.

read →
정수를 다루는 도구들 - 이름과 비용: 알고리즘 ep.06
  • series
  • develop
  • frontend
  • backend
  • cs
  • algorithm
  • numbertheory
  • modular
  • bigint

정수를 다루는 도구들 - 이름과 비용: 알고리즘 ep.06

유클리드 호제법과 에라토스테네스의 체를 원리부터 정리하고, 모듈러 연산이 어떤 성질 위에서 안전한지 확인합니다. 자바스크립트에서 정수 정밀도가 깨지는 경계와 BigInt로 넘어가는 기준까지 다루며 두 시리즈를 마칩니다.

read →
이미 쓰고 있는 것들의 이름 - 이름과 비용: 자료구조 ep.00
  • series
  • cover
  • develop
  • frontend
  • backend
  • cs
  • datastructure
  • algorithm

이미 쓰고 있는 것들의 이름 - 이름과 비용: 자료구조 ep.00

자료구조와 알고리즘을 두 개의 시리즈로 나눠 다룹니다. 자료구조 시리즈는 데이터를 담고 정리하는 구조를, 알고리즘 시리즈는 그 안에서 찾고 결정하는 방법을 봅니다. 각 편이 독립적으로 읽히도록 구성했고, 이 편은 전체 지도 역할을 합니다.

read →
크기가 접근법을 정한다 - 이름과 비용: 자료구조 ep.01
  • series
  • develop
  • frontend
  • backend
  • cs
  • datastructure
  • complexity
  • bigo

크기가 접근법을 정한다 - 이름과 비용: 자료구조 ep.01

시간 복잡도를 정의부터 다시 정리하고, 입력 크기 N에서 허용 가능한 복잡도를 역산하는 방법을 다룹니다. 상수를 버리는 표기법의 이점과 한계, 최선과 평균과 최악을 구분해야 하는 이유, 공간 복잡도를 함께 세는 습관까지 확인합니다.

read →
배열과 해시의 진짜 비용 - 이름과 비용: 자료구조 ep.02
  • series
  • develop
  • frontend
  • backend
  • cs
  • datastructure
  • array
  • hashmap
  • queue

배열과 해시의 진짜 비용 - 이름과 비용: 자료구조 ep.02

배열이 연속된 메모리라는 사실에서 따라오는 비용 구조를 정리하고, 해시 테이블의 충돌 처리 방식과 평균 성능이 깨지는 조건을 확인합니다. 자바스크립트 배열로 큐를 만들 때 생기는 함정과 그 해법도 함께 다룹니다.

read →
내장 정렬이 보장하는 것 - 이름과 비용: 자료구조 ep.03
  • series
  • develop
  • frontend
  • backend
  • cs
  • datastructure
  • sorting
  • javascript

내장 정렬이 보장하는 것 - 이름과 비용: 자료구조 ep.03

자바스크립트 기본 정렬이 값을 문자열로 바꾼다는 사실에서 출발해, 안정 정렬이라는 성질이 다중 기준 정렬에서 어떻게 작동하는지 다룹니다. 퀵 정렬과 병합 정렬과 힙 정렬의 성격 차이, 비교 정렬의 하한과 그것을 우회하는 계수 정렬까지 정리합니다.

read →
트리의 모양이 성능을 만든다 - 이름과 비용: 자료구조 ep.04
  • series
  • develop
  • frontend
  • backend
  • cs
  • datastructure
  • tree
  • heap
  • priorityqueue

트리의 모양이 성능을 만든다 - 이름과 비용: 자료구조 ep.04

이진탐색트리가 절반씩 버리는 원리와 그 전제가 무너지는 편향 상황을 확인하고, 균형 트리가 어떤 방식으로 높이를 통제하는지 정리합니다. 힙이 완전 정렬을 포기해서 얻는 이득과, 자바스크립트에 없는 우선순위 큐를 직접 구현하는 방법도 다룹니다.

read →
같은 구간을 반복해 묻는다면 - 이름과 비용: 자료구조 ep.05
  • series
  • develop
  • frontend
  • backend
  • cs
  • datastructure
  • prefixsum
  • segmenttree

같은 구간을 반복해 묻는다면 - 이름과 비용: 자료구조 ep.05

누적합으로 구간 질의를 상수 시간으로 만드는 방법과 2차원 확장을 다루고, 중간에 값이 바뀌는 상황에서 그 전략이 무너지는 지점을 확인합니다. 세그먼트 트리가 질의와 갱신을 모두 O(log N)으로 유지하는 원리와 선택 기준을 정리합니다.

read →
변경 경계와 Strangler Fig - 디자인 패턴, 시스템 수준 편 ep.12
  • series
  • develop
  • backend
  • frontend
  • architecture
  • system-design
  • typescript
  • migration
  • versioning
  • design-system

변경 경계와 Strangler Fig - 디자인 패턴, 시스템 수준 편 ep.12

Strangler Fig로 오래된 시스템을 점진적으로 교체하는 방법과 Expand-Contract로 스키마를 무중단 변경하는 순서를 정리합니다. API 버저닝의 비용과 디자인 시스템 v1에서 v2로 넘어가는 deprecation 정책, 릴리스 노트가 곧 계약서인 이유를 함께 봅니다.

read →
관측 경계와 분산 추적 - 디자인 패턴, 시스템 수준 편 ep.13
  • series
  • develop
  • backend
  • frontend
  • devops
  • architecture
  • system-design
  • typescript
  • observability
  • opentelemetry

관측 경계와 분산 추적 - 디자인 패턴, 시스템 수준 편 ep.13

로그·메트릭·트레이스의 역할을 나누고 correlation ID가 경계를 넘는 방법과 OpenTelemetry, SLI·SLO를 정리합니다. Error Boundary가 놓치는 것과 RUM, 그리고 사용자에게 보여줄 에러 ID의 설계를 함께 봅니다.

read →
상태의 경계와 서버 상태 분리 - 디자인 패턴, 시스템 수준 편 ep.07
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • state-management
  • cqrs
  • url-state

상태의 경계와 서버 상태 분리 - 디자인 패턴, 시스템 수준 편 ep.07

상태를 둘 수 있는 여섯 위치를 비교하고 서버 상태와 클라이언트 상태를 가르는 기준을 세웁니다. CQRS와 Repository를 TypeScript로 정리하고, URL이 상태를 가질 때 얻는 공유·뒤로가기·새로고침을 함께 봅니다.

read →
캐시 경계와 무효화 전략 - 디자인 패턴, 시스템 수준 편 ep.08
  • series
  • develop
  • frontend
  • backend
  • infra
  • architecture
  • system-design
  • typescript
  • caching
  • http

캐시 경계와 무효화 전략 - 디자인 패턴, 시스템 수준 편 ep.08

CDN부터 메모리까지 다섯 계층의 캐시를 짚고 TTL·태그·이벤트 기반 무효화를 비교합니다. stale-while-revalidate와 캐시 스탬피드를 TypeScript로 정리하고, 낡은 데이터를 숨기지 않고 드러내는 UI 패턴을 함께 봅니다.

read →
일관성 경계와 Saga 패턴 - 디자인 패턴, 시스템 수준 편 ep.09
  • series
  • develop
  • backend
  • frontend
  • architecture
  • system-design
  • typescript
  • saga
  • transaction
  • eventual-consistency

일관성 경계와 Saga 패턴 - 디자인 패턴, 시스템 수준 편 ep.09

트랜잭션이 닿는 범위와 닿지 않는 범위를 나누고, Saga의 보상 트랜잭션과 Event Sourcing, 최종 일관성을 TypeScript로 정리합니다. 부분 실패 상태를 사용자에게 어떤 문장으로 알릴 것인가, 되돌릴 지점을 어디에 둘 것인가를 함께 봅니다.

read →
신뢰 경계와 검증의 위치 - 디자인 패턴, 시스템 수준 편 ep.10
  • series
  • develop
  • backend
  • frontend
  • security
  • architecture
  • system-design
  • typescript
  • authorization
  • authentication

신뢰 경계와 검증의 위치 - 디자인 패턴, 시스템 수준 편 ep.10

인증과 인가를 분리하고 서버 권위 원칙과 최소 권한을 정리합니다. 토큰 저장 위치의 트레이드오프를 비교하고, 숨김과 비활성화의 차이, 에러 메시지가 흘리면 안 되는 정보, 위험한 행동 앞의 마찰 설계를 함께 봅니다.

read →
네트워크 경계와 회복 탄력성 - 디자인 패턴, 시스템 수준 편 ep.05
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • resilience
  • circuit-breaker
  • error-handling

네트워크 경계와 회복 탄력성 - 디자인 패턴, 시스템 수준 편 ep.05

Timeout, Retry, Circuit Breaker, Bulkhead, Fallback을 TypeScript로 정리하고 워터폴과 병렬 페칭의 차이를 짚습니다. 로딩·에러·빈 상태 3종 세트와 재시도 버튼의 정직함, 낙관적 업데이트의 롤백을 사용자에게 어떻게 알릴 것인가를 함께 봅니다.

read →
시간의 경계와 이벤트 기반 처리 - 디자인 패턴, 시스템 수준 편 ep.06
  • series
  • develop
  • backend
  • frontend
  • architecture
  • system-design
  • typescript
  • event-driven
  • message-queue
  • idempotency

시간의 경계와 이벤트 기반 처리 - 디자인 패턴, 시스템 수준 편 ep.06

동기와 비동기의 경계를 시간축에서 정리하고 메시지 큐, Pub/Sub, Outbox 패턴, at-least-once와 멱등성을 TypeScript로 다룹니다. 디바운스와 오프라인 큐를 짚고, "완료했습니다"라고 말했지만 큐에 넣은 것뿐인 상황을 정직하게 쓰는 방법을 함께 봅니다.

read →
시스템의 형태는 경계가 결정한다 - 디자인 패턴, 시스템 수준 편 ep.00
  • series
  • cover
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • boundaries

시스템의 형태는 경계가 결정한다 - 디자인 패턴, 시스템 수준 편 ep.00

객체 하나의 책임 위 층위에서 우리가 실제로 결정하는 것은 경계입니다. 이 시리즈는 코드·실행·데이터·수명이라는 네 층위에서 열세 개의 경계를 다루고, 각 경계에 이미 붙어 있는 패턴의 이름과 그 경계가 화면에 드러나는 자리를 함께 봅니다.

read →
모듈 경계와 폴더 구조 전략 - 디자인 패턴, 시스템 수준 편 ep.01
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • modularity
  • design-system

모듈 경계와 폴더 구조 전략 - 디자인 패턴, 시스템 수준 편 ep.01

응집도와 결합도를 기준으로 Package by Layer와 Package by Feature를 비교하고, 배럴 파일과 순환 참조, 모듈 경계와 번들 청크 경계의 불일치를 짚습니다. 같은 결정이 디자인 시스템과 프로덕트 사이의 선을 긋는 일에서 어떻게 다시 나타나는지를 함께 봅니다.

read →
의존 방향과 헥사고날 아키텍처(Hexagonal Architecture) - 디자인 패턴, 시스템 수준 편 ep.02
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • hexagonal-architecture
  • dependency-inversion
  • design-tokens

의존 방향과 헥사고날 아키텍처(Hexagonal Architecture) - 디자인 패턴, 시스템 수준 편 ep.02

의존성 역전 원칙과 Ports and Adapters 구조를 TypeScript로 정리하고, 프론트엔드에서 컴포넌트가 API 스키마를 직접 아는 문제를 짚습니다. 같은 결정이 디자인 토큰의 단방향 흐름(토큰에서 컴포넌트로, 컴포넌트에서 화면으로)에서 어떻게 다시 나타나는지를 함께 봅니다.

read →
계약 경계와 런타임 타입 검증 - 디자인 패턴, 시스템 수준 편 ep.03
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • zod
  • schema
  • design-system

계약 경계와 런타임 타입 검증 - 디자인 패턴, 시스템 수준 편 ep.03

타입 소거와 as 단언의 위험을 짚고, Parse don't validate 원칙과 zod 기반 파싱을 TypeScript로 정리합니다. 스키마 우선과 코드 우선, codegen과 tRPC가 실제로 보장하는 것을 구분하고, 컴포넌트 계약과 headless·slot 확장점 설계, 디자인 토큰 계약까지 함께 봅니다.

read →
  • experience
  • develop
  • backend
  • infra
  • devops
  • ai
  • fastapi
  • docker
  • yt-dlp
  • gemini

Chronosaurus를 검색하면 부작용이 나온다 - PIEmuvi 구축기

애플 뮤직·스포티파이·유튜브 뮤직 재생목록을 유튜브 재생 링크로 바꾸는 PIEmuvi를 FastAPI 단일 컨테이너로 만든 기록입니다. 스코어링만으로는 잡히지 않던 오답 세 가지를 채택 자격이라는 별도 축으로 해결한 과정과, 배포에서 세 번 헛짚고 원인을 찾은 진단 기록을 함께 정리합니다.

read →
패턴은 코드가 아니라 결정의 이름이다 - 디자인 패턴, 객체 수준 편 ep.00
  • series
  • cover
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented

패턴은 코드가 아니라 결정의 이름이다 - 디자인 패턴, 객체 수준 편 ep.00

GoF 카탈로그를 따라가되 각 편에서 그 패턴이 답하려 했던 질문을 함께 짚습니다. 같은 질문이 디자인·시스템 결정에서 다시 나타나는 자리를 연결해 봅니다. 코드 예제는 TypeScript로 통일했습니다.

read →
Factory와 디자인 시스템의 컴포넌트 팩토리 - 디자인 패턴, 객체 수준 편 ep.01
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • factory
  • creational
  • design-system

Factory와 디자인 시스템의 컴포넌트 팩토리 - 디자인 패턴, 객체 수준 편 ep.01

Simple Factory, Factory Method, Abstract Factory를 TypeScript 코드로 비교합니다. 각 형태가 무엇을 분리하려는 결정인지를 짚고, shadcn/ui 같은 디자인 시스템 라이브러리가 Abstract Factory의 모양을 그대로 따른다는 점을 함께 봅니다.

read →
Builder와 폼·필터·쿼리 빌더 UX - 디자인 패턴, 객체 수준 편 ep.02
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • builder
  • creational
  • ux

Builder와 폼·필터·쿼리 빌더 UX - 디자인 패턴, 객체 수준 편 ep.02

telescoping constructor가 자라는 자리에 Builder를 두는 이유를 짚고, TypeScript 코드로 fluent interface와 Director의 역할을 정리합니다. 같은 결정 구조가 폼·필터·쿼리 빌더 UI에서 어떻게 다시 나타나는지를 함께 살펴봅니다.

read →
Singleton과 전역 상태·테마 컨텍스트 - 디자인 패턴, 객체 수준 편 ep.03
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • singleton
  • creational
  • design-system

Singleton과 전역 상태·테마 컨텍스트 - 디자인 패턴, 객체 수준 편 ep.03

Singleton의 TypeScript 구현과 Eager·Lazy 초기화를 정리합니다. 숨겨진 의존성, 테스트 어려움 같은 안티패턴 논점을 짚고, 디자인 시스템의 ThemeProvider와 React Context가 정말 Singleton인지, 그 결정이 한 개여야만 하는지를 함께 살펴봅니다.

read →
Adapter와 레거시 컴포넌트 마이그레이션 - 디자인 패턴, 객체 수준 편 ep.04
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • adapter
  • structural
  • migration

Adapter와 레거시 컴포넌트 마이그레이션 - 디자인 패턴, 객체 수준 편 ep.04

Object Adapter와 Class Adapter의 차이를 TypeScript 코드로 정리하고, 결제 게이트웨이 통합 예제를 통해 외부 의존을 격리하는 방식을 살펴봅니다. 같은 결정 구조가 디자인 시스템 마이그레이션, 특히 v1 컴포넌트 위에 v2 인터페이스를 입히는 점진적 작업에서 어떻게 다시 나타나는지를 함께 봅니다.

read →
Decorator와 Wrapper 컴포넌트의 윤리 - 디자인 패턴, 객체 수준 편 ep.05
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • decorator
  • structural
  • react

Decorator와 Wrapper 컴포넌트의 윤리 - 디자인 패턴, 객체 수준 편 ep.05

Logger, Cache, Auth 데코레이터를 체인으로 쌓는 TypeScript 예제로 Decorator의 구조를 살펴보고, HOC와의 차이를 정리합니다. 같은 결정 구조가 Wrapper 컴포넌트와 Compound Component 사이에서 어떻게 다른 답을 내놓는지, 그리고 덧붙임에는 어떤 윤리가 따라오는지를 함께 봅니다.

read →
Facade와 디자인 시스템 라이브러리 API - 디자인 패턴, 객체 수준 편 ep.06
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • facade
  • structural
  • design-system

Facade와 디자인 시스템 라이브러리 API - 디자인 패턴, 객체 수준 편 ep.06

결제 시스템을 단일 PaymentFacade로 정리하는 TypeScript 예제를 통해 Facade의 구조를 살펴보고, Adapter와의 차이를 명확히 합니다. 같은 결정 구조가 디자인 시스템 컴포넌트 라이브러리의 API 표면(무엇을 노출하고 무엇을 가릴 것인가)에서 어떻게 다시 나타나는지를 함께 봅니다.

read →
Composite와 디자인 토큰 계층 - 디자인 패턴, 객체 수준 편 ep.07
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • composite
  • structural
  • design-tokens

Composite와 디자인 토큰 계층 - 디자인 패턴, 객체 수준 편 ep.07

파일시스템과 UI 트리 예제로 Composite 패턴의 구조를 살펴보고, 같은 결정 구조가 디자인 토큰의 primitive → semantic → component 계층에서 어떻게 다시 나타나는지를 함께 봅니다. 토큰이 다른 토큰을 참조하는 일이 왜 Composite의 가장 자연스러운 사례인지를 짚습니다.

read →
Strategy와 다크모드 스위칭 - 디자인 패턴, 객체 수준 편 ep.08
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • strategy
  • behavioral
  • design-system

Strategy와 다크모드 스위칭 - 디자인 패턴, 객체 수준 편 ep.08

switch문 안티패턴을 Strategy로 정리하는 TypeScript 예제와 정렬·결제 알고리즘 교체를 살펴봅니다. 같은 결정 구조가 다크모드, 다국어, 플랫폼별 분기에서 어떻게 다시 나타나는지를 함께 살펴봅니다. Strategy와 State의 경계도 짚습니다.

read →
Observer와 알림 UX의 윤리 - 디자인 패턴, 객체 수준 편 ep.09
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • observer
  • behavioral
  • ux-ethics

Observer와 알림 UX의 윤리 - 디자인 패턴, 객체 수준 편 ep.09

EventEmitter와 Pub/Sub의 구조를 TypeScript 코드로 정리하고, Push와 Pull 방식의 차이, 메모리 누수의 함정을 짚습니다. 같은 결정 구조가 사용자에게 닿는 알림 UX에서 어떻게 다시 나타나는지, 그리고 그 알림이 dark pattern과 가까워지는 경계를 함께 살펴봅니다.

read →
State와 폼 상태 머신 - 디자인 패턴, 객체 수준 편 ep.10
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • state
  • behavioral
  • finite-state-machine

State와 폼 상태 머신 - 디자인 패턴, 객체 수준 편 ep.10

주문 처리 상태(draft → submitted → paid → shipped)를 TypeScript로 정리하고, 분기문이 자라는 안티패턴을 State로 풀어내는 과정을 살펴봅니다. 같은 결정 구조가 폼 상태 머신(idle → validating → submitting → success/error)에서 어떻게 다시 나타나는지를 함께 봅니다. Strategy와의 경계도 다시 한 번 짚습니다.

read →
부록: 그 외 GoF 객체 패턴들 - 디자인 패턴, 객체 수준 편 ep.11
  • series
  • develop
  • frontend
  • backend
  • design-patterns
  • gof
  • typescript
  • object-oriented
  • appendix

부록: 그 외 GoF 객체 패턴들 - 디자인 패턴, 객체 수준 편 ep.11

Visitor, Memento, Flyweight, Iterator, Command, Chain of Responsibility, Prototype, Bridge, Mediator, Template Method를 한 편으로 다룹니다. 각 패턴마다 핵심 정의, 실무에서 보이는 자리, 그리고 본편이 아닌 부록에 머무른 이유를 간결하게 정리합니다. 시즌 1 객체 수준 편의 마지막 편입니다.

read →
  • experience
  • develop
  • backend
  • frontend
  • socketio
  • nextauth
  • nextjs
  • debugging

두 라이브러리의 req는 같은 req가 아니었다

채팅 기능을 구현하던 날 socket 레이어의 게이팅을 비워둔 익숙한 손버릇이, 보안 마이그레이션 시점에 정확히 같은 자리에서 청구서로 돌아왔습니다. NextAuth의 SessionStore가 req.cookies만 보고 req.headers.cookie 헤더 자체는 무시한다는 사실을 추적하기까지의 디버깅과, 끝내 root cause를 단정하지 못한 채 in-flight 가드로 봉합한 버그까지의 회고입니다.

read →
아키텍처 정의서는 왜 화석이 되거나 거짓말이 되는가 - 두 개의 아키텍처 정의서 ep.00
  • series
  • cover
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • c4
  • adr

아키텍처 정의서는 왜 화석이 되거나 거짓말이 되는가 - 두 개의 아키텍처 정의서 ep.00

같은 시스템을 내부 공유용과 SI 납품용, 두 개의 정의서로 나란히 작성하며 비교하는 시리즈입니다. 첫 편에서는 아키텍처 문서가 실패하는 두 가지 방식을 정의하고, 시리즈 전체가 사용할 샘플 시스템을 소개합니다. 이 시리즈가 끝나면 자신만의 정의서를 설계할 기준틀을 갖게 됩니다.

read →
아키텍처 문서의 표준 지형도 - 두 개의 아키텍처 정의서 ep.01
  • series
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • c4
  • adr
  • arc42

아키텍처 문서의 표준 지형도 - 두 개의 아키텍처 정의서 ep.01

아키텍처 문서를 다루는 네 가지 표준 도구를 정리합니다. ISO/IEC/IEEE 42010은 문서가 답해야 할 질문의 틀을, arc42는 문서의 골격을, C4는 다이어그램을 그리는 법을, ADR은 결정의 기록 형식을 정합니다. 같은 도구를 내부용과 납품용이 어떻게 다르게 쓰는지도 함께 봅니다.

read →
요구사항에서 시작하기: 품질 속성과 드라이버 - 두 개의 아키텍처 정의서 ep.02
  • series
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • quality-attributes

요구사항에서 시작하기: 품질 속성과 드라이버 - 두 개의 아키텍처 정의서 ep.02

기능 요구사항은 거의 어떤 구조로도 만족됩니다. 구조를 가르는 것은 가용성·성능·보안 같은 품질 속성과 제약입니다. 이 편에서는 품질 속성을 시나리오로 표현하는 법을 익히고, 스폿의 드라이버 여섯 가지를 도출한 뒤, 그것이 어떻게 설계 결정으로 이어지는지 추적합니다.

read →
뷰를 그리다: C4와 4+1 - 두 개의 아키텍처 정의서 ep.03
  • series
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • c4
  • diagram

뷰를 그리다: C4와 4+1 - 두 개의 아키텍처 정의서 ep.03

하나의 시스템을 여러 관점으로 나눠 그리는 법을 다룹니다. 4+1 뷰 모델로 누가 무엇을 보는지 가르고, C4의 컨테이너 뷰로 스폿의 구조를, 런타임 뷰로 동기와 비동기 두 경로가 갈라지는 순간을, 배포 뷰로 코드가 어디서 도는지를 그립니다. 같은 그림을 두 문서가 어떻게 다르게 싣는지도 비교합니다.

read →
결정을 남기다: ADR - 두 개의 아키텍처 정의서 ep.04
  • series
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • adr
  • decision-record

결정을 남기다: ADR - 두 개의 아키텍처 정의서 ep.04

ADR은 하나의 설계 결정을 맥락·결정·대안·결과로 남기는 형식입니다. 스폿의 여섯 가지 결정을 ADR로 적고, 결정에도 상태와 수명이 있다는 점을 상태 머신으로 봅니다. 같은 ADR이 내부용에서는 살아있는 로그로, 납품용에서는 요구사항에 매핑되는 목록으로 갈라지는 지점도 다룹니다.

read →
흩어진 정책을 모으다: 횡단 관심사 - 두 개의 아키텍처 정의서 ep.05
  • series
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • security
  • observability

흩어진 정책을 모으다: 횡단 관심사 - 두 개의 아키텍처 정의서 ep.05

횡단 관심사는 여러 컴포넌트에 걸치는 정책입니다. 한 곳에 모아 두지 않으면 컴포넌트마다 다르게 구현되고 어딘가에서는 빠집니다. 이 편에서는 스폿의 여섯 가지 횡단 관심사를 관심사와 컴포넌트의 매트릭스로 정리하고, 같은 외부 의존이라도 동기와 비동기 경로에서 에러 전략이 어떻게 갈라지는지 봅니다.

read →
내부 공유용 정의서: 거짓말하지 않는 문서 만들기 - 두 개의 아키텍처 정의서 ep.06
  • series
  • develop
  • backend
  • frontend
  • infra
  • devops
  • architecture
  • documentation
  • adr

내부 공유용 정의서: 거짓말하지 않는 문서 만들기 - 두 개의 아키텍처 정의서 ep.06

지금까지 모은 재료로 내부 공유용 정의서를 완성합니다. 핵심 과제는 두 번째 죽음, 거짓말을 막는 것입니다. 거짓말이 자라는 메커니즘을 짚고, 천천히 변하는 것만 직접 쓰기·다이어그램을 코드로 그리기·결정을 쌓기·검증을 자동화하기라는 네 원칙으로 거짓말할 수 없는 구조를 만듭니다.

read →
SI 납품용으로 변환하기: 화석을 인정하는 문서 만들기 - 두 개의 아키텍처 정의서 ep.07
  • series
  • develop
  • backend
  • infra
  • devops
  • architecture
  • documentation
  • adr

SI 납품용으로 변환하기: 화석을 인정하는 문서 만들기 - 두 개의 아키텍처 정의서 ep.07

살아 있던 내부용 정의서를 SI 납품용으로 변환합니다. 납품용은 살릴 수 없는 문서, 곧 화석입니다. 요구사항 추적표를 채우고, 버전과 승인 이력을 붙이고, 특정 시점에 박제합니다. 공공 SI의 감리·검수 맥락을 짚고, 인수인계를 통해 화석이 유지보수팀의 살아있는 문서로 다시 태어나는 흐름까지 그리며 시리즈를 닫습니다.

read →
  • experience
  • develop
  • frontend
  • backend
  • testing
  • jest
  • react
  • nextjs

테스트가 없던 두 레포에 단위·컴포넌트·통합 테스트를 들이며

사람 눈검토만으로 운영 VM에 배포되던 두 레포에 jest를 깔았습니다. 어드민에서 검증한 패턴을 서비스로 옮기는 미러링 전략으로 네 단계를 차례로 진행했고, 그 사이에 만난 함정과 결정 패턴을 정리합니다.

read →
통합 테스트: 모듈이 만날 때 - 사용자 대상 소프트웨어 테스트 가이드 ep.04
  • series
  • develop
  • backend
  • frontend
  • testing
  • integration-test
  • msw
  • testcontainers

통합 테스트: 모듈이 만날 때 - 사용자 대상 소프트웨어 테스트 가이드 ep.04

단위 테스트가 모두 통과해도 실제 환경에서 작동하지 않는 일이 있습니다. 문제는 보통 모듈이 만나는 경계에 있습니다. 통합 테스트는 그 경계를 검증하는 일입니다. 테스트 더블, 계약 테스트, 환경 격리까지 다룹니다.

read →
매일 쓰는 협업의 글: PR · 커밋 · 온보딩 - 개발자를 위한 기술문서 입문 ep.08
  • series
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • commit
  • pull-request
  • onboarding
  • code-review

매일 쓰는 협업의 글: PR · 커밋 · 온보딩 - 개발자를 위한 기술문서 입문 ep.08

기술문서라고 하면 큰 글을 떠올리지만, 개발자가 가장 자주 쓰는 글은 커밋 메시지와 PR 설명입니다. 거기에 온보딩 문서가 더해지면, 팀의 일상이 만들어집니다. 이번 편은 좋은 커밋의 골격, 리뷰가 즐거워지는 PR, 그리고 첫 주를 단축시키는 온보딩을 다룹니다.

read →
본 시리즈 바깥의 인접 문서들 - 개발자를 위한 기술문서 입문 ep.09
  • series
  • develop
  • design
  • frontend
  • backend
  • infra
  • devops
  • ai
  • user-manual
  • design-doc
  • security
  • appendix

본 시리즈 바깥의 인접 문서들 - 개발자를 위한 기술문서 입문 ep.09

본 시리즈는 내부 개발 협업에서 쓰는 문서에 초점을 맞췄습니다. 그러나 그 바깥에도 자리한 문서들이 있습니다. 비개발자가 읽는 사용자 매뉴얼, 구현 직전에 동료에게 의견을 구하는 디자인 문서, 공개와 비공개 사이의 보안 문서. 이번 편은 각자의 위치를 짚어두며 시리즈를 마칩니다.

read →
왜, 무엇을, 어떻게 - 개발자를 위한 기술문서 입문 ep.00
  • series
  • cover
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • technical-writing
  • documentation
  • diataxis

왜, 무엇을, 어떻게 - 개발자를 위한 기술문서 입문 ep.00

기술문서를 안 써본 개발자가 가장 자주 겪는 문제는 형식이 아니라 의도입니다. 이 시리즈는 Diátaxis 프레임워크로 문서의 좌표를 잡고, 실무에서 실제로 마주치는 여덟 가지 산출물을 한 편씩 다룹니다. ep.00은 그 지도를 펴 보이는 편입니다.

read →
프로젝트의 첫인상: README - 개발자를 위한 기술문서 입문 ep.01
  • series
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • readme
  • documentation
  • open-source

프로젝트의 첫인상: README - 개발자를 위한 기술문서 입문 ep.01

README는 한 글이 아니라 여러 글의 시작점입니다. 평가자·사용자·기여자라는 세 유형의 독자를 30초·5분·30분이라는 시간 축으로 갈라보고, Hero / Quick Start / Deep 세 구간으로 골격을 잡습니다. 좋은 예와 나쁜 예, 그리고 체크리스트까지.

read →
처음 온 사람을 데려가는 길: 튜토리얼 - 개발자를 위한 기술문서 입문 ep.02
  • series
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • tutorial
  • onboarding
  • learning

처음 온 사람을 데려가는 길: 튜토리얼 - 개발자를 위한 기술문서 입문 ep.02

튜토리얼의 가장 흔한 실수는 설명을 하려 든다는 것입니다. 튜토리얼은 학습자에게 작은 성공을 안기는 글이고, 그 성공이 다음 학습으로 이어지는 글입니다. 하우투와 어떻게 다른지, 학습자 여정을 어떻게 설계하는지, 좋은 예와 나쁜 예까지 짚어봅니다.

read →
한 가지 목적을 해내는 절차: 하우투 가이드 - 개발자를 위한 기술문서 입문 ep.03
  • series
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • how-to
  • guide
  • procedure

한 가지 목적을 해내는 절차: 하우투 가이드 - 개발자를 위한 기술문서 입문 ep.03

하우투는 목적이 있는 사람을 위한 글입니다. 골격은 단순합니다. 목적·전제·단계·검증·다음 행동. 그러나 분기를 잘못 다루는 순간 글은 무너집니다. 이번 편은 하우투의 골격을 짚고, 분기를 다루는 세 가지 패턴과 자주 망가지는 지점을 봅니다.

read →
정확한 사실의 색인: 레퍼런스와 API 문서 - 개발자를 위한 기술문서 입문 ep.04
  • series
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • reference
  • api
  • openapi
  • docstring

정확한 사실의 색인: 레퍼런스와 API 문서 - 개발자를 위한 기술문서 입문 ep.04

레퍼런스는 가장 조용한 문서입니다. 처음부터 끝까지 읽으라고 만든 글이 아니라, 색인처럼 필요할 때 펼쳐 보라고 만든 글입니다. 그래서 미덕이 완전성과 일관성입니다. 이번 편은 레퍼런스 스펙트럼을 따라 docstring·시그니처·스펙을 짚고, 한 항목을 어떻게 써야 하는지 그 골격을 살핍니다.

read →
왜 이렇게 만들었는가: 아키텍처와 개념 설명 - 개발자를 위한 기술문서 입문 ep.05
  • series
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • explanation
  • architecture
  • c4-model
  • diagram

왜 이렇게 만들었는가: 아키텍처와 개념 설명 - 개발자를 위한 기술문서 입문 ep.05

익스플레네이션은 왜의 글입니다. 결정의 배경, 다른 길과의 비교, 트레이드오프를 다룹니다. 이번 편은 C4 모델로 줌 레벨을 잡고, 여섯 가지 대표 다이어그램의 쓰임을 정리한 뒤, 설명문이 자주 빠지는 두 함정(묘사와 변호)을 짚습니다.

read →
의사결정의 기록: ADR과 RFC - 개발자를 위한 기술문서 입문 ep.06
  • series
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • adr
  • rfc
  • decision-record
  • architecture

의사결정의 기록: ADR과 RFC - 개발자를 위한 기술문서 입문 ep.06

팀의 큰 결정은 어딘가에 적혀야 합니다. 결정 *전*의 글은 RFC, 결정 *후*의 글은 ADR입니다. 둘은 같은 주제를 다루지만 톤·구조·수명이 다릅니다. 이번 편은 ADR과 RFC의 위치 차이, 각자의 템플릿, 그리고 ADR의 상태 머신을 다룹니다.

read →
운영의 언어: 런북과 포스트모템 - 개발자를 위한 기술문서 입문 ep.07
  • series
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • runbook
  • postmortem
  • incident
  • on-call
  • blameless

운영의 언어: 런북과 포스트모템 - 개발자를 위한 기술문서 입문 ep.07

운영 문서는 평소엔 안 읽힙니다. 읽힐 때는 누군가 잠에서 깬 새벽 3시이거나, 무언가가 막 망가진 직후입니다. 그래서 톤이 다릅니다. 군더더기가 없어야 하고, 감정이 빠져 있어야 하고, 사실이 우선해야 합니다. 이번 편은 런북의 응급 카드 구조와 포스트모템의 비난 없는 글쓰기를 다룹니다.

read →
운영의 관측과 탄력성 - OWASP Top 10:2025 ep.05
  • series
  • develop
  • backend
  • devops
  • security
  • owasp
  • logging
  • monitoring
  • observability
  • resilience
  • incidentresponse

운영의 관측과 탄력성 - OWASP Top 10:2025 ep.05

Logging & Alerting Failures(A09)와 2025년 신규 카테고리 Mishandling of Exceptional Conditions(A10)를 다룹니다. 무엇을 로깅하고 무엇을 로깅하지 말아야 할지, Fail Closed의 의미, Circuit Breaker 패턴, Chaos Engineering의 보안적 의미, 그리고 Incident Response Playbook까지.

read →
코드 밖의 리스크 - OWASP Top 10:2025 ep.04
  • series
  • develop
  • backend
  • devops
  • security
  • owasp
  • supplychain
  • sbom
  • slsa
  • threatmodeling
  • securedesign

코드 밖의 리스크 - OWASP Top 10:2025 ep.04

Software Supply Chain Failures(A03)와 Insecure Design(A06)을 다룹니다. 의존성 관리와 SBOM, dependency confusion, install script 위험, SLSA. 그리고 위협 모델링과 비즈니스 로직 악용까지. 스캐너에 잡히지 않고 설계 단계에서 봐야 하는 두 카테고리입니다.

read →
신뢰 경계의 관리 - OWASP Top 10:2025 ep.03
  • series
  • develop
  • backend
  • frontend
  • security
  • owasp
  • injection
  • sqlinjection
  • xss
  • deserialization
  • csp

신뢰 경계의 관리 - OWASP Top 10:2025 ep.03

SQL Injection이 왜 prepared statement로 풀리는지, XSS의 세 유형은 왜 다른 방어가 필요한지, 역직렬화는 왜 JSON과 Pickle이 천지차이인지. 그리고 외부 스크립트·CI/CD 아티팩트의 무결성을 어떻게 보장하는지를 실전 수준으로 정리합니다.

read →
데이터 보호의 기본기 - OWASP Top 10:2025 ep.02
  • series
  • develop
  • backend
  • devops
  • security
  • owasp
  • tls
  • https
  • encryption
  • hashing
  • cors
  • securityheaders
  • misconfiguration

데이터 보호의 기본기 - OWASP Top 10:2025 ep.02

전송 중 보호(HTTPS/TLS), 저장 시 보호(해시·암호화·키 관리), 애플리케이션 레이어(보안 헤더·CORS), 그리고 클라우드 설정까지. 2025년판 2위와 4위로 올라온 두 카테고리의 핵심을 실전 명령어와 함께 정리합니다.

read →
인증과 인가의 경계 - OWASP Top 10:2025 ep.01
  • series
  • develop
  • backend
  • security
  • owasp
  • authentication
  • authorization
  • jwt
  • mfa
  • passkey
  • idor

인증과 인가의 경계 - OWASP Top 10:2025 ep.01

Broken Access Control(A01)과 Authentication Failures(A07)를 한 편에서 다룹니다. IDOR과 권한 상승, JWT의 함정과 세션 관리, MFA의 실제 효과와 Passkey까지. 실제로 확인 가능한 명령어와 체크리스트를 포함합니다.

read →
웹 서비스 보안 점검 가이드 - OWASP Top 10:2025 ep.00
  • series
  • cover
  • develop
  • backend
  • devops
  • security
  • owasp
  • owasptop10
  • web

웹 서비스 보안 점검 가이드 - OWASP Top 10:2025 ep.00

OWASP Top 10:2025가 왜 이전과 다른지, 그리고 중고급 개발자가 이 시리즈를 통해 무엇을 얻을 수 있는지 정리합니다. 시리즈 전체 구성과 각 편에서 다룰 카테고리, 배포 직전 30분 안에 돌릴 수 있는 스모크 테스트를 소개합니다.

read →