홍익대학교 컴퓨터공학과 연합 DevTalk Seminar #1 후기

연합 DevTalk Seminar

지난 23년 8월 24일, 홍익대학교에 소속된 7개의 학회가 연합하여 연합 데브톡 세미나를 개최했습니다. 그리고 그중에는 제가 운영하는 B612도 포함되어 있습니다. 이전에 B612의 운영진 한 분을 연합 데브톡의 TF 팀으로 출장 보냈는데, 굉장히 잘 준비해주셨답니다. 신청폼이 나오자 마자 바로 신청했답니다.

카카오 메시지 사진 — 이렇게만 오간 것은 아니고, 저 사이에 조금의 협의들이 오가긴 했다.

그렇게 출장보내고 유기해놓고 있었는데, 중간중간 준비되고 있는 소식을 들으면서 굉장히 체계적으로 잘 준비되고 있는 게 느껴져서 많이 기대했습니다.

홍문관 지하 가람홀에서 진행되었습니다. 약 3-4백명 규모의 인원을 수용할 수 있는 시설인데, 사실 생각보다 많은 사람들이 모이지는 않아서 아쉬웠습니다. 약 80-100여 명 정도 모인 것 같았는데, 개강을 바로 앞둔 방학 중임을 고려하더라도 이렇게 세미나를 진행할 수 있는 자리가 결코 흔하지 않은데, 그렇게 많이 관심을 가져주지 않아서 아쉽긴 했습니다.

축사, 그리고 연합 데브톡의 의미

이번 데브톡은 의미가 굉장히 깊습니다. 홍익대학교 최초로, 7개의 여러 동아리가 함께 연합하여 기획하고 준비한 행사입니다. 작년까지 개발 동아리 자체가 거의 없던 홍익대학교에서, 이렇게 여러 동아리가 함께 개발에 대한 이야기를 서로 나누고 공유하는 자리를 만들었다는 것 자체가, 발전을 위한 중요한 발걸음이라고 생각합니다.

그러한 자리인만큼, 컴퓨터공학과 학과장이신 이혜영 교수님의 축사와, 컴퓨터공학과 학생회장 님의 축사가 있었습니다.

교수님 수업을 한 번도 못 들어봤는데, 되게 인자하고 좋은 교수님같다는 생각이 들었습니다.

연합 DevTalk Seminar의 Vision 그리고 준비 과정 - DevTalk TF Team

홍보 자료에 세미나(Seminar)가 아니라 세니마(Senimar)로 오타 있는게 포인트입니다

이건 미리 준비된 동영상으로 대체되었습니다.

영상에는 그 포함되지 않았지만, 데브톡 나름의 역사(?)를 이야기해볼게요. 원래 데브톡을 주기적이고 체계적으로 진행한 동아리는 작년 GDSC Hongik이 처음이었습니다(그전에 HIBL 등에서도 다른 연사를 부르는 등 DevTalk 활동을 계속하긴 했었지만, 아예 주기적으로 진행한 건 GDSC가 처음이었을 겁니다). 여러 번의 데브톡을 진행하였고, 특히 5회차부터는 온라인 한정으로 소수의 외부 인원에게도 공개된 채로 진행되었습니다.

그리고 23년 2월 GDSC Open Community의 출범 이후 7회차부터, 학교 전체를 대상으로 오프라인으로 DevTalk이 공개되었습니다.

그렇게 외부 공개 데브톡을 10회차까지 진행하다가, 이번에 규모를 더 키워서 연합 데브톡 세미나로 발전된 게 지금입니다.

좌: GDSC DevTalk #7 새싹 세미나 / 우: GDSC DevTalk #9

좌: GDSC DevTalk #10 / 우: 컴퓨터공학과 연합 DevTalk Seminar

이 내용은 어쩔 수 없이 특정 동아리가 많이 언급될 수 밖에 없어서, 모든 학회가 참여하는 연합 데브톡 세미나에서는 빠져 있었는데, 그래서 여기서 언급합니다.

대신 영상 속에는 이 데브톡 세미나를 구성하게 된 배경과 계기, 그리고 구성 과정을 녹여내고 있습니다.

가장 중요한, B612 소속 TF 팀 멤버의 인터뷰 내용을 들어봅시다.

