일반적으로 TypeScript 프로젝트에서 코드를 작성하고 실행하기 위해서는 컴파일 과정을 거쳐야만 합니다. 이 컴파일 단계는 개발 시간을 소비하며, 작은 수정 사항을 테스트하려면 번거로울 수 있습니다.

ts-node 는 TypeScript개발자들에게 큰 편리함을 제공하는 이 도구입니다. TypeScript 코드를 더 이상 컴파일하지 않아도 빠르게 테스트하고 개발할 수 있게 해줍니다. 그러면서도 TypeScript가 제공하는 정적 타입 체크와 편의성을 그대로 유지할 수 있습니다.

아래에서는 ts-node를 활용한 간편한 TypeScript 개발 환경 구축 방법과 사용법을 소개하겠습니다.

▽ ts-node란?

• TypeScript 코드를 JavaScript로 컴파일하지 않고 직접 실행시키는 라이브러리
• TypeScript를 사용하여 Node.js 환경에서 바로 TypeScript 코드를 실행할 수 있게 해주는 도구

일반적으로 TypeScript는 JavaScript로 컴파일된 후에 Node.js에서 실행되지만, ts-node를 사용하면 TypeScript 코드를 직접 실행할 수 있습니다. 이를 통해 개발자는 코드를 작성하고 변경사항을 빠르게 테스트하면서 별도의 컴파일 단계 없이 즉시 결과를 확인할 수 있습니다.

ts-node를 사용하면 TypeScript 파일(.ts 확장자)을 바로 실행할 수 있고, 내부적으로 TypeScript 컴파일러를 사용하여 코드를 컴파일하고 실행합니다. 이는 개발 단계에서 편리하게 TypeScript 코드를 작성하고 테스트하는 데 도움이 됩니다.

▽ ts-node 설치 명령어

npm i ts-node

npm install ts-node

⭐️ 글로벌 설치 (npm install -g)

npm install -g ts-node

이 방법은 패키지를 시스템 전체에서 사용할 수 있도록 글로벌하게 설치합니다. 이 패키지들은 시스템 경로에 설치되며 어느 프로젝트에서나 사용할 수 있습니다. 글로벌 패키지는 주로 커맨드 라인 도구 또는 개발 환경 설정 도구와 같은 경우에 사용됩니다.

▽ ts-node 사용 방법

아래와 같은 명령어를 사용하여 ts-node를 실행할 수 있습니다.

ts-node your-typescript-file.ts

특정 폴더에 있는 파일을 실행하려면 다음과 같이 폴더를 지정할 수 있습니다.

ts-node src/your-typescript-file.ts

위 명령어는 선택한 TypeScript 파일을 TypeScript 컴파일러를 사용하여 즉시 실행합니다. 이를 통해 개발 중인 TypeScript 코드를 신속하게 테스트하고 결과를 확인할 수 있습니다. 운영 환경에서는 더 정교한 빌드 및 배포 프로세스를 고려하는 것이 좋습니다.

커밋 메시지 컨벤션은 개발자들 간의 일관성, 협업 효율성, 코드 이력의 가독성을 향상시키는 중요한 요소입니다. 프로젝트에 맞는 컨벤션을 정의하고 사용함으로써, 개발과 관리 과정에서의 혼란을 최소화하고 효율성을 높일 수 있습니다.

커밋 메시지 컨벤션(Commit Message Convention)

프로젝트에서 일관성 있고 이해하기 쉬운 커밋 메시지를 작성하기 위해 사용되는 규칙

커밋 메시지 컨벤션을 사용하면 팀원들 간의 커밋을 쉽게 파악할 수 있고, 변경 내용을 추적하고 관리하기 쉬워집니다.

커밋 메시지 컨벤션을 사용해야 하는 이유

• 가독성과 이해성 향상 일관된 커밋 메시지 형식을 사용하면 다른 개발자들이 변경 내용을 빠르게 이해할 수 있습니다. 커밋 메시지를 읽는 사람들은 각 커밋이 어떤 작업을 수행했는지 파악할 수 있으며, 필요한 정보를 쉽게 찾을 수 있습니다.

• 변경 이력 추적 커밋 메시지 컨벤션을 사용하면 변경 이력을 추적하고 관리하기 쉬워집니다. 각 커밋이 어떤 유형의 변경을 반영하는지 명확하게 구분할 수 있으며, 필요한 경우 특정 타입의 커밋만 필터링하여 확인할 수 있습니다.

• 협업의 원활함 팀이나 다른 개발자들과 협업할 때, 일관된 커밋 메시지 컨벤션을 사용하면 의사소통이 원활해집니다. 모두가 동일한 형식과 규칙을 이해하고 사용함으로써, 변경 사항에 대한 이해와 협력이 강화됩니다.

• 문제 해결과 유지 보수 용이성 커밋 메시지 컨벤션을 사용하면 코드의 버그 수정, 기능 개선, 리팩토링 등의 작업을 명확하게 기록할 수 있습니다. 이를 통해 문제 발생 시 커밋 로그를 참조하여 문제 해결 과정을 추적하고, 코드의 유지 보수를 효율적으로 진행할 수 있습니다.

Conventional Commit 구조

<type>: <Subject> -> 제목  

body(생략 가능) -> 본문  

footer(생략 가능) -> 꼬리말

여기서 <type> 은 커밋의 성격이나 유형을 나타내는 것이고, <Subject> 는 커밋에 대한 간단한 설명입니다.

1. Commit Type

반적으로 사용되는 커밋 타입은 다음과 같습니다. 프로젝트의 특정 요구 사항이나 팀의 개발 프로세스에 따라 추가적인 커밋 타입을 정의할 수도 있습니다.

• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 변경
• style: 코드 포맷팅, 세미콜론 누락 등 스타일 변경
• refactor: 코드 리팩토링
• test: 테스트 코드 추가 또는 수정
• chore: 빌드 스크립트, 패키지 매니저 설정 등의 변경

예시)
feat: 사용자 등록 기능 추가
fix: 로그인 버그 수정

2. Subject Rule

• 일반적으로 50자를 넘지 않도록 작성
• 마침표 및 특수기호 사용 X
• 첫글자 대문자, 현재 시제로 명령문을 사용
• 간결하게 작성

3. Body Rule(생략가능)

• 가독성을 위해 각 줄은 72자를 넘지 않도록 작성
• 필요에 따라 여러 줄로 작성
• 본문과 제목 사이에는 한줄을 비워 구분
• 커밋에 대한 상세한 변경 사항, 이유, 방법 등을 기록

