2~3분기 동안 진행한 것

개발

• Spring Batch 스터디
  • 이전부터 진행하던 점심 인강 듣기 스터디(?)를 꾸준히 진행하고 있다. 현재 절반 가량 수강한 상태다. 확실히 인강으로 같이 하는걸 진행하니 진도가 느려서 다음엔 다른 방식을 선택해보려고 생각중이다.
• Clean Code 스터디
  • 팀내 코드리뷰에 긍정적인 영향이 있었으면 좋겠다는 생각에 Clean Code 스터디를 주도해 시작했다.
  • Spring Batch 와 마찬가지로 팀원들에게 부담을 주고 싶지 않아서, 팀장님의 허가를 받아 업무 시간의 일부를 사용하고 스터디 시간 안에 스터디가 끝나는 방식을 고안했다.
  • 스터디 방식으로 삼색볼펜법 방식을 적용했다.
  • 확실히 업무 시간에 진행하고, 그 시간안에 끝내니 서로 부담이 적었고 짧은 시간안에 몰입해 집중할 수 있다는 장점이 있었다.
  • 너무 호흡이 긴 책은 이 방식을 적용하기 어렵겠지만 비슷한 종류의 책으로 스터디를 진행한다면 이 방식을 다시 적용해볼 것 같다.
• HTTP 완강
  • 계속 미뤄지던 영한님 HTTP 강의를 완강했다. HTTP 책을 보기엔 부담스럽고 지식이 부족하다면 보기 좋은 강의 같다.
• 만들면서 배우는 클린 아키텍처 스터디
  • 스터디는 완료하고 프로젝트 진행을 간단히 해보았다. 서로의 코드리뷰를 보고 배운 점이 많았다.
• 사내 기술 블로그 작성
  • 이전에 했던 프로젝트 중 혼자 이끌어간 프로젝트로 회사 기술블로그에 쓸만한 내용이 있어서 처음부터 복기하면서 포스팅을 작성했다.
  • 여전히 어렵고 완전히 모든걸 알고 있다고 말하긴 어렵지만, 다시 복기하며 프로젝트에 대한 이해도가 높아져 한편으로는 아쉬움도 있었다. 지금의 내가 그 프로젝트를 다시 맡게 된다면 더 잘 할 자신이 있다는 생각이 들어서 인 것 같다.
  • 회사 블로그에 글을 쓴다는 건 생각보다 주변에 영향을 주며, 어렵고 공부가 되는 일인 듯 하다. 제대로 알고 쓰기 위해서 추가로 공부할 내용이 정말 많았고 잘못된 정보를 주지 않기 위해 신중해야했다. 애매하게 알고 넘어간 것도 다시 확인을 하게 되었다. 그리고 블로그에 글을 쓴 것 만으로 팀내 팀원들이 읽어보게 되고 타 팀에서도 내 글을 읽고 댓글을 남겨주었고, 이후 멈췄던 사내 기술 블로그에 타팀에서 글이 적극적으로 올라오는 것을 보면서, 이런 공식적인 활동이 팀내외로 긍정적인 영향을 끼치는 구나 생각이 들었다.
• 인프런 카프카 강의
  • 카프카 공부하다보면 알게되는 데브원영님 강의를 면접 준비하며 듣게되었다. 새로 알게 되는 것도 있었고 아는 내용도 있었다.
  • 카프카 초심자보다는 이미 알고 있는 중급자가 아는 내용을 정리하기 위해 듣기 좋은 강의인 것 같다.

이직 준비

• 경력 이력서 작성
  • 입사 후 한번도 이력서를 정리한 적이 없어서 경력 이력서 정리를 시작했다.
  • 3년 전 일을 갑자기 꺼내는 건 너무 어려운 일이었다... 이력서 정리는 아무리 바빠도 매번 제때제때 해야하는 듯 하다
  • 이력서를 쓰면서 나를 많이 돌아보게 되었다. 이런 부분은 부족하구나, 이런 부분은 강점이 될 수 있겠다.
  • 한가지 확실했던 건 지금 상태로 4년차가 되면 경쟁력이 떨어질 것 같다는 생각이 들었다. 그래서 이직을 본격적으로 준비해야겠다는 생각이 들었던 것 같다.
• 공격적인 이직 준비
  • 사실 실제로 이직 준비를 하게된 이유는 광고 때문이었다.
  • 이력서를 완성하고 나니(?) 이상하게(?) SNS, 웹서핑 중에 모집 공고가 자주 광고로 올라왔다.
  • 그 중 편하게 지원할 수 있다고 강조하는 회사의 채용 공고를 보고 이력서만 간단히 넣어봤는데 바로 다음날 서류 통과와 코딩테스트를 보게되었다. 코딩테스트를 못봐서 떨어질 줄 알았는데 1차 면접까지 가게되었다. 하지만 3년만의 첫 면접은 준비도 부족했고 대답도 제대로 하지 못했다. 개인적으로 가고 싶은 회사였기에 면접 전까지 일사천리로 진행되는 것을 보고 더 아쉬움이 들었고, 이 지원을 계기로 좀 더 공격적으로 지원을 하게 되었다.
  • 떨어진 곳도 지원하는 곳도 모두 네카라쿠배어쩌고 라인이었다
  • 현재 회사도 좋은 회사지만, 좀 더 적극적인 개발 문화가 있는 회사에 가고 싶었던 게 큰 이유였던 것 같다. 다른 뜻이 있었다면 스타트업도 생각해보았을 텐데 아직은 큰 시스템을 좀 더 경험해보고 싶다는 생각이 컸다. 스타트업 경험이 없어서 아직은 아니지만 추후 스타트업 지원을 생각해볼 수도 있을 것 같다.
  • 회사를 다니며 이직 준비를 하는 건 쉽지 않았다. 물론 평소에 아침 저녁으로 영어 공부와 개발 공부를 개인적으로 하고 있지만, 컨디션이 안좋거나 하기 싫을 때 쉴 수 있는 개인적인 공부와 달리 이직 준비는 그럼에도 불구하고 해야한다는게 힘들었다. 업무에 가급적 영향을 주지 않게 하려 했지만 몇번 휴가도 쓰게 되었다.
  • 서류 제출, 코딩테스트, 전화면접, 사전과제, 비대면 면접.. 회사마다 요구하는 것도 다양했다.
  • 채용 전형은 최대 2~3개까지 진행할 수 있었다. 토너먼트 형식으로 Max 수치만큼 맞추고 하나가 탈락시 다른 곳에 새로 서류를 넣는 방식으로 진행했다.

그리고 합격

• 그리고 다행히 지원했던 곳 중 한 곳에 합격을 하게 되었다.
• 개인적으로는 두 곳 이상 합격하고 싶었지만 함께 진행한 회사에 탈락해서 최종적으로 한 곳만 붙은 점은 좀 아쉬웠다.
• 굉장히 면접 느낌이 좋았고, 가장 갈증이던 개발 문화에 대한 것도 충족시킬 수 있는 회사로 보여서 기대가 된다.

앞으로 해야할 것

앞으로 계속 빅이벤트만 남아있다.

• 퇴사 준비 -> 송별회 -> 이사 준비(대청소) -> 집알아보기 -> 입사 -> 이사 -> 수습 3개월 -> 병원 -> 어쩌면 수술(?) -> 면허 취득

남은 올해는 정말 정신 없이 보낼 것 같다. 잘 이직한 것처럼 남은 큰 산들도 무탈히 잘 넘어갔으면 좋겠다. 🙏

앞으로 하고 싶은 것

