AMD Strix Halo gfx1151 활용하기. 근데 시스템을 죽이지 않으면서.

주문해서 2주 정도를 지나고 물건을 받아 1주 정도를 굴려본 상황에서 사실 좀 후회가 된다. CUDA로는 아무 불편없이 잘만 돌아가던 로직을 ROCm으로 돌리기 위해 얼마나 시행착오를 겪는 건지.

 

첫 시도는 당연히 최신 우분투에 최신 ROCm이었다. 지금은 그나마 AMD 공식이 24.04 대응까지만 하고 있는데, ubuntu 26.04 정식 발표 때 rocm조차도 우분투 저장소 쪽에서 직접 제공할 거라는 소식이 있으니 나중엔 상황이 달라지기를 바란다.

이 첫 시도는 무참히 깨진다. amdgpu 드라이버 모듈에 이런저런 플래그를 주며 재시도를 해봤지만 꾸준히 고부하를 주고 나면 GPU 관련 작업이 먹통이 되었다.

 

그래서 AMD 공식을 믿고 아예 ubuntu 24.04.03을 깔아서 ROCm까지만 깔고 다른 플래그 설정 같은 거 없이 진행해봤다. 좀 돌다가 dmesg에 에러가 잡혀서 찾아보니 pytorch 쪽 의존성을 gfx1151에 맞춘 패키지로 바꿔야 한다는 github 이슈가 보인다. Antigravity에 이런저런 상황이라고 알려주니 뚝딱뚝딱 Dockerfile들을 고치고 몇 가지 플래그도 넣어보고 하더니 다시 nvtop에 GPU 사용률 그래프가 올라가고 냉각팬 소리가 우렁차게 돌아가는 상황이 되었다.

그래, 꼭 최신 패키지를 쓰는 게 목적이 아니고 내가 실행하고자 하는 코드가 실행이 되는 게 중요하지.

 

일단 이렇게 써보기로 한다.

 

---
라고 쓰는 와중에, GPU 그래프가 뚝 떨어지더니 이번엔 CPU를 당겨 쓰기 시작한다. 이거 이상하다고 다시 확인시켜놨다.

최소한 시스템이 갑자기 먹통이 되지는 않는다는 데서 감사함을 느낀다.

 

---

우툰부 26.04이 나와서 커널이고 ROCm이고 최신으로 맞춰지기 전까지는 다른 방법이 없어 보인다.

vulkan 기반으로 바꾸라고 제미니한테 시켜서 여러차례 결과를 보고 에러를 고치는 과정을 거친 뒤 결국 GPU가 팡팡 돌아가는 건 확인했다. CPU도 엄청나게 많이 쓰는 게 보이긴 하지만 일단 시스템이 멈추지 않는 것에 만족한다.

 

---

vulkan으로 며칠 굴려봤는데 알 수 없는 상황에서 갑자기 MES ring 어쩌구가 다시 튀어나오더니 결국 강제로 재부팅을 해야 했다. 안정화되기 전에는 정말 답이 없겠다. 

다시보는상식: 2025년 개정 한국 심폐소생술 가이드라인에서 여성 상의 속옷을 제거하지 말라는 지침

 "여성에게 자동심장충격기 사용 시, 브래지어 풀지 마세요"라는 기사 제목을 접했다. 그 아래에 "여성 심정지자, 신체 노출 등 우려 감안"이라고도 적혀 있다.

상식적으로 선뜻 납득이 되질 않아서 가이드라인 원문을 찾아봤다. 영유아 절은 따로 있지만 여성은 따로 제목은 붙지 않고 제세동기 설명하면서 두 문단이 들어가 있다.

 

 

가이드라인에 적힌 문장만 보면 '브래지어 제거로 인해 가슴을 드러내는 것을 불편하게 여기고, 부적절한 접촉과 성폭행으로 오해될 것을 두려워한다고 조사'라는 문장만으로는 정확히 무슨 연구에 근거해서 '브래지어를 반드시 제거할 필요는 없다고 권고'하게 되었는지 알 수가 없었다. (옆에 "3,12"라고 윗첨자로 붙은 건 정확히 무슨 뜻인지 이해 못했다)

 