4. Footer Rule(생략가능)

• 커밋과 관련된 메타 정보를 기록
• 주로 이슈 번호, 참조 링크, 특정 이벤트와 연결된 정보

타입스크립트의 핵심인 타입은 다양한 종류가 있으며, 주로 : 기호를 사용하여 자바스크립트 코드에 타입을 정의하는 방식을 타입 표기(Type Annotation)라고 합니다.

이를 통해 변수, 함수 매개변수, 함수 반환 값 등에 타입 정보를 명시할 수 있습니다. 아래에는 타입스크립트의 주요 타입 종류와 타입 표기에 대한 설명을 제공합니다

1. 숫자

number : 숫자 타입을 나타냅니다.

let num: number = 1;

2. 문자열

string : 문자열 타입을 나타냅니다.

let str: string = 'hello';

3. Boolean

boolean : 불리언 타입을 나타냅니다.

let isLogin : boolean = false;

4. 배열

array : 배열 타입을 나타냅니다. 배열 요소의 타입을 함께 명시해야 합니다.

let arr: Array<number> = [10 , 20, 30];
let arr: number[] = [10, 20, 30];
let arr: Array<string> = ["lion", "tiger"];
let arr: [string, number] = ["sejong", 182];

5. 튜플

tuple : 고정된 요소 수와 타입 순서를 가진 배열을 나타냅니다.

let person: [string, number] = ["John", 30];

6. enum

enum : 열거형 타입을 나타냅니다. 사전에 정의된 값들 중에서 선택할 수 있습니다.

enum Color {
  Red,
  Green,
  Blue
}
let color: Color = Color.Red;

7. any

any : 모든 타입을 허용하는 동적 타입을 나타냅니다. 주로 타입 안정성이 필요하지 않은 경우에 사용됩니다.

let value: any = "Hello";
value = 10;

8. void

void : 반환 값이 없는 함수를 나타냅니다.

function sayHello(): void {
  console.log("Hello");
}

9. null, undefined

null 과 undefined : 각각 null과 undefined를 나타냅니다.

let data: null = null;
let status: undefined = undefined;

10. 객체(object)

object : 객체 타입을 나타냅니다.

let person: { name: string, age: number } = {
  name: "juny",
  age: 30
};

11. 함수(function)

function : 함수 타입을 나타냅니다. 매개변수와 반환 값의 타입을 함께 명시해야 합니다.

let greet: (name: string) => void = function(name) {
  console.log("Hello, " + name);
};

12. union, intersection

union 과 intersection : Union(|)은 두 개 이상의 타입 중 하나를 허용하는 타입을 나타내며, Intersection(&)은 두 개 이상의 타입을 동시에 포함하는 타입을 나타냅니다.

let value: string | number = "Hello";
let person: { name: string } & { age: number } = { name: "John", age: 30 };

타입스크립트(TypeScript)란?

• Microsoft에서 개발한 자바스크립트(JS)의 상위 집합 언어
• 정적 타입 시스템을 가지며, 이를 통해 코드의 안정성과 가독성을 높임
• 대규모 프로젝트의 개발과 유지보수를 용이하게 해주는 기능을 제공
• 라이언트 사이드와 서버 사이드를 위한 개발에 사용
• 자바스크립트와의 호환성이 높아 이미 존재하는 자바스크립트 코드에 대해 점진적으로 타입스크립트를 도입할 수 있음

타입스크립트는 자바스크립트의 모든 단점을 보완해 만든 언어라고 할 수 있습니다. 동적인 자바스크립트에 타입을 미리 부여하여 컴파일 시 발생하는 에러들을 잡을 수 있습니다.

타입스크립트를 왜 사용해야 할까?

동적인 자바스크립트는 웹 브라우저에서 직접 실행 가능하며, 런타임 속도가 빠르고 배우기 쉬운 문법을 가지고 있습니다. 이러한 특징을 통해 개발자들은 빠르게 웹 페이지의 동적인 기능을 구현할 수 있습니다.

하지만 단점도 명확합니다. 타입을 명시적으로 선언하지 않기 때문에 코드 실행 시에만 타입 에러를 확인할 수 있습니다. 이는 개발자가 코드의 일부를 실행해보기 전까지는 타입 오류에 대해 알 수 없다는 의미입니다.

이 문제가 다수가 함께 개발하는 대규모 프로젝트로 가면 어떨까요?

타입에 관한 오류를 찾기 어렵기 때문에 유지보수가 어렵고 대규모 프로젝트에서 여러 명의 개발자가 함께 작업하는 경우에는 타입이 명확하게 정의되지 않은 코드를 다른 개발자가 이해하기 어려운 상황들이 발생합니다.

그렇다면 자바스크립트는 쓰면 안되고 무조건 타입스크립트를 사용하면 좋을까?

NO! 무조건 타입스크립트가 좋은건 아닙니다.

내가 진행하는 프로젝트의 방향이나 규모, 개발환경에 따라 서로의 장단점을 구분하여 사용하시는게 좋습니다.

타입스크립트 장단점

장점

1. 정적 타입 지원 타입스크립트는 정적 타입 시스템을 가지고 있어 변수, 함수, 객체 등의 타입을 명시할 수 있습니다. 이를 통해 컴파일 시 타입 체크를 수행하고 잠재적인 오류를 사전에 감지할 수 있습니다. 이는 코드의 안정성을 높이고 디버깅 시간을 줄여줍니다.

2. 개발 생산성 향상 타입스크립트는 코드의 가독성을 높여주고, 코드 완성 기능, 타입 체크, 리팩토링 지원 등의 개발 도구와 통합되어 개발 생산성을 향상시킵니다. IDE나 편집기와의 호환성이 좋아 코드 작성에 편의성을 제공합니다.

3. 에코시스템 지원 타입스크립트는 많은 프레임워크와 라이브러리에서 지원되고 있습니다. 특히 앵귤러(Angular)와의 완벽한 통합을 지원하여 대규모 프론트엔드 프로젝트 개발에 유용합니다. 또한, 자바스크립트와의 호환성이 뛰어나서 이미 존재하는 자바스크립트 코드에 대해 점진적으로 타입스크립트를 적용할 수 있습니다.

4. 유지보수 용이성 타입스크립트는 타입 시스템과 강력한 IDE 지원을 통해 코드의 가독성과 유지보수성을 높여줍니다. 정적 타입 체크로 인한 잠재적인 버그를 줄이고, 코드베이스의 구조를 명확히 할 수 있어 팀 프로젝트에서 협업에 유리합니다.