연합 데브톡 세미나가 '홍익대학교 개발 커뮤니티 조성 및 발전에 기여하고자 기획되었다'는 점이 저희 학회가 지향하는 바와 맞아 합류하게 되었습니다.

B612 역시 학교 내 주니어 개발자들을 지원하고 개발 생태계 조성에 기여하는 것을 목표로 시작된 개발 커뮤니티인데요, 다른 학회들과도 힘을 합쳐 학우분들이 개발에 대한 생각과 경험을 자유롭게 말하며 함께 성장할 수 있는 개발 문화를 만들어가는데 큰 힘이 되고자 합니다. - GDSC TF 팀 소속 멤버의 인터뷰

어느 동아리나 사실 개발 문화를 활성화하겠다는 궁극적 가치는 동일할 것입니다. DevTalk Seminar는 이러한 이상을 실제 행동으로 보여준다는 점에서, 아주 높은 평가를 받을 만 합니다.

[keynote] 개발자의 지속적인 성장에 관한 이야기 - 박영웅 님

근데 보통 키노트 연사는 마지막에 하던데, 이번에는 그냥 처음부터 키노트 연사 발표로 때려버리더라구요?

박영웅 님은 첫 연합 데브톡의 키노트 연사로써, 개발자의 지속 가능한 성장이라는 주제로 50여분간 강연을 해주셨습니다.

가장 중요한 핵심 키워드로 지속성을 강조했습니다. 개발자의 마인드셋 중 가장 핵심이 되어야 하는 것이 지속성이라고 하셨는데, 맞는 말 같습니다. 원래 꾸준히 하는 것, 지속적으로 하는 게 가장 어려운 일이잖아요? 지속성을 유지할 수 있도록 스스로의 환경을 만드는 것이 성장에 있어서 중요한 밑거름이 될 수 있습니다.

개발자의 마인드셋

탄력적 사고

어려운 점이나 실패를 겪었을 때, 그 상황을 극복하고 회복하는 사고방식이 필요합니다.
즉 회복 탄력성을 높이는 연습을 해야 합니다.
원래 주니어 때는 멘탈이 들쭉날쭉합니다. 그러나 시니어 개발자는 멘탈이 나가도 수 일 내로 회복되며, 변화에 저항성을 갖는 안정적이라는 장점이 있습니다.
시간이 언젠가는 해결해줄 것이라 생각합시다. 끝은 언제나 좋게 마무리되는 법이고, 끝이 좋지 않다면 그건 끝이 난 게 아니라는 말이 있습니다.

비판적 사고

무조건적인 신뢰 대신, 비판적 사고를 가지고 검토와 분석 과정을 거친 후 스스로 혹은 다른 사람에게 질문을 통해 사고를 논리적으로 정리하는 단계를 거치세요.

좋은 질문이란 무엇일까요?

먼저 충분한 고민과 시도를 거친 후에, 질문해야 합니다.
충분한 정보를 전달해야 합니다.
1. 질문 후 사소한 역질문이 돌아오지 않도록, 첫 질문에서 충분한 정보를 전달해야 합니다. 정리가 어렵다면, 최소한 질문이 육하원칙에 근거하는지 확인하세요. 질문을 정리하는 과정에서 문제를 발견하는 경우도 많습니다.
신중한 접근
1. 이런 문제일거야! 같이 성급하게 문제 원인을 추측하지 않고, 다양한 가능성을 열고 신중하게 검토합시다. 성급한 추측 금지
코드 혹은 화면 공유
1. 질문할 때 일부 코드가 아닌, 프로젝트 단위 등으로 공유하고 의견을 받으세요. 화면 공유나 원격 제어가 가능하면 더 좋은 모습
부담 줄이기
1. 기초적인 질문을 할 때, ‘너무 기초적인 질문이라 질문하기 어려운데요…’ 하는 부담 없애기
확실한 보상

지속적인 호기심

새로운 기술, 지식, 도구 등에 대한 지속적인 관심과 경험을 유지해야 합니다.

기술 트랜드를 놓치지 않으려면?

끊임없이 새로운 정보를 받아들여야 한다고 합니다.

수용적인 자세

타인의 평가와 조언(코드 리뷰 등)을 긍정적으로 받아들이고 개선하는 자세를 가지세요.

