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

감사합니다.


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

발표

'발표'에 관한 글들을 모아봤어요.

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