코딩 하는 가든

조금 이른 2021 회고

가든리 — Thu, 2 Dec 2021 12:38:28 +0900

들어가며

아직 회고글이 올라오기엔 이른 시기지만 여유시간이 생겨버려 일찍이 회고글을 작성 하게 되었다. 2021년은 진정한 의미로 사회인으로서의 첫발을 내딛은 해였다.(현 직장이 올 해 2월 정규직 전환이 되었기 때문에,,, 학교 졸업도 2월에 했다.) 회사에서, 또는 여러 활동을 하며 좋은 사람들을 만나고 많은 것을 보고 배운 의미 있는 한 해 였던 것 같다. 같이 취준을 하던 친구들 또한 모두 취업을 했으며 벌써 더 좋은 조건에 이직을 하거나 연협을 통해 좋은 보상을 얻어내는 친구도 있었다. 종종 주변 동생들의 취업 소식도 들린다. 나 뿐만 아니라 주변 사람들 에게도 좋은 일이 많이 있었던 한 해 였던 것 같다.

2021년에서 제일 기억에 남는것은 역시 회사생활이 아닐까 한다.

회사

운이 좋게도 카카오라는 좋은 회사에서 첫 회사생활을 시작 할 수 있었다. 포털사이트 '다음'을 운영하는 팀을 만났고 시기가 들어 맞아 입사를 하자마자 다음 포털 서버 개편 프로젝트에 참여 할 수 있었다. 일일 PV가 수천만에 달하는 큰 서비스의 개편 프로젝트라니 정말 멋진 경험이었다.

사실 시작하기 전에는 두려움이 더 크긴 했다. 나같은 쪼렙 개발자가 이렇게 큰 서비스를 다룰 수 있을까 라는 생각을 했다.(별도의 온보딩 기간 없이 바로 프로젝트에 투입 되었던것같다.) 하지만 이 팀에서의 개발 경험은 그런 걱정 따위는 바로 잊게 할 만큼 군더더기 없이 깔끔하고 좋았다.

어떻게 하면 더 깔끔하고 유지 보수를 하기 좋은 코드가 될지? 해당 코드를 처음 접한 사람도 쉽게 접근 할 수 있도록 코드를 작성 할지? 등 많은 측면에서 공을 많이 들인 코드를 볼 수 있었다. 특히 디버깅 경험이 아주 훌륭했는데, 거의 웬만해서 문제가 생긴곳의 위치를 바로 알 수 있었다. 적절한 디자인 패턴의 접목과 DDD의 접목을 통해 좋은 품질의 코드를 만들어 볼 수 있었다.(사실 구조를 짜는것은 시니어분이 거의 다 하시긴 했다. 그 정도로 깔끔한 코드를 짜기 위해서는 수 많은 연습과 노력이 필요 하다는 것을 안다. 5년, 10년 후에는 나도 그런 경지에 다다르고 싶다.)

사실 사내 깃헙에서 여러 프로젝트를 찾아 봤는데 이정도로 깔끔하게 짠 코드는 많이 보지 못했던것 같다. 이런 훌륭한 분들과 한 팀에서 함께 일 할 수 있었던 것이 가장 큰 행운이지 않았을까 싶다.(물론 카카오에 계시는 개발자들 모두가 훌륭한 분들이다.)

결론적으로 다음 포털은 1초의 다운타임 없이 사용자 모르게 서버 전환을 성공 했다. 서버 구조는 완전히 바뀌었으며 쿠버네티스의 도입도 있었다. 이런 경험은 새내기 개발자인 나에게는 정말 의미있는 경험이었다.

해당 프로젝트 이후에는 여러 운영 업무도 해보았고 공통 라이브러리를 만들어 사내 배포를 통해 여러 프로젝트에 적용시키는 일도 해 보았다. 이런 경험들을 통해 특히 엔지니어로서의 성장을 한 것 같다. 엔지니어는 기술을 통해 문제를 해결하는 사람을 뜻하리라. 비록 내가 개발자지만 기술이라 함은 꼭 코딩을 뜻하는것은 아닐 것이다. 어느 순간은 단 한 줄의 코드 추가 없이 문제를 해결 할 수 있는 순간도 올 것이다. 더 빠르고 효율적으로, 안전하게 문제를 해결 할 수 있고 그 방법을 찾을 수 있어야 진정한 의미로써의 엔지니어가 아닐까 싶다. 카카오에서의 1년은 나를 단순 코더에서 엔지니어란 무엇인가에 대한 길을 찾을 수 있게 해 주었다. (아래 영상을 통해 더 공감 할 수 있었다.)

https://www.youtube.com/watch?v=3H4umWD5bwI

이직

그렇다. 카카오에서의 1년을 뒤로 한 채 이직을 하게 되었다. 기회를 잡는 것도 기회라 했던가. 더 훌륭한 개발자가 되기 위한 기회가 찾아 왔다고 생각 한다.

사실 이직을 준비 하고 있던건 아니었다. 카카오에서 더 배우고 성장 할 수 있다고 생각 하던 참이었고 적어도 3년정도는 있어야 겠다는 마음이었다. 그러던 중 토스팀에게 링크드인을 통해 연락을 받았고 토스팀에 대해 알아 보며 점점 흥미가 생기기 시작 했다.

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

해당 영상이 나를 토스로 이끌었다. 특히 영상에 나온 부분 중 '우리는 이름만 대면 알만한 대기업부터 자그마한 소상공인까지 그들의 사업을 이어나가는데 도움을 주고 니즈를 가장 가까이에서 들을 수 있는 매력적인 포인트가 있다.' 라는 대목이 흥미를 느끼게 했다.

토스팀의 채용 프로세스 경험은 매우 훌륭 했다. 리쿠르터, HR, 면접관 한 분 한 분 모두 너무 친절 하셨고 나를 배려 해 주시는게 너무 잘 느껴졌다. 면접을 보며 만난 개발자분들, HR분과 대화를 하며 그들 모두 재미있고 열정적으로 일하고 있다는게 느껴져서 참 좋았던 것 같다. 채용 프로세스 속도 또한 너무 만족 했는데 이력서 접수부터 최종 합격까지 열흘이 채 걸리지 않았다.(카카오에 올 때는 2달 이상이 걸렸다. 최근 면접 본 후배의 말에 따르면 많이 개선되었다고 한다.)

면접이 끝난 후엔 1년 전에 비해 많이 성장한것을 느꼈다라는 피드백도 받았다.(작년 취준때 2020토스 NEXT채용 코테에서 떨어졌었다.)

사실 학생때는 스프링계의 유명인이신 백기선님, 김영한님이 곧 바로 진리인 줄 알았다. 하지만 회사에 다녀 보니 앞서 언급한 두 분 못지 않는 훌륭한 분들이 너무 많이 계셨고 카카오에서의 1년은 나의 시야를 더 넓어지게 해줬다. 토스팀에서도 그런 훌륭한분들을 만날 수 있을거란 기대를 가지고 12월에 토스 팀에 합류를 결심 하게 되었다.

이번 이직을 진행하며 또 느낀것이 있는데 기회가 오면 두려워 말고 잡아야 한다는 것을 느꼈다. 이제 막 2년차에 접어든 내가 벌써 토스로 이직하리란 생각은 하지 못했었다. 사실 카카오에 지원 할 때도 경력도 없는 내가 수시채용에 지원해도 될까 라는 두려움이 있었다. 카카오 수시채용은 아는 선배의 권유에 의해 지원 마감 2일전에 급하게 지원 했던걸로 기억 한다.

기회는 예기치 못하게 찾아오며 그것을 잘 잡을 수 있어야 한다는 것을 알게 되었다. 물론 기회는 준비된 자에게 온다 라는 말도 조금은 동감 한다. 비록 딱히 이직 준비(코테, CS 지식, 기타 개발 지식 공부 등)를 한 것은 아니었지만 내가 지난 1년간 무엇을 했는지 왜 그런 결정을 내렸는지에 대해서는 막힘 없이, 맛깔나게 설명 할 수 있었다. 때문에 항상 내가 하고 있는 일을 진지하게 대하고 매 순간 최선을 다하며 복습과 회고는 항상 중요하다는 것을 다시 한 번 느끼게 되었다. 이것이 곧 이직 준비가 아니었을까 . . .

~~(사실 여기 가면 바빠질까봐 회고글을 미리 써놓는 것도 있다. . .)~~

자기계발

독서

올해는 유독 책을 많이 읽었던 것 같다.(몇 권 안 돼 보여도 내 기준에선 많다..) 사실 개발 관련 서적이 대부분 이지만...

객체지향의 사실과 오해
오브젝트
클린 아키텍쳐
스프링 5를 활용한 리액티브 프로그래밍
네티 인 액션
쿠버네티스 입문
Real Mysql
쿠버네티스 인 액션(스터디 진행중)
코틀린 인 액션(스터디 진행중)

얼마 전 부터는 마이크로 서비스 패턴 이라는 책을 읽기 시작 했다. 사실 작년에 서평 이벤트로 당첨되어 받은 것인데 당시에는 한 페이지도 공감을 못하다가 지금은 아주 재미있게 읽고 있다. 몇 일 전 '도메인 주도 설계로 시작하는 마이크로 서비스 개발' 과 '오브젝트 디자인 스타일 가이드' 라는 녀석들도 집에 들여 왔다. 다 읽을 수 있을진 모르겠지만 천천히 들여다 봐야 겠다.

개발 관련이 아닌것으로는

군주론 - 마키아벨리
인간실격 - 다자이 오사무
달과 육펜스 - 윌리엄 서머싯

을 읽었다. 사실 연 말쯤 되서 다 몰아 읽은것 같다. 고전 문학을 좋아하는 편인데 뭔가 남는건 없더라도 문학은 읽을 때 만큼은 세상과 단절 되고 모든 걱정을 뒤로 한 채 온전히 책에만 집중 할 수 있게 해주는 매력이 있다. 아직 데미안(나의 원픽)을 처음 읽었을 때의 그 전율을 이길만한 책은 아쉽게도 찾지 못했다.(예전엔 이런 류의 책을 많이 읽었던 것 같은데 요즘 쉽지 않다...) 또 문학은 내가 구사 할 수 있는 어휘를 조금 더 다채롭게 해준다. 이런 능력은 각종 자소서나 이력서 등을 쓸 때 언젠가 도움이 되지 않을까? 이 글을 보며 그렇지 않은 것 같다고 느낀다면 기분 탓이다.(사실 잘 못쓰는 것 인정 한다... 역시 글은 쓰는것보단 보는게...)

그리고 요즘엔 너무 개발 관련만 읽다 보니 개발바보가 되는것 같아서 어제 알라딘 중고 서점에서 인문학 책도 한 권 들고 왔다. '지적 대화를 위한 넓고 얕은 지식'이라는 책인데 이걸 읽고 조금은 더 지적으로 보이는 사람이 되어봐야겠다.

내년엔 개발 관련이 아닌 여러 책들을 좀 읽고 싶다.

건강

군대에 있을 땐 꾸준히 운동을 했었는데 전역하고 한참을 쉬다가 올 해 재택근무를 하는김에 PT를 등록해서 다녔었다. 4개월간 PT를 다녔고 확실히 배우지 않고 운동을 할 때 보다 더 많이 (근)성장이 되는게 느껴졌다. 하지만 8월에 PT가 끝나고 다시 헬스장에 등록을 못해서 근육은 다 빠진 것 같다. 요즘은 집 앞 도림천 런닝을 하는데 이것도 날이 추워져 슬슬 못할듯 싶다. 토스에 가게 되면 회사 근처 헬스장이라도 등록을 해야겠다. 사실 꾸준히 운동 하는건 자신 있는데 식단을 못해서 내 평생 바디프로필 한번 볼 수 있을까 싶다.

