Vite를 사용하다 보면, 개발 서버에서 모듈이 실시간으로 빠르게 갱신되는 경험을 하게 된다. 이 과정의 핵심에 있는 함수가 바로 다. 이번 글에서는 Vite 개발 서버 내부에서 이 함수가 어떤 역할을 하는지, 어떤 순서로 동작하는지, 그리고 실제 사용하면서 주의할 점은 무엇인지까지 정리해본다. 란? Vite의 개발 서버는 브라우저 요청을 가로채어, 모듈을 실시간으로 변환하고 전달한다. 이때 호출되는 내부 함수가 이며, 다음의 흐름으로 동작한다: 모듈 로드 파일 시스템에서 요청된 URL에 해당하는 파일을 읽어들인다. 플러그인 적용 ( 훅) Vite에 등록된 각종 플러그인들의 훅을 순차적으로 실행한다. esbuild 변환 (필요 시) TypeScript, JSX, Vue SFC 등은 esbuild를 사용해 JS로 변환한다. 결과 반환 최종 코드와 소스맵, 메타데이터 등을 포함한 결과 객체를 반환한다. 내부 구조를 코드와 함께 보기 Vite의 구현을 간략히 보면 다음과 같다: 실제…

요즘 Type Challenge 를 통해 TypeScript를 공부하고있는데 빈번하게, infer 을 자주 다루게 되었다. 단순하게, infer 가 어떻게 사용되는지 뿐 아니라, 어떤 목적으로 만들어지고 사용되고 동작하는지 알아보도록 하자. 특정 타입을 찾는 infer 위 예시 코드를 보고, infer의 역할을 추론해보자. infer라는 단어 자체가 ‘추론하다’라는 의미를 가지고 있어, 프로그래머 입장에서는 타입스크립트에서 자동으로 무언가를 추론하거나, let U = 추론된 값과 같이 변수를 선언하는 키워드로 오해할 수도 있다. 하지만 실제로 infer는 변수 선언 키워드가 아니라, 조건부 타입 내부에서만 사용되는 특수한 키워드로, TypeScript 컴파일러에게 ‘이 위치에서 타입을 추론하라’고 지시하는 역할을 한다. 즉, 프로그래머가 직접 값을 추론하는 것이 아니라, 컴파일러가 해당 위치의 타입을 자동으로 추론하도록 위임하는 구문이다. What is Infer? infer 키…

회사 내에서 프론트엔드 공통 유틸리티 모듈을 통합 관리하는 작업을 맡으면서, 다음과 같은 요구사항이 생겼다. 여러 레포지토리에 중복된 로직을 하나로 추출해 관리하고 싶다. 패키지 단위로 분리해 모노레포 형태로 운영하되, 유연한 버전 관리가 필요하다. 외부 공개 없이 사내에서만 배포 및 사용 가능한 NPM 패키지 레지스트리를 갖추고 싶다. CI/CD 파이프라인에서도 안전하고 빠르게 배포되도록 자동화를 고려해야 한다. 이 문제를 해결하기 위해 선택한 조합이 바로 와 다. Lerna는 모노레포에서 패키지를 효과적으로 분리하고, 빌드/배포 파이프라인을 정리하는 데 탁월하다. 특히 independent versioning 전략을 활용하면 각 패키지의 변경사항만 추적하여 배포할 수 있어 유틸리티성 모듈 관리에 적합하다. 반면, Verdaccio는 사내 전용 NPM 레지스트리를 손쉽게 구축할 수 있는 도구로, 설정이 단순하며, Docker 기반으로 격리된 레지스트리를 운영할 수 있다. npmj…

IDE와 포매팅 도구의 다양성으로 인한 문제점들이 사내에서 발생하고 있었다. 서로 다른 IDE(WebStorm, VSCode 등)를 사용하는 환경에서 일관된 코드 스타일을 유지하기가 어려웠고, IDE별로 설정 파일을 따로 관리해야 하는 번거로움이 있었다. 또한 포매팅 차이로 인해 불필요한 코드 리뷰 지적이 발생하곤 했다. 이러한 상황에서 ESLint의 포매팅 규칙들이 Deprecated되면서, 새로운 대안이 필요하게 되어, 여러 대안들을 검토해보았다. Prettier + ESLint 조합은 기존 ESLint 규칙들의 마이그레이션 문제와 도구 간 충돌 방지를 위한 추가 설정이 필요함 @stylistic/eslint-plugin-ts는 아직 커뮤니티 초기 단계라 안정성 검증이 부족하고 별도 플러그인 관리에 대한 부담이 있음 이런 상황에서 Biome이라는 도구에 관심을 가지게 되었다. Biome은 웹 프로젝트를 위한 고성능 툴체인으로, JavaScript, TypeScript, JSX …

