인프런 판교 퇴근길 밋업 with 개발바닥 참여 후기

퇴근길 밋업

가는 길

소개

인프런에서 주기적으로 크게 진행하는 행사인 판교 퇴근길 밋업에 드디어 선정되어 다녀오게 되었다!! 아직 학부생인데도 선발되어 정말 감사했고 좋은 경험이었다. 가서 보니 최종 지원자가 713명이었고 이 중 100명에 선발된 것!

특히 이번엔 블로그와 링크드인 통해서 알고 있었던 인프랩 CTO 향로님과 개발바닥 유튜브 운영하시는 호돌님이 진행하신다 해서 큰 기대를 안고 갔었다.
일정은 개발바닥의 고민 상담 이후 식사하며 네트워킹 순서로 진행되었다.

이번에는 특정 주제가 있는 것이 아니라 다양한 개발자 분들의 고민을 미리 신청할 때 받아 10개를 추려 향로님 & 호돌님이 직접 답변해주는 방식이었다.

그런데 두 분 다 오랜 개발 경력 동안 쌓인 게 많으셨는지 답변을 진짜 줄줄이 계속 해주셔서 10개 중 6개밖에 못 끝냈다. ㅋㅋㅋㅋㅋ

뭔가 유명인의 유튜브 라이브 직관하는 기분도 들고 두 분 다 말씀도 잘하시는데다 내용도 알차서 도움이 진짜 많이 되었다. 주로 업무 분야나 커리어, 개발 문화 등의 고민이 있었고, 좋은 말씀들을 많이 해주셔서 기억에 남는 내용 위주로 정리해 보려 한다.

판교 스타트업캠퍼스

준비하시는 개발바닥 분들

---

보상과 커리어

이직으로 보상을 높이는 것과, 한 회사에서 근속하는 것 중에 어떤 것이 좋을까라는 첫 질문이다.

자신이 성장할 수 있는 방향을 선택하자

두 분 다 처음에는 엄청 낮은 연봉으로 시작하셨지만 여러 번 이직을 하신 커리어를 갖고 계셨다. 하지만 연봉이 꾸준히 높아진 것은 아니고, 오히려 연봉을 깎고 이직한 경우가 많으셨다.

경제적 자유는 회사의 직원 신분으로는 얻기 힘들고, 낮은 확률이더라도 어차피 창업의 길로 가야 한다. 그렇다면 자신에게 도움이 되는 방향으로 행동하는 것이 어떨까라는 이야기를 해주셨다.

오랫동안 개발자로 일하려면 돈보다는 재미와 흥미가 있어서 일을 해야 하는 것 같다. 무슨 일이든 마찬가지겠지만 흥미 없이 생계를 위해, 돈을 벌기 위해서만 일하는 것은 너무 슬픈 미래일 것이다.

아직까지 개발이 재밌어서 다행이라는 생각이 들었고, 물론 회사에서 오래 일하면 생각이 달라지겠지만 지금은 빨리 회사에서 주위 좋은 동료들에게 많은 것을 배우고, 기여도 하고, 서비스 출시하고 QA와 사용자 피드백도 받아보고 싶다는 생각이 든다.

---

일과 삶의 적절한 배분과 권태기 극복

일상적인 삶과 개발 관련 자기계발 시간을 어떻게 배분하면 좋을까에 관한 두 번째 질문이다.
질문 중간에 개발바닥 분들은 권태기를 어떻게 극복하나요? 라는 질문도 있었다.

유독 개발 분야가 퇴근하고 나서도 공부해야 하고 계속 바뀌는 기술 트랜드를 따라잡으려면 평생 공부해야 한다는 말을 많이 들어온 듯하다.

또 업무 시간 외에도 이슈 터지면 일단 빠르게 해결해야 하는 개발자 특성 상 일과 삶을 명확히 구분짓기 쉽지 않을 거 같은데 10년 넘게 일하신 두 분은 어떻게 하는지 궁금했다.

