PIElog — MANAPIE의 글과 실험

// featured post_

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

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

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

read →

// experiences · 13_

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

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

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

read →
  • experience
  • develop
  • infra
  • devops
  • gcp
  • secret-manager
  • terraform
  • nodejs

.env에서 Secret Manager로, 미루던 이관을 시작하게 된 일주일

GCP 위의 작은 서비스에서 .env 기반 시크릿을 Secret Manager로 옮긴 회고입니다. 두 방식이 값을 어디에 두고 어떻게 전달하는지 먼저 비교한 뒤, 값이 지나가는 경로를 코드 밖까지 세어야 한다는 것, 레거시 액세스 스코프가 IAM보다 먼저 걸린다는 것, 평문을 어디까지 없앨지 선을 긋는 기준을 다룹니다.

read →
  • experience
  • develop
  • frontend
  • ai
  • ocr
  • paddleocr
  • tesseract
  • onnxruntime
  • webassembly
  • webgpu
  • web-worker
  • cache-storage

영수증 OCR에 서버가 꼭 필요할까 - 브라우저 온디바이스 OCR 구축기

PaddleOCR과 Tesseract를 영수증 26장으로 실측해 고르고, onnxruntime-web과 웹 워커로 브라우저 안에서 돌린 과정을 적었습니다. 회전 박스 후처리 한 줄이 날짜 인식률을 69%에서 100%로 올린 이야기와, 카나리 오판·캐시·손상된 모델 파일처럼 실제로 막혔던 열한 곳을 원인과 함께 정리했습니다.

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

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

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

read →
  • experience
  • develop
  • ai
  • infra
  • devops
  • comfyui
  • cloudrun
  • gcp
  • gpu

서버리스 GPU 위의 AI 이미지 생성기는 왜 로컬보다 느렸을까 - PIEmgmaker 구축기

로컬 Mac mini M4에서 잡 1건에 96분이 걸리던 AI 이미지 생성기를 GCP Cloud Run GPU로 옮겼습니다. 첫 원격 잡은 59분 26초, $1.69였습니다. 원인은 처리량이 아니라 로컬 SSD를 가정한 기본값이었고, 세 가지 처방으로 8분 25초 · $0.24가 됐습니다. 알파 채널 확보 전략부터 메모리 경계, AWS·GCP 선택, 모델 80GB 이전, 유휴 과금까지 2주간의 결정과 함정을 정리합니다.

read →
  • experience
  • develop
  • devops
  • ai
  • claude-code
  • shell
  • jq
  • cli

VSCode에서 돌리는 Claude Code 세션은 왜 안 잡힐까 - ccwhere 구축기

병렬로 띄운 Claude Code 세션을 한눈에 보는 도구를 찾다 기존 도구들이 VSCode 확장의 세션을 못 잡는 이유를 추적했습니다. 해법은 프로세스 추적이 아니라 세션 로그 파일을 직접 읽는 것이었습니다. jq의 16진수 미지원, command substitution 안에서 죽는 tput, 셸 변수 확장이 삼킨 jq 변수까지, 작은 셸 스크립트 하나에 박힌 함정들을 정리합니다.

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

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

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

read →
  • experience
  • design
  • develop
  • frontend
  • a11y
  • chart
  • react
  • d3
  • interactive

인터랙션과 접근성을 모두 고려한 차트 만들기

44개 차트 데모를 한 자리에 모았습니다. 시각 사용자·키보드 사용자·스크린리더 사용자가 모두 자연스럽도록 처음부터 설계했고, 그 과정에서 정착된 패턴들을 함께 정리했습니다. 그 패턴은 HTML overlay, roving tabindex, 호버와 키보드 포커스의 분리, 데이터 표 fallback입니다.

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

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

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

read →
  • experience
  • develop
  • frontend
  • security
  • swiper
  • dependency
  • prototypepollution

같은 critical, 두 앱의 다른 선택

스와이퍼의 두 번째 prototype pollution은 5년 전 패치가 우회된 사례입니다. 같은 CVE를 공유하는 두 앱 중 하나는 제거를, 다른 하나는 메이저 업그레이드를 택했습니다. 의존성의 실효 위험은 advisory가 아니라 코드가 결정합니다.

read →
  • experience
  • develop
  • frontend
  • react
  • nextjs
  • security
  • cve
  • rsc