단점

1. 컴파일 시간 타입스크립트는 자바스크립트로 컴파일되어 실행되어야 합니다. 타입 체크와 같은 추가적인 작업이 필요하기 때문에 컴파일 시간이 자바스크립트에 비해 더 오래 걸릴 수 있습니다. 큰 규모의 프로젝트에서는 컴파일 시간이 증가하여 개발 속도에 영향을 줄 수 있습니다.

2. 타입 정의의 복잡성 타입스크립트의 정적 타입 시스템은 강력하지만, 코드에 타입을 명시하는 작업은 추가적인 번거로움을 유발할 수 있습니다. 특히, 복잡한 타입이나 제네릭 타입을 다루는 경우에는 타입 정의가 복잡해질 수 있습니다.

3. 프로젝트 초기 설정 타입스크립트를 사용하기 위해서는 프로젝트 초기 설정이 필요합니다. tsconfig.json 파일을 설정하고, 빌드 도구를 구성해야 하는 등의 추가 작업이 필요할 수 있습니다.

SSR(Server Side Rendering) 이란?

SSR은 서버 사이드 렌더링으로 서버에서 페이지를 생성하고 HTML, CSS 및 JavaScript를 브라우저에 전송합니다.

브라우저는 이를 받아 렌더링하고 사용자에게 보여줍니다.

• 장점
  1. 검색 엔진 최적화(SEO)가 용이
     2. 초기 페이지 로드 속도가 빠름
     3. 브라우저가 JavaScript를 지원하지 않는 경우에도 콘텐츠가 표시
     4. 서버에서 데이터를 미리 불러올 수 있어 사용자 경험을 개선할 수 있음

• 단점
  1. 서버 자원을 많이 사용
     2. SPA(Single Page Application)에서 일부 기능을 구현하기 어려움
     3. 페이지가 매번 새로고침되어 매번 서버 요청이 발생하기 때문에 서버 측의 부담이 큼

CSR(Client Side Rendering) 이란?

CSR은 클라이언트 사이드 렌더링으로 브라우저에서 JavaScript를 사용하여 애플리케이션을 실행하고 데이터를 가져와 뷰를 렌더링합니다.

• 장점
  1. 애플리케이션 로딩 후에는 빠른 전환 및 부드러운 애니메이션 등 좋은 사용자 경험을 제공
     2. 서버 측 자원을 적게 사용
     3. SPA에서 일부 기능을 쉽게 구현

• 단점
  1. 초기 페이지 로딩 속도가 느리고, 검색 엔진 최적화(SEO)에 불리
     2. JavaScript를 비활성화 한 경우에는 콘텐츠를 볼 수 없음
     3. 브라우저에서 JavaScript를 실행하므로 보안상의 위협이 될 수 있음

SSR과 CSR의 차이점 한눈에 보기

어디에 사용해야 할까?

SSR 사용 예시

• 검색 엔진 최적화(SEO)가 중요한 경우 SSR은 서버 측에서 렌더링되므로, 검색 엔진이 웹 페이지를 쉽게 수집할 수 있습니다. 따라서 SEO가 중요한 경우 SSR을 사용하는 것이 좋습니다.

• 초기 로딩 시간이 중요한 경우 SSR은 서버 측에서 렌더링되므로, 초기 로딩 시간이 빠릅니다. 따라서 초기 로딩 시간이 중요한 경우 SSR을 사용하는 것이 좋습니다.

• 네트워크가 느릴 경우 SSR은 서버 측에서 렌더링되므로, 초기 로딩 시간이 빠르고 빈번한 데이터 요청이 없습니다. 따라서 네트워크가 느린 환경에서 SSR을 사용하는 것이 좋습니다.

• 보안이 중요한 경우 CSR은 클라이언트 측에서 렌더링되므로, 보안에 취약할 수 있습니다. 반면, SSR은 서버 측에서 렌더링되므로, 보안이 중요한 경우 SSR을 사용하는 것이 좋습니다.

• 컨텐츠 변경이 적은 경우 SSR은 페이지 이동 시 새로고침 없이 컨텐츠를 보여줄 수 있지만, 서버 측에서 렌더링되므로, 컨텐츠 변경이 적은 경우 SSR을 사용하는 것이 좋습니다.

CSR 사용 예시

• 소규모 프로젝트 초기 로딩 시간이 중요하지 않고, 단일 페이지 애플리케이션(SPA)을 개발해야 하는 경우 CSR을 사용하는 것이 좋습니다.

• 네트워크가 빠른 경우 CSR은 클라이언트 측에서 렌더링되므로, 초기 로딩 시간이 길어질 수 있습니다. 따라서 네트워크가 빠른 환경에서 CSR을 사용하는 것이 좋습니다.

• 서버의 성능이 좋지 않을 경우 CSR은 클라이언트 측에서 렌더링되므로, 서버의 성능에 큰 영향을 받지 않습니다. 따라서 서버의 성능이 좋지 않은 경우 CSR을 사용하는 것이 좋습니다.

• 사용자에게 보여줘야 하는 데이터의 양이 많을 경우 CSR은 초기 로딩 시간이 길어질 수 있지만, 페이지 이동 시 새로고침 없이 데이터를 보여줄 수 있습니다. 따라서 사용자에게 보여줘야 하는 데이터의 양이 많은 경우 CSR을 사용하는 것이 좋습니다.

• 웹 어플리케이션에 사용자와 상호작용 할 것들이 많을 경우 CSR은 페이지 이동 없이 사용자와 상호작용 할 수 있습니다. 따라서 웹 어플리케이션에서 사용자와 상호작용이 많은 경우 CSR을 사용하는 것이 좋습니다.

간단 정리

SSR을 사용할 때는 초기 로딩 시간이 빠르므로, 사용자가 페이지를 빠르게 볼 수 있다는 장점이 있습니다. 하지만, 페이지 이동 시마다 서버에 데이터를 요청해야 하므로, 빈번한 데이터 요청이 있을 경우 네트워크 성능에 영향을 줄 수 있습니다. SSR을 사용할 때는 적절한 캐싱 기술을 활용하여 성능을 개선하는 것이 좋습니다.

CSR을 사용할 때는 초기 로딩 시간이 길어질 수 있으므로, 사용자가 이를 인식하지 못하도록 스플래시 스크린 등의 UI 요소를 활용하여 사용자 경험을 개선하는 것이 좋습니다. 또한, SEO 등의 다른 측면에서도 CSR을 사용할 때 고려해야 할 점이 있으므로, 상황에 맞는 방식을 선택하여 사용하는 것이 중요합니다.

