관성적으로 api 연동할 때마다 사용했던 Promise 개념을 처음부터 끝까지 한 번에 정리해보고자 합니다.

Promise란?

• 비동기 연산의 상태(state)와 결과(result)를 나타내는 객체
• new 생성자를 통해 생성되며 생성과 동시에 실행

    //  new로 생성가능 -> 객체를 반환
    const promiseCallback = new Promise(()=>{
    // 인자로 콜백함수를 넣기 가능 -> 해당 콜백 함수 안에서 비동기 함수를 처리

    });  

Promise상태

• Pending: 비동기 처리가 진행중이면 대기 상태

• Fulfilled : 작업 성공시, 이행 상태

• Rejected : 작업 실패시, 거부 상태

  

→ 상태는 단 한 번만 바뀝니다.

WHY? 비동기 결과를 안정적으로 다루기 위해서입니다.

Promise는 지금은 없지만, 나중에 반드시 생기는 하나의 결과입니다. 결과는 성공 아니면 실패겠죠.

근데 만약에 결과가 여러번 바뀌면 어떻게 될까요? 지옥이 펼쳐집니다. 값을 예측하기 힘들겠죠. 그럼 디버깅 하기 힘들고 그럼 개발자는 눈물이 납니다.
SO, 첫 resolve, reject만 유효하고 이후 호출은 전부 무시합니다.

실제 코드로 실험해보면 다음과 같습니다.

const p = new Promise((resolve, reject) => {
  resolve('성공1');
  resolve('성공2');
  reject('실패');
});

p.then(console.log).catch(console.error);
//  "성공1"

Promise 상태 확정 함수

• resolve : fulfilled 상태로 확정시키는 함수
• reject : rejected 상태로 확정시키는 함수

Promise then / catch / finally 메소드

• then(): 이행되었을 때
• catch(): 거부되었을 때
• finally() : 이행되거나 거부되더라도 항상 실행

→ 프로미스는 생성과 동시에 비동기 작업을 처리합니다. ⇒ then, catch일 때 비동기 작업을 처리하는 것이 아닙니다.

const myPromise = new Promise((resolve, reject)=>{
  setTimeout(()=>{
    const text = prompt('hello를 입력해봐~')
    if(text === 'hello'){
      resolve('success')
    } else {
      reject('hello 입력 안함 ㅠ')
    }
  }, 2000)
}); 

myPromise
  .then((result)=> {
    console.log('result:', result)
  })
  .catch((error)=>{
    console.log('error:', error)
  })
  .finally(()=>{
    console.log('final')
  })

// hello를 입력하면 콘솔창에 
// result: success 

// hello를 입력하지 않으면 콘솔창에 
// error: hello 입력 안함 ㅠ

Promise 체이닝 규칙

• 체이닝이란? then이 Promise를 반환하기 때문에, 다음 then을 계속 연결할 수 있는 구조

  • promise.then(…) → 항상 새로운 Promise를 반환합니다.

      promise
        .then(...)
        .then(...)
        .then(...)

    SO, 위와 같은 코드를 쓸 수 있게됩니다.

    ⇒ 같은 Promise를 이어 쓰는게 아니라 새로운 then마다 새로운 Promise가 생기는 구조입니다.

    

• then 안에서 return 하면 무슨 일이 일어날까?

  • 값을 반환합니다. → 다음 then에서 반환된 값을 사용할 수 있습니다 WHY? promise 객체를 새로 만드니까

    myPromise
      .then((result)=> {
          console.log('result:', result)
          return `결과는? ${result}`
      })
      .then((result)=> {
          console.log('result:', result)
      })
    
      // hello를 입력하면 콘솔창에 아래와 같이 나옴 
      // result: success
      // result: 결과는? success
      // final
    

• then은 여러개 붙여도 순서가 보장될까?

  • 예 보장됩니다. then은 이전 Promise가 fulfilled 상태가 되어야 다음 Promise가 실행됩니다. WHY? promise는 체이닝 구조로 비동기 흐름을 제어하니까요

      .catch((error)=>{
          console.log('error:', error)
      })
      .finally(()=>{ //결과에 상관없이 무조건 실행됨
          console.log('final')
      })
    

• then은 왜 항상 비동기일까?

  • Promise의 then은 “이미 끝난 Promise”라도 반드시 다음 턴에 실행됩니다.

      Promise.resolve().then(() => {
        console.log('then');
      });
    
      console.log('sync');
    
      // 결과
      // sync
      // then
    

    이는 실행 순서를 예측 가능하게 하고, 동기/비동기 혼합으로 인한 문제를 방지하기 위함이며, Microtask Queue 규칙에 따라 처리되기 때문입니다.

    **Microtask Queue란? **

    - 현재 실행 중인 코드가 끝나자마자, 가장 먼저 실행돼야 하는 작업들
    - 자바스크립트 실행 흐름은 `Call stack` → `Microtask queue`→ `Macrotask queue`입니다.

    ```js
    console.log(1); // Call stack

    Promise.resolve().then(() => {
      console.log(2); // Microtask queue
    });

    setTimeout(() => {
      console.log(3);// Macrotask queue
    });

    console.log(4); // Call stack

    //결과
    1
    4
    2
    3
    ```

   SO, **`then`은 Promise의 상태와 상관없이 항상 Microtask Queue에 등록되어 현재 실행 중인 동기 코드가 모두 끝난 뒤 실행되도록 설계**되었습니다.

Promise 등장 이전의 비동기 처리 방식

• 비동기 작업을 처리하는 함수에 성공 콜백과 실패 콜백을 각각 넘겨서 완료 상태에 따른 처리를 했습니다.

  doSomething((err, result) => {
    if (err) { /* 실패 */ }
    else { /* 성공 */ }
  });

  → BUT, 여러 비동기 작업이 순차적으로 의존해야 할 경우!

  콜백 함수안에 콜백 함수가 중첩되는 callback hell이 펼쳐집니다

  ⇒ SO, 코드 가독성 + 유지보수성 저하

  • 콜백 지옥과 체이닝 차이

      // 콜백 지옥 
      doA(() => {
        doB(() => {
          doC(() => {});
        });
      });
    
      // 체이닝
      doA()
        .then(doB)
        .then(doC);
    

    → 체이닝은 중첩이 아니라 흐름을 제어하는 것입니다.

Promise 조합 메서드

• Promise.all

  • 모두 성공해야 성공! 하나라도 실패하면 즉시 reject됩니다

    await Promise.all([
    fetchUser(),
    fetchPosts(),
    fetchComments(),
    ]);
    

  • 언제 사용?

    • 페이지 렌더링에 전부 필요할 때
    • 하나라도 없으면 화면을 못 그릴 때

    → 하나라도 실패하면 나머지 결과는 무시됩니다.

    BUT 요청 자체가 취소되지는 않습니다.

    WHY? Promise에는 취소 개념이 없습니다.

    Promise가 할 수 있는 건 상태(pending / fulfilled / rejected)를 관찰하고 결과를 전달하는 것입니다.

    즉, Promise는 실행 중인 비동기 작업을 중단하지 못합니다. fetch, setTimeout, ajax를 강제 종료할 힘이 없어요.

    HOWEVER! 취소가 필요할 경우 AbortController 같은 별도 메커니즘을 사용해야 합니다.

• Promise.allSettled

  • 성공/실패 여부 상관없이 모두 완료될 때까지 대기

    const results = await Promise.allSettled([
    uploadImage(),
    uploadVideo(),
    ]);
    
    // 결과
    [
    { status: 'fulfilled', value: ... },
    { status: 'rejected', reason: ... }
    ]
    

  • 언제 사용?

    • 로그 수집
    • 여러 요청 중 일부만 성공해도 되는 경우
    • 실패 이유까지 보고 싶을 때

• Promise.race

  • 가장 먼저 끝난 것 하나만 반환

    Promise.race([
    fetch('/api'),
    timeout(3000),
    ]);

  • 언제 사용?

    • 타임아웃 구현
    • 가장 빠른 서버 선택

  • 성공이든 실패든 먼저 끝난 것 기준

    HOW? 상태가 제일 먼저 확정된 Promise를 그대로 따라갑니다.

      const fast = new Promise(resolve =>
        setTimeout(() => resolve('fast'), 100)
      );
    
      const slow = new Promise(resolve =>
        setTimeout(() => resolve('slow'), 1000)
      );
    
      Promise.race([fast, slow])
        .then(result => console.log(result));
    
      // 결과
      // fast

    BUT 나머지 코드 실행을 멈추는게 아니라 결과만 무시할 뿐 코드 실행은 계속됩니다.

• Promise.any

  • 가장 먼저 성공한 Promise 반환

    Promise.any([
    fetchFromA(),
    fetchFromB(),
    ]);
    

  • 언제 사용?

    • CDN / 미러 서버
    • 백업 API

  • 모두 실패하면 AggregateError 발생

Promise의 then / catch 메서드와 all/ allSettled 메서드들은 뭐가 다른거임?

then / catch는 하나의 Promise 흐름을 이어가는 인스턴스 메서드입니다.

→ Promise의 결과를 받아 다음 비동기 작업으로 전달함으로써, 비동기 코드를 동기 코드처럼 읽히게 만들어 흐름을 제어합니다.

반면 Promise.all / Promise.allSettled는 여러 Promise를 하나의 Promise로 조합하는 정적 메서드입니다.

→ 각 Promise는 서로 결과를 공유하지 않고 병렬로 실행되며, 모든 작업의 완료 상태를 기준으로 하나의 결과를 반환합니다.

async - await란?

• Promise의 완료를 기다리기 위한 문법

• async 키워드로 정의한 함수 내에서 호출되는 promise 앞에 await 키워드를 쓰면 해당 promise가 완료될 때까지 코드의 실행을 일시중단할 수 있습니다.

    async function fetchData(){
        try{
            const response = await fetch('https:주소')
            const data = await response.json()
            console.log(data)
        }catch(error){
            console.log('Fetch Error:', error)
        }
  
    }

  → fetch동작이 완료될 때까지 아래 부분을 실행하지 않아요

• 비동기 코드를 마치 동기 코드처럼 쉽게 작성 가능합니다.

async - await를 사용시 주의사항

• await 에러 핸들링은 반드시 try-catch 블록에서 해야합니다.

    try {
        await asyncFn();
    } catch (e) {
        // 에러는 이 안에서만 잡힘
    }

  BUT await는 promise가 완료될 때까지 함수의 실행을 중단하기 때문에, 실행흐름을 잘 고려하여 적재적소에 써야합니다.

  ex) 여러 비동기 작업이 순차적으로 진행될 필요가 없는 경우

     async function fetchExp(){
         try{
             const result1 = await fetch('https://api/result1')
             const result2 = await fetch('https://api/result2')
             console.log(await result1.json(), await result2.json())
         }catch(error){
             console.log('Fetch Error:', error)
         }
     }

  • 실행흐름

    1. fetch('result1') 요청 보냄
    2. result1 응답이 올 때까지 대기
    3. fetch('result2') 요청 보냄
    4. result2 응답 대기
    5. 둘 다 끝나면 출력 ⇒ 즉, 두 fetch가 "직렬(순차)"로 실행됩니다.

    BUT result1의 값이 다음 fetch 동작에 사용되지 않습니다. → result1 결과가 result2 요청에 전혀 영향 없기 때문에 순차적으로 실행될 필요가 없어요 이럴 때는 async-await 보다는 promise.all을 사용하는 것이 더 바람직합니다.

    • promise.all 버전

      async function fetchExp() {
      try {
      const [result1, result2] = await Promise.all([
        fetch('https://api/result1'),
        fetch('https://api/result2')
      ])
      
      console.log(
        await result1.json(),
        await result2.json()
      )
      } catch (error) {
      console.log('Fetch Error:', error)
      }
      }

    • 실행흐름

    1. fetch1 즉시 요청

    2. fetch2 즉시 요청

    3. 둘 다 동시에 날아감

    4. 둘 다 끝날 때까지 기다림

    5. 결과 사용

       ⇒ 즉, 두 fetch가 "병렬"로 실행됩니다.

한 줄 요약 정리

• Promise

  미래에 완료될 하나의 비동기 결과를 값처럼 다루기 위한 객체

• Promise 상태

  pending → fulfilled / rejected로 한 번만 확정됨

• resolve / reject

  Promise를 fulfilled 또는 rejected 상태로 확정하는 함수

• then

  이전 Promise의 결과를 받아 다음 Promise로 이어주는 흐름 제어 메서드

• catch

  체이닝 중 발생한 에러를 처리하는 메서드

• finally

  성공/실패 여부와 관계없이 항상 실행되는 후처리 메서드

• Promise 체이닝

  then이 새로운 Promise를 반환하면서 비동기 흐름을 연결하는 구조

• then은 항상 비동기

  실행 순서의 일관성과 안정성을 보장하기 위함

• Microtask Queue

  Promise의 then / catch 콜백을 실행하기 위한 우선순위가 높은 작업 큐

• async / await

  Promise 체이닝을 동기 코드처럼 작성하게 해주는 문법

• Promise.all

  모든 Promise가 성공해야 성공하는 병렬 조합 메서드

• Promise.allSettled

  성공/실패와 무관하게 모든 Promise 결과를 수집하는 메서드

• Promise.race

  가장 먼저 상태가 확정된 Promise 하나의 결과를 따르는 메서드

