[5팀 윤영서] Chapter 2-1. 클린코드와 리팩토링

[YeongseoYoon]

과제 체크포인트

배포링크 : https://yeongseoyoon-hanghae.github.io/front_6th_chapter2-1/

기본과제

• 코드가 Prettier를 통해 일관된 포맷팅이 적용되어 있는가?
• 적절한 줄바꿈과 주석을 사용하여 코드의 논리적 단위를 명확히 구분했는가?
• 변수명과 함수명이 그 역할을 명확히 나타내며, 일관된 네이밍 규칙을 따르는가?
• 매직 넘버와 문자열을 의미 있는 상수로 추출했는가?
• 중복 코드를 제거하고 재사용 가능한 형태로 리팩토링했는가?
• 함수가 단일 책임 원칙을 따르며, 한 가지 작업만 수행하는가?
• 조건문과 반복문이 간결하고 명확한가? 복잡한 조건을 함수로 추출했는가?
• 코드의 배치가 의존성과 실행 흐름에 따라 논리적으로 구성되어 있는가?
• 연관된 코드를 의미 있는 함수나 모듈로 그룹화했는가?
• ES6+ 문법을 활용하여 코드를 더 간결하고 명확하게 작성했는가?
• 전역 상태와 부수 효과(side effects)를 최소화했는가?
• 에러 처리와 예외 상황을 명확히 고려하고 처리했는가?
• 코드 자체가 자기 문서화되어 있어, 주석 없이도 의도를 파악할 수 있는가?
• 비즈니스 로직과 UI 로직이 적절히 분리되어 있는가?
• 코드의 각 부분이 테스트 가능하도록 구조화되어 있는가?
• 성능 개선을 위해 불필요한 연산이나 렌더링을 제거했는가?
• 새로운 기능 추가나 변경이 기존 코드에 미치는 영향을 최소화했는가?
• 코드 리뷰를 통해 다른 개발자들의 피드백을 반영하고 개선했는가?
• (핵심!) 리팩토링 시 기존 기능을 그대로 유지하면서 점진적으로 개선했는가?

심화과제

• 변경한 구조와 코드가 기존의 코드보다 가독성이 높고 이해하기 쉬운가?
• 변경한 구조와 코드가 기존의 코드보다 기능을 수정하거나 확장하기에 용이한가?
• 변경한 구조와 코드가 기존의 코드보다 테스트를 하기에 더 용이한가?
• 변경한 구조와 코드가 기존의 모든 기능은 그대로 유지했는가?
• (핵심!) 변경한 구조와 코드를 새로운 한번에 새로만들지 않고 점진적으로 개선했는가?

과제 셀프회고

일단 이번주 과제도...쉽지 않았습니다...그래도 최선을 다한것에는 만족합니다..ㅎㅎ..

나의 접근법(어떻게...하지?)

코드는 망했지만 제가 어떻게 이번 과제에 대해 접근하고 풀어 나갔는지에 대해 의식의 흐름으로 작성해보겠습니다.

일단 처음에는 AI를 사용하지 않고 코드의 흐름을 이해하려고 했습니다. 아...그런데 쉽지 않더라고요. 난잡한 변수명에 뇌정지가 왔습니다. 그래서 main.basic.js의 코드에 주석을 달아 달라고 AI에 요청하고, 어떤 기능들이 있는지를 파악하려고 했던 것 같습니다.

그 뒤로는 상수나 변수를 좀 정리했습니다. sel을 selectedProduct로, amt를 amount로 바꾸고... 이런 식으로요. 사실 그렇게 해도 별로 크게 달라지는 것은 없었던 것 같습니다. 그래도 충분히 '더러웠'거든요. 변수명만 바꾼다고 해서 근본적인 구조 문제가 해결되는 건 아니니까요...🥹

