diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/kimdokyung-week1.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/kimdokyung-week1.md
new file mode 100644
index 00000000..5f2d03d4
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/kimdokyung-week1.md
@@ -0,0 +1,21 @@
+# Week1 — Chapters 1~3
+
+## 1. 내가 이해한 흐름
+
+1장을 읽을 때는 “최고의 설계” 대신 “덜 나쁜 선택”을 골라 기록하라는 메시지가 계속 반복된다고 느꼈다. 운영·분석 데이터 구분, ADR, 피트니스 함수 같은 도구는 그런 선택을 기록하고 지키기 위한 장치처럼 다가왔다. 2장은 아키텍처 퀀텀을 설명하면서 DB, UI, 동기 통신을 공유하면 별도 서비스라도 결국 같은 퀀텀으로 묶인다고 이해했다. 3장은 모듈화를 설득할 때 시장 출시 속도, 가용성, 확장성 같은 비즈니스 동인을 먼저 말해야 한다고 느꼈고, 모놀리식에서 서비스 기반, MSA로 넘어갈수록 격리 이점과 운영 부담이 동시에 커진다는 그림이 그려졌다.
+
+## 2. 읽으면서 적어둔 포인트
+
+머리에 남은 메시지는 “최선”보다 “덜 나쁜 조합”을 골라 기록해야 한다는 경고였다. 또 아키텍처 퀀텀을 독립 배포 가능한 아티팩트로 이해했고, DB·UI·동기 통신이 엮이면 결국 한 덩어리라고 받아들였다.
+
+## 3. 주요 인사이트
+
+ADR은 짧아도 꾸준히 남기는 게 낫다고 느꼈다. 두세 문단만 적더라도 나중에 “왜 이 선택을 했는지”를 되짚는 데 충분한 힌트가 된다. 피트니스 함수를 쓰면 감(感)에 의존하는 시간을 줄일 수 있다. 렌더 프레임이나 로딩 시간을 CI에서 자동 측정하면 추측 대신 숫자로 구조를 검증할 수 있다. MSA는 결국 타이밍 싸움이라는 걸 다시 느꼈다. 팀 규모가 작을 때 퀀텀을 늘리면 운영 비용이 훅 뛰니 MVP 단계에서는 의도적으로 한 덩어리로 묶어둔다. 모듈화 메시지는 시장 언어로 변환해야 설득력이 생긴다. “테스트가 쉬워요”보다 “출시 주기가 줄어요” 같은 표현이 훨씬 잘 먹힌다는 걸 실제로 겪었다.
+
+## 4. XR 프로젝트에 적용
+
+실시간 렌더링 상태와 행동 로그를 다른 저장소·스키마로 나눠 응답 속도와 배치를 분리할 계획이다. ADR 템플릿은 `문제 → 옵션 → 선택 이유 → 부작용 → 재검토 조건` 순으로 짧게 쓰면서도 핵심을 잡을 생각이다. CI에서는 WebXR 테스트 씬을 돌려 평균 FPS와 CPU·GPU 사용률을 측정하고 기준선을 벗어나면 실패 처리하도록 자동화하려 한다. 콘텐츠 업로드와 세션 매칭이 같은 DB·UI를 쓰고 있으니, 지금은 한 퀀텀으로 묶고 나중에 필요할 때만 쪼갤 예정이다.
+
+## 5. 논의 주제
+
+팀 인원이 적을 때 “가벼운 ADR”을 어느 정도 길이로 쓰면 실제로 도움이 되는지 궁금하다. 세 문단 정도면 충분하다고 느꼈는데 다른 분들은 어떻게 기록하고 있는지 듣고 싶다. XR 도메인에서 모듈화 동인을 어떤 지표나 사건을 보고 결정했는지 궁금하다. 콘텐츠 업로드와 실시간 세션을 언제 분리했는지, 현장에서 겪은 기준을 공유해주면 좋겠다.