• Promise.any

  가장 먼저 성공한 Promise 하나의 결과를 반환하는 메서드

마치며

"Promise를 쓴다" ≠ "Promise를 이해한다"

이제는 왜 이렇게 쓰는지 설명할 수 있으면 성공 ✨

참고자료

https://www.youtube.com/watch?v=cDu9A5dl1J8&list=PLBh_4TgylO6CI4Ezq3OLRRzg2NAn3FLPB&index=2

https://www.youtube.com/watch?v=iUGLyhbwYkU

https://www.youtube.com/watch?v=wGF7eEXtD8Y

맨날 많이 들어보고, 얼레벌레 알고 있던 개념들을 이번에 제대로 정리해보고 싶어서

글로 남겨봅니다-☆

DOM이란?

• Document Object Model의 약자
• 마크업 언어로 작성된 문서(html, ml)를 프로그래밍 언어(javascript)가 조작할 수 있도록 하는 인터페이스
• 계층적 구조를 가진 노드 트리로 구성됨

⇒ 자바스크립트가 html을 이해하고 조작할 수 있게 해주는 중간 다리

DOM은 왜 필요할까?

• 마크업 언어에는 자바스크립트가 요소(element)에 직접적으로 접근할 수 있는 방법이 없습니다.

• 동적인 웹 페이지를 구현하려면 자바스크립트와 같은 프로그래밍 언어가 문서에 접근하고, 제어할 수 있는 수단이 필요합니다.

  WHY? 특정 요소를 수정하고, 이벤트를 처리하고, 화면에 다시 그리는 작업을 거쳐야 동적인 웹 페이지를 만들수 있기 때문입니다.

  ⇒ SO 문서에 접근하고, 제어할 수 있는 수단인 DOM이 필요합니다.

DOM으로 할 수 있는 것들

• 요소(element)에 접근
• 이벤트 핸들러 추가
• 요소 추가 / 제거 / 수정
• 속성(attribute) 변경

DOM은 왜 계층적 구조일까?

• 계층적 구조에서는 노드들 간의 관계가 부모, 자식,형제 등으로 정의합니다.

  이는, 명확하게 노드들의 관계를 알 수 있게하여 이벤트 처리에 유리합니다.

  • 왜 이벤트 처리에 유리할까요?

    이벤트는 DOM의 상하 관계에 따라 전파됩니다.

    • 이벤트 버블링 : 이벤트가 발생한 요소로부터 상위 요소로 이벤트가 전파되는 과정

    • 이벤트 캡처링 : 최상위 요소에서 발생한 이벤트가 하위 요소로 전파되는 과정

      

    ⇒ SO, 이벤트 버블링 / 캡처링은 상하관계가 있기 때문에 계층적인 구조에서 효율적으로 동작합니다. 

Virtual DOM이란?

• 실제 돔과 같은 내용을 담고 있는 복사본

  → 자바스크립트 객체 형태로 메모리 안에 저장되어 있습니다.

  → 실제 돔안에 있는 모든 요소와 속성들을 가지고 있습니다.

  ⇒ 브라우저가 아닌 메모리 상에 존재합니다.

• 브라우저 DOM API로 직접 조작할 수 없습니다.

  → 대신 리액트가 내부적으로 관리합니다. 개발자는 state와 props로 간접적으로 변경을 요청합니다.

가상 돔과 실제 돔의 차이

• 실제 돔은 브라우저에 있는 문서에 직접적인 접근 OK

  → BUT, 가상돔은 접근 불가능

  ⇒ 즉, 가상돔은 화면에 보여지는 내용을 직접 수정할 수 없습니다.

| 구분 | 실제 DOM | Virtual DOM |
| --- | --- | --- |
| 위치 | 브라우저 | 메모리 |
| 접근 | 브라우저 API로 직접 접근 가능 | 직접 접근/조작 불가 |
| 변경 비용 | 매우 비쌈 | 매우 저렴 |

그럼 왜 가상 돔을 쓰는 걸까?

• 실제 돔 조작 과정은 다음과 같습니다.

  • 현재 페이지의 html를 탐색 → 변경할 엘리먼트 찾음 → 해당 엘리먼트와 자녀 엘리먼트들을 돔에서 제거 → 새롭게 수정된 엘리먼트들을 교체 → css 다시 계산 → 레이아웃 정보를 알맞게 수정 → 새롭게 계산된 내용에 따라서 브라우저에 다시 그려줌

    ⇒ 트리에 있는 정보를 업데이트 시켜주는 것은 그렇게 무거운 작업은 아닙니다.

    BUT, 브라우저의 UI를 다시 그리는 작업은 복잡하고 시간이 오래 걸립니다.

    ⇒ 근데 매번 이 작업을 반복한다..? === 비효율 그 자체입니다.

• 리액트는 가상돔을 사용해서 실제 돔 조작 과정을 훨씬 효율적이게 만듭니다.

  • 가상돔은 실제 돔과 다르게 직접적으로 화면에 보이는 ui를 조작할 수 있게 해주는 api를 제공하지 않습니다. 가상 돔은 메모리에 저장되어 있는 그냥 자바스크립트 객체에 불과합니다. ⇒ SO, 가상돔을 생성하고 접근하는 것은 아주 아주 가볍고 빠른 작업입니다.

    → WHY? 실제 브라우저 화면에 접근하는게 아니니까요.

리액트가 가상돔을 활용하는 방법

• 리액트는 항상 2개의 가상돔 객체를 가지고 있습니다.

  1. 렌더링 이전의 화면 구조를 나타내는 가상돔
  2. 렌더링 이후에 보이게 될 화면 구조를 나타내는 가상돔

• 리액트는 state가 변경될 때마다 화면이 새로 렌더링됩니다.

  → 렌더링이 발생할 상황이 생긴다? → 리액트는 바로 새로운 화면에 들어갈 내용이 담긴 가상돔을 생성합니다.

  WHEN? 실제 브라우저가 그려지기 이전에!

⇒ 렌더링 이전에 화면의 내용을 담고 있는 첫번째 가상돔과 업데이트 이후의 내용을 담고 있는 두번째 가상 돔을 비교합니다 ⇒ AND 정확히 어떤 엘리먼트들이 변했는지 찾습니다!

→ 이러한 과정을 리액트는 Diffing이라고 부릅니다. 


**Diffing** 

- **이전 Virtual DOM과 새로운 Virtual DOM을 비교!**
- 효율적인 알고리즘으로 변경된 부분만 찾습니다.

⇒ 리액트는 딱 변경된 부분만 실제 돔에 적용함!

⇒  이 과정을 Reconciliation이라고 합니다 === 재조정 

Reconciliation

- Diffing 결과를 바탕으로** 변경된 부분만 실제 DOM에 적용**
- 이 과정에서 리액트는 Batch Update를 사용합니다.

Batch Update란?

- 배치 === 집단 혹은 무리
- 배치 업데이트는 변경된 모든 요소들을 한 번에 묶어서 실제 DOM에 적용하는 방식

  → 한 꺼번에 바뀐 모든 부분들을 적용시겨주기 때문에 **DOM 조작 횟수를 최소화**합니다. 

  →  돔 조작에서 비용이 많이 드는 작업은 **화면을 그려주는 작업(Reflow / Repaint)**인데 **배치 업데이트가 이를 완전 효율적으로 만들어**줍니다. 성능 최적화에 매우 중요합니다. 


SO, 리액트의 재조정 과정이 굉장히 효율적인 이유는 바로 Batch Update 때문입니다.  

한 줄 요약 정리

• DOM

  DOM은 자바스크립트가 HTML 문서를 조작할 수 있도록 만든 객체 모델입니다.

• Virtual DOM

  Virtual DOM은 실제 DOM 구조를 복사한 자바스크립트 객체로, 변경 사항을 계산하기 위한 중간 단계입니다.

• 왜 Virtual DOM을 쓰나?

  DOM 변경 자체보다 Reflow와 Repaint 비용이 크기 때문에, React는 Virtual DOM으로 변경 사항을 최소화합니다.

• Diffing

  이전 Virtual DOM과 새로운 Virtual DOM을 비교해 변경된 부분을 찾는 과정입니다.

• Reconciliation

  Diffing 결과를 바탕으로 변경된 부분만 실제 DOM에 적용하는 과정입니다.

• Batch Update

  여러 변경 사항을 한 번에 DOM에 적용해 성능을 최적화하는 방식입니다.

마치며

가상 DOM은 DOM을 빠르게 만들기 위한 기술이 아니라 DOM 변경 비용을 줄이기 위한 것을 잊지 마십쇼. to 내 자신.

참고자료

https://www.youtube.com/watch?v=pYHgo5mEcYE&list=PLBh_4TgylO6CI4Ezq3OLRRzg2NAn3FLPB

https://www.youtube.com/watch?v=gc-kXt0tjTM

https://www.youtube.com/watch?v=0jtalJxrxhs

린트는 사실 그동안 GPT나 팀원들이 세팅해준 설정을 그대로 가져다 쓰는 경우가 많았다.

예전에 한 번 린트를 전혀 사용하지 않고 프로젝트를 진행한 적이 있었는데,

그때는 코드 포맷이 조금만 어긋나도 직접 줄 맞추고, 띄어쓰기 하나하나 신경 쓰느라 꽤 스트레스를 받았다.

그 경험 덕분에 자동 줄바꿈과 포맷팅의 소중함을 제대로 느꼈다.

그래서 이번 프로젝트에서는 필수는 아니지만, 미래의 내가 이 글을 보고 다시 프로젝트를 세팅할 수 있기를 바라며 린트 설정 과정을 정리해두려고 한다.

eslint와 lint의 차이 ?

• lint : 코드에서 문법 에러, 버그 가능성, 스타일 문제를 미리 잡아주는 검사 개념
  • 언어에 상관없이 사용할 수 있다!
• eslint는 자바스크립트, 타입스크립트 용 lint 도구 중 하나이다. 즉, eslint ⊂ linter
• eslint 특징
  • 규칙을 프로젝트에 맞게 아주 세밀하게 설정할 수 있다.
  • 자주사용하는 플러그인은 다음과 같다.
    • eslint-plugin-react
    • @typescript-eslint
    • eslint-config-airbnb

프로젝트 eslint 적용하기

1. lint-staged 설치

    npm i -D lint-staged

lint-staged는 커밋하려는 파일만 선택적으로 lint/format을 실행하는 라이브러리다.

• 설치하는 이유 : 커밋할 파일이 1000개 있어도 staged된 파일만 검사해서 속도가 빠르다!

2. .husky/pre-commit 파일 만들기

커밋 전에 변경된 파일에 대해서만 린트를 실행하도록 설정한다!

    #!/bin/sh
    npx lint-staged

3. eslint.config.mjs 만들기

    import typescriptEslint from '@typescript-eslint/eslint-plugin'
    import typescriptParser from '@typescript-eslint/parser'
    import prettier from 'eslint-config-prettier'
    import globals from 'globals'

    export default [
      {
        ignores: ['.next/', 'out/', 'build/', 'next-env.d.ts'],
      },
      {
        files: ['**/*.{js,jsx,ts,tsx}'],
        languageOptions: {
          parser: typescriptParser,
          parserOptions: {
            ecmaVersion: 'latest',
            sourceType: 'module',
          },
        },
        plugins: {
          '@typescript-eslint': typescriptEslint,
        },
        rules: {
          ...typescriptEslint.configs.recommended.rules,
          'no-unused-vars': 'off',
          '@typescript-eslint/no-unused-vars': ['error'],
          'no-console': 'error',
        },
      },

      // 브라우저
      {
        files: ['**/*.{jsx,tsx}'],
        languageOptions: {
          globals: globals.browser,
        },
      },

      // Node / 서버
      {
        files: ['**/*.{js,ts}'],
        languageOptions: {
          globals: globals.node,
        },
      },
      prettier,
    ]

한 줄씩 알아보기

• 프로젝트에서 타입스크립트를 사용할 예정이기 때문에 typescriptEslint, typescriptParser를 import해야한다.

• typescriptEslint → TypeScript 전용 ESLint 플러그인으로 TS 문법에 대한 규칙을 제공한다

• typescriptParser → Eslint가 TypeScript 코드를 파싱할 수 있게 도와주는 파서이다. 이 설정이 없으면 eslint는 ts문법을 이해하지 못한다.

• prettier → ESLint와 Prettier 충돌 방지용 설정을 도와준다! 포맷팅 관련 eslint 규칙은 전부 꺼준다.

• export default → 배열의 각 객체가 하나의 설정 블록이다.

• export default 작성순서 1. eslint 검사에서 완전히 제외할 파일/폴더는 ignores배열에 넣어준다.

  • 해당 파일들은 린트를 돌릴 필요 없는 자동 생성 파일들이다.

         {
           ignores: ['.next/', 'out/', 'build/', 'next-env.d.ts'],
         },

    • .next/ : Next.js 빌드 결과물
    • out/ : next export 결과
    • build/ : 빌드 산출물
    • next-env.d.ts : Next가 자동 생성하는 타입 파일