주로 공부에 대한 내용인데,

• 인프런 자바, 스프링 커리큘럼
• 인프런 코프링 강의
• 패스트 캠퍼스 강의
• 인프런 JPA 강의

입사 전까지 여유 있을 때 이 강의들을 듣고 싶다. 얼마나 들을진 모르지만, 여유 있을 때 기본기를 한번 더 다지고 들어가고 싶어서, 가급적 열심히 들어야겠다는 생각이 든다.

기타 생각들

1년 전 쯤부터 블로그를 처음 쓰기 시작했을 때만해도 여러가지로 마음이 불안했다. 현재 내 경력이 물경력은 아닐까, 여태 업무해온 것이 어떤 의미가 있을까 등등 하지만 차근차근 블로그도 쓰고 하고 싶은 공부도 하고, 업무에서도 내가 할 수 있는 최선을 다해보니 어떻게든 길은 열린 것 같다.

마음이 너무 힘들어서 여러가지 랜선 모임을 찾고 그 분들을 보고 자극 받으며 공부를 슬슬 다시 시작한게 바로 작년 이쯤이었던 것 같다. 다시해도 되는구나, 이 세상에 늦는 건 없구나 새삼 생각이 든다.

조금씩 바꾸자 한 것들이 모여서 커다란 변화가 되었다. 일찍 자기부터 시작해 오전에 일찍 일어나기, 습관이 들면 오전에 공부하고 출근하기, 그 습관이 들면 오전 일찍 7시 출근하기, 4시 퇴근 후 공부하기 이런 식으로 습관을 하나씩 붙였다.

현재는 숨쉬듯 자연스럽게 습관대로 하고 있다.

이직 준비 또한 마찬가지였다. 위와 같이 개발 공부도 조금씩 계속 하게되었다. 업무에서도 적극적으로 하게 되면서 이력서에 어필할 부분이 많아졌다.

작은 변화가 모여 큰 변화를 만들어 냈다. 그리고 그것을 직접 겪으며 스스로에 대한 자존감, 자신감도 올라가는 것 같다.

_남은 올해의 시간들도 지금처럼 최선을 다하기를, 어제의 나보다 오늘의 내가 조금 더 발전하기를 바라며 다시 달려야겠다 _🏃‍♀️🏃‍♀️🔥

이미지 출처

백명석님의 코드리뷰 강의를 듣고 작성한 글입니다.

코드 리뷰 목적

• 주목적은 품질 문제 검수(버그, 장애)
• 추가적인 목적
  • 아키텍처 속성 개선을 위해 코드를 개선하는 것.
  • 코드, 해결책 등과 관련된 지식 공유에 기여하기 위함.
  • 집단 코드 오너십 및 결속 증대.

코드 리뷰가 어려운 이유

• 저자는 본인이 멋지다고 생각하는 PR을 보내고
• 리뷰어는 왜 멋지지 않은지에 대해 장황한 이유를 작성한다.
• 코드에 대한 비판을 자신에 대한 비판으로 이해한다.
  • 특히 상대가 직책자라면 ?
• 피드백을 _조심스럽게 표현하는 것이 중요_하다.

그래서 어떻게 하라고 ?

1. 지루한 작업은 컴퓨터로 처리한다.

• 기계가 할 수 있는 것들
  • 공백, 들여쓰기 등
• 별도의 커밋, PR로 분리해 불필요하게 리뷰할 필요 없게 한다.

2. 스타일 가이드를 통해 스타일 논쟁을 해소한다.

3. 리뷰는 즉시 시작해라.

• 코드리뷰를 높은 우선 순위로 둔다.
  • 저자는 리뷰를 받을 때까지 Block 되므로
• PR의 Size와 Complexity가 중요.
  • 작고 범위가 좁은 PR ->
  • 쉽고 상쾌하게 리뷰하기 좋음 ->
  • 빠르게 리뷰 수행
• 리뷰 라운드의 최대 시간은 하루
  • 우선 순위 높은 업무로 1일 내 불가하면 다른 리뷰어를 지정한다.
  • 재지정이 자주 일어난다면, 그 팀의 일하는 속도를 고려해봐야한다.

    4. 고수준으로 시작, 저수준으로 내려가라.

• 한 리뷰에 20~50개의 의견은 위험하다.
  • 초기 라운드에서 고수준 피드백으로 제한한다.
    • 인터페이스 클래스의 재설계, 복잡한 함수의 분리 등
  • 고수준 피드백 처리된 후 저수준의 이슈를 처리한다.
    • 변수명 변경, 주석을 명확하게 하는 것 등

      5. 예제 코드 제공에 관대해라.

• 하지만, 너무 긴 예제를 제공하는 것은 억압적으로 보인다.
• 너무 많은 예제를 제공하는 것도 안좋아 보일 수 있다.
  • 저자가 코드를 작성할 수 없다고 생각한다는 신호가 될 수 있다.

    6. 절대 "너"라고 하지 마라. (=~님도 같다)

• 리뷰의 핵심은 코드가 나아지게 하기 위한 것.
• 너라고 하는 순간 비판의 대상은 저자가 된다.
• 단어가 틀린 경우 "너 스펠링 틀렸어 00" X -> "스펠링만 정정"
• 주어만 빼라

7. 피드백은 명령이 아니라 요청으로 표현해라.

• ~해(X) / ~하는게 어떨까요?(O)

  8. 의견이 아니라 원칙에 기반해서 피드백해라.

• 저자에게 의견을 줄 때는 "제안하는 변경"과 "변경의 이유"를 모두 설명해라.
• SW는 항상 원칙에 기반할 수는 없다.
  • 단지 그냥 보기 싫거나 직관적이지 않을 수도 있음.
  • 무엇을 할 수 있을지 객관적으로 설명해라.
    • 이거 너무 혼란스러워(X)
    • 이건 이해하기 어렵다(O)

      9. 한 두 등급만 코드레벨을 올리는 것을 목표로 한다.

• D 등급이면 C나 B 등급을 받도록 도와라.
  • Working effective with legacy code
• Make it work, make it right, make it fast.
  • 첫번째만 필수고 나머지는 추가적인 것.
• 완전하지는 않아도 충분히 좋은 코드가 되도록 하면 된다.
  • 승인을 보류하는 유일한 이유는 수차례 리뷰 후에도 코드가 F인 경우

    10. 반복적인 패턴에 대한 피드백을 제한한다.

• 2~3개 정도만 언급하고 끝낼 것.
  • 개별 사례가 아닌 패턴으로 언급할 것.

    11. 리뷰의 범위를 존중한다.

• PR 범위에 대해서만 언급해라.
  • 하지만 PR이 둘러싼 코드에 영향을 미칠 경우엔 언급한다.

    12. 큰 리뷰를 잘게 나눌 기회를 찾아라.

• 400 라인 이상 리뷰는 작게 분리한다.
• 분리를 위한 논리적 경계를 식별해 짐을 덜어준다.
• 여러 파일에 걸쳐 변경했다면, 파일별로 리뷰를 나눠라.
• 코드 품질이 낮을 때 특히 리뷰 분리를 강조한다.
  • 품질이 낮은 코드 리뷰는 라인이 늘수록 리뷰하기 어려워지기 때문

    13. 진정한 칭찬을 해라.

• 잘못된 부분만 리뷰하지 말고 긍정적인 행위에 대해서도 PR 해라.

  14. 사소한 이슈만 남았다면 승인해라.

