Log-Chang

2025년 상반기 회고하기

Kid-Chang — Thu, 17 Jul 2025 23:32:18 +0900

돌아온 회고의 시간.

이번 회고는.. 성장 회고보다는 그냥 내 일상과 생각, 잡설을 나열하고 있다. 당연하게도 그 누구도 이 글을 읽을 필요는 없다.

이번 상반기는 참 다사다난했다.

최종적으로는 예상치 못하게 학교를 마치지도 못한 채로 은행 ICT직군에 취업하여 연수과정까지 마치고 당장 다음 주부터 첫 출근을 앞두고 있다.

자, 월별로 가보자.

1월

1월 1일 군대 아침 식사 포춘쿠키에서 나온 문구. 이것 때문에 속상하기도 힘이 되기도 했다. 흘려서 잃어버릴 뻔했던 4월의 어느 날까지 항상 내 지갑에 넣어 다녔었다. 지금은 보관함에 따로,,

12월 중순쯤부터인가 단기 자동차보험을 가입하고 어머니 차를 매일 몰았다. 나름의 운전 경험을 쌓고, 언젠가 쏘카 한 번쯤 빌릴 날 오지 않을까 싶어서이기도 하고, 차를 타고 다닌다는 게 아직까지는 재미있었기도 하다. 집에서 역, 그리고 도서관의 반복이었지만 그래도 운전대를 잡고 액셀을 밟는다는 게 재밌었다. 도서관에 가서는 12월에 공부하던 알고리즘을 계속해서 꾸준히 풀었고, 동시에 CKA 준비도 같이 하였다. 양이 꽤나 많아서 걱정이 많았지만 길~~게 휴가를 나와서 남는 게 시간이다 보니 9시까지 도서관 가서 6시에 퇴근하는 일정을 반복했다. 끝나고는 친구 만날 일 있으면 만나고 쉴 땐 쉬고...
이때는 참 웃긴 게 노트북이 없어서, 원격으로 세팅해서 썼던 미니 피씨와 외장 모니터, 키보드를 주렁주렁 매일 들고 가서 공부했다.
얼마나 이상한 놈으로 봤을까 싶긴 한데,,,

시험 직전에는 알고리즘 공부 비중을 줄이고 CKA에 투자를 바짝 해서 다행히 1월 중순쯤 CKA를 원트에 취득했다. 떨어져도 한 번 더 칠 수 있지만, 굳이 뭘 한번 할걸 두 번 할 필요가 없으니,,

그리고 월말에는 본가 친구들과 써울여행을 한번 갔다 왔다. 안산 사는 나보다 대전에 있는 친구가 오히려 더 지리를 잘 알더라..

이쯤에는 전역 후 고정수입이 없으니 어떻게 돈을 벌지에 미쳐있었다. 정확히는 돈을 악착같이 모으고 싶었다. 군 적금은 노트북 사는 용도 빼고는 쓰기 싫었고(지금도 한 푼도 쓰지 않았다.) 이를 위해 학교에서 돈 벌 수 있는 수단은 정말 많이 알아봤다. 그중 학교에서 멘토링 하는 사업도 서울 여행 중 급하게 신청해서 온라인으로 면접을 보고 합격했다. 추가모집이라 절차도 정말 간소화되어있어서 면접 당일 바로 합격 메일이 왔다. 최종적으로는 군 적금을 지키면서 월 100시간 정도를 멘토링, 서포터즈, 교내 근로로 일하면서 기숙사비, 생활비에 썼다...

한번은 당근 윈터테크 온라인 설명회를 참여했다. 뭐라도 도움 되겠지 싶어서 말이다.

이때부터 클라우드 직군 중에서도 SRE에 관심을 가지고 조금 더 찾아보기 시작했다.

그리고 여기서 나오는 최대한 슬라이드를 캡쳐했는데 이런 내용이 있었다.

작년 썸머테크를 통해 입사한 분의 팁 중 "지원하는데 돈이 들지 않는다!"가 특히 마음에 들었다. 합격하지는 못하더라도 그 과정 하나하나에 많은 것을 배울 수 있을 것이고, 그 과정은 내가 치뤄보지 않았더라면 절대 "남의 글"로만은 얻을 수 없을 것이다. 그리고 이 슬라이드가 올해 내 인생을 바꾸었다.

이때부터는 나름의 기준을 가지고 인턴이든 신입이든 써보자고 생각하고 노션에다가 채용공고가 뜨는 기업들을 정리하기 시작했다.

5월까지까지 정리한 기업과 JD

2월

이때는 군에서 친해진 친구들과 일본 여행을 짧게 갔다 왔다.
이때도 아이패드와 키보드를 들고 가서 밤마다 애들 잘 때쯤 알음알음 코테 풀고 아침에도 일찍 일어나서 공부했다.
정말 소마는 꼭 붙어보고 싶었다. 그래도 놀 땐 제대로 놀고,,!

혼자 하루 일찍 일본와서 스벅 코딩..

개맛도리 크로와상

다들 그런지는 모르겠지만, 3학년을 목전에 둔 나에게는 "칼 취업"이라는 단어가 꽤 강한 압박을 가해 왔다. 4학년 1학기 때부터 취업 프로세스를 밟아 졸업 전에 취업 확정을 받고 싶었다. 그러기에는 나에게 부족한 점이 많았다.
"칼 취업"을 위해 소마에 가야 한다고 생각했고, 소마에 가기 위해서는 코딩 테스트를 잘 해야 한다. 코테 기간은 얼마 남지 않았는데, CKA 준비, 서울 여행, 일본 여행들로 준비할 시간이 없어서 더더욱 초조해졌다. 더불어 클라우드 클럽 동아리에 지원도 하고 면접도 보면서 특히 정신없이 지나갔다(MSA의 제대로 된 정의를 모르는 멍청했던 내 이야기도 블로그에 있다).
전역 준비까지... 하니까 2월은 정말 짧게 스쳐 지나갔다.
전역하는 주에는 멘토 OT를 위해서 학교를 갔다가 다음날 부대에 복귀하기 위해 가방에 군복을 쑤셔 넣어 가보기도 하고,,

2월 28일 자로 전역함과 동시에 그날 소마 1차 코테 합격 메일을 받았다.

군대 짐을 정리한 택배도 기숙사로 보내고, 전역 당일 군복을 입고 기숙사에 입사하러 갔다. 그리고 바로 기숙사 행정실 근로 면접을 보고 나서는 바로 노트북을 챙겨 도서관에 갔다. 전역 당일에도 코테를 준비했다. 떨어지기 싫어서.

찐이다..

3월

면접을 망쳤다고 생각했는데 정말 좋게 봐주셔서 클라우드 클럽에도 합격했다. 그래서 전역한 주 주말 OT를 위해 AWS 오피스를 갔다. 대기업 오피스는 처음 가봤는데, 대기업은 다르더라...

그리고 그다음 주에는 앞서 서울에서 급하게 면접 봤던 멘토링 활동의 첫 OT 시간을 가졌다. 멘티들 성격이 다들 좋아서 다행이었지만 신입생들이 대다수다 보니 처음엔 좀 어려웠기도 하다. 나중에는 멘티들과 야구장, 한강도 가고 술도 먹으면서 친해졌다. 농담삼아 2학기 때도 같이 멘토링하자 했지만, 이젠 그럴 수는 없게 되었다.

3월 중순쯤은 참 힘들었다. 소마 2차 코테 떨.... 커트라인 문제까지는 테케를 맞은 거 같은데 정답은 아니었나 보다. 군대 마지막 휴가를 투자한 결과가 면접도 가보지 못했다는 게 참,,,

비밀글로 써놓은 하소연 글 ㅋㅋ;

멘탈이 나갈 때는 항상 여기로. 기울어진 나무가 내 처지 같다.

그리고 이때 학교에서 신설된 사업 관련 서포터즈가 있어서 돈도 벌 겸 신청했다. 이전에 연합동아리 운영했던 경험으로 스근하게 합격~

또한, 시기는 조금씩 다르지만 이때쯤부터 3개의 인턴과 1개의 정규직에 지원했다.

3월 말에는 구름 커밋과 AWS 한국 사용자 모임의 아키텍처 소모임에 가봤다. 현직자분들 이 팁들을 알려주셨고 꽤 좋은 경험이었다.
그리고 언제 또 구름 오피스나 AWS 오피스를 가보겠어.

그리고 멘토링 활동 체육대회하겠다고 아래 사진의 큰 공을 멘토들끼리 들고 가는데 참,,,, 저 날 다들 고생 많았더라.
난 클클 스터디한다고 중간에 탈주했긴 한데,,, 미안합니다.

4월

22년도부터 함께 놀던 자치회 구성원들끼리 진~~짜 오랜만에 만났다. 4월 초에 만나서 클라이밍도 하고 밥도 좀 먹었고. 4월 말에 또 만났을 때는 독일에 가있는 선배도 같이 만났다. 건강하더라!
세월이 흐르다 보니 모두 학생이던 사람들 사이에 언젠가 대학원생, 직장인이 된 사람들도 생겼다.

언제 한번은 군대에서 친한 친구들과 중앙동에서 만났다. 서로가 누가 더 불행한 복학생인가 배틀을 벌이기도 하고,,,
물론 과 동기들이랑도 학과 행사에서 나름의 청춘도 즐기고... 학교에서 연계해 주는 bpf 개발 프로젝트에도 참여하게 되었다. 바쁘다 바빠...

이때쯤에 키움 두산 전을 보러 야구장에 처음 가보았다. 재밌더라. 맛있는 것도 많고. 이후에 2~3주마다 야구를 한 번씩 보러 간 거 같다.

5월

면접의 반복.

중간중간 전시회도 보러 가고 청계천도 놀러 가고 축제도 따로 즐기고, 호공에서 밤새워 대화도 나누며, 정말 좋은 경험을 많이 했다.

생각보다 사람이 너무 많았던 론 뮤익 전시

5월 중순쯤 정규직 신입으로 지원한 회사에 서류 합격을 했다. 수요일에 발표했지만 금요일에 ncs와 코테..
서류를 붙고 알았다. 코테에서 파이썬이 안된다는걸.
도서관에서 자바 코테와 ncs 책을 빌렸지만 두께와 내용들을 보고 포기했다.

좋은 경험이나 하자!는 마인드로 그냥 코테를 위한 자바 공부만 조금하고 시험을 쳤다. 뭐 비공개 글에 정리해놨지만 요약하자면 이때 느낌으로는 꽤 난이도 준수한데? 싶었다. 실제로도 다행히 ncs가 좀 쉽게 나왔다고 한다.
그다음 주 월요일에 서류 붙었으니 목요일 면접 오세요~라는 통보를 받았고, 부랴부랴 면접 준비를 했다.
첫 기업 면접이 4시간짜리라 힘들었다. 시간은 짧았지만 면접을 도와주시는 선배가 있어서 최선은 다한 거 같았다. 그렇지만 1차 면접을 보고 나선 아.. 떨어졌구나. 좋은 경험 좋은 경험~ 마인드였는데, 면접 본 다음 주 화요일, 1차 면접을 합격했다는 내용을 접했다. 다음 면접도 마찬가지로 시간이 없기도 하고, 축제 술약, 부스 운영도 끼어있어서 시간이 많이 모자랐지만, 나름 준비를 했고, 내용 면에서는 이전에 도와주시던 선배도 보더니 많이 발전해서 정말로 수정할 부분이 없다고 잘 준비했다고 해서 다행이었다.

