KiCad로 그린 첫 회로도

KiCAD가 아니라 KiCad라고 쓰는 것이 관행인 것 같다. KiCad는 전자회로 및 PCB 설계에 특화된 오픈소스 EDA(Electronic Design Automation)이다. 공식 웹사이트는 https://www.kicad.org/.

KiCad와 같은 종류의 프로그램은 PCB를 설계하여 주문하려면 피할 수 없는 선택이다. LTspice와 Fritzing에 이어서 드디어 오늘을 기하여 KiCad에 입문하게 되었다. LibreCAD도 약간은 다룰 줄 안다. 취미 "메이커"가 알아야 하는 필수 소프트웨어를 조금씩은 다 경험하게 된 셈이다. 이러다가 3D 프린팅 도면까지 만들게 되는 것은 아닌지 모르겠다.

페놀 만능기판에 배선 실수와 납땜 불량을 감수하고 얼기설기 만들었던 Nano Ardule을 올해에는 PCB에 옮겨 보고자 ChatGPT에게 step-by-step tutorial을 요청한 뒤 이를 따라서 일단 회로도부터 만들어 보았다. NET LABEL의 개념을 제대로 이해하고 커넥터 배치에 신경을 써야 한다. 특히 아두이노 관련 PCB 설계에서는 커넥터 위치 결정이 절반 이상을 차지한다고 한다. 회로도 설계 단계에서는 일단 Conn_01x05과 같이 1-row의 단순한 것으로 그려 놓았지만, 조만간 어떤 커넥터를 써야 할지 결정을 해야 한다. 이제는 더 이상 프로토타입을 만드는 것이 아니기 때문에, 핀헤더를 납땜해 놓고 듀폰 케이블로 대충 연결할 수는 없다. 작년에 쓴 글 '세상의 모든 커넥터'를 다시 읽으면서 공부를 해야 되겠다. 터미널 압착기(SN-2549 크림핑 툴)를 사 놓기를 잘했다.  

아직 검증되지 않은 회로도. 회로 자체는 작년에 실물호 입증하였으나, 옮겨 그리는 과정에서 많은 실수가 숨어있을 것이다.

회로 자체는 대단히 간단(?)하다. 여기까지는 아마도 매우 쉬운 과정이었을 것이다. 실제 부품에 맞는 footprint를 고르는 일이 더 걱정이다. JST냐 Molex냐... 갖고 있는 부품 재고를 되도록 활용하고 싶은데 핀 수가 맞는지 모르겠다. KiCad의 'Assign Footprints'를 둘러 보았지만 Molex 5045 헤더(2.5mm 피치)에 딱 맞는 footprint가 보이지 않는다. 피치가 동일한 SPOX 5267을 써도 되는지? 혹은 무난하게 JST의 것을?

펌웨어는 이미 작년에 오랜 기간에 걸쳐 개발과 검증을 거쳤기에 별 걱정은 하지 않는다. 3월 중에 충분히 검토를 거쳐서 JLCPCB에 거버 파일을 보낼 수만 있다면 더 이상 바랄 것이 없겠다.

저자에서 디렉터로 — AI 시대 글쓰기의 변화

• 기획: 정해영(director, 국문으로 바꾼다면 구성 감독, 총괄 설계자, 또는 텍스트 연출자?)
• 텍스트 생성: AI 보조(text produced with AI assistance)

오랫동안 글쓰기는 ‘저자(author)’라는 개념을 중심으로 이해되어 왔다. 저자는 텍스트를 생산하는 사람이며, 글의 의미와 책임의 중심에 있는 존재였다. 책의 표지에는 저자의 이름이 적히고, 학술 논문에서는 저자 순서가 중요한 의미를 가진다. 글은 곧 저자의 창작물이었다.

