나는 발표를 왜 할까?

주니어 개발자 때는 커리어 개발을 위해서 PyCon, AWS Community Day와 스타트업 행사에서 발표를 하였다. 그리고 그 때는 PyCon이나 AWS Community day 발표처럼 비교적 큰 행사에서 발표하면 뭔가 멋지다는 생각을 했었다. 그래서 뭔가 발표를 하고 나면 뿌듯함을 느끼고 좋았던 것 같다. 그리고 그때는 나의 Comfort zone을 벗어날려고 노력을 많이 했다. 많은 사람들 앞에서 발표하는 것이 처음에는 정말 가슴이 두근두근 거리고 긴장이 많이 되었다. 하지만 이것도 몇번 반복하다보니 그러한 긴장감을 조금을 즐길 수 있는 상태가 되었다. 물론 발표 전에 떨리는 마음도 있고, 발표를 하면서 내 목소리가 조금 긴장하고 있다라는 것을 느낀다. 하지만 그러한 긴장감이 나에게 나쁜 스트레스를 주는 것이 아니라, 좋은 자극과 긴장감을 준다.

그런데 이번에 발표를 하게 된 이유는 조금 다르다. 먼저 다시 한번 내가 아는 지식을 나누고 싶다라는 열정이 다시 생겼다. 나는 개발자로 커리어를 시작하면서 훗날 좋은 멘토가 되는 것을 목표로 세웠다. 내가 그동안 경험한 것이나 배운 것들을 효과적으로 잘 전달하는 것도 좋은 멘토가 되기 위한 기술이라고 생각한다. 이번 발표를 통해서 그렇게 생각하고 열정적으로 살아온 나로 돌아가는 전환점으로 삼고 싶었다. 그리고 내가 습득한 지식들을 발표라는 방식으로 소화하고 배출하는 과정을 통해서 그 지식들을 장기기억으로 남기고자 하였다. 오늘 발표한 내용들을 다듬고 정리해서 인프런에서 강의로도 올릴 계획에 있다. "주말에 커피 한잔 마시면서 공부하는 쿠버네티스 네트워크"라는 컨셉으로 만들어 보고 싶다.

흑역사를 추가하다

마이크로 서비스 아키텍쳐에 대해서 수박 겉 핥기를 해놓고는, PyCon과 피플펀드에서 주최한 스티첼이라는 개발자 행사에서 열심히 아는 척 했었다. 하지만 그때 나는 마이크로 서비스 아키텍쳐에 빠져서 정말 열심히 탐구하였다. Domain Driven Design, Service Mesh, Consumer Driven Contract testing등 다양한 것에 대해서 공부하고 실험해보는 시간을 가졌다. 연말에 주어진 2주 휴가기간동안 Istio를 Minikube에서 이런저런 실행해보면서, Service mesh가 우리가 가진 문제점을 해결해줄 수 있지 않을까 고민해보기도 했다. Domain Driven Design을 연구하면서, 이 방법론으로는 우리가 저지른 실수를 예방할 수 있지 않을까 고민하기도 했다. 유투브에 남아 있는 PyCon 발표 영상, AWS community day 발표 영상들이 나의 흑역사로 남아 있지만, 그래도 그만큼 열정적이고 도전하는 시기었다.

이번에 Kubernetes Community Days에서 발표를 하면서 지금까지 내가 만든 흑역사 중에 최고 흑역사를 만들었다. 마지막까지 발표자료와 데모 시연 자료들을 정리하느라, 30분 시간에 맞춰서 내용을 잘 전달하는 것에 대해서 연습을 하지 못 했다. 30분이라는 발표 시간동안 너무 많은 것을 담으려고 했고, 또한 라이브 코딩을 하면서 진행을 했다. Ubuntu를 VM에 띄어서 별도의 namespace를 가진 process를 띄우고, root directory도 격리하고, cgroup으로 memory OOM 나는 것도 직접 명령어를 치면서 설명을 하였다. 이렇게 격리된 namespace에서 veth로 통로를 만들고, route rule로 하나의 container에서 다른 container로 패킷을 보내는 것을 시연하였다. 이렇게 하고 나니 이미 25분이 지나버렸다. 정말 시간이 순식간에 지나가버렸다. 하는 수 없이 나머지 내용들은 별도로 Community 세션으로 준비하여 설명해드리겠다고 말씀드렸다. 나머지 내용들은 Preview처럼 어떤 내용들을 설명하려고 했는지 훑어 보는 시간만 가지고 발표를 마무리 해야했다. 데모 시연들을 위해서 열심히 다양한 자료들을 준비했는데, 애당초 30분안에 이것들을 다 설명하는 것은 적합하지 않았다. 이렇게 나는 대왕 흑역사를 하나 또 생산했고, 이 대왕 흑역사는 유투브상에 남게 될 것이다.

