동시성(Concurrency)과 병렬성(Parallelism)은 두 가지 다른 개념으로, 프로그래밍 및 컴퓨터 시스템에서 중요한 역할을 합니다. 이 두 용어의 차이를 쉽게 설명하겠습니다:

1. 동시성(Concurrency):
   - 동시성은 여러 작업 또는 일련의 작업이 동시에 실행되는 것처럼 보이는 것을 의미합니다.
   - 하나의 작업이 진행 중에 다른 작업이 일어날 수 있고, 작업들 간에 전환을 할 수 있습니다.
   - 실제로는 하나의 CPU 코어에서 번갈아가며 여러 작업을 조금씩 처리합니다.
   - 동시성은 주로 I/O 작업(예: 파일 읽기, 네트워크 요청)과 같이 대기 시간이 발생하는 작업을 효율적으로 처리하는 데 사용됩니다.

2. 병렬성(Parallelism):
   - 병렬성은 여러 작업이 동시에 실제로 독립적인 CPU 코어에서 실행되는 것을 의미합니다.
   - 병렬적으로 실행되는 작업들은 동시에 진행되며, 독립적으로 실행되기 때문에 서로 영향을 주지 않습니다.
   - 병렬성은 다중 코어 CPU 시스템에서 주로 발휘되며, 계산 집약적인 작업(예: 병렬 계산, 렌더링)을 효율적으로 처리하는 데 사용됩니다.

간단히 말하면, 동시성은 여러 작업을 번갈아가며 처리하면서 전환할 수 있는 것을 의미하며, 병렬성은 독립적으로 실행되는 작업을 동시에 처리하는 것을 의미합니다. 이 두 가지 개념은 작업 처리 방식과 하드웨어 환경에 따라 다르게 적용되며, 특정 문제를 효율적으로 해결하기 위해 선택됩니다.

리액트에서 "mount"와 "commit"은 서로 다른 단계를 나타냅니다. 이 두 개념은 React 컴포넌트의 라이프사이클과 렌더링 프로세스에서 발생하는 다른 시점을 나타냅니다.

1. Mount(마운트):
   - "마운트"는 React 컴포넌트가 처음으로 생성되고 DOM에 삽입되는 시점을 가리킵니다.
   - 컴포넌트의 생명주기(Lifecycle) 메서드 중 `componentDidMount`가 이 시점에 호출됩니다.
   - 주로 초기화 작업 및 외부 데이터 로딩과 같은 작업을 수행합니다.
   - 사용자에게 보여지기 직전에 발생하므로, 컴포넌트가 실제로 화면에 표시되기 전에 실행됩니다.

2. Commit(커밋):
   - "커밋"은 Virtual DOM의 재조정 결과를 실제 DOM에 적용하고 라이프사이클 메서드를 실행하는 단계를 가리킵니다.
   - 재조정된 Virtual DOM의 변경 사항을 실제 DOM에 반영하고, 이후 라이프사이클 메서드 중 `componentDidUpdate`가 호출됩니다.
   - 주로 업데이트와 관련된 작업을 수행하며, 컴포넌트가 화면에 이미 표시되어 있을 때 호출됩니다.
   - 컴포넌트의 상태나 속성이 변경될 때마다 발생합니다.

요약하면, "마운트"와 "커밋"은 React 컴포넌트 라이프사이클에서 서로 다른 시점에 발생하는 단계입니다. "마운트"는 컴포넌트가 처음으로 생성되고 화면에 표시되는 시점에 관련되며, "커밋"은 컴포넌트가 이미 화면에 표시되어 있는 상태에서 상태나 속성이 변경되어 재조정 및 업데이트가 필요한 시점에 관련됩니다.

"workInProgress"가 "current"를 복제할 때, 실제로는 얕은 복사(Shallow Copy)를 사용합니다. 얕은 복사는 객체의 내부 구조를 완전히 복사하지 않고 참조만을 복제하는 방식입니다. 이것은 메모리 효율적이며 빠르게 복사할 수 있습니다.

실제로 "workInProgress"와 "current"는 가상 DOM의 구조를 공유하면서, 변경 사항만을 반영합니다. 이렇게 하면 메모리 사용량을 줄이고 렌더링 프로세스를 빠르게 처리할 수 있습니다.