그러나 디지털 환경과 협업적 지식 생산이 확산되면서 이 전통적인 개념은 조금씩 흔들리기 시작했다. 이미 20세기 후반에 여러 사상가들이 이러한 변화를 지적했다. 예컨대 Roland Barthes는 “저자의 죽음”이라는 유명한 글에서 텍스트의 의미는 저자가 아니라 독자의 해석 속에서 형성된다고 주장했다. 이어 Michel Foucault는 “저자는 하나의 기능(author function)”이라고 말하며, 저자를 절대적 창조자가 아니라 지식 체계 속의 역할로 이해했다.

오늘날 AI 도구가 글쓰기 과정에 깊이 들어오면서 이 변화는 더욱 분명해지고 있다. 이제 많은 글은 한 사람이 처음부터 끝까지 문장을 만들어내는 방식으로 생산되지 않는다. 자료 수집, 초안 작성, 문장 다듬기, 번역, 구조 정리 등 여러 단계에서 다양한 도구와 협업이 개입한다. 때로는 AI가 초안을 만들고 인간이 구조를 수정하며, 다시 AI가 문장을 정제하는 방식으로 글이 완성되기도 한다.

이러한 환경에서는 ‘저자’라는 말이 점점 어색해진다. 글을 직접 타이핑한 사람이 누구인가보다 중요한 것은 글의 방향과 구조를 설계한 사람이 누구인가라는 문제이기 때문이다. 다시 말해 텍스트의 생산 과정에서 중요한 역할은 더 이상 단순한 집필자가 아니라 전체 작업을 기획하고 조율하는 사람에게 있다.

이 역할을 가장 잘 설명하는 말은 아마도 ‘디렉터(director)’일 것이다. 영화에서 감독은 모든 장면을 직접 촬영하지 않는다. 배우가 연기하고 촬영 감독이 카메라를 잡으며 편집자가 영상을 다듬는다. 그러나 영화 전체의 방향과 스타일을 결정하는 사람은 감독이다. AI 시대의 글쓰기도 점점 이와 비슷해지고 있다.

앞으로의 글쓰기에서 중요한 능력은 문장을 얼마나 많이 생산할 수 있는가가 아니라, 어떤 질문을 던지고 어떤 구조를 설계하며 어떤 자료를 결합할 것인가일 가능성이 크다. 글은 점점 더 복합적인 생산 과정의 결과물이 되고, 저자는 그 과정을 지휘하는 역할로 이동한다.

따라서 AI 시대의 글쓰기를 이렇게 표현할 수도 있다.

우리는 더 이상 텍스트의 저자라기보다, 텍스트 생산의 디렉터가 되어가고 있다.

이 변화는 단순히 기술의 문제가 아니라 지식 생산 방식 자체의 변화를 보여준다. 글쓰기는 여전히 인간의 사유에서 출발하지만, 그 사유가 구현되는 방식은 점점 더 협업적이고, 도구 의존적이며, 연출적인 형태로 바뀌고 있다. 저자의 시대가 끝났다고 말하기는 아직 이르다. 그러나 적어도 오늘날의 글쓰기에서 저자의 모습이 과거와 같은 형태로 남아 있지 않다는 것만은 분명해 보인다.

---

이 글은 정해영의 아이디어를 바탕으로 AI(ChatGPT)의 도움을 받아 작성되었습니다.
본 텍스트는 Creative Commons Attribution 4.0 International (CC BY 4.0) 라이선스로 공개됩니다.
출처를 표시하는 조건으로 누구나 자유롭게 이용·수정·재배포할 수 있습니다.
정확성에 대한 보증이나 법적 책임은 제공되지 않습니다.

[DokuWiki] 문서 폭을 좁게 만드는 TOC, 어떻게 할 것인가?

DokuWiki에서는 문서 안에 자동으로 TOC(table of contents, 목차)를 만들어 준다. TOC는 문서의 내용을 신속하게 파악하고 특정 위치로 빨리 이동하는 데 큰 도움을 준다.

요즘은 ChatGPT를 써서 마크다운 문서를 만든 뒤 Commonmark Plugin을 이용해 DokuWiki에 삽입하는 일이 많다. 마크다운 문서는 GitHub에 올리기 좋고, 웹브라우저에서도 쉽게 열 수 있기 때문이다. DokuWiki에서는 새 문서를 <!DOCTYPE markdown>이라는 줄로 시작한 다음, 마크다운 본문을 복사해 넣으면 된다.