카카오에 다니면서 재택근무 및 온라인 회식을 자주 하다 보니 배달 음식을 엄청 자주 시켜 먹게 되었다. 내년엔 어차피 출근을 할듯 싶지만 배달음식도 좀 자제하고 건강하게 챙겨 먹어야 겠다.

먹고 있던 솔가 비타민 및 오메가3가 거의 다 떨어져서 영양제 개편도 한 번 필요 할듯 싶다. 집에 항상 두유를 두고 마시고 있었는데 대체품을 못 찾다가 야채주스가 맛있다는 말을 듣고 한번 사볼까 생각중이다.

여행

코로나 사태가 벌어지고 여행이라는 단어는 많이 조심스러워졌다. 사실 여행은 아니었고 10월 한 달을 재택근무로 제주에서 보냈다. 카카오 제주 오피스에도 몇 번 출근을 했다. 카카오 제주 오피스 하면 다들 정문에 있는 코딩하는 돌하르방을 떠올리지만 개인적으로는 뒷편에서 보는 오피스 전경이 더 멋졌다.

제주에서 근무를 하며 점심시간이나 근무 전 후로 바다 산책을 자주 했다. 해먹에 누워서 별을 보며 멍때리기도 하고 새벽에 일어나 일출을 보러 오름에 올라가기도 했다. 바다가 보이는 카페에서 아메리카노를 한 잔 하며 코딩을 하면 코드가 그렇게 잘 써...지진 않고 바다만 보인다. 근무를 할 때는 적당한 분위기는 필요 한 것 같다.(물론 제주에 근무 하면서 진행중이었던 프로젝트의 피쳐는 성실하게 잘 만들어 냈다.)

그래도 확실히 답답한 서울의 원룸에서 일 할 때 보다는 능률이 훨씬 잘 나온 것 같다. 아마 2021년 10월의 기억은 잊지 못할 추억이 될 것 같다.

취미

거의 10년간 손 놓았던 피아노를 다시 치기 시작 했다. 그동안 아주 작은 방 혹은 기숙사에만 살다가 이번에 전셋집으로 오게 되며 피아노가 들어올 자리가 생기게 되었다.(그래도 작긴 하다...) 오래 쉬어서 감이 잘 안 돌아오는것 같긴 하지만 이것도 연습만이 살 길 이다.

내년엔 유키 구라모토의 곡들을 연습 해 볼 생각이다.

개인적인 피아니스트 원픽은 피아노 가이즈의 존 슈미트고 그 다음은 유키 구라모토다. 유키 구라모토의 작품을 감상해보시라.

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

동아리

