
## 요약

짧게 요약한 내용입니다.

<img width="700" alt='회원가입 as-is' src='/images/blog/2305/ex-asis.png' />

이랬던 코드를 

<img width="700" alt='회원가입 to-be' src='/images/blog/2305/ex-tobe.png' />

이렇게 바꾸었습니다.

## 도입 계기

```typescript
    const [status, setStatus] = useState<{
        idMsg: string,
        idOk: boolean,
        isIdChecked: boolean,
        passwordMsg: string,
        passwordOk: boolean,
        confirmPasswordMsg: string,
        confirmPasswordOk: boolean,
      }>({
        idMsg: '',
        idOk: false,
        isIdChecked: false,
        passwordMsg: '',
        passwordOk: false,
        confirmPasswordMsg: '',
        confirmPasswordOk: false,
    });
```

원래는 비밀번호, 비밀번호 재입력 필드가 validate한지 여부를 담는 불린값(`passwordOk`)과 
그 상태에 따른 에러 또는 성공 메시지(`passwordMsg`)을 상태로 가지고 있었습니다.
원래 상태를 관리할 때 상태(`password`) 외에 그 상태에 따라 결정되는 값(`passwordMsg`, `passwordOk`)은 상태에 담지 않는게 맞는데요.

```js
    if (!values.password || !PW_REGEX.test(values.password)) {
      _errors.passwordOk = false;
      _errors.passwordMsg = MSG.RULE_PW;
    }

    if (!values.confirmPassword || values.password !== values.confirmPassword) {
      _errors.confirmPasswordOk = false;
      _errors.confirmPasswordMsg = MSG.WRONG_PW;
    }
    setStatus(_errors);
```

기존 코드를 저렇게 작성했던 이유는 필드 간의 의존성 때문이었습니다.
비밀번호가 바뀔 때마다 정규 표현식에 맞는지 확인하고 바로바로 에러메시지를 표시해줘야 했고, 비밀번호 확인 필드가 그 비밀번호와 일치하는지 다시 밸리데이션해야했습니다. 
이런 값들을 JSX 내부에서 그때그때 밸리데이션하게 하기보단 state로 분리해서 `onChange` 내에서 검사 후 `setStatus`를 한번에 하도록 했었어요.  

이 방법이 베스트가 아니라는 걸 알면서도 구현했던 거지만
밸리데이션 내용이 너무 길어졌고, 코드가 복잡해져 어떤 코드를 수정할 때 다른 부분에도 영향이 갈까봐 찝찝해지기 시작했습니다.

그래서 <a href='https://react-hook-form.com' target='blank'> **react-hook-form**</a>을 적용해보았고, 아주 만족 중입니다!

## react-hook-form이란?

react-hook-form, 줄여서 rhf는 폼을 관리하고 활용할 수 있는 커스텀 훅들을 제공해줍니다. 사용가능한 훅들은 이런 것들이 있습니다.

- `useForm`: 폼을 간단하게 관리할 수 있는 커스텀 훅.
- `useController`: MUI처럼 외부에서 제어하는 컴포넌트들의 input을 제어하고 싶을 때 사용합니다. 컴포넌트별로 `useController`를 만들고, `useForm`과 따로 씁니다.
- `useFormContext`: `formContext`에 접근할 수 있고 `useForm`의 메서드를 사용할 수 있습니다. 폼 컨텍스트를 prop으로 넘기기 불편한, 깊게 nested 된 구조에 쓰면 좋습니다.
- `useFormState`: 각 폼 상태를 구독하고, 커스텀 훅 레벨에서 리렌더링을 분리하고 싶을때 사용합니다.
- `useFieldArray`: 필드들을 배열로 관리해 다이나믹하게 필드를 추가하거나 삭제, 순서를 바꾸고 싶을 때 사용합니다.

그 중에서도 저는 가장 기본적인 <a href='https://react-hook-form.com/docs/useform'>`useForm`</a>을 사용하였습니다. 예시코드를 보겠습니다.

## useForm 연동

```jsx
    import { SubmitHandler, useForm } from 'react-hook-form';
    
    const 회원가입 = () => {
        const {
            register,
            handleSubmit,
            formState: { errors },
        } = useForm<FormValues>({
            mode: 'onChange',       // validation을 언제 할지
            defaultValues: {        // input들의 기본값 설정
                userId: '',
                password: '',
                confirmPassword: '',
            },
        });
        return (
            // 생략
        )
    }
```

가장 먼저, `useForm`을 세팅했습니다. `mode` 속성으로 `onChange`마다 validation 하도록 변경해주었습니다.
기본 설정은 `onSubmit`으로, 폼이 submit될 때에만 밸리데이션 처리를 합니다. 
위 폼에선 회원가입에 필요한 `userId`, `password`, `confirmPassword` 필드를 관리합니다.
`useState`와 비슷한 구조로 `defaultValues`를 지정해줍니다.

```jsx
    // 비밀번호 인풋
     <PasswordInput
         // name='password'
         // value={values.password}
         // onChange={handleChange}
        {...register('password', {
            deps: ['confirmPassword'],   // 의존성 연결
            pattern: {                   // 정규표현식 패턴
                value: PW_REGEX,
                message: '비밀번호는 숫자와 영어, 특수문자를 포함해주세요.',
            },
        })}
    />
```

그 다음은 `register` 메서드를 사용해 인풋과 연동합니다. 이 코드의 비즈니스 로직 중 하나가
'*비밀번호 입력값이 변경될때마다 비밀번호 확인 필드도 다시 확인해 바로바로 에러메시지를 띄운다.*'입니다.

그렇기에 `register`의 두번째 파라미터인 `options` 객체의 `deps` 배열에 `confirmPassword`를 넣어줍니다.

또 비밀번호를 위한 정규표현식과 그 정규표현식에 맞지 않을 때 뜰 에러메시지도 지정해줍니다.
기존에 `prop`으로 넘겨주었던 `name`, `value`, `onChange`를 넘겨줄 필요가 없게 되었습니다!

```jsx
// 비밀번호 확인 실패 에러메시지
<p>{errors?.confirmPassword}</p>
```

그리고 그 에러메시지는 `formState.errors.인풋name` 으로 사용하면 됩니다.

## 커스텀 밸리데이션

```jsx
    // 비밀번호 확인 인풋
    <PasswordInput
        // name='confirmPassword'
        // value={values.confirmPassword}
        // onChange={handleChange}
        {...register('confirmPassword', {
            validate: {
                sameAsPw: (v, formValues) => {
                    return formValues.password === v || '비밀번호와 비밀번호 확인 입력값이 일치하지 않습니다';
                },
                // 다른 커스텀 밸리데이션 규칙도 추가 가능!
            },
        })}
    />
```

