연사님 이력
-홍익대학교 컴퓨터공학과 9x학번
-컴퓨터공학과 학술학회 학회장
-(전) 네이버메일서비스개발팀 팀장
-(현) NHN 두레이 대표이사
-(현) NHN 개발자 채용업무 및 신입사원 기술 교육 담당
공지 올라온거 보고 200명 선착순이라길래 엄청 몰릴 줄 알고 후다닥 신청했는데, 막상 현장 가보니까 20명? 정도 왔더라
개인적으로 연차가 높고, 채용 업무를 진행하고 계시는 분의 강연은 정말 좋은 기회라고 생각했다.
여러가지 주제를 가지고 이야기 해주셨는데, 기억나는대로 두서없이 적어보고자 한다.
(나중에 PPT 자료 공유해주신다는데, 아직 못 받았다. 나중에 받으면 이 글도 좀 더 깔끔하게 정리하고 싶다.)
자기소개 + 회사홍보?
밥을 늦게먹어서 조금 지각하는 바람에 자기소개 중에 들어갔는데, 그냥 회사에서 있었던 썰을 푸셨던 게 메인이었다.
전에 SKT에서 일할 때 여기는 개발 안하고 매니징 업무하면서 오래오래 일하고 싶은 사람이면 추천한다고 하셨던 게 기억난다. 조금 무서웠던 말은 여기는 실력을 잃는 대가로 돈을 더 받는 느낌이라고..
전에 다니던 직장에서 일하시다가 업무 도구 툴을 직접 만들고 싶으셔서 회사에 건의 후 승낙받아 만들 뻔 했다가 내부적인 사정이 있어서 결국 잘 안되었다고 한다.
그때 다른 기업에서 업무 도구 툴 만드는 일을 제안받아서 이런 이런 조건이면 가서 일하겠다 했는데, 하루만에 OK 받아서 다음날 바로 사표쓰고 일하면서 지금까지 왔다고 하는 썰이었다.
강연 중간 중간 업무 시간중에 강연하러 온거라고 하시며 NHN 홍보?를 종종 하셔서 재밌게 들었다.
좋은 개발자 (잘하는 개발자)가 되려면
공부를 잘하려면 무엇이 중요할까? => 열심히 많이 하면 된다. 개발도 똑같다.
이런 서두로 시작해서 무엇 무엇을 하면 좋은지 말씀을 많이 해주셨다.
종종 '프로젝트를 할 때, 깊이 있게 파고 들어가는 경험이 중요하다' 와 같은 이야기를 많이 듣곤 했다.
이번 연사님도 사례를 통해 비슷한 이야기를 해주셨다.
어떤 서비스를 만들어서 회원가입을 기능을 만드려고 한다.
회원 가입은 간단하게 이메일과 비밀번호만 입력받는다고 하자.
이 기능, 만드는데 1시간이면 충분할까?
단순히 '입력 폼' 을 만드는 기능을 구현하는 것은 1시간이면 충분하다.
그런데 여러가지 상황을 생각해봐야 한다.
우선 비밀번호를 저장할 때 평문으로 저장할텐가?
당연히 해싱을 해서 저장해야 한다.
단순히 해싱만 하면 충분할까?
학부 때 이런 서비스를 만들어봤다고 친구들한테 자랑자랑하면서 써보라고 했더니 똑같은 해시값들이 여러개 보였다.
알고보니 귀찮다고 그냥 1234로 비밀번호를 저장했더라.
해커들은 (레인보우 테이블이라는 용어로도 있지만) 다들 각자 유명한 해시 알고리즘을 어떤 평문에 적용한 결과를 사전처럼 만들어 가지고 다닌다.
그래서 사전에서 해당 해시값을 발견하면 그걸 토대로 평문을 알아내기도 한다.
(그럼에도 이렇게 비밀번호를 관리하는 사이트들이 실제로 있다.)
그래서 해싱을 할 때는 이메일을 같이 이용해야 한다.
근데 또 귀찮다고 이메일을 a@a.com 으로 치는 애들이 있더라.
이런 걸 방지하려면 이메일 인증 기능을 추가해야 한다.
이제 다 되었다고 생각해서 서버를 올렸더니 이번엔 서버에 주기적으로 404, 403 에러 로그가 찍힌다.
알고보니 해커들이 뚫어보겠다고 시도를 날리는거더라
그래서 비밀번호를 3번이상 틀리면 캡챠를 달도록 기능을 추가했다.
이제 다시 생각해보자.
회원 가입 기능, 1시간으로 충분할까?
절대 충분하지 않다.
무언가 개발한다고 한다면, 그것과 비슷하게 실제 상용되는 서비스를 바라보면서, 그 서비스에서 고민하고 또 처리하고 있을 여러 상황들까지 고민하며 깊이 파고들어 개발해보는 것.
이게 깊이 있게 파고들어본 경험을 의미한다고 한다.
그리고 잘하는 개발자의 특징중 하나가, 생각을 한단계 더 깊이 한다고 한다.
어떤 문제가 안 된다고 하면, 이건 이런 이런 이유 때문에 안됐던 거였어요. 하고 남들에게 한단계 더 깊이 설명하곤 한다.
그리고 자바에서 발생한 오류를, 꼭 시스템 프로그래밍 같이 한 단계 더 깊은 레벨에서 C로 짜보고 공부했던 개발자들이 해결하곤 했다고 한다.
또 기억나는 내용은, 좋은 소스코드를 많이 읽어보고 인사이트를 얻는 것이다.
좋은 소스코드는 깃허브에 좋은 오픈소스들을 읽어보면 된다고 한다.
그 오픈소스들의 히스토리를 보면서, 또 유명한 프레임워크를 뜯어보면서 왜 이렇게 썼고, 왜 이렇게 변화했는지를 따라가다보면 인사이트가 생긴다고 한다.
또 언어의 변화에 맞춰 프레임워크와 라이브러리도 변화하기 때문에 그런 점들을 보기도 좋다고 한다.
새로운 기술 익히기
어떤 블로그 서비스를 만들어서 올려본다고 하자.
프론트를 개발하고, 백엔드를 개발하고, 디비를 개발해서 올렸을 것이다.
만약 이 상황에서 새로운 도구를 익힌다고 한다면 이렇게 익히는게 효율적이다.
기존 블로그의 프론트를 앵귤러로 개발하였는데, 리액트를 새로 공부한다고 한다면
기존 블로그의 백엔드와 DB는 그대로 놔두고, 프론트 로직만 리액트로 바꾸면서 기존 API를 그대로 활용하는 것이 좋다.
이렇게 했을 때, 기존에 잘 작동하던 로직이 리액트에서도 잘 작동하는지 확인하기도 쉽다.
매번 새로운 기술을 배울 때마다 New Project 를 하면서 공부하는 것은 효율적이지 않다.
컴공과가 비전공자보다 좋은 점
1. 기본기 (CS) 에 조금 더 익숙하다.
2. 컴퓨터 분야 인맥을 쌓기 쉽다.
하지만 필드에서 10년 20년 일하다보면 4년 컴공과를 다녔던 경험은 점점 의미 없어진다.
열심히 하자.
비 기술적으로 중요한 점
1. 엑셀
프로젝트 결과가 나왔을 때, 이 성과를 수식으로 계산하는 상황이 있다.
네이버에서 일할 때, 엑셀에 평균을 구했는데, 수식이 아니라 숫자로 직접 입력한 걸 보고 충격먹었다.
전문가가 될 필요는 없으나, 피벗테이블과 수식을 사용할 줄 아는 정도는 되는 것이 좋다.
2. 인성과 태도 (인간성)
커뮤니케이션과 비슷한 맥락인 것 같다.
연사님이 정말 기억에 잘 남는 예시를 하나 들어주셨는데,
인간성이 좋은 사람
무엇인가 물어볼 때 편하게 물어볼 수 있는 사람
& 새롭게 배운 것이 있을 때, 이를 나누려는 사람
당신 주변에 개발 잘하는 사람들을 떠올려보자.
그 사람 중에 혹시 '얘가 아무리 개발을 잘해도 절대 얘한테는 안 물어본다.' 하는 사람이 있는가?
그런 사람이 되면 안된다.
회사 입장에서도, 뭔가 어려운 일이 주어졌을 때, 그 어려운 일을 인간성이 좋지 않은 사람에게 주면,
팀원들이 어려운 일을 해결하려고 하다가 막히더라도 그 사람과 일하는 것을 꺼리기 때문에 문제 해결이 잘 안된다.
그런 사람한테는 회사에서도 일을 던져주지 않는다.
차라리 실력이 조금 낮더라도, 인간성이 좋은 사람에게 줘서 시간이 들더라도 팀원들과 머리 꽁꽁 싸매서 같이 해결하고 같이 성장하는 것이 회사에서 더 이득이다.
인간성이 좋지 않은 사람은 다른 사람들이 같이 고민하고 성장할 때, 혼자 고민하며 성장해야 한다.
또 무엇인가 고민한 결과로 새롭게 배운 것이 있을 때, 이를 자신의 비장의 무기로 삼으며 자신만 알고있으려는 사람이 있다.
이런 사람도 회사는 좋아하지 않는다.
배운 것이 있으면 이를 적극적으로 주변사람에게 공유하는 사람을 좋아한다.
3. 충돌 경험과 그 상황에서의 태도
학교에서 팀플을 하면, 잘하는 사람 하나가 하는 말을 중심으로 주변 사람이 끌려가기 마련이다.
이는 '협업' 이 아니다.
회사에 가면 날고 기는 사람들을 뽑아다가 모아놨기 때문에, 다들 서로 잘난 사람들만 모여있다.
이 상황에서는 '충돌' 이 반드시 발생한다.
보통 의견이 충돌 할 때는, 어떤 문제 상황을 해결하는 방법이 충돌하는 경우가 많다.
이럴 때, '전에 이 사람이 나와의 논리 배틀에서 승리하였으니, 이번엔 내가 반드시 이기겠다' 는 마음가짐으로 자신의 생각을 어떻게든 관철하고 설득하려고 하는 사람이 있다.
설득도 물론 중요하지만 이런 태도로는 설득하면 안된다.
언제나 의견이 충돌 할 때는, 자신의 의견을 설득하는 것도, 상대방의 의견에 동의하는 것도 모두 '더 나은 방향으로의 문제 해결' 에 초점을 두고 결정해야 한다.
웹 개발을 한다면
HTML, CSS, javascript 를 꼭 제대로 알아둬라.
'아 저 컴포넌트 왼쪽으로 조금만 더 밀고 싶은데 왜 안되지'
이 고민으로 정말 수 많은 시간을 날린다. 이건 다 CSS 지식이 부족해서 그렇다.
(나는 css는 검색으로 해결할 수 있을 수준으로 알아두자고 생각했는데, 아무래도 더 공부를 해야겠다고 다짐하게 되었다..)
취업 준비할 때 중요한 것
1. 알고리즘 문제 풀이능력
2. 자료구조 / OS / 데이터베이스 / 네트워크 지식
다들 많이 물어보는데, 공모전? 자소서? 이것들보다 저 2개가 3000배는 더 중요하다.
(나중에 질문 시간에 '프로젝트 경험은 안 중요한가요?' 라고 질문했는데 그게 공모전과 같은 축이라고 한다.
학부때 했던 프로젝트 경험은 별로 기대 안한다고 한다. 그냥 얘는 학부 때 뭐 많이 했네. 이거 딱 하나 생각하고 끝이라고)
자소서도 그냥 적당히 쓰면 된다고 한다.
결국 저 1, 2가 제일 중요하다고 한다.
누가 질문 시간에 '자소서 강점 항목에 어떤 걸 어필하면 좋을까요?' 라고 질문했었다.
그때 하신 대답은 '적극성을 어필 + 그걸 증명하면 좋을 것 같네요. 근데 자소서보다 알고리즘하고 CS 지식이 더 중요해요. 적당히 쓰세요' 라고 하셨다.
누가 질문 시간에 자격증도 물어봤다.
그 분은 클라우드 관련 분야를 생각하고 계신 것 같았는데, '리눅스마스터 자격증 도움 될까요?' 라는 질문에는
자격증은 내가 리눅스를 많이 공부했는데, 이걸 객관적으로 보여주고 싶어서 딴다면 상관 없는데,
스펙 한 줄 더 채우려고 따는 건 아주 비추다.
저 공모전/자소서와 같은 결로써, 자격증 딸 시간에 1, 2번을 제대로 하면 된다.
오히려 자격증이 너무 많으면, 얘 개발할 줄 몰라서 자격증으로 대신 도배해둔거 아냐? 이런 말을 면접관끼리 실제로도 한다고 한다.
그리고 실무에서 자격증 내용이 실제로 도움되는 경우도 없다고..
추가로 나온 질문 중에 '학점' 도 있었다.
학점은 공모전 / 자소서 / 자격증 보다는 중요하다고 한다.
하지만 여전히 알고리즘 / CS 지식보다는 아래라고 한다.
학점은 전체 평점을 보지, 세부 전공과목 평점을 보진 않는다고 한다. (이건 어떻게 보면 당연하려나)
그렇다면 알고리즘은 어떻게 공부하는가?
그 분은 알고리즘 책을 하나 구해서 처음 챕터부터 마지막 챕터까지 '난이도 하' 문제를 골라서, 연습문제도 1, 2번 문제만 풀면서 일단 쭉 훑으라고 한다.
처음부터 어려운 난이도를 풀면 그날 하루로 알고리즘을 접게 될 것이고, 책에 있는 모든 연습문제를 풀려고하면 일주일 내로 알고리즘을 접게 될 거라고..
그리고 그렇게 한번 훑으면 자신이 약한 파트를 대략 알게되어 그 부분을 다시 공부할 수 있게된다.
그리고 어제 풀었던 문제를 오늘 다시 푸는게 아니라, 3달전에 풀었던 문제를 다시 풀어보면 (위 방법으로 한다면, 책을 한번 훑고 다시 앞으로 돌아와서 풀어보면) 처음 풀 때와 다르게 사고하는 방법도, 걸리는 시간도 달라졌을 것이라고 한다.
이런식으로 알고리즘을 공부하면 된다고 추천해주셨다.
그리고 저학년 때는 알고리즘하면서 익숙한 언어를 하나 만들라고 추천해주셨다.
누가 질문으로 '2학년 겨울방학때 뭐 하면 알차게 보낼 수 있을까요?' 라는 질문에
혹시 머릿속으로 하고 싶은 말이 있을 때 한국어 줄줄줄 나와서 말하는 것처럼, 구현하려는 게 있을 때, 그거를 술술술 코드로 적어낼 수 있는 언어가 있나요? 그게 없다면 자바 공부하세요. 라고 하셨다.
한국에서 백엔드는 결국 자바가 메인이고, 다른언어보다도 파이썬/자바를 메인으로 공부해두라고 하셨다.
그렇다면 CS는 어느 정도 수준까지 알고 있어야 하나요?
그걸 실제로 구현해보고 하는 정도까지는 아니더라도, 학교다니면서 해당 과목의 중간고사/기말고사 본 직후 머릿속에 들어있는 상태가 계속 유지되도록 해야한다.
이 말을 듣고 조금 충격이었다.
그 정도까지..?
그래서 나중에 공부할려면 힘드니까 CS 공부하면서 미리 블로그 같은 곳에 정리해두고, 틈틈히 읽으면서 중간고사/기말고사 본 직후의 지식 수준을 계속 유지하라고 하셨다.
근데 전에 카카오 합격하셨던 선배분도 비슷한 수준이셨던 것 같다.
그 분은 '저는 정보처리기사 너무 쉬워서 그냥 안땄어요.' 라고 하셨다.
이 정도는 되어야 CS 준비가 되었다고 할 수 있으려나...
기술 면접
면접의 난이도가 쉬울 수도 있고 어려울 수도 있다.
하지만 난이도에 상관없이, 만약 면접 질문에 답을 못하겠다면, '혹시 힌트를 조금 주실 수 있을까요?' 하고 물어보라고 한다.
면접은 떨어뜨리기 위해서가 아니라, 뽑기 위해서 보고 있는 것이다.
면접 질문에 단답으로 '모르겠습니다.' 라고 하면 더 이상 할 말이 없이 끝나는 느낌이지만,
힌트를 받고나서 자신이 생각나는 곳까지 어떻게든 말하면서 면접관과 티키타카가 오고가고, 면접관은 어느 정도 선의 힌트를 주었을 때 이걸 맞춰주기를 바라면서 두근두근하다가 결국 맞췄을 때, (혹은 못 맞췄더라도) 단답으로 오고간 면접보다는 지루하지도 않고, 면접관도 재밌게 면접을 보니 오히려 좋다고 한다.
책 추천
그림으로 배우는 리눅스 구조
REDIS 관련 책 (REDIS는 키-밸류 쌍으로 저장하는 데이터베이스인데, 이게 생각보다 중요해서 학부생때 해두면 좋다고 추천한다고 하신다.)
Java 책
시스템 프로그래밍 관련 책 (스터디 할 가치가 있다)
학교에서 알려주지 않는 실무에서 중요한 기술 12가지
그리고 목차가 NHN 신입사원 교육 프로세스와 완전 동일한 책도 한권 있어서 추천해주셨다.
나중에 PPT 받으면 추가해봐야지
그 밖에 질문
C/C++ 언어 공부는 별로일까요?
-> 너무 시장이 좁다. 이직도 힘들고 자신이 네이버 다닐 때 C 언어 쓴 곳은 딱 2곳. 드라이브와 이메일처리 팀이었다.
저는 개발은 별로 안 맞는 것 같고 PM이 맞는 것 같은데요
-> 만드는 걸 좋아한다면 PM이 아니라 프로덕트 오너가 맞는 것일 수 있다. 그거는 창업을 하고 싶다는 뜻이다.
-> 개발을 안하고 PM을 하는 건 비추천이다. PM은 여러 부서 사이에서 의견을 조율하면서 주변에 휘둘리지 않아야 한다.
그런데 개발 지식이 얕다면 개발자들에게 휘둘릴 수 밖에 없다. 그래서 개발 경험을 쌓고 PM을 하는 것을 추천한다.
-> 그리고 PM은 별로 추천하지 않는다. 회사가 돈이 없어지면 개발자와 PM 중 누굴 먼저 자를까? PM부터 자른다.
PM이 중요하지 않아서가 아니라, 대체 가능한 인력이 너무 많아서다. (특별한 기술이 필요한 게 아니기 때문에)
그리고 이건 개발자도 똑같다. 사실 회사는 무서운 곳이다. 내가 굳이 없어도 된다면 내가 나가든 말든 회사는 상관없기 때문에 나를 막 대할 것이고, 내가 회사에 필요하다면 나를 모셔온다.
회의할 때도, PM한테는 막 소리지르고 하면서도, 개발자한테는 너가 한번 참아라 하는 경우가 있었다.
개발자가 최고다. 대우도 받고, 돈도 많이 받는 직업이다. 개발자해라.
그리고 개발자 대우해주는 회사로 가라. 개발자들을 무시하는 회사가 있는데, 그런 곳은 가지마라.
인턴에 대해서는 어떻게 생각하세요?
-> 이건 케바케가 심해서 좋다 나쁘다를 말할 수 없다.
인턴 중에, 뽑아놓고 그냥 잡일만 시키는 경우도 있다.
저는 개발을 별로 안좋아해요. 이런 건 어떻게 극복하나요?
-> 이건 내가 대답할 수 있는 질문이 아니다.
나는 개발을 너무 좋아한다. 학부생때도 개발이 재밌어서 학회 스터디할 때도 A라는 기능을 만들기로 했으면 여기에 B기능, C 기능 추가해보고 싶어서 밤새워 추가하고 친구들한테 자랑했다.
홍대 앞에 연못에 나뭇잎으로 배를 만들어서 띄워놓고 친구들한테 보여주려고 "여기 와서 내가 만든 것좀 봐봐" 했더니 친구들이 "이번엔 또 뭘 짰는데?" 라고 물어봤을 정도.
자신이 생각하기에 개발자는 개발을 좋아하는 사람이 아니면 하면 안된다고 생각한다.
개발자는 끊임없이 공부해야하는 직업이다.
10년차 개발자라고 지원해놓고, 1년차 수준의 개발을 10년동안 해온 사람도 있다.
JAVA 언어에 수많은 발전이 있었는데, 아직도 for문 짜라고 하면 for (i = 0; i < ...) 이렇게 짜는 사람이 있다.
그런 사람보면 10년동안 누군가의 피드백도 받지 못하고 혼자서 하던대로 코딩했구나 하는 생각이 든다고 한다.
언어를 공부할 때, 언어의 release 노트를 봐봐라.
무엇이 변했는지 확인해봐라.
스프링 프레임워크도 소스코드를 뜯어봐라.
그리고 프레임워크를 볼 때는 가장 초기버전을 봐라.
어차피 핵심 로직은 이미 초기 버전에서 구현이 되어있으니, 그걸 보는 편이 비교적 양도 적다.
근데 스프링 같은 경우는 그냥 뜯으면 그래도 너무 양이 많아서 절대 다 못읽는다.
그럴 땐 일부분만 살펴봐라.
스프링 프레임워크의 @Transaction 어노테이션 하나만 붙이면 커밋과 롤백을 다 알아서 해주는데, 이건 어떻게 한 건지 그 부분만 살펴봐라.
이해를 했다면 한번 여러 예외처리는 무시하고, 골든 로드를 직접 구현해봐라.
구현하는 과정에서 내가 알던 지식의 빈틈이 메워진다.
근데 스프링이 솔직히 양이 그래도 너무 많다면, 작은 단위 클래스를 뜯어봐라.
요즘은 안나오지만 예전에 StringBuffer 와 StringBuilder의 차이점을 묻는 질문을 하던 때가 있었다.
이 둘의 코드는 비슷하지만 미묘한 차이가 있다.
면접 때, '제가 몇달 전에 한번 읽어봤는데, 아마 ~~줄에서 ~~ 이런 코드가 있었고..' 하는 이야기를 하면 얘는 그래도 좀 깊게 팔 줄 아는구나 하는 생각이 든다고 한다.
그리고 같은 클래스여도, 자바 언어의 변화에 맞춰 클래스와 프레임워크가 변하니 이를 읽어봐라.
잘하는 개발자는 항상 남들보다 한 단계 더 깊게 생각한다.
자바 언어에 default 키워드가 추가되었다.
이 키워드 덕분에 Map 인터페이스가 버전이 올라감에따라 변경되었음에도 이전 코드에서도 문제가 없이 작동한다.
모바일 앱 개발은 어떻게 생각하세요?
-> IOS는 수요대비 공급이 적은편이라고 생각한다.
나는 한다면 IOS 개발자를 추천한다.
중고신입에 대해 어떻게 생각하시는지 궁금합니다.
-> 이건 회사 내에서도 논란이 있었다.
그래서 회사마다 다르긴 한데, '3년차 이상은 뽑지 말죠' 하는 경우도 있고.. 그렇다.
기본적으로는 '신입' 을 뽑는거니까 중고신입이 되어야지 하는 생각보다는 신입으로서 기본기를 갖추는 걸 더 중요하게 생각하라는 방향으로 말씀해주셨던 것 같다.
시니어 개발자는 주니어/신입 개발자와 어떤 점이 다를까요?
오늘 연사님이 개발을 좋아하신다고도 하셨고, 지금은 개발을 거의 안한다고 하셨다. (CEO니까 당연하겠지만)
그래서 개발을 오래 해왔던 분으로서 시니어 개발자의 핵심 역량은 무엇인지 궁금했다.
연사님이 마치 '개발자는 절대 안잘리고, 개발을 놓지 않는 한 평생할 수 있는 직업' 으로 묘사하셨기 때문이다.
판교 뚜벅초에서 봤던 영상 중 이런 말도 있었다.
"요즘 신입보면, 사실 신입이 나보다 개발 더 잘한다. 나는 그저 지난 10년간의 프로젝트 히스토리를 알고 있을 뿐인데, 나에게 이젠 시니어의 일을 회사가 요구하니 고민이 많다"
그때 연사님이 하신 말씀은
"지난 1년동안 있었던 일들 중 다른 사람에게 이야기할 수 있는 기억나는 스토리가 있어야 한다" 라고 하셨다.
기억나는 스토리가 없다는 것은, 스스로가 그동안 정체되어 있었다는 뜻이고, 당연히 최신 기술을 배워서 입사한 신입에게 밀리고 뒤쳐지는 것은 당연한 것이라고 한다.
그러면서 시니어의 차이점으로 한가지 사례를 들어주셨다.
네이버 메일팀에 있을 때, 한번 작정하고 누가 스팸 메일을 미친 듯이 보냈던 적이 있었다고 한다.
근데 하필 그게 높으신 분의 메일함에도 가는 바람에, 해결하라는 윗 지시가 내려왔다고 한다.
이런 상황에서, 연사님은 이 문제가 어려워 보이고 귀찮아 보인다고 가만히 있었던게 아니라 적극적으로 해결하기 위해 뛰어들었다고 한다.
일단 당장에 해결도 잘 안되고 급하니까 높으신 분의 메일만 따로 골라서 필터링하고, 나머지는 사람이 직접 일일히 필터링 하는 과정을 몇달동안 했다고 한다.
잠잘때도 휴대폰을 잡고자다가, 휴대폰 알람이 울리면 일어나서 VPN을 키고 스팸 메일을 정리했다고 한다.
그런데 이 고생을 몇달 하고 나니 스팸메일들의 규칙이 보이기 시작했고, 그 규칙을 이용해 이 문제를 해결했던 경험이 있다고 하셨다.
시니어 개발자들과 저연차 개발자의 차이는 이런 점에서 온다고 하신다.
이렇게 문제를 해결해봤기 때문에, 문제 상황에서도 대처하는 것이 다르다고
실제로 자신이 NHN 자회사 CEO로 오면서 같이 온 사람들이 있는데, 그 사람들과는 문제 상황에 대한 키워드 몇 개만 딱딱 던지면, 서로 자세하게 말을 안해도 "그럼 ~이렇게 하죠" 했을 때 다 알아듣는다고 한다.
그런데 이 말을 다른 사람들은 이해를 못한다고 한다.
이런 점이 경험의 차이이고, 시니어와 저연차 개발자의 차이라고 한다.
이 스토리를 듣고나니 "지난 1년동안 있었던 일들 중 다른 사람에게 이야기할 수 있는 기억나는 스토리가 있어야 한다" 라는 말이 이해가 되었다.
강연을 듣고나서...
사실 뭔가 강연 요지를 알 것 같으면서도 좀 혼란스러워졌다.
프레임워크를 뜯어보고, 블로그를 만들어보고, 경험을 기록하라고 하면서도 중요한 것은 알고리즘과 CS지식, 그 밖에 나머지는 부차적인 것 이라는 뉘앙스로 말씀하셨기 때문이다.
그리고 카카오 인턴쉽이나, 이번 쏘카 지원할때도, 포트폴리오를 아예 필수로 업로드 하라고 하고, 요즘 깃허브 링크도 올리라고 하는데, 프로젝트를 버리더라도 알고리즘과 CS지식에 집중하는게 더 맞는 걸까 하는 생각이 들었다.
연사님 말로는 '만약 프로젝트 경험, 프레임워크 사용 능력을 중요시 본다면, 그 회사는 당신의 성장보다 당장 그 프레임워크로 뭔가를 개발해서 프로덕트로 내는 것을 기대하고 있을 것이다' 라고 하셨던 것 같다.
요즘 '협업 경험', '프로젝트 경험' 에 목매면서 어떻게 보면 전공 공부보다도 개발 강의에 우선순위를 두고 프로젝트 트랙 활동을 하고 있었는데, 내가 잘못된 선택을 한 건 아닐까? 하는 생각이 들어 겁이 나기도 했다.
(사실 시간에 쫓겨 강의를 듣다보니 어떻게 보면 외워서 코드를 짜고 있는 모습에 현타가 오기도 했다.)
연사님은 '프레임워크 기술 익히는 것은 1달만 투자하면 금방 한다. 기본기가 충실하면 어떤 프레임워크든 금방 배우니 CS와 알고리즘에 집중해라' 라고 하셨다.
그리고 이것에 준비가 되었다면 그때 프레임워크 같은 도구를 사용해보라고 하셨다.
이 말을 듣고나니 고민이 더 많아졌다.
나는 저렇게 공부하면서 '기술자' 로서 개발을 할 수 있을까?
그냥 프로덕트를 만드는 것을 좋아하는 건 아닐까? 그냥 창업을 해야할까?
아니면 개발자로서의 성장의 기회를 돈과 바꾸고 안정적인 삶을 노려야 할까?
인생 방향 결정하기 참 어렵다🙃
그래도 질문 정리했던 걸 보면 알겠지만.. 연사님이 학생들 질문을 정말 많이 받아주시고, 질문 하나하나에 자세하게 답변해주시려고 해주시는게 느껴져서 정말 감사했다.
뭔가 식사라도 대접해드리면서 받아야 할 상담을 무료로 (심지어 발표한 사람들에게 책을 준다고 하셔서 책까지 받으며) 받게 되어서 너무 좋은 기회였던 것 같다.
이런 기회 잡으려고 등록금 내고 대학 다니는구나 하는 생각이 들었다ㅎ
다음에도 이런 기회 있으면 꼭 참여해야지
'자기계발 > 생각 정리' 카테고리의 다른 글
| 2023년 회고 (+ 2023년 12월 회고) (0) | 2023.12.31 |
|---|---|
| 2023년 11월 회고 (8) | 2023.11.30 |
| 2023년 10월 회고 (4) | 2023.10.31 |
| 군대 & 2022년 회고 (7) | 2022.12.30 |
| 프론트와 백엔드를 분리하고 싶다... (2) | 2022.06.20 |