매시업(https://www.mash-up.kr/) 이라는 동아리를 시작 하게 되었다. 학생과 직장인이 반반 정도 섞여있는 곳이다. 사실 동아리를 시작할 8월 즈음엔 반반이었던 것 같은데 지금은 그 사이에 많이들 인턴 또는 취업을 하여 회사 생활을 하고 있다. 실력있는 분들이 많이 모여 있는 곳이다. 내로라하는 IT기업 종사자들, 학생이 맞나 의심될 정도의 실력을 가진 분들이 많은 곳이다. 하루 하루 이곳에서 이야기 하며 배워가는 것들이 많다.

해커톤 행사에서는 1위를 해 상금을 타기도 했다.(상금을 지원해준 SSG에게 감사 드리며 해커톤을 캐리 해준 클라이언트 개발자, 디자이너 분들에게 감사 드린다. 서버가 미흡해서 죄송할 따름...)

프로젝트 팀 팀장을 맡아 회의를 주도 해 보기도 하고 이런 저런 일에 신경을 많이 썼던 것 같다. 적어도 초반 까지는 ... 뒤로 갈수록 이직 이슈 때문에 잘 참여를 못한것 같아 팀원들에게 미안하다. 다음 기수에는 끝까지 열심히 참여 해야지...

혹여나 하는 마음에 언급하지만 인원 제한과 방역수칙을 잘 준수하며 진행 되었다.

이 동아리는 개발만 잘 하는게 아니라 놀기도 잘 한다. 술을 엄청 잘 마시는 사람들이 많다. 사실 나는 이런 류의 동아리가 매시업이 처음인데 다른 동아리(SOPT, 넥스터즈, YAPP 등)를 경험한 친구들에 의하면 분위기가 제일 괜찮다고 한다. 매시업 덕분에 재미있는 연말을 보내는 중이다. (매시업이 없었다면 올해가 너무 무료했을지도 ,,, 땡큐 매시업!)

개발

스프링과 JPA를 사용하는 사람들을 위한 라이브러리 개발을 시도 했었다. 완성까진 한참 멀었다.

https://github.com/lee-garden/Jasmine

GitHub - lee-garden/Jasmine: Simple Jpa Admin Generator

Simple Jpa Admin Generator. Contribute to lee-garden/Jasmine development by creating an account on GitHub.

github.com

기존에 장고를 사용 하며 장고 어드민의 편의성에 아주 감탄을 하고 있었다. 하지만 스프링으로 넘어 오며 장고 어드민 같은 자동 생성 되는 어드민이 없다는것이 조금 불만이었다. 하긴 그도 그럴것이 장고는 어느정도 DB Access Layer를 강제 하지만 스프링에는 다양한 방법이 있으니 여러 상황에 대응 할 수 없겠다는 생각은 들었다.

적당한 선에서 타협을 하면 그래도 간단하게 쓸만한 정도는 되지 않을까라는 생각에 Spring + JPA를 사용하는 경우에 자동으로 어드민 사이트를 생성해주는 라이브러리를 개발 해보고자 하였다.

목표는 이러 하다. 의존성 추가를 하고 몇 가지 설정만 더해주면 어드민 사이트가 자동 생성이 된다. Reflection으로 JPA Entity를 읽고 JpaRepository를 가져와 JPA Entity의 메타데이터를 활용해 간단한 CRUD를 할 수 있는 페이지를 생성 해준다.

마지막 커밋은 한 달 전이고 아직 볼품없는 프로젝트지만 내년엔 완성 할 수 있지 않을까?

현재 라이브러리에 어드민용 템플릿을 추가 하면 라이브러리를 불러온 프로젝트에서 템플릿을 찾지 못하는 이슈가 있다. 사실 한 달 째 해결을 못하고 있다. ㅎㅎ... 오픈소스이니 추후엔 누군가의 기여도 기대해볼만 하지 않을까...

2022 계획

영어 공부

자랑은 아니지만 영어를 못한다고 이야기 하고 다닌다. 사실 학창 시절 제일 자신 없는 과목도 영어였고 여전히 개발 문서를 읽는것도 쉽지 않다. 막 학원에 다니거나 문제집을 사서 풀겠다는 이야기는 아니다. 시간이 날 때 영어 듣기를 한다던가 미드를 보거나 해외 유튜버의 영상을 보며 영어와 친숙해지는게 먼저인것 같다.

사실 이번에 이직을 하면서 외국계 기업에 대한 욕심이 생긴것 같다. 구글, 아마존, 페이스북... 꿈도 꾸지 못할거라고 생각 했었는데... 어! 영어만 된다면 의외로 할만 할지도? 라는 생각이 들었다. 젋고 열정이 있을 때 도전해봐야지 언제 해보겠는가! 못 먹어도 고(GO) 다.

MSA & DDD 공부

CQRS, Saga, 이벤트 소싱 등 여러가지 MSA 환경에 어울리는 패턴들에 대해 공부 해보고 싶다. 가능 하면 예제 코드를 작성해서 남겨 두려고 한다. DDD를 적용 해 더 깔끔한 코드를 작성 하면 좋을 것 같다.

기본 코드 뿐만 아니라 테스트에도 조금 더 신경 쓰고 싶은데, 나는 코딩 뿐 아니라 여러가지 자동화를 통해 반복되는 작업을 없애는걸 좋아 한다. 이슈 알람 프로세스라던지 자동 테스팅이 그런 것들인데 이번에 아주 흥미로운 전략을 알게 되었다.

https://martinfowler.com/articles/consumerDrivenContracts.html

Consumer-Driven Contracts: A Service Evolution Pattern

Consumers should drive the definition of service contracts, while limiting to their individual needs. Suppliers should then validate against the union of their consumers' contracts.

martinfowler.com

소비자 주도 계약 패턴에 대해 공부 하고 spring cloud contract나 pact를 이용하여 어느정도 자동화를 통해 의존 하는 서비스간의 테스트를 더 정확하고 깔끔하게 작성 해보고 싶은 생각이 들었다.

회고

조금 더 자주 회고를 작성 할까 한다. 사실 올해는 이게 처음이자 마지막 회고가 되겠지만 내년에는 가능하면 달에 한 번, 적어도 반기에 한 번은 회고를 하면 좋을 것 같다. 자주자주 메모 하고 기록하는 습관을 들여야겠다. 노션을 잘 활용해 보자. 올 한 해는 뭔가 기록물이 적은것 같아 아쉽다. 회사 업무일지라던지 업무를 진행 하며 느낀점, 스스로에 대한 회고 등 여러 글을 쓸 기회가 많았던것 같은데 그러지 못해 아쉽고 내년에는 더 많은 글을 작성해볼까 한다. 가끔씩은 일기도 써보면 좋을 것 같다. 여행을 갔을 때 남는건 사진뿐이라 하지만 그보다 더 오래 남는건 글이 아닐까

플러터

불로소득을 위하여! 화이팅!

마치며

사실 나도 취업을 할 때 주변에서 굉장히 도움을 많이 받았고 이제는 반대의 입장에 서서 많은 도움을 주고 싶다.

작년 말엔 '코알못이 개발자가 되기 까지' 라는 글로 4년간의 대학생활을 회고 하며 어떻게 취업을 준비 했는지에 대한 글을 썼다.

코알못이 개발자가 되기 까지 - (1)

2021.03.26 원래 학교 후배님들을 대상으로 작성 했던 글이라 학교 얘기를 좀 써놨는데 ... 프로그래머스에 포탈이 열려서 많은 분들이 오시는것 같네요 들어오시는 모든 취준 하시는분들 화이팅

gardeny.tistory.com

요즘은 조금 더 가까이에서 여러 사람들에게 도움을 주고 있다.(라고 생각 하고 있다.) 그래도 주변에서 취업을 했다 라거나 이직을 했다 라는 이야기를 들었을 때, 특히나 그 과정에서 나의 한마디가 덧붙여졌다라고 생각 하면 왠지 모를 뿌듯함이 느껴지곤 한다. 종종 누군가 무엇을 성취 했을 때, 그것에 대한 노티를 나에게 주었을 때 조금은 도움이 되지 않았을까 라는 생각이 든다.

나는 이야기 하는 것을 좋아 한다. 오지랖을 부려 지인들에게 여러 이야기를 하는 편이다. 물론 내 이야기를 듣는 모두가 다 잘 되었으면 하는 마음이 가장 먼저지만 내 이야기를 하는 것은 나에게도 도움이 된다는것을 느꼈기 때문에 더욱 더 내 이야기를 하려고 한다.

같은 말을 반복 하다 보면 어떤 개념이 내 안에 자리 잡게 되고 그것이 곧 신념과 비슷한 것이 되리라. 그리고 그것을 글로 적어 놓으면 온전히 내 것이 된다. 후배들에게 자주 하던 이야기가 있었는데 그런 이야기 들을 여러 면접들에서도 똑같이 이야기 했다. 비록 해당 질문이 들어온 것이 아니라도 어떻게든 엮어서 그런 이야기들, 내가 평소에 갖고 있던 생각들을 풀어내고 내가 어떤 사람인지를 전하면 언제나 충분히 승산이 있다고 믿는다.

회고 또한 마찬가지다 이렇게 내가 가지고 있는 생각을 풀어내는것 또한 훗날 나에게 혹은 다른 사람에게 도움이 될 것이라 믿고 이렇게 남겨 둔다. 혹시 이 글을 보며 혹은 항상 회고글을 보며 한 번 써볼까 망설였던 분들은 꼭 한 번 해보시기를 추천 드린다.

거창하지 않아도 좋다. 실패에 대한 회고도 좋다.

실패에 대한 기록 또한 훗날 나에게 도움이 될거라는 생각에 이렇게 기록을 남겨둔다.

작년의 나에게 가장 큰 감명을 주었고 가장 큰 도움을 주었던 블로그에 적혀 있는 글귀 이다. 해당 글을 첨부 하며2021년 회고를 마친다.

https://zorba91.tistory.com/286

카카오 뉴인턴에서 정규직 전환 실패에 대한 회고

정규직 전환 면접에서 떨어졌다. 3개월 동안 뉴인턴으로 카카오에 재직하며 평가기간을 거쳤다. 3개월 전에는 카카오 이직에 대한 후기를 남겼었는데, 3개월이 지난 지금은 실패에 대한 회고를

zorba91.tistory.com

입사부터 반 년 동안 재택 근무 한 신입 이야기

가든리 — Sun, 30 May 2021 18:05:51 +0900

유례없는 전염병이 세상에 나타나 사람들의 생활을 바꾸기 시작 한지도 벌써 1년 하고도 반 이나 지났다.

작년 비대면 강의를 수강하며 "설마 내가 회사 갈 때까지 이 사태가 지속이 될까?"라는 생각도 하긴 했지만 작년 11월 처음 계약직으로 회사에 입사하고 원격으로 3개월간의 평가 프로세스를 거친 후, 정규직 전환이 되어 3개월을 더 다니는 지금 까지도 나는 원격 근무를 하고 있다. 이 글에서는 본인이 원격 근무를 하며 느낀 점 등을 정리하려고 한다.

원격 교육, 원격 근무 등 (거의)새로운 방식들이 생겨나고 사람들은 적응해 나가고 있다. 하지만 물론 1년 반 만에 필요한 모든 제도가 갖춰지지는 않았을 것이며 아직 신경 쓰지 못한 부분들이 있을 것이다.

대부분의 회사, 부서들은 신규 입사자를 위한 온보딩 프로세스를 갖추고 있다. 하지만 최근 입사자가 없었다면 구시대의 온보딩 자료가 남아 있을 것이다. 그나마 회사 차원에서의 온보딩은 어느 정도 구색을 갖추고 있지만 실제 업무를 하기 위해 신규 입사자에게 필요한 것은 부서 차원에서의 온보딩 자료이다.

예를 들어 그 간 진행 했던 프로젝트의 히스토리, 담당하고 있는 서비스, 운영에 대한 이해 등 정리해 놓은 문서가 될 것이다.

물론 우리 부서에 신규 입사자를 위한 자료가 없던 것은 아니다. 하지만 비록 신규 입사자를 위한 자료가 있고, 팀원 분들과의 화상 회의로 여러 설명을 들었음에도 불구하고, 팀원 분들과의 회의가 끝나면 나는 무인도에 조난당한 선원처럼 무엇을 먼저 해야 할지 몰라 당황했던 기억이 역력하다.

뭘 해야 하지?

사실 입사 초기에 나는 모르는 게 생겼을 때, 안 되는 게 생겼을 때 팀원들이 "얘는 이것도 못하나?"는 생각을 하실 까 봐 질문을 많이 하지 못했었다. 안 되는 건 무작정 시간을 더 많이 들여(위키의 저 심해 어딘가까지 탐험하며...) 스스로 해결하려 했고 사실 처음에는 "아 이게 기업이 원하는 자기 주도적인 인재인가?"라는 생각을 했었다. (추후 셀장님과의 면담을 통해 미련한 짓이라는 걸 깨달았다...)

그런데 내가 입사 초기에 마주했던 문제 중 많은 문제는 대부분 VPN IP의 권한 등록 문제였고, 원격 근무를 하고 있기 때문에 발생한 문제였다. 사실 온사이트였다면 대부분 발생하지 않았을 것이고 보통 온사이트 근무를 하다 보면 어이없는 문제로 삽질하고 있는 내 모습을 어느 팀원 중 누군가 지나가며, 어깨너머로 보고 알려준다거나 반대로 내가 어깨너머로 배울 수 있는 게 있을 텐데 하면서 탄식을 했었던 것 같다.

물론 이 글은 우리 회사 문서가 불친절해요! 하는 글은 아니다. 보통의 경우 기존 팀원들은 업무가 바쁘고 오랫동안 신규 입사자가 많이 없었기 때문에(특히 코로나 이후로는) 거기까지 신경을 쓰지 못했으리라...

다행히 우리 부서는 바로 전 입사하신 분 께서 대략의 문서를 정리해주셨고 그것에 정말 큰 도움을 받았다. 그리고 다음 입사자가 똑같은 문제로 삽질하지 않기를 바라며 내가 입사 후 진행했던 환경 세팅, 권한 요청 등 여러 프로세스를 정리 해 놓았다. 이 글을 보는 신규 입사자분이 계시다면, 특히나 삽질을 하고 계시다면 다음 입사자를 위해 본인이 진행한 프로세스를 정리해 문서화를 해놓는 건 어떨까?

그리고 이런 문서를 작성했다면, 그리고 그 과정에서 어려움을 겪거나 궁금한 게 생기면 요약해서 퇴근 30분 전, 혹은 출근하여 팀원분께 피드백을 요청해보자! 어떤 과정에서 어려움을 겪었는지 그 히스토리가 드러나 있으면 피드백을 주실 때 그와 연관된 부가 작업이라던지를 더 설명해 주실 수 도 있다. 아마 그리고 진행상황을 알면 다음 과정 진행에 있어 가이드를 해주실 수 있을 것이다. (물론 완전히 막혀버려 더 이상 진행이 불가능한 상태면 최대한 빠르게 조심스럽게 질문해 보자 ㅎㅎ... )

그리고 질문을 할 때 최대한 구체적으로 해야 한다! 어디서 막혔는데 내가 시도 해 본 방법이 무엇이 있는지, 어떤 환경에서 시도했는지를 상세하게 설명해야 한다. 온사이트라면 바로 자리로 와서 같이 컴퓨터를 만져보며 할 수 있지만 원격이라 상황이 여의치 않을 때는 질문에 부가 설명이 구체적일수록 좋은 것 같다. 그래야 서로 간의 의사소통 비용을 많이 줄일 수 있는 듯하다...

인증 API 호출했는데 400 응답이 옵니다(x).

XX 프로젝트에서 인증 API 호출 했는데 400 응답이 옵니다.

VPN은 연결되어 있고 권한은 있습니다. 환경변수는 xxx설정해놓았습니다.(o)

위의 질문은 예시고 물론 원격이 아니더라도 아래처럼 질문하는 게 맞지만 하고자 하는 말의 요점은, 특히 텍스트로 전달할 때는 최대한 많은 정보를 주어 불필요한 생각을 제거해 주는 것이 많이 중요한 것 같다.

똑똑한 질문으로 효율적인 의사소통을 하는 것은 사실 어느 포지션에 있는 사람이든 함께 일하기 위해 중요한 부분인 것 같다.

여기까지는 개인적으로 원격 근무를 하며 느꼈던 점이고 잠시 잡담을 하며 글을 마무리하려고 한다.

오랜 재택근무로 인해 몸이 굳어가는 게 느껴진다. 며칠 동안 집 밖에 나가지 않은 적도 있고 사실 집에만 있다 보니 아침에 일어나 일 하다가 점심을 대충 차려 먹으면 (심지어 점심 먹을 때도 그 자리에 앉아있거나) 다시 앉아서 유튜브를 보거나 하며 시간을 보내곤 했던 것 같다.

몸도 굳어가고 눈도 나빠지는 게 느껴지는데 아주 작은 변화라도 주어 보고자 시작했던 챌린지(이름 왜 거창해...)가 있었다.

맥북 타이머 앱을 설치하고 30분에 한 번 씩 알람을 울리게 만들어 놓은 후 알람이 울리면 자리에서 일어나 스트레칭 한 번, 목, 손목, 어깨, 허리, 다리, 눈 까지 한 사이클을 돌리고 다시 앉는다. 정말 이 정도라도 안 하면 완전 몸이 망가질 것 같아 시작한 챌린지이다. 다행히도 지금은 피티도 받고 있고 가끔 나가서 산책도 한다...(진즉 할 것이지...)

그 외 재택근무하며 본인 스스로 지켜야 할 것, 그리고 나름의 루틴을 정해서 일을 하고 있다.

이런 루틴이라도 없으면 (특히나 재택인데 자율 출퇴근이어서...) 아마 재택근무가 엉망이 되지 않을까...

일어나서 근무 전에 머리 감기... 오전 근무 시작 전 카누 커피 한잔 타기... 미리 점심 먹을 쌀 불려 놓기.... 등등...

이 재택근무가 언제 까지 지속 될 지는 모르겠다. 곧 백신이 풀린다고는 하지만 과연 바로 온사이트 체제로 전환 될 수 있을지도 의문이다. 하지만 그 전까지라도 이런 소소한 것들을 정해서 나름의 재택 근무 원칙을 만들어서 지키며 번아웃 오지 않고 건강하게 해 나가야겠다.

Spring Webflux의 Functional Endpoints 사용법. (with RouterFunction)

가든리 — Sun, 16 May 2021 23:32:35 +0900

Spring Webflux에서는 엔드포인트를 매핑 하는 방식으로 기존에 사용하던 어노테이션 방식(@Controller, @RestController)이외에도 Router를 이용한 함수형 방식을 지원 합니다.

이번 글 에서는 웹플럭스에서 Functional Endpoints를 어떻게 사용하는지 알아봅니다.

당연한 이야기지만 우선 웹플럭스 의존성이 필요 합니다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-webflux'
}

Functional Endpoint를 사용 하기 위해서는 함수형 인터페이스인 RouterFunction의 구현체를 만들어서 스프링 빈으로 등록 시켜야 합니다.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.MediaType;
import org.springframework.web.reactive.config.EnableWebFlux;
import org.springframework.web.reactive.function.server.RouterFunction;
import org.springframework.web.reactive.function.server.RouterFunctions;
import org.springframework.web.reactive.function.server.ServerResponse;

import static org.springframework.web.reactive.function.server.RequestPredicates.*;

@Configuration
public class RouterConfig {

    @Bean
    public RouterFunction<ServerResponse> routerExample(PostHandler postHandler) {
        return RouterFunctions.route()                   //1
                .GET("/post/{id}", request -> postHandler.getById(request)) //2
                .POST("/post", postHandler::create)      //3
                .POST("/post/json", accept(MediaType.APPLICATION_JSON), postHandler::createFromJson) //4
                .build(); //5
    }

}