zustand의 immer 그리고 valtio에 대해 알아보기전에 불변성에 대해 간단히 알아보자. 불변성 불변성은 한번 생성된 데이터의 상태가 변경되지 않는다는 개념이다. 직접 수정을 금지하고, 변경이 필요할 때 새로운 객체를 생성해 원본 데이터의 무결성을 유지해야한다. 상태 변경이 직접적인 수정이 아닌 새로운 참조를 통해 이루어지므로, 상태 변화를 추적하고 예측하기 쉬워진다. React의 렌더링 최적화는 참조 비교에 기반한다. 불변성을 통해 객체 참조 변경을 빠르게 확인하기에, 불필요한 렌더링을 방지할 수 있다. 각 상태 변화에서 새로운 객체를 생성해 이전 상태를 보존할 수 있다. 이를 통해 상태 변화를 추적할 수 있다. 참조 비교 참조 비교는 메모리 관점에서 두 값이 동일한 메모리 주소를 가리키고 있는지를 확인하는 것을 의미한다. 원시값은 값 자체를 비교하고, 참조값은 메모리 주소를 비교한다. 얕은 비교는 객체의 최상위 레벨에서만 참조를 비교하고, 깊은 비교는 객체의 모든 중첩…

오늘은 프론트엔드 개발자로서 매일 마주하지만 깊이있게 들여다보지 않았던 package.json에 대해 이야기해볼 예정이다. 프로젝트를 다룰때마다 항상 핸들링하지만 그 이상으로 깊게 공부하지 않았기에 이번기회에 알아보려한다. package.json은 단순한 의존성 관리를 위한 파일을 넘어서 프로젝트의 전반적인 메타데이터와 설정을 관리하는 핵심 파일이다. 지금부터 package.json에 대해 깊이있게 알아보자 package.json의 생성 과정 package.json은 을 사용해서 생성하는 방법과 수동으로 프로젝트 루트 디렉토리에 직접 JSON 형식으로 생성하는 방법이 있다. JSON 문법에 에러 발생 가능성이 있기에 직접 생성보다는 패키지 라이브러리 init 명령어를 통해 생성하는 것을 추천한다. init을 이용해 package.json이 생성되는 과정을 살펴보자. (본론에서는 기본으로 많이 사용되는 npm을 예시로 설명하겠다.) 운영체제, 컴퓨터 시스템 등등 많은 조건에 따라 p…

useSyncExternalStore는 React 18에서 도입된 Hook으로, 외부 상태 관리 스토어와 React의 동시성 렌더링(Concurrent Rendering)을 안전하게 연동하기 위해 설계되었다. React 18의 동시성 렌더링 모드에서 외부 스토어의 상태 변경이 일관성을 해치는 문제 발생했는데, 이것을 Tearing 현상이라한다. (간혹 동일한 데이터를 보여주는 UI 컴포넌트들이 서로 다른 값을 표기하는 버그) Tearing 현상 Concurrent 모드에서 React는 렌더링을 여러 청크로 나누어 처리한다. 그리고 useEffect를 사용한 구독은 비동기적이며, Concurrent 모드에서 렌더링이 중단될 수 있다. 이렇게되면 서로다른 사용자마다 서로다른 데이터를 보게되는데, 데이터 일관성이 중요한 도메인에서는 치명적인 오류를 야기한다. 이런 문제를 useSyncExternalStore로 해결할 수 있다. useSyncExternalStore을 사용하면 상태 업데이…

React 상태가 변화하는 과정은 크게 5단계로 나눌 수 있다. 초기 트리거 단계: useState를 통한 상태 생성과 업데이트 객체가 만들어지는 단계 스케줄링 단계: 여러 상태 업데이트를 우선순위에 따라 배치 처리하는 단계 재조정(Reconciliation) 단계: Virtual DOM을 비교하여 실제로 변경이 필요한 부분을 파악하는 단계 커밋(Commit) 단계: 변경사항을 실제 DOM에 적용하고 부수효과를 실행하는 단계 완료 단계: 클린업을 수행하고 다음 업데이트를 준비하는 단계 이 각 단계들은 React가 상태 변화를 효율적이고 일관되게 처리하여 성능 최적화와 안정적인 렌더링을 보장하기 위해 설계되었다. 배치 처리 (Batching) 배치 처리는 여러 상태 업데이트를 하나의 리렌더링으로 그룹화하는 프로세스다. 배치 처리를 통해 불필요한 렌더링을 최소화하고, 메모리 할당을 줄이는 등의 장점을 누릴 수 있다. React 18에서는 모든 업데이트가 자동으로 배치 처리된다. 트랜…