그런데 이렇게 만들어진 문서에서는 TOC가 끝나고 나서야 비로소 본문이 시작된다. 그래서 위쪽에 긴 여백이 생겨 보기가 매우 좋지 않다. 왜 그럴까? Commonmark Plugin의 렌더링 방식 차이 때문이다. DokuWiki 문법으로 작성된 문서는 본문이 먼저 시작되고, TOC는 오른쪽에 float되며, 본문은 그 옆으로 자연스럽게 흐른다. 그러나 내가 사용한 Markdown wrapper div는 CSS 문제로 인해 본문이 아래로 밀려 내려가면서 공백이 크게 생기는 것이다.

다음은 너무 긴 여백이 보기 흉해서 그림을 삽입한 예이다. 하지만 TOC가 너무 길어지면 그림을 넣어도 별 소용이 없다.

글 원본 링크는 여기. ChatGPT가 당당하게 자기를 '저자'라고 표현하였다.

conf/userstyle.css에서 TOC가 나오지 않게 하면 어떨까? 하지만 이 방법은 위키 사이트 안의 모든 문서에서 TOC가 표시되지 않게 만들기 때문에 바람직한 해결책이 아니다. TOC를 표시하지 않을 문서를 일일이 CSS에 나열하거나, 네임스페이스 단위로 따로 설정할 수도 있겠지만, 그것 역시 번거로운 일이다.

문서마다 개별적으로 자동 TOC를 나오게 하거나 혹은 나오지 않게 하면 가장 좋겠지만, 즉 문서 상단에 위키 매크로인 ~~NOTOC~~를 삽입하면 좋겠지만, 현재 내가 쓰는 플러그인에서는 이것도 잘 먹지 않는다.

DokuWiki 안에서 Markdown을 쓰는 순간 위키 기능의 절반을 잃는다!

적어도 구조화된 기술 문서를 위키 안에서 안정적으로 운영하려면, Markdown보다는 처음부터 DokuWiki 문법으로 작성하는 편이 낫겠다. GitHub와의 호환성은 조금 아쉽더라도, 위키 본연의 기능을 온전히 살리는 쪽이 더 중요해 보인다.

오늘 이 문제를 해결해 보고자 ChatGPT와 더불어 여러 시도를 해 보았으나, 결국은 ‘futile cycle’만 돌고 말았다. 인공지능에 약간 실망하게 된 하루였다.

APS StepSeq 입력 도구의 다변화

Nano Ardule 드럼 패턴학 생태계를 이루고 있는 APS는 기본에 충실한 '스텝 시퀀서' 기능을 내장하고 있다. 16분음표 단위로 세분화된 스텝에 드럼킷을 구성하는 각 악기의 연주 정보를 입력하거나 편집하고, 메인 화면에서는 이를 연결하여 곡 단위의 arrangement 파일(패턴을 이어 붙인 곡 구성표)을 만드는 역할을 한다. 이 생태계를 구성하는 모든 파일 포맷은 ChatGPT와 의논하면서 정의해 나갔다.

스텝 시퀀서, 그러나 실시간에 대한 욕심

스텝 시퀀서라고는 하지만 실시간 입력에 대한 욕심을 충족하지 말라는 법은 없다. 킥 드럼 찍고, 비트마다 하이햇 찍고, 스네어 드럼 소리 찍어 올리고... 이 과정을 실시간으로 오버더빙하듯이 누적하여 입력하면 얼마나 편리하겠는가? 이러한 욕심은 NanoArdule 깃허브 프로젝트에서 메인과 독립한 별도의 브랜치(refactor/stepseq-v3.0a)를 만드는 것으로 이어졌고 마침내 필요한 기능을 모두 구현하게 되었다. 최종 테스트를 거친 뒤 이를 다시 메인 브랜치와 병합하는 일이 남았다.

현재 HEAD는 어디를 가리키는가?