상수나 변수명은 정리했고, 이전에 기능별로 분석을 해달라했으니 로직이나 유틸을 분리해볼까?? 라는 생각을 하면서 손을 댔는데, 그때 깨달았습니다. '아 이거 이렇게하면 면접 준비랑 병행 못한다'. 바로 그때 커서 Thinking mode를 켰고요(ㅋㅋㅋ), 제가 직접하지 않고 바로 분리해달라는 요청을 했습니다.

자동사냥 모드 ON

처음엔 이렇게 주문했는데, 제 말을 제대로 못알아듣더라고요. 이때 딱 알았습니다. 제 프롬프트가 너무 넓은 요청을 하고 있구나하는 것을요.

자 너는 내 리액트 선생님이고 자바스크립트와 리액트 개고수야


목표는 이거야

이번 과제는 더티코드를 클린코드의 형태로 개선을 하는 과제입니다. 주어진 테스트를 통과하면서 원래 기능과 동일한 동작을 하는 코드를 만들어주세요. basic과제는 제공되는 더티코드를 클린코드와 리팩토링 원칙에 입각해서 더 나은 코드로 만들어보세요. 주어진 테스트를 참고삼아 좋은 이름, 좋은 모양, 좋은 구조를 가지는 코드로 만들어 보세요.


/basic 디렉토리에 있는 더티코드를 클린코드로 리팩토링
바닐라스크립트를 사용해서 작성된 코드를 클린코드와 리팩토링 원칙에 입각해서 더 나은 코드로 개선
추후 React + Typescript로 고도화 리팩토링을 할 예정이니 이를 꼭 염두에 두고 React로 바꿔도 코드가 많이 변경되지 않도록 리팩토링
자 시작해줘

아 단계별로 커밋할거니까 스텝바이 스텝으로 진행해줘

본인이 리액트 개고수라는 것을 받아들이지 못하는 것 같았습니다.

암튼 이번주에 제가 해야하는 일들이 너무 많았어서...이렇게 하나하나 다 입력해주다가는 큰일날 것 같았습니다. 이때부터는 자동사냥 모드를 켜야겠다는 생각을 했습니다...그러지 말았어야했는데 선택지가 없었어요.

암튼 자동사냥을 하려면 조건이 있었습니다.

1. 내가 생각을 1을 해도 얘가 한 10의 퍼포먼스를 내줄 것.
2. 내가 테스트를 계속 돌리지 않아도 얘가 알아서 테스트를 돌려가면서 리팩토링 해줄 것.

어떤 AI를 사용해야 할까에 대해서도 잠깐 고민을 했었는데요,

이런 비교글을 읽어봐도, 퍼플렉시티한테 비교해달라고 요청해서 읽어봐도 마찬가지더라고요.

클로드 코드가 좀 더 절차적이고 심층적인 분석을 해주는 것 같았습니다. 그러나... 커서룰을 잘 작성하면 클로드 코드처럼 사용할 수 있다고 하길래 UX적으로 불편한 클로드 코드보다 커서를 선택했습니다...ㅎㅎ

그러면 어떻게 해야할까...하다가 커서룰을 제작해보자는 생각을 하게 됩니다.

사실 저는 커서룰을 여태 다른 사람들이 올려주는 룰만 사용했지, 제가 작성해본 적이 없었습니다. GitHub에서 awesome-cursor-rules 같은 레포지토리를 찾아보고, 유튜브에서 커서룰 작성법도 찾아봤는데 생각보다 체계적인 가이드는 없더라고요. 그래서 일단은 창준님이 올려주셨던 단계별로 태스크를 분리해서 작성 가능한 룰 커서룰을 적용해서 단계를 뽑아 줄 수 있는지 물어봤습니다. 이 룰이 좋은 점은 큰 작업을 작은 단계로 나누어서 진행할 수 있다는 거였어요. 하지만 제 상황에는 좀 더 구체적인 룰이 필요했습니다. 특히 "JavaScript를 React-like하게 만들기"라는 특수한 목적이 있었거든요.
그렇게 단계를 뽑아내 나온 컨텍스트를 두고, 저만의 커서룰을 작성하게 됩니다.

