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

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

였다.

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

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

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

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

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

📝


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

잡부 개발자면 안되는 걸까


![](/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월 요즘의 생각


## 첫번째 원동력: 사람

파스토에 다닌지 약 5주가 지났다.  
이직 회고를 작성해 소셜미디어에 공유했었는데, 어느날 이런 디엠이 왔다.

![대화1](/images/blog/2208/meet1.jpg)
![대화2](/images/blog/2208/meet2.jpg)

전 회사에서 며칠 함께 근무했던 분이 그 글을 보시고, 연락을 주신 거였다!  
나보다 몇개월 먼저 퇴사하셨었는데, 내 글을 보고 이직을 축하한다는 메시지를 주셨다.
개발자 세상이 좁다는 건 알고 있었지만 이렇게 다시 실감할 줄이야.

그와 더불어 그때의 내가 악조건(와이파이와 인터넷이 불가능한 내부망, 프로젝트 담당 공무원이 계속 바뀜 등등)에도 불구하고
눈이 반짝반짝했다는 이야기를 해주셔서, 지금의 나는 이때의 열정과 마음가짐을 잃지 않았는지 다시 한번 생각해보는 기회가 되었다.

사실 그때 힘든 환경에서 개발하는게 마냥 쉽지만은 않았지만,
그 경험덕분에 앞으로 어떤 환경이 주어지더라도 빠르게 적응해서 프로덕트를 만들어낼 수 있을 것이다.  
쉽지 않은 상황에서 나에게 가장 큰 원동력이 되어주는 건 바로 같이 하는 `동료들`이다.

## 두번째 원동력: 성취감

지금 회사에서는 지라로 업무 관리를 한다.
내가 맡은 업무의 설명과 개발 기간, 상태, 관련된 인물 등 업무 정보를 입력하는걸 '지라 티켓을 딴다'고 한다.
개발 진행상황을 계속 지라에 업데이트하는데... 이 지라 티켓을 관리하는게 너무 재미있다.

### 지라 재밌어요. 왤까요?

#### 1. 업무 상태를 바꿀 때의 손맛

할 일을 지라 티켓으로 배정받고 하나하나 끝낼 때마다 지라 티켓 상태를 `진행 중`에서 `개발 완료`로 바꾼다.
아이에게 성취감을 주려면 일을 잘개 쪼개서 작은 성취를 여러개 맛보게 하라고 했던가. 지라 티켓 상태를 바꿀 때가 바로 그렇다.
손맛이 있다. 꽤 큰 심리적 보상으로 다가온다.

#### 2. 내가 한 일을 정량적으로 체크 가능

지라에는 스토리포인트(`SP`)라는 '해당 업무를 끝내는데 얼마의 시간이 걸리는지를 산정하는 지표'가 있다.
`SP`는 담당자가 아니라 개발자 평균을 기준으로 산정된다.
지라 내 쿼리문을 작성해 내가 한 달동안 완료한 스토리 포인트를 조회할 수 있다.
1점이 반나절 기준이니 만약 8월에 SP 40점만큼의 일을 완료했다면 20일치의 일을 했다고 볼 수 있다.

## 결론: 사람과 성취감이 내 원동력이다

결론적으로 직장인으로서의 나를 `move forward`하게 해주는 가장 큰 두가지는 사람과 성취감이다.  
외향적인 성격이란 자기 외부, 즉 사회와 사람에게서 힘을 얻는 성격이라고 했는데 내가 정말 그렇다.
함께 성장하고 의견을 나눌 수 있는 동료들을 만나 긍정적인 피드백을 주고받는 게 생각보다 큰 힘이 된다.

앞으로도 성취감과 생산성을 높게 유지할 방법을 계속 찾으면서 **지속 가능한 개발, 회사 생활**을 해야겠다.
직장인 생활 1.5년차... 직장인으로서 나만의 스트레스 해소법과 동기부여 방법을 찾아가고 있는 것 같아 기쁘다.


직장인으로서의 나를 계속 앞으로 나아가게 해주는 원동력은... (더보기)

My biggest motivation


## 3월

### 16일: 이력서를 쓰고 그대로 사는게 더 쉽다

예전에 누군가 '이력서를 나중에 쓰는 것보다 먼저 쓰고, 그대로 사는 게 더 쉽다'고 한 적이 있었다.  
그때는 그게 도대체 무슨 말인가 했는데, 어제 이력서를 쓰면서 100000퍼센트 이해했다.

그 의미는 바로... '이력서를 쓰면서 내가 부족한 것을 파악하고, 그걸 해내라'는 거였다.

### 22일: 운영체제 스터디가 끝났다.

스터디 방식은 한 챕터씩 강의를 듣고 각자의 방식으로 정리한 뒤, 매주 수,일요일 저녁 9시에 줌에서 이야기를 하는 것이었다.
각자 돌아가면서 인상깊었던 것과 생각을 말하고 퀴즈를 내고 함께 풀었다.

시간이 남으면 수다를 떨었는데 나뺴고 다 백엔드개발자셨다. 덕분에 백엔드 기술 이야기를 많이 들었다.
스터디하면서 리눅스 코드에서 세마포어를 어떻게 구현했는지 보기도 하고 깃허브로 남의 코드를 보는 재미를 알게 되었다.

### 22일: 약 35일간 체지방 2.5kg 뺐다.

일련의 기준을 충족하는(새벽오픈, 집에서 가까울것, 인클라인 기능 있는 트레드밀이 있을것) 헬스를 등록해서 자주 다녔다.
다행히 근육은 0.2kg만 빠졌다. 근력운동을 유산소보다 더 많이 했는데. 역시 체지방 빼는 것보다 근육 늘리는게 더 어렵구나! 더 건강해지자 아좌아좍

### 29일: 짱 맛있는 초콜릿 발견

![chocolate](/images/blog/2203/choco1.jpg)
(얼마전 미친 맛으로 나에게 큰 행복이 되었던 기라르델리 씨솔트 아몬드 다크 초콜릿)

새로운 음식 먹어보기, 새로운 나라 여행하기, 새로운 사람 만나기.
모든 인간과 음식, 나라, 물건이 새로운 이야기를 가지고 있고 그런 이야기(& 의견)을 알게되는건 정말 즐거운 일이다. 결국 내 사고의 확장으로도 이어진다.

### 31일: 'MessageToMe'팀 첫 워크샵

![게더타운](/images/blog/2203/workshop2.png)

게더타운에서 MessageToMe 팀 첫 워크샵을 했다. 프로젝트를 하면서 회의는 자주 했지만 실제로 얼굴을 드러내고 사적인 이야기를 한 건 처음이었다.

## 4월

### 1st April Fool's day

![스택오버플로 테마](/images/blog/2204/so1.png)

아침에 에러 고치러 스택오버플로 들어갔는데 이렇게 보였다! ㅋㅋㅋ 만우절이라 그런 것 같았다.
해결방법 찾으려고 화면 뚫어져라 보다가 가뜩이나 안 좋은 시력 더 나빠질뻔!
보니까 테마가 추가돼서 저런 어지러운 테마부터 페이스북 느낌, 터미널 느낌까지 다양했다.

### 6th 메타인지

![지식](/images/blog/2204/know.JPG)

개발자가 되고 다른 사람들의 지식에 감탄하면서 쭈구리 모드가 되곤 했는데, 힘이 되는 다이어그램이다.
개발자로 커리어를 시작한 이후로는 (물론 내 첫 **직업**이 개발자지만 ㅋㅋㅋ) 공부를 어떻게 할 것인가를 자주 고민하고 있다.
배우고 싶은 && 배워야할 게 많아서 그런 것 같다. 공부 방법과 방향 감각을 잃지 않아야한다.

![공부란 스키마를 닮아가는 과정](/images/blog/2204/learn.jpg)

친구가 보내준 이 트윗도 좋아한다. **공부는 나보다 전문적인 사람들의 스키마(신경회로 패턴)을 닮아가는** 과정.
**마법적인 지름길은 없고,** 꾸준히 접하고 따라해보면서 점차 비슷해지는 것이다!

그래서 예전엔 재미있어보이는&흥미로운 아티클들만 읽었다면 요즘은 시간을 내서 읽는 중이다.

### 20th 서울시립미술관 남서울미술관

![남서울미술관 내부](/images/blog/2204/southart3.jpg)

얼마전 서울 사당역에 위치한 서울시립미술관 남서울미술관에 다녀왔다.
벨기에 영사관으로 사용되었던 남서울미술관은 원래 종로에 있었다.
그러다 1979년에 남현동으로 이전이 확정되었고 벽돌과 석재, 나무 하나하나를 `해체`해 그대로 옮겼다고 한다.  
그 건물이 이전된 거라고 하길래 건물을 부수고 그 자리에 새로 지은 것도 아니고, 그대로 이전할 수가 있지? 생각했는데  
처음 그 건물의 설계와 이전 후 재건축(이축)을 위한 설계가 아주 철저히 이뤄졌기 때문에 가능한 거였다.

미술관 내부를 구경하면서 안정적인 이전을 가능하게 한 건축가들의 장인정신을 느낄 수 있었다.
`소프트웨어 장인`이라는 책이 떠올랐고, 덕분에 내가 이런 멋진 공간을 즐길 수 있구나 싶었다.
층고가 높은 건물을 사랑하는데, 채광도 좋고 삐걱거리는 나무 계단도 참 좋았다.

### 25th framework

[자바스크립트 프레임워크 전쟁은 끝났다](https://news.hada.io/topic?id=6395&utm_source=weekly&utm_medium=email&utm_campaign=202217)

**최고의 프레임워크는 사용자 코드에서 자신을 제거하는 프레임워크**

정말 맞는 말이다!
사용자가 프레임워크만의 문법을 덜 쓴다면 나중에 다른 개발자가 유지보수할 때도 읽기 쉽고  
또는 다른 프레임워크로 옮겨가야할 때도 편하다.

(별개로, Geeknews weekly를 몇주째 구독중인데 내가 지금 받아보는 뉴스레터 중 가장 재미있고 깔끔하고 읽기 쉽다.  
운영자분들 적게 일하고 많이 버십시오~~)

## '별말,씀' 프로젝트 & 협업의 어려움

요즘은 퇴근 후에도 '별말,씀' 프로젝트를 계속 개발 중이다.  
깃랩으로 작업하고 있어서, 깃허브 잔디에 소홀해진 게 아쉽다
팀원들이 깃랩을 쓰자고 해서 쓰는 중인데 딱히 깃허브보다 나은 점은 잘 모르겠다(여쭤봐야겠다).  
프론트엔드 개발하면서 파트를 나눴지만 공통적으로 필요한 컴포넌트들이 있어서 공통 컴포넌트는 내가 다 개발하고 있다.  
이 컴포넌트가 어떻게 해야 여러 다른 점들을 포용하면서도 한 가지 기능& 스타일을 유지할 수 있을까 생각을 하게 된다.  
그래서 optional 변수를 명시적으로 적어둘 수 있는 타입스크립트가 더 유용하게 느껴진다.

그리고 기능별로 브랜치를 나눠서 작업하는데, 내가 브랜치 바꾸는 걸 자주 까먹는다.  
그래서 종종 `cherry-pick`을 한다.  
확실히 협업을 하니까 그만큼 컨플릭트도 더 자주 마주치지만 깃 명령어들과도 더 친해지고 있다.

주2회로 화요일엔 프론트엔드 회의, 목요일엔 전체 회의를 하는데 팀원 모두가 열정을 가지고 프로젝트에 임하고 있어서 나도 더 열심히 하게 된다.  
'별말,씀'이라는 이름이 어제 회의에서 정해진 우리 서비스의 정식 이름이다.  
잘 마무리되길!

이력서대로 살자, 협업의 어려움

생각

'생각'에 관한 글들을 모아봤어요.

잡부 개발자면 안되는 걸까

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

2023년 3월 요즘의 생각

My biggest motivation

2022년 3~5월의 짧은 기록