• 2. ESLint 검사 대상 파일 지정한다 *

  • JS / TS 관련 파일에 대해서만 린트를 실행한다.

         files: ['**/*.{js,jsx,ts,tsx}']

  3. languageOptions 을 설정한다

  • languageOptions 는 ESLint가 코드를 어떤 언어 환경으로 해석할지 여부이다.

            languageOptions: {
              parser: typescriptParser,
              parserOptions: {
                ecmaVersion: 'latest', // 최신 JS 문법 허용
                sourceType: 'module', // import / export 사용
              },
            },

  4. ESLint 규칙을 설정한다

             rules: {
               ...typescriptEslint.configs.recommended.rules, 
               'no-unused-vars': 'off', // JS 기본 no-unused-vars은 끔 
               '@typescript-eslint/no-unused-vars': 'error', // 사용하지 않는 변수 있으면 에러 처리
               'no-console': 'error', // 콘솔로그 있으면 에러
             },

  • no-unused-vars 를 끄는 이유
  • no-unused-vars 는 순수 JavaScript 기준으로 만들어져, TypeScript 환경에서는 중복 오류를 발생하는 경우가 많다.
  • no-console 에러로 처리한 이유
    • 커밋 전에 잡지 않으면 로그가 쉽게 쌓이기 때문이다
    • 사용자에게는 토스트 등 UI로 예외를 전달할 예정이다

  5. 브라우저 설정한다

       {
         files: ['**/*.{jsx,tsx}'],
         languageOptions: {
           globals: globals.browser,
         },
       },

  • 리액트 컴포넌트처럼 브라우저에서 실행되는 코드에 대한 설정이다!

  • languageOptions을 통해 window ,document ,fetch , location 등을 전역 객체로 허용한다.

    window.location.href // OK
    process.env.NODE_ENV // 에러

• 6. Node / 서버 설정한다*

        {
          files: ['**/*.{js,ts}'],
          languageOptions: {
            globals: globals.node,
          },
        },

• API routes, 서버 컴포넌트, 설정 파일처럼 Node.js 환경에서 실행되는 코드들을 대상으로 한다.
  • Node 전역 객체(process, __dirname, Buffer)를 허용한다.

** eslint.config.mjs 에서 브라우저와 서버 설정을 나눈 이유**

 - 실제 실행 환경이 다르기 때문에 섞이면 린트가 제대로 동작하지 않는다.
 - Next.js는 서버와 클라이언트 코드가 한 프로젝트 안에 공존한다.
 - 환경을 나누지 않으면 클라이언트 컴포넌트에서 잡아야 할 에러를 린트가 놓칠 수 있다.

  ```jsx
  // 클라이언트 컴포넌트인데 이렇게 쓰면 에러나는데 린트는 통과된다. 
  console.log(process.env.SECRET_KEY)

```

4. pakage.json 설정하기

• lint-staged 설치만 하면 아무 일도 안 일어난다

  ⇒ 어떤 파일에 어떤 명령을 실행할지 스스로 작성해야된다!

  그래서 package.json에 다음과 같이 설정을 추가했다.

```jsx
{
  "name": "hinkor",
  "version": "0.1.0",
  "private": true,
  "scripts": {
/// 생략
  },
  "dependencies": {
/// 생략
  },
  "devDependencies": {
/// 생략
  },
  "lint-staged": {
    "**/*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "**/*.{json,css,md}": [
      "prettier --write"
    ]
  }
}

```

• 커밋하려는 파일 중 →js, ts, tsx , jsx 가 있으면 자동으로 eslint 수정 → prettier 포맷

  • json, css, md 은 prettier만 실행된다

• 이렇게 설정한 이유

  • 자바스크립트 / 타입스크립트 파일(js, ts, tsx 등)은 단순 포맷 문제뿐 아니라 문법 에러, 잠재적인 버그, 사용하지 않는 변수 같은 것들도 함께 잡아줘야 한다.

  • 반면에 json, css, md 파일은로직을 포함하지 않는 설정 파일 또는 문서 성격의 파일이기 때문에ESLint를 적용해도 얻는 이점이 거의 없다고 판단했다.

  • 따라서, 해당 파일들은 포맷팅만 책임지는 Prettier만 실행하도록 분리했다.

    ⇒ 로직이 있는 파일은 린트까지 통과해야 커밋하고, 그 외 파일은 포맷만 맞추고 빠르게 커밋하는 것을 목표로 했다

마치며

개인 프로젝트라도 이런 기본적인 규칙을 세워두는 게 생각보다 개발할 때 피로도를 많이 줄여준다는 걸 확실히 느꼈다!

프로젝트마다 커밋 컨벤션을 정해두고도, 프로젝트가 끝나고 커밋 로그를 보면 항상 띄어쓰기나 기호 같은 작은 디테일이 무너져 있는 사람이 있다. _그게 바로 나다. _

이를 고치기 위해 팀 노션을 항상 열어두고 커밋을 작성했지만, 솔직히 너무 번거로웠다.

누가 강제로 커밋 좀 체크해 줬으면 좋겠다!

그래서 개인 프로젝트지만 일관적으로 커밋하는 습관을 갖기 위해서 깃허스키를 사용해 커밋 메세지를 컨벤션을 강제하고자 한다.

Git Husky

• Git Husky

  • Git hook을 쉽게 설정하고 실행할 수 있도록 도와주는 도구이다.

• Git hook

  • Git에서 특정 이벤트가 발생했을 때 자동으로 실행되는 스크립트이다.
  • 주로 사용되는 hook은 다음과 같다
    • pre-commit : 커밋 시작하기 바로 직전에 실행됨 → 코드 검사, 포맷팅, 테스트 실행 등에 사용
    • commit-msg: 커밋 메세지가 작성된 직후 실행됨 → 보통 커밋 메세지 검증에 사용함
    • pre-push : 푸시 직전에 실행됨

왜 나는 깃 허스키를 선택했는가?

커밋 직전, 커밋 메시지 작성 직후, 푸시 직전 등 여러 시점에서 자동으로 검증 로직을 실행할 수 있기 때문이다.

개인 프로젝트이지만 일관된 기준을 강제로 지키는 환경을 만들어보고 싶었다!

커밋 메세지 컨벤션 적용하기

1. 설치하기

    npm install --save-dev husky  

2. 허스키 초기화

    npx husky install 

3. .husky/commit-msg 파일 생성

#!/bin/sh 
. "$(dirname "$0")/_/husky.sh"

node .husky/validate-commit.mjs $1

한 줄씩 알아보기

• #!/bin/sh

  • “이 파일은 sh(shell) 로 실행해야 한다”는 뜻이다
  • Git 훅은 ‘스크립트 파일’이라 커밋 전에 자동으로 실행되기 때문에 저 선언문이 없으면 실행되지 않거나 오류가 날 수 있다

• . "$(dirname "$0")/_/husky.sh”

  • 허스키 내부 스크립트에서 불러오는 코드이다
  • Husky v9에서는 필수 설정으로 hook 실행에 필요한 환경을 세팅한다.

• node .husky/validate-commit.mjs $1

  • validate-commit.mjs를 실행해서 커밋 메시지가 규칙에 맞는지 검사한다.

  • $1 은 커밋 메시지가 저장된 파일 경로를 뜻한다.

    Git은 커밋 메시지를 작성할 때 임시로 .git/COMMIT_EDITMSG 파일에 저장한다

    따라서 깃은 커밋 메세지를 .git/COMMIT_EDITMSG 파일에 기록하고, commit-msg 훅 실행 시 해당 파일의 경로를 첫 번째 인자로 전달한다.

4. 권한 부여

// 터미널에 입력해야된다
chmod +x .husky/commit-msg

Git은 훅(hook) 파일이 “실행 가능한 파일(executable)”일 때만 자동으로 실행해준다.

만약 실행 권한이 없으면 이 파일은 그냥 텍스트 파일이라서 아무것도 실행되지 않는다.

따라서 실행 권한을 부여해야 한다.

