Who and Why am I here?
제 소개와 연락처입니다. 각 페이지 맨 아래에
또는 댓글 한마디 남겨주심 그저 좋아라~ 합니다.
최근 글
목록
Search

프라이베르크 도시 및 광산 박물관 정면에 위치한 프라이베르크 대성당(Dom St. Marien)을 뒤로하고 한 컷. 박문호 박사님과 라이프치히에서의 술 멤버 및 버스와 식사 시간에 이 탐사와 과학 관련 여러 의견을 나누었던 일행 분과 함께. 검정 옷 입길 잘했다. 똥배가 안보인다. 박사님의 사모님 작품.
독일 프라이베르크(Freiberg)
5일차(2025.09.03) 오전
여느 때와 마찬가지로 호텔에서의 새벽 강의로 하루를 시작. 강의 잘 듣지도 않는데 피곤해서 걍 재낄려했더니만 나만큼이나 강의에 진심이 없는 룸메이트 형님은 가겠단다. 한번 빠지기 시작하면 계속 빠지게 된다고. 그 말을 듣고보니 뭔가 나두 잘못하는거 싶어 따라 나섰다.
룸메이트 형님은 여행 내내 아침마다 내가 불러재끼는 케데헌의 Golden을 감당해야 했는데, 단순히 듣는거 뿐 아니라 노랫 가사의 ‘up, up, up’이 나올 때 마다 ‘손들고 위로 푸시’ 율동(?)을 따라하는 수고까지 감내해야만 했다. 부디 하루를 힘차게 열자는 뜻으로 그랬던거니 동생님의 이런 기특한 맘을 해아렸기를…(끝까지 따라하신거 보면 그런거 같다
)
여튼, 새벽 강의 듣고 호텔 조식 먹고 좀있다 버스타구 프라이베르크(Freiberg)로 출발. 일정 상으론 원래 라이프치히 가기 전에 여길 먼저 들르고 가야하는건데. 이제야 지도를 보니 프라하와 라이프치히 중간에 위치해서 원래 일정 대로 가는게 맞긴 한데 차막히구 뭐하구 해서 그런 거 같다. 여하튼 도착한 곳은 도시 및 광산 박물관(Stadt- und Bergbaumuseum; 공식 홈페이지 링크).
전술했듯 광물에 별 관심이 없기에 박문호 박사님의 열강을 뒤로하고 홀로 후딱 둘러본 먼저 나와서 담배 피기를 시전. 이 박물관은 쌔삥임에도 정작 영어 설명이 없다. 광물 전시는 지하에, 1층은 기념품 샵 및 로비, 2층은 작센 선제후 아우구스트란 사람에 대한 특별전으로 선제후란 신성로마제국 황제 투표권을 가진 제후를 뜻한다. 프라하 편에서의 금인 칙서 설명 참조.
사실 상 이 도시는 점찍고 가는 수준이라 뭐라 말하기 어렵지만, 박물관 가는 버스를 통해 도시를 가로지를 때나 박물관 앞에서 느꼈던건 사람이 너무도 안보였다는 거. 뒤져보니 중세에는 은 광산으로 번성했지만 지금은 프라이베르크 공과 대학 중심의 대학 도시라고. 인구 4만명 수준이라나. 여하튼 사람 없어 보였던 이유는 이걸로 퉁친다.
이후 우리는 바로 버스타고 포츠담으로 향했다. 아래는 이 글을 쓰는 시점에 알게 된 것들과 생각이다.
맨 앞 사진의 벽은 프라이베르크 대성당(Dom St. Marien; 성당이라 불리지만 루터교회이다. 역시나 카톨릭 교회에서 종교개혁 후 바뀐 것)이다. 프라이베르크에서 딱 한군데만 관광할 경우 추천지로 여길 꼽는다. 우리는 딱 한군데 방문한 곳이 이 광산 박물관이었고. 나아가 이 박물관의 정식 명칭에는 ‘도시’가 들어있기에 ‘도시’ 역시 보지 못한 셈이다(방문했던 현대 건축물이 아닌, 양쪽의 누런 전통 가옥이 ‘도시’를 담당하는 듯 보인다). 이게 부조리해보일 수 있지만, 앞서도 논했듯 이 학습탐사 주제는 ‘과학’, 게다가 대성당 등은 일정에 없던 곳이라… 그냥 아쉬울 뿐
. 가만, 뒷걸음치다 얻어걸린 듯 어쨌건 대성당 외벽 사진은 얻었으니 이것도 ‘방문’하긴 한건가 ㅎㅎ
추가로, berg는 산 또는 언덕을, frei는 영어의 free를 의미한다. 해서 Freiberg란 이 도시 이름은 광산 채굴권을 가졌던 '자유 광부’에서 유래한다나. 이걸 굳이 논하는 이유는 독일엔 e → u의 한끝 차이인 Freiburg란 도시도 있기 때문이다. burg는 성 또는 요새를 뜻한다고. 여기가 인구도 훨씬 많고 환경 도시로 유명하다네.
북유럽 여행기(a.k.a. 학습탐사): 독일 프라이베르크(Freiberg), 포츠담(Potsdam)
프로젝트s
박문호
북유럽 여행
프라이베르크
포츠담
아우구스트
광산 박물관
아인슈타인 타워
상수시 궁전
2025/10/12