• 모든 comment가 수정되는 걸 확인하고 나서야 승인하지 않아도 된다.
• 중요한 comment가 완료되었다면 승인해도 된다.
• 아래 조건 중 하나라도 만족되면 승인한다.
  • 더 이상 comment가 없을 때
  • 남겨진 comment가 사소한 이슈일 때 (오타 등)
  • 남겨진 comment가 선택적 제안인 경우
    • ex) 높은 수준의 리팩토링 / 디자인 패턴 적용 등

      15. 교착상태를 적극적으로 처리해라

• comment를 반영하지 않고 승인 거부 하는 경우.
• 저자는 comment 반영을 거부하는 경우
  • 만나서 얘기해라
  • 인정하거나 Escalate
• 인정이 불가한 경우
  • 팀장이나 테크 리더에게 Escalation을 권유한다.
  • 다른 리뷰어에게 할당

좋은 리뷰어가 되기 위한 방법

• 학습, 연습 뿐이다.
• 사례를 공유한다.
• Letter Grade
  • Make it work / right / fast : working 할 정도로만 해라
• PR Template(Chrome Plugin 등)을 사용해라.

안하는 사람들을 어떻게 해야할까

• 자신에게 이득이 되어야 한다.
  • 멋져보여야 하고 싶어진다. 그게 뭐든
• Refactoring Tip을 공유한다.

Code Review 문화 정착의 어려움과 극복 방법

• On / Offline의 차이에서 오는 어려움
  • 꾸중 vs 토론
    • Online에서의 토론이 _꾸중_처럼 느껴질 수 있다.
• Author의 노력
  • 작성자의 노력이 제일 중요하다.
  • 어떻게 작성하느냐에 따라 다수의 리뷰어의 시간을 절약하고, 효과적인 리뷰가 가능하다.
• Leader의 관심과 의지가 필요하다.
• 코드 비난에 대한 두려움 -> 나에 대한 비난이 아니다.

PR 효과

• 예상 못한 버그를 타 프로젝트에서 발견하기도 한다.
• 선플이 달리기 시작함.
• 많은 사람이 코드를 보고 있다는 생각에 PR 올리기 전 코드를 더 다듬게 된다.
• 좋은 설계, 아키텍처, 클린코드, TDD 등에 대한 공감대가 형성된다.

기타

• 변경 내역이 많으면, 커밋을 의미있게 나눠서 한 경우 커밋 단위로 봐달라고 요청을 하자
  • 그래도 잘라서 올리자 200-400자 내외로

이 글을 쓰기 위해 Notion과 다이어리를 뒤적여봤다.

1분기 동안 진행한 것

개발

• <모두의 알고리즘 파이썬> 완독
  • 알고리즘을 파이썬으로 다시 공부해보려고, 파이썬 문법을 따로 공부하는 대신 쉬운 알고리즘 책을 한 권 뗐다. 개인적으로 개발 경력이 있는 분에게 추천하진 않지만 쉬워서 스트레스 풀이용 으로 괜찮았다.
• Spring Batch 팀 내 스터디 시작
  • 작년부터 팀 내 슬슬 언급했던 스터디를 시작했다. 빌드업 하고 보니 스터디라기 보단 인강 같이 듣기 모임(?)에 가까웠다. 매주 목요일 점심시간 1시간을 짬내서 인프런에 스프링 배치 인강을 듣는다. 듣고 공유하고 싶은 부분이나 의문점이 들면 다음 시간에 토론을 하는 방식으로 진행중이..지만 사실상 거의 인강만 듣는다.
  • 팀내 분위기가 스터디에 소극적인데, 일이 몰려오면 급격히 몰려들기 때문이고 도메인 특성상 보수적인(?) 도메인이라 그런 것 같다. 그래서 가급적 팀원들의 부담을 주지 않는 선에서 함께 공부하는 분위기를 만들어보려고 시도했고 이정도는 괜찮은 시도라고 생각이 든다.
  • 단점은, 속도가 굉장히 느리다는 것인데.. 현재 1분기 동안 강의의 30% 정도 진행했고, 지금까지의 속도를 보면 올해 말 쯤 되면 완료될 것 같다. 당장 Spring Batch를 도입해야한다면 이런 방식을 사용하지 않겠지만, 위에 말했듯 부담되지 않으며 공부하는 분위기를 조성하기 위한 목적으로는 괜찮다고 생각이 든다.
• 인프런 HTTP 강의 ~ CH6까지 (CH7, 8 남음)
  • 좀 더 주니어 일때, 기본기에 대한 공부를 해두었으면 좋았겠지만, 여러 이유로 진행하지 못해서(회고록 참조) 올해 하려고 한다. 이 강의도 그의 일환이다. 개인적으로 강의 듣는 것을 별로 좋아하지 않는데, 김영한님 강의는 늘어지는 것 없고 덜 졸립게 재밌게(?) 진행되서 듣기 싫어도 클릭해서 보게 되는 것 같다.
• 인프런 docker-compose 강의 완
• NextStep ATDD 참여
  • 넥스트 스탭에 TEST 관련 강의가 있어서 TDD에 이어 들었는데, 개인적으로는 좀 어려웠지만 인수테스트에 대해 알게 되고, 통합 테스트를 작성하는 법, 전반적인 테스트를 작성하는 법에 대해 좀 더 알게 되어 좋았다. 완전히 완료하지 못해서 2분기에 다시 진행하는 것이 목표다.
• 우아한테크세미나: 우아한 객체지향
• 토비의 스프링 일부 읽기
  • 토비의 스프링을 1~2년 전에 읽었는데 완전히 이해하지 못해서 다시 읽으려 한다. 하지만 전체를 각잡고 읽는 것보다 필요한 부분만 발췌독 해 읽으려 한다.
• <만들면서 배우는 클린 아키텍처> 스터디 진행 중
  • 회사 CTO 분께서 헥사고날 아키텍쳐로 세미나를 하시기도 하고, 주변에서 '너가 좋아할만한 책'이라는 추천이 여러번 들어와서 읽게되었다. 마침 스터디 할 연이 생겨서 스터디를 진행중이다. 현재는 책을 90퍼 정도 보았고, 이후 간단한 토이 프로젝트를 하는 것이 목표다.
• 우아한테크세미나: 실시간 음식배달 플랫폼에서 활용한 분산 이벤트 스트리밍
• 도메인 주도 설계로 시작하는 마이크로서비스 개발 읽는 중
  • 이거는 서점에서 재밌어보여서 집은 책인데 원래라면 우선순위에 밀려서 바쁘다고 안읽었을 텐데 최근 친구와 진행하는 공부 외 기술 책읽는 모임을 만들어서 꾸준히 읽고 있다 1/3 정도 읽었는데 가볍게 MSA와 DDD 에 대해서 훑는 책이라 읽어서 관련 기반지식을 알아가는 것도 나쁘지 않은 듯 하다. 이후 추가로 깊이있게 보려면 마이크로서비스 패턴 책과 도메인 중심 설계 책을 보는게 좋을 것 같다.

기타

• 영어 공부
  • 오전에 출근 전 영어 공부 1시간씩 진행하고 있다.
• 경력 이력서 쓰기
  • 당장 이직 생각은 없지만 이력서는 써둬야지 하고 미뤄뒀는데 최근에 처음으로 경력 이력서를 써봤다. 부족한 점이 많이 보이고 보강 해야겠다는 생각이 든다.

벌려 놓은 것

• 랜선 모각코 인증
  • 랜선 모각코라는 온라인 상 모각코에서 공부할 때마다 인증 중이다. 최근 다들 활동이 뜸해지는 분위기라 아쉽다.