zustand의 공식문서를 살펴보다, “Zustand는 React의 useSyncExternalStore 훅을 사용하여 React의 상태 관리 시스템과 원활하게 통합되어 Concurrent Mode와 호환된다” 는 내용을 보았다. Concurrent Mode라는 낯선 단어를 찾아보게 되었고, 생각보다 면접 질문으로도 쏠쏠하게 등장하기에 정리해보려한다! React 18에서 도입된 Concurrent Mode는 React 애플리케이션의 성능과 사용자 경험을 향상 시키기 위해 생긴 기능이다. 앞으로 Concurrent Mode가 무엇인지, 어떻게 작동하는지, 그리고 개발자들이 이를 어떻게 활용할 수 있는지 자세히보자. Concurrent Mode란 Concurrent Mode는 React가 렌더링 작업을 중단, 재개, 그리고 even 폐기할 수 있게 해주는 새로운 기능이다. React가 브라우저의 메인 스레드를 차단하지 않고 백그라운드에서 컴포넌트 트리의 여러 버전을 준비할 수 있게 …

나는 Zustand가 Provider이 필요하지 않는 상태관리 라이브러리라는 것을 알고 있었다. 하지만 갑자기 생각이 들었다. 왜?? 어떻게 동작하기에 상태관리 라이브러리가 필요하지 않을까? 궁금해서 찾아보다가, 좋은 내용이 많이 보여 공유해보려 한다. React 상태관리 일반적인 React 애플리케이션에서 상태는 아래 그림처럼 동작한다. 컴포넌트 내부 상태는 useState 훅을 사용하여 관리한다. 그리고 컴포넌트 트리를 통한 상태 전달은 props를 통해 하위 컴포넌트로 전달한다. 컴포넌트 외부에 상태를 전달하기 위해서 Context API를 사용하고, Provider 컴포넌트를 사용하여 하위 트리에 상태 제공하게 된다. 이러한 방식들은 모두 “React 컴포넌트 트리 내부에서 상태를 관리” 한다고 표현한다. Zustand로 상태관리하면? Zustand는 flux 패턴으로 동작한다. 클로저 내부의 state가 Store 역할, 사용자 정의 함수들이 Action 역할, se…

개발을 진행하다 보면 어떤 문제가 생겼을 때 어떤 기술 스택을 선택해서 구현하고자 하는 목표를 해결하기 위해 고민을 한다. 근래 개발을 하면서 익숙한 것들에 편안해져 고민 없이 선택하고 있다는 것을 느꼈다. 그래서 이번에는 프론트엔드 개발자 관점에서 서비스의 한 부분을 구현할 때 어떤 고민을 해서 기술 스택을 결정하고, 어떤 궁금증을 백앤드, 디자이너, 기획자, 데브옵스 등에게 전달해야 하는지 추론해보도록 하겠다. 주어진 문제 상황은 아래와 같다. 어떤 기술 스택을 선택해야 할까? 기술을 선택하기전에 FAQ 페이지에서 갖춰야 될 특성을 분석해보자. 특정 기능에 대해 분석하고 요구사항에 대한 명세를 만들어주는 것은 개발자의 근본적 역할은 아니라고 생각한다. 아래는 토스와 네이버의 채용페이지 FAQ 페이지 사진이다. 다른 회사의 FAQ 페이지를 더 찾아보면, 다른점이 분명 존재할 수 있겠지만 2개의 회사 공고에 공통적으로 보이는 요소는 페이지네이션, 검색, 상세페이지에서 FAQ를 …