5. ./validate-commit.mjs 파일 생성

  import fs from 'fs'

  const msgFile = process.argv[2]
  const msg = fs.readFileSync(msgFile, 'utf-8').trim()

  const commitRegex = /^(feat|fix|docs|style|refactor|test|chore)(\(#\d+\)): .+$/

  if (!commitRegex.test(msg)) {
    console.error(`
  ❌ 커밋 메시지 규칙 위반!

  형식:
    작업타입(#이슈번호): 작업 내용

  예시:
    feat(#1): 로그인 로직 추가
    fix(#2): API 오류 수정
  `)

    process.exit(1) // 실패 → 커밋 중단
  }

한 줄씩 알아보기

• import fs from 'fs'

  • fs 는 Node.js 기본 모듈 "File System"로, 파일 읽기, 쓰기, 삭제가 가능하다.

• const msgFile = procress.argv[2]

  • Git 커밋 → Husky → validate-commit.mjs 로 실행된다.

    • 실행순서

      • process.argv[0] → node 실행 경로 ⇒ (/usr/local/bin/node)

      • process.argv[1] → 실행 중인 스크립트 파일 경로 ⇒ (scripts/validate-commit.mjs)

      • process.argv[2] → git이 전달한 커밋 메세지 파일 경로 ⇒ (.git/COMMIT_EDITMSG)

        → 이미 commit-msg에서 node .husky/validate-commit.mjs $1 로 스크립트 파일 경로를 넘겼기 때문에 node.js로 넘어오면 argv[2]가 된다.

  • 왜 process는 import하지 않는가?

    • Node.js에서 기본으로 제공하는 전역 객체이기 때문에 import가 필요 없다.
    • Node에서 기본 제공하는 전역 객체들 : process , __dirname , __filename , Buffer , global

• if (!commitRegex.test(msg)) 에서 test를 import 안 했는데 어떻게 바로 사용가능하지?

  • test는 전역 변수인가? 아니다. commitRegex 가 RegExp 객체이다.

    • RegExp객체란?

      • 자바스크립트에서 정규 표현식(Regular Expression)을 다루는 객체이다. 커밋 메세지가 컨벤션에 맞는지 확인하는 것처럼 문자열에서 특정 패턴을 찾거나 검증할 때 사용한다.

      • RegExp 는 new 생성자를 사용하지 않고 /.../ ← 리터럴 방식으로 생성이 가능하다.

        따라서 commitRegex 는 리터럴 방식으로 변수값을 할당했기 때문에 RegExp 객체이다.

      • RegExp 에는 test 뿐만 아니라 다양한 메서드가 있으나 주로 test , exec() 를 사용한다.

        • test() → true/false → 간단한 패턴 검증 시 주로 사용
        • exec() → 매치된 내용 배열 반환, 매치된 내용이 없으면 null 반환 → 더 상세한 정보 필요할 때 사용

커밋 메세지 컨벤션을 “ 작업타입(#이슈번호): 작업내용”으로 설정한 이유

우선 깃허브에서 이슈번호를 커밋에 넣으면 추적이 가능하기 때문에 추후 코드 리뷰 등 유지 보수 하기에 적합할 것이라고 생각했다.
가장 큰 이유는 개인 프로젝트라도 “작업타입”을 명시하면서 내가 작업한 부분을 분류하고 일관된 커밋 습관을 형성하기 위해서이다.

실행결과

규칙을 지키지 않으면 커밋 단계에서 에러가 발생하며, 커밋은 중단된다!

마치며

직접 스크립트를 만드는 방법도 있지만 라이브러리를 사용할 수 있다!

• @commitlint/cli : 커밋 메시지 체크
• @commitlint/config-conventional : 기본 컨벤션 규칙

참고자료

https://www.notion.so/husky-233ec690dcc680c2a8b7de3ee1cb142a

프론트엔드 부트캠프가 끝나고 노션과 메모장 등 여기저기 막 휘갈겨 쓴 기록물들을 정리해보니, 나만의 개인 프로젝트가 없었다! 팀 프로젝트를 많이 한 건 아니지만 그래도 적지 않았는데, 정작 온전히 나 혼자 기획하고 개발한 프로젝트가 존재하지 않았다. 그래서 이번에 처음부터 끝까지 나 혼자 만드는 프로젝트를 해보기로 했다.

🔥 기획 배경 : 나는 단어장을 만들기로 결심했다.

✔️ 왜 단어장인가?

우선, 나는 언어를 배우는 것을 좋아한다.

언어 공부는 인생에서 절대 손해 볼 일이 없다고 생각한다.

새로운 언어는 생각의 폭과 깊이를 확장해주는 도구이다.

특히, 특수 외국어를 전공하면서 느낀 것은 언어는 단어를 모르면 아무것도 할 수 없다는거다.

단어만 충분히 알고 있다면 문법이 조금 틀려도 의사소통을 할 수 있다. _언어는 기세다. _

✔️ 왜 힌디어인가?

일단 나는 인도학과이다.

우리 학과를 졸업하려면 FLEX Hindi를 통과해야 한다.

그런데 여기서 문제는 전국에 FLEX Hindi 교재가 단 1권뿐이고, 체계적인 힌디어 단어장은 존재하지 않는다는 것이다. 앱 스토어에서도 힌디어 사전만 있고, 힌디어 단어장은 없었다.

그래서 FLEX를 준비하기 전에 ‘어떻게 공부하면 좋을까’ 지레 겁을 먹으며 막막했던 경험이 있다.

그리고 최근에 언어 교환 앱인 HelloTalk에 배우고 싶은 언어를 힌디어로 설정했더니, 한국어에 관심있는 인도인 44명에게 메시지를 받았다. 이를 통해 인도인 사용자 니즈가 존재함을 판단했다.

👊🏻 그래서 ‘Hindi’ + ‘Korea’를 합친 단어장 힌코(HinKor)를 기획하게 되었다.

🔥 목표 사용자

• FLEX Hindi를 응시하는 모든 사람들
• 한국어에 관심있는 인도인들

🔥 HinKor의 차별점

• 힌디어, 한국어 발음 제공 ✔️

  힌디어는 자음/모음/반자음/결합자음이 많아서 영어 발음 표기만으로는 읽기 어렵다.

  또한, 네이버 힌디 사전에 발음기호가 없는 경우도 있다.

  실제로 FLEX 를 공부하며 나만의 단어장을 만들 때, 네이버 힌디 사전과 구글 힌디어 번역기 동시에 띄운 뒤 발음을 들으며 한글로 적었다. FLEX 공부 초반에는 하루종일 단어장만 만들었다.

  그래서 사용자가 바로 읽고 말해보면서 외울 수 있도록 힌디어 발음을 한국어로 제공하고자 한다.

• 동의어, 반의어 필터링 ✔️

  내가 생각했을 때 FLEX Hindi에서 가장 중요한 게 동의어·반의어 암기하는 것이다.

  하지만 일반적인 단어장은 단어만 크게 보여지고, 관련 단어나 활용형 단어는 조그맣게 적혀 있어 쉽게 눈에 들어오지 않는다.

  예를 들어, 나는 manage라는 단어만 읽고 manager나 management 같은 관련 단어는 잘 외워지지 않았다.

  

이 문제를 해결하기 위해 ‘긍정적인’·‘부정적인’과 같은 **테마별로 단어를 묶어**, 사용자가 테마별로 단어를 **직관적으로 확인하며 학습**할 수 있도록 하고자 한다.

사용자가 **테마를 클릭하면 동의어를 먼저 보고, 반의어 보기 버튼을 누르면 반의어로 전환**하는 기능을 제공한다. 

• 퀴즈 모드 ✔️

  나는 단어를 단시간에 가장 효율적으로 외우는 방법은 스펠링만 보거나 한글만 보고 뜻을 맞추는 것이라고 생각한다.

  개개인마다 다르겠지만 어떤 단어는 2번만 봐도 쉽게 외워지는데 어떤 단어는 10번을 봐도 헷갈리는 단어가 있다.

  대체로 나는 2번 봤을때 5초 안에 기억 안 나거나 유추도 안되는 단어는 집중 암기가 필요한 단어였기 때문에 형광색으로 표시하면서 다음에 볼때는 형광색으로 칠한 단어만 외웠다.

   (아래 사진은 실제 내가 사용했던 나만의 힌디 단어장이다.) 

  

  퀴즈 모드는 한국어 또는 힌디어 퀴즈를 선택할 수 있고, 선택한 데이터만 퀴즈로 제공하고자 한다. 단어는 한 번에 한 개씩 보여주며, 선지는 선택 데이터와 반대로 제공 된다. 사용자는 선지 중 하나를 선택해 정답을 확인할 수 있다. 예를 들면 사용자가 한국어를 선택하면 힌디를 보여주고, 선지는 한국어로 보여준다. 이렇게 하면 단어와 뜻을 빠르게 연결할 수 있어, 많은 단어를 효율적으로 외울 수 있다.

✔️ 로그인 기능은 없는건가?

이 프로젝트를 실제 서비스로 배포하고, 사용자를 받는다고 가정했을 때, 로그인 기능이 필요할까 고민했다. 결론적으로, 지금 단계에서는 필요 없다고 판단했다. 왜냐하면 어차피 시험장 들어가기 전까지 단어장에 있는 모든 단어를 외워야 하기 때문에, 북마크나 계정기반 기능의 우선순위가 높지 않다고 생각했다. 그래서 과감하게 MVP 범위에서는 로그인 기능을 제외하기로 했다.

✔️ 주요 기능 요약

🔥 사용자 흐름

🔥 사용할 기술스택

• 백엔드: Supabase 프론트와 백엔드를 모두 혼자 구현해야 하기 때문에, 무료 플랜에서도 DB, 스토리지, 인증, 실시간 기능, Edge Function을 모두 제공하는 Supabase를 선택했다.

• 프론트: Next.js SSR과 SSG를 통해 빠른 렌더링 속도를 제공하고, SEO를 지원하며 React 생태계와 자연스럽게 연동할 수 있어 선택했다.

• 기타: 상태관리, 데이터 패칭, 스타일링 라이브러리는 개발 과정에서 필요에 따라 도입할 예정이다.

마치며

그동안 마감 기한에 쫓기며 프로젝트를 하다 보니, 방향보다는 속도가 우선시되는 경우가 많아서 늘 아쉬움이 남았다. 그래서 언젠가는 처음부터 끝까지 혼자 기획하고 개발하는 프로젝트를 꼭 해보고 싶었는데 드디어..! 이번에 시작할 수 있게 되었다.
앞으로 개발 과정을 꾸준히 기록하면서 부족했던 부분도 채워나가려고 한다. 그리고 꼭 기획한 기능들을 모두 구현해서 교수님께 보여드리고 싶다. 나자신 화이팅!

실행 컨텍스트를 이해하기 위해서 알아야할 개념이 많이 있습니다. 근데 공부해도 뒤 돌아서면 까먹는 나란 아이.. 비정상 일까요..? 이제는 더이상 물러날 곳이 없다..! 이번에는 실행 컨텍스트를 공부하며 함께 등장했던 개념들을 차근차근 정리해보려 합니다.

실행 컨텍스트란?

자바스크립트에서 코드가 실행되는 전체적인 환경입니다.

→ 환경 :코드 실행에 영향을 주는 조건, 변수, 스코프, this 등을 의미합니다.

함수가 호출될 때 실행 컨텍스트가 생성되어 콜 스택(Call Stack)에 쌓이고, 실행 흐름이 관리됩니다.

콜 스택은 하나가 존재하고, 각 함수 호출마다 새로운 실행 컨텍스트가 생성되어 기존 콜 스택에 푸시(push) 콜 스택에 쌓입니다.

콜 스택은 실행 순서를 관리하며, 컨텍스트가 끝나면 스택에서 팝(pop)됩니다.

• 전역 실행 컨텍스트

  • 자바 스크립트가 처음 실행될 때 생성되는 컨텍스트입니다.
  • 프로그램이 종료될 때까지 유지합니다.
  • 전역에 선언된 변수, 함수가 포함되었기 때문에 어디서든 접근 가능합니다.
  • 기본적으로 자바스크립트는 싱글 스레드이기 때문에 전역 실행 컨텍스트 1개만 존재합니다.

• 함수 실행 컨텍스트

  • 함수가 호출될 때마다 생성되는 컨텍스트로, 각 함수마다 자신만의 실행컨텍스트 보유합니다.
  • 함수 실행 컨텍스트 내에서 선언된 변수와 함수는 그 함수 안에서만 새롭게 생성되고 유효하며, 함수 내부에서는 자신의 컨텍스트 + 외부 스코프(상위 스코프)의 변수에도 접근할 수 있습니다.
  • 함수가 종료되면 실행 컨텍스트도 함께 사라집니다.

실행 컨텍스트 중요 구성요소

변수 환경 Variable Environment

• 실행 컨텍스트 내에서 사용되는 변수와 함수 선언을 저장하는 초기 환경입니다. ⇒ 실행 컨텍스트가 생성될 때 var, 함수 선언문은 먼저 변수 환경에 등록되기 때문에
• var와 함수 선언문은 호이스팅이 빠르게* 일어납니다.
• 변수 환경은 실행 컨텍스트 생성 시 한 번 만들어지고, 이후 실행 단계에서는 렉시컬 환경에서 실제 변수 값을 관리합니다. ⇒ 즉, 변수 환경 자체는 업데이트되지 않습니다.

렉시컬 환경 Lexical Environment

• 환경 레코드 Environment Record

  • 현재 스코프에서 선언된 변수(let, const), 함수 표현식, 매개변수 등이 실제로 저장되는 객체입니다.
    • 실행 중 값이 바뀌면 이 환경 레코드가 업데이트되어 변수의 최신 상태를 관리합니다.
    • var, 함수 선언문도 초기 선언 단계 이후에는 결국 이 환경 레코드에서 관리됩니다.

• 외부 환경 참조 Outer Environment Reference

  • 현재 렉시컬 환경이 어떤 외부 스코프와 연결되어 있는지를 나타내는 참조입니다. ⇒ 이를 통해 스코프 체인(Scope Chain)이 만들어지고, 자바스크립트가 변수를 찾을 때 “현재 → 부모 → 그 부모 …” 순서로 탐색할 수 있습니다.

• 렉시컬 환경은 코드 실행 중 계속 변하는 활성 상태의 환경입니다.

• let, const는 TDZ(Temporal Dead Zone) 상태도 이 환경 레코드에서 관리합니다. ⇒ 실행 중 변수가 업데이트되면 모두 렉시컬 환경에서 처리합니다.

디스 바인딩 (this binding)

• this는 실행 컨텍스트에 따라 참조하는 대상이 달라지는 동적 바인딩입니다. ⇒ 렉시컬 환경은 “코드가 어디에서 작성되었는지”로 결정되는 반면, this는 “함수가 어떻게 호출되었는지”에 의해 결정되기 때문입니다. 즉, 동일한 위치에 정의된 함수도 호출 방식이 달라지면 this가 달라질 수 있습니다.

• 전역 컨텍스트는 2가지 환경 기록을 가집니다.

  • Object Environment Record
    • 전역 객체(window, globalThis 등)를 기반으로 var, 함수 선언문이 여기에 바인딩 됩니다. 그래서 var a = 1를 작성하면, window.a로 접근이 가능합니다.
  • Declarative Environment Record
    • 전역 스코프에 생성되는 독립적인 환경으로 let , const 변수가 여기에 저장됩니다. 그래서 var a = 1를 작성하면, window.a로 접근이 불가능합니다.

• 함수 컨텍스트에서 this는 함수 호출 방식에 따라 달라집니다.

  1. 일반 함수 호출 func()

     • 기본적으로 this는 전역 객체입니다. 그러나 strict 모드에서는 this는 undefined가 됩니다.

  2. 객체의 메서드로 호출 obj.method()

     • this는 해당 객체(obj)가 됩니다.

  3. 생성자 함수 호출 new Person()

     • this는 새로 만들어진 객체가 됩니다.

  4. 화살표 함수 () => {}

     • 속해 있는 외부 스코프의 this를 그대로 가져오기 때문에 새로 만들지 않습니다. 예를 들어, 아래의 코드가 있으면 this는 obj가 됩니다.

     const obj = {
     name: "Alice",
     greet: function() {
       console.log(this.name);
     }
     };
     
     obj.greet(); // Alice

     • 화살표 함수는 렉시컬 스코프를 따르기 때문에 this가 상위 컨텍스트를 참조합니다.

       const obj = {
       name: 'JavaScript',
       getName: function() {
           return this.name;
       }
       };
       console.log(obj.getName()); // 'JavaScript'
       const getName = obj.getName;
       console.log(getName()); // undefined => Why? 일반 함수는 기본적으로 전역 객체를 this로 참조 

** 왜 화살표 함수의 this만 상위 스코프를 가져오는가?** 일반 함수는 호출될 때마다 this가 새로 만들지만, 화살표 함수는 this를 새로 만들지 않습니다. 왜냐하면 화살표 함수는 콜백, 이벤트, 비동기 코드에서 this가 혼동되는 문제를 해결하기 위해 만들어졌기 때문입니다.

자바스크립트 실행과정

• 전역 실행 컨텍스트를 생성하여 콜스택에 푸쉬합니다.
• 전체 코드 스캔 후, 선언할 변수, 함수등이 있는지 확인합니다.
• 선언문만 실행해서 환경 레코드에 기록하며 호이스팅이 이뤄집니다.

  _호이스팅이란 변수와 함수 선언이 코드의 최상단으로 끌어올려지는 현상_입니다. 자바스크립트 엔진은 실행 컨텍스트를 생성할 때 소스 코드를 먼저 스캔하여 변수 및 함수 선언을 수집하고, 환경 레코드(Environment Record)에 등록하기 때문에 발생합니다.

• 환경 레코드에 새로운 식별자를 기록합니다.
  • var → undefined로 초기화 후 변수 환경에 등록됩니다.
  • let, const → 렉시컬 환경에 선언만 등록되고 초기화 전까지 TDZ상태가 됩니다.
  • 함수 선언문 → 함수 객체 자체로 즉시 초기화되어 등록됩니다.

• 선언문 외 나머지 코드를 순차적으로 실행합니다.

• 변수 참조 시, 렉시컬 환경에서 탐색합니다. ⇒ 현재 환경에 없으면, 외부환경참조(Outer)를 따라 상위 스코프로 이동합니다.

  • 이 과정에서 아래의 동작들이 발생합니다.

    • *식별자 결정 *

      • 코드에서 사용된 변수나 함수 이름(식별자)이 어떤 값을 참조할지 결정하는 과정입니다. ⇒”이 this는 어떤 스코프의 this인가?"를 찾는 단계입니다.
      • 스코프 체인(Scope Chain)
        • 식별자를 결정할 때, 현재 렉시컬 환경에서 시작해 외부 환경으로 이어지는 연결 구조입니다.
        • “현재 → 부모 → 조상 환경” 순으로 탐색합니다.

    • 변수 쉐도잉(Vairable Shadowing)

      • 하위 스코프에서 상위 스코프와 같은 이름의 변수를 선언해, 상위 변수의 접근이 가려지는 현상입니다.

호이스팅과 실행 컨텍스트 과정

변수 호이스팅

• var 선언

console.log(hoisting); // undefined
var hoisting = '호이스팅';
console.log(hoisting); // 호이스팅

• 변수 hoisting는 선언 전에 끌어올려져 첫 번째 console.log에서 접근 가능합니다

  • 선언과 초기화가 동시에!
    • 선언 : 메모리 공간을 확보하고 식별자와 연결
      • 초기화 : 식별자를 암묵적으로 undefined 값 바인딩
      • let, const

        console.log(hoisting); // Reference Error
        const hoisting = '호이스팅';

  

  • 자바스크립트 엔진이 변수를 선언하지만 값을 초기화하지는 않습니다. let, const로 선언된 변수는 Temporal Dead Zone(TDZ)에 들어가며, 초기화 전에는 접근이 불가능합니다.
    • 일시적 사각지대 Temporal Dead Zone : let, const로 선언했을 때, 선언 이전에 식별자를 참조할 수 없는 구역

함수 호이스팅

• 함수 선언

    /* Global */
    study()  // TypeError: 존재하지만 함수가 아닐 때
  
    var study = () =>{
        // do study
    };

  • var로 선언했기 때문에 study는 undefined입니다.
  • 함수와 달리 호출될 수 없기 때문에 타입 에러 발생합니다.

    /* Global */
    study() // Reference Error :변수가 존재하지 않을 때
  
    const study = () =>{
        // do study
    };

  • const로 선언시, 환경레코드에 기록된 값이 없어 Reference Error 발생

• 함수 표현 ⇒ 함수 표현식 : 변수에 함수를 담아서 함수를 선언하는 방식

  → 함수를 변수에 담고 있기 때문에 변수 호이스팅과 똑같이 동작합니다.

       /* Global */
       study() // 실행함 
  
       function study(){
           // do study
       };

  • 자바스크립트 엔진이 study 함수를 선언과 동시에 완성된 함수 객체를 생성해 환경레코드에 기록합니다. ⇒ 함수 선언과 동시에 함수가 생성되기 때문에 선언 전에도 함수를 사용할 수 있습니다.

그럼 비동기 함수는 어떻게 실행되는가?

동기 함수는 실행되면 → 실행 컨텍스트 생성 → 콜 스택 쌓임 → 코드 실행 → 컨텍스트 제거 됩니다. 비동기 함수는 어떻게 실행컨텍스트가 실행되는걸까요?

• 비동기 함수 실행과정

1. 콜백 큐에 등록됩니다. 콜백 큐는 비동기 함수의 콜백들이 대기하는 공간으로 타이머, 이벤트 등 실행 준비가 된 함수들이 이곳에 들어갑니다.

2. 이벤트 루프(Event Loop)를 통해 콜백 함수가 실행 컨텍스트 콜 스택에 올라가고 실행 컨텍스트가 생성됩니다. 이벤트 루프는 콜 스택이 비었는지 계속 확인하며 콜 스택이 비어 있으면 콜백 큐에서 함수를 하나씩 꺼내 콜 스택에 올립니다.

3. 실행 컨텍스트가 생성되어 함수가 실행됩니다. 비동기 이벤트 발생 → 콜백 큐 등록 → 콜 스택 비면 이벤트 루프가 콜백 스택에 올림 → 실행 컨텍스트 생성

• 예시

  setTimeout(() => {
    console.log('Hello, World!');
  }, 1000);
  console.log('Synchronous Code');

1. setTimeout 호출 → 브라우저/Node.js가 타이머를 등록

2. 콜백 함수(() => console.log('Hello, World!'))는 즉시 실행되지 않고

콜백 큐(Callback Queue)에 등록

3. 현재 실행 컨텍스트(전역 컨텍스트)는 동기 코드 실행 후 종료 → 콜스택 비워짐

4. 이벤트 루프(Event Loop)가 콜백 큐를 확인 → 콜백을 콜스택으로 올려서 실행 컨텍스트 생성 → 실행

실행 컨텍스트와 클로저의 관계

클로저란?

• 함수가 자신이 선언될 때의 렉시컬 환경을 기억하는 것으로,** 함수가 실행된 이후에도 외부 변수에 접근 가능** 합니다.

• 자바스크립트에서는 함수가 생성될때마다 클로저가 생성됩니다. 각각의 함수가 자신만의 클로저를 갖습니다.

• 실행 컨텍스트가 종료된 이후에도 변수에 접근 가능합니다.

• 예시코드

  function outer() {
      let count = 0;
      return function inner() {
          count++;
          return count;
      };
  }
  const counter = outer();
  console.log(counter()); // 1
  console.log(counter()); // 2

  • 클로저 덕분에 inner 함수는 outer 함수의 실행 컨텍스트가 종료된 이후에도 count 변수에 접근 가능합니다.
  • 클로저는 자바스크립트에서 상태를 유지하거나 캡슐화 구현하는데 자주 사용합니다.

📢 실행 컨텍스트에 대해서 설명해주세요!

실행 컨텍스트는 자바스크립트가 코드를 실행할 때 변수, 함수 선언, this, 스코프 등의 정보를 관리하는 환경 객체입니다. 전역 코드가 실행될 때 전역 실행 컨텍스트가 생성되고, 함수가 호출될 때마다 새로운 함수 실행 컨텍스트가 만들어집니다. 이 컨텍스트들은 콜 스택을 통해 순서대로 실행되며, 실행 흐름을 관리합니다. 실행 컨텍스트는 변수 환경, 렉시컬 환경, 그리고 this 바인딩으로 구성되어 있어, 변수 호이스팅, 스코프 체인, TDZ와 같은 규칙을 관리하고, this는 호출 방식에 따라 달라집니다. 자바스크립트 엔진은 이러한 정보를 활용해 변수를 어디서 찾고 어떤 순서로 코드를 실행할지 결정합니다.

마치며

최대한 시각화하려고 했는데요 ㅠㅠ 이 친구들,,, 생각보다 호락호락하지 않군여.. 이벤트 루프와 비동기를 좀 더 보충해서 공부해야될 것 같습니다. 그래도 실행컨텍스트의 개념을 한 번 정리해두니 이제 흐름이 보이는 것 같습니다! 이번엔 머릿속에 조금 더 오래 남을 것 같아요..ㅎ

참고자료

https://www.youtube.com/watch?v=EWfujNzSUmw

https://f-lab.kr/insight/understanding-javascript-execution-context-and-closure-20250124?gad_source=1&gad_campaignid=22368870602&gbraid=0AAAAACGgUFe0AKwxSBXcjjQBLo3zoDW6t&gclid=CjwKCAiA_dDIBhB6EiwAvzc1cObvuium3wyMKurFquBwwTxHlfyGKUXZBTg6-Kt-Pi67jCOpcX8ZURoC1vkQAvD_BwE

https://developer.mozilla.org/ko/docs/Web/JavaScript/Guide/Closures

저에게 “브라우저”란 익숙하지만 막상 설명하라고 하면 정의하기 어려운 단어인데요.. 저는 그저 ‘browse= 훑어보다’라는 뜻처럼, 우리가 보는 인터넷에서 어떤 정보를 훑어보는 것으로만 대충 알았습니다. 그리고 저의 렌더링지식은 아주 얕고 좁은데 공부하면 할수록, 그 얕고 좁은 지식이 큰 부메랑이 되어 제 뒷통수를 후려쳤습니다..핳 (이제는 더 이상 물러날 곳이 없다!) 이번 기회에 렌더링 과정을 직접 시각화로 정리하면서, 그동안 제가 작성했던 코드들이 실제로 어떻게 흘러갔는지 이해해보려 합니다.

브라우저란?

웹 브라우저(Web Browser)은 웹에서 페이지를 검색하고 표시하며, 사용자가 하이퍼링크를 통해 다른 페이지로 이동할 수 있게 도와주는 프로그램입니다.

• 하이퍼링크(hyperlink) : 보통 ‘링크’라고 부르며, 특정 URL에 연결된 텍스트나 이미지를 클릭하면 해당 주소로 이동할 수 있게 해줍니다.

현재 데스크톱에서 사용되는 주요 브라우저는 Chrome, Internet Explorer, Firefox, Safari, Opera 가 있습니다. (※ Internet Explorer는 2022년부로 공식 지원이 종료되었습니다.)

브라우저의 기본 기능은 서버에 웹 리소스를 요청하고, 응답을 받아 이를 화면에 표시하는 것입니다.

리소스는 HTML 문서뿐 아니라 PDF, 이미지, 동영상 등 다양한 형태일 수 있습니다.

브라우저 구조

1. 사용자 인터페이스

• 주소 표시줄, 뒤로/앞으로 가기 버튼, 북마크 메뉴 등 웹페이지 내용 외부의 조작 영역입니다.

  2. 브라우저 엔진

  • 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어합니다. → 사용자의 입력을 렌더링 엔진에 전달하고, 렌더링 엔진이 HTML과 CSS를 파싱하며 DOM을 생성하는 동안 상태를 추적하여 ‘로딩 중’, ‘새로고침’ 등의 UI 상태를 업데이트합니다. → 또한 CORS, 쿠키, 세션 등 보안 관련 정책을 관리하고, 렌더링 엔진이 이를 위반하지 않도록 제어합니다. → 사용자가 ‘뒤로 가기’ 버튼을 누르면, 브라우저 엔진은 렌더링 엔진에게 캐시를 이용해 이전 페이지로 돌아가도록 지시합니다. ⇒ 즉, 브라우저 엔진은 사용자의 행동과 렌더링 결과 사이를 연결하는 역할을 합니다.

3. 렌더링 엔진

• 요청한 컨텐츠 표시합니다. → HTML을 요청하면 HTML 과 CSS를 파싱하여 화면에 표시합니다. → 이때 렌더링 엔진이 수행하는 일련의 과정을 렌더링 파이프라인(Rendering Pipeline) 이라고 합니다. → 렌더링 파이프라인은 DOM 트리 생성부터 CSSOM, 렌더 트리, 레이아웃, 페인팅, 컴포지팅 단계로 이어집니다.

4. 통신

• HTTP 요청과 같은 네트워크 작업을 수행하는 모듈입니다.
• 플랫폼 독립적인 인터페이스로, 실제 네트워크 처리는 OS 수준에서 실행됩니다.

  → 개발자는 `fetch()` 나 `XMLHttpRequest` 같은 **공통 API**를 사용하지만, 실제로 OS 수준에서는 Windows의 Winsock, macOS의 BSD Socket, Linux의 Socket 등 **서로 다른 네트워크 시스템**을 사용합니다. 이 차이를 통신 모듈의 내부에서 맞춰줍니다. 

5. 자바스크립트 해석기

• ** 자바스크립트 코드를 해석하고 실행**합니다.
• HTML, CSS는 단순히 읽어서 표시하면 끝이지만, 자바스크립트는 실행을 해야됩니다. 이때 브라우저에서 내장된 JS엔진이 코드를 컴퓨터가 이해할 수 있는 기계어로 변환하고 실행합니다.
  • 대표적으로 Chrome, Edge, Opera는 V8, Safari는 JavaScriptCore (Nitro)를 사용합니다.

    6. UI 백엔드

    • 콤보박스, 버튼, 스크롤바 같은 브라우저 자체의 기본 UI 요소(창, 탭, 스크롤 등)를 그리고,
    • 렌더링 엔진이 만든 웹 콘텐츠를 실제로 화면에 그려주는 *그래픽 계층입니다.
    • 운영체제의 그래픽 시스템을 사용하지만, 브라우저 내부에서는 공통 인터페이스를 통해 관리되기 때문에 플랫폼(Windows, macOS, Linux 등)에 종속되지 않습니다. → 즉, 운영체제별로 서로 다른 UI 시스템을 통일된 방식으로 사용할 수 있도록 도와줍니다.

7. 자료 저장소

• 브라우저에서 사용하는 데이터를 저장하는 계층입니다.
• 쿠키, 캐시, localStorage, sessionStorage 등 다양한 형태의 데이터를 저장하는 계층입니다.
  → HTML5 명세에는 브라우저 내부에 데이터를 저장할 수 있는 기능(API) 이 포함되어 있습니다. 서버가 아닌 사용자 브라우저(클라이언트)에 데이터를 저장 할 수 있습니다.

브라우저의 렌더링 파이프라인

브라우저가 웹 페이지를 화면에 표시하기 위해 거치는 과정입니다. 크게 6단계로 나눌 수 있습니다.

각 단계는 브라우저 내부에서 순차적으로 수행되며, 일부 단계가 다시 실행되면 성능에 영향을 줄 수 있습니다.

1. DOM 트리 생성

• 브라우저는 HTML 파일을 받으면 파싱을 시작합니다.
• HTML Parser는 파일을 바이트 단위로 읽어 문자로 변환한 뒤, 이를 다시 HTML 토큰으로 변환합니다.
• HTML 토큰에는 시작 태그, 종료 태그, 속성 이름과 속성 값이 있습니다. 따라서 브라우저는 토큰이 생성되면 이를 기반으로 DOM 트리를 생성합니다.
• DOM트리는 HTML 문서의 구조를 트리 형태로 표현한 것으로, 각 태그가 노드가 되어 부모-자식 관계를 형성합니다. 태그 1개당 노드 1개가 됩니다.
• link, img 태그는 노드를 생성할때 브라우저가 해당 리소스를 다운 받습니다.
• <script> 태그를 만나면 DOM 생성을 잠시 중단하고 자바스크립트를 실행합니다.

2. CSSOM 생성

• 브라우저는 css파일을 파싱합니다. css 파일도 html 파일과 마찬가지로 바이트 단위로 읽은 뒤 문자로 변환합니다. 그 후, css 규칙으로 문자열을 나누는데 선택자와 선언자로 구별합니다.
• 선택자는 스타일을 적용할 HTML 요소를 정의하고, 선언부에는 실제 스타일 규칙이 작성됩니다. 즉, 선택자에는 html 요소, 선언에는 css 정보가 담기게됩니다. 이 규칙을 기반으로 cssom 트리를 생성합니다.
• CSSOM 트리는 DOM 트리와 유사한 구조이며, 각 노드에 스타일 정보가 담겨 있습니다.

3. 렌더 트리 생성

• DOM 트리와 CSSOM 트리를 합쳐서 렌더 트리를 생성합니다.
• display:none은 렌더트리에 포함되지 않습니다.

4. 레이아웃 (Layout)

• 브라우저가 렌더 트리를 사용해 각 요소의 정확한 위치와 크기를 계산하는 과정입니다.

• 리플로우(reflow)

  • DOM, CSS 스타일이 변경되면 브라우저가 각 화면의 요소를 다시 계산하는 과정입니다.

    부모 노드의 레이아웃 변화는 자식 노드의 레이아웃까지 영향을 미쳐 reflow를 발생시킵니다.

    일반적으로 리플로우는 리페인트까지 발생하기 때문에 성능에도 영향을 미칩니다.

  • reflow를 유발하는 css 속성

    • 크기 관련 속성 : width, height, padding, margin 등
    • 위치 관련 속성 : position, top, left 등
    • 레이아웃 관련 속성 : display, flex 등
    • 폰트 크기 관련 속성 : font-size , font-weight 등

  • 최적화 하는 방법

    • reflow를 유발하는 css 속성 최소화로 사용하기 ** 렌더링 성능을 최적화 하기 위해서는가능한 CSS스타일을 미리 설정해 초기 로드 시에만 계산**이 이루어지도록 하고, 이후에는 변경하지 않는 것이 좋습니다.

5. 페인팅(Painting)

• 브라우저가 각 요소를 실제 화면에 그리는 작업으로 텍스트, 색상, 그림자, 이미지 등 모든 시각적 요소가 화면에 그려집니다.

• 화면에 표시될 그래픽 요소를 생성하는 과정이기 때문에 복잡한 그래픽이나 애니메이션은 페인팅 작업이 많아져 성능이 저하될 수 있습니다.
• 리페인트(rePaint)
  • 웹 페이지에서 요소의 레이아웃은 그대로인데 색상이나 배경 등 요소의 모양이나 스타일이 변경될 때 다시 화면에 그리는 과정입니다.
  • 브라우저는 요소의 모양만 다시 그리면 되기 때문에 reflow보다는 비용이 덜 들지만, 여전히 성능에 영향을 줄 수 있습니다.
  • DOM, CSS 스타일이 변경되면 브라우저는 각 화면의 요소를 다시 계산*해야 합니다.
  • rePaint 유발하는 css 속성
    • 색상 관련 속성 : color, background-color 등
    • 테두리 관련 속성 : border-color, border-radius 등
  • 최적화 하는 방법
    • ** CSS 애니메이션에 transform, opacity 사용하기** transform, opacity은 레이아웃이나 페인트 과정을 거치지 않고 컴포지팅 단계에서만 처리됩니다.

6. 컴포지팅(Compositing)

• 브라우저가 화면에 그릴 요소들의 레이어를 각각 분리한 뒤 결합하여 최종 화면을 구성합니다. GPU가 각 레이어를 합성(Compositing)하여 실제 픽셀 단위의 화면을 만듭니다.

마치며

브라우저 구조에 대해 공부하고 렌더링 과정을 시각화하고 정리하면서, 내가 작성하는 코드 한 줄이 브라우저 내부에서 어떻게 흘러가는지 조금 더 명확히 이해할 수 있게 되었습니다. 앞으로는 코드를 작성할 때 단순히 결과만 보는 것이 아니라, “이 코드가 브라우저 안에서 어떻게 동작할까?” 를 한 번쯤 떠올려보는 습관을 가져보려 합니다!

참고자료

https://www.youtube.com/watch?v=z1Jj7Xg-TkU&t=284s https://developer.mozilla.org/ko/docs/Web/Performance/Guides/How_browsers_work https://ko.wikipedia.org/wiki/웹_브라우저 https://web.dev/articles/howbrowserswork?hl=ko https://www.youtube.com/watch?v=HgEZ07U_OSc

혹시 useEffect가 언제 호출되는지 모르고 얼레벌레 사용하는 사람 있나요..?

이상 자기소개였습니다. 이제는 더 이상 물러날 곳이 없다! 이번에는 useEffect를 낱낱이 파헤쳐 보겠습니다.

useEffect 란?

useEffect는 외부 시스템과 컴포넌트를 동기화하는 React 훅입니다.

여기서 외부 시스템이란, React가 직접 제어하지 않는 시스템을 의미합니다.

그렇다면 리액트가 제어하지 않는 시스템에는 어떤 것들이 있을까요?

컴포넌트가 화면에 표시되는 동안 네트워크, 브라우저 API, 서드파티 라이브러리 등과 연결해야 할 때가 있습니다.

이러한 것들은 모두 리액트 바깥에서 동작하므로 외부 시스템으로 볼 수 있습니다.

또한 브라우저의 전역 상태(localStorage, sessionStorage 등) 역시 React의 상태 관리 흐름과는 별개로 동작하기 때문에, 외부 시스템입니다.

언제 useEffect를 사용할까?

useEffect는 컴포넌트와 외부 시스템 사이의 동기화가 필요할 때 사용합니다. 아래 표를 보면 어떤 상황에서 useEffect를 활용해야 하는지 한눈에 확인할 수 있습니다.

useEffect 구조

import { useEffect } from 'react';

function test (){

  useEffect(() =>{
  // Setup 
      return // Cleanup
      },[ //Dependencies 
  ])

    return(
    ...
    )
}

• 컴포넌트를 외부 시스템과 연결해야하기 때문에 렌더링할때 가장 최상위 레벨에서 useEffect를 호출해야 합니다.

  • 가장 최상위 레벨에서 호출한다...? 이건 useEffect뿐만 아니라 다른 훅에서도 동일하게 적용되는데요.

  • 여기에서 가장 최상위 레벨이란 조건문, 반복문, 함수 안쪽이 아닌 곳입니다. 간단하게 depth가 가장 얉은 곳에서 호출한다고 생각하면 됩니다. 이렇게 최상위 레벨에서 호출하는 이유는 리액트가 훅 호출 순서를 기준으로 상태를 관리하기 때문입니다! 만약 최상위 레벨이 아닌곳에 훅들이 존재하면 리액트는 렌더링 순서를 파악하지 못하고 Invalid hook call 에러를 발생시킵니다.

       // 올바른 사용법⭕️ 
       function Component({ active }) {
         useEffect(() => {
           if (active) console.log('Effect 실행!');
         }, [active]);
       }
    
       // 잘못된 사용법❌ 
       function Component({ active }) {
         if (active) { 
           useEffect(() => {  // ❌ 조건문 안에서 훅 호출 금지
             console.log('Effect 실행!');
           }, []);
         }
       }

• useEffect는 쉽게 setup, cleanup, dependencies로 이뤄져있는데요.

  • setup: effect 내부 로직, 외부 시스템과 연결

  • cleanup: setup에서 만든 리소스를 정리

  • dependencies: 배열안의 값들이 바뀌면 setup → cleanup 순으로 재실행

• useEffect 자체는 반환값이 없지만, setup 함수 내에서 선택적으로 cleanup 함수를 반환할 수 있습니다.

실행(setup) 함수

useEffect(() => {
  // setup 예시 
  const id = setInterval(() => console.log('tick'), 1000);
}, []);

• setup은 effect의 로직이 포함된 함수로, 외부 시스템과 컴포넌트를 연결합니다.

• 실행 시점: 컴포넌트가 DOM에 추가되고 commit 단계가 끝난 후, 비동기적으로 실행됩니다.

  • ** 리액트 컴포넌트의 렌더링 과정**

  • 1. Render Phase* → JSX를 계산해서 가상 DOM(Virtual DOM)을 만듭니다. → 아직 실제 DOM에는 반영되지 않았습니다. → 여기서는 순수 계산만 하고, 브라우저 화면에는 아무 것도 나타나지 않아요!

  • 2. Commit Phase* → 가상 DOM에서 실제 DOM으로 변경 사항을 반영합니다. → 브라우저가 실제 화면을 그리기(paint) 직전 단계까지 완료합니다. 따라서 DOM 조작이나 외부 API 호출은 반드시 useEffect 안에서 수행해야 합니다.

• 의존성 배열이 변경될 때마다 실행됩니다.

• 필요시 clean up 함수를 반환하여 setup에서 생성한 리소스를 정리합니다.

정리 (cleanup) 함수

useEffect(() => {
  const id = setInterval(() => console.log('tick'), 1000);
  // 정리함수 예시 
  return () => clearInterval(id); 
}, []);

• 리액트가 컴포넌트를 언마운트하거나 effect를 다시 실행하기 직전에 자동으로 호출하는 별도의 단계입니다.

  cleanup 함수는 실행 함수를 제거하는 것이 아니라, 리소스를 정리하는 로직으로 리액트가 자동으로 호출합니다.

  • *리액트 컴포넌트의 생명주기 *
    • 마운트: 화면에 추가 → 살아있는 상태
      • 업데이트: props/state 변화 → 살아있는 상태
      • 언마운트: 화면에서 제거 → 종료 상태

• *cleanup의 실행 시점 *
  • 의존성 배열의 값이 변경되었을때 → 먼저 정리함수(CleanUp) 실행 ⇒ 그 다음에 setup 다시 실행
  • 컴포넌트가 DOM에서 제거되어 언마운트 되었을 때

cleanup이 필요한 이유 : 메모리 누수, setup의 중복 실행을 방지

• 컴포넌트가 언마운트될 때 cleanup이 없으면, 이전 effect 의 setup에서 생성한 자원(타이머, 이벤트 리스너 등)이 계속 메모리를 차지하게 됩니다.
• 또한, 의존성이 바뀌면 setup함수가 다시 실행되는데 이때, 이전의 setup이 남아있어 중복 실행될 수 있습니다.

• cleanup가 필요한 경우

  구분	설명	예시	cleanup 필요 여부
  네트워크 연결	서버와 지속적 연결	WebSocket, SSE	✅ 필요
  브라우저 API	DOM 이벤트, 타이머	addEventListener, setInterval	✅ 필요
  외부 데이터	fetch, axios	API 호출	✅ 필요
  서드파티 객체	외부 라이브러리	Chart.js, Mapbox	✅ 필요
  내부 상태 로직	리액트 상태 기반 UI	setState	❌ 불필요
  - cleanup은 setup에서 생성한 리소스만 정리해야됩니다.

의존성(dependecies) 배열

• 의존성 배열은 선택할 수 있지만, 배열에 들어갈 항목은 고정된 값입니다.

  • 배열 안에 포함되는 값들은 effect 내부 코드에서 참조되는 모든 반응형 값(props, state, 컴포넌트 내부 변수/함수) 이어야 합니다.

  • 리액트의 린터(ESLint-plugin-react-hooks)는 누락된 의존성을 자동으로 검출하고 경고를 표시합니다.

    • 경고하는 이유는 의존성 누락 시 stale state(오래된 값 참조) 버그를 유발할 수 있기 때문입니다.
    • 코드 린터(Linter) : 코드를 작성하는 동안 실시간으로 문제를 찾고 해결하는데 도움을 줌
    • 의존성 검사 과정
    1. Lint 검사 → 먼저 코드에서 의존성 배열에 필요한 값이 누락되지 않았는지 확인합니다. (Linter)
    2. 반응값 의존성 검증 → 의존성 배열에 있는 값들이 실제로 존재하는지 체크 (반응값 의존성 검증)
    3. Object.js → 실제 의존성 값들을 모아 관리하는 객체를 만듦
    4. Object.js에서 이전 값과 비교 → 이전 렌더 때 값과 지금 값이 같은지 비교 (이전값과 비교)

    • 같음 → effect setup은 실행되지 않음 (effect setup 실행 X)

    • 다름 → effect setup 실행 (effect setup 실행)

    ⇒ 리액트는 의존성 배열의 각 항목이 이전 렌더링과 값이 달라졌는지(Object.is 기준) 비교해 다를 때만 effect를 재실행합니다. ⇒ 만약, 의존성 배열에 의존성이 없다면, 컴포넌트는 리렌더링될 때마다 실행될 수 있습니다.

• useEffect 의존성 배열 사용 예시

//의존성 배열 사용X
useEffect(() => {
  // 모든 렌더링 후에 실행됩니다
});

// 의존성 배열사용 O - 의존성 없음 
useEffect(() => {
  // 마운트될 때만 실행됩니다 (컴포넌트가 나타날 때)
}, []);

// 의존성 배열사용 O - 의존성 있음 
useEffect(() => {
 // 마운트될 때 실행되며, 또한 렌더링 이후에 a 또는 b 중 하나라도 변경된 경우에도 실행됩니다
}, [a, b]);

그래서 useEffect는 언제 호출될까?

• useEffect 실행 과정

  1. 처음 렌더 → 실행함수(setUp) 실행
  2. 의존성 변경 → 먼저 정리함수(cleanUp) 실행 ⇒ 그 다음에 setup 다시 실행
  3. 컴포넌트 언마운트 → cleanup 실행

• 컴포넌트가 화면에 추가되었을때 === 컴포넌트 마운트 되었을 때

• 의존성 배열이 변경되었을때 === 리렌더링이 발생했을 때

• 컴포넌트가 화면에서 제거되었을 때 === 컴포넌트 언마운트 되었을 때

💡 useEffect에 관한 궁금증 정리

1. 의존성 배열이 없을 때와 빈 배열일 때의 차이는 뭘까?

의존성 배열이 없을 때는, 리액트가 어떤 값이 바뀌었는지를 추적하지 않기 때문에 모든 렌더링마다 useEffect가 실행됩니다. 따라서 useEffect 내부에서 상태를 변경하면 렌더링 → useEffect 실행 → 상태 변경 → 렌더링의 무한 루프가 생길 수 있습니다.

반면, 빈 배열([]) 을 전달하면 리액트는 “이 effect는 어떤 값에도 의존하지 않는구나”라고 판단해서 컴포넌트가 처음 마운트될 때 딱 한 번만 실행합니다. 이후에는 의존성 변경이 없기 때문에 재실행되지 않습니다.

2. useEffect 안에서 console.log 찍었을 때 왜 두 번 찍힐까?

리액트18에서 StrictMode가 켜진 개발 환경에서는 useEffect가 두 번 실행되는 경우가 있습니다.

그 이유는 리액트가 부수효과와 cleanup 함수가 올바르게 작성되었는지 검증하기 위해서입니다.

구체적으로, 컴포넌트가 마운트되면 useEffect가 실행되고, cleanup 함수가 호출된 뒤 다시 useEffect가 실행됩니다.

이렇게 해서 개발자가 작성한 cleanup 함수가 effect를 완전히 정리하는지, 부수효과가 안전하게 재실행될 수 있는지 확인할 수 있습니다.

실제 프로덕션 환경에서는 이 동작이 한 번만 실행됩니다

3. 의존성 배열에 객체나 함수를 넣으면 어떤 문제가 생길까?

객체와 함수는 참조 타입이기 때문에, 렌더링마다 새로운 객체나 함수가 생성되면 참조가 달라졌다고 판단되어 useEffect가 불필요하게 재실행될 수 있습니다.

• 참조 타입: 변수에 값 자체가 아니라 값이 저장된 메모리 주소가 들어감

이로 인해 불필요한 API 호출이나 DOM조작이 반복되거나, 메모리 사용이 증가할 수 있습니다.

해결 방법으로는 useMemo나 useCallback을 사용해 참조를 고정시켜 불필요한 effect 재실행을 방지할 수 있습니다.

4. useEffect가 여러 개 있을 때 실행 순서는 어떻게 될까?

// useEffect가 여러 개 있을 때
  const [count, setCount] = useState(0);
  const [message, setMessage] = useState("");

  // 첫 번째 useEffect
  useEffect(() => {
    console.log("첫 번째 useEffect 실행");
    setCount(prev => prev + 1);
  }, []);

  // 두 번째 useEffect
  useEffect(() => {
    console.log("두 번째 useEffect 실행, count:", count);
    setMessage(`Count is ${count}`);
  }, [count]);

  // 세 번째 useEffect
  useEffect(() => {
    console.log("세 번째 useEffect 실행, value:", message);
  }, [message]);

컴포넌트에 useEffect가 여러 개 있을 경우, 각 useEffect는 독립적으로 동작합니다.

모든 useEffect는 commit 단계 후 실행되며, jsx 파일에 작성된 코드를 기준으로 위에서부터 아래로 실행됩니다.

• 예시 코드 실행 흐름

    1️⃣ 첫 번째 useEffect 실행 
    → console.log("첫 번째 useEffect 실행")
    → setCount(prev + 1) 
    → count 상태 업데이트

    2️⃣ 두 번째 useEffect 실행 (count 변경 감지) 
    → console.log("두 번째 useEffect 실행, count:", count)
    → setMessage(`Count is ${count}`) 
    → message 상태 업데이트

    3️⃣ 세 번째 useEffect 실행 (value 변경 시만 실행) 
    → console.log("세 번째 useEffect 실행, value:", value)

각 useEffect는 의존성 배열을 기준으로 실행 여부가 결정됩니다.

의존성 배열이 변경되면 해당 effect만 재실행되고, 나머지 useEffect는 영향받지 않습니다.

즉, 렌더링 후 순서대로 effect가 실행되지만, 각 effect는 서로 독립적이므로 어던 effect의 실행이 다른 effect의 실행을 막지 않습니다.

5. 만약 useEffect 안에 비동기 함수를 직접 사용하면 어떤일이 생길까?

// 문제 상황
useEffect(async () => {
  const data = await fetchData();
  setData(data);
}, []);

useEffect 안에서 비동기 함수를 직접 async로 선언하면, useEffect 콜백이 Promise를 반환하게 되어 리액트가 이를 처리할 수 없습니다.

왜냐하면 리액트에서 useEffect 콜백 함수가 순수 동기 함수일 것으로 기대하기 때문입니다.

리액트는 콜백이 값을 반환하지 않거나 undefined를 반환할 것으로 예상합니다.

그런데 async를 붙이면 콜백 함수는 항상 Promise를 반환하게 되기 때문에 리액트에서 처리할 수 없습니다.

또한 비동기 작업이 완료되기 전에 화면이 렌더링되면, 데이터가 없는 상태로 화면이 그려지기 때문에 사용자 경험에 영향을 줄 수 있습니다.

따라서 리액트는 useEffect 안에서 별도의 async 함수를 선언하고 호출하는 방식을 권장합니다.

// 해결방법 
useEffect(() => {
  const fetchData = async () => {
    const data = await fetchSomething();
    setState(data);
  };

  fetchData();
}, []);

6. cleanup 함수를 작성하지 않으면 어떤 문제가 생길까?

cleanup 함수를 작성하지 않으면, 컴포넌트가 언마운트될 때 리소스를 정리하지 못해 메모리 누수가 발생할 수 있습니다. 또한 setInterval, 이벤트 리스너, WebSocket 연결 등은 계속 활성 상태로 남아 불필요한 동작을 유발할 수 있습니다. 따라서 useEffect에서는 생성한 리소스를 cleanup 함수에서 반드시 해제하여, 메모리 사용과 이벤트 실행을 안전하게 관리해야 합니다.

7. useEffect안에서 useState를 호출하면 어떻게 될까?

// 문제 상황
useEffect(() => {
  const [count, setCount] = useState(0); 
  setCount(count + 1);
});

useEffect안에서 useState를 호출하면 무한루프가 발생할 수 있습니다. useEffect 안에서 useState를 호출하면, 상태가 변경되면서 컴포넌트가 다시 렌더링됩니다.

만약 의존성 배열이 잘못 설정되었거나 없으면, useEffect는 렌더링 후 다시 실행되고, 다시 state를 업데이트하는 순환이 발생하기 때문입니다.

따라서 useEffect 안에서 상태를 업데이트할 때는 의존성 배열을 정확히 관리하거나, 업데이트 조건을 제한하는 방식으로 무한 루프를 방지해야 합니다.

//해결방법
const [count, setCount] = useState(0); // ✅ 최상위에서 훅 호출

useEffect(() => {
  setCount(prev => prev + 1); // ✅ 상태 업데이트만 수행
}, []); // ✅ 의존성 배열로 실행 횟수 제어

8.useEffect 안에서 props를 읽는데 의존성 배열에 안 넣으면 왜 경고가 나올까?

//문제상황
  const [userData, setUserData] = useState(null);

  useEffect(() => {
    // userId를 사용하는데 의존성 배열에 없음
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => setUserData(data));
  }, []); // ❌ userId가 바뀌어도 effect 재실행 안 됨

useEffect 안에서 props를 읽는데 의존성 배열에 포함하지 않으면, 해당 props가 변경되어도 effect가 재실행되지 않습니다.

이로 인해 effect는 최신 데이터를 기준으로 동작하지 않게 되고, 화면이나 부수효과가 예상과 다르게 동작할 수 있습니다.

리액트는 이러한 문제를 예방하기 위해 “missing dependency” 경고를 발생시킵니다.

따라서 useEffect에서 사용하는 모든 외부 값(props, state 등)은 의존성 배열에 포함시켜 effect가 항상 최신 데이터를 기준으로 실행되도록 해야 합니다

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => setUserData(data));
  }, [userId]); // ✅ userId 변경 시 effect 재실행

