
![](/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)

감사합니다.


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

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


## 요즘의 아쉬움

지난 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월 요즘의 생각


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

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


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

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


![마이크로소프트에서 바라보는 종로 전경](/images/blog/2209/main.jpg)

걸스인텍과 마이크로소프트에서 주최한 `CODE;WITHOUT BARRIERS MEETUP`에 다녀왔다.  
많은 여성 IT 종사자들을 만나볼 수 있다는 생각에 냉큼 신청했었는데 선정되어서 정말 기뻤다!
종로 놀러올 때마다 마이크로소프트 본사를 우러러봤었는데 오피스에 들어가볼 기회가 생겨 꿈만 같았다.

![다과](/images/blog/2209/cookies1.jpg)

2022년 9월 3일 10시 마이크로소프트에 도착해서는 다과를 나누면서 주변에 앉은 분들과
인사, 명함을 나눴다. 개발자도 있고 데이터 엔지니어나 PM 등 다양한 개발직군의 사람들이 있었다.  
(폴바셋 에그타르트 짱 맛있었다!)

## IT 업계의 유리천장

영국 이코노미스트 발표에 따르면 한국은 `2022년까지 10년 연속으로
OECD 29개국 중 유리천장이 가장 심한 국가`라고 한다.  
다른 분야에 비하면 IT 업계는 유리천장이 덜할 것 같지만, 통계에 따르면
시니어로 일하는 여성 IT 종사자 비율은 현저히 적었다.
그 외에도 여러 지표들이 국내 IT 업계의 젠더 갭들을 나타내고 있었다.

## MS의 Diversity and Inclusion

그래서 MS에서는 전 세계의 남성과 여성이 기술을 배울 수 있는 접근성의 차이가 있다고 보았다.
인종, 성별, 종교, 국가 등 다양성을 높이고 배제되는 사람이 없는 생태계를 만들기 위해
접근성의 격차를 메우고자 D&I(`Diversity and Inclusion`) 미션을 세웠다.

마이크로소프트의 과거 미션은 '전 세계 모든 가정이 PC에 MS 소프트웨어를 하나씩 가지도록 하는 것'이었지만
지금은 '**지구상의 모든 사람과 조직이 더 많은 것을 성취하도록 역량을 지원하는 것**'이라고 한다.

## Truths and Insights

그래서 팀별로 개발자 커뮤니티 내 D&I를 활성화하기 위한 게임 `Truths and Insights`를 진행했다.
주어진 문장의 빈 칸을 채우면서 의견을 공유하는 게임인데,
같은 IT 업계 종사자끼리 개발자로서 드는 고민이나 경험을 나눌 수 있었다.

우리 조는 다 주니어 개발자였는데, 내가 입사 1년차 때 했던 고민을 하는 조원들이 많았다.
그래서 내가 나눈 팁은 이와 같았다.

1. **구글링을 30분 이상 한다면 그건 내가 모르는 것**이다.
**충분히** 고민하고 찾아봤는데도 모르겠다면 도움을 청하는 걸 두려워말자.
2. 동료에게 조언을 구할 때는 **문제 상황과 그 문제를 해결하기 위해 내가 해본 것, 결과**를 자세히 이야기하자.
3. 나이차가 많은 사수에게 어떻게 질문을 해야할지 모르겠다면 `저 고민이 있어요...`라고 물꼬를 틀자.

마지막 소감을 이야기할때 내가 나눈 팁이 큰 도움이 되었다고 한 조원이 있어 기뻤다.
시간이 좀 더 길었다면 더 깊은 이야기를 할 수 있었을 텐데 게임 시간이 약 2-30분밖에 안 돼서 아쉬웠다.

그럼에도 임파워링되는 자리였고,
기술에의 접근성 격차를 줄이는 게 유리천장을 얇게 하는데 정말 중요한 요소라는 걸 깨달았다.
굳이 성별이 아니어도 서울과 비서울 지역의 개발자들이 얻는 기회와 인프라가 정말 다른데,
내가 기술 접근성 격차를 줄이기 위해 할 수 있는 일은 뭐가 있을까? 다시 한번 생각해보게 되었다.