HMR(Hot Module Replacement)이란? Hot Module Replacement(HMR)는 개발 환경에서 코드 변경 시 브라우저 전체를 새로고침하지 않고도 변경된 모듈만 업데이트하는 기능을 의미한다. 이는 특히 React와 같은 현대 프론트엔드 프레임워크에서 매우 유용하게 사용되고있다. HMR은 Webpack과 같은 모듈 번들러에서 지원하며, 개발 과정에서 생산성을 크게 향상시킨다. 수정사항을 웹에서 바로 확인할 수 있어, 불필요한 시간 소비를 방지할 수 있다. 그럼 HMR은 어떻게 동작할까? HMR이 편하게 해주는 것은 알겠다! 거의 2년여동안 HMR을 자연스럽게 사용하고 있는데, 궁금한적 없어 이참에 알아보자! 우선 개발자가 코드를 수정하고 저장하면, Webpack Dev Server는 변경 사항을 감지한다. Webpack Dev Server는 변경된 모듈만을 포함하는 업데이트를 생성하고 WebSocket을 토해 브라우저에 업데이트 정보를 전송한다. 브라우저는…

우선 해당 공부는 docker-test 레포를 이용했습니다. 문서를 열심히 읽어보아도 한 번의 실습이 더 값지다고 생각한다! 그렇기에 간단히 중요한 개념을 복습하고, 자주 사용하는 CRA부터 Elastic Beanstalk + Github Action + S3를 이용해 코드를 구현해보자 중요한 개념을 복습해보자. Dockerfile: 기본 이미지, 종속성 및 실행 명령을 지정하여 Docker 이미지를 빌드하는 지침을 포함 Docker 이미지: 애플리케이션을 실행하는 데 필요한 모든 것(코드, 라이브러리 및 종속성)을 포함하는 경량의 독립 실행형 패키지로, Dockerfile에서 빌드되며 버전을 지정할 수 있다. Docker 컨테이너: Docker 이미지의 실행 중인 인스턴스로, 컨테이너는 서로 격리되어 있고 호스트 시스템으로부터 격리되어 앱을 실행하기 위한 안전하고 재현 가능한 환경을 제공 Docker 레지스트리: Docker 이미지를 저장하고 배포하기 위한 중앙 집중식 리포지토…

회사에서 요즘 프론트개발자들이 DevOps 작업을 하는 것을 권장하고있다. 그래서 급하게 배포환경도 변경해보고, 자동화 배포도해보았다. 그러던 도중 이론이 너무 부족하다고 생각했는데, 현재 참여하고있는 SIPE 동아리에서 나와 비슷한 니즈가 있는 사람들과 함께 Docker와 DevOps에 대해 스터디 진행하기로 했다. 그런 내용들을 조금씩 기록해보도록 하겠다! 따라배우는 Docker 우선 사내에서 Docker를 사용하고 있는데 왜 사용하는지 모름. 귀여운 고래다. 끝 (필자는 귀여운게 싫다, 귀여운 것들은 이유가 있고 까볼수록 해악스럽기에) 그러던 와중 올리브영에서 진행된 AWSKRUG의 Next.js와 AWS ECS, CI/CD 행사에 다녀왔고, Git Action와 CDN까지 흐름을 살펴보는 시간을 가졌습니다 첫주에는 Docker가 뭐고, 왜 사용해야 하며, 기본적인 개념에는 어떤 것이 있는지 살펴보겠습니다. Docker를 왜 써? 간단하게 이해를 하면, 어떠한 프로그램을 다…

🚨 해당 게시글은 브라우저 렌더링의 모든 것의 후편이니 읽고 오시면 이해가 더 잘됩니다!! 먼저, 웹 렌더링이란 웹 페이지를 사용자가 볼 수 있는 형태로 변환하는 프로세스를 의미한다. 렌더링 방식에 따라 로딩 속도, 검색 엔진 최적화(SEO), 사용자 경험 등이 달라지기 때문에 우리는 방식을 선택할 때 많이 고민할 수 밖에 없다. 고민을 하다보면 CSR,SSR,SPA,MPA,SSG 등등.. 다양한 단축어에 대해 당황하게 된다. 모든 것들에 대해서 살펴보고 어떤 차이점이 있는지 알아보자. 해당 글은 웹 애플리케이션의 특성과 차이점(SPA,MPA) 에 대해 설명을 한 후에 웹 렌더링 방식(CSR,SSR,SSG,ISR,Universal Rendering) 에 대해 설명해보겠다! SPA vs MPA (웹 애플리케이션 특성) 9.gif Single Page Application(SPA) SPA는 하나의 브라우저 내에서 동작하는 애플리케이션이며 사용하는 동한 페이지 로딩을 필요로 하지 않는…

