최신 프론트엔드 상태 관리 도구 비교 🚀
안녕, 프론트엔드 개발자 친구들! 오늘은 정말 흥미진진한 주제로 찾아왔어. 바로 최신 프론트엔드 상태 관리 도구에 대해 깊이 파헤쳐볼 거야. 😎 우리가 웹 애플리케이션을 만들 때 상태 관리가 얼마나 중요한지 알지? 그래서 오늘은 현재 가장 핫한 상태 관리 도구들을 비교해보면서, 각각의 장단점과 어떤 상황에서 어떤 도구를 선택하면 좋을지 함께 알아보자구!
참고로, 이 글은 재능넷이라는 멋진 재능 공유 플랫폼의 '지식인의 숲' 메뉴에 올라갈 거야. 재능넷에서는 프로그래밍 실력을 나누는 것도 가능하니, 이 글을 읽고 상태 관리 도구에 대한 지식을 쌓은 후에 거기서 다른 개발자들과 공유해보는 것도 좋겠어!
자, 이제 본격적으로 시작해볼까? 🏁
1. 상태 관리, 왜 필요할까? 🤔
먼저 상태 관리가 왜 필요한지부터 얘기해보자. 프론트엔드 개발을 하다 보면 복잡한 데이터 흐름을 다뤄야 할 때가 많아. 사용자 정보, 애플리케이션 설정, 폼 데이터 등등... 이런 데이터들을 효율적으로 관리하지 않으면 어떻게 될까?
상태 관리 없이 개발한다면:
- 컴포넌트 간 데이터 전달이 복잡해져 🔄
- 코드 유지보수가 어려워지고 😓
- 예상치 못한 버그가 발생하기 쉬워져 🐛
- 성능 최적화가 힘들어져 🐢
이런 문제들을 해결하기 위해 등장한 게 바로 상태 관리 도구야. 이 도구들은 애플리케이션의 상태를 중앙에서 관리하고, 컴포넌트들이 필요한 데이터를 쉽게 가져다 쓸 수 있게 해줘. 마치 우리가 재능넷에서 다양한 재능을 한 곳에서 관리하고 거래하는 것처럼 말이야!
그럼 이제 본격적으로 각각의 상태 관리 도구들을 살펴볼 준비가 됐어? 가장 유명하고 많이 사용되는 도구부터 차근차근 알아보자구! 🚀
이 그림을 보면 상태 관리가 얼마나 중요한지 한눈에 알 수 있지? 복잡성은 줄이고, 성능은 높이고, 유지보수는 쉽게 하면서 버그까지 줄일 수 있다니! 정말 개발자의 꿈이 아닐 수 없어. 😍
자, 이제 각각의 상태 관리 도구들을 자세히 살펴볼 준비가 됐어? 다음 섹션에서 Redux부터 시작해서 최신 도구들까지 하나하나 파헤쳐볼 거야. 준비됐니? Let's go! 🏃♂️💨
2. Redux: 상태 관리의 대명사 👑
자, 이제 본격적으로 상태 관리 도구들을 살펴볼 거야. 첫 번째로 소개할 도구는 바로 Redux야. Redux는 거의 상태 관리의 대명사라고 할 수 있을 정도로 유명하고 널리 사용되는 라이브러리지. 🌟
Redux의 핵심 개념:
- 단일 스토어 (Single Store) 📦
- 불변성 (Immutability) 🔒
- 순수 함수 (Pure Functions) 🧼
- 단방향 데이터 흐름 (Unidirectional Data Flow) ➡️
Redux는 예측 가능한 상태 관리를 목표로 해. 모든 상태를 하나의 큰 객체(스토어)에 저장하고, 이 상태를 변경하려면 반드시 액션을 통해서만 가능하도록 만들어놨어. 이렇게 하면 어떤 장점이 있을까?
- 디버깅이 쉬워져: 모든 상태 변화를 추적할 수 있으니까 버그 찾기가 한결 수월해져.
- 상태의 일관성을 유지하기 쉬워: 한 곳에서 모든 상태를 관리하니까 데이터의 일관성을 지키기 좋아.
- 시간 여행 디버깅이 가능해: 이전 상태로 쉽게 돌아갈 수 있어서 문제 해결이 빨라져.
하지만 Redux가 장점만 있는 건 아니야. 단점도 있지:
- 보일러플레이트 코드가 많아: 액션, 리듀서, 미들웨어... 설정할 게 많아서 초보자에겐 진입 장벽이 높을 수 있어.
- 작은 프로젝트에선 과도할 수 있어: 간단한 앱에선 Redux의 복잡성이 오히려 부담이 될 수 있지.
- 비동기 작업 처리가 복잡해: 기본적으로 비동기 작업을 위한 도구가 없어서 추가 미들웨어(예: redux-thunk, redux-saga)가 필요해.
그래도 Redux의 인기는 여전해. 특히 대규모 프로젝트에서는 Redux의 강력한 기능들이 빛을 발하지. 예를 들어, 재능넷 같은 복잡한 플랫폼을 만들 때 Redux를 사용하면 사용자 정보, 거래 내역, 메시지 등 다양한 데이터를 효율적으로 관리할 수 있을 거야.
자, 이제 Redux의 기본적인 사용법을 간단히 살펴볼까?
// 액션 타입 정의
const ADD_TODO = 'ADD_TODO';
// 액션 생성자
const addTodo = (text) => ({
type: ADD_TODO,
payload: { text }
});
// 리듀서
const todoReducer = (state = [], action) => {
switch (action.type) {
case ADD_TODO:
return [...state, { text: action.payload.text, completed: false }];
default:
return state;
}
};
// 스토어 생성
import { createStore } from 'redux';
const store = createStore(todoReducer);
// 상태 변경
store.dispatch(addTodo('Redux 공부하기'));
이렇게 보면 좀 복잡해 보이지? 하지만 이런 구조 덕분에 상태 변화를 예측 가능하게 만들 수 있어. 액션을 통해서만 상태를 변경할 수 있고, 리듀서는 순수 함수이기 때문에 같은 입력에 대해 항상 같은 출력을 보장하거든.
이 그림을 보면 Redux의 데이터 흐름을 한눈에 이해할 수 있어. Action이 발생하면 Store를 거쳐 View로 전달되고, 다시 Action으로 돌아가는 순환 구조야. 이런 단방향 데이터 흐름 덕분에 애플리케이션의 상태 변화를 추적하기 쉬워지는 거지.
Redux는 React와 함께 사용될 때 더욱 강력해져. React-Redux 라이브러리를 사용하면 Redux의 상태를 React 컴포넌트의 props로 쉽게 전달할 수 있어. 이렇게 하면 컴포넌트 간의 데이터 전달이 훨씬 간단해지고, 상태 관리도 더 효율적으로 할 수 있지.
그런데 말이야, Redux가 아무리 강력하다고 해도 모든 상황에 딱 맞는 건 아니야. 작은 프로젝트에서는 오히려 부담이 될 수 있고, 러닝 커브도 있거든. 그래서 다음 섹션에서는 Redux의 대안으로 떠오르고 있는 다른 상태 관리 도구들도 살펴볼 거야. 어떤 게 있는지 궁금하지? 😉
자, 이제 Redux에 대해 어느 정도 감이 왔어? 다음으로는 MobX라는 도구를 살펴볼 건데, Redux와는 또 다른 매력이 있어. 준비됐니? 다음 섹션으로 고고! 🚀
3. MobX: 반응형 프로그래밍의 강자 🔄
자, 이번에 소개할 상태 관리 도구는 바로 MobX야. MobX는 Redux와는 좀 다른 접근 방식을 가지고 있어. 반응형 프로그래밍 패러다임을 기반으로 하고 있지. 뭔가 어려워 보이지? 걱정 마, 쉽게 설명해줄게! 😉
MobX의 핵심 개념:
- Observable State (관찰 가능한 상태) 👀
- Computed Values (계산된 값) 🧮
- Reactions (반응) 🎭
- Actions (액션) 🎬
MobX의 가장 큰 특징은 상태 변화를 자동으로 추적하고 반영한다는 거야. Redux처럼 일일이 액션을 디스패치하고 리듀서를 통해 상태를 업데이트할 필요 없이, 그냥 상태를 직접 변경하면 돼. 마치 마법처럼 관련된 모든 곳이 자동으로 업데이트되는 거지! 🪄
예를 들어볼까? 재능넷에서 사용자의 프로필 정보를 관리한다고 생각해보자. MobX를 사용하면 이렇게 할 수 있어:
import { makeObservable, observable, action, computed } from 'mobx';
class UserStore {
name = "김재능";
age = 25;
skills = ["웹개발", "디자인"];
constructor() {
makeObservable(this, {
name: observable,
age: observable,
skills: observable,
updateProfile: action,
skillCount: computed
});
}
updateProfile(name, age) {
this.name = name;
this.age = age;
}
get skillCount() {
return this.skills.length;
}
}
const userStore = new UserStore();
이렇게 하면 userStore.name
이나 userStore.age
를 변경할 때마다 자동으로 관련된 UI가 업데이트돼. 게다가 skillCount
같은 계산된 값도 쉽게 만들 수 있지. 정말 편리하지 않아? 😎
MobX의 장점을 좀 더 자세히 살펴볼까?
- 보일러플레이트 코드가 적어: Redux에 비해 설정해야 할 것들이 훨씬 적어. 그래서 초보자들도 쉽게 시작할 수 있어.
- 유연해: 클래스, 객체, 배열 등 다양한 형태의 상태를 쉽게 관리할 수 있어.
- 성능이 좋아: 필요한 부분만 정확하게 업데이트하기 때문에 불필요한 렌더링을 줄일 수 있어.
- 디버깅이 쉬워: MobX DevTools를 사용하면 상태 변화를 실시간으로 추적할 수 있어.
물론 MobX에도 단점은 있어:
- 자유도가 높아 구조화가 어려울 수 있어: Redux의 엄격한 구조에 비해 자유도가 높아서, 큰 프로젝트에서는 일관성 있는 코드를 유지하기 어려울 수 있어.
- 러닝 커브: 반응형 프로그래밍 개념에 익숙하지 않으면 처음에는 어렵게 느껴질 수 있어.
- 시간 여행 디버깅이 어려워: Redux처럼 모든 상태 변화를 추적하는 게 아니라서, 이전 상태로 쉽게 돌아가기 어려워.
이 그림을 보면 MobX의 데이터 흐름을 이해하기 쉬울 거야. Observable State를 중심으로 Action, Computed, Reaction, View가 서로 상호작용하는 걸 볼 수 있지. 이런 구조 덕분에 상태 변화에 따른 반응이 자동으로 일어나는 거야.
MobX는 특히 중소 규모의 프로젝트에서 빛을 발해. 복잡한 설정 없이도 강력한 상태 관리를 할 수 있거든. 예를 들어, 재능넷의 채팅 기능을 구현한다고 생각해봐. 실시간으로 메시지가 오고 가는 상황에서 MobX의 반응형 특성을 활용하면 UI를 매우 효율적으로 업데이트할 수 있을 거야.
MobX를 React와 함께 사용하면 더욱 강력해져. mobx-react 라이브러리를 사용하면 MobX의 상태를 React 컴포넌트에 쉽게 연결할 수 있어. 이렇게 하면 상태 변화에 따라 컴포넌트가 자동으로 리렌더링되니까, 개발자가 직접 신경 쓸 일이 훨씬 줄어들지.
자, 이제 MobX에 대해서도 어느 정도 감이 왔지? Redux와는 또 다른 매력이 있지? 어떤 걸 선택할지는 프로젝트의 특성과 팀의 선호도에 따라 달라질 수 있어. 큰 규모의 프로젝트에서는 Redux의 엄격한 구조가 도움이 될 수 있고, 중소 규모의 프로젝트에서는 MobX의 유연성이 빛을 발할 수 있지.
다음 섹션에서는 또 다른 인기 있는 상태 관리 도구인 Recoil에 대해 알아볼 거야. React 팀에서 만든 이 도구는 어떤 특징이 있을지 궁금하지? 함께 알아보자구! 🚀
4. Recoil: React를 위한 새로운 물결 🌊
자, 이번에 소개할 상태 관리 도구는 바로 Recoil이야. Recoil은 Facebook에서 만든 React 전용 상태 관리 라이브러리로, 2020년에 공개됐어. React의 철학을 그대로 따르면서도, 더 효율적인 상태 관리를 할 수 있도록 설계됐지. 😎
Recoil의 핵심 개념:
- Atom (원자) ⚛️
- Selector (선택자) 🔍
- React Hooks 기반 🎣
- 비동기 작업 지원 🔄
Recoil의 가장 큰 특징은 React의 기본 원리를 그대로 따른다는 거야. 마치 React의 내장 기능처럼 자연스럽게 사용할 수 있어서, React 개발자들이 쉽게 적응할 수 있지. 게다가 비동기 데이터 처리도 정말 간단해! 🚀
Recoil의 기본 사용법을 한번 볼까? 재능넷의 사용자 프로필을 관리하는 예제로 설명해볼게:
import { atom, selector, useRecoilState, useRecoilValue } from 'recoil';
// Atom: 상태의 단위
const userNameState = atom({
key: 'userNameState',
default: '김재능',
});
const userAgeState = atom({
key: 'userAgeState',
default: 25,
});
// Selector: 파생된 상태
const userInfoState = selector({
key: 'userInfoState',
get: ({get}) => {
const name = get(userNameState);
const age = get(userAgeState);
return `${name}님은 ${age}세입니다.`;
},
});
// 컴포넌트에서 사용
function UserProfile() {
const [name, setName] = useRecoilState(userNameState);
const [age, setAge] = useRecoilState(userAgeState);
const userInfo = useRecoilValue(userInfoState);
return (
<div>
<input value="{name}" onchange="{(e)"> setName(e.target.value)} />
<input type="number" value="{age}" onchange="{(e)"> setAge(Number(e.target.value))} />
<p>{userInfo}</p>
</div>
);
}
어때? 정말 React스럽지 않아? 😉 Atom은 상태의 가장 작은 단위고, Selector는 이 Atom들을 조합해서 새로운 상태를 만들어내는 거야. 그리고 이 모든 걸 React Hooks처럼 사용할 수 있어!
Recoil의 장점을 좀 더 자세히 살펴볼까?
- 학습 곡선이 낮아: React를 알고 있다면, Recoil을 배우는 건 정말 쉬워.
- 비동기 처리가 간단해: Selector를 사용하면 비동기 데이터를 쉽게 다룰 수 있어.
- 코드 분할이 쉬워: Atom 단위로 상태를 관리하기 때문에, 코드를 작은 단위로 나누기 좋아.
- 성능 최적화: 필요한 컴포넌트만 리렌더링되도록 자동으로 최적화해줘.
물론 Recoil에도 단점은 있어:
- 아직 새로운 기술이야: 다른 라이브러리들에 비해 생태계가 작고, 안정성이 덜 검증됐어.
- 복잡한 상태 관리에는 부족할 수 있어: 대규모 애플리케이션의 복잡한 상태 관리에는 Redux가 더 적합할 수 있어.
- 서버 사이드 렌더링 지원이 아직 완벽하지 않아: 이 부분은 계속 개선되고 있지만, 아직 완벽하진 않아.
이 그림을 보면 Recoil의 데이터 흐름을 이해하기 쉬울 거야. Atom과 Selector를 중심으로 Component와 Async Data가 서로 상호작용하는 걸 볼 수 있지. 이런 구조 덕분에 상태 관리가 직관적이고 효율적으로 이뤄지는 거야.
Recoil은 특히 React 기반의 중소 규모 프로젝트에서 빛을 발해. 복잡한 설정 없이도 강력한 상태 관리를 할 수 있고, 비동기 처리도 쉽게 할 수 있거든. 예를 들어, 재능넷의 실시간 알림 기능을 구현한다고 생각해봐. Recoil의 Selector를 사용하면 서버에서 실시간으로 데이터를 받아와 UI에 반영하는 걸 아주 간단하게 구현할 수 있을 거야.
Recoil의 또 다른 장점은 시간 여행 디버깅이 가능하다는 거야. Redux DevTools처럼 상태 변화를 추적하고 이전 상태로 돌아갈 수 있어. 이건 개발 과정에서 정말 유용한 기능이지!
자, 이제 Recoil에 대해서도 어느 정도 감이 왔지? Redux, MobX와는 또 다른 매력이 있지? Recoil은 특히 React와의 호환성이 뛰어나고, 사용법이 직관적이라는 게 큰 장점이야. 하지만 아직 새로운 기술이라 안정성 면에서는 조금 불안할 수 있어. 프로젝트의 성격과 팀의 기술 스택에 따라 선택을 고민해봐야 할 거야.
여기까지 Redux, MobX, Recoil이라는 세 가지 주요 상태 관리 도구에 대해 알아봤어. 각각의 도구들이 어떤 특징을 가지고 있는지 이해됐니? 다음 섹션에서는 이 도구들을 비교해보고, 어떤 상황에서 어떤 도구를 선택하면 좋을지 정리해볼 거야. 준비됐니? 가보자고! 🚀
5. 상태 관리 도구 비교 및 선택 가이드 🧭
자, 이제 우리가 살펴본 세 가지 상태 관리 도구 - Redux, MobX, Recoil을 비교해볼 시간이야. 각각의 도구들이 어떤 상황에서 빛을 발하는지, 그리고 어떤 프로젝트에 적합한지 정리해볼 거야. 준비됐니? 가보자고! 🚀
특성 | Redux | MobX | Recoil |
---|---|---|---|
학습 곡선 | 높음 | 중간 | 낮음 |
보일러플레이트 코드 | 많음 | 적음 | 매우 적음 |
유연성 | 중간 | 높음 | 높음 |
성능 | 좋음 | 매우 좋음 | 좋음 |
대규모 앱 적합성 | 매우 높음 | 높음 | 중간 |
React 친화성 | 좋음 | 좋음 | 매우 좋음 |
비동기 처리 | 미들웨어 필요 | 내장 | 내장 |
자, 이 표를 보면 각 도구의 특징이 한눈에 들어오지? 이제 어떤 상황에서 어떤 도구를 선택하면 좋을지 알아보자.
Redux를 선택해야 할 때:
- 대규모 프로젝트를 진행할 때
- 복잡한 상태 로직을 다뤄야 할 때
- 엄격한 아키텍처가 필요할 때
- 시간 여행 디버깅이 필요할 때
MobX를 선택해야 할 때:
- 빠른 개발이 필요할 때
- 객체지향적인 접근이 필요할 때
- 성능 최적화가 중요할 때
- 유연한 상태 관리가 필요할 때
Recoil을 선택해야 할 때:
- React 프로젝트를 진행할 때
- 간단하고 직관적인 API가 필요할 때
- 비동기 데이터 처리가 많을 때
- 코드 분할이 중요할 때
예를 들어, 재능넷 같은 복잡한 플랫폼을 개발한다고 생각해보자. 사용자 정보, 거래 내역, 메시지, 알림 등 다양한 상태를 관리해야 하고, 여러 개발자가 협업해야 하는 상황이라면 Redux가 좋은 선택이 될 거야. Redux의 엄격한 구조가 큰 프로젝트의 일관성을 유지하는 데 도움이 될 테니까.
반면에 재능넷의 모바일 앱을 빠르게 개발해야 한다면? 이때는 MobX나 Recoil이 더 적합할 수 있어. 특히 React Native를 사용한다면 Recoil의 React 친화적인 API가 개발 속도를 높여줄 거야.
그리고 재능넷의 실시간 채팅 기능을 구현한다고 해보자. 비동기 데이터 처리가 많이 필요한 이런 기능에는 Recoil이나 MobX가 적합할 거야. 둘 다 비동기 처리를 쉽게 할 수 있으니까.
이 그림을 보면 프로젝트의 규모와 복잡도에 따라 어떤 상태 관리 도구를 선택하면 좋을지 한눈에 알 수 있지? 물론 이건 절대적인 기준은 아니야. 팀의 경험, 프로젝트의 특성, 미래의 확장성 등을 모두 고려해서 선택해야 해.
결국, 완벽한 상태 관리 도구는 없어. 각각의 도구가 장단점을 가지고 있고, 프로젝트의 요구사항에 따라 최적의 선택이 달라질 수 있지. 중요한 건 프로젝트의 특성을 잘 이해하고, 팀의 역량을 고려해서 가장 적합한 도구를 선택하는 거야.
그리고 잊지 말아야 할 점! 상태 관리 도구는 계속 발전하고 있어. 새로운 버전이 나오면 성능이 개선되고 새로운 기능이 추가될 수 있지. 그러니 항상 최신 트렌드를 주시하고, 필요하다면 과감하게 새로운 도구를 도입해보는 것도 좋아.
자, 이제 상태 관리 도구에 대해 꽤 깊이 있게 알아봤어. 어때? 이제 프로젝트에 어떤 상태 관리 도구를 사용할지 결정할 수 있겠어? 😊 기억해, 가장 중요한 건 네 프로젝트에 가장 잘 맞는 도구를 선택하는 거야. 화이팅! 🚀
결론: 최적의 상태 관리 도구 선택하기 🎯
자, 이제 우리의 여정이 거의 끝나가고 있어. 지금까지 Redux, MobX, Recoil이라는 세 가지 주요 상태 관리 도구에 대해 깊이 있게 알아봤지. 각각의 도구가 가진 특징, 장단점, 그리고 어떤 상황에서 어떤 도구를 선택하면 좋을지까지 살펴봤어. 🕵️♂️
여기서 가장 중요한 점은 뭘까? 바로 상황에 따라 최적의 도구가 다르다는 거야. 완벽한 '만능' 도구는 없어. 프로젝트의 규모, 복잡도, 팀의 경험, 미래의 확장성 등을 모두 고려해서 선택해야 해.
상태 관리 도구 선택 시 고려해야 할 점:
- 프로젝트의 규모와 복잡도
- 팀의 학습 곡선과 기술 스택
- 성능 요구사항
- 유지보수의 용이성
- 커뮤니티 지원과 생태계
- 미래의 확장 가능성
예를 들어, 재능넷 같은 복잡한 플랫폼을 개발한다면 Redux의 엄격한 구조와 강력한 개발자 도구가 큰 도움이 될 거야. 하지만 작은 규모의 프로젝트나 빠른 개발이 필요한 상황이라면 MobX나 Recoil이 더 적합할 수 있지.
그리고 잊지 말아야 할 점! 상태 관리 도구는 계속 발전하고 있어. Redux도 Redux Toolkit이라는 새로운 도구로 보일러플레이트 코드를 줄이고 있고, MobX와 Recoil도 계속해서 새로운 기능을 추가하고 있지. 그러니 항상 최신 트렌드를 주시하는 것도 중요해.
마지막으로, 상태 관리 도구를 선택할 때 가장 중요한 건 뭘까? 바로 네 프로젝트와 팀에 가장 잘 맞는 도구를 선택하는 거야. 남들이 쓴다고, 유행한다고 무작정 따라가는 건 위험해. 네 상황을 잘 파악하고, 필요하다면 여러 도구를 직접 사용해보면서 최적의 선택을 하는 게 중요해.
이 그림은 상태 관리 도구를 선택하는 프로세스를 보여줘. 요구사항을 분석하고, 도구들을 비교하고, 실제로 테스트해보고, 최종 선택을 하는 과정이지. 이런 과정을 거치면 네 프로젝트에 가장 적합한 도구를 선택할 수 있을 거야.
자, 이제 정말 마무리할 시간이야. 이 글을 통해 상태 관리 도구에 대한 이해도가 높아졌길 바라. 그리고 재능넷에서 이 지식을 다른 개발자들과 공유하면 어떨까? 네가 배운 걸 나누면서 더 깊이 있는 이해를 할 수 있을 거야. 함께 성장하는 즐거움을 느껴보라구! 😉
마지막으로, 상태 관리는 프론트엔드 개발에서 정말 중요한 부분이야. 하지만 도구 자체가 목적이 되어선 안 돼. 도구는 우리가 더 나은 사용자 경험을 제공하기 위한 수단일 뿐이야. 항상 사용자의 관점에서 생각하고 , 최선의 선택을 하길 바라. 화이팅! 🚀
앞으로도 프론트엔드 개발 분야는 계속 발전할 거야. 새로운 도구와 기술이 계속 나올 테고, 우리는 그에 맞춰 계속 학습해 나가야 해. 하지만 걱정하지 마. 이렇게 기본을 탄탄히 다져놓으면, 어떤 새로운 도구가 나와도 금방 적응할 수 있을 거야. 계속해서 호기심을 가지고 새로운 것을 배우는 자세를 잃지 않길 바라!
그럼 이제 정말 마무리할게. 이 글이 네 프로젝트에 최적의 상태 관리 도구를 선택하는 데 도움이 되길 바라. 그리고 재능넷에서 네 경험과 지식을 다른 개발자들과 나누는 것도 잊지 마! 함께 성장하는 개발자 커뮤니티를 만들어가는 거야. 멋진 프로젝트 만들고, 훌륭한 개발자로 성장하길 응원할게. 화이팅! 👨💻👩💻