GPU 모니터링 앱을 하나 만들어서 새벽에 공개했다. all-smi 라는 이름의 앱이다. (미리 아답터를 만들어 두었다면) GPU, NPU 종류에 상관없이 하나의 뷰로, 지금 내 컴퓨터 또는 여러 서버에 걸쳐 모든 자원을 모니터링하는 툴이다. GPU 모니터링하러 뭔가 잔뜩 깔고, 웹까지 개발하고 열고 보는 그 모든 과정이 너무 불편해서 만들었다.
지금은 Nvidia GPU들, Nvidia Jetson GPU 및 (달려 있는 보드라면) DLA 가속모듈, Apple silicon 의 GPU 및 ANE 모니터링을 지원한다. 여러 서버 노드에 API 모드로 데몬으로 띄운 후 한 곳에서 모아서 보는 뷰 모드가 핵심인데, 서버 노드 300여대, GPU는 2400장까지 지원하는 것을 1차 목표로 만들었다. (더 많아지면 커넥션 풀과 뷰 설계가 좀 바뀌어야 할 듯 하다. 운영체제에 따라 현재 64개 정도의 커넥션 풀을 쓰는데, 더 댓수가 많아지고 중간에 몇몇 뻗는 노드들이 생길 때 타임아웃 고려하면 커넥션 풀 고갈 관련해서 머릴 써야 한다.)
설치는 cargo install all-smi 또는
https://github.com/inureyes/all-smi 에서 바이너리를 받으면 된다.
애플 머신을 위한 homebrew 랑 리눅스 배포판 추가 등은 저녁에 진행할 예정.
여기까지는 앱 소개였고,
사실 이 앱은 작년 8월 초에 휴가갔다가 rust 나 배워볼까 하고 만들기 시작했던 앱이다. 작년 여름에 NPU용 뷰잉 도구가 제대로 된 것이 없고, 사용성도 다 달라서 여러 GPU나 NPU가 섞여 있는 상황에서 뭘 하기가 너무 어려웠다. 그래서 휴가 간 김에 만들까 해서 시작했던 앱이다. rust 를 선택한 이유는 가장 안 해 본 언어라서였다. rust 는 정식 버전도 나오기 전 아주 초창기에 book of rust 읽고 해 본 것이 다였다.
당시의 페이스북 글이다.
https://www.facebook.com/share/p/1B44JfnsQU/
Google AI studio 와 ChatGPT에 계속 코드 조각을 물어보고 작성하고 수정할 때 준 프롬프트는 이랬다.
"난 러스트를 거의 처음 한다. C 프로그래밍 및 파이썬 3에는 익숙하다. 비동기 기술 및 패키징 기술, UI 기술에 대해서는 jQuery와 웹컴포넌트에 대한 풍부한 경험이 있다. 지금부터 프로그래밍을 하다가 오류가 생기면 디버그를 부탁할 것이다. 오류 및 수정 제안 코드를 설명할때 나의 백그라운드를 고려하여, 이해할 수 있는 설명 및 비유를 충분히 활용해서 설명하라. 비슷한 레토릭 및 일대일 대응이 되는 기능이 있다면 그 내용을 원용하여 설명하라. 오류가 발생할 경우, 원래 내가 알고 있는 지식과 러스트 언어의 특징을 비교하여, 러스트 언어의 특징에 의한 휴먼 에러인 경우 해당 부분을 상세하게 설명하라."
사흘 만들다가 휴가를 마치고 돌아와 일 년 가까이 잊고 있다가, 이번 주말에 다시 코드를 손댔다. 작년처럼 GPU/NPU가 섞인 상황도 있지만, 이번엔 GPU 네자릿수를 모니터링해야 할 상황이 되어서 귀찮아져서 다시 코드를 잡았다. GPU 달랑 천 대 모니터하려고 dcgm 셋업에 그라파나 대시보드를 짜야 한다는게 좀 그랬다. 한두번 할 것도 아니기 때문에 더 그랬다.
이번에는 Gemini CLI 를 거의 옆에 끼고 개발했다. 중간에 무한루프를 돌면 Gemini CLI를 잠시 끄고 (Gemini CLI 에 어제 그저께 replace tool 관련 버그가 있었다. GitHub 보니 구글에서 고치는 중으로 보인다.) Claude Code로 개발하고, Claude code가 영 감을 못잡으면 에디터 열어서 한 10분씩 직접 코딩했다. 다음주 발표자료 만들면서 한쪽에서 코딩하다 보니 대략 원하는 형태의 모습이 되어서 릴리즈까지 하게 되었다. 자동 릴리즈용 GitHub action 작성은 Gemini 에게 처리하라고 하고, Cargo 릴리즈는 ChatGPT 에게 방법을 물어봐서 적용했다.
오늘 개발 및 릴리즈를 하며 깨달은게 있는데, 코드와 컴퓨팅, 네트워크를 깊게 알수록 에이전틱 코딩에 절대적으로 유리하다. 중간중간 Gemini 나 Claude code의 삽질을 중간에 멈추고 해결책에 대한 의견 주기를 통해 최종 해결을 위한 가이드를 하며 느낀 점이다. 터미널에서 더블 버퍼링을 구현한다거나, 여러개의 스크린 버퍼를 두고 컴포지션해서 뿌리라거나 하는 가이드를 줘서 터미널 출력 관련 플리커링이나 프레임 문제들을 해결했다. 준기님 컴퓨터에서는 여전히 플리커링이 일어나 오늘 적응형 프레임 버퍼까지 구현을 하게 되었다. (터미널 프로그램 맞다.)
AI 모델로 코딩을 잘 외주하려면 우선 가이드를 줄 사람이 그런 기술들이 있다는걸 알아야 한다는 부분을 갈수록 더 많이 느낀다. 코딩 모델들은 핵심 구현에 대한 기술적 가이드를 줄 때는 그 방향으로 깊이 들어갈 수 있지만, 그렇지 않으면 그저그런 대답이나 코드들을 만들어낸다. 알아서 좀 잘 못하냐? 하기엔 AI는 의지가 좀 허약하다. 구현 디테일의 정도를 깊이 생각하지 않고 일단 지시에 따라 코드를 찍어내는 정도라, AI 모델 코딩 실력의 한계는 그걸 잡고 있는 사람의 실력 바운더리를 크게 넘지 못하는 듯 하다.
강한 방향성이 문제를 파고드는 의지를 만든다. AI나, 사람이나.
덧. Gemini CLI (맨정신일땐) 네가 최고다…
https://www.facebook.com/share/p/16ggK9RGFP/