라이프치히 성 토마스 교회에 위치한 존 세바스찬 바흐(Johann Sebastian Bach) 동상 앞에서. 이 감격스러운 포인트에서 의도하지 않게 함께 찍힌 여자 아이는 뱅크시(Banksy)의 ‘풍선을 든 소녀’를 연상케한다. 이쁘기두 해라 
독일 라이프치히(Leipzig)
체코 프리브람에서 독일 라이프치히(Leipzig)로 가는 와중, 이 도시 이름이 상당히 내게 익숙한 데 정작 아는게 없단 생각이 들었다. 분명 라이프니츠(Leibniz)와 구분은 하는데 말야. 잠시 구글링을 해보니 당장 제일 먼저 나오는게 바흐(Johann Sebastian Bach)이다. 이 땜시 그리 익숙했던 것이었으니… 어머, 여긴 가야해! 이 도파민 분출의 내 모습은 BTS를 고대하는 ARMY에 비견된다고나 할까.

라이프치히와 바흐의 관계를 안 순간의 내 마음을 가장 적절히 표현한 ‘회화’. 대상의 매력이 주체의 감정을 압도한 순간을 적절히 표현한 수작으로, 매우 유명함은 물론이거니와 실용적이기까지 하다.
그나저나 이 말에 ‘팝 아트’를 연상했다면… 넌 누구냐!
바흐는 그야말로 나의 최애 음악가인데, 왜 그리도 애정하는지는 설명하기 쉽지 않다.
귀하의 성향을 나타내는 미학적 가치는 진정성(Authenticity), 반키치(Anti-Kitsch), 구조(Structure), 정제(Refinement)로서, 이에 바흐가 가장 적합합니다.
Gemini AI의 분석인데, 무지 현학적으로 보이기에 맘에는 안들지만 그나마 이게 가장 정확한 설명일 듯하다. 빈에서 낭만파와 베토벤을 폄하했던 내 마음에 대한 변명도 되고. 또한 엔지니어라 이런 성향이 당연할지도 모른다. 어쨌건
연주곡 : J.S.Bach BWV565 - Toccata and Fugue in D minor,
연주곡 : J.S.Bach BWV578 - Fugue in G minor 를 포함해, 바흐는 예나 지금이나 내 연습곡의 대다수를 차지한다.
바흐는 박문호 박사님의 버스 안 강의에서도 언급되긴 했는데, ‘바흐는 시냇물이 아니라 바다라 불려야 한다(바흐 뜻이 시냇물이라고)’란 베토벤의 바흐에 대한 평을 전하는 것이 사실 상 전부다. 박사님은 과학, 역사 분야와는 달리 예술 쪽으로는 약하다는 생각이 확신으로 바뀌는 순간이었다. 빈에서의 미술사 박물관 스킵 건도 있고 해서.
금번 탐사의 주요 주제이자 박사님이 그리도 애정하는 ‘대칭’. 사실 그는 바흐를 제대로 알면 나처럼 빠질게 분명한데, 그 역시 상기 네 가지의 내 미학적 성향 모두를 가질 뿐 아니라 대칭은 대위법(Counterpoint)에 내재한 핵심 장치이기 때문이다. 대위법은 바흐를 대표하는 작곡 기법으로, 후려쳐 정의하자면 ‘두 개 이상의 유사 선율(voice)을 교차 배치함에도 전체 사운드가 조화롭게 들리도록 만드는 작곡 기법‘ 정도된다(내가 프로 음악인이 아님을 고려해서 받아들여지길).
후에 “대칭을 주요 소재로 다루는 괴델, 에셔, 바흐(GEB)를 아실텐데요, 바흐는 분명 좋아하실거에요”라며 박사님께 권해드렸는데, 이 책은 안 읽어보았고 바흐는 좀 더 공부해봐야겠다라 하신다.
4일차(2025.09.02)
북유럽 여행기(a.k.a. 학습탐사): 독일 라이브치히(Leipzig)
프로젝트s
박문호
북유럽 여행
라이프치히
Leipzig
바흐
대위법
Counterpoint
성 토마스 교회
라이프니츠
Leibniz
추론 계산
이진법
앨런 튜링
클로드 셰넌
폰 노이만
조지 불
2025/10/07