정규표현식 말고도 커스텀 validation 규칙을 추가할 수 있습니다. 
위 코드에선 `sameAsPw`라는 이름의 validation 규칙이 있고, 폼의 `password`와 값 `v`가 같은지 확인합니다. 같지 않을 경우'*비밀번호와 비밀번호 확인 입력값이 일치하지 않습니다*'라는 에러 메시지가 표시됩니다. 

참고로 저는 이 에러메시지들을 상수화해놓고 따로 구현하였으나, 예시 코드의 가독성을 위해 직접 넣어주었습니다.

## 온클릭 submit 연동

마지막으로 아이디 중복확인 버튼을 클릭했을 때, 서버로 아이디 중복확인 요청을 날려 그 응답을 받아와야 합니다.
하지만 이런 경우 아이디 중복확인 버튼에 `type=submit`을 넣을 수는 없습니다. 폼의 최종 submit은 회원가입하기 버튼을 눌렀을 때 이뤄져야 하기 때문입니다.

```jsx
    // 아이디 중복확인 버튼
    <CheckIdBtn 
        onClick={handleSubmit(checkId)} // handleSubmit으로 연동
    >
        중복확인
    </CheckIdBtn>
```

```typescript
    const checkId: SubmitHandler<FormValues> = (data) => {
        console.log('입력한 id:' + data.userId) 
    }
```

이럴 때엔 `useForm`의 `handleSubmit` 메서드에 중복확인을 하는 함수 `checkId`를 인자로 넘겨주면 됩니다.
이렇게 하면 `checkId`는 `MouseEvent`가 아니라 react-hook-form에서 정의한 타입 `SubmitHandler`을 리턴하며 해당 폼에서 관리하는 `data`를 받아 사용할 수 있습니다.

이런 식으로 react-hook-form을 사용해 리액트에서 폼과 인풋을 간단하게 구현하고 관리할 수 있습니다.
직접 리액트 `state`로 폼 인풋의 `value`를 계속 추적하고 `onChange` 핸들러를 전해줄 필요가 없게 되었습니다. 

이렇게 react-hook-form을 직접 써보니 너무 좋아서 회사 프로젝트에도 도입을 했는데요! 
그 프로젝트에선 MUI의 `TextField` 컴포넌트를 공통화해 사용하고 있었는데요. 그 컴포넌트와 react-hook-form의 `FormContextProvider`, `useController`를 함께 사용하였습니다.
인풋을 동적으로 추가해야하는 부분에서는 `useFieldArray`를 유용하게 사용했구요!

그럼 이만 다들 react-hook-form을 사용해 즐거운 코딩하시길 바라겠습니다!
😁


리액트로 폼 구현할 때 onChange, value, 상태의 props drilling을 줄여봅시다.

react-hook-form으로 리액트 폼 개선하기


회사 프로젝트에서 리액트 쿼리(tanstack query)를 사용하고 있습니다. 
useMutation을 custom hook으로 감싸면서 좀 더 활용할 수 있는 방법을 찾아보다가 QueryClient를 사용해 
쿼리 캐시를 활용할 수 있는 방법을 생각해보았습니다.

## QueryClient

- Tanstack Query에서 제공하는 클라이언트 캐시에 접근할 수 있는 객체
- Query cache, mutation cache, logger 등과 연결되어있다.

### 용어

- staleTime: 데이터가 `fresh` 상태로 유지되는 시간. `fresh` 상태일 땐 쿼리 인스턴스가 새로 마운트되어도 fetch가 일어나지 않는다.
- cacheTime: `inactive` 상태인 캐시 데이터가 메모리에 남아있는 시간. 
쿼리 인스턴스가 unmount 되면 데이터는 `inactive` 상태로 변경되며, 캐시는 `cacheTime`만큼 유지된다.
`cacheTime`이 지나기 전에 쿼리 인스턴스가 다시 마운트 되면, 데이터를 fetch하는 동안 캐시 데이터를 보여준다.
- fetching, fresh, stale, inactive, delete