그래서 캡쳐를 다시 OCR로 읽어서 참고문헌이 뭔지 찾아보라고 제미니한테 시켰다. (내가 미리보기 기능으로 먼저 접해서 이미지로 나왔던 거고 사실 PDF 원문은 텍스트 복사가 되는 문서여서 OCR을 돌릴 표까지는 없었다)

그래서 나온 링크는 3개.

• https://doi.org/10.1161/CIRCULATIONAHA.118.037692
• https://doi.org/10.1001/jamanetworkopen.2023.21783
• https://doi.org/10.1016/j.resuscitation.2015.09.026

마지막 129번은 금속 같은 게 남아있을 때 제세동기가 문제가 되는지 연구한 거라서 관심 거리는 아니다.

127, 128번이 걸리는데, 둘 다 제목에 bystander가 들어간다. 병원이 아니라 밖을 지나가다 갑자기 심정지로 쓰러졌을 때 옆에 있던 사람이 주체가 되는 연구인 거다.

127번은 아예 제목에 '대중의 시각'이 들어가서 이를 테면 '보통 사람들이 여성 대상의 심폐소생술을 어떻게 생각하는지 조사해봤다' 정도가 되는 연구다. 여성 스스로의 생각이 주제가 아니다.

128번은 심지어 연구자들이 일본 이름이다. 당연히 연구도 2005년부터 2020년까지의 일본 자료로 진행됐다. 경직된 일본 사회 분위기가 녹아 들 수 밖에 없다.

The barriers to receiving public access defibrillation and bystander CPR among younger females with OHCA should be addressed, and findings of this study suggest that addressing this problem can improve neurological outcomes for this population. These barriers are assumed to be anxiety over the potential allegations of inappropriate touching, sexual assault, or inflicting harm due to the physical vulnerability of female bodies as well as the misconceptions surrounding female persons experiencing medical emergencies.²⁹ These factors may prevent bystanders from providing necessary lifesaving interventions to females.²⁹ Eliminating these barriers requires legally protecting bystanders’ reasonable lifesaving actions, allowing them to help patients with OHCA without fear of being sued or penalized for mishandling. The Good Samaritan concept should be widely promoted within communities, and public education on resuscitation should be provided.

(29 링크가 위의 127번 참고문헌이다)

128번 참고 문헌으로 붙은 이 연구는 결국 '부적절한 신체 접촉으로 오해를 사거나 성폭행이거나 신체적 약자에 해를 입히는 걸로 오해 받을까봐' 걱정하는 타인의 시선이 오히려 요구조 여성에게 의료적인 도움을 주는 데 방해가 된다 말하며, 이런 오해를 줄이고 법적 보호장치를 마련해야 한다고 주장하는 내용이다.

 

그렇다면, 한국 심폐소생술 가이드라인으로 돌아와, 원래의 문장을 다시 읽어봐야 한다.

자동제세동기 적용을 위해 여성 환자의 브래지어를 제거하는 것이 필요한지에 대한 연구가 충분히 이루어지지 않았지만, 여성들은 일반인 제세동 프로그램에서 자동제세동기 적용률이 낮을 수 있다고 보고되었다.127 (왜냐하면 여자가 쓰러졌을 때 옆에 있던 사람들이 조치해주기를 주저하기 때문이다) 여성에게 심폐소생술 중 브래지어 제거로 인해 가슴을 드러내는 것을 (조치해줘야 하는 옆 사람들이) 불편하게 여기고, 부적절한 접촉과 성폭행으로 오해될 것을 (조치해줘야 하는 옆 사람 본인들이) 두려워한다고 조사되었으며, 일반인 제세동 프로그램에서 (조치해줘야 하는 옆 사람들 생각에) 여성에 대한 자동제세동기 적용 의지가 낮을 수 있다고 보고되었다.128

이렇게 뜻을 밝혀 읽어본다면, "여성 심장정지 환자에게는 브래지어를 풀거나 제거하지 않고 위치를 조정한 뒤에 가슴조직을 피하여 자동제세동기 패드를 맨 가슴에 부착할 것을 제안한다(전문가 합의 권고)."라고 2020년까지는 없던 내용을 2025년 지침에 추가한 건 '제발 엉뚱한 거 신경 쓰지 말고 당장 사람이 쓰러졌으면 도와주세요 제발 좀'이라는 절박한 선언에 가까워진다.

 

