슬기로운 인턴생활 참가후기

https://festa.io/events/345

지난 7월 6일 GDG Campus에서 열린 '슬기로운 인턴생활' 이라는 세미나에 다녀왔다.

총 5명의 발표자가 각각 진행하는 5개의 세션과 질의응답 시간으로 구성되었는데 LINE 재직자, 대학생, 일반인 등 다양하게 구성되었다.

 

이 주변은 처음 가보다보니 빌딩 지하에 있는 발표장소를 그냥 지나쳤다가 다시 돌아오느라 더워 죽는줄 알았다.

현대 기업 건물인지 1층에 자동차 등이 놓여져 있었는데 안내원에게 물어보니 지하2층에서 진행하고 있다고 했다.

아무래도 정시각보다 조금 늦게 간 만큼 자리가 애매해서(덥기도 했고) 그냥 뒤에 바닥에 앉아서 들었다. 이걸 봤는지 나중에 MC가 참가자들에게 자리를 조금 밀착해서 공간을 내어달라고 요청했기 때문에 여유롭게 뒷자석에 앉아서 들을 수 있었다.

 

진행은 일정보다 조금 빨리 진행되었는데 대부분의 발표자들이 발표를 5분, 10분 정도 일찍 끝내서 쉬는 시간이 길어졌기 때문에 제공된 토스트와 물을 먹으면서 점심을 때웠다. 아이스 커피는 플라스틱 아이스박스(캐그?)같은 통에 담아왔는데 금방 다 떨어졌다. 뜨거운 커피는 엄두도 내지 못했다.

 

발표내용을 간단히 요약하면 다음과 같다.

제가 당신을 뽑아야 할 이유가 뭔가요?

이 세션은 가장 기대하던 부분이었는데 사실 저 질문을 나 자신에게 물어보아도 알 수 없었기 때문이다. 다른 세션들이 인턴 합격 후 어떻게 해야 하는지에 중점을 맞추고 있었다면 이 세션에서는 인턴의 채용 목적 및 배경에 대해서 설명했기 때문에 인턴에 대해 다른 시각을 가질 수 있었다.

Manager, Senior, Junior

인턴에 대해 얘기하기 전에 '팀'이란 무엇일까? 이는 각자의 역할을 수행하며 공동의 목표를 향해 나아가는 사람들의 집합체라고 할 수 있다. Manager, Senior, Junior로 이루어지는데 각자의 역할을 알아보자.

 

Manager는 팀을 구성하고 목표를 세워 멤버들이 역량을 발휘할 수 있도록 만들어주는 사람이다. 팀은 사람들이 모인다고 팀이 되는 것이 아니라 팀워크를 이끌어 내는 것이 중요하기 때문에 팀 빌딩을 수행해야 한다. 또한 업무 비율의 점검을 통해 인사, 개발 진척 문의, 새로 들어온 정보 등을 처리하는데 이는 필연적으로 시간을 많이 잡아먹기 때문에 권한을 위임해서 이를 분배한다. 즉 앞서 나가기보다는 다른 사람들을 이끌어주고 능력을 발휘할 수 있도록 하는 것이 중요하다.

 

Senior는 개발과 커뮤니케이션을 안정적으로 진행해서 업무를 스스로 처리할 수 있는 사람을 의미한다. 즉 개발, 커뮤니케이션, 관리 세 가지가 모두 가능한 사람을 Senior라 부르며 이들은 그냥 알아서 잘 하면서 예상되는 문제점, 이슈, 업무 성과 결과물을 만드는 역할을 수행한다. 팀에서 가장 핵심이 되는 인물.

 

Junior는 왜 필요하게 될까? 이들은 Senior가 더 중요한 일에 집중할 수 있도록 뽑는 것이다. Senior는 중요한 만큼 그 시간이 절대적으로 부족하므로 Junior가 와서 거들어주면 시간을 더 절약할 수도 있고 다른 이유로 팀의 엔트로피를 낮춰 팀이 고착되지 않고 더 활발하게 만들어 주는 역할을 수행하기도 한다. 잘할까봐 뽑는 이유도 있다.

그렇다면 이들은 어떻게 일하면 될까? Senior와 반대로 알아서 잘 하지 않는 것이다. 시키는 것만 하는 게 아니라 확인-진행-공유 프로세스를 거쳐야 하는데 혼자서 하지 않고 확인받고 진행한 후 공유한 뒤 다시 확인을 받는 과정을 반복하다가 이제는 확인받지 않아도 된다라고 권한을 위임받았을 때 Senior가 되는 것이다.

 