방어 기제를 줄이려면?

항상 거짓없이 솔직해야 한다고 합니다.
이해해라 - 상대방에 문제가 있다고 해서 문제를 문제삼기보다, ‘그럴만한 사정이 있겠지’하고 이해합니다. 사정이 있었을 것입니다.

효과적인 학습법

자기주도학습

개인 스스로 통제권을 가지고 목표와 과정 등을 설계해야, 효과적인 자기주도학습을 진행할 수 있다고 합니다.

조건이 있습니다. 아래 조건이 충족되지 않는다면, 아무리 계획을 세워도, 결국 이행할 수 없습니다.

잘하고 싶고 잘해야 하는 마음이 드는가
뚜렷한 목표가 있는가
실무적 내용인가
지속 가능한가

방법:

목표 설정
정보 검색
일정 구성
검증과 실습
1. 간단한 예제와 프로젝트로 만들기
공유 및 의견 요청
1. 학습한 내용을 커뮤니티 등으로 공유하고, 다른 사람들의 의견을 주고 받기
2. 이러한 역할을 수행할 수 있는게 학교에선 동아리이죠

TIL (Today I Learned)

배운 내용을 다시 정리해서, 기억에 남기기

블로그에 작성하는 것도 일종의 TIL이라고 합니다.

블로그 작성

외부에 공유하는 걸 전제하기에, 다시 한 번 내용을 검토하게 됩니다. 아래 문구를 인용해주셨습니다:

Teaching is the best way to learn

실전 프로젝트 참여

프로젝트를 진행해서 학습한 기술을 실제로 적용해야 더 구체적인 기술 경험이 쌓입니다.

“아, 이렇게 사용할 수 있구나.” 하고 배울 수 있습니다.

시니어들은 언제 어떻게 학습할까

이들은 회사 프로젝트같은 곳에 신기술을 담습니다. 그 기술을 수행할 자신이 없더라도 일단 그 상황에 자신을 던짐으로써 학습을 강제하게 합니다. 프로젝트를 하면서 동시에 배워나가는 스킬입니다.

영상 시청 금지

유튜브 금지

클래식이나 재즈 등 가사가 없는 음악, 또는 화이트 노이즈 듣기

협업과 리더십

실무 개발은 혼자 하는 게 아닙니다. 협업을 위한 조언을 해주셨습니다.

효과적인 의사소통

정보의 사전 공유
- 상대방이 미리 정보를 알 수 있게 한다. 문서나 구두로 내용을 사전 공유
진지한 경청
질문을 통한 확인
간단명료하게 전달
비언어적 요소의 중요성

합리적인 의사결정과 문제 해결

문제인식
검토 및 전략 수집
실행
평가 및 조정

고민은 신중하게, 그리고 실행은 과감하게

실행 과정에서 발생하는 예외나 문제는 인정하고, 과감하게 밀어붙이기

리더의 역할

중립적인 위치에서 의견 조율하기
항상 겸손한 자세로 팀원의 이야기를 경청하기

일관성 있는 코드 작성

린터와 포매터 도입하기

이때 제가 린터와 포매터에 대한 글을 작성한 적이 있습니다.

상호 존중과 배려

상호 존중과 배려를 기본으로 설정하기

그 외…

그 외에도 후반부에는 여러 가지 이야기를 많이 해주었습니다. 세금 등 ‘이런 것까지..?’ 싶은 이야기도 있었는데, 한 가지 찔렸던 것은 바로 건강 관련 이야기였습니다…

연사 들으면서 굉장히 찔렸던 게, 제가 자세가 굉장히 좋지가 않거든요? 거북목이랑 굽은 허리가 굉장히 심한데, 연사 님께서 자세 교정에 신경쓰라는 말 듣고서 뜨끔했답니다.

거북목... 근데 저건 집중할 때 찍혀서 그래요, 평소에는 저것보단 덜하답니다.

안 그래도 오늘 연사 들으면서 옆에서 찍은 사진을 봤는데.. 저는 몰랐는데 남이 찍은거로 보니깐 진짜 기괴할 정도로 굽어있더라구요.. 당장 교정 치료부터 받아야겠습니다.

