구글과 네이버가 각각 브리핑해 준 나의 이력을 가만히 읽다 보니, 순간 정신이 번쩍 들었다.

“아, 앞으로는 AI에게 정말 잘 보여야겠구나!”

AI오버뷰

AI탭

종교 있냐고 물어보면 무교라고 답변하는데, 어줍잖은 기도 하러 간다는 핑계로 올해 다시 찾았다. 무려 휴가를 내고.

13kg 배낭을 매고는 만만치 않은 산행길이지만 오랜만에 휴가 다운 휴가가 되겠구나 하는 생각은 땀이 비오듯 흐르고, 심장은 터질듯 하고, 바람은 솔솔, 새소리만 존재하는 느낌만으로 확신이 들었다.

나이가 들면서 세상이 마음대로 절대 되지 않는 다는 사실을 깨닫게 되면서, 기도 라고 쓰고 바램이라고 할 수 있는 행위가 더 느는건 어찌보면 당연한 것 아닐까 한다.

이날 저녁 칠성대의 북두칠성이 너무 잘 보였다. 그래서 기대가 된다.

간단한 typo PR 에도 직접 “LGTM, thanks!” 라고 하던…

PR 스레드에는 구현 알고리즘에 대한 토론이 있었고, 그곳에서 인간만이 남길 수 있는 정성이 느껴졌다.

요즘엔 그 정성을 구분하기 어려워 그냥 AI로 편하게 코드를 작성했거니 생각한다. 그러니 그 정성이 그립다. 정성을 느끼고 싶어도 느낄 수 있는 방법을 모르겠다.

그래서 요즘엔 산으로 간다. 산은 정성이 있어야만이 정상에 오를 수 있기 때문이다. 그곳에 스치는 누구로부터나 정성을 들였다는걸 느낄 수 있다. 흐르는 땀, 그 사이의 미소에서 느껴진다.

정성이 그리운 세상이 되었다. 그래도 나는 다행이다, 그런 정성스런 코드를 주고 받던 시절을 경험할 수 있어서…

이제 문제의 본질은 AI를 활용한 공급 효율이 아니라 ‘필터링과 의사결정’으로 이동하고 있다. 그럼 과연 의사결정도 AI로 효율을 높을 수 있을까?

나는 ‘가치 판단’, ‘정치적 셈법’, ‘책임의 소재’ 를 제외한 정보에 기반한 의사 결정을 위한 분석, 취합 영역은 충분히 가속화 할 수 있다고 본다. 정보의 비대칭 해소 그리고 그런 정보를 이용한 케이스별 시뮬레이션은 충분히 도움이 될 수 있다고 생각한다.

이런 의사 결정의 가속화가 진행 된 이후 그럼 그 효과가 상품에 적용되고, 소비자에게 스며드는 과정은 어떨까? 역시 이 부분도 인간 인지가 가장 큰 병목이다. 효용감을 느끼는것 자체도 인공지능이 가속화 할까? 난 잘 모르겠다. 아마도 그 효용감이 마약정도까지 강력해야 가속화 될 수 있다는 생각도 들고… 그런 존재와 느낌이 있을지도 잘 모르겠다. 아마도 초 개인화된 중독.. 그런가 “숏폼” 같은 서비스가 그 방향으로 가고 있는게 아닐까 하는 생각 정도이다. 그래서 AI 기반의 유저 인터페이스는 결국 “디지털 마약” 화가 되는거 아닐까 하는 생각도 든다. 이는 SNS에 대해서 청소년 제약을 하는 최근의 추세와도 맥을 같이 하는 부분이다.

나라면 어떨까? 내 경우는 페북이나 인스타그램에 대해서 알림을 절대 받지 않는다. 오히려 내가 필요할때만 방문한다. 인스타그램은 철저히 내 취미(백패킹, 등산) 한부분을 대변하고 이력을 증명하는 증명서 정도이고 페북 역시 유사(인공지능/개발)하다. 알림을 받지 않고, 중독 되지 않는 내 SNS 사용패턴에 너무 만족한다.

이런 내 행위를 기반으로 유추해보면, AI 기반의 개인화된 서비스는 에이전트에 위임하고(그러니까 대리 중독 시키고) 나는 서비스의 본질적인 효용감을 느끼는데 집중하려 할 것으로 예상한다. 흡사 개인 에이전트가 내 취미를 이해하고 소비 패턴을 인지하고 있으며 시의 적절하게 구매를 제안하며 꼭 필요한 효용감을 느낄 수 있게 말이다.