2차 면접도 끝나고 나서는 어라라..?

6월

붙었다.
이때부터 몰려온 수많은 고민,,
붙은지 4일 후에 연수원 입소를 해야 한다.
지금 막 군대를 전역하고 3-1로 복학한지 3개월 된 시점,,, 취업을 하는 게 맞는지 잘 모르겠다.
지면에 담기는 힘들지만 고민도 정말 많았고, 취업도 해야 하고,, 모르겠다.
학교에 남아있을지 취업을 해야 할지의 결정이 내 손에 달려있었다.

솔직히 너무 슬펐다. 기숙사 짐을 다 뺀 토요일 밤에는 방에서 서럽게 울었다.

물론 누군가에게는 황당하게 들리겠지만, 최소한 나에게는 그렇다.

JD를 정리하면서 느낀 취업시장의 벽을 확실히 알고 있었다. 내년, 내후년이면 뚫지 못할 거 같았다. 이번 기회도 정말 말도 안 되는 운으로 합격했다고 생각한다. AI는 말도 안 되는 속도로 일자리를 잡아먹는다. 개발자 거품이 꺼짐과 동시에 AI의 발전으로 채용의 벽은 너무나 두터워졌고, 시간이 갈수록 말도 안 되는 속도로 벽이 더더더 두껴워질거란 걸 알았다.
그렇지만 지금 학교에서의 수많은 경험들을 잃기 싫었다. 너무나 싫었다. 더 경험하고 싶었다.
결국엔 실패했지만 어떻게든 지방 본점이 아닌 서울 개발 부서로 발령받겠다는 다짐을 하고 짐을 빼기 시작했다.

그리고 연수원 입소. 연수원 내용은 다뤄도 되는지 몰라서 따로 작성하진 않으려 한다.

당연하게도? 남자 동기 중에는 내가 제일 어렸지만, 남녀를 통틀어서도 내가 제일 어렸던 건 신기했다.
특히 또 기억에 남는 게 HR 부장님께서도 나를 기억하셨다. 아직 졸업 전인데 학교는 어떻게 할 거냐는 질문 주신 것도 기억하셨고, 전체적으로 정말 답변을 잘해서 인상 깊었다고도 하셨다.

7월

연수를 모두 끝내고 이제는 대구 개발부서로 발령받아 개발팀 연수를 새롭게 받고 있다.

분명 수습기간에는 가벼운 토이프로젝트를 한다고 얼핏 들었는데, 그게 아니라 많이 당황스럽다.

배울 것도 많고 스스로의 실력을 증명도 해야할 것이다.

다음 하반기 회고를 쓸 쯤에는 어떤 성장과 어떤 굴곡을 지나왔을 지 궁금하다.

잡설

# 선택지

난 항상 여러 선택지에서 하나를 고르라면 최선의 선택이 무엇인지 모르겠다. 그러한 혜안은 어떤 경험으로도 길러지지 않는다.
다만 최악만은 면해보기 위해 발버둥 치고 있다. 선택한 것이 옳은 방향인지는 몰라도, 최악은 아닐 것이라 믿는다.
사실 이러한 내 성격 때문에 "고민의 참견"이라는 서비스도 기획하고 개발해 본 적도 있다ㅋㅋㅋ 제대로 런칭은 못했지만,,,

20살이 되고 대학을 고를 때도 그랬다. 6개의 수시 원서를 모두 붙었고, 그중 1지망인 학교가 한양대 에리카, 경북대, 국민대 3개였다. 그중 어느 곳을 가도 선택하지 못한 학교에 대한 후회가 많을 거라 생각했고, 실제로도 그랬다. 그래서 선택하고 나서도 몇 달은 은근하게 스트레스를 받아왔다.

21살 때도 그랬다. 연합 동아리의 학교 회장을 어쩌다 맡을 기회가 생겼는데, "특정한" 이유로 이를 수락해야 하나, 말아야 하나 너무 고민했다. 지금도 이게 옳은 선택인지 모른다. 그냥 다른 선택지를 택하지 않은 것에서 너무나 미안할 따름이다.

지금도 그렇다. 과연 내가 대학교 3-1을 마치기도 전에 입사를 한 이 길이 옳은 길인지는 모르겠다. 그렇지만 최종 합격 후에는 내가 그만둔다고 해서 예비가 붙지는 않는다는 사실을 듣고는, 누군가의 짧으면 며칠, 길면 몇 년의 노력을 나로 인해 잃게 된다는 사실 특히 내가 포기하면 그냥 없는 자리가 되어버린다는 내용을 들었을 때는, 참으로 미안했다. 선택을 했으니 이젠 앞으로 밀고 나아가야 하지만. 이번에 서울 발령을 받지 못했기에 은연 중 속상한 마음이 강하다.

# 취업, 돈

취업에 대한 생각을 좀 일찍부터 했다. 부모님이 주말도 없이 힘들게 돈 버시는 모습을 아주 어렸을 적부터 보아왔기에 그랬을 것 같다.

고등학교도 인문계를 갈지 소프트웨어 마에스트로 고등학교를 가서 일찍 취업할지 고민했었다. 이때 고민 상담을 해주시던 대구 소마고 분은 최근에 깃허브를 보니 무신사 등 좋은 커리어를 쌓고 있어서 이 방법도 괜찮았을 거 같긴 하다.

사실 대학교 2학년 때도 금전적 문제로 대학교를 휴학하고 군대를 가야 했었다. 그러나 의도한 건 아니지만 약간의 욕심을 부려 내 생활비를 더 많이 벌면서 억지로 2학년까지 다니고 군대를 갔다. 입대한 이후, 복학하고 나서도 부모님의 손을 빌린 적이 없다. 모든 돈은 내가 악착같이 모아 생활했다.

혹시 이런 내가 누군가에게 돈을 쓰는 것에 망설임이 없었다면 그 친구는 정말 소중한 사람이었을 것이다.

20살에 처음 친해진 동기도 여러 이유로 취업을 빨리하고 싶어 했고, 그래서 잘 맞았던 거 같다. 그래서 서로 힘이 되어 악착같이 공부했다. 이 동기랑 길게 친구가 되지 못해서 아쉬울 따름이다.

21살 때는 연합 동아리를 총괄하면서 3~4학년들을 정말 많이 접했고, 동시기에 오픈소스컨트리뷰톤을 하면서는 우리 팀의 좋은 직장에 다니는 분들을 많이 만나 뵈었다. 나도 그분들처럼 좋은 실력을 가지고 빨리 대기업에 가고 싶었다.

이때도 사실 남들보다 이른 나이에 대외활동을 하고 있었다. 어느 곳을 가나 나보다 어린 사람은 찾기 어려웠고, 다들 이른 나이에 이런 활동을 한다고 신기해했다. 그냥,, 취업 압박이 너무 강했었던 거 같다.

24살인 올해도 그렇다. 당장에까지 급하게 취업을 할 생각은 아니었지만, 결국 내 실력에 비해 너무나 좋은 기회를 얻어서 입사를 했다.
아마 나이로는 동기뿐 아니라, 회사 내에서도 최연소일 거라 예상하고 있다. 이에 따라 남들보다 더 많은 챌린지가 기다리고 있을 것 같아서 두렵기도 하다.

친구들은 취업했다고 축하해 주면서 한편으로는 진심 어린 걱정해 주기도 한다. 많이들 하는 일반 휴학을 한 적도 없고, 대학도 칼같이 입학했다. 휴학이나 재수한 사람도 많다고, 24살이라는 나이에 취업은 너무 이르다고, 즐기고 다양한 경험을 해볼 나이에 너무도 일찍이라고 말한다. 물론 가지말라고는 안한다. 그저 안타깝다고만,,, 사실 나도 그렇게 생각한다. 26살에 칼 취업도 요즘 시대에 빠른데, 거기에 2년이나 앞선 건,, 오히려 독인 것 같기도 하다.

# 목표지향적

물론 좋은 인간관계를 형성해 나가는 것도 중요한 목표이지만, 몇 년 동안 "대기업 취업"이라는 훨씬 큰 줄기의 목표가 있었다.
취업에 대한 큰 줄기 목표 아래에 프로젝트, 자격증 취득, 대외활동 등 다양한 세부 목표들이 정해져있었다. 그걸 위해 달려나갔지만, 지금은 큰 줄기의 목표가 사라졌다. 갑작스럽게 크나큰 동력을 잃었다. 이제는 무엇을 새로운 목표로 삼아야 하는지를 고민해 볼 때가 왔다. 물론 회사에서 새로운 챌린지가 있겠지만, 내 개인의 목표를 새로 새워야 한다.

그리고,,,,,, 못다 한 대학 생활, 잡고 싶지만 잡을 수 없는 몇몇 희망들이 아직도 너무나 아쉽다. 잡을 수 있을지 모르겠다.

작년에 작성했던 목표를 다시보자

1분기
- CKA 취득 -> 성공
- 소마 준비 -> 코테는 열심히 준비함
- 관련 동아리 지원하기 -> 클라우드 클럽 합격
2분기
- 소마 합격! -> 실패
- go언어 학습 -> 성공. ebpf 공부와 함께 진행.
- 인턴 계속 지원하기 -> 신입 합격,,,,

3, 4분기 목표는 일단 회사 적응부터 하고 잡아보자...

아직 회사 주변 주거지 문제를 해결 못해서 본가에서 매일 6시에 일어나서 출근하는데 2시간 걸린다..

퍼센타일(P90, P95, P99)이란?

Kid-Chang — Sun, 1 Jun 2025 13:53:58 +0900

필자는 현재 클라우드클럽 시즌2 스터디에서 go언어를 기반으로 하는 부하테스트 도구를 만들어보고 있다.

부하테스트 결과에 대한 분석 지표를 위한 방법 중 퍼센타일을 확인하는 법이 있다고 하여, 내용을 알아보았다.

퍼센타일(percentile)은 실제 사용자 경험에 가까운 성능을 알려주는 지표로, P뒤에 붙은 숫자 값 이하의 값들은 이 시간 이하로 응답을 하였다는 것을 나타난다.

만약, P90이라면?

전체 요청 중 90%는 이 시간 이하로 응답됐다. -> 즉 10%는 이 시간보다 응답이 느렸다,

만약, P95이라면?

전체 요청 중 95%는 이 시간 이하로 응답됐다. -> 즉 5%는 이 시간보다 응답이 느렸다,

만약, P50이라면?

전체 요청 중 50%는 이 시간 이하로 응답됐다. -> 즉 50%는 이 시간보다 응답이 느렸다.(중앙값)

평균은 극단값에 영향을 너무 많이 받아 왜곡되기 싶기에, 퍼센타일을 통해 실제 사용자 경험에 가까운 성능을 보여줄 수 있다.

---자세한 설명은 추후 추가

[책] "(가상 면접 사례로 배우는) 대규모 시스템 설계 기초"를 읽으며 - 4주차

Kid-Chang — Thu, 3 Apr 2025 23:04:28 +0900

필자는 클라우드 클럽 7기 시즌1 스터디에서 시스템 붕괴 방지 위원회(줄여서 시붕방) 스터디를 참여하게 되었습니다.