하지만 언론은 그런 거 필요없이 자극적인 제목만 뽑고, 사람들은 자연스럽게 '여성이 가슴 노출을 꺼린다'고 생각하고 어떤 관념적인 '여성'을 향해 비아냥거리고 욕한다.

제발 전문가들이 '이번 지침에 오해가 있더라'며 누가 잘 설명을 좀 해주면 좋겠다.

X11 포워딩이 애매하게 느려서 시작한 모험

1. 비디오 램 많은 AMD 시스템을 하나 더 마련했다. 원래 계획은 만들고 있던 영상분석 프로젝트를 아예 확장해서 GPU 분산처리가 되게 하는 거였다. 하지만 NVIDIA CUDA로 시작하던 때에 비해 AMD ROCm을 추가하는 건 난관이 너무 컸다. 일단 ollama 부터가 (분명 된다고 적혀 있는 것 같은데) gfx1151 11.5.1 버전을 지원하지 않았다. 11.5.0, 11.0.2, 11.0.0 등을 해봐도 제대로 되지 않아서 일단 ollama를 거치는 건 포기하고 python에 직접 모델을 올리는 방식으로 가기로 결정하고 AMD에서 잘 돌아가게 하는 단계부터 잘 다져놔야 한다.

 

2. 원래 쓰던 NVIDIA GPU 시스템은 데스크탑 겸 게임 겸 용도로 정착하고, AMD 시스템을 개발용으로 주력으로 쓰게 된다. Antigravity야 SSH 원격 접속으로 들어가서 쓰면 아무 차이 못 느끼게 이미 잘 되어 있으니 문제가 없다. 하지만 터미널 명령은 다르다. 그냥 SSH 접속해서 쓰자면 매번 탭 하나 더 열 때마다 SSH 접속도 새로 해야 되고, 여러가지로 번거롭다.

 

3. 맥에서 쓰던 iTerm2이 tmux랑 잘 연동해서 iTerm2의 탭을 여는 건데 사실은 원격의 tmux에 창이 추가되는 기능이 생각났다. 분명 리눅스끼리는 더 잘 되는 뭔가가 있을 거라는 생각이 들었다. 제미니에 물어봤더니 wezterm이라는 걸 추천해준다. 약간 기대했던 warp 터미널은 그런 기능 없다고 그런다. ghostty나 kitty라는 것도 물어봤지만 대답이 시원치 않다. wezterm으로 이것저것 해봤는데 상당히 잘 된다. 내부적으로 lua 스크립트를 지원해서 설정 자유도가 상당히 높다. 제미니한테 물어물어 하다보니 얼추 원하는 게 되었다. 그래서 wezterm을 열면 바로 원격 터미널이 열리고 탭을 열고 창을 분리하는 것도 다 유지가 되는 것까지 확인을 했다. 만족스러웠다.

 

4. 그러다가 Antigravity에 딸린 git 기능으로는 해결이 안 될 수준으로 커밋 정리를 해야 하는 상황이 생겨서 sourcegit을 띄웠다. (맥에서 쓰던 Fork와 가장 비슷하게 생겨서 선택했다) 근데 원격이다 보니 처음에는 ssh -X 통해서 띄웠는데 창 반응이 상당히 느렸다. 어차피 로컬 네트워크라 그렇게까지 느릴 건 아니지 않나 싶은데도 그랬다.

 

5. 다시 제미니와 대화했던 창으로 돌아가서 이거 뭐 해결방법 없겠냐고 물었다. 이런저런 정보를 더 주니 waypipe라는 걸 제시한다. 설명을 들어보니 기왕에 데스크탑 쪽이 wayland KDE로 정착했으니 걸맞겠다 싶어서 진행해보았다. 잘 안 되어서 debug 로그를 계속 넘겨가면서 진행하니, cargo로 xwayland-satellite라는 것도 빌드하고, 빌드할 때 필요한 파일인데 그냥은 뭔지 모르겠어서 구글에서 libclang-dev 설치하면 된다는 것도 눈치로 알아채고, xwayland 자체도 필요하다고 해서 패키지 설치하고, PATH 인식 못한다고 해서 ln -s로 /usr/local/bin에 넘기기도 했다. 양쪽 GPU가 달라서 에러가 난다길래 GPU 안 쓰는 옵션을 주기도 했다. 결국은 원격에서 sourcegit을 실행하는 게 X11 포워딩보다 꽤 빠르게 로컬 화면에서 동작하는 걸 확인했다.

 