Web에 대해 공부하면서 렌더링이 무엇이고 어떻게 작동되는가? 에 대한 궁금증을 가지지 못했다. 취업을 해야된다는 막연한 생각때문에 과정없이 면접에 자주나오는 키워드만 암기했다. CS에 기초지식이 없으니 누군가에게 대답하는 형식으로 달달 외우기만 했다. 조금만 응용되어도 이론이 복잡하게 꼬여 버렸다. 그래서 언젠가는 이런 정리 안 된 내 지식을 정리해야지🔥🔥 라는 계획을 하다 이번에 렌더링이라는 키워드를 연관성에 맞춰서 상세하게 기록해보려고 한다. 작은 소망이라면 렌더링, 브라우저, DOM 등 다양한 키워드에 대해 궁금할 때 나의 글이 생각나고 흐름을 파악하면 좋겠다. 웹 렌더링이라는 주제를 정한 후 어떠한 순서로 웹 렌더링에 대해서 글을 써야 할까? 에 대해 많은 고민을 하였다. 이론적인 단계로 쓸 수 있고, 중요한 순서대로도 쓸 수 있다. 하지만 내가 선택한 방법은 내가 공부하면서 느꼈던 키워드의 연관성을 흐름에 맞춰서 기록해보려 한다. 예를들어! 🍎 사과에 대해서 글을 쓰고…

CRA(Create React App) 1.svg 2016년 이전에는 Create React App(CRA)가 등장하기 전에 프론트엔드 개발 환경이 통합되어 있지 않아서, 기존 앱에 리액트를 추가하기 위해 npm에서 import한 후 기존 빌드 구성을 수정하는 번거로움이 있었다고 한다! 여러 도구를 설치하고 JSX를 사용하기 위한 사전 설정을 진행하며, 개발과 프로덕션 환경을 다르게 구성해야 했다. 또한, 린트 설정 등 다양한 작업이 필요했는데, 이는 일반 사용자들에게는 쉽지 않은 작업이었을 것 같다. 시간이 지나 똑똑한 개발자들이 보일러플레이트 저장소를 만들어 공유하고 복제함으로써 시간을 단축할 수 있었지만, 업데이트가 어려워 빠르게 변화하는 생태계에 대응하는 것도 쉽지 않았을 것 같다. 이러한 어려움을 해결하기 위해, CRA(Create React App) 가 등장하게 되었다. CRA를 사용하면 리액트 애플리케이션을 쉽게 생성하고 필요한 설정 작업을 자동화할 수 있다. 이를 통…

첫 회사에서는 Azure 환경으로 배포했고, 개인 프로젝트에서는 클라우드와 인프라에 대한 개념이 부족해 heroku, github, netlify, vercel 등 간단하게 배포해서 프로젝트를 완성했다. 지금 회사에서는 pipeline을 사용하지 않고 pem,ppk로 인증을 한 후에 PuTTY와 winSCP를 이용해서 배포했다. 사용해보니 불편한 점도 너무너무 많아서 점진적으로 바꿔야겠다는 생각이 들게 되어 바꾸었고, FE 개발자의 아등바등 DevOps 경험을 기록으로 남겨볼려고 한다. 사내의 요구사항으로 인해 자동화로 CI/CD를 하지는 않았지만, 반자동화로서 성능과 효율성을 위해 변하는 배포과정을 살펴보자!! 참고로 저는 DevOps, 백앤드에 대한 지식이 부족합니다. 큰 프로젝트는 아니었지만, 필요성을 느껴서 사내 스터디처럼 공부처럼 이루어낸 것이므로 잘못된 정보가 있을 수 있으니, 모든 충고와 조언 감사히 받아들이겠습니다!!   처음에는요.. FE에서 develop에 개발…

난 왜 zustand 공부를 시작했을까?   회사에서 위처럼 회사에서 useState, useEffect, useRef 등 Hook을 하나의 컴포넌트에서 남발해서 사용하고 있다는 것을 알게 되었다. (위 사진은 극히 일부의 코드를 수정해서 보여준란걸..😂) 그렇게 되니 컴포넌트 내부의 요소를 변경하거나, 렌더링이 일어날 때 state, ref의 동적인 값들이 초기화되거나 생각하지 못한 데로 작동하게 되어버리게 되었다. 거기에 새로운 기능 개발을 하게 되었을 때 많은 요소 영향력을 생각해야 되게 되고, useEffect의 의존성 배열이 무한히 추가되는 현실까지 직면하게 되었다. ㅠㅠ 이런 상황까지 되어버리니 회사 내부에서는 프로젝트에 상태관리를 도입해서 렌더링이 발생하는 시점, 변수의 선언, 전역 변수의 props 전달 등 많은 것들을 효율적으로 관리 할 수 있다고 판단해 상태를 중앙에서 변수를 관리하자는 이야기가 나왔다. 이런 회의를 거쳐서 여러 가지 상태관리 라이브러리가 후보군에…