3월 안으로 (가상 면접 사례로 배우는) 대규모 시스템 설계 기초 책을 읽고 국내 대기업의 시스템은 어떻게 이루어져 있을지 설계하고,

4월에는 해당 책의 2탄을 읽고 마찬가지로 설계 해보는 스터디입니다.

우리 팀의 대부분은 직장인이지만, 필자는 대학생이기에 읽어보니 새로운 것들이 너무나 많은 것 같아 블로그에 정리하는 것도 목표로 두고 있습니다.

단순히 책 내용을 요약정리하는 것이 아닌, 인상 깊었거나 궁금했던 점들 위주로 정리하는 것이 글의 주 내용입니다.

당연히 슬프게도 틀린 내용이 있을 수 있으니 질문은 언제나 환영입니다.

설계해보기.

[책] "(가상 면접 사례로 배우는) 대규모 시스템 설계 기초"를 읽으며 - 3주차

Kid-Chang — Thu, 20 Mar 2025 11:41:54 +0900

필자는 클라우드 클럽 7기 시즌1 스터디에서 시스템 붕괴 방지 위원회(줄여서 시붕방) 스터디를 참여하게 되었습니다.

3월 안으로 (가상 면접 사례로 배우는) 대규모 시스템 설계 기초 책을 읽고 국내 대기업의 시스템은 어떻게 이루어져 있을지 설계하고,

4월에는 해당 책의 2탄을 읽고 마찬가지로 설계 해보는 스터디입니다.

단순히 책 내용을 요약정리하는 것이 아닌, 인상 깊었거나 궁금했던 점들 위주로 정리하는 것이 글의 주 내용입니다.

당연히 슬프게도 틀린 내용이 있을 수 있으니 질문은 언제나 환영입니다.

# 10장 알림 시스템 설계

날라갔네요 허허

분산 시스템에서 중복전송을 100% 막을 수는 없다고 하네요.

# 11장 뉴스 피드 시스템 설계

# 190p 두 종류의 팬아웃 모델1. 쓰기 시점에 팬아웃하는 모델(푸시모델)새로운 포스팅이 올라오자마자 뉴스 피드를 갱신시킴(해당 사용자의 캐시에 해당 포스팅을 기록장점: 뉴스 피드가 실시간으로 갱신, 친구 목록에 있는 사용자에게 즉시 전송, 새 포스팅이 기록되는 순간에 피드가 이미 갱신되므로 뉴스 피드를 읽는 데 드는 시간이 짧아진다.단점: 친구가 많은 사용자의 경우 친구 목록을 가져오고 그 목록에 있는 사용자 모두의 뉴스 피드를 갱신하는데 많은 시간이 걸린다.(핫키)서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야함으로 컴퓨팅 자원의 낭비로 보이기도 한다.

2. 읽기 시점에 팬아웃하는 모델(풀모델)요청 기반(온디맨드) 모델이다.장점: 비활성화된 사용자, 또는 서비스에 거의 사용하지 않는 사용자의 경우 이 모델이 유리,데이터를 친구 각각에게 푸시하는 작업이 필요없으므로 핫키 문제가 생기지 않는다.

단점: 각 사용자가 뉴스 피드를 읽는 데 많은 시간이 소요될 수 있다.

이 두 모델을 적절히 혼합하여, 대부분의 사용자에게는 푸시 모델을 사용하고, 친구나 팔로워가 아주 많은 경우 풀모델을 적용해볼 수 있다.

또한, 안정 해시를 적용해 부하를 줄인다.

# 12장 채팅 시스템 설계

채팅기능을 구현하기 위해서는 HTTP, 폴링, 롱 폴링, 웹 소켓 정도의 프로토콜을 고려해볼 수 있다.

웹 소켓을 제외하고는 실시간 채팅을 구현하기에 대부분 비효율적인 구조이다.

기본 설계안에는 일반적으로 HTTP통신을 하는 로드밸런서와 별개로 채팅 서버와 접속 상태 서버는 웹 소켓 통신으로 분리되어 있다.

서비스 디스커버리: 클라이언트에 가장 적합한 채팅 서버를 추천하는 역할.

이때 사용되는 기준으로는 클라이언트의 위치, 서버의 용량 등이 있다. 아파치 주키퍼 등의 서비스가 있다.

사용 가능한 모든 채팅 서버를 서비스 디스커버리에 등록시켜 놓고, 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라준다.

로직을 간단하게 말하자면, 사용자가 로드밸런서를 통해 특정한 API서버에 로그인 후 서비스 디스커버리가 여러 채팅 서버 중 적절한 채팅 서버를 골라서 관련 값을 리턴해주면, 사용자가 이제 해당 채팅서버로 웹소켓 통신을 보낸다.

특정 유저 두 명이서 채팅을 한다고 했을때, 웹소켓을 열어 하나의 채팅 서버에서 대화하는 것이 아닌, 각 유저 별 다른 채팅서버에 연결되어 있어도 상관없고, 메시지 동기화 큐에 의해 서로 소통하게 된다.

같은 유저가 여러 단말을 이용 중이라면 cur_max_message_id 와 같은 변수를 통해 각 디바이스 별 마지막 메시지 id를 키-값 저장소에 보관된 메시지와 비교해본다.

그리고 그룹 채팅의 경우 각 사용자 별로 별개의 메시지 큐를 가지고 있다. 사용자마다 메시지 수신 상태가 다르기 때문이라고 한다.

그룹이 크지않다면 메시지를 수신자별로 복사해서 큐에 넣는 작업이 비용이 문제가 되지 않는다.

# 217p 접속상태 확인을 위한 박동 검사

정말 단기간 인터넷이 끊어지는 경우 매번 오프라인 상태로 취급하는 것은 사용자 경험 측면에서 좋지않다.

대신 클라이언트가 주기적인 박동 이벤트를 접속상태 서버로 보내고 이벤트를 받은 지 x초 이내 새로운 이벤트를 접속상태 서버가 수신 받지 못하면 오프라인 상태로 전환한다.

작은 규모의 단체 방이라면 publish-subscribe 모델을 통해 접속상태 변경을 다른 모든 유저에게 제공하면 된다.

규모가 커진다면 이런 이벤트 하나에 수 십만 건의 이벤트가 발생하기 때문에 유저가 수동으로 조회하도록 유도하는 것이 좋다.

# 13장 검색어 자동완성 시스템

입력한 단어에 따른 검색어 추천을 위해 흔히 생각해볼 수 있는 방법은 검색된 단어마다 빈도를 +1 해주는 빈도 테이블(query, freqency)을 만들고, 아래 쿼리처럼 이용하는 방법이 가장 무난할 것이다.

select * from freqency_table where query like 'prefix%' order by freqency desc limit 5

하지만 위 방법은 데이터가 많아진다면 병목이 발생할 수 있다.

p231 최적화하기

데이터가 많아지더라도 병목현상이 생기는 것을 방지하기 위해,

1. trie(접두어 트리, retrieval에서 나옴) 자료구조를 사용한다.

접두어의 길이 p, 트라이 안에 있는 노드 개수 n, 주어진 노드의 자식 노드 개수 c라 가정하면,

시간복잡도는 O(p)+O(c)+O(c log c) 로 산출할 수 있다.

2. 접두어 최대 길이 제한

O(p)에서 O(상수) 처럼 제한을 걸어 시간을 단축할 수 있다.

3. 노드에 인기 검색어 캐시

미리 각 접두어 마다 인기 있는 검색어 5개씩을 캐싱하는 방법으로도 최적화를 이룰 수 있다.

p235 로그 취합 서버

앞선 방식들을 이용해도 트라이에 대해 개선할 부분은 여전히 있다.

매일 수천건의 질의에 따라 발생하는 빈도값 변화를 매번 갱신할 필요는 없다. 일주일에 한 번 정도만 또는 상황에 따라 하루에 한 번 정도만 갱신해도 트위터 같은 실시간 서비스가 아니라면 문제가 없을 것이다.

트라이 갱신방법은 크게 두가지로 볼 수 있을 것이다. 첫번째로는 갱신 때 마다 새로운 트라이를 만들어 기존 것을 대체하는 방법

두번째로는 각 노드를 개별적으로 갱신하는 방법. 당연히 각 노드를 개별적으로 갱신하는게 더 빠르지 않을까 싶었는데, 이는 하위 노드를 하나만 갱신하더라도, 이미 각 상위 노드마다 캐싱된 값들도 변경해줘야하기 때문에, 새롭게 트라이를 만들어 대체하는 것이 더 효율적이라고 한다.

# 14장 유튜브 설계

꼭 모든 서비스를 밑바닥에서부터 쌓아올릴 필요는 없다고 한다. 적절한 기술을 골라 주어진 시간 안에 설계를 마치는 것이 더 중요하다.

글로벌한 비디오 업로드/다운로드 서비스를 만들려면 CDN을 도입해야할텐데, 이 비용이 만만치 않다. 이를 줄이기 위해 지역별 인기 비디오, 조회수가 높은 비디오 등 특정 조건을 설정하여, CDN에 저장한다.

# 15장 구글 드라이브 설계

데이터를 업로드할 때, 사용자가 api서버와 통신하여 업로드 관련 내용을 처리한 후 디바이스 -> 블록 저장소 -> 클라우드 저장소 순으로 데이터가 업로드 된다.

이때, 디바이스에서 바로 클라우드 저장소로 가지 않고 블록 저장소를 거치는 이유는 파일을 블록으로 나누고, 압축 알고리즘을 적용하고 암호화 하는 등 업로드에 관한 처리를 담당해줘야하기 때문이다.

이때, 데이터 발송 최적화는 델타 동기화와 압축 두가지를 이용할 수 있는데, 각각 파일이 수정되면 전체 파일 대신 수정이 일어난 블록만 동기화, 블록 단위로 압축해 용량을 줄이는 방법이다.

[책] "(가상 면접 사례로 배우는) 대규모 시스템 설계 기초"를 읽으며 - 2주차

Kid-Chang — Tue, 11 Mar 2025 00:58:07 +0900

필자는 클라우드 클럽 7기 시즌1 스터디에서 시스템 붕괴 방지 위원회(줄여서 시붕방) 스터디를 참여하게 되었습니다.

3월 안으로 (가상 면접 사례로 배우는) 대규모 시스템 설계 기초 책을 읽고 국내 대기업의 시스템은 어떻게 이루어져 있을지 설계하고,

4월에는 해당 책의 2탄을 읽고 마찬가지로 설계 해보는 스터디입니다.

단순히 책 내용을 요약정리하는 것이 아닌, 인상 깊었거나 궁금했던 점들 위주로 정리하는 것이 글의 주 내용입니다.

당연히 슬프게도 틀린 내용이 있을 수 있으니 질문은 언제나 환영입니다.

# 6장 키-값 저장소 설계

91p: 키-값 저장소키-값 저장소는 키-값 데이터베이스라고도 불리는 비 관계형 데이터베이스입니다.아마존 다이나모, 멤캐시드, 레디스 등이 있습니다.

93p: CAP정리

분산 키-값 저장소(분산 해시 테이블)을 통해 여러 서버에 키-값들을 나누어 저장할 수 있습니다. CAP정리를 이해해야하는데, consistency(일관성), availability(가용성), partition tolerance(파티션 감내)라는 세가지 요구사항을 동시에 만족하는 분산 시스템을 설계하는 것은 불가능하다는 정리입니다.