프라하 구시가지 광장(Staroměstské náměstí, Old Town Square)에서. 프라하 역시 일전 유럽 배낭 여행에 다녀갔던 곳이라 별 감흥이 없다.
체코 프라하(Praha)
프라하 역시 예전 유럽 배낭 여행 때 다녀온 곳으로, 다녀왔던 적지 않은 유럽 도시 중 가장 ‘이쁘장한’ 도시로 기억한다. 당시 이 곳을 찾았던 이유는 구 소련 영향을 받던 동구권 도시라 후질구래할거란 선입관에도 미션 임파서블 1에 보이던 프라하 전경이 꽤나 인상적이었던 어릴 적의 기억 때문. 냉전 때의 유명한 민주화 운동이었던 프라하의 봄도 한 몫 했겠고. 하지만 무엇보다 큰 맥락은 퀸의 보헤미안 렙소디이겠지(보헤미안이란 자유로운 영혼을 의미하며, 집시와 연관되는 것도 이 때문이라고).
여하간 그런 도시인데, 이 걸로 글을 시작한 이유는 빈과 마찬가지로 이미 다녀간 곳이라 별 감흥이 없었기 때문이다. 여기는 연인하고나 올 곳이다. 근데 어쩌겠어 일정에 떡하니 박힌 곳인걸. 떡하니 박힌 이유는 이 여행의 주요 테마인 신성로마제국에 꽤나 의미있는 곳이기 때문으로 보인다.
탐사 전부터 신성로마제국의 7선제후를 (책과 강의에서) 지겹게 보고 들었는데, 보헤미아 국왕 겸 신성로마제국의 황제였던 카를 4세가 금인 칙서(Goldene Bulle)을 통해 이 황제 선출 제도를 확정했다고. 프라하는 이 카를 4세 때 보헤미아 겸 신성로마제국의 수도였다. 또한 카를 4세가 세운 카를 대학교(Karlova Univerzita)는 중부 유럽 최초의 대학이었다나. 여튼 이 도시는 죄다 카를이다. 카를교, 카를 대학교, 그가 세웠다는 가장 이쁘장해 보이던 성 비투스 성당, 그가 프라하를 중세 유럽 최대 규모 도시로 만들었다는 신시가지(Nové Město) 등등.
어쨌건 카를4세는 게르만의 후예이고 체코인 입장에선 타 민족이기에 싫어할 법도 한데, 그는 현대 체코인이 가장 존경하는 인물이라고. 우리나라의 세종대왕 즈음으로 인식되는 위인이라나.
2일차(2025.08.31)
여하튼 어찌저찌 빈(Wien)에서의 여정을 끝내고 버스로 체코 프라하로 갔다. 프라하에서의 일정 시작은 저녁 식사로, 프라하의 새로운 가이드가 이끈 곳은 한국인이 운영하는 한국 식당.
버스가 들어갈만한 거리가 아니라 버스에서 내려 도보로 얼마간 이동해서 도착했는데, 이 식당이 위치한 거리 내내 한글 간판의 식당이 꽤 보인다. 게다가 배낭 여행 당시 머물렀던 호스텔과도 비슷해보이는 위치여서 당시 생각이 모락모락. 어쨌건 이들 식당 중 하나를 지나치는데, 주인장인지 모를 어떤 분의 우리 일행을 바라보는 표정이 별로 좋지 않다. 나중에 밥먹었던 식당 측 이야기를 잠시 들었는데, 이 지역에 한국인 식당이 꽤 모여있는데 (경쟁 관계 때문인지) 사이가 별로 안좋다고. 뭐 사정이 있겠지만 멀리 타지에서 좀 거시기하다는 생각이 든다. 쪽팔리게스리.. 게다가 지금은 K-시대인데.

찍은 사진이 없어 Google Map에 있는 사진을 긁어왔다. 갔던 밥집이 여긴지도 긴가민가하는데, 대충 비슷한 거리 분위기였기에 이걸로 대체한다. 출처: https://maps.app.goo.gl/ZmXRUoaS1RXbAmZp7
북유럽 여행기(a.k.a. 학습탐사): 체코 프라하(Praha), 프리브람(Příbram)
프로젝트s
박문호
북유럽 여행
프라하
Praha
프리브람
Pribram
카를4세
가이드
광산
Lucy
오스트랄로피테쿠스
Pilsner Urquell
2025/10/05