그리고 한 가지 팁도 받았는데, 어떤 활동을 하든 사진을 남기라고 합니다. 추억이나 회고 시에 사용도 가능하지만, 제일 중요한 것은 바로 증빙용으로 사용할 수 있기 때문입니다.

저도 그래서 최근에는 어떤 활동이든 사진을 남기려고 합니다. 동아리 활동이든 무엇이든 최대한 남기려고 해요. 역시 남는 건 사진 뿐인가 봅니다.

커뮤니티와 동반 성장하기 - 안재현 님

안재현 님은 GDSC Hongik을 처음 만들고 지금까지 이끈 1기 회장님이십니다. 400명 단위의 오픈 커뮤니티로 GDSC를 발전시킨 배경에 대해서 이야기합니다.

저는 개인적으로 발표 내용 중에 많은 부분이 공감이 됐습니다. GDSC에 비해서 규모는 작지만 같은 목적의 개발 동아리인 B612를 설립하고 운영하는 입장에서 많은 부분이 더 특별히 공감이 됩니다.

재밌는 점은, 발표가 끝나고 나서, 어느 한 분이 질문 시간에, 이전 세미나에서 발표하시는 거 보고서 많은 감명을 받았다고 칭찬하시더군요. 발표자 분 부끄러워하시는 거 재밌게 봤습니다.

커뮤니티의 설립 계기

서두는 홍컴의 한계에 대해서 지적합니다. 지금이서야 홍컴에도 많은 개발 학회가 생겨났지만, 21년도만 해도 홍컴에는 별도의 자체적인 개발 학회가 없었다고 합니다. 가장 큰 학회는 개발 학회가 아닌 알고리즘 학회인 HI-ARC가 전부였습니다.

이는 제가 입학했을 때인 22학년도에도 마찬가지로, 1학년이 쉽게 들어갈 수 있는 개발 학회가 없었던 것은 똑같았습니다.

그래서 주로 외부 연합 동아리로 많이 빠지게 되는데, 외부 연합 동아리의 경우 홍대만의 특색을 갖추기가 힘들기도 하고, 많은 경력과 경험을 요구하다보니 쉽게 들어갈 수 없는 게 사실입니다.

결국 순수 개발 만을 위주로 하는 개발 동아리의 필요성은 계속해서 대두되었고, 이게 GDSC의 설립 계기가 되지 않았나 싶습니다.

특히 홍컴에 개발 동아리가 많이 부재하다는 것도 많이 공감이 됩니다. 지금껏 이러한 조건과 환경을 벗어나려고만 하지, 직접 바꾸려는 시도가 많이 없었던 것도 사실입니다. B612 역시 초기 설립 이유 역시, 개발 동아리의 부재를 벗어나기 위해서 소수의 사람들이 모여서 시작한 폐쇄적 성격의 개발 소모임이었습니다.

결국에 홍컴이 스스로 발전하기 위해서는 그 안에서 자생적인 생태계가 구축되어야 합니다. 그래서 저는 홍컴에 지금보다 더 많이 개발 동아리가 생겨났으면 좋겠습니다. 솔직히 아직도 많이 부족하다고 느낍니다.

이러한 개발 동아리가 많이 생겨나야, 결국 스스로에게 더 나은 환경이 되도록 만들게 되는 시작이라고 생각합니다.

개인의 성장에 관해서

이러한 이념 외에도 사실 몇몇 개인적인 포인트들 역시 공감이 가는 부분들이 있었습니다. 우선 개발 학회장인데 개발을 못한다는 이야기도 많이 공감이 되었습니다.

저 역시 웹 개발 분야에 이제 갓 입문하여서 많은 것들을 배워나가는 중입니다. 그렇기에 개발 학회를 안정적으로 운영할 수 있는지에 대해서는 스스로 도전적이여야 한다고 봅니다.

B급 마인드에 대해서 이야기를 했는데, A급 마인드는 스스로 잘하는 마인드지만 모든 사람들이 갖추기 어려운 마인드이고, B급 마인드는 A급 마인드를 가진 개발자 분들을 따라가자는 마인드라 표현합니다.

다만 개인적으로 저는 B급 마인드라는 표현은 별로 좋아하진 않았습니다. 어차피 모든 사람들은 다른 사람들로부터 영감과 자극, 그리고 조언을 무의식적으로 얻기 때문입니다.