SPA(Single Page Application) 란?

• 단일 페이지로 구성된 웹 애플리케이션을 의미
• 현재 웹개발 트랜드
• 브라우저에 최초에 한번 페이지 전체를 로드하고, 이후부터는 특정 부분만 Ajax를 통해 데이터를 바인딩하는 방식
• 렌더링의 역할을 서버에게 넘기지 않고 브러우저에서 처리하는 방식
• 전체 페이지를 새로 로드하지 않고도 필요한 부분만 업데이트

SPA 라이프사이클

1. 초기화(Initialization) SPA가 로드되면 초기화 단계가 시작됩니다. 이 단계에서는 애플리케이션을 초기화하고, 필요한 모듈을 로드하고, 초기 데이터를 가져옵니다.

2. 라우팅(Routing) 사용자가 페이지를 요청하면 라우팅 단계가 시작됩니다. 이 단계에서는 URL의 경로를 분석하고, 애플리케이션의 상태를 변경합니다. 라우터는 URL 경로와 상태를 연결하여 화면을 변경합니다.

3. 렌더링(Rendering) 라우터가 상태를 변경하면, 렌더링 단계가 시작됩니다. 이 단계에서는 변경된 상태를 기반으로 화면을 업데이트합니다. 이 때, React와 같은 라이브러리를 사용하는 경우, 가상 DOM을 사용하여 렌더링 성능을 최적화합니다.

4. 이벤트 처리(Event Handling) 사용자의 입력에 따라 애플리케이션의 상태를 변경할 필요가 있을 때, 이벤트 처리 단계가 시작됩니다. 이 단계에서는 사용자의 입력을 처리하고, 상태를 변경합니다.

5. API 요청(API Request) SPA에서는 브라우저에서 서버로 API 요청을 보내는 경우가 많습니다. 이 단계에서는 API 요청을 보내고, 응답을 받아서 상태를 변경합니다.

6. 소멸(Destruction) SPA가 종료되면, 소멸 단계가 시작됩니다. 이 단계에서는 리소스를 정리하고, 메모리를 해제합니다.

SPA에서는 이러한 라이프사이클을 반복적으로 실행하면서, 화면을 업데이트하고 사용자와 상호작용합니다.

SPA 장단점

장점

• 빠른 속도 SPA는 초기에 페이지를 로드할 때 필요한 모든 리소스를 한 번에 다운로드하므로, 이후에는 페이지를 로드할 때마다 서버에서 새로운 HTML을 전달 받을 필요가 없습니다. 이를 통해 빠른 속도를 제공할 수 있습니다.

• 좋은 사용자 경험 SPA는 페이지 전환시 화면 깜빡임이 없어 좋은 사용자 경험을 제공할 수 있습니다. 유지보수성이 높음: SPA는 코드의 모듈화가 잘 되어 있으며, 코드의 재사용성이 높아 유지보수성이 높습니다.

단점

• 검색 엔진 최적화(SEO) 문제 SPA는 페이지를 동적으로 업데이트하기 때문에, 검색 엔진이 이를 인식하지 못할 수 있습니다. 이를 해결하기 위해 SSR(Server-Side Rendering)이나 프리렌더링(pre-rendering) 기술 등을 사용할 수 있지만, 이는 추가적인 구현 비용이 발생할 수 있습니다.

• 초기 로딩 속도 SPA는 초기에 필요한 리소스를 모두 다운로드하기 때문에, 초기 로딩 속도가 느릴 수 있습니다. 이를 해결하기 위해 코드 스플리팅(code splitting)이나 레이지 로딩(lazy loading) 등의 기술을 사용할 수 있습니다.

SPA를 위한 프레임워크

일반적으로 SPA를 구현할 때 사용되는 프레임워크는 여러가지가 있습니다.

• Angular.js

  • 구글에서 개발한 SPA 프레임워크로, 양방향 데이터 바인딩, 의존성 주입, 템플릿, 라우팅 등 다양한 기능을 제공합니다.

    ex) Youtube

• React.js

  • 가장 인기 있는 SPA 프레임워크 중 하나입니다. React는 가상 DOM 기반의 컴포넌트 시스템을 사용해 UI를 빠르게 렌더링합니다. 또한, React는 리액트 라우터와 같은 다양한 라이브러리와 함께 사용할 수 있어 개발 생산성이 높아지는 장점이 있습니다.

    ex) 페이스북, 에어비앤비, 인스타그램

• Ember.js

  • SPA를 개발하기 위한 다양한 기능들을 포함한 풀 스택 프레임워크입니다. Ember.js는 기본적으로 채택한 아키텍처를 따라 개발해야 하기 때문에 학습 곡선이 다소 높을 수 있습니다.

    ex) 넷플릭스, 애플뮤직, 링크드인

• Backbone.js

  • MVC 패턴을 기반으로 한 SPA 프레임워크입니다. 다른 프레임워크에 비해 더 가벼우며, 기능이 적은 SPA에서 사용하기 좋습니다.

    ex) Airbnb, SoundCloud

• Vue.js

  • 가벼운 SPA 프레임워크로, React와 Angular의 장점을 합쳐놓은 듯한 특징을 가지고 있습니다. 또한, 가상 DOM을 사용하는 것이 아니라 실제 DOM을 사용하기 때문에 상대적으로 빠른 렌더링 속도를 보입니다.

    ex) GitLab, Alibaba

SPA와 MPA의 차이

MPA(Multi-Page Application) 란?

여러 개의 페이지로 구성된 어플리케이션을 말합니다. 
기존에 사용되던 웹사이트의 구조로, 각 페이지는 서버에서 새로운 HTML 파일을 받아와 렌더링합니다. 
이 방식은 각각의 페이지가 서로 독립적으로 작동하기 때문에, 
브라우저의 새로고침 없이 페이지 이동이 가능하고 검색 엔진 최적화(SEO)에도 유리합니다. 
하지만, 페이지 이동마다 서버에서 새로운 HTML 파일을 받아와야 하기 때문에 
초기 로딩 속도가 느리고 서버 자원을 많이 사용합니다.

동기(Synchronous)

작업을 수행하고 결과가 나올 때까지 기다리는 방식

• 장점
  • 코드의 구조가 간단하여 이해와 오류 처리가 쉽다.
  • 작업이 순서대로 실행되어 결과가 예측 가능하다.