볼츠만 묘비석 앞에서. 물리학에서나 S/W Engineering에서나 엔트로피의 중요성을 고려하자면, 볼츠만 묘비석 방문은 내게 큰 의미를 갖는다. 문제는 이 비석 정면에 떡하니 이동식 화장실이 놓여 비석을 가로막고 있었다는 거. 아니 오스트리아 사람들 재정신인가? 인류사에 손꼽히는 발견을 이룬 위인을 이따위로 취급하는 게 말이 되냐는 뜻이다.
오스트리아 빈(Wien)
1일차(2025.08.30)
카타르 도하에서의 환승을 거쳐 오스트리아 빈에서 탐사가 시작되었다. 이 탐사는 절대 빈 시간이 없다. 비행기에서 내리자마자 카르눈툼(Carnuntum)이란 고대 로마의 유적지로 이동. 여기를 방문한 이유는 소위 ‘카르눈툼 회의’라 하여 동서 로마의 정제(아우구스투스), 부제(카이사르) 간의 지위 조정을 통해 당시의 혼란을 (일시로 나마) 안정시킨 사건 때문이라고. 예나 지금이나 교통 정리는 무진장 중요한 듯.
실제 역사적 유적지란 점만 빼면 대강 울나라 민속촌 같은 곳인데, 고대 로마 당시의 건축물을 아주 그럴듯하게 복원해놨다(유적지라 건축터 말고 실제 남은 건축물은 없다). 새삼 놀랐던건 외양 면에선 현대 건축물과 큰 차이가 없단거, 무엇보다 콘크리트를 이 때도 사용했단 점. 로마 당시 복장으로 요리를 하던 유적지 측 묘령의 여인으로부터 빵을 얻어 먹으며 잠시 이야기를 나눴는데 그걸 사진으로 못 남긴게 한이다(내 스타일은 아니어도 이쁘긴 했는데…).

로마군 투구 모형을 쓰고 놀고 있는 나. 난 벌써 이 시점부터 이러고 따로 놀고 있었다. 대부분의 다른 탐사 대원은 박사님을 따라 열심히 강의 듣고 있는 와중에. 카르눈툼 기념품 샵에서.
카르눈툼에 이어 간 곳은 빈 중앙 묘지(Wiener Zentralfriedhof)로 유명 예술가, 학자들이 묻힌 곳이라고. 여기에 유명한 사람은 클래식으로 유명한 도시 답게 베토벤, 슈트라우스, 슈베르트, 브람스 등이 있지만 이들보다 훨씬 중요한 사람은 루트비히 볼츠만(Ludwig Boltzmann). 실제 이 때문에 박사님이 여길 방문지로 선택한 것으로 이해한다(본 글 맨 처음 사진 참조).
볼츠만은 그 유명하고도 중요한 엔트로피(Entropy)를 미시 분석 가능한 개념으로 재정의한 위인으로, 사실 상 정보 엔트로피의 원 저자이기도 하다. 정보 엔트로피는 '비트(bit)' 개념을 만든 정보이론의 클로드 셰넌(Claude Shannon)이 정립한 것으로, 이들 두 엔트로피 공식은 개념적 구조가 동일한데, 셰넌의 정의는 볼츠만의 물리학이 아닌 정보이론 맥락에서 만들어진 게 중요하다. 셰넌의 정의는 볼츠만의 그것에서 영감을 받은 결과이고. 따라서 셰넌은 내가 몸담은 S/W Engineering의 아버지(?) 격이라면, 볼츠만은 할아버지 격이다. 참고로 AI 클로드는 클로드 셰년의 이름에서 따온거다.
아래와 사진과 같이 베토벤이니 슈베르트니, 슈트라우스니, 브람스니 이들 유명 음악가 묘비석도 사진 찍어 ’주었지만’ 솔직히 이 양반들에겐 관심 없다. 난 낭만주의를 싫어한다. 감정 과잉이다. 베토벤은 낭만파도 아닌 주제에 개오버인데, 장중함이란 특유의 똥폼까지 갖췄으니 말 다했다.
여기까지가 이 도시에 도착하자마자의 행보이고, 저녁 먹으러 Alter Bach-Hengl란 이름의 오스트리아 전통 선술집/식당에 갔는데 300년 이상된 곳이라고. 헌데 어찌나 음식이 짜던지… 아래 사진에도 보이듯 전형적인 서양식 음식인데, 개인적으로 서양식, 특히 소시지 등 고기류를 좋아라 함에도 몇점 집어 먹다 말았다. 가이드 왈, 유럽 음식은 원래 짜다고 하지만 정작 윗동네로 가선 별로 그걸 못 느꼈다. 이 선술집이 와인으로 유명하다던데 정작 와인이 주문안된 건 함정. 이는 아마도 술을 못드시는 박사님 성향에 비롯된 듯 하다.
마침 앉은 자리가 8명으로 이루어진 우리 조 멤버 중심으로 이루어졌는데, 박사님의 최애 오른팔이신, 탐사 사전 스터디를 이끄신 우리 조장님이 마침 옆에 있어 물어보았다.
북유럽 여행기(a.k.a. 학습탐사): 오스트리아 빈(Wien)
프로젝트s
박문호
빈
Wien
Vienna
학습 탐사
북유럽 여행
클로드 셰넌
루트비히 볼츠만
2025/10/01