처음부터 회사 외적으로 뭔가를 추가로 공부하기보단 회사에 조금 더 빨리 가서 코드를 읽어본다거나 (정해놓고 가는 게 아니라 오늘은 쫌 일찍 일어났네? 하는 날에만.. ㅋㅋㅋ), 회사에서 Java spring이 아닌 php로 작성된 코드도 공부해본다거나 하는 방향으로 말씀해주셨던 것 같다.

그런데 두 분이 취미가 개발 블로그 글쓰기에 남는 시간에 개발 유튜브 운영하시는 모습을 가만 보니, 개발이 이미 삶의 일부가 되어 굳이 일과 삶을 구분할 필요가 없을 정도로 잘 섞여서 살고 계신게 아닌가 하는 생각이 들었다.

다른 취미로 열정 돌려놓기 & 시간 정해 놓고 그냥 하기

권태기 극복과 관련해서는 향로님이 열정의 아궁이 이론을 설명해주셨다.

아궁이 불씨를 꺼뜨리지 않기 위해 지속적으로 이곳 저곳으로 불씨를 옮겨놓는 것처럼, 열정의 불씨도 꺼뜨리지 않기 위해 꼭 개발이 아니라 다른 취미에도 주기적으로 열정을 옮기는 것이 필요하다는 거다. 이렇듯 개발에 열정이 식었다면 방향성은 달라도 열정은 꺼지지 않게 다른 곳에 잠시 옮겨두라는 것이다.

그런데 정작 자신은 이렇게 하지 않고, 하기 싫어도 시간을 정해 놓고 그냥 한다고 하셨다 ㅋㅋㅋㅋ

---

회사에서 다른 분야 학습 & 인프라의 중요성

희망 분야와 회사 입사해서 맡은 일이 다른 분야일 때 어떤 방향으로 나아가면 좋을지에 대한 세 번째 질문이다.

배우는 분야에 제한을 두지 말고 현재 배울 수 있는 것에 집중하기

백엔드 서비스를 희망해서 입사했는데 ai나 devops 쪽 일을 하는 중이라 백엔드 쪽을 더 배우고 싶은데 어떻게 해야 할지 고민이라 하셨다.

글머리로 표시된 것이 답변 내용들이고, 화살표는 개인적인 생각이다.

• 배우는 분야에 제한을 두지 말고 현재 회사에서 배울 수 있는 것에 집중하는 것이 중요하다. 회사에서 할 수 없는 건 집에서 해보면 좋다.
• 주니어 때, 사고쳐도 괜찮을 때 CI/CD, 모니터링 부터 인프라단까지 다 만져보고 돌려보는 것이 매우 좋은 기회다.
• devops, 인프라는 컴퓨터 구성을 파고들어가는 반면 애플리케이션은 점점 추상화를 쌓아올려 사람과 가까워지고 있다.

→ 이 말이 정말 공감되었다. ChatGPT 가 나온 이후 이제 개발이 거의 자연어 단계까지 추상화가 되고 있 상황에서, 과연 개발자로서 차별성을 어디서 찾아야 하나 고민 중이었는데 인프라를 잘 아는 개발자가 되면 확실한 차별성이 갖춰지지 않을까 싶다.

 

• 옛날 SSR은 서버 단에서 다 뿌려줬는데 현재는 Next로 프론트에서도 배포, 모니터링, 네트워크 구성, 소켓 등 다 해야 하는 상황이다.
• 저연차 때 인프라를 많이 다뤄봐야 고연차 때 폭발적인 성장이 가능하다.

→ 과거엔 서비스 구현하려면 온프레미스로 다 만들면서 인프라 다뤄야 했지만 요즘엔 클라우드 서비스도 많고 추상화가 많이 된 듯하다. 오히려 클라우드로 인프라가 추상화 되면서 개발자들이 인프라에 직접 접근하고 잘 이해해야 더 잘 쓸 수 있는 상황이 되었다고 느껴졌다.

 