// 1 : RouterFunctions 의 route() 메소드는 RouterFunctionBuilder를 반환 합니다.

빌더 패턴을 이용하여 RouterFunction을 완성 시킬 수 있습니다.

// 2 : GET 메소드로 http GET 메소드가 들어왔을 때를 정의 해 줍니다.

uri pattern과 함수형 인터페이스를 인자로 받을 수 있습니다.

// 3 : POST 메소드 정의. 함수형 인터페이스를 postHandler::create 처럼 축약하여 사용 한 형태.

// 4 : uri pattern과 함수형 인터페이스와 더불어 accept, 혹은 content-type을 명시적으로 써줄 수 있습니다.

// 5: build() 메소드로 빌더 패턴을 완성 시켜 구체 클래스를 만들어 냅니다.

다음으로 Handler의 구현을 보겠습니다.

@Component
public class PostHandler {

    /**
     * 이번 프로젝트의 주제는 router의 이해이므로
     * 로직은 최대한 간단하게 해서 결과만 받아 볼 수 있도록 구현
     * */

    // path variable 추출
    public Mono<ServerResponse> getById(ServerRequest request) {
        Long id = Long.parseLong(request.pathVariable("id"));
        Post post = new Post(id, "garden", "hello");
        return ServerResponse.ok().contentType(MediaType.APPLICATION_JSON).bodyValue(post);
    }

    // x-www-form-urlencoded 추출
    public Mono<ServerResponse> create(ServerRequest request) {
        Mono<MultiValueMap<String, String>> formData = request.formData();

        return formData.flatMap(data -> {
            Map<String, String> dataMap = data.toSingleValueMap();
            String title = dataMap.getOrDefault("title", null);
            String content = dataMap.getOrDefault("content", null);

            Post newPost = new Post(1L, title, content);
            return ServerResponse.ok().contentType(MediaType.APPLICATION_JSON).bodyValue(newPost);
        });
    }

    // json data 추출
    public Mono<ServerResponse> createFromJson(ServerRequest request) {
        Mono<Post> PostMono = request.bodyToMono(Post.class);
        return PostMono.flatMap(post ->
                ServerResponse.ok().contentType(MediaType.APPLICATION_JSON).bodyValue(post));
    }

}

Post.java

@AllArgsConstructor
@Setter
@Getter
public class Post {
    private Long id;
    private String title;
    private String content;
}

각 메소드는 router에서 넘겨준 것 처럼 ServerRequest 객체를 넘겨 받습니다.

ServerRequest는 Request에 대한 모든 정보를 담고 있으며 클라에서 넘겨준 데이터를 추출 하여 사용 하면 됩니다.

pathVariable() 메소드를 통해 "post/{id}" 처럼 들어온 요청의 pathVariable을 추출 할 수 있습니다.

request.pathVariable("id")

formData() 메소드를 통해 x-www-form-urlencoded 형식의 데이터를 추출 할 수 있습니다.

formData는 Mono<Map> 을 반환 합니다.

(multipartData() 를 통해 multipart form-data 도 추출 가능)

Mono<MultiValueMap<String, String>> formData = request.formData();

bodyToMono() 메소드를 통해 json 데이터를 Dto로 매핑 시킬 수 있습니다.

Mono<Post> PostMono = request.bodyToMono(Post.class);

어노테이션 방식을 이용 하면 @RequestMapping 외에도 @Controller나 @RestController에 공통으로 들어가는 path를 써주는 형태가 있는데 RouterFunctionsBuilder의 path 메소드를 통해 공통 path를 지정 할 수 있습니다.

    @Bean
    public RouterFunction<ServerResponse> nestedRouter(PostHandler postHandler) {
        return RouterFunctions.route()
                .path("/post", builder -> builder
                    .GET("/{id}", postHandler::getById)
                    .POST("", postHandler::create)
                    .POST("/json", postHandler::createFromJson)
                ).build();
    }

nest Method를 통해 공통으로 accept를 적용 시킬 수 도 있습니다.

    @Bean
    public RouterFunction<ServerResponse> nestedRouter2(PostHandler postHandler) {
        return RouterFunctions.route()
                .path("/post", builder -> builder
                        .nest(accept(MediaType.APPLICATION_JSON), builder2 -> builder2
                            .POST("/json", postHandler::createFromJson)
//                            .POST("", postHandler::xxx) 이 뒤로 붙는 RequestPredicate는 모두 APPLICATION_JSON이 accept
//                            .PUT("", postHandler::xxx)
                        )
                ).build();
    }

글에서 작성된 코드는 아래에서 확인 가능 합니다.

https://github.com/97e57e/BLOG/tree/master/Spring/router-master

97e57e/BLOG

블로그 예제 코드 모음. Contribute to 97e57e/BLOG development by creating an account on GitHub.

github.com

Spring Webflux에 Resilience4j를 이용해 서킷브레이커 패턴 구현하기 - (2)

가든리 — Wed, 5 May 2021 15:54:52 +0900

이번 글에선 실제로 코드를 보며 어떻게 서킷브레이커를 구현 하는지 알아 보겠습니다.

예제에 사용된 코드는 여기에서 확인 가능 합니다.

우선 Resilience4j는 Spring MVC와 Spring Webflux 환경에서 모두 사용 가능 합니다. 이번 예제에서 Webflux를 선택 한 이유는 MSA환경에서 많은 api 호출이 일어나는 환경에서는 Webflux가 많이 유리 할 수 있고, 개인적으로 느끼기에 점점 Webflux를 이용하여 개발을 많이 해 가고 있다고 생각 하기 때문 입니다.

-> 한창 뜨는듯 했으나 요즘은 다시 가라앉는것 같은 느낌이 들기도 ...

(2024.06.05 수정)

물론 Webflux가 만능은 아니며 토비의 스프링의 저자이신 토비님 께서는 if kakao에서 MVC 환경 에서 문제 없이 애플리케이션이 돌아 간다면 굳이 Webflux를 선택 할 이유가 없다고 하셨습니다.

https://tv.kakao.com/channel/3150758/cliplink/391418995

물론 서킷브레이커의 도입을 고민 하시고 계신 분이라면 라이브러리 선택은 이미 끝났다고 생각 하겠습니다 ..

서킷 브레이커 구현

Webflux + Resilience4j를 사용하기 위해서는 다음과 같은 라이브러리 의존성을 추가 해야 합니다.

implementation 'org.springframework.boot:spring-boot-starter-webflux'   // Webflux
implementation 'org.springframework.boot:spring-boot-starter-aop'       // Resilience4j의 어노테이션 방식을 사용하기 위해 필요
implementation "io.github.resilience4j:resilience4j-spring-boot2:1.7.0" // Resilience4j
implementation 'io.github.resilience4j:resilience4j-reactor:1.7.0'      // Reactive 환경에서 Resilience4j를 사용 하기 위해 필요

글 쓰는 기준 현재는 1.7.0 버전이 최신이며 최신 버전은 여기 에서 확인 가능 합니다.

먼저 외부 Api를 호출 하는 컴포넌트를 만듭니다.

@Component
public class TestApi {

    private WebClient webClient;

    TestApi() {
        webClient = WebClient.builder().baseUrl("http://localhost:8081").build();
    }

    public Mono<String> getApiData(String key) {
        return webClient.get()
                .uri("/data?key=" + key)
                .retrieve()
                .bodyToMono(String.class);
    }
}

Webclient를 이용해 api를 호출 하도록 했습니다. 테스트를 위해 localhost:8081에 테스트를 위한 API 서버를 띄워 놓았습니다.

API 서버는 간단하게 key라는 파라미터에 fail이 들어오면 exception을 반환 하도록 만들었습니다.

/**
 * 8081에 떠있는 API 서버
 * */
@RestController
public class DataController {

    @GetMapping("/data")
    public String success(String key) {
        if (key.equals("fail")) {
            throw  new RuntimeException();
        }
        return "data";
    }
}

이렇게 API 호출부와 API서버가 준비 되면 서킷 브레이커를 적용 해 볼 수 있는 준비가 끝났습니다.

Resilience4j의 서킷 브레이커를 정의 해 보겠습니다. 서킷 브레이커를 정의 할 수 있는 방법에는 두 가지가 있습니다.

1. Java 파일로 빈을 정의 한다.

2. yml, properties 파일에 정의 한다.

먼저 1번 방식 입니다.

@Configuration
public class CircuitConfig {

    @Bean // 1
    public CircuitBreakerRegistry circuitBreakerRegistry() {
        return CircuitBreakerRegistry.of(
                CircuitBreakerConfig.custom() // 2
                    .slidingWindowSize(10) // 3
                    .failureRateThreshold(80) // 4
                    .build()
        );
    }

    @Bean // 5
    public CircuitBreaker circuitBreaker(CircuitBreakerRegistry circuitBreakerRegistry) {
        return circuitBreakerRegistry.circuitBreaker("garden");
    }
}

서킷 브레이커 레지스트리를 위한 빈을 정의 합니다. 서킷 브레이커 레지스트리는 서킷 브레이커 객체들을 담고 있는 컨테이너 입니다.
서킷 브레이커 레지스트리에서 생성 될 서킷브레이커의 설정을 정의 합니다.
서킷 브레이커는 최근 요청 중 slidingWindowSize만큼의 요청을 저장 합니다.
서킷 브레이커는 slidingWindow에 저장된 call의 성공, 실패 여부를 저장 하여 실패 확률이 failureRateThreshold에 도달 하면 서킷 브레이커를 OPEN상태로 만들고 호출을 차단 합니다.
서킷 브레이커 레지스트리를 통해 garden이라는 이름의 서킷 브레이커를 만듭니다.
circuitBreaker("name") 메소드는 해당 이름의 서킷브레이커가 없으면 새로 생성 해 주고 있다면 해당 객체를 반환 합니다.

다음으로 2번 방식으로 yml에 정의 하는 방식 입니다.

resilience4j:
    circuitbreaker:
        configs:
            default:
                slidingWindowSize: 10
                failureRateThreshold: 80

        instances:
            garden:
                baseConfig: default

instances에 만들고자 하는 서킷 브레이커의 이름과 어떤 설정을 가질지를 정의 해 줄 수 있습니다.

주의할 점

2번 yml방식을 사용 하면CircuitBreaker 자체가 Bean으로 등록 되지 않는다는 것 입니다. Spring Bean에 등록 되는 것은 CircuitBreakerRegistry뿐이며 서킷 브레이커 객체를 이용 하기 위해서는 registry에서 직접 꺼내 주어야 합니다.

이렇게 서킷 브레이커를 정의 했으면 이 서킷 브레이커를 이용해 API 호출을 차단 해 보겠습니다.

서킷 브레이커를 손 쉽게 사용 하는 방법은 어노테이션 방식을 이용 하는 것 입니다.

@RequiredArgsConstructor
@Service
public class ServiceA {

    private final TestApi apiA;

    public Mono<String> getMonoData(String key) {
        return apiA.getApiData(key);
    }
}

위에 정의한 TestApi 컴포넌트를 통해 api를 호출 하는 서비스를 정의 해 보겠습니다.

이 서비스의 getMonoData 메소드에 서킷 브레이커를 적용 하는 방법은 간단하게 @CircuitBreaker 어노테이션을 붙여 주는 것 뿐 입니다.

@RequiredArgsConstructor
@Slf4j
@Service
public class ServiceA {

    private final TestApi apiA;