박문호 박사님과 함께한 전체 북유럽 학습탐사 코스. 푸른 선은 모조리 버스 이동이다. 14박 15일(25.08.30 ~ 25.09.14) 일정(출발은 25.08.29 밤)으로, 월말 김어준팀 20명 + 박문호의 자연과학 세상(소위 박자세. 홈페이지 링크)팀 20명 + 알파 4명(박사님을 포함한 staffs)과 함께.
나의 두 번째 교주님(!)인 박문호 박사님과 함께한 북유럽 여행기이다.
Prologue
여름 휴가로 다녀온 이 여행의 정식 명칭은 아래 월말 김어준의 Youtbe 링크에 드러나듯(해당 이벤트를 통해 갔다) ‘박문호 박사와 함께하는 북유럽 7개국 학습 탐사’. 탐사 주제는 입자물리학 + 신성로마제국 및 스칸디나비아를 포함한 주변 지역사. 무시무시하다.
우리가 북유럽에 가는 이유 #과학 #박문호
우리는 왜 북유럽에 가는가?
입자물리학, 피치블렌드, 방사선, 핵변환, 대칭
전자공학박사 박문호
〔월말 김어준〕 25년 6월호 바로가기
https://www.podbbang.com/magazines/1778990/issues/4409
〔월말 김어준〕 인스타그램 바로가기
https://www.instagram.com/kimoujoon_audio_magazine

https://www.youtube.com/watch?v=wwMWO9e-OcE

월말 김어준에서 진행하는 여행 이벤트 중 하나로, 본 학습 탐사 주제가 드러난다. 내가 특히 끌린 지점은 ‘대칭’. 이 ‘대칭’ 땜시 적어도 내겐 난데 없는 아벨 기념관까지 가게 된다. 유명하다는 수학의 ‘아벨상’의 그 아벨 맞다.
내게 있어 박문호 박사님이 왜 교주님인지는
공부법 핵심: 대칭화, 모듈화, 순서화를, 그의 생각은
박문호 박사의 ‘철학’ 을 참조하면 된다. 참고로, 저 글을 쓰는 시점에는 직접 뵈고 대화를 나눈 사이가 아닌지라 ‘님’이란 존칭을 뺐지만 이제는 도저히 그럴 수 없다. 14박 15일의 쉽지 않은 함께한 기간은 물론이요, 수 차례에 걸친 그와의 식사 시간, 무엇보다 작별 인사 말씀으로 “자네는 내 젊은 시절을 보는 것 같군”이란 나에 대한 평까지 ‘하사’ 받았기 때문이다. 나아가 이 말씀에 자부심이 차오르고, 곱씹을 수록 기분이 좋아지는지라.