얕은 복사를 사용하므로, "workInProgress"의 변경 사항이 "current"에 영향을 주게 되면서 두 구조가 서로 "alternate"로 교체되는 방식으로 작동합니다. 이러한 동작은 리액트의 효율적인 업데이트와 렌더링을 가능하게 합니다.

const App = ({ content }) => <div>{content}</div>;
ReactDOM.render(<App key="1" content="Deep dive react" />, container);

const element = {
  // React element를 고유하게 식별할 수 있도록 해주는 태그
  $$typeof: REACT_ELEMENT_TYPE,

  // 리액트에서 자체적으로 제공하는 속성
  type: type, // function App()
  key: key, // 1
  props: props, // { content: 'deep dive react' }
  ref: ref, // undefined
};

// react-reconciler > ReactFiber.js

function FiberNode(tag, pendingProps, key) {
  // Instance
  this.tag = tag; // fiber의 종류를 나타냄
  this.key = key;
  this.type = null; // 추후에 React element의 type을 저장
  this.stateNode = null; // 호스트 컴포넌트에 대응되는 HTML element를 저장

  // Fiber
  this.return = null; // 부모 fiber
  this.child = null; // 자식 fiber
  this.sibling = null; // 형제 fiber
  this.index = 0; // 형제들 사이에서의 자신의 위치

  this.pendingProps = pendingProps; // workInProgress는 아직 작업이 끝난 상태가 아니므로 props를 pending으로 관리
  this.memoizedProps = null; // Render phase가 끝나면 pendingProps는 memoizedProps로 관리
  this.updateQueue = null; // 컴포넌트 종류에 따라 element의 변경점 또는 라이프사이클을 저장
  this.memoizedState = null; // 함수형 컴포넌트는 훅을 통해 상태를 관리하므로 hook 리스트가 저장된다.

  // Effects
  this.effectTag = NoEffect; // fiber가 가지고 있는 side effect를 기록
  this.nextEffect = null; // side effect list
  this.firstEffect = null; // side effect list
  this.lastEffect = null; // side effect list

  this.expirationTime = NoWork; // 컴포넌트 업데이트 발생 시간을 기록
  this.childExpirationTime = NoWork; // 서브 트리에서 업데이트가 발생할 경우 기록

  this.alternate = null; // 반대편 fiber를 참조
}

// react/packages/react-reconciler/src/ReactFiber.js