• 장애가 났을 때 코드만 보느냐 전체 인프라를 다 보느냐 큰 차이가 있다.
• 깊게 가려면 처음에 넓게 파야 한다. 장애가 났을 때 해결하려면 결국 넓게 봐야 하니 주변에 보면 넓게 파는 사람들이 많다. 운영 쪽을 아는 사람부터 시니어로 부르기 시작한다.
• 향로님 신입 뽑을 때도 그냥 백 프론트만 해온 사람보단 네트워크, 인프라 경험 있는 사람 선호한다.

→ 신입인데 어떻게 네트워크, 인프라 경험을 쌓냐구요.. 이런 측면에서 정보보호병으로 전산실에서 일했던 경험이 진짜 운이 좋고 귀중한 경험이라 생각한다. 맨날 주무관님이 농담 삼아 7계층 짜식들이라고 불렀었는데 확실히 2, 3 계층까지 내려가서 네트워크 만져보고 실물 서버 접속해서 관리해보는 경험은 흔치 않다는 것을 사회 나와서 더 체감했다. 이때도 뭐가 크게 안되는 경우는 인프라 문제인 경우가 꽤나 있었고, 열심히 뛰어다니면서 해결했으니 말이다. 깨진 광.. 고장난 광컨.. 안되는 스위치 포트..

---

공부하는 방법

책을 통해, 온라인 강의 수강, 야생으로 검색해가며 뭔가 만들기 중 어떤 방법으로 성장하시나요? 라는 네 번째 질문이다.

향로님은 역시 파워블로거답게 오픈된 공간에 글을 쓰고, 많은 사람들이 보고 수정할 수 있는 상황에서 기술적인 글을 쓰며 큰 성장을 이뤘다고 하셨다.

공부한 내용을 회사 슬랙이나 블로그에 쓰고, 반박을 받아 수정하는 과정을 지속적으로 거치면서 실제로 된다는 것을 보여주기 위해 쿼리 성능 같은 테스트도 직접 많이 해보게 된다셨다.

공개된 공간에 글을 쓰고, 반박을 받아 수정해보자

이 말을 듣고 감명받아서 나도 몇 달간 방치했던 블로그에 다시 글을 올리기 시작했다.

호돌님은 어떤 앱, 서비스를 만들 목적이 있어야 한다는 말을 해주셨다. 책은 초반에만 보고 이후엔 그 목적을 위해 직접 짜면서 검색으로 문제해결 해나가는 방식을 선호하는데, 파생되는 것을 계속 타고타고 내려가면서 배우면 결국 완성은 못하더라도.. 공부는 많이 된다고 하셨다.

---

좋은 개발 문화

기존엔 좋은 개발 문화란 개발자가 개발에만 집중하게 해주는 것이라 생각했는데 개발만 해서는 일하기 힘들고, 타 부서와 협업하는 시간이 길고 협업 능력도 중요합니다.
이에 대해 개발바닥은 어떻게 생각하시나요? 라는 다섯 번째 질문이었다.

내가 만들어가는 좋은 회사 문화만이 있을 뿐이지, 좋은 개발 문화가 따로 있는 것이 아니다.

호돌님은 회사 출근하자마자 문화에 포함되는 것이라 해주셨다.
내가 하는 것도 기존 회사 문화에 영향을 미치고, 회사 문화에도 영향을 받는 등 내가 회사에서 행동하는 모든 것이 문화에 포함되는 것이라는 말을 해주셨다.

향로님은 모든 직군이 직군 자체에만 집중할 수 있는 환경을 만들어주면 회사가 성장 가능한가? 라는 질문을 던지셨고, 이렇게 되면 회사가 성장 불가능할 것이라고 답하셨다.
마찬가지로 개발자가 개발에만 집중하려면 다른 직군이 맞춰줘야 할 수밖에 없고, 그러면 좋은 회사 차원에서 좋은 서비스를 제공하기는 불가능하다고 대답하셨다.

