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

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

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

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

자동화의 두 얼굴: 왜곡되는 임금 사다리

AI가 직업 시장에 미치는 영향은 자동화되는 업무의 종류에 따라 극명하게 갈립니다. 아짐 아자르의 분석에 따르면, 두 가지 상반된 결과가 나타납니다.

• 고숙련 업무 자동화: 전문 지식의 진입 장벽이 낮아져 고용은 늘지만, 희소성이 사라져 평균 임금은 하락합니다.
• 저숙련 업무 자동화: 단순 반복 업무가 대체되어 고용은 줄지만, 남은 관리 인력의 가치는 높아져 임금이 상승합니다.

결국 어느 쪽이든 안정적이었던 통상적인 ‘임금 사다리’는 왜곡되고, 직업 시장은 예측 불가능한 방향으로 재편되게 됩니다.

시험대에 오른 첫 직업: 소프트웨어 개발자

이러한 변화는 저와 같은 사람이 몸담고 있는 소프트웨어 개발자 직군에서 가장 먼저, 그리고 가장 뚜렷하게 나타나고 있다는 것을 누구도 부인할 수 없을거 같습니다.

• 시장의 양극화: 단순 코딩은 AI로 대체되면서 초보 개발자의 입지는 좁아집니다. 반면, 복잡한 시스템을 설계하고 AI를 지휘하는 고숙련 개발자의 가치는 상승합니다. 소수의 ‘AI 오케스트레이터’와 다수의 ‘AI 사용자’로 시장이 나뉘는 것이죠.
• 새로운 개발자의 탄생: 역설적으로 AI는 개발의 진입 장벽을 극적으로 낮춥니다. 한 작가의 경험담처럼, 코딩을 전혀 모르던 사람도 AI 툴로 무언가를 만들며 성취감을 느끼고, 이는 곧 한계에 부딪히며 오히려 “제대로 배우고 싶다”는 지적 갈망으로 이어지는 사례가 늘어나게 될 것입니다. AI가 기술 학습의 ‘대체재’가 아닌 훌륭한 ‘관문’ 역할을 하는 것입니다.

결과적으로 개발자라는 직업은 소수의 고임금 설계자와 AI의 도움으로 유입된 다수의 제작자로 재편될 수 있습니다. 전체 고용은 늘 수 있지만, 평균 임금은 하향 평준화될 가능성이 제기됩니다. 또한 다수의 제작자들의 여러 아이디어 덕분에 시장은 확장될 가능성이 큽니다.

선택의 기로

이러한 변화는 급여 측면에서 안정적이었던 중산층을 위협하며 사회적 불안을 야기할 수 있겠죠. 결국 우리는 선택의 기로에 놓입니다. AI를 소수 자본의 부를 증식하는 도구로 쓸 것인가, 아니면 마크 저커버그의 비전처럼 개인의 역량을 강화하는 ‘개인용 초지능’으로 만들 것인가?

마크 저커버의 개인용 초지능 역시 누구나 가지고 있는 능력이라면 초지능이라고 부를 수 있을까요? 결국 산업 혁명 시절 육체적인 능력이 증기기관이라는 능력으로 평준화가 된 사례가 있었듯이, 지능이라는 인간 능력 영역이 AI로 인해 상향 평준화가 된다면 인간은 다른 능력으로 평가되고 교육될 것이라 예상됩니다. 앞으로 필요한 인간 고유의 능력이라는게 뭐가 될까요? 교육을 비롯하여, 기본 소득 등 사회 각 영역에서 반드시 고민이 선행되어야 될 부분이라 생각합니다.

끝!

에이전트 개발의 핵심은 단순히 ‘만드는 기술’을 넘어, ‘무엇을 위해 존재하는가?’라는 본질적인 질문에서 시작해야 합니다. 특히 서비스 에이전트는 ‘사용자’와 ‘서비스’에 대한 깊은 이해가 선행되지 않으면 그 가치를 제대로 발휘하기 어렵습니다. 진정으로 의미 있는 에이전트를 만들기 위해서는 다음의 과정들을 끊임없이 순환하며 발전시켜 나가야 합니다.

1단계: 본질 파악

에이전트 개발에 앞서, 우리는 서비스의 존재 이유와 목표를 명확히 해야 합니다. 이는 에이전트가 나아갈 방향을 설정하는 나침반과 같습니다.

• 서비스의 존재 이유: 이 서비스는 근본적으로 사용자에게 어떤 가치를 제공하기 위해 존재하는가?
• 핵심 성과 지표(KPI): 에이전트의 성공을 어떻게 측정할 것인가? 단순히 반복적인 작업을 돕는 것인가, 아니면 구매 전환율이나 고객 만족도 향상과 같은 구체적인 비즈니스 목표 달성인가?
• 사용자 행동 패턴: 사용자는 서비스를 어떻게 이용하며, 어떤 경로를 통해 의사결정을 내리는가?

이러한 질문에 대한 답이 불명확하다면, 실제 서비스 로그 데이터를 분석하여 사용자의 목소리에 귀를 기울이는 것이 무엇보다 중요합니다.

2단계: 데이터를 통한 ‘지식’과 ‘기억’ 구축

에이전트가 똑똑하게 행동하기 위해서는 잘 정제된 데이터, 즉 ‘지식’과 ‘기억’이 필요합니다. 이는 흩어진 원시 데이터를 가치 있는 정보로 변환하는 과정입니다.