마치며

“useEffect는 언제 호출될까?” 질문의 시작으로 useEffect에 관한 궁금증을 모두 정리해 보았습니다. 글을 쓰면서 느낀 점은 "내가 리액트 렌더링 과정을 정확히 알고 있었나..?", "내가 useEffect의 실행 로직을 알고 있었나..?"라는 생각이 들었고 과거의 저는 정말 수박 겉핥기 식으로 코드를 작성했구나를 느낄 수 있었습니다. 비록 그동안 수박 겉핥기 식으로 useEffect를 사용했지만, 앞으로는 실행 시점과 cleanup, 의존성을 고려해서 useEffect를 사용할 수 있을 것 같습니다! 그리고 브라우저의 동작원리에 대해서 다시 공부하고 정리해야 될 것 같습니다..배움의 축복이 끊이질 않네요

참고자료

https://ko.react.dev/learn/render-and-commit https://www.maeil-mail.kr/question/64 https://ko.react.dev/reference/react/useEffect https://ko.react.dev/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development

이제 FSD가 프론트엔드 프로젝트에 사용하기 적합하다는 것을 알게 되었습니다.

근데 그 다음은 어떻게 하면 좋을까요.? 막상 entites, shared, features는 어떻게 구분하고 그 안에는 어떤 slice를 넣으면 좋을지 모르겠습니다.