• 단점
  • 결과를 반환할 때까지 대기하면서 호출자의 실행이 일시 중지되기 때문에 대기 시간이 길어질 수 있다.
  • 다른 작업을 수행하지 못하고 대기해야 하기 때문에 처리 속도가 느려질 수 있다.
  • 작업의 병렬 처리가 어려워, 높은 처리량을 갖지 못한다.

비동기(Asynchronous)

작업을 수행하면서 결과가 나올 때까지 기다리지 않고 다음 작업을 수행하는 방식

• 장점

  • 대기 시간이 없어져 더 빠른 처리가 가능하다.
  • 높은 처리량과 작업의 병렬 처리가 가능합니다.

• 단점

  • 코드의 구조가 복잡해져 이해와 디버깅, 오류 처리가 여렵다.
  • 작업의 순서와 시점이 예측하기 어렵기 때문에 결과의 일관성을 보장하기 위해 추가적인 조치가 필요하다.

동기와 비동기 예시

물건을 주문하는 과정을 예시로 설명해보겠습니다.

동기적으로 주문을 처리한다면, 주문이 완료될 때까지 대기해야 합니다. 즉, 주문 요청을 보낸 후에 결과가 반환될 때까지 아무 작업도 수행할 수 없습니다. 이 과정에서 다른 주문을 처리하거나 다른 작업을 수행할 수 없습니다.

비동기적으로 주문을 처리한다면, 주문 요청을 보낸 후에도 다른 작업을 수행할 수 있습니다. 예를 들어, 주문 요청이 처리되는 동안 다른 주문을 처리하거나 상품을 검색하거나 다른 작업을 수행할 수 있습니다. 이러한 방식으로 작업 처리 시간을 최소화할 수 있습니다.

동기 방식은 작업이 완료될 때까지 대기하고 다른 작업을 수행할 수 없는 반면,
비동기 방식은 작업을 병렬적으로 처리할 수 있어서 더욱 효율적인 처리가 가능합니다.

동기와 비동기 예시2

다른 예시로는 웹 페이지를 로딩하는 과정입니다.

동기적으로 웹 페이지를 로딩한다면, 브라우저는 웹 서버에서 모든 리소스를 받아들이고 페이지의 렌더링을 완료할 때까지 기다립니다. 이 과정에서 브라우저는 다른 작업을 수행할 수 없습니다.

비동기적으로 웹 페이지를 로딩한다면, 브라우저는 웹 서버에서 리소스를 받아들이는 동안 다른 작업을 수행할 수 있습니다. 예를 들어, 이미지 파일을 다운로드하는 동안 다른 리소스를 요청하거나 또는 사용자 입력을 받아들이거나 다른 작업을 수행할 수 있습니다. 이러한 방식으로 로딩 속도를 개선할 수 있습니다.

이에 따라, 이번 글에서는 자바스크립트에서 프로토타입이 무엇인지에 대해 설명하고, 프로토타입 공부 시 헷갈릴 수 있는 부분에 대해 설명하고자 합니다.

참고로 2015년 6월에 발표된 ECMA6(또는 ES6) 표준에서는 Class 문법이 추가되었습니다.

ES6에서는 클래스 문법을 도입하여 객체 지향 프로그래밍에서 사용되는 클래스를 더욱 쉽고 간결하게 표현할 수 있게 되었습니다. 하지만 이는 문법이 추가되었다는 것일 뿐, 자바스크립트가 클래스 기반 언어로 변경된 것은 아니므로, 이에 대해 공부하면서 차근차근 이해해 나가는 것이 중요합니다.

들어가기에 앞서

- JavaScript에서 모든 객체는 프로토타입(Prototype)을 가지며, 이 프로토타입은 해당 객체가 상속받는 속성과 메서드를 포함합니다.

- 객체의 프로토타입은 내부적으로 proto 라는 속성에 저장되어 있습니다.

이 두 문장을 생각하며 본문으로 들어가봅시다.

프로토타입(Prototype)이란?

가장 중요한 개념은

함수를 생성하면 해당 함수의 프로토타입 객체(Prototype Object)도 함께 생성됩니다.
이 프로토타입 객체는 해당 함수로부터 생성된 모든 객체의 부모 역할을 합니다.

입니다. 위 개념만 이해하고 넘어간다면 프로토타입에 대한 기본적인 개념은 이해할수 있습니다.

• [[Prototype]]

  • 함수를 포함한 모든 객체가 가지고 있는 인터널 슬롯
  • 객체의 입장에서 자신의 부모 역할을 하는 프로토타입 객체를 가리키며 함수 객체의 경우 Function.prototype를 가리킨다

• prototype 속성
  • 함수 객체만 가지고 있는 속성
  • 함수 객체가 생성자로 사용될 때 이 함수를 통해 생성될 객체의 부모 역할을 하는 객체(프로토타입 객체)를 가리킨다.
  • 함수 객체만이 소유하는 prototype 프로퍼티는 생성자 함수가 생성할 인스턴스의 프로토타입을 가리킨다.

• constructor 속성
  • 프로토타입 객체는 constructor 속성을 갖는다.
  • constructor 속성은 객체 입장에서 자신을 생성한 객체를 가리킨다. -> 여기서 자신을 생성한 객체는 함수를 선언할 때 같이 생성된 프로토타입 객체를 가리킨다.
  • constructor 속성을 통해 해당 객체를 생성한 함수가 무엇인지 알 수 있다.

위 그림을 보며 쉽게 생각해봅시다.

함수 = 틀 함수 내 prototype 속성 = "틀 만들면서 찍어낸 원본이 뭐야?" .prototype = 틀을 만들면서 함께 만들어진 원본 constructor 속성 = "널 만들 때 사용한 틀은 뭐야?" __proto__ 속성 = "너의 원본은 뭐야?"

위 그림을 보면 Person 함수를 생성하면 함수의 객체도 함께 생성된다고 했죠?

Person 함수의 객체는 Person.prototype 입니다. 그러면 constructor는 "널 만들 때 사용한 틀은 뭐야?" 였죠?

Person.prototype.constructor === Person

는 true가 나오게 됩니다.

코드를 보며 설명해보겠습니다. 함수를 하나 생성하고 객체를 만들어줍니다.

function Person(name) {
    this.name = name;
}

let foo = new Person('Park');

여기서

Person.prototype.constructor === Person

Person 함수에 의해 생성된 객체의 생성자는? 이라고 했을 때 Person 함수가 나오게 됩니다.

foo.constructor === Person

new로 객체생성을 했을 때 생성한 객체의 생성자는? 이라고 했을 때도 Person 함수가 나옵니다.

