올해 3월부터 6월까지 약 3개월간 했던 네이버 인턴십 후기를 작성하려 한다.

계속 써야지 써야지 하면서 미루다가 인턴십이 끝난 지 거의 2달가량이 돼서 사실 시간이 꽤 많이 지났지만, 아무래도 첫 면접, 첫 실무의 기억이기 때문에 아직도 생생해서 기록으로 남긴다 :)

인턴십 준비 과정

1학년 때는 대학 개발 동아리를 위주로 2~3학년 때는 각종 회사 연계 대외활동을 위주로 내 개발 실력을 한 단계씩 높이려는데 목적이 있었다. 하지만 더 이상 대학생들 사이가 아닌 더 많은 현직자분들을 만나고 나도 현직자로 나아가고 싶다는 생각을 가지게 되었다.

그래서 3학년 2학기 말에는  네이버 핵 데이, 우아한 프리코스부터 시작해서 대학생 프로젝트에서 인턴십 및 취업으로 나아갈 수 있는 활동에 몰두했었다. 하지만 두 프로그램 모두 인턴십, 테크 코스까지는 이어지지 못했고, 안 좋은 결과에 기가 죽기보다는 오히려 시선을 돌려서 인턴십에 직접 지원을 하자고 마음을 먹게 되었다.

아무래도 네이버 핵데이를 2번이나 참가하다 보니 네이버라는 회사는 나에게 시작점이 되고 싶은 회사였다. 직접 작성한 레주메를 바탕으로 마침 기회가 생겨서 의도치 않게 네이버 인턴십에 여러 프로세스로 지원을 하게 되었는데

1. 클로바에 12월 경 교수님 추천으로 인턴십 지원을 하게 되었고, 서류 -> 코딩 테스트 후에 결과를 기다리고 있었다.

2. 클로바 코딩 테스트 결과가 약 한 달 동안 안 나와서 떨어졌다 생각했고, 네이버 웹툰 체험형 인턴십을 지원했다. 그 결과 서류 통과 후 면접에 오라는 메일을 받았다.

3. 네이버 웹툰에 지원서를 낸 상태였는데 우연히 아폴로 CIC 쪽에 지인 추천으로 서류를 낼 수 있는 기회가 생겨, 서류 통과 후 면접을 보았다 (당시 매우 프로세스가 빨랐다)

4. 아폴로 CIC 쪽에서 가장 빠르게 합격 결과를 알려주어서 아폴로 CIC 백엔드 인턴십을 진행하게 되었다. (의도치 않게 3개 조직에 민폐를 끼친 건 아닌가 싶어서 당시 매우 조마조마하면서 웹툰 면접을 거절했다) (클로바에서도 면접에 오라는 연락을 받았지만 아폴로 입사가 확정이라 거절했다)

1차 면접