저는 이를 ‘후킹’이라고 합니다. 다른 사람들로부터 보고 배우면서, 장점을 취하고 단점을 개선시킬 여지를 찾아냅니다. 그들이 어떻게 하는 지 포착하고, 나에게 적용함으로써 성장을 이끌어내려고 노력합니다. 이렇게 장점만을 뽑아내는 것을 저는 ‘후킹’이라고 표현하는데, 저만의 용어입니다.

후킹을 위해서는 결국 잘하는 사람들이 많은 집단에 소속되어야 합니다. 그리고 한 집단에 소속되어서는 안 되고, 되도록 여러 집단에 소속되어야 함을 느낍니다.

저 역시 잘하는 개발자들이 모이는 최대한 많은 집단에 소속되어 저의 역할을 부여받으려 하고 있고, 또 그 집단을 운영하거나 혹은 직접 설립하기도 합니다. 이 목적은 결국 저의 성장을 위한 것이고, 어떻게 하면 더 빠르게 성장할 수 있는지 보고 배우기 위함입니다.

이를 B급 마인드라고 생각하지 않습니다. A급 마인드는 개발 자체를 좋아하는 것이라 표현했는데, 저도 개발을 좋아합니다. 저의 경험을 말하자면, 저는 취미 자체가 코딩이었고, 취미가 코딩이었기 때문에 중학교 시절부터 대학의 목표는 오로지 컴공 뿐이었습니다.

그러나 중고등학교 때에 5년 동안 배운 내용보다 작년 한 해 동안 배운 내용, 이룬 성장이 비교하는 게 우스울 정도로 수천 수만 배는 더 많습니다. 비교하는 게 정말 우스울 정도에요.

이게 물론 환경의 차이, 배움의 밀도의 차이, 배경 지식의 차이가 나는 것도 있겠지만, 사실 따지고 보면 뇌가 더 말랑말랑한 것은 20대때보다 10대 때이거든요? 배우는 속도에 자체만 갖고서 말한다면 10대 때가 더 빨라야 해요.

그런데 왜 이런 밀도, 속도가 지금이 훨씬 더 빠른지 생각해보면, 환경과 커뮤니티 때문이라고 생각을 합니다.

어릴 때는 무엇을 배우든 혼자 배우는 게 전부입니다. 중학교 시절에는, C++ 책을 읽으면서 집 컴퓨터로 실습해봐도, 이에 대해서 이야기를 나눌 사람도, 조언을 구할 사람도 없었습니다. 그냥 제가 따라 쳐보고, 이것저것 만져보고, 그게 끝입니다. 어떤 것을 만들고자 하였을 때 정보를 얻을 공간도 없고, 어떤 문제가 생겼을 때 물어볼 공간도 없었습니다. 어떤 것을 만들어보아야겠다, 이런 결심을 할 성장 동력도 없었구요.

고등학교 때 Python, C를 다룰 줄 아는 사람을 딱 두 명 봤습니다. 문법만 아는 수준이었는데, 함께 이야기가 통한다는 사실 자체가 엄청 기쁘더라구요. 가끔 서로 이야기를 하면서 얻는 정보와 성장 동력의 힘이, 혼자서 쓱쓱 만져본 긴 세월보다 훨씬 많더라구요.

대학교에 와서는 그 경험의 밀도가 차원을 달리 합니다. 솔직히, 1학년 때 배우는 내용이 특별하지는 않아요. Python, C나 C++을 배우는데, 언어 처음 배우는 게 깊이 있는 내용도 아니여서, 어릴 때 처음 배운 내용과 다르거나 특별할 게 있겠습니까. 그런데 대학교에 와보니깐, 똑같은 것을 배워도 이에 관해서 이야기를 나눌 수 있는 사람들이 생긴다는 게, 성장의 질과 속도를 압도적으로 다르게 만들더라구요.