각각의 Layer에는 어떤 Slice를 넣어야될까?

Layer 우선순위: App → Pages → Widgets → Features → Entities → Shared

Shared

• 앱의 기본 구성요소를 모아둡니다

• 쉽게 전역변수의 모음집이라고 생각하면 됩니다. 모든 페이지에서 사용할 수 있는 것들을 넣어주세요. ex) 백엔드, 서드파티 라이브러리 , 공통 컴포넌트 등

• ** Slice가 필요하지 않습니다.**

• 비즈니스 도메인이 없으므로 Shared 안의 파일끼리는 자유롭게 Import할 수 있습니다.

• shared Layer의 segement 예시

  
    shared/
    ├── api — API 클라이언트와 백엔드 요청 함수
    └── ui — 공통 UI 컴포넌트
                    비즈니스 로직 제외, 브랜드 테마 적용 가능
                    로고, 레이아웃, 자동완성/검색창 등 UI 로직 포함 가능
                    자동완성/검색창 등 UI 로직 컴포넌트도 가능
    └── lib — 내부 라이브러리
                    단순 utils/helpers 모음이 아님
                    하나의 주제(날짜, 색상, 텍스트 등)에 집중
                    README로 역할과 범위를 문서화
    └── config — 환경변수, 전역 Feature Flag
    └── routes — 라우트 상수/패턴
    └── i18n— 번역 설정, 전역 문자열
  