우리가 인턴에 지원하든 신입사원으로 지원하든 결국 상대하는 것은 회사가 아니라 사람이다. 즉 입사지원을 할 때 우리는 회사에 지원하다고 생각을 하지만 면접은 결국 사람(Senior, Junior)이 보기 때문에 관점의 변화를 꾀할 필요가 있다.

우리가 매니저가 된다면?

우리가 매니저가 되어서 우리의 지원서를 본다면 어떤 관점일까?

 

이력서를 쓰는 과정은 쇼미더머니 예선과 비슷하다. 처음부터 지루하게 시작하면 목걸이를 받지 못하고 그냥 집에 가게되는 것이다. 비슷하게 LINE에 지원할 때 LINE 재직자인 채용담당관에게 LINE에 대해 설명한다거나 가족관계를 설명하거나 팀프로젝트에서 어떤 역할을 맡았는지 등 장황하게 시작하는 것은 좋지 않다고 하였다. 우리가 경력직이 아닌 이상 우리가 뽑는 것은 Junior기 때문에 Manager의 역할을 수행한 경험이나 팀프로젝트에서 다른 팀원들의 단점을 어떻게 메꾸고 어떤 상을 수상하고 학점이 어떻게 나오고.. 같은 내용은 적절하지 않다는 관점에서였다. 지원서에는 교내에서 주최한 어떤 상을 수상하고 어떤 프로젝트를 진행하였다고 써놨는데 막상 보니 생각보다 별거 아닌 경우도 많다고 하였다.

 

사실 실무자의 입장에서 보면 쌓여가는 메일과 발생하는 이슈 사이에서 수백명의 지원서를 읽는 것은 무리가 있다고 하였다. 즉 좋은 내용을 써도 충분히 읽어볼 시간이 없는 것이 문제.

 

또한 대부분의 학부생들은 여러가지를 얕게 했어도 한 분야에 대해서 깊게 파내려간 사람은 많이 없는데 이렇게 깊게 파본 경험이나 자신의 역할이 명확하고 결론이 남다르거나, 자신이 받은 과제를 수행하는 데 그치지 않고 리팩토링했다던가 처음부터 끝까지 만든 자신만의 프로젝트가 있다던가 하는 경험이 있다면 좋다고 하였다.

 

즉 우리 스스로가 Manager가 되어서 이 사람이 우리 팀에 와서 도움이 되고 사람들과 잘 어울릴 수 있는 사람인지 지원서를 다시 한번 읽어보도록 하자.

But, the important part is from now on

하지만 인턴에 합격했다고 끝일까? 전혀 그렇지 않다. 오히려 넘어여 할 산은 더 많고 중요한 것은 지금부터 시작이다. 이 세미나의 주제처럼 '슬기로운 인턴생활'을 수행하려면 어떻게 해야 할까?

 

사실 인턴에서 좋은 평가를 받는 가장 좋은 방법은 실력을 증명하는 것이다. 하지만 모두가 실력이 특출날 수는 없고 다들 비슷할 수도 있기 때문에 이것이 어렵다면 멘토들이 불안하지 않게, 귀찮지 않게 즉 적은 신경을 써서 결과물을 만들어내는 것이 좋다. 위에서 언급한 알아서 잘 하지 않는 것을 생각해보면 된다.

 

업무를 논의하거나 지시를 받으면 열심히 듣고, 자신이 들은 게 맞는지 확인하고, 진행 상태를 정리해서 가끔 구두로 짧게 보고하는 등 빠른 결과에 욕심내지 않고 제대로 진행하려는 노력을 보여줘야 한다. 내가 진행하고 있는 방향이 맞는지를 확인하는 것 역시 중요한데 막상 열심히 만들었더니 잘못 만들었다면 쓸모가 없기 때문.

 

즉 안심하고 일을 맡길 수 있는지, 미흡하지만 많은 고민과 노력을 기울이는지를 평가하는 것이다. 우리에 대한 기대치는 낮기 때문에 이 사람이 어떤 자세로 어떻게 우리와 같이 발전해 나갈 수 있는지를 보려는 것이다.

 

하지만 사람들에게 우리를 각인시킬 기회는 좀처럼 오지 않기 때문에 사람들을 마주치면 전부 다 선배들이라 생각하고 먼저 다가가서 인사하고 성실하게 인턴을 진행하도록 하자.

