• [x] PoC 브랜치명

  • PoC
  • experiment

  poc/face-gesture-control
  poc/realtime-video-connect
  poc/offline-p2p-networking-layer
  
  main
  develop
  poc/~~~~
  poc/face-gesture-control <- poc/oyobbeb/dev-6 (개인 브랜치 컨벤션 아래 참고)
  

• [x] 브랜치 전략

  • release (배포 - linear history 유지)
  • main (hotfix + release 분기점 - linear history 유지)
  • develop (개발할 때만 1차 배포 전까지 default 유지)
  • 기능, 리팩터 등 브랜치는 아래 컨벤션 적용

  poc/oyobbeb/dev-6
  feature/dev-6
  refactor/dev-6
  
  같은 Issue를 진행할경우 [prefix]/[username]/[issue-name]
  

• [x] 코드 스타일 (lint)

  • SwiftFormat Package 의존성 추가 및 스크립트 추가 (빌드시 실행) (Formatter)
  • SwiftLint Package (Linter)

• [x] 커밋 메세지 컨벤션 혹은 스타일 (어떤 형태로 작성할지)

  • [x] “무엇”을 구현했는지 보다는 “왜” 이렇게 어떤 상황 때문에 구현한지 기술
  • [x] prefix: https://www.conventionalcommits.org/en/v1.0.0-beta.4/
  • [x] https://linear.app/docs/github#link-through-pull-requests
  • [x] 하나의 이슈를 진행할 때 아래의 기준을 적용
    • [x] 연속된 커밋의 경우 refs, 마지막 이슈와 관련된 커밋은 closes magic word 사용

• [x] Xcode 버전 통일 및 개발 환경 통일

  • [x] Xcode 26.2 (17C52),
  • [x] iOS 18.0
  • [x] Swift Version: 6.2.1

• [x] 머지 전략 - rebase

• [x] PR 리뷰 작성시 P0, P1 같은 기준 설정?

  • P1: 꼭 반영해주세요 (Request changes)

  리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

  • P2: 적극적으로 고려해주세요 (Request changes)

  작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

  • P3: 그냥 사소한 의견입니다 (Approve)

  작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

  • https://blog.banksalad.com/tech/banksalad-code-review-culture/
  • 마지막에 칭찬 달아주기 좋았던 점! LGTM 도 가능

• [x] 의존성 관리 방식 (Tuist 및 모듈화 고려)

  • SPM or Tuist
  • CocoaPods는 지원 제약 때문에 제외
  • Tuist 왜 도입했나에 대한 질문에 대해 답변할 수 있는지?
  • 모듈화를 제대로 가져가고 모듈별로 빌드를 할 계획이 있으면 Tuist가 좋다고 생각이 되나
  • 빌드가 Tuist가 중분 빌드를 해서 빌드 시간이 단축이 되나, 작은 앱은 중분 빌드가 필요한가..?
  • 크게 모듈이 많을 것 같지 않고 샘플 앱 빌드 계획이 없다면 오버엔지니어링이라고 판단할 수 있다.
  • SPM → Tuist
  • 모듈을 나누고, Tuist만 안쓰는 대신 Xcode Project로 손수 관리하다가 Tuist로 이전하면 편할것 같은데 그럴거면 처음부터 Tuist 하는게 나을 것 같기도 하고.
  • Project 파일 충돌에 쓰는 리소스와 비용을 생각하면 Tuist 쓰는게 맞다고 생각한다.
  • Tuist, 모듈화
  • 모듈화가 왜 좋을까? 모듈화는 정말 필요할까? 우리는 오버엔지니어링으로 접근하는 것이 아닐까?
  • https://toss.tech/article/slash23-iOS
  • 모듈화 보다는 충돌 방지에 목적을 두고 쓰고 싶다.
  • 게임 엔진 모듈화를 고려한다면 Tuist 적극 지향 하는 방향 으로 진행

• [x] 스타일 가이드

  • https://github.com/airbnb/swift?tab=readme-ov-file#naming

• [x] 문서화 기준

  • Public API 는 doc-comment (option + cmd + / )
  • Private중에서 복잡한 로직이 담겨있다면 주석 상세히
  • 게임 엔진과 같은 복잡한 모듈에 DocC 도입
    • https://oliveyoung.tech/2025-03-28/swift-docc/

질문사항:

• AI 활용도 적정선 혹은 기준 정하기? (AI.md 파일을 코드베이스에 포함시킬지 말지)
  • https://p-iknow.notion.site/2-2661aaa68f2f806fb62ad3c51bc32e4d
  • https://docs.google.com/presentation/d/1xWmcBbSCKgQfN1WOdvG-_uF9AeQwWIm7TdNArQyAMII/edit?slide=id.g3793532b621_0_304#slide=id.g3793532b621_0_304
• 이러한 AI 활용 마크다운 파일을 코드 레포에 포함시키는 방향이 적절할지 질문하기

TODO:

• 아키텍처 & 디렉토리 구조 원칙
• CI/CD