• Segment 이름은 무엇을 하는 폴더인지 드러나야 합니다.

• components, hooks, types처럼 역할이 불명확한 이름은 피해야 합니다.

Entities

• 프로젝트에서 다루는 핵심 데이터 개념을 나타냅니다.

• 비즈니스 용어와 일치하는 경우가 많습니다.
  ex) User, Post , Product

• Entities Layer의 Slice 예시

    entities/
    ├── user
    │        ├── model — 데이터 상태와 검증 스키마
    │        └── api — 해당 Entity의 API 요청
    │        └──  ui — Entity의 시각적 표현
                     완전한 UI 블록이 아니어도 됨 
                     여러 페이지에서 재사용 가능하게 설계
                     비즈니스 로직은 props/slot으로 연결 권장

• 원칙적으로 Slice끼리는 서로 모르면 좋습니다. 하지만 현실적으로 다른 Entity를 포함하거나 상호작용 하는 경우가 있습니다. ex) Comment Slice가 User Slice 정보를 포함하는 경우

  src/ ├── entities/ │ ├── user/ │ │ ├── model/ │ │ ├── api/ │ │ └── ui/ │ │ └── user-avatar.tsx │ └── comment/ │ ├── model/ │ ├── api/ │ └── ui/ │ └── comment-item.tsx

→ 댓글에는 작성자의 정보가 함께 필요합니다.

// entities/comment/ui/comment-item.tsx

import { UserAvatar } from '@/entities/user/ui/user-avatar'; // ❌ 이렇게 하면 안 됩니다 
// => 왜? Entity -> Entity 간의 직접 참조로 결합도가 높기 때문입니다. 