"오랫동안 큰 소리로 계속 문을 두드리면 반드시 누군가 일어나 그 문을 열어줄 것이다." -롱펠로

인턴 경험으로 성장하기, 그리고 더 알차게 성장하기

이 발표자는 방학때 인턴을 웹 애플리케이션, 백엔드 쪽으로 다녀왔는데 인턴을 하게 된 이유가 새로웠다. 깃허브에 있는 백엔드 로드맵을 따라가면서 프레임워크 등을 다루고 여러 프로젝트등을 진행하다 보니 어느 순간 슬럼프가 와서 기술의 발전을 느끼지 못하고 형상 관리 등에 대한 배움의 욕구때문에 이를 타파하기 위해서 인턴을 다녀왔다고 했다.

 

이 인턴을 통해서 회사의 프로세스에 대한 경험과 엔지니어로서의 성장을 동시에 꾀할 수 있었다.

회사의 프로세스는 팀의 협업에 대해서 좋은 경험이 되었는데 웹이나 앱을 만들고 끝이 아니라 버전 관리, 배포, 신규 기능 기획 등을 수행하고 비 개발자 사람들과의 소통을 통해 엔지니어로써 팀과 일하는 방법을 알 수 있었다고 하였다.

 

또한 VCS, Git, Github, Gitflow 등을 활용하면서 엔지니어로서의 성장을 가장 크게 느꼈고 Code Review를 함으로써 코드를 많이 발전시킬 수 있었는데 학생이 아닌 엔지니어로써 일하면서 다른 엔지니어들의 여러 코멘트를 반영하여 수정하는 과정을 거쳐 성장할 수 있었다.

 

또한 기존에 프로젝트를 수행할 때는 SFTP, SSH, CLI를 통해 진행하였으나 Github, CircleCI를 통한 Lint Check, Unit Test, Test Code Coverage, Deployment 등의 과정을 거쳐 체계적으로 작업을 수행하게 되면서 개인, 팀 프로젝트에서 배우기 어려운 내용들을 배울 수 있었다.

그렇다면 어떻게 준비하면 좋을까?

1. Open Source Contribution
   꼭 기여하는 것이 아니라도 관심있는 오픈소스 프로젝트들을 찾아보면서 Contribution guideline, Issue, Pull Request 등을 살펴보면서 코드 리뷰 및 개발의 과정을 확인해 봄으로써 미리 경험해 본다면 도움이 될 것이다.
2. Team project
   팀 프로젝트를 진행하면서 소통/협업 툴의 사용에 익숙해지는 것이 좋다. Trello, Slack, Git 등. 그리고 Lint, Test framework를 통해서 코드를 확인하고 Lint에 따라 코드를 작성하는 습관을 들이고 다른 사람들과 코드 리뷰를 수행한다면 더욱 좋다.
3. Git 공부하기
   Git의 모든 기능을 알려고 하디보다는 저장소를 만들어서 commit, merge, pull 등을 해보도록 하자. 이때 commit, push, pull의 반복으로 conflict가 발생하는 커밋이나 의미없는 버전관리를 수행하지 않도록 주의! Git Workflow에 대해서도 알아보고 Github Fork, Upstream 설정, Rebase, Revert, Fetch 등에 대해서도 추가적으로 알아보도록 하자.

오픈소스든 팀프로젝트든 다양한 프로젝트를 경험하면서 다양한 기술 스택을 쌓고 학습 능력 및 전체적인 프로젝트 이해 능력을 높이는 것이 목적이다. 팀에 들어가서 일을 하게 된다면 우리가 원하는 부분을 개발하는 것이 아니라 이미 잘 짜여진 프로젝트에서 정해진 부분만 개발하기 때문. 즉 내가 좋아하는 것만 하다보면 다른 업무를 할 때 어려움이 많을 것이다.

 

또 스타트업 채용 박람회 같은곳에 다니는 것을 추천하였는데 발표자도 여기서 면접 일정을 잡고 들어가게 되었다고 한다. 자신이 부족하다고 생각되더라도 관심있는 회사, 팀에 가서 이야기를 해보면 어떤 직군이 현업에서 많이 필요하고 무엇을 준비해야할지 알 수 있을 것이다. 자신이 대학생이며 어느 부분에 관심이 있어서 왔다고 구체적, 적극적으로 설명하고 어필한다면 좋은 결과를 얻을 수 있을 것.

 