constructor 말고 __proto__도 알아보겠습니다.

__proto__ 는 자신의 부모 역할을 하는 객체를 가리키게 되는데 "너의 원본이 어떤거야?"라고 생각하면 이해하기 쉽습니다.

foo.__proto__ === Person.prototype

Person로 new 해서 생성한 객체의 원본이 뭐야? 라고 했을 때 해당 함수를 생성하면서 함께 생성된 객체를 가리키게 됩니다.

위 그림중 설명하지 않은 두개가 있습니다.

• Object.prototype
• Function.prototype

Object.prototype

자바스크립트에서 모든 객체의 부모 객체 이며, 기본적으로 모든 객체가 상속하는 프로토타입입니다.

Object.prototype 객체에는 자바스크립트에서 사용되는 기본적인 메서드들이 정의되어 있습니다.

예를 들어, toString(), hasOwnProperty(), valueOf()와 같은 메서드들이 Object.prototype 객체에 정의되어 있습니다.

이러한 메서드들은 자바스크립트에서 모든 객체에서 사용할 수 있으며, 필요한 경우에는 상속받아 사용할 수도 있습니다.

Function.prototype

모든 함수 객체의 부모 객체 이며, 기본적으로 모든 함수 객체가 상속하는 프로토타입입니다.

Function.prototype 객체에는 함수 객체에서 사용할 수 있는 기본적인 메서드들이 정의되어 있습니다.

예를 들어, apply(), call(), bind()와 같은 메서드들이 Function.prototype 객체에 정의되어 있습니다.

이러한 메서드들은 자바스크립트에서 함수 객체에서 자주 사용되며, 필요한 경우에는 상속받아 사용할 수도 있습니다.

쉽게 얘기해서 Fuction.prototype 은 모든 함수 객체가 상속하는 프로토타입 객체이고,
Object.prototype 은 모든 객체가 상속하는 프로토타입이다.

여기서 자바스크립트의 함수는 객체의 일종이기 때문에 함수 최상위에 위치하는 객체는 
Fuction.prototype 이고 Fuction.prototype 의 상위 
즉, Fuction.prototype.__proto__ 는 모든 객체의 최상위인 
Object.prototype 이 되는 겁니다.

이렇게 최대한 쉽게 prototype에 대해 알아보았습니다. 좀더 깊게 알고 싶다면 책이나 다른분들의 블로그를 참고하시면 도움이 많이 될것 같습니다.

무엇보다 중요한건 실제로 함수를 생성해보고 콘솔창에 비교를 해보며, true/false 값을 스스로 확인하는 것이 가장 좋습니다.

라이브러리(Library)란?

라이브러리는 프로그래밍을 할 때 자주 사용되는 기능들을 미리 작성해 놓은 코드의 집합입니다.

이러한 기능들은 필요할 때 호출하여 사용할 수 있습니다.

라이브러리는 보통 프로그래머가 개발하는 애플리케이션에 추가하여 사용됩니다.

장점

1. 개발 시간 단축 라이브러리를 사용하면, 개발자가 기능을 직접 구현할 필요 없이 라이브러리가 제공하는 기능을 활용할 수 있습니다. 이로 인해 개발 시간을 단축할 수 있습니다.

2. 코드 재사용 라이브러리를 사용하면, 이미 구현된 코드를 재사용할 수 있습니다. 이는 코드의 중복을 줄이고, 개발 시간을 단축시킬 수 있는 장점이 있습니다.

3. 안정성과 신뢰성 라이브러리는 보통 많은 사용자들이 사용하고 있기 때문에, 안정성과 신뢰성이 높은 편입니다. 따라서, 라이브러리를 사용하면 개발자가 직접 구현한 코드보다 안정적이고 신뢰성이 높은 코드를 만들 수 있습니다.

단점

1. 이해도가 낮을 수 있음 라이브러리를 사용하다 보면, 라이브러리가 제공하는 코드를 완전히 이해하지 못할 수 있습니다. 따라서, 라이브러리의 동작 방식이나 내부 구현 방법을 이해하지 못하면, 문제 발생 시 대처가 어려울 수 있습니다.

2. 자유도가 낮을 수 있음 라이브러리는 라이브러리가 제공하는 기능만 사용 가능하므로, 개발자가 원하는 기능을 추가하기 어려울 수 있습니다. 또한, 라이브러리를 사용할 때 개발자가 원하는 방식으로 동작하지 않을 수 있습니다.

3. 용량이 크다 라이브러리는 보통 많은 기능을 제공하기 때문에, 큰 용량을 가지고 있을 수 있습니다. 따라서, 라이브러리를 사용할 경우 애플리케이션의 용량이 커질 수 있습니다. 또한, 라이브러리의 버전이 업데이트될 경우 애플리케이션을 업데이트해야 할 수도 있습니다.

프레임워크(Framework)란?

프레임워크(Framework)는 소프트웨어 개발을 위해 사용되는 구조적인 체계를 의미합니다.

이 체계는 소프트웨어 개발에 필요한 여러 기능들을 미리 구현해 놓은 라이브러리나 API를 제공하여 개발자가 보다 쉽고 빠르게 소프트웨어를 개발할 수 있도록 도와줍니다.

장점

1. 생산성 향상 미리 구현된 기능들을 제공하여 개발자가 보다 쉽고 빠르게 소프트웨어를 개발할 수 있도록 도와줍니다. 이는 개발 생산성을 향상시켜 줍니다.

2. 일관성 유지 구조와 규칙을 제공하여 개발자가 일관성 있는 코드를 작성할 수 있도록 도와줍니다. 이는 코드 유지보수 및 확장성 측면에서 매우 중요한 요소입니다.

3. 안정성 향상 프레임워크는 많은 개발자들이 사용하므로, 많은 테스트와 검증을 거쳐 안정성이 보장됩니다. 따라서 개발자는 안정적인 소프트웨어를 보다 쉽게 개발할 수 있습니다.

단점

1. 제약 사항 개발자가 일정한 구조와 규칙을 따라야 하기 때문에, 개발자의 자유도가 제한될 수 있습니다. 이는 개발자가 원하는 기능을 구현하기 위해 제약 사항을 따르지 않고 일부 코드를 작성해야 하는 경우가 있습니다.

2. 학습 곡선 새로운 개발자가 프레임워크를 사용하기 위해서는 해당 프레임워크의 구조와 규칙을 이해해야 합니다. 이는 학습 곡선이 상대적으로 높은 단점으로 작용할 수 있습니다.

