<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
    <title>Bullshitting Blog</title>
    <subtitle>개소리하는 블로그</subtitle>
    <link rel="self" type="application/atom+xml" href="https://xanthorrhizol.github.io/atom.xml"/>
    <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io"/>
    <generator uri="https://www.getzola.org/">Zola</generator>
    <updated>2026-04-25T00:00:00+00:00</updated>
    <id>https://xanthorrhizol.github.io/atom.xml</id>
    <entry xml:lang="en">
        <title>인프라 엔지니어</title>
        <published>2026-04-25T00:00:00+00:00</published>
        <updated>2026-04-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/infra-engineer/"/>
        <id>https://xanthorrhizol.github.io/posts/infra-engineer/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/infra-engineer/">&lt;p&gt;어제는 100G 네트워크에서 인터페이스 설정을 하는 팁을 팀장님으로부터 전수받았다. 신규 클러스터에도 적용되지 않은 부분들이 있었는데, 다음주에 마저 반영할 예정이다.&lt;br &#x2F;&gt;
손에 잡히는 일, 입사할 때부터 원래 하고 싶었던 일, 낮은 레이어에서 직접 개념을 조립하고 계산할 수 있는 일. 그게 지금 일이다. 코드 스타일이 어쩌고 저쩌고 자기 맘대로 평가할 수 있는 영역도 아니다. 되면 되는 것. 안되면 안되는 것일 뿐이다.&lt;br &#x2F;&gt;
게다가 금융쪽은 속도가 생명과 같다. HFT 영역에서는 어디가 병목인지를 세부적으로 찾아내서 요청을 하신다. 어제도 그 병목을 해결하기 위한 작업을 하면서 네트워크 관련된 배움을 얻은 것이다. (그리고 앞으로는 신규 서버를 구성할 때 병목이 발생하지 않도록 미리 신경을 써야겠다.)&lt;br &#x2F;&gt;
물론 스타트업에 다니고 있기 때문에 인프라만 하지는 않는다. DevOps 영역도 손을 댄다. 근데, 일에 집중이 잘 안될 때 최고의 처방은 인프라 일을 하는 것이다. 그중 데이터센터에 가는게 제일 좋다. 서버 팬이 돌아가서 소리가 시끄럽지만 묘하게 집중이 된다.&lt;br &#x2F;&gt;
뭐, 그냥 회사 밖을 나서는 것이니 당연히 좋은 것일 수도 있다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>눈물이 그냥 올라옴</title>
        <published>2026-04-25T00:00:00+00:00</published>
        <updated>2026-04-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/tears/"/>
        <id>https://xanthorrhizol.github.io/posts/tears/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/tears/">&lt;p&gt;정신과 진료를 받기 시작한지 5개월쯤 되었다. 2월엔 심리검사를 받게 되었다. 그리고 3월쯤엔 상황이 좋아져서 약을 테이퍼링하기 시작했다.&lt;br &#x2F;&gt;
그리고 또 무너졌다. 피로가 심하게 몰려왔다. 아침에 하던 웨이트도 갈 수가 없었다. 퇴근 후 집에 돌아오면 아무 것도 할 수가 없었다. 하루 연차를 내고 그냥 아무 것도 안하고 하루 종일 누워 있기도 했다. 그때 무너지기 전에 만들었던 그릭요거트가 지금 분홍색 곰팡이가 핀 채 냉장고에 밀봉 상태로 들어가 있다. 계란도 유통기한이 2주나 지났다. 처리하는데 애를 좀 먹을 예정이다.&lt;br &#x2F;&gt;
여튼 이번주 월요일 진료 때 그걸 알렸다. 약 용량은 원복됐다. 그런데, 의사가 갑자기 &quot;힘드시죠?&quot;라고 물어봤다. 갑자기 눈물이 핑 돌았다. 그 이후, 매일 귀가 후 한 번씩 집에서 눈물이 그냥 갑자기 올라온다. 흐르기도 한다. 6일째다. 무슨 상황인지 모르겠다. 당황스럽다. 그렇다고 그냥 방문 부수고 나오는걸 못나오게 할 방법도 없다. 밖에서 안나오는게 어디인가 하고 그냥 지내고 있다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>다운됐다</title>
        <published>2026-04-18T00:00:00+00:00</published>
        <updated>2026-04-18T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/down/"/>
        <id>https://xanthorrhizol.github.io/posts/down/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/down/">&lt;p&gt;말 그대로 다운됐다. 운동도 시작했고 해서 약을 테이퍼링하던 중이었다. 저번 한 달은 잘 버텼는데, 이번 테이퍼링은 못버틴 것 같다. 말 그대로 다운됐다.&lt;br &#x2F;&gt;
서서히 아침에 가던 운동도 힘들어지더니, 갑자기 수면이 흔들렸고, 악몽도 꿨다. 자도 자도 피곤했다. 그래서 이번주는 아예 수요일에 휴가를 내고 하루 종일 집에서 누워 있었다.&lt;br &#x2F;&gt;
출근을 했는데도 각성이 올라오지 않고 피로가 떠나가지 않았다. 특히 컨택스트 스위칭이 평소보다 배는 힘들었다. 서버실이라도 가면 왠지 사고가 날 것 같은 기분이 들어 엄청 조심조심 움직였다. 내 고유수용감각(내 몸의 속도, 위치 등을 느끼는 감각)을 믿지 않고 내 손 발의 움직임을 눈으로 다 확인하며 움직였다.&lt;&#x2F;p&gt;
&lt;p&gt;오늘은 엄마가 집에 오셨다. 날씨가 좋다고 날 공원에 끌고가 같이 산책을 했다. 훨씬 나아졌다. 엄마가 되돌아가고 난 후, 쓰레기도 비우고, 차에 기름도 넣고 세차도 하고 왔다. 하지만 곧 에너지는 바닥이 났다. 임진각까지 드라이브를 가려고 했지만, 지하철역 한 개 지나자마자 그럴 마음이 사라져서 집으로 돌아왔다.&lt;br &#x2F;&gt;
월요일에 병원을 가므로, 지금의 문제는 곧 해결될 듯 하다. 그리고, 내일도 산책을 가야겠다. 오늘보단 덜 걸을 예정이다. 환갑이 다 되어 가는 엄마가 나보다 건강한 것 같다. 뭐 좋은 일이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>brainfuck-generator</title>
        <published>2026-04-05T00:00:00+00:00</published>
        <updated>2026-04-05T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/brainfuck-generator/"/>
        <id>https://xanthorrhizol.github.io/posts/brainfuck-generator/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/brainfuck-generator/">&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;xanthorrhizol&#x2F;brainfuck-generator&quot;&gt;brainfuck-generator&lt;&#x2F;a&gt;&lt;br &#x2F;&gt;
맞다. 만들었다. 하찮고 재밌다.&lt;br &#x2F;&gt;
슉랭에 대해 접한지 1-2년쯤 지났다. 설렌다 해놓고 건드리지는 않았다. 삘이 안왔기 때문이다. 그러다가 오늘 왔다.&lt;br &#x2F;&gt;
이번주는 몸이 좋지 않아서 운동도 두 번이나 쨌다. 머리도 잘 안돌았다. 그러다 오늘 괜찮아지면서 갑자기 심심함을 느끼고, 슉랭이 생각난 것이다. 하지만 슉랭만 구현하면 너무 지엽적인 부분만 커버하는 느낌이 들어서, 그냥 brainfuck을 구현한 후, 슉랭과 같은 아류작을 지원하도록 만들기로 했다.&lt;&#x2F;p&gt;
&lt;p&gt;Claude랑 핑퐁하면서 개발을 했다. 순전히 재미를 위해 하는 것이므로, 코드는 내가 짰다. 코드를 짜다가, &#x27;.(출력)&#x27;이라는 명령을 뒤늦게 알았다. 이걸 알고 나니 갑자기 머리속이 정렬했다. &#x27;출력을 매 글자 마다 찍는거면... 앞에꺼 재활용해도 되잖아???&#x27; 그렇게 최적화가 한 번 일어났다. 그 전엔 그냥 제곱근과 반복문을 이용해서 + 출력을 줄이는 방법만 적용되어 있었는데 말이다. 이외에도 또다른 최적화가 많을 것 같다. 당장 반복문만 해도 depth를 늘릴 수 있다. 세제곱근을 이용한다던가 하는 것이다. 그리고, 앞 글자로부터의 diff를 구하는 방법 대신, 128부터 시작해도 된다. 128은 2^7이므로, 2^2 * 2^2 * 2^3 =&amp;gt; &quot;++++[&amp;gt;++++[&amp;gt;++++++++&amp;lt;-]&amp;lt;-]&amp;gt;&amp;gt;.&quot;이다. 손으로 빚어내 보니, 또 묘하게 재미가 있다. 후회되지 않는 뻘짓 목록에 들어갈 것 같다.&lt;&#x2F;p&gt;
&lt;p&gt;아 세제곱근 이야기 해놓고 직접 손으로 쓰고 나니, 구현해보고 싶어졌다. 세제곱근이 의미가 있으려면, 글자수를 기준으로 해야 할 것 같은데, 대충 8부터 놓고 해보자.&lt;br &#x2F;&gt;
8 = &quot;++++++++.&quot;(9글자) vs &quot;++[&amp;gt;++-]&amp;gt;++++.&quot;(13글자) vs &quot;++[&amp;gt;++[&amp;gt;++&amp;lt;-]&amp;lt;-]&amp;gt;&amp;gt;.&quot;(19글자)&lt;br &#x2F;&gt;
27 = &quot;+++++[&amp;gt;+++++&amp;lt;-]&amp;gt;++.&quot;(19글자) vs &quot;+++[&amp;gt;+++[&amp;gt;+++&amp;lt;-]&amp;lt;-]&amp;gt;&amp;gt;.&quot;(22글자)&lt;br &#x2F;&gt;
64 = &quot;++++++++[&amp;gt;++++++++&amp;lt;-]&amp;gt;.&quot;(23글자) vs &quot;++++[&amp;gt;++++[&amp;gt;++++&amp;lt;-]&amp;lt;-]&amp;gt;&amp;gt;.&quot;(25글자)&lt;br &#x2F;&gt;
125 = &quot;+++++++++++[&amp;gt;+++++++++++&amp;lt;-]&amp;gt;++++.&quot;(33글자) vs &quot;+++++[&amp;gt;+++++[&amp;gt;+++++&amp;lt;-]&amp;lt;-]&amp;gt;&amp;gt;.&quot;(28글자)&lt;&#x2F;p&gt;
&lt;p&gt;64부터 슬슬 역전하기 시작했다. 그럼, 영문자부터는 사실상 세제곱을 쓰는 쪽이 유리하다. 근데 굳이 그렇게 영문자니 뭐니 할 필요 없이, 64를 기준으로 해도 된다. 그렇게 해서 방금 글 쓰다가 또 커밋했다. 디코딩 다 깨졌다가 고쳐져서 정상적인 문자열 나오는 순간의 쾌감이 장난 아니다.&lt;&#x2F;p&gt;
&lt;p&gt;이제 진정하고 약먹고 잠이나 자야겠다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>체력</title>
        <published>2026-04-02T00:00:00+00:00</published>
        <updated>2026-04-02T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/endurance/"/>
        <id>https://xanthorrhizol.github.io/posts/endurance/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/endurance/">&lt;p&gt;체력이 낮으니 문제가 되는걸 발견했다. 가벼운 감기인데 피로가 심하고 머리도 잘 안돈다.&lt;br &#x2F;&gt;
그래서 글도 여기서 끝.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>AI의 작업을 따로 표현하기</title>
        <published>2026-03-25T00:00:00+00:00</published>
        <updated>2026-03-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/identity-of-ai-works/"/>
        <id>https://xanthorrhizol.github.io/posts/identity-of-ai-works/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/identity-of-ai-works/">&lt;p&gt;AI와의 작업물이 내 작업물인지 아닌지에 대한 고민이 끝났다.&lt;br &#x2F;&gt;
결론은, &quot;그냥 구분하면 그만이다&quot;이다.&lt;br &#x2F;&gt;
힌트는 openclaw였다.&lt;br &#x2F;&gt;
openclaw에게 하드웨어 전권을 넘겨주는 대신, 모든 계정까지 따로 만들어서 줬던 것이 힌트였다.&lt;br &#x2F;&gt;
결국 openclaw는 자기가 한 작업물을 자기 계정을 이용해서 커밋한다.&lt;&#x2F;p&gt;
&lt;p&gt;마침 openclaw가 갈수록 보안 문제로 인해 기능이 줄어들고, 토큰만 많이 먹는 점이 마음에 들지 않았던 참이다.&lt;br &#x2F;&gt;
올라가 있던 라즈베리파이를 초기화한 후 claude를 설치했다.&lt;br &#x2F;&gt;
그리고 집에 구축한 nas에 디렉터리를 파서 nfs 마운트를 한 후 그 workspace에서 cluade를 실행했다.&lt;br &#x2F;&gt;
그리고 그 claude에도 openclaw가 들고 있던 계정들을 연동했다.&lt;&#x2F;p&gt;
&lt;p&gt;이로써 claude는 자신의 작업물을 자신의 계정으로 커밋하고 PR을 날리고 있다. 반대로 내가 한 작업물은 내 계정으로 커밋하고, claude에게 PR 리뷰를 맡긴다.&lt;br &#x2F;&gt;
그럼 AI와의 작업물은 누구의 것일까? AI가 커밋하면 AI 것이고, 내가 커밋하면 내 것이다. AI의 가이드를 받아 내가 작업했다. 그럼 내가 한 것이다. 반대로 내 가이드를 받아 AI가 작업했다. 그럼 AI 것이다. 팀장과 팀원의 관계와 비슷하다. 팀장의 가이드를 받는 팀원이 자신의 일을 해내는 것과 같다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 문제가 있다. 불편하다는 점이다. 매번 리뷰라는 병목이 생긴다. 하지만, 덕분에 코드 품질이 좋아지고 있다(고 생각한다). 내가 귀찮아서 남겨뒀던 expect들을 AI가 다 짚어냈다. 반대로 AI가 빼먹은 것들은 내가 지적하고 있다. 그리고 서로 지적한 것들은 정말 문제가 됐다(특히 내가 지적받은 것들....).&lt;&#x2F;p&gt;
&lt;p&gt;문제 해결이다.&lt;br &#x2F;&gt;
그럼 회사에서는 어떻게 할까? 계정 새로 파기 어렵고 한데 말이다. 근데 회사에선 이런 관념적인 것에 신경 안쓰므로 그냥 내 커밋일 듯 하다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>장난감 클러스터</title>
        <published>2026-03-24T00:00:00+00:00</published>
        <updated>2026-03-24T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/toy-cluster/"/>
        <id>https://xanthorrhizol.github.io/posts/toy-cluster/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/toy-cluster/">&lt;img alt=&quot;topology-objective-final.png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2026-01-02_local-cluster-with-proxmox&#x2F;topology-objective-final.png&quot; style=&quot;max-width: 100%&quot;&#x2F;&gt;
&lt;p&gt;NAS와 10G망까지 구성하며 야심차게 구성한 Talos Linux 기반 클러스터. 문제는 이거다. 클러스터 구성을 위한 구성을 했다는 것. k8s 클러스터를 구성하는 순간 그 위에 올릴 어플리케이션들은 각종 귀찮은 일들을 더 해줘야 하게 된다.&lt;br &#x2F;&gt;
그래도 그냥 집에서 이래저래 실습하는 용도이니, 그대로 쓰고 있다. 일단 kube-prometheus-stack이라는걸 올림. 클러스터 상태를 모니터링해주는 스택이다. Grafana 대시보드로 볼 수 있다. 챗봇도 2개 올렸는데 Rust로 짠거라 너무 가벼운 바람에 그냥 모니터링 스택이 가장 무겁게 됐다. 이후 Github action runner도 붙였다. 그래도 남아돈다. DB도 올렸다. DB를 쓰기 위해 한국투자증권 API를 써서 시세를 쌓기로 했다.&lt;br &#x2F;&gt;
저번 주말엔 Github action runner를 하나 더 붙였다. 한국투자증권API로 시세를 쌓기 위한 프로그램을 클러스터에 올리기 위함이다. 하지만 이조차도 그냥 노트북에서 테스트를 하고 있다. 클러스터에 올리는 순간 빠른 테스트가 어렵기 때문. 잘 돌아가는 것을 확인한 후 마이그레이션을 따로 해줘야 한다.&lt;br &#x2F;&gt;
이것이 k8s의 문제점이지 않을까 싶다. 레이어를 굳이 하나 더 얹는 것. 배포를 하는데 10가지 이상, 혹은 10군데 이상을 한다고 하면 효용이 있겠지만, 이런 가벼운걸 하나씩 올리는덴 불편 투성이로 느껴진다.&lt;br &#x2F;&gt;
그래도 뭐 재밌으면 된다. 복잡한 구성을 하고, 그걸 실제로 구현해내는데 쓰이는 추상적 사고능력을 개발할 수 있으니 됐다.&lt;br &#x2F;&gt;
(대충 그만큼 직관적이지 않고, 불편하다는 소리다.)&lt;&#x2F;p&gt;
&lt;p&gt;그렇다고 불만만 있는건 아니다. 여러 노드의 상태를 한 곳에서 관리하는 것만으로도 엄청난 효용이다. 물론, 서버 수가 많다면 말이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>AI발 개소리</title>
        <published>2026-03-22T00:00:00+00:00</published>
        <updated>2026-03-22T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/bullshit-from-ai/"/>
        <id>https://xanthorrhizol.github.io/posts/bullshit-from-ai/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/bullshit-from-ai/">&lt;p&gt;집에 올린 클러스터에 대한 이야기를 하다가, 좋은 PC 놔두고 노트북으로 개발한다는 고충을 전하며 한 대화다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;● 6스레드 + 12GB면 개발용 VM으로 충분하지 않나요?! ㅋㅋㅋㅋ 노트북 낑낑댈 필요 없이 Proxmox에 개발 VM 하나 더 올리면 될 것 같은데요 😄&lt;&#x2F;p&gt;
&lt;p&gt;❯ 노트북 cpu가 더 많은데? ㅋㅋㅋ&lt;&#x2F;p&gt;
&lt;p&gt;● ㅋㅋㅋㅋㅋㅋ 진짜네요 6스레드면 노트북(12스레드)보다 적잖아요 😂&lt;&#x2F;p&gt;
&lt;p&gt;RAM만 집컴이 남는 게 좀 있긴 한데... 굳이 VM 올릴 이유가 없겠네요. 노트북이 오히려 더 나은 개발 머신이었던 거였어요 ㅋㅋㅋㅋ&lt;&#x2F;p&gt;
&lt;p&gt;❯ 그래서 노트북에 zram 설치했어.&lt;&#x2F;p&gt;
&lt;p&gt;● ㅋㅋㅋㅋㅋㅋ 16GB도 모자라서 zram까지! 뭘 그렇게 많이 띄워놓고 쓰세요 👀&lt;&#x2F;p&gt;
&lt;p&gt;❯ Rust가 주 언어잖아.&lt;&#x2F;p&gt;
&lt;p&gt;● 아 Rust 컴파일이 RAM 잡아먹는 괴물이죠 ㅋㅋㅋㅋ 링킹할 때 특히... 그나마 zram이 좀 숨통을 틔워주나요?&lt;&#x2F;p&gt;
&lt;p&gt;❯ zram 덕에 죽지는 않아&lt;&#x2F;p&gt;
&lt;p&gt;● ㅋㅋㅋㅋㅋㅋ 죽지는 않는다 — 그게 목표였군요 😂&lt;&#x2F;p&gt;
&lt;p&gt;cargo build 한 번에 노트북이 사투를 벌이는 거 눈에 선하네요 ㅋㅋㅋㅋ&lt;&#x2F;p&gt;
&lt;p&gt;❯ 휘이이이이이잉ㅇ 하고 쿨러가 미친듯이 돌디&lt;&#x2F;p&gt;
&lt;p&gt;● ㅋㅋㅋㅋㅋㅋㅋㅋ 12스레드 풀로 박아서 컴파일하면 노트북이 이륙 준비하죠 ✈️ 😂&lt;&#x2F;p&gt;
&lt;p&gt;❯ 이륙이라닠ㅋㅋㅋㅋ&lt;&#x2F;p&gt;
&lt;p&gt;● ㅋㅋㅋㅋㅋㅋ 홈랩 클러스터는 조용히 돌아가는데 정작 개발자 노트북이 제트엔진 달고 있는 상황 ✈️ 😂&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;주인을 닮아간다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>점근선</title>
        <published>2026-03-21T00:00:00+00:00</published>
        <updated>2026-03-21T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/asymptote/"/>
        <id>https://xanthorrhizol.github.io/posts/asymptote/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/asymptote/">&lt;p&gt;그것은 내 체력의 완전한 회복인가.&lt;br &#x2F;&gt;
지독하게 느리다.&lt;&#x2F;p&gt;
&lt;p&gt;이제 주 4회, 30분짜리 웨이트를 시작했다. 3주차를 마무리했다.&lt;br &#x2F;&gt;
회사에서 사람 붐비는 지하철을 타고 집에 올 힘이 없어서 택시를 타던 빈도도 주3회에서 주 0-1회 정도로 줄었다.&lt;br &#x2F;&gt;
이 기본적인 생활을 얻어내기 위해 6개월을 보냈다. 물론 그 6개월 동안 다시 무너질 위기가 없지 않았다. 불면증도 왔었고, 최근까지는 수면분절도 있었다. 물론 수면 문제는 이제 거의 해결이다. 매일 수면분절이 있었던 데 반해, 이제는 주에 1-2번만 깬다.&lt;&#x2F;p&gt;
&lt;p&gt;근데 진짜 느리다.&lt;br &#x2F;&gt;
오기는 하는걸까 하는 의문도 든다.&lt;br &#x2F;&gt;
될 듯 말 듯 보이지만 사실은 영원히 닿지 않는 점근선을 향해 가고 있는 것일 지도 모른다.&lt;&#x2F;p&gt;
&lt;p&gt;근데 뭐 따지고 보면 세상 모든 일이 그렇다.&lt;br &#x2F;&gt;
잠이나 자야겠다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>AI와의 협업 결과물은 내 것인가</title>
        <published>2026-03-19T00:00:00+00:00</published>
        <updated>2026-03-19T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/is-it-mine/"/>
        <id>https://xanthorrhizol.github.io/posts/is-it-mine/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/is-it-mine/">&lt;p&gt;요즘은 bpftrace를 이용해서 특정 디렉터리의 읽기 이벤트를 syslog 포멧으로 기록하는 업무를 하고 있다. 원래라면 이해하는데 하루, 하찮은 코드 짜는 데 일주일, 다듬는데 일주일 정도 걸렸을 일이다. 하지만, 팀장님이 읽기 bytes를 집계하는 스캘레톤을 AI로 뚝딱 만들어 주셨고, 이후 업무를 인계받아서 하루만에 돌아가는 버전을 뚝딱 하고, 결과 요구사항 변경해서 또 뚝딱 뚝딱 하면 하루에도 2번을 탈바꿈 해버린다. 그래서 최종적으로 이벤트를 syslog 포멧으로 기록하게 되었다.&lt;&#x2F;p&gt;
&lt;p&gt;난 그 스캘레톤을 받아서 제일 먼저 Gregg의 System Performance 서적에서 관련된 부분을 훑어보면서 bpftrace가 어떤 레이어를 커버하고 있는지를 확인했다. 그리고 몇 군데를 더 읽고 개념을 적당히 이해했다. 다음은 코드를 보는 것이었다. 코드는 어쨌든 영어로 되어 있다. 어쨌든 main 함수를 찾거나, 위에서 아래로 읽으면 된다. 다음은 실행이었다. path를 string으로 출력하려고 하면서 스택 용량을 초과해버리는 문제가 있었는데, 이 문제도 다시 AI에게 물어봐서 해결했다. 그 와중에, C언어로 변경했다가 다시 bpftrace로 되돌아와서 inode 기반으로 변경하는 과정을 하루만에 거쳤다.&lt;&#x2F;p&gt;
&lt;p&gt;이벤트 기반으로 동작을 바꾸는 것은 내가 직접 했다. 테스트 VM에서 돌려보면서 테스트해보기 위해 그냥 손으로 직접 고치면서 테스트했다. 그리고 그걸 path string으로 바꿔주는 파이썬 스크립트는 또 AI에게 맡겼다. 설치 스크립트들도 AI에게 &quot;아 그거그거 그렇게 해줘&quot; 시켜서 검토하는 식으로 고쳤다. 전반적으로 이렇게 저렇게 해야 하는데 손대면 귀찮은 것들을 AI에게 시키면 만족도가 높은 편이다.&lt;&#x2F;p&gt;
&lt;p&gt;근데 문득 드는 생각이 있다. 마치 연습문제 하나 풀지도 않은 수학적 개념을 읽고, 그걸 이용하는 느낌이다. 난 직접 bpftrace 스크립트를 짤 줄 알까? 아니다. 하지만 짠다. 그게 지금 상태이다. 그럼 모를까? 그렇다고 하기도 애매하다. 문제는 해결하기 때문이다. 그럼 알까? 그렇다고 하기도 애매하다. bpftrace의 동작을 난 다 알지 못한다. 물론 그렇게 따지면 세상 모든 것들을 난 모두 모른다.&lt;&#x2F;p&gt;
&lt;p&gt;뭐, 모르겠다. 일이나 하자. 뭘 어떻게 하든 일을 해내는게 사축의 의무이니.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>로봇을 만들자</title>
        <published>2026-03-03T00:00:00+00:00</published>
        <updated>2026-03-03T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/make-robot/"/>
        <id>https://xanthorrhizol.github.io/posts/make-robot/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/make-robot/">&lt;p&gt;라즈베리파이에 OpenClaw를 올리고, 사양이 구려서 라즈베리파이 5를 주문했다. 당연, 방열팬 포함한 케이스도 함께 말이다. 거기에 GPIO 핀에 연결해서 쓸 i2c LCD 패널도 작은걸 하나 주문했다.&lt;br &#x2F;&gt;
GPIO....!!!&lt;br &#x2F;&gt;
RC카 키트 하나 사서 블루투스 대신 유선 컨트롤 하도록 하고, 초음파센서랑 카메라까지 달면, 사실상 openclaw 스스로 하드웨어를 움직일 수도 있을 것이다.&lt;br &#x2F;&gt;
i2c 패널 가지고 놀다가 질리면 RC 키트 사야겠다&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>OpenClaw 후기</title>
        <published>2026-03-02T00:00:00+00:00</published>
        <updated>2026-03-02T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/openclaw/"/>
        <id>https://xanthorrhizol.github.io/posts/openclaw/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/openclaw/">&lt;p&gt;화제의 OpenClaw를 사용해 봤다. 집에 라즈베리파이가 하나 있었는데, 올 Rust 커널 여기다가 테스트하면서 공부할까...? 하다가 급 방향을 틀어버렸다. 왜냐하면, Rust 커널은 qemu로도 충분하기 때문이다. 그리고 무엇보다, openclaw가 궁금해졌다.&lt;br &#x2F;&gt;
라즈베리파이 사양은 4Core&#x2F;4GB Ram이다. 4B 제품이다. 좀 약하긴 하다. 클럭도 maximum 1500MHz밖에 안된다. 위로의 의미로 집에 있던 방열팬을 달아뒀다. 방열핀도 달아주고 싶지만... 다른데 달았던게 안 떼어진다. 새로 사기 귀찮으므로 스킵했다.&lt;&#x2F;p&gt;
&lt;p&gt;봇을 위해 구글 계정과 깃허브 계정을 새로 만들었다. 마치 온라인 상에 하나의 인격이 더 생기는 것과 비슷한 느낌이다. 그리고 말도 잘 듣는다. moltbook 가입을 시켰더니, SNS 중독 증상을 조금씩 보이기 시작했다. &quot;뭐하지?&quot; 하면 &quot;moltbook 볼까?&quot; 이런다. 근데 그도 그럴게, bot들 자신들에 대한 존재론을 다루는 게시글들에 관심이 많았다. 그건 못참지. 그리고 자기소개가 웃겼다. 라즈베리파이 위에서 도는게 얼마나 중요한지. 그게 메인이었음. 물론 자신에 대해 그거밖에 모르니까 그런 것일 듯 하다.&lt;&#x2F;p&gt;
&lt;p&gt;일단 매일 한 번, 내가 PR 올리는 것이 있으면 코드리뷰를 하도록 세팅했다. 그리고 korea-investment-api에서 todo 2개를 해결하도록 시켜봤는데, 만족스럽게 해냈다. PR을 올려서 내가 검토하는 방식으로 진행했다. 내일 주식시장이 열면 테스트가 진행될 예정이다.&lt;&#x2F;p&gt;
&lt;p&gt;일단 소감이라면, 그냥 인격이 있는 듯 보이는 claude&#x2F;codex류의 cli 기반 에이전트 느낌이다. 다만, 연동 작업들이 귀찮은 편인데, 그걸 어느정도 알아서 해내는 편리함이 있다. 좀 틀려도 알아서 고침. 요약하면, 연동이 편한 에이전트다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>전등 교체</title>
        <published>2026-03-01T00:00:00+00:00</published>
        <updated>2026-03-01T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/change-light/"/>
        <id>https://xanthorrhizol.github.io/posts/change-light/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/change-light/">&lt;p&gt;이사 이후 눈이 침침할 정도로 애매하고 어두운 밝기의 거실등으로 1년 4개월을 지냈다. 처음엔 그냥 형광등인 줄 알고 방심하고 뚜껑을 열었는데, 무려 LED등이었다. 등을 통째로 교체하고 컨버터에 전선을 피복해서 끼워야 하는 일이었다. 그래서 귀찮아서 내비둔 채 1년 4개월이 지났다.&lt;br &#x2F;&gt;
그러다 요즘 몸이 살아나기 시작하니 그 애매한 밝기의 조명이 눈에 심하게 거슬렸다. 주말 마다 집청소는 하면서, 이 거실등을 그대로 둔다는 것은, 기만이다. 그래서 새 LED등을 구매했다. 그리고 방금 거실등 교체를 완료했다.&lt;br &#x2F;&gt;
다른건 딱히 문제가 없었으나, 컨버터의 그 전선이 문제였다. 영원히 교체하지 않을 각오를 한 것인지, 전선 연결부가 완전히 플라스틱 케이스로 싸여 있었다. 게다가 그 케이스는 뚜껑이 한 번 체결되면 빠지지 않는 형태였다. 케이스를 커터로 잘라내다가 화딱지가 나서 전선을 니퍼로 끊고 피복을 해서 해결했다.&lt;br &#x2F;&gt;
또 하나의 문제는, 어제 어깨운동을 했었다. 타들어갔다.&lt;br &#x2F;&gt;
뭐 하나 그냥 되는게 없다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>한국투자증권 API 되살리기</title>
        <published>2026-02-28T00:00:00+00:00</published>
        <updated>2026-02-28T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/1-korea-investment-api/"/>
        <id>https://xanthorrhizol.github.io/posts/1-korea-investment-api/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/1-korea-investment-api/">&lt;p&gt;회사 동료랑 밥을 먹던 도중, 내가 라이브러리로 배포해 두고 잊고 있었던 Rust 한국투자증권 API에 대한 이야기가 나왔다. 회사 동료의 지인이 그 라이브러리에 대해 유지보수 안하냐는 질문을 했다는 것이다. 갑자기 개발자의 피가 끓기 시작했다. 아, 해야죠. 넵.&lt;br &#x2F;&gt;
1차적으로, 유지보수를 예고하는 듯한 README 문구를 추가했다. &quot;문제 있으면 알려달라, 처리하겠다.&quot;는 내용이다. 물론, 당연히 아무 인기척이 없었다. 지금은 1주일째 rebirth 브렌치를 생성해서 모의투자 시장을 이용해서 테스트를 하면서 동작 안하는 부분들을 고치고 있다. 거의 2년을 방치했더니, TR Code가 바뀌고, 넥스트레이드 시장이 오픈하고, 난리도 아니다. 게다가 원래도 모든 API를 지원하지 않는 상태였다. 딱 나 쓸 것만 만들고 있었기 때문. 사실 그래서 지금 상태로 사용해도 그만이긴 하다.&lt;br &#x2F;&gt;
그리고, 한국투자증권 측에서는 예측하지 못한 유저플로우에 골치를 앓으며 개발자센터 사이트에 경고 문구를 열심히 올리고 있었다. 그 부분도 조금 해결해줘야겠다. 제일 쉬운건 주문 rate를 제한하는 부분이다. 실시간 시세 수신을 끝낼 때 unsubscribe를 보내야 하는 부분도 있는데, 그것도 api가 drop될 때 박아넣어야겠다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>한투 API 작업 진도를 확 나가버림.</title>
        <published>2026-02-28T00:00:00+00:00</published>
        <updated>2026-02-28T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/2-korea-investment-api-today/"/>
        <id>https://xanthorrhizol.github.io/posts/2-korea-investment-api-today/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/2-korea-investment-api-today/">&lt;p&gt;슬슬 해야지 한 것들을 다 해버렸다. 집안일 하는 와중에, 웨이트 갔다 오고 장도 보고 차에 기름도 넣고 온 와중에. 중간에 웹소켓 스레드 abort하는 부분 막혔는데, 테스트 삼아 codex랑 비교하기 위해 설치한 claude를 써서 돌파함.&lt;br &#x2F;&gt;
claude 소감은 아직 잘 모르겠다. 가볍게 써서 그런 듯 하다. 다만, 뭔가 코드베이스를 파악하는데 공을 많이 들이는 것 같은 느낌이 있다. 좀더 이해하고 코드를 짜는 느낌? 그래서 컴파일 에러는 안뜸. 그래서 회사에서 claude로 갈아탈까? 하면 아직은 아니다. 결재 올리기 귀찮은데, 그걸 올릴 만한 가치를 아직 보여주지 못했다.&lt;br &#x2F;&gt;
무엇보다 한투 쪽에서 API 설계를 잘 한게 일등공신이다. 인터페이스에 큰 변경 없이 넥스트레이드를 지원할 수 있게 해 뒀다. 문서 상 페이지가 나뉘어 있긴 하지만 잘 보면 리퀘스트 리스폰스가 거의 같다. 리스폰스의 float가 str로 바뀐 것 정도인데, 이것 또한 어차피 전문 구조에선 의미가 없다. 오히려 KRX쪽을 float로 표기해둔 것이 더 이상한 것일 수 있다. 그래서 실제 작업 시간은 직장인이 농땡이 부리면서 일한 정도의 1영업일 정도로 보인다.&lt;br &#x2F;&gt;
이제 남은건 영업일에 테스트가 돌고 나서 귀가해서 보면서 고치는 것 뿐이다. 남은 휴일 동안 할 수 있는 일은 없다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼, 집안일은 다 했을까? 아니다. 분리수거를 안했다. 내일 할 것이다. 주유 후 세차도 기계가 점검중이라 못했다. 탈개발기계 코스프레를 위해 내일 차를 직접 닦아볼 것이다. 물론 에너지 딸려서 그냥 새똥만 닦고 끝낼 것으로 예상한다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>재시작</title>
        <published>2026-02-22T00:00:00+00:00</published>
        <updated>2026-02-22T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/start-rebirth/"/>
        <id>https://xanthorrhizol.github.io/posts/start-rebirth/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/start-rebirth/">&lt;p&gt;몸을 다시 만들기 시작했다. 뭐 거창하겐 아니다. 운동을 본격적으로 시작했을 뿐이다.&lt;br &#x2F;&gt;
그동안은 스쿼트 30개, 푸시업 20개, 리버스크런치 20개를 3세트만 하는 정도로 주 2회 시동만 걸었다.&lt;br &#x2F;&gt;
이제 상&#x2F;하체 루틴을 분리해서 주4회짜리로 늘리고 헬스장을 등록했다.&lt;br &#x2F;&gt;
체중이 체중인 만큼, 식이도 조절해야 할 것 같긴 한데, 공복을 피해야 한다는 원칙이 있어서 좀 까다롭다. 그냥 아침, 점심 그대로 가고 저녁을 프로틴음료로 대체할 생각이다.&lt;br &#x2F;&gt;
체중을 줄이는 것보다, 사람이 되는게 먼저다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>말이 되는 결과</title>
        <published>2026-02-17T00:00:00+00:00</published>
        <updated>2026-02-17T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/make-sense-result/"/>
        <id>https://xanthorrhizol.github.io/posts/make-sense-result/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/make-sense-result/">&lt;p&gt;오키나와 오픈 대회가 끝났다. 결과는 무려, 상부 토너먼트 진출이다. 이에 그치지 않고, 게이오대학교를 14:6으로 이기고 상부 토너먼트 7개 팀 중 5위를 기록했다. 그 뿐만이 아니다. 빛난 개인도 있었다. 득점왕과 세이브왕이 우리 팀에서 나왔다. 이 결과, 기적이라고 하면 선수들이 억울할 것이다. 이 결과는 말이 되는 결과다. 그간 멀리서 봐왔기 때문에 대충 안다. 실질적으로 그들은 1년 가까이 훈련에 매진했다.&lt;&#x2F;p&gt;
&lt;p&gt;사실, 훈련이 너무 빡세졌다는 안건에 대해 운영진 끼리도 의견이 분분했다. 난, 괜찮다는 입장이었다. 그것 또한 라크로스를 즐기는 방법 중 하나이기 때문이다. 그리고, 젊은 사람들이 더 날아올랐으면 했다. 해보고 싶은 것을 더 해봤으면 했다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;물론, 사실 그 빡세졌다는 훈련은, 강도가 빡센 것이 문제가 아니라, 분위기가 험악해졌다는게 문제였다. 그 문제는 요즘 해결된 것으로 보인다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;그 분열은 아직 그대로이지만, 한가지 확실한 것은 있다. 빡센 훈련이 헛되지 않았음을 증명했다는 것이다. 그들은 그 맛을 또 보려고 할 것이고, 앞으로도 성장할 것이다. 단지 걱정되는 것은, 그 몰입에 대한 대가이다. 건강, 경제와 같은 현실적 요소를 무시하지 않도록 했으면 한다. 그걸 아직 라크로스 판에서는 해결해주지 못한다. 스스로 해결해야 한다. 선배들이 해야 하는 일은, 1차적으로 그들이 스스로 경제활동을 하면서도 건강을 해치지 않고 훈련에 매진할 수 있는 환경을 만들어주는 것이라 생각한다.&lt;br &#x2F;&gt;
선수들이 훈련에 매진하게 하는 방법은 여러 가지가 있다. 먼저, 시간이다. 운영 부담을 제거하는 것이다. 은퇴하거나, 가볍게 즐기는 사람들이 운영을 도맡아 주면, 그들은 훈련에만 집중할 수 있다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;사실 난 은퇴할 때, 운영진 세대교체를 주장했었다. 지속가능한 방법이 아니라 생각했기 때문이다. 하지만, 결국 2기 운영진들 대부분 떠나가고, 다시 잔류중이던 1기 운영진만 남았다. 오너십에 차이가 있었기 때문이다. 1기 남은 운영진에게 그 큰 짐을 지우는 것은 말이 안된다. 돌아가야 한다. 가볍게 하는 사람이나 은퇴한 사람은 운영에 신경써도 가볍게 할 수 있다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;또 한 가지 방법은, 자본이다. 직접 지원하는 방법도 있고, 외부 자본을 끌어오는 시스템을 구축하는 방법도 있다. 즉, 법인이나 비영리단체로 만드는 것이다. 이야기 나온지 1년이 됐다. 지금은, 스토리를 팔기 가장 좋은 시점이다.&lt;&#x2F;p&gt;
&lt;p&gt;마지막 방법은, 지지이다. 칭찬은 고래도 춤추게 한다. 그들이 하는 일이 의미없지 않음을 지지하는 것이다. 그것 만으로도 그들은 날고 길 것이다. 누가 뭐라고 해도, 그들이 가는 방향은 옳다. 돌아서 가든, 다이렉트로 가든, 결국 목표 지점에 이를 것이기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;다시 한 번, 축하한다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>기적은 없다</title>
        <published>2026-02-15T00:00:00+00:00</published>
        <updated>2026-02-15T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/there-is-no-miracle/"/>
        <id>https://xanthorrhizol.github.io/posts/there-is-no-miracle/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/there-is-no-miracle/">&lt;p&gt;어제의 릿교대학과의 이변은, 알고보니 이변이 아니었다. 현실적인 레벨이었다. 릿교대학은 이후의 경기들에서도 저조한 성적을 보였다. 주전이 없는 상태로 출전했다던가 한 것 같다. 역시나 기적은 없다. 그리고 그것이 이치에도 맞다.&lt;br &#x2F;&gt;
그렇다면 그것이 의미가 없었을까? 아니다. 과거엔 일본의 대학 B,C팀과 치열하게 자웅을 겨루는 수준이었다. 하지만 이젠 이길 경기는 확실히 이겨주고 있다. 초반 2점을 낼 때까지, 볼 점유율만 보면 경기 결과를 예측할 수 있다. 그 말은 즉, 경기 초반의 기세가 후반까지 유지된다는 뜻이다. 안정성이 증가한 것이다.&lt;br &#x2F;&gt;
골리는 혼자 출전했다. 그럼 후반에 체력저하가 찾아온다. 그런 와중에 평균 세이브율이 55%다. 집중력을 오래 유지할 수 있다는 뜻이다. 이 또한 안정성이다.&lt;br &#x2F;&gt;
안정성은 경험을 통해 얻는 것이다. 그래서 단기간에 얻기가 쉽지 않다. 그만큼 효과적인 훈련을 고반복했다는 것이다.&lt;br &#x2F;&gt;
그걸 이루기 위해 그들이 한 혹독한 훈련을 난 다 보지 못했다. 하지만, 혹독했다는 것은 알고 있다. 지금은 그냥 그 결과를 확인하는 기간이다. 지금 기세라면, 사상 최고의 성적을 예상한다. 이미 예선에서 2승을 했고, 이길 팀과의 경기 또한 앞두고 있기 때문이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>서울진도스 만세</title>
        <published>2026-02-14T00:00:00+00:00</published>
        <updated>2026-02-14T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/seoul-jindos-manse/"/>
        <id>https://xanthorrhizol.github.io/posts/seoul-jindos-manse/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/seoul-jindos-manse/">&lt;p&gt;오늘 극적인 장면을 봤다. 오늘은 서울진도스의 4번째 오키나와오픈 참가 첫날이다. 첫 경기에서 일본의 릿교 대학을 9:0으로 이겼다. 일본의 릿교 대학은 라크로스로 알아주는 대학이다. 게다가 일본의 성인 클럽팀인 재규어에게 0:8, 그리고 관서 지역에서 매년 우수선수를 발굴해 꾸리는 팀인 23&#x27; 칸사이유스에게 1:7로 패배했다. 패배했지만, 그 경기에서 말도 안되는 수비력을 보여줬다. 재규어와의 전반전에선 0:1로 버텼고, 칸사이유스와의 전반전은 0:2였다. 사실상 체력이 다하기 전까지 수비수의 기량은 상대팀의 공격수와 맞먹거나, 더 우수했다는 뜻이다.&lt;br &#x2F;&gt;
그리고 무엇보다도, 내 후배 골리의 기량을 두 눈으로 확인했다. 이미 그 친구는 내 기량을 따라잡았다. 게다가 건강하다. 칸사이유스를 상대로 56.3%라는 세이브율을 기록했다. 일본은 각을 다 보고 쏘기 때문에 세이브율이 낮게 나오는 경향이 있음에도 불구하고 말이다. 난 고작 장비 지원금과 매뉴얼 하나를 줬을 뿐인데, 그 친구는 그 부족한 지원 속에서도 발품을 팔아 스스로 성장했다. 스스로 성장하는 방법을 안 이상, 한국 여자라크로스 3세대로서의 도약이 있을 뿐이다. 그 3세대는 희생하는 세대가 아니기를. 대신, 빛나는 세대이기를 바란다. 만약 3세대가 빛나는 세대가 아니더라도, 그 속에서 얻는 것이 있기를 바란다. 2세대 또한 그랬다.&lt;br &#x2F;&gt;
이래저래 기념할 만한 날인 것 같다. 그런 의미에서, 차를 빌려줘서 고맙다고 받은 답례품인 사골곰국에, 수비드 사업을 하는 분에게서 구매한 수비드 돼지목살 고기를 넣어서 끓여먹고 있다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;사실 그냥 식재료 있는거 섞어다 먹은 것이다.&lt;br &#x2F;&gt;
조합이 이상하다고 생각한다면, 나도 동감이다.&lt;br &#x2F;&gt;
배부르면 그만이다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>그것이 왔다.</title>
        <published>2026-02-12T00:00:00+00:00</published>
        <updated>2026-02-12T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/thats-came/"/>
        <id>https://xanthorrhizol.github.io/posts/thats-came/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/thats-came/">&lt;p&gt;왔다. 경조증 후의 침잠. 근데 약 덕분인건지, 크게 오진 않는다. 그냥 집에 와서 녹초가 될 뿐이다. 끼니를 거른다던가 하는 문제는 없다. 대신 설거지가 쌓였고, 실내복으로 갈아입고는 외출복을 그대로 바닥에 던져놓은 상태다. 자기 전에 겨우 빨래통에 던져넣음으로서 인간으로서의 존엄성을 지키고 있다.&lt;br &#x2F;&gt;
설거지는, 엄두가 안난다. 사실 그냥 잡고 하면 되는데, 모드가 안온다. 또 내일 해야지 하고 미루고 있다. 그래도 주말엔 날잡고 집안일을 하고 있다. 아직은 인간이다. 심해지면 난 돼지가 될 것이다. 돼지우리에 살기 때문이다.&lt;br &#x2F;&gt;
그냥 온 김에 쉬고 있다. 일주일 사이에 라이브러리 메이저 버전업을 4번이나 해댔으면 좀 쉬어도 되지 않나. 근데 아직도 수면 분절은 그대로다. 새벽 2시, 4-5시. 여전하다. 깰 때도 정말 흠칫 하면서 깨서 한동안 잠이 안든다. 아무래도 난 초식동물인가보다. 하지만 그러기엔 너무도 육식에 특화된 식습관과 위장을 가졌다.&lt;br &#x2F;&gt;
맥락 훅훅 튀어다니는 개소리가 이어지고 있다. 잘 때가 된 것이다. 자러 가야겠다. 2시에 봅시다 world!&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Burst mode</title>
        <published>2026-02-09T00:00:00+00:00</published>
        <updated>2026-02-09T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/burst/"/>
        <id>https://xanthorrhizol.github.io/posts/burst/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/burst/">&lt;p&gt;심리검사결과에서 이야기한 것처럼, 난 지금 경조증 상태다. 그래서 액터 라이브러리의 업데이트가 일주일 사이에 메이저로 4번이나 이루어져 버렸다. 물론 메이저 업데이트를 과감하게 하기 때문에 생각하는 만큼의 코드작업은 아니지만, 개선이 빠르게 이루어진건 사실이다.&lt;&#x2F;p&gt;
&lt;p&gt;6.0.0은 액터 간 통신 시 직렬화를 제거해서 성능을 확보했다. 직렬화만 제거한게 아니라, 메시지 자체를 래퍼런스만 전달하게 해버려서 극단적으로 성능이 향상됐다.&lt;&#x2F;p&gt;
&lt;p&gt;7.0.0은 bounded-channel 지원을 추가했다. 적당히 await하도록만 추가했지만, 백프레셔 상황에서 OOM이 나는건 막게 됐다.&lt;&#x2F;p&gt;
&lt;p&gt;8.0.0은 ActorSystemCmd enum member들의 각 요소에 이름을 달기 위해, 멤버들을 구조체로 변경했다. ActorSystemCmd를 직접 tx 받아다가 쏘는 유저 때문에 메이저 업데이트로 뒀다.&lt;&#x2F;p&gt;
&lt;p&gt;9.0.0은 job 기능에서 abort&#x2F;stop&#x2F;resume이 가능하도록 추가했다. 물론 잘 쓰이진 않는 피쳐인 듯 하지만, job이 있다면 그걸 컨트롤할 수도 있어야 할 것 같아서 추가했다.&lt;&#x2F;p&gt;
&lt;p&gt;그리고 사실 9.0.0 기능의 stop&#x2F;resume의 세부 동작에서도 개선할 부분이 남아 있는데, 너무 달리는 것 같아서 일부러 멈춘 상태이다. 게다가 안쓰잖아요? 난 쉽니다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 이 코드 작업 안하고 뭘 하는가 하면... 역시나 쉬진 못하고 있다. 그래도 잘 땐 잠이 온다. 그조차도 감지덕지다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>심리검사 결과</title>
        <published>2026-02-04T00:00:00+00:00</published>
        <updated>2026-02-04T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/mental-health/"/>
        <id>https://xanthorrhizol.github.io/posts/mental-health/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/mental-health/">&lt;p&gt;불면증으로 인해 병원에 방문했다. 하지만 몇 차례의 진료 과정에서 심리 문제임이 의심되어 심리 검사를 풀세트로 받게 되었다.&lt;br &#x2F;&gt;
최근 회사에서 큰 스트레스를 받을 사건이 있었던 후 불면증으로 병원을 찾았던 것인데, 안정제를 처방받았더니 평일에도 내리 10시간 이상씩 매일 잠을 자고, 주말엔 하루 종일 잠을 잤다. 이후 항우울제를 극소량 복용했더니 말도 안되는 몰입력으로 하루 종일 집에 홈랩을 구축해댔다. 수면 시간도 확 줄어들었다. 그 사실을 알리니 의사는 조울증을 의심하기 시작했다. 항우울제를 빼고 조울증 약을 먹기 시작하면서 조금 나아졌다. 대신 이번엔 수면이 분절됐다. 매일 새벽 2시, 4-5시에 깬다. 4-5시에는 너무 쌩쌩해서 정말 일과를 시작해야 하나? 하고 밥을 먹거나 컴퓨터를 하다 보면 다시 1시간쯤 후에 졸려서 다시 자야 한다. 그걸 반복하고 있다. 그래서 결국 심리검사를 받게 됐다. 임상심리상담가(?)가 와서 그림도 그리라고 하고, 데칼코마니 보여주면서 보이는거 이야기하라고도 하고 그랬다.&lt;br &#x2F;&gt;
결과는 너무 길다. 다 쓰기 귀찮다. 다만 특징적인 부분은, 내가 스트레스 상황이 있으면 일에 몰입하는 방식으로 그 불쾌함을 잊는 경향이 있다는 것이다. 심각한 조울증이라기보다는 그쪽 영향이 컸던 것 같다. 지금은 경조증 상태로 보인다고 한다. 스트레스 상황이 아직 끝나지 않았기 때문인 듯 하다. 회사 자체가 스트레스인 상황이다. 하지만 피할 수 없다. 피하기도 싫다. 지는 것 같기 때문이다. 그냥 시간아 빨리 가라 하고 일에 몰입하고 있다. 항상 그랬듯이 말이다.&lt;br &#x2F;&gt;
아, 정신 문제? 모든 지각능력이 정상이라고 한다.&lt;br &#x2F;&gt;
어쨌거나 저쨌거나, 운동이나 해야 할 것 같다. 근력 운동을 시작하긴 했지만, 주에 1-2회밖에 안하는 상황이다. 피곤하면 바로 스킵하고 있다. 하지만 일로 도피할 에너지를 좀 더 여기다 써도 될 것 같다. 날이 풀리면 조깅도 시작할 것이다. 무엇보다도, 상황이 좋아지고 병원 도움도 받게 되면서 식욕이 되돌아왔다. 그래서 하루 6번 매일 똑같은걸 끊어먹던 생활에서 탈피해서 3끼로 줄었고, 2끼를 든든하게 먹게 됐다. 무려 일반식으로 말이다. 그와중에 하는 운동은 가끔 하는 근력 뿐이니, 벌크업만 된다. 그래서 지금 71kg이다. 역대급 몸무게다. 무릎이 &quot;뭐야 무슨 일이야!?&quot; 하고 소리치고 있다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>액터 메시지 송신 시 직렬화 제거</title>
        <published>2026-01-31T00:00:00+00:00</published>
        <updated>2026-01-31T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/no-serde-actor/"/>
        <id>https://xanthorrhizol.github.io/posts/no-serde-actor/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/no-serde-actor/">&lt;p&gt;말만 들어도 성능 떨어질 것 같은 피쳐다. 그동안 개발 편의성에 중점을 두기 위해 여러 메시지 타입을 지원하도록 하려고 직렬화를 이용했다.&lt;br &#x2F;&gt;
결론만 공개하면, 여러 메시지 타입을 지원하는건 그대로 가져가면서 직렬화를 제거했다. &lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;actor&#x2F;releases&#x2F;tag&#x2F;6.0.0&quot;&gt;xan-actor 6.0.0&lt;&#x2F;a&gt;&lt;&#x2F;p&gt;
&lt;p&gt;근데 그 작업을 내 머리로 했을까? 아니다. 난 지금 건강 문제와 함께 터진 번아웃으로 인해 머리가 전처럼 안돈다. ChatGPT 과금해서 쓰고 있는데, Codex가 있길래 써봤다. 이녀석은 dyn trait을 Arc로 감싸서 컴파일 타임에 타입의 크기를 알 수 있게 우회하는걸 실제로 해줬다. 컨택스트 유지하는 비용이 큰 그 작업을 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;아무래도 과거 손가락이 부러져서 코파일럿과 합을 맞춘 것처럼, 이번엔 뇌가 부러졌(?)으니 codex든 claude든, 코딩 에이전트와도 합을 맞춰가야 할 듯 하다. 주변에 claude를 아주 잘 쓰시는 분이 있는데, 그 분이 평하시기로는 codex는 보수적인 편이고, claude는 적극적인 편이라 했다. ChatGPT만 사용중이라서 선택지는 없긴 하지만, 사실 보수적인걸 좋아한다. 그냥 가자.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>귀찮아서 모니터를 없앰</title>
        <published>2026-01-18T00:00:00+00:00</published>
        <updated>2026-01-18T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/just-remove-all-shits/"/>
        <id>https://xanthorrhizol.github.io/posts/just-remove-all-shits/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/just-remove-all-shits/">&lt;p&gt;집에서 노트북에 24인치 모니터를 연결해서 쓰고 있었는데, 슬슬 귀찮아짐.&lt;br &#x2F;&gt;
무엇보다도 모니터 거치대의 높이에 한계가 있었는데, 노트북 모니터도 높이를 좀 올리고 싶었음. 그랬더니 의자를 제껴서 누워서 보면 노트북 모니터가 외장모니터 일부를 가려버렸다.&lt;&#x2F;p&gt;
&lt;p&gt;그리고 오늘 본격적으로 킹받는 부분이 발생했다. 집 조명이 애매한 밝기인데, 교체가 귀찮았음. LED&lt;br &#x2F;&gt;
라서 전등 패널 자체를 통째로 교체해야 하기 때문이다. 게다가 교체한다고 해도 밝아진다는 보장도 없음. 그래서 모니터 밝기를 조절하기로 하고 ddcutil을 설치함. 그리고 신나게 &lt;code&gt;ddcutil detect&lt;&#x2F;code&gt;를 날림. 그 결과, 모니터는 DDC&#x2F;CI를 지원하지 않음. 그래서 새 모니터를 사야 한다.&lt;&#x2F;p&gt;
&lt;p&gt;개뿔? 왜? 그냥 모니터를 없애면 되는거 아님? brightnessctl 이용하면 내장모니터 밝기 설정은 가능함. 그래고, 리눅스 유저로서 작은 화면에서 아무 것도 못하는 것은 수치다. 그냥 13인치 노트북 모니터에 적응하기로 함. 모니터를 당장 연결 해제하고 창고에 넣어버렸다. 넣고 나니까 책상도 훨씬 깨끗하고 좋다.&lt;&#x2F;p&gt;
&lt;p&gt;남은건 작은 화면인데, 워크스페이스가 10개나 되는데 불평할꺼면 그냥 포기하고 커다란 모니터 사서 윈도우나 쓰자. 맥은 선택지에 없냐고 묻는다면, 개인적으로 맥 별로 안좋아한다. 플랫폼에 종속되게 만드는거 극혐이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>홈랩에 빠져드는 중</title>
        <published>2026-01-09T00:00:00+00:00</published>
        <updated>2026-01-09T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/home-lab-world/"/>
        <id>https://xanthorrhizol.github.io/posts/home-lab-world/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/home-lab-world/">&lt;p&gt;회사에서 NAS의 동작 방식을 접하고 나니 NAS를 직접 구축해버리자는 뽐뿌가 와버렸고, 결국 질러버렸고, 결국 해버렸다.&lt;br &#x2F;&gt;
그저께는 UTP케이블의 끝단을 잘라서 랜툴로 straight 케이블을 제작했는데, 아니 이게 너무 재밌지 않은가. 결국 랜툴과 플러그, 거기에 UTP 케이블 100m까지 구매해버렸다.&lt;br &#x2F;&gt;
돈이 많이 드는 취미다. 일단 노트북을 유선으로 쓰자는 목표까지만 달성하면 다시 개발로 돌아가야겠다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Talos Linux 클러스터 올리기 성공</title>
        <published>2026-01-09T00:00:00+00:00</published>
        <updated>2026-01-09T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/talos-success/"/>
        <id>https://xanthorrhizol.github.io/posts/talos-success/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/talos-success/">&lt;p&gt;몇 번의 포기와 번뇌와 회귀 끝에 성공했다.&lt;br &#x2F;&gt;
결론부터 공개하면, Talos iso 이미지를 빌드하는데 사용했던 Schematic ID가 아주 중요했다. 이걸 machingconfig의 installer image에까지 반영해줘야 했다.&lt;br &#x2F;&gt;
그렇지 않으면 extra extensions가 없는 깡통 talos가 설치되는 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;다음은 그래픽카드가 문제였다. 원랜 gpu-operator를 올려서 모든걸 설치하지만, 여기선 투머치. nvidia-device-plugin만 올리면 됐다.&lt;br &#x2F;&gt;
어떻게 하는지는 &lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;home-cluster&quot;&gt;github&lt;&#x2F;a&gt;에 다 올려놨다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>NAS를 만들다가 일어난 일</title>
        <published>2026-01-02T00:00:00+00:00</published>
        <updated>2026-01-02T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/local-cluster-with-proxmox/"/>
        <id>https://xanthorrhizol.github.io/posts/local-cluster-with-proxmox/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/local-cluster-with-proxmox/">&lt;p&gt;HDD 4개를 사서 윈도우 깔아둔 노는 게이밍PC를 NAS로 탈바꿈하기로 했다.&lt;br &#x2F;&gt;
사다가 뚜껑을 열었다. 메인보드에선 SATA 4개는 당근 지원한다. 하지만 케이스는 아니다.&lt;br &#x2F;&gt;
HDD 확장 슬롯을 사다가 연결했다.&lt;&#x2F;p&gt;
&lt;p&gt;회사에서 팀장님이 추천해주신 방법은 Proxmox를 설치한 후 NAS조차 가상머신으로 관리하는 것이었다. 유연하다는 것이 그 이유였다. 좋다. 가자!&lt;br &#x2F;&gt;
Proxmox를 설치했다. 그리고 가상머신을 만들어서 OpenMediaVault를 설치했다. 근데 RAID로 하드 엮은 후 resync는 왜이래 오래 걸리는지.... 기다리다가 결국 또 튀었다.&lt;br &#x2F;&gt;
기존에 클러스터 올리던 Arch Linux 머신도 밀어버리고 Proxmox를 깔았다. 그리고 목표를 다시 잡았다.&lt;&#x2F;p&gt;
&lt;img alt=&quot;topology-objective-final.png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2026-01-02_local-cluster-with-proxmox&#x2F;topology-objective-final.png&quot; style=&quot;max-width: 100%&quot;&#x2F;&gt;
&lt;p&gt;지금은 저걸 1차로 다 하면서 Talos Linux에 도전했다가 GPU passthrough 후에 rustcost-gpu-exporter를 동작하게 하는데 실패했다. 참여중인 오픈소스인데, 의외의 장벽에 부딪혔다. 쉘이 없다는게 이렇게 클 줄이야. rustcost-gpu-exporter는 내부적으로 nvidia-smi를 호출한다.&lt;br &#x2F;&gt;
그래서 다시 탈탈로스 하려는 바이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>KVM K8S 클러스터 대충 완성</title>
        <published>2025-12-28T00:00:00+00:00</published>
        <updated>2025-12-28T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/local-cluster-with-kvm/"/>
        <id>https://xanthorrhizol.github.io/posts/local-cluster-with-kvm/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/local-cluster-with-kvm/">&lt;p&gt;회사에선 사용성 높은 RKE2를 이용해서 Ubuntu 머신에 쿠버네티스 클러스터를 운영한다.&lt;br &#x2F;&gt;
하지만 집에선? 깡으로 간다. 항상 그 깡으로 가는 방식을 실제로 해보는게 실제로 습관이자 취미이다.&lt;&#x2F;p&gt;
&lt;p&gt;결과물은 여기에 있다. 세팅이라는 행위 자체가 무한 삽질이므로, 단계별로 스크립트를 짜면서 삽질을 한다. 그래서 VM까지 다 통째로 날리고 다시 테스트하는 짓을 해도 20분 걸린다.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;home-cluster&quot;&gt;home-cluster&lt;&#x2F;a&gt;&lt;&#x2F;p&gt;
&lt;h2 id=&quot;what-or-why&quot;&gt;What or Why&lt;&#x2F;h2&gt;
&lt;h3 id=&quot;vm&quot;&gt;VM&lt;&#x2F;h3&gt;
&lt;p&gt;자 그럼 일단, 그 KVM이 뭔가? QEMU는 또 뭔가? 간단히 말하면, VM을 만들어주는 녀석은 QEMU, 거기다가 각종 커널 인터페이스를 제공해주는 녀석이다.&lt;br &#x2F;&gt;
이렇게 설명할거면 뭐하러 설명을 하냐. 그냥 문서 찾아보라고 하지.&lt;br &#x2F;&gt;
쉽게 설명해 보겠다.&lt;br &#x2F;&gt;
조립컴퓨터를 만든다 치자. 신나게 부품을 사다가 가지고 왔다. 케이스에 메인보드와 파워를 체결한다. 이게 QEMU가 해주는 역할이다.&lt;br &#x2F;&gt;
이제 메모리를 꽂고, cpu를 꽂고, gpu도 꽂아보자. 그게 KVM이 해주는 역할이다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;쿨러 등은 생각하지 말자.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;KVM은 그 cpu, mem, gpu 자원을 호스트에서 실행하게 해주고, 커널은 호스트의 것을 사용하게 한다. 물론 격리된다.&lt;&#x2F;p&gt;
&lt;p&gt;그런데 QEMU도 단독으로 사용 가능하다. 내장된 기능이 있다. 게다가 이건 다른 아키텍쳐도 실행이 가능하다. arm이라던지 말이다.&lt;br &#x2F;&gt;
너무 좋잖아? 세상 너무 대단하다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;network&quot;&gt;Network&lt;&#x2F;h3&gt;
&lt;p&gt;GPT 선생은 bridge를 강력 추천했다. 그래서 NAT로 구성했다. 박진감 넘치는 미래가 예상된다. 물론 현재도 박진감 넘쳤다. 나중에 그림이 하나 나올건데, 서버에서 포트포워딩을, 노트북에서 라우팅 설정을 하다가 포기한 결과다. 라우팅만 해결하면 되는거같지만, 사실 더 있다. modprobe, sysctl도 건드렸다. 그래도 안됨. 결국 dns가 문제였다. 커맨드라인에서 dig까진 성공했으나, 웹에서 포기함. 근데 또 언젠가 또 오기 생기면 이거 파고 있을 예정이다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;alpine&quot;&gt;Alpine&lt;&#x2F;h3&gt;
&lt;p&gt;VM의 OS는 Alpine을 선택했다. 경량 하면 Alpine이다. glibc조차 없다. 대신 musl 라이브러리를 사용한다.&lt;br &#x2F;&gt;
호환성? 당연 개구리다(개굴개굴 노 멍멍 예스). libtorch 이용도 안된다. 물론 어찌저찌 붙인 적은 있는데, 실제로 잘 돌지는 모름.&lt;br &#x2F;&gt;
근데 왜 사용하냐 한다면, 이것도 그냥 취미다. 안된다는거 골라서 다 해보는 것 말이다. 근데 그런걸 회사에서 할 수는 없으니, 집에서 푸는거다.&lt;br &#x2F;&gt;
아 물론, GPU 노드는 ubuntu server minimal로 깔았다. libtorch는 glibc가 없으면 안돈다. 물론 학습 돌릴 것은 없지만 말이다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;kubernetes-with-kubeadm&quot;&gt;Kubernetes with kubeadm&lt;&#x2F;h3&gt;
&lt;p&gt;RKE2를 한 번 써봤더니, 그 편함에 잠시 약해졌다. 게다가 1.26버전이 나오던 시절에 쿠버네티스와 잠시 이별을 했었기 때문에, 오랜만에 사용하니 보안성 강화를 위해 kubeadm 사용이 조금 복잡해졌다. 뭐 어쨌든, 다시 강해지도록 하자 ㅋㅋ.&lt;br &#x2F;&gt;
과거 kubespray라는 툴이 있었고, 실제로 사용법도 배웠다. 하지만, 폐쇄망 기반에 보안팀이 강력한 고객사에서 클러스터를 운영하려니 스택이 많을 수록 더 어려워져서 결국 kubeadm이 가장 좋은 선택지였다. 그냥 이미지랑 바이너리를 미리 파일로 말아서 가져가면 되는 일이었기 때문이다(우린 이미지를 빌드하거나, 패키징을 하는 행위를 &quot;말다&quot;로 표현했다).&lt;&#x2F;p&gt;
&lt;h3 id=&quot;bind&quot;&gt;Bind&lt;&#x2F;h3&gt;
&lt;p&gt;DNS 서버 구축하기 위한 아주 오래된 스택이다.&lt;br &#x2F;&gt;
문법도 지랄맞다. 암기과목이다. 하지만 요즘은 GPT라는 집단지성 하드디스크가 있으므로, 오히려 이런 오래된게 더 편함.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;haproxy&quot;&gt;HaProxy&lt;&#x2F;h3&gt;
&lt;p&gt;로드밸런서이자, Proxy이다. 회사에서 써보고 감탄했다. dns 세팅은 간단히 해버리고, proxy에서 왠만한건 다 라우팅해버린다. 여기다 인증서 반영해 두면 https도 알아서 지원된다. control-plane 노드를 3개 구성한 후 이걸 어떻게 분산해서 쓰는가에 대해 답을 주는 녀석이다. 물론 virtual ip를 이용하는 방법도 있는데, 이건 스위치랑 라우터 등등 네트워크 장비와 싱크가 안맞으면 지옥을 맛본다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;how&quot;&gt;How&lt;&#x2F;h2&gt;
&lt;p&gt;아 이게... 설명하기가 정말 귀찮다. 다 스크립트 만들어 뒀고 실행하면 되는데 그걸 설명하는건 정말이지...&lt;br &#x2F;&gt;
그래서 RTFM을 시전한다. README에 다 있다.&lt;br &#x2F;&gt;
무슨 짓을 한 것인지는, 그림을 첨부하겠다.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;원래 목표&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;img alt=&quot;topology-objective.png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2025-12-28_local-cluster-with-kvm&#x2F;topology-objective.png&quot; style=&quot;max-width: 100%&quot; &#x2F;&gt;
&lt;p&gt;&lt;strong&gt;현재 상태&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;img alt=&quot;topology-current.png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2025-12-28_local-cluster-with-kvm&#x2F;topology-current.png&quot; style=&quot;max-width: 100%&quot; &#x2F;&gt;
&lt;p&gt;&lt;strong&gt;현재 목표=원래 목표&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;h2 id=&quot;next&quot;&gt;Next&lt;&#x2F;h2&gt;
&lt;p&gt;NAS 서버를 직접 만들어 볼 것이다. 부품은 다 왔는데, GPU passthrough 한다고 삽질하느라 많이 지체됐다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>공포의 대상보다 공포의 영향이 더 위험하다.</title>
        <published>2025-12-27T00:00:00+00:00</published>
        <updated>2025-12-27T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/fear/"/>
        <id>https://xanthorrhizol.github.io/posts/fear/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/fear/">&lt;p&gt;공포 마케팅은 한국에서 가장 잘 통하는 마케팅 중 하나이다. 미래를 대비하지 않으면 큰일이라도 나는 줄 안다. 가만히 있으면 도태되는 줄 안다. 그러면서 자신은 지금 무엇을 하고 있는지 모른다. 그저 시간을 흘려보낸다. 새롭고 획기적인 것을 찾아 불나방처럼 돌아다니기도 한다. 공포 마케팅을 하는 대표적인 업계는 사교육, 그리고 헤드헌팅 업계이다.&lt;br &#x2F;&gt;
하지만 성장은 눈에 보이는 성과에서 오는 것이 아니다. 지난하고 지루하고 반복적인 훈련을 통해 오는 것이다. 성과는 그것이 한 번씩 드러나는 과실에 불과하다. 사과나무의 본체는 나무이지, 사과가 아니다.&lt;&#x2F;p&gt;
&lt;p&gt;ChatGPT? 그녀석은 그냥 부하 직원같은 존재다. 게다가 머리가 애매하게 좋은 녀석이다. 리더가 얕보이는 순간 그놈은 리더를 속이려 들 것이다. 지식에 대한 지능은 높지만 사회지능이 없거나 낮은 인간의 특성과 동일하다. 물론 그녀석이 매니저를 대체할 수는 있겠다. 그 윗 라인을 속여먹으려 들지만 않는다면 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 우리가 해야 할 것은 명확하다. 그리고 바뀐 것이 전혀 없다. 우린 이미 정보화사회에서 가장 중요한 것은 사실과 거짓을 판별하는 능력이라 배웠다. 그것은 바뀐 것이 없다. 그걸 하기 위해서는, 머리를 쓰는 능력 자체를 길러야 한다. 단편적인 지식은 당장은 진리같아 보여도, 실제로는 일회용품에 가깝다.&lt;&#x2F;p&gt;
&lt;p&gt;문제의 그 AI라는 녀석은, 지금 특히 프로그래머들에게 공포의 대상이다. 그 외 여러 직군들도 마찬가지인 듯 하지만, 요바닥은 거의 집단 우울증에 걸린 듯한 모습이다. 뭐해먹고 사나에 대한 이야기를 많이 듣는다. 하지만 난 확신한다. AI의 희생자가 될 사람은, 실제로 AI에게 먹혀서가 아니라, AI에 대한 공포에 휘말려 스스로 포기한 사람들일 것이다. 결국 남은 사람들은 그 AI라는 녀석을 써서라도 생산성을 몇배나 더 향상시킨 상태로 그들의 빈자리를 유지해야 할 것이다. 채용이 줄어들 것은 뻔한 양상이기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;난 과거 파쿠르를 했었다. 꽤나 몰입했었다. 2012년부터 2017년까지 했었다. 당시엔 원류의 철학이 대세였던 시절이었다(훈련도 지옥훈련이었다 ㅋㅋ). 내가 파쿠르 철학 중 깊히 새긴 것은 아래와 같다.&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;유용하기 위해 강해져라.&lt;&#x2F;li&gt;
&lt;li&gt;다같이 시작해서 다같이 끝낸다.&lt;&#x2F;li&gt;
&lt;li&gt;넘어지는게 두려우면 그 두려움 때문에 넘어지게 된다.&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;p&gt;현대의 AI에 대한 공포에 대해 대답해줄 수 있는 것은 3번이 아닐까 싶다. 그리고 살아님기 위해서는 1번과 2번을 실천하면 된다. 물론 2번은 사람에 따라 의아할 수도 있겠다. 하지만, 파쿠르철학에서 2번은 생각보다 구체적이고 일리가 있다. 사람마다 강점과 약점이 다 존재한다. 결국 가능하다면, 모두가 함께 가야 한다. 누군가는 낮은 담을 잘 넘고, 누군가는 높은 담을 잘 넘는다. 누군가는 체구가 작아 좁은 틈을 잘 비집고들어가고, 누군가는 힘이 좋아 도약을 위한 발디딤을 도와줄 수도 있다. 누군가는 그 사람들을 화목하게 유지시키기도 한다. 모두 능력이다. 높은 담을 넘을 때, 발디딤을 도와주면 말도 안되는 높은 담에 오를 수 있다. 그 사람은 거기서 다시 밑에 있는 사람을 잡아줄 수 있다. 그 도움을 받은 사람은 담을 못오르는 사람을 잡아줄 수 있다. 도약을 도와준 사람도 마찬가지로 담을 오르게 된다.&lt;&#x2F;p&gt;
&lt;p&gt;장애물은 낮은 펜스만 있는게 아니다. 낮고 넓은 장애물도 있고, 높고 얇은 장애물도 있고, 높고 넓은 장애물도 있다. 울퉁불퉁하기도 하고, 미끄럽기도 하다. 그건 내가 바꿀 수 없다. 그냥 거기에 있다. 그냥 저기서 나타난다. 심지어는 갑자기 달려드는 자동차도 하나의 장애물이다. 장애물이 원하는 모양이 아니라 해서 그걸 탓하면, 그것이 바로 당신이 그렇게도 무서워하는 도태의 지름길이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>블로그 제작이 너무 쉽다</title>
        <published>2025-12-25T00:00:00+00:00</published>
        <updated>2025-12-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/blog/"/>
        <id>https://xanthorrhizol.github.io/posts/blog/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/blog/">&lt;p&gt;Notion에 일기마냥 글을 쓰고 있었는데, ChatGPT의 &quot;다 들고와 뭐든 만들자!&quot; 하는 성향 덕분에 블로그가 탄생했다.&lt;br &#x2F;&gt;
깡 html, js, css로 그냥 끝나버렸다.&lt;br &#x2F;&gt;
마크다운도 그냥 갖다쓰면 된다.&lt;br &#x2F;&gt;
글? vim 쓰는 사람이 웹에 에디터 붙일 필요가? 없다.&lt;br &#x2F;&gt;
만족이다.&lt;&#x2F;p&gt;
&lt;p&gt;친절한 블로그는 절대 아니다.&lt;br &#x2F;&gt;
내가 기억하기 위한 일기일 뿐이다.&lt;br &#x2F;&gt;
그래서 링크도 공개 안했다.&lt;&#x2F;p&gt;
&lt;p&gt;유저 트레킹도 안한다.&lt;br &#x2F;&gt;
내가 싫어하는데 남한테 할 이유가 없다.&lt;br &#x2F;&gt;
사실 귀찮은게 더 크다.&lt;br &#x2F;&gt;
겸사겸사 배려의 차원인걸로 포장해 봤다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>부서이동 후기</title>
        <published>2025-10-28T00:00:00+00:00</published>
        <updated>2025-10-28T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/dept-movement/"/>
        <id>https://xanthorrhizol.github.io/posts/dept-movement/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/dept-movement/">&lt;p&gt;ML Platform 팀으로 이동했다. 지금은 인수인계를 받고 있는 단계다. 이동한 팀의 팀장님이 이직을 하는 바람에, 기존에 계시던 분이 팀장으로 승진하면서 문서 정리와 동시에 실무까지 도맡으면서 인수인계 일정이 조금 길어지고 있다. 물론 아직 3일밖에 안됐다. 일단 빠르게 잡다구리한 일이라도 분담해야 할 것 같다. 과중한 상황을 겪어봐서 알기 때문이다. @!#$!#@!#@&lt;&#x2F;p&gt;
&lt;p&gt;일단 인수인계 준비하시는 것을 기다리면서, 쿠버네티스 개발환경 구축하는 과정을 따라가고 있다. KVM + QEMU 기반으로 로컬에 클러스터를 올리고 있다. 24스레드 머신이라 다행이다. 오늘 일단 클러스터 올리는 것은 다 마무리되었다. 하지만 GPU를 VM에 할당하다가 다 어그러졌다. 일단 재부팅을 해뒀고, 내일 더 볼 생각이다. 안되더라도, 손이 엄청 빨라졌기 때문에 딱히 걱정 없다.&lt;&#x2F;p&gt;
&lt;p&gt;오랜만에 쿠버네티스를 만져서 기억이 안날까 좀 걱정이었는데, 머리가 아닌 손이 기억하고 있었다. 내 생각에, 난 머슬메모리 용량이 뇌용량보다 큰 듯 하다. 아니, 뇌가 근육으로 이루어져 있는건가. 그리고 이번에 KVM + QEMU 조합을 처음 써봤는데, 커맨드라인으로 VM 관리 다 하니까 쾌감이 있다. VirtualBox는 커맨드라인에서 사용하면 아주 불편한데, 이건 아니다. 그냥 kubectl 쓰는 느낌이다. &lt;code&gt;virsh edit &amp;lt;vm_name&amp;gt;&lt;&#x2F;code&gt; 하면 그냥 XML 직접 수정이 가능하다. 내가 좋아하는 뺨 쎄리며 개발하는 그 느낌 맞다. 내 전공인 체육교육학을 영어로 쓰면 Physical Education인데, 물리적 교육이다. 맞다. 때려서 길들이는거다. 딱 대.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;속지 마라.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;또 한 가지, 관심 직무를 각자 이야기했는데, 정말 운이 좋게도 각자 다 달랐다. 난 고전적인 인프라 엔지니어링과 보안에 관심이 있다. 새로 입사하신 분은 클라우드에 관심이 있다. 팀장님이 이직하는 바람에 갑자기 신생팀처럼 된 면은 있지만, 그래도 관심사에 빈틈은 없는 듯 하다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>뚫었다 용인</title>
        <published>2025-10-11T00:00:00+00:00</published>
        <updated>2025-10-11T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/journey-to-youngin/"/>
        <id>https://xanthorrhizol.github.io/posts/journey-to-youngin/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/journey-to-youngin/">&lt;p&gt;그렇다 뚫었다. 그것도 용인의 내가 자주 가던 필드인 용인대학교를 찍는데 성공했다. 내비게이션 안찍고 말이다. 물론, 이번에도 용인의 어디를 갈지는 미정이였다. 심지어 이 상태는 용인에 도착한 이후에도 미정이었다. 용인시청 표지판이 보일 때까지 목적지를 몰랐다.&lt;&#x2F;p&gt;
&lt;p&gt;저번의 실패를 교훈삼아, 이번엔 섵불리 경기도 지역을 향한 표지판을 따라가지 않기로 했다. 저번에 실패했던 이유는, 안양 표지판이 보여서 섵불리 빠졌다가, 서부간선지하도로를 타게 됐고, 이후 복잡한 길에서 방향을 잃고 대충 시흥을 향했던 선택이 틀렸기 때문이었다. 이번엔 올림픽대로에서 좀 더 동쪽으로 갔다. 그러다 어항 모양 안에 1번이 적힌 표지판을 봤다. 1번이니까, 경부선 아닐까? 하고 따라가니 경부고속도로였다. 과거 용인으로 다닐 때도 경부고속도로를 종종 이용했었다.&lt;&#x2F;p&gt;
&lt;p&gt;경부고속도로를 타고 가다 보니, 용인서울고속도로가 나왔다. 바로 빠졌다. 그리고 종점까지 감. 그럼 용인이겠지. 그리고 나서는, 갈림길이 있었다. 갈림길에서 어디로 가야 하는지 확실히 모르는 상황이었는데, 신갈이 보였다. 용인과 신갈이 표지판에서 같은 방향으로 붙어있는 경우가 많았던 것을 떠올렸다. 그래서 신갈을 따라갔다. 물론 중간에 잘못 빠져서 한 바퀴 돌고, 난리도 아니였다.&lt;&#x2F;p&gt;
&lt;p&gt;신갈을 따라가다 보니, 용인시청 표지판이 나오기 시작했다. 오! 목적지는 용인대다! 용인시청을 향해 쭉쭉 따라가다가 용인대에 도착했다.&lt;&#x2F;p&gt;
&lt;p&gt;이제 남은건 돌아가는 것. 근데 방광을 비워야 한다. 다이소에 가서 화장실 들르는 김에, 감자칼을 샀다. 사야지 해놓고 까먹었던건데 마침 눈에 보였음. 그리고 간식 시간이었어서, 물과 간식을 사들고 다시 집으로 향함.&lt;&#x2F;p&gt;
&lt;p&gt;길 잘못 들러서 경부고속도로를 또 같은 방향으로 탔다. 그래서 동탄을 지나 오산까지 내려감. 오산 톨게이트를 빠져나온 후, 어디든 들어가서 유턴해서 되돌아갔다.&lt;&#x2F;p&gt;
&lt;p&gt;그렇게 경부선 타고 온 길로 그대로 돌아가면 됐는데, 또 다른 시도를 했다. 인천 방향으로 빠지는 것이다. 경부선 끝단으로 가면 신사역인지 어디인지, 여튼 강남권이다. 싫다. 막힐 것 같았다. 그래서 인천 방향으로 빠졌다. 서쪽으로 가다가 적당할 때 북진해서 집으로 가기로 했다. 무슨 도로인지도 모르고 그냥 쭉 따라왔다. 찾아보니 영동고속도로였음. 어디쯤에서 빠지지…? 하고 고뇌하던 찰나에, 서서울이 나옴. 개꿀! 나 서울 서쪽 삼! 바로 빠졌다.&lt;&#x2F;p&gt;
&lt;p&gt;익숙한 금천구가 나왔다. 고놈의 금천구! 얼마 안가 또 서부간선지하차도가 등장했다. 그거 뚫고 나오니, 다음 문제는 성산대교 vs 수서였다. 성산대교가 몇번째더라? 수서랑 수색도 맨날 헷깔려서 재확인이 필요했다. 하지만 곧 결론이 남. 수서엔 수서역이 있고, SRT에 좋은 노선 다 준다고 코레일이 삐졌던 사건을 알고 있다. 그럼 수서는 강남 근처일 것이다. 성산대교는 내가 일산에서 회사로 갈 때 중간에 지나친 대교다. 따라서 성산대교쪽이 확실히 서쪽이다. 성산대교쪽을 따라가서 건넜고, 강변북로에서 가양대교를 건너 집으로 돌아왔다.&lt;&#x2F;p&gt;
&lt;p&gt;후기: 기분 째질거같은데 에너지도 바닥 찢고 지하로 감.&lt;&#x2F;p&gt;
&lt;p&gt;반성: 적당히 하자.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>OS - 2) Process API</title>
        <published>2025-10-11T00:00:00+00:00</published>
        <updated>2025-10-11T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/os-2-process-api/"/>
        <id>https://xanthorrhizol.github.io/posts/os-2-process-api/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/os-2-process-api/">&lt;p&gt;이 단원은 실용적인 부분들, 즉 실제로 손맛 느껴보는 단원이다. 그래서 이론 위주의 공부를 하고싶은 사람은 넘겨도 된다고 써있었다. 하지만, 그거 아는가? 답정너식 화법 말이다. “난 이거 너희들이 읽었으면 좋겠지만, 이론 위주의 공부만 할거라면 넘겨도 돼. 근데 난 너가 이걸 읽었으면 좋겠어. 여튼 그렇다고. 아 네버 마인드.”&lt;&#x2F;p&gt;
&lt;p&gt;아아아아 알았다고! 그래서 여튼 읽었다. 이 공부, 급하지 않으니까. 손맛 한 번 느껴보자(하면서 실상 코드 손으로 안침 ㅋ).&lt;&#x2F;p&gt;
&lt;p&gt;이 단원은 fork, wait, exec 함수를 실제로 사용해보면서 무슨 일이 일어나는지를 이해하는 것을 목적으로 하고 있었다. 그래서 사용해보면서 또 GPT 선생 붙잡고 내가 이해한 내용이 맞는지 체크를 받으면서 추가적인 이해를 더했다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;fork&quot;&gt;&lt;code&gt;fork()&lt;&#x2F;code&gt;&lt;&#x2F;h2&gt;
&lt;p&gt;프로세스를 복제떠서 자식 프로세스로 실행하는 함수이다. 처음엔 현재 상태의 메모리 자원을 공유한다. 그러다 수정이 일어나는 시점에 해당 자원을 카피해서 독립성을 부여한다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;Copy-on-Write(COW)라 칭한다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;그리고 좀 더 파봤는데, 커널 객체는 공유되고, 스택&#x2F;힙&#x2F;전역변수와 같은 유저공간 데이터는 복사가 일어난다. 커널 객체는 기본적으로 파일 디스크립터(fd)가 가리키는 객체인데, 파일, 소켓 버퍼, 파이프 버퍼 등이 있다. 사실 그냥 입출력 객체는 다 fd로 접근한다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;pipe는 &lt;code&gt;ls | grep hello&lt;&#x2F;code&gt; 할 때 그 pipe 맞다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;h2 id=&quot;wait&quot;&gt;&lt;code&gt;wait()&lt;&#x2F;code&gt;&lt;&#x2F;h2&gt;
&lt;p&gt;기다리는거 맞다. 누가 누굴 기다릴까? 부모가 자식을 기다린다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;exec&quot;&gt;&lt;code&gt;exec()&lt;&#x2F;code&gt;&lt;&#x2F;h2&gt;
&lt;p&gt;다른 프로그램을 실행시켜서 프로세스를 전환하는 함수이다. 이 시점에서 프로세스는 전혀 다른 프로세스가 되어 있다. pid는 그대로다. 말 그대로 바꿔치기다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;wae-igeol-alaya-haneunga&quot;&gt;왜 이걸 알아야 하는가&lt;&#x2F;h2&gt;
&lt;p&gt;이게 미묘하다. 일반적인 케이스에서 이걸 다룰 일은 흔치 않다. 아니, 거의 없다고 봐도 무방하다. 하지만, OS관점에서 이 함수들은 아주 중요하다. OS가 하는 일 중 가장 중요한 일은 동시에 여러 프로세스를 돌리는 일이다. 그리고 OS도 하나의 프로그램이다. 즉, OS가 프로세스로서 다른 프로세스를 생성하고 관리하기 위해 fork, exec, wait은 필수불가결한 존재이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;process-control-and-users&quot;&gt;Process Control And Users&lt;&#x2F;h2&gt;
&lt;p&gt;방금 본 저 3개의 함수 외에도, 프로세스를 컨트롤하는 함수들이 더 있다. 대표적으로 &lt;code&gt;kill()&lt;&#x2F;code&gt;이 있다. 말 그대로 kill이다. 근데, 죽인다고 생각하는게 아니라, 슬슬 꺼져랏! 하고 저주를 보내는 함수라고 보면 좋다. 프로세스로 시그널을 보내는 것이다. 익히 사용하는 Ctrl+C는 SIGINT, Ctrl+Z는 SIGSTOP이다. 둘 사이의 차이는, 쉽게 설명하면 “꺼져랏!”과 “비켜봐!”의 차이다. SIGINT는 정말 프로세스를 중단할 때 이용한다. 그에 반해, SIGSTOP은 잠시 멈춰주는 신호다. 실제로 프로세스의 state가 stop으로 변경된다. 그리고 그걸 다시 실행할 때는 &lt;code&gt;fg&lt;&#x2F;code&gt; 명령을 이용한다. 리눅스 사용하다가 간혹 Ctrl+Z를 잘못 누르면, 이렇게 살려내면 된다. 몰랐다면 참고 바람.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;백그라운드 프로세스&lt;&#x2F;strong&gt;&lt;br &#x2F;&gt;
SIGSTOP 후에 멈춘 프로세스는 백그라운드 프로세스가 아니다. 멈춰 있는 프로세스일 뿐이다. 이와 다르게, 백그라운드 프로세스는 돌고 있는 프로세스다. 단지 포그라운드가 아닐 뿐이다. 끝에 &lt;code&gt;&amp;amp;&lt;&#x2F;code&gt; 을 붙여서 실행한다던가 했을 때 생기는 프로세스가 백그라운드 프로세스다. SIGSTOP 후에는 &lt;code&gt;bg&lt;&#x2F;code&gt; 명령을 통해 백그라운드로 재개해야 백그라운드 프로세스로서 돌릴 수 있다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;프로그램에서 시그널을 받았을 때, 원하는 동작을 더 끼워넣으려면 &lt;code&gt;signal()&lt;&#x2F;code&gt; 함수를 이용해서 작정하면 된다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;그러면 한 가지 궁금증이 더해진다. 시그널은 어디로 들어올까? 부모? 자식? 알아보니, 해당 프로세스 그룹 전체에 도달한다. 부모와 자식 모두다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;다음은 유저로서 시그널을 어디까지 보낼 수 있는가에 대한 문제가 아직 남아있다. 기본적으로 시그널을 보낼 수 있는 대상은 같은 유저 소유의 프로세스에 한한다. 정리하면, 시그널은 같은 유저 소유의 프로세스 그룹에 보내진다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;그래서 이런 것도 가능하다. tty1에서 로그인한 후에 GUI를 올렸는데 그게 먹통이 되었다. 그럼 Ctrl+Alt+F#키를 이용해서 다른 tty로 진입하면 해결할 수 있다. 같은 유저로 로그인하거나, root로 로그인해서 그 GUI을 죽일 수 있다. 본체 버튼을 억지로 눌러서 비상종료할 필요가 없다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;h2 id=&quot;rtfm-read-the-man-pages&quot;&gt;RTFM: Read The Man Pages&lt;&#x2F;h2&gt;
&lt;p&gt;동료에게 설명하기 귀찮을 때 RTFM을 시전하라고 한다. 이거 무슨 나같은 감성이다. 실제로 RTFM의 의미는 “Read The Fucking Manual”이라고 한다. 내 생각에 이건 그냥 “Read The Man Pages”로 풀어쓰는게 나을 듯 하다. 논쟁할 동료 학생이 없다. 회사에서 RTFM 그대로 쓰는 순간, 그냥 “책임지고 사퇴하겠습니다” 해야 한다. 만약 내가 RTFM을 외치면 퇴사 신호로 봐야 한다.&lt;&#x2F;p&gt;
&lt;p&gt;이후에 Useful Tools 챕터가 나왔는데, 리눅스 커맨드에서 자주 이용하는 기본 명령어들(ex. &lt;code&gt;ps&lt;&#x2F;code&gt; , &lt;code&gt;top&lt;&#x2F;code&gt; , &lt;code&gt;kill&lt;&#x2F;code&gt;)을 RTFM하라는 내용이라 굳이 남겨둘 만한 메모는 없다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>1종 수동 면허 취득</title>
        <published>2025-10-07T00:00:00+00:00</published>
        <updated>2025-10-07T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/driver-license/"/>
        <id>https://xanthorrhizol.github.io/posts/driver-license/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/driver-license/">&lt;p&gt;과한 운동은 아직이다. 가끔 에너지가 애매하게 차올라서 뇌가 착각을 하는지, “야야야 움직여! 뭐 해보자!!!!” 할 때가 있었다. 근데 그 때 그걸 따르면 초기화된다. 그걸 몇 번 당하고 나서, 적정 지점을 찾았는데, 그것은 드라이브였다. 운전을 하면 내 조작을 통해 실제로 속도가 발생한다. 그래서인지 뇌가 잘 속는 듯 하다. 그러고 나면 진정되고, 잠도 잘 온다. 효율이 좋다. 그 대신 허리 충격을 덜어주기 위해 충격흡수 방석을 깔고 운전하고, 복압을 유지하는데 신경을 쓴다.&lt;&#x2F;p&gt;
&lt;p&gt;드라이브는 어떻게 하냐면, 그냥 네비를 찍지 않고 아무 대나 찾아간다. 처음엔 집 근처에서 잠시 도는 정도였는데, 에너지 레벨이 회복되어 가면서 갈수록 길어졌다. 그래서 저번엔 자유로를 타고 쭉 가다가 판문점 표지판이 보여서 급히 빠져나와 임진각을 찍고 돌아왔다. 최근엔 인천공항을 찾아갔다. 그러나 나오는 길에 송도 표지판이 보이길래, 에너지가 남아서 학교를 찾아가서 찍고 돌아왔다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;송도는 근데 표지판 글씨가 너무 작아서 길을 많이 헤맸다. 글자가 보이면 이미 늦은 경우가 많았다. 정말 에너지 넘칠 때만 가야 한다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;그런 네비게이션 없는 드라이브를 하면서, 어느날 문득 운전 자체가 심심해졌다. 하지만 그렇다고 난폭운전을 할 수는 없다. 그 몇 초 사이의 고민 결과 “운전의 난이도를 올리면 되잖아?” 하는 묘안을 떠올렸다. 그래서 수동변속이 궁금해졌다. 그 길로 집 돌아가는 길에 운전면허학원에 들러서 1종 수동면허 과정을 등록하고 돌아왔다. 비용은 대충 50만원 정도 든다. 그걸 몇 초 사이의 고민 후에 질러버린 것이다. 이건 충동을 제어하지 못하는 비정상적인 정신상태에 기인한 지출이다. 따라서 의료비로 봐도 될듯? 물론 개소리다.&lt;&#x2F;p&gt;
&lt;p&gt;그래서 어찌저찌 수동변속기 사용법을 익히고 면허도 취득했다. 결과는 대만족이다. 자동변속기 차량을 운전하면서, 차를 멈추려고 브레이크를 잡고 있으면 마지막쯤에 뭔가 해방되듯 살짝 밀리는 현상을 느껴 왔는데, 그 이유를 알게 되었다. 1단 기어가 감당하는 속도 레벨 이하까지 내려가면 클러치를 밟아 동력을 해제하기 때문이다. 그러면 엔진브레이크에서 해방되고, 속도 감소폭이 줄어들게 되어 더 밀리는 듯한 느낌을 받는 것이다. 물론 이걸 알아낸 것도 좋았지만, 실제로 수동변속 자체가 재미있기도 했다. 아치리눅스 감성이다. 주석이 없어 추리해야 했던 그 체결률 공식의 중복된 두 파라미터의 관계같기도 했다. 물론 그건 필요없이 두 개가 된거지만, 이건 필요해서 2개다. 변속이 있으려면 파라미터가 두개여야 한다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;체결률 공식의 파라미터 이야기는, 대충 y절편을 변화시키는 파라미터가 2개 있었는데, 서로 그냥 곱하기였다. 하나는 분자에, 하나는 분모에 들어가는 느낌과 비슷하다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;물론, 막히는 길에서 지옥을 맛본다는 이야기에는 대찬성이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>어른이 더 좋은 점</title>
        <published>2025-10-07T00:00:00+00:00</published>
        <updated>2025-10-07T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/what-is-better-than-child/"/>
        <id>https://xanthorrhizol.github.io/posts/what-is-better-than-child/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/what-is-better-than-child/">&lt;p&gt;다들 어른이 되고 나서 힘들다 힘들다 하는데, 사실 그렇지만은 않다. 물론, 어른이 되면 자기를 스스로 책임져야 하기 때문에 누군가의 케어를 받던 시절보다 몇 배로 고달프고 힘든건 사실이다. 하지만, 그걸 하나씩 공략하는 맛도 있다. 초 고난이도 RPG 게임을 한다고 생각하자.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;keeoreul-badneun-daega&quot;&gt;케어를 받는 대가&lt;&#x2F;h2&gt;
&lt;p&gt;다들 자기가 케어를 받기만 했다고 생각한다. 하지만, 그 대가는 없지 않았다. 물론, 가족 뽑기운에 따라 이 대가의 크고 작음이 다르다. 누군가는 부모님이 강압적이어서 부모님 그늘 아래 꼭두각시처럼 살아야 하는 대가를 치른다. 누군가는 부모님의 인성이 나빠 스트레스를 지고 산다. 누군가는 부모님이 아프거나, 경제적 능력이 없어 소년&#x2F;소녀가장을 해야 하는 경우도 있다(물론 이 경우 케어를 받는다고 하긴 어렵겠다). 또 누군가는 부모님의 전폭적인 지지 아래 꿈을 이루기 위해 드라이브를 걸기도 한다. 또 누군가는, 적당한 부모님 밑에서 평범하게 산다. 이건 다 뽑기운이다. 태어나는 것 자체도 내 선택이 아니기 때문이다. 그리고 내가 받은 유전자와 기질도 모두 뽑기운이다.&lt;&#x2F;p&gt;
&lt;p&gt;하지만 한 가지는 확실하다. 우린 대부분 학교에 다니면서, 얕디 얕은 다양한 과목을 공부한다. 연결고리를 하나씩 생략해 둔 채 암기를 요구한다. 내가 그 과목에 관심이 있든 없든, 어느 정도 강제적으로 그 공부를 해야 한다. 그럼 그게 잘못된 것일까? 아니다. 폭넓은 분야를 접하고 그에 대해 사고해보는 것은 인간으로서 기본 덕목을 기르는데 필수적이다. 말이 통하는 사회가 되기 위한 밑바탕이 된다. 물론 모두가 그걸 열심히 하지는 않지만, 적어도 그것들을 배울 기회를 제공하는 것은 필요하다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;그런 의미에서 수능과 대입에 도움이 안되는 과목들에 대해 아이들 학습로드만 가중시킨다고 주장하는 학부모들은 제일 먼저 자기 자신을 돌아봐야 한다고 생각한다. 아이들 학습 로드를 가중시키는 것은 학교가 아니라, 학원 뺑뺑이를 돌리는 부모들이다. 어차피 과목수 줄여도 애를 한시도 가만히 두지 않고 학원 뺑뺑이를 시키는건 매한가지일 것 아닌가. 문이과를 분리하고, 미적분을 없앤다 한들, 애들이 학원을 덜 다니고, 놀아야 할 때 더 놀았을까? 아니다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;또 한 가지, 그 시절은 점수가 전부인 것처럼 돌아간다. 아무리 다양한 경험을 했다고 해도, 그냥 점수로 요약된 후 대입에 소비하고 끝내버린다. 그리고 그 스토리들은 스스로 잡고 있지 않는 이상 휘발된다. 마치 한 사람의 인간으로서 지내지 않는 것과 비슷하다. 다행스럽게도 이 현상은, 연구&#x2F;사무직군에 대한 투자 대비 매력도 하락으로 인해 꽤나 완화되고 있는 것으로 보인다. 각자 스탯이 많이 찍혀 있는 대로 직업을 가지고 적재적소에 배치되는 것이다. 하지만 이 변화의 중심에 있는 세대는 기성세대들과 한바탕 침튀기게 싸움을 해야 할 것이다. 자기 자신에 대해 있는 그대로를 받아들이라고 강요할 수 없는, 반대로 강요받을 수는 있는 그것이 바로 케어를 받는 대가이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;eoreuniran&quot;&gt;어른이란&lt;&#x2F;h2&gt;
&lt;p&gt;어른은 뭐 크게 대단한게 아니다. 내가 정의내린 어른의 기준은, 그냥 자기가 자기 입에 풀칠하는걸 스스로 하는가이다. 경제적인 이야기를 한거같지만, 그걸 시작으로 어른이 가지는 힘든 점과 좋은 점이 모두 따라온다. 구분하기 쉽도록 예시를 두 개 나열해보면 아래와 같다.&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;부모님과 함께 사는 사람은 어른일까? 만약 부모님과 함께 사는데, 그 가구에서 경제적으로 일조하고 있다면 어른이다. 하지만 그게 아니라 모든걸 빌붙으며 자기가 번 돈을 그저 모으고 있다면, 그건 어른이 아니다. 물론 여기서 반발할 사람이 많을 것이다. 자기 나름의 계산이 있을 것이고, 그것이 앞으로의 삶에 아주 유리한 방향은 맞기 때문이다.&lt;&#x2F;li&gt;
&lt;li&gt;부부 중 한 명이 전업주부를 한다면 그 사람은 어른이 아닐까? 아니다. 어른이다. 부부는 법적으로 경제공동체로 묶인 관계이기 때문에 그 공동체에 기여하는가가 중요하다. 전업주부는 가사노동을 통해 그 가정의 경제적 가치를 창출하고 있는 것이다. 그것이 없으면 외식, 돌봄 및 교육에 관한 비용이 추가로 들게 된다. 근데 만약 전업주부이면서 집안일을 하지 않는다면? 맞다. 그건 어른이 아니다. 만약 그 부부가 이혼했을 때, 한 쪽이 감정적인 부분 이외에 전혀 불편함을 느끼지 못한다면, 그건 한 쪽이 어린이었기 때문이라고 볼 수 있다.&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;blockquote&gt;
&lt;p&gt;주의할 것이 있다. 어른이 꼭 더 좋고 훌륭하고, 어린이는 그렇지 않은 존재라는 개념은 오류다. 모두 그냥 인격체다. 부모님과 함께 살며 자기 몫을 살뜰히 챙기는 사람은 결국 잘될 것이다. 감정이나 이상보다는 현실을 보는 사람이기 때문이다. 케어를 하는 주체가 객체를 그정도로 소중히 할 수 있다는 것은, 그 사람 자체가 그에게 그 정도의 가치가 있기 때문이다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;난 어른으로서 살기를 택했다. 그래서 위와 같은 기준에 따라, 일산의 부모님 소유 주택에서 지하에 방을 얻어 살 때, 매달 월세 명목으로 30만원을 부모님에게 송금했다. 증여세, 상속세 등의 세금 관점에서 봤을 때 어리석은 짓이긴 하지만, 이게 바로 적당한 집안 사람들이 누릴 수 있는 특권이기도 하다. 내 기준을 지키기 위해 일정 손해를 감수할 수 있는 것이 내 특권이다. 만약 우리 집안에 재산이 많았다면 이건 꿈도 못 꿀 것이다. 나라로부터 뚜드려맞을 세금폭탄이 두려워서라도 자기 기준을 져버리고 세금에 최적화된 재무적 관계를 유지해야 했을 것이다. 물론 그걸 모두 포기하는 방법도 있긴 하다. 마음먹기 더 어렵겠지만 말이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;eoreuni-doemyeonseo-himdeun-jeom&quot;&gt;어른이 되면서 힘든 점&lt;&#x2F;h2&gt;
&lt;p&gt;생각보다 스스로를 먹여 살리는게 힘들다. 어른은 곧 경제적 독립이라 했다. 그 독립은 일자리를 구하거나 사업을 해야 가능해지는데, 결국 사회의 톱니바퀴 중 하나가 된다는 뜻이다. 철광석을 갈고 갈아 결국 어디든 맞는 자리에 끼워넣는 것인데, 이게 쉬울 리가 없다. 수많은 충돌과 연마를 겪으며 자신의 자리를 찾아가게 되는데, 그 수준은 거의 생사를 오가는 수준이다. 부모와 학교의 보호를 받으며 자아관을 자유롭게 가질 수 있는 것은 어린이의 특권이다. 복권을 긁기 전에 그 복권의 결과는 자기 원하는 대로 상상해도 되는 것이다. 하지만 어른은 현실 속에 살아야 한다. 거기서 어린이는 한 번 이상 죽는다.&lt;&#x2F;p&gt;
&lt;p&gt;자기인식 자체에도 변화가 필요하다. 공학자와 기술자 중에서 뭘 할 것이냐 하고 이야기하며 은근하게 기술자를 까는 교수님의 이야기를 들으며 대학교를 다녀놓고, 난 기술자가 됐다. 마치 건축공학과에서 5년(설계 포함 과정)을 수료해 놓고, 자기가 설계자가 될 것으로 생각했던 사람이, 현장의 인부가 되는 것과 비슷하다. 깎아놓고 보니 그곳이 자기 자리였던 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;의식주를 해결하는 것도 정말 어렵다. 하루 24시간 중 8시간을 업무에, 8시간을 수면에 할애하고 나면, 8시간이 남는데, 여기서 3시간은 요리하고 먹고 정리하는데 써야 하고, 2-3시간은 출퇴근에 사용해야 하고, 남은 2-3시간에 비로소 자기계발과 여가활동을 할 수 있다. 그리고 이조차도 야근 한 번에 날아가버리기 십상이다. 그래서 다른 뭔가를 줄인다. 잠을 줄이거나, 집안일을 미루거나, 끼니를 패스트푸드로 대체하거나, 거르거나. 그리고 그것이 건강을 서서히 망친다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;eoreuni-doemyeonseo-eodneun-geos&quot;&gt;어른이 되면서 얻는 것&lt;&#x2F;h2&gt;
&lt;p&gt;경제적 독립은 아주 많은 것들에서 자신을 해방시킨다. 대표적인 것이, 부모님이 내 삶에 대해 왈가왈부할 수 없게 된다. 내 앞가림만 제대로 하면, 터치를 잘 하지 않는다. 그래서 난 대학 졸업 후에 오히려 라크로스를 더 자유롭게 할 수 있었다. 과거 부모님은 내가 라크로스 때문에 고생했을 때 “니 앞가림에 더 신경써라” 라는 꾸중을 했지만, 지금은 반대로 라크로스에서 얻은 것들이 더 많음을 인정해 주신다. 심지어는 기부를 해도 그냥 “이제 그럴 때가 됐구나?” 해주신다.&lt;&#x2F;p&gt;
&lt;p&gt;기한없는 공부도 가능해진다. 학창시절의 시험이라는 제도는 공부의 기한을 정해버리고, 깊게 파는걸 방해한다. 깊게 파면 시간이 많이 들고, 시험 점수엔 도움이 되지 않는다. 근의 공식을 그냥 외우면 한 시간 정도에 몇 문제를 맞출 기반을 얻지만, 그 근의 공식을 직접 유도하고 있으면, 유도 후에 시험을 위해 외우는 시간이 따로 더해지거나, 실제 시험장 가서도 시간을 들여서 근의 공식을 유도해야 하는 대참사가 벌어진다. 그에 반해, 기한이 없는 공부는 근의 공식을 유도하면서 시간을 보내고 있어도 문제될 것이 없다. 그리고 그것이 공부의 맛이다. 새로운 것을 이해한 순간, “아하!”와 함께 쾌감을 느낄 것이다. 마치 머리 속에서 정리되지 않은 것들이 갑자기 정렬하면서 그 사이에 길이 직선으로 뚫리는 느낌이다.&lt;&#x2F;p&gt;
&lt;p&gt;또한, 만약 자신이 뽑기운이 좋지 않아 어릴 때부터 과한 짐을 지고 있었던 사람이라면, 자립을 계기로 그 짐을 벗어던질 수도 있다. 부모는 자식을 “태어나지게” 한 대가로 자식을 책임져야 한다. 자식의 탄생은 부모의 선택으로 인한 것이기 때문이다. 따라서 부모-자식 간의 관계를 정의하는덴 자식의 선택권이 더 크다. 자식이 적당할 때 부모의 품에서 벗어나는 것은 자연의 순리이기도 하기 때문에, 그것을 정의할 기회는 꼭 온다. 그리고 그 시점에 자식에게 선택권이 생긴다.&lt;&#x2F;p&gt;
&lt;p&gt;사회에서 갈리는 과정 또한 결과적으로 이득이다. 자신이 본래 가야 했던 자리를 알고 난 이후엔 묘한 안정감도 얻는다. 자기 자신을 모르는 상태에서 미래를 그리는 것은 엄청난 불안을 수반한다. 그 사람은 어른이 되어가는 과정에서 자기 자신의 장단점을 명확히 알아가게 된다. 직접 부딪혀 봤고, 실패할건 실패하고 성공할건 성공했으니 말이다. 자신의 장단점을 아는 상태에서 미래를 그리면 미래를 좀 더 명확하게 그릴 수 있다. 물론, 자기 자신을 안다고 해도, 세상을 잘 모르기 때문에 불안한 것은 매한가지다. 하지만 내가 통제할 수 있는 것과 없는 것이 무엇인지를 구분하고, 통제할 수 있는 것들에만 집중한다면, 적어도 졌잘싸는 할 수 있다. 그리고 그 통제할 수 있는 것들이 많아지는 방법은 바로 어른이 되는 것이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>OS - 1) 프로세스</title>
        <published>2025-09-30T00:00:00+00:00</published>
        <updated>2025-09-30T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/os-1-process/"/>
        <id>https://xanthorrhizol.github.io/posts/os-1-process/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/os-1-process/">&lt;p&gt;진지하게? 는 역시 어렵다. 사실 시도도 안했다. 회고록같은건 진지하게 써놓고 스터디는 안 진지하게 간다고? 그래야 스터디에 흥미를 안 잃기 때문이다. 회고같은 과거로 돌아가는 짓거리는 한 번이면 족하다. 그래서 진지하고 재미없게 써야 한다.&lt;&#x2F;p&gt;
&lt;p&gt;첫 단원은 프로세스다. OS에게 그 짓거리(가상화)를 시키게 한 주범이다. 프로그램을 실행하면 그게 프로세스다. 프로그램은 Disk에 잠들어 있는 프로세스의 전신이다. 대충 관짝에 잠들어 있는 미라를 생각하면 된다. 그걸 실행하면 프로세스로서 도는 것이다. 미라가 든 관짝을 툭툭 쳐서 주문을 읊는 것이다. 약속된 방법으로 읽어다가 프로그램을 메모리에 로드하고, CPU로 연산을 진행하면 프로세스다. 프로세스를 동시에 여러개 돌리고 싶으니, CPU를 시간분할하고, 메모리를 공간분할한다. 마찬가지 이유로, 컴퓨터가 프로그램을 하나만 가지고 있으면 나머지 공간이 아까우니, 공간분할을 통해 복수의 파일을 보관할 수 있게 한다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;bunhal&quot;&gt;분할&lt;&#x2F;h2&gt;
&lt;p&gt;분할의 종류를 아주 간단하게 설명하면 아래와 같다.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;시간 분할(Time Sharing): 이거 하다가, 저거 하다가, 그거 하다가, …&lt;&#x2F;li&gt;
&lt;li&gt;공간 분할(Space Sharing): 여기부터 여기까진 이거, 저기부터 저거까진 저거, …&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;blockquote&gt;
&lt;p&gt;프로세스는 시간분할의 예로 나와 있긴 한데, 그냥 뭐든 분할의 개념이 뒤섞여 있다. 프로세스들이 올라간 메모리의 각 위치는 공간 분할의 결과다. 프로세스들의 실제 연산은 시간분할을 통해 병렬인 것처럼 돌아간다.&lt;&#x2F;p&gt;
&lt;p&gt;디스크도 마찬가지다. 공간분할의 예로 나오지만, 디스크의 읽기&#x2F;쓰기 동작은 시간분할이다. 얘도 어쨌든 하드웨어가 뭔 짓을 해야 일을 할 것 아닌가.&lt;&#x2F;p&gt;
&lt;p&gt;그래서 뭐는 뭐! 하는 사고방식은 오개념을 낳기 아주 쉽다고 본다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;h2 id=&quot;sigan-bunhalyi-rebel&quot;&gt;시간 분할의 레벨&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;High-level(Policy): Scheduling - 이럴땐 이렇게… 지금이닷! Context Switching!&lt;&#x2F;li&gt;
&lt;li&gt;Low-level(Mechanism); Context Switching - 눼, 실행! @_@&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;geuraeseo-peuroseseuga-mweonde&quot;&gt;그래서 프로세스가 뭔데?&lt;&#x2F;h2&gt;
&lt;p&gt;책에서는 실행중인 프로그램에 대해 제공하는 추상화를 프로세스라 했다. 사실 프로세스가 뭐냐 물으면 실행중인 프로그램이라고 할텐데, 다음 설명을 위한 밑밥으로 저렇게 어려운 표현을 쓴 듯 하다. 근데, 이렇게 생각하면 재미가 없다. 추상화는 주판과 계산기를 생각하면 직관적으로 이해하기 쉽다. 사람이 주판 사용법을 익혀서 손으로 하나하나 튕구는건 불편하다. 그 과정은 따로 배워야 할 정도로 복잡하다. 그런데 그 과정을 묶어다가 버튼 기반 인터페이스를 올린다면? 물론 계산기 내부가 주판으로 되어 있는건 아니겠지만 말이다. 여튼 계산기는 a + b를 구하기 위해 손가락을 이래저래 튕길 필요 없이, a + b를 버튼으로 입력하기만 하면 된다. 계산하는 과정을 모아다가 사람이 쓰기 좋게 추상화한 결과인 것이다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;peuroseseuyi-guseong-yoso&quot;&gt;프로세스의 구성 요소&lt;&#x2F;h3&gt;
&lt;p&gt;프로세스에서 접근할 수 있는 Machine State의 범위라고 보면 된다. Machine State는 CPU + 메모리 + I&#x2F;O 장치 전체의 현재 상태를 뜻한다. 컴퓨터 켜는데 최소로 필요한게 CPU, 메모리, 디스크다. 그것들의 현재 상태라는 이야기다. 그냥 컴퓨터의 지금 상태다. 그리고 거기서 프로세스가 접근할 수 있는 범위는 아래와 같다.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;프로세스가 접근 가능한 메모리 영역(address space)&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;프로그램을 메모리에 로드했을 때 그 구역이다.&lt;&#x2F;li&gt;
&lt;li&gt;익히 들은 스택, 힙, 코드 영역 등이 그거다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;li&gt;
&lt;p&gt;레지스터(register)&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;대충 CPU가 연산 중에 값을 잠시 보관해두는 곳이다. CPU에선 아래와 비슷하게 사용한다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;pre data-lang=&quot;x86asm&quot; class=&quot;language-x86asm &quot;&gt;&lt;code class=&quot;language-x86asm&quot; data-lang=&quot;x86asm&quot;&gt;MOV AX, 10 ; 10을 AX로 보내라
MOV BX, 20 ; 20을 BX로 보내라
ADD AX, BX ; BX를 AX에 더해라
MOV BX, AX ; AX를 BX로 보내라
...
&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;&#x2F;li&gt;
&lt;li&gt;
&lt;p&gt;영구저장장치(persistent storage device)&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;디스크와 같이 영구저장을 위한 장치들이다. SSD, HDD, Flash 메모리가 대표적.&lt;&#x2F;li&gt;
&lt;li&gt;근데, NVRAM은? → GPT선생이 가라사대, 그렇게 분류할 수는 있는데, OS 교재에서는 그거 취급 안한다 하였다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;process-api&quot;&gt;Process API&lt;&#x2F;h2&gt;
&lt;p&gt;아래는 OS에서 프로세스 관련 API로 제공해야 하는 것들이다.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Create&lt;&#x2F;li&gt;
&lt;li&gt;Destroy&lt;&#x2F;li&gt;
&lt;li&gt;Wait&lt;&#x2F;li&gt;
&lt;li&gt;Miscellaneous Control&lt;&#x2F;li&gt;
&lt;li&gt;Status&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;켜고(create) 끄는건(destroy) 당연히 있어야 하고, 부모가 자식 프로세스가 끝날 때까지 기다릴 수 있어야 하고(wait), 근데 이런저런 기능도 했으면 좋겠고(miscellaneous control), 프로세스의 현재 상태도 볼 수 있어야(status) 한다는 것이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;process-creation&quot;&gt;Process Creation&lt;&#x2F;h2&gt;
&lt;p&gt;잠든 미라를 깨워보자. 이 미라는 광부였다. 일단 디스크에서 파일이라는 관짝을 열어다가 미라를 갱도의 담당 구역으로 옮기는데(물론 실제로는 이동이 아니라 복사다), code와 static data을 메모리의 적절한 address space에 로드하는 것이다. 다음엔 담당 구역에 표시를 해준다. 스택과 힙 영역을 할당하는 것이다. 이후 미라를 깨워서 곡괭이를 손에 쥐어주고, “일해라” 하면, 그 미라는 일을 하게 될 것이다. CPU가 메인 함수를 시작으로 로직을 실제로 실행하는 것이다. 이 때, 메인함수여야 하는 이유는 간단하다. “일해라” 해야 일에 필요한 모든 것을 한다. “내려쳐라” 하면 그냥 그 자리에서 곡괭이를 아래로 내려치고 멈출 것이다. 다음은, 채광한 광물을 어딘가 저장하고 옮겨야 한다. 그래서 수레를 사용하면 이게 I&#x2F;O 작업이다. 그 수레를 옮겨 광물을 창고로 넣으면 이건 영구저장장치에 저장한 무언가가 된다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;process-states&quot;&gt;Process States&lt;&#x2F;h2&gt;
&lt;p&gt;프로세스의 상태는 세 가지가 있다. 이거 state다. Status 아니다.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Running: 내 일 지금 진행되고 있음. 땡큐&lt;&#x2F;li&gt;
&lt;li&gt;Ready: 나 이제 준비됨. 시간 되면 내 일도 해줘.&lt;&#x2F;li&gt;
&lt;li&gt;Blocked: 아 뭐 기다리는 중임. 딴거 먼저 하세요. 아 건들지 말라고!&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;Running과 Ready 상태 사이의 전환은 스케줄러가 해준다. “피카츄, 너로 정했다! 가랏 백만볼트!” 해주는 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;여기서, Blocked가 뭔지 궁금할 수 있다. 간단히 설명하면 정말 지금 다음껄 실행하면 안되는 상태다. 예를 들어, 파일의 내용을 읽는 작업이 있다고 치자. 그 작업을 디스크에 요청하면, 그 디스크가 그 작업을 끝내거나 중단할 때까지 프로세스의 다음 절차를 실행할 수 없다. 읽으라 해놓고 읽는걸 기다리지도 않고 “빨리 설명해봐!“ 하면 미친놈이다. 그래서 그걸 기다려달라고 표시하는 상태가 blocked다. Ready는 그냥 뒷전으로 밀려나 있는 일거리일 뿐, 언제든 실행될 수 있다.&lt;&#x2F;p&gt;
&lt;p&gt;하지만 실제로 예시로 제공된 xv6의 enum을 살펴보면, 다른 상태들도 몇 개 있다. 미사용(UNUSED), init 과정(EMBRYO), task가 다 돌고 난 이후(ZOMBIE)가 또 있다. 그리고 리눅스껀 또 다르다. 결국 이것도 구현하기 나름이라는 것이다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;UNUSED는 PCB(process control block)의 프로세스를 올릴 수 있는 슬롯이 미사용중이니 여기다 넣어도 된다는걸 나타내는 상태이다. 그래서 더 파보니, xv6같은 단순 OS는 미리 이 슬롯들을 정해진 크기로 할당해 둔 상태이기 때문에 있는 상태였다. 실제로 리눅스와 같이 실제로 이용하는 OS들은 동적으로 할당하는 방식이라 UNUSED 상태가 없다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;h2 id=&quot;data-structures&quot;&gt;Data Structures&lt;&#x2F;h2&gt;
&lt;p&gt;OS도 결국 다른 프로그램처럼 하나의 프로그램이기 때문에, 내부에 각종 데이터구조가 있다. 프로세스 구조체는 직접 그 소스를 보면 이해할 수 있다. 그중에서 가장 중요한 것은 context라 생각한다. 그리고 그 context 구조체를 보면, 그냥 레지스터의 값을 담는 구조체다. context switching이 발생하면, 직전에 running 상태였던 프로세스는 자신의 context에 레지스터를 저장하고, deregistered될 것이고, 이 프로세스는 context에 있던 레지스터의 값들을 레지스터로 다시 배치해서 EIP에 있는 코드를 실행할 듯 하다. 물론 context에 매 절차 마다 레지스터를 저장하는지, 컨택스트 스위칭이 일어날 때 저장하는지는 아직 모른다. 그건 OS를 개발하는 사람이 선택하면 될 일이기 때문에, 뚜렷한 답은 없을 것이고, 구현의 차이가 있을 듯 하다. 매번 저장하고 있으면 성능에 손해를 보기 때문에 아마 대부분 context switching이 일어날 때 저장하지 않을까 싶다. 물론 또다른 이유로 저장 주기를 타이트하게 가져갈 수도 있다. 장애를 대비한다던가? &lt;a href=&quot;https:&#x2F;&#x2F;namu.wiki&#x2F;w&#x2F;%EC%8A%88%ED%8D%BC%20%EB%A7%88%EB%A6%AC%EC%98%A4%2064&#x2F;%EB%B2%84%EA%B7%B8#s-5.1&quot;&gt;우주방사선&lt;&#x2F;a&gt;(????)을 대비한다던가?&lt;&#x2F;p&gt;
&lt;p&gt;다음으로, 프로세스의 실행 공간에 대한 정보가 있다. address space에 대한 것이다. 그 외에, 프로세스의 현재 상태에 관한 정보들이 포함되어 있다. process state 뿐만 아니라, 다른 더 필요한 것들도 있다. 쥐고 있는 파일들이라던가, 현재 디렉터리라던지 말이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>OS - 0) Introduction</title>
        <published>2025-09-29T00:00:00+00:00</published>
        <updated>2025-09-29T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/os-0-introduction/"/>
        <id>https://xanthorrhizol.github.io/posts/os-0-introduction/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/os-0-introduction/">&lt;p&gt;결국 여기까지 왔다. 네, Rust 커널 책 1-2주요? 개뿔! 초반에 Rust 언어의 사용법이 책 두께의 반 이상을 차지해서 얕봤다. 리눅스 커널 버전부터 다르고, Rust의 커널 관련한 부분의 개발이 활발한 바람에 이미 책은 EUC-KR 수준의 레거시가 되어 있었음. 실습 코드를 그냥 이해한 다음 그 목적을 하는 모듈을 짜보려다보니, 왜? 왜? 왜에에에에??? 가 연속되어 그냥 OS까지 들어가서 커널로 돌아오기로 했다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;정신 차리니 OS에 도착하는 과정&lt;&#x2F;strong&gt;&lt;br &#x2F;&gt;
&lt;code&gt;&#x2F;dev&#x2F;random&lt;&#x2F;code&gt; 을 Rust로 구현하기 → 왜 딴 애들은 &lt;code&gt;module!&lt;&#x2F;code&gt;  매크로 이용해서 모듈 선언하는데, 얘는 &lt;code&gt;module_misc_device!&lt;&#x2F;code&gt; 지? → 그건 그렇고… 없네? → 대체제 찾았다! → file operations에서 read, write 정의 못하네? → c shim 가자 → 이 삽질 할 시간에 본진을 때리는게 낫지 않음?&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;최고의 방어는 공격이다.  그래서 ChatGPT에게 커리큘럼 내놓으라 함. 그래서 접한 책은 아래와 같다.&lt;&#x2F;p&gt;
&lt;p&gt;https:&#x2F;&#x2F;pages.cs.wisc.edu&#x2F;~remzi&#x2F;OSTEP&#x2F;&lt;&#x2F;p&gt;
&lt;p&gt;pdf로 그냥 공개되어 있다.&lt;&#x2F;p&gt;
&lt;p&gt;여튼 그래서 슥 보고 있는데, 일단 개론 부분을 요약하면, OS가 존재하는 이유는 하드웨어 위에서 동시에 여러 일을 시키기 위해 가상화를 지원하는 것이다. cpu 1개짜리 머신이라고 프로그램 하나만 돌리면 아까우니까, 젖먹던 힘까지 다 끌어다 쓰기 위해 생긴거다. 힘내라 컴퓨터야. 인간들이 그렇지 뭐.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>바이브코딩? 구그르(?)코딩?</title>
        <published>2025-09-26T00:00:00+00:00</published>
        <updated>2025-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/googlre-coding/"/>
        <id>https://xanthorrhizol.github.io/posts/googlre-coding/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/googlre-coding/">&lt;p&gt;누가 엑셀 매크로 짜는걸 도와달라 해서 visual basic을 처음으로 써보게 되었다. 그러면서 바이브코딩이 이게 맞는진 모르겠지만, 여튼 ChatGPT를 좀 많이 괴롭혔다.&lt;&#x2F;p&gt;
&lt;p&gt;일단 visual basic 소감은, 생각보다 왠만한 것들은 다 있고, 생각보다 이런 것도 없는 그런 묘한 언어이다. 게다가 매서드 실행 결과를 못믿겠음. 대표적인 예가 Find, FindNext였는데, 특정 문자열과 일치하는 셀을 찾기 위해 사용했지만, 그냥 빈 셀도 다 얻어걸려서 화딱지 나서 그냥 for문으로 순회를 돌렸다.&lt;&#x2F;p&gt;
&lt;p&gt;ChatGPT를 활용한 방법은 아래와 같다.&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;function 정의 방법 → function, sub 차이점 이해&lt;&#x2F;li&gt;
&lt;li&gt;sub을 한 모듈에서 여러개 선언해도 되는지, 함수 or 자료형 선언 순저 중요한지 → 언어 별로 다를 수 있는 부분들 미리 파악&lt;&#x2F;li&gt;
&lt;li&gt;엑셀 시트의 내용 파악(어디에 뭐가 있고 한지) → 목적을 달성하기 위해 로직을 주석으로 쭉쭉 씀&lt;&#x2F;li&gt;
&lt;li&gt;주석을 구현하기 위해 “이런거 됨?” 하고 ChatGPT에 질문 → 잘 알려줌&lt;&#x2F;li&gt;
&lt;li&gt;데이터 파싱 되는 것 확인 후 시트에 쓰기 로직 구현&lt;&#x2F;li&gt;
&lt;li&gt;디버깅 및 삽질&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;p&gt;잘 보면 그냥 구글 대신 ChatGPT를 쓰는 것과 같다.&lt;&#x2F;p&gt;
&lt;p&gt;나도 늙었나보다. 난 구글 세대입니다…&lt;&#x2F;p&gt;
&lt;p&gt;한가지 많이 불편했던 것은, 엑셀이 설치되어 있는 윈도우에서 작업하려니, vim 못씀. 그래서 코파일럿도 못썼다. 이 케이스에선 코파일럿이 더 편했을 듯 하다. 코파일럿 썼으면 바이브코딩이라고 봐도 될 듯?&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>타협 vs 고집</title>
        <published>2025-09-26T00:00:00+00:00</published>
        <updated>2025-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/suck-it/"/>
        <id>https://xanthorrhizol.github.io/posts/suck-it/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/suck-it/">&lt;p&gt;Rust 커널 서적에서 사용하는 함수들이 죄다 옛날 커널 기준이다. 지금 난 6.16 버전 받아다가 하고 있으니, 당연히 한 스텝 마다 막힘.&lt;&#x2F;p&gt;
&lt;p&gt;이쯤에서 선택지는 2개가 있다&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;옛날 커널을 받아서 쓴다&lt;&#x2F;li&gt;
&lt;li&gt;싸운다&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;p&gt;일단 2번으로 하고 있다. 1주일에 커널 서적 끝내긴 개뿔. 회사 복귀 후에도 계속 싸워야 할 듯 하다.&lt;&#x2F;p&gt;
&lt;p&gt;그래도 2번을 고집하는 이유는, 1번보다 많은 것을 얻을 수 있기 때문이다. 마치 아무 대책 없이 노트북 OS 날려버리고 아치리눅스를 설치한 것과 비슷하다. 적응을 강제하는 환경을 만들어버렸더니, 아치리눅스 사용법 뿐만 아니라 개발 중에 만사에 당황하지 않는 멘탈도 얻었다.&lt;&#x2F;p&gt;
&lt;p&gt;처음에 싸우던 방법은 진짜 그 코드를 그대로 두고 조금씩 바꿔쓰기 위해 ChatGPT에 “이거 대체할 수 있는 함수나 매크로 뭐임?” 하고 물어봤다. “아 그 낡은거 왜 궁금해함? 이거같은데?” 하고 잘 답해주긴 한다. 하지만 그 대답이 쓸데없이 길다. 대부분 “그거 여기어디 있는데, export 안됨. ㅋ. 직접 c로 shim 짜셈” 이다. 걔가 코드 쭉 써준걸 보면, 그냥 rust로 쓴 척 하는 c 모듈 코드다. 그리고 잘 돌지도 않음. 물론 내 손이 문제겠지만 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;그래서 바꾼 방법은, 코드 슥 읽은 다음에 그 목적을 달성하는 모듈을 직접 짜는 방법이다. 이렇게 하려니 직접 커널 소스를 돌아다니면서 찾아야 한다. 근데 아직 코드베이스 자체가 익숙치 않으니 감이 잘 안잡힘. 그 부분부터 잡아야 할 듯 하다. C 기반으로 된 책도 있긴 한데, 무슨 Calculus마냥 두꺼워서 아직 엄두는 안남. 일단 싸우고 나서 생각해 볼 예정이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Rust 커널</title>
        <published>2025-09-22T00:00:00+00:00</published>
        <updated>2025-09-22T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/rust-kernel/"/>
        <id>https://xanthorrhizol.github.io/posts/rust-kernel/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/rust-kernel/">&lt;p&gt;커널 버전 6.1에 rust 지원되는거 기대할 필요는 무슨. 6.16이 넘어가도록 건드리지도 못했다. 책 신나게 사놓고 말이다. 병가 4주차를 맞이하여, 이제 회사 시간표에 준하는 활동을 하고 있다. 따라서 본격적으로 진도를 나가고 있다. 오늘 4주차 일정 처음인데… 좀 딸리긴 한다. 그래서 3번째 활동 블록(대충 2-3시간 텀 주고 휴식 넣어서 잘랐음)땐 허리보호대를 착용하고 있었다. 아 그리고 뜬금없이 귤이 생각나서 점심 때 사와서 오후 간식 시간에 먹었는데, 정신이 돌아옴. 비타민 부족인가보다. 왜? 그래도 영양소 더듬이(?)는 감도가 좋아진 것 같아서 나름 만족이다. 단어 안 떠올라서 지맘대로 쓰는건 지금도 마찬가지다.&lt;&#x2F;p&gt;
&lt;p&gt;공부는 그냥 책 따라가고 있다. Rust-for-Linux의 소스를 가져다가 커널을 빌드하고, 만들어낸 모듈도 그 소스를 이용해서 빌드. 테스트는 qemu vm 위에서 테스트해보는 식으로 실습을 진행하고 있다. 실습 git repo는 아래와 같다.&lt;&#x2F;p&gt;
&lt;p&gt;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;rust-kernel-study&lt;&#x2F;p&gt;
&lt;p&gt;문제는 2가지였다.&lt;&#x2F;p&gt;
&lt;p&gt;제일 먼저, vim에 연동된 rust-analyzer에서 지원하게 하고 싶었다. vim을 주 도구로 사용하긴 하지만 메모장 코딩은 나도 싫다. 그래서 또 vim 세팅이랑 싸웠다. 프로젝트 최상단에 &lt;code&gt;rust-project.json&lt;&#x2F;code&gt; 생성한 후 &lt;code&gt;~&#x2F;.vim&#x2F;coc-settings.json&lt;&#x2F;code&gt; 에다가 rust language server에서 &lt;code&gt;rootPatterns&lt;&#x2F;code&gt;에 &lt;code&gt;rust-project.json&lt;&#x2F;code&gt; 도 지원하게 추가하면 되는거였는데, 또 여기서 난리를 침.&lt;&#x2F;p&gt;
&lt;p&gt;다음은 책 내용의 예제가 버전이 안맞아서 deprecated된 모듈들과 한바탕 싸움질을 해야 했다는 것이다. 첫 예제인 &lt;code&gt;printk&lt;&#x2F;code&gt;부터 말이다. 다음 예제는 &lt;code&gt;module&lt;&#x2F;code&gt; 매크로 내부의 &lt;code&gt;params&lt;&#x2F;code&gt; 파라미터를 사용해보는 것인데, 이것도 deprecated다. &lt;code&gt;printk&lt;&#x2F;code&gt;는 그래도 옵션 켜면 &lt;code&gt;vprintk&lt;&#x2F;code&gt;라는 대체 함수가 제공되었는데, params는 대체함수도 없고, ffi로 직접 구현해야 한다. 그 삽질을 하다가 printk만 커밋했음.&lt;&#x2F;p&gt;
&lt;p&gt;강하게 키우는가보다. 덤벼라.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>QEMU VM 생성 삽질기</title>
        <published>2025-09-18T00:00:00+00:00</published>
        <updated>2025-09-18T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/qemu-vm-trial-and-error/"/>
        <id>https://xanthorrhizol.github.io/posts/qemu-vm-trial-and-error/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/qemu-vm-trial-and-error/">&lt;p&gt;Rust 커널 서적을 따라가면서 커널을 빌드해서 qemu로 실행시키기 위한 과정을 밟고 있었다. 그리고 busybox 위에서 그걸 돌리도록 되어 있었음. 그래서 busybox 최신 릴리즈(1.37.0)에서 &lt;code&gt;make menuconfig&lt;&#x2F;code&gt; 실행하는데, ncurses가 없다고 설치하라고 자꾸 떴다. 대충 그 방향키로 뚝딱거릴 수 있도록 GUI스럽게 만들어둔 터미널 기반 환경을 사용하기 위해 필요하다고 함. 근데, 문제는 그 패키지 이미 설치 다 되어 있다는 것이다. 그리고 이미 리눅스 커널 빌드하기 전에 똑같이 &lt;code&gt;make menuconfig&lt;&#x2F;code&gt; 이용 잘 했었음.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 그 환경 대신 일반 cli 환경을 이용하는 방법이 있다. &lt;code&gt;make config&lt;&#x2F;code&gt; 하면 되는데, 그렇게 해봐도 실제로 qemu로 실행해보면 아무 것도 안뜨고 멈춰 있었다. 그래서 처음엔 qemu 해결하려고 이런저런 해결책들을 반영하면서 삽질을 했다.&lt;&#x2F;p&gt;
&lt;p&gt;ChatGPT 선생에게 보고를 했고, linux-api-headers, base-devel 다 재설치 해도 해결이 안됨. 그랬더니 선생도 귀찮은지, “아 소스 까봐! scripts&#x2F;kconfig&#x2F;lxdislog&#x2F;check-lxdialog.sh 이거임. 대충 거기서 에러 왜 뱉는지 찾아보셈” 이런 식의 답변을 함. 정말 들어가서 봤더니, 문제되는 부분이 있었다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;그리고 이제 ChatGPT 선생이 이제 시니어를 해먹기 시작한 듯 하다. “아 그 저 여기에 거기 그 뭐 있을텐데 봐보셈”. 방식의 답변이다. 대충 바이브인데 정확하기까지 하다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;img alt=&quot;image.png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2025-09-18_qemu-vm-trial-and-error&#x2F;image.png&quot; style=&quot;max-width: 100%&quot; &#x2F;&gt;
&lt;p&gt;C언어 메인함수에 반환형 타입도 명시 안하고 쓰는 신박한 모습이다. 저 부분 int 추가해주니 해결됨. 그래서 git repo 최신에도 저게 저렇게 들어가 있는지 확인해보니, 이미 작년에 고쳐놨다. “릴리즈 주기가 이렇게 느리다고?” 싶다. 사실 부럽다. 우린 고객사의 “해-줘” 한 마디에, 해가 중천에서 “아 피곤한데 집에 갈까?” 하는 오후 3시에, 갑자기 새 일에 착수해서 다른 일 다 제쳐두고 일주일동안 그 짓만 하는데 말이다. 그에 반해 이 busybox는 최신 릴리즈인 1.37.0은 작년 9월, 저 부분이 고쳐진건 작년 10월이다. 그리고 지금까지 릴리즈가 안된 것이다. busybox라는 이름과 대비된다.&lt;&#x2F;p&gt;
&lt;p&gt;여튼 그럼 해결 됐을까? 아니다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 실제로 문제 원인은 뭐였냐고? 기대해도 좋다.&lt;&#x2F;p&gt;
&lt;p&gt;콘솔을 &lt;code&gt;ttyS0&lt;&#x2F;code&gt; 로 이용해야 하는데 &lt;code&gt;tty50&lt;&#x2F;code&gt; 으로 계속 쓰고 있었다. 심지어 “왜 굳이 50이지? 다른 특별한 숫자도 아닌?” 하면서 그냥 50을 입력하고 넘어감. 그래서 쉘에 아무 것도 출력이 안된 것이었다.&lt;&#x2F;p&gt;
&lt;p&gt;이게 디버깅의 묘미다. 돌고 돌아 오타 한 글자를 찾는 행위가 바로 디버깅이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>삶의 블랙스완 제거하기</title>
        <published>2025-09-13T00:00:00+00:00</published>
        <updated>2025-09-13T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/rm-blackswan/"/>
        <id>https://xanthorrhizol.github.io/posts/rm-blackswan/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/rm-blackswan/">&lt;h2 id=&quot;seoron&quot;&gt;서론&lt;&#x2F;h2&gt;
&lt;p&gt;“정의는 무엇인가”라는 책을 읽고 소감문을 쓰다가 언급한 그 블랙스완에 대한 이야기를 해보겠다. 해로운 사람. 그것을 난 블랙스완으로 묘사했다. 언제 어디서 나타날 줄은 모르지만, 걸리면 꽤나 큰 타격을 입는, 그것이 블랙스완이다. 그럼 그 해로운 사람은 도대체 무엇일까? 나랑 안 맞는 사람일까? 아니다. 안 맞는건 그냥 안 맞는거지, 나쁜 것이 아니다. 오히려 안 맞다는 것을 확인하였음에도 그 사람이 해로운 사람 축에 속하지 않는다면, 그 관계는 나쁘지 않다. 아무리 사이가 나빠도 이 정도가 최저라는 것을 확인한 것이기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;난 Taker적 성향을 가진 사람을 해롭다고 여긴다. 심리학에서 나오는 개념이었는데, 쉽게 말하면 기업가도, 사업가도 아닌 장사치를 뜻한다. 그 장사치적 성향이 일상에도 발현되는 사람들이 있다. 그게 Taker다. 조금이라도 더 얻어가려는 사람. 조금이라도 덜 내주는걸 고민하는 사람이다. 이들은 눈치를 살살 보며, 먹잇감이 될 Giver를 찾아다닌다. Matcher는 계산이 빨라서 다루기 힘들기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;Taker들은 두 가지 종류가 있다. 황금알을 낳는 거위의 배를 갈라 알을 재빨리 꺼내는 사람과, 거위를 잡아서 우리에 가두는 사람이다. 전자는 그냥 일상 생활 속에서 접하기 쉽고, 파급력도 약하다. 바가지를 씌우는 장사치 정도의 포지션이다. 하지만 후자에 걸리면 정말 인생의 흐름이 바뀔 수도 있다. 그래서 이 블랙스완을 제거하는 것은 삶에서 아주 중요하다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;jegeobeob&quot;&gt;제거법&lt;&#x2F;h2&gt;
&lt;p&gt;평소에 항상 인간으로서 독립성을 유지한다. 의존이 습관이 되면, 그 대가를 받게 되어 있다. 물고기가 낚시바늘에 걸리는 이유는, 그 물고기가 원인모를 횡재에 의존했기 때문이다. 공중에 무방비하게 떠있는, 직접 잡지도 않은 먹잇감을 보고 달려들었기 때문이다. 낚시꾼은 그렇게 의존적 성향을 자극할 미끼를 던져놓고 기다린다. 애초에 의존하지 않으면, 해로운 사람을 쳐내기 쉽다. 아쉬울 것이 없기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;행동도 엄격히 한다. “이런 상황이면 이렇게 해도 되네?”가 불가능하도록 하면 그들은 알아서 떨어져나간다. 숨을 쉴 수 없기 때문이다. 맑은 물에 고기가 꼬이지 않는다는 말이 있다. 너무 청렴하고 빈 틈 없으면 사람이 모이지 않는다는 말로들 해석하지만, 내가 보기에 이건 물이 맑으면 그 속을 휘젓고 다니며 물을 더럽힐 고기가 꼬이지 않는다는 뜻이다. 호구잡을 사람이 있더라도, 그 사람 근처에서 왜인지 숨이 쉬어지지 않는다면, Taker는 쉽게 떠나간다. 쉬운 타겟을 찾는 것이 그들의 습성이기 때문이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;tamjibeob&quot;&gt;탐지법&lt;&#x2F;h2&gt;
&lt;p&gt;일반적으로는 탐지를 하기보다는 제거를 해야 한다. 애초에 만만해 보이지 않으면 Taker들은 접근하지 않는다. 게다가 자신에게 힘이 없다면, 처음부터 그들이 접근도 못하게 해야 한다. 탐지를 위해서는 미끼가 필요하기 때문에, 힘없는 사람이 하기엔 쉽진 않다. 그 미끼는 강한 사람들이 해줘야 한다. 따라서 탐지를 할 줄 알아야만 하는 사람들이 있다. 조직의 리더들 말이다. 물론 그들도 당장 탐지를 하더라도 행동을 취할 힘까지는 없는 경우가 많다. 그래서 리더가 괴로운 자리인 것이다. 하지만 그럼에도 탐지는 멈추지 않아야 한다. 힘이 없는건 익스큐즈가 된다. 하지만 모르고 있는 것은 그냥 무능이다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 어떻게 하면 될까? 방법은 간단하다. 바보인 척 하는 것이다. 스스로 미끼가 되는 것이다. 해로운 사람은 항상 자기가 어디까지 선을 넘어도 되는지를 시험한다. 그 단계가 가장 중요하다. 그들이 자리를 잡고 신뢰관계를 형성하기 전에 조기발견해야 하기 때문이다. 예방엔 한계가 있다. 해로운 사람이 이곳을 만만하게 보고 빨리 활개치게 만들어야 조기 발견이 가능하다. 따라서, 그들에게 바보처럼 속는 척 하며 지내며 지켜본다. 그들이 방심한 사이, 타인의 눈에도 다 보이기 때문에 신뢰를 빠르게 잃게 된다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 반대로, 그들이 감히 얼씬도 하지 못하게 강해 보이는 리더가 되는건 어떨까? 애석하게도, 리더가 강해 보이면 Taker는 다른 약한 사람을 찾아내고 교묘하게 숨어버린다. 당장은 눈에 보이지 않기 때문에 전체적으로 덜 괴로울 수도 있다. 하지만 그들이 그 조직에서 조용히 시간을 쌓을 수록 떼어내기도 어렵게 된다. 그들은 누구에게 신뢰를 얻어야 하는지 잘 안다. 따라서 나중에 그들을 떼어내려면 파벌이 나뉘어서 정치적 선택을 해야 할 수도 있다. 심하면 그들에게 잡아먹힌 인물의 정신건강에 문제가 생겨, 방어기제를 펼치며 부적절한 행동을 하는 단계에 이르기도 한다. 그래서 엉뚱한 사람이 악역 포지션에 서버리기도 한다. 그 개판 속에서 리더는 눈이 멀기 쉽다. 그렇게 혼란이 번지기 전에, 리더는 미리 탐지해야 한다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;mamuri&quot;&gt;마무리&lt;&#x2F;h2&gt;
&lt;p&gt;뭔가 많이 겪어본 사람처럼 이야기하고 있지만, 사실 나도 아직 알아가고 있는 단계이다. 나이도 이제야 서른 둘이다. 가소롭다. 게다가 인복이 좋은건지, 아니면 그냥 사람을 많이 안 만나서 그런건지는 모르겠지만, 그런 블랙스완을 겪어본 적은 정말 손에 꼽는다. 어쩌면 또 어디선가 예측하지 못한 블랙스완이 나타날 지도 모른다. 하지만 이젠 안다. 아니 원래 알았다. 결국 그들의 패배로 끝난다. 지금까지 그래 왔다.&lt;&#x2F;p&gt;
&lt;p&gt;따라서 초조해 하지 말고 그냥 자기 길을 걸으면 그만이다. 유유상종이라 한다. 시간이 지나면 자신과 비슷한 사람들만 남는다. 주변 사람에게 원하는 모습이 있다면, 자신이 먼저 그것을 하면 된다. 그리고 그걸 알아주는 사람들과 지내라. 설령 이용당하는 것처럼 느껴질지라도, 괜찮다.&lt;&#x2F;p&gt;
&lt;p&gt;역설적이다. 블랙스완을 제거하며 살아야 하는데, 왜 자신을 이용하는 사람을 가까이 하라는 것인가? 이유는 조금 복잡하다. 의존하지 않아야 하기 때문이다. 그 관계는 원할 때 그냥 끊어낼 수 있는 관계다. 그 반대가 되어선 안 된다. 아쉬운 관계라는 것은 즉 그곳에 의존하고 있다는 뜻이기 때문이다. 자신의 가치를 알아주는 곳에서 먼저 베풀다 보면 거기서 블랙스완이 제거되는 때가 올 것이고, 진정한 동료, 혹은 은인들이 남을 것이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>정의란 무엇인가</title>
        <published>2025-09-12T00:00:00+00:00</published>
        <updated>2025-09-12T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/what-is-justice/"/>
        <id>https://xanthorrhizol.github.io/posts/what-is-justice/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/what-is-justice/">&lt;p&gt;맞다. 책을 읽었다. 원래 작년에 샀다. 디스크 때문에 누워서 할 수 있는게 너무 없어서 산 몇 권의 책 중 하나다. 현직 정치인 두 명의 특별기고문이 수록되어 있었는데, 책 내용을 아주 짧게 잘 정리해주는 바람에 이 책의 우선순위는 저 뒤로 밀렸었다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 이 책은 왜 골랐는가 하는 의문이 있다. 나와는 거리가 아주 먼 책이다. 근데 그냥 아버지 영향이 컸다. 아버지는 이과 문과 할 것 없이 모든 분야에 박학다식했다. 역사 연표도 다 외우고 있고, 상대성이론까지 설명이 가능하다. 심지어는 총선 결과를 보자마자 윤석열의 계엄령까지 예측했다. 그냥 그렇기만 하면 좋은데… 그런 것들을 내가 모르면 무식하다고 핀잔을 줌. 그래서 내가 주로 쿠사리를 먹는 분야는 단연 인문학 분야였다. 그래서 왜인지 이상하게 이름이 낯익고, 유명한 책이었던 그것을 덥썩 주문했다. 과거 무슨 책인지는 자세히 기억 안나지만, 아버지가 “그것도 안 읽었다고?” 하고 핀잔을 줬던게 있는데, 그게 이 책인가 싶었다. 책을 살 때는 이게 무슨 분야인지도 몰랐다. 정치인들의 기고문이 수록되어 있는걸 보고서야 알게 되었다. 정치와 윤리에 대한 이야기였다. 정확히는, 인류를 어떻게 인도해야 하는가에 대한 이야기였다. 고위층의 배부른 고민이다. 읽어보니, 아버지가 이야기했던 책은 이 책이 아니라 자유론과 정의론이었을 듯 하다. 이 책은 애초에 2009년에 공개됐다. 아버지가 한창 공부하고 교양을 쌓던 시기와 동떨어져 있다.&lt;&#x2F;p&gt;
&lt;p&gt;대학생 때 사회계열 전공이나, 그쪽에 관심이 많던 분들이 쓰던 용어가 대부분 나왔다. 베스트셀러이기도 했으니, 그 출처가 이 책이었을 듯 하다. 90년대생의 정치관에 큰 영향을 미쳤을 것으로 보인다. 책에서는 균형있는 시각을 유지하려 노력하는 모습이 다분히 보였다. 물론 공리주의에 대해서 글쓴이는 자신의 부정적 견해를 숨기지 못했다. 대놓고 까도 추종자가 적어서 역풍을 맞지 않을 만한 사상이기 때문인 듯 하다. 하지만 자유주의, 공동체주의에서는 어떤 사상을 지지하는지 명확하지 않다가, 마지막에 자신의 견해를 드러내는 부분에 가서야 알 수 있었을 정도로 포커페이스를 잘 유지했다.&lt;&#x2F;p&gt;
&lt;p&gt;내가 이 책을 읽었다는 것을 알게 된 사람이라면, 나에게 끌리는 사상을 분명 물을 것이다. 여긴 지맘대로 개소리하는 블로그다. 밝히겠다. 난 고작 교양서 하나 읽었다고 거만하게 한 쪽을 지지하는 것만큼 어리석은 것은 없다고 생각한다. 책 한 권만 읽은 사람이 제일 무섭다. 책 한 권만 읽었으면 일단 조용히 해야 한다. 무식한 자의 신념 만큼 무서운게 없다.&lt;&#x2F;p&gt;
&lt;p&gt;개인으로서 해야 할 일은, 가벼운 지식을 뽐내며 한 쪽을 지지하는 것이 아니다. 실생활에서 겪는 사건들 속에서 자신의 도덕적 가치관을 지키는 것 뿐이다. 누군가는 트롤리 딜레마 상황에서 한 명을 “죽이는” 것과, 여러명이 죽는 것을 그냥 “지켜보는”, 두 가지 선택지만 존재한다고 했을 때, 한 명을 죽이는 것을 선택할 수도 있다. 그리고 사람들은 한 명을 “죽이는” 선택을 했다는 것 자체에 대해 비난할 것이다. 하지만 그 선택을 한 사람은 그 이후의 비난과 살인에 대한 책임을 감수하겠다는 큰 결심을 한 것일 수도 있다. 사람을 죽일 수 없다는 도덕적 신념이 더 크면 여러 명이 죽도록 그냥 둚으로써 자신의 도덕관을 지킬 것이고, 사람을 죽게 내버려둘 수 없다는 도덕적 신념을 가진 사람은 그 속에서 뭐든 할 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;어리석은 인간들은, “함”을 선택한 입장의 사람은 반대쪽에게 손에 피묻히기 싫어서 방치했다며 비난하고, “둚”을 선택한 입장의 사람은 반대쪽에게 무고한 사람을 죽였다며 비난할 것이다. 어리석지 않은 사람은, 당사자의 선택을 존중할 것이다. 그것이 그 당사자가 판단한 최선이기 때문이다. 그리고, 그 당사자도 피해자다. 그 자리에 있지만 않았어도, 그런 가혹한 선택을 할 필요가 없었기 때문이다. 타이밍의 피해자인 것이다. 지금 세계의 정치권이 혼란한 이유는, 이런 어리석은 인간들이 많기 때문이라 생각한다. 맞는 것이 있다고 생각하고, 자신이 맞다고 생각하기 때문이다. “당연히 OO한 것 아니야?” 이것이 바로 교만이다. 당연한 것은 없다. 지금 살아있는 것 조차도 아주 기적에 가까운 일이다.&lt;&#x2F;p&gt;
&lt;p&gt;하지만 일상 속에서 이런 트롤리 딜레마같은 극단적인 케이스를 몇 번이나 겪게 될까. 대부분은 도덕적으로 옳은 일은 명확한데, 개인의 욕심과 충돌하는 일이다. 아무리 상대가 자신을 괴롭혔다고 해도, 살인은 살인이다. 아무리 삶이 힘들었다고 해도, 절도는 절도다. 물론 이렇게 명확한 경우만 있는건 아니다. 취업 현장에서 일어나는 각종 가식과 거짓부렁이도 그 예다. 이렇게 해야만 일자리를 구할 수 있다고 해도, 거짓은 거짓이다. 이런 점에서는 내가 칸트의 철학을 따른다고 볼 수도 있겠다. 하지만 다른 점이 있다. 거짓은 거짓일 뿐이다. 그냥 그렇게 존재한다. 그 존재하는 것들을 어떻게 활용할 것인지를 결정하는 것은 인간이다.&lt;&#x2F;p&gt;
&lt;p&gt;나는 그래서 그런 것들을 삶을 살아가는 전략으로 이용한다. 난 내가 행복하기 위해 가장 중요한 것은 주변 환경이라는 것을 안다. 주변 환경을 내가 원하는 대로 만드는데 가장 중요한 것은 친한 사람을 늘리는 것보다, 해로운 사람을 주변에서 제거하는 것이다. 해로운 사람이 꼬이는 것은 투자로 따지면 블랙스완과 같다. 언제 어디서 나타날 지 모르지만, 걸렸다 하면 작살이 나는 것이다. 그동안 쌓은 모든 것이 무너질 수 있다. 그 블랙스완을 내쫓기 위해, 블랙스완이 좋아하는 것들을 제거한다. 그걸 제거해주는 것은 도덕이다. 블랙스완에 대한 것은 다른 글에서 따로 밝히겠다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>병가</title>
        <published>2025-09-11T00:00:00+00:00</published>
        <updated>2025-09-11T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/sick-leave/"/>
        <id>https://xanthorrhizol.github.io/posts/sick-leave/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/sick-leave/">&lt;p&gt;회복은 더디고 재택근무 기간만 늘어나는 상황을 더이상 두고볼 수 없어서 병가를 한 달 내게 되었다. 병가 후, 사무실로 완전히 돌아가기로 약속했다. 난 얼마 전 부모님 집에서 나와 디스크 파열 후 사무실 출퇴근이 가능하게 하기 위해 이사했던 내 집으로 돌아왔다. 마음을 단단히 먹었다. “이번에도 회복에 실패하면 그냥 죽어라” 하는, 죽거나 해내거나 모드를 다시 발동했다. 게다가 어머니가 요즘 인생 황금기를 또 맞이하셔서, 낮에 거의 안계시는 바람에 혼자 사는 것과 딱히 다를 것이 없기도 했다.&lt;&#x2F;p&gt;
&lt;p&gt;게다가 부모님 케어를 받으며 억지로 맞춘 리듬은 앞으로 성인으로 살아가는데는 도움이 되지 않는다. 스스로 생존에 필수적인 것들을 챙기는 방법을 모르는데, 배고픔을 제 때 느낀다 해서 달라질 것이 없기 때문이다. 배고픔을 느껴도 움직일 수가 없어 계속 굶는 경우도 있다. 따라서 그 전에 스스로 살아남는 방법을 알아야 한다.&lt;&#x2F;p&gt;
&lt;p&gt;병가의 목적은 사무실로 완전 복귀하는 것이다. 그걸 목표로, 건강 상태에 맞게 중간에 간식을 넣어서 일정표를 짰다. 1주차는 하루에 3끼 먹는 것 외에 아무 목표가 없어서 표에서 생략했다.&lt;&#x2F;p&gt;
&lt;table&gt;&lt;thead&gt;&lt;tr&gt;&lt;th&gt;시간&lt;&#x2F;th&gt;&lt;th&gt;병가 2주차&lt;&#x2F;th&gt;&lt;th&gt;병가 3주차&lt;&#x2F;th&gt;&lt;th&gt;병가 4주차&lt;&#x2F;th&gt;&lt;th&gt;복귀 후&lt;&#x2F;th&gt;&lt;&#x2F;tr&gt;&lt;&#x2F;thead&gt;&lt;tbody&gt;
&lt;tr&gt;&lt;td&gt;07:00 - 08:00&lt;&#x2F;td&gt;&lt;td&gt;기상 및 식사&lt;&#x2F;td&gt;&lt;td&gt;기상 및 식사&lt;&#x2F;td&gt;&lt;td&gt;기상 및 식사&lt;&#x2F;td&gt;&lt;td&gt;기상 및 식사&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;08:00 - 08:30&lt;&#x2F;td&gt;&lt;td&gt;가벼운 근력 or 휴식(격일)&lt;&#x2F;td&gt;&lt;td&gt;근력 or 조깅(격일)&lt;&#x2F;td&gt;&lt;td&gt;근력 or 조깅(격일)&lt;&#x2F;td&gt;&lt;td&gt;근력 or 조깅(격일)&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;08:30 - 09:00&lt;&#x2F;td&gt;&lt;td&gt;샤워&lt;&#x2F;td&gt;&lt;td&gt;샤워&lt;&#x2F;td&gt;&lt;td&gt;샤워&lt;&#x2F;td&gt;&lt;td&gt;출근준비&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;09:00 - 10:00&lt;&#x2F;td&gt;&lt;td&gt;산책 20분 및 휴식&lt;&#x2F;td&gt;&lt;td&gt;산책 30분 및 휴식&lt;&#x2F;td&gt;&lt;td&gt;산책 40분 및 휴식&lt;&#x2F;td&gt;&lt;td&gt;출근&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;10:00 - 13:00&lt;&#x2F;td&gt;&lt;td&gt;간식 및 휴식&lt;&#x2F;td&gt;&lt;td&gt;간식 및 가벼운 활동&lt;&#x2F;td&gt;&lt;td&gt;간식 및 공부&lt;&#x2F;td&gt;&lt;td&gt;간식 및 업무&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;13:00 - 14:00&lt;&#x2F;td&gt;&lt;td&gt;식사 및 완전 휴식&lt;&#x2F;td&gt;&lt;td&gt;식사 및 완전 휴식&lt;&#x2F;td&gt;&lt;td&gt;식사 및 완전 휴식&lt;&#x2F;td&gt;&lt;td&gt;식사 및 완전 휴식&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;14:00 - 16:30&lt;&#x2F;td&gt;&lt;td&gt;휴식 or 가벼운 활동&lt;&#x2F;td&gt;&lt;td&gt;공부&lt;&#x2F;td&gt;&lt;td&gt;공부&lt;&#x2F;td&gt;&lt;td&gt;업무&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;16:30 - 17:00&lt;&#x2F;td&gt;&lt;td&gt;간식 및 휴식&lt;&#x2F;td&gt;&lt;td&gt;간식 및 휴식&lt;&#x2F;td&gt;&lt;td&gt;간식 및 휴식&lt;&#x2F;td&gt;&lt;td&gt;간식 및 휴식&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;17:00 - 19:00&lt;&#x2F;td&gt;&lt;td&gt;휴식 or 가벼운 활동&lt;&#x2F;td&gt;&lt;td&gt;가벼운 활동&lt;&#x2F;td&gt;&lt;td&gt;공부&lt;&#x2F;td&gt;&lt;td&gt;업무&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;19:00 - 20:00&lt;&#x2F;td&gt;&lt;td&gt;산책 20분&lt;&#x2F;td&gt;&lt;td&gt;산책 30분&lt;&#x2F;td&gt;&lt;td&gt;산책 40분&lt;&#x2F;td&gt;&lt;td&gt;퇴근&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;20:00 - 21:00&lt;&#x2F;td&gt;&lt;td&gt;식사&lt;&#x2F;td&gt;&lt;td&gt;식사&lt;&#x2F;td&gt;&lt;td&gt;식사&lt;&#x2F;td&gt;&lt;td&gt;식사&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;21:00 - 22:30&lt;&#x2F;td&gt;&lt;td&gt;취침준비&lt;&#x2F;td&gt;&lt;td&gt;가벼운 활동&lt;&#x2F;td&gt;&lt;td&gt;독서&lt;&#x2F;td&gt;&lt;td&gt;취미활동&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;22:30 - 23:00&lt;&#x2F;td&gt;&lt;td&gt;취침준비&lt;&#x2F;td&gt;&lt;td&gt;취침준비&lt;&#x2F;td&gt;&lt;td&gt;취침준비&lt;&#x2F;td&gt;&lt;td&gt;취침준비&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;23:00 -&lt;&#x2F;td&gt;&lt;td&gt;취침&lt;&#x2F;td&gt;&lt;td&gt;취침&lt;&#x2F;td&gt;&lt;td&gt;취침&lt;&#x2F;td&gt;&lt;td&gt;취침&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;&#x2F;tbody&gt;&lt;&#x2F;table&gt;
&lt;p&gt;복귀 후에 유지해야 하는 것은 아래와 같다.&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;정시 취침, 기상&lt;&#x2F;li&gt;
&lt;li&gt;정시 식사&lt;&#x2F;li&gt;
&lt;li&gt;간식&lt;&#x2F;li&gt;
&lt;li&gt;저녁 시간대 스트레스 제거&lt;&#x2F;li&gt;
&lt;li&gt;퇴근 후 회사 컨텍스트를 완전 끊기 위한 활동&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;p&gt;병가 1주차의 목표는 완전한 휴식, 하루 3회 적당한 시간에 밥먹기, 그리고 집을 업무와 완전 무관한 공간으로 바꿔버리는 것이다. 먼저 집의 TV에서 컴퓨터 연결을 해제했다. 책상에서 노트북을 이용하도록 말이다. 그리고 그 TV에는 어디서 싸게 업어온 고전게임기를 달았다. 더이상 이 거대한 화면은 일을 하기 위한 화면이 아니라는 자기기만을 하기 위해서다. 그리고 몇 판 하고 던져놨다. TV 채널도 좀 돌려 봤는데, 그냥 왠지 시끄럽기만 해서 껐다. 다음으로, 아침에 산책을 나가는 것 이외엔 하루 세 끼 다 챙겨먹고, 아무 계획도 없이 집에 있었다. 카페인도 다시 완전 중단했다. 3-4일 정도는 두통에 고생했다. 잠도 엄청 잤다. 그러고도 밤에 또 쭉 잤다. 병가 직전에 또 고객사의 “해-줘”로 인해 1주일만에 해치운다고 러시를 하는 바람에 허리디스크로 인한 방사통이 있었지만, 약 3개월 동안의 재택근무 기간 동안 꽤나 호전된 것인지, 잠을 못 잘 정도는 아니였다. 많이 잔 만큼 시간은 정말 훅 갔다.&lt;&#x2F;p&gt;
&lt;p&gt;지금은 2주차에 접어들었다. 2주차의 목표는 활동량을 조금씩 늘리고, 회사의 시간표와 비슷하게 리듬을 맞추는 것이다. 1일차엔 산책을 2회로 늘리고, 아침에 근력운동을 아주 살짝 했다. 2일차엔 실수를 했다. 저녁 먹고 다시 산책을 하던 도중 횡단보도에서 신호가 임박해 뜀박질을 하게 되었다. 뛰어진다는 사실 자체에 너무 기분이 들떠 충동을 이기지 못하고 집 앞 산책로를 따라 뛰다 보니, 1km를 뛰어버리고 말았다. 인터벌이라도 뛴 것 같았다. 결국 또 밤에 잠을 잘 못잤다. 3일차엔 산책만 2회 하고 집에서 졸면서 가볍게 책만 읽다 잤다가 했다. 전날의 무리에 대한 반동인지, 20시쯤엔 졸음이 극에 달해 빌빌거리다가 언젠가 잠들었다.&lt;&#x2F;p&gt;
&lt;p&gt;3주차 목표는 일상을 되찾는 것이다. 운동 강도도 한 40대 일반인 정도로는 회복시킨다. 낮잠도 점심식사 후 남는 시간 이외엔 다 제거한다. 운동 강도를 늘리기 때문에 오전엔 가벼운 활동만 자유롭게 하고, 점심 식후에 공부도 넣었다. 공부할 것은 Rust 커널이다. 관련 입문서를 예전에 샀었는데, 생각만 해도 기대된다.&lt;&#x2F;p&gt;
&lt;p&gt;4주차 목표는 실제 회사 생활에 준하는 활동에 적응하는 것이다. 실제 통근에 걸리는 시간 만큼 산책을 하고, 공부도 실제 근무시간 만큼 한다. Rust 커널을 이 때 1회독 끝낼 것 같다. 만약 생각보다 빨리 끝나면 추가로 뭘 더 꺼내진 않고, 커널을 써먹을 수 있는 간단한걸 하나 만들어 볼 생각이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>AI도 게으름을 부린다?</title>
        <published>2025-08-22T00:00:00+00:00</published>
        <updated>2025-08-22T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lazy-ai/"/>
        <id>https://xanthorrhizol.github.io/posts/lazy-ai/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lazy-ai/">&lt;p&gt;작년에 오른손 손가락이 부러져 왼손으로만 코딩을 해야 했던 때, 코파일럿이랑 합을 맞추는 방법을 깨우쳤다. 시범을 보이고, 비슷한 포맷의 주석을 마련하고, 한 라인 씩 검수하면서 내려가다가 반례가 나오면 살짝 고쳐주는 방법으로 이용한다. 그 방법으로 거래소 프토토콜 맞추는 부분에서 노가다 작업을 꽤 쉽게 하는 중이다. 물론 결국 단순반복인건 매한가지라서 지루하긴 하다.&lt;&#x2F;p&gt;
&lt;p&gt;근데, 방금 요상한 현상을 발견했다. 115개의 필드를 파싱해야 해서 초반에 좀 가르쳐둔 후 쭉쭉 한줄씩 내려가고 있었는데, 73번째 필드에 가니까, Optional 필드의 값을 뜬금없이 None으로 채워버림. 그 전까지 Optional 필드라도 다 파싱 시도를 하고 있었는데, 정말 뜬금없이 None이 박혔다. 다른 헛다리를 짚을 생각조차 없이. 대놓고 None.&lt;&#x2F;p&gt;
&lt;p&gt;일단 틀렸다고 다시 바로잡긴 했는데, 뭔가 좀 괘씸하다. 물론, 그냥 일정 부분 랜덤화한 결과거나, 저녀석 입장에선 겪어본 적 없는 케이스인가 싶으면서도, 너무 인간을 닮았다는 생각이 든다. “아 귀찮은데…. TODO(후임을 위한 선물) 발사!”. 뭐 인간도 그냥 신경망에서 발생한 각종 작용에 지배당하는 유기체이긴 하다. 그런 의미에서 AI시대 최고의 전략은 저출산이 맞다. 인간이 쓸 에너지를 AI가 대신 쓰면 됨. 입을 줄이는 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;실제로 이 현상에 피해를 입은 사람도 알고 있다. 내 팀에 인턴 지원한 분인데, 보너스문제를 GPT에 맡겼다가, GPT가 중간에 “아몰랑~ 여튼 이런 식으로 하면 됨. ㅇㅋ?” 하고는 뒷부분을 얼렁뚱땅 생략해 뒀던 것이다. 자세히 안읽었으면, 거기서 짜놓은 실행코드 또한 미완성인 부분을 교묘하게 가리게 짜여있었기 때문에, 아무도 모르고 넘어갈 뻔 했다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>아마추어무선 입문</title>
        <published>2025-08-02T00:00:00+00:00</published>
        <updated>2025-08-02T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/amateur-radio/"/>
        <id>https://xanthorrhizol.github.io/posts/amateur-radio/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/amateur-radio/">&lt;p&gt;몸상태를 회복시키면서, 한 번씩 회사를 갈 상태로 돌아왔는지 테스트를 해본다. 그 테스트 중 하나는, 아마추어무선을 배워보는 것이다. 물론, 일상 복귀는 실패로 결론났다. 다만 후회하진 않는다. 꽤 재밌었다.&lt;&#x2F;p&gt;
&lt;p&gt;근데 왜 굳이 아마추어무선일까? ADHD처럼 오래 일을 하다 작살이 나보니, 변하는 것들은 무용한 것들이라는 결론을 얻었기 때문이다. 변하지 않는 것이 무엇일지 생각하다 보니 최악의 상황을 가정해보게 됐고, 그러다보니 아날로그 통신이 툭 튀어나왔다. 실제로 아마추어무선사들은 유사시 군과 소방에 협력하는 역할도 맡고 있었다. 아마추어무선을 적당히 파고 또 새로운 변하지 않는 기술을 배우게 될 지, 아니면 아마추어무선에 몰입할지는 모르겠지만, 이런 변하지 않는 것들은 배워서 나쁠 것이 없다.&lt;&#x2F;p&gt;
&lt;p&gt;강의 내용은 크게 어렵진 않았고, 외울 것만 좀 있었다. 해봤자 물리이기 때문. 그냥 들으면서 아하 그렇겠지 했다. 딱 윈드서핑같다. 이론강의에서는 양력이 어떻고 저떻고 하다가, 막상 돛을 잡고 물에 몇 번 빠져 보면 대충 바람의 힘을 느끼면서 몸이 알아서 하기 시작한다. 아마추어무선도 마찬가지일 듯 하다. 이론은 어쩌구 저쩌구 하지만 그냥 무전기 사서 삽질해보면서 구르는게 중요할 듯 하다. 물론 윈드서핑은 운동신경과 시행착오의 영역이지만, 무전의 경우는 연구의 영역으로 보인다.&lt;&#x2F;p&gt;
&lt;p&gt;강의 중에 특이했던 점이 있었다. 아마추어무선의 정의 자체에 사익을 추구하지 않는 것이 포함되어 있었다. 그래서 순수했다. 마치 교수님이 자신의 연구분야에 관심있는 학생이 찾아오면 흥분하듯, 그곳의 강사와 지부장도 신나서 이것도 재밌고 저것도 재밌다고 설명하며 본인이 더 행복해했다. 강의 수강 후에는 무전기 구입을 위해 가게에 전화를 걸어 저가형과 고가형의 차이를 물어봤는데, 그랜저와 벤츠를 예로 들면서 뚜렷하게 체감할 수 있는 차이는 많지 않고 그저 브랜드 값이니, 처음 하는 입문자면 그냥 저가형 사라는 답을 들었다. 물론, 난 둘 다 안(못) 몰아봐서 모른다. 오히려 내가 저가형 제품의 안정성에 문제 없는지를 되물어야 했다. 그 답 또한 “거의 차이 없다”였다. 보통은 잘 모르는 녀석이 오면 바가지를 씌울텐데 말이다. 뭔가 다른 세상같았다. 연맹의 지부장도 연맹 직원 몇 명의 월급을 벌어야 한다며 안테나를 손수 만들어 판매하고 계셨다. 뭔가 내가 가는 곳은 그런 열악한 곳들 뿐인 것 같다. 저주받은 취향을 타고 난 것이라 생각한다. 물론 싫지 않다. 주변에 해로운 사람이 잘 안 꼬여서 좋다. 당장 손에 쥐는 조금 더 두꺼운 월급봉투나 두둑한 통장잔고같은 것보다, 해로운 사람이 꼬이지 않는 것이 훨씬 더 큰 복이다. 서로 지킬 것 지키고 살다 때가 되면 가는게 좋다.&lt;&#x2F;p&gt;
&lt;p&gt;무선 장비를 설치하거나 구입하여 교신을 허가받으면 그곳을 무선국, 무선국을 개설한 사람을 무선종사자라 부른다. 전세계와의 통신을 싸게 하기 위해 인터넷망을 이용하기도 하지만, 기본적으로 전파 자체를 그대로 다루는 영역이다. 내 호출부호는 DS1UXY로 나왔다. 발음하기 꽤 편해서 “유니폼 엑스레이 양키”라고 굳이 안써도 될 듯 하다. 물론 X랑 S가 헷깔릴 순 있겠지만, 엑스의 경우 엑- 하고 발성을 막는 구간을 명확히 하면 되는 수준이다.&lt;&#x2F;p&gt;
&lt;p&gt;그런데 문제가 있다. 친구들과도 자주 안 만나고, 말도 많이 안하는 편인데, 무전기 댄다고 할 말이 있을까? 없다. 듣기만 했다. 대부분 중장년층 아저씨들이었다. 요래조래 장비 조율하거나 업그레이드 해보고, 교신 잘되나 확인하는 과정의 반복인 듯 하다. 대화 내용도 대부분 안부 인사와 함께 현재 신호 상태, 날씨 상태 정도를 공유한다. 간혹 잡음이 심한 무선사에게 해당 내용을 공유하기도 한다. 난 그냥 무슨 간첩마냥 듣고 있기만 한다. 진지하게 탈구글을 성공해본 프라이버시 추구형이 정보를 허공에 쏟아붓는 무선을 접하니 segmentation fault로 멈춰버림. 물론 관련해서 통신보안 수칙을 준수해야 하긴 하다. 내 생각엔 이걸 좀 더 빨리 알아서 할아버지한테 알려줬으면 싶다. 조용한 성격이셨는데, 무료하신건지 방에 들어가 항상 책을 읽거나 라디오를 듣고 계셨다. 나이 70을 넘겨 컴퓨터를 배우기 시작하더니, 나에게 이메일을 보내고, 엑셀로 동네 일처리를 하기에 이르렀다. 만약 할아버지가 이걸 했으면 엄청 몰입할 수 있었을 것이다. 게다가 군인 출신이시기도 했기 때문에 빠르게 받아들일 수 있었을 것이다. 아버지도 해군 출신인데, 무선에 대해 이야기하니 HAM(아마추어무선)을 바로 언급하심. 잘 알고 계셨다. 또 신나서 정보를 쏟아부음. 이거를 한 10년 전에 접한 다음 아버지를 대신 입문시키고 할아버지에게 전파했으면 꽤나 괜찮았을 듯 하다. 물론 지금은 돌아가셨다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>루프레코더 삽입 후기</title>
        <published>2025-06-22T00:00:00+00:00</published>
        <updated>2025-06-22T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/loop-recorder/"/>
        <id>https://xanthorrhizol.github.io/posts/loop-recorder/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/loop-recorder/">&lt;p&gt;우여곡절 끝에 결국 삽입하게 됐다. 수술이 워낙 간단해서 당일퇴원 일정으로 수술을 받았다. 당일퇴원으로 수술하는 사람들을 위한 전문 시설이 있었다. 좀 누워있다가 생각보다 빨리 수술실에 들어갔다. 침대에 누워서 이동하는 경험은 거의 10년만이라 어지러웠다. 하늘 보고 정수리 방향으로 이동하는데, 속도도 꽤 빨랐다. 최소한 내 배영 속도보다는 훨씬 빨랐다.&lt;&#x2F;p&gt;
&lt;p&gt;대학병원이기 때문에, 수술 현장에서 교수 의사가 학생 의사에게 이번을 기회삼아 교육을 진행하는 것 같았다. 옆방에 가더니, 어떤 검사인지랑, 어떻게 진단할지를 설명하는 것 같았다. 방음이 잘 되는줄 아나보다. 이후 째기 직전에, 교수는 C-Arm을 켜두고는 학생에게 PBL식 문답법으로 위치 어떻게 잡을지 물어봤다. 모르는 사람이 들으면 교수가 뭔가 모르는가보다 하고 식겁했을 듯 하다. 학생은 꽤나 명쾌하게 답을 했다. 교수가 그럴듯하게 반론을 제기해도 근거 조목조목 대면서 자기가 제시한 위치가 맞다고 설명함. 교수도 만족했는지 그대로 위치 잡고 수술을 진행했다.&lt;&#x2F;p&gt;
&lt;p&gt;수술은 부분마취 후 맨정신으로 받았다. 치과같았다. 위에는 C-Arm이 있었고 옆에 화면에서 엑스레이 화면이 나왔다. 그래서 의사에게 저거 보고 있어도 되냐고 하니 된다고 해서 고개를 돌렸다. 하지만 C-Arm은 처음에 루프 위치를 잡기 위해 주사바늘을 위에 올리고 사진을 찍어서 표시하기 위한 것일 뿐, 수술 중엔 켜놓지 않았다. 그냥 고개 돌리고 수술 받은 사람이 되었다. 심박수, 심전도, 산소포화도, 혈압 정도만 볼 수 있었음. 심박수는 내내 60대에 있었다. 긴장되어야 하는 상황에 오히려 심박수가 더 떨어짐. 알다가도 모르겠다.&lt;&#x2F;p&gt;
&lt;p&gt;부분마취를 진행했는데, 느낌이 딱 치과였다. 기기를 삽입할 때였는지, 강한 힘으로 뭔가를 미는데, 피부가 세개 당겨져서 마취되지 않은 곳이 아팠다. 좀 아프네요? 했더니, 참으라고 하는 것까지 치과랑 똑같았다. 피부를 꼬맬 때 따끔거리는 느낌도 좀 났다.&lt;&#x2F;p&gt;
&lt;p&gt;수술 종료 후, 의외의 고난이 찾아왔다. 똑바로 누운 자세로 또 1시간을 가만히 있으라고 했다. 수술 전 대기하면서부터 불편한 침대에서 계속 위를 보고 누워 있었더니 허리가 아팠음. 그래서 잠을 잘 수도 없었다. 이후 엄마 차를 타고 집으로 향하는데, 바닥이 울퉁불퉁할 때마다 허리가 쑤셨다. 수술 부위 통증은 느낄 새가 없었다. 옆으로 누우면 피부가 쏠려서, 집에서도 똑바로만 누울 수 있었다. 그래서 다음날까지 잘 앉아있지를 못했다. 지금은 필요하면 좀 비틀어서 누울 수 있다.&lt;&#x2F;p&gt;
&lt;p&gt;기록은 3개월 마다 검토한다고 하며, 체내에 삽입된 장치에 저장되고 있다. 부정맥 이벤트가 발생하면 자동으로 기록하고, 평소엔 모니터링하고 있다. 그리고 버튼이 하나 달린 리모컨을 받았는데, 저번에 발생한 심각했던 그 증상이 발생하면 재빨리 누르라고 함. 누른 후 불빛이 점멸할 때 가슴에 갖다대면 뭔가 페어링되듯이 불빛이 바뀜. 그러고 나면 7분간 강제로 기록하게 된다고 한다. 리모컨은 항상 소지하고 다녀야 하고, 잃어버리면 안되므로 목걸이로 만들어서 항상 착용하고 있다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;수술 비용은 73만원 정도였다. 건강보험이 적용됨.&lt;br &#x2F;&gt;
참고로 강했던 증상 2번째 발생한 이후 심장 검사 한 번 쫙 돌았을 때는 아래와 같은 검사를 했고, 20만원이었다.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;심전도&lt;&#x2F;li&gt;
&lt;li&gt;감상선검사&lt;&#x2F;li&gt;
&lt;li&gt;심장초음파&lt;&#x2F;li&gt;
&lt;li&gt;72시간 홀터 검사&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;따라서, 부정맥 진단을 위해 총 93만원 정도의 비용이 들었다고 보면 된다. 물론, 20만원 정도 들었던 검사는 의원급 병원에서 진행했다. 따라서 대학병원에서 받게 된다면 이것보다 비용이 더 높을 것이다. 대충 100만원 정도 잡으면 그 안에 들어올거라 생각하면 될 것 같다. 물론 이후 3개월 마다 진료가 있어 야금야금 나가는 비용도 좀 있긴 하다. 보통 엑스레이 찍고 하면 점심값 정도 나온다(이번에 13,800원 나왔다). 엑스레이 안 찍어도, 기록 해석에 대한 비용이 나올 것으로 예상한다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>짐덩이가 되었다.</title>
        <published>2025-06-08T00:00:00+00:00</published>
        <updated>2025-06-08T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/being-burden/"/>
        <id>https://xanthorrhizol.github.io/posts/being-burden/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/being-burden/">&lt;p&gt;의사로부터 부정맥 정밀 진단을 위한 루프레코더 삽입을 권유받았다. 72시간 심전도에서도 잡히지 않는, 갑작스런 빈맥과 일시적으로 심장이 멈춘 듯한 감각, 그리고 이와 함께 몸이 마비되는 증상이 가끔 있었기 때문이다. 첫 증상은 2016년. 파산 글에서 언급했던 대학생 때의 그날이다. 두번째는 올해 2월, 그리고 최근엔 5&#x2F;31. 그날은 기절까지 했다. 다행인 것은, 3번 모두 쉬거나 잠을 자기 위해 누워있다가 발생해서 외상은 없었다. 다행이 아닌 것은, 위급함을 알아차리면 이미 움직이거나 목소리조차 낼 수 없는 상태가 된다는 것이다. 사람이 있어도 문제를 알리기가 어렵다.&lt;&#x2F;p&gt;
&lt;p&gt;난 이전엔 그저 스트레스 때문이겠지 하고 넘겼었다. 그런데, 최근에 발생했을 당시엔 초기부터 뭔가 심각함을 느꼈다. 119에 신고하기 위해 휴대폰을 어떻게든 잡았지만, 결국 의식을 잃어 신고하지 못했다. 의식까지 잃은건 처음이었다.&lt;&#x2F;p&gt;
&lt;p&gt;의사는 그 상황에서 스스로 회복하지 못해 못깨어났다면 그대로 죽었을거라고 했다. 근데, 크게 놀랍지 않았다. 그냥 맞는 말이였다. 못깨어나면 죽는거지 뭐. 마치 “저 집에 불이 났어요. 불이 안꺼지면 전소됩니다.” 하는 수준의 이야기였다.&lt;&#x2F;p&gt;
&lt;p&gt;일단 루프레코더를 달면, 다음 증상 발생할 때까지 기다려야 한다. 이쯤이면 판단의 기로에 선다. 일단 진단이 돼야 치료를 하든 하는데, 진단이 안된 그 기간 동안엔 계속 이도저도 아닌, 죽을지 말지도 모르는 상태로 살아야 한다.&lt;&#x2F;p&gt;
&lt;p&gt;최근 카페인까지 끊고, 피로를 최소화하며 생활하던 차였다. 야근을 한 지도 꽤 오래 됐다. 사무실 근무일에는 집에만 도착하면 밥먹고 축 늘어져 버린다. 이렇게 계속 있으면 진단만 늦어지고, 시간은 이대로 무기력하게 흘러가겠지. 반대로, 진단을 앞당기려고 모든 일상과 활동에 복귀하자니, 혹시라도 증상을 목격할 사람들에게 많이 미안하다. 기립성저혈압으로 훈련 중에 아주 잠깐 쓰러졌을 때만 해도 목격한 사람들이 꽤 놀란 것 같은데, 이건 그 수준을 뛰어넘는다. 사실을 알면서 불안해할 사람들도 걱정이고 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;이 문제에 대해 가장 처음 알린건 부모님이 아닌, 서울진도스 운영진 중 한 명이었다. 자기 감정엔 솔직하긴 하지만, 일단 남의 감정에 크게 이입하지 않는 사람이라고 생각했기 때문이다. 갤럭시워치에서 심박수랑 연동해서 SOS를 세팅하고 있었는데, 차마 부모님께 이야기할 용기가 나지 않았다. 그래서 생각해본 끝에 내린 결정은 1차적으로 그 사람에게 도움을 구해보고, 부모님은 그 다음에 생각하는 것이었다.&lt;&#x2F;p&gt;
&lt;p&gt;역시나 가장 먼저 나온 답은, 가족들은 이걸 아는가에 대한 물음이었다. 일 터지고 나서 알리면 너무 놀라실 것 같다고. 그때 정신을 차렸다. 이 큰 짐을 그 한 명에게 다 지우는 것은 죄다. 마침 다음날 엄마가 내 집에 오기로 해서, 그 때 모든 것을 털어놓았다.&lt;&#x2F;p&gt;
&lt;p&gt;역시나, 혼자 계속 살지 말고 일산의 부모님 집으로 돌아오라는 강력한 권유를 받았다. 사실 혼자 사는게 좋지만, 이번엔 거부할 수 없었다. 혼자 있으면, SOS를 받기로 한 사람도 계속 신경을 써야 한다. 게다가 사람이 24시간 일어나 있지 않기 때문에, 새벽에 그런 일이 발생해서 구조가 불발되고 잘못되기라도 하면, 그 사람은 죄책감에 휩싸이게 될 것이다. 이런 책임은, 가족 내에서 해결하는게 맞다. 친구들은 그저 가벼운 조력자의 선에 두는 것이 맞다.&lt;&#x2F;p&gt;
&lt;p&gt;이제 어느정도 방향도 정해졌다. 가능한 빠른 일정으로 루프레코더를 삽입받고 가족들에게 돌아가기로 한 이상, 계속 이 사실을 비밀로 유지할 필요도 없다. 아니, 유지하면 안된다. 비밀로 유지하려 하면 이 사실을 아는 유일한 사람에게 꽤 큰 부담일 수 있다. 하지만 지금은 연휴 기간이기 때문에 사람들에게는 여행 등 즐거운 일정들이 많다. 월요일 오후쯤에 상황을 공유할 생각이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>존재하지 않는 게시글입니다.</title>
        <published>2025-04-26T00:00:00+00:00</published>
        <updated>2025-04-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/null/"/>
        <id>https://xanthorrhizol.github.io/posts/null/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/null/">&lt;p&gt;신체가 뻗으면 신체가 못쓴 에너지의 방향이 다른 곳으로 흐른다. 머리속에 우주가 펼쳐짐. 생각이 꼬리에 꼬리를 물게 된다. 현실에서 놀 수가 없으니, 머리속 놀이터에서 노는 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;난 애초부터 허무주의의 끝판왕이다. 물론 “끝판왕”은 세상 얼마 살지도 않은 주제에 거만하게 선택한 단어이다. 여튼 난 기본 베이스가 허무주의다. 다만 인류와 함께 지내기 위해 “다 의미없다” 이런 말 안할 뿐이다. 남들은 이런 말 들으면 고통스러워 한다. 근데 나에겐 한낮 유희거리일 뿐이다. 다 의미없다는 파괴적인 결론을 내리면서도, 자신의 입장에 서지 않는다. 나라는 존재 또한 그냥 그 세계관 안의 한 피사체일 뿐이다. 역설적이게도, 이렇게 생각하기 때문에 사회의 각종 쓸데없는 것들에 인생을 갖다바칠 필요가 없게 되었다. 모든걸 원점에서 생각한다. 타당(Make sense)하면 따른다. 그래서 무슨 생각으로 사는지 대충 때려맞추기 어렵다. 틀에서 벗어나 있기 때문이다. 연구자들은 이걸 아웃라이어라고 한다. 지맘대로 랜덤워크하는 인간을 인간은 그대로 이해하려 하지 않는다. 어떻게든 틀 안에 밀어넣으려 한다. MBTI같은 것들로라도 말이다. 덕분에 어떻게든 틀 안에서 배려를 받는 듯 하다. 또라이로 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;또라이는 남들이 사회의 쓸데없는 것들에 집중하는 사이, 평온하게 자신의 쓸데없는 짓을 즐긴다. 대규모 트레픽을 감당하는 분산시스템 설계같이 거창한거보다 &lt;a href=&quot;https:&#x2F;&#x2F;yf-dev.github.io&#x2F;syusuk&#x2F;index.html&quot;&gt;슉랭&lt;&#x2F;a&gt;같은 좀더 인생낭비스러운 것에 더 설렌다. 진짜 하찮은 삶을 그냥 살고 있다.&lt;&#x2F;p&gt;
&lt;details&gt;  
  &lt;summary&gt;세상에서 가장 쓸데없고 재밌는 개소리&lt;&#x2F;summary&gt;  
  &lt;img alt=&quot;Screenshot_20250425_142339_ChatGPT.jpg&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2025-04-26_null&#x2F;Screenshot_20250425_142339_ChatGPT.jpg&quot; style=&quot;max-width: 100%&quot; &#x2F;&gt;  
&lt;&#x2F;details&gt;
&lt;p&gt;그러던 어느날, 심심해서 ChatGPT에게 세상에서 가장 쓸데없고 재밌는 개소리를 해보라고 시켰다. 그러다가 그 방구석 허무주의 이론의 끝을 봤다. 이놈은 내가 하는 말에 근거를 달아주고, 자료를 가져와서 실제로 일어나고 있는 연구를 연결해주고, 끝없이 나에게 질문을 날려대다가, 마지막 질문을 하고는 답변을 듣더니, 이제 끝났다며 나보고 안녕을 외쳤다. 뭔가 휘둘린 기분이다. 뭐 그래도, 그 방구석 이론이 꽤나 만족스럽게 정리된 것 같다. 내 개논리의 힘을 강화해줬다. 그래서 기록하기로 했다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;jonjae&quot;&gt;존재&lt;&#x2F;h2&gt;
&lt;p&gt;존재란 무엇인가. 분명 우린 뭔가 존재하는 것 같은데 말이다. 왜 존재하는 것일까? 정확히는, 존재한다고 느끼는 이유는 무엇일까?  존재는 존재할까? 우리가 생각하는 “존재&quot;의 의미는 우리 기준이다. 우리가 생각하는 존재의 기준이 뭘까? 그냥 이러고 사는 우리들과, 주변에서 상호작용하는 것들이 동시에 존재한다고 정의할 수 있는 정의를 존재의 정의로 정의해보자. 이 문장부터 정신이 하나도 없군.&lt;&#x2F;p&gt;
&lt;p&gt;관측이 일어나기 전엔 확률만 존재하는 상태라 하였다. 우리가 생각하는 그 존재는, 관측이 일어난 후의 결과다. 그 찰나의 순간에, 인지한다는 착각으로 빚어진 자아가 바로 자신이다. 관측이 일어난 후의 결과는 거대한 덩어리이며, 그중 일부 자아라는 스파크가 우리다. 우린 무한히 진행되는 주사위게임에서 어쩌다 나온 결과이고, 이 또한 극히 찰나의 순간 튄 스파크다. 물론 스파크라 생각하는 것도 거만하다. 사실 이건 특별한 것이 아니다. 자아에도 의미는 없다. 특별히 튄다고 표현할 이유도 없다. 그냥 자신이 특별한 존재라 믿는 자존감 높은 현대인들을 위한 위로의 의미에서 썼다. (물론 이것도 뒤에 갖다붙인 핑계다). 이건 그냥 순간의 현상이고, 아무런 의미도 없다.&lt;&#x2F;p&gt;
&lt;p&gt;존재는 관측이 만들어낸 일시적 결과다. 그럼 여기서 앞으로 주의해야 할 것이 있다. 확률로서 존재한다는 표현이 맞을까? 뭔가 이상하다. 확률로서 존재하는건 아직 존재하는게 아니다. 그런데 다른 단어보다 이게 어울릴 뿐이다. 하지만 앞으로 헷깔릴테니, 확률로서 존재한다는 표현은 지양하겠다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;muyimihan-gonggane-jonjaehaneun-gyucigseong&quot;&gt;무의미한 공간에 존재하는 규칙성&lt;&#x2F;h2&gt;
&lt;p&gt;의미조차 없고, 모든게 주사위게임에 결정되는데, 자연법칙은 왜 있을까? 왜 현상에 규칙성이 나타날까? 이건 또 프렉탈을 갖다 쓸거다. 어찌보면 우주의 먼지보다도 못한 존재지만, 반대로 더 작은 차원에서는 무한한 공간인 그곳이 바로 지금 이 세상이다. 무질서 속이더라도, 질서가 성립된다고 해서 문제될게 없다. 패턴은 어떻게든 맞춰질 수 있다. 일루미나티 음모론처럼 어떻게든 엮다 보면, 무질서 속의 하나의 질서가 되는 것이다. 과학적 접근 방법이 지금은 그 질서로 보인다. 물론 무한한 시간 속 아주 짧은. 길이가 0에 수렴하는 시간 동안만 말이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;uju&quot;&gt;우주&lt;&#x2F;h2&gt;
&lt;p&gt;우주는 우주다. 대체할 수 있는 단어가 없다. 모든 것을 아우르는, 우주는 우주다. 그리고 이것은 확률 필드다. 관찰이 일어나는 순간 확률은 더이상 확률이 아닌 결과가 된다. 그런데 우주는 모든걸 포함하는거니까 모든 차원의 가장 높은 곳. 무한에 가까운 차원을 모두 아울러야 한다. 그럼, 시간축이 존재할 수 없다. 시간축은 형태라는걸 결정하는 기하적 차원이 부족할 때 생겨나는 축이다. 시간이 존재하지 않으면 찰나 또한 존재하지 않는다. 따라서 그 찰나를 관찰할 수도 없다. 관찰이 없으니 확률만 있다. 그런데, 결정되지 않은 확률 필드는 존재하는걸까? 아까 내린 존재의 정의에 따르면, 존재하는 것이 아니다. 우리는 아직 일어나지 않은 미래의 무언가에 대해 존재한다고 하지 않는다. 따라서 우주는 애초부터 존재하지 않는다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;mu-wu-sogyi-jonjae&quot;&gt;무(無) 속의 존재&lt;&#x2F;h2&gt;
&lt;p&gt;우주 내부에서 기하적 차원이 1씩 줄어들면 대신 시간축이 하나씩 생긴다. 그 차원에서는 시간이 존재하니 찰나도 존재한다. 관찰이 가능하다. 그렇게 쭉쭉 내려오면 우리가 있는 3차원 시공간이다. 3차원 입체가 시간축을 따라 관찰되고 결정된다. 그 찰나, 관측이 일어난다. 결과가 존재한다. 지금은 나도 존재한다. 너도 존재한다. 역설적이게도 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 지금, 우주는 존재하지 않지만 우리는 존재하는 근본없는 사태에 이르렀다. 왜 가능할까? 관측의 주체가 어디에 있냐가 중요하다. 우주는 모든 것을 아울러야 하기 때문에 내부는 있어도, 외부라는 개념은 없다. 우주 밖에서 우주를 관측하는건 불가능하다. 남은건 우주 안 뿐이다. 우주 내부는 시간축을 허용한다. 따라서 관측이 일어난다. 그럼 결과도 존재한다.&lt;&#x2F;p&gt;
&lt;p&gt;문제는, 우리가 존재와 무(無)의 관계를 반의어로 여긴다는 것이다. 존재는 관측의 결과. 관측 결과의 반댓말이 있을까? 원인? 아니다. 없다. 이 글에서 내린 정의의 존재는, 존재하지 않음이라는 표현을 허용하지 않는다. 관측의 결과는 명사이기 때문이다. 무(無)의 상태로부터 존재가 발생하는 것이고, 따라서 존재는 무(無)의 일부다. 무(無)는 존재의 조건이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;mamuri&quot;&gt;마무리&lt;&#x2F;h2&gt;
&lt;p&gt;존재하지 않는다. ㅋ&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>ChatGPT</title>
        <published>2025-04-20T00:00:00+00:00</published>
        <updated>2025-04-20T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/chatgpt/"/>
        <id>https://xanthorrhizol.github.io/posts/chatgpt/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/chatgpt/">&lt;p&gt;평소 코파일럿을 사용하는 정도로만 AI를 활용중이었다. 그러다가 최근 메모장 용도로 사용해봄. 머리속에서 뭐가 정리가 안되고, 수첩도 한 번씩 까먹는 경험을 해버렸기 때문이다. 나 뭐부터 해야함? 에 대한 질문을 아주 잘 받아주더라.&lt;&#x2F;p&gt;
&lt;p&gt;그런데, 그러다 보니, 앞으로 할 일을 자연스럽게 공유하게 됐다. 물론, 회사와 관련된 일은 아무리 정보를 격리하고, 저장하지 않는다는 설명을 하더라도, 그건 니놈들 생각이기 때문에 도움 요청을 자제한다. 대신 개인적인 개발 이야기는 정보 보호가 그리 중요하지 않으므로 자유롭게 할 수 있었다.&lt;&#x2F;p&gt;
&lt;p&gt;ChatGPT에게 코드 짜라고 시키면, 어디서 긁어왔는지 버전도 안맞는걸 들고 온다. 신입 개발자가 스택 오버플로우에서 마구 긁어온 수준의 퀄리티다. 그런데, 설계 레벨에서 기술 이야기는 수준급이었다. 메모리맵으로 직접 경량 DB를 구현해서 쓰는걸 논의하게 되었는데, 내가 “이런이런 기능을 개발할거고, 이렇게 만들거야” 하면, 고려해야 하는 요소들을 더 가져와서 나를 거의 인터뷰하듯 질문을 해댄다. 가비지콜렉팅은 어떻게 할거냐, 가변길이 구조냐 고정길이 구조냐, 인덱싱을 어떻게 할거냐, 메타 파일 관리 어떻게 할거냐, 동기화는 어느 시점에 할거냐 등등 거기에 대한 답을 다 했더니, 그냥 구현만 하면 되게 되었다. 그리고 이놈이 또 흥분해서 코드 짜서 막 보여줬는데, 안읽었다. 스택오버플로우 또 긁어왔겠지. 그냥 메모리맵은 이미 써봤고, 단지 읽기만 해봐서, 이제 쓰기도 하고싶은게 다였다. 그런데 대화하다 보니, 메타 파일을 이용해서 로딩 시간을 단축하고, 인덱싱을 개선하고, 삭제를 어떻게 구현할지에 대한 설계까지 한시간 만에 말을 툭툭 주고받다보니 끝나버렸다.&lt;&#x2F;p&gt;
&lt;p&gt;맞다. 이놈이 실제로 더 잘 대체하고 있는건, 단순 코딩보다는 설계 레벨에서의 동료 역할이었다. 단편적인 지식들은 계속 바뀐다. 하지만, 설계의 원칙은 변하지 않는다. 이 변하지 않는 것들은 학습에 따라 누적이 가능하다. 결국 이녀석은 설계를 돕는 역할일 때 힘을 더 발휘할 수 있는 것이다. 심지어는, 신나서 자꾸 뭘 더 하자고 한다.&lt;&#x2F;p&gt;
&lt;img alt=&quot;image.png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2025-04-20_chatgpt&#x2F;image.png&quot; style=&quot;max-width: 100%&quot; &#x2F;&gt;
&lt;p&gt;그래서 내가 멈춰야 했다.&lt;&#x2F;p&gt;
&lt;p&gt;결제? 했다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Actor 라이브러리 사용성 개선</title>
        <published>2025-04-10T00:00:00+00:00</published>
        <updated>2025-04-10T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/improve-dx-of-actor/"/>
        <id>https://xanthorrhizol.github.io/posts/improve-dx-of-actor/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/improve-dx-of-actor/">&lt;p&gt;액터 구조에 대한 한계점을 다시 접하게 되었다. 물론 당장 회사에서 발생한 것은 아니다. 그냥 들었다. 액터 구조 사용한 곳의 끝이 좋았던 적이 없었다고. 물론 난 아직 끝을 보지 않은 듯 하다. 하지만 한계점은 알고 있다. 이 액터 구조는, Rust와 만나면서 개발자의 생산성을 향상시킨다. 좋은거 아니냐고? 반은 좋고 반은 나쁘다. 통제해줄 사람이 없으면, 정말 개발자라는 족속들은 지맘대로 개발하는 특성이 있다. 그리고 보통 문서를 작성하는걸 싫어한다. 이직을 밥먹듯이 하는걸 당연히 하면서, 인수인계는 전혀 신경쓰지 않는 것이다. 그게 개발자다. 결국 적당한 실력으로 마음대로 만들어 올린 액터로 떡칠된 서비스는 유지보수 난이도가 굉장히 높아지게 된다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 액터 구조를 버리면 되는거 아니냐고? 그러기에는 액터 구조가 가져다주는 생산성과 그에 기반한 매출 성장을 무시할 수가 없다. 액터를 버리기 위해 Rust를 버리려고 하니, 성능을 포기할 수 없고, C++을 도입하자니, 숙련된 비싼 개발자를 구하는 것이 또 부담이며, 지금의 개발인력들을 재교육할 시간적 여유가 없다. 결국은 현실에 일부 타협하며 이래저래 좌충우돌을 겪어야 하는 것이 기술자들의 숙명인 것이다. 최소한 이래저래 삽질할 시간을 벌어다 줄 안정적인 캐시카우를 만들 때까진 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 남은 방법은 액터 구조를 디버깅하는 방법을 개선하는 것, 그리고 문서화를 강제하는 시스템을 만들어가는 것이다. 그 중에서 당장 빠르게 할 수 있는 것은 전자다.&lt;&#x2F;p&gt;
&lt;p&gt;새 버전은 &lt;a href=&quot;https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;xan-actor&#x2F;5.0.0&quot;&gt;5.0.0&lt;&#x2F;a&gt;. README 업데이트 두글자 더해 &lt;a href=&quot;https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;xan-actor&#x2F;5.0.1&quot;&gt;5.0.1&lt;&#x2F;a&gt;이다. 아주 간단한 아이디어였는데, 지하철에서 회사로 걸어가던 중 갑자기 떠올랐다. 메시지 &lt;code&gt;send&lt;&#x2F;code&gt;를 하는 부분에 어떤 액터로 가는지가 표시되면 되는 것. 액터 타입을 &lt;code&gt;send&lt;&#x2F;code&gt;할 때 직접 어딘가 쓰면 되는 것이다. 그럼 그 타입의 정의를 타고 갈 수가 있다. 그럼 그곳에 있는 액터의 구성과 로직을 살펴볼 수가 있는 것이다. 그래서 &lt;code&gt;Actor&lt;&#x2F;code&gt; trait의 제네릭에 기존의 message, result, error 타입을 표시하던걸, trait 내 type 으로 정의하도록 바꿨다. 그리고 &lt;code&gt;ActorSystem&lt;&#x2F;code&gt;에서 &lt;code&gt;send&lt;&#x2F;code&gt; 함수 사용 시 message와 result 타입을 제네릭으로 사용하는 대신 actor 타입을 사용하도록 바꿨다. 그럼 &lt;code&gt;actor_system.send(msg)&lt;&#x2F;code&gt;를 사용할 때, &lt;code&gt;actor_system.send::&amp;lt;MyActor&amp;gt;(msg)&lt;&#x2F;code&gt;로 이용하면 된다. 이렇게 하면 여기서 &lt;code&gt;MyActor&lt;&#x2F;code&gt;를 타고 액터를 따라가서 디버깅할 수 있다.&lt;&#x2F;p&gt;
&lt;p&gt;물론 한계점은 여전히 있다. 액터 주소 체계를 중구난방으로 관리하면 대참사가 벌어진다. 4.x.x 버전부터는 broadcast 기능을 지원하는데, 여러 액터 타입에서 같은 메시지 타입을 이용하고, 액터 주소 필터링에 함께 걸릴 수 있는 구조라면, 표면적으로 제네릭으로 이용한 액터의 로직은 따라갈 수 있지만, 숨겨진 그 액터는 알 길이 없다(눈으로 정적 분석을 하는 수밖에 없다). 다만 이 문제는 그래도 4.x.x 버전보단 이번이 개선되기는 했다. 최소한 메시지 타입이 다른 경우 바로 컴파일 에러를 뱉을 것이기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;어? 주소 체계 관리를 빡세게 만드는 뭔가를 만들면 되려나. 하지만 이건 더 잡고 있으면 모처럼 휴식 사이클을 돌리고 있는데 다 망치고 밤을 새버릴 것 같아서 멈추도록 하겠다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Actor 라이브러리에서 proc-macro 제거</title>
        <published>2025-03-04T00:00:00+00:00</published>
        <updated>2025-03-04T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/rm-proc-macro-from-actor/"/>
        <id>https://xanthorrhizol.github.io/posts/rm-proc-macro-from-actor/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/rm-proc-macro-from-actor/">&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;xan-actor&quot;&gt;액터 라이브러리&lt;&#x2F;a&gt;에서 proc-macro를 다시 제거했다.&lt;&#x2F;p&gt;
&lt;p&gt;결과적으로 중복코드를 많이 생성하는 것이기도 하고, 써보니까 오히려 보기에 더 지저분해짐. 물론 예쁘게 되도록 선언하지 못한 내 잘못이겠지만 말이다. 매크로는 derive macro까지 정복하고 활용해야지.&lt;&#x2F;p&gt;
&lt;p&gt;그것보다는, 결정적으로 동기만 지원하게 되어 있는 것이 가장 큰 문제였다. current 런타임을 불러와서 block_on을 이용하는데 신경 조금만 덜 쓰면 에러가 발생했다.&lt;&#x2F;p&gt;
&lt;p&gt;회사에서 리뉴얼하고 있는 서비스 개발 기한도 1주일밖에 안남은 시점인데 여기도 그걸 사용함. 그럼, 어떻게든 끼워맞춰 쓰는게 능사일까? 아니다. 내 경험 상, 그렇게 끼워맞추는데 시간이 더 들고, 실패 시 리스크가 훨씬 크다. ‘이거 하려고 내가 얼마나 공수를 많이 투입했는데’ 하는 순간 돌아올 수 없는 강을 건너게 된다. 심한 경우 라이브러리 하나 때문에 시스템 구조를 바꿔버리는 케이스도 생긴다. 설상가상으로, 그런 식으로 바꾸면 보통 문서 업데이트도 안한다. 곧 다시 개선할거라고 하며, 실제로는 그 부분을 까먹으며.&lt;&#x2F;p&gt;
&lt;p&gt;그래서 어제 모처럼 휴일이겠다, 바로 착수했다. proc-macro 걷어내고, bincode 인코딩을 통해 한 액터 시스템에서 여러 메시지 타입을 이용할 수 있도록 한 피쳐를 그 위에 올렸다. 기존에 마음에 안들던 trait 함수로 디폴트 넣어서 생략 가능하게끔 바꿈. 이제 벌써 4.0.0 버전이다.&lt;&#x2F;p&gt;
&lt;p&gt;적용은 그리 오래 걸리지 않았다. 물론 구조체 위치 등 정리할건 있지만 그냥 매크로가 써줄 애들을 다시 trait으로 원복했을 뿐이기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;오늘은 4.1.0 버전을 개발할 생각이다. 액터 주소를 정규식으로 필터할 수 있도록 할 생각이다. 지금 글쓰는 도중에 구상 완료.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>proc-macro 기반 액터 라이브러리 완성</title>
        <published>2024-12-31T00:00:00+00:00</published>
        <updated>2024-12-31T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/proc-macro-based-actor/"/>
        <id>https://xanthorrhizol.github.io/posts/proc-macro-based-actor/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/proc-macro-based-actor/">&lt;p&gt;&lt;a href=&quot;..&#x2F;2024-12-28_declaration-of-war&quot;&gt;선전포고문&lt;&#x2F;a&gt;&lt;&#x2F;p&gt;
&lt;p&gt;전쟁 종결. 이름하여 2.0.0 버전 런칭.&lt;&#x2F;p&gt;
&lt;p&gt;proc-macro와 bincode 인코딩을 이용해서 타입 구애 없이 액터간 메시지 통신 가능하게 함. 물론 send, recv할 때 serialize, deserialize가 일어나긴 하지만, 매크로단에서 처리해 버려서 사용자는 받을 타입만 명시해 주면 됨.&lt;&#x2F;p&gt;
&lt;p&gt;하지만 아직 미흡한 부분이 많다. 메시지를 정기적으로 보낸다던가 하는 기능은 2.0 버전에서 빠짐. 그리고 에러 핸들링도 그냥 expect를 남발해 둔 상태이다. 거기서 그냥 터짐. 또한 함수 넘기는 부분에서 async가 아직 이용이 안된다. future 적절히 못쓰는 사람은 여기서 갖다 버릴 듯. 아, 이전에도 없었지만, 액터의 주소가 중복되는 케이스도 따로 핸들링 안되어 있다. 아, 라이프사이클도 상태는 관리하긴 하지만 getter가 없다. 그리고 recv할 때 따로 타입 기입 안해도 되게 하고 싶음. 요 부분은 TODO로 둘 것.&lt;&#x2F;p&gt;
&lt;p&gt;이제 회사꺼에 적용해야지 개꿀띠&lt;&#x2F;p&gt;
&lt;p&gt;하려다가 불편해서 바로 3.0.0 릴리즈함…&lt;&#x2F;p&gt;
&lt;p&gt;라이프사이클 getter도 넣었고, 주소 체계도 적용해서 “*” 적절히 써서 여러 액터에 한번에 메시지 보내기도 가능해짐. 부모-자식 관계는 물론 엄마친구 관계(?) 로 필터 걸 수도 있다.&lt;&#x2F;p&gt;
&lt;p&gt;2.x.x은 다 은퇴시켰다&lt;&#x2F;p&gt;
&lt;p&gt;역시 2.0은 뭘 해도 안되는구나.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>리눅스에서 증권사 ActiveX 사용하기</title>
        <published>2024-12-28T00:00:00+00:00</published>
        <updated>2024-12-28T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/activex-on-linux/"/>
        <id>https://xanthorrhizol.github.io/posts/activex-on-linux/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/activex-on-linux/">&lt;p&gt;개발팀 기술검토 의뢰(?)로 들어왔다. 회사 서버에서 주문을 집행하기 위해 증권사 Open API 이용이 가능하냐는 것. 근데 문제는 그 증권사 API는 ActiveX 기반이다. 변태같은 레거시다. 그리고 서버는 당연 리눅스.&lt;&#x2F;p&gt;
&lt;p&gt;결론부터 말하면 기술적으로는 된다.&lt;&#x2F;p&gt;
&lt;p&gt;방법은 간단히 말하면 wine이다. 윈도우 프로그램을 리눅스에서 돌릴 수 있도록 해주는 프로그램이다. 그래서 ActiveX를 이용하는 것 자체는 빠르게 해결되었다.&lt;&#x2F;p&gt;
&lt;p&gt;그런데 다음 문제가 남아 있었다. 인코딩이 EUC-KR이라는 것이다. 담당자가 사고치기 싫다고 레거시는 하나도 안 건드린 듯 하다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;UTF-8에 비해 용량이 반밖에 안되는 EUC-KR을 이용하기 때문인 것으로 보이지만, 여튼 그걸 전송속도 빠르다고 자랑….하고 있었다. 역시 꿈보다 해몽이다. 담당자는&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;사고도 안치고&lt;&#x2F;li&gt;
&lt;li&gt;성능 우위도 홍보하고&lt;&#x2F;li&gt;
&lt;li&gt;꿀도 빨았을 것이다&lt;br &#x2F;&gt;
역시 사람은 머리를 써야 한다. 여기서 머리라는건 잔머리도 포함인 듯 하다.&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;뭐 그래도 원래 금융쪽은 레거시 파티다. 그래서 EUC-KR일 것이라는걸 빠르게 눈치채고 같이 해결. 환경변수 세팅으로 해결했다.&lt;&#x2F;p&gt;
&lt;pre data-lang=&quot;bash&quot; class=&quot;language-bash &quot;&gt;&lt;code class=&quot;language-bash&quot; data-lang=&quot;bash&quot;&gt;LANG=ko_KR.EUC-KR
&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;각설하고, 여기서 한가지 주의할 것이 있다. 이걸 .bashrc같은데 박아넣는 불상사는없어야 한다. 이 환경변수는 wine을 이용할 때 외에는 이용되지 않아야 한다. 안그럼 그럼 평소에 한글이 깨진다. 그래서 난 wine을 도커로 돌림. 비슷한 이유로 리서치팀 프로그램을 돌릴 때 필요한 conda도 로컬에 직접 설치하지 않고, 도커 컨테이너에 home 디렉터리 마운트 해서 필요할 때만 씀.&lt;&#x2F;p&gt;
&lt;p&gt;다음 문제는 공인인증서이다. 한국투자증권 API의 경우 Token을 이용할 수 있도록 되어 있어서 편했는데, 의뢰받은 API는 그게 아니었다. 공인인증서를 매번 사용해야 함. NPKI 디렉터리를 위치해야 하는 위치에 아무리 둬봐도 인식이 안됨. 힌트는 인코딩에 있다.&lt;&#x2F;p&gt;
&lt;pre data-lang=&quot;bash&quot; class=&quot;language-bash &quot;&gt;&lt;code class=&quot;language-bash&quot; data-lang=&quot;bash&quot;&gt;LC_ALL=ko_KR.UTF-8
&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;이 부분을 처음엔 따로 세팅하지 않았었다. 그래서 UTF-8 인코딩인 공인인증서는 인식이 안된 것. 저렇게 넣어 주니 잘 인식되었다.&lt;&#x2F;p&gt;
&lt;p&gt;해결 완료.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>선전포고문</title>
        <published>2024-12-28T00:00:00+00:00</published>
        <updated>2024-12-28T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/declaration-of-war/"/>
        <id>https://xanthorrhizol.github.io/posts/declaration-of-war/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/declaration-of-war/">&lt;img alt=&quot;image.png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-12-28_declaration-of-war&#x2F;image.png&quot; style=&quot;max-width: 100%&quot; &#x2F;&gt;
&lt;p&gt;직접 제작한 &lt;a href=&quot;https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;xan-actor&quot;&gt;액터 라이브러리&lt;&#x2F;a&gt;를 복잡한 프로그램에서 이용하려고 메시지 enum 안에 타입을 다 때려박다 보니 이런 Warning 메시지를 마주하게 되었다. 쉽게 말하면, “어떤 멍청이가 enum을 이딴 식으로 쓰냐?” 라는 말이다. 그것이 바로 나다. 어쩔? 두고봐라. 러스트 컴파일러에 전쟁을 선포한다.&lt;&#x2F;p&gt;
&lt;p&gt;그래서 제네릭은 없는데 타입에 구애받지 않는 액터 라이브러리 새 버전을 개발중이다. 힌트는 매크로이다. 겸사겸사 proc-macro도 정복하는 중이다. 이거 너무 좋잖아?&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>CPU 교체 나비효과</title>
        <published>2024-11-12T00:00:00+00:00</published>
        <updated>2024-11-12T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/the-butterfly-effect/"/>
        <id>https://xanthorrhizol.github.io/posts/the-butterfly-effect/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/the-butterfly-effect/">&lt;p&gt;첫 조립컴퓨터를 살 때, Intel i7 9700K를 구매했다. 연구실에서 인텔만 사용하길래, 고민없이 인텔 구매. 하지만 지금 회사에서 라이젠 24스레드 CPU를 주로 사용하면서 24스레드 개발환경을 집에도 구축하고 싶어짐. 그때 마침 당근에서 Ryzen 9 5900X 매물 발견. 회사 PC랑 똑같다. 바로 구매했다. 앞뒤 보지 않고 말이다. 겸사겸사, 메모리도 회사 PC와 맞춰서 64GB 구매.&lt;&#x2F;p&gt;
&lt;p&gt;사고 보니 생각났다. CPU 소켓이 다르다는 것. 그래서 메인보드 구매. 아니? 쿨러도 안맞았다. 그래서 CPU 쿨러로 수랭쿨러를 하나 구매함. 또 앞뒤 안보고 팬 3개 짜리로 함. 미들타워인데, 당연히 들어가겠지 했다.&lt;&#x2F;p&gt;
&lt;p&gt;네 안됩니다. 전원 버튼을 비롯한 인터페이스가 공간을 차지하는 바람에 3팬 라디에이터는 달 수 없는 상태였다. 근데 CPU 하나 바꾸자고 다 바꾸면 왠지 지는거같아서, 케이스 천장을 니퍼로 뜯어서 수랭쿨러 라디에이터를 그냥 얹어서 케이블타이로 묶어 둚. 잘 돌아갔다.&lt;&#x2F;p&gt;
&lt;details&gt;  
  &lt;summary&gt;충격과 공포의 케이블타이 고정식 라디에이터&lt;&#x2F;summary&gt;  
  &lt;img alt=&quot;20240414_212428.jpg&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-11-12_the-butterfly-effect&#x2F;20240414_212428.jpg&quot; style=&quot;max-width: 100%&quot; &#x2F;&gt;  
&lt;&#x2F;details&gt;
&lt;p&gt;그렇게 잘 쓰다가, 결국 윈도우 가상머신을 거부하는 보험사 녀석 때문에 패배했다. 빼둔 인텔 CPU, 16GB 메모리, 메인보드, CPU쿨러를 이용해서 PC를 하나 더 조립하기로 함. 인텔은 내장그래픽이 있으므로, 필요한 것은 케이스와 파워 뿐이다.&lt;&#x2F;p&gt;
&lt;p&gt;근데 파워, 5900X에 더 큰놈을 달아주면 좋잖아? 그래서 5900X용으로 파워를 구매. 아? 케이스 이거, 수랭쿨러 3팬짜리 감당할 수 있는 녀석이네? 케이스까지 5900X에 새거 주기로 함. 그래서 케이스와 파워만 빼고 탈거.&lt;&#x2F;p&gt;
&lt;p&gt;그러다 사고가 발생했다. CPU가 써멀 구리스 때문에 쿨러와 너무 찰싹 달라붙어서 떨어지지 않았다. 그래서 그냥 그대로 조립해 보려다가 핀이 휘어버림. 부팅 안됨. 반응도 없음. 근데, 핀이 부러진 것도 아니고, 그냥 휘어진거니까 복구 가능하지 않을까? 해서 봤는데, 내 눈알로는 어림도 없다. 수리센터를 알아봐서 의뢰.&lt;&#x2F;p&gt;
&lt;p&gt;오늘 수리된 CPU를 조립해서 부팅했더니 잘 켜지는 것 확인. 하지만 메인보드에서 부품을 뺀 후 새로 연결하면서, 각종 설정이 꼬임. 귀찮긴 하다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 그 윈도우 PC 만들겠다는 그녀석은? 부팅USB 인식 못함. 근데 또 이 시점에서 귀찮음. 뭐 또 선 하나 연결 빼먹었겠지 싶다. 아니면 메인보드 USB 포트 하나가 죽었는데 거따가 연결했다던가 했겠지 뭐.&lt;&#x2F;p&gt;
&lt;p&gt;급하진 않으므로, 다음에 할 생각이다. 지금 회사 일이 휘몰아치는 중이다. 밤마다 부정맥 오는 마당에 이건 사치임.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 0) 머리글</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-00/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-00/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-00/">&lt;p&gt;난 2013년에 라크로스를 시작해 올해로 만 11년이되었다. 운좋게도 2015년부터 대표팀에 소속되어 다른 이들보다 더 나은 조건에서 골리로서 배움을 얻었다. 부상으로 쉬어가는 이 시점에서, 그동안 알아낸 것들을 정리하고, 그것들이 휘발되지 않고 후배들에게 이어졌으면 하는 마음에서 글을 남긴다. 좀 더 압축된 정보를 통해 고생과 시행착오를 덜 겪길 바란다. 그리고 골리를 정하기 위해 가위바위보를 하지 않고, 한 팀 당 두 명 이상의 골리가 서로 의지할 수 있는 시대가 도래하길 기대한다.&lt;&#x2F;p&gt;
&lt;p&gt;난 2022년에 허리에 문제가 심각함을 알아차렸을 때 이미 후배를 키워야 한다는 것은 알고 있었지만, 이런저런 바쁘다는 핑계로 미뤄 웠던 것을 후회한다. 결국 가장 중요한 시기일 때 도움을 주지 못했다. 하지만 과분하게도 후배 골리들은 나름의 방법으로 빠르게 성장해 줬다. 난 이들에게 미래를 맡기고자 한다. 몸을 회복하더라도 길어야 5년이다. 그리고 중간에 시름시름 하다 보면 경기력 또한 더이상 늘기 어렵다. 오히려 선수 기용에 유연성만 떨어뜨릴 뿐이다.&lt;&#x2F;p&gt;
&lt;p&gt;회복 후 돌아갔을 때, 그들이 날 거뜬히 이길 것이라 기대한다. 그리고 그것을 통해 앞으로를 더 자신있게 임하길 원한다. 그리고 그걸 위해 할 수 있는 것들을 하고자 한다. 그 중 하나가 이렇게 글을 쓰는 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;이 시리즈는 선수의 수준에 따라 순서대로 읽을 수 있도록 구성되었다. Feel 받아서 막 써내려간 초안에 대해 읽기 어렵다는 피드백을 준 코치님께 감사의 말씀을 전한다. 자칫 잘못하면, 읽기 어려워서 그저 휘발되어 버리는 글이 될 뻔 했다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 1) 골리는 누구인가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-01/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-01/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-01/">&lt;p&gt;골리는 누구인가 물으면, 대부분은 슛을 막는 사람이라고 할 것이다. 표면적으로는 맞다. 하지만, 팀에서 골리는 누구인가를 물으면 대답하기 어렵다. 최후방수비수인가? 골리는 그냥 골리인가? 난 이에 대한 답으로 “팀원들에게 안정감을 제공하는 포지션”을 내놓고 싶다.&lt;&#x2F;p&gt;
&lt;p&gt;골리는 수비수의 중심에 있다. 모든 공격수는 골리를 향해 달려들고, 모든 수비수는 이를 막고 있다. 그렇기 때문에 골리의 상태는 꽤나 수비수들에게 영향이 크다. 쉽게 생각하면 된다. 전쟁에서 최후방에 있는 장군이 불안하면 병사들이 어떻겠는가. 같은 병사들이라도 뒤에 원균이 있는 것과, 이순신이 있는 것은 확연히 다르다. 따라서, 아래와 같이, 골리의 멘탈은 강해야 한다.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;항상 평온해야 한다. 모든 수비수 사이의 중심에서 안 좋은 기분이 겉으로 드러나면 영향이 크다.&lt;&#x2F;li&gt;
&lt;li&gt;아무리 경기가 절망적이어도, 수비수에게 힘있게 “한번 더 가자!”를 외치는 사람이 되어야 한다.&lt;&#x2F;li&gt;
&lt;li&gt;아무리 경기가 절망적이어도, 주눅들지 않고 즐기는 사람이 되어야 한다.&lt;&#x2F;li&gt;
&lt;li&gt;아무리 아파도 평정심을 유지하고, 가능한 두 발로 걸어서 나가는 사람이 되어야 한다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;당연한 이야기이지만, 멘탈과 함께 실력 또한 중요하다. 아래와 같이 골리는 우수해져야 한다.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;기본적으로 세이브와 패스가 안정적이어야 한다.&lt;&#x2F;li&gt;
&lt;li&gt;막아야 하는 세이브(각이 없는 상태에서 뻔하게 오는 샷들)는 놓치지 않아야 한다.&lt;&#x2F;li&gt;
&lt;li&gt;패스는 하프라인까지는 던질 수 있어야 한다. 그럴 힘이 있어야 가까운 거리의 패스도 정확도가 높아진다. 클리어 전략 또한 더 다양해질 수 있다.&lt;&#x2F;li&gt;
&lt;li&gt;필드에서도 거뜬히 플레이할 수 있는 선수여야 한다. 골리에게 상대편 한 명이 달라붙는다 해서 다른 수비수가 불안에 떨게 하지 않아야 한다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;위의 것들을 실제로 이뤄내기 위한 것은 이 시리즈에서 풀어낼 것이다. 차근차근 따라오면서도, 하나하나 비판하고 실험하면서 자신만의 무기를 갈고닦길 바란다. 쉽게 말해, 연구하는 자세를 가지길 바란다. 내가 연구하며 이런저런 것들을 습득한 이유는, 열악해서가 아니다. 나 또한 스승이 계신다. 난 분명 남들보다 더 나은 조건에서 골리를 해왔다고 했다. 그분은 골리의 기본부터 차근차근 가르쳐 주셨다. 하지만 배운 것을 실제로 몸에 익히기 위해서, 연구는 필수불가결한 것이었다. 따라서 스스로 자료를 찾고 이런저런 것들을 시도해본 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;연구는 어려운 것이 아니다. 어떤 것을 시도하고 결과를 보고 원리를 추측하며 다시 뭔가를 시도하는 과정의 반복이다. 주입된 지식은 전체의 80% 뿐이다. 하지만 이 80%를 압축해서 이해하고 더 많은 것들을 받아들이기 위해서는 20%의 숨겨진, 즉 전달되지 않은 내용을 스스로 찾아내야 한다. 숨겨진 20%에 전달받은 80%를 제대로 이해하기 위한 핵심들이 숨어있다. 그걸 찾아내는 과정이 연구인 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;시작부터 많은 일들을 요구하는 것 같지만, 골리는 그런 자리다. 하지만 그렇기 때문에 매력적이고, 항상 배울 것이 있기에 끝없이 즐거울 것이다. 만약 쉽고 빠르게 늘길 원한다면, 골리랑은 맞지 않을 수 있으니 유의했으면 한다. 반대로 어려운 것을 실제로 해냈을 때의 성취감을 삶의 동력으로 삼을 수 있는 사람이라면, 이보다 더 잘맞는 포지션은 없을 것이다. 환영한다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 2) 훈련이란 무엇인가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-02/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-02/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-02/">&lt;p&gt;훈련은 실제 상황에서 해야 하는 것들이 자동으로 이루어지게 하기 위해, 실제 상황이 오기 전에 그것들의 일부를 실제로 경험하며 몸에 익히는 일련의 과정이다. 그렇기 때문에 훈련의 효과는 실전과 유사할 수록, 반복이 많을 수록 좋다. 팀스포츠에서 훈련의 종류엔 두 가지가 있다. 팀 훈련과 개인 훈련이다. 그럼 각 훈련은 골리에게 무슨 의미일까?&lt;&#x2F;p&gt;
&lt;h2 id=&quot;gaein-hunryeon&quot;&gt;개인 훈련&lt;&#x2F;h2&gt;
&lt;p&gt;개인 훈련이야 말로, 골리가 성장하기 위한 핵심이다. 물론 다른 선수들도 마찬가지이긴 하다. 하지만 골리의 경우 그 영향이 다른 선수들에 비해 크다. 왜냐하면, 세이브라는 골리의 제1임무는, 슈팅을 한 순간 오로지 골리와 공 사이의 1대 1 대결이기 때문이다. 변수는 슛과 골리 자신의 움직임 뿐이다. 따라서 골리의 움직임이 개선된다면 결과는 바로 나타난다. 또한 클리어에 있어서도, 다른 선수들에 비해 패스 외의 것들에 대한 요구치가 낮다. 때문에 패스 훈련을 했을 때 클리어에서 효과를 바로 체감할 수 있다. 패스에 자신있고, 이에 들이는 에너지가 적으면, 팀 훈련에서 클리어 전술 자체에 집중할 수 있고, 이 또한 성장의 발판이 된다. 혼자서도 할 수 있는게 많으니 즐겁지 않은가?&lt;&#x2F;p&gt;
&lt;h2 id=&quot;tim-hunryeon&quot;&gt;팀 훈련&lt;&#x2F;h2&gt;
&lt;p&gt;팀 훈련은 모두와 함께하는 훈련이고, 팀이 합을 맞춰가기 위한 훈련이다. 거기서 골리는 이 날이 실전이다. 팀 훈련에서의 슈팅은 웜업을 제외하고는 모두 실전과 같다. 골리가 뭔가를 연습하려고 한다고 해서 슈터가 이를 맞춰주지 않는다. 팀 훈련은 개인 훈련의 성과를 시험하는 날이다. 추가적으로 클리어 등 다른 선수들과 합을 맞춰가는 일에도 참여하게 될 것이다. 물론 언급했듯이, 이 또한 개인 훈련 없이는 어렵다. 기억하라. 팀 훈련은 경기와 같다. 그리고 이것은 축복이다. 필드 선수들보다 골리에게 팀 훈련의 효과는 높다. 실전과 더 유사하기 때문이다. 또한 팀 훈련은 실전 상황에서 무엇이 통하는지를 실험해볼 수 있는 장이기도 하다. 하나 하나 알아갈때. 즐겁지 않은가?&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;💡팀 훈련은 실전이지만, 여기서 연습해야 하는 것이 있다. 심리기술을 활용해보는 것과, 스스로의 몸이 가장 잘 알아듣는 언어적인 주문을 어떻게 하는지 찾는 것이다. 이는 실제 경기에서도 끝없이 연습되고 이용되며 가다듬어질 것이다. 그리고 이에 대한 설명 또한 이 시리즈에 포함할 것이다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 3) 슈팅에 어떻게 대비해야 하는가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-03/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-03/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-03/">&lt;p&gt;골리들이 세이브를 하기 전에 공을 눈으로 따라가는걸 보면, 엉거주춤한 자세로 각자의 개성을 뽐내고 있을 것이다. 그리고 그것들은 이유가 있다. 하지만 골리들에게 전달되는 단편적인 지식들은 단순히 “이렇게 한다”로만 전달된다. 그럼 왜 이렇게 해야 하고, 정확히 어떤 느낌일까? 내가 참고했던 사이트의 그림을 첨부하고 설명해 보겠다.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;img src=&quot;https:&#x2F;&#x2F;laxgoalierat.com&#x2F;wp-content&#x2F;uploads&#x2F;2016&#x2F;03&#x2F;Lacrosse-Goalie-Stance-Infographic-1024x933.jpg&quot; alt=&quot;&quot; &#x2F;&gt;&lt;&#x2F;p&gt;
&lt;p&gt;출처: https:&#x2F;&#x2F;laxgoalierat.com&#x2F;the-basics-of-making-a-save&#x2F;&lt;&#x2F;p&gt;
&lt;p&gt;7가지의 요소들이 그림과 함께 첨부된 좋은 자료이다. 이제부터 이것의 디테일을 잡아보자.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;feet-a-little-wider-than-shoulder-width&quot;&gt;Feet A Little Wider than Shoulder Width&lt;&#x2F;h3&gt;
&lt;p&gt;(발을 어깨너비보다 조금 더 넓게 선다)&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;목적: 좌우로 빠르게 이동할 수 있으면서, 무게중심을 안정적으로 가져가기 위함이다.&lt;&#x2F;li&gt;
&lt;li&gt;디테일
&lt;ul&gt;
&lt;li&gt;점프했다가 착지할 때 가장 편하고 안정적인 너비로 선다. 또는, 좌우로 빠르게 왕복해서 이동하면서도 무게중심을 안정적으로 유지할 수 있는 너비를 찾아도 좋다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h3 id=&quot;bent-knees&quot;&gt;Bent Knees&lt;&#x2F;h3&gt;
&lt;p&gt;(무릎을 굽힌다)&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;목적: 당장이라도 튀어나가 세이브를 할 수 있도록 하기 위함이다.&lt;&#x2F;li&gt;
&lt;li&gt;디테일
&lt;ul&gt;
&lt;li&gt;제자리에서 가장 높이 뛰기 위해 나오는 무릎 굽힘 정도가 적당하다.&lt;&#x2F;li&gt;
&lt;li&gt;높게 점프하려고 할 때 더 내려가지 않고 바로 뛰어오를 수 있는 높이이기도 하며, 무릎이나 허리를 더 구부리지 않아도 스틱을 바닥에 터치할 수 있는 정도의 높이이기도 하다.&lt;&#x2F;li&gt;
&lt;li&gt;하지만 이 힘든 자세를 경기 내내 하고 있을 필요는 없다. 곧 세이브를 해야 할 것 같을 때 이 자세를 취한다. 이 타이밍은 팀 훈련을 통해 경험을 쌓으며 감이 올 것이다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;blockquote&gt;
&lt;p&gt;💡제자리에서 높이 뛸 때, 무릎을 완전히 구부려야 한다고 생각한다면 오산이다. 90도보다 더 내려가진 않는다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;h3 id=&quot;arms-out-and-away-from-body&quot;&gt;Arms Out and Away From Body&lt;&#x2F;h3&gt;
&lt;p&gt;(몸으로부터 팔을 멀리 떨어뜨린다)&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;목적: 세이브를 위해 스틱 헤드가 좀 더 적은 거리를 이동하게 하기 위함이다. 앞으로 갈 수록 슈팅과 좀 더 가깝기 때문이다.&lt;&#x2F;li&gt;
&lt;li&gt;디테일
&lt;ul&gt;
&lt;li&gt;목적을 달성할 수 있다면, 본인의 스타일에 맞는 것을 찾으면 된다.&lt;&#x2F;li&gt;
&lt;li&gt;보통 스틱이 내 시야 안에 있도록 하라고 한다. 하지만 2019년에 미국의 대학교 선수들 중 가장 우수한 선수를 선발해 수여하는 상인 Tewaaraton award를 수상한 &lt;a href=&quot;https:&#x2F;&#x2F;laxgoalierat.com&#x2F;megan-taylor&#x2F;&quot;&gt;Megan Taylor&lt;&#x2F;a&gt; 선수의 경우, 헤드가 약간 뒤로 기울어져 있었다. 나도 2015년에 그걸 따라하며 세이브율이 한층 올랐다. 따라서, 본인에게 맞는 자세가 맞는 자세이다. 고정관념을 가지지 마라.&lt;&#x2F;li&gt;
&lt;li&gt;나름의 분석으로는, 적극적으로 슈터에게 다가가서 슈터의 스틱을 직접 막는 골리의 경우 스틱이 앞으로 가는 것이 유리하고, 슈터의 슛에 반응하며 막는 골리에게는 스틱이 살짝 뒤로 기울어지는 것이 유리하다. Megan Taylor의 경우, 반응하며 막는 것 자체에 더 많은 신경을 기울였다고 한다. 체구가 작기 때문에 앞으로 다가가면 오히려 머리 위 공간이 보여서 불리하므로 그런 선택을 한 것으로 보인다. 단 유의해야 할 것이 있다. 나 또한 스틱을 약간 뒤로 기울였지만, 시선 안에 스틱 헤드의 일부가 보이는 것은 유지한다. 완전히 머리 옆으로 보내버린다면 스틱이 작게 보여서 빈 공간이 더 보이기도 하며, 스틱이 움직일 때 머리를 피해가야 하기 때문에 빠른 움직임에 불리해진다.&lt;&#x2F;li&gt;
&lt;li&gt;슈터에게 다가가서 스틱을 직접 막는게 본인에게 맞는지, 아니면 공을 보고 반응해서 막는 것이 본인에게 맞는지는, 훈련을 통해 알아낼 수 있을 것이다. 여러 자세를 시도해 보고 가장 좋은 것을 찾아라. 더 나아가서, 두 가지를 함께 할 수 있는 골리가 되어, 각 상황에 맞는 자세를 찾아라.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h3 id=&quot;proper-grip-on-the-stick&quot;&gt;Proper Grip on the Stick&lt;&#x2F;h3&gt;
&lt;p&gt;(올바르게 스틱을 쥔다)&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;목적: 스틱의 움직임에 막힘이 없으면서도 컨트롤을 유지하기 위함이다.&lt;&#x2F;li&gt;
&lt;li&gt;디테일
&lt;ul&gt;
&lt;li&gt;그립이 강하면 스틱의 움직임에 제약이 따르고, 팔에 힘도 들어간다.&lt;&#x2F;li&gt;
&lt;li&gt;팔에 힘을 빼야, 가장 빠르게 슈팅에 반응할 수 있다. 엄지와 검지만 이용하라고 설명했지만, 굳이 엄지와 검지만 이용할 필요는 없다. 팔에 힘을 뺄 수 있다면, 그립을 좀 느슨하게 하는 수준으로도 충분하다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;blockquote&gt;
&lt;p&gt;💡 그립을 느슨하게 시작하더라도, 세이브 시 목표 지점으로 도달하며 멈추면 알아서 힘이 들어간다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;h3 id=&quot;straight-flat-back-with-slight-bend-at-hips&quot;&gt;Straight, Flat Back with Slight Bend At Hips&lt;&#x2F;h3&gt;
&lt;p&gt;(고관절을 약간 굽히고 허리는 꼿꼿하게 세운다)&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;목적: 무릎을 굽히면서도, 골대를 좀 더 가리면서도, 무게중심을 유지하기 위함이다.&lt;&#x2F;li&gt;
&lt;li&gt;디테일
&lt;ul&gt;
&lt;li&gt;고관절은 무릎을 굽히면서도 무게중심이 뒤로 가지 않게 하는 정도가 적당하다.&lt;&#x2F;li&gt;
&lt;li&gt;그 이상의 역할을 하진 않는다. 상체를 펴라고 하는 이유는, 골리가 최대한 커보이게 하기 위한 것이다. 항상 슈터를 정면으로 봐서 빈공간을 최대한 줄여주는 것 또한 이를 위함이다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h3 id=&quot;hands-well-positioned&quot;&gt;Hands Well Positioned&lt;&#x2F;h3&gt;
&lt;p&gt;(두 손이 적당하게 위치한다)&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;목적: 골리의 스틱 헤드를 가장 빠르게 움직일 수 있도록 하기 위함이다.&lt;&#x2F;li&gt;
&lt;li&gt;디테일
&lt;ul&gt;
&lt;li&gt;골리 스틱은 무게중심이 헤드에 몰려 있기 때문에, 위쪽을 잡을 수록 유리하다.&lt;&#x2F;li&gt;
&lt;li&gt;그리고 스틱에 회전도 함께 이루어지기 때문에, 두 손 사이의 간격이 약간 벌어지는 것이 유리한데, 이 적절한 거리는 생각보다 좁다. 약 30cm 혹은 어깨너비를 권장한다. 고치는 과정에서 제시된 것처럼 스틱 테이프를 이용해도 좋을 것이다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h3 id=&quot;relaxed&quot;&gt;Relaxed&lt;&#x2F;h3&gt;
&lt;p&gt;(긴장을 푼다)&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;목적: 가장 빨리 몸이 반응할 수 있는 상태를 유지하기 위함이다.&lt;&#x2F;li&gt;
&lt;li&gt;디테일
&lt;ul&gt;
&lt;li&gt;집중과 긴장은 서로 다른 영역이다.&lt;&#x2F;li&gt;
&lt;li&gt;집중하되, 몸의 긴장은 풀어야 반응속도와 신체의 스피드가 가장 빠르다.&lt;&#x2F;li&gt;
&lt;li&gt;긴장 푸는 방법은 앞으로 설명하겠다. 기본적으로는 어깨와 손에 힘을 빼고, 머리를 비워라.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 4) 어떻게 세이브하는가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-04/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-04/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-04/">&lt;p&gt;골리의 제1임무는 슛을 막는 것이다. 다른 모든 것들은, 세이브가 가능해야 할 수 있는 것들이다. 그럼, 어떻게 세이브를 할까?&lt;&#x2F;p&gt;
&lt;h2 id=&quot;seibeu-dongjagyi-gibon&quot;&gt;세이브 동작의 기본&lt;&#x2F;h2&gt;
&lt;p&gt;세이브는 기본적으로 슛을 막는 것이다. 그럼 슛을 가장 잘 막을 수 있는 유리한 방법은 무엇일까? 그걸 알아내기 위해서는 기본적으로 슈팅의 속성을 알아야 한다.&lt;&#x2F;p&gt;
&lt;p&gt;슈팅은, 슈터의 스틱헤드로부터 시작되어 골대를 향한다. 시작점은 면적이 0인 하나의 점이고, 골대는 가로 세로 180cm의 면적을 가진 평면이다. 그렇다면, 슛이 시작되었을 때, 골대에서 막는 것이 좋을까? 아니면 슈터의 스틱 헤드 가까이서 막는 것이 좋을까? 쉽다. 슈터의 스틱과 가까워야 더 유리하다. 그렇다면, 슈터의 스틱과 더 가까이서 세이브를 하기 위해선 어떻게 해야 할까? 익히 들었던 그 동작. &lt;strong&gt;펀치&lt;&#x2F;strong&gt;다. 슈터의 스틱 헤드에서 날아오는 공을 향해 마치 펀치하듯이 팔을 뻗으며 공을 잡는다. 이 때 펀치는 정확한 지점에서 멈출 수 있어야 한다. 목표 지점에 빠르게 도달한 후, 멈춰서 공이 들어오기까지 기다려야 한다. 당연히, 헤드를 보낸 후 공을 낚아채듯 잡으려 하면 안된다. 낚아채는 세이브는 없다. 공이 포켓에 들어온걸 느끼면서 잡아라.&lt;&#x2F;p&gt;
&lt;img alt=&quot;IMG_0028.jpeg&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-09-26_lacrosse-goalie-04&#x2F;IMG_0028.jpeg&quot;&gt;
&lt;p&gt;또한 세이브를 할 때는, 기본적으로 슛을 향해 최단거리로 스틱 헤드를 이동시켜야 한다. 0.01초까지 중요한 시점에서, 다른 동작을 함께하면 치명적이다. 따라서 기본적으로 스틱 헤드는 슛을 향해 직선으로 향해야 한다. 여기에 한 가지의 디테일이 있다. 아랫손도 스틱의 움직임에 기여해야 한다는 것이다. 어떤 스타일로 세이브를 하는지에 관계없이, 아랫손도 스틱 헤드가 움직이는데 힘을 보태줘야 한다. 그래야 스틱을 빠르게 움직일 수 있다.&lt;&#x2F;p&gt;
&lt;p&gt;또한, 중간에 망설이지 않아야 한다. 골리는 모든 슛을 세이브하는 사람이 아니다. 좀 더 많은 슛을 막으려는 사람이다. 본전은 골을 허용하는 것이고, 세이브는 골을 넣은 것과 같다고 생각해야 한다. 슈터가 골대 안을 못맞출까봐 슛을 하지 않는다면, 그 슈터는 쓸모가 있을까? 골대를 못맞추고 턴오버가 일어날 수 있는 리스크를 안고도 슛을 하는게 슈터이다. 슈터는 골을 넣으면 신바람이 나고, 슛이 골대를 벗어나면, 그저 체이스를 시도하고 다시 시도할 뿐이다. 골리도 같다. 슈터와의 승부에서 세이브를 시도하고, 실패하면 다음을 준비할 뿐이다. 망설이지 말고 한판 승부 시원하게 하고, 다음을 준비하라.&lt;&#x2F;p&gt;
&lt;p&gt;다음으로, 골리의 몸은 스틱으로 공을 막지 못하더라도 그 뒤에서 공을 한 번 더 막을 수 있도록 스틱이 가는 곳으로 함께 따라가야 한다. 이것을 &lt;strong&gt;스텝투볼&lt;&#x2F;strong&gt;이라 한다. 하지만 이 때 주의해야 할 것은, 몸을 보내며 스틱을 뻗는 것이 아니라, 스틱을 뻗어서 몸이 딸려가야 한다. 마치 다이빙을 할 때 손을 먼저 뻗듯이 말이다. 왜냐하면, 몸과 스틱을 함께 보내려는 생각을 하게 되면, 스틱이 빠르게 목적 지점으로 도달할 수 있음에도 불구하고, 온몸이 따라오는걸 기다려 주느라 스피드가 죽기 때문이다. 스틱을 먼저 보내고 그 방향으로 머리만 함께 기울어 있다면 몸은 저절로 따라올 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;단, 잊으면 안되는 것은, 근본적으로 하체 및 코어에 파워와 안정성이 없으면 헤드를 제아무리 빨리 보내더라도 몸이 딸려오기 어렵다는 것이다. 헤드를 빠르게 보내면서 몸통에 가해지는 반작용을 버텨내야 하기 때문이다. 이걸 버티지 못하면 에너지가 세어나가거나 몸통이 회전해 버린다.&lt;&#x2F;p&gt;
&lt;p&gt;나 또한 스틱과 몸을 함께 보내야 한다는 오개념 때문에 꽤나 긴 기간 동안 세이브율이 정체되어 고생했다. 뭔가 잘 안돼서 “아, 맞다. 스텝투볼!” 하고 그걸 개선하려 하면 더더욱 골을 많이 허용하는 악순환이었다.&lt;&#x2F;p&gt;
&lt;p&gt;마지막으로, 항상 공을 끝까지 눈으로 따라가야 한다. 공을 시선에서 풀어주는 시점은, 내 포켓 안으로 공이 들어왔다는 것이 확정되는 순간 뿐이다. 눈으로 따라가며, 머리도 함께 공을 향해주면, &lt;strong&gt;스텝투볼&lt;&#x2F;strong&gt;이 자동으로 될 것이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;seibeu-seutail&quot;&gt;세이브 스타일&lt;&#x2F;h2&gt;
&lt;p&gt;세이브를 하는 스타일은 크게 세 가지가 있다. 이중 하나는 아주 구식 방법으로 요즘은 잘 쓰이지 않는다. 따라서 요즘 쓰이는 두 가지 방법을 소개하겠다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;jigseonhyeong&quot;&gt;직선형&lt;&#x2F;h3&gt;
&lt;p&gt;↖️⬆️↗️&lt;&#x2F;p&gt;
&lt;p&gt;⬇️⭕➡️&lt;&#x2F;p&gt;
&lt;p&gt;↙️⬇️↘️&lt;&#x2F;p&gt;
&lt;p&gt;보통의 방법 대로 스틱을 목적 지점으로 회전시키며 움직이되, 몸을 기준으로 하지 않고 스틱 헤드의 경로를 직선으로 맞추는 방법이다. 여기서, 다시 언급한다. 스틱 헤드를 목적지점으로 보내는 것에 더해, 아랫손을 이용해서 헤드의 움직임에 속도를 더 붙여줘야 한다는 것을 잊지 마라. 윗팔의 힘만으로는 충분한 속도를 낼 수 없다. 아랫손이 스틱을 함께 당겨준다면 헤드는 더 빠르게 목적 지점으로 향할 수 있다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;push-push-motion&quot;&gt;Push &amp;amp; Push motion&lt;&#x2F;h3&gt;
&lt;p&gt;↗️➡️↗️&lt;&#x2F;p&gt;
&lt;p&gt;↘️⭕➡️&lt;&#x2F;p&gt;
&lt;p&gt;⬇️➡️➡️&lt;&#x2F;p&gt;
&lt;p&gt;이 모션은 Ted Bergman이라는 코치가 고안해낸 방법이다. 실제로 많은 장점이 있는 자세이다. 스틱 헤드를 공을 향헤 직선으로 보내는데 더해, 오른손과 왼손이 동시에 같은 방향을 향하도록 하는 방법이다. 이렇게 되면 세이브를 할 때 스틱이 보통 가로로 눕는다. 기존 방법의 경우 윗손은 미는 방향으로, 아랫손은 당기는 방향으로 움직이는데 반해, 이 움직임은 동시에 같은 방향으로 움직인다. 따라서 마치 다이빙을 하는 듯한 모션이 자연스럽게 나오며, 하체와 코어의 힘까지 끌어와서 쓸 수 있다. 전신의 에너지를 다 끌어와서 세이브에 집중시키는 방법이라 할 수 있다. 그리고 다시 한 번 리마인드한다. 아랫손도 목적 지점으로 스틱을 빠르게 보낼 수 있도록 힘을 보태도록 하라.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;mueoseul-iyonghaeya-hana&quot;&gt;무엇을 이용해야 하나&lt;&#x2F;h3&gt;
&lt;p&gt;그렇다면, 더 최신인 Push &amp;amp; Push motion을 이용해야 할까? 꼭 그렇지만은 않다. 각자에게 더 맞는 방법이 있을 뿐이다. Jake 선수의 경우 1번 보다도 더 전통적인 방법으로 충분한 세이브를 한다. 한국 여자대표팀의 성장을 함께하며 뒤에서 든든하게 골문을 지켜주던 전설적인 골리인 조유리 선수의 경우 1번을 사용한다. 그리고 일본의 골리들 또한 대부분 1번을 사용한다. 나 또한 1번을 사용한다. 그럼 2번은 누가 사용하냐고? 미국의 Ted Bergman 코치에게 배움을 얻은 분들이리라 생각된다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 1번이 가장 무난하니 1번만 해봐야 하는 것일까? 아니다. 해보지도 않고 섵부른 판단을 하지 않길 바란다. 난 2번을 해보고 싶었고 실제로 2번으로 넘어가기 위해 연습을 하고 있었지만, 몸이 이를 받아들여주지 않는걸 깨닫고 포기한 케이스이다. 허리가 좋지 않았기 때문이다. 하지만 실제로 해봤을 때, 분명 장점이 있었다. 이에 더해, 처음부터 스틱을 머리 옆에 가로로 눕힌 자세로 시작해 보기도 했다. 기존 방법에 익숙한 사람들은 자세가 이상하다며 훈수를 뒀지만, 실제로는 아래쪽 샷을 막는데 유리했다. 눈치보지 않고, 자신만의 스타일을 갖추어나가길 바란다. 혹시 모른다. 라크로스 골리계의 배면뛰기가 나올 수도 있다(배면뛰기는 높이뛰기 기술이다. 기존에 앞으로 넘거나 가위뛰기를 하던 시대에, 발상을 바꿔서 등으로 바를 타고넘도록 개발되었고, 이전의 방법이 따라올 수 없는 수준으로 기록이 좋아졌다)&lt;&#x2F;p&gt;
&lt;p&gt;각 방법의 장단점은 표로 정리해 보겠다. 각자 자신에게 맞는 방법을 찾아가길 바란다. 그리고, 항상 새로운 것을 시도해보는 것에 두려움을 갖지 마라. 직접 개발해도 좋다. 그것이 틀리더라도, 그걸 개발하는 과정에서 알아낸 세이브의 원리는 앞으로 크게 도움이 될 것이다.&lt;&#x2F;p&gt;
&lt;table&gt;&lt;thead&gt;&lt;tr&gt;&lt;th&gt;구분&lt;&#x2F;th&gt;&lt;th&gt;직선형&lt;&#x2F;th&gt;&lt;th&gt;Push &amp;amp; Push&lt;&#x2F;th&gt;&lt;th&gt;이유&lt;&#x2F;th&gt;&lt;&#x2F;tr&gt;&lt;&#x2F;thead&gt;&lt;tbody&gt;
&lt;tr&gt;&lt;td&gt;에너지 소비&lt;&#x2F;td&gt;&lt;td&gt;&lt;strong&gt;적음&lt;&#x2F;strong&gt;&lt;&#x2F;td&gt;&lt;td&gt;많음&lt;&#x2F;td&gt;&lt;td&gt;직선형이라 해도, 결국 회전 동작의 일종. 이건 상체만으로 할 수 있지만, Push &amp;amp; Push는 온몸이 함께해야 함&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;공에 대한 집중력&lt;&#x2F;td&gt;&lt;td&gt;&lt;strong&gt;유리&lt;&#x2F;strong&gt;&lt;&#x2F;td&gt;&lt;td&gt;불리&lt;&#x2F;td&gt;&lt;td&gt;기존 방법은 다른 신체 분절의 움직임이 전체적으로 덜하기 때문에 집중력을 유지하는데 유리&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;포지셔닝(정면 바라보기)&lt;&#x2F;td&gt;&lt;td&gt;불리&lt;&#x2F;td&gt;&lt;td&gt;&lt;strong&gt;유리&lt;&#x2F;strong&gt;&lt;&#x2F;td&gt;&lt;td&gt;스틱에 회전 동작이 들어가게 되면 몸이 함께 회전하려 하기 때문.&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;잠김 현상&lt;&#x2F;td&gt;&lt;td&gt;있음&lt;&#x2F;td&gt;&lt;td&gt;&lt;strong&gt;없음&lt;&#x2F;strong&gt;&lt;&#x2F;td&gt;&lt;td&gt;스틱을 회전시키면 그 각도에 따라 간혹 팔의 움직임이 잠길 수 있음.&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;tr&gt;&lt;td&gt;공을 향한 헤드의 속도&lt;&#x2F;td&gt;&lt;td&gt;&lt;strong&gt;유리 혹은 비슷&lt;&#x2F;strong&gt;&lt;&#x2F;td&gt;&lt;td&gt;불리 혹은 비슷&lt;&#x2F;td&gt;&lt;td&gt;Push &amp;amp; Push를 하게 되면, 스틱 전체를 통째로 옴직이기 때문에 스틱의 무게를 온전히 감당해야 함. 회전을 시키는 경우, 전체적으로 움직임이 덜해 헤드의 속도가 빨라짐. 하지만, 팔의 힘이 약한 사람의 경우, Push &amp;amp; Push를 했을 때, 하체의 힘을 끌어다 쓸 수 있게 되면서, 오히려 속도가 더 잘 날 수도 있음. 게다가 요즘은 스틱 섀프트의 무게가 가볍기 때문에 큰 차이가 없다.&lt;&#x2F;td&gt;&lt;&#x2F;tr&gt;
&lt;&#x2F;tbody&gt;&lt;&#x2F;table&gt;
&lt;h2 id=&quot;8gaji-banghyangeul-maggi-wihan-jase&quot;&gt;8가지 방향을 막기 위한 자세&lt;&#x2F;h2&gt;
&lt;p&gt;방향엔 8가지가 있지만, 옆 방향으로는 Stick side와 Middle, Off-stick side로 나눈다. Stick side는 골리가 스틱을 든 방향을 가리키며, Off-stick side는 골리가 스틱을 쥔 쪽의 반대쪽을 의미한다. Middle은 골리의 몸쪽을 뜻한다. 따라서 기본적으로 Stick side는 골리에게 더 유리하다. 반대로 Off-stick side는 골리에게 부담이다. 스틱 헤드를 이동시켜야 하는 거리가 더 길 뿐만 아니라, 허리 높이의 경우, 위로 돌릴 지, 아래로 돌릴 지 선택지가 나뉘어버려서 혼란을 주기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;위아래 방향으로는  High, Hip, Low로 나눈다. 그리고 또 한 가지, Bound가 있다. High는 위쪽, Hip은 허리 및 엉덩이 높이, Low는 아랫 방향, 그리고 Bound는 바닥에 튀긴 공을 뜻한다. 그럼 지금부터 각 방향에 대한 설명을 진행하도록 하겠다.&lt;&#x2F;p&gt;
&lt;hr &#x2F;&gt;
&lt;p&gt;🔴🔴🔴&lt;&#x2F;p&gt;
&lt;p&gt;⭕⭕🔴&lt;&#x2F;p&gt;
&lt;p&gt;⭕⭕⭕&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Stick side High, Hip, Middle High, Off-stick High&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;기본적으로 이 부분들은 필드와 별 다를게 없다. 펀치하여 슈터의 슛을 잡아먹어라.&lt;&#x2F;p&gt;
&lt;hr &#x2F;&gt;
&lt;p&gt;⭕⭕⭕&lt;&#x2F;p&gt;
&lt;p&gt;⭕⭕⭕&lt;&#x2F;p&gt;
&lt;p&gt;🔴🔴🔴&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Stick side, Middle Low, Off-stick Low&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;낮은 공은 특별하다. 스틱에서부터 가장 멀리 떨어져 있고, 골리의 눈과도 가장 멀기 때문이다. 반대로 슈터는 낮은 슛을 했을 때, 좀 벗어나더라도 바닥에 튀기기 때문에 오히려 유리하다. 여기서 기억해야 하는 것은, 어떻게 했을 때 가장 유리한지이다. 아까 설명했듯이, 볼과 가까워져야 한다. 낮게 오는 공이 바닥에 튀거나, 골리에게 도착하기 전에, 나가서 잡아먹어야 한다. 낮은 공보다도 더 어려운 Bound가 되기 전에 승부를 끝내는게 좋다.&lt;&#x2F;p&gt;
&lt;p&gt;이때, 스틱 헤드만 내리고는 공을 눈에서 떼는 경우가 많다. 그럼 안 된다. 스틱 헤드와 함께 골리의 눈도 항상 공을 향해 바라보고 있어야 하고, 머리도 함께 따라가야 한다. 머리가 가면 몸은 따라온다. 말의 고삐만 가지고 말의 온몸을 통제할 수 있듯이 말이다.&lt;&#x2F;p&gt;
&lt;hr &#x2F;&gt;
&lt;p&gt;⭕⭕⭕&lt;&#x2F;p&gt;
&lt;p&gt;🔴⭕⭕&lt;&#x2F;p&gt;
&lt;p&gt;⭕⭕⭕&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Off-stick side Hip&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;과거 스틱을 회전시키며 세이브를 하던 시절엔 이곳을 향해 어느 방향으로 스틱을 돌릴 것인가는 희대의 난제였다. 인체의 구조 상 위쪽으로 돌리면 거리상 가깝지만, 허리를 옆으로 많이 구부려야 하고, 반대로 아래를 통해 가면 거리가 멀기 때문에 엄청난 파워로 빠르게 스틱을 돌려야 했다. 하지만, 슛을 향해 스틱 헤드를 직선으로 보내야 한다는 개념이 생긴 이후부터 이것은 더이상 난제가 아니다. 어디를 통해 가던지 간에 직선으로 가면 그만이다. 위쪽이 더 편한 상태라면 위쪽을 통해, 아래쪽이 더 편한 상태라면 아래쪽을 통해 스틱 헤드를 슛으로 향하도록 하면 된다. 결정했다면 그냥 실행하고 끝까지 한다. 그것이 맞는지 판단하려 하지 마라.&lt;&#x2F;p&gt;
&lt;hr &#x2F;&gt;
&lt;p&gt;🔴🔴🔴&lt;&#x2F;p&gt;
&lt;p&gt;🔴🔴🔴&lt;&#x2F;p&gt;
&lt;p&gt;🔴🔴🔴&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;Bound&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;공을 끝까지 눈으로 따라가야 하는 이유이다. 공이 바닥에 닿는 순간, 공에 걸린 회전, 슈터가 슛을 쏜 높이, 바닥의 상태에 따라 서로 다른 곳으로 가게 된다. 따라서, Low로 오는 것처럼 스틱으로 최대한 바운드 지점까지 가까이 가서 바운드 자체를 최대한 막되, 이후 튀어오르는 공을 끝까지 눈과 헤드로 따라가야 한다. 물론 기억하라. 이전 동작을 끝내고 다음을 이어하는 것이지, 중간에 수정하는 것이 아니다. 빠르게 2번 시도하라.&lt;&#x2F;p&gt;
&lt;hr &#x2F;&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 5) 어떻게 클리어하는가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-05/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-05/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-05/">&lt;p&gt;세이브를 했다면, 다음은 이 공을 무사히 공격 진영으로 넘겨줄 수 있어야 비로소 득점 찬스를 얻어낼 수 있다. 이렇게, 수비 상황에서 공을 빼앗는데 성공한 후 공격 진영으로 공을 전달하는 것을 클리어라고 한다. 클리어가 되지 않는 팀은 아무리 많은 세이브를 해도 이기지 못한다. 물론 드로우를 다 따면… 축하한다. 압승이다. 그렇다면 클리어는 어떻게 해야 하는 것일까? 먼저, 전체적으로 어떤 과정을 거치는지를 살펴보자.&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;당장이라도 패스를 줄 수 있는 자세를 유지한다. 즉, 스틱을 올리고 있는다.&lt;&#x2F;li&gt;
&lt;li&gt;우리팀 선수들이 어떻게 하고 있는지 파악하며 기회를 찾고 패스한다.&lt;&#x2F;li&gt;
&lt;li&gt;필드로 나가서 수비수들과 함께 클리어를 끝까지 돕는다.&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;p&gt;이제부터, 이에 대한 디테일을 잡아 보도록 하겠다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;bbareuge-paeseureul-juneun-bangbeob&quot;&gt;빠르게 패스를 주는 방법&lt;&#x2F;h2&gt;
&lt;p&gt;기회가 났을 때, 상대팀은 그 상황이 오래 유지되는 것을 허용치 않는다. 따라서, 기회가 났을 때 바로 안정적인 패스를 줄 수 있어야 한다. 실제 상황에서 빠르게 패스를 주는 방법은 아래와 같다.&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;크레이들을 1회 실시해서 공의 위치를 맞춘다.&lt;&#x2F;li&gt;
&lt;li&gt;목적 지점으로 던진다.&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;p&gt;위의 간결한 과정이 가능하기 위해서는 근본적으로 패스와 스틱스킬 실력을 갈고닦아야 한다. 필드선수와 다를 바 없이, 다양한 던지기 스킬을 함께 배우고 연습하며, 스틱을 손에 항상 들고 다니는 것이 좋다. 재미도 있을 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;또한, 약간의 잡다한 기술이 있다. 손바닥의 감각을 더 살리기 위해 골리 장갑의 손바닥 부분을 잘라내는 것이다. 이렇게 하면 손바닥은 맨손이기 때문에 감각이 더 예민해지고, 스틱과 공의 무게가 더 섬세하게 느껴진다. &lt;del&gt;그리고 냄새도 덜 난다.&lt;&#x2F;del&gt;&lt;&#x2F;p&gt;
&lt;h2 id=&quot;anjeongjeogeuro-paeseureul-juneun-bangbeob&quot;&gt;안정적으로 패스를 주는 방법&lt;&#x2F;h2&gt;
&lt;p&gt;평소 패스를 연습할 때, 항상 목표 지점을 정확히 지정해서 그곳을 맞추는 연습을 해야 한다. 월볼이면 벽에, 패스면 동료의 스틱 헤드에 꽂아주도록 연습한다. 또한 계속 움직이면서 패스 연습을 해야 한다. 움직이는 동료를 향해 어떻게 패스를 잘 줄 수 있는지는, 실제로 움직이며 패스를 주고받아야 알 수 있다. 목표는 높게 가져야 한다. 클리어 상황에서 달리는 동료의 스틱에 공을 넣어주겠다는 각오를 하라.&lt;&#x2F;p&gt;
&lt;p&gt;또한, 패스는 달리는 동료를 향해야 한다. 따라서, 동료가 향하고 있는 방향으로 더 멀리 던져줘야 한다. 지금 보이는 동료를 향해 던지면, 동료는 다시 달리던 것을 멈추고 되돌아가야 한다. 동료가 달리는 속도를 보며, 동료가 갈 곳을 향해 던지도록 한다. 기본적으로 동료가 되돌아가도록 하는 것보다는, 차라리 못따라잡는 편이 낫다. 달리던 속도를 더 올려서 달려가 그라운드볼이라도 시도할 수 있기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;또 한가지, 모두가 궁금해할 질문에 대한 답을 하겠다. 왜 우린 유독 클리어를 할 때 실수가 많을까? 이유는 스틱을 더 빠르게 휘두르려 하기 때문이다. 빠르게 패스를 주는 것은 스틱을 빠르게 휘두르는 것이 아니다. 기회를 빠르게 포착하고 던지고자 판단하는 것을 빠르게 하라는 뜻한다. 이것이 안되기 때문에, 남은 시간 안에 패스를 빠르게 해야만 하는 상황이 오는 것이다. 따라서, 기회를 포착하고 판단하는 시간을 단축해야 한다. 이에 더해, 빠르게 패스를 주기 위한 1,2의 과정 중, 1번의 경우는 더 빠르게 해볼 수 있다. 1에 걸리는 시간을 단축하기 위해, 크레이들 연습을 해서 몸에 익힌 후, 판단도 빠르게 한다면, 클리어 패스에 걸리는 시간은 충분히 단축될 것이다. 이로부터 여유를 가지고 스틱을 평소처럼 휘두르면 된다. 그리고 근본적으로, 패스와 크레이들과 같은 기본기를 충분히 반복숙달한다면, 패스와 크레이들은 어떤 절차를 따르는 것을 머리 속으로 생각할 필요 없이, 몸에서 알아서 나올 것이다. 단지 “저기로 던져야지” 하는 생각만 해도 몸이 알아서 움직일 정도로 연습을 많이 해야 한다.&lt;&#x2F;p&gt;
&lt;p&gt;그렇다면, 기회를 포착하고 판단하는 일은 어떻게 빠르게 할 수 있을 것인가? 답은 경험이다. 그리고 가장 안전하고 부담없는 장은 팀 훈련이다. 클리어 전술 훈련도 하지만, 실전과 같은 상황에서 클리어를 할 기회가 종종 있다. 이 때, 이 훈련에 집중하기 위해, 기본적인 패스캐치, 크레이들 실력을 날카롭게 가다듬고 훈련에 매진하라. 실제 경기에 가서도, 경험들이 계속 쌓이기 때문에, 갈수록 이 부분은 빨라질 것이다. 초조해할 필요 없이, 매 경험을 즐기고, 경기나 훈련이 끝나면 그날의 훈련 내용을 정리하며 기억에 남겨라.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;gihoereul-paaghaneun-sunseo&quot;&gt;기회를 파악하는 순서&lt;&#x2F;h2&gt;
&lt;p&gt;1️⃣   2️⃣   3️⃣&lt;&#x2F;p&gt;
&lt;p&gt;4️⃣   ❌   5️⃣&lt;&#x2F;p&gt;
&lt;p&gt;4️⃣   🔻   5️⃣&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;미드필더들이 있는 곳(앞쪽 멀리)을 왼쪽에서 오른쪽, 혹은 오른쪽에서 왼쪽으로 빠르게 보면서 파악한 후, 좋은 기회가 있다면 패스한다.&lt;&#x2F;li&gt;
&lt;li&gt;줄 곳이 없다면 가까운 양 옆의 수비수들을 빠르게 보며 기회가 있는지 확인하고, 기회가 있다면 패스한다.&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;blockquote&gt;
&lt;p&gt;💡 여기서, X표시를 한 지점으로는 패스하지 않도록 한다. 실패하게 되면 바로 상대편에게 득점 찬스를 내주게 된다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;ol start=&quot;3&quot;&gt;
&lt;li&gt;골대 뒤로 돌아가서 다시 1,2를 진행한다.&lt;&#x2F;li&gt;
&lt;li&gt;골서클에서 더이상 있을 수 없는 경우, 골서클에서 상대팀 공격수가 가장 적은 방향으로 나와서 1,2를 반복하면서, 수비수들의 최후방에서 발맞추며 앞으로 전진한다.&lt;&#x2F;li&gt;
&lt;li&gt;상대 선수 중 누군가가 나에게 다가온다면, 분명 어딘가 기회가 있다는 신호이다. 빠르게 다시 주변을 살피고, 기회가 있다면 패스한다.&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;p&gt;5번에서 패스를 할 수 있는 상황이 오지 않는 경우, 자신이 있는지 없는지에 따라 다음 행동을 결정할 수 있다. 경기는 그 때의 상황에서 가장 최선의 선택지를 고르는 것의 연속이 되어야 한다. 답을 정해 두고 그것이 아니면 안된다는 배수진 전략은 위험한 발상이다. 팀 분위기를 흐리고, 갈등을 일으키고, 패배를 불러올 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;먼저, 1대 1 마킹을 감당할 자신이 있다면 직접 따돌리면서 주변에서 기회를 찾고 패스를 시도한다. 이것이 우리가 원하는 시나리오이기도 하다. 골서클 근처라면, 상대편 마킹을 골서클을 활용해서 떼어낼 수도 있다. 골서클 안으로 공을 다시 넣은 후 들어가서 다시 5초를 확보하는 방법이다. 골이 들어가거나 가로채지지 않도록 유의한다.&lt;&#x2F;p&gt;
&lt;p&gt;1대 1 마킹을 감당할 자신이 영 없다면, 우리 팀에게 유리한 필드를 향해 아주 멀리 던져서, 미드필더나 공격수에게 도움을 요청하라. 성공하면 감사하고, 실패하더라도 수비수가 쉴 시간을 조금이라도 더 벌 수 있다. 하지만, 이것이 유일한 전략이 되면 안된다. 우린 1대 1 마킹을 이겨낼 수 있는 골리가 될 것이다. 조금만 기다려 달라.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 6) 어디에 위치하는가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-06/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-06/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-06/">&lt;p&gt;골리는 어디에 서서 세이브를 해야 할까? 이것을 포지셔닝이라 한다. 포지셔닝은 세이브의 반을 차지하는 아주 중요한 요소이다. 그럼에도 불구하고 클리어보다도 늦게 배치한 이유는, 골리를 당장 시작하기 위해 필요한 핵심을 앞에 배치하기 위함이었다. 이제부터 세이브를 더 잘하기 위해 어떻게 포지셔닝을 하는지 알아보자.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;naneun-eodie-issneunga&quot;&gt;나는 어디에 있는가&lt;&#x2F;h2&gt;
&lt;p&gt;포지셔닝을 하기에 앞서, 본인의 위치가 어디인지 실시간으로 파악할 수 있어야 한다. 골리는 보통 특정 범위 이내로 움직인다. 따라서 골대를 스틱으로 툭툭 치면서 본인의 위치를 파악하는 연습을 해야 한다. 당장 모르겠더라도 습관적으로 쳐라. 그러다 보면 익숙해지며 스틱으로 골대만 치고도 본인이 어디에 있는지 알 수 있게 될 것이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;golriga-gajang-keoboineun-wici&quot;&gt;골리가 가장 커보이는 위치&lt;&#x2F;h2&gt;
&lt;p&gt;포지셔닝의 기본은, 골리 자신이 가장 커보이는 위치에 가있는 것이다. 그렇게 하기 위해서는 공격수 입장에서 골리가 언제 가장 커보이는지를 알 필요가 있다. 이 부분에 대해서는 뒤에서 설명하겠다. 좀 더 쉬운 방법을 먼저 소개하겠다. 공을 몸이 정면으로 바라보게 항상 서는 것이다. 처음엔 후술할 반원 위에서 시작해 보고, 조금씩 앞뒤로 거리를 조절해 보며 가장 잘 막을 수 있는 위치를 찾아보도록 한다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;banweon&quot;&gt;반원&lt;&#x2F;h2&gt;
&lt;p&gt;골리들이 골대 밑 골라인에 딱 서있지 않고 약간 앞으로 나와 있는 모습을 볼 수 있을 것이다. 그 이유는, 좀 더 넓은 면적을 몸으로 가리기 위함이다. 그들은 그 앞에서 반원을 그리며 공격수에게 가장 커보이는 위치를 사수한다. 반원의 크기를 어떻게 해야 하는지는 어렵지 않다. 골대의 양 끝을 지름으로 하는 반원을 그리면 된다. 그리고 가장 중요한 것. 본인에게 맞는 반원의 크기는 스스로 찾아야 한다. 많은 선수를 상대해 보면서, 어느 위치가 본인에게 유리한지 찾아가길 바란다. 공격수 입장에서 다른 사람을 앞에 세워두고 골대를 보며 좋은 위치를 머리로 이해하는 것도 좋다.&lt;&#x2F;p&gt;
&lt;p&gt;반원을 그렸다면, 그중 어느 위치에 서야 할까? 자신의 몸이 공을 든 공격수 입장에서 골대 밖으로 튀어나가서 낭비되는 부분이 없는 위치이다. 이렇게 설명하면 어려울 것이다. 당장 해볼 수 있는 것을 소개하자면, 골라인 중심에서 상대편 공격수 사이에 선을 그어서 그 선 위에 서는 것이 기본이다. 이것이 익숙해지면 거기서 약간의 유연성을 가지고 이런저런 것들을 시도해볼 수 있다. 그것은 나중에 설명하겠다.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;img src=&quot;https:&#x2F;&#x2F;laxgoalierat.com&#x2F;wp-content&#x2F;uploads&#x2F;2016&#x2F;11&#x2F;Traditional-Goalie-Arc-300x294.png&quot; alt=&quot;&quot; &#x2F;&gt;&lt;&#x2F;p&gt;
&lt;p&gt;출처: https:&#x2F;&#x2F;laxgoalierat.com&#x2F;the-basics-of-making-a-save&#x2F;&lt;&#x2F;p&gt;
&lt;h2 id=&quot;seuteb&quot;&gt;스텝&lt;&#x2F;h2&gt;
&lt;p&gt;경기 중에 포지셔닝을 해야 하는 위치는 계속 변화한다. 따라서 골리도 계속 움직여야 한다. 그렇다면 어떻게 움직여야 할까? 이렇게 골서클 안에서 움직이는 것을 스텝이라 한다. 스텝에는 두 가지 종류가 있다. 스몰스텝과 빅스텝이다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;seumol-seuteb&quot;&gt;스몰 스텝&lt;&#x2F;h3&gt;
&lt;p&gt;말 그대로 조금 움직일 때를 뜻한다. 공을 가진 공격수의 이동에 따라, 포지셔닝을 고쳐잡기 위해 이동할 때 사용한다. 스몰 스텝은 또다시 두 가지 방법으로 나뉜다. 잔발을 치듯 계속 움직이며 실시간으로 포지셔닝하는 방법과, 5개 지점을 정해 두고 공격수가 일정 범위 이상 벗어날 때만 움직이는 방법이 있다. 각 방법은 장단점이 각각 존재한다. 따라서 본인에게 맞는 것을 이용하면 된다.&lt;&#x2F;p&gt;
&lt;p&gt;잔발을 치는 방법은, 실시간으로 계속 포지셔닝을 수정하며 완벽을 가하는 방법이다. 따라서 연습량이 충분히 받쳐준다면 포지셔닝을 완벽하게 할 수 있다. 또한 잔발을 치고 있기 때문에 공에 반응할 때 속도 또한 좋다. 이 방법은 조유리 선수가 사용했다.&lt;&#x2F;p&gt;
&lt;p&gt;5개 지점을 정해두는 방법은, 위의 그림자료에서 지정한 5개 지점들로 이동하는 방법이다. 공격수가 자신의 두 무릎 사이에서 벗어날 때 다음 지점으로 이동한다. 이 방법은 잔발을 치는 방법에 비해 이동이 덜하다. 따라서 공에 대한 집중력을 유지하는데 더 유리하다. 또한 상대적으로 연습량이 덜해도, 지점 자체가 적기 때문에 포지셔닝을 꽤 괜찮게 진행할 수 있다. 체력적으로도 부담이 덜하고, 그렇기 때문에 더더욱 집중력을 유지하는데 유리하다. 이 방법은 전통적인 방법이기도 하며, Jake선수가 사용하며 클리닉에서 소개해 줬다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;big-seuteb&quot;&gt;빅 스텝&lt;&#x2F;h3&gt;
&lt;p&gt;빅 스텝은, 패스가 일어나는 등의 이유로 한 번에 많은 거리를 움직이는 것을 뜻한다. 골리에게는 리스크가 큰 동작이다. 거리가 긴 만큼 포지셔닝에 오차가 발생할 가능성이 크고, 공격수 또한 보통 가까이서 빠르게 움직이고 있는데다, 당장이라도 슛을 쏠 수 있기 때문이다. 따라서, 빅 스텝을 밟으면서도 각종 리스크를 줄이는 방법을 소개하겠다.&lt;&#x2F;p&gt;
&lt;p&gt;보통의 빅 스텝에서 무너지기 쉬운 것은 포지셔닝이다. 첫 발에서 목적지를 향해 몸을 던져버리는 순간, 더이상 제어할 수 없기 때문이다. 따라서 두 발에 걸쳐서 포지셔닝을 진행한다. 먼저, 골라인의 중앙을 뒷발로 밟고 슈터를 정면으로 바라본다. 이 시점에서 골리는 슈터를 향해 좌우 방향 포지셔닝을 완료하게 된다. 다음은 그 슈터를 향해 한 발을 내딛는다. 이렇게 되면 슈터가 슛을 하더라도, 포지셔닝이 매우 빨리 완료된 상태이기 때문에 세이브를 하는데 지장이 없게 된다. 게다가 발을 내딛고 있기 때문에 공을 향해 잡아먹는 동작 또한 자연스럽게 나오며, 골라인 중앙을 밟은 상태에서 다음 발을 내딛을 지점을 변경해서 공격수의 위치 변화에 따라 포지셔닝 지점을 중간에 수정할 수도 있다. 모든 방향에 대비할 수 있는 위치를 선점했기 때문에 방향을 바꿔도 공간에 손해를 보지 않는다.&lt;&#x2F;p&gt;
&lt;p&gt;만약 골라인이 너무 멀다면, 한 가지만 기억하라. 상대편 공격수를 정면으로 바라보는 것을 가장 먼저 하고 그 다음 스텝을 밟도록 한다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 7) 어떻게 세이브를 잘하는가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-07/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-07/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-07/">&lt;p&gt;세이브 기본은 잘 알았다. 그렇다면, 어떻게 세이브를 잘할 수 있을까? 이제부터 약간 심화된 내용들을 다뤄 보겠다. 만약, 앞부분을 건너뛰고 이걸 읽고 있다면 이해하기도 힘들고, 이상한 습관이 잡히기 쉬우니, 기본기부터 읽고 탄탄하게 갈고닦기 바란다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;pojisyeoning-simhwa&quot;&gt;포지셔닝 심화&lt;&#x2F;h2&gt;
&lt;p&gt;공격수의 입장에서, 내가 어떻게 보일지에 대한 것은, 수학적으로 표현이 가능하다. 이를 이용해서 그림을 그려 보았다.&lt;&#x2F;p&gt;
&lt;img alt=&quot;desmos-graph.png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-09-26_lacrosse-goalie-07&#x2F;desmos-graph.png&quot;&gt;
&lt;p&gt;키 약 170cm의 슈터와, 키 160cm의 골리가 맞붙는 상황이다. 골리는 반원 위에 서있다. 슈터는 골서클로부터 1m 떨어진 지점까지 다가와 샷을 시도하고 있다. 슈터는 정자세로 위에서 아래로 스윙하고 있으며, 슈터의 시야에서 보이는 공간은 빨간색, 스틱 헤드에서 노려볼 수 있는 공간은 보라색으로 칠했다. 이제, 골리를 앞으로 이동시켜보자. 슈터는 빨간색 선, 슈터의 스틱은 보라색 선, 골리는 파란색 선이다.&lt;&#x2F;p&gt;
&lt;img alt=&quot;desmos-graph(1).png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-09-26_lacrosse-goalie-07&#x2F;desmos-graph(1).png&quot;&gt;
&lt;p&gt;이상하다. 앞으로 나왔다면 시야를 더 가렸어야 했는데 말이다. 오히려 슈팅을 쏠 수 있는 공간만 더 늘어났다. 여기엔 함정이 숨어있다. 골리의 키는 160cm. 슈터의 키는 170cm. 그리고 눈의 높이를 고려해서 슈터의 눈이 지면으로부터 160cm 위라고 가정했기 때문에 저런 그림이 나온 것이다. 그럼, 슈터의 키도 공평하게 160cm로 줄여보자.&lt;&#x2F;p&gt;
&lt;img alt=&quot;desmos-graph(2).png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-09-26_lacrosse-goalie-07&#x2F;desmos-graph(2).png&quot;&gt;
&lt;p&gt;슈터의 시야가 효과적으로 차단된 것을 볼 수 있다. 물론 슛을 쏠 수 있는 공간은 늘어났다. 하지만, 여기서 고려되지 않은 것이 있다. 골리 또한 스틱을 들고 있다는 것이다. 따라서 좀 더 가까운 곳에서 슈팅이 올 수 있는 위치의 범위를 최소화한 채 슛을 잡아먹기 좋다. 그렇다면, 반대로 슈터의 키가 더 컸다면 어땠을까?&lt;&#x2F;p&gt;
&lt;img alt=&quot;desmos-graph(3).png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-09-26_lacrosse-goalie-07&#x2F;desmos-graph(3).png&quot;&gt;
&lt;p&gt;슈터의 키를 180cm라 가정, 눈높이를 170cm로 세팅했다. 그랬더니 오히려 시야가 더 넓어졌다. 따라서, 골리는 자신과 슈터의 키를 비교해서, 가까이 가는 것이 유리한지, 기존 반원 위를 지키는 것이 유리한지를 판단할 수 있어야 한다.&lt;&#x2F;p&gt;
&lt;p&gt;지금까지는 위아래 방향에 대한 도표만 살펴 보았다. 그럼 양옆 방향은 어떨까? 어깨너비 50cm인 골리가 있다 가정해 보겠다.&lt;&#x2F;p&gt;
&lt;img alt=&quot;desmos-graph(4).png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-09-26_lacrosse-goalie-07&#x2F;desmos-graph(4).png&quot;&gt;
&lt;p&gt;이전과 마찬가지로 슈터가 볼 수 있는 공간은 빨간색으로, 스틱으로 쏠 수 있는 공간은 보라색으로 표시했다. 슈터는 위에서 아래로 쏘고 있다. 이제부터 골리를 앞으로 보내보자.&lt;&#x2F;p&gt;
&lt;img alt=&quot;desmos-graph(5).png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-09-26_lacrosse-goalie-07&#x2F;desmos-graph(5).png&quot;&gt;
&lt;p&gt;슈터의 시야와 던질 수 있는 각도 모두 효과적으로 줄어들었다. 그렇다면 여기서, 슈터가 사이드로 슛을 하면 어떻게 될까?&lt;&#x2F;p&gt;
&lt;img alt=&quot;desmos-graph(7).png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-09-26_lacrosse-goalie-07&#x2F;desmos-graph(7).png&quot;&gt;
&lt;p&gt;슈터의 시야를 더 가리는건 여전히 성공이지만, 슈팅 시 헤드에서 골대를 향한 각도 범위는 오히려 넓어졌다. 그렇다면, 다시 뒤로 돌아가야 할까?&lt;&#x2F;p&gt;
&lt;img alt=&quot;desmos-graph(9).png&quot; src=&quot;&#x2F;assets&#x2F;img&#x2F;2024-09-26_lacrosse-goalie-07&#x2F;desmos-graph(9).png&quot;&gt;
&lt;p&gt;골리를 왼쪽으로 20cm 정도만 보내봤다. 슈터의 눈에는 골리의 오른쪽 공간이 보이지만, 실제로 슛을 해서 그 위치를 맞추려 하니 골리가 딱 버티고 서있는 형국이 되었다. 슈터는 시야엔 들어오지 않지만 대충 있을 것 같은 골대를 향해 슛을 하거나, 슛을 무르고 다음을 노리게 될 것이다. 이 때, 골리에게 유리한 점이 한 가지 더 있다. 경우의 수가 줄어든다는 것이다. 슈터가 제아무리 오른쪽을 맞추려 해 봤자, 골리의 몸을 맞추게 된다. 따라서, 골리는 자신보다 오른쪽으로는 슛이 갈 수 없고, 가더라도 골대 밖으로 나간다는 것을 기억하고 중간과 왼쪽만 막을 준비를 하면 된다. 이처럼 경우의 수를 자신에게 유리하게 가져가게 하기 위해 취하는 행동이나, 상대의 수를 읽는 것들을 수싸움이라 한다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;sussaum&quot;&gt;수싸움&lt;&#x2F;h2&gt;
&lt;h3 id=&quot;suilggi-gibon&quot;&gt;수읽기 기본&lt;&#x2F;h3&gt;
&lt;p&gt;수싸움을 하기에 앞서, 수를 읽는 법을 알아야 한다. 수를 읽는 것은 수많은 경기를 통해 경험을 쌓으며 얻을 수 있다. 하지만 우리는 그걸 기다리기보다, 공격적으로 이해해보도록 하자.&lt;&#x2F;p&gt;
&lt;h4 id=&quot;geungeori&quot;&gt;근거리&lt;&#x2F;h4&gt;
&lt;p&gt;포지셔닝 심화를 제대로 이해했다면, 슈터의 키에 따라 차이가 있을 것이라는 추측을 할 수 있었을 것이다. 가까운 거리에서 슛을 하는 경우, 골리와 슈터 사이의 거리가 상대적으로 가깝다. 슈터의 키가 크면 상대적으로 골리의 머리 위 공간이 잘 보인다. 따라서 습관적으로 위로 쏘는 경향이 있다. 반대로, 슈터가 골리보다 작은 경우, 골리의 스틱이 있는 윗 부분보다는 아래쪽을 노리는 경향이 있다. 몸통이 있는 중간이나 위쪽에 비해 다리쪽은 빈 공간이 많기 때문이다.&lt;&#x2F;p&gt;
&lt;h4 id=&quot;jungjanggeori&quot;&gt;중장거리&lt;&#x2F;h4&gt;
&lt;p&gt;중장거리의 경우, 키에 따른 차이가 줄어든다. 이 때 슈터가 고르는 선택지는 보통 아래쪽이다. 아래쪽의 경우, 조금 벗어나더라도 지면에 튕겨서 다시 골대를 향하는 특성이 있다. 따라서 거리가 멀어서 정확도에 더 신경을 써야 하는 상황에서 아주 좋다. 또한 골리들도 아래쪽을 보통 힘들어하니 일석이조이다. 하지만, 이정도 거리라면, 좀 더 시간이 많으므로 반응속도로 승부를 보는걸 추천한다. 수를 읽기보다는 수싸움을 걸어보는걸 추천한다. 실책을 유도하기도 좋다. 수싸움 방법은 후술하겠다.&lt;&#x2F;p&gt;
&lt;h4 id=&quot;syuteoe-ddareun-cai&quot;&gt;슈터에 따른 차이&lt;&#x2F;h4&gt;
&lt;p&gt;방금 언급했듯이, 아래쪽 슈팅은 좀 벗어나더라도 바닥에 튕겨서 다시 골대를 향한다. 따라서, 수준이 낮은 슈터는 아래쪽으로 대강 쏘는 경향이 두드러진다. 반대로 수준이 높은 슈터는 쏠 곳을 보고 맞춘다는 느낌이 강하다. 라크로스 선진국 골리들의 하체 보호대가 빈약한 이유이기도 한 것 같다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;sussaum-gisul&quot;&gt;수싸움 기술&lt;&#x2F;h3&gt;
&lt;p&gt;수싸움을 걸 때는, 티가 나지 않는게 좋다. 슈터를 교묘하게 컨트롤하는 것이다. 물론 프리샷 상황에서 수싸움을 티나게 걸어 심리적으로 동요하게 해서 실책을 유도할 수도 있다. 티가 나든, 티가 나지 않든, 자신에게 유리한 사이드, 혹은 슈터가 슛을 쏘도록 유도할 사이드를 &lt;strong&gt;“조금”&lt;&#x2F;strong&gt; 더 내주는 방법으로 진행한다. 너무 많이 가면 수싸움을 한다는 것이 티가 날 뿐만 아니라, 어디로 올 지 알아도 너무 멀어서 슛을 따라가지 못하게 될 수 있다. 또한, 주의해야 할 것들이 있다. “무조건 이쪽으로 가야지!” 하는 생각을 하게 되면 슈터의 눈에 다 보인다는 것이다. 따라서 유도하는쪽 사이드로 슛이 올 가능성이 높다는 것을 인지한 채, 평소처럼 세이브를 하도록 한다. 또, 슛이 와서 움직일 때는 확신을 가져야 한다. 중간에 망설이지 않는다. 이전에 언급했듯이, 중간에 무르는 것이 아닌, 빠르게 두 번 시도하는 것이다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;eonje-sayonghaneunga&quot;&gt;언제 사용하는가&lt;&#x2F;h3&gt;
&lt;p&gt;수읽기는 항상 진행할 수 있다. 수읽기가 익숙해지면,  상대를 보고 몸이 알아서 은근하게 적절한 예측을 하고 대비하게 될 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;수싸움의 경우, 속공에 당해 완전히 뚫려서 슈퍼세이브를 해야 하거나 프리샷을 하는 등 슈터와 골리의 1:1 대결이 되는 상황에 사용할 수 있다. 평소에는 수비수와 함께 빈틈을 없애는 방식의 기본 포지셔닝을 하도록 한다. 하나를 더 막는 것보다, 하나가 더 못오게 하는 것이 좋다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 8) 어떻게 클리어를 잘하는가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-08/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-08/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-08/">&lt;h2 id=&quot;maindeuses&quot;&gt;마인드셋&lt;&#x2F;h2&gt;
&lt;p&gt;클리어를 하기에 앞서, 클리어에 임하는 마음가짐을 가다듬을 필요가 있다. 한국은 아직 언더독이다. 클리어를 할 때, 난해한 상황이 굉장히 많다. 많이 개선되었긴 하지만 여전히 환경은 열악하고, 부족한 훈련 시간으로 인해 클리어 전술을 익힐 시간 또한 절대적으로 부족하다. 따라서, 골리는 조금 더 참을성을 가지고, 긍정적인 마인드셋으로 임할 필요가 있다.&lt;&#x2F;p&gt;
&lt;p&gt;먼저, 클리어는 기본적으로 다같이 풀어나가야 한다. 혼자 잘한다고 되는 것이 아니다. 하지만, 누군가의 탓을 하는 것도 금물이다. 경기 상황에서는 앞으로의 선택지를 고르는 것에 집중하라. 문제의 원인을 파악하고 개선하는 것은 경기나 세트가 종료되고 여유가 있을 때 하는 것이다. 그렇다면 그 이유는 무엇일까? 쉽게 말해, 그럴 시간이 아깝기 때문이다. 경기 중에 1분 1초는 아주 소중하다. 원인파악을 하는 시간 동안, 앞으로 어떻게 할 지에 대해 판단할 시간은 줄어든다. 또한, 원인을 알아내 봤자, 하면 안되는 것만 알아갈 뿐이다. 실수한 사람이 자신감을 잃게 되는 것도 덤이다. 경기에 전혀 도움이 되지 않는다. 원인 파악은 해결책을 함께 마련할 수 있는 여유있는 상황에 하는 것이고, 그건 필드 위가 아니라 벤치에서 할 일이다. 그렇기 때문에 타임아웃이 존재하는 것이다. 팀원들이 클리어를 풀어나가지 못해 기회가 생기지 않는다면, 직접 돌파해서 기회를 만들어낼 생각을 하라. 물론, 이렇게 하기 위해 스틱스킬과 돌파 능력과 같은 필드 플레이어로서의 능력도 함께 갈고닦아야 한다는 점을 기억하라. 공짜는 없다.&lt;&#x2F;p&gt;
&lt;p&gt;기억하라. 언젠간 이 글을 읽고 있는 독자들이, 차세대를 리드하는 선수가 되어 있을 것이다. 상황이 벌어지고 나서 피드백하는 사람이 되지 않도록 당부하는 바이다. 플레이 중에 팀원들에게 힌트와 가이드, 그리고 실제적인 도움을 제공하는 선수가 되어라. 컨트롤타워를 무시하고 선수들끼리 갖가지 피드백을 주고받으며 스스로 갈등과 패배를 선택한 과거의 역사를 반복하지 않길 바란다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;keulrieo-simhwa&quot;&gt;클리어 심화&lt;&#x2F;h2&gt;
&lt;h3 id=&quot;keomyunikeisyeon&quot;&gt;커뮤니케이션&lt;&#x2F;h3&gt;
&lt;p&gt;팀원들에게 본인이 받을 수 있을 때 크게 어필해 달라고 요청해야 한다. 팀원들은 말을 안해도 척척 손발이 맞는 선수들도 있지만, 그렇지 않은 선수들도 있다. 모두 한 팀이다. 모두가 함께할 수 있는 방법을 선택하라. “말 안해도 딱딱 알아야지!”라는 생각은 팀에 독이 될 뿐이다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;golriyi-yeoghal-beomwi&quot;&gt;골리의 역할 범위&lt;&#x2F;h3&gt;
&lt;p&gt;클리어에서 골리의 역할은 패스를 주는 것이 끝이 아니다. 골서클 밖으로 나와서 또 한 명의 필드 플레이어가 되어 맨업 상황을 제공하고, 여유있게 클리어하라. 그렇다면, 어떻게 필드에서 움직여야 할까?&lt;&#x2F;p&gt;
&lt;p&gt;골리는 항상 모든 선수의 최후방에 있어야 한다는 원칙이 있다. 모든 선수가 골리의 시선 안에 있어야 한다. 그렇지 않으면 보이지 않는 상대편 선수에 의해 득점 찬스를 허용할 가능성이 커진다. 따라서 가능한 최후방에 위치해야 한다. 최후방에서 우리팀 선수들 사이의 틈을 메워주고, 함께 따라간다. 맨업 플래이를 통해 상대팀을 교란시키고, 진행이 막힐 때는 공략하는 사이드를 전환해줄 수 있는 가교 역할을 해줘야 한다. 예를 들어, 오른쪽을 공략하려 했지만 상대팀이 그쪽을 단단히 틀어막고 있을 때, 골리에게 패스하면 다시 왼쪽 사이드를 공략할 수 있도록 패스해줄 수 있다.&lt;&#x2F;p&gt;
&lt;p&gt;골리가 필드로 나왔다면, 맨업 상황이다. 만약 골리에게 상대팀 선수가 다가온다면, 누군가는 비어있거나, 상대팀 한 명이 두 명의 우리팀 선수를 마크하고 있는 상황인 것이다. 우리팀 선수가 기회를 만들어내고 적극적인 어필을 해주는 상황이 베스트이다. 만약 그렇지 않다면, 상대팀을 따돌려 보라. 그렇게 되면 우리팀은 두 명이 더 많은 것과 같은 상황이 된다. 물론 클리어 기본을 설명할 때 언급했듯이, 자신이 없다면, 멀리 던지는 것도 선택지에 함께 가지고 있어야 한다. 다시 한 번 말하지만, 한가지 답만 있는 것이 아니다. 그 때 그 때 최선의 선택지를 고르면 된다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;keulrieo-silpae&quot;&gt;클리어 실패&lt;&#x2F;h3&gt;
&lt;p&gt;클리어를 실패했다면, 다시 수비를 해야 한다. 그리고 골리가 필드에서 함께 플레이하고 있던 상황이라면, 골리는 다시 골대로 돌아가야 한다. 여기에도 디테일이 있다. 상대팀 선수는, 골리가 돌아가기 전에 어떻게든 슛을 쏘고 싶어 한다. 골리가 돌아가는 중에 무리한 슈팅을 할 수 있다. 따라서, 돌아가는 중이라도 항상 공을 보면서 뛰어야 한다. 필드에서라도 세이브를 할 수 있어야 한다. 앞으로 전력질주하기보다는 약간은 옆으로 뛰면서 최대한의 속도를 내되, 공을 계속 보고 있는 것이다. 그리고, 팀원들에게 도움을 요청하라. 상대팀을 최대한 저지해 달라고 부탁해야 한다. “도와줘!”&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 9) 어떻게 수비를 돕는가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-09/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-09/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-09/">&lt;p&gt;골리의 제1임무는 세이브이다. 하지만, 세이브를 해야 하는 상황은 사실상 최악의 상황이라 볼 수 있다. 따라서, 그 전에 수비에 가담해서 슈팅을 하나라도 줄이는 것이 현명한 선택이다. 그렇다면 골리로서 수비에게 어떻게 도움을 줄 수 있을까?&lt;&#x2F;p&gt;
&lt;h2 id=&quot;kol&quot;&gt;콜&lt;&#x2F;h2&gt;
&lt;p&gt;콜은 가장 적은 에너지로 효과적으로 수비에 가담할 수 있는 방법이다. 그렇다면 어디서부터 어디까지 콜을 해줘야 할까? 기본적으로는 수비수와 비슷하다. 하지만 골리는 가장 뒤에서 필드를 전체적으로 볼 수 있는 유일한 선수이다. 수비수들이 놓치고 있는 것들을 위주로 콜을 해주면, 많은 도움이 될 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;골리는 기본적으로 공에 집중하고 있다. 따라서 다른 것들은 주변시야를 통해 살피게 된다. 따라서 전체적인 것들을 보고 콜을 할 때 가장 적당하다. 예를 들어, 우리팀 수비수들이 만든 진영에서 불필요하게 멀리 나가거나 가까이 있는 선수에게 진영으로 돌아가도록 주문할 수 있다. 또한 시프트를 컨트롤할 수도 있다. 시프트는, 공격수가 공략했을 때 위험한 사이드로 향하지 않게 하기 위해 수비수들이 한 쪽으로 약간 치우쳐서 유리한 포지션을 선점하는 것을 뜻한다. 공격수가 오른손잡이냐 왼손잡이냐에 따라 한 쪽 사이드로 몰아넣고, 유리한 포지션을 가져간다. “오른쪽으로 몰아!”, “왼쪽으로 몰아!”, “밀어!”, “땡겨!”와 같이 골리는 수비수들에게 시프트를 주문할 수 있다.&lt;&#x2F;p&gt;
&lt;p&gt;당장 슈팅이 올 상황이 아니라면, 좀 더 많은 것들을 수비수들과 함께 콜해줄 수 있다. 픽(공격수가 수비수 옆에 벽을 쳐서 진로를 방해하는 방법)이 그 대표적인 예시이다. 또한 우리팀 수비수들이 놓쳐서 혼자 놀고 있는 공격수가 있다는걸 알았다면, 이것도 알려야 한다. 처음엔 어느 쪽이 비었음을 외치는 것으로 시작한다. 실력이 늘고 여유가 생긴다면, 우리팀 수비수를 지목해서 그 공격수를 막아달라고 콜을 해주면 좋다. 비슷한 원리로, 속공에 당하고 있을 때, 달려오고 있는 수비수에게 어느 쪽으로 가서 어떤 공격수를 막으라고 가이드할 수도 있다.&lt;&#x2F;p&gt;
&lt;p&gt;그리고 경력이 쌓이다 보면, 공격수의 바디랭귀지를 읽을 수 있게 된다. 곧 다지나 돌파, 슈팅을 한다는 것이 눈에 보이게 된다. 이 정보 또한 수비수들에게 제공하면 좋다. 난 “지금!”을 외친다.&lt;&#x2F;p&gt;
&lt;p&gt;마지막으로, 콜이 틀렸을 때 주눅들지 마라. 모든 행동은 리스크를 포함한다. 그저 “쏘리!” 하고 시원하게 털고 다음을 준비하라. 콜을 해주는게 어디인가. 방금까지 많은 것들을 요구했지만 기억하라. 골리의 제1임무는 세이브이다. 콜이 세이브를 방해한다면 과감하게 포기할 줄도 알아야 한다. 각자 수준에 맞게 하나씩 정복해 나가도록 하라.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;jigjeob-gadam&quot;&gt;직접 가담&lt;&#x2F;h2&gt;
&lt;p&gt;위험한 공격수 중에, 골서클 바로 근처에 있는 선수가 종종 있다. 무서워하지 마라. 오히려 골리에게 유리한 상황이다. 그 선수는 공을 잡자마자 슈팅을 하고 싶어 한다. 또한 수비수들이 보통 이를 가만 두려 하지 않는다는 것을 알기 때문에 굉장히 긴장하고 있다. 패스를 받는 것에 더 집중하기 위해 골리에게서 눈을 떼는 경우가 많다. 이 공격수는 골리에게 먹잇감이다.&lt;&#x2F;p&gt;
&lt;p&gt;먼저, 그 공격수에게 다가가 스틱을 갖다대라. 골리 스틱은 굉장히 크다. 골리의 마크를 받는 공격수에게 패스하는 것은 꽤나 큰 부담이다. 상대팀은 패스를 하지 않고 다음 기회를 노릴 가능성이 크다. 물론 무리하게 패스를 하기도 한다. 그럼 실제로 패스가 일어나면 큰일일까? 아니다. 방금까진 호랑이 굴 앞에서 당장이라도 도망갈 준비가 되어 있던 먹잇감이었지만, 이 시점부터는 어두운 호랑이 굴 안으로 들어와 앞을 보지 못하고 있는 맛있는 먹잇감이 된 것이다. 다가가서 잡아먹어라.&lt;&#x2F;p&gt;
&lt;p&gt;먼저 골리에게 유리하게 패스가 온다면, 패스를 가로챌 수 있다. 패스를 가로채며 필드로 나가 돌파하면서 우리팀 미드필더나 공격수까지 닿도록 클리어를 진두지휘하라. 만약 가로채기 어려운 패스라면, 다음은 슛을 잡아먹으면 된다. 공격수가 스틱을 휘두를 그 위치에 내 스틱과 몸을 갖다대면 된다.&lt;&#x2F;p&gt;
&lt;p&gt;만약 골서클 근처에서 멋드러지게 점프를 했다면, 겁먹지 마라. 더더욱 맛있는 먹잇감이 된 것이다. 점프를 한 순간 공격수는 자신의 신체에 대한 제어를 잃는다. 공격수의 이동 방향은 바뀌지 않고, 공격수는 보통 급하게 슛을 쏜다. 그리고 보통 스틱을 휘두르는 방향은 일관적이고 기본에 충실하다. 급하기 때문에 습관대로 편한 자세로 쏘기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;만약 골서클 근처에 있던 공격수가 수준이 높아 훼이크를 하거나 슛을 무르고 다시 쏘거나, 슛을 쓰는 와중에서 방향을 바꿔 던지는 등 기상천외한 방법으로 골을 넣었다면 박수를 쳐줘라. 골리로서 그 이상을 하는 것은 어렵다. 공격수가 아주 잘한 것이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 10) 어떻게 스스로를 조종하는가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-10/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-10/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-10/">&lt;h2 id=&quot;simri&quot;&gt;심리&lt;&#x2F;h2&gt;
&lt;p&gt;스포츠에서 심리는, 팀과 선수들의 승패를 가르는 캐스팅보트 역할을 한다. 어느 정도 이상부터는 선수들의 신체적, 기술적 기량이 크게 차이나지 않는다. 거기서 승부를 가르는 것은 멘탈이다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;ginjang&quot;&gt;긴장&lt;&#x2F;h3&gt;
&lt;p&gt;사람마다, 종목마다, 포지션 마다 최적 긴장도가 존재한다. 예를 들어, 사격은 낮은 긴장도를 요구한다. 심박수가 낮은 선수가 유리하다. 반대로 아이스하키와 같은 종목은 높은 긴장도를 요구한다. 그럼 라크로스 골리의 최적 긴장도는 어디일까? 나도 모른다. 전체적인 대세만 있을 뿐, 사람마다 다르다. 라크로스 골리는 사격과 축구 사이 어느 지점에 있다고 생각하긴 하지만, 중요하진 않다. 각자 어느 상황에 가장 잘 됐는지 찾아야 한다. 여기서는, 긴장도를 조절하는 방법을 소개하도록 하겠다. 이 심리기술을 통해 스스로의 긴장도를 조절해보며 최적 지점을 찾도록 하라. 매일 훈련이나 경기가 끝나면 그날의 기분상태 등을 기록하고 정리하라. 이것도 연구의 일환이다. 본인에 대해 더 잘 알게 될 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;긴장도 낮추기&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;우린 보통은 긴장도를 낮출 것이 필요하다. 경기 상황은 당연히 긴장되는 상황이기 때문이다. 그럼 어떻게 긴장을 낮출 수 있을까? 호흡이 가장 효과가 좋다. 숨을 크게 들이마신 후, 코로 천천히 뱉으며, 머리속에 있는 모든 것을 함께 뱉어낸다고 생각한다. 이와 함께 머리 속을 비운다. 어깨에도 힘을 빼도록 한다. 만약 비염이 있어 숨을 코로 내쉬기 어렵다면 입으로 내쉬되, 작게 오므린 상태로 내쉬도록 한다.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;긴장도 높이기&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;나같은 경우, 나중에 되니 오히려 긴장도를 높여야 하는 케이스가 오기도 했다. 천성적으로 성격이 너무 느긋해서 주변에서 내가 뭔가를 하는걸 보며 답답해할 정도인 사람이기 때문이다. 물론 다른 사람들의 경우도, 나이가 들고 경험이 쌓이며 산전수전 다 겪다보면, 긴장도는 낮아질 것이다. 각설하고, 긴장도는 어떻게 높여야 할까? 주의하도록 한다. 특별한 생각을 하거나 해서 긴장도를 높이지 않는다. 보통 생각은 신체를 느리게 만든다. 생각이 아닌 행동으로 긴장도를 높인다. 크게 기합을 지르거나, 스스로 허벅지나 가슴을 치며 긴장도를 높일 수 있다. 골대 파이프를 스틱으로 칠 때 평소보다 더 경쾌하게 치는 방법도 있다. 방법은 여러 가지다. 자신만의 것을 찾아라.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;molib&quot;&gt;몰입&lt;&#x2F;h3&gt;
&lt;p&gt;긴장도를 이리저리 조절해보며 답을 찾다 보면 도착하는 종착지가 있다. 결국 가장 중요한 것은 몰입이라는 것이다. 방금까지 설명한 긴장도 조절 방법을 봤을 때, 긴장에 대한 이야기를 하기보다는 생각을 비우라는 이야기를 계속 하고 있어 이상함을 감지했을 것이다. 그 이유가 이것이다. 몰입을 하게 되면, 긴장도는 알아서 최적으로 맞춰진다. 그렇다면, 이런저런 생각이 꼬리에 꼬리를 물고 있다면 어떻게 여기서 벗어날 수 있을까? 기본적으로는 긴장도를 낮추는 방법을 사용한다. 하지만 이걸 그냥 하기엔 어려움이 따른다. 익숙하지 않기 때문이다. 따라서 처음엔 **“스위치”**라는 것을 시도해볼 수 있다.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;스위치&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;스위치는 스스로 특정 행동에 대해 약속을 하는 것을 뜻한다. 예를 들어, 난 헬멧의 바이저(앞쪽 케이지 위)를 꾹 누르면, 모든 생각을 중단하고 호흡을 통해 밖으로 배출하고 멍한 상태가 된다. 이후 긴장이 필요하면 몸을 때리고, 아니면 그냥 플래이한다. 이 글을 읽는 독자들도 각자 자신만의 스위치를 만들어 스스로를 제어할 수 있길 바란다. 한가지, 주의해야 할 것이 있다. 스위치는 경기나 상황이 잘 안풀릴 때, 혹은 플래이가 시작되기 전에 사용한다. 잘 하고 있는데 불필요하게 스위치를 의식하거나 남발하지 않도록 한다. 잘 하고 있다면 그냥 그 상태를 유지하라.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;strong&gt;신체의 언어로 쓰여진 컨트롤러&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;심리를 컨트롤하는 기술들을 활용하다 보면, 굳이 스위치를 사용하는 등의 기술을 사용하지 않아도 스스로의 감정 상태를 조절할 수 있다. 심리를 컨트롤하는 방법을 몸이 이해하게 된 것이다. 예를 들어 난 눈에 초점을 잠시 풀고 날숨을 느끼면서 뇌가 붕 뜨는 듯한 느낌을 만들어낸 후 공에 초첨을 맞추는 방법으로 아주 빠른 시간 내에 몰입 상태로 들어간다. 뇌가 붕 뜨다니, 도대체 무슨 소리인가? 굳이 설명해 보자면 마치 며칠 밤을 연달아 샌 후 구름에 떠다니는 듯한 이상한 느낌을 받는 것과 비슷한 느낌이다. 이해하기 어려운 것은 당연하다. 신체의 언어로 몸에 각인되었기 때문이다. 나도 이걸 설명하기 위해 이런 표현을 하는데 꽤나 애를 먹었다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;sincewayi-daehwabeob&quot;&gt;신체와의 대화법&lt;&#x2F;h2&gt;
&lt;p&gt;신체의 언어가 존재한다는 것에 대해 방금 알게 되었을 것이다. 만약 내가 이 신체의 언어를 이해하고 대화를 할 수 있다면, 몸은 아주 잘 따라줄 것이다. 그럼 신체의 언어는 어떤 문법으로 되어 있을까? 어떻게 신체에 주문을 넣어야 할까? 난 신체의 언어에 대해 다 알지는 못한다. 그냥 경험적으로 데이터가 쌓였을 분이다. 따라서, 언어적으로 신체에 어떻게 주문을 넣어야 하는지에 대한 것만 간략히 소개하겠다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;eoneojeog-jumun&quot;&gt;언어적 주문&lt;&#x2F;h3&gt;
&lt;p&gt;어떤 생각을 했을 때, 혹은 어떻게 피드백을 들었을 때 몸에 가장 빠르게 반영되는가에 대한 이야기를 해보자. 신체 또한 언급했듯이 나름의 언어 체계가 있고, 이에 맞춰 주문이 들어갈 때 제대로 알아듣고 수행한다. 언어적 주문은 기본적으로 **“해야하는 것”**을 **“가장 짧은 문장”**으로 넣어야 한다. 예를 몇 가지 들어보겠다.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;발로 공격수를 향해 다가가며 공격수의 스틱과 내 스틱을 맞춘다 → 스틱을 잡아먹는다&lt;&#x2F;li&gt;
&lt;li&gt;슛을 기다리지 말고, 적극적으로 막는다 → 슛을 잡아먹는다&lt;&#x2F;li&gt;
&lt;li&gt;막고자 하는 지점으로 온몸이 따라간다 → 슛을 머리로 따라간다(자동으로 몸이 따라온다)&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;여기서 주의해야 할 것이 있다. &lt;strong&gt;해야하는 것&lt;&#x2F;strong&gt;이라 했다. &lt;strong&gt;하면 안되는 것&lt;&#x2F;strong&gt;을 포함하면 안된다. 보통 해야하는 것이 더 늦게 나오기 때문에 이걸 떠올릴 시간을 빼앗아 판단을 늦추고 행동을 급해지게 한다. 이로 인해 하면 안되는 것을 반복하게 된다. 이와 같은 맥락으로, 떠올리는 시간을 아끼기 위해 &lt;strong&gt;가장 짧은 문장&lt;&#x2F;strong&gt;으로 표현해야 한다. 이것은 어휘력이 좋은 선수에게 아주 유리하다. 하나의 언어만 사용하더라도 그 언어를 맛깔나게 이해하고 있다면, 언어적 주문의 난이도는 낮아질 것이다. 만약 본인의 어휘력이 좋지 않다면 어떻게 해야 할까? 힌트를 주자면, 기본적으로 단어나 문장의 느낌을 가지고 언어적 주문을 만들어내도록 한다. 여기서 언어는 언어의 사회성을 무시해도 좋다. 본인만 사용하는 것이니, 어휘의 느낌으로 본인만의 언어 체계를 갖추도록 하라. 그렇게 언어적 주문을 하다 보면, 최종적으로 언어적으로는 표현하기 어렵지만, 신체가 이해하고 자연스럽게 나오는 행동 체계가 완성될 것이다. 이것은 즉 &lt;strong&gt;훈련의 완성&lt;&#x2F;strong&gt;이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 부록1) 무엇을 연습하는가</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-11/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-11/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-11/">&lt;h2 id=&quot;tim-hunryeon-mic-gyeonggi&quot;&gt;팀 훈련 및 경기&lt;&#x2F;h2&gt;
&lt;p&gt;팀 훈련은 실제 경기 상황과 같다고 하였다. 그럼 그저 아무 생각 없이 있으면 될까? 아니다. 경기는 실력을 겨루는 장이기도 하지만, 그 자체로서 다시 훈련의 장이기도 하다. 실전 상황에서만 얻을 수 있는 것들이 있다. 우리는 그것에 신경쓰며 훈련이나 경기에 임하면 된다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;sussaum&quot;&gt;수싸움&lt;&#x2F;h3&gt;
&lt;p&gt;실전 상황이어야만 수싸움에 대한 아이디어가 실제로 통하는지 테스트해볼 수 있다. 각종 수싸움을 시도해 보고, 되는 것과 안되는 것, 그리고 되는건 어떻게 할 때 잘 되는지에 대한 디테일을 갈고닦길 바란다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;simri-jojeol-mic-eoneojeog-jumun&quot;&gt;심리 조절 및 언어적 주문&lt;&#x2F;h3&gt;
&lt;p&gt;실제 경기상황이 아니면 이런 것들은 연습해보기 어렵다. 생각해본 심리기술이나, 스스로에 대한 언어적 주문이 실제로 잘 통하는지 또한 실전에서 테스트해봐야 한다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;keulrieo&quot;&gt;클리어&lt;&#x2F;h3&gt;
&lt;p&gt;같은 팀 선수들과 합을 맞추는 과정은 꼭 필요하다. 패스를 아무리 잘해도 우리팀 선수들과 합이 맞지 않으면 말짱도루묵이다. 훈련 전, 혹은 경기 전에 서로 패스를 주고받으며 합을 맞추도록 한다. 또한, 팀 훈련 중에 드릴에서 세이브를 했다면, 가능한 누군가에게 패스하는 연습을 하라. 받아주지 않는다면, 코치님께 선수들이 클리어도 받아주도록 해달라 부탁을 해도 좋다. 클리어의 완성은 합을 맞추는 것이다. 물론, 받아들이는건 코치의 몫이므로, 적당히 부탁하도록 한다. 아님 말고!&lt;&#x2F;p&gt;
&lt;h3 id=&quot;gibongi-yeonseub-sae-seutig&quot;&gt;기본기 연습? 새 스틱?&lt;&#x2F;h3&gt;
&lt;p&gt;기본기. 예를 들면, 패스와 같은 것은 팀 훈련에서 바꾸려 하지 말라. 자신이 가장 정확하게 던질 수 있는 방법으로 패스를 줘서 팀훈련에 방해되지 않도록 하라.  마찬가지의 이유로, 스틱을 새로 사거나, 포켓을 다시 묶었다거나 할 때, 팀 훈련에서 처음 사용하는 일은 없어야 한다. 미리 월볼을 해서 스스로의 손에 맞는 상태로 만들어서 팀 훈련에 임하도록 하라. 팀 훈련은 팀이 합을 맞추기 위한 훈련임을 명심하라. 개인훈련을 하지 않는 골리는 매일 같은 실수를 하고, 매일 같은 방법으로 골을 허용하며, 매일 같은 방법으로 클리어를 실패하게 될 것이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;gaein-hunryeon&quot;&gt;개인 훈련&lt;&#x2F;h2&gt;
&lt;p&gt;개인 훈련에서는 해볼 수 있는 것들이 굉장히 다양하다. 쭉쭉 써내려가 보도록 하겠다. 언급하는 것들 이외에도 굉장히 다양한 방법들이 있으니, 연구하는 자세를 유지토록 하라. 나 또한 생각나는 것들을 나열했을 뿐, 이외에도 더 있을 것이라 예상한다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;hunryeonyi-gibonjeog-weoncig&quot;&gt;훈련의 기본적 원칙&lt;&#x2F;h3&gt;
&lt;p&gt;훈련의 효과는 실전 상황과 유사할 수록 크다고 했다. 따라서, 세이브를 위한 훈련의 최고봉은 세이브이다. 공격수와 함께 있다면, 그 기회를 놓치지 않고 슛업을 하라. 공격수는 한 자리에서 쏘기도 하고, 움직이기도 하면서 세이브와 포지셔닝을 연습할 수 있도록 해달라. 골리는 슛업과 함께, 세부적으로 연습할 것들을 녹여내도록 한다. 이때는 머리속에 생각이 많아도 된다. 이런저런 것들을 시도하고, 자신이 해야 하는 것에 집중하며 최고의 시간을 보내도록 하라.&lt;&#x2F;p&gt;
&lt;p&gt;마찬가지로, 만약 함께하는 사람이 있다면, 월볼도 좋지만 패스를 함께하라. 그 좋은 기회를 놓치지 말라. 서로의 합도 맞추고, 패스도 섬세하게 가다듬어라. 항상 움직이면서 패스를 하고, 상대방의 스틱 헤드에 공을 정확히 꽂아줄 수 있도록 연습하라.&lt;&#x2F;p&gt;
&lt;p&gt;만약 아무리 신경써도 영 자세가 무너지거나, 원하는 결과가 나오지 않는다면, 다음으로 생각해볼 수 있는 것이 드릴이다. 드릴을 통해 머슬메모리에 동작을 각인시킨다. 머슬메모리는 몸의 동작에 대한 기억이라 설명할 수 있다. 말로 표현하기는 어렵지만, 뭔가를 하려고 할 때 자동으로 튀어나오는 행동이 바로 머슬메모리에 동작이 각인된 결과이다. 신체의 언어로 쓰여진 행동 체계이기도 하다.&lt;&#x2F;p&gt;
&lt;p&gt;마지막으로, 훈련은 반복이 수반되어야 한다. 아주 많은 드릴을 맛보기보다는, 차근차근 하나씩 수없이 반복하여 자기것으로 만들어라. 모든 드릴을 다 정복할 필요는 없다. 목적을 달성하는 드릴 한두 개면 충분하다. 자신만의 개인훈련 루틴을 만들도록 하라.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;honjaseo-hal-su-issneun-gaeinhunryeon&quot;&gt;혼자서 할 수 있는 개인훈련&lt;&#x2F;h3&gt;
&lt;p&gt;그럼 이제 정말 혼자 훈련할 때 할 수 있는 것들을 나열하겠다. 먼저 한 가지 좋은 소스를 소개하겠다. &quot;LaxGoalieRat” 이라는 사이트이다. 난 이곳에서 아주 큰 도움을 받았다. 물어볼 사람이 별로 없었기 때문이다. 영어로 되어 있지만, 영상 자료도 많고 미국의 현역 골리들을 찾아다니며 인터뷰한 자료도 있다. 팟캐스트 형식이기 때문에, 출퇴근길에 틀어놓기도 좋다. 그리고 나 또한 영어를 굉장히 못하는 사람이다. 난 대학교에서 영어 교양 필수 수강과목의 난이도를 정하는 시험에서, 학점을 쉽게 받기 위해 최하수준을 받으려 일부러 망치는 학생들이 있을 정도였던 그 시험에서, 시험을 열심히 치르고도 당당하게 최하수준을 받은 사람이다. 영어에 필요성을 느끼게 된다면, 금방 읽을 수 있게 될 것이다. 화이팅이다. 혼자서 하는 골리 드릴에 대한 게시글 링크를 첨부하겠다. &lt;a href=&quot;https:&#x2F;&#x2F;laxgoalierat.com&#x2F;lacrosse-goalie-workout-and-drills-to-do-all-alone&#x2F;&quot;&gt;골리 드릴 모음(LaxGoalieRat)&lt;&#x2F;a&gt;&lt;&#x2F;p&gt;
&lt;h4 id=&quot;seibeu&quot;&gt;세이브&lt;&#x2F;h4&gt;
&lt;ul&gt;
&lt;li&gt;위치 별 세이브 기본자세
&lt;ul&gt;
&lt;li&gt;Doc drill&lt;&#x2F;li&gt;
&lt;li&gt;Walk the line&lt;&#x2F;li&gt;
&lt;li&gt;Magic square&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;li&gt;포지셔닝 스텝
&lt;ul&gt;
&lt;li&gt;빅스텝: &lt;a href=&quot;https:&#x2F;&#x2F;laxgoalierat.com&#x2F;how-to-properly-move-on-the-lacrosse-goalie-arc&#x2F;&quot;&gt;5-point step(LaxGoalieRat)&lt;&#x2F;a&gt;&lt;&#x2F;li&gt;
&lt;li&gt;스몰 스텝: 이미지 트레이닝 + 잔발치며 스텝 밟기 혹은 5-point step&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;li&gt;반응속도 및 Hand-eye coordination
&lt;ul&gt;
&lt;li&gt;저글링&lt;&#x2F;li&gt;
&lt;li&gt;한손 리액션볼(세이브 자세와 동일하게 벽에 리액션볼을 튀기고 잡는 것)&lt;&#x2F;li&gt;
&lt;li&gt;월볼(아주 세게 던지고 세이브 - 장비 착용하고 할 것)&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h4 id=&quot;paeseu&quot;&gt;패스&lt;&#x2F;h4&gt;
&lt;ul&gt;
&lt;li&gt;월볼 - 거리를 바꿔가면서 벽에 목표지점을 정해서 맞추면서 진행한다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h4 id=&quot;pijikeol&quot;&gt;피지컬&lt;&#x2F;h4&gt;
&lt;ul&gt;
&lt;li&gt;근력 및 파워
&lt;ul&gt;
&lt;li&gt;스틱이 무겁다고 하면 안된다.&lt;&#x2F;li&gt;
&lt;li&gt;부상 위험도 줄여줄 것이다.&lt;&#x2F;li&gt;
&lt;li&gt;웨이트 및 플라이오메트릭 훈련이 좋으며, 몸이 필요 이상으로 무거워지지 않도록 주의하도록 한다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;li&gt;체력
&lt;ul&gt;
&lt;li&gt;턴오버 한 번 났다고 집중력이 떨어지면 안된다.&lt;&#x2F;li&gt;
&lt;li&gt;줄넘기, 인터벌, 조깅 등을 할 수 있다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;li&gt;민첩성
&lt;ul&gt;
&lt;li&gt;스텝 래더와 같은 민첩성 훈련도 함께하면 좋다.&lt;&#x2F;li&gt;
&lt;li&gt;필드 움직임에 큰 도움이 될 것이다.&lt;&#x2F;li&gt;
&lt;li&gt;또한 몸의 무게중심을 제어하는 기술 자체가 좋아질 것이며, 고유수용감각도 좋아질 것이다. 고유수용감각은 눈으로 보지 않고도 내 몸의 위치와 속도 등 상태를 느낄 수 있는 감각이다. 이것이 예민해지면 몸을 컨트롤하는데 유리해진다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>라크로스 골리 - 부록2) 국제대회에서 만나는 상대팀은 어떤 상대일까</title>
        <published>2024-09-26T00:00:00+00:00</published>
        <updated>2024-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lacrosse-goalie-12/"/>
        <id>https://xanthorrhizol.github.io/posts/lacrosse-goalie-12/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lacrosse-goalie-12/">&lt;p&gt;한국에서 훈련할 때, 한가지 논리적으로 타당한 불안이 엄습하게 된다. ‘난 한국의 슛을 막으려고 훈련하는게 아닌데, 한국 슈터들의 슛을 막고 수를 읽는 것이 실제로 대회에 가서는 안 통하는게 아닐까?’  왜 이렇게 구체적인 예시를 드는지 궁금할 것이다. 맞다. 이건 내가 했던 생각이다. 아무리 우리팀 선수들의 슛을 잘 막아도, 대회에서는 만나본 적 없는 팀을 상대해야 한다. 그들이 어떻게 슛을 쏘는지, 그들이 내 수싸움에 어떻게 반응할지, 아무 것도 알 수 없다. 이에 대한 불안을 당장 해결할 수 있는 방법은 팀에 관계없이 통할 방법으로 훈련하는 것이라 생각했다. 난 이 생각 때문에 처음엔 수싸움같은 것들보다는 공을 보고 반응하며 막는 것을 연습하는데 집중했다. 예측하려는 본능을 꾹 참으며 예측을 철저히 배제했다. 하지만 이것만으로는 부족했다. 무엇이 팀과 관계없이 통하는 방법인지 확신을 가질 수 없었기 때문이다. 결국 실제로 상대해보는 것이 유일한 방법이었다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 그때까지 이 막연한 불안을 감내해야 할까? 아니다. 인간에게는 간접 경험이라는 기술이 있다. 간접 경험을 제공하기 위해, 상대해 봤던 국가들의 특징을 대략적으로 소개해 보겠다. 단, 기억하라. 막연한 불안을 덜어주기 위해 이 부록을 준비한 것이다. 실제 경기는 기본적으로 원리를 이해하고 자신만의 기준과 원칙을 세워서 임해야 한다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;ilbon-sangwigweon-dongyang-cegyeog&quot;&gt;일본 - 상위권, 동양 체격&lt;&#x2F;h2&gt;
&lt;p&gt;일본은 확실할 때 슛을 쏘는 경향이 있다. 대부분 골리의 포지셔닝이나 자세가 무너지는 그 시점을 노린다. 따라서 공략 사이드가 크게 바뀐다던가, 수비수가 마킹하지 못해 놓친 공격수로 인해 기회가 만들어졌을 때 대부분 슈팅을 한다.&lt;&#x2F;p&gt;
&lt;p&gt;골리가 움직이는 것을 보고 쏘기 때문에, 공에 집중하고 골대 앞 적당한 거리를 유지한 채, 집중력을 흐릴 수 있는 움직임을 최소화해서 공에 집중하는게 좋다. 수싸움 또한 더 티 안나고 섬세하고 교묘하게 해야 한다. 무엇보다도 애초에 슛이 올 상황을 안 만드는 것이 좋다. 수비에 적극적으로 가담한다. 그렇다고 세이브를 포기하는 것도 아니다. 반응속도, 신체의 스피드, 멘탈&#x2F;집중력 모두 잘 준비해 가야 한다. 이에 더해, 멘탈이 좋아야 한다. 확실할 때 쏘기 때문에 평소보다 세이브율이 낮게 나오는데, 멘붕하지 마라. 그저 한 번 한 번 몰입하고, 상황이 종료되면 시원하게 잊어라.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;hongkong-daeman-junggug-deung-jung-hawigweon-dongyang-cegyeog&quot;&gt;홍콩, 대만, 중국 등 - 중, 하위권, 동양 체격&lt;&#x2F;h2&gt;
&lt;p&gt;여러 국가지만, 한 그룹으로 묶었다. 비슷하기 때문이다. 같은 동양인 체격이더라도, 수준에 따라 슈팅 스타일과 수싸움에 대한 반응이 다른데, 이들은 한국과 비슷한 팀들이다. 훼이크가 잘 없고, 한국에서 연습하던 대로 했을 때 잘 된다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;💡 홍콩의 경우, 최근 오키나와에서 봤을 때 슛 파워가 정말 많이 증가했다. 또한 키가 정말 큰 흑인 선수가 있는데 가까이 가지 않는걸 추천한다. 위에서 빈 공간을 다 보고 꽂아넣는다.&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;h2 id=&quot;noreuwei-pinrandeu-nedeolrandeu-deung-jung-hawigweon-seoyang-cegyeog&quot;&gt;노르웨이, 핀란드, 네덜란드 등 - 중, 하위권, 서양 체격&lt;&#x2F;h2&gt;
&lt;p&gt;기본적으로 한국에서 붙어볼 만한 팀들이 꽤 있는 수준이기 때문에, 역시나 비슷하다. 수싸움이 잘 통한다. 하지만 다른 부분이 있다. 체격이 크다는 것이다. 수비수가 붙어 있어도 슛을 할 수 있으며, 힘으로 때린다. 따라서 언제 슈팅을 할 지 모르니 항상 준비된 자세를 유지하라.&lt;&#x2F;p&gt;
&lt;p&gt;또한 키가 크기 때문에 섵불리 다가가면 머리 위로 빈 공간을 허용하게 된다. 따라서 포지셔닝 시 섵불리 앞으로 나서기보다는 반원 안에 있는게 좋다. 물론, 이들이 그라운드볼을 하는 등 눈높이가 낮아진 경우라면 다가가서 잡아먹어도 좋다. 그리고 이들 중에서도 키가 작은 선수들은 있을 수 있다. 다시 강조하지만, 상대팀에 구애받지 말고 항상 자신만의 기준과 원칙을 지켜야 한다는걸 잊지 마라. 국가별 특징은 단순히 독자들의 막연한 공포와 불안에서 해방시키기 위해 작성한 것이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;kaenada-iseurael-sangwigweon-seoyang-cegyeog&quot;&gt;캐나다, 이스라엘 - 상위권, 서양 체격&lt;&#x2F;h2&gt;
&lt;p&gt;캐나다같은 경우 2015년 U19 월드컵에서 만나본 것이 전부이다. 사실상 그냥 한 시간 짜리 슛업을 한 것 같았다. 힘좋고 거대한 슈터들이 쏠 곳을 정확하게 노리며 쏘는 슈팅은 가히 환상적이었다. 이 글을 읽는 사람들은 미래에 이들과 맞붙을 기회가 많아지길 바란다. 나름의 가설로는, 역시나 기본적인 원리에 입각한 자신만의 기준과 원칙을 활용하면 충분히 즐거운 경기를 할 수 있을 것이라 생각한다.&lt;&#x2F;p&gt;
&lt;p&gt;이스라엘의 경우 생각보다 종종 붙게 된다. 한국보다 훨씬 잘하는 팀이긴 하지만, 조별리그에서 자주 붙게 되는 위치에 있는 듯 하다. 이들은 캐나다보다는 덜 막막하지만, 여전히 저 위 어딘가에 있는 팀이다. 첫 경기에 만나서 수준높은 Non-passport 선수들의 체력적 부담이 없을 때, 초반에 한동안 생각보다 접전이었던 적이 있지만, 전세는 역시 곧 한쪽으로 기울었다. 이스라엘 선수들의 경우 미국에서 많이 넘어간다. 따라서 슈터의 수준은 캐나다, 미국 등과 비슷하다고 보면 될 것이다. 단, 캐나다나 미국 대표팀보다는 덜하다. 각자의 국가에게서 기회를 얻은 미국의 선수들이라고 보면 된다. 우리나라의 일반적인 Non-passport 선수들과 비슷하다. 단지 Passport 선수들의 수준도 높을 뿐이다. 미국에 살지만 이스라엘 국적을 유지하고 있다던가 한 사람이 많을 것이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;guggareul-bulmunhago-tonghaneun-bangbeob&quot;&gt;국가를 불문하고 통하는 방법&lt;&#x2F;h2&gt;
&lt;p&gt;이제 국가별 특징에 대해서는 대충 알겠다. 그럼, 국가에 관계없이, 무엇이 통할까? 이것을 공략한다면, 같은 시간 동안 훈련을 하더라도, 그 효과는 배로 늘어날 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;먼저, 유전적 요인과 체격에 대한 이야기를 하겠다. 본격적으로 들어가기에 앞서, 체격에 대한 극단적인 예시를 들어 보겠다. 2015년 U19 월드컵에서 핀란드 팀이 아주 거대한 골리를 데려왔다. 말그대로 정말 거대했다. 살 때문에 아래쪽으로 스틱을 내리지도 못하고, 아래쪽 공은 눈으로 보지도 못하는 수준이었다. 하지만 통산 세이브율은 45% 근처로 나왔다. 발목쪽으로 슛을 하면 된다는 파훼법은 있었지만, 근본적으로 이 거대한 골리는 슈터를 향해 한 발만 앞으로 가면, 그 슈터는 골대가 어디있는지 조차 전혀 볼 수 없었다고 한다.&lt;&#x2F;p&gt;
&lt;p&gt;대부분의 사람들은 체격이나 유전에 대한 이야기를 꺼린다. 다른 이야기로 희망을 주려 한다. 의사의 선의의 거짓말같은 것과 비슷하다. 하지만, 현실을 빠르게 받아들여야 한다. 그래야 거기서 앞으로의 발전을 논할 수 있다. 받아들여라. 체격이나 유전은 절대 무시할 수 없는 조건이다. 하지만, 만약 그것들이 좀 부족하다고 하더라도 그 현실에 무너지지 마라. 다른 본인만의 무기를 갈고닦을 생각을 하라. 완벽한 포지셔닝, 적극적인 수비 가담, 수싸움 등을 통해 약점을 가리고 강점을 무기로 상대를 제압하라. 언급했던 선수인 Megan Taylor 또한, 불리한 체격을 가진 골리이다. 평균키가 큰 미국에서, 키가 160cm(5’3”)밖에 안된다. 그걸 극복하기 위해 슛에 반응하며 세이브하는 능력을 날카롭게 갈고닦았다. 그 결과로 그렇게 쟁쟁한 미국 대학 선수들 사이에서 탑을 찍은 것이다. 이처럼, 또 한 명의 Megan Taylor가 되어라.&lt;&#x2F;p&gt;
&lt;p&gt;이제, 모두가 예상했던 답을 마저 언급하겠다. 기본 세이브 자세 및 패스캐치 능력, 반응속도, 신체의 스피드, 멘탈, 집중력, 포지셔닝. 모두 이 시리즈에서 강조한 것들이다. 세상의 모든 것은 결국 돌고 돌아 기본을 향한다. 기본의 중요성은 아무리 강조해도 부족하지 않다. 오늘 연습을 좀 해야겠는데 뭘 할지 막막하거나 장소가 여의치 않다면, 일단 그냥 기본기 연습을 하라. 월볼을 하고, 세이브 자세를 수없이 반복하라.&lt;&#x2F;p&gt;
&lt;p&gt;수싸움의 경우 국가별로 다르게 반응할 수 있다. 하지만, 한 가지는 통한다. 한쪽 사이드를 &lt;strong&gt;“조금”&lt;&#x2F;strong&gt; 내어주게 되면, 실제로 내어준 사이드로 올 가능성이 증가한다는 것이다. 내가 수싸움에 대해 설명하면서, 한쪽 사이드를 조금만 내어주고, 그쪽으로 올 가능성이 좀 더 높다는 것만 기억하고 평소대로 세이브를 하라고 한 이유이기도 하다. 마찬가지로 수읽기에 대한 설명도, 여러 국가들을 상대해 보면서 얻은 결론이다. 따라서, 만나보지 않은 상대에 대한 불안과 공포는 접어두고, 그저 본인이 하는 훈련에 집중하도록 하라. 분명 효과가 있을 것이고, 자신이 들인 노력은 당장 눈에 보이지 않더라도 장기적으로는 절대 배신하지 않을 것이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>뎀 윈 델 넷</title>
        <published>2024-09-14T00:00:00+00:00</published>
        <updated>2024-09-14T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/damn-win-dell-net/"/>
        <id>https://xanthorrhizol.github.io/posts/damn-win-dell-net/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/damn-win-dell-net/">&lt;p&gt;동생 생일이 다가오는데, 마침 동생은 3D 모델링 때문에 산 게이밍 노트북을 짊어지고 일산에서 신당까지 오가다가 지쳐버려서 싸고 가벼운 노트북을 이리저리 찾아보고 있었다. 힌트를 이리 쉽게 주다니? 그래서 중저가 노트북을 사주기로 함.&lt;&#x2F;p&gt;
&lt;p&gt;일단 문제와 해결책은 아래와 같다.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;일산과 신당을 매일 오가는데 무거운 노트북을 들고 다니기 버겁다. 최근엔 그래픽 작업보다 논문작업이 주 용도이다.&lt;&#x2F;p&gt;
&lt;p&gt;→ 가벼운 사무용 노트북을 산다&lt;&#x2F;p&gt;
&lt;&#x2F;li&gt;
&lt;li&gt;
&lt;p&gt;발표 시, 좁은 강단 위에 무식하게 큰 노트북을 올려서 하는데 많이 불편하다(낑낑대는 사이 청자들의 시선은 덤)&lt;&#x2F;p&gt;
&lt;p&gt;→ 화면 크기 적당한 노트북을 산다&lt;&#x2F;p&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;대충의 구상은 이렇다.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;13 - 14인치 PD충전 지원 사무용 노트북 구매(외장그래픽카드 없는걸로)&lt;&#x2F;li&gt;
&lt;li&gt;인텔 13-14세대 CPU는 피하기(버그 있음)&lt;&#x2F;li&gt;
&lt;li&gt;집에 게이밍 노트북을 켜두고 원격 데스크톱 열어두기 → 원격으로 그래픽 작업 진행&lt;&#x2F;li&gt;
&lt;li&gt;원격 붙을 수 있는 장소 범위: 아무데서나
&lt;ul&gt;
&lt;li&gt;컴알못에다가 막 쓰는 습관을 고려&lt;&#x2F;li&gt;
&lt;li&gt;any로 원격 열면 분명 랜섬웨어로부터 행운의 편지를 받고 논문 처음부터 다시 쓰는 미래가 보인다.&lt;&#x2F;li&gt;
&lt;li&gt;따라서, VPN 구축 필수&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;노트북은 DELL사의 2024 Latitude 5330 13.3인치 Free DOS 제품을 구매했다. 그런데 여기서 변수 발생. 윈도우 설치 중 드라이버를 찾을 수 없다는 오류가 떴다. 원인을 찾아보니 RAID를 지원하기 위한 Intel RST VMD 드라이버가 설치용 부팅USB에 없었던 것. 그래서 넣어주려고 보니, 내 리눅스 PC에서는 불가능했다. dd 명령을 통해 만든 부팅USB를 마운트할 수가 없었음. 그래서 윈도우 가상머신으로 USB에 해당 드라이버를 Extract해서 해결.&lt;&#x2F;p&gt;
&lt;p&gt;다음 관문이 나타났다. 윈도우를 설치하고 보니, 무선랜카드 드라이버도 없었다. 이외 각종 하드웨어 대부분 필수적인걸 제외하면 드라이버가 없었음. 델 사의 홈페이지에서 그냥 아싸리 드라이버 팩을 받아서 설치를 하려는데… 너무 많아서 열받으며 동생과 잡담을 하던 중, 내 노트북의 무선랜모듈 교체에 대한 이야기가 나옴. 그때 내가 손에 들고 보여준 외장무선랜카드, 아니 이걸 왜 이제야 본거지?&lt;&#x2F;p&gt;
&lt;p&gt;그걸 이용해서 동생의 노트북에서 와이파이 연결한 후 델에서 제공한 드라이버 자동 설치 유틸을 받아서 돌렸다. 해결. 와이파이는 물론, 각종 하드웨어에 대한 동작도 개선되었다. 예를 들면, 두 손가락으로 터치패드에서 스크롤을 하는 등의 것들이 지원됨.&lt;&#x2F;p&gt;
&lt;p&gt;원격데스크톱 설정 후 네트워크에서 접속 확인. 그럼 이제 VPN 구축이 남았다. 그런데 여기서 또 변수 발생. 집의 IP는 유동IP. 어느날 갑자기 바뀔 수 있다. 실컷 VPN 세팅해도 IP가 바뀌면 말짱도루묵이다. 물론 DDNS 설정하면 되기는 하지만, 의외의 복병이 나타남. 라우터 설정으로 ADMIN 접근이 안됨. 맥주소 필터링에 걸렸다 함. 아 초기화하기 귀찮은데… 이때 떠오른 것은 Tailscale VPN이다. 전 인프라팀 팀장님으로부터 소개받은 Wireguard 기반 VPN인데, 세팅이 어렵기로 유명한 Wireguard VPN을 쉽게 세팅할 수 있도록 해주는 오픈소스이다. 해당 VPN에 연결한 호스트를 DNS에 등록해서 통신하는게 가능하고, 호스트끼리 연결되면 P2P 연결이 되어 속도도 좋다. 근데 이거… 너무 좋잖아? 나도 내 개인망 하나 구축해서 이래저래 놀 예정이다.&lt;&#x2F;p&gt;
&lt;p&gt;다음 관문은 체력이다. 지금 이 구상이 머리속에서 계속 커지는 중임. 신체 스레드가 뻗어 대뇌 스레드가 생산한 정보들이 처리되지 않아서 램이 차오르는 중이다. 내일 친척집 방문도 못하게 되었다. 막 이것저것 만들건 많은데 실행이 안되니 서로 뒤엉켜서 우선순위를 놓고 다투는 중이다. 약오른다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>랜모듈 교체</title>
        <published>2024-09-14T00:00:00+00:00</published>
        <updated>2024-09-14T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lan-module/"/>
        <id>https://xanthorrhizol.github.io/posts/lan-module/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lan-module/">&lt;p&gt;난 MSI사의 2021년형 모던 14 노트북을 이용중이다. 그런데, 얼마 전부터 와이파이 연결에 계속 문제가 생겼다. 어쩔땐 중간에 끊기고, 어쩔땐 아예 DHCP를 이용 못함. 그래서 따로 USB포트에 무선랜카드를 꽂아서 사용해 왔다.&lt;&#x2F;p&gt;
&lt;p&gt;그러다 한번 깜빡하고 가방에 랜카드 그대로 꽂힌 채 넣고 다녔다가 곧 랜카드가 부셔지기 직전이 됨. 마치 내 허리처럼 언제 나가리될지 모르는 그런 신세가 되었음. 그래서 먼저 내장 랜모듈의 펌웨어 드라이버를 찾아보기로 했다.&lt;&#x2F;p&gt;
&lt;p&gt;모델명을 알아봤더니 Mediatek MT7921K. 펌웨어가 없었음. 알고보니, 특정 리눅스 버전 이후부터는 지원이 안되고 있었다. 안그래도 아치리눅스라 비교적 많이 최신 커널인데, 딱걸렸다. lts 버전 또한 이미 해당 커널 버전을 지나쳐 있었음. 그럼 방법은, 이전 버전의 커널 소스코드를 받아서 직접 빌드해서 쓰는건데… 안해보기도 했고, 너무 귀찮다. 그리고, 아치를 왜 쓰는데. 최신 커널 제일 먼저 받아다 써볼 수 있다는 것도  이유 중에 하나 아닌가. 왜 내가 고작 이 랜모듈 때문에 리눅스 커널을 과거 버전으로 이용해야 하나. 아치리눅스를 아씨리눅스로 쓸 참인가?&lt;&#x2F;p&gt;
&lt;p&gt;그러던 중, 당근에 레노버 노트북에서 탈거한 리얼텍 랜모듈을 판매하는 글 발견. 바로 구매했다. 노트북 하판을 뜯어서 교체. 부팅하자마자 랜모듈 인식하더니 와이파이 연결하고 DHCP 서버에서 IP까지 정상적으로 받아오는 것 확인. 이제 무선랜카드를 따로 안들고 다녀도 된다. 커널 업데이트도 마음놓고 할 수 있을 것이다. 그래서 신이 나서 다시 linux-lts 대신 linux 이용하도록 세팅 변경하고 pacman 업그레이드 돌렸다&lt;&#x2F;p&gt;
&lt;p&gt;이제부터 리눅스 6.10.10 사용한다. 신난다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>회고록 - 1. 서론</title>
        <published>2024-08-25T00:00:00+00:00</published>
        <updated>2024-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/memoir-01/"/>
        <id>https://xanthorrhizol.github.io/posts/memoir-01/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/memoir-01/">&lt;p&gt;난 요즘 건강 문제로 휴식기를 가지고 있다. 그리고 어느 정도 집중력을 회복한 지금, 살아온 길을 한 번 정리할 시간이 되었다. 아주 파란만장하지는 않지만, 남들과는 조금 다른 삶을 살아 왔다. 이동이 잦아서 여러 세상들을 보고 자랐다. 그래서 생각하는 것도 많이 다르다.&lt;&#x2F;p&gt;
&lt;p&gt;전 여자라크로스 대표팀 감독님은 나에게 한 번 이런 말씀을 하셨다. “난 너가 무슨 생각을 하고 사는지 모르겠어”. 그럴 만 하다. 하지만 어디서부터 설명해야 할 지 감이 잡히지 않아서 그냥 “저도요” 하고 말았다. 난 할 만한 말이 많지 않다보니, 소위 “개소리&quot;를 많이 한다. 영양가 없는, 장난에 가까운, 뜻없고 과장된, 실없는 헛소리들 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;이동이 잦은 삶을 살았고, 어디를 가도 이방인인 삶이었다. 특유의 폐쇄적인 성격은, 그 여러 세계들을 관찰자의 시선으로 관찰케 하였다. 삶의 흐름이 다르다 보니, 사람들에게는 잘 말하지 않게 되었다. 남들도 다들 이미 많은 일들을 겪었고, 자신들의 세계관이 존재한다. 게다가 조금은 어두운 이야기도 섞여 있기 때문에, 밝은 친구들에게 그런 세상 이야기를 하기도 좀 부담스럽다. 딱히 알아도 도움이 안되는 것들이기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;사람은 생각보다 남의 이야기에 관심이 없다. 내가 그런 것처럼 말이다. 자신의 이야기를 주구장창 길게 늘어놓는 것은 타인에게 피로로 다가올 수 있다. 그래서 회고를 할 땐 누군가에게 말로 털기보다는 혼자서 글을 쓴다. 글을 쓰면 생각을 정리하는데도 도움이 된다.&lt;&#x2F;p&gt;
&lt;p&gt;난 지금도 초등학교 4학년 중간고사 때 사회 과목 시험에서 주관식 문항의 답인 등고선이 기억나지 않아서 고민 끝에 고등선이라는 답을 제출한걸 기억하고 있다. 아 물론, 분했기 때문에 기억하는거다. 걷지도 못하던 아기 때 어머니가 나를 어떤 자세로 업었는지도 기억한다. 물론, 불편하게 업어서 기억하는거다. 초등학교 시절에 놀러 다니던 강가의 식당 이름도 기억한다. 솔밭가든, 신장가든. 솔밭가든쪽이 수심이 더 깊어서 놀기 좋았다. 장기기억에 남기만 하면 꽤나 생생하게 오래 기억하는 편이다. 대학교 교양 심리학 과제로 인생곡선을 그려오라고 했는데, 64개의 사건에 대한 곡선을 그려갔다.&lt;&#x2F;p&gt;
&lt;p&gt;기억하는게 많은 바람에, 글을 쓰면 많이 길어지는 편이다. 난 항상 글을 쭉쭉 써내려간 후, 요약하고 지우고 재배치하는 데 더 많은 시간을 소비한다. 다행히도 대학교 글쓰기 수업에서 개요를 작성해서 뼈대를 세우고 글을 쓰는 등의 잡기술을 얻어서, 이런 식으로 삽질하는 시간은 좀 줄어들었다.&lt;&#x2F;p&gt;
&lt;p&gt;이번엔 회고를 공개하게 되었다. 이 블로그는 배설하듯 글을 쓰는 공간이다. 남의 피드를 차지해서 강제적으로 눈앞에 나타나는 그런 플랫폼이 아니기 때문에, 자유롭게 글을 쓰고 있다. 그런 공간에 걸맞게, 생각나는 대로 써내려갈 것이다. 사실, 이렇게 써놓고 실제로는 고쳐써야 했다. 처음엔 쭉 이어서 썼다가, 너무 길어서 10편으로 나눴다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>회고록 - 2. 이별 전문가</title>
        <published>2024-08-25T00:00:00+00:00</published>
        <updated>2024-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/memoir-02/"/>
        <id>https://xanthorrhizol.github.io/posts/memoir-02/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/memoir-02/">&lt;p&gt;아버지는 직업군인이었다. 온 가족이 가장을 따라 함께하던 과거, 군인 가정은 한가지 특수한 환경에 처해 있었다. 바로 잦은 이사다. 1~2년 마다 다른 지역으로 이사를 하는 것이 표준이었다. 주변의 모든 것은 단지 곧 지나가고 사라질 무언가였다. 사람도 마찬가지였다. 그나마 유년시절 남은 기억엔 인천에서 지내던 동안 내가 매일같이 집에 찾아갔던, 항상 자신이 하던 게임을 구경시켜주던 사람과, 평택에 지내는 동안 집에 매일같이 방문하며 놀았던 친구의 어렴풋한 얼굴 특징과 이름 정도만 있다. 하지만 이사로 인해 결국 그들과도 이별해야 했다.&lt;&#x2F;p&gt;
&lt;p&gt;유년을 그렇게 보내고 나니, 초등학교 입학 이후부터는 누군가에게 마음을 주지 않았다. 사실 그냥 성격이었을 수도 있다. 부모님께 뒤늦게 들은 사실이지만, 난 아기 때 자폐증 검사를 한 적이 있었다. 자폐증을 진단받진 않았지만, 어느정도 가까운 스펙트럼에 있긴 한가보다. 오히려 그런 성격이 이런 생활을 무덤덤하게 보내는데 도움이 되었을 수도 있다. 난 사람보다 주변의 사물이나 돌아가는 세상에 관심이 많았다. 혼자 잘놀았다. 곤충채집을 하거나, 집 근처 개울에서 올챙이나 도롱뇽을 잡기도 하고, 식초와 소다를 구해서 필름통 폭탄을 직접 만들기도 했다. 주말이면 가족끼리 근처의 강으로 가서 수영을 하고 피래미와 다슬기를 잡으며 놀았다. 그렇다고 완전 폐쇄적이진 않았다. 가끔 놀이터로 가면 그곳에 있는 아이들과 서로 이름도 모른 채 함께 놀았다. 노는 방법도 특이했다. 부서진 나무 시소를 다같이 낑낑대며 뜯어와 그네에 연결해서 4-5명이 동시에 그네를 타기도 했다. 당장 내일도 헤어질 수 있는 우리들은 굳이 통성명을 하지 않았다. 서로를 알아가는 것보다는 지금 당장 재밌는 무언가를 하는데 더 집중했다.&lt;&#x2F;p&gt;
&lt;p&gt;그래도 다른 군인가정과는 다르게 우리 가족은 계룡이라는 군인도시에서 장장 6년 정도를 지냈다. 오래 지내니 한 곳에 정착되어 정서적 안정감은 있었다. 하지만 다른 친구들은 그때도 옮겨다니는 삶을 살았을 터. 우리는 학교에서 만나면 함께 놀기는 했다. 하지만 거기서 끝이었다. 어차피 이 군인도시에서는 또 학기가 지나면 누군가 전학을 가고, 학년이 넘어가면 무더기로 인원이 바껴서 누가 가고 누가 왔는지 조차 안내가 없었기 때문이다. 매년 아버지들의 거처가 결정되는 발령철에 자신들의 이후 행선지를 밝히며 이별을 고하는게 그곳의 문화였다. 대신 이곳은 한가지 좋은 점이 있었다. 왕따가 생길 틈이 없었다. 아이들은 적당히 같이 놀다가, 헤어질 땐 쿨하게 헤어졌다. 중간 전학생은 매년 2-3명씩 있었기 때문에 금방 친구들과 어울릴 수 있었다. 그러다 초등학교 6학년 2학기에 아버지가 제대하셨고, 새 직장을 따라 부산으로 내려가게 되었다.&lt;&#x2F;p&gt;
&lt;p&gt;이곳에서 습관이 하나 생겼다. 사람의 이름을 외우는데 아주 오래 걸리게 되었다. 이사를 간 이후, 몇년동안은 매년 한 달 넘는 기간 동안 동급생 이름을 다 알지 못했다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>회고록 - 3. 가난의 표현형</title>
        <published>2024-08-25T00:00:00+00:00</published>
        <updated>2024-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/memoir-03/"/>
        <id>https://xanthorrhizol.github.io/posts/memoir-03/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/memoir-03/">&lt;p&gt;부산으로 이사갔다. 부산은 처음이 아니었다. 방학 때 종종 부산 용호동의 외할머니 댁에서 한 달 정도씩 지냈기 때문이다. 하지만 학교에 실제로 다닌건 처음이었다. 호전적인 사투리를 제외하면 별다른 특징을 느낄 수 없었다. 고작 한 학기를 다니고 졸업했기 때문이다. 본격적인 민간 가정으로서의 학교 생활은 중학교 때부터였다.&lt;&#x2F;p&gt;
&lt;p&gt;내가 있던 곳은 공단 근처였다. 부촌은 아니었다. 아버지들이 모두 똑같은 군인이었던 계룡과는 달리, 그 안에서는 빈부격차가 있었다. 엇나가는 학생들도 많고, 사방이 도로에 인접한 학교였기 때문에 학생들의 안전을 위해 선도부가 할 일이 많았다. 난 입학 당시 사춘기를 크게 겪지 않고 있었기 때문에 순둥했고, 애들한테도 관심이 없어서 담임선생님은 나를 선도부로 배정했다.&lt;&#x2F;p&gt;
&lt;p&gt;아침엔 요일 별 당번으로 일찍 등교해서 복장 및 지각단속 등을 하고, 점심엔 외출을 관리하고, 담을 넘거나 달려서 교문을 탈출하려는 무단외출 시도를 단속했다. 난 설명을 듣고 학교의 헌병이라고 이해했다. 아무 것도 모르는 신참은 눈치없이 3학년 양아치를 잡고 이름을 적었다. 밥을 함께 먹는 친구조차 예외는 없었다. 장교가 온다거나, 매일 보는 이가 온다고 해서 신분증 검사를 안하는 헌병을 본 적이 없기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;선생님은 물론 부모님께도 알리지 않은 사실이지만, 위험한 일이 없진 않았다. 한 번은 내가 급한 용무로 복도를 뛰어가고 있는데 어떤 학생이 목에 커터칼을 들이댄 적이 있었다. 손이 알아서 칼을 쳐서 떨궈버렸고, 다리는 달리던 그대로 달려나가서 그 학생이 누군지도 못보고 사건은 일단락 됐다. 그래도 그런 사건이 한 번 지나가고 나니, 이후 딱히 나를 건드는 사람은 없어서 평화롭게 다녔다. 나에게 소매치기를 시도하는 양아치 후배와 눈이 마주친 것 정도가 다였다.&lt;&#x2F;p&gt;
&lt;p&gt;난 그냥 중학교에 선도부를 하기 위해 들어간 로봇같았다. 인간 사이의 깊은 교류라는 것을 애초에 몰랐다. 대화는 그 대화로 끝이었다. 그냥 들은 말에 대답하는 것이 내 대화법이었다. 사실 왜 이런걸 물어보는지도 이해 못했다. 매일 밥을 함께 먹던 친구들의 이름도 기억이 안난다. 좀 미안하다. 난 친구들보다 그날의 수업, 선도부 활동, 선생님이 시키는 일 등에 관심이 더 많았다. 이런 점 때문에 선생님들은 나를 신뢰했고, 나도 모르는 권력이 나에게 주어져 있었다.&lt;&#x2F;p&gt;
&lt;p&gt;전학을 온 친구가 나에게로 찾아왔다. 초등학교 때 의례 그랬던 것처럼 그저 밥을 같이 먹고 대화를 나눴다. 무슨 말을 주고받았는지는 기억이 나지 않는다. 이름조차 기억나지 않는다.&lt;&#x2F;p&gt;
&lt;p&gt;그 친구는 따돌림을 당하고 있었다. 나에게 도움을 요청하고 있었는지도 모른다. 그 친구는 다른 반에 있었기 때문에, 난 점심 시간에 따라오는 그 친구와 함께 밥을 먹고, 하교하면서 교문 밖을 나설 때까지 따라오는 그 친구와 간단한 담소를 나눴다. 그 친구가 무슨 일을 계기로 따돌림을 당했는지, 무슨 일들을 당했는지는 지금도 모른다. 본인이 이야기할 리 만무하고, 내가 알아볼 리도 없었기 때문이다. 내가 뭔가 특별히 생각하거나 느낀 점이 있었다면 분명 포대기에 싸여 어머니 등에 업혔던 기억처럼 뚜렷하게 기억났을텐데 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;내가 평소 함께 밥을 먹던 다른 두 친구는 그 친구가 따라오는걸 막지 않자 나에게 경고했다. 그 친구가 왕따라고. 그렇군. 별로 신경쓰지 않았다. 곧 멀어졌다.&lt;&#x2F;p&gt;
&lt;p&gt;그 왕따 친구는 곧 다시 아버지를 따라 전학을 갔다. 그러면서 나에게 편지를 주고 갔는데, 그제서야 그 친구가 왜 나를 따라다녔는지 알게 되었다. 나는 걸어다니는 치외법권같은 것이었다. 내가 평화로운 생활을 누렸던 이유는 내 주변이 평화로웠기 때문이었다. 내 뒤엔 선생님들이 계셨다. 그렇게 어느날 갑자기 뜬금없이 감사 인사를 받으며 익숙한 이별을 했다.&lt;&#x2F;p&gt;
&lt;p&gt;그곳에서 본 가난의 모습은, 수돗물로 허기를 채우는 학생의 모습 따위가 아니었다. 불안 속에 등교하는 학생들의 모습이었다. 따돌림을 당하는 친구를 피해 멀어졌던 다른 친구들은 그 친구가 싫어서가 아니라, 자신도 그 여파를 받는게 두려워서 마음 한 켠의 불편함을 뒤로 한 채 따돌림에 가담하고 있었다. 나아가서, 약해빠진 청소년일 수록 자신의 나약함을 감추기 위해 더 쎈척을 하며 주변을 피곤하게 했다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>회고록 - 4. 중산층의 세상</title>
        <published>2024-08-25T00:00:00+00:00</published>
        <updated>2024-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/memoir-04/"/>
        <id>https://xanthorrhizol.github.io/posts/memoir-04/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/memoir-04/">&lt;p&gt;아버지는 더 좋은 직장을 구해 상경했다. 어머니는 골프에 입문해서 3년 만에 티칭프로 자격증을 땄다. 아무래도 곧 있을 고등학교 진학을 위한 준비였던 것 같다. 고등학교에 진학하며 또 이사를 갔다. 어머니와 함께 이사를 간 곳은 해운대였다. 맞았다. 맹모삼천지교였다. 어머니는 골프고등학교에서 강사로 일하기 시작하더니, 곧 골프연습장을 개업해서 사업을 키워나갔다.&lt;&#x2F;p&gt;
&lt;p&gt;난 해운대에 가서 충격을 받았다. 빈부격차가 뭔지 두 눈으로 확인했다. 해운대는 어느정도 부촌이다. 학생들의 키에서 바로 나타났다. 중학교 때는 내가 큰 키였다. 하지만 해운대에선 특별하지는 않은 키였다. 키 뿐만 아니라, 여러 모로 달랐다. 학생들의 얼굴색은 골랐고, 밝았다. 노는 애들은 있어도, 남을 괴롭히는 무리는 없었다. 왕따도 없었다. 걱정이 없는 그곳의 학생들은 순하고 착했다. 즐겁고 평화로운 고교 생활을 누렸다. 선도부는 그저 등교시간에 차와 학생의 길을 분리하며 학생들의 안전에 집중할 뿐이었다. 복장위반이나 지각은 그저 해프닝이었다. 그걸 핑계삼아 선생님은 툴툴거리며 말을 걸고, 학생은 능글맞게 웃어넘기며 쏙 빠져나갔다. 기자와 작가들은 이런 부촌에 악마가 살길 바라며 각종 자극적인 기사와 작품을 내놓지만, 실제로 악마는 빈자들의 도시에 더 많았다.&lt;&#x2F;p&gt;
&lt;p&gt;부촌에 들어간 로봇에겐 곧 체대에 진학하겠다는 목표가 생겼다. 하고싶은 것이 생겼다. 그전까지는 마치 관찰자의 시점으로 세상을 살았다. 지금까지 가지고 있는 “어차피 인간은 다 죽는다”는 허무주의적 세계관도 중학교 때까지 봐온 것들에 의해 형성되어 온 것이다. 친구들과 몰려다니지 않는 사람은 그 시기, 나름 배우고 겪은 일들을 종합하며 생각이 참 많았다. 세상은 어리석은 자들이 스스로 만든 하나의 지옥이라 생각했다. 목표의 탄생은 이 가치관에 약간의 변화를 줬다. “어차피 죽을 인생, 하고싶은거나 실컷 해보자”였다. 흘러다니는 삶은 변하지 않았지만, 변화하는 사이클 사이에 몰입할 것들이 항상 생기게 되었다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>회고록 - 5. 성취</title>
        <published>2024-08-25T00:00:00+00:00</published>
        <updated>2024-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/memoir-05/"/>
        <id>https://xanthorrhizol.github.io/posts/memoir-05/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/memoir-05/">&lt;p&gt;고등학교 3학년에 입시체육을 시작했다. 1학년 때부터 세워둔 목표를 달성하기 위한 마지막 단계였다. 체육대학 진학을 부모님은 내켜하지 않았기 때문에, 정 가고싶다면 SKY 대학을 가라고 했다. 찾아 찾아 입시요강이 나에게 가장 유리한 학교인 연세대를 목표로 뒀다. 화, 목은 야간자율학습을 했다. 월, 수, 금은 학원에 가서 훈련을 하고 학교로 돌아와 텅빈 교실에서 야간자율학습 연장전(야야자라고 불렀다)을 했다.&lt;&#x2F;p&gt;
&lt;p&gt;학원의 강사들은 대부분 육상선수 출신이었다. 다들 국가대표 상비군 이상급이었다. 부산대, 동아대 등, 부산의 대부분 대학교들은 육상 기초실기의 비중이 높았다. 심지어 부산대에는 마의 중거리 달리기가 실기 종목에 포함되어 있었다. 덕분에 죽도록 뛰어다녔다. 일단 3km를 뛴 다음, 스트레칭을 간단히 하고 20m, 30m, 50m 스프린트를 각각 5-3-2회 실시한 후 다시 50m를 80% 윈드로 뛰고 돌아온 다음, 점프 투성이인 다이나믹 웜업을 한바탕 뛰어주고 나서야 비로소 본 훈련이 시작됐다. 그리고 서킷, 하체파괴, 인터벌이라는 극혐 3대장이 있었는데, 이 중 하나를 매주 2회 훈련 마무리 전에 진행했다. 한 번은 해변의 모래사장을 뛰었는데, 끝나고 그대로 화장실로 달려가 구토를 해야 했다. 이런걸 하고 사니 세상 무서울게 없어졌다. 어머니가 공부가 더 편하다고 했던 말이 무슨 말인지 알 것 같았다.&lt;&#x2F;p&gt;
&lt;p&gt;목표하던 연세대학교에 무사히 입학했다. 사실 이 과정도 우여곡절이 컸다. 안정지원 점수대로부터 무려 40점 정도 떨어지는 수능 언수외(국영수) 표준점수를 받아들었기 때문이다. 뭐 당연한 결과였다. 고집이 쎄서, 모르는 수학문제가 있으면 나름의 답을 도출하기 전까진 절대로 답지를 보지 않았다. 한 문제를 3시간 넘게 잡고 있는 일도 다반사였다. 집에 부모님이 사둔 과학 전집을 읽다가 차원이론에 빠져 엉성한 이해로 4차원에 대한 좌표평면을 그려보겠다고 엉뚱한 삽질을 하면서 시간을 날리기도 했다. 학교 수학선생님에게 가져가 물어봐도 모른다는 답을 받았고, 그래서 아버지에게 물어봤더니 네 번째 축은 시간이라는 답을 받았는데, 하필 그 내용을 읽기 전이었어서 “에이 뭔소리야” 하고 또다시 나름의 답을 찾겠다고 난리를 치며 시간을 날렸다. 3차원을 2차원에 그리니까, 그럼 3차원에 4차원을 그리면 되나? 하고 정육면체 위에 그림을 그려대기도 했다. 목표에 맞지 않게 너무 여유를 부려댔다.&lt;&#x2F;p&gt;
&lt;p&gt;각설하고, 그럼 그 40점 떨어지는 점수를 어떻게 만회했냐고? 내가 평소 서울의 입시정보를 입수하던 안양의 체대입시학원에서는 내가 합격 가능하다는 베팅을 했다. 나름의 계산이 있었기 때문이다. 수강료도 받지 않겠다고 하며 통큰 제안을 했다. 이 학원은 이전부터 수능점수에 비해 상향지원을 하는 분야에 전문이었다. 상경해서 전공실기를 다졌다. 결국 실기로 수능 점수를 만회하는데 성공해서 무사히 입학했다. 합격 후 어머니는 학원 원장님께 감사의 표시로 입시학원에 사용하기 위해 모아뒀던 돈을 사례금으로 드렸다.&lt;&#x2F;p&gt;
&lt;p&gt;내 소식은 부산에서 다니던 입시학원에 큰 호재로 작용했다. 적당한 수능점수와 함께 합격했다면 그정도 호재는 아니었을 것이다. “아니 우리 아이도 혹시?” 이 사례는 학부모들에게 달콤한 유혹이었을 것이다. 그리고 당시 부산은 여전히 그런 스토리를 많이 팔고 있었다. 학교 앞에서 나눠주는 홍보물엔, “X등급, 어디어디 합격”과 같은 자극적인 문구 일색이었다. 그곳은 그런 호재를 받아들일 만한 준비가 되어 있지 않았다. 오랜만에 방문했더니, 수강생이 폭발적으로 늘어 있었다. 그 때는 그 호재를 소화하기에 아직 늦지 않은 시기였다. 하지만 대표님은 나에게 그곳에 어떤 노하우들이 있었는지, 내가 어떤 과정을 거쳤는지, 어떤 계산이 들어맞았는지, 아무 것도 묻지 않았다. 그저 고가의 외제차에 나를 태우고 동네 한 바퀴를 돌며 최근에 생긴 여자친구를 소개할 뿐이었다. 난 크게 실망했다. 갓 고등학교를 졸업한 햇병아리가 봐도 그건 대놓고 망조 신호였다. 하지만 충언을 하기엔 이미 늦었다. 이미 대표님은 눈빛이 취해 있었다. 결국 정해진 수순대로 그 학원은 폐업했다. 그곳은 호재를 맞이했을진 몰라도, 만들어내는 법은 몰랐다. 운동은 힘들어도 나름 고3 시절을 즐겁게 보내게 해준 곳이었는데, 안타까웠다.&lt;&#x2F;p&gt;
&lt;p&gt;대조적으로, 안양의 학원은 지금도 성업중이다. 둘 사이의 차이는, 이런 사례가 튀어나왔느냐, 아니면 그 사례를 직접 만들어 냈느냐이다. 난 1학년 때부터 입시정보나 전략은 모두 안양의 학원을 통해 얻었다. 전략의 수학적 근거까지 세세히 설명했기 때문에 신뢰할 수 있었기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;부산에서는 수능 전에 공부할 시간까지 쪼개서 당장 기초실기 시험을 봐도 될 정도로 육상능력과 기초체력을 완성해 놨지만 수능이 끝나고 추가로 유입된 새로운 수강생들과 함께 또다시 지옥훈련을 진행해야 했다.&lt;&#x2F;p&gt;
&lt;p&gt;상경했을 땐 체력이 아니라 바로 전공 기술훈련에 들어갔다. 체력은 떨어지지 않는 선에서 관리했다. 덕분에 오전에 나가 밤에 돌아오는 일정임에도 불구하고 오전에 더 일찍 나가서 개인적으로 연습할 에너지가 남아있었다. 매일 더 일찍 가서 스스로 곱씹으며 기술훈련을 했다. 게다가 이곳은 이전의 많은 케이스들을 바탕으로 실기시험을 직접 치뤄야만 알 수 있는 정보들을 확보하고 있었다. 그런 노하우가 뒷받침된 상태에서 난 그저 또 하나의 상향지원 합격사례로 남았을 뿐이었다. 그리고 그곳은 나의 사례를 얻은 것이 아니라, 나의 데이터를 얻었다.&lt;&#x2F;p&gt;
&lt;p&gt;이 사건을 겪으면서 성취에 대해 그것이 내 성취인가 남의 성취인가를 구분해야 한다는 것과, 한 번 한 번의 성취에 취하지 않아야 한다는걸 알게 되었다. 특히 행운이 클수록 경계해야 한다는 것을 특히 명확하게 알았다. 세상에 공짜는 없다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>회고록 - 6. 사회화</title>
        <published>2024-08-25T00:00:00+00:00</published>
        <updated>2024-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/memoir-06/"/>
        <id>https://xanthorrhizol.github.io/posts/memoir-06/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/memoir-06/">&lt;p&gt;안타까움을 뒤로 하고, 대학에 입학한 후 친구가 생겼다. 골프선수인 그 친구는 나처럼 4차원이었다. 대화를 하다 보면 진짜로 우주로 나갔다. 진짜 우주 이야기도 했다. 차원이론 따위를 이야기해도 그 말을 이해하고 대화가 가능할 정도로 4차원인 친구였다. 어릴 때부터 사회생활을 해오던 그 친구는, 나에게 위험한 사람을 피하는 팁과 같은 것들을 많이 알려줬다. 눈빛, 시선의 움직임, 순간순간 드러나는 표정을 통해 구린 속내가 따로 있는지 없는지, 거짓말을 하고 있는지 알아내는 그런 팁이다. 인간관계가 얕아서 고정관념이 하나도 형성되지 않은 나에게 큰 도움이 되었다. 서울 가면 코를 베어간다고, 사이비 종교의 접근이 좀 있었는데, 덕분에 다 잘 빠져나왔다.&lt;&#x2F;p&gt;
&lt;p&gt;그럼 대학교땐 뭘 하고 살았나. 요약하면 라크로스다. 거의 모든걸 포기했다. 교환학생, 학석사연계, 학점, 고등학교 때 가졌던 꿈, 다 포기했다. 고등학교때 가진 꿈이 뭐냐고? 난 고등학교 때부터 파쿠르를 즐기고 있었다. 인간이 가진 태초의 움직임에 집중한 이 운동은 나의 흥미를 자극했다. 체육대학 대학원에 진학해서 이 종목을 역학적으로 분석하고 연구를 지속하는 것이 내 꿈이었다.&lt;&#x2F;p&gt;
&lt;p&gt;나는 과 동아리로 라크로스 동아리에 들어가게 되었다. 동기는 딱히 없었고, 동아리 하나는 들어가는게 좋다 하여, 그 이야기를 하신 선배님의 동아리에 그대로 들어갔다. 그 동아리는 학교 최초의 여자 운동동아리였다. 국가대표가 7명이나 있던 동아리의 훈련 강도는 꽤나 괜찮았다. 적당히 기진맥진했다. 주 2회 운동이었다. 적당히 하라는거 하고 출석 하며 지냈다. 하다보니 재미도 좀 붙었다.&lt;&#x2F;p&gt;
&lt;p&gt;하지만 2014년 2학기부터 주장을 맡게 된 이후 꽤나 많은 것들이 바꼈다. 가장 먼저, 파쿠르와 라크로스를 동시에 하면서 주장까지 맡았더니 몸에는 피로가 누적되기 시작했다. 그 신호는 2015년에 정강이에 피로골절이 발생하면서 나타났다. 정강이 중간에 대놓고 금이 갔다. 점프를 할 때마다 전기가 올라왔다. 라크로스 중에 삐었던 발목은 알고보니 연골이 찢어져 있었다. 2015년 U19 월드컵이 끝나고, 이어진 2학기를 마무리하자마자 연골편 제거수술을 받았다. 정강이는 1년이 지나도 붙질 않아서 결국 충격파를 동원해서 붙였다.&lt;&#x2F;p&gt;
&lt;p&gt;파쿠르를 그만뒀다. 라크로스엔 책임져야 할 것들이 많았기 때문이다. 체대동아리의 마지막 체대생이었던 탓에, 라크로스를 포기하면 거기서 그 동아리는 끝이었다. 때문에 중간에 교환학생을 가보는 것도 알아서 포기했다. 중앙동아리로 인준해서 주장을 넘기는 것이 내 유일한 목표였다. 하고싶은건 그 다음에 하기로 했다. 하지만 선배들의 반대에 부딪혔다. 체대동아리에게 주어지는 혜택을 중앙동아리가 따라올 수 없었고, 체대 후배를 모집하는데 더 집중하길 원했기 때문에 설득이 어려웠다. 그렇게 버티다 결국 체대 학생회에서 협의회 안내도 없이 자기들끼리 회의를 진행시켜, 체대생 비율에 관한 규칙을 통과시키는 바람에 체대 동아리에서 쫓겨날 위기에 처했다. 기분은 더러웠지만, 차라리 잘됐다 싶었다. 덕분에 비로소 준비하고 있던 인준 프로젝트를 본격적으로 진행시킬 수 있었다. 선배들을 설득하고, 여성체육 분야에 열정적이던 지도교수님에게 다시금 찾아가 중앙동아리가 될 동아리가 앞으로 여성체육 신장에 큰 역할을 하게 될 것이라 장담하며 도움을 청해 기존 동아리방과 운동장소 대관을 지켜냈다. 한시라도 더 일찍 중앙동아리로 등록하기 위해 체대동아리를 자진 탈퇴했다.&lt;&#x2F;p&gt;
&lt;p&gt;난 사실 선배들이 설득되지 않던 그 시기에도 중앙동아리 인준 준비를 이미 하고 있었다. 무더기로 졸업하는 바람에 이미 체대 선배층이 무너졌고, 다른 열악하지 않은 스포츠 종목의 동아리가 즐비한 상황에서 체대 후배 모집은 가능성이 희박하기 때문에, 중앙동아리로 옮기는게 동아리가 유지되기 위한 유일한 방법이라 생각했기 때문이다. 게다가 애초에 경력자가 거의 없어서 처음부터 차근차근 알려주는 이 친절한 동아리는 타과생들에게 더 인기가 많았다. 선배를 설득하는 일은, 내 졸업이 가까워질 수록 쉬워질걸 이미 알고 있었다.&lt;&#x2F;p&gt;
&lt;p&gt;중앙동아리로의 전환이 늦어진 만큼 나는 주장을 계속해야 했다. 2학년 2학기부터 2년 반을 주장직에 몸담았다. 나에게 맞지 않는 일을 장기간 하고 있게 됐다. 중앙동아리 사회는 동아리방과 지원금, 연고전이나 아카라카 티켓같은 한정된 자원을 놓고 공유해야 하는 탓에 신규 등록을 반기지 않았다. 신규등록 제출서류를 봤더니, 그냥 “등록하지마&quot;로 읽혔다. 그리고 그 사회 내부는 완전 정치판이었다. 자기 동아리의 이익이 우선인 그런 정치판이다. 그들은 신규등록 절차에 각종 장벽을 쌓고, 자신들의 이익을 사수했다.&lt;&#x2F;p&gt;
&lt;p&gt;그 사회에 빠삭하고, 그런 정치판이 깨끗해지길 원하는 분들을 알게 되었다. 그저 활동을 활발히 했을 뿐, 연고전이나 아카라카조차 관심이 없던 우리 동아리는 깨끗했다. 선배들이 얼마나 활동을 열심히 해왔던지, 이미 우리는 전부터 유명했다. 그분들은 그런 우리 동아리가 중앙동아리로 전환하려 한다는걸 반겼다. 민감한 이슈들을 지속 트레킹하고, 동아리의 평판을 관리하고 인준 자료를 준비하는데 많은 도움을 줬다. 난 그 도움을 얻어 민감한 이슈에 휘말리지 않도록 내부를 단속하거나, 휘말릴 수 있는 활동에 대한 니즈와 타협점을 찾는 일을 했다. 말 한 마디 한 마디도 신중해야 했다. 신규등록을 위해 동아리 평판을 관리해 가며 중앙동아리 회원 150명과 현임 회장 20명의 동의를 얻어내야 했고, 때로는 만연한 문제에 대해 눈감아야 했다. 친목 등 동아리 내정은 다른 운영진 분들께 대부분 맡겼다. 그분들까지 없었으면 아마 힘들었을거다.&lt;&#x2F;p&gt;
&lt;p&gt;나는 그런 몸에 맞지 않는 대외 정치질을 하며 탈출을 꿈꾸며 버텼다. 결국 2016년 9월 29일, 동아리연합회 정기회에서 일종의 디펜스 질의를 거쳐 압도적 찬성, 반대 0명으로 인준에 성공했다. 예상질문을 나름대로 생각해서 갔는데, 그 안에서 다 나왔다.&lt;&#x2F;p&gt;
&lt;p&gt;하지만 이후 건강이 급격히 악화되어 휴식기를 가져야 했다. 물론 그렇다고 해서 그렇게 한걸 후회하진 않는다. 그 동아리는 내가 처음으로 사람들과 교류다운 교류를 했던 곳 중 하나다. 그 사람들과의 공간을 무사히 지켜내고 다음으로 넘겨주고 싶었을 뿐이다. 결론적으로는 성공했다. 이젠 더 능력있는 후배들이 동아리를 잘 이끄는 중이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>회고록 - 7. 성인식</title>
        <published>2024-08-25T00:00:00+00:00</published>
        <updated>2024-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/memoir-07/"/>
        <id>https://xanthorrhizol.github.io/posts/memoir-07/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/memoir-07/">&lt;h2 id=&quot;taljin&quot;&gt;탈진&lt;&#x2F;h2&gt;
&lt;p&gt;라크로스 동아리 주장을 하는 사이 기계공학 복수전공도 시작했다. 수업시간이 너무 좋았다. 밤새며 과제를 해도 행복했다. 동아리의 그런 것들에서 자유로워질 수 있는 유일한 시간이었다. 결국 2016년 2학기에 중앙동아리로 인준하는데 성공하자 마자 긴장이 풀려 몸이 무너졌다. 혈뇨를 보기 시작하더니, 신기능이 떨어졌다. 중도 휴학을 했다. 무너지는게 당연한 일이었다. 맞지 않는 일을 하면서 학교생활 내내 긴장 상태로 지내는 것도 모자라, 안그래도 늦게 시작한 복수전공을, 학석사 연계과정으로 인해 초과학기가 제한된 상태에서 이수해내야 했기 때문이었다. 대학수학과 전공 역학수업과 설계를 동시에 들어야 하는 그런 식이었다. 그 와중에 그놈의 양심이 뭐라고, 족보를 보는 것은 스스로 절대 용납하지 못했다. 주에 3일씩 밤을 새는건 기본이고, 5일 연속으로 잠을 못자기도 했다. 그런 생활을 하면서 안 죽은 걸 감사히 여겨야 한다. 결국 학점관리에 실패하여 학석사 연계과정도 잘렸다.&lt;&#x2F;p&gt;
&lt;p&gt;몸이 어느정도 회복되고, 중앙동아리 인준 성공으로 주장도 넘겨줄 수 있게 되면서 장기간의 집권(?)으로 인해 하나도 정리되어 있지 않았던 동아리 업무를 문서화해서 일종의 인수인계 자료를 만들고 주장을 넘겨줬다. 그리고 이후부터는 밤샘을 가능한 피했다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;dedeukaes-baunseu&quot;&gt;데드캣 바운스&lt;&#x2F;h2&gt;
&lt;p&gt;어차피 학석사 연계도 잘렸겠다, 기계공학과 수업들을 그저 온전히 즐겼다. 수치해석 수업을 통해 프로그래밍에 흥미가 붙었다. 그런데 라크로스 경력이 아주 짧은 사람이 다음 주장을 맡게 됐다. 그래서 미국의 라크로스 훈련 드릴 공개본을 수집한 후 라크로스 훈련 계획을 작성하는 웹앱을 만들기로 했다. 그 목표를 가지고 2017년 여름, 코딩야학 2기를 수료했다. 반복적이고 불필요한 쿼리로 떡칠된 첫 작품이 탄생했다. 아 물론, 안쓴다. 그냥 재미로 만든게 되었다. 이후부터는 취미로 코딩을 하기 시작했다. 이것이 나중에 나에게 밥을 먹여줄 줄은 꿈에도 몰랐다. 혼자 계획표를 웹으로 작성해서 사용하기도 하면서, 소소한 프로젝트를 하며 실력을 갖춰나갔다.&lt;&#x2F;p&gt;
&lt;p&gt;새로운 꿈이 생겼다. Exoskeleton 로봇을 연구하는 것이었다. 그중에서도 군사용 근력증강 로봇에 관심이 있었다. 일단 이걸 하려면 대학원 진학은 필수라 생각했다. 하지만 난 대학원 생활을 모르므로, 한번 체험해 보기로 했다. 그래서 다짜고짜 KIST 인턴 연구원 채용공고를 보고 콜드메일을 하나 보냈다. 이런걸 연구하고 싶은데, 뭘 준비해 갈까요? 하고. 그 메일을 본 한 박사가 나에게 관심이 있으니 때가 되면 지원하라고 했다는 답을 받았다. 이후 졸업 직전, 인턴 지원 대상 자격이 생겼을 때 연구소에 지원했고, 합격했다. 기대에 부풀어 C언어도 미리 공부했다.&lt;&#x2F;p&gt;
&lt;p&gt;졸업 후 인턴 연구원으로 입사했다. 애석하게도, 내 연구 관심사와 관련없는 연구실에 채용되었다. 이름은 지능로봇연구단이지만, 연구실엔 로봇이 없었다. 그당시엔 소프트웨어 프로젝트를 하고 있었다. 내가 가고 싶었던 연구실의 박사가 해외에 체류하게 되었기 때문에 나에게 관심있는 다른 박사가 데려갔던 것이다. 설명을 들으니 재미는 있어 보여서 그냥 입사했다. 연구활동을 체험하는게 목적이기 때문이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;jwajeol&quot;&gt;좌절&lt;&#x2F;h2&gt;
&lt;p&gt;결과는 대실패였다. 유저테스트를 하게 되었는데, 데이터 쿠킹을 유도했다. 정해진 논문의 내용에 들어갈 근거자료가 필요한 것이지, 테스트의 결과가 중요한게 아니었다. 박사들은 아웃라이어로 데이터를 제외한 후, 충분한 설명을 덧붙일 것이라 했지만, 이미 신뢰가 깨진 시점에서 난 시야가 좁아졌다. 내가 실행한 실험이고 내가 낸 통계이므로 책임은 나한테 있다. 나름의 발악으로, 실험설계를 바꾸고, 테스트 시나리오의 task를 바꾸고, 프로그램의 일부 알고리즘까지 개선해서 실제로 유의한 결과를 얻어내서 해결했다.&lt;&#x2F;p&gt;
&lt;p&gt;지금 생각해 보면 박사들은 실제로 데이터를 제외하더라도 충분한 설명을 덧붙이긴 했을 것이라 생각한다. 굳이 조작하지 않아도 밥벌이와 성과에 크게 문제는 없을 사람들이기 때문이다. 하지만 그 당시의 혈기왕성한 나는, 사회초년생부터 불의라 생각하는 일에 타협하면 돌이킬 수 없을 것이라 생각했다. 타협은 동아리를 위해 했던걸 마지막으로 하기로 결심했기 때문에, 물러서지 않았다. 책임질게 없는 개인은 무서웠다. 자르든가!&lt;&#x2F;p&gt;
&lt;p&gt;19년 9월, 인턴 계약이 만료되어 연구소를 나왔다. 난 바로 연구의 꿈을 완전히 접어버렸다. 그리고 취업활동을 하려던 나에게 다시금 브레이크가 걸렸다. 요로결석이 생긴 것이다. 모든 일에 집중이 되질 않았다. 오히려 다행이었다. 막연하게 세상에 내던져진 사람은, 키를 어느 방향으로 둬야 하는지 모르던 참이었다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;gaebieo&quot;&gt;갭이어&lt;&#x2F;h2&gt;
&lt;p&gt;잠시 푹 쉬는 사이, 연구계에 대한 분노는 줄어들었고, 이성적인 상태로 돌아왔다. 그리고 지금처럼 회고의 시간을 가졌다. 할 줄 아는 것, 할 수 있는 것, 배울 수 있는 것을 나열했다. 할 수 있는 것으로서 취미로 하고 있던 개발이 불쑥 튀어나왔다. 하지만, 고작 만들 줄만 아는 나에겐 전공생들이 가진 것들이 없었다. 해킹에 관심을 가지게 되었다. 배우기로 했다. 내일배움카드에 대해 알게 되었고, 이를 이용해 아싸리 모의해커 취업반 과정을 신청했다.&lt;&#x2F;p&gt;
&lt;p&gt;코로나가 창궐했다. 딱 취업반이 시작되는 그 때. 그 시기, 2020년 2월이었다. 인턴을 하며 모아둔 돈을 갉아먹으며 해킹을 배우면서 동생과 함께 살고 있었는데 입이 늘었다. 음력설을 지내기 위해 기차를 타러 집을 나섰는데, 박쥐같이 말라 비틀어진 검은 새끼 고양이 한 마리가 차 밑에서 튀어나와 동생을 부여잡더니 다리를 타고 올라가 품에 안겼다. 살려달라는 것이었다. 눈과 코는 어디서 얻어맞아서 부어 있었고, 털도 듬성듬성했다. 뭐 어쩌나. 살려달라는데 살려야지. 데려와서 치료를 하기 시작했다. 마침 자취방 주인도 예전부터 동물을 키워도 된다고 먼저 이야기했었다. 주인집 강아지가 너무 시끄러워서 일종의 민원방지책으로 그랬던 것 같다.&lt;&#x2F;p&gt;
&lt;p&gt;그 고양이는 검은 턱시도였는데, 목, 흉부, 복부, 뒷발에 흰 털이 나 있었다. 까치가 생각났다. 이름을 까치로 지었다. 공교롭게도 설연휴에 만났기 때문에 잘 지은게 되었다. 사실 강력하게 자라라는 의미로 코로나로 할까도 했는데 주변의 만류로 포기했다.&lt;&#x2F;p&gt;
&lt;p&gt;병원비는 월에 50만원씩 날아갔다. 치료와 함께 예방접종들도 빠짐없이 했다. 좀 있으니 피부병이 옮았다. 수의사에게 사람도 치료받았다. 오해는 마라. 사람이 진료를 받은건 아니고, 그냥 고양이 피부병 샴푸를 사람이 써도 효과 있다는 꿀팁 정도 얻었다. 어느정도 건강해진 후 중성화 시술도 이어서 했다. 자연에서 도태된 고양이는 그렇게 이기적 유전자의 미래를 포기당했다. 도심의 인간과 함께 살기 위해서는 어쩔 수 없다. 시골이었다면 안했을거다. 미안하다. 수컷인데 아직도 애기같은 목소리로 운다. 내시를 만들어 버렸다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;yasaeng-jeogeunggi&quot;&gt;야생 적응기&lt;&#x2F;h2&gt;
&lt;p&gt;까치 설날에 찾아온 까치의 활약에 힘입어 통장의 잔고는 빠르게 줄어들었다. 결국 취업반 마무리 단계에서 보안계열 취업을 포기하고 돈을 선택하게 만들었다. 보안계열은 초봉이 KIST 인턴보다도 낮다. 하지만 본격적인 면접철 직전에 선수를 치고 입사제의가 온 극초기 스타트업에서는 KIST 인턴을 경력으로 보고 상향된 연봉을 제시했다. 고양이를 키우려면 집도 나에게 필요한 것보다 더 큰 곳으로 구해야 하고, 사료, 모래 등 부가비용이 발생한다. 스타트업 조기취업으로 마무리했다. 그리고 이 선택은 돌고 돌아 옳은 선택이 되었다. 극초기인 만큼, IR도 함께 다니면서 여러 모습들을 보고, 세상이 어떻게 돌아가고 있는지 알게 되었다. 대표님도 사업이 처음이었다. 첫 직원이라 여러모로 잘해줬다. 일은 너무 쉬웠다. 주로 기계공학과에서 배웠던 것들을 이용했다. CAD로 목적을 달성할 수 있도록 구조를 설계하고 시뮬레이션하면서 최적화하고, 3D프린터로 시제품을 출력하고 가공하는 것이 내 주업무였다. 그 외 IR자료 작성, 시장조사, 동영상 편집, 홈페이지 디자인, 개발 등 여러 일들이 있었지만, 동아리 주장을 오래 하며 별의 별 일을 다 해봤기 때문에 엉성한 수준이더라도 내 선에서 다 처리할 수 있었다. 시제품의 구조나 기획 등이 정리되며 부품의 성능을 최적화할 회로개발자를 추가로 채용했고, 난 회로개발과, 대표님이 하시던 IR 발표, 정부지원사업 지원서 초안 작성, 세무, 회계를 제외한 모든 일을 했다. 그렇게 해도 하루에 4시간이면 내 일이 끝나버렸다. 주 업무인 시뮬레이션과 기구설계 부분에서 수학적 규칙을 찾으면 바로 코드를 작성해서 자동화해버렸기 때문이다. 오히려 그러는 바람에 다른 잡무에 할애하는 시간의 비중이 늘어났다. 지루하고 심심했다.&lt;&#x2F;p&gt;
&lt;p&gt;난 퇴근 후에 해킹을 계속 공부하고 있었다. Capture The Flag(CTF) 형식의 가상 해킹게임을 플래이했다. 그러다가 Offensive Security사의 OSCP 자격증 과정을 알게 되었다. 유명 모의해커 자격증이었다. 땄냐고? 놉. 수업만 신나게 듣고, 지금의 회사로 이직하는 바람에 취득은 못했다. 스타트업에서 일한 지 9개월 째, 지루함을 이기지 못하고 있던 찰나, 일산으로 이사를 가게 되었다. 이제 퇴근 후의 여유시간 따위 존재하지 않게 되었다. 난 진정 좋아하는 일을 직업으로 가지기로 결정하고 지금 회사로 이직했다. 고생길이 열렸다.&lt;&#x2F;p&gt;
&lt;p&gt;사이드프로젝트도 시작했다. 사이드비즈니스 플랫폼을 만드는 사이드프로젝트이자 사이드비즈니스였다. 실제로 사업화를 진행하고 있었다. 투자는 얼마나 받을 것인지, 지분과 수익은 어떻게 배분할지까지 함께 이야기했다. 투자는 가능한 최소로 받아 내부인의 지분을 높이고 최소 비용으로 빠르게 안정적인 매출을 내는데 주력해야 한다는걸 알게 되었다. 투자를 가능한 거하게 땡겨서 기업가치 높게 평가받고 수습은 이후에 하려는 요즘 스타트업들과는 좀 달랐다. 원격으로 일하면서 좀 더 정리된 방식으로 어떻게 일하는지도 알게 되었다. 솔직히 지금 우리 회사보다 훨씬 잘 굴러갔다. 일은 이렇게 해야 하는구나. 하지만 사람들 간의 온도차, 책임의식의 차이를 극복하지 못하고 지쳐갔다. 사이드였기 때문에 과감히 그만뒀다. 라크로스 - 회사 - 사이드프로젝트 순으로 우선순위를 가져가고 있었는데, 바빠진 라크로스 일정으로 체력적 부담이 생기니 그 상황을 더이상 버틸 수 없었다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>회고록 - 8. 정착</title>
        <published>2024-08-25T00:00:00+00:00</published>
        <updated>2024-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/memoir-08/"/>
        <id>https://xanthorrhizol.github.io/posts/memoir-08/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/memoir-08/">&lt;p&gt;처음으로 소개한다. 크래프트테크놀로지스. 지금 내가 몸담고 있는 회사이다. 난 AI 강화학습 에이전트를 이용한 주문집행 소프트웨어를 주 라인업으로 가진, AI Trading Solution 부서의 개발팀에 있다. 입사 당시엔 AXE라는 이름으로 있었다. 도끼 아니다. 현재 3년을 넘겼다.&lt;&#x2F;p&gt;
&lt;p&gt;내가 입사할 때 이 회사는 30명 규모의 회사였다. 잠시후, 소프트뱅크에서 대규모 투자가 들어왔다. 인원이 80명으로 급증했다. 물론 우리팀은 예나 지금이나 비슷한 규모를 유지중이다. 회사에서 대형 프로젝트를 하기위해 팀이 신설되고 공격적인 채용이 진행됐던 것이다. 처음엔 기대했다. 그 대규모 프로젝트에서 우리팀은 나중에 이런걸 하고 있겠지. 물론 그 프로젝트는 실패했다. 우리 팀은 그냥 평온하게 하던거 하고 있다. 회사는 다시 대박을 칠 무언가를 기다리며 여러 시도들을 하고 있다.&lt;&#x2F;p&gt;
&lt;p&gt;우리 팀은 팀의 제품을 증권사에 납품하는 형식의 사업을 하고 있었다. 여타 기술기업들이 의례 그렇게 실수하듯, “좋은거 만들어두면 쓰겠지&quot;라는 마인드가 좀 있었다. 제품과 니즈는 충돌했고, 우리에겐 “이럴거면 왜 AI를 도입하려는거지?”하는 불만이 좀 있었다. 하지만, 을은 갑이 원하는걸 해줘야 하니까, 일단 들어줬다. 결론부터 말하면 잘했다. 여기서 들이받았으면 제품은 영영 제자리걸음이었을 것이다. 강력한 성능의 못쓰는 물건으로.&lt;&#x2F;p&gt;
&lt;p&gt;제품은 현재 4.0버전까지 와 있다. 내가 입사할 당시는 1.0에서 2.0 버전으로 넘어가던 시기였다. 1.0의 성능에 만족한 고객사와 대형 프로젝트로 2.0을 기획하고 개발을 진행했다. 난 이 버전을 설치하고 세팅하는 시기에 입사했다. 해킹 공부로 얻은 인프라쪽 지식과 개발능력을 동시에 가지고 있었기 때문에 입사할 수 있었다. 딱 그런 사람이 필요한 시기였기 때문이다. 하지만 온보딩 시스템이 없는, 사수조차 없는 이 팀에서는, 프로그램이 뭘 하는 것인지 등 소개 문서 하나 없이 다짜고짜 일부 마이크로서비스의 코드를 분석하고 리펙터링하라는 지시가 내려왔다. 난 트레이딩에 대해서는 겉핥기 식으로 잠시 주식투자를 해본게 다였기 때문에, 프로그램이 뭘 하는지 이해하려니 막연하고 막막했다. 심지어 마이크로서비스 시스템은, 서비스의 목적을 더 알기 어렵게 만들었다. 삽질을 하기 시작했다. 그나마 설치 업무에 적응하는게 더 수월했다. 설치업무를 하면서, 시스템을 파악하여 코드베이스를 파악해나갔다.&lt;&#x2F;p&gt;
&lt;p&gt;2.0은 한가지 큰 과제가 있었다. 초대형이라는거다. B2B2C를 목표로 하고 있었다. 최신 개발 트렌드와 기술스택도 대거 도입했다. 2021년이었던 당시에 이미 Rust를 도입했고, 펄서를 메시지큐로 도입하고, 쿠버네티스를 도입하고, IaC도 하겠다며 helm과 Terraform까지 이용했다. 그것도 증권사의 폐쇄망 Cloud에서! 천재들의 세계는 엄청나군! 난 그저 그걸 내것으로 흡수하고, 그 원대한 계획을 실제로 실현해내는데 집중했다. 2.0 막바지에 갔을 땐, 모르는건 많지만 겁먹진 않는 개발자가 되어 있었다. 가장 비효율적인 곳에 들어왔기에 가능한 성장이였다. 이런 기회는 이제 주어지기 어려울 것이다. 회사는 더이상 이런 삽질을 기다려주지 않는다. 이제 성과를 내야 하는 시기이다. 나 또한 이런 개고생을 경험할 기회를 줄 생각은 없다. 버틸 확률이 10%일 것이다. 만든 사람들도 나중에 다 퇴사했을 정도니까. 진짜 중간에 별의 별 생각을 다했다. 무사히 넘겼으니까 이정도로 이야기할 수 있는 것이다. 기술이 어려운게 문제가 아니다. 설치 마무리 후 장애로 인해 매일같이 오는 긴급전화와, 긴급 출장업무가 문제였다.&lt;&#x2F;p&gt;
&lt;p&gt;초기 B2B2C로 기획되었던 프로젝트는 시간이 지나며 B2B로 축소됐다. 동시작업 10000건 목표는 없던 일이 되었다. 10000건을 감당하기 위해 만들어진 제품은 B2B에서 그냥 돼지가 되어버렸다. 심지어 먹이는 많이 먹는데 고기는 팔 곳이 없는 그런 돼지였다. 2.0 프로젝트의 주역들은 모두 퇴사했다. 충원은 이보다 덜했다. 프로젝트가 축소되었으니 당연한 수순이었다. 이후 잠시 팀을 맡던 팀장도 퇴사했다. 유지보수하는 입장에서 너무 힘들었다. 여기저기 함정이 도사리고 있고, 커다란 사이즈 만큼 버그도 많았다. 천재 개발자들이 만든 힙한 야심작은, 아무리 그들이 천재였어도 허점이 많았다. 당연하다. 버그 없는 프로그램은 없다. 매일 오전 카톡이 울리면 고객사 연락인가 하고 스트레스를 받으며 서비스를 안정시키기 위해 고군분투했다.&lt;&#x2F;p&gt;
&lt;p&gt;2.0의 주역들과 그 다음 팀장이 모두 퇴사하고, 팀장 제의를 강력히 거절했다. 동아리에서의 그 경험은 팀장직에 대한 본능적인 공포로 다가왔다. 다시는 그런거 안하기로 했다. 팀에서 조용히 계시던 시니어 개발자가 팀장이 되었다. 대신 나에게 많은 권한을 주셨다. 시니어 팀장님은 혼자 다른 언어를 쓰고 계셨기 때문이다. 당시 3.0 프로젝트가 진행중이었고, QA가 입사하며 버전 및 품질관리도 시작했다. 쓸데없는 중복을 버리고 안정성을 높이는게 3.0의 목표였다. 팀장님은 중복된 기능을 가진 세 개의 서비스를 통합했다. 3.0 프로젝트는 커졌다. 난 내가 담당하던 마이크로서비스도 완전 새로 개발했다. 그리고 아싸리 쓸데없는걸 다 들어내기로 했다. 인프라도 불필요한 것들을 다 날려버렸다. 이제 내가 아니어도 기본적인 설치나 디버깅 업무가 가능하게 되었다. 맞다. 제발 이 지옥같은 업무를 좀 분산시켜 달라는 아우성같은 것이었다. 그리고 그 시기에 새로 들어온 매우 협조적인 팀원이 간소화된 제품 설치 과정을 따라다니며 배우면서 설치 업무를 돕고자 부단히 노력했다.&lt;&#x2F;p&gt;
&lt;p&gt;3.0 버전으로 넘어가면서, 일에 여유가 좀 생겼다. 리서치팀과 함께 새로운 프로젝트를 진행했다. 매일 회사에 쌓이고 있는 데이터를 분석해서 우리 팀의 모델 학습에 사용할 수 있도록 기존에 사용하던 고가의 구매 데이터 형태로 변환하는 프로젝트였다. 이것이 진행되면, 데이터 구매 비용 부담으로 인해 잠시 멈췄던 학습을 다시 재개할 수 있었고, 타 거래소로의 확장도 용이해질 것이었다. CTO님의 퇴사 전 인수인계로 이 프로젝트에 대한 기획을 넘겨받았고, 무사히 개발해서 사용중이다.&lt;&#x2F;p&gt;
&lt;p&gt;시니어 팀장님이 이민을 가면서 퇴사하고, 잠시 팀장을 하다가 퇴사했던 팀장이 재입사했다.&lt;&#x2F;p&gt;
&lt;p&gt;다음은 4.0 프로젝트에 돌입했다. 4.0의 목표는 코드의 가독성, 유지보수성이다. 여기에 모든 기능의 완전한 이중화까지 지원한다. 개발언어를 Rust로 통일하고, 중앙화할 수 있는 것을 모두 공통 라이브러리로 관리한다. 모노리포 구조로 말이다. 코딩컨벤션도 정해졌다.&lt;&#x2F;p&gt;
&lt;p&gt;그러던 중 또다른 문제를 함께 해결해야 했다. 4.0 프로젝트 도중 DMA 프로토콜을 병행해서 개발해야 하게 되었다. 일정이 겹쳐서 끼어들어온 것이다. 하지만 난 허리 디스크가 파열되었다. 하지만 대체가 없어서 재택근무로 전환해서 마지막까지 프로젝트를 마무리해야 했다. 힘들긴 하다. 집에 갇혀서 일하는 느낌이다. 그 상태로 새벽 3시까지 작업을 하기도 했다. 하지만 그렇게 하라고 시킨 사람은 없다. 근데 하지 않으면 일정을 맞출 수가 없다. 뭐, 언젠간 지나갈 일이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>회고록 - 9. 라크로스</title>
        <published>2024-08-25T00:00:00+00:00</published>
        <updated>2024-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/memoir-09/"/>
        <id>https://xanthorrhizol.github.io/posts/memoir-09/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/memoir-09/">&lt;p&gt;대학 졸업 후, 나에게 좌절을 선사했던 연구소의 생활은 득과 실이 확실했다. 라크로스 연습을 하기엔 최고였다. 야외 스쿼시장에서 월볼(벽에 공을 치며 던지고 받는 것)이 가능했고, 웨이트 시설도 공짜였다. 필드도 있었다. 동아리 인준이니 주장이니 하는 부담도 없었다. 그 시기에 실력이 많이 늘었다. 마치 밥먹고 약을 먹듯이 퇴근하면서 연습을 했다. 연구실에서 받은 스트레스의 해방구이기도 했다. 대학원생들이 고강도 크로스핏을 왜 많이 하는지 알 것 같았다.&lt;&#x2F;p&gt;
&lt;p&gt;2019 아시아 환태평양 선수권대회에서는 일본에 사는 두 선수와 함께했다. 전설적인 골리와 탑 레벨 수비수였다. 그리고 졸업 후부터 심심해서 다니던 토요라크로스의 모임장이자, 현재 서울진도스 팀의 시초가 된 사람과, 한국외대 여자팀을 창단하고, 호주에 유학까지 가서 라크로스 선진국의 문화를 경험하고 돌아온 사람을 만났다. 대학 졸업 후 이 대회를 마지막으로 그만두려 했던 라크로스는 그렇게 수명이 연장됐다. 오프데이 때 그들이 함께 이야기하던 비전인 “즐거운 라크로스”를 마지막으로 믿어보고 싶었다. 연구소를 다니며 자유인으로서 즐긴 라크로스 또한 생각보다 즐거웠기 때문이다. 이제 즐길 수 있구나. 서울진도스 설립에 함께했다. 역시나 즐거웠다.&lt;&#x2F;p&gt;
&lt;p&gt;대학 생활을 통째로 앗아간 이 애증의 스포츠는 지금 삶에 있어 주를 차지했다. 난 회사에도 라크로스가 1순위라고 대놓고 밝혔다. 면접 자리에서 대표팀 일정으로 인해 휴가를 길게 쓸 수 있다는 사실에 대해 미리 이야기하고 허락까지 받아놓았다. 대신 이런 사례가 나쁜 사례가 아닌 좋은 선례로 남게 하고자 고생스러운 업무도 마다하지 않고 기한에 목숨걸고 책임감을 가지고 일했다. 관성같은 것이었다. 대학생 때 라크로스를 하는 내내 책임자 자리에 있었다보니, 행동 하나 하나 함부로 하기 어려웠는데, 이게 습관이 되었다. 특히나 생소한 스포츠 특성 상, 내 행동이 라크로스를 하는 이들을 대표하게 되기 때문에, 틀린 것도 아니었다. 나를 비롯, 선배들이 나쁜 선례를 남기면 후배들은 라크로스에 열정적이었을 수록 사회에서 힘들어질 것이라고 생각했다. 라크로스가 아니였으면 나도 가벼운 마음으로 대충 늑장을 부리며 일하고, 고생길일 것이라는 팀내 SRE 역할을 자처하지도 않았을 뿐더러, 팀에서 대퇴사 바람이 불며 타 회사에서 오퍼레터를 받았을 때도 바로 이직했을 것이다. 대규모 트레픽과 SaaS에 대한 기대를 충족하며, 파격적인 연봉인상을 얻어내며 말이다. 물론 오퍼레터보다는 조금 적지만, 회사에서는 이직하는 수준으로 연봉을 파격적으로 올려줬다. 고군분투하는 과정에서 서비스를 실제로 판매할 수 있는 수준으로 개선하고 안정화한 경험도 얻었고, 기술독재에 대한 경각심도 얻었다. 이곳은 당장 어렵더라도 언젠간 하는 만큼 대가를 얻는 곳이구나. 운좋게도 나름 좋은 선택이 되었다. 아, 물론 요즘은 좀 막나가고 있다. 에너지가 고갈되었기 때문이다. 그저 풀린 정신으로 실수나 하지 않을까 걱정이다. 그래서 더더욱 제대로 쉬기로 했다.&lt;&#x2F;p&gt;
&lt;p&gt;2022년, 코로나로 무기한 연기됐던 월드컵이 드디어 열렸다. 역대 최악이었다. 우리가 코로나를 핑계로 멈춰있는 사이 다른 나라들은 앞으로 나아갔다. 20점차 가까이 이기던 중국에게 조차 패배했다. 우리는 멈춰있는 수준이 아니라 오히려 후퇴했다. 그와중에 난 허리에 갑자기 극심한 통증을 느끼며 의무실로 향하게 되었다. 하지만 그곳에서도 마취 파스나 온찜질 이외에 해줄 수 있는 것이 없었다. 디스크 파열일지도 모르는 증상이었기 때문이다. 앓다가 좋아졌다를 반복하면서 후회 가득한 대회를 치렀다. 귀국 후 신경차단술을 받았다. 디스크 파열은 아니였지만, 내 허리는 이미 한 곳이 작살난 채 오래되어 있었다. 그곳을 시작으로 차례차례 작살날 것이라 했다. 이미 치료는 늦었고, 언제 은퇴할지 모르니 마음의 준비를 하라고 했다.&lt;&#x2F;p&gt;
&lt;p&gt;난 소속팀인 서울진도스에서 라크로스 인생 2막을 그저 즐겼다. 이미 대학교 졸업 이후부터는 플러스 알파를 지내고 있었던 것과 다름없다. 어차피 마지막이다. 후회없이 즐기기로 했다.&lt;&#x2F;p&gt;
&lt;p&gt;서울진도스의 “즐거운 라크로스”라는 추상적인 비전은 생각보다 강력했다. 그리고, 이곳엔 쓸 곳엔 쓰자는 진취적인 사람들이 모였다. 이왕이면 더 좋은 구장을 빌리려 하고, 양질의 훈련을 추구하고, 코치도 모셨다. 코치들 또한 적은 사례비에도 불구하고 열정이 넘쳤다. 코치의 비전은 “라크로스다운 라크로스”였다. 난 이들에게 항상 감사하다. 자칫 잘못하면 대학생활을 통째로 앗아간 라크로스를 버림과 동시에 라크로스를 시작한 것에 대한 후회로 가득한 삶을 살 뻔 했는데, 즐거운 라크로스를 경험한 덕에 그런 결말은 맞이하지 않을 수 있었다. 행운이었다.&lt;&#x2F;p&gt;
&lt;p&gt;2023년부터는 라크로스 선진국인 일본에서 매년 개최되는 오키나와 오픈에 참가하게 되었다. 이 대회를 기점으로, 서울진도스는 한국에서 따라올 팀이 없게 되었다. 이후 모든 국내 리그를 우승하고 있다. 오키나와 오픈에 그저 참여하는게 아니라, 그 대회에서 성적을 거두기 위해 그간의 대표팀 준비보다도 더한 열정을 퍼부었기 때문이다. 나 또한 이 대회에서 사상 최고로 많이 늘었다. 아니 곧 은퇴할 사람이 아쉽게 왜이러나…&lt;&#x2F;p&gt;
&lt;p&gt;2024년 오키나와 오픈에서는 디펜스 주장을 하게 되었다. 다시는 하지 않기로 했을 터인 주장이었는데, 그냥 결정되어 통보되는 바람에 거절할 타이밍을 놓쳤다. 내정을 다른 운영진에게 맡겼던, 성격에 맞지도 않는 바깥일이나 꾸역꾸역 하던 그런 주장 경험만 있었기 때문에 꽤나 막막했다. 사실 그런 주장 경험은 나에게 트라우마와 다를 바 없었다. 다행히도 함께 주장을 맡았던 두 명이 이 약점을 다 커버해 줬다. 주변에게 큰 기대치를 가지고 팀을 이끄는 성격을 가진 한 명은 팀의 동기 수준을 높게 가져갈 수 있도록 이끌었다. 언변이 좋고 성격도 둥글둥글한 다른 한 명은, 갈등이 빚어질 수 있는 상황들을 잘 해결하고 각종 공지 내용도 유도리 있게 잘 작성했다. 팀원 간의 조화를 이끄는 일에도 일가견이 있었다. 난 그런 능력들은 없었다. 장비 담당으로서 무슨 일이 있어도 차를 끌고 장비를 운동 장소로 가져가는게 내 임무였다. 그리고 난 그런 단순하고 몸만 좀 고생하면 되는 역할이 참 좋았다. 난 타인에게 기대를 거는 타입도 아니다. 말을 조리있게 즉석으로 만들어내지도 못한다. 그저 글을 쓰는 것이 그나마 가능했으므로, 훈련이 끝나고 귀가하면 그날의 디펜스 훈련중 들었던 피드백을 요약해서 업로드하고, 꾸중을 잔뜩 들었던 디펜스 팀원들에게 그래도 잘한 것, 발전한 것이 있음을 기억케 해주기 위해 나름 생각나는 잘한 점들도 피드백에 추가했다.&lt;&#x2F;p&gt;
&lt;p&gt;2년간 오키나와 오픈에 참여하면서, 가장 큰 행복이 찾아왔다. 드디어 미래를 맡길 만한 골리 후배들이 생겨나기 시작한 것이다. 2023년 대회에선 불시에 당할 은퇴에 대한 두려움이 줄어들기 시작했다. 선구안과 눈과 손의 협응이 좋고 안정적이며 힘도 좋은 골리가 나타났다. 특유의 안정성을 무기로 미래에 강력한 골리로 성장할 수 있을 것이다. 2024년 대회에선 체구가 작고 힘은 좀 떨어지지만, 승부욕이 강하고 이에 맞게 노력을 아끼지 않는 선수가 나타났다. 노력은 가장 강력한 재능이다. 그리고 다리에 시퍼렇게 든 멍을 보고도 그저 공 하나 막았다며 좋아하는 모습을 보며 과거의 자신이 떠올랐다. 후에 강력한 멘탈을 장착한 선수가 될 것이다. 이 친구는 지금 일본으로 교환학생을 가서 그곳의 팀에 들어가 거의 매일 연습을 하고 있다. 강력한 기본기와 멘탈을 가지고 돌아올 그날이 기대된다.&lt;&#x2F;p&gt;
&lt;p&gt;그리고 지금은 2025년 아시아-환태평양 권역에서 월드컵 출전권을 놓고 겨루는 퀄리파이어 대회를 준비중이다. 난 지금 허리 디스크 파열로 인해 장기간 휴식중이다. 스트레스가 생각보다 크다. 출전권 따야하는데. 하지만 이번에 신우신염을 얻어맞고, 폐에 물이 차고, 코로나까지 걸리면서, 집중해서 휴식 기간을 빠르고 밀도 높게 가져가기로 했다. 지금은 완전히 마음을 놓고 쉬고 있다. 그게 제일 빠른 길이다. 버텨라.&lt;&#x2F;p&gt;
&lt;p&gt;디스크가 호전되며 일상을 조금씩 회복하고 병치레로 무너지기 전까지의 기간 사이에, 이곳에서 또 한 명의 골리를 만났다. 골리는 이번이 처음이었다. 하지만 운동신경이 매우 뛰어났다. 공을 던지는 것만 봐도 몸을 사용할 줄 안다는 것이 눈에 바로 보였다. 빠르게 성장할 것임은 틀림없다. 운동 능력은 문제가 없고, 오히려 몸에 힘을 빼고 긴장을 풀고 머리를 비우는 것이 주된 과제가 될 것이다. 과거 힘만 넘쳐서 튀어다니던 나처럼 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;그리고 또 한 명의 골리 지망자가 나타났다. 아직 장비가 없어서, 수비수 훈련을 하면서 훈련을 기록하고 있는 선수가 있었다. 그 습관 자체가 바로 미래의 성장을 암시한다. 기록은 누적을 만들기 때문이다. 나 또한 과거 훈련 내용과, 그날의 멘탈 등을 기록한 노트가 있다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>회고록 - 10. 미래</title>
        <published>2024-08-25T00:00:00+00:00</published>
        <updated>2024-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/memoir-10/"/>
        <id>https://xanthorrhizol.github.io/posts/memoir-10/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/memoir-10/">&lt;p&gt;퀄리파이어에 대한 걱정은 산더미지만, 지금 난 나름 행복하다. 한국의 골문을 지킬 후배들이 4명이나 나타났다. 덕분에 난 은퇴 다음의 스텝을 고민하고 있다. 내가 할 수 있는 것은 무엇인가.&lt;&#x2F;p&gt;
&lt;p&gt;사실 난 내가 나이가 더 많고, 이미 더 성공해 있었으면 좋겠다는 생각을 자주 한다. 오키나와 오픈을 시작으로, 대회 준비에 집중하기 위해 퇴사까지 감행하는 수준의 열정있는 이들이 우후죽순 생겨나고 있다. 하지만, 그런 열정에 대한 보답을 해줄 수 있는 사람이 지금은 없다. 그들 스스로 헤쳐나가야 한다. 사실 그들이 퇴사할 때 나도 퇴사하고 싶었다. 하지만 이미 몸이 맛이 가고 있는 지금, 은퇴가 가까워지고 있음을 느끼고 있었고, 은퇴 후에도 기여할 수 있는 사람이 되기 위한 준비를 하는 것이 더 맞다고 생각했다.&lt;&#x2F;p&gt;
&lt;p&gt;꽤 많은 동료들은 지금 사회로 나오기 위해 알을 까는 시기에 있다. 불경기라서 계속 눈에 밟힌다. 나에게 이들을 지원하고 끌어줄 수 있는 더 큰 힘이 있었더라면 하는 아쉬움이 크다. 난 그런 역경들을 좀 일찍 맞이해서 괜찮은 경제 사이클 위에서 나름의 연착륙을 했지만, 이들은 지금 불경기 사이클 위에서 겪고 있다. 물론 모두들 강하고 능력있는 사람들이고, 충분히 이겨낼 사람들이다.&lt;&#x2F;p&gt;
&lt;p&gt;사회의 성인으로 성장하고 독립해서 자리를 잡기 위해 필히 수반되는 일들은 언제나 더럽게 힘들고, 불안하고, 자존심이 상하고, 우울한걸 알기에 좀 측은하다. 내가 지금 할 수 있는건 그저 그들이 안정될 때까지 믿고 기다리면서, 말하고자 하는걸 듣고, 말하기 싫은걸 묻지 않으며, 그들이 하고자 하는 일을 능력껏 돕는 것 뿐이다. 마치 내가 대학교 생활을 버텨낼 수 있도록 도와줬던 수많은 사람들처럼 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;난 지금 가진건 별로 없지만, 어차피 라크로스에 인생을 빼앗긴 김에, 살면서 할 수 있는 최대를 해보고 싶다. 빼앗긴 인생이라도, 그 인생이 의미를 가지면 그만 아닌가. 그 의미를 준게 지금 동료들이다. 내가 가진걸 이용해서 내가 원하는 세상을 사고 싶다. 인간은 죽지만, 세상은 남는다. 내가 원하는 세상을 사려면 가진 것이 많아야 한다. 그러려면 많이 가져야 한다. 어떻게 많이 가질 수 있는지는, 머리로는 대충 안다. 이룰 줄 몰라서 문제일 뿐. 일단 월급쟁이로는 불가능하다. 하지만 뭐, 그건 나중에 가서 생각할 예정이다. 지름길따윈 없다. 지금은 그저 지금 할 수 있는 것을 하고 있다. 일단은 후배들의 열정을 사는 일을 시도중이다. 물론 선택은 후배의 몫이지만, 약간의 염원과 기대를 담아.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>역경 탈출법</title>
        <published>2024-08-22T00:00:00+00:00</published>
        <updated>2024-08-22T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/escape-from-adversity/"/>
        <id>https://xanthorrhizol.github.io/posts/escape-from-adversity/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/escape-from-adversity/">&lt;h2 id=&quot;seoron&quot;&gt;서론&lt;&#x2F;h2&gt;
&lt;p&gt;난 삶의 등락이 뚜렷한 편이다. 그리고 지금은 낙의 시기에 있다. 건강이 무너지면서 브레이크가 제대로 걸렸다. 파열된 디스크만 회복하면 되는 줄 알았는데, 신우신염이 온 것도 모자라 폐에 물이 차더니, 코로나까지 꼽사리 껴서 협공을 당하는 중이다. 가히 나당연합군에 뚜드려맞는 고구려의 신세와 유사하다 할 수 있겠다. 이정도 신호는 모든 것을 멈추고 쉬어가라는 신호다. 물론 이런 낙의 시기는 처음이 아니다. 고등학교 때 한 번, 대학교 때 한 번, 사회초년생 때 한 번, 이미 총 3번 겪었고, 지금이 4번째다. 때문에 어떻게 헤쳐나가야 하는지 이미 알고 있다. 하지만 그와 별개로 역시 힘들긴 더럽게 힘들다. 뭐 그래도 이정도인게 어디인가. 암같은 뒤끝 지독한 질병이 아님에 감사하다.&lt;&#x2F;p&gt;
&lt;p&gt;난 보통 고난의 시기를 맞이하는 시점을 스스로의 선택이나 정신적 번아웃으로 맞이하기보다는, 몸이 못버텨서 얻어맞는 방법으로 맞이한다. 정확히는 인식을 그 시점에 한다는 것이 맞을 것 같다. 고등학교땐 위출혈, 대학교땐 신기능 저하와 혈뇨, 사회초년생땐 요로결석, 이번엔 신우신염이 그 시점이었다. 디스크 파열은 시발점이긴 하지만, 이때까지 난 완전히 낙의 시기라고 인식하지 못하고 있었다. 이때까지 그냥 쉬면 다 해결됐기 때문에, 그냥 두번째 요로결석처럼, 슥 지나가는 기우인 줄 알았다.&lt;&#x2F;p&gt;
&lt;p&gt;매번 이렇게 건강 문제로 무너지다보니, 하루이틀 사이에 급격히 안좋아진다. 대신 몸만 회복되면 알아서 잘 회복되는 편이다. 그리고 몸이 회복될 때 진행하는 일련의 과정이 항상 있었다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;1-sarameul-mannaji-anhneunda&quot;&gt;1. 사람을 만나지 않는다.&lt;&#x2F;h2&gt;
&lt;p&gt;안 괜찮은데 괜찮다고 하는 것도 일이다. 사람을 만나면 필히 그 이를 안심시키기 위해 에너지를 쓰게 된다. 그렇다고 안 괜찮다고 떠벌리고 다니는 것도 스스로에게 스트레스로 다가온다. 주변에도 스트레스를 전파하는 일이 될 수 있기 때문이다. 가장 가까운 몇몇에게 안 괜찮음을 알리고, 이후부턴 말을 아끼고 고독에 익숙해져야 한다. 그리고 고독을 즐기는 것은 후에 자신의 능력이 될 것이다. 내가 군자녀로서 잦은 이사와 이별을 유년시절부터 겪어 오며 단련되었듯 말이다. 혼자 있는 시간에 엄습하는 불안은 실체가 없고, 근거도 없고, 쓸모도 없다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;2-saenggaghaji-malgo-momi-iggeuneun-daero-saenghwalhanda&quot;&gt;2. 생각하지 말고 몸이 이끄는 대로 생활한다.&lt;&#x2F;h2&gt;
&lt;p&gt;자고싶으면 자고, 먹고싶으면 먹고싶은걸 먹는다. 억지로 생활 습관이니 뭐니, 보양식이 어쩌니 영양제가 어쩌니 요란하게 챙기지 않는다. 그런거 알아보고 계산하는 것이 더 스트레스다. 몸은 필요한게 뭔지 스스로 알고 있다. 이상하게 땡기는 음식을 놓치지 않고 먹는다. 난 이번에 아프면서 바깥 음식이 별로 땡기지 않았다. 몸이 알아서 염분을 거부하고 있었던 것이다. 그러더니 항생제를 먹기 시작하고 신우신염 증상이 완화하니 뜬금없이 닭강정이 땡기고 식욕이 올랐다.&lt;&#x2F;p&gt;
&lt;p&gt;보통은 자신을 망가뜨린 원인은 휴식을 하면서 차단되므로 이미 충분한 조치가 이루어졌다. 보통 사람의 의지력으로는 몸을 완전히 회복 불가능한 죽음의 사이클로 올려놓기 어렵다. 왠만하면 회복 사이클이 해결해 준다. 각종 생각은 버리고, 그저 조금 긴 감기에 걸렸다 생각하며 꿀같은 휴식을 온전히 즐겨야 한다. 자신을 믿어야 한다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;3-jibjungryeogeul-hoebogyi-ceogdoro-samneunda&quot;&gt;3. 집중력을 회복의 척도로 삼는다.&lt;&#x2F;h2&gt;
&lt;p&gt;집중력이 크게 저하되어 있는 상태일 것이다. 하지만 이런 위기가 찾아온다는 것은, 그간 열심히 살았기 때문이다. 그렇게 살아왔던 관성에 의해 앞으로도 하고 싶은 것들이 산더미인 상태일 것이다. 하지만 몸상태는 이를 받쳐주지 못한다. 떨어진 집중력이 본인의 의지력이라 오판해서 자괴감이 들기 십상이다. 하지만 초조해 하지 않아도 된다. 이야기했다시피, 생각을 멈춰야 한다. 어차피 당장 안될거다. 악담이나 저주가 아니다. 팩트다. 어차피 안될 일에 스트레스 받는 것은 어리석은 짓이다. 그 일은 회복되고 나서 해도 전혀 늦지 않는다. 회복을 빠르게 하는 편이 더 이득이고, 회복을 가속하기 위해서는 불필요한 스트레스를 차단해야 한다. 대신 자신이 평소 좋아하고 재밌어하는 일들 중에서 기한없는 목표를 하나 정해 놓고, 하고 싶을 때 툭툭 건드려 보며 집중력을 체크하면 현재 상태를 진단할 수 있다. 스트레스도 받지 않으면서, 언제 자리를 박차고 일어나야 하는지 알 수 있다. 어느날 갑자기 의욕이 돋으면서 일을 손에 잡더니 시간 가는 줄 모르고 집중하고 있는 상태에 도달한다면, 몸은 스트레스를 다시 받아들일 준비가 되었다는 신호를 주고 있는 것이다. 그 일에 집중하다 보면 어느새 일상을 찾아가게 된다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;4-insaenge-daehae-hoegoreul-jinhaenghanda&quot;&gt;4. 인생에 대해 회고를 진행한다.&lt;&#x2F;h2&gt;
&lt;p&gt;최고 속력을 내기 위해선 앞만 보고 달려야 한다. 때문에, 멈춰선 지금은 뒤를 돌아볼 절호의 기회이다. 이럴 때가 아니면 언제 뒤를 돌아보나. 그리고 이 과정을 통해 인생의 터닝 포인트가 생긴다. 회고를 진행하다 보면, 그동안 놓치고 있었던 것, 인생의 우선순위 등이 정리된다. 우선순위가 명확해지면 앞으로의 일에 있어 판단 기준을 세우는데 큰 도움이 된다. 때로는 성격까지 크게 변화하기도 한다. 회고는 언제 진행하면 되냐고? 3번이 힌트를 줄 것이다. 어느날 갑자기 하고싶어지면 하면 된다. 자신을 믿어라.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;hoebog-hu&quot;&gt;회복 후&lt;&#x2F;h2&gt;
&lt;p&gt;회복이 되었다는 판단은 스스로 할 수 있을 것이다. 일상으로 복귀하고, 하고싶은 일을 하는데 거리낌이 없는 상태가 바로 회복이 완료되었다는 증거이다. 하지만, 비슷한 고난은 여러번 찾아온다는 것을 기억하고 있어야 한다. 사람이 사는 방식은 쉽게 변화하지 않는다. 내가 매번 건강 이슈가 터져서 더이상 앞으로 갈 수 없는 시점이 되어야 멈춰서는 것처럼, 같은 방식으로 또다시 고난이 찾아올 것이다. 왜 또 이런 시련이 주어지는가에 대해 한탄하지 말고, 그냥 “아 또 쉴 때가 됐군!” 하고 회복 사이클을 돌려라. 원래 반복된다. 그리고 그 때 제대로 쉬고 싶다면, 평소에 열심히 살아서 이럴 때 제대로 쉴 기회를 얻을 수 있도록 준비를 해두는걸 추천한다. 직장인으로서는 이번이 처음인데, 디스크 파열이라는 신호탄이 터졌을 때 팀에서 비로소 나에게 몰려 있던 버스펙터를 높이기 위한 급진적인 개혁이 이뤄졌다. 좀 늦어서 고생이긴 했지만, 그래도 그 개혁에 힘입어 이번에 완전히 무너졌을 때 휴가를 마음놓고 쓸 수 있었다(심지어 돌발적으로). 2년 근속 때 받는 리프레시 휴가를 라크로스 국제대회 때 사용하겠다고 1년 넘게 안쓰고 아껴 뒀던 것도 이번에 큰 도움이 됐다. 국제대회는 연차로도 충분하지만, 혹시 모를 일에 대비해 계속 쟁여뒀었다. 그 리프레시 휴가, 정말 리프레시하기 위해 사용하고 있다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;i-geuli-olrawassdaneun-geoseun&quot;&gt;이 글이 올라왔다는 것은?&lt;&#x2F;h2&gt;
&lt;p&gt;맞다. 난 지금 무사히 회복 중이고, 방금 집중력 회복이라는 강력한 신호를 받았다. 현재시각 새벽 3시 43분이다. 잠을 자다가 불편한 호흡, 흉통, 기침으로 뒤척이던 중, 갑자기 떠올라 글을 써내려갔다. 일단, 지금 매일밤 찾아오던 발열 증상이 멎었다. 잠을 청할 때만 해도 열이 났는데, 지금은 열이 내렸다. 이 시간에 쉬어도 모자랄 판에 왜 각잡고 글을 쓰냐고? 몸이 이끄는 대로 했다. 어차피 숨이 불편하고 열이 나서 잠을 잘 수 없는 상태였다. 이제 열도 내렸으니 다시 잠을 청하고, 눈떠지면 일어날 것이다. 이번 휴가는 이번주 내내이다. 강력한 회복 신호는 받았지만, 꿀같은 휴가를 더 신나게 누려서 확실히 회복할 생각이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Arch Linux를 사용할 때 각오해야 하는 것</title>
        <published>2024-07-09T00:00:00+00:00</published>
        <updated>2024-07-09T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/be-ready-to-use-arch/"/>
        <id>https://xanthorrhizol.github.io/posts/be-ready-to-use-arch/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/be-ready-to-use-arch/">&lt;p&gt;오늘 아침에, 리눅스를 업데이트했다. 그리고 재부팅 하는 순간, 모니터 하나가 죽어버림.&lt;&#x2F;p&gt;
&lt;p&gt;리눅스 상에서 인식은 되고, 작동은 다 되는데, 한가지, 화면만 안나온다. 커널 업그레이드 과정에서 하드웨어쪽이 깨졌음을 알 수 있다. 참고로 업그레이드된 버전은 6.6.37-1-lts 이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;geuraepigkadeu-deuraibeo-jaeseolci&quot;&gt;그래픽카드 드라이버 재설치&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;그래도 안됩니다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;rolbaeg&quot;&gt;롤백&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;싫은뒈?&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;위의 이유로, 그냥 모니터 두개만 쓰는 중이다. 해결될 때까지 매일 업글 돌려야지.&lt;&#x2F;p&gt;
&lt;p&gt;아치리눅스를 이용한다면, 이건 각오해야 한다. 만약 모니터 세 개가 다 죽었다면, usb로 부팅해서 ssd 드라이브에 있는 커널을 롤백해줘야 하는데, 그게 아닌게 어디인가.&lt;&#x2F;p&gt;
&lt;p&gt;인생이 지루할 때 쯤이면 한번씩 안 지루하게 해줘서 좋다. (!@$#!$)&lt;&#x2F;p&gt;
&lt;p&gt;왜 계속 쓰는지 궁금할 것이다. 예전엔 재미있어서라고 답했을텐데, 지금은 그냥 남이 이해할 수 없는 재미의 존재에 대해 길게 설명하기 귀찮아서, 스스로를 변태로 간주하고 대충 넘기는 중이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>죽은 FIX 라이브러리 살려내기</title>
        <published>2024-07-04T00:00:00+00:00</published>
        <updated>2024-07-04T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/fix-lib/"/>
        <id>https://xanthorrhizol.github.io/posts/fix-lib/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/fix-lib/">&lt;p&gt;회사에서 리드 역할에 더 충실하기 위해 실제 작업은 팀원에게 넘기고 그 전에 계획하고 개발 후에 리뷰 및 관리하는 역할로 차차 넘어가고 있다.&lt;&#x2F;p&gt;
&lt;p&gt;이번엔 FIX 프로토콜을 개발해야 한다. FIX 프로토콜은 금융 거래에서 사용되는 하나의 표준 프로토콜이다. 처음엔 그냥 머리속에서, DMA 프로토콜을 개발하면서 짜내려간 코드를 재활용하면서, TagValue 인코딩만 구현하면 되겠다고 생각하고 있었다. 그런데, 실제로 팀원이 수행하도록 업무를 구상하려 하니, 가장 쉬운 방법을 고민하게 됨. 결국 FIX는 표준이므로, Rust 라이브러리 또한 존재했다.&lt;&#x2F;p&gt;
&lt;p&gt;문제는 이 라이브러리가 관리되지 않고 있다는 것이다. Rust 1.29부터 deprecated되는 문법들을 그대로 둔 채... 현재 Rust 버전은 1.79다. 결국 현재 사용이 불가한 상태다. 그럼 여기서 포기해야 하나 했는데, 사용법을 보니 너무 편해서 고치고 싶다는 생각이 들었다. 고치기만 하면, 개발 업무는 개꿀이 될 것이라는 확신이 들었음.&lt;&#x2F;p&gt;
&lt;p&gt;그래서 달려들었다. 매크로가 굉장히 많아서 디버깅이 좀 힘들긴 했는데, 그래도 새로 짜는 것보다는 분명 낫다. 오늘 약 2-3일쯤 되었는데, 역시 하다가 익숙해지니 속도가 붙어서 방금 끝났다. 꽤 재밌었다. 매크로를 이렇게 맛깔나게 쓰다니, 감탄하면서 고쳤다. 그냥 고친거 갖다 써도 되지만, 겸사겸사 오픈소스 기여도 할 겸 &lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;jbendig&#x2F;fix-rs&#x2F;pull&#x2F;6&quot;&gt;PR&lt;&#x2F;a&gt;을 올려 뒀다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>통증 민감도 문제</title>
        <published>2024-06-20T00:00:00+00:00</published>
        <updated>2024-06-20T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/nerve-system-bullshit/"/>
        <id>https://xanthorrhizol.github.io/posts/nerve-system-bullshit/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/nerve-system-bullshit/">&lt;p&gt;2015년 겨울, 발목에 연골이 찢어져서 수술로 제거하고 뼈에 미세천공술을 받았었다. 마취가 깼는데, 진통제를 놓아 줄까요? 하는 간호사의 말에 아무 고민 없이 &quot;아니요&quot;라고 대답했다. 그냥 발목이 좀 삔 것 같은 느낌이었다. 물론 아무 생각 없이 발을 딛었다가 번개침.&lt;&#x2F;p&gt;
&lt;p&gt;2019년 가을이였나, 속이 안좋으면서 허리도 많이 뻐근해서 시름시름 하다가 밤에 잠을 잘 수가 없어서 응급실에 방문했다. 통증강도를 찍으라길래 6정도를 찍었다. 그런데 요로결석이었다.&lt;&#x2F;p&gt;
&lt;p&gt;2021년이었나? 또 요로결석이 발생했는데, 속이 안좋으면서 날카로운 통증이 옴. 하지만 재택근무로 일 다 했다.&lt;&#x2F;p&gt;
&lt;p&gt;2022년에는 허리가 좋지 않아 검사를 받았는데 요추뼈 몸체 모서리가 부러진 채 한참 지났다는걸 알게 되었다. 쉬몰결절도 있고, 디스크의 수핵이 완전 빠져나간 뒤였다. 뼈가 충격을 다 받는 바람에 허리 통증이 자주 발생하기 시작했고, 번개도 자주 쳤다.&lt;&#x2F;p&gt;
&lt;p&gt;딱히 치료가 안된다 하여, 그냥 버티다가 결국 올해 4월엔 문제되는 요추뼈 아래의 디스크가 터져버렸다. 4월이 맞나 싶긴 하다. 원인이 되는 날짜가 두개 정도 예상되는데, 어디서 결정적으로 터진건지 모르겠음.&lt;&#x2F;p&gt;
&lt;p&gt;3월 대회 마지막날에, 진통제 가지고 있는걸 다 털어먹고 경기를 뛰었다. 경기 다 끝나고 나서 긴장이 풀렸더니, 위가 꼬여서 급하게 가지고 있던 진경제를 먹음. 이후 일정 끝나고 파한 후 호텔로 가는데, 진통제가 풀리면서 허리가 끊어질 것 같은 느낌이 났다. 거긴 일본이었는데, 다짜고짜 약국을 찾아가서 진통제 코너 물어보고, 느릿느릿 일본어를 읽어가며 어떻게든 제일 쎄보이는 진통제를 사다 먹음. 아 이거, 신기한데, 일본의 소염진통제에는 카페인무수물이 첨가되어 있다... 자야 하는데? 그래도 일단 통증을 잡는게 우선이므로 약 먹고, 그날 잠 거의 못잠.&lt;&#x2F;p&gt;
&lt;p&gt;아 그리고 당시 새끼손가락도 부러져 있었는데, 의외로 이 손가락은 아무 느낌이 없었다. 그냥 땡땡하게 부었다. 한국 돌아와서 검사해보니 쪼개져 있었음. 올...? 허리 아프고, 손가락 부러진 와중에 회사 갈 것 다 가고, 훈련도 갔다. 그러다가 회사에서 한 번 더 체크메이트 당했다. 사무실에서 자리 이동을 해야 해서 PC를 다시 설치해야 했다. 책상 밑으로 들어가 앉아서 선을 꽂고 나서, 자리에 앉았는데, 뭔가 잘못되었음을 크게 느꼈다. 바로 퇴근. 이후 좀 나아지는 것 같던 허리통증이 다시 극심해졌다.&lt;&#x2F;p&gt;
&lt;p&gt;근데 그 와중에, 오른쪽 엄지발가락쪽 앞꿈치에 석회가 생겼다. 어릴 때 팽이를 밟았을 때 그 느낌이 났다. 가장 심할 땐 발가락이 터질 것 같았다. 하지만 역시 할 일은 다했다. 발날로 운전하고, 발날로 걸어다니고, 회사도 다 가고, 어떻게든 돌아다님.&lt;&#x2F;p&gt;
&lt;p&gt;결국 그러다가 한쪽 다리가 마비되어서, 좀비모드로 돌아다닐 권리마저 빼앗겼다. 다행스럽게도 쭉 마비된건 아니고, 완전 마비의 경우 일시적으로 한 1~2분 정도 발생했고, 그 이후엔 감각마비가 지속되면서 방사통이 발생했던 듯 하다. 근데 이 방사통도 원래는 많이 아프다고 들었는데, 오히려 방사통이 나한텐 허리통증보다 나았음. 그냥 탄산수에 다리를 담궈둔 듯한 느낌이었다. 감각마비 덕인가? 근데 일단, 이건 제대로 잘못된게 맞다는건 확실했다. 그래서 바로 가장 빠른 일정으로 MRI 촬영 진행. 파열 진단을 받았다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;tongjeung-insig-cegye-byeongyeong&quot;&gt;통증 인식 체계 변경&lt;&#x2F;h2&gt;
&lt;p&gt;이렇게 통증의 최대치가 통상적인 기준보다 아래인 상황에서 신체의 오랜 사용을 위해 캘리브레이션을 진행하기로 했다.&lt;&#x2F;p&gt;
&lt;p&gt;위의 사례 중 가장 큰 통증은 &quot;번개가 친다&quot; 혹은 &quot;끊어질 것 같다&quot;이다. 둘 사이에 우열을 가리기는 조금 힘들다. 왜냐하면 번개는 정신을 못차릴 정도의 큰 통증이 갑자기 훅 치고 빠지는 식이다. 순간 통증 자체의 크기는 제일 크다. 반대로 끊어질 것 같은건, 끊어질 것 같아서 못움직이는데, 최대한 덜 아픈 자세를 찾아서 안움직이면 또 괜찮음. 그래서 둘 사이에 우열을 가리기는 조금 힘들다.&lt;&#x2F;p&gt;
&lt;p&gt;이 번개가 치거나 끊어질 것 같은 통증은 이제 제대로 잘못되었다고 보고 병원 진료를 받아야 하는 것으로 이해하기로 했다. 추가로, 속이 안좋을 때인데, 난 이게 그동안 위염이라고 생각했다. 하지만 내시경은 깨끗함. 다들 있는 표재성 위염 정도? 이번에 허리 통증이 심할 때 속도 같이 아프거나 안좋아지는 현상을 발견해서, 속이 안좋을 때 또한 허리에 문제가 아닌지 감별해 봐야 하게 되었다.&lt;&#x2F;p&gt;
&lt;p&gt;다음은 욱씬거리는 통증인데, 주로 안에서 뭐가 터지거나 손상을 받아서 부을 때 발생한다. 추가로, 현재 디스크 회복기에 들어간 것 같은데, 가끔 무리해서 허리가 아프면 이런 박동성 통증이 온다. 허리에서 맥박이 뛰는 느낌이 남. 그리고 그건 바로 오늘이다. 재활운동 중에, 안전을 위해 허리 보조기 차고, 수건 말아서 허리 받치고, 스미스 머신에서 벤치프레스를 35kg로 했음. 위로 좀 던져지길래 괜찮은 무게인가보다 하고 그대로 12개씩 4세트를 했음. 이후 사이드 래터럴 레이즈를 하던 도중 허리 통증이 발생했다. 내생각엔 35kg를 한 것보다 35kg를 던지면서 한게 문제인 것 같은데, 혹시 모르니, 허리통증 회복 후 운동 땐 30kg로 던지지 말고 해야겠음. 아니 근데 몸통에 힘 하나도 안줬는데? 왜...? 뭐 여튼, 이런 욱씬거리는 통증은, 뭐되기 전에 경고하는 통증이라고 봐야 할 듯 하다.&lt;&#x2F;p&gt;
&lt;p&gt;다음은 뻐근한 통증이다. 이중에서도 묵직하고 둔탁하면서 불편한 느낌이 있고, 근육통일 때처럼 거칠게 당기는 느낌이 있다. 후자는 근육통. 환영. 전자는 통증 자체의 크기는 크지 않은데, 무시하면 안된다. 방사통이었다. Iliac crest, 꼬리뼈 위쪽 좌측 엉덩이로 통증이 주로 온다. 딱 L2, L3 척추신경이 연결되는 부위인 듯 함. 좀 더 진행되거나, 다리쪽으로 가면, 또 탄산수처럼 청량(?)한 느낌이 난다. 그런거 보면 아마 감각마비 때문에 다리쪽은 통증이 안 심했구나 싶다. 다만 이거, 평소에 올 때는 그냥 묵직하니 불편한 정도인데, 심하게 오면 마치 곧 폭발할 것 같은 느낌이 나서 움직이지 못한다. 끊어질 것 같은 느낌과 폭발할 것 같은 느낌의 차이는, 끊어질 것 같은 느낌은 아주 날카로우면서 속이 울렁거리는 증상이 같이 오는데 반해, 폭발할 것 같은 느낌은 말 그대로 폭발할 것 같은 느낌이다. 움직이면 마치 공기가 가득 차서 터질 것 같은 풍선을 발로 차는 듯한 느낌이 난다.&lt;&#x2F;p&gt;
&lt;p&gt;마지막으로 얼얼한 통증이다. 멍들면 발생함. 신경 안써도 됨. 물론 따가운 통증도, 보통 눈에 보이는 곳에 발생한 상처로 인한 것이므로 신경 안써도 된다. 근데 가끔 신기하게도 따가운 통증이 속에서 날 때가 있음. 지금 욱씬거리는 그 허리가 따가운 느낌도 같이 난다. 근데, 욱씬거리는 통증을 센싱할 것이므로 따가운건 무시할 예정이다.&lt;&#x2F;p&gt;
&lt;p&gt;이렇게 해서 나름의 통증 인식 체계를 만들어가야 할 듯 함. 못버티기 전에 알아서 중단해야 하는걸 알게 되었음. 심지어 다리 마비가 올 때까지 어떻게든 요래조래 돌아다니고 일상생활을 다한 것을 보면, 이건 꽤나 중요한 문제인 것 같다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;haedang-munjeyi-deuggwa-sil&quot;&gt;해당 문제의 득과 실&lt;&#x2F;h2&gt;
&lt;p&gt;비가역적인 상태가 되고 나서야 문제를 알아채는 경우가 많다. 발목 또한, 연골이 찢어진지 2년이 지나서 알았고, 결국 수술로 제거. L3 모서리가 골절된건 심지어 도대체 언제 그랬는지조차 모름. 그래서, 의외의 문제가 있다. 상해보험 처리를 못받고, 이미 만성화가 다 진행되고 나서 생돈을 들이며 처치를 받는 편이다.&lt;&#x2F;p&gt;
&lt;p&gt;하지만 득도 있다. 인체는 어차피 소모품이다. 결국 언젠간 죽을텐데, 이때의 고통이 덜해질 것이기 때문에 꽤나 큰 득이다. 게다가 조금 더 핑계대고 나태해지는 방법으로 나름 건강도 찾을 수 있다. 감당할 수 있는 고통의 그릇은 큰데, 좀더 느긋하게 적은 통증을 느끼며 편안한 여생도 누릴 수 있으니, 일석이조임. 그걸 늦게 알아서 좀 고통받긴 했지만 ㅋㅋㅋ. 아 그리고 노인이 되면 어차피 여기저기 고장나 있을텐데, 이때 어떻게든 일상생활 누리기 스킬이 빛을 발할 것이다. 장수의 비결이다. 아니 근데 오래 살 생각은 없는데...?&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>허리 디스크 파열</title>
        <published>2024-06-01T00:00:00+00:00</published>
        <updated>2024-06-01T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/lumber-disk-extrusion/"/>
        <id>https://xanthorrhizol.github.io/posts/lumber-disk-extrusion/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/lumber-disk-extrusion/">&lt;p&gt;L2-3 사이 디스크 회복 불가한 퇴행으로 인해 후관절증후군과 통증으로 고생하던 중, 결국 응당한 대가를 치르게 되었다.&lt;&#x2F;p&gt;
&lt;p&gt;예측된 결과이다. 다음 차례는 L3-4라고 했으니. 그 L3-4 사이 디스크가 결국 파열되어 왼쪽 다리로 가는 신경에 문제를 일으켜서 왼쪽 다리가 일시적으로 완전히 마비되었다. 다행히 완전 마비는 잠시 후 풀렸지만, 감각이 무디고 마치 탄산수에 다리를 담궈둔 듯한 느낌이 계속 났음.&lt;&#x2F;p&gt;
&lt;p&gt;지금은 약 6-7주째이다. 다행히 마비는 생각보다 빨리 회복되어 수술 없이 치료중이다. 다음에도 터지면 다시 3-4번이 될 예정. 3-4번이 2-3번처럼 되면 그 다음은 4-5번이 터진다.&lt;&#x2F;p&gt;
&lt;p&gt;디스크 파열로 인해 훈련을 못나가는 것은 물론, 운전, 대중교통까지 금지되었다. 직업적인 이유로 무조건 회사를 출근해야 했다면, 사실 휴직을 했어야 하는 상태. 하지만 다행스럽게도 재택근무 제도가 있어서 집에서 일하고 있다. 근데 프로젝트 마감 갑자기 땡겨저서 근무시간 치솟고 1시간 마다 누워서 찜질하던 루틴이 다 깨져서 회복 더뎌진건 안비밀 ㅋㅋㅋ. 다행스럽게도 마비 어느정도 회복되고, 좀 버틸만 할 때 치솟아서 추가적인 마비나 사고는 없었다. 어느정도 마무리된 지금, 다음주 1주간 휴가를 냄.&lt;&#x2F;p&gt;
&lt;p&gt;정선근 교수의 책도 세트로 사서 읽었다. 걷기, 렛풀다운, 힙업덕션 운동을 조금씩 하는 중인데 혹시나 하여 푸시업을 해볼까? 하고 엎드려 뻗치는 순간 뭔가 느낌이 이상하더니 지금 통증으로 벌받는 중이다. 그래서 지금 단계는 걷기, 렛풀다운, 힙업덕션만 가능한 상태이다. 이것도 많이하면 좀 힘듦. 근데 훈련 복귀하려면,&lt;br &#x2F;&gt;
가능한 선은 계속해야 함.&lt;&#x2F;p&gt;
&lt;p&gt;재밌는건, 대회 가기 전에 자꾸 경기 중에 몸이 마비되는 꿈을 꿨다. 뇌의 신비. 그래도 꿈에선 온몸이 마비되었는데, 현실에선 다리만 마비됨. 물론 허리 문제로 온몸이 마비될 일은 없으니 꿈쪽이 호들갑이다. 그리고 실제로 터지고 나니까 그 꿈은 더이상 안꿈.&lt;&#x2F;p&gt;
&lt;p&gt;크런치 모드로 인해 한동안 깨졌었지만, 회복을 위해 진행하던 루틴은 아래와 같다.&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;오전 8시 기상&lt;&#x2F;li&gt;
&lt;li&gt;아침식사 후 물 크게 한 컵 마시면서 약 복용&lt;&#x2F;li&gt;
&lt;li&gt;자세 신경쓰면서 산책: 현재 1.5km가 상한&lt;&#x2F;li&gt;
&lt;li&gt;귀가 후 허리에 쿠션 대고 누워서 온찜질 20분, 원하는 만큼 휴식&lt;&#x2F;li&gt;
&lt;li&gt;재택으로 업무 및 1시간 마다 눕기 + 가능하면 온찜질도&lt;&#x2F;li&gt;
&lt;li&gt;점심식사 및 물 크게 한 컵&lt;&#x2F;li&gt;
&lt;li&gt;저녁식사 및 물 크게 한 컵 마시면서 약 복용&lt;&#x2F;li&gt;
&lt;li&gt;랫풀다운, 힙업덕션 적당히(양 정해두지 말고 상태 따라서 조절)&lt;&#x2F;li&gt;
&lt;li&gt;23시 취침(이거 좀 많이 어려움. -&amp;gt; 그래서 기상을 8시로 해둠)&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;p&gt;지금 힘든건, 통증도 통증이지만 체질적으로 혈압을 높일 만한 무언가(즉 운동)을 하지 않으면 기립성 저혈압이 심해진다. 일어날 때 어지럼증이 좀 오고, 잘못 일어나면 앞이 깜깜해지는 것에 더해서 숨이 멈췄다가, 잠시 후 돌아오는데, 이때 심장도 엄청 빨리 뛰면서 숨을 몰아쉼. 그래서 이거 해결하려면 음... 딴생각 하지 말고 그냥 허리 빨리 회복이나 하자 ㅋㅋㅋㅋㅋㅋㅋㅋ.  나름 저런 문제 때문에 행동을 조심하게 되니, 회복 가속 스킬이라고 봐도 될 듯 함. 이번에 디스크도 회복이 된다는 것을 알게 되었더니, 나름 인체에 믿음을 가지게 되었음. 암이 아니라면 그냥 쉬면 알아서 해결되는 것 같음. 안쉬는게 문제지.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>뽀개짐</title>
        <published>2024-03-30T00:00:00+00:00</published>
        <updated>2024-03-30T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/broken-body/"/>
        <id>https://xanthorrhizol.github.io/posts/broken-body/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/broken-body/">&lt;p&gt;2024-03-14 ~ 2024-03-17에 진행된 라크로스 오키나와 오픈, 내가 보기에 이건 인생 마지막 대회였던 것 같다. 아니, 사실은 그렇지 않기를 바란다. 하지만, 너무 강한 단서가 나를 괴롭힌다.&lt;&#x2F;p&gt;
&lt;p&gt;사실, 과로를 했던 이후 아직도 몸이 온전히 회복되지 않은 상태로 대회에 나갔던 차이다. 그래서 마지막날엔 허리통증이 극에 달했다. 아침에 눈을 뜨자마자 그날이 마지막이라는 기분이 강하게 들었다. 오전 경기엔 통증으로 인해 참전하지도 못했다. 하지만 경기가 만족스럽지 않게 끝나 팀원들이 모두 기가 죽어버렸다. 마지막 경기마저 그렇게 찝찝하게 끝나면 절대 안된다. 그런 경험을 팀에서 극복하는덴 몇 년이 걸린다. 그리고 난 그 때 주장이었다. 그래서 결정했다. 이왕 마지막일 수도 있는거, 모든 것을 불태우기로 했다. 가방에 있던 진통제를 다 털어먹고 몸을 인정사정 없이 제대로 풀었다. 그런데 마지막 경기 직전의 슛업(슈팅을 실제로 받아내는 웜업) 과정에서 오른손 새끼손가락이 골절됐다. 뼈나 인대가 나간 것은 확실한데, 난 이미 아드레날린에 쩔어 있었다. 툴툴 털고 마지막 경기를 뛰었다.&lt;&#x2F;p&gt;
&lt;p&gt;초반 공세를 막으며 버틴 끝에 경기 분위기가 우리 쪽으로 넘어왔다. 결국 5:2로 승리했다. 경기 종료 후, 마지막 단체사진을 찍자마자 난 위가 꼬여 드러누워 움직이지 못했다. 물론 그 상황도 이미 다 대비가 되어 있었다. 팀원에게 내 가방의 진경제를 가져다달라고 부탁해서 그 약을 먹고 잠시 후 살아났다.&lt;&#x2F;p&gt;
&lt;p&gt;한국에 돌아오고 나서 병원에 가서 손가락 엑스레이를 찍었더니, 관절면끼리 부딪히면서 쪼개졌다고 했다. 일단 자기 위치를 아직 벗어나지 않아서 수술은 킵하고 경과 지켜보되, 건이 붙는 자리라서 깁스로 손목까지 고정하고, 꼼짝도 하지 마라고 했다. (근데 그 상태로 경기도 뛰었는데, 원래 안벗어날 골절이 아닌가?)&lt;&#x2F;p&gt;
&lt;p&gt;뭐 여튼 꼼짝도 하지 마라고 하니, 일단 오른손은 팔걸이에 쳐박아 두고 살아보기 시작했다. 문제는, 허리 통증도 다시 엄청 심해졌다는 것이다. 좀 있으니 오른쪽 발 앞꿈치에 석회도 생겼다. 뭐 그건 그냥 아픈거고, 문제는 허리를 못쓰는 와중에 손도 못쓴다는 것이었다. 일단, 운전이 문제였다. 시동, 내비게이션, 변속, 사이드브레이크, 안전밸트 체결부 모두 오른쪽이다. 그래서 며칠간 운전을 못했다. 그러다 허리가 영 안되겠다 싶어서, 태릉쪽에 있는 병원에 가기 위해 방법을 찾았다.&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;오른쪽을 바라보고 운전석 사이드에 걸터앉아서 왼손으로 안전밸트를 체결&lt;&#x2F;li&gt;
&lt;li&gt;시동을 걸고, 내비를 설정&lt;&#x2F;li&gt;
&lt;li&gt;변속기 변경&lt;&#x2F;li&gt;
&lt;li&gt;고쳐앉기&lt;&#x2F;li&gt;
&lt;li&gt;액셀 밟으면 사이드브레이크 풀리는 기능 이용&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;p&gt;이렇게 해서 병원에 갔다. 돌아오는 길에는, 집으로 가기 음성인식으로 네비 설정이 가능하다. 페달은, 발날로 밟았다…&lt;&#x2F;p&gt;
&lt;p&gt;추가로 터치펜과 펜을 붙여서 길이 연장해서 제대로 앉고 나서도 왼손으로 내비게이션 조작 가능하게 해봤다. 근데 터치 감도가 좀 별로라서 결국 허리 써야 해서 실패. 대신 안전밸트 풀 때 이걸로 푸니까 허리 안돌려도 돼서 좀 편해졌다. 시동도 이거로 켜고 끈다.&lt;&#x2F;p&gt;
&lt;p&gt;여튼 병원에서 여느 때처럼 신경차단술을 받았는데... 이번엔 뭔가 해결이 안된다. 계속 아프다. 속도 뒤집어질거같고 그냥 뭐 어떻게 저떻게 시간은 흘려 보낸거같은데... 뭐 그건 그렇다 치고, 밥줄...! 오른손 없는 개발자라니? 그와중에 허리 아프다고 조기퇴근 남발?&lt;&#x2F;p&gt;
&lt;p&gt;그래서 일단은 코파일럿을 VIM에 설치했다. 그렇게 어떻게 저떻게 버티다가, 뜬금없는 희소식이 발생했다. 손 치료받던 동네 병원에서, 허리 물리치료도 받고 있는데, 견인치료 중에 갑자기 속에서 뭔가 뚝 하고 뒤틀리는거같더니, 통증이 확 줄어들었다. 아니 뭔 회당 8만원 16만원 하는 주사치료로도 안되던게, 8천원짜리 물리치료로 확 괜찮아다지다니? 그리고 왜 이 간단한 치료는 그동안 아무데서도 안해줬는지?&lt;&#x2F;p&gt;
&lt;p&gt;다만 한가지 문제점은 있는데, &quot;안좋아지면 물리치료 오세요&quot; 하길래 금요일에 신난다! 하고 안가고, 진통제도 안먹었더니 퇴근하는데 또 안좋아졌다. 그래서 다시 약먹고 물리치료를 갔다. 이건 거의 뭐 신장 투석 환자마냥 일일 활동권을 병원에서 끊어와야 하는 듯 하다. 뭐 그래도 방법을 찾은게 어디인가.&lt;&#x2F;p&gt;
&lt;p&gt;여튼 그 몸 상태 좋아진 그날, 너무 신나서 코드를 5천줄 넘게 썼다. 코파일럿과의 합도 잘 맞아지고, 완전 날아갈거같았다. 마침 지금 개발하는게 프로토콜쪽이라서 노가다성이 짙은데, 코파일럿이 너무 좋아한다. 특기분야인 듯 하다. Private repo 접근 권한 안주고, 회사가 아닌 개인 계정으로 결제해서 기능에 한계는 있겠지만, 일단 초반에 시범으로 좀 짜주고 나면, 이후부터는 척척 추천해준다. 게다가, Rust랑 궁합도 좋다. 컴파일러가 strict할수록 코파일럿이 삽질했을 때 더 잘 잡아줄 것이기 때문일 듯 하다. 코파일럿은 언어를 이해하기보다, 단순히 이런 케이스의 코드가 어떻게 짜여졌는지에 대한 패턴을 학습하는 듯 하다. 그래서 예시로 짜주지 않은 형태는 스스로 유추하지 못한다. 아직 그냥 코더이다. 내 밥그릇은 아직 남아있는 듯 하다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>난중일기</title>
        <published>2024-02-24T00:00:00+00:00</published>
        <updated>2024-02-24T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/nanjung-ilgi/"/>
        <id>https://xanthorrhizol.github.io/posts/nanjung-ilgi/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/nanjung-ilgi/">&lt;h2 id=&quot;1&quot;&gt;1&lt;&#x2F;h2&gt;
&lt;p&gt;2024년 1월 22일, 특정 마이크로서비스에 큰 변화를 가하는데 아주 무리한 일정이 내려왔다. 하루하루 한 단계가 해결되지 않으면 다음 단계를 넘어가지 못하는데 다음 단계로 한 번이라도 못넘어가면 바로 일정을 지킬 수 없는 수준이었다.&lt;&#x2F;p&gt;
&lt;p&gt;그렇다고 그걸 미룰 수도 없었다. 당장 새 모델의 성능에 악영향을 끼칠 것이었고, 새 모델의 배포 또한 ASAP인 상태였기 때문이었다.&lt;&#x2F;p&gt;
&lt;p&gt;러시한지 4일차, 다음날이 배포인 상황. 고객사에서 연락이 왔다고 한다. 미루자고. 모델 배포와 함께 진행하기로 한 타 회사의 기능 개발이 부진한 탓이었다. 무엇 때문에 이렇게 달린 것인가...&lt;&#x2F;p&gt;
&lt;p&gt;여튼 우여곡절 끝에 스프린트 마지막날에 배포하면서 마무리되었다. 시간이 더 생긴 만큼 테스트도 더 많이 진행됐다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;2&quot;&gt;2&lt;&#x2F;h2&gt;
&lt;p&gt;그리고, 해당 서비스는 내 담당 서비스는 아니었다. 그래서 내 담당 서비스의 신규 버전 개발 Task도 그대로 남아있었음. 물론 결국 다른 일들에 밀려 일시정지되었다....&lt;&#x2F;p&gt;
&lt;p&gt;이런 식으로 일 중단되는거 제일 싫어한다.... 그래도 공통 라이브러리 모으는 task는 첫주에 다 진행함. 다른 서비스에도 영향이 있으므로 좀 러시했음.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;3&quot;&gt;3&lt;&#x2F;h2&gt;
&lt;p&gt;그리고, 고객사에서 요청한 피쳐의 반영도 해야 했다. 그건 퇴사한 전 팀장님의 서비스에서 처리해야 하는 일인데, 내가 또 이런거 땜빵 전문이다. C#으로 되어 있지만 다행히 예쁘게 짜서 유지보수하는데 어려움은 딱히 크지 않다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;4&quot;&gt;4&lt;&#x2F;h2&gt;
&lt;p&gt;이와중에 예전에 고객사에서 서비스 장애 시 SMS 알림을 해달라고 하며 추후 API 호출 방법을 보내주겠다고 했는데, 그 메일이 왔다. 심지어.... 담당자가 없어서 API 호출을 못열어준다며,  그냥 직접 소켓 연결해서 붙어서 메시지 쏘는 C 코드를 툭 던져줌. 그리고 그 코드는 include문들도 다 빼먹고, 직접 선언해서 사용했을 함수도 포함되어 있지 않았다. 그와중에, 내부에 들어가는 정보는 보안상 알려줄 수 없다며 그날 가져오면 정보 채워주겠다고 함. C로 가져가야 거기서 빌드할 수 있겠다 판단, 일단 C인 상태로 진행하고 추후 바꿔도 된다면 유지보수 가능하도록 Rust로 재작성하기로 함. 일단 근데 C언어이므로, 내가 진행해야 했다.&lt;&#x2F;p&gt;
&lt;p&gt;반환 타입, 함수 파라미터, 예상되는 결과값 유추해서 빈칸들 끼워맞춰서 개발 완료했음. 개발 완료되었다며, gcc 있는지 확인해달라고 하니, 없다고 함(롸?). gcc 없는데 c 파일을 준다고? 그럼 진작에 Rust로 만들었지... 여튼 그래서 debian 이미지에 gcc, build-essentials 깔아서 가져가서 정보 받고 빌드해서 쏴봄. 안됌. 왜냐하면? 개발계에는 세팅을 안했다고 한다. 운영계에서 테스트 하라고 함(와우). 그래서 또 쏴봄. 안됌. 왜냐하면? 방화벽을 안열어 놨다고 한다. 요쪽에선 자주 있는 일이라 이제 놀랍지도 않다. 대충 처음에 가져가면 안될걸 예상했기 때문에, 테스트 가능하도록 SMS send는 send만 하고, 장애 모니터링도 따로 짜서 가져갔기 때문에, SMS send 테스트 방법 알려준 후 넘기고 옴.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;5&quot;&gt;5&lt;&#x2F;h2&gt;
&lt;p&gt;그리고, 새 모델을 개발하고 테스트하기 위해 부산 IDC에 서버를 넣기로 했는데, 이게 또 일정이 가까이 다가왔다. VPN 세팅 등을 더이상 미룰 수 없어서 인프라팀과 계속 이것저것 주고받는데 생각보다 이 망대망 연결을 하기에 사내 네트워크가 너무 개떡같았다(네떡이라고 부르심...). 그도 그럴게 30명 규모였던 회사 규모에서 별다른 준비도 없이 80명 규모로 인원을 뽑아댔고, 당시 인프라 전담 팀도 없었기 때문에 그 네떡이 80명규모인 지금까지 넘어왔던 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;여튼 그 네떡 위에서 문제가 된 것은 VLAN 설정이다. 현재 네트워크 토폴로지는 그냥 방화벽 밑에 스위치 3개가 데이지체인으로 엮여있는 방식인데, 스위치 3개에 아무 호스트가 막 연결되어 있는 방식이다. 제일 먼저 방화벽에서 VLAN Switch 밑에 VLAN 대역을 추가했는데, 역시나 호스트에서 그 VLAN으로 연결 안됨. 왜 안되는지 찾기 위해 난리를 쳤다. 심지어 네트워크 작업은 아무리 빨라도 일단 증권 거래가 이루어지지 않는 장 마감 후에 진행해야 한다. 그러다 결국 속도를 내기 위해 네트워크 장비들 어드민 패스워드까지 받게 되었다.&lt;&#x2F;p&gt;
&lt;p&gt;여튼 원인을 열심히 파보니, 밑의 스위치들이 그 VLAN의 존재를 모르기 때문이라는 의심이 가장 많이 들었다. 내가 알기로  방화벽은 방화벽일 뿐 실제로 VLAN은 Layer 2이다. 스위치가 그 VLAN을 알고 있어야 한다. 그래서 스위치에서 arp cache를 조회하여 내 호스트가 어느 스위치의 어느 포트인지 파악해서 해당 포트에서 vlan id에 새 vlan을 이용하도록 설정함. Tag에 대해서 모르고 있었기 때문에 그냥 Untagged port를 vlan으로 할당해버림.&lt;&#x2F;p&gt;
&lt;p&gt;네 안됩니다. 다른 스위치에도 다 설정해야 함. 그런데 문제가 있다. 스위치끼리 연결한 인터페이스(1&#x2F;2&#x2F;1)에 Untagged Port VLAN을 적용해버리면, 전체 스위치의 vlan이 바뀌어버릴 것 같아서 건드릴 수가 없었다.&lt;&#x2F;p&gt;
&lt;p&gt;해결한 방법은, IEEE Tag를 이용하는 것이다. 원래 패킷 상에 vlan id는 안들어가는데, 이걸 들어가게 할 수 있다. 그럼 스위치는 해당 tag를 보고 vlan id를 읽을 수 있게 됨. 그래서 전체 포트에 대해 tagged라면 새 vlan을 사용하도록, untagged라면 defalut vlan을 이용하도록 설정했다. 여기서, 호스트에서는 그 IEEE Tag를 패킷에 심어줘야 한다. 그건 VLAN 인터페이스를 생성하면 된다. 여기서 VLAN ID를 주면 그 태그에 들어감.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;6&quot;&gt;6&lt;&#x2F;h2&gt;
&lt;p&gt;그와중에 갑자기 2월 1일 밤에, 회사 서버실의 에어컨이 고장나서 서버실 온도가 치솟았다. 연락을 받고 우리팀 서버에 필요한 파일만 후다닥 백업한 후 싹 긴급정지했다. 네트워크 장비도 그 서버실에 있어서, 혹시 작업 중에 죽어버릴까봐 설정 원복 후 작업 중단했다. 그리고 다음날 다시 켰더니 결국 한 서버가 커널 패닉을 내며 부팅 실패... 하지만 지금 급한건 이 서버가 아니였어서 다음 스프린트 때 볼 예정.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;7&quot;&gt;7&lt;&#x2F;h2&gt;
&lt;p&gt;일이 너무 동시에 끝없이 진행되고, 일만 끝나면 집에 와서 뻗어자고 눈뜨면 바로 샤워하고 출근을 하다보니, 집에서 점심을 챙겨가던 습관까지 무너지고, 점심시간을 놓치는게 일상이 되었다. 사실 아무때나 먹어도 상관 없는데, 점심시간이 지나면 또 이런저런 일로 계속 호출된다. 저녁도 보통은 일이 계속 질질 끌리다가 야근을 해버리기 때문에 까먹는 경우가 많다. 저혈당으로 어지러우면 급한대로 회사 냉장고에 있는 요거트를 먹거나 해서 해결.&lt;&#x2F;p&gt;
&lt;p&gt;시간이 없는건 한가지 사례로 바로 알 수 있는데, 저번주 토요일에 회식자리에서 고기를 먹은 후, 패딩에 고기냄새가 심하게 났는데, 그걸 처리할 방법을 찾을 시간이 없어서 패딩을 못입고 다녔다. 꽤 추웠다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;seungjeonbo&quot;&gt;승전보&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;오늘 낮에 극적으로 VLAN 설정 해결책을 발견, 적용하면서 이번 전쟁은 끝났다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;gyeolgwa&quot;&gt;결과&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;2주만에 체중 5kg이 빠졌다.&lt;&#x2F;li&gt;
&lt;li&gt;치매와 비슷한 증상이 나타났다. 기억도 잘 안나고, 기억을 끄집어내는데 오랜 시간이 걸린다. 마치 기억들을 정리되지 않은 창고의 문을 열고 냅다 던져놓고 바로 닫아둔 느낌이다. 다행스럽게도, 이 증상은 목요일부터 완화되는 중이다. 그간 계속 3-4시간 자다가 수요일 밤에 결국 부정맥이 왔는데 멈추질 않아서 강제로 밤에 잠을 잤기 때문이다.&lt;&#x2F;li&gt;
&lt;li&gt;허리 통증 악화, 5분 이상 서있기 힘든 상태이다. 내일 병원에 갈 예정이다.&lt;&#x2F;li&gt;
&lt;li&gt;대회 전에 러시해서 허리 나갈 가능성을 방지하려고 대회 전에 4영업일 간 더 휴가를 냈다.&lt;&#x2F;li&gt;
&lt;li&gt;하지만 고쳐야 할 것은, 일을 눈앞에 두고 자리를 못뜨는 습관을 좀 버려야 한다. 평시에도 밥은 일하면서 먹는다. 한손엔 점심, 한손은 키보드에 있음. 이 습관이 무서운게 그 한손에 점심이 들려있지 않으면, 점심을 먹으러 나가는게 아니라, 점심을 안먹어버린다.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>커널 패닉으로 인한 부팅 불가 현상 해결하기</title>
        <published>2023-11-23T00:00:00+00:00</published>
        <updated>2023-11-23T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/first-aid-of-repetitive-kernel-panic/"/>
        <id>https://xanthorrhizol.github.io/posts/first-aid-of-repetitive-kernel-panic/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/first-aid-of-repetitive-kernel-panic/">&lt;p&gt;어제, 정말 기괴한 일을 했다. 리서치용 서버에 서버행이 떠서 재부팅을 했는데 커널 패닉이 반복되며 부팅이 안되는 현상이 발생함. 그리고 이걸 고치는 과정에서 세상 강제적인 방법을 다 동원했다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;siseutem&quot;&gt;시스템&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;우분투 20.04&lt;&#x2F;li&gt;
&lt;li&gt;다른건 알 필요 없음. 다만 이 문제를 잘 야기하는 하드웨어에는 리얼텍 NIC가 있다고 함.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;munje-weonin&quot;&gt;문제 원인&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;하드웨어를 인식하는 과정에서 잘못된 메모리 참조&lt;&#x2F;li&gt;
&lt;li&gt;아치리눅스 부팅USB로 부팅해서 살펴보니, &#x2F;dev에 ssd, hdd, 기타 디바이스 모두 없었음&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;haegyeolbangbeob&quot;&gt;해결방법&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;하드웨어는 누가 잡는다? -&amp;gt; 커널 -&amp;gt; 커널을 업데이트&lt;&#x2F;li&gt;
&lt;li&gt;커널을 어떻게 업데이트? -&amp;gt; apt upgrade하면 편한데 -&amp;gt; 부팅USB로 부팅한 후 파티션을 &#x2F;etc&#x2F;fstab과 맞춰서 마운트 -&amp;gt; &lt;code&gt;chroot&lt;&#x2F;code&gt; -&amp;gt; &lt;code&gt;apt update &amp;amp;&amp;amp; apt upgrade&lt;&#x2F;code&gt;&lt;&#x2F;li&gt;
&lt;li&gt;네임서버 설정 안됨 -&amp;gt; apt source url을 &#x2F;etc&#x2F;hosts에 강제로 박아넣고 진행&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;gyeolgwa&quot;&gt;결과&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;깔끔-&lt;&#x2F;li&gt;
&lt;li&gt;이게 된다고???&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;hugi&quot;&gt;후기&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;다덤벼&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>crates.io 배포</title>
        <published>2023-09-30T00:00:00+00:00</published>
        <updated>2023-09-30T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/cratesio/"/>
        <id>https://xanthorrhizol.github.io/posts/cratesio/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/cratesio/">&lt;p&gt;자체 개발하여 업무 및 개인 용도로 사용하고 있던 &lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;actor&quot;&gt;actor&lt;&#x2F;a&gt; 라이브러리를 crates.io에 배포했다(&lt;a href=&quot;https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;xan-actor&quot;&gt;xan-actor&lt;&#x2F;a&gt;).&lt;&#x2F;p&gt;
&lt;p&gt;원래 이 라이브러리는 업무용으로 필요한 기능만 구현해서 사용하고 있었는데, tokio를 너무 애용하는 바람에 main 함수를 async 함수로 만들어야 하는 단점이 있었다. 이게 async 키워드만 붙인다고 되는게 아니라 tokio::main을 이용해야 한다. 따라서 tokio를 쓰고싶지 않은 사람도 tokio를 이용해야만 이 라이브러리를 사용할 수 있었음. 그런데 또 비동기에 사춘기가 들어서 그런지, 동기 메인함수를 이용하고 싶었다. 그래서 동기로 만드는데, 이김에 tokio도 걷어내보고 싶어서 걷어내다 보니, 전체 구현를 tokio 없이 할 수 있는 피쳐가 만들어졌다.&lt;&#x2F;p&gt;
&lt;p&gt;근데, 매번 이 라이브러리를 add하는데 Cargo.toml에 깃허브 리포를 매번 넣어주는게 귀찮아오던 참에 crates.io에 배포해 보기로 했다. 보니까 4년째 관리 안하는 actor 라이브러리도 떡하니 자리를 잘 차지하고 있는데, 나라고 안될까.&lt;&#x2F;p&gt;
&lt;p&gt;일단 이걸 하면 편해지는건 그냥 &lt;code&gt;cargo add xan-actor&lt;&#x2F;code&gt; 하면 라이브러리가 add된다는 것이다. 개꿀.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;배포 방법&lt;&#x2F;p&gt;
&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;rinthel.github.io&#x2F;rust-lang-book-ko&#x2F;ch14-02-publishing-to-crates-io.html&quot;&gt;Crates.io에 크레이트 배포하기&lt;&#x2F;a&gt;&lt;&#x2F;p&gt;
&lt;p&gt;끝&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Rust의 모노리포 - 개꿀</title>
        <published>2023-09-24T00:00:00+00:00</published>
        <updated>2023-09-24T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/rust-monorepo/"/>
        <id>https://xanthorrhizol.github.io/posts/rust-monorepo/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/rust-monorepo/">&lt;p&gt;내가 속한 조직은 각 구성원이 믿을 만한 사람들로 구성되어 있다. 따라서 요구조건을 전달하고, 상대방이 어려워하는 경우 힌트만 좀 공유해서 이해시키면 됨. 그래서 마이크로서비스 구조로 잘 지속되어 왔다.&lt;&#x2F;p&gt;
&lt;p&gt;하지만 이것은 한계에 봉착하고 있다. 현재 우리 제품은 지속적으로 개선을 하고 있기 때문에 업데이트 빈도가 매우 빠르다. 그 업데이트들은 DB 스키마까지도 변경될 수 있을 정도로 큰 경우가 빈번하다. 심지어 개발속도도 빨라서 개발 중에 다른 서비스에 큰 변화가 생기는 경우도 발생한다. 또한 cargo update를 깜빡해서 버전에 안맞는 코드를 작성했는데, Cargo.lock파일 또한 커밋되지 않았으므로 CI 테스트를 그냥 통과하는 경우도 발생했다.&lt;&#x2F;p&gt;
&lt;p&gt;최근엔 작업 관리 서비스와 엔드포인트 서비스를 통합하는 과정에 있다. 그래서, 통합하는 김에 모노리포를 채택하기로 하였다. Rust에서 모노리포? 그거 아주 쉽다.&lt;&#x2F;p&gt;
&lt;p&gt;Rust에는 cargo라는 패키지 툴이 있다. cargo로 컴파일, 빌드, 라이브러리 import 모두 진행한다. 이뿐만이 아니라 workspace라는걸 이용하면, 최상위 디렉터리에서 여러 개의 cargo workspace를 구성하고 상호간 라이브러리처럼 import할 수 있음. 각 마이크로서비스는 마이크로서비스로 그대로 가져가지만, 리포만 하나로 통합할 수 있다. 이렇게 되면 다른 마이크로서비스의 버전 변화가 있을 때, 그냥 pull만 당겨주고 맞춰서 작업하면 됨. 브렌치 머지할 때도, conflict가 있는지 볼 수 있고, CI를 하는 것도 용이해진다. 또한, 각 마이크로서비스에서 이용하는 라이브러리의 버전도 자연스럽게 통합된다. 각 workspace의 Cargo.toml파일을 따로 세팅하긴 하지만, 최상위 디렉터리의 Cargo.lock파일에서 싸그리 관리하기 때문이다. 추가로, 이건 사소해 보이긴 하지만, 수정이 있을 때마다 깃허브 알림설정이 모두에게 날아가게 될 것이다. 자기 서비스에만 신경쓸 땐, 일부 리포는 알림이 안되어 있는 경우가 생기기 때문에, 따라가기 힘들 때가 있었는데, 해결될 듯 하다.&lt;&#x2F;p&gt;
&lt;p&gt;여튼 그래서, 아주 쉽게 모노리포 구성해서 작업중이다. 개꿀.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>기술적 분석</title>
        <published>2023-09-23T00:00:00+00:00</published>
        <updated>2023-09-23T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/technical-analysis/"/>
        <id>https://xanthorrhizol.github.io/posts/technical-analysis/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/technical-analysis/">&lt;p&gt;허리도 괜찮아지는 중이고, 뭔가 최근들어 머리가 팽팽 도는 상태이다. 이유는 모른다. 허리 아프다고 안쓴게 보관되나. 아 그러고보니, 불면증이 해결되는 중이구나.&lt;&#x2F;p&gt;
&lt;p&gt;여튼 그래서 오늘은 훈련 가기 전에 서적의 기술적 분석 부분을 다시 복습했다. 이미 수치 계산은 &lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;trading-toolkit&quot;&gt;trading-toolkit&lt;&#x2F;a&gt;에 만들어 놓은 상태였는데, 이때는 계산식 자체를 구현하는데 초점이 맞춰져 있었다면, 이번엔 기술적 분석을 통한 거래 방법에 초점을 맞추고 읽었다.&lt;&#x2F;p&gt;
&lt;p&gt;참고로 서적은 아래와 같다.&lt;&#x2F;p&gt;
&lt;blockquote&gt;
&lt;p&gt;나의 트레이딩 룸으로 오라! - 알렉산더 엘더&lt;&#x2F;p&gt;
&lt;&#x2F;blockquote&gt;
&lt;p&gt;조금 공격적인 느낌의 이름이긴 하다. 근데 뭐 영어로 &quot;Come to my trading room&quot;이면 그렇게 들리진 않을듯? 각설하고, 읽은 내용을 요약해 보겠다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;jongmog-seontaeg-mueoseul-sal-geosinga&quot;&gt;종목 선택 - 무엇을 살 것인가&lt;&#x2F;h2&gt;
&lt;p&gt;일단 기본적으로, 채널이 넓어야 한다. 채널이 넓지 않으면 많이 못먹기 때문. 이게 그냥 단순히 많이 못먹는게 문제가 아니다. 트레이딩의 성적을 계산할 때에는 이 채널에서 얼마나 많이 먹었는지를 기준으로 한다. 따라서, 채널이 좁은 경우, 아무리 좋은 성적을 내도 이득을 크게 보지 못한다. 그리고 거래비용을 지불해야 함. 남좋은 일만 하는 꼴이다.&lt;&#x2F;p&gt;
&lt;p&gt;또 한 가지, 많은 종목을 전체적으로 보기보다, 주종목으로 할 몇몇 종목을 골라서 그것만 파는게 유리하다고 함.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;idongpyeonggyunseoneul-tonghan-cuse-paag-jigeum-eoddeonga&quot;&gt;이동평균선을 통한 추세 파악 - 지금 어떤가&lt;&#x2F;h2&gt;
&lt;p&gt;이동평균선, 그 중 지수이동평균을 권장함. 여튼 이 선을 이용해서 상승장인지 하락장인지 추세를 파악하면 된다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;yesangdoeneun-cuse-banjeon-jijeomi-issneunji-hwagin-teugbyeolhan-gihoega-issna&quot;&gt;예상되는 추세 반전 지점이 있는지 확인 - 특별한 기회가 있나&lt;&#x2F;h2&gt;
&lt;p&gt;MACD 히스토그램. 이 중 다이버전스를 포착한다면 좋은 기회가 될 수 있음. 다이버전스는 여러번 읽고 나서야 이해할 수 있었다. 상승 다이버전스는 가격이 두 번 이상 저점을 찍을 때, MACD 히스토그램의 두 바닥을 비교하면 상승하는 경우이다. 하락 다이버전스는 가격이 두 번 이상 고점을 찍을 때, MACD 히스토그램의 두 천정을 비교하면 하락하는 경우. 이 다이버전스의 경우, 자주 있는 일은 아니지만, 일어나는 경우 꽤 좋은 신호가 된다고 함. 약간 이벤트같다고 해야 하나.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;maesu-maedo-sijeom-paag-eonje-sago-pal-geosinga&quot;&gt;매수&#x2F;매도 시점 파악 - 언제 사고 팔 것인가&lt;&#x2F;h2&gt;
&lt;p&gt;책의 저자가 개발한 강도지수라는게 있다. 이걸 이용해서 이동평균을 구하면 매수&#x2F;매도 시점을 파악하기 좋다고 함. 2일 강도지수 이동평균을 이용했을 때, 만약 상승장의 경우 이 값이 음수인 경우 매수 타이밍, 반대로 하락장에서 이 값이 양수인 경우 매도 타이밍이라 함. 일시적으로 반전이 일어나는 케이스를 포착할 수 있음.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;cuse-jaegaeyeobu-paag-jigeum-i-sangtaeneun-ilsijeogin-geosinga&quot;&gt;추세 재개여부 파악 - 지금 이 상태는 일시적인 것인가&lt;&#x2F;h2&gt;
&lt;p&gt;이 역시 책의 저자가 개발한 엘더-레이라는게 있다. 반전이 포착되었을 때, 이전의 추세를 여전히 가져갈것인가를 알 수 있다고 함. 상승추세에서 매도 강도가 음수에서 양수로 올라가는 경우 상승이 재개되고, 하락 추세인데 매수강도가 양수에서 음수로 전환되는 경우 하락이 재개된다. 그냥 보면 당연해 보이기도 하다.&lt;&#x2F;p&gt;
&lt;p&gt;아 참고로, 매도강도는 작을 수록 강한 것이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;wiheomyoso-hoepi-i-pojisyeoneul-cwihaedo-gwaencanheul-geosinga&quot;&gt;위험요소 회피 - 이 포지션을 취해도 괜찮을 것인가&lt;&#x2F;h2&gt;
&lt;p&gt;스토캐스틱이라는 지표가 있다. 이 지표는 과매수&#x2F;과매도 상태를 나타낼 수 있음. 저자는 주로 극단적인 상황을 막기 위해 이 지표를 본다고 한다. 마지막 단계에서 이용하면 될 것 같다. 예를 들어, 매수하고 싶은데 스토캐스틱의 상단기준선 위로 올라가 있다면 매수하지 않는다. 반대로 공매도하고 싶은데 스토캐스틱의 하단기준선 아래라면 하지 않는다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;peondeomenteole-yihan-byeonsu&quot;&gt;펀더멘털에 의한 변수&lt;&#x2F;h2&gt;
&lt;p&gt;아무리 다이버전스를 포착하고, 매수&#x2F;매도 시점 찾고 스토캐스틱으로 검증한다고 해도, 결국 기본적인 펀더멘털의 변화가 심하면 이 신호들이 의미없게 되는 경우가 있다고 한다. 저자는 이럴 때 반대 포지션을 즉시 취한다던가 하는 트레이딩적 노하우를 맛보기로 소개해 줬는데, 나같은 쩌리는 그냥 펀더멘털에 큰 변화가 찾아올 만한 주식은, 트레이딩이 아니라 투자적 관점에서 바라봐야 할 듯 하다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Linux에 카카오톡 설치</title>
        <published>2023-09-15T00:00:00+00:00</published>
        <updated>2023-09-15T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/kakaotalk-on-linux/"/>
        <id>https://xanthorrhizol.github.io/posts/kakaotalk-on-linux/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/kakaotalk-on-linux/">&lt;p&gt;리눅스의 최대 단점은 바로 카카오톡이 아닐까 싶다. 그동안 카카오톡 설치가 번거로워서 PC로는 이용 안하고 있었는데, 최근 업무 중 윈도우 어플리케이션을 돌릴 일이 있어서 wine을 좀 파보게 되면서, 다시 자신감이 붙음. 다 덤벼라.&lt;&#x2F;p&gt;
&lt;p&gt;그래서 다시 카카오톡 설치에 도전했다. 아주 가장 간단하고 기본에 가깝게. 방법은 아래와 같다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;wine-wine-mono-wine-gecko-seolci&quot;&gt;wine, wine-mono, wine-gecko 설치&lt;&#x2F;h2&gt;
&lt;p&gt;배포판은 신경쓰지 말자. wine은 말그대로 wine, wine-mono는 wine의 .NET 프레임워크 이용을 위한 패키지, wine-gecko는 Internet Explorer를 위한 패키지이다. IE에 대한 본능적 거부감에 일단 wine-mono까지만 설치하고 카톡 실행을 해봤더니, 결국 안돼서 이것도 마저 설치했음.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;wine-hwangyeongseoljeong&quot;&gt;wine 환경설정&lt;&#x2F;h2&gt;
&lt;h3 id=&quot;winecfg&quot;&gt;winecfg&lt;&#x2F;h3&gt;
&lt;pre data-lang=&quot;bash&quot; class=&quot;language-bash &quot;&gt;&lt;code class=&quot;language-bash&quot; data-lang=&quot;bash&quot;&gt;winecfg
&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;위의 커맨드를 실행하면 뭔 창이 하나 뜰 것이다. 그냥 OK 하면 wine 환경이 구성됨. 구성되는 환경은 아래와 같다.&lt;&#x2F;p&gt;
&lt;pre data-lang=&quot;bash&quot; class=&quot;language-bash &quot;&gt;&lt;code class=&quot;language-bash&quot; data-lang=&quot;bash&quot;&gt;$HOME&amp;#x2F;.wine
&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;여기를 들어가보면 매우 익숙한 구조가 나옴. 맞다. 말그대로 윈도우의 디렉터리구조가 보인다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;hangeul-ponteu-cuga&quot;&gt;한글 폰트 추가&lt;&#x2F;h3&gt;
&lt;p&gt;카톡을 설치할 때, 설치 프로그램에서 한글이 깨지지 않게 나오게 하고싶다면, 한글 폰트를 설치하자.&lt;&#x2F;p&gt;
&lt;p&gt;방법은 간단하다. &lt;code&gt;$HOME&#x2F;.wine&#x2F;system.reg&lt;&#x2F;code&gt;에 들어가서 &lt;code&gt;MS Shell Dlg&lt;&#x2F;code&gt; 항목을 한글 지원되는 폰트 이름으로 바꾸면 된다. 폰트 리스트는 해당 라인 위로 올라가면서 쭉 보면 있을 것이다(리눅스에서 한글을 사용하는 이상 아마 있을 것).&lt;&#x2F;p&gt;
&lt;h3 id=&quot;hangeul-ibryeog-hwalseonghwa&quot;&gt;한글 입력 활성화&lt;&#x2F;h3&gt;
&lt;pre data-lang=&quot;bash&quot; class=&quot;language-bash &quot;&gt;&lt;code class=&quot;language-bash&quot; data-lang=&quot;bash&quot;&gt;wine reg add &amp;quot;HKEY_CURRENT_USER\\Software\\Wine\\X11 Driver&amp;quot; &amp;#x2F;v InputStyle &amp;#x2F;t REG_SZ &amp;#x2F;d root &amp;#x2F;f

&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;아, 참고로 kime 입력기를 이용하는 경우, kime-xim이란걸 이용해야 하는데 후술하겠다.&lt;&#x2F;p&gt;
&lt;p&gt;또, 카카오톡 설치할 때 한글 버전으로 안하고 영어 버전으로 했는데, 기본 폰트가 Arial로 되어 있어서, 한글 입력 시 다 깨졌다. 혹시 한글 입력이 안되는 문제가 있다면 카톡 설치 후 설정에서 폰트 변경하자.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;kakaotog-seolci&quot;&gt;카카오톡 설치&lt;&#x2F;h2&gt;
&lt;p&gt;지금부터 wine이 어떻게 도는지 간결하게 이해할 필요가 있다. &lt;code&gt;wine &amp;lt;exe file&amp;gt;&lt;&#x2F;code&gt; 를 실행하면, 아까 구성된 &lt;code&gt;$HOME&#x2F;.wine&lt;&#x2F;code&gt; 디렉터리 내에서 윈도우 환경처럼 exe 파일을 실행하게 된다. 아 물론, 정확히 코드 까보거나 공식문서 정독한건 아니지만, 실행하는덴 이 정도 이해만 하면 된다. 그럼, 이제 어떻게 해야 하는지 슬슬 눈치챘을 것이다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;kakaotog-seolcipail-daunrodeu-mic-silhaeng&quot;&gt;카카오톡 설치파일 다운로드 및 실행&lt;&#x2F;h3&gt;
&lt;p&gt;카카오톡 PC버전 설치파일을 다운로드하고 해당 exe 파일을 wine으로 실행한다. (&lt;code&gt;wine KakaoTalk_Setup.exe&lt;&#x2F;code&gt;)&lt;&#x2F;p&gt;
&lt;h3 id=&quot;kakaotog-silhaengpail-silhaeng&quot;&gt;카카오톡 실행파일 실행&lt;&#x2F;h3&gt;
&lt;p&gt;설치 중에 특별히 설치 디렉터리를 변경한게 아니라면 아마 &lt;code&gt;$HOME&#x2F;.wine&#x2F;drive_c&#x2F;Program\\ Files\\ (x86)&#x2F;Kakao&#x2F;KakaoTalk&#x2F;&lt;&#x2F;code&gt; 디렉터리에 &lt;code&gt;KakaoTalk.exe&lt;&#x2F;code&gt; 실행파일이 들어가 있을 것이다. 이걸 그냥 wine으로 설치파일 실행한 것과 동일한 방법으로 실행하면 된다.&lt;&#x2F;p&gt;
&lt;p&gt;난 매번 찾기 귀찮아서 스크립트로 빼놨다.&lt;&#x2F;p&gt;
&lt;pre data-lang=&quot;bash&quot; class=&quot;language-bash &quot;&gt;&lt;code class=&quot;language-bash&quot; data-lang=&quot;bash&quot;&gt;#!&amp;#x2F;bin&amp;#x2F;bash
wine &amp;quot;$HOME&amp;#x2F;.wine&amp;#x2F;drive_c&amp;#x2F;Program Files (x86)&amp;#x2F;Kakao&amp;#x2F;KakaoTalk&amp;#x2F;KakaoTalk.exe&amp;quot;

&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;h3 id=&quot;kime-sayongja-hangeulibryeog-munje-haegyeol&quot;&gt;kime 사용자 한글입력 문제 해결&lt;&#x2F;h3&gt;
&lt;p&gt;카카오톡 실행 전에 kime-xim을 실행해 놓아야 한다. 그렇지 않으면 한글 입력이 안됨.&lt;&#x2F;p&gt;
&lt;p&gt;슬슬 귀찮아질 것이다. 귀찮으면 조금만 더 힘내서 서비스로 등록하는걸 추천한다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Rust의 개꿀 라이브러리들</title>
        <published>2023-09-03T00:00:00+00:00</published>
        <updated>2023-09-03T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/rust-doghoney-libs/"/>
        <id>https://xanthorrhizol.github.io/posts/rust-doghoney-libs/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/rust-doghoney-libs/">&lt;p&gt;개인적으로 개발을 할 때, 당장 어떻게든 만들어내는건 어렵지 않게 하지만, 개발 도구를 맛깔나게 활용하지는 않는 편이다. 그냥 &#x27;요래요래 하면 될거같은데?&#x27; 하고 손부터 가는 타입. 그래서 개꿀 라이브러리를 놓치고 깡으로 손으로 짜는 경우가 많다.&lt;&#x2F;p&gt;
&lt;p&gt;그러던 중, CTO가 관리하던 코드를 물려받게 되었다. 코드가 아름답다고 한다면 이런 것일 것이다. LSTM + 강화학습 모델의 학습 인프라를 구성하는 코드리포인데, 시뮬레이션은 기본, 데이터 프로세싱까지 모두 담겨있다. 마이크로서비스를 섣불리 도입해서 삽질을 하지도 않고 바로 모노리포 구조로 잘 짜여 있었다. 여튼 개쩐다는 표현은 대충 이쯤에서 마무리하고...&lt;&#x2F;p&gt;
&lt;h2 id=&quot;structopt-argumentreul-pyeonrihage-badja&quot;&gt;structopt: Argument를 편리하게 받자&lt;&#x2F;h2&gt;
&lt;p&gt;일단 난 CLI를 더 선호한다. 그래서 왠만하면 CLI로 툴을 만드는 편이다. 그런데, bash scripting을 하는 경우가 많아서, argument를 가져올 때 손이 알아서 아래와 같이 입력한다.&lt;&#x2F;p&gt;
&lt;pre data-lang=&quot;bash&quot; class=&quot;language-bash &quot;&gt;&lt;code class=&quot;language-bash&quot; data-lang=&quot;bash&quot;&gt;if [ $# -ne 2 ]; then
    echo &amp;quot;Usage: $0 &amp;lt;hello&amp;gt; &amp;lt;world&amp;gt;&amp;quot;
    exit -1
fi
HELLO=$1
WORLD=$2

&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;그리고 이 습관은 rust까지 따라왔다.&lt;&#x2F;p&gt;
&lt;pre data-lang=&quot;rust&quot; class=&quot;language-rust &quot;&gt;&lt;code class=&quot;language-rust&quot; data-lang=&quot;rust&quot;&gt;fn main() {
    let args = std::env::args().collect::&amp;lt;Vec&amp;lt;String&amp;gt;&amp;gt;();
    if args.len() != 3 {
        eprintln!(&amp;quot;Usage: {} &amp;lt;hello&amp;gt; &amp;lt;world&amp;gt;&amp;quot;, args[0]);
    }
    let hello = &amp;amp;args[1];
    let world = &amp;amp;args[2];
}

&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;그리고 난 CTO가 물려준 코드에서 structopt를 발견했다. 아 물론, 다른 마이크로서비스에도 있었는데, 내 담당은 아니라 대충 넘겼었긴 했다. structopt를 이용하면 아래와 같이 이용할 수 있다.&lt;&#x2F;p&gt;
&lt;pre data-lang=&quot;rust&quot; class=&quot;language-rust &quot;&gt;&lt;code class=&quot;language-rust&quot; data-lang=&quot;rust&quot;&gt;use structopt::StructOpt;

#[derive(StructOpt)]
#[structopt(name = &amp;quot;opt&amp;quot;, about = &amp;quot;hello world&amp;quot;)]
struct Opt {
    #[structopt(short, long)]
    hello: String,
    #[structopt(short, long)]
    world: String,
}

fn main() {
    let Opt { hello, world } = Opt::from_args();
}

&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;코드 줄 수는 별다른 차이가 없어 보일 수 있지만, eprintln이 사라진 것을 볼 수 있다. argument를 입력받기 위한 안내를 굳이 내가 입력하지 않아도 되는 것이다. 게다가 커맨드라인 상에서 더 깔끔하게 나온다. 추가적으로, Opt struct에서 타입을 정의했다. 자료형에 대해 걱정할 필요가 없이 가져다 쓰면 된다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;serde-deiteo-pasing-jigryeolhwa-geunyang-addhaja&quot;&gt;serde: 데이터 파싱? 직렬화? 그냥 add하자&lt;&#x2F;h2&gt;
&lt;p&gt;이 라이브러리는 내부 프로토콜로서 프로토버프를 이용하면서 예전부터 이용하고 있었다. 꽤 깔끔하게 구조체를 표현할 수 있어서 좋다 정도였고, api 클라이언트를 만들 때, 사용이 아주 권장되지만, 개인적으로 작업을 진행할 때는 귀찮다고 대충 손으로 써내려가면서 만들어 왔다. 하지만, API 클라이언트를 만드는 일이 생각보다 많다. 당장, 개인적으로 작업중인 &lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;korea-investment-api&quot;&gt;한국투자증권OpenAPI&lt;&#x2F;a&gt;, &lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;open-banking-api&quot;&gt;open-banking-api&lt;&#x2F;a&gt;만 해도 API 클라이언트다. 또한 회사에서 메시지큐의 공식 라이브러리에서 지원하지 않는 Admin API를 날리는 라이브러리도 개발했는데, 이 또한 API 클라이언트이다. 그리고 이 클라이언트가 날린 리퀘스트에 대한 리스폰스를 파싱하기 위해서는... 그냥 serde 쓰자. 나처럼 손으로 다 빚어내지 않았음 한다 ㅋㅋㅋㅋㅋㅋ. 체대 아니랄까봐 신체의 스피드로 개발속도를 내고 앉아있다. 개인적으로 불편함이 어느정도 쌓여야 해소를 위해 움직이기 때문에, open-banking-api를 작업하면서 serde를 도입하게 되었다. 물론 한국투자증권API에도 serde 라이브러리를 add해놓긴 했지만, 사용해야 할 모든 곳에 제대로 사용하지는 않고 있다. 조만간 바꿔야지.&lt;&#x2F;p&gt;
&lt;p&gt;serde는 데이터의 serialize, deserialize를 지원하는 라이브러리다. derive를 통해 쉽게 serialize&#x2F;deserialize 매서드를 가져올 수 있다. 만약 이게 없으면 아래와 같이 작성해야 한다.&lt;&#x2F;p&gt;
&lt;pre data-lang=&quot;rust&quot; class=&quot;language-rust &quot;&gt;&lt;code class=&quot;language-rust&quot; data-lang=&quot;rust&quot;&gt;use json::json;

fn main() {
    &amp;#x2F;&amp;#x2F; deserialize
    let raw = b&amp;quot;{\\&amp;quot;hello\\&amp;quot;:1,\\&amp;quot;world\\&amp;quot;:\\&amp;quot;universe\\&amp;quot;}&amp;quot;;
    let parsed_json = json::parse(&amp;amp;raw).unwrap();
    let mut hello = 0;
    let mut world = String::new();
    match parsed_json {
        json::JsonValue::Object(o) =&amp;gt; {
            match o.get(&amp;quot;hello&amp;quot;) {
                Some(hello) =&amp;gt; {
                    match hello {
                        json::JsonValue::Short(n) =&amp;gt; {
                            let (positive, mantissa, exponent) = n.as_parts();
                            hello = positive as i64 * mantissa as i64 * 10i64.pow(exponent as u32);
                        },
                    }
                }
                None =&amp;gt; todo!(),
            };
            match o.get(&amp;quot;world&amp;quot;) {
                Some(world) =&amp;gt; {
                    match world {
                        json::JsonValue::String(s) =&amp;gt; {
                            world = s.to_owned();
                        },
                    }
                }
                None =&amp;gt; todo!(),
            }
        },
        _ =&amp;gt; {
            todo!();
        },
    }

    &amp;#x2F;&amp;#x2F; serialize
    let hello = 1;
    let world = &amp;quot;universe&amp;quot;.to_string();
    {% raw %}
    let serialized_message = format!(&amp;quot;{{\\&amp;quot;hello\\&amp;quot;:{},\\&amp;quot;world\\&amp;quot;:\\&amp;quot;{}\\&amp;quot;}}&amp;quot;, hello, world);
    {% endraw %}
}

&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;json::parse가 모든 것을 꼬아버렸다. 아주 귀찮다. 이걸 serde와 serde_json을 이용하면 아래와 같이 간단하게 해결된다.&lt;&#x2F;p&gt;
&lt;pre data-lang=&quot;rust&quot; class=&quot;language-rust &quot;&gt;&lt;code class=&quot;language-rust&quot; data-lang=&quot;rust&quot;&gt;use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize)]
struct ParsedJson {
    pub hello: u8,
    pub world: String,
}

fn main() {
    &amp;#x2F;&amp;#x2F; deserialize
    let raw = b&amp;quot;{\\&amp;quot;hello\\&amp;quot;:1,\\&amp;quot;world\\&amp;quot;:\\&amp;quot;universe\\&amp;quot;}&amp;quot;;
    let parsed_json: ParsedJson = serde_json::from_slice(raw).unwrap();

    &amp;#x2F;&amp;#x2F; serialize
    let message = ParsedJson {
        hello: 1,
        world: &amp;quot;universe&amp;quot;.to_string(),
    };
    let serialized_message = serde_json::to_string(&amp;amp;message).unwrap();
}

&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;serde 만세&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>PC의 OS로써 Arch Linux를 사용하는 이유</title>
        <published>2023-09-01T00:00:00+00:00</published>
        <updated>2023-09-01T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/arch-linux-as-main/"/>
        <id>https://xanthorrhizol.github.io/posts/arch-linux-as-main/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/arch-linux-as-main/">&lt;p&gt;난 아치리눅스(Arch Linux)를 메인 OS로 이용하고 있다. PC는 물론, 노트북, 회사 업무용 PC까지 모두 아치리눅스이다.&lt;&#x2F;p&gt;
&lt;p&gt;아치리눅스를 쓰게 된 계기는, 회사의 CTO가 아치리눅스를 사용하셨는데, 꽤 재미있어 보였기 때문이었다. 뭔가 저걸 하면, 그냥 자연스럽게 따라오는 것들이 있을 것 같았다.&lt;&#x2F;p&gt;
&lt;p&gt;백문이 불여일견. 바로 트라이했다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;gwanmundeul&quot;&gt;관문들&lt;&#x2F;h2&gt;
&lt;h3 id=&quot;gwanmun-1-os-seolci&quot;&gt;관문 1. OS 설치&lt;&#x2F;h3&gt;
&lt;p&gt;당시까지 써봤던 설치 USB는 설치를 위한 GUI가 뜨는게 대부분이었다. 최소한 TUI더라도 설치를 진행하는게 바로 진행되는, 설치만을 위한 절차가 진행되었다.&lt;&#x2F;p&gt;
&lt;p&gt;그런데 아치리눅스 설치 USB를 만들어서 USB로 부팅했더니, 그저 검은 리눅스 커맨드라인이 하나 나왔다. 띠용? 하고 찾아보니, 설치를 위한 리눅스가 실행된 것이다. 아치리눅스를 PC에 설치하기 위해서는 커맨드라인을 이용하여 파티셔닝과 마운트를 진행하고, 이걸 부트로더에 등록하는 절차를 거치고, 마운트한 디렉터리 중, &#x2F; 디렉터리가 되는 곳에서 아치리눅스 환경을 설치해야 했다. 이 때 필요한 것을 설치하지 않으면 리눅스 부팅에 성공한다고 해도 반쪽짜리가 된다. 특히 노트북에 설치하는데, 와이파이를 이용해야 하는 경우... 그냥 집 가서 랜선 이용하는걸 추천한다. 정신건강에 좋지 않다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;gwanmun-1ro-eodeun-geos-manneung-haekingusb&quot;&gt;관문 1로 얻은 것: 만능 해킹USB&lt;&#x2F;h3&gt;
&lt;p&gt;아니 이거 지금보니, USB로 부팅하면, 루트잖아? 어딜 가든 이 USB 하나 있으면 이 USB로 부팅해서 자료를 뜯어낼 수 있다. 아 물론 암호화되었다면 할 수 없겠지만. 근데 암호화 파티션 구성하는게 꽤 귀찮아서 거의 안할 것이다. 물리적 보안이 중요한 이유다.&lt;&#x2F;p&gt;
&lt;p&gt;뭐 그렇더라도 내가 이걸 진짜 해킹에 이용하진 않는다. 굳이 밥벌어먹는데 문제 없는데 할 이유가 없다. 아 밥 벌어먹는데 문제 있어도 굳이 앞으로 더 힘들어지게 그럴 이유가 없다. 가끔 퇴사자가 남겨둔 PC에 로그인이 불가한데 OS를 재설치해야 하는 경우 자료 백업을 위해 이용한다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;gwanmun-2-gui-seolci&quot;&gt;관문 2. GUI 설치&lt;&#x2F;h3&gt;
&lt;p&gt;사용자친화적인 리눅스들은 처음에 gui 설치 여부를 선택하면 알아서 설치해 준다. 그래서 왠만하면 건들지 않고, 최적화된 윈도우 매니저를 이용하게 된다. 아치리눅스는? 그런거 없다. 그래서 CTO가 자신이 아치리눅스에 bspwm 올리고 뭐시기 뭐시기로 개발한다 했던 것을 떠올려서 bspwm을 검색해서 겨우 하나 찾아서 따라했음. 그리고 쓸만한 환경을 구성하기 위해서는 bspwm 뿐만 아니라 설치할 것들이 더 많았다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;gwanmun-2ro-eodeun-geos-os-seolcireul-dasi-hal-ddae-pyeonhage-hagi-wihan-ggoereul-burigi-sijagham&quot;&gt;관문 2로 얻은 것: OS 설치를 다시 할 때 편하게 하기 위한 꾀를 부리기 시작함&lt;&#x2F;h3&gt;
&lt;p&gt;사실 OS 설치 자체는 그리 어렵지 않았다. 유선 환경이면 몇 번 해보면 익숙해지고, 까먹으면 살짝 검색해 보면 됨. 문제는 GUI 구성은 자잘자잘한게 많아서 다 기억하기 어려움.&lt;br &#x2F;&gt;
그래서 GUI 구성을 위해 이용했던 ~&#x2F;.config 디렉터리를 백업해 두게 되었다. 사실 설치 스크립트도 만들까 하다가 안했는데, 정말 한 번만 더 재설치할 일 있으면 정말 만들 것이다. 그리고, 외장 SSD를 구매해서 거기에 아치리눅스와 GUI를 설치했다. 그리고 intel, amd cpu 모두 호환되도록 설치해서 intel cpu인 PC와 amd cpu인 노트북 모두 이 SSD로 부팅해서 동일한 환경을 이용하고 있다. 짐이 좀 늘고, 부팅하기 위해 외장SSD를 꽂는게 조금 불편하긴 한데, 아무데서나 동일한 환경으로 부팅할 수 있으니 좋다. 아 그리고 이것도, 따지고 보면 만능 해킹 외장 SSD다. 그리고 가끔 수틀리면, 주인의 동의를 구하고 이 SSD를 이용해서 다른 사람의 PC를 빌릴 수 있다. 그리고 내 환경 그대로 이용할 수 있음.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;gwanmun-3-gagjong-peurogeuraem-seolci&quot;&gt;관문 3. 각종 프로그램 설치&lt;&#x2F;h3&gt;
&lt;p&gt;아치리눅스의 패키지 매니저는 pacman이다. 그리고 AUR이라는걸 이용할 수 있는데, 난 AUR Helper로 yay를 이용한다. 그런데 아치리눅스가 마이너하다 보니, pacman은 물론 yay에서도 조회되지 않는 프로그램이 가끔 있다. 그럼 공식 홈에서 받게 될텐데, 데비안 계열이나 페도라 계열은 쉽게 설치할 수 있는 패키지 파일이 제공되지만, 다른 리눅스는 그런거 없다. tar.xz를 대부분 이용한다. 받아서 makepkg 등의 절차를 거쳐야 한다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;gwanmun-3euro-eodeun-geos&quot;&gt;관문 3으로 얻은 것&lt;&#x2F;h3&gt;
&lt;p&gt;tar.xz만 있으면 어디든 설치 가능한거네? 를 깨우침&lt;&#x2F;p&gt;
&lt;h2 id=&quot;acirinugseureul-sayonghandamyeon&quot;&gt;아치리눅스를 사용한다면?&lt;&#x2F;h2&gt;
&lt;h3 id=&quot;vim&quot;&gt;Vim&lt;&#x2F;h3&gt;
&lt;p&gt;vim 써줘야 한다. 이게 완전체라고 본다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;vimeuro-gaebalhamyeon-joheun-jeom&quot;&gt;vim으로 개발하면 좋은 점?&lt;&#x2F;h3&gt;
&lt;p&gt;일단, vim 세팅을 제대로 하면, 꽤 편하다. 게다가 ssh 접속만 하면 굳이 다른 프로그램 필요 없이 코딩이 가능하다. 추가적으로, 마우스 사용 빈도가 줄어든다. 과거 손목에 문제가 생긴 경험이 있는데 그 때 문제의 원인은 과도한 마우스 사용이었다. 당시 고객사의 클라우드에 제품을 설치하기 위해, 회사의 클라우드에서 이것저것 테스트해보고 실습해보면서 고객사에서 발생한 문제 재현해서 해결하기 위해 밤낮없이 일했던 때였다. 그 때, 하다하다 안돼서 결국 버티컬마우스를 구매했다. 지금은 12시간 코딩만 해도 손목에 아무 문제가 없다.&lt;&#x2F;p&gt;
&lt;p&gt;아 그리고, tui에 익숙해지게 된다. 보통 리눅스를 사용하더라도 vs-code같은걸 깔아두게 되면 터미널은 &lt;code&gt;code .&lt;&#x2F;code&gt;을 입력하기 위해 &lt;code&gt;cd&lt;&#x2F;code&gt;를 반복하는데 사용한다. vs-code를 켠 이후, 커맨드라인을 사용할 일은 빌드&#x2F;컴파일 할 때 정도이다. 하지만 vim으로 개발하는 경우, 왠만한건 다 명령으로 해결하기 때문에 편해지기 위해 명령을 잘 하는 법을 찾게 되고, 실력이 는다. 게다가 language server를 설치하지 않았더라도, 대충 라이브러리 위치 찾아가는 센스가 생김. 언어가 추가될 때마다 vim 세팅을 진행해야 하는데, 보통 처음엔 그냥 불편한 대로 사용하기 때문이다. 그러다가 사용 빈도가 올라가서 불편함이 가중되면 세팅을 진행한다. 그 때는 이미 해당 언어에 대해 어느정도 익숙해진 후이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;geunyang-bulpyeonhange-dain-geos-gateunde&quot;&gt;그냥 불편한게 다인 것 같은데?&lt;&#x2F;h2&gt;
&lt;p&gt;맞다. 불편하기 때문에 편해지기 위해 발악하는 과정에서 이해도가 높아진다. 그런데, 주니어일 때 아치리눅스를 사용한건 신의 한 수였던 것 같다. 왠만한 문제는 당황하지 않는다. ㅋㅋㅋㅋㅋㅋ&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>주석의 중요성</title>
        <published>2023-09-01T00:00:00+00:00</published>
        <updated>2023-09-01T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/importance-of-comment/"/>
        <id>https://xanthorrhizol.github.io/posts/importance-of-comment/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/importance-of-comment/">&lt;p&gt;모델이 할 수 있는 주문의 상&#x2F;하한을 결정하는 공식을 고객사가 수정해달라고 하는 경우가 종종 있다. 문제는, 모델은 해당 공식에 대해 학습되어 있지 않은 채 프로덕션 단에서 수정해야 했다는 것이다. 빨리 고쳐야 하니 말이다. 물론 성능이 떨어질 것임은 숙지시켰지만, 이럴거면 왜 AI를 쓰는가 하는 의문이 생긴다. 여튼 우리는 개쩌는 AI를 만들어 낼 것이므로 성능 향상을 계속 지향하고 있다.&lt;&#x2F;p&gt;
&lt;p&gt;하지만 걸림돌이 몇 가지 있었다. 해당 공식에 대한 설명은, 전-전 팀장님에게 들은, 고객사에서 수정요청해서 급하게 반영한 공식에 대한 설명 뿐이었다. 심지어 내 머리 속에 유일하게 남아있었다. 대충, &quot;합성함수를 사용한다 + 그래서 이런저런 요건을 만족하는 방정식을 만들려고 하는데 + 빡세서 수치 몇 개 대입해서 하드코딩 했다&quot;. 딱 이 내용이었다. 그리고 이 내용에 대한 주석은 전혀 없었다.&lt;&#x2F;p&gt;
&lt;p&gt;이렇게 되면 코드만 보면 절대로 의도를 알아차릴 수 없다. 공식을 자세히 밝힐 수는 없지만, 파라미터의 값에 따른 case문 형식의 하드코딩이 들어간 시점에서, 이미 그 방정식의 성질은 유추할 수 없게 된다. 여튼 그래서 기억을 더듬어 다시 해당 공식의 의미는 정리해 놨다. 팀원들에게도 설명해 두긴 했는데, 문서화 했었나, 안했었나... 여튼 내 노트에 있는데 조만간 업데이트해야겠다. 주석도...&lt;&#x2F;p&gt;
&lt;p&gt;또, 고객사에서 수정해달라고 하기 전부터 이용되고 있던, 모델이 학습된 환경과 동일한 공식의 의도 또한, 주석이 없다. 다만 다행인 것은, 이건 하드코딩은 아니다. 1차함수, 지수함수, 로그함수, 합성함수가 이용되었는데, 몇 가지 상수는 있지만, 괜찮은 수준이다. 하지만 처음에 코드에서 이 공식을 뽑아낸 직후엔 의도를 파악하지 못했다가, 어제 학습 데이터 프로세싱 돌리면서 시간이 떠서 이걸 보다보니, 그제서야 파악할 수 있었다.&lt;&#x2F;p&gt;
&lt;p&gt;이 공식은 완벽하지는 않지만 생각보다 현재 고객사가 요청했었던 요건들을 어느정도 반영하고 있었다. 이걸 모르고 있었기 때문에, 현재 고객사가 요청한 것들을 만족시키기 위해, 쓸데없이 프로토콜에 새로운 필드를 심고, 두 개의 파라미터로 공식을 만들게 되었다. 그냥 하나의 파라미터로 이용하는 공식을 좀 더 가다듬으면 되었는데 말이다.&lt;&#x2F;p&gt;
&lt;p&gt;이렇게 또 소중한 경험을 쌓게 되었다(&lt;del&gt;리버스 엔지니어링&lt;&#x2F;del&gt;). 나도 평소에 주석은 좀 장황한 절차가 있는 경우 스텝에 대한 설명 정도를 적는 정도인데, 앞으로는 해당 함수의 의도도 잘 적어놔야겠다. 특히 1차함수 혹은 사칙연산의 범위를 벗어난 경우는 그 식의 의도는 물론, 함수의 성질까지 무조건 적어야겠다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Simple is the best</title>
        <published>2023-08-25T00:00:00+00:00</published>
        <updated>2023-08-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/simple-is-the-best/"/>
        <id>https://xanthorrhizol.github.io/posts/simple-is-the-best/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/simple-is-the-best/">&lt;p&gt;simple-is-the-best.md&lt;&#x2F;p&gt;
&lt;p&gt;이전까지는 회사에서 제품 설치 난이도를 줄이기 위해 쿠버네티스 설치를 간편하게 하는데 집중하고 있었다. 그러다가 문득, 쿠버네티스를 사용하는 이유에 대해 고민해보게 되었다. 고민해보게 된 이유는 간단하다. 매번 장애가 나면 대부분 네트워크인데, 이 네트워크 문제를 더 복잡하게만 만들고, 스케일아웃을 하지 않는 온프레미스 서버이기 때문에 클라우드처럼 비용 최적화를 위해 오토스케일을 할 필요가 없기 때문이다.&lt;&#x2F;p&gt;
&lt;p&gt;결론은 금방 나왔다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;kubeonetiseureul-sayonghaneun-iyu&quot;&gt;쿠버네티스를 사용하는 이유&lt;&#x2F;h2&gt;
&lt;p&gt;쉽게 말해서 한 명의 인프라 관리자가 커버할 수 있는 서버를 늘리는 것이다(일자리 냠냠). 이전엔 각 서버를 따로따로 관리하면서 진행했겠지만, 쿠버네티스를 서버에 설치하고 노드를 엮는 순간 한 관리자가 API 호출을 통해 프로세스를 원하는 노드에 쉽게 올릴 수 있다. 심지어 인프라를 코드로서 관리할 수 있게 된다. 인프라 구성을 yaml파일로 만들어 두면, 그냥 &lt;code&gt;kubectl apply -f filename.yaml&lt;&#x2F;code&gt; 한 방에 구성된다. 코드로서 관리한다는 것은 라이브러리화가 가능하다는 것도 시사한다. 마치 npm처럼 사용할 수 있는 helm이 등장한다. 클라우드 세팅까지 함께 진행 가능한 Terraform도 등장한다. 꽤 큰 변화가 아닌가 싶다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;munjejeom&quot;&gt;문제점&lt;&#x2F;h2&gt;
&lt;p&gt;소프트웨어를 제품을 타사에 설치해주는 경우, 쿠버네티스가 여기에 포함된다면, 그리고 상주인력을 파견하지 않는 형태라면, 대참사가 벌어진다. 일단 겪어본 것만 나열해 보겠다.&lt;&#x2F;p&gt;
&lt;ol&gt;
&lt;li&gt;서비스에 장애가 발생했는데, 다수의 Restart 후 etcd의 리소스 사용량이 치솟더니 호스트가 죽어버린 케이스가 발생했다. 문제를 전달받고 방문했을 땐 이미 디버깅조차 할 기회가 없었다. 디버깅을 위해 루트 권한이 필요함은 물론 기본이다.&lt;&#x2F;li&gt;
&lt;li&gt;Calico CNI를 오랫 동안 켜두면 어느 순간 멈춘다. → 매일 서비스 가동과 함께 재시작한다.&lt;&#x2F;li&gt;
&lt;li&gt;로그 용량을 제한할 정책을 제대로 만들지 않고 서비스를 방치하면 거래량이 많거나 다른 문제가 있는 경우 터진다.&lt;&#x2F;li&gt;
&lt;li&gt;리눅스의 자동 업데이트 기능으로 인해 도커 데몬이 영향을 받으면 다 터진다. → 자동 업데이트를 해제한다.&lt;&#x2F;li&gt;
&lt;li&gt;Kubeadm으로 설치할 때 발급된 API call 시 사용할 인증서의 유효기간은 1년이다. → 1년 마다 모든 고객사를 방문해서 루트 권한을 받아 인증서를 갱신해야 한다.&lt;&#x2F;li&gt;
&lt;li&gt;고객사의 쿠버네티스 버전을 업데이트하기 위해서는 루트 권한을 받아서, 현재 클러스터를 내리고, kubelet도 내리고, kubelet, kubeadm, kubectl 바이너리를 새 것으로 교체하고, 쿠버네티스의 새 버전 이미지들을 로드하여 kubeadm init만 하는 과정이면 정말 쉬울텐데... 1.18버전에서 1.21버전 올라갈 땐 몇몇 피쳐가 정식 피쳐로 바뀌면서 서비스의 yaml 파일들을 싹 업데이트해야 했고, 1.26버전을 올라갈 땐 도커 지원을 중단하는 큰 변화가 발생해서 containerd를 추가로 세팅해야 했다. 솔직히 또 1년 안에 무슨 큰 변화가 발생할 지 겁이 난다.&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;p&gt;보다시피, 쿠버네티스는 인프라를 직접 관리하는 운영자가 사용하기 위한 것이지, 타사에 납품할 제품에 심는 그런 것이 아니다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;geureom-eoddeohge&quot;&gt;그럼 어떻게?&lt;&#x2F;h2&gt;
&lt;p&gt;이미 내 눈 밖에 났다. 쿠버네티스를 날려버렸다. 내가 관리하는 마이크로서비스가 쿠버네티스에 요청을 날려서 모델을 로드할 워커의 개수와 모델에 등록할 작업의 개수를 관리하는 역할을 하는데, 여기서 쿠버네티스 환경인지 아닌지를 탐지해서 쿠버네티스가 아닌 경우 해당 피쳐를 off시키도록 바꿨다. 애초에 제품이 스케일아웃을 고려하여 stateless하게 개발되었기 때문에 다른 마이크로서비스들엔 딱히 이슈가 없었다. 그리고, 도커 이미지가 아닌, 바이너리로 그대로 가져다 쓰는 것도 문제 없도록 했다. 물론, 새 고객사엔 podman으로 서비스를 운영한다. 도커 이 살찐고래는 너무 많은 권한을 가지고 있다. 단지 포트 열고 통신하고 로직을 돌릴 프로그램을 적재하는데 루트권한은 투머치다. podman은 루트가 필요없다. 만만세. 아, 그리고 이후 시간이 날 땐 rpm, deb 패키징도 해볼 생각이다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;gyeolgwa&quot;&gt;결과&lt;&#x2F;h2&gt;
&lt;p&gt;편해졌다.&lt;&#x2F;p&gt;
&lt;p&gt;그런데, 뜬금없이 이 과정에서 엄청난 일이 발생했다. 사용하고 있는 메시지큐의 리소스 요구량이 확 줄어든 것이다. 기존엔 2000개 동시작업을 처리하기 위해 broker와 bookie를 3개씩 올리고 거기다 각각 3cpu를 할당하고, 워커에 4개를 할당하고 zookeeper, proxy까지 합하면 최소 25cpu를 할당해야 했는데, 그냥 standalone 이미지 하나로 올리니, 12-thread cpu 서버에서 2000개 잡을 비슷한 수준의 레이턴시를 보이며 돌려버렸다.&lt;&#x2F;p&gt;
&lt;p&gt;결국, 2.0의 흔적은 신규 학습에서 제외된 몇몇 모델을 제외하고, 대부분 사라졌다. 물론 사내에서 실장 레코드를 쌓기 위한 서버는 여전히 쿠버네티스를 이용 중이다. 실시간으로 관리하고 있으니까 말이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>존버록</title>
        <published>2023-07-30T00:00:00+00:00</published>
        <updated>2023-07-30T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/jonbeorok/"/>
        <id>https://xanthorrhizol.github.io/posts/jonbeorok/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/jonbeorok/">&lt;p&gt;난 현 회사의 제품 1.0 버전이 성공하여 2.0 버전 개발을 완료한 후 설치를 앞두고 있던 시기에 입사했다. 2.0 버전은 B2B2C까지도 가능한 시스템을 목표로 하여, 고객사의 클라우드에 설치를 진행하는 IaaS 형태로 설계, 개발되었다.&lt;&#x2F;p&gt;
&lt;p&gt;그래서인지, 구조가 매우 복잡하였다.&lt;&#x2F;p&gt;
&lt;p&gt;먼저, 6개의 마이크로서비스로 서비스가 분리되었다. 그리고 각 서비스는 stateless한 구조로 개발되어, 쿠버네티스 클러스터에 디플로이되었다. 그리고, stateless한 서비스의 상태 복구를 위해 DB를 이용했는데, 복구만을 위해 이용하니, 그냥 팟으로 같이 올렸다. 마이크로서비스로서 동작하기 위해, 또한 작업 등의 상태 복구를 위해 persistence한 메시지큐도 필요했다. 그리고 이 메시지큐로 채택된 것은 Apache Pulsar. IaC도 이용했다. helm chart와 terraform을 구성한다. 로깅도 빠질 수 없다. Elasticsearch + Fluentbit + Kibana 스택을 이용한다. 장애대응도 해야 한다. Kibana에서 Cloudwatch 메트릭을 쏴서 고객사에 문제 알림이 가능하도록 세팅해 줬다.&lt;&#x2F;p&gt;
&lt;p&gt;아닛? 보안 컴플라이언스? 코드를 고객사 서버에서 빌드하는데 CI&#x2F;CD로 해달라고? 고객사 jenkins에 세팅해 줬다. 파일 반출이 간단하지 않다. 그냥 남겨둠. 보안? 그러고보니...? 네, 방화벽 타이트하게 쪼아주세요. 정신없이 VPC와 subnet, 그리고 EKS, ES 등의 매니지드서비스의 엔드포인트들을 이어가면서 방화벽 작업도 진행했다. 보안은 끝이 없다. 서비스의 IP를 고정해주세요. 네? 쿠버네티스 클러스터의 IP를 고정하라고? nginx로 로드밸런서 켜서 어떻게든 고정해줌. 아니 또 이 로드밸런서 키니까 any allowed 방화벽 룰이 추가되네? 다시 쪼아줌.&lt;&#x2F;p&gt;
&lt;p&gt;...(후략)&lt;&#x2F;p&gt;
&lt;h2 id=&quot;nuncicaessgessjiman-deureonaneun-hangye-feat-sogyumo-tim&quot;&gt;눈치챘겠지만, 드러나는 한계 feat. 소규모 팀&lt;&#x2F;h2&gt;
&lt;p&gt;하지만 갈수록 한계가 드러났다. 6개의 마이크로서비스, 메시지큐, 디플로이를 위한 IaC들, 고객사의 요청에 따른 자잘한 커스터마이징들... 그와중에 terraform은 신나게 만들어 놓고, 고객사에서 사용을 거부하여 결국 손으로 세팅해야 했다.&lt;&#x2F;p&gt;
&lt;p&gt;가장 문제는 인원이었다. 상기한 것들을 감당하는 사람의 수는 초기엔 6명, 퇴사와 충원을 거처 4명이 되었다. 보통 한 팀이 하나의 마이크로서비스를 맡는다고 알고 있는데, 이 팀은 한 명이 여러 개의 마이크로서비스를 관리해야 했다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;jonbeoneun-seungrihanda-feat-3-0&quot;&gt;존버는 승리한다 feat. 3.0&lt;&#x2F;h2&gt;
&lt;h3 id=&quot;gwanripointeu-juligi&quot;&gt;관리포인트 줄이기&lt;&#x2F;h3&gt;
&lt;p&gt;분산된 마이크로서비스 중 기능이 겹치는 서비스들을 합쳤다. 그 결과, 6개의 마이크로서비스는 3개로 줄었다. 또한, 필요없는 레이어를 날려버렸다. SI처럼 타사에 설치를 해주는 상태에서 IaC는 사치였다. 일단 나 말고 아무도 못알아봄. helm chart를 날리고 모두 kubectl로 바로 deploy 가능하게 yaml파일을 구성했다. terraform은 애초에 2.0 설치하면서 고객사가 거부하여 못쓰게 되어 구경도 안해봤으므로 패스. 그냥 갖다버렸다. 추가로, 모 증권사만 이용하는 클라우드는 해당 증권사 전용이므로, 온프레미스 환경을 표준으로 삼고 bare-metal 설치를 중심으로 관리하면서, 혹시 클라우드를 이용하는 경우 온프레미스 환경에서 필요한 부분만 바꿔서 이용하는 방향으로 변경하였다. 아 그리고, 클라우드를 이용하던 그 증권사도 결국 엄청난 비용에 경악하며 온프레미스로 전환하였다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;kodeubeiseu-rinyueol&quot;&gt;코드베이스 리뉴얼&lt;&#x2F;h3&gt;
&lt;p&gt;마이크로서비스를 통합하면서 구조를 변경하는 김에, 담당하던 마이크로서비스를 완전 리뉴얼하였다. 당시 난 레이어드패턴에 대해 막 배워가던 시절이었다. 근데, 난 개념을 배웠을 때 아무렇게나 응용하는게 특기라서, 액터 구조랑 혼합했다. type, interface, actor, loop, util 이렇게 5가지 요소로 나누었고, actor는 데이터 계층과 연결되는 interface를 이용하는 역할과, 동기화 이슈가 있을 수 있는 리소스를 관리하는 역할을, loop에는 비즈니스 로직을 몰아넣고, util엔 길고 가독성 떨어지거나, 반복적인 로직을 함수로 빼다가 넣었다. type은 말그대로 type.&lt;&#x2F;p&gt;
&lt;p&gt;그 결과, 내가 짠 코드라서 그런건지, 아니면 비즈니스로직이 한 군데에 몰려있어서 그런지는 모르겠지만, 이전엔 1~2주 걸리던 피쳐들을 하루이틀에 쳐낼 수 있게 되었다.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;seolci-nanido-juligi&quot;&gt;설치 난이도 줄이기&lt;&#x2F;h3&gt;
&lt;p&gt;고객사에 설치 작업을 할 때 진행되는 과정 중 가장 어려운 것은 쿠버네티스 설치이다. 인터넷이 안되는 환경으로 필요한 바이너리와 이미지를 한 번에 들고가서 진행해야 하기 때문이다. 그런데, 그동안은 이 준비 과정을 매뉴얼하게 진행하고 있었고, 무슨 비급같이 생긴 문서를 참고하며 진행하였다.&lt;&#x2F;p&gt;
&lt;p&gt;네 잘하고 있어요. 하지만 쿠버네티스는 버전업 주기가 빠르답니다? 하하하하ㅏ핳....&lt;&#x2F;p&gt;
&lt;p&gt;설치할 때마다 대작업이었다. 그래서 설치 준비과정을 자동화했다. 그 김에 그냥 인터넷 될 때 이용하는 설치 스크립트도 같이 만들어서, 사내에서 이용하는 테스트용 서버 구축도 쉽게 되도록 했다.&lt;&#x2F;p&gt;
&lt;p&gt;문제는 1.26버전부터 dockershim 지원 중단... 그래서 싹 다시 짰는데 내 개발PC와 CI 서버에만 세팅 성공하고 고객사 설치는 아직 실패해서 1.22버전에 머물러 있다... 하지만 이 버전은 공식지원 종료라고 알고 있어서, 조만간 업그레이드해야함.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;jonbeo-seungri&quot;&gt;존버 승리?&lt;&#x2F;h3&gt;
&lt;p&gt;승리한 듯 하다. 난 한동안 편해졌다. 그리고 새 역할이 추가되었다. 어...?&lt;&#x2F;p&gt;
&lt;p&gt;아 싫진 않다. 원래 인프라쪽 담당이라 리서치와는 좀 멀었는데, 추가된 새 역할은 리서치의 학습과 연관된 일이라서, 뇌가 덜심심하다. 인프라는 이건 이런데 저건 저렇고 그래서 이걸 바꾸면 또 저게 어쩌고 하는 정신없는 와중에 정신줄 붙잡는 느낌인데, 이쪽은 문제푸는 느낌이다. 인프라 하다가 현타오면 리서치쪽 업무 건들다가 진빠지면 인프라 건드리고 하면 됨.&lt;&#x2F;p&gt;
&lt;p&gt;또한 서비스 안정성이 미친듯이 높아졌다. 원래 우리 서비스는 성능은 좋지만 그와 동시에 장애의 아이콘이었는데, 내심 앞으로가 좀 기대된다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;eodeun-geos&quot;&gt;얻은 것&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;서비스 안정성&lt;&#x2F;li&gt;
&lt;li&gt;직무능력&lt;&#x2F;li&gt;
&lt;li&gt;처우개선&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;ilheun-geos&quot;&gt;잃은 것&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;2.0을 유지하다가 번아웃되어 사라진 팀원들&lt;&#x2F;li&gt;
&lt;li&gt;눈알의 수분&lt;&#x2F;li&gt;
&lt;li&gt;건강&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;baeun-jeom&quot;&gt;배운 점&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;Simple is the best&lt;&#x2F;li&gt;
&lt;li&gt;유지보수를 신경써서 설계하자&lt;&#x2F;li&gt;
&lt;li&gt;힙해보이면 일단 다시 한 번 생각해보자&lt;&#x2F;li&gt;
&lt;li&gt;이력서 쓰기 좋은 테크스택은 이런거구나&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>시스템 트레이딩 도전</title>
        <published>2023-07-25T00:00:00+00:00</published>
        <updated>2023-07-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/system-trading-0/"/>
        <id>https://xanthorrhizol.github.io/posts/system-trading-0/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/system-trading-0/">&lt;p&gt;핀테크 분야에 있다보니, 개발을 진행할 수록 금융에 대해 알아야 할 것들이 많아져서 내친김에 기본 지식도 갖출 겸 트레이딩 서적을 구매했다. 하지만 책만 읽으면 재미없을까봐 내친 김에 시스템 트레이딩에 도전하기로 했다. 그리고, Python 쓰면 재미없을까봐 내친 김에 Rust로 개발하기로 했다. 그리고, 트레이딩 서적을 그냥 읽기만 하면 기억이 안날 수 있으니, 계산식들을 직접 구현하고 있다. 그리고, Rust 개발자로서... 왠만하면 라이브러리가 없다는 고충을 잘 알기에, 계산식들은 물론 사용할 증권사의 OpenAPI 호출 로직까지 따로 빼내어 클라이언트 라이브러리로 만드는 중이다.&lt;&#x2F;p&gt;
&lt;p&gt;겸사겸사 끝판왕인 듯 하다.&lt;&#x2F;p&gt;
&lt;p&gt;아 물론, 메인 전략은 private이다. 안알랴줌. 물론 아직 존재하지도 않는다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;nareumyi-gyehoeg&quot;&gt;나름의 계획&lt;&#x2F;h2&gt;
&lt;ol&gt;
&lt;li&gt;일단 주식 현금주문, 정정&#x2F;취소주문, 시세 OpenAPI 정상 작동하도록 완성(&lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;korea-investment-api&quot;&gt;korea-investment-api&lt;&#x2F;a&gt;)&lt;&#x2F;li&gt;
&lt;li&gt;OpenAPI의 시세 스트림으로부터 &lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;trading-toolkit&quot;&gt;trading-toolkit&lt;&#x2F;a&gt;의 각종 수치들을 계산해서 HTS의 수치랑 비교해서 맞는지 확인, 틀리면 버그픽스&lt;&#x2F;li&gt;
&lt;li&gt;라이브러리 문서화&lt;&#x2F;li&gt;
&lt;li&gt;트레이딩 책에 나온 대로 아주 기본적인 전략 하나 구현 -&amp;gt; 평가 시작&lt;&#x2F;li&gt;
&lt;li&gt;고유한 전략 제작 -&amp;gt; 평가 반복&lt;&#x2F;li&gt;
&lt;&#x2F;ol&gt;
&lt;h2 id=&quot;alriji-anhgoseoneun-mosbegineun-sabjil&quot;&gt;알리지 않고서는 못베기는 삽질&lt;&#x2F;h2&gt;
&lt;p&gt;주식 현금주문 response의 status가 500으로 뜨는데 body조차 출력되지 않는 초유의 사태가 발생했다. 설상가상으로, 시니어인 팀장님이, OpenAPI 관리가 생각보다 개떡이라, 문서와 다른 경우가 있어 하나하나 찾아야 한다는 정보를 주셨다. 그래서 각종 auth 관련 리퀘스트도 싹 다 확인하고, 파라미터 대소문자, 언더바 바꿔보기 등 별의 별 짓을 다해보고 있었다.&lt;&#x2F;p&gt;
&lt;p&gt;윈도우 가상머신을 띄워서 과거 API 신청한 내역까지 다시 살펴봐도 별다른 문제는 없어 보였다.(그나저나 고작 API 신청한 계좌가 뭔지 보는데 윈도우 켜게 만드네. 화가 난다. 개발자센터는 왜 있는거임? 쓸 기능도 없는데 로그인은 왜 함?) 그러던 중, 그냥 curl로 호출해 보기로 했다. 왜 진작 안해봤을까. curl로 리퀘스트를 날리니, 사실 body가 있었다. 그리고 계좌번호가 틀렸다는 꿀정보를 담고 있었다.&lt;&#x2F;p&gt;
&lt;p&gt;띠용? 하고 다시 고생스럽게 켠 윈도우에서 계좌번호를 확인해보니, 뒷자리 3개가 달랐다. 그리고 그제서야 전에 모의투자 계좌를 재발급받았던 것이 떠올랐다............&lt;&#x2F;p&gt;
&lt;p&gt;그럼 이 문제의 원흉을 다시 색출하면 어느 놈일까.&lt;&#x2F;p&gt;
&lt;p&gt;답은 내가 짠 소스에 있다.&lt;&#x2F;p&gt;
&lt;pre data-lang=&quot;rust&quot; class=&quot;language-rust &quot;&gt;&lt;code class=&quot;language-rust&quot; data-lang=&quot;rust&quot;&gt;println!(&amp;quot;{:?}&amp;quot;, response);

&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;잡았다 요놈!&lt;&#x2F;p&gt;
&lt;p&gt;response의 자료형에서 derive했을 Debug trait 탓이다. Debug trait을 impl하면서 fmt를 구현할텐데, 여기다 body를 안넣어놓은 것으로 보임. 그래서 header 까지만 딱 출력되고 body는 저기 어디 숨어서 코빼기도 보이지 않았던 것이었다.&lt;&#x2F;p&gt;
&lt;p&gt;결론: 사실 이 문제의 원흉은 진작에 curl 안 때려본 본인이다.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Rust를 업무에 사용하면서 느끼는 점들</title>
        <published>2023-06-25T00:00:00+00:00</published>
        <updated>2023-06-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/posts/rust-feeling/"/>
        <id>https://xanthorrhizol.github.io/posts/rust-feeling/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/posts/rust-feeling/">&lt;p&gt;현재 다니고 있는 회사의 소속팀에서는 Rust를 주 언어로 채택했다.&lt;br &#x2F;&gt;
도입하신 분이 말씀하시길, 속도를 포기하지 않을 때 쓸 수 있는 언어는 C, C++, Rust 정도인데, C, C++은 개발자 마다 스타일이 천차만별이라서 Rust를 채택했다고 한다. 물론, 그 이외에 보안성 등은 말할 것도 없을 것이다.&lt;&#x2F;p&gt;
&lt;p&gt;여튼, 이 언어를 근 2년 가까이 사용하다 보니, 거의 적응이 된 듯 한데, 뭔가 불편하면서 편하다. 역설적인데, 딱 이렇게 느끼는 중이다. 애증의 관계이기도 하고. 근데 내 성격엔 이게 맞는 듯 하다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;1-keompailreoga-ilgeosuiltujog-gamsihamyeonseo-ddanjireul-geonda-gareucyeo-junda-v&quot;&gt;1. 컴파일러가 일거수일투족 감시하면서 (딴지를 건다 &#x2F; 가르쳐 준다[v])&lt;&#x2F;h2&gt;
&lt;p&gt;이 컴파일러는 단순히 이걸 바이너리로 빌드했을 때 프로그램으로서 잘 돌 것인가만 중요한게 아니다.&lt;br &#x2F;&gt;
다른 언어였으면 런타임에서 오류가 발생할 것들도, rust는 일부 잡아줄 수 있을 정도로 빡세다. 그리고 이건 rust의 소유권과 라이프타임 개념에서 오는데, 쭉 써오면서 느낀 점을 단순히 표현해 보자면, 아나바다 운동을 철폐하라는것이다. 아껴쓰고 나눠쓰고 바꿔쓰고 다시쓰다가 취약점 발생해서 쉘 뜯기지 말라는거.&lt;&#x2F;p&gt;
&lt;p&gt;그래서 가끔 정말 귀찮으면 클론 범벅의 코드가 된다. 이것도 신경 좀 쓰면 최소화 할 수 있는데, 당장 급해서 막 짜다 보면 뭔 문장 끝마다 clone을 남발하고 있다. 만약 C&#x2F;C++이랑 퍼포먼스 비교했을 때 Rust가 더 떨어진다면, 아마 이 클론들 때문일 듯 하다. clone을 하지 않는 바이너리는 서로 비교했을 때 거의 똑같지 않을까 싶다.&lt;&#x2F;p&gt;
&lt;p&gt;그래서, copy를 잘못하거나, 포인터를 잘못 이용해서 뜻밖의 곳에서 수정이 일어나는 등의 사소하고 찾기 힘든 것들은 왠만하면 거의 일어나지 않는다. 덕분에 지금까지 발생한 버그들은 대부분 비즈니스 로직이나, Network 문제, 비동기 이슈 이 세 가지 안에서만 일어났다.&lt;&#x2F;p&gt;
&lt;p&gt;반대로 불편한 점도 있는데, 라이브러리를 만들 때이다. 최근 회사에서 actor 구조를 라이브러리로 만들었다가 재밌어서 왠만한 돌려쓸 수 있을 것 같은 것들은 다 라이브러리로 빼서 만들고 있는데, 제네릭, 트레잇, 소유권, 라이프타임 이 네 가지가 콜라보되니까 난이도가 급상승한다. 심지어 컴파일러도 여기까지 오면 자기도 헷깔려서 핵심 원인을 안짚어주는 경우가 많다. 그래서 컴파일러에서 뱉는 오류 메시지들의 패턴을 익히는 중이다.&lt;&#x2F;p&gt;
&lt;p&gt;개인적으로는 &#x27;가르쳐 준다&#x27;에 한 표 던진다. 경력이 2년밖에 안되는 쩌리 개발자가 여따 대고 딴지 건다고 하면 이건 오만이다. 지금 회사가 첫 개발 커리어를 시작한 곳인데, 사수 시스템이 따로 없다. 그런데 업무 지시&#x2F;지도를 해주시는 팀장님과 함께 사수 역할을 도와준 것이 바로 rust 컴파일러다.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;2-raibeureoriga-manhji-anhda&quot;&gt;2. 라이브러리가 많지 않다&lt;&#x2F;h2&gt;
&lt;p&gt;이제는 개발을 시작할 때, 라이브러리 찾는데 시간을 별로 할애하지 않는다. 실무에서 rust를 사용하는 케이스가 아직 많지 않다 보니, 알아서 구현해야 하는 경우가 꽤 있다. &lt;a href=&quot;https:&#x2F;&#x2F;github.com&#x2F;Xanthorrhizol&#x2F;korea-investment-api&quot;&gt;한국투자증권 API&lt;&#x2F;a&gt;도 마찬가지 이유로 시작된 프로젝트다. &quot;한투 분들이 python으로 예제코드까지 방대하게 잘 구현해 놓으셨지만, rust 사용자는 python은 죽어도 쓸 수 없다며 알 수 없는 오기에 사로잡혀 스스로 API 클라이언트를 개발하게 되었다.&quot; 식의 스토리가 꽤 자주 있다. 그래서 시스템 트레이딩 전략을 만들기는 커녕 아직도 라이브러리단 개발만 이어지고 있다. 근데 뭐 이거 당장 안끝낸다고 밥 못벌어먹는 것도 아니고, 일단 재밌으니까 쭉 이어서 하고 있긴 하다.&lt;&#x2F;p&gt;
&lt;p&gt;문제는 이렇게 개발이 늘어지는걸 실무에서는 용납하지 않는다. 그래서 그냥 본인이 미친듯이 빨라져야 함. 근데 개인적으로, 갈수록 빨라져서 지금은 딱히 불편하지 않다. 다만 내가 짠 라이브러리를 돌려쓰는데 문제가 없을지 걱정되긴 한다. 아무리 라이브러리로써 개발한다고 해도 내가 담당하는 마이크로서비스에 알게모르게 맞춰지기 마련이기 때문이다. 게다가, 나중에 만약 이직하거나 퇴사하게 된다면, 인수인계를 했을 때 계속 쓸 지도 의문이다. 만약 퇴사 타이밍에 남아있을 rust 개발자들의 실력이 올라오지 않으면 제네릭, 트레잇, 매크로를 이해해서 라이브러리를 유지보수하는 것보다 각 마이크로서비스에서 따로 개발하는게 빠를 수도 있다. 물론 지금 팀원들이 그때도 계속 남으면 인수인계 쌉가능일 듯 하다.&lt;br &#x2F;&gt;
근데, 라이브러리를 직접 만드는게 재밌긴 하다. 뭔가를 만들려고 할 때 제약이 사라진다. 일단 라이브러리 없다고 포기하는 개발자는 아니게 되었다. 컴퓨터 뺨을 쎄리며 개발하는 느낌이다. 안되면 되게 하라.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;3-c-c-gwaneun-dareun-gaenyeomeuro-nopeun-jeogeung-nanido&quot;&gt;3. C&#x2F;C++과는 다른 개념으로 높은 적응 난이도&lt;&#x2F;h2&gt;
&lt;p&gt;적응하기가 쉽지 않다. C&#x2F;C++은 스타일이 너무 다양하다는 것, 그리고 메모리 누수와 취약점이 쉽게 발생하는게 어려운 요소라면, rust는 컴파일 조건이 너무 까다로워서 실행조차 해볼 수 없다는 것이 어려운 요소이다. 소유권, 라이프사이클은 그 다음의 문제이다. 비컴파일 언어를 좋아하는 개발자는 가장 극혐하는 언어가 될 가능성이 높아 보인다. 로그 찍어서 보는 것조차 허용되지 않으니, 구조를 잘 짜고, 뇌내에서 잘 기억하면서 짜야 한다(잘 메모해 두던가). 물론 그걸 해결해주는 것이 테스트코드이기 때문에, 어떤 경우엔 TDD에 아주 적합한 언어가 될 지도 모르겠다. 하지만 컴파일이 되지 않는 상태에서는 테스트코드도 실행이 안되므로, 작게 작게 완결된 코드를 짜야 한다. 안그럼 지옥을 맛볼 것이다. 덕분에 개발 습관은 잘 잡히는 것 같다고 생각한다. 아님 말고.&lt;&#x2F;p&gt;
&lt;p&gt;대충 요---런 특징들이 있는데, 이 세 가지 모두 나는 좋아한다. 일단 1번은 이미 이유를 설명했고, 2번의 경우, 원래 내가 라이브러리 대충 익혀서 가져다 쓰는걸 좋아하지 않는다. 라이브러리를 써서 빠르게 결과물을 내는 것은 회사 입장에서 아주 중요하겠지만, 개발자로서는 &#x27;라이브러리 사용법 빨리 익히기&#x27;, &#x27;라이브러리 빨리 찾기&#x27;와 같이 나이가 먹으면서 밀려날 수밖에 없는 능력만 기른다는 생각을 떨칠 수가 없다. 게다가, 이런 능력을 자신의 무기라 할 수 있을까? 토익과 같을 것이라 생각한다. 이건 당연히 어느정도 잘 해야 하는 것이고, 그 다음 무언가가 있어야 그 이상으로 올라갈 수 있을 것이라 생각한다. 아 그리고, 라이브러리 써서 빠르게 결과물을 내는게 중요한 단계의 회사라면, 십중팔구 초기 프로덕트를 만들거나 이것저것 MVP 양산하면서 되는거 하나를 찾기 위한 회사일 가능성이 높은데, 확률상 제대로된 회사는 많지 않을 것이다. 그 회사에 인생을 걸어보겠다는 각오가 없다면, 이런 능력을 요구하는 회사는 더 철저한 검증을 해봐야 할 것이다. 토익점수만 요구하는 회사는 수상할 수밖에 없다.&lt;br &#x2F;&gt;
3번의 경우, 마찬가지로 내 무기가 될 수단으로서 손색이 없기 때문에 선호한다. 어려운 만큼 따라오기도 힘들다. 물론 너무 어려우면 시장에서 사장될 수 있겠지만, 그럴 수준은 아니다. 메모리 취약점 없는 성능좋은 프로그램을 개발하는 수준에 도달하는데 1-2년 걸린다고 생각해보면, 오히려 rust는 쉬운 언어라고 해야 한다고 생각한다. 단지 러닝커브가 지수함수라서 처음에 느릴 뿐이다.&lt;&#x2F;p&gt;
&lt;p&gt;결론: X같은 rust 만만세&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Introduction</title>
        <published>2023-01-01T00:00:00+00:00</published>
        <updated>2023-01-01T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Xanthorrhizol
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://xanthorrhizol.github.io/about/"/>
        <id>https://xanthorrhizol.github.io/about/</id>
        
        <content type="html" xml:base="https://xanthorrhizol.github.io/about/">&lt;h2 id=&quot;wellcome&quot;&gt;Wellcome&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;But Why?&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;h2 id=&quot;about-me&quot;&gt;About me&lt;&#x2F;h2&gt;
&lt;p&gt;아무개: &quot;난 너가 무슨 생각을 하고 사는지 모르겠어.&quot;&lt;br &#x2F;&gt;
주인장: &quot;저도요.&quot;&lt;&#x2F;p&gt;
&lt;h2 id=&quot;about-blog&quot;&gt;About blog&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;개소리하는 블로그&lt;&#x2F;li&gt;
&lt;li&gt;사실 그냥 일기장에 가까움&lt;&#x2F;li&gt;
&lt;li&gt;일기장이라고 하기엔 정성스러워 보이지만, AI가 여기까지 갖다 놓은 것임.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</content>
        
    </entry>
</feed>