발표를 마치고, 이렇게 발표에서 시간 관리를 못한 것이 많이 창피했다. 지금도 생각하면 창피하다. 시간을 내서 내 발표를 들으러 온 사람에게 미안한 마음도 있었다. 하지만 그래도 발표를 마치고 질문 시간에 해당 내용들이 정리된 블로그나 자료들을 확인할 수 있는 곳이 있는지 물어보는 사람도 있었다. 그리고 강단으로 찾아와서 뒤에 내용들을 들을 수 있었으면 좋겠다고 이야기 하시고, 쿠버네티스 그룹에서 세션이 진행되면 꼭 참석하겠다고 말씀하셨다. 누군가에게는 알고 싶은 내용이었다고 생각하니 긍정적인 마음이 다시 생겼다. 그리고 발표에서 말씀드린 것처럼, 하반기에 쿠버네티스 그룹에서 더 여유롭게 내용들을 하나 하나 잘 전달할 것이다. 하반기에 진행하려고 하는 세션은 정말 만족스럽게 잘해서, 흑역사가 아니라 자랑스러운 세션이라고 당당히 말할 수 있게 준비해보자.

새로운 것을 알게 되는 기쁨

어떠한 경지에 오르는 과정을 고단하다. 내가 모르는 내용들을 채워나가면서 발표 내용들을 준비하는 과정들은 고단했다. 시간을 쪼개서 이런저런 공부하고 테스트하는 시간들을 가졌다. 내가 설명하려면 확실히 알고 있어야 하기 때문에, 내가 아는 것들이 정확한지 직접 구동을 해보면서 확인하였다. 내가 발표를 하겠다고 신청했고, 그 시간이 정해져 있었기 때문에 가능했다. 과정은 고단했지만, 그 과정에서 여러가지 새로운 지식들을 가지게 되었다.

kindnet은 route rule에서 192.168.55.1로 가게 하고, veth pair가 이제 192.168.55.1 주소를 가지게 된다. 따라서 route rule에 의해서 IP로 찾아가고, host의 veth pair에 오면 route rule로 다른 interface로 forward된다. 하지만 calico는 local-link address인 169.254.1.1로 가게 하고, 해당 veth pair가 proxy arp역할을 해서 해당 packet이 오도록 한다. 따라서 host의 veth interface는 별도의 ip address 설정없이 packet이 찾아 올 수 있다. 그 이후는 동일하게 route rule을 통해서 찾아가게 된다. 그래서 문서에서는 이렇게 설명되어 있다. 처음에는 이 문서의 내용이 이해가 안되었는데, 이해하게 되었을 때의 소소한 행복감이 찾아온다!

Note how the Pod routing is set up so that all the traffic, including the intra-subnet Pod-to-Pod communication, is sent over the same next-hop. This allows for all Pods to be interconnected via L3 without relying on a bridge or ARP for neighbor discovery.

cgroup v1과 v2의 차이점도 알게 되었고, 이제 간단하게 cgroup을 통해서 memory limit을 설정할 수 있게 되었다. Kubernetes에서 어떻게 memory swap을 관리하는지 알게 되었고, 1.22부터 kubelet 설정 flag를 통해서 swap을 사용할 수 있게 되었다는 것을 알게 되었다. Iptables에서 mark를 남겨서 Control할 수 있다는 것도 알게 되었다. 이렇게 준비를 하면서 알게 된 것들은 고단함을 지나고 얻은 달콤한 열매이다. 흑역사를 남겼지만 이렇게 다시 한번 고단함에서 맛보는 달콤함을 경험했다.