![Tanstack Query's lifecycle](https://github.com/pullingoff/nexthome/assets/50111853/8467b853-52c4-420a-9ee7-6a47d66fff04)

### 주요 메서드
- `fetchQuery({ queryKey, queryFn })`: fetch하고 쿼리를 캐시한다. (비동기)
쿼리가 존재하는데 데이터가 유효하지 않거나 staleTime을 넘어섰을 경우 캐시 데이터를 반환한다. 그렇지 않은 경우엔 최신 데이터를 fetch한다.
- `prefetchQuery({ queryKey, queryFn })`: 데이터가 필요하기 전에 쿼리를 미리 fetch한다.
`prefetchInfiniteQuery`도 있다.
- `getQueryData(queryKey)`: 해당 쿼리의, 캐시되어있던 데이터를 가져온다. (동기)
- `setQueryData(queryKey, updater)`: 동기적으로 캐시를 업데이트한다. 
cacheTime(기본값 5분) 이내에 쿼리를 사용하지 않을 경우 가비지컬렉트된다.
- `invalidateQueries({queryKey...})`: 캐시된 쿼리를 무효화하고 다시 fetch한다.

## 기본 refetch 조건
query가 refetch 되는 기본 조건은 아래와 같습니다. 공통화해두면 좋을 것 같습니다.

- `refetchOnMount`: 쿼리 인스턴스가 마운트될 때
- `refetchOnReconnect`: 네트워크가 다시 연결될 때
- `refetchOnWindowFocus`: 윈도우 창이 다시 포커스될 때 (개발자도구 클릭 후 돌아오는 경우 등)
- `refetchInterval`: 쿼리의 refetch Interval이 지나 refetch가 필요할 때

## 방법1: 리소스별 queryKey

![tanstack query keys](https://github.com/pullingoff/nexthome/assets/50111853/d22f276c-7431-4029-a9b7-cf9814314aaf)

쿼리 키는 캐시의 키다. 쿼리 키를 REST API처럼 리소스에 따라 나누면 한 캐시를 대상으로 CRUD 작업을 할 수 있다.

## 방법2: keepPreviousData

결과: 기존 데이터에서 새 데이터로 부드럽게 전환된다.

```js
type Filter = '전체' | '쿠팡' | '아임웹';

const useProductsQuery = (filter: Filter) =>
  useQuery({ 
    queryKey: ['products', filter], 
    queryFn: () => fetchProducts(filter) 
  });
```

위 코드는 filter 값에 따라 상품 목록을 불러오는 코드다. queryKey는 useEffect의 의존성 배열과 같은 존재다. 
그렇기에 filter 값이 바뀔 때마다 query Key가 변하고, query key가 변했으므로 쿼리가 refetch된다.

또 query key는 캐시의 키이므로, cache entry가 새로 생기고, 처음으로 필터를 전환할 경우 (로딩 스피너가 표시되는) 하드로딩 상태가 된다. 
이때 keepPreviousData를 true로 설정하거나 initialData를 설정해두면 새 쿼리가 새 데이터를 요청하는 동안 가장 최근의 데이터를 활용할 수 있다.

```js
export const useProductsQuery = (filter: Filter) =>
  useQuery({
    queryKey: ['products', filter],
    queryFn: () => fetchProducts(filter),
    initialData: () => {
      // '전체' 상품의 데이터를 활용해 우선적인 데이터를 보여줄 수 있다.
      const allProducts = queryClient.getQueryData<Products>(['products', '전체'])
      const filteredData =
        allProducts?.filter((product) => product.type === filter) ?? []
        
      return filteredData.length > 0 ? filteredData : undefined
    },
  })
```

이후 새 데이터가 도착하면 기존의 데이터가 부드럽게 새 데이터로 스왑된다. 
비슷하게 Tab에서도 각 탭의 query key를 다르게 해 사용할 수 있다.
다만 initialData를 쓸 경우 각 페이지에서 개발자가 추가해줘야하는 코드가 늘어날 수 있고, 
만약 기존 데이터 중 filter에 걸리는 데이터가 없다면 보여줄 데이터가 없을 수도 있다. 이런 경우엔 전체 데이터를 보여줘야할 것이다.

## 방법3: Smart refetching

결과: mutation이 성공할 때마다 매번 refetch 되는 것이 아니라, 데이터가 필요할 때 fresh하게 불러오도록 한다.

상품 목록에서 한 가지 상품을 골라 삭제를 할 수 있다. 
상품 삭제 모달에서 confirm을 하면 상품 목록이 리렌더되며 해당 상품이 제외된 상품 목록이 표시되어야한다. 

이렇게 CRUD 후 바로 적용된 데이터를 보여줘야 할 때, mutation success callback에서 관련된 쿼리의 캐시를 무효화시킨다. 
데이터를 invalid시킴으로써 React query가 해당 쿼리를 refetch를 하도록 만드는 것이다. 

```js
 // 상품을 삭제한다.
  const deleteProduct = (productId) => {
    return axios.delete('/product', productId);
  };
  
  const { mutate: deleteProduct } = useMutation(deleteProduct, {
    onSuccess: () => {
      // 방법1. queryKey가 'products'로 시작하는 모든 쿼리 무효화
      queryClient.invalidateQueries('products');
      
      // 방법2. productId에 따라 해당 쿼리 무효화 
      queryClient.invalidateQueries({ queryKey: ['products', productId] }
    }
  });
```

`onSuccess` 안에서 `invalidateQueries`로 쿼리를 무효화시켜 refetch하도록 하는 것과 `refetch()`를 직접 호출하는 것에는 차이가 있다. 
직접 refetch를 할 경우 요청을 새로 보내서 데이터를 새로 가져오게 된다. 
해당 쿼리를 보고 있는 observer가 없어도 무조건 다시 가져온다. 
반면 invalidateQueries를 사용하여 데이터를 무효화하는 경우 데이터는 `stale` 상태로 변했다가
이후 query의 refetch 조건에 부합할 때에 fetch하게 된다. (useQuery 나 관련 훅을 통해 쿼리가 렌더링되고 있다면 백그라운드에서도 refetch한다.)

refetch를 하면 query key(예를 들면 무한스크롤 컴포넌트의 page)를 기준으로 inactive한 모든 페이지의 데이터를 불러오지만 
쿼리 무효화를 하면 우선 query를 `stale`하게만 만들기 때문에 `active`한 페이지의 데이터만 fetch한다. 이러한 이유로
쿼리 무효화를 하는 게 미세하게 나은 성능을 가질 수 있다.

`setQueryData`를 통해 optimistic update를 하는 방법도 있지만,
변화를 우선적으로 적용한 뒤 성공 여부에 따라 값을 다시 바꿔야하는 optimistic update보다는 무효화를 하는게 
각 쿼리에서 개발자가 추가해야할 코드의 양은 적어지는 것 같다.

## 참고 

- [Practical React Query](https://tkdodo.eu/blog/practical-react-query#treat-the-query-key-like-a-dependency-array)
- [React Query로 서버 상태 관리하기](https://blog.rhostem.com/posts/2021-02-01T00:00:00.000Z)
- [refetch vs invalidating query](https://github.com/TanStack/query/discussions/2468)


Tanstack query useQueryClient로 할 수 있는 일들

Tanstack Query 캐시 활용하기 (리액트 쿼리 QueryClient)


## 요즘의 아쉬움

문득 든 생각인데 최근 3개월은 기술적으로 나아진 게 없는 거 같다.
정산 어드민 리뉴얼 프로젝트를 열심히 했는데, 하루 8시간 주 5일 회사에서 뇌 리소스를 다 써버리니까 주말이나 퇴근 후엔 거의 개발을 못했다.
사이드프로젝트(리욜드) 개발을 하긴 했지만 짜는 코드의 질은 별로 개선이 없었던 느낌이랄까?

지난 12월 말 - 1월 초에 코로나 휴가를 가지면서 유인동 강사님의 인프런 함수형 강의를 들었다.
잘 써먹어보리라 다짐했었는데 아직 실제 프로젝트에서는 못 써봤고, 주중에 시간을 따로 내서 하는 동료들과의 스터디와
개인 사이드 프로젝트만 간간히 하고 있다.

작년 하반기에는 레거시 홈페이지의 자동화 테스트를 도입했다. Cypress, Mocha 문법, POM 패턴, 테스트 코드 짜는 법 등등
공부하면서 실무에서 사용해볼 수 있었는데 최근 3개월에는 프로젝트 완성을 최우선으로 하느라
문서를 그때그때 발췌독하면서 작업을 해서 이런 아쉬움이 남았다.(이런 작업 방법이 나쁘다고 생각하지는 않는다.)

어쨌든 회사 내 성과 평가는 잘 받았지만 뭔가 채워지지 않는 것이 있었다고나 할까.
진짜 일을 잘 하는 사람들은 회사를 위해 일하지 않고 나를 위해 일한다던데
최근 몇개월간은 내 개인적 성장보다는 회사를 위해서 일한 것 같다.

물론 그 과정에서 내가 기존에 사용해온 기술들을 더 잘 이해할 수 있었고, 더 많은 문서와 지식을 얻긴 했지만
지금보다 더 라이브러리를 잘 활용하고, 코드의 질도 높이고 싶다. 기술 부채를 청산할 때가 온 거다.
그래서 이런 고민을 한 팀 동료에게 이야기했는데 같이 정기적으로 회고해보자고 하셔서 매주 금요일마다 해보려고 한다.

또 블로그 글의 질을 높이고 싶다. 그냥 기본적인 개념을 정리해놓기보단 정말로 내가 개발하면서 마주쳤던 문제와 내가 찾은 해결법, 시도들을 
기록하고 싶은데 그런 글을 쓰려면 품이 많이 든다. 틈틈이 내가 썼던 글들을 보면서 보완하거나, 글 목록에서 빼두려고 한다. 
이미 같은 고민을 먼저 했던 사람이 더 나은 해결책을 적어두진 않았을까 싶어서 쓰는게 주저되기도 한다.    
쉽지 않군

## 회고 양식

**[new]**
- 이번주 새로 배운 것이 있었나요?
- 있었다면, 다음번에 또 활용할 수 있을까요? 어떻게 활용하면 좋을까요?

**[finding]**
- 이번주 기술적으로 가장 어려웠던 건 뭐였나요? 어떤 이슈가 있었나요?
- 해결했다면 어떻게 해결했나요?

**[future]**
- 앞으로 시도해보고 싶은 게 있나요?

## 3월 돌아보기

### [new] 새로 배운 것이 있었나요?

- Mui ver.4에는 `warning`, `info`, `success` 등의 color prop이 없다.
- **행복 방정식**. 행복은 내가 원하는 것 대비 내가 가진 것의 양이라는 방정식인데,   
  이때 행복을 키우는 방법에 분모를 줄이는 것 또는 분자를 키우는 것이 있다면 나는 분자를 키워 행복을 키우려는 사람이다.  
  왜 그렇냐면 타고난 성정이 '새로운 뭔가를 해보는 것'을 너무 좋아해서 그렇다.
  활기와 에너지를 갖고 다양한 것에 도전하며 분자를 늘리려 노력하자.
  
<img width="200px" alt="행복 방정식" src="https://user-images.githubusercontent.com/50111853/227767505-853dc3ee-1c17-4be7-9aa3-29cb818c0509.png"/>

### [finding] 가장 어려웠던 건 뭐였나요?

알림처럼, 숫자 뱃지가 위에 올라가는 탭. Mui Tab 컴포넌트와 Badge 컴포넌트를 썼는데 탭도 `span`, 뱃지도 `span`이라 `width` 잡기가 힘들었다.
글자 수에 따라 다이나믹하게 탭 길이가 달라지는 걸 원했다. 탭의 `overflow: hidden` 속성들을 다 `visible`로 바꾸고
글자 수가 가장 적을 경우를 `min-width`로 고정해둬 글자수가 길어지더라도 글자와 뱃지가 모두 보이도록 했다.

### [future] 앞으로 시도해보고 싶은 게 있나요?

react-query 더 자세히 공부


2023년 3월 요즘의 생각


[진유림 님의 강점 혁명 워크샵](https://milooy.github.io/life/strength-finder/)에 관한 글을 읽고
바로 책을 구매해서! 나의 강점 찾기 테스트를 해보았다.

아래와 같은 결과가 나왔다.

1. 최상화(Maximizer) 테마
2. 개별화(Individualization) 테마
3. 커뮤니케이션(Communication) 테마
4. 사교성(Woo) 테마
5. 긍정(Positivity) 테마

## 강점 5가지

### 1. 최상화
: 개인이나 단체의 탁월성(excellence)을 이끌어내기 위해 그들의 강점에 초점을 맞춥니다.
이들은 평균 이하의 수준을 평균으로 올리는 것보다, 우수한 수준을 최상의 수준으로 끌어올리는 것을 추구합니다.
 1. 기준이 평균이 아니라 최상
 2. 0부터 시작되는 일보단 이미 잘 되고 있는 일을 최고로 만드는거에 더 끌림
 3. 사람들의 강점에 매력을 느끼고 그 점을 선별하는 성향 때문에 다른 사람들은 이 성향의 사람이 차별한다고 생각할 수 있음
 4. 인정, 칭찬에 후하고 또 본인도 인정받을 때 감사해함
 5. 자신의 강점을 발견하여 개발한 사람들에게 매력을 느낌
 6. 본인의 부족한 점을 고쳐서 평균으로 만드려고 하는 것은 비선호 (타고난 재능을 적극 활용하고 싶어함, 이 방식이 더 즐겁고 효율적이라고 느낌)
 7. 자신의 한계, 약점, 실패에 대해 고민하는데 시간을 쓰고 싶어하지 않음
 8. 새로운 사람을 대화에 참여시킴. 새로운 사람을 알게 되는 게 기쁨

### 2. 개별화
: 각 개개인이 가지고 있는 고유한 개성에 흥미를 느낍니다.
이들은 서로 다른 사람들이 어떻게 협력해서 생산적으로 일할 수 있는지를 알아내는 재능을 가지고 있습니다.
 1. 개인간 차이에 주목함. 각자가 어디서 동기를 얻는지, 어떻게 생각하는지, 어떻게 대인관계를 구축하는지 관찰함 -> 생산적인 팀을 구성하는데 도움이 됨
 2. 다른 사람이 도움이 필요할 때를 빠르게 알고 돕는 것을 즐김
 3. 최신 정보를 빨리 얻고 특정 사람들에게 현재의 사건에 대한 최신 소식을 알려줌

### 3. 커뮤니케이션
: 대체적으로 쉽게 자신의 생각을 말로 옮길 수 있습니다. 이들은 대화도 잘하고 발표에도 능합니다.
 1. 사람들의 주의 집중 시간이 아주 짧다고 생각하여, 내가 전달하는 정보가 사람들의 기억에 남도록 이야기에 생명력을 불어넣으려고 함
 2. 완벽한 표현을 찾기 위해 노력하고 극적인&힘있는 단어를 조합하려고 애씀
 3. 자신이 아끼는 사람들과 떨어져있을 때 비참하거나 쓸쓸해하고 좋은 친구와 함께 있을 수 있기를 애타게 바람
 4. 활기 넘치는 토론에서 의견 주고 받기를 매우 좋아함

### 4. 사교성
: 새로운 이들을 만나 그들의 마음을 얻는 일에 도전하기를 무척 즐깁니다.
이들은 어색한 분위기를 깨고 다른 사람과 인맥을 쌓는 데에서 만족감을 얻습니다.
 1. 할말이 없는 경우가 거의 없고 어색함을 깨고 친해지는 데서 만족감을 얻음
 2. 일단 친해지면 대화를 마무리하고 다른 사람에게 옮겨가는 것도 좋아함 (이 성향의 세계에는 남이란 없고 아직 만나지 않은 친구들만이 있음)
 3. 사람들의 성공, 기여, 장점을 강조하여 칭찬과 축하의 메시지를 잘 건넴
 4. 새로운 사람이나 외부 사람을 토론에 잘 끌어들임
 5. 한번에 한 사람에게 모든 관심을 집중
 6. 너무 오래 혼자 있으면 기가 꺾일 수 있다.

### 5. 긍정
: 주변 사람들을 쉽게 사로잡는 긍정적인 열정을 가지고 있습니다.
이들은 낙관적이며 사람들로 하여금 자신들이 하려는 일에 열의를 갖게 만듭니다.
 1. 성취를 이룰때마다 이를 축하하고 모든 프로젝트에 재미를 가미하려고 함
 2. 미래를 계획할 때 융통성 있게
 3. 본인에게도 다른 사람에게도 과도한 스트레스 주지 않으려 노력
 4. 사람들과 교류를 많이 할 수록 인생에 더 큰 의욕

## 피드백 & 액션 아이템

1. 사람들의 성공을 돕는 역할을 찾아보자. 사람들이 자신이 가장 잘하는 것을 설명하는 것을 도와보자
2. 내 강점에 집중해라
3. 친구와 동료들에게 동기를 부여하는 활동을 계획해보자 (소소한 성과를 기념하는 이벤트, 정기적인 축하 행사 등)
4. 당신의 감정을 구체적, 실질적이며 개인적인 감사와 인정의 표현으로 바꾸어 사람들에게 전달하도록 꾸준히 노력하자

### 내 생각

생각해보니까 이미 나도 모르게 이 액션 아이템들을 실행하고 있는 것 같다.
회사 팀원들과 같이 공부하고 기술적인 내용을 나누고 싶어서 한 팀원에게 제안해 시작한 스터디! 5개월째 하고 있는데 다른 팀원들도 자유롭게 참여할 수 있도록
라운지에서 주기적으로 실행했고, 그 모습을 본 다른 팀원들도 자발적으로 참여해 지금은 넷이서 스터디를 하고 있다.

주제로 프론트엔드 전반적인 걸 다루는데 의문이 생기면 같이 찾아보고 이해하는 과정도 재미있고, 스터디 때 다뤘던 문제나 내용을 
실제 작업하면서 마주쳐서 '어!! 이거 그때 저희 마주쳤던 문제!!!'하면서 쉽게 해결할 때도 종종 있다.
이 스터디가 팀원들의 성장, 나의 성장을 돕는 요소이자 동기를 부여하는 활동인 것 같다.


내 한계와 실패를 미리 걱정할 시간따위 없다!

강점혁명! 나의 강점은 무엇일까?


상태: 앱의 동작 방식을 설명하는 모든 데이터

**상태 '관리'의 조건**
- 최초 값(initial value)을 저장
- 현재 값(current value)를 읽기
- 값을 업데이트

React 상태 관리 로직의 한계점
- props drilling, props bubbling
- Context API는 확정되지 않은 수의 값을 저장하는데 적합하지 않고 최적화 관점에서 한계가 명확하다.
또 높은 곳 -> 자식, 손자 컴포넌트로 줌으로 많은 데이터를 많은 컴포넌트에 주게 된다.
- Context API는 상태 관리라기보단 의존성 주입(Dependency Injection)에 가깝다. (`Provider`라는 파이프 시작점에서 `Consumer`라는 파이프 끝으로 이어지는)

## Recoil
- React의 내장 상태 관리 기능의 한계점 극복
- 최대한 리액트스러운 API 유지 (리액트 유저들의 러닝커브 낮음)
- 사용하기 위한 부속 라이브러리 최소화
	- redux (redux-thunk, redux-saga 등...)

### Recoil의 접근 방법
- redux의 경우 redux, react가 따로 있고 react-redux가 전달해줘야했음. 반면 recoil은 directed graph를 따라 리액트 컴포넌트로 바로 흘러들어감.

### Recoil의 철학
- 보일러 플레이트는 적게, 리액트의 로컬 상태(useState, useReducer)와 유사한 인터페이스
- **파생 데이터**를 사용함으로써 데이터를 사용하는 컴포넌트에서 임의로 데이터를 바꾸는 로직을 가져가지 않아도 된다. 
	- 가져와서 useEffect로 바꿔주기 하지 않고, 로직 자체를 recoil atom에 귀속시킬 수 있다.

## Recoil의 Core Concept

### flexible shared state: 유연하게 상태 관리

- context api에서는 데이터를 동적 생성했을 경우 변화 주기가 어렵고 변화를 줄 경우 전체 트리가 새로 렌더링된다. 또 Provider, Consumer가 각각 트리의 root, leaf에 존재하다보니 커플링 현상이 발생한다. => 렌더링 최적화에 이슈가 생길수도. (context api는 잘 바뀌지 않는 데이터를 쓸 때 좋다.)
- 리액트의 로컬 컴포넌트 상태(useState, useReducer)처럼 batching 같은 작업이 모두 라이브러리 내부에서 처리된다.

### derived data and queries: 파생 데이터

예를 들어 화면에 사각형 두개를 그리고 이 두개가 겹치는지 안 겹치는지 확인하고 싶다면 사각형 두개의 위치와 **그 두 위치를 계산해 판별한 겹침 여부 상태**가 따로 필요할까?

redux에서는 `layeredItemKey`를 사각형 데이터에 넣어놓고 겹칠때마다 업데이트하는 로직을 넣어준다. 
만약 그냥 컴포넌트에서 판별하게 하려면? `useEffect`에 `layeredItemKey` 관련 로직을 넣어도 된다. 
근데 이러면 로직이 컴포넌트 안으로 들어가게 된다. 커스텀 훅으로 뺀다고 해도 컴포넌트가 여러개 생길때 커스텀훅을 다시 잡아다가 넣어줘야한다.

recoil에서는 `layeredItemKey`(겹친 사각형 key) 데이터를 `selector`가 dependency 있는 애들을 가지고 있다가 위치 데이터가 바뀔때 recompute한다.
즉, **상호의존적인 상태를 만들 필요가 없다. & 리액트 사이드에서 고민할 필요가 없다.**
파생 데이터를 만들어두고 observing하고 있다가 데이터가 바뀌었을 때만 재계산한다.(mobX와 비슷. mobX 만든사람이 만듦)

- `Atom`: 데이터를 보관하는 기본 단위, redux의 reducer과 유사하지만 전체 Store의 일부분
- `Selector`: atom이나 다른 셀렉터들을 조합할 수 있음, 파생되는 상태를 생성, dependency인 atom이 업데이트되면 같이 업데이트되므로 관리가 용이.

### React API와 비슷한 API들

recoil의 atom과 selector는 동일한 API를 쓴다.

- `useRecoilState`: `useState`와 똑같이 getter, setter 가짐
- `useRecoilCallback` : `useCallback`은 메모이징된 함수를 사용하기 위해 쓴다. 
그냥 `useCallback`을 써도 문제는 없지만 dependency array가 더럽혀질 수 있다. 
`useRecoilCallback`은 리코일 자체가 스냅샷을 읽어서 리액트 컴포넌트 내부에서 사용 가능. 

### App-wide state observation: 앱 단에서 상태 관찰 기능


리액트 상태관리 라이브러리 비교 (작성중)

redux vs. recoil vs. jotai


## 일에서 만족감을 얻는 사람들

- 만족하며 일하는 사람들은 일을 하면서 도전정신이 샘솟는다. 일은 그들의 능력을 최대한 발휘하게 하여,
한계를 벗어나 편안한 영역 밖으로 나가게끔 밀어붙인다. 이러한 운 좋은 사람들은 일이 재미있다고 생각한다. (p.12)
- 그들은 업무시간에 어느 정도의 자율성과 재량권을 갖는다. 그리고 그 자율성과 재량권을 이용하여 전문지식을 쌓거나
정통함의 경지로 나아간다. 그들은 근로자로서 또 인간으로서 두 역량을 모두 계발하며 새로운 것을 배운다. (p.12)
- 일을 하는 대가로 봉급을 받는 한, 사람들은 자신이 하는 일이 가져올 결과를 그다지 중요하게 생각하지 않는다. (p.20)

## 텔로스와 소명의식

- 루크가 자신의 일에서 추구한 것은 철학자 아리스토텔레스가 `텔로스(telos)`라고 불렀던 것,
바로 그가 속한 조직의 '목적'에 의해 형성되었다. 환자들의 건강을 증진하고, 질병을 치료하고, 고통을 줄이는
그 병원의 목적이 루크가 자신의 일을 바라보는 방식에 깊이 내재해 있었다. (p.38)
- 루크는 자신이 속한 조직의 목적을 믿었다. 이 믿음은 그의 일을 의미 있게 만들었다. (p.39)

자신의 일에 만족하려면 자신이 하는 일의 목적에 대한 신념이 있어야한다.
소명(calling)은 생업(job)이나 직업(career)과는 다르다. 생업, 직업, 소명 순으로 일에 만족감을 느낀다.
루크는 환자와의 상호작용을 통해 자신을 가장 쓸모 있고, 중요하며, 능력있다고 느꼈다.

## Job Crafting

자신의 직무 그 이상, 그 너머를 일하는 사람들은 자신이 속한 곳의 목적을 내재화해 그에 맞추어 일한다.
병원 청소 노동자 루크는 자신의 공식 업무 너머 '환자와 보호자 케어'라는 목적을 내면화한 채 일했다.
병원의 핵심 목적을 마음속에 담아둔 채 자신의 일을 재창조한 것이다.

소명의식을 가진 미용사들은 자기 기술에 자부심을 가지고 있으며,
겉보기에는 단순해보이는 머리 자르기 같은 행동의 복잡한 특성을 한껏 즐기고 있었다.
또 사람들을 상대하며 이야기를 나누고 그들을 이해하는 스스로를 자랑스러워했다. (p.53)

### 일은 언제 의미를 지닐까?

```text
1. 모든 일은 다양성, 복잡성, 기술계발, 발전이라는 요소를 포함하도록 구성될 수 있다.
2. 그 일을 하는 사람에게 상당한 자율권을 부여하도록 조직될 수 있다.
3. 사람들을 다른 이의 행복에 기여하도록 하면서 일은 의미를 지닐 수 있다.
```

- 자신의 일이 다른 사람들에게 미치는 잠재적 영향력을 아주 중요시하는 것만으로도 직원들에게 영감을 줄 수 있다. (p.55)
대학 기부금 아웃바운드 노동자들에게 장학금 수혜자를 만나게 해주면 그들은 영감을 받은 후, 더 효율적으로 변한다.

### 만족스러운 일은

```text
1. 그 일 자체가 조금 어렵고 다양한 특성을 지니며 매력적이어야 도움이 된다.
2. 그 일이 당신에게 기술을 사용하고 더 많은 기술을 계발할 기회를 준다면 도움이 된다.
3. 일하는 방식에서 재량권을 지니면 도움이 된다.
4. 존경하는 동료들과 한 팀을 이루고 있다고 느끼면 도움이 된다.
5. 일이 아주 중요한 목표를 갖고 있으며 당신이 하는 일에 의미와 목적의식을 부여한다면 큰 도움이 된다.
```

## 효율적인 조직들의 공통 요소

1. 높은 수준의 고용안정성 -> 직원들의 충성심과 신뢰 형성
2. 자율관리팀과 권력이 분산된 의사결정 과정 -> 직원들의 재량권과 자율권. 다른 직원을 감독하는 일이
주 업무인 직원의 필요성을 줄이고 직원들 사이 신뢰를 강화
3. 업계 평균 급여보다 더 높은 급여 & 개인적인 인센티브에 의존하지 않음 -> 회사가 성과를 잘 내면 모든 직원들이 이득을 본다.
4. 지속적으로 광범위한 교육 제공 -> 직원들은 새로운 도전을 마주하고 새로운 기술을 계발
5. 직원의 수행력을 과도하게 평가하지 않음
6. 회사의 사명을 굉장히 강조 -> 조직 곳곳에서 날마다 실행

## 인센티브와 동기 밀어내기

- 돈같은 외발적 동기는 내발적 동기를 약화('동기 밀어내기')시킨다. 금전 제안은 사람들로 하여금
`이 일에 내 시간과 노력을 들일 가치가 있는가?`라는 질문을 하도록 만든다.

## 이데올로기는 어떻게 진실이 되는가

- 사람들이 자신의 행동에 대한 생각을 바꾸면서다.
우리가 과거 행동들을 이해하는 방식은 우리의 미래 행동들에 영향을 미칠 가능성이 크다. (p.142)
- 자기 충족적 예언을 통해서다. 이때 이데올로기는 다른 사람들이 행위자에 반응하는 방식을 변화시키고,
다시 이것은 그 행위자가 미래에 하는 행동을 변화시킨다.
예를 들어 교사들에게 임의로 '학습속도가 더 빠른 아이'를 알려준다면, 그들을 대하는 교사의 교육방식이 달라지고
그 학생들은 더 나은 학업 성과를 낸다. 자기 충족적 예언이 실현된 것이다.

### 피그말리온 효과

아이들의 지능이 '고정되어있다는 사고'가 있는 문화보다 '개발된다는 사고'를 지닌 문화에서 아이들이 더 많은 지적 발달을 이룬다.
회사에서도 경영주들이 근로자들이 급여를 통해서만 동기 부여를 받는다고 생각하면, 임금 외에는 일할 이유가 없도록 만드는
의미없는 조립라인을 만든다.

## 결론

일에서 재량권, 몰입, 의미를 박탈하면 사람들은 만족감을 덜 느끼고, 그 일을 잘 못하게 된다.
그들이 일을 잘 못할 수록 감독들은 그들에게서 더 많은 재량권을 앗아간다.

사회구조 속에 스며있는 이데올로기는 인간의 본성을 디자인했다. 그렇기에 우리는
**사람들이 가치있다고 여기는 일을 하도록 만드는 업무환경**과 **사람들이 자신의 일에서 의미를 발견하도록 하는 환경**을
디자인해야한다. 훌륭한 업무환경은 사람들로 하여금 훌륭한 일을 하도록 만들고,
노동자와 고객, 고용주에게도 좋은 영향을 미치는 포지티브 섬(Positive sum)을 이뤄낸다.

사람들은 행복할수록 더욱 유능하고 똑똑하게 일한다. 마음 상태가 긍정적일 때 대범하고 창의적으로 생각한다.
행복의 관점에서 효율성을 정의하고 업무환경을 변화시키자.

## 내 생각

나는 개발을 통해 만족감을 얻고, 내 쓸모를 느끼며, 행복하다. 내 삶의 모든 행복이 일을 통해 오는 건 아니지만 회사에서 소소한 기쁨을 마주칠 때가 많다.
지금 내가 다니고 있는 파스토와 나의 업무들은 거시적으로 볼 때 소상공인들의 경제활동을 돕고 우리나라 풀필먼트 산업의 디지털 포메이션에 기여한다.
내가 짜는 코드 한 줄 한 줄은 이 시스템을 안정화하고, 성능을 개선한다.
직원으로서 내가 하는 일의 목적에 신념을 갖고, 조직의 구석구석에서 창의적인 파트너십을 이끌어내자.


내가 하는 일의 목적에 신념을 갖고, 조직의 구석구석에서 창의적인 파트너십을 이끌어내자.

책 '우리는 왜 일하는가'를 읽고

 

2023년 2월 MVP 오픈을 목표로 하고 있는 사이드 프로젝트 리욜드(RE:jord)를 개발하면서 상호간 커뮤니케이션을 잘 못해 있었던 일을 정리해보았다.

## 상황

![세션을 이용한 인증 방식](/images/blog/2212/auth-session.png)

나와 백엔드 개발자 플뎁님은 위 이미지처럼 세션ID를 `httpOnly` 쿠키에 저장하는 방식으로 사용자 인증을 구현하고 있었다.
로그인 요청을 클라이언트에서 서버로 보내면, 유효한 사용자(로그인 요청)일 경우 서버에서 SessionID를 발급해 응답 헤더로 돌려주는 방식이었다.
이때 헤더에 바로 넣어서 보내주는게 아니라, 응답 헤더에 `set-cookie:JSESSIONID=세션ID`를 넣어 보내주면 브라우저가 자동으로 `JSESSIONID` 데이터를
쿠키에 저장해준다.

그렇게 개발하던 중, 서버와 클라이언트의 도메인이 다를 경우 `set-cookie`가 동작하지 않는다는 것을 발견했다.
API 응답은 제대로 오지만 브라우저에서 쿠키를 저장하지 못했다.

## set-cookie

그 이유는 서버와 클라이언트 도메인이 다를 때 쿠키를 주고받으려면 서버, 클라이언트 양쪽에서
http의 `withCredentials` 설정을 `true`로 하고, `Allowed Origin`을 와일드카드(*)가 아니라 클라이언트, 서버의 도메인으로 지정해야했는데
우리 앱은 이 두 설정을 안 해놨기 때문이었다. (`Allowed Origin`이 와일드카드로 되어있으면 서버에 credential=true로 요청한 모든 사이트의
credential 정보를 서버가 맘대로 바꿀 수 있다.)

![withCredential should be true between two different domains](/images/blog/2212/mdn-credentials.png)

[mdn](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials)에서도 이렇게 언급하고 있다.

그런데 현재 웹 뿐 아니라 앱에서 동일한 API를 사용하고 있었기 때문에 앱의 특성상 `Allowed Origin`에 특정 도메인을 제한해두는 게 불가능하다고 생각했다.
그래서 앱 분들은 이 오류가 안 나나? 하고 물어보니

쿠키가 브라우저 자체 기능인 만큼 앱 개발을 맡은 뿌요님과 데브님은 당연하게 아직 서버에서 인증 구현을 안 했다고 알고 있던 거였고,
oAuth 또는 JWT 방식으로 토큰이 구현되기를 기다리고 있던 거였다.

프로젝트를 시작한 이후로 매주 일요일마다 회의를 하고 있음에도 이런 오해가 있었다는 것은... 우리가 충분하게 소통하지 못했기 때문인 것 같다
나도 일이 바쁠 땐 슬랙이나 메세지를 봐뒀다가 답하는 걸 까먹곤 하는데 적어도 하루에 한번, 퇴근 후에 
밀린 답장을 하는 루틴을 만들어야겠다.

## 결과

결과적으론 인증 방식을 JWT로 바꿔서 해결했다. 
로그인 시 jwt 토큰을 받아 `axios-interceptor`에서 모든 요청 값에 이 값을 넣도록 설정하였다.


서버 클라이언트 도메인이 다른 cross-site 요청시 꼭 해줘야할 http 설정들 (withCredentials, Allowed origin)

리욜드: 인증 관련 미스 커뮤니케이션 회고

 

## 1, 2분기

올 1, 2분기에는 직접 블로그를 만들고, 공부를 더 해서 개발자 인생 처음으로 이직을 했다.
스터디 2개와 사이드 프로젝트를 같이 해서 정말 바빴는데 하다보니 일종의 루틴이 생겨 할 만 했다.
이직을 하기 위해서만은 아니었고 프론트엔드 개발에 집중을 하기로 마음을 먹으면서였다.
저질러 놓은 스케줄이 많다보니 몇달 간 퇴근 후에는 개발만 했다. 스스로를 압박하고 강제한 건 아니었는데 만들고 싶은 게 있고 원하는 게 있었다보니 자연스레 몰입할 수 있었다.
(당시에는 몰랐는데 지금 와서 생각해보면 ‘몰입’이라 부르기에 충분한 것 같다.)
또 회사가 집 5분 거리 지식산업센터로 이전하면서 출퇴근 스트레스가 확 줄었고, 룸메이트가 간간히 응원해준 게 큰 힘이 되었다.

6월 즈음에 지금의 회사에 합격했다. 자세한 이직 후기는 [이 글](https://haeun.vercel.app/blog/2207-move)에 있으니 생략한다.
합격 통보를 받는 순간 친구랑 통화를 하고 있었는데, 이 친구도 면접 합격을 기다리고 있었다.
내 합격 소식을 전하자마자 친구가 ‘좋은 기운 나눠줘서 고마워’라고 해서 마음이 찡했던 기억이 있다.
또 전 회사 생활을 마무리하면서 동기들과 저녁을 함께 했었다. 몰랐는데 우리가 생각보다 서로에게 유대감이 있었구나 느꼈다.
같이 일했던 동료들이 좋은 분들이었어서 마지막 퇴근을 하면서 아쉬운 마음과 후련한 마음 등 복합적인 감정이 들었었다.
아무튼 이 시기는 첫 이직 연봉협상도 해보고 설렘이 넘쳤던 시간이었다.

## 3분기

7월 중순 새 회사에 본격적으로 합류해서 회사와 팀에 적응했다.
팀에 리액트를 써본 사람이 별로 없어서 리액트와 TS로 진행한 통합회원 프로젝트의 꽤 많은 부분을 맡아 작업했다.  
API 연동 외에도 ERP에서 쓰일 공통 컴포넌트를 만드는 게 주 업무였는데
한 컴포넌트가 가지는 view, 밸리데이션, 로직 관련된 프로퍼티들을 잘 관리하고 또 여러곳에서 불러 쓸 수 있도록
개발하는 게 가장 어려웠다.

이전 회사는 SI 회사라 프로젝트 단위로 팀이었기 때문에 풀스택 업무를 해야했는데 이번 회사에서는 프론트엔드에 집중할 수 있어 좋았다.
또 팀에 시니어 프론트엔드 개발자가 계셔서 내가 원하는 미래를 걷고 있는 사람이 근처에 있다는 게 꽤 든든했다.

## 4분기

4분기 초에 위에서 언급한, 꽤 많은 부분을 맡아 열심히 개발했던 프로젝트가 회사 사정으로 내년으로 미뤄졌다.
약간의 멘붕과 무력감을 느꼈었는데 우리 팀 동료들과의 일대일 면담이 큰 도움이 되었다.

또 팀에 테스트를 도입하고자 테스트 관련 컨벤션 문서들을 작성하고 예시로 돌려볼 수 있는 테스트 케이스 문서와 코드를 작성했다.

회사가 자율 재택 근무에서 주 1회로 재택할 수 있는 날을 줄이면서
통근하느라 체력적으로 힘들어지기는 했지만 팀원들이랑 더 자주 만나고 서로 알아갈 수 있어서 좋았다.
회식 끝나고 집에 돌아갈 때마다 `우리 팀 진짜 좋다…`는 생각을 하곤 했다.
새로운 팀원이 두분이나 오셔서 더 재밌고 복작복작했던 4분기였다.

## 2023년에는

2023년에 더 공부하고 싶은 건 이것들이다.

- 유연하고 단단한 컴포넌트 설계, 함수형 프로그래밍
- 자바스크립트 철학
- JS, 리액트, 타입스크립트 더더더

그럼 이만 2023년도 화이팅! 🦭


벌써 2022년을 마무리할 때가 되었다. 개발보다는 내 경험과 감정에 관한 내용이다.

2022년, 개발 경력 2년을 채우면서의 회고

 

## 시간을 효율적으로 쓰면서 시간의 밀도를 높여라

### 시간의 밀도를 높이는 법

**하나의 행위가 2-3개의 의미가 있게 만들어라.**

- 즉, 하나의 행위를 여러 목적을 위해 이용하라.
- 만약 공인 중개사 자격을 위해 공부한다면 다른 부동산 임대업이나 강연, 집필도 할 수 있게 준비한다고 생각하라.

이렇게 목적이 추가되면 같은 공부를 해도 성과가 2배가 되고 의욕도 높아진다. 

### 바쁜데 할 수 있을까?

- 바쁠 때 `공부`를 하면 오히려 마음의 여유가 생긴다. (행동함으로써 불안이 줄어든다.)
- 바쁠 때 `타인`을 만나라. 세상에는 타인과의 만남으로만 얻을 수 있는 경험과 지식이 있고, 오히려 덧셈의 발상으로 시간 밀도를 높이게 된다.
물론 내 시간을 쓸 가치가 있는 사람을 만나라.

### 시간관리의 최대 장점 2가지

일과 인생이 즐거워지고, 좋은 사람이 될 수 있다.
시간 밀도를 높이고 시간을 유용하게 써서 해야할 일을 바로바로 마무리하고, 하고 싶은 일에 계속 도전할 수 있다.

### 커뮤니케이션을 할 때 시간을 낭비하지 않는 법

1. 열심히, 상세하게 이야기할 수록 상대에게는 전달되지 않는다. 장황하게 늘어놓으면 상대는 제대로 이해하지 못한다. 상대의 시간도 소중하다.
2. 포인트만 추려서 이야기하면 상대에게 잘 전달된다.
3. 남을 혼내거나 조언할 때는 여러 문제를 나열하지 않는다.
4. 상대를 설득하려면 밀어붙이는 것보다 질문 형식으로 말한다.
5. 사실과 의견을 나눠서 말한다.

### 생각하는 시간은 15분으로 제한

아직 준비가 되지 않았어도 일단 시작해버리는 각오도 필요하다. 막상 해보면 의외로 간단히 결되는 경우도 있다. 실패하더라도 그 경험을 발판 삼아 다음 행동을 하면 된다. 
주저된다면 `지금 안 움직이면 기회를 놓치는 건 아닐까` 스스로 질문해본다.


시간을 효율적으로 쓰면서 시간의 밀도를 높여라

Recent Posts