물론 인사 담당자를 통해 회사를 파악(기술 직군의 발전 가능성, 사내 문화 등)하는 것도 중요하다.

인턴이라면 꼭 해야할 3가지

발표자는 Naver Clova NSML 인턴을 3개월 동안 수행하였고 그에 따른 느낀점들을 발표하였다.

체험형 인턴

대부분 경력 공고였지만 체험형 인턴이 있는 것을 발견하고 발표자는 이에 지원하여 서류 통과 및 코딩 테스트를 보고 들어갔다. NSML은 딥러닝 클라우드 플랫폼이지만 AI를 잘 몰랐는데 웹 Front-End에 지원하였기에 큰 문제는 없었다.

 

이곳에 들어가기 전에 여러 프로젝트들을 수행한 것이 도움이 되었다. 조직(네이버)에서 제공하는 얼굴인식 API를 이용하여 Flask, Docker, AWS를 이용한 토이 프로젝트와 슬랙 날씨알림 봇 등 여러 프로젝트를 진행하면서 Docker의 장점에 대해 알게 된 것이 도움이 되었다고 한다(NSML이 Docker를 사용).

초심을 잃지 말자

초심을 잃지 않는 것 역시 중요한데 인턴을 수행하면서 열정적으로 배워야겠다는 마음가짐을 업무를 진행하면서 느끼는 한계때문에 잃어버리지 않도록 주의하라고 하였다. 인턴은 모르는 것이 당연하므로 이에 대해서 질문을 자주 하면서 어려운 부분을 극복하는 것이 도움이 되었다고 한다. 잘 모르는 것에 대해서는 그림을 그리거나 질문 리스트를 만들어서 잘 이해하고 있는지 스스로 확인함으로써 자신감을 얻을 수 있었다고 한다.

프로답게 일하기

인턴이라고 해도 돈을 받고 일하는 사람이기 때문에 프로답게 일하도록 하자. 에러 핸들링이나 유지보수, 네이밍을 잘 해서 나중에 다른 사람이 개발하기 쉽게 만든다던가.

 

IT기업은 대부분 수평적인 문화로 되어 있기 때문에 상사보다는 같이 일하는 동료가 우선시되며 논의할 사항(컨퍼런스 참가 등 업무에 영향을 주는 것)이 있다면 먼저 동료에게 논의하도록 하자. 또한 의견은 적극적으로 제시하는 것이 좋다.

 

자잘한 거지만 카페를 자주 가면서 팀원들과 친해져서 이런저런 조언도 듣고 인연도 쌓을 수 있었고 인턴을 하면서 기업 자체는 대기업일지라도 팀 자체는 또다른 스타트업이라는 느낌을 받았다고 한다. 개발 방식이나 회의 방식, 밥 먹는 방식까지도 팀마다 달랐기 때문. 그렇기에 회사를 알아보는 것도 중요하지만 자신이 들어가게 될 팀에 대해서 기술 스택이나 자신의 성장 여부 등을 알아본다면 더 좋을 것.

It was my intern. Now is your turn

이번 발표는 과거의 자신이 인턴을 수행하며 쓴 글을 지금 다시 돌아보면서 회고하는 방식으로 발표를 진행하였다. 

값진 경험?

발표자는 막 시작한 스타트업에 인턴으로 참가했기 대문에 굉장히 초반이었고 대신에 낯선 장소에서 낯선 사람들과 식구가 되어 개발자로서의 경험을 쌓는다는 것을 굉장히 값진 경험이라 생각했었다. 하지만 지금에서야 돌아본다면 그때는 모든 경험이 다 값진 경험이었지만, 실제로 원하는 바를 이뤄보는 것이 값진 경험이라고 발표자는 말했다.

자신이 들어갈 회사와 거기서 만들 서비스, 목표에 대해서 확실히 하고 들어가서 기대했던 모습으로 서비스를 만들었을 때 그것을 값진 경험이라 할 수 있을 것이다.

즉 목적, 방향, 방법이 정의되어 목적한 곳에 올바른 방법을 통해 제대로 도달했을 때 값진 경험이 될 것이다.

긴 회의?

발표자는 회의를 하는게 재밌었고 할말도 많지만 길어지면서 힘들었고 그래서 역시 개발은 힘들구나 하는 생각을 가졌었다. 하지만 이것은 지금 돌아보면 단지 내가 회의를 하고 있다는 유능감, 소속감에 불과하였다.

 

