index.json

[
  {
    "title":     "동네 뒷산 등반기",
    "permalink": "/hiking-with-daughter/",
    "date":      "2025년 06월 14일",
    "summary":   "아이와 동네 뒷산에 올랐다. 뒷산 이라고 하니 어디 야트막한 동산 쯤으로 여겨질 법하지만, 이래 봬도 해발 500m. 어른 걸음으로도 꼬박 한 시간 이상은 걸어야 정상에 닿을 수 있는 산이다. 만 5세의 여자아이에게는 결코 만만치 않은 여정이다. 여느 산처럼 초입은 완만하지만 중반을 넘어설 즈음부터는 경사가 가파르게 치솟는 탓에 완등이 가능하리라 생각치 않았다. 그럼에도 아이에게 산행을 제안했던 이유는, 그저 중턱 어디쯤 올라 벤치에 앉아 시원한 얼음물로 목을 축이고는, 올라온 길을 내려다보며 소박한 성취감 같은 것을 맛볼 수 있지 않을까 하는 생각에서였다. 아이는 주저없이 내 제안을 수락했다. 요즘 아이는 마치 스탬프 투어라도 나선 듯 아직 경험해보지 못한 것들을 하나씩 정복해가는 재미에 푹 빠져 있었다. 나이가 들수록 신선한 것들보다는 익숙하고 무던한 것들이 많아지는 나로써는 부러운 일이다.\n",
    "content":   "아이와 동네 뒷산에 올랐다. 뒷산 이라고 하니 어디 야트막한 동산 쯤으로 여겨질 법하지만, 이래 봬도 해발 500m. 어른 걸음으로도 꼬박 한 시간 이상은 걸어야 정상에 닿을 수 있는 산이다. 만 5세의 여자아이에게는 결코 만만치 않은 여정이다. 여느 산처럼 초입은 완만하지만 중반을 넘어설 즈음부터는 경사가 가파르게 치솟는 탓에 완등이 가능하리라 생각치 않았다. 그럼에도 아이에게 산행을 제안했던 이유는, 그저 중턱 어디쯤 올라 벤치에 앉아 시원한 얼음물로 목을 축이고는, 올라온 길을 내려다보며 소박한 성취감 같은 것을 맛볼 수 있지 않을까 하는 생각에서였다. 아이는 주저없이 내 제안을 수락했다. 요즘 아이는 마치 스탬프 투어라도 나선 듯 아직 경험해보지 못한 것들을 하나씩 정복해가는 재미에 푹 빠져 있었다. 나이가 들수록 신선한 것들보다는 익숙하고 무던한 것들이 많아지는 나로써는 부러운 일이다.\n늘 도시에서 지내온 아이에게 숲과 산은 그 자체로 신선한 공간이었다. 과장 조금 보태서 서너 걸음마다 한 번 씩 멈춰 서서는 무언가를 주의를 뺏기곤 했다. 발 밑에 떨어진 도토리를 집어들고는 이게 무어냐 묻더니, 곧 안이 궁금하다며 고사리 손으로 돌멩이를 하나 주워들고는 무자비하게 내려찍었다. \u0026amp;ldquo;도토리는 다람쥐가 먹는 밥 같은 거야\u0026amp;rdquo; 라고 이야기를 해주니 갑자기 흥분한 목소리로 자기도 들은 적이 있다며 유치원에서 들었을 다람쥐 이야기를 신나게 늘어놓기도 했다.\n몇 걸음 더 가서는 쓰러져 있는 나무를 발견하고는 종종 걸음으로 달려가 작은 가지를 꺾으려 애를 쓴다. 혼자 힘으로는 무리라는 것을 알았는지 도와달라는 무언의 눈빛을 보내온다. 가지를 꺾어 쥐어주자, 다른 등산객들처럼 지팡이 삼아 몇 걸음을 내디뎌본다. 하지만 지팡이로 삼기에는 너무 가늘었던 탓에 다시 가지를 돌려쥐고는 내 쪽으로 붕붕 휘둘러댄다. 평소처럼 으악 하고 단말마 비명을 지르며 쓰러지는 악당 역할을 하고 있자니 아빠 그게 아니란다. 같이 나뭇가지를 휘두르며 칼싸움을 해야 된단다. 아이의 장단에 맞추어 대여섯 번 가지를 휘둘러 주고서야 다시 산행길을 나설 수 있었다.\n하지만 또 몇 걸음도 채 못가서는 개미 떼의 행렬에 넋을 빼앗겼다. 말로는 \u0026amp;ldquo;귀여워!\u0026amp;rdquo; 를 외치며 감탄하다가도 이내 발로 슬며시 그들을 짓밟아보고 싶어 하는 그 복잡다단한 마음은 무엇일까.\n이렇듯 쉬지 않고 새로운 발견을 해대는 탓에 산행은 좀처럼 진도를 나가지 못했다. 나는 끊임없이 \u0026amp;ldquo;이제 가자\u0026amp;quot;며 아이의 주의를 되돌려야 했다. \u0026amp;ldquo;갈 길이 아직 멀다\u0026amp;quot;는 말로 재촉도 해보고, \u0026amp;ldquo;저기까지만 가서 조금만 쉬자\u0026amp;quot;는 회유도 해봤다. 그러다 무심코 \u0026amp;ldquo;산 정상에는 음료수와 아이스크림을 파는 아저씨가 있다\u0026amp;quot;는 말실수를 해버리고 말았다.\n사실 없는 말은 아니었다. 주말마다 아이스박스를 짊어지고 올라와 정상에서 시원한 음료며 아이스크림을 파는 아저씨가 있긴 했다. 하지만 애초에 정상까지 오를 생각이 없었기에 이는 의도치 않은 실수였다. 하지만 그 순간부터 아이의 목표는 명확해졌다. 정상에 올라 달콤한 아이스크림을 맛보는 것.\n아이스크림이 뭐라고, 집 앞 편의점만 가도 얼마든지 사먹을 수 있는 그게 대체 뭐라고 아이는 전의를 불태우기 시작했다. 비록 본인 소유의 돈이 없으니 아무때나 사먹을 수 없는 건 사실이긴 했지만, 그럼에도 \u0026amp;ldquo;아빠, 우리 아이스크림 사먹으러 갈까?\u0026amp;rdquo; 한 마디면 어렵지 않게 시원한 쭈쭈바 쯤은 획득할 수 있다는 것을 아이는 이미 경험적으로 알고 있을 것이다. 하지만 목적을 위해 최단 경로를 탐색하는 것은 어른의 사고법이다. 아이는 그저 보상이 마음에 들면 이리저리 재는 법 없이 우다다다 달려간다.\n완등 뒤에 있을 아이스크림이 썩 마음에 든 아이는 이제 산행 자체에 열을 올리기 시작했다. 꽤 가파른 경사 앞에서도 내 손을 꼭 잡고서는 \u0026amp;ldquo;할 쑤 이써, 할 쑤 이써\u0026amp;quot;를 되내며 허벅지에 힘을 주고 나아갔다. \u0026amp;ldquo;할 쑤 이써 …",
    "tags":      ["daily"]
  },
  {
    "title":     "이력서의 기술",
    "permalink": "/resume-skill/",
    "date":      "2025년 05월 22일",
    "summary":   "\n이력서는 프레임을 만든다. 근래 몇 차례 면접관으로 들어가면서 느낀 감상이다. 이력서는 단순히 지원자의 이력을 요약한 문서에 지나지 않지만, 어떤 이력서는 면접의 방향과 구조를 사실상 선제적으로 설계하는 역할을 하기도 한다. 면접관은 주의하지 않으면 자신도 모르게 이력서가 만들어놓은 프레임 내에서 질문하고 평가하기 십상이다. 특히 경력을 주요 검증 대상으로 삼는 경력직의 면접이 그렇다. 경력 면접이 가진 이러한 구조적 특성을 정확히 인지한 상태에서 면접관은 인지 편향에 휩쓸리지 않는 준비와 훈련이 필요하다. 반대로 지원자도 이러한 구조적 편향을 이해하고 그에 맞는 전략적 대응을 하는 것이 영리한 전술일 것이다.\n",
    "content":   "\n이력서는 프레임을 만든다. 근래 몇 차례 면접관으로 들어가면서 느낀 감상이다. 이력서는 단순히 지원자의 이력을 요약한 문서에 지나지 않지만, 어떤 이력서는 면접의 방향과 구조를 사실상 선제적으로 설계하는 역할을 하기도 한다. 면접관은 주의하지 않으면 자신도 모르게 이력서가 만들어놓은 프레임 내에서 질문하고 평가하기 십상이다. 특히 경력을 주요 검증 대상으로 삼는 경력직의 면접이 그렇다. 경력 면접이 가진 이러한 구조적 특성을 정확히 인지한 상태에서 면접관은 인지 편향에 휩쓸리지 않는 준비와 훈련이 필요하다. 반대로 지원자도 이러한 구조적 편향을 이해하고 그에 맞는 전략적 대응을 하는 것이 영리한 전술일 것이다.\n이력서는 인지 편향을 만든다. 이력서가 눈 앞에 놓이면 면접관은 무심코 그 내용을 중심으로 질문을 조립한다. 눈에 띄는 프로젝트나 기술 이력에서 질문을 발굴하여 던지고, 그에 대한 답이 좋으면 지원자에 대해 좋은 평가를 내리는 경향이 생긴다. 그 결과로 함께 검증해야 하지만 이력서에는 포함되어 있지 않거나 적은 비중으로 구성된 항목은 충분히 검증되지 못한다. 결국 면접관은 자신도 모르는 사이에 이력서에 적힌 내용 만으로 질문 범위를 한정하기 쉽고, 그 내용을 강화하거나 반박하는 식으로 판단하기 쉽다.\n면접은 애초에 구조적으로 이러한 인지 편향이 일어나기 쉬운 전장이다. 여기에는 두 가지 요인이 영향을 미치는데 이력서가 가진 \u0026amp;ldquo;선제적 정보 제공 역할\u0026amp;rdquo;, 그리고 면접관의 \u0026amp;ldquo;제한된 시간 내 효율적으로 판단해야 하는 상황\u0026amp;quot;에 기인한다.\n먼저 지원자는 이력서를 통해 스스로 정보를 취사 선택하고 이를 통해 면접의 무대를 사전에 세팅할 수 있다. 자신에게 유리한 경험, 프로젝트, 스킬셋 등을 강조하고, 불리한 항목은 비중을 줄이거나 의도적으로 드러내지 않는 선택을 할 수도 있다. 이 과정에서 이력서는 본래 정보의 출발점이지만 평가의 방향타로서도 기능하기 시작한다.\n면접관은 자연스레 지원자가 이력서를 통해 의도한 방향대로 정보를 소비하기 시작한다. 대부분의 면접은 한시간 남짓, 길어야 두 시간. 그 제한된 시간 내에 면접관은 기술 역량과 문제 해결 능력을 검증하고, 지원자의 경험과 이력이 우리 팀에서 효과적으로 쓰일 수 있을지 판단해야 하며, 이를 위해 지원자의 대답을 평가하고 추가 질문을 이어나가야 한다. 당연히 사전에 이력서를 받아 준비하는 시간을 가지겠지만 면접 준비 외에도 일상적인 실무를 놓을 수는 없으니 그 준비 시간 마저 넉넉하다고 할 수 없겠다.\n자연히 이 과정에서 전체를 일일히 뜯어보는 것 보다는 빨리 판단할 수 있는 단서를 찾는 경향을 띄게 된다. 이는 인간의 인지 자원의 절약 본능과 맞물리는 현상이다. 바로 이 시점에 과거 경험, 유사 사례, \u0026amp;lsquo;느낌\u0026amp;rsquo;에 기반하여 빠른 판단을 내리는 인간의 직관 시스템이 가동하기 시작한다. 직관은 빠르고 강력하지만 동시에 편향의 문을 열어주는 기제가 되기도 하며, 실질적인 평가 왜곡을 유발하는 시발점이 되기도 한다.\n그렇다고 직관이 항상 부정확하고 위험하다고 단정할 수도 없는 노릇이다. 면접관의 직관은 그동안의 사례 축적에서 비롯된 암묵적 지식이다. 직관을 통해 때때로 문장 너머의 의도를 읽어내고, 겉으로 보이게만 좋은 말과 실제 능력 간의 간극을 빠르게 감지해내는 강력한 신호 체계가 된다. 문제는 이 직관이 검증되지 않은 채 진실처럼 작동할 때다.\n구조적으로 편향을 유도하는 면접에서 특별한 주의를 기울이지 않으면 이력서가 강조한 경험 및 기술 영역은 과도하게 주목되고 검증되는 반면, 그 외의 영역은 상대적으로 간과되거나 평가 기회조차 주어지지 않을 수 있다. 특정 영역이 반복적으로 질문되고 집중 조명되는 이유가 정말 중요해서라면 상관없겠지만 \u0026amp;ldquo;그것이 눈에 잘 띄었기 때문\u0026amp;quot;이라는 단순한 이유일 수도 있다. 더불어 일부 역량이나 경험이 지원자의 전체 능력을 대표하게 되는 오류가 발생하기도 쉽다.\n그래서 면접관은, 이력서가 유도하는 프레임에 쉽사리 휩쓸리지 않게 사전에 팀 기반으로 우리 만의 …",
    "tags":      ["career"]
  },
  {
    "title":     "\u003c자아 연출의 사회학\u003e 독서 후기",
    "permalink": "/the-presentation-of-self-in-everyday-life/",
    "date":      "2024년 08월 24일",
    "summary":   "사회 초년생 시절, 10년도 넘게 흐른 지금도 유난히 기억에 남는 장면이 하나 있다. 평소처럼 업무를 하던 중 갑자기 귀에 들려오는 고성에 파티션 너머로 고개를 들어 두리번거렸다. 상황을 보니 당시 옆 라인에 있던 다른 개발팀 팀장이 핸드폰을 붙잡고 화를 내고 있었다. 내용을 들어보니 영업팀과의 통화로 추정되었는데, 영엄팀의 욕심 혹은 실수로 인해 개발팀이 불필요한 업무를 떠맡게 된 상황이었다.\n그 장면이 유독 기억에 남는 이유는, 그 팀장의 불만 표현의 강도가 다소 과하다는 인상을 받았기 때문이다. 구체적인 내용이 모두 기억나진 않지만, 영업팀과의 문제가 말도 안되는 느낌의 사건이라기 보다는, 서로 잘 협의만 했더라면 충분히 익스큐즈가 될 수 있는 내용이었다. 즉, 개발팀 입장에서 불만을 가질 수는 있지만 사무실 한복판에서 전화로 고함을 칠 정도는 아니었다는 것이다.\n",
    "content":   "사회 초년생 시절, 10년도 넘게 흐른 지금도 유난히 기억에 남는 장면이 하나 있다. 평소처럼 업무를 하던 중 갑자기 귀에 들려오는 고성에 파티션 너머로 고개를 들어 두리번거렸다. 상황을 보니 당시 옆 라인에 있던 다른 개발팀 팀장이 핸드폰을 붙잡고 화를 내고 있었다. 내용을 들어보니 영업팀과의 통화로 추정되었는데, 영엄팀의 욕심 혹은 실수로 인해 개발팀이 불필요한 업무를 떠맡게 된 상황이었다.\n그 장면이 유독 기억에 남는 이유는, 그 팀장의 불만 표현의 강도가 다소 과하다는 인상을 받았기 때문이다. 구체적인 내용이 모두 기억나진 않지만, 영업팀과의 문제가 말도 안되는 느낌의 사건이라기 보다는, 서로 잘 협의만 했더라면 충분히 익스큐즈가 될 수 있는 내용이었다. 즉, 개발팀 입장에서 불만을 가질 수는 있지만 사무실 한복판에서 전화로 고함을 칠 정도는 아니었다는 것이다.\n당시 신입사원이었던 나는 그 팀장이 적절하지 못한 방식으로 상황을 처리했다고 생각했다. 아무리 불만이 있더라도 앞으로도 함께 일해야 할 파트너 팀에게 그렇게 공개적이고 감정적으로 갈등을 일으켜도 되는지 의문이었다.\n하지만 지금 와서 돌이켜보면, 그것은 모두 의도된 연출이지 않았을까 하는 생각이 들었다. 일단 그 팀장의 원래 캐릭터 자체가 감정적으로 쉽게 행동하는 타입이 아니기도 했고, 통화를 하던 위치도 모두가 들을 수 있는 사무실 한복판이기도 했다. 아마도 과도한 업무 부담으로 인해 팀원들의 불만이 쌓이지 않도록 팀장 본인이 대신 강하게 나서며 \u0026amp;ldquo;나는 당신들의 편이다\u0026amp;quot;라는 메시지를 전달하려 했을 것이다. 이를 통해 팀의 결속력을 강화하고, 팀원들이 느낄 스트레스를 줄이려는 전략적인 행동이었을 수 있다.\n또한 영업팀과의 앞으로의 관계에서도 유리한 고지를 차지하려는 전략적인 포석도 계산했을 것이다. 상대방의 실수와 그로 인한 피해를 명확히 짚고 넘어가며, 앞으로는 너희 팀의 성과를 위해 우리 팀을 희생시키지 않겠다는 경고 섞인 엄포였을 것이다.\n지금와서 이 장면을 다시금 떠올리게 된 이유는 어빙 고프먼의 \u0026amp;lt;자아 연출의 사회학\u0026amp;gt; 이란 책에서 비슷한 내용을 읽었기 때문이다. 이 책에서는 우리가 사회생활을 하면서 모두 일종의 \u0026amp;ldquo;연출\u0026amp;quot;을 하게 되는데, 연출의 1차적인 목적은 타자의 상황 정의에 영향을 미치기 위함이라고 이야기하고 있다.\n사회적 상호작용에서 연출은 불가피한 부분이 있다. 일상 생활 안에서 우리는 여러가지 사회적 역할을 수행한다. 직장에서 팀원으로, 가정에서는 배우자이자 부모로, 또 친구들과의 관계에서는 다른 모습으로 사회적 역할을 수행한다. 각 상황에서 요구되는 역할에 맞추기 위해 우리는 자신의 행동을 조정하고, 그 역할에 부합하는 이미지를 연출해야 한다. 이미 그런 식으로 사회적 기대가 형성되어 있기 때문이다.\n더불어 이러한 연출은 사회적 관계의 마중물 역할을 하기도 한다. 모든 관계가 자연스럽게 형성되지는 않으며, 종종 관계의 초기에는 연출을 통해 자신을 긍정적으로 보이게 함으로써 관계를 시작하게 된다. 자신의 장점을 부각하고 단점을 감추려는 일종의 연출이 없다면 많은 관계들이 시작조차 되지 못했을 것이다.\n결과적으로 연출은 단순히 타인을 속이기 위한 목적이 아니라, 사회적 규범/기대에 부응하고 관계를 형성하기 위해 불가피하게 체득해야 하는 전략에 가깝다.\n하지만 이렇게 대놓고 연출에 대해 적어놓고 보자니 거부감도 좀 든다. 이는 우리가 서로에게 진정성 같은 가치를 기대하고 있기 때문일 것이다. 즉 타인이 보여주는 모습은 진짜 자신을 반영하기를 기대하고 있는 것이다. 연출은 아무래도 인위적 요소를 포함할 수 밖에 없게 마련이고, 연출이 연출이었음을 들키게 되는 날에는 사람들에게 \u0026amp;lsquo;가식적\u0026amp;rsquo;이라는 인상을 줄 수 있다. 특히나 동양권 문화에서는 겉과 속이 다르다는 인식을 주어 그 사람에 대한 신뢰를 크게 떨어뜨릴 수 있다.\n여기서 인간 사회의 복잡성과 모순이 드러난다. 진정성은 너와 내가 모두 사회적으로 중요하게 여기는 가치지만, 실제로 모든 상황에서 연출없이 있는 그대로의 …",
    "tags":      ["daily"]
  },
  {
    "title":     "시작하는 개발자들을 위한 기술 여행 가이드",
    "permalink": "/tech-travel-guide/",
    "date":      "2023년 11월 07일",
    "summary":   "1996년, OOPSLA 라는 이름의 객체 지향 프로그래밍 컨퍼런스에서는 아주 이상한 일이 벌어집니다. 소프트웨어 개발자들이 잔뜩 모인 이 컨퍼런스의 기조 연설을 한 건축가가 맡게 된 것입니다. 이게 얼마나 이상한 일이었냐면, 강단위에 선 그 건축가 마저도 자신이 이 자리에 서게 된 데에 어리둥절해하고 있었습니다.\n\u0026ldquo;음, 이건 제게 정말 이상한 일인데요. 여기 계신 수많은 분 앞에서 제가 연설을 하고는 있지만 저는 여러분이 하는 일에 대해서는 아무 것도 아는 바가 없습니다.\u0026rdquo;\n어째서 소프트웨어 개발과는 관련이 없는 건축가가 개발 컨퍼런스의 기조 연설을 맡게 된 것일까요?\n",
    "content":   "1996년, OOPSLA 라는 이름의 객체 지향 프로그래밍 컨퍼런스에서는 아주 이상한 일이 벌어집니다. 소프트웨어 개발자들이 잔뜩 모인 이 컨퍼런스의 기조 연설을 한 건축가가 맡게 된 것입니다. 이게 얼마나 이상한 일이었냐면, 강단위에 선 그 건축가 마저도 자신이 이 자리에 서게 된 데에 어리둥절해하고 있었습니다.\n\u0026amp;ldquo;음, 이건 제게 정말 이상한 일인데요. 여기 계신 수많은 분 앞에서 제가 연설을 하고는 있지만 저는 여러분이 하는 일에 대해서는 아무 것도 아는 바가 없습니다.\u0026amp;rdquo;\n어째서 소프트웨어 개발과는 관련이 없는 건축가가 개발 컨퍼런스의 기조 연설을 맡게 된 것일까요?\n사실 이 건축가의 이름은 크리스토퍼 알렉산더로, 1977년 \u0026amp;lt;A Pattern Language\u0026amp;gt; 라는 책을 출간한 적이 있었습니다. 이 책은 건물과 도시의 디자인을 설명하고 문서화하는 데에 패턴 언어라는 것을 사용하자고 제안하는 내용이었는데요. 그가 제안했던 패턴 언어를 한 문장으로 설명하면 \u0026amp;lsquo;특정 컨텍스트(A)에서 어떤 문제(B)를 해결하기 위한 솔루션(C)\u0026amp;lsquo;을 정리해놓은 것입니다.\n그리고 이 아이디어에 영감을 받은 커닝햄과 켄트 벡이 소프트웨어 개발에 패턴 언어를 접목시키면서 오늘날 개발자들이 말하는 디자인 패턴이 만들어지기 시작했습니다.\n이 내용은 제가 이번에 집필하게 된 \u0026amp;lt;시작하는 개발자들을 위한 기술 여행 가이드\u0026amp;gt; 라는 책의 일부를 가져온 것입니다. 디자인 패턴에 대해 풀어놓은 4장에서 크리스토퍼 알렉산더가 건축 분야에서 처음으로 제안하게 된 패턴 언어에 대해 설명하고, 이것이 소프트웨어 개발 업계로 넘어오면서 어떻게 발전하게 되었는지, 왜 패턴이 유용하며 어떻게 사용해야 하는지를 가능한 쉽게 풀어내었습니다.\n물론 디자인 패턴에 대해서만 다룬 책은 아닙니다.\n책은 크게 3부로 나누었는데요.\n1부에서는 코드에 대한 이야기를 주로 다루었습니다. 좋은 코드의 기준과 버그, 그리고 그 버그를 잡아내는 디버깅에 대해서 다루었고, 버전 관리 시스템과 여러 프로그래밍 언어에 대한 이야기로 구성했습니다.\n2부에서는 환경에 대한 이야기를 풀어놓았습니다. 서버 환경과 클라우드, 웹, 데이터베이스가 어떤 흐름으로 오늘날에까지 이르게 되었는지를 이야기했습니다. 그리고 모니터링, 코드 파이프라인, 마이크로서비스 등에 대해서도 다루었습니다.\n3부는 개발자라는 직업을 가지고 있는 우리의 이야기입니다. 우리는 왜 코드에 이토록 뜨거운 열정을 품고 있는지, 어떻게 성장하면 좋을지, 좋은 팀을 만들기 위한 방법, 오픈소스 정신, 그리고 마지막으로 경력직으로서의 이직에 대한 이야기도 담았습니다.\n목차 소개를 보시면서 참 잡다한 주제들을 많이도 우겨넣었구나 싶으실지도 모르겠습니다. 실제로 다양한 주제를 다루고 싶었습니다. 이제 개발자로써 막 여행을 시작하는 주니어 개발자들이 앞으로 수도 없이 만나게 될 개발자로서의 여정에서의 키워드들을 가능한 넓고 다양하게 담았습니다.\n다양한 주제를 담은 만큼 깊고 자세하게 파고들지는 않았습니다. 그 부분은 이 책을 읽는 독자들의 몫이니까요. 이 책은 그저 시작하는 개발자들이 성장하면서 만나게 되는 키워드들에 대한 흐름과 개념을 알려주는 책이 되었으면 좋겠다고 생각하며 원고를 써나갔습니다.\n\u0026amp;lt;시작하는 개발자들을 위한 여행 가이드\u0026amp;gt;는 이제 막 예약 판매를 시작하여 11월 10일에 정식으로 출간됩니다. 예약 판매 링크는 아래를 참고해주세요.\n예스24: https://www.yes24.com/Product/Goods/123367539 교보: https://product.kyobobook.co.kr/detail/S000211021316 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=328200170 당초 300페이지 정도로 계획하고 원고를 써내려가기 시작했지만 이런 저런 내용을 알차게 채워넣으려다보니 600페이지가 넘는 두꺼운 책이 되어버렸습니다.\n처음으로 집필한 책이니만큼 새벽잠을 줄여가면서 열심히 썼고, 부디 많은 분 …",
    "tags":      ["tech"]
  },
  {
    "title":     "영화 \u003c슬램덩크\u003e 관람기",
    "permalink": "/slam-dunk/",
    "date":      "2023년 02월 10일",
    "summary":   "슬램덩크 영화를 보고 왔다. 이전부터 보고 싶다는 생각을 하고 있었는데 더 미루면 상영관에서 내려갈 것 같아서 급히 동탄 메가박스까지 가서 보고 왔다.\n사실 큰 감동을 기대하지는 않았다. 원작 만화를 즐겁게 읽긴 했지만, 그 시절 읽었던 수많은 만화 중 하나일 뿐이었다. 재매있긴 했지만 그 이상의 기억은 희미했다. 스토리도 잘 기억이 나질 않았다.\n하지만 기대 이상으로 잘 만들어진 영화라는 생각이 들었다. 단지 만화를 영화로 옮긴 것에서 그치지 않고 메인 스토리를 가지고 새로운 이야기를 그려냈다. 기존 만화의 이야기는 크게 언급되지 않았고, 영화의 시작부터 마지막까지 산왕과의 경기로만 흘러간다. 대신 각 인물들의 과거 이야기가 중간 중간에 오버랩되어 나오는 구성이었는데 상당히 흥미로웠다. 각 인물들의 과거의 그들이 겪은 좌절, 그리고 이를 극복한 경험들이 모두 한데 침착되어 산왕전의 패스 하나, 슛 하나로 이어진다는 느낌을 받았다.\n",
    "content":   "슬램덩크 영화를 보고 왔다. 이전부터 보고 싶다는 생각을 하고 있었는데 더 미루면 상영관에서 내려갈 것 같아서 급히 동탄 메가박스까지 가서 보고 왔다.\n사실 큰 감동을 기대하지는 않았다. 원작 만화를 즐겁게 읽긴 했지만, 그 시절 읽었던 수많은 만화 중 하나일 뿐이었다. 재매있긴 했지만 그 이상의 기억은 희미했다. 스토리도 잘 기억이 나질 않았다.\n하지만 기대 이상으로 잘 만들어진 영화라는 생각이 들었다. 단지 만화를 영화로 옮긴 것에서 그치지 않고 메인 스토리를 가지고 새로운 이야기를 그려냈다. 기존 만화의 이야기는 크게 언급되지 않았고, 영화의 시작부터 마지막까지 산왕과의 경기로만 흘러간다. 대신 각 인물들의 과거 이야기가 중간 중간에 오버랩되어 나오는 구성이었는데 상당히 흥미로웠다. 각 인물들의 과거의 그들이 겪은 좌절, 그리고 이를 극복한 경험들이 모두 한데 침착되어 산왕전의 패스 하나, 슛 하나로 이어진다는 느낌을 받았다.\n사실 인생도 그렇지 않은가. 매일의 작은 경험, 기억, 감정들이 차곡차곡 쌓이며 나만의 개성과 역사를 구축하고, 그렇게 만들어진 덩어리가 결국 미래의 항로를 결정해나간다. 이 관점에서 강백호의 \u0026amp;ldquo;감독님의 영광의 시대는 언제인가요? 나는 지금입니다.\u0026amp;rdquo; 라는 명대사가 새롭게 다가왔다. 이전에는 \u0026amp;ldquo;미래의 어떤 순간보다 지금이 중요하니, 바로 지금 모든 걸 쏟아붓겠다\u0026amp;rdquo; 라는 의미로 이해했지만, 이제는 \u0026amp;ldquo;오늘의 경험과 승리를 쌓아서 더 나은 내일을 만들겠다\u0026amp;quot;는 의미로 들린다.\n삶을 쟁취와 성취의 관점에서 본다면, 일상의 작은 승리들은 결코 소홀히 대할 수 없다. 흔히 말하는 \u0026amp;ldquo;이기는 습관\u0026amp;quot;을 쌓아가는 것이 중요하다. 슬램덩크는 겉보기에는 단순히 스포츠 만화일지 모르지만, 깊어 들여다보면 나를 완성해나가는 과정에서의 고민과 시련, 그리고 그것들을 이겨내는 습관을 만들어나가는 주인공들의 여정을 그린 것이다. 정우성처럼 이미 완성된 천재라 할지라도 조그만 생채기가 나고 그 상처를 치유해나가는 과정에서 더 강해진다. 송태섭 같은 노력파는 손바닥에 쓰여진 글씨를 읽는 습관을 통해 걱정을 지우고 여유로운 마음을 찾는 훈련을 통해 목표에 다가선다.\n대부분의 삶은 어쩌면 땀에 흠뻑 젖은 채 코트 위를 달리는 열 명의 선수가 아니라, 벤치에서 그들을 바라보는 교체 선수, 혹은 응원을 보내는 아무개에 더 가까울 지도 모르겠다. 삶의 특별한 순간은 그리 자주 찾아오지 않는다. 그럼에도 누구에게나 주인공의 순간은 있다. 멀찍이서 삶의 항로를 뒤돌아봤을 때 유난히 빛나고 있는, 그래서 오늘날의 나를 강하게 만들어주는 그런 순간들이 분명 있다. 그 기억들을 쉬이 잊게 된다면 나는 어쩌면 내가 아니게 될지도 모른다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "나의 기계식 키보드 연대기",
    "permalink": "/chronicle-of-mechanical-keyboard/",
    "date":      "2022년 11월 16일",
    "summary":   "근래 주력 키보드를 교체하면서 내가 그동안 써온 기계식 키보드의 수를 세보니 어느새 그 수가 10대에 달했다. 기간도 대략 10여 년 정도가 되었는데 그동안 여러 키보드를 바꿔가며 써오다보니 어느새 기계식 키보드가 일종의 취미가 되어버렸다. 그동안 써오던 키보드 들도 떠올릴 겸 기억을 되살려 연대기를 써보기로 했다.\n기계식 키보드란 물건을 접한 건 일산의 어느 PC방 에서였다. 시간이 어중간하게 붕 떠버린 탓에 들어간 PC 방은 당시로는 상당히 최신식이었다. 게임 로그인을 하려 무심코 키보드 위에 손을 얹어 타이핑을 하는 데 손 끝에서 느껴지는 감각이 뭔가 신선했다. 그동안 경험해오던 키보드와는 뭔가 다른 색다른 키감이었다. 어느새 그 독특한 키감에 반해 하려던 게임은 안하고 한참을 키보드 타이핑만 했던 것 같다. 그때는 몰랐지만 그 키보드는 체리 청축 키보드였다.\n",
    "content":   "근래 주력 키보드를 교체하면서 내가 그동안 써온 기계식 키보드의 수를 세보니 어느새 그 수가 10대에 달했다. 기간도 대략 10여 년 정도가 되었는데 그동안 여러 키보드를 바꿔가며 써오다보니 어느새 기계식 키보드가 일종의 취미가 되어버렸다. 그동안 써오던 키보드 들도 떠올릴 겸 기억을 되살려 연대기를 써보기로 했다.\n기계식 키보드란 물건을 접한 건 일산의 어느 PC방 에서였다. 시간이 어중간하게 붕 떠버린 탓에 들어간 PC 방은 당시로는 상당히 최신식이었다. 게임 로그인을 하려 무심코 키보드 위에 손을 얹어 타이핑을 하는 데 손 끝에서 느껴지는 감각이 뭔가 신선했다. 그동안 경험해오던 키보드와는 뭔가 다른 색다른 키감이었다. 어느새 그 독특한 키감에 반해 하려던 게임은 안하고 한참을 키보드 타이핑만 했던 것 같다. 그때는 몰랐지만 그 키보드는 체리 청축 키보드였다.\n집에 돌아와 찾아보니 그것이 바로 기계식 키보드라는 것 같았다. 하지만 가격이 만만치 않은 탓에 쉽게 지르지 못하고 있다가 1년에 한 번 뿐인 생일 선물 찬스를 이용해 첫 기계식 키보드를 가질 수 있게 되었다. 그 때가 2012년 말이었다.\n나의 첫 기계식 키보드는 아이락스 제품이었다. 사실 그 때만 해도 기계식 키보드 스위치의 종류가 다양하고 스위치 별로 키감이 천차만별이라는 사실을 몰랐다. 그래서 초보자에게 제일 추천한다는 체리 적축 스위치의 키보드를 골랐다. 그렇게 고대하던 택배 상자를 열고 처음으로 키보드를 타건해보는 순간, 허무한 실망감을 금치 못했다. 이 느낌은 내가 일산 PC방에서 느꼈던 느낌과는 전혀 다른 느낌이었다. 상쾌하게 찰칵이는 키감을 기대했지만 손 끝에 느껴지는 감각은 심심하기 그지 없었다. 사실 이전까지 써오던 멤브레인 키보드와 다른 게 무언가 라는 생각까지 들었다. 하지만 바로 새로운 키보드를 지르기에는 가격이 만만치 않았던 터라 그 키보드를 열심히 쓰기 시작했다.\n두 번째 키보드도 첫 번째 키보드와 마찬가지로 다음 해 생일 찬스를 이용해 받았다. 스위치 별로 키감이 상당히 다르다는 사실을 뼈저리게 느꼈기 때문에 이번에는 신중에 신중을 기울였다. 주변에 기계식 키보드를 사용하는 동료들 책상을 돌아다니며 서로 다른 키감을 몸으로 직접 느껴보기도 했다. 장고의 시간 끝에 나의 선택은 체리 갈축이었다. 청축을 사무실에서 쓰기에는 소음이 너무 심했고, 적축보다는 구분감이 좀 더 느껴지기를 원했기 때문이었다. 그렇게 고른 키보드 모델은 레오폴드 FC660M 이었다.\n사진에서 보다시피 이 키보드는 60% 배열이었다. 이전에 쓰던 아이락스 제품은 풀 배열이었는데 풀 배열 보다는 마우스까지의 동선이 짧은 텐키리스 배열이 더 낫다고 판단했고, 기왕 짧아지는 거 텐키리스보다 짧은 FC660M 의 배열을 사용해보기로 했다.\n선택의 결과는 대만족이었다. 체리 갈축 스위치의 키감도 마음에 들었고, 배열도 마음에 들었지만 예상치 못하게 내 만족감을 배가시킨 것은 키캡의 재질이었다. 살짝 오돌토돌한 질감의 키캡은 타이핑의 즐거움을 더욱 더해주었다. 덕분에 이 키보드를 상당히 오랫동안 주력 키보드로 사용했었다.\nFC660M 갈축에 대만족을 하고 있었지만 이쯤되니 다른 키보드들의 느낌은 어떨까 궁금해졌다. 먼저 일산의 이름모를 PC방에서 처음으로 기계식 키보드의 즐거움에 눈뜨게 해주었던 체리 청축 스위치의 키보드를 하나 더 사보기로 했다. 모델은 이전과 동일하게 레오폴드 FC660M 이었는데 이 배열에 상당히 만족하고 있었기 때문에 굳이 다른 모델로 넘어갈 필요성을 느끼지 못했다. 그렇게 세 번째 키보드, FC660M 체리 청축 키보드를 들이게 된다.\n이쯤부터 키보드를 꾸미는 데에도 재미를 붙이기 시작했다. 내심 알록 달록한 키캡으로 키보드를 꾸미고 싶었지만 그런 포인트 키캡을 구하는 것이 쉽지 않았다. 마침 FC660M 청축 키보드의 키캡이 무각 흰색이었던 덕에 문구점에서 염료를 따로 사다가 집에서 키캡 염색을 해보기도 했다.\n당시 회사에는 기계식 키보드를 사용하는 동료가 꽤 있었는데 그 중 하나가 리얼포스였다. 같은 팀 과장님이 사용하던 키보드였는데 가 …",
    "tags":      ["daily"]
  },
  {
    "title":     "손절의 시대",
    "permalink": "/cut-off/",
    "date":      "2022년 06월 01일",
    "summary":   "어떤 키워드들은 당시의 시대상을 반영하면서 탄생하고 유행한다. 2000년대 언젠가의 기억을 더듬어보면 \u0026ldquo;웰빙\u0026quot;의 시대가 있었다. \u0026ldquo;그린라이트\u0026quot;라는 표현이 유행하게 된 맥락에는 남녀 문제와 성 문제를 공개적인 영역에서 당당하기 논의하게 된 사회적 변화가 있었다. 먹고살기 퍽퍽해진 시대에는 \u0026ldquo;헬조선\u0026quot;이라는 신조어가 튀어나오기도, 헬조선을 견디다 못해 \u0026ldquo;욜로\u0026quot;와 같은 새로운 종류의 라이프 스타일을 뜻하는 신조어가 유행을 타기도 했다. 가상화폐와 코로나 발 유동성 파티가 벌어지던 시대를 맞아 \u0026ldquo;파이어족\u0026rdquo;, \u0026ldquo;경제적 자유\u0026rdquo; 같은 단어들이 입에 오르내리기도 했다.\n근래의 시대상을 대변하는 다른 단어를 찾다보니 \u0026ldquo;손절\u0026quot;이 떠오른다. 손절은 원래 주식을 매입했으나 주가가 떨어져 손해를 감수하고 매도하는 손절매라는 단어가 원형이다. 하지만 어쩐지 요즘에는 사람간의 관계를 끊어내는 의미로 사용되는 것 같다. 용례를 생각해보면 무시무시하다.\n",
    "content":   "어떤 키워드들은 당시의 시대상을 반영하면서 탄생하고 유행한다. 2000년대 언젠가의 기억을 더듬어보면 \u0026amp;ldquo;웰빙\u0026amp;quot;의 시대가 있었다. \u0026amp;ldquo;그린라이트\u0026amp;quot;라는 표현이 유행하게 된 맥락에는 남녀 문제와 성 문제를 공개적인 영역에서 당당하기 논의하게 된 사회적 변화가 있었다. 먹고살기 퍽퍽해진 시대에는 \u0026amp;ldquo;헬조선\u0026amp;quot;이라는 신조어가 튀어나오기도, 헬조선을 견디다 못해 \u0026amp;ldquo;욜로\u0026amp;quot;와 같은 새로운 종류의 라이프 스타일을 뜻하는 신조어가 유행을 타기도 했다. 가상화폐와 코로나 발 유동성 파티가 벌어지던 시대를 맞아 \u0026amp;ldquo;파이어족\u0026amp;rdquo;, \u0026amp;ldquo;경제적 자유\u0026amp;rdquo; 같은 단어들이 입에 오르내리기도 했다.\n근래의 시대상을 대변하는 다른 단어를 찾다보니 \u0026amp;ldquo;손절\u0026amp;quot;이 떠오른다. 손절은 원래 주식을 매입했으나 주가가 떨어져 손해를 감수하고 매도하는 손절매라는 단어가 원형이다. 하지만 어쩐지 요즘에는 사람간의 관계를 끊어내는 의미로 사용되는 것 같다. 용례를 생각해보면 무시무시하다.\n친구를 손절하고, 여자친구를 손절하고, 부모를 손절한다.\n가끔 온라인에서 고민 상담글을 종종 보곤 한다. 친구에게 돈을 빌려줬는데 못 돌려받고 있다, 남자 친구 핸드폰에서 전 여자친구 사진을 발견했다, 결혼을 앞두고 장인될 사람이 비상식적인 행동을 했다 등등. 댓글들은 대부분 입을 모아 손절을 외친다.\n손절하세요. 일찍 알게 되서 다행이네요. 그런 관계를 굳이 스트레스 받아가면서 유지할 필요가 있나요. 손절하세요.\n바야흐로 그런 시대인 것 같다. 각자에게 요구되는 도덕성, 인격, 상식 수준은 모두 상향 평준화 되었고 흠결 사유가 발견되면 가차없이 아웃이다. 그 대상이 TV에 나오는 공인이던, 랜선 너머 익명의 누군가이던, 20년 지기 친구던 이해의 여지는 없다. 그렇게 우리는 점차 자신의 곁을 내어주는 것을 어색해하기 시작했다.\n이런 변화에 씁쓸해하면 옛날 사람이 되어가는 걸까. 누구나 실수를 하고 실언을 한다. 의도와 본심은 상황에 따라 곡해된다. 하지만 충분히 무르익은 관계는 실수와 오해를 초월할 수 있지 않을까 하는 생각을 했다.\n우리에게 용납될 수 없는 일이 정말로 그러한지, 혹은 너그럽게 보면 그려려니 할 수 있는 종류의 일인지 모르겠다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "감자칩과 인터넷 밈",
    "permalink": "/catching-context/",
    "date":      "2022년 05월 11일",
    "summary":   "신문에서 감자칩과 인터넷 밈 이라는 글을 보다가 생각해볼 만한 부분을 발견하여 일부를 발췌해본다.\n\u0026hellip; 적어도 현 시점까지의 인터넷은 빠르고 짧은 정보를 선호한다. 디바이스도, 플랫폼도, 매체도, 이용자도 그렇다. \u0026lsquo;빠르고 짧다\u0026rsquo;는 표현은 어쩌면 동어반복인데, 인터넷 세상에서 어떤 정보가 빨리 전파되려면 짧아야 하기 때문이다.\n한데 지식은 대개 짧지 않다. 지식이란 정보들이 논리에 따라 연결되어 있는 구조물이다. 깊은 지식일수록 규모가 크고 구조가 복잡하다. 따라서 문맥이 중요하다. 책 한 권을 문장 단위로 분리해서 마구 흐뜨러뜨린 뒤 순서 없이 읽는다면, 그 책의 모든 글자를 다 본다 해도 제대로 이해하는 내용은 아주 적을 게다. 그게 인터넷이고 소셜미디어다.\n",
    "content":   "신문에서 감자칩과 인터넷 밈 이라는 글을 보다가 생각해볼 만한 부분을 발견하여 일부를 발췌해본다.\n\u0026amp;hellip; 적어도 현 시점까지의 인터넷은 빠르고 짧은 정보를 선호한다. 디바이스도, 플랫폼도, 매체도, 이용자도 그렇다. \u0026amp;lsquo;빠르고 짧다\u0026amp;rsquo;는 표현은 어쩌면 동어반복인데, 인터넷 세상에서 어떤 정보가 빨리 전파되려면 짧아야 하기 때문이다.\n한데 지식은 대개 짧지 않다. 지식이란 정보들이 논리에 따라 연결되어 있는 구조물이다. 깊은 지식일수록 규모가 크고 구조가 복잡하다. 따라서 문맥이 중요하다. 책 한 권을 문장 단위로 분리해서 마구 흐뜨러뜨린 뒤 순서 없이 읽는다면, 그 책의 모든 글자를 다 본다 해도 제대로 이해하는 내용은 아주 적을 게다. 그게 인터넷이고 소셜미디어다.\n문맥이라는 단어가 유난히 시선을 잡아끈다. 사실 문맥을 읽어내는 것은 모든 일에서 중요하지 않나 하는 생각이 든다. 우리가 마주하는 일상은 항상 거대한 카오스 덩이리이고, 그 안에 친절한 3줄 요약 같은 건 없다. 중요한 인사이트는 장면이 아니라 거대한 줄기를 아우르는 문맥에서 온다. 사람과의 관계에서 문맥을 읽어내는 일, 업무에서 문맥을 읽어내는 일, 심지어는 30여년 짜리 대서사 같은 내 인생에서의 문맥을 읽어내는 일. 내가 마주하는 문맥 중 어느 하나 중요하지 않은 것이 없다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     " 네이버 클라우드 입사 8개월차 회고",
    "permalink": "/8th-month-after-joining-naver-cloud/",
    "date":      "2022년 04월 21일",
    "summary":   "작년 8월 말에 현재의 회사, 네이버 클라우드로 이직해왔다. 학교 다닐 적에는 전학 한 번 없이 스트레이트로 졸업까지 했건만, 직장인이 된 이후로는 어쩌다보니 이직을 꽤 자주 하고 있다.\n매번 이렇게 다른 회사, 다른 포지션으로의 변화를 겪다보니 이직이 마치 여행과 같다는 생각을 하기도 한다. 익숙한 동네와 사람들을 떠나 새로운 곳에서 새로운 문화와 만나는 여정과 같으니 말이다. 밖에서 볼때는 어차피 똑같은 IT 회사에 똑같은 개발자로의 이직이니 다 비슷비슷하지 않겠느냐 하고 볼 수도 있겠지만, 실제로는 매번 이직 때마다 너무 다른 경험들을 하게 된다. 사람들이 다르고, 회사가 다르고, 향하는 목적지가 다르니 당연한 일이다.\n",
    "content":   "작년 8월 말에 현재의 회사, 네이버 클라우드로 이직해왔다. 학교 다닐 적에는 전학 한 번 없이 스트레이트로 졸업까지 했건만, 직장인이 된 이후로는 어쩌다보니 이직을 꽤 자주 하고 있다.\n매번 이렇게 다른 회사, 다른 포지션으로의 변화를 겪다보니 이직이 마치 여행과 같다는 생각을 하기도 한다. 익숙한 동네와 사람들을 떠나 새로운 곳에서 새로운 문화와 만나는 여정과 같으니 말이다. 밖에서 볼때는 어차피 똑같은 IT 회사에 똑같은 개발자로의 이직이니 다 비슷비슷하지 않겠느냐 하고 볼 수도 있겠지만, 실제로는 매번 이직 때마다 너무 다른 경험들을 하게 된다. 사람들이 다르고, 회사가 다르고, 향하는 목적지가 다르니 당연한 일이다.\n업무 도메인의 변화 이직에 따른 나의 여정을 되짚어보니, 우연찮게도 나는 점점 더 low level 의 기술들을 다루고 있었다. 5년 전에는 RIDI 에서 웹 개발을 하고 있었는데, 그 이후에 SK C\u0026amp;amp;C 에서는 클라우드 모니터링 서비스를 SaaS 형태로 만들었고, 현재 회사에서는 매니지드 Kubernetes 서비스에 대한 PaaS 를 만들고 있다. 의도했던 건 아니었고, 그냥 매 이직 때마다 마음에 드는 회사와 포지션을 쫓았을 뿐인데 어쩌다보니 이런 경향성을 띄게 띄었다.\n생각해보면 참 우스운 일이기도 한게, 나는 원체 low level 에 약했다. 학교 다닐 적 졸업 작품에서 다뤘던 기술은 웹과 앱 개발 이었다. 당시에도 몇몇 친구들은 졸작으로 리눅스 기반의 네트워크 트래픽 제어 라던지, 심지어 선배 중에는 간단한 OS 를 만든 케이스도 있었다. 하지만 당시의 나로써는 설명을 들어도 그게 뭔지 이해도 다 못하는 수준이었다. 리눅스는 정말 기초적인 커맨드 외에는 아는 게 없었고, 학교에서 배우는 CS 관련 수업도 어찌어찌 따라가긴 했지만 어디가서 자랑할 만한 수준은 못되었다. 졸업 후 첫 회사에서 서버 개발자로 일하긴 했지만 그저 응용단 개발자에 지나지 않았다. 내가 작성하는 코드 기저의 추상화된 영역은 거의 알지 못했다. 반정도는 일종의 블랙박스였다. 단순히 코드 내에서 접속할 IP 주소와 포트 넘버를 지정해주면 원격지로 연결이 된다 정도 까지는 인지를 하고 있었다. 그리고 그 기저에서에는 수업에서 배운대로 TCP/IP 프로토콜을 통해 어떤 식으로든 패킷을 주고 받는다 정도의 피상적인 이해만 가지고 있었다. 실제로 패킷을 까본다던가 관련된 커맨드들을 활용해본 경험은 없었고, 사실 그렇게 할만큼의 충분한 지식도 없었다.\n그러다 보니 이러한 OS 및 인프라 영역에 대한 내 지식은 대부분 실전에서 맨 땅에 헤딩을 하면서 알게 된 부분이 많았다. 가령 스토리지 용량이 충분한데 계속해서 발생하는 No space left on device 에러로그 앞에서 멘붕을 하며 하루종일 구글링을 하다가 inode 의 존재에 대해 알게 되는 식이었다. 문제가 생기면 에러 메시지를 구글링해보고, 스택 오버플로우의 고수들의 대답을 보면서 실제로 인프라 레벨에서의 동작 과정을 어렴풋이 가늠하곤 했다. 그러다 정 이해가 안되는 부분이 있으면 더 깊게 찾아보고 그래도 이해가 안되는 부분은 다시 블랙 박스로 남겨두기도 했다.\n그래서 웹 개발의 영역을 벗어나 SK C\u0026amp;amp;C 의 모니터링 서비스 개발이나, 현재 네이버 클라우드의 Kubernetes Service 개발 포지션으로 이직을 할 때 마다 내 솔직한 심정은 8할의 설렘과 2할의 걱정이었다. 매번 더 low level 의 영역을 향해 도전하는 셈인지라 새로운 경험을 쌓아갈 수 있다는 종류의 설렘과 함께, 이 일을 내가 잘 해낼 수 있을까, 지금 내 역량이 혹시 부족하지는 않을까 하는 심정이었다. 그간 어떻게든 적응을 하고 답을 찾아내었던 가닥이 있으니 이번에도 열심히 헤딩하면 어떻게 되지 않을까 하는 생각도 있었다.\n입사 후 8개월 정도가 지난 현재 시점에서 돌아보면 이번 도전은 그간 다소 부진했던 학습/성장 곡선의 기울기를 다시 세워주고 있다는 체감이 든다. 그동안 어느 정도 경험이 있던 웹을 비롯한 응용 단의 개발 뿐만 아니라, 인프라 영역에서의 경험은 훗 …",
    "tags":      ["career"]
  },
  {
    "title":     "\u003c뜨거운 피\u003e 관람/독서 후기",
    "permalink": "/hot-blood/",
    "date":      "2022년 03월 30일",
    "summary":   "느와르 영화를 좋아하는 편이라 \u0026lt;뜨거운 피\u0026gt;의 예고편을 보고는 후다닥 예매를 해서 보고 왔다. 기대보다 재미있게 봐서 원작 소설도 찾아서 완독을 했다. 영화와는 또 다른 재미가 있었다.\n영화는 뭐랄까, 알파메일들의 대활극 정도의 느낌이었다. 부산이라는 공간도 이런 스토리가 잘 어울렸다. 각각의 독특한 캐릭터들이 인상적이었고, 그들이 마치 사자가 영역 싸움을 하듯 서로의 덩치를 부풀리며 으르릉 거리는 모습이 멋지게 다뤄졌다. 폭력적이기도 했지만 반대로 다소 찌질하고 암울하기까지 한 건달들의 이야기는 매력이 이썼다.\n영화 마지막에 주인공 희수를 비추며 나오는 나레이션 역시 여운을 남기며 이야기를 잘 정리해준다는 느낌을 받았다.\n",
    "content":   "느와르 영화를 좋아하는 편이라 \u0026amp;lt;뜨거운 피\u0026amp;gt;의 예고편을 보고는 후다닥 예매를 해서 보고 왔다. 기대보다 재미있게 봐서 원작 소설도 찾아서 완독을 했다. 영화와는 또 다른 재미가 있었다.\n영화는 뭐랄까, 알파메일들의 대활극 정도의 느낌이었다. 부산이라는 공간도 이런 스토리가 잘 어울렸다. 각각의 독특한 캐릭터들이 인상적이었고, 그들이 마치 사자가 영역 싸움을 하듯 서로의 덩치를 부풀리며 으르릉 거리는 모습이 멋지게 다뤄졌다. 폭력적이기도 했지만 반대로 다소 찌질하고 암울하기까지 한 건달들의 이야기는 매력이 이썼다.\n영화 마지막에 주인공 희수를 비추며 나오는 나레이션 역시 여운을 남기며 이야기를 잘 정리해준다는 느낌을 받았다.\n\u0026amp;ldquo;뜨거운 것들은 모두 사라졌다. 허깨비처럼 쓸쓸하고 무의미한 것이 되었다. 하지만 헛것을 뒤집어쓰고 살아갈 것이다. 치욕과 슬픔에 발을 담그고.\u0026amp;rdquo;\n소설은 영화와는 또 다른 맛이었다. 영화에서는 생략되거나 수정된 이야기들이 꽤 있었고, 영화에서는 전하기 힘든 상황적인 설명도 곁들여져 있었다. 덕분에 영화만 봤을 때는 이해가 잘 안되던 부분이 소설로 채워지는 부분들도 있었다.\n그리고 작중 캐릭터들이 영화보다 찌찔하고 야비하고 볼품없게 비춰진다. 소설의 첫 문장은 이렇게 시작된다.\n구암의 건달들은 아무도 양복을 입지 않는다.\n구암의 건달들은 아무도 온 몸에 문신을 휘감지 않는다. 반딱거리는 정장을 걸치고 보무 당당하게 활개치는 모습은 찾아볼 수 없다. 유니폼은 츄리닝이고, 박력있는 캐릭터 대신 찌질하고 무식한 캐릭터들이 즐비하다.\n주인공인 희수도 영화에서는 구암의 에이스인 장면들 위주로 비춰지지만, 소설에서는 나이 마흔에 가진 건 빚뿐인, 호텔 달방을 전전하는 자조적인 모습들로 설명된다. 심지어 빚도 영화보다 몇 배 더 많다.\n그래도 전반적인 스토리는 영화나 소설이나 비슷하게 흘러간다. 하지만 마지막 작가의 말은 영화와 조금 결을 달리 한다.\n\u0026amp;hellip; 사람들은 더 쿨해지고 더 예의발라지고 더 유머러스해진다. 상대방을 배려하고 관대하게 대한다. 모두들 상처를 주지 않기 위해 상대방을 예민하게 살핀다. 쾌적하고 젠틀하고 깔끔하다. 하지만 나는 어쩐지 이 예의바르고 유머러스한 관계 속에서 갑갑함을 느낀다. 사람을 만나는 일이 점점 더 힘들고 공허해진다. 이 도시가 이렇게 예의바르고 관대할 수 있는 것은 아무도 문을 열지 않기 때문이다. \u0026amp;hellip;\n사람들은 이제 뜨겁지 않다. 뜨거운 것들은 모두 미숙하고 촌스럽고 어른스럽지 못하다는 죄목으로 촌충처럼 사라져버렸다. 그럴 때마다 나는 구암의 그 지리멸렬한 삶이 그리워진다. 구암의 시절엔 짜증나고, 애증하고, 발끈해서 술판을 뒤집었지만 적어도 이토록 외롭지는 않았다.\n이 밤에 혼자 소주병을 따며 나는 상처를 주지 않고 사랑을 건낼 방법을 떠올려본다. 상처를 받지 않고 사랑을 받을 방법을 떠올려본다. 하지만 이내 고개를 흔든다. 그런 삶은 없다. 모든 좋은 것은 나쁜 것과 버무려져 있다. 문을 닫으면 악취가 들어오지 않지만 꽃향기도 들어오지 못하는 것처럼. \u0026amp;hellip;\n영화에서의 \u0026amp;ldquo;뜨거운 것\u0026amp;quot;은 건달의 그것이었으나, 소설에서의 \u0026amp;ldquo;뜨거운 것\u0026amp;quot;은 친구, 이웃, 동료, 사람들의 그것이었다. 누구누구의 장례식장에서 작은 말다툼으로 시작해 끝내는 상을 뒤엎고 주먹질이 오가지만, 결국 다음 날 또 아무렇지 않은 얼굴로 마주하고 사과를 주고 받는 뜨거움. 재미도 없는 농을 매일같이 남발하는 바람에 혈압이 오르게 하지만 끝내는 \u0026amp;ldquo;그래도 심성은 착한 놈\u0026amp;rdquo; 이라고 회상하는 뜨거움.\n미지근해지는 세상에 다소 아쉽던 차에 재미있게 읽은 책이었다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "길 잃은 노인을 만났다.",
    "permalink": "/met-a-lost-old-man/",
    "date":      "2022년 02월 18일",
    "summary":   "며칠 전의 일이다.\n아파트 상가의 한 편의점에서 친구를 기다리는데 한 노인분이 들어오셔서 갑자기 말을 걸었다.\n\u0026ldquo;109동이 어딥니까?\u0026rdquo;\n처음에는 부정확한 발음 때문에 몇 번을 되물었다. 하지만 곧 노인께서 찾으시는 게 아파트 단지 내 109동이란 걸 확인한 후에 지도 앱을 켜서 위치를 안내해드렸다. 하지만 그러고도 한참을 가만히 계시다가 다시 \u0026ldquo;109동이 어딥니까?\u0026rdquo; 하고 물으셨다. 좀 더 자세히 설명드려야 하나 싶어 고민하는데 한 마디를 덧붙이셨다.\n\u0026ldquo;109동이 우리 집인데 어딘지를 기억이 나질 않아요.\u0026rdquo;\n심장이 덜컹하고 떨어지는 기분이었다.\n",
    "content":   "며칠 전의 일이다.\n아파트 상가의 한 편의점에서 친구를 기다리는데 한 노인분이 들어오셔서 갑자기 말을 걸었다.\n\u0026amp;ldquo;109동이 어딥니까?\u0026amp;rdquo;\n처음에는 부정확한 발음 때문에 몇 번을 되물었다. 하지만 곧 노인께서 찾으시는 게 아파트 단지 내 109동이란 걸 확인한 후에 지도 앱을 켜서 위치를 안내해드렸다. 하지만 그러고도 한참을 가만히 계시다가 다시 \u0026amp;ldquo;109동이 어딥니까?\u0026amp;rdquo; 하고 물으셨다. 좀 더 자세히 설명드려야 하나 싶어 고민하는데 한 마디를 덧붙이셨다.\n\u0026amp;ldquo;109동이 우리 집인데 어딘지를 기억이 나질 않아요.\u0026amp;rdquo;\n심장이 덜컹하고 떨어지는 기분이었다.\n마침 친구도 아직 도착하지 않아 직접 모셔다 드리겠다고 했다. 롱패딩으로 꽁꽁 싸맨 제 외투와는 다르게 노인의 외투는 그다지 두꺼워보이지 않는 등산복 재킷이었다.\n\u0026amp;ldquo;한 시간을 헤맸어.\u0026amp;rdquo;\n그때 기온이 영하 5도였다. 두꺼운 롱패딩으로 둘둘 싸맨 나 마저도 추워서 편의점 안으로 대피해있던 참이었다. 노인께서 한 손에 쥐고 있던 등산용 스틱인지 지팡이 인지가 유난히 위태로워 보였다.\n가족에게 연락을 드려야 하나 싶어 댁에 가족이 있으신지 여쭈었다.\n\u0026amp;ldquo;아내가 있었는데 작년에 갔어. 지금은 혼자 살아요.\u0026amp;rdquo;\n그리고는 다른 이야기를 한참 하시다가 씁쓸한 목소리로 다시 덧붙이셨다.\n\u0026amp;ldquo;109동이 우리 집인데 기억이 안나. 내 머리가 정말 이상한가봐.\u0026amp;rdquo;\n노인분의 집으로 향하면서 이런저런 이야기를 나누었다. 올해로 연세가 88살이라고 하셨고, 이 아파트에는 2017년 1월 13일에 이사를 오셨다고 했다. 날짜까지 정확히 기억하시는 걸 보니 기억력이 정말 좋으신 것 같다고 말씀드리니 조용히 웃으셨다.\n자제분들에 대해 여쭈니 분당에서 살고 계시다고 하셨다. 그리고는 얼마전에 자식 분들이 점심 시간에 찾아와 같이 식사를 하는데, \u0026amp;ldquo;아버지 괜찮냐\u0026amp;quot;고 묻고는 \u0026amp;ldquo;아무래도 이상하다\u0026amp;rdquo; 는 이야기를 했단다.\n이윽고 109동에 도착했다. 노인께서는 고맙다며 몇 번이고 내게 악수를 청했다. 혹시 몇 호인지도 기억을 못하실까 싶어 들어가시는 것까지 보고 가겠다고 했지만 한사코 괜찮다며 나를 돌려세우셨다. 다음 번에 또 헷갈리시면 아파트 입구의 관리사무소를 찾으시는 게 좋을 것 같다고 조언드리고 발걸음을 돌렸다.\n요 며칠 계속 그 때의 생각이 난다.\n세상 사람들이 다 나를 잊어갈 때도 마지막까지 나를 기억하는 건 다른 누구도 아닌 나 자신이다. 그런 나 자신마저 나를 잊어가는 일이 얼마나 암담하고 무서울 지, 또 얼마나 서럽고 외로울 지 감히 상상도 되질 않는다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "Rust 사용 소감",
    "permalink": "/thoughts-about-rust/",
    "date":      "2022년 02월 08일",
    "summary":   "몇 년 전엔가, Rust 를 배워볼까 생각을 해본 적이 있었다. Java 를 메인으로 쓰던 때였다. 그 즈음에 Go 언어를 새로이 배워 이것저것 만들어보곤 했는데, Java 를 사용하면서 느꼈던 아쉬움들이 많은 부분 해소가 되어 Go 언어에 꽤 깊이 빠져있었다. 그와 동시에 매번 Go 언어와 붙어서 비교가 되곤 하는 Rust 에 대한 호기심이 들었다. GC 도 없다고 하니 좀 더 퍼포먼스 크리티컬한 걸 짤 때 더 효과적이지 않을까 하는 기대를 가지고 있었다.\n",
    "content":   "몇 년 전엔가, Rust 를 배워볼까 생각을 해본 적이 있었다. Java 를 메인으로 쓰던 때였다. 그 즈음에 Go 언어를 새로이 배워 이것저것 만들어보곤 했는데, Java 를 사용하면서 느꼈던 아쉬움들이 많은 부분 해소가 되어 Go 언어에 꽤 깊이 빠져있었다. 그와 동시에 매번 Go 언어와 붙어서 비교가 되곤 하는 Rust 에 대한 호기심이 들었다. GC 도 없다고 하니 좀 더 퍼포먼스 크리티컬한 걸 짤 때 더 효과적이지 않을까 하는 기대를 가지고 있었다.\n하지만 딱히 이렇다할 기회가 없었는데 요즘 Rust 를 써볼 수 있는 기회를 가지게 되었다. 하지만 제대로 처음 접해본 Rust 에 대한 나의 현재 감상은 영 실망이다. 처음 학습을 진행하던 초반에는 그래도 꽤 재미있기도 했다. syntax sugar 도 많아서 \u0026amp;ldquo;이거 잘만 익숙해지면 꽤 재미있는 코드들을 만들어낼 수 있겠구나\u0026amp;rdquo; 싶었다. Go 언어에 차용해보고 싶은 부분들도 여럿 보였다. trait 이라던가, scala 에서 가져온듯 한 match 기능도 마음에 들었다. 하지만 여러 장점들을 쭉 나열해놓는다고 해도 다 덮지 못할 만큼 단점도 크게 느껴졌다.\n일단 너무 복잡했다. 아직 언어가 완벽히 손에 익은 단계가 아니라서 더 그렇겠지만, 익숙해진다 한들 이걸 정말 편하게 쓸 수 있을까 하는 의구심이 들었다. 특히 소유자 개념이 그런데, 이 때문에 순수 비즈니스 로직 외적으로 고민해야 하는 부분들이 너무 많았다. 거기다가 컴파일 속도 마저 느려도 너무 느렸다. Rust 로 만들어진 모듈을 간단히 수정만 하면 되는 일인데 꽤나 오랜 시간을 여기다가 쏟아 붓고 있다. 앞으로 Rust 를 도입할 수 있는 기회가 온다 하더라도 쉽사리 손을 뻗을 수 있을 것 같지 않다.\n",
    "tags":      ["tech"]
  },
  {
    "title":     "아이에게는 부모가 세상의 전부다",
    "permalink": "/parents-are-everything-to-a-child/",
    "date":      "2021년 12월 08일",
    "summary":   "\u0026ldquo;아이에게는 부모가 세상의 전부\u0026rdquo; 라는 말이 요즘 종종 머리에 맴돈다. 아이가 와서는 팔을 잡아당기며 놀아달라고 할 때 라던가 원하는 바를 얻지 못해 큰 소리로 울 때. 내가 조금 피곤하다거나 귀찮다는 이유로 아이에게 소홀히 대하지는 않았나 하는 반성을 하기도 한다. 아이는 음식도 부모가 주는 것만 먹을 수 있고, 놀이도 부모가 마련해 준 울타리 안에서만 놀 수 있다. 새로운 세상을 발견하고, 새로운 친구를 만나는 일 모두가 부모를 통해서만이 가능하다. 내가 더 부지런하면 아이는 새롭고 즐거운 경험들을 더 할 수 있는 셈이다. 내 생에 누군가에게 이렇게나 영향을 크게 끼치는 사람이 되본 적이 있던가.\n",
    "content":   "\u0026amp;ldquo;아이에게는 부모가 세상의 전부\u0026amp;rdquo; 라는 말이 요즘 종종 머리에 맴돈다. 아이가 와서는 팔을 잡아당기며 놀아달라고 할 때 라던가 원하는 바를 얻지 못해 큰 소리로 울 때. 내가 조금 피곤하다거나 귀찮다는 이유로 아이에게 소홀히 대하지는 않았나 하는 반성을 하기도 한다. 아이는 음식도 부모가 주는 것만 먹을 수 있고, 놀이도 부모가 마련해 준 울타리 안에서만 놀 수 있다. 새로운 세상을 발견하고, 새로운 친구를 만나는 일 모두가 부모를 통해서만이 가능하다. 내가 더 부지런하면 아이는 새롭고 즐거운 경험들을 더 할 수 있는 셈이다. 내 생에 누군가에게 이렇게나 영향을 크게 끼치는 사람이 되본 적이 있던가.\n사실 결혼 전에는 아이를 가지는 일에 회의적이기도 했다. 그때나 지금이나 내 인생에 큰 영향을 끼치는 일에는 직접 고민을 충분히 하고 결정을 내려야 한다고 생각하고 있고, 아이를 가지는 것이 좋을지에 대한 확신을 아직 가지지 못했던 시기였다. 사실 부모가 되면서 치뤄내야 하는 책임과 희생들에 자신이 없기도 했다. 아기를 좋아하긴 했지만 부모가 되는 일을 내가 정말 잘 해낼 수 있을까 하는 의구심도 들었다. 하지만 지금, 여전히 내가 잘 해내고 있는지는 잘 모르겠지만, 그래도 아이를 가진 것은 역시 잘한 일이라는 생각이 든다. 어찌됐건 인생은 아름답고 소중한 것이고, 그러한 인생의 씨앗을 아이에게 선물하고 그것을 잘 꽃피울 수 있게 옆에서 보살펴 주는 일은 내게도 크게 의미있고 즐거운 경험이다.\n종종 학창 시절을 생각한다. 친구들과 함께 시내를 쏘다니며 이런 저런 새로운 경험들을 하고, 처음으로 이성 친구를 만나 문자를 주고 받고, 또 새로운 학교에 진학하면서 새로운 친구들을 사귀고. 모두가 십대의 빛나는 그 시기에만 쌓을 수 있는 소중한 경험들이다. 내 아이에게도 그러한 시기가 올 것이다. 뭘 해도 즐거운 그 시기를 더 즐거이 보낼 수 있도록 내가 도울 수 있는 부분이 많았으면 좋겠다는 생각이 든다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "Golang 간단한 최적화 과정 기록",
    "permalink": "/golang-optimization/",
    "date":      "2021년 07월 08일",
    "summary":   "어젯밤에 golang 으로 작성한 모듈의 최적화를 진행했는데 생각보다 유의미한 결과를 얻었다. 그 내용을 기록으로 남겨놓는다.\nslice 선언시에 cap 파라미터를 통해 slice 내부 배열의 초기 사이즈를 지정해줄 수 있다. slice 의 사이즈를 미리 알 수 있는 상황에서는 이를 통해 배열의 재할당을 최소화할 수 있다. 전체 코드를 뒤져 cap 파라미터를 추가할 수 있는 곳들에 전부 추가해주었다. 하지만 프로파일링 결과 눈에 뛸 만큼의 성능 변화는 없었다.\nOOP 하던 습관이 남아서 그런지 그냥 함수로 선언할 수 있는 로직도 구조체로 선언한 로직들이 몇개 있었다. 불필요한 힙메모리 사용을 방지하기 위해 이를 함수로 변경했다. 이 역시 눈에 띄는 변화는 없었다.\n",
    "content":   "어젯밤에 golang 으로 작성한 모듈의 최적화를 진행했는데 생각보다 유의미한 결과를 얻었다. 그 내용을 기록으로 남겨놓는다.\nslice 선언시에 cap 파라미터를 통해 slice 내부 배열의 초기 사이즈를 지정해줄 수 있다. slice 의 사이즈를 미리 알 수 있는 상황에서는 이를 통해 배열의 재할당을 최소화할 수 있다. 전체 코드를 뒤져 cap 파라미터를 추가할 수 있는 곳들에 전부 추가해주었다. 하지만 프로파일링 결과 눈에 뛸 만큼의 성능 변화는 없었다.\nOOP 하던 습관이 남아서 그런지 그냥 함수로 선언할 수 있는 로직도 구조체로 선언한 로직들이 몇개 있었다. 불필요한 힙메모리 사용을 방지하기 위해 이를 함수로 변경했다. 이 역시 눈에 띄는 변화는 없었다.\nbyte slice 를 string 으로 변환할 때 unsafe.Pointer 를 이용해 메모리 할당 횟수를 줄였다.\n자주 사용하는 엔티티들을 디스크 기반으로 캐싱해놓은 코드가 있었는데 이를 메모리 기반으로 변경했다. 막상 캐싱되는 사이즈를 보니 메모리에만 올려도 문제가 없겠다고 판단했다. 덕분에 매번 serialize 를 하지 않아도 되었고, CPU 사용량에 의미있는 감소를 확인할 수 있었다.\nUber 에서 만든 automaxprocs 라이브러리를 적용했다.\n기존에 사용 중이던 ratelimit 용 라이브러리를 교체했다. 원래 uber 에서 만든 걸 쓰고 있었는데 알고리즘을 자세히 살펴보니 우리의 요구사항과는 안맞는 부분이 있었다. 처리량이 유의미하게 증가했음을 확인했다.\n자주 생성되는 구조체에 대해서 sync.Pool 을 적용해보았는데 생각했던 것 만큼 성능 향상이 보이지도 않았고 추후에 잘못 다루면 문제가 생길 여지가 보여서 다시 원복했다.\n",
    "tags":      ["tech"]
  },
  {
    "title":     "생일",
    "permalink": "/birthday/",
    "date":      "2021년 06월 30일",
    "summary":   "유난히 마음이 시끄러운 날이 있다. 바로 오늘 같은 날이다. 버겁기 그지없는 회사일에 파묻혀서 허우적 대기를 한참, 문득 시계를 보니 어느새 자정이다. 아무도 없는 사무실의 불을 끄고 터벅거리며 나온다. 채 끝내지 못한 회사일이 앵앵 거리는 모기 소리마냥 머리 속을 헤맨다. 관자놀이를 슬쩍 문질러보았으나 영 신통치않다. 선릉역 사거리에서 운 좋게 빈 택시와 조우한다. 도착지를 전하는 내 목소리에 얼마간의 피로함이 묻은 탓일까, 택시기사님은 별 다른 말없이 악셀을 밟는다. 말라 비틀어진 무말랭이 같은 모양새를 하고는 뒷좌석에 몸을 푹 파묻는다. 의미없이 창밖으로 놓아두었던 시선을 거두어다가 스마트폰에다 갖다 놓는다. 뉴스를 뒤적여도 영 눈에 들어오는게 없어 카카오톡을 켜본다. 거기서 당신의 이름을 발견한다. 어쩐지 위쪽에 올려진 당신의 이름 옆에는 생일 이모티콘이 반짝이고 있다. 아, 당신의 생일이 바로 오늘인 모양이다.\n",
    "content":   "유난히 마음이 시끄러운 날이 있다. 바로 오늘 같은 날이다. 버겁기 그지없는 회사일에 파묻혀서 허우적 대기를 한참, 문득 시계를 보니 어느새 자정이다. 아무도 없는 사무실의 불을 끄고 터벅거리며 나온다. 채 끝내지 못한 회사일이 앵앵 거리는 모기 소리마냥 머리 속을 헤맨다. 관자놀이를 슬쩍 문질러보았으나 영 신통치않다. 선릉역 사거리에서 운 좋게 빈 택시와 조우한다. 도착지를 전하는 내 목소리에 얼마간의 피로함이 묻은 탓일까, 택시기사님은 별 다른 말없이 악셀을 밟는다. 말라 비틀어진 무말랭이 같은 모양새를 하고는 뒷좌석에 몸을 푹 파묻는다. 의미없이 창밖으로 놓아두었던 시선을 거두어다가 스마트폰에다 갖다 놓는다. 뉴스를 뒤적여도 영 눈에 들어오는게 없어 카카오톡을 켜본다. 거기서 당신의 이름을 발견한다. 어쩐지 위쪽에 올려진 당신의 이름 옆에는 생일 이모티콘이 반짝이고 있다. 아, 당신의 생일이 바로 오늘인 모양이다.\n내가 맺고있는 인간관계가 모두 내 생활영역 안에 넉넉히 들어와있던 때가 있었다. 고등학교 시절이 그랬다. 가족과 친구들 모두 내 생활과 맞닿아 있었다. 등교를 하면 거기엔 당연스레 내 친구들이 있었고, 집으로 돌아오면 또 당연스레 가족들과 저녁을 함께 했다. 구태여 연락을 하고 만나려 하지 않아도 매일의 얼굴을 마주했고, 그 일상들을 자연스레 공유하게 되었다. 공부를 하고, 점심시간에 짬짬이 축구를 하고, 또 가끔은 야자를 째고 노래방에나 가는, 그런 내 생활들을 모두 당신들과 함께 했다.\n처음으로 그러한 패턴이 틀어진 것은 대학교 진학 이후였다. 매일을 함께하던 고등학교 친구들은 각자 대학교 합격증을 손에 들고 전국 팔도로 흩어지게 되었고, 우리는 더이상 일상을 자연스레 공유하지 못하게 되었다. 만날 이유를 찾아 약속을 잡고서야 당신들의 얼굴을 마주할 수 있었다. 습관처럼 당신들과 내 일상을 나누려다가 머뭇거린다. 당신들과 내 일상은 이제 예전처럼 자연스럽게 공유되지 않는다는 걸 깨닫는다. 그렇게 얼굴을 마주 할 기회 마저도 사실 일 년에 채 몇 번이 되지 못했다. 각자가 서로 일상을 자연스레 공유하는 다른 친구들이 생겼고, 우리의 일상은 멀어져감을 느꼈다.\n군대를 다녀오고, 졸업을 하고, 회사에 취직을 하는 매 시점마다 이러한 패턴은 계속해서 반복되었다. 여러 지인들이 내 일상에 들어와 잠시간 머물다가 또 스쳐지나간다. 자연스레 함께 하던 친구들은 어느새 일부러 손을 뻗지 않으면 닿지 않는 곳에 있었다. 송년회니 동창회니 여러 이유들을 만들어 내어 얼굴을 맞대지만 어째 매번 느끼는 것은 점점 낯설어지는 당신의 나이든 얼굴이었다. 내 기억 속의 당신은 아직까지 소년에 머물러 있는데 어째서 당신의 얼굴에선 넉넉한 나이가 느껴지는지, 또 배는 언제 그렇게 나왔는지 모를 일이다.\n생일 이모티콘과 나란히 놓여진 당신의 이름을 눌러 당신과의 대화창을 켠다. 선물하기 메뉴를 들어가 커피 기프티콘을 하나 골라본다. 생일 축하한다는 메시지와 함께 당신에게 조그만 마음을 전한다. 오랜만이라고, 어떻게 지내는지 하는 말들을 뒤에 덧붙인다. 고개를 드니 택시는 사당을 지나고 있다. 이 늦은 시간에도 사람들은 북적이고 있다. 창문이 닫혀있음에도 불구하고 그 시끌벅적한 소리가 생생히 들리는 듯 하다. 당신에게서 답장이 도착했다. 나만 당신을 그리고 있던 건 아니었는지 당신도 반가움을 전해왔다. 몇 마디 더 하잘 것 없는 신변잡기를 나누다가 우리는 이내 약속을 잡는다. 이번 주 금요일, 저녁에, 사당에서. 그 쯤에서 나는 스마트폰을 내려놓는다. 나는 당신과 다시 얼굴을 맞대고 만날 것이다. 일상을 함께 하던 어릴적 이야기도 나누고 궁금하던 당신의 근황도 물을 것이다. 우리의 일상이 얼마나 멀리 떨어져 있는지를 아쉬워해봐야 무용하다. 일년에 한 번 쯤은 당신에게 손을 내밀 수 있는 생일이라는 좋은 핑계가 있다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "좋은 곳에서 좋은 사람을 만나는 일",
    "permalink": "/meeting-good-people-at-good-place/",
    "date":      "2021년 06월 25일",
    "summary":   "누군가의 페이스북에서 본 글이 감명깊어 갈무리 겸 남겨놓는다.\n좋은 학교, 좋은 회사에 가라고 이야기하는 이유는 좋을 구루를 만나기 위해서 입니다. 좋은 곳에 좋은 구루가 있으니까요. Quantum Leap 은 물리학, 회사의 성장에만 존재하는 것이 아닙니다. 사람에게도 존재합니다. Quantum Leap 을 만들기 위해서는 지속적으로 노력하는 것도 중요하지만, 생각을 많이 하고 사람을 많이 만나는 것도 중요합니다. 저도 계속 소모되는 곳에 있어서 지치지만 시간이 되면 구루라고 생각하는 사람을 만나려고 노력합니다. 그런 사람을 만나면 대충 10분만 만나도 1년을 살 수 있습니다. 구루는 컨퍼런스에서도 만날 수 있고, 유튜브에서도 만날 수 있지만 저는 주로 커피숍에서 만납니다. 컨퍼런스의 격식차린 대화가 아닌 가벼운 대화 속에서 더 많은 것을 느낄 때가 많습니다.\n",
    "content":   "누군가의 페이스북에서 본 글이 감명깊어 갈무리 겸 남겨놓는다.\n좋은 학교, 좋은 회사에 가라고 이야기하는 이유는 좋을 구루를 만나기 위해서 입니다. 좋은 곳에 좋은 구루가 있으니까요. Quantum Leap 은 물리학, 회사의 성장에만 존재하는 것이 아닙니다. 사람에게도 존재합니다. Quantum Leap 을 만들기 위해서는 지속적으로 노력하는 것도 중요하지만, 생각을 많이 하고 사람을 많이 만나는 것도 중요합니다. 저도 계속 소모되는 곳에 있어서 지치지만 시간이 되면 구루라고 생각하는 사람을 만나려고 노력합니다. 그런 사람을 만나면 대충 10분만 만나도 1년을 살 수 있습니다. 구루는 컨퍼런스에서도 만날 수 있고, 유튜브에서도 만날 수 있지만 저는 주로 커피숍에서 만납니다. 컨퍼런스의 격식차린 대화가 아닌 가벼운 대화 속에서 더 많은 것을 느낄 때가 많습니다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "내가 매기는 나의 가치",
    "permalink": "/the-value-that-i-value/",
    "date":      "2021년 03월 25일",
    "summary":   "유튜브에서 희열의 순간 이라는 프로그램을 봤다. 유시민이 나오는 편이었는데 재미있는 내용들이 꽤 있었다. 가장 인상깊은 부분은 \u0026ldquo;남이 내게 어떤 꼬리표를 달아주는지에 대해 신경을 쓸 게 아니라 내가 인생에서 어떠한 의미를 부여할 것인가가 중요하다\u0026quot;는 부분이었다. 정말 당연한 내용이지만 평소에 쉽게 잊어버리고 마는 내용이다. 자연스럽게 다른 사람들과 비교하며 연봉으로 줄 세우기를 하고, 회사의 네임밸류가 나의 가치인 양 목을 뻣뻣하게 치켜세우기 십상이다. 그러한 어리석은 태도는 심지어 쉽사리 전염이 되기까지 한다.\n그래서 사유의 시간이 중요하다는 생각을 한다. 생각하는 대로 살지 않으면 사는 대로 생각하고 된다고, 사유의 깊이가 충분치 않으니 남들이 쓰는 어리석은 가치 기준의 잣대로 나를 가늠하는 것이다. 그러한 시간을 충분히 보내지 못했음을 반성하고, 또 그를 도와줄 좋은 책을 읽는 일마저 게을리 한 것을 다시 한 번 반성한다.\n",
    "content":   "유튜브에서 희열의 순간 이라는 프로그램을 봤다. 유시민이 나오는 편이었는데 재미있는 내용들이 꽤 있었다. 가장 인상깊은 부분은 \u0026amp;ldquo;남이 내게 어떤 꼬리표를 달아주는지에 대해 신경을 쓸 게 아니라 내가 인생에서 어떠한 의미를 부여할 것인가가 중요하다\u0026amp;quot;는 부분이었다. 정말 당연한 내용이지만 평소에 쉽게 잊어버리고 마는 내용이다. 자연스럽게 다른 사람들과 비교하며 연봉으로 줄 세우기를 하고, 회사의 네임밸류가 나의 가치인 양 목을 뻣뻣하게 치켜세우기 십상이다. 그러한 어리석은 태도는 심지어 쉽사리 전염이 되기까지 한다.\n그래서 사유의 시간이 중요하다는 생각을 한다. 생각하는 대로 살지 않으면 사는 대로 생각하고 된다고, 사유의 깊이가 충분치 않으니 남들이 쓰는 어리석은 가치 기준의 잣대로 나를 가늠하는 것이다. 그러한 시간을 충분히 보내지 못했음을 반성하고, 또 그를 도와줄 좋은 책을 읽는 일마저 게을리 한 것을 다시 한 번 반성한다.\n무의식적으로 나는 이미 무언가가 되었고, 새로운 삶의 방식을 획득하기 어렵다는 생각을 했다. 하지만 생각해보면 나는 언제라도, 심지어 이 글을 쓰고 있는 당장이라도 새로운 삶을 살 수 있다. 그를 가로막고 있는 것은 어제까지의 내가 살아왔던 삶의 관성 뿐이다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "MySQL 이 데이터를 안준다",
    "permalink": "/mysql-convert-tz-timezone/",
    "date":      "2021년 02월 05일",
    "summary":   "팀원 중 한분으로부터 헬프 요청이 왔다. 수정 중인 코드에서 버그가 생겼는데 원인을 도무지 모르겠다는 것이었다.\n상황을 대충 들어보니 아래와 같았다.\n특정 쿼리가 주기적으로 실행되면서 데이터를 가져온다. 그리고 로그에는 몇 건의 데이터를 가져왔는지를 찍고 있는데, 계속해서 쿼리 결과로 가져오는 데이터가 0건이라는 것이다.\n헌데 이상한 것은, 해당 쿼리를 데이터베이스 툴을 통해 직접 때려보면 2건의 데이터가 조회된다.\n즉, 똑같은 쿼리를 서버의 런타임에서 날리면 0건, 데이터베이스 툴에서 직접 날리는 2건이 나오는 상황인 것이다.\n처음 의심한 포인트는 쿼리가 잘못 구성되었고, 그로 인해 ORM 을 통한 object 바인딩에 실패한 것이지 않을까 하는 부분 이었다. 하지만 object 바인딩에 실패하면 에러가 반환되어야 정상이었다. 문제의 코드에는 에러가 없었다.\n",
    "content":   "팀원 중 한분으로부터 헬프 요청이 왔다. 수정 중인 코드에서 버그가 생겼는데 원인을 도무지 모르겠다는 것이었다.\n상황을 대충 들어보니 아래와 같았다.\n특정 쿼리가 주기적으로 실행되면서 데이터를 가져온다. 그리고 로그에는 몇 건의 데이터를 가져왔는지를 찍고 있는데, 계속해서 쿼리 결과로 가져오는 데이터가 0건이라는 것이다.\n헌데 이상한 것은, 해당 쿼리를 데이터베이스 툴을 통해 직접 때려보면 2건의 데이터가 조회된다.\n즉, 똑같은 쿼리를 서버의 런타임에서 날리면 0건, 데이터베이스 툴에서 직접 날리는 2건이 나오는 상황인 것이다.\n처음 의심한 포인트는 쿼리가 잘못 구성되었고, 그로 인해 ORM 을 통한 object 바인딩에 실패한 것이지 않을까 하는 부분 이었다. 하지만 object 바인딩에 실패하면 에러가 반환되어야 정상이었다. 문제의 코드에는 에러가 없었다.\n그 다음에 의심한 포인트는, 실행중인 코드가 실제 코드와 다른 버전일 가능성을 의심해봤다. 팀원분께 여쭤보니 그건 아니었다.\n더 많은 단서를 필요로 했다.\n혹 환경 상의 문제는 아닐까 싶어 일단 코드가 돌고있는 pod 으로 직접 ssh 연결을 붙었다. mysql cli 툴을 깔아서 직접 해당 pod 에서 쿼리를 날려봤는데 정상적으로 2건이 반환되었다. 즉, 환경 상의 문제도 아니었다.\n한참을 이런 저런 시도를 해봤으나 이상한 점은 보이지 않았다. IDE 에 문제의 쿼리를 띄워놓고 자세히 살펴보기 시작했다.\n해당 쿼리가 참조하는 테이블의 컬럼에는 start_time, end_time, timezone 등의 컬럼이 있었다. start_time, end_time 에는 hhMM 포맷의 시간 데이터가 저장되어 있었다. 쿼리는 해당 timezone 을 기준으로 현재 시간이 start_time 과 end_time 사이에 속하는 행들을 조회하는 쿼리였다.\n현재 시간을 timezone 기준으로 변경하는 부분은 아래와 같았다.\n... CONVERT_TZ(NOW(), \u0026amp;#39;GMT\u0026amp;#39;, timezone), ... 일단 CONVERT_TZ 함수 자체가 생소했기 때문에 MySQL 공식 문서를 통해 정의를 확인해보았다.\nCONVERT_TZ(*dt*,*from_tz*,*to_tz*)\nCONVERT_TZ() converts a datetime value dt from the time zone given by from_tz to the time zone given by to_tz and returns the resulting value.\n즉, dt 의 timezone 이 from_tz 라고 가정하고 이를 to_tz 기준으로 변경하는 함수인 것이다. 해당 함수의 사용법에는 딱히 문제가 없어보였다. 하지만 문득 든 생각이, NOW() 에서 반환하는 값이 GMT 가 아니라면 쿼리가 정상적으로 반환해야 할 행들을 반환하지 못할 수도 있다는 생각이 들었다.\n다시 MySQL 문서를 찾아보니 NOW() 함수는 세션의 timezone 설정에 영향을 받는다고 적혀있었다. 백엔드에서 쿼리 중에 난데없이 세션의 timezone 을 변경할 일은 없다. 하지만 데이터베이스로 연결하는 초기 시점에 연결 문자열에서 세션의 timezone 을 설정할 수 있다. 해당 연결문자열을 찾아보니 아니나 다를까 timezone 이 Asia/Seoul 로 설정되어 있었다.\nparseTime=true\u0026amp;amp;charset=utf8\u0026amp;amp;loc=Local\u0026amp;amp;time_zone=%27Asia%2FSeoul%27 잡았다 요놈\n연결문자열에서 timezone 설정을 날리고 코드를 다시 돌려보니 역시 정상적으로 2건의 데이터를 조회하는 것을 확인할 수 있었다.\n",
    "tags":      ["tech","trouble shooting"]
  },
  {
    "title":     "선생님",
    "permalink": "/teacher/",
    "date":      "2020년 10월 18일",
    "summary":   "회사에 입사한 지 채 1년이 안 되었을 무렵의 일이다. 업무를 하면서 지방 어딘가의 교육청 담당자와 통화를 한 일이 있었다. 여차저차 이렇게 저렇게 하자고 이야기를 마무리하고 전화를 끊는데 묘한 여운이 남았다. 이유는 다름이 아닌 호칭 때문이었다. 그는 나를 \u0026lsquo;선생님\u0026rsquo; 이라 지칭했다. 물론 그것이 내가 진짜 교사라는 오해를 하고 있는 것도 아니며, 그의 직장이 교육청이기 때문도 아니다. 그저 나를 지칭할 말이 마땅치 않아 나온 말이었을 것이다. 내가 이웃 아저씨에게 \u0026lsquo;사장님\u0026rsquo;이라 칭했던 것처럼. 차라리 직급이 대리나, 하다못해 주임이라도 됐더래도 편하게 \u0026lsquo;주임님\u0026rsquo;하고 직급으로 부를 수 있었을 텐데, 하필 직급으로 부르기도 어색한 사원이었으니 호칭이 애매하기도 했을 것이다.\n",
    "content":   "회사에 입사한 지 채 1년이 안 되었을 무렵의 일이다. 업무를 하면서 지방 어딘가의 교육청 담당자와 통화를 한 일이 있었다. 여차저차 이렇게 저렇게 하자고 이야기를 마무리하고 전화를 끊는데 묘한 여운이 남았다. 이유는 다름이 아닌 호칭 때문이었다. 그는 나를 \u0026amp;lsquo;선생님\u0026amp;rsquo; 이라 지칭했다. 물론 그것이 내가 진짜 교사라는 오해를 하고 있는 것도 아니며, 그의 직장이 교육청이기 때문도 아니다. 그저 나를 지칭할 말이 마땅치 않아 나온 말이었을 것이다. 내가 이웃 아저씨에게 \u0026amp;lsquo;사장님\u0026amp;rsquo;이라 칭했던 것처럼. 차라리 직급이 대리나, 하다못해 주임이라도 됐더래도 편하게 \u0026amp;lsquo;주임님\u0026amp;rsquo;하고 직급으로 부를 수 있었을 텐데, 하필 직급으로 부르기도 어색한 사원이었으니 호칭이 애매하기도 했을 것이다.\n외국인들을 위한 한국어 교재에는 절대 나오지 않을 한국어 네이티브들만의 어법이 있다. 선생님, 사장님 이런 호칭들이 그 중 하나일 것이다. 단골 식당에서 주문은 고모도, 외숙모도 아닌 이모에게 해야하고, 여자 아이돌에게는 혈연관계가 전혀 없음에도 삼촌 팬이라고 불리는 존재들이 있다. 아내를 지칭할 때는 영어 표현인 wife 를 사용하는게 자연스럽지만 남편을 husband 라 지칭하는 사람은 찾아보기 힘들다.\n우리에겐 무척이나 낯익은 이런 풍경들이 외국인들에게는 다소 재미나게 비치겠구나 하는 생각이 문득 든다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "Share Memory By Communicating",
    "permalink": "/share-memory-by-communicating/",
    "date":      "2020년 10월 09일",
    "summary":   "Go 언어는 동시성 프로그래밍에 매우 특화된 언어다. 이러한 특징은 Go 언어가 탄생하게 된 유래에서도 관련이 있다. 지금은 매우 당연하게 사용되고 있는 멀티 코어 프로세서가 상용으로 세상에 나온지는 사실 생각보다 그리 오래되지 않았다. 2005 년에서 2006 년 사이에 인텔에서 상용 듀얼 코어 프로세서를 출시했다. 그리고 바로 2007년, Google 에서는 이러한 멀티 코어의 이점을 언어에서 native 레벨로 챙길 수 있는 언어로 Go 언어를 개발하기 시작하였다.\n실제로 Go 언어로 멀티스레딩 코드를 만들어보면 이를 체감할 수 있다. 다른 프로그래밍 언어에 비해서 비교적 쉽게 동시성을 다룰 수 있도록 지원하고 있다. Java 의 경우처럼 Runnable 인터페이스를 구현하거나 Thread 를 상속받아서 run 메소드를 작성할 필요없이, 별도의 스레드로 실행할 함수 앞에 go 라는 키워드만 붙여주면 된다.\n",
    "content":   "Go 언어는 동시성 프로그래밍에 매우 특화된 언어다. 이러한 특징은 Go 언어가 탄생하게 된 유래에서도 관련이 있다. 지금은 매우 당연하게 사용되고 있는 멀티 코어 프로세서가 상용으로 세상에 나온지는 사실 생각보다 그리 오래되지 않았다. 2005 년에서 2006 년 사이에 인텔에서 상용 듀얼 코어 프로세서를 출시했다. 그리고 바로 2007년, Google 에서는 이러한 멀티 코어의 이점을 언어에서 native 레벨로 챙길 수 있는 언어로 Go 언어를 개발하기 시작하였다.\n실제로 Go 언어로 멀티스레딩 코드를 만들어보면 이를 체감할 수 있다. 다른 프로그래밍 언어에 비해서 비교적 쉽게 동시성을 다룰 수 있도록 지원하고 있다. Java 의 경우처럼 Runnable 인터페이스를 구현하거나 Thread 를 상속받아서 run 메소드를 작성할 필요없이, 별도의 스레드로 실행할 함수 앞에 go 라는 키워드만 붙여주면 된다.\n이러한 문법적 편리성은 여기서 그치지 않는다. 각 스레드들끼리의 데이터 공유 수단으로 channel 이라는 빌트인 타입을 만들어 제공하고 있다. channel 은 queue 와 그 쓰임새가 매우 유사하다. enqueue / dequeue 기능이 있고 선입선출의 순서를 가진다. 그럼 Go 언에서 이 channel 이란 타입을 빌트인으로 만들어서 제공한 이유는 뭘까? 그냥 표준 패키지에서 구현해도 되는 자료구조를 왜 언어의 native 기능으로 추가했을까?\nGo 언어에서 channel 개념을 학습하다보면 꼭 접하게 되는 문장이 있다.\nDo not communicate by sharing memory; instead, share memory by communicating\n언뜻보면 금방 이해가 안가는 문장이다. 하지만 이해하고 나면 Go 언어에서 동시성 문제를 얼마나 중요하게 다뤘는지에 대해 알 수 있다.\n간단한 샘플 코드를 짜보자.\nvar counter = 0 func main() { for i := 0; i \u0026amp;lt; 100; i++ { go increaseCounter() } fmt.Println(counter) } func increaseCounter() { counter += 1 } 간단한 내용의 코드다. counter 변수를 증가시키는 로직을 수행하는 increaseConter 라는 함수가 있고 메인 스레드에서는 이 함수를 각각 별도의 스레드로 100번 실행시킨 후에 counter 변수의 값을 실행한다. 직관적으로는 당연히 counter 의 값이 100이 될 것 같지만 사실 그렇지 않다. 내 맥북을 기준으로 결과값은 80 후반대에서 90 초반대의 값이 출력된다. 하지만 만약 이 코드를 싱글코어 머신에서 실행하면 값은 의도한 대로 100이 나올 것이다.\n이렇게 되는 이유는, counter 라는 공유 자원을 각각의 스레드에서 동시에 접근하게 되기 때문이다. 듀얼 코어 이상의 머신에서는 counter 를 증가시키는 코드가 동시에 여러 스레드에서 실행되는 케이스가 발생하고, 이 때문에 counter 의 값이 오롯이 100 이 안되는 것이다.\n멀티스레드 프로그래밍을 하면서 가장 많이 하게 되는 실수 중 하나다. 각 스레드들간 공유하고 있는 자원을 적절하게 핸들링하지 못하게 되는 케이스다. 이런 문제를 해결하는 가장 간단한 방법은 Lock 을 이용하는 것이다. 공유자원에 접근하기 전에 먼저 lock 을 걸고 자원 사용이 끝나면 다시 unlock 을 호출하는 것이다. Go 언어에서도 Mutex 라는 구조체를 통해 이러한 lock 을 이용한 접근을 지원하고 있기는 하다.\n사실 이러한 방법은 Go 언어에서 지양해야 하는 접근 중 하나이다. 위의 문장에서도 Do not communicate by sharing memory 라고 이야기하고 있다. 본 예제 코드에서는 counter 라는 메모리 상의 자원을 스레드들간에 공유한 것이기 때문이다.\n이제 channel 을 이용해서 다시 짜보자.\nfunc main() { ch := make(chan int) go receiver(ch) sender(ch) } func …",
    "tags":      ["tech"]
  },
  {
    "title":     "내 나이",
    "permalink": "/age/",
    "date":      "2020년 09월 27일",
    "summary":   "흔히들 \u0026ldquo;쌍팔년도\u0026quot;를 1988년을 칭하는 표현으로 알고 있는 경우가 많다. 하지만 이는 사실과 다르다. \u0026ldquo;쌍팔년도\u0026quot;는 사실 단기 4288년, 즉 서기 1955년을 이르는 말이다. 이는 서로 다른 기년법에서 비롯되는 오해인 셈이다. 흔히 우리가 사용하고 있는 서기는 예수가 탄생했을 것을 추정한 해를 기원으로 하고, 단기는 단군이 고조선을 개국했다고 전해지는 해를 기원으로 하는 기년법이다. 이렇듯 우리가 자연스럽게 헤아리던 년도가 실은 특정 시점이 일어난 시기를 기점으로 세어지기 시작한 것이라는 사실을 생각하다보니 나이라는 것도 이러한 셈법의 연장선 상에 있는 것이 아닌가 하는 생각을 하게 된다. 우리가 태어난 해를 기점으로 세어지는, 실은 어찌보면 기년법의 일종인 것이다.\n",
    "content":   "흔히들 \u0026amp;ldquo;쌍팔년도\u0026amp;quot;를 1988년을 칭하는 표현으로 알고 있는 경우가 많다. 하지만 이는 사실과 다르다. \u0026amp;ldquo;쌍팔년도\u0026amp;quot;는 사실 단기 4288년, 즉 서기 1955년을 이르는 말이다. 이는 서로 다른 기년법에서 비롯되는 오해인 셈이다. 흔히 우리가 사용하고 있는 서기는 예수가 탄생했을 것을 추정한 해를 기원으로 하고, 단기는 단군이 고조선을 개국했다고 전해지는 해를 기원으로 하는 기년법이다. 이렇듯 우리가 자연스럽게 헤아리던 년도가 실은 특정 시점이 일어난 시기를 기점으로 세어지기 시작한 것이라는 사실을 생각하다보니 나이라는 것도 이러한 셈법의 연장선 상에 있는 것이 아닌가 하는 생각을 하게 된다. 우리가 태어난 해를 기점으로 세어지는, 실은 어찌보면 기년법의 일종인 것이다.\n서기 2020년이라는 숫자 외에 다른 숫자를 더 붙여볼 수 있을 것 같다. 예를 들어, 올해는 인생 34년차이자, 아버지 1년차, 운전경력 4년차에 개발자 8년차이다. 대개 경력의 연차를 가지고 역량의 농익은 정도를 대략적으로 추정하곤 한다. 물론 이것이 절대적인 척도가 될 수는 없다. 하지만 아직 경험이 미천한 주니어인지, 혹은 어느정도 농익은 경륜을 기대할 수 있는 시니어인지를 우리는 대개 경험의 역사의 길고 짧음에 빗대어 추정하곤 한다. 채용 공고에 항상 사족처럼 붙어있는 \u0026amp;ldquo;관련 분야 n년 이상\u0026amp;rdquo; 이라는 조건들이 이러한 경향성을 뒷받침한다.\n생각이 여기까지 이어지면서 나는 인생 34년차 걸맞게 충분히 농익었는지를 생각해본다. 이 연차에 어울리는 역량은 어떤 것일까. 나라는 개체에 대해 충분히 파악하고 있는지, 또 충분한 정도의 지식과 상식과 경험들을 쌓아두었는지, 앞으로의 인생에 있어서 얼마만큼의 비전과 확신을 가지고 있는지, 이런 것들을 생각해본다. 다소간의 반성과, 또 다소간의 위안 같은 것들을 책상 위에 흩뜨려 놓고 나는 나를 돌아본다.\n그냥 살아지는 것만이 생生이 아님을 다시금 생각한다. 한낯 김치조차도 익힌 시간만큼의 깊은 맛을 낸다. 이제 막 맛을 내기 시작하는 올해는 서기 2020년이자, 단기 4353년, 그리고 생生기 34년이다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "20세기 문화 이미지",
    "permalink": "/culture-image-of-20-century/",
    "date":      "2020년 05월 16일",
    "summary":   "근래에 “20세기 문화이미지” 라는 책을 짬짬이 읽고 있다. 우연히 들른 헌책방에서 무려 2천원을 내고 업어온 책이다. 지금은 고인이 되신 이성욱 작가님이 쓰신 책으로, 서문에서는 그를 “문화기술자”라고 칭하고 있다. 이 책에 담긴 단편의 글들도 그 호칭의 연장선 상에 놓인 글들이다. 대부분 90년대 후반에 쓰여진 글들을 모아서 2004년에 책으로 묶어냈는데, 주로 당시의 생활, 문화, 세태 들을 작가의 관점에서 재미있게 풀어놓은 글들이다. 이 책이 더욱 재미있어지는 부분은 이 책을 읽는 지금이 2020년 이라는 사실이다. 한 세대 이전의 사회에 대해 당시의 작가가 이렇게 저렇게 기술해놓은 글들을 20여년이 지난 지금에 읽으니 이게 또 새로운 맛이 안날 수가 없는 것이다.\n",
    "content":   "근래에 “20세기 문화이미지” 라는 책을 짬짬이 읽고 있다. 우연히 들른 헌책방에서 무려 2천원을 내고 업어온 책이다. 지금은 고인이 되신 이성욱 작가님이 쓰신 책으로, 서문에서는 그를 “문화기술자”라고 칭하고 있다. 이 책에 담긴 단편의 글들도 그 호칭의 연장선 상에 놓인 글들이다. 대부분 90년대 후반에 쓰여진 글들을 모아서 2004년에 책으로 묶어냈는데, 주로 당시의 생활, 문화, 세태 들을 작가의 관점에서 재미있게 풀어놓은 글들이다. 이 책이 더욱 재미있어지는 부분은 이 책을 읽는 지금이 2020년 이라는 사실이다. 한 세대 이전의 사회에 대해 당시의 작가가 이렇게 저렇게 기술해놓은 글들을 20여년이 지난 지금에 읽으니 이게 또 새로운 맛이 안날 수가 없는 것이다.\n이렇게 재미있는 책을 만난 것도 꽤나 오랜만이라 그냥 흘려보내기 아쉬워 몇몇 부분을 발췌하여 남겨본다.\n자본주의 사회는 \u0026amp;ldquo;연출하는 자아\u0026amp;quot;를 대량생산한다는 진단이 딱 맞아떨어진다는 현장이다.\n\u0026amp;hellip; 공주병의 본질은 자아도취, 바꿔말해 성찰없는, 혹은 객관적인 것에 대한 반성의 부재이다. 자아 그리고 사회에 대한 성찰 등이 결여된 존재는 불가피하게 모든 관심과 이해를 자신에게로 돌린다. 처음과 끝이, 원인과 결과가 \u0026amp;ldquo;자아\u0026amp;quot;에서 출발하고 매듭지어진다. 그렇기에 자신과 다른 사람 및 사회와 맺어지는 관계의 다양성에 대한 고려는 대단히 부박해진다.\n\u0026amp;hellip; 오늘 계속 이야기하는 공주병 증후군의 병인은 심각한 사회적 문제이기 때문이다. 그 병인은 앞에서 말했다시피 소비에 대한 신경질적이고 강박적인 증상이다. 그래서 말하자면 공주병은 소비증후군이 진행된 2차 증후라는 것이다.\n“연출하는 자아” 라는 표현을 들었을 때 처음으로 떠오르는 것은 인스타그램을 위시한 SNS 들이다. 시대가 흐르고 자아를 연출하기가 더 쉬워짐에 따라 우리는 병세가 더 심해졌는지도 모르겠다.\n“뽕짝의 리얼리즘”이라는 것이 바로 그런 것이다. 공부 높은 30대 음악이론가가 \u0026amp;ldquo;뽕짝\u0026amp;quot;을 형식미학적으로 난도질할 수는 있다. 그러나 그에게 여즉 부산 국제 시장의 장사치로 남아있는 서북 노인네가 왜 \u0026amp;ldquo;굳세어라 금순아\u0026amp;quot;에 일순 허물어지는지에 대해서는 요령부득이다. 그 까닭이야 간단한 것, 새파란 젊은 나이로는 그 \u0026amp;ldquo;비속한\u0026amp;rdquo; 노래 하나에 단단히 결합되어 있는, 요컨데 예술보다 더 높거나 넓은 일은 살 생애의 파란 많은 삶이 리얼리티를 파고들어 갈 수 없기 때문이다. \u0026amp;ldquo;뽕짝\u0026amp;quot;에 리얼리즘이 연결되는 게, 다름 아니라 그런 노래가 우리 현대사의 한 곳을 고유한 자기 자리로 삼고 있기 때문이라면, \u0026amp;ldquo;이발소 그림\u0026amp;rdquo; 역시 바로 그런 것이었다.\n근대의 징표인 대도시의 가속화는 시계의 개인화를 낳았다. 마을 중앙광장에 높이 세워진 큰 시계를 통해 시간을 확인하던 근대 이전의 작은 공동체의 방식은 거대한 혼란을 특징으로 하는 대도시에서는 더 이상 가능하지 않았다. 그 혼란을 질서로 바꾸는 데에 필요한 것이 마을 시계가 보이지 않더라도 시각을 확인할 수 있는 개인용 시계였다. 회중시계의 출현은 바로 그런 사회적 배경을 통해서였다. 그런데 그때 회중시계의 의미는 단지 시각 확인 장치에 머무르지 않았다. 시간을 관리, 통제한다는 것은 가장 첨단의 근대인으로 여겨질 수 있었기에, 요컨데 회중 시계는 특정한 사회적 지위를 상징하는 기호로 작용하기도 했다. 그런 버릇이 우리에게도 이어졌다. 개화기, 세월의 대세가 개화로 물꼬를 틀자 너도 나도 개화꾼임을 자처하고 나섰다. 그때 단발, 양복, 회중시계 등속은 개화인임을 증거하는 상징물이었다. 생각과 가치관의 변화는 요지부동이면서 겉으로만 개화에 발을 담근 자 혹은 개화를 무슨 유행처럼 생각하는 자들은 그때 ‘얼개화꾼’ (얼치기 개화꾼)이라 불렀는데, 그런 자일수록 회중시계를 애용했다. 회중시계가 자신이 개화꾼임을 보장해 주는 알리바이라고 생각했던 것이다. 얼개화꾼에게 시계는 시각확인 장치의 사용가치보다 상징가치의 지표일 뿐이 …",
    "tags":      ["daily"]
  },
  {
    "title":     "8년 간의 개발자 생활 회고 (3)",
    "permalink": "/look-back-on-8-years-3/",
    "date":      "2020년 05월 16일",
    "summary":   " 8년 간의 개발자 생활 회고 (1) 8년 간의 개발자 생활 회고 (2) 8년 간의 개발자 생활 회고 (3) SK C\u0026amp;C (2018. 7 ~ ) 새로운 시작 첫 입사날 내게 비친 풍경은 자리가 군데군데 비어있는 사무실이었다. 나중에 알고보니 여름휴가 시즌이라 길게 자리를 비우신 분들이 많았고, 내가 소속된 파트의 파트리더도 휴가중이었다. 그래서 처음 몇 일은 노트북을 지급받고 회사 시스템과 분위기를 익히는 데 썼다.\n휴가를 떠났던 파트리더님이 돌아와 현재 우리 파트에 대한 설명을 들었다. 우리가 가지고 있는 기술 스택과 목표로 하는 일 등에 대해 자세히 설명을 들었다. 정말 생소하기 짝이 없는 아키텍처였다. 관계형 데이터베이스가 여기선 단순한 메타성 데이터 저장소 용으로 사용되고 있었고, 대신 InfluxDB 라는 시계열 데이터베이스가 굉장히 헤비하게 사용되고 있었다. 또한 TICK 스택이라 불리는 솔루션들과 더불어 Kafka 나 Kubernetes 같은 써본 적 없는 기술들이 즐비하게 사용되고 있었다. 나름대로 리서치도 하고 주변 동료들에게 물으면서 전체 인프라 스택을 머리속에 정리해나갔다. 아무래도 생소하기는 했다. 하지만 앞으로 그걸 다루는 게 내 일이었고 경력직 개발자로서 나는 빠른 시간 내에 팀에 전력이 되어야 했다.\n",
    "content":   " 8년 간의 개발자 생활 회고 (1) 8년 간의 개발자 생활 회고 (2) 8년 간의 개발자 생활 회고 (3) SK C\u0026amp;amp;C (2018. 7 ~ ) 새로운 시작 첫 입사날 내게 비친 풍경은 자리가 군데군데 비어있는 사무실이었다. 나중에 알고보니 여름휴가 시즌이라 길게 자리를 비우신 분들이 많았고, 내가 소속된 파트의 파트리더도 휴가중이었다. 그래서 처음 몇 일은 노트북을 지급받고 회사 시스템과 분위기를 익히는 데 썼다.\n휴가를 떠났던 파트리더님이 돌아와 현재 우리 파트에 대한 설명을 들었다. 우리가 가지고 있는 기술 스택과 목표로 하는 일 등에 대해 자세히 설명을 들었다. 정말 생소하기 짝이 없는 아키텍처였다. 관계형 데이터베이스가 여기선 단순한 메타성 데이터 저장소 용으로 사용되고 있었고, 대신 InfluxDB 라는 시계열 데이터베이스가 굉장히 헤비하게 사용되고 있었다. 또한 TICK 스택이라 불리는 솔루션들과 더불어 Kafka 나 Kubernetes 같은 써본 적 없는 기술들이 즐비하게 사용되고 있었다. 나름대로 리서치도 하고 주변 동료들에게 물으면서 전체 인프라 스택을 머리속에 정리해나갔다. 아무래도 생소하기는 했다. 하지만 앞으로 그걸 다루는 게 내 일이었고 경력직 개발자로서 나는 빠른 시간 내에 팀에 전력이 되어야 했다.\n사실 새로운 스택을 익히는 데에 있어서 어려움만 있었던 것은 아니다. 오히려 어려움보다 기술적인 흥미가 더 컸다. 사실 일반적인 웹 아키텍처는 인터넷을 좀만 뒤지면 여러 레퍼런스를 찾기 어렵지 않다. 하지만 시계열 데이터를 다루는 이런 도메인에 대한 아키텍처는 레퍼런스를 찾기 어려운 편이다. 특히 Kubernetes 가 이제 막 container orchestrator 의 de-facto 가 되가던 시점이었기 때문에 한 번 배워야겠다는 생각을 하고 있던 차 이기도 했다. 그리고 역시 이런 기술 스터디는 필드에서 직접 맨땅에 헤딩해가면서 배우는 게 제일 효과적이다. 기본적으로 새로운 기술을 접하는 걸 좋아했기 때문에 초반 소프트랜딩 과정이 꽤 즐거웠다.\n새로운 언어들 새로운 언어를 사용하는 기회가 되기도 했다. 특히 취미로만 사용해오던 Go 언어를 현업에서 사용할 수 있게 되었다. 해결하고자 했던 문제가 Go 언어의 동시성 기능이 필요한 부분이기도 했고, Java 로 짜기엔 다소 무거웠다. 이 팀에서 일하면서 Go 언어를 정말 다양하게 사용했는데, 배치성 코드, 간단한 API 서버, 메트릭 수집 모듈, 그리고 Agent 들을 모두 Go 언어로 작성하였다.\nTypescript 도 이때 처음 다루게 되었다. 간단한 백 오피스를 만들어야 해서 처음에는 Javascript 를 이용해서 백엔드는 Koa, 프론트엔드는 React 로 만들었다. 하지만 점차 기능이 이것저것 붙기 시작하면서 언어적인 한계에 자주 부딪혔고 그에 대한 대안으로 Typescript 를 고려하기 시작했다. 기본적인 문법을 익히고 조그만 토이 프로젝트에 적용해봤다. 그 결과 이건 꼭 도입해야 하는 물건이라는 생각이 들었다. 새로운 언어를 배워야 한다는 러닝커브를 제외하면 도입하지 않을 이유가 없었다. 곧바로 백엔드와 프론트엔드 코드를 모두 Typescript 로 포팅하였고, 그 결과 더 안정적이고 유지보수하기 좋은 코드들이 나왔다.\nKoa 의 대안으로 NestJS 를 살펴보기도 했다. 이전까지는 node.js 를 백엔드 서버로 사용하는 경우 express 가 대세였다. npm trends 를 보면 지금도 활발하게 사용되고 있긴 하다. 하지만 개인적으로 express 웹 프레임워크 라기 보다는 라이브러리 느낌이 강하기 때문에 규모가 있는 코드를 express 로 작성하기에는 특별한 이점이 없는 것 처럼 느껴졌다. 내 경우에도 express 대신 koa 를 많이 사용하긴 했지만 koa 역시 한계가 명확하고 활성도 조차 높지 않은 프로젝트였다. 그러던 차에 Typescript 를 도입하면서 알게 된 프레임워크가 NestJS 였다. express 나 koa 에 비교하여 여러가지로 next-generation framework 라는 인 …",
    "tags":      ["tech","career"]
  },
  {
    "title":     "8년 간의 개발자 생활 회고 (2)",
    "permalink": "/look-back-on-8-years-2/",
    "date":      "2020년 05월 11일",
    "summary":   " 8년 간의 개발자 생활 회고 (1) 8년 간의 개발자 생활 회고 (2) 8년 간의 개발자 생활 회고 (3) RIDI (2016. 6 ~ 2018. 3) 신입과 경력의 차이 두 번째 회사에서의 생활은 내게 굉장히 큰 변화였다. 일단 맥북을 쓰게 되었다. 그 전까지는 윈도우 환경에서 개발을 했고 맥북은 써본 일이 없었다. 그래서 일단 맥 사용법을 익히는 일부터 해야 했다. 뿐만 아니라 모든 것이 새로웠다. 첫 회사에서는 SVN 으로 소스 관리를 해왔기 때문에 Git 을 처음 사용해보게 되었고, 언어도 생경하기 짝이없는 PHP 와 Javascript 를 사용했다. 특히나 PHP 는 아예 처음이었기 때문에 문법과 Laravel 프레임워크, Doctrine ORM 사용법을 익히는 데에 일주일 정도의 시간을 사용했다. 게다가 Asana 라는 생경한 툴로 태스크 관리를 했고 슬랙도 여기서 처음 써보게 되었다.\n",
    "content":   " 8년 간의 개발자 생활 회고 (1) 8년 간의 개발자 생활 회고 (2) 8년 간의 개발자 생활 회고 (3) RIDI (2016. 6 ~ 2018. 3) 신입과 경력의 차이 두 번째 회사에서의 생활은 내게 굉장히 큰 변화였다. 일단 맥북을 쓰게 되었다. 그 전까지는 윈도우 환경에서 개발을 했고 맥북은 써본 일이 없었다. 그래서 일단 맥 사용법을 익히는 일부터 해야 했다. 뿐만 아니라 모든 것이 새로웠다. 첫 회사에서는 SVN 으로 소스 관리를 해왔기 때문에 Git 을 처음 사용해보게 되었고, 언어도 생경하기 짝이없는 PHP 와 Javascript 를 사용했다. 특히나 PHP 는 아예 처음이었기 때문에 문법과 Laravel 프레임워크, Doctrine ORM 사용법을 익히는 데에 일주일 정도의 시간을 사용했다. 게다가 Asana 라는 생경한 툴로 태스크 관리를 했고 슬랙도 여기서 처음 써보게 되었다.\n하지만 무엇보다 큰 변화는 첫 경력직으로서의 직장이라는 부분이었다. 신입과 경력의 차이는 크다. 전 직장에서는 처음부터 신입으로 입사했기 때문에 모르는 것을 모른다고 말하고 모두의 도움을 부담없이 받으며 소프트랜딩 할 수 있었다. 하지만 경력으로 들어온 이상 이젠 모르는 것을 모른다고 하기가 힘들어졌다. 모르는 것도 어떻게든 답을 내야하는 연차였다.\n새로운 언어와 프레임워크를 익히고 백오피스 위주로 소스코드에 손을 대고 있을 쯔음이었다. 입사한지 약 한달 정도가 지난 시점으로 기억한다. 팀장님이 나와의 면담을 요청했다. 내용인 즉 회사에서 신규 서비스를 계획 중이고 그를 위한 새로운 팀을 빌딩중인데 여기에 참여해 주었으면 한다는 내용이었다. 나는 고민할 것도 없이 수락하였다. 일단 이미 만들어져있는 시스템을 조금씩 뜯어고치는 것 보다는 새로운 시스템을 맨땅에서부터 쌓아올리면서 배우는 것이 더 많을 거라고 생각했고, 그에 따른 기술 셋을 온전히 팀 멤버들끼리 선택할 수 있다는 것도 장점으로 다가왔다. 그렇게 나는 리디스토리 개발팀으로 이동을 하게 되었다.\n신규 서비스 개발 팀 멤버는 딱 2명이었다. 추가 인원을 채용 중에 있긴 했지만 이제 막 이력서를 받는 단계였기 때문에 일단 기존 개발팀들에서 이동한 인원으로 팀을 꾸렸다. 기획이 전부 픽스되지도 않은 시기였지만 빠른 시장 선점을 필요로 하는 상황 탓에 스케쥴은 녹록치 않았다. 팀 빌딩이 8월 정도였는데 그해 말까지 Android, iOS 를 대상으로 앱을 출시해야 했다. 덕분에 우리는 픽스되지 않은 기획을 추측해가며 백엔드부터 쌓기 시작했다. 팀 인원이 둘 밖에 없었기 때문에 각자 담당 업무를 나누고 말고 할 것도 없이 서로가 할 수 있는 최대치를 했다.\n백엔드 언어 및 프레임워크로는 Python + Django, Ruby on Rails, Java + Spring Boot 이 세 가지 선택지를 놓고 일주일 정도를 고민해였다. Ruby on Rails 는 개발자 수급 문제를 제쳐놓더라도 해당 프레임워크의 에코시스템 자체가 다른 프레임워크 대비 활성화되지 않아서 오래 보지않았다. 개인적으로는 아무래도 Java + Spring 쪽이 욕심이 나기는 했다. Spring 경험을 현업에서 해보고 싶기도 했고, Spring 경험이 있는 개발자를 빠르게 수급할 수 있으리라는 생각이었다. 하지만 결국 최종 선택지는 Python + Django 가 되었다. 세 가지 선택지 모두 경험이 없는 상태에서 그나마 Python + Django 의 러닝커브가 적다고 판단되었던 것이 첫 번째 이유고, Admin 툴이 기본으로 제공된다는 것이 두 번째 이유였다. 시간과 인력이 적은 상태에서 별도의 백오피스를 만들기 보다는 Django admin 을 최대한 이용하는 것이 바람직하다는 판단이었다. 이 판단은 지금에서도 유효하다고 생각한다.\n인프라는 AWS 에서 제공하는 서비스를 적극적으로 이용했다. EC2, RDS, Elasticache, CloudFront, S3, CloudWatch 정도를 주로 썼었던 것 같다. 다만 일반적인 웹 서비스에서 사용되는 인프라에 대한 지식이 약했던 나 대신 팀장님이 대부 …",
    "tags":      ["tech","career"]
  },
  {
    "title":     "8년 간의 개발자 생활 회고 (1)",
    "permalink": "/look-back-on-8-years-1/",
    "date":      "2020년 05월 10일",
    "summary":   " 8년 간의 개발자 생활 회고 (1) 8년 간의 개발자 생활 회고 (2) 8년 간의 개발자 생활 회고 (3) 개발자의 길로 들어선 것이 어느덧 8년이다. 처음 직장 생활을 시작하던 20대 후반의 나와 지금의 내가 얼마나 달라졌는지는 사실 잘 모르겠다. 그래서 지난 8년 간의 기록을 여행기 쓰듯이 써보려고 한다. 다른 분들이 많이들 하시는 신년맞이 지난해 회고를 난 한 번도 한 적이 없으니, 8년치 회고를 한꺼번에 하는 셈이다.\nIgloosec (2013. 1 ~ 2016. 6) 신입 개발자 처음 개발자로써 사회 생활을 시작한 것은 2013년 1월 이었다. 첫 회사는 이글루시큐리티였고 보안 솔루션들을 만드는 회사였다. 주력 솔루션은 통합보안관제솔루션(이하 ESM) 이었는데, 운 좋게 이 캐시카우를 만드는 팀에 신입으로 입사를 하게 되었다. 사실 캐시카우인 만큼 레거시 코드도 많고 순수 개발 외 고객사 지원 업무도 많아 편한 포지션이라고 하기는 어렵다. 그럼에도 불구하고 운이 좋다고 표현한 것은 주니어 엔지니어 시기에 그런 하드한 환경에서 쌓은 경험치들이 나중까지 도움이 많이 되었기 때문이다. 물론 좋은 선배들도 많이 만나게 되었다.\n",
    "content":   " 8년 간의 개발자 생활 회고 (1) 8년 간의 개발자 생활 회고 (2) 8년 간의 개발자 생활 회고 (3) 개발자의 길로 들어선 것이 어느덧 8년이다. 처음 직장 생활을 시작하던 20대 후반의 나와 지금의 내가 얼마나 달라졌는지는 사실 잘 모르겠다. 그래서 지난 8년 간의 기록을 여행기 쓰듯이 써보려고 한다. 다른 분들이 많이들 하시는 신년맞이 지난해 회고를 난 한 번도 한 적이 없으니, 8년치 회고를 한꺼번에 하는 셈이다.\nIgloosec (2013. 1 ~ 2016. 6) 신입 개발자 처음 개발자로써 사회 생활을 시작한 것은 2013년 1월 이었다. 첫 회사는 이글루시큐리티였고 보안 솔루션들을 만드는 회사였다. 주력 솔루션은 통합보안관제솔루션(이하 ESM) 이었는데, 운 좋게 이 캐시카우를 만드는 팀에 신입으로 입사를 하게 되었다. 사실 캐시카우인 만큼 레거시 코드도 많고 순수 개발 외 고객사 지원 업무도 많아 편한 포지션이라고 하기는 어렵다. 그럼에도 불구하고 운이 좋다고 표현한 것은 주니어 엔지니어 시기에 그런 하드한 환경에서 쌓은 경험치들이 나중까지 도움이 많이 되었기 때문이다. 물론 좋은 선배들도 많이 만나게 되었다.\n2013년 1월 2일, 내 첫 출근일이었다. 아직도 그 풍경이 생생히 기억난다. 면접 때 입었던 불편하기 짝이 없는 정장을 입고 사수의 뒤를 쫄레쫄레 따라 자리에 앉았다. 썰렁해보이는 책상 위에는 두꺼운 책을 한 권 있었다. ESM 매뉴얼이었다. ESM 을 구매한 고객사에게 나가는 용 이었는데 두께가 왠만한 백과사전 만큼이나 두꺼웠다. 내 첫 업무는 이 책을 참고하여 ESM 의 대략적인 기능을 익히는 것이었다.\n그 날 오후 쯤에는 두 번째 임무가 주어졌다. 서버실에 있는 테스트 용 서버에 CentOS 와 Oracle, 그리고 ESM 을 설치하는 것이 그것이었다. 당시 쌩 신입이었던 내게 이 일은 꽤 어렵게 느껴졌다. 일단 리눅스 환경 자체가 익숙치 않았고, Oracle 설치도 툭하면 알 수 없는 오류가 발생하여 롤백을 몇 번이나 반복해야 했다. ESM 설치도 쉽지 않았다. 단일 프로세스 형태가 아니라 여러 모듈들이 함께 설치되는 구조였고, 각 모듈간의 정상적인 연결을 위해 꽤 복잡한 설정을 거쳐야 했다. 이 일에 약 1주일 정도를 매달렸다. 이후에는 사수로부터 ESM 의 아키텍처와 전반적인 흐름에 대해 면대면으로 교육을 받았다. Standalone 구조는 그런대로 이해를 금방 했는데, Master - Slave 형태의 분산 구조에서 꽤 해맸던 기억이 있다.\n위의 과제들을 모두 끝낸 후에야 처음으로 소스 코드를 마주했다. 팀에서 내가 소속된 파트는 미들웨어 파트였고 주 언어는 Java 였다. 당시 기준으로도 8년 이상 유지되던 소스 코드라 레거시의 양이 어마무시했다. 그리고 무엇보다 Spring 같은 프레임워크를 사용하지 않은 쌩 Java 코드 였다. 이 미들웨어의 역할은 실시간으로 유입되는 데이터들을 기반으로 time window 단위 통계 관리, 설정 관리, 분산 노드 간 데이터 동기화 등의 기능을 담당하고 있었다. 신입 입장에서 곧장 파악하기에는 기능도 코드도 너무 복잡했다. 때문에 일단은 전체 구조만 숙지한 상태로 특정 기능에 대한 이슈가 발생했을 때 마다 딥하게 파는 방식으로 배웠다.\n트러블 슈팅 단련기 앞서 이야기했듯 당시 회사의 ESM 솔루션은 꽤 많은 고객사들이 사용하고 있었다. 그 수가 물경 세 자리에 달했다. 당연히 연구소에서 직접 이 많은 고객사와 커뮤니케이션하지는 않았고, 설치 및 유지보수, 장애 조치 등을 담당하는 엔지니어 조직이 따로 있었다. 자주 발생하거나 단순한 장애의 경우에는 엔지니어 조직 내부에 매뉴얼화가 되어 있었기 때문에 자체 대응이 가능했다. 하지만 그렇지 못한 이슈 들은 연구소로 많이 토스되었다. 말하자면, 연구소까지 넘어온 이슈들은 대부분 이전에 발생한 적이 없고 원인을 파악하기 어려운 이슈들이었다. 고객사가 워낙에 많아 이런 식으로 연구소가 대응해야 하는 이슈가 많게는 일주일에 두세 건씩 발생했다.\n오랜기간 사용되면서 충분히 안정화된 솔루션임에도 …",
    "tags":      ["tech","career"]
  },
  {
    "title":     "오픈소스 프로젝트에 코드 기여한 이야기",
    "permalink": "/contribute-code-into-telegraf/",
    "date":      "2019년 08월 22일",
    "summary":   "그동안 개발자로 일하면서 오픈소스의 도움을 많이 받아왔다. 아닌게 아니라 당장에 Github이 없으면 나는 지금 생산성의 반의 반도 못 내고 있을 것이다. 하지만 부끄럽게도 작년에야 처음으로 오픈소스에 기여를 하게 되었다. 사실 기여를 하고자 하는 생각은 아주 오래전부터 가지고 있었다. 하지만 기여할 프로젝트를 고르는 문제부터 시작해서, 코드 베이스를 파악하고, 버그의 원인을 찾고, 메인테이너와 소통하고 하는 일들이 너무 어렵게 느껴져 시도하지 못했다고 하는게 맞을 것 같다. 그러던 차에 우연찮게 처음으로 오픈소스 프로젝트에 기여하게 되었고 그 과정이 생각보다 어렵지 않다는 것을 알게 되었다.\n",
    "content":   "그동안 개발자로 일하면서 오픈소스의 도움을 많이 받아왔다. 아닌게 아니라 당장에 Github이 없으면 나는 지금 생산성의 반의 반도 못 내고 있을 것이다. 하지만 부끄럽게도 작년에야 처음으로 오픈소스에 기여를 하게 되었다. 사실 기여를 하고자 하는 생각은 아주 오래전부터 가지고 있었다. 하지만 기여할 프로젝트를 고르는 문제부터 시작해서, 코드 베이스를 파악하고, 버그의 원인을 찾고, 메인테이너와 소통하고 하는 일들이 너무 어렵게 느껴져 시도하지 못했다고 하는게 맞을 것 같다. 그러던 차에 우연찮게 처음으로 오픈소스 프로젝트에 기여하게 되었고 그 과정이 생각보다 어렵지 않다는 것을 알게 되었다.\n내가 참여한 오픈소스는 Telegraf 였다. 뭐 이름이 생소하게 들릴 수 있지만 그래도 모니터링 쪽 동네에서는 나름 방귀 좀 뀌는 프로젝트다. 일반적으로 모니터링이라고 하면 서버 모니터링 (IaaS 레벨의 모니터링)과 애플리케이션 모니터링(APM) 정도를 많이 떠올릴 텐데, 이 Telegraf 는 서버 모니터링 쪽에서 활약하고 있는 메트릭 수집 에이전트다.\n모니터링은 일반적으로 수집 -\u0026amp;gt; 저장 -\u0026amp;gt; 분석 -\u0026amp;gt; 시각화 정도의 플로우를 타게 된다. (중간에 순서가 조금 바뀌는 경우는 있다.) 여기서 Telegraf 는 수집단을 맡고 있다. Elastic stack 의 metricbeat와 포지셔닝이 비슷하다고 할 수 있을 것이다.\n말 나온 김에 모니터링 영역에서 Elastic 스택과 TICK 스택을 비교해보자면, Beat -\u0026amp;gt; Logstash -\u0026amp;gt; Elasticsearch -\u0026amp;gt; Kibana 의 플로우를 가지고 있는 Elastic 스택은 기본적으로 로그 모니터링에 근간을 두고 있다. 애초에 Elasticsearch 라는 솔루션이 풀 텍스트 인덱싱을 하는 Lucene 으로 만들어진 물건이니. 물론 요즘에는 로그와 메트릭 뿐만 아니라 APM 까지 만들어서 애플리케이션 레벨의 모니터링까지 영역을 넓히고 있긴 하다.\n그에 반해, TICK 스택은 메트릭 기반의 모니터링이라고 볼 수 있다. 여기서 메트릭과 로그의 차이점이라고 하면, 로그는 단순히 문자열 형태의 메시지라면 메트릭은 수치값을 가지는 형태라고 볼 수 있을 것이다. 애초에 Telegraf 자체도 메트릭 수집에 특화되어 있고 데이터 저장소인 InfluxDB 도 시계열 데이터를 저장하는 데이터베이스로 만들어져 있다.\n여기서 TICK 스택이라고 하면 Telegraf, InfluxDB, Chronograf, Kapacitor 로 이루어진 스택을 이야기하는데 그런 것 치고 시각화 영역을 Chronograf 로 쓰는 경우는 별로 없다. 사실 Chronograf 보다는 Grafana 가 시각화 도구로서 기능도 더 많고 기타 여러 데이터 소스와의 접합도 좋아서 TIG (Telegraf - InfluxDB - Grafana) 형태의 스택이 더 많이 쓰이는 것 같다. 근데 문제는 Grafana 쪽에서는 TICK 스택보다는 Prometheus 랑 더 친하고 요즘 container 기반 에코 시스템에서 Prometheus 가 더 잘 나간다는 사실이다. 그리고 둘 다 Go 언어로 만들어져 있다. 사실 요즘 container 기반의 에코 시스템 위의 툴들은 열에 여덟은 Go 언어를 사용하고 있는 것 같다. 이쪽 동네의 de facto 언어가 되어가는 느낌이다.\n아무튼 각설하고, Telegraf 앞서 말했든 메트릭 수집 에이전트다. 하지만 Telegraf 를 설명하는 말에는 항상 수식어가 하나 더 붙는다. \u0026amp;ldquo;플러그인 기반\u0026amp;rdquo; 이 그것이다. Telegraf 는 다양한 플러그인을 통해서 다양한 종류의 메트릭들을 수집할 수 있다. 그리고 수집된 메트릭을 꼭 InfluxDB 에만 넣을 수 있는 것도 아니라 다른 Output Plugin 을 통해서 다른 종류의 데이터 저장소에 집어 넣는 것도 가능하다.\n위의 그림은 Telegraf 공식 웹페이지에 있는 그림으로 TICK 스택의 아키텍처를 자세하게 보여준다. 여담으로 작년말에 확인해 봤을 때는 저 그림에 …",
    "tags":      ["tech","open source","telegraf"]
  },
  {
    "title":     "작명의 중요성",
    "permalink": "/naming-is-important/",
    "date":      "2019년 08월 16일",
    "summary":   "개발자들 사이에서 흔히들 하는 농으로 개발하는 시간보다 변수명을 짓는 데 더 시간을 쓴다고들 한다. 변수에 이름 붙이는 게 뭐 그리 어렵겠느냐만 사실 굉장히 어렵기도 하고 또 그만큼 중요하기도 하다.\n얼마전 회사 미팅에서 있었던 일이다. 내부적으로 만든 서비스 중에 Alert Manager 라는 서비스가 있었고, 해당 서비스에 이러이러한 기능을 붙이자는 의견이 나왔다. Alert Manager 에 있음직한 기능이었기 때문에 의견은 받아들여졌고, 그에 대한 논의가 지속되면서 추가하고자 하는 기능의 범위가 넓어졌다. 어느 선부터는 Alert Manager 에 있음직하지 못한, 더 넓은 개념의 기능이었기 때문에 이 기능을 Alert Manager 와 분리시켜서 별도의 서비스를 만들기로 합의했고 그 서비스에 대한 논의를 이어갔다. 하지만 서비스의 이름을 짓지 않은 상태에서 논의하다보니 편의상 새롭게 만들 서비스도 Alert Manager 로 지칭하기 시작했고 나를 포함한 다른 사람들은 혼란을 겪기 시작했다. 지금 논의되고 있는 기능이 원래의 Alert Manager 에 들어가야 하는 건지, 아니면 새롭게 만들 서비스에 들어갈 기능을 이야기하는 건지 헷갈리기 시작했다. 특히 처음부터 논의해 포함되어 있지 않던 사람들의 혼란은 더 컸다. 더이상의 혼란을 방지하기 위해 논의를 잠시 중단시키고 가제라도 이름을 짓고 시작하자고 제의했고, Admin Portal 이라는 이름이 선정되었다. 새로운 이름이 지어진 이후에야 혼란은 줄어들었다. 심지어는 Admin Portal 에 새로 들어감직한 기능들이 더 구체적으로 논의되기 시작했다. 다들 머리속에서 unidentified 상태의 서비스를 구체화시키기 보다는 Admin Portal 이라는 서비스를 구체화시키는 편이 더 쉬운 듯 했다. 문득 작명의 중요성에 대해 다시 한 번 생각해보게 되었다.\n",
    "content":   "개발자들 사이에서 흔히들 하는 농으로 개발하는 시간보다 변수명을 짓는 데 더 시간을 쓴다고들 한다. 변수에 이름 붙이는 게 뭐 그리 어렵겠느냐만 사실 굉장히 어렵기도 하고 또 그만큼 중요하기도 하다.\n얼마전 회사 미팅에서 있었던 일이다. 내부적으로 만든 서비스 중에 Alert Manager 라는 서비스가 있었고, 해당 서비스에 이러이러한 기능을 붙이자는 의견이 나왔다. Alert Manager 에 있음직한 기능이었기 때문에 의견은 받아들여졌고, 그에 대한 논의가 지속되면서 추가하고자 하는 기능의 범위가 넓어졌다. 어느 선부터는 Alert Manager 에 있음직하지 못한, 더 넓은 개념의 기능이었기 때문에 이 기능을 Alert Manager 와 분리시켜서 별도의 서비스를 만들기로 합의했고 그 서비스에 대한 논의를 이어갔다. 하지만 서비스의 이름을 짓지 않은 상태에서 논의하다보니 편의상 새롭게 만들 서비스도 Alert Manager 로 지칭하기 시작했고 나를 포함한 다른 사람들은 혼란을 겪기 시작했다. 지금 논의되고 있는 기능이 원래의 Alert Manager 에 들어가야 하는 건지, 아니면 새롭게 만들 서비스에 들어갈 기능을 이야기하는 건지 헷갈리기 시작했다. 특히 처음부터 논의해 포함되어 있지 않던 사람들의 혼란은 더 컸다. 더이상의 혼란을 방지하기 위해 논의를 잠시 중단시키고 가제라도 이름을 짓고 시작하자고 제의했고, Admin Portal 이라는 이름이 선정되었다. 새로운 이름이 지어진 이후에야 혼란은 줄어들었다. 심지어는 Admin Portal 에 새로 들어감직한 기능들이 더 구체적으로 논의되기 시작했다. 다들 머리속에서 unidentified 상태의 서비스를 구체화시키기 보다는 Admin Portal 이라는 서비스를 구체화시키는 편이 더 쉬운 듯 했다. 문득 작명의 중요성에 대해 다시 한 번 생각해보게 되었다.\n다른 것들과 구별되어야 하는 대상들에는 모두 이름이 붙어 있다. 자동차, 빌딩, 가로등, 거리, 그림, 마우스, 키보드 등등. 그리고 그 이름이라는 것은 그 대상에 대해 이러이러한 이름으로 부르기로 모두와 약속이 된 부분이기 때문에 다른 사람과 소통하기도 쉽다. 자동차라는 이름 없이 \u0026amp;ldquo;바퀴가 달리고 도로를 달릴 수 있는 교통수단\u0026amp;quot;이라고 부르면 소통 간에 오해의 소지가 생기기 쉽다. 누군가는 오토바이를 상상할지도 모르고, 누군가는 롤러스케이트, 누군가는 리어카를 상상할지도 모르는 일이다. 그것에 대해 \u0026amp;ldquo;자동차\u0026amp;quot;라고 이름을 붙이기 시작하는 순간 그러한 오해의 소지는 최소화된다. 모두가 같은 대상을 머리속에 그려놓고 이야기를 할 수 있다.\n더욱이 그 \u0026amp;ldquo;무언가\u0026amp;quot;를 만들어야 하는 사람들에게는 제대로 된 작명이 더 중요하게 된다. \u0026amp;ldquo;자동차\u0026amp;quot;라는 이름 없이 자동차를 만들어야 하는 조직에서는 자동차를 구체화시키기가 쉽지 않다. 하지만 만들어야 할 대상을 \u0026amp;ldquo;자동차\u0026amp;quot;로 이름붙이고 나서는 우리가 무엇을 만들어야 하는지가 더욱 분명해진다. 백미러와 사이드 미러가 있어야 하고, 고무로 만들어진 타이어와 사람이 타고 내릴 수 있는 문, 그리고 전방을 볼 수 있는 유리창을 다들 동일하게 머릿속에 떠올릴 것이다.\n하지만 동시에 대상에 이름을 붙이는 것은 그 대상의 범위를 좁혀버리는 일이기도 하다. \u0026amp;ldquo;자동차\u0026amp;quot;를 만들기로 한 팀은 아마도 엔진과 연료의 효율 등에 자연스레 신경을 더 쓰게 될 것이다. 자동차 안에 무엇이 포함될 지는 더이상 이야기하지 않을 것이다. 자동차 안에 포함된 건 당연히 사용자가 않을 시트와 짐을 싣을 트렁크 뿐이니까. 하지만 \u0026amp;ldquo;자동차\u0026amp;quot;라는 이름의 한계를 뚫고 그 안에 주방과 화장실과 침대를 넣자는 아이디어가 어쩌면 그들에게는 더 필요한 방향일 수도 있다. (그리고 그 대상은 \u0026amp;ldquo;캠핑카\u0026amp;quot;라는 새로운 이름을 얻게 될 것이다.) 하지만 \u0026amp;ldquo;자동차\u0026amp;quot;라는 이름의 한계를 뚫기는 쉽지 않다.\n대상에 이름을 붙이는 순간 그것이 상상력의 여지를 닫아버리 …",
    "tags":      ["daily"]
  },
  {
    "title":     "새로운 곳으로 이사",
    "permalink": "/move-to-another-place/",
    "date":      "2019년 08월 15일",
    "summary":   "약 2년간의 관악구 생활을 마치고 용인으로 이사를 가기로 했다.\n애초에 이 곳으로 이사를 오게 되었던 이유는,\n아무래도 서울 안의 인프라가 더 많으니까 처가가 가까우니까 였는데, 중간에 차를 사고 나니 이런 것들이 크게 의미가 없어져버렸다. 주말이나 휴일에 항상 차를 타고 다니게 되면서 서울 안쪽 보다는 바깥쪽으로 매번 나돌았고, 사람들이 그득그득한 시내보다는 고즈넉하고 여유로운 풍경들을 즐기기 시작했다. 거기다 아무래도 차가 있으니 처가에서 좀 멀어진다고 해도 방문하기에 크게 무리가 없기도 하고.\n다음 이사지로 용인을 고른 것은 아무래도 직장의 영향이 컸다. 내 경우에 지금 직장은 분당, 그리고 이직을 해봤자 판교나 멀어도 강남 정도에 떨어지게 될 것이다. 아내도 강동구로 출퇴근을 하게 될 예정이었기 때문에 용인은 여러모로 괜찮은 선택지였다. 거기다 오히려 경기도라서 더 메리트가 있다고 느껴졌다. 사실 가능하다면 아예 경기도 조차도 벗어나고 싶다는 생각을 했다.\n",
    "content":   "약 2년간의 관악구 생활을 마치고 용인으로 이사를 가기로 했다.\n애초에 이 곳으로 이사를 오게 되었던 이유는,\n아무래도 서울 안의 인프라가 더 많으니까 처가가 가까우니까 였는데, 중간에 차를 사고 나니 이런 것들이 크게 의미가 없어져버렸다. 주말이나 휴일에 항상 차를 타고 다니게 되면서 서울 안쪽 보다는 바깥쪽으로 매번 나돌았고, 사람들이 그득그득한 시내보다는 고즈넉하고 여유로운 풍경들을 즐기기 시작했다. 거기다 아무래도 차가 있으니 처가에서 좀 멀어진다고 해도 방문하기에 크게 무리가 없기도 하고.\n다음 이사지로 용인을 고른 것은 아무래도 직장의 영향이 컸다. 내 경우에 지금 직장은 분당, 그리고 이직을 해봤자 판교나 멀어도 강남 정도에 떨어지게 될 것이다. 아내도 강동구로 출퇴근을 하게 될 예정이었기 때문에 용인은 여러모로 괜찮은 선택지였다. 거기다 오히려 경기도라서 더 메리트가 있다고 느껴졌다. 사실 가능하다면 아예 경기도 조차도 벗어나고 싶다는 생각을 했다.\n이런 생각을 가지게 된 건 원주에 사는 처형네를 종종 방문하면서 부터 였다. 서울 근교 지역과 비교해 크게 저렴한 집값과 더불어, 주변에 아이를 데리고 산책을 할 수 있는 공원이 있는 것도 부러웠고, 무엇보다 차를 타게 된다는 가정 하에 주변에 필요한 인프라는 모두 갖추어져 있었다. 사실 개발자라는 직업을 놓기 전까지는 원주 같은 곳으로의 이사는 무리지만 아무래도 용인 정도면 비슷한 메리트들을 누릴 수 있지 않을까 하는 생각이다.\n사실 이러한 생각의 연장선으로 요즘에는 풀 리모트 근무에 대한 희망을 가지고 있기도 하다. 리모트 근무를 하게 된다고 해도 어차피 집에서 일을 하기에는 무리가 있을테니 코워킹 플레이스 같은 곳으로 출근을 하긴 해야 할 것이다. 하지만 매일 아침, 사람들로 그득그득한 지옥철이나 차들이 그득그득한 도로로 향하지 않고 내가 마음에 드는 곳으로 출근을 할 수 있는 생활이 굉장히 매력적으로 느껴졌다. 매일같이 느껴지는 사무실의 갑갑함에서 벗어나는 것 만으로도 삶의 질이 굉장히 오를 것으로 생각한다.\n예전부터 사무실에서 근무를 하다 문득 갑갑함이 느껴질 때는 유튜브에서 오토바이 투어링 영상을 틀어놓곤 했다. 뻥뻥 뚫린 국도를 달리는 오토바이 영상을 보고 있기만 해도 답답한 마음이 조금은 풀어지고는 했다. 하지만 풀 리모트 근무를 하게 된다면 이러한 희망 사항을 현실로 이룰 수 있을 것이다. 아침마다 나는 출근할 사무실을 정할 수 있다. 어느 날에는 홍대의 코워킹 플레이스로, 혹은 가평 근처 어딘가의 적당한 백색 소음이 있는 까페로.\n요즘 많은 기술 기업이나 스타트업들이 풀 리모트들을 하나 둘 씩 받아들이고 있다. 특히 글로벌 테크 기업의 경우에는 우리나라의 경우보다 더 적극적으로 리모트 근무를 적용하고 있다. 사실 리모트 근무 하나만 놓고 보자면 국내 기업 보다는 글로벌 기업들을 노리는 것이 더 확률이 높을 것이다. 하지만 마지막까지 걸리는 것은 언제나 영어였다. 종종 친구들과 \u0026amp;lsquo;영어가 지금까지 내 발목을 잡을 줄은 몰랐다\u0026amp;rsquo;라고 농을 주고받곤 했는데, 언젠가 넘긴 넘어야 하는 벽이라고 생각한다. 그래서 일주일이 한번씩 지인과 영어 회화 스터디를 하고 있긴 하다. 하지만 어느 순간에는 학원이나 과외같은 전문가의 도움을 받아야 하겠다 라는 생각도 하고 있다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "Git - branch 삭제 후 push",
    "permalink": "/git-delete-branch-and-push/",
    "date":      "2019년 08월 14일",
    "summary":   "git에서 브랜치를 따서 작업을 하고 머지된 이후에는 자연스레 작업 브랜치는 날리게 된다. Github 의 풀 리퀘스트 같은 수단을 이용하게 되면 머지 이후에 Delete Branch 버튼을 통해 쉽게 remote 상의 브랜치를 제거할 수 있으나 로컬에서 바로 머지한 경우에는 로컬의 브랜치와 remote 의 브랜치를 모두 제거해주어야 한다. 헌데 로컬 브랜치 제거는 괜찮은데 remote 브랜치 제거 명령어를 항상 까먹는다.\n명령어는 아래와 같다.\ngit branch -D branch-name # local branch 제거 git push origin :branch-name # remote branch 제거 remote 브랜치 제거 명령어를 매번 까먹어서 매번 찾아서 하다가 이걸 그냥 alias 를 걸어놔야 되겠다고 생각했다. 기왕 alias 거는거 local + remote 둘 다 한 번에 제거하게끔 계획했다. 이 과정에서 제거할 브랜치 이름을 argument 로 받아야 하는데 문제는 git alias 에서는 argument 를 지원하고 있지 않다는 것이다. 이 부분을 해결하기 위해 구글링을 해봤지만 뭔가 elegant 한 방법은 찾지 못했고 아래와 같이 구성하였다.\n",
    "content":   "git에서 브랜치를 따서 작업을 하고 머지된 이후에는 자연스레 작업 브랜치는 날리게 된다. Github 의 풀 리퀘스트 같은 수단을 이용하게 되면 머지 이후에 Delete Branch 버튼을 통해 쉽게 remote 상의 브랜치를 제거할 수 있으나 로컬에서 바로 머지한 경우에는 로컬의 브랜치와 remote 의 브랜치를 모두 제거해주어야 한다. 헌데 로컬 브랜치 제거는 괜찮은데 remote 브랜치 제거 명령어를 항상 까먹는다.\n명령어는 아래와 같다.\ngit branch -D branch-name # local branch 제거 git push origin :branch-name # remote branch 제거 remote 브랜치 제거 명령어를 매번 까먹어서 매번 찾아서 하다가 이걸 그냥 alias 를 걸어놔야 되겠다고 생각했다. 기왕 alias 거는거 local + remote 둘 다 한 번에 제거하게끔 계획했다. 이 과정에서 제거할 브랜치 이름을 argument 로 받아야 하는데 문제는 git alias 에서는 argument 를 지원하고 있지 않다는 것이다. 이 부분을 해결하기 위해 구글링을 해봤지만 뭔가 elegant 한 방법은 찾지 못했고 아래와 같이 구성하였다.\n[alias] dd = \u0026amp;#34;!f() { git branch -D $1 \u0026amp;amp;\u0026amp;amp; git push origin :$1; }; f\u0026amp;#34; ",
    "tags":      ["tech","git"]
  },
  {
    "title":     "오늘의 삽질 - 괜히 Bash 만 의심했다.",
    "permalink": "/bash-is-not-async/",
    "date":      "2019년 08월 13일",
    "summary":   "회사에서 만들어놓은 쉘 스크립트가 있었다. 필요한 패키지를 다운로드받아 설치하고 설정파일을 고치고 systemctl 로 띄우는 내용의 스크립트로 대략적인 모양새는 아래와 같다.\ninstall_blabla() { dest=$(mktemp /tmp/blabla_XXXX.deb) curl -fsSL http://blabla.com/blabla.deb -o $dest dpkg -i $dest rm -f $dest } install_conf() { curl -fsSL http://blabla.com/blabla.conf -o /etc/blabla/blabla.conf sed -i -e \u0026#34;...\u0026#34; /etc/blabla/blabla.conf } start_blabla() { systemctl start blabla } do_install() { install_blabla install_conf start_blabla } do_install 위의 스크립트에 따르면 아래의 로직을 타게 된다.\n",
    "content":   "회사에서 만들어놓은 쉘 스크립트가 있었다. 필요한 패키지를 다운로드받아 설치하고 설정파일을 고치고 systemctl 로 띄우는 내용의 스크립트로 대략적인 모양새는 아래와 같다.\ninstall_blabla() { dest=$(mktemp /tmp/blabla_XXXX.deb) curl -fsSL http://blabla.com/blabla.deb -o $dest dpkg -i $dest rm -f $dest } install_conf() { curl -fsSL http://blabla.com/blabla.conf -o /etc/blabla/blabla.conf sed -i -e \u0026amp;#34;...\u0026amp;#34; /etc/blabla/blabla.conf } start_blabla() { systemctl start blabla } do_install() { install_blabla install_conf start_blabla } do_install 위의 스크립트에 따르면 아래의 로직을 타게 된다.\ncurl 로 blabla.deb 다운로드 dpkg 로 blabla.deb 설치 curl 로 blabla.conf 다운로드 sed 로 blabla.conf 내용 수정 systemctl 로 blabla 시작 이 로직대로 정상 작동 한다면 blabla는 수정된 설정파일을 정상적으로 물고 떠야한다. 하지만 blabla가 이상 동작을 한다는 이슈가 리포팅되었고, 확인 결과 수정된 설정파일이 아니라 기본 설정 파일을 물고 뜨는 것으로 의심이 되는 상황이었다.\n하지만 아무리 확인을 해봐도 설정파일은 정상적으로 수정되어 있었고, 그렇다고 다른 path의 설정 파일을 물고 있는 상황도 아니었다.\n순간 머리속을 스치는 의심 하나,\n\u0026amp;ldquo;모종의 알 수 없는 이유로 blabla.conf 파일 다운로드가 채 끝나기 전에 다음 구문이 실행되었다면?\u0026amp;rdquo;\n그래서 blabla를 재기동해보았고 정상적으로 수정된 설정 파일을 잘 물고 뜨는 걸 확인할 수 있었다. 갑작스레 혼란이 밀려왔다.\n\u0026amp;ldquo;아니, 무슨 bash가 node.js 도 아니고 상황에 따라서 curl 명령이 끝나기 전에 다음 구문으로 넘어갈 수가 있나? 무슨 bash가 async야?\u0026amp;rdquo;\n혹시나 싶어서 구글링을 해봤지만 걸리는 건 없었고 사건이 터진 이유를 알 수 없어 혼란스러워 하던 즈음, 옆 동료 분이 원인을 정확하게 짚어주셨다.\n\u0026amp;ldquo;이거 dpkg 로 설치하고 바로 뜨는 것 같은데요.\u0026amp;rdquo;\n문제는 당연히 bash 가 async 로 동작했다거나 그런게 아니었고 ubuntu 기준으로 dpkg로 설치되는 패키지는 서비스가 포함되어 있으면 자동으로 enabled \u0026amp;amp;\u0026amp;amp; started 되는 현상이었다.\n괜히 의심했던 것 같아 bash 에게 사과를\u0026amp;hellip;\n",
    "tags":      ["tech","trouble shooting"]
  },
  {
    "title":     "연봉과 연차의 무게",
    "permalink": "/better-than-yesterday/",
    "date":      "2019년 08월 13일",
    "summary":   " \u0026ldquo;이제는 단순 개발만 하고 기능구현만 하는 것이 아니라 그 이상을 해야 할 시기가 다가온다.\u0026rdquo;\n\u0026ldquo;사람들 관리가 될 수도 있고 어느 한 분야에 전문가가 되어야 할 수도 있고, 선택은 본인의 몫\u0026rdquo;\n(from https://taetaetae.github.io/2019/07/07/review-first-half-2019/)\n직장 생활을 시작한 이래로 꽤 오랫동안 해오던 생각들이다. 개발자에게 가장 기본이 되는 일은 \u0026ldquo;의도대로 동작하는 코드를 작성\u0026quot;하는 일이다. 하지만 어느 순간에는 그 이상의 플러스 알파를 해낼 수 있어야 한다.\n이러한 생각을 처음 했던 것은 개발자로써 직장 생활을 막 시작했을 무렵이었다. 회사에서 마주한 코드들은 내가 그동안 아마추어로써 만져오던 코드들과 완전히 궤를 달리할 정도로 수준이 달랐다. 나름 그래도 대학교 시절 코드 좀 쓴다고 자부했던 내 자존감은 앓는 이처럼 흔들거리고 있었다. 그 무렵 나는 하루에도 몇 번 씩이나 회사에서 내개 요구하는 기대치와 현재 나의 레벨에 대해서 생각했다. 나는 과연 내가 받는 월급의 값어치를 다하고 있는 걸까, 신입사원에게 실수는 어디까지 용납될까, 6개월 정도면 신입사원 딱지를 떼고 오롯이 한 사람의 몫을 할수 있어야 하지 않을까, 하는 생각들로 나를 채찍질했다. 그리곤 퇴근시간이면 항상 내게 자문했다. \u0026ldquo;나는 오늘 일급 만큼의 일을 했는가? 만약 내가 나를 고용했다면, 오늘의 내게 이 정도의 돈을 줄 수 있나?\u0026rdquo;\n",
    "content":   " \u0026amp;ldquo;이제는 단순 개발만 하고 기능구현만 하는 것이 아니라 그 이상을 해야 할 시기가 다가온다.\u0026amp;rdquo;\n\u0026amp;ldquo;사람들 관리가 될 수도 있고 어느 한 분야에 전문가가 되어야 할 수도 있고, 선택은 본인의 몫\u0026amp;rdquo;\n(from https://taetaetae.github.io/2019/07/07/review-first-half-2019/)\n직장 생활을 시작한 이래로 꽤 오랫동안 해오던 생각들이다. 개발자에게 가장 기본이 되는 일은 \u0026amp;ldquo;의도대로 동작하는 코드를 작성\u0026amp;quot;하는 일이다. 하지만 어느 순간에는 그 이상의 플러스 알파를 해낼 수 있어야 한다.\n이러한 생각을 처음 했던 것은 개발자로써 직장 생활을 막 시작했을 무렵이었다. 회사에서 마주한 코드들은 내가 그동안 아마추어로써 만져오던 코드들과 완전히 궤를 달리할 정도로 수준이 달랐다. 나름 그래도 대학교 시절 코드 좀 쓴다고 자부했던 내 자존감은 앓는 이처럼 흔들거리고 있었다. 그 무렵 나는 하루에도 몇 번 씩이나 회사에서 내개 요구하는 기대치와 현재 나의 레벨에 대해서 생각했다. 나는 과연 내가 받는 월급의 값어치를 다하고 있는 걸까, 신입사원에게 실수는 어디까지 용납될까, 6개월 정도면 신입사원 딱지를 떼고 오롯이 한 사람의 몫을 할수 있어야 하지 않을까, 하는 생각들로 나를 채찍질했다. 그리곤 퇴근시간이면 항상 내게 자문했다. \u0026amp;ldquo;나는 오늘 일급 만큼의 일을 했는가? 만약 내가 나를 고용했다면, 오늘의 내게 이 정도의 돈을 줄 수 있나?\u0026amp;rdquo;\n첫 번째 이직을 하던 즈음에는 고민의 깊이가 한층 더 깊어졌다. 여기서 나는 어떤 역할을 수행해야 하는가, 면접 때 내게 질문을 던지던 CTO 님은 내게 어떤 기대치를 가지고 있으며, 나는 거기서 어디까지 충족하고 있을까. 이러한 고민들은 때론 비타민이 되기도, 또 때론 내 자존감을 끌어내리기도 했다. 그러는 와중에도 계속해서 내가 만족시켜야 하는 기대치와 나의 가치에 대해 생각했다.\n조직에 필요한 사람의 종류를 크게 두 가지로 나누라고 한다면 이렇게 대답할 수 있을 것 같다. 우리가 어디로 가야 하는지에 대한 물음에 의사결정을 하는 사람, 그리고 실제로 그 곳으로 다다르기 위해 페달을 밟는 사람. 전자는 일반적으로 \u0026amp;ldquo;장\u0026amp;quot;의 지위를 가지고 있고, 후자는 실무자 정도가 될 수 있을 것이다. 그리고 대부분이 실무자에서 시작하여 대리, 과장, 차장 등의 직급의 계단을 하나씩 올라 점점 더 중요한 의사결정을 해야 하는 권한과 책임을 짊어지게 된다. 권한과 책임, 그것이 점차 높아지는 연봉의 무게가 아닌가 하는 생각을 한다.\n대부분의 사람들이 신입 딱지를 떼면 한 사람 분의 일을 오롯이 해낸다. 거기에 2~3년 정도의 경험이 붙으면 가히 베테랑이라 부를 수 있을 만큼 속도와 효율이 올라간다. 하지만 실무 관점에서의 이러한 업무 효율이 계속해서 선형적으로 증가하지는 않는다. 업무의 성격마다 다르겠지만 연차가 붙을 수록 실무 역량 증가의 기울기는 점차 감소하게 된다. 그렇다고 해서 회사가 특정 연차 이후의 직원들을 대상으로 연봉을 동결시키지는 않는다. 매년 더 높은 연봉을 주고 더 높은 직급을 달아주는 것은 단순히 실무를 효율적으로 진행하는 것, 그 이상의 플러스 알파를 개인에게 기대하기 때문이다. 여기서 플러스 알파가 무엇인지는 회사, 직군, 조직에 따라 모두 다를 것이다. 심지어는 같은 조직 내 개인 별로도 모두 다를 수있다. 각자 자신만의 무기를 갈고 닦아서 회사 내 자신의 존재 이유를 증명해내야 한다.\n이 무기를 계속해서 찾아내고, 또 갈고 닦지 않으면 지금껏 평범하게 영위하던 일상을 어느 순간에는 손가락 사이 모래처럼 잃을 수도 있다는 다소의 불안감을 가지고 있다. 일상을 지속시키기 위한 대가가 이다지도 작지 않다는 것이 사회 초년병 시절에는 생경하게 느껴지기도 했다. 하지만 그동안 적지 않게 먹은 직장 생활 짬밥 덕분일까, 이제는 이러한 종류의 일상의 투쟁이 뭐 크게 이상하지도 않다.\n지금 재가 갈고 닦고 있는 무기는 기술 도메인이다. 단순히 읽기 좋 …",
    "tags":      ["tech","career"]
  },
  {
    "title":     "qmk_firmware 빌드 시에 chibios 관련 에러 발생",
    "permalink": "/error-while-building-qmk_firmware/",
    "date":      "2018년 10월 16일",
    "summary":   "qmk_firmware는 programmable한 여러 키보드들을 지원하는 오픈소스 펌웨어다. 이 펌웨어가 지원하는 대표적인 키보드는 planck, ergodox 등이 있다. documentation 및 자세한 정보는 https://qmk.fm/ 에서 확인할 수 있다. 처음 이 소스를 clone 받아서 빌드를 하기 위해서 documentation을 보면 아래와 같이 가이드를 해준다.\n$ make \u0026lt;my_keyboard\u0026gt;:\u0026lt;my_keymap\u0026gt; 하지만 그대로 따라치면 아래와 같은 에러를 볼 수 있다.\n$ make ergodo_infinity:default tmk_core/chibios.mk:38: lib/chibios-contrib/os/common/startup/ARMCMx/compilers/GCC/mk/startup_k20x7.mk: No such file or directory tmk_core/chibios.mk:40: lib/chibios/os/hal/hal.mk: No such file or directory tmk_core/chibios.mk:46: lib/chibios-contrib/os/hal/ports/KINETIS/K20x/platform.mk: No such file or directory tmk_core/chibios.mk:78: lib/chibios-contrib/os/hal/boards/PJRC_TEENSY_3_1/board.mk: No such file or directory tmk_core/chibios.mk:79: lib/chibios/os/hal/osal/rt/osal.mk: No such file or directory tmk_core/chibios.mk:81: lib/chibios/os/rt/rt.mk: No such file or directory tmk_core/chibios.mk:87: lib/chibios/os/common/ports/ARMCMx/compilers/GCC/mk/port_v7m.mk: No such file or directory tmk_core/chibios.mk:89: lib/chibios/os/hal/lib/streams/streams.mk: No such file or directory quantum/visualizer/visualizer.mk:77: lib/ugfx/gfx.mk: No such file or directory make[1]: *** No rule to make target `lib/ugfx/gfx.mk\u0026#39;. Stop. make: *** [ergodox_infinity:default] Error 1 이는 submodule이 적절히 업데이트 되지 않아 발생하는 문제다. 따라서 아래의 명령어로 submodule을 업데이트 시켜주면 정상적으로 다시 빌드를 할 수 있다.\n",
    "content":   "qmk_firmware는 programmable한 여러 키보드들을 지원하는 오픈소스 펌웨어다. 이 펌웨어가 지원하는 대표적인 키보드는 planck, ergodox 등이 있다. documentation 및 자세한 정보는 https://qmk.fm/ 에서 확인할 수 있다. 처음 이 소스를 clone 받아서 빌드를 하기 위해서 documentation을 보면 아래와 같이 가이드를 해준다.\n$ make \u0026amp;lt;my_keyboard\u0026amp;gt;:\u0026amp;lt;my_keymap\u0026amp;gt; 하지만 그대로 따라치면 아래와 같은 에러를 볼 수 있다.\n$ make ergodo_infinity:default tmk_core/chibios.mk:38: lib/chibios-contrib/os/common/startup/ARMCMx/compilers/GCC/mk/startup_k20x7.mk: No such file or directory tmk_core/chibios.mk:40: lib/chibios/os/hal/hal.mk: No such file or directory tmk_core/chibios.mk:46: lib/chibios-contrib/os/hal/ports/KINETIS/K20x/platform.mk: No such file or directory tmk_core/chibios.mk:78: lib/chibios-contrib/os/hal/boards/PJRC_TEENSY_3_1/board.mk: No such file or directory tmk_core/chibios.mk:79: lib/chibios/os/hal/osal/rt/osal.mk: No such file or directory tmk_core/chibios.mk:81: lib/chibios/os/rt/rt.mk: No such file or directory tmk_core/chibios.mk:87: lib/chibios/os/common/ports/ARMCMx/compilers/GCC/mk/port_v7m.mk: No such file or directory tmk_core/chibios.mk:89: lib/chibios/os/hal/lib/streams/streams.mk: No such file or directory quantum/visualizer/visualizer.mk:77: lib/ugfx/gfx.mk: No such file or directory make[1]: *** No rule to make target `lib/ugfx/gfx.mk\u0026amp;#39;. Stop. make: *** [ergodox_infinity:default] Error 1 이는 submodule이 적절히 업데이트 되지 않아 발생하는 문제다. 따라서 아래의 명령어로 submodule을 업데이트 시켜주면 정상적으로 다시 빌드를 할 수 있다.\n$ make git-submodule 혹은 아래의 두 명령어도 같은 역할을 한다.\n$ git submodule sync --recursive $ git submodule update --init --recursive --progress ",
    "tags":      ["tech","keyboard"]
  },
  {
    "title":     "reselect",
    "permalink": "/reselect/",
    "date":      "2018년 10월 06일",
    "summary":   " https://github.com/reactjs/reselect reselect는 redux에 붙여서 쓸 수 있는 selector 라이브러리로 역할은 아래의 두 가지로 정리된다.\n컴포넌트를 redux에 connect 시킬 때 store로부터 데이터를 꺼내와서 매핑시키는 부분 추상화 selector 함수에서 반환되는 값을 캐싱하여 성능 향상 가령 아래와 같은 코드가 있다고 가정하면,\nconst mapStateToProps = (state, ownProps) =\u0026gt; { const { contentIds } = state.userContent; return { contentIds, }; }; reselect를 붙여 아래와 같은 형태로 정리할 수 있다.\n// selector const getUserContent = state =\u0026gt; state.userContent; const selectUserContentIds = createSelector( [ getUserContent ], // input selector userContent =\u0026gt; userContent.contentIds ); //component const mapStateToProps = (state, ownProps) =\u0026gt; ({ contentIds: selectUserContentIds(state), }); 이러한 형태에서 먼저 눈에 띄는 장점은 컴포넌트 단에서 redux store의 구조를 알 필요없이 selector 만 호출할 수 있다는 점이다. 이외에도 reselect는 memoized selector 를 통해서 성능 향상을 꾀할 수 있다.\n",
    "content":   " https://github.com/reactjs/reselect reselect는 redux에 붙여서 쓸 수 있는 selector 라이브러리로 역할은 아래의 두 가지로 정리된다.\n컴포넌트를 redux에 connect 시킬 때 store로부터 데이터를 꺼내와서 매핑시키는 부분 추상화 selector 함수에서 반환되는 값을 캐싱하여 성능 향상 가령 아래와 같은 코드가 있다고 가정하면,\nconst mapStateToProps = (state, ownProps) =\u0026amp;gt; { const { contentIds } = state.userContent; return { contentIds, }; }; reselect를 붙여 아래와 같은 형태로 정리할 수 있다.\n// selector const getUserContent = state =\u0026amp;gt; state.userContent; const selectUserContentIds = createSelector( [ getUserContent ], // input selector userContent =\u0026amp;gt; userContent.contentIds ); //component const mapStateToProps = (state, ownProps) =\u0026amp;gt; ({ contentIds: selectUserContentIds(state), }); 이러한 형태에서 먼저 눈에 띄는 장점은 컴포넌트 단에서 redux store의 구조를 알 필요없이 selector 만 호출할 수 있다는 점이다. 이외에도 reselect는 memoized selector 를 통해서 성능 향상을 꾀할 수 있다.\n여기서 주의할 점은, 만약 리스트 형태의 컴포넌트에서 selector를 사용할 경우 각 리스트 아이템마다 필요로 하는 데이터가 다르게 되기 떄문에 정상적으로 memoized 되지 않는다는 점이다. 이 경우에는 selector를 생성하는 로직을 함수로 한번 래핑하여 각 리스트 아이템들마다 다른 selector를 사용하도록 해야 한다.\n// selector const getUserContent = state =\u0026amp;gt; state.favoriteContent; const selectTitleByContentId = (state, contentId) =\u0026amp;gt; createSelector( [ getUserContent ], userContent =\u0026amp;gt; userContent.titles[contentId] )(state); // list item component const mapStateToProps = (state, ownProps) =\u0026amp;gt; ({ title: selectTitleByContentId(state, ownProps.contentId), }); reselect의 또다른 특징으로는 composable 하다는 점이다. 아래의 경우처럼 미리 만들어놓은 selector가 다른 selector의 input selector가 될 수 있어 selector들을 조합하는 것이 가능하다.\n// selector const getUserContent = state =\u0026amp;gt; state.userContent; const getEntities = state =\u0026amp;gt; state.entities; const selectUserContentIds = createSelector( [ getUserContent ], // input selector userContent =\u0026amp;gt; userContent.contentIds ); const selectUserContents = createSelector( [ selectUserContentIds, getEntities ], (userContentIds, entities) =\u0026amp;gt; userContentIds.map(contentId =\u0026amp;gt; entities.contents[contentId].data) ); //component const mapStateToProps = (state, ownProps) =\u0026amp;gt; ({ contents: …",
    "tags":      ["tech"]
  },
  {
    "title":     "AWS API, IP 기반으로 접근 제한하기",
    "permalink": "/aws-api-ip-based-access-control/",
    "date":      "2018년 01월 30일",
    "summary":   "EC2 상의 인스턴스나 로드밸런서에 특정 IP 대역만 접근 가능하도록 설정하고 싶다면 Security Group 혹은 ACL을 이용하면 된다. 하지만 그 외의 AWS에서 제공하는 API 들에 대해서 IP 기반으로 접근제한을 걸고 싶다면 Security Group, ACL 로는 불가능하다. 이 부분은 IAM의 Policy로 해결을 봐야 한다.\n예를 들어, AWS System Manager의 Parameter Store에 접근해서 데이터를 읽어오는 API를 IP 기반으로 제한하고 싶다고 가정하자. 그럼 일단 Parameter Store에 대한 기본 Policy 부터 확인해보자. “AWS IAM -\u0026gt; 정책” 로 들어가서 찾아볼 수 있다.\n",
    "content":   "EC2 상의 인스턴스나 로드밸런서에 특정 IP 대역만 접근 가능하도록 설정하고 싶다면 Security Group 혹은 ACL을 이용하면 된다. 하지만 그 외의 AWS에서 제공하는 API 들에 대해서 IP 기반으로 접근제한을 걸고 싶다면 Security Group, ACL 로는 불가능하다. 이 부분은 IAM의 Policy로 해결을 봐야 한다.\n예를 들어, AWS System Manager의 Parameter Store에 접근해서 데이터를 읽어오는 API를 IP 기반으로 제한하고 싶다고 가정하자. 그럼 일단 Parameter Store에 대한 기본 Policy 부터 확인해보자. “AWS IAM -\u0026amp;gt; 정책” 로 들어가서 찾아볼 수 있다.\n확인해본 결과 AmazonSSMReadOnlyAccess 라는 정책이 있다. 정책 상세값은 아래와 같다.\n{ \u0026amp;#34;Version\u0026amp;#34;: \u0026amp;#34;2012-10-17\u0026amp;#34;, \u0026amp;#34;Statement\u0026amp;#34;: [ { \u0026amp;#34;Effect\u0026amp;#34;: \u0026amp;#34;Allow\u0026amp;#34;, \u0026amp;#34;Action\u0026amp;#34;: [ \u0026amp;#34;ssm:Describe*\u0026amp;#34;, \u0026amp;#34;ssm:Get*\u0026amp;#34;, \u0026amp;#34;ssm:List*\u0026amp;#34; ], \u0026amp;#34;Resource\u0026amp;#34;: \u0026amp;#34;*\u0026amp;#34; } ] } 우리는 여기서 IP 기반 조건만 넣어주면 된다. 일단 기본 정책 AmazonSSMReadOnlyAccess의 상세 JSON 값을 복사한 후에 새로운 정책을 생성해보자.\n“AWS IAM -\u0026amp;gt; 정책 -\u0026amp;gt; 정책 생성”으로 들어가면 정책을 생성하기 위한 도구로써 시각적 편집기와 JSON 입력창이 제공되는데 JSON 입력창을 이용하여 다음의 내용을 입력한다.\n{ \u0026amp;#34;Version\u0026amp;#34;: \u0026amp;#34;2012-10-17\u0026amp;#34;, \u0026amp;#34;Statement\u0026amp;#34;: [ { \u0026amp;#34;Effect\u0026amp;#34;: \u0026amp;#34;Allow\u0026amp;#34;, \u0026amp;#34;Action\u0026amp;#34;: [ \u0026amp;#34;ssm:Describe*\u0026amp;#34;, \u0026amp;#34;ssm:Get*\u0026amp;#34;, \u0026amp;#34;ssm:List*\u0026amp;#34; ], \u0026amp;#34;Resource\u0026amp;#34;: \u0026amp;#34;*\u0026amp;#34;, \u0026amp;#34;Condition\u0026amp;#34;: { \u0026amp;#34;IpAddress\u0026amp;#34;: { \u0026amp;#34;aws:SourceIp\u0026amp;#34;: [ \u0026amp;#34;{IP_ADDRESS_TO_ALLOW}\u0026amp;#34; ] } } } ] } 처음봤던 기본 조건에 비교하여 달라진 점은 “Condition” 부분이 추가되었다는 것이다. {IP_ADDRESS_TO_ALLOW} 부분을 적절하게 Allow 할 IP로 대체하면 된다. 단, aws api를 요청하는 경우에는 대부분의 경우 source ip가 외부 ip로 찍히게 되므로 사설 ip 대역은 설정해놓으면 안된다.\n이런식으로 정책을 설정한 뒤에 특정 계정에게 적용해놓으면 해당 계정을 통해서는 기 설정해놓은 IP 대역대에서만 접근할 수 있다.\n본문에는 “Allow” 기반으로 했는데 “Allow” 대신 “Deny”로 바꾸고 “IpAddress”를 “NotIpAddress”로 바꿔도 동일하게 동작 할 것이다.\nIAM 정책상에서 동일 리소스 및 동작에 대해 Allow와 Deny가 같이 존재한다면 Deny가 우선순위를 가진다.\n",
    "tags":      ["tech","aws"]
  },
  {
    "title":     "새로운 서비스를 만들어 봤습니다.",
    "permalink": "/making-new-service/",
    "date":      "2017년 12월 01일",
    "summary":   "",
    "content":   " ",
    "tags":      ["tech"]
  },
  {
    "title":     "\u003c조중균의 세계\u003e 를 읽었다.",
    "permalink": "/shame/",
    "date":      "2017년 11월 21일",
    "summary":   "그는 “지나간 세계” 라는 시를 쓰고 또 동명의 술집에서 형수라는 친구와 함께 산다. 대학생 무렵에는 운동권에 몸담았다. 운동권 학생들이 마음에 안들었던 한 교수는 역사 시험에서 시험지에 이름만 쓰면 점수를 주겠다고 했다. 다른 친구들은 아무렇지 않게 그 시험을 받아들일 때 그는 부끄러움을 생각했다. “아무것도 하지 않음으로써 이득을 취하는 일”에 그는 동조하지 않고 시험지에는 이름과 함께 시를 썼다. 이후 회사에 다니면서도 점심을 안먹고 점심 식대를 월급에서 제하지 않는 그에게 누군가 “몰래 점심을 먹을 수도 있지 않냐”라는 의심을 하자 그는 다시 부끄럽지 않기 위해서 매일 점심을 먹지 않았다는 확인 서명을 받았다. 일정대로 일이 진행되지 않자 상사는 그가 나태하게 일한다는 의심을 했고 그는 다시 그 의심 앞에서 부끄럽지 않기 위해서 매 시간 조카뻘되는 동료에게 찾아가 나태하게 일하지 않았다는 확인 서명을 받았다. 왼손 약지가 두 마디 정도 없던 그의 삶은 무엇을 가지고 있는지보다 무엇을 가지고 있지 못한지를 찾는 것이 편했다. 부끄럽지 않기 위한 대가였다.\n",
    "content":   "그는 “지나간 세계” 라는 시를 쓰고 또 동명의 술집에서 형수라는 친구와 함께 산다. 대학생 무렵에는 운동권에 몸담았다. 운동권 학생들이 마음에 안들었던 한 교수는 역사 시험에서 시험지에 이름만 쓰면 점수를 주겠다고 했다. 다른 친구들은 아무렇지 않게 그 시험을 받아들일 때 그는 부끄러움을 생각했다. “아무것도 하지 않음으로써 이득을 취하는 일”에 그는 동조하지 않고 시험지에는 이름과 함께 시를 썼다. 이후 회사에 다니면서도 점심을 안먹고 점심 식대를 월급에서 제하지 않는 그에게 누군가 “몰래 점심을 먹을 수도 있지 않냐”라는 의심을 하자 그는 다시 부끄럽지 않기 위해서 매일 점심을 먹지 않았다는 확인 서명을 받았다. 일정대로 일이 진행되지 않자 상사는 그가 나태하게 일한다는 의심을 했고 그는 다시 그 의심 앞에서 부끄럽지 않기 위해서 매 시간 조카뻘되는 동료에게 찾아가 나태하게 일하지 않았다는 확인 서명을 받았다. 왼손 약지가 두 마디 정도 없던 그의 삶은 무엇을 가지고 있는지보다 무엇을 가지고 있지 못한지를 찾는 것이 편했다. 부끄럽지 않기 위한 대가였다.\n신념 이라는 단어를 내뱉으면 어쩐지 고리타분한 냄새가 난다. 돈이 신념이 되버린 시대다. 내게 이득이 되도록 우리는 무수히도 부끄러운 순간들을 눈감아왔다. 신념 같은 것들은 국어사전 속에나 존재했고, 이득을 위해 어느 선까지 부끄러울 수 있는가를 저울질하는 정도의 차이만 있을 뿐이지 우리는 전부 부끄러움 앞에서 발가벗은 것처럼 무력하다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "2006년의 서울과학기술대학교 (3)",
    "permalink": "/snut-2006-3/",
    "date":      "2017년 11월 09일",
    "summary":   "종종 마음이 시끄러우면 나는 학교를 찾는다. 내비에 공릉동을 찍으면 집에서 대략 한 시간 정도의 거리가 나온다. 쉽게 올만한 거리는 아니다. 그럼에도 한 번씩 사는 게 버겁게 느껴질 때면 공릉동 이곳저곳을 기웃거린다. 어릴 적 소풍 가서 보물 찾기를 하는 마음으로 공릉동 구석구석에 묻어있는 기억들을 캐낸다. 어쩐지 매번 새롭다. 이십 대의 대부분을 보낸 내게 공릉동은 왠지 고향집 같은 느낌을 준다.\n오늘도 다시 찾았다. 어의관 엘리베이터 앞에 비치된 러비 12월호를 챙겨 로비 소파에 앉아 정독했다. 글을 읽고 쓰는 걸 좋아했기 때문에 대학생 때는 러비에서 직접 글을 써보고 싶다는 생각도 했지만 당시에는 도저히 짬을 낼 수 없을 것 같아 마음을 접었다. 그래도 아쉬운 마음에 종종 후기 엽서를 써 보냈는데 당첨된 적이 있다. 상품권을 준다길래 부리나케 달려갔던 러비 동아리방은 제1학생회관 옥상층에 홀로 떨어져 자리 잡고 있었다. 지금 생각해보면 옥탑방이나 마찬가진데 이 추운 겨울에 어찌 버티고 있는지 문득 궁금해진다.\n",
    "content":   "종종 마음이 시끄러우면 나는 학교를 찾는다. 내비에 공릉동을 찍으면 집에서 대략 한 시간 정도의 거리가 나온다. 쉽게 올만한 거리는 아니다. 그럼에도 한 번씩 사는 게 버겁게 느껴질 때면 공릉동 이곳저곳을 기웃거린다. 어릴 적 소풍 가서 보물 찾기를 하는 마음으로 공릉동 구석구석에 묻어있는 기억들을 캐낸다. 어쩐지 매번 새롭다. 이십 대의 대부분을 보낸 내게 공릉동은 왠지 고향집 같은 느낌을 준다.\n오늘도 다시 찾았다. 어의관 엘리베이터 앞에 비치된 러비 12월호를 챙겨 로비 소파에 앉아 정독했다. 글을 읽고 쓰는 걸 좋아했기 때문에 대학생 때는 러비에서 직접 글을 써보고 싶다는 생각도 했지만 당시에는 도저히 짬을 낼 수 없을 것 같아 마음을 접었다. 그래도 아쉬운 마음에 종종 후기 엽서를 써 보냈는데 당첨된 적이 있다. 상품권을 준다길래 부리나케 달려갔던 러비 동아리방은 제1학생회관 옥상층에 홀로 떨어져 자리 잡고 있었다. 지금 생각해보면 옥탑방이나 마찬가진데 이 추운 겨울에 어찌 버티고 있는지 문득 궁금해진다.\n지난번에 썼던 “2006년의 서울과학기술대학교” 1편과 2편을 뒤적이다 보니 시계탑 이야기가 빠져있었다. 2006년의 서울과학기술대학교 이야기를 풀어내겠다고 해놓고 시계탑 이야기를 빼놓았다니. 지금 재학생들에게 “시계탑”이라고 하면 알런지 모르겠다. 이미 철거된 지 꽤 되었으니까. 정확히 시기는 기억나지 않지만 아마도 2008년도쯤이었던 걸로 기억한다. 그러니 아직 학교를 다니고 있는 고학번들이나 겨우 얘기만 들어봤을까.\n사실 시계탑은 학교의 상징과도 같은 구조물이었다. 처음 입학하던 날 조우했던 우스꽝스러운 “凸” 모양의 교문도 사실은 다산관의 모양을 본 딴 것이고 다산관 머리 위에는 멋들어진 시계가 얹어 있었다. 사실 이 시계탑은 이미 예전부터 제 기능을 하지 못하고 있었다. 4면의 시곗바늘은 언제나 다른 시간을 가리키고 있었다. 그 시계탑이 유명한 것은 사실 신입생을 놀려먹는 유명한 레퍼토리 중 하나였기 때문이다. 새내기들이 학교에 대해 알아가기 시작하는 3, 4월쯤, 짓궂은 선배들은 새내기들에게 “다산관 시계탑은 사실 안에서 사람이 자전거 페달을 돌려 작동이 되는 거다”라는 거짓말로 골리곤 했다. 심지어는 “일이 고되기 때문에 시급이 짭짤하다”, “알바 신청은 어의관 행정학과 과사무실에서 하면 된다”는 식의 구체적인 거짓부렁들이 추가되기도 했다. 그 장난 섞인 거짓말들에 누군가는 진짜로 속아 행정학과 과사무실을 들렀다던가 하는 이야깃거리들이 축제 술자리 안주 위로 떠다녔다.\n교명이 변경되던 때의 이야기도 기억이 난다. 군대 가기 전까지는 “서울산업대학교”였는데 전역하고 복학할 시기가 다가오니 학교는 교명 변경으로 한창 시끄러웠다. 학생들 대부분은 산업대라는 어감을 별로 마음에 들어하지 않았다. 따라서 교명 변경 자체는 대부분 찬성했지만 변경될 교명에 대해 의견이 분분했다. 당시 여러 가지 교명 후보들이 사람들 사이에서 오르내렸는데 특히 현재의 교명인 서울과학기술대학교에 대해서 말이 많았다. 공대야 그렇다 쳐도 인문대와 조형대 학생들의 반발이 컸다. 과학기술대학교 문예창작학과라니 마치 하버드대학교 감귤학과 같다며 반대하는 이들이 있었지만 결국 현재의 교명으로 변경되고 말았다. 당시 후보로 사람들 사이에서 이야기되었던 다른 교명들로는 다산관의 이름을 따서 다산대학교도 있었지만 국립대 티가 별로 안 난다는 의견이었다. 누군가는 장난스레 “우리 학교의 모체인 공립어의동실업보습학교가 고종황제의 칙령으로 만들어졌으니 서울 왕립대가 어떠냐”라고 제안하기도 했다. 개인적으로 가장 간지가 풀풀 날리는 이름이 아닌가 싶다.\n마음이 시끄러울 때마다 학교를 찾게 되는 이유를 생각해본다. 공릉동 여기저기에 묻어있는 추억들이 괜히 특별하게 여겨지는 이유가 뭘까 고민해본다. 이 곳에는 20대의 어설픈 내 모습들이 묻어있다. 꼴에 대학생이라고 뭐라도 된 마냥 어설픈 몸짓으로 뭔가 일을 벌여보겠다고 설치기도 많이 설쳤다. 괜스레 미간 사이에 주름을 잡고는 후배들에게 설익은 조언을 건네기도 했다. 모자란 실력들을 가지고 과방에서 …",
    "tags":      ["daily"]
  },
  {
    "title":     "2006년의 서울과학기술대학교 (2)",
    "permalink": "/snut-2006-2/",
    "date":      "2017년 10월 24일",
    "summary":   "새 학기가 시작되면 자주 보이는 모습이 있었다. 바로 교내 잔디밭에서 자장면을 시켜먹는 모습이었다. 정문 근처 잔디밭, 붕어방 근처 잔디밭, 제1학생회관 옆 잔디밭 등등 너른 땅에 잔디밭이 수도 없이 깔려 있었고 당시에는 잔디밭에 출입을 통제하지도 않았기 때문에 친구들끼리 혹은 선후배들과 동그랗게 모여 앉아 자장면을 시켜먹는 모습은 자연스러운 광경이었다. 그러다 흥이 오르면 즉석에서 막걸리 잔이 돌아갔고 얼굴에 불콰한 빛을 띤 신입생들은 수업 시간을 외면한 채 2차 장소로 향하는 선배의 뒤를 쫄래쫄래 쫓곤 했다. 자장면 배달은 주로 서울대반점에 시켰었다. 저렴한 가격도 가격이었지만 무엇보다 배달시간이 비상식적으로 빨랐다. 교내 어디에서 시키던 최대 5분 컷을 넘어본 적이 없다. 맛이야 뭐 학교 앞 중국집들이 다 그러하듯 그냥 먹을만한 정도였던 걸로 기억한다. 서울대반점의 “스피드” 전략은 비단 배달에만 해당하지 않았다. 공강 시간에 서울대반점에 들러 카운터 앞에서 자장면 주문을 하면 채 자리에 앉기도 전에 자장면이 먼저 놓였다는 도시전설 같은 이야기가 떠돌았고 누구도 그 진위를 의심하지 않았다. 지금 생각해보면 그 너른 잔디밭에서 하루에 몇 번이고 “자장면 시키신 분?”을 외쳐야 했던 배달 요원들의 노고가 새삼 대단하다 싶다.\n",
    "content":   "새 학기가 시작되면 자주 보이는 모습이 있었다. 바로 교내 잔디밭에서 자장면을 시켜먹는 모습이었다. 정문 근처 잔디밭, 붕어방 근처 잔디밭, 제1학생회관 옆 잔디밭 등등 너른 땅에 잔디밭이 수도 없이 깔려 있었고 당시에는 잔디밭에 출입을 통제하지도 않았기 때문에 친구들끼리 혹은 선후배들과 동그랗게 모여 앉아 자장면을 시켜먹는 모습은 자연스러운 광경이었다. 그러다 흥이 오르면 즉석에서 막걸리 잔이 돌아갔고 얼굴에 불콰한 빛을 띤 신입생들은 수업 시간을 외면한 채 2차 장소로 향하는 선배의 뒤를 쫄래쫄래 쫓곤 했다. 자장면 배달은 주로 서울대반점에 시켰었다. 저렴한 가격도 가격이었지만 무엇보다 배달시간이 비상식적으로 빨랐다. 교내 어디에서 시키던 최대 5분 컷을 넘어본 적이 없다. 맛이야 뭐 학교 앞 중국집들이 다 그러하듯 그냥 먹을만한 정도였던 걸로 기억한다. 서울대반점의 “스피드” 전략은 비단 배달에만 해당하지 않았다. 공강 시간에 서울대반점에 들러 카운터 앞에서 자장면 주문을 하면 채 자리에 앉기도 전에 자장면이 먼저 놓였다는 도시전설 같은 이야기가 떠돌았고 누구도 그 진위를 의심하지 않았다. 지금 생각해보면 그 너른 잔디밭에서 하루에 몇 번이고 “자장면 시키신 분?”을 외쳐야 했던 배달 요원들의 노고가 새삼 대단하다 싶다.\n서울대반점 하니 학교 앞 핫 플레이스들이 몇 군데 떠오른다. 산업대의 메인 스트리트라고 하면 단연 술집 “술쟁이”가 있던 골목이었다. 누군가는 “술쟁이 골목”이라고 불렀고 누군가는 “공릉동 로데오”라고 불렀던 그 골목에는 보석 같은 가게들이 몇 군데 있다. 대표적으로는 “술쟁이”와 “나루터”가 있었다. 두 술집은 정 반대로 대비되는 분위기였다. 술쟁이는 저학번들이 주로 찾던 술집이었다. 실내에는 시끌시끌하게 최신가요가 나오고 벽 한편에는 빔 프로젝터로 뮤직비디오나 라이브 무대들을 틀어주었다. 술집에 들어서면 사방에서 “랜덤게임”을 하는 소리로 귀가 먹먹할 정도였다. 안주는 대략 5000원 대에서 형성되어 있었고 감자그라탕 같은 메뉴들이 잘 팔렸다. 술쟁이 앞에는 술을 들이붓다 지친 이들이 모여 쪼그려 앉아 있곤 했다. 그리고 그 옆에 토사물도 심심치 않게 눈에 띄었다.\n술쟁이 맞은편에는 나루터가 있었다. 술쟁이의 반 정도 되는 공간이었는데 “응답하라 1997”에나 나올 법한 술집이었다. 사방 벽에는 선배 동문들이 휘갈긴 글귀들이 세월의 바람을 맞아 누렇게 변색되어 붙어 있었고 주력 메뉴는 전통적인(?) 반도리탕이나 두부김치 같은 것들이었다. 분위기가 이러하니 이 술집은 주로 고학번들이 찾았다. 단골인 선배를 따라 처음 나루터를 갔을 때 선배는 사장님을 아버지라 불렀고 사장님은 “니들만 먹냐”며 냉장고에서 소주 한 병을 꺼내와 우리와 함께 잔을 나누셨다. 그런 사장님 뒤로 뭔가 불만이신 사모님의 얼굴도 보였다. 사장님 이야기를 해보자면 원래는 교직 생활을 하셨다가 은퇴 후 나루터를 차리셨다고 했다. 집안이 어려운 친구들을 위해 학기마다 장학금을 주셨는데 이걸 우리는 나루터 장학금이라고 불렀다. 듣자 하니 지금은 안타깝게도 문을 닫았다고 한다. 언젠가는 술에 취해 나루터 벽에다 “무슨무슨 동아리 누구누구 일동” 같은 낙서를 남겼는데 그 낙서를 다시 볼 수 없다는 게 조금 아쉽기도 하다.\n신입생 시절 내 공강 시간의 대부분은 동아리방과 당구장에서 보냈다. 당구장은 특히 학교 앞 에버그린 당구장을 많이 갔는데 음료수뿐만 아니라 달짝지근한 토스트를 줘서 친구들과 에버그린 토스트를 먹으러 가자며 자주 발길을 향하곤 했다. 하지만 내 또래 중 당구장을 다니는 친구는 일부였고 대부분은 플스방을 갔다. 내 선배들까지는 당구가 그 또래의 소셜 스포츠 급은 되었을 정도로 대중적이었는데 06학번부터는 당구를 많이 치지 않았다. 그래서 주로 형들과 많이 치러 다녔다.\n당구장 외에 공강 시간은 물론 수업이 끝나고 나서도 주로 동아리방에 많이 붙어있었다. 당시 내가 속해있던 동아리는 역사가 20년쯤 되었는데 그러다 보니 동아리방 캐비닛을 열면 케케묵은 노트와 사진첩들이 가득 들어차 있었다. 가끔 심심하면 그것들을 꺼내 …",
    "tags":      ["daily"]
  },
  {
    "title":     "2006년의 서울과학기술대학교 (1)",
    "permalink": "/snut-2006-1/",
    "date":      "2017년 10월 24일",
    "summary":   "오랜만에 모교인 서울과학기술대학교에 들렀다. 한밤 중이라 어두워 제대로 보이진 않았지만 못 보던 건물들이 꽤 들어서있었다. 심지어는 아직 공사 중인 곳도 있어서 포크레인이 부지 한가운데 덩그러니 서있었다. 10여 년 전에는 잔디밭이었던 곳에 번쩍번쩍 거리는 건물이 웅장하게 들어서 있었다. 귀신이 자주 출몰했다던 다빈치관은 온데간데 없어지고 대신 또 새로운 건물이 그 자리를 차지하고 있었다. 학교는 계속해서 더 나아지고 있지만 어쩐지 내 기억 속의 모습들과 조금씩 빗겨나가고 있는 것이 아쉬웠다. 그래서 2006년의 서울과학기술대학교의 모습을 늦기 전에 기억을 되새겨 남겨놓으려 한다.\n",
    "content":   "오랜만에 모교인 서울과학기술대학교에 들렀다. 한밤 중이라 어두워 제대로 보이진 않았지만 못 보던 건물들이 꽤 들어서있었다. 심지어는 아직 공사 중인 곳도 있어서 포크레인이 부지 한가운데 덩그러니 서있었다. 10여 년 전에는 잔디밭이었던 곳에 번쩍번쩍 거리는 건물이 웅장하게 들어서 있었다. 귀신이 자주 출몰했다던 다빈치관은 온데간데 없어지고 대신 또 새로운 건물이 그 자리를 차지하고 있었다. 학교는 계속해서 더 나아지고 있지만 어쩐지 내 기억 속의 모습들과 조금씩 빗겨나가고 있는 것이 아쉬웠다. 그래서 2006년의 서울과학기술대학교의 모습을 늦기 전에 기억을 되새겨 남겨놓으려 한다.\n정확히는 서울산업대학교였다. 아직 일반대학교 전환이 되기 전이었다. 덕분에 정시로 지원할 때는 ‘라’군으로 분류되어 가, 나, 다 군을 다른 학교에 쓰고 안전빵으로 우리 학교를 많이 쓰곤 했던 걸로 기억한다. 친구들끼리 학교를 부를 때는 주로 산업대라고 줄여 불렀다. 하루는 자취방에서 늦잠을 잔 덕에 택시를 타고 “산업대로 가주세요”라고 하고 한숨 자고 일어났는데 근처 삼육대학교로 가있었던 우습던 기억도 난다.\n어른들로부터의 평판은 좋지 못했다. 우리 아버지도 그랬다. 서울산업대로의 지망 의사를 밝혔을 때 아버지는 왜 그렇게 열심히 공부해놓고 고작 산업대를 가냐고 했다. 산업대라는 이름 속에는 어쩐지 직업전문학교의 냄새가 풀풀 풍겼고 심지어는 입시를 준비하는 학생들 사이에서의 인지도도 그리 좋지 못했다. 하지만 이상하게 고3들에게만은 인지도가 괜찮았다.\n그러고 보니 동기들 중에 실업계 출신도 있었다. 당시 서울산업대는 서울 내에서 실업계전형이 있는 몇 안 되는 대학교 중 하나였고, 그 문턱이 결코 낮지 않았기 때문에 많은 실업계 친구들이 우리 학교를 지망했다. 조금 과장하자면 실업계 전형의 서울대학교였다. 어디 무슨 도대회 대상 정도의 타이틀은 달고 있어야 합격 가능권에 발끝이라도 디뎌볼 수 있었다. 그래서인지 실업계 전형으로 온 친구들은 이래저래 재주가 많았다. 웹디자인 비슷한 걸로 대회 준비를 해서 온 친구 하나는 학과 홈페이지 리뉴얼 같은 알바를 종종 맡으면서 부족했던 생활비를 충당했다.\n처음 입학했을 쯤의 가장 인상적인 기억은 어의관이었다. 지금도 어의관이라고 부르는지 모르겠다. 내 한 학년 선배들은 어의관을 인문대, 그리고 다산관을 1공대 뭐 이런 식으로 불렀었다. 모든 교양과목들은 어의관에서 진행되었기 때문에 전공을 불문하고 학생들 사이에서 어의관은 익숙한 건물이었다. 어의관 내부 구조는 로비를 가운데로 두고 복도가 양쪽 끝으로 늘어서있는 모양새였는데 쉬는 시간이면 다들 담배를 물고 로비로 모여들었다. 그리고 로비에서 흡연을 했다. 지금이야 올바른 흡연 문화가 자리 잡혀가는 과정에서 흡연자들이 입지가 많이 줄어들었지만 그때 당시의 시선으로도 그건 충격이었다. 건물 한가운데서 담배를 폈다. 심지어 흡연장소는 자판기 옆이라 비흡연자인 친구들도 음료수를 뽑으려면 흡연자를 사이로 들어가야 했다. 그런 곳에 재떨이가 있었다는 것이 지금으로는 상상도 못 할 일이다. 나중에는 강의실 문을 열고 나오자마자 담배에 불을 붙이는 친구들도 있었다.\n어의관 1층 뒤편에도 역시 음료수 자판기와 흡연장소가 있었다. 그리고 그 뒤로는 불암 학사가 있었다. 그때 당시 기숙사라고는 불암 학사 밖에 없었다. 수용인원 역시 택도 없이 적었기 때문에 웬만해서는 기숙사 생활을 꿈꾸지 못했다. 지금 기억으로는 학점이 중요한 커트라인 중 하나였던 걸로 기억을 하는데 기숙사에 사는 대부분의 친구들의 평점이 모두 4.0을 넘었다. 나는 학교를 다니는 내내 기숙사를 들어가 보려는 엄두도 못 냈다.\n기숙사 뒤편으로는 협동문이라고 부르던 학교 후문이 있다. 아마 지금도 있을 것이다. 말이 후문이지 사실상 개구멍이라고 불러도 어색하지 않을 정도로 초라했다. 그 후문을 통하면 하계역까지 갈 수 있는 루트가 있는데 이 루트를 통하면 공릉역에서부터 걸어오는 것보다 더 빨리 학교에 도착할 수 있다고 했다. 특히 어의관에서 수업을 많이 듣는 인문대 친구들은 하계역 - 협동문 코스를 많이 …",
    "tags":      ["daily"]
  },
  {
    "title":     "리디스토리 프론트엔드 개발기",
    "permalink": "/how-to-develop-ridistory-frontend/",
    "date":      "2017년 10월 08일",
    "summary":   "본 포스팅은 회사 블로그에 올려놓았던 글을 옮겨놓은 것입니다.\n몬타나 존스 라는 만화영화가 있었습니다. 1990년대 중반쯤에 방영되었던 것으로 기억이 나네요. 에피소드마다 의인화된 사자와 호랑이가 유적지를 탐험하다 제로경으로 대표되는 악의 무리와 부딪힙니다. 제로경은 니트로 박사라는 부하가 만들어준 로봇을 타고 주인공의 앞길을 막고, 쫓고 쫓기는 아슬아슬한 활극 끝에 결국 정의의 편인 주인공이 승리하곤 합니다. 여기서 제로경과 니트로 박사가 주고받는 대화가 일품입니다.\n제로경: 니트로 박사, 사정을 설명해보실까? 니트로 박사: 지금이라도 시간과 예산을 조금만 더 주신다면… 제로경: 변명은 죄악이란 걸 모르나!\n",
    "content":   "본 포스팅은 회사 블로그에 올려놓았던 글을 옮겨놓은 것입니다.\n몬타나 존스 라는 만화영화가 있었습니다. 1990년대 중반쯤에 방영되었던 것으로 기억이 나네요. 에피소드마다 의인화된 사자와 호랑이가 유적지를 탐험하다 제로경으로 대표되는 악의 무리와 부딪힙니다. 제로경은 니트로 박사라는 부하가 만들어준 로봇을 타고 주인공의 앞길을 막고, 쫓고 쫓기는 아슬아슬한 활극 끝에 결국 정의의 편인 주인공이 승리하곤 합니다. 여기서 제로경과 니트로 박사가 주고받는 대화가 일품입니다.\n제로경: 니트로 박사, 사정을 설명해보실까? 니트로 박사: 지금이라도 시간과 예산을 조금만 더 주신다면… 제로경: 변명은 죄악이란 걸 모르나!\n오래된 기억 상자 속에서 몬타나 존스라는 만화영화 이야기를 꺼낸 이유는 신규 서비스를 개발하는 입장에서 니트로 박사에게 어쩐지 묘하게 공감했기 때문입니다. 스타트업에서 개발을 하는 많은 개발자분들도 공감할 수 있는 이야기라는 생각이 듭니다.\n우리에게 시간이 좀 더 있다면! 예산이 더 있다면! 인력이 더 있다면!\n가장 큰 문제는 시간 아, 시간! 콘텐츠 플랫폼의 비즈니스 가치는 유료 회원수와 콘텐츠의 질에 따라 결정됩니다. 그렇기 때문에 초기 시장을 선점하는 일은 굉장히 중요합니다. 이미 사용자는 기존 플랫폼이 제공하는 UX에 익숙해져 있습니다. 특별한 이유가 없다면 다른 제품을 사용하지 않습니다. 또한 콘텐츠 제공자는 시장에 영향력을 가진 플랫폼을 선호하기 때문에, 신생 플랫폼 입장에서 콘텐츠를 확보하려면 많은 노력이 필요합니다.\n하지만 리디스토리 개발이 시작될 당시 이미 굳건한 위치를 잡고 있는 플랫폼들이 많이 있었습니다. 따라서 리디스토리는 골리앗에게 도전하는 다윗의 심정으로 조금이라도 더 누구보다 빠르게 남들과는 다르게 출시해야 했습니다.\n이러한 사정은 비단 리디스토리 만의 이야기는 아닙니다. 많은 스타트업들이 빠르게 시장에 진입하기 위해 기반기술 같은 부분들은 가능하면 매니지드 서비스를 이용하고 생산성이 좋은 언어와 프레임워크를 이용하는 것이 요즘 트렌드인 것 같습니다.\n웹앱, 그리고 더 빠르게 그래서 웹앱이었습니다. 서비스 론칭까지 4개월, 선택지는 그리 많지 않았습니다. 사실 개발 초기에는 서버 개발자 2명밖에 없었습니다. 팀 내에 네이티브 앱 개발 경험을 가진 개발자가 있더라도 빠른 서비스 론칭을 위해서는 결국 웹앱 쪽으로 방향을 잡을 수밖에 없었습니다. 동일한 서비스를 구현하는 코드를 Android, iOS 각각의 플랫폼별로 두 벌을 만들어 유지하고 각각의 코드에서 발생할 이슈들까지 잡아나가기엔 시간과 인력의 효율 면에서 좋지 못했습니다.\n방향이 웹앱으로 정해지고 나서부터 리디스토리 개발팀은 익숙하고 빠르게 결과물을 낼 수 있는 방식으로 작업을 하기 시작했습니다. 서비스에 필요한 UI를 HTML로 구성하고 그 안에서 동적으로 변경되는 부분들은 Django에서 지원하는 Jinja2라는 템플릿을 통해서 구성하는 전통적인(?) 방식이었습니다. 그렇게 서비스의 얼개가 대강 잡혔을 때쯤 우리는 그동안 우리 안에서 가지고 있던 불안에 대해 꺼내놓고 이야기하기 시작했습니다.\n이거 너무 느린데요?\n네, 너무 느렸습니다. 느릴 수밖에 없었습니다. 스마트폰에 앱이라는 형태로 인스톨된 이상 사용자는 여타 다른 네이티브 애플리케이션과 비슷한 반응성을 기대하며 리디스토리 앱을 이용하게 됩니다. 하지만 리디스토리 앱의 내부는 웹과 동일한 형태로 구현이 되었으니 사용자 입장에서는 어딘가 모르게 굼뜨다는 인상을 받게 됩니다. 매 화면 이동마다 흰 화면이 순간적으로 노출되고 인터랙션도 어딘가 모르게 답답합니다.\n개발팀은 하던 일을 모두 중지하고 회의실에 모여 머리를 맞대고 대책을 강구하기 시작했습니다. 길고 긴 회의 끝에 기존의 방법을 버리고 Single Page Application(이하 SPA)으로 전면 개편이라는 선택지로 겁도 없이 손을 뻗었습니다. SPA 개발을 도와줄 도구로서 React와 Angular를 비교했고, 학습곡선이 낮고 좀 더 자유로운 방식으로 사용 가능한 React에 React-router를 곁들여 사용 …",
    "tags":      ["tech","react"]
  },
  {
    "title":     "삶은 무지개 색이어야 한다.",
    "permalink": "/life-with-rainbow-colors/",
    "date":      "2017년 07월 08일",
    "summary":   "아침부터 찌는 듯이 덥다가도 오후가 되니 거짓말처럼 폭우가 들이닥친다. 더운 공기가 물러간 것은 다행이지만 여전히 끈덕진 걸 보니 그래도 여름은 여름인 모양이다.\n사실 \u0026ldquo;여름\u0026quot;이라는 단어를 곱씹고 있자면 어쩐지 그리운 느낌이 스물스물 든다. 꼬맹이 시절 방학숙제는 내팽게쳐놓고 하루종일 산으로 들로 뛰댕기던 모습들, 열대야에 잠 못 이룰때 티비에서 보던 공포영화 같은 것들이 생각난다. 친구들과 자전거 한 대에 둘씩 타고는 30분을 걸려 계곡으로 물놀이를 가던 장면들, 근처 실내 수영장에서 입술이 파래지도록 놀고 나온 후 수영장 옆 문구사에서 사먹었던 컵라면 같은 것들이 스쳐간다.\n",
    "content":   "아침부터 찌는 듯이 덥다가도 오후가 되니 거짓말처럼 폭우가 들이닥친다. 더운 공기가 물러간 것은 다행이지만 여전히 끈덕진 걸 보니 그래도 여름은 여름인 모양이다.\n사실 \u0026amp;ldquo;여름\u0026amp;quot;이라는 단어를 곱씹고 있자면 어쩐지 그리운 느낌이 스물스물 든다. 꼬맹이 시절 방학숙제는 내팽게쳐놓고 하루종일 산으로 들로 뛰댕기던 모습들, 열대야에 잠 못 이룰때 티비에서 보던 공포영화 같은 것들이 생각난다. 친구들과 자전거 한 대에 둘씩 타고는 30분을 걸려 계곡으로 물놀이를 가던 장면들, 근처 실내 수영장에서 입술이 파래지도록 놀고 나온 후 수영장 옆 문구사에서 사먹었던 컵라면 같은 것들이 스쳐간다.\n그로부터 약 십여년이 지났고 내 삶은 많이도 변했다. 민증이 나오고 술, 담배를 합법적으로 하게 되었을 때도 어른이라는 자각은 그다지 없었지만 매달 내 통장을 스쳐 지나가는 대출이자를 보고 있자니 어른이란게 무언지 어렴풋이 알 것 같은 기분이다. 어느새 집에서 독립을 하니 주민등록등본 상에 엄마 아버지 이름이 없고 내가 세대주란다. 거기다 어찌어찌 결혼을 하고 나니 친구들은 나보고 이제 가장이란다. 삶이 참 많이도 변했다.\n나이를 한 살 두 살 먹을 때마다 \u0026amp;ldquo;산다\u0026amp;quot;는 것에 대해 새롭게 생각하게 된다. 입시란 걸 진지하게 준비하기 시작했던 시절부터 였을까, 당시의 나는 \u0026amp;ldquo;산다\u0026amp;quot;는 것은 무엇을 이루기 위해 준비해야 하는 과정 쯤으로 생각했던 것 같다. 어릴 때 엄마가 사주셨던 위인전 세트 때문 이었을까, 인서울을 했다던 학교 선배 이야기 때문 이었을까. 아니면 티비에 나오던 성공한 사람들의 화려한 삶의 단면 때문 이었을까.\n아침 8시까지 등교를 하고나면 밤 12시는 되어야 그 교문을 다시 나올 수는 있었다. 지겹고 답답했지만 버틸 만 했다. 끝이 분명히 있었고, 학교를 다니는 것 외에 삶을 즐겁게 만들 만한 취미도 딱히 없었으니까. 한달에 한번씩 치루는 모의고사 점수표가 일종의 당근과 채찍이 되어주었다. 원하는 대학에 진학을 하기 위한 “과정”을 그렇게 어찌어찌 버텨내었고 다행스럽게도 고3 겨울 수능날을 기점으로 그 길고 길었던 인내의 끝에 무사히 도달할 수 있었다.\n문득 지금의 삶과 비교를 해보게 된다. 지금도 나는 어딘가의 종착지에 닿기 위한 “과정”의 삶을 살고 있는걸까. 종착지로 삼기 좋은 것들은 차고 넘친다. 좋은 직장, 높은 연봉, 사회적인 명예나 좋은 차 같은 것들. 다소 속물스러운 늬앙스를 풍긴다는 점만 빼면 아주 매력적인 종착지 들이다. 고생스럽겠지만 페달을 밟아볼만 하다. 그 곳에 닿고 나면 삶은 행복해질테니까.\n아니, 삶은 행복해지지 않을 것이다.\n내일의 무언가를 위해 오늘을 희생하는 삶의 태도를 견지하는 이상, 내일도 다른 내일을 위해 희생될 수 밖에 없다. 목표했던 종착지에 닿았다고 생각했을 때에도 어느샌가 생겨버린 다른 종착지에 다시 닿기 위해 자전거에서 내릴 수 없을 것이다. 쉬지 않고 페달을 밟아야 한다. 아주 쉬운 이야기다. 삶이 행복해지기를 원한다면 그 시점은 내일이 아닌 오늘 이어야 한다.\n사실 이런 논리는 일과 삶의 균형에 대한 주제에 대해 이야기할 때 자주 나오는 흔한 클리셰다. 삶이 일이라는 괴물에 잡아먹히기 직전의 마지막 순간에서 모두가 하나같이 외치는 절규다. 또한 이런 외침을 반박하기 위한 논리 역시 어렵지 않게 찾아볼 수 있다. 사실 이 글을 쓰기 시작한 이유도 이와 관련이 있다.\n일이 삶이고 삶이 일인 사람들이 분명 있다. 그들에게 있어서 삶은 일에 잡아먹히는 성질의 것이 아니며 삶과 일이 자연스럽게 섞여있다. 특히 개발자들 사이에도 그런 사람들을 쉽게 찾아볼 수 있다. “좋아하는 일 = 잘 하는 일 = 돈이 되는 일” 정도가 되면 흔히들 덕업일치의 축복을 받았다고들 한다. 개인적으로 나는 이게 굉장히 큰 행운이라고 생각한다. 덕업일치가 안 되었더라면 나는 일찍히 개발자를 때려쳤겠지. 그렇게 되었다면 장사를 하고 있었을까. 그건 잘 모르겠다.\n현데 사람 산다는 게 또 참 어려운 것이, 덕업일치가 되는 단 몇가지의 즐거움 만으로 인생을 색칠 …",
    "tags":      ["daily"]
  },
  {
    "title":     "운전을 하고 싶다",
    "permalink": "/drive/",
    "date":      "2017년 05월 18일",
    "summary":   "운전을 하고 싶다. 틈 날때마다 생각한다. 참 희안한 것이, 운전면허를 따기전까지는 운전을 하고 싶다는 생각을 단 한번도 해본 적이 없다. 오히려 최대한 늦게 따야겠다고 다짐까지 했을 정도니까. 고3 수능이 끝나고 친구들이 하나 둘씩 운전면허 학원에 등록을 할때도, “저것들은 차도 없는 것들이 왜 벌써부터 면허를 따려고 하나” 생각하며 알바 하기에 바빴고, 친구들과 여행을 가면 장거리 운전으로 피곤해 하는 친구에겐 미안하지만 (빈말이다. 사실 별로 미안하지도 않았다.) 뒷자리에서 편히 쉬면서 갈 수 있음을 즐기기도 했다. 지금 가지고 있는 운전면허도 아내와 제주도 여행을 앞두고 급하게 딴 것이다. 제주도에선 차가 없으면 불편하다는 아내의 성화가 없었다면 아마 높은 확률로 지금도 무면허였을 것이다.\n",
    "content":   "운전을 하고 싶다. 틈 날때마다 생각한다. 참 희안한 것이, 운전면허를 따기전까지는 운전을 하고 싶다는 생각을 단 한번도 해본 적이 없다. 오히려 최대한 늦게 따야겠다고 다짐까지 했을 정도니까. 고3 수능이 끝나고 친구들이 하나 둘씩 운전면허 학원에 등록을 할때도, “저것들은 차도 없는 것들이 왜 벌써부터 면허를 따려고 하나” 생각하며 알바 하기에 바빴고, 친구들과 여행을 가면 장거리 운전으로 피곤해 하는 친구에겐 미안하지만 (빈말이다. 사실 별로 미안하지도 않았다.) 뒷자리에서 편히 쉬면서 갈 수 있음을 즐기기도 했다. 지금 가지고 있는 운전면허도 아내와 제주도 여행을 앞두고 급하게 딴 것이다. 제주도에선 차가 없으면 불편하다는 아내의 성화가 없었다면 아마 높은 확률로 지금도 무면허였을 것이다.\n헌데 운전이 하고 싶다. 참으로 이상스런 일이 아닐 수 없다. 택시 앞자리에 앉으면 전방의 차들과 차선을 째려보며 마치 내가 운전을 하는 양 몰입을 하게 된다. 어쩌다 한번씩 고향에 내려가 엄마 차를 몰게 되기라도 하면 몇 시간이고 지치지 않고 여기, 또 저기로 쏘다니기 바쁘다. 이전까지는 몰랐다. 마음만 먹으면 언제든, 또 어디로든 갈 수 있다는 말이 주는 설렘을 전혀 알지 못했다. 아주 설레다 못해 명치께가 간질거리기까지 한다.\n2주 후에 계획된 제주도 여행에서도 관광 명소라던가, 맛집이라던가, 여행지에서의 멋진 숙소 같은 건 머릿 속에 들어오지도 않는다. 그저 운전할 일을 생각하며 설렌다. 해안 도로를 달리고, 그러다 배가 고파지면 맛집을 찾아다가 네비에 찍고 그대로 달리는, 그런 것들을 상상하게 된다. 참으로 이상한 일이 아닐 수 없다.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "mariadb multi source replication",
    "permalink": "/mariadb-multi-source-replication/",
    "date":      "2017년 04월 28일",
    "summary":   "multi source replication 절차 slave가 될 mysql 인스턴스의 설정에 아래의 부분을 추가한다.\n# /etc/mysql/maridb.conf.d/50-server.cnf [mysqld] server_id=19823759 # master와 겹치지 않게 replicate-ignore-db=mysql # mysql 데이터베이스는 복제하지 않음 master 데이터베이스에서 replication 용 계정 생성 후 권한을 부여한다\ngrant replication slave on *.* to ‘repl’@‘%’ identified by ‘!repl123’; mysqldump 를 이용해서 master가 될 데이터베이스에서 덤프를 받는다.\nmysqldump --databases database_1 database_2 --single_transaction --master-data=1 -h host_path -u account -p \u0026gt; dump.sql 락이 걸리는 걸 방지하기 위해 —single-transaction 옵션 추가해야 하며, 덤프를 받은 시점의 binlog 파일과 포지션을 확인하기 위해 —master-data=1 옵션 추가한다. 그러면 덤프 파일 상단에 change master … 구문이 생성되는데 multi source 로부터 replication 을 받아야 하기 때문에 아래와 같이 수정해준다.\n",
    "content":   "multi source replication 절차 slave가 될 mysql 인스턴스의 설정에 아래의 부분을 추가한다.\n# /etc/mysql/maridb.conf.d/50-server.cnf [mysqld] server_id=19823759 # master와 겹치지 않게 replicate-ignore-db=mysql # mysql 데이터베이스는 복제하지 않음 master 데이터베이스에서 replication 용 계정 생성 후 권한을 부여한다\ngrant replication slave on *.* to ‘repl’@‘%’ identified by ‘!repl123’; mysqldump 를 이용해서 master가 될 데이터베이스에서 덤프를 받는다.\nmysqldump --databases database_1 database_2 --single_transaction --master-data=1 -h host_path -u account -p \u0026amp;gt; dump.sql 락이 걸리는 걸 방지하기 위해 —single-transaction 옵션 추가해야 하며, 덤프를 받은 시점의 binlog 파일과 포지션을 확인하기 위해 —master-data=1 옵션 추가한다. 그러면 덤프 파일 상단에 change master … 구문이 생성되는데 multi source 로부터 replication 을 받아야 하기 때문에 아래와 같이 수정해준다.\nCHANGE MASTER \u0026amp;#39;master_name\u0026amp;#39; TO master_host=\u0026amp;#39;host_path\u0026amp;#39;, master_user=\u0026amp;#39;account\u0026amp;#39;, master_password=\u0026amp;#39;password\u0026amp;#39;, master_port=3306, MASTER_LOG_FILE=\u0026amp;#39;mysql-bin-changelog.052616\u0026amp;#39;, MASTER_LOG_POS=886626; # dump에 기록된 그대로 유지 만약 덤프 파일이 너무 커서 수정하기가 힘든 경우 아래와 같이 파일을 잘라서 수정한 후에 합치는 방법을 사용할 수 있다.\nhead -n 30 dump.sql \u0026amp;gt; new_dump.sql vim new_dump.sql tail -n +30 dump.sql \u0026amp;gt;\u0026amp;gt; new_dump.sql slave가 될 데이터베이스에 덤프를 밀어넣는다.\nmysql -h hostpath -u account -p database_name \u0026amp;lt; dump.sql 여기서 database_name은 덤프 내 여러개의 데이터베이스가 담겨 있다고 해도 그 중 하나만 지정해도 되지만 지정된 데이터베이스는 미리 생성되어 있어야 한다.\nreplication 스레드를 시작시킨다:\nstart slave \u0026amp;#39;master_name\u0026amp;#39; 기타 유의사항 replication 설정을 위해서는 super previleges가 필요한데 aws rds를 이용하면 일반 사용자가 super previleges를 가질 수 없다. binary log가 너무 빨리 rotate 되는 경우에는 아래와 같이 retention 값을 확인 및 조정할 수 있다. call mysql.rds_show_configuration() 으로 binlog retention hours 값 확인 call mysql.rds_set_configuration(‘binlog retention hours’, 1); ",
    "tags":      ["tech","mariadb"]
  },
  {
    "title":     "Too many open files",
    "permalink": "/too-many-open-files/",
    "date":      "2017년 04월 25일",
    "summary":   "집에서 기타치면서 놀고 있었는데 외출했던 아내가 귀가중이라는 메시지를 받았다. 집 앞 지하척 역으로 마중나가려고 핸드폰을 챙겨서 나가려는데 슬랙 메시지가 뭐가 많이 와있다. 평소 팀에서 커뮤니케이션을 슬랙으로 하기 때문에 별 생각없이 슬랙 메시지들을 확인해보고 있는데 서버쪽에 장애가 날 때 메시지가 오는 채널에 몇개의 메시지가 와있다. 순간 심장이 덜컹하며 확인해보니 몇가지 종류의 에러메시지가 꽤 여러번 발생한 형태다.\n첫번째 에러는 too many open files 두번째 에러는 unable to find server blabla\n두번째 에러로그는 심지어 디비서버를 못찾는다는 에러메시지! 디비 서버를 못찾았다면 서비스 자체가 안될텐데. 마음을 졸이며 우리 서비스에 들어가보니 일단 접속도 잘 되고 데이터 로딩도 문제없이 된다. 그렇다면 사태는 일단락 되었다는 이야긴데..\n",
    "content":   "집에서 기타치면서 놀고 있었는데 외출했던 아내가 귀가중이라는 메시지를 받았다. 집 앞 지하척 역으로 마중나가려고 핸드폰을 챙겨서 나가려는데 슬랙 메시지가 뭐가 많이 와있다. 평소 팀에서 커뮤니케이션을 슬랙으로 하기 때문에 별 생각없이 슬랙 메시지들을 확인해보고 있는데 서버쪽에 장애가 날 때 메시지가 오는 채널에 몇개의 메시지가 와있다. 순간 심장이 덜컹하며 확인해보니 몇가지 종류의 에러메시지가 꽤 여러번 발생한 형태다.\n첫번째 에러는 too many open files 두번째 에러는 unable to find server blabla\n두번째 에러로그는 심지어 디비서버를 못찾는다는 에러메시지! 디비 서버를 못찾았다면 서비스 자체가 안될텐데. 마음을 졸이며 우리 서비스에 들어가보니 일단 접속도 잘 되고 데이터 로딩도 문제없이 된다. 그렇다면 사태는 일단락 되었다는 이야긴데..\n그렇다고 손놓고 다시 기타나 뚱기뚱기할 수는 없으니 다시 로그를 뒤진다. was 로그와 syslog 등등을 종합적으로 뒤지고 수상해보이는 놈들은 죄 구글링을 해봤지만 별게 안나왔다. 할 수 없이 에러로그에 집중해보니, 일단 too many open files가 먼저 나고 그 다음에 디비서버를 못찾았다. 혹시나 싶어 로드밸런서에 물려있는 다른 서버를 확인해봤는데 다른 서버는 문제가 없었다. 그렇다면 실제 디비서버가 나가리가 되었다거나 한 문제는 아니라고 볼 수 있겠다고 생각했다.\n일단 too many open files가 떠있으니 ulimit 을 확인해주는데, 어라? 1024? 왜 이렇게 값이 작지?\n찬찬히 머리속에서 히스토리들을 뒤져보는데 한달전쯤 was를 변경했고 was가 변경되면서 리눅스 계정이 바꼈고 바뀐 리눅스 계정에 대해서 ulimit 값을 변경\u0026amp;hellip;.을 안해줬구나. 아\u0026amp;hellip;\n",
    "tags":      ["tech","trouble shooting"]
  },
  {
    "title":     "아닌 밤중에 리퀘스트가 튄다?",
    "permalink": "/weird-requests/",
    "date":      "2017년 04월 25일",
    "summary":   "신규 서비스를 오픈하면서 서버 모니터링을 위해 aws cloudwatch를 사용하게 되었다. 원래는 cloudwatch와 newrelic 을 모두 선택지에 올려놓고 마지막까지 고민을 했다. newrelic 쪽이 기능도 많고 레퍼런스도 확실했지만 일부 서버에서 agent의 설치가 안되는 문제가 있었다. 사실 agent 설치 안되는 문제야 조금 더 시간을 들여서 파보면 해결할 수 있는 문제였겠지만 당장에 서비스 오픈을 코앞에 둔 상황에서 시간적인 여유가 부족했고, cloudwatch도 우리가 필요한 기능을 대부분 제공하고 있었기 때문에 cloudwatch로 가기로 했다.\ncpu, 메모리, 디스크 사용량 등의 지표를 대시보드로 구성해놓고 며칠 모니터링하고 있으려니까 좀 이상한 현상이 눈에 띄었다.\n",
    "content":   "신규 서비스를 오픈하면서 서버 모니터링을 위해 aws cloudwatch를 사용하게 되었다. 원래는 cloudwatch와 newrelic 을 모두 선택지에 올려놓고 마지막까지 고민을 했다. newrelic 쪽이 기능도 많고 레퍼런스도 확실했지만 일부 서버에서 agent의 설치가 안되는 문제가 있었다. 사실 agent 설치 안되는 문제야 조금 더 시간을 들여서 파보면 해결할 수 있는 문제였겠지만 당장에 서비스 오픈을 코앞에 둔 상황에서 시간적인 여유가 부족했고, cloudwatch도 우리가 필요한 기능을 대부분 제공하고 있었기 때문에 cloudwatch로 가기로 했다.\ncpu, 메모리, 디스크 사용량 등의 지표를 대시보드로 구성해놓고 며칠 모니터링하고 있으려니까 좀 이상한 현상이 눈에 띄었다.\n일부 서버에서 주기적으로 network out이 튀고 있었다. 시간도 정확하게 6시 반쯤에 시작해서 11시에는 정상으로 돌아왔다. 제일 먼저 해당 서버에서 주기적으로 스케쥴링되어 돌고 있는 태스크가 있는지 확인했다. 하지만 스케쥴이 걸려있는 태스크라고는 cloudwatch 메트릭 값을 수집하는 agent 뿐이었고 이 에이전트도 5분마다 한번씩 실행되도록 구성되어 있었기 때문에 용의선상에서 벗어났다. 그외에 여러 의심되는 부분들을 샅샅이 뒤져봤으나 애초에 해당 서버는 aws s3에 있는 데이터들을 변환해 던져주는 역할만 하는 심플한 서버였기 때문에 원인을 진단하기가 어려웠다. network out이 튀는 정도가 분당 평균 5mb 근처였기 때문에 당장 서비스 운영에 문제를 줄만한 사안이 아니었고 이 문제 말고도 긴급을 요하는 태스크들이 많았기 때문에 자연히 칸반 보드의 todo list 어딘가로 해당 이슈는 쳐박히게 되었다.\n문제는 다른 부분에서 다시 일어났다. 이 서버의 메모리 사용량이 슬금슬금 눈치채지 못할 정도로 느리게 증가하고 있었다. 최초 기동시에는 6퍼센트 정도에서 머물던 것이 시간이 지남에 따라 50%를 넘어 70%를 넘보는 수준까지 도달한 것이었다. 그때 팀원 중 한명이 s3fs를 의심하기 시작했다. 이 서버는 s3에 있는 데이터를 서빙하기 위해서 s3fs 라는 오픈소스를 이용해서 s3 특정 버킷을 가상으로 마운트 시켜놓고 쓰고 있었다. s3fs 프로젝트의 issue란을 뒤져보니 memory leak이 있다는 issue가 유난히 많았다. 팀 내부에서도 s3fs의 memory leak bug로 인한 현상으로 추정하고 옵션값 튜닝을 더 해보고 안되면 s3fs 대신 goofys 라는 솔루션으로 넘어가기로 했다. 하지만 그대로 s3fs의 memory leak bug 라고 단정해버리기엔 좀 찜찜한 것이, github issue에 올라온 memory leak 리포트들은 대부분 수십분에서 수 시간 내로 서버의 메모리를 모두 잡아먹고 뻗어버리는 현상이 발생했던 것과는 달리 우리 서버는 2주째 메모리 사용량을 야금야금 먹으면서 올라오긴 했지만 서버의 메모리를 모두 잡아먹진 않았다. 조금 더 살펴보기로 했다.\n일단 좀 더 정확한 정황을 확인하기 위해 s3fs의 디버그 로그 옵션을 켜고 다시 재기동하였다. syslog에 어마어마한 양의 로그가 쌓이기 시작했다. 양 자체가 워낙에 많에 전수조사를 할 수는 없었지만 일단 일부 확인한 내용으로는 이상해보이는 로그는 보이지 않았다. 그렇게 주말을 보내고 월요일 아침 다시 로그를 확인해보았다. 이 때 였다. 의심스러운 로그가 눈에 들어오기 시작했다.\n매일 아침 6시 25분마다 s3fs에 의해서 가상 마운트되어 있는 폴더 아래 모든 오브젝트들을 하나씩 순회하는 로그들이 찍혀있었다. 해당 s3 bucket에는 수만개 이상의 오브젝트들이 존재하고 있기 때문에 이 순회 작업은 수시간 후에야 끝났다. 그 때 잊고 있었던 네트워크 튐 현상이 떠올랐다. network out 지표에도 매일 아침 6시 반부터 11시 까지 그래프가 튀어 있었고 s3fs 로그에서는 그 시간대에 bucket내 모든 오브젝트들을 순회하는 로그가 찍혀있었다. 즉, s3fs 마운트 폴더에서의 순회요청은 그대로 디스크를 뒤지는 것이 아니라 …",
    "tags":      ["tech","trouble shooting"]
  },
  {
    "title":     "겹겹의 공간들",
    "permalink": "/spaces/",
    "date":      "2017년 04월 25일",
    "summary":   " 일상에서 우리가 기억이라고 부르는 것도 공간화한 기억이다. 프루스프가 \u0026ldquo;읽어버신 시간을 찾아서\u0026quot;에서 끊임없이 유년의 마을과 길과 집과 방들을 소환하는 까닭도, 추억이란 게 벌집 같은 공간 속에 특정의 시간들을 압축-공간화하고 있기 때문이다. 바슐라르가 \u0026ldquo;공감의 시학\u0026quot;에서 한 말처럼 \u0026ldquo;기억을 생생하게 하는 것은 시간이 아니라 공간이다. 우리들이 오랜 머무름에 의해 구체화된 지속의 아름다운 화석들을 발견하는 것은, 공간에 의해서, 공간 가운데서인 것이다\u0026rdquo;\n그러고보니, 추억이라는 것들을 하나둘씩 들여다보면 시간과 사람들, 그때 했던 생각이나 가졌던 감정들, 표정과 분위기같은 것들은 희끄무레하니 기억이 잘 나지 않는 반면에 공간만큼은 선명하게 기억이 난다. 생각보다 공간이라는 의미는 인간에게 이리도 푸대접받을 만한 작은 의미가 아닌걸까. 우리의 공간에 대한 인식이 이리 뚜렷한 이유가 뭘까.\n",
    "content":   " 일상에서 우리가 기억이라고 부르는 것도 공간화한 기억이다. 프루스프가 \u0026amp;ldquo;읽어버신 시간을 찾아서\u0026amp;quot;에서 끊임없이 유년의 마을과 길과 집과 방들을 소환하는 까닭도, 추억이란 게 벌집 같은 공간 속에 특정의 시간들을 압축-공간화하고 있기 때문이다. 바슐라르가 \u0026amp;ldquo;공감의 시학\u0026amp;quot;에서 한 말처럼 \u0026amp;ldquo;기억을 생생하게 하는 것은 시간이 아니라 공간이다. 우리들이 오랜 머무름에 의해 구체화된 지속의 아름다운 화석들을 발견하는 것은, 공간에 의해서, 공간 가운데서인 것이다\u0026amp;rdquo;\n그러고보니, 추억이라는 것들을 하나둘씩 들여다보면 시간과 사람들, 그때 했던 생각이나 가졌던 감정들, 표정과 분위기같은 것들은 희끄무레하니 기억이 잘 나지 않는 반면에 공간만큼은 선명하게 기억이 난다. 생각보다 공간이라는 의미는 인간에게 이리도 푸대접받을 만한 작은 의미가 아닌걸까. 우리의 공간에 대한 인식이 이리 뚜렷한 이유가 뭘까.\n",
    "tags":      ["daily"]
  },
  {
    "title":     "이직 면접 이야기",
    "permalink": "/job-interview/",
    "date":      "2016년 08월 25일",
    "summary":   "직장인이 이직 면접을 준비하면서 받는 스트레스가 이혼을 할 때 받는 스트레스와 비슷하다는 이야기를 들은 적이 있다. 글쎄, 내 경우에 비추어보면 조금 과장되다 싶게 느껴지는 이야기긴 하지만, 그만치 감당해야 할 부담이 상당하다는 점에서는 공감을 하게 된다. 면접이 거듭될 때마다 자존감이 손바닥 위 모래처럼 사그러들고, 나는 지금까지 뭐하고 살아왔나 하는 인생 전반에 대한 후회를 하게 되는 것이, 이거 오래 준비하다간 내 명에 못살지 싶었다. 회사 입장에서는 심플하게 충원하려는 자리에 맞지 않아서 퇴짜를 놓았다지만 지원자는 난 역시 이 정도밖에 안되는 인간인가 하는 자괴감을 느끼게 되는 것이다.\n",
    "content":   "직장인이 이직 면접을 준비하면서 받는 스트레스가 이혼을 할 때 받는 스트레스와 비슷하다는 이야기를 들은 적이 있다. 글쎄, 내 경우에 비추어보면 조금 과장되다 싶게 느껴지는 이야기긴 하지만, 그만치 감당해야 할 부담이 상당하다는 점에서는 공감을 하게 된다. 면접이 거듭될 때마다 자존감이 손바닥 위 모래처럼 사그러들고, 나는 지금까지 뭐하고 살아왔나 하는 인생 전반에 대한 후회를 하게 되는 것이, 이거 오래 준비하다간 내 명에 못살지 싶었다. 회사 입장에서는 심플하게 충원하려는 자리에 맞지 않아서 퇴짜를 놓았다지만 지원자는 난 역시 이 정도밖에 안되는 인간인가 하는 자괴감을 느끼게 되는 것이다.\n개인적인 경험에 빗대어 봤을 때, 긴장이 풀리면 면접이 잘 풀렸었다. 어느 순간부터 \u0026amp;ldquo;지금 면접관이 날 어떻게 생각하고 있을까\u0026amp;quot;하는 생각이 머릿 속에서 사라지고, \u0026amp;ldquo;말빨\u0026amp;quot;이 터져 진짜 내가 누군지를 여실히 떠들고나면 면접관들 입가에서 만족스런 미소를 여볼 수 있었다. 반대로 시작부터 긴장된 상태로 면접에 돌입하고, 지금 내가 긴장을 하고 있다는 사실을 수시로 확인하며 긴장은 더욱 더 증폭이 되고, 이쯤되면 면접관의 간단한 질문도 도저히 한국말로는 안들리게 되는 것이다. 질문을 듣고 고심하는 척 미간을 찌푸리지만 이미 머릿속은 백지다. 그리고 \u0026amp;ldquo;지금 머릿속이 백지구나\u0026amp;quot;라고 한번 더 되뇌이는 순간 사고는 정지되고 등 뒤로는 식은 땀이 흐른다.\n그래도 면접은 내게 대부분 즐거운 경험이었다. 실패에 대한 리스크가 작지 않다는 점에서 뭔가 위험천만한 스릴 같은 것들이 느껴지기도 했다. 면접을 준비하면서 \u0026amp;ldquo;나는 이렇게 이런걸 쌓아왔어. 난 괜찮은 놈이야\u0026amp;quot;라고 자기 최면을 걸고, 면접 당일에는 내 자신에 대한 이야기를 한시간에서 두시간 가량 마음껏 늘어놓을 수 있으니 두려움만 떨치면 이건 즐거운 경험이었다. 나는 말이 많은 편은 아니지만 자기 표현에 대한 욕구는 많은 사람이었다. \u0026amp;ldquo;나는 이런 사람입니다, 이렇게 살아왔구요, 이런 것들을 중요하게 생각합니다.\u0026amp;rdquo; 하고 떠들고 있다 보면 오랜 친구와 술에 거나하게 취해 인생이 어쩌고 하는 개똥철학을 주고 받는 장면을 떠올리게 한다.\n아쉬운 것은, 신입으로 경력을 쌓고 경력직으로 면접을 준비하게 되면 더이상 내 자신에 대한 이야기 보다는 내가 쌓아온 경험에 대해 이야기해야 하는 시간이 더 많았다. 하지만 이것 또한 나쁘지 않은 것이, 신입 시절 운좋게 내가 좋아할 수 있는 직무를 맡게 되면서 즐겁게 공부하고 경험해온 것들을 떠들 수 있어서 좋았다.\n면접 준비를 하고 면접에 떨어지고 나면 내가 가야할 길들이 좀 더 명확하게 느껴지곤 한다. 내가 가고싶은 회사, 가고싶은 직무의 구직공고에 붙어 있는 기본 요건과 우대 사항들을 보면서 앞으로 내가 공부해 나가야 될 청사진들을 대략적으로 잡을 수 있었고, 면접을 거친 후 내가 대답할 수 있었던 질문과, 대답하지 못했던 질문들을 다시 헤아리며 내가 지금 서있는 위치와 부족한 부분들을 객관적으로 알 수 있었다.\n그렇게 면접 준비와 면접 과정을 거쳐 지금 회사로 이직을 하게 되었고 꽤 만족스럽다고 생각하고 있다. 결과적으로 가고 싶은 회사, 하고 싶은 직무를 맡을 수 있었고, 원하는 조직 문화를 체험하게 됐으며, 똑똑한 사람들과 더 재미있는 일들을 할 수 있게 되었다. 이 회사에 평생 몸담을 수 있다면 그것도 그것 나름대로 좋겠지만 나는 아마 또 이직 준비를 해야 할 시기를 맞게 될 것이다. 하지만 이직을 준비하고 이직을 하게 되는 경험들이 크게 보면 나를 계속해서 채찍질하여 성장하게 만든다고 생각한다.\n",
    "tags":      ["career"]
  }
]