예를 들어서 제가 처음 C++를 배울 때, 객체 지향이라는 것을 접해보고 감동을 먹었을 때가 있었어요. 근데 이 감동을 같이 이야기할 사람이 없는 거예요. 다른 친구들이 학교에서 영어 시험 이야기, 생활기록부 이야기, 내신 이야기, 고등학교 어디 갈건지 이런 이야기를 하고 있는데 거기서 갑자기 뜬금포로 C++의 객체 지향 설계가 주는 감동에 대해서 이야기를 꺼낸다면, 영어 시험 이야기, 생활기록부 이야기 이런 얘기 꺼낼 친구들도 없어지지 않을까요. 그래서 참 답답했습니다. 이야기를 안 하니깐, 스스로 이 감동이 무뎌져서, 큰 감흥으로 다가오지 않게 됩니다.

그러나 대학교에 와서 같은 과에 들어오면 이야기가 달라집니다. 대학교에 입학하니깐, 객체 지향이 무엇인지에 대해서 이야기할 사람이 생기고, 깊게 객체 지향 설계에 대해서 이야기하고, 정보를 공유할 사람이 생기고, 선배들로부터 객체 지향 설계의 깊은 내용, 본질에 대해서 전해듣게 됩니다. ‘디미터 법칙’, ‘디자인 패턴’, ‘SOLID 원칙’ 등 처음 들어보는 개념에 대해서도 학습하게 됩니다.

그렇게 학습하면서, 점차 개념에 대해서 더 깊게 알아가게 되고, 단순히 추상화니 뭐니 외우기만 했던 얕은 개념에서 벗어나, 스스로 개념에 대해서 정의하고 설명하기 시작합니다.

정보의 풍부함 역시 차원이 다릅니다. 무엇을 만들고자 했을때, 조언을 구할 사람이 주위 여기저기서 생겨요. 어느 진로를 가야겠다고 생각했을 때, 그 길에 대해서 알고 있는 사람들이 여기저기서 소개됩니다. 모두가 같은 관심사, 그러나 그 안에서 조금조금씩 다른 디테일과 경험, 인사이트를 갖고 있기에, 혼자서 정보를 검색하고 해결하려고 할 때보다 엄청난 시너지 효과를 얻어낼 수 있습니다.

이를 한 번 경험한 이후에, 적극적으로 개발 동아리 활동에 참여하려고 합니다. 그 안에서 얻어낼 수 있는 건 물론 인맥도 있겠지만, 저의 개인적 성장에도 엄청난 효과를 주기 때문입니다.

그리고 다른 사람들의 깃허브나 블로그 등을 많이 보고, 참고하려고 합니다. 다른 사람들은 이 문제에 대해서 이렇게 해결했구나를 알면, 비슷한 경험을 겪고 있을 때 도움이 되기도 하며, 이러한 길을 겪고자 할 때, 그 길을 이미 걷고 있는 분들은 어떤 경험을 했는지 등을 참고하면, 저 역시 길을 걷는데 도움이 될 것이기 때문입니다.

블로그나 깃허브가 이럴 때 큰 힘이 되죠. ‘이러한 상황에 대해서 테스트 코드를 어떻게 작성해야 할까요?’, ‘이러한 프로그램을 만들려고 하는데, 아키텍처를 어떻게 설계해야 할까요?’, ‘폴더 구조 어떻게 가져가요?’, ‘문서화나 주석 어떻게 관리해요?’ 이런 말을 사실 사석에서 하기 쉽지는 않잖아요? 같은 프로젝트를 하는 동료가 아니라면 더더욱이요. 그러나 블로그나 깃허브에는 이러한 질문에 대한 답변들이 정적으로 들어가있으니깐, 참 편한 것 같아요.

결론적으로, 어차피 혼자서 스스로 뚝딱뚝딱 성장하는 개발자는 많지 않을 것입니다. 그렇게 보이는 사람들도 결국 다른 사람의 장점을 후킹하여서 자신의 것으로 빠르게 전환해나가는 능력이 뛰어날 것입니다. 결국 남들로부터 배우고, 장점을 얻어가야 빠르게 성장하는 개발자가 될 수 있을 것입니다.

매력적인 신입되기 - 이찬진 님

이찬진 님은 Toss Backend 개발자이십니다. GDSC의 데브톡에서도 많은 세미나 발표를 통해서 경험을 전수해주셨고, 두둥의 기획자이자 개발자로 많은 영감을 주시는 분이십니다.

특히 두둥같은 경우는 정말 감명깊게 봐서, 저 스스로 깃허브 레포지토리 보면서 두둥 팀은 이렇게 개발하는구나 많이 공부했던 기억도 있습니다.