회의를 하면서 인지해야 할 것은 우리가 앞으로 어떻게 해야 할 지를 계획하고 서로의 의견을 교환, 합치하는 과정일 뿐 소속감을 이끌어내는 과정이 아니기 때문에 회의를 진행하기 전에 Summary를 두고 두괄식으로 말하는 습관을 들이는 것이 좋다고 하였다.

배워야 할 게 많다

스타트업에서 이런저런 일을 하고 여러 툴을 다루다보면 직무와 다른 일(영상 편집 등)도 하게 될 텐데 이때는 내가 이 일을 배워서 할 만큼 중요한 일인가에 대해서 스스로 자문하는 습관을 들이는 것이 좋다고 하였다. 새로운 것을 배워서 결과물을 만드는 것과 이미 아는 것을 통해 결과물을 만드는 것 둘 중 어떤 것이 더 효율적으로 우리 서비스에 기여할 수 있을지를 고민해보는 까칠한 인턴이 되보는 것도 좋다고 하였다.(이는 다른 발표자에게서 비판받았다... 그때 회사의 입장에서는 필요한 일이었을 것.)

식어버린 열정

미뤄지는 런칭 등 여러가지 이유에 의해서 의욕을 잃고 열정이 식은 과거의 자신을 보면서 발표자는 이것이 내가 열심히 일하는 노력에 따른 결과물이 나오지 않는 것에 따른 모습이라 하였다. 기대와 충족이 반복되는 노력의 선순환이 구성된다면 좋겠지만 기대와 실망이 반복되는 악순환에 빠지게 되는 것이 그 원인이라 했는데, 그렇다면 여기서 어떻게 빠져나올 수 있을까?

 

이것은 바로 회사에서의 기대와 내 기대를 분리하는 것이다.

(회사에 대한)기대, 불충족, 절망, 권태의 수순을 밟기 전에 회사의 일은 Out of Control, 즉 내가 원하는 결과물이 나오지 않을 수도 있고 프로젝트가 아예 엎어질 수도 있기 때문에 이 기대를 나의 성장에 대한 기대로 바꾸는 것이 그 해답이라 하였다.

 

토이프로젝트, 블로그, 발표, 취미 등 회사와 무관한 성공 목표를 세운다면 열정을 좀 더 오래 유지할 수 있을 것이다.

멘토스랑 인턴콜라

이 발표자는 16년에 개발을 시작해서 17년에 LINE 인턴, NAVER 인턴 후 NAVER에 입사했다.

 

처음 인턴을 할 때는 사소한 질문이나 기본적인 일정도 면접처럼 느껴지고 모르는 게 너무 많아서 망했다 라고 생각할 정도로 자신이 없었는데, 인턴에게 주어지는 과제 중 하나를 고를 때 '제가 공부하고 선택해도 될까요' 라고 물어보지 못한 것을 후회한다는 점이 인상깊었다.

 

인턴이 된다는 것은 팀에 속한다는 것인데 사실 이 '팀'은 생각보다 완벽하지 않을 수 있다. 부족한 것도 많고 잘 안되고 있는 것도 많은데 발표자는 이를 관성에 비유하였다. 운동을 계속 유지하려는 성질처럼 팀도 마찬가지로 바쁘니까 그냥 하던대로 하는 관행(지루한 반복적인 업무, 잦은 커뮤니케이션, 산재된 기술 공유 등)을 유지하게 되는 것. 이를 해결하기에는 너무 바빠서 시간이 없는 것이다.

 

그래서 이를 해결하기 위해 Notion, Slack, Probot, Jenkins, Travis CI, Yeoman 등을 사용하여 Generator, Bot, Automation을 구현하였다고 한다.

 

인턴을 합격하여 멘토를 할당받을 때, 멘토는 인턴에게 무엇을 기대할까? 즉, 직설적으로 말하면 어떻게 인턴에서 정직원으로 전환될 수 있을까? 이는 크게 다음과 같다.

• 스스로 학습하는 능력
  소프트웨어 개발 방법론, 개발 환경과 인프라, 네트워크 등 여러 분야에 대해서 자신만의 학습 방법을 개발하자.
• 원인을 찾고 기록하는 습관
  내 개인적인 경험에 비교하면 해군 부사관들이 쓰던 Tech-Note가 생각나는 TIL(Today I Learned) 노트를 작성하는 것. 시키지 않아도 따로 쓰면서 디버깅을 마주하고 그에 대한 시도들을 문서화 하여 정리하는 것이다.