아폴로 CIC에서 본 면접이 내 인생 첫 인턴십 면접이었다. 그래서 당시 매우 떨리는 마음으로 면접을 봤던 기억이 난다. 당시에 무슨 깡이었는지ㅋㅋ 면접에서 물어볼 법한 컴퓨터 공학 지식에 대한 공부를 하나도 안 하고 갔다. (패기 봐라) 당시 외주 프로젝트 기한 때문에 면접 준비를 많이 못했었고, 같이 스터디를 했었던 자바봄(http://javabom.tistory.com/) 멤버들이 한번 봐줬던 모의 면접이 끝이었는데🧐그래서 잠을 못 자서 밤을 꼴닥 새우고 면접을 보러 갔었다.

나는 주로 기존에 알고 있던 Java와 관련된 지식, Cleancode, 자주 사용하던 test 관련 개념, 사용했던 디자인 패턴 위주 복습하고, 이전에 했던 프로젝트에서 사용했던 기술의 간단한 특징 정도를 리마인드하고 갔다.(queryDSL을 사용했을 때 장점 같은 것들!)

면접을 준비할 때는 기술에 대한 키워드만 적어두고 그 키워드에 대한 내용을 보기만 하기보다는, 실제로 다른 사람에게 전달한다 생각하고 말을 하면서 준비를 했었다. 이렇게 하다 보니 이 키워드에 대한 질문이 나왔을 때 어떤 흐름으로 대답을 해야겠다는 노하우가 생겨서 수월했다.👍

면접 질문은 크게 2가지 종류였다. 

1. 종이에 문제가 2가지 적혀있었고, 30분 동안 각 문제에 대한 해결법을 말로 풀어내는 것이었다. 문제 중 기억에 남는 문제가 있었는데 당시 복기해서 적어놨었다.

25마리의 말이 있습니다. 이중에 가장 순서대로 빠른 말 3마리를 찾아내고 싶습니다. 말의 절대 속도는 알 수가 없으며, 한 경주에 최대 5마리의 말이 참여할 수 있고, 그들의 상대적인 순위만을 알 수 있습니다 최소한의 횟수로 찾아내려면 어떤 방법을 써야 할까요?

이 문제를 풀 때 종이에 적어가며 설명을 드렸었는데, 처음에 낸 정답에 대해 "여기서 더 최적화할 수 있을 것 같아요!", "이런 경우엔 어떻게 해야 할까요?" 등의 질문을 면접관님이 넌지시 던져주셔서 정답에 도달할 수 있었다. 내 생각을 기반으로 면접관 님이랑 소통하면서 같이 정답에 도달한 느낌이라 아직도 기억에 남을 정도로 재미있었다👍

2. 두 번째로는 약 1시간 반 동안 자바에 대한 기술 질문이 이어졌다. JVM의 구조, GC의 동작 방식과 같은 기본적인 질문을 하시기도 했고, 내  깃허브에 들어가서 했던 프로젝트에서 dto와 domain 폴더링의 이유를 여쭤보셨던 기억도 난다. 외에도 테스트 코드를 짜면 좋은 점이나 테스트 코드를 짤 때 어떤 부분을 생각하며 짜는지를 여쭤보셨다.(자바 봄 스터디원들이 해준 모의 면접에 나왔던 질문이 많이 나와서 정말 좋았다)

그 결과 합격!!! 3월로 입사일이 정해지게 되었다.

당시 원래는 휴학을 하려 했었는데, 채용형 인턴십이었기 때문에 빠른 졸업이 필요해 4학년 1학기 학점을 인턴십으로 대체할 수 있도록 교수님과 조율하면서 정신없이 입사를 기다렸었다.

코로나로 인한 원격 입사

그렇지만 3월에 코로나 확진자 수가 급격하게 늘어나면서 입사일이 미뤄지는 사태가 발생했다. 많이 기다리던 입사일이었는데 코로나로 인해 걱정을 하면서 회사 측의 연락을 기다렸었다.

그 결과 입사일이 일주일이 미뤄졌었고, 미뤄진 입사일 조차도 네이버에서 풀 재택근무 체계로 들어가다 보니 원격 입사를 하게 되었다. OT 진행도 화상으로 했고, 각종 계약서도 모두 메일로 받았다.

그래서 입사일에 각종 회사 장비가 집으로 배송이 되었고, 당시 생활멘토, 기술멘토 멘토님이 두 분이 계셨는데 웍스로만 연락을 드리게 되었다.

그래서 입사일부터 약 한 달 반 정도 풀 재택근무를 했었다. 그리고 남은 한 달 반은 주 2회 출근을 했었어서 그때 팀원분들이나 멘토님들을 볼 수 있었다.

인턴 과제

입사 2일 후에 멘토님과 앞으로 인턴십 기간 동안 어떤 과제를 진행할지에 대한 부분을 이야기했었다. 나는 모먼트 팀 소속이었는데, 모먼트는 4월에 런칭된 서비스라서 한 달 동안 다른 분들께 내 부서를 설명할 때 둘러 대며 말했던 기억이 난다.

인턴 기간 동안 내가 했던 job은 3가지였다.

1. 이펙티브 자바와 클린 코드를 읽고 정리하기

2. 현재 모먼트 서버와 비슷한 환경의 토이 프로젝트를 진행하기
    2-1. 네이버 서비스를 연동하는 서버 만들기
    2-2. 만든 서버를 k8s를 이용하여 배포하기
    2-3. jenkins pipeline을 작성하여 해당 서버의 CI/CD 구축하기 
    2-4. sonarlint를 사용하여 코드 리팩터링 하기

3. 모먼트 서비스에 대한 분석 및 모먼트 팀 소속으로 회의 참석

1. 이펙티브 자바와 클린 코드를 읽고 정리하기

정리한 내용은 내 블로그에 조금씩 업로드를 하고 있다
https://jyami.tistory.com/category/Dev%20Book%20Review/Effective%20Java
다만 티스토리 에디터에 맞춰서 글을 조금 편집해야 하는 게 번거로워서 아직도 모든 문서를 올리지 못했다.. 크흐

책 읽는 과제를 하면서 내가 집중했던 건 모르는 구절이 나와도 넘어가지 않는 것이었다. 자바 봄 스터디에서 이 방식으로 책을 읽고 있어서 이 과제를 할 때도 영향을 줬었다.

다른 사람 블로그를 찾아보기도 하고, oracle docs를 찾아보기도 하고, 책에 있는 내용을 코드로 작성해보기도 했었다. 당시 prallel stream 부분을 읽으면서 forkjoinpool에 대한 이야기가 나왔었는데, JDK 코드를 보면서 까지 책을 읽었던 기억이 난다.

두 책이 인턴 과제였던 점은 아직까지도 영향을 미치고 있다. 사실 나는 개발 서적 읽는걸 별로 안 좋아했다. 대학원 생각이 없는 이유가 문서를 많이 읽어야 하는 게 싫어서였을 정도로 그런데, 당시 매주 정해진 분량에 대한 계획을 세우고 책을 읽었었는데 이 습관이 지금까지 이어지고 있다 (요즘은 하루에 한 챕터씩 자바 8 인 액션을 읽고 있다.)

생각보다 내가 잘 알고 있다고 생각했던 자바에는 공부를 계속해도 궁금한 점이 나왔었고, 실제로 내가 모르던 부분에 대한 키워드를 책에서 얻어서 몇 번 포스팅한 적이 있다.

https://jyami.tistory.com/112

https://jyami.tistory.com/99

그래서 이 과제 이후로 부터 책을 읽는다는 것에 거부감이 덜 생기게 되었고, 앞으로 읽고 싶은 책이 정말 많다. (실제로 많이 사뒀다..ㅎㅎ)

2. 현재 모먼트 서버와 비슷한 환경의 토이 프로젝트를 진행하기

주로 삽질속에서 성장을 하는 과정이었다ㅋㅋ 아무래도 당시 모먼트의 런칭이 얼마 안 되었을 때였고, 나의 집념도 한몫해서 멘토님께는 정말 해결이 안 될 때만 여쭤봤었다. 해결이 안 될 때에는 "어떤 부분을 하고 있는데, 이런 부분이 해결이 안돼서 이렇게 에러를 해결해 보려고 몇 가지 방법을 찾아보았습니다 제가 생각할 때는 이 부분이 문제인 것 같아 이 부분을 다시 찾아보려고 하는데 올바른 방향이 맞나요?" 이런 식의 현재의 상황을 브리핑하면서 조언을 얻는 방향으로 여쭤봤었다.

아무래도 구글링을 해서 바로 나오는 내용이면 좀 민망하기도 하고, 한심해 보이지 않을까 싶어서 그랬는데, 후에 멘토님 피드백으로 뭔가 혼자 알아서 해결하고 혼자 잘 정리해오는 스타일이었다고...ㅋㅋㅋㅋ 

2-1. 연동 서버 구현

먼저 네이버 api를 연동하여 여러 서비스의 response 값을 조회하고, 이 내용을 디비, 캐시에 CRUD 하는 서버를 만들었다. 사실 구현은 어렵지 않았지만 이 부분에서는 멘토님과의 커뮤니케이션을 많이 할 수 있었다. 요구사항에 대해 구체화하고, 나에게는 접근권한이 없는 docs 페이지의 경우엔 멘토님께 도움을 요청해야 구현까지 할 수 있었기 때문이다.

코드를 구현하면서 가장 내가 신경 썼던 것은 테스트 코드 작성이었다. 한 가지 기능을 구현할 때 그 기능과 대응하는 TC를 작성하려고 의식적으로 생각했었다. 그래서 구현 중간에 test line coverage를 측정해봤을 때 구현을 마치고 측정했을 때 모두 80프로 대가 나왔었다.

혼자 하는 과제이지만 테스트 코드는 내가 작성한 프로젝트의 요구사항을 알 수 있는 커뮤니케이션 수단이라고 생각했기 때문에, @DisplayName까지 꼼꼼하게 작성했었다 (미래의 내가 봤을 때 못 알아보는 경우를 그나마 방지하기 위해)

2-2. 컨테이너 환경에서의 배포

이렇게 완성한 서버를 k8s를 이용해서 배포해야 했었는데, 당시 나는 docker, k8s에 대한 지식이 전무했다. (대충 환경을 저장하는 게 도커구나 만 알고 있었음) 과제를 하면서 어떻게든 공부를 해야 하다 보니 익히게 되었는데 요즘 개발할 때 정말 유용하게 써먹고 있다ㅋㅋㅋ (얼마 전에 나간 엔젤핵의 배포 시스템이 dockerfile 기반이라 수월했다) 

당시 helm chart를 이용해서 pod 오브젝트 스펙들을 관리했었고, 사내 컨테이너 배포 시스템을 이용해 배포 파이프라인까지 모두 잘 작성하였다. 당시 과제 기한이 3주였는데 여기까지 다 했을 때 1주가 남아서, 추가적으로 HPA 설정, ELK 설정까지 도전해 볼 수 있었다.

이 부분에 대한 인턴 발표를 진행했을 때, 사내 컨테이너 배포 시스템의 불편한 점에 대해 언급했었다. 그때 한 개발자 님이 본인 팀에도 도입하려 했었는데 이런 불편함을 참고해서 개발해야겠다고 발표 내용이 인상적이라고 피드백 주셨었는데 진짜 뿌듯했었다.

배포를 하면서 여러 Devops적 지식을 알게 된 점이 있었다. 그래서 매일매일 위 사진처럼 트러블 슈팅에 대한 문서를 작성했었다. 근데 대부분의 말이 "다시 해보자." "왜 안되지" "으아아아ㅏㄱ!!" 이런 거였음ㅋ

2-3. jenkins pipeline을 이용한 CI/CD 

jenkins도 인턴 과제 덕분에 처음 사용해봤었다 (그동안은 팀원들이 해주던 CI/CD를 사용했었으니..)

역시나 삽질은 많이 했었는데, 삽질속에 깨달음이 많았음.. jenkins는 앞으로 사용할 일이 많으니 좋은 경험이었다 생각 중이다ㅋㅋ

아무래도 처음 jenkinsFile을 작성하다 보니 문법 오류도 나에겐 퍼포먼스 저하의 하나의 원인이었다. 그때 사내 github에 있는 소스코드를 가져와서 해당 소스 폴더에 있는 jenkinsFile을 읽어 jenkins pipeline을 실행하도록 했었는데 문제가 많았다.

1. jenkinsFile 문법이 맞는지 확인하려고 한 줄을 수정해도 그때그때 github에 push 했었다.

2. 후에 commit 내역이 더러워지고 있음을 깨닫고 force push를 막 했었다
그래도 github에 push를 계속해보면서 jenkinsFile을 테스트한다는 사실이 올바른 방법 같진 않았다.

3. 똑똑한 방법으로 발전! : jenkins안에서 jenkinsFile 동작을 확인할 수 있게 script 테스트
jenkins의 build 내역에 들어가서 replay 버튼을 이용해 작성한 스크립트의 재 빌드를 할 수 있었다. 이렇게 하니 그때그때 빌드 파이프라인이 잘 작동하는지 여부를 확인할 수 있었다. (앞으로 종종 써먹을 듯하다.)

2-4. sonarlint를 사용하여 코드 리팩터링 하기

마지막 1주에는 리팩터링 및 코드 품질을 향상하는 작업을 했었는데, 이때 테스트의 중요성을 다시 한번 느꼈다. 소나린트에 따라 소스를 리팩터링 할 때, 패키지 명을 바꾸는 간단한 리팩터링이더라도, 사람의 실수로 혹은 테스트 스코프가 벗어나서 등 다양한 이유로 소스가 안 돌아갈 수 있었다.

코드 악취가 146에서 13으로 줄어드는 걸 보면서도, 리팩터링 과정에서 에러가 없음을 보장받을 수 있는 수단이 TestCase 였다. 테스트의 중요성은 아무리 말해도 부족한 듯.

3. 모먼트 팀 소속 인턴

모먼트 팀의 소속으로 각종 회의에 참석하고 팀원 분들과 개발에 대한 이야기부터 앞으로 계획에 대한 이야기도 하면서 실무에 대한 이해를 높일 수 있었다.

인턴 시작 3일 때 모먼트 프로세스 문서를 보고 궁금한 점을 정리했었는데, 실무가 아니면 몰랐을 사실들이 있었다. (예를 들면 DB설계 문서에서 Auto Increasement가 빠져있었는데, 분산 DB를 사용하기 때문이라는 사실이 너무 놀라웠다ㅋㅋㅋ)

팀원들과 일과를 보낼 때 나와 같은 인턴도 똑같은 개발자라는 마음으로 대해주셔서 좋았다.
일부 이슈 해결에 대한 일정이 있었음에도, 페어 프로그래밍으로 팀원들과 같이 도메인 지식의 수준을 동등하게 맞춰나가는 시니어 개발자님의 모습이 좋았다. 인턴임에도 옆에서 같이 보고 의견을 낼 수 있었고 환상으로만 있었던 이런 개발자 회사의 문화에 감동했었다.

그리고 코로나 시기 인턴으로서 팀원들 그리고 멘토님께 감사했던 점은 활발한 비대면 커뮤니케이션이었다! 사실 인턴십을 하면서 모르는 점을 물어볼 때 메신저로 갑자기 연락을 드리기가 죄송했었다(이건 내 성격이다. 다들 친절하셨음). 그래서 초반에는 차라리 직접 만나서 대면 인턴십을 진행했다면 좀 달랐을까 싶었는데, 뒤로 갈수록 비대면으로도 너무 의사소통이 잘돼서 재택을 사랑하게 되었다..ㅎㅎ

팀 내 시니어 개발자님이 나를 만나고 얼마 안 되었을 때, 갑자기 웍스로 "민정님 이 코드의 문제점이 뭘까요?" 하고 먼저 말을 걸어주셨는데, 코드에 대한 이야기를(Optional과 Null을 같이 사용할 때 문제점에 대한 이야기를 했었다.) 30분 내내 웍스로 집중해서 하다 보니까, 얼굴을 뵌 적이 없는 분임에도 내적 친밀감이 마구 상승했었다ㅋㅋㅋ

외에도, 과제를 하다가 의존성 때문에 문제가 생긴 적이 있었는데, 이 의존성 문제를 해결하려고 역시 웍스로 1시간 내내 커뮤니케이션하면서 해결했었다. 

또 팀원 분들과 많은 커피타임을 가지면서 운동의 중요성에 대한 부분을 정말 많이 들었었는데ㅋㅋ (사실 지금도 엄청 듣고 있다) 개발 외적으로도 자기 계발에 힘쓰는 분들과 일을 할 수 있어서 감사하다는 마음이 들었다.

인턴십 끝

배운 것들 부터해서 좋은 팀원 분들까지 얻은 게 너무 많은 인턴십이었지만, 아쉽게도 채용까지 이어지지는 못했다.

인턴 평가는 좋았으나, 전환면접 (2차 면접)에서 (다시 말하지만 나는 이 인턴십이 첫 기술면접이었다.) 너무 긴장한 나머지 나의 장점을 말하기보다는 내가 못하는 부분, 나의 단점을 더 드러내는 면접을 했었다.

어느 때보다 치열하게 살았던 3개월이었지만, 인턴십 자체만으로도 좋은 경험임을 알고 있기에 결과보다는 과정 위주로 기억이 남았다. (좋은 얘기만 있어서 포장이라 할 수 있는데, 포장아니다 ㄹㅇ 재밌었음)
아까운 결과이지만, 2달이 지났음에도 좋은 기억으로 남은 걸 보니 후기를 안 쓰면 후회할 것 같아서 기록으로 남긴다!

끝! 

I'd like to write about my Naver internship experience, which lasted about 3 months from March to June of this year.

I kept telling myself I'd write it up but kept putting it off, and now it's been almost 2 months since the internship ended, so quite a bit of time has passed. But since it was my first interview and first real work experience, the memories are still vivid, so I'm putting them down in writing :)

Preparing for the Internship

During my freshman year, I focused on university dev clubs, and in my sophomore and junior years, I focused on various company-affiliated extracurricular activities — all with the goal of leveling up my development skills step by step. But I started wanting to meet more industry professionals rather than just staying among college students, and I wanted to step into the professional world myself.

So toward the end of the second semester of my junior year, I dove into activities that could lead from student projects to internships and employment — starting with Naver Hack Day and Woowa Pre-Course. Unfortunately, neither program led to an internship or tech course, but rather than feeling discouraged by the bad results, I shifted my focus and decided to apply directly for internships.

Having participated in Naver Hack Day twice, Naver was a company I wanted as my starting point. Based on a resume I'd written myself, an opportunity came up and I unexpectedly ended up applying to Naver internships through multiple channels:

1. Around December, I applied for an internship at Clova through a professor's recommendation. I was waiting for results after the document screening -> coding test.

2. The Clova coding test results didn't come for about a month, so I assumed I'd been rejected and applied for the Naver Webtoon experiential internship. As a result, I passed the document screening and received an email inviting me for an interview.

3. While my Naver Webtoon application was still pending, I happened to get a chance to submit my resume to Apollo CIC through someone I knew. After passing the document screening, I had the interview (the process was super fast at the time).

4. Apollo CIC was the fastest to let me know I'd been accepted, so I went ahead with the Apollo CIC Backend Internship. (I felt terrible that I might have inconvenienced all three teams, and I was super nervous when I had to decline the Webtoon interview) (I also got an interview invitation from Clova, but I declined since my Apollo onboarding was already confirmed)

First Interview

The interview at Apollo CIC was the very first internship interview of my life. So I remember being incredibly nervous. Looking back, I don't know where I got the nerve lol — I went in without studying any of the computer science knowledge they might ask about. (The audacity!) I couldn't prepare much for the interview because of a freelance project deadline, and the only prep I had was a mock interview that my Java Bom (http://javabom.tistory.com/) study group members put me through 🧐 So I ended up pulling an all-nighter and went to the interview without any sleep.

I mainly reviewed Java-related knowledge I already knew, Clean Code concepts, testing concepts I frequently used, and design patterns I'd worked with. I also reminded myself of the key characteristics of technologies I'd used in previous projects (like the advantages of using queryDSL!).

When preparing for the interview, rather than just jotting down keywords and reading about them, I practiced actually speaking as if I were explaining to someone else. Doing this gave me a sense of how to structure my answers when questions about those keywords came up, which was really helpful. 👍

The interview questions fell into two main categories. 

1. There were 2 problems written on paper, and I had 30 minutes to verbally explain my solutions. One problem that stuck with me — I actually wrote it down from memory at the time:

You have 25 horses. You want to find the top 3 fastest horses in order. You can't measure their absolute speed, and each race can have a maximum of 5 horses, where you can only see their relative rankings. What's the minimum number of races needed to find the top 3?

When solving this problem, I explained while writing on paper. When I gave my initial answer, the interviewer gently nudged me with questions like "I think you could optimize this further!" and "What would you do in this case?" — which helped me arrive at the correct answer. It felt like we reached the answer together through communication based on my ideas, and it was so fun that I still remember it vividly. 👍

2. The second part consisted of about an hour and a half of technical questions about Java. They asked basic questions like JVM structure and how GC works, and I also remember them going to my GitHub and asking about why I structured my DTO and domain folders the way I did. They also asked about the benefits of writing test code and what I think about when writing tests. (A lot of the questions from the mock interview my Java Bom study group gave me actually came up, which was really great!)

The result: I passed!!! My start date was set for March.

At the time, I was originally planning to take a leave of absence, but since it was a conversion-type internship, I needed to graduate quickly. So I coordinated with my professor to have my senior year first semester credits replaced by the internship, and I waited anxiously for my start date.

Remote Onboarding Due to COVID

However, as COVID cases surged in March, my start date got pushed back. I'd been looking forward to it so much, but I waited for the company's update while worrying about COVID.

As a result, the start date was pushed back by a week, and even on the delayed start date, Naver had transitioned to a full remote work system, so I ended up onboarding remotely. The orientation was conducted via video call, and all contracts were received by email.

So on my start date, all the company equipment was delivered to my home, and I had two mentors at the time — a life mentor and a tech mentor — and I could only contact them through Works (the company messenger).

So from my start date, I worked fully remote for about a month and a half. For the remaining month and a half, I went to the office twice a week, which is when I got to meet my team members and mentors in person.

Intern Tasks

Two days after joining, I discussed with my mentor what tasks I'd be working on during the internship. I was part of the Moment team, and since Moment was a service that launched in April, I remember having to talk around it when explaining my department to others for the first month.

During the internship, I had 3 main jobs:

1. Read and summarize Effective Java and Clean Code

2. Build a toy project in an environment similar to the current Moment server
    2-1. Build a server that integrates with Naver services
    2-2. Deploy the server using k8s
    2-3. Set up CI/CD for the server by writing a jenkins pipeline
    2-4. Refactor the code using sonarlint

3. Analyze the Moment service and attend meetings as a Moment team member

1. Reading and Summarizing Effective Java and Clean Code

I've been gradually uploading the summaries to my blog
https://jyami.tistory.com/category/Dev%20Book%20Review/Effective%20Java
Though it's a hassle to format the posts for the Tistory editor, so I still haven't uploaded everything.. ugh

What I focused on while doing this reading task was not skipping over any passages I didn't understand. I'd been reading books this way in my Java Bom study group, and that approach carried over to this task.

I'd look things up on other people's blogs, check the Oracle docs, and try coding out examples from the book. I remember reading the section on parallel streams, which led to a discussion about ForkJoinPool — I even ended up reading through the JDK source code while studying that part.

Having those two books as intern tasks still has a lasting impact on me. Honestly, I wasn't a big fan of reading dev books. I disliked reading documents so much that it was one of the reasons I didn't want to go to grad school. But back then, I'd set a plan each week for how much to read, and that habit has stuck with me to this day. (These days I'm reading a chapter a day of Java 8 in Action.)

I was surprised to find that Java, which I thought I knew well, kept raising new questions no matter how much I studied. I actually got keywords for things I didn't know from the books and wrote a few blog posts about them.

https://jyami.tistory.com/112

https://jyami.tistory.com/99

So after this task, I became much less resistant to reading books, and there are so many books I want to read now. (I've actually bought a bunch already..haha)

2. Building a Toy Project in an Environment Similar to the Moment Server

This was mostly a process of growing through trial and error lol. Since Moment had just recently launched at the time, and partly due to my own stubbornness, I only asked my mentor when I truly couldn't solve something. When I was stuck, I'd ask in this format: "I'm working on this part, and I'm stuck on this issue. I've looked into a few approaches to resolve it, and I think the problem is in this area, so I'm going to look into it further — am I heading in the right direction?" It was all about briefing the current situation and getting guidance.

I was a bit embarrassed to ask questions that could be easily Googled, and I didn't want to look clueless. Later, in my mentor's feedback, they said I was the type to figure things out on my own and come back with everything neatly organized... lol

2-1. Building the Integration Server

First, I built a server that integrated with Naver APIs to query response data from various services and perform CRUD operations with a database and cache. The implementation itself wasn't that difficult, but this part allowed me to communicate a lot with my mentor. I needed to flesh out the requirements, and for docs pages I didn't have access to, I had to ask my mentor for help before I could implement anything.

What I focused on most while coding was writing test code. When implementing a feature, I consciously made an effort to write corresponding test cases. So when I measured the test line coverage mid-implementation and after finishing, it was in the 80% range both times.

Even though it was a solo project, I considered test code as a communication tool that conveys the project's requirements, so I was thorough about writing @DisplayName annotations too. (To at least prevent my future self from not understanding what's going on)

2-2. Deploying in a Container Environment

I had to deploy the finished server using k8s, but at the time, I had zero knowledge of docker or k8s. (I vaguely knew that Docker was something that saves environments) Since I had to learn it for the task, I picked it up along the way, and I'm actually using it all the time these days lol (The deployment system for Angel Hack, which I recently participated in, was Dockerfile-based, so it went smoothly!)

At the time, I managed pod object specs using helm charts and successfully set up the entire deployment pipeline using the company's internal container deployment system. The task deadline was 3 weeks, and when I finished all of this with 1 week to spare, I was able to additionally try setting up HPA and ELK configurations.

When I gave my intern presentation on this part, I mentioned some pain points about the internal container deployment system. A developer there gave me feedback saying they'd been planning to adopt it for their team too and would keep these issues in mind — they said the presentation content was impressive. That made me really proud.

I learned a lot of DevOps knowledge while doing deployments. So every day I wrote troubleshooting documentation like the screenshot above. But most of it was like "Let's try again." "Why isn't this working?" "AAAARGH!!" lol

2-3. CI/CD Using Jenkins Pipeline

Jenkins was also something I used for the first time thanks to this intern task. (I'd always just used the CI/CD that teammates set up..)

There was plenty of trial and error as expected, but I learned so much through the struggle.. Jenkins is something I'll use a lot going forward, so I consider it a great experience lol

Since I was writing a JenkinsFile for the first time, even syntax errors were a source of performance slowdowns. I was pulling source code from the company's internal GitHub and running the Jenkins pipeline from the JenkinsFile in that source folder, but there were many issues.

1. To check if the JenkinsFile syntax was correct, I'd push to GitHub every time I changed even a single line.

2. Later I realized the commit history was getting messy and started force pushing carelessly.
Still, testing the JenkinsFile by continuously pushing to GitHub didn't feel like the right approach.

3. Evolved to a smarter approach: Testing scripts directly within Jenkins
I found that I could go into Jenkins build history and use the replay button to rebuild with a modified script. This way, I could verify whether the build pipeline was working correctly on the spot. (I'll definitely use this trick going forward.)

2-4. Refactoring Code Using SonarLint

In the last week, I worked on refactoring and improving code quality, and this is when I once again felt the importance of testing. When refactoring based on SonarLint suggestions, even simple refactoring like changing a package name could break things — due to human error, tests going out of scope, and various other reasons.

Watching the code smells drop from 146 to 13, the thing that guaranteed there were no errors during refactoring was TestCase. You can never say enough about the importance of testing.

3. Being an Intern on the Moment Team

As a member of the Moment team, I attended various meetings and talked with team members about everything from development to future plans, which helped deepen my understanding of real-world work.

On my third day as an intern, I reviewed the Moment process documentation and wrote down my questions. There were things I never would have known without actual work experience. (For example, I was surprised to find that Auto Increment was missing from the DB design docs — turns out it was because they were using a distributed DB lol)

I appreciated that when spending time with team members, they treated me as a fellow developer, even though I was just an intern.
Even when there were deadlines for resolving certain issues, it was great to see a senior developer doing pair programming with team members to bring everyone's domain knowledge up to the same level. Even as an intern, I could sit alongside them, watch, and share my opinions. I was moved by this kind of developer culture that I'd only dreamed about.

And as a COVID-era intern, one thing I was really grateful to my team and mentors for was their active remote communication! Honestly, during the internship, I felt bad about suddenly messaging people on the company messenger whenever I had questions (that's just my personality — everyone was actually very kind). So early on, I wished the internship had been in person instead. But as time went on, communication worked so well even remotely that I fell in love with working from home..haha

Shortly after I first met a senior developer on the team, they suddenly messaged me on Works saying, "Minjeong, what do you think the problem with this code is?" We ended up having an intense 30-minute conversation about code on Works (we discussed the issues with using Optional and Null together), and even though I'd never seen this person's face, my sense of closeness shot through the roof lol

On another occasion, I ran into a dependency issue while working on a task, and we spent an entire hour communicating through Works to resolve it.

I also had lots of coffee chats with team members, and I kept hearing about the importance of exercise lol (I'm honestly still hearing about it constantly). It made me grateful to work with people who invest in self-improvement beyond just development.

End of the Internship

From everything I learned to the great team members I gained, it was an internship that gave me so much. Unfortunately, it didn't lead to a full-time offer.

My intern evaluation was good, but in the conversion interview (2nd interview) — (again, this internship was my very first technical interview experience) — I was so nervous that instead of highlighting my strengths, I ended up revealing the things I couldn't do and my weaknesses.

It was 3 months of living more intensely than ever, but since I know the internship itself was a great experience, the memories are more about the journey than the outcome. (It might sound like I'm sugarcoating things since it's all positive, but I'm not — it was genuinely fun)
It's a bittersweet result, but the fact that it remains a good memory even 2 months later makes me think I'd regret not writing this up, so I'm leaving it as a record!

The End! 

개발자 포트폴리오, 백엔드 개발자 레주메 (update 2020.06.12)

Developer Portfolio, Backend Developer Resume (update 2020.06.12)