• 일일 커밋 인증
  • 일일 커밋 인증 카톡방을 따로 들어가 있어서 커밋할 때마다 인증한다.
• 갓생살기 인증(책장 속 책 읽기, 영어 공부, 개발 공부, 운동)
  • 친구들과 갓생살기 디스코드를 운영 중이다. 자기 계발은 하고 나서의 쾌감은 엄청나지만 시작하기가 어렵다.. 그래서 동기부여를 위해 인증에 미쳐버렸다.
  • 공부 한번만 해도 모각코와 갓생살기 두군데 인증을 한다. 공부도 2배로 한 것 같고 기분이 좋다. 커밋까지 했다면 인증을 3번한다. 좋은 도파민이다.
• Spring Batch 스터디
• 만들면서 배우는 클린아키텍처 스터디
• 우아한 스터디 (신청은 했는데 될까?)
  • 이번에 우아한 스터디를 신청해봤는데 되면 일이 하나 더 벌려지지만 될지 모르겠다 된적이 거의 없다.

못한 것

• 가상면접으로 배우는 대규모 시스템 설계 6장 부터 다시 읽기
  • 블로그 포스팅 중이던 이 책을 읽다 말아서 도메인 주도 설계로 시작하는 마이크로서비스 개발 을 다 읽고 읽을 생각이다.

업무

• 기존에 하던 밥 짓는 업무를 마무리 했다. (2021 회고록 참고) 그리고 새 업무에 들어가는데 입사 이래로 밥 짓는 것 외에는 주로 Fade Out 건을 진행했다. 이번에도 그런 업무지만, 기능을 옮기면서 스터디로 배운 헥사고날 아키텍처를 적용하고 기존 코드에 테스트 커버리지를 올리려고 생각 중이다.

앞으로 하고 싶은 것

팀내 코드 리뷰 문화 및 테스트 작성 문화 만들기

• 이건 반 이상 성공적으로 진행되고 있다. 입사했을 때는 팀내 코드 리뷰는 크리티컬한 부분만 하고, 클린 코드에 대한 리뷰는 거의 없었다. 그런 분위기를 바꿔보고자 입사 이래로 코드 리뷰를 여러번 시도 했다. 나는 도메인 로직을 시니어 개발자들 보다 모르고, 대신 클린 코드나 TDD에 대해서는 그 분들보다 평소에 관심을 많이 가져서, 그 부분에 대해 주로 리뷰를 했다.
  • 코드 리뷰는 Code Level의 리뷰보다 Architecture Level의 리뷰를 하는 것이 더 좋다는데.. 아직 나는 그정도 역량이 안되서 되는 선에서 최선을 다하고 있다.
• 개발자는 Soft Skill이 중요 하다고 하는데 그에 어느정도 공감이 간다. 팀원들과 함께한지 2년이 넘어가니 팀원들도 내 성향을, 나도 팀원들의 성향을 어느정도 알고 내가 어떤 것에 관심 있고 추구하려 하는지 팀원들도 알고 있다. 그래서 원하는 의견을 좀 더 자연스럽게 관철할 수 있게 된 것 같다.
• 예전 같았으면 코드 리뷰를 무시 받는것에 상처 받았다면, 지금은 좀 덜 받고(?) 리뷰가 무시되는 빈도도 거의 없어졌다. 어떻게 보면 갓 들어온 0년차~1년차가 도메인도 잘 모르면서 Code Level의 리뷰 위주로 하는게 안좋게 보였을 수도 있을 것 같다.
• 예전에는 PR에 댓글이 0개고 Approve만 되었다면 최근 PR에서 30개 넘는 댓글을 받아 감동받았다. 내가 열심히 분위기를 만들고 기술적으로 더 뛰어난 시니어 개발자 분들이 리뷰하는 문화가 만들어진다면 좀 더 내가 그리는 이상향에 가까워질 것 같다는 생각이 든다.

팀내 기술 공유 발표

• 헥사고날 아키텍쳐라던지 TDD에 대해서 사내 코드에 적용하게 된다면 관련 내용에 대해 작게 팀 내 기술 발표를 해서 팀내 전파되도록 하고 싶다.

기타 생각들

올해 초에는 막연히 Java, Spring을 좀 더 깊이 있게 공부해보자 생각했는데, 최근 해온 것들과 관심사가 변하고 목표를 다시 세웠다. 분기 단위로 회고를 하는 건 꽤 괜찮은 것 같다.

업무에서는 클린 코드와 클린 아키텍처, 헥사고날 아키텍쳐 적용, TEST 커버리지 올리기, 자바 심화 공부를 목표로, 개인적으로는 카프카, 아키텍처 설계, MSA 쪽으로 관심 갖고 공부를 진행하려고 한다.

나에게 계획은 세워서 다 지키겠다는 의미보다는 방향성을 지정하는 것에 가깝다. 하고 싶은게 많고 시간은 부족하지만, 중요한 건 어제의 나보다 오늘의 내가 발전했는가라고 생각한다.

아는 중니어(?) 시니어(?) 개발자 분께서 할게 많으니 우선 순위를 잘 세워서 공부해야한다고 하셨는데 그 말에 공감하면서, 당장 눈앞에 재밌어 보이는걸 하자 라는 생각도 들었다. 직장인이 회사 업무 외 일을 한다는 것은 시간과의 싸움에 가깝고 하고 싶은건 많지만 시간도 체력도 따라주지 않는다. 그만큼 이상적인 우선 순위 대로 공부하는 것도 좋지만 당장 내가 관심가고 하고 싶은 것을 먼저 공부하는 것도 나쁘지 않다고 생각한다.

개인적으로 나는 8시간 근무를 기준으로 하루에 낼 수 있는 순수 시간은 3시간 인 것 같다. 이 이상 잠을 줄이거나, 공부 시간을 늘리면 기본적인 생활에 지장이 간다. 단 3시간 뿐이라 더 공부와 생산성에 관심을 갖게 된다.

그래서 예전이라면 공부하는 것은 주로 타이핑하고 요약해서 정리를 했다면 요즘은 읽고 흘러가는 대로 두는 것도 괜찮다고 생각한다. 모든 걸 다 기억할 순 없고, 나는 기억력이 나쁘고, 그 당시 읽고 지나가더라도 이해한다면 나중에 관련 일을 할 때 찾아볼 수는 있다고 생각한다. 아 그 거시기 뭐 있잖여..

또, 예전의 나는 책 한 권을 다 떼지 않으면 다른 공부는 하면 안되는줄 알았지만, 지금은 그냥 여러 권을 돌려가면서 본다. 책 1권만 본 개발자와 일부만 발췌독 했지만 100권을 본 개발자 중에 후자가 나은면도 있다고 생각하기 때문이다.

"아무 것도 모르면 아무 것도 찾아볼 수 없다. 내가 어떤걸 모르는지 모르기 때문이다."

그래서 지금은 당장 재밌어보이는 걸 공부해야겠다. 2021 회고록에 썼듯이, 열심히 한 눈 팔다보면 무엇이든 길은 나올 것이라 믿기 때문이다.

꾸준히 노력하기 위해 노력하는 사람

나는 어떤 사람인가? 한마디로 정의내린다면 위와 같을 것 같다.

그동안의 일일커밋 기록

CS 전공이지만 개발자가 아닌 다른 진로를 생각하다 개발자로 취업을 준비하게되어 2018년에 개발 공부를 제대로 처음 시작하게 되었다.