아직은 나도 주니어고 모르는게 많아 다른 사람들을 끌어주는 일을 많이 하지 못했는데
먼 미래가 아니라 가까운 미래에 내가 할 수 있는 일들(Action item)을 찾아봐야겠다.

마지막으로 지하 1층에서 마이크로소프트에서 제공해준 부타동 솥밥을 먹었다.
맛있었고, 즐거웠다.

🔚


광화문 마이크로소프트, 빌게이츠씨가 사준 밥, 즐거운 동료 개발자들과 함께

걸스인텍xMS CODE;WITHOUT BARRIERS 밋업에 다녀오다


[원문](https://matt-rickard.com/reflections-on-10-000-hours-of-programming)

무엇에서든 월드 클래스 실력을 가지는 방법은 올바른 방법대로 약 만 시간의 시간을 훈련하는 것이다. [아웃라이어, 말콤글래드웰]

글쓴이가 순전히 **코딩**(소셜 스킬, 매니징 스킬 등 제외)을 만 시간 하며 느낀 것을 적었다. 
그는 의도적으로 코드를 일만 시간 짜보았다고 한다. 그 중에서 보다 와닿은 것을 번역해보았다.

1. 공식문서를 읽는 것이 스택오버플로우에서 답을 찾는 것보다 거의 항상 빠르다.
2. 많은 경우에 당신이 찾는 답은 인터넷에 있지 않다. 그 말은 그 문제가 어렵거나 중요하거나 둘 다라는 것이다.
3. 가능한 한 코드를 많이 지워라
4. Syntactic sugar는 보통 나쁘다.
5. 단순하게 하는 건 어렵다.
6. 다양한 종류의 툴을 갖고 적절한 때에 무엇을 사용할지 알아두어라.
7. git이나 bash처럼 자주 사용되는 것들의 내부 원리를 알아두어라.
8. 반복되는 워크플로우의 경우 당신만의 툴을 만들어두어라. 자기가 직접 만든 게 그 무엇보다도 빠르다.
9. 만약 코드가 못생겼다면, 그건 나쁜 실수일 경우가 많다.
10. docstring이 아닌 주석을 달아야하는 코드는 리팩토링이 필요하다. 
11. 당신의 프로그램이 프로덕션에서 어떻게 구동되는지 이해 못한다는 것은 그 프로그램을 이해하고 있지 않단 뜻이다. 
최고의 엔지니어들은 자신의 프로그램이 모든 환경에서 어떻게 작동하는지 안다.
12. 11번은 빌드 파이프라인에서도 마찬가지다.
12. 쉽게 재작성할 수 있는 소규모 라이브로리나 일부분만 사용할 큰 라이브러리의 경우, 의존성을 직접 갖지 말아라.
13. [룰을 깨야할 때를 알아라. "don't repeat yourself" 같은 규칙의 경우, 가끔은 조금 반복하는게 더 낫다.](https://matt-rickard.com/dry-considered-harmful/)
14. 변수명을 정확하게 지어라. 예술과 같은 작업이다.
15. 결과적으로, 다른 분야의 엔지니어들은 세상을 다르게 바라본다.
16. 몇몇 프로그래머들은 다른 사람보다 10배 이상 효율적이다. 
17. 10배 더 나은 프로그래머인 것과 10배 더 나은 직원이 되는 데에는 연관이 없다. (어쩌면 반비례할 수도 있다.)
18. 좋은 API들은 사용하기 쉽고, 잘못 사용하기가 더 어렵다.

Reflections on 10,000 hours of programming

'일만 시간 프로그래밍을 한 개발자가 느낀 점' 번역


## 첫 오프라인 원티드살롱 네트워크편
[6월 원티드살롱 네트워크편](https://www.wanted.co.kr/events/wantedsalon220629)에 다녀왔다.

**코로나 19 이후에 개발자 커리어를 시작했기 때문에 회사나 SNS 외부에서 개발자를 만나는게 쉽지 않았다.** 
그래서 원티드를 둘러보다가 바로 참여 신청을 눌렀던건데 어떻게 소모임 리더로까지 선정이 되었다.

![핑거푸드](/images/blog/2206/wanted1.jpg)

원티드 사무실이 있는 롯데타워 35층에 도착해서, 근처에 계셨던 분과 핑거푸드를 먹으며 대화하기 시작했다. 
그 분이 우아한 형제들 소속 기획자였는데, 세상 진짜 좁다고 느꼈다.
내가 개발 처음 배울 때 워크숍에서 알게 된 배민 개발자분의 이름을 말했더니 '방금까지 그 분이랑 이야기하고 왔다'고... 
ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 이 맛에 네트워킹하지(?) 싶었다. 😉

가벼운 식사를 한 후엔 원티드에서 짠 팀대로 본격적인 네트워킹을 시작했다. **우리팀(8조)은 나까지 엔지니어 4명에 기획자 2명**이었다. 
엔지니어라고 또 같은게 아니라 임베디드 등 여럿 해보신 12년차 개발자분, 화공과 나와서 개발팀장하고 계신 분, 
기구 설계 엔지니어분과 1.5년차 쪼렙 개발자인 나까지 ㅋㅋㅋ  
기획 분야에서도 전략기획실에 있는 분이랑 A&R 기획자로 분야가 정말 다양했다.
그렇게 한 시간동안 자기 소개와 고민을 이야기했다.

## 8조의 고민

![원티드 살롱 모임](/images/blog/2206/wanted2.jpeg)

### 고인물

우리 조의 고민거리는 크게 **고인물**과 **전문성**이었다.  
실력(발전)이 없으나 윗자리를 차지하고 아랫 사람의 의견을 듣지 않는 임원진과
 직원에게 credit을 주지 않는 사람들에 대한 고민이 주로 나왔다.  
이야기를 들어보니 **대기업이든 중소기업이든, 한국이든 미국이든 상황은 다 비슷**한 것 같았다. 
다만 미국의 경우 프로젝트 매니저와 피플 매니저가 따로 있어서 동료때문에 힘든 경우 피플매니저에게 중재를 요청할 수 있다고 한다. (🫢) 
그런 사람을 어떻게 대해야할지에 대해서도 이야기해봤는데 결론은 '**현재에 충실하고 더 나은 사람이 돼서 다른 회사로 가자**'였다.
 어디 가든 상황은 비슷하니 내 발전에 좀 더 신경쓰는게 낫다는 거였다.  

이때 한 CEO의 이야기를 들었다. 그 사람은 성과를 낸 직원을 강단으로 불러서 
이 사람이 어떤 결과를 냈는지 모두에게 보여주고 퍼포먼스하듯, 시끄럽게 credit을 돌린다고 한다.
그 외에도 큰 선물을 미리 준비해두고 보이는 곳에 둔다는 등 직원들의 사기를 올리는 법을 확실히 아는 사람이었다. ㅋㅋㅋ
**보상이 핵심이다!**

### 전문성 (부제: 풀스택은 허상이다)

두번째로 '전문성'에 대한 이야기가 나왔다.
나포함 **모든 엔지니어들이 전문성에 대한 고민**을 하고 있었다.
2022년 6월 기준 나도 회사 프로젝트에서 파이썬을 자바스크립트나 리액트보다 더 많이 다뤘었다.  
그러다가 프론트도 백도 아닌 어중간한 상태가 되는 것 같아 아예 프론트엔드 엔지니어로 이직하려고 퇴사했는데, 
선배 개발자들이 내 선택에 응원을 보내주셔서 다시 한번 확신을 얻었다.
프론트엔드만 해도 배울 거, 공부할 게 너어어어어어무 많아서 다른 걸 공부하는 시간을 내기가 참 어렵다. 
영원히 공부하는 게 개발자의 숙명인 것을 요즘 들어 더 느낀다.

## 마무리

이렇게 한시간동안 이야기한 걸 요약해 발표하고, 단체사진을 찍은 후 해산하였다.  
짧은 시간이었지만 팀원들의 고민에 크게 공감할 수 있었고, 아직 대부분의 친구들이 대학생&대학원생인 나로선
 선배 직장인들의 이야기를 들을 수 있어 참으로 알찬 시간이었다.  
오늘의 만남을 소중히 하며 앞으로도 서로 영감과 고민을 나눌 수 있으면 좋겠다. 

끝!


조명, 온도, 습도... 좋은 사람들까지

원티드 살롱 네트워크편 다녀온 후기


네이버 테크 콘서트 정영록 님의 '빠르게 성장하는 슈퍼루키로 거듭나기' 영상을 보았다.  
빠르게 성장하기 위해선 환경/리뷰/기술이 중요하다.

## 환경

"문제에 봉착했을 때에야 사람이 간절해진다."

프론트엔드 개발자 로드맵에 있는 걸 다 보는게 가능할까?  
=> **전체를 훑으며 기초를 다지고 각각의 깊이를 더해가자.**

### 프론트 개발자가 커버하는 영역

1. 웹 애플리케이션 구조 설계
2. 시맨틱, 접근성, 검색엔진 최적화, 크로스 브라우징, 브라우저 하위 버전 호환성, 반응형을 고려한 마크업
3. 디자인 가이드라인으로부터 UI/UX 규칙을 도출하고 적용
4. 애플리케이션 로딩 및 렌더링 성능 최적화
5. 보안 취약점 방어
6. 테스트, 빌드, 배포, 운영, 모니터링
7. 개발, 테스트, 빌드~배포 자동화 도구 개발

- MVP(최소 기능 제품)을 만들기 위해 필요한 핵심만 챙겨 빠르게 과정 전반을 훑기
- 다양한 정보의 키워드를 주워듣고 일단 킵해두기. 
  - 무엇과 관련된 개념인가?
  - 어떤 맥락에서 등장?
  - 이걸 다루려면 어디를 봐야하는가?

=> 문제에 봉착하고 그 키워드가 등장했을때, 심화 지식을 찾아 해결하자.  
이론+실제 사용해봄으로써 문제 해결에 소요되는 시간을 줄일 수 있었음.

## 리뷰

힌트, 가이드라인, 핵심만 알아도 러닝커브가 낮아진다.  
선배가 개발하는 방법, 생산성을 높이는 방식을 옆에서 보고 습득하기

=> 코드리뷰!!!

### 코드리뷰의 목적

- 시나리오 체크, 로직 점검, 버그 가능성 제보, 오타 발견, 코드 규칙 위반 사례 확인 등
- 작성된 코드 더블체크
- 좋은 코드를 보고 배울 수 있는 기회
- 작성된 코드에 대한 책임을 함께 진다는 의미
- 구현 과정에서의 궁금증, 어려움을 공유할 수 있는 창구

## 기록

- 배운 건 기록하고, 기록은 공유한다. 기록은 공유하면 쓸모가 배가 된다.

### TIL : 엄연히 하나의 기술 문서!

- 오늘 새롭게 알게 된 내용을 문서화
- 이해에 구멍이 있는 부분 점검하고 채워넣기
- 난항을 겪고 있는 문제를 정리하기
- 꾸준하게 문서화 작성 스킬 향상, 부담 경감

=> 대신 독자를 상정하고 글을 쓰자. 체계적이고 정리된 형태로!

### Pull Request

- 분석과 진단, 의사결정 과정+ 구현 사례(코드)까지 갖춘 완결성 있는 문서.
- 히스토리 & 튜토리얼 역할. 팀 내에서 두고두고 공유되며 볼 수 있다.


루끼루끼 마 수뻐루끼 루끼루끼 마찌마찌 랔 느낌적인 느낌느낌

신입 개발자, 빠르게 성장하는 슈퍼루키로 거듭나기


미디엄의 ['how to be a 10x engineer'](https://medium.com/@_michaellin/how-to-be-a-10x-engineer-fdac2a5a1bd5)라는 글을 짧게 요약하고 내 생각을 적어본다. 

*(글에서 시니어 개발자가 10배 더 나은 개발자고 주니어 개발자는 평범한 개발자라는 느낌을 살짝 주지만, 
저자가 의도한 'junior'는 오로지 연차만을 말하는게 아닌 것 같습니다. 'junior developer'라는 단어는 '평범한 개발자'로 의역을 했습니다.)*

## 최고의 개발자?
'최고의 개발자'란 보통의 엔지니어보다 약 10배 나은 사람을 말한다.  
그들은 더 느린 속도로, 더 적은 양의 일을 할지도 모른다. 어쩌면 **코드를 치는 것보다 삭제하는데 더 많은** 시간을 쓸지도!  

### 최고의 개발자 vs. 평범한 개발자
는 바로 **소프트 스킬(non-technical skills)** 이다.  
They use the right tools, ask the right questions, and know how to prioritize.  
**그들은 적시적소에 맞는 툴을 쓰고 적절한 질문을 하며 우선순위를 매길 줄 안다.**

### 뛰어난 개발자는 적절한 도구를 찾아낸다.
“내가 8시간 안에 나무를 베어야한다면 내 도끼날을 가는데 7시간을 쓰겠다.” / 링컨

평범한 개발자는 무딘 도끼로 8시간 동안 나무를 벨지도 모른다. 뛰어난 개발자는 한 시간만에 잘 드는 전기톱을 고를 것이다. 그리고 5분 후 나무를 다 벨 것이다.  
평범한 개발자들이 자주 하는 실수는 무작정 코드부터 친다는 것이다. 그들은 자기가 아는 기술 하나로 모든 상황을 처리하려한다.

저자가 한 개발자에게 개인 웹사이트를 만들어보라고 했을 때 그는 그렇게 말했다.
"학교에서 리액트 앱 만드는 법을 배웠어서 그걸로 기초를 만들었어. 근데 이미지랑 CSS를 제대로 배치하는게 어려웠고, 
나는 배포하는 법도 몰랐어. 그래서 AWS에서 커스텀 배포를 하려고 했는데 콘솔 쓰는게 또 좀 헷갈리더라. micro 인스턴스는 뭐고 large 인스턴스는 또 뭐야?"

이때 이 개발자가 놓친 것은 이런 게 있다.  
- 요구사항 정의: 검색엔진 최적화, 댓글달기, 템플릿 등에 대한 이야기가 없음
- 대안: 그는 리액트와 AWS만 알았고 그것밖에 생각하지 못했음.

### 뛰어난 개발자는 도움을 요청한다.
몇몇은 뛰어난 개발자가 고독한 천재라는 오해를 하곤 한다. 문제를 안고 속으로 끙끙대면 해결책이 나타날 거라고 생각한다. 

팀 동료에게 질문하면 5분만에 해결될 문제를, 코드가 사골국이 될 정도로 고민하는 이들이 많다. 
그러나 **도움을 요청할 줄 아는 적은 경력의 엔지니어가 절대 도움을 요청하지 않는 능력있는 엔지니어보다 낫다.** 
도움을 요청할 땐 문제 해결에 도움이 되는 추가 맥락을 설명해주면 좋다. 예를 들어 '코드를 왜 이런 구조로 짰는지', '어디서 불러오는 API인지', '배포는 어떻게 이루어지는지' 등이 있다.

### 뛰어난 개발자는 비즈니스 가치를 이해한다.
뛰어난 개발자는 일이 일종의 투자라는 것을 안다. 그리고 그 투자로 얻는 수익은 그들이 공들인 시간보다 더 큰 가치를 가져야한다. 
기회비용을 이해하고, 구현할 수 있는 기능을 전부 구현하는게 아니라 가장 효율적이고 효과적인 기능을 추려낸다.

## 결론은 소프트 스킬이다.

**"유능하지만 재수 없는 놈(jerk)을 그냥 냅두지 마세요. 팀워크는 너무나 중요합니다."** / Netflix CEO

이외에도 결국 최강의 개발자를 결정하는 것은 바로 소프트 스킬이다. 
개발을 잘 하는 것보다 재수 없는 놈(jerk)이 되지 않는게 더 쉽다. 쓸데 없는 자존심때문에 우리의 노력이 물거품이 되지 않도록 하자. 

엔지니어는 무엇보다도 가치를 우선적으로 전달해야한다.


## 느낀 점

첫번째로 저자가 언급한 '적절한 도구 찾기'는 내가 최근 들어 가장 절실히 느끼고 있는 것이었다.  
개인 블로그를 만들면서 지킬로 했다가 리액트로 했다가 다시 지킬로 돌아왔다가... 배포를 AWS로 할까 했다가 다시 깃허브 페이지로 돌아오고... 
적절한 기술을 찾아보고 선택해서 개발을 시작하는게 무작정 시작하는 것보다 더 시간을 절약할 수 있었을 텐데 말이다. 
이제 슬슬 삽질을 줄이려고 노력해야겠다. 

그 방법은 더 많이 찾아보는 것과 기술, 배경 지식을 더 깊게 이해하는 것. 
구독하고 있는 위클리 뉴스레터들을 대충 훑을 게 아니라 흥미로운 게 있으면 들어가서 공식문서도 좀 자세히 볼 것.

또 내 블로그에도 개선하고 추가해야할 기능이 많은데, 이것들도 좀 리스트업을 해봐야겠다.
내 시간과 에너지의 기회비용을 생각하며 꼭 필요한 기능을 추가해나가자.


미디엄의 한 글을 읽고 밑줄 치고 싶었던 문장들을 적어본다.

'최고의 개발자가 되는 법'을 읽고 


[테헤란벨리 / 백엔드 vs 프론트엔드 비교 영상](https://youtu.be/S9qAtvvvxio)을 보았다.  
등장인물들의 개인적 의견이지만 어떤 분야를 팔지 고민하고 있는 나같은 사람을 위해 정리해서 올려본다.

## 프론트

- 코드의 유효 기한이 짧음 (n개월인 경우도 있음)
- 코드의 유효기간이 짧다 보니 추후에 유지보수가 쉽도록 하는게 별로 도움 되지 않음 
- 백엔드에 비해 '성능을 좋게 할 방법'을 고민하는데 쓰이는 시간의 중요성이 낮음. 그래도 이 고민을 통해 나온 결과물은 써보면 티가 난다(e.g. 토스의 웹뷰)
- 기획, 디자인 등의 이유로 바뀌는게 엄청 많음
- 백엔드나 다른 분야에 비해 변화가 극심하게 빠르다 (**학습에 즐거움을 느끼고 변화에 스트레스 안 받는 타입**이 좋음)
- 채용 수요가 가장 많다. 이에 비해 팀장급 이상 개발자가 적다.
- Bleeding Egde: 최첨단
- 역사가 없어 뭐가 더 나은지에 대해 이야기할 때 진영이 나뉘므로 **다양한 의견을 듣고 시도해보길 즐기는 사람**이 프론트엔드 개발을 하는게 좋다.

### 프론트엔드 개발자는 화면에 보이는 모든 것을 만든다. (정재남 님)

- html, css, js를 이용해 마크업 화면에서 이루어지는 애니메이션과 인터랙션 구현
- UI 성능 최적화
- 서버에 데이터 요청하고 응답을 받아서 화면에 뿌려주기 (XMLHttpRequest, 웹소캣, 쿠키, 로컬스토리지, 세션스토리지)

보통 문제가 생기면 디자이너나 기획자가 제일 먼저 찾는 사람이 **프론트엔드**. 
프론트엔드가 원인을 파악하고 백엔드로 넘겨주는 경우가 많음. => **커뮤니케이션 스킬**이 중요!

### 프론트엔드 개발자 전망

- SPA 시대가 되면서 템플릿 언어까지 프론트엔드가 맡는 경우가 많아짐.
- GraphQL 등 데이터를 직접 가공하는 일까지 넘어오는 추세
- 데이터 캐싱, 라우터 관리 등 업무 영역이 넓어지고 있음

## 백엔드 

- 백엔드 개발에서는 기술적 성능을 높이면 돈으로 직결된다. (프론트에서는 성능이 좋아져도 차이가 미묘한 경우가 많음)
- 추상적 사고력 중요 (완전 추상화된 세계)
- 설계를 지루해하지않고 트래픽이 늘었을 때를 상상해 설계할 줄 알아야함
- 백엔드 기술의 발전, 역사를 알고 기술이 어떻게 전 기술을 보완하며 발전했는지 파악하면 이해가 쉬움

## 나의 결론

위 영상에 나온 바로는 나는 앞구르기뒷구르기 프론트엔드 개발자...   
내가 변화, 새로운 것을 좋아한다고 해도 너무 빠르게 발전하니까 좀 압도당할 때가 있었는데   
여전히 더 고민해봐야할듯...ㅎ

유튜버 테헤란밸리와 정재남 님의 글을 요약 정리해봤다.

백엔드 vs. 프론트엔드. 개발자 적성 찾는 법과 신입 프론트엔드 개발자가 해야할 일


## 국비학원 이틀차 일기

1. 개발학원 이틀째... 개발하기로 맘먹은 이유는 나한테 있어 시간이 제일 빨리 가는 활동이라,,  
   원래 집중 길게 못하는데 프로그래밍 공부할땐 최소 한시간은 숨만 쉬고 하기 가능,,

2. 가장 먼저 든 생각은 눈빛 tells everything.  
   특히나 이런 코로나 시대에선... 마스크때문에 얼굴에서 보이는 건 이마랑 눈뿐이니, 눈빛으로 살아있음ㅋㅋㅋ을 말하는게 중요하지 않나 싶다.
   입은 웃고 눈은 안 웃는 상황 이제 불가능이니까. 그래서 학원 둘째날부턴 커피 때려넣고 선생님 눈 계속 쳐다본다.  
   마스크 끼고/실내에서/조별과제 없이 새 친구 사귀기 여간 쉬운게 아니다.

3. 지금은 자바랑 SQL을 배운다. 코딩을 배우기 시작한지 1년 반 됐는데 그동안 기초를 열심히 다져서인지 쉽다.
   sql은 r이랑 비슷한 것같기도하고 직관적이라 좋다. 깃헙도 그냥 튜토리얼 따라서 하고 이해 못한채로 명령어만 쳤었는데
   이제는 그 원리와 용어들을 배워서 안다. 공부할 맛 나고 만족스럽다!

4. 학원 이틀차부터 어깨가 부서질 것같길래 앞으로 8개월은 계속 컴퓨터 앞에만 앉아있어야하는데 ㅠ 싶었다.
   근데 느껴보니 내 가방이 너무 무거워서 그런거였던 것..!  
   기차역-학원까지 편도 30분씩 걸어다니는데 내가 빨리 걸어서 무리가 가는것 같았다.  
   그래서 금요일엔 가방을 메지 않고 품에 안고 갔는데 훨씬 괜찮아짐. 이제는 공유 자전거를 빌려서 가방은 바구니에 넣고 다니려고 한다.
   시간도 편도 20분씩은 절약되고 자전거 타니 기분도 더 좋아지겠지

5. 점심 먹고 오후 수업 시작하기 전까지 계속 산책한다.  
   아침이나 주말에 달리기도 최대한 하고 있는데 왜 공부하려면 체력이 중요하다는지 알겠고...
   그래야 주5-6일 수업 버틸수 있다 고딩때는 심적으로도 압박이고 하니 책상에 안 앉아있으면 불안했는데,
   지금은 휴식과 충전의 중요성을 알겠다. 꾸준히 잘 해바야쥐,,,

### 한 달간 기억에 남는 것

- 학원에서 깜짝 SQL 시험 본 것과 자바의 상속(inheritance) 
- SQL emp, dept 테이블에서 `WHERE dept.deptno != emp.deptno `를 하면 행이 몇개가 나오냐는 문제였다. 
어떻게 저런데 조인을 하지? 했다가 14*3 = 42로 고쳤다. 
- inheritance가 기억에 남았던 이유는 내가 자바 코드를 읽을 때 extends 가 나오는 부분을 많이 봤는데 그게 상속 기능이었다는 것을 드디어 알았기 때문이었다.

### 낯설었던 것

이번주 초에는 객체지향이라는 것을 아직 이해하지 못한 상태였다. 
메소드는 함수같이 쓰이는 것이다-는 알고 있었지만 클래스를 어떨 때 써야할지 몰랐는데 과제로 프로그램을 만들어보고 
계속 써보면서 이해했다. 클래스 안에 메서드가 들어가고 메서드는 그 클래스에서 사용할 함수들을 표시해주는 것.

### 유용해보이는 것

자바의 상속. 비슷한 클래스를 여러개 쓸 필요 없이 상속받아 쓸 수 있다는게 유용해보인다. 
`super()`로 parent class의 생성자를 불러올 수도 있는데 이것도 자식 클래스에게 새로운 옵션을 주는 것 같아 유용해보임.


국비 개발학원에 다니기 시작했다.

성장

'성장'에 관한 글들을 모아봤어요.