https://www.youngju.dev/blog 천천히 올바르게. AI Researcher & DevOps Engineer Youngju's blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology. ko fjvbn2003@gmail.com (Youngju Kim) fjvbn2003@gmail.com (Youngju Kim) Sat, 15 Aug 2026 00:00:00 GMT https://www.youngju.dev/blog/architecture/2026-08-15-guide-concurrency.en https://www.youngju.dev/blog/architecture/2026-08-15-guide-concurrency.en The working order an application designer follows when facing concurrency. First check whether shared state can be removed at all, narrow its scope when it cannot, put atomicity boundaries and locks around what is left, defend anything that crosses a process boundary with transactions and idempotency, and only then verify with tests. This is not a conceptual distinction or an infrastructure comparison — it is the decision order of the person writing the code. Sat, 15 Aug 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) 동시성아키텍처concurrencylockingbackpressuretesting https://www.youngju.dev/blog/architecture/2026-08-15-guide-concurrency.ja https://www.youngju.dev/blog/architecture/2026-08-15-guide-concurrency.ja アプリケーション設計者が並行性の問題に向き合うときに踏む作業順序を整理します。まず共有状態を消せるかを確認し、消せなければ範囲を狭め、残ったものに原子性境界とロックをかけ、プロセスの外に出たらトランザクションと冪等性で守り、最後にテストで確認します。概念の区別でもインフラ比較でもなく、コードを書く人の意思決定順序に焦点を当てます。 Sat, 15 Aug 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) 동시성아키텍처concurrencylockingbackpressuretesting https://www.youngju.dev/blog/architecture/2026-08-15-guide-concurrency https://www.youngju.dev/blog/architecture/2026-08-15-guide-concurrency 애플리케이션 설계자가 동시성 문제를 다룰 때 밟는 작업 순서를 정리합니다. 공유 상태를 없앨 수 있는지부터 확인하고, 없앨 수 없으면 범위를 좁히고, 남은 것에 원자성 경계와 잠금을 씌우고, 프로세스 밖으로 나가면 트랜잭션과 멱등성으로 지키고, 마지막에 테스트로 확인합니다. 개념 구분이나 인프라 비교가 아니라 코드를 쓰는 사람의 결정 순서에 초점을 둡니다. Sat, 15 Aug 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) 동시성아키텍처concurrencylockingbackpressuretesting https://www.youngju.dev/blog/architecture/2026-08-15-guide-design-docs.en https://www.youngju.dev/blog/architecture/2026-08-15-guide-design-docs.en This guide treats design documents as a team decision-making infrastructure rather than a writing skill. It covers which of the four formats (1-pager, design doc, ADR, RFC) to use when, how to run the review as a process, how decisions expire, and the eight ways documents fail. Sat, 15 Aug 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) 설계문서adrrfcdesign-doc기술문서의사결정아키텍처 https://www.youngju.dev/blog/architecture/2026-08-15-guide-design-docs.ja https://www.youngju.dev/blog/architecture/2026-08-15-guide-design-docs.ja 設計ドキュメントを文章術ではなくチームの意思決定インフラとして扱います。1-pager・設計ドキュメント・ADR・RFC のどれをいつ使うか、レビューをどう運用するか、決定がどう期限切れになるか、そして文書が失敗する八つの形を整理します。 Sat, 15 Aug 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) 설계문서adrrfcdesign-doc기술문서의사결정아키텍처 https://www.youngju.dev/blog/architecture/2026-08-15-guide-design-docs https://www.youngju.dev/blog/architecture/2026-08-15-guide-design-docs 설계 문서를 글쓰기 기술이 아니라 팀의 의사결정 인프라로 다룹니다. 1-pager·설계 문서·ADR·RFC 중 무엇을 언제 쓰는지, 리뷰를 어떤 절차로 운영하는지, 내려진 결정이 어떻게 만료되는지, 그리고 문서가 실패하는 여덟 가지 방식을 정리합니다. Sat, 15 Aug 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) 설계문서adrrfcdesign-doc기술문서의사결정아키텍처 https://www.youngju.dev/blog/architecture/2026-08-15-guide-testing-strategy.en https://www.youngju.dev/blog/architecture/2026-08-15-guide-testing-strategy.en Instead of picking a winner between the test pyramid and the testing trophy, this post decomposes the argument into the axes it actually turns on, so a team can derive its own ratio. It covers the definition of a unit, the four-part cost function, how far to take mocking, what to do with coverage numbers, using defect distribution data, and the operational rules for slow and flaky tests. Sat, 15 Aug 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) 테스트아키텍처testingtest-pyramidcoveragemocking https://www.youngju.dev/blog/architecture/2026-08-15-guide-testing-strategy.ja https://www.youngju.dev/blog/architecture/2026-08-15-guide-testing-strategy.ja テストピラミッドとテスティングトロフィーのどちらが正しいかを選ぶのではなく、その論争を実際の軸に分解して、チームが自分の比率を自分で決める方法を整理します。単位の定義、コスト関数、モックの使用範囲、カバレッジの数字、欠陥分布のデータ、遅く壊れやすいテストの運用規則までを判断基準中心に扱います。 Sat, 15 Aug 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) 테스트아키텍처testingtest-pyramidcoveragemocking https://www.youngju.dev/blog/architecture/2026-08-15-guide-testing-strategy https://www.youngju.dev/blog/architecture/2026-08-15-guide-testing-strategy 테스트 피라미드와 테스팅 트로피 중 무엇이 맞는지 고르는 대신, 그 논쟁을 실제 축으로 분해해 팀이 자기 비율을 스스로 정하는 방법을 정리합니다. 단위의 정의, 비용 함수, 목 사용 범위, 커버리지 숫자, 결함 분포 데이터, 느리고 깨지는 테스트의 운영 규칙까지 결정 기준 중심으로 다룹니다. Sat, 15 Aug 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) 테스트아키텍처testingtest-pyramidcoveragemocking https://www.youngju.dev/blog/database/2026-08-15-guide-caching-strategy https://www.youngju.dev/blog/database/2026-08-15-guide-caching-strategy PostgreSQL 18을 기준으로 캐시를 데이터베이스 쪽에서부터 올라가며 정리합니다. shared_buffers와 운영체제 캐시라는 이미 존재하는 캐시 계층, 머티리얼라이즈드 뷰라는 계산 캐시, 그 위에 외부 캐시를 얹을지 판단하는 기준, 그리고 캐시 도입의 진짜 난제인 무효화의 네 가지 실패 모드와 쓰기 경로 순서 문제, 캐시 스탬피드 방어까지 다룹니다. Sat, 15 Aug 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) 데이터베이스postgresql캐시성능튜닝아키텍처