그동안은 전공 공부 정도로만 개발을 공부했다면 2018년에는 처음으로 Spring 을 공부하며 동시에 프로젝트를 진행했다. C나 Java 정도는 공부했지만 실질적으로 개발에 제로 베이스였던 내가 공부를 시작하며 동시에 프로젝트를 시작할 수 있었던 것은 함께 프로젝트를 진행한 친구가 개발을 어느정도 할 줄 알았고 메인으로 프로젝트를 끌고가 주어서 가능했다.

그 당시 Spring 공부와 프로젝트, 23학점의 수업, 졸업요건을 위한 봉사활동, 교내 아르바이트까지 동시에 진행을 했고, 정말 잠을 제대로 자지 못할 정도로 시간이 부족했다.

거의 매일 열람실과 동아리 방에서 밤을 세워 공부하다 다음날 아르바이트를 하러 갔고 모든 남는 시간은 부족한 개발 공부와 프로젝트를 하는데 사용했다. *너무 스트레스 받고 피곤할 때는 의자에서 쪽잠을 자거나 우쿨렐레를 쳤다. *

(지금 생각해보니 지켜보는 사람이 있었다면 얼마나 내가 웃겨보였을까 개발을 열심히 하다가 갑자기 우쿨렐레를 미친 듯이 치고 다시 개발하다가 치고..)

그리고 나는 프로젝트를 성공적으로 완료하고, 당시 목표였던 성적 4.3을 받았다.

누군가 인생에서 가장 열심히 살았을 때가 언제니? 라고 묻는다면 망설임 없이 2018년이라 대답할 수 있을 것이다.

개발 홀로서기

2018년의 하반기부터는 취준의 연속이었다.

프론트 엔드 친구와 두번째 프로젝트를 시작하고 서버 개발부터 배포 까지 온전히 혼자만의 힘으로 진행을 하게 되었다. 부가적으로 Effective Java와 자바 ORM 표준 JPA 프로그래밍 공부, 그리고 AWS로 CI/CD 배포하기를 진행했다.

그 당시에도 그렇고 지금도 그렇고 나에겐 멘토가 없었다. 이 다음엔 어떤 방향으로 나아가야하는지, 취업 준비는 어떻게 하는지 정보가 전혀 없었다. 그래서 당시에는 인터넷의 도움을 많이 받았다. 구글이 나의 멘토였다.

해당 시기 진행한 프로젝트는 창천향로님의 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 시리즈 도움을 많이 받았다.

나처럼 전공자임에도 정보를 얻을 수 있는 네트워크가 없던 사람, 또는 아예 새로 시작하는 비전공자 등 어떻게든 지푸라기라도 잡고 싶은 주니어들에게 양질의 개발 글을 작성해주는 개발자분들이 있어 멘토가 없이도 성장할 수 있었다. 참 감사하다.

방향 고민과 첫 대외활동

지금도 그렇지만 당시에 가장 어려웠던 것은 방향 설정이었다. 열심히는 할 수 있다. 하지만 어떻게 해야하는가? 많은 주니어 개발자들의 고민 또한 이것일 것이라고 생각한다.

그때까지의 나는 계속 소규모 개발을 해왔기에, IT 동아리 활동을 도전했다. 동아리 활동에서 기획자와 디자이너와 협업을 어떻게 하는지. 한 프로덕트가 나오기 위해서 어떤 과정을 거치는지 회사에 가기 전에 미리 배운 것 같다. 그리고 다른 백엔드 개발자와 협업을 하며 PM의 역할도 간단히 해보았다.

어떻게 어떤 방향으로 성장하는게 좋을지는 아직도 고민하고 답을 찾고 있는 문제다. 그래서 그 때도 지금도 답을 외부에서 찾아보는 중이고, 당시의 동아리 활동은 그 헤맴의 일환이었다.

그리고 취업

취준 회고를 너무 늦게 작성해서, 지금 트렌드와 조금 다르게 포트폴리오가 화려하지 않아도 원하는 회사에 취업에 성공했다.

(정확한 방향은 정하지 못했지만 내가 원했던 회사는 SI가 아니며 자체 IT 서비스가 있으며 대규모 트래픽이 발생하는 회사였다.)

내가 그동안 진행한 것은 소규모 프로젝트 2개 그리고 IT 동아리에서 진행한 프로젝트 1개였다.

그 당시는(?) 내 정보 부족일 수 있지만, 지금처럼 부트캠프나 학원이 성행할 때가 아니었고 1일 1커밋도 슬슬 알려지기 시작할 때라 많이 하고 있지 않은 상황이었다. 그래서인지 당시에 면접보러 다니던 회사 중 한 곳에서는 1일 1커밋의 성실함과 학원을 다니지 않은 것을 자신감이 있어보인다며 좋게 보기도 했다.

(지금은 워낙 1일 1커밋이 흔하고 화려한 포트폴리오가 많아서 지금 같은 포트폴리오로 신입을 도전한다면 좋게 볼지는 잘 모르겠다. )

한 가지 아쉬운 점은 계속해서 달려오느라 지쳐서, 너무 쉽게 만족해버린 것. 현재 회사에 최종 합격을 했어도 조금 더 다양한 회사에 지원을 좀 더 넣었으면 좋지 않았을까 생각은 든다.

병아리 개발자로 홀로 살아남기

취업을 하고 정말 많은 일들이 있었다.
그 중 나에게 가장 많은 영향을 끼친 일은 홀로 살아남게 된 일이다.

사수가 퇴사했다

사수의 퇴사는 뒤따라오는 Side-Effect 가 많았다.

우선 팀 내 거의 유일하게 학습과 성장에 적극적인 분이었다는 점.
따라서 그 분의 퇴사로 팀내 이런 분위기는 침체되어 버렸다. 그리고 그 분이 맡던 서비스를 떠맡게 된 것. 그리고 그 분이 남겨 놓은 똥과 내 똥이 합쳐져 빅똥이 되어 장애가 난 것. 그 장애의 뒤처리. 나도 모르는데 나한테 들어오는 모든 것들. 생각보다 엉망진창인 코드와 생각보다 심각한 팀내 레거시 등

이 과정을 홀로 헤쳐나와야 했다.

취업을 하고 알게된 것

직업으로써의 개발자

• 인터넷으로 개발을 배우다 보면 주로 유니콘같은 개발자들을 주로 보게 된다.
• 좋은 개발 문화를 지향하고 코드 리뷰를 하고 테스트 코드를 작성하고..
• 현업에서는 생각보다 그런 문화를 지향하는 분이 (회사에 따라) 드물다.
• 그게 나쁜 것인가? 그건 아니다. 지향점의 차이라는 것을 알았다.
• 좋은 개발자란 무엇인가 ?
• 우선은 업력(業力)이 제일 중요하다

무리를 해도 안되는건 안된다

• 그동안은 무리를 하면 해결할 수 있는 선이었다.
• 직업으로써의 개발자는 장기 레이스 선수이다. 그러므로 되도록 무리하지 말고 되는 데까지 해야한다.
• 안되는 일정은 조율해야한다.
• 업무에 100% 이상의 에너지를 쓰면 안된다.

레거시를 대하는 마음가짐

• 레거시는 어디에나 있다.
  • 오래된 서비스 회사는 오래되어서 있고, 최신 스타트업은 빠른 Business Delivery가 필요해 기술 부채가 존재한다.
• 오늘의 코드는 내일의 레거시가 된다.
• 레거시를 그대로 두는 이유는 보통 이유가 있어서..
• 레거시를 꼭 최-신-식 기술을 넣어서 다 뜯어 고치는게 꼭 정답일까
  • 레거시를 좀 더 잘 굴러갈 수 있게 포장하는게 올바른 역할일 수 도 있다.
