업무 학습일지 TIL (Back-end 개발, 2022~)

[TIL ##1] 2023 업무 회고

HannaDev — Mon, 1 Jan 2024 02:55:52 +0900

▶ 목차

[1] 2023 업무 요약
[2] 2023 첫 번째 업무 - 건강 도메인 개발
[3] 2023 건강 도메인 업무 노트 中
[4] 2023 두 번째 업무 - B2B 건강 서비스 개발
[5] 2023 업무 회고 - 도서
[6] 마무리

▶ 2023 업무 요약

2023년을 요약하자면 이런 느낌이 아닐까... ~~(업무에 영혼을 갈아넣은 2023년)~~

열정있던 신입 사원은 이제 없어...

여분 목숨없이 디펜스 게임에 투입된 직장인만 있습니다 (...)

5월 ~ 12월 타임라인을 요약하자면... 이직하고 한 달 정도 잠시 공부하는 시간을 가진 후...

시간과 모든 것을 갈아넣어 두 개의 프로젝트를 마무리 지었습니다 ^-ㅠ

[공부 > 업무 > 업무...? > 업...무... > 기절 > 새업무! > ???? (혼돈) > ...ㅎㅎ 업무 > 기절]

▶ 2023 첫 번째 업무 - 건강 도메인 개발

첫 번째 프로젝트에서는 정식 앱 오픈을 준비하며 건강관련 서비스 개발을 진행했어요!

이직하면서 기술 도메인이 모두 달라져서 난관이 많을 거라고는 예상했었는데요.
[건강] 이라는 서비스 도메인 자체를 이해하는 것부터 난관이었던 프로젝트였습니다.

수험생으로 다시 돌아간 느낌이랄까... 약물 용어 공부하고 건강 검진 항목 정리하고...
건강 분석 엔진 로직 파악하면서 유사 의료종사자가 되어가는 듯한 신비한 경험이었습니다 ｡°(°°᷄◠°᷅°)° ｡

▶ 2023 건강 도메인 업무 노트 中

2023년은 특히 암기력과... 정리력이... 많이 늘었습니다 ^-^ㅠ

건강검진 도메인 및 협력 업체 로직 파악

건강검진 기획 요구사항에 따른 로직 설계

회사 위키 문서화 + 슬랙 협력채널 문의 히스토리 기록

▶ 2023 두 번째 업무 - B2B 건강 서비스 개발

두 번째 프로젝트에서는 건강관련 B2B 서비스 개발을 진행했어요!

외부 업체와 협력하는 B2B 서비스 개발이었는데 외부 업체와 협업은 처음이어서 해당 부분에서 난관이 있지 않을까 생각했었는데요.

...ㅎㅎ 그냥 모-든 부분이 난관이었던 프로젝트였습니다.

굉-장히 촉박한 일정에 기획서 보면서 협력 업체 건강 도메인 물어가며 공부하고, 기획자와 기획 정책 수립하고... B2B 사업 진행 일정도 챙기고...? 복잡한 부분 테스트 케이스도 작성하고 릴리즈 시나리오, 오픈 전 시나리오도 작성하고... 정말... 정말... 많은 작업이 몰아친 프로젝트였습니다. ~~(개발은 언제하지)~~

학부 시절에 창업 프로젝트 시작했을 때의 혼돈을 회사에서 다시 느끼게 될 줄은 몰랐는데... 확실히 지금 부서마다 문화가 모두 달라서 협업하는 방식에 있어 무언가의 정립이 필요해보이는 느낌을 많이 받았어요 ㅎㅎㅠ

어찌어찌 잘 마무리되었지만... 내가 개발자가 맞나? 직무 정체성 혼란도 느끼고 제 업무 방식에 대해서도 다시금 되돌아본 프로젝트였습니다 (ﾉ´ｰ`)ﾉ

▶ 2023 업무 회고 - 도서

그런 의미에서 2023년 업무를 회고하며 한 해 마무리를 같이 한 도서는 [프로젝트가 서쪽으로 간 까닭은 - 프로젝트 군상의 86가지 행동 패턴] 입니다!

3일에 걸쳐 완독했는데 공감되는 부분이 많네요 (oT-T)尸~~
내년 상반기에도 큰 프로젝트가 있는데 들어가기 전에 확실히 제 업무 방식에 대해서도 조정이 필요할 것 같습니다..!

낙관적으로 모든 것을 하려고 했던 과거의 나는 이제 잊고 단호하게...

소설처럼 가볍게 읽어보기 좋았습니다~!

iOS 북모리 어플 활용 - 독서 노트

▶ 마무리

돌아보니 업무도 많고 생각도 많았던 2023년이었네요! 이제 곧 3년차가 되는데 여러 의미로 레벨업은 많이 한 것 같아 그래도 후회는 없는 것 같아요. 그래도 업무 방식 재정립해서 올해처럼 힘든 한 해는 이제 그만... ╭( •̀ •́ )╮

2024년에는 기술적으로 레벨업을 이루고 싶네요! 해피 뉴 이어입니다 !

[TIL #33] 업무 마무리

HannaDev — Sun, 30 Apr 2023 02:00:31 +0900

▶ 목차

[1] 첫 회사 업무 마무리
[2] 퇴사 주간 Time Tracker
[3] 4월 Monthly Tracker
[+] NEW 기술 블로그
[+] 싱잉볼 + 바다 여행

▶ 첫 회사 업무 마무리

첫 입사일이 작년 2월 7일이었는데... 벌써 백엔드 개발자로서 1년 3개월이 지나갔네요!
흔히 사회를 정글에 비유하곤 하는데 확실히 정글은 맞았던 것 같아요 ( 　'-' )ノ)`-' )
그래도 탐험하는 재미도 있고 경악도 하고 머리도 굴리면서 썰은 많아졌네요 ㅋㅋ ~~(인류애는 줄었을지도...)~~
아쉽기도 하고 걱정도 많고 기쁘기도 하지만... 어찌됐든 이직을 하게 되었습니다 ( ˙▿˙ )/

첫 회사인 만큼 정도 많이 들고 동료 분들과 많이 친해졌지만... 커리어를 위해 다음 STEP 을 선택했어요.

동료 분들이 마지막 날 배웅해줬는데 완전 감동... 그래도 같은 IT 업계면 언젠가 다시 만나게 될거라 생각해요!

▶ 퇴사 주간 Time Tracker

퇴사 마지막 주간에는 크게 2가지 업무를 진행했어요.
- 진행 중이던 메인 화면 API 개발 업무 및 PR 마무리
- 인수인계 문서 작성 및 오프라인 설명회 개최

업무적으로는 특히 인수인계 문서 작성에 공을 많이 들였는데... 제가 생각보다 담당했던 부분이 많더라구요 ( ͡•. •͡)
특히 챌린지 (유저 활동 기반 미션 수행 기능) 부분은 복잡한 요구사항에 따라 코드 구조가 실타래가 된 부분이 많아서 정리가 어려웠어요. 최대한 추상적인 레이어에서 간략히 정리했는데... 앞으로 업무할 때는 코드 구조나 주의해야 할 점들을 미리미리 정리해 놓으면 좋겠다라는 생각이 많이 들었습니다. ‧₊˚(✘﹏✘)
그래도 올해 1월부터는 새로 시작하는 모든 업무에 대해 문서 작성을 진행해, 이를 기반으로 인수인계 문서를 빠르게 작성할 수 있었는데요. 해당 부분은 서버 개발자 세 분께 3-4 차례에 걸친 세미나 형식으로 내용을 추가 전달드렸습니다.
기술적으로는 [ElasticSearch (키워드 검색), FCM PUSH (알림 시스템), Amplitude/Braze (CRM)] + [Celery/MQ (비동기 처리 관련) + 유사 추천 로직] 을 전달드렸는데 도움이 되었으면 좋겠네요!

인수인계 문서 中

테크노트

업무 외적으로는 2가지 활동을 진행했어요.
- 짐 정리 + 동료 분들과 작별 인사 (점심 식사 / 저녁 뒷풀이)
- 독서 (상자 밖에 있는 사람) + 마지막날 퇴사 면담

업무를 모두 정리하고 남은 시간에는 책을 읽었는데, 읽은 책은 "상자 밖에 있는 사람" 이라는 소통과 협력에 관한 책이에요. 확실히 회사 생활을 해보니까 소통이 진짜! 매우! 중요하더라구요. 그만큼 어려움을 겪는 부분이기도 하구요. 아직 다 읽지는 못했지만 자기기만이라는 상자에서 나와야 한다는 부분이 인상 깊었습니다.
그리고 마지막으로 동료 분들과 식사 시간을 가지면서 작별 인사 시간을 가졌는데... 특히 기획자님 분들과는 많이 친해졌었는데 막상 식사는 많이 못했어서 너무 아쉬웠어요 ㅠㅠ 다른 팀 분들과도 평소에 식사 시간을 틈틈이 가지면 더 좋지 않았을까 조금은 후회되는 부분이었습니다.
[+] 마지막 주간 Time Tracker → 계획했던 업무/일정들은 모두 수행 완료

마지막 주간 Time Tracker

▶ 4월 Monthly Tracker

: 인수인계 문서를 무사히 마무리할 수 있어 다행이었던 2023년 4월이었습니다.
: 인수인계 문서 양식은 추후 다른 TIL 에서 다뤄보고자 해요.

4월 Monthly Tracker

▶ NEW 기술 블로그

번외로 오늘 새롭게 기술 블로그를 개설했는데요!
최근 SpinSpin 이라는 웹 서비스를 개발/운영 중인 언니를 주말에 도와주고 있어서
Infra 부분에서의 작업 내역을 정리해서 기록해 보기로 했어요 ＿〆(。。)
오늘 작성한 글은 [Infra #1] SpinSpin ELK 구축 - 공적인 기술 블로그 느낌을 원하셔서 기술 블로그처럼 작성해보고 있는데 작성하면서 조금 어색하긴 해요...ㅋㅋ ELK 구축하면서 삽질도 많이 하긴 했어서 그 부분도 시간 되면 정리해보고자 합니다!

[Infra #1] SpinSpin ELK 구축 中

▶ 싱잉볼 + 바다 여행

새로운 입사일은 5월 9일 (화) ! Refresh 를 위해 다음 주간에는 속초 바다 여행을 준비 중이에요. 마침... 싱잉볼도 와서 가져가서 명상도 하고 계획 없이 돌아다녀 보고자 합니다 ꒰⑅•ᴗ•⑅꒱

오브제 / 싱잉볼

☽ 모두 즐거운 2023년이 되었으면 좋겠습니다

5/1 (월) 낙산해변, 날씨 맑음

5/4 (목) 속초해변, 날씨 흐림

[Book #1] 만약 시간이 존재하지 않는다면 - 카를로 로벨리

HannaDev — Mon, 27 Feb 2023 02:15:55 +0900

▶ 목차

[1] 책 선택
[2] 책 소개 & 감상평
[3] 후기 (NEXT?)
[3] 번외 (양자 컴퓨터?)

▶ 책 선택

한 두 달에 한 번씩은 교보 문고로 구경 가곤 하는데요~
요즘에 너무 업무 관련 도서만 읽은 것 같아서 (...) 오랜만에 과학 도서를 읽어보았습니다 ㅎㅎ

과학 도서 중에서 특히 물리 분야 책을 주기적으로 읽어보는데 요즘에는 유튜브로도 관련 지식을 재미있게 접할 수 있어서 좋은 것 같아요 ദ്ദി˙∇˙)ว 양자 역학 관련 과학 유튜브 영상은 거의 다 챙겨 보는데 볼 때마다 어지럽고 새로워서 재밌네요! ㅋㅋ

뭔가 되고는 있고 수학적으로는 들어맞는데 실질적으로 양자역학에 대해서는 이해한 사람이 존재하지 않는다는 게 너무 신기하지 않나요? 번역 이슈인지 주목을 끌기 위한 마케팅인지 모를 말장난이 있어서 더 헷갈리는 것 같긴 한데... 그래도 보다 보면 다른 세계의 마법 도서 읽는 것 같아서 매력적인 것 같아요~! (*충분히 발달한 과학 기술은 마법과 구별할 수 없다는 말도 있는 것처럼요!)

과학 3법칙 - 아서 C. 클라크 (SF 소설가이자 미래학자)

1. 어떤 뛰어난, 그러나 나이 든 과학자가 무언가가 "가능하다"라고 말했을 때, 그것은 거의 확실한 사실에 가깝다. 그러나 그가 무언가가 "불가능하다"라고 말했을 경우, 그의 말은 높은 확률로 틀렸다.

2. 어떤 일의 가능성의 한계를 알아낼 수 있는 유일한 방법은, 바로 불가능의 영역에 아주 살짝 도전해 보는 것뿐이다.

3. 충분히 발달한 과학 기술은 마법과 구별할 수 없다.

아무튼 이번에 선택한 책은 카를로 로벨리, 『 만약 시간이 존재하지 않는다면 』인데요. 작년 이맘때쯤 카를로 로벨리, 『 시간은 흐르지 않는다 』 를 인상 깊게 읽은 기억이 있어 같은 저자의 다음 책을 바로 읽어보았습니다 φ(^∇^ ) - 아 물론 읽어본 거지 이해한 건 아닙니다...

1회독 완료한 카를로 로벨리의 저서

▶ 책 소개

저자 카를로 로벨리 (66)는 '제2의 스티븐 호킹'이라 평가받는 이탈리아 태생의 세계적인 이론 물리학자로, 현재 주로 양자 중력 분야에서 연구 중인 루프 양자 중력 이론의 창시자인데요~

『 만약 시간이 존재하지 않는다면 』 는 루프 양자 중력 이론을 창시하게 된 과정을 담은 자서전 성격의 책입니다. 시공간에 관한 본질적인 질문과 '시간 없이' 우주를 이해할 수 있는 새로운 시각에 대한 물리학의 대답을 찾아가는 저자의 여정이 담겨져 있습니다.

자서전 성격의 책인 만큼 이론을 깊게 다룬다기보다는 저자가 생각하는 '과학적 사고'에 대한 가치관과 이러한 가치관으로 도달한 루프 양자 중력 이론과 그 창시 배경에 대해 소개하고 있습니다 φ（．．）

만약 시간이 존재하지 않는다면 - 카를로 로벨리

과학적 사고 관련해서는 '에필로그'에 저자의 가치관이 서술되어 있는데요.

- 세상을 이해하기 위한 가장 효율적인 방법을 찾아가는 과학
- 반면 학교에서는 과학을'기정사실'과 '법칙', 문제 풀이를 위한 연습처럼 가르치는 경우가 대부분이다.
- 나는 교과서가 아닌 비판적 사고방식을 가르쳐야 한다고 생각한다. 학생들에게, 또한 교사들에게, 맹목적으로 통념을 따르기보다는 의심을 품을 수 있도록 가르쳐야 한다.
- 과학은 과학 그 자체로서 가르쳐야 한다. 과학은 매력 가득한 인류의 모험인 동시에, 대혼란 속에서 새로운 해결책을 끈질기게 탐구할 때 어지러울 정도의 개념적 도약을 거쳐 마침내 퍼즐 조작들이 맞아떨어지는 번득이는 깨달음을 얻게 되는 일련의 과정이다.
- 공전하는 지구, 유전정보를 담고 있는 DNA, 모든 생물의 공통 조상, 휘어 있는 시공간 등, 과학은 그야말로 신비와 아름다움이 가득한 길고 긴 이야기이다. 이런 과학을 교육하기 위해서는 의심하고 감탄하는 법을 가르쳐야 할 것이다.
- 과학은 우리에게 스스로의 무지와 한계를 인정하고, '타인'을 의심하기보다 그로부터 배울 것이 더 많다는 사실을 인정하라고 한다.
- 내가 과학을 통해 배운 것은 단 하나의 현실 세계라는 것은 존재하지 않는다는 사실이다. 이 세상은 항상 우리의 생각과는 다르며, 우리의 눈앞에서 계속 변화하는 존재이다.

다음과 같은 구절을 읽으며, 우리는 어쩌면 과학 법칙을 '세상을 이해하기 위한 방법'이 아닌 '절대적인 법칙', '기정사실'로 받아들이고 있기 때문에 새로운 주장 (양자 역학과 같은) 들을 받아들이기 어려워하고 있지 않을까 하는 생각이 들었습니다.

실제로 양자 역학 관련 유튜브 영상을 볼 때면 '우리가 세상을 잘못 이해하고 있었을 수 있다'라는 느낌보다는 '우리가 인지하고 있던 세상의 법칙이 깨졌다!'라는 느낌을 많이 받았거든요. 그래서 더 마법같이 느껴지기도 하고요!

하지만 "세상을 이해하기 위해서는 시간이라는 개념으로부터 벗어나야 한다!", "세상을 이해하기 위한 가장 효율적인 방법을 찾아가는 것이 과학이다."이라는 문구를 읽으면서 제가 인지하고 있는 과학에 대해 한 번 더 생각해 보게 되었습니다 ㅎㅎ;;;

카를로 로벨리가 말하는 '시공간은 존재하지 않는다'도 결국은 '절대적인 시공간은 존재하지 않는다'라는 말이었는데요. 감수자의 말을 인용하자면 아래와 같이 요약할 수 있습니다. 결론적으로 우주에는 절대적인 시계, 공간 지표가 존재하는 것이 아닌 상대적인 위치에서 공간이라는 개념이 생기고, 상대적인 사건의 관계 속에서 시간이라는 개념을 인지하게 된다라고 이해할 수 있을 것 같아요!

카를로 로벨리의 루프양자중력이론에 따르면, 우주에는 그동안 우리가 알고 있던 공간이나 시간이 더 이상 존재하지 않는다. 공간은 알갱이화된 중력장들의 연결망이고, 시간은 사건과 사건 간의 관계일 뿐이다. 우리는 이를 직관적으로 쉽게 받아들이지 못할 것이다.
이런 우리를 향해 카를로 로벨리는 외치고 있다. 이 세상을 비공간적이고 비시간적인 표현을 통해 이해하는 방법을 생각해 보라고. 견고하게 여겨왔던 기존의 관념들을 뒤엎고 세계를 다른 방식으로 바라보라고. 다른 시각으로 사물을 보고 이를 통해 세상이 겉모습과 다를 수 있음을 깨달아보라고. 바로 이 책이 우리에게 전하는 메시지다.

- 알갱이화된 중력장 이라는 단어는 잘 이해가 안되네요 (...)

[시간을 인지한다 != 시간이 존재한다] [공간을 인지한다 != 공간이 존재한다]
얼핏 봐서는 말장난처럼 느껴지지만 '인지하다'와 '존재하다'의 차이를 구분하는 게 핵심일 것 같네요.

어떻게 보면 우주에 절대적인 시계와 절대적인 줄자가 없는 건 당연한 말 같지만, 절대적인 시계 (n초, n시간...)와 절대적인 줄자 (__cm, __km...)가 있는 세상에서 살고 있는 존재로서는 직관적으로 이해하기 어려운 것 같습니다.

시간과 관련해서는 다음 구절이 가장 인상 깊었습니다 ( ˙ỏ˙ )？

- 시간을 실재성이 결여된 개념으로 전제하자는 것이 아니다.... 각각의 원자에는 색도, 맛도, 온도도 존재하지 않는다. 따라서 기초적 차원에서 세계를 이해하기 위해서는 이런 개념들로부터 벗어나야 한다.
- 특정한 단계나 특정 상황에서 존재하는 개념과, 기초적 차원으로 자연을 서술하는 데 필요한 개념은 엄연히 다르다.

- 말하자면 시간에 대해 생각할 때 우주의 일생에 맞춘 우주 시계가 존재하는 것처럼 여겨서는 안 된다는 것이다. 우주 속의 모든 물체는 각각의 고유한 시간을 가지고 있으므로, 시간에는 지역적인 조건이 있다고 봐야 한다.
-... 우리는 여전히 자연적 현상을 '세고' 있을 뿐, 시간 그 자체를 측정하고 있는 것은 아니다. (=세슘 원자의 진동 주기 등을 기반으로 시간을 표현하고 있을 뿐)

- 시간을 *창발 현상으로 간주하는 우리의 아이디어는 양자역학과 열역학에서 출발한 것이었다. (*창발 현상 : 하위 계층에는 없는 특성이나 행동이 상위 계층에서 자발적으로 돌연히 출현하는 현상)
- 열역학계에서의 반응은 확률적이며 엔트로피는 '시간에 따라' 상승한다.
- 결국 '시간'은 그저 '엔트로피화의 방향'에 지나지 않는다. 엔트로피의 증가가 관찰되는 방향을 시간이라고 부를 뿐이다. / 물체가 낙하하기 때문에 아래라는 개념이 생겨나듯, 엔트로피가 증가하기 때문에 시간이라는 개념이 생겨난 것이다.
- 아래는 '물체가 낙하하는 방향'이고, 시간은 '열이 식는 방향'인 셈이다.

- 그런데 시간이 존재하지 않는데도 시공간에 대한 이야기를 할 수 있을까?... 예를 들어 '5초 후'에 낙하하는 물체의 위치를 예측하는 대신, '진자가 다섯 번 진동한 후'의 물체의 위치를 예측하기로 하면 된다.
-... 스핀 네트워크를 정통적인 공간 개념과는 차이가 있을지라도 계속 '공간'이라는 단어로 지칭할 수 있듯이, 스핀 네트워크가 변화하는 방식, 즉 스핀 네트워크의 변화 '경로' 역시도 '시공간'이라는 단어로 지칭할 수 있을 것이다.

▶ 후기 (NEXT?)

여기까지 『 만약 시간이 존재하지 않는다면 』 를 읽어 보았는데요. 이해될 것 같으면서도...? 이해한 게 맞나 하는 상태가 되어 버렸네요...ㅎㅎㅎ 그래도 시공간에 대한 다른 접근법을 알게 되어 유익한 시간이었습니다 (੭˙ ˘ ˙)੭

다음에는 시간 여유되면 양자 컴퓨터 관련해서도 책을 읽어보고 싶어요! 관련 책 사면서 SF 소설책도 한 권 골랐는데 읽게 되면 블로깅해 보도록 하겠습니다 :)

SF 소설 - 쿼런틴, 양자 컴퓨터 - 퀀텀의 세계

▶ 번외 (양자 컴퓨터?)

번외로 오랜만에 양자 역학 책을 읽으면서 고등학교 때 읽은 관련 책들을 찾았는데 추억이네요 ㅎㅎ

2013년 (고1) 에 양자 컴퓨터가 존재할 수 있다는 것에 신기해했었는데... 10년 지난 2023년은 현재 점점 더 많은 양자 컴퓨터 관련 기사들이 나오고 있고, 요새 뜨거운 감자인 Chat GPT 도 등장해서 새삼 경이로운 기분이 듭니다. ((( 진짜 몇십 년 뒤에는 마법 세계가 되어 있는 게 아닐까요 Chat GPT 도 너무 신기해요 )))

근데 개발자 입장에서는 양자 컴퓨터 나오면 컴파일러는 어떻게 되는 걸까 궁금하기도 하고...?? (새로운 언어가 등장하게 되려나요? 모든 경우에 양자 컴퓨터가 높은 효율을 보이는 것 같진 않더라구요) 그래도 아직까지는 거의 국가 단위로 연구 중인 주제니까 실제 개발 현장에 보편적으로 적용되기에는 먼 미래일 것 같기도 하네요!

[TIL #32] 2022 My Report - 업무편

HannaDev — Mon, 13 Feb 2023 03:15:12 +0900

▶ 목차

[1] 2022 -> 2023
[2] 2022 주요 업무 키워드 - 사용자 기반 서비스 / 서버 이슈
[3] 업무 방식 - 업무 노트 및 일정 관리
[4] 의사소통 - QA 티켓 분포도
[5] 독서 - 클린코드 (리팩토링)
[6] 2022 세부 타임라인 + 총평

▶ 2022 -> 2023

다사다난했던 2022년... 12개월 간의 업무 타임라인을 정리해보며 2022 업무 분석해보는 시간을 갖고자 합니다 :)

[2022 리뷰]

드디어 12개월을 채우고 백엔드 개발자 2년차가 되었습니다 ＼＼\(۶•̀ᴗ•́)۶//／／

이제는 업무에 들어가는 것이 두렵지 않게 되었어요!

업무도 많고 이슈도 많았던 한 해였지만 그래도 재미있게 개발자 1년을 보낸 것 같습니다 ㅎㅎ

입사할 당시에만 해도 1년이 지나면 반복 업무처럼 쉽게 처리할 수 있는 업무들이 많아지지 않을까 상상했는데... 점점 난이도 높아지는 업무에 경이로움을 느낀 한 해였습니다. 그래도 하나씩 어떻게든 해가는 재미가 있었던 것 같아요.

▶ 2022 주요 업무 키워드

# 사용자 기반 서비스

진행한 주요 프로젝트는 총 3개 (시리즈, 웹소설, 챌린지)

: 한 줄 감상평 1. '서비스 요구사항... 알고리즘 문제'
: 한 줄 감상평 2. '열정도 과하면 독이 된다' (일감이 2배...!)

: 깨달음 1. 기획자와 친해지자
: 깨달음 2. 중복코드 지옥 - 클린코드와 친해지자

# 서버 이슈

가장 빈도수가 높았던 서버 이슈는 RDB CPU 80-90% -> Server Down

: 22년 10월 DB Scale-Up 을 통해 현재는 어느정도 안정화 되었습니다.

대응 매뉴얼

1. 배포 이후 발생했다면 롤백부터 합니다. 원인 파악도 중요하지만 즉각 대응이 우선됩니다.
2. 빠르게 원인을 파악할 수 없다면 kill 명령어를 통해 일단 임시 조치를 취합니다. 활용 가능한 명령어는 아래와 같습니다.
~~ㄴ 최후의 방법으로는 RDB 재부팅이 있지만 권장되지 않습니다...~~
3. 다음을 확인하여 원인을 조사합니다.
- CloudWatch Dashboard : 평상 시와 다른 그래프 양상을 확인합니다. (이를 위해 평상 시 지속적인 모니터링이 필요합니다.)
- ELK 를 통한 에러 분석 : 어디서 어떤 에러가 발생하고 있는지 파악합니다. (구분 없이 503 TIMEOUT 에러 발생 등...)
- AWS RDS 의 '성능 개선 도우미' 를 활용하여 모니터링 지표 및 느린 쿼리들을 확인합니다. (쿼리가 아닌 RDB 자체에 의심이 간다면 인스턴스 내 모니터링 부분의 지표들을 확인합니다.)
- Elastic Beanstalk 의 '상태', '모니터링' 페이지를 활용하여 전반적인 지표를 확인합니다.
- 최근에 나간 배포 이력과 실행 중인 배치들을 확인하여 추론합니다. 관련된 부분이 없다면 인프라 문제일 수 있습니다.
- RabbitMQ 등 추가적으로 구성한 부분이 있다면 해당 부분도 모니터링합니다.
4. 2~3 을 반복합니다. 필요하다면 역할을 분담하여 A 그룹이 kill 하는 동안 B 그룹이 원인을 조사하는 방식을 취할 수 있습니다.
5. 추후 장애 리뷰를 위해 중간중간 스크린샷과 함께 진행 상황을 기록해두면 도움이 됩니다. 확실치 않더라도 의심되는 부분이 있으면 slack 또는 구두를 통해 공유합니다.
6. 서버가 정상적으로 돌아왔더라도 원인을 파악하지 못했다면 또다시 이슈가 발생할 수 있으니 추적합니다. (이를 위해 평상시에 꾸준한 모니터링이 필요합니다. 평소와 그래프가 달라지는 부분이 발생한다면 이슈를 추적하세요.)

# 실행중인 쿼리 출력
select *
from information_schema.PROCESSLIST
order by time desc;

# 300 초 이상 대기중인 프로세스들을 출력하는 쿼리
select * from information_schema.processlist
where (COMMAND = 'sleep' or COMMAND='query') and time > 300 ORDER BY TIME desc;

# 300 초 이상 대기중인 프로세스들을 kill 하는 쿼리를 출력하는 쿼리
select concat('KILL ',id,';') from information_schema.processlist
where (COMMAND = 'sleep' or COMMAND='query') and time > 300 ORDER BY TIME desc;

▶ 업무 방식 - 업무 노트 및 일정 관리

# 업무 노트

총 13권 사용 + 스케치북 0.5권
: 가장 많이 활용한 테마 '로직 설계', '요구사항 분석'

: 한 줄 감상평 1. '요구사항 분석을 잘해야 추후 대공사를 예방할 수 있다 (...)'
: 한 줄 감상평 2. '복잡한 요구사항은 반드시 실제 구현 전에 Flow Chart 를 그려보자'

로직 설계 초안 (실제 구현 모습과는 상이)

# 일정 관리

Planning Poker 방식 활용

: Paper -> Google Spread Sheet 로 일정 산정 도구 업그레이드
: (new) 일정 산정 비용 <-> 실제 개발 비용 간의 차이 기록

: 한줄 감상평 1. '처음 생각한 일정의 1.5 ~ 2배를 곱하자'
: 한줄 감상평 2. '실제 소요 시간을 기록해야 다음에 일정 산정을 할 수 있다'

▶ 의사소통 - QA 티켓 분포도

# 기획 관련 QA 티켓 비율 75% 감소 -> QA 기간 감축

기획 관련 QA 티켓 비율 -> 69% -> 57% -> 18% (빠른 처리가 불가능한 부분)
단순 구현 miss -> 31% -> 43% -> 81% (빠르게 처리 가능한 부분)

: 한 줄 감상평 1. '요구사항 분석을 잘해야 추후 대공사를 예방할 수 있다 222 (...)'
: 한 줄 감상평 2. '단계 별로 기획자님과 조율에 들어가자'
ㄴ [기획 회의 단계] 구현 가능 여부 빠르게 판단 -> 스팩 조율 (가장 중요 ★★★)
ㄴ [기획서 검토 단계] 사용자 시뮬레이션에 따른 사용자 관점에서의 피드백
ㄴ [설계 단계] 개발 비용 및 서버 성능 면에서의 스팩 조율
ㄴ [구현 단계] 세부 운영 규칙과 같은 운영 관점에서의 규칙 조율
ㄴ [개발자 테스트 단계] 앱 테스트를 통한 사용자 관점에서의 피드백
: 한 줄 감상평 3. '기획 의도만 부합하면 어느정도 조율의 여지는 있다. 의도를 파악하자.'

# 웹소설 QA 티켓 분포도 (22년 6월, 9월 기준)

기획 관련 QA 티켓 비율 -> 69% -> 57%

단순 구현 miss -> 31% -> 43%

# 챌린지 QA 티켓 분포도 (23년 1월 기준)

기획 관련 QA 티켓 비율 -> 18%

단순 구현 miss -> 81%

: 확실히 기획 관련 QA 티켓이 줄어들고 단순 구현 miss 의 비중이 높아지며 빠르게 처리 가능한 QA 티켓의 비율이 높아졌다.

▶ 독서 - 클린 코드 (리팩토링)

# 챌린지 코드 리팩토링

매달 새로운 챌린지가 추가된다는 요구사항에 대응하기 위한 리팩토링 작업 진행
: [1] 클래스 분리 작업 (ChallengeEvent, Challenge 2개의 클래스로 분리)
: [2] 테스트 코드 작성 (리팩토링을 위한 ChallengeEvent 단위 테스트 및 Challenge API 테스트 코드 작성)
: [3] 상속 및 컴포지션 방식을 통한 중복 코드 개선 (95% -> 10%)
: [+] 추가 리팩토링 아이디어 채굴을 위한 디자인 패턴 학습 중...

챌린지 일정산정 中

# 클린코드, 파이썬 클린 코드 (독서 2권)

: 12월 말 ~ 2월 중순까지 약 6주간 클린코드, 파이썬 클린 코드 2권 완독 & 노트 정리 (추가 복습 필요)

: 한줄 감상평 1. '중복 코드를 줄이자. 방법을 모르겠다면 책을 통해 아이디어를 얻자.'
: 한줄 감상평 2. '입사 초에는 이해가 안갔지만... 챌린지 프로젝트 이후 몰입도 ↑'
: 한줄 감상평 3. '2권이나 읽었지만 한 번씩 더 읽어야 이해할 수 있을 것 같다'

: 깨달음 1. '신문 기사처럼 코드를 작성하자. 세부 내용이 궁금하면 클릭해서 들어가도록 유도하는 느낌으로...'
: 깨달음 2. '코드 중복이 아닌, 코드 구조에 대한 중복도 줄일 수 있는 방법이 존재한다'

▶ 2022 세부 타임라인 + 총평

여기까지 <2022 My Report - 업무편> 을 작성해보았습니다.

이렇게 바쁘기도 바빴고 많은 걸 경험하고 공부한 한 해가 지나갔네요!

2022년에는 특히 사용자 친화적인 서비스 개발을 주로 담당했는데 그 만큼 요구사항도 복잡하고 서버 DB CPU 상태도 아슬아슬해서 알고리즘 문제를 분해하듯이 업무에 임했던 것 같아요...ㅎㅎㅎ (특히 챌린지 프로젝트 난이도가...)

그래도 이렇게 정리하고 보니 뿌듯하네요. 2023년도 다시 힘내봐야겠어요!

벌써 2월이지만 올해는 좀 더 깊이 있게 공부하고 저만의 업무 매뉴얼을 만들어보는 한 해가 되었으면 합니다:)

[TIL #31] 2022 My Report - 일상편

HannaDev — Mon, 2 Jan 2023 04:31:17 +0900

▶ 목차

[1] 2022 -> 2023
[2] 문화생활 - 공연 / 전시
[3] 자기계발 - 도서 / 업무 노트 / 블로깅

[4] 공간 - 작업 공간
[5] 2022 -> 2023 총평

▶ 2022 -> 2023

드디어 새 해가 밝았네요. 2022년에는 백엔드 개발자로 취업도 하고 호기심도 채우면서 다양한 경험을 해 본 해인 것 같아요~
2022년 1월 1일에 일출 보러 간 게 아직도 생생한데 벌써 2023년이라니 올해도 다양한 경험을 해볼 수 있을 것 같아 기대가 됩니다! 물론 언제나 그렇듯 설렘과 불안이 같이 공존하지만... 그래도 항상 그래왔듯 어떻게든 되지 않을까요~~ ദ്ദി´ ▽ ` )
아무튼 2023년을 맞아 무엇을 해보면 좋을까 하다가 요새 개인화된 분석 보고서를 제공해주는게 트랜드인 것 같더라구요! 유튜브 뮤직, 네이버 웹툰에서 2022년 제가 해당 서비스를 얼마나 어떻게 즐겨 사용했는지 분석해줬는데 너무 신기했어요. 자신이 생각하는 자신의 모습이랑 데이터 상에서의 모습은 생각보다 차이가 있더라구요?
그래서 저도 자체적으로 분석 보고서를 만들어보려합니다. 범주는 크게 일상편 / 업무편 으로 나눌 예정인데 가볍게 일상편부터 시작입니다! ＼＼\(۶•̀ᴗ•́)۶//／／
[자세히보기] Youtube Music - 2022 Recap

나의 음악 성격 유형은 '비트의 지배자' - 트랜드를 주도하며 파티를 신나게 만드는 분위기 메이커에요.
- 권은비님의 음악을 가장 많이 들은 사용자 0.1% 에 들었어요.
- IVE (아이브) 의 LOVE DIVE - 이 곡을 90번 들었어요.
- 스트림 수가 2671만일 때부터 NewJeans 의 음악을 들어온 초창기 팬이시네요. (누적 스트림 횟수는 4억회이고 계속 늘어나고 있어요.) - 대체 이 정보는 DB 에 어떻게 쌓았을까요;;; 통계를 낸 것도 신기;;;
- 최신곡을 즐겨 듣는 편이에요. - 내가 들은 음악의 58%가 인기곡이었어요.
- 좋아하는 곡을 꾸준히 들어요 . - 반복해서 들은 곡이 61%에요.
- 올해 에너지 넘치는 곡을 즐겨 들었어요. - 즐겨 들은 음악의 56%가 신나는 곡이었어요.
평소 내가 생각하는 음악 취향 - 비트가 중독적인 신나는 노래
- TripleS 음악을 가장 많이 반복해서 들었다고 생각했는데 IVE 의 LOVE DIVE 의 재생 이력이 더 많음.
  - 직접 Click Action 을 통해서는 들은 음악은 TripleS 음악이지만, IVE 의 LOVE DIVE 가 알고리즘을 타며 랜덤 재생 시 많이 나온 점이 반영된 것으로 보임. (LOVE DIVE 가 대중적으로 인기가 많아서)
- 권은비님의 음악을 가장 많이 들은 사용자 0.1%
  - 모든 앨범, 수록곡이 취향 저격. 하지만 0.1% 일 줄은...;;; 아직 대중픽까지는 아닌 점이 반영된 것으로 보임. 아니면 K-pop 코어 팬들은 Youtube Music 앱이 아닌 앱으로 듣는 걸 수도 있음.
- 스트림 수가 2671만일 때부터...
  - NewJeans 는 워낙 곡 나오기 전부터 여돌 판에서 뜨거운 감자였어서... 유튜브 알고리즘에 계속 노출돼서 결국 듣게 됨.
  - 근데 이 통계는 어떻게 계산할 걸까. 듣는 음악마다 그 때의 스트림 수도 저장할까. 유튜브에서 노래 재생한 것과 유튜브 뮤직에서 노래 재생한 거는 데이터 이력을 다르게 쌓겠지?

Youtube Music - 2022 Recap

▶ 문화 생활 - 공연 / 전시

: 2022년의 주요 키워드는 '문화 생활'

총 공연 26회, 전시 3회

: 가장 많이 보러 간 테마는 '클래식 연주'
: 즐겨 본 테마는 '뮤지컬', '발레'
: 호기심 충족 '콘서트', '서커스'

티켓북 (뮤지컬/연극, 클래식/발레/오페라, 콘서트/여행)

뮤지컬 6회
- AIDA (아이다), 데스노트, 엘리자벳, 마타하리, 미세스 다웃파이어, 스위니 토드
연극 1회
- 햄릿
클래식 (오케스트라, 악기) 8회
- 예술의 전당 여름음악축제 클로징, 신세계 콘서트 * 4
- 경기필하모닉 마스터피스 시리즈 Ⅲ 〈무소륵스키 전람회의 그림〉
- 손민수 피아노 리사이틀 <초절기교>, 해리 포터와 아즈카반의 죄수 인 콘서트
발레 5회
- 유니버설발레단 <잠자는 숲속의 미녀>, <오네긴>
- 파리 오페라 발레 <2022 에투알 갈라>
- 국립 발레단 <지젤> & <트리플 빌>
- 발레 신데렐라
오페라 1회
- 로미오와 줄리엣
콘서트 4회
- 2022 (G) I-DLE World Tour, 2022 알렌 워커 내한 공연
- 또모 재즈 콘서트, 더데빌 콘서트
서커스 1회
- 태양의서커스 <뉴알레그리아>
전시 3회
- 도밍개인전 <환상유랑극단>, 우연히 웨스 앤더슨, 요시고 사진전

01234

2022 티켓북 (뮤지컬/연극, 클래식/발레/오페라, 콘서트/여행)

2022 마지막으로 관람한 뮤지컬 - 스위니 토드

올해의 공연 TOP 3

TOP 1. 태양의서커스 <뉴알레그리아> : 놀이공원 느낌. 공중그네가 인상적.
TOP 2. 유니버설발레단 <잠자는 숲속의 미녀> : 무대의 화려함. 자본이 느껴지는 공연.
TOP 3. 국립 발레단 <지젤> & <트리플 빌> : 발랄한 여주. 반전의 할로윈. 다시보고 싶은 공연.

ㄴ 유니버설발레단 - 잠자는 숲속의 미녀

태양의서커스 <뉴알레그리아> 내부 공연장 모습

총평
: 재밌었지만 통장이 위험하다.
: 2023년에는 1~2달에 1번만.

▶ 자기계발 - 도서 / 업무 노트 / 블로깅

: 2022년의 Big Event '취업'

도서
: 총 40권 구입
: 완독 10권, 북스터디 2권 (세미나 5회 진행)
: 가장 즐겨 본 테마 '자기계발서'
: 가장 오래 본 테마 '업무 관련 도서'
: 가장 집중력이 높았던 테마 '업무 관련 도서'
: 흥미를 갖는 or 필요한 책을 그 때 그 때 읽는 스타일 - 좀 더 진득이 읽는 연습이 필요하다
: 현재 읽고 있는 책 <Clean Code> <Real MySQL 8.0>

- 자기계발

[완독] 포커스 (Focus)
[완독] 나의 MBTI 가 궁금하단 마리몽
[5%] 헤르만 헤세의 문장들
[10%] 사고법 도감
[완독] 직장인 공부법
[완독] 위대한 나의 발견 강점혁명
[20%] 프로젝트가 서쪽으로 간 까닭은
[완독] 존 도어 | 구글이 목표를 달성하는 방식 OKR
[완독] 왜 일하는가
[30%] 일의 격: 성장하는 나 성공하는 조직 성숙한 삶

- 프로그래밍 교양

[완독] 프로그래머의 뇌
[완독] 실용주의 사고와 학습
[완독] UML 기초와 응용
[10%] 파이썬 핵심 개발자들과의 인터뷰
[20%] Flask 기반의 파이썬 웹 프로그래밍
[20%] 파이썬 클린 코드
[50%~] Clean Code (클린 코드)
[30%] KODE VICIOUS 개발 지옥

- 업무 관련 도서

[50%] ElasticSearch in Action
[80%] RabbitMQ in Depth
[40%] RabbitMQ 따라잡기
[20%] 대용량 데이터베이스솔루션 1 - 북스터디
[30%~] Real MySQL 8.0 (1권)
[완독] 배워서 바로 쓰는 14가지 AWS 구축 패턴 - 북스터디
[10%] 컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커

도서 총평
: 책은 너무 충동구매한 게 아닐까...? 복지포인트지만 좀 더 고민해서 선정해보자.
: 2023년에는 흥미 위주보다는 좀 더 계획성 있게 책을 읽어보자.

업무 노트
: 총 11권 사용 + 스케치북 0.5권
: 가장 많이 활용한 테마 '로직 설계', '요구사항 분석'

업무 중에 사용한 필기 노트

블로깅 - Tistory
: 총 게시글 50개 (TIL 30개, PEP 8개, Error 4개, 기타 8개)
: 가장 많이 작성된 테마 'TIL (Today I Learn)'
: 공백 기간 (22.06.11 ~ 22.12.28, 약 6개월) - 업무에 집중한 기간

총평
: 업무 노트에 작성된 내용이 블로깅에 좀 더 활용되면 좋을 것 같다.
: 업무가 바쁘더라도 적어도 2주에 한 번은 블로깅에 도전해보자.

▶공간 - 작업 공간

: 2022년 Working Space - Update 목록

2개의 모니터 + 모니터암 설치
청축 키보드 구비 (G913 Clicky)
유리 칠판을 통한 파티셔닝
책장 +1 추가
식물 키우기 (2년+) - 아보카도는 죽었다...

총평
: 유리 칠판 활용하자 (...)
: 모니터암 만족도 100%

▶ 2022 -> 2023 총평

여기까지 <2022 My Report - 일상편> 을 작성해보았는데, 생각보다 많은 것들을 해 본 2022년이었네요!
수치로 보니 독서도 많이 하고 업무 노트도 많이 작성한 게 느껴져서 뿌듯한 것 같습니다 ㅎㅎ
하지만 재정적으로는 (...) 노력이 더 필요할 것 같네요.
2023년에는 문화생활은 조금 줄이고 업무 역량에 좀 더 도전해봐야겠습니다.

+ 개인적으로는 SQLP 자격증을 따보고 싶은데 실무 경력 2년이 필요하더라구요? 아직 1년차도 안되긴 했지만...ㅎㅎ 2023년에는 SQLD 에 도전해보고, 2024년에 SQLP 에 도전해보고자 해요! 뭔가 업무를 하면서 DB 엔진 쪽에 관심이 많이 생기더라구요~

2023년도 화이팅~~

[Error #2+] 장애 리뷰 준비 & 올해의 장애 TOP 2

HannaDev — Sat, 31 Dec 2022 01:13:16 +0900

장애가 발생했다면 추후 재발 방지를 위해
장애 리뷰를 진행합시다

다만 연말인 만큼 모두 휴가를 갔기 때문에 (...) 시간 공백이 생긴 만큼 문서 작성에 좀 더 공을 들여 보았습니다.
이때를 위해 장애 났을 때부터 틈틈이 캡처해 둔 증거 사진 (?) 과 함께 전반적인 타임라인과 개선점을 정리했더니 3시간이 훌쩍 지나가네요...ㅎㅎ

(+ 2월부터 서버 장애를 하도 겪다보니 캡처하는 습관이 생겼는데... 사실 장애가 난 당시에는 급박하다 보니 흘리고 지나가는 것들이 많더라고요. 사건 현장을 사진으로 남겨두면 나중에 복기할 때 좋은 것 같아요!)

▶ 장애 리뷰 문서 형식

장애 리뷰 문서는 기본적으로 ① 발생한 장애를 분석하고 ② 개선할 점을 회고하는 방식으로 구성하고 있는데요!
이렇게 문서를 작성하게 되면 댓글이나 장애 리뷰 시간을 통해 재발 방지 대책을 세우게 됩니다.

장애 분석
- 장애 경과 (= 타임 라인)
- 장애 여파 (= 피해 범위)
- 장애 원인 / 대응
개선할 점
- 장애 파악/인지 개선
- 장애 대응 게산
- 예방 방안
- 추가로 논의할 내용

올해에는 16개의 장애 리뷰 문서가 작성되었네요! 정말 다산 다난한 해였습니다 (...)
이 중 2개가 제가 진행한 프로젝트에서 발생한 장애 사건이네요 ㅠ.ㅠ
하필 연말에 큰 사고 (...) 가 발생하다니 역시 마음이 느슨해지면 바로 장애로 이어지나 봐요...ㅎㅎ
(앱 스토어 댓글 확인하는데 심장이 너무 아프네요)

2022년 장애 리뷰 목록

▶ 올해의 장애 TOP2 (RDS)

장애 리뷰조차 진행되지 못했던 올해의 큰 사건 사고들도 많았는데요. 올해는 DB 이슈가 참 많았습니다 ㅠ.ㅠ
신입으로는 할 수 있는 일이 많지 않았지만... DB 엔진에 대한 공부의 필요성을 많이 느낀 한 해였습니다!!
(지금도 열심히 책 보고 있는데 너어어어어어무 어렵네요)

[1] DB Scale Up 을 결정하기 전, 불안정한 RDS CPU & 주기적 서비스 장애
- 기본 RDS CPU 80~90% 유지
- 매일 트래픽이 몰리는 시간대에는 RDS CPU 100% -> 서비스 장애 발생
- 장애 원인
  - 레거시 코드 (DB 를 괴롭히는 수많은 로직들)
- 대응 방법
  - mysql kill thread_id; 명령어를 통한 임시조치
  - AWS RDS 성능 개선 도우미를 통한 DB 에 가장 많은 부하를 일으키는 상위 쿼리 파악 (레거시) -> 리팩토링
[2] DB Scale Up 을 진행한 후, 높아진 Read Latency + Disk I/O 이슈 & 서비스 장애
- mysql kill thread_id; 명령어를 통한 임시조치
- AWS 모니터링 지표를 통한 원인 분석 -> 디스크 I/O 사용률 100% 돌파
- DB 에 요청되는 데이터 저장량은 초당 1.3G 에 근접 <-> GP2 볼륨의 최대 처리량은 초당 1G
  - 디스크 I/O 병목 현상 발생 (쓰기 횟수보다 쓰기 량이 너무 많아 한계에 도달)
  - 20Mb/s 는 쓰기 요청. 1G는 테이블 쓰기와 인덱스 갱신 등 전체 물리 디스크 I/O 수치.
- 장애 원인
  - [추측 1] DB Scale Up 전에는 CPU 가 병목 지점 -> 이러한 병목이 디스크 I/O 사용률이 100% 에 도달하지 못하도록 하는 안전장치가 됨 -> DB Scale Up 을 함 -> CPU 가 처리하는 요청량이 증가하며 디스크 I/O 사용률도 증가 -> 디스크 I/O 사용률이 100% 를 돌파하며 병목 발생
  - [추측 2] 모종의 이유로 이전보다 성능이 낮은 디스크가 할당되었다.
- 대응 방법
  - 디스크 크기를 늘린다.
  - 인덱스가 과도하게 많은 DB Table 을 정리한다. (불필요한 Index 삭제)
- 높아진 Read Latency 는 3일 경과 후 점차 안정화 (DB Scale Up 의 여파가 며칠 간 존재하는 듯하다.)

뭔가... 장애로 고통스러웠던 기억은 남아있지만... 이해를 위해선 추가 공부가 필요하다.

다시 생각해도 DB Scale Up 직후는 정말 아찔하네요. 원인을 발견해서 다행이지 그 상황에서 DB Scale Up 작업 자체를 롤백할 수도 없고;;;; 그날은 거의 오후 11시까지 완전 비상이었습니다.

▶ 장애 리뷰 - 문서 작성 (Rabbit MQ)

DB 외적으로 올해의 장애 TOP 1 이 있다면 당연코 연말에 발생한 요번 Rabbit MQ 사건입니다.
Rabbit MQ 를 본격적으로 서비스에 활용한 지 얼마 안 된 시점이라 원인 파악, 장애 대응 모두 미흡한 점이 많았습니다 ㅜ.ㅜ 장애 리뷰 문서를 정리할수록 그 점이 점점 명확해지더라고요.
특히 이런 점들이 많이 아쉬운 부분이었습니다.

모니터링 페이지는 있으나 경보 시스템은 없었던 점
장애 당일, 서버 개발자 모두 연차로 대응이 늦어진 점
QA 팀으로부터 챌린지 시스템에 이상이 있음을 장애 발생 전에 전달받았지만 당일 연차로 확인하지 못한 점
보안그룹 문제로 재택에서 모니터링 페이지 접근이 되지 않아 큐 상태 확인이 늦은 점
Rabbit MQ 장애 상황에 대한 경험자가 없는 점

장애 대응 당시에는 2번이 가장 크게 느껴졌는데...ㅎㅎ
근본적으로는 장애를 미리 인지할 수 있는 시스템이 없었다는 점이 문서로 점점 드러나는 것 같습니다!

목차 및 장애 경과

장애 리뷰 - 목차 및 장애 경과

장애 원인 中

로직 변경 - ... - 장애 확산

Rabbit MQ - Disk Full (정상 작동 시, +- 0 유지)

대응 및 개선점 中

장애 대응 과정에 대한 상세 타임라인 및 개선점

▶ 장애 리뷰 - 논의가 필요한 부분

장애 대응 개선과 관련해서는 다른 동료도 문서에 의견을 작성해 주었는데요. 생각해보지 못했던 부분들이라 와닿는 부분들이 많았습니다. 특히 circuit breaker 개념은 처음 들어봤는데 지금 상황에 정말 필요한 시스템인 것 같아요!

동료가 작성해 준 개선 방향!

장애 대응 방식에 대해서도 의견을 남겨주었는데,
메세지 데이터를 삭제한 1번 방식이 아니라 EC2 의 볼륨을 조작, 백업 등을 통해 메세지 데이터를 보존하는 2번 방식이었으면 어땠을까에 대한 의견이었습니다.

[조치한 방법] Disk Full 발생 -> EC2 인스턴스 터미널 접속 -> 메세지 데이터 삭제
[제시된 의견] Disk Full 발생 -> EC2 인스턴스 볼륨 확장 -> 볼륨 스냅샷 등 백업 -> 필요 시 메세지 데이터 삭제

사실 장애 당시에는 1번 방식밖에 떠오르는 게 없었는데 2번 방식으로 했다면 확실히 메세지가 보존되어 후속 조치 (유저별 챌린지 달성 마이그레이션...) 에 도움이 되었을 것 같아요.
물론 볼륨 확장에는 돈이 청구된다는 점에서 해당 방식은 장애 리뷰 때 좀 더 논의해보면 좋을 것 같습니다!

[Error #2] 연말은 에러와 함께~ (Rabbit MQ)

HannaDev — Wed, 28 Dec 2022 00:30:55 +0900

모니터링이 필요한 곳이 있다면
모니터링 방안을 구상하자

약 6개월 만의 작성해보는 게시글이네요. 벌써 입사 1년이 되어간다니 감회가 새로운데요...ㅎㅎ
소중히 아껴온 2022년 마지막 연차가 에러와 함께 불타오르는 것을 보니 서버 개발자가 된 것이 실감이 났습니다 (*ˊᵕˋ*)ﾉ
사실 1년차가 되면 일정량 업무가 반복 업무처럼 되어갈 줄 알았는데 매일매일이 새롭네요. 이 쯤 되니 경이롭습니다.
~~(하지만 거의 12시간 동안 서버 장애가 해결 안된 건 너무 새로운 이벤트가 아닌지...)~~

▶ 발생한 오류

이번에 마주하게된 에러는 Rabbit MQ 과부하 (DISK FULL) 입니다.
챌린지 2차 프로젝트를 진행하며 동료와 함께 설계를 일부 변경한 부분이 문제가 되었습니다.
콘텐츠 재생 서비스와 Rabbit MQ 가 맞닿아 있어 결국 서버 자체에 영향이 갔고,
이로인해 모든 서비스가 불능 상태가 된 사건입니다. (MQ 문제와 별개로 인프라 구성에도 문제가 있는 것 같은...)

▶ 타임라인

[!] 유저 별로 콘텐츠 재생 시 30초 또는 1분 마다 재생 기록 API 가 호출되며,
유저의 콘텐츠 누적 재생 시간에 따라 주마다 Weekly 챌린지를 달성 처리 한다.

1. [2022-12-xx 챌린지 구현 중] 이 때, 체크포인트 변곡점에서만 이벤트를 발생시키던 A 방식에서 체크포인트 이후에 이벤트가 달성 처리되어 있지 않으면 이벤트를 계속 발생시키는 B 방식으로 변경

Why? - A 방식의 경우 변곡점 이벤트가 누락되면 영원히 달성 처리가 누락되기에 B 방식으로 챌린지 달성을 보장하고자 함
C 방식 (후보) - 체크포인트 변곡점 ± 5분 오차 허용

2. [2022-12-xx 챌린지 구현 중] 하지만 기획상 Weekly 챌린지는 그 다음주부터 시작되는 챌린지 -> 챌린지 오픈 전까지는 계속 미달성 상태
3. [2022-12-23 금요일 오전 11시 경] 이 상태에서 해당 기능 서버 배포
4. [2022-12-26 월요일 오후 6시 경] 이로인해 지속적으로 이벤트 발생 -> Rabbit MQ 큐에 과도한 메세지가 쌓이면서 DISK Full
5. [2022-12-26 월요일 오후 6시 경] 서버에서는 Celery 를 통해 이벤트 메세지를 Rabbit MQ 에 넣는 요청을 넣음 -> 현재 큐에 메세지를 넣을 수 없는 상태 -> (추측) 큐에 메세지를 넣기 위해 대기 상태 -> OSError / 502 Timeout -> 모든 서비스 접근 불가 / 불능 상태
6. [2022-12-26 월요일 오후 6시 경] 백엔드 개발자 4명 모두 당일 연차 -> Sentry 오류로 장애 인지했으나 원인 불명 -> 인프라 의심 (리더 개발자님 대응 중)
7. [2022-12-26 월요일 오후 8시 경] 서비스 여전히 접근 불가 / 집 도착
8. [2022-12-26 월요일 오후 11시 경] Rabbit MQ 에 대한 의심 -> 하지만 재택에서 모니터링 페이지 접근 불가 / EC2 인스턴스 자체에는 이상 無 -> 크게 의심하지 않고 다른 원인 물색 / 배포 자체는 3일 전 금요일에 진행했기에 챌린지에 문제 있을 거라고 생각 못 함
9. [2022-12-26 화요일 오전 6시 경] 임시 조치를 통한 서비스 정상화 + 금요일 배포한 챌린지에 문제가 있는 것 같다는 공지 (=리더 개발자님)

10. [2022-12-26 화요일 오전 7시 경] 공지 확인 -> 깨달음 -> 원인 파악 -> 동료에게 수정 요청 -> 보고
11. [2022-12-26 화요일 오전 9시 경] 출근 -> Rabbit MQ 모니터링 페이지 확인 -> 원인 확실시 -> 보고 -> 대응

약 1800만 개의 메세지가 쌓여 있다 (약 32G - DISK Full)

메세지 생성 속도가 소비 속도보다 월등히 높은 상태 (3일째 터져버린 시한 폭탄)

12. [2022-12-26 화요일 오전 9시 반 경] 모니터링 페이지에서 미러링 중단 버튼 클릭 -> 페이지 down -> MQ EC2 인스턴스 (master, slave) 중단 후 재실행 -> slave 클러스터 노드 죽어 있음 + master 클러스터 노드는 살아 있으나 큐에 durable 속성 적용되어 디스크에 저장된 메세지 복구 중 -> 또다시 Disk Full 상태를 향해 달려가는 중

약 40G 중 4.9 메가 남은 상태 -&gt; 점점 줄어든다 (지옥의 카운트다운)

13. [2022-12-26 화요일 오전 10시 반 경] EC2 인스턴스 터미널 접속 -> 구글링 -> 메세지 데이터 삭제 방법 알아냄 -> master, slave queue 내의 .idx 파일 삭제 (각 28G+)

https://www.rabbitmq.com/backup.html

메시지 데이터는 위에서 언급한 노드의 데이터 디렉토리 에 저장됩니다.

3.7.0부터 시작하는 RabbitMQ 버전에서 모든 메시지 데이터는 msg_stores/vhosts 디렉터리에 결합되고 가상 호스트당 하위 디렉터리에 저장됩니다. 각 가상 호스트 디렉토리는 해시로 이름이 지정되고 가상 호스트 이름이 있는 .vhost 파일을 포함하므로 특정 가상 호스트의 메시지 세트를 별도로 백업할 수 있습니다.

3.7.0 이전의 RabbitMQ 버전에서 메시지는 노드 데이터 디렉터리 아래의 여러 디렉터리( queues , msg_store_persistent 및 msg_store_transient )에 저장 됩니다. 또한 노드가 정상적으로 중지된 경우 복구 메타데이터를 포함 하는 recovery.dets 파일이 있습니다.

14. [2022-12-26 화요일 오후 2시 경] Slave 클러스터 노드 여전히 죽어 있음 (disk 데이터는 모두 정리된 상태) -> 구글링 -> 몇 가지 복구 방법 알아냄 -> 실행

목표 : node 살려내기

rabbitmq 서버 터트리고 살리기 (akka. file discriptor가 문제다.)

파일 디스크립터 갯수 올리려다가 rabbitmq 터진 사건 파일 디스크립터 갯수가 1024개로 되어 있으나, OS의 파일 디스크립터 갯수는 81920개까지 사용 가능하다. $ ulimit -n #명령어로 갯수 확인이 가능

seungdols.tistory.com

방법 1. 효과 없음

So after removing sudo rm -rf /var/log/rabbitmq/* , I started sudo service rabbitmq-server start and rabbitmqctl start_app. It worked, thanks!

방법 2. 효과 있음

그러던 중 rabbitmq-server fails to start on Red Hat Openstack Platform 7 의 문서에서 Resolution 을 따라보기로...
rm -rf /var/lib/rabbitmq/mnesia/*, systemctl start rabbitmq-server...

15. [2022-12-26 화요일 오후 3시 경] 노드 재설정 하였으나 서버와 연결되지 않음 -> 리더 개발자님이 추가 조사 -> 이 과정에서 master cluster 노드도 재설정되어 버려서 slave cluster 만 살려서 연결 / 복구 -> sentry alert 드디어 더이상 안옴
16. [2022-12-26 화요일 오후 4시 경] 큐 정상화 / Celery worker 다시 활성화
17. [2022-12-26 화요일 오후 4시 경] 뒷 수습 중... (날아간 메세지 관련 후속 처리, 마이그레이션 일부 진행) / 프로덕트팀에 상황 공유
18. [2022-12-26 화요일 오후 6시 경] 퇴근

▶ 장애 인지 및 대응 개선

[1] Rabbit MQ 에 대한 모니터링 미흡 → 경보 시스템이 필요하다

Rabbit MQ - celery queue 에 메세지가 과도하게 쌓이면서 disk full 상태에 이르렀지만, EC2 인스턴스 및 Celery Worker 상태는 초록불.
- Rabbit MQ 모니터링 페이지 보면 큐에 이상이 있는게 확실한데 왜 EC2 인스턴스, Celery worker 는 계속 초록불이었는지 의아하다.
큐 상태에 대한 경보 시스템이 필요하다.

2022년 12월 26일 월요일

- 14:25 - QA 팀 → 챌린지 미달성 현상 제보

월요일 오후 5시 50분 경 전으로 QA 팀에서 챌린지 이상 현상을 캐치하였으나 당일 연차로 확인하지 못함

QA 티켓 주셨을 때 Rabbit MQ 페이지 확인했다면 전체 서비스 장애까지는 안 가도록 조치 가능했을지도…

[2] 모니터링 페이지 관련해서는 재택에서도 접근 가능하도록 환경 미리 세팅 필요

[3] 터미널을 통해 EC2 인스턴스에 접근, 로그 확인 / 파일 CRUD 등 기본 명령어 연습 필요

12/27 (화) 장애 대응 시, 다른 동료한테 EC2 터미널 접속 방법 강의 받음

장애 대응 시 고민되었던 지점 = 대응 시 병목 지점이 된 심리 상태
[4] 장애 상황에서는 빠른 결단이 필요하다 (선 조치 후 보고 방식을 고려하자)

버튼을 함부로 누르지 말자 <-> 뭐라도 해보자
- 결국 MQ 모니터링 페이지의 미러링 중지 버튼을 눌렀는데 바로 페이지 다운됨 (EC2 인스턴스 재실행으로 페이지 일단 살림;;;;) - 그리고 이렇게 slave cluster 의 node 가 죽었다. (=not running)
disk 를 살리기 위한 disk 내 메세지 삭제 명령어를 실행시키는 과정에서 1시간 병목
- 삭제해도 되는가? 되지 않을까? (챌린지 프로젝트와 무관한 동료와 상의 30분....) - 터미널 명령어만 확인 부탁.. 문제가 생기면 범인은 나인 걸로 해... - 일단 GO - disk 문제는 해결됨
- 어차피 즉시 판단을 내릴 수 있는 사람이 나밖에 없었다는 점에서 좀 더 빠르게 결단을 내리고 실행했으면 좋았을 것 같다. ~~어떻게 회사에 리더가 아무도 없어...~~ (휴가간 챌린지 프로젝트 동료와 리더 개발자님을 슬랙에서 소환해서 논의할 수도 있었겠지만... 그러면 이렇게 판단하게 된 배경부터 근거, 이유 + 답변 기다리는 시간까지 한 3시간은 걸리지 않았을까 / 아닌가 전화라도 해서 상의해보는게 나았을까? 리더 개발자님도 celery, mq 쪽은 안 다루셔서 주석처리로 새벽에 서비스만 살려두고 휴가 가버리셨는데 ㅎㅎㅠ?)
  - 다음날 리더 개발자님이 장애 상황에서는 선 조치 후 보고 해도 된다고 말씀하셨다.
  - 다음날 휴가간 챌린지 프로젝트 동료가 차라리 EC2 볼륨을 높여보는게 낫지 않았겠냐는 의견을 냈다. (disk 용량을 높이면 추가 비용 청구되지 않나. 이 방식은 리더 개발자님의 허가가 필요했을 듯.) ~~비용이 드는 결정은 판단이 어렵다.~~
slave cluster 의 node 를 살리기 위한 명령어 (특정 로그 파일 삭제, 특정 경로 파일 삭제) 를 실행시키는 과정에서 2시간 병목
- 위와 동일. 삭제해도 되는가? 되지 않을까? (동료와 상의...를 시도했으나 결제 관련 이슈로 떠나버려서 혼자 남음) - 삭제 명령어가 잘못되었을 때의 상황 시뮬레이션 상상 1시간... 근데 어차피 node 죽어있어서 아무것도 못하느니 뭐라도 해보는게... - 삭제할 파일 복제해두고 일단 GO - node 는 정상적으로 재설정 됨
- 어차피... 모두 바쁘다면... 선 조치 후 보고 해도 되었을 것 같다. 그래도 node 재설정 후 서버와 연결 작업은 슬랙에 다시 나타난 리더 개발자님이 조치해주셨다.
  - 어떻게 하신건지 매우 궁금하다. 1월 첫째 주에 장애 리뷰할 때 여쭤보자.

▶ 결론

모니터링 자동화 - 경보 시스템 필요 (~~근데 왜 celery, mq 부분은 제 담당이 되어 있는거죠?)~~
경보 시스템 어떻게 추가할 수 있을까 - 고민 필요
챌린지 관련 고객 문의는 마음이 아프다 - 후속 조치 리스트업 필요

[+] MEMO
가용성을 높이는 조치가 덫이 되다
디스크에 저장된 메세지 어떻게 비우지에 대한 고민도 하나의 병목 지점

[TIL #30] 오랜만에 미술학원 + Elastic Search 공부

HannaDev — Sat, 11 Jun 2022 23:48:08 +0900

▶ 목차

[1] 오늘자 그림

[2] Elastic Search 공부 중!

[3] 공부하게 된 계기...

[+] Elastic 노트 정리

▶ 오늘자 그림

저번에는 기본적인 입체 도형을 그렸다면 이번에는 표면 반사가 가득한 주전자에 도전해보고 있습니다!

오랜만에 미술 학원에 갔는데 주전자 몸통 꼼꼼하게 잘 그렸다고 칭찬받았습니다 ㅎㅎㅎ

칭찬 받고 싶을 때 미술 학원 가는 것도 나쁘지 않은 것 같습니다 ㅋㅋㅋ

사실 손잡이는 선생님이 시범으로 그려주셨습니다...ㅎ

▶ Elastic Search 공부 중!

사실 저는 2주간 Elastic Search 로 고통받고 있는데요. 다행히 금요일에 1차 PR 수정을 어찌어찌 마쳤습니다...ㅎ

2주간 얻게된 교훈은.... 공부를 열심히 하자... 그냥 구글링으로만 해결하려다가 화를 입었습니다 ㅠ.ㅠ

서칭 능력도 중요한 역량이지만 정석적인 공부도 확실히 필요함을 느꼈습니다!

특징 : 물음표 가득함

공부에 사용한 교재는 "Elasticsearch IN ACTION" 인데요! 최근에 나온 책은 아니여서 ES 1.x 버전을 기준으로 설명이 나와있지만 기본적인 내용들과 활용법들이 자세히 적힌 책이었습니다 :D (현재 ES 최신 버전은 8.x - 회사는 7.x 사용 중)

공부는 월요일... 공휴일에 독서실 가서... 했는데요... ㅎㅎㅠ 사람이 업무적으로 압박을 받으니 확실히 집중은 잘 되었습니다 ㅋㅋㅋㅠㅠ 시험기간인지 다들 열심히 공부 중이시더라구요...ㅎ 시험 기간처럼 한번에 9시간 이렇게 공부는 안했지만 3시간씩 3일정도 공부하니 1~4장(~190p) 는 끝낼 수 있었습니다! 4장까지가 기본 내용이어서 입문으로 보시면 좋을 것 같아요 :)

고통받은 흔적들...

<공부하게 된 계기...>

검색 API 수정 (특정 카테고리 검색 신설) -> 상무님, 차장님 기준 1~2 일 추정 -> 내 기준 3일 추정

3일 간 작업
[1일차] 회사 내부 코드 파악 + 수정 범위 파악
[2일차] 질문 + 구글링 -> Index 하나를 2개의 Index 로 분할하는 방식으로 검색 API 수정 시작
[3일차] 기능 구현 완료 -> 피드백 (feat. 상무님)

Filter 와 Query 의 존재 파악 -> 지금 구현된 건 클라 분들 테스트용으로 전달하고 내부 구현 방식 갈아 엎기 시작

3일 간 공부... 기본 내용 숙지... (주말+공휴일) -> 검색 API 수정 시작

[4~7일차]

JSON 형태로 만드는 활용법은 알겠는데 회사 코드는 특정 Library 함수들을 활용하는 상태 -> Library 활용법 탐구 시작 (내부 코드 읽기 ^ㅁ^...)

aggregation 결과가 이상함 -> 밤 10시 반... 상무님과 함께 야근 -> 상무님이 원인 파악해 주심! (bucket default 값이 10 이어서 카테고리 집계 결과가 10개만 나옴 ㅠ.ㅠ)

Library 활용법 탐구 -> 집계 부분 파악! -> aggregation + filter 방식으로 구현 -> 피드백에 따른 추가 수정 진행 (금요일)

▶ Elastic Search 노트 필기 (1~2장)

시간이 된다면 티스토리에도 공부한 내용 올려보겠습니다...♪(´▽｀)

>>> 1장 : 엘라스틱 서치 소개

>>> 2장 : 기능 들여다보기

[TIL #29] 5월 업무 일정 회고 (feat. 웹소설 API)

HannaDev — Mon, 30 May 2022 00:07:20 +0900

<<< 목차 >>>
[1] 웹소설 1차 - 상세 목차 API 일정 회고 => 상세 목차 API => 구현 4일 + PR 수정 3일 => 총 7일+a 소요
[2] 웹소설 1차 - 5월 4주차 일정 회고 => 구현 및 PR 에 따른 수정 6일+a

[1] 웹소설 1차 - 상세 목차 API 일정 회고

일정을 회고합니다. (구현 4일 + PR 수정 3일 => 총 7일+a 소요)

[일정 회고]

5/9 (월) ~5/10 (화) +사전 작업

대시보드 clip 목록 조회 API 구현
- 레이어드 구조로 구현 => PR => 피드백 & 수정
[A] 테스트를 위한 웹소설 clip 데이터 insert API 구현
- Webnovel dummy (호접몽전 복제) <<< 데이터 생성

5/11 (수) +1일 차

[A] 를 통한 테스트용 데이터 세팅
- Webnovel dummy (호접몽전 복제) : 하루에 clip 한 개 open, 기다무 무료 clip 하나 open, 기다무 무료 clip 하나 close…. 등의 테스트가 용이한 데이터로 설계 및 세팅
상세 목차 API 구현 시작
- 클라 + 서버 설계 논의 (2h+)
- 스팩 확장
  - 여러 이슈로 Contents-info API 에서 Clip 목록 분리하기로 결정
  - 클라 로직을 서버 측으로 가져오기로 결정 (OPEN, LOCK, DDAY)
  - 전체 다운로드 버튼 로직도 클라에서 서버 측으로 이관 결정
상세 목차 API 구현률 Zero 로 회귀

5/12 (목) +2일 차

어제 논의한 내용을 바탕으로 재생 관련 API 리딩 + 요구사항 분석 및 파악
상세 목차 API - 페이징 구현
상세 목차 status 로직 파악 및 분해 - 조립

5/13 (금) +3일 차

양방향 + center 커서 구현
연재상태 - clip 함수 구현
- 테스트 코드 도입 - 로직 검증
로직 구조 변경 (리팩토링)

5/15 (월) +4일 차

상세 목차 API - 재생률 구현
PR 요청 및 알파 환경 배포
클라 측 피드백에 따른 커서 수정
- 양끝단 커서 null 처리는 나중으로 미룸

5/16 (화) +5일 차

PR 피드백에 따른 수정 - 1일 차
시리즈 Hotfix 작업

5/17 (수) +6일 차

PR 피드백에 따른 수정 - 2일 차
시리즈 Hotfix 배포 (⑅˃◡˂⑅)
상세 목차 API - 커서 보완
pagination 회의 참여 (2h) + 회식 참여 (3h)

5/18 (목) +7일 차

PR 피드백에 따른 수정 - 3일 차
- PR - 1차 완료 (*ˊᵕˋo o
재생 관련 API 수정할 부분 파악 및 코드 리딩
- Contents-info API
- Play-Data API

=> 상세 목차 API => 구현 4일 + PR 수정 3일 => 총 7일+a 소요

[일감 재분배] - 22/05/29 (일) 기준

대시보드 CUD => 이관
요일별 연재 / 요일별 랭킹 => 이관
전체 재생 / 전체 다운로드 버튼 상태 로직 <= 나에게로 이관
검색 API <= 나에게로 이관

[2] 웹소설 1차 - 5월 4주차 일정 회고

일정을 회고합니다. (구현 및 PR 에 따른 수정 6일+a)

[일정 회고]

5/20 (금) +1일 차

재생 관련 Contents-info API 수정
Clip code list API 구현 (전체 다운로드 관련 API)
전체 재생 / 전체 다운로드 버튼 상태 로직 구현
- 클라 로직 → 서버로 이전
- 과장님께 로직 컨펌

5/23 (월) +2일 차

전체 재생 / 전체 다운로드 버튼 상태 로직 구현 => PR 요청
- 질문 및 의문점 클라 측과 소통 - 로직 수정
상세 목차 API - PR 에 따른 수정 (clip status 함수 구조 변경)
- can_play 를 기준으로 분해 - 재조립

5/24 (화) +3일 차

다운로드 관련 API 및 함수 - PR 피드백 및 수정
[B] 상세 목차 API - 성능 개선
Play-data API 수정

5/25 (수) +4일 차

Play-data API 수정 및 Swagger 문서 업데이트
대시보드 - clip 목록 조회 API 등 조율
- 알파 환경 → 권한 오류 (2h) → 갑자기 시간 지나니 권한 있음으로 해결됨 (원인 파악 X)
- 중간 중간 날짜 패턴화 로직 구상 도와드림~~ (feat. 과장님)
[B] 성능 개선 부분 관련하여 clip image 가져오는 로직 구조 변경
최근 재생 목록 API 요구사항 분석 및 파악
- 쿼리 구상…

5/26 (목) +5일 차

최근 재생 목록 API 쿼리 구상
- Visual Explain 돋보기로 성능 분석 (재생 기록을 많이 가지고 있는 사용자일 수록 시간 cost 상승)
- SQL 쿼리 구현
최근 재생 목록 API 구현 - DAO 부분에서 STOP (4h)
- MySQL 상에서 구상한 쿼리를 ORM 문법에 맞춰 변환하는 과정에서 삽질 시작…( ･ั﹏･ั)
- Select 문에 Scalar Query 를 사용하고 싶다 => 되지 않는다 => 다른 방법들 시도 => 되지 않는다 => 생각… => 뭔가 삽질을 하고 있는 것 같다

5/27 (금) +6일 차

최근 재생 목록 API 구현
- 상무님께 질문 - DB 2번 갔다 오기 (이렇게 하면 2번째 부분은 캐싱으로 대체도 가능해진다)
최근 재생 목록 API - 커서 구현
최종 기능 확인 및 PR 요청

=> 구현 및 PR 에 따른 수정 6일+a

22/05/29 (일) 기준 칸반 보드 Ticket

> 한 줄 요약

상세 목차... 어려웠다... (내 작업들은 왜 다 알고리즘 문제같지 기분 탓인가)

> 적용할 점

일정 미리미리 산정해서 혼자 못 다할 경우 도움을 요청하자
회사 생활에서 마감은 매우 중요!
구현 전 설계할 시 뭐부터 해야될 지 모르겠다면 처음과 끝 (controller, dao) 부터 생각해서 이어가자

[오늘의 달 사진 #3] 음악분수대 옆에서

HannaDev — Sun, 15 May 2022 20:49:41 +0900

음악 분수대

업무 학습일지 TIL (Back-end 개발, 2022~)

[TIL ##1] 2023 업무 회고

▶ 목차

▶ 2023 업무 요약

▶ 2023 첫 번째 업무 - 건강 도메인 개발

▶ 2023 건강 도메인 업무 노트 中

▶ 2023 두 번째 업무 - B2B 건강 서비스 개발

▶ 2023 업무 회고 - 도서

▶ 마무리

[TIL #33] 업무 마무리

▶ 목차

▶ 첫 회사 업무 마무리

▶ 퇴사 주간 Time Tracker

▶ 4월 Monthly Tracker

▶ NEW 기술 블로그

▶ 싱잉볼 + 바다 여행

[Book #1] 만약 시간이 존재하지 않는다면 - 카를로 로벨리

▶ 목차

▶ 책 선택

과학 3법칙 - 아서 C. 클라크 (SF 소설가이자 미래학자)

▶ 책 소개

▶ 후기 (NEXT?)

▶ 번외 (양자 컴퓨터?)

[TIL #32] 2022 My Report - 업무편

▶ 목차

▶ 2022 -> 2023

▶ 2022 주요 업무 키워드

# 사용자 기반 서비스

진행한 주요 프로젝트는 총 3개 (시리즈, 웹소설, 챌린지)

# 서버 이슈

가장 빈도수가 높았던 서버 이슈는 RDB CPU 80-90% -> Server Down

대응 매뉴얼

▶ 업무 방식 - 업무 노트 및 일정 관리

# 업무 노트

총 13권 사용 + 스케치북 0.5권: 가장 많이 활용한 테마 '로직 설계', '요구사항 분석'

# 일정 관리

Planning Poker 방식 활용

▶ 의사소통 - QA 티켓 분포도

# 기획 관련 QA 티켓 비율 75% 감소 -> QA 기간 감축

기획 관련 QA 티켓 비율 -> 69% -> 57% -> 18% (빠른 처리가 불가능한 부분)단순 구현 miss -> 31% -> 43% -> 81% (빠르게 처리 가능한 부분)

# 웹소설 QA 티켓 분포도 (22년 6월, 9월 기준)

기획 관련 QA 티켓 비율 -> 69% -> 57%

단순 구현 miss -> 31% -> 43%

# 챌린지 QA 티켓 분포도 (23년 1월 기준)

기획 관련 QA 티켓 비율 -> 18%

단순 구현 miss -> 81%

▶ 독서 - 클린 코드 (리팩토링)

# 챌린지 코드 리팩토링

# 클린코드, 파이썬 클린 코드 (독서 2권)

▶ 2022 세부 타임라인 + 총평

[TIL #31] 2022 My Report - 일상편

▶ 목차

▶ 2022 -> 2023

▶ 문화 생활 - 공연 / 전시

총 공연 26회, 전시 3회

올해의 공연 TOP 3

총평: 재밌었지만 통장이 위험하다.: 2023년에는 1~2달에 1번만.

▶ 자기계발 - 도서 / 업무 노트 / 블로깅

도서 총평: 책은 너무 충동구매한 게 아닐까...? 복지포인트지만 좀 더 고민해서 선정해보자.: 2023년에는 흥미 위주보다는 좀 더 계획성 있게 책을 읽어보자.

업무 노트: 총 11권 사용 + 스케치북 0.5권: 가장 많이 활용한 테마 '로직 설계', '요구사항 분석'

블로깅 - Tistory: 총 게시글 50개 (TIL 30개, PEP 8개, Error 4개, 기타 8개): 가장 많이 작성된 테마 'TIL (Today I Learn)': 공백 기간 (22.06.11 ~ 22.12.28, 약 6개월) - 업무에 집중한 기간

총평: 업무 노트에 작성된 내용이 블로깅에 좀 더 활용되면 좋을 것 같다.: 업무가 바쁘더라도 적어도 2주에 한 번은 블로깅에 도전해보자.

▶공간 - 작업 공간

총평: 유리 칠판 활용하자 (...): 모니터암 만족도 100%

▶ 2022 -> 2023 총평

[Error #2+] 장애 리뷰 준비 & 올해의 장애 TOP 2

장애가 발생했다면 추후 재발 방지를 위해장애 리뷰를 진행합시다

목차

▶ 장애 리뷰 문서 형식

▶ 올해의 장애 TOP2 (RDS)

▶ 장애 리뷰 - 문서 작성 (Rabbit MQ)

목차 및 장애 경과

장애 원인 中

대응 및 개선점 中

▶ 장애 리뷰 - 논의가 필요한 부분

[Error #2] 연말은 에러와 함께~ (Rabbit MQ)

모니터링이 필요한 곳이 있다면모니터링 방안을 구상하자

목차

▶ 발생한 오류

▶ 타임라인

총 13권 사용 + 스케치북 0.5권
: 가장 많이 활용한 테마 '로직 설계', '요구사항 분석'

기획 관련 QA 티켓 비율 -> 69% -> 57% -> 18% (빠른 처리가 불가능한 부분)
단순 구현 miss -> 31% -> 43% -> 81% (빠르게 처리 가능한 부분)

총평
: 재밌었지만 통장이 위험하다.
: 2023년에는 1~2달에 1번만.

도서 총평
: 책은 너무 충동구매한 게 아닐까...? 복지포인트지만 좀 더 고민해서 선정해보자.
: 2023년에는 흥미 위주보다는 좀 더 계획성 있게 책을 읽어보자.

업무 노트
: 총 11권 사용 + 스케치북 0.5권
: 가장 많이 활용한 테마 '로직 설계', '요구사항 분석'

블로깅 - Tistory
: 총 게시글 50개 (TIL 30개, PEP 8개, Error 4개, 기타 8개)
: 가장 많이 작성된 테마 'TIL (Today I Learn)'
: 공백 기간 (22.06.11 ~ 22.12.28, 약 6개월) - 업무에 집중한 기간

총평
: 업무 노트에 작성된 내용이 블로깅에 좀 더 활용되면 좋을 것 같다.
: 업무가 바쁘더라도 적어도 2주에 한 번은 블로깅에 도전해보자.

총평
: 유리 칠판 활용하자 (...)
: 모니터암 만족도 100%

장애가 발생했다면 추후 재발 방지를 위해
장애 리뷰를 진행합시다

모니터링이 필요한 곳이 있다면
모니터링 방안을 구상하자