0512 TIL

전예진

팀프로젝트 관련 고민

jira & github 연동

jira에 github 추가하는법
  1. 소프트웨어>깃허브 검색>add
  2. 이렇게 지라에 권한을 주면 지라 내에서 깃허브 브랜치와 커밋 메세지를 설정할 수 있음.
  3. 근데 깃허브 이슈란엔 자동 등록되지 않음. 지라 내에서 이슈를 오픈하고 클로즈해야됨.

    다들 지라 사용이 익숙치 않으니 깃허브 이슈란에서 태스크를 보는게 더 편할 것 같다고 생각함.

github 이슈란에서 이슈 등록시 jira에 자동 등록 플로우
용어 정리
  • 백로그란
    • 현재 진행 중인 작업과 앞으로 해야할 작업 목록 (아직 완료되지 않은 작업 항목들)
  • 스프린트란
    • 프로젝트를 작은 주기로 분할하여 모든 팀원이 정해진 기간동안 정해진 태스크를 몰두해서 작업하는 것.
  • 에픽? 스토리? 태스크?
    • 에픽: 큰 기능의 작업
      • 생각해보니 옛날에 1차 멘토링 브랜치 충돌 내기 실습을 했을 때 멘토님께서 epic 단위로 브랜치를 생성하신게 기억남.
      • 이 때도 에픽을 뜻을 찾아봤었는데 까먹고 있었음..
      • "에픽"이라는 단어는 원래 광범위한 이야기나 작품을 다룰 때 쓰인다고함. (마치 영화장르처럼)
      • 고로 소프트웨어 방법론에서도 이 단어의 본질적 의미를 그대로 차용한 것.
    • 스토리: 사용자 관점에서 구현해야 할 기능 단위. 에픽보다는 작고 태스크보다는 큰 단위.
    • 태스크: 가장 작은 작업 단위로, 실제 개발자가 수행할 구체적인 작업 항목.

jira & figma 연동

초기엔
  • 그냥 피그마에 있는 프레임을 복사해서 지라상에 이미지를 붙여넣었음.
  • 근데 이렇게 이미지 자체를 붙여넣으면 추후 디자인에 변동이 생겼을 때 수정사항을 즉각적으로 보지 못하는 문제가 발생함.
해결방법
  1. 아까 github 앱 추가한 방식이랑 똑같이 지라내에 figma 앱을 추가함.
  2. figma에는 jira 플러그인을 설치함.
  3. figma 상에서 프레임이나 컴포넌트를 클릭 후 왼쪽 사진처럼 지라 이슈를 링크한 후, 지라에 들어가보면 오른쪽 이미지처럼 지라상에서 피그마를 연동돼서 바로 볼 수 있음.
참고사항
  • 지라내에서 추가한 이슈가 바로 피그마상에 나타나지 않는 것 같음. 피그마를 한 번 껐다가 실행해야 동기화가 되는듯함.

네트워크 기초


이한빈

Jira 프로젝트 키와 네이밍 고려사항

Jira 프로젝트 키(Project Key)란?

  • 프로젝트 내 이슈를 식별하는 고유한 접두사
  • ex) PROJ-123
    • PROJ : 프로젝트 키
    • PROJ-123 : 티켓 넘버, 티켓, 이슈 등의 용어로 부를 수 있음
  • Jira 이슈 링크, URL, 검색 등 여러 곳에서 사용되므로 쉽고 직관적으로 설정하는 것이 중요

네이밍 고려 사항

  1. 영문 대문자 사용
    • 한글을 사용할 수 없음
    • 하이픈(-), 언더스코어(_) 사용 불가능
  2. 간결함 : 일반적으로 2~5자의 짧은 영문 대문자로 작성
  3. 식별성 : 프로젝트 주제, 목적, 팀 등과 직관적으로 연결되어야 함
    • APP : 앱 개발 프로젝트
    • WEB : 웹 프론트엔드 개발
    • DOCS : 문서화 관련 프로젝트
  4. 일관성 : 조직, 부서, 팀, 제품 별로 일관된 패턴 유지하는 것이 좋음

파일 구조

Atomic Design

  • 디자인 시스템과 UI 컴포넌트 개발에서 유래한 방법론
  • 작은 단위(atoms)부터 큰 단위(pages)로 계층적으로 조립하는 방식
  • 구조 예시 
    /components
  /atoms        // 버튼, 라벨, 아이콘 (가장 작은 단위)
  /molecules    // 입력 필드 + 버튼 조합 등 (작은 컴포넌트 묶음)
  /organisms    // 헤더, 카드 리스트, 폼 등 (섹션 수준)
  /templates    // 페이지 뼈대, 레이아웃
  /pages        // 전체 페이지 (라우팅 단위)
  • 장점 👍
    • 디자인 시스템화, 컴포넌트 재사용에 강함
  • 단점 🥲
    • 비즈니스 로직과의 직접적인 연결이 어려움 (UI 위주)

페이지 별 컴포넌트 분리

  • 라우트(페이지) 단위로 관련된 컴포넌트들을 디렉토리별로 관리
  • 페이지 중심으로 생각하며, 특정 페이지에만 사용하는 컴포넌트는 해당 폴더에 위치
  • 구조 예시 
    /pages
  /Home
    HomePage.jsx
    Banner.jsx
    ProductList.jsx
  /Profile
    ProfilePage.jsx
    Avatar.jsx
    ProfileInfo.jsx
  • 장점 👍
    • 유지보수와 파일 찾기 쉬움 (작업 중인 페이지만 보면 됨)
  • 단점 🥲
    • 동일 컴포넌트가 여러 페이지에서 필요할 경우 중복될 수 있음

FSD (Feature-Sliced Design, 관심사 분리)

  • 러시아 커뮤니티에서 주도한 설계 방법론
  • **도메인(기능)**과 레이어를 기준으로 구조화
  • 대규모 프로젝트에서 복잡한 비즈니스 로직 관리에 유리
  • 구조 예시 
    /src
  /features      // 사용자 관점의 주요 기능 (로그인, 결제 등)
    /auth
      ui/
      model/     // 상태 관리, 스토어 (예: Zustand, Redux)
      lib/       // 유틸 함수
      api/       // API 호출 로직
  /entities      // 비즈니스 엔티티 (User, Product 등)
  /shared        // 공통 유틸, 공통 컴포넌트
  /pages         // 라우트 페이지
  • 장점 👍
    • 대규모 프로젝트, 명확한 도메인 분리, 유지보수 용이
  • 단점 🥲
    • 소규모 프로젝트에서는 과한 설계가 될 수 있음