    @CircuitBreaker(name = "garden", fallbackMethod = "fallback")
    public Mono<String> getMonoData(String key) {
        return apiA.getApiData(key);
    }

    public Mono<String> fallback(String key, Throwable t) {
        log.error("Fallback : " + t.getMessage());
        return Mono.just("fallback data");
    }
}

@CircuitBreaker 어노테이션을 서킷브레이커를 적용시키고 싶은 메소드 위에 붙입니다.
어노테이션의 인자는 name (서킷브레이커의 이름) 과 fallbackMethod(Exception 발생 시 수행 할 메소드) 입니다.
fallback메소드를 정의 할 때는 주의 할 점이 있는데 fallback의 파라미터로 서킷을 정의 한 메소드의 파라미터를 똑같이 정의 하고 어떤 Exception을 잡을 것인지를 하나 더 써줘야 한다는 것 입니다.
getMonoData(String key)
fallback(String key, Throwable t)
저는 Throwable을 인자로 주었기 때문에 모든 타입의 익셉션을 처리 할 수 있고, 메소드 오버로딩을 통해 여러 폴백을 정의 하면 가장 가까운 타입의 익셉션 인자가 있는 메소드를 수행 하게 됩니다.

이렇게 하고 서비스를 호출 하는 컨트롤러를 만들어 보겠습니다.

@RequiredArgsConstructor
@RestController
public class TestController {

    private final ServiceA serviceA;

    @GetMapping("/annotation")
    public Mono<String> testAnnotation(String key) {
        return serviceA.getMonoData(key);
    }
}

이렇게 해서 애플리케이션을 시작 하고 요청을 보내 보겠습니다.

먼저 slidingWindow(10)를 꽉 차게 하기 위해

http://localhost:8080/annotation?key=success 라는 url로 10번 호출을 한 후

http://localhost:8080/annotation?key=fail로 10 번을 호출 해 보겠습니다.

에러 로그를 보면 failureRateThreshold가 도달 하기 까지 8번의 호출은 실제 api를 호출 해서 Exception이 발생 했지만 80%가 넘어간 순간 부터 CircuitBreaker의 상태가 OPEN이 되어 API의 호출을 완전히 차단 한 것을 볼 수 있습니다.

서킷 브레이커가 OPEN된 상태에서 메소드를 호출 하면 CallNotPermittedException이 발생 하며 호출을 막게 됩니다.

이렇게 OPEN 상태가 된 서킷은 시간이 지나면 HALF_OPEN상태 ( 이 때 약간만 호출을 해서 다시 서킷을 열지 정상 상태로 되돌릴지 판단 합니다.)를 거쳐 다시 OPEN이 되거나 CLOSE 상태가 될 수 있습니다.

이 때 몇 초간 기다려서 서킷의 상태를 바꿀 것인지 등에 대한 세세한 설정을 해 줄 수 있는데 상세 설정은 여기를 참고해 보시면 됩니다. 이 외에도 slowCall이 발생 했을 때도 서킷 브레이커를 발동 시킬 수 있으며 설정을 통해 더 세세한 컨트롤이 가능 해 집니다.

어노테이션을 이용해 서킷 브레이커를 사용 하는 방법 외에도 서킷브레이커 오퍼레이션을 통해도 사용 할 수 있습니다.

이렇게 사용 할때는 주로 서킷브레이커를 Spring Bean이 아니라 순수한 자바 객체에서 사용 하고 싶을 때가 있습니다.

어노테이션 방식을 사용하려면 Spring AOP를 이용 해야 하는데 이는 Spring Bean이 아니면 동작 하지 않기 때문 입니다.

public class ServiceB {

    private TestApi api;
    private CircuitBreakerRegistry circuitBreakerRegistry;
    
    public ServiceB(TestApi api, CircuitBreakerRegistry registry) {
        this.api = api;
        this.circuitBreakerRegistry = registry
    }

    public Mono<String> getMonoData(String key) {
        CircuitBreaker circuit = circuitBreakerRegistry.circuitBreaker("garden");

        return api.getApiData(key)
                .transform(CircuitBreakerOperator.of(circuit))
                .onErrorResume(this::fallback);
    }

    public Mono<String> fallback(Throwable t) {
        log.error("Fallback : " + t.getMessage());
        return Mono.just("fallback data");
    }
}

위와 같이 Reactive Stream 중간에 .transform 메소드 체인을 이용 하여 CircuitBreakerOperator.of(circuitBreaker) 를 이용 하면 transform 메소드의 업스트림에 대해 서킷 브레이커 적용이 가능 합니다.

api.getApiData(key) 의 과정에서 익셉션이 난것을 서킷브레이커 오퍼레이션이 캐치 하여 서킷 브레이커를 발동 시켜 줄 것 입니다.

마찬가지로 서킷이 오픈 되면 CallNotPermittedException이 발생 하게 되고 그 익셉션을 onErrorResume으로 캐치해 처리 하는 전략 입니다.

Resilience4j에는 이런 서킷 브레이커 이외에도 장애에 강한 시스템을 만들기 위한 TimeLimiter, Retry같은 여러 모듈들이 존재 합니다. 시스템을 더 안전하게 만들고 싶은 분이라면 Resilience4j의 다른 모듈에 대해서도 알아 보시길 권합니다.

github.com/resilience4j/resilience4j

resilience4j/resilience4j

Resilience4j is a fault tolerance library designed for Java8 and functional programming - resilience4j/resilience4j

github.com

Spring Webflux에 Resilience4j를 이용해 서킷브레이커 패턴 구현하기 - (1)

가든리 — Sun, 2 May 2021 21:37:39 +0900

이번 글에서는 실제 구현은 없고 서킷 브레이커 패턴에 대한 설명을 합니다.

마이크로 서비스 아키텍처라는 단어가 세상에 나온지도 10년이 지났습니다. 비대해지는 모놀로틱 아키텍처에서는 여러가지 문제(유지 보수의 어려움, 오래 걸리는 컴파일 및 빌드 시간 등)가 발생 하였고, 이 문제들에서 벗어날 수 있는 방법 중에서 마이크로 서비스 라는 아키텍처가 대세로 떠오르게 되었습니다.

마이크로 서비스는 하나의 거대한 애플리케이션을 작은 기능을 하는 여러개의 애플리케이션으로 나누어 각각의 서비스가 따로 구동 되고 배포 될 수 있는 환경을 갖추게 됩니다.

마이크로 서비스 아키텍처에 대한 글은 아니므로 자세한 설명은 잘 작성된 다른 블로그의 글로 대체 합니다.[마이크로 서비스 아키텍처에 대해 잘 설명된 글]

하지만 마이크로 서비스 아키텍처도 만능은 아닙니다.(물론 지금도...) 마이크로 서비스 아키텍처라는 패러다임이 이렇게 활발히 사용되기까지 여러 시행 착오가 있었을 것이고 여러 문제들을 해결하기 위한 고민들이 있었을것입니다.

오늘은 그 중에 CircuitBreaker 패턴에 대해서 알아보겠습니다.

(사실 서킷 브레이커는 msa 환경 뿐만 아니라 외부 api 호출이 일어나는 상황에서는 어디든지 적용 가능 합니다. 하지만 외부 api호출이 활발하게 일어나는 msa환경에서의 서킷브레이커 패턴 적용이 더 많은 사례와 요구가 있을 듯 하여 msa환경이라는 전제조건을 붙이게 되었습니다.)

CircuitBreaker Pattern

서킷 브레이커는 개발뿐 아니라 다른 분야에서도 쓰이는 용어 입니다. (전기, 주식, ~~스타크래프트~~ 등)

서킷 브레이커는 과부하로 인해 문제가 발생하는 것을 방지 하기 위하여 과부하를 주는 원인을 차단 하는 역할을 합니다.

예를 들어 주식 시장에서는 빠른 시간 내에 주가가 급락, 급등 할 때 시장의 과열을 막기 위해 잠시 동안 매매가 정지 되는데 이것을 서킷 브레이커가 발동되었다고 합니다.

그럼 개발계에서의 서킷브레이커는 어떤 상황에서 쓰일 까요? 아래와 같은 MSA 구조가 있다고 해보겠습니다.

이 상황에서 만약 어떤 서비스에 장애가 발생 한다면 그 장애로 인해 다른 서비스 까지 장애 상황을 겪게 될 수 있습니다.

이러한 상황을 '장애가 전파 된다.' 라고 합니다.

서킷 브레이커 패턴은 이러한 상황을 방지 하기 위해 존재 합니다.

서킷 브레이커는 어떤 API를 호출하는데에 있어 서킷 브레이커를 두어 장애가 발생한 서버로의 호출을 차단 하게 됩니다.

사실 이렇게만 보면 이렇게 생각 할 수도 있습니다.

'외부 API를 호출하는 서버에 exception 처리만 잘 해주면 되는거 아니야?'

서킷 브레이커는 장애로부터 우리의 서버를 지켜 주는 역할도 하지만 호출 하는 서버를 지켜줄 수 있는 역할을 하기도 합니다.

위의 그림에서 serviceA가 TimeOutException 을 던진다고 가정 해 봅시다. serviceA가 완전히 응답 할 수 없는 상황이기에 익셉션을 던진 것 일 수도 있지만 애플리케이션에서 정의한 timeout이 일어난 것 일 수도 있습니다.

예를 들어 serviceA는 완전 죽지는 않았지만 slow query등의 이슈로 인해 가용 thread가 더 이상 남아 있지 않을 수 도 있습니다. 이러한 상황에서 계속 해서 요청이 들어 온다면 불난 집에 기름을 붓는 꼴이 되어버릴 것 입니다.

이러한 상황에서 serviceA가 안정을 찾기 위해 요청을 잠시 멈춰주는 전략 또한 서킷 브레이커를 통해 구현 할 수 있게 됩니다.

CircuitBreaker 구현체

서킷브레이커의 구현체로는 대표적으로 Netflix사에서 만든 Hystrix가 있었으나 더이상 개발 되지 않고 Hystrix에서도 오픈소스인 resilience4j를 사용 하라고 권하고 있습니다.

resilience4j는 글 작성일 기준 10일 전에 마지막 커밋이 되었고 이슈나 풀리퀘스트가 꾸준히 올라오는 활발한 오픈소스 프로젝트 입니다.

다음 글에서는 이 resilience4j를 이용하여 서킷 브레이커 패턴을 직접 구현 해 보도록 하겠습니다.

Java - Java에서 Throttle기법 사용 하기.

가든리 — Fri, 30 Apr 2021 17:12:42 +0900

들어가기에 앞서 먼저 Throttle(쓰로틀)이란?

쓰로틀은 같은 이벤트가 짧은 시간 내에 반복적으로 일어 날 때 부하를 막기 위해 호출 횟수의 제어를 하는 기법입니다.

주로 프론트엔드에서는 스크롤을 올리고 내릴 때, 스크롤에 붙어 있는 이벤트가 짧은 시간 내 엄청나게 많이 호출 되는 것을 방지하여 정해 진 시간 내에 정해진 횟수만큼 실행 될 수 있도록 제어하기 위해 쓰로틀 기법을 많이들 사용 합니다.

[www.zerocho.com/category/JavaScript/post/59a8e9cb15ac0000182794fa]

Java로 Throttle을 사용 하는 경우?

사실 잘 모르겠습니다 ㅎㅎ.