React/Next.js CVE 6개월 정리

React 19와 Next.js의 6개월 동안 발견된 CVE들을 한 편에 정리합니다. 각 CVE의 문제, 재현 방식, 패치, 그리고 당장 올릴 수 없을 때의 대처법을 코드 예시와 함께 다룹니다.

read →
  • experience
  • develop
  • infra
  • devops
  • gce
  • centos
  • selinux
  • pm2
  • systemd

한 달간 1분 30초마다 죽고 있었던 서버

Next.js 서비스에서 시간을 두고 접속하면 가끔 503이 떨어지던 문제를 추적했습니다. 처음에는 MongoDB 유휴 커넥션을 의심해 옵션을 다듬었고, 다음으로 OOM을 의심했지만 둘 다 원인이 아니었습니다. 진짜 원인은 PM2 데몬 자체가 systemd에 의해 통째로 강제 종료되고 있다는 사실이었고, 그 뿌리에는 SELinux의 사용자 홈 파일 접근 차단이 있었습니다.

read →
Astro + Vercel로 구축하는 개인 기술 블로그 세팅 후기
  • experience
  • develop
  • frontend
  • astro
  • vercel
  • blog
  • ssg

Astro + Vercel로 구축하는 개인 기술 블로그 세팅 후기

플랫폼에 종속되지 않고, 내 도메인에서 글을 온전히 소유할 수 있는 기술 블로그를 구축하려 합니다. 주로 기술이나 디자인에 관한 실무적·교육적 콘텐츠를 다룰 예정이며, 코드 블록과 인터랙티브 데모를 자유롭게 삽입할 수 있는 환경이 필요합니다. 이 글에서는 기술 스택을 선정하기까지의 과정과, 최종 선택한 Astro + Vercel 조합의 구체적인 구현 방법을 정리합니다.

read →

// knowledge · 131_

무엇을 남기는가 - PM 문서 가이드 ep.07
  • series
  • design
  • pm
  • project-management
  • documentation
  • closure
  • retrospective
  • lessons-learned
  • receipt

무엇을 남기는가 - PM 문서 가이드 ep.07

프로젝트의 마지막 날도 문서로 끝납니다. 닫힌 프로젝트가 다음 프로젝트의 출발점이 되도록 약속과 결과를 비교하고, 팀의 솔직한 회고를 모으고, 조직에 남길 교훈을 적습니다. 종결을 잘 하는 PM이 좋은 PM입니다.

read →
잘 가고 있는가 - PM 문서 가이드 ep.06
  • series
  • design
  • pm
  • project-management
  • documentation
  • status-report
  • burndown
  • dashboard
  • meeting-notes
  • receipt

잘 가고 있는가 - PM 문서 가이드 ep.06

가시화는 잘하고 있다는 사실을 증명하는 일이 아니라 같은 그림을 공유하는 일입니다. 상태 보고서는 매주의 압축이고, 번다운은 추세이고, 대시보드는 실시간 단면이고, 회의록은 결정의 기록입니다. 네 문서가 함께 움직이면 PM은 같은 말을 다섯 번 하지 않아도 됩니다.

read →
무엇이 흔들리는가 - PM 문서 가이드 ep.05
  • series
  • design
  • pm
  • project-management
  • documentation
  • risk
  • issue
  • change-management
  • receipt

무엇이 흔들리는가 - PM 문서 가이드 ep.05

통제는 일을 막는 것이 아니라 흔들림을 기록해 다음 결정에 쓰는 일입니다. 리스크는 아직 일어나지 않은 일, 이슈는 이미 일어난 일, 변경은 약속을 다시 그리는 일입니다. 세 문서가 함께 움직여야 프로젝트가 표류하지 않습니다.

read →
누가 책임지는가 - PM 문서 가이드 ep.04
  • series
  • design
  • pm
  • project-management
  • documentation
  • raci
  • resource-plan
  • communication
  • receipt

누가 책임지는가 - PM 문서 가이드 ep.04

분담은 일을 균등하게 나누는 일이 아니라 책임을 명확히 하는 일입니다. RACI는 한 사람이 한 일에 어떤 방식으로 관여하는지, 리소스 플랜은 그 사람이 얼마나 일할 수 있는지, 커뮤니케이션 플랜은 그 결과를 누구에게 어떻게 알릴지를 정합니다.