• 원활한 커뮤니케이션
  질문을 할 때도 현재 어떤 상황이며 어떤 시도들을 했었고 궁극적으로 해결하고자 하는 것이 무엇인지를 동반하여 멘토에게 질문한다면 멘토가 같은 삽질을 반복하는 일이 없어지는 것처럼 멘토-인턴 간 커뮤니케이션이 원활하게 수행되는 것이 좋다.

멘토와 코드 리뷰를 수행할 때는 근거(레퍼런스 등)에 기반한 의견을 제시하거나 센스 있는 코멘트(commit 링크 등)를 남기고 지적 뿐 아니라 질문이 오고간다면 긍정적인 결과를 가져올 수 있을 것이라 하였다. 이때 직접 찾아가서 대화하는 것은 업무의 흐름이 끊길 수 있으니 E-Mail, Slack, PR 등 비동기적 커뮤니케이션을 활용한다면 더욱 좋을것.

 

그 외에 여러 질문들이 오고갔는데 그에 대한 답변을 적어보자면 다음과 같다.

Q. 인턴은 야근/주말 출근을 통해 열정을 보여야 하나?

A. No. 제시간에 앉아있는 성실성이 더 중요. 야근/주말 출근까지 했는데 성과가 이것밖에 안되나? 싶을 수도 있으니....

 

Q. 과제를 완벽하게 해내는 것이 중요한가?

A. No. 과제를 설정할 때는 멘토와 Senior가 인턴의 수준을 모르는 상태이므로 이 과제를 어떻게 학습하고 맞닥뜨린 문제를 어떻게 해결했는지가 더 중요하다. 이를 증명하기 위해서 TIL 문서를 활용할 수 있는 것.

 

Q. 인턴은 코드 리뷰를 받기만 해야 할까?

A. No. 모르는 것은 질문하고 리뷰할 것에 대해서는 근거와 함께 정확히 주장한다면 좋다.

 

Q. 모르는 것을 물어보면 좋지 않은 평가를 받을까?

A. No. 모르는 것이 있다면 무엇이 문제인지, 무엇을 모르겠는지 정리해서 질문하도록 하자. 평가에는 아무런 영향이없고 오히려 선순환 구조를 이끌어 낼 수 있을 것.

 

Q. 프로젝트 설계 및 업무 일정은 인턴의 일이 아니다?
A. No. 마라톤에서 페이스 조절은 자신밖에 할 수 없는 것처럼 인턴도 팀원의 일원으로써 아이디어를 제기하거나 일정을 제시할 수 있다.

 

물론 이는 전부 회사, 팀, 사람에 따라 다른 것이고 같이 일하는 사람들이 전부 대단해 보이더라도 겁먹지 말 것!

패널 토크

이는 발표가 전부 끝나고 참가자들이 적은 질문에 대하여 발표자들이 몇개 골라서 답변하는 형식으로 진행되었다.

코딩 테스트는 어느정도 수준까지 원할까?

• 회사마다 다르리라 생각한다. 카카오 블라인드까지 원할 수도 있고 단순 알고리즘일수도 있지만 간단한 Todo앱, CRUD 컨셉을 구현할 수 있거나 그에 대해서 알고 있다면 합격할 수 있을 것.
• 조직마다 다르지만 인턴이나 신입들에게 원하는 것은 대학교 때 배운 능력을 충분히 잘 수료했는지 여부다. 다른 발표자가 말했던 것처럼 '프로'를 뽑아야 하므로 기본기가 잘 되어 있어야 함.
• 기본적인 자료구조는 알고 있어야 하며 내 경우에는 수행한 프로젝트의 기술적인 부분이나 면접관이 물어보는 자료구조에 대해서 화이트보드에 쓰는 방식으로 진행했다.
• LeetCode, 백준 등에서 연습해보면 도움이 될 것.
• '알고리즘의 필요성'이라는 글을 읽어보면 도움이 될 것 같다. 대학교 수준정도만 하면 되지 않을까 라고 생각함.
• 처음에는 코딩 테스트에 나오는 문제를 다 맞아야지 라고 생각했었는데 욕심부리지 않고 하나를 풀더라도 완벽하게 풀어보는 것이 좋다.

첫 인턴은 언제 가는것이 좋을까?