저 같은 경우엔 Spring 백엔드 서버에서 외부 api의 응답 결과를 캐시에 저장 하는 작업을 하는데, 반복적으로 같은 값들이 계속 저장 되기 때문에 매번 저장할 필요 없이 초당 횟수를 제한하여 저장 하면 좋지 않을까? 라는 생각이 들어 자바로 쓰로틀링을 구현하는 방법에 대해 찾아 보았습니다. 아마 여기까지 찾아 오신분들이라면 각자의 이유가 있을것이라고 생각 합니다...

구현

쓰로틀링을 구현한 라이브러리가 몇 가지 있지만 여기서는 google에서 만든 guava 라이브러리를 사용해 보겠습니다. 사실 guava는 많이 사용 하던 라이브러리 인데 쓰로틀 같은것 까지 구현 되어 있을 줄은 몰랐습니다.

1. 먼저 구아바 라이브러리 의존성을 추가 해 줍니다. (최신 버전은 여기서 확인 가능 합니다.)

dependencies {
    implementation 'com.google.guava:guava:30.1.1-jre'
}

2. RateLimiter 객체를 만들어 줍니다.

create 메소드의 인자는 double permitsPerSecond 인데 초당 몇 회까지 호출 할 수 있는가에 대한 값 입니다.

3. 쓰로틀링을 사용하고 싶은 로직을 if(rateLimiter.tryAcquire()) 로 감쌉니다.

RateLimiter rateLimiter = RateLimiter.create(2);

public void throttleMethod() {
	if (rateLimiter.tryAcquire()) {
		System.out.println("hello, world!");
	}
}

위와 같이 코드를 작성 하면 throttleMethod 내의 프린트는 최대 1초에 2회 찍히게 됩니다.

전체적인 코드는 아래와 같이 생겼습니다.

초당 최대 2회를 부를 수 있게 했고 5초동안 루프를 돌며 호출을 해봤습니다.

초당 2회씩 5초동안이면 10번이 호출 될 것 입니다.

결과

몇 줄 없지만 전체 코드는 깃허브에서 확인 가능합니다.

github.com/97e57e/BLOG/tree/master/Java/throttle

코알못이 개발자가 되기 까지 - (3)

가든리 — Tue, 29 Dec 2020 01:09:36 +0900

2020 1학기 (인턴 생활 및 취준 준비)

1학기 활동을 크게 나눠보면 다음의 네 가지 입니다.

인턴 활동, Spring공부, 스터디, 알고리즘

인턴(1-6월) 생활은 짧은 회고 글로 대체를 하겠습니다. [학생 개발자의 6개월 개발 인턴 회고] (사실 별 내용이 없어서 안읽어보셔도 됩니다... 중요한건 아니라...)

회사에서 Django로 개발을 하고 있었지만 스프링민국이라는 말을 워낙 많이 들어서 (사실 처음 인턴 찾을때도 많이 느꼈습니다.) 퇴근후에는 간간히 스프링 공부를 하기 시작했습니다. 처음에는 간단한 책을 통해 게시판예제를 만들어보며 기본적인 학습을 했습니다. 이후에 안 사실이지만 제가 가고싶었던 대부분의 IT기업 (흔히 네카라 라고들 부르는,,,)들의 공고에는 대부분 Spring Framework를 요구하는 곳이 많았고 본격적으로 공부를 해야겠다고 느낍니다. (2020 1월경)
이 시기에는 슬슬 본인이 원하는 회사들의 모집 공고들을 보며 어떤준비를 해야할지 알아가야 하는 시기인 것 같습니다.

책으로 공부를 마치고 난 뒤 저는 인프런 이라는 사이트에서 개당 약 10만원 하는 스프링 강의를 들었습니다. 만족도는 100%였고 혹시라도 유료 강의를 고민 하시는분들은 저는 무조건 강력 추천 드립니다... 확실히 비싼 이유가 있고 이로 인해 취업이 잘 된다면 그 돈은 다시 되돌아오는 것이라고 생각합니다...

퇴근 후에는 스프링 공부를 하며 친구들과 주말 스터디를 진행 했습니다. 운이 좋게도 주변에는 저와 같은 뜻(IT기업 취직)을 가진 친구들이 있었고 4명의 친구들과 함께 스터디를 진행 하게 됩니다. 매 주 각자 돌아가며 하고싶은 주제로 발표를 하기도 하고 함께 프로젝트를 진행하기도 했습니다. 이런 경험이 면접에서는 매우 잘 먹혔던 것 같습니다.

그리고 결정적으로 스터디가 정보력 싸움에도 큰 도움이 되었습니다. 각각에 흩뿌려져있는 공고나 팁들을 친구들이 하나하나 주워 와서 모으며 스터디 내에서는 나름의 큰 정보풀이 생기게 되었습니다. 많은 정보를 볼 수 있음과 동시에 정보를 찾기 위한 시간을 절약 할 수 있다는것이 이런 그룹의 큰 장점인 것 같습니다.

이 시기에는 알고리즘도 풀기를 시작 합니다. 아시겠지만 대부분의 회사들은 입사 시험으로 코딩 테스트를 보며 그 수준은 저에게는 꽤나 높았습니다. 저는 알고리즘 공부를 4학년 1학기 때 처음 시작했습니다. (후회되는것중 하나입니다.)

저는 4학년때 처음 시작한 알고리즘이 가장 고통스러웠습니다. 겨우 프로그래머스 2단계 문제를 푸는데 2시간, 3시간이 걸렸으며 못풀고 해답을 본 문제도 굉장히 많았습니다...(이짓을 한 두세달 하니 늘긴 하더군요... 꾸준함이 답인것 같습니다.)

처음엔 어떻게 해야할지 감이 안와 유료 강의를 들었습니다.(돈이짱입니다.) 그리고 매일 1~2문제씩 프로그래머스, 백준 등을 풀었던 것 같습니다. 이 시기에 4~5월 즈음 카카오 여름 인턴 코딩 테스트를 봤는데 5문제중 2문제를 맞췄던걸로 기억 합니다...

알고리즘은 정말 꾸준함만이 답인 것 같고 빨리 시작하면 시작 할수록 좋은 것 같습니다. 요즘은 코딩부트캠프(?) 라는 과목이 있어서 3학년쯤 부터 학교에서 강제로 알고리즘을 시키는걸로 알고 있습니다. 분명 고통스러우시겠지만 취준때 많은 시간을 절약해줄 것입니다....

사실 많이 생략되어있지만 올해는 정말 정신 없이 보낸 것 같습니다. 인턴 회사 퇴근을 하면 매일 1~2시까지 스프링 공부, 알고리즘 공부를 하며 지냈던 것 같습니다. (대충 보이는 공부 시기...)

6월 인턴을 하는 도중 더 좋은 회사가 욕심이 나 프로그래머스에서 진행한 dev matching(programmers.co.kr/competitions/144/2020-web-be-first)에 도전 합니다. 어떻게 코테를 통과해 면접까지 간 저는 면접에서 한마디 못하고 (이터러블 객체가 뭔지도 대답을 못했습니다.) 영혼까지 탈탈 털린 후 다시금 생각을 합니다. 지금까지 너무 코딩, 구현에만 집중 하고 있었고 뭔가 본질적인것 (cs나 언어에 대한 이해)을 놓치고 있다는 생각이 들었습니다. 그런 것을 다지기 위해서는 많은 시간이 필요 할 것 같았고 저는 기존의 인턴회사에서 들어온 연장 제의를 거절 하고 퇴사 후 폐관수련에 들어갔습니다.

2020 여름 (진짜 취준 ...!)

이 시기를 요약 하자면 자소서, 이력서, 알고리즘, cs공부 입니다.

6월이 끝남과 동시에 퇴사를 하고 7월 부터는 아침부터 밤까지 개인 공부에 시간을 썼습니다.

자소서 : 자소서도 사실 일찍 쓰기 시작하면 좋습니다. 3학년때 미리 한번쯤 써보면 좋을 것 같습니다. 네이버쪽 인턴 지원 할때 괜찮은 항목들이 많던데 그런것들 찾아서 써보시면 좋습니다. 자소서는 써보면 써볼수록 발전하고 꼭 많이 써보고 많이 첨삭 받아보시길 바랍니다. 나중에 취준할때 쓰면 되지 라고도 생각 하겠지만 은근 시간 많이 잡아먹습니다. . . 정말로 . . .

이력서 : 이력서 및 포폴은 (luckyyowu.tistory.com/382, brunch.co.kr/@hee072794/132, resume.yowu.dev/) 이 글들을 참고하여 작성 했던 것 같습니다. 이력서도 많은 수정과 노력이 필요합니다. 회사를 다니며 느낀거지만 지원자의 이력서를 검토하는데 많은 시간이 걸리지 않습니다. 짧은 시간 안에 최대한 이목을 끌고 어필을 할 수 있도록 나름 디자인도 신경 쓰고 해야 하는 것 같습니다.

부끄럽지만 이력서 일부를 공개 합니다.

적당히 아이콘이나 색감을 넣으면 깔끔하고 있어보입니다.

알고리즘, cs 및 각종 준비

계획은 중요합니다. 여러 준비를 하기에 앞서 하루정도는 계획을 잡아보는 시간을 가져보는것도 좋습니다. 저는 다음과 같은 계획을 잡고 계획한것을 최대한 지키려고 노력 했습니다.

아래의 것을 지켜가며 7~8월 두달을 보냈습니다.

OutLine

이 때 잠깐 카트라이더 러쉬플러스에 빠졌었습니다; 1-6월을 너무 달려서인지 이 시기에는 9시간을 잤네요. (잘 지켰을지는...)

6층 pc실에 자주 갔어서 이런식으로 정리 했던 것 같습니다.

이건 제가 썼던 자소서들 모음인데 아마 LG는 지원해놓고 인적성을 안보러갔던것 같습니다.

혹시라도 면접을 보게 된다면 회고는 항상 중요합니다.

이건 제가 봤었던 면접들인데 사실 면접이라는게 다니다보면 묻는게 다 거기서 거기이고 그렇다면 어떤 하나의 면접에서라도 완벽하게 대답 할 수 있다면 다른 면접도 문제 없다고 봅니다. 면접을 본 후에는 꼭 자신이 어떤 질문을 받았는지, 대답 못한게 무엇이 있는지, 잘못 대답한건 없는지 되짚어 보시기 바랍니다. 질문 못한 대답이 있다면 꼭 학습합시다.

요즘은 코로나로 비대면 면접이 대부분이기 때문에 저는 면접을 볼 때 항상 녹음기를 켜두고 끝난 후 제가 어떤식으로 대답했는지를 돌아봤습니다.

무슨 깡이었는지 네카라 아니면 안가겠다라는 마인드로 대부분의 기업 공고에 지원을 안하거나 면접을 안보러갔습니다. 잘 돼서 다행이지 하마터면 백수가 될뻔했네요

저중에선 네이버 예약은 탈락, 네이버 웹툰(채용연계형 인턴)은 합격하여 9월 중순부터 출근해 다녔습니다. 다니던 중 카카오에서 합격 연락이 와서 한달만에 도망갔습니다.

(진심으로 축하해주시며 보내주셨던 네이버 웹툰 멘토님께 감사드립니다.)

카카오 공고 : careers.kakao.com/jobs/P-11696

카카오 영입

[월간 카카오 7월] 사용자 서비스 서버 개발자 모집 / 테크 / 정규직

careers.kakao.com

제가 지원했던 카카오 수시채용 공고입니다. 7월에 지원 했는데 9월말에 합격발표가 나서 11월에 입사하여 다니고있습니다.