// Fiber는 컴포넌트에서 수행해야 할 작업 또는 수행된 작업이다. 컴포넌트 당 하나 이상의 Fiber가 있을 수 있다.
export type Fiber = {|
  // 이 첫 번째 필드들은 개념적으로 Instance의 멤버이다. 이것은 이전에 별도의 타입으로 분리되어 다른 Fiber 필드와 교차되었지만, Flow가 교차 버그를 수정할 때까지 하나의 타입으로 병합했다.

  // Instance는 컴포넌트의 모든 버전에서 공유된다. 우리는 이것을 별도의 객체로 쉽게 분리할 수 있다. 트리의 대체 버전에 너무 많은 복사를 피하기 위해. 우리는 초기 렌더링 중에 생성되는 객체의 수를 최소화하기 위해 일단 하나의 객체에 넣었다.

  // fiber의 종류 식별자
  tag: WorkTag,

  // 이 child의 고유 식별자
  key: null | string,

  // 이 child의 reconciliation 중에 identity를 보존하는 데 사용되는 element.type의 값
  elementType: any,

  // 이 fiber와 연관된 함수/클래스
  type: any,

  // 번역: 이 fiber와 연관된 local state
  stateNode: any,

  // Conceptual aliases
  // 부모는 Instance -> return이다. 우리는 fiber와 instance를 병합했기 때문에 부모는 return fiber와 동일하다

  // 나머지 필드는 Fiber에 속한다.

  // 이것을 처리한 후에 반환할 Fiber
  // 이것은 사실상 부모이지만, 부모가 여러 개(두 개)일 수 있다
  // 그래서 이것은 우리가 현재 처리하고 있는 것의 부모에 불과하다
  // 이것은 개념적으로 스택 프레임의 반환 주소와 동일하다
  return: Fiber | null,

  // 단일 연결 리스트 트리 구조 => 위에서 설명한 구조네!!!
  child: Fiber | null,
  sibling: Fiber | null,
  index: number,

  // 여기서부턴 번역 생략... 영어로 보는 게 더 좋을 것 같다.

  // The ref last used to attach this node.
  // I'll avoid adding an owner field for prod and model that as functions.
  ref: null | (((handle: mixed) => void) & { _stringRef: ?string }) | RefObject,

  // Input is the data coming into process this fiber. Arguments. Props.
  pendingProps: any, // This type will be more specific once we overload the tag.
  memoizedProps: any, // The props used to create the output.

  // A queue of state updates and callbacks.
  updateQueue: UpdateQueue<any> | null,

  // The state used to create the output
  memoizedState: any,

  // A linked-list of contexts that this fiber depends on
  firstContextDependency: ContextDependency<mixed> | null,

  // Bitfield that describes properties about the fiber and its subtree. E.g.
  // the ConcurrentMode flag indicates whether the subtree should be async-by-
  // default. When a fiber is created, it inherits the mode of its
  // parent. Additional flags can be set at creation time, but after that the
  // value should remain unchanged throughout the fiber's lifetime, particularly
  // before its child fibers are created.
  mode: TypeOfMode,

  // Effect
  effectTag: SideEffectTag,

  // Singly linked list fast path to the next fiber with side-effects.
  nextEffect: Fiber | null,

  // The first and last fiber with side-effect within this subtree. This allows
  // us to reuse a slice of the linked list when we reuse the work done within
  // this fiber.
  firstEffect: Fiber | null,
  lastEffect: Fiber | null,

  // Represents a time in the future by which this work should be completed.
  // Does not include work found in its subtree.
  expirationTime: ExpirationTime,

  // This is used to quickly determine if a subtree has no pending changes.
  childExpirationTime: ExpirationTime,

  // This is a pooled version of a Fiber. Every fiber that gets updated will
  // eventually have a pair. There are cases when we can clean up pairs to save
  // memory if we need to.
  alternate: Fiber | null,

  // Time spent rendering this Fiber and its descendants for the current update.
  // This tells us how well the tree makes use of sCU for memoization.
  // It is reset to 0 each time we render and only updated when we don't bailout.
  // This field is only set when the enableProfilerTimer flag is enabled.
  actualDuration?: number,

  // If the Fiber is currently active in the "render" phase,
  // This marks the time at which the work began.
  // This field is only set when the enableProfilerTimer flag is enabled.
  actualStartTime?: number,

  // Duration of the most recent render time for this Fiber.
  // This value is not updated when we bailout for memoization purposes.
  // This field is only set when the enableProfilerTimer flag is enabled.
  selfBaseDuration?: number,

  // Sum of base times for all descedents of this Fiber.
  // This value bubbles up during the "complete" phase.
  // This field is only set when the enableProfilerTimer flag is enabled.
  treeBaseDuration?: number,

  // Conceptual aliases
  // workInProgress : Fiber ->  alternate The alternate used for reuse happens
  // to be the same as work in progress.
  // __DEV__ only
  _debugID?: number,
  _debugSource?: Source | null,
  _debugOwner?: Fiber | null,
  _debugIsCurrentlyTiming?: boolean,
|};

// shared > ReactSideEffectTags.js

export const NoEffect = /                / 0b0000000000000;
export const PerformedWork = /           / 0b0000000000001;
export const Placement = /               / 0b0000000000010;
export const Update = /                  / 0b0000000000100;
export const PlacementAndUpdate = /      / 0b0000000000110;
export const Deletion = /                / 0b0000000001000;
export const ContentReset = /            / 0b0000000010000;
export const Passive = /                 / 0b0001000000000;
/*...*/

export type SideEffectTag = number;

// Don't change these two values. They're used by React Dev Tools.
export const NoEffect = /*              */ 0b000000000000;
export const PerformedWork = /*         */ 0b000000000001;