독일에서 덴마크로 넘어가기 위해 거쳐간 Lübeck 항에서 박문호 박사님과 함께. 이 사진을 찍기 전까지 그와 나누었던 토론(?) 주제는 ‘자유의지란 존재하는가’. 유명하기 짝이 없는 이 질문에 그는 답하길, 그간 ‘없다’가 주류였는데 다시금 ‘있다’가 떠오르고 있다는 신경과학계의 트랜드를 전했다. 박사님 본인의 입장도 함께 물었지만 명확한 답변을 얻지는 못했다.
‘학습 탐사’답게, 탐사 전 한 달부터 무지막지한 숙제와 강의가 이어졌지만, 교주님으로 모시는 내 태도와는 달리 극히 일부만 소화했다. 숙제와 강의를 간단히 요약하자면, 프랑스, 독일 중세 역사 달달 외우기에 관련 서적 7권 읽기, 그리고 박사님 진행의 매주 목요일 3시간 화상 강의. 그 끔찍한 왕이름 순서 외우는건 기본 중 기본이다.
암기 자료는 가히 박사님의 오른팔이라 할 수 있는 두 분 조장님이 제공했는데, 대강 중고등 시절 많이 쓰던 시험용 요약 메모라 보면 된다. 여하튼 이중 내가 소화한 건 책 세 권(30개 도시로 읽는 독일사, 주경철의 유럽인 이야기, 이야기 독일사)에 띄엄띄엄 들은 화상 강의 뿐인데, 일단 암기는 나랑 안맞고, 역사책을 세 권이나 읽은 마당에 나머지 네 권 역시 전부 역사책이라 질렸기 때문이다(그래도 유럽사 속의 전쟁은 재미있어 보여 사 두기만 했다. 현 시점까지 안 읽은 건 함정). 강의를 띄엄띄엄한 건 내가 언제부터 누구 말 듣는 인간이었다고... 가 아니라, 스스로 동기부여가 안되면 집중이 안되는 고질병(?) 때문이다. 탐사 전반의 주제는 내 관심사와 일치하지만, 강의 각각의 각 세부 주제까지 그러하기는 쉽지 않은 일이다.
‘학습 탐사’는 뭐랄까, 끝없는 강의의 연속이라 하면 과장 조금 보탠 무엇이다. 강의는 새벽 6시부터 시작된다. 거의 매일! 한 시간 동안 진행되는 이 강의는 본 여행에서 상당 시간을 보낸 버스 안에서도 이어지는데, 버스 안에서의 시간 최소 2/3가 그 또는 가이드의 강의이다. 이게 끝이 아니다. 답사지 방문 내내 계속된다.

비오는 날 호텔 밖 처마(?) 진행된 새벽 강의. 이런 와중에 강의 내내 대다수가 수첩에 받아 적고 있다. 보통 호텔 로비 구석이나 식당에서 강의가 진행되는데, 이날은 호텔 측이 장소 제공을 거부해서 옆건물, 게다가 밖에 서서 진행 되었다. 체코 프라하.

이 강의가 새벽 6시가 채 안된 시점임을 보여준다. 앞서 논했듯 난 관심 없는 주제듣는 데 잼병이기에, 상당 부분, 특히 여행 뒤로 갈 수록 이렇듯 강의 시간을 딴짓으로 일관했다.
북유럽 여행기(a.k.a. 학습탐사): Prologue
프로젝트s
박문호
북유럽 여행
학습 탐사
Prologue
암기
이해
학습법
2025/09/30