월간 카카오는 매 달 진행되니 관심있으신분은 영입페이지를 확인 한 후 지원해주시면 좋을 것 같습니다. 지원 하는 분이 계시다면 댓글로 알려주시면 더 자세히 설명 드리겠습니다.

ps. 코테에 약하신 분들은 수시채용을 노려보시기 바랍니다. 수시채용은 거의 이력서와 면접으로 결정 되며 코테의 비중이 낮습니다. 저도 카카오 공채 코테 문제는 잘 못푼답니다.

이건 제가 친구한테 전해준 자소서를 쓸 때 팁인데 점점 졸려지니 사진으로 대체하겠습니다.

글을 읽으신 모든 분들이 잘 되시기를 바랍니다.

코알못이 개발자가 되기 까지 - (2)

가든리 — Tue, 29 Dec 2020 01:09:22 +0900

2019 1학기 (웹개발을 접하다.)

이 전 글에서 언급했던것 처럼 친구에게 추천받은 동아리인 '멋쟁이 사자처럼'에 면접을 보게 되었고 운이 좋게도 합격을 하게 되었습니다. 비전공자들을 위한 동아리여서 그런지 코딩 경험이나 기술같은건 물어보지 않았기 때문에 합격 할 수 있지 않았나 싶습니다...

1학기에 동아리를 시작하며 본격적으로 html, css를 공부하게 됩니다. (사실 js는 아직도 잘 모릅니다.) 그리고 합격하고 동아리에서 들었던 말이 있는데 전공자들은 수업템포를 조금 더 높이기 위해 어려워 하는 비전공자들 친구들 옆에서 함께 도와주며 하는 마치 보조 강사 같은 역할을 기대하고 뽑았다고 합니다. (수준만 보면 나도 비전공자인데...) 그런데 성격상 그런 기대를 받아버리면 기대를 져버리면 안된다는 강박이 조금 있어서 활동 초기에 아마 거의 밤을 새며 html, css를 공부 했던 것 같습니다. 가르치는것이 배우는것이다. 라고 아마 이때 동아리를 하며 주변 친구들에게 도움을 주며 스스로 많이 성장을 했던 것 같습니다.

자신이 배운것을 확인하는 과정으로 남에게 가르쳐주는것은 참 좋은 학습법인것 같습니다. 그 과정에서 모르는 부분에 대해 더 알아 갈 수 있고 내 말로 정리하며 자신의 것으로 만들어 나갈 수 있는 것 같습니다. 이런 블로그 또한 그런것중의 일부라고 생각 합니다. 이 블로그의 첫번 째 페이지로 가보면 아시겠지만 대단한 것은 없습니다. 단지 java에서 배열 정렬 하는 법 이라는 주제로 블로깅을 시작 했고 시작은 대부분 대단한것이 아닙니다. 시작하는 것이 대단한것이지요

다시 본론으로 돌아가서 이 한학기 동안 Django를 위주로 웹 개발 수업을 들었습니다. 학기가 끝나고는 팀을 짜서 팀 프로젝트를 하는데 이 때 어디에 내놔도 부끄러운 저의 첫 번째 포트폴리오 항목이 완성 됩니다. 거의 2~3달 동안 아침부터 저녁까지 이 작업에만 몰두 한 것 같았지만 결과물은 대단하지 않고 코드 퀄리티는 똥이었습니다. 하지만 대부분의 기능을 검색 없이 직접 생각해서 만들어보았으며 많은 공부가 되었던 프로젝트 입니다.

github.com/97e57e/linkmoa

97e57e/linkmoa

Contribute to 97e57e/linkmoa development by creating an account on GitHub.

github.com

사실 코드의 수준은 처참하기 그지 없습니다. 로깅도 몰라 비지니스 로직 코드에 print문을 덕지덕지 붙여놓았고 관심사의 분리 없이 대부분의 기능들이 모놀로틱 하게 돌아갑니다. (요약하면 몰라서 개 대충 짬) 그래도 하나의 서비스를 완성해가는 과정, 각각의 페이지가 완성되는 것을 보는 과정 에서 개발에 대한 흥미가 생겨나게 되었습니다.

하지만 사실 이정도 수준도 처음 아무 베이스도 없던 저에게 혼자 하라고 하면 절대 하지 못했을 것 같습니다. 따라서 관심이 있는 분들은 저처럼 동아리나 대외활동의 도움을 받길 추천드립니다.

코딩 경험이 없으신분 : 멋쟁이 사자처럼, 피로그래밍 등 비전공자들과 함께 하는 동아리

어느정도의 경험이 있으신분 : SOPT, 디프만, MASH UP, NEXERS, YAPP 등의 동아리

대외 활동 : ssafy, 소프트웨어 마에스트로, 42서울 등

물론 이건 제 기준이고 지원자격은 각각의 공고를 보며 잘 판단해 보면 좋을 것 같습니다.

2019 2학기 (인턴의 준비)

1학기와 여름방학을 Django 초급 과정(?)을 통해 어느정도 웹개발에 대한 감을 익혔습니다. 2학기때 '산업체 핸즈온' 이라는 과목이 있었는데 어쩌다보니 웹개발 경험이 있는 제가 팀 프로젝트를 주도 하게 되었고 Django로 웹 개발 프로젝트를 진행 하게 됩니다. 처음에는 '아 .. 내가 거의다 하겠네' 라는 생각이었지만 돌아보면 수업과 동시에 실력 향상을 얻었으니 나름 나쁘지 않은 결과였습니다. (두번 째 포폴 획득)

여기서 느낀 것은 산업체 핸즈온, 캡스톤 디자인 등의 프로젝트 과목이 있을 때 미리미리 어느정도 기술스택이 맞는 친구들을 찾아 포트폴리오로 발전 시키기 좋은 프로젝트를 진행하는것이 좋다는 것입니다. 저는 2019 2학기의 캡스톤을 해보지도 않은 안드로이드로 진행한다고 고생을 좀 했습니다. 이번 겨울 방학에 마음 맞는 친구들과 미리 접선해서 함께 공부하며 다음학기에 진행할 프로젝트를 계획해보는것도 좋습니다.

학교 프로젝트에서 더 발전해 잘 진행된 예 : eodiro.com/

어디로

중앙대 학생들만을 위한 길잡이 서비스

eodiro.com

프로젝트를 할 수 있는 과목에는 다음의 것들이 있습니다.

1학기 : 오픈소스 프로젝트, 캡스톤 디자인(2)

2학기 : 산업체 핸즈온, 캡스톤 디자인(1)

이번 학기 (2020 2학기)를 진행하며 친구중 한명은 영상처리 과목의 프로젝트를 하는데 클라이언트를 웹으로 구현한 것을 보고 이런식으로 본인의 특기를 접목시키는것도 좋다고 생각 했습니다.

3학년의 겨울 방학시즌에는 인턴을 꼭 하고 싶었던 저는 11월즈음 슬슬 인턴을 찾아보기를 시작합니다.

인턴 정보를 찾을 수 있는곳 : 다빈치 교육원, 로켓 펀치(스타트업 위주), 프로그래머스 등

저는 로켓펀치를 통해 Django를 사용하는 우트(www.hellowoot.co.kr/)라는 스타트업에 지원을 했고 1년동안 진행 한 두개의 프로젝트(여름방학에 멋쟁이 사자처럼에서 했던 프로젝트, 2학기에 산업체 핸즈온 프로젝트[github.com/97e57e/CAULendClassRoom])를 포트폴리오로 합격을 하게 되었습니다.

1~6월까지 6개월을 진행 하기로 했고 학교에서 전공 15학점 + 자유 3학점을 인정을 받을 수 있었습니다.

인턴을 정할 때는 꼭 개발팀이 있는지 여부, 사수가 있을지, 자체 서비스인지 등 본인이 가서 정말 개발을 배울 수 있는 환경인지에 대해 알아보셔야 합니다. 물론 알아보기 힘들겠지만 사실 이 과정부터가 진짜 시작이라고 봅니다. 결국 취준이라는것, 그것을 포함한 앞으로의 커리어에 대한 것은 모두 정보 싸움이라고 생각 합니다. 사실 인턴을 정하는것도 할말이 정말 많지만 기회가 되면 따로 글을 작성해 보도록 하겠습니다.

중요한것은 본인이 개발자를 꿈꾸고 있다면 개발적으로 성장을 이루어낼 수 있는곳을 가는게 가장 중요합니다. 저는 비록 작지만 자체 서비스를 하는 이 스타트업에서 많은 것을 배우고 성장 할 수 있었습니다.

개인적으로 서비스 규모가 아기자기한 스타트업이 기획을 포함하여 많은 경험을 해보고 많은 기반 지식을 쌓을 수 있다고 느꼈습니다. 제가 인턴 과정에서 느낀건 깊은 기술력 보다는 어느 상황에 무엇을 사용할지? 의사 결정을 어떻게 할지? 에 도움이 되는 기반 지식이었던 것 같습니다.

저는 초기에 월 150~250을 준다는 교육원에 있는 애니x직 이라는 기업과 월 80을 준다는 우트에 동시에 합격을 한 후 우트를 선택했고 그 선택이 정말 신의 한수라고 생각 합니다. (이 결정에 는전에 언급했던 병특 친구가 도움을 주었습니다.)

사실 1학기 정도 인턴 경험을 할 수 있다면 기술 스택은 큰 관련이 없다고 생각합니다. 저도 1년 동안 Djano를 공부하고 인턴도 Django로 했지만 현재 회사에서는 Spring으로 일을 하고 있습니다.

두려워 하지 말고 지원 하시길 바랍니다. 생각보다 회사는 많고 개발자는 부족합니다. 떨어지더라도 한번 한번의 면접 기회가 소중한 경험이 될것입니다.

2부를 기획했는데 쓰다보니 3부로...

다음으로

코알못이 개발자가 되기 까지 - (1)

가든리 — Tue, 29 Dec 2020 01:09:03 +0900

2021.03.26

원래 학교 후배님들을 대상으로 작성 했던 글이라 학교 얘기를 좀 써놨는데 ... 프로그래머스에 포탈이 열려서 많은 분들이 오시는것 같네요 들어오시는 모든 취준 하시는분들 화이팅 하시고 꼭 원하는 기업에 갈 수 있기를 바랍니다!! (_ _)

---

이 글의 예상 독자를 IT 기업의 개발자로 취직하고 싶은 분들 이라고 가정하고 썼지만 아니여도 상관은 없습니다 ㅎㅎ

제 소개를 하자면 저는 15학번 컴공 학생으로 이번 4학년 2학기에 운좋게 좋은 기회를 얻어 네이버 웹툰 인턴을 거쳐 카카오에 재직중인 사람입니다.

먼저 사실 취업 후기를 쓰려 했는데 취준 생활을 되돌아보니 알고리즘 풀고 전공공부 한것밖에 생각이 안나서 이게 도움이 될까? 라는 의문이 들었습니다. 생각해보면 개발자로 취업을 위해서는 정량적인 스펙, 학점보다는 개발 능력, 커뮤니케이션 능력이라고 생각을 하고 스펙나열하기는 딱히 의미가 없을 것 같아서 시간순으로 어떤 과정을 겪으며 준비를 했는지를 써보려 합니다.

저보다 일찍 개발자로의 진로를 잡으신분, 혹은 늦게 진로를 잡으신분들이 계실거라고 생각 합니다. 물론 이 글이 정답은 아니며 누군가에게는 맞을수도 맞지 않는 글 일 수도 있지만 이 글을 읽으며 앞으로의 남은 시간을 어떻게 쓸지 전략을 세우는데 도움이 되었으면 합니다.