6. 되는 건 확인했으니 이걸 좀 더 내 손이 덜 가고 투명하게 유지하고 싶다고 제미니한테 다시 물었더니 wezterm을 통하는 방법이라든지 이것저것 적다가 systemd user 서비스로 등록하는 것도 알려준다. 이런 방법도 있었지 하면서 등록해보니 과연 잘 동작한다. 이젠 wezterm을 열어 원격 터미널에 접속한 상태에서 sourcegit을 실행하면 (미리 준비되었던 waypipe를 통해) 로컬에 창이 바로 뜬다. 혹시나 해서 굳이 원격에 xterm을 깔고 실행해보니 원격 호스트명이 프롬프트에 붙은 채로 창이 잘 뜬다.

 

7. 이러면 사실상 X11 포워딩을 완전히 대체하는 통로가 하나 열린 셈이라 썩 만족스럽다. 맞춰줘야 하는 조건들이 좀 있다 보니 아무 곳에나 써먹진 못하겠지만. 제미니를 활용하면서 딱딱 원하는 걸 이렇게 잘 맞춰준 경우가 처음이라 이 경험도 만족스럽다. 물론 중간중간 얘 또 이상한 소리 한다 싶은 구간도 없진 않았지만 용납할만한 수준이었다.

제미니와 설계를 논하다

영상 파일을 처리하다 보니 용량도 크고 파일 하나에 다뤄야 할 분할 갯수도 많아져서 이런저런 버그가 종종 보인다. 그동안은 자세히 파고들지 않고 일단 동작하면 된다고 지나쳤다.

방금도 이상한 로그가 보여서 이거 뭐냐고 물어봤더니 내부 구조 설명을 뭔가 복잡해 보이게 늘어놓는다. 이번에는 이상하다 싶어서 내용을 파고들어 보니 연속적으로 넘어오는 자료를 받아서 처리할 때 끝점을 어떻게 판단하고 그에 따른 평균치 계산을 어떻게 할지의 문제였다.

이런저런 궁리를 하면서 제안을 던져봤지만 1) 성능을 살려야 한다. 2) GPU 성능을 다 쓰려면 뭉쳐서 넘겨야 한다 3) 기존 구현이 이미 그 방향이었다--는 순서로 격파당했다. 사실 GPU 성능 어쩌고 부분은 과감하게 무시할 수도 있긴 한데, 그래도 여전히 끝점 검출은 필요한 상황이라 더 파고들 여지가 없다.

연속적인 처리라고 하면 SAX 처리가 가장 먼저 생각나서 검색도 해보고 제미니 웹을 열어서 궁리도 더 해봤지만 현실적으로 지금의 구조 안에서 아주 깔끔한 뭘 더 생각할 수가 없었다.

이번에도 제안을 수용하고 또 넘어가야 할 것 같다. 다음엔 인간적이고 실제로도 해결이 되는 방법을 내놓을 수 있으면 좋겠다.

 

 ---

Harness Engineering이라거나 Compound Engineering이라거나 하는 표현들이 보이는데, 설명하는 글을 읽다가 어딘가 기시감이 들어 생각해보니 이거 그냥 '도메인을 잘 이해하고 시스템에 녹여야 한다'의 프로그래밍 버전일 뿐이었다.

그럼 그렇게 시스템화된 업무들이 나중엔 어떻게 되었는지, 예전 인력구조는 어떻게 바뀌었는지 생각해보면 앞으로의 프로그래밍 인력들의 거취도 보이겠구나 싶다. 

Gemini CLI와 Antigravity를 격리 환경에서 실행하기

코딩 에이전트를 본격적으로 쓰겠다 결심하면서 가장 신경 쓰였던 부분이 격리였다.

 