• 인턴은 최대한 빨리 가는것이 좋다고 생각한다. 인턴에 합격했다는 것은 그만한 수준이 됬다는 것이기에 자신의 실력을 알 수 있는 방법이기도 하고.
• 인턴을 나갈 수 있다는 생각이 들면 언제든지 도전해 볼 것.
• 개인 공부만으로는 성장이 어려울 때 생각해보면 좋다고 생각함.
• 인턴 경험을 빨리 해보는 것은 좋지만 어떤 조직에서는 3, 4학년때 인턴 결과가 좋으면 졸업 후 취업연계를 생각하기도 하니 자기 자신이 생각하기에도 실력이 된다고 생각할 때 지원하는 것을 추천. 회사는 학습의 단계가 아니고 돈을 받고 일하는 '프로'들이 다니는 곳이기 때문에.
• 앞서 말한 것처럼 회사는 학습의 단계가 아니지만 학교에서 배운 과목들을 어떻게 쓰는지 효용을 느낄 수 있기 때문에 학습을 더 효과적으로 할 수 있으므로 대학을 다니다가 방향성을 확인하는 맥락으로 가면 좋다.
• 공부한 내용을 검증하고 퍼포먼스를 내보고 싶을 때가 적절하지 않을까 라고 요약할 수 있을듯.

내가 가고싶은 부서는 어떻게 정하면 될까?

• 내가 가고싶은 부서보다 내가 어떤 형태의 개발자가 되고 싶은지를 정의하고 그에 이 부서, 회사가 일치하는 방향을 가지는지 확인한 후 부서를 선택하는 것이 좋다고 생각함. 잘할 수 있는 곳이나.
• 본인이 뭘 잘하고 어느쪽으로 관심이 있어서 많이 해봤는지가 명확해야 한다. 물론 내부에서도 잘 모르는 부서들을 외부에서는 더욱 알기 어렵지만 자신의 감정과 방향이 뚜렷하게 드러난다면 그 부서에서 자신을 데려갈 것.
• 자신이 잘하는 것을 1순위로 고려하는 것이 맞지 않나 생각함.
• 가고싶은 분야를 본인에게 질문하고 그에 대해서 어필하면 부서는 저절로 따라오지 않을까 생각함.

처음 이력서를 쓸 때는 어떻게 해야 할까?

• 처음 인턴을 지원할 때는 경력이 없으니까 자기소개서 같은 느낌으로 쓰면 된다. 하지만 자기소개서만 보고 이 사람이 궁금하지 않다 싶으면 면접을 보지 않으므로 자신이 궁금하도록 써야 한다. 또한 기술 스택을 줄줄이 나열하는 것보다는 면접관이 얘기해보고 싶은 느낌이 드는 자기소개서를 작성하는 것이 좋다.
• 자소설닷컴에서 '첨삭'기능을 사용했음. 또한 체험형 인턴을 지원한다면 그 공고에 나와있는 항목에 대한 얘기를 더 하고 자신이 수행한 프로젝트에 대해서 최대한 구체적으로 적자.
• 원티드에서 이력서쓰는 서비스를 사용했음. 회사와 학생의 관점은 다르기때문에 실무자나 주변인에게 첨삭을 많이 받고 프로젝트에 대해서 자세히 적는 것이 좋다.
• 궁금하게 만들어야 하지만 쓸데없는 객기는 지양할 것. 그러면서도 장황하지 않게 나는 이것도 해봤고 저것도 해봤고가 아니라 나는 이러한 강점이 있는 사람이다를 어필해야 한다.
• 남들이 다 하는 것을 나열하는 것보다 이것만큼은 나의 강점이고 깊게 공부해왔다. 이 문제는 나만 겪어봤을 것이다 같은 매력적인 모습을 보이는 게 좋다.
• 원티드, 케이크레지메 등에서 잘 짜여진 이력서 포맷을 써서 가독성을 높이면 도움이 될 것.

그외

Q. 해봤던 프로젝트는 어떤게 있나요?

A. Todo 애플리케이션을 여러가지 스택(Vanilla JS, JQuery, NVP, ...)으로 만들어봤다. 이걸 포트폴리오도 냈더니 면접관이 재밌어 했던 경험이 있다. 새로운 라이브러리나 프레임워크를 공부할 때 무언가를 만들어보면서 하는 게 제일 좋은데 새로운 걸 만들기보다 기존에 만들었던 걸 만드는 게 시간도 절약되고 좋아서 그렇게 했다.

 