존경하는 선배님이십니다. 올해 토스에 새롭게 입사하셨는데, 토스에 채용되기까지의 경험을 전수해주십니다.

발표 속에서는 실제 본인의 이력서를 화면에 보여주어서, 추상적인 내용으로 끝나지 않고, 구체적인 예시를 볼 수 있어서 정말 좋았습니다.

개발 이력서 작성하기

개발 이력서를 작성할 때는 아래 내용이 중요하다고 합니다.

같이 협업하고 싶은 개발자인지
- 같이 성장할 수 있는 개발자인지
어떤 기술을 선택할 때 왜 선택했는지
기술 스택을 얼마나 파고 드는지
위 사항을 depth 없이 들어낼 수 있는 이력서인지

찬진 님은 위 내용을 아래와 같이 풀어냈다고 합니다.

같이 성장할 수 있는 개발자인지 → GDSC 발표, 운영진 경험 등
만드는 건 잘하는 지 알겠는데, 왜 이 기술을 선택했는지 → 블로그, 면접 대비 잘 정리해두기
이력서는 최대한 평범한 포맷으로

여기서 이력서를 최대한 평범한 포맷으로 만들라는 것은, 뎁스(Depth)를 줄이라는 조언입니다. 같은 경험을 담고 있는 이력서인데, 이를 어떻게 풀어내는 지에 따라서 그 결과가 달라지기도 합니다. 왼쪽은 찬진 님께서 네이버에 지원하셨을 때의 서류인데 탈락했다고 하고, 오른쪽은 이번에 합격한 토스 지원 이력서라고 합니다.

왼쪽은 한 번의 들여쓰기, 즉 뎁스가 있습니다. 그러나 오른쪽은 매우 평범한 포맷으로 쓰여진, 뎁스가 없는 이력서입니다. 오른쪽이 면접관 입장에서 훨씬 보기 좋은 포맷이라고 합니다.

미리 준비하기

면접관 입장에서 고민해보기

자신이 면접관이라면, 어떤 사람을 뽑고 싶은 지 고민해봅시다. 어떤 사람이 조직에 잘 어울릴 수 있을까요? 어떤 사람이 조직에게 가장 높은 성과와 이윤을 가져와줄까요? 개인의 성과는 실력과 성실도에 영향을 받겠지만, 조직의 성과는 그보다 훨씬 더 복합적인 원인들이 동시에 작용합니다. 면접관 입장에서 중요하게 생각하는 가치가 무엇일 지 스스로 고민하라 조언합니다.

꾸준한 스토리가 있는 프로젝트, 그리고 임팩트 있는 프로젝트

면접관이 좋아하는 프로젝트는 단순 구현에서 벗어난, 임팩트있는 프로젝트라고 합니다.

동시에 꾸준한 스토리가 있는 프로젝트를 준비하라고 합니다.

사실 이는 고등학교 때 대학교를 가기 위해서 생활기록부를 채우는 듯한 느낌을 받았습니다. 그 중요성만 다를 뿐 맥락은 비슷하죠 사실.

찬진 님의 경우는 컴퓨터공학과 밴드 동아리에 있으면서, 밴드부 내에서의 정산 문제, 공연 예매 문제와 같은 자신에게 가까운 문제를 해결하였고, 이것이 임팩트 있는 스토리가 되었다고 설명합니다.

주변에서 찾을 수 있는 가까운 문제들을 해결하는 과정에서 스토리를 녹여 내라고 조언합니다.

CS, 알고리즘 미리미리 공부하기

위에서 임팩트 있는 프로젝트가 중요하다고 하였는데, 이 프로젝트와 연관되어 면접에서 이끌어낼 수 있는 CS 역시 공부하라고 조언합니다.

문제 은행처럼 정해진 기출 문제를 돌려가면서 내는 기업도 있으나, 좋은 기업의 면접이라면 본인이 했던 프로젝트와 연관되어 물어볼 것입니다. 발표에서 언급된 예시를 소개하자면,

예) CRUD에서 벗어나, 동시성 이슈를 해결하는 내용
예) 레디스에서 Swap memory를 주었을 때 왜 안 좋은지