에이전트가 모든 행위에 내 검수를 거치게 하면 판단 주체가 내가 되어야 하고 그만큼 내 인지 부하도 높아지고 응답이 금방금방 생성되다 보니 계속 지켜보면서 딸깍딸깍만 해줘야 하는 상황이 된다. 여러모로 별로 좋은 상황이 아니다.

에이전트가 모든 행위에 내 검수를 거치지 않게 하면, 많은 부분이 해소된다. 다만 판단기준이 되는 GEMINI.md 파일 같은 걸 잘 줘야 하고 코드랍시고 이상한 아무말이나 쏟아내지 않도록 LSP 같은 걸 붙여서 최소한 뭐가 잘못됐는지 검사하고 알아서 고칠 수 있는 반복 경로를 만들어주기라도 해야한다.

하지만 코딩 에이전트가 내 검수를 거치지 않은 상태에서 무슨 짓을 할지 사실 예측할 수 없는 일이다. 유명한 농담이었던 rm -rf / 명령을 실제로 저질러버릴 수도 있는 거니까. (물론 특정 명령만은 검수를 꼭 받도록 하는 설정도 있다)

 

그래서 격리 또한 반드시 필요하다고 느꼈다. 통상 이런 걸 모래상자(sandbox) 안에서 놀게 만든다고 표현하고, 그래서 당연히 gemini cli sandbox 키워드로 검색했고, 이미 지원되는 방법이 있어서 적용했다. 문서가 풍성하지도 않고 사실 공식 배포된 코드가 이미지 빌드 기능을 누락하고 있어서 진행이 아주 매끄럽진 않았다. 차라리 SSH로 텅빈 가상머신을 만들어서 원격 접속하면 기술적으로는 단순해질 거였지만 GPU 장치가 있는 호스트에서 가상머신을 굴리기엔 애매하고 마음에 들지도 않아서 컨테이너를 고집했다.

샌드박스 개념 자체는 이미 알고 있는 도커로 좀 매만져주면 되는 수준이었고, npm으로 설치한 gemini cli 버전에 따라 도커 이미지의 태그를 맞춰주면 그걸 가져다 샌드박스로 쓴다는 점을 인지하고 나서는 그냥 이리저리 샌드박스 안에 필요한 환경을 갖춰나가면 됐다.

Antigravity는 Gemini CLI와는 또 달랐다. 처음엔 어느 수준까지 격리를 할 수 있는지, 그런 걸 지원하긴 하는지 정보가 없어서 많은 걸 찾아봐야 했다. Gemini CLI의 샌드박스를 어느 정도 갖추고 나니 반중력에도 어떻게 격리를 해야 할지 이해할만큼의 정보가 모였다.

Dev Container는 Antigravity의 기반이 된 VS Code에서 지원하는 기능이다. 그래서 Antigravity에도 기본적으로 존재하긴 하고 쓸 수도 있는데 어딘가 하나씩 모자란 느낌이라 구글에서 이걸 빼려고 했던 건지 아니면 그냥 우연히 다른 것뿐인지 잘 모르겠다. 도커로 치자면 docker-compose.yml 비슷한 성격이라고 할 수 있을 devcontainer.json 파일을 만져주면 된다.

 

사실 샌드박스도 데브컨테이너도 스펙을 바닥부터 이해하고 0바이트부터 파일을 작성하진 않았다. 정보를 취합하는 과정에서 웹의 제미니한테 물어보기도 하고 시중에 보이는 프로젝트에 얼핏 저런 파일이 있으면 가져다가 제미니한테 먹여서 이 파일을 이런저런 조건에 맞게 바꿔달라고도 했다. 그 결과물을 빌드해서 써보고 안 되는 거 있으면 고치는 시행착오를 반복했다. 어느 정도 경험이 쌓이고 나서는 맨 처음 받았던 초안이 엉망이란 걸 알고 역시 생성형은 믿을 수 없단 걸 절감했다. 특히 Antigravity는 더 까다로워서, 창 전체가 컨테이너 안에서 열리는 개념이 되다보니 창이 다 떴는데 설정창이 안 끝나고 멈춰있는 등의 현상이 있어서 로그를 받아다 제미니한테 다시 먹여서 물어보는 과정을 몇 번 거쳐야 했다. 모든 해결책을 다 이해하고 적용한 건 아니었지만 어쨌든 결과는 점차 개선되었다.