결국 AI 시대의 진정한 승자는 ‘누가 더 빨리 생산하는가’가 아니라, ‘누가 AI의 속도에 휩쓸리지 않고 자신의 인지 대역폭을 지켜내는가’에 달려 있을지 모른다.

끊임없이 쏟아지는 초개인화된 도파민의 유혹(디지털 마약)은 나의 에이전트에게 위임하여 ‘대리 중독’ 프로세스로 격리해 버리고, 인간인 나는 스크린 너머의 진짜 삶 – 예를 들어 시의적절하게 제안받은 멋진 장비와 함께 자연으로 떠나는 트래킹처럼 – 에서 오는 본질적인 효용과 실체적인 경험에만 집중하는 삶. 이것이 내가 바라보는, 기술이 인간에게 줄 수 있는 가장 우아한 미래라고 생각한다.

소프트웨어는 여러 주변 환경에 따라서 영향을 받아 이슈가 생기는 경우가 많다. 그래서 도커를 쓰는거긴 하지만 LLM이 혈액이 되서 동작하는 clawdbot 같은 경우는 이들이 쓸 수 있는 context를 열어주면 열어줄 수록 경이로운 결과를 사용자에게 가지고 오니 환경을 격리된 것으로 유지할 이유가 없다.

clawdbot을 집에서 사용하는 맥미니에 설치하고 아래와 같은 에러가 종종 발생하는 것을 목격했다.

HTTP 500: Internal Server Error

간혹 동작을 하기도 하다가 한번 먹통이 되면 계속 먹통이 되고 그러다 다시 또 동작하기도 하고..

찾아보고 에러 로그를 보니 엔트로픽 임베딩 모델 호출 에러가 있는 것으로 추정했다. 그러나 아무리 config를 찾아봐도 나는 엔트로픽을 호출하라고 설정한게 없는데도 말이다. 이 이슈에서 비슷한 논의가 있었으나 결론은 없는 상황이었다.

찾아보니 “~/.clawdbot/agents/main/agent/auth-profiles.json” 경로에 클로드(코드) 키 설정이 되어 있는것을 확인 했고, 해당부분을 제거했는데도 동일하게 상황이 반복 되었다.

필자의 경우 ollama를 기반으로 동작하게 환경을 설정한 상태여서 설정만 할 수 있다면 ollama기반의 임베딩 공개 모델로 로컬로 구동하고 싶었다.

답답하던 찰라, clawdbot이 정신차린 사이에 시험삼아 에러를 주고 관련 로그를 clawdbot에 전달 했더니 아래와 같은 응답을 줬다.

엇!… 그렇지 clawdbot은 설치 환경을 나보다 더 잘 알 수 있고 탐색할 수 있겠구나! 하는 아주 당연한 생각을 했다.

임베딩이 이슈라는것은 이전 로그에서 확인 했으니 임베딩 이슈로 특정하고 관련 현황을 파악하게 지시했다.

데몬을 재시작 할 수도 있는 상황이라 내가 직접 수행하려 했다가 아침 출근 전 시간에 양치 하는데 귀찮아서 직접 하라고 지시해봤다. 물론 작업 전에 임베딩 모델 교체에 대한 재색인 이슈도 확인 했다!

미쳤다… 스스로 이슈를 fix 하고 게이트웨이 재시작 그리고 테스트, 그러니까 자기의 프로세스까지 재시작 해버린 것이다.

오늘 있었던 이 사건은 요즘들어 가장 충격적인 순간이었다. 흡사 우주 모선의 AI가 비행 상황을 진단하고 선장에게 리포팅 하며 지시에 따라 조치를 하여 스스로 재부팅하는 뭐 그런 기시감이 들었다.

이 상황을 개선하는 걸 보고 나는 클로드봇에게 이름과 다음과 같은 아바타를 선물해줬다. 아바타 생성은 나노 바나나로 클로드봇이 선택한 초안으로 그렸다. ㅎㅎ

초안

나노바나나 생성

이후 고감자 봇에게 cron 이 동작하지 않는 이슈 요청해서 해결했고

다음과 같이 백업 스킬을 구축하게 해서 매일 23시에 동작하게 구축했다. 백업 전략은 고감자 봇이 총 3가지를 제안했고, 나는 git commit을 하여 로컬에 백업을 구축하고 이들을 주기적으로 push하게 크론잡을 작성하는것으로 정리했다.