React 19에 도입될 Hooks   use(Promise) & use(Context) Form actions useFormState useFormStatus useOptimistic Bonus: Async transitions 마무리 ✨ 잠깐!!! 모든 코드는 테스트 환경 에서 테스트 가능합니다. (단, React 19에 포함될 예정이지만 최종 release 전에 API가 변경될 수 있음)   use(Promise) & use(Context)   Reference 컴포터는의 호출을 사용하여 Promise 또는 Context 와 같은 리소스의 값을 읽음 use는 if문과 같은 조건문 루프 안에서 호출 가능 use를 호출하는 함수는 컴포넌트 또는 Hook 이어야 함 Promise와 함께 호출될 때, use는 Suspense 및 Error Boundaries와 통합된다. use가 pending 상태일 때 Promise가 전달완료 될 때까지 일시중단되고, use를 호출하는 컴포넌트가…

함수형 컴포넌트의 상태 관리 pjqnl16lm7 - CodeSandbox 클래스형 컴포넌트는 render() 메서드를 통해 상태 변경을 감지 Props 는 react 에서 불변 / this 는 변경가능, 조작가능 함수형 컴포넌트는 렌더링이 발생하면 함수 자체가 다시 호출 render 될 때의 값을 유지 ⇒ 상태를 관리하려면 함수가 다시 호출되었을 때 이전 상태를 기억해야 함 ⇒ useState 는 클로저를 통해 이 문제를 해결 클로저 : 내부 함수에서 상위 함수 스코프의 변수에 접근할수 있는 것을 의미 왜 hooks 를 사용해야 될까? UI 의 상태 관련 동작 및 부수 작용을 캡슐화하는 가장 간단한 방법 고차 컴포넌트(HOC)의 복잡성을 피할 수 있음 props 로 전달되는 속성들이 명확하지 않고 중복됨 컴포넌트 구조의 복잡성을 유발 계층의 변화없이 상태 관련 로직을 재사용할 수 있음 useState 란 무엇인가 React 공식 문서 React 내부에서 상태를 관리하는 방식을 추…

What is Single Thread? javascript 는 Single Thread 기반 언어 ⇒ 한 번에 하나의 작업만 수행 가능 하지만! 동시에 병렬처리 해야 될 때가 있다 그럴 때 javascript는 비동기 함수(setTimeout, ajax, Promise 객체 등)를 이용 동기와 비동기 동기(Synchronous) : 먼저 시작된 작업이 끝날 때까지 기다리다가 새로 시작(한번에 여러작업이 아닌 하나씩) 비동기(Asynchronous): 작업이 끝날때까지 기다리지 않고 다음 작업 수행(한번에 여러작업을 처리함) 자바스크립트의 비동기 내장함수 자바스크립트는 비동기 내장함수를 제공함 ⇒ setTimeout, XMLHttpRequest, fetch() XMLHttpRequest 현재는 잘 사용하지 않음 관련 링크 : https://7942yongdae.tistory.com/67 setTimeout / clearTimeout setTimeout() 함수는 특정 코드를 바로…

Branch 구조와 전략을 세워보자! 코드를 작성하다보면 엄청나게 많은 Branch를 만들어야한다. 어떻게 구조를 잡아야할지 알아보자! Branch Structure(Gitflow 전략) 제품의 안정된 버전을 유지하는 브랜치, 배포 가능한 코드만을 허용하며, 직접적인 작업은 X 개발의 중심이 되는 브랜치, 다른 개발자들과의 협업 및 새로운 기능 개발을 위해 사용 새로운 기능 개발을 위한 branch, 개별 기능 또는 작업 단위로 생성 되며 develop 에서 분기됨 개발이 완료되어 pr 이 merge 되면 해당 feature branch 는 삭제(줄기관리) feature 은 작은 단위의 issue 가 된다. 올바른 branch 관리를 하기위해 각 feature 은 해당하는 이슈의 문제만 해결한다! 배포를 준비하기 위한 branch, 배포 전 마지막 테스트와 버그 수정 진행 develop 에서 분기되며, 완료되면 develop과 master 로 병합. 해당 작업을 진행할때는…