• 얼마 전 들은 웨비나에서 회사는 리팩토링할 시간을 주지 않는다고 들었다.
  • 리팩토링 또한 내가 의식적으로 해야하는 것이며, 리팩토링할 시간을 주지 않는다, 없다며 불만을 가질 문제가 아닌 것.
• 그런 시간을 내는 것 또한 업무, 개발의 능력이라는 생각이 든다
• 최우선은 리팩토링의 욕심보다 정해진 일정 준수 뒤 부가적으로 욕심내는게 맞는 것.
• 이런 능력을 기르고 노력한 뒤, 조금 빨라진 속도로 생긴 조금의 여유를 리팩토링과 코드 개선에 투자해야하는 것 같다.

번아웃 그리고 코로나 블루

절망의 계곡 헤매기

더닝 크루거 곡선에서의 절망의 계곡

사수의 Side-Effect를 헤치고 나온 나에게 주어진 다음 일은 밥 하는 일이었다.

그런데 밥 하는건 좋은데 밭갈고 농사부터 하게 될 줄이야..?

마치 농사를 처음 짓는데, 1등급 쌀을 지어서 임금님께 바치세요 같은 느낌이었다. 하지만 팀 내 아무도 1등급 쌀을 수확하는 농사법은 모르는 상황이었다.

입사 전 소박한 Monolithic Architecture를 만들던 나는 갑자기 MSA의 시스템 설계를 하고, 개발하게 되었다. 그것도 혼자. 농사를 짓는 건 어렵지 않았다. 하지만 정답이 없는 1등급의 쌀을 지어야하는 것이 어려웠고 큰 부담이었다.

그 당시 공부를 하면 할수록, 사내 문서, 공식 문서, 구글링, 한국 공식 기술 모임, 온갖 세미나 영상, 이름 모를 오래된 Blog 등을 찾아볼수록 더 어려웠다. 말 그대로 절망의 계곡이었다.

초조한 제자리 걸음

학습에 관한 글 중 개인적으로 좋아하는 글이 있다.

• 당신이 제자리 걸음인 이유와 의도적 수련

의도적 수련과 성장에 관한 글이다.

간략하게 요약하자면 사람은 너무 쉬우면 지루하고, 너무 어려우면 불안함을 느낀다. 그 모든건 몰입을 방해하는 요소이며 제자리 걸음을 걷게 하는 요소이다. 성장하기 위해서는 몰입 영역에 들어가기 위한 의도적 수련이 필요하다는 요지이다. 너무 어려운 경우 나의 실력을 높이거나, 업무의 난이도를 낮춰서 몰입할 수 있도록 해야한다.

나는 이 기간에 많이 성장했지만 그럼에도 불구하고 많은 불안감과 초조함을 느꼈던 것 같다.

슬럼프의 극복과 지속 가능한 개발

성장하는 환경 만들기

사람은 생각보다 의지보다 환경의 영향을 많이 받는다. 모든 일은 노-오-력만으로 되지 않기도 한다. 성장하는 환경 또한 마찬가지이다.

얼마전에 본 토크 콘서트에서도 비슷한 이야기가 나왔다. 창의적인 인재란 "얼마나 창의적인 생각을 해낼 수 있냐"보다 "얼마나 창의적인 상황에 자신을 던질 수 있는지"가 중요하다고 말이다.

이 내용을 성장에 빗대어 본다면, 나는 얼마나 성장할 수 있는 환경에 나를 던질 수 있는지 생각해보게 된다.

그동안은 현재 팀이 의식적으로 성장하는 환경이 아니라는 생각에 외부로 눈을 돌렸다. 주로 인프런 등의 강의를 들었고 Next Step의 TDD 수업도 들었다. 특히 여기서 슬럼프 극복에 도움이 된 것은 Next Step의 TDD 수업이었다.

• 우선 개발이 다시 쉽고 재밌었으며
• 열정 넘치는 사람들에게 둘러 쌓인 환경이었고
• 끌어주는 멘토(자바지기님)와 리뷰어가 있었다.
• 그리고 코드 리뷰를 배웠다.

그리고 지금은 내부로 시선을 돌려 팀을 성장하는 환경을 만들기 위해 소소하게 나마 내가 할 수 있는 선에서 행동하고 있다.

그동안

• 업무의 특성
• Top-Down 으로 급하게 내려오는 일정
• 개별 프로젝트로 각자 파편화된 업무

등의 이유로 팀 내 코드리뷰가 거의 이루어지지 않았는데, TDD 수업에서 배운 것을 기반으로 소소하게 팀 내 코드리뷰를 시작했다. 작은 시도지만 다른 분들도 코드리뷰를 조금씩 하기 시작하는 등의 변화가 일어나는 것이 눈에 보인다.

그리고 개인적으로는, 랜선 모각코를 들어갔다. 업무에 집중하기 위해 사이드 프로젝트나 IT 동아리 활동을 하기 보다는 회사일과 관련된 공부를 꾸준히 하고 싶었다. 기존에는 오프라인으로 친구들과 만나 공부했지만 코로나로 인해 이전과 같이 할 수 없어 랜선에서의 모임을 찾아봤다. 열심히 공부하는 사람들 사이에 나를 던져 놓아 성장하는 환경을 만들었다.

나의 보상 체계는 성취감

지속 가능한 개발, 지속 가능한 공부를 위해서는 자기 자신과의 약속을 지키고 스스로에게 보상을 확실히 주어야한다. 그런 의미에서 일일커밋을 다시 시작했다.

일일커밋에 대해 부정적으로 또는 긍정적으로 보는 상반된 의견이 있는 것으로 알지만 내 일일커밋은 개인적인 동기부여이다. 초록색을 채우는게 마치 RPG 게임의 경험치 바를 채우는 느낌이 들고 눈에 보이는 지표이기 때문이다.

억지로 커밋을 하지는 않을 것이다. 가급적 하루에 간단한 코드 한줄이라도 짜보자 는 느낌으로 가볍게 시작해보려고 한다.

그동안의 성장에 대한 갈증과 생각들

• 너무 많은 걸 다 잘하고 싶어 마구잡이로 교육을 들었다.
  • 소화하지 못한 배움은 결국 체한다. (마음만 초조해짐)
  • 모든 걸 다 잘할 순 없다. 선택과 집중이 필요하다
  • 모르는 걸 잘 인정하는 것 또한 좋은 개발자가 아닐까.
• 깊게 꼭꼭 씹어 소화시킬 것인지 빠르게 훑고 지나갈 것인지 정답은 없지만, 전자로만 살아왔으니 빠르게 훑는 연습을 해야겠다.

• 나는 입사 전의 나보다 개발자로 성장했는가 ? -> YES
• 나는 입사전의 나보다 의식적으로 개발자로 성장했는가 ? -> 모르겠다

• 일을 하지 않는게 아닌이상 성장하는 건 너무 당연하다. 거의 제로베이스이기 때문에.
• 하지만 여러 슬럼프와 번아웃으로 인해 나는 내가 생각한 것보다 의식적으로 성장하지 못했다.

• 하지만 개발 외적으로 겪은 이런 혼란스러운 감정들은 사회초년생들이라면 으레 맞닥드릴만한 상황들이 아니었을까.
• 나는 조금 헤맸고, 그만큼 성장했다. 지금의 깨달음은 앞으로 사회생활, 개발자로의 생활에 도움이 될 것이라 생각한다.
• 아직은 정확히 무엇을 개발하고 싶은지, 하고 싶은지 모르겠지만, 주어진 것에 최선을 다하며, 최선을 다해 한눈을 팔다보면 무엇이든 생길 것이라 믿는다.