그럼에도 불구하고 스펙을 말해보자면

졸업평점은 3.6 정도(~~사실 지금 12학점 듣고 있는데 더 떨어질것 같아요~~)이나 취준을 하며 학점이 쓸모 있던 경우는 없었으며(IT기업만지원)

토익, 토플 같은 외국어 성적은 없고(지원 할 때도 안썼습니다. 나중에 토스 lv6을 따긴 땄어요.)

자격증(정처기 필기만 따고 귀찮아서 포기)도 물론 한개도 없습니다...

3학년때 본 TOPCIT은 170점 정도 였던 것 같고 (그렇습니다 발로풀어도 못받을 점수를 제가...) 4학년 1학기때 본 TOPCIT은 500점 중후반 정도 였던 것 같습니다.

따라서 위의 것들이 필요할지도 모를 대기업이 목표이신분은 아마 도움이 크게 되지 않을수도 있겠지만 재미삼아 읽어주셔도 될 것 같습니다.

2015.03 ~ 2017.01 (1, 2학년 시기)

딱히 처음부터 코딩에 흥미가 있던건 아니었습니다. 누군가는 그렇듯 대충 점수를 맞춰서 온 학과였고 컴퓨터공학과가 뭘 하는곳인지도 모르고 처음보는 c언어는 정말 난해했거든요. 대부분의 시간을 술과 오락으로 보낸것 같습니다... 그래서 덕분에 3, 4학년때 더 공부에 집중 할 수 있었을지도요...

2학년을 마칠 때 까지는 뭔가 이렇다 할 만한게 없어서 민망합니다. 운이 좋았던건 바로 옆에(같은 학사에 살던) 코딩을 정말 잘하는 선배가 계셨고 이 선배가 대부분의 코딩과제를 도와줬다는것... 덕분에 코딩은 할줄 모르지만 코딩 과제는 점수가 항상 높았습니다. (이 자리를 빌어 그분께 다시한번 감사의 인사를... 이분에게는 요즘도 많은 도움을 받고 있습니다.) 물론 개념이 없으니 시험을 못보고 학점은 항상 낮았습니다. 2학년을 마칠 때 까지 평균 3.1~3.2정도의 학점을 받았습니다. (사~~실 도움을 못받았다면 학점이 어떻게 됐을지는...~~)

하지만 운이 좋게도 예전부터 중 고등 수학 방정식같은걸 푸는걸 좋아했던 저는 코딩은 못했지만 이론과목에는 흥미를 느꼈습니다.

오토마타, 컴퓨터 구조, 이산수학 등이 그 예입니다. 아마 이런 과목들은 대부분 A0 ~ B+ 정도였고 객체지향 프로그래밍, 소프트웨어프로젝트 같은 과목은 C+을 받았던 걸로 기억 합니다. (2년간의 학교생활에서 유일한 A+은 회계와 사회였던것같네요)

하지만 오토마타, 이산수학 등이 되돌아보면 저의 성장에 큰 도움을 줬던 과목들인것 같습니다. 물론 화려한 코딩 스킬도 중요하지만 결국 개발자의 본질은 문제를 해결하는것이고 문제 해결을 위한 뭐랄까 컴퓨터공학도에게 필요한 생각하는 방식이라던지 사고 능력을 많이 길러준 과목들이라고 생각합니다. (교수님 그래도 쿼터스는 좀 .. ㅠㅠ) 위와 같은 이론 과목에 대해 부정적인 생각을 가진 후배님들이 계신걸로 알고 있습니다. 물론 아닌경우도 있겠지만 만약 개발자를 꿈꾼다면 위의 과목들을 수강하며 했던 훈련들은 문제 해결 능력을 길러줄 기반을 잘 다져주었을거라고 생각 합니다.

아무튼 이 시기는 사실 별게 없고 요약 하자면 코딩을 잘 몰라도, 잘 못해도 이 기간에 배우는 많은 이론 과목들은 나중을 위한 기반을 다지기 위한 훌륭한 과목들이라고 생각 합니다.(어셈블리언어같은건 잘 모르겠네요...) 아무튼 이 시기까지 코드를 잘 짜지 못해도 너무 걱정할 필요가 없다고 말해주고 싶었습니다 ㅎ.ㅎ..

2017.01 ~ 2019.02 (구닌)

2학년을 마치고 군대를 갑니다. 물론 누구나 그렇듯 공부 열심히 해야지! 라는 마음을 가지고 입대를 하지만 운동만 열심히 하다가 나옵니다.

아마 전역하기 한 두 달 전쯤 친구를 찾아가 여러모로 상담을 하게 됩니다. 그 친구는 당시 병특 생활중이었고 개발자로 지내고 있었습니다. 아마 그런 친구를 보며 저친구는 벌써 저렇게 잘하는데 나는 뭐지? 라는 불안감과 초조함이 있었을테고 3년 반동안 열심히 놀아서 코드 한줄 제대로 못 짜는데 진로를 바꿔야 하나 라는 생각도 들었습니다. (의경 생활을 했는데 진지하게 순경시험 칠까를 많이 고민 했습니다.)

친구는 자신이 만든 포트폴리오 등을 보여주며 '멋쟁이 xx처럼' 이라는 동아리를 추천해 줍니다. 웹 개발이 뭔지, 프론트 엔드, 백엔드가 있다는 둥 아마 가장 기본적인 것들을 이 때 들었던 것 같습니다. 이런저런 이야기를 들으며 앞으로의 계획에 대해 생각 해보게 되었습니다.

돌아보면 코딩에 갖는 흥미는 늦었지만 친구 덕분에 웹개발은 꽤나 빨리 접했고 경쟁력이 있었을지도 모르겠습니다.

돌아보면서 주변 사람들도 참 중요한것 같다고 느꼈던게 아마 개발을 잘하며 저에게 가이드를 해주던 위에 언급했던 그 형님과 친구가 없었다면 저도 진즉 진로를 바꿨을지도 모르겠습니다.

아무튼 이런 상담을 통해 전역하기 한달 전 쯤(2018. 09쯤) 일주일 정도 생활코딩의 Web n (html, css) 강의를 듣다가 곧 전역인데 뭔 공부야 ㅎ 하면서 때려쳤던것 같습니다. . .

쓰다보니 길어질 것 같아 시리즈로 나눕니다...

다음으로

spring - validation (유효성 검사) 하기

가든리 — Mon, 7 Sep 2020 23:13:27 +0900

Validation을 해보자

웹 개발을 하다 보면 서버에 들어온 요청이 서버에서 요구하는 스펙에 잘 맞게 들어왔는지 검사해야 할 필요가 있습니다.

예를 들어 회원가입을 할 때 이름은 필수로 들어와야 한다던지, 나이는 0보다 커야 한다던지 같은 것 입니다.

물론 이런 식으로 들어온 요청에 대해 검사를 할 수도 있을 것입니다.

//이름이 비어있으면 exception을 던진다.
if (request.getName() == null) {
	throw Exception;
}

// 나이가 0보다 작으면 exception을 던진다.
if (request.getAge() < 0) {
	throw Exception;
}

하지만 점점 커지는 웹 어플리케이션 에서 위처럼 요청에 대한 검사를 하다 보면 필드가 늘어남에 따라 코드의 대부분이 유효성 검사 코드로 뒤덮일 것입니다.

스프링에서는 이런 상황을 방지하기 위해서 손쉽게 Validation을 하기 위 전략 중 하나로 Hibernate Bean Validator를 사용할 수 있습니다.

Hibernate Bean Validator는 유효성 검사를 해야 하는 필드에 @NotEmpty, @NotNull, @Max와 같은 어노테이션을 붙여줌으로써 유효성 검사를 진행할 수 있습니다.

Bean Validator 사용 하기

먼저 Hibernate bean validator에 대한 의존성 설정을 해야 합니다.

pom.xml

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-validator</artifactId>
   <version>6.1.5.Final</version>
</dependency>

스프링 부트 + gradle를 사용할 경우는 다음과 같이 해줍니다.

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-validation'

	// 기타 의존성
}

예시를 위해 간단한 회원가입 시 사용할 Dto 클래스를 만들어 보았습니다.

public class MemberDto {
    
    private String realName;
    
    private String password;
    
    private String nickName;
    
    private int age;
}

회원 가입을 위해서는 [이름, 비밀번호, 닉네임, 나이]가 필요합니다.

@RestController
public class MemberController {

    @PostMapping("/member")
    public String createMember(@RequestBody MemberDto memberDto) {
        System.out.println("memberDto.getRealName() = " + memberDto.getRealName());
        System.out.println("memberDto.getPassword() = " + memberDto.getPassword());
        System.out.println("memberDto.getNickName() = " + memberDto.getNickName());
        System.out.println("memberDto.getAge() = " + memberDto.getAge());
        // 비지니스 로직이 들어가는 자리.
        return "성공!";
    }
}

간단하게 "/member"에 MemberDto를 RequestBody로 받아보았습니다.

아래 보이는 것처럼 Postman을 통해 요청을 보내 보니 요청이 제대로 도달한 것을 알 수 있습니다.

하지만 여기서 RealName이나 Password를 보내지 않으면 어떻게 될까요?

Password를 빼고 보내도 Password가 null로 찍힐 뿐 요청을 처리하는데 아무 문제가 없었습니다.

하지만 우리는 요청으로 받는 Request의 Body에 RealName과 Password가 Null이면 요청을 거부하고 예외 처리를 해주고 싶습니다.

그럴 때는 아래와 같이 RequestBody를 받는 부분 앞에 @Valid 어노테이션을 붙여줍니다.

그리고 Dto 클래스에 가서 Non-Nullable 하게 만들고 싶은 필드에 @NotNull 어노테이션을 달아줍니다.

public class MemberDto {

    @NotNull
    private String realName;

    @NotNull
    private String password;

    private String nickName;
    
    private int age;
}

이 상태에서 다시 Password를 빼고 요청을 보내보면!?

클라이언트에서 요청을 잘못했다는 400 status code와 함께 에러 리스폰스를 응답해 준 것을 볼 수 있습니다.

서버 쪽에는 아래와 같이 MethodArgumentNotValidException이 발생하게 됩니다.

Resolved [org.springframework.web.bind.MethodArgumentNotValidException: 
Validation failed for argument [0] in public java.lang.String 
garden.practice.validation.MemberController.createMember
(garden.practice.validation.MemberDto): 
[Field error in object 'memberDto' on field 'password': rejected value [null];
codes [NotNull.memberDto.password,NotNull.password,NotNull.java.lang.String,NotNull]; 
arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [memberDto.password,password]; 
arguments []; default message [password]]; default message [널이어서는 안됩니다]] ]

우리는 이런 에러를 exception handler를 통해 응답에 메세지를 담아 넘겨주는 등의 행위를 할 수 있을 것입니다.

Bean Validator 에는 @NotNull 어노테이션뿐 아니라 @NotEmpty, @Max, @Min, @Length와 같은 여러 가지 어노테이션이 존재합니다.

어떤 어노테이션이 존재하는지는 공식 문서 (docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#section-builtin-constraints) 에 가면 자세히 나와 있습니다.

또한 javax.validation.constraints 패키지에 가면 어노테이션의 구성을 볼 수 도 있으니 궁금하신 분들은 찾아보시길 바랍니다.

이렇게 Bean Validation의 사용법에 대해 알아보았습니다.