ENFJ.dev

2025년 회고

gngsn — Wed, 31 Dec 2025 12:55:59 +0900

1/ 운동

# 트레일런

# Full Marathon Sub-4

2 / 개발
# 사이드 프로젝트

  # 새로운 팀
  # 기술 발표
  # Open Source Contribution

3 / 일상
  # 첫 대출
  # 자취 시작
  # 첫 장기 운전
KPT 2026
  # Keep
  # Problem

# Try

보이는 성과를 의식하며 시작한 2025년에는
생각보다 많은 것들을 했다.

다양한 기술적 시도들을 했다.

기술 발표,
AI 사이드 프로젝트,
오픈소스 프로젝트,
영어 기술 모임,
4개의 사내외 기술 스터디,
기술 밋업 참석.

운동에도 정신이 나가있었다.

Marathon 10K - ⏱️ PB 00:50:09
Marathon Full - Sub-4 ⏱️ 03:57:24
장수 트레일런 - 38K-J 완주 ⏱️ 09:51:32
체지방률 19%이하 달성 - 6kg 감량

새로운 환경을 만들었다.

정말 쉽지 않았던 첫 대출 실행,
강남 내 자취 시작,
운전연수와 첫 장기 운전.

언어는 비중이 줄었지만 꾸준함을 가져가고 있다.

매일 아침 트레이드밀에서 보는 영어 Podcast 혹은 영어 교육 컨텐츠.
매주 진행하는 영어 프리토킹.
주기적으로 만나는 외국 친구들.
마구적어보는 영어 일기.
SNS의 70%이상을 채운 영어 인사이트.

일 년은 길고도 짧았다.

믿을 수 없는 성취의 기쁨을 느낀 적도,
한없이 부족한 스스로를 질책하기도 했다.
권태에 발버둥치기도 했고,
번아웃 직전까지 가기도 했다.

많은 것을 시도했고, 그만큼 많은 것을 경험하고 감각했다.
2025년 마무리로 다룰 내용들이 많아 욕심껏 써보고자 한다.

운동

트레일런

장수 트레일런 38-J

트레일런에 도전했다.
첫 풀마라톤 이후 조금 더 난이도 있는 도전을 해보고 싶었는데,
마침 장수 트레일런 신청기간이었다.

가파른 산 38.8km에 대한 감도 잡지 않은 채,
겁도 없이 장수로 향했다.
트레일런은 정말 여러 해 동안 기억에 남을, 가장 인상 깊은 경험이었다.

당일 새벽까지 내린 비에 젖은 흙은 발밑에서 무너졌고,
이끼 낀 바위는 손으로 짚어도 미끄러졌다.
경기 도중 계속해서 쥐가 났다.
정신적·육체적으로 많이 흔들렸고, DNF를 진지하게 세 번 고민했다.

DNF: Did Not Finish, 경기를 중단하는 것

네 번째 쥐가 올라올 때 주저앉아, 눈물이 날 만큼 고통을 겪었다.
육체적으로도 그렇지만 정신적 한계치에 다다른 순간이었다.

DNF를 다짐하고,
반대 방향으로 발을 돌리려는 찰나에
문득 이런 생각이 들었다.
어차피 못 끝낼 거면 될 때까지 천천히 가는 게 낫지 않을까?

Cut-Off Time으로 실격을 해도,
내 의지로 할 수 있는 만큼 끝까지 최선을 다하기로 했다.

Cut-Off Time: 제한 시간 내에 완주하지 못하면 경기에서 제외되는 시간

내 의지로 최선을 다 하는게 더 '나 다운 마무리'이겠다 싶었다.
내 의지로 끝내는 것이 용납이 안됐다.
나는 중간에 그만두는 걸 정말 못한다.

|

그렇게, 10시간을 달린,
긴 여정을 마무리했다.
Finish Line 바로 옆에 누워버린 상태로 한참을 있었다.

표현할 수 없는,
마음 깊은 곳에서부터 울려오는,
경험하지 못한 전율이 몸에 한참 맴돌았다.
공허함이 느껴지는 듯하더니, 순식간에, 뿌듯함이 압도적으로 밀려들었다.
실감이 와닿는 순간이었다.

세 번의 중도 포기 다짐을 했던 순간들이 스쳐갔다.
완주 기념 벨을 받으니 웃음이 새어 나왔다.
"이게 되네"를 연신 남발하며 신이 나서 여기저기 사진을 찍어댔다.
정말 말도 안 되는 기쁨이었다.

LAst NaME만 모두 대문자인게 너무 거슬린다

장수 트레일런을 통해 알게된 네 사람들이 있다.

한 분은 버스 옆자리 여자분이었는데, 나와 상황이 비슷했다.
셔틀, 비박, 홀로 경기, 트레일런이 뭔지도 모르고 일단 장수까지 온 그런 상황이다.

다른 한 분은 로드와 트레일런 모두 프로급이셨다.
이 두 분과는 서울에 와서 따로 저녁도 먹고,
나중에 출전할 경기도 같이 나가자는 얘기를 오가고 있다.

또, 두 분은 경기 중 쥐가 심하게 났을 때 약을 건네주시고 괜찮아질 때까지 함께 있어준 사람들이다.
러닝 크루로 참여하신 두 분이었는데, 한 분이 부상을 입어 무리할 수 없는 상황이었다.

이 분들은 20대 여자가 트레일 38-J 코스를 뛰러 혼자 장수까지 왔다고 해서 꽤나 큰 충격을 받으셨다.
혼자 운동하고 혼자 경기에 나가는 게 익숙해진 터라 의식하지 못했던 건데, 놀랄 수도 있는 일이구나 싶었다.

예기치 못하게 늦어진 완주에 집으로 가는 셔틀을 놓쳤는데,
마침 한 자리가 빈다고 서울까지 태워다 주셨고, 저녁과 커피까지 사주셨다.

따뜻한 인간의 정을 느꼈고, 건강한 스포츠 문화를 만드는 분들의 존재를 마주하니
세상의 이런 부분을 경험할 수 있음에 큰 감사함을 느꼈다.

그렇게 서울부터 왕복 9시간인 장수에서,
완주의 벨을 울리고 무사히 서울로 돌아왔다.

경기 이후, 크게 느꼈던 게 두 가지가 있었다.

첫 번째는 완주한 후의 기쁨을 나눌 사람의 소중함.
두 번째는 이젠 어떤 정신적·육체적으로 고단한 도전이 어렵게 느껴지지 않는다는 것.

너무나 험난하고 의지력을 최상까지 끌어올린 경험 이후의 힘듦은 아무것도 아니었다.
웃기다. 극기 훈련이 되어버린 것이다.
불가능해보이는 것들도 "38-J도 완주가 되더라" 라는 생각으로 쉬워보였다.

이렇게 체육인이 되어가는 걸까

짧은 쾌락 뒤엔 지속되는 고통이 오고,
짧은 고통 뒤엔 지속되는 행복이 온다.

Full Marathon Sub-4

풀마라톤을 Sub-4를 달성했다.
"Full Marathon을 도전하자"는 2025년 목표를
기대보다 훨씬 이상으로 달성한 것이다.

한파에 떨며 완주한 첫 풀 마라톤

응원을 즐기며 행복했던 두 번째 풀 마라톤

첫 번째 마라톤은 엉망진창이었다.
정말 말 그대로 "엉망진창".

올해 2월 한파주의보가 뜨던 날, 아는 것 하나 없이 '일단 해봐'라는 마음으로 나갔다.
추위와 살을 에는 바람이 4시간 반 내내 끊이지 않았다.
정말 고통스럽고 다신 하고 싶지 않은 경험이었다.

:: 두려움 없애기

풀마라톤을 말할 때면,

일년 전 - 첫 10K 마라톤 때가 몇 번이고 생각나는데

마치 살벌한 전쟁을 나가는 장군같은 포부로,
"다녀오겠습니다"를 외치던 마라톤 하루 전날이 매번 떠오른다.

두려움 떨며 중간에 포기해도 괜찮다고 스스로를 위안했던 때였다.

웃기게도 불과 일 년 전이었던,
10K에 벌벌 떨던 이 때를 아직 생생히 기억한다.
이젠, 풀코스가 아무렇지 않게 느껴진다.

두려움은 분명히 익숙함으로 무뎌지게 할 수 있다.
겁이 나거나 하기 싫은 일은 분명히 있다.
그때마다, 무섭고 하기 싫다는 생각을 없애고 "하는 사람"으로 최면을 걸곤 한다.

풀마라톤을 완주하는 사람.
매일 아침 운동하는 사람.
매번 새로운 시도를 하는 사람.

선택은 없다.

내가 되고 싶은 사람으로,
매번 스스로를 정의할 뿐이다.

|

두 번째 마라톤은 JTBC 마라톤이었다.
첫 풀마 전에 신청해 놓은 풀마라톤이 얼마 남지 않았다는 메일을 보고 아찔했다.
워낙 유명한 마라톤이지만,
첫 풀마가 너무 좋지 않은 기억으로 남아 기대 없이 출발했다.

그런데, 출발선의 공기가 달랐다.
날씨는 좋았고, 달리는 거리마다 응원하는 사람들로 끊이질 않았다.
응원은 제 몫을 톡톡히 했고, 힘들다는 생각이 지속되지 않게 했다.

완주를 목표로 달렸던 두 번째 풀마를 3시간 57분 안에 들어왔다.
끊임없이 "나 뭐지..왜지?"를 말하면서 실감이 안 났다.
이후 근육통도 없이 멀쩡해서 약간 무서울 정도였다.

이것도 트레일런의 영향일 것이다.

마음 따뜻해지는 경험도 했다.
어떤 할아버님이 내 배번의 이름을 보고, "경선씨, 포도 먹어요" 라고 하시며 청포도 하나를 건네 주셨다.
추운 날씨 때문에 겹겹히 입은 옷에 비해, 청포도를 건낸 손은 빨갛고 하얗게 튼 맨손이셨다.
다정하게 불러주시던 이름과,
처음 보는 이를 응원하는 그 따뜻한 마음에
그 여운은 한참 동안 가시지 않았다.

마라톤 내내 힘들었던 순간들이 분명 있었는데,
즐겁고 행복해서 그 순간이 거의 기억에 남지 않을 정도다.

현수막까지 만들어서 소리지르며 응원하던 여대생들의 모습도 재밌었고,
꽁꽁 싸매고 응원나온 애기들과 아내를 마주한 아빠의 모습도 보기 좋았다.

두 번째 풀마라톤은 Sub-4라는 성취감을 얻은 것도 좋지만,
거리응원이라는 새로운 경험이 더 큰 의미로 다가왔다.

출발은 혼자였지만, 뛰는 동안엔 늘 함께였다.

개발

하반기에는 영어와 운동보다는 개발에 더 많은 비중을 두었다.
성과가 보이지 않아 답답했던 마음을 풀고자 했던 것 같다.

많은 시도와 도전들을 해보았는데,
본인이 필요할 때조차 휴식을 취할 수 없는 환경이 되었다.
멈출 수 없는 상태가 되어버렸다.

10월 이후부터는 거의 번아웃이 올 뻔할 만큼 지쳐있던 것 같다.
무엇인가를 하고 싶고 해내고 싶은 마음이 들어도
시간, 에너지, 정신력의 균형을 잘 관리해야 함을 느꼈다.

:: 노력할 줄 아는 사람

보통 무엇인가를 시작하면 기준보다 더 많이 하고 오래 하려는 경향이 있다.
이 경향은 이기고 싶어서 만들어진 습관이 아니라,
비슷해지고 싶다는 생각이 만들어냈다.

수학 문제집을 5번씩 풀던 때가 있었다.
선생님이 문제집 반복보다 교과서 변형 문제를 풀어보는 게 좋다며,
학원에서 기출 문제를 주지 않느냐고 물었다.

학원을 다니지 않는다고 했다.
선생님은 아무 말하지 않으셨다.
그 의미를 이해하지 못했다.

어느날 친구가 대뜸 수학 학원에서 받은 본교 수학 예상 기출문제지를 건네줬다.
조금씩 함정을 넣은 변형 문제들이 대부분이었다.

시험날이었다.
예상 기출문제에 나온 문제들이 다수 나왔다.

수학 시험이 끝난 후,
엄청난 무기력함을 느꼈다.
문제집 백 번 풀어봤자,
학원에서 주는 본교 시험을 몇 년간 분석한 예상 기출문제를 이길 수 없던 것이다.

⎸

그때부터였다.
“더 오래, 더 많이 노력하는 사람”이 되기로 했다.
두 배 세 배 노력하면,
어느정도 비슷한 선에 도착할 수 있진 않을까.

이 생각은 머릿 속에 오래 머물면서 습관이 되어버렸다.

누군가에게 도움을 청하는 걸 못했다.
고등학생 때 위독해진 아빠의 병에,
혼자 잘 해내야 한다는 생각 뿐이었고,
도움을 부탁하는 건 당연히 민폐라는 생각이었다.

생활, 수능, 진학을 혼자 결정해야하는 나의 환경은
주변 친구들과 비교해보고 있자면
마치 레일이 보이지 않는 마라톤에서 길을 헤매며 종착지에 가야만 하는 꼴이었다.

당시 생각에는 원망스런 환경이었다.
하지만, 지금은 그런 환경이 있었기 때문에
이렇게 스스로 노력할 줄 아는 사람이 되었다고 생각한다.
어렸을 때 배울 수 있었음에 감사할 뿐이다.

⎸

극복할 수 있는 부족함을 그대로 두고 싶지 않다.
환경에 불평하고 싶지도 않다.
불평은 부정적인 기운으로 사기만 떨어뜨릴 뿐이다.

이젠 '좋아하는 일에 노력하는 나'라는 가치에 중점을 둔다.

새로운 팀

올해 5월, 새로운 팀에 합류했다.
어려운 도메인과 새로운 팀원들.

최근, 평가를 진행하고 팀장님과 One on One (개인 면담)을 진행했다.

"썬은 성격이 재산인 것 같아요."

본인이 들을 수 있는 말 중, 가장 값진 말이었다.
밝고 긍정적인 성격으로 쉽게 의사소통할 수 있게 하는 성격,
또 뭐든 배우려는 자세를 높은 가치로 봐주셨다.

가까이 일한 동료에게 받은 올해 평가는 아래와 같다.

"이 정도면 됐지"가 아니라, 스스로의 높은 기준을 향해 노력하려는 모습이 인상적이었다.

밝고 긍정적인 에너지로 팀 분위기를 항상 좋게 만들어 주셔서 감사했고,
저 또한 주변 동료에게 썬과 같은 동료인지 뒤돌아보게 됐다.

일하는 태도와 산출물의 완성도 모두 훌륭하나, 번아웃 예방을 위해 워크로드와 휴식의 균형을 꾸준히 챙겨주시길 바랍니다.

팀 이동으로 담당자를 변경한 서비스에 장애가 났을 때에도 자기 서비스처럼 적극적으로 대응해 주셔서 역시 썬이다라고 생각했다.

업무에 대한 적극적인 태도 덕분에 높은 신뢰와 안정감을 느꼈다.
부족한 요건에 대해 먼저 의견 주시고 챙겨주셔서 죄송하고 감사했다.

레거시 코드를 분석하며 문제점을 찾아 공유하고 개선하는 과정이 인상 깊었다.

이런 평가를 해주는 동료들이 있는 것이 본인이 가진 복인 것 같다.
공모주를 함께 개발한 시니어 개발자 분이 하시던 말을 기억하고 싶다.

"본인의 가치를 알아주는 곳에서 일해야 성장한다."

가치를 만들고 성장하는 환경을 만들어가보자.

-

도메인이나 기술로는 기존 팀원들보다 많이 부족하니,
새로 합류하는 사람으로써 낼 수 있는 긍정적인 영향이 무엇이 있을지 고민해보곤 했다.

도메인을 배우면서 프로젝트를 보고, 낯설어 보이거나 문제가 있을 법한 것들을 찾아보았다.
죄송할만큼 질문을 많이 했다.
호기심이 많은 탓에 스스로에게 "왜지" 라는 질문이 습관이 되어 버렸는데,
코드를 볼 때나 위키를 찾아보며 엄청난 "왜지" 들이 쏟아진 터였다.

반 년간 도메인을 배우고 팀 내 기술을 익혀갔고,
유저가 사용하는 서비스 레이어부터 시작해서 알림,
그리고 지금은 복잡한 코어 레이어를 작업하고 있다.

사용자가 직면하는 서비스부터, 내부 복잡한 도메인을 개발을 하며
점진적으로 투자 도메인 전문성을 기르는 중이다.

팀원 분들이 놀랄 만큼 성장하고 싶은데,
본인에겐 여전히 성에 차지 않는다.
더 빨리 많이 배워서 큰 도움이 되고 싶다.

이 밖에도 사내/사외 스터디를 운영했다.
- Kotlin in Action e2 스터디
- AWS Certified Advanced Networking Specialty Certification 강의듣고 정리
- 영어 발표 스터디 - 가상 면접 사례로 배우는 대규모 시스템 설계 기초
- Claude Code 파헤치기

기술 발표

이게 진짜 될까 ⎯
내가 하고 싶다고 할 수 있는 걸까 ⎯

2024년에 정한 2025년 목표 중 하나는 "기술 발표"였다.
발표 기회를 어떻게든 갖고 싶었지만, 나만 마음먹는다고 되는 일인가 싶었다.

25년의 하반기가 다다를 때까지 목표를 이루지 못했다.
"내년엔 이루지 뭐" 라는 위안이라는 가면을 쓰고,
내심 정말 안되는 건지 여기저기 찾아보고 다니기 바빴다.

기회는 가만히 기다리는 게 아니라, 엿보고 있을 때 찾아왔다.
아슬아슬하게, 하반기에 발표 기회를 얻었다.
그리고, 그동안 만들어온 오픈소스를 소개하는 주제로 발표를 준비했다.
발표 주제는 아래에서 언급할 OpenChat Playground 오픈소스 소개로 정했다.

회사 일, 사이드 프로젝트, 개인 일정 등
놀라울 만큼 모두 겹쳐버린 일정들로 거의 한 달을 발표 준비에 쏟았다.
발표를 준비하며 정말 많은 질문을 스스로에게 많이 던졌다.

어떻게 하면, 다수의 시간을 의미있게 채울 수 있을까?
어떻게 하면, 이 발표가 사람들에게 도움이 될까?
어떻게 하면, 사람들이 집중을 유지시킬 수 있을까?

장표와 데모 녹화를 만족할 때까지 다듬었다.
도식화를 하고, 비유를 사용해서 이해를 도우려 했다.
더 배울 수 있도록 참고 자료와 링크를 찾아 넣었다.

45분이라는 시간이 짧게 느껴질 만큼,
좋은 인사이트를 가져갔으면 좋겠다는 욕심이 컸다.
부끄럽지만 이벤트 중 내 발표를 가장 재밌게 들어주는 상상도 많이 했다.

그렇게 발표 자료를 다듬고, 피드백을 부탁하고, 리허설을 했다.
준비할 수록, 내 발표가 스스로의 만족에 다가갈수록 긴장감은 기대감으로 변했다.

발표 당일,
늘 타던 지하철이 아닌 버스를 타고
늘 가던 방향이 아닌 서울 중심부로 향했다.

발표는 순식간에 끝났다.
항상 그랬듯, 만족의 기준이 높은 나 자신을 만족시키지 못했다.
조금 더 유연하고 활기찬 발표였으면 재밌지 않았을까 하는 아쉬움이 남았다.

|

그런데 결과는 예상보다 훨씬 좋았다.
발표 후에 많은 분들이 다가와서 질문을 해주셨고, 좋은 후기들을 들을 수 있었다.

직접 찾아와 인사를 건네주시는 분들.
추가 질문을 하시는 분들.
프로젝트에 관심을 보이시는 분들.

발표 이후 찾아와 주신 분들께 되려 더 깊은 감사함을 느꼈다.

가능성을 의심하기보다,
이룰 방법에 집중하는 것이
목표를 달성하는 가장 빠른 길이었다.
"이게 진짜 될까" 보다는 "이걸 어떻게 해내지"라는 태도가 더 도움이 됐다.

:: 되는 방법 찾기

개발을 하면서,

직장 생활을 하면서,

인생에 투영할 수 있는 것들이 많이 배웠다.
되는 방법을 찾게 된 것도 그 중 하나이다.

사실 어떤 요구사항이든, 개발로 만들어 낼 수 있다고 믿는다.
개발만을 봤을 때는 가능하지만, 회사와 팀 내의 조건과 환경이 가능과 불가능을 좌지우지한다.

일상에서도 동일하게 되는 방법을 찾을 수 있고,
개발과 다른 점이 있다면,

조건과 환경을 내가 구성하고 만들어갈 수 있다는 점이다.

그렇게 2025년의 목표 한 칸을 채웠다.

사이드 프로젝트

사이드 프로젝트를 진행했다.

# StanByMe

해외 K-pop 팬을 위한 AI 챗봇 서비스 - K-pop 아이돌 페르소나를 가진 AI 캐릭터와 대화할 수 있는 앱/웹 서비스

K-pop 관련 지식을 벡터 데이터베이스에 저장하고,
사용자 질문과 유사한 컨텍스트를 검색하여 AI 응답 품질을 향상시키는 RAG 기반 음성 챗봇 서비스를 제작했다.

사용 기술:
- Language: TypeScript
- Runtime: Deno (Supabase Edge Functions)
- Database: PostgreSQL, pgvector + HNSW
- AI/ML: LangGraph, OpenAI Embeddings API
- Frontend: React, Capacitor

주요 기능:
- RAG 기반 지식 검색: pgvector + HNSW를 활용한 벡터 유사도 검색
- 실시간 음성 스트리밍: WebSocket 양방향 통신 기반 음성 지원
- LangGraph 워크플로우: 노드 기반 상태 관리로 AI 워크플로우 설계
- 하이브리드 앱 배포: Capacitor를 활용한 단일 코드베이스 iOS/Android 앱 개발

화자의 목소리를 인식해서 녹음을 시작하고 종료하는 타이밍을 잡는 게 어려웠다.
또, 응답 속도를 빠르게 하려고 몇 주간 WebSocket과 SSE를 시도했는데,
Supabase Edge Function은 충분히 강력했음에도 실시간 통신에는 한계가 분명했다.

서버를 마련하면 좋겠다고 생각했지만,
빠른 MVP 배포를 위해 ElevenLabs 라이브러리를 사용으로 대체했다.

React로 생성한 프로젝트를 모바일 앱으로 배포하고 싶어
Capacitor 라이브러리를 사용해보았는데,
생각보다 빌드가 어렵지 않게 되어서 놀랐다.
더 복잡하고 다양한 요구사항이 생기면 어떻게 될지 궁금하다.

# Trufu

: 내 감정을 안전하게 반복해서 털어놓을 수 있고, 나만의 맥락에서 위로와 해석을 제공하는 AI 친구

Trufu는 내 감정을 안전하게 털어놓을 수 있고,
나만의 맥락에서 위로와 해석을 제공하는 AI 감성 챗봇 서비스이다.

사용 기술
- Language: TypeScript
- Runtime: Deno (Supabase Edge Functions)
- Database: PostgreSQL, pgvector
- Backend: Supabase (Auth, RPC, Storage)
- AI/ML: OpenAI Chat Completion & Embeddings API

주요 기능:
- RAG 기반 지식 검색: e-book 콘텐츠 청킹 및 벡터 검색
- Short-term + Long-term Memory: 인간 두뇌 모방 장기 메모리 - 반복적 고민도 기억하며 들어주는 친구 경험 구현
- 대화 내용에 따라 메모리 타입을 Social, Events, Semantic 으로 구분
- Dynamic Prompting: 친밀도 기반 동적 프롬프트 결정: 공감/조언/팩폭 모드 동적 전환
- 하이브리드 검색: 사전 등록 e-book 우선 검색 → Vector fallback
- 워크플로우 성능 분석: 노드별 생성 데이터, 토큰 사용량, 검색 정확도 Tracing
- Node-based Workflow 설계
1. loadChatHistoryNode: 대화 히스토리 로드
  2. generateEmbeddingNode: OpenAI Embedding API 연동
  3. loadMemoryNode: 벡터 유사도 기반 메모리 검색
  4. retrieveKnowledgeNode: Q&A + 벡터 하이브리드 검색
  5. generatePromptNode: 친밀도 레벨 기반 동적 프롬프트 생성
  6. generateResponseNode: GPT-4o 기반 응답 생성
  7. saveChatHistoryNode / saveMemoryNode: 영구 저장

사용자의 인간관계를 기억못하거나, 문맥을 이해하지 못하는 문제가 있었다.
초반에는 "내 전남친이 승진했어" "전남친 이름은 철수야" "철수가 어떻게 됐다고?" 를 물어보면 승진했다는 사실조차 몰랐다.

히스토리와 메모리로 대화 내용을 저장해서 보완했는데,
문제는 언제까지의 대화를 불러오고,
언제까지의 대화까지 기억시킬지 애매했다.

혹은 인간의 감정 상 기대하는 내용을 못 말하는 문제가 여전히 발생했다.
- Test User: 이모가 한 달 전에 돌아가셨어.
- Trufu: 많이 슬프겠다. 내가 도와 줄 일은 없어?
- Test User:이모랑 같이 갔던 레스토랑 정말 좋았는데.
- Trufu: 와! 이모랑 레스토랑에 가서 너무 신났겠다. 어떤 음식을 먹었어?

이때 깨달았다.
문맥을 이해하는 것과,
사람의 감정을 이해하는 것은 전혀 다른 문제라는 걸.

많은 연구가 필요할 것 같다.

# Mindthos
AWS CloudFormation, ECS
AI: Spec Driven Development, Cline, Claude, Codex, Supabase, Nextjs

TODO

Open Source Contribution

6개월간 오픈소스 컨트리뷰팅 모임에 참여했다.
OpenChat Playground 오픈소스를 만드는 초기 단계부터 함께했다.

OpenChat Playground
매번 서로 다른 LLM Provider를 구현해야하는 번거로움을 줄이고자
다양한 LLM 모델을 일관된 방식으로 사용할 수 있게 해주는
MEAI 라이브러리를 기반으로
여러 LLM 모델 제공자를 미리 구현한 ASP.NET Core 기반 오픈소스 프로젝트

GitHub Issue, PR 작성, 코드 리뷰, 협업 등
오픈소스가 될 코드와 문서에 대해 엄격한 관리가 이루어졌다.

175개의 댓글이 달린 코드 리뷰는
결코 쉬운 경험은 아니었지만,
그만큼 코드가 ‘공공재’가 된다는 감각을 배울 수 있었다.

이 그룹에 속하게 되어 좋았던 건,
열정 있는, 다양한 사람들을 가까이에서 볼 수 있었다.
특히 리더님은 오랜 직장 생활에도 지치지 않고 여러 활동을 운영하고 참여하고,
기술 발표를 통해 여기저기 기술을 알리는 데 주저하지 않는 모습이 굉장히 인상적이었다.

⎸

종종 "나도 그땐 그렇게 열심히 살았다" 라는 말을 듣는데,
이 말을 들을 때면, 나도 언젠간 지금만큼의 열정과 에너지를 쏟지 못할 시기가 온다는 생각이 들었다.

그런데 놀랍게도, 최근 발표를 위해 찾아간 컨퍼런스에서
오랜 경력에도 불구하고 열정을 담고 계시는 분들을 볼 수 있었다.
꾸준한 열정과 자신의 업에 대한 진지함이 느꼈졌다.

"내가 가진 열정이 언제 꺼질까"라는 질문을 스스로에게 자주 던지곤 했는데,
이 분들을 보며 "오래도록 열정을 유지하는 방법"에 대해 생각하는 전환점이 되었다.

C# & Dotnet

이번 기회에 C#과 Dotnet을 배우게 됐다.
지식의 깊이는 굉장히 얕아 궁금증이 커졌지만, 경험해본 것으로 만족중이다.
Microsoft와 freeCodeCamp에서 운영하는 C# 자격증 취득이 그 시작이었다.

AI를 통한 바이브 코딩으로 ASP.NET Core 기반 앱들을 만들었다.
만드는 과정 자체를 정말 즐겼다.

일상

하반기에는 정말 많은 어려움을 겪었다.
핸드폰이 갑자기 꺼지고 영영 켜지지 않아 모든 추억이 날아갔고,
갑자기 대출이 막혀 일주일 내내 여러 은행을 뛰어다니고,
이후로는 대환 대출, 이삿짐, 서류 처리로
한 달이 어떻게 지나갔는지 기억조차 안난다.

이 회고를 적는 이 순간은 "그랬었지" 하는 심정이다.
시간이 지나면 어차피 흐려질 고통이다.

어차피 지나갈 거,
지금은 현재 행복할 수 있는 것들에 집중하고 싶다.

첫 대출

"대출"이라는 단어가 두려웠다.
없으면 없는대로 사는 거라며 빚을 지는 것을 타부시 여긴 가정에서 자라 반감이 컸다.
은행에서 일하면서 관점을 바꿔봐도 되겠다 싶었다.

책임지지 못할 일을 벌이진 않을 성격이라 생각했고,
그래서 대출을 받아보기로 다짐했다
회사에서 전세 대출 이자 지원을 해준다.
지금이 '적기'라는 생각을 했고, 바로 실행에 옮겼다.

세 달 동안,
일주일에 1~4곳씩 집을 보고 다녔다.
이동 중에 버스와 지하철에서 회의하고,
개발을 하느라 늘 정신이 없었다.

마지막 즈음엔, 완벽한 집이 아니라 '충분히 괜찮은 집'을 찾아야 함을 깨달았다.
가격과 위치, 집 상태가 모두 완벽하기란 불가능하다.

자취할 집을 결정했다.
잔금일을 잡았다.

그때는, 일이 이렇게 복잡해질 줄 몰랐다.

|

대출을 신청하러 갔다.
그런데, 대출이자 지원 대상의 상품 실행일이 잔금일 이후까지 막혔다.
신청하러 간 바로 직전 날 공표되어 알 길이 없었다.
곧 추석 연휴이기도 했고, 예상컨데 정부의 전세대출 규제의 변화 예정이어서 영향을 받았을 것이다.

계약일을 조정하려고 집주인과 협의했다.
현 세입자의 다음 전세 계약과 맞물려 불가능하다고 한다.

다른 은행의 이자 지원 전세대출을 알아봤다.
막혔다.

대출이자 지원 대상의 전세대출은 물건너 갔다.
다른 은행의 신용대출을 고려했다.

- 대출 실행이 풀렸을 때, 다른 은행의 전세자금으로 갈아타야한다.
- 금액이 큰 만큼 큰 부담과 번거로움을 감수해야 했다.
- 금리가 높았고, 신용점수의 하락도 걱정됐다.

하지만 이자 지원 대상이니, 일부 이자만 갈아타기 전까지 지불하면 된다.

그런데,
다른 문제를 발견했다.
전세 대출은 계약 후 잔금일 이전에만 신청할 수 있다는 사실을 알게 되었다.
즉, 대출이자 지원 대상의 신용대출도 불가능했다.

정리하면,
이자 지원 전세대출은 시점 문제로 불가능했고,
신용대출도 조건상 막혔다.
결국 다른 은행 전세대출 → 추후 대환이라는 선택지만 남았다.

계약일이 2주 남았다.
대출이자 지원을 포기하고, 주거래 은행을 찾았다.
너무 가까운 잔금일과 연휴가 가깝다며 거절당했다.

반차를 썼다.
회사 근처의 은행을 찾았다.
거래 실적이 전혀 없는 곳이다.
그만큼 간절했다.

신청에 성공했다.
시간이 어떻게 흐르는지 모르게 일주일을 보냈다.

실행일 당일, 은행에서 금리 우대 대상의 적금상품이 아니라 현재 적금 해지를 요청했다.
여러 요건이 걸려있었다고 했는데, 급박한 상황에 들은 상세한 이유가 기억에 없다.
헬스장에 있다가 급하게 집까지 달려갔다.

---

배운 점이다.

1. 잔금일은 반드시 한 달 이상 여유 있게 잡자.
   대출 심사와 실행까지 최소 2주 이상이 걸린다.

2. 전 세입자의 전세금 사정도 반드시 고려해야 한다.

3. 전세대출 서류는 온라인 발급이 가능하지만,
   여러 은행을 돌 예정이라면 한 번에 출력하는 편이 낫다.

4. 전세 보증보험은
   HUG, HF, SGI 중 본인에게 유리한 곳을 미리 알아두자.

5. 전세대출은 반드시
   계약 후, 잔금일 이전에 신청해야 한다.

대환 대출로 인해 중도상환수수료를 내야했고,
대출 이자 지원을 받지 못했고,
은행을 직접 방문해 신청해야하는 번거로움이 있었다.

자취 시작

그렇게 자취를 시작했다.

이후로는 이사 준비로 바빴다.
새 가구를 들이고, 서류 처리들도 마무리하고, 관리비나 자동이체 관리로 계좌/적금/예금/투자를 정리해두었다.

3개월이 지난 지금,
너무 힘들었던 이 시기에 얼마나 절박했고, 얼마나 간절했는지 돌아본다.
아직은 생생히 기억난다.

많은 문턱이 있던 만큼, 많이 경험하고 배웠다.
적어도, 지금은 자취 생활은 정말 즐겁게 하고 있으니 행복하다.

첫 장거리 운전

운전연수를 받았다.
오만 로드 트립에서 친구 혼자 운전하는데 미안함을 느끼고 다짐한 시작이었다.

한국에 오자마자 운전연수를 받았고,
다행히도 연수 선생님이 나는 공간 감각이 있어서 운전을 금방 잘할 거라고 말씀해주셨다.

자신감을 얻고 이번엔 첫 렌트와 홀로 운전에 도전했다.
운전을 무사히 마쳤지만, 너무 긴장해서 기운이 아주 없었다.
솔직한 심경은, 운전을 영영 미루고 싶었다.
왜 이런 긴장과 두려움을 굳이 느끼면서 해야하지, 마음 속에서 계속 되뇌였다.

연말에, 엄마가 남해에 사는 삼촌에게 가고싶다고 했다.
그렇게 가족여행을 계획하는데 남해에 가는 교통편이 말도 안되게 긴 여정이었다.
난 렌트를 제안했고, 가족들이 운전할 날 믿어주었다.

여행 전까지 렌트한 차에 대한 정보와 영상을 찾아 보며
시도때도 없이 상상 연습을 했다.

운전초보 엄청 티 내는 유튜브 히스토리

부끄럽지만...
유튜브를 거의 안보다가 유튜브 앱을 깔아서 볼 정도였다.

여행은 정말 성공적이었다.
엄마가 그렇게 행복해하는 모습을 보니 정말, 더할 나위 없었다.
찾아온 네 모녀에 삼촌은 진심으로 기뻐하셨다.
연말에 찾아온 따뜻함이었다.

차가 없었으면 정말 어려웠을 여행이었다.
운전 연수를 받은 것과, 미리 렌트를 시도해봐서 다행이었다.

KPT 2026

보이는 성과를 만들고자 했던 다짐이
혼자 하는 헬스에서 마라톤 기록을,
오픈소스 기여와 기술 발표를 하게 이끌었다.

목표를 정의해두는 건, 생각보다 그 의미가 크다.
내가 의식하지 않을 때 방향을 인도하고,
나는 무의식적으로 그 길을 선택하고 향한다.

그래서 연말이 다가오면 어느정도 만족할 만한 성취를 해둔 것 같다.
만족의 기준점이 높아 잘했다고는 못하겠지만
어느 과정이나 최선을 다했던 스스로의 가치를 인정해주고 싶다.

스스로에게 떳떳할만큼 노력할 나 자신을 믿고
포기하지 않을 스스로를 응원한다.

Keep

운동을 꾸준히 하자.
신체 건강을 위해 시작했던 운동이
이젠 정신적인 건강까지 함께 길러주고 있다.

나에게 운동은
단순히 ‘운동을 한다’는 행위가 아니라,
‘꾸준함을 실행하는 사람’이라는 정체성을 유지하는 수단이었다.

그럼에도 불구하고 ‘매일’ 운동을 한다는 건 쉽지 않다.

그래서 더더욱,
매일의 운동은
스스로에게 꾸준함을 증명할 수 있는 가장 선명한 방법이 아닐까 싶다.

성과를 잘 보이게 하자

성과를 보이게 하려고 의식하자,
그 자체가 스스로에게 주는 보상처럼 느껴졌다.

‘나는 분명히 해냈다’는 사실을
눈으로 확인할 수 있다는 것만으로도
생각보다 큰 만족과 동기부여가 됐다.

앞으로도
내가 걸어온 과정을 가시화하고,
성과를 기록하며 스스로에게 보상을 주는 방식을 계속 가져가고 싶다.

AI 시장 흐름
AI 시장은 놓치지 말아야 한다.

그저 읽고, 써보고, 활용하는 데서 그치지 않고
시장을 읽지 않으면 안 되는 환경에 나 자신을 계속 두고 싶다.

의식하지 않으면 금방 뒤처지는 영역이기 때문에,
의도적으로 관심을 강제하는 구조를 만들어야겠다고 느꼈다.

밋업 참석
밋업은 기대 이상의 것을 가져다줬다.

다양한 인사이트,
다양한 사람들,
그리고 그 안에서 생겨나는 다채로운 아이디어와 에너지.

혼자였다면 떠올리지 못했을 생각들을
사람들 사이에서 자연스럽게 얻게 되는 경험은
앞으로도 계속 가져가고 싶은 자극이다.

Problem

수면과 휴식
2025년 후반부에는
번아웃 직전까지 갔던 순간이 분명히 있었다.

개발, 회사 업무,
대출과 이사,
영어 수업, 기술 발표, 사이드 프로젝트 일정이
짧은 기간에 한꺼번에 몰렸고,

‘할 수 있겠지’라는 생각으로
스스로를 계속 몰아붙였다.

쉬고 싶다는 신호가 와도
이미 쉬지 못하는 상태가 되어버린 뒤였다.

점심시간에 몰래 개인 공부를 하다
작은 소파에 걸터앉아 노트북을 붙잡은 채 잠들어버렸고,
산책하는 팀원들에게 들킨 부끄러웠던 순간도 있었다.

앞으로는
최소 6시간,
가능하다면 6시간 30분에서 7시간을 목표로
의도적으로 지켜보려고 한다.

영어 일기
예전엔 버스로 출퇴근 할 때, 앉아서 영어 일기를 쓰곤 했다.
하루를 정리하는 짧은 문장이어도 좋고,
감정이 엉킨 날에 막 적기 좋았다.

자취를 시작한 이후엔 영어 일기를 멈췄다.
다시 부담 없이 이어가고 싶다.
생각을 영어로 남기는 습관을 두고 싶다.

처음엔 영어 일기는 ‘공부’라기보다,
언어를 대하는 태도에 유지하는 장치에 가까웠다.
그런데 쓰다보니 내 생각을 막 적는 걸 즐기게 되었고,
막 적을 때 내가 의식하지 못했던 내 감정들도 적게 되었다.

그 시간이 기다려졌다.
그 시간이 그립다.다시 시작해보자.

Try

영어 기술 발표

2025년의 기술 발표를 이뤘다.

"그 다음은 뭐지?"

라는 질문을 던졌을 때 바로 생각난 건 영어 기술 발표였다.

다른 도전처럼 떨리고 무섭고,

"이렇게 두려운데 이걸 꼭 해야하나" 라는 생각이 든다.

하지만, 늘 그랬듯 -

해봐야 알게 될 것이다.

좋은 기억이 되든 나쁜 기억이 되든,

경험해볼 수 있을 때 도전해보고 싶다.

단 몇 개월의 긴장과 준비를 통해 나머지 인생에 있어서의 통찰을 얻을 수 있다면,

도전과 시도라는 건 어릴 수록 해두면 좋으니까.

바디 프로필

헬스장을 옮겼는데, 일하는 트레이너 쌤이 종종 운동을 봐주신다.친해진 쌤이랑 같이 얘기하다가 인바디를 보여드렸는데,"이 정도면 바프도 금방 하겠는데요" 라는 말씀을 하셨다.

바디 프로필에 반감을 갖고 있었는데,부담스럽지 않은 선에서 해볼까? 라는 생각이 들었다.지속된 "할까?" 라는 물음은 "하자"라는 결심이 되었고,26년 2월에 바디 프로필을 계획하고자 한다.

사실 부담스럽지 않은 시작이라고 했지만,막상 시작하면 제대로 준비할 스스로를 알기 때문에 몸이 망가질까 겁이 나기도 한다.

근데, 일단 해보고 몸이 망가질 것 같다면 그 때 생각해보려고 한다.이젠, 일단 해봐가 몸에 밴 것 같다.

:: 부담없는 시작

일상 러닝이나 마라톤의 시작은 "과하지 않게, 만족할 만큼" 이었다.
"5km만 달려야지"는 10km가 되고,
"10km만 달려야지"는 25km가 되곤 했다.

의지가 강하고 욕심이 있는 탓에 항상 그 이상을 하는 스스로를 깨달았다.

이 성격을 이용해보려고 한다.

새로운 시도를 하는데 시작이 어렵다면,

꾸준함을 가져가고 싶은데 어렵다면,

스스로에게 가볍게 시작해도 된다고 디독여주려한다.

매일 2km만 달리다보면 금방 3~4km가 되고,

3~4km는 5km를 해볼만하게 만드는 것 처럼.

Marathon

마라톤 목표는 아래와 같다.

- 10KM PB - 40분 초중반

- 해외 Full Marathon 도전

AI 관련 아티클 작성
블로그에 작성할 좋은 컨텐츠이다.
AI 시장의 흐름도 읽고,
영어로 글도 작성하고,
글을 꾸준히 쓰는 습관이 되기에도 좋은 명분이다.

2025년 상반기 회고

gngsn — Mon, 30 Jun 2025 23:46:44 +0900

2025년 상반기 돌아보기

1/ 일상

# 풀마라톤

2/ 개발

# 새로운 팀

# 커뮤니티

3/ 여행

# 프랑스 친구와의 로드트립

# 운전연수

2025년 하반기 목표

# 언어

# 건강

# 금융

# 개발

2025년 상반기 돌아보기

2025년엔 잘하고 있나 —

"잘하고 있다"라는 말을 감히 못 하겠지만,

적어도 "행복하게 살고 있다" 라고 말하겠다.

최근에 무엇인가 막연함이 주는 불확실성이 있었다.

왜 막연하지, 라는 생각을 하다가

최근에 겪은 다양한 실패들을 떠올리기도 했지만,
결국 결론 지은 내용은 충족이 주는 권태로 인해 스스로 만든 긴장감과 벌과 같은 것이었다.

그래서 충분히 느끼기로 했다.
가진 것들과 누리고 있는 순간들을.

길을 잃었다고 생각했다.

어디로 나아가고 있는지 보이지 않았다.

내가 가는 방향이 맞는지 의심스러웠다.

답답한 마음에 읽을 만한 책을 찾아보곤 했고,

책이라는 물음을 던질 수 있는 곳이 있어 다행이었다.

그러고 나면 마음이 어느 정도 다듬어진다.

엄밀히 말하면 책에게 던지는 질문을 본인에게 던짐으로써 얻은 안정감일지도 모른다.

프레임이라는 책을 읽다가 헤르만 헤세 인용구에 멈칫했다.

행복은 '무엇'이 아니라 '어떻게'의 문제다.
행복은 대상이 아니라 재능이다.
- 헤르만 헤세

어쩌면 행복은 성향이지 않을까 싶다.

행복은 물질로써 얻어지지 않는다. 그 무엇을 성취하던, 그 무엇을 얻던 행복을 결정하는 건 본인의 마음이다.

내 생각과 마음이 나를 행복으로 이끌지 불행으로 이끌지를 좌지우지 한다.

1/ 운동

# 풀마라톤

25년 목표 중 하나인 풀 마라톤을 참가했다.

대회 당일이 다가오기까지 아무런 느낌을 받지 못했다.

어쩌면 생각할수록 생겨날 걱정을 무의식이 방어하고 있다는 생각도 들었다.

당일이 되었다.

예기치 않게 날씨가 너무 추웠다. 옷을 얇게 입고 간 것은 큰 실수였다.

뛰면서 더울 것 같았지만, 땀이 나면 찬 바람을 맞아 체감온도는 더 낮아졌다.

손이 얼어 물컵조차 잡을 의지가 안 났다.

미숙함에 에너지젤을 두 개만 챙긴 것도 실수였다.

손이 얼어 에너지젤 하나를 까다가 그만 떨어뜨렸다.

20km를 넘겼을 땐, 너무 춥고 힘들었지만, 드디어 반이나 왔다고 좋아했다.

30km가 다가왔을 땐, 지치고 바람이 너무 매서워 몇 번 소리를 질렀다. 부끄러움도 감수하게 되는 고통이었다.

35km쯤 다가올 때쯤, 한 조각 베어 문 바나나가 너무 맛있어서 순간의 엄청난 행복을 느꼈다.

남은 6km는, 1km 마다 그 거리가 아득하게 느껴졌다.

실수 투성이고 미숙함 투성이었다.

그래도, 결승점에 도착했다.

4시간 31분 만에 멈춰 섰다.

관성이 멈춘 발을 어색하게 만들었다.

뛰면서 들은 오디오북도 기막힌 타이밍에 끝이 났다.

얼굴을 쓸어내다, 모래인지 소금인지 정체 모를 가루들이 잔뜩 낀 걸 발견하곤 헛웃음이 나왔다.

얼어버린 몸을 녹일만한 곳을 찾다가 그냥 집에 가기로 했다.

풀 마라톤을 끝낸 후엔, 생각만큼의 감흥이 느껴지지 않았다.

며칠간의 근육통이 전부였고 힘들었던 순간은 금방 잊혔다.

며칠 뒤에야 나에게 물었다. 무얼 느꼈는지.

이상하게도, 허무함이었다.

이 의외의 감정이 다시 한 번 나를 깨웠다.

내가 원하는 건 목표를 달성하는 게 아니라 목표를 세우는 거라고.

달성이 목적이 아닌 원동력이 될 수 있는 목표가 필요했을 뿐이다.

맞다, 그랬었지.

목표를 설정하고 목표를 이뤄서 오는 기쁨보다 그 과정이, 그 여정을 위한 목표다.

이루지 못할 목표만큼 허무맹랑하진 않으면서도,

어느 정도 의구심이 들만큼의 목표이면서도,

그 과정을 충분히 즐길 수 있는 목표.

어렵게 성취한 목표를 즐길만한 성취감을 만끽할 감정이 점차 무뎌지면 다음을 생각한다.

풀 마라톤이 이런 목표로 적합했는데 너무 허무하게 끝나버린 것이다.

다음엔 어떤 목표를 가져볼까.

어떤 목표가 나에게 적절한 설렘과 긴장을 줄 수 있을까.

작년 이맘때쯤, 10km 마라톤에 참가하는 걸 겁먹던 본인을 떠올린다.

매일 아침 7km-8km 를 뛰고 회사를 가는 지금 생각하면 웃긴 일이다.

아니, 일 년 전 본인이 생각하기에 아침에 7-8km를 뛰고 출근하는 본인을 생각조차 못했겠지.

1년 뒤에 내가 어떻게 변해있을지 모른다.

그 미래를 만드는 건 스스로이고,

못해낸다는 프레임을 만들면 그것 또한 내가 만든 생각일 뿐이다.

높은 장벽을 넘을 수 있으려면 조금씩 높게 뛰는 노력이 있어야 한다.

노력은 오래 걸릴 수 있지만, 시작도 안 한다면 기회조차 생기지 않는다.

한 번 그 높은 장벽을 넘고 나면 장벽은 낮아 보인다.

그리고 더 높은 장벽을 넘을 마음을 갖게 된다.

본인을 프레임에 가두지 마라.

겁을 먹어도, 두려움과 도전을 분리해서 생각하자.

두려움은 인간으로서 당연히 느낄 수 있는 자연스러운 감정일 뿐이다.

두려움을 느낀다고 내가 그만큼 못한다고 정의 내리면,

그때부터 진전은 없다.

2/ 개발

# 새로운 팀

몇 주 동안 개발자로서 많은 내적 고심이 있었다.

그중 하나는, 회사에서의 답답함이었다.

많은 걸 해보고 싶고 경험하고 싶은데 일이 제한적이었다.

적어도, 여유보다 바쁜 일상을 선호한다는 걸 깨달았다.

바쁜 하루로 시간이 소용돌이처럼 휘몰아치는 경험이 너무 그리웠다.

내가 할 수 있을 만한 걸 찾아다녔다.

스터디를 하나 더 만들고, 뱅커톤도 나가봤다.

그러다, 인생의 선배이자 개발자 선배인 시니어 팀원분들께 도움을 구했다.

본인이 느낀 권태에 대해 털어놓고, 여기저기 길게 혹은 짧게 대화를 나눴고, 공감과 조언을 받았다.

내 인생의 선택은 항상 내 몫인데 어떻게 할지, 어디로 갈지 고르는 건 항상 어렵다.

결국, 조언 중 하나였던, 옆 팀으로 이동하기로 결정했다.

같은 팀이었다가 올해 초 분리된터라, 사실 구성원 자체로는 큰 변화를 못느꼈다.

도메인은 어렵지만 업무량도 꽤 많고 기술적으로 배울 점 많다는 점 때문에 옮길 결심이 섰다.

그렇게 팀을 옮긴 지 한 달이 되었다.

지금은 도메인을 배우는 재미를 느끼고 있고,

팀원분들에게 배울 점도 너무 너무 많아서 좋다.

서툴고 싶지 않은데 이미 서툴고 있는 것 같다.

빠르게 적응해서 뭔가를 해내고 싶다는 마음만 앞선다.

미숙한 도메인 지식과 ... 귀여운 코딩 능력을 ... 가졌지만,

마음만큼은 큰 업적 하나를 세우고 싶다는 용기로 가득하다.

재밌고, 설렌다.

정신없고 나름 긴장도 하고 있는데, 주변 사람들이 표정이 더 밝아졌다는 말도 해주신다.

팀원 분들께 도움을 요청한 게 정말 잘한 일인 것 같다.

본인을 진심으로 생각해 주고 조언을 해주는 사람들이 있다는 게 참 감사하다.

# 커뮤니티

커뮤니티에 들어가 활발히 소통하자는 목표를 세웠었다.

다양한 외부 인사이트를 지속적으로 듣고자 함이었다.

그렇게 4개월 간 외부 스터디에 참가했고,

결과적으로 큰 인상을 받진 못했다.

진행 방식이 서툴러서 그런지 체계가 없는 게 본인에게는 와닿지 않았다.

본인의 문제일 수도 있다. 큰 기대를 하지도 않았고 엄청 몰입했다고 느끼지 않는다.

한국인들 사이에서 진행되다 보니, 영어나 기술 면에서 배운 점이 본인의 흥미를 이끌어내지 못했다고 본다.

스터디에서 다루는 내용이나 멤버들은 충분히 흥미로웠다.

오직 영어를 이용한 스터디는 굉장히 좋았다.

영어를 사용한 '기술' 설명이나 '내가 해온 성과' 설명하기 연습을 꾸준히 하고자 한다.

겸손한 태도로 배울 점들을 계속 살펴보고 가져가봐야 할 것 같다.

스터디가 끝난 뒤에는 사이드 프로젝트를 시작했다.

아직 합류한 지 얼마 안 돼서 언급할 내용은 없지만, 굉장히 재밌을 것 같다.

다만, 시간을 더 많이 써야 하는 일인 만큼 일정과 우선순위를 잘 챙겨야겠다.

3/ 인생

# 로드트립

매 순간이 감사할 만큼, 잊고 싶지 않은 여행을 했다.

아름다운 경험이었다.

혼자 여행에 점점 지루함을 느꼈던 찰나에,

마침 친구가 여행지에서 만나 같이 여행하자는 좋은 제안이었다.

두바이와 오만을 가게 되었는데,

그 친구가 이집트계 프랑스인이라, 이슬람 문화에 대해 깊이가 상당한 친구였다.

두바이에 살았었던 그 친구는 두바이와 오만을 같이 여행하자고 했고,

고심 끝에 두바이와 오만을 모두 가보기로 했다.

오만은 유명한 여행지는 아니라 미지로의 여행이라는 긴장감을 느끼곤 했다.

오만 여행은 많은 생각을 하게 했다.

아랍어를 할 수 있는 무슬림 친구와 여행.

힌두의 교리를 따른 친절한 사람들.

운전에 익숙한 친구와 함께한 로드 트립.

마음 깊숙한 곳까지 느낄 수 있던 아름다운 건물들.

믿을 수 없을 만큼 감동적인 풍경들.

친구가 소개 시켜준 한 번도 시도해보지 못한 많은 이슬람 문화권 음식과,

친구 어머님이 마침 두바이에 여행 중이셔서 공항 픽업도 해주셨다.

모든 것들이 마음 깊숙한 곳에서부터 감사하게 느껴졌다.

이런 감정을 느낄 수 있다는 것마저 감사할 만큼.

아름다움을 느끼고 여유를 즐긴다는 순간이 소중했다.

# 운전연수

새로운 목표를 세웠다.
바로 운전이다.

계기는 친구와 같이 로드 트립 여행 중, 여행 내내 친구만 운전을 하는 게 너무 미안했다.
오만에서 그 친구가 운전을 알려줬다.
면허를 취득 후의 첫 운전연수가 오만이라니, 꽤나 특별했다.

운전을 미리 배워야겠다는 마음이 드는 순간 부담이 생겼다.
내가 할 수 있을까라는 막연함이었다.

시간이 지나는 만큼 걱정은 커지면 커지지 작아지지 않는다.
그래서 연수를 바로 신청했다.

연수가 끝나고 이제 실전이었다.
역시나 무섭고 또 한 번의 막연함이 느껴졌다.
걱정이 시작되려고 하니, 일단 해보자라는 다짐을 했다.
차를 렌트해서 가까운 곳이라도 운전해 보았다.
걱정과는 다르게 문제가 생기지도 않았고 첫 시작을 내디뎠다는 안도감을 가졌다.

2025년 하반기 목표

# 언어

매일 아침 버스에서 간단한 영어 일기를 작성하고 있다.

어디서나 글을 많이 쓰라는 말을 한다.
왜 일까?
글을 쓰는 게 좋은 건 알겠지만, '매일' 쓰면 좋은 이유는 모르겠다.
한 번 반기동안 매일 글 쓰는 챌린지를 해볼까.

책을 읽다가 남긴 메모가 시발점이었다.

하반기까지 영어 일기를 꾸준히 작성해 보자.

아직까지 장점이나 변화를 느낀 건 없지만, 시간이 쌓인 후에 보면 또 다를 테니, 지켜볼 예정이다.

# 건강

꾸준하자.

아침 운동은 신체를 위한 루틴이 아니라 정신을 위한 루틴이다.

능동적으로 아침을 여는 시작은 곧, 내가 이끌어갈 하루가 되게 한다.

하반기에는 다양한 스포츠에도 도전하면 좋겠다.

하고 싶은 게 있다면 시도해 보고 내가 좋아하는지 알아가 보자.

# 수면

적어도 6시간, 최소한 4시간의 수면시간을 확보하자.

1시간 정도 수면 시간이 늘었다가 3개월이 지나지 않아 다시 줄어들고 있다.

충분한 수면의 장점을 좀 더 되새겨야겠다.

퇴근하고 공부하다 집에 도착하는 시간을 9시를 목표로 했는데,

점점 늦어지더니 다시 11시 쯤 도착하게 되었다.

1시 ~ 2시에 자고 5시반 ~ 6시 반 사이에 기상을 하니 수면 시간을 다시 놓쳐버린 것이다.

반드시 11시 쯤엔 취침하고, 6시에 기상하는 루틴을 만들어 봐야겠다.

# 금융

직장인이 되고 난 후부터 돈 관리를 엄격하게 해서 그런지,

또래에 비해 많은 돈을 저축했다.

문제라고 하면 초기에 잡아놓은 소비 습관이 너무 엄격해서 돈을 쓰는 씀씀이를 키우기가 어렵다는 점이다.

저축은 지금처럼 꾸준히 하자.

다만, 본인을 위한 투자는 더 과감해져도 되겠다.

# 개발

전문성 키우기 — 내가 쓰고 있는 기술을 깊이 파자.

그리고 이를 다루는 아티클을 영문으로 작성하자.

적어도 한 달에 두 편, 12편을 목표로 한다.

# 기술 발표

기회를 엿보아야 기회가 생긴다.

기술 발표라는 기회가 왔을 때, 혹은 보일 때 잡을 수 있도록 미리 준비해 두자.

이 번해 최소 한 번의 기술 발표를 목표로 한다.

프레임

gngsn — Thu, 27 Feb 2025 23:58:00 +0900

프레임, 최인철

Date: 2025.02.12 ~ 2025.02.24

Rate: ★ 4.2

Pages: 308

Comment: 이 책의 마지막 문장을 맞이했을 때의 그 기분이 참 묘했다 ⎯ "모든 출구는 어딘가로 들어가는 입구다". 프레임과 관련된 모든 내용들 끝에 이 문장을 만났고, 이 지혜로운 한 문장이 책에 여운을 남게 했다.

프레임은 많은 사람들에게 추천받은 책이다. 심리학 책이라고 해서 관심은 있었는데, '베스트셀러' 타이틀에 질려있던 본인이라서 한동안 읽기를 꺼려졌었다. 하지만 눈에 밟힌 이 책을 읽어볼 마음이 생겼고, 감사하게도 본인의 취향에 맞는 심리학 책을 발견했다.

읽으면서 저자의 따듯함을 느낄 수 있었는데, 문장 표현력 때문인지, 마치 친밀하고 저명한 지인이 옆에서 들려주는 이야기처럼 편하게 읽었으며 더 나은 나를 위해, 정말 나라는 개인을 위해서 쓰인 말을 들려주는 것만 같았다. 덧붙이자면, 종종 문장이 본인의 이야기로 나열된 형식이라 제 3자 입장의 멀리 떨어진 청객처럼 느껴지는 방식과는 달랐다는 의미다.

글은 각 장 마다의 목적과 주제가 분명히 드러난다. 그래서 쉽게 읽힌다. 또, 다양한 뒷받침 사례와 연구 결과들이 공감을 할 수도 신뢰를 느낄 수도 있는 요소들로 재미를 느낄 수 있다.

우리 모두는 프레임을 갖고 있다.

우리가 세상을 바라보는 방식으로 우리는 생각하고 여긴다.

우리는 세상을 있는 그대로 객관적으로 보고 있다고 생각하지만,
사실은 프레임을 통해서 채색되고 왜곡된 세상을 경험하고 있는 것이다.

프레임으로 인한 이러한 마음의 한계에 직면할 때 경험하게 되는 절대 겸손,
나는 이 것이 지혜의 출발점이라고 생각한다.

이 책에서의 잔반적인 내용은, 우리가 인지하지 못했던 프레임에 대해 짚어주고 일깨워주는 것이다. 흥미로웠던 점은 다양한 연구 결과를 제시하고 이야기 하듯 서술하며 어떤 프레임이 우리, 인간 안에 숨아있었는지 짚는다.

최상의 프레임으로 자신의 삶을 재무장하겠다는 용기, 나는 이것이 지혜의 목적지 라고 생각한다.

이 책을 읽는 목적이라고 한다면, 혹은 추천하는 목적이라고 한다면, 인지하지 못했던 프레임을 일깨워 내고, 어떤 프레임을 취할지 우리의 삶 속에서 고르고 개선하는 방향으로 말할 것 같다.

작가는 다양한 예시를 들며 프레임이 ‘단어 싸움’ 이라고 했는데,

우리가 어떤 문장과 어휘를 받아들이는지에 따라 우리의 생각과 느끼는 감정이 바뀐다는 내용이다. 이처럼 프레임은 변한다. 우리가 어떤 것을 인지하는지, 어떻게 보이는 지에 따라 세상을 다르게 볼 것이며 나를 바꾼다.

내가 얼마나 행복한지를 판단하기 직전에 던진 질문이 내 인생을 평가하는 주된 프레임이 된다

행복한가라는 질문 직전에 던진 질문이 무엇인가?

평소에 생각하던 질문들, 관심사들이 그 주를 이룰 것이다.

자기 삶에 대한 평가가 시시하다면 내가 시시한 질문을 던지고 있기 때문인지도 모른다. 답이 안 나오는 인생을 살고 있다면, 질문에 문제가 있을 가능성이 있다. 무언가 더 나은 답을 찾고 싶은 사람은 세상을 향해 던지고 있는 질문부터 점검해야 한다.

우리는 평소에 어떤 질문을 스스로에게 던지는가?

본인이 생각하는 인생이 어떤지, 본인에게 던지는 질문들에 투영해서 확인해보라. 우리가 평소에 느끼는 감정으로 우리는 스스로에게 질문을 던진다.

“행복은 '무엇'이 아니라 '어떻게'의 문제다.
행복은 대상이 아니라 재능이다." (헤르만 헤세)

행복은 물질로써 얻어지지 않는다.

어쩌면 행복은 성향이지 않을까 싶다.

그 무엇을 성취하던, 그 무엇을 얻던 행복을 결정하는 건 본인의 마음이다.

내 생각과 마음이 나를 행복으로 이끌지 불행으로 이끌지를 좌지우지 한다.

보통 우리는 목적을 달성하면 행복할 것이라 믿는다.

최근에 봤던 내용 중 인상 깊은 건,

지속적인 행복이란 목표를 달성한 사실이 아니라,

목표를 달성해가는 길이라고 한다.

성취하는 사람의 프레임은 '접근' 프레임이다.
반면에 안주하는 사람의 프레임은 '회피' 프레임이다.
접근 프레임은 보상에 주목하기 때문에 어떤 일의 결과로 얻게 될 보상의 크기에 집중하고 그것에 열광한다.
그러나 회피 프레임은 실패 가능성에 주목한다.
자칫 잘못하다간 실수할 수 있다는 데 주목하고, 보상의 크기보다는 처벌의 크기에 더 큰 영향을 받는다.

접근 프레임과 회피 프레임을 구분 지어 정의한 것이 인상적이었다.

성취를 원하는 사람은 보상에, 안주하는 사람은 실패 가능성에 집중하는 성향이라는 의미로 해석된다.

새롭게 해석되는 내용에 재미를 느끼며 읽은 구절이다.

“지혜는 한계를 인정하는 것이다.” 이것이 바로 내가 내린 지혜에 대한 정의다.
나는 지혜란 자신이 아는 것과 알지 못하는 것, 할 수 있는 것과 할 수 없는 것 사이의 경계를 인식하는 데에서 출발한다고 믿는다.

본인이 생각하는 겸손은 손사레치며 본인을 치켜세워주는 말에 부정하는 것이 아니라,

본인의 실패에 순응할 줄 아는 것이라고 생각한다.

실패를 하지 않는다는 것은 사실, 새로운 것들을 회피할 때 유지되는 것 아닐까.

무지를 인정하고, 부족함을 인정하고 받아들이며 말할 줄 아는 것이 진정한 겸손이라고 생각한다.

‘타인에게는 나 자신이 상황이다’라는 인식을 갖는 것. 다른 사람의 행동이 그 사람의 내면이 아니라 바로 ‘나’라는 상황 때문에 기인한다는 깨달음. 그것이 지혜와 인격의 핵심이다.

본인이 상황이 된다는 것에 대한 인지.

그 인지를 깨워주는 부분이었다.

작가는 이에 대한 많은 예시, 본인이 몸소 깨달았던 예시를 들어주며 이를 설명한다.

본인이 인지하는 상황에서의 프레임에 벗어나 주변 사람들에 비춰지는 상황으로써의 나를 프레임하게 만든다.

수학자나 인지심리학자들은 이와 같이 분명한 답이 존재하는 문제를 '잘 구조화된 문제' 혹은 '잘 정의된 문제'라고 부른다.
반면 지혜를 필요로 하는 문제는 '잘 구조화되지 않은 문제' 혹은 '잘 정의되지 않은 문제'다.

지혜가 어려운 이유는 잘 구조화되지 않았기 때문이다.

정의가 명확히 되어 있는 문제는 답을 내기도 쉽지만,

정의가 명확하지 않으면 답을 내기도 명확하지 않다.

마지막 섹션에서는 "지혜로운 사람의 11가지 프레임"을 소개한다.

이 내용들은 두고두고 옆에 두며 생각해볼만 하다.

1. 의미 중심의 프레임을 가져라

"당장 내일 어떻게 살 것인가?”를 물어야 한다.

10년 후에 어떤 삶을 살고 싶은 지를 연구하는 사람이 아닌, 당장 내일에 대해 생각해보는 사람이다.

미래의 본인이 상상하는 삶은 이상적이다.

현재에 집중하라.

일상적인 행위 하나하나를 마치 그것을 먼 미래에 하게 될 일이라고 생각하면서,
의미 중심으로 프레임하는 습관을 길러야 한다.

2. 접근 프레임을 견지하라

이 부분은 인상 깊었던 접근 프레임과 회피 프레임을 떠올리게 했다.

자기 방어에 집착하지 말고 자기 밖의 세상을 향해 접근하라.

하고 싶었지만 주저했던 일이 있다면 이제라도 과감하게 실행해야 한다.

저자는 정주영 회장의 "해보기나 했어?" 라는 아주 적절하고 명료한 예시를 들어주었다.

3. ‘지금 여기’ 프레임을 가져라

내일, 혹은 나중에 할 일로 생각하며 사는 내일에 오늘은 없다.

하루 하루 행복을 미루지 않았으면 한다.

행복으로 가는 길은 지금 순간을 충분히 즐기고 감사하는 것으로부터 비롯된다.

4. 비교 프레임을 버려라

언제부터인가 잦은 일상의 불편함을 느꼈던 것이 사라졌다.

더 이상 남들과 비교하지 않고, 과거의 나와 비교하기 시작할 때였다.

그 누구도 나와 비교할 수 없다.

과거의 자신보다 현재의 자신이 얼마나 나아지고 있는지, 자신이 꿈꾸고 있는 미래의 모습에 얼마나 근접해 있는지를 확인하는 시간상의 비교가, 남들과 비교하는 것보다 훨씬 더 생산적이라는 결론이다.

언제부터인가 잦은 일상의 불편함을 느꼈던 것이 사라졌다.

더 이상 남들과 비교하지 않고, 과거의 나와 비교하기 시작할 때였다.

그 누구도 나와 비교할 수 없다.

우리 각자는 비교할 수 있는 대상이 아니다.

우리의 삶은 그 자체로 다 다른데 비교한다는 것은 무의미한 일이다.

5. 긍정의 언어로 말하라

긍정의 언어에 대한 새로운 생각을 갖게 해준 부분이다.

다 먹고살자고 하는 거 아니겠어?” 또는 “좋은 게 좋은 거 아니겠어?”라는 표현이나 ‘대충, 아무거나’ 등의 단어들은 하루라도 빨리 사전에서 지워버려야 한다. 이런 말들은 우리의 마음가짐을 ‘최고(Best)’의 프레임에서 순식간에 ‘충분한(Good enough)’의 프레임으로 바꿔버린다.

최고에서 충분한으로 기준이 바뀐다는 개념이 흥미로웠다.

'좋은 것에서 위대한 것으로'가 아닌, '위대한 것에서 좋은 것'으로 바뀌고 있는진 않은지 본인의 말투를 주의해볼 필요가 있다.

긍정의 언어는 긍정의 프레임을 갖게 한다.

6. 닮고 싶은 사람을 찾아라

정말 흥미로운 예시를 읽었다.

한 작가가 본인이 쓴 소설 속 주인공과 닮아가는 에시였다.

작가는 자신이 꿈꾸는 이상적이 자기 모습을 소설 속 주인공으로 녹여냈고,

의도적으로 그 주인공처럼 행동하려 했다.

신기하게도, 그 작가가 서서히 달라지는 것을 느낀 것이다.

본받고 싶은 대상을 스스로 만들어 간 것이다.

누군가 본받고 싶은 대상이 있다면 그 사람의 전기나 자서전을 읽고 그 사람처럼 되기 위해 의도적으로 노력하고 반복적으로 행동하고 실천하는 것이 필요하다. 만일 그런 대상이 없다면 뮐러처럼 자신이 가장 되고 싶은 이상적인 자기를 만들어보고 그 사람의 이야기를 계속해서 자신에게 들려줘라.

본받고 싶은 사람이 있다면, 혹은 기억할만한 이야기가 있다면 기억해두자.

7. 주변의 물건들을 바꿔라

주변 물건들을 적절히 선택해 배치하는 것은 지혜로운 마인드라고 소개한다.

8. 소유보다는 경험의 프레임을 가져라

너무나도 공감하는 말이다.

소유 보다는 경험에 대한 가치가 더 마음 속 깊이, 그 가치가 오랫도록 자리잡곤 한다.

작가는 행복은 소유 자체를 위한 소비보다는 경험을 위한 소비를 했을 때 더 크게 다가온다고 한다.

재미있는 팁도 전해주어서, 이를 인용해본다.

누군가를 위해 돈을 지불하는 것을 단순한 인사치레나 의례적인 선물로 프레임하기보다는, 자기 자신을 위한 행복 비타민이라고 프레임하는 발상의 전환이 필요하다.

9. ‘누구와’의 프레임을 가져라

우리는 아주 소중한 사람을 옆에 두지만, 그 가치를 잊곤 한다.

삶에 있어서 감사하도록 인연을 이어가는 그 사람들에 가치를 계속해서 상기 시키자.

우리 삶에서 정말 중요한 건 '어디서'의 문제가 아니라 '누구와'의 문제다.

10. 위대한 반복 프레임을 연마하라

습관이 만드는 결과는 대단한다.

아주 사소한 것이라도 반복적으로, 주기적으로 하다보면 그 결과는 기대를 훨씬 웃돌곤 한다.

말콤 글래드 웰(Malcom Gladwell)을 비롯한 여러 심리학자의 연구에 따르면,
성인기의 성인기의 성취라는 것은 그것이 어떤 영역이든 '중단 없는 노력'에 의해 이루어진다고 한다.

반복의 결과는 결코 과소평가 될 수 없다.

11. 인생의 부사(副詞)를 최소화하라

The road to hell is paved with adverbs.
- 스티븐킹

수식어는 불안함에 의해 많이 사용된다.

생명력이 넘치는 문장은 단순하고 명료한 문장이다.

작가는 우리의 삶에 매달아 둔 액세서리들을 줄여야 한다고 말한다.

우리의 인생은 꾸밈없이 생명력 넘치게 살아갈 때 생기의 빛을 발한다.

작가의 프레임으로 인생을 바라보면 삶의 매 순간이 문장이다.
문장이 살아 있어야 삶에 생명력이 있다. 글과 삶에서 중요한 것은 주어이지, 부사가 아니다.

고전이 답했다, 마땅히 살아야 할 삶에 대하여.

gngsn — Fri, 14 Feb 2025 08:31:51 +0900

고전이 답했다, 마땅히 살아야 할 삶에 대하여, 고명환

Date: 2025.01.11 ~ 2025.01.18

Rate: ★ 4.6

Pages: 252쪽

Comment: 책을 통해 세상을 보고 있다면, 혹은 배우고자 한다면, 거절할 수 없는 책이다. 다양한 고전을 소개하며 어떤 성찰을 할 수 있는지 기회를 준다. 작가는 고전에서 찾을 수 있는 가치있는 문장들을 인용하고, 본인의 삶에 투영하여 이야기한다. 그 고전이 어떤 의미를 내포하고 있는지 이해하는데 큰 도움을 준다.

'고전'이 주는 의미를 진정한 가치의 인용구들을 사용해 전한다. 숨어있는 고전 속 의미를 전달한다. 덕분에, 흐릿해진 그 고전의 가치를 다시 한 번 살려주었다. 삶의 어려움, 삶의 의미, 삶의 목표, 어렵고 난해한 질문들을 어떻게 풀어갈지 방향을 제시해준다.

특히, 고전을 미리 읽어본 사람에게 추천한다.

고전을 읽으면서 고전이 주는 통찰을 느끼지 못했다면, 이를 해소할 것이다.

고전을 읽으면서 고전이 주는 통찰에 감명을 받았다면, 공감하며 읽을 것이다.

책에 관심이 많으면서 '고전'은 아직 낯선 이들에게는 고전에 관심을 갖게 하는 책이 될 것이다.

문장들이 쉽고 간결하게 구성되어 편하게 읽을 수 있었다.

작가는 쇼팬하우어가 제시한 직관과 개념을 소개한다.

2 x 2는 4가 아니다.

스스로 생각하는 것이 '직관'이고, 누군가의 완성된 생각이 '개념'이다.
그래서 '직관'이 '개념' 앞에 있어야 한다고.

두 개념에 대한 이해를 돕는 사전적 의미를 보면 아래와 같다.

직관: 감관의 작용으로 직접 외계의 사물에 관한 구체적인 지식을 얻음.
개념: 여러 관념 속에서 공통된 요소를 뽑아내어 종합하여서 얻은 하나의 보편적인 관념.

최근에 회고를 하나 작성했었다.

본인은 이를 내 생각을 가지고 살아야 한다고 했는데,

쇼팬하우어가 직관과 개념이라는 두 명확한 개념으로 설명했다.

모호했던 개념들이 선명해졌다.

공감과 위안을 느꼈다.

재밌던 사실은 ‘2 x 2 !‎ = 4’ 을 설명할 때였다.

여전히 의문으로 남은 이 말을 이젠 어느정도 이해하고 받아드릴 수

있게 되었다. 이는 개념이다. 개념과 직관을 구분할 줄 아는지 시험같은 말이었다. 천상 이과인 본인은 큰 의문을 가졌던 지난 시간과는 다른 해소감을 느꼈다.

우리는 남에게 끌려 다니지 않고, 자신만의 생각을 가지며 살아야 한다.

우리는 개념 속에서 나와, 직관을 가지고 살아야 한다.

우리는 만연한 생각이 내 것인 것처럼 살지 말아야 하고, 나 자신으로써 살아야 한다.

스스로를 충분히 믿을 때까지 삶의 기준은 무엇인지, 세상을 직접 관찰하고 판단하고 용기내어야 한다.

인스타, 페이스북, 쉴 새없는 채팅 속에서 당신은 당신의 온전한 생각을 가지고 있는가?

"가장 오래 산 사 람은 가장 나이 들어 죽은 사람이 아니라 인생을 잘 느끼다 죽은 사람이다"
- 장 자크 루소의 『에밀」

하루를 살아도 자 기 직관으로 인생을 느끼며 살다가 죽은 사람이 가장 오래 산 사람이다.

—-

'무지(IX)의 지(체)'.

돈키호테는 책을 읽고 깨달았다.
녹슬어 사라 지지 않고 닳아서 사라지는 게 훨씬 아름다운 삶 이라는 사실을.

노력은 결코 쉽지 않다.

목표를 이뤄가는 과정도 결코 즐겁지 만은 않다.

그럼에도 그 가치를 느끼고 살아있음을 느낀다.

누구나 본인만의 이야기가 있다.

본인이 죽기 직전에 바라본 본인의 이야기 책이 어떨지 상상해보라.

이곳 저곳을 떠돌았던 여행책이 될수도 있고,

모든 게 불평 불만이었던 암울한 책이 될 수도 있고,

넷플릭스 후기를 잔뜩 써놓은 남의 이야기로 가득한 책일 수도 있다.

본인은 끝내 감동으로 가득한 두꺼운 책이 되고 싶다.

많이 헤지고 많은 어려움과 고통을 이겨낸 이야기로 다른 사람이 배워 이겨나갈 수 있는 밑거름이 될 수 있는 그런 책이 되고 싶다.

많은 사람에게 도움이 되는, 빛이 나는 책이다.

돈키호테는 알았다.
결과는 중요하지 않다는 것을.
하루를 살아도 내가 믿고 내가 깨닫고 내가 결정한 삶을 살아야 함을.
그 신념 앞에서 죽음도 두렵지 않음을.

인생의 의미를 찾는 것의 가치와 이를 이뤄가는 진정한 삶의 중요성을 수 천 번 강조해도 부족할 것이다. 본인이 정하는 삶, 본인이 정하는 방향, 본인이 향하는 가치는 우리의 삶을 포만감으로 가득 채운다.

조지 오웰의 1984릉 보고 한동안 인간의 본성에 대해 생각하곤 했다. 이기적인, 본인의 생명이 우선인가? 이해할 수 없었다. 그럼 독립 운동가들은 어떻게 그 끔찍한 고문을 이겨내었고, 본인의 목숨을 거두었는가?

답을 찾았다. 그들은 본인의 삶을 이미 결정했다. 그들의 신념은 그들의 삶의 의미를 단단히 만들었고, 그들이 결정한 삶을 영광스럽게 지키고 간 것이다.

마치 죽음의 수용소에서 빅터 프랭클이 제시했던 로고스처럼 말이다.

진짜 선과 악은 무엇인지, 진실은 그 자체로 선한 것인지, 거짓은 늘 악한 것인지

2 곱하기 2는 4인가?

아니다. 요점은 그게 아니다.

직관과 개념을 분리 시켜라.

직관은 다른 말을 전하고 있을 지도 모르는데,

우리는 개념 만을 따르고 있다.

자신이 무엇을 모르는지를 아는 것이 매우 중요하다.
- 『원칙」 257쪽

인상 깊었던 내용 중에 안정에 대한 개념을 다시 생각해보게 된 문장이 있다.

인간은 안정을 원한다.
그런데 진정한 안정 은 어떤 상태인가?
가만히 있는 것인가?
인간은 계속 변화하는 동물이다.

변화는 움직임이다.
자전거가 계속 움직여 앞으로 나아 갈 때 안정적인 것처럼 인간 역시 계속 움직여야 안정적이다.
한자리에 머물러 안주하면 녹슬어버리는 게 인간이다.
고로 인간 에게 진정한 안정은 움직임이다.

가만히 머물러 있으면 퇴회하는 시대가 맞다. 이 내용이 고전에서도 담겨있다는 게 놀라울 뿐이었다.

어쩌면 이 시대가 아니라, 뗄 수 없는 진실이 아니었을까.

인간은 움직여야 안정적이다.

결심이라는 구실로 양심의 가책을 줄일 수는 있겠지만, 효과는 없습니다.
(중략)
결심은 때때로 현재의 도전을 피해 전혀 구속력이 없는 미래로 도망치는 것과 다르지 않습니다.…

- 「머물지 말고 흘러라, 92쪽

우리는 결심이라는 구실로 양심의 가책을 줄이는 오류를 범한다.
결심만 하는 계획은 무계획이다.
직접 실행을 해야한다.
움직여야 한다.

이어 동일한 맥락으로, 연금술사에서 주인공 산티아고의 말을 인용했다.

'결정이란 단지 시작일 뿐'
- 연금술사

“내 언어의 한계가 내 세계의 한계다"라는 비트겐슈타인

이 세계의 언어를 모르면 이 세계의 소리를 들을 수 없다.

임계점이란 그런 것이다.
두려움을 주고 서두르게 만들고 불가능할 것처럼 느끼게 한다.
그 순간을 참고 묵묵히 꾸준히 반복 하면 임계점을 반드시 돌파할 수 있다.

어느 분야든 임계점을 뚫을 수 있는 최고의 비결은 '꾸준함'이다.
꾸준함은 믿음에서 나온다.
이렇게 계속하면 반드시 성과가 나올 거라 믿어야 한다.

끝임 없는 도전을 습관처럼 만들면, 임계점의 위치가 점점 올라가기 시작한다.
할 수 없을 것만 같은 일들이 마법처럼 다시 살아나기 시작한다.
책의 저자는 이 임계점을 넘는 방법을 '꾸준함'으로 언급했다.

2024년 회고

gngsn — Tue, 31 Dec 2024 20:39:00 +0900

2024년 돌아보기

1/ 일상

# 마라톤

2/ 개발

# 스터디

# CKA 자격증

3/ 경험

# 여행

⎸

KPT 2025

Keep

- 가까운 만큼 더 잘하자.

- 성과를 더 잘 보이게 하자.

- 경제 관념을 키우자.

- 여행하고, 관찰하자.

Problem

- 독서.

- 꾸준한 연락.

Try

- Full Marathon.

- 커뮤니티.

- 기술 발표.

2024년 돌아보기

시간에 쫓기는 삶을 원치 않아

시간을 만들어가는 삶을 만들어 가려 노력중이다.

그렇게, 하루하루의 노력이 당연하게 느껴질만큼 꾸준하게 걷고 뛰고를 반복하고 있다.

더 고요한 삶을 위해, 더 단단한 마음을 갖기 위해,

끊임없이 배움을 얻으려 노력 중이다.

:: 행복은 자유에서 오며, 자유는 지식에서 온다.

행복은 목적지가 아니다.
행복은 방향이다.

"I believe discipline is freedom'."
- American tennis player, Venus Williams

규율은 자유를 실현한다.

루틴은 가치 있는 하루를 만들 자유를 실현한다.

성실한 노력은 목표를 달성할 자유를 실현한다.

친절을 우선으로 삼는 규칙은 더 나은 나를 만들 자유를 실현한다.

이끌리는 삶이 아닌 만들어가는 삶,
이끌리는 하루가 아니라 만들어가는 하루 속에서
우리는 비로소 진정한 의식 속에서 숨 쉴 수 있다.

무엇을 이루어감에 있어 규율은 성취할 수 있는 자유를 준다.

자유를 가졌음에도 주관이 없다면

그 자유는 결국 남에게 이용당하기 쉬운 상태가 된다.

행복은 자유에서 오며, 자유는 지식에서 온다.

1/ 일상

# 마라톤

아침 6시, 혼자 헬스장에 가서 운동하는 아침을 즐긴다.
더 자고 싶은 날도, 가기 싫은 날도, 몸이 지친 날도,
10분이라도 하자는 마음으로 헬스장에 간다.

일단 움직인다.

'갈까 말까' 고민할 선택을 없애도록,

스스로를 '매일 운동 가는 사람'으로 정의내려버린 것이 큰 도움이 되었다.

어쩌면, 운동이라는 목적이 아니라 나와의 약속을 지키고 싶은 것이었다.

그런데 작년부터, 노력을 하고 있지만 무언가의 공허함을 느꼈다.
그 어떤 노력도 당연하게만 느껴지는 시기였다.

나 자신에게 보여줄 성과물이 필요함을 느꼈다.

그러다 10KM 마라톤을 발견하게 되었고, 적절한 기회라는 것을 느꼈다.
기록과 추억이 남고, 정확한 수치로 기억될 수 있는 정확한 성과물이었다.

10KM이 너무나도 아득해 보였다.

그래도,

일단 신청했다.

달리기를 오래 쉬어서 그런지 처음에는 반감이 너무 컸다.

그래도,

일단 시작했다.

막상 시작하고 나니 역시나 더 멀리, 더 잘 뛰고 싶어졌다.

그래서,

일단 연습했다.

그렇게 10KM 마라톤을 완주했다.
당일 비가 와서 비를 온몸으로 맞으며 결승점까지 달렸다.

바로 20KM 마라톤에 도전했다.
역대급 폭염으로, 한창 폭염주의보가 울리던 8월 15일, 광복절을 기념하는 마라톤이었다.
실제로 눈 앞에서 쓰러지는 사람도 볼 만큼 더운 날씨였다.
그렇게 20KM 마라톤도 완주했다.

다음엔 10KM 트레일러닝에 참여했다.
내리막길에 공포를 느끼는 탓에 오르막길에 온 힘을 다했다.
첫 10KM 트레일러닝에 1시간 20분 기록을 냈고, 전체 여자 31위를 차지했다.

10KM 마라톤이 가볍게 느껴질 때쯤 자신감이 생겨났다.
덕분에, 카카오뱅크에서 열린 "SaveRace"의 마라톤 구급대원인 패트롤로 참여하는 기회를 얻을 수 있었다.

스스로의 노력이 눈에 보여질 때,
그간의 노력마저 가치있게 느껴졌다.

꾸준했던 러닝 훈련이 가치있었고,
꾸준했던 근력 운동이 엄청난 성과로 보여졌다.

한 단계, 한 단계,
너무나도 벅차고 말도 안된다고 느껴졌던 도전들이
지금은 그냥 하면 되는 것이 되었다.

다음 단계에 도착해있을 때
상상도 못했던 도전이 닿을 수 있을 것처럼 느껴졌고, 반복됐다.

도전이 무섭지 않다.

지금은 불가능할 것 같은 도전도,

이뤄낸 다음엔 할만한 도전이었다고 말할 본인을 믿는다.

:: 진정한 목표의 가치

노력해도 안되는 게 있다.

타고난 재능 앞에서, 본인의 능력이 한없이 작아보이는 순간을 본다.

무기력하고 싶지 않았다.

불가능 앞에 좌절하기보다는, 만들어갈 수 있는 것을 바라보고자 했다.

목표가 높아 이루지 못한다면, 가장 가까운 곳,

마치 닿을 수 있을 것만 같은 순간까지 노력할 수 있지 않을까?

노력은 끝임 없이 계속될 수도 있다.

어떤 날은 아득하도록 멀게만 느껴지는 노력에 지쳤다.

오랜 기간이 걸릴지도 모르는 그 시간을 모두

힘겨움과 좌절 속에서만 보내야 할까.

아니다.

'나를 위해, 목표를 위해 내가 무엇을 노력하고 있는지'를 인지하고

그 과정에서 행복을 느끼는 것이었다.

목표의 결과가 인생의 목적이 되고,

결과 만을 좇고, 비교하고,

목표 만이 기준점이 되어 스스로를 낮추기만 한다면,

인생의 진정한 의미를 놓치는 것 아닐까?

정말 원하는 것이 그게 맞는지를 물어보는 것이다.

성취와 성과는 결국, 한 인생 내에서 본인 의미를 찾는 과정같다.

인류를 구할 대단한 업적을 얻는 게 아니라면,

세기의 꿈을 꾸는 게 아니라면,

감히 소중한 내 인생을 우울 속으로 몰고 갈 이유는 없지 않을까.

목표로 향하는 과정의 배움과 즐거움을 깨달은 이후에,

비로소 진정한 목표의 가치를 찾을 수 있다.

# 성과 가시화 하기

2024 상반기 회고에서 다음과 같은 목표를 세웠다.

# 성과 가시화 하기

정량적인 측정이 안되니 공허함을 느끼곤 했다.
스스로가 깨달을 수 있는 결과물들을 만들어보자.
본인이 걸어온 성과를 가시화해서 성취의 보상을 주는 것이 좋을 것 같다.

멈춰있는 것이 아닌가 의심이 들지 않도록,

'보이는 성과'를 내려고 노력했다.

⎯ 기록

스터디 모임을 만들어 매주 진행되는 스터디를 '기록'했고,

혼자 하는 헬스보다는 '마라톤'을 시도했다.

⎯ 개발

메인 개발자로 기여한 서비스의 이용자가 100만명을 돌파했고,

사내 프로젝트 포상을 받았다.

⎯ 경제

대부분의 또래가 이루고 싶어할 단위의 돈을 빠르게 이뤘고,

꾸준히 경제 지식을 배워가고 있다.

⎯ 경험

겁없이 여행하며 특이하고 특별한 경험을 쌓고,

시드니/미국 내 회사 CEO/CTO에게 특별한 제의를 받기도 했다.

⎯ 건강

작년보다 수면 시간을 1시간 더 확보했고,

틈틈히 사색할 시간을 확보했다.

2/ 개발

# 스터디

스터디를 만들어서 진행중이다.

처음엔 쿠버네티스를 알고 싶어 그 분야에 경험이 있는 분과 함께 진행하고 싶어 만든 스터디였는데,

성향이 비슷한 사람들이 모여 높은 참여율을 보이는 스터디를 만들어 가고 있다.

매주 랜덤 발표를 통해 참여율을 높이고,
어느정도 욕심껏 분량을 가져가되 지속 가능하도록,
쿠버네티스, 네트워크, SRE 등 주제를 다루고 있다.

https://github.com/gngsn/deepdive/blob/main/kubernetes/udemy/README.md#certified-kubernetes-administrator-cka-with-practice-tests

정말 이해할 수 있을까라는 의구심이 들 정도로 막막했던 개념들이 머리속에서 그려지고,
가상화된 객체들이 머리속에서 분리되고, 조합되고, 상호 연결되는 상상을 하며 큰 재미를 그렸다.

많은 분량이 버거웠고,
아득하도록 느껴지는 시간이 필요하다는
많은 시간이 필요하다는 사실이 아득했는데
어느샌가 머릿속에서 선명해지는 그림들이 본인을 응원했다.

# CKA 자격증

12월 22일, CKA 자격증을 취득했다.

그 많던 개념들을 다 이해할 수 있을까 의심이,
어느덧 반쯤 이해해가는 순간,
너무 어렵게만 느껴졌던 내용들이 더 이상 아득하지 않게 느껴지는 것이 신기했다.

일 년이나 걸릴지도 모른다고 생각했던 아득함이

실제로 다가와 결과물로 보여졌다.

공식 문서, 책, 강의를 모두 시도해보았고,
나에게 가장 맞는 방법을 찾아낼 수 있었다.

처음 모든 내용을 훑을 때엔 너무 깊이 들어가진 않을까 걱정했던 부분들을

자격증 공부를 하면서 하나 하나 파헤칠 시간을 가질 수 있었다.

호기심 많은 성격에 깊이 파헤쳐 가는 게 더 재미있게 느껴졌다.

사실 자격증이 최종 목표는 아니었다.

그저 쿠버네티스를 공부하고 싶은데, 공부할 명분이 필요했다.

공식 자격증 커리큘럼에는 알아야할 중요한 내용을 짚고 있겠지라는 시작이 결국 자격증 취득까지 닿게했다.

:: 助言

"이 자격증을 굳이 왜?"
"도움 안돼"
"어리니까 좀 놀아"
"너무 공부만 하지말고 돈도 좀 쓰고 더 놀아"

달리고 있는데 갑자기 멈추라고 하는 것만 같았다.

멈춰야 할 것 같았다.

분명히 본인을 위해서 하는 말인데, 무엇인가 씁쓸한 기분을 들게 했다.

고민됐다.

어떤 일을 해야 내가 원하는 방향으로 갈 수 있을까.

고민의 시간이 깊어 질수록, 점점 확신하게 됐다.

조언을 해주는 분들의 이야기를 새겨 듣되, 조언을 취할지 말지는 스스로의 결정이라고.

아는 내용이라는 자만심이 들어도, 끝까지 듣고 방향을 결정함에 있어 항상 열어두겠다고.

깨우침을 주는 말을 잘 구별할 수 있도록 노력하고 있다.

모두가 가는 길은 편안한 길이 되겠지만,

아직 편한 길을 가기엔,

많은 이야기를 만들어갈, 그 시작점에 서 있다.

평범한 길보다는 조금은 특별한 길로,

남다른 결과를 욕심내고 싶다.

올해는 유난히 '말'로 인해 많은 스트레스를 받은 해이기도 하다.

그러다 보니 '말'이라는 가치에 대해 더 많은 생각을 해온 것 같다.

'말'이란 이루 말할 수 없이 중요하지만, 중요성을 간과하기 쉽다.

또, 한없이 옮겨다니기 쉬워서 꾸준히 주의해야 하는 인생의 중요한 요소 중 하나인 것 같다.

부정적인 언어들은 주변을 금방 물들이고,

긍정적인 언어들은 사람 자체를 빛나보이게 한다.

말은 서로 다른 화자와 청자의 상호작용이라

어떤 말이 어떻게 전달될지 알아가는 것도 어렵다.

화자의 의도와 다르게 전달되는 말은 누구의 책임일까.

어쩌면 대화에서의 '배려'는

서로 다른 두 사람이 받아들이는 의미의 간극을 줄이는 노력 같다.

3/ 경험

# 여행

혼자 밴쿠버, 토론토, 그리고 뉴욕을 여행했다.

무모하도록 겁없이 여행했고,
마치 그 곳에 사는 것 처럼 행동하고 상상하며 직접 보고 느끼고 배웠다.

15시간 비행 거리, 3주간의 혼자만의 여정,
주변에서는 큰 걱정을 했다.

위험할 수도 있고, 예상치 못한 문제가 생길지도 모른다고 했다.

수많은 사람을 만나며 그들의 삶의 이야기를 들었다.

많은 개발자를 만나며 궁금했던 과정들에 대해 직접 물어봤다.

다가오는 사람들을 거절하지 않자, 따듯한 추억들이 쌓였다.

핀란드 영사관의 홈파티에 초청되어, 뉴욕 시티 한 가운데에서 근사한 파티를 즐겼다.

친해진 사람이 알고보니 하버드 생이었는데, 프라이빗 소셜 클럽인 Harvard Club of New York City 을 투어시켜주었다.

센트럴 파크 한 가운데에서 한 사진 작가와 2시간 동안 독립 영화를 이야기하며 친한 친구 사이가 되었다.

위험할 수 있는 것도 맞고 어떤 문제가 생길지도 모른다.

하지만 생각해보면, 걱정은 일상에서도 끝이 없다.

갑작스러운 화재, 교통 사고, 혹은 강도
가만히 있어도 걱정 거리는 끊임없다.

가만히 있는 위험과
어떤 행동을 취해서 다가오는 위험이
다르면 얼마나 다를까.

다르더라도, 무섭다고 숨고 피하는 삶을 원치 않는다.

내가 정말 좋아하는 것은 무엇일까.
내가 정말 원하는 생활은 무엇일까.

삶을 여행하며 나를 알아가는 과정 속에 내가 있다.

:: 두려움

우리는 종종 위험을 과대평가하고,
기회를 과소평가하는 경향이 있다.

위험은 생각만큼 크지 않을 수 있고,
기회는 예상보다 훨씬 클 수 있다.

독일 속담에 "두려움은 늑대를 더 커보이게 한다"는 말이 있다.

Fear makes the wolf bigger than he is.

두려움을 방치하면, 실제 늑대의 크기나 위험성에 상관없이

평생 늑대라는 두려움 속에서 살게 된다.

우리가 두려워 하는 건,

'어떤 대상'이 아니라 '모르는 무엇인가', 즉 불확실성이다.

두려움을 이겨내면 그 두려움은 별것 아닌 존재로 전락한다.

그리곤, 더 큰 두려움을 이겨내는 디딤돌이 되어준다.

우물 밖 세상은 내가 알지 못하는 지혜로 가득하다.

조심하는 것은 나쁠 게 없지만,

아무것도 하지 않으면 결국 수많은 늑대들 속에서 살아가게 될 것이다.

KPT 2025

본 회고에 다루지 못한 도전들과 성취들이 많았다.

경제적인 목표를 달성했고,

언어에 대한 도전을 꾸준히 하고 있으며,

자기관리에 대한 노력을 하는 등

다양한 분야를 탐구 중이다.

잘했던 것도, 아쉬웠던 것들도 많다.

2025년이 어떤 일들이 있을지는 미래가 되어 보고야 알겠지만,

꾸준할 스스로를 믿는다.

노력할 내일의 본인을 믿고 포기하지 않을 스스로를 응원한다.

Keep

가까운 만큼 더 잘하자.

아빠의 장례식의 영향인지 모르겠지만

가까운 사람에게 잘하려고 노력한다.

공부보다도, 시험보다도 더 중요한 건

가족과 친한 친구라는 것을 놓치지 않으려 한다.

낯 간지러운 말이라도

꼭 하고 싶은 진심어린 말은 일단 뱉어보기도 한다.

그 어떤 것도 사람을 이길 수는 없는 것 같다.

시험, 성공, 돈 - 모든 것들이 내가 사랑하는 사람이 없으면

다 의미 없는 존재들이 되어버린다.

사회는 결국 수 많은 사람 사이의 관계로 이루어진다.

각각의 '삶'들의 상호작용이 우리의 오늘을 만든다.

재산은 편의를 만들지만, '살아 감'은 인생의 목적이다.

성과를 더 잘 보이게 하자.

보이는 성과에 대한 목표를 잡고 노력하니

성취감이 보여지는 일들이 생겨났다.

눈으로 보이는 성취에 대해 보상감을 느꼈고,

이전에 느낀 공허함을 채워주었다.

2025년에도 가능하다면 남는 성과에 대해

한 번쯤 더 생각해보는 기회를 만들어 가고자 한다.

보상 심리를 충족시켜줄만한 시스템을 생각해보자.

경제 관념을 키우자.

사회 초년생답게, 저축이나 투자에 대한 관심을 많이 가졌고,

지출하는 비용을 굉장히 제한해왔다.

돈을 모으는 재미를 알게 되었고, 덕분에 올해 10월 목표했던 자산을 달성했다.

또래보다 많은 금액을 번 것도 뿌듯하지만,

무엇보다 성실하게 모은 금액이라는 것이 가장 큰 의미를 가져왔다.

과소비를 없앴고, 돈이 새는 곳을 막았다.

자동 이체 마스터가 되어버렸고,

MBTI - J력 100% 처럼 보일 만큼,

여러 표에 기록중이다.

내년의 경제 상황은 어떻게 될지 모르겠지만,

근본에 충실하게 성실하자.

여행하고, 관찰하자.

새로운 경험은 전에 없던 생각을 만들고

창의성과 새로운 아이디어를 얻게끔 해준다.

넓은 식견을 갖고자하는 열망을 채워줄 수도 있고,

바쁜 일상 속에서 사색의 시간을 갖게 해주는 정말 가치있는 시간이다.

2025년에도 새로운 문화를 탐험하고 즐기고 배워나 가자.

Problem

독서.

하반기에는 독서를 거의 하지 못했다.

마음이 바쁠 수록 안정을 주는 쉼터가 필요한데,

독서는 도저히 우선순위가 올라가지 않았다.

내년 상반기에도 독서마저 챙길 시간이 있을지 모르겠다.

적어도 바쁜 마음을 달래줄, 지혜의 궁금증에 힌트를 필요로 할 때

시간을 만들어 온전한 시간을 만들어가고 싶다.

최소한 한 달에 1권을 읽자.

꾸준한 연락.

꾸준히 회고록에 등장하는 개선점인데,

아직도 개선해야할 사항으로 남아있다.

본인이 인지함에도 바꾸기 어려웠던 문제점은 '연락'이었다.
흔히 안읽씹이었다.

나름 조금 노력했다고 생각했다가도 부족했다는 생각밖에 들지 않았다.

2025년에는 이 문제를 해결해야 겠다.
이를 위해 확인하면 바로 답장하고 바로 해결해나가고자 한다.

Try

Full Marathon.

10KM 가 무리라고 생각했던 처음과는 비교는 안될 만큼,

풀 마라톤이라는 도전이 더 이상 두렵지 않다.

상상조차 되지 않았던 42.195km를 달리는 본인의 모습이 이젠 머리속에 그려진다.

눈 앞의 도전을 함으로써, 큰 도전을 작게 만들어가는 과정은 언제나 신기하다.

더 이상 본인의 한계를 정하지 않게 되었다.

못한다고 생각하는 건 본인의 생각에서 비롯된다.

커뮤니티에 들어가자.

스터디 모임을 만든 건 좋은 선택이었다.
고립된 공부 말고도, 본인의 식견 밖의 지식을 가져가자.

도전하고자 하는 일 중 도움이 필요한 일들이 있는데,

조금 더 적극적으로 알아가보고 참여하고자 한다.

조언을 구할 곳을 찾고 지식을 나눌 곳을 알아가보고 경험해보자.

기술 발표.

현재 본인은 새로 배우는 입장으로 많은 내용들을 배워가고 있고, 큰 수용력을 갖고 있다.

많은 사람들에게 이 내용을 전달하자.

본인의 수용력과 열정이 빛나는 시기에, 이 힘이 닿을 수 있을 만큼 많은 사람들에게 긍정적인 영향력으로 전달될 수 있도록.

더이상 발표를 무서워하며 울먹거리던 어린 시절의 본인이 희미해져간다.

더 멀리, 많은 사람들 앞에서 발표를 할 수록,

그 긴장과 무서움이 무뎌질 것이라 믿는다.

Airflow, virtualenv python - Task 별 독립 환경 구성

gngsn — Mon, 16 Dec 2024 23:58:50 +0900

본 글에서는 Airflow Task 실행 시 virtualenv python 을 사용해 각 Task 마다 독립된 환경을 구성하는 방법에 대해 다룹니다.

사용 목적

: Airflow python 에 설치된 package와 분리를 위함입니다.

가령, Airflow Python 패키지인 apache-airflow 2.7.0 에서는 현재 pydantic==1.10.12 의존성을 가집니다.

apache-airflow constraints

이 때, 사용자는 pydantic==2.6.0 버전의 기능을 사용하고 싶을 수 있죠.
하지만, 버전을 높이는 것은 Airflow 의존 버전과 충돌해서 불가능합니다.

✔️ 해결법: 분리된 환경의 Python 사용
위 문제를 해소하기 위해서

각 task 실행 시 분리된 환경을 만들고자 virtualenv 를 사용할 수 있습니다.

Airflow Task 에서 독립된 virtualenv python 을 사용하면 몇 가지 알아둘만한 특징이 있습니다.

✔️ 특징
- Airflow Python 버전과 다른 Python Version 사용 가능

- 독립된 환경으로 Task 실행 가능

- var 과 ti(task_instance) 지원 안함

- airflow.apache.org - Passing in arguments

Airflow 와 완전히 분리된 환경에서 Task가 실행
이 때, dags/ 파일의 경로 (e.g. ../ipo-airflow-dags/dags/) 또한 전달되지 않습니다.

때문에, dags/ 하위의 파일를 import 하지 못하는데요.

이를 위해 dags/ 폴더의 path를 추가해주어 해결할 수 있습니다.

Example.

[sys.path.append(p) for p in filter(lambda p: p.split('/')[-1] == 'dags', param['dag_sys_path'])]

# 물론, 간단히 dags/ path를 append 할 수도 있습니다.
# sys.path.append('/path/to/dags-directory')

Before

...
'/Users/gyeongsun/opt/taskvenv/lib/python3.11/site-packages'

After

...
'/Users/gyeongsun/opt/taskvenv/lib/python3.11/site-packages',
'/Users/gyeongsun/airflow/dags'

마지막 경로로 dags 디렉토리가 추가되었습니다.

Task 실행 시 Virtualenv Python 사용하기

Airflow Task 실행 시 Virtualenv Python 사용하는 방법은 아래의 두 가지가 존재합니다.

1. @task.virtualenv

: Task 실행 시 마다 Virtualenv Python 생성 후 패키지 다운로드

2. @task.external_python

: Virtualenv Python 미리 생성 후 참조하여 사용

비교를 위해 @task, @task.virtualenv , @task.external_python 를 차례로 살펴보도록 하겠습니다.

@task

가장 기본이 되는 @task 어노테이션으로 실행해보도록 하겠습니다.

@dag(
    dag_id="venv_task",
    ...
)
def venv_test_dag():
    # Run with '/usr/bin/python3'
 
    @task(task_id="execute")
    def execute():
        # It'll run with '/usr/bin/python3', which is the same as running on dag
        ...
 
    execute(params)

@task.virtualenv

Task 실행 시 마다 Virtualenv Python 생성 후 패키지 다운로드를 실행합니다.

@dag(
    dag_id="venv_task",
    ...
)
def venv_test_dag():
    # Run with '/usr/bin/python3'
 
    @task.virtualenv(
        task_id="execute",
        system_site_packages=False,
        python_version='3.11',
        requirements=[
            "pytz==2023.3",
            "requests==2.31.0",
            "peewee==3.17.0",
            "pendulum==2.1.2",
            "pydantic==2.6.0",
            "dataclasses-json==0.6.4"
        ],
    )
    def execute(param: dict):
        # It'll run with virtualenv python, which is airflow made (fyi. /usr/local/bin/python -m virtualenv /tmp/venv0rql4m81 --python=python3.11)
        ...
 
    execute(params)

실제 실행되는 로그를 살펴보면 아래와 같이 출력됩니다.

...
Executing cmd: /usr/local/bin/python -m virtualenv /tmp/venv0rql4m81 --python=python3.11
...

@task.external_python

Virtualenv Python 미리 생성 후 참조하여 사용

✔️ Virtualenv Python 설치

먼저, Airflow 에서 Dag를 실행시킬 때 생성하는 Pod Container Image 에 virtualenv를 생성합니다.

ARG SOURCE=container-registry/external/apache/airflow
ARG SOURCE_TAG=2.6.3-python3.9
ARG SRC_PATH=$(pwd)
FROM $SOURCE:$SOURCE_TAG
 
...

ENV VIRTUAL_ENV=/opt/taskvenv
RUN python3 -m venv $VIRTUAL_ENV
RUN source $VIRTUAL_ENV/bin/activate && \
    export PIP_USER=false && \
    export PIP_CONFIG_FILE=/home/airflow/.pip/pip.conf && \
    echo $(which python3) && \
    python3 -m pip install \
        pytz==2023.3 \
        requests==2.31.0  \
        peewee==3.17.0  \
        pendulum==2.1.2  \
        pydantic==2.6.0  \
        dataclasses-json==0.6.4  \
        psycopg2-binary==2.9.9  \
        boto3==1.34.69
 
USER airflow

✔️ Virtualenv Python 실행 적용

생성 후, Dag가 실행되는 Pod Container에서 해당 python 을 사용하도록 python path 를 직접 지정해줍니다.

PYTHON3_11_VIRTUALENV = "/opt/taskvenv/bin/python3"
 
@dag(
    dag_id="venv_task",
    ...
)
def venv_test_dag():
    # Run with '/usr/bin/python3'
 
    @task.external_python(
        task_id="execute",
        python=PYTHON3_11_VIRTUALENV
    )
    def execute(param: dict):
        # It'll run with '/opt/taskvenv/bin/python3', which is pre-equipped virtualenv python 
        ...
 
    execute(params)

위와 같이 실행하면 아래 로그처럼 지정한 python 을 사용할 수 있음

✔️ 검증

INFO - Running <TaskInstance: update_ipo_list.execute scheduled__2024-12-13T09:20:00+00:00 [running]> on host update-ipo-list-execute-cj4qeg2i
INFO - Executing cmd: /opt/taskvenv/bin/python ...

Airflow 이미지에 생성한 가상 환경 Python 을 활성시켜 사용하는 것을 확인할 수 있습니다.

참고로, sys.path 에서도 /opt/taskvenv/bin/python 경로가 추가된 것을 확인할 수 있습니다.

Kubernetes Static Pods, 제대로 이해하기

gngsn — Wed, 10 Jul 2024 23:28:52 +0900

본 포스팅에서는 Kubernetes의 Static Pod의 개념을 이해하고 생성, 수정 및 삭제할 수 있도록 학습하는 목표를 가집니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

쿠버네티스의 Static Pod에 대해서 알아보도록 하겠습니다.

Static Pods

일반적인 Pod는 주로 Deployment, StatefulSet, DaemonSet 등의 컨트롤러를 통해 생성되고 관리됩니다.

또, 생성된 리소스는 Kubernetes API 서버를 통해 정의되고 관리됩니다.

정적 Pod(이하 Static Pod)는 API 서버의 관여없이 특정 노드에서 kubelet 데몬에 의해 직접 관리됩니다.

컨트롤 플레인에 의해 관리되는 일반 Pod와 달리,

kubelet이 각 Static Pod를 관찰하고 실패하면 재실행시킵니다.

Regular Pod vs. Static Pod

일반 Pod과 Static Pod의 차이점을 조금 더 살펴보도록 하겠습니다.

먼저 관리 주체가 다릅니다.

✔️ Regular Pod

일반 Pod는 API 서버에 의해 관리되고, 관리를 위한 데이터가 etcd에 저장됩니다.

따라서 kubectl 같은 명령어를 통해 쉽게 조회, 수정, 삭제가 가능합니다.

일반 Pod의 경우, kubelet은 kube-apiserver에 의존하여 해당 kubelet이 위치한 노드에 어떤 Pod를 배치할지 지시를 받습니다.

이 지시는 kube-scheduler의 판단에 따라 결정되고, 이후 데이터 저장소에 저장됩니다.

✔️ Static Pod
Static Pod는 API 서버와 독립적으로 동작합니다.

kubelet은 Static Pod를 감지하고 생성하지만, Static Pod의 정보를 따로 저장하지 않습니다.

대신, API 서버는 "Mirror Pod"라는 형태로 조회할 수 있게 합니다.

kubelet는 각 Static Pod에 해당하는 Mirror Pod를 Kubernetes API에 생성을 시도합니다.

그래서 Etcd에 저장되어 있지 않아도,

kube-apiserver API 나 kubectl 명령어를 통해 Static Pod 정보를 확인할 수 있습니다.

즉, kube-apiserver API에서 조회는 할 수 있어도 mirror 객체이기 때문에 그 어떤 제어는 불가능합니다.

Static Pod는 항상 특정 노드의 하나의 Kubelet에 바인딩됩니다.

Static Pod 이름은 특정한 규칙이 있는데요.

해당 ≪static_pod_name≫-≪node_name≫ 으로 생성됩니다.

자세한 내용은 마지막 섹션 Regular Pods? Mirror Pods? 을 참고해주세요.

Usage

독립적인 Pod를 띄우고자 할 때 Static Pod를 사용하기 때문에,

두 종류의 Pod는 사용 목적이 다릅니다.

✔️ Regular Pod

일반 Pod는 애플리케이션 배포, 스케일링, 업데이트 등의 일반적인 Kubernetes 작업에 사용됩니다.

✔️ Static Pod

Static Pod는 주로 클러스터 부팅 과정에서 필수적인 컴포넌트를 실행할 때 사용됩니다.

가령, etcd 이나 kube-apiserver 등이 있죠.

각 노드에 필수적으로 존재해야 하는 시스템 컴포넌트를 실행하는 데 적합합니다.

만약, Master 없을 때 단일 Node가 독립적으로 실행될 수 있을까요?

kube-apiserver, kube-scheduler, controllers, etcd cluster 등 리소스를 관리할 컨트롤 플레인이 없을 때, 가능할까요?

결론적으로 말씀드리면,

네, 하나의 Node가 독립적으로 실행될 수 있습니다.

How Static Pod Work?

kubelet 데몬으로 실행되기 때문에 노드를 독립적으로 관리할 수 있습니다.

그러나 Pod 상세 데이터를 제공해줄 API 서버가 없습니다.

어떻게 Pod를 생성 할 수 있을까요?

kube-apiserver 없이 Pod 정의 파일을 전달하는 방법은,

kubelet이 Pod 상세 정보를 파일에서 읽어오게 설정할 수 있습니다.

https://www.simform.com/blog/kubernetes-architecture/

즉, Pod에 관한 정보를 저장하는 서버 디렉터리에 관리하고,

kubelet을 설정하면 해당 Pod 정의 파일을 읽을 수 있습니다.

kubelet은 주기적으로 특정 디렉터리 하위의 파일을 읽고 Pod를 생성하며, Pod가 죽지 않도록 보장합니다.

특정 디렉터리는 아래 Designated Directory 섹션에서 계속 설명합니다.

앱이 고장 나면 kubelet이 재시작을 시도합니다.

디렉터리 내 파일이 변경되면 kubelet이 Pod를 재생성하여 변경 사항을 적용합니다.

파일을 제거하면 해당 Static Pod가 자동으로 삭제됩니다.

API 서버나 쿠버네티스 클러스터 구성 요소의 간섭 없이,

kubelet이 스스로 만든 Pod를 정적 Pod라고 합니다.

kubelet은 오직 Pod에 대한 내용만 알기 때문에,

ReplicaSet, Deployment, Service를 통해 배치될 수 없고,

지정된 디렉토리에 정의 파일을 배치하는 방식으로만 Pod를 만들 수 있습니다.

Designated Directory

그렇다면, kubelet이 Static Pod를 생성하기 위해 참조하는 폴더는 어디에 존재하며 어떻게 구성할까요?

Static Pod 의 Manifest (이하 매니페스트) 파일들을 관리하는 폴더는

기본적으로 /etc/kubernetes/manifests 폴더로 설정되어 있습니다.

여기서 매니페스트 파일이란, 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 Pod 정의를 의미합니다.

가령, 아래와 같이 Control Plane 컴포넌트 중,

기본적으로 Static Pod 로 띄우는 파일들이 저장되어 있음을 확인할 수 있습니다.

controlplane ~ ➜  ll /etc/kubernetes/manifests
total 28
drwxrwxr-x 1 root root 4096 Jul 10 13:30 ./
drwxrwxr-x 1 root root 4096 Jul 10 13:30 ../
-rw------- 1 root root 2400 Jul 10 13:30 etcd.yaml
-rw------- 1 root root 3877 Jul 10 13:30 kube-apiserver.yaml
-rw------- 1 root root 3393 Jul 10 13:30 kube-controller-manager.yaml
-rw-r--r-- 1 root root    0 Apr 17 18:31 .kubelet-legacy.yaml
-rw------- 1 root root 1463 Jul 10 13:30 kube-scheduler.yaml

Kubelet은 해당 디렉터리를 정기적으로 스캔하며,

디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 Static Pod를 생성하거나 삭제합니다.

참고로, Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시합니다.

예시를 위해 위에 추가 해둔 .kubelet-legacy.yaml 은 무시됩니다.

이 때, Kubelet이 참조할 디렉터리를 변경하고 싶다면 아래의 두 옵션을 통해 수정할 수 있습니다.

✔️ Kubelet config - staticPodPath

kubelet 을 설정할 때 kubelet 설정 파일에 staticPodPath 옵션으로 원하는 위치를 지정할 수 있습니다.

가령, kubelet이 아래와 같이 실행되었을 때,

$ ps -ef |  grep /usr/bin/kubelet
root        4345  0.0  0.0 4357904 94820 ?       Ssl  13:30   0:11 /usr/bin/kubelet \
--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf \
--kubeconfig=/etc/kubernetes/kubelet.conf \
--config=/var/lib/kubelet/config.yaml \
--container-runtime-endpoint=unix:///var/run/containerd/containerd.sock \
--pod-infra-container-image=registry.k8s.io/pause:3.9
...

설정 파일인 --config=/var/lib/kubelet/config.yaml 을 살펴보면,

$ cat /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
staticPodPath: /etc/kubernetes/manifests
...

위와 같이 설정된 staticPodPath 를 확인할 수 있습니다.

Kubelet의 구성 파일은 Kubelet Config 에서 자세히 확인할 수 있습니다.

✔️ --pod-manifest-path option

혹은, 권장하지는 않지만, 명령행의 인자로 넘겨줄 수 있습니다.

--pod-manifest-path=/etc/kubernetes/manifests

호스트의 어떤 디렉터리든 될 수 있으며,

디렉터리 위치는 서비스를 실행하는 동안 kubelet에 옵션으로 전달됩니다.

이처럼 Kubelet이 특정 위치에서 Static Pod를 불러오기 때문에,

Static Pod을 생성할 때는 가장 먼저 kubelet 옵션을 살펴볼 필요가 있습니다.

Create a Static Pod

가장 간단하게 Static Pod를 생성하는 방법은

pod 실행 yaml 를 Kubelet이 참조하는 staticPodPath에 저장하면 됩니다.

가령, 아래와 같은 단일 명령어로 말이죠.

$ kubectl run --restart=Never \
    --image=busybox static-busybox \
    --dry-run=client -o yaml \
    --command -- sleep 1000 \
    > /etc/kubernetes/manifests/static-busybox.yaml

해당 명령어를 입력한 후, 아래와 같이 저장된 것을 확인할 수 있습니다.

controlplane ~ ➜  cat /etc/kubernetes/manifests/static-busybox.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: static-busybox
  name: static-busybox
spec:
  containers:
  - command:
    - sleep
    - "1000"
    image: busybox
    name: static-busybox
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

두 번째 방법은 아래와 같이 일반 Pod 파일을 생성하는 것입니다.

원하는 Static Pod Yaml Spec을 작성해서 위 위치에 저장해주면,

Kubelet이 주기적으로 읽어서 업데이트 할 때 Pod가 올라갑니다.

# /etc/kubernetes/manifests/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP

그럼, 이번엔 생성한 Static Pod를 확인해보겠습니다.

Observe Static Pods

먼저, Static Pod를 확인하기 위해서 Container Runtime의 명령어를 사용할 수 있습니다.

Kubectl 명령어나 kube-serverapi 가 없이도 확인할 수 있다는 의미입니다.

아래와 같이 확인합니다.

✔️ Docker: docker ps
✔️ cri-o: crictl ps
✔️ containerd: nerdctl ps

controlplane ~ ➜  crictl ps
CONTAINER           IMAGE               CREATED             STATE               NAME                      ATTEMPT             POD ID              POD
7bfd3f585b3a9       fffffc90d343c       2 minutes ago       Running             web                       0                   cb6e2e86b0ccf       static-web-controlplane
8255080953cff       65ad0d468eb1c       10 minutes ago      Running             static-busybox            0                   a6edc266133b3       static-busybox-controlplane
...

Modify / Delete a Static Pod

그럼, Static Pod 를 수정 하거나 삭제하려면 어떻게 해야할까요?

kubectl edit 명령어나 그 밖에 떠 있는 Pod에서는 수정하거나 삭제할 수 없습니다.

Mirror 객체이기 때문이죠.

반드시 Kubelet이 읽어오는 Static Pod 파일 자체를 수정해야합니다.

가령, 위의 예시 중 static-busybox 의 sleep 시간을 500으로 변경하고 싶다면 아래와 같이 수정합니다.

$ kubectl run --restart=Never \
    --image=busybox static-busybox \
    --dry-run=client -o yaml \
    --command -- sleep 500 \
    > /etc/kubernetes/manifests/static-busybox.yaml

단순히 오버라이딩하는 것으로 수정이 완료 됩니다.

삭제할 때도 동일합니다.

해당 Static Pod 정의 파일 자체를 삭제하면 됩니다.

$ rm /etc/kubernetes/manifests/static-busybox.yaml

General Pods ? Mirror Pods?

일반 Pod와 Static Pod 로 생성된 인스턴스인 Mirror Pod는 어떻게 구분할까요?

두 가지 방법이 있습니다.

✔️ 1. 이름을 통한 추측

Static Pod는 생성 시, 이름 뒤에 노드 이름이 붙습니다.

위에서 언급했다시피, ≪static_pod_name≫-≪node_name≫ 의 포맷으로 생성됩니다.

Ex: etcd-controlplane, kube-apiserver-controlplane, kube-controller-manager-controlplane, kube-scheduler-controlplane 등

컨트롤 플레인에 존재하는 Static Pod 를 살펴보면 쉽게 이해할 수 있을 텐데요.

❯ k get nodes
NAME                 STATUS   ROLES           AGE   VERSION
kind-control-plane   Ready    control-plane   59d   v1.29.2

❯ kubectl get pods -A
NAMESPACE            NAME                                         READY   STATUS    RESTARTS      AGE
kube-system          coredns-76f75df574-l6tsh                     0/1     Running   1 (11s ago)   59d
kube-system          coredns-76f75df574-s787j                     0/1     Running   1 (11s ago)   59d
kube-system          kube-apiserver-kind-control-plane            0/1     Running   1 (11s ago)   59d
kube-system          kube-controller-manager-kind-control-plane   0/1     Running   1 (11s ago)   59d
kube-system          kube-proxy-8v42q                             1/1     Running   1 (11s ago)   59d
kube-system          kube-scheduler-kind-control-plane            0/1     Running   1 (11s ago)   59d
...

먼저, kube-scheduler 나 kube-apiserver 등의 경우, 하이픈과 노드 이름 kind-control-plane 이 붙은 것을 확인할 수 있습니다.

kube-scheduler-kind-control-plane, kube-apiserver-kind-control-plane

→ Static Pod

반면, kube-proxy나 coredns의 경우, 하이픈 뒤 랜덤 문자열이 붙은 것을 확인할 수 있습니다.

kube-proxy-8v42q, coredns-76f75df574-l6tsh, coredns-76f75df574-s787j

→ 일반 Pod

✔️ 2. Pod 상세 조회

Static Pod의 경우네는 .metadata.ownerReferences.kind → Node 로 표기됩니다.

가령, 아래 kube-controller-manager 를 확인해보면,

controlplane ~ ➜  kubectl get pods kube-controller-manager-controlplane -n kube-system -o yaml
apiVersion: v1
kind: Pod
metadata:
  ...
  name: kube-controller-manager-controlplane
  namespace: kube-system
  ownerReferences:
    - apiVersion: v1
      controller: true
      kind: Node
      name: controlplane
      uid: 07cf24ac-9926-4125-9f64-f501d99ddd95

kind가 Node 인 것을 확인할 수 있습니다.

→ Static Pod

반면, Control Plane을 통해 관리되는 Pod는 .metadata.ownerReferences.kind → ReplicaSet 와 같이 Node가 아닙니다.

controlplane ~ ➜  kubectl get pods coredns-69f9c977-8v7km -n kube-system -o yaml 
apiVersion: v1
kind: Pod
metadata:
  ...
  name: coredns-69f9c977-8v7km
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: coredns-69f9c977
    uid: 2d54c431-233c-4fdc-9734-f90bb46dcdc5

위와 같이 kind가 ReplicaSet인 것을 확인할 수 있습니다.

→ 일반 Pod

| Reference |

Kubernetes.io - Official Docs

Udemy: certified-kubernetes-administrator-with-practice-tests

2024년 상반기 회고

gngsn — Mon, 1 Jul 2024 20:00:42 +0900

2024년 상반기 돌아보기

1/ 일상 – 1%의 하루

2/ 개발 – 첫 서비스

3/ 영어 – 호주 여행

⎸

2024년 하반기 목표

# 성과 가시화 하기

# 스스로에 대한 투자하기

# 꾸준히 기록하기

# 나를 생각할 시간 확보하기

2024년 상반기 돌아보기

새 직장을 다니기 시작한 만큼 새로운 마음으로 한 해를 시작했다.

내가 향하는 방향이 맞는지 계속해서 의심하고,

내가 정말 하고 싶고 이루고 싶은 것이 무엇인지 질문해오며,

꾸준한 노력들을 이뤄갔다.

6개월을 보내는 동안 긴 시간처럼 느껴졌다.

막상 회고를 적을 시간이 다가오니,

그저 짧은 6개월이었다는 것을 막연히 느낄 뿐이다.

2024년에 이루고자 했던 것들을 생각해보면

이직한 회사에서의 적응, 경제 관념 키우기, 운동, 독서, 그리고 영어 공부 등이 있었다.

본 회고에서는 상반기의 본인의 반기를 정리해보며,

옳은 방향으로 가고 있는지 되짚어 보는 시간으로 보내고자 한다.

1/ 일상 – 1%의 하루

하루를 의미있게 살 방법에 대해 고민하곤 한다.

어제보다는 더 나은 내가 되었으면 했고,

매 순간이 아쉽지 않게 보냈다.

그런데, 문득 공허함을 느꼈다.

달리고 노력하고, 다시 또 달리는 것을 스스로도 알지만 무엇인가 공허할 때가 있다.

채워지지 않는 갈망 같은 것이다.

이유를 찾고 싶었다.

인생에 대한 방향성을 위한 지혜를 갈구했다.

어느날은 인생의 멘토가 있었으면 좋겠다는 생각을 하기도 했다.

본인이 가고 있는 길이 맞는 길인지 옆에서 알려주고 묵묵히 응원해주는 그런 멘토.

한참 공허함을 느낀 언제가는,

본인이 어떤 하루를 보내고 있는지,

하루 일과를 적었다.

6:00 ~ 6:40 침대 정리 & 헬스장 이동
6:50 ~ 8:00 운동 (1H)
8:00 ~ 9:00 출근 준비 (1H)
9:00 ~ 20:00 일 (11H)
→ 12:00 ~ 13:00 점심 시간 영어 공부

20:00 ~ 20:30 이동 & 저녁 & 휴식 (.5H)
20:30 ~ 23:30 개인 공부 (3H)
→ 영어 수업 (MON, THU) or 기술 스터디 / 블로그 포스팅 (WED, THU, FRI)

23:30 ~ 24:30 씻기 (.5H) & 독서 & 휴식
24:30 ~ 01:00 휴식 후 취침

곰곰히 생각해보고 나서야,

눈에 보이는 산출물이 없어서라는 결론을 지었다.

결과물이 생기는 다른 걸 또 해볼까 하다가,

더 이상 일정을 추가하기엔 무리인 것 같아서 그만 뒀다.

곧, 왜 이런 일정을 갖게 됐을까하는 의문을 가졌다.

하고 싶은게 많았다.

되고 싶은 꿈꾸는 본인의 모습을 그렸다.

그래서 미래까지 영향을 줄 수 있는 작은 하루 하루의 행동이 필요했다.

어제 만든 무언가가 오늘까지 영향을 줄 수 있는 것.

한 발씩 내딛는 작은 발걸음이,

한 보폭 한 보폭이,

마침내 마라톤의 결승 지점으로 이끌어주는 것처럼 말이다.

본인이 생각했을 때, 달릴 때 중요한 건 방향성과 연속성이었다.

본인이 정말 하고 싶은 일이 무엇인지를 고민하고,

어제와 내일이 연결될 수 있는 오늘을 만드는 것이다.

매일 아침 일찍 운동하고,

매일 30분 경제 뉴스를 읽고,

매일 자기 계발을 위해 스스로를 가르치고,

매주 외국인 친구들을 만나 추억을 만들고,

주기적으로 블로그 글을 포스팅하는 것.

처음의 무지와 서투름이 점점 스스로 인정하는 실력을 갖게 될 때까지.

너무 작게 느껴지는 1%의 점이, 백 일 뒤엔 100%의 점으로 채워질 수 있게.

다만, 도전할 수 있는 가장 어린 나이에 전속력을 내고 싶은 마음이다.

마라톤을 하는데 처음부터 걸어가긴 아쉽지 않을까.

---

# ‘나’ 에 대한 기대

최근, 한 CTO와 미팅을 했다.

친근한 성격의 시드니에서 온 호주 사람이었다.

필자의 포트폴리오 사이트를 보고 좋은 인상을 받았다고 했다.

사실, 포트폴리오 사이트를 만든 계기는 이렇다 ⎯

"모든 이력서가 너무 다 똑같아 보여서 재미가 없고,

개발자라면 코드로 쓰여진 이력서 쯤 갖고 있어야 하지 않을까?"

대학교 2학년 때 재미로 만들었었고,

사실, 코드가 마음에 들지 않아 네 번이나 다시 만들었다.

그는 흥미로운듯 많은 질문을 했는데,

그 중 주변에서도 아주 많이 물어보는 질문이 있었다.

어떻게 그렇게 열정을 가지고 사는지, 지치진 않는지.

어려운 질문이었다.

24년 현재로서의 본인이 대답을 하자면,

스스로 만들어갈 본인의 모습이 기대된다.

되고 싶은 모습을 꿈꾼다.

좋아하는 것을 잘하고 싶다는 꿈을 그린다.

좋아하는 것을 잘할 때까지 꾸준히 노력하다 보면,

점점 실력이 느는 본인을 볼 수 있다.

잘하게 되면 더 좋아지고,

좋아지면 더 잘하고 싶다.

2/ 개발 – 첫 서비스

일을 하는 게 재미있다.

내가 배워온 것들을 실제로 써보고,

추상화된 내용을 실제로 만들어 내고,

결과를 창출해내는 일련의 과정이 재밌고 유의미했다.

대학생 때 프로젝트를 하면서 느낀 재미보다는 현실감과 책임감을 크게 느껴야 하지만,

성취감은 더욱 컸다.

일을 하는 만큼 실력이 향상되는 전문성을 띈 직업을 갖고 있다는 것에 감사했다.

실력 뿐 아니라 다양한 면에서 배울 점 많은 동료들과 함께,

개인은 노력과 열정을 부어서 그 만의 가치를 만들어내고 회사는 그에 상응하는 월급을 주니,

어떻게 일을 즐기지 않을 수 있을까.

직장에서의 시간을 허투루 보내고 싶지 않았다.

흔히 '월급 루팡' 을 하기엔, 하루 중 가장 효율성이 높은 중요한 시간이었다.

아직 배울 점이 많아,

배울 점 많은 환경을 최대한 활용해야 겠다는 생각을 하곤 했다.

그렇게 이직한 회사에서의 일년이라는 시간이 다다랐다.

순식간에 지난 일 년동안 본인의 페이스대로, 하고 싶은 것들을 이뤄 나갔다.

배우는 것을 즐겼고 결과를 만들어가는데 최선을 다했다.

⎸

이직한 회사에서의 첫 프로젝트가 오픈한다.

7월 1일, 다사다난했던, 애정이 깃든, 원망과 희망이 공존했던,

공모주 서비스를 오픈한다.

작게 시작했지만 작지 않았고,

가볍게 시작했지만 큰 의미를 가져왔고,

많은 이들을 웃고 울게 했던 프로젝트다.

내가 만들어가는 프로젝트라는 마음을 단 한번도 잃지 않았다.

어쩌면 잘만들었다는, 유용하다는, 잘쓰고 있다는 말을 듣고 싶어 발버둥 쳤었던 것 같다.

큰 책임감은 무거움을 가져오지만 그만큼의 애정을 깃들게 했다.

나의 미래를 함께 고민하고 기대해준 리더님,

힘든 시간을 같이 보내며 전우애를 쌓아온 기획·디자이너 멤버 분들도,

본인 일처럼 다가와 도움을 주고 가는 팀원분들도

같이 일할 수 있어서 이렇게나 부족한 본인이 멋진 서비스를 만들 수 있었다.

# 생각은 행동이 되고, 행동은 내가 된다.

언젠가 아주 피곤한 상태로 깬 적이 있다.

그냥 포기하고 다 쉬고 싶다는 생각까지 했다.

문득, 못 다한 프로젝트 기능이 떠올랐다.

그리고, 오늘은 기필코 그 기능을 마무리하겠다고 결심했다.

얼른 완성하고 싶다는 생각에 피곤함을 잊어버렸다.

가끔 하는 생각인데, 게임에서 레벨업을 하면 기분이 좋듯이,

나는 인생에서의 레벨업에 큰 기쁨을 느끼는 것 같다.

배우고 실제로 사용하는 건 큰 재미와 흥미로 다가온다.

자전거를 배운 후 실제로 탈 수 있을 때,

영어를 배운 후 문장을 읽을 수 있게 될 때처럼 말이다.

얼마나 배우고 어느 정도의 성과를 낼 수 있는지,

성취감을 얻을 수 있는지 생각해 볼 가치가 있다.

직장에서 배우는 많은 것을 그저 간과한다면 이런 성취를 보지 못할 것이다.

현실적으로, 대부분의 사람에게 직장은 인생에서 뗄 수 없는 존재이다.

일이 하기 싫다는 생각을 가지면, 평생 해야 하는 일이 불행하게만 느껴져 너무 비극적이지 않을까.

어차피 해야 할 일이면 즐기면서 하자는 생각이다.

아침 일찍 일어나는 건 싫어도, 아침 커피 한잔과 생산적인 하루를 보낼 수 있다는 건 좋을 수 있지 않을까.

하기 싫은 일이 있어도, 마침내 해내는 내 모습에 성취감을 느낄 수 있지 않을까.

생각하기 나름인 것 같다.

성장을 목표로 삼으면 성장을 하고, 회사를 위한 곳으로 생각하면 그것이 전부가 되는 것처럼.

결국 본인의 생각이 본인의 행동이 된다.

---

3/ 영어 – 호주 여행

영어 공부에 큰 노력을 쏟았다.

그래서 실제로 써보고 싶었고,

혼자 호주 여행을 가기로 결심했다.

특유의 악센트, 슬랭, 특유의 단어, 한편으로는 긴장되었고 한편으로는 기대됐다.

걱정은 없었다. 걱정을 버린지는 오래다.

걱정이 주는 변화는 없다는 걸 안 이후로.

자연을 즐기고 정말 많은 사람들과 소통했다.

카페에서 만난 시드니 친구랑 이틀 간 같이 여행하고,

길에서 만난 이란 친구와 산책을 하며 호주에서의 현실 일상을 듣기도 했고,

우연히 만난 한국 분을 에어비앤비로 초대해 과일을 깎아 먹기도 했다.

누군가에게 말거는데 거리낌 없는 여행 페르소나가 가뜩 뿜어진 것 같다.

직원들에게 낯가림 없는 척 이것저것 물어봤고,

능청스럽게 너무 맛있었다는 말 한마디라도 더 했다.

영어가 자연스러운 공간의 차이를 크게 느꼈다.

⎸

호주에서의 마지막 밤, 개발 관련된 모임에 참석했다.

낯설었고,

두려웠고,

무서웠다.

두려운 감정은 한 번 부딪혀 봐야 다음부터는 덜 두렵게 되는 걸 알게 된 이후부터는 눈 딱 감고 부딪히고 있다.

그렇게 발걸음을 옮겼다.

왠지 모르게 주눅들었는데, 뭐에 대해 두려운 건지, 긴장감이 돌았다.

두렵지 않은 척 스스로를 속이는게 익숙해졌다고 생각했는데 아니었나 보다.

종종 대화들을 놓쳤고, 언제는 그냥 집에 가고 싶었다.

영어가 당연한 환경이지만, 그럼 당연히 그 언어를 잘해야 하지 않을까 라는 생각이 들었다.

외국어를 구사하더라도 본인의 표현 방식이 정확한지 알 수 없어 불안했다.

시간이 지날수록, 점점 편해졌다.

이 상황이 언젠간 “이 순간을 웃어넘길 수 있겠지”라는 생각으로 무서움을 무시하려고 애썼고, 그 순간이 얼른 왔으면 했다.

나에 대한 질문이 쏟아질 때쯤 대화에 중심에 있었고, 속으로는 긴장됐지만, 태연한 척 대화를 이어갔다.

그 그룹에서 만난 친구들과 새벽까지 놀다 해산했는데,

다음 날 떠나는 본인을 진심으로 아쉬워했다.

꼭 다시 한 번 오라는 말을 몇 번이나 반복하며 마지막 인사를 나눴다.

⎸

그렇게 숙소로 돌아가는 길,

본인이 이전에 그리던 모습을 그리고 있는 스스로를 발견했다.

아주 새로운 사람들을 만나 서로 다른 생각을 나누고,

색다른 환경에서의 사람들의 일상을 들어보고,

친구들의 문화를 알아가는 동시에 당연시 여겼던 한국의 문화를 새삼 느끼고 있었다.

다양한 문화를 배우면서 한국의 문화가 좋아진 것도 같다.

포기하고 싶고 실패처럼 느껴졌던 과거가 순간 떠올랐다.

포기했다면 그저 실패로 남았겠지만, 결국 실패가 아니었다.

그저 하나의 과정이었다.

⎸

몇 번 실패해도, 중간에 멈춰도, 다시 시작하면 된다.

한 번의 실패로 멈추게 되면 그건 진짜 실패가 되지만,

다시 시작하면 그냥 과정일 뿐이니까.

내가 이루지 못한 것을 내일의 내가 이루게 하면 된다.

오늘의 내가 실패한 곳에서 배울점을 찾으면,

그 마저도 실패가 아닌 배움의 과정이다.

실패했다고 생각한다면 과정으로 만들어 버리면 된다.

# 몽골에서의 밤

몽골 여행을 떠났다.

한 몽골 남자와 한 몽골 여자와 함께 여행했다.

우리 셋은 또래였고, 그래서 친구처럼 여행할 수 있었다.

Terkhiin Tsagaan Lake 의 마지막 밤,

마지막 밤 게르 앞에 돗자리를 펴 놓고 누워 별을 바라보며 서로의 이야기를 들었다.

여자 동행은 자신의 모습을 좋아하지 않아서 최근 살을 빼기 위해 운동을 시작했다고 말했다.

낮은 자존감의 그 친구가 안쓰러워 보였다.

과거의 필자가 생각났다.

곧 남자 동행이 다소 격한 언어로 말했다.

다른 사람들이 하는 말들에 신경쓰지 말라고.
너 스스로를 사랑하라고.

맞다. 그런데, 마음 한켠에 반감이 들었다.

듣기 좋은 흔한 말이다.

하지만 다른 사람들의 말을 신경쓰지 않고 스스로를 사랑하라는 말이,

정말 말로써 전달이 될까?

사회에서 주는 분위기를, 미의 기준을 무시하고 살기란 현실에서 쉬운 일은 아니다.

⎸

남자 동행의 말이 끝나고 잠깐의 정적이 흘렀다.

정적을 깨고 정말 그 친구에게 해주고 싶은 이야기를 했다.

필자는 무언가 바꾸려고 노력하는 내 모습을,
한 발짝 움직인 스스로를 인지하고 응원해주는 것 부터 시작하는 게 도움이 되었었다고.

본인의 모습을 마음에 들지 않는다고 해서 당장 변하는 건 없다.

걱정하고 우울해한다고 해서 달라지는 건 없다.

근데, 내 모습을 객관적으로 받아들인다고 해서 달라지는 것도 없다.

천재였으면 좋겠다는 생각으로 매일 배우는 걸 멈추지 않았던 것,

아침 일찍 일어났으면 좋겠다는 생각으로 매일 이른 아침 운동을 가기 시작했던 것처럼.

본인은 천재가 아니었고, 너무 많이 자는 바람에 부모님께서 병은 아닐까 걱정까지 하던 사람이라는 것을 받아들였다.

더이상 본인이 천재가 아니라서 속상해 하지 않았고, 일찍 못일어나는 스스로를 위해 습관을 만들려고 노력했다.

천재는 아니지만 장난스레 천재라는 말을 들었고, 2년간 6시 기상을 이뤄가고 있다.

작은 성취들은 스스로의 자기 효능감을 키웠고, 자존감을 키웠다.

⎸

본인이 바꾸고 싶은 본인의 문제점을 그대로 받아들이기 시작한 이후부터,

그다음 변화를 위해 움직일 수 있다.

어쩌면 본인이 받아들이기 어려운 부분은 본인이 정말 욕심내는 부분이기 때문에 외면하고 있을지도 모른다.

스스로의 모습을 피하거나 부정하지 않고, 객관적인 나라는 존재를 그대로 받아들이는 일.

무언가 변하고 싶어 노력하는 나를 알아주는 일.

변화를 위해 움직이는 스스로를 응원하는 일.

이 변화가 다음을 도전하는 스스로를 믿게 해주는 동력이 되어주었다.

나를 믿어 주는 한 걸음이다.

⎸

2024년 하반기 목표

# 성과 가시화 하기

2023년부터 2024년 까지 꾸준히 해온 것들이 정말 많았다.

영어 프로그램,

꾸준히 다니는 언어 교환 모임,

기술 책 스터디,

쿠버네티스 스터디,

블로그 포스팅,

새롭게 시작한 운동,

혼자 여행.

아쉽게도 눈에 보이기는 힘든 것들이 많았다.

정량적인 측정이 안되니 스스로가 공허함을 느끼곤 했다.

조금 더 스스로가 깨달을 수 있는 결과물들을 만들어보자.

본인이 걸어온 성과를 가시화해서 성취의 보상을 주는 것이 좋을 것 같다.

# 스스로에 대한 투자하기

사회 초년생이기 때문에 돈을 쓰는 씀씀이를 아주 적게 만들고 사회 생활을 시작했다.

덕분에 저축이나 투자에 대한 관심을 많이 가졌고,

지출하는 비용이 굉장히 적었다.

덕분에 돈을 모으는 재미를 알게됐다.

하지만, 종종 필요한 소비를 할 때에도 돈을 아껴야 한다는 생각을 떨치기가 어려웠다.

운동 비용, 교육 비용, 생활 비용 등등.

본인에 대한 투자임을 알면서도 주춤하게 되곤 했다.

조금 더 스스로에게 투자하는 데 너그러워지고,

적절한 선에서의 지출을 늘리는 게 좋겠다.

# 꾸준히 기록하기

하루 하루, 하고 싶은 것들을 하고 이루고 싶은 것들을 이루고,

힘든 과정을 이겨내고, 어려운 시간을 견디는 소중한 하루를 기록하고 싶다는 생각을 한다.

자유롭게 생각하고 움직일 수 있는 좋은 시기임을 인지하고 감사하자는 생각이다.

본인의 소중한 하루가 한 페이지의 재미, 혹은 흥미로운 이야기로 남도록.

하루하루는 책을 써가는 것 같다. 내가 바라는 삶은, 언젠가 책을 펼쳤을 때 그 이야기가 흥미롭고 재미있는 이야기로 채워져 있는 것이다.

누군가에게 이렇게 말할 수 있을 만큼: "⎯ 이런 삶을 살아봤는데, 정말 의미 있더라, 정말 좋았다."

즐거운 일만이 흥미로운 이야기는 아니다. 인간으로서 느낄 수 있는 감정을 충분히 느끼며, 인생 속에 있음을 느끼는 것만으로도 흥미롭다.

예를 들어, 힘든 이별 후에 느껴지는 감정을 외면하지 않고 충분히 느껴보는 것이다. 평범한 일상 속에서 골치 아픈 일이 일어나지 않는 사실을 충분히 감각하는 것이다. 성취했을 때의 자신을 충분히 인정해주고 만끽하는 것이다.

감정을 걷어낸 인지와 감정을 있는 그대로 충분히 느끼는 그 사실이 살아 있음을 느끼게 한다.

나는 스스로에게 최면을 걸곤 한다. 바로 긍정적인 면을 계속 찾는 것이다.

효과가 좋다. 좋아하지 않더라도, 힘든 일이라도 생각하기 나름이다.

# 나를 생각할 시간 확보하기

바쁘다는 이유로 나를 마주보는 시간이 줄어들고 있다.

누군가에게 말하기 준비가 안된 것들도 많았는데, 혼자만의 영역에 정리할 필요가 있다.

책 읽는 시간을 확보하고 내가 어떤 생각을 갖는지,

무엇을 좋아하는지 조금 더 생각해볼 여유를 갖는 게 좋겠다.

Container Networking, 어렵지 않게 이해하기

gngsn — Wed, 19 Jun 2024 13:18:35 +0900

안녕하세요.

이번 포스팅에서는 컨테이너 네트워킹에 대해 다뤄보겠습니다.

컨테이너는 물리 기기나 개념을 가상화하여 분리된 네트워킹 시스템을 만들어왔습니다.

물리적인 개념과 가상화된 내용을 비교하면서 Container Networking을 알아보도록 하겠습니다.

네트워크 스위칭과 라우팅, DNS, 네트워크 네임스페이스, 그리고 CNI까지 자세히 살펴보겠습니다.

Switch

네트워크 스위치는 동일한 네트워크 내에서 여러 장치를 연결하고,

각 장치 간의 데이터 전송을 효율적으로 관리하는 장치입니다.

스위치는 각 장치의 MAC 주소를 기반으로 데이터를 적절한 포트로 전달하여 네트워크 효율성을 높입니다.

네트워크 브리지는 여러 컴퓨터나 장치를 서로 연결해주는 장치로,

같은 네트워크 안의 여러 장치를 연결하여 데이터가 원활하게 오갈 수 있도록 돕는 장치입니다.

Pysical World

동일한 네트워크 상에 컴퓨터 A와 B가 있다고 가정해보겠습니다.

가령, 노트북과 데스크톱, 클라우드, VM 등이 될 수 있죠.

A와 B를 연결하려면 어떻게 해야 할까요?

두 시스템을 포함하는 네트워크를 생성하는 Switch로 두 시스템을 연결하면 됩니다.

Switch 에 각각 연결된 케이블이 필요하죠.

Container World

컨테이너도 동일합니다.

단, 두 개의 컨테이너의 네트워크를 연결하기 위해서 서로를 연결해줄 가상의 케이블 같은 게 필요합니다.

이 둘을 연결하려면 각 호스트에 네트워크 인터페이스가 필요합니다.

네트워크가 192.168.1.0 내 eth0 인터페이스를 스위치에 연결하는 데 사용한다고 해볼게요.

Switch

192.168.1.10 와 192.168.1.11 를 각 컴퓨터의 eth0에 할당합니다.

ip addr add 192.168.1.10/24 dev eth0
ip addr add 192.168.1.11/24 dev eth0

이렇게 eth0 에 특정 IP 주소로 주소를 할당시켜서 서로 통신할 수 있습니다.

여기서 스위치는 동일한 네트워크 내에서만 통신을 가능하게 합니다.

이번에는 서로 다른 네트워크 간의 통신을 고려해보도록 하겠습니다.

Router

다른 네트워크 192.168.2.0에 시스템 C와 D가 있다고 가정해보겠습니다.

- System C: 192.168.2.10

- System D: 192.168.2.11

현재 라우팅 설정을 확인하려면 route 명령어를 사용할 수 있습니다.

이 명령어는 커널의 라우팅 테이블을 출력합니다.

$ route
Kernel IP routing table
Destination     Gateway     Genmask     Flags Metric Ref    Use Iface

만약 라우팅 설정이 없다면, 시스템 B는 시스템 C에 접근할 수 없습니다.

이 경우, 시스템 B는 동일한 네트워크인 192.168.1.0에만 접근할 수 있습니다.

서로 다른 네트워크에 설치된 두 컴퓨터는 어떻게 연결할 수 있을까요?

Pysical World

두 네트워크를 연결하려면 Router가 필요합니다.

라우터는 서로 다른 네트워크를 연결하는 역할을 합니다.

전체 네트워크를 집으로 비유 하자면,

네트워크가 하나의 방이고 Switch는 그 방의 문입니다.

Router는 집과 밖을 연결하는 집의 문과 같습니다.

방에 있는 사람은 방문 (Switch)을 통해 거실로 나와 집문(Router)을 통해 집 밖으로 나가는 거죠.

Router

Container World

컨테이너에서도 동일합니다.

각 서버에 Gateway를 추가합니다.

외부 네트워크인 192.168.2.0에 접근하고 싶다면, 라우터에 아래와 같이 설정을 추가할 수 있습니다.

$ ip route add 192.168.2.0/24 via 192.168.1.1

시스템 B에서 라우팅 설정을 다시 확인해보겠습니다.

# System B's routing configuration

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags   Metric  Ref     Use Iface
192.168.2.0     192.168.1.1     255.255.255.0   UG      0       0           0 eth0

192.168.1.0 네트워크에서 Router로 가는 IP인 192.168.1.1 이 게이트웨이로 설정되었습니다.

이제 시스템 B에서 시스템 C로의 통신이 가능합니다.

하지만, 시스템 B에서 시스템 C로의 요청은 가능하지만, 시스템 C에서 시스템 B로의 응답을 받을 수는 없습니다.

이를 위해 시스템 C에서도 시스템 B로 접근하기 위한 설정이 필요합니다.

$ ip route add 192.168.1.0/24 via 192.168.2.1

시스템 C의 라우팅 설정을 확인해보겠습니다.

# System C's routing configuration

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags   Metric  Ref     Use Iface
192.168.1.0     192.168.2.1     255.255.255.0   UG      0       0           0 eth0

Internet

위 네트워크를 인터넷에 연결하려면 어떻게 해야할까요?

동일한 방법으로 Router에 Internet과 연결하도록 설정합니다.

인터넷에 연결할 새로운 라우팅 테이블을 추가하면 됩니다.

$ ip route add 172.217.194.0/24 via 192.168.2.1

이제, 시스템 A와 시스템 B는 인터넷과 연결되는 상태가 되었습니다.

Default Gateway

이렇게 설정할 때, 문제가 발생합니다.

모든 시스템에서 이를 설정해야 한다는 것입니다.

실제 인터넷에는 무수히 많은 네트워크가 존재하기 때문에

각 네트워크를 위해 모든 IP 주소를 라우팅 테이블에 추가하고, 각 라우팅 설정마다 한 IP를 각각 설정하는 대신,

단일 테이블 엔트리와 IP 주소들이 정의된 기본 게이트웨이를 생성하면 됩니다.

$ ip route add default via 192.168.2.1

모든 요청은 기본 라우터로 전달되어 외부의 어떤 네트워크로도 갈 수 있습니다.

Destination     Gateway         Genmask         Flags   Metric  Ref     Use Iface
default         192.168.2.1     0.0.0.0         UG      0       0           0 eth0
0.0.0.0         192.168.2.1     0.0.0.0         UG      0       0           0 eth0

기본 게이트웨이를 default 대신 0.0.0.0으로 명시되어 있는 경우를 확인할 수 있는데요.

Destination     Gateway     Genmask         Flags   Metric  Ref     Use Iface
192.168.2.1     0.0.0.0     255.255.255.0   UG      0       0           0 eth0

게이트웨이 필드가 0.0.0.0이라면, 게이트웨이를 통할 필요 없다는 의미입니다.

예를 들어, 한 시스템이 동일한 네트워크에 존재하는 다른 시스템에 접근하려고 하면,

자체 네트워크에 있기 때문에 게이트웨이가 필요하지 않습니다.

게이트웨이는 여러개 일 수 있습니다.

가령 하나는 인터넷과 연결된 라우터, 다른 하나는 내부 프라이빗 네트워크와 연결된 라우터가 있을 때,

각 네트워크를 위한 서로 다른 진입 경로를 설정합니다.

Linux Server - Router

가상의 라우터를 설정하는 방법에 대해 알아보겠습니다.

Linux 서버를 라우터로 사용하고 싶을 때, 설정하는 방법입니다.

실제로 아래의 명령어를 수행할 일이 없겠지만,

컨테이너 네트워크에 대한 이해를 위한 내용입니다.

A, B, C 세 호스트를 보면, A와 B는 192.168.1.0 네트워크에 연결돼 있고,

B와 C는 192.168.2.0 네트워크에 연결돼 있습니다.

호스트 B는 eth0와 eth1, 두 인터페이스를 통해 양쪽 네트워크에 연결되어 있습니다.
이 때, A에서 C로 연결하려고 하면 아래와 같은 오류가 발생합니다.

# Host A
$ ping 192.168.2.5
Connect: Network is unreachable

A가 C로 요청을 보내려고 할 때 어디를 통해서 가는 지를 모르기 때문이죠.

즉, A가 C로 갈 때 B를 거치라는 설정이 필요합니다.

이를 가능하게 하기 위해선 호스트 B를 통해 접근할 수 있으며, 그 과정은 아래와 같습니다.

STEP 1. 라우팅 설정: A → B → C

호스트 A에서 B로 패킷을 전송할 수 있게 설정합니다.

# command in Host A
$ ip route add 192.168.2.0/24 via 192.168.1.6

이제 호스트 A에서 호스트 B를 통해 호스트 C로 요청이 전달될 수 있습니다.

다음으로는, 호스트 C에서 호스트 A로 응답을 보내려면 연결할 수 있게 설정해야 합니다.

STEP 2. 라우팅 설정: C → B → A

이번엔 호스트 C에서 A로 패킷을 전달할 수 있게 설정해야 합니다.

# command in Host C
$ ip route add 192.168.1.0/24 via 192.168.2.6

이제 ping을 다시 해보면 전송은 되지만 응답을 받을 수는 없습니다.

이는 Linux에서 기본적으로 하나의 인터페이스에서 다른 인터페이스로 포워딩을 허용하지 않기 때문입니다.

즉, eth0 로 요청된 내용은 항상 eth0로만 반환되도록 설정되어 있습니다.

현재는 eth0 로 들어온 요청이 eth1으로 입력되려고 하고 있죠.

A에서 C로 갈 때는 인입이 eth0 으로 입력되었으므로,

C에서 A로 응답을 보내려고 할 때는 eth1로 나갈 수 있도록 설정이 필요합니다.

(시스템 B 기준으로 인입될 때만 해당됩니다)

STEP 2. Allow ip_forward

해당 설정을 허용하려면 /proc/sys/net/ipv4/ip_forward 설정을 변경해야 합니다.

$ cat /proc/sys/net/ipv4/ip_forward
0    ← No Forward

기본 설정값은 0입니다. 이를 1로 변경해야 합니다.

$ echo 1 > /proc/sys/net/ipv4/ip_forward
1

영구 설정을 위해서는 /etc/sysctl.conf 파일에 다음 라인을 추가합니다.

net.ipv4.ip_forward=1

이제 호스트 A에서 C로, 그리고 C에서 A로의 통신이 가능합니다.

그럼 지금까지 Container 네트워킹에 대해 알아보았습니다.

Kubernetes Storage, 제대로 이해하기

gngsn — Mon, 10 Jun 2024 00:00:00 +0900

본 포스팅에서는 Kubernetes의 저장소를 구성하는 방법인 PV & PVC 의 개념을 이해하고 적용할 수 있도록 하는 목표를 가집니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

쿠버네티스의 저장소에 대해서 알아보도록 하겠습니다.

Volumes

Pod는 내부에서 컨테이너 들이 실행되며, 서로 CPU, RAM, Network Interface 등 리소스를 공유합니다.

그렇다면, 파일 시스템도 동일할까요?

다른 리소스와 다르게, Pod 내부의 각 컨테이너는 각각의 분리된 파일 시스템을 가집니다.

컨테이너 마다의 파일 시스템은 컨테이너 이미지에서 제공하기 때문입니다.

Docker Volume과 동일하게,

쿠버네티스의 컨테이너 내 디스크에 있는 파일은 임시적입니다.

이미지 레이어으로 부터 Copy-On-Write 전략을 통한 컨테이너 레이어를 생성하기 때문이죠.

자세한 내용은 Docker Volume, 제대로 이해하기 를 참고하실 수 있습니다.

Pod 생명 주기 == Contianer Layer의 파일 생명 주기

컨테이너 레이어의 데이터는 수정할 수는 있지만 영구적으로 저장되지 않습니다.

이로 인해, 컨테이너가 크래시하면 파일이 손실되거나,

여러 컨테이너 간 파일 공유 불가능하다는 문제점이 있죠.

Kubernetes는 Volume을 통해 위 두 문제를 해결합니다.

Pod 생명 주기 ≠ Contianer Layer의 파일 생명 주기

쿠버네티스의 볼륨은 Pod의 구성요소로 컨테이너와 동일하게 Pod spec에서 정의됩니다.

볼륨은 Pod의 모든 컨테이너에서 사용 가능하지만 접근하려는 컨테이너에서 각각 마운트 되어야 합니다.

각 컨테이너의 어떤 경로에나 볼륨을 마운트할 수 있습니다.

예를 들어, 아래와 같이 볼륨을 정의하고 Pod에서 사용합니다.

apiVersion: v1
kind: Pod
metadata:
  name: volume-demo
spec:
  containers:
    - image: alpine
      name: alpine
      volumeMounts:
        - mountPath: /opt
          name: data-volume
  volumes:
    - name: data-volume
      hostPath:
        path: /data
        type: Directory

.spec.volumes 하위에 data-volume 볼륨을 정의하고,

.spec.containers.volumeMounts 를 통해 생성한 볼륨을 마운트합니다.

위 볼륨은 hostPath 타입으로, 호스트 노드의 파일 시스템과 Pod의 파일을 연결하는 볼륨 타입입니다.

단일 노드에서는 문제가 없지만, 다중 노드 클러스터에서는 권장되지 않습니다.

다중 노드에서는 각 서버, 즉 host가 다르기 때문에 데이터를 공유할 수 사용할 수 없기 때문이죠.

그럼, 어떤 Volume Types 들을 사용해야 할까요?

Volume Types

Kubernetes는 다양한 Volume Types을 제공합니다.

https://www.linkedin.com/posts/mmumshad_kodekloud-kubernetes-cloudcomputing-activity-7155899563218759680-QYWM/

자세한 내용은 공식 문서 - volume types 를 참고할 수 있으며, 간단히 훑어 보자면 아래와 같습니다.

- emptyDir: 일시적인 데이터를 저장하는 데 사용되는 간단한 빈 디렉터리
- hostPath: 워커 노드의 파일 시스템을 파드의 디렉터리로 마운트하는데 사용
- nfs: NFS 공유 파드에 마운트
- gcePersistentDisk(GCE Persistent Disk), awsElasticBlockStore(AWS EBS Volume), azureDist(MS Azure Disk Volume): 클라우드 제공자의 전용 스토리지를 마운트
- cinder, cephfs, iscsi, glusterfs, quobyte, rbd, flexVolume, vsphereVolume, photonPersistentDisk: 다른 유형의 네트워크 스토리지를 마운트
- configMap, secret, downwardAPI: 쿠버네티스 리소스나 클러스터 정보를 파드에 노출하는 데 사용되는 특별한 유형의 볼륨
- persistentVolumeClaim: 사전에 혹은 동적으로 프로비저닝된 퍼시스턴트 스토리지를 사용하는 방법

클라우드 사용하는 예를 들어보자면, AWS EBS를 사용하려면 다음과 같이 설정할 수 있습니다.

...
volumes:
  - name: data-volume
    awsElasticBlockStore:
      volumeID: <volume-id>
      fsType: ex4

Persistent Volumes

하지만 이렇게 매번 Pod 정의 파일에 Volume을 지정하면,

많은 포드를 배포할 때마다 각각의 Pod에 저장소를 구성해야 합니다.

변경 사항이 있을 때마다 모든 Pod에 수정 사항을 작성하는 대신, 중앙에서 관리하는 것이 더 효율적입니다.

Persistent Volume을 사용하여 큰 저장소 풀을 생성하고,

필요에 따라 각 Pod에서 이를 사용할 수 있도록 설정할 수 있습니다.

Kubernetes에서 Persistent Volumes(이하 Persistent Volumes / PV )를 설정하는 방법은 아래와 같습니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-vol1
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  hostPath:
    path: /tmp/data

PV 객체를 생성하기 위해 kubectl create 명령어를 사용할 수 있습니다.

❯ kubectl create -f pv-definition.yaml
persistentvolume/pv-vol1 created
❯ kubectl get persistentvolume
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pv-vol1   1Gi        RWO            Retain           Available                          <unset>

혹은, 외부 클라우드 저장소를 사용하려면 다음과 같이 설정할 수 있습니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-vol1
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  awsElasticBlockStore:
    volumeID: <volume-id>
    fsType: ext4

관리자가 Persistent Volume 이라는 스토리지 객체를 만들어 두면,

원하는 사용자(개발자)가 이를 가져다 사용할 수 있게 만들어 둡니다.

클러스터 내에서는 관리자에 의해 만들어진 Persistent Volume가 여러 개 존재할 수 있습니다.

그럼, 사용자는 어떤 Persistent Volume 를 사용하고 싶은지 요청을 해야하죠.

이를 Persistent Volume Claim을 통해 구현합니다.

일종의 스토리지 요청서와 같습니다.

Persistent Volume Claim

Persistenet Volume Claim 는 사용자가 요구하는 일종의 저장소 청구서입니다.

(이하 Persistenet Volume Claim / PVC )

비유를 해보자면, PVC는 Pod와 비슷한 개념으로,

Pod가 Node 리소스를 소비하는 것처럼,

PVC는 PV 리소스를 소비합니다.

Pod ⎯ request → Node Resources
PVC ⎯ request → PV

관리자는 Persistent Volume 세트를 만들고,

사용자는 해당 저장소를 사용하기 위해 persistent volume claims을 생성합니다.

Persistent Volume Claims 이 생성되면

쿠버네테스가 볼륨에 설정된 요청과 속성에 따라 claims 에 persistent volume을 묶습니다.

PVC는 특정 크기와 액세스 모드를 요청할 수 있습니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

위의 예시는 읽기 모드(ReadWriteOnce)로 설정 및 리소스를 설정해 500Mi의 저장 공간 요청합니다.

accessMode 는 아래 PV & PVC 섹션에서 다룹니다.

이후 kubectl get persistentvolumeclaim 명령어로 PVC를 생성합니다.

PVC를 생성하고 나서,kubectl get persistentvolumeclaim 명령어로 확인할 수 있습니다.

❯ kubectl create -f pvc-definition.yaml
persistentvolumeclaim/myclaim created

❯ kubectl get persistentvolumeclaim
NAME      STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
myclaim   Pending                                      standard       <unset>                 9s

이전에 생성한 PV의 accessModes가 일치하며, storage 용량이 충분하면 매칭됩니다.

PV & PVC

이 때, Persistent Volume 과 Persistent Volume Claim 은 어떻게 매칭될까요?

클레임은 특정 크기 및 액세스 모드를 요청할 수 있는데,

ReadWriteOnce, ReadOnlyMany, ReadWriteMany, ReadWriteOncePod 가 될 수 있습니다.

Access Modes

✔️ ReadWriteOnce

: RWO. 볼륨은 읽기/쓰기 모드에서 단일 작업자 노드로 적용 가능,

하나의 워커 노드에 마운트되면 다른 노드는 마운트할 수 없음

✔️ ReadOnlyMany

: ROX. 볼륨은 읽기 전용 모드로 여러 작업자 노드에 동시에 적용 가능

✔️ ReadWriteMany

: RWX. 볼륨은 동시에 여러 작업자 노드에 읽기/쓰기 모드로 적용 가능

✔️ ReadWriteOncePod

: RWOP. 하나의 Pod만 읽기/쓰기 모드로 적용 가능, Kubernetes 1.22+ 버전부터 지원

PVC은 단 하나의 PV에 묶이게 됩니다.

바인딩 과정에서 쿠버네티스는 사용자의 요청 만큼 PV가 충분한 용량을 가졌는지 확인하는데요.

용량 뿐만 아니라, Sufficient Capacity, Access Modes, Volume Modes, Storage Class 등을 체크합니다.

PVC가 생성되면, Kubernetes는 설정된 요청과 속성에 따라 PV를 매칭합니다.

모든 PVC는 단일 PV로 매칭되며, 매칭 조건이 맞으면 바인딩됩니다.

사용 가능한 PV가 없으면, PVC는 보류 상태로 대기합니다.

Kubernetes in Action

PVC를 Pod, ReplicaSets, Deployments에 정의하여 사용할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
        - mountPath: "/var/www/html"
          name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

이와 같이 설정하면, Pod가 PVC를 통해 PV를 사용하게 됩니다.

만약, 단일 클레임에 매치 가능한 게 여러 개 있는데,

특정 볼륨을 지정하고 싶다면 Label을 사용할 수 있습니다.

마지막으로, 다른 모든 매칭 조건이 일치하고 더 나은 옵션이 없는 경우, 더 작은 Claim이 더 큰 Volume 으로 묶일 수 있습니다.

Claim과 Volume 은 일대일 관계이기 때문에, 다른 클레임은 볼륨의 남은 용량을 활용할 수 없습니다.

Delete PVC

PVC를 삭제하려면 kubectl delete 명령어를 사용합니다.

❯ kubectl delete persistentvolumeclaim myclaim

이 때, PVC 가 삭제되면 PV는 어떻게 될까요?

기본 값은, PV는 유지되고 관리자에 의해 삭제될 때까지 유지됩니다.

이 설정은 변경할 수 있는데요.

PersistentVolumeReclaimPoliy를 설정하여 PVC 삭제 후 PV를 관리 정책을 설정합니다.

PersistentVolumeReclaimPolicy

kubernetes.io - Persistent Volumes: Reclaiming

PVC가 삭제된 후 PV를 어떻게 처리할지는 persistentVolumeReclaimPolicy에 정의할 수 있습니다.

- Retain: 기본값. PV가 유지되며 관리자가 수동으로 삭제할 때까지 남아 있습니다.

- Delete: PVC가 삭제되는 순간 PV도 자동으로 삭제됩니다.

- Recycle: Deprecated. 기본 스크럽을 수행하고 새 클레임에 대해 다시 사용할 수 있도록 합니다.

⚠️ The Recycle reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.

CSI - Container Storage Interface

CSI Spec

CSI는 컨테이너 스토리지 관리를 위한 API 공통 사양을 정의입니다.

다양한 컨테이너 오케스트레이션 시스템에서 호환성을 유지하기 위해 만들어졌습니다.

Kubernetes는 CSI를 구현하여 기본 스토리지 인프라에 대한 특정 지식 없이도 스토리지 볼륨을 관리할 수 있습니다.

쿠버네티스 CSI은 기본적으로 프로비저너(Provisioner), 어태쳐(Attacher), 컨트롤러(Controller), 노드서버(NodeServer)로 이루어져 있습니다.

Provisioner

프로비저너는 클러스터에 PVC가 생성되는 걸 모니터링하고 있다가 PVC가 생성되면 PV를 생성하는 걸 담당합니다.

Attacher

어태처는 파드가 PVC를 사용하려할 때 해당 컨테이너에서 PV를 마운트하는 걸 담당합니다.

Controller

컨트롤러는 쿠버네티스 컨테이너에서 사용할 볼륨을 스토리지 서버에서 생성 및 삭제하는 걸 담당합니다.

NodeServer

노드서버는 파드가 배포될 노드에서 스토리지 볼륨에 마운트할 수 있게 환경을 만드는 걸 담당합니다.

Storage Class

Static Provisioning Volumes

위 방식에서는 PV 를 작성하고, PVC를 생성한 후, Pod 에 사용할 PVC를 명시하는 과정을 거쳤습니다.

하지만, 여전히 실제 스토리지를 미리 프로비저닝 해야하는 번거로운 작업이 필요합니다.

가령 Google Cloud에 연결한다고 하면,

1. PV를 생성하기 전에 Google Cloud에서 디스크를 먼저 생성하고

2. 저장소가 필요할 때마다 Google Cloud에서 수동으로 디스크를 프로비저닝해야 하며,

3. 생성한 디스크와 같은 이름을 사용하여 수동으로 PersistentVolume 정의 파일을 만들어야 합니다.

지금까지 살펴본 내용,

즉 PV를 정의해서 PVC에 명시해 사용하는 방식을 Static Provisioning Volumes라고 합니다.

Dynamic Provisioning

쿠버네티스는 PV의 동적 프로비저닝(Dynamic Provisioning)을 지원합니다.

덕분에 이 일련의 작업을 자동으로 수행할 수 있습니다.

관리자가 PV를 생성하는 대신 PV 프로비저너(Provisioner)를 배포하고,

사용자가 선택 가능한 PV 타입을 하나 이상의 Storage Class(SC) 객체로 정의할 수 있습니다.

사용자가 PVC에서 PV가 아닌 StorageClass를 참조하면,

Provisioner가 퍼시스턴트 스토리지를 프로비저닝할 때 이를 자동으로 처리합니다.

사실 대부분의 클라우드에서 Provisioner를 포함하는데,

덕분에 PVC에서 StorageClass만 정의하면 클레임 요청시 시스템이 알아서 PV를 생성합니다.

이제 PV를 직접 생성할 필요가 없습니다.

StorageClass에 의해 자동으로 생성됩니다.

PersistentVolume 을 정의하는 대신 StorageClass를 정의

StorageClass를 정의하게 되면 아래의 순서로 실제 Pod에 매핑됩니다.

StorageClass → PersistentVolumeClaim

PVC에서 정의한 StorageClass를 이름을 지정합니다.

그래야 PVC가 어떤 StorageClass를 사용할지 알 수 있습니다.

PersistentVolumeClaim → Pod
PVC가 생성되면, StorageClass는 정의된 프로비저너를 통해 요청된 사이즈에 맞게 디스크를 프로비저닝합니다.

그 다음 PersistentVolume을 생성해 그 볼륨에 PVC를 묶습니다.

⚠️ 수동으로 PV를 생성할 필요는 없지만, 여전히 StorageClass에 의해 PV가 생성됩니다.

쿠버네티스에서는 AWS EBS, Azure File, Azure Disk, CephFS, Portworx, ScaleIO 같은 다양한 프로비저너를 사용할 수 있습니다.

각 프로비저너에 추가적인 매개 변수를 전달할 수 있습니다.

예를 들어, 프로비저닝 디스크 유형이나 복제 유형 등을 지정할 수 있습니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: google-storage
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
  replication-type: none

Google Persistent Disk에서는 표준 또는 SSD로 유형을 지정할 수 있습니다.

각각 다른 유형의 디스크를 사용하여 다양한 StorageClass를 만들 수 있습니다.

가령,
- 표준 Disk인 silver StorageClass

- SSD 드라이브가 포함된 gold StorageClass

- SSD 드라이브 및 복제가 포함된 platinum StorageClass

StorageClass

이렇게 다양한 서비스 클래스를 만들 수 있기 때문에 StorageClass라고 합니다.
다음에 PVC를 생성할 때, 필요한 저장소 클래스를 지정하기만 하면 됩니다.

| Reference |

Kubernetes.io - Official Docs

Udemy: certified-kubernetes-administrator-with-practice-tests

Docker Series

gngsn — Tue, 4 Jun 2024 00:25:41 +0900

Docker Deep Dive 시리즈 를 이곳에서 확인할 수 있습니다.

Docker Series

Docker Engine, 제대로 이해하기 (1) - docker engine deep dive

Docker Engine, 제대로 이해하기 (2) - namespace, cgroup

Docker Network, 제대로 이해하기 (1) - libnetwork

Docker Network, 제대로 이해하기 (2) - bridge, host, none drivers

Docker, 제대로 사용하기 - Commands

Docker Volume, 어렵지 않게 이해하기

Docker Volume, 제대로 이해하기

gngsn — Mon, 3 Jun 2024 23:59:51 +0900

Storage in Docker

Docker가 로컬 파일 시스템에 데이터를 저장하는 방식에 대해 알아보겠습니다.

Docker의 파일 시스템 구조

도커를 처음 설치하면 /var/lib/docker 폴더가 생성되며, 다양한 하위 폴더들이 포함됩니다.

/var/lib/docker
├─ aufs
├─ containers
├─ image
└─ volumes

이 폴더들 하위에는 Docker 호스트에서 실행되는 이미지나 컨테이너와 관련된 데이터들이 저장됩니다.

Docker Layered architecture

Docker는 이미지를 구축할 때 레이어드 아키텍처를 사용합니다.

Dockerfile를 빌드할 때 각 지시문마다의 레이어를 생성합니다.

각 지시어마다 레이어가 생성되고 사이즈가 측정됨

한 번 빌드된 레이어는 수정할 수 없으며, 새로운 빌드를 통해 재정의해야 합니다.

각 이전 레이어에서 변경된 부분에 한해 새로운 레이어를 생성하는데,

레이어들은 각 명령어의 변화와 크기를 반영하게 됩니다.

가령, 4번 째 줄부터 변경사항이 있는 아래 파일을 빌드하면,

동일한 지시어는 Cache 된 레이어 사용

변하지 않은 첫 3줄에 대해서는 캐시된 레이어를 재사용하여 빌드 속도와 이미지 사이즈 면에서 큰 효율을 가져옵니다.

이렇게 빌드된 이미지를 실행하면,

새로운 컨테이너 레이어가 이미지 레이어 위에 생성됩니다.

컨테이너 레이어는 쓰기 가능 (R/W) 하며, 컨테이너에 의해 생성된 데이터(로그 파일, 임시 파일 등)를 저장할 수 있습니다.

하지만 이런 파일들은 도커의 Copy-On-Write 전략으로 컨테이너가 살아있는 동안에만 유지됩니다.

Copy-On-Write Strategy

Copy-On-Write (aka. CoW) 는 쓰기 권한이 필요하면 복사본을 제공하는 전략입니다.

파일 혹은 디렉터리가 특정 레이어에 존재하고,

다음 계층에서 해당 파일의 편집 권한이 필요하다면 기존 파일을 복사해 편집할 수 있도록합니다.

이미지를 구축하거나 컨테이너를 실행할 때 파일은 해당 계층으로 복사됩니다.

이를 통해 I/O와 하위 계층 각각의 크기를 최소화할 수 있죠.

이미지 레이어의 복사 파일로 컨테이너 데이터 초기화

즉, 컨테이너는 이미지 레이어에서 복사해온 파일들로 초기화됩니다.

이후 복사본들에 접근하여 수정 하는 구조입니다.

컨테이너에서 수정해도 원본인 이미지 레이어의 읽기 전용 파일은 절대 수정할 수 없죠.

컨테이너 제거 시, 컨테이너 레이어의 모든 데이터가 삭제

컨테이너를 제거하면 컨테이너 레이어의 모든 데이터가 삭제됩니다.

그런데, 만약 데이터를 영구적으로 유지하고 싶다면 어떻게 해야 할까요?

Volumes

컨테이너 데이터를 영구적으로 저장하려면 Volume(이하 볼륨)을 사용해야 합니다.

먼저 볼륨을 생성합니다.

$ docker volume create data_volume

docker volume을 실행하면 /var/lib/docker/volumes 하위에 디렉터리가 생성됩니다.

/var/lib/docker
├─ aufs
├─ containers
├─ image
└─ volumes
   └─ data_volume

이후, 컨테이너 실행 시 docker run -v 명령어로 볼륨을 마운트합니다.

마운트를 하는 방법은 Volume Mounting 과 Bind Mounting 두 가지로 구분할 수 있습니다.

✔️ Volume Mounting

-v 옵션을 사용하여 볼륨을 마운트합니다.

$ docker run -v data_volume:/var/lib/mysql mysql

생성한 호스트 내의 data_volume 볼륨에 지정된 위치와 컨테이너 내의 /var/lib/mysql 이 마운트됩니다.

Volume Mounting

위 명령어를 실행하면, MySQL 데이터베이스의 모든 데이터는 Docker 호스트에 생성된 볼륨에 저장됩니다.
더 이상 컨테이너 레이어의 복사본을 사용하지 않아, 컨테이너가 파괴되어도 데이터는 유지됩니다.

볼륨 마운팅이라고 말해서 어려워 보일 수 있지만 사실상 두 디렉터리를 연결한 것이죠.

컨테이너 내에 저장하는 대신 호스트 디렉터리에 바로 저장해 컨테이너 생명 주기에 영향을 받지 않게 합니다.

이후 생성되는 컨테이너도 /var/lib/docker/volumes/data_volume 에 접근하면 이전 컨테이너와 동일한 파일을 참조하겠죠.

✔️ Bind Mounting

원하는 호스트 파일의 절대 경로를 사용해서 기존의 저장소 폴더를 마운트합니다.

$ docker run --mount type=bind,source=/data/mysql,target=/var/lib/mysql mysql

마찬 가지로 MySQL 데이터베이스의 모든 데이터가 Docker 호스트에 사용자가 지정한 특정 디렉토리에 저장됩니다.

Storage Drivers

Docker Storage Drivers

이상적으로는 컨테이너의 컨테이너 레이어에 데이터를 기록하지 않고,

도커 볼륨을 사용하여 데이터를 작성하는 것이 이상적입니다.

하지만, 일부 워크로드에서는 컨테이너 레이어에 데이터를 작성해야 합니다.

이 때 스토리지 드라이버가 사용합니다.

도커는 여러 개의 Storage Driver를 플러그인 형식으로 지원합니다.

Storage Driver는 이미지와 컨테이너가 도커 호스트에서 저장되고 관리되는 방식을 제어합니다.

스토리지 드라이버 개요를 읽은 후 다음 단계는 워크로드에 가장 적합한 스토리지 드라이버를 선택하는 것이다.

가장 일반적인 시나리오에서 전체 성능과 안정성이 가장 우수한 스토리지 드라이버를 사용한다.
도커 엔진은 리눅스에서 다음과 같은 스토리지 드라이버를 제공합니다:

Docker는 여러 종류의 스토리지 드라이버를 지원합니다.

Overlay2	- 현재 지원되는 리눅스 배포판에서 지원하는 가장 선호되는 스토리지 드라이버 - 추가 구성 필요 없음
fuse-overlays	- Rootless overlay를 지원하지 않는 호스트 상의 Rootless Docker 를 실행하기 위해서만 선호됨 - Ubuntu 및 Debian 10 에서 사용될 필요가 없음 - overlay2는 Rootless 모드에서도 동작 - Rootless Mode Documentation 참조
BTRFS / ZFS	- "스냅샷"을 만드는 것과 같은 고급 옵션을 허용하지만 더 많은 유지보수와 설정이 필요 - 각각 올바르게 구성하기 위한 backing filesystem에 의존함
VFS	- vfs 스토리지 드라이버는 테스트나 Copy-On-Write 시스템에 적합하지 않는 상황을 위해서만 사용 - 성능이 좋지 않고 일반적으로 프로덕션 용으로 권장되지 않음

이 외에도 AUFS, BTRFS, Device Mapper 가 있습니다.

참고로, Ubuntu의 기본 스토리지 드라이버는 AUFS입니다.

Fedora나 CentOS는 AUFS를 지원하지 않으므로, 호환 문제가 생길 경우 Device Mapper를 사용하는 것이 좋습니다.

Kubernetes Cluster Upgrade, 제대로 이해하기

gngsn — Wed, 24 Apr 2024 13:19:55 +0900

본 포스팅에서는 Kubernetes 클러스터를 업그레이드하는 방법에 대해 이해하는 목표를 가집니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

Versioning

Kubernetes releases

쿠버네티스는 표준 소프트웨어 릴리스 버전 관리 절차를 따릅니다.

쿠버네티스의 첫 번째 Major 버전인 1.0 은 2015년에 발표되었고, 최근 버전은 1.30 (2024-04-17) 입니다.

Semantic Versioning

: MAJOR.MINOR.PATCH

MAJOR version
: when you make incompatible API changes

MINOR version
: when you add functionality in a backward compatible manner. features / functionalities 단위

PATCH version
: when you make backward compatible bug fixes

MINOR 버전은 몇 달마다 새로운 feature 와 functionality 출시하며

PATCH 버전은 버그를 수정하며 더 자주 업데이트합니다.

쿠버네티스는 몇 달에 한 번씩 소규모 릴리스를 통해 새로운 피처와 기능을 발표합니다.

kubectl get nodes 명령을 실행하면 설치한 쿠버네티스 클러스터를 특정 버전을 확인할 수 있습니다.

❯ kubectl get nodes
NAME                 STATUS   ROLES           AGE   VERSION
kind-control-plane   Ready    control-plane   58d   v1.29.2
node01   Ready    <none>   58d   v1.29.2

위에서는 1.29.2 버전을 사용하고 있다는 것을 알 수 있습니다.

위 버전 말고도, Alpha와 Beta가 릴리즈 됩니다.

|
* v1.10.0 (March 2018)
|\
| * v1.10.0-beta
| |
| |
| * v1.10.0-alpha
|/
|

모든 버그를 고치고 개선하면 먼저 alpha 태그를 부착한 Alpha를 릴리즈 합니다.
기본적으로 Alpha는 기능이 비활성화되어 있으며 버그가 존재할 수 있습니다.

그 다음 코드를 잘 테스트하면 Beta 릴리스로 넘어가고, 새 기능이 디폴트로 활성화됩니다.
그리고 마지막으로, 최종적으로 안정적인 상태 를 릴리즈합니다.

GitHub Repository Release.

페이지를 확인해보면 쿠버네티스를 tar 파일로 다운로드할 수도 있습니다.

추출해보면 해당 쿠버네티스 버전에 해당하는 컴포넌트가 존재하는데, 모든 컴포넌트가 모두 같은 버전으로 포함되어 있습니다.

Upgrade Process

Upgrading kubeadm clusters

쿠버네티스 Control Plane (이하 컨트롤 플레인) 컴포넌트는 각각의 버전을 갖습니다.

또한, 컴포넌트 중엔 Etcd 클러스터나 CoreDNS 같이 외부 컴포넌트 종속성을 가진 컴포넌트도 존재하며,

이 경우 자체 프로젝트의 버전을 가집니다.

이 외 컨트롤 플레인의 주요 컴포넌트 대부분 동일한 버전이겠지만,

모두 동일한 버전을 갖는 게 의무는 아니며, 개별 업그레이드를 할 수도 있습니다.

Supported versions

하지만 각 컨트롤 플레인 컴포넌트는 서로 의존하기 때문에,

개별 업데이트 시 제한을 가집니다.

먼저, kube-apiserver는 컨트롤 플레인의 주요 구성요소이면서,

다른 구성요소들과 통신하는 구성요소이기 때문에,
어떤 다른 구성요소도 kube-apiserver보다 높은 버전으로 되어 있어서는 안됩니다.
controller-manager와 kube-scheduler는 kube-apiserver 보다 한 버전까지 더 낮출 수 있습니다.

즉, kube-apiserver 버전이 X라면
controller-manager나 kube-scheduler는 X-1 버전까지 호환 가능하며,
kubelet과 kube-proxy 는 X-2 버전까지 호환 가능합니다.

가령, kube-apiserver 버전이 v1.10라면
controller-manager 나 kube-scheduler는 v1.9 혹은 v1.10 버전이어야 하고,
kubelet과 kube-proxy 는 v1.8, v1.9, v1.10 중 한 버전이어야 함

이때, kube-apiserver 는 kubectl 에 의존하기 때문에

kubectl 는kube-apiserver 보다 높은 버전인 v1.11 이나 v1.12, v1.13 중 하나여야 합니다.

기본적으로, 쿠버네티스는 업그레이드 시 최근 세 개의 minor 버전까지만 지원합니다.

쿠버네티스가 v1.13 을 출시하면서 v1.12, v1.11 및 v1.10까지만 지원한다는 의미입니다.

반대로 생각해보면, 현재 버전이 v1.10이라면, 쿠버네티스는 버전 v1.13 까지 업그레이드 할 수 있다는 말이죠.

권장하는 업데이트 방식은, 한 번에 마이너 버전 하나씩 업그레이드하는 것입니다.

❌ v1.10 → v1.13
✅️ v1.10 → v1.11 → v1.12 → v1.13

실제 AWS 에서는 단 하나의 마이너 버전만을 업그레이드하게끔 제한합니다.

Upgrade Strategy

Upgrade Kubelet And Kubectl

쿠버네티스를 업그레이드 하는 방법은 어떻게 설치되어 있느냐에 따라 달라집니다.

✔️ Cloud Service: Provider

GKE (Google Kubernetes Engine), EKS (Elastic Kubernetes Service), AKS (Azure Kubernetes Service) 와 같은 클라우드 서비스는 업그레이드를 지원합니다. 따라서 아주 간편하게 버튼 클릭 만으로 업그레이드를 실행할 수 있습니다.

✔️ kubeadm

쿠버네티스 커뮤니티에서 직접 관리되는 툴로, 간편하게 클러스터를 설치하고 업그레이드를 할 수 있습니다.

아래에서 자세히 다뤄볼 예정입니다.

✔️ Manual Installation

직접 하나씩 설치해서 업그레이드 하는 방식입니다.

`kubeadm`

간략히 말해보자면, kubeadm을 통한 업그레이드는

kubeadm upgrade plan 와 kubeadm upgrade apply 명령어를 통해 간편하게 업그레이드 할 수 있습니다.

지금부터 한 클러스터를 업그레이드 한다고 가정해봅시다.

production 환경에 클러스터가 있고, 클러스터의 major 버전을 두 번 업그레이드 해야 합니다.

이 클러스터는 master node(이하 마스터 노드) 와 worker node(이하 워커 노드)를 가지고 있습니다.

Master
Node Node 1 Node 2 Node 3
v1.10 v1.10 v1.10 v1.10

클러스터 업그레이드는 크게 두 가지 단계로 이루어집니다.

1. 마스터 노드 업그레이드

2. 워커 노드 업그레이드

#1. Upgrading Master Node

먼저, 마스터 노드를 업그레이드 합니다.

Master
Node Node 1 Node 2 Node 3
v1.10 v1.10 v1.10 v1.10

마스터 노드가 업그레이드되는 동안 컨트롤 플레인의 컴포넌트가 잠시 다운됩니다.

kube-apiserver, kube-scheduler, kube-controller-manager 등

하지만, 마스터 노드가 다운된다고 해서 클러스터 내의 워커 노드와 앱이 영향을 받는 건 아닙니다.
워커 노드에 호스트된 모든 작업은 평소처럼 사용자들에게 제공됩니다.

다만, 마스터가 다운됐으니 관리 기능도 다운됩니다.

kube-controller-manager도 작동 하지 않기 때문에,

kubectl이나 다른 쿠버네티스 API를 통해 클러스터에 액세스할 수 없습니다.
즉, 새 앱을 배포하거나 기존 앱을 삭제, 수정할 수 없습니다.

결론적으로, Pod가 고장 나면 새 포드가 자동으로 생성되지 않겠지만,
노드와 포드가 작동하는한 앱은 실행되고 사용자는 영향을 받지 않습니다.

업그레이드가 완료되면 클러스터가 백업되고 이후 정상 작동합니다.

Master
Node Node 1 Node 2 Node 3
v1.11 v1.10 v1.10 v1.10

마스터 노드의 버전이 v1.11 로 업데이트 되었습니다.
이제, 워커 노드를 업그레이드할 차례입니다.

#2. Upgrade Worker Node

워커 노드는 세 가지의 다양한 업그레이트 방식이 있습니다.

✔️ Strategy 1. Upgrade All of Them At Once

첫 번째는 한번에 모두 업그레이드합니다.

Master
Node Node 1 Node 2 Node 3
v1.11 v1.10 v1.10 v1.10

업그레이드가 완료되면 노드가 백업되고, 새 Pod가 스케줄링 된 후 사용자가 다시 접근할 수 있습니다.

하지만 Pod가 한번에 모두 다운되는 다운타임을 발생시키는 전략입니다.

잠시동안 사용자가 앱에 접속할 수 없습니다.

✔️ Strategy 2. Upgrade One Node At a Time

두 번째 전략은, 한 번에 노드 하나씩 업그레이드합니다.

Master + +
Node Node 1 Node 2 Node 3
v1.11 v1.10 v1.10 v1.10

첫 번째 노드를 업그레이드 할 때, Pod가 두 번째와 세 번째 노드로 이동합니다.

첫 번째 노드가 업그레이드 된 후, 두 번째 노드를 업데이트합니다.

Master
Node   Node 1           Node 2      Node 3
v1.11        v1.11 v1.10    v1.10

첫 번째와 세 번째 노드로 Pod가 이동합니다.
마지막으로, 세 번째 노드가 업데이트 될 때, 이전과 마찬가지로 다른 노드로 Pod가 이동합니다.

✔️ Strategy 3. Add New Nodes to the Cluster

세 번째 전략은 클러스터에 새로운 소프트웨어 버전을 가진 노드를 추가합니다.

Master
Node Node 1 Node 2 Node 3 Node 4
v1.11 v1.10 v1.10 v1.10 v1.11

Pod을 새 노드로 옮기고 옛 노드를 제거합니다.

Master
Node ~~Node 1~~ Node 2 Node 3 Node 4
v1.11 ~~v1.10~~ v1.10 v1.10 v1.11

해당 방식은 클라우드 환경에서 특히 편리합니다.

새 노드를 프로비전하고 오래된 걸 해체할 수 있기 때문입니다.

새 소프트웨어 버전의 노드로 모두 교체될 때까지 진행합니다.

Hands-on Upgrade

kubeadm에는 클러스터 업그레이드를 돕는 명령이 있습니다.

kubeadm upgrade plan 명령을 실행하면 많은 정보를 얻을 수 있습니다.

❯ kubeadm upgrade plan
...
[upgrade/versions] Cluster version: v1.28.0
[upgrade/versions] kubeadm version: v1.28.0
...
COMPONENT   CURRENT       TARGET
kubelet     2 x v1.28.0   v1.28.9

Upgrade to the latest version in the v1.28 series:

COMPONENT                 CURRENT   TARGET
kube-apiserver            v1.28.0   v1.28.9
kube-controller-manager   v1.28.0   v1.28.9
kube-scheduler            v1.28.0   v1.28.9
kube-proxy                v1.28.0   v1.28.9
CoreDNS                   v1.10.1   v1.10.1
etcd                      3.5.9-0   3.5.9-0

You can now apply the upgrade by executing the following command:

        kubeadm upgrade apply v1.28.9

Note: Before you can perform this upgrade, you have to update kubeadm to v1.28.9.
...

현재 클러스터 버전, kubeadm 버전, 모든 컨트롤 플레인 컴포넌트의 각 버전,

또 Target Version (업데이트 가능한 어떤 버전) 보여줍니다.

⚠️ 단, kubeadm은 kubelet을 업데이트 시키지 않습니다.

1. upgrade kubeadm

Installing kubeadm

먼저, 클러스터를 업데이트하려면 kubeadm 툴 자체를 업그레이드 해야합니다.

kubeadm 업데이트를 진행합니다.

❯ apt-get upgrade -y kubeadm=1.12.0-00
...
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.12.0". Enjoy!
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.

-y option: Automatic yes to prompts; assume "yes" as answer to all prompts and run non-interactively.

kubeadm 버전을 v1.11.0 에서 v1.12.0으로 업그레이드합니다.

이후 클러스터를 해당 커맨드를 통해 업그레이드합니다.

❯ kubeadm upgrade apply v1.12.0

명령이 완료되면 컨트롤 플레인의 구성요소는 1.12로 변경됩니다.
하지만, kubectl get nodes 명령어로 확인해보면, 아직 버전이 1.11이 것을 볼 수 있습니다.

이유는 API 서버 자체의 버전이 아니라 API 서버에 등록된 각 노드들의 kubelet 버전을 보여주기 때문입니다.

2. upgrade kubelet

다음 단계는 마스터 노드에 있는 kubelet 업그레이드합니다.

여러분의 setup에 따라 마스터 노드에서 kubelet이 실행될 수도 아닐 수도 있습니다.

이 경우 kubeadm과 함께 배포된 클러스터는 마스터 노드에 kubelet가 있는데, 컨트롤 플레인 컴포넌트를 실행하는 데 사용됩니다.

apt-get 업그레이드 kubelet 명령을 실행합니다.

❯ apt-get upgrade -y kubelet=1.12.0-00

패키지가 업그레이드 되고 난 후, kubelet 서비스를 다시 시작합니다.

❯ systemctl restart kubelet

kubectl get nodes 명령을 실행하면 마스터가 v1.12.0로 업그레이드 됩니다.

❯ kubectl get nodes
NAME    STATUS  ROLES   AGE   VERSION
master  Ready   master  1d
node-1  Ready   <none>  1d  v1.11.3 
node-2  Ready   <none>  1d  v1.11.3

3. upgrade worker nodes

다음 단계는 워커 노드 업그레이드합니다.

한 노드 씩 작업을 위해 Pod를 이동시켜야 합니다.

kubectl drain 명령어로 노드에서 모든 Pod를 안전하게 종료하 다른 노드의 일정을 재조정할 수 있습니다.

❯ kubectl drain node-1

그 다음, 워커 노드에서 kubeadm과 kubelet 패키지 업그레이드합니다.

❯ apt-get upgrade -y kubeadm=1.12.0-00
❯ apt-get upgrade -y kubealet=1.12.0-00
❯ kubeadm upgrade node config --kubelet-version v1.12.0
❯ systemctl restart kubelet

그런 다음 kubeadm 도구 업그레이드 명령을 이용해 새 kubelet 버전을 위해 노드 구성을 업데이트합니다.
이후 kubelet 서비스 다시 시작합니다.

이제 노드는 새 소프트웨어 버전(v1.12)과 함께 재생성 됩니다.

하지만 노드에 Pod를 없앨 때 Unscheduleable 표시를 했는데요.

kubectl uncordon 명령어를 통해 다시 스케줄링 가능한 상태로 변경해야합니다.

❯ kubectl uncordon node-1

하지만 이는 단지 Schedule 가능하다는 표시를 한 거지,

Pod가 이 노드로 바로 돌아온다는 걸 의미하진 않습니다.

이렇게 모든 노드를 업그레이드 하면 업그레이드가 끝납니다.

그럼 여기까지, 쿠버네티스 업그레이드 방법에 대해 알아보았습니다.

| Reference |

Kubernetes.io - Official Docs

Udemy: certified-kubernetes-administrator-with-practice-tests

Kubernetes Series

gngsn — Tue, 16 Apr 2024 23:38:55 +0900

Kubernetes Deep Dive 시리즈 작성중입니다.

모든 게시글은 이곳에서 확인할 수 있습니다.

Kubernetes Series

K8s Architecture, 제대로 이해하기

Kubernetes Architecture, 제대로 이해하기 - Control Plane

Kubernetes Architecture, 제대로 이해하기 - Worker Node

Kubernetes Deployment, 제대로 이해하기

Kubernetes Taints & Tolerations, 제대로 이해하기

Kubernetes Affinity, 제대로 이해하기

Kubernetes Scheduler, 제대로 이해하기

Kubernetes Resource & Limit, 제대로 이해하기

Kubernetes DaemonSet, 제대로 이해하기

Kubernetes Static Pods, 제대로 이해하기

Kubernetes ConfigMap & Secret, 제대로 이해하기

Kubernetes Storage, 제대로 이해하기

FYI.

Container Networking, 어렵지 않게 이해하기

Kubernetes ConfigMap & Secret, 제대로 이해하기

gngsn — Tue, 16 Apr 2024 23:29:28 +0900

본 포스팅에서는 Kubernetes의 환경변수를 구성하는 방법인 ConfigMap & Secret 의 개념을 이해하고 적용할 수 있도록 하는 목표를 가집니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

쿠버네티스를 사용하면서, 환경에 따라 다르거나 자주 변경되는 설정 옵션들을,

실행되는 애플리케이션 코드와 분리시키고 싶을 때가 생깁니다.

환경 변수를 정의하면서 이를 해결할 수 있는데요.

본 포스팅에서는 쿠버네티스에서 환경변수를 설정할 수 있는

총 세가지의 방법을 소개해드리고자 합니다.

Environment Variables

Official: Configuration

Container Runtime 중 대표적인 Docker에서 환경변수를 입력할 수 있습니다.

Dockerfile에서 ENV 지시자를 통해 환경변수를 정의할 수 있는데요.

ENV MY_NAME="John Doe"
ENV MY_DOG=Rex\ The\ Dog
ENV MY_CAT=fluffy

혹은, Command Line에서 실행 시 옵션 값으로 입력할 수도 있습니다.

docker run -e <<ENV_KEY>>=<<ENV_VALUE>> <<container_name>>
# ex> docker run -e DEMO_GREETING="Hello from the environment" my-app

Kubernetes 에서도 이처럼 환경 변수를 지정할 수 있습니다.

각각의 Pod에 환경변수를 지정해주는 것이죠.

아래와 같이 세 개의 방식을 통해 환경 변수를 지정할 수 있습니다.

✔️ Plain Key Value

✔️ ConfigMap

✔️ Secrets

하나씩 살펴보도록 하겠습니다.

#1. Plain Key Value

가장 간단한 방식으로 환경 변수를 설정하기 위한 속성을 직접 Pod 정의 파일에 정의합니다.

이때, Pod 정의 파일 내 spec.containers[].env 속성을 사용할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: print-greeting
spec:
  containers:
  - name: env-print-demo
    image: bash
    env:
    - name: GREETING
      value: "Warm greetings to"
    - name: HONORIFIC
      value: "The Most Honorable"
    - name: NAME
      value: "Kubernetes"
    - name: MESSAGE
      value: "$(GREETING) $(HONORIFIC) $(NAME)"
    command: ["echo"]
    args: ["$(MESSAGE)"]

env 속성은 배열 타입으로, 하위에 각 name과 value 리스트를 명시합니다.

env[].name: 환경 변수 이름

env[].value: 해당 환경 변수 값

이 때, ConfigMap Key는 DNS subdomain 상 유효한 값이어야 합니다.
가령, alphanumeric characters, dashes, underscores, dots 등을 포함하며,

유효하지 않은 값들이 무엇인지 살펴볼 필요가 있습니다.
혹은 선택적으로 Key는 leading dot (ex. .local.test.com)이 포함될 수 있습니다.

쉽고 간단히 사용할 수 있지만,

여러 Pod에 지정하거나 정의하고자 하는 환경 변수가 많아질 수록,

한 파일에 여러 환경 변수를 관리하기 어려워집니다.

혹은, 조금 더 독립적으로 정의하고 싶을 때가 생깁니다.

그럴 땐, ConfigMap이나 Secret의 값을 가져올 수 있습니다.

#2. ConfigMap

환경 변수를 Pod 정의 파일에서 분리해 Configuration Map 형식으로 중앙 관리할 수 있습니다.

ConfigMap은 쿠버네티스에서 Key-Value 쌍의 Config 데이터를 전달하는 데 사용합니다.

Pod는 ConfigMap을 이름으로 참조하기 때문에,

모든 Pod 스펙을 동일하게 사용하면서 각 환경에서 다른 구성을 사용할 수 있습니다.

ConfigMap 객체 생성을 위해서는 아래 두 단계를 진행합니다.

STEP 1. Create ConfigMap

STEP 2. Inject into Pods

STEP 1. Create ConfigMap

첫째, ConfigMap을 생성합니다.

다른 쿠버네티스 객체와 동일하게, Imperative 혹은 Declarative 방법으로 생성 가능합니다.

1. Imperative: kubectl create

첫 번째로, Key-Value 를 Command Line에 바로 입력하여 적용할 수 있습니다.

사용할 수 있는 옵션들에 대해 미리 살펴보면 아래와 같습니다.

kubernetes in action

$ kubectl create configmap my-config
    --from-file=foo.json                     ❶
    --from-file=bar=foobar.conf              ❷
    --from-file=config-opts/                 ❸
    --from-literal=some=thing                ❹

❶ 단일 파일
❷ 특정 키에 파일에 지정된 값 바로 입력
❸ 디렉터리 하위 전체
❹ 리터럴: 값 직접 입력

하나씩 살펴보도록 하겠습니다.

✔️ --from-literal

--from-literal 옵션을 사용하면 원하는 환경 변수 key-value 값을 입력할 수 있습니다.

❯ kubectl create configmap \
     <<config-name>> --from-literal=<key>=<value>

가령, 아래처럼 적용할 수 있습니다.

❯ kubectl create configmap myconfigmap \
    --from-literal=foo=bar --from-literal=bar=baz --from-literal=one=two
configmap/myconfigmap created

여러 개의 옵션을 사용하고 싶다면, 위 처럼 --from-literal 옵션을 여러 번 사용할 수 있습니다.

실제 생성된 ConfigMap 객체를 확인해보면, data 섹션에서 해당 데이터를 확인할 수 있습니다.

❯ kubectl get configmap myconfigmap -o yaml
apiVersion: v1
data:
  bar: baz
  foo: bar
  one: two
kind: ConfigMap
metadata:
  creationTimestamp: "2024-04-16T12:42:36Z"
  name: myconfigmap
  namespace: default
  resourceVersion: "1248496"
  uid: 25cc5f7e-e228-4d13-b8bf-662a1ff1b316

✔️ --from-file

--from-literal 옵션을 사용하면 명령줄이 길어질 수 있는데,

이때 --from-file 옵션을 통해 파일을 명시할 수 있습니다.

❯ kubectl create configmap \
     <<config-name>> --from-file=<path-to-file>

이 때, 인자 값으로는 위에서 보았듯이, 단일 파일 혹은 디렉터리를 입력할 수 있습니다.

미리 생성해둔 파일을 명시합니다.

❯ kubectl create configmap fortune-config \
	--from-file=my-nginx-config.conf \
	--from-file=sleep-interval=sleep-interval-config.conf
configmap "fortune-config" created

실제 생성된 데이터를 확인해보면 다음과 같습니다.

❯ kubectl get configmap fortune-config -o yaml
apiVersion: v1
data:
  my-nginx-config.conf: |
    server {
      listen              80;
      server_name         www.kubia-example.com;

      gzip on;
      gzip_types text/plain application/xml;

      location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
      }
    }
  sleep-interval: |
    5
kind: ConfigMap
metadata:
  creationTimestamp: "2024-04-16T13:30:13Z"
  name: fortune-config
  namespace: default
  resourceVersion: "1251054"
  uid: 371cfd85-873c-4bb9-98a4-8c943f2f9979

2. Declarative: kubectl apply

혹은, 미리 정의해둔 파일을 kubectl apply 등 명령어를 통해 생성할 수 있습니다.
ConfigMap 정의 파일은 보통 객체 정의에서 보았던 spec 대신 data 속성을 포함합니다.

# config-map.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_COLOR: blue
  APP_MODE: prod

Config 파일 이름 지정해서 kubectl 명령 실행합니다.

kubectl apply -f config-map.yaml

그럼 쿠버네티스는 지정한 ConfigMap 값으로 환경 변수를 생성합니다.

FYI. View ConfigMaps

ConfigMap을 확인하고 싶다면, kubectl get configmaps 명령 실행합니다.

혹은, 단축어로 kubectl get cm을 사용할 수 있습니다.

❯ kubectl get configmaps
NAME                          DATA   AGE
app-config                    2      5s
kube-root-ca.crt              1      48d

더 자세한 내용을 보기 위해선, kubectl describe configmaps 명령 실행해서 상세 확인이 가능합니다.

Data 섹션 하위에 지정한 환경 변수를 확인할 수 있습니다.

❯ kubectl describe configmaps
Name:         app-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
APP_COLOR:
----
blue
APP_MODE:
----
prod

BinaryData
...

STEP 2. Inject into Pod

정의를 했다면, 이제 Pod에 적용할 환경변수를 지정합니다.

이때, 환경 변수를 지정하는 방식에는 세 가지가 존재합니다.

✔️ 첫 번째, envFrom - ConfigMapRef

...
spec:
  containers:
  - name: something
    ...
    envFrom:
      - configMapRef:
        name: app-config

.spec.containers[] 하위에 envFrom[].configMapRef 로 이미 생성해둔 ConfigMap 을 참조합니다.

envFrom 속성은 Array 타입으로 다중의 환경 변수를 전달할 수 있습니다.

✔️ 두 번째, ConfigMap entry 값을 Env에 직접 정의

...
spec:
  containers:
  - image: something
    env:
    - name: INTERVAL            # 정의할 ENV 이름
      valueFrom:
        configMapKeyRef:
          name: fortune-config  # ConfigMap 이름
          key: sleep-interval   # ConfigMap Entry Key 값
...

미리 정의해둔 ConfigMap에 정의된 속성 중 원하는 값을 Key으로 참고해 다른 ENV 이름으로 정의합니다.

다소 복잡해보일 수 있는데, 아래 그림이 이해에 도움이 될 듯 합니다.

✔️ 세 번째, Volume 지정

...
spec:
  containers:
  - image: nginx:alpine
    name: web-server
    volumeMounts:
    ...
    - name: config
      mountPath: /etc/nginx/conf.d  # configMap volume 에 마운팅할 포인트 지정
      readOnly: true
    ...
  volumes:
  ...
  - name: config
    configMap:                      # ConfigMap 리스트 중,
      name: fortune-config          # fortune-config 객체를 들고옴

파일을 볼륨에 입력한 후, 마운팅 포인트에서 해당 값을 참조합니다.

추가 옵션:

.spec.containers[].volumeMounts[].readOnly = true

#3. Secrets

하지만, ConfigMap만으로 모든 요구사항을 채우기 어렵습니다.

간혹, 애플리케이션에서 직접 입력할 수 없는 Secret 값을 설정해야합니다.

예를 들어, Database Host, User, Password 등을 설정할 때 어떻게 설정해야 할까요?

ConfigMap은 일반 텍스트 형식으로 구성 데이터를 저장하기 때문에 적절하지 않습니다.

이때, Secret 사용 - 비밀번호나 Key 등 민감한 정보를 저장하는 데 활용할 수 있습니다.

값은 아래와 같이 인코딩된 형식으로 저장됩니다.

DB_Host: RvEtdlSw=
DB_User: THevDhS==
DB_Password: aHrGgsdJ

이렇게 인코딩되어 저장된다는 점만 제외하고는,

ConfigMap 와 거의 동일한 방식으로 설정할 수 있습니다.

ConfigMap 와 마찬가지로 Secret 구성은 두 단계로 구성됩니다.

STEP 1. Create Secret

STEP 2. Inject into Pods

STEP 1. Create Secret

가령, 아래와 같은 설정 값을 Secret으로 저장한다고 가정해봅시다.

DB_Host: mysql
DB_User: root
DB_Password: paswrd

ConfigMap 과 동일하게 Imperative 와 Declarative 방식으로 생성할 수 있습니다.

1. Imperative

kubectl create secret generic 명령어를 통해 Secret 지정 가능합니다.

kubectl create secret generic \
    <secret-name> --from-literal=<key>=<value>

예를 들면, 아래와 같이 정의할 수 있습니다.

kubectl create secret generic \
    app-secret --from-literal=DB_Host=mysql \
               --from-literal=DB_User=root \
               --from-literal=DB_Password=paswrd

혹은 --from-file 옵션으로 파일을 지정할 수 있습니다.

kubectl create secret generic \
    <secret-name> --from-file=<path-to-file>

가령 아래와 같이 정의할 수 있습니다.

kubectl create secret generic \
    app-secret --from-file=app_secret.properties

모든 내용은 ConfigMap에서 지정한 내용과 동일하게 적용할 수 있기 때문에,

--from-literal 과 --from-file 부분은 ConfigMap의 Step 1 섹션을 참고해주시길 바랍니다.

2. Declarative

혹은, 미리 정의해둔 파일을 kubectl apply 등 명령어를 통해 생성할 수 있습니다.
Secret 정의 파일은 보통 객체 정의에서 보았던 spec 대신 data 속성을 포함합니다.

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
    DB_Host: bXlzcWw=
    DB_User: cm9vdA==
    DB_Password: cGFzd3Jk

Secret 은 민감한 데이터를 저장하기 위해 사용되어 인코딩된 포맷으로 저장합니다.

명령적 방식 Secret을 생성하려면 인코딩된 형식의 Secret 값을 지정해야 합니다.

일반 텍스트에서 인코딩된 형식으로 데이터를 변환하려면 echo -n '<<string>>' | base64 입력할 수 있습니다.

❯ echo -n 'mysql' | base64
bXlzcWw=
❯ echo -n 'root' | base64
cm9vdA==
❯ echo -n 'paswrd' | base64
cGFzd3Jk

위와 같이 정의한 후, 아래 명령어를 통해 Secret 객체를 생성합니다.

kubectl create -f secret-data.yaml

FYI. View Secrets

secret을 확인을 위해서는 kubectl get secrets 명령어 사용합니다.

❯ kubectl get secrets
NAME                                         TYPE                 DATA   AGE
app-secret                                   Opaque               3      4s
Name:         app-secret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
DB_Host:      5 bytes
DB_Password:  6 bytes
DB_User:      4 bytes

값을 보고 싶다면, YAML 포맷으로 확인할 수 있습니다.

❯ kubectl get secrets app-secret -o yaml
apiVersion: v1
data:
  DB_Host: bXlzcWw=
  DB_Password: cGFzd3Jk
  DB_User: cm9vdA==
kind: Secret
metadata:
  name: app-secret
  namespace: default
...

인코딩의 반대로, 디코딩을 하고 싶다면 --decode 옵션을 추가해서 확인할 수 있습니다.

❯ echo -n 'bXlzcWw=' | base64 --decode
mysql
❯ echo -n 'cm9vdA==' | base64 --decode
root
❯ echo -n 'cGFzd3Jk' | base64 --decode
paswrd

STEP 2. Inject into Pod

Pod에 생성한 Secret을 입력하는 방법은 ConfigMap과 동일합니다.

✔️ 첫 번째, envFrom - ConfigMapRef

.spec.containers[] 하위에 envFrom[].secretRef 로, 이미 생성해둔 Secret 을 참조합니다.

envFrom 속성은 Array 타입으로 다중의 환경 변수를 전달할 수 있습니다.

...
spec:
  containers:
  - name: something
    ...
    envFrom:
      - secretRef:
        name: app-secret

configMapRef 과 비교해보면 configMapRef 이 secretRef 로만 변경되었습니다.

✔️ 두 번째, Secret entry 값을 Env에 직접 정의

...
spec:
  containers:
  - image: something
    env:
    - name: DB_Password            # 정의할 ENV 이름
      valueFrom:
        secretKeyRef:
          name: app-secret         # Secret 이름
          key: DB_Password         # Secret Entry Key 값
...

미리 정의해둔 Secret 에 정의된 속성 중 원하는 값을 Key으로 참고해 다른 ENV 이름으로 정의합니다.

다소 복잡해보일 수 있는데, 아래 그림은 ConfigMap이지만 동일한 구조이기 때문에,

이해에 도움을 드리고자 첨부했습니다.

✔️ 세 번째, Volume 지정

apiVersion: v1
kind: Pod
metadata:
  name: secret-dotfiles-pod
spec:
  volumes:
    - name: secret-volume
      secret:                             # Secret 객체 리스트 중,
        secretName: dotfile-secret        # dotfile-secret 객체를 들고옴
  containers:
    - name: dotfile-test-container
      image: registry.k8s.io/busybox
      command:
        - ls
        - "-l"
        - "/etc/secret-volume"
      volumeMounts:
        - name: secret-volume
          readOnly: true
          mountPath: "/etc/secret-volume"  # Secret volume 에 마운팅할 포인트 지정

파일을 볼륨에 입력한 후, 마운팅 포인트에서 해당 값을 참조합니다.

추가 옵션:

.spec.containers[].volumeMounts[].readOnly = true

⚠️ Caution

kubenetes - Secret

Kubernetes Secret은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장됩니다.
암호화되어 있지 않기 때문에, 누구든 기밀문서로 만든 파일을 볼 수 있고 Secret 을 얻을 수 있습니다.

가령, API 액세스 권한이 있는 사람이나 etcd에 대한 액세스 권한이 있는 사람은

누구나 Secret을 검색하거나 수정할 수 있습니다.

또한, 네임스페이스에 Pod를 생성할 권한이 있는 사람은 누구나

해당 액세스 권한을 사용하여 해당 네임스페이스에 있는 보안 비밀을 읽을 수 있습니다.

Secret을 안전하게 사용하려면 최소한 다음을 고려해야 합니다.

- 비밀에 대한 저장 데이터 암호화를 활성화.

- 보안 비밀에 대한 최소 권한 액세스로 RBAC 규칙을 활성화하거나 구성.

- 특정 컨테이너에 대한 Secret 액세스 제한

- 외부 Secret Store Providers 사용 고려: AWS Provider, Azure Provider, GCP Provider, Vault Provider

그럼 여기까지, 쿠버네티스의 Secret에 대해 알아보았습니다.

| Reference |

Kubernetes.io - Official Docs

Kubernetes in Action by Marko Luksa

Udemy: certified-kubernetes-administrator-with-practice-tests

Kubernetes RollingUpdate & Rollbacks, 제대로 이해하기

gngsn — Sun, 7 Apr 2024 23:59:44 +0900

본 포스팅에서는 Kubernetes의 RollingUpdate의 개념을 이해하는 목표를 가집니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

지난 포스팅에서 Deployment에 대해 알아보았습니다.

다시 짚어보자면, Deployment는 이름 그대로, 쿠버네티스에서 배포를 위한 객체입니다.

기능적으로는, Pod와 ReplicaSet를 배포를 관리합니다.

이번 포스팅에서는 배포 이후의 업데이트 과정을 다뤄보겠습니다.

앱 버전 1을 배포한 상태에서 버전 2로 업데이트할 때를 생각해보겠습니다.

5개의 Pod가 떠 있는 상태에서 해당 Pod 를 어떻게 교체해야 할까요?또, 교체되는 과정이 어떻게 될지 살펴보도록 하겠습니다.

Rollout

Deployment를 생성하면, Deployment는 새로운 배포 Revision을 생성합니다.

이후, 새로운 버전을 배포하고자 Deployment를 수정하면,

Deployment 생성을 시작하고, 이는 새 배포에 대한 Revision을 생성합니다.

덕분에 배포 변화를 추적할 수 있을 뿐만 아니라,

필요 시 이전 배포 버전으로 쉽게 되돌릴 수 (Rollback) 있습니다.

Deployment Strategy

배포 방법에는 2가지가 존재합니다.

첫 번째, Recreate

: 배포된 모든 앱 제거 후, 새로운 버전 앱 한 번에 생성

가령, 배포된 이전 앱 5개를 모두 지우고 난 후,

새로운 앱 5개를 새로 띄우는 것입니다.

️ ️ Old Version ⬆️️ ⬆️️ ⬆️️ ⬆️

⬇️ ⬇️ ⬇️ ⬇️ New Version

하지만, 이 방식엔 문제가 있습니다.

모든 배포 앱을 다운시키고 나서 새로운 앱이 업로드 될 때까지 사용자의 접근이 불가합니다.

무중단 배포 (Zero Downtime Deployment)가 불가한 상황입니다.

개발자들은 사용자들이 해당 앱을 항상 사용가능하게 만들게끔 하고 싶죠.

동시에, 새로운 버전을 하루에도 여러 번 배포할 수 있게 하고자 합니다.

쿠버네티스에서는 이를 RollingUpdate 로 해결합니다.

두 번째, Rolling Update

: 제거 및 생성을 부분적으로 점차 진행

Deployment 생성 시 디폴트 배포 전략입니다.

Rolling Update는 현재 배포된 버전의 Pod를 새로운 Pod로 점진적으로 교체합니다.
새로운 Pod는 리소스가 유효한 노드에 예약되어,

이전 Pod를 제거하기 전에 새로운 Pod가 시작되기를 기다립니다.

구 버전을 부분적으로 내려, 그 만큼의 새 버전을 배포하며,

️ ️ ⬆️️ ⬆️️

⬇️ ⬇️

모두 새 버전이 될 때까지 반복합니다.

️ ️
️ ️   ⬆️️ ⬆️️

⬇️ ⬇️

앱이 다운되지 않고 업데이트 가능하죠.

좌측 상단 부터 1, 2, 3, 4 / https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/

쿠버네티스에서는 업데이트가 버전화되고 배포 업데이트는 이전(안정적) 버전으로 되돌릴 수 있습니다.

롤링 업데이트를 통해 다운타임 없이 배포 업데이트를 수행할 수 있습니다.

RollingUpdate Strategy

위의 두 전략은 Deployment 정의 시 .spec.strategy.type에 지정합니다.

즉, .spec.strategy.type 필드에 Recreate 또는 RollingUpdate를 입력할 수 있으며, "RollingUpdate"가 기본값입니다.

⚠️ .spec.strategy 이전 포드를 새 포드로 대체하는 데 사용되는 전략을 지정합니다.

만약 RollingUpdate 를 지정했을 시,

maxUnavailable 과 maxSurge를 설정해 롤링 업데이트 과정을 설정할 수 있습니다.

기본적으로 업데이트 중에 이용 불가한 Pod의 최대 개수 (maxUnavailable) 와,

한 번에 생성 가능한 새로운 Pod의 최대 수 (maxSurge)는 한 개 입니다.

두 옵션 모두 숫자 또는 백분율(Pods) 로 설정할 수 있습니다.

Max Unavailable

: 업데이트 중, 이용 불가한 Pod의 최대 개수

.spec.strategy.rollingUpdate.maxUnavailable 은 업데이트 프로세스 중에 사용할 수 없는 최대 파드의 수를 지정하는 선택적 필드입니다.

해당 값은 5와 같이 특정 개수를 명시하거나, 10%와 같이 비율로 기입할 수 있습니다.

기본 값은 25% 입니다. 즉 75%의 Pod는 사용을 보장받는 것이죠.

만약, .spec.strategy.rollingUpdate.maxSurge 가 0이면 값이 0이 될 수 없습니다.

가령 30%로 설정 하면 RollingUpdate 시작 시,

이전 ReplicaSet의 크기를 즉각적으로 Desired Pod의 70%로 Scale Down할 수 있습니다.

새 Pod가 준비되면 기존 ReplicaSet을 Scale Down할 수 있으며,

업데이트 중에 항상 사용 가능한 전체 Pod의 수는 새로운 Pod 수의 70% 이상이 되도록 새 레플리카셋을 Scale Up할 수 있습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 1

Max Surge

: 업데이트 중, 새로 추가되는 최대 파드 수

.spec.strategy.rollingUpdate.maxSurge 는 의도한 파드의 수에 대해

생성할 수 있는 최대 파드의 수를 지정하는 필드입니다.

해당 값은 5와 같이 특정 개수를 명시하거나, 10%와 같이 비율로 기입할 수 있습니다.

MaxUnavailable 값이 0이면 이 값은 0이 될 수 없으며, 기본 값은 25% 입니다.

예를 들어 이 값을 30%로 설정하면 RollingUpdate 시작시,

새 ReplicaSet의 크기를 즉시 조정해서 기존 혹은 새 Pod의 전체 갯수를 의도한 Pod의 130%를 넘지 않도록 합니다.

기존 파드가 죽으면 새로운 ReplicaSet은 Scale Up할 수 있으며,

업데이트하는 동안 항상 실행하는 총 Pod의 수는 최대 의도한 Pod의 수의 130%가 되도록 보장합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 1

Applying

위의 변경된 내용을 기반으로 Deployment를 업데이트하는 방법은 두 가지가 존재합니다.

첫 번째, 필요한 내용 수정 후 kubectl apply 명령어로 변경 사항 반영할 수 있습니다.

❯ kubectl apply -f deployment-definition.yml

새로운 Rollout이 트리거되고, Deployment의 새로운 Revision 가 생성됩니다.

두 번째, 필요한 내용 수정 후 kubectl set image 명령 사용할 수 있습니다.

❯ kubectl set image deployment/myapp-deployment nginx-container=nginx:1.9.1
# kubectl set image ≪deployment-name≫ ≪container-name≫

Application의 이미지를 업데이트를 함으로써 해당 변경을 적용합니다.

이 방식은 배포 정의 파일의 구성을 달라지게 하기 때문에,

정의 파일을 유지하고 싶을 때에는 주의해야 합니다.

Update

그렇다면, 실제 Update 시 Pod 들에 어떤 변화가 있을까요?

결론적으로, 쿠버네티스 Deployment 객체가 내부적으로 새 ReplicaSet을 만들고 컨테이너를 배포하기 시작합니다.

가령, 새로운 앱 5개를 배포한다고 할 때, 먼저 자동으로 ReplicaSet를 생성하고,

이후 ReplicaSet에 따라 여러 개의 Pod가 생성됩니다.

실제 업데이트를 진행하다 보면, Events 로그에서 업데이트가 다르게 변하고 있음을 확인할 수 있는데요.

실제 Deployment를 두 가지 Strategy로 생성한 후, 업데이트를 했을 때의 로그를 확인해보도록 하겠습니다.

Recreate Events

❯ kubectl describe deploy webapp-recreate
Name:               webapp-recreate
...
Selector:           name=webapp
Replicas:           4 desired | 4 updated | 4 total | 0 available | 4 unavailable
StrategyType:       Recreate
MinReadySeconds:    0
Pod Template:
  Labels:  name=webapp
  Containers:
   nginx:
    Image:        nginx:1.14.3
    Port:         80/TCP
    Host Port:    0/TCP
...
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  4s     deployment-controller  Scaled down replica set webapp-recreate-54f8cdd695 to 0 from 4
  Normal  ScalingReplicaSet  4s     deployment-controller  Scaled up replica set webapp-recreate-7bb89cfdbb to 4

ScalingReplicaSet 으로 Pod를 0에서 4로 즉시 올리는 것을 확인할 수 있습니다.

Rolling Update Events

❯ kubectl describe deployment
Name:                   webapp-rollingupdate
Namespace:              default
...
Replicas:               4 desired | 2 updated | 5 total | 3 available | 2 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  name=webapp
  Containers:
   nginx:
    Image:        nginx:1.24.0
    Port:         80/TCP
....
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  2m17s  deployment-controller  Scaled up replica set webapp-rollingupdate-54f8cdd695 to 4
  Normal  ScalingReplicaSet  3s     deployment-controller  Scaled up replica set webapp-rollingupdate-b5bc55fdd to 1
  Normal  ScalingReplicaSet  3s     deployment-controller  Scaled down replica set webapp-rollingupdate-54f8cdd695 to 3 from 4
  Normal  ScalingReplicaSet  3s     deployment-controller  Scaled up replica set webapp-rollingupdate-b5bc55fdd to 2 from 1

ScalingReplicaSet 으로 ScaleUp/Down을 점진적으로 진행하는 것을 확인할 수 있습니다.

Rollout

마지막으로, 아래 명령어를 통해 Rollout 정보를 얻을 수 있습니다.

1. Rollout 상태 확인

❯ kubectl rollout status deployment/myapp-deployment
Waiting for deployment "myapp-deployment" rollout to finish: 2 out of 4 new replicas have been updated...

2. Rollout 내역 확인

❯ kubectl rollout history deployment/myapp-deployment
deployment.apps/myapp-deployment 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>

Rollback

업데이트 이후 새로운 버전에서 문제를 발견하면 어떻게 될까요?

쿠버네티스 Deployment는 이전 Revision으로의 롤백 지원합니다.

kubectl rollout undo 명령어 뒤 배포 이름을 명시해서 롤백할 수 있습니다.

❯ kubectl rollout undo deployment/myapp-deployment

새 ReplicaSet의 Deployment는 새 ReplicaSet의 Pod를 파괴하고,

이전 버전 ReplicaSet의 예전 Pod를 불러옵니다.

실제 kubectl get replicasets 명령어를 확인해보면,

다시 이전 버전의 Pod가 4개로 늘어난 것을 확인할 수 있습니다.

frontend-54f8cdd695 가 구버전, frontend-7bb89cfdbb가 신버전입니다.

❯ kubectl get replicasets
NAME                  DESIRED   CURRENT   READY   AGE
frontend-54f8cdd695   0         0         0       4m57s
frontend-7bb89cfdbb   4         4         4       4m19s

해당 앱은 이전 버전으로 돌아갑니다.

❯ kubectl get replicasets
NAME                  DESIRED   CURRENT   READY   AGE
frontend-54f8cdd695   4         4         4       4m57s
frontend-7bb89cfdbb   0         0         0       4m19s

Kubernetes DaemonSet, 제대로 이해하기

gngsn — Mon, 1 Apr 2024 13:19:55 +0900

본 포스팅에서는 Kubernetes의 DaemonSet의 개념을 이해하는 목표를 가집니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

DaemonSets

DaemonSet은 일부 혹은 모든 노드에 동일한 Pod (copy of a Pod) 가 하나씩 실행되도록 보장합니다.

클러스터에 새 노드가 추가될 때마다 Pod 복제본이 자동으로 해당 노드에 추가되고,

노드가 제거되면 Pod는 Garbage Collection의 대상이 되어 자동으로 제거됩니다.

대부분의 일반적인 경우엔,

ReplicaSet과 Deployment을 통해 여러 Worker Node에서 애플리케이션을 복제하면서,

Cluster 내 다양한 노드에 다양한 포드를 배포할 수 있었습니다.

Before Deployment

Node 1 Node 2 Node 3 Node 4

는 각 Node에 위치한 Pod를 의미합니다.

DaemonSet 은 ReplicaSet 와 비슷하게 여러 개의 인스턴스 Pod를 배포할 수 있게 하는데,

클러스터의 노드마다 단 하나의 Pod를 실행합니다.

After Deployment

⚫️    ⚫️ ⚫️ ⚫️


Node 1    Node 2 Node 3 Node 4

⚫️ 는 각 Node에 위치한 DaemonSet Pod를 의미합니다.

DaemonSet은 Pod의 복제본을 클러스터 내 모든 노드에 항상 존재하게 합니다.

일반적으로, DaemonSet는 다음과 같은 용도로 사용되곤 합니다.

✔️ 모든 노드에서 실행되는 클러스터 스토리지

✔️ 모든 노드에서 실행되는 로그 수집

✔️ 모든 노드에서 실행되는 노드 모니터링

단순하게, 모든 노드에 존재하는 하나의 DaemonSet가 여러 타입의 daemon 처리를 위해 사용되곤 합니다.

더 복잡한 설정을 위해, 하나의 데몬 처리를 위해 여러 DaemonSet을 사용할 수 있지만,

각 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라집니다.

Use cases

1. Monitoring or Logs Viewer

데몬셋을 활용할 수 있는 아주 적합한 예시들이 존재하는데요.

바로, Monitoring 과 Logs Viewer입니다.

Monitoring 에이전트나 Logs Collector를 클러스터 내 각 노드에 배포하면,

데몬셋은 모든 노드에 한 Pod로 배치하기 때문에 최적입니다.

클러스터에 변화 생기면, 데몬셋이 알아서 제거/추가하기 때문에 따로 관리할 필요가 없습니다.

2. kube-proxy

kube-proxy 는 DaemonSet의 좋은 예시입니다.

kube-proxy 구성 요소는 클러스터에서 DaemonSet으로 배포될 수 있습니다.

3. Networking

weave-net 같은 네트워킹 솔루션은,

해당 에이전트가 클러스터 내 각 노드에 배치되어야 하기 때문에 데몬셋을 활용하기 적합합니다.

DaemonSet Definition

데몬셋을 생성은 ReplicaSet 생성 정의와 비슷합니다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: monitoring-daemon
spec:
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      containers:
      - name: monitoring-agent
        image: nginx

ReplicaSet의 selector에 지정한 레이블(.spec.selector.matchLabels)과,

Pod template 하위의 레이블이 일치하는지 확인 필요합니다.

Command

정의한 파일을 기반으로 DaemonSet을 생성해보겠습니다.

✔️ 1. kubectl create 명령어로 DaemonSet 생성

❯ kubectl create -f daemon-set-definition.yaml
daemonset.apps/monitoring-daemon created

✔️ 2. kubectl get 명령어로 DaemonSet 조회

❯ kubectl get daemonsets
NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
monitoring-daemon   1         1         1       1            1           <none>          2m21s

✔️ 3. kubectl describe 명령어로 DaemonSet 상세 조회

❯ kubectl describe daemonsets monitoring-daemon                                                                                                                ─╯
Name:           monitoring-daemon
Selector:       app=monitoring-agent
Node-Selector:  <none>
Labels:         <none>
Annotations:    deprecated.daemonset.template.generation: 1
Desired Number of Nodes Scheduled: 1
Current Number of Nodes Scheduled: 1
Number of Nodes Scheduled with Up-to-date Pods: 1
Number of Nodes Scheduled with Available Pods: 1
Number of Nodes Misscheduled: 0
Pods Status:  1 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=monitoring-agent
  Containers:
   monitoring-agent:
    Image:        nginx
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                  Message
  ----    ------            ----  ----                  -------
  Normal  SuccessfulCreate  3m7s  daemonset-controller  Created pod: monitoring-daemon-vtnsp

How does DaemonSet work?

DaemonSet 은 어떻게 동작할까요?

어떻게 모든 노드에 포드가 있는지 보장할 수 있을까요?

클러스터의 각 노드에 포드를 지정해야 한다면, Node Affinity 를 사용할 수 있습니다.

혹은, 각 Pod의 스팩 정의에 nodeName 속성 설정할 수도 있습니다.

Affinity:  Node 1    Node 2   Node 3   Node 4
              ⚫️      ⚫️       ⚫️       ⚫️
              ↓       ↓️        ↓       ↓️
               ️       ️                
            Node 1   Node 2   Node 3   Node 4

쿠버네티스 버전에 따라 동작에 조금 차이가 있습니다.

< v.1.12: Pod가 생성될 때 각 노드에 자동 배치

>= v.1.12: NodeAffinity + default scheduler

조금 더 자세한 내용은 How Daemon Pods are scheduled 을 참고 하시길 바랍니다.

그럼 여기까지, 쿠버네티스의 DaemonSets에 대해 알아보았습니다.

| Reference |

Kubernetes.io - Official Docs

Udemy: certified-kubernetes-administrator-with-practice-tests

Kubernetes Resources, 제대로 이해하기

gngsn — Mon, 1 Apr 2024 12:34:15 +0900

본 포스팅에서는 Kubernetes의 Resources 를 제한하고 보장받을 양을 지정하는 방법을 익힙니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

Resource Management

for Pods and Containers

모든 Pod를 운영하려면 자원이 필요하며,

모든 노드엔 사용 가능한 CPU와 메모리 리소스를 가지고 있습니다.

쿠버네티스 스케줄러는 Pod에 요구되는 리소스 양을 고려하여,

노드에서 사용 가능한 리소스에 따라 Pod가 배치될 최적의 노드를 결정합니다.

이때, 노드에 배치할 Pod를 지정 시, 컨테이너에 필요한 각 리소스의 양을 선택적으로 지정할 수 있는데요.

대표적인 리소스에는, CPU와 메모리(RAM) 등이 있습니다.

CPU / Memory
Pod A:

Node1 [ ]
Node2 [ ]
Node3 [ ]

위의 예시의 경우, Pod A이 요구하는 사항 ( : 3, : 3) 을 만족하는 Node2 혹은 Node3에 배치될 수 있겠죠.

Request & Limit

리소스에 대해서 request 와 limit 값을 지정할 수 있는데요.

request

Pod에서 컨테이너에 대한 리소스 요구 사항(request )을 지정하면,

kube-scheduler는 이를 보장하여 배치될 노드를 결정합니다.

kubelet이 컨테이너가 사용할 해당 시스템 리소스의 최소 request 양을 예약해둡니다.

가령, 컨테이너에 256MiB의 memory request 를 설정하고,

8GiB의 메모리를 가진 노드로 배치될 Pod 내에 해당 컨테이너가 있으며,

다른 파드는 없는 경우 컨테이너는 더 많은 RAM을 사용할 수 있습니다.

Memory
Pod 1️⃣: Requests

Node1 [ ]
Node2 [ ]
Node3 [ ]

Pod 1️⃣은 Node2, Node3 에 배치될 수 있습니다.

limit

컨테이너에 대한 리소스 제한(limit)을 지정하면,

kubelet은 실행 중인 컨테이너가 설정한 제한보다 많은 리소스를 사용할 수 없도록 합니다.

가령, 컨테이너에 4GiB의 memory lmit을 설정하면, kubelet (& Container Runtime)이 제한을 적용합니다.

Container Runtime은 컨테이너가 해당 리소스 제한을 초과하지 못하게 합니다.

Before
Node [ ]
Pod 1️⃣ 의 Limit

After
Node [ ]
1️⃣: ← ❌

Pod 1은 Node에 자원이 남아있어도, 3 이상 사용할 수 없습니다.

limit은 두 가지 방식으로 구현할 수 있습니다.

- reactively: 반응적. 시스템이 위반을 감지한 후에 개입

- enforcement: 강제적. 시스템이 컨테이너가 제한을 초과하지 않도록 방지

⚠️ limit은 지정하고 request은 지정하지 않는 경우,
해당 리소스에 대한 요청 기본값을 지정하는 admission-time mechanism이 없다면,
limit을 복사하여 해당 리소스의 request 값으로 사용합니다.

컨테이너 프로세스가 허용된 양보다 많은 메모리를 사용하려고 하면,

시스템 커널은 메모리 부족(out of memory, OOM) 오류와 함께 할당을 시도한 프로세스를 종료합니다.

노드에 충분한 리소스가 없으면,

스케줄러는 해당 노드에 Pod를 두는 걸 피하고 리소스가 충분히 사용 가능한 곳에 배치합니다.

모든 노드에 사용 가능한 리소스가 충분하지 않으면 스케줄러가 Pod의 스케줄링을 보류합니다.

가령, CPU가 충분치 않을 때, 아래와 같은 오류 이벤트가 발생합니다.

Events:
  Reason                        Message
  ------                        -------
  FailedScheduling      No nodes are available that match all of the following predicates:: Insufficient cpu (3).

Pod은 현재 Pending 상태 유지한 상태이며,

kubectl describe 명령어로 확인한 Events에서 CPU가 불충분하다는 것을 확인할 수 있습니다.

Resources

그럼, Resources를 실제로 설정 방법에 대해 알아보겠습니다.

각 컨테이너에 대해, 다음과 같은 리소스 제한(limit) 및 요청(request)을 지정할 수 있습니다.

✔️ spec.containers[].resources.limits.cpu

✔️ spec.containers[].resources.limits.memory

✔️ spec.containers[].resources.limits.hugepages-<size>

✔️ spec.containers[].resources.requests.cpu

✔️ spec.containers[].resources.requests.memory

✔️ spec.containers[].resources.requests.hugepages-<size>

Resources: CPU

Pod 정의를 통해 생성 시, 필요한 CPU와 메모리의 양을 지정할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

⚠️ 이 때, Pod 내 모든 컨테이너마다 제한과 요청이 설정됩니다.
컨테이너가 여러 개면 각 컨테이너는 개별적으로 요청이나 제한을 설정할 수 있습니다.

쿠버네티스에서 CPU 리소스에 대한 단위는, 1 CPU 단위는 1 Physical CPU core 혹은, 1 virtual core입니다.

가령, 컨테이너의 spec.containers[].resources.requests.cpu를 0.5로 설정한다는 것은,

1.0 CPU 절반의 CPU 타임을 요청한다는 의미입니다.

Resources: Memory

memory 에 대한 제한 및 요청은 바이트 단위를 사용합니다.

E, P, T, G, M, k 혹은 Ei, Pi, Ti, Gi, Mi, Ki 와 같이, Quantity 접미사 중 하나를 사용하여 표현할 수 있습니다.

1 G (Gigabyte) = 1,000,000,000 bytes
1 M (Megabyte) = 1,000,000 bytes
1 K (Kilobyte) = 1,000 bytes

1 Gi (Gigibyte) = 1,073,741,824 bytes
1 Mi (Mebibyte) = 1,048,576 bytes
1 Ki (Kibibyte) = 1,024 bytes

Behavior

Pod가 지정된 limit을 초과하면 어떻게 될까요?

CPU는 시스템이 CPU를 조절해 지정된 한도를 넘지 않습니다.

즉, 컨테이너가 한계점 이상으로 CPU 리소스를 쓸 수 없습니다.

Memory는 컨테이너는 한도보다 많은 메모리 리소스를 초과하여 쓸 수 있습니다.

계속해서 limit 보다 많은 메모리를 소모하면 Out-of-Memory 오류로 종료 (terminated) 됩니다.

kubeclt 명령어의 log나 describe 을 사용하면, 출력에서 Pod가 OOM 에러를 확인할 수 있습니다.

Default Behavior

기본적으로 쿠버네테스는 CPU나 메모리 요청, 한계점이 없습니다.
즉, 어떤 Pod든 어떤 노드에서 필요한 만큼의 자원을 소비할 수 있고,
해당 노드에서 실행 중인 다른 Pod나 프로세스를 질식(suffocate)시킬 수 있습니다.

그렇다면, 클러스터에서 CPU 리소스를 공유하는 여러 Pod가 있을 때,

어떻게 설정하는 게 가장 이상적일까요?

Behavior: CPU

한 Pod가 필요한 양의 CPU를 아래와 같이 표시해보겠습니다.

Available CPU:

위 CPU를 공유해서 사용하는 Pod 1️⃣ 과 Pod 2️⃣ 가 있을 때,

가장 이상적인 상황을 찾아보도록 하겠습니다.

✔️ CASE 1. NO REQUESTS / NO LIMITS

리소스 limit을 지정하지 않으면,

Pod 하나가 노드의 모든 CPU 리소스를 소비하고 두 번째 리소스 request도 막을 수 있습니다.

Pod 1️⃣ 에 Limit과 Request를 지정하지 않을 때

Available CPU: (Empty)

Limit: X, Request: X
1️⃣:
2️⃣: ❌ (사용 불가)

✔️ CASE 2. NO REQUESTS / LIMITS

구체적인 request은 없지만 limit가 구체적으로 명시된 경우,

이 경우 쿠버네티스는 자동으로 요청을 한계와 동일하게 설정합니다.

Pod 1️⃣ 에 Limit만 지정했을 때

Available CPU: (Empty)

Limit: 3 , Request: (Empty) = Limit
1️⃣:
2️⃣:

request이 비어있지만, limit 값이 존재하기 때문에 request를 3개로 추정합니다.

Pod마다 vCPU가 3개 이상 보장합니다.

✔️ CASE 3. REQUESTS / LIMITS

request과 limit가 모두 구체적으로 명시된 경우,

각 Pod에는 vCPU 하나인 CPU 요청이 보장되고, vCPU 3 까지만 사용 가능합니다.

Pod 1️⃣ 에 Limit과 request 둘 다 지정했을 때

Available CPU:

Limit: 3 , Request: 1
1️⃣:
2️⃣:

이상적으로 보이지만, 비효율이 존재합니다.

그런데, Pod 2️⃣ 또한 CPU를 많이 차지 않는 상황이라면, CPU의 제한을 두고 싶지 않을 수 있습니다.

그래서 1️⃣번 Pod의 CPU를 더 사용할 수 있게 하고 싶다면,

CPU 사이클의 리소스를 불필요하게 제한하지 않는게 낫습니다.

✔️ CASE 4. REQUESTS / NO LIMITS

limit 없이 request 설정할 경우,

요청이 정해져 있어서, 각 구역마다 vCPU를 사용을 보장받습니다.

Pod 1️⃣ 에 request만 지정했을 때

Available CPU:

Limit: (Empty), Request: 1
1️⃣:
2️⃣:

사용 가능 시에는 한계가 설정되지 않기 때문에, Pod마다 CPU 사용량을 최대한 많이 사용 가능합니다.

또, 어떤 시점에서든 Pod 2의 CPU 사용이 요구되면 요청된 CPU 사용량이 보장됩니다.

즉, 가장 이상적인 환경이죠.

Behavior: Memory

이번에는 Pod가 필요한 양의 Memory를 아래와 같이 표시해보겠습니다.

Available Memory: ️ ️ ️ ️ ️ ️

메모리도 CPU와 동일한데,

위 Memory를 공유해서 사용하는 Pod 1️⃣ 과 Pod 2️⃣ 가 있을 때를 예시로 들어보겠습니다.

✔️ CASE 1. NO REQUESTS / NO LIMITS

메모리 limit을 지정하지 않으면, Limit이 없어 Pod 하나가 노드의 메모리 리소스 전체를 소비할 수 있습니다.

즉, 다른 Pod가 필요한 리소스 사용을 막을 수 있습니다.

Pod 1️⃣ 에 request과 limit 둘 다 지정하지 않을 때

Available Memory: (Empty)

Limit: X, Request: X
1️⃣: ️ ️ ️ ️ ️ ️
2️⃣: ❌ (사용 불가)

✔️ CASE 2. NO REQUESTS / LIMITS

Request가 구체적으로 명시되지 않고 limit는 명시되어 있는 경우,

컨테이너는 자동으로 request을 한계로 설정됩니다.

Pod 1️⃣ 에 limit만 지정할 때

Available Memory: (Empty)

Limit: 3 Gi, Request: (Empty) = Limit
1️⃣: ️ ️ ️
2️⃣: ️ ️ ️

위 예시에서는, Request과 Limit는 둘 다 3Gi로 설정 됩니다.

✔️ CASE 3. REQUESTS / LIMITS

request과 limit가 모두 구체적으로 명시된 경우,

각 Pod에는 메모리 request 만큼의 양이 보장되고, 3Gi 까지만 사용 가능합니다.

Pod 1️⃣ 에 request과 limit 둘 다 지정할 때

Available Memory: ️ ️

Limit: 3Gi, Request: 1Gi
1️⃣: ️ ️ ️
2️⃣: ️

Request과 Limit을 설정한 경우, 각 포드마다 메모리가 보장됩니다.

✔️ CASE 4. REQUESTS / NO LIMITS

Request을 정하되 Limit은 지정하지 않을 경우, 각 Pod에 정해진 Request 만큼의 양을 보장합니다.

Pod 1️⃣ 에 request만 지정할 때

Available Memory: (Empty)

Limit: (Empty), Request: 1Gi
1️⃣: ️ ️ ️ ️ ️ OOM
2️⃣: ️

하지만, 한계가 설정되지 않기 때문에 어떤 포드든 사용 가능한 메모리를 소모할 수 있습니다.

CPU와는 달리 메모리를 조절할 수 없기 때문에,

Pod 2가 제공된 메모리 보다 더 요청하면 죽게됩니다.

Memory를 되찾을 유일한 방법은 Pod를 죽이고 Pod에 사용한 Memory를 해제(free)시켜주는 것입니다.

LimitRange: Pod Resource Limit

기본적으로 Pod에 구성된 리소스 요청이나 한계가 없다고 했는데,

그렇다면 Pod 내 Container에 Default로 설정할 Resource Limit을 지정할 수 있을까요?

이는 LimitRange 정의를 설정해서 가능합니다.

LimitRange는 하나의 쿠버네티스 객체이며,

Namespace 레벨에서 생성됩니다.

Pod 정의 파일에 Resource 나 특정 Limit 없이 생성된 컨테이너에 한해, Pod 내 모든 컨테이너에 적용됩니다.

가령, default Limit 을 500m으로 지정하고,

defaultRequest도 동일하게 500m로 지정할 수 있습니다.

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
    - default:           # limit
        cpu: 500m
      defaultRequest:    # request
        cpu: 500m
      max:               # limit
        cpu: "1"
      min:               # request
        cpu: 500m
      type: Container

max는 Pod 내 Container에 지정할 수 있는 Maximum limit,

min 은 Pod 내 Container가 만들 수 있는 Minimum request 의미합니다.

✔️ 적용한 Pod에 명시되는 정보

Name:             myapp-pod
Namespace:        default
Priority:         0
Service Account:  default
Node:             kind-control-plane/172.21.0.2
Start Time:       Sat, 30 Mar 2024 17:04:30 +0900
Labels:           app=myapp
                  type=front-end
Annotations:      kubernetes.io/limit-ranger: LimitRanger plugin set: cpu request for container nginx-container; cpu limit for container nginx-container
Status:           Running

메모리도 동일합니다.

apiVersion: v1
kind: LimitRange
metadata:
  name: memory-resource-constraint
spec:
  limits:
  - default:
      memory: 1Gi
    defaultRequest:
      memory: 1Gi
    max:
      memory: 1Gi
    min:
      memory: 500Mi
    type: Container

⚠️ 위 Limitation은 Pod가 생성될 때 강제로 설정됩니다.

만약, LimitRange를 생성하거나 수정한다면, 기존 Pod에는 적용되지 않고 새로 생성되는 Pod에 한해서만 적용됩니다.

Cluster Limitation: ResourceQuota

쿠버네티스 클러스터에 배포된 앱이 사용할 수 있는 전체 리소스를 제한할 방법이 있습니다.

Resource Quota는 네임스페이스 레벨에서, Request와 Limit의 Hard Limit 값을 설정할 수 있습니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resource-quota
spec:
  hard:
    request.cpu: 4
    request.memory: 4Gi
    limit.cpu: 10
    limit.memory: 10Gi

그럼 지금까지, 쿠버네티스에서 최소 리소스를 설정하고 제한하는 방법에 대해 알아보았습니다.

| Reference |

- Manage Memory, CPU, and API Resources

- LimitRange for CPU

- LimitRange for Memory

Kubernetes Scheduler, 제대로 이해하기

gngsn — Sun, 31 Mar 2024 23:59:29 +0900

본 포스팅에서는 Kubernetes의 Scheduler의 개념을 이해하는 목표를 가집니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

Pod가 특정 노드에 배치되는 이유를 알고 싶거나,

사용자 정의 스케줄러를 직접 구현할 계획이라면,

해당 포스팅에서 이해해보도록 하겠습니다.

Scheduling

Kubernetes에서 스케줄링은 Kublet이 Pods를 실행할 수 있도록 Nods와 매칭시키는 것을 의미합니다.

Scheduler

스케줄러는 새로 생성된 Pod 중, 아직 노드에 할당되지 않은 Pod들을 찾아내고,

해당 Pod가 실행될 최적의 Node를 찾는 역할을 합니다.

kube-scheduler

kubernetes.io - Scheduling Framework

kube-scheduler는 워커 노드에서 Kubernetes pod의 스케줄링을 담당합니다.

한 Pod를 배포할 때 CPU, Memory, Affinity, Taints and Tolerations, Priority, Persistent Volumes (PV) 등과 같은 포드 요구 사항을 지정합니다.

스케줄러의 주된 역할은 생성된 요청을 식별하고,

요구 사항을 충족하는 Pod가 배치될 가장 적합한 노드를 선택하는 것입니다.

하나의 Kubernetes 클러스 내에는 하나 이상의 워커 노드가 존재할 수 있습니다.

그렇다면, 어떻게 스케줄러는 모든 워커 노드들 중에서 하나를 지정할까요?

스케줄러는 Scheduling cycle과 Binding cycle 두 단계로 되어 있고, 이를 둘을 합쳐 "scheduling context"라고 합니다.

Scheduling cycle은 최적의 노드를 선택하기 위해, filtering 과 scoring 작업을 수행하고,

Binding cycle은 binding 이벤트를 생성하여 그 변화를 클러스터에 적용합니다.

Scheduling Cycle

1. Filtering

Filtering 단계에서는, Pod를 스케줄할 수 있는 가장 적합한 노드를 찾습니다.

가장 먼저 Pod 가 생성되면 Pod 는 Scheduling Queue 끝에 추가되어, 스케줄링 될 때까지 대기합니다.

스케줄러는 스케줄링을 위해 항상 우선순위가 높은 pod들을 우선순위가 낮은 pod들보다 먼저 배치합니다.

Scheduling Queue
1. ⚪️ ⚪️ ⚪️ ← New pod
2. ⚪️ ⚪️ ⚪ ← Sorting based on the priority defined on the pods
3. ⚪️ ⚪️ ⚪ (sorted)

이 때, 큐 내의 Pod 들은 Priority 에 따라 정렬됩니다.

우선 순위는 아래와 같이 PriorityClass 객체를 정의해서 Pod에 적용할 수 있습니다.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

이제, 순차적으로 Pod를 스케줄할 수 있는 가장 적합한 노드를 찾습니다.

실행가능한 워커 노드를 모두 선택합니다.

Pod를 실행할 수 없는 노드는 여기서 필터링됩니다.

가령, 스케줄링할 차례가된 Pod인, simple-webapp 에 대해 생각해봅시다.

simple-webapp 는 resource의 CPU request 가 10으로 지정되어 있습니다.

즉, 최소 CPU 10 을 실행할 수 있는 노드에 배치되어야 합니다.

: simple-webapp( 10)

⬜️ ⬜️ ⬜️ ⬜️
Node 1 Node 2 Node 3 Node 4
CPU : ❌4 ❌4 12 16

앞 두 노드는 리소스가 부족해 필터링 됩니다.

: simple-webapp( 10)

⬜️ ⬜️
Node 3 Node 4
CPU : 12 16

Scheduling Cycle

2. Scoring

스케줄러가 필터링된 워커 노드들에 점수를 부여하여 노드들의 순위를 매깁니다.

그중, 가장 높은 순위를 가지는 노드가 Pod 스케줄링을 위해 선택됩니다.

만약 모든 노드들이 동일한 순위를 가지면, 한 노드가 임의로 선택됩니다.

스케줄러는 여러 스케줄링 플러그인들을 호출하여 스코어링을 합니다.

기본적으로, 각 노드에 해당 Pod에 필요한 CPU를 사용한 후 남은 공간을 수치로 점수를 매깁니다.

: simple-webapp ( 10)

          ⬜️ ⬜️
Node 3 Node 4
CPU : 12 16
Weight: 2 6

첫 번째 노드는 2, 두 번째 노드는 6 만큼의 CPU 사용량이 남습니다.
따라서, 두 번째 노드가 더 높은 점수를 받아 선택됩니다.

Binding cycle

3. Binding Event

노드가 선택되면, 스케줄러는 API서버에 Binding 이벤트를 생성합니다.

이때 Binding 이벤트란, Pod와 node를 Binding하는 이벤트를 의미합니다.

⬜️ ⬜️ ← simple-webapp
Node 3 Node 4
CPU : 12 16

Profile

스케줄링 프로파일을 사용하면 kube-scheduler에서 스케줄링의 각 단계들을 구성할 수 있다.

위에서 살펴본 각 단계마다, 플러그인이 연결될 수 있는 Extension Point이 존재하는데,

Extension Point 마다 플러그인을 자유롭게 커스터마이징하여 배치할 수 있습니다.

Extension Point들 중 하나 혹은 그 이상을 구현해서 스케줄링에 실행될 수 있게끔 제공합니다.

KubeSchedulerConfiguration

기본적으로, 플러그인에 대한 설정은 아래와 같은 정의를 통해 설정할 수 있습니다.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - plugins:
      <<Extension Point>>:
        disabled:
        - name: <<Plugin Name>>
        enabled:
        - name: <<Plugin Name>>

.profiles.plugins 하위에 extension point 를 명시하고,

해당 지점에서 사용할/사용하지 않을 플러그인의 이름을 명시합니다.

가령 아래와 같이 score 단계에서 PodTopologySpread 는 비활성화하고,

MyCustomPluginA 와 MyCustomPluginB를 활성화 설정을 할 수 있습니다.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - plugins:
      score:
        disabled:
        - name: PodTopologySpread
        enabled:
        - name: MyCustomPluginA
          weight: 2
        - name: MyCustomPluginB
          weight: 1
      preScore:
        disabled:
          - name: '*'

모든 디폴트 플러그인을 비활성화 시키고 싶다면, * 를 사용할 수 있습니다.

Extension Points

스케줄링은 아래의 순차적 단계로 이루어지며, Extension Point 으로 노출되어 커스텀할 수 있습니다.

https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/

1. queueSort:

스케줄링 대기열에서 Pending 중인 파드를 정렬하는 데 사용되는 정렬 기능을 제공.

대기열 정렬 플러그인은 한 번에 정확히 하나만 활성화할 수 있음.

2. preFilter

필터링 전에 Pod 또는 클러스터에 대한 사전 처리나 정보를 확인하는 데 사용.

Pod에 unschedulable 표시를 할 수 있음.

unschedulable는 모든 Pod가 가지고 있는 속성이며, 기본 설정은 모두 true.

해당 노드에 false로 설정된 Pod가 없다는 걸 보장하는데 사용할 수 있음.

3. filter

스케줄링 정책의 Predicate와 동일하며 Pod를 실행할 수 없는 노드를 필터링하는 데 사용됨.

필터는 설정된 순서대로 호출.

모든 필터에 통과된 노드가 없으면, Pod는 unschedulable로 표시됨.

4. postFilter

Pod를 배치할 노드를 찾지 못했을 때, 구성된 순서대로 호출.

만약 어떤 postFilter 플러그인이 Pod를 schedulable로 표시한다면, 이후 플러그인들은 호출되지 않음.

5. preScore

Scoring 작업 수행 전, 사용할 수 있는 정보성 Extension Point.

6. score

필터링 단계를 통과한 각 노드에 점수를 매김.

이후 스케줄러는 가중치 합계가 가장 높은 노드를 선택.

7. reserve

지정된 Pod에 리소스가 예약된 경우, 플러그인에 알리는 정보성 Extension Point.

플러그인 구현 시, Reserve 실행 중 혹은 그 이후에 실패 시, 호출할 Unreserve 을 구현함.

8. permit

Pod 바인딩을 방지하거나 지연시킬 수 있음.

9. preBind

Pod가 바인딩되기 전, 필요한 모든 작업을 수행.

10. bind

Pod를 노드에 바인딩.

bind 플러그인은 순서대로 호출되며, 한 번 바인딩이 완료되면 나머지 플러그인은 건너 뜀.

적어도 하나 이상의 bind 플러그인 필요

11. postBind

Pod가 바인드된 후 호출되는 정보성 Extension Point

12. multiPoint

모든 적용 가능한 익스텐션 포인트에 대해, 플러그인들을 동시에 활성화하거나 비활성화할 수 있게 하는 환경 설정 전용 필드

Scheduling plugins

kubernetes.io: Scheduler Configuration

다음 플러그인은 기본적으로 사용하도록 설정되어 사용할 수 있습니다.

✔️ ImageLocality: 파드가 실행하는 컨테이너 이미지가 이미 있는 노드를 선호.

Extension points: score.

✔️ TaintToleration: taints and tolerations 구현.

Implements extension points: filter, preScore, score.

✔️ NodeName: Pod 정의 시, .spec에 명시한 nodeName이 현재 노드와 일치하는지 확인 .

Extension points: filter.

✔️ NodePorts: Pod가 요구하는 포트들을 해당 노드에서 사용 가능한지 확인.

Extension points: preFilter, filter.

✔️ NodeAffinity: node selectors 와 node affinity 구현.

Extension points: filter, score.

✔️ PodTopologySpread: Pod topology spread 구현.

Extension points: preFilter, filter, preScore, score.

✔️ NodeUnschedulable: .spec.unschedulable 이 true로 설정된 노드를 필터링.

Extension points: filter.

✔️ NodeResourcesFit: 해당 노드에 파드가 요청하는 모든 리소스가 있는지 확인.

다음 3가지 전략 중 하나 사용 가능: LeastAllocated (default), MostAllocated and RequestedToCapacityRatio.

Extension points: preFilter, filter, score.

✔️ NodeResourcesBalancedAllocation: 파드가 스케줄된 경우, 해당 노드보다 균형잡힌 리소스 사용량을 얻을 수 있는 노드를 선호.

Extension points: score.

✔️ VolumeBinding: 노드에 요청된 Volume이 있는지 또는 바인딩할 수 있는지 확인.

Extension points: preFilter, filter, reserve, preBind, score.

Note: score Extension Point 는 VolumeCapacityPriority 기능이 활성화되어 있어야 활성화되며,

요청된 볼륨 사이즈를 만족하는 가장 작은 PV들을 우선순위 매깁니다.

✔️VolumeRestrictions: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한 제한 사항을 충족하는지 확인.

Extension points: filter.

✔️ VolumeZone: 요청된 볼륨이 가질 수 있는 영역 요구 사항을 충족하는지 확인.

Extension points: filter.

✔️ NodeVolumeLimits: 노드에 대해 CSI 볼륨 제한을 충족할 수 있는지 확인.

Extension points: filter.

✔️EBSLimits: 노드에 대해 AWS EBS 볼륨 제한을 충족할 수 있는지 확인.

Extension points: filter.

✔️ GCEPDLimits: 노드에 대해 GCP-PD 볼륨 제한을 충족할 수 있는지 확인.

Extension points: filter.

✔️ AzureDiskLimits: 노드에 대해 Azure 디스크 볼륨 제한을 충족할 수 있는지 확인.

Extension points: filter.

✔️ InterPodAffinity: inter-Pod affinity and anti-affinity 구현.

Extension points: preFilter, filter, preScore, score.

✔️ PrioritySort: 기본 우선 순위 기반 정렬을 제공

Extension points: queueSort.

✔️ DefaultBinder: 기본 바인딩 메커니즘을 제공.

Extension points: bind.

✔️ DefaultPreemption: 기본 선점preemption 메커니즘을 제공

Extension points: postFilter.

기본적으로 활성화되지 않는 플러그인을 컴포넌트 구성 API를 통해 활성화할 수도 있습니다.

✔️ CinderLimits: 노드에 대해 OpenStack Cinder 볼륨 제한이 충족될 수 있는지 확인

Extension points: filter.

Multiple profiles

둘 이상의 프로파일을 실행하도록 kube-scheduler 를 구성할 수 있습니다.

여러 개의 KubeSchedulerConfiguration 객체를 정의할 수 있겠죠.

하지만, 각각 다른 프로세스이기 때문에, 결국 관리를 위한 추가적인 노력이 필요합니다.
더 중요한 건, 각각 다른 프로세스로 실행되면서, 스케줄링에 차질이 생길 수 있다는 것입니다.

가령, 한 스케줄러가 어떤 노드에서 작업을 스케줄링할 때,

다른 스케줄러가 동시에 같은 노드에서 작업 스케줄링을 하는 것을 모른다는 것인데요.

쿠버네티스 1.18 릴리즈에서 하나의 Scheduler에 대한 Multiple Profile 소개합니다.

한 scheduler 설정 파일 내에 다수의 프로파일을 구성할 수 있습니다.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
  - schedulerName: no-scoring-scheduler
    plugins:
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

하나의 관리 파일 내에 스케줄러 정책을 정의할 수 있게되었습니다.

여러 개의 스케줄러가 하나의 바이너리로 실행되는 것일 뿐,

각각의 스케줄러 자체도 분리된 스케줄러처럼 작동합니다.

각 프로파일에는 스케줄러 이름이 있으며,

Extension Point에 구성된 다른 플러그인 세트를 가질 수 있습니다.

그럼 여기까지, Node Scheduling에 대해 알아보았습니다.

| Reference |

Kubernetes.io - Official Docs

Udemy: certified-kubernetes-administrator-with-practice-tests

Kubernetes Affinity, 제대로 이해하기

gngsn — Mon, 25 Mar 2024 12:22:12 +0900

본 포스팅에서는 Kubernetes의 Affinity의 개념을 이해하여 Taints & Tolerations와의 차이점을 구분할 수 있는 목표를 가집니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

Assigning Pods to Nodes

노드를 특정 애플리케이션 만을 실행하게 만들거나,

다른 서비스와 구분되는 그룹으로 만들고 싶을 때가 있습니다.

Pod을 특정 Node에 배치되도록 하는 방식에는 Label & Selector, NodeSelector, Affinity 등이 있습니다.

Node Affinity vs Taints & Tolerations

두 기능의 차이가 궁금하신 분들은 이전 포스팅의 Node Affinity vs. Taints & Tolerations 섹션을 참고 바랍니다.

스케줄러는 자동으로 자원이 부족한 노드에 파드를 배치하지 않도록 노드 간에 파드를 분배합니다.

이러한 합리적인 방식 Node를 선택하여 Pod를 배치하도록 만드는 것이 가장 좋지만,

종종, Node를 특정지어야할 때가 있습니다.

가령, SSD가 장착된 머신에 파드가 배포되도록 하거나,

통신이 빈번한 두 애플리케이션의 파드를 동일한 가용성 영역(availability zone)에 배치하는 경우가 있습니다.

이번 포스팅에서는 Pod의 속성으로 지정할 수 있는,

NodeSelector와 Affinity가 무엇인지 알아보도록 하겠습니다.

Node Selector

Node Selector는 가장 단순하게 노드 선택을 하는 방식입니다.

Pod spec 작성 시, nodeSelector 속성에 타겟이 되는 Node를 명시하면,

쿠버네티스가 해당 Label을 갖는 Node만 고려하여 스케줄링합니다.

가령, 세 대의 하드웨어가 있다고 가정해 봅시다.

   Pod 1    Pod 2 Pod 3
Pods:

Nodes: ⬜️ ◽️    ◽️
   Node1 Node2 Node3

가령, 위와 같이 큰 리소스를 가질 수 있는 Node 1 ( ⬜️ )과,

작은 리소스를 갖는 두 노드, Node 2 와 Node 3 (◽️)가 있습니다.

클러스터에는 각자 다른 종류의 작업들이 실행되고 있는데,

리소스 한계 문제로 데이터 프로세싱 처리 애플리케이션를 가지는 Pod 3 ( ) 을 가장 큰 리소스를 가진 노드에 배치해야 합니다.

먼저, Node Selector를 통해 배치해 보도록 하겠습니다.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: data-processor
    image: data-processor
  nodeSelector:
    size: Large

마지막 구문에, nodeSelector에 size가 Large 를 입력해, {size: Large} Label을 가진 노드를 지정한 것을 확인할 수 있습니다.

Pods:
           ⬇️
    ️ Large

Nodes: ⬜️ ◽️    ◽️
(Label) noting

이 때, nodeSelector을 사용하려면 Pod를 생성하기 전, 반드시 노드에 레이블을 지정해야 합니다.

위 조건을 만족하기 위한 방법은 Node Selector 을 살펴보았는데요.

다른 방법인 Node Affinity를 살펴보겠습니다.

$ kubectl label nodes

Pod가 특정 노드에 붙게끔 설정 했으면, 이젠 특정 노드에 Label을 붙여 찾아갈 수 있게 해야 합니다.

Label을 Node에 붙이려면 아래와 같이 입력할 수 있습니다.

❯ kubectl label nodes <node-name> <label-key>=<label-value>

위 예시를 보면 아래와 같은 모습이 되게끔 하면 됩니다.

Pods:
        ⬇️
           ️ Large

Nodes: ⬜️ ◽️    ◽️
(Label) ️ Large

위의 예시를 들면 아래와 같이 나타낼 수 있습니다.

❯ kubectl label nodes node-1 size=Large

이처럼 NodeSelector은 특정 Pod가 특정 노드에 배치되는 것을 충족시켜줍니다.

하지만, 더 복잡한 요구 사항이 있을 때 대응하지 못합니다.

가령 Large 혹은 Medium 레이블에 지정 (Large OR Medium) 하거나,

Small 이라는 Label이 붙지 않은 노드 (NOT Small) 에 배치해달라고 하는 등의 표현이 불가합니다.

이 때에는 Node Affinity를 사용할 수 있습니다.

Node Affinity

Node affinity is a property of Pods that attracts them to a set of nodes (either as a preference or a hard requirement).

Node Affinity는 특정 노드에 해당 Pod를 위치시키도록 보장합니다.

참고로, 실제 단어의 개념을 살펴보면 다음과 같습니다.

Affinity: a close similarity between two things

Node Affinity 기능은 특정 Pod 들이 특정 노드에 위치시는 것을 보장하기 위한 기능입니다.
nodeSelector는 OR이나 NOT 연산 등의 제한이 있었습니다.

Node Affinity 에서는 복잡한 구문을 통한 노드 매치가 가능합니다.

apiVersion: v1
kind: Pod
metadata:
  name: core-k8s
spec:
  containers:
  - name: data-processor
    image: data-processor
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: size
            operator: In
            values:
            - Large

affinity 명세는 .spec.affinity 하위에 작성합니다.

Matching

여러 Label 들에 함께 적용하고 싶다면 아래와 같은 조건을 걸 수 있습니다.

✔️ Large OR Medium

Large 뿐만 아니라 Medium Label도 추가 하고 싶다면 아래와 같이 사용할 수 있습니다.

...
- matchExpressions:
    - key: size
      operator: In
      values:
        - Large
        - Medium
...

✔️ NOT Small

혹은 특정 Label만 제외 시키고 싶다면, 아래와 같이 구문 설정합니다.

...
- matchExpressions:
    - key: size
      operator: NotIn
      values:
        - Small
...

위 처럼 Node Affinity 를 사용해서 Pod를 Node 선호도에 따라 배치할 수 있는데요.

만약, 노드에 Large라는 Label을 설정할 수 없다면, 어떻게 될까요?

matchExpressions에 해당하는 노드가 존재하지 않는다면?

즉, 배치할 수 있는 Node가 존재하지 않는다면?

실제로, 누군가 Label을 변경한다면 배치할 수 없는 Pod이 존재할 수 있게 됩니다.

하지만 실제로 이런 일이 발생하면 안되겠죠.

쿠버네티스 스케줄러는 Node Affinity 타입을 통해, 이를 해결합니다.

Available:

1️⃣ requiredDuringSchedulingIgnoredDuringExecution

규칙이 만족되지 않으면 스케줄러가 Pod를 스케줄링할 수 없습니다.

이 기능은 nodeSelector와 유사하지만, 좀 더 표현적인 문법을 제공한다는 차이가 있습니다.

속성 명이 직관적인데요.

하나씩 확인해보면 다음과 같습니다.

- Required + DuringScheduling: 새로 생성되는 Pod에 대해 적용, 만족하지 않는 Node에 스케줄링 하지 않음

- Ignored + DuringExecution: 실행 중인 Pod에 대해 무시

2️⃣ preferredDuringSchedulingIgnoredDuringExecution

스케줄러는 조건을 만족하는 노드를 찾으려고 노력합니다.

해당되는 노드가 없더라도, 스케줄러는 여전히 파드를 스케줄링합니다.

- Preferred + DuringScheduling: 새로 생성되는 Pod에 대해 적용, 최대한 조건을 만족하도록 스케줄링

- Ignored + DuringExecution: 실행 중인 Pod에 대해 무시

Preferred 는 마치 "Try your best to place the pod on matching node" 라고 말하는 것과 같습니다.

"최대한 매칭될 수 있는 Node에 배치시켜줘" 라는 식입니다.

Planned:

3️⃣ requiredDuringSchedulingRequiredDuringExecution

아직 지원하지는 않지만, 곧 지원될 예정인 속성입니다.

- Preferred + DuringScheduling: 새로 생성되는 Pod에 대해 적용, 만족하지 않는 Node에 스케줄링 하지 않음

- Required + DuringExecution: 실행 중인 Pod에 대해 적용, 만족되지 않는 Pod는 퇴출

그럼 여기까지, Node Affinity를 알아보았습니다.

| Reference |

Kubernetes.io - Official Docs

Udemy: certified-kubernetes-administrator-with-practice-tests

Kubernetes Taints & Tolerations, 제대로 이해하기

gngsn — Sun, 24 Mar 2024 23:58:24 +0900

본 포스팅에서는 Kubernetes의 Taint 와 Toleration의 개념을 이해하여 Affinity와의 차이점을 구분할 수 있는 목표를 가집니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

Taints & Tolerations?

Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes.

Taint (테인트)와 Toleration(톨러레이션)는 Pod가 적절치 않은 노드에 스케줄링 되지 않는 것을 보장합니다.

특정 Pod가 Node에 스케줄링 될 때, Node 배치에 제한을 걸 수 있는 용도로 사용될 수 있습니다.

참고로, 실제 두 단어의 개념을 살펴보면 다음과 같습니다:

Taint: the act or result of spoiling something or giving it an unpleasant quality

Tolerant: having the ability to bear something unpleasant or annoying, or to keep going despite difficulties Example.

Toleration은 Pod에, Taint는 Node에 적용되어 두 개념이 함께 사용됩니다.

이해를 위해 예시를 먼저 확인하고 조금 더 깊이 들어가보겠습니다.

Example.

벌레 3마리와 동물 3마리가 있다고 가정해보겠습니다.

, , 와 , , 가 있습니다.

Pods:

Nodes:
dog koala fox

벌레들이 동물들을 괴롭혀서, 동물들은 벌레 퇴치제 를 구매합니다.

벌레가 다가오지 못하게 에게 벌레 퇴치제를 뿌리면, 냄새에 견디지 못하는 벌레들이 다가오지 못하게 할 수 있습니다.

이 때, ① 강아지 를 Taint 상태라고 지칭할 수 있습니다.

Pods:

Nodes:
   dog koala fox

이제 퇴치제 를 뿌린 dog에게는 어떤 벌레도 다가오지 못합니다.

, , → ❌

해당 벌레 퇴치제 냄새를 견딜 수 있는 벌레가 있을 수 있어서 동물에게 닿을 수 있다면,

그 벌레는 해당 Tolerant 에 견딜 수 있다고 할 수 있습니다.

이 때 벌레 C가 퇴치게에 내성(Tolerant)이 생겼다고 가정해보죠.

Pods:
A B C

Nodes:
dog    koala fox

즉, 벌레가 다가오지 못하게 Taint 상태로 만들 수 있고,

해당 퇴치제를 견딜 수 있어 Taint 상태의 동물( )에게 다가갈 수 있는 특정 벌레( )를 Tolerate 하다고 표현합니다.

, → ❌

→ ⭕️

쿠버네티스에 적용해보면 동물 → Node / 벌레 → Pod 입니다.

즉, 특정 Node에 아무 Pod 이나 배치되지 않게 Taint 상태를 만들어 두고,

지정하고자 하는 Pod에 Toleration 조건을 달아 특정 Node에 접근할 수 있게 만드는 것입니다.

(Toleration) app Equal blue
Pods ⚪️ ⚪️

Nodes ⬜️ ⬜️
(Taint) app=blue

How to use

그럼, 쿠버네티스에서 어떻게 적용할 수 있는지 살펴보도록 하겠습니다.

1. Node - kubectl taint

Node에 taint를 적용시키려면 kubectl taint 명령어를 사용할 수 있습니다.

❯ kubectl taint nodes <<node-name>> <<key>>=<<value>>:<<taint-effect>>

node-name: taint를 적용할 노드 이름

key: taint key

value: taint value
taint-effect: taint에 tolerate 하지 않는 Pod에 대한 액션

가령 아래와 같은 명령어를 사용할 수 있습니다.

kubectl taint nodes node1 key1=value1:NoSchedule

node1 노드에 taint를 적용합니다.

taint는 key 값으로 key1을, value 값으로 value1을 지정하며,

taint effect 는 NoSchedule로 지정됩니다.

일치하는 Toleration이 없으면 파드를 node1 에 스케줄하지 않음을 의미합니다.

만약, 위의 taint 명령어를 제거하고 싶다면 아래와 같이 - 를 추가하여 입력합니다.

kubectl taint nodes node1 key1=value1:NoSchedule-

Taint Effect.

Taint effect 로 지정할 수 있는 값은 아래와 같이 3가지가 있습니다.

✔️ NoSchedule

: Pod가 Node에 스케줄되지 않음. 기존 실행되던 Pod는 유지됨 (퇴출 ❌)

✔️ PreferNoSchedule

: Pod가 Node에 스케줄되지 않도록 최대한 노력하지만 보장되는 건 아님

✔️ NoExecute

: 새로운 Pod는 해당 Node에 위치되지 않으며, 만약 해당 Node에 존재했던 Pod가 있다면 아래 조건에 따라 처리

- Tolerate 되지 않은 Pod, 즉시 퇴출

- Tolerate 된 Pod 이면서, toleration spec에 tolerationSeconds 가 지정되지 않으면, 영구적 바인딩

- Tolerate 된 Pod 이면서, toleration spec에 tolerationSeconds 에 특정 시간이 지정되어 있으면, 해당 시간 이후 Node Lifecycle Controller에 의해 퇴출

---

tolerationSeconds: Pod가 Node에 바인딩된 시간을 지정

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600

2. Pod - PodSpec

Pod에 Toleration를 적용시키려면 PodSpec을 정의합니다.

아래 Tolerations에 정의된 내용이 taint와 일치한다면,

정의된 Pod는 해당 Node에 배치될 자격이 주어집니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"

위의 예시에서는 key가 key1이고 value가 value1으로 동일(Equal)하는 NoSchedule의

Taint 노드에 진입 (or 견딜 수 Tolerate) 있다는 의미입니다.

tolerations 필드 하위의 값들은 항상 쌍따옴표("")에 감싼 값을 입력해야 합니다.

Matching.

조건은 다양하게 지정할 수 있는데, operator의 기본 값은 Equal 입니다.

Toleration은 다음과 같은 3가지 조건을 만족해야 Taint와 "매칭"됩니다.

1. Key 동일

2. Effect 동일

3.1. Operator가 Equal 일 때, value 값이 동일

tolerations:
- key: "example-key"
  operator: "Equal"
  value: "example-value"
  effect: "NoSchedule"

3.2. Operator가 Exists 일 때 (value 필드 값은 필요 없고 키 값이 존재하는 지 필요)

tolerations:
- key: "example-key"
  operator: "Exists"
  effect: "NoSchedule"

다만, 두 가지 특별한 경우가 있습니다.

✔️ operator가 Exists 이면서 key 가 빈 값일 때, 모든 것들이 Tolerate 됩니다.

✔️ effect 가 빈 값일 때, key가 일치하는지만 확인합니다.

Caution

⚠️ Node 1 은 오직 Pod D만 배치될 수 있지만, 반대로 Pod D가 항상 Node 1에 배치된다는 보장은 없습니다.
즉, taint & toleration 은 특정 노드에 배치하기 위한 설정이 아니라, 특정 노드가 특정 Pod만을 수용한다는 것을 의미합니다.

만약, 반대로 특정 Pod 만을 제외하고 싶은 거라면, Node Affinity 를 통해 설정 가능합니다.

Master Node

클러스터에 존재하는 Master Node는 초기 설정 시,

다른 Pod가 지정되지 못하도록 자동으로 taint가 설정됩니다.

물론 해당 설정을 수정할 수는 있지만,

권장하는 Best Practice는, master 노드 서버에 애플리케이션 워크로드를 배포하지 않는 것입니다.

❯ kubectl describe node kind-control-plane -n kube-system | grep Taint
Taints: node-role.kubernetes.io/master:NoSchedule

실제 Control Plane 노드를 확인해보면, 쿠버네티스에서 지정해둔 Taint를 확인할 수 있습니다.

Node Affinity vs. Taints & Tolerations

세 개의 노드 blue, red, green ( , , )와 세 개의 Pod blue, red, green ( , , )가 있다고 가정해 보겠습니다.

Pods:

Nodes:

이 때, 다른 팀들과 같은 쿠버네티스 클러스터를 공유하고 있어서,

두 개의 Node (⬛️)와 두 개의 Pod (⚫️)를 추가로 존재하는 것을 감안해서 보겠습니다.

Pods: ⚫️ ⚫️

Nodes: ⬛️ ⬛️

목표

각 Node가 동일한 색상의 Pod 만을 가져야 합니다.

다른 팀의 Pod가 우리 노드에 놓여서는 안되고, 우리 포드가 다른 팀 노드에 있는 것도 안된다는 조건이 있습니다.

이제 Node Affinity와 Taints and Tolerations를 사용했을 때를 생각해보겠습니다.

1. Taints and Tolerations

먼저, Node에 각 색상 별 Taint를 추가 시킵니다.

(Toleration)   blue red green
Pods:    ⚫️ ⚫️

Nodes:     ⬛️ ⬛️
(Taint) blue red green

이후, 각 Pod의 배치를 허용할 수 있도록 하는 Tolerate 를 색상 별로 설정합니다.

그럼 의도대로 blue 노드에는 blue Pod가, green 노드에는 green Pod가 배치될 수 있습니다.

Pods: ⚪️ ⚪️ ⚪️ ⚫️ ⚫️
(scheduled)

Nodes: ⬛️ ⬛️
(Taint) blue red green X

하지만, 가능성이 있는 것이지, 해당 노드만을 선호한다는 보장은 없습니다.

따라서 Red Pod가 다른 팀의 노드(검은 노드)에 배치될 수 있습니다.

2. Affinity

먼저, 각 노드에 Label을 붙입니다.

그 다음, 각 Pod에 nodeSelector를 설정해 해당 Pod가 특정 Node에 배치되도록 유도합니다.

그럼 의도대로 blue, red, green Pod가 각각의 노드에 배치될 것입니다.

Pods: ⚪️ ⚪️ ⚪️ ⚫️ ⚫️
(scheduled)


Nodes:       ⬛️ ⬛️
(Taint) blue red green

하지만, 다른 Pod가 해당 노드에 배치되지 않는다는 보장이 없습니다.

즉, 다른 Pod가 우리 팀의 노드에 올 가능성이 있습니다.

Pods: ⚪️ ⚪️ ⚪️ ⚪️ ⚫️
(scheduled)


Nodes:     ⚫️   ⬛️    ⬛️
(Taint) blue red green

3. Taints and Tolerations + Node Affinity

두 방식을 결합해서 사용하면 의도하는 동작을 정확히 수행 가능합니다.

처음에는 Taint 와 Toleration 를 사용해 다른 팀의 Pod가 우리 노드에 놓이는 것을 막습니다.

Pods:     |       ⚪️ ⚪️
     |
     |
Nodes:      |    ⬛️ ⚫️ ⬛️ ⚫️
(Taint) blue red green

이후, Node Affinity 를 통해 우리 포드가 다른 팀 노드에 놓이는 것을 막습니다.

Pods: ⚪️ ⚪️ ⚪️ | ⚪️ ⚪️
|
|
Nodes: | ⬛️ ⚫️ ⬛️ ⚫️
(Taint) blue red green

그럼 여기까지, Node Affinity의 차이점까지 알아보았습니다.

| Reference |

Kubernetes.io - Official Docs

Udemy: certified-kubernetes-administrator-with-practice-tests

도둑맞은 집중력

gngsn — Sun, 24 Mar 2024 20:56:07 +0900

Stolen Focus, Johann Hari

Date: 2023.01.20 ~ 2023.01.27

Rate: ★ 4.8

Pages: 464

Comment: 유독 베스트셀러라는 책에 반감이 있던 본인에게, 베스트셀러가 된 이유가 타당하다고 느껴졌던 책이다. 저자 ‘요한 하리’의 책 “도둑맞은 집중력”에서 그가 풀어내는 문장의 흐름을 느꼈고, 번역 또한 문장력이 인상깊었다. 영국 저널리스트 답게 궁금증을 유발하는 문장들과 그의 의견을 전달하고자 하는 내용에 자연스럽고 담백하게 녹여냈다.

가령, 그가 느끼고 배운 내용들을 강조하는 방식이 아니라, 마치 감상문처럼 아무렇지 않게 적어 전달해 나아가는 것이다. 혹은, 장이 끝날 쯔음 파생될 수 있는 질문을 스스로 던짐으로써, 이후에 나올 내용들에 그에 대한 답이 나오길 기대하게 하는 것이다.

이 책에서 좋았던 점 중 하나는, 신빙성있는 전문가들과 대학 교수와의 인터뷰를 기반으로 다양한 연구 결과, 의견 등을 기반으로 내용을 이어간다는 점이었다. 저널리스트라는 직업에서 얻을 수 있는 장점을 본인의 서적에 녹여 내어 책에 장점으로 담은 것 같다는 생각이 들곤 했다.

본 책을 읽은지 며칠이 지나 한달 가량 됐을 무렵, 인스타그램을 하는 스스로를 보고 있자면 이 책이 계속 생각났다. 상향 평준화, 주관이 빼앗기는 기분 등 복잡한 감정이었다. 그래서 최근 3주간 핸드폰을 하는 시간을 줄이고 있다.

첫 주에는 일주일 평균 4시간 30분,

그 다음 주에는 4시간,

그 다음주인 지난 주는 3시간 10분,

그리고 금주에는 2시간 반을 사용하고 있다.

한 달 동안 가장 많이 사용한 앱은 독서, G메일(뉴스레터), Safari(검색)이 90%였다.

인스타그램 사용량이 급격히 줄었는데, 하루 평균 4시간 사용량을 15분으로 줄였다.

한 달 정도 이런 생활을 지속하니 SNS을 하면 종종 느까는 불안감이나 불확실함 등 부정적인 감정이 줄어든 것을 확실히 느끼고 있다. 적어도 FOMO에서 자연스럽게 멀어질 수 있는 길이기 때문에 어느정도 효과가 있을 거라는 기대에 대한 실현이라고 본다.

이러한 변화가 어떤 영향을 미칠까요? 내가 묻자 수네가 빙긋 웃었다.

"속도는 기분을 좋게 해주는 면이 있습니다.
우리가 속도에 빠지는 건 그게 좋기 때문이기도 하잖아요.
온 세상과 연결 되었다고 느끼고,
어느 주제에 관해 무엇이든 알아내고 배울 수 있다고 느끼게 되니까요."

그러나 우리는 자신이 노출되는 정보량의 엄청난 팽창과 정보가 들이닥치는 속도를 아무 대가 없이 얻을 수 있다고 생각했다. 그건 착각이다.

"점점 진이 빠지게 됩니다."
수네가 말했다.

"더욱 중요한 것은, 우리가 모든 차원에서 깊이를 희생하고 있다는 겁니다.
깊이는 시간을 요구합니다.
깊이는 사색을 요구해요.

모든 것을 다 따라잡아야 하고 늘 이메일을 보내야 한다면 깊이를 가질 시간이 없어져요.
관계에서의 깊이도 시간이 필요합니다. 에너지가 필요해요. 오랜 기간을 필요로 하죠.
거기에 전념해야 해요. 주의력도 필요하고요.
깊이를 요구하는 모든 것이 악화되고 있어요.
그게 우리를 점점 더 표면 위로 끌 어올리고 있고요.”

- 덴마크 공과대학교 교수 수네 레만과의 대화

곧 수네의 논문에서 등장한 “주의력 자원의 더욱 빠른 소진”에 대해 말한다.

현대 사회에서 우리는 쏟아지는 정보에 자신들의 주의력을 통제하지 못하고 우리들의 주의력들을 가속해서 사용하고 있다고. 이것이 과연 우리들의 자의적인 선택이라고 하면, 글쎄, 부정적인 의견이 더 강하다.

곧 다음과 같은 이야기를 한다.

“주의력을 잘 인식하는 상류층들은 자신들의 한계 내에서 살아가고,

사회 구성원들은 조종에 저항할 자원이 부족해 조종당해 살 것이라고. “

너무 빠른 속도, 너무 잦은 멀티태스킹

1장은 멀티태스킹에 대한 내용이다.

그는 얼 밀러 (Earl Miller, 신경과학 분야 교수)의 우리 문화가

“산만함의 결과로 인지 능력 저하의 절체절명의 고비” 를 만들어 내고 있으며,

우리가 할 수 있는 최선은 주의를 산만하게 하는 것들을 최대한 줄이는 것이라고 한다.

“뇌는 근육과 같습니다. 어떤 부위를 많이 사용하면 할수록 연결이 강화되고, 더 능숙해지게 되지요”

그리곤 10분에 한 가지 작업만 수행한 다음 1분간은 집중을 풀고 다시 10분간 집중하라는 해결 방식을 제시한다. 점점 더 집중하는 시간을 늘려가면서 집중을 연습할 필요가 있다고 전달한다.

몰입의 손상

2장에서는 몰입에 대한 내용을 다룬다.

몰입에 대한 중요성을 크게 여기고 있어 집중해서 읽어갔다. 내용의 중반 쯤, 그는 본인이 경험한 몰입에 대해 다루었다.

하루의 초반에 몰입을 세 시간 하면,
나머지 시간에 느긋하고 열린 태도로 다른 활동을 할 수 있다는 사실을 알아차렸다.

나는 갑갑해하거나 짜증 내거나 핸드폰을 갈구하지 않고 해변을 따라 걷고 사람들과 수다를 떨고 책을 읽었다.
몰입이 내 몸을 이완하고 정신을 열어주는 듯 했는데,
아마도 내가 최선을 다했을을 자각했기 때문일 것이다.

전과는 다른 리듬에 몸을 맡기고 있는 기분이었다.

본인이 하지 못할 것 같은 일들을 하려고 할 때, 내 범위 내의 일들을 해나아갈 때의 몰입은 본인에게 강한 인상을 준다. 시간의 흐름을 느끼지 못하게 만들고 세상에 그 무엇도 느껴지지 않은 무자각의 흐름을 느낄 수 있다. 그 흐름은 힘든 일을 할 때에도, 흥미로운 일을 할 때에도 동일하게 온전히 나밖에 없다는 강력한 느낌을 준다. 끊을 수 없는 자극이다.

반면 우리의 집중력을 망치고 있는 SNS와 끊임 없는 알림들 같이.

잠들지 못하는 사회

3장

해당 챕터를 보면서 감각으로 느껴지는 감정들을 느꼈다. 요동치는 공감과 약간의 분노같은 것이었다.

잠들지 못하는 사회는 말그대로, 점점 더 빠른 것들을 요구하는 사회에서 사람들의 수면 시간이 단축되고 있다는 것이다. 우리는 언제부터인가, 핸드폰을 내려놓는 것을 ‘진짜 그만’의 마지노선에서 외치며 끝내곤 한다. 가벼운 의지만으로 힘이 들곤 한다는 것이다. 페이스북의 ‘무한 스크롤’의 등장을 생각해보자. 언제부턴가 끝임 없는 스크롤로 우리는 ‘이젠 끝’을 외치면서도 손가락을 멈추지 못하곤 한다. 그리곤 스스로를 탓한다. 왜 이렇게 멈추지 않았을까하는 후회의 말들을 뱉으면서.

수면 부족은 집중력에 큰 타격을 준다. 깨어있는 듯 보여도 뇌의 일부는 잠들어 있고 지속적인 사고가 불가능하다는 것이다. 눈을 뜨고서도 앞에 있는 사물을 제대로 인지하지 못한다는 말이다.

이루고 싶은 열망을 무엇이라도 하나 더 하라고 말하는데, 스스로를 위해서는 항상 잠을 충분히 자라고 한다. 어떨 때는 나보고 어떻게 하라는 건지 세상이 원망스럽다.

최근 읽은 책들은 항상 강조했다. 충분한 수면, 충분한 휴식이 반드시 필요하다고.

더 많은 것들을 배우고 싶고 알아가고자 하는 것은 욕심일 뿐일까?

이 사회에서 ‘잘’ 살아남기 위해서 충분한 수면은 정말 가능한가?

답장을 하지 않으면 스스럼 없이 잘못을 질책하는 친구들,

읽지 않은 메일들을 확인하라는 수 없는 알림,

다재다능한 인재를 원하는 높은 기준을 가지는 사회,

그에 걸맞는 성공한 사회 구성원이 되야 한다는 관념.

스스로 생각을 할 시간 조차 시간을 내야하는 하루에 지치기도 한다. 나를 위한 시간을 위해 엄격히 일정을 조율해야 한다.

“그렇게 열심히 살 필요가 없다”는 사람들의 말에 좌절하고 포기하는 삶을 가져야 할까.

아니, 그에 순응하면 그저 내가 바라보고 있는 평범한 사람들이 되는 것이다.

사회에 의해 굴러가는 쳇바퀴가 아닌 사회를 움직이는 톱니바퀴가 되고 싶다.

소설의 수난 시대

4장

책을 제대로 읽기 시작한 2년 전, 필요한 내용만 읽고 훑어 보는 읽는 현상이 커진다는 뉴스가 강한 사회의 경고로 느껴졌다. 정확히 본인이 언제부터인가 부분적으로 읽고 있는 것이다. 이 문제는 심각했는데, 이러한 읽기 방식이 본인의 의지로 조금 읽는 것이 아닌 모든 문장을 읽기가 힘들어 졌다는 것을 인지했을 때였다. 그렇게 진지하게 꾸준히, 책을 읽기 시작했다. 결과는 효과적이었는데, 이제는 한 자리에서 100페이지를 거뜬히 읽을 수 있다.

하지만 실제로 실천을 힘들어 하는 사람들이 다수 임을 알고 있다. 문제를 알고서도 바꾸는 것은 힘들다. 4장에서는 이 문제를 정확히 짚고 있는데, 아래의 비유가 그 문제를 쉽게 와닿게 할 것이다.

독서의 붕괴가 어떤 면에서는 집중력 감퇴의 증상이자 원인임을 깨달았다. 이러한 변화는 나선의 형태를 띤다. 우리는 책에서 어화면으로 이동하기 시작하면서 책에서 나오는 더 깊은 형태의 읽기 능력을 잃기 시작했고, 결국 책을 더욱더 안 읽게 되었다. 몸무게가 늘면 운동하기가 점점 더 어려워지는 것과 비슷하다.

사실 책 중에서도 ‘소설’을 독서하는 것에 대한 의구심을 갖곤 했는데, (허상일 뿐 본인의 인생에 도움이 될 수 있을까라는 의구심이었다) 이후, 소설이 공감 능력을 키우는 데 효과가 있다는 주장과 그를 뒷받침하는 연구 결과를 제시한다. 소설을 읽음으로서, 마치 일종의 공감 체육관처럼, 다른 사람의 머릿속에 있는 경험에 푹 빠져들고 그들의 상황을 그리고 공감하곤 한다.

산만함에 불을 지피다

7장

그렇다면 SNS (페이스북)가 ‘알고리즘’을 통해 우리들의 집중력을 훼손하는 방식은 무엇일까.

저자는 많은 사람들과 함께 인터뷰를 하며 알아낸 것들을 여섯가지로 정리한다.

또, 각 내용에 대한 타당한 연구 결과들을 이후 챕터에서 증명하고 있다.

첫째, 우리가 잦은 보상을 갈망하게끔 만든다.
피드에 게시글을 올리며, 좋아요와 댓글을 기대하는 것을 보면 쉽게 이를 인정할 수 있다.
혹은 내가 단 댓글에 누군가 대댓글을 남겨주진 않을지 공감의 좋아요를 누르고 가진 않을지 기대하는 것이다.
그리고 실제 누군가 좋아요를 누르거나 댓글을 달면 이로 그 갈증이 풀어지고 더 큰 갈증을 기대하게 되는 것이다.

둘째, 더 많은 전환을 만든다.
페이스북에서 인스타로 넘어가고 다양한 컨텐츠이 주제를 넘나 들며 작은 전환들이 꾸준하게 만들어진다.
책에서는 이 전환이 가져올 사고력 저하가 술이나 약에 취한 것만큼이나 나쁘다는 것을 다루었다.

셋째, 우리를 내침하여 학습한다.
우리가 좋아하는 것들, 싫어하는 것들, 흥분하는 것들을 분석하고 시기 적절하게 뚫고 들어온다.

넷째, 우리를 자주 화나게 만든다.
과학자들은 분노는 주변에서 벌어지는 논쟁에 평소만큼 집중하지 못하며, 정보 처리가 얕아짐을 발견했다. 실제로 페이스북이 내부에서 사회의 부정적인 영향을 끼치는 결과를 가지고 이를 감추고 대변하기 위한 과정을 진행 중이었다는 것을 책에서 다루며 이를 증명한다.

다섯째, 우리가 타인의 분노에 에워싸고 있다고 느끼게 만든다.
이 때문에 우리의 집중력은 그 걱정에 주의를 뺏고 주변의 집중에 어려움을 겪게 되는 일종의 각성 상태에 이르게 된다고 말한다.

여섯째, 사회 전체에 불을 지른다.
가짜 뉴스는 진짜 뉴스보다 여섯 배 더 빠르게 이동한다는 연구 결과가 있다.
실제로 SNS가 저지른 사회의 변화들을 많이 목격해 오고 있다.
성별 문제, 선거, 환경 오염 등 긍정과 부정의 선을 넘어 우리 사회로 크고, 격하게 다가오고 있다.

Kubernetes Deployment, 제대로 이해하기

gngsn — Sun, 17 Mar 2024 22:28:19 +0900

본 포스팅은 Kubernetes Core Concept 중, Deployment Object의 개념과 사용법을 익히도록 합니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

본 포스팅에서는 Kubernetes을 사용하며 반드시 알아야할 개념 중 하나인 Deployment를 살펴보고자 합니다.

Deployment?

A Deployment provides declarative updates for Pods and ReplicaSets

Deployment는 이름 그대로, 쿠버네티스에서 배포를 위한 객체입니다.

기능적으로는, Pod와 ReplicaSet를 배포를 관리합니다.

운영자가 Deployment에서 원하는 상태desired status를 설정하여 적용하면,

Deployment Controller가 현재 Pod 배포 상태를 변경하고자 하는 상태에 가까워 지도록 관리합니다.

현재는 대부분의 서비스를 운영함에 있어서

아래의 상황 등을 고려하여 안정적인 운영을 지향하곤 합니다.

✔️ 배포된 파드 업데이트

✔️ 새로운 애플리케이션 릴리즈

✔️ 무중단 배포

쿠버네티스에서는 각종 고려되는 상황들을 반영하여,

안정적인 배포 뿐만 아니라, 배포 과정을 한 번 선언해두면 항상 동일한 방식으로 배포가 진행되도록 합니다.

그럼, 쿠버네티스에서 배포는 어떻게 진행할 수 있을까요?

애플리케이션을 업데이트하고 싶을 때, 모든 Pod에 변경 사항을 쉽게 반영하기 위해

Pod의 상위 계층인 ReplicaSet 에 변경 사항을 적용할 수 있습니다.

ReplicaSets를 통해 안정적으로 파드 개수를 유지시키고,

하나의 파드에 장애가 발생했을 때, 트래픽을 정상 동작하는 파드로 조정하여 안정적인 파드 운영을 도와줍니다.

하지만 업데이트를 반영 시, 여러 ReplicaSet 모두에 반영을 하려고 할 땐 어떨까요?

가령, 공통 모듈 내 DB·서버·프론트와 같이 3개의 애플리케이션에 해당하는 ReplicaSet들을 하나씩 업데이트 하는 방법도 있을 텐데요.

문제는 서버 다음 프론트를 업데이트 한다고 했을 때,

서버가 v2인데 DB와 프론트는 아직 v1인 내용을 반영한다면 장애가 발생할 수도 있습니다.

위 방식이 아닌, 공통 모듈의 모든 구성요소가 한 번에 업데이트되고, 항상 동일한 조건의 배포를 통해 진행되는 것을 선호할 것입니다.

ReplicaSet보다 더 높은 계층인 Deployment 를 배포함으로써, 안정적인 업데이트를 진행할 수 있습니다.

쿠버네티스에서는, Deployment 정의 파일을 구성하는 방법이, 배포 방법과 동일하기 때문에,

Deployment 정의 구성을 알아가며 배포 방식을 이해하도록 하겠습니다.

Deployment YAML

Deployment를 생성하는 Manifest YAML 파일을 어떻게 구성할 수 있는지 알아보겠습니다.

공식 문서 예시를 참고했습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment          # ❶
  labels:
    app: nginx
spec:
  replicas: 3                     # ❷
  selector:                       # ❷
    matchLabels:                  # ❷
      app: nginx                  # ❷
  template:
    metadata:
      labels:
        app: nginx                # ❸.①
    spec:                         # ❸.②
      containers:                 # ❸.②
      - name: nginx               # ❸.③
        image: nginx:1.14.2       # ❸.②
        ports:
        - containerPort: 80

❶ Deployment 이름

Kubernetes는 .metadata.name를 참고하여 nginx-deployment를 생성합니다. 이 이름은 나중에 생성될 ReplicaSets 나 Pods 의 기초가 됩니다. 자세한 내용은 이후 Deployment Spec 을 설명할 때 다루겠습니다.

❷ ReplicaSet 정의

Deployment는 .spec.replicas 를 참고하여 ReplicaSet이 생성·관리할 Pod의 개수를 설정합니다. .spec.selector는 생성된 ReplicaSet이 어떤 Pod을 관리할지 지정합니다. 위 경우, 파드의 템플릿 app: nginx 로 정의된 레이블을 찾습니다. 파드 템플릿 규칙을 살펴보면, 조금 더 정교하게 규칙을 설정할 수 있습니다.

FYI. matchExpressions
.spec.selector.matchLabels 필드는 {key, value}의 쌍으로 정의합니다. 비슷하게, matchExpressions를 사용할 수 있는데요. matchExpressions는 정교한 조건을 담아selector를 설정할 수 있습니다.
이 때, matchLabels 에 정의된 {key, value} 쌍은, matchExpressions에 { key: ≪key≫, operator: In, values: ≪value≫} 를 입력하는 것과 동일합니다. 즉, key 필드는 matchLabels의 "key"값을, operator는 "In", values 는 matchLabels의 "value"를 명시하는 것과 동일합니다.

❸ Template 정의

템플릿의 필드는 다음과 같은 하위 필드들을 포함합니다:

❸.①: Pod는 .metadata.labels를 통해 app: nginx로 라벨링됩니다.
❸.②: 파드 템플릿을 정의하거나 .spec.template.spec 필드에 명시한 내용들은 하나의 컨테이너에서 동작한다는 것을 의미합니다. 위 예시에서는 파드가 nginx:1.14.2 이미지를 사용하여, nginx 이름으로 Port 80에서 생성시키라는 설정입니다.
❸.③: .spec.template.spec.containers[0].name에 nginx을 설정함으로써,nginx 명의 컨테이너가 생성됩니다.

Deployment command

✔️ NGINX Pod 생성

❯ kubectl run nginx --image=nginx

✔️ POD Manifest YAML file 확인 (저장 x)

❯ kubectl run nginx --image=nginx --dry-run=client -o yaml

-o yaml: POD Manifest YAML file 생성

--dry-run: Don't create it

✔️ Deployment 생성

❯ kubectl create deployment --image=nginx nginx

--image: 생성할 image 명시

✔️ Deployment Manifest YAML file 확인 (저장 x)

❯ kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

-o yaml: POD Manifest YAML file 생성

--dry-run:Don't create it

--image: 생성할 image 명시

✔️ Deployment Manifest YAML file 생성

❯ kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml

-o yaml: POD Manifest YAML file 생성

--dry-run`: Don't create it

--image: 생성할 image 명시

>: 다음 인자로 입력한 이름으로 파일 저장

✔️ Deployment 생성 with Yaml File

❯ kubectl create -f nginx-deployment.yaml

특정 Manifest 파일 생성/수정 후 생성

✔️ (k8s version 1.19+) Deployment 생성 with Yaml File

❯ kubectl create deployment --image=nginx nginx --replicas=4 --dry-run=client -o yaml > nginx-deployment.yaml

--replicas : replicas 개수 지정

Use Case

실제 Deployment는 어떤 식으로 사용하는지 사용 사례들을 알아보며 감을 익혀도록 하겠습니다.

✔️ ReplicaSet 배포

ReplicaSet는 내부에서(background) Pod를 생성하며, 배포 과정 상태를 체크할 수 있습니다.

✔️ 새로운 상태의 Pod 선언

Deployment의 PodTemplateSpec를 업데이트해서 새로운 상태를 선언합니다.

새로운 ReplicaSet가 생성되고 Deployment는 속도를 제어하며,

Pod가 이전 ReplicaSet에서 새로운 ReplicaSet 하위로의 이동을 관리합니다.

각각의 새로운 ReplicaSet은 Deployment의 수정을 반영합니다.

✔️ Rollback

현재 배포 상태가 안정적이지 않은 경우 이전 배포 개정판으로 롤백합니다.

각 롤백은 배포 수정 버전을 업데이트합니다.

✔ Deployment 스케일 업

더 많은 부하를 견디기 위해 Deployment를 스케일 업합니다.

✔️ 배포 진행 확인

Deployment의 상태를 통해, 배포가 정상인지를 나타내는 지표로써 사용합니다.

✔️ ReplicaSet 정리

더 이상 필요 없는 이전 버전의 ReplicaSet 세트를 정리합니다.

| Reference |

Kubernetes.io - Official Docs

Udemy: certified-kubernetes-administrator-with-practice-tests

| Hacks | conda - Python multiple venv manger

gngsn — Sat, 9 Mar 2024 13:06:01 +0900

miniconda: 여러 버전의 python 혹은 package가 설치된 환경을 쉽게 관리하는 툴

가령, 여러 가상 환경들의 목록을 조회하고, 생성하고, 내보내고, 제거하거나 업데이트할 수 있습니다.

서로 다른 환경을 쉽게 활성화하거나 전환할 수 있습니다.

또, 환경 파일을 공유할 수도 있습니다.

❯ python venv ≪new-virtual-env≫ 
❯ source ./new-virtual-env/bin/activate

위와 같이 반복되는 기존 명령어를 한 번에 정리해둔 셈이죠.

본 포스팅은 기록 겸 여러 miniconda 명령어들을 정리해두기 위해 작성되었습니다.

# brew를 통한 conda 설치
❯ brew install miniconda

# conda 초기 설정
❯ conda init «SHELL≫
# ex.conda init zsh

# 특정 python 버전 지정 생성
❯ conda create -n «venv-name≫ python=3.12

# 생성 확인: 등록된 conda 가상 환경 목록 출력
❯ conda env list

# 생성한 가상환경 활성화
❯ conda activate «venv-name≫

ERROR: conda init 시 No action taken. 오류

conda activate .. 명령어 입력 시 conda init 이 먼저 필요하다는 안내가 나오는데,

❯ conda activate base

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'. 
To initialize your shell, run 

    $ conda init <SHELL_NAME> 

Currently supported shells are: 
  - bash 
  - fish 
  - tcsh 
  - xonsh 
  - zsh 
  - powershell 

See 'conda init --help' for more information and options. 

IMPORTANT: You may need to close and restart your shell after running 'conda init'.

하지만, conda init ≪current-shell-name≫ 명령어를 입력하세요

❯ conda init
no change     /opt/homebrew/Caskroom/miniconda/base/condabin/conda
no change     /opt/homebrew/Caskroom/miniconda/base/bin/conda
no change     /opt/homebrew/Caskroom/miniconda/base/bin/conda-env
no change     /opt/homebrew/Caskroom/miniconda/base/bin/activate
no change     /opt/homebrew/Caskroom/miniconda/base/bin/deactivate
no change     /opt/homebrew/Caskroom/miniconda/base/etc/profile.d/conda.sh
no change     /opt/homebrew/Caskroom/miniconda/base/etc/fish/conf.d/conda.fish
no change     /opt/homebrew/Caskroom/miniconda/base/shell/condabin/Conda.psm1
no change     /opt/homebrew/Caskroom/miniconda/base/shell/condabin/conda-hook.ps1
no change     /opt/homebrew/Caskroom/miniconda/base/lib/python3.12/site-packages/xontrib/conda.xsh
no change     /opt/homebrew/Caskroom/miniconda/base/etc/profile.d/conda.csh
no change     /Users/gyeongsun/.bash_profile
No action taken.

conda init 명령어에 shell 을 누락하고 입력하면 conda init 을 하고 conda activate 를 해도 init 을 요구합니다.

몇몇의 글에서 conda init 으로 안내하고 있어서 default인 bash가 아닌 경우 해당 명령어를 놓친 것입니다.

Kubernetes Architecture, 제대로 이해하기

gngsn — Sun, 3 Mar 2024 20:14:16 +0900

본 포스팅은 Kubernetes Architecture 를 이해하고 구성 요소들의 개념과 역할을 이해하는 것을 목표합니다.

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

본 포스팅에서는 Kubernetes 혹은 K8s 을 살펴보려 합니다.

이론과 실습 중 무엇이 선행되어야 할지 생각해봤을 때,

제 기준에서 Kubernetes는 개념 정도만 먼저 알아보고, 실제로 사용해보며 깊이 들어가는 것이 좋지 않을까 싶습니다.

어떤 역할을 하는, 왜 생겨난 서비스인지를 파악한 후, 무작정 따라해보고 이유를 찾아가며 배우면 좋을 듯 합니다.

그럼 지금부터 쿠버네티스 아키텍처에 대한 전반적인 내용을 살펴보도록 하겠습니다.

Kubernetes의 목적은 컨테이너들을 배포 및 운영 스팩을 미리 정의해두어

자동 배포, 스케일링, 관리할 목적의 오픈 소스 시스템입니다.

TL;DR

Kubernetes의 클러스터에는 아래와 같이 여러 개의 구성 요소가 있습니다.

요약하자면, 가장 상위 개념으로, Master Node와 Worker Node가 있습니다.

쿠버네티스에서, 각각을 Control Plane 과 Data Plane으로 부를 수 있습니다.

Master Node에는 클러스터에 대한 정보를 저장하는 etcd가 있습니다.

Node에서 애플리케이션이나 컨테이너 스케쥴링을 담당하는 Kube-scheduler 이 있습니다.

Node Controller, Replication Controller 등 다양한 기능을 처리하는 다양한 Controller가 있습니다.

클러스터 내의 모든 작업을 컨트롤하는 역할을 하는 Kube API 서버가 있습니다.

Worker Node에는 Kube API 서버의 명령에 따라 컨테이너를 관리하는 Kubelet과,

클러스터 내의 서비스 간 통신을 가능하게 하는 Kube Proxy가 있습니다.

Architecture

Kubernetes의 클러스터에는 아래와 같이 여러 개의 구성 요소가 있습니다.

Control Plane / Master Node
- Etcd
- Scheduler (kube-scheduler)

- Controller Manager

- Kube API Server

Data Plane / Worker Node

- kubelet

- kube-proxy

Container Runtime Engine

위 다이어그램을 보면 복잡해 보여서 덜컥 포기하고 싶어질 수 있는데요.

쉬운 이해를 위해, 각 요소를 실제 화물선 운반과 비교해 보도록 하겠습니다.

두 개의 화물선이 있다고 가정해봅시다. 각 화물선에는 많은 컨테이너들을 싣고 있습니다.

https://medium.com/devopsanswers/kubernetes-the-easy-way-19f69e57738d

Master Node

컨테이너를 어느 화물선에 실을 지, 혹은 화물선들의 방향을 조정하고 모니터링 등의 관리를 위한 모선(mastership)이 필요합니다.

이 관리는 다른 화물선들과는 다른 공간에서 구별되어 운영되곤 하는데,

Container 관리 시의 Master Node와 동일합니다.

이처럼 관리를 위한 Master Node는 쿠버네티스 클러스터를 관리하는 Controle Plane의 역할과 동일합니다.

서로 다른 노드에 대한 정보를 저장하거나, 컨테이너를 배치 시키고, 노드와 컨테이너들을 모니터링합니다.

Etcd

수 많은 컨테이너들이 운행될 경우, 몇개의 화물선에 얼마나 많은 컨테이너가 있는지에 대한 정보가 필요한데요.

이 모든 정보는 ETCD 라는 높은 가용성의 key-value 스토리지에 저장됩니다.

추후 이어질 포스팅에서, Etcd에 어떤 데이터가 어떠한 방식으로 저장되는지 알아볼 필요가 있습니다.

Kube-scheduler

모선(mastership)에 있는 컨테이너들을 화물선에 할당할 때, 크레인을 사용해서 컨테이너를 옮깁니다.

이 크레인은 특정 컨테이너가 어떤 화물선에 배치되어야 하는지를 식별할 수 있습니다.

가령, 해당 화물선의 수용량이나 특정 화물선에 이미 선박된 컨테이너가 몇 개 있는지,

혹은 화물선의 목적지, 운반 가능한 타입인지 등의 조건들을 이미 알고 있는 것이죠.

https://www.freepik.com

바로 이 크레인이 kube-scheduler 의 역할입니다.

쿠버네티스에서 스케쥴러는 큰 역할을 담당하기 때문에,

추후 포스팅에서 스케쥴 과정에 대한 내용을 깊이 파는 시간을 갖겠습니다.

Controller Manager

이 모선(mastership)에는 또한, 특정 운영에 특화된 업무를 맞는 부서들이 있습니다.

가령, 운영 부서는 각 화물선의 화물 수를 조정하거나, 트래픽을 통제하는 등의 일들을 합니다.

어떤 팀은 이슈를 처리하거나 경로에 맞는 화물선으로 경로를 조정하는 등의 일들을 처리하곤 합니다.

쿠버네티스에서도 비슷하게 서로 다른 영역 들에 특화된 컨트롤러들이 존재합니다.

가령, Node Controller는 노드를 관리합니다. Replication Controller들은 레플리케이션 그룹에 동시에 할당되어야 하는 개수(desired number)에 맞춰 새로운 노드들을 클러스터에 할당하거나 제거합니다.

Kube API Server

그런데, 지금까지 쿠버네티스 클러스터의 Master Node 내 컴포넌트들은 어떻게 서로에게 정보나 상태를 전달할까요?

Kube API 서버가 바로 이 커뮤니케이션의 중추가 됩니다.

Kube API 서버는 클러스터 내 모든 오퍼레이더들을 오케스트레이팅합니다.

외부 사용자들에게 Kubernetes API를 노출시켜,

워커 노드들이 해당 서버와 커뮤니케이션할 수 있게 하여 클러스터의 운영을 관리합니다.

클러스터의 상태를 모니터링하기 위해 요구되는 필요한 변경 사항을 반영합니다.

Container Runtime Engine

이렇게 쿠버네티스 세상에서는 모든 것들이 컨테이너로 동작합니다.

그래서 모든 환경 또한 컨테이너에 맞게 동작되게 됩니다.

전체 시스템을 관리하기 위한 형식의 서로 다른 컴포넌트들은 컨테이너의 형식으로 호스팅될 수 있습니다.

또, DNS 서비스 또한 컨테이너 형식으로 배포됩니다.

이 모든 컨테이너들을 실행시킬 소프트웨어가 필요한데, 바로 컨테이너 런타임 엔진입니다.

대표적으로 Docker가 있습니다.

그래서 쿠버네티스 클러스터들의 모든 노드들이 컨테이너 환경에서 실행되기 위해 Docker가 필요한 것입니다.

만약 컨테이너로 실행시키길 원한다면 Master Node 또한 포함된 환경을 말합니다.

쿠버네티스는 Docker 뿐만아니라 다른 Runtime Engine으로 Container 나 Rocket 등을 지원합니다.

Worker Node

이 번엔, 각각의 화물선에 조금 더 집중해보도록 하겠습니다.

kubelet

모든 화물선에는 선장이 있습니다. 선장은 이 화물선의 모든 이벤트들을 관리합니다.

선장의 주요 임무는 모선(mastership)과 통신하며 모선에게 다른 그룹에 합류할 의사나,

해당 화물선에 적재되는 컨테이너들에 대한 정보를 받는다거나,

적절한 컨테이들이 필요 시 적재할 수 있는지를 알려주고 해당 화물선이나 컨테이너 들에 대한 상태에 대한 보고를 마스터로 부터 받습니다.

쿠버네티스의 kubelet이 바로 쿠버네티스 내의 선장의 역할입니다.

kubelet은 클러스터 위의 각 노드에서 실행되는 Agent입니다.

Kube API 서버로부터 오는 지시 사항을 듣고, 필요할 때 컨테이너를 배포하거나 제거합니다.

Kube API 서버는 주기적으로 노드의 상태나 해당 노드의 컨테이너의 상태를 모니터하기 위해 kubelet으로 부터 상태값을 가져옵니다.

Kube Proxy Service

하지만, Worker node에서 실행되고 있는 애플리케이션은 종종 다른 Worker Node와 통신하고 싶어질 수 있습니다.

가령, 웹 서버가 한 컨테이너에서 실행될 때 다른 워커 노드에서 실행 중인 데이터베이스와 연결하고 싶을 때가 있죠.

Kube Proxy Service는 Worker Node에서 실행 중인 컨테이너가,

서로 통신할 수 있도록 작업자 노드에 필요한 규칙이 있는지 확인합니다.

그럼 다음에는 각 구성 요소를 더욱 상세한 내용으로 소개하는 포스팅으로 만나뵙겠습니다.

| Ref. |

Udemy: certified-kubernetes-administrator-with-practice-tests

2023년 회고

gngsn — Mon, 1 Jan 2024 18:29:26 +0900

2023년 돌아보기

이번 해에는 마치 세상의 주인공이 된 것처럼 믿기지 못할 일들이 일어났다.

먼 훗날에도 가슴 한편에 자리 잡을 다양한 일들이, 커다란 마일스톤이 된 해였다.

많은 일들을 다 적지 못하는 게 아쉽지만,

본 글은 본인의 성장 과정을 적는 기회로 가져가려 한다.

1/ 경험

일 년 전, 세상이 너무 좁게 느껴졌다.

기술 공부로는 해결되지 않는 무엇인가였다.

세상을 배우고 싶었고, 미지라는 두려움을 이겨내고 싶었다.

22년에 정한 23년의 KPT - Keep 중 '도전'이 있었다.

계속해서 도전하자.
도전이 만드는 그려지지 않은 미래가 무섭고, 두렵다.
안주하는, 안정적인 삶도 나쁘지 않다.

하지만 지금 본인의 시기에는 아니다.
조금이라도 어릴 때, 조금이라도 더 큰 수용력을 가질 때, 성장의 추진력이 생겼을 때 더 멀리 나갈 수 있다.
지금은 실패를 경험해 볼 시기고, 다양한 범위로 도전해 볼 수 있는 시기다.
이 시기에 있음을, 또 이 사실을 깨달았음을 즐기며 도전하자.

- 2022년 회고 KPT 중 KEEP

그래서, 본인을 두려움 속에 던지곤 했다.

끝없는 도전이 본인의 생각을 단단하게 만들길 원했고,

세상을 배워가며 결정의 선택지를 넓히고 싶었다.

그렇게, 경험이 주는 배움이 도전을 멈추지 못하게 했다.

결국 아무것도 아니다.

내가 걱정하고 고민하는 것들이 결국, 어떤 형식으로든 지나갈 일이라는 걸 확인했다.

두렵다고 하지 못할 것 같다는 생각은 결국 본인이 만들어낸 벽이었던 것이다.

안일하고 싶다는 생각도, 도전이 꼭 필요한가라는 생각도 계속 든다.

세상에 대한 호기심이 많은 성향이,

통찰력을 얻고 싶은 성향이 본인을 이렇게 이끌고 있는 것 같다.

정답 없는 세상에 지혜를 질문하는 것이 더 많은 경험을 요구한다.

-- 도전

언젠가, 울고 싶을 만큼 본인의 영어 실력이 부족하게 느껴졌다.

힘든 시간을 겪어야 하는 걸 알고 있는데도, 이렇게나 힘들 수 있구나, 새삼 느꼈다.

한 번은 이런 생각을 했다.

한국에서만 평생 살아도 영어 없이 행복할 수 있다. 무수한 사람이 행복해왔다.

그렇다면 영어를 포기하는 게 맞을까?

모든 도전에서 이런 과정이 있곤 한다.

굳이 하지 않아도 되는 일.

어떤 도전을 하던지, 그 도전을 하지 않았을 때도 충분히 잘 살아갈 수 있다.

본인은 이런 생각을 한다.

어쩌면 아주 사소한 일들이 검은 장막에 가려져 두려운 것으로 생각하며 지낼지도 모른다.

지금 해보지 않은 일들은 두고두고 생각날 것이다.

몇 년 후 본인은 했던 일보다 하지 않았던 일로 인해 더 실망할 것이라고.

# 혼행

혼자 여행

문뜩 정신나간 짓들을 해보고 싶었다.

3일 뒤의 비행기 티켓을 무작정 구매하고 모든 절차들을 신속히 해결해 나갔다.

공항으로 가기까지 준비되지 않은 일들이 있어도 걱정하지 않기로, 스스로 약속했다.

외부에 의존하지 않는 내면의 강인함을 갖고 싶었던 것 같다.

혼자라도 할 수 있다는 자신감, 스스로의 신뢰가 필요했다.

무작정 태국을 가보고 무작정 걸었다.

예상치 못한 일들에 긴장과 기쁨이 산발적이고 다발적인 여행이었다.

현지인과 대화하는 것을 즐겼다.

무작정 몽골을 가보고 직접 보고 느꼈다.

유목민 거주지에 머물고 자연을 보고 담았다. 한국과는 전혀 다른 세상에서 가슴 뛰는 경험들을 했다.

혼자 해결할 수 있다는 자신감을 느꼈다.

내가 세상을 배우는 만큼, 내가 깨달은 것만큼이 나의 세계가 되었다.

새로운 경험들을 좇다 보니,인생에서 잊히지 않을 추억들을 쌓았다.

인생의 목표가 무엇이냐고 한다면, ≪인생을 잘 살아가는 것≫이라고 말하고 싶다.

인생의 끝에서 인생이 어땠냐라고 물었을 때,

“수도 없이 많은 이야기들로 가득 찬 정말 재밌는 과정이었다 −”고 할 수 있도록.

현재에 최선을 다하고, 세상을 배우며,

본인의 존재가 스스로에게 자부심이 되는 인생이 괜찮을 것 같았다.

현재에 집중해서 많은 재미들을 만들어 가고 이루어 가는 게 대답이었다.

훗날 이 글을 다시 본다면, 20대 중반의 본인은 이런 생각을 갖고 있었음을 기억하고 싶다.

인생을 만들어 가는 방법은 참 다양하다.

혹자는 남편이 아주 늦게 들어오더라도 매일 저녁밥을 차려주는 것이 행복일 수 있다.

혹자는 휴가를 아끼고 아껴 가족들과 여행을 떠나는 것이 행복일 수 있다.

이미 이 사람들은 −어쩌면 본인도 모르게 − 인생에서의 본인의 행복을 찾은 것이다.

그래서 다른 사람들이 행복해 보인다고,

나보다 잘 살아 보인다고 부러워할 필요가 없다.

다른 사람의 행복과 당신의 행복은 다르니 비교할 수 없다.

나는 셰익스피어에 필적하는 책을 쓸 수 없다.
하지만 내 책이라면 쓸 수 있다.
- Walter Raleigh

# 언어

영어를 배우는 것을 즐기기로 했다.

달리고 달려도 머물러 있는 것 같은 느낌이 들곤 한다.

세상에는 원어민처럼 말하는 사람이 너무나도 많은데, 본인은 한없이 머물러 있다는 기분이 들 때,

하고 싶은 말이 머릿속에 가득한데, 이를 표현할 능력이 부족함을 맞닥뜨릴 때마다 멍청한 기분이 들었다.

실수를 할 때마다, 틀렸다는 생각이 머리를 떠나질 않았다.

이 기분을 떨치고 싶었다.

이 생각을 다른 생각으로 바꿨다.

실수해도 된다는 것

틀리면서 성장한다는 것

왜 틀리면 본인을 나무라곤 할까.

배우는 과정에서 실수는 당연한데 말이다.

배우는 과정은 결코 짧게 끝날 수 없는데,

그 기간마다 본인을 나무란다면 너무 혹독하다.

이제껏 필자에게 해온 것처럼.

실수를 잘못이 아닌 실수로 받아들일 수 있도록.

2/ 이직

이직을 했다. 일 년 전 회고를 보아하니, 이제 막 회사에 첫 입사한 신입이 벌써 이직을 하고 반년이 채 안 됐다. 1년 4개월이라는 짧은 회사 생활 끝에 새로운 시작을 맞이했다.

이직 준비 전, 가장 먼저 했던 건 스스로에게 질문을 던지는 것이었다.

인생의 목표를 가는 과정의 한 부분으로써,

현재 시점에 하고 싶은 일이 무엇인지 찾아보았다.

기술적 성장, 배울 수 있는 환경을 물론 중요하게 두었지만,

인생 전반에 도움이 될 만한 도메인이었으면 했다.

그래서 경제 지식을 얻을 금융 쪽이나,

언어 경험을 얻을 외국계 기업에 관심이 갔다.

# 이직 과정

이직을 준비하면서, 계획을 먼저 세웠다.

큰 틀을 잡고 준비하는 것이 본인에겐 안정적인 마음을 주었다.

먼저, 나를 먼저 파악했다.

자신감을 높여줄뿐만 아니라, 이직이라는 여정을 시작하는 가장 기반이라고 생각했다.

본인 신뢰는 곧 자신감이 되어 추진력을 주었다.

5월에 준비한 AWS 자격증을 얻고 나서, 포트폴리오를 정리했고, 면접을 준비한 후 7월에 입사했다.

증명할 수 있는 학습 결과가 필요했고, AWS 자격증 목표를 앞당겨 취득했다.

그동안 진행했던 프로젝트를 어떻게 성공시켰고 무엇을 배웠는지 그 과정과 결과를 적었다.

과정은 역시나 쉽지 않았다.

노력해야 할 것도 많았고, 답이 없는 답을 구하려 애썼다.

# 면접

면접 준비는 길게 하지 않았는데, 흔한 질문들을 정리하며 본인의 생각과 가치관을 조금 더 알아가는 시간을 가졌다. 질문에 대한 대답을 정리하면서 어떤 질문이 들어와도 유연하게 준비해둔 내용을 연결시켜 대답할 수 있도록 대답들을 정리해갔다. 하나의 에피소드가 다양한 질문에 대한 대답이 될 수 있게끔 말이다.

결국 가장 많이 했던 건, 본인이 말하고자 하는 것의 '왜' 였다. 본인이 가장 열심히한 프로젝트의 이유, 난관을 겪은 이유, 해결해나간 방향성에 대한 타당성 등 "내가 왜 이렇게 했었을까?"를 생각했다.

이전에 면접에서는 "잘 보이고 싶다"는 마음이 컸다. 좋은 방향으로, 정답일 것 같은 대답을 해야할 것 같다는 생각이 커서 부자연 스러웠다. 본인의 생각이 무엇인지 생각하기 보다는 정답이 무엇일까를 생각하느라 긴장했다. 이후에는 "본인은 이런 사람이다"를 말하며 얼마큼의 가능성이 있는지를 알려주고, 조화롭게 어울릴 수 있음을 말하는 자리가 됐다. 그러니 긴장도 서서히 줄었고, 자신감이 생기며 좋은 인상을 주기도 했다.

기술 질문은, 진행했던 프로젝트들에서 전달하고 싶은 내용들을 추려냈다. 가령, 힘들었던 점이나 배운점 다시 한다면 더 개선할 점 등의 이미지를 그렸다. 본인이 직접 경험한 일들을 한 번 정리해보는 것과 안하는 것의 차이는 크기 때문에 하나의 스토리를 처음부터 끝까지 완전히 적어봤다. 질문에 대한 대답을 하지 못할 때는 대화를 시도했다. 모르겠다는 말과 함께 어떻게 해결해 나아갈지를 질문하는 것이다. 결국엔 함께 일할 사람들과 얼마나 말이 잘 통하냐가 중요하기 때문에 의사소통 능력을 보여주려고 했고, 면접자 중에 질문을 하는 사람이 드물기 때문에 강한 인상을 주기 쉽다고 생각했다.

인성 질문도 비슷하게, 흔한 면접 질문들 리스트들을 생각해보고 몇 가지 대답만을 준비했다. 질문들은 사실 보고자 하는 핵심 가치가 어느정도 상통된다. 본인의 성장 가능성, 전망, 실력, 사회성 등이다. 미래에 대한 설계, 본인이 하는 노력, 팀원들과 어울릴 줄 아는 사회성 등에 대해 계속해서 생각해보는 것이다. 거짓은 삼가하는 것이 좋겠다. 진정성을 가질 필요가 있다. 진정성 없는 답변은, 면접의 질문이 깊어질 수록 어려움을 겪는다.

# 실패를 이겨내는 법

개인적인 의견으로는, 면접을 준비하는 것은 가치있다.

아니, 가치 있는 과정으로 이끌 수 있다.

결국 나를 알아가는 과정이다.

스스로 원하는 것이 무엇이고, 본인의 장단점은 무엇이며, 주변과의 관계는 어떤지를 생각해본다.

굳이 겪지 않아도 될 어려움이라면 상관없을 수도 있지만,

피할 수 없는 면접이라면 성숙함을 얻을 수 있는 하나의 과정이며,

스스로를 탐구하는 값진 시간이라고 보는 것도 좋을 것 같다.

면접에서 떨어졌다고 본인의 탓을 하지 않는다.

본인은 충분한 노력을 했고, 될 때까지 할 것이다.

어차피 성공할 때까지 도전할 스스로를 믿는다.

면접에서 떨어졌을 때,

의연히 스스로를 뒤돌아보면 된다.

모든 사람들의 성격이 각각 다른 형태를 띄듯이 각기 다른 희망 사항이 있을 것이다.

혹자는 신기술에 빠져있는 트렌디함을 원할 수도 있지만, 반대로 검증된 언어에 대한 깊은 지식을 요구할 수 있다.

또, 열정 넘치는 팀원을 원할 수도 있지만, 너무 열정 많은 사람이 부담스러운 사람들도 있다.

중요한 능력은, 객관적으로 스스로를 볼 줄 아는 것 아닐까.

부족한 부분이 보인다면 보완해야 한다.

인성 질문에 말문이 막힌다면 스스로를 잘 파악한 게 맞는지 확인해야 한다.

본인이 떨어졌다는 감정을 터는 것은 어려우니, 오히려 그 원인을 깊이 파보는 것이다.

어느 때는, 막연한 우울함이 들 때 객관적인 시선이 기분을 떨쳐주곤 한다.

결국 두려움은 무지에서 오니.

-- 변명

어느새부턴가 변명을 멀리했다.

시간이 부족하다고, 아직 본인은 안된다고 하는 말들을 하지 않게 됐다.

성공해낼 본인을 믿고 의지를 가지면 된다.

의지를 가지면 모든 걸 다 할 수 있다는 것은 아니다.

본인이 할 수 있는 만큼을 생각해 보고, 그 일들을 해 나아가는 것이다.

그렇게 실수들과 실패들을 겪고 드디어 이뤄내는 것이다.

아직은, 하고 싶은 것들이 많다.

그래서 많은 것들을 이루어 가고 있다.

잠을 못 자서 피곤하고, 종종 과하다 싶을 때도 있긴 하지만.

변명을 하기 시작하면 평범해지는 것이다.

3/ 적응

예상보다 빠르게 이직에 성공한 후, 하반기 목표를 '적응'으로 적었다.

23년 후반엔 목표를 위해 무작정 달렸다.

회사를 다니며 기술 공부, 모임 스터디, 기술 포스팅, 영어 학습, 언어 교환, 독서, 운동, 회사 적응 등 했다.

그러다 문제가 생겼다. 적은 수면시간에, 하루를 꽉 채운 스케줄로 몸뿐만 아니라 정신까지 힘들었다.

그럼에도 불구하고, 이 삶을 포기하질 못했다.

꾸준한 운동이 주는 자신감

회사 일을 하는 값진 시간

블로그 포스팅의 성취감

기술 학습으로부터 오는 성장

다양한 문화를 배우는 즐거움

독서를 통한 인생의 가르침

모든 일들을 다 하고 싶어 하니 물리적인 시간이 부족했다.

쇼펜하우어가 인간은 욕망의 동물이라고 했던 게 이걸까 느끼며 웃기기도 했다.

반대로, 본인의 의지로 하루를 살아가는 노력을 보면, 또 그의 철학이 주장하는 내용이긴 하니 의아해진다.

---

어떤 것을 포기해야 할지 고민 중이다.

그저, 내 삶에 맞는 하루를 찾아가는 과정 중 하나인 것 같다.

부지런한 삶을 살아보는 건 인생의 가장 어린 나이에 해보면 좋으니 지금 해보자고 생각하곤 한다.

힘들다는 생각보다는 이렇게도 살아보고 저렇게도 살아봐야 직접 느끼고 경험해 봐야 알 것 같다.

삶을 어떻게 살아갈지 직접 느끼고 고쳐나가는 것,

이를 의식하며 재미를 느낄 줄 알고 싶다.

무섭지만, 많은 실패를 겪어보고 무지에서 오는 두려움을 떨쳐내는 데 익숙해지려고 한다.

견딜 수 있는 실패의 무게가 커지는 과정이 필요하다.

더 큰 어려움을 떨쳐낼 수 있는 단단함을 키우는 것이다.

나이가 더해질수록 내면의 견고함이 더욱 커지는 어른으로 성장하고 싶다.

현재의 노력들이 어떤 형태로, 언제까지 이어질지는 모르겠다.

본인의 의지, 본인의 열정, 본인의 체력.

쉽게 오지 않을 이 모든 자원들이 존재할 때 최선을 다하고 싶다.

어리다는 생각을 하지 않을 때까지,

인생을 배우는 것보다 인생을 알려줄 게 많은 사람이 될 때.

KPT 2024

2023년의 KPT를 생각해보면,

중간에 바꾼 목표도 많았고, 우선순위가 높아진 것들도 많았다.

사실 목표 중간점에서는 이룬게 없어 보였다.

글을 쓰는 빈도도 적어졌고, 포기한 게 많았다.

신기하게도 결론적으론, 꽤나 만족을 느낀다.

정리해보면 그만큼 시도해본 게 많았다.

막상 정리해보니 본 글에 모두 적지 못할 만큼 몰입했던 것들이 정말 많았다.

새로운 경험을 얻었고, 방향을 계속해서 바꿔 나아갔다.

23년을 기반으로 24년의 목표를 제대로 잡아보자.

Keep

영어 환경을 만들자.

환경을 만들어 갔던 건 잘했던 일이다.

부딪히며 배워나가는 것 만큼 빠르게 성장하는 것도 없는 것 같다.

24년에는 이런 환경을 유지하고 잘 관리하고자 한다.

책 읽기

인생에 궁금증이 생길 때마다 해답이 될 것 같은 책을 읽곤 했다.

항상 답이 있던 것도 아니고, 비평적으로 읽기도 했었는데,

종종 발견하는 독서가 주는 통찰력과 지혜가 본인에게 활기가 된 적이 있다.

어쩔 때는, 막상 읽고 나서는 그냥 그랬는데

읽고 나니 일상 속에서 그제야 보이는 것들도 있었다.

운동을 꾸준히 하자.

신체 건강을 위해 시작했던 운동이 이젠 정신적인 건강 또한 길러지고 있다.

본인에게 운동을 하는 것은 '운동'이라는 행동 자체를 더불어 '운동하는 꾸준함'에 대한 의미가 있었다.

운동을 매일 하지 않아도 건강하다는 것을 알고 있다.

그럼에도 '매일' 운동을 하는 것은, 어쩌면 스스로의 꾸준함을 증명할 수 있는 가장 선명한 수단이기 때문은 아닐까싶다.

스스로 꾸준히 가져가고 싶은 아이덴티티 중 하나는 '꾸준함', 즉 근성이다.

Problem

꾸준한 연락하는 습관

본인이 인지함에도 바꾸기 어려웠던 문제점은 '연락'이었다.

흔히 안읽씹이었다.

2024년에는 이 문제를 해결해야 겠다.

이를 위해 확인하면 바로 답장하고 바로 해결해나가고자 한다.

여유있는 단위로 하루를 만들자

꽉 채운 하루로 혼자 생각할 시간조차 줄어들었다.

이는 분명히 해결해야할 문제이다.

주중에는 하루종일 공부에 집중했다가,

주말에는 공부와 친구 만나기를 동시에 했다.

정신없는 일주일 내내 본인 생각을 가질 시간들이 점점 줄어들었다.

기술 공부의 시간을 줄이고 포스팅 수를 줄여나가야겠다.

독서와 친구 만나는 시간, 영어 공부 시간은 꼭 필요한 시간들이니 줄일 수 있을까 의문이다.

잠을 늘리고 일정을 조금 더 완화하도록 조정할 것들을 찾아봐야 겠다.

성과를 더 잘 보이게 하자

2023년에 이룬 것들이나 새로 도전한 것들이 정말 많았는데,

눈에 보이기는 힘든 것들이었다.

누군가에게 말하기 준비가 안된 것들도 많았는데, 혼자만의 영역에 정리할 필요가 있다.

본인이 걸어온 성과를 가시화해서 성취의 보상을 주는 것이 좋을 것 같다.

Try

본 글에서 쓸 준비는 아직 안됐기 때문에 본 내용은 생략한다.

Redis ZSET, 제대로 이해하기

gngsn — Wed, 27 Dec 2023 00:06:57 +0900

본 포스팅은 Redis의 정렬된 집합 자료 구조형인 ZSET 명령어에 대해 알아봅니다.

ZSETs

Sorted Set, 정렬된 집합

ZSET는 score에 대한 member의 매핑 값을 저장할 수 있습니다.
HASHes의 키 및 값과 유사하다고 볼 수 있습니다.

이러한 매핑 값을 통해 숫자 값의 score를 조작할 수도, 또한 score 정렬 순서에 따라 가져올 수도, score 값 뿐만 아니라 member와 score를 한 번에 검색해 가져올 수 있습니다.

score은 실제로 'IEEE 754 floating-point doubles'에 따라 Redis 내부에 저장됩니다.

이 절에서는 ZSET에서 작동하는 명령어에 대해 알아보겠습니다.

Sorted Set

Command	FORMAT	Example use and description
`ZADD`	`ZADD key-name score member ...`	ZSET에 입력받은 점수들을 각 member에 추가
`ZSCORE`	`ZSCORE key-name member`	Returns the score of the member in the ZSET
`ZREM`	`ZREM key-name member ...`	ZSET에서 입력받은 score 제거. 제거된 members들의 개수 리턴
`ZCARD`	`ZCARD key-name`	Returns the number of members in the ZSET
`ZCOUNT`	`ZCOUNT key-name min max`	Returns the number of members with scores between the provided minimum and maximum
`ZINCRBY`	`ZINCRBY key-name`	increment member—Increments the member in the ZSET
`ZRANK`	`ZRANK key member [WITHSCORE]`	Returns the position of the given member in the ZSET
`ZRANGE`	`ZRANGE key-name start stop [WITHSCORES]`	Returns the members and optionally the scores for the members with ranks between start and stop

ZRANGE 는 2편에서 소개하도록 하겠습니다.

`ZADD`

️ @write, @fast

Link: redis.io - ZADD

⏱️ Time complexity: O(log(N))

N: the number of elements in the sorted set

ZADD key-name score member [score member ...]

ZSET에 입력받은 점수들을 각 member에 추가합니다.

✔️ Example.

redis> ZADD myzset 1 "one"
(integer) 1
redis> ZADD myzset 1 "uno"
(integer) 1
redis> ZADD myzset 2 "two" 3 "three"
(integer) 2
redis> ZRANGE myzset 0 -1 WITHSCORES
1) "one"
2) "1"
3) "uno"
4) "1"
5) "two"
6) "2"
7) "three"
8) "3"

✔️ Options

ZADD key [NX | XX] [GT | LT] [CH] [INCR] score member ...

XX: 이미 존재하는 요소에 한해 업데이트하며 추가하지 않음
NX: 이미 존재하는 요소는 업데이트하지 않고 오직 새로 추가
LT: 이미 존재하는 요소 보다 Score이 작은 경우에만 업데이트 This flag doesn't prevent adding new elements.
GT: Only update existing elements if the new score is greater than the current score. This flag doesn't prevent adding new elements.
CH: Change의 약자. 새로 추가된 요소의 수뿐만 아니라, 변경된 요소의 수와의 합을 반환. (일반적으로는 새로 추가된 요소들의 수만을 반환)
INCR: ZINCRBY 처럼 동작. 오직 하나의 score-element 쌍을 지정할 수 있음

Note: The GT, LT and NX options are mutually exclusive.

`ZSCORE`

️ @read, @fast

Link: redis.io - ZSCORE

⏱️ Time complexity: O(1)

ZSCORE key-name member

ZSET에 존재하는 score값을 key나 member으로 조회합니다.

반환 값은 string 혹은 숫자(double) 이 될 수 있습니다.
혹은, key나 member가 존재하지 않다면 nil을 반환합니다.

✔️ Example.

redis> ZADD myzset 1 "one"
(integer) 1
redis> ZSCORE myzset "one"
"1"

`ZREM`

️ @write, @fast

Link: redis.io - ZREM

⏱️ Time complexity: O(M*log(N))

N: the number of elements in the sorted set
M: the number of elements to be removed

ZREM key-name member [member ...]

ZSET 내의 특정 member들을 제거하고, 제거된 members들의 개수 반환합니다.
존재하지 않는 member들은 무시합니다.
단, key가 존재하지만 Sorted Set는 없을 때 오류를 반환합니다.

✔️ Example.

redis> ZADD myzset 1 "one"
(integer) 1
redis> ZADD myzset 2 "two"
(integer) 1
redis> ZADD myzset 3 "three"
(integer) 1
redis> ZREM myzset "two"
(integer) 1
redis> ZRANGE myzset 0 -1 WITHSCORES
1) "one"
2) "1"
3) "three"
4) "3"

`ZCARD`

️ @read, @fast

redis.io - ZCARD

⏱️ Time complexity: O(1)

ZCARD key

각 key에 대한 Sorted Set의 Cardinality(요소들의 갯수)를 반환합니다.

✔️ Example.

redis> ZADD myzset 1 "one"
(integer) 1
redis> ZADD myzset 2 "two"
(integer) 1
redis> ZCARD myzset
(integer) 2

`ZCOUNT`

️ @read, @fast

Link: redis.io - ZCOUNT

⏱️ Time complexity: O(log(N))

N: the number of elements in the sorted set

ZCARD key

key에 해당하는 sorted set 내에, min과 max 사이 score의 개수를 반환합니다.
min 및 max 인수는 ZRANGEBYSCORE 과 동일한 의미를 갖습니다.

Note: 내부적으로 ZRANK(ZRANK 참조)를 사용하기 때문에 복잡도는 O(log(N))입니다.

범위 내 요소의 크기에 비례하는 작업을 수행할 필요가 없습니다.

✔️ Example.

redis> ZADD myzset 1 "one"
(integer) 1
redis> ZADD myzset 2 "two"
(integer) 1
redis> ZADD myzset 3 "three"
(integer) 1
redis> ZCOUNT myzset -inf +inf
(integer) 3
redis> ZCOUNT myzset (1 3
(integer) 2

`ZINCRBY`

️ @write, @fast

redis.io - ZINCRBY

⏱️ Time complexity: O(log(N))

N: the number of elements in the sorted set

ZINCRBY key increment member

key에 저장된 sorted set의 member의 score를 증가시킵니다.
정렬된 집합에 구성원이 존재하지 않으면, 마치 이전 점수가 0.0이었던 것처럼 가정하고 증가합니다.

key가 존재하지 않으면 지정된 member을 단독 member으로 하는 새로운 정렬된 집합이 만들어집니다.

key가 존재하지만 sorted set을 보유하지 않으면 오류가 반환됩니다.

score 값은 숫자 값의 문자열 표현이어야 하며, 배정밀도(double precision) 부동 소수점 숫자 형식을 사용합니다.
score를 감소시키고 싶다면 음수의 값을 입력하면 됩니다.

✔️ Example.

redis> ZADD myzset 1 "one"
(integer) 1
redis> ZADD myzset 2 "two"
(integer) 1
redis> ZINCRBY myzset 2 "one"
"3"
redis> ZRANGE myzset 0 -1 WITHSCORES
1) "two"
2) "2"
3) "one"
4) "3"

`ZRANK` / `ZREVRANK`

️ @read, @fast

ZRANK, ZREVRANK

⏱️ Time complexity: O(log(N))

N: the number of elements in the sorted set

ZRANK key member [WITHSCORE]
ZREVRANK key member [WITHSCORE]

ZSET에서 지정된 member의 순위rank를 반환합니다.

ZRANK key에 저장된 sorted set의 member의 순위를 오름차순으로 반환합니다.
순위 (rank 혹은 index)는 0을 기준으로 하며, 점수가 가장 낮은 구성원의 순위가 0 입니다.

ZREVRANK를 사용하면 내림차순으로 원소의 순위를 얻습니다.

key에 저장된 정렬된 집합의 member 순위를 높은 점수에서 낮은 점수로 반환합니다.

두 명령어 모두, 옵션 WITHSCORE 을 추가하면 rank 뿐만 아니라 score 값도 함께 얻을 수 있습니다.

✔️ Example.

redis> ZADD myzset 1 "one"
(integer) 1
redis> ZADD myzset 2 "two"
(integer) 1
redis> ZADD myzset 3 "three"
(integer) 1
redis> ZRANK myzset "three"
(integer) 2
redis> ZRANK myzset "four"
(nil)
redis> ZRANK myzset "three" WITHSCORE
1) (integer) 2
2) "3"
redis> ZREVRANK myzset "one"
(integer) 2
redis> ZRANK myzset "four" WITHSCORE
(nil)

`ZRANGE`

️ @read, @slow

Link: redis.io - ZRANGE

⏱️ Time complexity: O(log(N)+M)

N: the number of elements in the sorted set
M: the number of elements returned

ZRANGE key start stop [BYSCORE | BYLEX] [REV] [LIMIT offset count] [WITHSCORES]

<key>에 저장된 정렬된 집합의 요소 범위를 지정한 값으로 반환합니다.

ZRANGE는 index(rank), score 또는 사전적 정렬과 같은 다양한 유형의 range 쿼리를 수행할 수 있습니다.

Redis 6.2.0부터, 아래의 명령어들로 조건에 맞는 range 쿼리를 사용할 수 있습니다.

ZREVRANGE → ZRANGE + REV

ZRANGEBYSCORE → ZRANGE + WITHSCORE

ZREVRANGEBYSCORE → ZRANGE + REV + WITHSCORE

ZRANGEBYLEX → ZRANGE + BYLEX

ZREVRANGEBYLEX → ZRANGE + REV + BYLEX

공식문서를 참고하면, 좌측 명령어는 Deprecated 되고, 우측 명령어를 사용하는 것을 권장합니다.

ZSET에 입력받은 점수들을 각 member에 추가합니다.

✔️ Example.

redis> ZADD myzset 1 "one"
(integer) 1
redis> ZADD myzset 1 "uno"
(integer) 1
redis> ZADD myzset 2 "two" 3 "three"
(integer) 2
redis> ZRANGE myzset 0 -1 WITHSCORES
1) "one"
2) "1"
3) "uno"
4) "1"
5) "two"
6) "2"
7) "three"
8) "3"

✔️ Options

ZADD key [NX | XX] [GT | LT] [CH] [INCR] score member ...

XX: 이미 존재하는 요소에 한해 업데이트하며 추가하지 않음
NX: 이미 존재하는 요소는 업데이트하지 않고 오직 새로 추가
LT: 이미 존재하는 요소 보다 Score이 작은 경우에만 업데이트 This flag doesn't prevent adding new elements.
GT: Only update existing elements if the new score is greater than the current score. This flag doesn't prevent adding new elements.
CH: Change의 약자. 새로 추가된 요소의 수뿐만 아니라, 변경된 요소의 수와의 합을 반환. (일반적으로는 새로 추가된 요소들의 수만을 반환)
INCR: ZINCRBY 처럼 동작. 오직 하나의 score-element 쌍을 지정할 수 있음

Note: The GT, LT and NX options are mutually exclusive.

마흔에 읽는 쇼펜하우어 - 2

gngsn — Tue, 26 Dec 2023 23:44:50 +0900

마흔에 읽는 쇼펜하우어, 강용수

- 마음의 위기를 다스리는 철학 수업

Date: 2023.12.15 ~ 2023.12.17

Rate: ★ 4.8

Pages: 232.

Comment: 본 책은 분량이 많지 않은데, 기록하고 싶은 마음에 2편까지 적었다. 쇼펜하우어의 생각에서 새로움과 동시에 많은 공감을 느낄 수 있었다. 그리곤, 쇼펜하우어의 입장을 반대하는 인물의 이야기도 들어보고 싶다.

책을 읽을 때, 공감과 불신을 동시에 갖고 읽곤 한다. 명백한 진실을 전하는지, 그 사람의 의견이라면 맞을지 아닐지를 구분하고 필자의 생각과 동일하지 않다면 그 이유를 스스로에게 물어보는 것을 즐기는 탓이다. 본인의 생각을 단단하게 만들어주는 좋은 방법이라고 생각했다.

본 책은 이와는 다르게 내용에 휘말리듯이 읽었다. 공감되지 않는 부분이 없었기 때문이다. 본 책을 읽고 니체와 관련된 책도 읽는 중인데, 아직 그렇게 큰 공감이나 감명을 얻지는 못했다. 결국, 본 책이 다른 철학자들의 이야기를 들어보고자하는 호기심이 크게 들게 만들었다.

쇼펜하우어가 제시한 내용 중 기억하고 싶은 구절이 많이 있었는데, 당장 하나를 꼽자면 "내가 깨달은 것만큼이 나의 세계다"이다. 현재 본인에게 가장 필요한 말이기 때문이다. 끝없는 경험을 원하고 세상을 알아가는 데에 큰 흥미를 느끼는 본인으로써, 와닿지 않을 수 없는 구절이다.

쇼펜하우어의 주장에 따르면 지식이나 사고력은 고통이 따라온다고 하는데, 웃기게도, 세상을 많이 알수록 이 고통은 더해지는 것이다. 더 생각을 많이 할 수록, 미래와 과거를 생각할 수록 우리는 고통을 겪을 수 있다. 이를 피하기 위해 '현재'에 더욱 집중해서 머물러야 한다고 하니, 염세주의 쇼펜하우어보다 낙관적인 사람이 어디있을까 싶다.

쇼펜하우어는 염세주의 철학자로 유명하다.

그런 그를 알아갈 수록, 그 내면은 긍정적이고 유쾌하다는 사실을 알아가는 과정이 꽤 흥미로웠다.

고통과 권태라는 양자택일 앞에 놓인 인간은 불행할 수 밖에 없다는 것이 그의 주장이다.

이 세계의 본질은 끊임없이 살려고 노력하는 의지이며,
이로 인한 권태가 불행의 원인이 된다.

배가 고플 때의 고통과, 셀 수 없이 많은 음식 앞에 배가 터질 듯 부를 때로 예시를 들 수 있다.

따라서, 영원한 충족과 행복감은 없다고 한다.

욕망의 최대 만족은 권태이고 욕망의 최대 결핍은 고통이다.

죽음

쇼펜하우어는 <의지와 표상으로서의 세계>에서 세계를 이끌어가는 건 '의지'라고 주장했다.

바로, 삶을 살아가게 하는 맹목적인 의지이다.

개별적인 행위에는 목적이 있겠지만, 전체 의욕에는 목적이 없다.

영원한 시간 속에서 인간이 살고 죽는 것은 덧없는 꿈일 뿐인 것이다.

그는 금욕적인 삶의 의지를 부정하면서, 욕망과 번뇌를 없애는 것이 고통에서 벗어나는 유일한 수단이라고 한다.

사실, 염세주의인 사람들의 끝은 '자살'이 아닌가라는 생각도 했다. 특히, 인생은 고통의 연속이며 죽음은 아무것도 아니라는 말들은 죽음을 가볍게 보이게 했다. 하지만 쇼펜하우어가 주장하는 철학의 의미를 조금 더 자세히 들여보면, 오해한 내용이었다.

아니다. 그가 주장한 것이 욕망과 번뇌를 부정하는 것이지 포기하라는 것이 아니다. 마치 다이어트를 할 때 음식을 줄여 성공으로 가는 길을 알려주었다고, 금식을 하는 것과 동일한 것이다.

세상을 부정한다는 자살은 무익하고, 아무것도 바뀌지 않는 선택이기 때문에 어리석은 행위이다.

무수한 수증기로 이루어진 무지개에 물방울 한 입자가 사라진다고 해서 달라지는 것이 없는 것과 같다.

자신의 고통을 주변의 고통으로 이동시키는 데에서 전체 고통의 무게는 여전하다.

쇼펜하우어 책의 저자가 말하는 쇼펜하우어는 굉장히 재치가 있는 사람이며, 인생을 유쾌하게 살았다고 한다. 언뜻 염세주의 철학자의 레이블과는 다른 삶이라고 느껴서 더 흥미가 있던 것 같다. 책의 후반부에는 쇼펜하우어가 말하는 행복을 추구하는 법을 다루는데, 충분한 공감이 되어 재미 요소로 다가왔다.

평정심

행복은 무엇인가를 두고 다양한 의견들이 존재하는데,

쇼펜하우어는 "고통이 없는 상태"를 읽컬었다.

행복을 위해서는 고통이 없는 상태, 괴롭힘을 당하지 않는 상태, 안정과 여유를 좇아아야 한다.

그래서 외부의 것에 거리를 둘 필요가 있다.

이 것이 그가 고독을 주장한 이유와 연결된다고 느꼈다.

현자는 쾌락이 아니라 고통이 없는 상태를 추구한다.

쇼펜하우어는 외부와 거리를 두고 자신의 목소리에 귀를 기울이는 것을 강조했다.

고독

평정심, 고독과 관련된 내용을 읽고 있자니, "외부의 것에 얼마나 휘둘리는가"를 생각해보았다.

인간은 외부의 것으로 행복을 얻고, 슬픔을 느끼고, 편안함을 느끼고, 불안함을 느낀다.

외부의 것들이 생각하는 것이 곧 내 생각인 것처럼 느껴질 때도 있다.

쇼펜하우어가 말한 '고독'은 다음과 같다.

고독은 나의 진정한 모습을 들여다볼 수 있는 벗

외부의 것에 휘둘리지 말고, 본인의 목소리에 귀기울이자.

내가 생각해서 인생을 살고, 내가 생각하는 가치를 추구하며 살자는 것이다.

익시온의 바퀴가 멈추면 에피쿠로스 학파가 말한 완전한 행복의 상태에 이른다.
그것은 감정의 동요나 혼란이 없는 평정심의 상태인 아타락시아다 -

아타락시아(ataraxia)
Ataraxia는 헬레니즘(hellenisum) 시대의 인간의 자연스러운 본성에 근거하여 쾌락의 획득과 고통의 회피가 인간을 행복하게 한다고 주장한 에피쿠로스 학파가 감정적, 정신적 동요나 혼란이 없는 평정심의 상태를 표현한 말이다.
스토아학파의 아파테이아(apatheia)와 자주 비교되는 용어이다.

에피쿠로스가 추구한 쾌락은 정신적이고 지속적인 쾌락이다.
감각적이고 순간적인 쾌락을 추구할 경우 쾌락주의의 역설에 빠질 우려가 있어 이를 추구하지 않았다.
쾌락주의의 역설이란 육체적 쾌락을 추구하면 할수록 점점 더 강도가 높은 쾌락을 원하게 되어 결국에는 고통과 근심의 원인이 된다는 것이다. 그러므로 에피쿠로스학파는 어떤 쾌락을 추구하기보다 고통과 근심을 제거하여 평온한 상태를 추구하는 소극적 쾌락주의를 지향하였다.

- Wikipedia, Ataraxia

논외의 이야기이지만, 본책의 재미거리 중 하나는 간간히 출현하는 신화이야기와 쇼펜하우어와 연관된 다른 철학자들의 짧고 명료한 설명이었다. 숲속의 신 실레노스의 이야기나, 위의 인용구에서, 헤라와의 동침을 자랑하고 다닌 익시온을 제우스가 수레바퀴에 달아 영원히 돌아가게 만든 형벌을 비유하는 것과 같이 말이다.

행복

행복한 인생을 결정짓는 진정한 가치는 고통을 잘 견뎌 내는 인내력에 있다.

쇼펜하우어가 말한 '행복'을 향유하는 방법은 건강, 예술 감각과 독서, 글쓰기, 거리두기 공감, 만족, 현재에 집중하는 것 등이었다.

그는 예술과 자연이 삶의 고통의 도피처, 그 이상으로 고통의 원인이자 세계의 근원인 의지를 인식하고 느끼게 하는 것으로 보았다. 이에 빠져들 줄 안다면, 의지와 고통없이 시간을 초월한 마음을 보여준다는 것이다.

과학이 이 세계를 인과율(법칙)로 설명한다면 예술은 이 세계의 영원한 모습을 보여 준다.
그것을 플라톤은 이데아라고 부른다.
..
자연이라는 객관에 완전히 몰입한 상태에서는 개별성이 잊혀지면서 이데아라는 세계를 보게 된다. 쇼펜하우어가 예를 들었듯이 왕이든, 죄수든, 거지든 자신의 신분을 잊고 똑같이 아름다운 자연 풍경을 감상하면 삶의 고통에서 잠시 벗어나게 된다. 고통스러운 자아에서 벗어나 순수한 마음으로 대상과 하나가 될 때 고통의 세계는 사라진다.

독서

쇼펜하우어는 사유의 힘을 키울 수 있는 방법으로 독서를 권했다.

“먹은 것이 육체가 되고 읽은 것이 정신이 되어 현재의 자신이 된다.”

철학적으로 향유하려면 사고하는 근육을 키워야 한다고 전한다.

"내가 깨달은 것만큼이 나의 세계다"

또, 독서를 올바르게 하는 방식을 제시하는데, 독서 방식의 방향이 다르면 오히려 해가 될 수 있다는 것이다.

이에 쇼펜하우어는 독서의 세 가지 방식을 제안한다.

고전을 읽고,

두 번 읽고

악서를 피하라

악서는 흔히 돈을 위해 쓰여진 책이다.

독자적인 생각을 하지 못하는 상태에서 책을 읽게되면 다른 사람이 생각이 자신의 생각인 것처럼 느껴진다.

독자적인 사고란, 자신이 직접 파악하는 것을 이해한다.

책을 많이 읽는 사람은 남이 먹다 남긴 음식을 먹는 것과 남이 입다 버린 옷을 입는 사람에 불과하다.

현재

또 흥미로운 내용 중 하나는,

쇼펜하우어는 지능을 생존을 위한 도구로써 살려는 의지에 봉사하는 보조 역할 이라고 한다.

너무 많은 지식, 사고력은 고통이 따라온다는 말을 전했다.

따라서 인간은 세상에서 가장 불행할 수 있는 존재이다.

이에 쇼펜하우어는 불행을 멀리하는 방법으로, 하루의 소중함을 아는 것을 강조한다.

인생 전체를 구성하는 하루하루는 똑같은 것이 아니라 어제와 다른 늘 새로운 것이다.
현재의 가치를 늘 긍정적으로 평가할 수있어야 된다.
과거와 미래에 빠져 있는 사람은 아무런 걱정 없이 살아가는 매 순간의 가치를 모르고 지나가는 일이 많다.

동물들은 미래나 과거에 대한 걱정이나 고통없이 현재를 살아 인간보다 더 행복할 수 있는 존재이며,

우리는 동물의 이러한 면을 배울 필요가 있다고 한다.

후반부의 행복을 향유하는 방법이 인생의 허망함을 느끼고 무엇이 행복인가를 찾는 사람들에겐 좋은 선택지가 될 수 있을 것 같다. 본 포스팅에서는 그 부분까지는 다루지 않았기 때문에, 궁금증이 든다면 한 번쯤 시도해보는 것도 좋을 것 같다.

마흔에 읽는 쇼펜하우어 − 1

gngsn — Tue, 19 Dec 2023 01:49:39 +0900

마흔에 읽는 쇼펜하우어, 강용수

- 마음의 위기를 다스리는 철학 수업

Date: 2023.12.15 ~ 2023.12.17

Rate: ★ 4.8

Pages: 232.

Comment: 작은 분량의 가볍게 읽을 줄 알았던 책이, 큰 의미로 다가왔다.

저자는 쇼펜하우어를 주인공으로, 그의 철학관을 소개하기 위한 적극적인 설명을 읽기 쉬운 문체들로 이끌어갔다. 덕분에 쇼펜하우어의 가치관을 알아가고 이해해가는 보기 좋은 네비게이터가 되었다.

가장 흥미롭던 내용은 염세주의의 낙관적인 그의 성격, 그의 철학관 그 자체였다. 처음 보면 조화롭지 않은 듯한 이 단어들은, 점점 그가 어떤 인물이었는지에 대한 호기심으로 커졌다. 그가 얼마나 통찰력있는 생각을 했는지 놀라웠다. 인생의 수많은 고통을 냉담히 분석하면서도 유머와 낙관적인 성격을 가졌던 것은, 그가 주장한 독자적인 삶이 만들어낸 굳건함의 실현아니었을까.

쇼펜하우어에 대한 호기심, 철학에 대한 큰 관심으로 본 책에 이끌렸다. 마흔은 어떤 의미인지도 궁금했는데, 인생에서의 큰 변곡점이 될 수 있는 마흔이라는 의미뿐만 아니라 쇼펜하우어의 인생이 마흔을 기준으로 많이 변했다고 한다. 본인에게는 마흔 쯔음의 사람들에게 전달해줄, 그들에게 필요한 이야기는 무엇인지에 대한 호기심이 들었다.

고독, 인생, 행복, 자존감. 삶에 대한 의문을 가져봤다면, 고독이 키우는 강인함에 공담한다면, 쇼펜하우어의 철학을 들어보는 것을 추천한다.

# 고통

"모든 인생은 고통이다."

염세주의 철학자로 잘알려진 쇼펜하우어가 남기고 간,

대중적으로 가장 많이 알려진 말이다.

그가 생각하는 인생은 무엇이었을까.

그는 왜 인생을 고통이라고 생각했을까.

쇼펜하우어가 인생을 고통이라고 한 이유는,

삶에 대한 맹목적인 의지, 그것이 바로 인간의 본성이기 때문이라고 한다.

"이 세상의 모든 생물은 살려는 의지를 충분히 갖고 있으나
이 의지가 충분히 만족되지 않기 때문에 산다는 것은 괴로운 것이다."

저자는 이를 위한 설명으로 인생을 기차에 비교한다.

인생이라는 기차가 기관사(이성) 없이 삶에 대한 욕망(동력)에 이끌려 가는 것과 같다는 것이다.

우리의 삶은 정신이 아니라, 충동에 떠밀려 간다는 말로 슈펜하우어의 철학을 설명한다.

그는 이성 또한 한낱 "욕망의 도구"에 불과하다는 입장이었다.

대조적으로, 아리스토텔레스가 지혜로운 인간의 능력으로,

이성을 최대한 발휘하며 자신의 인생을 사는 탁월함을 말한다.

쇼펜하우어는 본능의 관점으로 이러한 '이성'이 이끄는 행복을 망상으로 보았다.

그는 삶에 대한 애착과 맹목적인 열망을 잘 다스릴 때, 주체적으로 행복한 삶이 가능하다고 본다.

"인간은 무수한 욕망의 덩어리다"

쇼펜하우어가 남긴 위의 말이, 그의 생각을 노골적으로 보이게 한다.

쇼펜하우어는 고통에 대한 중요성을 말했다.

개인적으로 저자의 표현들이 좋았는데,

"고통을 깨달아야 인생을 깨닫는다" 라는 소주제에서 부터 쇼펜하우어의 입장을 잘 소개한다.

저자가 풀어낸 고통의 중요성은,

가령, 우리는 종종 너무 쉽게 오는 것들에 대한 가치를 망각하곤 한다는 것이다.

고통은 우리가 인생을 항해함에 있어서 바닥짐이 되어준다.

# 욕망

쇼펜하우어가 보는 "욕망"과 "이성"은 어떤 것이었을까?

그는 욕구의 의지가 우세하게 작용한다고 주장한다.

의지를 통해 욕구할 이유를 찾는 것이 아닌,

욕구하기 때문에 욕구할 대상을 찾는다는 것이다.

"욕망이 좋고 나쁨을 선택하는 생각에 앞서있기 때문에 인간은 자유로운 생각을 할 수 없다"

는 것이 그의 주장이다.

즉, 인간의 욕망이 죽을 때까지 생존을 위한 욕망을 충족해야 행복할 수 있다.

외적인 자극에서 자유로워져야만 행복해질 수 있다고 한다.

"욕망을 자각하지 않으면 고통이 꼬리에 꼬리를 물고 일어나게 될 것이다."

# 과잉

욕망의 최대 만족은 권태이고, 욕망은 최대 결핍은 고통이다.

쇼펜하우어는 아래와 같은 말을 남겼다.

"고통과 무료함은 한쪽이 멀어질수록 다른 쪽이 다가온다.

즉, 고통과 권태라는 양자택일 앞에 인간은 불행할 수 밖에 없다.

# 결핍

"우리의 모든 불행은 혼자 있을 수 없는 데서 생긴다."

무수한 욕망 덩어리인 인간이기 때문에 우리는 새로운 것에 대한 호기심이 생긴다.

외적인 것에 대한 호기심, 즉 변화하는 대상에서 찾는 행복은 오래가지 않는다.

그럼에도 인간은 항상 새로운 것을 지향한다.

호기심은 자신의 결핍을 인식하고 자신의 능력을 확장하고 탐구하고 배우는 수단으로 사용하라.

외적인 것과는 거리를 두고, 혼자있는 법을 익혀야 한다.

# 행복

쇼펜하우어가 생각한 행복이란 무엇일까?

"현자는 쾌락이 아니라 고통이 없는 상태를 추구한다."

즉, 쾌락을 찾는 것이 아닌 고통의 원인을 없애는 것이 현명하다는 것이다.

행복은, 고통과 권태라는 불행의 길에서 이를 잘 견뎌 내는 인내력에 있다.

행복을 평가하는 기준은 성공, 부, 성취, 출세가 아닌, 정신적으로나 육체적으로 겪는 고통의 정도인 것이다.

그럼에도 우리는 우리의 노력으로 행복을 누릴 수 있다.

쇼펜하우어가 중요하게 여겼던 것 중 하나는,

우리는 끊임없이 자신과 세계를 탐구하며 자신 스스로를 알아가야 한다는 것이다.

내가 진정 원하는 것을 알아야만 자신만의 행복의 방향이 비로소 정해진다는 것이다.

오랜 성찰을 통해, 타고난 욕망과 능력이 무엇인지 찾아,

그 일에서 즐거움을 찾는 일이 행복으로 가는 길이 될 수 있다.

자신의 성격에 맞는 일을 찾아 선택하라.

그것이 가장 중요한 출발점이다.

하던 대로 하고 살던 대로 살면 갈등과 고민에서 벗어날 수 없을 것이다.

낙관적인 사람은 고난에서 기회를 보고,
비관적인 사람은 기회에서 고난을 본다.

# 감정

쇼펜하우어는 지능을 생존을 위한 도구로써 살려는 의지에 봉사하는 보조 역할을

지성은 생존 문제를 해결하는 데 좋지만, 해결한 후엔 작동을 멈춘다.

오히려, 많이 알수록 불행해질 수 있다는 점에서 지식은 쓸모가 없다.

《성경 구약》 전도서 제1장 18절이 쇼펜하우어의 생각을 잘 대변한다.

“지식을 더하는 자는 근심을 더하느니라.”

죽음 자체보다 죽음을 생각하는 것이 고뇌의 더 큰 원인이 된다.

인간이 겪는 고통의 대부분은 상상력, 회상과 예상이라는 지성 활동에서 비롯된다.

우리는 현재 행복함을 깨닫지는 못하지만,

좋지 않은 시기가 되면 과거를 그리워하며 탄식하곤 한다.

"과거의 행복에 매달리지 말고,

미래에 행복을 미루지 마라."

# 죽음

인생은 고통의 연속이다.

쇼펜하우어는 죽음을 욕망을 단절한다고 분석했고,

한 사람의 죽음은 결국 아무것도 아님을 말한다.

“죽음은 우리에게 아무것도 아니다”.
- 에피쿠로스

저자는 다음과 같이 말한다.

우리가 존재할 때는 죽음이 존재하지 않으며, 죽음이 존재할 때 우리는 존재하지 않는다.

그렇다면 사는 것은 무엇이고, 죽음은 무엇일까?

책에서는 이를 뒷받침하는 신화를 소개한다.

그리스 신화에 등장하는 반인반수의 실레노스의 이야기와 지혜가 니체의 《비극의 탄생》에 잘 나타나 있다.
숲속의 신 실레노스는 ‘가장 좋은 건 무엇인가요?’라는 질문에 다음과 같이 대답한다.

“최선의 것은 네가 얻을 수 없다: 태어나지 않는 것, 존재하지 않는 것, 무(無)가 가장 좋은 것이므로.
하지만 차선의 것은 네가 얻을 수 있다 — 당장 죽는 것이므로.”

그렇다면 우리에게 죽음은 무엇일까?

그렇다면 자살이 고통을 탈피하는 방법인가?

‘차라리 태어나지 않았다면 좋았을 텐데’라는 생각을 가질 때 어떤 답을 내놓아야 할 것인가.

역설적으로, 자살은 삶에 대한 무한한 사랑을 보여 준다는 것이 쇼펜하우어의 생각이다.

쇼펜하우어는 욕망과 번뇌를 없애려고 했지, 삶 그 자체를 없애려고 한 것은 아니다.

예를 들어 식탐이 많으면 살이 찌고 건강이 나빠져서 다이어트를 할 수는 있지만 금식을 권장한 것은 아니라는 의미다.
먹으려는 욕망 자체는 나쁜 것이 아니다.

죽음은 삶에 따른 고통을 줄이려고 할 뿐, 생존 의지 자체를 제거하는 것은 아니다.
삶의 형식은 끝없는 현재다.
시간은 쉬지 않고 끊임없이 흘러가는 강물과 같으며 인간은 그 물결에 휩쓸려 사라지는 존재다.
그 영원한 시간 속에서 인간이 살고 죽는 것은 ‘덧없는 꿈’과 같다.
이런 점에서 세상을 부정하는 자살은 무익하고, 아무것도 바뀌지 않는다는 점에서 어리석은 행위다.

결론적으로, 고통의 총량은 변하지 않는다.

한 인간의 죽음은 사실, 무지개를 이루는 수증기 하나가 없어졌을 때와 같은 것이다.

죽음은 아무것도 아니다.

LATERAL JOIN, 어렵지 않게 사용하기

gngsn — Tue, 28 Nov 2023 23:59:44 +0900

본 포스팅은 LATERAL JOIN을 이해하고 실습해보기 위한 포스팅입니다.

LATERAL JOIN 은 PostgreSQL, Oracle, DB2, MS SQL 등에서 사용될 수 있지만, 잘 알려지지는 않은 기능입니다.

최근 쿼리를 작성하면서 LATERAL JOIN 기능을 사용할 일이 있었는데요.

LATERAL JOIN 으로 어떤 것들을 할 수 있을지 잘 파악한다면,

꽤 유용한 기능이라고 생각이 들어 글을 작성해보고자 합니다.

내용을 살펴보기 전에, SQL의 기본적인 SELECT 와 FROM 구문을 생각해봅시다.

SELECT <something...> FROM <table>;

기본적으로, 위 코드는 루프를 돌며 데이터를 가져오는 것을 알 수 있는데요.

마치 아래와 같은 pseudo 코드와 같이 생각할 수 있습니다.

for x in tab
loop
     "do something"
end loop

테이블 내 각각의 엔트리마다, SELECT 구문에 작성된 내용들을 확인하고 가져옵니다.

주로 간단한 쿼리로도 결과를 반환하며, 개발자들이 원하는 요구사항을 충족하곤 합니다.

하지만 만약 "중첩" 루프가 필요하다면 어떻게 될까요?

이 때, 바로 LATERAL 이 좋은 옵션이 됩니다.

LATERAL JOIN

Presentation

데이터베이스에 많은 상품들이 저장되어 있고, 또 소비자들의 위시리스트를 갖고 있다고 가정해봅시다.

이 때, 목표를 각 위시리스트 마다 각 3개씩의 최상위 상품들을 찾아낸다고 설정해봅니다.

SQL은 간단히 아래와 같이 준비해보겠습니다.

postgres=# CREATE TABLE product AS
    SELECT   id AS product_id,
             id * 10 * random() AS price,
             'product ' || id AS product
    FROM generate_series(1, 1000) AS id;
 
postgres=# CREATE TABLE wishlist
(
    wishlist_id        int,
    username           text,
    desired_price      numeric
);

postgres=# INSERT INTO wishlist VALUES
    (1, 'sun.ny', '450'),
    (2, 'kiana', '60'),
    (3, 'gngsn', '1500')
;

상품 테이블은 1,000개의 상품들로 채워져있습니다.

postgres=# SELECT * FROM product LIMIT 10;
 product_id |       price        |  product   
------------+--------------------+------------
          1 | 2.4007917948567448 | product 1
          2 |  15.46599584566692 | product 2
          3 | 12.327515522601548 | product 3
          4 | 27.733379812329897 | product 4
          5 |  24.29865467116169 | product 5
          6 |  5.258883593537411 | product 6
          7 |  47.37658728440519 | product 7
          8 |  35.28311989012357 | product 8
          9 |  51.37916660750454 | product 9
         10 | 0.5820259854988574 | product 10
(10 rows)

다음으로, 아래와 같은 두 가지의 위시리스트를 가집니다.

postgres=# SELECT * FROM wishlist;
 wishlist_id | username | desired_price 
-------------+----------+---------------
           1 | sun.ny   |           450
           2 | kiana    |            60
           3 | gngsn    |          1500
(3 rows)

Running

위와 같은 데이터들을 생성한 후,

이제 실제 상황에서 발생할 수 있는 상황을 알아보도록 하겠습니다.

모든 위시리스트에 대해 최상위 세 개의 상품을 얻고 싶을 때,

다음과 같은 pseudo-code를 작성해볼 수 있습니다.

for x in wishlist
loop
      for y in products order by price desc
      loop
           found++
           if found <= 3
           then
               return row
           else
               jump to next wish
           end
      end loop
end loop

여기서 핵심은, 중첩 루프가 필요로 한다는 것입니다.

이를 위해서는 먼저, 모든 위시리스트를 순회하고 난 후,

정렬된 상품 목록에서 상위 3개를 고른 후,

다음 위시리스트로 넘어갑니다.

자, 이제 pseudo-code 를 LATERAL-JOIN 을 사용해서 표현해보도록 하겠습니다.

SELECT *
FROM wishlist AS w, 
    LATERAL (
        SELECT *
        FROM  product AS p
        WHERE p.price < w.desired_price
        ORDER BY p.price DESC
        LIMIT 3
    ) AS x
ORDER BY wishlist_id, price DESC;

가장 먼저 FROM 구문에 위시리스트 테이블을 확인할 수 있는데요.

LATERAL이 무엇을 동작하냐면, 상위 쿼리인 위시리스트의 엔트리에 접근할 수 있게 합니다.

그래서 위시 리스트에 있는 각각의 엔트리를 위해 우리는 세 개의 상품들을 출력합니다.

우리가 필요한 상품이 어떤 것인지 알아내기 위해서는,

위시리스트 테이블에 있는 desired_price 라는 값을 알 수 있도록 만들어야 하는데요.

일반적인 JOIN으로는 외부쿼리의 엔트리에 접근할 수 없죠.

하지만, LATERAL 를 사용한다면, 이를 가능하게 해줍니다.

위 pseudo-code에서 확인했던 FROM 구문은 outer loop 코드로,

그리고 LATERAL 은 inner loop로 이해해도 좋습니다.

이에 대한 결과 값을 확인해보면 아래와 같이 출력됩니다.

 wishlist_id | username | desired_price | product_id |       price        |   product   
-------------+----------+---------------+------------+--------------------+-------------
           1 | sun.ny   |           450 |        662 | 449.89768179672245 | product 662
           1 | sun.ny   |           450 |         54 | 433.56115443539176 | product 54
           1 | sun.ny   |           450 |        736 |  432.9276145431032 | product 736
           2 | kiana    |            60 |        535 | 59.783453007038275 | product 535
           2 | kiana    |            60 |        714 |  58.56072565492091 | product 714
           2 | kiana    |            60 |         42 |  55.71988686789034 | product 42
           3 | gngsn    |          1500 |        608 | 1494.5220473756249 | product 608
           3 | gngsn    |          1500 |        173 | 1494.2119790676245 | product 173
           3 | gngsn    |          1500 |        944 | 1491.6807231391247 | product 944
(9 rows)

PostgreSQL은 각 위시리스트마다 세 개의 엔트리를 반환하는데,

이는 정확히 우리가 원하는 대로 출력된다는 것을 알 수 있습니다.

여기서 중요한 부분은 LIMIT 구문이 LATERAL에 공급되는 SELECT 내부에 있다는 것입니다.

따라서 전체 행 수가 아니라 위시리스트당 행 수를 제한합니다.

PostgreSQL은 LATAL 조인을 최적화하는 작업을 꽤 잘 하고 있습니다.

이 경우 실행 계획execution plan은 매우 간단해 보입니다.

postgres=# EXPLAIN SELECT *
FROM wishlist AS w,
    LATERAL  (SELECT *
        FROM       product AS p
        WHERE       p.price < w.desired_price
        ORDER BY p.price DESC
        LIMIT 3
       ) AS x
ORDER BY wishlist_id, price DESC;
                                     QUERY PLAN                                      
-------------------------------------------------------------------------------------
 Sort  (cost=23403.03..23409.40 rows=2550 width=91)
   Sort Key: w.wishlist_id, p.price DESC
   ->  Nested Loop  (cost=27.30..23258.74 rows=2550 width=91)
         ->  Seq Scan on wishlist w  (cost=0.00..18.50 rows=850 width=68)
         ->  Limit  (cost=27.30..27.31 rows=3 width=23)
               ->  Sort  (cost=27.30..28.14 rows=333 width=23)
                     Sort Key: p.price DESC
                     ->  Seq Scan on product p  (cost=0.00..23.00 rows=333 width=23)
                           Filter: (price < (w.desired_price)::double precision)
(9 rows)

LATERAL JOIN 은 알아둘 만한 유용한 기능이며,

다양한 케이스를 커버하며 속도를 향상 시키거나,

혹은 코드를 더 쉽고 이해하기 좋게 만들 수 있도록 사용할 수 있습니다.

| Reference |

Postgresql Official - QUERIES LATERAL

Cybertec: Understanding-lateral-joins-in-postgresql/

Kubernetes Architecture, 제대로 이해하기 - Control Plane

gngsn — Wed, 22 Nov 2023 23:27:17 +0900

Kubernetes Series

모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.

Kubernetes Architecture

쿠버네티스 아키텍처는 컨테이너화된 워크로드를 안정적이고 적응 가능한 환경을 제공하기 위해,

여러 서버와 클러스터에 분산된 컴포넌트들이 함께 동작하는 집합입니다.

쿠버네티스 클러스터는 크게 컨트롤 플레인Control plane과 워커 노드 Worker Node 로 구성됩니다.

지금부터 쿠버네티스 아키텍처의 중요 요소들을 이해하도록 해당 개념을 다루며,

본 글에서는 컨트롤 플레인에 해당하는 컴포넌트를 살펴보도록 하겠습니다.

워커 노드에 해당하는 글은 다음 글로 찾아뵙겠습니다.

Kubernetes Components

Kubernetes 아키텍처는 master-worker 모델 구조를 따릅니다.

컨트롤 플레인에 해당하는 master는 워커 노드들을 관리하며,

Pod들로 캡슐화된 컨테이너들은 워커 노드들 내에 배포되어 실행됩니다.

그럼 지금부터 아래 아키텍처에 나타난, 중요 구성 요소에 대해 알아보겠습니다.

https://kubernetes.io/docs/concepts/overview/components/

Control Plane

Control Plane은 컨테이너 오케스트레이션을 담당하며 클러스터의 상태를 유지합니다.

Control Plane은 아래와 같은 네 가지 구성 요소로 구성되며, 각각 특정 작업을 담당합니다.

✔️ kube-apiserver: Kubernetes API를 노출하는 컴포넌트 kubectl 로부터 리소스를 조작하라는 지시를 받음

✔️ etcd: 고가용성을 갖춘 분산 key-value 스토어, 쿠버네티스 클러스터의 백킹 스토어로 사용됨

✔️ kube-scheduler: 노드를 모니터링하고 컨테이너를 배치할 적절한 노드를 선택

✔️ kube-controller-manager: 리소스를 제어하는 컨트롤러를 실행

이러한 구성 요소들은 함께 작동하여 각 Kubernetes 클러스터의 상태가 미리 정의된 원하는 상태 desired state 와 일치하는지 확인합니다.

kube-apiserver

kube API 서버는 사용자·컴포넌트가 쿠버네티스 클러스터와 쉽게 통신할 수 있도록 합니다.

드물게, 모니터링 시스템이나 써드파티 서비스들이 클러스터들 간 통신하기 위해 사용할 수도 있습니다.

kubectl과 같은 CLI를 사용하여 클러스터를 관리할 때는, API 서버와 통신하기 위해 HTTP REST API를 사용하는데요.

하지만, 스케줄러 및 컨트롤러와 같은 내부 클러스터 구성 요소는 gRPC 방식으로 통신합니다.
API 서버는 TLS를 통한 안전성을 위해 다른 컴포넌트와 암호화 통신을 합니다.

kube-apiserver의 주요 역할은 다음과 같습니다.

✔️ API 요청을 관리

✔️ API 객체 검증

✔️ 사용자 인증 및 권한 부여 authenticate & authorize

✔️ 컨트롤 플레인과 워커 노드 컴포넌트들 사이에서 위치 조정 처리

✔️ ...

API 서버는 etcd에서만 작동합니다.

또, 내장된 bastion API 서버 프록시를 포함하는데, 이를 통해 Cluster IP 서비스에 대한 외부 액세스를 가능하게 합니다.

etcd

etcd는 key-value 데이터 저장소입니다.
Kubernetes 클러스터에서 저장되는 데이터를 위해 설계되었는데,

가령 Pod 들이나 각 Pod들의 상태, 그리고 Namespace 들과 관련된 데이터를 저장합니다.

간단히 말하면, 만약 kubectl을 사용하여 쿠버네티스 오브젝트 세부 정보를 얻으려고 한다면,

바로 etcd에서 해당 데이터를 가져오는 것입니다.

Kubernetes는 분산형 시스템으로 분산형 특성을 지원하는 etcd와 같은 효율적인 분산형 데이터베이스가 필요합니다.
백엔드 서비스 디스커버리backend service discovery 와 데이터베이스 역할을 동시에 수행합니다.
Kubernetes 클러스터의 뇌라고 할 수 있습니다.

etcd는 보안을 위해 오직 API 서버에서만 접근할 수 있습니다.

etcd는 일관성과 가용성을 엄격하게 지키기 위해 raft consensus algorithm 을 사용합니다.

고가용성과 노드 장애에 견딜 수 있도록 leader-member 방식으로 작동합니다.

또한 Pod과 같은 객체를 배포할 때도 etcd에서 엔트리가 생성됩니다.

✔️ Key-Value Data

etcd는 gRPC를 이용한 key-value API를 제공합니다.

참고로, gRPC 게이트웨이는 모든 HTTP API 호출을 gRPC 메시지로 변환하는 RESTful 프록시로,

Kubernetes에 이상적인 데이터베이스입니다.

Kubernetes 객체의 모든 구성, 상태 및 메타데이터를 저장합니다.

메타데이터에는 pods, secrets, daemonsets, deployments, configmaps, statefulsets 등이 있습니다.

모든 객체는 /registry 디렉토리 key 아래에 key-value 형식으로 저장됩니다.

예를 들어 기본 네임스페이스의 Nginx라는 이름의 Pod 정보는 /registry/pods/default/nginx 아래에 있습니다

✔️ Watch

Kubernetes의 api-server는 etcd의 watch 기능을 사용하여 객체의 상태에 대한 변경 사항을 모니터링합니다.

더 구체적으로는, 클라이언트가 Watch() API를 이용해 이벤트를 subscribe 할 수 있도록 해줍니다.

Kube-api-server는 etcd의 watch 기능을 이용해 객체의 상태 변화를 추적합니다.

Control Plane에서 유일한 Statefulset 컴포넌트이기도 합니다.

Statefulsets: Pod 집합의 Deployment와 Scaling을 관리하며, 파드들의 순서 및 고유성을 보장. 상태를 가진 앱에 사용되는 API 객체

kube-scheduler

kube-scheduler는 워커 노드에서 Kubernetes pod의 스케줄링을 담당합니다.

한 Pod를 배포할 때 CPU, memory, affinity, taints 나 tolerations, priority, persistent volumes (PV) 등과 같은 포드 요구 사항을 지정합니다.

스케줄러의 주된 역할은 생성된 요청을 식별하고, 요구 사항을 충족하는 Pod가 배치될 가장 적합한 노드를 선택하는 것입니다.
다음 이미지는 스케줄러 작동 방식을 보여줍니다.

https://devopscube.com/kubernetes-architecture-explained/

하나의 Kubernetes 클러스 내에는 하나 이상의 워커 노드가 존재할 수 있습니다.

그렇다면, 과연 어떻게 스케줄러는 모든 워커 노드들 중에서 하나를 지정할까요?

스케줄러는 Scheduling cycle과 Binding cycle 두 단계로 되어 있고, 이를 둘을 합쳐 스케줄링 컨텍스트라고 합니다.

scheduling cycle은 워커 노드를 선택하고, binding cycle은 그 변화를 클러스터에 적용합니다.

scheduling cycle에서는 kube-scheduler는 최적의 노드를 선택하기 위해, filtering 과 scoring 작업을 수행합니다.

binding cycle에서는 binding 이벤트를 생성합니다.

1. Scheduling Cycle: Filtering

Pod를 스케줄할 수 있는 가장 적합한 노드를 찾습니다.

예를 들어, Pod를 실행할 자원이 있는 워커 노드가 5개인 경우에는 5개의 노드를 모두 선택합니다.

노드가 없으면 pod는 스케줄이 불가능하기 때문에, 스케줄링 큐 scheduling queue 로 이동합니다.

대규모의 클러스터일 경우, 100개의 워커 노드가 있다고 치면, 스케줄러는 모든 노드를 순회하지 않습니다.

round-robin 방식으로 먼저 50% 이상의 노드에 대해 순차적으로 조회iterate 합니다.

50%라고 말한 이유는, percentageOfNodesToScore 라는 스케줄러 구성 파라미터의 값을 참고 하며,

기본값이 일반적으로 50%입니다.

워커 노드가 여러 영역zone 에 분산되어 있으면, 스케줄러는 다른 영역zone 의 노드까지 순차적으로 조회iterate 합니다.

매우 큰 클러스터의 경우에는, percentageOfNodesToScore 의 기본값은 5%입니다.

스케줄러는 스케줄링을 위해 항상 우선순위가 높은 pod들을 우선순위가 낮은 pod들보다 먼저 배치합니다.
어떤 경우에는, pod가 선택된 노드에서 실행되기 시작한 후에, pod가 제거되거나 다른 노드들로 이동될 수 있습니다.

ref. Pod 우선순위 가이드

2. Scheduling Cycle: Scoring

스케줄러가 필터링된 워커 노드들에 점수를 부여하여 노드들의 순위를 매깁니다.

스케줄러는 여러 스케줄링 플러그인들을 호출하여 스코어링을 합니다.

그중, 가장 높은 순위를 가지는 워커 노드가 포드 스케쥴링을 위해 선택됩니다.

만약 모든 노드들이 동일한 순위를 가지면, 한 노드가 임의로 선택됩니다.

3. Binding cycle: Binding Event

노드가 선택되면, 스케줄러는 API서버에 binding 이벤트를 생성합니다.

이때 binding 이벤트란, pod와 node를 binding하는 이벤트를 의미합니다.

직접 커스텀한 스케줄러를 생성해서 기본 스케줄러와 함께 두 스케줄러를 클러스터 내 동시에 실행할 수 있습니다.

pod를 배포할 때는 pod 매니페스트에서 사용자 지정 스케줄러를 지정할 수 있습니다.

따라서 사용자 지정 스케줄러 로직을 기반으로 스케줄링 결정이 내려지게 됩니다.

스케줄러에 플러그인 가능한 스케줄링 프레임워크가 있습니다.

즉, 사용자 지정 플러그인을 스케줄링 워크플로우에 추가할 수 있습니다.

kube-controller-manager

Kube-controller-manager는 모든 컨트롤러를 관리하고,

컨트롤러는 클러스터를 원하는 상태로 유지하기 위해 지속적으로 시도합니다.

커스텀한 리소스를 정의하여 custom controllers과 함께 사용해서 kubernetes 를 확장할 수 있습니다.

https://devopscube.com/kubernetes-architecture-explained/

컨트롤러는 무한한 컨트롤 루프를 실행하는 프로그램으로,
지속적으로 실행되면서 원하는 물체의 상태를 실제와 비교하며 관찰하며 둘이 최대한 가까워지도록 조정합니다.

각 컨트롤러는 현재 클러스터 상태를 원하는 상태에 가깝게 이동하려고 합니다.

Controller ?

로보틱스(robotics)나 자동화 장치(automation)에서는,
제어 루프 control loop 는 시스템의 상태를 조절하기 위해 무한 루프입니다.

제어 루프의 예시를 들자면, '온도 조절기'가 있습니다.
온도를 설정하면 온도 조절기는 원하는 상태를 알려줍니다.
실제 실내 온도는 현재 상태이며,
이 현재 상태를 원하는 상태에 가깝게 만들도록 온도 조절기는 장치를 켜거나 끄는 역할을 합니다.
−−

Kubernetes 에서 컨트롤러는 클러스터의 상태를 관찰한 다음,
필요한 곳에 변경시키거나 변경을 요청하는 컨트롤 루프입니다.
각 컨트롤러는 현재 클러스터 상태를 원하는 상태에 가까워지도록 조절합니다.

가령, 매니페스트 파일 (YAML) 에서 원하는 상태를 지정하고 Deployment 를 생성한다고 가정해봅시다.

이 때, 두 개의 레플리카와 각각 하나의 volume mount와 configmap 맵 등을 지정합니다.
내장된 배포 컨트롤러는 배포가 항상 원하는 상태로 유지되도록 보장합니다.

사용자가 5개의 레플리카으로 deployment 를 업데이트하면,

배포 컨트롤러가 원하는 상태인 5개의 레플리카가 되도록 확인하고 조정합니다.

Kube-controller-manager는 Kubernetes의 모든 Controller를 관리합니다.

Kubernetes가 기본적으로 지원하는 것 중, 중요한 Controller 는 다음과 같습니다.

- Node controller: 노드가 다운되었을 때 이를 인지하고 응답하는 역할

- Job Controller (Kubernetes Jobs): 일회성 작업을 나타내는 작업 객체를 관찰한 다음, Pods를 생성하여 해당 작업을 완료하도록 실행

- Endpoints controller: EndpointSlice 개체를 채움 Populates (Service 들과 Pod 들 사이의 링크 제공)

- ServiceAccounts controller: 새로운 Namespace 에 대한 기본 ServiceAccounts를 생성합니다.

- Deployment controller

- Replicaset controller

- DaemonSet controller

- CronJob Controller

- Namespace controller

...

논리적으로 각 컨트롤러는 별개의 프로세스이지만,

복잡성을 줄이기 위해 모두 하나의 바이너리로 컴파일되어 하나의 프로세스로 실행됩니다.

cloud-controller-manager

Cloud Controller Manager, CCM

쿠버네티스 컨트롤 플레인 컴포넌트 중 하나로, 클라우드 컨트롤 로직을 처리합니다.
Kubernetes가 클라우드 환경에 배포되면 cloud-controller-manager 는

Cloud Platform API와 Kubernetes 클러스터 사이의 브리지 역할을 합니다.

https://www.simform.com/blog/kubernetes-architecture/#:~:text=The%20Kubernetes%20architecture%20follows%20a,the%20cloud)%20or%20physical%20servers.

쿠버네티스 핵심 구성 요소가 독립적으로 작동할 수 있으며,

클라우드 공급자가 플러그인을 사용하여 쿠버네티스와 통합할 수 있습니다.
(예를 들어, 쿠버네티스 클러스터와 AWS 클라우드 API 간의 인터페이스)

클라우드 컨트롤러 통합을 통해 Kubernetes 클러스터는 instances (for nodes), Load Balancers (for services), and Storage Volumes (for persistent volumes)과 같은 클라우드 리소스를 프로비저닝할 수 있습니다.

온프레미스 환경에서 쿠버네티스를 실행시킨다면, 클러스터는 cloud-controller-manager 를 갖지 않습니다.

kube-controller-manager와 마찬가지로, cloud-controller-manager도 논리적으로 여러개의 독립된 제어 루프를 하나의 바이너리로 결합시켜 하나의 프로세스로 실행시킵니다.

성능을 향상시키거나 장애를 견딜 수 있도록tolerate failures 하기 위해, 수평 확장(하나 이상의 복사본 실행 ) 이 가능합니다.

다음 컨트롤러는 클라우드 클라우드 제공자 dependency 들을 가질 수 있습니다:

✔️ Node controller

응답 중단 후, 클라우드에서 노드가 삭제되었는지 확인하기 위해 클라우드 제공자를 확인합니다.

클라우드 제공자 API와 대화하여 노드 관련 정보를 업데이트합니다.

예를 들어, node labeling & annotation, hostname 가져오기, CPU & memory 사용 가능 여부, nodes health 등

✔️ Route controller

기본underlying 클라우드 인프라스트럭처에서 Route를 설정합니다.

클라우드 플랫폼의 네트워크 라우팅을 설정하는 책임을 가지며, 이를 통해 Pod들이 서로 통신할 수 있습니다.

✔️ Service controller

클라우드 제공자 로드밸런서 생성, 업데이트 및 삭제합니다.

쿠버네티스 서비스를 위한 로드 밸런서 배포나 IP 주소 할당을 책임집니다.

전반적으로 Cloud Controller Manager는 kubernetes가 사용하는 클라우드를 위한 리소스의 라이프사이클을 관리합니다.

| Ref. |

Kubernetes Architecture and Components with Diagram
Kubernetes Architecture Explained

해커와 화가 - Paul Graham

gngsn — Mon, 20 Nov 2023 01:55:35 +0900

Hackers & Painters - Paul Graham

Publication date: 2010.07.06

Author: Paul Graham

Rate: ★ 3.8

Pages: 364

Comment: 폴 그레이엄이 가진 프로그래밍에 대한 신념이, 생각의 다양성을 이끌어냈다. 한 번도 생각해보지 못했던 프로그래밍에 대한 표현을 만날 수 있었고, 새로움이 재미로 다가왔다.

책은 그가 분석한 해커 세상에 대한 날카롭고 대범하며, 솔직한 견해를 덧 붙인다.

크게 아쉬웠던 부분은 문장력이었는데, 원문이 원인인지 번역이 원인인지 알 수 없지만, 각주나 문장에서 역자의 노력이 보임에도 불구하고 외국어를 한국어로 번역할 때의 부자연스러움을 꽤 느꼈다.

summary: 해커와 화가는 닮았다. 그들은 새로운 것을 창조하며, 혁신적인 생각으로 뛰어난 작품을 만들어 낸다. 그들은 아름다운 것을 만들어 내며, 좋은 디자인을 만들어 가는 공통된 특징이 있다.

Hacker?

대부분의 "해커"를 남은 컴퓨터에 침입한 사람이라는 의미로 사용한다.

하지만, 프로그래머에게 있어서 "해커"란 문자 그대로 어떤 것에 정통했다는 의미를 담고 있다.

즉, 컴퓨터가 원하든 아니든 컴퓨터를 자기가 원하는 대로 조작할 수 있는 사람이라는 의미다.

일반인이 생각하는 해커로는 해킹을 하고 정보를 훔치는 나쁜 일을 하는 크래커의 개념으로 많이 알고도 있는 것을 보게 된다.

저자가 소개하는 해커와 화가의 공통점

- 그들은 둘 다 무엇인가를 창조한다.

작곡가, 건축가, 작가와 마찬가지로 해커와 화가는 좋은 무엇을 만들어 내기 위해 노력한다.
창조의 과정에서 훨씬 좋은 새로운 기술을 발견하기도 한다.

좋은 해커는 모든 것에 대해서 의문을 품는 습관을 지니고 있다. 기계식 손목처럼 복잡하면서 그 크기는 수천 배인, 단어로 이루어진 컴퓨터를 상대로 일할 때는 그렇게 끊임없이 의문을 품는 습관이 반드시 필요하다.

둘, 해커와 화가

재밌게 읽었던 부분은, 저자가 "컴퓨터 사이언스"라는 말을 좋아하지 않는 이유였다.

그 첫 번째 이유로, 컴퓨터 사이언스는 존재하지 않는다고 말한다.

이 단어가 겉보기엔 연관된 것처럼 보이는 영역을 연결시켜둔 것처럼 느껴진다고 한다.

실제로 컴퓨터를 다루는 일이 수학, 물리학, 건축학을 섞어놓은 영역이라는 점에서,

과연 "컴퓨터 사이언스"라는 단어가 이 모든 것을 함축시킬 수 있는지를 본다면

전혀 아니라는 것이다.

같은 맥락에서 "소프트웨어 엔지니어링"도 잘못된 인식을 심어준다고 말한다.

두 번째 이유로는, 단어 그대로 "과학"이 아니라는 이유에서다.

컴퓨터를 다루는 아주 내부 영역은 실험 과학일 수 있더라도, 그 외의 사람들은 과학을 하지 않는다.

아름다운 소프트웨어인지 아닌지 측정할 수 있는 유일한 외적인 방법은 시간이다.
시간이 지남에 따라서 아름다운 것은 퍼지고 못난 것은 사라진다.

책을 읽으면 종종 들었던 인상적인 점은,

저자가 소프트웨어를 다루는 일을 실제 하나의 예술을 다루는 것처럼 표현한다는 점이었다.

폴 그레이엄은 본인이 프로그램하는 방식에 특별한 이름을 붙였다.

바로 "스케치"이다.

전체적인 프로그램을 미리 신중하게 적어,
생각하는 방향이 옳은지 여부를 확인하기 전에 조각난 코드부터 대책 없이 늘어놓은 다음,
그것의 모양을 조금씩 잡아 나가는 방법으로 프로그래밍했다.

디버깅이란 틀린 철자나 부주의한 실수를 잡아내는 최후의 과정이라고 여겨지지만,
내가 일한 방식대로라면 프로그래밍 자체가 완벽하게 디버깅으로 이루어져 있다는 것이다.

그것은 프로그래밍이라는 것이 부드럽고 말랑말랑한 존재라는 엄연한 사실에 대한 재확인이다.

또, 소프트웨어를 제작할 때 완벽한 시작은 없다는 것을 말하는 내용도 있었다.

우리가 그림 그리기에서 생각해 볼 수 있는 것 또 하나는 그림이 점진적인 세공의 과정을 거쳐서 완성된다는 점이다.
그림은 대개 스케치에서 시작되어 세밀한 부분이 조금씩 더해진다.
...
엑스레이를 통해 서 들여다보면 많은 그림에서
팔다리를 여기저기로 옮기고 얼굴 표정을 셀 수 없이 고친 흔적을 고스란히 볼 수 있다.

우리가 그림으로부터 배울 수 있는 것이 이것이다.
나는 해킹도 이와 같은 방식으로 진행되어야 한다고 생각한다.
프로그램을 위한 스펙 요구사항 이 완벽할 것이라고 기대하는 것은 환상이다.

그것을 처음부터 인정하고, 개발 도중에 스펙이 바뀌는 것을 수용할 수 있는 방식으로 프로그램을 짜는 것이 현명할 것이다.

폴 그레이엄은 이 내용에 덧붙여

큰 회사에서는 이런 수정이 어렵기 때문에 스타트업이 가질 수 있는 강점으로 말했다.

셋, 우리가 말할 수 없는 것

그는 해커와 이단이 세상의 통념에 반해 혁신적인 생각을 한다는 의미에서 비슷하다고 본다.

이와 관련해, 위대한 업적은 다른 사람이 간과하는 생각에서 자라난다는 주장을 하며,

훌륭한 일을 수행하기 위해서는 우선 당신의 두뇌가 가볼 수 있는 모든 곳을 열심히 가보는 것이 좋다고 말한다.

이와 관련해서 기억에 남는 이야기가 하나 있다.

닫힌 사고,

: 말할 수 없는 것을 발견했을 때, 그것을 입 밖에 내지 말라.

미래에 노란색을 금지하는 운동이 일어날 거라고 가정해 보자.
노란색을 쓰려는 움직이려 한다면, 오직 노란색만 좋아하는 사람이라는 의미를 띤 "노란색주의자"라는 경멸적인 딱지가 붙는다.
오렌지색을 좋아하는 사람은 다소 의심을 받긴 하지만 용납이 된다.

그런 상황에서 당신이 노란색이 문제될 건 없다는 사실을 깨달았다고 하자.
만약 당신이 이 말을 한다면, "노란색주의자" 라는 딱지가 붙을 것이다.
또, 반노란색주의자들과의 엄청난 논쟁에 휘말리게 될 것이다.

당신의 삶의 목표가 노란색의 권리를 회복시키는 것이라면, 원하던 바일 것이다.
하지만 당신이 다른 일에 더 관심이 있다면, 노란색주의자라는 딱지는 방해가 될 것이다.
-

가장 중요한 점은 당신이 원하는 것을 말하는 것이 아니라, 그냥 생각하는 것이다.

만약 당신이 스스로 생각하는 모든 것을 입 밖으로 내어 말한다면, 그것은 파격적인 생각에 방해가 된다.

당신의 생각과 말 사이에 날카로운 경계선을 그어라.

머릿속에서는 무엇이라도 허용이 되지만, 외부자에게 발설되면 곤란하다.

그의 재미난 생각이 인상깊었고, 그가 이를 통해 전하고자 하는 얘기 또한 흥미로웠다.

과감한 생각을 창의적인 스토리로 표현해냈다는 게 인상깊었던 것 같다.

사실, 해당 내용의 저자가 하고 싶은 내용을 온전히 받아들이진 않은 것 같다.

이유는 머리로는 이해를 했고, 실제로 본인이 머릿 속에서만 생각을 해온 적이 있기 때문이다.

하지만, 이 것이 한 번도 파격적인 생각을 만들어 낸다는 생각을 해본 적이 없어서 그렇다고 느낀다.

만약 이후 본인이 파격적인 생각을 하고 있고, 이를 통해 더 큰 파격적인 생각을 했음을 의식한다면

그 때 분명 이 책이 기억날 것이다.

여덟, 스팸을 위한 계획

폴 그레이엄은 스팸 필터 알고리즘을 처음 개발한 사람으로도 유명한데,

관련된 내용을 본 책에서 다루었다.

스팸 메일을 필터링할 때 어떻게 할지 한 번 생각해보며 읽어보며 그 내용은 꽤 흥미로웠다.

스팸은 몇 가지 간단한 규칙만으로도 대부분의 스팸을 막아낼 수 있다.

가령, "클릭"이라는 단어를 포한한 메일을 스팸으로 간주해보면 79.9%가 올바르게 필터링 되었고, 1.2%의 정상 메일이 잘못 걸러졌다.

오히려 필터링 규칙을 지나치게 강화하면 잘못된 필터링의 확률이 높아진다고 한다.

이와 관련한 메일 필터링에 대한 저자의 이야기가 더 나오는데, 이 부분을 굉장히 흥미롭게 읽었다.

열하나, 100년 후의 프로그래밍 언어

그는 언어를 만들면서 스스로 깨달은 사실과 그의 견해들을 분석적이고 냉소적으로 말하곤 한다.

내가 자바는 성공적인 언어가 아니라고 말하는 이유는 더 구체적이다.
결국 자바도 진화의 과정에서 언젠가 막다른 길에 이르게 될 것이라는 의미다.

폴 그레이엄은 자바 언어에 대한 종말의 가능성을 열어둔다.

그가 주장하는 내용들을 보았을 때, 이런 주장을 꽤 선명하게 느낄 수 있다.

위 문장의 바로 다음 문장에 부정의 가능성을 열어두지만 말이다.

하지만 이것은 단지 추측에 불과하다. 내가 틀릴 수도 있다.

이후, 그가 말하는 프로그래밍 언어의 특징에서 그 이유를 찾을 수 있는데,
그 내용은 바로 다음 문단에 나오는 말이다.

프로그래밍 언어의 발전 가능성은 제한되어 있고,
쉽게 변종이 탄생하지 않기 때문에 수렴convergence이라는 현상은
실제 종의 진화보다 언어에서 더 잘 일어날 것이다.
언어를 설계하는 사람들은 다른 언어로부터 아이디어를 빌려오기 위해서 의식적으로 노력하기도 한다.

위를 본인의 표현으로 풀어보자면 다음과 같다.
프로그래밍 언어는 수 많은 나무 줄기처럼 생성되기도, 뻗어나아가기도 한다.
하지만, 프로그래밍 언어의 진화는 마치 로그 그래프가 점근선을 따라 한계지어지는 것처럼,

점근선이라는 한계가 존재한다는 것이다.

언어가 발전될 때 발견할 수 있는 재미있는 사실이 있는데,

고급 프로그래밍 언어와 점점 멀어지는 언어들이 생겨난 후,

그 언어들이 발전할 때마다 그 언어는 점점 근본 언어들의 모습과 비슷해진다는 것이다.

이후에는 리스프 언어에 대한 이야기들이 주를 이룬다.

한 번쯤 읽어보기 좋은 내용들로 구성된다.

만약, 본인이 신입이거나 자신의 개발 이념을 환기시키고 싶다면 한 번쯤 읽어볼만한 내용이다.

HABITUS - 아비투스, 도리스 메르틴

gngsn — Mon, 13 Nov 2023 03:26:30 +0900

Habitus: Sind Sie bereit für den Sprung nach ganz oben?, Doris Märtin

Date: 2023.10.14 ~ 2023.11.12

Rate: ★ 3.2

Pages: 327

Comment: 본 책의 주요 내용은 사회 내 빈곤, 중간, 최상층 사람들이 가진 아비투스를 분석한 내용이다. 객관적인 시선으로, 사회 활동을 하는 인간들을 재산으로 구분했을 때, 그들의 행동 양식을 분석한 내용들을 얘기한다. 이러한 아비투스를 바꿀 수 있다고 말하는 부분도 있지만, 강한 필자의 의견까지는 느껴지지 않았다. 디테일이 부족했다고 느꼈다.

아비투스를 읽기 전, 기대했던 내용은 인간이 살고 있는 환경에 대한 분석, 그리고 만족스러운 주변 조건들을 만들어가기 위한 새로운 관점이나 깨달음이었다.책을 읽고 본인에게 반영시킬만한 내용을 주로 찾곤하는데, 본 책에서는 해당 내용을 찾기는 어려웠다.

최상층(슈퍼 리치) 계급이 어떠한 특성을 보이니, 그들을 따라해보자를 메세지로 받을 수 있겠지만, 그 정도의 재산을 갖고 난 후, 스스로에게 반영시킬 순 있겠지만, 빌게이츠 같은 빌리어네어 가족이 아닌 이상, 글쎄 아직까지 본인에게 크게 와닿는 내용은 아닌 것 같았다. 적어도, 본인의 행동을 돌아보며 본인의 품격을 돌아보며, 특정 행동은 삼가고 특정 행동은 조금 더 취할 수 있겠다는 생각을 종종 하곤 했다.

개인적으로, 해당 책을 읽으면서 최상위 층의 행동 양식을 따라해야할 때의 가이드를 받고 있다는 생각을 떨치지 어려웠다. 과연, 정말로, 부의 최상위 계층의 행동 양식을 분석해서 이를 고려하며 살아가는 게 우리의 인생을 위한 것인가?라는 의구심이 들었다. 하지만, 본 책이 실제 부유한 계층과 그렇지 않은 계층을 객관적인 시선으로 잘 분석했다. 행동 양식의 차이, 사회망과 각 계층의 심리적인 차이를 분석한 내용은 꽤 흥미로웠다.

Summary: 아비투스는 사회적 지위이자 결과이며 표현이다. 특정 계층의 사람들은 해당 계층의 아비투스 성향을 강하게 보인다. 하지만, 당신이 진정으로 원한다면 이러한 아비투스를 변화시킬 수 있다.

필자는 아비투스를 결정짓는 심리·문화·지식·결제·신체·언어 7가지의 품격의 차이를 분석했으며, 이를 제시하며 책을 구성한다. 또한, 최상층 아비투스를 분석하고 제시함으로써 그들 사이에 속하기 위해 어떤 행동을, 그리고 어떤 조건을 가져야 하는지를 생각케 한다.

결론적으로, 품위와 격식을 보이는 행동이 무엇인지를 구분하며, 돈만이 진짜 부자를 진짜 부자처럼 만들지 않음을 전달한다. 돈 만이 아니라 그들의 행동, 사회망, 가치관 모두가 진정한 부자를 표현한다.

아비투스 HABITUS

타인과 나를 구별 짓는 취향, 습관, 아우라

사회문화적 환경에 의해 결정되는 제2의 본성

계층 및 사회적 지위의 결과이자 표현

아비투스가 삶, 기회, 지위를 결정한다.

"인간도 각자 다른 조건을 갖고 삶을 시작한다. "

어디에서 태어났느냐에 따라 우리는 성공에 유리한 아비투스를 많이 혹은 적게 몸에 익힌다.
행동 방식과 생활방식, 지위와 언어, 자원, 성공 기회, 삶에 대한 기대에서 추진력을 얻느냐 제동이 걸리느냐는 아비투스에 달렸다.

아비투스는 공평하지 않다.

사회적 서열이 높은, 흔히 재산과 권력을 크게 갖고 있는 부모가 있다면,

그만큼의 재산과 권력을 다른 계층보다 더 쉽게 얻게 된다.

부모가 빌리어네어라면, 그 사회 환경, 문화, 경제, 품위는 그들의 본성이 되어 자라게 된다.

아비투스는 사회적 지위의 결과이자 표현이다.
아비투스는 우리의 사회적 서열을 저절로 드러낸다.

출신 아비투스는 비록 우리의 일부이긴 하지만,
우리가 출신 배경을 뛰어넘어 성장하는 것을 막지는 못한다.

아비투스는 사회 내에서 한 사람의 위치를 강하게 표현하곤 한다.

그럼에도 불구하고, 이 아비투스를 바꿀 수 있고 우리는 돈 뿐만 아니라,

심리, 문화, 지식, 결제, 신체, 언어 등 7가지 자본을 타인과 잘 구별되도록함으로써 우리의 품격을 높일 수 있다고 한다.

우리의 행동이 애쓰는 것처럼 보이지 않고 자연스럽게 느껴지기까지는 오랜 시간이 걸리지만 그렇게 차곡차곡 쌓인 아비투스는 빌려 입은 가짜가 아니라 진짜 외투다. 콜롬비아의 사회학자 샤무스 칸(Shamus Khan)의 말처럼 “우리는 타고난 취향, 가치관, 성향을 그대로 받아들이는 대신 자신이 닮고 싶은 역할을 배우고 행동한다. 시간이 지나면 연기가 아닌 타고난 본성처럼 보이게 된다”.

그러므로 새로운 곳에 처음부터 완전히 소속되고 싶더라도 여유를 갖고 아비투스가 서서히 물들게 놔두기를 권한다. 관찰하라. 뒤로 물러나 상황을 탐색하라. 그리고 적합한 아비투스가 저절로 생길 것을 믿으라. 우리는 오랫동안 그것을 경작하기만 하면 된다.

우리의 아비투스를 바꾸기 위해서는 오랜 시간이 필요하다.

한 번에 바꾸려하지 말고 서서히 그들(최상위 층)에 물들일 수 있게끔 기다리고 관찰하라.

본 책의 주 내용은 아비투스를 이루는 7가지의 자본인데,

필자는 자본 유형을 다양하게 가질수록 더 높이 올라간다고 말한다.

요약해보자면, 아래와 같다.

#1. 심리자본

: 낙관주의, 열정, 상상력, 끈기

잠재력을 온전히 실현하느냐 아니면 중간 수준에 머물게 하느냐는 심리적 안정감에 달려 있다.

늘 같은 곳에 머물러 있지 마라

어떤 아비투스도 돌에 새겨지지 않았다.
미국의 심리학자 캐럴 드웩(Carol Dweck)은 한계를 긋는 태도를 ‘고정 마인드셋’이라고 불렀다.
고정 마인드셋을 가진 사람은 “나는 원래 수학을 못해”라고 확신하는 고집스러운 어린아이와 같다.

인간은 선천적으로 특정 능력을 타고나는데, 그 능력은 살면서 거의 변하지 않는다고 한다.

안정적인 수준에서 안도하느냐, 늘 새로운 것에 도전할 줄 아느냐로 구분된다.

아비투스를 바꾸려면 성장 마인드셋을 가지는 것이 필요히다.

하지만, 고정 마인드셋이 부정적인 것만은 아니다.

심리학자 가나자와 사토시의 연구에 따르면 흔히 고집스럽게 틀을 유지하는 사람이 과감하게 앞을 향해 가는 사람들보다 아이큐가 더 낮게 보이지만, 더 만족스럽게 살고 가족과 친구를 더 많이 돌보고 더 많은 돈을 번다고 한다.

회복 탄력성

플랜A가 실패하면 당황할 필요 없다.
플랜B, 플랜C… 알파벳은 아직 25개나 더 있다”라는 사실을 깨달았기 때문이다.

신체 근육과 마찬가지로 내적 저항력도 체계적으로 단련한 덕분에
그들은 어려운 상황에서 다른 사람보다 더 위엄 있게 대처한다.

여기서 말하는 "그들은" 성공을 해본 사람들을 의미한다.

칭찬에는 교묘한 암시가 숨어 있다.

칭찬하는 사람은 칭찬하는 대상과 자신을 같은 수준에 둔다.

폴리에스테르 스카프를 맨 사람이 부자 친구의 캐시미어 원단을 칭찬하는 건 살짝 기이해 보인다.

작가 오스카 와일드는 칭찬에 대한 정확한 지침을 준다.

칭찬은 향수와 같다.
향을 내되 코를 찔러서는 안 된다.

감탄과 인정은 섬세한 감각이 필요하다.

#2. 문화자본

: 선망과 존중을 받는 코드와 취향.

몸에 밴 고급문화와 탁월한 사교술이 고전적 문화자본이라면,

주의 깊고 한결같은 생활 양식 혹은 용기 있는 기행과 개별성이 문화자본이다.

가장 갖기 어려운 자본이다.

격식이 필요한 지위에 오르기 전에 미리 몸에 익혀둬야 한다.

#3. 지식자본

: 졸업장, 학위, 전문 지식, 경력, 학술 및 기능 자격증,

자신의 지식과 역량으로 어떤 일을 해내는 능력

매일 책을 500쪽 씩 읽으십시오.
지식은 그렇게 복리 이자처럼 쌓입니다.
여러분 모두는 그럴 가능성을 가졌습니다.
하지만 장담하건대 여러분 중 극히 일부만이 그 가능성을 이용할 것입니다.

- 워렌 버핏

초보자의 오만에 빠지지 않게 조심하라.

“내가 아무것도 모른다는 것을 나는 안다.”
그리스 철학자 디오게네스는 이 말로 많은 이들이 놓치는 지혜를 보여주었다.

초보자는 특히 첫걸음을 뗀 후에 자신의 실력을 과대평가한다.
비행기 조종사는 첫 800시간 비행 뒤에 사고율이 서서히 오른다.
의사들은 보통 수술을 16회에서 20회 했을 때 실수를 저지른다.
아직 루틴으로 몸에 배지 않았지만 조심성이 약해졌을 때를 조심하라.

본 책을 읽으면서, 가장 생산적으로 느꼈던 구문이다.

가장 공감이 가는 문장 구문 중에 추후 인용하고 싶은 구문이라고 생각했기 때문이다.

#4. 경제자본

: 소득, 현금 자산, 부동산, 주식, 연금, 보험, 예상되는 상속 재산 등 모든 물질적 재산.

경제자본이 넉넉하면 굴복하지 않아도 된다. 영화 「겜블러」에서, 사채업자 프랭크로 분한 존 굿맨이 이것을 설명한다. “30억 원을 딴 게 무엇을 뜻하는지 바보 멍청이도 알아. 죽을 때까지 ‘fuck you-지위’를 갖는 거야. 누군가 당신에게 지시를 내려? fuck you! 상사가 괴롭혀? fuck you! 영리한 남자는 ‘fuck you’로 사는 거야.” ‘재정적 독립’ 혹은 ‘fuck you-지위’, 뭐라고 부르든 상관없다. 어느 정도 재산이 있으면 자신을 굽히지 않아도 되고 다양한 영향을 받지 않아도 된다. 또한 더 많이 가지려는 욕구도 같이 올라간다.
돈이 없으면 엄두 내지 못했을 일들을 실행한다. 독립하기, 소설 쓰기, 다른 분야로 사업 확장하기, 마음에 담아두었던 특수 기기 구매하기, 유망한 스타트업 인수하기. 종종 이런 행위가 토대가 되어 더 높은 소득 가능성과 야망이 생긴다. 이것이 다시 추진력을 키운다. 그 결과는 선순환이다.

현실을 객관적으로 본 내용이다.

돈이 있다면, 어떤 것을 시작할 때의 두려움은 줄어든다.

이 추진력이 더 높은 소득과 야망을 불러일으키는 충분한 불씨가 된다.

또한, 필자는 경제 자본을 목적으로 일하는 사람들은 그 적극성이 더 크다고 한다.

이 또한 동의한다.

경제 자본을 얻기 위해 일을 하고, 또 그 경제 자본을 얼마나 보유했는지에 따라 그들의 행동, 품위 또한 달라진다.

#5. 신체자본

: 스스로 얼마나 매력적이고 건강하고 활기차다고 느끼는지에 대한 판단.

사람들은 외형에서 사회적 지위, 내적 가치를 유추한다.

"각자의 몸에서 최적화된 의지와 적절함을 드러내는 것이 중요해질 것이다.”
날씬하지만 마르진 않았다. 몸을 단련하지만 광적이지 않다. 건강하게 살지만 강박적이지 않다. 자기 관리에 신경 쓰지만 그것 때문에 거울 앞에서 많은 시간을 보내진 않는다.

#6. 언어자본

: 유창한 언변으로 사람들에게 다가가고 다양한 관점에서 구체적, 객관적으로 주제를 설명할 수 있는 능력.

어디에서 무슨 주제를 어떤 방식으로 말해야 할지 아는 것이 특히 중요하다.

심리학에서는 성공한 사람의 겸손한 자세를 '카운터시그너링(countersignaling)'이라고 하는데,

한 문장으로 말하면 다음과 같다.

"과시하지 않음으로써 과시한다."

#7. 사회자본

: 누구를 아는가. 개인이나 집단과 얼마나 잘 지내는가.

든든한 가족, 훌륭한 롤모델, 도움을 줄 수 있는 인맥, 진정성 있는 멘토, 결정권자와의 친분, 서로를 격려하는 동료, 영향력, 권력, 가시성.

누가 인생 도박에서 잭팟을 터트릴지는 태어날 때부터 거의 결정된다.

경제자본과 문화자본이 많은 가정에서 태어난 아기는 고상한 출신 아비투스를 같이 얻을 확률이 높다.

아기는 태어나자마자 상류층의 언어, 사고, 행동을 흡수한다. 이후의 삶에서도 마찬가지다.
부모가 부자 동네에 사는가? 그렇다면 당신은 틀림없이 상급학교 진학률이 높은 초등학교에 입학한다.
처음 사귄 친구가 부모 손에 이끌려 정기적으로 미술관에 가는가?
그러면 당신도 전에 없던 관심이 덩달아 생긴다. 엄마의 친구가 중견기업 사장인가?
그곳에 입사하면 당신은 처음부터 유리한 업무를 맡는다.

사회적 관계는 문화, 재정, 사회적으로 우리를 앞서게 한다. 출신은 내장된 프로그램이다. 하지만 우리는 그것을 뛰어넘어 자신의 힘으로 사회자본을 축적한다. 출신을 뛰어넘어 좋은 인생을 뒷받침할 관계망을 직접 구축할 가능성이 그 어느 때보다 높아졌다.

사회 자본은 이미 최상위 계층의 아비투스와 구분될 수 밖에 없는 조건이다.

Docker Swarm, 제대로 이해하기 - Swarm & Service

gngsn — Mon, 30 Oct 2023 00:00:26 +0900

본 포스팅은 Docker Swarm 과 Service의 개념을 익히고 실제 사용할 수 있도록 데모를 실행해보는 것을 목표합니다.

Docker Series

Docker Engine, 제대로 이해하기 (1) - docker engine deep dive

Docker Engine, 제대로 이해하기 (2) - namespace, cgroup

Docker Network, 제대로 이해하기 (1) - libnetwork

Docker Network, 제대로 이해하기 (2) - bridge, host, none drivers

Docker, 제대로 사용하기 - Commands

> Docker Swarm, 제대로 이해하기 - Swarm & Service

Docker Swarm

: 여러 도커 호스트를 클러스터로 묶어 주는 컨테이너 오케스트레이션 도구의 한 종류

Swarm으로 클러스터의 앞 쪽에서 하나 이상의 도커 노드를 그룹화하여 클러스터로 관리할 수 있습니다.

도커 호스트 여러 대를 사용할 때, 컨테이너 오케스트레이션 도구 없이는 확장성있는 애플리케이션을 만들기가 매우 어렵습니다.

어느 도커 호스트에 어떤 컨테이너를 배치해야 할지,
서로 다른 호스트에 위치한 컨테이너간의 통신은 어떻게 제어하는지 등의 조율을 오케스트레이션 도구없이 하기에는 무리가 있습니다.

오케스트레이션 도구를 도입하면 이러한 조율에 수고를 줄여 줄 뿐만아니라,
호스트가 여러대로 나뉘어 있다는 점을 신경 쓰지 않고,

클러스터를 투명하게 다룰 수 있다는 이점도 있습니다.

컨테이너 그룹을 오케스트레이션하기 위해서 알아볼 키워드를 정리하자면, 아래와 같습니다.

이름	역할	대응하는 명령어
Compose	여러 컨테이너로 구성된 도커 애플리케이션을 관리 (주로 단일 호스트)	`docker-compose`
Swarm	클러스터 구축 및 관리(주로 멀티 호스트)	`docker swarm`
Service	스웜에서 클러스터 안의 서비스(컨테이너 하나 이상의 집합)를 관리	`docker service`
Stack	스웜에서 여러개의 서비스를 합한 전체 애플리케이션을 관리	`docker stack`

Swarm 은 아래의 두 가지 용도로 사용할 수 있습니다.

✔️ 상용 도커 호스트의 보안 클러스터

An enterprise-grade secure cluster of Docker hosts

✔️ 마이크로서비스 앱의 오케스트레이터

An orchestrator of microservices apps

Benefits

Swarm은 따로 설치나 설정 없이도 바로 사용할 수 있는 Out-of-the-box 서비스로 아래와 같은 기능을 제공합니다.

- 암호화된 분산 클러스터 스토어 Encrypted distributed cluster store

- 암호화된 네트워크 Encrypted networks

- Mutual TLS

- 보안을 위한 클러스터 조인 토큰 Secure cluster join tokens

- 인증서 관리 및 재발급을 쉽게 해주는 PKI

또, 노드를 중단 없이 non-disruptively 추가 및 제거할 수도 있습니다.

오케스트레이션 앞 쪽에서, 스웜으로 복잡한 마이크로서비스 앱을 쉽게 배포하고 관리할 수 있습니다.

앱을 정의하는 파일을 제작한 후, 네이티브 도커 명령으로 스웜에 배포할 수 있습니다.

뿐만 아니라, 도커가 기본으로 제공하는 간단한 명령으로 롤링 업데이트, 롤백, 스케일링 작업까지 수행할 수 있습니다.

Swarm은 쿠버네티스 Kubernetes 와 비슷하게 컨테이너화된 애플리케이션을 오케스트레이션합니다.

쿠버네티스는 훨씬 더 많은 탄력성과 더 활발한 커뮤니티 및 생태계를 가지고 있지만,

Swarm은 쉽게 사용할 수 있고, 많은 중소기업과 애플리케이션 배포 시 채택되고 있습니다.

혹은, 쿠버네티스를 학습하기 위해 Swarm을 먼저 알아두면 큰 도움이 될 수 있습니다.

Commands

데모를 생성하기 전에, 사용할 모든 명령어들을 먼저 훑어 보겠습니다.

✔️ docker swarm init : 새로운 swarm 생성

해당 명령어를 실행하는 노드가 첫 번째 관리자가 되어, swarm mode로 실행되도록 전환됩니다.

✔️ docker swarm join-token : worker와 manager를 swarm에 포함시키기 위해 필요한 명령과 토큰 발급

새로운 manager를 가입시키기 위해서 docker swarm join-token manager 명령을 사용합니다.

새로운 worker를 가입시키기 위해서 docker swarm join-token worker 명령을 사용합니다.

토큰은 반드시 안전하게 보관합니다.

✔️ docker node ls : swarm 내의 모든 노드를 나열

어떤 게 manager인지 또 어떤 게 leader 인지를 포함한 모든 노드를 확인할 수 있습니다.

✔️ docker service create : 새로운 서비스를 만드는 명령어

✔️ docker service ls: 실행 중인 서비스를 나열

실행 중인 서비스를 확인할 수 있어, 서비스 상태 및 실행 중인 replicas에 대한 기본 정보를 확인할 수 있습니다.

✔️ docker service ps <service> : 특정 서비스 replicas에 대한 보다 자세한 정보 제공

✔️ docker service inspect : 서비스에 대한 매우 상세한 정보 제공

가장 중요한 정보만을 확인하려면 위해 --pretty 플래그를 입력할 수 있습니다.

✔️ docker service scale : 서비스의 복제본 수를 확장하거나 수축

✔️ docker service update : 실행 중인 서비스의 많은 속성을 업데이트

✔️ docker service logs : 서비스의 로그 확인

✔️ docker service rm : swarm에서 서비스를 삭제

확인을 요구하지 않고 모든 서비스 복제본을 삭제하므로 주의하여 사용해야 합니다.

Swarm Hands-on

실제 swarm을 제작해보겠습니다.

Single engine mode vs Swarm mode

swarm에 포함되지 않은 도커 노드는 single-engine mode라고 합니다.

swarm에 추가되면 자동으로 swarm mode로 전환됩니다.

single-engine mode로 도커 호스트에서 docker swarm init 을 실행하면,

해당 노드가 swarm mode로 전환되고, 새로운 swarm을 생성하며 노드가 스웜의 첫 번째 관리자가 됩니다.

그러면 추가 노드를 worker 또는 manager로 포함될 수 있으며,

이 때 자동으로 swarm mode로 전환됩니다.

Overview

실제 진행할 데모에 대해 알아보겠습니다.

먼저, Manager 2대, Worker 3대의 컨테이너를 생성합니다.

스웜을 구축하는 과정을 스웜 초기화라고 하며, 크게 아래의 과정으로 진행됩니다.

1. Manager 초기화 및 등록 Initialize the first manager

2. Workers 등록 Join workers

✔️ manager

Control plane 관리. Cluster의 상태 관리나 worker에게 task를 보내는 것과 같은 swarm 전체를 제어하는 역할

✔️ worker

manager로부터 작업을 수락하고 실행

Manager 1 에서 새로운 swarm을 생성하기 위해 초기화 명령어를 입력합니다.
그런 다음 Worker 1, Worker 2 및 Worker 3를 워커 노드로 합류시키는데,

이 과정에서 해당 컨테이너들은 자동으로 swarm mode로 전환됩니다.
마지막으로 Manager 2 를 추가 관리자로 등록하는데, 이 때도 동일하게 자동으로 swarm mode로 전환됩니다.
모든 과정이 끝나면 5개 노드 모두 swarm mode임을 확인할 수 있으며, 동일한 swarm로써 작동하게 됩니다.

여러 대의 도커 호스트로 스웜 클러스터 구성하기

Docker Machines
여러 대의 도커 호스트를 만들 수 있으며, 도커 머신즈를 사용하려면 macos 에서는 virtualbox 드라이버, 윈도우에서는 hyperv 드라이버가 각각 필요합니다.

Virtual Box
같은 가상화 소프트웨어를 사용하면 물리 호스트 1대에 여러 대의 도커 호스트를 실행할 수 있음 도커 공식 참조 문서에서도 이 방법을 소개하고 있습니다.

Docker in Docker
= dind. 도커 호스트 역할을 할 도커 컨테이너를 여러 개 실행하는 방법이며, 도커 컨테이너 안에서 도커 호스트를 실행할 수 있습니다.

1. docker-compose 작성

먼저, swarm이라는 디렉토리 하나를 생성해서 docker-compose를 구성합니다.

❯ mkdir swarm
❯ cd swarm
❯ vi docker-compose.yml

version: "3" 
services:
  registry:
    container_name: registry
    image: registry:2.6
    ports:
      - 5000:5000
    volumes:
      - "./registry-data:/var/lib/registry"

  manager:
    container_name: manager
    image: docker:dind
    privileged: true
    tty: true
    ports:
      - 8000:80
      - 9000:9000
    depends_on:
      - registry
    expose:
      - 3375
    command: "--insecure-registry registry:5000"
    volumes:
      - "./stack:/stack"

  worker01:
    container_name: worker01
    image: docker:dind
    privileged: true
    tty: true
    depends_on:
      - manager
      - registry
    expose:
      - 7946
      - 7946/udp
      - 4789/udp
    command: "--insecure-registry registry:5000"

  worker02:
    container_name: worker02
    image: docker:dind
    privileged: true
    tty: true
    depends_on:
      - manager
      - registry
    expose:
      - 7946
      - 7946/udp
      - 4789/udp
    command: "--insecure-registry registry:5000"

  worker03:
    container_name: worker03
    image: docker:dind
    privileged: true
    tty: true
    depends_on: 
      - manager
      - registry
    expose:
      - 7946
      - 7946/udp
      - 4789/udp
    command: "--insecure-registry registry:5000"

2. docker-compose 실행

이제 docker-compose.yml 실행합니다.

❯ docker-compose up -d
[+] Running 6/6
 ✔ Network swarm_default  Created                                                                                                                                                                              0.0s 
 ✔ Container manager02    Started                                                                                                                                                                              0.8s 
 ✔ Container manager01    Started                                                                                                                                                                              0.6s 
 ✔ Container worker02     Started                                                                                                                                                                              1.8s 
 ✔ Container worker01     Started                                                                                                                                                                              1.7s 
 ✔ Container worker03     Started

오류 발생
Your kernel does not support cgroup memory limit

해결
: Apple M2 Chip에서 발생한 오류로, docker-image 변경함

Before
image: docker:18.05.0-ce-dind

After
image: docker:dind

3. 새로운 swarm 초기화

docker swarm init 명령어로 도커를 manager로 지정합니다.

❯ docker container exec -it manager01 docker swarm init
Swarm initialized: current node (2kgbjysdan5582hetvrlz0a66) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-1dke3... 172.21.0.2:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

위의 명령어와 같이 swarm init 명령 성공하게 되면, 해당 도커 호스트는 manager로 마킹되면서

swarm mode가 활성화됩니다.

종료 후 출력된 join 토큰을 확인할 수 있습니다.

해당 토큰을 통해 worker docker 를 해당 manager가 관리하게끔 만듭니다.

Token

토큰은 위처럼 생성 시 확인할 수도 있고, join-token 명령어를 통해 확인할 수 있습니다.

Worker를 등록하고자 토큰을 발급하고 싶다면, 아래와 같이 worker 를 입력합니다.

❯ docker container exec -it manager01 docker swarm join-token worker
To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-543ojw1... 172.23.0.2:2377

또 다른 manager를 등록하고자 한다면, manager를 입력하여 발급받습니다.

❯ docker container exec -it manager01 docker swarm join-token manager
To add a manager to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-543ojw1... 172.23.0.2:2377

4. Swarm에 Worker 등록

worker 컨테이너에서 manager 컨테이너를 식별하도록 manager:2377 로 join 토큰 전달합니다.

❯ docker container exec -it worker01 docker swarm join --token SWMTKN-1-1dke3... manager01:2377
This node joined a swarm as a worker.

나머지도 등록해줍니다.

❯ docker container exec -it worker02 docker swarm join --token SWMTKN-1-1dke3... manager01:2377
This node joined a swarm as a worker.
❯ docker container exec -it worker03 docker swarm join --token SWMTKN-1-1dke3... manager01:2377
This node joined a swarm as a worker.

5. Swarm에 추가 Worker 등록

추가 manager를 등록합니다.

위에서 살펴본 join-token 명령어에 manager를 입력하여 발급받습니다.

❯ docker container exec -it manager01 docker swarm join-token manager
To add a manager to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-1dke3... 172.21.0.2:2377

발급받은 토큰을 이용해 manager로 등록해줍니다.

❯ docker container exec -it manager02 docker swarm join --token SWMTKN-1-1dke3js... manager01:2377
This node joined a swarm as a manager.

6. Swarm cluster 상태 확인

그럼 이후 manager에 등록된 노드들을 확인할 수 있습니다.

❯ docker container exec -it manager01 docker node ls
ID                            HOSTNAME       STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
ifc8dg8cdl0rwvw66lfd8yhha     0bfa1e8e38bc   Ready     Active         Reachable        24.0.6
fynomalhu2fryrut2hh2e75dx     055ede599440   Ready     Active                          24.0.6
cslu1q9tv2vqcgch8ji9rjff5     77539678ba45   Ready     Active                          24.0.6
xqsafi0huh7azu1sg2dyfk5r3 *   ac9c5449faa0   Ready     Active         Leader           24.0.6
r5umbj98vrl6huftnhwrqou1k     cbcf19990e5e   Ready     Active                          24.0.6

Swarm Lock

이전 manager를 다시 시작하거나, 이전 백업을 복원하면 클러스터에 충돌이 발생할 수 있습니다.

이전 manager가 다시 조인하면 암호를 해독하여 Raft log time-series database에 액세스할 수 있고,

현재의 Swarm configuration을 오염시키거나 삭제할 수도 있습니다.

이러한 상황을 방지하기 위해 도커는 Autolock 기능으로 스웜을 잠글 수 있습니다.
이는 클러스터에 다시 들어가기 전에 관리자가 키를 제시하도록 강제합니다.

초기화 과정에서 --autolock 플래그를 docker swarm init 명령에 전달하여 스웜을 잠글 수 있지만,

이미 Swarm을 구축했기 때문에 docker swarm update 명령을 사용하여 Swarm을 잠가야 합니다.

Swarm의 manager에게 다음 명령을 실행합니다.

$ docker swarm update --autolock=true
Swarm updated.
To unlock a swarm manager after it restarts, run the `docker swarm unlock` command and 
provide the following key:

   SWMKEY-1-XDeU3XC75Ku7rvGXixJ0V7evhDJGvIAvq0D8VuEAEaw

Please remember to store this key in a password manager, since without it you will not be able
to restart the manager.

잠금 해제 키는 안전한 장소에 보관해야 합니다.

docker swarm unlock-key 명령으로 항상 현재 스웜 잠금 해제 키를 확인할 수 있습니다.

관리자 노드 중 하나를 재시작하여 클러스터에 자동으로 재가입되는지 확인합니다.

명령어 앞에 sudo를 붙여야 할 수도 있습니다.

$ service docker restart

# Try and list the nodes in the swarm.
$ docker node ls
Error response from daemon: Swarm is encrypted and needs to be unlocked before it can be used.

Docker service가 관리자에서 다시 시작되었지만 Swarm에 다시 조인하는 것은 허용되지 않았습니다.
다른 관리자 노드에서 docker node ls 명령을 실행해서 확인할 수 있습니다.
다시 시작된 manager는 down 과 unreachable 로 표시됩니다.

docker swarm unlock 명령을 실행하여, 재시작된 관리자에 대한 docker swarm unlock 명령을 실행합니다.

재시작된 manager에 대해 이 명령을 실행하고, 이 때 unlock 키를 함께 제공해야 합니다.

$ docker swarm unlock
Please enter unlock key: <enter your key>

노드는 swarm에 다시 가입할 수 있으며, 만약 docker node ls 명령을 하게 되면 ready 와 reachable로 표시 됩니다.
운영 환경에서는 스웜을 잠그고 unlock 키를 보호하는 것이 좋습니다.

Docker Service

위에서 생성한 Swarm을 배포하기 위해 Service를 생성하여 한 번에 배포합니다.

단일 도커 컨테이너 배포는 docker container run 명령으로 컨테이너를 하나씩 실행하거나,

compose 를 통해 여러 컨테이너 동시 실행하곤 합니다.

Swarm 은 아래와 같이 넓은 범위를 아우르게 구성될 수 있기 때문에,

애플리케이션을 구성하는 일부 컨테이너를 제어하기 위한 단위로 서비스라는 개념을 가집니다.

이번에는 생성한 Swarm을 배포해보겠습니다.

1. Service 생성

먼저, leader manager에 접속해서 서비스를 하나 생성합니다.

❯ docker container exec -it manager01 docker service create --replicas 1 --publish 8000:8000 --name echo gngsn/echo:latest
overall progress: 0 out of 1 tasks
1/1: preparing [=================================>                 ]

2. Service 확인

다음, 서비스가 제대로 생성되었는지 확인합니다.

❯ docker container exec -it manager docker service ls
ID             NAME      MODE         REPLICAS   IMAGE               PORTS
6royaikec2pg   echo      replicated   1/1        gngsn/echo:latest   *:8000->8000/tcp

3. Service Scaling

만약, 서비스 내에서 동일한 컨테이너 수를 늘리고 싶을 땐 어떻게 해야 할까요?

각각의 컨테이너 수만큼 docker container run명령을 반복해야겠지만, 현실적이지 않습니다.

docker service scales: 레플리카 수 조절

위 명령어는 자동으로 컨테이너를 복제하고 여러 노드에 배치합니다.

이를 통해 애플리케이션을 쉽게 스케일 아웃할 수 있습니다.

❯ docker container exec -it manager docker service scale echo=6

늘어난 REPLICAS 확인해보면, 6 개로 늘어난 것을 확인할 수 있습니다.

❯ docker container exec -it manager docker service ls
ID             NAME      MODE         REPLICAS   IMAGE                             PORTS
js126i5zxbe0   echo      replicated   6/6        registry:5000/gngsn/echo:latest   *:8000->8000/tcp

4. Service 삭제

생성한 서비스는 아래와 같이 제거할 수 있습니다.

❯ docker container exec -it manager docker service rm echo
echo

제거한 서비스를 확인해봅니다.

❯ docker container exec -it manager docker service ls
ID        NAME      MODE      REPLICAS   IMAGE     PORTS

FYI.

✔️ 서비스는 레플리카 수(컨테이너 수)를 조절해 컨테이너를 쉽게 복제할 수 있으며, 여러 노드에 레플리카를 배치할 수 있기 때문에 스케일 아웃에 유리

✔️ 서비스로 관리되는 (여러 개의) 레플리카는 서비스명으로 name resolution 되므로 서비스에 대한 트래픽이 각 레플리카로 분산됨

✔️ 스웜 클러스터 외부에서 스웜에 배포된 서비스를 이용하려면 서비스에 트래픽을 분산시키기 위한 프록시를 갖춰야 함

Docker, 제대로 사용하기 - Commands

gngsn — Tue, 17 Oct 2023 23:59:25 +0900

본 포스팅은 Docker 명령어 중, 실제 현업에서 많이 사용하는 명령어를 습득하고 적절한 상황에서 사용할 수 있도록 목표합니다.

Docker Series

Docker Engine, 제대로 이해하기 (1) - docker engine deep dive

Docker Engine, 제대로 이해하기 (2) - namespace, cgroup

Docker Network, 제대로 이해하기 (1) - libnetwork

Docker Network, 제대로 이해하기 (2) - bridge, host, none drivers

> Docker, 제대로 사용하기 - Commands

안녕하세요. 오늘은 Docker 명령어를 정리해보고자 합니다.

해당 포스팅에 작성된 명령어 이외의 많은 명령어들이 존재하지만,

본 포스팅은 실무에서 많이 사용하는 명령어를 기준으로 선별했습니다.

http://docker-saigon.github.io/post/Docker-Internals/

Docker Image

: Docker Container 를 구성하는 파일 시스템과 실행할 애플리케이션 설정의 템플릿

$ docker image --help

: 이미지를 다루는 명령어 도움말 확인

혹은 docker image COMMAND --help 와 같이 하위 명령어의 도움말을 확인할 수도 있습니다.

$ docker image build

build command

: Dockerfile 명세에 따라 도커 이미지 생성

$ docker image build -t IMAGE_NAME[:TAG] DOCKERFILE_PATH
# example. docker build -t vieux/apache:2.0 .

DOCKERFILE_PATH 는 이미지를 생성할 스펙을 담고 있는 Dockerfile의 위치를 입력하면 됩니다.

바로 아래의 예시를 보면, vieux/apache 라는 image 명의 2.0 태그를 달아 . 에 위치해 있는 Dockerfile로 새로운 이미지를 빌드합니다.

Option

-t : 태그 명을 붙임. 실제 상황에서 거의 필수적으로 사용되는 옵션

--pull : 캐시 값을 사용하지 않고 베이스 이미지를 강제로 새로 받아오는 옵션

Dockerfile에 작성한 FROM instruction에 지정한 이미지는,

호스트 운영체제에 캐시되어 해당 이미지를 사용할 때 캐시 값을 사용합니다.

이를 원치 않고, 베이스 이미지가 새롭게 다운 받아져와서 그 위에 본인의 이미지를 구축하고 싶을 때 사용합니다.

가령, latest 태그를 달고 있을 때 유용하게 사용할 수 있습니다.

$ docker search

: 저장소에 있는 이미지 검색

$ docker search [OPTIONS] TERM

공식 레포지토리의의 네임스페이스는 library 입니다.

Docker Hub 에는 이미지들의 기반이 되는 운영체제 (CentOS, Ubuntu, etc) 나,

언어의 런타임이나 미들웨어 이미지 등 이미 완전한 제품으로 관리되어 지는 이미지들이 많습니다.

덕분에 다른 사람들이 만든 이미지를 사용할 수 있는데, 이 때 어떤 이미지가 존재하는지 확인할 수 있는 명령어입니다.

$ docker search --limit 5 mysql
NAME            DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
mysql           MySQL is a widely used, open-source relation…   14517     [OK]       
mariadb         MariaDB Server is a high performing open sou…   5543      [OK]       
percona         Percona Server is a fork of the MySQL relati…   621       [OK]       
phpmyadmin      phpMyAdmin - A web interface for MySQL and M…   876       [OK]       
bitnami/mysql   Bitnami MySQL Docker Image                      98                   [OK]

Option

--limit : 검색 건수 제한

$ docker image pull

: 저장소에 있는 이미지 다운로드

$ docker image pull [OPTIONS] NAME[:TAG]

태그를 생략하면 기본값 (보통 latest)으로 지정된 태그로 적용됩니다.

대부분 이미지를 생성할 때, Docker Hub 에 이미 사전 정의되어 등록된 이미지를 불러와서 그 위에서 만들텐데요.
Docker Hub는 사전에 구축된 많은 이미지pre-built image들이 등록되어 있어,

직접 정의하고 구성할 필요 없이 바로 pull 받아 사용할 수 있습니다.
특정 image 또는 repository 를 다운로드하려면 docker pull 명령어를 사용합니다.

$ docker image ls

: 다운받은 도커 이미지 목록 확인

$ docker image ls [OPTIONS] [REPOSITORY[:TAG]]

현재 호스트 운영 체제 (docker demon이 실행중인 호스트 환경)에 저장된 도커 이미지의 목록을 보여줍니다.

$ docker image ls
REPOSITORY       TAG       IMAGE ID       CREATED        SIZE
redis            latest    6f3eb785c21d   3 weeks ago    157MB
apache/airflow   2.7.1     f08724944476   5 weeks ago    1.37GB
postgres         latest    ee56d70bcdf1   2 months ago   433MB

$ docker image tag

: 다운받은 도커 이미지 목록 확인

도커 이미지에 붙은 태그는 이미지의 특정 버전을 구별하기 위해 사용합니다.

$ docker image tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]

기본적으로, 한 이미지에 같은 태그가 여러 개 할당될 수 없습니다.

즉, 이미지 고유의 IMAGE ID 이외의, 한 이미지 당 태그는 식별될 수 있는 단위인 것입니다.

동일한 이미지를 조금씩 수정하고 빌드하다 보면 아래와 같이 <none> 값들을 확인할 수 있게 됩니다.

$ docker image ls -a
REPOSITORY       TAG       IMAGE ID       CREATED         SIZE
example/image    latest    ef864d623b3b   11 months ago   119MB
<none>           <none>    c0f8d921704c   11 months ago   119MB
<none>           <none>    7caafbde4e75   11 months ago   119MB

example/image라는 동일한 이미지를 수정했는데, 매번 latest가 새로운 이미지에 할당되면서 이전의 태그는 사라지게 됩니다.

태그는 이미지를 쉽게 참조할 수 있는 별명과도 같습니다.

버전 관리를 위해 태그를 통해 latest 의 버전을 남겨두고, latest 태그를 붙일 새로운 이미지를 붙이는 것이 좋습니다.

$ docker tag example/image example/image:1.0

이후 이미지를 확인하면 아래와 같이 태그는 다르지만 해시 값이 같은, 즉 동일한 이미지임을 확인할 수 있습니다.

$ docker image ls -a
REPOSITORY       TAG       IMAGE ID       CREATED         SIZ
example/image    1.0       ef864d623b3b   11 months ago   119MB
example/image    latest    ef864d623b3b   11 months ago   119MB

이미지 명이 아닌 아래와 같이 IMAGE ID 로도 수정할 수 있습니다.

# Tag an image referenced by ID
$ docker tag 0e5574283393 fedora/httpd:version1.0

$ docker image push

: 이미지를 저장소에 업로드

$ docker push [OPTIONS] NAME[:TAG]

생성한 이미지를 Docker Hub 와 같은 public registry에 업로드하기 위한 명령어입니다.

아래와 같은 예시를 확인할 수 있습니다.

이 때, 네임스페이스는 개인의 계정 혹은 특정 소속을 의미하기 때문에, tag 명을 변경해서 업로드해야 합니다.

가령, example은 필자의 계정/소속이 아니며, 필자의 아이디는 gngsn이기 때문에 아래와 같이 tag 명을 변경합니다.

$ docker image tag example/image gngsn/example:latest
$ docker image push gngsn/example:latest

이후, docker hub 에 push 명령어로 업로드할 수 있습니다.

공개 레포지토리에 Dockerfile을 업로드할 때에는 패스워드나 API 키 값처럼 민감한 정보가 포함되지 않게 주의하세요.

Docker Container

도커 컨테이너는 위에서 살펴본 Lifecycle 중 Running, Stopped, Deleted 의 3가지 상태를 가지며,

이를 컨테이너의 생애주기라고 합니다.

https://linuxhandbook.com/container-lifecycle-docker-commands/

✔️ 실행 중 :: RUNNING

docker container run 명령의 인자로 지정된 도커 이미지를 기반으로 커테이너가 생성되면,

이 이미지를 생성했던 Dockerfile에 포함된 CMD 및 ENTRYPOINT 인스트럭션에 정의된 애플리케이션이 실행됩니다.

이 때, 컨테이너의 상태가 실행 중이 됩니다.

✔️ 정지 상태 :: STOPPED

실행 중인 상태에 있는 컨테이너를 사용자가 명시적으로 정지하거나,

컨테이너에서 실행된 애플리케이션이 정상/오류 여부와 관계없이 종료된 경우,

컨테이너가 자동으로 정지 상태가 됩니다.

정지 상태에는 컨테이너가 가상 환경으로서 동작하진 않지만,

디스크에 컨테이너가 종료되던 시점의 상태가 저장되어 있습니다.

정지시킨 컨테이너를 다시 실행할 수 있습니다.

✔️ 파기 상태 :: DELETED

정지 상태인 컨테이너는 명시적으로 제거하지 않는 이상 디스크에 그대로 남아있습니다.

컨테이너를 빈번하게 생성하고 없애야 한다면 디스크를 차지하는 용량을 고려하여, 이를 완전히 삭제하는 것이 바람직합니다.

$ docker container run

: 컨테이너 생성 및 실행

도커 컨테이너를 실행 중 상태로 만들기 위해 사용합니다.

아래 인자 중 IMAGE는 IMAGE_NAME[:TAG] 혹은 IMAGE_ID 로 표현할 수 있습니다.

$ docker container run [OPTIONS] IMAGE [COMMAND] [ARG...]

가령, 아래와 같은 방식으로 컨테이너를 백그라운드에서 실행할 수 있습니다.

$ docker container run -d -p 9000:8080 gngns/example:latest

위 예시에서 -p 옵션을 통해 호스트 쪽 포트 9000을 컨테이너 쪽 포트 8080으로 포트 포워딩한 것을 확인할 수 있습니다.

서버 에플리케이션을 위해 도커를 사용하는 경우가 많기 때문에, -d 이나 -p 옵션을 사용할 일이 많이 있습니다.

option

✔️ -p: --port 의 축약형입니다.

위의 예시처럼 포트 포워딩을 원할 때 -p HOST_PORT:CONTAINER_PORT 와 같이 적용할 수 있습니다.

✔️ -d: --detach 의 축약형입니다.

container 실행을 background 에서 실행한 후 Terminal 제어권을 다시 돌려받습니다.

✔️ -it: docker container run 명령에 -it 인자를 전달하면 Dockerfile 에 정의했던 CMD 인스트럭션을 오버라이드할 수 있습니다.

-i옵션은 --interactive의 축약형입니다.

컨테이너를 실행할 때 컨테이너 쪽 표준 입력과의 연결을 그대로 유지하여,

컨테이너 쪽 셸에 들어가서 명령을 실행할 수 있다.

-t 옵션은 --tty 의 축약형입니다.

유사 터미널 기능을 활성화 하는 옵션인데,

-i 옵션을 사용하지 않으면 유사 터미널을 실행해도 입력할 수가 없으므로,

이를 같이 사용하기 위해 -it 의 형태로 자주 사용됩니다.

예를 들어 library/aipine:3.7의 CMD 인스트럭션은 /bin/sh 로, 셸을 실행하는데,

아래와 같이 다른 명령으로 오버라이드할 수 있습니다.

$ docker image pull alpine:3.7
# container 내 실행 중인 셸에 접속
§ docker container run -it alpine:3.7 uname -a

✔️ --name: container에 원하는 이름을 붙일 수 있습니다.

container 에 운영할 서비스 개발 중에는 같은 docker 명령을 반복 실행하는 등 container를 다룰 일이 많습니다.

기본적으로 container는 ID, NAME으로 식별할 수 있는데,

ID가 자동 생성되며, NAME은 container 가 실행되면 무작위의 단어로 이름 지어집니다.

하지만, docker container ls 명령으로 빈번하게 ID 나 이름을 확인하기가 번거롭습니다.

또, container ID와 자동 부여된 컨테이너 이름 모두 컨테이너가 실행되고 나야 알 수 있습니다.

이 문제를 해결할 수 있는 방법이 컨테이너에 이름을 붙이는 기능입니다.

$ docker container run --name CONTAINER_NAME IMAGE
# example. docker container run --name alpine alpine:latest

✔️ -v: --volume 의 축약형입니다.

Container 동작 시 데이터 볼륨을 지정할 수 있습니다.

데이터 볼륨은 호스트와 컨테이너 간에 디렉터리나 파일을 공유하기 위해 사용합니다.

$ docker container ls

: 실행 중이거나 종료된 컨테이너의 목록을 보여주는 명령

$ docker container ls [OPTIONS]

실제 명령을 실행해서 확인해보면 아래와 같은 필드를 확인할 수 있습니다.

$ docker container ls
CONTAINER ID   IMAGE          COMMAND                  CREATED       STATUS                 PORTS      NAMES
8b36b2e62616   postgres:13    "docker-entrypoint.s…"   2 weeks ago   Up 2 weeks (healthy)   5432/tcp   airflow-local-postgres-1
ca1d9ab8f694   redis:latest   "docker-entrypoint.s…"   2 weeks ago   Up 2 weeks (healthy)   6379/tcp   airflow-local-redis-1

✔️ CONTAINER ID : 컨테이너 식별자

✔️ IMAGE : 해당 컨테이너를 만드는 데 사용된 도커 이미지

✔️ COMMAND : 컨테이너에서 실행되는 애플리케이션 프로세스

✔️ CREATED : 컨테이너 생성 후 경과된 시간

✔️ STATUS : Up 이나 Exited 등 컨테이너의 실행 상태

✔️ PORTS : 포트 포워딩, 호스트 포트와 컨테이너 포트의 연결 관계

✔️ NAMES : 컨테이너의 이름

Option

✔️ -q: 컨테이너의 ID 만을 추출합니다.

✔️ --filter: 컨테이너 목록을 필터링합니다.

$ docker container ls --filter "FILTER_NAME=VALUE"

가령, 원하는 이름과 컨테이너 명이 일치하는 컨테이너의 목록을 보고 싶으면 name 필터를 사용합니다.

$ docker container ls --filter "name=redis"

✔️ -a: 종료된 컨테이너를 포함한 컨테이너 목록을 확인할 수 있습니다.

$ docker container stop

: 실행 중인 컨테이너 정지

$ docker container stop [OPTIONS] CONTAINER [CONTAINER...]

가령 아래와 같이 사용할 수 있습니다.

$ docker container run -t -d --name echo example/echo:latest
$ docker container stop echo
echo

echo 라고 이름붙인 컨테이너를 정지시킵니다.

$ docker container restart

: 실행 중인 컨테이너 재시작

정지 상태의 컨테이너를 재시작할 수 있습니다.

$ docker container restart [OPTIONS] CONTAINER [CONTAINER...]

가령, 정지해둔 echo 컨테이너를 아래와 같이 재시작할 수 있습니다.

$ docker container restart echo

$ docker container rm

: 정지시킨 컨테이너를 완전히 제거

$ docker container rm [OPTIONS] CONTAINER [CONTAINER...]

단, 현재 실행 중인 컨테이너는 제거할 수 없습니다.

만약 강제로 제거하고 싶다면 아래에 명세한 --force 옵션을 사용합니다.

실 업무 중 컨테이너 실행 및 정지를 반복하다 보면 아래와 같이 정지된 컨테이너가 여러개 생깁니다.

$ docker container ls --filter "status=exited"
CONTAINER ID   IMAGE          COMMAND                  CREATED       STATUS                   PORTS      NAMES
8b36b2e62616   postgres:13    "docker-entrypoint.s…"   2 weeks ago   Exited (2) 2 weeks ago   5432/tcp   airflow-local-postgres-1
ca1d9ab8f694   redis:latest   "docker-entrypoint.s…"   2 weeks ago   Exited (2) 2 weeks ago   6379/tcp   airflow-local-redis-1

위의 명령어를 통해 종료된 컨테이너를 확인해볼 수 있습니다.

실제로 많이 사용될 수 있는 알아두면 유용한 옵션입니다.

이 때 종료된 docker 를 제거하기 위해 아래와 같은 명령어를 사용할 수 있습니다.

$ docker container rm 8b36b2e62616

Option

Option	Short	Description
--force	-f	Force the removal of a running container (uses SIGKILL)
--volumes	-v	Remove anonymous volumes associated with the container

$ docker container logs

: 표준 출력 연결하기

현재 실행 중인 특정 도커 컨테이너의 표준 풀력 내용을 확인할 수 있습니다.

단, 컨테이너의 출력 내용 중 표준 출력으로 출력된 내용만 확인할 수 있기 때문에,

파일 등에 출력된 로그는 볼 수 없습니다.

$ docker container logs [OPTIONS] CONTAINER

가령, 컨테이너 리스트에서 postgres 명을 찾아 로그를 실행시키고 싶다면 아래와 같은 명령어를 입력할 수 있습니다.

$ docker container logs -f $(docker container ls --filter "name=postgres" -q)
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

$ docker container exec

: 실행 중인 컨테이너에서 명령 실행

$ docker exec [OPTIONS] CONTAINER COMMAND [ARG...]

예를 들어, 실행 중인 Docker Container의 bash 명령어를 실행하고 싶다면 아래와 같이 접근할 수 있습니다.

$ docker exec -it 8b36b2e62616 /bin/bash
root@8b36b2e62616:/#

Options

Option	Short	Description
--detach	-d	Detached mode: run command in the background
--env list	-e	Set environment variables
--interactive	-i	Keep STDIN open even if not attached
--privileged		Give extended privileges to the command
--tty	-t	Allocate a pseudo-TTY
--user	-u	Username or UID (format: <name
--workdir	-w	Working directory inside the container

$ docker container cp

: 파일 복사하기

$ docker container cp [OPTIONS] CONTAINER:SRC_PATH DEST_PATH|-
# or
$ docker cp [OPTIONS] SRC_PATH|- CONTAINER:DEST_PATH

docker comainer cp 명령은 컨테이너끼리 혹은 컨테이너와 호스트 간에 파일을 복사하기 위한 명령입니다.

Dockerfile에 포함된 COPY 인스트럭션은 이미지를 빌드할 때 호스트에서 복사해 올 파일을 정의하기 위한 것이고,

docker container cp 명령은 실행 중인 컨테이너와 파일을 주고받기 위한 명령입니다.

docker container cp 명령은 디버깅 중 컨테이너 안에서 생성된 파일을 호스트로 옮겨 확인할 목적으로 사용하는 경우가 대부분입니다.

또한, 아직 삭제되지 않은 정지 상태의 컨테이너에 대해서도 실행할 수 있습니다.

$ docker container prune

: 컨테이너 및 이미지 제거

docker container prune 명령은 실행 중이 아닌 모든 컨테이너를 삭제하는 명령입니다.

$ docker container prune [OPTIONS]

docker container prune 명령은 도커 운영이나 관리 시 사용할 수 있는 명령어입니다.

도커를 오랜 기간 사용하다 보면 디스크에 저장된 컨테이너와 이미지가 점점 늘어나곤 합니다.

이런 경우에 prune 명령을 사용해 필요 없는 이미지나 컨테이너를 일괄 삭제할 수 있습니다.

정지시킨 대부분의 컨테이너는 그리 쓸모가 없기 때문에,

정기적으로 이들을 삭제하는 것이 좋습니다.

$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:
74a18a7eda29cbd62876ec2ad2cca73069a1f3647df67ba07cb47e840fb221b1
3174c544e7d7a95113139e4a7f04eef42739414806d092aa7e99dd959a450e9a
9afc781f43879b0566319090c06d5b54e0ce69cb8edcf2d1b5adf4fc78650823
5435e63da04d83db9cfc170623e63ba11e7e74c58e3061f0ba092f1797399a98
43221ba1280d9ebdae7fd541b637e6af8bb75188213058b7d0e091bd6048d87e

Total reclaimed space: 87.75MB

$ docker container stats

: 사용 현황 확인하기

docker container stats 명령은 시스템 리소스 사용 현황을 컨테이너 단위로 확인할 수 있습니다.

유닉스 계열 운영 체제의 top 명령과 같은 역할을 한다고 볼 수 있습니다.

$ docker container stats
CONTAINER ID   NAME                       CPU %     MEM USAGE / LIMIT     MEM %     NET I/O       BLOCK I/O        PIDS
8b36b2e62616   airflow-local-postgres-1   0.35%     40.99MiB / 7.667GiB   0.52%     5.8kB / 0B    37.6MB / 305MB   7
ca1d9ab8f694   airflow-local-redis-1      0.29%     8.359MiB / 7.667GiB   0.11%     5.87kB / 0B   14.8MB / 0B      6

JDK 17 ~ 21 Release, 제대로 이해하기

gngsn — Tue, 10 Oct 2023 00:00:12 +0900

본 포스팅은 openJDK 17 부터 21 까지의 변경 사항을 확인하고, JDK 21을 사용할 때 개발자로서 알아두면 좋을 내용을 학습합니다.

Previous Series:

JDK 11 ~ 17 Release, 제대로 이해하기

JDK 17 ~ 21 Release, 제대로 이해하기 (current)

지난 9월 19일 (2023년), Open JDK LTS인 JDK 21 가 프로덕션에 적용 목적의 General Availability로 릴리즈되었습니다.

General Availability: Final release, ready for production use

JDK 21에서는 아래 15개의 새로운 기능들을 발표했는데요.

크게 네 개의 카테고리로 분류해보면 아래와 같습니다.

Core Java Library

JEP 431: Sequenced Collections

JEP 442: Foreign Function & Memory API (Third Preview)

JEP 444: Virtual Threads

JEP 446: Scoped Values (Preview)

JEP 448: Vector API (Sixth Incubator)

JEP 453: Structured Concurrency (Preview)

Java Language Specification:

JEP 430: String Templates (Preview)

JEP 440: Record Patterns

JEP 441: Pattern Matching for switch

JEP 443: Unnamed Patterns and Variables (Preview)

JEP 445: Unnamed Classes and Instance Main Methods (Preview)

HotSpot:

JEP 439: Generational ZGC

JEP 449: Deprecate the Windows 32-bit x86 Port for Removal

JEP 451: Prepare to Disallow the Dynamic Loading of Agents

Security Library:

JEP 452: Key Encapsulation Mechanism API

이 중, 본 포스팅에서는 아래 내용과 함께, 두 가지의 수정된 버그 사항을 확인합니다.

- Sequenced Collections

- Virtual Threads

- Record Patterns

- Type Pattern

- Record Patterns

- Pattern Matching for Switch

- ZGC

Sequenced Collections

JEP 431: Sequenced Collections

JDK 21 버전에서 SequencedCollection Interface가 새로 정의되었습니다.

Sequence 가 요소들을 특정한 순서로 배열한다는 의미를 갖고 있으며,

Sequenced Collection는 서로 연쇄된 요소들을 갖는 Collection 을 의미합니다.

✔️ History

Sequenced Collection가 등장한 이유는 Open JDK의 공식 문서에 있는 Issue 8280836 를 살펴보면,

결론적으로, 특정 순서를 갖는 collection을 나타내는 정해진 형식이 없다는 것입니다.

일련의 순서를 갖는다는 동일한 특성을 갖는 collection 임에도 불구하고

이를 사용하는 연산들은 아래 표와 같이 제각각이라 일정 형식이 반복되기도, 많은 불만을 일으키기도 했습니다.

	First element	Last element
List	list.get(0)	list.get(list.size() - 1)
Deque	deque.getFirst()	deque.getLast()
SortedSet	sortedSet.first()	sortedSet.last()
LinkedHashSet	linkedHashSet.iterator().next()	// missing

실제로, List와 Deque는 둘 다 특정된 순서를 갖지만 일반화된 supertype 없이 Collection을 super type으로 갖습니다.

Set은 이런 순서를 특정짓지 않는데 동일하게 Collection을 확장합니다.

그 하위의 HashSet 또한 순서가 필요없죠.

하지만, SortedSet이나 LinkedHashSet 은 순서가 필요합니다.

이제, 특정 순서를 가진 특별한 Collection 만을 위한 API가 필요하다는 것을 이해할 수 있습니다.

그렇다고 해서, 기존의 Collection이나 List를 변경하고자 하니,

Collecion은 너무 범용적이고 List는 너무 구체화된 클래스입니다.

이런 이유로, Sequenced Collection 가 등장하게 됩니다.

https://openjdk.org/jeps/431

위와 같이 SequencedCollection와 SequencedSet, SequencedMap을 Interface로 추가하여 개조된 구조를 확인할 수 있습니다.

✔️ Sequenced Collection?

Sequenced Collection 는 아래와 같은 API를 가지는 Interface입니다.

Sequenced Collection 는 첫 번째와 마지막 요소를 통해 접근하며,

Collection 연산을 사용할 때 처음뿐만 아니라 끝에서도 처리를 진행할 수 있습니다.

즉, 처음부터 끝의 순서로 차례대로 처리하거나 forward, 반대 순서 reverse 로 처리할 수 있습니다.

중간 요소들은 바로 이 전의 요소 predecessors 와 바로 다음 요소 successors 를 가리키고 있습니다.

실제, 아래와 같은 방식으로 첫 번째, 마지막 요소에 접근합니다.

새로운 reversed() 메소드는 원래 순서였던 collection을 반대 순서로 보이도록 합니다.

시간이 된다면, 한 번 코드를 살펴 보는 것도 좋을 것 같은데요.

List interface에 default method 로 구현된 reversed() 메소드를 확인해보면 ReverseOrderListView를 생성하는 것을 확인할 수 있습니다.

ReverseOrderListView.of()의 두 번째 인자는 새로 생성할 리스트의 변경 가능 여부를 나타내는데,

기본이 true (modifiable=true) 임을 알 수 있습니다.

public interface List<E> extends SequencedCollection<E> {
	// ...
    
    default List<E> reversed() {
        return ReverseOrderListView.of(this, true); // we must assume it's modifiable
    }
}

✔️ Caution

기존의 시스템을 JDK 21로 업데이트할 때 주의해서 살펴볼 점이 있습니다.

만약, JDK 21 이전에 List를 확장한 클래스에 getFirst() 라는 이름의 메소드를 정의해서 사용하고 있을 경우,

JDK 21에서는 overload method가 되어 컴파일 오류가 발생합니다.

public class StringList extends AbstractList<String> implements List<String> {
    /* [...] */

    // ✅ up to Java 20: compiles successfully
    // ❌ since Java 21: error
	public Optional<String> getFirst() {
		return size() == 0 ? Optional.empty() : Optional.of(get(0));
	}
}

실제로 위의 StringList 를 JDK 17 과 JDK 21을 사용해서 compile 하려고 시도하면,

아래와 같이 JDK 21에서만 오류가 발생하게 됩니다.

Virtual Threads

JEP 444: Virtual Threads

Virtual Thread가 많은 주목 속에 JDK 21에서 정식 적용 되었습니다.

JDK 19 - JEP 425: Virtual Threads (Preview)

JDK 20 - JEP 436: Virtual Threads (Second Preview)

Mutli-thread 기반인 Java는 여러 실행이 한 번에 일어나기 때문에,

Thread는 Java의 동시성 단위로 볼 수 있으며, 다른 스레드와 거의 독립적으로 동시에 실행됩니다.

Virtual Thread는 매번 실행되는 바로 이 Thread를 경량화하여 처리량을 높이기 위한 기술입니다.

✔️ Problems: Platform Thread

JDK는 기본적으로 Plarform Thread 라고도 불리는 Java Thread 와 OS Thread 가 일대일 관계로 동작합니다.

https://medium.com/@RamLakshmanan/java-virtual-threads-easy-introduction-44d96b8270f8

이 말은 Thread 가 IO 연산이 완료될 때까지 대기할 때까지,

Thread의 근간이 되는 OS Thread는 사용되지 않는 상태인 Block 상태로 대기한다는 의미입니다.

이를 이해하기 위해, 일반적인 Java Thread가 어떻게 동작하는지 먼저 살펴보겠습니다.

#1. Thread가 Thread Pool 에 생성
#2. Thread가 새로운 요청을 위해 Pool에서 대기
#3. 새 요청이 오면 스레드는 요청을 수신하고, 이 요청을 처리하기 위한 데이터베이스를 호출
#4. Thread가 데이터베이스로 부터 응답이 오기까지 대기
#5. 데이터베이스로 부터 응답이 오면 해당 Thread가 이를 처리하고, 사용자에게 응답을 반환
#6. Thread는 Thread Pool로 반환

Application이 종료되기 전까지 1 단계부터 6 단계가 반복됩니다.

위의 처리 과정을 살펴보면, 사실상 Thread가 실행되는 구간은 3 번째와 5번째가 전부입니다.

나머지는 모두 대기하는 단계죠.

OS Thread 의 사용 가능 여부에 의존해서 Application이 한계를 갖기 때문에,

Java 생태계의 확장성의 측면에서 큰 문제가 되어왔습니다.

#1. Async Programming

Thread 가 Block 되는 동안 비효율적으로 사용되는 자원 문제를 해결하기 위해,

비동기 Asynchronous 사용을 위해 Future를 사용하는 등의 시도를 해왔습니다.

비동기 프로그래밍이 Thread 문제를 극복하기 위한 방식이 될 수 있겠지만,

비동기 프로그래밍을 작성하는 과정이 상당히 복잡하고 어렵습니다.

또 하나의 큰 문제는 디버깅이 어렵다는 것입니다.

들어오는 요청이 여러 스레드에 의해 처리될 수 있기 때문에

Debugging, Logging, Stack Trace의 분석 등에 어려움을 겪곤 합니다.

#2. Expensive Creation of Threads

Java Thread는 새로 생성과 유지 비용이 비쌉니다.

Thread 메모리를 할당하고, Thread 스택을 초기화한 후, OS Thread를 등록하기 위해 OS 호출을 하는 등

많은 무거운 작업이 필요하기 때문에 비용이 많이 듭니다.

때문에 Thread가 필요할 때마다 스레드를 새로 만들기보다는, Thread를 미리 생성하고 Thread Pool에 저장합니다.

하지만 OS Thread가 제한적이고 Java Thread를 만들 때의 비용을 고려해야 해서

애플리케이션을 안전하게 실행하려면 제한된 스레드 풀이 필요합니다.

#3. Expensive Context Switching

마지막으로, OS Thread 레벨의 Context Switching으로, 많은 CPU 사이클을 수반하여 큰 비용이 듭니다.
Context Switching 발생 시, OS Thread가 하나의 Java Thread에서 다른 Java Thread로 전환하려면,

OS는 로컬 데이터와 메모리 포인터를 현재 Thread에 저장하고, 새로운 Java Thread에 대한 포인터를 로드해야 합니다.

이를 위해서는 OS가 Thread를 일시 중지하고, 스택을 저장하고, 새로운 Thread를 할당하는 일을 처리하는데,

Thread 스택을 로드하고 언로딩해야 하기 때문에 비용이 많이 듭니다.

이러한 문제를 해결하기 위해, Project Loom과 Virtual Thread 이 등장했습니다.

✔️ Virtual Threads

자바의 Virtual Thread는 Virtual Memory와 유사해서 그 이름을 가져왔습니다.

Virtual Thread가 가상 메모리가 동작하는 방식과 유사하게,

거의 무한의 스레드를 사용할 수 있다는 착각illusion을 하도록 의도하기 때문입니다.

가상 스레드는 시스템에 최소한의 오버헤드를 가하기 때문에 한 애플리케이션에 수천 개의 스레드를 가질 수 있습니다.
모든 가상 스레드는 작업을 수행하기 위해 OS thread가 필요하지만,

리소스를 위한 대기 상태동안 Java thread 처럼 OS thread를 붙잡고 있지는 않습니다.

https://medium.com/@RamLakshmanan/java-virtual-threads-easy-introduction-44d96b8270f8

가상 스레드가 I/O를 위해 대기할 수 있는데,

이 때, 사용중이던 Java thread는 풀어줘서 다른 Virtual Thread가 사용하여 다른 일을 할 수 있게 합니다.

또, I/O 작업이 완료되면 이전 작업을 이어서 처리합니다.

Cheap Context Switching

자바에서 Context Switching은 스레드 스택이 발생할 때마다 저장하고 로드해야 하기 때문에 비용이 매우 많이 들었었는데요.

Virtual Thread는 JVM의 통제 하에 있기 때문에 Thread stack은 Stack에 저장되지 않고 힙 메모리에 저장됩니다.

활성 중인 Virtual Thread에 Thread stck을 할당하는 것이 훨씬 저렴해진다는 것을 의미합니다.

Virtual Thread의 데이터 스택을 캐리어에 할당할 때 "carrier" Thread stack에 로드하는 과정을 마운팅 mounting 이라고 하며,

내리는 과정을 언마운팅 unmounting 이라고 합니다.

✔️ Motivation

Virtual thread를 사용하기 위해 새로운 개념을 따로 학습할 필요는 없습니다.

다만, 기존에 사용하던 고비용 Java Thread를 효율적으로 사용하려고 작성하던 코드 습관들을 버릴 필요는 있습니다.

Virtual Thread 의 개발 방향성을 이해하는 것도 참고로 알아두시면 좋을 텐데요.

JEP 444의 Motivation 섹션을 간략히 요약해본 내용입니다.

✔️ 자원을 효율적으로 관리하면서, 확장 가능한 Thread-per-Request 스타일로 작성합니다.

✔️ java.lang.thread API 수정을 최소화하면서 가상 스레드 사용할 수 있게 합니다.

✔️ 기존 JDK 툴을 사용하여 가상 스레드의 troubleshooting, debugging, profiling 지원합니다.

The thread-per-request style

각 사용자마다의 요청을 처리하기 위해, 각 요청을 처리하기 위한 전용 스레드를 할당하는 방식입니다.

이를 통해, 코딩 작업 뿐만 아니라 디버깅, 프로파일링이 용이하게 하며 이해하기 쉽게 만듭니다.

Requesting-handling code

하나의 요청의 시작과 끝은 하나의 thread가 처리하는 대신,

다른 I/O 연산을 기다릴 때마다 Java Thread를 Pool에 반환해서 다른 요청을 처리합니다.

Preserving the thread-per-request style with virtual threads

가상 스레드는 OS 스레드와 일대일 대응되지 않으며, 자바 런타임에서 구현되도록 합니다.

애플리케이션 코드는 가상 스레드에서 실행되며, CPU 연산 중일 시에만 OS thread를 소비합니다.

Implications of virtual threads

Virtual thread는 저비용으로 생성되기 때문에 pool로 저장해놓고 관리하지 않습니다.

대부분 짧은 수명과 얕은 호출 스택을 갖고 있으며,

주로 하나의 HTTP 요청이나 JDBC 쿼리와 같은 작업 수행합니다.

✔️ How to Use

Virtual Thread 는 Thread를 많이 만들어 로직을 처리하는 동작에서 큰 효과를 볼 수 있습니다.

사용법은 간단히 아래와 같이 사용할 수 있습니다.

기존의 Java Thread 와 시간 차이를 위한 테스트를 진행해보았습니다.

좌) Java Thread (Platform Thread): 100,382 ms, 우) Virtual Thread: 1,024 ms

실제 실행에서도 100,382 ms / 1,024 ms 의 차이를 확인할 수 있었습니다.

Record Patterns

JEP 440: Record Patterns

JDK 16의 JEP 394: Pattern Matching for instanceof 에서는

"JDK 11 ~ 17 Release, 제대로 이해하기" 참고

instanceof 연산자가 타입을 비교해서 ﹣ type pattern,

특정 객체의 내부 값을 매칭시켜 바로 가져오는 ﹣pattern matching 기능을 수행했습니다.

✔️ Type Pattern

위의 예제에서 obj 변수를 String이라는 '타입'으로 비교해서 s 변수로 할당하는데요.

이렇게 특정 대상을 타입으로 비교해서 할당하는 패턴을 Type Pattern 이라고 합니다.

fyi. dev.java: pattern-matching

이러한 Type Pattern은, 빈번하게 발생하는 캐스팅을 제거해서 많은 코드를 간결하게 줄여 줍니다.

TIP. String Type은 CharSequence Type을 확장하기 때문에 CharSequence 으로도 할당 받을 수 있습니다.

Type Pattern 을 Record 타입에도 활용할 수 있도록,

JDK 21 에서는 Records Patterns를 제공합니다.

✔️ Record Patterns

Records(JEP 395)는 데이터 처리를 위한 목적의 데이터 운반을 역할을 하는 데이터 클래스입니다.

Record 클래스의 인스턴스는 getter와 같은 접근 제어 컴포넌트만을 통해 데이터를 제공합니다.

Type Pattern을 사용하여 값이 Record 클래스의 인스턴스인지 확인하고,

맞다면, 해당 Record 의 내부 필드 값을 추출할 수 있습니다.

obj가 Point record 타입이라면, obj record의 컴포넌트를 x 와 y 값으로 추출해서 할당하라는 의미입니다.

JDK 16인 왼쪽 코드와 동일한 의미가 되죠.

Record 인스턴스가 중첩되어 있어도 Type Pattern을 모두 적용할 수 있습니다.

Pattern Matching for Switch

JEP 441: Pattern Matching for switch

위의 Record Pattern과 함께 진행되었으며, Pattern Matching을 Switch 문에서 사용할 수 있도록 지원합니다.

✔️ Overview

Pattern Matching은 가장 처음 JEP 406 (JDK 17) 을 시작으로 JEP 420 (JDK 18), 427 (JDK 19), and 433 (JDK 20)를 거쳐

위에서 본 Record Patterns 와 함께 점점 다듬어져 왔습니다.

instanceof 사용 시 if ... else 문의 Pattern Matching으로 간편하게 사용하고 코드를 줄일 수 있습니다.

하지만 아래 코드와 같이 체인처럼 많은 비교를 하게 될 수도 있습니다.

위 코드의 목적은 formatted 변수에 해당 타입을 넣는 시도를 하지만,

어떤 타입도 매칭되지 않으면 할당되지 않게 됩니다.

또, 큰 문제는 실제로 변수에 문자열을 할당하는 시간 복잡도는 O(1) 임에도 불구하고,

타입 수가 n 개 일 때 O(n) 시간 복잡도를 갖게 합니다.

이런 불만은 switch 를 이용한 pattern matching이 가장 적합하게 해결해줄 수 있습니다.

Switch 문을 이용해 간단하게 expression 을 확장하고 Pattern Matching을 이용해서 값을 할당해 사용할 수 있습니다.

✔️ Switches and null

이전까지는, switch 문에 입력한 변수 expression 가 null 이라면, NullPointerException을 던졌는데요.

JDK 21 이후부터는 null label을 추가하여 스위치에 결합하여 사용할 수 있습니다.

좌) JDK 21 이전, 우) JDK 21 이후

✔️ Case refinement

Switch label 을 Pattern case 로 구분하다 보면, 아래 좌측 코드와 같이 실행 블록에 더 많은 조건문을 요구할 때가 생깁니다.

이는 사실상 아쉬운 확장성을 가지고 하나의 조건을 분기처리하는 것과 동일합니다.

좌) case label 내 조건문 처리, 우) case / when 구문 분기 처리

이 때, 아래 우측 코드와 같이 when 구문을 사용할 수 있습니다.

when 구문을 사용해서 명확하고 확장가능한 구문을 작성할 수 있습니다.

또한 Switch Pattern을 사용하면 모든 경우를 남김없이 처리하도록 Exhaustive 컴파일이 검증한다는 장점이 있습니다.

CardClassification 이 sealed 가 아닌 interface CardClassification {} 라면 다음과 같은 컴파일 오류가 발생합니다.

error: the switch statement does not cover all possible input values

항상 break 문을 추가해야하거나 아쉬움이 있던 비교 구문들을 개선하면서

switch 문이 점차 개선되고 있다는 것을 알 수 있었습니다.

ZGC

JEP 439: Generational ZGC

JVM은 Serial GC, Parallel GC, CMS GC, G1 GC 등 다양한 Garbage Collector를 연구하고 개발해왔습니다.

Garbage Collector에 대한 자세한 내용은 "Garbage Collector, 제대로 이해하기" 를 참고하실 수 있습니다.

ZGC(Z Garbage Collector)는 이 흐름에 이어 새롭게 등장한 Java의 garbage collector입니다.

가장 최근까지 사용되던 G1 GC는 메모리를 region이라는 논리적인 단위로 구분했습니다.

https://hub.packtpub.com/getting-started-with-z-garbage-collectorzgc-in-java-11-tutorial/

이 번에 기본 Garbage Collector로 채택된 ZGC는 메모리를 ZPage라는 논리적인 단위로 구분합니다.

OpenJDK의 ZPage 구조는 Github 링크를 통해 확인할 수 있습니다.

ZGC는 다룰 내용이 많기 때문에 해당 포스팅에서 자세한 내용은 생략하겠습니다.

다만, Naver D2에서 정리한 내용이 상세하여, 한 번 읽어보길 추천드립니다.

Bug Fixed

이번엔, JDK 21까지 수정된 버그들을 살펴보도록 하겠습니다.

✔️ Double.toString()

bugs.openjdk: JDK-8291475

Double.toString(double) 은 최대한 작은 자릿수를 포함하는 실수를 문자열로 변환하도록 설계되었습니다.

하지만, 실제로 그렇지 않은 상황들이 있었습니다.

가령, 1e23과 9.999999999999E22가 같은 double인데,

1e23을 Double.toString(double)를 통해 문자열로 변경하려고 하면 "9.9999999999E22"를 반환했습니다.

JDK 19 에서 이를 업데이트 했습니다.

그 결과, JDK 19부터 생성된 문자열 중 일부가 이전보다 짧아졌습니다.

가령, 이전 JDK 릴리즈에서 "9.99999999999999E22" 를 반환했다면, JDK 19부터는 "1.0E23"이 반환합니다.

또, JDK 19 이후, Double.toString(double) 메서드에 9.99999999999999E22를 전달하면 동일한 값인 "1.0E23"을 반환합니다.

이밖의 다른 double과 float 의 문자열을 표현하는 형식들 또한, 위의 형식으로 통일되어 변경되었습니다.

✔️ IdentityHashMap

bugs.openjdk: JDK-8178355

github commit diff

IdentityHashMap의 메소드 remove(key, value)와 replace(key, value, newValue)는

"Identity" HashMap임에도 불구하고 value 값을 equals() 로 비교했습니다.

때문에, IdentityHashMap의 Value 값을 비교를 통한 remove(..) / replace(..) 메소드를 실행하면,

해당 String를 문자열 값(compared by identity) 이 아닌,

객체의 주소 값(compared by equality)으로 비교해서 원하는 동작을 하지 않았습니다.

JDK 20에서 부터는 이를 "Identity" 기반 비교로 수정하여 의도된 동작하도록 수정되었습니다.

FYI. Identity vs Equality

Identity
For example:
Integer a = new Integer(1);
Integer b = a;
a 는 b 와 일치 identity
Java 에서는, identity 를 == 기호로 비교합니다. (ex. a == b )

Equality
Integer c = new Integer(1);
Integer d = new Integer(1);
c 는 d 와 동등 equality 하지만 일치 identity 하지는 않음
Java 에서는, equality 를 equals() 로 비교합니다. (ex. a.equals(b) )

그럼 지금까지 JDK 21까지의 릴리즈 노트를 확인해보았습니다.

| Reference |

https://openjdk.org/projects/jdk/21/

https://wiki.openjdk.org/display/zgc/Main#Main-JDK21

https://www.youtube.com/watch?v=5jIkRqBuSBs

https://www.infoq.com/news/2023/09/java-21-so-far/

https://theboreddev.com/understanding-java-virtual-threads/

https://medium.com/@RamLakshmanan/java-virtual-threads-easy-introduction-44d96b8270f8

Apache Airflow, 어렵지 않게 시작하기

gngsn — Wed, 4 Oct 2023 00:11:58 +0900

Airflow의 간단한 Demo를 제작하며 Airflow에 익숙해지는 것이 본 포스팅의 목표입니다.

안녕하세요.

이번에는 짧게 Airflow 시리즈를 작성해보려고 합니다.

본 포스팅은 Airflow에 대한 가장 기본이 되는 개념을 다룹니다.

pip3 + venv

venv 를 통해 가상 환경을 만들어 격리된 환경에서의 세팅을 설정해보겠습니다.

Python은 프로젝트 별로 독립된 개발 환경을 구성하도록 가상 환경 (virtual environment) 기능을 제공합니다.

이를 통해 프로젝트 간 의존성 충돌 문제를 효과적으로 예방할 수 있습니다.

Airflow를 이러한 독립 환경에 설정해서 기존의 환경에 호환되지 않아 생기는 부수적인 문제 없이 설치해보도록 하겠습니다.

FYI. virtualenv

Python 2에서는 virtualenv 라는 외부 패키지를 통해 가상 환경을 제작했지만,

Python 3 부터는 venv 모듈이 Python에 기본 내장되어 별도 외부 패키지 설치없이 사용할 수 있습니다.

Evironment

✔️ python: 3.9.6
✔️ pip : 23.2.1

#1. Setting venv

먼저, Python 가상환경을 생성합니다.

1.1. venv 생성

가상 환경을 생성합니다.

$ python -m venv {{venv_name}}

# example.
$ python -m venv .myvenv

관례에 따라 python -m venv .venv 로 설정하셔도 됩니다.

1.2. 가상 환경 활성화: Activate venv

가상 환경을 생성했다면, 이번엔 가상 환경을 활성화 시킵니다.

N개의 가상 환경이 있을 때, 사용할 가상 환경을 선택해서 해당 환경만을 활성화 시켜야겠죠.

$ source {{your_venv}}/bin/activate

# example.
$ source .myvenv/bin/activate

1.3. 가상 환경 활성 여부 확인

가상 환경의 파이썬을 사용하는지 which 명령어로 확인해보겠습니다.

현재 제작한 프로젝트 하위에 잘 생성된 것을 확인할 수 있습니다.

$ pwd
/Users/gyeongsun/git/gngsn-airflow-lab

$ which python3
/Users/gyeongsun/git/gngsn-airflow-lab/.myvenv/bin/python3

활성 전의 명령과 비교해보실 수 있습니다.

$ which python3
/usr/bin/python3

FYI.

해당 환경을 비활성을 시키고 싶다면 아래 명령어를 입력하세요.

$ deactivate {{your_env}}

# example.
$ deactivate .myvenv

#2. Install Airfow

Official link

2.1. Airflow Home 설정

환경 변수를 통해 Airflow Home 위치를 설정합니다.

$ export AIRFLOW_HOME=~/airflow

2.2. Airflow 설치

Airflow를 설치하기 전에, 어떤 Airflow 버전과 Dependencies를 설치할 지 알아보도록 하겠습니다.

# Latest version as of 2023-10-03
# Ariflow 버전 입력 
AIRFLOW_VERSION=2.7.1

# 설치된 Python 버전. 현재 Python 3.11 은 지원 안됨.
PYTHON_VERSION="$(python3 --version | cut -d " " -f 2 | cut -d "." -f 1-2)"

# 설치 URL 입력
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"

위의 모든 환경 변수가 잘 설정되었는지 확인해보세요.

그럼 이제, Airflow를 설치할 수 있습니다.

$ pip3 install "apache-airflow==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"

일반적인 방식의 Python 모듈 설치에 비해 조금 번거로운 과정을 거쳐야 하는데요.

Airflow는 library인 동시에 application이기 때문에,

설치 과정에서 버전 호환이나 호환되지 않는 Dependencies 문제가 발생할 수 있습니다.

그래서 Airflow 팀은 버전을 명시하게 하도록 setup.cfg 나 setup.py 를 통해서도 사용자들이 버전을 지정할 수 있게 제작했습니다.

#3. Verify installed Airflow

먼저, 모든 Dependencies에 문제가 없는지 확인합니다.

$ pip3 check
No broken requirements found.

이후, Airflow가 정상적으로 설치되었는지 확인합니다.

$ python3 -m airflow
Usage: airflow [-h] GROUP_OR_COMMAND ...

Positional Arguments:
  GROUP_OR_COMMAND 
...

#4. Initializing database

이번에는 Airflow의 초기 설정을 진행합니다.

아래 명령을 톡해 Metastore와 DB 등을 초기 생성하도록 하겠습니다.

$ airflow db init

이후, AIRFLOW_HOME 변수 명으로 아래와 같은 airflow 폴더 아래의 파일들을 확인할 수 있습니다.

$ cd $AIRFLOW_HOME
$ pwd
/Users/gyeongsun/airflow   # "~/airflow"과 동일

airflow.cfg : airflow 설정 파일
airflow.db : SQLite DB 파일
/logs : Log directory

FYI.

개인적으로, Airflow에서 제공하는 기본 예제들을 포함하지 않고 실행하고 싶기 때문에 Example 로드 설정을 off로 설정하겠습니다.

# ~/airflow/airflow.cfg

 100 # Whether to load the DAG examples that ship with Airflow. It's good to
 101 # get started, but you probably want to set this to ``False`` in a production
 102 # environment
 103 # 
 104 # Variable: AIRFLOW__CORE__LOAD_EXAMPLES
 105 #
 106 load_examples = False

#5. Create User

airflow에 접근할 사용자를 생성합니다.

$ airflow users create \
    --username admin \
    --firstname gngsn \
    --lastname park \
    --role Admin \
    --email gngsn@example.com

Password: <<your_password>>
Repeat for confirmation: <<your_password>>

# [Log] User "admin" created with role "Admin"

#6. Run Airlfow webserver

이번엔 ariflorw가 제공하는 webserver를 실행시킵니다.

$ airflow webserver --port 9090

그리고, username과 입력한 password를 사용해서 airlfow webserver에 로그인합니다.

위와 같은 Airflow Webserver 페이지를 확인할 수 있습니다.

Troubleshooting

만약, 아래와 같이 airflow 명령어 실행이 실패했다면,

bash: airflow: command not found"

Airflow 명령을 실행시켜주기 위해 airflow 명령 파일의 위치를 PATH 시스템 환경 변수에 추가해줍니다.

PATH=$PATH:~/.local/bin

Docker

이번에는 Docker를 통해 Airflow를 실행하는 방식을 다뤄보겠습니다.

#1. Fetch docker-compose file

가장 먼저, docker-compose 파일을 가져오겠습니다.

기호에 따라, Airflow를 관리하기 위한 폴더 (airflow-local) 를 생성합니다.

# optional
~$ mkdir airflow-local
~$ cd airflow-local

Airflow docker production을 curl 명령어를 통해 다운받습니다.

~/airflow-local$ curl -LfO 'https://airflow.apache.org/docs/apache-airflow/2.7.1/docker-compose.yaml'

docker-compose.yaml 에는 아래와 같은 서비스들이 정의됩니다.

✔️ airflow-scheduler

Scheduler는 모든 Task와 DAG를 모니터링하고, Task이 실행될 수 있는 상태일 때 (이전 의존성이 실행 완료되었을 때) 해당 Task를 실행합니다.

✔️ airflow-webserver

Airflow의 웹 서버는 기본적으로 http://localhost:8080 을 통해 접근할 수 있습니다.

✔️ airflow-worker

Worker들은 스케줄러에 의해 전달 받은 Task를 실행합니다.

✔️ airflow-triggerer

Triggerer는 지연 가능한 작업 deferrable tasks 에 대해 이벤트 루프를 실행합니다.

✔️ airflow-init

Airflow 사용을 위해 서비스의 초기 설정을 진행합니다.

✔️ postgres

Airflow가 사용하는 database 입니다.

✔️ redis

Redis는 Scheduler에서 Worker로 메세지를 전송하는 브로커의 역할로 실행됩니다.

#2. Initializing Environment

2.1. Airflow가 사용할 폴더 생성

# docker-compose.yaml과 동일한 위치에 생성
~/airflow-local$ mkdir -p ./dags ./logs ./plugins ./config

./dags : DAG 파일 보관
./logs : Task 실행 시, 혹은 Scheduler의 로그 보관
./config : 커스텀 log parser를 추가하거나 Cluster 정책을 위한 airflow_local_settings.py를 추가할 수 있음
./plugins : 커스텀 Plugin 보관

2.2 .env 파일 생성

.env 파일을 통해 Docker 내의 Airflow UID를 설정해줍니다.

~/airflow-local$ echo -e "AIRFLOW_UID=$(id -u)" > .env

확인해보면 아래와 같은 .env 파일의 내용을 확인할 수 있습니다.

~/airflow-local$ cat .env
AIRFLOW_UID=501

Airflow의 docker-compose.yaml의 주석을 참고해서 .env 에 설정 값을 추가할 수 있습니다.

# This configuration supports basic configuration using environment variables or an .env file
# The following variables are supported:
#
# AIRFLOW_IMAGE_NAME - Docker image name used to run Airflow.
# Default: apache/airflow:2.7.1
# AIRFLOW_UID - User ID in Airflow containers
# Default: 50000
# AIRFLOW_PROJ_DIR - Base path to which all the files will be volumed.
# Default: .
# Those configurations are useful mostly in case of standalone testing/running Airflow in test/try-out mode
#
# _AIRFLOW_WWW_USER_USERNAME - Username for the administrator account (if requested).
# Default: airflow
# _AIRFLOW_WWW_USER_PASSWORD - Password for the administrator account (if requested).
# Default: airflow
# _PIP_ADDITIONAL_REQUIREMENTS - Additional PIP requirements to add when starting all containers.
# Use this option ONLY for quick checks. Installing requirements at container
# startup is done EVERY TIME the service is started.
# A better way is to build a custom image or extend the official image
# as described in https://airflow.apache.org/docs/docker-stack/build.html.
# Default: ''

(Optional) docker-compose customizing

실행하기 전에, 몇가지 설정을 변경합니다.

현재 다른 프로젝트를 8080 포트로 사용하고 있기 때문에, docker 외부에서 접근할 port 번호를 9090 으로 설정하겠습니다.

ports: - "9090:8080"

Airflow는 기본적으로, 처음 실행 시 꽤 많은 양의 예시를 제공합니다.

Airflow의 예제를 확인하고 싶지 않다면 아래 옵션을 'true' → 'false' 로 설정합니다.

AIRFLOW__CORE__LOAD_EXAMPLES: 'false'

#3. Running Containers

database migration 과 첫 사용자 계정을 설정하기 위해 아래 명령어를 실행하세요.

~/airflow-local$ docker compose up airflow-init

가령, docker compose 파일을 통해 airflow를 실행시키면 아래와 같은 Container들이 실행됩니다.

~/airflow-local$ docker compose up
[+] Running 7/7
 ✔ Container gngsn-airflow-lab-redis-1              Running                                                                                         0.0s 
 ✔ Container gngsn-airflow-lab-postgres-1           Running                                                                                         0.0s 
 ✔ Container gngsn-airflow-lab-airflow-init-1       Created                                                                                         0.0s 
 ✔ Container gngsn-airflow-lab-airflow-triggerer-1  Created                                                                                         0.1s 
 ✔ Container gngsn-airflow-lab-airflow-worker-1     Created                                                                                         0.1s 
 ✔ Container gngsn-airflow-lab-airflow-scheduler-1  Created                                                                                         0.1s 
 ✔ Container gngsn-airflow-lab-airflow-webserver-1  Created                                                                                         0.1s 
Attaching to gngsn-airflow-lab-airflow-init-1, gngsn-airflow-lab-airflow-scheduler-1, gngsn-airflow-lab-airflow-triggerer-1, gngsn-airflow-lab-airflow-webserver-1, gngsn-airflow-lab-airflow-worker-1, gngsn-airflow-lab-postgres-1, gngsn-airflow-lab-redis-1

그럼 아래와 같은 로그를 확인할 수 있는데,

docker-compose 파일에서 설정된 아이디와 비밀번호가 모두 airflow 인 사용자를 생성합니다.

gngsn-airflow-lab-airflow-init-1  | User "airflow" created with role "Admin"

✔️ Login 정보

ID: airflow
Password: airflow

#4. Verify installed Airflow

아래와 같이 airflow-worker를 통해 airflow 명령어를 입력합니다.

$ docker compose run airflow-worker airflow info

혹은, Linux나 Mac OS를 사용하고 있다면, wrapper script를 다운받아 airflow를 조금 더 쉽게 사용할 수 있습니다.

$ curl -LfO 'https://airflow.apache.org/docs/apache-airflow/2.7.1/airflow.sh'
$ chmod +x airflow.sh

위와 같이 airlfow 실행 파일을 설치하고, 해당 파일을 통해 아래와 같이 airflow 명령어를 실행할 수 있습니다.

$ ./airflow.sh info

Running a DAG

이번엔 위에 간단히 정의한 DAG를 실행해보도록 하겠습니다.

먼저, 간단한 DAG 정의를 먼저 알아본 후, 그 중 하나를 통해 실행 해보겠습니다.

Create a DAG

먼저, DAG를 정의하는 방법은 3가지가 있습니다.

첫 번째 방법은 python의 with와 함께 아래와 같이 DAG를 정의하는 방식입니다.

import datetime

from airflow import DAG
from airflow.operators.empty import EmptyOperator

with DAG(
     dag_id="my_dag_name",
     start_date=datetime.datetime(2021, 1, 1),
     schedule="@daily",
): EmptyOperator(task_id="task")

두 번째 방법은 기본 생성자로 생성해서 Operator의 dag 인자로 넘겨주는 것입니다.

 import datetime

 from airflow import DAG
 from airflow.operators.empty import EmptyOperator

 my_dag = DAG(
     dag_id="my_dag_name",
     start_date=datetime.datetime(2021, 1, 1),
     schedule="@daily",
 )
 EmptyOperator(task_id="task", dag=my_dag)

세 번째 방법은 @dag 어노테이션을 사용해 DAG Generator를 활성화할 수 있습니다.

import datetime

from airflow.decorators import dag
from airflow.operators.empty import EmptyOperator

@dag(start_date=datetime.datetime(2021, 1, 1), schedule="@daily")
def generate_dag():
    EmptyOperator(task_id="task")

generate_dag()

Test a DAG

이번에는 해당 DAG를 실행시키도록 하겠습니다.

DAG를 실행하기 위해서는 ~/airflow/dags 하위에 DAG를 정의한 파일을 추가하면 됩니다.

docker 로 실행하고 있다면, 위에서 생성한 /dags 하위에 생성합니다.

# ~/airflow/dags/say-hello.py

from datetime import datetime

from airflow import DAG
from airflow.decorators import task
from airflow.operators.bash import BashOperator

# ① A DAG represents a workflow, a collection of tasks
with DAG(dag_id="demo", start_date=datetime(2023, 10, 1), schedule="0 0 * * *") as dag:

    # ② Tasks are represented as operators
    hello = BashOperator(task_id="hello", bash_command="echo hello")

    @task()
    def airflow():
        print("airflow")

    # ③ Set dependencies between tasks
    hello >> airflow()

위와 같이 정의한 후, 아래의 명령어로 airflow가 활성되었는지를 확인합니다.

✔️ venv

$  airflow dags list
dag_id | filepath     | owner   | paused
=======+==============+=========+=======
demo   | say-hello.py | airflow | None

✔️ docker

$ docker compose run airflow-worker airflow dags list
[+] Creating 3/0
 ✔ Container airflow-local-redis-1         Running                                                                                                                    0.0s 
 ✔ Container airflow-local-postgres-1      Running                                                                                                                    0.0s 
 ✔ Container airflow-local-airflow-init-1  Created                                                                                                                    0.0s 
[+] Running 3/3
 ✔ Container airflow-local-redis-1         Healthy                                                                                                                    0.5s 
 ✔ Container airflow-local-postgres-1      Healthy                                                                                                                    0.5s 
 ✔ Container airflow-local-airflow-init-1  Started                                                                                                                    0.2s 

dag_id | filepath     | owner   | paused
=======+==============+=========+=======
demo   | say-hello.py | airflow | None

이제, 아래 명령어로 DAG를 실행합니다.

✔️ venv

$ airflow dags test "demo"
...
[2023-10-04T00:03:37.223+0900] {subprocess.py:86} INFO - Output:
[2023-10-04T00:03:37.226+0900] {subprocess.py:93} INFO - hello
...

✔️ docker

$ docker compose run airflow-worker airflow dags test "demo"
...
[2023-10-03T15:24:02.488+0000] {subprocess.py:86} INFO - Output:
[2023-10-03T15:24:02.489+0000] {subprocess.py:93} INFO - hello
...

다음에는 airflow 명령어를 확인해보면서, 조금 더 정밀한 스케줄링을 할 수 있도록 만들어보겠습니다.

| Reference |

https://airflow.apache.org/docs/

https://www.altexsoft.com/blog/apache-airflow-pros-cons/

⌜Data Pipelines with Apache Airflow⌟ - Oreilly

https://www.altexsoft.com/blog/apache-airflow-pros-cons/

Apache Airflow, 제대로 이해하기 - Schedule

gngsn — Tue, 3 Oct 2023 02:51:20 +0900

Airflow의 Scheduling을 이해하는 것이 본 포스팅의 목표입니다.

안녕하세요.

이번에는 짧게 Airflow 시리즈를 작성해보려고 합니다.

본 포스팅은 Airflow에 대한 가장 기본이 되는 개념을 다룹니다.

Scheduling

Airflow를 통해 각 DAG에 대한 스케줄 간격을 정의하여 파이프라인이 실행되는 정확한 시간을 결정할 수 있습니다.

Flow가 매 시간, 매일, 매주 등으로 DAG를 실행하도록 지시하거나,

Cron 같은 식을 사용해서 복잡한 스케줄 간격을 사용할 수 있습니다.

Airflow DAG를 개발하고 실행하기까지의 전반적인 프로세스를 살펴보면서,

Airflow가 DAG를 어떻게 실행하는지 알아보겠습니다.

Components

Airflow는 크게 세 가지로 구성되어 있습니다.

Data Pipelines with Apache Airflow

✔️ Scheduler

DAG를 파싱하고 스케줄 간격을 확인한 후, 만약 DAG의 스케줄이 지난 경우 Airflow workers 에게 전달하여 DAG의 작업을 실행하도록 스케줄링하기 시작합니다.

✔️ Workers

실행 예정인 작업을 가져와 실행합니다. workers는 사실상 "작업을 수행"할 책임을 가집니다.

✔️ Webserver

스케줄러에서 파싱한 DAG를 시각화하고, 사용자가 DAG 실행 및 결과를 모니터링할 수 있는 기본 UI를 제공합니다.

How to work

Airflow의 핵심은 파이프라인이 언제 어떻게 실행되는지를 결정하는 정확한 스케줄링입니다.

스케줄러는 크게 아래와 같은 단계를 거칩니다.

Data Pipelines with Apache Airflow

1. 사용자가 워크플로우를 DAG로 작성합니다.

2-1. Airflow Scheduler가 DAG 파일들을 읽어 각 DAG의 Task, 종속성, 스케줄 간격을 추출합니다.

2-2. Airflow Scheduler는 DAG가 마지막으로 읽힌 시점과 비교하여 스케줄을 실행할 시점인지 아닌지를 확인합니다. 만약 스케줄을 실행할 시점이라면, DAG 내의 작업이 실행을 위해 스케줄링됩니다.

2-3. 이후 스케줄러는 각각의 스케줄링된 작업에 대해 작업의 종속성(Upstream Tasks)이 완료되었는지 여부를 확인합니다. 만약 완료되었다면, 해당 Task를 실행 큐에 추가합니다.

4. 스케줄러는 잠시 대기 후, 첫 번째로 단계로 돌아가 새로운 루프를 시작합니다.

일단 실행을 위해 큐에 추가된 Task들은, 병렬적인 실행과 결과 추적을 위해 Airflow Workers Pool가 해당 작업을 가져갑니다.

이러한 결과들은 Airflow의 metastore과 통신하여, 사용자는 Airflow가 제공하는 웹 인터페이스를 통해 Task들의 진행을 추적하고 그들의 로그를 볼 수 있습니다.

Airlow Scheduler는 Airlow 운영 환경에서 영구적인(persistent) 서비스로 실행되도록 설계되었습니다.

사용하는 방식은 간단한데, Airlow Scheduler 명령을 실행하기만 하면 됩니다.

이때, airflow scheduler 명령은 Airlow.cfg에 명시된 구성을 사용합니다.

Scheduling intervals

Airflow가 DAG를 실행하기 위해서는, 해당 Task가 언제부터 시작할지를 알아야 합니다.

Airflow는 사용자가 입력한 start_date 값을 참고해 첫 번째 날짜 이후 (start + interval),

첫 스케줄 시간이 될 때 첫 번째 실행을 실행하기 위한 스케줄링합니다.

스케줄링을 위해, DAG 정의 시 입력할 수 있는 DAG의 세 가지 파라미터가 있습니다.

✔️ start_date

: 시작할 시점 설정

✔️ end_date

: 종료할 시점 설정

✔️ schedule_interval

: 스케줄 시간 정의

여기서 세 번째 요소인 schedule_interval를 살펴보겠습니다.

schedule_interval는 스케줄 시간을 정의할 수 있는 설정 값입니다.

schedule_interval를 설정할 수 있는 방법은 총 세 가지로 확인할 수 있는데요.

지금 부터 하나씩 알아보도록 하겠습니다.

1. using Preset

Preset	Meaning
@once	한 번 실행
@hourly	한 시간에 한 번, 한 시각이 시작할 때 실행
@daily	하루에 한번, 자정에 실행
@weekly	일주일에 한 번, 일요일 자정에 실행
@monthly	한 달에 한 번, 그 달의 첫 날 자정에 실행
@yearly	1년에 한번씩 1월 1일 자정에 실행

아래 예시로 조금 더 자세히 알아보겠습니다.

dag = DAG(
    dag_id="02_daily_schedule",
    schedule_interval="@daily",             ❶
    start_date=dt.datetime(2019, 1, 1),     ❷
    ...
)

❶ 매일 자정에 해당 DAG를 실행시키기 위한 스케줄 설정

❷ DAG 스케줄링을 시작할 일시

특정 간격을 주기적으로 DAG를 실행하는 것을 알아보았는데요.

그렇다면, 조금 더 세밀한 조정을 통해 실행하고 싶다면 어떻게 할 수 있을까요?

2. Cron-based intervals

DAG를 실행하고자 할 때, 가령 "매주 토요일 23시 45분" 과 같이 정밀한 시기를 지정하고 싶어질 때가 있습니다.

이렇게 좀 더 복잡한 스케줄링을 위해, cron과 같은 스케줄링을 위한 정규 표현식을 사용할 수 있습니다.

cron은 macOS나 Linux와 같은 유닉스 계열 컴퓨터 운영 체제에서 사용되는 시간 기반 작업 스케줄러입니다.

cron은 다섯 가지 구성 요소로 아래와 같이 정의됩니다.

# ┌─────── minute (0 - 59)
# │ ┌────── hour (0 - 23)
# │ │ ┌───── day of the month (1 - 31)
# │ │ │ ┌───── month (1 - 12)
# │ │ │ │ ┌──── day of the week (0 - 6) (Sunday to Saturday;
# │ │ │ │ │      7 is also Sunday on some systems)
# * * * * *

cron 작업은 시간/날짜 필드가 현재 시스템 시간/날짜와 일치할 때 실행됩니다.

특정 시기를 명시하기 원하지 않는 필드를 정의하기 위해 숫자 대신 별표(*)를 사용할 수 있는데,

해당 필드의 값을 신경 쓰지 않는다는 것을 의미합니다.

cron 표현식이 처음에는 복잡하다고 느껴질 수 있겠지만, 시간 간격을 유연하게 정의할 수 있습니다.

예를 들어, 아래와 같은 cron 식을 표현해서 시간 간격, 일 간격 및 주 간격 등을 정의할 수 있습니다.

0 0 * * * : daily (자정 실행)
0 0 * 0 : 매주 (일요일 자정에 실행)

0 0 1 * * : 매월 1일 자정

45 23 * * MON, SAT : 매주 월요일, 토요일 23:45

0 0 * * MON-FRI : 주중 평일 자정에 실행

3. Frequency-based intervals

"5분에 한 번" 혹은 "3일에 한 번" 등과 같이 특정 빈도를 기반으로 스케줄링을 작성하고 싶어질 때도 있습니다.

빈도 기반의 스케줄을 설정하기 위해,

Airflow는 상대적인 시간 간격으로 스케줄 간격을 정의하도록 지원합니다.

빈도 기반 스케줄을 사용하기 위해서는 표준 라이브러리인 datetime 모듈에서 timedelta 인스턴스를 스케줄 간격으로 전달할 수 있습니다.

dag = DAG(
    dag_id="04_time_delta",
    schedule_interval=dt.timedelta(days=3),              ❶
    start_date=dt.datetime(year=2019, month=1, day=1),
    end_date=dt.datetime(year=2019, month=1, day=5),
)

❶ timedelta 를 통해 빈도 기반의 스케줄링을 사용할 수 있음

그럼 지금까지 Apache Airflow의 Scheduling 방식에 대해 알아보았습니다.

감사합니다.

| Reference |

https://airflow.apache.org/docs/

https://www.altexsoft.com/blog/apache-airflow-pros-cons/

⌜Data Pipelines with Apache Airflow⌟ - Oreilly

Apache Airflow, 제대로 이해하기 - Concept

gngsn — Sat, 30 Sep 2023 17:54:31 +0900

Airflow의 개념과 용어 - Dag, Task, Operator 등 - 을 이해하는 것이 본 포스팅의 목표입니다.

안녕하세요.

이번에는 짧게 Airflow 시리즈를 작성해보려고 합니다.

본 포스팅은 Airflow에 대한 가장 기본이 되는 개념을 다룹니다.

Apache Airflow 는 배치 워크플로우를 개발과 스케줄링, 그리고 모니터링하기 위한 오픈 소스 플랫폼입니다.

데이터를 관리하기 위한 데이터의 플로우를 지정 할 수 있을 뿐 아니라,
특정 서비스를 호출하는 등 배치 작업을 수행할 수 있습니다

기본으로 지원되는 GUI 웹 인터페이스를 통해 Aitflow 사용성을 크게 향상시킵니다.

Airflow는 넓은 범위, 그리고 다양한 크기의 배치를 지원하며,

다양한 배포 방식을 사용 할 수 있습니다.

What is Airflow?

Airflow는 Workflows as code 도구로, 모든 워크플로우가 Python 코드로 정의됩니다.

간단히 실제 Airflow 코드를 보면서 Airflow가 무엇인지에 대해 알아보겠습니다.

from datetime import datetime

from airflow import DAG
from airflow.decorators import task
from airflow.operators.bash import BashOperator

# ① A DAG represents a workflow, a collection of tasks
with DAG(dag_id="demo", start_date=datetime(2022, 1, 1), schedule="0 0 * * *") as dag:

    # ② Tasks are represented as operators
    hello = BashOperator(task_id="hello", bash_command="echo hello")

    @task()
    def airflow():
        print("airflow")

    # ③ Set dependencies between tasks
    hello >> airflow()

① Scheduling

"demo"라는 이름지어진 DAG는 2022년 1월 1일 부터 시작해서 하루에 한 번 실행됩니다.

DAG는 Airflow에서 사용하는 하나의 workflow 을 의미합니다.

② Tasks

아래의 총 두 가지의 Task가 실행됩니다.

Task는 Airflow에서 사용하는 가장 기본이 되는 작업 단위입니다.

1. Bash 스크립트를 실행하는 BashOperator

2. @task 를 사용하여 정의한 Python 함수

③ Dependencies

dependency를 고려하여 진행할 작업들의 순서를 >> 기호로 정의하여, 실행할 순서를 제어합니다.

Airflow는 위와 같은 스크립트를 읽어,

각 작업들의 순서와 각 작업 사이의 간격을 평가한 후 순서대로 작업을 실행합니다.

Overview

Airflow는 아래와 같은 구성으로 동작됩니다.

https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html

✔️ Scheduler

: 예약된 워크플로우를 트리거하고, Executor에게 작업을 전달하고 실행

✔️ Executor

: 실행 중인 작업을 처리하는 실행 프로그램

기본적으로 Airflow 를 설치하면 스케줄러 내부의 모든 것을 실행하지만,

Production 을 위한 Airfow 작업에서는 Worker에게 작업을 전달합니다.

✔️ DAG Directory

: /dags. 정의한 DAG 파일을 포함하는 폴더

Scheduler와 Executor, 그리고 Executor가 가진 모든 Worker 가 읽는 폴더입니다.

✔️ Metadata Database

: scheduler, executor 및 webserver가 상태를 저장하는 데 사용하는 데이터베이스

✔️ Webserver

: 사용자의 편의성을 위해 DAG와 Task의 동작을 검사하고 트리거하고, 디버깅할 수 있는 UI를 제공하는 웹 서버

가령, 아래와 같이 기본 제공되는 웹 UI를 통해 확인할 수 있습니다.

https://airflow.apache.org/docs/apache-airflow/stable/index.html

지금부터는 Airflow의 기본 개념인, 용어에 대해 살펴보도록 하겠습니다.

DAG

: Directed Acyclic Graph

DAG 는 Airflow의 핵심 개념입니다.
작업들을 모아서, 각 작업의 의존 모듈 (이하 dependency)와 관계를 구성하여

각 실행의 진행 방식을 명시합니다.

특정 작업(이하 Task)들의 의존성들을 나타내는 방식 중 하나는,
데이터 파이프라인을 Directed Graph로 표시하는 것입니다.

Directed Graph

Directed Graph는 작업들을 'Node'와 '방향성을 가진 Edge'를 가진 그래프를 표시하는 방식입니다.

가령, Task A 부터B, C 있다고 가정한다면, 위 세 개를 순차적으로 연결한다고 해봅시다.

Task A >> Task B >> Task C

Task A가 성공적으로 완료 되었을 때, Task B가 실행되기 시작합니다.

또, Task B가 성공적으로 완료 되었을 때, Task C가 실행되기 시작합니다.

그렇다면, DAG - Directed Acyclic Gragh 의 가운데 단어인 "Acyclic"은 어떤 의미일까요?

이는 Acyclic graph를 나타내며,

비순환 의존의 그래프, 즉 Loop 나 Cycle을 갖지 않는 Graph를 의미합니다.

이를 통해 Deadlock 등과 같이 순환 의존으로 인해 발생될 수 있는 문제를 방지하는 역할을 합니다.

아래 그림에서 위 그림이 Acyclic graph, 아래 그림이 Cyclic graph 입니다.

"Data Pipelines with Apache Airflow"

4개의 작업 A, B, C, D 을 정의한 후에,

언제 실행되어야 할지, 또 어떤 작업에 의존되어 있는지에 대한 정의를 명시합니다.

또한 DAG에 실행 빈도를 작성할 수도 있는데,

"내일부터 5분마다" 또는 "2020년 1월 1일 이후 매일" 와 같이 일정 시기를 지정하고 싶을 때 사용합니다.

DAG는 각 작업이 어떤 일을 하는지 관심이 없으며,

오로지 작업 실행 순서, 작업 재시도 횟수, 시간 초과가 있는 경우 등과 같은 작업을 실행하는 방법에만 관심이 있습니다.

Advantages

Airflow는 작성되어, 복잡하거나, 규모가 크거나, 스케줄링 작업이 필요한 곳에 적합합니다.

Airflow를 사용해야 한다면, 그 이유는 무엇일지 확인해보겠습니다.

1. Python

Python은 Data science 분야를 포함한 광범위한 분야에 사용되고 있습니다.

때문에, 많은 다양한 툴들과 라이브러리들이 제공되고 있습니다.

적은 노력, 그리고 적은 코드로 구현할 수 있는 Python의 장점을 그대로 응용할 수 있습니다.

2. Workflow as a code

Airflow는 Workflow as a code로, 모든 Airflow 작업은 코드로 정의됩니다.

간혹 DAG를 동적으로 정의한다고 해보겠습니다.

수 많은 파라미터들과 작업들을 보관해야만 하는 상황일 때,

코드를 통해 자동화시켜 생성해낼 수 있습니다.

3. Out of the box

특별히 Airflow를 사용하기 위한 코드 작업없이,

Airflow를 이해만 하고 있다면 바로 사용할 수 있는 형태입니다.

스케줄러를 의도에 맞게 설정만 한다면

복잡하거나 병렬 작업이 필요한 작업 등을 알아서 여러 스케줄러에 걸쳐 실행시킬 수도 있습니다.

Disadvantages

Airflow의 단점은 아래와 같습니다.

1. Learning curve

Airflow를 사용하기 위해선 Airflow에서 사용되는 개념이나 동작에 대한 이해가 필요합니다.

또한, Python 사용자가 아니라면 새로운 언어를 배워야 하는 어려움이 있습니다.

2. Insufficient docs

Airflow 공식 페이지를 보면 튜토리얼부터 용어 설명에 대해 명세되어 있습니다.

그럼에도 불구하고, 실제 Airflow를 사용할 때의 디테일이나 설명이 명료하지 못한 부분들로 어려움을 겪을 수 있습니다.

3. No versioning

많은 사용자들이 원하는 기능 중에 하나인 버전 관리도 하나의 단점이 됩니다.

변화된 이력을 기록하고 추적하는 기능이 필요해 보이지만, 현재로서는 지원되지 않습니다.

Task

Airflow의 가장 기본적인 실행 단위입니다.

Task들을 이용해서 DAG 들을 원하는 실행 순서로 배열하고, 작업이 가진 Dependency를 고려한 순서를 조정하게 됩니다.

기존적으로, 아래와 같이 세 종류의 Task가 존재합니다.

✔️ Operator: DAG의 대부분을 빠르게 구성할 수 있는 미리 정의되어진 작업 템플릿 predefined task template

✔️ Sensor: 외부 이벤트 발생을 대기하는 Operator를 특정지어 정의한 Operator 하위 클래스

✔️@task: Python 함수를 커스텀한 TaskFlow를 위한 decorator

Operator

개념적으로 Operator는 미리 정의되어진 Task의 템플릿을 의미합니다.

모든 Operator는 특정한 하나의 작업을 실행한다는 기본적인 목적이 있으며, 가령 아래와 같은 종류가 있습니다.

✔️ BashOperator: Bash command/script 실행 시 사용

✔️ PythonOperator: Python 함수를 실행하는 데 사용

✔️ EmailOperator: 이메일을 보내는 데 사용

✔️ SimpleHTTPOperator: HTTP 엔드포인트를 호출하는 데 사용

Operator vs Task?
Operator와 Task라는 단어가 종종 혼용되어 사용되곤 합니다.
일부 사람들은 이 둘이 동일한 동작을 할 수 있고, 서로를 대체할 수 있다고 주장합니다.

사실 여기엔 작은 차이점이 있는데요, 차이점을 기준으로 정리하면 다음과 같습니다.

Operator: 수행할 일을 처리하는 템플릿처럼 사용가능한 클래스
Task: Operator를 구현해서 수행할 일을 정의한 것

가령 위에서 확인했듯이, Airflow는 BaseOperator라는 클래스가 있는데
이로부터 상속되는 PythonOperator, EmailOperator, OracleOperator 등이 존재합니다.

Operator는 수행해야 할 작업에 집중할 수 있고,
Task를 통해서는 조금 더 정밀한 작업의 실행이 가능합니다.

Task Depencencies

주로 배치를 작성할 때, 하나의 작업이 동작하기 보다는 여러 작업들이 연쇄적으로 실행하는 형식입니다.

다른 작업의 결과에 의존하여 실행하는 작업(upstream)과 다른 작업이 의존하는 작업(downstream)이 있습니다.

작업 사이에 이러한 의존성을 선언함으로써, DAG 구조를 구성합니다.
각 작업 dependency를 선언하는 기본적인 방법으로는, 크게 두 가지가 있습니다.

첫 번째로, 권장하는 방법인 >> 와 << 연산자 입니다.

first_task >> [second_task, third_task]
third_task << fourth_task

두 번째로, set_upstream 과 set_downstream 메소드를 통해 명시적으로 정의할 수 있습니다.

first_task.set_downstream(second_task, third_task)
third_task.set_upstream(fourth_task)

조금 더 복잡한 dependency 정의는 cross_downstream, chain 메소드를 통해 정의할 수 있으며,

해당 내용은 공식 페이지를 참고해주시기 바랍니다.

| Reference |

https://airflow.apache.org/docs/

https://www.altexsoft.com/blog/apache-airflow-pros-cons/

⌜Data Pipelines with Apache Airflow⌟ - Oreilly

인간관계론, 데일카네기

gngsn — Fri, 1 Sep 2023 02:01:11 +0900

How to win friends and influence people, Dale carnegie

Date: 2023.07.12 ~ 2023.07.28

Rate: ★ 4.2

Pages: 352p

Comment: 인간관계론을 읽은 지는 꽤 지났는데, 그동안 이 책의 매력을 느낄 수 있었다. 책을 처음 읽을 때는 "너무 당연한 소리아닌가"라는 생각으로 좋게 잘 읽었다는 생각이 크진 않았다. 시간이 지나고 사람들을 만나며, 많은 패턴의 사람들을 보게 됐다. 그런 사람들을 볼 때 이 책이 계속 생각나곤 했다. 상대방의 경계심이나 불안함이 보이며, 이럴 때 어떻게 다가가면 좋겠다는 생각을 하곤 한다. 책을 보기 전에도 이런 생각을 했을 수도 있지만, 중요한 건 '인지'였다. 막연한 '어떻게 행동해야겠다'가 생각의 타당한 이유를 갖게 된 것이다.

본인이 생각하기에 책을 읽는 재미는, 바로 이렇게 적용할 수 있고 공감할 수 있는 내용으로 메타인지를 얻어갈 때 인 것 같다.

Summary:

본 책은 총 6부의 상대방을 대하는 방식에 대해 소개한다. 그 중, 본 포스팅에서는 3부에 소개된 "사람들을 설득하는 12가지 방법"에 대해 정리한다. 가장 인상깊었던 내용인 이유로, 어떤 내용을 다룰 지 확신이 서지 않는 상태에서 가장 높은 우선순위였기 때문이다. "사람들을 설득하는 12가지 방법"은 총 12가지의 규칙을 소개한다.

사람들을 설득하는 12가지 방법

Rule 1. 논쟁을 이기는 유일한 방법은 논쟁을 피하는 것이다.
The only way to get the best of an argument is to avoid it.

Rule 2. 다른 사람의 의견을 존중하라.
Show respect for the other man’s opinions. Never tell a man he is wrong.

Rule 3. 틀렸다면 인정하라.
If you are wrong, admit it quickly and emphatically.

Rule 4. 우호적으로 시작하라.
Begin in a friendly way.

Rule 5. 다른 사람들로 하여금 ‘Yes’ 를 말하게 하라.
Get the other person saying “yes, yes” immediately.

Rule 6. 다른 사람이 말을 많이 하도록 만들어라.
Let the other man do a great deal of the talking.

Rule 7. 상대방이 스스로 생각해 냈다고 여기도록 만들어라.
Let the other fellow feel that the idea is his.

Rule 8. 진심으로 다른 사람의 관점에서 보려 애써라.
Try honestly to see things from the other person’s point of view.

Rule 9. 다른 사람들의 생각과 욕망에 공감하라
Be sympathetic with the other person’s ideas and desires.

Rule 10. 유의미한 동기를 어필하라
Appeal to the nobler motives.

Rule 11. 당신의 생각을 극화하라
Dramatize your ideas.

Rule 12. 도전 의욕을 불러일으켜라
Throw down a challenge.

# Rule 1.

Avoiding arguments is winning

논쟁을 이기는 유일한 방법은 논쟁을 피하는 것이다.
The only way to get the best of an argument is to avoid it.

본 장을 시작하며, 카네기는 자신과 개몬드 씨 사이의 일화를 하나를 소개한다.

개몬드는 오랜 시간 셰익스피어를 연구한 카네기의 친구다.

둘은 한 연회를 갔고, 즐거운 만찬을 즐긴다.

이때, 옆에 앉은 신사가 “인간이 계획할지라도 최종 결정을 내리는 것은 신이다.”와 관련된 재미있는 이야기를 했다.

하지만 곧 그 신사는 그 말이 성경에 있는 말이라고 했고,

곧 카네기는 그 말이 셰익스피어가 한 말임이 틀림없이 알아차렸다.

카네기는 그 자리에서 바로 그 말이 틀렸음을 지적했다.

한창 그 신사와 카네기는 서로가 옳다고 말하다가,

오랜 시간 셰익스피어를 연구한 개몬드에게 진실의 여부를 물어본다.

개몬드는 셰익스피어가 한 말임을 알고 있었지만, 그 신사분이 옳다고 말한다.

카네기는 개몬드와 집을 같이 걸어가며, 아래와 같은 대화를 한다.

밤 집으로 오는 길에 나는 개몬드 씨에게 말했다.

“프랭크, 그 말을 셰익스피어가 썼다는 건 너도 알잖아?”
“그럼, 물론이지. 『햄릿』 5막 2장이지.
하지만 데일, 우린 즐거운 연회에 손님으로 간 거잖아. 왜 그 사람이 틀렸다는 걸 증명해야 해? 그러면 그 사람이 널 좋아할까? 그냥 체면을 살려 주면 좋잖아? 그 사람은 네 의견을 묻지도, 원치도 않았어. 왜 그런 사람과 논쟁을 하려고 해?
예리한 칼날은 피하고 보는 법이야.”

“예리한 칼날은 피하고 보라.”

카네기가 기억하는 개몬드씨가 남긴 유의미한 교훈이다.

우리는, 다른 사람이 저지른 오류에 대해 본인이 '알고 있음'을 과시하기 위해 그 오류를 지적하곤 한다.

하지만, 누군가에게 자신의 의견을 설득하고 싶다면, 아래의 문장을 기억하라.

“자신의 의지에 반해 설득당한 사람은 자신의 생각을 바꾸지 않는다.”

논쟁하고, 지지 않으려 애쓰고, 반박을 하면 때로는 승리를 얻을 수도 있지만,

하지만 상대방의 호의를 얻지 못한다면 그것은 공허한 승리에 불과하다.

# Rule 2.

Respect, don't criticize

다른 사람의 의견을 존중하라.
Show respect for the other man’s opinions. Never tell a man he is wrong.

우리는 사실이라고 익숙하게 믿어 왔던 것들을 계속해서 믿고 싶어 한다.

어떤 사람이 우리의 가정(가설)에 어떤 의심이라도 제기하면 우리는 분개하며,

그 가정을 지킬 수 있는 모든 변명 거리를 찾는다.

단적으로, 우리의 합리성은 이미 믿어 왔던 것을 계속 믿기 위한 주장을 찾아 내려는 시도에 불과하다.

가령, 카네기의 이야기를 살펴보자.

한 번은 카네기가 아주 높은 가격으로 집의 커튼을 만들었다.

며칠 후, 친구 하나가 찾아와 커튼을 보았고, 가격을 듣더니 그녀는 승리감에 도취된 큰 소리로 말한다.

"제대로 바가지 썼군."

곧 카네기는 이 말이 사실임을 인지했음에도 변명을 늘어놓는다.

카네기는 비쌀수록 제 가치를 하기 마련이며, 싼 가격으로는 품질과 예술적 취향 둘 다를 잡을 수 없다는 등등의 말을 한다.

다음날 다른 친구가 찾아왔는데, 그녀는 커튼을 보며 감탄과 칭찬을 건넨다.

그러자, 그의 반응은 완전히 달라졌다.

“사실, 돈을 너무 많이 썼어. 이런 걸 주문하지 말 걸 그랬어.”

우리는 잘못을 저질렀을 때 스스로 인정할 수 있다.

다른 사람이 잘 말해준다면 기꺼이 잘못을 인정하고, 본인이 솔직하고 마음 넓은 사람이라는 여지도 생긴다.

하지만 다른 사람이 우리가 소화하기 힘든 사실을 억지로 밀어 넣으려고 한다면 반발심만 생긴다.

누군가의 판단력까지 걸고넘어지는 사실을 듣기 좋아하는 사람은 없다.

누군가에게 무엇인가를 알려줘야 한다면, 다음 문장을 기억하라.

“인간들은 가르치지 않는 척 가르쳐야 한다. 그가 모르고 있는 것들은 그가 잊은 것이라고 하라.”
- 영국 시인 알렉산더 포프

그리고, 현명한 길을 택해라.

"가능하면 다른 사람보다 현명해져라. 하지만 사람들에게 그 사실을 말하지는 말아라"

혹은 다른 사람의 마음을 열게하는 아래 마법의 문장을 사용하라.

“저도 틀릴 수 있죠. 자주 틀리기도 해요. 사실을 한 번 들여다보기로 합시다.”

# Rule 3.

Admit mistakes promptly

틀렸다면 인정하라
If you are wrong, admit it quickly and emphatically.

싸워서 얻을 수 있는 것은 많지 않다.
하지만 양보하면 생각보다 휠씬 많은 것을 얻는다.

# Rule 4.

Begin in a friendly way.

우호적으로 시작하라
Begin in a friendly way.

유명한 이야기로 해당 규칙의 이해를 돕는다.

햇볕과 바람이 한 사내의 코트를 벗기는 내기를 하는 이야기를 누구나 한 번쯤 들어봤을 것이다.

결론 적으로, 햇볕은 바람보다 빠르게 코트를 벗길 수 있다.

친절과 우호적인 접근 또 인정은, 가혹한 위협이나 폭풍 같은 비난보다 훨씬 더 쉽게 사람의 마음을 바꿀 수 있다.

"벌꿀 한 방울에 한 통의 쓸개즙보다 더 많은 파리가 꼬인다."
- 링컨

사람들을 당신 의견에 동의하도록 만들고 싶을 때는,

잊지 말고 우호적인 방식으로 다가가도록 하라.

# Rule 5.

Make them say "yes" immediately

다른 사람들로 하여금 ‘Yes’ 를 말하게 하라
Get the other person saying “yes, yes” immediately.

소크라테스의 문답법은 상대방의 우호적인 반응을 먼저 이끌어 낸 후,

그가 원하는 질문을 할 때까지 긍정적인 반응을 유지 시키는 것이다.

즉, ‘네, 네’ 반응을 이끌어 내는 데 기반을 둔다.

소크라테스는 상대방이 동의할 수밖에 없는 질문을 던졌다.

그는 계속해서 질문을 던져, 계속해서 많은 동의를 받아 냈다.

소크라테스는 이러한 방법으로

상대방이 조금 전까지 비판했던 사실을, 자신도 모르는 사이에 받아들일 수 밖에 없게 만들었다.

누군가가 당신이 틀렸다고 말하고픈 기분이 든다면,

맨발의 소크라테스를 기억하고 상냥하게 질문을 던져라.

‘네, 네’ 반응을 이끌어 낼 질문을 던져라.

# Rule 6.

Encourage them to talk more

다른 사람이 말을 많이 하도록 만들어라
Let the other man do a great deal of the talking.

# Rule 7.

Make them feel it's their idea.

상대방이 스스로 생각해 냈다고 여기도록 만들어라
Let the other fellow feel that the idea is his.

우리가 설득해야 하는 대상에게 설득을 목적으로 말하는 것은 크게 도움이 되지 않는다.

그들로 하여금 그 생각을 하고 있다고 생각할 수 있도록 대화를 이어나가라.

2천 5백 년 전 중국의 현자였던 노자는 아래의 중요한 말을 했다.

“수많은 산골짜기 시내가 강과 바다를 선망하는 이유는, 그들의 아래에서 흐르고 있기 때문이다.
강과 바다는 모든 산골짜기 시내를 지배할 수 있다.
그러니 다른 사람들보다 위에 서고 싶은 현자들은 그들보다 자신을 낮춰야 한다.
다른 사람들 앞에 서고 싶으면 그들보다 뒤에 서야 한다.
그래야 사람들이 자신들보다 위에 있는 사람에게 중압감을 느끼지 않는다.
자신들 앞에 서 있는 사람이 있더라도 그것에 대해 아파하지 않는다.”

위의 인용구는 해당 규칙을 사용하고자 할 때 가질만한 입장이나 태도를 정비할 기회를 준다.

# Rule 8.

See from others' perspective

진심으로 다른 사람의 관점에서 사물을 보려 애써라
Try honestly to see things from the other person’s point of view.

해당 규칙에서는 인상깊은 카네기의 말을 다듬어 적어본다.

진실로 그 사람의 입장이 되어 보라.

“내가 저 사람이었다면 어떤 생각을 했을까? 어떻게 반응했을까?”

누군가의 행동이나 생각, 즉 원인에 관심을 갖게 되면, 결과를 덜 싫어하게 되기 때문이다.

이는 시간을 절약하고, 상대방에 대한 불편함도 줄일 수 있다.

더불어, 사람을 다루는 당신의 능력도 놀랍도록 일취월장할 것이다.

사람이 어떤 생각을 하고 어떤 행동을 하는 데는, 그럴만한 이유가 있기 마련이다.

그 숨겨진 이유를 찾아내라.

그러면 그의 행동이 이해될 것이다.

아마 그의 성품마저 이해할 수 있게 될 것이다.

하지만 기억하라.

다른 사람이 완전히 틀릴 수도 있다.

하지만 그 사람은 그렇게 생각하지 않는다. 그들을 비난하지 마라.

바보라도 비난은 할 수 있다.

이해하려 노력하라. 현명하고, 아량이 넓고, 뛰어난 사람만이 그런 노력을 한다.

카네기는 또한, 인터뷰를 할 때도 이 규칙을 적용할 수 있다는 말을 전한다.

인터뷰 중 어떤 말을 할 것인지, 면접관의 관심과 동기에 비추어 보는 관점에서 면접관을 먼저 이해하는 것이다.

이 책을 통해 항상 다른 사람의 관점에서 생각해 보고 당신뿐 아니라

상대방의 관점에서 사물을 보는 태도를 얻을 수만 있다면,

그 사실만으로도, 당신의 경력에서 중요한 이정표 하나가 세워진 것이다.

# Rule 9.

Empathize with others' ideas and desires

다른 사람들의 생각과 욕망에 공감하라
Be sympathetic with the other person’s ideas and desires.

화가 나 있고, 완고한 태도를 가졌고, 터무니없는 이야기를 늘어놓는,

그런 사람들을 생각해보면 딱히 욕먹을 만한 근거는 많지 않다.

그 사람들에게 안타까운 마음을 가져라.

그 사람들을 동정하고, 그 사람들에게 공감하라.

카네기는 아래의 글을 인용해 부정적인 모습으로 다가오는 사람들을 이해해야하는 타당성을 알려준다.

"인간이라는 종은 모두 공감을 갈망한다.
아이는 자신의 상처를 남들 눈앞에 드러내 보여 주고, 동정을 받기 위해서라면 자신의 몸에 상처를 내는 일도 마다하지 않는다.
같은 이유로 어른들도 자신의 상처를 보여 주고, 자신이 겪은 사고와 질병, 특히 수술에 대해서 꼬치꼬치 이야기하려 든다.

실제든 가상이든 간에 불행에 대한 ‘자기 연민’은 어느 정도는 누구에게나 보편적으로 있다."

- 아서 I. 게이츠Arthur I. Gates, 『교육 심리학Educational Psychology』

# Rule 10.

Appeal to the nobler motives

고상한 동기를 어필하라
Appeal to the nobler motives.

해당 규칙은 카네기가 소개하는 한 이야기의 등장인물이 한 말을 통해 그 의미를 파악할 수 있다.

그는 아래와 같이 말했다.

고객에 대해 어떤 정보도 얻을 수 없을 때 유일하게 일을 진행할 수 있는 기반은,

바로 그 고객이 옳다고 느끼면,

본인이 바로 '옳은 것에 기꺼이 비용을 지불하려는 사람'이라고 가정하곤 한다는 것이다.

즉, 그들이 진실되고, 정직하고, 믿을 수 있는 사람이며 자신들이 옳다는 확신만 있으면 비용을 아끼지 않는다는 말이다.

좀 더 분명하게 말해 보자면, 사람들은 정직하며 자신의 의무를 다하기를 원한다.

이 규칙에 예외가 되는 사람들은 많지 않다.

거짓으로 속이려 드는 사람들이라도,

본인을 정직하고, 올바르고, 공정한 사람이라고 생각한다고 느끼게 만들어 준다면,

대부분 호의적으로 돌아서리라고 확신한다는 것이다.

# Rule 11.

당신의 생각을 극화하라
Dramatize your ideas.

전시해 놓은 캔디에 우연히 환한 조명이 비추며 캔디 판매가 두 배가 되었다는 이야기도 있고,

크라이슬러사가 자기 회사의 차에 코끼리를 올려놓고 차의 튼튼함을 부각시켰다는 예도 있다.

# Rule 12.

도전 의욕을 불러일으켜라
Throw down a challenge.

“어떤 일을 하게 만들기 위해서는 경쟁심을 자극해야 합니다.

누가 더 돈을 많이 버는가 하는 추잡한 경쟁이 아닙니다.
다른 사람보다 더 뛰어나고자 하는 욕망, 그게 경쟁심입니다.

Kotlin 1.9.0 Release, 제대로 살펴보기

gngsn — Mon, 28 Aug 2023 23:59:08 +0900

본 포스팅은 개발 시 직접적으로 사용하게 될 Kotlin 1.9.0의 업데이트 사항들을 살펴보는 것을 목표로 합니다.

Kotlin 1.9.0

지난 2023년 8월 23일, Kotlin 1.9.0 가 릴리즈 되었습니다.
기존의 기능들이 Stable 지원되고, 성능 개선이나 사용성 향상이 되는 등의 다양한 업데이트가 진행되었습니다.

참고로, 1.7부터 Alpha로 지원되던 K2 Compiler가 1.9부터 Beta로 지원됩니다.
따라서 Kotlin 2 릴리즈 전 설정 후 사용해보실 수 있습니다.

본 포스팅에서는 Web(Wasm), Multiplatform Support 등은 제외하고,
Kotlin의 Language / Library 측면의 내용만을 정리했습니다.

Highlights

본 포스팅에서 다룰 내용이자 목차는 아래와 같습니다.

Enum.entries
Data object
Inline value classes
..< operator
Stable time API
@Volatile
Regex named capture group
createParentDirectories()

본 포스팅에서 다루지는 않지만, 참고할 만한 업데이트 사항입니다.

✔️ New Kotlin K2 compiler updates
✔️ Preview of the Gradle configuration cache in Kotlin Multiplatform
✔️ Changes to Android target support in Kotlin Multiplatform
✔️ Preview of custom memory allocator in Kotlin/Native
✔️ Library linkage in Kotlin/Native
✔️ Size-related optimizations in Kotlin/Wasm

Enum.entries

Kotlin - Enum.entries

entries는 Enum의 values() 함수를 성능을 고려한 형태입니다.

Kotlin Github 를 확인해보면 Enum.values() 가 아닌 Enum.entries 를 사용해야 할 내용에 대해 확인할 수 있습니다.

Enum의 entries 속성은 이미 1.8.20 버전에서 Experimental feature로 소개되었습니다.
1.9.0에서 부터는 Stable 되어 제공됩니다.

values()는 계속해서 지원될 예정이지만, entries 사용을 추천합니다.
IntelliJ는 아래와 같은 경고 메시지를 띄웁니다.
'Enum.values()' is recommended to be replaced by 'Enum.entries' since 1.9

✔️ values()

Openjdk bugs 과 Openjdk mail 에서 확인할 수 있듯이,
values() 함수는 "design bug in Java" 라고 언급되는 JDK Issue 중 하나입니다.

This is essentially an API design bug; because values() returns an array, and arrays are mutable, it must copy the array every time. Otherwise some miscreant could change the contents of this array, and other consumers of `values()` would see wrong data.

요약하자면, 다음과 같습니다.
values()는 모든 호출 마다 Mutable Array 복사본을 생성해서 반환하기 때문에, API 본질적 설계 버그입니다.
이는 values()이 반환한 Array 값을 악의적인 의도로 변경하거나 배열을 조작하려는 개발자의 실수로 이어질 수 있습니다.

설계 버그인 이유는 Enum의 정의 값들을 반환하는 배열이 Mutable할 이유가 전혀 없죠.
새로운 배열을 계속 생성하니, 불필요하게 메모리를 차지 하기도 합니다.

✔️ values() → entries

1.9부터는 바로 아래와 같이 사용할 수 있습니다.

enum class Color(val colorName: String, val rgb: String) {
    RED("Red", "#FF0000"),
    ORANGE("Orange", "#FF7F00"),
    YELLOW("Yellow", "#FFFF00")
}

fun findByRgb(rgb: String): Color? = Color.entries.find { it.rgb == rgb }

만약, 1.9 버전 미만이라면, 아래와 같이 gradle을 설정한 후, @OptIn Annotation을 붙여서 사용할 수 있습니다.

Step 1 / 1.9 버전 사용 gradle 설정

// kotlin
tasks
    .withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask<*>>()
    .configureEach {
        compilerOptions
            .languageVersion
            .set(
                org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
            )
    }
    
// groovy
tasks
    .withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask.class)
    .configureEach {
        compilerOptions.languageVersion =
              org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
}

Step 2 / @OptIn Annotation(ExperimentalStdlibApi)

@OptIn(ExperimentalStdlibApi::class)
fun findByRgb(rgb: String): Color? = Color.entries.find { it.rgb == rgb }

Data object

Kotlin - data object

Data object는 data class와 동일한 방식의 toString(), equals() 및 hashCode() 를 포함한 형태입니다.
Kotlin 1.8.20에 소개된 Data object 도 마찬가지로 Stable 하게 지원됩니다.

이 기능은 데이터 object 선언과 함께 data class을 선언합니다.
때문에, sealed class 나 interface hierarchy로 구성된 sealed 계층에서 특히 유용합니다.

sealed interface ReadResult
data class Number(val number: Int) : ReadResult
data class Text(val text: String) : ReadResult
data object EndOfFile : ReadResult

fun main() {
    println(Number(7)) // Number(number=7)
    println(EndOfFile) // EndOfFile
}

위 코드에서 EndOfFile을 일반 object 대신 data object로 선언하면
직접 재정의할 필요 없이 toString()을 포함됨을 의미합니다.
data object의 기능은 함께 제공되는 data class 정의와 동일한 형태로 /*대칭*/ 유지됩니다.

kotlin에서는 data object와 data class의 기능을 동일하게 가져간다는 말을 '대칭을 유지한다'라고 표현합니다.
원문: This maintains symmetry with the accompanying data class definitions.

Inline value classes

Kotlin - Inline value classes

Kotlin 1.9.0 부터, value class 내 secondary constructors의 body를 작성할 수 있습니다.

@JvmInline
value class Person(private val fullName: String) {
    init {
        check(fullName.isNotBlank()) {
            "Full name shouldn't be empty"
        }
    }
    
    // Until Kotlin 1.9.0:
    constructor(name: String, lastName: String) : this("$name $lastName")
    
    // Allowed by default since Kotlin 1.9.0:
    constructor(name: String, lastName: String) : this("$name $lastName") {
        check(lastName.isNotBlank()) {
            "Last name shouldn't be empty"
        }
    }
}

기존에는 public 기본 구성자에서만 body를 작성할 수 있었는데요.
이로 인해, 기본 값을 캡슐화하거나, 값에 제약을 건 inline class (value class)를 만드는 것이 불가능했습니다.
더 자세한 사항은 Kotlin: KEEP를 참고하세요.

Kotlin 1.4.30에서 init 블록에 대한 제한을 해제하여 이를 가능하게 했으며,
Kotlin 1.8.2 에서는 보조 생성자의 body를 구현하는 기능의 Preview를 소개했습니다.

그리고, 1.9.0 부터는 default를 위 기능을 사용할 수 있게 되었습니다.
실제, Kotlin 1.8.2 버전 이하에서 보조 생성자의 body를 생성하고자 하면 아래와 같은 컴파일 오류를 발생시킵니다.
The feature "value classes secondary constructor with body" is only available since language version 1.9

Open-ended Operator: `..<`

Kotlin - ..< operator

: open-ended ranges

..< 연산자는 개구간(open-ended ranges) 을 포함하는 미만 범위 연산자입니다.

Kotlin 1.7.20에 도입되어 1.8.0에서 Stable이 되었습니다.

1.9.0부터는, 개방형 범위에서 작업하기 위한 표준 라이브러리 API도 Stable입니다.

쉽게 말해, ..< 연산자는 less than (﹤)을 표현하는 연산자 입니다.

주의할 점은, less than 은 equal 을 포함하지 않는다는 점입니다.

가령, 아래와 같이 infix 함수를 사용할 때, 범위에 대한 오류를 범하곤 합니다.

fun main() {
    for (number in 2 until 10) {
        if (number % 2 == 0) {
            print("$number ")
        }
    }
}

출력이 어떻게 될지 예상이 가시나요?

2 4 6 8

출력은 ﹤ 의 범위이기 때문에 10을 포함하지 않습니다.

하지만, 영어권이 아닌 곳에서 until 이라는 단어는 포함 여부를 혼동시킬 수 있기 때문에,
아래와 같이 명확하게 표시할 수 있습니다.

fun main() {
    for (number in 2..<10) {
        if (number % 2 == 0) {
            print("$number ")    // 2 4 6 8
        }
    }
}

Stable Time API

Kotlin - ..< operator

기존 시간 API에는 measureTimeMillis와 measureNanoTime 함수가 존재합니다.
하지만, 이 두 함수는 사용하기에 직관적이지 않습니다.

둘 다 다른 단위로 시간을 측정하는 것은 맞지만,
measureTimeMillis는 실제 세계 시간을 나타내는 Wall Clock 을 사용하지만,
measureNanoTime은 컴퓨터가 직접 계산하는 Monotonic Clock 를 사용합니다.

이 문제를 해결하기 위해 1.9.0은 아래의 기능을 포함하는 새로운 시간 API를 제공합니다.

- 원하는 시간 단위로 Monotonic Time Source (Clock) 를 사용해서 코드 실행 시간 측정 가능
- 특정 시간의 시점 표시
- 두 시점 사이의 차이를 비교
- 특정 시간 이후 시간이 얼마나 흘렀는지 확인
- 현재 시간이 특정 시점을 지나갔는지 확인

하나씩 확인해보겠습니다.

✔️ Measure execution time

: 코드 실행 시간 측정하기

코드 실행 시간 측정을 위해서 아래의 두 함수를 사용할 수 있습니다.

#1.
inline fun measureTime
: 코드 실행 시간 측정

#2.
inline fun measureTimedValue
: 코드 실행 시간 측정 + 결과를 반환 시간 측정

기본적으로 두 기능 모두 Monotonic Time Source를 사용합니다.
만약, 실제 세계 시간을 사용하고 싶다면, System.nanoTime()를 사용할 수 있습니다.

Android 라면, SystemClock.enapsedRealTimeNanos()를 사용할 수 있습니다.

tailrec fun ack(m: Int, n: Int): Int = when {
    m == 0 -> n + 1
    n == 0 -> ack(m - 1, 1)
    else -> ack(m - 1, ack(m, n - 1))
}

fun computeAck(m: Int, n: Int) {
    var res = 0
    val t = measureTime {
        res = ack(m, n)
    }
    println("ack($m, $n) = ${res}")
    println("duration: ${t.inWholeNanoseconds / 1e6} ms")
}

fun main() {
    println("Hello from Kotlin!\n")
    computeAck(3, 10)
}

위 코드를 실행 시키면, 아래와 같은 결과를 확인할 수 있습니다.

Hello from Kotlin!

ack(3, 10) = 8189
duration: 77.754667 ms

✔️ Measure differences in time

특정 순간을 시간으로 표시하려면 TimeSource 인터페이스와 MarkNow() 함수를 사용하여 TimeMark를 생성합니다.

동일한 TimeSource 내의 TimeMarks의 차이를 ① 감산 연산자(-)를 사용해서 측정할 수 있습니다.

혹은, ② TimeMarks 간 비교를 할 수도 있습니다.

import kotlin.time.*

fun main() {
    val timeSource = TimeSource.Monotonic
    val mark1 = timeSource.markNow()
    Thread.sleep(500) // 0.5초 Sleep
    val mark2 = timeSource.markNow()

    repeat(4) { n ->
        val mark3 = timeSource.markNow()
        val elapsed1 = mark3 - mark1	// ①
        val elapsed2 = mark3 - mark2	// ①

        println("Measurement 1.${n + 1}: elapsed1=$elapsed1, elapsed2=$elapsed2, diff=${elapsed1 - elapsed2}")
    }
    
    println(mark2 > mark1) // ② true
}

✔️ Check if a time has passed

특정 기한이 지났거나 특정 시간에 도달했는지 확인하려면,

extension 함수인 hasPassNow() 혹은 hasNotPassNow() 를 사용할 수 있습니다.

import kotlin.time.*
import kotlin.time.Duration.Companion.seconds

fun main() {
    val timeSource = TimeSource.Monotonic
    val mark1 = timeSource.markNow()
    
    val fiveSeconds: Duration = 5.seconds
    val mark2 = mark1 + fiveSeconds

    println(mark2.hasPassedNow()) // false - 5초 안지남
    Thread.sleep(6000) // 6초 대기    
    println(mark2.hasPassedNow()) // true  - 5초 지남

}

@Volatile

Java에서와 동일하게, Kotlin에서 @Volatile 를 Stable 하게 지원합니다.

var 속성에 주석을 붙이면 '읽기'와 '쓰기'가 atomic하게 되고,
'쓰기'는 항상 다른 스레드도 확인할 수 있게끔 표시visible 됩니다.

writes are always made visible to other threads

1.8.20 에서 JVM과 Kotlin/Native 모두 사용 가능한 Kotlin.concurrent.Volatile 을 Preview 로 도입했으며,

1.9.0 에서 kotlin.concurrent.Volatile 은 Stable로 지원합니다.

1.8.20 이전에는 JVM에서만 kotlin.jvm.Volatile 주석을 사용할 수 있었습니다.
다른 플랫폼에서 사용한 경우 무시되어 오류가 발생했습니다.

멀티 플랫폼 프로젝트에서 kotlin.jvm.Volatile 을 사용하고 있었다면,

kotlin.concurrent.Volatile 로 마이그레이션하는 것을 추천합니다.

Regex named capture group

1.9.0 이전에도 정규 표현식을 사용할 때, 캡처 그룹 이름을 통해 문자열을 추출하기 위한 기능이 존재합니다.
하지만, 이를 지원하는 특정 함수가 없었는데요.

실제로, stackoverflow에서 이를 구현하는 코드들을 논의한 것을 확인할 수 있습니다.

1.9.0에는 정규 표현식 matching에 대한 그룹 이름을 기반으로 문자열을 추출할 수 있는 기능을 지원합니다.
즉, 그룹 이름을 가져오기 위해 따로 코드를 작성하지 않고,
Kotlin이 지원하는 형식 common function 을 사용해서 손쉽고 안정적으로 추출할 수 있다는 의미입니다.

가령, 아래와 같은 그룹 city, state, areaCode 를 추출하는 정규식을 확인해보겠습니다.

fun main() {
    val regex = """\b(?<city>[A-Za-z\s]+),\s(?<state>[A-Z]{2}):\s(?<areaCode>[0-9]{3})\b""".toRegex()
    val input = "Coordinates: Austin, TX: 123"

    val match = regex.find(input)!!
    println(match.groups["city"]?.value)
    // Austin
    println(match.groups["state"]?.value)
    // TX
    println(match.groups["areaCode"]?.value)
    // 123
}

각 이름을 통해 문자열을 추출한 결과를 확인할 수 있습니다.

createParentDirectories()

상위 디렉터리를 생성하기 위한 새 경로 Utility가 추가되었습니다.
가령, 새 파일을 만드는 데 부모 디렉터리가 없다면, 필요한 모든 부모 디렉터리를 생성합니다.

실제로 부모 디렉터리 생성을 위해 파일 경로를 제공하면, 먼저 부모 디렉터리가 존재하는지 확인합니다.

만약 존재하지 않으면 부모 디렉터리가 생성됩니다.

createParentDirectorys()는 파일을 복사할 때 특히 유용한데,

가령, 아래와 같이 copyToRecursive() 함수와 함께 사용할 수 있습니다.

sourcePath.copyToRecursively(
   destinationPath.createParentDirectories(),
   followLinks = false
)

지금까지 다룬 코드 상의 업데이트가 아니더라도, 다양한 기능들이 업데이트 되었습니다.
다른 업데이트 사항들을 확인하면, 해당 언어에 대한 이해에 큰 도움이 되기 때문에 한 번쯤 읽어보시는 것을 추천드립니다.

| References |

What's new in 1.9.0
What's new in 1.8.20
Kotlinlang Docs
Kotlinlang API :latest-jvm-stdlib

Kotlin, null 어렵지 않게 다루기

gngsn — Sun, 20 Aug 2023 23:29:39 +0900

최근, 코프링을 사용하고 있어서 코틀린 시리즈를 마무리해보려 합니다.

이전 게시글을 다시 작성하는 것도 고려하고 있으니, 참고하시길 바랍니다.

TL;DR

- 코틀린은 널이 될 수 있는 타입을 지원해 NullPointerException 오류를 컴파일 시점에 감지할 수 있습니다.

- 코틀린의 안전한 호출 ?., 엘비스 연산자 ?:, 널 아님 단언 !!, let 함수 등을 사용하면 널이 될 수 있는 타입을 간결한 코드로 다룰 수 있다.

- as? 연산자를 사용하면 값을 다른 타입으로 변환하는 것과 변환이 불가능한 경우를 처리하는 것을 한꺼번에 편리하게 처리할 수 있다.

- 널이 될 수 있는 원시 타입(Int? 등) 은 자바의 박싱한 원시 타입 (java.lang.Integer 등)에 대응한다.

- Any 타입은 다른 모든 타입의 조상 타입이며, 자바의 Object에 해당한다. Unit 은 자바의 void와 비슷하다.

코틀린에서는 자바를 사용하며 문제를 겪었던 문제들에 도움이 되는 몇 가지 특성을 새로 제공합니다.

✔️ 널이 될 수 있는 타입 nullable type

✔️ 읽기 전용 컬렉션

본 포스팅에서는 그 중, 널이 될 수 있는 타입에 대해 다루려고 합니다.

Nullability

적어도 자바 개발자라면, NullPointerException로 고통받아 null에 대한 부정적인 시선이 있을 수도 있습니다.

코틀린 개발자의 입장으로는 null과 type에 대해 다시 한 번 생각해볼 필요가 있습니다.

자바에서는 의도치 않은 null 값을 고려하여 코드를 작성해야 했다면,

코틀린에서는 의도적으로 사용할 null 값만 고려하면 됩니다.

코틀린은 의도치 않은 null, 정확히는 NullPointerException 을 위해 타입 체크를 컴파일 시점으로 옮깁니다.

컴파일러가 컴파일 시 오류를 미리 감지해서,

실행 시점에 발생 할 수 있는 예외의 가능성을 줄일 수 있습니다.

코틀린이 채택한 방식을 보면, 타입을 두 가지로 나눌 수 있습니다.

바로, 널이 될 수 있는 타입과 널이 될 수 없는 타입입니다.

Nullable types

코틀린 타입은 널이 될 수 있는 타입을 명시적으로 표시하게끔 지원합니다.

타입 뒤에 물음표를 명시하는 방식입니다.

Type? = Type or null (ex. String? , Int? , CustomType? )
Type = only Type

Null과 문자열을 인자로 받을 수 있게 하려면 타입 이름 뒤에 물음표(?)를 명시합니다 : String?

자바 코드와 함께 예시를 확인해봅시다.

Java

int strLen(String s) { 
    return s.length();
}

Java로 정의된 위 함수는, Kotlin에서는 아래와 동일합니다.

Kotlin

fun strLen(s: String?) = /* logic with null handling... */

Null을 허용하지 않는 경우와 비교해보겠습니다.

fun strLen(s: String) = s.length

strLen에 null이거나 널이 될 수 있는 값을 넘기려 할 경우,

컴파일 시 오류가 발생합니다.

strLen(null) // ERROR: Null can not be a value of a non-null type String

Type vs Type?

중요한 점은 널이 될 수 있는 값을, 널이 될 수 없는 타입에 대입할 수 없다는 것입니다.

엄격하게 다른 타입으로 구분됩니다.

val x: String? = null
var y: String = x
// ERROR: Type mismatch: inferred type is String? but String was expected

가령, 아래와 같은 함수를 정의한다고 해봅시다.

fun strLenSafe(s: String?) = s.length()

그럼, 다음과 같은 오류가 발생합니다.

ERROR: only safe (?.) or non-null asserted (!!.) calls are allowed on a nullable receiver of type kotlin.String?

Kotlin → Java

실제 Kotlin 를 Java 코드에 대응해보면 아래와 같이 변환됩니다.

아래 코드는 Kotlin → Bytecode → Java Decompile 한 형태입니다.

좌) Nullability Type 우) Type

사실, 실행 시점에 널이 될 수 있는 타입이나 널이 될 수 없는 타입의 객체는 같습니다.

컴파일 시점의 검사를 통해 둘을 구분합니다.

즉, 널이 될 수 있는 타입을 처리하는 데 별도의 실행 시점 부가 비용이 들지 않습니다.

Null Safety

코드를 작성하다 보면 널이 될 수 있는 타입을 널이 될 수 없는 타입의 객체를 변환해야 할 때가 많습니다.

코틀린은 null을 위한 특별한 연산자를 제공합니다.

아래의 특별한 네 개의 연산자와 let 함수, 그리고 lazyinit 키워드를 통해

null 값을 조작하는 방식을 알아보겠습니다.

- Safe call operator — ?.

- Elvis operator — ?:

- Safe casts — as?

- Not-null assertions — !!

- let function

- Late-initialized properties

Safe calls - `?.`

: nullability 변수가 null이 아닐 경우에만 이후 체인 호출

해당 연산자는 Type이 null이 아니라면, 해당 속성을 호출하고, null이라면 호출을 하지 않습니다.

val a = "Kotlin"
val b: String? = null
println(b?.length)
println(a?.length) // Unnecessary safe call

b가 null 이기 때문에 ?. 연산자는 length를 호출하지 않고,

a는 Nullability 변수가 아니기 때문에 kotlin comiler가 주의를 내보냅니다.

해당 연산자는 특히 연쇄 호출 (chain 호출) 시에 유용합니다.

예제를 통해 확인해보겠습니다.

Person는 Company를 포함하고, Company는 Address를 포함합니다.

주목할 점은, 두 속성 모두 Nullable하다는 것입니다.

class Address(val streetAddress: String, val zipCode: Int, val city: String, val country: String)

class Company(val name: String, val address: Address?) 

class Person(val name: String, val company: Company?)

위와 같은 클래스가 정의되어 있을 때,

Person 객체가 갖는 Company의 국가를 조회해본다고 해봅시다.

// Example #1
fun Person.countryName(): String { 
    val country = this.company?.address?.country      // ?. 연산자로 안전한 연쇄 호출
        return if (country != null) country else "Unknown"
}

이 때, Country를 null로 주게 되면 어떻게 진행될지 예상해보고,

아래 결과와 비교해보시길 바랍니다.

val person = Person("Dmitry", null)
println(person.countryName()) // Unknown

Elvis operator - `?:`

: null 대신 사용할 디폴트 값 지정

엘비스 연산자는 널 복합null coalescing 연산자라고도 합니다.

fun foo(s: String?) = s ?: "" // "s"가 null이면 결과는 빈 문자열

foo("abc")	// "abc"
foo(null)	// ""

다른 예시로, ?. 연산자에서 다룬 'Example #1' 함수를 다시 보도록 하겠습니다.

fun Person.countryName(): String { 
    val country = this.company?.address?.country
        return if (country != null) country else "Unknown"
}

위 함수에서 country가 null이면 "Unknown"을 반환합니다.

이를 엘비스 연산자를 통해 아래와 같이 단축할 수 있습니다.

fun Person.countryName() =
         this.company?.address?.country ?: "Unknown"

혹은, 함수의 전제 조건 pre-condition 을 검사하는 경우 특히 유용합니다.

fun printShippingLabel(person: Person) {
	val address = person.company?.address
    	?: throw IllegalArgumentException("No address") // 주소가 없으면 예외를 발생
	with(address) {
		println("$streetAddress \n$zipCode $city, $country")
	}
}

val address = Address("Elsestr. 47", 80687, "Munich", "Germany")
val jetbrains = Company("JetBrains", address)
val person = Person("Dmitry", jetbrains)

/*   Success Case   */
printShippingLabel(person)
// Elsestr. 47
// 80687 Munich, Germany

/*   Failure Case   */
printShippingLabel(Person("Alexey", null))
// java.lang.IllegalArgumentException: No address

Safe casts - `as?`

: 특정 값을 지정한 타입으로 캐스트하고, 변환할 수 없으면 null을 반환

대상 값을 as로 지정한 타입으로 바꿀 수 없으면 ClassCastException이 발생합니다.

as를 사용할 때마다 is를 통해 미리 as로 변환 가능한 타입인지 검사해볼 수도 있습니다.

가령, 아래 People 클래스의 equals 정의를 확힌해보면,

People 클래스와의 비교를 위한 코드를 확인할 수 있습니다.

class People(
    val firstName: String,
    val lastName: String) {

    override fun equals(o: Any?): Boolean {
        val other = o as? People ?: return false  // 타입이 일치하지 않으면 false 반환
        return other.firstName == firstName &&    // 안전한 캐스트 후, other이 Person 타입으로 스마트 캐스트
                    other.lastName == lastName
    }

    override fun hashCode(): Int
        = firstName.hashCode() * 37 + lastName.hashCode()
}

인자로 들어온 o 를 People 로 캐스트하고,

그 값이 없다면 null을 반환하기 때문에

엘비스 연산자를 통해 false를 반환합니다.

이 때, Kotlin의 스마트 캐스트 덕분에 아래에서 firstName을 그대로 불러올 수 있습니다.

스마트 캐스트가 아니었다면, Unresolved reference: firstName 를 발생시켰을 것입니다

Not-null assertions - `!!`

: 어떤 값이든 널이 될 수 없는 타입으로 (강제로) 변경 가능

근본적으로 !!는 컴파일러에게 "나는 이 값이 null이 아님을 잘 알고 있다. 내가 틀리면 예외가 발생해도 감수하겠다" 라고 말하는 것입니다.

즉, 널에 대해 !!를 적용하면 NPE가 발생합니다.

실제로 Kotlin 공식 페이지에서는 해당 연산자를 'The option is for NPE-lovers'로 소개합니다.

TMI.

일상 채팅에서 !! 표시는 종종 소리지르는 모습이거나 조금 떼쓰는 표시가 될 수 있죠.

코틀린 설계자들은 컴파일러가 검증할 수 없는 단언 말고,

더 나은 방법을 찾아보라고 !!라는 못생긴 기호를 택했다고 합니다.

!! 기호는 마치 컴파일러에게 소리를 지르는 것 같은 느낌이 든다. 사실 이는 의도한 것이다.
검증할 수 없는 단언 말고, 더 나은 방법을 찾아보라고 !! 라는 못생긴 기호를 택했다.

fun ignoreNulls(s: String?) {
	val sNotNull: String = s!!
	println(sNotNull.length)
}

결과는 다음과 같습니다.

ignoreNulls("not null!") // not null!
ignoreNulls(null) // Exception in thread "main" kotlin.KotlinNullPointerException

가장 주의할 점은, 아래와 같이 여러 !! 을 한 줄에 함께 쓰는 일을 피해야 합니다.

person.company!!.address!!.country

`let` function

: let 함수는 오직 null이 아닌 값에 대해서만 실행

Type?을 Type만 인자로 받는 함수에 넘기려면 어떻게 해야 할까요?

안전하지 않기 때문에 컴파일러는 해당 호출을 허용하지 않습니다.

이런 상황에서 도움이 될 수 있는 함수가 바로 let { ... } 입니다.

val listWithNulls: List<String?> = listOf("Kotlin", null, "Java")
for (item in listWithNulls) {
    item?.let { println(it) } // prints Kotlin, Java and ignores null
}

for 문의 Kotlin과 Java는 출력이 되지만, null에 대해서는 실행되지 않습니다.

fun sendEmailTo(email: String) { /*...*/ }

가령, 위와 같은 함수가 정의되어 있을 때, 아래와 같은 결과를 출력합니다.

// ① null이 아닌 경우 - let 함수 실행
var email: String? = "yole@example.com"
email?.let { sendEmailTo(it) }
// Sending email to yole@example.com

// ② null일 경우 - let 함수는 실행되지 않음
email = null
email?.let { sendEmailTo(it) }

Late-initialized properties

: lateinit 변경자로 정의한 프로퍼티는 늦은 초기화 허용

코틀린에서는 일반적으로 생성자에서 모든 프로퍼티를 초기화해야 합니다.

또, 타입이 널이 될 수 없는 타입이라면, 반드시 널이 아닌 값으로 해당 프로퍼티를 초기화해야 합니다.

초기화 값이 없다면 널이 될 수 있는 타입을 사용할 수 밖에 없는데,

널이 될 수 있는 타입을 사용하면 null 검사를 넣거나 !! 연산자를 써야 하는 문제가 또 생깁니다.

하지만, 실생활에서는 인스턴스 생성 후 초기화하는 프레임워크가 많습니다.

kotlin은 이런 "나중에 초기화하는 프로퍼티"를 위해 "lateinit" 키워드를 통해 초기화 시점을 늦출 수 있게 지원합니다.

당연한 얘기지만, 나중에 초기화하는 프로퍼티는 항상 var여야 합니다.

좌) !! 연산자 사용 우) lateinit으로 정의

만약, lateinit을 정의했지만, 값을 할당하지 않는다면 어떻게 될까요?

정답은, Compile에서 오류를 내기 때문에 실행 시점에서의 not-null을 보장할 수 있습니다.

class MyTest {
    private lateinit var myService: MyService

    fun setUp() {
        myService = MyService()
    }

    fun testAction() {
        Assert.assertEquals("foo", myService.performAction())
    }
}

val myTest = MyTest()
println(myTest.testAction()) // Compile Error
// UninitializedPropertyAccessException: lateinit property myService has not been initialized

Nullable receiver

: 널이 될 수 있는 타입도 확장 메서드를 가질 수 있음

String? 타입의 확장 메서드에는 isNullOrEmpty이나 isNullOrBlank 메소드가 있습니다.

즉, 널이 될 수 있는 수신 객체에 대해 호줄할 수 있는 메서드를 정의하고 사용할 수 있습니다.

kotlin-stdlib-common 에 포함된 Strings.kt 에는 String 확장 메서드들이 정의되어 있습니다.

그 중 하나인 isNullOrEmpty 메소드는 다음과 같이 정의되어 있습니다.

public inline fun CharSequence?.isNullOrEmpty(): Boolean {
    contract {
        returns(false) implies (this@isNullOrEmpty != null)
    }

    return this == null || this.length == 0
}

실제로, String? 타입에 대해 아래와 같이 사용할 수 있습니다.

fun verifyUserInput(input: String?) {
        if (input.isNullOrBlank()) {  // 따로 안전한 호출을 하지 않아도 됨
        println("Please fill in the required fields")
}

verifyUserlnput(" ")
// Please fill in the required fields

verifyUserlnput(null) // 예외가 발생하지 않음
// Please fill in the required fields

Nullability of type parameters

흔히 T로 정의되곤 하는 Type Parameter는 이름 끝에 물음표가 없더라도 T가 널이 될 수 있는 타입으로 간주됩니다.

fun <T> printHashCode(t: T) { 
    println(t?.hashCode())
}

제네릭 T는 Any? 타입으로 추론됩니다.

printHashCode(null) // 0

| Reference |

Kotlin in Action, Dmitry Jemerov and Svetlana Isakova

Kotlin Official - Null Safety

Hexagonal Architecture, 어렵지 않게 이해하기

gngsn — Thu, 3 Aug 2023 01:45:29 +0900

본 포스팅은 Hexagonal Architecture의 등장 배경과 개념을 이해하는 것을 목표로 합니다.

본 편 이후, Hexagonal Architecture를 Spring을 통해 실제로 구성하는 내용을 다룰 예정입니다.

Architecture

소프트웨어 개발은 복잡합니다.

생각 없이 코드를 작성하다 보면 서로 얽히고설킨 구조가 만들어지기 쉽죠.

하지만, 소프트웨어의 특성 상 비즈니스는 변경되기 쉽고, 코드 또한 변경되기 쉽습니다.

소프트웨어의 아키텍처를 아래의 순서에 따라 살펴 보도록 하겠습니다.

- Layered Architecture

- Clean Architecture

- Hexagonal Architecture

Layered Architecture은 Clean Architecture가 나오기까지의 과정을 소개하기 위해 담은 내용입니다.

바로 Hexagonal Architecture를 찾아보셔도 문제없이 읽으실 수 있습니다.

Layered Architecture

전통적인 아키텍처로는 계층형 아키텍처가 있습니다.

현재까지 많이 사용합니다.

계층형 아키텍처는 같은 목적의 코드들을 같은 계층으로 그룹화한 것으로, 역할과 관심사를 계층으로 분리합니다.

https://overcoded.dev/posts/Arch-14

✔️ Presentation Layer

: 사용자와의 상호 작용(UI)을 처리하는 계층

✔️ Domain Layer

= Business or Service Layer

: 서비스 및 시스템의 핵심 로직으로, 비즈니스 로직을 포함한 작업을 처리하는 계층

Presentation 계층에서 전달 받은 데이터의 유효성(Validation) 검사를 포함하고,

Persistence의 연결을 결정하여 사용합니다.

✔️ Persistence Layer

= Data Access Layer

: 영속성을 유지하기 위한 기능을 지원해 주는 소프트웨어 계층

데이터베이스에서 영구 데이터를 관리하도록 결정할 뿐만 아니라,

Message Queue 나 외부 API 통신 등을 처리합니다.

계층형 아키텍쳐는 각 계층의 관심사가 다른 계층으로 분리된 견고한 아키텍처 패턴입니다.
각 계층 별로 역할이 나뉜 “관심사의 분리 separation concern”를 요구하기 때문에,
각 계층의 역할을 수행할 수 있는데 집중하여 도메인 로직을 개발할 수 있습니다.

하지만, 개발자들이 계층형 아키텍쳐를 기반한 개발을 진행해 오면서,

몇 가지의 문제점들을 발견하게 됩니다.

대표적인 두 가지 문제점을 살펴보겠습니다.

✔️ 영속성 계층의 변경에 반응하는 도메인 객체

계층형 아키텍쳐의 구조적 특징을 살펴보면,

Presentation 계층은 Domain 계층에 의존하고, Domain 계층은 Persistence 계층에 의존합니다.

때문에 자연스레 데이터에 의존하게 됩니다.

그렇게 모든 것이 영속성 계층을 토대로 만들어지는 데이터베이스 주도 설계를 따르게 됩니다.

이렇게 데이터베이스 주도 설계를 하게 되면,

설계를 시작하는 처음부터 데이터를 결정하도록 강요하기 때문에

너무 이른 시기에 내부 구현에 초점을 맞추게 됩니다.

캡슐화를 위반하지 않기 위해서는 협력을 우선하여 생각해야 하고, 협력에 초점을 맞춰야만 응집도가 높고 결합도가 낮은 객체들을 창조할 수 있으며 훌륭한 책임을 수확할 수 있다. 그러니, 상태가 우선이 아니라 행동이 우선이다.

- 오브젝트

✔️ 흩어지기 쉬운 도메인 로직

계층형 아키텍처에서는 도메인 로직이 여러 계층에 걸쳐 흩어지기 쉽습니다.

로직이 간단하다는 이유로 도메인 계층을 생략한다면 웹 계층에 존재할 수도 있고,

특정 컴포넌트를 도메인 계층과 영속성 계층 모두에서 접근할 수 있도록 아래 계층으로 내린다면 영속성 계층에 존재할 수도 있습니다.

이는 계층을 분리하는 규칙 외에 다른 규칙을 강제하지 않아서,

대충 하려는 개발자들의 코드가 '깨진 창문 이론'처럼 번져가게 된다는 것을 보여줍니다.

또, 한 서비스에 다양한 기능을 하는 로직들을 담는 문제를 야기하며,

이를 넓은 서비스 문제라고 부릅니다.

이 밖에도 테스트하기 어려워진다는 점도 있습니다.

이러한 계층형 아키텍처의 문제점들을 보완하고자,

개발자들은 새로운 아키텍처를 찾는 시도들을 합니다.

Clean Architecture

Clean Architecture는 Robert C. Martin이 'Clean Architecture' 책에서 처음 소개한 개념입니다.

Robert C. Martin은 클린 아키텍처 설계가 비즈니스 규칙의 테스트를 용이하게 하고,

*외부 애플리케이션이나 인터페이스로부터 비즈니스 규칙이 독립적일 수 있다고 주장합니다.

* Framework, Database, UI 등

클린 아키텍처에서의 핵심 규칙은 도메인 코드가 바깥으로 향하는 어떤 의존성도 없어야 한다는 것입니다.

의존성 역전 원칙의 도움으로 계층 간의 모든 의존성이 코어 안쪽으로 향하게 해야 합니다.

이로써 비즈니스 규칙을 담는 도메인 코드, 즉, 엔티티는

어떤 영속성 프레임워크나 UI 프레임워크가 사용되는지 알 수 없기 때문에,

특정 프레임워크에 특화된 코드를 가질 수 없고 비즈니스 규칙에 집중할 수 있습니다.

생각해 볼 점은, 도메인 모델이 외부 계층과 분리돼야 하기 때문에
애플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수해야 합니다.

가령, ORM(Object-relational mapping) 프레임워크를 사용한다고 했다고 한다며,
도메인 계층에서는 ORM을 사용한다는 것을 모릅니다. 영속성 계층을 모르기 때문이죠.
때문에, ORM을 위한 'Entity 객체'를 '도메인 객체'와 따로 생성해야 합니다.

하지만, 다시 생각해보면 이는 바람직한 분리입니다.
도메인 코드를 특정 프레임워크에 한정된 문제로부터 파생되는 의존성을 제거된 상태로 만들기 때문입니다.

가령, JPA은 엔티티에게 기본 생성자 생성을 강제하며, 이는 JPA 프레임워크가 만드는 의존성입니다.

유스케이스는 전통적인 아키텍처에서 서비스로 불렸던 로직을 담지만, *단일 책임을 갖기 위해 조금 더 세분화됩니다.

서비스 로직이 불필요하게 커지는 문제 해결합니다.

*단일 책임: 변경할 단 한 가지의 이유

하지만, Clean Architecture는 하나의 추상적인 아키텍처 이론이기 때문에,

바로 현업에 적용하기란 쉽지 않습니다.

~~이를 위해, Clean Architecture의 원칙들을 조금 더 구체적으로 구현하는~~

~~'육각형 아키텍처 Hexagonal Architecture'가 등장합니다. (댓글 참고)~~

그래서 Clean Architecture 을 구현할 수 있는 다른 이론을 모색해보자면,

Hexagonal Architecture 를 참고할 수 있습니다.

Hexagonal Architecture

헥사고날 아키텍처 Hexagonal Architecture는 클린 아키텍처를 구현하는 가장 대표적인 모델입니다.

Alistair Cockburn가 Hexagonal Architecture 용어를 만들었으며, 그의 블로그에서 소개되었습니다.

Netflix Medium Blog - "Ready for changes with Hexagonal Architecture"

육각형 안에는 도메인 엔티티와 이와 상호작용하는 유스케이스가 위치합니다.

육각형 바깥에는 애플리케이션과 상호작용하는 다양한 어댑터들이 위치합니다.

가령, 웹이나 데이터베이스 등 외부 시스템과 상호작용하는 어댑터들이 위치할 수 있습니다.

또, 애플리케이션 코어가 각각의 포트를 제공해야 하는데,

이는 애플리케이션 코어와 어댑터들 간의 통신을 위함입니다.

이러한 구조로 인해 '포트와 어댑터 (ports-and-adapters)' 아키텍처로도 알려져 있습니다.

Netflix에서 작성한 헥사고날 아키텍처의 설명이 이해를 더해줍니다.

The idea of Hexagonal Architecture is to put inputs and outputs at the edges of our design. Business logic should not depend on whether we expose a REST or a GraphQL API, and it should not depend on where we get data from — a database, a microservice API exposed via gRPC or REST, or just a simple CSV file.

- Netflix Technology Blog

정리해보면 아래와 같습니다.

헥사고날 아키텍처의 아이디어는 입력과 출력을 설계의 가장자리에 배치하는 것입니다.

비즈니스 로직은 REST 또는 GraphQL API를 노출시키는지 여부에 의존해서는 안됩니다.

마찬가지로, 데이터베이스나 API 또는 단순한 CSV 파일과 같은 데이터를 어디에서 가져오는지에 의존해서는 안 됩니다.

즉, 비즈니스 로직을 설계의 중심으로 하면서,

노출시키는 영역(outputs)과 데이터를 가져오는 영역(inputs)에 의존하지 않는 디자인을 의미입니다.

이런 설계가 갖는 이점이 무엇일까요?

Benefits

✔️ 유연성 Flexibility

포트와 어댑터를 사용함으로써, 다양한 기술 변화에 대응할 준비가 되어 있습니다.

빠르게 기술이 변화되고 있는 현재, 더 나은 기술의 활용은 더 이상 선택이 아닌 필수로 볼 수 있습니다.

이러한 유연성은 변경에 용이한 소프트웨어의 이점을 잘 나타냅니다.

✔️ 유지보수성 Maintainability

책임이 분리되어 있어, 코드의 이해와 수정이 용이하며, 변화에 빠르게 대응할 수 있습니다.

기존 기능을 다른 기술로 변경하고자 할 때, 새로운 어댑터 만으로 추가할 수 있습니다.

✔️ 테스트 용이성 Testability

각 컴포넌트를 독립적으로 테스트할 수 있을 뿐만 아니라, 외부 의존성 없이 테스트할 수 있습니다.

이를 통해 품질 향상과 개발 속도 향상에 도움이 됩니다.

Is it worth the effort?

사실 Hexagonal Architecture를 도입하는 건, 그만큼의 노력이 필요합니다.

웹 어댑터에 도메인 구현 모델이 있고 데이터베이스 어댑터에 또 다른 도메인 모델 표현이 있을 수 있습니다.

결국, 포트 인터페이스를 만들고, 여러 도메인 모델 구현체 사이에 매핑할 필요가 생길 수도 있습니다.

뿐만 아니라, 팀원들과의 의견을 조율하는 과정 또한 중요한 관건입니다.

그렇다면, Hexagonal Architecture을 도입하는 것이 과연 가치가 있을까요?
이에 대한 대답은 "상황에 따라 다르다" 입니다.

단순히 데이터를 저장하는 간단한 CRUD 애플리케이션을 만들고 있다면, 아마 오버헤드일 것입니다.

혹은 상태와 행동으로 가득 찬 도메인 모델로 표현할 수 있는 비즈니스 규칙을 따르는 애플리케이션을 만들고 있다면, 해당 아키텍처는 빛을 발할 수 있습니다.

Hexagonal Architecture

Layers

클린 아키텍처와 동일하게 Hexagonal Architecture도 계층으로 구성할 수 있습니다.

가장 안쪽 계층에는 도메인 엔티티 위치시키고, - Domain Layer

중간 계층에는 포트와 유스케이스 구현체를 결합해서 애플리케이션 계층 구성시키고, - Application Layer: Port & Usecase

두 개 모두 인터페이스를 정의하기 때문에 결합시킵니다.

가장 바깥쪽 계층에는 애플리케이션과 다른 시스템 간의 번역을 담당하는 어댑터를 위치시킵니다. - Adapter Layer

이를 정의하는 Domain, Port, Usecase, Adapter를 각각 자세히 살펴보겠습니다.

예시 코드는 Get Your Hands Dirty on Clean Architecture (Github) 책을 참고했습니다.

Domain

: 실세계에서 사건이 발생하는 집합의 모델링

소프트웨어를 통해 해결하기 원하는 핵심 문제를 설명하는 요소를 나타냅니다.
중요한 비즈니스 데이터와 규칙에 관련된 엔티티들로 채워집니다.
도메인 개체는 상태와 동작을 모두 포함할 수 있습니다.

도메인 개체는 바깥으로 향하는 어떤 의존성도 없어야 합니다.
순수한 자바이며 사용 사례에서 작동할 수 있는 API를 제공합니다.

도메인 개체는 다른 계층에 종속성이 없기 때문에 다른 계층에서의 변경에 영향을 받지 않습니다.

이는 "클래스는 단 한 개의 책임을 가져야 한다"의 의미를 가진

SOLID의 단일 책임 원칙 (SRP, Single Responsibility Principle)의 대표적인 예시가 됩니다.

객체는 오직 하나의 변경의 이유 만을 가져야 하며,

도메인 개체의 경우 유일한 변경의 이유는 비즈니스 요구 사항의 변경이 됩니다.

개발하는 동안 종속성의 흐름을 따라,

도메인 객체에서 코딩을 시작하고 육각형 모델에 맞춰 바깥으로 개발해 나아갑니다.

도메인 계층 내에는 Entity와 Value Object가 포함될 수 있습니다.

예를 들어, 은행 애플리케이션의 "다른 계정으로 돈 보내기"을 구현한다고 해봅시다.

아래는 Account를 모델링한 도메인의 예시입니다.

public record Account(
    @Getter AccountId id,
    @Getter ActivityWindow activityWindow,
    Money baselineBalance
) {

    public Money calculateBalance() {
        return Money.add(
                this.baselineBalance,
                this.activityWindow.calculateBalance(this.id));
    }

    public boolean withdraw(Money money, AccountId targetAccountId) {
        if (!mayWithdraw(money)) {
            return false;
        }

        Activity withdrawal = new Activity(
                this.id,
                this.id,
                targetAccountId,
                LocalDateTime.now(),
                money);
        this.activityWindow.addActivity(withdrawal);
        return true;
    }

    private boolean mayWithdraw(Money money) {
        return Money.add(
                        this.calculateBalance(),
                        money.negate())
                .isPositiveOrZero();
    }
    
    public boolean deposit(Money money, AccountId sourceAccountId) {
        Activity deposit = new Activity(
                this.id,
                sourceAccountId,
                this.id,
                LocalDateTime.now(),
                money);
        this.activityWindow.addActivity(deposit);
        return true;
    }
}

Usecase

: 소프트웨어 동작을 추상화하여, 소프트웨어가 무엇을 하는지를 설명하는 역할을 합니다.

예를 들어, 은행 애플리케이션의 "다른 계정으로 돈 보내기"를 하나의 사용 사례라고 가정해 보겠습니다.

사용자가 돈을 송금할 API로 SendMoneyUseCase 클래스를 만듭니다.

이때, 송금 시 필요한 비즈니스 규칙 검증 및 논리를 Usecase의 구현체에 정의할 수 있습니다.

가령, 입력 값을 확인한다거나 계좌 번호를 확인하는 로직을 도메인에 구현할 수 없기 때문입니다.

도메인 객체와 유사하게 Usecase는 외부 구성 요소에 의존하지 않습니다.

육각형 외부에서 무언가가 필요할 때에는 출력 포트를 만듭니다.

public interface SendMoneyUseCase {
    boolean sendMoney(SendMoneyCommand command);
}

public class SendMoneyService implements SendMoneyUseCase {
	// ...
}

Port

도메인 객체와 Usecase는 육각형 내에 있으며, 즉 애플리케이션의 핵심 내에 있습니다.

이때 외부와의 모든 통신은 전용 "Port"를 통해 이루어집니다.

Input과 Output Port로 시스템에 들어오고 나가는 위치가 매우 명확하기 때문에,

아키텍처를 쉽게 추론할 수 있어 코드를 이해하는 데 큰 도움이 됩니다.

✔️ Input Port

입력 포트는 외부 구성 요소에 의해 호출될 수 있고, Usecase에 의해 구현되는 인터페이스입니다.
입력 포트를 호출하는 구성 요소를 입력 어댑터 또는 "driving" adapter라고 합니다.

✔️ Output Port

출력 포트는 데이터베이스와 같이 외부에서 필요한 것이 있을 경우 Usecase에서 호출할 수 있는 인터페이스입니다.

이 인터페이스는 Usecase의 요구에 맞게 설계되지만, output adapter 또는 "driven" adapter라는 외부 구성 요소로 구현됩니다.

인터페이스를 사용하여 Usecase에서 Output Adapter로 종속성을 뒤집기 때문에,

SOLID의 DIP(Dependency Inversion Principle)가 적용된 것을 확인할 수 있습니다.

public interface LoadAccountPort {
    Account loadAccount(AccountId accountId, LocalDateTime baselineDate);
}

public record AccountPersistenceAdapter(
        AccountRepository accountRepository,
        ActivityRepository activityRepository,
        AccountMapper accountMapper
) implements LoadAccountPort, UpdateAccountStatePort {
	// ...
}

Adapter

외부 인터페이스 제공하며, 애플리케이션 기능의 노출 방법을 결정합니다.

소프트웨어와 통신할 수 있는 기술을 결정합니다.

Adapter는 육각형 구조의 외부 층에 위치하여, 코어와 상호 작용합니다.

어댑터를 사용하면 애플리케이션의 특정 계층을 쉽게 교체할 수 있습니다.

예를 들어, 애플리케이션에 다른 데이터베이스가 필요한 경우,

이전 데이터베이스와 동일한 출력 포트 인터페이스를 구현하는 새로운 rsistence 어댑터를 추가합니다.

✔️ Driving Adapter

= Input adapter.

애플리케이션 코어를 호출하며, 애플리케이션을 주도하는 어댑터입니다.

코드 상으로는, 코어에 있는 유스케이스 클래스들에 의해 구현 및 호출되는 인터페이스가 될 수 있습니다.

Driving Adapter는 특정된 목표를 수행하기 위해 입력 포트를 호출합니다.

가령, Driving Adapter는 웹 인터페이스가 될 수 있습니다.

사용자가 브라우저에서 버튼을 클릭하면, 웹 어댑터는 특정 입력 포트를 호출하여 해당 사용 사례를 호출합니다.

@WebAdapter
@RestController
class SendMoneyController {
	// ...
}

✔️ Driven Adapter

= Output adapter.

Driven Adapter는 Usecase에 의해 호출됩니다.

출력 어댑터는 Output Port 인터페이스 집합을 구현합니다.

가령, 데이터베이스로 부터 애플리케이션으로 데이터를 제공할 수 있습니다.

혹은 File에서 외부 데이터를 읽기 위해 txt 파일에 접근해 출력 포트를 구현할 수도 있습니다.

@PersistenceAdapter
class AccountPersistenceAdapter implements LoadAccountPort, UpdateAccountStatePort {
        // ...
}

| Reference |

Netflix Medium Blog - Ready for Changes with Hexagonal Architecture

Reflectoring - Spring Hexagonal

Github - buckpal

만들면서 배우는 클린 아키텍처 - 톰 홈버그

2023년 상반기 회고

gngsn — Sat, 8 Jul 2023 01:41:51 +0900

2023년 상반기 돌아보기

2022년 회고록을 많은 분들이 봐주었고,

감사하게도 긍정적인 자극을 받았다는 후기를 건네주셨다.

덕분에 꾸준히 더 잘 살아봐야겠다는 의지를 가질 수 있었다.

선순환을 만들어가는 작은 시작이었으면 한다.

많은 변화가 있어서 그런지 6개월을 보내는 동안 긴 시간처럼 느껴졌다.

막상 회고를 적을 시간이 다가오니,

그저 짧은 6개월이었다는 것을 막연히 느낄 뿐이다.

“벌써, 일 년의 반이 지났다”

시간은 나도 모르는 사이 훌쩍 지나간다.

나도 모르는 새 지나간 시간들을 생각해 보고 종종 놀라곤 한다.

"10년 금방이다"라는 말을 종종 듣곤 한다.

아직 내가 체감하지 못한,

더 큰 시간의 단위가 나도 모르는 새 지나갈 것임을 암시한다.

과거에 길다고만 생각했던 일 년이,

이젠 과거만큼이나 긴 시간으로 느껴지지 않는 것처럼 말이다.

그래서 항상 생각한다.

빠른 시간을 보낸 것처럼 느껴질 이 시간을 어떻게 채워나갈까.

그래서인지, 본인에게 시간은 굉장히 소중하다.

크던 작던, 그 시간을 오롯이 나의 결정으로 채워지도록 한다.

빠르게 지나온 시간을 훑어봤을 때, 지나온 동안의 나를 뿌듯해 할 수 있도록 말이다.

마치 응축된 것만 같은 시간에 나의 업적들을 빼곡히 기록하는 것이다.

흘러가는 시간을

그냥 흘러가게 두지 말자.

이번 해 상반기에도 정말 큰 변화들이 있었다.

성장을 위한 변화의 의지가 큰 덕분에

주변 환경이 실제로 빠르게 변화해 가는 것 같다.

상반기 회고는 가볍게 쓰고자 한다.

그리고 그 키워드를 AWS 자격증, 이직, 그리고 언어로 삼고자 한다.

1/ AWS 자격증

2022년을 마무리하며 작성한 회고글의 KTP 중 Try에 아래와 같은 목표를 다짐했다.

AWS 자격증을 취득하자.

목표를 이루고자 AWS 자격증 시험을 5월로 목표 삼았다.

자격증 시험이 직전으로 다가온 4월은 정신없이 몰입했다.

집중을 벗어나고 싶지 않아서 새벽까지 멈추지 않았다.

그러다 보니 주말엔 밤새 공부하는 게 익숙해졌다.

토요일로 넘어가는 밤, 밤새 공부하는 것을 즐겼다.

결론적으로, SAA 시험에 합격했고 자격증을 취득했다.

AWS 자격증을 목표로 한 이유는,

컴퓨팅 기술의 전반적인 개념과 우수 사례들을 공부하고 싶었기 때문이다.

AWS는 VPC와 Subnet, Load Balancing, Database, Container까지 다양한 기술들을 제공한다.

해당 서비스를 공부함으로써

해당 기술의 등장 배경과 필요한 이유를 알아갈 수 있고,

발생할 수 있는 특정 문제의 해결 사고 방식을 엿볼 수 있다.

다시 말해, 실제 벌어지고 있는 일에 대한 감각을 키우는 것을 기대했다.

많은 시간에 걸쳐온 성능 개선을 위한 생각과 해결론이 담겼다.

이를 공부하는 가치가 시간 대비 능력을 키우기에 큰 역할을 해줄 것이라 확신했다.

공부하는 동안 큰 호기심을 느꼈고,

마치 게임 캐릭터에게 스킬을 적용하는 것처럼 공부하며 몰입할 수 있었다.

“어느샌가, 노력이 운처럼 다가올 때”

운을 잘 믿지 않는다.

내가 아는 내용들로 가득한 시험지.

유난히 컨디션이 너무 좋은 시험 당일.

대부분이 정답이었던 찍은 문제들.

믿지 않는다. 본인에게 일어난 적도 거의 없을뿐더러 불명확하다.

주관적인 생각으로, 본인은 운이 좋은 사람은 아니다.

그래서 많은 노력이 필요하다고 생각했다.

예전에는 본인의 기대보다 부족한 것들이 운이 부족해 일어나는 일들이라고 생각했다.

"더 좋은 머리를 갖고 태어나면 좋았을 텐데" 하며 말이다.

그래서 못난 부분들을 위해 노력하기로 했다.

고등학생 때, 운없이 나쁜 머리를 가지고 태어났다고 생각했다.

"난 왜 이렇게 머리가 나쁠까."

다른 사람보다 더 큰 노력을 하면 된다고 생각했다.

남들이 1시간 할 때, 본인은 2시간 혹은 그 이상을 한다는 것을 항상 염두했다.

중학생 때, "그림 그리는 게 좋은데, 내놓기 민망한 그림 실력을 가졌네"

수없이 그림을 그리고, 그리고, 지우고, 또다시 그렸다.

거의 다 그렸다가도 마음에 안 들어 다시 시작했다.

대학생 때, "난 진짜 발표는 못하겠다. 남들 앞에서 말하다 울 것 같아"

준비된 사람이 떨지 않는다고 한다.

발표할 수 있는 모든 기회에 도전했고, 모든 스크립트를 달달 외우고 발표했다.

3년 전, "난 왜 이렇게 글을 못쓸까".

불평은 아무것도 만들지 않는다.

글을 많이 쓰면 늘겠지. 기술 포스팅을 쓰기 시작했다.

그렇게 노력이 습관이 됐다.

종종 주변 분들께 과분한 친창을 받곤 한다.

긴장 없이 발표를 잘하는 사람, 타고난 그림 실력을 가지고 태어난 사람, 글을 잘 쓰는 사람.

타고난 운과 상관없이, 내가 만들어온 '노력'이 본모습을 숨긴 채 '운'으로 다가왔다.

내가 이뤄온 줄도 모르게, 꽤 많은 것들을 만들어 왔다.

노력이 운처럼 다가오도록 만들어가보자.

긍정적인 사람은 운을 기대하는 사람이 아니다,

어떤 결과든 그 결과를 순응할 줄 아는 사람이다.

2/ 이직

퇴사를 했다.

개인적인 이유로 이직을 목표로 했다.

이직을 하며 바라는 점 단 한 가지는 "성장할 수 있는 환경"이었다.

활발한 개발 문화, 도전적인 과제를 요구하는 업무.

숨 막히게 정신없는 시간들이었다.

5월 초 AWS 자격증 취득을 시작으로, 포트폴리오와 이력서를 정리하기 시작했다.

링크드인에 정보들을 업데이트했다.

메신저를 통해 외국계 회사에서 연락을 받았고, 영어 인터뷰도 경험해 봤다.

Resume를 작성하기도 했다. 분명 좋은 경험이었다.

높게 평가해 주는 분들 덕에, 그동안의 노력들을 체감할 수 있었다.

과제도 보고, 면접도 준비했다.

Objects책을 공부하고 있었는데 과제를 하며 이를 적용해 보기 좋았다.

결론적으로, 가고 싶던 국내 기업에 합격하여 이번 달 말쯤 합류하게 되었다.

개발 문화뿐만 아니라 뛰어난 인재가 많다고 들었기 때문에 큰 기대가 된다.

동시에, 곧 만나게 될 새로운 팀원들의 기대에 부합하도록,

혹은 그 이상이 되게끔 노력해 나아가고자 한다.

“ 삶을 의미 있게 만들 자유 ”

이번 해 초, Victor Frankl의 ≪죽음의 수용소≫ 를 읽었다.

빅터 플랭클(이하 빅터)은 제2차 세계대전 때,

악명 높은 아우슈비츠 수용소를 3년 간 경험했다.

정신과 의사였던 빅터는 수용소 내에서 삶의 이유를 탐구하였고,

인간 본연의 의미를 찾아가는 것의 중요성을 제시한다.

“삶을 의미 있고 목적 있는 것으로 만드는 것,
이것이 바로 빼앗기지 않는 영혼의 자유다.”

빅터를 포함한 몇 수감자들은

굶주린 상황에서 무자비한 폭력과 극심한 노동으로,

아무리 화가 나도 인간으로서의 도리를 지켜냈다.

그렇지 못한 대부분의 사람들은 인육을 먹고 서로를 해치며,

그들의 삶을 비극으로 만들어갔다고 말한다.

빅터가 그의 정신을 붙잡을 수 있던 것은,

정신적으로나 영적으로 어떤 사람이 될 것인가는

본인이 선택할 수 있다는 것이 그의 가치관이었기 때문이다.

똑같이 척박한 환경에서,

그들의 정신이 그들의 삶의 의미를 다르게 만든다는 의미다.

빅터는 본인이 제창한 Logotherapy를 소개하며,

인생의 목표와 의미를 만들어가는 과정으로 그 인생이 가치 있다고 주장한다.

Logotherapy는 인간이 자신의 삶에서 어떤 의미를 찾고자 하는 노력을 "인간의 원초적 동력"으로 본다.

그는 인생의 의미를 갖게 만드는 것의 중요성을 강조한다.

일을 하며 본인의 가치를 찾거나,

다른 사람과의 관계를 통한 가치를 찾거나,

혹은 큰 어려움을 극복하며 본인의 가치를 깨닫게 하는 방법들이 있다.

본인은 항상 인정과 명예를 바라왔던 것 같다.

스스로를 발전시켜 여러 곳에서 필요하게끔 만들고 싶었다.

많은 사람들이 인정할 만큼 나의 가치를 올리는 것을 서슴지 않았다.

이 것이 빅터가 말하는 본인 가치의 의미를 찾는 과정이었을지도 모른다.

스스로의 가치를 높이려는 의도가 바로 노력의 동력이 되어 온 것이 아닐까.

나의 삶의 의미를 찾고자 하면, 그에 대한 동력을 키울 수 있다.

나의 가치를 올리는 노력이, 나의 열정의 동력이 되어 온 것처럼 말이다.

이렇게 내 인생에 책임을 갖고, 기대를 갖고, 희망을 갖고 사는 것이

단 한 인생을 살아가는 본인에게 줄 수 있는 큰 선물 아닐까 싶다.

3/ 언어

일 년 전, 세상이 너무 좁게 느껴졌다.

지식의 벽, 언어의 벽, 견문의 벽.

정확히 무엇이 내 세상을 넓혀줄지 모르겠지만,

일단 많은 경험을 해봐야겠다는 생각을 했다.

지난해 회고에서 아래와 같은 목표를 다짐했다.

영어를 사용할 수밖에 없는 환경이 필요하다.
영어를 사용할 수 있는 환경을 만들어서 익숙해지자.

그리고, 언어 교환을 가기로 마음먹었다.

가는 내내 긴장과 무서움, 그리고 부담감이 휩쓸었다.

모든 변명을 생각했다.

"한국에서도 편하게 살 수 있는데, 굳이 이렇게 부담 가질 필요가 있을까"

"영어 공부를 제대로 더 한 뒤에 유창해지면 갈까"

피하고 싶었다.

다시 스스로를 독려했다.

"내가 시도할 수 있는 가장 어린 시기에 도전해 보자."

"지금의 걱정을 다음으로 미루지 말자, 괜히 이 감정을 똑같이 겪을 필요가 없다."

그리곤 언어교환 모임 장소로 들어갔다.

먼저 다가가지도 못했고, 먼저 입을 떼기는 더 어려웠다.

식은땀도 나고, 도망치고 싶은 감정이 절정에 달랐다.

다시 한번 스스로를 독려했다.

"내가 여기서 가장 배워갈 수 있는 게 많다."

영어를 배우는 과정에서 유창할 수 없는 건 당연하다.

곧 나의 부족함을 인정했고, 점점 긴장은 풀려갔다.

가장 미숙하다는 핑계를 대고, 오히려 즐기고자 노력했다.

매번 긴장했고, 매번 주저했고, 매번 변명했다.

그래도, 매번 스스로를 그 환경 속으로 던졌다.

하루도 빠짐없이 조금이라도 연습하려고 갔다.

점점 긴장이 많이 누그러졌다.

다양한 친구를 사귈 수 있었고,

쉽게 경험하지 못할 커다란 추억을 남기고 있다.

그들 덕분에 많은 생각을 넓힐 수도 있었다.

누구와도 소통할 자신감을 키워가고 있고,

혼자 여행할 용기가 있으며,

무엇이든 받아들일 수 있는 마음이 있다.

더 이상 내 세상은 작지 않다.

“엄격함, 그리고 격려”

1월부터 스피킹에 온전히 집중했다.

영작을 처음 시작했을 때보다 더욱 큰 어려움을 겪었다.

글을 쓰는 것과 말을 하는 것은 완전히 별개였다.

본인은 스스로에게 엄격하다.

스스로를 채찍질하고 무능함을 타박하며 될 때까지 만들어가는 것이다.

그러다 4월로 넘어갈 때쯤, 언어 교환에서 프랑스에서 온 친구를 만났다.

그 친구는 나의 영어 자신감이 부족하다는 것을 안다.

그 친구는 한국을 떠나기 전, 밥을 같이 먹자며 연락했다.

떨리고 부담됐다.

"내 부족한 영어가 점점 답답하다고 느끼면 어쩌지,

나 때문에 분위기를 망칠 것 같은데.."

우리는 만났고, 우려했던 상황은 전혀 나오지 않았다.

영어가 막힐 때마다 오히려 그 친구가 도와줬다.

한 번은 말문이 막혀 미안해하는 나를 보며

그 친구가 입을 열었다.

"When you started studying for speaking in January,
did you even imagine that you would have dinner

with a French who can only speak English?"

그 친구는 사려 깊었다.

그 친구는 내게 필요한 말이 무엇인지 알고 있었다.

내가 옳은 방향으로 가고 있음을 확인시켜 주었다.

본인은, 스스로의 부족함을 인정하는 것은 쉽다.

하지만 본인의 발전을 인정하는 것이 어려웠다.

자만심 같았고, 더 높은 목표만을 좇았다.

현재 본인에게 안일할 것 같아 인정하지 않았다.

성장을 위한 엄격함과 스스로를 위한 인정과 격려,

이 둘을 조절하는 것은 항상 어렵다.

무엇이 적절한 방향일지, 저울질하며 관찰 중이다.

다만, 나의 방향에 확실함을 가지고 멈추지 말자.

그 친구는 2개월 뒤에 다시 한국을 방문했고,

우리는 다시 만나, 다시 한번 추억을 만들었다.

잘하고 있다.

그러니 멈추지 말자.

2023년 하반기 목표

# 새로운 환경에 적응

하반기에는 새로 합류할 회사에 대해 적응하는 것을 우선순위로 잡을 예정이다.

인터뷰를 통해 본인을 어떻게 봐주셨을지는 모르겠지만,

팀원 분들이 생각하는 것만큼, 혹은 그 이상의 성과를 내고 싶다.

실력이 부족하다면 키워질 때까지 노력하자.

실수를 했다면 실수를 하지 않을 때만큼 실력을 쌓고 반복하자.

본인의 나이는 아직 어리다.

1년 만해도 본인에게는 큰 성장의 기회가 된다.

할 수 있는 게 많고, 배우고자 하는 의지와 열정이 있다.

얼마큼 성장할지 기대되는 사람이 되자.

# 책 읽기

구독 모델을 절대 사용하지 않던 본인이

최근에 두 개의 구독 제품을 결제했다.

하나는 Medium이고,

하나는 밀리의 서재이다.

책을 읽는 것은 온전히 본인의 인생을 위한 선물이다.

'배움'의 선물보다 값진 것은 없다.

한 인사이트 영상을 본 적이 있다.

노년의 여성에게 어릴 때로 돌아간다면 하고 싶은 일에 대해 인터뷰하는 영상이다.

여성은 "더 많이 배우는 것"이라고 말한다.

인생은 배워감의 연속이며,

많은 것들을 배우고 살아가는 것이 전부라고 한다.

단 한 인생을 살아가며, 내가 살아가는 세상을 알아가는 것은 꽤나 의미 있다.

많은 것들을 배우면 그만큼 더 많은 것들을 보고, 느끼고, 인식할 수 있다.

일상의 것들도 새로운 것을 배움으로써 달리 보일 수 있다.

그래서 배우는 것을 즐기나 보다.

세상이 다르게 보인다.

나를 위해 책을 꾸준히 읽자.

# 계속해서 도전하자

실패를 바라보는 시선은 두 개로 가져갈 필요가 있다.

실패를 무서워하지 말아야 하고, 동시에 무서워해야 한다.

도전은 시작은 단순하다.

실패를 무서워말고, 도전을 주저하지 말아야 한다.

실패를 무서워하고, 긴장감을 가지고 가야 한다.

실패할 수 있다는 것에 어느 정도의 두려움을 가지고 시작하면 이 긴장감을 잘 활용할 수 있다.

긴장하고 시작하라, 또 실패를 인정하고 받아들여라.

기회가 닿기를 기다리지만 말고, 기회가 올 환경을 만들자.

# 영어 공부

새로운 영어 코칭을 시작했다.

프라이빗 코칭으로, 엄청난 인연으로 만났다.

링크드인으로 소수만 진행되는 프라이빗 코칭을 제안받았다.

아주 자세한 내용을 건네주었고, 확실히 믿을 만한 배경을 가지고 있었다.

그래서 일단 한 번 만나보자는 생각으로 강남에서 만났다.

미팅은 성공적이었다.

선생님의 열정을 어렵지 않게 볼 수 있었고,

본인이 찾던 과정을 통해 영어를 배울 수 있는 과정이었다.

그렇게 함께 하기를 약속한 후, 서로에 대해 이야기를 나눴다.

그런데 알고 보니 선생님이 현재 거주하는 집과 2분 거리 채 안 되는 곳에 살고 있었다.

자주 가는 스타벅스에 종종 보던 외국인이 바로 그분이었던 것이다.

덕분에 수업이 아니더라도, 집 앞에서 종종 만나 밥을 먹거나 카페를 가곤 한다.

현재는 선생님이 미국으로 잠시 가 있기 때문에,

선생님이 키우는 새들을 돌봐주러 선생님 집에 가고 있다.

정말 믿기지 않는 인연이다.

하반기에는 이를 통해 영어 공부를 지속하고자 한다.

또, 외국에서 온 친구들과의 인연을 꾸준히 이어가고자 한다.

이전에는 영어를 목적으로 사귀었다면,

이제는 친구들과 함께 하기 위해 영어를 배우고 있다.

좋은 사람들을 만났다. 쉽게 끊고 싶지 않은 인연이다.

# 운동을 꾸준히 하자

역시나 빠질 수 없는 목표다.

상반기에도 꾸준히 운동을 해왔다.

처음 운동을 시작한 이유는 한창 개발에만 몰두할 때, 내 몸을 위해 나에게 주는 선물이었다.

이번엔 헬스가 아닌 다른 운동을 찾아볼 시기가 온 것 같다.

만약, 기회가 된다면 새로운 운동을 시작할 기회를 엿봐야겠다.

JDK 11 ~ 17 Release, 제대로 이해하기

gngsn — Thu, 8 Jun 2023 23:08:50 +0900

본 포스팅은 openJDK 11 부터 17 까지의 변경 사항을 확인하고, JDK 17을 사용할 때 개발자로서 알아두면 좋을 내용을 학습합니다.

Previous Series:

JDK 11 ~ 17 Release, 제대로 이해하기 (current)

JDK 17 ~ 21 Release, 제대로 이해하기

Release Timeline

JDK 11는 JDK 17 바로 이전의 LTS release 입니다.

Oracle Java SE Product Releases Timeline

본 포스팅에서는 JDK 11 릴리즈 이후에 변화된 JDK Release를 시간 순서대로 다뤄볼 예정입니다.

JDK 12

JDK 12에서는 Compact Number Formatting을 지원하고, 확장된 Switch 표기법 처음 소개 (Preview) 했습니다.

새로운 모습의 Switch 문은 자세한 내용은 정식으로 릴리즈 되는 JDK 14에서 다루겠습니다.

모든 변화된 JDK 12 기능은 아래를 확인하세요.

- 230: Microbenchmark Suite

- 325: Switch Expressions (Preview)

- 334: JVM Constants API

- 340: One AArch64 Port, Not Two

- 341: Default CDS Archives

- 344: Abortable Mixed Collections for G1

- 346: Promptly Return Unused Committed Memory from G1

✔️ Compact Number Formatting

Compact Number Formats

단축된 숫자 표기 형식을 위한 NumberFormat을 지원합니다.

가령 Locale을 en_US 로 설정한다면, 1000은 "1K"로, 1000000은"1M"로 Formatting 할 수 있습니다.

숫자 표기 형식은 NumberFormat.Style을 통해 설정할 수 있습니다.

// Local: US, Style: SHORT 
NumberFormat fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT);
fmt.format(1_000);		// 1K
fmt.format(10_000);		// 10K
fmt.format(1_000_000);		// 1M

// Local: US, Style: LONG
NumberFormat fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.LONG);
fmt.format(1_000);		// 1 thousand
fmt.format(10_000);		// 10 thousand
fmt.format(1_000_000);		// 1 million


// Local: KOREA, Style: SHORT
NumberFormat fmt = NumberFormat.getCompactNumberInstance(Locale.KOREA, NumberFormat.Style.SHORT);
fmt.format(1_000);		// 1천
fmt.format(10_000);		// 1만
fmt.format(1_000_000);		// 100만

✔️ Collectors.teeing()

Java 12에서 등장한 Collectors.teeing()은 static method로, 두 Collector의 수행 결과를 결합해 결과를 냅니다.

java.util.stream 패키지에 정의된 Collectors 클래스 내에 정의되어 있습니다.

//Import
import java.util.stream.Collectors;

// Syntax
public static <T, R1, R2, R> Collector<T, ?, R> teeing(
        Collector<? super T, ?, R1> downstream1, 	// ①
        Collector<? super T, ?, R2> downstream2, 	// ②
        BiFunction<? super R1, ? super R2, R> merger) 	// ③

Parameter

① Collector<? super T, ?, R1> downstream1: 첫 번째 Collector
② Collector<? super T, ?, R2> downstream2: 두 번째 Collector
③ BiFunction<? super R1,? super R2, R> merger: 첫 번째와 두 번째 Collector의 결과 값을 결합하기 위한 함수

List<Integer> grades = List.of(3, 5, 5, 2, 5, 3, 4, 3, 5, 4, 4, 2);

Double averageGrade = grades.stream()
    .collect(teeing(
        summingDouble(i -> i),
        counting(),
        (sum, n) -> sum / n));

System.out.println(averageGrade);	// 3.75

JDK 13

JDK 15에서 정식으로 릴리즈될 Text Block의 Preview가 소개되었습니다. 자세한 내용은 15에서 다루겠습니다.

JDK 13에서는 자세히 다룰만한 큰 변화는 없습니다.

- 350: Dynamic CDS Archives

- 351: ZGC: Uncommit Unused Memory

- 353: Reimplement the Legacy Socket API

- 354: Switch Expressions (Preview)

- 355: Text Blocks (Preview)

JDK 14

Java의 새로운 타입인 Records가 Preview로 처음 소개되었습니다.

이전의 가장 최근 소개된 Java Type이 Java 5의 Enum이라는 것을 감안하면 꽤 주목할만한 내용이라는 것을 알 수 있습니다.

- Packaging Tool (Incubator)

- NUMA-Aware Memory Allocation for G1

- JFR Event Streaming

- Non-Volatile Mapped Byte Buffers

- Helpful NullPointerExceptions

- Records (Preview)

- Switch Expressions (Standard)

- Deprecate the Solaris and SPARC Ports

- Remove the Concurrent Mark Sweep (CMS) Garbage Collector

- ZGC on macOS, ZGC on Windows

- Deprecate the ParallelScavenge + SerialOld GC Combination

- Remove the Pack200 Tools and API

- Text Blocks (Second Preview)

- Foreign-Memory Access API (Incubator)

✔️ Switch expressions

JEP 361: Switch Expressions

JDK 12와 JDK 13의 Preview 로 소개되었던, 새로운 Switch 구문이 JDK 14에 정식 릴리즈 되었습니다.

추가된 기능은,

첫 번째로 기존의 방식과 동시에 새로운 기능의 Switch 문을 사용할 수 있습니다.

두 번째는 기존의 방식에 yield 키워드를 통해 결과 값을 산출하도록 만들 수 있습니다.

하나씩 살펴보도록 하겠습니다.

- Arrow labels

- Yielding a value

- Exhaustiveness

# Arrow labels

Traditional Case : case L: Label, fall through

New Case : case L -> Label, No fall-through

좌) Traditional Case, 우) New Case

새로운 구문은 위와 같이 화살표 (->)로 표시하며, 다중 조건으로 판단해 구문을 실행할 수 있습니다.

Unnecessary break;

기존의 방식은 case 조건에 맞다면 해당 구문을 실행하고,

그 아래 case로 이동하는 fall-through 가 진행되었습니다.

때문에 필요한 곳에 break; 을 작성하여,

fall-through를 막는 형식으로 사용하기도 했습니다.

모든 case에 break 키워드를 붙여야 하는 번거러움 때문에 switch를 잘 사용하지 않기도 하죠.

뿐만 아니라, 위처럼 다중 조건 할당 (multi-way conditions)을 위해 break;를 작성하지 않고,

fall-through를 유도하여 break가 걸리기 전의 구문을 실행하도록 만들기도 했습니다.

예를 들어, MONDAY와 FRIDAY는 num에 6을 할당하기 위해,

SUNDAY의 구문이 걸릴 때까지 아무런 구문도 없이 조건 정의만 되어 있습니다.

새로운 구문에서는 불필요하도록 매 조건마다 달아야하는 break를 개선합니다.

num 변수 값 할당

또한 이전에는 num에 변수 값을 할당하기 위해 case 문 마다 변수 값 할당을 따로 지정해주어야 합니다.

JDK 14에서는 yield와 새로운 구문을 통해 switch에서 특정 값을 산출해낼 수 있습니다.

위에서도 num 값을 switch 구문으로

# Yielding a value

또한 새로운 switch 표현식 뿐만 아니라, 기존의 switch 문에서도 결과 값을 산출할 수 있게 되었습니다.

s 값에 따라 기존 방식인 case L: 에서 yield 키워드를 통해 산출 값을 반환하는 것을 확인할 수 있습니다.

# Exhaustiveness

철저함

switch에 정의된 case는 반드시 모든 케이스를 정의내려야 합니다 (exhaustive).

기존 방식의 Switch 문은 종종 놓치는 케이스를 염려하여 default를 정의내리곤 했습니다.

새로운 switch 문에서는 모든 케이스를 정의하도록 강제하며,

만약 빠진 구문이나 반환되는 값이 완전하지 않다면 컴파일 오류가 발생합니다.

✔️ Helpful NullPointerExceptions

JEP 358: Helpful NullPointerExceptions

종종, 복잡한 구조에서 객체가 null 일 경우 디버깅에 어려움을 겪었습니다.

JDK 14부터는 NullPointerException의 자세한 설명을 통해 조금 더 쉽게 디버깅할 수 있도록 합니다.

public static void main(String[] args) {
    HashMap<String, GrapeClass> grapes = new HashMap<>();
    grapes.put("grape1", new GrapeClass(Color.BLUE, 2));
    grapes.put("grape3", null);
    grapes.get("grape3").getColor(); // ERROR! NullPointException
}

이전 방식에서는 아래와 같이 출력이 되었다면,

Exception in thread "main" java.lang.NullPointerException
        at com.mydeveloperplanet.myjava17planet.HelpfulNullPointerExceptions.main(HelpfulNullPointerExceptions.java:13)

변경된 방식은 아래와 같습니다.

Exception in thread "main" java.lang.NullPointerException: 
	Cannot invoke "...GrapeClass.getColor()" because the return value of "java.util.HashMap.get(Object)" is null
    at ....HelpfulNullPointerExceptions.main(HelpfulNullPointerExceptions.java:13)

Null 값의 위치를 자세히 명시해줍니다.

간단한 예시로 a.b.c.i = 99; 에서 오류가 발생한다면, 어디에서 오류가 발생했는지 아래와 같이 명시해줍니다.

Exception in thread "main" java.lang.NullPointerException: 
        Cannot read field "c" because "a.b" is null
    at Prog.main(Prog.java:5)

JDK 15

자바 15 릴리스 기능은 공식적으로 text blocks 기능을 포함하고 있으며,

ZGC와 Shenandoah 가비지 컬렉터에 대한 개선을 지속하고 있습니다.

- 360: Sealed Classes (Preview)

- 371: Hidden Classes

- 372: Remove the Nashorn JavaScript Engine

- 373: Reimplement the Legacy DatagramSocket API

- 374: Disable and Deprecate Biased Locking

- 375: Pattern Matching for instanceof (Second Preview)

- 377: ZGC: A Scalable Low-Latency Garbage Collector

- 378: Text Blocks

- 379: Shenandoah: A Low-Pause-Time Garbage Collector

- 381: Remove the Solaris and SPARC Ports

- 383: Foreign-Memory Access API (Second Incubator)

- 384: Records (Second Preview)

- 385: Deprecate RMI Activation for Removal

✔️ Text Blocks

JEP 378: Text Blocks

Java SE 13에서 등장했던 Text Block 기능이 preview 기능에서 permanent 기능으로 변경되었습니다.

Text Block은 대부분의 이스케이프 시퀀스가 필요하지 않고, 자동으로 문자열 형식을 예측 가능한 방식으로 지정하며, 원하는 경우 개발자가 형식을 제어할 수 있도록 하는 여러 줄 문자열 리터럴입니다.

Goals
문자열 사이에 사용하던 Escape Sequence(Escape 특수 문자)의 사용을 줄이면서,

+ 기호 없이도 여러 줄의 문자열을 단순하게 표현할 수 있도록 합니다.

텍스트 블록은 세 개의 큰따옴표로 정의되며, 시작을 표시하는 세 개의 큰따옴표와 끝을 표시하는 세 개의 큰따옴표는 같은 줄이면 Compile Error가 발생하며, 반드시 한 줄을 띄어 표기합니다.

기본적으로 시작과 끝의 큰따옴표의 위치에 따라 공백이 달라집니다.

마지막 라인은 자동으로 줄바꿈이 됩니다.

마지막 라인 줄바꿈을 막으려면 아래와 같이 마지막 문자열 끝에 종단 큰 따옴표를 붙이면 됩니다.

# New string methods

text blocks과 함께 아래와 같은 메소드들이 함께 소개되었습니다.

stripIndent() : 불필요한 공백을 제거합니다.

translateEscapes() : Escape 문자를 변환한 새로운 문자열을 반환합니다.

formatted() : 기존의 String Format 과 같이 템플릿 형식으로 변환한 값을 반환합니다.

System.out.println("%s\\n%s\\n%s"
	.translateEscapes()			// translateEscapes: \\n -> (new line)
	.formatted(				// formatted: %s -> string
		"   hello world".stripIndent(),	// stripIndent: remove unnecessary space
		"hello world  ".stripIndent(),
		"   hello world  ".stripIndent()));

출력값은 아래와 같습니다.

hello world
hello world
hello world

✔️ Z Garbage Collector

experimental 기능이었던 Z Garbage Collector(ZGC)가 프로덕션에서 사용할 수 있게 되었습니다.

-XX+ZGC : command 옵션 -XX를 사용하여 ZGC를 활성화합니다.

ZGC는 높은 성능을 보이는 새로운 Garbage Colloctor로, Garbage Colloctor의 키워드를 뽑자면 다음과 같습니다.

- Concurrent

- Region-based

- Compacting

- Colored pointers

- Load barriers

더 자세한 내용은 JDK 공식 문서를 확인하시길 바랍니다.

JDK 16

JDK 16에서는 데이터 record 클래스가 정식 출시되었고, instanceof 의 Pattern Matching 이 더욱 사용하기 편리한 형식으로 개선되었습니다.

- 338: Vector API (Incubator)

- 347: Enable C++14 Language Features

- 357: Migrate from Mercurial to Git

- 369: Migrate to GitHub

- 376: ZGC: Concurrent Thread-Stack Processing

- 380: Unix-Domain Socket Channels

- 386: Alpine Linux Port

- 387: Elastic Metaspace

- 388: Windows/AArch64 Port

- 389: Foreign Linker API (Incubator)

- 390: Warnings for Value-Based Classes

- 392: Packaging Tool

- 393: Foreign-Memory Access API (Third Incubator)

- 394: Pattern Matching for instanceof

- 395: Records

- 396: Strongly Encapsulate JDK Internals by Default

- 397: Sealed Classes (Second Preview)

✔️ Record Class

JEP 395: Records

JDK 16에서 출시된 가장 큰 기능은 record 클래스입니다.

record 클래스는 data-carrier classes, 데이터 객체의 역할을 합니다.
덕분에, Immutable Java Class 를 표현할 때의 Boilerplate 코드를 줄여줍니다.

아래의 record 클래스를 확인해볼게요.

위 클래스는 아래 클래스와 동일합니다.

몇 가지 record class의 규칙을 적어보자면 아래와 같습니다.

- record class는 암묵적으로 final class이며, 추상 클래스 abstract class가 될 수 없습니다.
- record class 내의 필드는 final입니다. data-carrier classes로써 Immutable 객체를 목표로 합니다.

- 접근자, 생성자, equals, hashCode 및 toString 메서드가 자동으로 생성됩니다.

접근자는 getter와 동일한 역할로, 필드 명을 그대로 가진 메서드 접근자를 생성합니다.

IntelliJ에서 생성한 record에 접근할 수 있는 메소드를 확인해보면 위와 같습니다.

record 클래스와 관련한 내용은 다룰 것이 많지만, 본 글에 다루기에는 적합하지 않아

위의 JEP 공식 문서를 참고하시는 것을 추천드립니다.

✔️ Pattern Matching for instanceof

JEP 394: Pattern Matching for instanceof

instanceof 연산자의 패턴 매칭으로 간결한 분기 처리를 할 수 있습니다.

간단한 예로, 아래와 같은 일반적인 패턴의 코드를

if (obj instanceof String) { String s = (String) obj; // grr... ... }

다음과 같이 바꿔 사용할 수 있습니다.

if (obj instanceof String s) { // Let pattern matching do the work! ... }

String s 는 if 문 내에서 사용할 수 있습니다.

if (obj instanceof String s && s.length() > 5) {
    flag = s.contains("jdk");
}

✔️ Stream.toList()

Steam에서 List로 변환시키기 위해 사용하던 Collector.toList() 대신, stream 에서 바로 ImmutableList로 변경하여 반환하는 메소드가 추가되었습니다.

좌측은 ArrayList를 생성하는 JDK 16 이전에 사용하던 stream → List 변환 방식이며,

우측은 ImmutableCollection을 생성하는 JDK 16 이후의 stream → List 변환 방식입니다.

JDK 17

LTS release features And finally, here are the enhancements made to the latest, Java LTS release:

- Enhanced Pseudo-Random Number Generators

- New macOS Rendering Pipeline

- macOS/AArch64 Port

- Deprecate the Applet API for Removal

- Strongly Encapsulate JDK Internals

- Pattern Matching for switch (Preview)

- Remove RMI Activation

- Sealed Classes

- Remove the Experimental AOT and JIT Compiler

- Deprecate the Security Manager for Removal

- Foreign Function & Memory API (Incubator)

- Vector API (Second Incubator)

- Context-Specific Deserialization Filters

✔️ Sealed Class

JEP 409: Sealed Classes

seal
verb. fasten or close securely

sealed class 는 이름 그대로 클래스를 안전을 위해 감추는 기능을 합니다.

sealed 키워드로 클래스를 정의하면 permits 키워드 이후의 명시된 클래스 이외에는 확장할 수 없습니다.

즉, 어떤 클래스가 해당클래스를 상속받는지를 쉽게 알수 있고 제한할수 있습니다.

가령, 위의 예시에서는 Circle, Square, Rectangle 이외의 클래스는 Shape 객체를 확장할 수 없습니다.

sealed 클래스의 하위 클래스는 반드시 아래 키워드 중 하나를 명시해야만 합니다.

sealed – ① 허용된 (permitted) 하위 클래스만 확장을 허용하거나, ② 정의된 파일 내의 class만 확장 가능하도록 정의
non-sealed – 확장에 열린 상태로 정의
final – 확장에 닫힌 상태로 정의

① sealed 클래스를 확장하는 하위 클래스는 동일한 모듈이나 동일한 패키지에서 정의할 수 있습니다.

위의 Shape 클래스를 확장하는 Circle, Square, Rectangle는 아래와 같이 정의할 수 있습니다.

② 혹은 아래와 같이 동일한 파일 내에 정의하여 permits 구문을 생략할 수 있습니다.

전체적인 구조를 도식화하여 확인해보면 아래와 같습니다.

https://www.happycoders.eu/java/sealed-classes/

Reference

- theserverside: all-changes-in-Java-17-since-JDK-11-LTS-release

- docs.oracle.com/en/java/javase/17/language/

- openjdk.org/projects/jdk/17

- openjdk.org/projects/jdk/17/jeps-since-jdk-11

JVM Architecture, 제대로 이해하기

gngsn — Sun, 14 May 2023 20:03:33 +0900

본 포스팅은 JDK, JRE, JVM에 대한 큰 그림을 그리고 각 구성요소가 어떤 기능을 하는지 깊이 있게 공부합니다.

바야흐로 금요일 저녁 javap 관련 글을 보다가 ...

아니 그래서 ClassFile은 뭘 확인할 수 있는데, 아니 그래서 JDK 9에서 뭐가 바꼈는데, 아니 그래서 JVM Architecture이 어떻게 구성되었는데 ...

이렇게 "아니 그래서 ..." 삼진 아웃 맞고 주말 내내 이어진 디깅이 포스팅이 되었습니다 ‍♀️

사실 한 번쯤 파보고 싶던 내용이라 확실히 재밌게 공부했습니다. 본 글이 많은 분들에게 도움이 되길 바랍니다.

2차 사용 시 출처 표시 부탁드립니다.

본 포스팅은 JVM Class Loader, JVM Memory, JVM Execution Engine 로 나뉘어져 조금 더 상세한 내용을 담을 예정입니다.

개발자가 작성한 Java 코드가 실행될 때 까지 어떤 과정을 거치게 될까요?

JDK으로 개발하고 난 후, JVM의 메모리에 컴파일된 바이트 코드를 올리면, JRE를 통해서 해당 로직을 실행하게 됩니다.

본 포스팅에서는 해당 내용을 하나씩 파헤쳐보려 합니다.

JDK · JVM · JRE의 개념을 먼저 살펴보고, 이 중 JVM에 대해 깊이 있게 알아봅니다.

이를 통해 Java 파일을 컴퓨터가 실행할 수 있는 코드로 변환되고 실행되는 과정을 살펴보도록 합시다.

Java Architecture

JDK

Java Development Kit 는 Java application과 Applet을 개발하기 위해 사용되는 소프트웨어 개발 환경입니다.

JDK는 다음을 포함합니다.

- JRE (Java Runtime Environment)
- Interpreter / loader (java)
- Compiler (javac)
- Archiver (jar)
- Documentation generator (Javadoc)
- Etc...

JDK와 JRE를 이해하기 위해서는 JDK 8 → JDK 9 사이의 변화를 살펴볼 필요가 있는데요.

Java 9 Platform Module System (JPMS)으로 인해 JDK 내부 구조가 크게 변했기 때문입니다.

Java 공식 계정에서 Alex Buckley가 발표한 Modules in JDK 9 영상에서 잘 설명하고 있습니다.

해당 글에서는 핵심적인 내용만 볼 예정이기 때문에 자세한 내용은 따로 한 번쯤 찾아보시길 권장합니다.

(곧 포스팅할 예정이긴 합니다 ㅎㅎ)

JDK 8 → JDK 9

Java SE 8에 이르기까지 JDK에는 다음과 문제점들이 존재했습니다.

다양한 자바 기본 패키지를 제공하는 거대한 코드 베이스를 관리하기가 굉장히 어려웠고,

공식 패키지를 공유하는 방법은 오직 Public 접근자로 열어두는 것이기 때문에,

한 패키지의 모든 코드가 모든 곳에 열릴 수 밖에 없었습니다.

패키지는 클래스를 구성하고 조직해두기 좋지만, 더 제한적인 관리가 필요했습니다.

결론적으로, Jdk 9 부터 모듈 시스템을 도입하면서 아래의 문제점들을 해결했습니다.

✔️ 무거운 JDK

Jdk 8:

JDK 자체가 너무 커서 성능을 높이기 어렵고, 낮은 성능의 기기에서 실행하기 어렵습니다.

JDK와 JRE는 monolithic으로 JDK 내에 JRE를 포함하고 있었습니다.

내장된 JAR 파일이 점점 많아지면서 해당 파일 관리가 어려워지고 크기가 커졌습니다.

JRE 사이즈가 점점 커졌는데, 가령 rt.jar만해도 60Mb를 차지했습니다.

rt.jar는 runtime의 약자로 ClassLoader 섹션에서 언급할 예정입니다.

이처럼 JDK가 점점 무거워지면서 Application의 성능 또한 개선하기 어려웠습니다.

Jdk 9:

필요한 모듈만 사용할 수 있도록 Java API를 73개의 모듈로 나누었습니다.

정확히는, 파일 Layout을 변경하여 rt.jar와 같은 몇 Jar를 제거하고, .jmod 파일 속에 rt.jar와 tools.jar 코드를 포함시켰습니다.

The Java Module System

모두 읽어보면 좋겠지만, 특히 주목할만한 내용인 우측 jdk-9 하위의 jmods를 확인해보면,

Raw platform modules as .jmod files; thier code was formerly found in rt.jar, tools.jar, and others. Not present in JREs.

라는 내용을 확인할 수 있습니다.

이렇게 모듈로 분리함으로써, 개발자는 Jlink 도구를 생성하여

애플리케이션에 정말 필요한 모듈만 포함하는 사용자 정의 JRE를 생성할 수 있게 되었습니다.

실제 Jdk bin 디렉토리를 확인해보면 아래와 같은 도구들을 확인할 수 있습니다.

✔️ public 접근 제어자, 내부 접근 가능

Jdk 8:

사용자가 내부 API에도 액세스할 수 있기 때문에 보안에 큰 문제였습니다.

Java 시스템에 강력한 캡슐화가 없어 누구나 접근할 수 있습니다.

Jdk 9:

Jdk 9 부터 지원하는 모듈은 재사용을 위해 설계된 패키지 모음입니다.

모듈은 특정 패키지에서 원하는 부분은 공개하고 특정 부분은 재사용할 수 없게 만듭니다.

가령, java.base 패키지를 확인해보면 쉽게 이해할 수 있습니다.

java.base를 개발한 후 해당 패키지를 사용하는 모든 개발자가 java.base 내부의 모든 코드에 접근할 수 있었습니다.

때문에 java.base 내부의 sun.nio.ch 나 sun.security.provider 와 같은비핵심 API의 코드 내부까지 액세스할 수 있었습니다.

우측 그림 source: youtube.com/watch?v=22OW5t_Mbnk

java.base 패키지에는 java.lang, java.io, java.net, java.util을 배포하면 Jdk 8까지는 모든 내부 패키지들이 공개되었습니다.

Jdk 9 부터는 module-info.java에 오직 외부에 공개하려는 패키지만을 exports로 정의함으로써 노출시킵니다.

즉, 내부 api인 sun.reflect.annotation, sun.security.provider는 정의되어 있지만 보호될 수 있는 것입니다.

JRE

Java Runtime Environment는 Java 응용 프로그램을 실행하기 위한 최소 요구 사항을 제공합니다.

자바로 만들어진 프로그램을 실행시키는데 필요한 라이브러리들과 각종 API, 그리고 자바 가상 머신 (JVM)이 포함되어 있습니다.

JRE은 다음을 포함합니다.

- Java Virtual Machine(JVM)
- Java core packages
- classes
- supporting files

JVM

❙ The abstract specification, a concrete implementation, or a runtime instance.

Java Virtual Machine은 Java 바이트 코드를 실행할 수 있는 런타임 환경을 제공하는 규격입니다.

JVM이 Java 바이트코드(.class file)를 실행하고 컴퓨터 하드웨어가 이해할 수 있는 다른 언어(Native Machine Language)로 변환할 수 있는 플랫폼을 만듭니다.

Platform Specific Interpreters ⸺ Write once, run anywhere

JVM은 설치하는 것이 아니라, JRE가 설치되면 코드가 배포되면서 특정 플랫폼에 대한 JVM을 생성합니다.

이것이 바로 JVM이 다양한 하드웨어 및 소프트웨어 플랫폼에서 사용할 수 있는 이유입니다.

자, 이제 본론으로 들어가겠습니다.

Internal Structure of JVM

JVM을 크게 세 가지로 구분하여 매커니즘, 즉 작동되는 방식을 확인할 수 있습니다.

Internal Structure of JVM

JDK에서 Java 코드를 개발하고 나면 Java Compiler에 의해 Class 파일로 변환시킵니다.

먼저, Class File을 먼저 살펴보도록 하겠습니다.

Chapter 1. Class File

▪️ Compiling: javac

▪️ Decompiling: javap

▪️ Class File Structure

Class File

Class 파일은JVM에서 실행할 수 있는 Java byte code를 포함한 .class 확장자 파일입니다.

Java 클래스 파일은 컴파일이 성공한 결과로 .java 파일에서 Java Compiler에 의해 생성됩니다.

javac 명령어로 java 파일을 class 파일로 컴파일할 수 있습니다.

가령, 아래와 같은 코드가 있다면,

void spin() {
	int i;
	for (i = 0; i < 100; i++) {
		// Loop body is empty
	}
}

컴파일러는 아래와 같이 컴파일할 것 입니다.

0 iconst_0	// Push int constant 0
1 istore_1	// Store into local variable 1 (i=0)
2 goto 8	// First time through don't increment
5 iinc 1 1	// Increment local variable 1 by 1 (i++)
8 iload_1	// Push local variable 1 (i)
9 bipush 100	// Push int constant 100
11 if_icmplt 5	// Compare and loop if less than (i < 100)
14 return	// Return void when done

Compiling: javac

Javac 명령어로 컴파일을 진행하여 모든 Java 소스 파일을 Class 파일로 변환합니다.

정확히는 프로그래머가 작성한 Java 코드를 Runtime 시 Interpreter 혹은 JIT Compiler가 읽을 수 있는 형태인 Java Virtual Machine Code로 변환하여 .class 확장자를 가진 파일로 저장합니다.

Class 파일은 java 파일 내 모든 클래스의 정의 별로 각각 생성됩니다.

가령, java 파일 내에 A, B 클래스가 정의 되어 있다면, A.class, B.class 파일이 생성됩니다.

또, 정의가 되어 있지 않은 java 파일은 Class파일은 생성되지 않습니다.

참고로, Nested Class는 OuterClass$InnerClass.class와 같이 생성됩니다.

먼저 Hello.java 파일을 다음과 같이 컴파일하면 Class 파일이 생성됩니다.

$ cat Hello.java
public class Hello {
	public static void main(String[] args) {
		System.out.println("HELLO");
	}
}

$ javac Hello.java
$ ls
Hello.java  Hello.class

Decompiling: javap

javap는 프로그래머가 컴파일한 코드를 확인하고 JVM의 실행을 예상할 수 있는 파일을 생성합니다.

Javac를 통해 Java Virtual Machine code를 생성할 수 있다고 했는데요.

그런데, 종종 이 코드가 어떻게 생성되는지 분석하고 싶거나, 궁금할 때가 생깁니다.

javap는 Oracle JDK가 제공하는 Java Virtual Machine code를 "virtual machine assembly language"로 불리는 형식으로 변환합니다. virtual machine assembly language는 Oracle javap 유틸리티에서 비공식적으로 불리는 이름이며, Java Virtual Machine code에 주석이 달린 일련의 코드 목록으로 구성됩니다.

Virtual machine assembly language 는 아래와 같은 형식을 가집니다.

<index> <opcode> [ <operand1> [ <operand2>... ]] [<comment>]

<index>: 지시어 opcode 인덱스

Java Virtual Machine code의 바이트 배열의 인덱스를 나타냅니다.

다른 관점으로 보면, 프로그램의 메소드 시작 오프셋으로 생각할 수 있습니다.

<opcode>: 명령어의 opcode에 대한 mnemonic

<operandN>: 명령어의 피연산자
<comment>: 선택 사항, 주석 구문

실제로 실행해보면 아래와 같은 코드를 확인할 수 있습니다.

$ javap -c SimplePrint.class
Compiled from "SimplePrint.java"
public class SimplePrint {
  public SimplePrint();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]) throws java.lang.Exception;
    Code:
       0: invokestatic  #7                  // Method printHelloWorld:()V
       3: return

  public static void printHelloWorld();
    Code:
       0: getstatic     #12                 // Field java/lang/System.out:Ljava/io/PrintStream;
       3: ldc           #18                 // String Hello
       5: invokevirtual #20                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       8: return
}

각 명령어는 opcode의 작업을 추적하여 실행 과정이나 메모리 할당을 예상해볼 수 있습니다.

Class File Structure

JDK 17 기준으로 Class File의 구조를 나타내보면 아래와 같습니다.

ClassFile {
   magic;
   minor_version;
   major_version;
   constant_pool_count;
   constant_pool[constant_pool_count-1];
   access_flags;
   this_class;
   super_class;
   interfaces_count;
   interfaces[interfaces_count];
   fields_count;
   fields[fields_count];
   methods_count;
   methods[methods_count];
   attributes_count;
   attributes[attributes_count];
}

더 자세한 사항은 oracle java spec을 참고하시길 바랍니다.

javap -v option을 통해 Class File의 정보를 확인할 수도 있습니다.

이렇게 만들어진 Class 파일이 실행되려면 어떻게 해야 할까요?

JDK으로 개발하고 난 후, JVM의 메모리에 컴파일된 바이트 코드를 올리면, JRE를 통해서 해당 로직을 실행하게 됩니다.

개발을 하고 Class 파일로 생성한 것까지 확인했으니,

이 번엔 컴파일된 바이트 코드를 JVM 메모리에 올리는 과정을 알아보도록 하겠습니다.

Chapter 2. Class Loader System

Types of ClassLoader

≤ JDK 8
  ▪️ Application Class Loader
  ▪️ Extension Class Loader
  ▪️ Bootstrap Class Loader
≥ JDK 9
▪️ Application Class Loader
▪️ Platform Class Loader
▪️ Bootstrap Class Loader
How Do Class Loaders Work
  1/ Loading
  2/ Linking
  ▪️ Verify
▪️ Prepare
  ▪️ Resolve
  3/ Initialization

Class Loader System

컴파일 이후 여러개의 Class 파일이 생성되는데, 이 파일들은 서로 다른 디렉터리에 위치되어 있습니다.

Class Loader System 단계에서는 ClassLoader를 통해 서로 다른 디렉터리에 분산된 파일들을 메모리에 올리는 역할을 합니다.

또, 이미지와 같은 연결된 리소스를 연결하는 역할을 하기도 합니다.

ClassLoader

ClassLoader는 말그대로 Class의 Loading을 담당하는 객체입니다.

특정 Class의 Binary name이 주어지면, 해당 클래스가 정의된 데이터를 찾거나 생성하려는 시도를 합니다.

일반적으로, Class 이름을 File 명으로 변환한 다음, 파일 시스템에서 해당 이름의 클래스 파일을 읽습니다.

JVM Architecture: Class Loader System

Types of ClassLoader

ClassLoader는 java.base 패키지에서 확인할 수 있는 하나의 Abstract Class입니다.

해당 클래스는 Jdk 9 부터 모듈 도입으로 구조가 바뀌면서 같이 변경되었습니다.

대부분 검색을 해보면 ClassLoader 설명에서는 Java 8까지의 ClassLoader를 설명을 하는데,

그래서 실제 코드를 확인해보면 Jdk 9부터 ClassLoader의 사용이 설명과는 다른 것을 확인할 수 있었습니다.

요약하자면, Jdk 8 이전의 무거운 java API를 개별의 모듈로 분리하면서

Jdk 9 부터 JRE의 런타임에 불러오는 방식으로 변경되었고, 이하부터 해당 내용을 설명합니다.

≤ JDK 8

ClassLoader는 각 클래스 파일들의 성격에 따라 세 가지 유형으로 나눠 로딩합니다.

www.javatpoint.com/classloader-in-java

✔️ Application/System ClassLoader: classpath, -cp, Manifest에서 클래스 로드

✔️ Extension ClassLoader: JRE/lib/ext 에서 클래스 로드

✔️ Bootstrap ClassLoader: JRE/lib/rt.jar 에서 클래스 로드

자세한 내용은 이하 '1/ Loading' 단계의 Parent Delegation Model으로 확인할 예정이며,

본 내용은 어떤 ClassLoader가 있는지, 각 ClassLoader가 클래스를 로딩하는 위치가 다르구나를 확인하시면 됩니다.

≥ JDK 9

기본적으로, JDK 9는 기존에 존재했던 클래스 로더의 계층 구조를 유지하며, 다음과 같이 변경되었습니다.

변화된 내용을 살펴보도록 하겠습니다.

해당 내용은 Oracle JDK 9E Official Docs 을 참고하여 정리한 내용입니다.

JDK 9: rt.jar 제거
Java 8까지 JDK와 JRE는 monolithic이었으며, Bootstrap ClassLoader가 클래스를 찾는 rt.jar만해도 60Mb를 차지했습니다. 이를 해결하기 위해 Java 9부터 모듈 시스템을 도입했습니다.

그 결과, JDK 9부터는 rt.jar가 제거되고 73개의 모듈로 나뉘었습니다. 자세히 말하자면, Java 9부터 파일 Layout을 변경하여 module로 불리는 .jmod 파일 속에 rt.jar와 tools.jar 코드를 포함합니다. 이렇게 모듈로 분리함으로써 개발자는 Jlink 도구를 생성하여 애플리케이션에 정말 필요한 모듈만 포함하는 사용자 정의 JRE를 생성할 수 있게 되었습니다.

✔️ Application Class Loader

: Java SE 또는 JDK 모듈을 제외한 모듈 내의 클래스에 대한 기본 로더입니다.

더 이상 URLClassLoader의 인스턴스가 아닌 internal 클래스의 인스턴스입니다.

즉, 아래 코드를 Jdk 8 이전 환경에서 실행시키면 if 절은 true가 되고, Jdk 9 이후 환경에서 실행시키면 false가 될 것입니다.

if (classLoader instanceof URLClassLoader) {
    URLClassLoader urlClassLoader = (URLClassLoader) classLoader;
    URL[] urls = urlClassLoader.getURLs();
    // Do something with the URLs
} else {
    System.out.println("Application class loader is not an instance of URLClassLoader");
}

✔️ Platform Class Loader

: Extension Class Loader → Platform Class Loader 이름 변경

: 더 이상 URLClassLoader의 인스턴스가 아닌 internal 클래스의 인스턴스

Java SE Platform의 모든 클래스는 Platform Class Loader를 통해 참조됩니다. 또한 Java SE Platform의 일부는 아니지만 Java Community Process에 따라 표준화된 모듈의 클래스도 Platform Class Loader를 통해 참조됩니다.

단순히 Platform Class Loader를 통해 클래스를 볼 수 있다고 해서 해당 클래스가 실제로 Platform Class Loader에 의해 정의되는 것은 아닙니다. Java SE 플랫폼의 일부 클래스는 Platform Class Loader에 의해 정의되는 반면, 다른 클래스는 Bootstrap Class Loader에 의해 정의됩니다. 중요한 점은 어플리케이션이 Class Loader가 어떤 플랫폼 클래스를 정의하는지에 따라 달라지지 않아야 한다는 것입니다.

JDK 9의 변경 사항으로, Bootstrap Class Loader를 부모로 사용하려면 바로 위에서 살펴본 Application LoaderClass의 코드와 같이 코드를 변경해야 할 가능성이 있습니다.

(참고: ClassLoader.getPlatformClassLoader)

✔️ Bootstrap Class Loader

: 여전히 Java Virtual Machine에 기본 내장되어 있으며, ClassLoader API에서 null로 표시

java.base와 같은 소수의 중요 모듈에서 클래스를 정의합니다.

따라서 JDK 8보다 훨씬 적은 클래스를 정의하며, 아래와 같은 상황에서 코드를 변경해야 할 수 있습니다.

-Xbootclasspath/a로 배포되는 애플리케이션
부모로 null인 클래스 로더를 만드는 애플리케이션

ClassLoader의 타입을 알아보았으니, 이제는 ClassLoader가 하는 일에 대해 살펴보도록 하겠습니다.

How Do ClassLoader Work

ClassLoader는 크게 Loading, Linking, 그리고 Initialization의 세 가지 역할을 합니다.

Loading: 클래스 파일를 메모리에 적재. Type에 대한 binary data 찾고 가져오기
Linking: 클래스 파일 기본 값으로 초기화 및 검증
2.1 Verification: 가져온 type의 정확성 확인
2.2 Preparation: 클래스 변수에 메모리 할당 후 메모리를 기본값으로 초기화
2.3 Resolution: (Optionally) Symbolic References를 type에서 Direct References로 변환
Initialization: 클래스 변수를 시작 값으로 초기화한 Java 코드를 호출

하나씩 살펴보도록 하겠습니다.

1/ Loading

JVM이 파일 로딩 시, ClassLoader가 아래와 같은 데이터를 로드하고 읽는 단계입니다.

FQCN, Fully qualified class name (패키지명을 모두 포함한 클래스 명)
변수 정보 (인스턴스 변수)
바로 위 Parent 정보
Class / Interface / Enum 인지 확인

java 명령어에 -verbose:class 옵션을 추가하여 탑재 과정을 확인할 수 있습니다.

$ java -verbose:class Test.java
[0.103s][info][class,load] java.lang.Object source: shared objects file
[0.108s][info][class,load] java.io.Serializable source: shared objects file
[0.109s][info][class,load] java.lang.Comparable source: shared objects file
[0.109s][info][class,load] java.lang.CharSequence source: shared objects file
[0.109s][info][class,load] java.lang.constant.Constable source: shared objects file
[0.110s][info][class,load] java.lang.constant.ConstantDesc source: shared objects file
[0.110s][info][class,load] java.lang.String source: shared objects file
[0.111s][info][class,load] java.lang.reflect.AnnotatedElement source: shared objects file
[0.111s][info][class,load] java.lang.reflect.GenericDeclaration source: shared objects file
[0.111s][info][class,load] java.lang.reflect.Type source: shared objects file
...

특정 클래스가 JVM에 로드되면, 해당 클래스 유형의 객체가 생성되고, Heap Area에 배치됩니다.

해당 클래스 타입 객체는 클래스가 JVM에 처음 로드될 때에만 생성됩니다.

Parent Delegation Model

ClassLoader.loadClass() 메소드가 런타임 시 Fully Qualified Class Name 으로 클래스를 로딩하는 역할을 합니다.

실행 후 해당 클래스가 로드되지 않았다면, Parent class loader에게 해당 작업을 위임합니다.

이 작업 위임은 재귀적으로 발생합니다.

클래스를 찾는 기준은 '개발자가 정의한 클래스 파일'인지 '확장 패키지 하위의 클래스 파일인지', 혹은 'Java에서 제공받는 클래스 파일'인지의 기준에 의해 구분됩니다. 이 구분은 따로 갖고 있는 정보가 아니라, 시도하고 없으면 다음을 찾는 형식입니다.

즉, Application → Extension → Bootstrap 순서로 아래 과정을 재귀적으로 진행합니다.

Class 찾기 → Class 없음 → Parent Class로 위임

ClassLoader.loadClass()로 Class를 찾고 없으면 부모에게 위임하여 부모 클래스가 ClassLoader.loadClass()를 호출하는 형식입니다.

JDK 8 이하에서는, 만약 Parent Class Loader가 끝까지 클래스를 찾지 못하면, URLClassLoader가 파일 시스템 자체 내 클래스를 찾아보기 위해 URLClassLoader.findClass()를 호출합니다. 만약 이번에도 못찾으면 java.lang.NoClassDefFoundError 이나 java.lang.ClassNotFoundException 오류를 던집니다.

실제 오류를 살펴보면, 아래와 같은 코드를 확인해볼 수 있습니다.

≤ JDK 8: ClassNotFoundException

① ClassLoader는 loadClass 호출을 시도 후 없으면 Parent 재귀적 위임을 시도

② URLClassLoader의 findClass 메소드를 호출

③ 결론적으로 찾지 못해 ClassNotFoundException 오류가 발생한 것을 확인할 수 있습니다.

JDK 9 이상에서는 아래와 같이 출력됩니다.

이번에는 ClassNotFoundException가 발생할 때까지의 오류를 다시 살펴보면 다음과 같습니다.

≥ JDK 9: ClassNotFoundException

2/ Linking

클래스 파일의 데이터를 메모리 영역에 연결합니다.

Linking 단계에서는 Verify → Prepare → Resolve 단계를 거칩니다.

✔️ 2.1 Verify

클래스 파일과 컴파일러를 유효성 판단을 위해 아래 사항을 가장 먼저 검증합니다.

Compiler가 유효한지
Class 파일의 포맷 혹은 구조가 올바른지

가령, 보안 스레드를 고려할 때 멀웨어와 같은 일부 프로그램이 클래스 파일에 일부 콘텐츠를 변경하거나 추가할 수 있습니다.

이 경우 byte code verifier에 의해 식별되고, "verify exception" 예외를 던집니다.

✔️ 2.2 Prepare

Verification 완료 후 preparation 단계로, 모든 변수가 기본값으로 초기화됩니다.

int 변수에는 0, 모든 객체에는 null, 모든 부울 변수에는 false 등을 할당합니다.

예를 들어 아래와 같은 클래스 내에 아래와 같은 정의가 있었다면,

JVM은 Preparation 단계에서 enabled를 위한 메모리를 할당하고 boolean의 default value인 false를 설정합니다.

private static final boolean enabled = true;

현재 단계에서는 무조건 default 값을 할당하고, "3/ Initialization" 에서 해당 값을 초기화합니다.

✔️ 2.3 Resolve

Symbolic references를 Runtime Constant Pool에 있는 Direct references로 대체됩니다.

예를 들어, 아래와 같은 Salutation 클래스가 있다고 해봅시다.

Salutation Class

Loading 단계에서 아래 사용되는 객체들을 모두 로드한 상태입니다.

주의할 점은 아직 작성된 Java 코드는 실행되지 않았고, 메모리 할당과 초기화만 시켜둔 상태라는 점입니다.

즉, 클래스 fields 값은 개발자가 지정한 시작 값이 아닌 default 값입니다.

<clinit>()(main 메소드)를 실행하기 전, Resolution 단계가 선택적으로 실행됩니다.

만약 Symbolic Reference가 실제로 사용이 되어진다면 Resolution을 진행하고,

존재는 하지만 실제 사용되지 않는다면 해당 단계를 지나칩니다.

6	CONSTANT_Class_info	45
13	CONSTANT_Methodref_info	6, 20
14	CONSTANT_Double_info	2.99
20	CONSTANT_NameAndType_info	51, 21
21	CONSTANT_Utf8_info	"()D"
45	CONSTANT_Utf8_info	"java/lang/Math"
51	CONSTANT_Utf8_info	"random"

Class Salutation's constant pool

이 때, choice는 Math.random()를 할당하기 위해 java/lang/Math 라는 Symbolic Reference를 들고 있다가,

Resolution을 위해 다음을 진행합니다.

Reference가 될 클래스를 찾거나 필요 시 로딩
기호 참조를 클래스, 필드 또는 메서드에 대한 포인터 또는 오프셋과 같은 직접 참조로 변경

더 자세하게는, Salutation 클래스 Constant pool 에서 choice를 가리키는 하위 엔트리의 Symbolic Reference을 실제 객체가 저장된 Direct Reference로 변경하는 것입니다.

이 세 단계가 끝나면 Java 파일이 메모리 영역에 로드됩니다.

Resolution 단계에 대한 자세한 자료가 거의 없고 찾기 어려웠는데,

Inside the Java Virtual Machine - Bill Venners 에 constant pool 구조까지 설명되어 있습니다.

다만 오래된 책이니 현재와 동일한 내용인지 다시 한 번 확인하시길 바랍니다.

3/ Initialization

이 단계에서는 모든 정적 및 인스턴스 변수에 실제 값들이 할당됩니다.

모든 static 변수와 인스턴스 변수에 실제 값이 할당됩니다.

Class loading의 마지막 단계입니다.

Initialization 단계에는 클래스 또는 인터페이스의 초기화 메소드(<clinit>) 실행이 포함됩니다.

해당 단계에서는 클래스의 생성자 호출, static block 실행, 모든 static variables에 값 할당을 포함합니다.

클래스를 실사용active use되기 전에는 반드시 초기화Initialization 되어야 합니다.

참고로, 다음과 같은 6가지 실사용 규칙이 있습니다.

Use new keyword.
Invoke static methods.
Assign values for static fields.
Initialize class.
Use getInstance() in Reflection API.
Instantiation of sub-class.

Linking의 preparation 단계에서 선언한 하기 코드를 예로 들자면, 위의 단계까지는 기본값인 false로 설정되었습니다.

private static final boolean enabled = true;

Initialization 단계에서 이 변수에는 실제 값 true가 할당됩니다.

⚠️ JVM은 멀티 스레드입니다.

따라서, 여러 스레드가 동시에 동일한 클래스를 초기화하려고 할 수 있습니다.

이로 인해 동시성 문제가 발생할 수 있기 때문에, 안전하게 스레드를 처리해야 합니다.

Chapter 3. Runtime Data Area

Method Area

Heap Area

Stack

PC Register

Native Method Stack

Runtime Data Area

Runtime Data Area은 따로 더 자세한 포스팅을 준비중이기 때문에 아주 자세한 내용은 생략했습니다.

Runtime Data Area는 프로그램이 동작하는 동안 데이터들이 저장되는 공간입니다.

아래의 5개의 요소로 구성되어 있습니다.

JVM Architecture: Runtime Data Area

Method Area

Method Area는 JVM 당 오직 하나만을 가지며, 아래와 같은 Class 레벨의 데이터를 저장합니다.

✔️ ClassLoader reference

✔️ Type Information

✔️ Run time constant pool

✔️ Constructor data — Per Constructor : parameter types (in order)

✔️ Method data — Per method: name, return type, parameter types (in order), modifiers, attributes

✔️ Field data — Per field: name, type, modifiers, attributes

Heap Area

모든 객체들과 그에 해당하는 인스턴스 변수들이 Heap Area에 저장됩니다.

가령, 아래와 같은 "Employee"를 호출하는 코드를 포함한 프로그램을 작성했다고 가정해봅시다.

Employee employee = new Employee();

클래스가 로드될 때, 그의 인스턴스 employee 가 생성되고 Heap Area에 로드됩니다.

Stack

스레드마다 분리된 Stack 영역을 갖습니다. Stack은 호출되는 메소드 실행을 위해 해당 메소드를 담고 있는 역할을 합니다. 메소드가 호출되면 새로운 Frame이 Stack에 생성됩니다. 이 Frame은 LIFO 로 처리되며, 메소드가 실행이 완료되면 제거됩니다.

PC Register

PC Register는 현재 실행되고 있는 명령어instruction의 주소를 저장합니다. Multi-thread 프로그래밍 환경에서 한 thread가 작업하다가 다른 thread로 잠시 CPU 점유를 넘겨주고 다시 돌아왔을 때 이전에 어떤 명령을 수행하고 있었는지를 기억하고 있어야 이전 작업을 다시 이어서 수행할 수 있겠죠.

현재 PC Register가 가르키고 있는 명령어가 실행되면, PC Register은 다음 명령어를 가르키도록 업데이트됩니다. 만약, 현재 실행되는 메소드가 'native'라면, program counter register는 정의되지 않은 상태undefined가 됩니다.

Native Method Stack

Native Method는 다른 프로그래밍 언어로 구현된 자바 메소드입니다. 가령 C 나 C++ 등으로 작성될 수 있습니다.

해당 메모리 영역은 이러한 native method들의 정보를 담는 역할을 합니다.

Chapter 4. Execution Engine

Interpreter

JIT Compiler

▪️ Interpreter vs. JIT Compiler

Garbage Collector

Execution Engine

로딩과 저장하는 과정이 끝나고 나면, JVM은 마지막 단계로 Class File을 실행시킵니다.

Execution Engine은 다음과 같은 세 가지 요소로 구성됩니다.

JVM Architecture: Execution Engine

Interpreter

프로그램 실행 시작 시 Interpreter는 Bytecode를 한 줄씩 읽어 기계가 이해할 수 있도록 변환을 시킵니다. 마치 사전을 보고 '해석Interpret'하는 역할로 볼 수 있죠.

Interpreter의 '로드 속도'와 '실행 속도'는 매우 빠르지만, Interpreter 자체의 속도는 비교적으로 느린 편입니다. 그 이유는 모든 코드를 한 줄 한 줄 읽고 처리해야 하고, 동일한 코드 반복을 줄일 수 없어 실행 시간을 최적화할 수 없습니다.

다시 말해, Method 재사용이나 Loop와 같은 동일한 코드 블록을 실행할 때, 이를 반복적으로 처리해야 한다는 것입니다.

JIT Compiler

Just In Time Compiler는 Interpreter의 주요 단점을 극복하기 위해 도입되었습니다.

JIT Compiler는 실행되는 반복되는 코드 블록을 기억합니다.

가령, "Employee"라는 클래스 내 getEmployeeID()라는 메소드가 선언되었다고 해봅시다.

getEmployeeID() 메서드를 1000번 호출할 때, 인터프리터는 매번 해당 코드를 실행합니다.

하지만 JIT 컴파일러는 반복되는 코드 구간segment을 식별할 수 있으며, 캐시에 native code로 저장됩니다.

덕분에, 다시 해당 코드 구간을 캐시에 저장된 네이티브 코드를 사용합니다.

JIT Compiler는 다음과 같은 네 개의 컴포넌트를 갖습니다.

Intermediate Code Generator - intermediate code 를 생성
Code Optimizer - 성능을 위한 intermediate code 최적화
Target Code Generator - intermediate code를 native machine code 로 변경
Profiler - hotspots(반복적으로 실행되는 코드) 탐색

Interpreter vs. JIT Compiler

그렇다면 언제 Interpreter가 실행되고, 언제 JIT Compiler가 실행될까요?

바로 HotSpot Code의 여부에 따라 달라집니다.

Interpreter vs JIT Compiler

애플리케이션의 성능은 전체 코드 중 일부만 자주 실행되는 일부가 얼마나 빠르게 실행되는가에 의해 좌우됩니다.

자주 실행되는 이 영역을 애플리케이션의 핫스팟이라고 합니다.

Interpreter와 JIT Compiler를 이해하기 위한 예시를 확인해보겠습니다.

int sum = 10;
for(int i = 0 ; i <= 10; i++) {
   sum += i;
}
System.out.println(sum);

Interpreter

Loop의 매 반복마다 sum 값을 메모리에서 꺼내와서 i 값을 더해주고, 다시 메모리에 write합니다.

매번 메모리에 접근하니, 꽤나 큰 비용이 필요한 것을 알 수 있습니다.

JIT Compiler

반면 JIT Compiler는 해당 코드가 HotSpot을 가지고 있다고 간주하고, 해당 코드를 최적화시킵니다. 해당 스레드의 PC Register에 Local Copy하고, 루프가 다 돌 때까지 i 를 계속해서 더합니다. 해당 루프가 종료되면 다시 메모리에 write합니다.

JIT Compiler는 컴파일 시간이 필요하기 때문에 Interpreter 보다 더 많은 시간이 필요합니다. 때문에 만약 프로그램이 단 한 번만 실행되는 것이라면 Interpreter를 사용하는 것이 낫습니다.

Garbage Collector

자세한 내용은 이전에 작성한 "Garbage Collector, 제대로 이해하기" 참고하세요.

위에서 설명한대로 JVM의 실행이 시작되기 전, 모든 객체들은 Heap Area에 저장됩니다. 하지만, 이 영역은 제한되어 있기 때문에 해당 영역을 주기적으로 청소해서 효율적이게 사용해야 합니다. 여기서 청소는 더 이상 사용하지 않는 객체들을 지우는 것을 비유한 말입니다.

Heap 메모리 영역에서 필요없는 객체를 지우는 과정을 흔히 알고있는 메모리 관리 중 한 부분인 Garbage Collection이라고 합니다.

더 이상 사용하지 않는 객체를 찾는 방법은 아래 두 가지 방법이 있습니다.

1. null 참조

아래 employee는 Employee 객체를 참조하고 있다가 null 값을 할당받게 됩니다. 이 때, Employee 객체를 가리키는 참조는 없어지게 됩니다. 따라서 해당 객체는 더 이상 참조되지 않는unreachable object로 간주됩니다.

Employee employee = new Employee();
employee = null;

2. 다른 객체 참조

결론적으로, 아래 코드에서 employee1 는 employee2를 가리키게 됩니다.

때문에 첫 째줄에 생성한 Object 1에 해당하는 Employee 객체는 더 이상 참조 되지 않습니다.

Employee employee1 = new Employee(); //object 1
Employee employee2 = new Employee(); //object 2
employee1 = employee2;

GC는 백그라운드에서 돌고 있는 Daemon Thread 이며, 아래 두 단계로 실행됩니다.

www.site24x7.com/learn/java/choosing-garbage-collector.html

1. Mark: GC가 메모리 상에 사용하지 않는 객체를 식별 → 위 도식의 붉은 도형 Object 5, 6, 7, 8

2. Sweep: 첫 번째 과정 중 식별된 객체를 제거

Garbage Collection에 의해서 자동으로 수행되긴 하지만, 프로그래머가 System.gc() 메소드를 호출해서 GC를 발생시킬 수도 있습니다.

System.gc()
System.gc() 또는 Runtime.getRuntime() API를 직접 호출하는 건 이미 잘 알려진 Bad Practice입니다.

System.gc()가 호출되면 Full GC 이벤트를 발생시킵니다. Full GC가 Stop-the-world 진행하는 동안 모든 고객 트랜잭션이 일시 중지는데, 일반적으로 이 Full GC는 완료하는 데 오래 걸립니다.

프로그래머가 GC를 직접 호출하지 않아도 JVM가 GC를 트리거할 시점에 대한 복잡한 알고리즘로 모든 계산을 백그라운드에서 항상 작동합니다. 또, JVM이 1 ms 전에 GC 이벤트를 트리거했는데, 애플리케이션에서 System.gc()를 다시 호출할 경우를 생각해보면 문제를 확인할 수 있겠죠. 애플리케이션은 GC가 언제 실행되었는지 알 수 없기 때문에 충분히 가능한 상황입니다.

Types of Garbage Collector

JVM에는 네 가지 유형의 Garbage Collector가 있습니다:

✔️ Serial GC - GC의 가장 단순한 구현 형태이며, 단일 스레드 환경에서 실행되는 소규모 응용 프로그램을 위해 설계되었습니다. 가비지 수집을 위해 단일 스레드를 사용합니다. 실행 시 전체 응용 프로그램이 일시 중지되는 "Stop the world" 이벤트가 발생합니다. Serial GC 사용을 위해서는 -XX:+UseSerialGC JVM 인자를 입력하면 됩니다.

✔️ Parallel GC - Throughput Collector라고도 합니다. 가비지 수집에 여러 스레드를 사용하지만 실행 중 응용 프로그램을 일시 중지합니다. Parallel GC 사용을 위해서는 -XX:+UseParallelGC JVM 인자를 입력하면 됩니다.

✔️ G1 GC - Garbage First GC는 사용 가능한 힙 크기가 큰(4GB 이상) Multi Thread Application을 위해 설계되었습니다. Heap을 동일한 크기의 영역 집합으로 분할하고 여러 스레드를 사용하여 검색합니다. G1GC는 가비지가 가장 많은 영역을 파악하여 해당 영역에서 가비지 수집을 먼저 수행합니다. G1 Garbage Collector 사용을 위해서는 -XX:+UseG1GC JVM 인자를 입력하면 됩니다.

✔️ ZGC - Z Garbage Collector는 Concurrent 가비지 수집기로, 무거운 작업들을 처리할 때에도 스레드가 실행되는 동안 작업을 마칩니다. 즉, 스레드의 실행을 중지하지 않으면서 GC를 실행할 수 있습니다. 덕분에 기존에 GC가 애플리케이션 응답 시간에 미치던 영향이 크게 줄었습니다. ZGC의 확장 가능한 저지연 가비지 수집기로, 아래 목표를 기반으로 설계되었습니다.

- 최대 일시 중지 시간 millisecond 미만
- heap, live-set 또는 root-set 크기에 따라 일시 중지 시간이 증가하지 않음
- 8MB에서 16TB에 이르는 크기의 heap 처리

ZGC는 처음에 JDK 11에서 실험적 기능Experimental feature으로 도입되었으며 JDK 15에서 운영 준비Production Ready 상태로 선언되었습니다.

CMS(Concurrent Mark Sweep) GC라는 Garbage Collector도 있습니다. 하지만 Java 9 이후로 더 이상 사용되지 않으며 JDK14에서 G1GC를 위해 완전히 제거되었습니다.

Chapter 5.

Java Native Interface

Java는 Java Native Interface(JNI)를 통해서 native code 실행을 지원합니다.

www.researchgate.net/figure/Java-Native-Interface-JNI-to-access-the-C-code_fig3_331872802

경우에 따라 native code(C/C++, non-java)를 사용해야 할 때가 있습니다. 가령 하드웨어와 인터렉션한다거나, 메모리 관리나 성능 제약을 극복해야 하는 경우가 있습니다. JNI는 C, C++ 등의 다른 프로그래밍 언어에 대한 지원 패키지를 허용하는 일종의 Bridge 역할을 합니다.

특히 C로만 작성할 수 있는 몇몇 플랫폼 기능과 같이, Java에서 코드를 지원하지 않는 경우에 유용합니다. native 키워드를 사용하여 해당 메서드가 native 라이브러리로 구현되었다는 것을 명시할 수 있습니다. System.loadLibrary()를 호출해서 공유 native 라이브러리를 메모리에 로드하고 Java에서 사용 가능한 function으로 만들어야 합니다.

Chapter 6.

Native Method Libraries

Native Method Libraries는 C, C++ 및 assembly와 같은 다른 프로그래밍 언어로 작성된 라이브러리입니다. 이러한 라이브러리는 일반적으로 .dll 또는 .so 파일 형식으로 제공됩니다. 이러한 기본 라이브러리는 JNI를 통해 로드할 수 있습니다.

Chapter 7.

Common JVM Errors

ClassNotFoundException - ClassLoader가 Class.forName() , ClassLoader.loadClass() 또는 ClassLoader.findSystemClass() 를 사용하여 클래스를 로드하려고 하지만 지정한 이름의 클래스에 대한 정의를 찾을 수 없는 경우에 발생합니다.

NoClassDefFoundError - 컴파일러가 클래스를 성공적으로 컴파일했지만 클래스 로더가 런타임에서 클래스 파일을 찾을 수 없는 경우에 발생합니다.

OutOfMemoryError - 메모리가 부족하여 JVM이 개체를 할당할 수 없고 가비지 수집기가 더 이상 사용할 수 있는 메모리를 만들 수 없을 때 발생합니다.

StackOverflowError - 스레드를 처리하는 동안 새 Stack Frame을 생성하는 동안 JVM의 공간이 부족한 경우에 발생합니다.

| Reference |

Oracle: java spec - jvms17

"Inside the Java Virtual Machine" Book by Bill Venners

Youtube: Modules in JDK 9 by Alex Buckley

Youtube: Stack and Heap: Memory Management In Java

Artima.com: I nside Jvm - Li nking model

Slideserve.com: java-virtual-machine-jvm

Freecodecamp.org: java-virtual-machine-architecture