read →
어떻게 쪼개는가 - PM 문서 가이드 ep.03
  • series
  • design
  • pm
  • project-management
  • documentation
  • wbs
  • gantt
  • sprint
  • receipt

어떻게 쪼개는가 - PM 문서 가이드 ep.03

정의가 끝나도 실행은 저절로 시작되지 않습니다. 작업을 잘게 쪼개고, 시간 축에 늘어놓고, 어떤 순서로 처리할지 합의해야 합니다. WBS는 위계로 쪼개고, 간트는 시간으로 펼치고, 스프린트 백로그는 다음 2주를 약속합니다.

read →
무엇을 만드는가 - PM 문서 가이드 ep.02
  • series
  • design
  • pm
  • project-management
  • documentation
  • prd
  • user-story
  • use-case
  • receipt

무엇을 만드는가 - PM 문서 가이드 ep.02

정렬을 마치면 정의가 시작됩니다. PRD는 제품의 큰 그림을, 유저 스토리는 사용자의 의도를, 유스 케이스는 시스템과의 상호작용을, 화면설계서는 화면 단위의 약속을 적습니다. Receipt의 PRD가 처음 그려지는 순간을 따라갑니다.

read →
왜 시작하는가 - PM 문서 가이드 ep.01
  • series
  • design
  • pm
  • project-management
  • documentation
  • project-charter
  • brd
  • stakeholder
  • receipt

왜 시작하는가 - PM 문서 가이드 ep.01

프로젝트는 누군가의 불편에서 시작되지만, 그것만으로는 일이 되지 않습니다. 왜 시작하는지, 누구의 합의가 있는지, 무엇을 약속하는지가 문서에 적혀야 비로소 프로젝트가 됩니다. ep.01은 정렬을 위한 세 문서(차터, BRD, 이해관계자 매트릭스)를 Receipt의 시작점에서 살펴봅니다.

read →
왜 하나를 더 쓰는가 - PM 문서 가이드 ep.00
  • series
  • cover
  • design
  • pm
  • project-management
  • documentation
  • receipt

왜 하나를 더 쓰는가 - PM 문서 가이드 ep.00

PM 가이드는 이미 많습니다. 그래서 이 시리즈는 양식을 늘어놓는 대신 가상의 프로젝트 하나를 시간 순서로 따라가며, 각 단계에서 PM의 책상 위에 어떤 질문이 놓이고 어떤 문서가 그 질문에 답하는지 봅니다. ep.00은 시리즈의 흐름과 가상 프로젝트 Receipt를 소개합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

read →
부록: 조직 경계와 콘웨이의 법칙 - 디자인 패턴, 시스템 수준 편 ep.14
  • series
  • develop
  • design
  • architecture
  • system-design
  • organization
  • conway-law
  • design-system
  • governance

부록: 조직 경계와 콘웨이의 법칙 - 디자인 패턴, 시스템 수준 편 ep.14

콘웨이의 법칙과 역콘웨이 기동, 팀 토폴로지의 네 유형을 정리하고 디자인 시스템 거버넌스 세 모델을 비교합니다. 기술 부채의 소유권, 문서가 코드가 되는 지점, 그리고 제품 경계와 시스템 경계가 어긋날 때 벌어지는 일을 함께 봅니다.

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 →
변경 경계와 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.11
  • series
  • develop
  • frontend
  • devops
  • architecture
  • system-design
  • typescript
  • micro-frontend
  • feature-flag
  • deployment

배포 경계와 마이크로 프론트엔드 - 디자인 패턴, 시스템 수준 편 ep.11

모놀리스에서 마이크로서비스까지의 스펙트럼을 비용 관점으로 정리하고, Module Federation과 코드 스플리팅, feature flag의 수명 주기를 다룹니다. 한 화면에 두 버전의 디자인 시스템이 섞이는 순간과 점진 롤아웃의 UX를 함께 봅니다.

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

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

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

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.08
  • series
  • develop
  • frontend
  • backend
  • infra
  • architecture
  • system-design
  • typescript
  • caching
  • http

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

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

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

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

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

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.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.04
  • series
  • develop
  • frontend
  • architecture
  • system-design
  • typescript
  • rendering
  • ssr
  • rsc
  • bff