export const CommentItem = ({ comment }) => {
  return (
    <div>
      <UserAvatar user={comment.user} />
      <p>{comment.text}</p>
    </div>
  );
};

⇒ 이때는 로직을 상위 Layer(Feature/Page) 로 올려 처리하면 좋습니다.

src/
├── features/
│   └── comment-with-user/
│       ├── ui/
│       │   └── comment-with-user-item.tsx
│       └── model/
│       └── lib/
├── entities/
│   ├── user/
│   └── comment/

→ features 폴더에 댓글 Comment Slice가 User Slice를 모두 사용할 수 있도록 comment-with-user 폴더를 만든 뒤에 import 해줍니다. → features는 Layer에서 Entity보다 높은 우선순위를 가지고 있기 때문에 imort 할 수 있습니다. ⇒ Entity끼리는 서로 몰라도 되기 때문에 결합도가 낮아집니다!

// features/comment-with-user/ui/comment-with-user-item.tsx

import { UserAvatar } from '@/entities/user';
import { CommentItem } from '@/entities/comment';

export const CommentWithUserItem = ({ comment }) => (
  <div>
    <UserAvatar user={comment.user} />
    <CommentItem comment={comment} />
  </div>
);

근데 여러 군데에서 결합된 entity를 사용한다면?

→ Feature로 올려서 조합하는 것을 권장하지만 만약 여러 Feature에서 같은 조합을 반복해야 한다면 중복 코드가 발생할 수 있습니다.
⇒ 만약 한 Entity 데이터에 다른 Entity가 포함된다면,@x 표기를 사용해 교차 Public API로 연결을 명시적으로 드러내세요!

• @x 주석 적용 예시

   // entities/comment/model/comment.ts
  
   /**
    * Comment Entity
    *
    * **@x user** - Comment는 작성자 User 정보를 포함
    */
   export interface Comment {
     id: string;
     text: string;
     userId: string; // 실제 User 객체는 Feature Layer에서 연결
   }
  

  • @x user → “Comment가 User와 관계 있음”을 명시

  • Comment Entity 내부에서는 User를 import하지 않음

    ⇒ Entity끼리 직접 import하지 않고 Feature Layer에서 조합

    // features/comment-with-user/ui/comment-with-user-item.tsx
    import { Comment } from '@/entities/comment';
    import { UserAvatar } from '@/entities/user';
    
    export const CommentWithUserItem = ({ comment }: { comment: Comment }) => (
    <div>
      <UserAvatar userId={comment.userId} />
      <p>{comment.text}</p>
    </div>
    );
    

  • @x는 “관계가 있음”을 문서/주석으로 드러냅니다.

    ⇒ 즉, 실제 코드 실행이나 import, 의존성을 바꾸는 기능은 없습니다.

Features

• 사용자가 앱에서 수행하는 주요 기능을 담습니다. → 보통 특정 Entity와 연결됩니다.

• 모든 기능을 Features 로 만들 필요는 없습니다. 그러나 여러 페이지에서 재사용되는 경우는 고려해야됩니다.

  • ex) 여러 에디터에서 같은 댓글 기능을 쓴다면 comments를 Features의 Slice로 만듭니다.

      src/
      ├── features/
      │   └── comment/
      │       ├── ui/ — 상호작용 UI(예: 폼)
      │       └── api — 기능 관련 API 요청
      │       └── model — 검증, 내부 상태
      │       └── config — Feature Flag 

• 근데 Features 안에 Slice는 무슨 기준으로 만들어야 하나요?

  • 무엇을 하는 기능인지를 기준으로 비즈니스 관점에서 나누고 이름을 직관적으로 지어야 합니다!

    • 동사 + 명사의 형태로 이름을 지으면 직관적으로 Slice가 무엇을 하는지 알 수 있습니다.

      ex) sign-in (로그인), add-to-cart (장바구니 추가)

  • Features 안에 Slice는 작지만 완전한 기능 단위입니다. ⇒ Slice는 다른 Layer에서 재사용 가능하지만 Slice끼리는 참조하지 않습니다.

• Features가 너무 많으면 중요한 기능을 찾기 어려워집니다. 새로운 팀원과 한 달 뒤의 나를 위하여** Page와 Features 만 봐도 앱 기능 구조를 파악할 수 있도록 구성**해야 합니다.

Widget

• 가장 큰 UI 블록입니다. 여러 페이지에서 재사용하거나, 한 페이지에 큰 블록이 여러개 있을 때 유용합니다. ⇒ 그러나, 재사용하지 않는 특정 페이지의 콘텐츠라면 그냥 Page안에 두는게 낫습니다. ex) 404 에러페이지, 데이터 로딩 상태 표시 등

• 그래서 어떻게 Slice 를 만들고 나눌 수 있을까요?

  • Widget은 UI 중심, 재사용 가능한 큰 블록이기 때문에 Slice를 나누는 기준을 기능/역할 단위로 잡으면 됩니다.

    widgets/
    ├── header/
    │   ├── ui/
    │   │   └── header.tsx
    │   └── model/
    ├── product-card/
    │   ├── ui/
    │   │   └── product-card.tsx
    │   └── model/
    

    ⇒ Widget Slice를 나누는 팁

  1. 재사용 가능한지 판단 → 가능하면 Slice, 불가능하면 Page

  2. Slice 내부 구조는 Features와 비슷하게 Segment(ui, model, lib)를 구성

     → Widget은 UI 중심이므로 Feature처럼 비즈니스 로직에 집착하지 않아도 됩니다.

Page

• 웹/앱의 화면에 해당합니다. → 대부분의 페이지는 1개, Slice도 1개이지만, 유사한 페이지는 하나의 Slice로 묶을 수 있습니다.

• 코드 찾기가 쉽다면 Page Slice의 크기 제한은 없습니다

• 재사용되지 않는 UI는 Page안에 둡니다! (Widget과 다른점)

• 보통 전용 모델은 없고, 간단한 상태만 컴포넌트 내부에서 관리합니다.

      pages/
  ├── home/               // 홈 화면
  │   ├── ui/
  │   │   └── home-page.tsx
  │   └── model/          // 페이지 전용 상태, 필요 시
  ├── product/
  │   ├── detail/         // 상품 상세 페이지
  │   │   ├── ui/
  │   │   │   └── product-detail.tsx
  │   │   └── model/
  │   └── list/           // 상품 목록 페이지
  │       ├── ui/
  │       │   └── product-list.tsx
  │       └── model/
  ├── error/
  │   └── not-found/      // 404 페이지
  │       └── ui/
  │           └── not-found.tsx
  

Process

• 과거에는 여러 페이지를 넘나드는 기능을 위한 탈출구 역할이었지만, 요즘 대부분의 앱에서는 사용하지 않습니다.

App

• 앱 전역에서 동작하는 환경설정, 공통 로직을 관리하는 Layer입니다. → ex) 라우터 설정, 전역 상태 관리, 글로벌 스타일, 진입점 설정 등 앱 전체에 영향을 주는 코드

• Shared 처럼 Slice 없이 Segment로 구성합니다.

    src/
    ├── app/
    │   └── routes/ -  Router 설정
    │   └── store/ -   Global State Store 설정
    │   └── styles/ -  Global Style
    │   └── entrypoint/ -  Application Entry Point와 Framework 설정

마치며

FSD는 공식문서를 참고해 공부했지만, 실제 프로젝트에서는 구조가 많이 달라질 수 있을 것 같습니다.

저 같은 경우는 현재 api segment가 각 Slice마다 존재하는데, 이 구조가 유지보수에 정말 용이할지 고민이 됩니다. 개인적으로는 Features Slice순위까지 두는 것으로 충분할 것 같다는 생각도 듭니다. 따라서 팀원과 상의하여 api segment를 어디까지 허용할지 결정하는 게 좋겠습니다.

전체적인 틀을 가져가되, 우리팀에 꼭 맞는 폴더구조를 만드시길 바랍니다.

참고자료

https://feature-sliced.design/kr/docs/reference/layers

한 달의 전의 나는 타인이다.

이 말을 아시나요? 제가 만들어낸 말입니다.

다른 사람의 코드를 볼 때마다, 과거의 내가 짠 코드를 볼 때마다 어디에 뭐가 있는지 모든게 리셋되서 파일을 찾는데 단단히 지쳐버렸습니다... 이제는 FSD를 받아들이기로 했습니다.

FSD란?

• Feature Sliced Design로 프론트엔드 애플리케이션 구조를 위한 아키텍처 방법론입니다.

• Layers, Slices, Segments는 모두 폴더 단위입니다.
• 각각의 Layers 안에는 Slices가 있고 각각의 Slices 안에는 Segments가 존재합니다

Layer

1. App* - Routing, Entrypoint, Global Styles, Provider 등 앱을 실행하는 모든 요소
2. Processes(더 이상 사용되지 않음) - 페이지 간 복합 시나리오
3. Pages - 전체 page 또는 중첩 Routing의 핵심 영역
4. Widgets - 독립적으로 동작하는 대형 UI·기능 블록
5. Features - 제품 전반에서 재사용되는 비즈니스 기능
6. Entities - user, product 같은 핵심 도메인 Entity
7. Shared - 프로젝트 전반에서 재사용되는 일반 유틸리티

• App·Shared Layer는 Slice 없이 곧바로 Segment로 구성됩니다. → 왜냐하면 두 폴더는 이미 공통된 영역이기 때문에, 별도의 Slice로 나눌 필요가 없습니다.

• 상위 Layer의 모듈은 자신보다 하위 Layer만 참조할 수 있습니다. 즉, 단방향으로 참조가 가능합니다.

→ ex) pages는 widgets를 참조할 수 있지만, widgets는 pages를 참조할 수 없습니다. pages가 widgets의 상위 layer이기 때문입니다. (= widgets → pages로 import ❌) (= pages → widgets로 import ⭕️)

• Layer에 있는 모든 폴더를 써야하나요?
  • 필요할 때만 추가해도 됩니다. 그러나 대부분의 프론트엔드 프로젝트에서는 최소한 shared , pages , app 은 포함합니다.

Slice

• Slice는 Layer 내부를 비즈니스 도메인별로 나눕니다.

⇒ 이름·개수에 제한이 없으며, 같은 Layer 내 다른 Slice를 참조할 수 없습니다. 왜냐하면 높은 응집도와 낮은 결합도를 유지하기 위해서입니다.

• ex) 로그인과 회원가입 기능이 features 폴더에 있다고 해봅시다.

``` features/ ├── sign-in/ └── sign-up/

• features는 Layer 폴더이고 sign-in , sign-up은 features의 slice에 해당합니다. 근데 이 둘은 서로 참조할 수 없습니다.
  (=sign-in → sign-up로 import ❌) (=sign-in ← sign-up로 import ❌)

Segment

• Slice와 App·Shared Layer는 Segment로 세분화되어, 기술적 목적에 따라 코드를 그룹화합니다.

  • ui - UI components, date formatter, styles 등 UI 표현과 직접 관련된 코드

  • api - request functions, data types, mappers 등 백엔드 통신 및 데이터 로직

  • model - schema, interfaces, store, business logic 등 애플리케이션 도메인 모델

  • lib - 해당 Slice에서 여러 모듈이 함께 사용하는 공통 library code

  • config - configuration files, feature flags 등 환경·기능 설정

    → 대부분의 Layer에서는 위 다섯 Segment로 충분합니다.

    필요하다면 App 또는 Shared Layer에서만 추가 Segment를 정의하세요. (필수 규칙은 아닙니다.)

아니 그래서 FSD 왜 써야됨 ?

• 일관성

  • 모든 팀원이 작성한 코드가 마치 한 사람이 작성한 것처럼 일관성을 가질 수 있습니다.
  • 폴더 구조와 참조 규칙이 미리 정의되어 있기 때문에, 여러 개발자가 동시에 작업하더라도 구조가 흐트러지지 않습니다.
  • 일관된 코드 구조는 유지보수를 쉽게 만들고, 새로운 팀원이 프로젝트에 빠르게 적응하도록 도와줍니다.

• 격리성

  • 단방향 참조와 기능 단위 분리 덕분에, 하나의 기능인 slice 를 삭제하거나 수정하더라도

    다른 영역에 미치는 영향이 최소화됩니다.

  • “부분적인 변경이 전체를 깨뜨리지 않는다”는 점이 큰 장점입니다.

• 도메인 중심 구조

  • 폴더 구조가 비즈니스 도메인 중심(로그인, 장바구니, 결제 등) 으로 구성되어 있기 때문에 프로젝트의 전체 맥락을 몰라도 특정 기능을 독립적으로 개발할 수 있습니다.
  • 이는 기능 단위의 확장성과 테스트 용이성을 크게 높입니다.

그럼 언제 FSD를 써야됨?

• 프로젝트가 점점 커지면서, 기능 개발 속도가 느려졌을 때
• 새로운 팀원이 구조를 이해하기 어려운 상황일때

⇒ 즉, 우리 프로젝트에 구조 전환이 필요할 때 FSD를 고려하면 좋습니다.

마치며

완벽한 프로젝트 구조는 처음부터 나올 수 없다고 생각합니다. 하지만 꾸준히 다듬고 적용하다 보면, 한 달 뒤의 나는 지금의 나를 빠르게 이해하지 않을까요..?ㅎㅎ 아자아자 화이팅!

참고자료

https://feature-sliced.design/