
유료 멘토링을 신청해 시니어 개발자와 대화를 했던 적이 있다.  
신청한 이유는 1. 동료 개발자의 추천 2. 구직을 시작하기에 앞서 포트폴리오를 리뷰받고 싶었음 3. 시니어 개발자의 이야기가 듣고 싶어서였다.

받은 조언들은 아래와 같았다.  
1. 이력의 공백이 있다면 그 시간을 어떻게 썼는지 잘 정리해라
2. 포트폴리오에 고민의 흔적이 있는 프로젝트가 있어야한다
3. 이력서에 자기만의 스토리가 있는게 좋다
4. 프론트엔드 개발자에게 1번째 우선순위는 순수 자바스크립트를 잘 쓰는 것이다

였다.

내 이력서와 포트폴리오에 대한 피드백은 ‘시키는 대로 일은 잘 하는 건 알겠는데, 본인만의 스토리가 없다’는 것이었다. 
*개발 중에서도 무엇에 관심이 있고 좋아하는지를 표현하지 않은 느낌*이었다고 하셨다. 
그 분은 웹에서의 애니메이션, 게임 개발에 관심이 많아 커리어를 그렇게 타온 분이었다. 
**어떤 프로덕트를 만드는 회사에서 무슨 일을 하고 싶다**는 걸 말할 수 있어야한다고 하셨다. 

그 피드백을 들었을 때 반박할 수 없었다! 
왜냐면 개발 자체는 재미있어도 딱히 어떤 프로덕트를 만들 때, 그 프로덕트(예를 들면 게임)라는 이유로 유독 재미있다고 생각해본 적은 없기 때문이다. 
(아직 만들어본 프로덕트의 종류가 적어서 그럴 수도 있다.)
오히려 그 프로젝트의 목적이 봉사와 소수자의 권익 증진 목적이면 보람을 더 느낄 것 같긴 하다.

대신 어떤 작업을 할때 유독 재미있었단 건 있었다. 프로젝트 과정에서 다른 팀, 다른 개발자와 소통하면서 제품을 성장시켜가는 협업과정 자체가 재미있었다. 
사내 FE 디자인 시스템을 만드려고 동료와 코드 구조를 설계할 때나 react-hook-form을 어떻게 활용할지 PoC를 만들었을 때가 가장 보람찼던 순간으로 떠올랐다. 
또 가독성이 좋지않은 코드, 개선의 여지가 있어보이는 코드를 리팩토링하는 개발을 할 때 제일 빠르게 시간이 갔다.

즉, 내가 ‘만들고 싶은 단 하나의 제품군은 없지만 어떤 프로덕트던 그걸 만들어내는 과정에서 사람들과 협업할 때 가장 행복을 느끼는 사람’이라는 걸 깨달았다.
이 결론을 얻고 나서 회사에서 내가 협업, 커뮤니케이션, 더 나은 개발 문화를 위해 기여했던 부분들을 더 돋보이게 이력서를 수정했다. 

결론은… 꼭 만들고 싶은 어떤 프로덕트가 있어야만 좋은 개발자라고 생각하지 않는다.
**프로젝트를 해내는 과정 자체에서 즐거움과 성취감을 얻는 나같은 사람도 있다는 걸 사람들이 알아줬으면 좋곘다.** 
또 나같은 개발자들이 이런 이유로 자신을 의심하지 않았으면 좋겠다.

📝


면접관이 말했다 '어떤 개발을 할때 가장 재미있으신가요'

잡부 개발자면 안되는 걸까


![팀 문화를 위해 노력한다는 칭찬](/images/blog/23/teamCulture.png)