1. 데이터 소스 연결: 서비스 내부에 흩어져 있는 다양한 데이터 소스를 하나로 통합합니다.
2. 의미 관계 구축: 연결된 데이터 간의 관계를 파악하여 의미 있는 구조로 엮습니다.
3. 데이터 명확화: 명확한 데이터는 자연어나 특정 단어로 치환하여 에이전트가 쉽게 이해할 수 있도록 합니다.
4. LLM 기반 추론 보강: 명시적으로 드러나지 않는 관계나 사용자의 숨은 의도는 LLM의 추론 능력을 활용하여 보강합니다.
5. ‘지식’으로 가공: 방대한 원시 데이터를 에이전트가 즉시 활용할 수 있는 ‘지식 체계’로 구축합니다.

이 과정에서 ‘개인화’는 필수적입니다. ‘에이전트’라는 용어 자체가 개인 비서를 의미하듯, 각 사용자에게 최적화된 경험을 제공하는 것을 목표로 해야 합니다.

3단계: 태스크(Task) 정의와 플로우(Flow) 디자인

앞선 단계를 통해 서비스와 사용자에 대한 깊은 이해를 갖추었다면, 이제 에이전트가 수행할 구체적인 ‘태스크’를 정의하고 그 실행 과정인 ‘플로우’를 디자인해야 합니다.

• 태스크 정의: 에이전트가 사용자를 위해 해결해야 할 구체적인 과업은 무엇인가?
• 플로우 디자인: 정의된 태스크를 어떤 순서와 방식으로 처리할 것인가?

4단계: 지속적인 평가와 개선의 순환 구조

에이전트 개발은 한 번에 끝나는 프로젝트가 아닙니다. AI 시스템의 성능과 효용성은 지속적인 평가와 개선을 통해 향상됩니다. 결론적으로, 에이전트를 만드는 과정은 [본질파악 → 데이터/로그 기반 지식 정의 → 태스크 고도화]의 사이클을 끊임없이 반복하는 것입니다. 이는 서비스를 만드는 과정과 본질적으로 같으며, 특히 서비스 데이터를 잘 가공하여 적시에 모델 컨텍스트에 제공하고, 그 결과를 평가하고 모니터링하는 부분이 에이전트의 성능에 가장 큰 영향을 미칠 거라 생각합니다. 이 부분이 누구나 가질 수 있는 AI API를 사용하지만 결국 결과적으로 큰 차별화를 할 수 있는 부분이라 생각합니다.

끝!

• https://cafe.naver.com/camback/18779 : 굴업도 연평산
• https://cafe.naver.com/camback/19136 : 굴업도 개머리 언덕

두 번째 글은 아래의 여행 유튜브 영상과 같이 보면 다른 사람의 관점에서 동일한 시점과 공간에서 섬을 어떻게 느꼈는지를 알 수 있을것이다.

보면 아시겠지만 두 유튜브에 내가 모두 출현한다. 그것도 이분들을 섬에서 우연히 만나고 이야기 하게 된 내용으로 말이다.

예전에는 어려운 개념서의 서로 다른 저자의 책 두 권을 구해서 겹쳐 읽기를 해서 이해도를 높였던 읽기 기술을 사용했던 적이 있다. 물론 지금은 그 역할의 한 축을 AI가 담당하고 있지만 여전히 이 방법은 유효하다고 자부한다. 비슷하게 여행이나 경험도 겹쳐 읽기가 이제는 가능한 시점이 되지 않았나 싶다. 대부분의 사람들이 글과 영상을 남기고 공유하는 누구나 크리에이터인 세상에서 경험의 겹쳐 읽기가 가능하다는 것이 참으로 격세지감이기도 하다. 이렇게 경험을 겹쳐 읽다 보면 하나의 시공간을 여러 시점으로 경험하게 되어서 경험의 깊이가 깊어지는 효과가 있다.

나름대로 경험의 깊이를 배가 시키는 여행 후의 작업들은 아래와 같다.

1. 반드시 여행을 다녀온 뒤에 작은 여행기를 쓴다.
2. 여행기를 적당한 온라인 공간에 공유한다.
3. 비슷한 시점에 같은 곳을 다녀온 여행을 찾아서 보고 읽는다.

아마도 이 유튜버 분들이 나의 카페글을 읽을지 안 읽을지 모르겠지만 이분들도 경험의 겹쳐 읽기를 하면서 경험의 깊이를 배가 시키길 바란다.

모두가 콘텐츠 생산자이자 소비자가 된 세상이 되니 경험의 깊이가 깊어지고 이해도 깊어지는 효과가 있다. 이로서 여행을 두번 세번 하는 경험까지 말이다. 하지만 그러한 경험도 직접 일부라도 경험해 보면서 느끼는 것과는 다를 것이다. 따라서 소파에서 편하게 여행하는 느낌을 충분히 콘텐츠로 누리시되 직접 경험하는 재미를 잃지 마시라 권유하고 싶고, 그렇게 한 경험을 누구에게 보여줄 수 있는 수준으로 정리하는 습관 그리고 부끄럽지만 공유하는 자세도 좀더 기억에 남는 여행을 위해 필요하다고 생각한다.

끝!