3. 유지보수의 어려움 프레임워크를 사용하면 개발자는 대부분의 코드를 작성하지 않아도 되지만, 이는 반대로 프레임워크를 수정하는 일이 어려울 수 있습니다. 따라서 프레임워크 업데이트에 대한 유지보수 비용이 증가할 수 있습니다.

라이브러리와 프레임워크의 차이점은 무엇일까?

위에서 얘기한 딱딱한 개념 대신 예를 들어서 라이브러리와 프레임워크에 대해 설명해보겠습니다.

우리가 요리를 한다고 했을 때, 라이브러리는 칼, 국자, 집게, 냄비, 후라이팬 같은 요리 도구입니다.

요리를 할 때, 칼로 식재료를 자르고 국자로 뜨고 집게로 잡아내듯, 라이브러리는 개발자가 필요한 작업을 수행할 때 사용하는 도구입니다. 이러한 라이브러리는 자유롭게 사용할 수 있으며, 필요에 따라 적절하게 조합하여 다양한 작업을 수행할 수 있습니다.

말이 안되긴 하지만 냄비로 달걀후라이를 하거나, 국자로 고기를 자르는 것처럼 말이죠

즉, 라이브러리는 요리 도구와 마찬가지로 자유롭게 사용 가능하지만, 각각의 도구는 특정 용도를 가지고 있으며, 그에 따라 적절하게 사용해야 합니다.

프레임워크는 밀키트라고 생각해봅시다.

주어진 재료가 있고 설명서에 따라 요리하는 방법이 정해져 있습니다. 설명서와 다르게 조금씩 바꿀순 있지만 설명서대로 만들면 요리가 완성되도록 되어있습니다. 즉, 결과물이 정해져 있습니다.

이처럼 프레임워크는 개발에 필요한 핵심 구성 요소와 함께 밀키트처럼 미리 준비된 코드와 규칙을 제공합니다. 개발자는 이러한 밀키트를 활용하여 웹 애플리케이션, 앱 등을 만들어낼 수 있으며, 필요에 따라 일부 구성 요소를 수정하여 맛을 개선할 수 있습니다. 하지만, 이러한 구성 요소들은 일정한 규칙과 틀 안에서 작동해야 하기 때문에, 개발자는 이러한 규칙을 따르는 것이 중요합니다.

여기서, 제일 중요한 차이점은 "제어 흐름의 권한"이 어디에 있는가?를 알아야합니다.

라이브러리는 내가 원하는 것을 선택하여 사용하기 때문에 사용자가 코드의 흐름을 직접 제어해야합니다. 반면, 프레임워크는 코드가 프레임워크에 의해 사용됩니다. 프레임워크가 짜 놓은 틀에서 수동적으로 동작하기 때문에 제어의 흐름을 프레임워크가 가지고 있다고 할 수 있습니다.

그러면 프레임워크를 안쓰고 라이브러리만 사용하면 안되나요?

프레임워크를 사용하지 않고 라이브러리만 사용하는 것도 가능합니다.

그러나 이 경우 애플리케이션 전체를 직접 개발해야 하며, 이를 위해서는 충분한 능력과 시간이 필요합니다.

반면에, 프레임워크는 이미 구현된 틀을 제공하기 때문에 빠르게 개발이 가능하며, 수정이나 업데이트도 빠릅니다. 비유하자면, 배고플 때 밥을 먹고 싶어서 요리를 해야하는데 재료부터 구해서 요리하는 것과 비슷합니다. 가능하지만 시간과 노력이 많이 필요합니다.

마지막으로 어떤 기술이든 장단점이 존재합니다. 이러한 장단점을 파악하여 적절한 상황에서 활용하는 것은 개발자로서의 역량을 향상시키는 것입니다.

부트스트랩 설치

홈페이지를 참고하여 부트스트랩을 설치합니다. https://react-bootstrap.github.io/getting-started/introduction/

1. npm으로 설치

npm install react-bootstrap bootstrap

npm으로 설치시 import 'bootstrap/dist/css/bootstrap.css'; 를 추가해야 합니다.

2. CDN 설치

<link
  rel="stylesheet"
  href="https://cdn.jsdelivr.net/npm/bootstrap@5.2.3/dist/css/bootstrap.min.css"
  integrity="sha384-rbsA2VBKQhggwzxH7pPCaAqO46MgnOM80zW1RWuH61DGLwZJEdK2Kadq2F9CUG65"
  crossorigin="anonymous"
/>

index.html의 태그 안에 CDN을 추가해줍니다. CDN은 홈페이지에서 최신버전을 확인 후 사용하기!!

부트스트랩 사용

1. 홈페이지에서 원하는 Component import 후 사용하기

https://react-bootstrap.github.io/components/alerts/

2. class에 추가하기

Javascript 의 경우에는 class 옆에 써주면 되지만 React의 경우 className 옆에 써줘야 합니다.

  예시)
  <div className="ml-1"><div/>

위 코드의 경우 해당 div의 마진 왼쪽값을 1rem( font-size가 16px이면, 16px) 크기만큼 주겠다 라는 의미 입니다.

React에서 부트스트랩을 사용하면서 가장 많이 겪게 되는 상황

그러면 여러 개를 함께 쓰고 싶을 땐 어떻게 하나요?

className 에 한개씩 띄어서 작성해주면 됩니다.

예시)
<div className="ml-1 mr-1 d-flex"><div/>

그러면 기존에 들어가 있던 css와 부트스트랩을 사용해서 쓸 수 있나요?

네! 사용할 수 있습니다. 제가 사용했던 방법을 알려드리겠습니다.

<div className="ml-1"><div/>

import testStyle from '../css/test.mopdule.css';

<div className={testStyle.testDiv}><div/>

이런 두개의 코드가 있다고 가정한 후, 두개를 합치면

import testStyle from '../css/test.mopdule.css';

<div className={`ml-1 ${testStyle.testDiv}`}><div/> 

이런식으로 합칠 수 있습니다.

{}사이에 백틱 ``을 넣어준뒤 부트스트랩은 그냥 넣어주고

따로 import 해준 CSS는 ${} 사이에 작성한 뒤, 띄어서 넣어주면 됩니다.

class로 지정한 CSS를 여러 개 적용할 수 있습니다.

import testStyle from '../css/test.mopdule.css';

<div className={`ml-1 mr-1 ${testStyle.testDiv} ${testStyle.testDiv2}`}><div/> 

하지만 섞어쓰는 경우, 가독성이 떨어지며

팀원들과 함께 작업하는 경우 문제가 생길 수 있습니다!!