Envoy의 resiliency metrics으로 Grafana에서 Resilency 모니터링을 구성한 대시보드. Timeout, Retry, Circuit Breaker(Outlier Detection), Rate Limiting이외에도 Request Queue의 상황을 Inbound, Outbound 모두에 대해 나타내고 있다.
Introduction
앞선
Istio resiliency 기반 장애 대응: feature 별 상세의 적정 설정 값을 얻기 위해서는 결국 반복적 테스트가 최선이다. 또한 설정 이후 운영 시점에서도 설정 값 조정은 다반사가 될 것이기에, 모니터링 도구가 필수이다. 본 모니터링을 위해 Istio, Envoy에서 제공하는 metric을 논한다.
Istio 기반 resiliency 관련 metric
Access logging — envoy 1.35.0-dev-cdf3dd documentation
Access logs are configured as part of the HTTP connection manager config, TCP Proxy,
UDP Proxy or
Thrift Proxy.
https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#config-access-log-format-response-flags
Istio response_flags의 값 목록. Envoy가 제공함을 알 수 있다. Istio response log에도 해당 값이 나타난다.
Istio의 metric은 (까보지는 않았지만) 사실 상 Envoy metric을 사용하기 좋도록 wrapping한 것으로 추정된다. 특히나 resiliency 영역이 그러한데, Istio는 별도 resiliency metric을 위한 별도 metric을 제공하는 대신 istio_requests_total 의 response_flags label을 통해, Envoy가 생성한 해당 request에 대한 resiliency 현황을 요약하기 때문이다.
Istio 공식 문서에서 언급하듯이 response_flags 는 Envoy Access Log의 response 상세 코드로서, HTTP status code보다 훨씬 더 상세한 response 원인을 제공한다. Resiliency 관련 flags는 별도로 highlight 처리 했다.
Envoy 기반 resiliency 관련 metrics
Envoy metrics는 Istio와는 비교 불가할 정도로 많은 metric을 제공함과 동시에 제공되는 정보 역시 깊다. 문제는 Istio metrics 대비 사용하기가 어렵다는 점으로, 이를테면 request 갯수를 얻기 위해 Istio는 istio_requests_total 단일 metric만 사용하여 upstream 또는 downstream용인지는 여러 label(e.g. source_app, destination_service)을 통해 구분이 가능한 반면, Envoy는 upstream용과 downstream용 metric이 나뉘어 있음과 동시에 counter part를 쉽게 식별할 label이 없다.
나아가 downstream용에는 upstream용과는 달리 resiliency 관련 metrics가 없기에 오직 upstream용 metrics 만을 사용해야 한다. 이는 달리 표현하자면 resiliency metric이 오직 client side에서만 만들어진다는 뜻인데, Timeout, Retry, Circuit Breaker가 client side에서 동작함을 떠올려보면 당연한 일이기도 하다( 참조).
Statistics — envoy 1.35.0-dev-d87007 documentation
The cluster manager has a statistics tree rooted at cluster_manager. with the following
statistics. Any : character in the stats name is replaced with _. Stats include
all clusters managed by the cluster manager, including both clusters used for data plane
upstreams and control plane xDS clusters.
https://www.envoyproxy.io/docs/envoy/latest/configuration/upstream/cluster_manager/cluster_stats#timeout-budget-statistics
Upstream 관련 Envoy metrics. Timeout, Retry, Circuit Breaker(Outlier Detection)의 resiliency 관련 metric을 포함한 전방위적 upstream 대상의 metrics가 제공된다.
Statistics — envoy 1.35.0-dev-c12fef documentation
Every connection manager has a statistics tree rooted at http.<stat_prefix>. with the following
statistics:
https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/stats
Downstream 관련 Envoy metrics. Istio와는 달리 Upstream / Downstream 용 metrics가 나뉘어있는 한편 내용은 달라 본 metric에서는 resiliency 관련 metrics가 없다.
Istio resiliency 기반 장애 대응: 모니터링
as S/W 엔지니어
Istio
Envoy
resiliency
timeout
retry
circuit breaker
rate limit
metric
Prometheus
2025/07/20
Introduction
아래의 golang 공식 SDK를 기준으로 proxy-wasm plugin을 빌드하는 방법과, 추가로 Istio 환경에서 배포 및 테스트하는 방법에 대해 설명한다.
상기 SDK는 다양한 내용을 포함하지만, 여기서 참조한 내용은 다음과 같다.
•
다양한 예제(examples 폴더 내) 중 Helloworld: 주요 기능(REQ/RES header, query string, path, body 변경, 주기적 실행(timer) 등)에 대한 예제 제공. 본 가이드는 주기적으로 로그를 뱉는 helloworld 만을 다루지만, 빌드 방법은 타 예제에 대해서도 동일하다.
•
빌드를 위한 전체 절차: 기본 빌드 방법 및 Makefile 기반한 자동화 및 구체 실행 절차
참고로, 이 SDK는 Proxy-Wasm 자체에 대한 상세 설명도 함께 제공하는데, Proxy-Wasm root 문서보다도 훨씬 더 자세하여 지금껏 보았던 그 어떤 문서보다 났다. 동일 주제를 다루는
Proxy-Wasm overview 작성 시 이를 몰랐다는게 아쉬울 지경.
Prerequisite
•
golang 설치
•
docker 설치
•
OCI Image repository(e.g. dockerhub)
참고로 SDK의 README 가이드는 envoy 역시 설치를 요구하지만, macOS에 (brew를 통해) 설치되는 envoy는 default WASM runtime인 V8이 빠져있기에 실행이 안되기에 해당 step은 제외하였다. 따라서 테스트는 별도 Istio 기반의 istio-proxy에서 교체하였다. 그러므로 테스트를 위해서는 아래가 필요하다.
•
k8s 환경 내 동작하는 istio-proxy
golang으로 Proxy-Wasm 빌드&테스트 하기
as S/W 엔지니어
Proxy-Wasm
Envoy
WASM
WasmPlugin
Istio
golang
2025/06/13
Introduction
앞선
Istio resiliency 기반 장애 대응: overview 에 대한 상세 설명과 대응 방법, 추천 설정이다. 유의 사항으로 모든 추천 설정은 일반적 웹 서비스를 가정한 값이므로 적정 값은 각 서비스에 따라 상당히 달라질 수 있다. 쉽지 않지만 반복적 테스트를 통해 얻기를 강력 추천한다(특히, Circuit Breaker, Rate Limiting). 참고로, 이어지는
Istio resiliency 기반 장애 대응: 모니터링에서는 테스트와 운영을 위한 metrics 및 설정 방법을 논한다.
Timeout
Timeout은 최대 응답 지연을 보장함과 동시에, 클라이언트 자원 고갈 문제를 방지하는 fast fail 기법으로, Circuit Breaker와 함께 클라이언트 자원 고갈 문제를 해결하는 주요 수단이다.
대응 문제
•
높은 지연 (
주요 대응): 클라이언트의 오랜 대기를 방지한다. 최대 응답 지연 보장 효과이다.
•
클라이언트 자원 고갈 (
주요 대응): 오랜 대기로 인한 자원 고갈 문제를 제거한다. 마이크로서비스의 클라이언트는 받은 요청 처리를 위해 서버를 호출하기 마련이다. 즉, 받은 요청 만큼 서버 호출을 위한 자원 소비량은 늘어난다.
•
연쇄적 장애 (
부분적 대응): 클라이언트 자원 고갈로 인한 장애로의 발전을 사전에 차단한다. 하지만 서버 자원 고갈로 인한 장애는 해결하지 못하기에 한계가 있다. 서버 자원 고갈 대응안은 Rate Limiting이다.
유의사항, 설정 방법, 추천 설정
•
•
설정 방법: https://istio.io/latest/docs/reference/config/networking/virtual-service/ 의 timeout field 및 예제 참고한다.
•
추천 설정: 호출 대상 API의 latency을 고려하는 것이 가장 중요한데, P99 값은 timeout으로 자주 사용되는 값으로 논의된다. 참고로, 웹 사용자는 일반적으로 2~3초 내 응답을 기대한다고(AI 피셜). 또한 AWS Lambda function 역시 default timeout은 3초이다.
Retry
Istio resiliency 기반 장애 대응: feature 별 상세
as S/W 엔지니어
Istio
resiliency
timeout
retry
circuit breaker
rate limit
Envoy
outlier detection
회복탄력성
2025/05/24
Introduction
Istio는 다양한 resiliency features, 즉 Timeout, Retry, Circuit Breaker, Rate Limiting을 제공하지만, 이러한 다양성이 오히려 각기 어떤 문제에 대한 해결책인지 구분이 잘 안되는 혼선을 일으키고는 한다. 이는 마치 개발 시 요구사항이 불분명하거나 동일 요구사항에 대한 각기 다른 솔루션이 제시된 상황과 비슷하다. 또한, 잘못된 설정은 시스템 안정성을 직접적으로 위협하는 와중에 설정 자체가 까다롭기까지 하다. 따라서 명확한 이해가 더욱 요구된다.
본 문서 및 이어지는
Istio resiliency 기반 장애 대응: feature 별 상세,
Istio resiliency 기반 장애 대응: 모니터링은 이에 대한 대응으로, 이해와 함께 구체적 실행 방법을 요약한다.
참조 문서는 Istio, Envoy, Kubernetes 공식 문서 및 AI(주로 Grok, Gemini. Claude는 그림 정도…)이며, AI의 환각 이슈 대응도 함께 하였다(AI 간 cross checking, 타당성, 일관성 중심 검토). 용어는 되도록이면 canonical term을 쓰려고 ‘노력’했다(별도 권위있는 문서는 찾아볼 여유가 없었단게 변명 아닌 변명. 그나마 아래 Google SRE book을 일부 참조했지만 문서 작성 막바지에야 알게 되어서리…).
이외에 실험 기반이 아닌 개인 경험과 및 참조 문서에 의존한 내용임도 밝힌다.
장애 시나리오 예시
용이한 설명을 위해 먼저 장애 시나리오를 상정하였다. 서비스 A와 B(각각 10개 pod, pod 당 10 RPS 처리 가능)가 있을 때, A → B 호출 시 트래픽이 100 RPS에서 200 RPS로 급증(spike)한다고 가정한다. 이때 아래와 같은 순서로 장애가 발생 가능하다.

1.
높은 지연(High Latency): 과부하로 인한 B의 일부 pod 응답 시간이 5초로 증가, A의 대기 시간 증가.
2.
일시적 장애(Transient Failure): B의 pod에서 request queue 포화, 네트워크 혼잡 등으로 일시 또는 간헐적 5XX 오류 발생, A의 요청 실패.
3.
반복적 장애(Persistent/Repeated Failure): B의 특정 pods에서 5xx 오류 지속, B의 가용성 저하.
4.
연쇄적 장애(Cascading Failure)
Istio resiliency 기반 장애 대응: overview
as S/W 엔지니어
Istio
resiliency
retry
timeout
circuit breaker
rate limit
outlier detection
Envoy
회복탄력성
2025/05/20
Load more
카테고리 별 글
목록
Search
as 음악인
13
Load more
as S/W 엔지니어
131
Load more
예술/인문 소감
73
Load more
自省(Introspection) / 세상살이
74
Load more
프로젝트s
97
Load more
방명록 백업