다음은 사무실 PC에서 바라본 각 브랜치의 모습이다. HEAD가 어느 브랜치(또는 커밋)를 가리키는지 확인해 보자. 보다 기술적으로 말하자면, '현재 체크아웃된 브랜치를 확인해 보자'가 되겠다.

PS E:\Projects\NanoArdule\APS> git branch
  main
* refactor/stepseq-v3.0a
PS E:\Projects\NanoArdule\APS> git branch -a
  main
* refactor/stepseq-v3.0a
  remotes/origin/HEAD -> origin/main
  remotes/origin/main
  remotes/origin/refactor/stepseq-v3.0a
PS E:\Projects\NanoArdule\APS> git branch -vv
  main                   5a38227 [origin/main] docs: add Windows 11 KB5077241 compatibility notice
* refactor/stepseq-v3.0a 83625bd [origin/refactor/stepseq-v3.0a] StepSeq: disable REC arm when using GS Wavetable or no MIDI OUT
    

리얼타임 입력 도구

리얼타임 기반의 입력 도구는 컴퓨터 키보드(4×4 keyboard grid)와 MIDI 키보드 컨트롤러의 두 가지를 선택하여 쓸 수 있다. 전자의 경우 자판의 왼쪽 16개 키를 이용하며, 이 때에는 벨로시티를 조정하지는 못한다. 후자의 경우는 AKAI MPK Mini MKII의 4×2 패드를 사용한다. 사실 어떤 MIDI 키보드 컨트롤러를 써도 상관은 없다. AKAI 미니 키보드에서는 패드 설정을 바꾸어서 원하는 악기 소리가 나도록 해 두었다. 드럼의 각 악기 선택과 패드 배열에 대한 상세한 정보는 별도의 스펙 문서로 정리하였다. PC 키보드 일부를 4×4 패드처럼 쓰는 방식을 나는 4×4 keyboard grid라고 부르기로 했다. 아래 그림에서 알파벳 두 글자로 표기된 드럼계열 악기명 약어의 설명과 실제 GM 드럼킷에서 할당하는 노트번호는 위에서 언급한 스펙문서에 상세히 설명되어 있다.

Microsoft GS Wavetable Synth의 한계

문제는 latency다. PC에 내장된 Microsoft GS Wavetable Synth가 소리를 내는 상태에서는 반응 속도가 느려서 리얼타임 입력 도구를 사용하기 곤란하다. 따라서 MIDI OUT이 외부 음원 모듈로 연결되지 않았다면 Record가 아예 되지 않게 만들었다. 이러한 상태에서 'R'을 누르면 'REC disabled: Microsoft GS Wavetable is high-latency'라는 경고문이 나온다. 녹음은 타이밍 정확도가 중요하므로 차단하고, 미리듣기(Preview)는 학습/확인 목적이므로 허용한 것이다. 그러나 외부 MIDI 음원이 없더라도 녹음 모드가 아니라면 키보드 또는 패드를 누를 때 Microsoft GS Wavetable Synth를 통해서 소리는 난다('Preview').

앞으로 나아갈 방향

ASIO를 사용하는 DAW를 대체하기 위하여 APS/StepSeq을 만든 것은 아니니, 이러한 latency 문제를 적극적으로 해결할 계획은 아직까지는 없다. APS는 완성형 드럼 머신과 경쟁하려는 도구가 아니다. 그러나 입력 방식의 실험이라는 점에서 충분히 의미 있는 시도가 될 것이다.

운영체제가 나의 TUI를 부수던 날