이러한 정보는 프로젝트를 진행하면서 겪은 경험적인 내용, 그리고 그 경험과 연계된 CS 지식이라고 합니다.

또 질문이 아니더라도, 답변하는 과정에서 이렇게 툭툭 던질 수 있는 CS 기반 지식이 있다면, 큰 장점이 된다고 합니다.

그리고 알고리즘이 문제인데, 어차피 코딩 테스트를 통과하지 못한다면 면접이든 서류이든 프로젝트이든, 자신을 보여줄 기회조차 얻지 못합니다. 그렇기 때문에 알고리즘을 미리미리 공부해두라고 조언합니다.

들어가고 싶은 기업의 Job Description 확인하기

Django, Node.js를 하다가 갑자기 Spring을 다루는 기업에 취업하기란 어렵겠죠. 그 기업이 어떤 기술을 다루고 있는지 미리 알아보고 대비합시다.

내 주변 개발 Pool 만들기

위에서의 내용과 비슷한 맥락인데, 내 주위에 개발 Pool을 만들라고 합니다.

사실, 컴퓨터공학과에 입학했음에도, 그 장점을 활용하지 못하는 분들이 가끔 보여서 안타깝습니다. 무엇이든 혼자 하려고 하는 분들을 많이 봤는데, 같이 성장하는 개발자가 됩시다. 좋은 아티클을 공유하거나, 혹은 같이 프로젝트를 진행해보라고 조언합니다.

취업 꿀팁

기업별 테크 유튜브 (배민, 토스, 카카오, NHN 등)
기업별 테크 블로그 (카카오페이, 당근, 하이퍼커넥트, 컬리 등)

기업별 테크 유튜브나 블로그는 한 바퀴 둘러가면서 정독하라고 조언합니다.

그리고 아래 블로그나 유튜브에 도움이 될 만한 많은 아티클과 비디오가 있으니, 많이 보라고 소개해주십니다.

F-lab 블로그
널널한 개발자
개발바닥 (이력서 시리즈)
면접왕 이형
쉬운 코드 (cs에 강점을 갖는 유튜브)

결론

결론적으로, 응집력 있는 모습이 신입의 경쟁력이라고 강조합니다.

다년차 개발자에 비해서 신입이 보여줄 수 있는 무기는 그렇게 많지 않습니다. 기업 입장에서는 똑같은 조건, 똑같은 환경이라면 다년의 경험이 있는 지원자를 제치고 신입을 뽑을 이유가 없을 것입니다. 애초에 신입을 새롭게 교육할 수 있는 환경을 갖춘 회사 자체가 그리 많지 않구요. 그러나 이들과 경쟁하기 위해서 신입이 어필할 수 있는 부분은, 비록 경험이 없더라도 모든 부분을 아울러 가면서 성장할 수 있는, 응집력 있는 모습을 갖추라고 조언합니다.

🧭 그외 후기

끝나고서 추첨을 통해서 상품이 전달되었거든요? 10명 뽑는데 갑자기 제가 당첨되더라구요?

그래서 생각하지도 못했는데, 책 선물을 받았습니다. 기쁘네요. 잔뜩 주위에 자랑하고 다녔답니다. 이런 데서 추첨으로 선물받은 것은 처음이에요. 운이 좋네요.

애자일 방법론 및 개발 문화에 대한 서적입니다. 지금은 따로 읽고 있는 책이 있어서, 그 책을 다 읽고 나면 이 책도 빠르게 읽어보려고 합니다.

다음 연합 세미나 데브톡이 언제 시작되나 궁금합니다. 많이 기대하고 있답니다.

그리고 개인적으로, 이 연합 세미나 데브톡을 필두로, 각 홍컴의 동아리들이 교류할 수 있는 또다른 이벤트들이 많이 생겨나면 좋겠습니다.

그리고 데브톡 세미나가 다 좋은데, 다음 세미나에 새로운 사람도 많이 보였으면 합니다. 더 대단한 사람, 혹은 다른 대단한 사람이 오길 바라는 게 아니라(물론 그러면 좋겠죠), 보다 미숙하더라도 경험을 나눌 수 있는 분들이 있었으면 좋겠습니다. 거기서도 배울 게 많을텐데, 다음 세미나를 기대합니다.