만든 앱 투표 링크는 여기!!!

https://ai.google.dev/competition/projects/muse-diary?hl=ko

 

뮤즈 일기  |  Gemini API Developer Competition  |  Google AI for Developers

매일 채팅하고, 사운드트랙을 선별하고, 소중한 순간을 간직하세요

ai.google.dev

 

시작

진짜 오랜만에 올리는 포스팅..ㅎㅎ 민망하구만.
24년 6월부터 7월까지 한 달 반의 시간동안 평일 저녁과 주말 시간을 쪼개서 Google Gemini API Developer Competition (Gemini API를 사용한 제품 개발 공모전)에 참여했다. 1명의 PM, 2명의 클라이언트개발자, 1명의 디자이너, 그리고 서버개발자였던 나. 능력있는 멋진 동료들과 함께해서 그런지 힘든 기억보단 새로웠던 시간들이라 블로그로 정리하게 되었다.

어느덧 카카오에 입사한지 4년이 되었는데 (5년차라니...) 회사 일에 적응하고 외부 활동은 거의 안하다보니 슬슬 갇혀있는 기분이 들었었다. 회사에서 하는 AI 수업도 들었는데 결국 하는 일은 비슷비슷하다보니 요즘 세상은 어떻게 돌아가는지가 궁금했었다. (회고라 쓰고 외부 개발세계 탐방기라고 읽는다) 그러던차 PM 언니한테 생일 축하 메시지와 함께! 같이 공모전 할 생각있냐는 연락이왔다..!!! 

회사 일에 지장이 될까 걱정됐는데, 현생에 방해되지 않게 책임진다는 말과 클라이언트 개발자 분의 계획이 담긴 카톡을 보내줬는데 너무 든든해서 결국 참가하게 되었다.  기존 코드 고치는 작업이 아니라 내가 처음부터 코드를 짜는게 얼마만인지 두근두근!!

 

사전 지식 준비 (gen ai, spring-ai)

Gemini API를 사용해서 프로젝트를 제출하는 거였는데, 사실 굉장히 시기가 좋았다. 마침 회사에서 Generative AI(이하Gen AI) 기초반, 심화반 강의도 신청해서 듣고 흥미가 생겼었기 때문이다. AI 개발의 경우엔 대학때부터 느꼈지만 되게 나랑 안맞았다. 왜 그게 그 결과가 나오는지 이해가 안되서인가... 납득이 잘 안됐다. 근데 GPT가 나오고 언젠가는 결국 해야할 것들이라는 생각이 들어서 한번 공부를 하면 좋겠다 싶어서 회사 세션을 시작하게되었고 이 공모전을 시작하게되었다.

대부분의 사이드프로젝트가 그렇듯 사실 클라이언트만 있어도 결과물이 나오는데 서버가 굳이..? 싶었는데, 아무래도 클라에서 하면 API나 프롬프트가 외부에 노출될 가능성도 있고, 개선시 클라이언트 패치의 불편함이 있어서 서버개발자를 구하게 되었다고 하셨다.

사실 서버는 Gen Api 호출 서버를 만드는거라서 간단했다. 그래서 이참에 Spring-AI를 사용해보자는 개인 목표를 잡으며 공모전에 참여하게 되었다. 

우선적으로 회사를 통한 gen ai 공부는 꽤나 신기했다. 여러 개념이나 모델에 대한 설명에서 시작해서 프롬프트 엔지니어링, RAG, ollama, langchain, function call 실습 등 전반적인 방향성을 잡는데 도움이 되었다. 따라서 우리 공모전에서 AI를 사용할때 어떤 선택지가 있는지를 고를 수 있는 기반이 되었던 것 같다. 그리고 끝나고 팀원분들께 간단 공유시간도 가졌었는데 지금 몇개월 지나니까 다시 기억이 잘 안나는 것 같기도..

덕분에 우리 공모전에서 필요했던 건 RAG까지 갈 필요도 없이 prompt enginneering 만으로도 충분히 가능하다는걸 이해할 수 있었고, 사실 prompty engineering만 한다면  spring자체에서만 보면 httpClient 만 있어도 괜찮다는걸 스스로도 알았다. 그치만 spring-ai를 써보고싶었고, 오히려 spring-ai를 쓰면서 여기서는 지원하지 않아 생긴 허들도 있었어서 재밌었다. (이건 아래에) spring-ai를 쓰다보니 아직 안정화가 되지않아 구조가 휙휙 바뀌는 프레임워크단 코드를 체감할 수 있었던게 회사에서와는 다른 경험이라 신기했다.

 

그래서 뭘 만들었을까

https://youtu.be/lcMANrDdTSw?feature=shared

우리팀의 핵심 기능은 gemini prompt와 대화하며 일기를 적거나 글로 하루를 회고한 내용을 바탕으로 youtube music을 추천하는걸 주 기능으로 하는 앱이다. 제목은 muse diary 이다. gemini가 추천해주는 음악이 당신의 일상에 한번 더 영감을 주면 좋겠다는 의도로 muse라는 단어가 떠올랐다. 아무래도 gen ai를 사용한다면 이미 검색으로 찾을 수 있는 public한 내용에 대한 정리집 혹은 커뮤니티성 앱보다는 개인화에 집중된 private한 내용이 좀 더 사용성에 맞는 것 같다고 팀원간의 의견 나눔이 있었다.

 

짱 멋진 팀원들 자랑

1. 기획

초반에는 기획을 다같이 정리하는 시간을 가졌는데 PM언니가 떠다니기 쉬운 아이디어들을 잘 정리해주고 다시 리마인딩 하면서 회의를 진행했던게 좋았다.

커뮤니케이션은 보통 슬랙으로 했었는데, 평소에 업무를 할 때 카톡으로 하다보니 슬랙 확인을 좀 늦게하곤했었다ㅠ 그런데 확실히 회사밖의 다른 개발자들은 슬랙을 잘 쓰는구나 싶어서 되게 재밌었다. 퇴근하고 아무래도 밀려있는 내용들을 볼때 언급되어있는 스레드들 모아보기로 빠르게 확인하고 개발하고 배포해서 빠르게 확인하는게 되게 효율적이었다.

간만에 회사 외부의 능력자들과 일하는 경험이 되게 신선하면서도 서로 현생에 영향을 미치지 않게 배려해줘서 무사히 마칠 수 있었다.

 

2. 디자인

항상 나는 디자이너분들을 되게 좋아하는 편인데 (클라 개발자가 아니라 부딪힐일이 없어서그런가) 이번에도 역시 디자이너 너무좋다 디자인이 이뻤다!!! 하루를 마치고 LP바에서 술한잔과 함께 오늘 있었던 일을 얘기하면 그에 맞는 잔잔한 노래를 듣는 느낌을 생각했는데, 바이닐 컨셉의 디자인을 가져와주셨다. 

다들 직장인이라 바쁜 시간을 쪼개서 참여하다보니 사실 아이디에이션 했던 모든 기능을 넣을수가 없었는데, PoC단계에서 GUI 디자인 단계로 넘어가기 직전에 대부분의 앱들에서 사용하는 탭바를 걷어내자고 디자이너분이 제안을 주셨다. 덕분에 핵심기능에 집중해서 공모전을 마무리할 수 있었다. (기한이 쫄린다면 기획을 쳐내는게...) 다들 현생을 놓지않으면서도 새벽시간을 쪼개서 얘기하고 회의하고 밥먹고 되게 기억에 남는 팀이 될 것 같다.

 

3. 클라이언트

https://github.com/geminiApiDevKorea/diary_flutter

 

GitHub - geminiApiDevKorea/diary_flutter: 다이어리 플러터 프로젝트

다이어리 플러터 프로젝트. Contribute to geminiApiDevKorea/diary_flutter development by creating an account on GitHub.

github.com

클라이언트 개발자 두 분은 플러터로 개발을 했었는데, 확실히 크로스 플랫폼의 이점이 있었다. gen ai 프롬프팅을 한 클라개발자분께서 담당하셨었는데 (너무 감사했다.. 백엔드지만 프롬프팅 엔지니어링 까지는 관심이 없었기에 )  flutter로 프롬프팅 관련 PoC를 금방 구현해보시더니 다른 팀원분들도 해보라고 web으로 배포해서 주셨다. 덕분에 일기 추출 프롬프팅 부분을 다같이 테스트해보며 실제로 gpt가 말하는 뉘앙스를 보며 프롬프트를 수정하기도하고, 앱의 디자인적 사용성이나 백엔드에서는 실제로 들어갈 데이터들을 좀 더 고려해 볼 수 있었다.

그리고 클라이언트 각종 인터렉션을 디자인적 완성도를 위해 깡코드로 구현하시고, 많이 있는 library를 쓰지 않고 직접 코드로 구현한다거나.. 이런 부분이 개인적으로 가장 놀라웠다. 바이닐을 넘기는 인터렉션을 하나하나 디자이너분께 컨펌받으면서 섬세하게 디테일을 잡으시는 모습도 인상적이었고, 나는 백엔드 개발자다보니 당연히 달력은 라이브러리를 쓴다는게 고정적인 생각이었어서 그런가 직접 달력부분 코드를 하나하나 짠다는것도 충격이었다. 

그리고 실제로 보내주신 코드들을 보니 다트가 깔끔한건지 코딩을 잘하신건지.. 보기에도 편했다. 시니어 클라이언트 개발자와 함께하는 사이드프로젝트 꽤나 감격적이었달까

 

서버만 잘하면 되겠네

그래서 이렇게 자기할일 딱딱하는 팀원들과 함께 하기위해서라면 나도 일을 착착 해나가야겠다! 싶었는데 회사 밖에서 코딩을 한다는건 코딩이 문제가 아니었다! 그동안 기본적으로 환경세팅이 다 되어있던 회사 인프라를 벗어나서 외부에서 하나하나 해야하는 상황! 되게 재밌었다 외부 생태계는 이렇구나 요즘 개발자들은 이렇게 개발하는구나를 체험해볼수있어서 디버깅을 하나하나 해나가는게 재밌었다. 퇴근하고 정신없이 코딩하는게 그냥 며칠만 투자하면 됐기 때문에, 금방금방되서 그런가 몇개월이 지난 지금 생각해도 힘든것보단 재밌었다는 기억만 남았다!!!

우선 서버 코드는 아래에 있다.

https://github.com/geminiApiDevKorea/gem-api

 

GitHub - geminiApiDevKorea/gem-api: gem api server

gem api server. Contribute to geminiApiDevKorea/gem-api development by creating an account on GitHub.

github.com

그리고 구조는 아래처럼 잡았다.

코딩보다도 CI/CD구성이나 환경변수 관리 새로운 인프라 api에 대한 러닝커브 등등이 좀 더 기억에 남는다. 사실 사이드 프로젝트다 보니까 api 서버 만드는 건 확장성보다도 기획에서 바로바로 요청이 올 때 빠르게 변경한다거나 이런것들이 더 중요했기 때문에 객체화 클린코드 테스트코드 같은 것 보다 가장먼저 CI/CD부터 완성했다.

 

1. github Action CI/CD

회사에서는 CI/CD를 jenkins로 하고있어서 github action을 처음써봤다. github action에 대해서 좋다고 좋다고 말만들었지 처음 써보는거라 ansible 문법 익히듯이 action 문법들을 익혀야하는건가 싶었는데 와 요즘 개발은 GPT를쓰는구나?

진짜 감격 그자체 dockerfile 부터 github action worflow까지 다 짜주는 이런 세상이라니.. 그래서 action 쓰기는 했지만 썻다고 말할수 없다 내가 만든게 아니라 gpt가 만들었으니까! 근데 사실 여타 ci/cd가 그렇듯 jenkins pipeline문법이나, ansible 문법이나 action 문법이나 그냥 찾아가면서 작성하는거니까.. 라고 생각하면서 패스했다. 

회사에서는 아무래도 소스코드나 에러메시지를 직접 복사 붙여넣기해서 넣지 못하다보니 gpt한테 질문할때 가공해서 넣어야해서 귀찮았었는데 그냥 넣으면 나오니까 편했다ㅋㅋ. 그리고 Google Cloud Platform을 쓸때도 어떤 버튼을 어떤메뉴에 들어가야하는지까지 알려주고 바깥 세상 개발은 참 좋구나... 회사 내부 인프라를 사용하다보면 내부 인프라 가이드를 찾아보고 그랬었는데, 외부 세상에서 하는 개발은 gpt한테 물어볼 수 있다는 메리트가 있었다. 그동안 회사 개발만 했다는 티가 너무나나ㅠㅠ

 

그러나 바깥 세상의 개발중에 언제나 그렇듯 귀찮았던건 아무래도 secret 관리였다. 회사안에서는 사실 priavet repository라서 일부는  springboot aplication.yml에 박아서 썼었는데 각종 변수 하나하나를 환경변수 처리를 해야한다니.. 그리고 안했을때 혹시라도 과금폭탄이 무서웠다. 물론 private repository를 쓰면 똑같지만 공모전이다보니 open source 여야했다.

이런 민감정보들이 몇개 되지는 않아서 우선은 전부 app 시작시 쓰는 환경변수로 처리했는데, 만약 프로젝트가 좀 더 커진다면 좀 귀찮아 질 것 같다. 그치만 application.yml 파일 자체를 직접 import해서 로딩한다던지 다른 배포방법도 있지 않을까 싶긴하다. 이런 환경변수 처리들을 좀 쉽게하는 오픈소스들이 무조껀 있을텐데.. 라는 생각이 들면서도 개발을 시작해야하다보니 우선은 github action 자체의 secret을 사용했다.

그리고 사실 엄청 간단한 CI/CD 였기 때문에 문법이나 플러그인을 새롭게 도입할 필요가 없었다. 그래서 오히려 github CI/CD 예제를 보고 배포 플랫폼을 정했다ㅋㅋㅋ gemini api를 써야하다보니 Google Cloud Platform을 무조껀 써야하는 상황이었다. 따라서 google기반의 작은 vm기반 서버로하면 돈이 덜 들테니 그렇게 할까는 막연한 생각만 있었는데, action workflow을 쳐보니 cloud run 이란게 있네..? 부터 시작해서 위와 같은 서버 구조를 갖게 되었다. GKE는 쿠버네티스니까 스케일업,아웃 헬스체크까지 필요한 오케스트레이션 스펙은 현재 굳이 쓸 필요가 없다고 판단했다.

딱 빌드한 이미지가 빠르게 즉각적으로 배포되면서, 작은 컴퓨팅 리소스만 쓰는게(replica를 1로 설정했다.) 이런 작은 공모전 프로젝트에 오히려 적합하다는 생각이 들었다. 이런 gcp사용도 하나의 러닝커브였는데 이것 역시 GPT가 친절하게 어떤 버튼을 누르면 되고,, 어떤버튼으로 설정하면 되는지 알려주는 친절한 외부 개발 세상에 감탄했다ㅋㅋㅋ

그렇게 만든 github action flow는 아래와 같이 매우 간단하다 (여러 account key, secret 전달로 인해 길어졌을뿐.)

1. docker file을 빌드한다 (docker 빌드시 gradle 빌드하여 앱을 실행한다.)
2. 해당 docker 이미지를 GCP registry에 push한다.
3. push된 이미지를 Cloud run이 (replica 1)실행시킨다.

cloud run을 사용하니 로깅도 즉각적으로 확인 할 수 있고 트래픽 모니터링도 기본적으로 제공해주는 게 있어서 편했다. 
(알람 시스템까지 따로 달았다면 좀 더 즉각적으로 에러를 볼 수 있었겠지만... 현재 사용자도 없는데 오버스펙이다.)

2. Spring + Kotlin 개발 그리고 Spring-Ai

그리고 이제 내부 api를 개발할 때가 되었는데 사실 인증, 데이터베이스, ai 사용. 이렇게 세가지가 주요한 백엔드 기능이었다. 
gemini 개발자 대회에서 firebase 섹션도 있어서, 인증과 데이터베이스를 모두 firebase 기반으로 구현했다.
firebase관련 코드자체는 클라이언트 사이드에서 직접쓰면 좀 더 효율적이었을 거란 생각이 들긴했다. firebase 코드전부가 future로 되어있었는데 spring-webflux도 아니라 spring-mvc 기반으로 사용하고있어서 전부 blocking하게 데이터를 가져올 때 조금 아쉬움이 들었다.

간만에 사용하는 spring-security로 firebase token 기반 인증을 구현하였고, database는 전부 cloud firestore로 구현했다. 그리고 gemini api 호출부는 spring-ai 기반으로 구현하였다. 비즈니스로직이 사실상 db읽기 + gemini api 호출뿐이라 큰 복잡도가 없어 model이 중요한 상황에서 kotlin을 사용하니까 data class를 사용하는게 코드 줄수도 적고 편했다.

이 공모전을 시작하면서 spring-ai를 쓰는게 목표였는데 사실 우리팀의 경우엔 RAG이나 embedding model을 커스텀해서 쓰기보단 gemini api에 호출하고 호출할때의 prompt engineering을 잘 하는게 목표였기 때문에 spring-ai 안에서도 chatClient만을 사용했다. chatClient에서 제공하는 기능을 사용하는건 사실상 httpClient로도 가능하지 않나 싶어서 조금 아쉬운 부분이었다.

그래도 spring-ai덕분에 python 환경에서 langchain, lamaindex를 사용할 때 공통된 포맷으로 gen ai api를 호출하고 embedding model을 변경하는 등의 작업을 할수 있다는 것처럼, jvm 시스템 안에서도 이런 일들이 조금은 가능하다는점에 의의가 있다고 생각했다. 따라서 Spring-AI의 경우에 ChatClient를 기반으로하는 추상화가 중요했고, Gpt, VertexApi,  Azure 등등의 gen ai 모델들을 ChatModel들의 구현체들로 유연하게 사용할 수 있게 했다는 점에서 객체지향을 많이 고려한다는게 느껴졌다.

다만 각 gen ai 모델 구현체들의 업데이트도 빠르게 이루어지고 지원범위가 다양하게 있는 만큼, 그걸 spring-ai 에서 따라가기 힘든경우가 있구나 느꼈는데 그것또한 되게 재밌는 경험이었다.

vertex api 스펙에 보면 response의 출력형식을 결정할 수 있는 요청 필드가 있는데 이 필드가, VertexAiGeminiChatModel 에서는 구현이 되어있지 않은 상황이었다. 우리 공모전에서 사용할 prompt에서는 이 필드를 꼭 넣어야 json 타입으로 응답이 올바르게 오는데 지정을 하지 않으면 parsing 에러로 500에러가 간간히 떨어지는 경우가 있었다.

https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/gemini?hl=ko#request

따라서 이걸 spring-ai의 chatClient를 안쓰고 그냥 httpClient를 사용해서 해결할까..라는 고민을 하다가 이미 어느정도 ChatClient에 맞춰서 개발을 해둔 상황이었고, spring-ai의 공식지원은 아니지만 reflection을 이용해서 config를 직접 주입해 넣으면 될것 같아서 아래와 같이 VertexAiGeminiChatModel의 기본 구현을 무시하고 reflection으로 내가 원하는 기능을 구현했다.

val chatModel = VertexAiGeminiChatModel(
    VertexAI(System.getenv("GEMINI_PROJECT_ID"), System.getenv("GEMINI_LOCATION"))
)

val generationConfig = GenerationConfig.newBuilder()
    .setResponseMimeType("application/json") // responseMimeType 을 설정할 수 없어서. 직접 접근하여 설정하였다.
    .setTemperature(0.8f)
    .build()

val generationConfigField = VertexAiGeminiChatModel::class.java.getDeclaredField("generationConfig")
generationConfigField.isAccessible = true
generationConfigField.set(chatModel, generationConfig)

생각해봤을때 spring-ai에서 default로 제공하는 gemini 버전은 gemini-1.5-pro 였고, 이 요청필드의 경우엔 1.5부터 지원을 했기에 공식적으로 지원을 하는게 좋지 않을까 싶어서. spring-ai에 해당 필드를 추가하여 PR도 넣어보았는데 승인되었다 :)
공모전덕분에 spring 관련 레포에 처음으로 contribution 하는 경험을 얻었다.

 

https://github.com/spring-projects/spring-ai/pull/1185#issuecomment-2305876768

 

feat: Add responseMimeType option in vertexAiGeminiChatOptions by jyami-kim · Pull Request #1185 · spring-projects/spring-ai

The Gemini model provides the responseMimeType parameter, as documented in the Gemini Model Reference. However, when I attempting to call the Gemini model using Spring AI, there is no direct option...

github.com

 

 

3. 문서화 : swagger

CI/CD를 완성하면서 인증, 데이터베이스, gen ai 호출까지 왠만한 기능들의 api를 구현하는것만 남았었다. 처음부터 swagger는 붙였었지만 실제로 해당 api를 사용할때 파라미터는 어떻게 해야하고, 어떤의미이고 이런것들을 처음엔 거의다 slack으로 안내를 드렸다.
근데 하다보니.. 같이 작업하시는 클라이언트 개발자분들의 편의가 걱정이 되었고 이에 따라 swagger에 documentation을 제대로 달아서 소통을 하는 방향으로 작업 방향을 바꾸게 되었다.

그런데 이런부분을 되게 좋아하셨어서 다음에 또 사이드프로젝트를 하게된다면 그때는 swagger기반으로한 문서화를 기본으로하고, 스웨거에서 api 호출도 가능하게까지 지원해야겠다고 생각했다. spring-security + swagger를 같이 사용하면 그만큼 스웨거를 이용한 api 호출을 이용할 때 추가 설정을 해줘야하는데, 허허 퇴근후 개발 쉽지않다더라. 

 

마치며

회고이기 때문에 내가 느낀점들을 위주로 글을 흐물흐물 쓴거같다. 그동안 퇴근하면 운동하고, 친구들 만나던 삶을 반복하다가 간만에 개발을 하다보니 리프레쉬가 되던 경험이었다. 스펙을 간단하게 잡기도했고 아무래도 서버사이드에서 크게 챌린징할만한 부분이 없었던(?) 작고 소소한 개발이었을지라도 퇴근하고 시간을 쪼개서 작은 프로젝트를 좋은 사람들과 협업해서 만들었다는게 되게 기분이 좋았기 때문에 간만에 블로그를 쓰게 되었다.

사실 아쉬운건 언제나 있을 수 밖에 없다. 사이드 프로젝트다 보니 코드를 너무 일회성으로 짜버렸을까. spring-ai 사용할때 테스트코드도 한번 짜볼껄, 슬랙으로 알람 연결해서 클라 개발자분들의 제보없이도 빠르게 고칠 수 있게 만들어볼껄 그랬나. 가장 간단한 인증방식으로 우선 구현을 위해서 했는데 jwt 기반으로 해볼껄 등등 여러가지 생각나는 것들이 있긴하다.

또한 서버에서 챌린징하는건 아무래도 정말 운영환경에 들어갔을때 정말 일이 시작되는구나도 느끼게되었다. 사실 api를 개발하는건 어떤 개발자든 금방 할테지만, 그 api를 얼마나 확장성있게, 그리고 안전하게, 빠르게 탐지하고 운영할 수 있게 만드는건 더더욱 중요한 요소라는 걸 반증하는 것 같았다. 놀랍게도 그래서 사이드 프로젝트를 하면서 회사 내부에서 사용하는 여러 운영 스킬들에 대해서도 한번 더 중요함을 느끼게되었다.

여튼 주절주절은 여기서 끝!
혹시라도 읽으시는 분이 있다면 현재 피플스초이스어워드가 진행중이니, 소중한 한표 부탁드립니다~! 🙇‍♀️

https://ai.google.dev/competition/projects/muse-diary?hl=ko

 

뮤즈 일기  |  Gemini API Developer Competition  |  Google AI for Developers

매일 채팅하고, 사운드트랙을 선별하고, 소중한 순간을 간직하세요

ai.google.dev

 

The voting link for the app we made is here!!!

https://ai.google.dev/competition/projects/muse-diary?hl=ko

 

Muse Diary  |  Gemini API Developer Competition  |  Google AI for Developers

Chat every day, curate your soundtrack, and cherish precious moments

ai.google.dev

 

The Beginning

It's been so long since my last post..haha, kind of embarrassing.
From June to July 2024, over the course of about a month and a half, I squeezed in weekday evenings and weekends to participate in the Google Gemini API Developer Competition (a competition for building products using the Gemini API). Our team consisted of 1 PM, 2 client developers, 1 designer, and me — the server developer. Working with such talented and awesome teammates made it more of a refreshing experience than a tough one, which is why I decided to write this blog post.

Before I knew it, it's been 4 years since I joined Kakao (year 5, seriously...). After getting comfortable with work and barely doing any outside activities, I started feeling a bit trapped. I even took AI classes offered by the company, but at the end of the day, the work stayed pretty much the same, so I was curious about what's going on in the world these days. (It says retrospective but really it's an exploration journal of the external dev world.) Then, out of the blue, my PM sent me a birthday message along with — surprise! — an invitation to join a competition together..!!! 

I was worried it might interfere with my day job, but she promised it wouldn't get in the way of our real lives, and one of the client developers sent over a detailed plan via KakaoTalk — it was so reassuring that I ended up joining.  It had been so long since I wrote code from scratch instead of fixing existing code — I was excited!!

 

Background Knowledge Prep (Gen AI, Spring-AI)

The competition was about submitting a project using the Gemini API, and honestly, the timing couldn't have been better. I had just signed up for and attended the Generative AI (Gen AI) beginner and advanced courses offered by my company, which had sparked my interest. When it comes to AI development, I've felt since college that it really wasn't my thing. Maybe it's because I couldn't understand why certain results came out the way they did... it just didn't click. But after GPT came out, I started thinking it was something I'd eventually have to tackle, so I figured I should study up — that's how I started the company sessions and eventually this competition.

Like most side projects, the client side alone could produce a working result, so you might wonder — do we really need a server? But having everything on the client side could expose the API keys and prompts, and pushing client patches for every improvement would be inconvenient, which is why they decided to bring in a server developer.

The server work was actually pretty straightforward since it was basically building a Gen AI API calling server. So I set a personal goal of using Spring-AI for this opportunity and joined the competition. 

The Gen AI study through the company was quite fascinating. Starting from explanations of various concepts and models, it covered prompt engineering, RAG, Ollama, LangChain, function call hands-on practice, and more — it really helped me get a sense of the overall direction. It became the foundation for understanding what options we had when using AI in our competition project. I even held a brief sharing session with my teammates afterwards, though now that a few months have passed, I'm not sure I remember everything that well..

Thanks to that, I was able to understand that what we needed for our competition didn't even require RAG — prompt engineering alone was more than enough. And honestly, if it's just prompt engineering, even a plain httpClient would do the job from a Spring perspective. But I wanted to try Spring-AI, and the hurdles that came from things it didn't support yet actually made it fun. (More on that below.) Using Spring-AI, I got to experience firsthand how a framework that hasn't stabilized yet goes through rapid structural changes — something quite different from what I'm used to at work, which was pretty cool.

 

So What Did We Build?

https://youtu.be/lcMANrDdTSw?feature=shared

Our team's core feature was an app whose main function is to recommend YouTube Music based on diary entries written through conversation with a Gemini prompt, or based on written reflections about your day. The title is Muse Diary. The word "muse" came from the idea that the music recommended by Gemini could inspire your daily life once more. When using Gen AI, we agreed as a team that it makes more sense to focus on personalized, private content rather than building a compilation or community-style app for publicly searchable information.

 

Shoutout to My Amazing Teammates

1. Planning

In the early stages, we all spent time organizing the plans together, and our PM did a great job of wrangling all the floating ideas, keeping things organized, and reminding everyone during meetings — that was really helpful.

We mostly communicated via Slack, but since I normally use KakaoTalk for work, I tended to check Slack a bit late 😅 But it was really interesting to see how developers outside my company actually use Slack well. After getting off work, being able to quickly catch up on piled-up messages through the thread mentions view, then code and deploy — it was really efficient.

Working with talented people outside of my company after such a long time was really refreshing, and everyone was considerate about not letting it affect each other's real lives, so we managed to wrap things up smoothly.

 

2. Design

I've always been a big fan of designers (maybe because I'm not a client developer so there's nothing to butt heads about?), and this time was no different — the designer was amazing and the design was beautiful!!! I had imagined the feeling of finishing your day at an LP bar, having a drink, and talking about what happened while listening to some mellow music — and the designer brought exactly that with a vinyl concept. 

Since everyone had full-time jobs and was squeezing in time to participate, we couldn't actually include every feature we ideated. Right before moving from the PoC stage to the GUI design phase, our designer suggested removing the tab bar that most apps use. Thanks to that, we were able to focus on the core features and wrap up the competition. (When the deadline is tight, cutting features from the plan is the way to go...) Everyone managed to not abandon their real lives while still squeezing in late-night discussions, meetings, and meals together — I think this team will stay in my memory for a long time.

 

3. Client

https://github.com/geminiApiDevKorea/diary_flutter

 

GitHub - geminiApiDevKorea/diary_flutter: Diary Flutter Project

Diary Flutter Project. Contribute to geminiApiDevKorea/diary_flutter development by creating an account on GitHub.

github.com

The two client developers built with Flutter, and the cross-platform benefits were definitely real. The client developer who handled the Gen AI prompting was in charge of that part (I was so grateful.. as a backend developer, prompt engineering wasn't really my area of interest) — they quickly built a prompting PoC in Flutter and even deployed it as a web app so the rest of the team could try it out. Thanks to that, we were all able to test the diary extraction prompting together, see the nuances in how GPT responds, tweak prompts accordingly, and better consider the app's UX as well as the actual data that would flow through the backend.

And the client developers implemented various interactions from scratch for design completeness, opting to write the code themselves instead of using commonly available libraries.. that part personally impressed me the most. Watching them meticulously fine-tune the vinyl-flipping interactions one by one while getting confirmation from the designer was also really impressive. As a backend developer, I always assumed calendar components would naturally come from a library, so the fact that they hand-coded the calendar from scratch was honestly shocking to me. 

And looking at the code they shared, whether it's Dart that's clean or they're just great coders... it was really easy to read. Working on a side project with senior client developers was quite a moving experience, I'd say.

 

All I Need to Do Is Handle the Server, Right?

So with teammates like these who just get their stuff done, I felt like I needed to step up too! But coding outside of work turned out to be — the coding wasn't the hard part! Breaking out of the company infrastructure where everything was already set up, and having to do everything from scratch on my own! It was actually really fun. Experiencing the external ecosystem and seeing how developers work these days — debugging things one by one was enjoyable. Coding frantically after work only needed a few days of investment, so it flew by quickly. Even now, months later, the memories that stick are the fun ones, not the tough ones!!!

First off, the server code is below.

https://github.com/geminiApiDevKorea/gem-api

 

GitHub - geminiApiDevKorea/gem-api: gem api server

gem api server. Contribute to geminiApiDevKorea/gem-api development by creating an account on GitHub.

github.com

And the architecture was set up like this.

What stuck with me more than the actual coding was setting up CI/CD, managing environment variables, and the learning curve for new infrastructure APIs. Since it was a side project, building the API server was less about scalability and more about being able to quickly make changes whenever requests came in from the planning side, so rather than focusing on object-oriented clean code and test code, I completed the CI/CD first.

 

1. GitHub Actions CI/CD

At work, we use Jenkins for CI/CD, so this was my first time using GitHub Actions. I'd only ever heard people say how great it was but never actually used it. I was thinking I'd have to learn the Actions syntax like learning Ansible syntax, but then —  wow, so nowadays people use GPT for development?

I was genuinely amazed — we live in a world where it writes everything from the Dockerfile to the GitHub Actions workflow for you.. So I did use Actions, but I can't really say I "wrote" it since GPT did it for me! But honestly, like any CI/CD tool, whether it's Jenkins pipeline syntax, Ansible syntax, or Actions syntax, you just look things up as you go.. that's what I told myself and moved on. 

At work, since I can't directly copy-paste source code or error messages, I had to sanitize things before asking GPT, which was annoying. But here, I could just paste it in and get answers right away lol. And when using Google Cloud Platform, it even tells you which button to click and which menu to navigate to — developing in the outside world is really nice... When you're using internal company infrastructure, you have to dig through internal infra guides, but in the outside world, you have the perk of being able to ask GPT. It was so obvious that I'd only been doing company development until now 😢

 

However, as always in the outside development world, the annoying part was definitely secret management. At work, since we use private repositories, I'd sometimes just hardcode things in the Spring Boot application.yml — but having to turn every single variable into an environment variable.. and the fear of getting hit with a billing bomb if I didn't. Of course, using a private repository would be the same, but since it was a competition, it had to be open source.

There weren't that many sensitive values, so I handled them all as environment variables loaded at app startup. If the project were any bigger, it would've gotten pretty tedious though. That said, there are probably other deployment approaches like directly importing and loading the application.yml file itself. I had a feeling there must be open-source tools out there that make environment variable management easier.. but since I needed to start developing, I just went with GitHub Actions' built-in secrets for now.

And since the CI/CD was really simple, there was no need to learn new syntax or adopt plugins. So I actually chose the deployment platform based on GitHub CI/CD examples lol. Since we had to use the Gemini API, we were basically required to use Google Cloud Platform. I had a vague idea of using a small VM-based server on Google to keep costs down, but when I looked up Action workflows, I found this thing called Cloud Run..? — and that's how we ended up with the server architecture above. I decided GKE was overkill since it's Kubernetes with orchestration specs for scale-up/out and health checks that we didn't need at the moment.

It felt perfect for this kind of small competition project — the built image gets deployed immediately while using minimal computing resources (I set replicas to 1). Learning to use GCP was another learning curve, but once again, GPT kindly told me which buttons to click and which settings to configure — I was impressed by how friendly the outside development world is lol

The resulting GitHub Actions flow is super simple as shown below (it just looks long because of all the account keys and secret passing).

1. Build the Dockerfile (the Docker build runs a Gradle build to start the app).
2. Push the Docker image to the GCP registry.
3. Cloud Run runs the pushed image (with replica 1).

Using Cloud Run, I could check logs in real time and it came with built-in traffic monitoring, which was convenient. 
(If I had set up an alert system, I could have caught errors even more quickly... but with no actual users, that would be overkill.)

2. Spring + Kotlin Development and Spring-AI

Then it was time to develop the internal APIs, and the three main backend functions were essentially authentication, database, and AI usage. 
Since the Gemini developer competition had a Firebase section too, I implemented both authentication and database using Firebase.
In hindsight, the Firebase-related code might have been more efficient if used directly on the client side. All the Firebase code was based on futures, but since I was using Spring MVC rather than Spring WebFlux, I felt a bit disappointed having to fetch everything in a blocking manner.

I implemented Firebase token-based authentication using Spring Security (which I hadn't used in a while), and the database was entirely built on Cloud Firestore. The Gemini API call layer was implemented using Spring-AI. Since the business logic was essentially just DB reads + Gemini API calls with no major complexity, and the model layer was what mattered most, using Kotlin's data classes kept the code concise and convenient.

My goal going into this competition was to use Spring-AI, but in our team's case, rather than customizing RAG or embedding models, the goal was to call the Gemini API and do good prompt engineering. So within Spring-AI, I only used the ChatClient. Using the features provided by ChatClient felt like something that could've been done with just an httpClient, which was a bit underwhelming.

Still, thanks to Spring-AI, just as LangChain and LlamaIndex in the Python ecosystem allow you to call Gen AI APIs in a common format and swap embedding models, I thought it was meaningful that similar things are now somewhat possible within the JVM ecosystem too. So the key abstraction in Spring-AI was centered around ChatClient, and the fact that it enables flexible use of various Gen AI models — GPT, Vertex API, Azure, etc. — through implementations of ChatModel showed that a lot of object-oriented thinking went into it.

However, since each Gen AI model implementation updates rapidly and supports a wide range of features, I noticed that Spring-AI sometimes struggles to keep up — and that was actually a really interesting experience.

Looking at the Vertex API spec, there's a request field that lets you determine the output format of the response, but this field wasn't implemented in VertexAiGeminiChatModel. In our competition, we needed this field to ensure the response came back properly in JSON format — without specifying it, we'd occasionally get 500 errors from parsing failures.

https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/gemini?hl=ko#request

So I debated whether to ditch Spring-AI's ChatClient and just use httpClient instead, but since I'd already built a fair amount around ChatClient, and I figured I could inject the config directly using reflection even though it wasn't officially supported by Spring-AI, I ended up bypassing VertexAiGeminiChatModel's default implementation with reflection to implement the feature I needed, as shown below.

val chatModel = VertexAiGeminiChatModel(
    VertexAI(System.getenv("GEMINI_PROJECT_ID"), System.getenv("GEMINI_LOCATION"))
)

val generationConfig = GenerationConfig.newBuilder()
    .setResponseMimeType("application/json") // responseMimeType 을 설정할 수 없어서. 직접 접근하여 설정하였다.
    .setTemperature(0.8f)
    .build()

val generationConfigField = VertexAiGeminiChatModel::class.java.getDeclaredField("generationConfig")
generationConfigField.isAccessible = true
generationConfigField.set(chatModel, generationConfig)

When I thought about it, the default Gemini version provided by Spring-AI was gemini-1.5-pro, and this request field was supported starting from version 1.5, so I thought it would be good for them to officially support it. I submitted a PR to Spring-AI adding this field, and it got approved :)
Thanks to the competition, I got the experience of making my first contribution to a Spring-related repo.

 

https://github.com/spring-projects/spring-ai/pull/1185#issuecomment-2305876768

 

feat: Add responseMimeType option in vertexAiGeminiChatOptions by jyami-kim · Pull Request #1185 · spring-projects/spring-ai

The Gemini model provides the responseMimeType parameter, as documented in the Gemini Model Reference. However, when I attempting to call the Gemini model using Spring AI, there is no direct option...

github.com

 

 

3. Documentation: Swagger

After finishing the CI/CD, all that was left was implementing the APIs for authentication, database, and Gen AI calls. I had attached Swagger from the start, but when it came to actually using those APIs — what parameters to send, what they meant — I initially communicated almost everything through Slack.
But as I kept going, I started worrying about the convenience of the client developers I was working with, so I shifted my approach to properly documenting everything in Swagger for communication.

They really appreciated it, so if I ever do another side project, I plan to make Swagger-based documentation the default from the start, and even support making API calls directly from Swagger. When you use Spring Security + Swagger together, you need additional configuration to enable API calls through Swagger, and well, developing after work isn't easy, let me tell you. 

 

Wrapping Up

Since this is a retrospective, I think I've been rambling on about my personal thoughts and feelings. After months of the same routine — working out after work and meeting friends — getting back into development after such a long break was really refreshing. Even though the spec was kept simple and there wasn't much that was deeply challenging on the server side (?), it was a small and humble project. But the fact that I squeezed in time after work to build a small project in collaboration with great people made me feel really good — which is why I'm writing a blog post after such a long time.

There are always things to be regretful about, of course. Since it was a side project, maybe I wrote the code too disposably. I wish I had written test code when using Spring-AI, set up Slack alerts so I could fix issues quickly without relying on reports from the client developers, or used JWT-based auth instead of the simplest authentication method I chose for quick implementation — all sorts of thoughts come to mind.

I also realized that the real challenges on the server side truly begin when you're actually in a production environment. Any developer can build APIs quickly, but making those APIs scalable, secure, quickly detectable, and operationally maintainable is an even more critical factor — and this experience really drove that point home. Surprisingly, doing this side project also made me appreciate the various operational skills we use internally at the company even more.

Anyway, that's the end of my rambling!
If anyone happens to be reading this, the People's Choice Award voting is currently underway, so I'd really appreciate your vote~! 🙇‍♀️

https://ai.google.dev/competition/projects/muse-diary?hl=ko

 

Muse Diary  |  Gemini API Developer Competition  |  Google AI for Developers

Chat every day, curate your soundtrack, and cherish precious moments

ai.google.dev

 

한게 없는데 올려도 될까 회고... 1월 내내 생각 날 때마다 정리하고있는데 하핫 미루고 미루다보니 2월이네..?시간 너무 빨리간다. 회사 다니고 나서부터 3년이 1년처럼 흐르는 느낌이랄까 

22년은 사실 개발자로써의 성장보단 운동으로 건강찾다가 재미를 붙여버린 한해였어서 개발 얘기 거의 없는 일기장 회고이다.
자자 시작해보자!!

 

개발자 쟈미

올해는 외부 스터디나 서브프로젝트 없이 회사 생활에만 집중했었다. 아무래도 그만큼 흥미로운 일을 하고있어서 회사 코드와 구조 그리고 일에 애정이 생기기 때문이 아닌가 싶다.

 

카카오

지금 부서인 카카오 톡메시징파트에서 일을 하다보면, 이제 3년을 향해가고 있음에도 몰랐던 도메인지식이 나온다. 카카오톡 채팅이라는 매우 큰 서비스와 기능이 많은 서비스를 운영 개발하고있어서 그런거겠지. 도메인적으로 모를때도 스스로 놀라면서 환기가 되기도하고, 사실 기술스택도 다양하고 장애양상이나 그 문제를 해결하는 양상도 다양하여 매울점이 굉장히 많은 조직에 속해있다고 자부심을 느낌다.

22년도에 회사일을 하면서 아무래도 기억에 남는 것들이 몇 개가 있다.

 

1. 회사 유튜브 출연

작년에는 회사 블로그에 내 글을 썼던걸 회고에 적었었는데, 올해는 유튜브 컨텐츠에 출연을 했다. 개발자로써 훌륭해서라기보단 우리 파트에서 가장 외향적이고, 이런 컨텐츠를 찍으면 내 회사 생활이 재밌을 것 같다고 생각해서 자원했다. 

https://www.youtube.com/watch?v=9SU1jBYZ14o 

https://www.youtube.com/watch?v=J9KsjiQs604 

예능 컨텐츠 하나, 인터뷰 컨텐츠 하나해서 두개를 찍었는데 아무래도 기억에 남는건 팀채팅 인터뷰 컨텐츠이다. 파트내에서 팀채팅 서버도 관리하고 있고 팀채팅에 대한 부분도 가끔 유지보수를 하고있는데, 이 좋은 서비스를 많이들 모르는 것 같아 아쉬웠다. 그래서 이전에 내 유튜브에도 올린 팀채팅 활용법에 대한 내용을 영상에 담았다.

그리고 겸사겸사 톡 메시징파트의 롤을 설명하는 내용도 인터뷰에 남겼는데, 덕분에 이 짤을 생성하였지 후후

 

2. 카카오 해커톤

대학생때 취준을 할 때부터 IT 기업에 가면 임직원 해커톤이 있다는 얘기를 듣고 한번은 꼭 해보고 싶다고 생각했다. 그동안은 코로나로 안열렸었는데, 22년부터 조금 완화가 되고 슬슬 개발자 관련 행사들이 많이 나왔었다. 그래서 참가한 카카오 해커톤 22K 꽤나 재밌었다. 해커톤 영상에도 내가 나온다ㅋㅋ https://youtu.be/j-nXQwSY98o?t=560

우리 팀 빌딩은 모두 카카오톡을 개발하는 크루들이었고, 톡디자인 케이, 톡 안드로이드 피터와 이안, 톡 메시징인 나 이렇게 넷이서 참가하였다. 사내 코드를 써도 되기 때문에 카카오톡 오픈채팅을 변경한 서비스를 만들었고, 지난 코로나 시대에 오픈채팅 팬미팅, 오픈채팅 콘서트가 종종 이루어진 것을 봤었어서. 팬미팅에 사용할 수 있도록 팬덤색이나 팬덤 로고들을 좀더 커스텀해서 팬들과 스타가 소통할 수 있는 채팅기능을 개발하였다. 시연영상은 내 유튜브에 비공개로 저장해뒀다ㅎㅎ 나중에 보면 매우 추억일 것 같은 느낌!

 

3. 제주도 출장

22년에 제주도만 3번을 다녀왔었는데, 그중 2번이 회사관련 출장이었다. 한번은 태경이 수영이랑 같이 제주도 여행을 다녀왔었고,
한번은 if-kakao 컨퍼런스 준비단 워크샵, 그리고 아래 vlog찍을 때 갔던건 포팅과제 집중근무를 위한 제주 출장이었다. 일도 하면서 좋은경치 맛있는 음식 잔뜩먹으면서 제주도 혼자 여행을 다녀오다보니 당시에 리프레쉬도 되었고, 22년도 기억에 남는 일중 하나였다. 본사가 제주에 있는 회사에 다니니 워크샵 제주 힐링그자체!! 

vlog에서도 언급을 했었지만 당시에 만난 케빈과 조엘이 엄청 인상적이었다. 두분은 같은 학교 동문, 그리고 당시에 두분 다 유관 부서로 한달 제주도 워케이션을 하신다고해서 한번 만남을 가졌었다. 생활패턴과 개발철학이 비슷해서 마음이 맞는친구와 한달동안 알차게 여행 겸 근무를 할 수 있는 사람이 있다는게 정말 부러웠다. 나두 23년에 조엘이랑 떠나는 스위스 여행 매우 기대중 ㅎㅅㅎ

https://www.youtube.com/watch?v=X0YzYGM7JDw 

 

4. 그리고 개발

올해는 리팩토링 업무, 그리고 기존 레거시 포팅작업이 나의 주된 과제였었는데, 그 와중에도 유저가 직접 사용하는 기능 개발에도 참여하곤했었다. 너무 내부과제에만 치중하다보니 스스로 번아웃이 오고 개발로 좀 재미를 찾고 싶었기 때문에 실제 유저가 사용할 수 있는 기능 개발을 하고싶다고 생각을 했었다.

그렇게 했던 과제가 추모 프로필이었는데 하필이면 12월 가장 바쁠 시기에 내가 여행을 일주일 다녀오는 바람에 같이 일을 했던 빈스에게 매우 죄송했다. 그래도 전후로 나름 열심히 팔로우 했던 프로젝트! 사실 서버 공수가 많지는 않았지만 23년 1월에 오픈되고 유저들의 반응이 너무 좋아서 뿌듯했다. 덕분에 사용자와 밀접한 서비스를 만들게되면 또 다른 멋진 기능을 개발, 혹은 기존 기능들을 개선 할 수 있도록 힘을 낼 수 있는 계기가 되어 개발자로 자부심있게 살 수 있게 되는 것 같다.

https://cs.kakao.com/helps?service=8&category=226&device=1&locale=ko&articleId=1073205009&controllerName=help&actionName=mobileviewpage&accountLoginUrl=https%3A%2F%2Faccounts.kakao.com%2F&without_layout=false 

 

고객센터

카카오 고객센터를 통해 각 서비스 도움말을 확인해보세요.

cs.kakao.com

 

 

5. 판교 IDC 장애 대응 / 월드컵 대응 / 신년 대응

4분기 휘몰아쳤다. 각종 대응으로 유독 새벽에 작업을 할 일이 많았었다. 

판교 장애 대응은 앞으로 개발자로 계속 산다고 해도 이정도 규모의 장애를 대응해볼 일이 있을까 싶을정도로 기억에서 안잊혀질 것 같다. 토요일 3시부터 시작해서 일요일 오전 7시까지 쉼없이 대응하고 2시간 자서 다시 일어난다음 일요일 9시부터 00시까지 일하고.. 그러고 월요일도 9시 출근해서 00시까지 일하고.. 어떻게든 빠르게 복구해야한다는 생각밖에 안들었던 당시였다. 내가 자는시간만큼 내 주변인들이 서비스를 사용하지 못한다고 생각하니, 진짜 아드레날린이 너무 몰아쳐서 심장이 계속 두근거리고 잠을 못자는 상황이었다. 그래도 물리적장애를 소프트웨어적으로 빠르게 해결하려고 대응책을 세우고 실제로 하나하나 대응되는 대로 서비스가 살아나는 것을 보면서 재밌기도했고 개발자로써 희열을 엄청 느꼈던 사건이었다.

월드컵 트래픽으로 신년 트래픽으로 혹시나 서버에 이상이 있을까 뒤에서 모니터링을 했었다. 우리 파트에 있으면 사용자의 패턴에 따라 내 서비스의 트래픽이 오르고 내리는 것을 볼 때 정말 신기함을 느낀다. 실제 대한민국 대부분 국민들의 서비스 사용성을 직접 데이터로 볼 수 있다는 점에서 항상 많은 인사이트를 얻고 그에 따른 대응 로직을 준비하고 대비하면서 많은 배움을 얻는다. 첫 직장 첫 부서가 대규모 트래픽을 감당하기 위해 많은 것을 고려해야하는 파트라는 점에 항상 감사함을 느낀다.

 

개발자 외부 활동

1. 블로그

월간 방문수 약 13000명대를 유지하고있다. 사실 글도 잘 안쓰는데.. 이전에 스프링 기본기에 대해 정리해뒀던 문서나 회고 글들이 인기가 많아서 꾸준히 유입이 있다. 23년에는 블로그에 글을 많이 쓸랑가

 

2. 유튜브

https://www.youtube.com/@developer-jyami

 

개발자 쟈미

🌱개발자 쟈미의 일상 기록🌱 클라이밍하는 개발쟈미

www.youtube.com

구독자가 3400명이 되었다. 22년에는 광고영상 1개, 카톡팁 영상 1개, 제주 vlog 영상 1개.. 하핫 올리고 싶을 때 취미로 하는 유튜브라서그런지 꾸준히 하지 못해서 구독자가 확실히 크게 우상향하지는 않는다.

그래도 가끔 회사에 신입사원분들이 들어오실 때 블로그나 유튜브와 같이 열심히 살던 과거의 영광들을 봐주시고 감사하게도 좋게봐주셔서 알아봐주시는 분들이 계시다. 그런만큼 열심히 살아야 하는데..ㅠㅠ 22년에는 아무래도 개발자로서의 성장보다 다른데 좀더 집중해서 살다보니 블로그도 유튜브도 업로드가 많이 이루어지지 않았었다.

3. 세미나

외부 컨퍼런스에 잘 나가는 편은 아니지만 지속적으로 대학교 선후배들과의 네트워크는 하려고 학교 행사에는 많이 참여하려고 하는 편이다. 22년에는 총 3번의 세미나를 진행했었는데, 아무래도 전부 취준을 앞둔 대학생 대상이다보니 커리어에 대한 이야기를 많이 했다.

• 1월 GDSC EWHA 선배초청 세미나 : 서버개발자가 아키텍처 확장해 나가는 플로우
• 11월 이화여대 컴퓨터공학과 클라우드 데이 : 개발자는 어떻게 공부해야할까
• 11월 GDSC EWHA 홈커밍 데이 : 서버개발자에게 궁금한 점 QnA

발표를 준비하면서 아무래도 내가 개발을 어떻게 공부를 했었고, 앞으로는 어떻게 공부를 해야겠다는 생각을 정리할 수 있었다. 그래서 다들기술 발표를 하고 멘토링을 하라는 이유가 스스로도 되짚어볼 수 있게되기 때문인가보다. 개발자는 어떻게 공부해야할까? 라는 점에 대해서 아키텍처가 점점 확장되면서 요구사항에 따라 그때그때 공부를 확장해가면서 해야한다는 이야기를 했었다. 면접에서 cs를 본다고해서 그것을 주먹구구로 외우는 방식보다는 직접 서비스나 프로젝트를 하면서 그에 따른 지식을 익혔던 것이 기억에 많이 남는다는 것이 주된 주제였다. 다행히도 많은 후배분들이 질문도 많이 해주시고 연락도 많이 해주셔서 뿌듯함과 그들의 열정을 느끼는 일정이었던게 기억에 남는다.

 

4. 인터뷰

https://korea.googleblog.com/2022/10/GDSC-job-fair-2022.html

 

Google Developer Student Clubs와 함께 취업에 도전하는 개발자가 되어보세요!

GDSC(Google Developer Student Clubs)는 구글 기술에 관심이 있는 학생들을 위한 대학 기반 커뮤니티 그룹으로, 현재 전 세계 110개 이상의 국가 약 1,800개 대학에서 활동하고 있습니다. 대학생들이 함께 A..

korea.googleblog.com

GDSC에서 요청이 와서 서면 인터뷰를 했었다. 사실 취준기에 대해서 이 블로그를 통해 유명해지긴 했으나,, 어느새 직장을 다닌지 만으로 3년차이기에 너무 라떼는 얘기가 아닐지 걱정이된다. 운동을 하고있는 지금 입장에서는 과거에 운동도안하고 무작정 밤샘을 하던 나의 모습이 좋지 않다는 걸 특히나 더 실감하고 있어서 더 그렇다.

 

5. 스터디?

주된 관심사가 아무래도 운동이었어서 개발 공부를 해야한다는 생각은 한켠에만 있고 그러다보니 옛날만큼 퇴근 후 공부를 많이 하진 않았다. 3월부터 6월까지는 자바봄이랑 effective kotlin 책으로 코틀린 스터디를 했었다.

effective java만큼 인사이트를 주지 않을까 하여 사실 많이 기대했던 책인데 아직은 코틀린이 자바만큼 안티패턴이나, 주의해야할 점 등 사례가 많이 쌓이진 않았어서 effective java만큼 충격적으로 다가오진 않았다. 아직도 내 최고의 명서는 effective java... 오히려 코틀린은 kotlin in action 이 좀더 실용적이고 내용이 알찬게 좀 더 마음에 들었다.

마찬가지로 자바봄이랑 이펙티브 코틀린을 진행할 때 github 코드 정리와 블로그 정리를 동시에 했었는데 관련 링크는 아래에 있다

• 소스코드 : https://github.com/Java-Bom/ReadingRecord/tree/master/%EC%9D%B4%ED%8E%99%ED%8B%B0%EB%B8%8C%20%EC%BD%94%ED%8B%80%EB%A6%B0
• 질문 리스트 : https://javabom.tistory.com/category/Reading%20Record/%EC%9D%B4%ED%8E%99%ED%8B%B0%EB%B8%8C%20%EC%BD%94%ED%8B%80%EB%A6%B0
• 블로그 : https://github.com/Java-Bom/ReadingRecord/issues?q=label%3A%22Effective+Kotlin%22 

직장을 다니면서 내가 원하는 깊이로 마음맞는 사람들과 스터디를 하는게 쉽지 않다는걸 깨닫게되었다. 대학교에 다닐때 자바봄을 만난건 매우 행운이었구나 생각이 들었다. 고로 앞으로 공부를 한다면 스스로 흥미를 찾아서 꾸준히 해야할텐데 쉽지않다ㅠ 사회에는 재밌는게 너무 많다! 앞으로의 공부방법에 대해서는 항상 고민으로 두고 찾아가야 할 것 같다.

 

운동인 쟈미

사실 본론은 여기일지도 위에는 그래도 양심상 제목이 devlog니까 개발자를 위로 올렸는데, 22년의 진짜 본모습은 운동인이었다ㅋㅋㅋ 21년에 시작한 운동이 생각보다 재밌었고, 22년 2월부터 클라이밍에 빠지게 되면서 꾸준히 운동을하고있는데, 운동하나를 시작하니 다른 운동도 곧잘해서 이것저것 많이 시도하고 도전했었던 한해였다.

1. 클라이밍

2월부터 꾸준히 하고있는 운동이다. 사실 진짜 운동하는 느낌은 웨이트가 그렇고, 클라이밍은 운동이지만 승부욕이 많이 생겨서 게임하는 느낌이긴 하다. 꾸준히 했더니 처음보다 실력이 많이늘었고, 클라이밍으로 새로운 사람들을 많이 만나면서 22년을 덕분에 즐겁게 보낼 수 있었다. 

위에 달력 보면 진짜 많이도 했다 싶다..ㅋㅋㅋㅋ 암장리스트도 싹 정리하니 많이도 다녔다..ㅎㅎ

클라이밍안에도 많은 종류가 있는데 이것저것 해보기를 좋아해서 그런지 실내볼더링 인공암벽리드 자연볼더링 자연리드 가릴 것 없이 많이 했다. 클라이밍을위해 먼 지역에 여행을 가기도 하면서 참 많이 놀러다녔다. 클라이밍이 너무 해보고싶어서 언더독 클라임에 무작정 일일강습을 신청했고, 진짜 재밌었다. 그래서 이후에 혼자 암장을 가서 사람들이랑 친해지기도하고, 그렇게 친해진 사람들의 친구들을 소개받으면서 같이 클라이밍을 하고 다니면서 다양한 곳을 다니게 되었다.

3월에서 4월까지는 모란 클라임어스에서 기초반 강습을 들었었고, 그 이후에 한 5월쯤인가 부터 지금까지 계속 더클라임 회원권을 연장해서 실내 볼더링을 하고있다. 처음에 더클라임 초록도 쩔쩔맸었는데, 어느새 갈 때마다 빨강을 한두개씩 깨게 되고 22년 마지막에 보라색도 하나 했다!! 9월쯤 헬스랑 함께 클라이밍을 했을 때까지 실력이 엄청 빠르게 늘어서 매번 재밌었는데, 사실 22년 끝물에 연말이라고 술을 너무 많이 먹었더니 근손실이 왔는지 조금 정체했다..ㅎㅎ 23년에는 헬스도 클라이밍도 꾸준히 하면서 좀 더 잘해지고싶다!

무엇이든 신기한 클린이는 상반기에는 서울 근처 암장투어를 정말 많이 다녔었고, 결국엔 클라이밍을 위한 여행도 많이 가게 되었다. 부산, 속초, 대전, 제주, 양양, 진안 심지어 태국까지 어느 여행지를 가게되도 클라이밍을 연상하는 클친자가 되어가는 중이다. 하반기에는 더클라임 회원권을 끊게되면서 이곳저곳 원정을 안가게 되었고, 실내가 아닌 실외에 관심을 갖게되었다.

9월에 가을이 되면서 날씨가 좋아지고,, 날씨가 좋아지니 실내보다는 밖을 나가고 싶어서 결국 리드를 시작하게 되었다. 근처 주민인 소나언니한테 리드를 배워서  결국 리드 클라이밍을 꾸준히 하고있는 돌무리 크루에 들어오게 되었다. 가을에 이쁜 하늘을 보면서 클라이밍을 하고싶어서 배운 리드를 인공암벽에서 시작해서 결국 실제 자연바위에서도 리드를 하게 되었고, 태국 끄라비까지 가게 되었다. 끄라비 자연리드는 아무래도 22년에 가장 기억에 남는 이벤트였었고, 같이간 우리 돌무리 언니오빠들이랑 하나도 안싸우고 서로서로 챙기면서 8박9일 클라이밍 겸 태국여행을 무사히 다녀올 수 있어서 감사했다. 

외에도 더클라임에서 진행하는 걸스온탑, 클라임어스에서 진행하는 볼더링 파티도 참가해보면서 한정된 시간안에 많은 문제 혹은 고득점 문제를 풀어야하는 긴장감도 경험해볼 수 있었다. 사실 이런 이벤트를 할 때마다 내가 좀더 강했다면하고 그레이드를 많이 낮춰서 나가게 되는데, 그래도 1년안에 이정도면 꽤 잘하는거니까!!! 23년에도 다양한 이벤트를 많이 나가보는걸로 하자

재밌겠다는 생각 하나로 시작한 취미로 다양한 직군의 사람들을 만날수 있게되었고, 취미를 위해 여행을 떠나는 삶을 내가 살고있을거라고는 생각도 못했었다. 사실 올 한해 클라이밍과 운동에 푹 빠져있어서 덕분에 퇴근하고 개발공부보단 운동을 하러가는 일상이 반복되었지만 , 그만큼 많이 건강해진 패턴을 가지게되어서 다행이라고 생각한다. 22년에는 운동에만 미쳐있었다면 23년에는 그래도 현생도 조금은 챙기면서 운동을 하고 싶다.

---

볼더링 (실내 28 + 자연 2)

• 언더독 클라이밍 (수원)
• 더클라임 (양재 + 강남 + 신림 + 서울대 + 마곡 + 홍대 + 연남 + 일산)
• 클라임어스 (모란)
• 피커스클라이밍 (종로)
• 서울숲클라이밍 (서울숲)
• 클라이밍파크 (종로 + 신논현 + 한티)
• 에픽클라임 (영통)
• 닷클라이밍 (송파)
• 볼더메이트 (기흥)
• 락트리 (분당)
• 비블럭 클라이밍 (언주 + 송도)
• 알레 클라이밍 (혜화)
• 손상원 클라이밍짐 (강남)
• 원정 : 아임낫볼더 (속초)
• 원정 : 웨이브락 (광안리, 서면)
• 원정 : 픽스볼더 (제주)
• 원정 : 베이스캠프 (대전)
• 자연바위 : 양양 죽도암
• 자연바위 : 진안 운일암반일암

리드 (인공암벽 4 + 자연 2)

• 판교 공원
• 뚝섬 한강 공원
• 영등포 스포츠 클라이밍 경기장
• 광교 스포츠 클라이밍장
• 자연리드 : 조비산
• 자연리드 : 끄라비 (태국)

이벤트

• 피커스 볼빼페 (볼더링 빼고 페스티벌)
• 더클라임 걸스온탑
• 더클라임 강남점 오픈페스티벌
• 모란 볼더링 파티

 

2. 헬스

그래서 3대몇? 스쿼트가 잘 기억이 안나는데 S : 55kg / B : 32.5kg / D : 75KG = 3대 162.5kg 이다.
요즘엔 헬스를 잘 안해서 3대 운동을 잘해서 아마 더 많이 내려갔을 텐데ㅠㅠ 1월부터 10월까지 꾸준히 PT를 했을때 기록이었다. PT를 22년에 꽤 많이 받았더니 돈도 많이 들고, 사실 기구 사용법이나 자극도 왠만해서는 혼자도 할 수 있는 정도가 되어 11월부터는 PT없이 혼자서 하고있다. PT거의 마지막 즈음에는 내가 고립운동을 재미없어하는걸 쌤이 느끼셨는지 크로스핏이나 역도 동작도 시켜보고ㅋㅋ 또 곧잘하니까 선생님도 재밌어하고 했었다ㅋㅋ 운동에 한번 흥미를 느끼니 "고립운동"이라서 하는게 아니라 그냥 운동이면 무엇이든지 일단 도전해보게 되었다.

22년 1월 인바디와 22년 9월 인바디 차이이다. 12월에 했어야했는데 생각을 못했다ㅠㅠ 식단없이 평소대로 식습관을 하면서 오로지 운동만으로만 이루어낸 결과이다. 목표로 운동을 한것은 아니었지만 몸 라인이 달라지고 데이터로도 나아지는 것을 보면서 보람을 느꼈고, 몸도 이전보다 많이 건강해졌다는걸 느끼고있다. 생활속에서도 옛날에는 무거운 물건을 옮기는걸 굉장히 부담스러워했는데, 어느순간 혼자서도 척척 잘 옮길 수 있게 되서 나름 삶의질도 높아졌다.

지금은 클라이밍을 주운동으로해서 헬스를 많이 하고있지는 않지만, 그래도 클라이밍과 반대되는 근육 발달을 위해 일주일에 한번이라도 헬스장을 가고있긴하다. 외에도 너무 몸이 무거울 때 유산소를 가볍게 하면 기분도 나아지고 좀 가벼워지는 기분이 든다. 하지만 앞으로 헬스를 주운동으로 하지는 않을 것 같다. 고로 3대측정도 계속 낮아지겠지.. 적당한 건강유지 정도를 위해 할 예정이다.

 

3. 일회성 운동 체험

클라이밍과 헬스로 점점 운동에 재미를 붙이다보니 사실 일회성으로도 여러 운동에 도전해보는걸 주저하지 않게되었다. 인생에서 처음 스키장에 가서 스키를 타보기도하고, 프리다이빙 체험을 하려다가 자격증 코스 수업을 듣기도했다 (근데 성격이 급해서 그런가.. 나랑은 잘 안맞아서 그만뒀다). 클라이밍의 다이나믹 무브를 잘하고싶어서 언더커버에 파쿠르 체험을 가서 파쿠르 코치님들이랑 친해지기도했다. 유산소를 진짜 싫어해서 절대 안할줄 알았던 러닝도 생각보다 처음하는 것 치고 기록이 잘나와서 꽤 흥미로웠다. (5km 6분 11초)

코딩에서 하나의 언어를 잘 알면 다른 언어를 배울 때 좀더 수월하게 배우는 것처럼 운동도 비슷한 느낌이 들었다. 어느정도 헬스와 클라이밍으로 상체와 하체 근육이 받쳐주다보니 다른 운동도 처음시작하는 것 치고 곧잘하는 느낌이 들어 빠르게 흥미를 붙일 수 있게 될 것 같다. 다만 그래도 아직은 클라이밍이 너무 재밌다..ㅎㅎ

 

그래서 23년에는..

글의 분위기에서도 느껴졌겠지만 개발 얘기할 때는 조금은 차분하게 운동얘기할 때는 매우 활기차게 글을 썼다ㅋㅋㅋ. 그런만큼 22년에는 개발자로서의 성장보다는 운동으로 건강돌리기와 재미찾기가 우선인 한 해 였다. 하지만 언제까지 재미만 찾아다닐 순 없겠지ㅠ 그래서 어떻게 하면 개발 공부를 좀 더 재밌게 할 수 있을까 고민중이다. 시니어 개발자분들중에 한분은 본인의 취미를 개발과 접목시키면 결국 관심사라서 공부를 하게 된다고 하셨었다. 그래서 퇴근하고 사이드프로젝트로 내가 쓰고싶은 클라이밍 관련 서비스를 만들어 볼까 생각도 해보고있다. 22년은 근육만 성장했다면, 23년은 근성장, 개발자로서의 성장 둘다 잡는 멋진 한 해를 만들어보자!! 화이팅!

I don't even have much to show for it, but is it okay to post a year-end retrospective... I've been jotting things down whenever they come to mind throughout January, but haha I kept putting it off and now it's February..? Time flies so fast. Ever since I started working, it feels like 3 years go by like 1 year 

2022 was honestly a year where I found fun in working out and getting healthy rather than growing as a developer, so this is more of a diary-style retrospective with barely any dev talk.
Alright, let's get started!!

 

Developer Jyami

This year, I focused solely on work life without any external study groups or side projects. I think it's because the work I'm doing is interesting enough that I've grown attached to the company's code, architecture, and the work itself.

 

Kakao

Working in my current department, the KakaoTalk Messaging Part, even as I'm approaching my 3rd year, I still come across domain knowledge I didn't know about. I guess that's because we're operating and developing KakaoTalk Chat — a massive service with tons of features. When I encounter something I didn't know domain-wise, I surprise myself and it's a nice wake-up call. The tech stack is diverse, the types of incidents and how we resolve them vary widely too, so I feel proud to be part of an organization where there's so much to learn.

There are a few things from work in 2022 that really stick out in my memory.

 

1. Appearing on the Company YouTube

Last year I wrote about publishing a post on the company blog in my retrospective, and this year I appeared in YouTube content. It wasn't because I'm an outstanding developer — I'm just the most extroverted person on our team, and I volunteered because I thought filming this kind of content would make my work life more fun. 

https://www.youtube.com/watch?v=9SU1jBYZ14o 

https://www.youtube.com/watch?v=J9KsjiQs604 

We filmed two videos — one entertainment piece and one interview piece — and the one that stands out most is the Team Chat interview content. Our part manages the Team Chat server and occasionally does maintenance on it, and I always thought it was a shame that not many people knew about this great service. So I included tips on how to use Team Chat, which I had also previously uploaded on my own YouTube channel.

While I was at it, I also explained the role of the Talk Messaging Part in the interview, and thanks to that, I got this meme-worthy screenshot hehe

 

2. Kakao Hackathon

Ever since my college days when I was job hunting, I'd heard that IT companies have employee hackathons, and I always wanted to try one. They hadn't been held due to COVID, but starting in 2022, restrictions eased up and a lot of developer events started popping up. So I participated in the Kakao Hackathon 22K, and it was pretty fun. I even appear in the hackathon video lol https://youtu.be/j-nXQwSY98o?t=560

Our team was made up entirely of crew members who develop KakaoTalk — Kay from Talk Design, Peter and Ian from Talk Android, and me from Talk Messaging, four of us total. Since we were allowed to use internal code, we built a modified version of KakaoTalk Open Chat. During COVID, I'd seen fan meetings and concerts held through Open Chat, so we developed a chat feature that let fans and stars communicate with more customized fandom colors and logos for fan meetings. I saved the demo video as unlisted on my YouTube hehe — I feel like it'll be a great memory to look back on later!

 

3. Jeju Island Business Trip

I went to Jeju Island 3 times in 2022, and 2 of those were work-related trips. Once I went on a personal trip with Taekyung and Suyoung,
once was a workshop for the if-kakao conference preparation team, and the trip I vlogged about below was a Jeju business trip for focused porting work. Working while enjoying beautiful scenery and eating tons of delicious food, basically a solo trip to Jeju, was so refreshing at the time, and it's one of the most memorable things from 2022. Working at a company with headquarters in Jeju means workshop trips to Jeju are pure healing!! 

As I mentioned in the vlog, meeting Kevin and Joel at the time was really impressive. They're alumni from the same school, and both were doing a month-long Jeju workation in a related department, so we met up. Our lifestyles and development philosophies were similar, and I was really envious that they had someone whose vibe matched so well to travel and work with for a whole month. I'm super excited for my Switzerland trip with Joel in '23 too hehe

https://www.youtube.com/watch?v=X0YzYGM7JDw 

 

4. And the Actual Development

This year, refactoring work and porting legacy code were my main tasks, but I also got involved in developing user-facing features along the way. Being too focused on internal tasks was burning me out, and I wanted to find some fun in development again, so I thought I'd like to work on features that actual users would use.

The project I ended up working on was the Memorial Profile feature, but unfortunately, I happened to go on a week-long trip during the busiest time in December, so I felt really bad for Vince who was working on it with me. Still, I did my best to follow up before and after! The server workload wasn't that heavy honestly, but when it launched in January '23 and the user response was so positive, I felt really proud. Thanks to that experience, whenever I get to build a service that's close to users, it motivates me to develop more awesome features or improve existing ones, and it makes me feel like I can live with pride as a developer.

https://cs.kakao.com/helps?service=8&category=226&device=1&locale=ko&articleId=1073205009&controllerName=help&actionName=mobileviewpage&accountLoginUrl=https%3A%2F%2Faccounts.kakao.com%2F&without_layout=false 

 

Customer Center

Check out the help guides for each service through the Kakao Customer Center.

cs.kakao.com

 

 

5. Pangyo IDC Outage Response / World Cup Response / New Year's Response

Q4 was a whirlwind. With all sorts of incident responses, I ended up working in the early morning hours a lot. 

The Pangyo outage response is something I'll never forget — even if I keep working as a developer for the rest of my life, I doubt I'll ever deal with an incident of that scale again. It started at 3 PM Saturday and I worked non-stop until 7 AM Sunday, slept for 2 hours, got back up and worked from 9 AM Sunday until midnight.. Then on Monday, went in at 9 AM and worked until midnight again.. All I could think about at the time was recovering as fast as possible. Knowing that for every moment I was sleeping, people around me couldn't use the service — the adrenaline was pumping so hard my heart wouldn't stop racing and I couldn't sleep. But watching the services come back to life one by one as we devised software solutions for a physical outage was actually exciting, and it was a moment where I felt an incredible thrill as a developer.

For the World Cup traffic and New Year's traffic, I was monitoring from behind the scenes in case anything went wrong with the servers. Being on our team, it's truly fascinating to watch the traffic on our service rise and fall based on user patterns. The fact that we can directly see usage data from most of the Korean population through actual data always gives me a lot of insights, and I learn so much from preparing and implementing response logic accordingly. I'm always grateful that my first job and first team is one that has to consider so many things to handle massive traffic.

 

External Developer Activities

1. Blog

I'm maintaining about 13,000 monthly visitors. I honestly don't even write that much.. but the Spring fundamentals posts and retrospective posts I wrote before are popular, so there's a steady stream of visitors. Maybe I'll write more blog posts in '23

 

2. YouTube

https://www.youtube.com/@developer-jyami

 

Developer Jyami

🌱Developer Jyami's Daily Log🌱 A dev who climbs

www.youtube.com

I hit 3,400 subscribers. In 2022, I only uploaded 1 sponsored video, 1 KakaoTalk tips video, and 1 Jeju vlog.. haha since it's a hobby YouTube channel I upload whenever I feel like it, so naturally the subscriber count isn't growing dramatically.

Still, sometimes when new employees join the company, they've seen the past glories of me working hard through the blog or YouTube, and thankfully they think positively of it and recognize me. That means I should keep working hard but..ㅠㅠ In 2022, I was more focused on things other than growing as a developer, so I didn't upload much to the blog or YouTube.

3. Seminars

I don't go to external conferences much, but I try to participate in school events to keep networking with university seniors and juniors. In 2022, I gave 3 seminars in total, and since they were all aimed at college students preparing for job hunting, I mostly talked about careers.

• January — GDSC EWHA Alumni Seminar: The flow of how a server developer scales architecture
• November — Ewha Womans University Computer Science Cloud Day: How should developers study?
• November — GDSC EWHA Homecoming Day: Q&A about things you're curious about as a server developer

While preparing the presentations, I was able to organize my thoughts on how I had studied development and how I should study going forward. So I guess that's why everyone says to give tech talks and do mentoring — because it lets you reflect on yourself too. On the topic of "How should developers study?", I talked about how as architecture gradually expands, you should expand your studies on-the-fly based on the requirements at hand. The main point was that rather than rote-memorizing CS concepts just because they come up in interviews, the knowledge you gain from actually building services or projects sticks with you much more. Fortunately, many juniors asked lots of questions and reached out to me afterward, so I remember it as an event where I felt proud and could feel their passion.

 

4. Interview

https://korea.googleblog.com/2022/10/GDSC-job-fair-2022.html

 

Become a developer ready for employment with Google Developer Student Clubs!

GDSC (Google Developer Student Clubs) is a university-based community group for students interested in Google technologies, currently active at about 1,800 universities in over 110 countries worldwide. College students together A..

korea.googleblog.com

GDSC reached out to me, so I did a written interview. I actually became well-known through this blog during my job-hunting days, but now that I've been working for a full 3 years, I worry if my stories are becoming too "back in my day." Especially now that I'm working out, I realize even more how unhealthy it was to just pull all-nighters without exercising back then.

 

5. Study Groups?

Since my main interest was working out, the thought of studying development was just sitting in the back of my mind, so I didn't study much after work like I used to. From March to June, I did an Effective Kotlin book study with Javabom.

I had high expectations, thinking it would give insights like Effective Java, but Kotlin hasn't accumulated as many anti-patterns or gotchas as Java yet, so it didn't hit me as hard as Effective Java did. My all-time best book is still Effective Java... For Kotlin, I actually preferred Kotlin in Action — it felt more practical and had richer content.

Similarly, when doing Effective Kotlin with Javabom, I organized code on GitHub and wrote blog posts at the same time. The related links are below:

• Source code: https://github.com/Java-Bom/ReadingRecord/tree/master/%EC%9D%B4%ED%8E%99%ED%8B%B0%EB%B8%8C%20%EC%BD%94%ED%8B%80%EB%A6%B0
• Question list: https://javabom.tistory.com/category/Reading%20Record/%EC%9D%B4%ED%8E%99%ED%8B%B0%EB%B8%8C%20%EC%BD%94%ED%8B%80%EB%A6%B0
• Blog: https://github.com/Java-Bom/ReadingRecord/issues?q=label%3A%22Effective+Kotlin%22 

I realized that it's not easy to find like-minded people to study with at the depth I want while working a full-time job. Meeting Javabom in college was truly lucky. So if I'm going to study going forward, I'll need to find my own motivation and keep at it consistently, but that's easier said than done ㅠ There are too many fun things in life! I think figuring out how to study going forward is something I'll need to keep thinking about.

 

Jyami the Athlete

Honestly, this might be the real main topic. I put the developer stuff up top out of conscience since the title says devlog, but my true identity in 2022 was an athlete lol. The workouts I started in 2021 turned out to be more fun than expected, and after getting hooked on climbing starting February 2022, I've been exercising consistently. Once I started one sport, I naturally picked up others too, so it was a year of trying and challenging myself with all sorts of things.

1. Climbing

This is the sport I've been doing consistently since February. Honestly, weight training feels more like a "real workout," while climbing is technically exercise but it fires up my competitive side so much that it feels more like a game. With consistent practice, my skills improved a lot from the beginning, and I got to meet so many new people through climbing, which made 2022 a really enjoyable year. 

Looking at the calendar above, I really did go a LOT lolol. And when I compiled my gym list, I visited so many places too hehe.

There are actually many different types of climbing, and since I like trying all sorts of things, I did everything without discrimination — indoor bouldering, artificial wall lead climbing, outdoor bouldering, and outdoor lead climbing. I even traveled to faraway places just for climbing and went on tons of trips. I wanted to try climbing so badly that I just signed up for a one-day lesson at Underdog Climb on impulse, and it was seriously fun. After that, I started going to climbing gyms on my own, made friends with people there, got introduced to their friends, and ended up climbing together and visiting all kinds of places.

From March to April, I took beginner classes at Moran Climb Us, and after that, starting around May I think, I've been renewing my membership at The Climb for indoor bouldering ever since. At first I struggled even with The Climb's green problems, but before I knew it, I was clearing one or two red problems each visit, and at the end of 2022, I even completed a purple one!! Until around September when I was combining weight training with climbing, my skills were improving super fast and it was fun every time. But honestly, toward the end of 2022, I drank way too much because of year-end gatherings, and I think I lost some muscle because I hit a plateau.. hehe. In 2023, I want to keep doing both weight training and climbing consistently and get even better!

As a climbing newbie curious about everything, I toured a ton of climbing gyms around Seoul in the first half of the year, and eventually ended up going on lots of climbing trips too. Busan, Sokcho, Daejeon, Jeju, Yangyang, Jinan, and even Thailand — no matter where I traveled, I was becoming that climbing-obsessed person who associates every destination with climbing. In the second half, after getting a membership at The Climb, I stopped going on expeditions to different gyms and became more interested in outdoor climbing rather than indoor.

As autumn arrived in September and the weather got nicer, I wanted to be outside rather than indoors, so I ended up starting lead climbing. I learned lead climbing from Sona unnie, who lives nearby, and eventually joined the Dolmuri crew, who regularly do lead climbing. I wanted to climb while looking at the beautiful autumn skies, so I started with lead climbing on artificial walls and eventually progressed to actual natural rock faces, even traveling all the way to Krabi, Thailand. The outdoor lead climbing in Krabi was definitely the most memorable event of 2022, and I was grateful that all of us Dolmuri crew members got along without a single fight, looked out for each other, and safely completed the 8-night, 9-day climbing and Thailand trip. 

On top of that, I participated in Girls On Top hosted by The Climb and the bouldering party hosted by Climb Us, where I got to experience the thrill of solving as many problems or high-scoring problems as possible within a limited time. Honestly, every time I did these events, I wished I were a bit stronger and ended up registering in a lower grade category. But still, this is pretty good for just one year of climbing!!! Let's make sure to participate in lots of events in 2023 too.

What started from a simple thought of "this seems fun" turned into a hobby that let me meet people from all different professions, and I never imagined I'd be living a life where I travel for my hobbies. Honestly, this whole year I was so deep into climbing and exercise that my daily routine after work became going to work out rather than studying development. But I think it's a good thing because I ended up with a much healthier lifestyle. If 2022 was all about being obsessed with exercise, in 2023 I want to exercise while also taking care of real life a bit more.

---

Bouldering (Indoor 28 + Outdoor 2)

• Underdog Climbing (Suwon)
• The Climb (Yangjae + Gangnam + Sillim + Seoul National Univ. + Magok + Hongdae + Yeonnam + Ilsan)
• Climb Us (Moran)
• Peakers Climbing (Jongno)
• Seoul Forest Climbing (Seoul Forest)
• Climbing Park (Jongno + Sinnonhyeon + Hanti)
• Epic Climb (Yeongtong)
• Dot Climbing (Songpa)
• Boulder Mate (Giheung)
• Rock Tree (Bundang)
• B-Block Climbing (Eonju + Songdo)
• Allez Climbing (Hyehwa)
• Son Sangwon Climbing Gym (Gangnam)
• Expedition: I'm Not Boulder (Sokcho)
• Expedition: Wave Rock (Gwangalli, Seomyeon)
• Expedition: Fix Boulder (Jeju)
• Expedition: Basecamp (Daejeon)
• Natural Rock: Yangyang Jukdo-am
• Natural Rock: Jinan Unil-am Banil-am

Lead (Artificial Wall 4 + Natural 2)

• Pangyo Park
• Ttukseom Hangang Park
• Yeongdeungpo Sports Climbing Arena
• Gwanggyo Sports Climbing Center
• Outdoor Lead: Jobisan
• Outdoor Lead: Krabi (Thailand)

Events

• Peakers Bouldering Festival
• The Climb Girls On Top
• The Climb Gangnam Branch Opening Festival
• Moran Bouldering Party

 

2. Weight Training

So what's your big three? I don't remember squat exactly, but S: 55kg / B: 32.5kg / D: 75kg = Big Three total of 162.5kg.
I haven't been doing much weight training lately so I'm not great at the big three lifts, and the numbers have probably dropped even more ㅠㅠ These were my records when I was consistently doing PT from January to October. I did quite a lot of PT sessions in 2022 so it cost a lot, and honestly I got to the point where I could handle equipment usage and muscle activation on my own well enough, so starting November I've been working out solo without a trainer. Toward the end of my PT sessions, my trainer must have noticed I found isolation exercises boring, so they had me try CrossFit and weightlifting movements too lol. And since I picked them up quickly, my trainer had fun with it too lol. Once I found interest in exercise, it wasn't about doing "isolation exercises" anymore — I became someone who just wants to try any kind of exercise.

This is the comparison between my InBody results from January 2022 and September 2022. I should have done one in December but I forgot ㅠㅠ These results were achieved purely through exercise alone, without any diet changes — just eating the way I normally do. I didn't set specific body goals, but seeing my body shape change and the data improve gave me a real sense of accomplishment, and I can feel that my body has become much healthier than before. In daily life too, I used to find it really burdensome to move heavy objects, but at some point I became able to move them easily by myself, which actually improved my quality of life.

Right now I'm not doing much weight training since climbing is my main workout, but I still try to hit the gym at least once a week to develop the muscles opposite to the ones used in climbing. Also, when my body feels really heavy, doing some light cardio improves my mood and makes me feel lighter. But I don't think I'll be making weight training my main workout going forward. So my big three numbers will probably keep going down.. I plan to do it just enough to maintain reasonable health.

 

3. One-off Sport Experiences

As climbing and weight training got me more and more into exercise, I became unafraid to try various sports even if just once. I went to a ski resort for the first time in my life and tried skiing, and I was going to just try freediving but ended up taking a certification course (though I guess I'm too impatient.. it didn't really suit me so I quit). I wanted to get better at dynamic moves in climbing, so I went to Undercover for a parkour experience and ended up becoming friends with the parkour coaches. I also tried running, which I always thought I'd never do because I absolutely hated cardio, but my times were surprisingly good for a first-timer, so it was pretty interesting. (5km in 6 minutes 11 seconds)

Just like how knowing one programming language well makes it easier to learn another, I felt the same applies to sports. Since I had built up a decent foundation of upper and lower body muscles through weight training and climbing, I could pick up other sports pretty quickly for a beginner, which made it easy to get interested fast. But still, climbing is just too fun for now.. hehe.

 

So in 2023..

You could probably feel it from the tone of this post, but I wrote calmly when talking about development and super energetically when talking about exercise lol. That's how much 2022 was a year prioritizing getting healthy and finding fun through sports, rather than growing as a developer. But I can't just chase fun forever ㅠ So I've been thinking about how I can make studying development more enjoyable. One senior developer told me that if you combine your hobbies with development, you naturally end up studying because it's something you're interested in. So I'm thinking about building a climbing-related service as a side project after work. If 2022 was a year of only muscle growth, let's make 2023 a awesome year where I achieve both muscle growth AND growth as a developer!! Let's go!

우선 회고를 시작하기 전에, “올해도” 연말에 카톡 메시징 서버 문제 없었다!!! 올해는 내가 직접 연말 대응을 핸들링 하게 되었어서, 연말 기록까지 남기고 싶어서 회고를 뒤로 미루게 되었다.

20년도 9월에 입사를 하고 12월부터 실질적인 실무 업무를 시작하게 되었는데 22년이된 지금!! 내가 3년차라니?!! 너무 놀랍다ㅋㅋㅋ 사실상 실무를 1년 1개월 정도 한 상태인데 3년차라니.. 다시 한번 놀랍다.
그래서 21년도는 나에게 입사 후 실무 개발자로써 적응을 하는 시기, 이제 개발을 직업으로 삼게 되면서 일과 일상의 밸런스를 위해 개발 외에 것들을 시도해보는 시기였다. 그렇다면 지금부터 회고를 시작해보자

이번 회고는 1년치 일기장쓴 기분이라 가독성이 없다.

 

1. 회사

1-1. 업무를 숙제처럼?

매일매일 업무일지를 쓰면서 회사 일을 하나씩 처리했는데, 확실히 상반기와 하반기를 비교하면 많이 달라진게 느껴진다.
상반기만해도 일반채팅 개발버전 배포하는 것만해도 엄청 놀라워하고 가슴떨려하고 그랬는데, 하반기에 와서는 그 일반채팅을 리얼 버전으로 서버를 증설해서 배포하기도하고, 서버 배포 설정을 수정하려고 ansible을 이래저래 고치기도하고 결국 마지막엔 연말대응까지 이것이 짬이 차는 과정인가..?😳

확실히 상반기 후반기 사이 내가 업무를 하는 모습에서 차이는 있었던 것같다. 상반기만해도 내가 이런 커다란 과제를 해도 될까? 잘 모르는데 메시징 일을 받아도 될까? 망설이면서 시니어분들이 지정해주시는 일만 했었다면, 하반기에는 상반기에 비해서 내가 먼저 일을 찾아서 했었던 것 같다. 파트에서 묵혀둔 이슈를 몇개 가져가기도하고, 클라이언트분과 친해지면서 적극적으로 커뮤니케이션하면서 메시징 로직 가이드를 드리기도하고, 코드에서 고치고 싶은 사항이 있다고 하면 먼저 이슈를 따서 진행하기도하고 그랬었다. 상반기 초에 파트 시니어 분께 “쟈미는 일을 숙제하듯이 해” 라는 말을 들었었는데, 이 말이 변하게 된 계기였던 것 같다. 처음 이 말을 들었을 때는 아무 생각없이 음 나는 숙제 항상 잘했고 퀄리티 높게 해왔었으니까. 되게 정성적으로 한다는 뜻인가? 하고 생각했었는데, 이 말이 신경쓰여서 은님께 여쭤보니, 일을 좀더 능동적으로 해야한다는 말이라는 것을 알게되었기 때문이다.

1-2. 어떤 개발자가 좋은 개발자일까?

그래도 아직은 이슈를 자잘자잘하게 가져가는 느낌이긴 하다. 자진해서 c > java 포팅작업을 주도하겠다 라는 시니어 개발자 분이 있었는데, 이분처럼 나중에는 정말 큰 이슈도 내가 먼저 이슈업 하는 날이 오지 않을까?라는 생각이 들기도한다. 이런 걸 보면 확실히 메시징파트에는 참 배울 분들이 많다고 느낀다. 그런데 그때문에 입사 전과 후로 어떤 개발자가 되어야하나라는 생각에 변동을 겪고있다. 이전에는 당연히 자바, 스프링 좋아하니까 그걸 마구마구 파고 막 클린코드, DDD이런거 다 적용하는 개발자가 좋고, 당연히 실무에 들어가면 spring구조 다 까보고 그러고 있으면 좋은 개발자가 되지 않을까? 라고 생각하고 있었다, 그런데 입사 이후에는 어떻게 하면 좀 더 좋은 구조의 서버 구조를 가지고, 여러가지 컴포넌트를 올바르게 사용할 수 있는지도 매우 중요하구나를 깨닫고있다.

왜냐하면 아무래도 장애가 나거나, 새로운 컴포넌트에 대한 계획을 세울때는 코드를 어떤방식으로 짜고.. 보다는 어떻게 하면 좀더 성능을 높일 수 있고, 이런 엣지케이스에는 어떻게 대응할 것이고 등등의 실무적인 관점을 접했기 때문이 아닐까 싶다. 그래서 이전에는 redis를 사용한다하면, spring-data-redis를 사용할 때 어떤 메서드를 사용해야 좋은 코드 좋은 테스트 코드를 짤 수 있다! 이런거를 고려했다면, 지금 메시징 파트에 와서는 redis 자체에 대해서 고민을 해야한다는걸 깨달았다. redis가 가지는 자료구조, failover 정책, evction 정책, 백업 정책 등등 그 자체에 대해서 먼저 알고가는게 더 중요할 수 있다는 걸 경험적으로 습득하게 되었다. 그래서 그냥 어떤 언어를 잘하는 보다는 문제상황이 발생하면 잘 해결하는 개발자가 사실 일하기는 가장 좋은게 아닐까 하면서 생각이 변하는 중이다. 파트장님과도 여러번 고민을 공유했었는데, 다 다른길을 걷고있고 어떤 개발자가 좋다는 정답은 없다고 조언을 주셨었다.

1-3. 인턴멘토 / 공채 신입 코드리뷰어

그리고 하반기부터 내 아래로 인턴 / 신입분들이 들어왔다. 나는 내가 아직도 신입같은데.. 내가 인턴분의 멘토를 했었고, 공채 신입 분들의 코드리뷰를 담당하고 있다. 사실 처음에는 나보다 나이가 많으신 분들을 대상으로 괜찮으려나 걱정도 했었는데 괜찮았다.✌️ 어찌됐든 신입 과제가 내가 알고있는 선에서 나왔고 모르면 공부하면 되니까라고 생각했다.
나도 연차가 많이 높진 않지만 인턴 멘토를 하면서 회사가 어떤 사람을 신입개발자로 뽑고 싶어하는지를 파악하면서 가이드를 드렸었다.

인턴분의 근처에 가장 가까이서 일하면서 많은 것들을 느끼게 되었고, 최대한 합격을 하는데 도움이 되도록 코드단부터 의사결정단까지 조언을 열심히 해주었다. 그러나 당시 인턴분보다 나의 열정이 더 과했던거 같았다..하핫 그래서 사람과의 협업과 매니징이 쉽지않다고 이 당시에 느꼈던게 가장 생생하고, 개발자로서 이 시기에 조금 고민이 있던 것 같다. 앞으로는 많은 사람들의 선배개발자가 될텐데 어떤방식으로 조언을 드려야 도움이 될까를 고민해보게 되었다. 그래서 요즘 신입분들 코드리뷰하면서, 우선 코드단부터 읽으면 좋은 책과 아티클을 PR에 던져드리고 있다🙌 (리뷰를 좀 빡세게 하는 편이라.. 제 리뷰이분들 화이팅..ㅎ)

근데또 써놓고 보니 어렵다 ~_~ 원래 인생 계획없이 사는 타입이라 (지독한 ESTP) 대충 현생에 충실하다보면 미래에도 꽤 괜찮은 사람이 되어있지 않을까

2. 개발 외부 활동

올해에는 커뮤니티 활동을 줄였다. GDSC EWHA 리드였다보니 카카오 면접볼때 받은 질문이 “개발커뮤니티 하는거 좋아하시나요?” 였는데, 그 답변을 충실히 수행했다. “3-2학기 리드활동에 몰입하면서 많은 사람들에게 기여했다는 뿌듯함과 새로운 경력을 쌓은건 좋았다. 그러나 그 때는 개발자로서의 성장이 멈춘 학기였다. 연사섭외 행사준비 등등을 하다보니 개발 공부를 할 시간이 부족했고, 3-1학기의 제 개발 실력과 거의 비슷해서 현타가 왔었다. 그래서 회사에 입사한다면 초반에는 개발공부와 회사 적응에 집중하기 위해 개발커뮤니티쪽에서 눈을 조금 돌리 생각이다.” 라는 답변이었다. 그대로 실천했다. 원래 뭐를 하자는 결심보단 뭐를 하지말자라는 결심이 더 편해서😝

근데 또 막상 되돌아보니 이것저것 하긴 했었더라..? 어쩔 수 없는 관종인가 싶기도하다.

2-1. 유튜브

유튜브는 한달에 한번을 목표로. 블로그는 최대한 기술적인 것들 위주로 쓰고 싶었는데 부진했다. 뭐 어쩔수 없지, 현생을 살면서도 이만큼 챙긴게 어딘가!! 흠흠 유튜브는 (22년 1월 16일 기준) 2813명의 구독자가 생겼다. 정말 소소한 VLOG 동영상만 올리는데도 다들 좋아해주셔서 신기하다. 정작 나는 유튜브는 정말 킬링타임용 및 힐링용으로 예능(더지니어스, 크라임씬, 워크맨 , 문명특급), 게임(파카, 쌀튜브, 여왕럭스) 이런류만 보는편이라 나는 브이로그를 안보는 유튜버다..! (당당)🙄
회사분들이 유튜브 수익 물어보시는데 없다. 유튜브 수익을 얻으려면 구독자 1000명이상 시청시간 4000시간 이상이어야하는데, 내가 영상을 많이 올리지 않아서 시청시간이 부족해서 광고수익이 없다. 아 그런데 상반기에는 멋쟁이사자처럼, 마스슬립에서 협찬 및 광고 제안을 해주셔서 관련 영상을 찍었었는데, 이렇게 협찬을 받고 제작하는 영상은 뭔가 일이 되는 느낌이라 유튜브 영상 올리는게 재미가 없어져서 그 이후부터는 모든 협찬을 거절하고있다. 개발 관련 제품 요청이 아니면 앞으로도 화장품이나 등등의 잡화 요청은 거절할 것 같다ㅋㅋ (뭔가 전자제품이나 파우치 이런거는 유용하지 않을까 싶기도🤔)

유튜브 스튜디오를 보면 분석 전략이 나오는데, 여기 보면의외로 코드윗미가 재생이 많이된다. 그래서 뭔가 나도 다른 코드윗미처럼 이쁜 인테리어 이쁜 조명으로 올리고싶은데..! 음 나는 인테리어가 그렇게 어렵더라;;; 뭔가 내가하는 인테리어는 감성이 부족함 좀더 연구해보겠다😵‍💫 시청자 층은 아무래도 개발자들이 많이 보는지 연령으로는 18~34세가 성별으로는 2:1(남:여) 이더라. 판교뚜벅초(아 진짜 좋아하는 유튜버다 영상이 너무 재밌음), 조코딩, 노마드 코더 유튜브로 흘러들어오는 사람들이 많은듯.

2-2. 블로그

블로그는 사실 올 한해 책을 읽은 달이 훨씬 더 많은데, 책내용을 정리해두긴 했으나 뭔가 내가 정리해둔 정리본을 다시 보기다는 그냥 한번더 읽지 라는 생각이 요즘 들어서 깃에만 저장해두고 블로그에는 따로 정리해서 안올렸다. 그러다보니 블로그에 올라오는 글이 현저히 줄어들었다. 그래서 블로그 인기 글이 대부분 회고록/ 취뽀기 인데,, 흐음 기술 글보다 회고록이 인기가 많은 개발자 블로그라니 🙄이게 맞나? 파트에서 일하면서 ansible이나 이것저것 정리해보고 싶은 주제가 몇개가 있는데 아 주말에 블로그 쓰기/ 유튜브 편집하기가 정말 쉽지않더라 직장인에게 꿀같은 주말이기 때문에…😘 22년에는 시간을 좀 내보는걸로 하자.

아근데 생각해보니, 내 블로그가 아니라 회사블로그에 글을 썼다.ㅋㅋㅋㅋ 카카오 테크 블로그에 내 글이 있다는게 뿌듯하기도하고.. 한번쯤은 해보고 싶었는데 유관부서에서 먼저 요청이 왔다 하핫. 글은 아래에 있다.

https://tech.kakao.com/2021/05/24/jyami/

 

뉴크루의 카카오 백엔드 개발자 이야기

안녕하세요, 톡플랫폼개발팀 톡메시징파트의 신입 개발자 쟈미(jyami)입니다. 저는 자바, 코틀린을 좋아하는 백엔드 개발자이고, 카카오에 들어온 지는 약 반 년이 되어갑니다. 제가 카카오에 입

tech.kakao.com

https://tech.kakao.com/2021/10/25/grace-hopper-celebration/

 

Grace Hopper Celebration 참가기

카카오에서는 크루의 주도적인 성장과 역량 향상을 위해 글로벌한 인사이트 확대를 경험할 수 있도록 해외 컨퍼런스 참관 참여를 지원하고 있습니다. 안녕하세요, 톡플랫폼개발1팀의 jyami입니

tech.kakao.com

위에있는 뉴크루의 백엔드 개발자 이야기가 당시에 페북에서 공유가 엄청 많이 되었던 기억이 있다. 확실히 취업/신입 개발자 관련 주제는 엄청 핫한가 보다. 다음에 회사블로그에 또 글을 쓴다면 그건 꼭 기술에 대한 적용기 이야기를 쓰고 싶다. 그동안 너무 커리어적인 글만 양산한거 아닌가 싶어서 내가 과연 기술적으로 성장하였는가? 라는 고민이 있었기 때문이다.🙌 (근데 요즘 공부를 안함…흠…)

2-3. 외부 인터뷰

상반기에 이곳저곳에서 인터뷰가 생각보다 많이 들어왔었다. 다 비슷비슷하게 취업기 관련 커리어 글이었는데, 학교에서도 들어오고 대학 잡지, 기술 뉴스레터 등 다양한 곳에서 나의 이야기를 담아주셨다.

http://inews.ewha.ac.kr/news/articleView.html?idxno=32531

 

선배들의 따끈따끈 ‘취뽀’ 성공담 – 카카오(Kakao) 개발자 편 - 이대학보

코로나19의 여파로 취업 시장이 얼어붙었다. 청년층의 실업자 수는 2017년 이후 최고치를 기록했다. 이런 취업난에도 최근 다양한 분야에 취뽀(취업뽀개기)한 이화인들이 있다. 본지는 이들의 이

inews.ewha.ac.kr

https://maily.so/1step/posts/4a440c

 

📑 IT 대기업 입사는 공채만이 답?

프로합격러가 들려주는 주니어 상시채용 취준 꿀팁

maily.so

http://www.campl.co.kr/contents/content_read.asp?idx=10483

 

“하고 싶은 건 다 해보고, 끊임없이 배우는 것이 중요해요” 카카오톡 김민정

캠퍼스플러스

campl.co.kr

 

3. 스터디

신입일 때는 이것저것 막 공부해야하는거 아닌가 싶어서 상반기 하반기 모두 채찍질 하면서 스터디를 생각보다 많이 했던 것 같다. 그런데 지금 되돌아보면 이것저것 일을 벌리면서 스터디를 하는 것 보다 정말 관심있는 것 몇가지만 집중해서 하면 좋았을텐데라는 아쉬움이 있다. 현재는 스터디를 이것저것 했지만, 그 시간을 헛으로 보낸 것 같다는 느낌이 들어서 전부다 그만두고 쉬고있는 상황이다. 내가 공부하고 싶을 때 하고, 스터디를 시작한다면 상황적으로 여유가 될 때 하나만 집중해서 하고싶다.

3-1. Next Step Effective Kotlin (2월 ~ 3월)

혼자서 코틀린 인액션 책을 읽었는데 챕터 5까지 정도밖에 안읽고 실제로 쓸 일이 없으니까 코틀린을 적당히 자바 문법이랑 호환되는 부분만 사용할 줄 알지, 실제 코틀린 문법을 알고 적절하게 사용하고있다는 느낌이 안들었다. 그래서 자바봄에서, 우아한 프리코스에서 했던대로 코틀린을 써보면 좀 더 익숙해지지 않을까 생각해서 넥스트스텝 교육을 신청했다. 리뷰를 받으면서 내가 몰랐던 코틀린 문법이나 패턴들을 알게된 건 좋았으나, 퇴근하고 미션을 수행하는게 정말 쉽지않더라.. 그래서 미션 4개중에 2~3개 정도까지만하고 완수는 못했다. 그래도 리뷰 받은 내용들이 모두 도움이되는 내용이었고, 감사했다. 따로 다시 공부해야하는데… 이번에 코틀린 관련 업무를 시작하면서 좀 더 봐야겠다.
https://edu.nextstep.camp/c/Z9QeJlCi/

 

이펙티브 코틀린(Effective Kotlin) with TDD, Refactoring, Clean Code

edu.nextstep.camp

3-2. 자바봄

대학교 3학년때부터 하던 스터디이다. 사실 이 스터디 덕분에 자바를 좀더 집중적으로 공부할 수 있었고, 취업할 때 덕이 컸다고 생각한다. 모든 인원이 전부 취업에 성공하면서 배민2 / 네이버 / 카카오 / 마리트 이렇게 모두 직장을 갖게되었는데, 그럼에도 나름 꾸준히 올해도 책을 조금씩 읽어나가면서 서로 질문하고 답변하고 찾아보는 형식의 스터디를 계속해서 진행했다. 자바봄에서 올해 했던 책 리스트에 대한 건 아래 링크에서 볼 수 있는데, 어느 순간 이 리포가 스타 200을 넘어섰다!! 다들 열심히 정리하고 관리하는 레포지토리라서 많은 사람들이 참고한다는 점에 되게 뿌듯하고 신기해했던 기억이 있다.
https://github.com/Java-Bom/ReadingRecord

 

GitHub - Java-Bom/ReadingRecord: 📚 책 읽고 정리하기 📚

📚 책 읽고 정리하기 📚. Contribute to Java-Bom/ReadingRecord development by creating an account on GitHub.

github.com

자바봄에서는 총 3가지 책을 했는데, 각 책에 대한 느낌은 아래와 같다. (괄호에 들어간 이름으로 issue 라벨을 관리중이다.)

• 토비의 스프링 (Spring of Toby) : 확실히 스프링을 하는 개발자라면 한번은 읽어 봐야하는 책이었다. 대충 읽고 넘어간 부분도 있고, 집중해서 읽고 넘어간 부분도 있었는데, 이 책을 다시본다면 그때는 스프링 내부 코드와 함께 봐야겠다는 생각이 들었다. 다만 이번에 책을 읽을 때는 호흡을 길게 가져가면서 읽어서 이전에 읽었던 내용도 까먹고 넘어가고 했던게 종종 있었다. 앞으로는 두꺼운 책이라도 호흡을 짧게 가져가면서 읽고싶다. (쉽지않겠지만..)
• 쿠버네티스 입문 (Kubernetes introduction) : 음 개인적으로 재미없었다. 이책 읽은 것중에 쿠버네티스 구조 부분 좀더 보고싶어서 쿠버네티스 인액션이랑 공식문서 함께 보면서 혼자 정리한 부분은 재밌었는데, 그 외에는 yml 다 따라치면서 어떤 기능이 있다 소개하는 거였기 때문이다. 나는 아무래도 이미 쿠버네티스를 사용해본적이 있다보니 yml 작성하면서 각 오브젝트의 기능을 소개하는 부분은 이미 알고있는 내용이라 그랬을수도 있다. 그래서 쿠버네티스 입문 책보다는 이후에 읽은 쿠버네티스 인액션 책이 좀 더 재밌었다. 그치만 쿠버네티스를 배워본적이 없어서 핸즈온랩처럼 따라하면서 가고싶다면 이책도 나쁘지 않은듯?
• 스프링 배치 완벽 가이드 (Definitive Guide to Spring Batch) : 이 책을 읽으면 좀 더 스프링 배치를 잘 짤 수 있지 않을까 라는 기대로 시작했는데, 정작 소득이었던건 배치 repository 구조를 좀 보게된 것 정도인 것 같다. 내가 리딩을 하지 않으면 적당히 책을 읽고 넘어갔었기 때문이다. (이때 쯤부터 책읽는걸 조금 힘들어했었다.) 배치 인터페이스를 소개하면서 각종 구현체들에 대한 설명까지 간략하게 나와있는데, 이런게 있구나 하고 알고 넘어가고 사용할 때 직접 써보지 않는다면 잘 와닿지 않는다는 느낌이 있어서 그랬던 것 같다. 역시 책만 읽기보다는 직접 코딩 해보면서 감을 잡아보는걸 좋아하는 타입이다. 그러나 사용하고 싶은 구현체가 있다면 이 책으로 간단히 개요를 보고, 스프링 배치 공식문서를 본다면 빠르게 파악하고 넘어갈 수 있을것 같다.

지금은 자바봄 스터디를 멈춘 상태이다. 다들 일이 바쁘고, 의욕이 안살아서 조금 휴식기를 가지기로했다.

3-3. 설계 스터디 (8월 ~ 11월)

• 가상 면접 사례로 배우는 대규모 시스템 설계 기초

GDSC로 알게된 정동오빠가 주도해서 하게된 스터디이다. 아예 인연이 없는 새로운 개발자 분들과 스터디를 하게 되었고, 배민 / 토스 / AWS / 카카오 조합으로 책을 봤다. 다양한 회사의 사람들이랑 이 책을 읽었을 때 좋았던 점은 각 회사 본인의 도메인에서 봤던 설계에 대해서, 실제로 어떻게 사용하고있는지 경험담을 들을 수 있던게 좋았다. 이 책 내용이 조금 대략적으로 간단하게 설계에 대한 이야기를 하고있는데, 책의 내용으로는 가벼울 수 있는 내용을 각 구성원들의 경험과 지식으로 채우면서 생각보다 재밌었다. 이 스터디를 하면서 위에 말했던 애플리케이션 코드의 중요성 뿐만아니라 설계에 대한부분도 좀더 보는 개발자가 되어야하지 않을까? 라는 생각을 하게되었다.

정동오빠가 설계 관련해서 공부하기 좋은 아티클 링크나, 유튜브 영상 링크를 보내줬는데, 올해중에 맘잡고 전부 싹 훑어보고 블로그에 하나씩 업로드하는게 목표이다. 이 책을 읽은 것 만으로는 조금 빈약한 부분이 있었기 때문이다. 그리고 이 책을 읽으면서 면접에서 서버당 TPS 이런 수치들은 어떻게 추측할 수 있는지 우리파트 시니어 개발자 분께 여쭤봤는데 경험의 영역이라고 한다. 그래서 파트에서 사용하고있는 서버의 대수나 그에 대비하는 TPS, 구조를 좀 더 기억하거나, 정리하는게 중요하다는 인사이트를 받을 수 있었다. 실제로 파트에서 장애나, 연말대응같은 빅 이벤트에서의 회고를 진행하면서 여러 수치적인 지표를 한번 더 짚고 넘어가고 있는데, 할 때마다 되게 좋긴하다.

3-4. 책 스터디 (1월 ~11월)

GDSC로 알게된 원범오빠가 본인의 대학 친구들하고 하고있는 스터디이다. 왜하게된건지 기억은 안나는데, 이 스터디는 자바봄과는 다르게 엄청나게 짧은 주기로 책을 읽고 리뷰한다. 책 한권을 잡으면 일주일에 2번 모이고, 각 모일때마다 한챕터씩 읽어야한다 (약 60~70페이지 분량). 기존에 책을 널널하게 읽는데에 익숙해져있어서, 하루에 한 챕터 읽기도 힘들어했던 내가 (소설아니면 책읽는거 진짜 싫어한다 원래). 그냥 하루에 열심히 한 챕터 정도는 읽어보자하면서 변화하게 되었다. 그러다보니 생각보다 많은 책을 읽을 수 있다는 점은 좋았지만, 집중해서 보고싶은 부분을 시간에 쫓겨서 넘어간 적도 많았었다.

• 마이크로 서비스 패턴 : 가장 맨 처음에 읽었던 책이라서 기억이 잘 안난다ㅠㅠ 그런데 되게 여러가지 패턴이나 도식도를 보면서 최대한 내가 알고있는 예제들과 적용시키면서 이해하려고 했던 기억이 난다. 아무래도 파트에서 이미 적용하고 있는 부분도 있고, 아닌 부분도 있어서 이런 이해 방식이 가능했던 것 같다. 가장 어려웠던 부분은 아무래도 분산 트랜잭션 부분이었다.
• DDD Start : DDD를 모르는 스터디 원들도 계셨기에 앞에있는 MSA 책 이전에 이 책을 읽으면 좋았겠다 싶었다. 좋았던건 내가 그동안 객체지향이라고 부르던 것들이 애그리거트 / 도메인 / 도메인 모델 등등 특정 단어로 명명되고 있다는 걸 알게되었다는 점이었다. 이 책을 읽기는 했지만 나는 DDD를 하고있는가? 라고 제대로 알고 사용하고 있는 것 같지는 않다고 대답할 것 같다. 위에서 말한 용어들을 의식적로 인지하고 구현하고 있지 않기 때문이다. 책 자체는 엄청 쉽게 설명이 되어있어서 말 그대로 DDD를 시작하는 사람이 읽으면 좋을 것 같다.
• 리팩터링 (2판 사진을 올렸으나 자바로 되어있는 1판을 읽었다.) : 파트에서 리팩터링 과제를 맡고있어서 이 책을 읽으면 엄청 도움이 되지 않을까? 기대를 하고 봤는데 사실 조금 실망인 부분도 있었다. 여기서 소개하는 일부 패턴 및 전략들이 intellij ide로 대체가 가능 한 것들이 있었는데, 옛날 책이라 어쩔 수 없는 것 같다. 그러나 개발자 교양서라고 부르는건 인정.
• 쿠버네티스인액션 : 쿠버네티스 yml을 짜기는 하지만, 좀더 깊게, 혹은 구체적으로 알지 못했던 부분을 하나씩 추가하는 느낌이라 좋았었다. 그러나 뒷부분으로 갈 수록 사용을 안해본 오브젝트이거나 하는 경우에는 이해나 응용을 떠오르기 어려웠었다. 근데 etcd, api 서버, kubelet 등 쿠버네티스 구조와 관련된 컴포넌트들을 이 책을 통해 열심히 봤었다.
• 데이터중심 애플리케이션 설계 : 아 진짜 어려웠다. 이 책이랑 대규모 시스템설계 기초 책을 함께 봤었는데, 그러다보니 더더욱 분산 시스템 설계의 중요성에 대해서 공부해봐야겠다고 생각이 들었던 때가 이 때쯤이었다. 아근데 진짜 어렵다. 책의 모든 내용이 나에게 도움이 되진 않았고, 한 앞에서부터 2/3 지점까지가 굉장히 좋았다. 뒷부분은 하둡, 스파크 등 데이터 분석에 대한 내용이었는데, 아무래도 관심이 가질 않았기 때문이다.

이 스터디역시 마무리했다. 올해 스터디를 전부다 책 스터디만 하면서 스터디 시간으로 인해 책만 읽고 실제 코드로 구현을 해보거나 더 찾아본다거나 하는 일이 없었어서 조금 현타가 왔었다. 그래서 지금은 전부다 그만둔 상태! 리프레시 하고 다시 원하는 공부를 하는걸로 하자.

3-5. 사내 스터디

• redis 스터디 : 사내 스터디로 파트 대부분의 분들이 참여했었는데, 여기에서도 redis-cluster를 k8s helm과 함께 사용하는 방법에 대한 발표를 내부적으로 진행했었다. 이때 bitnami 레포를 분석하면서 분석한 내용을 바탕으로 내부적으로 어떤 명령어들이 실행되어서 이런 설정들이 가능한지를 발표했었다. 그러나 현재 파트에서 진행하는 redis-cluster 전환 작업은 참여하고있지는 않다. 전환 작업을 하고계시는 분들의 진행과정 발표를 들었었는데, 공부한 내용을 직접 적용하기 위해 많은 것을 공부하고 설정값 확인부터 모니터링까지 모든 것을 염두하기 쉽지않을텐데 정말 대단하시다고 생각했다.
• UNIX 고급프로그래밍 : 내가 입사하기 9개월전에 입사하신 주니어 개발자 분과 둘이서 하고있다. 아무래도 우리 파트 코드중에 C로 되어있는 코드가 있어서 이 책을 읽으면 조금 진입장벽이 낮아지진 않을까?! 기대를하면서 이책을 시작하게 되었는데. 엄.. 어렵다. unix에서 사용하는 함수나 용법에 대한 설명이 있어서 와닿기 어려울 때도 있고, 어쩔때는 운영체제 수업, 컴퓨터 구조 수업을 잘 들어둘껄 생각도 든다. 그래도 회사 분이랑 함께 시작 한 스터디니까, 어찌저찌 끝마추지 않을까

3-6. 외에 개인적으로 본 책

• 네티 인액션 : 이전에 내가 검증형계약직에서 정규직으로 전환될 때 했던 과제가 네티가 필요해서 읽었었다. 그런데 인턴분이 진행하신 프로젝트 역시 네티를 사용해서 코드리뷰와 적절한 가이드를 위해 한번 더 이 책을 읽었다. 한번 읽으면 슈루룩 읽는데 뭔가 응용해서 짜보려하니 쉽지 않았다.
• 코틀린 인액션 : 읽다가 말았다ㅠ 책을 읽는거에 그치지 않고 책에 있는 예제를 하나하나 따라해보고 실행해보아야 온전한 내 것이 될 것 같아서 눈으로 읽기를 그만두었으나. 다른 책 스터디에 밀려서 우선순위가 후순위가 되었다.
• redis 운영 관리 : 간단하게 읽기 좋은데 진짜 꿀팁만 담겨져 있다. 100페이지도 안되서 더 좋다. 간략 정리글은 내 블로그에 있다 : https://jyami.tistory.com/141
• 프로그래머의 뇌 : 요즘 읽고있다. 개발 책만 읽는게 힘들어서 개발 인문학(?) 느낌으로. 근데 읽다보니 내 뇌가 마치 컴퓨터처럼 되어있나라는 생각이 든다. 사람의 기억을 램과 디스크와 CPU로 비유해서 서술한다.

 

4. 이화여대

4-1. 토익과 졸업

졸업했다!!! 드디어!! 토익 졸업 자격 요건 때문에 졸업을 못할 뻔 했는데 이것도 통과했다!!! 사실 원래대로라면 20년 말에 토익을 보고 21년 2월 졸업을해서 바로 칼졸업을 하는게 베스트였는데, 20년 말에 카카오 정규직 전환 인터뷰를 준비를 하면서 학교 졸업요건들을 잘 챙기지 못했었다. 그래서 유예하고 21년 8월 졸업을 노렸었는데.. 이것 역시 까먹고 얼레벌레 살다가 한 6월쯤 되서 생각나서 토익 점수 마감일 계산해서 공부를 딱 2주 할 수 있는 시간이 있었다.
원래 20년 말에 노베이스로 토익을 그냥 공부 안한 상태로 봤을 때 565점이었다. 그런데 졸업을 위해 700점을 2주만에 맞춰야하는 상황이었다..!! 미리 공부좀 해두었으면 좋았을걸, 나중에 나중에 미루다가 2주동안 공부해서 135점을 올려야하는 상황이었다. 그래서 당시에는 9시 출근 6시나 7시 퇴근하고 밥 먹고 10시 11시까지는 토익공부에 집중하고 힐링을 위해 롤 1~2시간 정도 하는 삶을 살았었다. 그렇게 해서 결국 나온 결과는 710점. 영어공부 목적이 아니라 정말 졸업만을 생각하고 달렸었기 때문에, 700점만 넘으면 되서 더도말고 덜도 말고 딱 2주동안 해서 700점 넘었다는게 너무 좋았다 (더 공부했으면 억울할 뻔)

그렇게 진짜로 졸업했다!! 우리학교 기준 평점 4.3 만점 3.85 학점으로 졸업을 할 수 있었다. 학점에 대한 비결은,, 나는 전공을 좋아해서 전공 학점은 거의 A대 였다. 그래서 전공을 늘리고 교양을 줄였는데, 교양은 대부분 패논패로 처리해서 최대한 전공학점이 반영이 되게 학점관리를 했었다. 그래서 전공학점을 기준으로하면 4.3 만점 4.05 학점이다. 나름 학교 생활을 성실하게 했다는 지표이기 때문에 이력서에도 열심히 넣었었다. (아.. 이력서 업뎃도 해야하는데..)

4-2. 학관 리모델링 재건축기금 기부

작년 2월 학관 리모델린 재건축기금 기부를 받는다고해서 이제 막 월급 따박따박 받는 사회초년생이 된 기념으로 바로 300만원 기부를 했었다. 후원자 기념판 이름에 등재된다고 해서 매우 기대가 된다. 학교에 기부해서 내 이름이 학교 어딘가에 걸려있는게 나름의 버킷리스트였는데, 당시 기회가 있을 때 잡자! 생각해서 일단 신청은 CMS로 했는데.. 다음날에 대외협력처에 바로 전화해서 그냥 일시불로 입금했던 기억이 있다. 지금처럼 당당하게 나를위한 삶을 살 수 있게 된게 우리학교를 다닌게 영향이 분명히 있고 학교에 애정이 있기 때문에 꼭 해보고 싶었다.

5. 일상

5-1. 운전 면허

5월인가 운전 면허를 땄다. 그동안 돈이 없다는 핑계로 못했던 거였는데, 직장인이 되고 일상, 수익이 안정되니까 이제 한번 해볼까? 하고 도전하게 되었다. 필기 기능 도로주행 모두 실패없이 한번에 통과했다!!! 그런데 지금 사는 곳이 교통이 좋아서 딱히 자차가 필요가 없어서 그런데 정작 차는 없어서 장롱면허가 될 예정이다ㅋㅋ 캐스퍼가 막 출시됐을때 무리해서라도 차를 살까 하는 뽐뿌가 엄청 왔었는데, 그래도 정작 써먹을 데를 생각해보니 없는 것같아서 한 30살에 가까워 질 때쯤 사야지 생각했다.
아 면허를 따면서 웃겼던 기억은..ㅋㅋㅋ 나는 길치인데, 도로주행 길이 진짜 너무 안외워져서 그냥 길이나 내가 해야하는 행동을 종이에 적어서 다 외워갔다. 운전학원 유튜브에 도로주행 연습하는 영상이 있었는데, 그 영상으로 보면서 "신한은행 간판이 보이면 우측 깜박이" > "이후 사거리에서 우회전 (핸들은 빠르게 한바퀴)" 이런식으로... 친구들이 듣고 경악했다. 나중에 실제로 운전해야 할 때는 연수 제대로 받고 해야지..

5-2. 머리색 근황

그동안 살면서 탈색을 한번도 안했었다. 다들 염색한번 해보는 시기인 고3 수능 끝나고에는 “한국사람이면 그냥 검정머리가 제일 이쁘지” 이렇게 생각하고 머리를 해도 파마만 했었는데ㅋㅋㅋ 그냥 문뜩 올해 5월 지금 20대 초반일때 탈색 한번도 안하면 평생에 앞으로 할 일 없지 않을까? 하고 질렀다 그러고 지금까지 유지중이다. 탈색하고 헤어제품도 엄청 많이사고 발열현상이나 등등 미용사 쌤한테 들으면서 알게 된게 많은데, 확실히 머리색을 바꿀 때 기분전환이 잘 되었다. 내 머리가 발열현상이 잘일어나서 탈색을 3번했는데도 백금발 탈색은 어려워서ㅠ 애쉬그레이 같은 색은 제대로 색이 안나와서 주로 붉은 계열로 염색을 한다. 근데 이게 탈색을 하다보니 머리색이 옅어지는 것 같기도..? 앞으로 한 일년정도 더 유지해볼까 고민중이다.

5-3. 운동

재택근무를 하다가 어느순간 너무 오래 앉아있었는지 허리가 아파서 이제 슬슬 운동을 해야하나? 생각이 들었다. 재택근무를 위주로하니까 처음에는 의자를 시디즈로 바꾸는걸로 시작했는데, 그거와는 별개로 자취도하다보니 식습관이나 건강이 급 걱정이되었다. 작년 여름부터 계속 은님이 “조져지기 전에 운동하세요” 했었는데, 이러다가 조져지고 나서 운동하려나 싶어서 최대한 빨리 시작하자 하고 PT를 시작했다. PT를 하면서 아쉬웠던게 선생님이 많이 바뀌었던건데ㅠ 지금 하고있는 피티까지 다하면 40회정도되는데 선생님 변경만 3번이 있었다. 처음에 만났던 선생님이 잘맞아서 운동에도 재미붙이고 개인운동도 나가고하면서 20회를 결제했는데, 그 선생님이 퇴사를 하게되어서 7회는 중간에 다른 선생님이랑 하면서 또 적응하고, 새로운 헬스장으로 옮기면서 그 헬스장에서 다른 선생님이랑 지금 20회를 진행하고있다.
처음 받았던 쌤이랑 했을 때 매일매일 피티 받은 내용을 안잊으려고 쌤이 했던 조언들을 빼곡히 적어놨었다. 지금은 strong 어플을 사용하고있다.

확실히 지금 근력이 처음보다는 나아지고 관심이 많아지고있다는걸 느끼고있긴한데, 처음받았던 선생님이랑 쭉했으면 좋았겠다 싶어서 너무 아쉽다. 처음에 맨몸스쿼트만 하던내가 지금 랙에서 40KG 바벨들고 스쿼트 하고있다는거 보시면 와 처음에는 이랬는데, 지금은 이렇네요 이러면서 같이 뿌듯해하고 좋아해주셨을텐데 싶어서 말이다ㅠ. 그래도 처음 만났던 그 선생님 덕분에 뭔가 목표를 하나씩 깨는 느낌이 좋았었고, 주변에 재연언니나 은님 등등 운동에 관심많은 사람들이랑 얘기하면서 더 알아보다보니까 운동하는게 생각보다 재밌다. 원래는 슬라임, 달팽이 소리하면서 운동 귀찮아아 이러고 다녔는데 반년만에 생각이 바뀌다니 신기하다.
운동은 주에 3~4회정도 가고있다. 피티 받으면서 좀 더 스트레칭에 신경쓰려고 폼롤러 마사지도 많이 해주고있다. 개발자다보니 확실히 목 어깨 겨드랑이쪽 근육이 많이 뭉쳐서 업무 중간중간 마사지볼이나 폼롤러로 근육이 뭉치지 않게하려고 조금씩 해주고있다. 이렇게 해주면 좋은게 업무할 때도 리프레쉬 될 때도 있고, 상체운동 할 때 근육이 안뭉쳐있는 상태로 하면 덜 아프긴하더라. 여튼 피티를 시작으로 여러 운동에 관심이 갔고, 실제로 다른 운동들에도 좀 더 근력 더 키우고 해보고싶다라는 마음도 많이든다. 작년과 비교하면 내 인생에서 운동이 정말 큰 변화였던 것 같다.

---

이렇게 회고 끝!! GDSC 리드했던 멤버들이랑 매년 회고 릴레이를 하고있는데, 귀찮아 하면서도 막상 쓰면 엄청 길게 일년동안의 내 생각들을 주저리주저리 적고있는 것 같다. 1년치 일기장이라서 당연히 그럴 수 있지.

다들 회고록에 내년 목표를 적는데, 적당히 살자. 적당히 현생 챙기면서 살다보면 해피한 미래가 있겠지 👀 장기 계획세우면서 사는 타입이 아니라😳 2022년에도 활기차게 에너지 넘치는 쟈미로 살자 2021년 고생 많았다 안녕🙌🙌

Before I start this retrospective, “once again this year,” there were no issues with the KakaoTalk messaging server at year-end!!! Since I was the one directly handling the year-end response this time, I wanted to document the year-end experience too, which is why I ended up delaying this retrospective.

I joined the company in September 2020 and started doing real hands-on work from December, and now it's 2022!! I can't believe I'm in my 3rd year?!! It's so surprising lol. I've really only been doing actual work for about 1 year and 1 month, yet I'm a 3rd-year developer.. That's amazing all over again.
So 2021 was a time for me to adapt as a working developer after joining the company, and since development became my profession, it was also a time to try things outside of coding to find a balance between work and life. With that, let's dive into the retrospective!

This retrospective feels like writing a year's worth of diary entries, so the readability isn't great.

 

1. Work

1-1. Treating work like homework?

I wrote daily work logs and tackled company tasks one by one, and comparing the first and second halves of the year, I can definitely feel a big difference.
In the first half, just deploying the dev version of the regular chat was thrilling and nerve-wracking, but by the second half, I was scaling up servers and deploying that same regular chat to the real/production version, tweaking ansible configs here and there for deployment settings, and eventually even handling the year-end response. Is this what it means to gain experience..?😳

There was definitely a noticeable difference in how I approached work between the first and second halves. In the first half, I kept wondering, "Am I really good enough to take on such a big task? I don't know much — should I really be taking on messaging work?" I hesitated and only worked on things that senior developers assigned to me. But in the second half, compared to the first, I started proactively seeking out work. I picked up a few issues that had been sitting around in our team, got closer with the client-side developers and actively communicated with them to provide messaging logic guidelines, and when I found something in the code that I wanted to fix, I'd create an issue and work on it myself. Early in the first half, a senior on my team told me, "Jyami, you do your work like it's homework." When I first heard this, I thought nothing of it — like, "Well, I've always done my homework well and with high quality. Does that mean I'm very meticulous?" But it kept bugging me, so I asked Eun about it and realized it meant I needed to be more proactive with my work.

1-2. What makes a good developer?

Still, I feel like I'm only picking up small, minor issues for now. There was a senior developer who volunteered to lead the C-to-Java porting effort, and I wonder if someday I'll be the one raising big issues like that too. Seeing things like this, I really feel there are so many people to learn from in the messaging team. But because of that, my thoughts on "what kind of developer should I be" have shifted since before and after joining the company. Before, I naturally thought since I love Java and Spring, I should dig deep into them and apply clean code, DDD, and all that stuff, and that once I started working, if I dug into Spring's internals, I'd become a good developer. But after joining, I've been realizing that knowing how to design better server architectures and properly use various components is also extremely important.

I think it's because when outages happen or when planning for new components, what matters more than how you write the code is the practical perspective — how to improve performance, how to handle edge cases, and so on. So before, when it came to using Redis, I used to think about which methods to use with spring-data-redis to write good code and good test code. But now, working in the messaging team, I've realized you need to think about Redis itself first. I've learned from experience that understanding Redis's data structures, failover policies, eviction policies, backup strategies, and so on is more important. So my thinking is shifting toward the idea that rather than being good at a particular language, a developer who can solve problems well when issues arise is probably the best to work with. I shared these thoughts with my team lead several times, and they advised me that everyone walks a different path and there's no single right answer for what makes a good developer.

1-3. Intern mentor / New hire code reviewer

Starting in the second half, interns and new hires began joining under me. I still feel like a newbie myself.. but I mentored an intern and am now responsible for code reviews of new hires who came in through the regular recruitment process. Honestly, I was a bit worried at first since some of them were older than me, but it turned out fine.✌️ After all, the new hire assignments were within the scope of what I knew, and anything I didn't know, I could just study up on.
Although I don't have a ton of experience myself, while mentoring the intern, I figured out what kind of person the company wants to hire as a new developer and guided them accordingly.

Working closely alongside the intern, I learned a lot, and I did my best to help them pass — advising them on everything from code to decision-making. But looking back, I think my enthusiasm might have been even greater than the intern's.. haha. That's when I most vividly felt that collaboration and managing people isn't easy, and I think I was going through some growing pains as a developer during that period. I started thinking about how, as I'll eventually become a senior to many people, what's the best way to give advice that's actually helpful. So these days, while doing code reviews for the new hires, I first share books and articles that are good to read at the code level and drop them in the PR🙌 (I tend to give pretty tough reviews.. so hang in there, my reviewees..heh)

But then again, writing all this out, it is tough ~_~ I'm originally the type who lives without plans (a hardcore ESTP), so I figure if I just do my best in the present, I'll probably turn out to be a pretty decent person in the future too.

2. Activities outside of development

This year, I cut back on community activities. Since I was the GDSC EWHA lead, one of the questions I got during my Kakao interview was, "Do you enjoy participating in developer communities?" And I stayed true to my answer: "During my 3-2 semester as lead, I felt proud of contributing to many people and building new experience. But that semester, my growth as a developer stalled. Between inviting speakers and preparing events, I didn't have enough time to study development, and my skills were about the same as in my 3-1 semester, which was frustrating. So if I join the company, I plan to step back from developer communities early on to focus on studying and adapting to work." I followed through on that. I've always found it easier to commit to NOT doing something rather than committing to doing something😝

But looking back, I actually ended up doing this and that..? Maybe I just can't help being an attention-seeker.

2-1. YouTube

My goal was to post on YouTube once a month. I wanted to focus my blog on technical content, but that didn't go well. Oh well, what can you do — at least I managed this much while living my life!! Hmm, as of January 16, 2022, my YouTube channel has 2,813 subscribers. It's amazing that people enjoy it even though I only upload casual VLOG videos. Meanwhile, I personally only watch YouTube for killing time and relaxation — variety shows (The Genius, Crime Scene, Workman, Civilization Express), gaming channels (Paka, Ssal Tube, Queen Lux) — so I'm a YouTuber who doesn't watch vlogs..! (proudly)🙄
People at work ask me about YouTube revenue, and the answer is none. To earn YouTube revenue, you need over 1,000 subscribers and 4,000+ hours of watch time, but since I don't upload many videos, I don't have enough watch time for ad revenue. Oh, but in the first half of the year, I got sponsorship and ad offers from Likelion and Mars Sleep, so I filmed some sponsored content. But making videos with sponsorships felt like work, which took the fun out of uploading YouTube videos, so I've been declining all sponsorships since then. Unless it's a dev-related product, I'll probably keep turning down cosmetics and other miscellaneous product requests lol (though I do think electronics or pouches could actually be useful🤔)

When I look at YouTube Studio analytics, it shows strategy insights, and surprisingly, "Code With Me" videos get a lot of views. So I kind of want to film them with nice interior decor and pretty lighting like other Code With Me channels..! But ugh, interior decorating is really hard for me;;; My decorating attempts always lack that aesthetic vibe. I'll do more research😵‍💫 As for the viewer demographic, since it's mostly developers watching, the age range is 18–34 and the gender ratio is 2:1 (male:female). It seems like a lot of people find my channel through Pangyo Walker (ah, I genuinely love this YouTuber — their videos are so fun), Jocoding, and Nomad Coders.

2-2. Blog

As for the blog, I actually spent more months reading books this year, and while I did take notes, lately I've been thinking "instead of re-reading my notes, I'd rather just re-read the book," so I've only saved them on Git and haven't organized them into blog posts. As a result, the number of posts on my blog dropped significantly. So my most popular blog posts are mostly retrospectives and job-landing stories,, hmm — a developer blog where retrospectives are more popular than technical posts 🙄 is this right? While working with my team, there are several topics I want to write about like ansible and other things, but ah, writing blog posts and editing YouTube videos on weekends is really not easy when weekends are so precious for office workers…😘 Let's try to make some time in 2022.

Oh wait, now that I think about it, I didn't write on my own blog — I wrote on the company blog lol. It feels pretty great to have my article on the Kakao Tech Blog.. It was something I'd always wanted to do, and a related team actually reached out to me first, haha. The posts are below.

https://tech.kakao.com/2021/05/24/jyami/

 

뉴크루의 카카오 백엔드 개발자 이야기

안녕하세요, 톡플랫폼개발팀 톡메시징파트의 신입 개발자 쟈미(jyami)입니다. 저는 자바, 코틀린을 좋아하는 백엔드 개발자이고, 카카오에 들어온 지는 약 반 년이 되어갑니다. 제가 카카오에 입

tech.kakao.com

https://tech.kakao.com/2021/10/25/grace-hopper-celebration/

 

Grace Hopper Celebration 참가기

카카오에서는 크루의 주도적인 성장과 역량 향상을 위해 글로벌한 인사이트 확대를 경험할 수 있도록 해외 컨퍼런스 참관 참여를 지원하고 있습니다. 안녕하세요, 톡플랫폼개발1팀의 jyami입니

tech.kakao.com

The "New Crew's Kakao Backend Developer Story" post above got shared a ton on Facebook at the time. Career/new developer topics are definitely super popular. If I write on the company blog again next time, I really want it to be about applying a specific technology. I'd been feeling like I've only been producing career-related content, which made me wonder, "Have I actually grown technically?"🙌 (But lately I haven't been studying… hmm…)

2-3. External interviews

In the first half, I got more interview requests from various places than I expected. They were all pretty similar — career-related stories about landing a job. Requests came from my university, college magazines, tech newsletters, and more, all featuring my story.

http://inews.ewha.ac.kr/news/articleView.html?idxno=32531

 

선배들의 따끈따끈 ‘취뽀’ 성공담 – 카카오(Kakao) 개발자 편 - 이대학보

코로나19의 여파로 취업 시장이 얼어붙었다. 청년층의 실업자 수는 2017년 이후 최고치를 기록했다. 이런 취업난에도 최근 다양한 분야에 취뽀(취업뽀개기)한 이화인들이 있다. 본지는 이들의 이

inews.ewha.ac.kr

https://maily.so/1step/posts/4a440c

 

📑 IT 대기업 입사는 공채만이 답?

프로합격러가 들려주는 주니어 상시채용 취준 꿀팁

maily.so

http://www.campl.co.kr/contents/content_read.asp?idx=10483

 

“하고 싶은 건 다 해보고, 끊임없이 배우는 것이 중요해요” 카카오톡 김민정

캠퍼스플러스

campl.co.kr

 

3. Study Groups

When I was a newbie, I felt like I had to study everything under the sun, so I pushed myself pretty hard in both the first and second halves of the year and ended up doing way more study groups than I expected. But looking back now, I kind of regret spreading myself so thin instead of just focusing deeply on a few things I was truly interested in. I've done all sorts of study groups by now, but it started feeling like I was wasting that time, so I quit everything and I'm currently taking a break. I want to study when I actually feel like it, and if I start a study group again, I want to focus on just one when I actually have the bandwidth for it.

3-1. Next Step Effective Kotlin (Feb – Mar)

I had been reading Kotlin in Action on my own but only got through about chapter 5, and since I never really had a chance to use it in practice, I only knew the parts of Kotlin that were compatible with Java syntax — I didn't feel like I truly understood Kotlin's own idioms and was using them properly. So I thought maybe if I tried writing Kotlin the way I did at Java-Bom and the Woowa Precourse, I'd get more comfortable with it, and signed up for the Next Step course. It was great to learn about Kotlin syntax and patterns I didn't know through code reviews, but doing the missions after work was really tough... So I only completed about 2–3 out of 4 missions and couldn't finish them all. Still, every piece of review feedback was genuinely helpful and I was grateful. I need to study it again separately… now that I'm starting Kotlin-related work, I'll have to dig deeper.
https://edu.nextstep.camp/c/Z9QeJlCi/

 

이펙티브 코틀린(Effective Kotlin) with TDD, Refactoring, Clean Code

edu.nextstep.camp

3-2. Java-Bom

This is a study group I've been part of since my junior year of college. Honestly, this group is a big reason I was able to study Java more intensively, and I think it helped a lot when I was job hunting. Every single member ended up landing a job — Baemin2 / Naver / Kakao / Marit — and despite that, we still kept going this year, steadily reading books little by little, asking questions, answering them, and looking things up together. You can see the list of books we covered this year at the link below, and at some point the repo crossed 200 stars!! Everyone puts a lot of effort into organizing and maintaining the repository, so it felt really proud and amazing to know that so many people were referencing it.
https://github.com/Java-Bom/ReadingRecord

 

GitHub - Java-Bom/ReadingRecord: 📚 책 읽고 정리하기 📚

📚 책 읽고 정리하기 📚. Contribute to Java-Bom/ReadingRecord development by creating an account on GitHub.

github.com

At Java-Bom, we covered a total of 3 books, and here's how I felt about each one. (The names in parentheses are the issue labels we use to manage them.)

• Toby's Spring (Spring of Toby): This is definitely a must-read for any developer working with Spring. Some parts I skimmed through, others I read carefully, but if I ever revisit this book, I think I should read it alongside the actual Spring source code next time. The thing is, I read it at such a slow pace this time that I'd sometimes forget what I'd read earlier and just move on. Going forward, I want to read even thick books at a faster pace. (Easier said than done, though..)
• Kubernetes Introduction (Kubernetes introduction): Hmm, personally I didn't find it very fun. The part about Kubernetes architecture that I wanted to dig deeper into — which I studied on my own by cross-referencing Kubernetes in Action and the official docs — was interesting, but the rest was basically typing out YAML files and being introduced to various features. Since I've already used Kubernetes before, the parts introducing each object's functionality via YAML were stuff I already knew, which is probably why. So I enjoyed Kubernetes in Action more than this introductory book. But if you've never learned Kubernetes and want a hands-on-lab style experience to follow along with, this book isn't bad either.
• The Definitive Guide to Spring Batch (Definitive Guide to Spring Batch): I started this book hoping it would help me write better Spring Batch jobs, but the main takeaway ended up being just getting a better look at the batch repository structure. When I wasn't the one leading the session, I'd just kind of read through and move on. (Around this time I was starting to get tired of reading books.) The book introduces batch interfaces and briefly explains various implementations, but if you just note "oh, this exists" and don't actually use it yourself, it doesn't really stick — that's how I felt about it. I'm definitely the type who prefers getting a feel for things by actually coding rather than just reading. But if there's a specific implementation you want to use, I think you could get a quick overview from this book and then consult the official Spring Batch docs for a fast understanding.

The Java-Bom study group is currently on pause. Everyone's busy with work and motivation is low, so we decided to take a break.

3-3. System Design Study Group (Aug – Nov)

• System Design Interview – An Insider's Guide

This study group was organized by Jeongdong, whom I got to know through GDSC. I ended up studying with completely new developers I had no prior connection with, and we read the book as a group from Baemin / Toss / AWS / Kakao. The great thing about reading this book with people from different companies was hearing real-world stories about how system designs are actually used in each company's domain. The book covers design topics at a fairly high level, so the content could feel lightweight on its own, but it was surprisingly fun as each member filled in the gaps with their own experiences and knowledge. Through this study group, I started thinking that beyond the application code I mentioned above, I should also become a developer who pays more attention to system design.

Jeongdong shared some great article links and YouTube videos for studying design, and my goal is to go through all of them this year and upload them to my blog one by one. Reading this book alone left some gaps. Also, while reading this book, I asked a senior developer on our team how you can estimate things like TPS per server in interviews, and they said it's a matter of experience. So I got the insight that it's important to remember or document the number of servers our team uses, the corresponding TPS, and the architecture. In fact, during retrospectives for outages or big events like year-end traffic spikes, we go over various numerical metrics, and it's really great every time we do it.

3-4. Book Study Group (Jan – Nov)

This is a study group run by Wonbeom, whom I also met through GDSC, along with his college friends. I don't remember how I ended up joining, but unlike Java-Bom, this group reads and reviews books on an incredibly fast cycle. Once we pick a book, we meet twice a week, and each time we need to have read one chapter (about 60–70 pages). I was used to reading books at a leisurely pace, and I'm the type who struggles to read even one chapter a day (I genuinely hate reading books unless they're novels). But I just told myself "let's push through and at least read one chapter a day" and that changed me. The upside was that I ended up reading way more books than expected, but I also often had to rush past parts I wanted to focus on because of time pressure.

• Microservices Patterns: This was the very first book we read so I don't remember it too well 😢 But I do recall looking at various patterns and diagrams and trying my best to understand them by mapping them to examples I already knew. Since our team was already using some of these patterns and not others, this approach to understanding was possible. The hardest part was definitely the distributed transactions section.
• DDD Start: Since some study members didn't know DDD, I thought it would've been better to read this book before the MSA book above. What was great was learning that the things I'd been calling "object-oriented" were actually named with specific terms like Aggregate, Domain, Domain Model, etc. I did read this book, but if you asked me "are you doing DDD?" I'd probably say I don't think I'm truly understanding and applying it properly — because I'm not consciously aware of those terms when I implement things. The book itself is explained very simply, so it's great for someone who's literally just starting with DDD.
• Refactoring (I posted the 2nd edition cover but actually read the 1st edition in Java): Since I was assigned a refactoring task at work, I had high hopes that this book would be super helpful. Honestly, I was a little disappointed in some ways. Some of the patterns and strategies introduced here can be done with IntelliJ IDE features — I guess it can't be helped since it's an older book. But I do agree it deserves to be called a must-read for developers.
• Kubernetes in Action: I was already writing Kubernetes YAML, but it felt great to fill in the deeper, more specific knowledge gaps one by one. However, as I got into the later chapters covering objects I'd never actually used, it became hard to understand or think of applications. That said, I really dug into the Kubernetes architecture components like etcd, API server, kubelet, and others through this book.
• Designing Data-Intensive Applications: Oh man, this one was really hard. I was reading this alongside the System Design Interview book, and that's around when I really felt the need to study distributed system design more seriously. But seriously, it's really hard. Not everything in the book was useful to me, but roughly the first two-thirds was excellent. The latter part covered data analysis topics like Hadoop and Spark, which just didn't interest me.

I wrapped up this study group too. All my study groups this year were just book study groups, and I ended up only reading books during study time without ever actually implementing code or digging deeper, which gave me a bit of an existential crisis. So now I've quit everything! Time to refresh and get back to studying what I actually want.

3-5. Internal Company Study Groups

• Redis study group: This was an internal study group where most of our team members participated. Here, I also gave an internal presentation on how to use redis-cluster with k8s helm. At the time, I analyzed the bitnami repo and presented what commands were being executed internally to enable certain configurations. However, I'm not currently involved in the redis-cluster migration work our team is doing. I attended the progress presentations from the people working on the migration, and I was really impressed — it can't be easy to study so much to apply what you've learned in practice, keeping everything from config verification to monitoring in mind.
• Advanced Programming in the UNIX Environment: I'm doing this with a junior developer who joined 9 months before I did, just the two of us. Since our team has some code written in C, I started reading this book hoping it might lower the barrier to entry a bit. Umm... it's hard. There are explanations of UNIX functions and conventions that are sometimes hard to relate to, and sometimes I think I should have paid more attention in my operating systems and computer architecture classes. But since I started this study group with a coworker, we'll probably muddle through to the end somehow.

3-6. Books I Read on My Own

• Netty in Action: I had previously read this when I needed Netty for the project I did during my conversion from probationary to full-time employee. But since the intern's project also used Netty, I read it again to give proper code reviews and guidance. It's a quick read once you've been through it, but trying to actually apply and build something with it was not easy.
• Kotlin in Action: I started reading it but never finished 😢 I felt like I wouldn't truly internalize it unless I followed along and ran each example from the book, so I stopped just reading with my eyes. But then it got pushed to the back burner by other book study groups.
• Redis Operations & Management: Simple and easy to read, packed with nothing but golden tips. Even better that it's under 100 pages. My brief summary is on my blog: https://jyami.tistory.com/141
• The Programmer's Brain: Currently reading this. I got tired of only reading dev books, so I picked this up as kind of a developer humanities (?) read. As I'm reading it though, I'm starting to think "wait, is my brain basically a computer?" It describes human memory using analogies of RAM, disk, and CPU.

 

4. Ewha Womans University

4-1. TOEIC and Graduation

I graduated!!! Finally!! I almost couldn't graduate because of the TOEIC score requirement, but I passed that too!!! Ideally, I should have taken the TOEIC at the end of 2020 and graduated in February 2021 right on time, but at the end of 2020, I was preparing for my Kakao full-time conversion interview and didn't keep track of the graduation requirements. So I deferred and aimed for August 2021 graduation... but I forgot about that too, and was just living life until around June when it hit me. I calculated the TOEIC score submission deadline and had exactly 2 weeks to study.
The last time I took the TOEIC at the end of 2020 with zero preparation, I scored 565. But now I needed to hit 700 within 2 weeks..!! I wish I'd studied earlier, but I kept putting it off and ended up needing to raise my score by 135 points in just 2 weeks. So at the time, I was going to work at 9 AM, getting off at 6 or 7 PM, eating dinner, studying TOEIC until 10–11 PM, then playing a game or two of LoL to unwind. The result? 710 points. My goal wasn't to actually learn English — I was purely focused on graduating, so I only needed 700. Getting exactly past 700 in just 2 weeks felt amazing (if I'd studied any more, I would've felt robbed).

And just like that, I actually graduated!! By my school's standards, I graduated with a 3.85 GPA out of 4.3. My secret to the GPA? I loved my major, so my major courses were almost all A-range. I loaded up on major courses and cut down on liberal arts, and handled most liberal arts as pass/fail so my GPA would mostly reflect my major courses. So my major-only GPA is 4.05 out of 4.3. Since it's an indicator that I was pretty diligent during school, I made sure to put it on my resume. (Ah... I need to update my resume too...)

4-2. Student Union Building Renovation Fund Donation

Last February, the school was accepting donations for the student union building renovation fund, so as a fresh working adult who had just started receiving a steady paycheck, I went ahead and donated 3 million won right away. They said my name would be engraved on the donor memorial plaque, which I'm super excited about. Having my name displayed somewhere on campus was one of my bucket list items, and I thought "seize the opportunity while it's here!" I initially signed up via automatic monthly payments (CMS), but the next day I called the Office of External Affairs and just wired the whole amount in a lump sum. Being able to live confidently and on my own terms is definitely partly thanks to attending this school, and I have real affection for it, so I really wanted to do this.

5. Daily Life

5-1. Driver's License

I got my driver's license around May. I'd been putting it off using the excuse that I didn't have money, but once I became a working adult and my daily life and income stabilized, I thought "why not give it a shot?" and went for it. I passed the written test, skills test, and road test all on the first try!!! But since I live in an area with great public transportation and don't really need a car, I don't actually own one, so it's destined to be a dusty license lol. When the Casper first launched, I was seriously tempted to splurge on a car, but when I thought about where I'd actually use it, I couldn't think of anywhere, so I figured I'd buy one when I'm closer to 30.
Oh, a funny memory from getting my license... I'm terrible with directions, and I absolutely could not memorize the road test route, so I just wrote down the roads and every action I needed to take on paper and memorized it all. There was a YouTube video from the driving school showing the road test practice route, and I watched it while writing things like "When you see the Shinhan Bank sign, turn on right blinker" > "Then make a right turn at the intersection (turn the wheel one full rotation quickly)"... My friends were horrified when they heard. When I actually need to drive for real someday, I'll make sure to get proper driving lessons first..

5-2. Hair Color Update

I had never bleached my hair in my entire life. Back when everyone experiments with hair color — right after the college entrance exam in senior year — I was like "Koreans look best with black hair" and only ever got perms lol. Then out of the blue in May this year, I thought "I'm in my early 20s — if I don't bleach my hair now, I'll probably never do it for the rest of my life," and I just went for it. I've been keeping it up since then. After bleaching, I bought a ton of hair products and learned a lot from my hairstylist about things like heat reactions and whatnot. Changing my hair color was definitely a great mood booster. My hair tends to have strong heat reactions, so even after bleaching 3 times, platinum blonde is hard to achieve 😢 Colors like ash gray don't come out right, so I mainly go with reddish tones. But I feel like my hair color is getting lighter with each bleach...? I'm debating whether to keep it up for about another year.

5-3. Working Out

While working from home, at some point my back started hurting from sitting too long, and I thought maybe it's time to start exercising. Since I was mostly working from home, I first started by switching to a Sidiz chair, but aside from that, being on my own with my own cooking made me suddenly worried about my diet and health. Starting from last summer, Eunnim kept telling me "exercise before your body gives out," and I started thinking I'd probably end up exercising only after my body breaks down, so I decided to start personal training as soon as possible. The frustrating part about PT was that my trainer kept changing 😢 Including my current PT sessions, I've done about 40 sessions total, but I've had 3 trainer changes. My first trainer was a great fit — I got into working out, started going to the gym on my own, and bought 20 more sessions. But that trainer quit, so I did 7 sessions with a different trainer while adjusting, then switched to a new gym where I'm now doing 20 sessions with yet another trainer.
When I was with my first trainer, I wrote down all the advice they gave me after every session so I wouldn't forget. Now I use the Strong app.

I can definitely feel that my strength has improved since the beginning and I'm getting more interested, but I really wish I could have continued with my first trainer. I went from doing bodyweight squats to now squatting with a 40KG barbell on the rack — if my first trainer could see that, they'd say "wow, you started like this and now look at you!" and be proud together with me 😢. Still, thanks to that first trainer, I got that great feeling of crushing goals one by one, and talking with people around me who are into fitness — like Jaeyeon and Eunnim — and learning more from them made working out surprisingly fun. I used to go around whining like a slug or a snail saying "ugh, exercise is so annoying," and it's wild that my mindset changed in just half a year.
I go to the gym about 3–4 times a week. With PT sessions, I'm also trying to focus more on stretching and do lots of foam roller massages. Being a developer, the muscles around my neck, shoulders, and armpits definitely get really tense, so I try to use a massage ball or foam roller between work to keep the muscles from knotting up. It's nice because it also refreshes me during work, and when I do upper body exercises without knotted-up muscles, it hurts less. Anyway, starting PT led me to get interested in various types of exercise, and I genuinely want to build more strength and try other workouts too. Compared to last year, exercise has been the biggest change in my life.

---

And that's the end of my retrospective!! The GDSC lead members and I do a yearly retrospective relay, and even though I always grumble about how bothersome it is, once I actually start writing, I end up going on and on about my thoughts from the past year. I guess that's natural since it's basically a year's worth of diary entries.

Everyone writes their goals for next year in their retrospectives, but I'll just say: let's take it easy. If I just keep taking care of my daily life, there'll be a happy future ahead, right? I'm not the type to make long-term plans 😳 Let's live as an energetic, vibrant Jyami in 2022 too! 2021, it's been tough — goodbye 🙌🙌

오아... 이걸 이제야 쓰다니.. 계속해서 고민하다가 드디어 글을 완성해 보려한다. (그래도 카카오 갔는데.. 네이버 후기가 블로그 조회수 가장 높은게 맞나 싶어서ㅋㅋㅋㅋ)
 6월 중순 네이버 정직원 전환 면접에서 떨어진 이후 나는 취준을 시작하게 되었다.

jyami.tistory.com/116

 

네이버 백엔드 인턴십 후기

올해 3월부터 6월까지 약 3개월간 했던 네이버 인턴십 후기를 작성하려 한다. 계속 써야지 써야지 하면서 미루다가 인턴십이 끝난 지 거의 2달가량이 돼서 사실 시간이 꽤 많이 지났지만, 아무래

jyami.tistory.com

네이버 인턴십을 준비할 때는 알고리즘 준비, 면접준비 하나도 없이 그냥 인턴십에 합격했었다. 그래서 회사 첫 면접이 저 네이버 인턴십 면접이었기 때문에 네이버를 갔다면 취준 없이 취뽀를 할 수 있다는 행복회로를 엄청 돌렸었다ㅋㅋㅋ. 그치만 현실은 아쉽게 전환이 되지 못했고ㅠ 진짜 취준하네..? 이러고 취준을 하게 되었다ㅋㅋㅋ

결론만 놓고 보자면 취준을 그렇게 장기간 신경쓰면서 한 것 같진 않지만, 짧다면 짧은 1달간의 취준기를 써보려한다.

 

1. 가고싶은 회사

목표하는 회사 정하기

나는 모든 대학생들이 취준을 시작할 때 본인이 가고싶은 회사에 대한 기준을 세우는게 가장 중요하다고 본다. 공기업, 스타트업, 대기업, IT기업, 외국계 회사 등 너무 다양한 회사가 있고, 각각의 회사마다 신입사원을 뽑는 기준이 다르기 때문이다. 또한 본인이 희망하는 회사가 원하는 인재상부터 시작해서 필요한 기본 스펙 (어학, 자격증 등)부터 각 회사마다의 채용 절차가 전부 다르기 때문에 미리 준비하기 위해서이다. 

예시로 내가 만약 삼성을 가고 싶다 생각했으면, 우선적으로 삼성에서 그동안 나왔던 코딩테스트 기출문제를 풀어보고 채용 절차에 있는 직무 적성검사도 공부할테고, 면접을 간다했을 때 면접의 순서라던지 각 면접의 특징에 맞춰서 준비를 했을 것이다. 이런 채용 절차는 보통 그 회사의 채용 안내 및 전형 프로세스에 자세하게 나와있다. (구글링을 생활화 합시다) 이런 채용 절차를 보면 본인이 현재 가진 스펙을 바탕으로 객관화를 한 후에 부족한 부분을 준비할 수 있다.

본인이 가고싶은 회사를 정했다면 앞으로 길고 긴 채용절차와 그에 맞는 준비를 할 예정일 것이다. 그 고된 과정을 거쳐서도 본인이 가고싶은 회사여야지 합격 발표가 났을때 그만큼 기쁨은 더 될 것이다. 따라서 나는 누구든 꼭 본인이 가고싶은 회사를 우선적으로 선택하고, 그 선택에 집중해서 준비를 하는게 중요하다고 생각한다.

IT 회사가 가고싶어요..

그래서 나는 "개발자로 성장을 할 수 있는 곳" 이라는 키워드를 기반으로 IT회사 혹은 외국계 IT회사를 생각을 했고, 당시 그래서 카카오, 하이퍼 커넥트, 네이버, SAP 이 네 곳에 지원서를 제출했다. (외에도 관심있는 IT회사는 많았지만 당시 내가 관심있어하는 공고가 이 네 곳이었다)

그래서 공통적으로 IT기업이라는 특징을 가진 이 네 곳에서 요구하는 인재상은 사실 비슷비슷 했다. "개발을 좋아하는, 잘하는 개발자"가 핵심 키워드였다. 좀 더 자세히 보면, java를 잘 이해하는 사람, computer science 지식을 잘 알고있는 사람.. 등등 원하는 기술 역량이 잡 디스크립션에 상세하게 적혀있다.

개발자를 채용하는 회사 입장에서 이렇게 물어보는 것 같았다. 앞으로 개발 공부 더 많이 해야할거고, 넌 그동안 개발 서적이나 여러 개발 협업 경험, 전공 지식에 대한 깊은 이해, 본인이 사용하는 주 언어에 대한 이해는 있어야 우리와 함께 할 수 있는데 준비 되어있니? 그렇다. 학부생으로 개발에 어느정도 관심을 가지고 있었고, 개발 능력 향상을 위해 본인이 그동안 어떤 노력과 공부를 했는지, 그 공부가 정확하게 되어있는지를 물어보고 있었다.

그리고 현재 상태의 나는 요구되는 그 역량을 그동안 내가 학부생활 동안 했던 공부 내용이나 프로젝트내용, 기술적인 관심으로 충분히 어필을 할 수 있을거라는 생각이 들었다.  그리고 잡 디스크립션에서 내가 맞지 않는 부분이 있더라도 내가 현재 가지고 있는 기술스택을 충분히 깊게 공부했다는 점을 어필할 생각이었다.

이건 팁인데 본인이 앞으로 무엇을 공부해야할지 모르겠으면, 본인이 가고싶은 회사의 개발역량 지원 자격을 보면 도움이 된다. 나같은 경우 Kotlin 서버 개발 경험이 없는데, 만약 3학년때 이 공고를 봤다면 Kotlin을 공부라는 새로운 공부거리를 찾을 수 있었을 것이다. 그리고 알고있는 내용이라고 하더라도 무조껀 본인이 가능한 최대한 깊게 공부하면 좋다. 예를들어 java 기반 서버 개발 경험이라고 하면, 내 블로그 몇몇 글을 보면 알겠지만 학부에서 배운 자바 수업 외로도 이펙티브 자바와 같은 책을 읽거나, 제네릭과 같이 이해가 안되는 내용이 있을때 더더 찾아보면서 성장하자. 

 

2. IT 기업의 지원 방식

내가 가고싶었던 회사는 주로 IT기업이었고, 그중에서도 카카오, 네이버를 가고싶었다. 그래서 해당 회사에 신입으로 입사를 할 수 있는 방법을 많이 접하고 찾아봤던 것 같다. 내가 볼 때 이 두 회사의 지원 방식은 크게 3가지가 있다.

• 공채 (상시 채용)
• 수시 채용
• 인턴 (상시 채용 / 수시 채용)

공채

공채는 많은분들이 아실 것이라 생각한다. 공채는 주로 상반기 하반기 공채로 나누어져있으며, 한번에 많은 신입 개발자를 뽑는 제도이다. 아무래도 공채는 카카오, 네이버 외에도 많은 회사에서 신입사원을 뽑을 때 사용하는 방법이라 다들 잘 알고있으리라 생각된다.

그러나 IT기업임을 감안하여 공채 특징을 짚어보자면

• 정말 많은 지원자
• 코딩테스트가 어려움
• 면접은 주로 컴퓨터 공학 전공 기초 내용 위주의 질문으로
• 면접에서 N : N (지원자 : 면접관)으로 볼 수 있음
• 바로 정규직으로 입사
• 회사에서 제공하는 지원기간에 맞춰서 본인의 취업 스케줄을 조정해야함
• 입사한다면 동기들이 있음
• 공채 합격후 워크숍 기간을 갖고 생활
• 어떤 팀에 갈지 모른다

위에 코딩테스트가 어렵다는 특징이 있는데, 실제로 공채를 준비하는 대학생 분들 중에 해당 기업에서 나온 기출문제를 바탕으로 N년간 대비하는 분들도 보았다. 실제로 카카오 공채는 프로그래머스에서 진행을 하는데, 프로그래머스에서 공채 코딩테스트 문제 분석이라는 강의를 파는 모습도 본 것 같다 (18년도인가..)

또 이건 개인적으로 공채 공고를 보면서 느낀건데, 공채 공고에서는 기술 역량 자격이 적혀져있지 않다. 자바, 씨, 파이썬 언어 상관없이 본인이 해당 개발 분야에 대해 자신이 있고, 컴퓨터 공학적 능력이 뛰어나다면 신입개발자로 채용하겠다는 느낌이 들었다.

나는 공채는 지원하지 않았다. 개인적으로 코딩테스트에 자신이 없었다. 나름대로 코딩테스트 대비를 하긴 했지만, 많은 공채 지원자들 사이에서 최상위권이 될 수 있을까라는 의문이 있었기 때문이다. (그래도 리트코드 easy~medium 정도는 푼다) 그리고 공채에서는 많은 지원자들이 몰리는 만큼 내 이력을 꼼꼼히 봐주실까? 라는 의심도 있었다. 그리고 가장 중요했던 이유는 6월에 시작한 취준이었는데, 공채를 보려면 9월까지는 기다려야했고 그 사이에도 충분히 회사에 지원하고 합격할 수 있을 것이라고 생각했다.

그렇지만 바로 정규직이 될 수 있다는 안정감과 함께 입사하는 동기들이 있다는 점이 공채의 가장 큰 장점이자 내 입장에서 부러운 점이었다.

 

수시채용

내가 카카오에 지원한 방식이다. 수시 채용의 경우에는 모르는 대학생도 있을 것으로 보인다. 수시 채용은 각 회사의 채용사이트에 있는 개발자 공고에 맞춰서 지원하는 방식이다. 여기 보면 (경력) 이렇게 써져있다보니 나같은 신입은 지원하지 못하는 공고아니야? 라고 생각할 수 있는데, 채용사이트를 잘 뒤져보면 경력무관, 혹은 신입 개발자에 대한 수습기간 설명이 적혀있는 경우가 있다.

아무래도 경력 개발자를 위한 공고가 주 목적인 사이트는 맞지만, 팀이 제시한 요구 스펙을 맞춘 신입 개발자가 지원을 하는 경우도 고려한 공고가 가끔 있다. 따라서 수시 채용을 노린다면 본인이 원하는 회사의 채용사이트를 주기적으로 확인하자.

IT기업 개발자 수시 채용 특징을 신입 개발자 입장에서 짚어보자면

• 팀의 분위기를 고려한 채용
• 팀이 요구한 기술 스펙에 맞는 인재 선호
• 신입 지원시 회사에 따라 3개월의 수습 기간을 가질 수 있음
• 수습 기간이 있을 경우 평가에 따라 계속 일 할 수 있을지 없을지 여부가 정해짐 (3개월 계약직)
• 코딩 테스트는 팀바팀
• 면접에서 컴퓨터 공학 지식 내용 물어봄
• 면접에서 지원서에 쓴 내용을 바탕으로 본인 경험기반으로 깊게 물어봄
• 면접에서 1 : N (지원자 : 면접관)
• 채용일정 전반적으로 본인의 상황에 맞게 조정가능

수시 채용의 경우에는 지원자가 나 혼자이다보니, 내 지원서를 보고 좀 더 맞춰서 질문을 하는 경향이 있었다. 또한 공채 신입정도의 실력이 되는지를 판단하기 위한 지표로 컴퓨터 공학 지식도 하드하게 물어봤었다. 코딩테스트의 경우엔 내 기준 공채 기출보다는 좀 더 쉬운 편이었으나 이는 팀바팀일 것으로 예상된다. (그러나 대부분 공채 보다는 좀 낫다..) 

그리고 수시 채용의 경우에는 공채와는 다르게 채용일정을 내 일정에 맞춰서 조정이 가능했다. 공채에서는 전달해준 일자에 면접, 코딩테스트를 딱딱 봐야한다면 수시채용의 경우는 회사 인사팀에서 메일이 와서 선호하는 시간 및 날짜를 물어본다.

하지만 신입이 위처럼 수시 채용으로 입사하는 경우에는 3개월의 수습기간을 가지는 등의 패널티가 있을 수 있는데, 내가 그런 상황이었고, 이때의 불안정성이 조금 힘들었다. 공채보다 더 긴 채용 절차를 거쳤음에도 계약직이며 동기도 없고 3개월 후에 이 회사에 없을 수도 있다는 점은 심리적으로 조금 위축이 되긴한다. 

수시 채용의 경우 내가 원하는 핏을 가진 회사와 팀을 지원자 본인이 선택하고, 인터뷰를 보면서 나에게 집중된 채용절차를 밟을 수 있다는 점이 장점이다. 나는 이런 점이 마음에 들어서 수시 채용을 선택했다.

 

인턴 (상시 채용 / 수시 채용)

IT기업에서 인턴 채용도 하고있다. 그렇지만 인턴이 금턴이라는 말이 생길만큼 역시 쉽지 않다고 한다. 인턴의 경우에는 상시 채용, 수시 채용 형태 모두 보았는데, 인턴 채용의 경우에는 채용 규모나 절차 모두 회사 바이 회사였다. 

예를 들어 카카오 인턴은 위에 카카오 신입 개발자 공채과 비슷하게 이루어졌지만, 네이버 인턴 상시채용은 네이버 자회사인 NBP 인턴채용 이런식으로 좀 더 작은 규모에서 상시채용이 이루어졌다. 

나같은 경우엔 이번 6월 취준시 네이버 클라우드 상시채용 인턴에 지원했었고, 1월 인턴 지원시에는 수시채용 인턴에 지원했었는데, 아무래도 인턴이다보니 위에서 말한 공채와 수시 채용의 좀더 소프트 한 버전의 지원방식이라는 느낌을 받았다. (그래도 면접준비는 빡세게 해가자)

 

3. 지원서 작성하기

2번으로 원하는 팀 혹은 회사의 지원방식을 보고 선택을 했다면 서류평가를 위한 지원서를 작성해야 할 시간이다. 서류 평가에는 보통 기업에서 제시하는 지원서와 본인 개인 레주메를 낼 수 있도록 하고있는데, 나는 주로 레주메 안에 내 활동을 담으려했으며, 지원서에는 좀 더 레주메 안의 내용을 서술적으로 풀어서 제출했다. 지원서를 쓸 때 조언하고 싶은 점은 아래와 같다.

1. 개발자 레주메의 첫인상은 개발에 관심이 많은 사람임을 알 수 있어야한다.

개발자를 뽑으니까 특히나 신입개발자를 뽑으니까 내가 내는 서류에는 개발에 대한 열정이 가득한게 좋을 것 같다 생각했다. 그래서 내가 지원서를 작성할 때는 5가지를 어필하려 노력했다.

• 개발 서적 읽기 : 학교 지식을 넘어서 현업 개발자에 다가가기 위해 노력했다는 점 어필
• 해커톤 : (음...그냥 재미로 나간거였지만) 모르는 스택도 필요에 따라 따르게 익혀서 사용했다는 빠른 러닝커브 어필
• 프로젝트 / 대외활동 : 기술을 바탕으로 다른사람과 협업을 할 수 있다는 점 어필
• 컴퓨터 공학 지식 공부 (학점) : 개발자의 기본도 성실히 이수했다. 
• 나의 주언어 공부 (Java) : 내가 사용하는 언어를 언어의 특성에 맞게 사용이 가능하다.

이 5가지가 내 입장에서 개발자로 열정을 보여줄 수 있는 것들이었기 때문이다. 신입으로써 지원서에서 어필할 수 있는건 실제 실무보다는 본인이 개발 공부를 어떤식으로 해왔는지, 개발에 얼마나 관심이 많은지, 어떤 개발자로 성장하고 있는지 밖에 없기때문에 최대한 본인의 경험을 녹여서 일목요연하게 쓰자

실제로ㅋㅋㅋ 그래서 하이퍼 커넥트에 지원을 할 때는 신입임에도 경력직 공고에 패기롭게 넣었는데, 서류를 보시더니 졸업 예정자인지 확인하고 면접을 보게 해주셨다..ㅇ0ㅇ 그치만 코딩테스트에서 떨어졌다 (하이퍼 커넥트 코딩테스트는 되게 신기했는데, 알고리즘 테스트가 아닌 실무 코드에 대한 내용을 주로 물어봤다 그리고 영어였다)

2. 레주메는 최대한 그때그때 정리하자

대외활동이나 여러 동아리 활동을 하다보면 여러번 지원서를 쓰고 매번 이력이 업데이트된다. 그리고 각각 활동별로 깨우치는 바가 있을 것이다. 그때 깨달은 점을 꼭 정리하자. 

• 1학년 멋쟁이 사자처럼 : 웹에 대한 관심, mvc 구조로 웹 개발 가능해짐. / 프론트 백엔드 뭐든 서비스 완성 위주
• 2학년 SOPT : api 구조로 웹 개발가능해짐 / 스프링부트 학습 / 자바 숙달 / 백엔드 개발자에 관심
• 2학년 스마일게이트 : 서버 아키텍처에 대한 이해 / 스프링 숙달
• 3학년 자바봄 : 백엔드 개발자로써 공부해야 할 기본지식 / 클린코드 / 테스트코드 작성 / 스프링, 자바에 대한 더 깊은 이해 
• 3학년 dsc : 개발 커뮤니티 운영
• 4학년 인턴 및 취업준비

나같은 경우에는 대략적으로 위의 히스토리였는데, 사이사이에도 오픈핵, 네이버 핵데이 등 여러 활동 참여를 많이 했었다. 그런 활동을 하다보면 쓰는 지원서가 있는데, 그 지원서를 결국 쓰다보니 계속 조금만 고쳐서 조금만 업데이트해서 계속 사용하게 되었고 거슬러 올라가면 SOPT때의 지원서가 현재 사용한 자기소개서의 초안이 되었다. 따라서 본인의 방식으로 꼭꼭 잘 저장해두자.

3. 지원서를 쓸 때 받을 수 있는 면접 질문을 생각하고 지원서에 쓴 기술 스택은 제대로 공부하자

지원서에 작성한 기술 스택은 면접에서 물어볼 예상 질문이다. 따라서 본인이 지원서에 작성한 내용은 모두 깊게 공부해서가자. 본인이 자기소개서에 mySQL을 사용해본 경험이 있다고 적었다고 가정하자. 그러면 면접관은 mySQL의 특징부터해서, db 정규화, 트랜잭션, 인덱스, 고립레벨 등등 물어볼만한 질문이 너무 많기 때문이다. 그리고 실제로 면접이 아니더라도 본인이 공부한 기술 스택에 대한 깊이 있는 이해는 개발자라면 기본적으로 알아야하는 내용이다. 따라서 면접에서 나오는 해당 기술에 대한 질문은 정말 기초적으로 알아야하는 내용임을 암시하므로 내가 모르는 부분에 대한 질문이 나오면 땡큐라고 생각하고 바로 깊게 공부했다. (실제로 그 다음 면접에서 대답 못한 질문을 다시 대답해보라고 했었다.)

또한 면접에서 물어봤을 때 잘 대답을 못할 것 같거나, 정말 겉햝기 식으로 공부한 지식들의 경우에는 지원서에서 과감하게 뺐다. 나같은 경우에는 프론트엔드 외주 이력이 있지만, 면접에서 프론트엔드 관련해서 혹시라도 물어볼까 싶어 지원서에 해당 이력을 뺐다. 혹시라도 나한테 javascript 의 이벤트 핸들링에 대해서 설명해 보세요. 이런 질문을 하면 대답할 자신이 없었고, 그에 맞는 꼬리 질문도 대답 절대 못했다. 또한, 현재 지원서에 적은 기술 스택만 하더라도 면접 전까지 공부해야 할 내용이 산더미인데 프론트 엔드는 언제 공부하냐.. 싶었다.

4. 레주메는 읽기 쉽게 쓰자 + 앞장은 메인이다

지원서는 눈에 띄는 것도 중요하다. 해당 기업에 엄청 많은 지원자가 지원을 하는데 내용이 반복되고, 주술관계가 이상하며 읽는 사람이 이해할 수 없게 쓰면 얼마나 읽는사람이 힘들겠는가. 본인이 아무리 대단한 경험과 대단한 깨달음을 얻었다고 해도 지원서에는 최대한 요약하자 (어차피 면접에서 그 요약본을 보고 궁금해서 물어볼 것이다.) 

따라서 나는 보는 사람이 읽기 쉽게 직접 일러스트를 사용해서 그래프, 색깔처리, 볼드처리, 항목화 별짓거리를 다해서 가독성을 높이려고 했다. 그리고 주변 아는 개발자분들께 부탁을 드려서 리뷰를 받았었다.

jyami.tistory.com/8

 

Backend Developer Resume

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

jyami.tistory.com

또한 레주메의 경우에는 앞장이 메인이다. 대학생들의 경우 가끔 프로젝트 경험을 쓸 때 히스토리별로 (과거->현재)로 작성하곤한다. 하지만 앞장이 메인이다. 가장 기술적으로 현재와 가깝고 가장 성장해 있는 최근 경험을 앞장에 쓰자 (현재->과거). 또한, 자신있고 어필하고 싶은 기술 스택을 위주로 앞장에 보여주자. 

 

4. 코딩테스트

코딩테스트 준비

사실 코딩테스트 준비 어떻게 했냐는 질문도 정말 많이 받았던 것 같다.

나는 코딩테스트는 수능 입시 수학이랑 비슷하다는 생각을 종종한다. 우리가 수능 수학문제 어떻게 준비했는가, 먼저 개념 익히고, 그 개념에 따른 유형별 문제 풀어보고, 고난도 문제도 풀어보고 계속해서 반복학습을 한다. 1번부터 28번까지 문제는 유형을 알면 풀 수 있는 문제이기 때문에 그때그때 맞는 유형의 풀이를 기계적으로 하기 위해서 계속해서 반복하고 알던 내용도 계속해서 응용해서 풀어보는 노력을 한다. 그리고 29번 30번의 고난도 문제의 경우에는 앞에서의 유형별 반복학습과 개념의 이해가 먼저 되고나서 고난도 문제 기출을 풀어보곤 한다. 코딩테스트도 똑같다.

알고리즘에도 그리디, 수학, DP, 그래프, 자료구조 등 다양한 유형이 있고 기본적인 1번부터 28번까지의 문제를 풀기 위해 그 문제 유형을 반복적으로 학습하고 풀어본다. 그리고 기업 코딩테스트의 가장 어려운 문제는 29번 30번 처럼 계속해서 해당 기업 코딩테스트 기출의 동향을 보고 어려운 문제를 마주했을 때 어떤 방식으로 접근해야하는지 역시 반복적으로 학습한다. (이 29-30번을 못풀것 같아서 공채 코테가 자신이 없었다)

내가 알고있는 코딩테스트 준비 및 강의 사이트는 아래와 같다

• 백준 :www.acmicpc.net/
• 프로그래머스 : programmers.co.kr/
• leetcode : leetcode.com/
• codility : www.codility.com/
• 코드플러스 : code.plus/
• 인프런 : www.inflearn.com/

사실 결론은 간단하다 꾸준한 반복학습이다. 나같은 경우엔

1. 학교 알고리즘 수업으로 기본 개념을 익히고
2. 코드플러스의 백준 강의를 이용해서 유형별 풀이법을 정리하고
3. 리트코드, 프로그래머스, 백준 뭐든 이용해서 꾸준히 풀었다.

특히 당시에 리트코드를 애용했는데, 리트코드에서 하루에 한문제씩 알고리즘 문제를 푸는 챌린지가 있었어서 습관만들기 좋았다.

코딩테스트 전과 후

코딩테스트를 보기 전에는 꼭 해당 플랫폼의 사용법에 익숙해지자. 카카오는 프로그래머스, 네이버는 codiliity와 프로그래머스에서 봤던 기억이있는데, 어느 플랫폼이든 코딩테스트 전에 해당 플랫폼 테스트 링크를 주기 때문에 꼭꼭 익히자. 

백준에 익숙해져 있는 학생은 bufferedReader 부터 코딩을 시작할텐데, 프로그래머스에서는 IO 관련 코드를 짤 필요가 없기 때문에, 플랫폼 테스트 없이 그냥 바로 들어가서 시험을 본다면 백프로 당황할 것 같다.

코딩테스트를 볼때 나는 주로 아이패드를 이용해서 문제를 풀곤하는데 그 패드에는 항상 풀이 뿐만 아니라 문제에 대한 간단한 키워드도 함께 정리해두었다. 며칠이 지나고 복기를 위해서 혹은 해당 기업에 또 코딩테스트를 볼 일이 있을때 한번 더 풀어보고 혹이라도 같은 회사니까 비슷한 유형으로 나올까 싶어서 였다. 코딩 테스트 후에도 본인이 푼 문제를 복습하는건 중요하다.

 

5. 면접

면접 시작 전 후

요즘 코로나로 인해 2020년부터 기업에서 온라인 면접을 하고있다. 나도 그래서 실제로 대면으로 면접을 보기보다는 온라인으로 면접을 본게 훨씬 많았는데, 온라인 면접이 처음인 분들을 위한 팁을 아래 적는다.

• 흰 배경 : 이건 사바사지만 배경보단 나한테만 집중해줬으면 좋겠어서 흰 벽만 보이는 위치에서 면접을 봤다ㅋㅋ
• 얼굴이 잘 보이게 + 조명 확인 : 비대면이라 만나지 못해서 화면상으로라도 내 인상이 좋아보이게 하려고 했다.
• 통신 상태 확인
• 혹시 모르니 노트와 펜 준비하기

4번이 가장 중요하다. 면접을 보다보면 본인이 한 프로젝트의 서버 컴포넌트를 직접 그려서 설명해주세요. 혹은 이해가 안되는데 도식화해서 설명해주세요라는 요구를 받을 수 있다. 대면의 경우에는 회사측에서 준비할테지만 온라인 면접은 그러지 못하니 꼭 옆에 설명을 위한 종이와 펜을 준비하자. (요즘 채용 메일에 준비사항으로 대부분 공지하는 것으로 알고있다.)

나같은 경우엔 아이패드 + 맥북이라는 점을 이용해서 아이패드를 연결하고 화면공유를 한 뒤에 아이패드에 필기하면서 설명했다. (맥북의 사이드카 기능을 찾아보자)

또한 위에 코딩테스트와 마찬가지로 면접도 끝난 직후에 모든 질문내용을 복기해서 정리해두었다. 그리고 그 정리된 내용은 다음 면접을 준비할 때 혹은 다른 회사 면접을 준비할 때 사용했다.

 

면접 준비

면접은 사실 위에 지원서에 말한 내용과 같다. 최대한 관련 내용을 깊게 공부하는게 중요하다. 내가 한 면접 준비 방식은 아래와 같다.

1. 면접 예상 질문 리스트를 찾는다.

처음엔 막막해서 질문 리스트에 대한 구글링을 했다 키워드는 아래와 같다
[자바, 운영체제, 네트워크, 알고리즘, 데이터베이스, 디자인패턴] 면접 질문

요즘 github로 신입개발자 면접 질문 정리 이런식으로 정리해둔게 많아서 좋았다ㅋㅋ 그리고 추가로 내가 했던 프로젝트의 기술 스택 관련해서 면접 질문으로 나올 만한 것들을 선별했다 (docker, k8s, ELK 등)

위 사진은 실제 내가 적어두었던 면접 질문 리스트인데, 훨씬 더 많다. 관련 예상 질문을 받을때 기억해야하는 내용과 대답할 내용의 키워드를 적었다. 외에도 이전 면접을 보면서 받았던 질문들에 대한 리스트도 있었다.

 

2. 답변 키워드를 적어가면서 최대한 깊게 공부한다

답변 키워드를 적은 것은 위 사진에 예시를 적었다. 위 질문 키워드를 바탕으로 실제 면접에서 대답할 내용을 최대한 깊게 공부하자. 깊게 공부하지 않고 정말 간단한 내용만 공부하면 그만큼 말도 간단하게만 할 수 밖에 없다.

예를 들면 면접에서 Java HashMap이란? 이라는 면접 질문이 들어왔다고 하자. 그때 답변은 아래 3가지 컨셉을 바탕으로 내가 알고있는 것들을 최대한 깊게 대답 할 것이다 (그리고 이렇게 대답하기 위해 공부를 했다.)

Q. Java HashMap이 뭔지 설명해주세요

A. 키와 값으로 구성된 구조를 가지는 컬렉션 클래스로, 키에 따라서 값을 조회 삭제 수정 삽입이 가능합니다.

B. Map 인터페이스를 상속받은 구현체로 구현체의 특징이 hashing을 사용한다는 특징이 있습니다. 다른 Map 인터페이스의 구현체로는 treeMap이 있는데 이진 검색트리 형태로 데이터를 저장한다는 특징이 있습니다.

C. 해시테이블은 해싱을 사용한다고 했는데요. 해싱을 사용한다는 것은 객체가 가지고 있는 hashcode값에 따라서 key 테이블이 위치할 곳을 정한다는 것입니다. hashcode 계산으로 해당 데이터가 위치한 곳을 빠르게 찾을 수 있기 때문에 많은 양의 데이터를 검색할 때 유리합니다. 하지만 주의도 필요합니다. 이때 만약 다른 key값인데 hascode 값이 동일한 경우가 있을 수 있는데 이때는 해시 충돌이 일어날 수 있습니다. 이때는 hashcode를 담고있는 bucket이 연결리스트와 같은 구조로 다음 연결 리스트의 노드에 해당하는 key 값을 넣어주어 값을 저장합니다.

실제로 A만 말하더라도 B라는 꼬리 질문이 들어올 수 있고, B까지 말하더라도 C라는 꼬리질문이 들어올 수 있다. 꼬리질문은 그 지식에 대해 깊게 알고있는지를 판단하기 위해 들어오는 것이다. 꼬리질문을 예상해서 답변키워드를 적어가면서 깊게 공부했었다. 본인이 알고있는 지식이라고 생각해도 다시 한번 더 점검해보고 모르는 내용이 없는지 점검하고 더 공부하자.

그리고 다시한번 말하지만 면접에서 내가 모르는 내용을 질문하면 정말로 땡큐다. 모를때는 그냥 A, B까지는 아는데 질문 주신 부분은 잘 모르겠습니다. 공부해야 할 거리가 생겼네요 감사합니다. 하고 넘겼었다. 그렇게 대답하니 실제로 그 다음 면접에서 실제로 몰랐던 내용에 대한 재 답변을 요청했고, 그때는 완벽하게 대답해서 좋은 인상을 남겼다.

 

3. 말로 각 질문에 대한 답변을 소리내서 해본다

공부한 내용을 글로 정리하는 것과 말로 상대방에게 내가 알고있는 것을 전달하는 건 진짜 매우 다르다!!! 이거는 진짜 무조껀 해보고 가야한다. 같이 취업 준비를 하는 친구들과 모의면접을 하고 피드백을 받는 것도 좋다. 

나같은 경우엔 위에 예상 질문 중에 나온다면 이 예시를 들어서 설명해야지 까지 미리 말로 연습해서 갔었다. 예를 들면 템플릿 메서드 패턴의 예시를 들때는 Message라는 추상클래스를 두고 KakaoTalk, InstargramDM, FaceMessanger 클래스를 바탕으로 설명해야지. 동시성 관련한 질문이 들어오면 account 계좌 입출급을 동시에 했을 때에 대한 경우를 예를 들어야지.까지 설정한 후에 말로 해보면서 준비했다.

 

4. 면접에서 공부할 거리

지원서를 쓸 때 받을 수 있는 면접 질문을 생각하면서 썼었다. 따라서 지원서에 쓴 기술 스택을 2번에서 말한 것처럼 제대로 공부하자.

컴퓨터공학 기초적인 내용은 정말 기본이기 때문에 내 경력이 아무리 화려해도 면접에서 언제든 나올 수 있다. 꼭 대비하자. 구글링 해보면 면접에서 물어보는 대표적인 질문들이 몇가지가 있다. 적어도 그정도라도 공부하자 :)

주언어(Java)와 관련한 내용 공부를 해도해도 끝이 없다. 자바 기준으로 컴파일타임 런타임타임에 대한 질문, 내부 JVM 구조, GC, 메모리 저장, 람다, 함수형 프로그래밍, 스트림 등등 언어안에도 너무 많은 내용이 있다. 성능뿐만 아니라, JVM같은 경우엔 운영체제와도 연관되는 내용이며 자바 thread 역시 현업에서의 동시성 프로그래밍을 위한 기초이다. 언어를 공부하다 보면 컴퓨터 공학 지식과 연관되는 부분도 많이 나와서 나는 자바 공부를 진짜 열심히 했었다. (재밌기도했다..) 그러다보니 자바 관련 질문에서는 대부분 답변을 할 수 있었다.

 

6.  결론

나는 결국 위 과정을 통해 약 한 달 간의 취업준비를 했었고 최종적으로 카카오에 가게 되었다. 

• 네이버 클라우드 채용형 인턴 : 서류 합 > 코테 합 > 1차 면접 합 > 최종 합격 > 거절
• SAP 인턴 : 서류 합 > 1차 면접 합 > 최종 합격 > 거절
• 하이퍼커넥트 경력직 > 서류 합  > 코테 불합
• 카카오 수시채용 : 서류 합 > 코테 합 > 전화 면접 합 > 1차 면접 합 > 2차 면접 합 > 최종 합격 > 취뽀

내가 서류를 넣은 4곳 중 가장 가고싶었던 곳은 카카오였다.  하지만 최종 합격 발표가 난 나머지 두곳이 시기는 더 빨랐었다. 수시 채용이나 인턴을 이용해서 취업을 준비하다보니 그사이 지원 간격이나 계약서 사인을 조금만 기다려달라는 메일도 보내 조정을 해보려했으나, 두곳의 합격 발표가 난 시점이 각각 카카오 전화 면접 합, 2차 면접 결과를 기다리던 시점이었다. 채용 일정 차이로 다른 곳을 포기하거나 카카오 결과를 기다리거나 택일의 상황이었다. 하지만 가장 가고싶었던 곳이 여기었기에, 두 곳 모두 계약서 작성을 거절하고 위와 같은 방식으로 카카오 면접에만 집중했었고 그 결과 카카오 검증형 계약직으로 입사하게 되었다.

그리고 3개월의 계약직 기간을 거쳐, 내부 과제를 마치고 전환 평가에 합격했다.

사실 내 취준 방법이 정답은 아니다. 나처럼 수시채용을 노리는 것보다 공채를 노리는게 훨씬 마음이 편할 수 있다. 또한 각자의 스펙과 전략이 있을거고 나와는 다를 수 있다. 하지만 내가 취준을 하면서 공부한 방식이나 얻었던 정보들이 누군가에게 도움이 될 수 있지 않을까 해서 취준기를 계속 써야지 써야지 하고 계속 미뤘는데, 드디어 글을 마치게 되었다 :) 모두 본인의 강점을 내세울수 있는 취준을 하고 취뽀를 할 수 있기를🙏

Oh man... I can't believe I'm only writing this now.. I kept going back and forth and finally decided to finish this post. (Still, I went to Kakao, but my Naver review is the most viewed post on my blog?? LOL)
 After failing the Naver full-time conversion interview in mid-June, I started my job search.

jyami.tistory.com/116

 

Naver Backend Internship Review

I'm going to write about my Naver internship experience from March to June, about 3 months. I kept putting it off saying I'd write it eventually, and it's been almost 2 months since the internship ended, so quite a bit of time has passed, but anyway

jyami.tistory.com

When I was preparing for the Naver internship, I got in without any algorithm prep or interview preparation at all. Since my very first company interview was that Naver internship interview, I was running on pure hopium thinking if I got into Naver, I could land a job without any real job hunting LOL. But reality hit hard — I unfortunately didn't get converted to full-time ㅠ and I was like "wait, am I actually job hunting now..?" and that's how my job search began LOL

Looking at just the conclusion, I don't think I spent that long stressing about job hunting, but I want to write about my relatively short 1-month job search journey.

 

1. Companies I Wanted to Join

Setting Your Target Companies

I believe the most important thing for any college student starting their job search is to set criteria for the companies they want to join. There are so many different types of companies — public enterprises, startups, large corporations, IT companies, foreign companies, etc. — and each one has different standards for hiring new employees. Also, starting from the ideal candidate profile that your desired company is looking for, to the basic qualifications needed (language certifications, professional certifications, etc.), the hiring process is different for every company, so you need to prepare in advance. 

For example, if I wanted to join Samsung, I would first practice the past coding test problems from Samsung, study for the aptitude test included in their hiring process, and if I made it to interviews, I'd prepare according to the interview order and characteristics of each interview round. These hiring processes are usually described in detail on each company's recruitment guide and process pages. (Make Googling a habit) By looking at these hiring processes, you can objectively assess your current qualifications and prepare for any gaps.

Once you've decided on the company you want to join, you'll be going through a long hiring process and preparing accordingly. After going through all that grueling process, it should be a company you truly want to join — that way, when the acceptance announcement comes, the joy will be that much greater. So I believe it's important for everyone to first choose the company they truly want to work at and focus their preparation on that choice.

I want to work at an IT company..

So I had the keyword "a place where I can grow as a developer" in mind, and I was thinking about IT companies or foreign IT companies. At the time, I submitted applications to these four places: Kakao, Hyperconnect, Naver, and SAP. (There were other IT companies I was interested in, but these four had the job postings that caught my attention at the time)

The ideal candidate profiles required by these four companies, which all shared the common trait of being IT companies, were actually pretty similar. The core keyword was "a developer who loves and excels at development." Looking more closely, things like understanding Java well, having solid computer science knowledge, etc. — the desired technical competencies were detailed in the job descriptions.

From the company's perspective of hiring developers, it felt like they were asking: You'll need to study a lot more going forward, and you need to have read development books, have collaborative development experience, deep understanding of your major's knowledge, and understanding of your primary programming language to work with us — are you ready? That's right. They were asking whether you, as an undergrad with some interest in development, had put in effort and study to improve your development skills, and whether that studying was done properly.

And I felt that my current state could sufficiently demonstrate the required competencies through the studies, projects, and technical interests I'd pursued during my undergraduate years.  Even if there were parts of the job description that didn't match me, I planned to emphasize that I had studied my current tech stack in sufficient depth.

Here's a tip — if you don't know what to study next, look at the qualification requirements of the companies you want to join. In my case, I didn't have Kotlin server development experience, but if I had seen this posting in my third year, I would have found a new thing to study: Kotlin. And even if you already know the content, you should absolutely study it as deeply as you possibly can. For example, if it says "Java-based server development experience," as you can see from some of my blog posts, beyond the Java classes at school, I read books like Effective Java, and when there were concepts I didn't understand like generics, I dug deeper and kept growing. 

 

2. How IT Companies Recruit

The companies I wanted to join were mainly IT companies, and among them, I especially wanted to go to Kakao and Naver. So I looked into and explored many ways to enter these companies as a new hire. From what I could see, these two companies had roughly 3 types of application methods.

• Open Recruitment (Regular Hiring)
• Rolling Recruitment
• Internship (Regular Hiring / Rolling Recruitment)

Open Recruitment

I think most of you are already familiar with open recruitment. Open recruitment is usually divided into first-half and second-half cycles, where they hire a large number of new developers at once. Since open recruitment is a method used by many companies beyond just Kakao and Naver, I think most people already know about it.

However, considering these are IT companies, here are some characteristics of open recruitment:

• A really large number of applicants
• The coding test is difficult
• Interviews mainly focus on basic computer science knowledge questions
• Interviews can be N:N (applicants : interviewers)
• You join directly as a full-time employee
• You have to adjust your job search schedule to match the company's application period
• If you get in, you'll have peers who joined at the same time
• After passing, there's a workshop period before you start
• You don't know which team you'll be assigned to

I mentioned above that the coding test is difficult — among college students preparing for open recruitment, I've seen people who practice past exam problems from these companies for years. In fact, Kakao's open recruitment coding test is conducted on Programmers, and I think I even saw Programmers selling a lecture course analyzing the open recruitment coding test problems (was it 2018?)

Also, this is something I personally noticed while looking at open recruitment postings — they don't list specific technical skill requirements. I got the feeling that regardless of whether you use Java, C, or Python, if you're confident in your development area and have strong computer science abilities, they'll hire you as a new developer.

I didn't apply through open recruitment. Personally, I wasn't confident in coding tests. I did prepare for coding tests in my own way, but I had doubts about whether I could be at the top tier among all those open recruitment applicants. (Though I can solve LeetCode easy~medium problems) I also had doubts about whether they would carefully review my resume among so many applicants. And the most important reason was that I started my job search in June, but I would have had to wait until September for open recruitment, and I thought I could apply to and get accepted at companies in the meantime.

However, the stability of becoming a full-time employee right away and having peers who join together were the biggest advantages of open recruitment and something I was envious of.

 

Rolling Recruitment

This is how I applied to Kakao. Some college students might not know about rolling recruitment. Rolling recruitment means applying to developer positions posted on each company's career site. You might see "(Experienced)" written on these postings and think "I'm a new grad, so I can't apply to this, right?" But if you dig through the career site carefully, you'll sometimes find postings that say "experience level doesn't matter" or include explanations about probation periods for new developers.

It's true that these sites are primarily intended for experienced developer postings, but there are occasional postings that also consider new developers who meet the tech specs required by the team. So if you're targeting rolling recruitment, check your desired company's career site regularly.

Here are some characteristics of IT company rolling recruitment from a new developer's perspective:

• Hiring considers team culture fit
• Preference for candidates matching the team's required tech specs
• New hires may have a 3-month probation period depending on the company
• If there's a probation period, your continued employment is determined by evaluation (3-month contract)
• Coding tests vary by team
• They ask computer science knowledge questions in interviews
• They dig deep into your experience based on what you wrote in your application
• Interviews are 1:N (applicant : interviewers)
• The overall hiring schedule can be adjusted to fit your situation

With rolling recruitment, since I was the only applicant, they tended to tailor their questions to my application. They also asked tough computer science questions to gauge whether I was at the level of an open recruitment new hire. The coding test was, in my experience, a bit easier than open recruitment past exams, but this probably varies by team. (But most are a bit easier than open recruitment..) 

Also, unlike open recruitment, rolling recruitment allowed me to adjust the hiring schedule to fit my own schedule. While open recruitment requires you to take interviews and coding tests on fixed dates, with rolling recruitment, the HR team sends you an email asking about your preferred time and date.

However, when a new hire enters through rolling recruitment like this, there can be penalties like a 3-month probation period. That was my situation, and the uncertainty was a bit tough. Even though I went through a longer hiring process than open recruitment, being on a contract with no peers and the possibility of not being at the company after 3 months was a bit psychologically daunting. 

The advantage of rolling recruitment is that you can choose a company and team that fits what you want, and go through a hiring process that's focused on you. I liked this aspect, which is why I chose rolling recruitment.

 

Internship (Regular Hiring / Rolling Recruitment)

IT companies also hire interns. But there's a saying that "internships are golden tickets" because they're just as hard to get. For internships, I've seen both regular hiring and rolling recruitment formats, and the hiring scale and process really varied company by company. 

For example, Kakao internships were conducted similarly to the Kakao new developer open recruitment mentioned above, but Naver intern regular hiring was done on a smaller scale through NBP (Naver's subsidiary) intern recruitment. 

In my case, I applied for the Naver Cloud regular hiring internship during my June job search, and when I applied for an internship in January, it was through rolling recruitment. Since it's an internship, I felt it was a softer version of the open recruitment and rolling recruitment methods mentioned above. (But still, prepare hard for the interviews)

 

3. Writing Your Application

If you've looked at the application method for your desired team or company in section 2 and made your choice, it's time to write your application for the document screening. Document screening usually allows you to submit the company's standard application form along with your personal resume. I mainly tried to pack my activities into my resume, and in the application form, I expanded on the resume content in a more narrative style. Here are some tips I'd like to share for writing applications:

1. A developer resume's first impression should show you're passionate about development.

Since they're hiring developers — especially new developers — I thought my documents should be brimming with passion for development. So when writing my application, I tried to highlight these 5 things:

• Reading development books: Showing I made efforts to go beyond school knowledge and get closer to being a real-world developer
• Hackathons: (Well... I just did them for fun, but) Demonstrating a fast learning curve by quickly picking up unfamiliar stacks when needed
• Projects / Extracurricular activities: Showing I can collaborate with others using technology
• Computer science knowledge (GPA): Showing I diligently completed the developer fundamentals 
• Studying my primary language (Java): Showing I can use my language according to its characteristics

These 5 things were what I could use to demonstrate my passion as a developer. As a new grad, what you can highlight in your application isn't real work experience, but rather how you've been studying development, how interested you are in development, and what kind of developer you're growing into — so weave in your experiences and write them in a clear, organized manner.

Actually LOL, so when I applied to Hyperconnect, I boldly submitted my application to an experienced-hire posting despite being a new grad, and after reviewing my documents, they confirmed I was about to graduate and let me interview..ㅇ0ㅇ But I failed the coding test (Hyperconnect's coding test was really interesting — instead of algorithm tests, they mainly asked about real-world code and it was in English)

2. Keep your resume updated as you go

As you participate in various extracurricular activities and clubs, you end up writing multiple applications and your history keeps getting updated. And you'll have takeaways from each activity. Make sure to document those takeaways when they're fresh. 

• 1st year - LIKELION: Interest in web, became able to do web development with MVC structure / Focus on completing services regardless of front or back end
• 2nd year - SOPT: Became able to do web development with API structure / Learned Spring Boot / Became proficient in Java / Interested in backend development
• 2nd year - Smilegate: Understanding of server architecture / Became proficient in Spring
• 3rd year - JavaBom: Fundamental knowledge needed as a backend developer / Clean code / Writing test code / Deeper understanding of Spring and Java 
• 3rd year - DSC: Running a developer community
• 4th year - Internship and job search preparation

In my case, the rough history was as above, and in between, I also participated in many activities like Open Hack, Naver Hack Day, etc. Through those activities, I wrote applications, and as I kept writing them, I'd just tweak them a little and keep reusing them. Going all the way back, the application I wrote for SOPT became the first draft of the self-introduction letter I used later. So make sure to save everything well in your own way.

3. When writing your application, think about potential interview questions, and thoroughly study the tech stacks you mention

The tech stacks you write in your application are basically expected interview questions. So study everything you put in your application deeply. Let's say you wrote in your self-introduction that you have experience using MySQL. Then the interviewer could ask so many questions — from MySQL characteristics to DB normalization, transactions, indexing, isolation levels, and more. And even outside of interviews, having a deep understanding of the tech stacks you've studied is fundamental knowledge every developer should have. So questions about those technologies in interviews are really hinting at things you should basically know. Whenever I got a question about something I didn't know, I thought "thank you" and immediately studied it in depth. (In fact, in the next interview, they asked me to re-answer questions I couldn't answer before.)

Also, if I felt I couldn't answer well in an interview, or if I had only surface-level knowledge about something, I boldly removed it from my application. In my case, I had freelance frontend work experience, but I removed that from my application because I was worried they might ask about frontend stuff. If they asked me to explain JavaScript event handling, I wouldn't have been confident answering that, and I definitely couldn't have handled follow-up questions either. Plus, even with just the tech stacks already in my application, I had mountains of content to study before the interview — when would I study frontend too?

4. Make your resume easy to read + The first page is the main page

Standing out in your application matters too. With so many applicants applying to these companies, if the content is repetitive, the subject-predicate relationships are off, and it's written in a way the reader can't understand — imagine how exhausting that would be to read. No matter how impressive your experiences and insights are, summarize them as much as possible in your application (the interviewers will see that summary and ask about what intrigues them anyway.) 

So I personally used illustration tools to add graphs, color coding, bolding, bullet points — I did everything I could to improve readability. I also asked developer friends I knew to review it.

jyami.tistory.com/8

 

Backend Developer Resume

Developer portfolio, backend developer resume (update 2020.06.12)

jyami.tistory.com

Also, with resumes, the first page is the main page. College students sometimes write their project experiences in chronological order (past→present). But the first page is the main page. Put your most recent experience — the one closest to the present and showing the most growth — on the first page (present→past). Also, showcase the tech stacks you're most confident in and want to highlight on the front page. 

 

4. Coding Tests

Preparing for Coding Tests

I think I got asked a lot about how I prepared for coding tests.

I often think coding tests are similar to the math section of the Korean college entrance exam (수능). How did we prepare for the math section? First learn the concepts, then practice problems by type, try difficult problems too, and keep doing repetitive learning. Problems 1 through 28 can be solved if you know the patterns, so you keep repeating and applying what you know to mechanically solve each pattern type. And for the hard problems like 29 and 30, you first need the pattern-based repetitive learning and conceptual understanding, then practice with past difficult problems. Coding tests are exactly the same.

Algorithms also have various types like greedy, math, DP, graphs, data structures, etc., and you repeatedly study and practice those problem types to solve the basic problems 1 through 28. And for the hardest problems on company coding tests, like problems 29 and 30, you keep studying trends from that company's past coding tests and repeatedly learn how to approach difficult problems. (I wasn't confident in open recruitment coding tests because I couldn't solve these 29-30 level problems)

Here are the coding test preparation and lecture sites I know of:

• Baekjoon:www.acmicpc.net/
• Programmers: programmers.co.kr/
• LeetCode: leetcode.com/
• Codility: www.codility.com/
• Code Plus: code.plus/
• Inflearn: www.inflearn.com/

The conclusion is actually simple: consistent, repetitive practice. In my case:

1. I learned the basic concepts through my school's algorithm class
2. I organized problem-solving methods by type using Code Plus's Baekjoon lectures
3. I consistently solved problems on LeetCode, Programmers, Baekjoon — whatever was available.

I especially loved LeetCode at the time because they had a daily algorithm problem challenge, which was great for building habits.

Before and After the Coding Test

Before taking the coding test, make sure you're familiar with the platform. Kakao uses Programmers, and I remember Naver using Codility and Programmers. Whatever the platform, they give you a test link beforehand, so definitely practice with it. 

Students who are used to Baekjoon will start coding from bufferedReader, but on Programmers you don't need to write IO-related code. So if you just go in and take the test without trying the platform first, you'll 100% be thrown off.

When taking coding tests, I usually used my iPad to work through problems, and on that iPad I always noted not just the solutions but also brief keywords about each problem. This was for reviewing days later, or in case I had another coding test at the same company, so I could try solving them again and see if similar types might come up since it's the same company. Reviewing the problems you solved after the coding test is important.

 

5. Interviews

Before and After the Interview

Due to COVID, companies have been conducting online interviews since 2020. I also ended up doing way more online interviews than in-person ones. Here are some tips for those doing online interviews for the first time:

• White background: This varies by person, but I wanted them to focus only on me rather than the background, so I positioned myself in front of a white wall for interviews LOL
• Make sure your face is clearly visible + check the lighting: Since we can't meet in person, I tried to make a good impression through the screen.
• Check your internet connection
• Have a notebook and pen ready just in case

Number 4 is the most important. During an interview, you might be asked to draw and explain the server components of a project you worked on, or to diagram something for better understanding. For in-person interviews, the company would prepare materials, but for online interviews they can't, so definitely have paper and a pen ready for explanations. (These days, I believe most companies include this in the preparation instructions in their hiring email.)

In my case, I took advantage of having an iPad + MacBook by connecting the iPad, sharing the screen, and writing on the iPad while explaining. (Look up the Mac Sidecar feature)

Also, just like with the coding test above, right after each interview ended, I reviewed and documented all the questions. I then used those notes to prepare for the next interview or interviews at other companies.

 

Interview Preparation

Interview preparation is honestly the same as what I said about the application above. The key is to study related content as deeply as possible. Here's how I prepared for interviews:

1. Find lists of expected interview questions.

I was overwhelmed at first, so I Googled question lists. The keywords were:
[Java, Operating Systems, Networking, Algorithms, Databases, Design Patterns] interview questions

These days there are lots of well-organized resources on GitHub like "new developer interview question compilations," which was great LOL. Additionally, I selected potential interview questions related to the tech stacks from my projects (Docker, K8s, ELK, etc.)

The photo above shows the actual interview question list I wrote down, and there's much more. I wrote down keywords for what to remember and how to answer each expected question. There was also a list of questions I'd received from previous interviews.

 

2. Write down answer keywords and study as deeply as possible

I showed an example of writing down answer keywords in the photo above. Based on those question keywords, study as deeply as possible for the actual interview answers. If you only study simple content without going deep, you'll only be able to give simple answers.

For example, let's say the interview question "What is Java HashMap?" comes up. I would answer as deeply as possible based on these 3 concepts (and I studied specifically to be able to answer this way):

Q. Please explain what Java HashMap is.

A. It's a collection class with a key-value structure that allows you to look up, delete, modify, and insert values by key.

B. It's an implementation of the Map interface, and the key characteristic of this implementation is that it uses hashing. Another implementation of the Map interface is TreeMap, which stores data in a binary search tree format.

C. I mentioned that hash tables use hashing. Using hashing means that the location where a key will be placed in the table is determined by the object's hashcode value. Since you can quickly find where data is located through hashcode calculation, it's advantageous when searching through large amounts of data. But caution is needed. If different keys happen to have the same hashcode, a hash collision can occur. In that case, the bucket containing the hashcode uses a structure like a linked list, placing the key value in the next node of the linked list to store the value.

In reality, even if you only say A, a follow-up question B could come. And even if you say up to B, a follow-up question C could come. Follow-up questions are asked to determine if you have deep knowledge of the subject. I studied deeply by anticipating follow-up questions and writing down answer keywords. Even if you think you already know something, double-check it, look for gaps in your knowledge, and study more.

And once again — if they ask me something I don't know in an interview, I'm genuinely thankful. When I didn't know, I'd say "I know up to A and B, but I'm not sure about what you're asking. Looks like I've found something new to study — thank you." and move on. When I answered that way, in the next interview they actually asked me to re-answer something I didn't know before, and that time I answered perfectly and left a good impression.

 

3. Practice answering each question out loud

Organizing what you've studied in writing versus verbally conveying what you know to someone else are truly VERY different!!! You absolutely must try this before going in. It's also great to do mock interviews with friends who are also job hunting and get feedback. 

In my case, for the expected questions above, I even practiced to the point of deciding which examples to use. For example, when explaining the Template Method pattern, I'd use an abstract class called Message with KakaoTalk, InstagramDM, and FaceMessenger classes. When a concurrency question came up, I'd use the example of depositing and withdrawing from an account simultaneously. I prepared by setting up these scenarios and practicing out loud.

 

4. What to study for interviews

When writing the application, I thought about potential interview questions. So study the tech stacks in your application thoroughly, as mentioned in point 2.

Basic computer science knowledge is truly fundamental, so no matter how impressive your background is, it can come up anytime in an interview. Definitely prepare for it. If you Google it, there are several representative questions that commonly appear in interviews. Study at least those :)

Studying content related to your primary language (Java) never ends. For Java alone, there are questions about compile time vs runtime, internal JVM structure, GC, memory storage, lambdas, functional programming, streams, and so much more. Beyond just performance, the JVM is also related to operating systems, and Java threads are the foundation for concurrency programming in the real world. As I studied the language, a lot of it connected to computer science knowledge, so I really studied Java hard. (It was fun too..) As a result, I was able to answer most Java-related questions.

 

6.  Conclusion

In the end, I went through the process described above over about a month of job hunting, and ultimately ended up joining Kakao. 

• Naver Cloud Recruitment Intern: Resume passed > Coding test passed > 1st interview passed > Final offer > Declined
• SAP Intern: Resume passed > 1st interview passed > Final offer > Declined
• Hyperconnect Experienced Hire > Resume passed  > Coding test failed
• Kakao Rolling Recruitment: Resume passed > Coding test passed > Phone interview passed > 1st interview passed > 2nd interview passed > Final offer > Got the job!

Out of the 4 places I applied to, Kakao was where I wanted to go the most.  However, the other two places that gave me final offers did so earlier in the timeline. Since I was preparing through rolling recruitment and internships, I tried to adjust the timing by sending emails asking them to wait a bit before signing the contract, but the two offers came in while I was waiting for Kakao's phone interview results and 2nd interview results, respectively. Due to the difference in hiring schedules, I was in a situation where I had to choose between giving up the other places or waiting for Kakao's results. But since Kakao was where I wanted to go the most, I declined to sign the contracts at both places and focused solely on the Kakao interviews using the methods described above — and as a result, I joined Kakao as a probationary contract employee.

After a 3-month contract period, I completed the internal assignment and passed the conversion evaluation.

Honestly, my job hunting approach isn't the definitive answer. Unlike me who targeted rolling recruitment, aiming for regular mass recruitment cycles might be much less stressful. Everyone has their own qualifications and strategies, and they might be different from mine. But I thought the study methods and information I gathered during my job search might help someone out there, and I kept putting off writing this job hunting story, saying "I should write it, I should write it" — but I've finally finished it :) I hope everyone can leverage their own strengths in their job search and land their dream job 🙏

작년에도 회고록을 31일에 맞춰 썼는데, 올해도 결국에는 31일에 쓰는구나...ㅋㅋㅋ 아니 사실 이거 쓰기 전에 취업 관련 글 하나 쓰려했는데 시간 관계상 그건 신년에 쓰는 걸로 하자 크크... 와 그나저나 21년에는 24살이구나 시간 빨라...

올해 코로나 때문에 취업이 어려워졌단 소리가 엄청 많아졌는데, 덕분에 나도 올해에 취업으로 희로애락을 다 경험한 것 같다..ㅋㅋㅋ 올해 회고는 거의 취준생 일기일 것 같지만 그래도 시작해보자 후후 (쓰는 게 어디야 쓰는 게..)

와.. 지금 보니 이때 열정 가득했었구나.. 새삼 회고록 쓰면 약간 1년 일기장 같긴 한데 새록새록하다

---

[1월 - 2월] 인턴십 지원과 여러 활동들

인턴십 지원과 합격

의도한 건 아니지만 나름 내 대학교 로드맵에는 순서가 있었는데ㅋㅋ 1학년 : 교내 개발 동아리 / 2학년 : 교외 개발 동아리 / 3학년 : 회사 연계 개발 관련 대외활동 / 4학년 : 회사 인턴십 및 구직 이렇게 대학교 생활이 지나갔다.

따라서 인턴십 준비는 19년도 12월부터 했었고, 어쩌다 보니 교수님 추천, 지인 추천, 직접 지원 등 여러 경로로 인턴십을 지원을 했었던 기억이 난다. 이에 따라 대부분 1~2월에 서류 및 코딩 테스트 결과가 났었다.

20년도 1~2월 당시에는 정말 취업 연계형 생각 없이 체험형 인턴으로 스펙을 쌓기 위해 도전을 했었기 때문에 코딩 테스트나 면접 준비나 전부 전무했다. 그렇지만 감사하게도 면접에서도 나를 좋게 봐주셔서 (와 이때 생각해보니 면접 준비 하나도 안 하고 전날에 벼락치기해서 인턴 첫 면접을 갔었네.. 패기..) 20년도 상반기 네이버에서 인턴을 할 수 있게 되었다

그래서 사실 입사 전이니까 2월은 잘 쉬고 놀고 그랬어야 했지만.. 역시나 추진력 하나는 최고인 재미는 실수를 하고 마는데...

 

백엔드 외주

그렇다... 2월 말까지 마감인 외주를 하고 있었다..ㅋㅋㅋ 같이 오픈 핵 + 중국 해커톤을 갔었던 오빠가 자바 라이브러리를 API로 만드는 작업을 부탁해서 했던 외주였다. 이때 GCS연동 + 외부 라이브러리 연동이 주 과제였는데, 와.. 이때 테스트 코드의 중요성을 확 느꼈었다.

사실 스프링으로 그냥 간단하게 controller만 만들고 service단에 자바 라이브러리를 넣으면 되겠지 하고 객체 관계나 클린 코드 신경 쓰지 않고 내 마음대로 그냥 스파게티 코드를 막 짰었다.. 그런데 그러다 보니 내가 모르는 에러가 막 발생했다. 결국 정신 차리고 테스트 코드를 짠 후 코드를 하나하나 리팩터링 하면서 객체가 하나의 역할을 가지게 내부적으로 수정했었다. 이때 유지보수나 객체지향을 무시하고 짠 코드의 위험성을 체감했었다.

그래서.. 사실 인턴십 면접 보기 직전에도 이 외주 작업 코드 수정하고, 면접을 보고 입사 직전까지도 이 외주 작업을 계속하느라 정신이 없었던 기억이 난다. 지금은 내가 만든 서버를 사용하지 않는 걸로 알고 있는데, 회고 쓰면서 찾아보니 검색도 되고.. 오올 학생 스타트업으로 열일 하는 것 같다.

 

네이버 AI 버닝 데이

그리고.. 맞다.. 네이버 AI 버닝 데이에 갔었다.. 진짜 3학년 때 중국톤 이후로 해커톤 다시는 안 해!! 이랬는데. 는 무슨 연례행사로 하나보다. (그리고 버닝 데이 끝날 때도 해커톤 안 해 -ㅅ- 이랬지만..ㅋ) 

사실 AI가 주인 대회라서 내가 할 일이 별로 없을 줄 알았는데 아아... 매번 해커톤을 가면 할 때마다 하나씩 헤매는 부분이 생긴다. 기억하기론 우리 팀 AI 엔지니어 언니가 작성한 python 코드를 스프링에서 돌릴 때 디버깅이 힘들었던 문제였던 것 같은데 기억이 잘 안 난다.

그리고 이때 Naver Cloud Platform 크레딧을 제공해줘서 이 플랫폼에 익숙해지느라 애먹기도 했다 (이때의 경험 덕에 요즘 NCP로 돌리는 서버가 한대 있긴 하다)

진짜 해커톤이 너무 신기한 게 어떻게든 완성을 하긴 한다..(그리고 생산성이 중요한 해커톤에서 다시는 스프링 안 쓴다고 했지만... 결국은 항상 스프링 쓴다) 사실 이 대회는 네이버 실무진과의 이야기를 통해 사람에 따라 취업 기회도 주는 성격이 있었는데, 이미 인턴십 합격이 된 상황이라서 그냥 기념품을 잘 받아왔다 >< (이때 받은 맨투맨 일코 하기가 좋아서 너무 잘 입고 다닌다)

그리고 이때 레크리에이션 때 어쩌다 보니 경품으로 에어 팟을 받게 되었는데 크으... 이미 하나 쓰고 있는 게 있기에 당근 마켓 했다ㅋ

 

구글 HashCode 참가

jyami.tistory.com/52?category=854536

 

HashCode 2020 참가 후기

처음으로 PS 대회에 참가해봤다. DSC Korea 슬랙에서 팀원을 구한다는 얘기를 듣고 참가를 하게 됐는데! 하하 UTC 17:30이라니,, 한국시간으로 오전 2:30부터 6:30까지 였다. 그래서 팀원들끼리 코딩할

jyami.tistory.com

막 그렇게 엄청 심혈을 기울인 행사는 아니었지만, 새삼 1~2월 사이에 많이도 했다는 생각이 든다..ㅎㅎ 이때 나 정말 알고리즘 못하는구나...라고 생각했었고 버스 탔었는데 (아련..) 지금도 알고리즘은 자신이 없다ㅠㅠ

 

이화 동산 커미터스

이전 DSC Ewha Lead 회고에도 썼지만, 이때 당시 DSC 몇 명의 멤버들과 일일 커밋 그룹을 만들었었다. 이때 커밋 기록 관리 툴로 슬랙과 웹을 사용했었는데, 웹 같은 경우 기존에 비슷한 활동을 하시던 그룹의 코드를 포크 해와서 우리 그룹에 맞게 커스터마이징 하는 작업을 했다.  (관련 글 : jyami.tistory.com/123?category=865823)

 

2019-2020 DSC Ewha Lead를 마치고

2019년 8월부터 2020년 8월까지 1년간의 DSC 활동이 끝났다. 사실 진작 활동을 정리해서 써야지 했는데, 미루다 보니 어느새 10월이다ㅋㅋㅋ이전에 회고록에서 DSC 활동에 대해 쓰긴 했었는데, 아무래

jyami.tistory.com

기존 코드가 장고로 되어있었고, 도커로 말려있었는데 이때 환경 세팅하는 부분에서 엄청 애먹었었다. 장고도 익숙하지 않았고 도커도 익숙하지 않아서였는데, 흠 뭔가.. 근데 요즘 느끼는 건 가면 갈수록 프레임워크든 뭘 사용하는지는 점점 상관이 없어지는 것 같다. 점점 구글링에 능숙해져서 그런가ㅋㅋㅋ 모르면 그냥 찾아서 배포하고 만들고 삽질을 하면 된다는 마인드가 생겼달까

 

[ 3월 - 6월 ]  코로나 그리고 4학년 1학기와 첫 인턴십

코로나 붐

2020년 3월 급격하게 코로나 확진자가 늘어났다. 확진자가 늘어나면서 여러 활동들을 중단하게 되었는데 대표적으로는 학교도 모두 온라인으로(DSC 활동을 거의 못하게 되었다..), 회사도 재택근무를 했다. 학교는 대면 수업으로 해도 회사와 병행이 가능하게 조절을 잘해두고, 입사를 기다렸는데 입사일도 미뤄지고 입사도 집에서 했다. (그리고 쟈미가 입사할 무렵 코로나가 심해지고 재택근무로 돌아가는 현상은 이후에도 반복되는데...)

그리고 무엇보다. 인턴십을 기대하고 새로운 집도 구해놨는데 재택근무라 본가에 있는 게 더 편해서 월세가 너무 아까웠음... ㅠㅠ

첫 인턴십

처음 했던 인턴십 내용은 아래 글에 너무 자세히 적어두기도 했고ㅋㅋ 다들 너무 많이 읽어주셔서 링크로 대체한다.

jyami.tistory.com/116

 

네이버 백엔드 인턴십 후기

올해 3월부터 6월까지 약 3개월간 했던 네이버 인턴십 후기를 작성하려 한다. 계속 써야지 써야지 하면서 미루다가 인턴십이 끝난 지 거의 2달가량이 돼서 사실 시간이 꽤 많이 지났지만, 아무래

jyami.tistory.com

 

4학년 1학기.. 졸업 프로젝트 끝!

학교와 회사를 같이 병행하게 해 두긴 했지만 그래도 해야 할 일은 있었다. 어찌 됐든 졸업을 하기 위해 기존에 하던 졸업 프로젝트를 다 했어야 했는데 이때 친구들한테 너무 감사했다... 퇴근하고 작업하다 보니 코딩도 많이 못하고 참여도 많이 못했는데 덕분에 잘 마무리했다...ㅎ 진짜 대학생활 첫 프리라이딩이었던 것 같...ㅋㅋㅋ 

이 졸업 프로젝트 때문에 퇴근하고 코딩하고 배포하고.. 안드로이드 xml도 짜고 별 경험을 다했는데ㅋㅋㅋ 회사와 학교 병행하기 정말 힘들다는 걸 알았다ㅠㅠ 회사일에만 집중하고 싶은데 그러지 못해서 슬펐다.. 그렇지만 이걸 안 하면 졸업을 못해서 취직을 못하닠ㅋㅋㅋ (그치만 이것 역시 같은 실수를 반복하게 된다..)

결국 4학년 1학기는 총 14학점 중 패논패만 11학점으로ㅋㅋㅋㅋㅋㅋ 엌ㅋㅋㅋㅋ (회사 학교 병행 꿀팁 : 패논패) 그리고 졸프는 A 학점으로 마무리하게 된다. 원래는 조기졸업도 생각을 했었는데, 조기졸업을 위해 학점을 더 들으면 인턴십에 무리가 있을까 걱정돼서 조기졸업은 미루게 되었다.

 

[ 6월 - 8월 ]  짧은 취준과 꿀 같은 휴식

우울감 극복

6월 중순 전환면접을 보자마자 느낌이 안 좋아서ㅋㅋㅋㅋ 사실 그날 바로 이력서를 업데이트했다ㅋㅋㅋㅋㅋ 원래 없던 영어 CV도 작성하고, 기존 인턴십 이력도 추가하고

jyami.tistory.com/8?category=865823

 

Backend Developer Resume

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

jyami.tistory.com

이력서 업데이트뿐만 아니라 여러 곳을 더 넣으면서 최대한 우울한 감정에 빠지지 않으려 했다. 처음에는 오랫동안 기대하고 노력한 일을 실패했다는 생각에, 우울한 감정으로 많이 울고 힘들어했었지만, 생각지도 못한 이유 덕분에 빠르게 회복했다. 

떨어졌다는 상실감이 사실 투지력으로도 불타서ㅋㅋㅋㅋ 공부도 꾸준하게 다시 시작하고, 이곳저곳 이력서를 넣었다. 그런데 이력서를 넣으면서 내가 더 원하는 곳에 도전할 수 있는 기회가 생긴 거구나 라는 생각이 문득 들었다. 그래서 실제로 이력서를 넣은 4곳 중 3개 모두 최종 합격까지 가게 되었고, 내 가치를 봐주는 곳이 많다는 자신감이 생기면서 극복하게 되었다.

당시 그래서 한 달 반 정도 취준을 위한 공부를 했던 것 같다. 매일매일 리트코드 챌린지를 이용해서 알고리즘 연습을 하고, 총 5~6번의 면접을 위해 그때그때 내가 사용했던 프로젝트의 기술 스펙을 돌아보고 컴퓨터 공학 지식을 한번 더 점검하는 시간을 가졌다. 사실 이 부분도 굉장히 기억에 남는다. 만약 그냥 취업을 했다면, 취업을 위한 최소한의 컴퓨터 공학 지식 공부도 안 했을 텐데, 이 기회를 통해 공부한 게 좋았다. 그동안 4년간의 공부를 정리하게 되었고 이때 쌓아둔 기반은 앞으로의 다시 깊게 공부할 기초에 대한 아웃라인이었기 때문에 하길 잘했다는 생각이 들었다.

짧은 취준이었지만 기술적으로도 정신적으로도 정리할 수 있었던 시간이었다. 사실 뭔가 큰일에서 엎어지고 극복한 게 이번이 처음이 아니었다. 대입에서도 내가 장시간 준비했던 원하는 학교에 불합격을 했는데, 오히려 전화위복으로 이화를 가게 되었고 더 큰 기회를 얻게 되었다. 그런데 되돌아보니 하나의 징크스처럼 지금도 그런 게 아닐까?라는 생각을 하게 되었다.

 

길고 길었던 카카오의 절차

사실 이 부분에 대한 글을 쓰고 있었는데 완성을 하지 못해 회고부터 쓰게 되었다..ㅠ 이 글 다쓰면 회고에도 참조해서 다시 넣어야지ㅎㅎ 

나는 취준을 하면서 공채에 넣을 생각이 1도 없었다. 공채에서는 아무래도 개개인의 활동에 대한 맞춤 질문보다는 좀 더 정량적으로  평가하기 위한 요소들이 훨씬 많을 것이라는 예상이 있었기 때문이다. 이런 평가가 나의 가치를 제대로 봐줄 수 있을까라는 의구심과 여러 IT기업의 공채 공고가 뜨기까지 기다리지 못하는 조급함이 있었다.

내가 서류를 넣은 4곳 중 가장 가고 싶었던 곳은 카카오였다. 사실 그래서 최종 합격 발표가 난 나머지 두 곳이 시기는 더 빨랐지만, 가장 가고 싶었던 곳이 여기었기에, 두 곳 모두 계약서 작성을 거절하고 여기 면접에만 집중했었다.

나는 상시채용으로 기반서비스개발팀에 지원을 하게 되었고, 신입의 경우 상시채용으로 입사하면 계약직으로 3개월 일하고 이후에 평가를 한 번 더 받는다는 페널티가 있었지만 그런 페널티를 모두 무시하고도 너무 가고 싶었다..!!!! 

서류 전형 => 코딩 테스트 => 원격 인터뷰(전화 인터뷰) => 1차 인터뷰 => 2차 인터뷰 => 합격 

절차는 위와 같았는데, 전화 인터뷰는 1시간, 1차 인터뷰는 2시간, 2차 인터뷰는 1시간.. 총 4시간의 면접을 통해 합격을 하게 되었다. 지금 생각하면 같이 일하시는 분들이 인터뷰를 봐주신 거였는데 다들 해주시는 배려가 너무 감사했다.

사실 카카오에 가고 싶었던 이유 중에 하나로 면접관의 분위기가 있었다. 나는 인터뷰는 면접관이 지원자에 대해 평가를 하는 자리뿐만 아니라, 지원자가 그 회사에 대해 평가도 같이하는 것이라고 생각하고 있다. 그런데 카카오가 가장 면접관분들의 질문이 가장 컴퓨터 지식에 대해, 그리고 내 활동에 대해 깊게 물어봤기 때문에 인상이 좋았다. 한 가지 기술이라도 내가 기술을 사용할 때 어떤 부분을 고려하고 사용하는지, 사용하는 기술에 대해 이론적으로도 올바르게 알고 있는지 대부분 이런 질문이었는데, 그만큼 더 공부하고 알아야 하는 팀이라서 더 깊은 질문을 하시는구나라는 느낌을 받았다. 그리고 틀리게 대답한 질문이면 다음 면접에서 혹시 이 부분 다시 대답해보실래요? 이런 식으로 개선의 기회도 주는 게 너무 감사했다.

이때 모든 면접을 화상으로 봤는데 화상으로 보다 보니 한 번쯤은 가보고 싶었던 카카오 오피스도 못 가봤다 흑흑.. (그래도 합격하고 입사해서 갔으니 괜찮다ㅎ) 그치만 코로나 시대 취준생으로써 앞으로 면접을 직접 대면해서 보는 게 더 어색할 것 같다. 화상으로 하는 면접이 너무 익숙해졌다.

이외에도 받은 느낌이 너무 많은데 이건 나중에 쓸 취준 글에서 쓰기로 하자ㅋㅋ

 

합격과 함께 꿀 같은 휴식 - 나 홀로 제주도 여행

결국 가장 원하던 곳에 합격을 하고 저번에는 못했던 리프레시하는 시간을 가졌다. 그동안 쉼 없이 달려 번아웃이 온 상태였기 때문에 휴식은 갖고 싶었기 때문이다. 나는 학교를 다닐 때도 휴학 없이 방학에도 대외활동으로 시간을 많이 보냈었는데, 그 이유는 뭔가.. 쉬려고 해도 쉬지 않고 내가 뭔가를 또 하고 있을걸 알았기 때문에 휴학도 휴식도 그냥 안 가졌었다ㅋㅋㅋㅋ

그렇지만 역시 8월에도 코로나 때문에 누군가를 만나기는 부담스러웠다. 그래서 가고 싶었던 유럽여행도 가장 마음이 편한 시기인 취업 확정된 상태인 입사 전 한 달 동안 꼭 갔다 올 거라고 버킷리스트에 담아두었었다. 그렇지만 코로나...ㅠ 괜히 해외로 여행 갔다가 코로나 걸리면 입사에만 문제가 생길 테니 포기했다. 대신 조심하면서 한 번쯤은 해보고 싶었던 국내 혼자 여행을 했다.

혼자 제주도에 가서 혼자 오겹살도 먹고, 서핑도 배우고 이래저래 많이 돌아다니면서 힐링을 했다. 제주 바다는 언제 봐도 좋았다. 

이때 태풍이 오던 시기라서 태풍도 빡세게 경험했었다. 원래 태풍 때문에 하루 내내 호텔에 있을 생각을 했고, 그래서 그날은 하루 종일 호텔에서 롤 하려고 노트북도 가져갔다!!! 근데 태풍 때문에 호텔이 정전이 됐곸ㅋㅋㅋㅋㅋㅋ 하... 결국 계획대로 하지 못했다ㅠ

면허가 없는 뚜벅이라서 조금 힘들기도 했지만 나름의 매력이 있었다 처음 만나는 언니가 태풍 오는 날 위험하다고 호텔까지 데려다 주기도 하고 뚜벅이라서 힘들었지만 뚜벅이라서 스펙타클했던 경험을 했다.

제주도 외에는 입사 전에 한 일이 게임밖에 없다ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 원래도 롤을 좋아했었는데, 이 시기에 같이하는 게임 친구들도 생겨서 진짜 매일 오전 6시에 자고 낮 3시에 깨고... 겜창 인생을 반복했다ㅎ 랭크했으면 회고록에 적었을 텐데 아쉽게도 맨날 5인 큐로 일반 돌리다 보니 op.gg에 총판수만 늘어났다  (하... 이때 학교 졸업준비 좀 했어야 했는데...)

 

엔젤 핵 참가

아 생각해보니 취준 중에 엔젤핵도 나갔었네, 엔젤핵이 올해는 리모트로 진행이 되었는데 기존에 중국 해커톤을 했던 소현이 원종오빠 + 멋사에서 같이 촬영팀을 했던 현석오빠 + 같이 자바 봄 스터디를 하고 있는 민형 오빠 이렇게 다섯이 참가하게 되었다. (이때 스프링 시큐리티를 조금 보게 되었는데 진짜 아직도 모르겠다ㅋㅋㅋ)

위에 네이버 버닝 데이 할 때만 해도 해커톤은 절대 안 한다!! 이러고 있었는데, 그치만 다들 오래 본 사람들이라서 친한 사람들끼리 나가는 해커톤이 또 나가고 싶었던 건지 하핳.. 또 하게 되었다.이 서비스는 언제 마무리하지... 해커톤은 하면 할수록 마무리 안된 코드만 늘어나는 것 같아 슬프다 아휴..

우리는 처음에는 온라인으로 하다가 마지막 2일 다 같이 에어비앤비에 모여서 작업했었다. 당시 타임랩스도 찍고,, 다들 잠도 못 자고ㅋㅋㅋ 항상 해커톤은 할 때마다 느끼지만 프론트엔드가 고생하는 것 같다. 뭔가 항상 바빠 보인달까

엔젤핵 할 때 재밌었던 것 중 하나는 이때 온라인으로 하다 보니 운영진분들이 액티비티도 온라인으로 준비하셨었다. 그래서 온라인 게임 점수를 기반으로 상품을 주곤 했는데, 크롬 공룡 게임에 미쳐서...(그냥 게임이면 미치는 듯) 개발도 안 하고 계속 공룡 점프나 시켰다.

 

[ 9월 - 12월 ]  카카오 입사 그리고 학교 졸업?

카카오에서의 생활

그렇게 게임만 하고 살던 와중 입사가 가까워져 왔다. 근데 왜 위에 말한 것처럼 왜 내가 입사할 때면 코로나가 심해지는 걸까ㅠ 인터뷰도 원격으로 보고, 입사도 원격으로 하게 되었다. 카카오에서 했던 원격 입사에서 했던 온보딩 프로그램 진행할 때 받은 워크북이랑 이것저것 굿즈들❤️ 너무 좋았다ㅎㅎ 아 면접 때는 몰랐던 내가 일 할 파트도 알게 되었는데 카카오톡의 채팅 부분에 해당하는 톡 메시징 파트에 가게 되었다. 가장 핵심인 서비스이고 그런 만큼 정말 봐야 할 것도 알아야 할 것도 많다는 걸 입사 처음에도 실감했지만 지금은 더더더더더 실감하고 있다..ㅠ 공부하자 제발

그렇게 풀 재택근무를 한 한 달 정도 했었다. 그리고 약 한 달 후 코로나가 꽤 괜찮아져서 순환근무를 2주 정도 하다가, 풀 출근을 2주 정도 했다. (그러다 다시 심각해져서 요즘과 같이 일확진자 1000명대가 되었다.) 

사실 재택근무만 할 때는 적응하기 힘들었다. 여쭤보는 건 언제나 고민이었다. 너무 쉬운 걸 물어보는 건 아닐까, 멘토님이 실무로 바쁘신데 내가 귀찮게 하는 건 아닐까..? 하는 생각이 있었기 때문이다. 그치만 항상 물어보면 너무 친절하게 알려주셨다. 그리고 내가 본 분 중에 진짜 가장 대단한 분을 만나게 된 점에 너무 좋았고 멘토님은 모르겠지만 많이 존경하고 있다ㅋㅋㅋㅋㅋ 하ㅏ... 진짜 대단... 그렇게 되고 싶다

어쨌든 확실히 신입은 출근을 하면 좋은 것 같긴 하다. 출근했을 때 이래저래 파트분들과의 일상에 조금씩 적응하게 되고 소속감이 느껴지기 때문이다. 그래서 누구보다도 사실 출근을 하고 싶었는데... (이번 연말 대응에도 너무 회사에 가보고 싶었는데..) 안타깝게도 요즘 너무 심하다...

카카오 상시채용 신입으로 들어가 계약직으로 지낼 때도 마찬가지로 인턴 과제를 받아서 수행했다. 네이버 때와는 다르게 파트와 너무 연관된 내용이 많아 자세히 적을 순 없지만, 생각보다 새로운 도전을 많이 해보았다. 그리고 반성도 많이 했었다.

이번에 새로웠던 건 네티 프로그래밍 + 코틀린을 사용했던 것이었다. 벌써부터 공부해야 할까? 싶었던 4 계층을 이번 기회에 책도 보고, 기존 실무 코드도 보면서 익힐 수 있었는데 아직도 헷갈린다ㅠ 이 파트에 있으면서 진짜 공부할게 엄청 많다는 걸 느낀다. 면접 때 물어본 스레드나, 비동기 프로그래밍, 동기화 등 다소 어려웠던 개념들을 집중적으로 여쭤보신 이유가 있었구나 싶었다. 그때 이론적으로만 열심히 했던 대답들을 코드로 실제로 threadExecutor나 sychronized 등 사용되는 코드를 보니 내가 이걸 건드려도 되는 걸까 싶었다.

그리고 처음 써본 코틀린에 대한 느낌은 와 진짜 편하긴 하다!!! 근데 아직 자바보다 덜 익숙해서 내년에 코틀린 인 액션을 읽으면서 안티 패턴을 피하고, sealed class나 suspend function, 코루틴 등 코틀린을 코틀린답게 사용하는 방법을 공부하려 한다. 개인적으로 정말 좋았던 건 생성자가 너무 편했다 내가 만든 과제 서버도 코틀린 + 스프링으로 짤까 고민도 했지만 평가가 걸린 만큼 익숙한 언어로 구현하는 게 나을 것 같아 자바 + 스프링을 사용했는데, 코틀린 <=> 자바 호환도 되게 잘 돼있다. 꼭 코프링해봐야지+_+

그리고 이번에도 역시 k8s 기반으로 배포를 했는데, 이전에는 helm을 사용해서 오브젝트들을 관리했는데 이번에는 파트 내에서 kustomize를 사용하고 있어서, 나도 kustomize로 작성을 한번 해보는 걸 도전해보았다. 약간 개인적인 느낌은 으음,, 비유가 올바를지는 모르겠지만 helm은 약간 jsp에 데이터 바인딩하는 것처럼 주어진 템플릿에 값을 주입해 넣는다면, kustomize는 자바 오버라이드처럼 설정 값에 따라, 오브젝트 공용 설정은 미리 베이스로 해 두고 수정이 필요한 부분만 설정값을 오버라이드 해서 넣는 느낌이었다. 근데 사실 어떤 툴이든 특성에 맞게 잘만 사용하면 되는 거니까 +_+ 이번에는 k8s를 사용할 때 클러스터 내 네트워크도 구성하면서 한 단계 성장한 느낌이 든다.

 

약간의 슬럼프 그렇지만 정규직 전환 합격

다들 몰랐겠지만 사실 슬럼프가 왔었다. 사실상 인턴생활에 올 한 해를 전부 보내버렸고, 인턴이다 보니 제한된 권한도 있었고 실무로부터 조금은 떨어져 있는 과제를 받다 보니 실무에 기웃거리지만 혼자서만 코드를 짠다는 것에 회의감을 느꼈기 때문이다. 아무래도 나 혼자서 커밋하고 머지하는 코드는 정체될 수밖에 없고 한계가 있을 수밖에 없는데, 혼자 하는 프로젝트를 계속해서 하다 보니 힘들었었다.

만약 다른 친구들처럼 상시채용이 아니라 공식적인 인턴 모집으로 같이 인턴 생활하는 하는 친구들이 있었다면 좀 더 의지할 곳이 있지 않았을까. 많은 다른 개발자들처럼 공채를 준비했으면 같이 입사한 동기들도 있고 계약직이라는 불안정한 상황 없이 바로 정규직이니까 조금 덜 불안하지 않았을까. 와 같은 만약을 계속 생각하며 아쉬워했었다. 원래 나의 행동에 후회를 하지 않고 그때그때 잘한 선택이라고 믿고 추진하는 편인데 나에게 상시채용 + 인턴이 최선의 선택지였고 지금 충분히 잘하고 있다는 걸 알고 있음에도 자꾸만 다운되었다.

사실 이렇게 다운되는 경우 여러 사람들을 만나고 기운을 받아 다시 동기부여를 하는 타입인데, 코로나로 인해 그러질 못했어서 더 슬펐다. 그러다 보니 계속 이야기를 할 수 있는 게임 친구들과의 디코에 들어가게 되고 그러다 보니 이전보다 개발 공부에 투자하는 시간이 적어지고 게임에 투자하는 시간이 많아지는 악순환이 반복되었다.

그래서 정규직 전환 면접 직전 가장 멘탈이 불안한 시기에는 본가로 올라와서 일부러 가족들과 함께 보냈다. 그래도 꿋꿋이 버티고, 업무시간에는 딱 집중을 하면서 살다 보니 다행히도 면접에서 좋은 인상을 주었는지 전환면접에 합격하게 되었다. 당시 합격에 대한 기쁨으로 모든 사람들에게 알리고 축하도 많이 받았는데 이때 슬럼프에서 탈출했다ㅎㅎ 아무래도 직장이나 소속에 대한 불안정성이 내 슬럼프의 가장 큰 원인이었던 것 같다.

 

유튜브 시작

그렇다.. 유튜브를 시작했다. 사실 시작은 정말 소소했다. 재택근무하는 타임랩스를 인스타 스토리에 올렸는데 주변 친구들이 유튜브 각?! 유하~! 이러고 보내서 호옹.. 진짜 해봐?! 이러고 패기롭게 9월에 시작했다ㅋㅋㅋㅋㅋ

www.youtube.com/c/%EC%9F%88%EB%AF%B8JYAMI

 

쟈미 JYAMI

🌱신입 백엔드 개발자 쟈미의 일상 기록🌱 블로그도 해야하는데 유튜브까지 두둥! 과연 할수있을까ㅇㅂㅇ

www.youtube.com

그치만 점점 전환면접으로 바빠지면서 11월 12월은 업로드 주기가 조금 느려지게 되었는데, 호오,,, 신기하게도 많은 분들이 사랑해주시고 계시다 (현시점 888명!!). 위에 링크 사진을 보니.. 썸네일도 배경도 대충 해서 올린 거라 이것도 유튜브 향으로 바꿔야 하는데 헤헷 중요한 건 아니니 미루기로 하자. 개인적으로 유튜브 찍으면서 좋았던 건 코드윗미나 스터디 윗미 찍을 때 뭔가 강제적으로 공부하게 된다ㅋㅋㅋㅋㅋ 굿... b

+ (2020년 1월 1일) 이전에 후배가 그려준 그림이 있어서 프로필 사진을 바꿨다 >.0

 

졸업을 위한 도전 학기 프로젝트

이번 회고는 쓰다보니 복선이 많다. 회사다니면서 학교 플젝하면 힘들다라고 했는데, 이번 계약직 기간에도 마찬가지로 학교플젝을 하고 있었다ㅋㅋㅋㅋ 이렇게 된 이유는 참... 코로나 때문이다.

도전 학기 지원 당시 나는 전공 6학점이 남은 상황이었고, 하반기에 코로나가 잠잠해지고 학교에서 대면 수업을 하지 않을까?라는 생각이 있었다. 그렇기 때문에, 회사와 학교를 병행하면 학교의 대면 수업을 절대 못 갈 것 같다 생각했고, 그렇기에 혼자서 프로젝트를 설정하고 그걸 학기 내에 완수하는 도전 학기제를 선택했다. (그래서 덕분에 회사 퇴근하면 이거 개발하고 그랬다..ㅠ 갈갈각랄... 8월 한 달 내내 롤 하지 말고 이걸 했어야 했는데ㅋ) 근데 후회했던 건, 사실 코로나가 이렇게 심해질 줄 알았다면 어차피 비대면일 테니 그냥 대충 수업 듣고 F만 안 맞았으면 됐겠네?라는 아쉬운 점이 있다는 것이다ㅋㅋㅋ. 그랬다면 회사일에 좀 더 집중할 수 있었을 테니!

내가 선택한 도전 학기 프로젝트는 위에서 했던 이화 동산 커미터스의 확장판으로 이화인을 위한 개발 커뮤니티를 만드는 프로젝트를 진행하였다. 개발은 스프링, 리액트로 백 + 프론트 모두 했으며 배포도 헤로쿠로 했으나 현재는 에러를 발견해 서버를 내려둔 상태이다.

현재 커밋 기록 가져오는 작업에 대해 배치성 작업임에도 불구하고 API 형태로 구현되어있어 보수를 해야 하며, 스프링 시큐리티에 미숙해 에러 핸들링 부분에 오류가 있던걸 배포 직전에 발견했다. 또 프론트엔드 역시 어... 되게 해커톤식의 코드로 구현해두어서 마음에 들지 않아 실제 유저를 대상으로는 배포를 하지 않았다. 현재 주변 지인들로 베타 버전에 대한 피드백만 받았으며 음.. 실제 배포는 보수해서 내년 2월에 할 수 있으면 좋겠다ㅋㅋㅋㅋ

이 프로젝트로 전공 6학점을 받게 되었고 나는 졸업 이수요건인 140학점을 모두 채울 수 있었다. 그래서 나의 대학교 학점은 4.3 기준 3.85 / 4.5 기준 4.03으로 마무리하게 되었다. 사실상 4학년 1학기 2학기는 모두 회사생활로 인해 패논패 수업을 들었기 때문에 내 학점은 사실상 3학년 때 완성을 시켰다.

그렇지만 나에게는 한 가지 복병이 더 남아 있었는데...

 

결국 수료...ㅎ 졸업은 내년ㅋㅋㅋㅋㅋㅋ 사진이나 찍자

그렇다... 조기졸업도 생각했지만 결국 칼 졸도 못하고 수료를 하게 되었다. 그 이유는 토익이다ㅎ 우리 학교 컴공 졸업요건에는 토익 700을 넘어야 하는 기준이 있다. 그러나 하하.. 매번 영어는 가장 후로 미루고 미루다 보니 항상 회사 + 여러 학교 프로젝트 + 개발 공부에 우선순위가 밀려 토익공부를 안 했다.

토익공부를 하나도 안 한 채로 혹시나 하는 마음으로 토익시험을 한번 보기는 했는데 700점은 안 나오더라ㅠ 그래서 결국 수료를 하게 되었다. 아마 졸업은 내가 토익을 딴다는 가정하에 21년 8월 졸업을 할 것 같다. 그때까지 코로나가 잠잠해져서 그때는 졸업식을 갈 수 있기를!!

그래서 올해 친한 동기들과 졸업 스냅사진을 찍었는데 너무 좋았던 기억이다 :) 내 대학 4년을 버티게 해 준 우리 컴공댕이들 고맙다

 

마무리

20년 회고는 19년 회고에 비해 어두운 내용도 있었다. 19년도는 마냥 밝기만 하고 감사만 했던 회고였던 것 같은데, 올해는 마냥 좋아 보이는 말만 쓰고 싶지 않았기 때문이다. 

이제 진짜 신입 개발자로 21년을 시작할 예정이다. 항상 감사한 프루님 은님이 하신 말이 기억에 남는다. 3년 힘들게 공부하라고. 내년에는 더 더 책 읽어야지 진짜... 지금 당장 부족하다고 느끼는 것만 해도 디자인 패턴, 네트워크, 스레드, 디비 어우 너무 많다.

파트 내 시니어 개발자 분이 본인은 신입 때 한 달에 두 권씩 책을 읽었다는 말을 하셨는데, 그렇게 공부를 하셨으니 지금 이런 퍼포먼스를 내시는 거였구나 싶다. 지금 주변에 너무 대단한 분들이 많은 환경이니 나도 우리 메시징에 적응하기 위해서는 따라가야지 +_+. 꾸준히 공부하는 게 내년 목표이다. 

파이팅 :) 

ps. 내년 회고는 꼭 31일 말고 30일에 써야지..

+ (21년 12시 지나서) 올해 카톡 안터졌다..b 파트분들 넘 멋짐쓰

Last year I also wrote my year-end reflection on the 31st, and here I am writing it on the 31st again this year...lol No, actually I was going to write a post about job hunting before this, but due to time constraints, let's save that for the new year haha... Wow, and I'll be 24 in '21, time flies...

This year there's been so much talk about how COVID has made job hunting harder, and thanks to that, I feel like I experienced every possible emotion through my job search this year..lol This year's reflection is going to read mostly like a job seeker's diary, but let's get started anyway hehe (hey, at least I'm writing it, right..)

Wow.. looking back at this now, I was really full of passion back then.. It's kind of like a one-year diary when you write a year-end reflection, but it brings back so many memories

---

[January - February] Internship Applications and Various Activities

Internship Applications and Acceptance

It wasn't intentional, but I sort of had my own college roadmap lol — Freshman year: on-campus dev club / Sophomore year: off-campus dev club / Junior year: company-partnered extracurricular dev activities / Senior year: company internships and job searching. That's how my college life went.

So I'd been preparing for internships since December 2019, and I remember applying through various channels — professor recommendations, referrals from people I knew, direct applications, and more. As a result, most of the document screening and coding test results came out around January–February.

Back in January–February of 2020, I genuinely had no intention of getting a full-time conversion — I was just trying to build my resume with an experiential internship, so I'd done zero preparation for coding tests or interviews. But thankfully, they saw something good in me during the interview (wow, thinking back, I didn't prepare for the interview at all and crammed the night before for my very first intern interview.. the audacity..) and I got to intern at Naver in the first half of 2020.

So since I hadn't started yet, February should've been a time to rest and have fun.. but of course, with my unstoppable drive, I ended up making a mistake...

 

Backend Freelance Project

Yep... I was working on a freelance project due at the end of February..lol A guy I'd gone to Open Hack + a hackathon in China with asked me to turn a Java library into an API, so I took on the project. The main tasks were GCS integration + external library integration, and wow.. that's when I really felt the importance of test code.

Honestly, I thought I could just whip up a simple controller in Spring and plug the Java library into the service layer, so I ignored object relationships and clean code and just wrote spaghetti code however I wanted.. But then all these errors I couldn't understand started popping up. I finally came to my senses, wrote test code, refactored the code piece by piece, and restructured things internally so each object had a single responsibility. That's when I truly felt the dangers of writing code that ignores maintainability and object-oriented principles.

So... I actually remember being so busy right before my internship interview fixing this freelance project code, then going to the interview, and continuing to work on it right up until my start date. As far as I know, they're not using the server I built anymore, but when I looked it up while writing this reflection, it shows up in search results.. ooh, looks like they're doing great as a student startup.

 

Naver AI Burning Day

And.. right.. I went to Naver AI Burning Day.. I literally said "never doing another hackathon!!" after the China hackathon in my junior year. But apparently it's like an annual event for me. (And I said the same thing when Burning Day ended too — "no more hackathons -_-"..lol) 

Since it was an AI-focused competition, I thought there wouldn't be much for me to do, but ahhh... every hackathon I go to, there's always something new I struggle with. If I remember correctly, the issue was that it was hard to debug when running the Python code written by our team's AI engineer in Spring, but I don't remember the details.

Also, they provided Naver Cloud Platform credits for this event, and I had a hard time getting used to the platform (but thanks to that experience, I actually have a server running on NCP these days).

The amazing thing about hackathons is that somehow you always manage to finish something..(And I kept saying I'd never use Spring again at hackathons where productivity matters... but I always end up using Spring anyway) This event actually had a networking component where you could talk with Naver employees and potentially get job opportunities depending on the person, but since I'd already been accepted for the internship, I just happily collected the swag >< (The sweatshirt I got is great for stealth-wearing to work, so I wear it all the time)

And during the recreation time, I somehow won AirPods as a prize... nice... But since I already had a pair, I sold them on Danggeun Market lol

 

Google HashCode Participation

jyami.tistory.com/52?category=854536

 

HashCode 2020 Participation Review

처음으로 PS 대회에 참가해봤다. DSC Korea 슬랙에서 팀원을 구한다는 얘기를 듣고 참가를 하게 됐는데! 하하 UTC 17:30이라니,, 한국시간으로 오전 2:30부터 6:30까지 였다. 그래서 팀원들끼리 코딩할

jyami.tistory.com

It wasn't an event I poured my heart and soul into, but looking back, I did a lot between January and February..haha That's when I realized I'm really bad at algorithms... I totally got carried by my team (nostalgic..) and I'm still not confident about algorithms ㅠㅠ

 

Ewha Dongsan Committers

As I also wrote in my previous DSC Ewha Lead reflection, around that time a few DSC members and I created a daily commit group. We used Slack and a web app as tools to track our commit records, and for the web app, we forked the code from a group that had been doing something similar and customized it for our group.  (Related post: jyami.tistory.com/123?category=865823)

 

After Finishing as 2019-2020 DSC Ewha Lead

2019년 8월부터 2020년 8월까지 1년간의 DSC 활동이 끝났다. 사실 진작 활동을 정리해서 써야지 했는데, 미루다 보니 어느새 10월이다ㅋㅋㅋ이전에 회고록에서 DSC 활동에 대해 쓰긴 했었는데, 아무래

jyami.tistory.com

The existing code was written in Django and wrapped in Docker, and I really struggled with the environment setup. I wasn't familiar with Django or Docker at the time, but hmm.. something I've been feeling lately is that the more I go on, the less it matters what framework or tool you're using. Maybe it's because I've gotten better at Googling lol. I've developed the mindset that if I don't know something, I just search for it, deploy it, build it, and muddle through.

 

[ March - June ]  COVID and Senior Year First Semester with First Internship

The COVID Boom

In March 2020, COVID cases surged rapidly. As cases increased, many activities had to be suspended — most notably, all university classes went online (which meant I could barely do any DSC activities..), and the company switched to remote work too. I had carefully arranged my school schedule so I could manage both in-person classes and work, and was waiting for my start date, but then the start date got pushed back and I ended up onboarding from home. (And this pattern of COVID getting worse and going back to remote work right around when I start would repeat itself later...)

And above all else — I'd found a new place to live in anticipation of the internship, but since we were working remotely, it was more comfortable staying at my parents' house, so the rent felt like such a waste... ㅠㅠ

First Internship

I wrote about my first internship in great detail in the post below lol and so many people read it, so I'll just link to it here.

jyami.tistory.com/116

 

Naver Backend Internship Review

올해 3월부터 6월까지 약 3개월간 했던 네이버 인턴십 후기를 작성하려 한다. 계속 써야지 써야지 하면서 미루다가 인턴십이 끝난 지 거의 2달가량이 돼서 사실 시간이 꽤 많이 지났지만, 아무래

jyami.tistory.com

 

Senior Year First Semester.. Graduation Project Done!

Even though I'd set things up to juggle school and work, there were still things to do. I had to finish the graduation project I'd already been working on in order to graduate, and I was so grateful to my friends during this time... Since I could only work on it after getting off work, I couldn't code much or participate as actively, but we wrapped it up well thanks to them...heh I think that was honestly my first time free-riding in my entire college life...lol 

Because of this graduation project, I was coding after work, deploying, even writing Android XML — I did all sorts of things lol But I learned that balancing work and school is really, really hard ㅠㅠ I wanted to just focus on work but couldn't, and that made me sad.. But if I didn't do this, I couldn't graduate, which meant I couldn't get a job lol (But of course, I'd end up repeating this same mistake later..)

In the end, my senior first semester — out of 14 total credits, 11 were pass/fail lolololol omg lol (Pro tip for balancing work and school: pass/fail) And I finished my graduation project with an A. I had originally considered graduating early, but I was worried that taking more credits for early graduation would strain my internship, so I decided to postpone it.

 

[ June - August ]  A Brief Job Search and Sweet, Sweet Rest

Overcoming the Blues

Right after my conversion interview in mid-June, I had a bad feeling about it lol so I actually updated my resume that very same day lol I even wrote an English CV that I'd never had before and added my internship experience.

jyami.tistory.com/8?category=865823

 

Backend Developer Resume

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

jyami.tistory.com

Beyond just updating my resume, I applied to multiple places and tried my best not to fall into a depressive funk. At first, thinking about how I'd failed at something I'd hoped for and worked toward for so long, I cried a lot and had a really hard time. But I recovered quickly thanks to an unexpected reason. 

The sense of loss from being rejected actually fueled my fighting spirit lol I started studying consistently again and sent my resume everywhere. And as I was applying, I suddenly realized — oh, this means I now have the opportunity to aim for places I want even more. In fact, out of the 4 places I applied to, I ended up getting final offers from 3 of them, and the confidence that many places saw my value helped me overcome everything.

So I think I studied for job prep for about a month and a half. Every day I practiced algorithms using the daily LeetCode challenge, and for about 5–6 interviews, I reviewed the tech specs of projects I'd worked on and double-checked my computer science knowledge each time. This period is really memorable to me too. If I had just gotten the job, I probably wouldn't have done even the bare minimum of CS studying needed for employment, so I'm glad I had this opportunity to study. It helped me organize everything I'd learned over 4 years of college, and the foundation I built during this time served as an outline for the fundamentals I'd later need to study more deeply, so I'm glad I did it.

It was a short period of job searching, but it was a time when I could get myself together both technically and mentally. Actually, this wasn't the first time I'd been knocked down by something big and bounced back. When I was applying to college, I didn't get into the school I'd prepared for over a long time, but it turned out to be a blessing in disguise — I ended up going to Ewha and got even bigger opportunities. Looking back, I started to think — maybe it's like a jinx (or pattern) that's happening again now too?

 

Kakao's Long, Long Process

I was actually writing a separate post about this part, but I couldn't finish it so I ended up writing the year-end reflection first..ㅠ Once I finish that post, I'll link it back here too hehe 

While job searching, I had absolutely zero intention of applying through public recruitment. I figured that public recruitment would involve way more quantitative evaluation factors rather than customized questions about each individual's activities. I had doubts about whether that kind of evaluation could truly see my value, and I was too impatient to wait for the various IT companies' public recruitment announcements to come out.

Of the 4 places I applied to, the one I wanted to go to the most was Kakao. Actually, the other two places that gave me final offers were faster with their timelines, but since this was the place I wanted to go to the most, I declined to sign contracts with both of those companies and focused solely on my interviews here.

I applied through the year-round recruitment to the Platform Services Development team. For new grads, applying through year-round recruitment came with the penalty of working as a contract employee for 3 months and then being evaluated again, but I wanted to go so badly that I was willing to ignore all of that..!!!! 

Resume Screening => Coding Test => Remote Interview (Phone Interview) => 1st Interview => 2nd Interview => Accepted 

The process was as above — the phone interview was 1 hour, the 1st interview was 2 hours, and the 2nd interview was 1 hour.. I got accepted through a total of 4 hours of interviews. Thinking about it now, the people who interviewed me are the ones I work with, and I'm so grateful for all the consideration they showed.

One of the reasons I wanted to go to Kakao was actually the vibe of the interviewers. I believe that an interview isn't just a place where interviewers evaluate the candidate — it's also where the candidate evaluates the company. And Kakao's interviewers asked the deepest questions about computer science knowledge and about my activities, which left a great impression. Even for a single technology, they asked what I considered when using it and whether I had a theoretically correct understanding of the technologies I used — most of the questions were like that. I got the feeling that they asked such deep questions because it was a team where you needed to study and know more. And when I answered a question incorrectly, they'd say in the next interview, "Would you like to try answering this again?" — giving me a chance to improve, which I really appreciated.

All interviews were conducted via video call, and since they were all virtual, I never got to visit the Kakao office that I'd always wanted to see.. sob sob.. (But it's okay because I got accepted and visited after joining heh) Still, as a job seeker in the COVID era, I think meeting face-to-face for interviews would actually feel more awkward going forward. I've gotten so used to video interviews.

There are so many more impressions I had, but I'll save those for the job hunting post I'll write later lol

 

Acceptance and Sweet Rest — Solo Jeju Island Trip

After finally getting accepted to the place I wanted most, I took some time to refresh that I hadn't been able to before. I'd been running nonstop and was burned out, so I really wanted some rest. Even when I was in school, I never took a leave of absence and spent my breaks on extracurricular activities. The reason was... even when I tried to rest, I knew I'd end up doing something anyway, so I never bothered with taking time off lol

But even in August, meeting people was uncomfortable because of COVID. I'd been planning a Europe trip on my bucket list — I was going to go during the most stress-free time possible, the month before starting my job after securing employment. But COVID...ㅠ Going abroad and catching COVID would only cause problems for my start date, so I gave up. Instead, I took precautions and went on a solo domestic trip that I'd always wanted to try.

I went to Jeju alone, ate samgyeopsal by myself, learned to surf, and wandered around a lot to heal. The Jeju ocean is always beautiful no matter when you see it. 

It happened to be typhoon season, so I got to experience a typhoon full-force. I had planned to stay in the hotel all day because of the typhoon, so I'd even brought my laptop to play League of Legends all day!!! But then the hotel lost power because of the typhoon lololol sigh... In the end, things didn't go as planned ㅠ

It was a bit tough since I don't have a driver's license and had to walk everywhere, but it had its own charm. A woman I'd just met for the first time drove me back to my hotel because it was dangerous with the typhoon coming, and while it was tough walking everywhere, the fact that I was on foot made for some spectacular experiences.

Other than Jeju, all I did before starting my job was play games lolololol I'd always liked League of Legends, but during this period I made gaming friends to play with, so I was literally going to bed at 6 AM and waking up at 3 PM... living the gamer life on repeat heh I would've written about my rank in this reflection, but unfortunately since we always played normals in a 5-man queue, only my total game count on op.gg kept going up  (sigh... I should've been preparing for graduation during this time...)

 

Angel Hack Participation

Oh, now that I think about it, I also participated in AngelHack while job hunting. AngelHack was held remotely this year, and I joined as a team of five with Sohyeon and Wonjong who I'd done the China hackathon with + Hyeonseok who I'd been on the filming team with at LikeLion + Minhyung who I was doing a Java Spring study group with. (I got a little exposure to Spring Security during this, and I honestly still don't get it lol)

I'd been saying "I'm absolutely never doing another hackathon!!" back during the Naver Burning Day, but since these are all people I've known for a long time, I guess the pull of doing a hackathon with close friends was too strong haha.. I ended up doing it again. When are we going to finish this project though... The more hackathons you do, the more unfinished code piles up, and that makes me sad sigh..

We started working online and then for the last 2 days, we all gathered at an Airbnb to work together. We filmed timelapses, nobody could sleep lol — every hackathon, I always feel like the frontend people have it the hardest. They always seem so busy.

One of the fun things about AngelHack was that since it was online, the organizers prepared online activities too. They gave out prizes based on online game scores, and I got obsessed with the Chrome dinosaur game...(I go crazy for any game, apparently) I wasn't even developing — I just kept making the dinosaur jump.

 

[ September - December ]  Joining Kakao and Graduating?

Life at Kakao

While I was just living my life playing games, my start date was approaching. But why does COVID always get worse right when I'm about to start a new job, like I mentioned earlier ㅠ I ended up doing my interview remotely and onboarding remotely too. The workbook and all the goodies❤️ I got during Kakao's remote onboarding program were so nice hehe Oh, and I also found out which team I'd be working on, which I didn't know during the interview — I was assigned to the Talk Messaging part, which handles the chat functionality of KakaoTalk. It's the most core service, and I realized from day one that there was so much to learn and understand, but now I feel it even more and more and more..ㅠ Please, let me study

I worked fully remote for about a month. Then about a month later, COVID eased up a bit, so I did rotating office days for about two weeks, followed by full in-office work for about two weeks. (Then it got bad again and daily cases hit the 1,000s like we're seeing these days.) 

Honestly, it was tough to adjust when I was only working from home. Asking questions was always something I agonized over. I kept thinking, "Am I asking something too easy? My mentor is busy with actual work — am I being a bother..?" But whenever I did ask, they always explained things so kindly. And I was so happy to have met someone who is genuinely the most amazing person I've ever encountered — my mentor probably doesn't know this, but I truly admire them lolol Hahhh... truly incredible... I want to be like that someday

Anyway, it really does seem like new hires benefit from going into the office. When I was in the office, I gradually got used to the daily life with my team members and started feeling a sense of belonging. So I actually wanted to go to the office more than anyone... (I really wanted to go in during the year-end response too..) Unfortunately, things are just too bad right now...

As a new hire through Kakao's rolling recruitment, I was on a contract position and similarly received an intern project to work on. Unlike Naver, the project was closely tied to the team's work so I can't go into detail, but I got to try a lot of new challenges. And I also did a lot of self-reflection.

What was new this time was working with Netty programming + Kotlin. I had wondered if it was too early to study Layer 4 networking, but through this opportunity I got to read books and look at actual production code to learn — though I'm still confused ㅠ Being on this team, I really feel like there's so much to study. I understood why during the interview they had asked me intensively about threads, asynchronous programming, and synchronization — concepts that were quite difficult. Seeing the theoretical answers I had worked so hard on actually being used in code with things like threadExecutor and synchronized, I wondered, "Am I really allowed to touch this stuff?"

As for my first impression of Kotlin — wow, it really is convenient!!! But since I'm still less familiar with it than Java, next year I plan to read "Kotlin in Action" to avoid anti-patterns and study how to use Kotlin the Kotlin way — things like sealed classes, suspend functions, and coroutines. Personally, what I really liked was how convenient the constructors are. I considered building my project server with Kotlin + Spring too, but since evaluations were on the line, I went with Java + Spring since I'm more comfortable with it — and the Kotlin ⇔ Java interop is really well done. I definitely need to try the Kotlin + Spring combo! +_+

And once again, I deployed on k8s this time too. Previously I used Helm to manage objects, but this time the team was using Kustomize, so I gave writing Kustomize configs a shot. My personal take is, hmm, I'm not sure if this analogy is perfect, but Helm feels like binding data to a JSP template — you inject values into a given template — while Kustomize feels like Java overriding — you set up common base configurations for objects and then only override the parts that need changes based on your settings. But honestly, any tool works fine as long as you use it well for its intended purpose +_+ This time I also configured in-cluster networking when using k8s, which made me feel like I leveled up.

 

A Bit of a Slump, But Passing the Full-Time Conversion

Nobody probably knew, but I actually went through a slump. I had essentially spent the entire year on internships, and being an intern meant I had limited access and was given projects somewhat removed from actual production work — so I felt disillusioned about writing code all by myself while only peeking at real-world work. Code that only I commit and merge is bound to stagnate and has its limits, and doing solo projects continuously was draining.

If I had come in through an official intern recruitment cycle like other friends and had fellow interns to go through it with, maybe I would've had more people to lean on. If I had prepared for the regular hiring process like many other developers, I would've had colleagues who joined at the same time and wouldn't have had the instability of being on a contract — maybe I would've been a little less anxious. I kept thinking about these "what ifs" and feeling regretful. Normally I'm the type who doesn't regret my decisions and believes I made the right choice at the time, but even though I knew that rolling recruitment + interning was the best option for me and that I was doing well enough, I just kept feeling down.

Usually when I feel down, I'm the type to meet people, recharge, and motivate myself again, but COVID made that impossible, which made it even sadder. So I ended up spending more time on Discord with my gaming friends since I could always chat with them, which led to a vicious cycle of spending less time studying development and more time gaming.

So right before the full-time conversion interview, during my most mentally unstable period, I went back to my parents' house and deliberately spent time with family. I hung in there, stayed focused during work hours, and fortunately I must have made a good impression in the interview because I passed the conversion! I was so happy about passing that I told everyone and got so many congratulations — that's when I escaped the slump hehe. I think the instability around my job and sense of belonging was the biggest cause of my slump.

 

Starting YouTube

Yep.. I started YouTube. The beginning was actually really casual. I posted a time-lapse of myself working from home on my Instagram story, and my friends were like "YouTube vibes?! Go for it~!" so I was like hmm.. should I actually try?! And I boldly started in September lolol

www.youtube.com/c/%EC%9F%88%EB%AF%B8JYAMI

 

쟈미 JYAMI

🌱Daily life of JYAMI, a junior backend developer🌱 I already have a blog to maintain, and now YouTube too, ta-da! Can I really do this? ㅇㅂㅇ

www.youtube.com

But as the conversion interview got closer and I got busier, my upload frequency slowed down in November and December — but ohh,,, amazingly, a lot of people have been showing love (888 subscribers as of now!!). Looking at the link thumbnail above.. I just threw together the thumbnail and background, so I need to change it to something more YouTube-appropriate, hehe. But it's not important so let's procrastinate on that. Personally, what I liked about filming YouTube was that when I film "code with me" or "study with me" videos, I'm sort of forced to study lolol Nice... b

+ (January 1, 2020) A junior drew some art for me a while back, so I changed my profile picture >.0

 

Challenge Semester Project for Graduation

This retrospective has a lot of foreshadowing, it turns out. I mentioned how tough it is to do school projects while working at a company, and sure enough, during this contract period I was also doing a school project lolol The reason things turned out this way is... well, COVID.

When I applied for the challenge semester, I had 6 credits of major courses left, and I thought COVID would calm down in the second half of the year and school would go back to in-person classes. So I figured if I was juggling work and school, I'd never be able to attend in-person classes, and that's why I chose the challenge semester system — where you set up your own project and complete it within the semester. (So after work I'd be developing this..ㅠ So exhausting... I should've done this during all of August instead of playing League lol) But what I regretted was that if I'd known COVID would get this bad, classes would've been online anyway, so I could've just taken regular courses and passed as long as I didn't fail, right? lol. That way I could've focused more on work!

The challenge semester project I chose was an expanded version of the Ewha Dongsan Committers I mentioned above — I built a developer community for Ewha students. I did both backend and frontend development with Spring and React, and deployed on Heroku, but the server is currently down because I found some bugs.

Currently, the commit history fetching work is implemented as an API even though it should be a batch job, so it needs to be fixed. I also found an error in the error handling part due to my lack of familiarity with Spring Security right before deployment. And the frontend was, well... coded in a very hackathon-style way that I'm not happy with, so I didn't deploy it for actual users. I've only gotten beta version feedback from people around me, and hmm.. I hope I can fix it up and actually deploy it by February next year lolol

This project earned me 6 major credits, and I was able to fulfill all 140 credits required for graduation. So my final university GPA ended up at 3.85 on a 4.3 scale / 4.03 on a 4.5 scale. Since I basically took pass/fail courses for both semesters of my senior year because of work, my GPA was essentially finalized during junior year.

But there was one more obstacle left for me...

 

Ended Up Just Completing Coursework...lol Graduation Is Next Year lolol Let's at Least Take Some Photos

Yep... I had considered early graduation, but I couldn't even graduate on time and ended up just completing my coursework without officially graduating. The reason is TOEIC lol. My school's CS department graduation requirements include scoring over 700 on the TOEIC. But haha.. I always pushed English to the very last priority, so it kept getting pushed behind work + various school projects + dev studying, and I never studied for the TOEIC.

I took the TOEIC once without studying at all, hoping for the best, but I didn't hit 700 ㅠ So I ended up just completing coursework without graduating. Assuming I pass the TOEIC, I'll probably officially graduate in August 2021. I hope COVID calms down by then so I can actually attend the graduation ceremony!!

So this year I took graduation snap photos with my close classmates, and it was such a great memory :) Thank you to my CS crew who got me through 4 years of college

 

Wrapping Up

My 2020 retrospective had some darker parts compared to my 2019 one. The 2019 retro was nothing but bright and grateful, but this year I didn't want to only write things that looked rosy. 

Now I'm about to start 2021 as a real junior developer. Something that Pru-nim and Eun-nim — for whom I'm always grateful — said sticks with me: "Study hard for three years." Next year I really need to read more books... Just the things I feel lacking in right now — design patterns, networking, threads, databases — ugh, there's so much.

A senior developer on my team mentioned that when they were a junior, they read two books a month — and I thought, no wonder they perform at this level now with that kind of studying. I'm surrounded by so many incredible people right now, so I need to keep up to adapt to our messaging team +_+. Studying consistently is my goal for next year. 

Fighting :) 

ps. Next year's retrospective — I'll definitely write it on the 30th, not the 31st..

+ (Past midnight into '21) KakaoTalk didn't crash this year..b Our team is so cool

2019년 8월부터 2020년 8월까지 1년간의 DSC 활동이 끝났다.

사실 진작 활동을 정리해서 써야지 했는데, 미루다 보니 어느새 10월이다ㅋㅋㅋ이전에 회고록에서 DSC 활동에 대해 쓰긴 했었는데, 아무래도 조금 요약한 감이 있다.

jyami.tistory.com/40?category=865823

 

2019년 회고록

대학교 처음 들어왔을 때만 해도 일 년이 이렇게 짧진 않았는데 점점 일 년이 빠르게 흘러가는 것 같다. 매년 다이어리 사고 꾸준히 안 쓰는 작심삼일은 똑같으니까 1년에 한 번인 회고록이라도

jyami.tistory.com

1년간의 활동을 지금부터 회고해보자.

 

지원과 합격

우연히 지난 스마일게이트 윈터캠프때의 인연으로 알게된 오빠가 DSC라는 프로그램을 소개해주면서 알게되었다. 근데 마감일이 당일이었는데 어떻게 호다닥 써서 준비했던게 합격을 하게되었다.

합격까지의 과정은 1. 서류제출 2. 행아웃 인터뷰 이렇게 두개였는데, 지금의 절차는 하나 더 추가되었다고 한다.

1. 서류제출

문항은 리더십/입팩트와 개발 경험에 대한 질문으로 이루어져있었다.

리더십 질문

• 본인을 소개할 수 있는 영상을 유튜브에 업로드
• 개발 프로젝트에서 리더를 한 경험에 대한 질문
• Google Community program 참여 경험에 대한 질문
• 발표 경험에 대한 질문 : 대상자, 주제, 이벤트, 인원수
• 누군가를 가르친 트레이닝 경험에 대한 질문 : 대상자, 주제, 인원수

리더십 질문으로는 아래와 같았는데, 3번을 제외하고 모든 문항을 작성했었다. (당시에는 GDG의 존재도 몰랐었다.) 문항이 너무 많았고, 글자수 제한도 없다보니 모든 문항을 잘 작성하려 하기보다는 내가 한 경험으로 내 장점을 어필하면서 자세히 풀어서 썼다.

이번 리드지원, 혹은 여러 통로를 이용해서 나한테 조언을 얻고자 하는 사람들에게 항상 하는 말인데, 내가 단점이 되는 부분은 굳이 먼저 쓸 필요가 없다고 생각한다. Why Not? 그게 단점이야? 라는 태도로 주구 장창 나는 장점만 말하는 편이다ㅋㅋㅋ

그래서 내가 구글 커뮤니티와 연관이 많다는 점 보다는 나는 이렇게 사람들앞에서 말도 해보고, 누군가를 가르치는 것도 플젝 경험도 많은사람인데 이 활동은 분명히 나랑 핏이 맞을꺼야라는 뉘양스로 자신있게 지원서를 작성했다.

참고로 1번에서 만든 내 소개 영상은 내 유튜브 채널에 비공개 영상으로 저장되어있다ㅋㅋㅋㅋ : 아무에게도 보여주지 않을테야...
당일에 지원서 작성 + 영상 업로드 다 해야했다보니 편집 하나도 없이 그냥 캠켜서 찍은 영상이었는데 지금보면 쪽팔리다...ㅋㅋㅋㅋ
지금 하라고 하면 옛날에 했던 멋사 영상팀 경력을 살려서 짐벨도 대여하고 카메라 워킹 시나리오도 짜서 인생 영상으로 한번 만들어보고싶다..

개발 경험 질문

• github 프로필 링크
• 안드로이드 앱 개발 경험과 프로젝트 설명
• 웹 개발 경험과 프로젝트 설명
• 클라우드 개발 경험과 프로젝트 설명
• 머신러닝 개발 경험과 프로젝트 설명

개발 경험도 마찬가지로 내가 모르는 부분은 진솔하게 모른다 쓰고 내가 잘하는 부분만 잘 녹여내서 썼었다. 그때 클라우드 경험으로 AWS이야기를 했는데ㅋㅋㅋ 이런..ㅎㅎ 아무래도 DSC 활동을 하면 관련 기술에 대한 뉴스레터 수신, 각종 기술에 대한 학습 영상을 제공받게 되는데, 어느 분야에 대한 관심이 있는지를 보려고 넣은 질문인 것 같다.

당시에는 개발 능력이 엄청 중요하지 않을까라고 생각해서 개발 능력만 엄청 어필해서 썼던 기억이 난다. 근데 1년이 지나고난 지금 실제 활동은 리더십이 훨씬 중요했다. 그래서 지금 다시 리드 지원을 한다고 하면 리더십 부분에 좀 더 초점을 맞춰서 지원서를 작성할 것 같다. 개발 경험의 경우엔 어차피 깃허브에 선호하는 언어, 프레임워크에 대한 정보가 나와있기 때문에 그사람이 개발을 어떻게 대하는지에 대한 태도가 있기때문이다.

 

2. 행아웃 인터뷰

Google Korea DevRel 팀과의 1:1 인터뷰를 진행한다. 당시 꿈에 부풀어서 이것도 하고싶고 저것도 하고싶다고 열심히 말했던 기억이 아직도난다. 

인터뷰는 주로 기술질문보다는 리더십 + 본인의 경험에 대한 질문을 물어봤었다. 1년이 지나서 기억은 잘 안나지만 당시 내가 어떤걸 컨트리 뷰션을 하고싶냐는 말에 대답했던 뉘양스는 어렴풋하게 기억이난다.

저는 컴퓨터공학과 소속인데, 저는 외부 활동을 통해 여러 프로젝트를 하면서 내가 어떤걸 좋아하는구나를 알게되었고, 계속해서 공부를 해왔다.
근데 주변에 많은 친구들을 보면 컴퓨터공학과임에도 불구하고 학교 수업에만 열중하다보니 경험이 없어 본인이 어떤 분야를 좋아하는지를 모르는 경우가 많다. 나는 학생들이 스스로가 직접 만들어보는 경험이 중요하다 생각하고 그 경험들이 모여서 자신의 진로를 고민할 수 있는 기회가 많아진다고 생각한다. 그래서 우리학교 학생들에게 DSC가 좀 더 많은 개발 경험을 접할 수 있는 기회가 될거라고 확신한다.

그래서 나는 내 DSC 활동에 멤버들이 1년동안 공을 들여서 본인의 프로젝트를 완성하는 경험을 할 수 있도록 활동을 했었다.

외에도 블로깅에 대해서 여쭤보셨는데, 내가 하는 활동을 블로그를 통해 전파하고싶다는 말씀을 드렸고 실제로 우리 활동에서는 팀블로그를 이용을 했으며, 내 블로그 곳곳에 DSC의 향기가 있다ㅋㅋㅋ
와.. 그때만해도 블로그에 글이 3개인가 그랬는데..ㅋㅋ 1년이 지난 지금 발전한 모습이라서 다행이다!! 후후

 

3. 합격 메일

면접을 마치고 먼저 Google Korea에서 연락이 온 후에 합격 메일을 공식적으로 받게되었다 :) 
당시 영어로 메일 받았다고 엄청 신기해 하면서 하나하나 번역하면서 꼼꼼히 읽었었는데ㅎㅎ 이젠 영어메일 쯤이야!!! 아직도 가뿐하지 않다

 

4. 2020 리드 지원때 온 연락

이번 리드 지원때 여러 질문을 받았었는데, 한 분이 기억에 남는다. 당시 나의 개발 수준과 상황을 여쭤보는 질문이었는데, 프로젝트 경험 깃허브 프로필 등 어느정도로 관리해야하는지를 여쭤보셨다.

여기에 대해서는 리드마다 모두 스펙이 다르고 모두 좋아하는 분야가 다르기 때문에 모두가 같은 포폴을 가질 수 없고 자신이 하고싶은 일들을 어필하는게 중요할 것 같다는 답변을 드렸다. 실제로 우리 리드들 같은 경우도 비전공자도 있었고 서로 관심사도 모두 달랐다. 내가 백엔드 몰빵으로 관심이 있었다면, 정동님은 처음에는 ML에 관심있다가 DSC 활동 후에 Cloud 몰빵 캐가 되었다. 

리드 활동 같은 경우는 일단 누군가에게 기술 교육을 받는 활동이 아니고, 본인이 개발 관련 활동을 만들어 나가야 한다. 그래서 리드 지원할 때 어필해야하는 점은 본인이 이 활동으로 어떤 사람들을 만나고, 어떻게 컨트리뷰션을 하고 싶다라는 계획성이 보이는게 중요하다.

어찌됐든 리드활동은 누군가가 시켜서하는게 하는 것보단 스스로 나서서 해야하는 일이기 때문에, 내가 공부하는 기술의 대단함보다는 나의 주체성을 어필하는 것이 더 도움이 된다고 생각한다. 사실 그 기술의 대단함은 이미 Googler가 갖고있는 것이니 대항생인 우리들은 우리의 열정을 보여주자!!🔥🔥

 

첫 시작 : Google Korea Onboarding

나의 가장 첫 활동은 온보딩 프로그램이었다. 지금은 코로나 때문에 온보딩도 행아웃으로 진행한다고 한다. 그치만 당시에는 구글 코리아 오피스에 가서 DSC 활동에 대한 정확한 소개를 받고, 여러 지역에 있는 리드들과의 만남을 할 수 있었다. 아래 엄청 자세하게 써두어서 링크를 첨부한다

jyami.tistory.com/7?category=854536

 

[DSC Lead] - google Korea 방문기 & DSC Lead onBoarding

GDG, 즉 Google Developer Groups에 대해서 아시나요? DSC를 간단하게 말하자면 GDG의 대학생 버전이라고 할 수 있을 것 같습니다!! onboarding에서 듣기로는 구글은 개발자와 커뮤니케이션하는 것을 중요시 �

jyami.tistory.com

아무래도 내가 활동한 기수가 1기이다 보니, 각종 DSC Korea 페이스북, 슬랙, 카카오톡을 파면서 하나의 커뮤니티의 시작을 다들 준비해갔다. 아무런 체계 없이 백지에서 모든걸 창조해야하다보니 초반에 다들 힘들어했었고, 본인이 잘 하고있는건지 어떤걸 해야하는지 대한 고민이 많았었다. 

그래서 온보딩 이후로 1~2달 후인가 우리 리드들끼리 2주에 한번 행아웃 화상회의를 통해 각 학교에서 어떻게 활동하는 중인지 공유하는 시간을 가졌다. 그래서 상대 학교에서 반응이 좋았던 행사는 우리 학교에서도 도입하고 그랬었다.

 

개강과 함께 DSC Ewha 시작

혼자 모든걸 한다는게 쉬운 일이 아니었다. 포스터 제작 (당시 중국해커톤을 하고있었는데, 그때 시상식때 나는 DSC Ewha 포스터 제작하고 있었다), 홍보 문구 작성, 커리큘럼 구체화, 면접, 선발 모든 과정을 혼자 했었다.

나는 모든 멤버를 선발한 후에 그 멤버들 안에서 코어 멤버(운영진 멤버)를 뽑았었는데, 지금 생각하면 먼저 코어 멤버를 뽑고 같이 어떤 활동을 할지 의논해 나가는게 더 좋았겠다라는 생각이 든다.

면접의 경우엔 개인 지원서에 특화하여 질문을 했었다. 어느 조직이든 마찬가지이지만 나는 면접은 이사람이 왜 우리 조직에 들어오고 싶은지에 대한 이유가 가장 중요하다 본다. 

• 여러 개발 동아리가 있는데, 굳이 DSC Ewha를 해야하는 이유?
• 프로젝트 경험을 원하는 거라면 DSC가 아니어도 되는데 왜 굳이?
• 1년 후 기대하는 본인의 모습
• github 관리여부

위 네개 질문을 주로 물어봤었다. 잘못한 일중에 하나가 지원자 22명중 22명을 전부 뽑았었다. 당시 생각은 본인이 지원하겠다고 한 일에 책임을 느낄 것이라 생각했으며 내가 생각한 선발 인원 수와 맞아 떨어졌기 때문이다. 하지만 이때의 판단은 후반부 이탈률이 높아진 것과 인과를 가진 것 같아 후회하는 일 중 하나이다.

 

DSC Ewha 멤버들과의 1년

사실 대부분의 DSC 활동이 19년도에 몰려있다. 코로나로 인해 20년도 활동이 애매모호해졌고 다들 온라인으로 하다보니 동기부여가 잘 안되는 상황이었다. 만약 20년도에 코로나가 아니었다면.. 좀 더 많은 활동을 멤버들과 할 수 있었을까 하는 아쉬움이 있다.

아무래도 대학이다보니 동아리 형식으로 활동을 했었다. 우리의 주된 활동은 세미나 + 1년 팀프로젝트였다. 19년 2학기에는 정기모임을 가졌고 이 정기모임에서는 팀별 시간 + 세미나 시간을 가졌다. 반면 코로나가 시작되고 나서는 팀별 시간은 팀 자율에 맞춰서, 세미나는 팀블로그에 업로드 하는 방식으로 변경하였다.

 

1. 팀 프로젝트

이 DSC 활동이 내가 주도해서 하나의 강의를 하는 형식이 되기를 원치 않았다. 내가 SpringBoot 강의를 한다면 그만큼 멤버들이 체계적으로 공통적인 기술 하나에 집중한다는 장점이 있을 수 있지만, 후에 프로젝트를 할 때 여러 기술을 사용해 보지 못할 것이라고 생각했다. 그리고 애초에 그런 방식이라면 웹 개발 동아리를 하나 만들지 왜 굳이 DSC를 하겠는가. 그래서 나는 멤버들이 자유롭게 원하는 기술을 이용해서 프로젝트를 진행하도록 했다.

나는 당시 운영만으로도 힘들어서 나는 팀프로젝트에 참여하지 않겠다 했는데 옳은 선택이었다. 3학년 1학기 때 대외활동을 전부 관뒀음에도 불구하고 3-2에 졸업프로젝트 + DSC Ewha 활동 + 스터디 자바봄 + 학업의 문제로 프로젝트를 할만한 여력이 안되었기 때문이다. 그리고 4-1에 네이버 인턴십까지 했었으니 집중하기 정말 어려웠겠다는 생각이 든다.

팀 프로젝트는 모임 첫날 아이디어 스피칭 후 원하는 아이디어로 팀 구성을 하게 했다. 이후 매주 모임시간마다 팀별 회의를 진행하고, 각 팀의 진행상황은 팀블로그에 돌아가면서 작성하게 했었다. 그러고 각 분기에 한번씩 (3개월에 한번) 각 팀별로 발표를 진행했는데, 코로나로 인해 2학기에만 대면으로 발표하고 나머지 겨울방학 / 1학기 / 여름방학에는 모두 행아웃으로 진행할 수 밖에 없었다.

나는 기술적으로 도움을 준 부분이 거의 없었다. 멤버들이 주체적으로 팀원들끼리 android, react 스터디를 해서 나온 결과물이 이 활동의 프로젝트들이었다. 분기발표 때 멤버들이 하는 발표를 보면서, 디자인부터 백엔드 설계, 프론트엔드 통신, 모델 학습 데이터 수집까지 차근차근 진행했던 모습을 보고 감탄했었다. 프로젝트 기획부터 완성까지의 과정을 통해 멤버들이 본인의 커리어에 도움이 되는 프로젝트가 되었으면 좋겠다. 

총 4개 프로젝트가 완성의 단계까지 갔으며, 그 중 핸들랭 팀의 프로젝트는 DSC Solution Challenge에 제출했다. 좋은 결과가 있으면 좋았겠지만 아쉽게도 DSC Korea에서는 순천향대 팀이 수상하였다. 소스코드는 깃허브를(github.com/DSC-Ewha) 이용해 모아두고 다음 리드에게 인수인계를 완료했다.

 

2. 미니 세미나

개발에도 다양한 분야가 있다. 많은 학생들이 하는 고민이 본인이 어떤 걸 좋아하는지 모른다는 것이었다. 그 이유중에 하나는 일단 여러 기술 및 분야의 존재를 모른다. 학습 방식 및 툴 조차도 모른다. 따라서 기술의 존재만이라도 툴의 이름이라도 알고 넓고 얕게 지식을 접할 수 있는 경로가 무엇이 있을까라는 생각을 했다.

그래서 나는 멤버들이 서로 본인들이 주로 사용하는 기술 혹은, 위 팀프로젝트에서 사용한 기술에 대해 개인이 공부한 내용을 공유하는 시간을 만들었다. 팀 프로젝트가 제각기 다른 기술을 사용해서 진행이 되었고, 공통 관심사를 갖는 멤버들이 있다면 더 이야기 할 수 있는 수단이 될 것 같았기 때문이다.

그래서 매주 모임을 가질 때 멤버별로 돌아가면서 약 15분간 미니세미나를 진행했고, 처음에는 그 세미나에 대한 간단 QnA 형식으로 DSC Ewha 페이스북 페이지(www.facebook.com/DSCEwha) 게시글을 채워나갔다. 

그러나 나중에 코로나로 인해 온라인으로 팀 프로젝트를 진행하고 모임을 진행하지 않게되면서 미니세미나도 온라인으로하게 되었다. 팀블로그에 영상을 찍어서 올리는 방식으로 변경했는데, 나도 처음 접하는 주제들이 많았다. 이 활동도 코로나로 무산되면 어쩌지 했었는데, 멤버들이 책임감을 갖고 다들 업로드 해주어서 마무리 할 수 있었다.

활동을 하면서 좋은 점만 있는건 아니었다. 대면으로 활동할 때는 매주 모임을 준비하고, 다른 DSC 행사 준비와도 병행을 해야하다보니 신경써야할 것들이 많았다. 그러다보니 3학년 2학기에 커뮤니티 활동으로 인해 개발공부를 많이 못했던 것이 아쉬웠다. 반면 온라인으로 활동할 때는 멤버들의 이탈도 발생했고, 프리라이딩이 일어나기도 했었는데 여기에서 내 능력에 되게 회의감을 느꼈었다. 이때 아무래도 온라인으로 팀플을 하다보니 리드로써 어느정도로 팀을 케어해주어야했는데라는 후회가 있다.

이렇게 부족한 리드임에도 불구하고 프로젝트, 세미나 모든 활동을 적극적으로 참가해준 멤버들이 있기에 활동을 잘 마무리하고 인수인계까지 잘 할 수 있었다.

와... 여기까지 10월에 쓰고 다시 마무리하려고 텍스트창을 킨게 12월이라니ㅋㅋㅋ 그래도 마무리 짓는거에 의의를 두자!!

DSC Ewha에서 진행했던 행사들

1. DSC Ewha Open Codelab 모.같.코

행사를 하게 된 계기

기초 SW 교육으로 코딩을 배워본 친구들은 많지만 그것은 결국 언어레벨이다. 교양 수업에서 배운 프로그래밍 언어를 가지고 어떤 일들을 하는지 코딩에 관심있는 벗들에게 알려주기 위한 흥미위주의 코딩세션을 진행하였다. 구글 코드랩이 튜토리얼식의 입문자를 위한 설명이 잘 되어있다고 판단하였기 때문에 이 행사를 기획하게 되었고, 이화여대 내 DSC Ewha의 입지도 키울 수 있는 큰 이벤트라고 생각했다.

행사 준비 과정

준비과정에서 DSC Ewha 멤버들이 튜터로 참여하므로써 혼자 모든걸 하지 않으려했었고, 다행이도 많은 친구들이 같이 해주었어서 우리도 재미있게 행사를 준비했던 기억이난다. 그리고 나는 리드로서 행사에 필요한 비용마련을 위해 이화여대 소프트웨어 중심대학 사업단쪽과 컨텍을 하는등.. 사실상 개발자의 역할보다는 관리자의 역할로서 총괄을 하였던 기억이 난다.

행사 진행

행사는 우리학교 기준 한교시동안 진행하였다. 총 1시간 15분 중 5분은 DSC Ewha를 설명하고 DSC Korea를 시간하는 OT시간, 60분은 튜터들과 코드랩을 같이 실습하는시간, 10분간은 설문조사를 요청드리는 시간으로 타임라인을 잡았다. 

코드랩을 진행할 때는 메인튜터, 서브튜터로 나누었으며 메인튜터가 앞에서 코드랩을 라이브로 진행하고 서브튜터들은 실제 학생들이 모르는 부분이 생길때 그부분에 대한 추가 설명이나 도움을 줄수있도록 하였다.

행사는 총 2회 (1회에 세션 2개씩 총 4개 세션) 진행했으며 내 기억상 10월과 12월 두번이었다. 심지어 12월에는 여러 교수님들도 들어와서 참관했던 기억이...ㅎㅎ 행사진행후 설문조사에서의 의견도 전부 긍정적이었어서 다들 뿌듯해했던 기억이다. 원래는 올해 초 내가 리드를 할 때만해도 계속 주최를 할 예정이었지만 코로나로인해 다들 온라인에 적응을 못한상황이라 전부 취소하고 이후 계획을 세우지 못한 것이 아쉽다.

 

2. 이화동산 커미터스

DSC Ewha 내부에서 진행했던 행사이다. 겨울방학 + 1학기 개강 일시에 걸쳐서 70일 동안 일일커밋 그룹을 진행하였다. 기존에 DSC HUFS에서 진행했던 활동방식을 참고했으며, GDG 판교에서 했던 행사인 잔디콘을 참고해서 구체적인 방향을 정했었다. 그렇게 우리 그룹은 총 9명이 진행했으며 70일 전부를 참여한 사람은 7명이었다. 

매일매일 일일커밋이 일어나는 걸 서로 관제하기위해 slack의 github 플러그인을 이용해 각자의 레포지토리에 변경이 있으면 알림이오도록 했다. 물론 커밋을 하지 않았을때 벌금도 정했었다. 

그리고 나는 개인적으로 GDG 판교의 정원사들에서 만든 커밋관리툴을 이화동산 커미터스 용도로 다시 재 배포하고, 커밋기록을 수집하는 사이트도 만들었는데, 관련 코드는 https://github.com/mjung1798/ewha-daily-commit 링크에 저장되어있다,

원래는 70일이 끝나는 마지막날인 3월 28일에 학교에서 이화잔디콘이라는 네이밍의 컨퍼런스를 열어 우리가 했던 일일커밋활동에 대한 기록을 불특정다수의 동문들에게 발표하려했으나 코로나로 인해 역시 무산되었던 점이 아쉬웠다.

위와같은 관리수단으로 우리는 모두 1일 1커밋을 실천하려고 하는 커밋그룹을 진행했었고, 혼자서는 꾸준히 하기 힘들었을텐데, 이런식으로 같이 하다보니 나에게도 도움이 많이되었었다.

이화에서 했던 활동 모두 내가 기획하고 관리해서 좋은 반응을 이끌어냈으나, 모두 N회 더 하고싶다는 욕심이있었는데 20년도 이래저래 정신없는 상황으로인해 주된 활동이 19년도에만 있었어서 아쉬운 점이 있다.

개인적으로 모같코를 진행할 때는 내가 공부하고 싶은 기술에 대한 깊이나 탐구보다는 동아리를 알리기위한 이벤트성으로 코딩에 흥미를 붙이기 위한 목적만 신경을 썼었다. 그러다보니 사실 기술적으로는 나에게 도움이되는 내용보다는 입문자를 위한 내용이 앞썼다. (아무래도 불특정 다수를 대상으로하는 행사들은 입문자를 대상으로할 때 가장 많은 인원을 모을 수 있기 때문) 그러다보니 이 행사를 준비할 때는 나의 개발자 커리어적으로 기술적인 향상은 없을 수 밖에없었고, DSC Ewha를 할 때 행사 및 동아리를 준비 운영하는 리소스가 나의 기술적 전문성 향상을 위해 투자하는 리소스보다 훨씬 컷던게 아쉬움이 남았다.

하지만 커미터스 활동은 나또한 1일 1커밋을 진행하면서 꾸준히 개발공부를 하는 습관을 들이고, 실제로 개발공부를 통해 기술적으로 성장을 할 수 있는 시간을 오롯히 나만을 위해 마련했기 때문에 나도 만족도가 높았던 활동이다.

 

구글 커뮤니티와 연계하여 했던 나의 활동

DSC 활동을 하면서 Google Korea Developer Relation 팀과의 커뮤니케이션은 필수적이었다. DSC Korea는 2019년 처음 진행하기도 했고, DSC 외의 구글에서 지원하는 다른 커뮤니티와의 협업도있었기 때문이다. 그러다보니 자연스럽게 GDG, WTM, GDE 분들이 주최하는 행사도 참여하고 같이 협업하기도 했었다.

1. DevFest Seoul 2019 Staff 참여

jyami.tistory.com/24?category=854536

 

DevFest Seoul 2019 Staff 후기

DevFest Campus Korea 2019 준비로 교수님과 면담하고 다같이 행아웃 회의하고 그랬는데 정작 제가 DevFest를 안가봐서 이번에 DevFest Seoul 스탭으로 지원을 하게되었습니다! 사실 너무 속셈이 보이는 지원

jyami.tistory.com

가장 먼저 GDG Seoul에서 진행했던 DevFest에 스태프로 참여하면서 어떤식으로 행사를 진행하는지를 살펴보고, 이때부터 내가 만들 DSC 행사들을 기획하고 생각하게 되었다. 자세한 후기는 위에 링크에 정리해두었다. ( 평소에 하나하나 잘 정리해뒀어야했는데..ㅎㅎ )

2. google cloud summit 2019 참여

jyami.tistory.com/25?category=854536

 

2019 google cloud summit 후기

11월 6일 코엑스에서 Google Cloud Summit이 열렸는데요. DSC Korea 소속으로 티켓을 받아서 갔다왔습니다. 원래는 AWS만 사용하는 유저였는데, DSC 활동을 하면서 google product에 대한 얘기를 많이 듣게 되다

jyami.tistory.com

구글 코리아 데브렐측에서 DSC Korea 리드들에게 참가권을 주어서 참석하게되었다. 이전까지는 사실 AWS만 사용하고 GCP는 잘 사용안했었는데ㅋㅋ 이때부터 GCP를 조금씩 사용해봤던 것 같다. 다행히도 이때 후기를 적어두었네

3. DevFest on Campus 2019 기획단

jyami.tistory.com/26?category=854536

 

DevFest on Campus 2019 - 기획단의 후기!

1. 인트로 2019년 11월 16일 DevFest on Campus 2019가 드디어 끝났다!!!! https://festa.io/events/654/ DevFest on Campus 2019 | Festa! Festa에서 당신이 찾는 이벤트를 만나보세요. festa.io GDG Campus에..

jyami.tistory.com

GDG Campus Korea 측에서 DSC Korea 리드들과의 DevFest를 같이 만들자는 요청이와서 하게되었다. 어쩌다보니 우리학교에서 공간 대여를 하게되었다보니 더 적극적으로 이 행사에 참여했었다.

4. Google Cloud OnBoard 2019 참여

jyami.tistory.com/32?category=854536

 

Google Cloud OnBoard 후기 & 정리본 링크

2019년 11월 26일 세종대학교에서 열린 Google Cloud OnBoard에 다녀왔습니다. 11월 초 summit에 다녀오긴 했는데 실제로 핸즈온 세션이 열린다고 해서 갔다왔습니다. https://inthecloud.withgoogle.com/onboard-..

jyami.tistory.com

 

핸즈온 세션에 기대해서 개인적으로 갔다왔었다. 아무래도 리드로 활동하다보니 여러 행사소식을 빠르게 들을 수 있었고, 이때 학교 수업을 빠지고 가야겠다 결심했던 기억이 난다ㅋㅋ 

 

5. Korea Community Summit 참여

구글 커뮤니티의 모든 오거나이저들이 모여서 회고하는 자리였다. DSC Lead로 참석하였으며, 올해에 대한 회고와 본인 소개, 내년에 대한 계획을 세울 수 있는 자리였다. 많은 GDG, GDE 분을 뵐 수 있었고, 조언을 얻을 수 있었다. 구글 코리아 오피스에서 다양한 액티비티를하면서 많은 분들과 이야기를 주고받을 수 있는 기회가 있었다.

 

6. 2020 HashCode 참가 (DSC Korea 팀)

jyami.tistory.com/52?category=854536

 

HashCode 2020 참가 후기

처음으로 PS 대회에 참가해봤다. DSC Korea 슬랙에서 팀원을 구한다는 얘기를 듣고 참가를 하게 됐는데! 하하 UTC 17:30이라니,, 한국시간으로 오전 2:30부터 6:30까지 였다. 그래서 팀원들끼리 코딩할

jyami.tistory.com

DSC Ewha 친구들과 함께 구글에서하는 팀 알고리즘 대회인 해시코드에 참가했다. 하루를 꼬박 새서 참가했었다. 개인적인 활동이었는데, 앞으로 알고리즘 더 열심히 공부해서 계속해서 참가하고싶다.

7. DSC korea 네트워킹 데이

DSC Korea Lead들끼리 준비했던 행사이다. DSC Korea의 총 12개 학교의 학생들이 모두 모여 레크레이션도 하는 등 네트워킹 행사를 개최했다. 행사를 준비하는 Lead들끼리 장소 대관, 회계, 홍보, 프로그램 구상등 으쌰으쌰하면서 준비했다. 덕분에, DSC 행사중 가장 만족도가 높았던 행사로 피드백을 받았었다. 

행사를 준비할 때 연사자 초청, keynote 준비, 아이스브레이킹 자료 준비, 참가한 멤버들의 그룹 토론 주제 준비, 디자인, 장소섭외 등 정말 많은 부분을 하나하나 준비하면서 리드들끼리 더 돈독해지기도 했다. 이때 구글 데브렐, GDE분들이 많은 도움을 주셨던 기억이난다.

DSC 이름으로 걸고하는 가장 큰 행사였으며, 예산처리, 실제 인원체크, 장소 확인 및 준비 등 작은 이벤트를 하기 위해서도 많은 사람들이 노력이 필요함을 다들 체감했다. 원래는 해커톤도 개최하려 했으나 역시나 코로나-19로 인해 이게 DSC 전체의 마지막 행사가 되어서 아쉬웠다..

 

활동 마무리

활동 막바지 리드들과 함께 활동 후기 릴레이를 작성했다. 작성을하면서 우리 다음으로 활동을 할 리드들이 어떤분들일까 궁금하고, 우리가 아닌 다음 사람들이 할 새로운 활동들이 어떤걸지 설렜었다. 

인수인계

2019-2020 DSC Ewha Lead를 마치고 9월중 인수인계 자료를 만들었다. 이때 인수인계 자료를 만들다보니 그동안의 활동을 정리했었는데. 그렇게 블로그 글을 쓰게되었다ㅋㅋㅋㅋ 그런데 이 글을 지금 마무리 하게 될 줄이야.. 현재 DSC Ewha는 다른 리드가 이어받아 운영을 하고있다. 너무 잘하는 친구이지만 코로나때문에 현재 활동이 어떻게 진행되고있는지는 알지못한다ㅠ

DSC는 기존에 하던 개발 동아리, 개발 대외활동이 아닌 데브렐관련 활동도 하면서 나에게 새로운 경험을 주었기 때문에 잊을 수 없는 활동이다. 이때 만났던 인연들은 아직까지도 다들 연락하고 서로 으쌰으쌰하면서 지내고있다 :)

솔직히 좋은일만 있던건아니다. 커뮤니티 오거나이저로 여러 곳과의 커뮤니케이션 문제, 개발자로서의 개인 계발 부진에 대한 고민 등 힘들었던 점들도 많지만 너무 소중한 인연들을 만날 수 있었고 식견을 넓힐 수 있었던 너무 좋은 경험이었다. 따라서 대학교때 했던 활동중 가장 잘한일이라고 생각하고있다.

My one-year DSC activity from August 2019 to August 2020 has come to an end.

I kept telling myself I should write up a summary of my activities, but I kept putting it off and now it's already October lol. I did write about DSC in a previous retrospective, but it was a bit summarized.

jyami.tistory.com/40?category=865823

 

2019 Retrospective

When I first entered university, a year didn't feel this short, but it seems like each year goes by faster and faster. Since my New Year's resolution to keep a diary consistently never lasts more than three days, at least let me write this once-a-year retrospective

jyami.tistory.com

Let me look back on the past year of activities starting now.

 

Application and Acceptance

I happened to learn about DSC through a connection I made during the previous Smilegate Winter Camp — a senior introduced the program to me. The thing is, the deadline was that very day, but somehow I managed to scramble and put together an application, and I got accepted.

The acceptance process consisted of two steps: 1. Document submission 2. Hangouts interview. I've heard that the current process has one more step added.

1. Document Submission

The questions were about leadership/impact and development experience.

Leadership Questions

• Upload an introductory video of yourself to YouTube
• Questions about your experience leading a development project
• Questions about your experience participating in Google Community programs
• Questions about your presentation experience: audience, topic, event, number of attendees
• Questions about your training experience teaching others: audience, topic, number of attendees

The leadership questions were as listed above, and I filled out all of them except for number 3. (At the time, I didn't even know GDG existed.) There were so many questions and no character limit, so rather than trying to perfectly answer every single one, I focused on highlighting my strengths through my actual experiences and wrote in detail.

This is something I always tell people who come to me for advice, whether it's for lead applications or through other channels — I don't think you need to voluntarily bring up your weaknesses first. Why not? Is that really a weakness? That's the attitude I take, and I just go on and on about my strengths lol

So rather than emphasizing how connected I was to the Google community, I wrote my application with the confident tone of: I've spoken in front of people, I've taught others, I have plenty of project experience, and this program is definitely a great fit for me.

By the way, the introductory video I made for item 1 is saved as a private video on my YouTube channel lol: I'm never showing it to anyone...
Since I had to write the application AND upload the video on the same day, I just turned on my webcam and recorded without any editing — looking at it now is so embarrassing... lol
If I had to do it now, I'd put my old video team experience from LikeLion to use, rent a gimbal, write a camera movement scenario, and make it a masterpiece of a video..

Development Experience Questions

• GitHub profile link
• Android app development experience and project description
• Web development experience and project description
• Cloud development experience and project description
• Machine learning development experience and project description

For the development experience section, I was honest about what I didn't know and focused on showcasing what I was good at. Back then, I talked about AWS for my cloud experience lol... oops haha Since DSC activities include receiving newsletters about related technologies and learning videos on various tech topics, I think this question was meant to gauge what fields applicants are interested in.

At the time, I thought development skills would be super important, so I remember heavily emphasizing only my dev skills. But after a year, the actual activities showed that leadership was far more important. So if I were to apply for lead again now, I'd focus more on the leadership section. As for development experience, your preferred languages and frameworks are already visible on your GitHub profile anyway, so it's really about your attitude toward development.

 

2. Hangouts Interview

You do a 1:1 interview with the Google Korea DevRel team. I still remember being so excited and enthusiastically saying I wanted to do this and that. 

The interview mainly asked about leadership and personal experiences rather than technical questions. It's been a year so I don't remember well, but I vaguely recall the gist of what I said when asked what kind of contribution I wanted to make.

I'm in the Computer Science department, and through various extracurricular activities and projects, I discovered what I enjoy and have been continuously studying.
But when I look at many of my peers, even though they're in Computer Science, they only focus on coursework and lack experience, so they often don't know what field they actually enjoy. I believe it's important for students to have hands-on experience building things themselves, and I think those accumulated experiences create more opportunities to explore their career paths. That's why I'm confident that DSC can be an opportunity for students at our university to gain more development experience.

So throughout my DSC activities, I focused on enabling members to spend a year dedicated to completing their own projects.

They also asked me about blogging, and I mentioned that I wanted to spread the word about our activities through a blog. In practice, we actually used a team blog, and you can find traces of DSC scattered throughout my blog lol
Wow... back then I only had like 3 posts on my blog... lol I'm glad I've come a long way after a year!! Hehe

 

3. Acceptance Email

After the interview, I first got a call from Google Korea, and then officially received the acceptance email :) 
At the time, I was so amazed to receive an email in English that I translated it word by word and read it carefully haha. Now English emails are no big deal!!! Actually, they're still not easy

 

4. Messages I Received During the 2020 Lead Application Period

During this round of lead applications, I received various questions from people. One person particularly stands out in my memory. They asked about my development level and situation at the time — things like how much I managed my project experience, GitHub profile, etc.

My response was that every lead has different specs and different fields they enjoy, so not everyone can have the same portfolio — what's important is highlighting what you want to do. In fact, among our leads, there were non-CS majors too, and everyone had different interests. While I was all-in on backend, Jeongdong initially had interest in ML but became a Cloud all-in player after his DSC activities. 

As for lead activities, it's not something where you receive technical training from someone — you have to create development-related activities on your own. So when applying for lead, what's important to convey is your plan: what kind of people you want to meet through this program and how you want to contribute.

At the end of the day, being a lead is about taking initiative rather than being told what to do, so I think showcasing your proactivity is more helpful than showing off how impressive your technical skills are. After all, Googlers already have that technical prowess, so as university students, let's show them our passion!!🔥🔥

 

The Beginning: Google Korea Onboarding

My very first activity was the onboarding program. Nowadays, onboarding is also done via Hangouts because of COVID. But at the time, we got to visit the Google Korea office, receive a proper introduction to DSC activities, and meet leads from different regions. I wrote about it in great detail before, so I'll attach the link below.

jyami.tistory.com/7?category=854536

 

[DSC Lead] - Google Korea Visit & DSC Lead Onboarding

Do you know about GDG, a.k.a. Google Developer Groups? To put it simply, DSC is like the university student version of GDG!! From what I heard at the onboarding, Google values communicating with developers

jyami.tistory.com

Since I was part of the very first cohort, we were setting up various DSC Korea Facebook pages, Slack channels, and KakaoTalk groups from scratch, preparing the foundation of a new community. Having to create everything from a blank slate with no established structure made things tough for everyone in the beginning — we all had a lot of concerns about whether we were doing it right and what we should be doing. 

So about one to two months after the onboarding, we leads started having bi-weekly Hangouts video meetings to share how activities were going at each university. Events that got a good response at other schools would then be adopted at ours too.

 

DSC Ewha Begins with the New Semester

Doing everything alone was no easy task. Poster design (at the time I was participating in a hackathon in China, and during the awards ceremony I was working on the DSC Ewha poster), writing promotional copy, finalizing the curriculum, interviews, selection — I did every step by myself.

I selected all members first and then picked core members (executive team) from within the group. Looking back, I think it would have been better to recruit core members first and discuss what activities to do together.

For the interviews, I tailored questions to each applicant's individual application. Like any organization, I believe the most important thing in an interview is understanding why this person wants to join our organization. 

• There are many developer clubs out there — why specifically DSC Ewha?
• If you want project experience, you don't need DSC for that — so why here?
• What do you hope to look like one year from now?
• Whether they maintain their GitHub

These were the four main questions I asked. One mistake I made was accepting all 22 out of 22 applicants. My thinking at the time was that people would feel responsible for something they applied to on their own, and the number happened to match what I had in mind. However, in hindsight, this decision seems to have been causally related to the high dropout rate later on, which is one of my regrets.

 

A Year with DSC Ewha Members

In reality, most of the DSC activities were concentrated in 2019. COVID made the 2020 activities ambiguous, and with everyone working online, it was hard to stay motivated. If it weren't for COVID in 2020... I wonder if we could have done so much more with the members.

Since we were at a university, we ran things in a club format. Our main activities were seminars + a year-long team project. In the second semester of 2019, we held regular meetups that included team time + seminar time. After COVID hit, team time was left up to each team's discretion, and seminars shifted to being uploaded on the team blog.

 

1. Team Projects

I didn't want DSC to become a format where I just led a single course. If I taught a Spring Boot class, members could focus systematically on one common technology, but I thought they wouldn't get to try various technologies when it came time for projects. And honestly, if that's all it was going to be, why bother with DSC when you could just start a web development club? So I let members freely choose whatever technologies they wanted for their projects.

At the time, I said I wouldn't participate in team projects since managing everything was already overwhelming — and it was the right call. Even though I quit all extracurricular activities in my junior year first semester, in the second semester I was juggling a capstone project + DSC Ewha activities + Java Spring study group + coursework, so I really didn't have the bandwidth. And then I did a Naver internship in my senior year first semester, so it would have been truly impossible to focus.

For team projects, on the first meeting day members pitched ideas and then formed teams around the ones they liked. After that, they had team meetings at every weekly gathering, and each team took turns writing about their progress on the team blog. We also had quarterly presentations (once every 3 months) from each team, but due to COVID, only the second semester presentations were in-person — the winter break, first semester, and summer break presentations all had to be done via Hangouts.

I barely provided any technical help. The members independently studied Android and React within their teams, and the projects from this program were the result of their self-driven efforts. Watching their quarterly presentations, I was impressed seeing them work through everything step by step — from design to backend architecture, frontend communication, to model training and data collection. I hope that the experience of going from project planning to completion became something that helped each member's career. 

A total of 4 projects made it to the completion stage, and among them, Team Handleang's project was submitted to the DSC Solution Challenge. It would have been great to get good results, but unfortunately the winning team from DSC Korea was from Soonchunhyang University. The source code is collected on GitHub (github.com/DSC-Ewha) and was handed over to the next lead.

 

2. Mini Seminars

There are so many different fields in development. A common concern among students was not knowing what they actually enjoy. One reason for this is that they simply don't know many technologies and fields exist. They don't even know about learning methods or tools. So I thought about what kind of pathway could help people gain broad, shallow knowledge — at least knowing that certain technologies and tools exist.

So I created a time for members to share what they'd personally studied about the technologies they mainly use, or the technologies used in their team projects. Since each team project used different technologies, I figured this could be a way for members with common interests to connect and discuss further.

So at each weekly meetup, members took turns giving about 15-minute mini seminars. Initially, we filled the DSC Ewha Facebook page (www.facebook.com/DSCEwha) with simple Q&A-style posts about each seminar. 

However, when COVID forced us to move team projects and meetings online, the mini seminars also went online. We switched to a format where members recorded videos and uploaded them to the team blog. There were many topics that were new to me too. I was worried this activity might also get scrapped due to COVID, but the members showed great responsibility and everyone uploaded their content, so we were able to wrap it up successfully.

It wasn't all good times during the activities. When we were meeting in-person, I had to prepare for weekly meetups while also coordinating other DSC events, so there was a lot to manage. Because of that, I regret not being able to focus on my own development studies during my junior year second semester due to community activities. On the other hand, when we moved online, some members dropped out and there was free-riding, which really made me doubt my own abilities. During that time, since we were doing team projects online, I regret not providing more care and support as a lead.

Despite being such an inadequate lead, I was able to wrap up activities well and complete the handover thanks to the members who actively participated in every project and seminar.

Wow... I wrote up to here in October and now I'm opening the text editor again to finish it in December lol. Well, at least there's meaning in getting it done!!

Events Held at DSC Ewha

1. DSC Ewha Open Codelab "Mo.Gat.Co" (Let's Code Together)

How the Event Came About

Many students have tried coding through basic SW education courses, but that's ultimately just at the language level. We organized a fun, interest-driven coding session to show students who are curious about coding what you can actually do with the programming languages they learned in elective courses. We decided to plan this event because Google Codelabs had excellent tutorial-style explanations for beginners, and I thought it would be a great opportunity to build DSC Ewha's presence within Ewha Womans University.

Event Preparation Process

During preparation, DSC Ewha members participated as tutors so I didn't have to do everything alone. Fortunately, many members were willing to help, so we had fun preparing the event together. As a lead, my role was more of an administrator than a developer — I handled things like contacting Ewha Womans University's Software-Centered University Initiative to secure funding for the event.

Running the Event

Each session ran for one class period at our university. Out of the total 1 hour and 15 minutes, 5 minutes were for an OT introducing DSC Ewha and DSC Korea, 60 minutes were for hands-on codelab practice with tutors, and 10 minutes were for requesting survey responses. 

For the codelabs, we divided roles into main tutors and sub-tutors. The main tutor ran the codelab live in the front, while sub-tutors helped students with any parts they didn't understand, providing additional explanations and assistance.

We held the event twice (2 sessions per event, 4 sessions total), and from what I remember, it was in October and December. In December, several professors even came in to observe... haha. The feedback from the post-event surveys was all positive, so everyone felt really proud. Originally, when I was still lead earlier this year, we planned to keep hosting these events, but due to COVID and everyone struggling to adapt to the online format, we had to cancel everything and unfortunately couldn't plan anything further.

 

2. Ewha Garden Committers

This was an internal event within DSC Ewha. We ran a daily commit group for 70 days spanning winter break and the start of the first semester. We referenced the activity format that DSC HUFS had done, and set the specific direction based on "Jandicon," an event held by GDG Pangyo. Our group had 9 members total, and 7 of them participated for all 70 days. 

To monitor each other's daily commits, we used Slack's GitHub plugin so that any changes to each person's repository would trigger a notification. Of course, we also set fines for missing a commit. 

I also personally redeployed the commit management tool created by GDG Pangyo's "Gardeners" for our Ewha Garden Committers, and built a site to collect commit records. The related code is saved at https://github.com/mjung1798/ewha-daily-commit.

Originally, on the last day of the 70-day period, March 28th, we planned to hold a conference at school called "Ewha Jandicon" where we would present our daily commit activity records to fellow students. But once again, COVID put an end to that plan, which was disappointing.

With these management tools, we ran a commit group where everyone tried to make one commit per day. It would have been hard to keep it up alone, but doing it together like this was really helpful for me too.

All the activities at Ewha that I planned and managed received great responses, but I always wanted to do them N more times. Unfortunately, with the chaotic situation in 2020, the main activities only happened in 2019, which is a shame.

Personally, when running Mo.Gat.Co, I focused less on deep technical exploration of technologies I wanted to study, and more on making it an event to promote the club and spark interest in coding. So the content was geared more toward beginners than toward things that would help me technically. (After all, events targeting the general public tend to attract the most people when aimed at beginners.) As a result, preparing these events didn't bring any technical growth to my developer career. When running DSC Ewha, the resources spent on organizing events and managing the club far outweighed the resources invested in improving my own technical expertise, which is something I feel regretful about.

However, the Committers activity was one I was very satisfied with, because I was also doing one commit per day, building a habit of consistently studying development. It gave me dedicated time purely for my own technical growth through actual development studies.

 

My Activities in Connection with the Google Community

Communication with the Google Korea Developer Relations team was essential while doing DSC activities. This was because DSC Korea was launched for the first time in 2019, and there were also collaborations with other Google-supported communities beyond DSC. Naturally, I ended up participating in and collaborating on events hosted by GDG, WTM, and GDE members.

1. DevFest Seoul 2019 Staff Participation

jyami.tistory.com/24?category=854536

 

DevFest Seoul 2019 Staff Review

I'd been meeting with my professor and having group Hangouts meetings to prepare for DevFest Campus Korea 2019, but I hadn't actually been to a DevFest myself, so I applied to be a staff member for DevFest Seoul! Honestly, my ulterior motives were pretty obvious

jyami.tistory.com

First, I participated as staff at DevFest organized by GDG Seoul to see how events were run, and from that point on, I started planning and thinking about the DSC events I would create. I've written a detailed review at the link above. (I should've been documenting things properly all along..haha)

2. Google Cloud Summit 2019 Participation

jyami.tistory.com/25?category=854536

 

2019 Google Cloud Summit Review

The Google Cloud Summit was held at COEX on November 6th. I attended with a ticket I received as a DSC Korea member. I used to only use AWS, but through my DSC activities, I started hearing a lot about Google products

jyami.tistory.com

The Google Korea DevRel team gave attendance passes to DSC Korea Leads, so I got to attend. Up until then, I'd honestly only used AWS and didn't really use GCP lol. I think this was when I started gradually trying out GCP. Luckily, I wrote a review about it back then.

3. DevFest on Campus 2019 Planning Committee

jyami.tistory.com/26?category=854536

 

DevFest on Campus 2019 - Planning Committee Review!

1. Intro DevFest on Campus 2019 on November 16, 2019 is finally over!!!! https://festa.io/events/654/ DevFest on Campus 2019 | Festa! Find the events you're looking for on Festa. festa.io GDG Campus..

jyami.tistory.com

GDG Campus Korea reached out to DSC Korea Leads with a proposal to co-organize a DevFest together. Since our university ended up being the venue, I got even more actively involved in this event.

4. Google Cloud OnBoard 2019 Participation

jyami.tistory.com/32?category=854536

 

Google Cloud OnBoard Review & Summary Notes Link

I attended the Google Cloud OnBoard held at Sejong University on November 26, 2019. I had already been to the summit in early November, but I went because they were holding actual hands-on sessions. https://inthecloud.withgoogle.com/onboard-..

jyami.tistory.com

 

I went on my own because I was excited about the hands-on sessions. Being a Lead meant I could hear about various events quickly, and I remember deciding to skip class to go to this one lol 

 

5. Korea Community Summit Participation

This was a gathering where all the organizers of Google communities came together for a retrospective. I attended as a DSC Lead, and it was a chance to reflect on the year, introduce ourselves, and plan for the next year. I got to meet many GDG and GDE members and receive their advice. At the Google Korea office, we did various activities and had plenty of opportunities to chat with lots of people.

 

6. 2020 HashCode Participation (DSC Korea Team)

jyami.tistory.com/52?category=854536

 

HashCode 2020 Participation Review

It was my first time participating in a PS competition. I heard on the DSC Korea Slack that someone was looking for teammates, so I joined! Haha, UTC 17:30 means it was from 2:30 AM to 6:30 AM in Korean time. So the teammates had to code

jyami.tistory.com

I participated in HashCode, a team algorithm competition by Google, together with friends from DSC Ewha. We pulled an all-nighter for it. It was a personal activity, but I'd love to keep participating after studying algorithms more seriously.

7. DSC Korea Networking Day

This was an event organized by the DSC Korea Leads together. Students from all 12 DSC Korea universities gathered for a networking event that included recreational activities. The Leads worked together on venue booking, budgeting, promotions, and program planning, cheering each other on throughout. Thanks to everyone's efforts, this event received the highest satisfaction feedback among all DSC events. 

While preparing the event — inviting speakers, preparing keynotes, creating icebreaker materials, preparing group discussion topics for attending members, designing, and securing the venue — we Leads grew even closer through all the work. I remember the Google DevRel team and GDE members helping us a lot during this time.

This was the biggest event held under the DSC name, and everyone realized how much effort from so many people is needed even to organize a small event — budget management, headcount checks, venue confirmation and setup, and more. We had originally planned to host a hackathon as well, but unfortunately, due to COVID-19, this ended up being DSC's last event overall, which was really disappointing..

 

Wrapping Up Activities

Toward the end of our term, the Leads wrote a relay of activity reviews together. While writing them, I was curious about who the next batch of Leads would be and excited about what new activities they would come up with. 

Handover

After finishing my term as the 2019-2020 DSC Ewha Lead, I prepared handover materials around September. While putting together the handover documents, I ended up organizing all my past activities — and that's how I ended up writing this blog post lol. But I never expected to be finishing it this late.. Currently, DSC Ewha is being run by a new Lead who took over. She's really talented, but because of COVID, I'm not sure how activities are going right now ㅠ

DSC was different from the typical dev clubs and extracurricular activities — it gave me new experiences through DevRel-related activities, making it an unforgettable part of my life. The connections I made back then? We're all still in touch, cheering each other on :)

Honestly, it wasn't all sunshine and rainbows. There were struggles like communication issues with various organizations as a community organizer and worries about not growing enough as a developer. But I was able to meet truly precious people and broaden my horizons — it was such an amazing experience. That's why I consider it the best thing I did during my college years.

지난 회고에 알고리즘 공부좀 해야겠다고 적었다.

이전에 5월 챌린지, 6월 챌린지도 조금 했었는데 두번 다 그냥 대충 내가 아는문제만 풀다가(dfs, tree 문제들 푸는걸 귀찮아 해서 그런 문제가 나오면 넘겼다.) 끝까지 완주하지 않고 안했었다.

회고에 적었던 알고리즘 공부를 사실 안 지키고 있었는데ㅋㅋ
코딩테스트 준비를 하려고 알고리즘 공부를 한 2일정도 했는데, 묘하게 재밌다 싶어서 시작하게 되었다.

https://leetcode.com/explore/challenge/card/july-leetcoding-challenge/

 

Explore - LeetCode

LeetCode Explore is the best place for everyone to start practicing and learning on LeetCode. No matter if you are a beginner or a master, there are always new topics waiting for you to explore.

leetcode.com

리트코드에서 매일매일 24시간안에 한 문제를 풀어야하는 과제가 내려오는 형식인데 
한국 시간 기준으로는 오후 4시에 새로운 문제가 업로드 된다.

이 챌린지를 계속 하다보니 일일커밋도 자연스럽게 하게 되었다 (지금 깃캣도 키우고있음..ㅎㅎ) 
7월 레포지토리 기준 33 커밋이다.

매일매일 문제를 풀고 싶었으나 그럼에도 머리가 안돌아가서 못푼문제, 사람들의 discussion을 봐도 이해가 안되는 문제들은 가볍게 패스했다. 풀다보면 나중에 봤을때 이해가 되는 순간이 있지 않을까 싶어서 그랬다.

7월 챌린지는 84 프로로, 27 / 31 ( solve / total ) 달성 했다.

생각보다 하나씩 해결하는게 재밌어서 8월에도 할 듯?

In my last retrospective, I wrote that I should study algorithms.

I had done a bit of the May Challenge and June Challenge before, but both times I just half-heartedly solved only the problems I already knew how to do (I was too lazy to solve DFS and tree problems, so I'd skip them whenever they came up) and never finished either one.

I wasn't actually keeping up with the algorithm study I mentioned in my retrospective lol
But I spent about 2 days studying algorithms to prepare for a coding test, and it was oddly fun, so I decided to jump in.

https://leetcode.com/explore/challenge/card/july-leetcoding-challenge/

 

Explore - LeetCode

LeetCode Explore is the best place for everyone to start practicing and learning on LeetCode. No matter if you are a beginner or a master, there are always new topics waiting for you to explore.

leetcode.com

The format is that LeetCode gives you one problem each day that you have to solve within 24 hours. 
Based on Korean time, new problems are uploaded at 4 PM.

Keeping up with this challenge naturally led me to make daily commits too (I'm even raising a GitCat right now lol). 
Based on the July repository, I've made 33 commits.

I wanted to solve a problem every single day, but there were still some problems I couldn't solve because my brain just wouldn't cooperate, and some that I couldn't understand even after reading people's discussions — I just lightly skipped those. I figured that if I keep at it, there'll come a time when I look back and finally get them.

I finished the July Challenge at 84 percent, achieving 27 / 31 ( solve / total ).

It was more fun than I expected to knock them out one by one, so I'll probably keep going in August too!

올해 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

 

volatile을 사용한 쓰레드간 통신 동기화

이펙티브 자바를 읽으면서 짜릿한 단일검사(racy single-check)에 대해 찾아보던 중, 알게된 내용이다. 동기화의 기능 자바의 쓰레드 프로그래밍을 해보았다면 synchronized 키워드를 몇번 접해볼 수 있�

jyami.tistory.com

https://jyami.tistory.com/99

 

자바의 제네릭 타입 소거, 리스트에 관하여 (Java Generics Type Erasure, List)

1. 자바의 제네릭과 로타입 (Java Generics and Raw Type) public class Example{ private T member; } 위와 같이 클래스 및 인터페이스 선언에 타입 매개변수 T 가 사용되면 제네릭 클래스, 제네릭 인터페이스라..

jyami.tistory.com

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

 

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

 

volatile을 사용한 쓰레드간 통신 동기화

이펙티브 자바를 읽으면서 짜릿한 단일검사(racy single-check)에 대해 찾아보던 중, 알게된 내용이다. 동기화의 기능 자바의 쓰레드 프로그래밍을 해보았다면 synchronized 키워드를 몇번 접해볼 수 있�

jyami.tistory.com

https://jyami.tistory.com/99

 

자바의 제네릭 타입 소거, 리스트에 관하여 (Java Generics Type Erasure, List)

1. 자바의 제네릭과 로타입 (Java Generics and Raw Type) public class Example{ private T member; } 위와 같이 클래스 및 인터페이스 선언에 타입 매개변수 T 가 사용되면 제네릭 클래스, 제네릭 인터페이스라..

jyami.tistory.com

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!