Q. 프로젝트는 어떻게 하는게 좋을까요?

A. 혼자만의 무언가를 해서 가져오는 것을 추천한다. 하나를 주제를 정해야 공부할 내용이 나오는 것인데 자기가 Needs가 있다면 공부를 하고, 시행착오를 하면서 잘 만들고 싶은 욕심이 생기기 마련이다. 그렇기 때문에 큰 것보다는 작은 것부터 시작해보면서 하는 것을 추천한다.

 

Q. 개발을 공부한 지 1년도 안되서 어떻게 대기업에 입사하게 되었나요?

A. 대회 탈락, 대학교 자퇴 등이 원동력이 되었다. 또한 블로그 포스팅을 하루에 하나씩 했는데 단순 스크랩이 아니라 남들에게 보여준다는 마음가짐으로 지식을 정리하니 기억도 잘나고 보기도 편했다. CS 과목들은 프로젝트들을 진행하면서 Top-Down 방식으로 공부했다.

 

Q. 모집공고를 보면 지원요건, 우대사항이 있는데 우대사항을 꼭 맞춰와야 하나요?

A. 우대사항을 채워서 오는 학생을 본 적이 없다. 우대사항은 현재 우리가 사용하고 있거나 사용할 기술이고 대신 기본역량이 되어야 이를 사용하거나 말거나 할테니 지원요건을 잘 다져서 오는 것이 좋다. 물론 아예 모르는 것보다는 조금이라도 학습해서 알아오는 것도 좋지만 이를 기대하지는 않고 중요한 것은 기본기다.

 

Q. 블로그 포스팅 말고 또 무엇을 했나요?

A. 블로그말고도 TIL도 작성했고 로켓펀치라는 곳에 자신의 이력을 홍보하거나 자신의 개발 철학, 학습 기록등을 블로그에 적기도 했다. 물론 이런것으로 채용되는 것은 일반적인 케이스가 아니고 성실함의 지표를 나타내는 것이라 생각하면 된다.

 

Q. TIL은 어떻게 작성하면 좋을까요?

A. 이는 멘토, 팀원들에게 공유하는 식으로 작성하는 것이 좋다. 자신이 삽질했던 내용을 적는 것인데 내가 까먹을 수도 있으니 적어놓는 것이기 때문에...

 

Q. 리팩토링한 것도 이력서에 적을 만한 경험이 될까?

A. 물론이다. 모든 것은 경험이 되고 적을 수 있지만 어느것이 가장 관심을 가질만한 것인지는 추려내야 한다. 물론 개발의 기본적인 소양(클린 코드 등)을 적으려 한다면 면접관 입장에서는 이걸 가지고 무엇을 시킬 수 있을지 모르기 때문에 이력서에 녹여내기 힘들다. 그리고 리팩토링은 의외로 그렇게 간단한 게 아니기 때문에 괜찮은 프로젝트일 수 있다. 기존에 어떤 문제가 있었으며 어떤 디자인 패턴을 적용하여 어떤 결과를 얻었는지 등을 보이면 더욱 좋고.

 

Q. 스타트업 인턴은 어떤 장점이 있을까?

A. 스타트업에 들어간다고 더 많이 배우는 그런것은 아니고 개발자 이외의 관점에 대해서 알 수 있는 기회가 좀 더 일찍 온다는 장점이 있다. 기술의 깊이를 늘려가거나 역량 개발, 문화 체험에는 규모가 있는 곳이 더 좋을 수 있지만 스타트업 생태계나 자신이 하고 있는 일이 전체 프로젝트에 어떻게 영향을 미치는 지를 알 수 있다는게 장점이 된다.

 

물론 이들은 전부 정답이라 할 수 없고 회사, 팀마다 다르기 때문에 이런 관점도 있구나 하고 받아들이는 것이 좋다.

후기

인턴에 대해서는 학교에서 단기, 장기 IPP 등에 대해 알아보면서 약간의 관심을 가지게 되었지만 곧 흥미를 잃고 자세히 알아보지 않았던 것 같다. 하지만 발표를 듣고 나니, 그리고 질의응답 때 사람들이 물어본 질문(포스트잇으로 제출)을 보니 다들 간절하고 인턴이 되기 위해 열심히 노력하고 있다는 것을 느낄 수 있었다. 내년쯤에 가야지 하고 어영부영 생각하고 있었는데 그 생각을 고치게 된 계기가 되었다.