실행 경계와 렌더링 전략 - 디자인 패턴, 시스템 수준 편 ep.04

빌드 타임과 런타임, 서버와 클라이언트라는 두 축으로 실행 지점의 사분면을 그리고 SSG·ISR·SSR·CSR·RSC·Islands의 좌표를 정리합니다. hydration 비용과 BFF를 짚고, 스켈레톤 UI와 레이아웃 시프트가 이 경계의 산물임을 함께 봅니다.

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 →
의존 방향과 헥사고날 아키텍처(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.01
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • modularity
  • design-system

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

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

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

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

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

read →
앱 개발자에게 무엇을 요청할 것인가 - 웹뷰는 브라우저가 아니다 ep.09
  • series
  • develop
  • frontend
  • webview
  • wkwebview
  • androidwebview
  • hybridapp
  • checklist

앱 개발자에게 무엇을 요청할 것인가 - 웹뷰는 브라우저가 아니다 ep.09

웹뷰 이슈의 담당을 가르는 기준은 증상이 아니라 "무엇을 바꾸면 동작이 바뀌는가"입니다. 이 편은 시리즈 전체의 증상을 여섯 계통으로 묶어 원인과 담당을 매핑하고, 그 판정을 이슈 양식과 설정 체크리스트로 옮깁니다. 패스키·플랫폼 결제·공동인증서처럼 웹 코드로 우회할 수 없는 항목도 같은 표 안에서 담당을 가릅니다.

read →
어제 배포했는데 앱에서는 그제 화면입니다 - 웹뷰는 브라우저가 아니다 ep.08
  • series
  • develop
  • frontend
  • webview
  • wkwebview
  • androidwebview
  • hybridapp
  • cache
  • bfcache

어제 배포했는데 앱에서는 그제 화면입니다 - 웹뷰는 브라우저가 아니다 ep.08

캐시 모드는 앱 설정에 종속되고, 렌더러 프로세스는 시스템이 회수하며, 백그라운드에서는 타이머가 흐르지 않습니다. 웹 개발자가 통제할 수 있는 층이 어디까지인지 문서로 확인한 뒤, 폼 초안 복원과 만료 시각 기반 카운트다운, 배포 반영을 위한 캐시 무효화 전략까지 웹 쪽에서 할 수 있는 것으로 착지합니다.

read →
로그인이 풀립니다 - 웹뷰는 브라우저가 아니다 ep.07
  • series
  • develop
  • frontend
  • webview
  • wkwebview
  • androidwebview
  • cookie
  • origin
  • cors
  • securecontext

로그인이 풀립니다 - 웹뷰는 브라우저가 아니다 ep.07

웹뷰의 저장소는 브라우저가 아니라 앱이 소유합니다. 그리고 로컬 번들을 file 스킴으로 로드하는 순간 오리진 판정이 무너지면서 Web Storage, 교차 출처 요청, 보안 컨텍스트가 한꺼번에 따라 무너집니다. 세 층을 분리해서 보면 "로그인이 풀립니다"라는 한 문장 뒤에 서로 다른 원인이 몇 개나 숨어 있는지 가릴 수 있습니다.

read →
앱이 내 CSS를 덮어씁니다 - 웹뷰는 브라우저가 아니다 ep.06
  • series
  • develop
  • frontend
  • webview
  • wkwebview
  • androidwebview
  • darkmode
  • accessibility
  • css

앱이 내 CSS를 덮어씁니다 - 웹뷰는 브라우저가 아니다 ep.06

Android 웹뷰의 prefers-color-scheme는 사용자의 OS 다크모드가 아니라 앱 테마의 isLightTheme로 결정됩니다. 시스템 글꼴 배율은 웹 콘텐츠에 곱해지고, 핀치 확대는 앱이 켜지 않으면 아예 동작하지 않습니다. 마지막 항목은 WCAG 1.4.4 위반이기도 합니다. 이 편은 CSS 바깥에서 들어오는 스타일의 출처를 하나씩 지목하고, 웹이 선언할 것과 앱에 요청할 것을 가릅니다.

read →
화면이 잘리고 손이 미끄러집니다 - 웹뷰는 브라우저가 아니다 ep.05
  • series
  • develop
  • frontend
  • webview
  • wkwebview
  • androidwebview
  • viewport
  • safearea
  • css

화면이 잘리고 손이 미끄러집니다 - 웹뷰는 브라우저가 아니다 ep.05

레이아웃 뷰포트와 시각 뷰포트를 나눠 보면 100vh 문제, 키보드에 가려지는 하단 버튼, 노치에 잘리는 헤더가 한 축으로 정렬됩니다. iOS와 안드로이드 크롬과 Android WebView가 서로 다른 시간표로 움직였다는 점, 그리고 CSS로 막을 수 있는 제스처와 없는 제스처의 경계를 버전 조건과 함께 정리합니다.

read →
한글이 덜 조합된 채로 넘어갑니다 - 웹뷰는 브라우저가 아니다 ep.04
  • series
  • develop
  • frontend
  • webview
  • ime
  • hangul
  • composition
  • vue

한글이 덜 조합된 채로 넘어갑니다 - 웹뷰는 브라우저가 아니다 ep.04

조합 이벤트 세 개와 isComposing, 그리고 폐기 예정인 keyCode 229를 같이 봐야 하는 이유를 스펙과 MDN 문서로 정리합니다. 전송 버튼·엔터 중복·실시간 조회·Vue의 v-model까지, 증상별로 틀린 코드와 고친 코드를 나란히 놓고 무엇을 웹에서 막고 무엇을 앱에 요청할지 가릅니다.

read →
폼이 내 디자인이 아닙니다 - 웹뷰는 브라우저가 아니다 ep.03
  • series
  • develop
  • frontend
  • webview
  • wkwebview
  • androidwebview
  • hybridapp
  • forms
  • accessibility
  • autofill
  • passkey
  • webauthn

폼이 내 디자인이 아닙니다 - 웹뷰는 브라우저가 아니다 ep.03

폼 컨트롤은 웹이 마크업으로 선언하고 실제 UI는 플랫폼이 그립니다. 그래서 CSS가 닿지 않고, 커스텀으로 다시 만들면 접근성이 통째로 웹의 책임이 됩니다. 2026년 기준으로 표준 select를 스타일링할 수 있게 된 조건, 파일 선택의 플랫폼별 정반대 기본값, 패스키가 앱과 도메인의 연결을 요구하는 조건, 그리고 인증번호 자동입력이 iOS와 안드로이드에서 갈리는 지점을 근거와 함께 정리합니다.

read →
눌렀는데 아무 일도 안 일어납니다 - 웹뷰는 브라우저가 아니다 ep.02
  • series
  • develop
  • frontend
  • webview
  • wkwebview
  • androidwebview
  • hybridapp
  • navigation

눌렀는데 아무 일도 안 일어납니다 - 웹뷰는 브라우저가 아니다 ep.02

링크와 스킴과 다운로드와 인쇄는 따로 고장 나는 것처럼 보이지만, 실제로는 웹뷰가 "이 요청을 어디로 보낼지" 정하는 하나의 지점을 함께 지납니다. 각 요청이 어느 콜백으로 넘어가는지, 앱이 무엇을 켜지 않으면 사라지는지, 그리고 사용자 제스처가 언제 만료되는지를 공식 문서 기준으로 정리합니다. 웹 코드에서 바꿀 것과 앱에 요청할 것을 갈라 놓는 데까지 갑니다.

read →
같은 엔진, 다른 껍데기 - 웹뷰는 브라우저가 아니다 ep.01
  • series
  • develop
  • frontend
  • webview
  • wkwebview
  • androidwebview
  • useragent
  • debugging
  • hybridapp

같은 엔진, 다른 껍데기 - 웹뷰는 브라우저가 아니다 ep.01

iOS는 웹뷰 엔진이 OS 버전에 묶여 올라가고, Android는 웹뷰가 별도 APK로 앱처럼 올라갑니다. 이 비대칭이 "특정 기기에서만 안 됩니다"의 뿌리입니다. 사용자 에이전트에서 신뢰할 수 있는 신호와 무너진 신호를 가르고, WebView DevTools와 Safari 웹 인스펙터로 실기기 환경을 특정하는 절차, 릴리즈 빌드에서 디버거가 막혔을 때의 대안까지 정리합니다.

read →
// see all posts_ 144 posts →