아이를 재우고 난 어느 밤, 아내가 무라카미 하루키의 산문책을 읽고 있었습니다. “밸런타인데이의 무말랭이”라는 제목이었는데 특별히 새로워보이진 않았습니다. 하루키의 산문은 달리기에 관한 책을 하나 읽은 것이 전부였고, 요즘엔 특이한 제목들의 하루키 책들이 많다 정도로만 알고 있었으니까요. “채소의 기분, 바다표범의 키스“, “샐러드를 좋아하는 사자“ 같은 것들이요. 아내가 책을 건네주어 짧은 글을 읽어봤는데 글의 내용도 내용이지만 말하는 투와 분위기가 인상 깊었습니다. 사실 내용은 잘 기억나지 않아요. 아, 어떤 내용이었냐면.. 평일 오후에 도심을 거니는 것이 보통의 직장인과 달라 머쓱한 기분이 든다, 안자이 씨를 만난 이야기 였습니다. 저는 글을 적는다고 생각하면 괜히 자세를 고쳐잡게 되면서 긴장 아닌 긴장을 하게 된달까요, 불필요하게 본격적으로 되버리고 맙니다. 하지만 하루키는 짧은 산문을 담백한 듯 싱거운 듯 편하게 적어내려갑니다. 그 느슨함과 여유가 매력입니다. 저는 떄로 글을 적을 때 너무 적은 분량이 아닌가, 쓸모있는 정보가 없는 것이 아닌가, 그냥 글 읽는 사람의 시간을 낭비하는 건 아닐까 고민할 때도 많으니까요. 싱거운 글을 쓰는 연습을 해봅시다. 아니 연습이라고 하니 또 애쓰는 것 같은데 너무 애쓰지 맙시다.
요즘 제가 맡은 회사일의 핵심은 인프라 스트럭처 입니다. 회사에서 만든 제품을 안정적으로 구동할 수 있는 환경을 만드는 일이죠. 혼자 만들고 사용하는 환경과는 다르게 확장성과 안정성이 필요합니다.
기존의 환경은 Docker Compose를 이용한 배포였습니다. AWS EC2 Instance를 필요한 만큼 만들고 각 인스턴스들에서 docker compose를 실행하여 여러 서비스들을 동작시킵니다. 만약 소프트웨어 오류로 컨테이너가 정지한다면 재시작 해줄 수 있고, 가상화된 네트워크와 볼륨을 이용하여 서로 다른 서비스끼리 연결하거나 같은 볼륨을 공유할 수 있습니다. Docker Compose에 내장된 로드 밸런싱 기능이 있을지 모르겠지만 간단하게는 Nginx 등 다른 소프트웨어를 통해 로드밸런싱을 수동으로 설정할 수도 있을겁니다. 하지만 인스턴스 자체의 오류로부터는 무방비 상태입니다.
AWS 같은 클라우드 환경을 사용하더라도 종종 인스턴스 장애에 대한 메일 안내를 받습니다. 인스턴스의 하드웨어 결함을 발견했으니 교체 예정이다, 이에 대비하여 필요한 작업을 수행하라 이런 내용입니다. 저희가 집 혹은 회사에서 사용하는 단일 데스크탑 혹은 랩탑의 경우 이 장치의 수명이 다할 때까지 하드웨어 결함을 만나기 어려울 수 있습니다. 하지만 데이터 센터와 같은 규모에선 상황이 다릅니다. 수천 수만개의 스토리지를 사용하므로 매일 어떤 스토리지는 고장나게 마련입니다. 글의 제목처럼 “죽지 않는 컴퓨터”는 없습니다.
저는 일하면서 Kubernetes를 익힐 기회가 있었는데 유용하게 활용하고 있습니다. 앞서 말씀드렸던 안정성과 확장성을 고려하여 컨테이너 관리를 할 수 있고 이들 작업은 코드의 형태로 관리할 수 있습니다. 지난 창업의 경험에선 혼자 제품을 위한 인프라를 구축하고 관리해야 했습니다. 이때 Kubernetes의 사용이 빛을 발했습니다. 중간에 클라우드 서비스 제공자를 바꿔야하는 경우도 있었는데 아주 적은 수정만 가해 쉽게 옮길 수 있었습니다.
회사 제품의 인프라를 생각하면서 제품을 구성하는 기능들은 최소 2개 이상의 복제본을 갖도록 했습니다. 치밀하게 생각한다면 이들의 복제본은 서로 다른 인스턴스(작업 노드)로 스케줄 되어야 하며, 더 치밀하게 생각한다면 서로 다른 가용 영역 Availability Zone 을 사용할 수 있고 (한국 내 Region에서도 다수의 데이터센터에서 인스턴스를 운영하며 이들이 서로 다른 가용 영역을 이룹니다. 곧 서울에 있는 데이터센터가 망가지더라도 판교에 있는 데이터센터는 살아있을 수 있으니 서로 다른 가용 영역을 이용하여 다중화를 시켜두면 더 안정적인 인프라를 갖출 수 있습니다) 나아가 Multi Region, 더 나아가 Multi Cloud Service Provider 전략을 취할 수도 있습니다.
복제본을 만들기 위해선 가급적 서비스가 Stateless 성격을 가져야 합니다. 그래야 쉽게 복제본을 추가하거나 제거할 수 있기 때문입니다. 다행히 저희 제품의 웹서버들은 이런 성격을 갖추고 있었으며 Job Queue-Worker 구조로 동작하는 나머지 부분 역시 쉽게 Worker(복제본)를 추가하거나 제거할 수 있었습니다. Job Queue를 사용하는 경우엔 신경써야하는 설정 부분이 있습니다. Job Queue에서 작업을 제거하는 시점이 단순히 Worker가 작업을 가져가는 순간이라면 문제가 발생합니다. 작업을 가져간 후 Worker에서 오류가 발생해도 해당 작업을 다시 시도할 수 없기 때문이죠. 따라서 이런게 실패하는 작업들을 모아서 다시 처리하기 위한 Dead Letter Queue를 관리하거나, Job Queue에서 작업을 제거하는 시점을 Worker의 작업 처리 성공 시점으로 설정해야 합니다.
인프라 스트럭처는 단순히 구축에서 끝나는 작업이 아닙니다. 실제 제품의 기반을 Docker Compose에서 Kubernetes로 바꾼 후 예기치 못한 장애들을 자주 만났습니다. 가능한 한 제품의 가시성을 높이고 장애가 발생할 수 있는 지점을 파악할 수 있게 노출시켜야 합니다. 저는 Kubernetes에서 널리 사용하는 Prometheus/Grafana 도구를 이용하여 대시보드를 만들어 사용하고 있습니다. 제품이 제대로 동작하는지 확인하기 위해 1시간에 한번씩 Kubernetes CronJob으로 간단한Integration Test를 합니다. 또한 추가로 내부 서비스들 간의 연결 확인을 위해 1분에 한번씩 CronJob을 수행합니다. Grafana 대시보드에선 마지막으로 성공한 CronJob 시각과 현재 시각의 차이를 구해 임계치를 넘어가는 경우 알람을 주도록 설정했습니다.
이번 작업을 위해 새롭게 많은 것들을 익혀야 했습니다. Terraform을 이용한 AWS 인프라 자동 구축, Kapenter를 이용한 Node Autoscaling, Skupper를 이용한 Kubernetes 클러스터 간 연결 등. 인프라 작업이 어려운 이유는 문제가 발생할 구석이 많고 모든 부분을 명료하게 파악하기엔 범위가 크다는 점입니다. 소스코드에서 발생한 오류의 경우, 범위를 한정하고 나면 그 안의 논리를 확인하는 것으로 문제를 해결할 수 있습니다. 인프라 구축에서 발생하는 문제는 우선 다양한 컴포넌트들의 상호작용을 파악하고 문제가 발생할 만한 가능성이 높은 부분을 추려내는 것에서 시작합니다. 하지만 때론 이런 분석이 무색하게 전혀 엉뚱한 이유로 문제가 발생하기도 합니다. 오류 메시지 혹은 상황이 때론 작업자를 기만하기도 합니다. 하지만 이렇게 신경 쓸 것이 많고 트러블슈팅도 까다로운 인프라 작업이지만 그것이 또 묘미 아니겠습니까. 소프트웨어 엔지니어의 근성을 기르기 위한 훈련에도 이만큼 적당한 작업도 없을 겁니다.
#buddhism
안녕하세요, 새해 첫 글을 적어봅니다. 새해맞이 결심 중 하나는 꾸준히 불교 공부하기 입니다. 저는 주로 출퇴근 시간을 활용하여 책을 읽는데 보통 두 권의 책을 번갈아가며 읽습니다. 그 두 권의 책 중 하나는 불교 책으로 선택하려 합니다. 무언가 익히고 습관으로 만들기 위해선 꾸준히 시간과 관심을 들여야 합니다. 한번 익히고 관심을 다른 곳으로 돌리면 금방 잊어버리고 안 배운 것과 마찬가지인 상태로 돌아가 버리더군요. 불교도 그렇습니다. 가슴을 울리는 이야기들이 가득한 불교 관련 책을 읽다보면 마음이 너그러워지고 나도 수행하여 무명에서 벗어나고 싶다는 마음이 드는데, 책을 읽고 나서 별 생각없이 뉴스와 신문으로 세상 이야기를 듣다보면 다시 마음은 경계로 가득차고 내것에 집착하게 됩니다. 이런 이유로 짧은 시간이나마 꾸준히 하루에 몇 줄씩은 불교 혹은 명상에 대한 책을 읽으려 하는 것이죠.
안녕하세요. 이번 글은 책 ”일의 감각, 원제 Expert”에서 발견한 한 문장에서 시작했습니다. 장인의 작업을 소개하며 “부서지기 직전의 재료로 작업하기”라는 개념이 있었는데 아마 재료 그 물성의 한계를 파악하고 최고의 결과를 얻기 위해 해당 재료가 허용하는 한계까지 밀어붙여 작업하는 걸 의미했던 것 같습니다. 다중 감각을 이용하여 작업물의 상태를 파악하고 재료의 한계를 직감적으로 파악하여 다루는 장인의 모습이 멋졌습니다. 그럼 저와 같은 소프트웨어 엔지니어에겐 “부서지기 직전의 재료로 작업하기”는 무얼 의미할까요. 먼저 소프트웨어라는 작업물이 부서지는 상황을 생각해 봤습니다.
#reading #tech #diy
최근 책 Livewired를 읽었습니다. 뇌과학의 최신 연구를 기반으로 다양한 사례들을 소개시켜주는데 두뇌의 유연성, 강력함을 확인할 수 있습니다. 자연이 빚어낸 두뇌라는 소프트웨어는 다양한 환경 변화에 적응할 수 있습니다. 저자는 우리 두뇌와 신체의 관계를 포테이토헤드 에 빗대어 표현하는데 컴퓨터의 플러그앤플레이 장치처럼 우리의 감각기관과 운동기관을 자유롭게 추가하거나 제거하는 모델입니다. 포테이토헤드를 보면 감자로 된 머리에 얼굴의 각 부분과 팔 다리 등을 자유롭게 배치할 수 있습니다. 마찬가지로 자연은 영리한 전략을 택했는데 두뇌라는 유연한 소프트웨어를 장착시킴으로써 혹시 모를 다양한 상황에서도 생존을 추구할 수 있도록 했습니다. 예를 들어 후천적으로 시각 혹은 쳥력을 잃거나 다리 혹은 손을 못 쓰게 되는 경우에도 두뇌는 남은 자원에 집중하여 살아남는데 집중합니다. 태어날 때부터 앞다리를 사용하지 못하는 개는 두 다리로 걷는 법을 익히고 눈이 멀게된 사람은 소리로 세상을 보는 법을 익힙니다. 뜻하지 않은 변화는 돌연변이에서도 발생합니다. 돌연변이로 팔이 하나 더 생기거나 어떤 결함 혹은 의도치 않은 변화가 있어도 두뇌는 주어진 상황에서 최대한 적응하려고 노력합니다.
요리사, 도예 장인, 그래픽 디자이너 등 뭔가 만드는 사람들은 자신만의 작업공간과 질서를 만듭니다. 소프트웨어 엔지니어에게 가장 중요한 도구는 프로그램을 작성하는 코드 편집기 입니다. 이번 글에서는 코드 편집기를 바꿔온 여정을 소개하며 제가 생각하는 코드 편집기의 필수 요소들을 이야기해보겠습니다.
제 자리엔 티크 나무 컵받침이 있습니다. 넓적하고 둥글게 잘라낸 나무 토막이죠. 티크 나무는 습기에 강하다고 해요. 선박을 만들 때 사용하기도 했다는데 컵받침으로 쓰기에도 딱이죠. 차가운 표면에 물이 맺히면 컵받침에도 물이 흥건해지니 말입니다. 티크 나무 컵받침은 홈플러스에서 우연히 발견했습니다. 사실 컵받침으로 사용할 수 있는 재료는 많지요. 천조각으로 만들거나 코르크 재질, 아니면 종이 혹은 실리콘도 있습니다. 정 귀찮으면 맘에 들지 않는 책 한 권을 사용해도 문제 없지요. 이번 나무 컵받침 전엔 실리콘 컵받침을 사용했었어요. 몬스테라 이파리를 형상화한 컵받침이었죠. 그걸 보니 아, 자연을 곁에 두고 싶어 하는 구나 라는 생각이 들었습니다. 몬스테라 “모습”을 하거나 나무라는 천연의 “재료”를 사용하거나 말이죠. 저희 집에는 조화도 몇개 있습니다. 화사한 꽃도 있고 고사리도 있어요. 몇번 집 안에서 식물을 기르려는 시도를 해봤는데 바람과 볕이 부족해서 늘 시들해지고 죽었습니다. 결국 살아남을 수 있는 건 조화 밖에 없었지요 (애초에 살아있지 않았으니 살아남았다는 말이 이상하긴 하지만요). 도시 생활에선 자연을 만날 일이 별로 없어요. 포장된 도로와 대중교통, 사무실을 비롯한 건물들. 지금의 사무실을 둘러보니 창이 별로 없고 창이 있어도 건물들로 가로막혀 있네요. 이디서 자연을 찾아야 할까요? 하루의 많은 시간을 사무실 제 자리에서 보내는데 아무래도 티크 나무 컵받침으로는 부족하겠어요. 식물을 하나 들여야겠는데 식물들이 죽어나가는 저희 집과 별반 다를 바 없는 곳이라 식물 혼자서는 살아나갈 수 없을 것 같습니다. 이제 기술을 사용할 때 입니다. 테라리움을 하나 마련하고, 식물 생장 램프와 휴대용 선풍기를 준비합니다. 해가 뜨고 지는 주기에 맞춰 식물 생장 램프를 켰다가 꺼주고, 종종 선풍기 바람을 쐬여줍니다. 아마 그렇게하면 살 수 있을거에요. 재료들을 주문하러 가봐야겠네요.
쌍문역 근처에 놀이터가 하나 있습니다. 그 놀이터를 지날 때 가끔 어떤 여성분을 발견하는데 그네를 열광적으로 타고 있는 모습 때문에 눈이 갑니다. 보통의 그네 타기가 아닙니다. 마치 세상을 떠나가려는 듯이 아주 높게, 엉덩이가 들릴만큼 세차게 그네를 탑니다. 저라면 그렇게 못 탈 것 같아요. 너무 무서워보이거든요. 아무튼 그런 그네타기의 모습은 확실히 일상의 풍경과는 거리가 멉니다. 그런 그네타기를 하고 있는 놀이터 옆을 걸어 지나갈 때면 마치 영화 속에 들어간 기분이 듭니다. 이게 현실일까 꿈일까 생각하게 만들기도 하고요. 어떤 이유에서 그네타기를 하고 있는 걸까요? 아내와 얘기했을 때 아내 추측은 이랬습니다. 그건 운동하고 있는 것 아닐까? 전신을 사용하는 유산소 운동 말야. 과연 그런 가능성도 있습니다. 그네타기는 그 자체로 즐겁기도 하고 엉덩이가 들리고 날아가려는 몸을 붙잡으며 타는 그네타기는 스릴 만점이겠습니다. 마음도 단련하고 있는 걸까요? 수차례 그 모습을 보며 지나가다 보니 어떤 날은 말을 걸어보고 싶기도 합니다. 가장 먼저 물어보고 싶은 건 왜 그렇게 격렬하게 그네를 타고 있는지 그 이유지요. 그 다음으로는 그네타는 모습을 영상으로 담고 싶습니다. 이렇게 여기서 풀어내는 이야기가 정말 진실이라고 말이죠. 오늘의 교훈은 이렇습니다. 마음의 유연함을 가질 것. 일상과 비일상의 경계는 모호합니다. 누군가는 세상을 떠나가는 그네 타기를 보고 아무 감흥이 없을 수도 있습니다. 그것 또한 일상일 수도 있지요. 반대의 경우일 수도 있습니다. 그네타기의 시각 정보는 두뇌로 도착했지만 그걸 흘려보내고 감지하지 못할 수도 있지요. 그건 감수성과 현존의 부재입니다. 세상을 살아가지만 머리는 다른 생각으로 가득차 지금 여기에 존재하지 않는 셈이지요. 다음엔 꼭 그분의 그네타기 속으로 들어가 저 역시 그네타기를 해봐야겠습니다.
안녕하세요, 은수 아빠입니다. 예전에 영화 127시간에 대해 듣고 이야기 나눈 일이 있었습니다. 주인공이 산행을 하다가 크레바스 같은 틈새로 떨어져 버리고 팔이 바위에 꽉 끼어 오도가도 못하는 상황이 되는게 영화에 등장하는 갈등 상황입니다. 며칠을 애쓰며 빠져나오려 하지만 실패하고 결국 바위에 끼인 팔을 스스로 절단하여 빠져나옵니다. 끔찍한 내용이지만 놀랍게도 이 영화는 실화를 바탕으로 하고 있습니다. 이런 상황에 처했을 때 영화 속 인물처럼 행동할 수 있을까요? 이 질문이 대화 중 나왔었고 처음 생각으로는 저는 못할 것 같았습니다. “작은 휴대용 칼“을 사용하여 눈 앞에서 자신의 팔을 잘라내는 걸 누가 쉽게 할 수 있겠습니까. 찾아보니 해당 인물은 가족 생각을 하며 생존의 열망을 갖고 버텼다는데요 다시금 생각해보니 저 역시 그런 상황에서 가족, 특히 아이를 생각한다면 어떻게든 살아남아 돌아가겠다는 의지를 불태웠을 것 같습니다. 아빠 없이 자라게 될 아이로 만들 수 없고 저 역시 다시 아이 모습을 볼 수 없다는 걸 받아들일 수 없었겠지요. 아빠가 된다는 것이 이렇게 극적으로 사람을 변화시킬 수 있다는 생각에 놀랐습니다. 왜 어머니와 아버지가 강한지 이해할 수 있었죠. 이런 생각을 아내에게 말하니 아내는 새로운 의견을 얘기해줬습니다. 왜 애초에 그런 위험한 활동을 시작했느냐 말이죠. 책임져야할 가정과 사랑하는 가족들이 있는 상황에서 위험한 활동을 하는게 어리석다고 생각한 겁니다.