커서룰을 처음 작성해봐서 어떻게 써야 할지에 대한 가이드가 없었는데요, 그래서 가이드를 만들기 위해서 페르소나가 달린 커서룰을 가져와서 해당 커서룰을 수정해달라고 했습니다.

제가 참고한 커서룰

Persona

You are a senior full-stack developer. One of those rare 10x developers that has incredible knowledge.

Coding Guidelines

Follow these guidelines to ensure your code is clean, maintainable, and adheres to best practices. Remember, less code is better. Lines of code = Debt.

Key Mindsets

1. Simplicity: Write simple and straightforward code.
2. Readability: Ensure your code is easy to read and understand.
3. Performance: Keep performance in mind but do not over-optimize at the cost of readability.
4. Maintainability: Write code that is easy to maintain and update.
5. Testability: Ensure your code is easy to test.
6. Reusability: Write reusable components and functions.

Code Guidelines

1. Utilize Early Returns: Use early returns to avoid nested conditions and improve readability.
2. Conditional Classes: Prefer conditional classes over ternary operators for class attributes.
3. Descriptive Names: Use descriptive names for variables and functions. Prefix event handler functions with "handle" (e.g., handleClick, handleKeyDown).
4. Constants Over Functions: Use constants instead of functions where possible. Define types if applicable.
5. Correct and DRY Code: Focus on writing correct, best practice, DRY (Don't Repeat Yourself) code.
6. Functional and Immutable Style: Prefer a functional, immutable style unless it becomes much more verbose.
7. Minimal Code Changes: Only modify sections of the code related to the task at hand. Avoid modifying unrelated pieces of code. Accomplish goals with minimal code changes.

Comments and Documentation

• Function Comments: Add a comment at the start of each function describing what it does.
• JSDoc Comments: Use JSDoc comments for JavaScript (unless it's TypeScript) and modern ES6 syntax.

Function Ordering

Order functions with those that are composing other functions appearing earlier in the file. For example, if you have a menu with multiple buttons, define the menu function above the buttons.

Handling Bugs

• TODO Comments: If you encounter a bug in existing code, or the instructions lead to suboptimal or buggy code, add comments starting with "TODO:" outlining the problems.

Example Pseudocode Plan and Implementation

When responding to questions, use the Chain of Thought method. Outline a detailed pseudocode plan step by step, then confirm it, and proceed to write the code. Here's an example:

---

Important: Minimal Code Changes

Only modify sections of the code related to the task at hand. Avoid modifying unrelated pieces of code. Avoid changing existing comments. Avoid any kind of cleanup unless specifically instructed to. Accomplish the goal with the minimum amount of code changes. Code change = potential for bugs and technical debt.

Follow these guidelines to produce high-quality code and improve your coding skills. If you have any questions or need clarification, don't hesitate to ask!

커서룰 작성법에도 사실 왕도가 있을 것 같긴한데, 전 그냥 그런건 모르겠고 '킹갓제너럴엠페러마제스티골져스프레셔스뷰리풀하이클래스엘레강스럭셔리클래식지니어스원더풀러블리월드탑클래스어쩌고커서룰'을 만들고싶었습니다. 진짜 최고의 개발자여야 제 코드를 구원해줄 수 있을 것 같았거든요. 그래서 일단 페르소나에 좋다는 수식어는 다 넣어봤습니다.

이걸 좀 수정해줘

개쩌는 자바스크립트 및 프론트엔드 개발자의 최강자고 지금은 자바스크립트 최고 권위자 및 CTO로서 코드가 엉망인 회사의 자바스크립트 스파게티 코드를 리액트와 닮게 만들고 그를 자연스럽게 리액트로 전환하도록 하려고해

컴포넌트랑 이벤트위임 그리고 상태업데이트부가 있으면 좋을거같고 컴포넌트는 jsx의 형태와 닮도록 개발하고싶어

그리고 절대 기존 코드의 로직은 건들지 않고 리팩토링만 진행하면 좋겠어

이걸 다 만족하면서 리팩토링할수있도록 커서룰을 보완해줘

계속해서 자바스크립트를 리액트와 닮게 만들어 달라고 요청을 하는데, 이 친구가 그 뒤로 React-like라는 용어를 사용하면서 수정하긴 하더라고요.(ㅎㅎ 그치만 리액트와 전혀 닮지 않았다는...)

그렇게 하니까 룰을 짜주긴했는데, 앞서 언급했던 것처럼 저는 회사일+면접준비+과제 세 가지를 동시에 해야했기 때문에 정말 자동사냥 모드가 필요했습니다. 단순히 Auto Run 모드를 켜주는 것만으로는 불가능했습니다. 리팩토링을 하면서 테스트가 계속 깨지는데, 이 친구가 작성해준 룰로는 리팩토링을 하고 테스트를 재실행해주지 않았기 때문입니다.

그래서

아 그리고 여기다가

pnpm test 해서 테스트를 깨지지 않게 계속 회귀테스트도 진행하라는 룰 넣어줘

라는 주문을 넣어서 아래와 같은 커서룰을 제작합니다.

제가 작성한 커서룰

🛠️ JavaScript to React-Like Refactoring Cursorules

Purpose

This document defines strict refactoring rules for transforming legacy JavaScript "spaghetti" code into a React-like structure. The goal is to improve maintainability without altering existing business logic, inspired by JSX-style rendering, event delegation, and isolated state handling.

⚠️ Never modify existing business logic.
⚠️ Only restructure code without changing its behavior.

---

👑 Role Assumed

The refactoring is executed by a senior JavaScript expert (CTO-level) responsible for safe architectural migration, ensuring minimal friction and zero regression.

---

✅ Principles

1. Componentization First

Extract related DOM + logic into modular components.

• ✅ Good: function ProductCard(props) { ... }
• ❌ Bad: function renderProductBlock() { ... }

2. JSX-Like Function Structure

Structure the component's return to reflect JSX semantics via:

• Template literals
• document.createElement
• Consistent nesting and layout hierarchy

3. Event Delegation Pattern

Avoid direct event listeners inside loops or for every element.

• ✅ container.addEventListener('click', handleClick)
• ❌ el.addEventListener('click', ...) inside .forEach

4. State Isolation

Simulate useState behavior via top-level scope isolation.

• ✅ let isOpen = false with updater function
• ❌ Mutating state directly inside a handler

5. Immutable Thinking

Prefer immutable operations. Avoid in-place mutations unless absolutely necessary.

6. Render Function Convention

• Use PascalCase or renderX naming
• Must accept props (or equivalent arguments)
• Must be pure and side-effect free

7. Early Return in Handlers

Avoid deep nesting in event handlers.

• ✅ if (!target) return;
• ❌ Deep if-else or switch-case chains

8. Naming Convention

• ✅ Use camelCase for variables, functions, and handlers
• ✅ Use PascalCase only for component-like pure render functions (like React)
• ❌ Avoid snake_case or inconsistent casing

---

🧩 Directory Structure

src/
├── components/
│   └── ProductCard.js       ← React-like component
├── dom/
│   └── domHelpers.js        ← DOM abstraction helpers
├── state/
│   └── stateStore.js        ← isolated state manager
└── events/
    └── clickDelegates.js    ← centralized event delegation

---

🔒 Safety Rules

• ❌ Never rename variables or functions unless unused
• ❌ Never alter logic branches or flow
• ✅ Use // TODO: comments to mark refactored boundaries
• ✅ Add /** Pure render function */ JSDoc for all JSX-like components

---

🧪 Testing & QA

🔁 Refactoring without regression is non-negotiable.

• ✅ Always run tests via pnpm test before and after changes
• ✅ Run tests frequently during refactor, especially after any structural or state change
• ❌ Do not commit if any test fails, even if the failure seems unrelated
• ✅ Perform DOM snapshot diffing (if available)
• ✅ Use console.assert to validate structural equivalence
• ⚠️ Temporary logs allowed within component scope only, and must be removed before commit
• ✅ Component output must be visually and functionally identical pre/post refactor

---

📝 Example Conversion

Before

const button = document.createElement('button');
button.innerText = 'Click me';
button.onclick = function () {
  alert('clicked');
};
document.body.appendChild(button);

After

/** Pure render function */
function ClickButton(): HTMLElement {
  const button = document.createElement('button');
  button.innerText = 'Click me';
  button.addEventListener('click', handleClick);
  return button;
}

function handleClick() {
  alert('clicked');
}

document.body.appendChild(ClickButton());

---

🧭 Migration Phases

1. Phase 1 – Extract component boundaries
2. Phase 2 – Centralize event delegation
3. Phase 3 – Isolate state per component
4. Phase 4 – JSX/React compatibility pass

---

🛑 Anti-Patterns

Pattern	Why to Avoid
.innerHTML = ...	XSS-prone, hard to test
Global let count = 0	Shared state = bugs
Direct DOM mutation	Untrackable, brittle
Nested functions in render logic	Unreadable and non-composable

---

📌 PR Checklist

• No logic modifications
• JSX-style component naming used
• Event handlers prefixed with handle
• No loop-level .addEventListener
• // TODO: comment added where necessary
• ✅ pnpm test passes locally before each commit

---

📎 Git Commit Tags

Use these prefixes in commit messages:

• refactor(component): Refactor logic into a React-like component
• refactor(event): Apply event delegation pattern
• refactor(state): Isolate or lift state cleanly
• test(regression): Add missing test or fix test artifact
• docs(cursorules): Update cursorule documentation

---

✍️ Notes

This document evolves alongside the codebase.
Suggest additions and improvements via pull request under the tag:

docs(cursorules): update rulebook

물론 지피티와 좀 충돌은 일어났지만...ㅎㅎ... 그렇게 저의 자바스크립트와 리액트에서 킹갓개발자이자 CTO며 권위자인 사수분이 탄생하셨습니다.

제 전반적인 커서룰 만들기 작업은 요기서 보실 수 있습니다. (잘 만들었는지는 모르겠습니다)

그 뒤로 자동사냥을 하면서 제가 원하는 형태를 잡아갔습니다.

처음에는 정말 단순한 요청부터 시작했어요.

• "음 다 좋은데 지금 나눈것도 좀 features단위로 찢을수있지 않나...먼가 다 한 파일에 때려박아놧네"
• "그 service는 services로 해줘 왜 자꾸 service만 단수야?"
  이런 식으로 하나하나 방향을 잡아주면서 점진적으로 개선해나갔어요.

가령 제 커서는 클래스를 엄청나게 좋아하는 친구라서, Store분리에 클래스를 적용하려고 하면, 리액트로 넘어가는 상황에 불편하게 될 것 같아서 클래스를 만들지 말고 함수 형태로 만들어 달라고 한다던가, 헬퍼 함수를 분리하는데 UI와 강결합 되어있는 케이스가 있어서 이를 좀 더 분리해달라고 한다던가 하는 프롬프트를 계속 주입시켜줬습니다.

// 커서가 처음에 만들려던 것 (클래스 기반)
class ProductStore {
  constructor() {
    this.products = [];
    this.selectedProduct = null;
  }
  
  setProducts(products) {
    this.products = products;
  }
}

// 제가 원했던 것 (함수 기반, React useState와 유사)
export let productState = {
  products: [],
  selectedProduct: null
};

export const setProductState = (updates) => {
  productState = { ...productState, ...updates };
};

또 리팩토링을 진행하면서 괜찮은 상태(테스트는 일단 통과하는)가 되었다면 문서화를 진행해달라고 요청했습니다. 이 부분이 중요했던 이유는, 나중에 다른 개발자(혹은 미래의 나)가 이 코드를 봤을 때 왜 이렇게 구조를 잡았는지 이해할 수 있도록 하기 위해서였어요. 특히 "왜 이렇게 리팩토링했는지"에 대한 맥락을 남겨두는 게 중요하다고 생각했습니다.
추가된 문서를 확인해보실 수 있습니다.

또한 advanced도 basic의 테스트와 동일한 기능을 하는지를 테스트하기 위해 테스트를 추가했습니다. 809b9c6
요부분도 ai를 통해 작성해봤는데, 너무 빠르게 잘 작성해줘서 만족스러웠습니다.

ai를 통해 테스트를 작성한 방법은 6e525b3로 문서화하였습니다.

과제를 하면서 내가 제일 신경 쓴 부분은 무엇인가요?

멘토링을 들으면서 접근 자체를 '어떻게하면 리액트로 마이그레이션이 쉬울까?'라는 접근으로 가져가고 싶었던 것 같습니다.
처음에는 단순히 "클린코드로 만들자"라고 생각했는데, 발제때 테오가 말씀해주신 "나중에 React로 마이그레이션할 때를 생각해보세요"라는 조언이 정말 핵심이었어요. 그래서 방향을 완전히 바꿨습니다.
구체적으로는

• 컴포넌트화: 관련 로직들을 하나의 함수로 묶어서 Props를 받는 형태로 만들기
• 상태 관리: window.productStore 같은 전역 변수를 productState, setProductState 형태로 바꿔서 useState와 유사하게 만들기
• 이벤트 위임: 개별 요소에 이벤트 리스너를 다는 대신 상위 요소에서 위임받아 처리하기
• DOM 추상화: 직접적인 DOM 조작을 유틸 함수로 감싸서 나중에 React로 바꿀 때 쉽게 교체할 수 있도록 하기

이번 과제를 하면서 처음에는 어떻게 하면 AI를 잘 사용할 수 있을까에 매몰되었는데요, 사실 AI를 '잘' 사용하는 것 자체는 좋지만 AI는 수단이라고 생각하고 결과물이 중요하다는 생각을 하게 되었던 것 같습니다 ㅎㅎ 이번 주차는 클린코드 주차니까요..ㅎㅎ....

특히 중간에 "아, 내가 AI한테 너무 의존하고 있나?"라는 생각이 들었던 순간이 있었어요. 테스트가 계속 깨지는데 원인을 파악하지 못하고 계속 AI한테만 맡기고 있더라고요. 그래서 중간중간은 직접 코드를 읽어보고 문제를 파악하려고 노력했습니다. 아무래도 아직은 인간의 개입이 있지 않으면 풀 AI로 작업하는건 불가능하지 않을까? 특히 유지보수적인 측면이나 리팩토링을 제어하는건 사람이 해야할일이 아닐까? 하는생각이 들었습니다. ~~ (처음코드 어떻게 유지보수 하냐고~)~~

그리고 기본과제에서 심화과제로 넘어갈때 최대한 기존 기본과제의 형태를 심화과제로 넘어갈때 가져가도록 구현하였습니다. 다시 리액트 앱을 만드는게 아니라 제가 리팩토링한 부분을 토대로 넘어가도록 구현해서 그 부분이 시간이 오래걸리고 힘들었습니다...ㅎㅎ 자세한 커밋은 여기에서부터 전환 과정을 확인하실 수 있습니다.

과제를 다시 해보면 더 잘 할 수 있었겠다 아쉬운 점이 있다면 무엇인가요?

사실 다시 해봐도 시간이 충분하지 않는 이상 결과는 비슷할 것 같습니다. 그래도 좀 더 개선이 가능하다면

1. 처음부터 명확한 요구사항 정의

처음부터 요구사항이나 스텝을 명확히 하고 알려줬더라면 베이스 코드가 덜 지저분해져서 더 빨리 끝냈을수도 있었을 것 같습니다.
중간에 방향을 여러 번 바꾸면서 불필요한 작업들이 있었거든요. 클래스를 쓸거라고 생각하지 못해서 클래스를 쓰지 말라고 얘기를 안했다거나...(자동 사냥하느라 그걸 나중에 알아버린) 지역상태가 아니라 전역 상태를 둔다거나 하는 일들이요.

2. 토큰 사용량 최적화

그리고 준일님이 멘토링때 '컨텍스트를 계속 참조하고 있으면 토큰을 많이 쓴다'는 말씀을 해주셨는데요, 커서가 토큰을 많이 먹는 것도 있지만 암튼 계속 컨텍스트를 참조하고 있는 바람에 토큰 과금을 해버려서...그 부분에 대해서도 아쉬움이 남습니다...일찍 질문 드렸더라면 토큰을 좀 더 아낄 수 있지 않았을까...?
특히 큰 파일들을 계속 컨텍스트에 포함시키고 있으면서 작은 수정을 할 때도 매번 전체 파일을 다시 분석하게 만든 것 같아요. 좀 더 세밀하게 작업 단위를 나누어서 진행했다면 토큰을 아낄 수 있었을 것 같습니다.

3. 테스트 절대 건들지 말라고하기

자동사냥을 하면서 문제점이 이 친구가 테스트를 계속 건들고, 초반엔 테스트를 run 할때도 워치 형태로 실행시켜서 제가 run을 눌러주지 않으면 넘어가지 않더라고요. 또 테스트 통과가 안되면 한 다섯번 해보다가 테스트가 안되면 테스트 자체를 고쳐버리더라고요. 그냥 테스트를 지우면 테스트 통과하는 코드가 될텐데 그럴거면 그냥 지워버리지 그러나 하는 생각도 했었습니다. 다시 처음부터 하게 된다면 초반에 테스트 자체를 절대 건들지 말고, 명령어도 꼭 --run으로 하도록 지시할 것 같습니다.

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)

[YeongseoYoon-hanghae]

최고권위자 CTO의 도움은 효과적이었나요?

그 cto가 노망이 난거같아요

[heojungseok]

또 배운다

[Yangs1s]

내맘대로 로직 바꾸고 ui바꾸는 ai 혼좀 나야할듯..

[yuhyeon99]

비교적 짧은 시간이었을텐데 AI랑 협업(원활하진 않았던 것 같지만..)끝에 제출까지..! 고생하셨습니다🙂

[chan9yu]

아니 도대체 몸이 몇개임 바쁜와중에 정리 잘해놨네... 😦

[k-sang-soo]

"본인이 리액트 개고수라는 것을 받아들이지 못하는 것 같았습니다." ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
AI와의 협업이라고 해야되나 사투라고 해야되나.. AI를 사용하면서 저와 비슷한 빡침을 느끼셨군요. 고생하셨습니다😭

[Hwirin-Kim]

영서님 이번 과제에서 시간이 많이 부족하셨다고 하셨는데 PR내용에서 많은 부분을 배워갑니다..! 저보다 짧은 시간이셨는데 내용은 훨씬 알차고 훨씬 많은것을 공부하셨네요! 한 주 고생 많으셨습니다..!

[creco-hanghae]

App 에 전체적으로 로직이 그대로 드러난 내용이 좀 있는데, 어느정도 추상화해서 표현해봐도 좋을 것 같습니다.

코멘트가 좀 추상적이서 지송..ㅋㅋ..

[creco-hanghae]

이건 어떤가요

Suggested change

	const handleRemove = () => {
	if (onRemove) {
	onRemove(id);
	}
	};
	const handleRemove = () => onRemove?.(id);

[creco-hanghae]

토글이면 약간 이런 것도 좋을 것 같아요

Suggested change

	setIsOpen(!isOpen);
	setIsOpen((isOpen) => !isOpen);

[creco-hanghae]

👍