docs: README 수정

Author: eunseozz

README.md

@@ -2,8 +2,9 @@
 
 ![compressed_image_under_1MB (1)](https://github.com/user-attachments/assets/b78436a3-0832-4696-b9ce-71a4e1e6f4a6)
 
-**Domido - 3D 도미노 시뮬레이터**
-
+**Domido - 3D 도미노 시뮬레이터**<br/>
+<sub>프로젝트 기간: 2025.05.19 - 2025.06.20</sub><br/>
+<br/>
 마우스로 직접 도미노를 배치하고, 중력의 법칙에 따라 쓰러지는 도미노의 연쇄 반응을 시뮬레이션할 수 있습니다.
 
 </div>
@@ -26,7 +27,6 @@
   - [2. 사용자가 클릭한 3D 위치에 도미노를 어떻게 정확히 배치할까?](#2-사용자가-클릭한-3d-위치에-도미노를-어떻게-정확히-배치할까)
   - [3. 멀티플레이시 사용자에게 정확하고 빠른 결과를 어떻게 줄 수 있을까?](#3-멀티플레이시-사용자에게-정확하고-빠른-결과를-어떻게-줄-수-있을까)
   - [4. 튜토리얼 로직을 기존 기능에 영향을 주지 않고 어떻게 설계할까?](#4-튜토리얼-로직을-기존-기능에-영향을-주지-않고-어떻게-설계할까)
-  - [5. 단축키 하나에 모든 도미노가 반응한다고? React key 문제 해결기](#5-단축키-하나에-모든-도미노가-반응한다고-react-key-문제-해결기)
 - [🔧 트러블슈팅 기록서](#-트러블슈팅-기록서)
   - [이슈 #1: \[WebAssembly "recursive use of an object detected" 에러\]](#-이슈-1-webassembly-recursive-use-of-an-object-detected-에러)
   - [이슈 #2: \[React 상태 업데이트 직후 socket.emit이 잘못된 상태로 실행되는 버그\]](#-이슈-2-react-상태-업데이트-직후-socketemit이-잘못된-상태로-실행되는-버그)
@@ -40,6 +40,8 @@
   - [커서만 움직였을 뿐인데, 왜 프레임이 떨어질까?](#-커서만-움직였을-뿐인데-왜-프레임이-떨어질까)
 - [회고록](#회고록)
 
+<br/>
+
 ## 주요 기능
 
 ### 🚀 핵심 게임플레이
@@ -488,6 +490,7 @@ rigidBodyRef.current.applyImpulse(
 - 방향 벡터를 직접 회전시켜 계산하는 방식은 여러 물리 오브젝트에 재사용 가능하며, 다양한 회전 각도를 가진 객체에도 일관된 동작을 보장합니다.
 - 향후 움직임 제어 기능을 구현할 때, 단순한 좌표 입력보다 회전과 방향의 관계를 먼저 고려한 설계가 필요하다는 점을 확실히 배웠습니다.
 
+<br/>
 
 ## 🔥 최적화
 
@@ -647,36 +650,40 @@ const throttledPointerOver = useMemo(() => {
 
 ### 최은서
 
-**가장 어려웠던 부분** 
-3D 렌더링과 실시간 멀티플레이 환경을 함께 다루는 구조 자체가 쉽지 않았습니다. 물리 엔진과 동기화된 사용자 입력을 빠르게 반영하면서도 성능 저하 없이 자연스러운 UX를 유지하는 것이 가장 큰 도전이었습니다. 특히, 렌더 타이밍 제어, 상태 일관성 유지 같은 세부 이슈들이 복합적으로 얽혀 있었습니다.
+**가장 어려웠던 부분**
+
+프로젝트를 진행하면서 각자 맡은 파트를 구현하는 데 집중하다 보니 팀 전체 흐름까지 신경 쓰는 데에는 다소 여유가 없었습니다.
+그러다 보니 서로의 코드가 맞닿는 경계 지점에서 맥락을 충분히 이해하지 못한 채 수정이 이뤄지는 일이 있었고  그로 인해 예상치 못한 오류나 오해가 생기기도 했습니다.
+가장 어려웠던 건 그럴 때 단순히 “누가 잘못했는가”를 따지기보다 어떻게 서로의 맥락을 존중하며 조율할 수 있을지에 대한 고민이었습니다.
 
 **배운 점**
 
-- React Query를 중심으로 한 단일 상태 흐름 설계의 안정성과 장점
-- 프레임 감지 방식보다 선언형 상태 구조가 유지보수에 유리하다는 점
-- 디바운싱, 낙관적 업데이트, UUID 선할당 등, 실시간 UX를 위한 다양한 기법들
+내 파트의 완성도만으로는 팀 프로젝트가 매끄럽게 흘러가지 않는다는 걸 배웠습니다.
+특히 하나의 작업이 팀원들에게 어떤 영향을 줄 수 있는지 미리 상상해보고, 필요하다면 의도와 맥락을 설명하는 것이 얼마나 중요한지 실감했습니다.
+결국 협업은 ‘코드를 공유하는 일’이 아니라 ‘맥락을 공유하는 일’이라는 걸 깨달았습니다.
 
 **개선하고 싶은 부분**
 
-- 초기 구조에 의존한 로직을 분리하여 확장 가능한 구조로 재정비
-- 선택, 이동, 튜토리얼 트래킹 로직을 일관된 흐름으로 재구성
-- 기능 단위로 모듈화 가능한 설계를 통해 테스트 가능성 향상
+작업을 진행할 때 “내가 맡은 파트”를 기준으로만 사고하지 않고 다른 사람의 흐름과 맞물리는 지점을 더 잘 의식하고 설명할 수 있도록 하고 싶습니다.
+또, 코드 변경 시에는 예상되는 영향 범위나 의도를 더 명확히 공유하여 오해 없이 논의할 수 있는 소통력을 갖추고 싶습니다.
 
 **다음 프로젝트에서 적용할 점**
 
-- 렌더링 타이밍 / 상태 흐름 / 실시간 입력 처리를 아키텍처 초기부터 유기적으로 설계
-- 상태 관리는 항상 단일 데이터 소스를 기준으로 정리
-- 기능 추가에 유연한 구조(선언형, 모듈화)를 우선 고려
-- “작동하는 것”보다 “관리하기 쉬운 것”을 기준으로 개발 진행
+- 코드를 수정하거나 구조를 바꿀 땐 영향받을 수 있는 파트를 먼저 살펴보고 필요한 설명을 함께 전달하기
+- 팀원 코드 리뷰 시에도 단순한 스타일 지적보다 흐름을 고려한 이해와 질문을 우선하기
+- PR이나 커밋 메시지에 단순한 변경 내역뿐 아니라 “왜”를 함께 기록해 맥락 전달하기
 
 ---
 
 ### 문인
 
-**가장 어려웠던 부분** 
+**가장 어려웠던 부분**
+
 프로젝트를 진행하며 가장 어려웠던 점은 모르는 것을 놓치지 않고 끝까지 이해하려는 태도를 일관되게 유지하는 것이었습니다. 팀원들과의 대화에서 생소한 개념이나 흐름을 이해하지 못했을 때, 회의 흐름을 끊지 않으면서도 필요한 질문을 던지는 타이밍과 방식에 신경을 많이 썼습니다. 처음에는 단순한 궁금증을 질문하는 수준이었지만, 점점 질문을 통해 맥락을 정리하고 논의에 기여하는 방향으로 나아가고자 노력했습니다.
 
-**배운 점** 이번 프로젝트를 통해 질문은 단순한 이해 수단이 아니라, 협업의 질을 높이는 도구라는 것을 깨달았습니다. 저의 질문이 팀원들의 생각을 끌어내고, 토론을 유도하고, 때로는 새로운 아이디어로 이어지는 경험을 하며 협업의 진정한 가치를 체감했습니다. 또한, 문제 상황에서 감정보다 근거와 논리로 접근하는 태도, 지식 격차를 메우기 위한 주도적 학습 자세 역시 실천을 통해 체득할 수 있었습니다.
+**배운 점**
+
+이번 프로젝트를 통해 질문은 단순한 이해 수단이 아니라, 협업의 질을 높이는 도구라는 것을 깨달았습니다. 저의 질문이 팀원들의 생각을 끌어내고, 토론을 유도하고, 때로는 새로운 아이디어로 이어지는 경험을 하며 협업의 진정한 가치를 체감했습니다. 또한, 문제 상황에서 감정보다 근거와 논리로 접근하는 태도, 지식 격차를 메우기 위한 주도적 학습 자세 역시 실천을 통해 체득할 수 있었습니다.
 
 **개선하고 싶은 부분**
 
@@ -694,7 +701,8 @@ const throttledPointerOver = useMemo(() => {
 
 ### 임승현
 
-**가장 어려웠던 부분** 
+**가장 어려웠던 부분**
+
 실시간 멀티플레이 환경에서의 사용자 경험을 최적화하는 것이 가장 큰 과제였습니다. 여러 사용자가 동시에 조작할 때 발생하는 지연이나 깜빡임 없이 부드러운 경험을 제공하는 데 집중했습니다.
 
 **배운 점**