오늘은 Nano Ardule의 APS 개발에서 이정표 하나를 세울 수 있는 날이었다. StepSeq 코드를 개선하여 '루퍼'와 유사하게 드럼 연주 정보를 입력하도록 만들었기 때문이다. 16 x 12로 펼쳐진 그리드 위에서 커서를 화살표로 이동하여 엔터키를 눌러 노트를 입력하는 스텝 시퀀서 본연의 기능은 이미 잘 다져진 상태였다. 여기에 외부 장비인 AKAI MPK MINI MkII를 연결하여 패드를 터치하면 드럼 패턴을 실시간으로 자연스럽게 녹음할 수 있다. 메트로놈 소리를 들으면서 베이스 드럼을 먼저 찍고, 다음으로 스네어 드럼, 그 다음에는 하이햇... 스크립트 실행 전 MIDI 기기 연결 상태를 점검하는 환경변수 설정을 먼저 해야 했던 다소 비효율적인 최근의 변경도 훨씬 안전하고 단순한 방식으로 고쳐 놓았다.

StepSeq의 기능을 이렇게 맞추어 나가기 위해 메인에서 독립한 별도의 브랜치(refactor/stepseq-v3.0a)까지 만들어서 몇 시간을 투자한 끝에 원하는 목표까지 달성을 하였다. 마침 Windows update가 있다는 알림이 있어서 설치를 지시해 놓고 아내와 함께 잠시 장을 보고 돌아왔는데...

APS에서 화면이 하나도 나오지 않는 것이다. 말 그대로 까만 터미널 창 그 자체의 '조용한 실패'였다. 챗GPT와 질문을 주고 받으면서 별의별 노력을 다 해 보았지만, TUI(text user interface)를 구현하기 위한 핵심인  ncurses 라이브러리의 작동이 Windows update와 더불어 문제를 일으킨 것 같다는 것이 최종 결론이었다.

오늘 설치한 Windows 11 버전 25H2 및 24H2(KB5077241)에 대한 비보안 업데이트는 KB5077241이다. 원인을 확실하게 알기 위해서 이 업데이트를 제거한 뒤 재설치해 보았다. [설정 > Windows 업데이트 > 업데이트 제거] 순서로 작업하면 된다.

KB5077241은 프리뷰(선택적) 업데이트였다. 설치하지 않아도 Patch Tuesday에 배포되어 자동으로 설치되는 다음 정식 누적 업데이트에 포함될 것이고, 안정성이 중요한 개발 환경에서는 보통 건너뛰는 것이 안전하다고 한다.

그러면 다음번 정식 업데이트가 KB5077241를 그대로 포함할 것이니 또 TUI와 관련한 문제가 재발하지 않겠는가? 꼭 그렇지는 않다. 문제 있는 부분은 수정되거나 제외될 수 있기 때문이다. 프리뷰 업데이트를 기계적으로 설치하는 버릇을 고쳐야 되겠다.

KB5077241를 삭제하였더니 업데이트를 하라는 알림이 트레이에서 다시 뜨기 시작하였다. '최신 업데이트가 제공되는 즉시 받기'를 꺼 두기로 하였다.

업데이트를 제거한 결과는? 언제 그랬느냐는 듯이 멀쩡한 APS 화면으로 돌아왔다. 어째서 이런 일이 벌어진단 말인가... 챗GPT에 의하면, Windows 업데이트 이후 curses/ncurses 계열이 깨지는 일은 꽤 자주 보고된다고 한다. 개발이 쉬울 것이라 생각해서 TUI를 선택하였는데, OS 변화 영향이나 Windows 호환과 관련해서는 nurses TUI보다 GUI가 더 낫다니 이는 미처 예상하지 못했던 일이다.

장기적으로는 curses 의존도를 줄여 나가는 것이 좋을 것이다. 앞으로 개발에 약간의 수고가 더 들더라도 GUI로 갈아타는 것을 오늘 처음으로 고민하기 시작하였다. 간단한 조사를 통해서 다음과 같이 결론을 내려 보았다.

🚩 PySimpleGUI로 전체 GUI 스켈레톤을 먼저 만들고,
StepSeq가 답답하면 그 부분만 Dear PyGui 스타일로 개선

refactor/stepseq-v3.0a 브랜치의 테스트를 완벽히 마친 뒤 main과 병합한 다음, GUI로 넘어가기 위한 탐색을 시작하련다. 만약 오늘의 작은 '사고'가 아니었더라면, GUI에 대한 호기심은 일절 갖지 않았을 것이다. 취미 코딩의 종착역이 어디까지 가게 될지 모두지 알 수가 없다.