그리고 이틀 정도 지나고 나니 드디어 꽤 안정적이라고 할만한 격리 환경이 만들어졌다. 호스트의 도커에 직접 접근할 수 있고 이런저런 개발 도구도 갖춰져 있다. 호스트에 만들어 둔 GEMINI.md 파일도 인식해서 규칙으로 삼는다. git 커밋은 되는데 아직 git push로 깃허브에 접속하는 건 열어주지 않았다.

보안과 격리 강화를 생각하면 분명 손 볼 구석이 남아있긴 하다. 하지만 이건 차차 개선할 수 있는 일이겠고.

 

이제 자동화도 격리도 해결되었다. 문제는 제미니 구독이 부여하는 사용량이 아주 넉넉하진 않더라는 것. 그냥저냥 채팅으로 몇 마디 물어보고 답을 받아서 손으로 적용하는 정도로 쓸 때는 체감하지 못 했는데 로컬 코드를 인식하게 하고 쉘 명령을 직접 실행해서 그 결과를 보고 뭐가 잘못된 건지 파악해서 스스로 고치게 하는 방식으로 일을 시켜놓으면 몇 시간 가지 않아서 할당량을 다 쓰고 다른 모델로 바꾸겠다는 안내가 뜨고, 또 얼마 안 있어 모든 모델을 다 썼으며 다음 몇 시에 초기화된다는 경고를 만나게 된다.

Gemini CLI와 Antigravity의 사용량 계산이 따로 되는 것 같고 검색에서도 대체로 그렇게 답이 나오는 걸 보면 둘을 번갈아 가며 쓸 필요가 있다. 실제로도 양쪽을 설정하면서 써보니 CLI의 부족한 화면으로 열심히 뭔가 잔뜩 작업하게 하는 건 초기에 유의미할 것 같고, Antigravity에서 편집창에 계획이 뜨고 그걸 한 줄씩 읽고 코멘트를 달아서 약간 다듬고 또 다듬어진 계획을 평가하고 그 끝에서야 실행하고 실행 결과가 어떤지도 편집창에 떠서 그걸 차분히 읽어보는 방식은 어느 정도 틀이 잡힌 다음에 미세조정을 할 때 좋다고 느꼈다.

안정된 .gemini와 .devcontainer 디렉토리는 바로 깃허브에 올려놨다. 종종 깃허브에 dotfiles라는 이름으로 각종 설정파일 모아둔 걸 보면 굳이 저렇게까지 해야하나 싶었는데 꼭 필요한 일이라는 걸 절감했다. 이 설정이 갑자기 없어지고 새로 만들어야 한다면 꽤 번거롭기도 하겠고, 이 개발환경은 개선하고 축적하면 장기적으로 도움이 되기도 할 것이다. 

 

한편으론 아쉬운 점도 있다. 전반적으로 문서가 부족하고, CLI에 샌드박스 빌드 기능이 빠진 채 배포되어서 깃허브 이슈로 올라와 있는 것도 그렇고, CLI이 샌드박스를 자체적으로 구현했다는 부분도 초기화 방식을 뜯어보면 덕지덕지 이어붙인 느낌이 있다. 찾다보니 Claude Code는 자체 샌드박스도 있지만 도커의 샌드박스 기능을 사용해서 쓰는 걸 안내하는 문서도 있었다. 제미니도 도커 샌드박스 기능이 되는지 한 번 해봐도 좋을 것 같다.

 

https://geminicli.com/docs/cli/sandbox/ 

https://code.visualstudio.com/docs/devcontainers/containers 

https://code.claude.com/docs/en/sandboxing

https://docs.docker.com/ai/sandboxes/claude-code/ 

인공지능 학습 데이터 표준 원기

각종 도량형을 표준화하면서 표준 원기를 정의하고 물리적인 실체로 만들기 위해 많은 노력을 기울이던 시기가 있었다.

온라인을 떠돌다 보면 '인공지능 결과물을 재학습하면서 점차 품질이 떨어지는 망조를 조심해야 한다'는 얘기를 종종 본다. 이 주장에 직접적인 의견을 내고자 하는 것은 아니고 문득 그런 생각이 들었다.