여기서 일관성과 가용성은 들어봤는데, 파티션 감내성이라는 용어는 처음 들어본다.파티션 감내: 파티션은 두 노드 사이에 통신 장애가 발생하였음을 의미한다. 파티션 감내는 네트워크에 파티션이 생기더라도 시스템은 계속 동작하여야 한다는 것을 뜻한다. (맨날 tolerance, 관용이라는 단어만 쓰다가 감내라는 단어를 쓰니 상당히 어색하네요. 아무튼 네트워크 문제가 생기더라도 시스템에 지장이 가지 않도록 해야한다는 뜻 같습니다.

근데 가용성과 파티션 감내의 차이점이 다르다고는 하는데, 이 차이가 아직까지는 와닿지 않습니다.

availability: 서버 3대 중 1대가 죽어도 나머지가 응답

partition tolerance: 서버 3대가 네트워크 단절되어도 각자 응답

이라고는 하는데 흐으음.... 서버에 접근하지 못하더라도 다른 서버가 데이터를 찾을 수 없다는 응답이라도 대신 보내준다고는 합니다.

조금 더 이해가 되면 내용 수정해보죠,,,

일단 이 3가지 중 2가지만 만족할 수 없다는게 CAP법칙!

만약, 파티션 문제(네트워크 에러)가 발생했을 때, 일관성을 유지할 것인지(CP시스템), 가용성을 유지할 것인지(AP시스템) 고를 수 있습니다.

95p: 어떤 케이스에 어떤 시스템을 쓰는가?

금융권의 경우 일관성 유지가 우선이므로, 서비스가 불가능하다는 에러를 보낼 것이고, 낣은 데이터라도 "응답"이 필요하면 가용성을 유지하는 것을 택하는 경우도 있을 것입니다.

98,99p: 데이터 다중화, 데이터 일관성

다중화는 말 그대로 여러 서버에 복제해서 보관하는 것이고(여기서도 해시링을 이용하는데, 가상 노드 중 같은 서버를 만나면 건너뛰고 처리할 수 있습니다.

일관성은, AWS 공부할 때 비슷한 내용을 본거같은데, 읽기나 쓰기 모두 정해진 정족수를 채워야 해당 행위가 컨펌되는 행위입니다.

이 정족수를 적절히 조절하는 것은 서버의 속도나 신뢰성을 조절하는 것과 마찬가지이죠.

101p: 백터 시계(vector clock)

D([S1, v1], [S2, v2], ...) D는 데이터, Sn은 서버 번호, vi는 버전 카운터라고 합니다.

서버에서 저장한 값이 없으면 [S1, 1] 을 추가하고, 카운터를 하나씩 올려갑니다. 이를 통해 이전버전이나 충돌에 대해 쉽게 파악할 수 있습니다. 빠르게 값이 변하면서 임계치에 도달하면 문제가 발생하다는 소리도 있었지만 AWS도 아직 그런 문제를 격은 적이 없다고 하네요~

107p: 머클트리

대규모 자료구조의 내용을 효과적이면서 안전한 방법으로 검증하기 위한 트리

각 서버 안의 버킷에 대해 균등 분포 해시 함수를 적용해 해시를 구한다. 그럼 각 서버의 버킷마다 해시값이 나오고 이를 리프노드로서, 부모 노드들을 만들어간다.

각 서버 본체가 루트노드가 되었다면, 이제 두 서버의 루트부터 해시값을 비교하면서, 해시가 다른 부분을 찾아나간다고 합니다.

이렇게 해서 문제가 생긴 버킷들을 찾고 해당 버킷들만 동기화 하면 된다. 즉, 서버 전체의 용량과 무관하게 차이가 있는 버킷만을 수정하는 것이죠.

근데 어떻게? 최신 정보를 가진 버킷이 어딘지 판단하고 덮어씌우거나, 백터 시계를 이용하거나, 사용자가 개입하는 등으로 처리할 수 있다고 합니다.

# 7장 분산 시스템을 위한 유일 ID 생성기 설계

하나의 서비스에 여러 서버를 이용하면서 유일한 ID를 만들기 위해서는 고민이 필요합니다.

단순히 DB의 auto increase를 이용하기엔 서버가 두개만 되어서 중복되는 아이디가 생기겠죠.

이를 해결하기 위해 첫번째로 UUID를 이용하는 방법이 있습니다.

이는 타임스탬프 등 아이디 자체에서 뽑아낼 필요가 없고, 각 ID당 길이가 128비트로 길어도 괜찮으면 가장 마음이 편한 선택지인듯 합니다.

# 8장 URL 단축기 설계

# 9장 웹 크롤러 설계

144p 크롤러 설계 시 알아둘 것

대규모랑 살짝은 다른 이야기지만, 단순히 파이썬 크롤러 딸깍하는게 아니라 고려할 부분이 몇가지 있습니다.

안정성(잘못된 주소, 반응 없는 서버, 악성 코드 등), 예절(짧은 시간에 너무 많은 요청을 보내면 안됨), 확장성(크롤링하고싶은 콘텐츠 별로 매번 새롭게 설계하는 것은 너무나도 비효율적이다. 뭐 절대 콘텐츠가 바뀌지 않는다!면 괜찮겠지만)

그리고 마지막으로 규모 확장성(병렬처리 등을 이용해서 수십억 개의 페이지를 효과적으로 크롤링하자)

150p 탐색 할 때 DFS? BFS? 어느 방향으로 갈까나?

방문하는 페이지에서 추가로 탐색가능한 페이지가 있다면 그걸 저장했다가 이용해야합니다. 이때, 어떤 알고리즘을 쓸지를 선택해야합니다. DFS(깊이우선탐색)은 어느 깊이까지 탐색을 할지 가늠하기 어려워 권장되지 않는다고 합니다.

그렇다면 BFS를 써야하지만, 여기에도 문제가 있다. 한 페이지에서 나오는 링크의 상당수는 같은 서버로 돌아갑니다.(정말 단순하게 사이트맵을 생각해보면 이해가 바로 된다.) 이렇게되면 아까 크롤러 설계 시 알아둘 것 - 예절을 지키지 않는 크롤러가 될 가능성이 높지요.

예의바른 크롤러가 되기 위해 같은 웹 사이트에 요청할 경우 시간차를 두어 실행하면 된다고 합니다.

이를 구현하려면 같은 호스트에 속한 URL 정보는 언제나 같은 큐에 가도록 하는 역할을 하는 "큐 라우터"를 만들어 줍니다.

근데? 그럼 같은 호스트에 속한 URL이 몇 개 될줄 알고 굳이 여러 큐를 구비해야하는 건 공간 낭비 아닌가?

라고 생각했지만 지피티가 역시 저보다 똑똑하죠.

큐를 정적으로 할당하는 게 아니라 필요한 상황에서만 동적으로 생성하면 된다고 합니다.

156p 신선도 유지

모든 url을 재수집하기에는 부담이 있으니, 우선순위를 활용해 각 사이트별 재수집 빈도수를 조정

157p 성능 최적화

다른 중요한 내용도 많지만 도메인 이름 변환기(DNS Resolver)에 대한 이야기가 꼭 필요한 거 같습니다.

DNS 요청을 보내고 결과를 받는 과정이 동기적으로 발생하고, 이는 크롤러 스레드 중 하나가 DNS 요청을 보내면 다른 스레드는 요청할 수 없어 병목이 생기게 된다. 이 문제를 해결하기 위해 도메인 이름과 IP 주소 사이 관계를 미리 캐시에 보관해 놓고 크론 잡을 돌려 주기적으로 갱신하여 성능을 개선시킬 수 있습니다.

160p 거미 덫

크롤러를 무한 루프에 빠뜨리도록 설계된 페이지가 종종 있습니다.

이러한 경우는 url의 최대길이를 설정해놓음으로서 빠져나올 수 있습니다.

소프트웨어마에스트로 16기 지원 회고 (2차 코테에서 탈락)

Kid-Chang — Sun, 9 Mar 2025 15:26:56 +0900

이번엔 소마 16기 지원하고 그 과정들을 간단하게 풀어내려고 합니다.

* 알고리즘 문제에 대한 자세한 복기는 없습니다. 그냥 간단간단한 회고!!

특히 이번 기수는 몇 년사이와는 다르게 선발인원이 반타작나서(110명...) 큰 기대를 하기 어렵긴 합니다만, 그럼에도 공고가 올라오기 전부터 군대 복무기간 라스트댄스처럼 준비했던게 소마 코테이기 때문에 끝까지 노력해야겠죠.

이 글까지 들어가서 구경할 정도라면 대충 프로세스를 아시겠지만 서류->1차 코테->2차 코테->면접->최종 선발 프로세스를 거칩니다.

서류는 소마준비 오픈채팅에서도 떨어졌다는 사람이 없다는거보면, 정말 "."만 적어서 내는게 아니면 붙여준다는 말이 사실인 듯 합니다.

[서류]

저는 1번에는 이때까지 했던 활동들을 몇가지 추려서 개발활동, 오픈소스 기여활동, IT 지식공유 이 3가지 카테고리로 작성했습니다.

2번에는 이전에 개발했던 링고프레스라는 서비스가 어느 부분이 아쉬웠고, 어떻게 보완하고 싶은지, 소마에서 어떤 지원을 받아서 성장하고 싶은지를 작성했습니다.

서류는 소마 12기 한 명과 개발자로 일하셨던 한 명을 붙잡고 계속 피드백받으면서 수정했습니다.

[코테 준비]

사실 알고리즘 준비를 한달 정도 밖에 못했습니다. 10월까지는 SAA자격증을 취득하느라 바빴고, 11월은 도저히 힘들어서 쉬고, 12월부터 CKA 자격증과 같이 준비를 했습니다. 1월에는 CKA에 집중해야해서 잠깐 내려놓고, 시험이 끝나고도 월말 서울 여행일정과 2월 초 일본 여행일정, 그리고 부대에 복귀하고 다시 나오는 과정들 때문에 제대로 집중을 못했네요...

12월~1월에는 이코테 책으로 전체 개념과 삼성 문제를 제외한 다른 문제들을 모두 두번씩 풀어봤습니다.

(근데 풀었다기보단,,, 대부분 못풀겠어서 해설보고 이해하고, 두번째 봐도 모르겠는건 세번보고,,,)

그리고 한 3주간의 공백기를 보내고 일본여행이 끝난 다음날부터는 프로그래머스의 알고리즘 고득점 킷과, SQL 고득점 킷, 백준에 사람들이 만들어 놓은 소마 대비 문제집이 정말 많은데 그것들을 잡고 계속 공부했습니다.

[1차 코테]

1번, 2번, 3번은 단순 구현이라 잘쳐줘도 실버 1 이하 문제들이었고, SQL도 join, ifnull정도만 알면 되는 문제였습니다.

4개의 문제를 푸는데 50분정도가 걸리더군요. 남은 시간을 4번에 투자했는데, 못풀었습니다....

4번 문제는 부분점수를 주는 골드 문제인데, 톡방에서도 난이도 가지고 열띈 토론을 하더군요.

저는 10% 부분점수만 맞도록 코드를 만들어서 제출했습니다.

아마 프로세스를 어떻게 적절하게 분배할건지와 관련된 문제였던 걸로 기억합니다.

이렇게 톡방에서 3,4솔이 가장 많았고, 합격자도 특별한 경우가 아니면 3솔인 듯 합니다.

합격발표가 작년엔 코테 다음주 수요일이었다가 이번에는 금요일로 바뀌어서 좀 더 쫄렸지만, 다행히 1차는 합격했습니다.

발표날이 전역일과 같아서 긱사에서 짐 풀면서 합격메일을 받으니 기분이 상..당히 좋더군요 ㅎㅎ

[2차 코테]

사실 1차 코테를 치루고 난뒤에는 코테공부를 거의 못했습니다. 부대에 복귀해서 짐 택배도 붙이고, 사진도 찍고, 생활관 단체 외식도 나가는 등 잡다하게 해야할 것들이 많았거든요.

합격 메일을 받고나서부터 다시 공부를 시작했는데, 돈을 벌기위해 기숙사 교내근로, 멘토링활동 등 다양하게 일을 벌려놓기도 했고, 클라우드 클럽이라는 활동에 합격해서 OT 가고 하는 무슨 말도 안되는 일정이 쌓여있었네요... 그리고 다행히(!) 밥 약속도 있고해서 아침일찍 일어나고 공강시간, 저녁 늦은 시간을 최대한 활용했습니다.

사실상 일주일 밖에 시간이 없어서 백준의 소마 대비 문제집들을 여러 번 돌리고, leetcode에 있는 문제를 풀고 정리하는 일의 반복으로 처리했습니다. 근데 그때 좀 어려운 문자열 문제같은 건 버리고 좀 효율적으로 공부하겠다고 DFS, BFS, 그리디, DP 계열만 주구장창 풀었는데, 이번에 완전히 깨졌습니다.

1번은 유사한 문제가 프로그래머스의 조이스틱 문제(레벨2)인데 사실 이 문제 어려워서 해설 한번만 읽고 버렸는데, 1번문제를 보자마자 헉,,,, 후회했습니다. 1번이 신기한게 부분정답이 있어서, 저는 일단 50%부분정답을 목표로 해결했습니다. 아마 프로그래머스 기준으로 레벨2와 유사하니까 실버1? 골5? 정도 이지 않을까 싶네요.

그 이후에 SQL을 바로 풀었는데, 이것도 사실 어려운 건 없고 case문이랑 join 좀 잘 사용하면 해결되지 않을까... 싶은 문제였습니다.

작년 SQL이 엄청 어렵게 나왔다길래 LAG, 재귀, CTE 뭐 별에별 문법 다 공부했는데 생각보다는 쉽게나와서(그렇다고 진짜 쉬운 문제는 아님) 아쉬웠습니다.

1번 부분정답에 SQL까지 푸는데 30분정도 쓴거 같네요.

그리고 빠르게 2, 3번 문제를 훝었는데(4번은 무조건 버린다는 마인드), 3번이 더 쉬워보여서 접근했다가 20분 동안 아무것도 못써서 멘탈이 털린채로 2번으로 넘어왔습니다.

2번은 dict을 잘 이용만 할줄 알면 그렇게 어렵진 않아서 한 30분 정도 사용했습니다. 30분 쓴거면 어려운건가..?

함튼 2번까지 푸니까 40분정도가 남았어서 1번 전체정답을 목표로 다시 풀었는데 생각보다 금방 풀려서 10분만에 처리했네요.

남은 시간은 혹시나 하는 마음에 풀었던거 다시 전체적으로 검토하고도 시간이 남아서 3, 4번 그냥 구경만 하다가 나왔습니다.

일단 시험이 끝나고나서의 톡방 반응은 1,2,5번이 너무 쉽게 나와서 다 풀었을 것이다. 못해도 3솔이 기준일 것이다. 였습니다...

투표도 보니, 3솔정도가 커트라인 일듯 한데, 문제는 제가 완벽하게 1,2,5번을 풀었는게 맞냐죠.

일단 기다려보겠습니다.

2차 코테에서 탈락..... 아마 엣지케이스 등에서 실수한게 많은거 같다.

그래도 많은 경쟁률을 뚫고 3배수? 2배수? 까지 갔다는 거에 만족을 해야지.. 다음에 또 노려봅시다!

[책] "(가상 면접 사례로 배우는) 대규모 시스템 설계 기초"를 읽으며 - 1주차

Kid-Chang — Sun, 9 Mar 2025 15:26:44 +0900

필자는 클라우드 클럽 7기 시즌1 스터디에서 시스템 붕괴 방지 위원회(줄여서 시붕방) 스터디를 참여하게 되었습니다.

3월 안으로 (가상 면접 사례로 배우는) 대규모 시스템 설계 기초 책을 읽고 국내 대기업의 시스템은 어떻게 이루어져 있을지 설계하고,

4월에는 해당 책의 2탄을 읽고 마찬가지로 설계 해보는 스터디입니다.

단순히 책 내용을 요약정리하는 것이 아닌, 인상 깊었거나 궁금했던 점들 위주로 정리하는 것이 글의 주 내용입니다.

당연히 슬프게도 틀린 내용이 있을 수 있으니 질문은 언제나 환영입니다.

# 1장 사용자 수에 따른 규모 확장성

# 2장 개략적인 규모 추정

37p 대규모는 이런거구나…

어느정도가 대규모일까? 끽해봤자 초당 100명 정도 접근해도 꽤나 대규모이지 않을까? 하는 다소 안타까운 생각을 하고 있었는데...

월간 능동 사용자 3억에
50% 사용자가 매일 매일 트위터를 하고
평균 매일 2건의 트윗을 올리고
미디어를 포함하는 트윗이 10%
5년간 데이터를 보관해야한다면

QPS 추정하기
3억*0.5=1.5억
QPS(query per second)=1.5억*2트윗/24시간/3600초 = 3500
최대 QPS(2배)=7000

미디어 저장소 요구량 추정하기
평균 tweet_id: 64byte, text: 140byte, media: 1MB
미디어 저장소→ 1.5억210%*1MB = 30TB/일
5년간 저장을 위해 5PB가 필요.

40p 시스템 설계 면접이란?

시스템 설계 면접은, 모호한 문제를 풀기위한 해결책을 찾아내는 과정에 대한 시물레이션과, 설계 과정에서 내린 결정들에 대한 방어 능력을 보이는 자리.

설계의 순수성에 집착하여 트레이드오프를 도외시하여 결국 오버엔지니어링을 한 결과는, 시스템 전반의 비용을 올리게 된다.

(오티 술자리에서 비용에 대해 깊게 생각해본 경험이 중요하다고 말씀하신 분이 떠올랐습니다..!)

# 3장 시스템 설계 면접 공략법

- 45p 캐시를 왜 저장할때 바로 사용할까?

면접 공략법이라는 내용에 무색하게 이 플로우를 보고 의문이 생겼다.

왜 저장 서비스에서 바로 데이터베이스에 저장을 바로 하지않고 캐시에 먼저 보내는거지?

아니 애초에 캐시는 데이터를 가져올 때에 속도를 줄이기 위함 아니었나?

~~캐시 제대로 안써본 티 팍팍~~

-> 그림에 나와있으니 당연히 이유가 있겠지만, 검색해보니

DB에 직접 쓰면 많은 요청이 몰릴 경우 부하가 커지고 속도가 느려질 수 있음
그래서 캐시를 먼저 거쳐서 데이터베이스로 저장하면 효율적으로 처리 가능 (이후 배치 작업 또는 비동기 처리로 DB에 저장함.)
대규모의 데이터들을 DB에 직접 쓰는 것이 병목이 될 수 있음.
DB에 즉각적으로 쓰는 대신, 캐시에 저장 후 나중에 DB에 반영하는 방식.
만약 피드 등록 후 친구들이 바로 포스트를 보려 하면, DB에서 가져오는 것보다 캐시에서 가져오는 게 훨씬 빠름.
포스팅이 등록되자마자 DB에 저장하고 그걸 다시 캐시에 넣는 것보다, 포스팅할 때 캐시에 먼저 저장하는 게 더 빠르게 반영됨.

와 같은 이유로 인해 캐시서버를 이용한다고 합니다.

하지만 SAA에서 캐시서버는 한두개 설치하는게 아니라고 배웠는데, 어떻게 동기화를 하지? 궁금했습니다.

실제로 특정 지역의 캐시서버에만 데이터를 가지고 있는 일관성 문제가 발생할 수도 있다고 하네요.

이를 해결하기 위해

글로벌 캐시 동기화 → 모든 지역 캐시에 실시간 복제(AWS Global Accelerator + Redis Replication)
캐시 미스 시 원본 캐시 조회 → 특정 지역에 없는 경우, 다른 지역 캐시에서 가져오기(Cloudflare Workers)
빠른 DB 저장 → 캐시에 저장할 때 DB에도 즉시 저장, 장점 상쇄.. (Amazon DynamoDB Streams 또는 Kafka)

정도의 해결책도 있다고 합니다.

# 4장 처리율 제한 장치의 설계

51p 처리율 제한 장치

처리율 제한 장치(rate limiter)는 클라이언트 또는 서비스가 보내느 트래픽의 처리율을 제어하기 위한 장치.

딱 보자마자, 예전에 프론트엔드 개발 중 검색기능에 디바운싱를 적용했던 것이 생각났습니다.

대표적으로 디바운싱 기능이 적용되지 않은 곳을 꼽자면 백준에서 검색 버튼을 누르고 뭔가를 입력할 때마다 바로바로 결과가 리프레쉬되는 걸 볼 수 있습니다.

그에 비해 네이버 검색 같은건 아주 약간이라도 딜레이가 있죠. 디바운싱은 프론트 단에서 검색에 대한 쿼리를 즉각적으로 보내는 것이 아니라, 약간의 텀을 두어, 사용자의 다음입력이 없는지 확인하고 서버에 요청하여 트래픽을 줄이는 목적을 가지고 있습니다.

근데 이게 프론트에 적용되어있다보니, 일반적인 유저들이 만드는 트래픽은 줄이겠지만, 서버에 직접 검색과 관련된 대규모 요청을 보내버리면 서버가 감당하지 못하는 것은 마찬가지 일듯 합니다.

책에서도 질문자가 "어떤 종류의 처리율 제한 장치를 설계해야하나요? 클라이언트 측 제한 장치 입니까, 아니면 서버 측 제한 장치입니까?"라고 물어보네요. (앞서 작성한 제 생각과 비슷한 내용이 바로 나오네요..ㅎ)

54p 처리율 제한 장치를 어디에 둘 것인가?

MSA를 사용한다면 API 게이트웨이에 붙여넣는 것이 좋기도 하거니와, 애초에 약간이라도 서버의 부담을 더 줄이기 위해서는 서버에 진입 전 게이트웨이 단에서 컷하는 것이 옳은 거 같긴합니다.

60p 고정 윈도 카운터 알고리즘에서 발생하는 버스트 트래픽 문제가 토큰 알고리즘에서도 똑같이 발생할 수 있는거 아닌가?

고정 윈도 카운터에서의 버스트 트래픽: 카운터 초기화 직전과 직후에 요청이 몰려서 서버 부하가 급격히 증가하는 문제

사실 책 설명대로라면 토큰도 1분당 몇 개씩 제공하니 비슷한 문제가 있지 않겠나 싶지만,

토큰 알고리즘은 1분에 4개를 제공한다고 해도, 일반적으로는 15초마다 1개씩 주어지는 식으로 동작합니다.

만약 "최대 보관 4개 + 1분 단위로 한꺼번에 4개 지급"과 같은 특수한 경우이라면,

특정 순간에 8개 요청이 발생할 수도 있지만 이는 설계 방식의 차이일 뿐, 토큰 버킷 자체의 문제는 아님.

관련된 헤더로는 x-ratelimit-limit, x-ratelimit-remaining 등이 있다. 이때까지 개발할때는 헤더에 토큰 말고는 뭘 의도해서 담아본 적이 없는 거같은데...

# 5장 안정 해시 설계

78p

server pool이란: 여러 개의 서버를 하나의 그룹으로 묶어 두고, 부하 분산(로드 밸런싱)이나 가용성을 높이기 위해 운영하는 개념

server pool이 고정되어있다는 것은 해당 그룹에서 서버의 갯수가 늘어나지 않는다는 소리이고, 해시 함수 등을 통해 어느 서버에 캐시 값을 저장할 지 서버인덱스 계산 식을 hash(key)%N 처럼 설계해도 괜찮다! 하지만, 현실은 다른 법. 서버가 다운되는 변수가 생긴다면 모듈러 연산에서의 N(서버 갯수)가 달라지고 이는 캐시 미스가 발생할 수도 있게 된다. 또한, %N으로 나눠서 저장할 서버를 결정하면, 서버 풀의 변동에 따라 값의 이동이 매우 커진다. 이를 해결하기 위해 안정 해시를 사용하기도 한다.

80p 안정 해시(consistent hash)?

기억해두면 좋을 개념같아서 정리해봅니다.

해당 내용은 https://www.youtube.com/watch?v=UQfNytDFpgk&t=102s 요 영상을 보고 읽으면 이해가 더 쉽습니다.

k는 값, s는 서버이다.

s와 k의 해시 값을 특정한 방법(일단 %n은 아님)으로 구하고 이를 해시 링(위 그림)에 배치합니다. 그리고 k가 시계방향으로 돌면서 가장 인접한 서버에 저장됩니다.

s3가 새로운 서버

그렇다면 만약 서버가 추가되더라도, 일부 값만 이동하면 되는거죠. 서버가 제거되는 상황도 마찬가지.

근데 여기서 단점이, 균등하게 분포되지 않는 문제가 발생할 수 있습니다.

이는 서버를 여러 파티션으로 나눠서 곳곳에 가상으로 배치하는 방법으로 해결합니다. 이때 서버를 가상 노드 또는 복제라고 부릅니다.

내가 만든 서비스가 MSA가 아닌가? (멍청)

Kid-Chang — Sun, 16 Feb 2025 20:56:32 +0900

블로그에 써놔야지... 하면서 아직까지 작성을 시작도 못한 프로젝트가 있다.

영어학습 서비스인 "링고프레스"다. 혼자 풀스택으로 개발하면서 나름 많이 배웠다고 생각하고, 이걸 정리해놓자! 싶었지만, 그 글을 쓰는 것보다 이 프로젝트로 면접에서 했던 이야기를 먼저 쓰게 되었다. 면접 결과 전에 외부에 말하지 말라고 했던 게 기억나서, 일단 비밀글로라도 후다닥 써본다.

며칠 전 개발 관련 연합 동아리 면접을 보던 중 "MSA를 이용했다고 하는데, 어느 부분에서 사용했다고 말할 수 있나요?"라는 질문을 받았다. 사실 서버를 분리하여 각 서비스별 안정성이 독립적이면 MSA이지 않을까 라고 생각했고, 이 짧은 생각을 지원서에 작성했다. 그러니 면접관이 의아하게 생각하고 물어본 듯하다.

현재 개발한 프로젝트는 하나의 VPC 안에 두 개의 인스턴스를 가지고 있다. 하나의 인스턴스에는 Whisper라는 서비스만, 다른 인스턴스에는 크롤링, 메인 백엔드, DB 컨테이너, RabbitMQ를 올려놨다. 여기서 (돈만 있다면) Health Check 기능을 올리고, AWS API Gateway 등을 이용해서 API 콜을 하나로 묶고, DB를 이중화하는 등의 기능을 추가하고 싶었다. 하지만 (돈이 없고 시간도 없기에) 딱 지금한 정도까지에서 멈춰있다. 이 정도가 MSA인가? 라는 생각을 했지만 일부 도메인별 분리를 해놨고, 여기서 헬스체크 기능만 더하면 기본 MSA는 된다고 생각했다. 이전에 인프런의 스프링 클라우드 강의에서 몇몇 서비스를 분리하고 유레카나 스프링 컨피그 등을 붙여서 MSA라고 설명했던 게 기억났기 때문이다.

나는 어떤 문제점 때문에 서비스를 각 인스턴스로 분리했고, 이러한 부분을 MSA라고 생각했다고 답변했다. 면접이 끝나고 다시 찾아보겠다는 말을 좀 길고 횡설수설하게 했는데, 면접관의 표정을 보아하니 틀린 답변이었던 듯하다. 이때부터 '아... 좀 더 고민해볼걸' 하는 후회가 들었다.

더불어 쿠버네티스가 뭔지 설명해보라는 질문에도 "서버를 안정적으로 유지하게 해주는, 아마존에서 제공하는 서버 재시작 등의 기능들을 종합한 것" 정도로 답변했다. 하지만 면접관은 그냥 간단하게 "MSA를 실현시킬 수 있는 서비스" 정도로 요약해도 된다고 하셨다.

하하... 참 준비가 부족했다. 면접이 끝나자마자 부랴부랴 클러드와 티키타카를 했는데, 아래와 같은 답변을 주더라.

서비스를 물리적으로 다른 인스턴스에 분리 배포 도커 컨테이너로 각 컴포넌트 분리 메시지 큐를 사용한 비동기 처리

이 정도인데, 이는 단순히 "분산 시스템" 또는 "모듈화된 모놀리식 아키텍처"에 가깝습니다.

진정한 MSA가 되려면 다음과 같은 특징들이 필요합니다:

서비스별 독립적인 비즈니스 로직과 데이터베이스
서비스 간 느슨한 결합 (Loose Coupling)
각 서비스의 독립적인 배포/확장 가능
API Gateway를 통한 중앙화된 진입점
서비스 디스커버리 메커니즘
Circuit Breaker 등의 장애 대응 패턴

면접에서는 "현재 제가 구현한 것은 완전한 MSA는 아니지만, 서비스를 물리적으로 분리하고 메시지 큐를 활용해 비동기 처리를 구현한 분산 시스템 아키텍처입니다. 이를 통해 리소스 관리와 장애 격리의 일부 이점을 얻을 수 있었습니다."라고 답변하는 게 더 정확했을 것 같네요.

그래요. 부끄러움을 느끼고, 더 공부합시다.

CKA 취득 후기

Kid-Chang — Sat, 18 Jan 2025 13:36:13 +0900

취득 계기

쿠버네티스에 대한 공부는 24년도 초에 (CKA 준비용이 아닌) 유데미 강의를 보면서 조금해보았지만, 막상 제대로 구성해본 프로젝트도 없어서 이론만 겉핥기로 배우는 느낌이 강했었다. 그렇다고 군대에서 실습환경을 구성하기도 불가능에 가깝죠..

또한, 인프라를 구성하고 작업하는 프로젝트 특성상 혼자할 수 있을까라는 생각도 들었습니다. 군대에 있다보니 인원을 제대로 구해보기도 쉽지 않아보였기에 말이죠.

그래서 AWS 자격증을 취득했을 때와 마찬가지로 군 복무라는 특수성에 의해, 자격증을 취득하기로 했습니다.

공부순서

역시 유데미. 만 오천 원에 이 시험을 취득하는 사람이라면 누구나 듣는 뭄샤드 강의로 구매했습니다.

24년 12월 중순부터 하루에 1~2시간정도만 보다가 1월이 되고서야 온종일을 투자할 수 있었습니다. 그렇게 합쳐서 3주 가량은 이론 강의와 실습을 보는데 시간을 썼습니다. 근데 일 년전이긴 해도 한 번 공부했던 경험이 있어서 막 어려운 느낌은 아니었습니다.

근데 막상 이론 뒤에 따라오는 실습을 풀때부터 모르는게 너무 많았습니다. 대다수의 문제가 힌트나 솔루션을 보지않고는 풀기가 어려웠죠. 그래서 처음에는 망했따... 싶었습니다.

머리가 깨지기를 몇번 반복하고, 시험을 보기 일주일 전 부터는 라이트닝 랩과 mock exam을 풀었죠. 근데 라이트닝 랩을 풀때는 진짜... 시험을 볼 수준이 아니란 걸 깨달았습니다. mock exam도 마찬가지였고요. 실습이랑은 또 다른 느낌이더군요. 과연 시험을 치를 수 있을까 걱정이 정말 많았습니다.

근데 이틀 동안 이 연습시험을 세번 반복하니까 자신감이 붙었습니다. 그래도 이론은 꾸준히 듣고 실습도 해봤다보니, 연습시험을 한두번 해보니 어떻게 푸는지 감이 잡히더라고요.

연습시험이 익숙해고나서는 이성미 강사님의 [CKA 기출문제 핵심 요약] CKA 기출문제 풀이_FULL 버전 강의를 두 번 돌려봤습니다. 참고로 (2회차) 라고 적힌 강의 영상에 문제 pdf도 다운받을 수 있습니다! 2회차 영상은 안봤는데 pdf내용이 같은걸 보니 강의 내용도 비슷할 겁니다.

특히 이 강의는 실습 환경도 제공해줘서 아마 많은 도움이 될겁니다. 저는 환경상 여기 실습은 해보지 못했습니다.

이 기출문제 풀이 영상도 눈에 익는다 싶으면, killer 문제를 풀어보고요. 다른 글 찾아봐도 똑같이 말하지만 그냥 kube config use-context 명령어를 꼭 써야하는구나!를 인지하고, 원격 시험환경 익히는 정도로만 알고있어도 충분합니다!

참고로 killer 홈페이지는 공식문서에서 한글이 깨지는데, 시험칠때는 한글 잘 보입니다.

마지막으로 아래 두 블로그 글을 반복해서 읽었습니다. 시험이랑 거의 비슷하게 나와서 이것도 많은 도움이 되었습니다.

[CKA] 기출문제 정리

CKA 기출 문제 복기 및 접근법 정리[24.11.24 응시]

요약하자면 이론 및 실습 -> 라이트닝 랩, mock exam -> 이성미 강사님 기출풀이 -> killer -> 블로그 글 참고

순으로 공부하였습니다. 사실 이론 및 실습 공부가 3주 정도 차지했고, 나머지 부분은 하루종일 공부한다고 가정했을 때 일주일이면 충분합니다.

이론을 충분히 익히면 시험 문제에 익숙해지는 건 금방인거 같습니다.

시험

저는 사이버 먼데이 때 구매했습니다. 이때는 반값이거든요. 다행히 환율이 오르는 12월의 어느 특별한 날 전에 미리 환전을 해놔서 그나마 낮은 금액을 결제했던걸로 기억합니다. 지금이면 할인해도 1~2만원 정도 비싸겠네요.

예약할때는 한국 시간을 기준으로 예약할 수 있고, 최소 24시간전 시간에 예약이 가능합니다. (나중에 오는 메일을 보니 제가 치룬 시간이 미국기준 새벽 4시 정도이더군요..)

이때 미리 신분증을 업로드할 수 있는데 그러면 시험 치룰때 따로 신분증 확인은 하지 않는거같다군요? 그래도 혹시나 하니 챙기시길 바랍니다.

또한, 노티를 몇개 보면 시험환경을 테스트 할 수 있으니 미리 해보시는 걸 추천드립니다.

시험은 온라인으로 보고, 사방이 벽이고, 주변이 비어진 장소에서 응시가 가능합니다. 저는 딱히 그런 공간을 찾을 수가 없어서 침실을 싹 비우고 치뤘습니다.

시험을 치기 30분 전부터 접속하여 psi 브라우저를 설치하면 됩니다. 접속하면 감독관이 채팅으로 이것저것 물어봅니다. 말하지는 않아서 듣기에 취약한 저도 문제없이 채팅으로 잘 답변했네요.

환경은 killer와 거의 동일하니, 한번 해보셨다면 문제를 푸는거에는 딱히 불편함이 없을 겁니다.

그리고 합격 컷은 66점 입니다. 위에 적혀있는대로 다 공부하면 충분히 합격컷일 겁니다. (물론, 2월 10일 이전에 치룬다는 기준!)

저는 94점으로 나름 고득점? 한거같아서 기쁘지만 66점만 넘어도 합격 컷이기도 하고, retake기회가 한번 있기도 하니 너무 부담가지시지 않으셔도 될거같습니다.

시험후기

사실 음... 이 자격증이 제 능력을 대변하기는 어렵다는 생각을 가졌습니다.

시험도 1시간 10분만에 끝냈고, 문제도 어렵지 않았습니다. 아마 기출에서 유사하게 나왔고, 이전에도 계속 유사해서 출제를 했겠지요. 2월부터는 시험유형이 조금은 바뀐다고 하던데...

내가 어떠한 범주에 대해 광범위하게 안다는 것을 증명하기 위해 자격증을 취득했지만, 막상 시험은 기출에서 봤던 유형들이 정말 조금씩 바뀌는 정도라,,, 빛 좋은 개살구랄까요.

물론 얻어가는게 없는건 아닙니다. 시험이 목적이 아닌 정말 쿠버네티스를 다루기 위해 공부했기에 이론을 충분히 학습하려고 노력했고, 어려 기출문제와 killer를 풀면서 어떤 상황이 발생하면 어떻게 대응할 수 있다에 대한 기본은 잡혔으니까요.

2월부터는 시험에서 Configure workload autoscailing, Use the Gateway API to manage Ingress traffic, Use Helm and Kustomize to install cluster components 와 같은 내용이 추가된다고 합니다. 실무에 조금 더 가까운 내용들이라고 하네요.

강의에서는 다룬 적이 없지만 아마 시험이 바뀌고나면 추가되겠지요? 저도 여기서 멈추지 않고, 추가되는 강의들을 들어보려고 합니다. 사실 저 항목들이 꽤나 중요해보이거든요.

2022년 상반기 회고하기

Kid-Chang — Tue, 7 Jan 2025 15:51:28 +0900

24년 12월 30일, 한달간의 휴가를 마치고 부대에 복귀하면서, 갤러리를 뒤적거렸습니다.

24년도부터 스크롤을 올리면서 아이폰을 처음 쓴 21년도까지의 사진들을 빠르게 넘겨보면서 문득, 아 이런 기억들이 있었지? 싶었던 것들이 차츰 떠오르기 시작했습니다. 과연 내가 21년도 22년도에 무엇을 했을까를 한번 글로서 적어보고 싶은 충동이 들었고, 다음번 휴가 나오면 적어봐야겠다는 다짐을 했습니다.

휴가도 나왔고, 오늘은 집에서 쉬는 날이기 때문에 글을 한번 적어봅시다.

사진을 담으면 좋겠지만 너무 귀찮은 관계로, (사진을 첨부하지 않은) 사진 기반 글 작성~

우선 뭔가를 많이했던 22년도부터!

21년 11~12월

22년도 회고지만 두달만 더 땡겨서 21년도 11월, 저는 중대한 고민을 하게됩니다. 여러 복잡한 사정들이 맞물리면서 군휴학을 할지 1년 더 다니고 휴학할지를 고민하던 차 였습니다. 근데 1년을 더 다니기에는 나름의 명목이 필요했었죠.

이때 우테코에 대해 좀더 찾아보고 이거면 이유가 되겠다 싶어서 지원을 했습니다.(가차없이 컷) 그리고 다른 어느날 컴공선배라는 유튜브의 커뮤니티에 UMC의 학교별 회장단을 모집한다는 글도 올라옵니다. 아 이것도 재미있겠다! 싶어 며칠 고민하다가 지원서를 냈습니다. 이때 21년도에 약간의 깃과 프론트를 다뤄본 경험과 도커에 대해 공부하고 멘토링 했던 경험을 써서 냈고, 면접을 참여하게 됩니다.

이 동아리를 후원하는 회사원 두 분과 2기 총괄이 3:1로 면접을 봤습니다. 면접에서는 개발경험보다도 책임감과 운영 능력에 대해 평가하는 듯 했습니다. (개발능력이 중심이었다면 저는 떨어졌겠죠...)

면접에서는 참 우연찮게도 재미있는 상황이 있었습니다. 면접관 중 한명이 다름아닌 제 본가와 걸어서 10분거리인 옆 아파트 사람인겁니다? 면접이 끝나고 밥도 같이 먹으면서 이것저것 이야기하면서 전화번호도 교환하게 되었죠. 하지만 아무리 같은 동네 사람이라도 공과 사는 확실히 구분해야하니, 면접결과가 나오길 기다리고 있었죠.

그 과정에도 약간의 일이 있었지만 결과는 합격, 22년도 1학기 UMC 2기부터는 제가 우리 학교에서 처음으로 이 동아리를 이끌게 됩니다.

그리고 이 시기 21년도 2학기에 부원으로 참여했던 기숙사 자치회에서 좋은 기회를 얻어 "대외협력부장"이라는 직책을 얻게되었습니다. 부장 자리를 얻으면 약간의 장학금 등 여러 맛있는 혜택이 있었기에 더할나위 없었죠. 끼얏호우~

방학

UMC 준비하기

방학동안 동아리에서 제공해준 프론트엔드 부트캠프를 들으면서 처음으로 리액트를 배웠고, 협업을 해보았습니다.

그러는 와중에 허겁지겁 교내 운영진을 구성하면서 운영준비를 했죠.

우리 학과의 고질적 문제 중 하나인 학회 동방의 부재는 예전부터 말이 많았지만 해결책이 없었기에 이때 중앙동아리도 신청하였습니다. 임시 동아리? 한학기를 지내고, 추후 중앙동아리 회장들의 동의가 있다면 정동아리도 승격함과 동시에 동아리방을 얻을 수 있기 때문이었죠.

2월 말에는 면접을 몰아보았습니다. 최대한 많은 사람들에게 기회를 주고싶어 정말 성의가 없는 사람들을 제외하고는 다 뽑았었죠.

기숙사 자치회

방학기간동안 자치회일도 많았습니다. 사실 제 직책은 다른 업무가 적은 대신 짐꾼에 가까웠습니다. 도미니라는 냉장고등 기숙사용품 대여 업체와 협력하는 직책이었거든요. 반납하는 냉장고나 대여해줄 냉장고를 옮겨야했는데, 방학기간에는 제 부서에 부원도 없었기에 저 혼자나 다른 부장들 꼬득여 같이 했었습니다.

그리고 자치회는 말이죠, 직무관련 활동을 제외하고는 22년도 중 가장 잘 뿌듯했고, 즐거웠던 활동이었음은 틀림없습니다.

코로나

하필 2월 말 코로나에 걸렸습니다. 외부 활동도 종종 있었고 기숙사 교내 근로도 진행중이라 정말 수많은 사람들과 지나치면서 마스크를 잘 써도 한번쯤은 걸리겠거니 싶었습니다. 심지어 코로나 걸린 사람들에게 방역복을 입고 음식 배달을 해주는 근로도 하고 있었던지라....

정작 국을 나눠먹은 형이 코로나에 걸려서 저도 같이 걸렸었습니다. (농담삼아 몸 괜찮냐고 물어봤는데 완전 말짱하다던 그..)

이때 본가에 내려가기도 힘들고, 그렇다고 기숙사에 남아있을 수도 없어서, 하루 이틀만 기숙사 격리 층에 머물다가 평택에 있는 격리장소로 이동했습니다. 5일인가 1주일인가를 2인 1실로 격리하였죠. 그때 같이 계신 형님은 전담을 몰래 가져와서 화장실에서 피우셨지만, 냄새가 심하진 않아 그러려니 했던 경험도 있네요. 친절하시고 정말 재미있었던 형님이셨어서ㅎ..

1학기

정신없이 바빴던....

이때는 말도 안되게 바빴었습니다.

UMC운영, 교내근로, 기숙사 자치회, 한가지함 활동(봉사학점), 창업 프로젝트 등등...

3월

UMC는 30개 가까운 학교가 참여하기에 대부분의 활동은 교내 또는 몇 학교를 묶은 연합으로 진행되었습니다.

에리카는 당시 그나마 지리적으로 가까운 아주대/인하대/숭실대/중앙대와 함께 CHASI(중앙, 한양대에리카,아주,숭실,인하의 약자를 따서 지은) 지부라는 이름으로 활동했었습니다.

연합 OT과 교내 OT를 진행하고 회식도 한번 했던거 같습니다

교내 OT를 진행하면서 사람들과 대화해보니, 참 우리학교의 아쉬운 점이 교내 동아리가 활발하지 않는다는 점이라는걸 알게되었습니다. 다른 학교는 안가봐서 모르겠지만, 학교 홈페이지에 나와있던 대부분의 동아리는 사라져있고, "제대로" 돌아간다 싶은 동아리는 한 두개 정도였습니다. 그 흔한 GDSC도 없고,,,,

우리학교 사람들도 많은 기회를 가지고 활동을 할 수 있으면 좋겠다는 생각에 UMC 운영에 더 적극적으로 임하자는 동기부여를 하는 시간이었죠.

OT를 끝낸 주에는 본가 친구들과 안산 대부도에 놀러갔다왔습니다. 약간의 리프레시랄까요. 스쿠터도 타보고, 바다도 구경하고, 중앙로에서 술도 먹고 말이죠.

본격적으로 교내 스터디 팀을 꾸리고 운영하는건 스터디 운영진들에게 어느정도 넘기고, 연합 활동들을 많이 찍어냈죠.

연합 세션, 팀 매칭, 스터디 일정 조율 등 몸이 갈려 나갔습니다.

팀원 학교 투어 등 재미있을 법한 활동들도 기획했지만 이건 아쉽게 무산이 된...

그런데 이때부터 다들 슬슬 중앙 운영에 불만을 가지기 시작했습니다.

구체화된 내용은 없고, 너무나 추상적인 활동들 뿐이었거든요. 사실 교내 스터디를 스터디 운영진에게 넘길 수 밖에 없던 이유가 이거였습니다. 추상적으로 던진 기획안들을 우리 지부 학교리더들끼리 밤마다 모여 구체화하는 작업을 하고있었죠.

그래도 활동 자체는 재미있었습니다. 교내 사람들을 모아서 CMC 데모데이에 대려가기도 하고 아이디어톤도 자체적으로 열면서 어떻게든 교내 사람들에게 많은 것을 보여주려고 노력했었으니까요. (이때는 몰랐죠. 저도 아직 좁디좁은 우물 속에 있던다는 사실을)

그리고 어느 날, 회장단 면접때 면접관이었던 동네 형이 연락을 주셔서 창업 프로젝트를 하고 있는데 프론트엔드 팀원으로 같이 해보지 않겠냐는 제안을 주셨습니다. 너무 소중한 기회라 생각하고 바로 승락을 했죠. 그렇게 "기글"이라는 창고 임대업 창업 프로젝트에 조인하여 몇달간 열심히 프로젝트에 기여를 했습니다.

여기서도 많은 분들을 만났습니다. 휴학을 하고 창업을 하고계신 분, 경영학과 졸업을 앞두신 분, 실제 회사에서 일하고 계신 디자이너. 이정도의 멤버와 함께하게 된 저에게는 속으로 막중한 책임감을 느꼈습니다. 실수하면 안된다는 압박에 꽤나 마음 고생을 했었기도 했네요.

이때 처음으로 AWS를 알게되었고 백엔드 개발을 맡았던 형의 github action 코드를 따라 쳐가며 S3->EC2로 배포하는 환경을 구현했었던 경험을 했었죠. dev, stage, prod 서버로 구분해서 배포한다는 개념을 배우는 등 실제 배포가 어떤건지 어깨 너머로도 배우면서 많이 성장했었다고 생각합니다.

하지만 기글은 결국 5월 중순쯤 여러 복잡한 문제로 1차 MVP배포를 목전에 둔 채 올스탑이 되었습니다...ㅠ

그래서 이때는 진짜 일주일에 5번씩 꼬박 회의가 있었습니다.

UMC지부회의, UMC교내운영진회의, 한가지함 회의, 자치회 회의, 기글 회의...

4월

4월엔 찍어놓은 사진들이 많이 없네요.

대망의 중간고사가 끝나고는 또다른 본가 친구들이 서울에 놀러와 같이 놀았습니다. 사실 서울가까이 살면서 한강을 가본 횟수가 손에 셀 수 있을 정도였지만, 그나마 몇번 가봤다고 전시회도 가고 공연도 보고 한강도 가는 등 알차게 시간을 보냈었네요.

5월

이때는 처음으로 학교 축제를 즐겨봤습니다. 대낮부터 기다려서 나름 앞줄을 차지해 연예인들을 가까이서 보기도 하고, 재밌었죠ㅎㅎ

그리고 마포 프론트원에서 CHASI 지부 아이디어톤을 진행했었습니다. 이때 다른학교 회장단 분들을 실제로 만난게 두번째인가 싶었는데 제일 어렸던 저에게 많이 배려해주셔서 너무 감사한 마음이 많이 들었습니다. 기억은 안나지만 재미있는 아이디어들이 많아서 아이디어를 구상하는걸 항상 힘들어했던 저는 넋놓고 바라봤던 기억이 있네요

그리고 이시기 쯤 우리 지부를 넘어 모든 학교 리더들이 중앙 운영에 대한 스트레스가 최고조에 달했을 겁니다.

이때까지 해당 문제에 대해 얘기하면 다음엔 개선하겠다는 말 뿐이고, 정작 개선되는 내용이 없었습니다. 그래서 지부별로 각자 활동들을 같이 논의하거나 지부에서 만든 내용들을 타 지부에 공유하는 등, 사실 상 중앙의 도움없이 활동하기 시작했습니다.

결국 해당 문제에 대한 여러 논의 끝에 저를 포함한 학교 운영진 몇명이 중앙 운영 대부분에 함께하기 시작했습니다. 데모데이 준비를 저와 다른 학교 리더 한분이 도맡아 관리하기 시작했죠.

그리고 대망의 첫 과MT..! 이때 모르는 얼굴도 많고, 소극적인 분들도 많아서 참 걱정이 많았지만, 새벽되니까 살아남은 사람은 살아남고 그 그룹에서 노니까 어찌어찌 재미있게 잠도 안자고 놀다 왔었네요.

그리고 기글이 끝나 아쉬워 하던 찰나 외주 기회를 얻게됩니다. 클라이언트가 외주를 의뢰하거나, 개발자에게 여러 외주 공고를 보여주는 페이지를 제작하는 거였어요. 처음으로 공수분석표를 받아보고, 이걸... 이 기간 안에 해야한다고? 라는 생각이 들었지만, 외주라는게 사실 학생을 배려해주는 건 아니다보니,, 계약을 하고 선금을 받는 순간에는 뭔가 아차! 싶었습니다. 내가 돈을 받고 개발을 할 수준이 맞을까?라는 압박을 받았습니다. 그리고 나중에가서보니 제가 만든 결과가 그리 좋지는 않더군요. QC 시트에 적힌 수많은 시나리오 Fail을 보면서 너무나 부끄러웠습니다. 기간을 맞추기위해 밤을 새면서 버그를 수정했죠. 덕분에 기말고사를 꽤나 말아먹었다는...ㅎ

6월

이때는 제 인생에 또한번 큰 터닝포인트를 얻게됩니다. 종종 연락하던 아주대 리더 누나가 오픈소스 컨트리뷰톤에 대해 알려주셨고, 여러 프로젝트를 찾아보다가 재미있을거 같던 쿠버네티스 팀에 지원서를 냈습니다.

사실 이때 쿠버네티스를 써보기는 커녕 도커로 이미지 빌드하고 컨테이너로 찍어냈던 경험 정도밖에 없었지만, 대신 이때까지 이런 경험들을 해왔고 앞으로도 끊임없이 공부할 것이라는 걸 강조했었던거 같습니다.

이때의 경험이 지금까지도 클라우드와 관련된 직업을 구해야겠다는 생각을 가지게 해준 소중한 경험입니다. 고맙습니다.

그리고 이 시기 동아리를 후원하던 회사에 현장실습 기회를 얻게됩니다.

어찌된고 하니 UMC에 제 몸을 갈아넣었던 것을 인정받았는지, 다음 3기의 중앙 운영(총괄)을 저게 제안하시면서, 어찌어찌 단계를 거쳐 회사에 하계 현장실습 기회를 구할 수 있었습니다.

사실 1기때는 처음이다보니 기획이 부족한게 당연한거고 2기때는 약간이라도 안정화 될 줄 알았으나 큰 변화가 없어서, 저에게 밑바닥부터 기획을 다시 쌓아올려달라는 거였습니다.

사실 UMC 학교 리더중 제가 제일 어리기도 하고, 절대적으로 봐도 21살 밖에 안된 저에게 이 기회는 꽤나 부담이었습니다.

하지만, 2학년인 제가 언제 이런 경험을 해보겠습니까ㅎㅎ 물론 개발 직군은 아니고 PM 직군이지만 결국 현장실습생이 되었습니다.

당연하게도 외주, umc 준비 등의 활동이 겹쳐 중간보다 못한 기말 성적이 나왔고, 학점은 그야말로 바닥을 쳤습니다....

기숙사도 학점이 낮아 못들어가나 걱정했는데, 다행히 자치회 부장은 우선입사 기회가 있더라고요.

7월

오픈소스 컨트리뷰톤 최종 합격연락을 받고 정말 기뻤습니다. 합격하고 받은 OT 자료에서 보니 경쟁률이 무려 10:1이더군요. 그리고 함께한 21명의 멘티분들도 직장을 다니시는 분들이 대부분이었습니다. 그나마 대학교 4학년이신 두 분이 계셨고, 2학년은 저혼자.. 여기서도 제가 막내더군요. 처음 간 OT에서 학생인 저에게 혹시 이 분야에 더 관심이 있으면 편하게 연락하시라고 멘토 분의 명함을 받기도 하고, 멘토멘티분들끼리 서로 링크드인과 깃헙 계정도 공유하더군요.

저는 그 당시 링크드인이 외국에서 주로 쓰는 서비스인거 정도만 알고있어서, 급하게 회원가입하고 공유했던 기억이 나군요.

네이버, 쏘카, 무신사, SK 등 엄청난 분들의 링크드인과 깃헙 계정에 팔로우를 하면서 아... 나도 몇년 뒤에는 내 링크드인 커리어에 대기업 로고를 박아보자!라는 다짐을 했던 ㅋㅋ

그리고 이때는 대학교 친구들 몇명이서 주변 고등학교에 봉사캠프를 하러 가서 일주일에 한두번 코딩을 알려줬던 경험도 했었네요.

이러한 활동들을 할 수 있었던건, 다행히 일주일에 한두번만 출근하고 나머지는 재택근무였던 회사 덕분입니다~~

이때도 사실 기획도 하고 새로운 학교 리더 면접도 보고 아주그냥 난리가 아니였습니다....

그리고 기획을 구체화는 과정을 하면서 저는 항상 "최악의 경우"에 대한 가정에 집착을 했었습니다.

2기 팀매칭을 준비하면서 팀 인원이 부족한 경우가 너무 많아 이에 대해 너무나 골치가 아팠던 경험이 있어서.... 각 활동 들에서 어떤 문제가 발생할 수 있겠는가? 그리고 이 문제는 어떻게 해결할 수 있겠는가에 대해 많이 고민했습니다. 물론 모든 문제를 사전에 알 수는 없지만, 그럼에도 이렇게 준비해놓는 것과 하지 않는 것은 차이가 클 것이라고 생각했습니다.

그리고 월말에는 예전부터 출사를 같이 가던 친구가 있는 청주로 가서 사진도 찍고 다녔습니다. 이때 친구가 정말 잘 찍어준 사진이 있었는데, 필름으로 찍은거라 아마 폰 갤러리 대신 제 컴퓨터에 있겠네요

8월

UMC 기획 준비를 한지 한달이 다되갈 쯤, 총괄 포지션인 저는 새로운 한분을 영입하게 됩니다. 그리고 포지션을 운영국장, 사무국장으로 쪼개고 저는 운영국장을 맡게됩니다. (사실 국장 한명씩 밖에 없는 뭐..) 혼자 기획하다보니 어떤게 더 좋을 지 고민할 상황이 많았고, 이때마다 시간이 너무 낭비되었기에, 도움이 필요했습니다. 그리고 혼자 일하니 제 멘탈이 부서질거 같기도 하더군요. 그래서 2기 데모데이를 함께 준비하면서 정말 든든했었던 분에게 연락드렸고 흔쾌히 합류해주셨습니다.

8월 중순에는 본가 친구 한 명과 일본으로 떠났습니다. 노트북을 들고서 말이죠...... ~~(가서도 일한다..)~~

이때 코로나로 패키지여행만 갈 수 있어서 자유롭게 돌아다니지는 못했기도 하고, 밤에 숙소에 돌아와서 못해도 1~2시간씩은 일을 몰아서 했었고 등등...

꽤나 내용이 길어지네요. 원래는 일년치를 한 번에 작성할려했는데 나눠서 작성해야겠습니다.

하반기에는 UMC로 인해 멘탈이 박살난 경험이 꽤나 많기에... 내용이 더 길어지지 않을까 싶네요.