오늘의 결론은 이러하다. 코드는 멀쩡했다. 운영체제가 바뀌었을 뿐이다. 이것이 새로운 시도로 이어지는 계기가 될 수도 있겠다.

갈라질 결심(Creating a Git Branch)

갈라진다고 하여 사람이나 조직과 인연을 끊거나 헤어진다는 뜻은 아니고, Git에서 새로운 기능을 넣기 위해 처음으로 메인에서 독립하여 별도의 브랜치를 만들겠다는 뜻이다.

Nano Ardule 드럼 패턴학 생태계에서 PC쪽 패턴 생성 및 편집기, 즉 APS(Ardule Pattern Studio)는 기본적으로 키보드를 두드려서 입력을 하는 데 충실하게 만들었다. 실시간 연주를 받아들이는 것이 아니라 StepSeq, 즉 16분음표 단위의 스텝으로 커서을 이동하여 선정된 악기의 타격 신호를 기록한다. 2차원 그리드 위에 체크 표시를 한다고 생각하면 간단하다. 어제도 코드 효율을 높이기 위한 약간의 수정을 하여 commit를 한 상태이다.

이번 단계의 목표는 AKAI MPK Mini MKII를 입력 장치로 쓰게 만드는 것이다. 그러면 컨트롤러의 4x2 패드를 이용하여 드럼 패턴을 입력할 수 있기 때문이다. 이미 패드를 두드려서 스텝 단위 입력을 할 수 있게 만들어 두었으나, 욕심을 좀 더 부려서 마치 루퍼처럼 오버더빙 형식의 실시간 입력을 가능하게 만들고 싶다.

그러려면 상당한 수준의 코드 수정이 필요하기에 아예 이번 기회에 branch를 새롭게 생성해 보기로 하였다. 브랜치 생성 요령은 별도의 문서('Safe Git Branching Guide for StepSeq Refactoring')로 정리해 두었다. 어제까지 완성하여 안정화된 기능(키보드를 통한 스텝 입력)은 일절 건드리지 않아야 한다.

그리고 한가지 더. GUI나 DAW로 관심이 이동하면 절대로 안 된다! 그건 나의 본분을 잊는 행위이다. 목표를 명확히 하고 개발의 시행착오를 줄이기 위하여 이번 단계의 설계 개념은 문서로 충분히 작성해 두었다. 

레코딩('녹음'이라고 표현하면 오디오 신호 자체의 기록이라는 느낌이 강하게 든다)을 자체 개발 파이썬 스크립트로 소박하게 구현해 보면서 몇 가지 중요한 개념을 공부하게 되어 좋은 기회라고 생각한다.  녹음과 재생에 대한 각종 설정 또는 제어 상태는 다음과 같은 계층 구조로 이해하면 좋다.

1. Transport layer: 플레이헤드 진행 및 루프 범위 제어
2. Record arm layer: 입력이 패턴을 수정할 수 있는지 결정
3. Write policy (overwrite or overdub): 기존 데이터와 새 입력의 병합 방식 정의

만약 이 브랜치에서 성공적으로 개발이 완료된다면, APS의 StepSeq은 아주 쓸모 있는 장난감이 될 것이다. 

그리고... 업무 스트레스를 달리기로 푼 어제의 기록. 기온이 많이 올라서 야간 달리기를 하기에 아주 좋았다. 479kcal를 태웠으니 라면 한 그릇의 열량을 소모한 정도?

만족스럽지 못한 2월의 달리기 기록. 일본 여행과 날씨 탓이 크다. 어제는 오랜만에 7km를 넘게 달렸다.

데이터 분야 'AI 준비도'(AI readiness)의 압박