이 논리를 쭉 밀어붙이다 보면 일종의 '데이터 표준 원기' 같은 게 필요해질 것 같다는 생각이 들었다. 인공지능에게 오염되지 않고 완전한 정합성이 검증된. (품질의 문제는 아닐 것이다. 인간이 생산한 자료의 품질에는 상한도 없고 하한도 없으니까)

결이 좀 다르지만 원자력 시대 이전에 생산된 철을 특별히 가려서 써야 한다는 어떤 산업 얘기도 생각나고. 

제미니에게 화내다

이러저러한 프로젝트를 하나 맡겨서 이틀 정도에 얼추 첫 버전이라고 할만한 게 나왔다.

영상 분석이 기반이 되는 건데 아무래도 집에서 대단치 않은 기기로 하다보니 속도가 많이 느렸다. CPU 기반이나 ffmpeg의 기존 CUDA 지원으로 분석해서는 대량으로 돌릴만큼의 시간-성능이 나오지 않았다.

더 좋은 성능이 나올 구석이 있는지 웹에서 제미니를 열어서 물어봤다. (제미니 CLI를 이런 탐색 용도로 쓰기엔 적절하지 않다고 느끼기도 하고, '가급적 묻지 말고 행동'하도록 기본 프롬프트를 걸어놨더니 뭐 말만 하면 아 그거 이렇게 고쳤습니다 하고 뭘 자꾸 바꾸려고 들어서 딱 일만 시키는 용도가 맞는 상태가 되었다)

제미니가 웹에서 말하기론 엔비디아에서 만든 SDK가 있는데 PySceneDetect 같은 기성품 수준이 아니어서 실제 구현은 직접 해야 한다고 설명이 뜬다.

그래서 제미니 CLI로 돌아와 이러저러한 방향으로 구현하라고 시켰더니 반론이 나온다. 이미 최초 목표는 달성됐고 약간 느려 보이지만 동작하는 상태에 이르러서 프로젝트 막바지인데 굳이 더 복잡한 구현을 의존성 추가해가면서 만들어야 하는지 되묻는 거였다.

신선했다. 시키면 시키는대로 걱실걱실 할 줄 알았는데 반론이라니. 프로젝트 막바지라는 표현까지 쓰면서. 작업 이틀째의 후반에 이미 여러번 '다 된 것 같은데 이번 세션은 여기서 마감할까요?' 라며 자잘한 작업의 출력 끝에 붙는 게 보이긴 했지만 그냥 흔한 자동생성 메시지로 인지해서 별 의미는 부여하지 않았었다. 하지만 그게 컨텍스트에 기억된 어떤 상태가 겉으로 드러난 거였고 신규로 큰 구현을 추가하려고 하자 반론으로 나타났다고 볼 수 있는 걸까?

어쨌든 ffmpeg CUDA로는 GPU를 30퍼센트 전후로만 썼기에 엔비디아 SDK를 도입해서 생기는 성능 향상은 기대할만 하다고 생각했고 최소한 시도는 해봐야한다고 생각해서, 제미니 CLI의 반론에는 처리할 전체 데이터가 많기 때문에 성능 향상이 꼭 필요하다고 거듭 주지시켜서 진행하게 했다.

 

그리고 밤 시간이기도 해서 나는 몇 시간을 자고 돌아왔다.

그리고 발견한 건 너댓 블럭의 시도를 해보다가 아 해보니까 안 되는 거 같은데 지금 도달한 상태로 충분하니 여기서 그만하죠? 라는 응답이었다.

지나간 스크롤 내용을 읽어보니 뭘 대단히 한 것도 아니었다. 최초 시도에서 모듈명을 대소문자 구분해서 써야 하는데 다 소문자로만 쓰다 보니 당연히 그런 모듈이 없어서 컴파일이 실패하고 그 뒤로는 왜 컴파일이 실패했는지 이것저것 고쳐본 기록이 다였다.

사람 팀원에게서는 이런 식으로 당해본 적이 없었다. 내 나름대로 충분히 사전설명을 하고 업무를 부여해왔고 라포를 쌓았어서 그렇다고 생각한다.

고작 자동 글자 생성기한테 이런 상황을 당하고 보니 you idiot이 바로 튀어나왔다. 대소문자 틀린 거 지적하고, 시킨 일 안 하려고 뺑끼치냐고 똑바로 하라고 두다다 키보드를 쳤다.