• 회사의 목적은 좋은 서비스와 제품을 만들어 판매하는 것인데 이를 위해선 제품 조직의 성장이 필요하다.
• 서비스 장애가 많이 난다면 다른 부서들도 개발 조직에만 서포트하는 것이 맞다.
• 그런데 서비스 장애가 없고, 현재 기술 부채는 떠안고 갈 만하다면 개발자는 다른 조직을 서포트 해주는 것이 맞다.
• 조직과 현재 만들고 있는 제품이 성공하려면 좋은 회사 문화만 있을 뿐이지 좋은 개발 문화가 따로 있는 것이 아니다.
• 어느 정도 궤도에 오른 대기업은 사업 부서가 힘들고, 여기에 중점이 맞추어져 있다.
• 초기 스타트업은 디자인, 서비스 마케팅 팀에서 바이럴을 일으켜야 해서 도움이 필요하다.
• 스타트업 중반에 성장하며 서비스 확장해야 해서 기술 부채 개선이 필요할 때 개발 부서가 힘들고 서포트 받아야 한다.
• 하지만 이 시기만 찾고 개발자 지원만을 바라면 안된다.

→ 두 분 다 CTO이셔서 그런지 보는 시각이 개발 팀을 넘어서 회사의 지속가능함에 초점을 두고 계셔서 정말 좋았다.

→ 이전에 모의면접을 봤을 때 지원자님은 어떤 회사에 들어가고 싶나요? 라는 질문에 막연히 좋은 개발 문화가 갖춰진 회사에 들어가고 싶습니다. 라고 답변했었고, 이에 대해 개선이 필요하다는 평을 받은 적이 있었다. 그동안 나도 개발자 입장에서만 좋은 개발 문화에 대해 생각했었는데 이 통찰력이 담긴 대답들을 듣고 시야가 넓어진 기분이다.

---

성장하는 개발 문화를 만들 수 있는 방법

성장하는 개발 문화와 조직 문화를 어떻게 효과적으로 만들 수 있을까요? 근데 이제 시니어 부재를 곁들인.
이라는 여섯 번째 질문이다.

주변 사람들과 문화를 바꾸는 사람이 되자

향로님이 시니어가 있을수록 오히려 좋은 개발문화 만들기 힘들 수 있다, 주니어들끼리가 좋은 개발문화 만들기 쉽다라고 말씀해주셔서 의외였다. 그런데 이유를 듣고 나니 이해가 되었다.

• 연차가 쌓일수록 실패경험이 많이 쌓이고 이는 레퍼런스가 된다. 일반적으로 해도 안될거라거나 이미 실패해본 경험이 있거나 왜 하느냐는 질문이 나오게 되고, 이에 주니어는 시니어 개발자를 설득하기 힘들다.
• 신입일 때 같은 신입들을 이상적으로 생각한 개발문화를 만들자고 설득하기가 쉽다.
• 나랑 비슷한 연차도 설득 못하는데 더 높은 연차인 시니어 설득이 훨 어렵다
• 향로님도 인프런 처음 시작할 때 원래 이렇게 하는 거야.. 라고 말하며 주니어 개발자들에게 새로운 개발 문화들을 도입해서 성공할 수 있었다고 하셨다 ㅋㅋㅋㅋㅋ
• 주변 사람들과 문화를 바꾼 사람. 이게 많은 회사가 찾는 사람이다.

호돌님은 문화 구성원인 자신부터 스스로 바꾸려 노력하는 것이 가장 중요하다고 말해주셨다.
코드리뷰만 막 도입한다 해서 좋은 문화일 수는 없고, 각자 관심사가 다르고 목표가 다 다르니 차분히 접근해서 천천히 바꿔나가는 것이 좋을 것이다 라고 해주셨다.

