chore: 트렁크 기반 개발로 전환 (#236)

* chore: 트렁크 기반 개발로 전환 — dev CI/CD 제거, README 브랜치 전략 갱신

dev/main 두 장수 branch를 cherry-pick으로 동기화하던 방식이 계속
내용 불일치(cherry-pick hell)를 낳아 폐기한다. main을 유일한
trunk로 삼고, 모든 작업은 main에서 분기한 짧은 수명 feature
branch로 진행한다.

dev-ci.yml/dev-cd.yml은 AWS CodeDeploy/EC2 기준으로 작성된
워크플로인데 실제로는 더 이상 배포에 쓰이지 않는 죽은 파일이라
(staging은 Render가 담당) 함께 제거했다.

* docs: README 브랜치 전략 섹션을 트렁크 기반으로 갱신

---------

Co-authored-by: 나미 <dnska6657@gmail.com>

Author: unam98

.github/workflows/dev-cd.yml

@@ -152,31 +152,20 @@
 
 ## 🌳 Branch
 
-🌱 git branch 전략
+🌱 Trunk-Based Development
 
-`main branch` : 운영 서버 배포 단위 branch
+`main branch` : 유일한 trunk. 항상 배포 가능한 상태를 유지하며, 운영 서버와 staging 서버 모두 이 branch에서 배포된다.
 
-`dev branch` : 주요 개발 branch, main merge 전 거치는 branch, test 서버로 배포되는 branch
+`feature branch`: 각 작업 단위의 짧은 수명 branch. `main`에서 분기해 하루~수일 내에 PR로 병합한다.
 
-`feat branch`: 각자 개발 branch
+- `main`에서 분기, `feat/#issue번호-작업요약` 형식으로 branch 생성
+  - 브랜치명이 `test/...`로 시작하면 GitHub ref 경로 충돌이 나므로 테스트 관련 branch는 `tests/...`(복수형) 사용
+- 작업 완료 후 PR 생성 (base: `main`)
+  - CI(`build` status check)를 통과해야 병합 가능
+  - 미완성 기능은 브랜치를 오래 살려두지 말고, feature flag로 감싸 `main`에 빠르게 합친다
+- 리뷰 완료 후 squash merge, 병합된 branch는 삭제
 
-- 할 일 issue 등록 후 issue 번호와 isuue 이름으로 branch 생성 후 작업
-  - ex) feat/#`issue num`-`isuue name(기능요약)`
-- 해당 branch 작업 완료 후 PR 보내기
-  - 항상 local에서 충돌 해결 후 → remote에 올리기
-  - reviewer에 서로 tag후 code-review
-  - comment 전 merge 불가!
-  - review반영 후, 본인이 merge.
-
-### branch 구조
-
-```jsx
-- main
-- dev
-- feat
-   ├── #1-isuue name1
-   └── #2-isuue name2
-```
+과거에는 `dev`/`main` 두 개의 장수 branch를 cherry-pick으로 동기화하는 방식이었으나, 두 branch가 내용상 계속 어긋나는 문제(cherry-pick hell)가 반복되어 폐기했다. staging 배포도 `main` push를 기준으로 트리거된다.
 
 </aside>
 <hr>