올해의 목표

• 의식적으로 성장하기
• 적극적으로 기록하기
  • 취업 후 바쁘기도 하고 글쓰기의 생산성이 떨어진다는 생각에 기술 블로그를 중단했었다. 올해는 부담 없이 간단히 기록에만 집중하기 위해 Git Blog에서 Velog로 옮겼다.
  • 간단한 글을 자주 쓰자. 생산성과 글의 퀄리티 사이의 간극은 차차 메워가자.
• 건강하기
  • 취업을 하고 무리를 하면서 체력이 달린다는 느낌을 많이 받았다. 영양제와 운동을 꼭 챙기자.

그리고 마지막으로,

• 현재의 리듬을 즐길 것.
• 적정한 나 자신이 될 것.

*잘 지내보자 2022 ! *

<대규모 시스템 설계 기초> "5장 안정 해시 설계"를 읽고 작성하는 포스트 입니다.

안정 해시(Consistent Hashing) 이란?

안정 해시(Consistent Hash)는 일반적으로 요청 또는 데이터를 서버에 균등하게 나누기 위해 일반적으로 사용되는 기술이다.

전통적 해시 테이블(Hash Table)

전통적인 Hash Table의 경우 모듈로(%) 연산을 이용한다

ex) serverIndex = hash(key) % N (N은 서버의 개수)

이 경우 적용하려는 대상(서버 또는 데이터)의 갯수가 고정되어 있는 경우 문제가 없지만, 해당 대상이 추가 되거나 삭제 되는 등의 변동이 있는 경우, 대부분의 해시 대상이 재분배 된다. 따라서 확장성(scalability)에 취약하다

해시 키 재배치

해시 키 재배치란, 책에 나온 예를 들자면 Key 8개와 서버 4대가 있을 때 Key는 2개씩 0, 1, 2, 3에 할당되어 있지만 서버 1대가 장애가 나는 경우 서버 대수(위 수식의 N)를 기반으로 해싱하기에 모두 새로 해싱되어 해시 키가 재배치(Rehash) 된다. 이 경우 장애가 발생한 서버에 보관된 키를 제대로 찾지 못해서 대규모 Cache Miss가 발생하게 된다.

안정 해시와 해시 테이블

이런 해시테이블과 다르게 안정 해시는 해시 테이블 크기가 조정될 때 평균적으로 Key/N(위의 서버 수와 동일)의 키만 재배치하도록 하는 해시 기술이다.

안정 해시는 전통적 해시 테이블과 다르게 모듈로 연산(%)으로 대상을 탐색하지 않으며, Hash Ring을 만들어 링 위에서 첫번째 만나는 것을 대상으로 한다.

이미지 출처

1, 2, 3, 4의 서버가 있을 때 A의 대상 서버는 2이다. 위와 같은 구조일 때 서버 2에 장애가 난다면 A는 2가 아닌 3 서버에 재배치될 것이다.

안정 해시 기본 구현법의 문제

• 균등 분포 해시 함수를 사용
• 시계 방향 첫 번째의 서버를 지정하는 것

이 해시의 문제점은 균등 분포 해시 함수를 사용해도 해시 파티션(partition) (위 그림의 링 위의 서버 사이의 간격) 의 크기를 균등하게 유지하는게 불가능 하다는 것과 이로 인해 키가 균등하게 분포되기 어렵다는 문제가 있다.

이를 해결 하기 위해 가상노드(Virtual Node) or 복제(Replica)라 불리는 기법을 사용한다

안정 해시의 가상 노드(Virtual Node)

이미지 출처

하나의 서버는 링 위에서 여러 개의 가상 노드를 가지게 된다. (우측 그림) 따라서 안정 해시는 탐색 후 첫번째 만나는 서버를 대상으로 하므로, 가상 노드가 없는 좌측 그림의 구조와 달리 가상 노드가 많을 수록 키의 분포가 균등하게 된다. *가상 노드의 개수를 늘릴 수록 표준 편차의 값은 떨어지지만 가상 노드 데이터를 저장할 공간은 더 많이 필요하므로 시스템의 요구사항에 맞는 적절한 수치가 필요하다. *

추가적으로 찾아본 것

읽다보니 주 스택으로 사용하는 Java에서의 Hash는 어떻게 구현되어 있나 궁금함이 생겨 검색해보니 아래의 글이 나왔다.

• Java의 Hash Collection
  • Java 7에서 Java 8의 Hash 구현 변화와 해시 충돌을 막기 위한 보조 해시 함수에 대한 내용, String 객체에 대한 해시 함수 내용이 있다. 고퀄리티의 글이라 읽는 것을 추천한다.
  • Java의 HashMap에서는 해시 충돌 방지를 위해 Seperate Chaning과 보조 해시 함수를 사용하고, Java8의 경우 Separate Chaning에서 Linked List 대신 Tree를 사용하기도 한다.
  • 웹 어플리케이션 서버의 경우 HTTP Request가 생성될 때마다 여러개의 HashMap이 짧은 시간내 생성되고 사라지기에 GC의 대상이 된다.

또, 책 내에서 참고 문헌으로 든 Discord의 Scaling 사례가 있다.

• Discord의 Scaling
  • Discord에서는 Fast Access를 위해 Consistent Hashing 을 사용하고 있으며 사용 후에도 Node 조회에 이슈가 있어 세마포어를 구현해 Node 조회 이슈를 해결한 문제에 대해 설명하고 있다.

하단에 링크 추가한 Line 블로그의 이미지입니다.

<대규모 시스템 설계 기초> "4장 처리율 제한 장치"를 읽고 작성하는 포스트 입니다.

처리율 제한 장치란 ?

처리율 제한 장비(Rate Limiter)는 클라이언트가 보내는 트래픽의 처리율(Rate)을 제어하기 위한 장치다. 일반적으로 정의된 임계치(Threshold)를 넘어가면 추가로 들어온 모든 호출은 처리를 중단한다.

ex) 사용자 는 초당 2회 이상 새 글을 올릴 수 없다.

처리율 제한 장치를 사용할 때의 장점은

• Dos 공격에 의한 자원 고갈 방지
• 비용 절감
• 서버 과부하를 방지

등 예상할 수 있는 것들이다.

처리율 제한 장치를 설계할 시 고려할 점

해당 책에서 포인트로 잡는 것은 다음과 같다

• 처리율 제한 장치를 어디에 구축할 것인지 (클라이언트 vs 서버)
• 어떤 기준을 잡고 API 호출을 제한할 것인지
• 시스템 규모는 어느정도일지
• 분산 환경인지
• 독립된 서비스인지, Application에 포함되는지
• 장치에 걸러진 경우 사용자가 그 사실을 알아야 하는지

위 포인트를 기준으로 나온 시스템 요구사항이 이러하다고 가정을 해본다.

• 설정된 처리율 초과시, 정확하게 제한하고
• 낮은 응답 시간을 가지며
• 가능한 적은 메모리를 쓴다
• 분산형 처리율 제한(Distributed Rate Limiting)
  • 하나의 처리율 제한 장치를 여러 곳에서 공유
• 예외 처리
  • 요청이 제한되었을 때 사용자에게 보여준다
• 높은 결함 감내성(Fault Tolerance)
  • 제한 장치에 장애가 생겨도 전체 시스템에 영향을 주면 안된다.