// You can change the rest (and add more).
export const Placement = /*             */ 0b000000000010;
export const Update = /*                */ 0b000000000100;
export const PlacementAndUpdate = /*    */ 0b000000000110;
export const Deletion = /*              */ 0b000000001000;
export const ContentReset = /*          */ 0b000000010000;
export const Callback = /*              */ 0b000000100000;
export const DidCapture = /*            */ 0b000001000000;
export const Ref = /*                   */ 0b000010000000;
export const Snapshot = /*              */ 0b000100000000;
export const Passive = /*               */ 0b001000000000;

// Passive & Update & Callback & Ref & Snapshot
export const LifecycleEffectMask = /*   */ 0b001110100100;

// Union of all host effects
export const HostEffectMask = /*        */ 0b001111111111;

export const Incomplete = /*            */ 0b010000000000;
export const ShouldCapture = /*         */ 0b100000000000;

리액트 소스 코드에서 side effect (부수 효과) 태그를 이진수로 표현하는 이유는 성능 및 메모리 최적화와 관련이 있습니다. 이진수로 표현함으로써 비트 단위로 각 태그를 활성화 또는 비활성화할 수 있으므로, 메모리 사용을 최적화하고 연산을 빠르게 수행할 수 있습니다.

여기에 몇 가지 이유와 장점이 있습니다:

메모리 최적화: 이진수 표현을 사용하면 각 태그가 메모리에서 고정된 크기를 차지합니다. 이는 리액트가 메모리를 효율적으로 관리할 수 있도록 도와줍니다.

비트 연산의 효율성: 이진수로 표현된 값을 비트 단위로 검사하고 조작할 수 있습니다. 예를 들어, 여러 태그를 병합하거나 필터링하는 등의 작업을 빠르게 수행할 수 있습니다.

디버깅 및 툴 지원: 개발자 도구와 같은 도구들이 이진수로 표현된 값을 해석하고 시각적으로 표현할 수 있습니다. 예를 들어, 이진수 플래그를 디버깅 시에 쉽게 추적하고 이해할 수 있습니다.

확장성: 새로운 태그가 추가될 때 이진수로 표현된 값을 확장하기가 비교적 쉽습니다. 비트 단위로 조작하므로 새로운 태그를 추가하는 데 비교적 적은 노력이 필요합니다.

이진수 표현은 리액트 내부에서 side effect를 효과적으로 관리하고 최적화하는 데 도움을 주는 중요한 기술적 결정 중 하나입니다.

// 자식의 side effect를 부모로 올린다.
// returnFiber: 부모 fiber, workInProgress: 자식 fiber
if (returnFiber.firstEffect === null) {
  returnFiber.firstEffect = workInProgress.firstEffect;
}
if (workInProgress.lastEffect !== null) {
  if (returnFiber.lastEffect !== null) {
    returnFiber.lastEffect.nextEffect = workInProgress.firstEffect;
  }
  returnFiber.lastEffect = workInProgress.lastEffect;
}

// 자신에게도 side effect가 있다면 자기 자신도 effect list에 추가해준다.
if (effectTag > PerformedWork) {
  if (returnFiber.lastEffect !== null) {
    returnFiber.lastEffect.nextEffect = workInProgress;
  } else {
    returnFiber.firstEffect = workInProgress;
  }
  returnFiber.lastEffect = workInProgress;
}

let NoContext = 0b00;
let RenderContext = 0b01;
let CommitContext = 0b10;
let executionContext = NoContext; // 0

// Render phase에서 접어들어 현재 context를 render context로 설정
executionContext |= RenderContext; // 00 | 01 => 01

// 현재 context에 따라 분기처리
// executionContext를 특정 context와 and 처리했을 때, NoContext가 아니라면 특정 context라는 의미!
if (executionContext & (RenderContext !== NoContext)) {
  // Render phase
} else if (executionContext & (CommitContext !== NoContext)) {
  // Commit phase
}

// Render phase가 끝나고 Commit phase에 접어들면 이전 context를 지우고 다음 context를 설정
executionContext &= ~RenderContext; // 01 & ~01 => 00
executionContext |= CommitContext; // 00 | 10 => 10

// 리액트에서의 실제 사용 사례
if ((executionContext & (RenderContext | CommitContext)) !== NoContext) {
  //현재 context가 Render phase이거나 Commit phase이면
  return msToExpirationTime(now());
}