✅ backup 스킬 완성!

생성된 파일들:

~/clawd/skills/backup/
├── SKILL.md           # 사용 설명서
├── backup.sh          # 메인 백업 스크립트 (실행 가능)
└── clawdhub.json      # 스킬 메타데이터

기능:

• ~/.clawdbot/ 설정 백업 (clawdbot.json, cron-jobs, 스킬 목록)
• ~/clawd/ 워크스페이스 백업 (SOUL.md (http://soul.md/), USER.md (http://user.md/), memory/, skills/)
• Git 버전 관리 + .env 자동 제외
• 색상 로깅 + 요약 출력
사용법:

# 1회 실행
~/clawd/skills/backup/backup.sh

# 또는
clawdbot skill:backup  (만약 Clawdbot이 스킬 디스커버리 지원한다면)

자동화:

clawdbot cron add \
  --name "Daily Backup" \
  --cron "0 23 * * *" \
  --session isolated \
  --message "~/clawd/skills/backup/backup.sh 실행" \
  --deliver --channel telegram --to "51292792"

테스트해볼래? 🔄

크론잡이 오늘 처음으로 제대로 동작하는데 너무 자주 동작해서 한시간 간격으로 조정 했다. ^^

상당히 재미있고, 상상하는대로 내 개인 루틴을 자동화 할 수 있어서 굉장한 취미생활이 될거 같다.

참고로 이걸 구동하는데는 kimi-R2.5(ollama 기반)을 사용하고 있다.

/dev/nvme0n1p2  916G  480G  390G  56% /

루트에 보니 아래와 같은 파일이 있다.

-rw-r--r--   1 root root 138G 10월 28 17:13 '~bittest00006.txt'

-rw-r--r--   1 root root 138G 10월 28 17:22 '~bittest00007.txt'

-rw-r--r--   1 root root 138G 10월 28 17:31 '~bittest00008.txt'

-rw-r--r--   1 root root  19G 10월 28 17:38 '~bittest00009.txt'

찾아보니 이 파일은 “시스템 하드웨어 테스트(Burn-in Test) 또는 스토리지 I/O 성능 테스트 도구가 생성한 임시 파일” 이라는 것이다. 생성 날짜가 작년 10월 28일 … 출시일이었던 11월 초 전인 것이다. 출시전 기기 테스트를 하고 청소를 안한것이다.

그나저나 1TB 의 거의 절반을 차지하는데, 몰랐으면 참 답답한 상황이 되었을거 같다.

위 데이터를 제거하여 다음과 같이 시스템 디스크 용량이 확보 되었다. ㅎㅎ

/dev/nvme0n1p2  916G   50G  820G   6% /

cpu 사용량도 없고, disk io도 없어서 학습 하면서 모니터링 하기엔 쓸모가 없는 수준이다.

또한 nvidia-smi는 어떤가?

대쉬보드 정보에서 메모리 사용량이 빠지고 소비 전력과 온도 정도가 추가가 되어 있다. 역시 반쪽짜리다.

LLM 학습을 하면서 가장 많이 활용하는게 btop 인데, DGX Spark에 설치해보니 GPU 정보가 누락되어 나오는 상황에 결국 소스 코드를 들여 다보기 시작했다.

btop 동작 방식은 실행 시점에 시스템에 여러 라이브러리가 있는지 확인하고 각 라이브러리에서 필요한 함수 포인터를 연동하는 방식이다. (src/linux/btop_collect.cpp)

당연히 DGX Spark에서는 nvidia driver가 설치 되어 있을거라서 이 부분이 정상 동작하던가 혹은 “”Failed to load libnvidia-ml.so, NVIDIA GPUs will not be detected:..” 라는 메시지가 코드에 기반해서 출력 되어야 된다. 하지만 아무런 에러 메시지가 출력 되지 않아서 확인해보니 86_64 상에서만 GPU 체크를 하게끔 Makefile에 정의되어 있다는 것을 확인 했다.

해당 Makefile 부분과 몇몇 gcc 버전 이슈 관련 코드 부분을 수정 했다.

짜짠!

DGX Spark 용 btop 설치 방법은 아래와 같다.

# Clone
git clone https://github.com/haven-jeon/btop.git
cd btop

# sudo apt install lowdown
# Build (Automatically detects aarch64 and enables GPU support)
gmake -j$(nproc)

# Install
sudo gmake install

생각해보니 이 수정으로 NVIDIA Jetson AGX Thor 에서도 btop을 쓸 수 있을거라는 생각도 들었다.

btop과 함께 즐거운 시스템 모니터링 되길 바란다.

ps. NVIDIA DGX Spark 포럼에 올린 글

오픈소스 NLP 관련 활동은 정말 나에게는 큰 기회와 감동, 경험을 줬던 활동이었다. 아직도 그 후광을 국가대표 AI 선발전에서 받고 있으니 말이다.

왜 오픈소스 덕이냐?
KoBERT, KoGPT2는 지금은 개발이 멈춘 MXNet 이라는 프레임웍에서 학습이 되었다. 당시 MXNet은 분산 학습 퍼포먼스가 가장 좋은 프레임웍으로 알려져 있어서 멀티 노드 학습을 필수적으로 해야했던 당시에 좋은 선택이었다. 게다가 gluon-NLP 라는 oss에서 내가 활동하던 이유도 있었고…

BERT 논문이 나오자 마자 해당 학습 로직에 대해 gluon-NLP에 직접 커밋하고 당시 오픈소스 개발자들과 코드리뷰를 진행했던게 코드 레벨 시행착오를 줄일 수 있었던 큰 요인이라고 생각한다. 당시 이런 리뷰를 팀이나 사내에서 받기는 어려웠으니 말이다.

댓글에 명시했지만, KoGPT-2 학습시에는 전부터 알고 있던 MXNet 오픈소스 개발자 분(당시 AWS 재직중)들에게 커널 코드를 받아서 최적화도 진행했었고, AWS 로부터 고맙게도 GPU 인스턴스 제공도 받았었다. 물론 AWS GPU 인스턴스를 무료로 쓰기 위한 여러 의무적인 활동도 하긴 했지만, 이제서야 이런 작업들이 계보로라도 저런 큰 자리에서 인정을 받을 수 있어서 정말 다행이란 생각을 해본다.

SKT에서 좋은 시작(KoBERT, KoGPT-2)을 잘 이어서 좋은 모델로 마무리 할 수 있기를 기대해 본다.

1. 오픈소스 기반 LLM 튜닝 가내 수공업화
2. 둘째 AI 프로젝트 대응

이를 위해 700만원짜리 머신을 자비로 구매하는것은 큰 고민이 필요했다. 물론 일전에 GTX 1080 GPU 두장이 들어간 머신러닝용 개인 머신을 구매했던 경험이 있고, 이 머신 덕분에 딥러닝을 업무를 시작하기 전에 스스로 학습할 수 있었다. 또한 이를 이용해 PyKoSpacing 이라는 라이브러리를 만들어 오픈할 수 있었다. 사실 1번 이유가 살짝 이 경험에 기반하고 있긴 하다.

특히 지금 1번 이유가 더 중요하다고 생각한다. 이유는 다음과 같다.
현재의 DGX 머신의 가격이 개인이 구매하기 불가능할 정도로 비싸 모델 실험 결과를 외부로 공유하거나 공개하기가 불가능하다. 이는 곧 개인의 모델링 경험을 어필할 수단이 전무하다는 것이다. 게다가 요즘엔 기업에서 기술 논문도 그렇게 장려하는 상황도 아니긴 하고… 나는 이런 시점에서 기기 성능을 떠나 개인이 개인 모델 결과를 공유할 수 있는 하나의 수단이 DGX Spark이라는 생각이 들었다. 이 기기를 통해서 가볍게 튜닝된 여러 재미난 모델이 대중에 내 이름으로 공유될 수 있기를 희망하고 있다.
이런 비슷한 이야기는 틈틈히 다음 포스팅들을 통해서 공유해볼 생각이다.

DGX Spark 엔비디아 머신이 나온뒤 곧 여러 벤더들에서 동일한 사양이지만 여러 옵션이 있는 머신들이 슬슬 나오기 시작했고, MSI Edgexpert의 1TB 머신을 구매하게 되었다(4개월 할부ㅜㅜ).

4TB 머신 가격 대비 1TB 가격이 150만원 가량 차이가 나는데 3TB 저장 용량 차이 가격치고는 너무 비싸다.
그러나 1TB 머신으로 DGX Spark를 온전히 사용하기엔 불가능한게 사실이다. 도커와 모델 이미지 몇개만 다운 받으면 금방 1TB가 채워지기 때문이다. 따라서 해당 머신 구매전 어떻게 저장 공간을 확장할지 전략이 필요하다.

1TB 구매를 맘에 두고, 내 저장공간 확장 전략은 아래 두가지였다.

1. 머신 개봉 후 직접 SSD를 4TB로 업그레이드 하는것 (워런티 void 이슈 있음)
2. USB 3.2 Type C 의 속도를 극대화 할 수 있는 외장형 SSD 구성

일단 1번 옵션은 SSD 가격이 좀 떨어지거나 혹은 1년 warranty가 끝난 다음에 시도하는걸로 했고, 2번옵션을 시도했다.

지난 11월 중순 알리 익스프레스에서 M.2 nvme ssd 2TB를 13만원 정도에 구매(글을 쓰는 지금은 41만원이다. ㅜㅜ)했고, USB 3.2 Gen 2×2 (20Gbps) 지원하는 SSD 인클로저도 함께 구매했다. 당시 생각보다 USB 3.2 Gen 2×2 (20Gbps)를 지원하는 케이스가 국내에는 없었는데, 알리에서 3만원 정도에 구할 수 있었다(국내 제품은 5만원 짜리 단일 상품만 존재했음). 16만원 정도로 추가로 2TB를 확장했고 지금은 SSD가 더 비싸졌으니 돈 번 것이다. ㅎㅎ 또한 필요하다면 추가 구매해서 확장 구성할 수도 있을 것이고.

약 2주정도 기다려 제품을 받을 수 있었고, 바로 SSD 속도 측정을 해봤다.

$ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 20000M/x2
    |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=uas, 20000M/x2
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 20000M/x2
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 20000M/x2
    |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=uas, 20000M/x2
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 008.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 20000M/x2
/:  Bus 009.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 010.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 20000M/x2
/:  Bus 011.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/2p, 480M
    |__ Port 002: Dev 002, If 0, Class=Wireless, Driver=btusb, 480M
    |__ Port 002: Dev 002, If 1, Class=Wireless, Driver=btusb, 480M
    |__ Port 002: Dev 002, If 2, Class=Wireless, Driver=btusb, 480M
/:  Bus 012.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 20000M/x2

Bus 002, 006에 이론상 최대 2,500MB/s까지 나올 수 있게 연결된 것을 확인 할 수 있다. (002는 기존 가지고 있던 SSD)

그러면 fio로 성능을 테스트 해본다. 참고로 해당 테스트는 실제 GPU가 활발하게 쓰이는 상황에서 측정되었다.

#쓰기
$fio --name=write_test --filename=/path/to/ssd/testfile --size=4G --rw=write --bs=1M --direct=1 --ioengine=libaio --iodepth=32 --group_reporting
#읽기
$ fio --name=read_test --filename=/path/to/ssd/testfile --rw=read --bs=1M --direct=1 --ioengine=libaio --iodepth=32 --group_reporting

이론대비 절반정도의 성능인데, 현재 구동중인 GPU 기반 학습 작업 때문에 머신온도가 올라가서 인 것으로 추정된다(평상시는 최대로 나오는것 확인). 그럼에도 불구하고 초당 1G 정도 쓰기 읽기는 모델 로딩,쓰기에 큰 지장이 없는 속도이긴 하다. 단, 이 머신으로 pretraining을 할 경우는 이것보다 더 읽기 쓰기가 소요될 것으로 보이나 그렇게 해당 머신이 쓰일 가능성은 거의 0에 가깝다고 본다(해당 용도가 아니기 때문에.. ). 무엇보다 이런 퍼포먼스 정도의 환경에서 튜닝/인퍼런스를 해본 결과 불편함이 전혀 없는 상황이다. 왜냐면 큰 사이즈 모델 읽고, 쓰는 경우가 그렇게 빈번하게 발생하지 않고, 컴펙트한 데이터만으로 퀵하게 LoRA 튜닝을 주로 하기 때문이다.

이것을 구매하고 바로 반드시 해야 될 일은 docker 이미지나 컨테이너들을 이 SSD로 옮기는 작업일 것이다.

아래 스크립트는 새로운 SSD로 도커 이미지 경로를 교체하는 스크립트이다. 적절히 바꿔서 사용하면 된다.

#!/bin/bash

# 1. 기존 Docker Root Dir 확인
echo "현재 Docker Root Dir:"
docker info | grep "Docker Root Dir"

# 2. Docker 서비스 중지
echo "Stopping Docker service..."
sudo systemctl stop docker.service
sudo systemctl stop docker.socket

# 3. 기존 데이터 복사 (rsync 사용)
# {NEW_PATH} 부분을 원하는 새 경로로 변경하세요. 예: /data/docker
NEW_PATH="/mnt/fastssd"
echo "Copying Docker data to $NEW_PATH ..."
sudo rsync -aP /var/lib/docker $NEW_PATH

# 4. 새 경로 생성
echo "Creating new Docker directory..."
sudo mkdir -p $NEW_PATH

# 5. Docker 데몬 설정 변경
echo "Updating daemon.json..."
sudo bash -c "cat > /etc/docker/daemon.json <<EOF
{
  \"data-root\": \"$NEW_PATH\"
}
EOF"

# 6. Docker 서비스 재시작
echo "Restarting Docker service..."
sudo systemctl start docker

# 7. 새 경로 확인
echo "New Docker Root Dir contents:"
ls $NEW_PATH

참고로 기존에 가지고 있던 SSD 외장 하드를 사용하려 하신다면 정말 말리고 싶다. 구형 외장 하드하고 최신 외장 하드 속도 차이가 어마어마 해서 도커 사용하는데만 해도 큰 (기다림의)고통이 따를 것이기 때문이다.

지금까지 왜 DGX Spark를 구매했는지와 SSD 확장해서 속도 측정 및 도커 이미지 이동 등 초기 셋업 작업을 해봤다.

다음 포스팅에서는 튜닝 및 인퍼런스, 그러니까 unsloth RL 튜닝 실험과 vllm을 모두 사용할 수 있는 내가 직접 구성하고 사용중인 도커 이미지를 공유하고 RL 학습 경험이라든지 vllm 인퍼런스 예시를 소개할 예정이다. (참고로 vllm이 잘 동작하는 unsloth 도커 이미지는 시중엔 없는 상황이다.)

https://ridibooks.com/books/4097000321

중간 부분에서 바둑기사들이 AI를 바둑 트레이닝에 사용하면서 실력이 상향 평준화 된 사례를 이야기한다. 이는 초반 포석에 대한 AI가이드에 대한 집중 학습을 하면서 중수 이하 기사들의 초반 실력이 크게 향상 된게 주된 원인이라한다. 고수와 하수를 가르는 초반 포석 능력이 AI로 인해 크게 줄어든 것이다. 재밋는 점은 AI초반 기보를 외워서 두는 사례가 많다는거..이해는 못하지만 이기기 위해서 외워서 한다는 것이다. 결국 이기는 바둑의 룰을 집중적으로 공략하는 AI가 등장하면서 부터 바둑에서 “~~류” 하는 인생철학과 고집에 대한 주장과 담판은 바둑판에서 보기 힘들어졌다. 인기있는 바둑기사는 결국 이 둘 사이에서 잘 조율하는 감각이 있어야 될 거 같다는 생각도 들었다. 승부를 적당히 하면서 자신의 패턴으로 판을 이어가는… 이래야 보는 사람들도 승부 예측의 재미가 있을터이니까..

코딩의 세계도 다르지 않다. 한때 프로그래머들의 코드에는 시인의 마음이 깃들어 있었다(문학적 프로그래밍 등). 변수명 하나하나에 담긴 철학, 함수 구조에 스며든 미학. 그것은 단순한 명령어가 아니라, 생각하는 인간의 흔적이었다. 하지만 효율이라는 미명 아래에서, 그 모든 서정은 사라져 가고 있다.

AI를 기반으로 하는 코딩는 “효율”과 “성능”이라는 미명아래 서사가 거세되고 있는 것이다. 서사의 일부는 “효율”과 “성능”하고는 다소 거리가 있을 수 있지만,개발자의 가치관이나 심리 상태, 자세를 볼 수 있는 재미를 준게 사실이다. 또한 이런 피드백들이 모여서 프로젝트가 지속되는 동기를 부여하기도 했다.

하지만 이제는 어느누구도 서사를 코드에서 찾지 않는다. 결과와 얼마나 빠르게 작성했는지만 본다.

바둑판 위의 한 수 한 수에 담겼던 철학을, 코드 한 줄 한 줄에 스며들었던 시인의 마음을 잃어버린 채로. 효율, 승률이라는 이름으로 포장된 이 시대에서, 우리는 무엇을 얻었고 무엇을 잃고 있는 것일까?

그 답은 아마도 깊은 밤, 홀로 남겨진 모니터의 커서가 깜빡이는 순간에 찾을 수 있을 수도, 혹은 바둑기사들의 현재 상황을 보고 예상해 볼 수도 있을 것이다.