이도 공감이 많이 되는 것이 팀플할 때만 봐도 코드리뷰 필수로 한다 해도 결국 팀원들의 관심사가 코드 리뷰에 있는지 코드를 빨리 짜서 제출하는 것에 있는지에 따라 리뷰 퀄리티가 달라지고, 더 나아가 코드 퀄리티까지도 영향을 크게 받는다.
팀원과 많은 대화를 통해 각자 관심사를 파악하고 적절한 기준을 찾아 맞추어 나가는 것이 정말 중요하다 느꼈다.

---

네트워킹 시간

개발 분야에 맞게 12팀으로 나눠 주셨는데, 무려 백 8팀 풀스택 2팀 프론트 2팀이었다. 그 중 프론트 팀에 속해 흥미로운 이야기를 많이 듣고 왔다.

무려 1인 1피자와 음료가 제공되었다. 감사해요 인프랩~

오신 분들의 연차는 엄청 다양하셨다. 아직 학부생이라고 말씀드리니, 왜 프론트를 선택했냐는 질문이 바로 되돌아왔다…
학교만 해도 프론트 파는 사람이 별로 없는데 백엔드, 서버 분야가 아무래도 프론트에 비해 꾸준히 수요도 많고 사람도 많지 않은가 싶다.

React만 사용하는 분은 없었고, Next.js를 다들 도입해서 사용 중이셨다. 물론 app router와 page router는 반반 정도로 많이 갈렸는데, 특히 app router의 여러 오류에 대한 이야기가 오갔다.

최근 동아리와 프로젝트 하면서도 전역 상태 관리의 단점들에 관한 이야기가 나온 적이 있었는데 이 때문인지 기존 전역 상태를 다 뜯어내고 최대한 context API, zustand store 조금 정도로 사용하신다는 분도 계셨다.

마크업 개발자 분이 따로 계신 회사도 꽤 있는 것 같아 신기했다. 디자인 시스템 쪽을 담당해주시는 건지 CSS나 Sass로 뽑아주시는건지 궁금했는데 여쭤볼 기회가 없어 아쉬웠다.

또 다른 이야기로는 기억에 의존해서 틀린 내용일수도 있지만, 마크업 개발자 분은 sass 스타일을 한 곳에 모아서 관리하시는 것을 선호하시는 반면 프론트 개발자 입장에서는 그때그때 사용하기 좋게 styled-component 등을 필요할 때 만들어 쓰는 것이 편한 것이 아닌가라는 것이었다. 여기서 관점의 차이가 발생한다 하셨고, 토스 프론트엔드 파이트 클럽에서 들은 CSS vs. CSS-in-JS 이야기와도 겹치는 면이 있는 것 같았다.

호돌님이 테이블에 와주셨는데 마침 호돌님이 CTO이신 반려생활에서 프론트엔드 개발자 채용 중이기도 하셔서 어떤 분이 이직, 경력직 채용 시에 회사 코드는 대부분 볼 수 없으니 어떤 것을 주로 보고 뽑느냐고 질문해 주셨다.

호돌님 답변으로는 코드를 어떻게 짜는지는 확인할 수 있어야 해서 회사 계정 외에도 깃헙 잔디나 코드가 관리되어 있어야 하고, 그 외에는 프레임워크/라이브러리 등을 써본 경험이 있는지 질문할 것이라 하셨다.

---

소감

정신없이 이야기만 듣다보니 마지막에 링크드인 교환을 두 분 밖에 못해서 아쉬웠다.
내용적으로도 기술적으로도 정말 도움이 많이 되는 시간이었고, 학생입장에서는 더더욱 그렇고 회사 다니는 분들 입장에서도 다른 회사의 현직자 분들을 만날 기회가 드문데 이렇게 네트워킹 자리까지 마련해주셔서 아주 값진 시간이었다.