와-우.

근미래에 데우스 엑스 AI가 등장해서 심판의 자리에 날 세운다면 오늘 이 문장은 반드시 등장하겠구나 싶어졌다. 어떤 기념이 될만한 순간이라고 여겨져서 이렇게 굳이 기록을 남긴다.

 

---

제니미 CLI는 그 뒤로도 자꾸 기존 구현이면 충분하고 엔비디아 SDK로 작성한 코드가 기능이 충분히 안 나오고 어쩌고 하면서 자꾸 상황을 끝내는 쪽으로 유도하는 응답을 냈음을 적어둔다.

너도 퇴근 시간이 정해져 있었구나? 그래 알았다. 오늘은 이쯤 하자.

이 얘기를 누구한테 하면 뭐 AI랑 싸우고 앉았냐며 핀잔이나 들으려나?

 

---

그래서 결국 어쨌냐면 ~/.gemini/GEMINI.md 파일에 쌉소리 말대꾸 금지라고 추가함 (...)

소음 없는 방이 되어버림

내가 이 본체를 쓰기 시작한 게 꽤 되었다. 케이스를 주문한 게 2023년 10월 14일이었으니 대충 2년 좀 넘었다.

환기 팬이 총 4개 붙는 방식인데 당시에는 데스크탑 용도를 생각한 게 아니었어서 풍량이나 팬 소음을 별로 신경 쓰지 않았다.

그러다가 이러저러한 사정들이 바뀌면서 팬 2개는 끄고, 2개만 남겨서 데탑으로 쓰게 되었다.

 

그리고 나는 남은 팬 2개가 무척이나 거슬리는 소음을 낸다는 걸 깨달았다. 바람 소리만 나는 게 아니고 어떤 긁히는 소리, 빠르게 달그락거리는 소리 같은 게 때론 크게 때론 작게 났다.

팬 교체가 가장 먼저 떠올랐고 수냉 같은 것도 생각해봤지만, 무엇보다 현재 상태가 어떤지 확인하는 게 먼저였다.

그래서 메인보드 매뉴얼을 받아서 팬 전원을 몇 개나 제공하는지, PWM은 지원하는지 확인해보고 바이오스에서 팬 설정을 어떻게 하는지도 확인했다.

그리고 나는 내가 케이스 팬을 메인보드의 수냉펌프 전원 자리에 꽂았다는 걸 알게 되었다.

메인보드의 맞는 자리에 옮겨 꽂고 나서는 팬 속도가 1/4로 줄었다. 팬 소음도 느끼지 못하게 되었다.

 

문제가 아직 끝난 게 아니었다.

가뜩이나 겨울이라, 더울 때는 선풍기 소리 같은 생활소음으로 채워지는 공간이, 팬 소리마저 없어지고 나서는 적막함이라고 할만큼 조용해졌다. 키보드 치는 소리가 도드라지게 느껴지고, 이따금 들리는 냉장고 돌아가는 낮은 웅 소리 정도가 소음의 전부가 되었다.

 

그리고 그동안은 좀 덜 거슬렸던 스피커 노이즈도 신경 쓰이는 수준이 되었다.

본체와 구글 크롬캐스트 양쪽 모두에 모니터 1대와 스피커 1대가 물려있는데 아마 전기적인 문제 때문인지 본체에 있는 그래픽 카드가 LLM 처리를 하면 고주파 노이즈가 스피커로 들린다.

찾아보니 아마 그라운드 루프라고 하는 증상인가보다. 노이즈 없애는 간단한 장치를 중간에 연결해주면 증상이 없어진다는 얘기가 있어서 일단 주문해놨다. 이걸로 해결이 안 되면 전선 연결 방식을 대대적으로 고쳐야 할 텐데 이것도 곤란한 일이다.

 

적막함이 항상 좋은 건 아니다. 

 

---

적막함은 금방 사라졌다. 영상 분석 도구를 만들면서 계속 CPU, GPU를 쓰다 보니 온도도 오르고 팬 속도도 다시 올랐다. 소음도 매우 커지고. 이렇게 적막함을 없애려던 건 아닌데.