처리율 제한 장치를 어디에 구축할 것인지 ?

• 클라이언트는 쉽게 위변조가 가능하므로 서버에 구축한다
• 서버에 구축시 같은 서버에 직접 구현하는 경우와
• 미들웨어로 처리율 제한 장치를 따로 두어 API 서버로 가는 요청을 따로 통제할 수 있다.
• 일반적으로 처리율 제한 장치는 API Gateway에 구축하는 편이다

장치에 걸러진 경우 사용자가 그 사실을 알아야 하는지 ?

• 이때 제한범위 이상의 Request를 보낸 경우 장치에서 HTTP 상태코드 429(Too many request)로 알려줄 수 있다.

어떤 기준을 잡고 처리율을 제한할 것인지?

일반적으로 처리율 제한에 사용되는 알고리즘은 다음과 같다

• 토큰 버킷(Token Bucket)
• 누출 버킷(Leaky Bucket)
• 고정 윈도 카운터(Fixed Window Counter)
• 이동 윈도 로그(Sliding Window Log)
• 이동 윈도 카운터(Sliding Window Counter)

토큰 버킷 알고리즘의 경우 지정된 용량을 갖는 컨테이너에 정해진 양의 토큰이 주기적으로 채워지고 토큰이 꽉찬 경우 채워지지 않는다(버려진다). 그리고 요청이 들어올 때마다 토큰을 하나 사용해 요청을 처리한다. 즉 정해진 크기만큼 일정 시간마다 요청을 처리할 수 있게 된다.

버킷은 몇개나 사용해야할까?

공급제한 규칙에 따라 달라진다.

• 통상적으로 API Endpoint 마다 별도의 버킷을 둔다
  • ex) 사용자마다 하루에 1번 포스팅 가능하고, 150명까지 추가할 수 있고 좋아요는 5번 가능하다면 사용자마자 3개의 버킷 필요.
  • ex) 전체 시스템을 초당 N개의 요청으로 제한하고 싶다면 모든 요청이 하나의 버킷을 공유하도록 하면 된다.

나머지 4가지 알고리즘은 처리에 대해 섬세하게 다른 부분이 있어 자세한 것은 구글 검색을 추천한다.

중요한 것은 *처리율 제한 알고리즘은 얼마나 많은 요청이 접수되었는지 추적하는 카운터를 추적 대상별로 두고 어떤 한도를 넘어서면 한도를 넘어선 요청을 거부한다는 것이다. *

그렇다면 카운터는 어디에 보관할까?

• 일반적으로 빠른 속도가 요구되기때문에 메모리에서 동작하는 캐시가 바람직하다.
• Redis가 자주 사용된다.

병행성이 심한 환경이라면 ?

• 경쟁 조건 이슈가 발생할 수 있다.
  • ex) Redis에 Counter 3을 가져와 작업을 완료해 다시 +1 하기 전에 다른 요청이 Counter 3을 가져가서 두 요청이 Counter 4를 업데이트 하는 식의 현상 (원래 값은 5가 되어야함)
• 경쟁 조건은 일반적으로 Lock으로 해결하지만 시스템 성능을 떨어뜨릴 수 있다
• Lock 대신 Lua Script와 Redis의 Sorted Set을 사용하기도 한다.

동기화 이슈

• 분산 환경에서 처리율 제한 장치 서버를 여러 대 두면 동기화가 필요하다
• 웹은 State-less이므로 웹은 기존에 가져온 장치의 정보를 가질 수 없기 때문에 Counter 관리가 정상적으로 수행되지 않는다.

  이를 해결하기 위해

• 고정 세션(Sticky Session)을 이용해 같은 클라이언트 요청은 같은 처리율 제한 장치로 보내도록 할 수 있지만, 확장 가능성과 유연성이 떨어진다.
• 대신 Redis와 같은 중앙 집중형 데이터 저장소를 쓴다.
  • 즉 분산 환경에서 처리율 제한 장치는 중앙에 1개의 서버만 사용하는 것이다.

처리율 제한장치를 모니터링 한다면

• 채택된 처리율 알고리즘이 효과적인지 확인한다
• 정의한 처리율 제한 규칙이 효과적인지 확인한다.

추가적으로 알면 좋을 것

• 경성(hard) 처리율 제한 / 연성(soft) 처리율 제한, 임계치를 절대 넘을 수 있는지 잠시 동안은 넘어도 되는지 차이
• 예시는 Application Layer지만 OSI 다양한 계층에서 처리율 제한 가능하다는 것
• 클라이언트는 어떻게 설계하는게 좋을까 ?
  • 클라이언트 측 캐시를 사용해 API 호출 횟수를 줄이고
  • 임계치를 알고 짧은 시간동안 너무 많이 호출하지 않도록 하고
  • 에러나 예외를 Gracefully하게 복구하도록 하며
  • 재시도(retry) 로직을 구현할 때는 back-off를 충분하게 둔다

추가적으로 찾아본 것

Ratelimit 오픈소스

예제로 나온 Ratelimit 오픈소스

• 버킷 알고리즘을 읽으면서 버킷이 아주 많이 생성될 것으로 예상되었는데 Domain과 Desctiptors, limit 조건, now 시간을 기준으로 Redis Key를 만들어 캐싱하고 있었다.
  • 수가 엄청 나게 많아져도 Redis Key로 생성하는 것이므로 문제가 없나보다 (?)
• 해당 오픈 소스는 근사치까지 최대한 처리하고 처리 불가능하면 HTTP 429를 보내는 것으로 보인다
• 근사치 등 처리의 근거는 레디스 캐시 서버에서 가져온다.

병행성이 심한 환경에서의 Redis의 Sorted Set와 Lua Script

Redis Sorted Set

• 토큰 버킷 알고리즘을 사용하기엔 결함이 있었다
  • 일부 프로세스는 버킷을 계속 다시 채워야함. (너무 처리할 데이터가 많다)
    • 위 Ratelimit에서 궁금했던 사항이 문제점으로 등장했다.
      • Ratelimit의 경우 내부에서 추가적으로 처리하는지 대규모 시스템에서 사용할 수 없는 수준인지는 코드를 좀 더 뜯어봐야 알 것 같다.
  • 더 정교한 방식이 필요했다
• Redis의 Sorted Set을 이용해서, 각 유저는 자신과 연결된 정렬된 집합을 가지고 있다가
• 사용자가 작업을 수행하려 하면 한 interval 전에 발생한 집합 요소를 모두 삭제한다
• 그리고 집합의 모든 요소를 가져와서 현재 타임스탬프를 세트에 추가한다
• ... 그 외 자세한 방식은 링크를 참조
• 이 방식의 장점은 모든 작업을 Redis를 이용해 원자적 작업으로 수행할 수 있다는 것
  • Redis Lua Script
    • Redis의 Lua Script는 Redis에서 명령어를 원자적(Atomic)으로 수행할 수 있게 해준다

Scaling your API with rate limiters

• 간략히 정리하면 여러 종류의 Rate Limiter를 사용해 종류별로 Rate를 제한한다.
• 이를 통해 병행성을 최대한 낮춘다.

추가로 읽어볼 것

• 고 처리량 분산 비율 제한기 by Line Engineering
  • 해당 책에서는 기본적인 Redis를 이용한 중앙집중적 구조만 나왔지만 Client Side에서 분산하는 구조도 나온다. 또한 논블로킹 구조도 있어 다양한 형태의 분산 처리기에 대해 공부할 수 있다. 현업에서 어떤 식으로 사용되는지도 확인할 수 있다.