지금은 인공지능 대전환기이자 대혼란기이다. '대혼란기'라고 한 이유는, AI와 관련하여 '몇 시까지 자료 만들어 주세요(보통 2~3시간 이내)'라는 급박한 요청이 부쩍 늘어났기 때문이다. 자발적인 것이든 외부 요인에 의해 어쩔 수 없는 것이든 실제로 AI에 적응하려면 조직, 나아가 개인의 일하는 방식이나 사고 방식에 이르기까지 해체에 가까운 변혁이 필요하다. 좀 천박하게 말한다면 매일 'AI 대환장 파티'가 벌어지고 있다.

IBM의 웹사이트에서  Thriving through AI disruption이라는 글을 읽어 보았다. AI 준비도(AI readiness)의 5대 축은 다음과 같이 묘사된다.

1. Strategy & business alignment
2. Data foundation
3. Technology & architecture
4. Talent, skills & culture
5. Operating model & governance

내가 일하고 있는 조직, 특히 바이오와 같은 high-stakes 영역에서는 2번 data foundation이 가장 중요하다. 왜냐하면 우리는 바이오 연구 데이터의 수집, 관리 및 활용 기반을 제공하는 곳이기 때문이다. 이러한 체제를 갖추어서 실제로 부끄럽지 않은 수준으로 돌아가게 된 지는 그렇게 오래 되지 않았다.

논문에 쓰인 연구 데이터를 과학 발전을 위해 공유하는 아름다운 관행은 인공지능이 유행을 타기 훨씬 전부터 널리 퍼져 있었다. 이를 위해서 데이터 리포지토리가 매우 중요한 역할을 해 왔다. 현재의 문제는 리포지토리에 모인 데이터를 인공지능 학습용으로 그대로 가져다 쓸 수 있느냐에 있다. 

완벽한 데이터란 실제로 그렇게 많이 존재하지 않는다. 그러나 우리는 다음과 같은 말을 많이 듣는다.

'쓸 만한 데이터가 없다'

'AI 학습이 가능한 형태로 가공되어 있지 않다' 

수요자 입장에서는 충분히 나올 수 있는 이야기이다. 하지만 이것이 'AI 투입을 위해 모든 자원이 갖추어져야 한다'라는 입장으로 변질되어 권력의 틀을 쓰면 모두가 힘들어진다.

우리가 늘 준거집단으로 삼는 미국에서는 최근 Genesis Mission의 출범을 통해 AI 총동원 기조가 강화되고 있다. 데이터와 (인적·컴퓨팅)자원을 AI에 총동원해야 한다는 주장은 무한 경쟁 시대의 국가적 생존이나 경제·안보 등의 키워드를 등에 업으면 그 자체가 '권력'이 된다. 특히 더 나은 모델을 늘 벤치마킹해야 한다는 압박에 시달리는 우리나라에서는 국외의 사례가 정책 정당성의 근거로 과도하게 사용될 위험이 있다.

• 선진국 사례가 곧 '정당성'이 아니다.
• 국가안보 또는 경쟁 프레임은 안전과 권리에 대한 논의를 약화시킨다.
• AI 에이전트/파운데이션 모델은 검증 비용을 없애지 않는다.

나에게 본업이 아닌 취미 활용 영역에서 AI란 매우 흥미롭고 효율을 높여주는 도구이지 동반자였다. AI가 제시한 전자회로와 코드는 반드시 나의 실증을 거쳤고, 그러한 최종 마무리 과정에는 결코 적지 않는 노력이 들었다. 확인되지 않은 AI 활용 결과물은 개인 차원의 재미 추구에는 문제가 없다. 그러나 그것이 정책으로 번져 나가면 그 파급효과는 너무나 크다. 가뜩이나 쏠림이 심한 우리나라 사회에서 역적으로 몰리기는 너무나 쉬운 일이니까.

AI가 애써 고민하고 결론을 내리는 인간의 영역을 완전히 대체하는 방향까지 나아가는 것은 경계한다.

다음과 같은 글에도 관심을 가져 보자.

데이터센터 모라토리엄 - 경향신문 에디터의 창, 2월 26일.

'AI 데이터센터 특별법처럼 이익은 사유화하고 비용은 공공이 지게 하려는 시도에 제동을 걸어야 한다.'