알려준대로 했는데 에러가 발생해요!

가장 큰 이유는 클래스 이름이 카멜케이스가 아니여서 발생합니다. React에서 CSS 적용시 클래스 이름이 카멜케이스 방식이 아닌 test-div, test_div 로 작성할 시 에러가 발생하게 됩니다.

이러한 부분들을 수정한다면 손쉽게 React에서도 부트스트랩을 사용하실 수 있을 겁니다!

위 게시물에 출처와 내용에 문제가 있거나 잘못된 부분이 있다면 알려주세요!

 초심자를 위한 정말 간단한 정보와 사용법을 알려드립니다!!

처음 git을 사용할 때 너무 헷갈리고 코드가 날아갈까봐 무서워서 못썼던 경험을 바탕으로 작성합니다.

이곳에서 기초를 익히고 다른 게시물들을 검색해서 보시면 다양한 git 사용법을 보실 수 있습니다.

git이 뭔가요?

여럼 명이서 하나의 프로젝트를 할 때, 소스 코드와 같은 파일의 변경 내역을 추적하고

여러 사람이 협업하여 작업할 때 버전 관리를 용이하게 해줍니다.

하나의 중앙 서버에만 의존하지 않고 로컬 저장소와 원격 저장소를 모두 사용할 수 있습니다.

꼭 알아야 할 관련 용어

• Branch : 가지, 분기점이라고 합니다. 현재 상태를 복사(중요!!)하여 새로운 분기점을 만듭니다.(나 지금 있는 코드랑 똑같은 복사본 만들래)
• Commit : 내가 작성한 코드를 로컬 컴퓨터에 저장합니다. (내가 지금 작성한 코드를 내컴퓨터[Local]에 저장할래, 변화한 부분을 내 컴퓨터 저장소에만 저장합니다!)
• Push : 로컬 컴퓨터에서 서버로 변경사항을 올립니다. (내 컴퓨터[Local]에 저장된 코드를 인터넷 저장소에 저장할래)
• Merge : 현재 Branch를 원하는 branch와 병합하는 과정 (선택한 브런치를 지금 선택되어 있는 브런치로 가져와서 합칠래)
• Pull : 원격저장소에 있는 프로젝트의 변경사항을 그대로 로컬저장소에 가져와 자동으로 병합 (fetch + merge를 모두 할래)
• Fetch : 원격 저장소에 있는 프로젝트의 변경사항을 가져온다. (다른 사람들이 올린 수정사항 등을 확인하고 가져오기만 할래, 코드 병합 X)
• Check Out : 작업하기 원하는 브랜치로 이동 (나 이 브랜치 사용할래)

• Update Project(인텔리제이에만 있는 기능) : 현재 작업 중인 프로젝트의 Git 저장소에서 최신 변경 사항을 가져와 프로젝트를 업데이트하는 작업입니다. (pull과 비슷한 기능입니다.)

→ pull 과 update는 무슨 차이가 있나요? pull은 git 저장소에 최신 변경 사항을 가져오지만 update는 인텔리제이에 모든 변경사항을 가져옵니다.

그림으로 보는 깃

구글에서 git을 검색하시면 많이 보이는 workspace, index, local, remote

처음에는 이게 뭐야? 하실겁니다.

처음 git을 사용한다면 아래처럼 생각하는게 좋습니다.

저장소 이름	쉽게 보기
workspace	현재 작업중인 저장소
index	임시 저장소
local	내 컴퓨터 저장소
remote	원격 저장소

꼭! 체크하자!

git을 사용하면서 꼭 하셔야 하는 것이 있습니다.

그건 바로 확인 작업과 실행 시켜보는 것입니다.

내가 작성한 코드가 잘 올라갔는지 
원래 있던 코드들과 에러는 없는지 꼭! 확인하고 올리셔야하며
특히 메인이나 기타 브런치에서 다른 브런치를 병합(Merge) 하는 경우 
병합 후 에러는 없는지 내가 작성한 부분은 잘 돌아가는지 
꼭! 확인 후 Push 하셔야 합니다.

자주 발생하는 상황들

FaQ

Q. 내 브런치에는 있는데 git 사이트를 들어가니까 내가 작성한 코드가 반영이 되지 않았어요.

A. 보통은 push를 하지 않았거나 반영이 되지 않아서 그럽니다. push를 다시 해보고 확인해주세요.

Q. 내 브런치에서 commit과 push는 어느때마다 해줘야 하는 건가요?

A. 처음에는 변경되는 페이지나 코드를 기준으로 자주 commit 해주는 것이 좋습니다. 그래야만 나중에 문제가 생겨도 돌아가기 수월합니다.

Q. 브런치는 개인당 한개만 만들어야 하나요?

A. 아닙니다. 여러 개 만들어서 사용해도 상관없습니다.

하지만 처음 써보신다면 어느 브런치에 어느 작업을 한지 잘 표시해두고 관리하셔야 합니다.

저 같은 경우에는 백업용으로 한개씩 만들어 두고 나중에 삭제하기도 했습니다.

(브런치를 ‘현재 로컬 저장소의 코드 복사본을 만든다’ 라고 생각하시면 이해가 쉬울겁니다.)

나중에가면 Develop Branch, Feature branch 등 기능별로 나눠서 브런치를 만드는데 이건 기본을 익힌다음 찾아보시면 좋아요!!!

Q. 나는 기본을 익혀서 할줄 아는데 같이 하는 팀원들이 git 사용을 힘들어 합니다. 좀더 쉽게 합치는법이 있나요?

A. 있습니다. 한사람이 모든 사람들 브런치를 모아서 main에 올리는 방법도 있습니다.

기준이 되는 사람이 자신의 브런치를 선택한다음 한사람씩 자신의 브런치로 병합(merge)하면 됩니다.

예시)

기준 브런치 ← 팀원1 브런치(merge)

확인

기준 브런치 ← 팀원2 브런치(merge)

확인

….

최종 확인 후 기준 브런치 → main(psuh)

main 확인 후 팀원1, 팀원2 … main을 받아서 최신화

Q. 브런치를 새로 만들었는데 다른 팀원 컴퓨터에서는 브런치가 안보여요.

A. 먼저 내가 가진 브런치를 push 했나 확인해봐야 합니다. 그래도 보이지 않는다면 팀원 컴퓨터에서 fetch를 하여 변경점을 모두 내려 받으면 보일 겁니다.

해당 게시물에 틀린 부분이나 아쉬운 부분을 알려주신다면 바로 수정 하도록 하겠습니다!