어렸을 때부터 친구들 사이 갈등이 있을 때 중재자 역할을 종종 하기도 했고
소프트 스킬이 나의 큰 강점 중 하나라고 생각해왔다.
**2023년은 그 생각이 나 혼자만의 생각이 아니었단 걸 다른 사람들을 통해 검증 받은 한 해**였다.
[2023년 상반기 회고](http://localhost:3000/blog/2306-retro)에 이어 하반기 기록을 적어본다.

## 6-8월: 열일

![우리가 가장 좋아했던 카페](/images/blog/23/coffeeWith.webp)

6~8월엔 정말 열심히 일했다. 중요한 프로젝트를 진행 중이었어서 대다수의 팀원들이 자발적으로 야근을 했다.
이때 회사 오피스 이전도 겹쳤었는데, 새로운 오피스가 아침 8시부터 오후 6시까지만 에어컨을 틀어줬다.
그래서 그냥 땀 뻘뻘💦하면서 야근을 했다. 모두가 열심히 했던 프로젝트였는데
퇴사에 대한 이야기는... 아쉬운 마음은 여전히 있지만 2024년부터는 진짜로 무브온 할거라
이쯤에서 마무리!

\
어쨌든 팀원들과 열심히 일하고, 저녁식사로 떡볶이 먹고 택시 타고 집 갈때의 그 여름 바람은
꽤 잊기 힘들 것 같다! 2023년 가장 감사한 일은 이 팀원들을 만난 것이고 2024년 이후 나의 과제는
이 개발자 동료들과 오래오래 서로 응원하며 지내는 것.

새로운 회사에서도 좋은 동료들을 만날 수 있길!

## 9월: 쉼과 공부 그리고 첫 발표

![발표하는 모습](/images/blog/23/conference.webp)

9월엔 개발자로서 [첫 컨퍼런스 발표](https://haeun.vercel.app/blog/2309-fengicon)를 했다.
사내 스터디 경험에 관한 발표였다. 발표 후에 **잘 들었다고 다가와서 말씀해주신 분도 계셨고
이후에 사내 스터디를 직접 만드셨다는 소식을 들려주신 분도 계셔서 뿌듯**했다.

\
또 9월부터는 실업급여를 받게 되었다. 바로 재취업을 할까 했으나
미뤄뒀던 블로그 리뉴얼을 하고 싶었고
커리어를 시작하기 전 긴 여행을 다녀오지 못한게 아쉬워서 호주 여행을 계획하였다.
서울대입구 캐치카페에서 공부도 하고, 바빠서 못 만났던 친구들도 만나고 여행준비도 했던 9월.

## 10월: 호주 여행

![울룰루](/images/blog/23/ausNight.webp)

10월엔 **3주 동안 호주**를 다녀왔다. 호주 서부인 퍼스로 시작해서 중부 사막 지역인 울룰루와 동부 시드니까지 다녀왔다.
빨간 모래 가득한 울룰루에 직접 가는게 인생의 버킷 리스트 중 하나였어서 모든 비행 일정을 울룰루 방문에 맞췄었다.

\
위 사진 속 왼쪽에 작게 보이는 게 세상에서 가장 큰 돌이자 **지구의 배꼽🏜️**이라고 불리는 울룰루다.
울룰루를 처음 알게 된 건 대학교 때였는데 그 빨간 모래, 화성 같은 비주얼에 이유없이 반했다.
언젠가 꼭 가보고 싶었는데, 가서 땡볕에 그 옆을 계속 걷기까지 했으니
당시에는 쪄죽거나 탈수로 쓰러질 것 같았지만 글쎄, 올해 가장 잘한 일 중 하나다.

![카타츄타 국립공원](/images/blog/23/kataTjuta.webp)

울룰루에서는 3박 4일 투어를 했다.
침낭에서 머리 위에 뭔가가 기어다니는 걸 못 들은채 하면서 자고, 매일 새벽 4시 해가 뜨기 전 일어나 협곡이나 산에 올라갔다.
투어 가이드 레이첼의 말대로 _'strictly dominated by the Sun'_, 즉 철저하게 태양의 사이클에 맞춰 움직여야 했다.
이게 낭만이 아니면 뭐란 말인가...

어쨌든 울룰루에 있던 그 순간만큼은 철저한 대자연 속에서 속세의 일들과 걱정을 다 잊을 수 있었다.
투어에서 나와 일행 둘을 제외하곤 모두 유럽과 영어권 국가에서 온 친구들이었기 때문에 계속 영어로 대화하고
서로의 문화와 경험들에 대해 이야기했다.
무언가를 바라보는 관점이 탁 트이는, 내가 정말정말정말 좋아하는 기분이 드는 하루들이었다.

## 11-12월: 취업준비

호주에 돌아온 다음날부터 정말 바로 재취업 준비를 시작했다.
호주에서 힘을 많이 받고 돌아와서 힘들지 않았다.
이력서와 포트폴리오를 디테일하게 써내고 여러번 갈아엎었다.
포트폴리오를 정리하면서, 지난 회사에서 다양한 일들을 해볼 수 있던 것 같아 감사했다.

\
개인적으로 면접 전에 긴장을 너무 많이 해서 면접 스터디를 꾸렸다.
아는 사람 중에서 면접 스터디원을 구할 수 없어서 직접 만들었던 건데
모두가 의지를 가지고 잘 참여해주신다. (출석률 거의 100%)
모두 취업하게 되면 다른 스터디로 넘어가자고 먼저 말해주셨을 정도로 기간제 스터디 팀원이 아니라
좋은 프론트엔드 개발자 동료들을 만난 것 같아서 참 감사하다.

\
아직 이직처가 정해지진 않았지만
지난번 이직 때보다 더 다양한 채용 프로세스를 겪고 있는 중이다.
(이직 후 이 경험에 대한 이야기들은 한번에 적어볼 예정이라 스킵)
지난 이직을 했던 2021년 중반보다 경기가 안 좋은게 체감은 되지만 그동안 나도 많이 성장했기 때문에
좋은 곳으로 갈 수 있으면 좋겠다.

## 2024년의 core value

다가오는 한 해 **업무 외에** 리소스를 투자해보고 싶은 일은 아래와 같다.

1. **잘하는, 타고난 것같은 개발자들을 볼 때 드는 열등감 이겨낼 방법 찾기**
2. **개발 철학을 쌓아가기** (커피챗 활용하기, 실무 경험 외에도 개발 방법론 관련 서적을 읽어야할 것 같음)
3. **나에게 딱 맞는 기록법 찾기** (프라이빗 용도)

\
☘️
2024년의 소망이 있다면 좋은 팀원들을 만나 즐겁고 또 치열하게 개발하며 성장하는 것이다.
좋은 팀원들을 만날 수 있길 바라는 것 이전에 내가 좋은 팀원이 되는게 우선이겠지만!

그럼 이만 2023년 다들 고생많으셨고 2024년에는 더더더 햄복합시다 !!!


2023년 하반기 회고와 결심


![총 점](/images/blog/2204/score.png)

작년 초 라이트하우스로 성능과 접근성을 개선했었는데요!
개선 전에는 점수가 퍼포먼스 77점, 접근성 92점, Best Practices 92점, SEO 92점이었고,
개선 후에 모두 100점이 되었습니다! 모두 100점이 되니 빵빠레도 터지더라구요 ㅋㅋㅋ
작년 초에 개선했던 내용과 이번에 추가로 개선한 내용을 합쳐 글을 엮었습니다.

## 네트워크 성능

<img alt='성능 진단' src='/images/blog/23/lighthousePerformance.png' width='450px'/>

자세한 진단을 보면 첫째로는 `Reduce initial server response time`.
서버 응답 시간이 느리다고 합니다. 이 문제는 서버의 문제도 있지만 와이파이의 성능과 관련된거기도 해서요!
첫 측정 시에는 사람이 꽉 찬 카페에서 작업을 했던지라 집에 와서 다시 해보니 이 에러는 고쳐진 걸 확인했습니다!

## 이미지 사이즈 최적화

![이미지 사이즈](/images/blog/2204/imgsize.png)

두번째로는 `Properly size images`. 메인 화면에 있는 사진의 크기가 적절하지 않았다고 합니다.
실제로 보여지는 거에 비해 큰 사이즈의 이미지를 가져오고 있기 때문인 것 같습니다.
`next/image`의 `sizes` 속성을 사용해 최적화를 하라고 제안하더군요!
이 메인 이미지의 경우 최대 800px으로 커질 수 있기 때문에 `sizes`를 사용해 800px으로 크기를 제한했습니다.

마지막인 `Reduce unused JavaScript`는 구글 애널리틱스 연결에 필요한 키를 넣어두지 않아서 그런거였습니다.
Vercel 설정에 환경변수를 추가함으로써 위 문제도 해결했습니다.

### Document doesn't have a `<title>` element

사이트의 title이 있어야 스크린리더를 사용하는 사람들이 페이지의 개요를 알고, 서치엔진이 적절한 검색어와 사이트를 엮어줄 수 있습니다.

제 블로그에서는 게시글별로 커스텀 메타데이터를 적용하고 있습니다.
게시글이 아닌 페이지에 title이 없다고 해서 METADATA 상수를 사용해 기본값을 지정해주었습니다.

js의 스프레드 연산자를 사용해 기본값을 먼저 넣어주고, 그 위에 커스텀 메타데이터를 덮어쓰도록 했습니다.

```js
const MetaContainer = ({customMetadata}: {
    customMetadata?: CustomMetadata,
}) => {
    const config = {
        ...METADATA,        // 기본값
        ...customMetadata,      // 커스텀 메타데이터
    }

    return (
        <Head>
        <title>{config.title}</title>
            <meta content="width=device-width, initial-scale=1" name="viewport" />
            <meta name="robots" content="follow, index" />
            <meta content={config.description} name="description" />
        // 생략...
      </Head>
    )
}
```

### Links do not have a discernible name

![링크 이름 경고](/images/blog/2204/link.png)

블로그 `footer`에 깃허브, 트위터, 링트인 링크가 달린 로고를 걸어두었는데 이 링크에 아무 텍스트가 적혀있지 않아서 난 이슈입니다.
`aria-label` 속성을 추가하니 접근성이 100점이 되었습니다.

![aria-label 추가](/images/blog/2204/aria.png)

### `<html>` element does not have a [lang] attribute

문서에 언어가 지정되어있지 않다고 합니다.
`next.config.js`에서 수정해주면 됩니다. 제 블로그는 일단 한국어 컨텐츠뿐이라 kr로 지정해주었습니다.
추후에 영어도 추가하고 영어컨텐츠를 좀 더 적을 수 있으면 좋겠네요.

```js
// next.config.js
module.exports = {
  // 생략
  i18n: {
    locales: ["kr"],
    defaultLocale: "kr",
  },
}
```

## SEO 진단

<img alt='요소 겹침 이슈' src='/images/blog/23/lighthouseTarget.png'/>

그리고 위 문제는 모바일 뷰로 볼 경우 저 부분 요소들이 겹쳐서 그런 거였습니다.
요소의 마진값을 수정해 해결했습니다!

기술 블로그 라이트하우스로 성능과 접근성 개선하기


![](/images/blog/23/fengicon/001.jpg)

안녕하세요. 오늘 ‘작은 공을 쏘아올리자’,
부제 ‘회사에서 성장할 수 있는 환경 만들기’라는 발표를 하게 된 프론트엔드 개발자 박하은입니다.
저는 회사에서 사내 스터디라는 작은 공을 쏘아올려 팀원들과 함께 성장할 수 있었던 경험을 공유하려고 합니다.

![](/images/blog/23/fengicon/002.jpg)

일단 제 소개를 먼저 하자면 저는 캐나다에 있는 대학에서 마케팅을 전공했습니다.
디지털 마케터가 되기 위해 통계 프로그램인 R을 한번 공부해봤는데요.
원래 저는 하나에 길게 집중을 잘 못하는데, 제가 몇시간동안 자리에서 일어나지 않고 코딩을 하고 있더라고요.
그래서 이게 내 적성인가? 싶어서 코딩 관련 강의를 몇개 들어보니까,
정말 재미있어서 마침 코로나로 한국에 들어왔겠다, 대전에 있는 대덕인재개발원에서 스프링과 JSP 위주의 개발을 배웠습니다.

![](/images/blog/23/fengicon/003.jpg)

과정을 마친 후 2020년 연말 대전의 한 SI 기업에서 풀스택 개발자로서 일을 시작했습니다.
유성구에 있는 국가정보자원관리원에 파견되어 일을 했구요.
그러다가 2022년 여름에 서울의 한 물류 스타트업으로 이직을 했습니다.
아예 프론트엔드 개발자로 진로를 정해 리액트로 주로 개발을 했습니다.
그리고 6개월 후에 있었던 인사평가에서 받았던 피드백 중에 ‘팀과 함께 성장하고 더 나은 팀 문화를 만들고자 고민하고 행동한다’는 내용이 있었습니다.
그래서 오늘 발표에서는 이 피드백을 받기까지 제가 했던 것을 나눠보려고 합니다.

![](/images/blog/23/fengicon/005.jpg)

진짜 일을 잘 하는 사람은 자기 자신을 위해 일하는 사람이라고 합니다.
회사에서 몰래 개인 프로젝트를 한다는 게 아니라, 회사를 위한 일을 하지만 나도 함께 성장하는 개발을 한다는 건데요.

![](/images/blog/23/fengicon/006.jpg)

취업을 하고 나니 아침일찍 출근해서 8시간동안 일을 하고 집에 오면 에너지가 남아있지 않더라구요.
그래서 개인적인 공부나 사이드 프로젝트를 하는게 쉽지 않았습니다.
또 새 회사의 팀에는 중니어와 시니어보다 주니어가 더 많았습니다.
기술적으로 고연차 팀원에게 의존할 수만은 없는 상황이었기 때문에,
회사에서 스스로 성장할 수 있도록 환경을 조성해야겠다는 생각이 들었습니다.

![](/images/blog/23/fengicon/007.jpg)

그래서 맨 처음엔 팀원 한명과 일대일 스터디를 시작했습니다.
그러다 3명이 자발적으로 조인해 5명이 되었습니다.
일주일 회고, 함수형 프로그래밍, next.js 등등 다양한 주제를 함께 공부했는데요.
사내 스터디다보니 업무에서 쓰기로 한 기술을 함께 공부해서 직접 써볼 수 있었습니다.
한 가지 예시로, next.js 스터디를 한 후 사내 리액트 CRA 프로젝트를 next.js로 전환하기도 했습니다.

![](/images/blog/23/fengicon/008.jpg)

이렇게 팀원들과 같이 스터디를 하고, 함께 성장해서 좋았던 점은 크게 3가지가 있었습니다.
첫째로, 업무를 하다보면 바빠서 내 업무만 보게 될 때가 있는데요.
스터디를 하니까 서로의 아웃풋을 주기적으로 공유할 수 있었어요.
업무 외적으로 하고 있는 개발이나 방향성에 대한 대화를 많이 할 수 있었고,
동료와 같은 곳을 바라보고 있다는 라포가 형성되어 팀워크가 좀 더 강해지는 걸 느꼈습니다.
또 저는 팀원들의 실력이 좋아진다는 건 내 환경이 좋아지는 거라고 생각하는데요.
이런 이유로 실제로 네카라쿠배당토 같은 기업들이 사내 스터디를 장려하고 있기도 하죠.
함께 스터디를 하면서 서로 모르는 걸 알려주고, 보완해줄 수 있습니다.
마지막으로, 개발자 동료가 생깁니다. 회사 동료를 떠나서 함께 개발 이야기를 하고,
기술적인 토론을 할 수 있는 개발자 친구들이 생깁니다.
같은 도메인에서 같은 기술을 사용해본, 누구보다 더 서로를 공감할 수 있는 동지가 생깁니다.

![](/images/blog/23/fengicon/009.jpg)

그럼 사내 스터디를 시작하기 전 우리가 가져야할 마인드셋은 뭐가 있을까요?
첫째로, 공유하는 것을 아까워하지 말아야합니다.
나만 알아서 남보다 더 좋은 성과를 내고 싶을 수도 있고,
힘들게 찾은 황금 정보라 나만 알고 싶을수도 있습니다.
그러나 일단 내가 아는 정보는 남도 알고 있을 확률이 높습니다.
남이 알던 나만 알던 일단 ‘나는 이해했으니까 됐다’라고 생각해야합니다.
내가 제대로 이해했다면 그걸로 된 것입니다.
또 누군가와 아티클을 같이 읽고 이야기해보면 혼자 읽었을 때보다
더 잘 이해하게 되거나 시너지가 날 수도 있습니다.
마지막으로, 양질의 기술 정보를 팀원들에게 계속 공유해준다면
인사 평가에도 긍정적인 영향이 갈 수 있습니다.

![](/images/blog/23/fengicon/010.jpg)

즉, giver가 되자는 뜻입니다.

![](/images/blog/23/fengicon/011.jpg)

남에게 주는 것은 내 지식을 뺏기는 것이 아닙니다.
남에게 지식을 전해주기 위해서는 그 전에 내가 그것을 완벽히 이해해야 합니다.
결과적으론 남에게 주는 것보다 나에게 남는 경험과 지식이 더 큽니다.

![](/images/blog/23/fengicon/012.jpg)

두번째로, 스터디를 시작할 때 우리는 리더가 되어야합니다.
많은 개발자분들께서 ‘아 진짜 공부해야되는데…’라고 말합니다. 하지만 시작이 어렵죠.
그렇기에 우리는 리더가 되어서 스터디를 주도해야합니다.
스터디 일정을 계획하고, 일정이 밀린다면 어느 날 딱! 하자고 결단을 내린다던가 사람들을 독려할 수 있어야합니다.
그런데 만약 스터디를 제안하는 거 자체가 어렵다던가 어떻게 말을 꺼내야할지 모르겠다면 어떻게 하는게 좋을까요?

![](/images/blog/23/fengicon/013.jpg)

제가 사용했던 방법은 "함께 발전하고 싶다고 자연스럽게 느끼게 하기”였는데요.

![](/images/blog/23/fengicon/014.jpg)

아래의 이미지는 사내 디자인시스템 컴포넌트를 설계했을 때 정리했던 내용의 일부입니다.
이 디자인시스템을 공유할때 그냥 ‘이렇게이렇게 해서 써라'라고 하지 않고,
설계를 할때 어떤 고민을 했고 어떤 방법으로 그 문제를 해결했는지 등등 최대한 내용을 자세히 담아 팀 회의때 공유했었습니다.
다들 업무를 하면서 새로 알게 된 내용이나 업무 관련 기술을 잘 정리하고 계실 것 같은데요.
그 문서를 혼자 보시기보다는 살짝 다듬어서 팀원들에게 공유해보는건 어떨까요?
저는 이렇게 정리했던 걸 공유하기 위해서 글을 다듬고,
또 혹시나 질문이 들어오면 답을 해줘야하니까 좀 더 자세하게 찾아보는 과정에서 많이 배웠던 것 같습니다.
그리고 이렇게 몇번 하니까 팀원분들이 저를 ‘성장 욕구가 큰 사람, 새로운 걸 배우는 걸 즐거워하는 사람'으로 봐주시더라고요.

![](/images/blog/23/fengicon/015.jpg)

그렇게 빌드업을 이제 해뒀으면, 성장 의지가 강해보이는 한 사람 또는 소규모 인원에게 스터디 제안을 해보세요.
저도 향상심을 가지고 있는 동료 한명에게 스터디를 슬쩍 제안하는 걸로 시작했었는데요.
스터디를 하게 되면 모든 구성원이 시간과 노력을 기여해야합니다.
그렇기에 스터디 구성원을 무작정 늘리기보단 향상심을 가진 소규모 인원 위주로 시작하는 것을 추천드립니다.

![](/images/blog/23/fengicon/016.jpg)

그럼 이제 어떻게 스터디를 진행했는지 이야기해드릴게요.
저는 무조건 아웃풋이 있는 스터디를 하는 편입니다.

![](/images/blog/23/fengicon/017.jpg)

제가 가장 추천하는 방법은 정해진 내용을 각자 공부해와서 각자 인출하는 건데요.
칠판이나 종이에 주제만 적어두고 공부한 내용을 요약해서 모두 적어봅니다.
그 다음 각자 적은 내용을 설명해봅니다. 빠뜨린 내용이 있다면 되짚어보면서 보완합니다.
이렇게 하면 내가 모르는 게 뭔지 확실히 알 수 있고, 설명하는 연습을 하면서 면접 대비도 됩니다!
만약 모른다는 사실을 밝히기 부끄러운 분이 있다면 각자 노트에 적는 것도 좋습니다.

![](/images/blog/23/fengicon/018.jpg)

실제로 제가 스터디를 했던 모습입니다.
회사 회의실에 화이트보드가 있어서 거기서 했구요.
이런식으로 아웃풋이 있는 스터디를 했습니다.
공부한 걸 직접 설명해볼때 훨-씬 기억에 오래 남는다는 걸 느낄 수 있었습니다.

![](/images/blog/23/fengicon/019.jpg)

그 외에 추천하는 방법은 아예 그자리에서 같이 읽고 이야기해보는 것입니다.
이 방법은 짧은 아티클이나 배경 지식이 어느정도 있는 내용에 추천합니다.
또는 다양한 리소스를 활용해도 좋습니다.
꼭 어떤 책이나 강의의 커리큘럼을 따라가는게 아니라, 돌아가면서 읽고 싶은 아티클을 가져와
다같이 읽어보세요. 아마 다들 ‘나중에 읽어야지’하고 즐겨찾기해둔 글이 많으실 것 같은데요.
북마크했던 글들을 읽기에도 좋고, 다양한 주제다보니 덜 지루하게 느껴집니다.
마지막으로 회고 스터디를 추천드립니다.
새로 배운 것이나 했던 업무를 회고해보는 겁니다.
지난 한주간 마주쳤던 기술적인 이슈를 어떻게 해결했는지나 개인적으로 공부했던 내용을 가볍게 이야기해볼 수 있어 좋습니다.

![](/images/blog/23/fengicon/020.jpg)

그런데 만약, 아예 스터디를 같이 할 만한 팀원 자체가 없거나,
기술적인 내용을 계속 공유했는데도 아무 피드백이 없다면 어떻게 해야할까요?

![](/images/blog/23/fengicon/021.jpg)

이런 척박한 환경 속에서 우리는 그냥 ‘나 혼자 공을 쏘아올린 사람’이 됩니다.
무력감이나 실망감을 느낄 수 있습니다.
하지만 생각해보면 공을 쏘아올리는 과정 자체가 나에게 배움의 기간입니다.
그 과정을 통해 새로운 기술이나 몰랐던 것을 배우고, 문서화하는 경험을 했을테니까요.
이렇게 한번 작은 공을 쏘아올렸으니, 다른 작은 공을 쏘아올리는게 더 쉬워집니다.
또 그 작은공을 회사 밖에서 쏘아올릴 수도 있겠죠!

![](/images/blog/23/fengicon/022.jpg)

결론적으로 제가 이 발표를 통해 하고자 하는 말은 ‘내 환경을 내가 선택하자’는 것입니다.
무작정 ‘회사가 별로면 퇴사해버려!’라는게 아니라, 작은 공을 쏘아올려서 그 환경을 나의 성장을 위한 발판으로 삼자는 것입니다.
지금 환경이 척박하더라도 그 작은 공을 쏘아올리는 순간 우리는 성장하니까요.

어떤 행동경제학 연구에 따르면 ‘진정한 동기 부여는 팀워크와 성취감, 어려움 극복에서 나온다’고 합니다.
마라톤을 하는 사람들의 표정을 보면 너무 힘들어보이지만 그럼에도 그들이 달리는 이유는 그들의 동기가 내면에서 나오기 때문이라고 합니다.
42킬로미터를 달렸다는 성취감, 함께 달리는 사람들과의 연대, 그리고 체력적 한계를 극복하는 것.
프로젝트를 해내는 개발자들과 비슷할 것 같은데요.
여러분도 혼자 또는 팀의 동료들과 함께 작은 공을 쏘아올려보면 어떨까요?
더 즐겁게, 자발적으로 일할 수 있게 될 겁니다.

![](/images/blog/23/fengicon/023.jpg)

감사합니다.


사내 스터디 리딩 경험을 나눴던 발표 내용을 공유합니다.

작은 공을 쏘아올리자 : 회사에서 성장할 수 있는 환경 만들기


![input 비교](/images/blog/23/myBack.jpg)

## 상반기 목표와 결과

연초에 적었던 상반기 목표는
1. 유연하고 단단한 컴포넌트 설계법 배우기
2. 함수형 프로그래밍 공부
3. 자바스크립트 철학을 이해하고 JS, 리액트, 타입스크립트 더더더 공부하기
였다.

이 목표들의 달성 여부를 하나하나 따져보겠다.

## 유연하고 단단한 컴포넌트 설계법 배우기

리액트로 개발을 하면 컴포넌트를 합성하는 일이 잦다.
컴포넌트 합성과 재사용을 하면서 동시에 컴포넌트 별로 커스텀해야하는 부분들이 있기에
변화에 유연하면서도 단단한 컴포넌트를 만드는 법을 연습하는 게 중요하다고 생각해서 세웠던 목표다.

![input 비교](/images/blog/23/inputDesign1.png)

감사하게도 회사에서 공통 컴포넌트 설계 업무를 맡아 해볼 수 있었다. MUI `TextField`를 기반으로
`textarea`, 기본 텍스트 인풋, 검색어 인풋, `counter` 컴포넌트를 만들어야했다.
처음엔 위 이미지처럼 각 컴포넌트를 모아두고 공통점과 차이점을 비교해보면서 어떤 부분은 공통화하고 커스텀해야할지 생각해보았다.
counter를 제외한 세 컴포넌트의 공통점은 사용자가 text를 입력할 수 있고 validation 값에 따라 아래에 문구가 붙을 수 있으며
input 내부에 고정된 요소가 있을 수 있다는 거였다. 그러면서도 그 요소들은 각 페이지에 따라 조립하는 것처럼 넣었다 뺄 수 있어야했다.
그래서 **Compound Components** 디자인 패턴을 사용해 `input` 내/외 요소의 위치와 디자인은 디자인 시스템(공통 컴포넌트) 단에서 고정해두고
더 자세한 내용물은 각 컴포넌트에서 구현하도록 하였다.

이 작업은 나의 사수인 희동님이 이끌어 주셨는데, 정말 배운게 많았다.
희동님은 공통 컴포넌트를 설계할 때 **스타일, 레이아웃, 동작(메서드), 용어**를 먼저 생각해보라고 하셨고
코드 가독성을 위해 JSX 태그만 보고도 이 컴포넌트의 레이아웃을 알 수 있게 설계하자고 하셨다.
그래서 Compound Components 패턴을 사용했는데,
그렇게 하고 나니까 조합해 사용하는 것도 쉬웠고 리액트의 선언적 특성을 살릴 수 있었던 것 같다.
참 뿌듯했던 공통 디자인 컴포넌트 설계, 구현 경험이었다.

그럼에도 100% 달성!한 목표는 아닌 것 같고 앞으로도 유연하고 단단한 컴포넌트를 설계할 수 있도록
디자인 패턴 공부도 좀 더 하고 잘 만들어진 오픈 소스 라이브러리들의 코드도 좀 까볼 예정이다.

## 함수형 프로그래밍

함수형 프로그래밍 배우기!를 결심한 이유는 첫번째 목표와 조금 연결된다.
어떻게 해야 코드를 잘 짤 수 있을까 생각하다가 함수형 프로그래밍을 배워보면 좋을 것 같아
인프런 함수형 강의를 수강하기 시작했다. 강의 1편을 다 들어서 하반기에는 응용편을 들어야한다.
*쏙쏙 들어오는 함수형 코딩*이라는 책으로 스터디도 하고 있다.

일단 지금까지 함수형 프로그래밍을 해본 바로 가장 좋았던 건 코드를 지연적으로 실행할 수 있다는 거였다.
어떤 값이 필요할 떄 그걸 다 만들어놓고 시작하는게 아니라, 이터레이터를 만들어두고 지연적으로 실행시킬 수 있으니까
성능 개선에 꽤 도움이 될 것 같다. 또 단일 책임 원칙도 지키면서 가독성과 낮아진 유지보수 난이도까지 한번에 챙기는...
또 자바스크립트도 점점 함수형을 도입하고 있는 만큼, 내가 사용하는 언어가 나와 같은 곳을 바라보고 있는 것 같아 더 좋았다.
다만 실무에서는 별로 안 써봐서, 개인 프로젝트를 먼저 함수형으로 리팩토링하려고 한다.

## JS TS와 리액트

자스, 타스, 리액트 모두 작년보다 더 친해지긴 했지만 얘네가 워낙 빨리 발전하고 있는 만큼 딱 맞춰 따라가기가 어렵다.
코어 자바스크립트도 한 번 더 읽고 모던자바스크립트 딥다이브도 스터디하고 있지만 아직 아쉽다.

## 젤리주도개발자들

![달력](/images/blog/23/cal.png)

올 상반기에는 스터디를 정말 많이 했다. 출근 전, 퇴근 후 팀원들이나 아는 개발자 친구들과 스터디를 해서 세보니까
상반기에만 한 60회 정도를 했다. [혼공컴운](https://github.com/pullingoff/CAOS),
코어자바스크립트, [모던자바스크립트 딥다이브](https://github.com/Jellies-Study/Modern-JS),
[쏙쏙 들어오는 함수형 코딩](https://github.com/Jellies-Study/Grokking-Simplicity) 책 스터디부터
next.js, [함수형 프로그래밍 강의 스터디](https://github.com/pullingoff/ES6plus-Study)와 각자 배운 내용을 나눠보는 회고 시간 등등
업무 시간 외에도 개발 공부를 계속 하려고 노력했다.
개인적으로 [프로그래머스 알고리즘 문제](https://github.com/pullingoff/algorithm)도 PREP에 맞춰 꾸준히 풀었다!

스터디도 하고 회사일도 하고 심지어 방통대 컴퓨터과학과에까지 편입을 해서...
일정이 정말 바빠 가슴이 답답하거나 피곤할 때도 있었지만
일할 때 가장 중요한 게 동료, 최고의 복지도 좋은 동료라고 생각하는 나로써는
같이 달리는 팀원들이 있었기에 이 일정을 소화할 수 있었던 것 같다.

![카톡 캡쳐](/images/blog/23/ball.png)

이건 좀 자랑인데, 팀원한테 이런 말도 들었다.
왜냐면 제가 블로그 만들기 스프린트인 `Next.js로 블로그만들기 스파르타`를 개최해서
그 중 한분이 개인 블로그를 완성하셨그든요!!!

굳이 바깥에서 사람을 찾는게 아니라, 내 회사 동료들과 같이 공부하고 성장하니까
우리 사이의 유대도 커지고 팀워크도 좋아지고 업무할 때도 더 손발이 잘 맞게 되어 좋았다.
또 스터디를 만들고 인원을 늘리며 관리해온 과정은 **회사에서 작은 공 쏘아올리기**라는 제목으로
올 9월에 있을 펜지니어 컨퍼런스에서 좀 더 나눠볼 예정이다.

## 하반기 목표

그래서 2023년의 하반기 목표는

1. 혼공컴운/네트워크/모던자스/쏙코딩/이코테 1회독
2. 함수형강의 응용까지 완강
3. 개인프로젝트 함수형 프로그래밍 도입해 리팩토링 & 수치적인 성능 변화 기록할 것
4. 알고리즘 문제 주 3개 이상
5. 뜯어볼 코드 정하고 뜯어보기

이다.
그럼 이만 🎀오늘의 회고 끝🎀

2023년 상반기 회고


## 요약

짧게 요약한 내용입니다.

![회원가입 as-is](/images/blog/2305/ex-asis.png)

이랬던 코드를

![회원가입 to-be](/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으로 리액트 폼 개선하기


## 요즘의 아쉬움

지난 12월 말 - 1월 초에 코로나 휴가를 가지면서 유인동 강사님의 인프런 함수형 강의를 들었다.
실제 프로젝트에 써볼 만한 것들이 있는 것 같다.

최근엔 정산 어드민 리뉴얼 프로젝트를 열심히 했는데, 하루 8시간 주 5일 회사에서 뇌 리소스를 다 써버리니까 주말이나 퇴근 후엔 거의 개발을 못했다.
주중에 시간을 따로 내서 하는 동료들과의 스터디와 개인 사이드 프로젝트만 간간히 하고 있다.

작년 하반기에는 레거시 홈페이지의 자동화 테스트를 도입했다. Cypress, Mocha 문법, POM 패턴, 테스트 코드 짜는 법 등등
공부하면서 실무에서 사용해볼 수 있었다.

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

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

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

## 회고 양식

**[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월 요즘의 생각


자바스크립트 ES6에서 배열은 프로토타입 메서드 map, filter, reduce를 가진다.
배열이 아니더라도 이터러블이라면 사용할 수 있는 함수형 map, filter, reduce 함수를 구현해본다.

## map

수집할 값 정보를 파라미터 함수 `f`에게 완전히 위임한 고차함수 map을 구현해보자.
이터러블을 순회하며 함수 `f`를 실행한 값을 배열에 넣어 리턴하도록 하면 된다.

```js
const map = (f, iter) => {
	let res = [];
	for (const a of iter) {
		res.push(f(a));
	}
	return res;
}

map(p => p.name, products)
map(p => p.price, products)
```

## 이터러블 프로토콜을 따른 map의 다형성

```js
document.querySelectorAll('*').map(el => el.nodeName);
```

위 코드에서 `querySelectorAll`의 리턴값인 `NodeList`는 배열을 상속받지 않았기 때문에
map 함수가 없다고 뜨고, 에러가 뜬다. 그럴 땐 위에서 정의한 map 함수를 쓰면 된다.

```js
map(el => el.nodeName, document.querySelectorAll('*'));
```

제너레이터가 반환하는 이터레이터를 순회하는 것도 가능하다.

```js
function *gen() {
	yield 2;
	if (false) yield 3;
	yield 4;
}

map(a => a*a, gen());
```

최근 ECMAScript의 헬퍼 함수들이 이터러블 프로토콜을 기반으로 만들어지고 있어 앞으로 호환성도 좋아질 예정이다.

### 자료구조 Map 써보기

기존의 `Map` 자료구조를 사용해 새로운 map을 만들 수도 있다.

```js
let m = new Map();
m.set('a', 10);
m.set('b', 20);

new Map(map(([k,v] => [k, v*2]), m));
```

## filter

이터러블에서 조건에 맞는 원소만 걸러내는 함수형 `filter`를 만들어본다.
전체적인 구현 방식은 `map`과 비슷한데, `f(a)`가 `true`인 값만 걸러내면 된다.

```jsx
const filter = (f, iter) => {
	let result = [];
	for (const a of iter) {
		if(f(a)) result.push(a)
	}

	return result;
}
filter(p => p.price > 3000, products);
```

## reduce

reduce는 **값을 순회하면서 하나의 값으로 누적해 축약**하는 함수이다.
reduce는 영어로 '졸이다'는 뜻도 있는데, 여러개의 값을 졸여서(누적해서) 하나의 결과값을 생성한다고 생각하면 이해가 편하다.
이 함수는 **보조함수(1번째 파라미터)에 어떻게 축약할지를 완전히 위임**한다.

배열의 모든 원소를 더하고 싶을 때 `reduce`를 쓰지 않고 구현한다면 아래와 같다.

```js
const nums = [1,2,3,4,5]

let total = 0;
for(const n of nums) {
	total += n;
}
```

이제 `reduce`를 사용해 리팩토링해보자.
자바스크립트 내장 `reduce`에서는 `acc`를 생략할 수도 있으니 만약 `acc`가 생략되었다면 자동으로 첫번째 요소를
두번째 파라미터를 기본값으로 변환하도록 한다.

```js
reduce(add, 0, [1,2,3,4,5]); // 15
// =(add(add(add([0,1]), 2), 3).... 을 반복하는 것임

const add = (a, b) => a+b;

reduce(add, [1,2,3,4,5]);   // 이렇게 온다면 자동으로
reduce(add, 1, [2,3,4,5]);  // 첫번째 요소를 기본값으로 변환해 계산한다.

const reduce = (f, acc, iter) => {
	if(!iter) {
		iter = acc[Symbol.iterator]();
		acc = iter.next().value;
	}
	for (const a of iter) {
		acc = f(acc, a)
	}
	return acc;
};
```

커스텀한 `reduce` 함수는 가장 먼저 3번째 파라미터(이터레이터)가 있는지 확인하고, 없을 경우
`acc`에서 자기 자신 이터레이터를 꺼내오고, 그 `이터레이터.next()`의 값을 `acc`로 지정한다.

### reduce로 products의 모든 가격을 더한다면

```jsx
reduce((total, curr) => total + curr.price, 0, products)
```

## map+filter+reduce 중첩 사용과 함수형 사고

1. `map`으로 가격을 뽑는다
2. `filter`로 특정 금액(3만원) 이하의 상품만
3. `reduce`로 모든 가격의 합을 구한다

이 때 `filter`, `map`의 순서를 바꿔도 결과는 동일하다.

```js
const add = (a, b) => a+b;
	reduce(
		add,
		map(p => p.price,
			filter(p => p < 30000, products)
	)
)
```

좀 더 함수형으로 생각하려면 `add` 다음 파라미터(`curr`)나 `map`의 두번째 파라미터(타겟 arr)가 숫자가 있는 배열로 평가되도록 코드를 작성하면 된다.

```js
reduce(
	add,
	// 숫자 배열로 평가되도록
)
```

*참고: 인프런 [함수형 프로그래밍과 Javascript ES6+](https://www.inflearn.com/course/functional-es6)*

배열이 아니어도 사용할 수 있는 map, filter, reduce 함수형으로 만들어보기

자바스크립트 함수형 프로그래밍: map, filter, reduce


[진유림 님의 강점 혁명 워크샵](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개월째 하고 있는데 다른 팀원들도 자유롭게 참여할 수 있도록
라운지에서 주기적으로 실행했고, 그 모습을 본 다른 팀원들도 자발적으로 참여해 지금은 넷이서 스터디를 하고 있다.

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


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

Recent Posts