Machikoba no Techo

쓸 줄 아는 사람만이 위험을 알아본다.

9월입니다. 이곳 여름의 정취 가운데 하나인 한치(창오징어) 야간 집어등 낚시 시즌도 슬슬 끝을 향해 갑니다. 밤바다로 배를 내던 분들도 조용히 저희가 budouika, '포도오징어'라고 부르는 쪽으로 옮겨 가고 있습니다. 늘 변함없는 성원에 진심으로 감사드립니다.

그리고 9월에는 또 하나의 얼굴이 있습니다. 무늬오징어(aori-ika)가 모여드는 계절이라는 것입니다. 여름의 정점에서 수온이 가라앉기 시작하면 베이트 피시가 일제히 활기를 띱니다. 오징어도 그에 맞춰 달라지고, 새끼 오징어 무리가 얕은 곳으로 들어오면서 마즈메(여명·황혼)의 짧은 시간대에 방파제 곳곳에서 로드가 휘어집니다. 한 해 중 가장 설레는 시기일지도 모릅니다. 에깅을 시작해 볼까 하는 분에게도 가장 부담 없는 계절입니다.

이번 달에도 공장 뒤편 이야기를 적어 보려 합니다. 지난달에는 AI가 써 주더라도 멈춰 세워 확인하는 일은 사람의 몫이라고 썼습니다. 이번 글은 그 속편입니다. 지난 1년, 이른바 '바이브 코딩'을 현장에서 실컷 써 보면서 그 힘과 꼭 그만한 크기의 위험을 함께 느꼈습니다. 그리고 아마 많은 분이 마주하고 있을 질문에 부딪혔습니다. AI가 만들어 낸 코드를, 안을 들여다보지 않은 블랙박스인 채로 현장에 들여도 되는가?

■ '이런 걸 원한다'고 말하면, 움직인다

바이브 코딩이란 상세한 사양서를 건너뛰고, 원하는 것을 보통의 말로 설명해 AI에게 쓰게 한 뒤 움직이는 물건을 돌려받는 방식입니다. 지난 1년, 현장용 작은 도구를 바로 이런 식으로 여럿 만들었습니다. 아니, 숨 쉬듯이 도구를 만들어 낸다는 편이 맞겠습니다.

먼저 말씀드리면, 이것은 정말로 강력합니다. '하고는 싶지만 알아볼 시간이 없다'며 미뤄 두었던 일이 떠올린 그날 바로 움직입니다. 예전이라면 외주 업체 견적부터 시작했을 일이 점심시간 사이에 형태를 갖춥니다. 저희 같은 작은 공장에 이보다 반가운 변화는 없습니다.

■ 움직이는 것과 올바른 것은 다르다

그런데 올해 가장 무서웠던 것은 바로 그 움직인다는 점이었습니다. 나온 것은 대개 동작합니다. 화면은 말끔하고 숫자도 표시됩니다. 움직이기 때문에, 그것이 건전한지 위험한지는 밖에서 봐서는 알 수 없습니다.

한 군데만 미묘하게 다른 반올림. 예상 범위를 벗어난 값이 들어왔을 때의 정의되지 않은 동작. 조용히 삼켜져 아무 일도 없었던 듯 진행되는 오류. 이런 것들은 잘 돌아가는 화면을 아무리 들여다봐도 보이지 않습니다. 보이는 사람은 그런 코드를 직접 써 보고 데어 본 사람뿐입니다.

결국 나온 코드를 전부 따라가 보기 전에는 마음을 놓을 수 없습니다. 맡겨서 아꼈어야 할 시간이 고스란히 읽는 시간으로 되돌아옵니다. 만드는 문턱은 엄청나게 낮아졌지만, 위험을 알아채는 문턱은 그대로였습니다. 이 비대칭이 올해 배운 것 가운데 가장 분명한 것입니다. 저희 식으로 말하면, 4,000만 엔짜리 머시닝 센터 앞에서 '움직였으니 됐다'고 말하는 것과 같습니다. 그것은 결코 허용되지 않습니다.

■ 작은 공장에 이상적인 소재는 없다

그렇다면 쓸 수 없는 도구인가 하면, 전혀 그렇지 않습니다. 저희 일의 어떤 부분에는 무엇보다 잘 맞습니다. 다만 그것을 설명하려면 작은 공장의 현실을 한 번 돌아가야 합니다.

제 경우에는 조금 별난 일을 일상적으로 합니다. NC — 기계의 언어 — 를 바이브 코딩으로 만들어 냅니다. NC를 출력하는 코드를 쓸 때는 대개 Python이 자동으로 선택되지만, 저는 대부분 그것을 Ruby로 바꿉니다. 그게 제 방식입니다.

요즘의 NC 공작기계는 대단히 정밀합니다. 이상적인 소재와 이상적인 형상, 이상적인 치수를 주면 놀랄 만한 마무리로 깎아 냅니다. 그런데 저희 작업장에는 그 이상적인 조건이 거의 갖춰져 있지 않습니다. 지금 손에 있는 것으로 해내야 합니다. 소재는 고르지 않고, 형상도 크기도 매번 다릅니다. '도면대로'라는 전제 자체가 눈앞에 없습니다.

저는 이것을 '있는 것으로 해내는 정신'이라고 부릅니다. 작은 공장의 강점이자 저희의 자부심이지만, 프로그램을 쓰는 쪽에서 보면 꽤나 성가신 상대입니다. 치수가 매번 다르니 숫자를 박아 넣은 절차서를 쓸 수 없습니다. '이 형상을 이 치수로 깎아라'가 아니라 '눈앞의 것을 재고, 그 값에서 깎을 양을 끌어내라'로 바꿔 써야 합니다. 다시 말해 추상도를 상당히 끌어올려야 합니다. 작은 공장에서 프로그래밍을 할 때 가장 어려운 부분이 여기입니다.

■ 소재에 맞추는 일과 리버스 엔지니어링에는 안성맞춤

그리고 이 '실물에 맞춰 간다'는 방식은 바이브 코딩과 놀랄 만큼 닮았습니다. 완벽한 사양서가 먼저 있는 것이 아니라, 눈앞의 대상에 다가가며 깎아서 맞춰 보고, 맞춰 보고 다시 깎습니다. 일단 움직이는 것을 만들게 하고, 잘못된 곳을 짚어 고치게 하고, 다시 시도합니다. 사양이 정해지기 전에 손을 움직일 수 있으니 '있는 것으로 해내는' 현장과 무척 잘 맞습니다.

무엇보다 바이브 코딩은 가장 어려운 부분, 즉 추상도를 끌어올리는 일을 잘 보완해 줍니다. 숫자를 박아 넣은 판본을 하나 보여 주고 치수가 바뀌어도 동작하게 해 달라고 하면, 무엇을 변수로 삼아야 하는지 골라냅니다. 사람이라면 며칠이 걸렸을 일반화의 실마리 — 어디부터 손을 대야 하는가 — 가 단숨에 정리됩니다. 바로 저희의 '있는 것으로 해내는' 현장에 부족했던 능력입니다.

또 하나 잘 맞는 것이 리버스 엔지니어링입니다. 속을 모르는 구조를 밖에서 두드려 보며 그 뒤의 논리를 재구성하는 일입니다. 낯선 데이터 형식이나 오래전에 누군가 쓴 긴 코드를 읽고 무슨 일을 하는지 알아내는 데는 놀랄 만큼 든든합니다. 애초에 저희가 이해하지 못하던 영역이니 틀려도 손해가 적습니다. 실마리만 잡히면 나머지는 사람이 검증할 수 있습니다.

가까운 예로, 기계 제조사가 직접 출력한 NC 프로그램이 있습니다. 솔직히 저는 그것을 그리 좋아하지 않습니다. 들여쓰기도 없고 주석도 도움이 되지 않아 무슨 일을 하는지 읽어 낼 수가 없습니다. 읽을 수 없는 프로그램은 멈춰 세워 확인할 수 없는 프로그램입니다. AI는 그 빈틈을 메워 줍니다. 코드가 읽기 어려우니 들여쓰기와 주석을 붙여 달라고 하면 정확히 그대로 돌아옵니다. 추상도가 너무 낮으니 서브루틴으로 나눠 달라고 하면 의미 있는 덩어리로 코드를 갈라 줍니다. 동작은 그대로, 사람이 읽을 수 있는 형태로 정리해 주는 것 — 지금 저희가 가장 자주 쓰는 용도일지도 모릅니다.

가장 곤란한 것은 서브루틴이 어떤 변수에 부작용을 미치는지가 어디에도 적혀 있지 않다는 점입니다. 호출하면 무언가가 바뀝니다. 그런데 무엇이 바뀌는지는 전체를 다 읽기 전에는 알 수 없습니다. AI에게 읽히고 안에서 값이 쓰이는 변수를 맨 앞 주석에 나열해 달라고 하면 그것들을 골라 줍니다. 사람이 반나절을 들이던 일입니다.

구체적인 예를 하나 들겠습니다. 저희는 와이어 방전 가공기의 NC 프로그램을 AI에게 손보게 하는 일이 잦습니다. 코피가 날 만큼 편리합니다. NC의 세계에서는 모두가 'G-code'라고 부르면서도 제조사마다 쓰는 버릇이 있습니다. 사실상 방언입니다. 이 기종은 이렇게 쓰고, 저 기종은 이 명령이 필요하다는 식입니다. 사람에게는 매뉴얼을 비교하고 현장에서 익히는 수밖에 없는 일입니다.

AI는 그것을 건네받은 프로그램의 문체에서 읽어 냅니다. 이 코드가 누구의 관례를 따르고 있는지 감지하고, 덧붙이는 부분도 같은 관례로 씁니다. 제조사 매뉴얼까지 함께 주면 시키지 않아도 그 기종 전용 매크로를 쓰기 시작합니다. '이 기계에는 이런 명령이 있다'는 것을 읽어 내고 태연한 얼굴로 써 넣습니다. 오랜 세월 공장 현장에 쌓여 온 암묵지가 이렇게 끌려 나오는 것을 보고, 솔직히 등골이 서늘했습니다.

다만 그렇게 만든 프로그램을 그대로 기계에 보내는 일은 결코 없습니다. 디버그를 합니다. 반드시 실기에 올려 한 줄씩 짚어 가며 변수 값과 와이어의 움직임을 눈으로 확인합니다. 지난달에 썼던 M01(옵셔널 스톱)이 힘을 발휘하는 대목입니다. 아무리 잘 만들어진 것처럼 보여도, 실기에서 디버그할 능력이 없다면 이 도구는 쓸 수 없습니다. 아니, 써서는 안 된다고 생각합니다. 정답을 만들어 내는 도구로 쓰면 위험하고, 실마리를 찾는 도구로 쓰면 강력합니다. 다만 그 실마리를 확인하는 일은 언제나 사람의 몫입니다.

■ 블랙박스인 채로 괜찮은가

그래서 처음의 질문으로 돌아옵니다. AI가 만들어 낸 코드를 안을 보지 않은 채 현장에 들여도 되는가. 솔직히 저희는 들여도 되는 경우와 안 되는 경우를 나누고 있습니다. 지금 긋고 있는 선은 그것이 어디에 놓이는가입니다. 나중에 실수를 알아채고 고칠 수 있는 곳, 잃는 것이 시간뿐인 곳에서는 전부를 따라가지 않고 씁니다. 기계가 움직이고 치수가 정해지고 소재가 소모되는 곳 — 두 번째 시도가 없는 곳에서는 아무리 멀리 돌아가더라도 사람이 전부를 읽습니다.

까다로운 것은, 블랙박스가 AI가 쓴 부분만이 아니라는 점입니다. 오늘날의 소프트웨어는 GitHub 등에 세계 어딘가의 누군가가 공개한 라이브러리를 대량으로 불러다 쓰며 만들어집니다. 얼마 전에도 JavaScript 세계에서 큰 사건이 있었습니다. (사실 백도어는 거의 매일같이 나오는 듯합니다.) 수많은 소프트웨어가 딛고 선 라이브러리가 탈취되어, 설치할 때 실행되어 다음 패키지로 스스로 퍼지는 장치가 심어졌습니다. 몇 시간 만에 수백 개의 패키지가 오염된 것으로 보입니다. 그 얼마 전에는 전송 도중에 가로채 결제 대상을 바꿔치기하는 사례 — 즉 돈을 다루는 부분을 조작하는 사례도 있었습니다.

AI에게 '이런 걸 원한다'고 하면, 당연하다는 듯 편리한 부품을 골라 넣어 줍니다. 빠른 이유의 일부는 그 부품을 직접 쓰지 않기 때문입니다. 그러니 저희가 받아 드는 것은 이중 구조입니다. AI가 쓴 상자 안에서, 다시 남의 상자를 부르고 있는 것입니다. 무엇이 섞여 있는지 모르는 소재를 깎는 장인은 없습니다. 소프트웨어도 마찬가지라고 생각합니다.

남의 상자를 믿을 수 있는가 하는 이 질문은 새로운 것이 아닙니다. 1990년대 중반, 메일 전송 프로그램 qmail을 쓴 D. J. Bernstein은 (저희도 10년도 더 전에 그것을 운용했습니다) 표준 C 라이브러리 — 언어에 딸려 오는, 누구나 의심 없이 쓰는 부품 — 조차 믿지 않았습니다. 그는 설계 노트에서 표준 라이브러리를 사실상 포기했다고 밝히고, 문자열 처리나 메모리 관리처럼 사고가 가장 나기 쉬운 부분을 여러 해에 걸쳐 직접 만든 작은 부품으로 바꿔 놓았습니다. 운영체제까지 새로 만들지는 않았지만, 한 가지 점에서는 철저했습니다. 위험한 부분은 자기 손 안에 두라는 것입니다.

qmail을 관통하는 것은 믿어야 할 것을 최대한 줄인다는 사고방식입니다. 부품을 직접 쓰는 데서 그치지 않고, 프로그램 내부를 역할별로 작게 나누어 자기가 만든 부품끼리도 서로 믿지 않도록 만들었습니다. 그중 하나가 탈취되어도 거기서 더 나아갈 수 없게 말입니다. 30년 전에 이것을 끝까지 생각한 사람이 있었습니다. 물론 저희가 모든 라이브러리를 직접 쓰는 흉내를 낼 수는 없습니다. 그러나 믿을 수 없는 것이 섞여 든다는 전제로 경계를 긋는다는 발상은 지금도 그대로 통합니다.

그리고 무서운 것은, 상자가 너무 크면 되돌아갈 길이 없다는 점입니다. 속을 모르는 것을 큰 덩어리째 들여오면 무슨 일이 생겼을 때 떼어 낼 수가 없습니다. 그러니 대책은 설계에서 세워야 합니다. 언제든 갈아 끼울 수 있는 형태로 유지할 것. 이 부분은 다른 것으로 바꿀 수 있고, 이 부품을 빼도 전체는 돌아간다. 그렇게 만들어 두면 무슨 일이 생긴 날 그 상자만 버릴 수 있습니다.

거기에 필요한 것이 객체지향적인 의미의 설계 능력입니다. 무엇을 하나의 단위로 볼 것인가, 무엇을 밖으로 드러낼 것인가, 안쪽을 어디까지 감출 것인가. 경계를 어디에 그을 것인가. 예전에는 '깔끔하게 쓰는 일'로 여겨지던 것이, 이제는 위험한 것을 안으로 들이지 않기 위한 실질적인 필요가 되었습니다. AI가 내용을 쓰기 때문에 오히려 경계를 정하는 능력이 필요합니다.

그리고 이 선은 내버려 두면 움직입니다. 잘 풀리는 일이 이어지면 사람은 아무래도 상자를 더 크게 만들고 싶어집니다. 게다가 직접 쓰지 않는 만큼 정확히 그만큼 위험을 알아채는 능력이 무뎌집니다. 이 도구에는 쓰면 쓸수록 꿰뚫어 보기 어려워지는 성질이 있습니다. 그러니 선은 도구 쪽이 아니라 사람 쪽에서 다시 그어야 합니다.

■ 코딩보다 시스템 엔지니어링

한 해를 돌아보며 인상이 가장 크게 바뀐 곳이 여기입니다. 앞으로 정말로 없어서는 안 될 것은 코딩 자체가 아니라 시스템 엔지니어링이라는 점입니다.

무엇을 만들고 무엇을 만들지 않을지 정하는 일. 기계에 맡기는 부분과 사람의 판단이 이어받는 지점 사이에 선을 긋는 일. 만들기 전에, 멈췄을 때 어떻게 되돌릴지를 준비해 두는 일. 데이터를 어디에 두고 누가 책임질지 정하는 일. 아무리 똑똑해져도 AI가 이것들을 대신 정해 주지는 않습니다. 정하려면 현장의 일을 알아야 하기 때문입니다.

코드를 쓰는 시간이 줄어든 대신, 설계와 운용, 그리고 멈출 때를 판단하는 데 시간을 쓰게 되었습니다. 얄궂게도 쓰는 수고가 사라지면서, 쓰기 전에 오는 일의 무게가 훨씬 또렷하게 보이기 시작했습니다.

■ 아리타에서, 전 공정을 자사에서

작은 회사에서는 만든 사람이 쓰고, 고장 나면 같은 사람이 고칩니다. 그래서 '만들 수 있는가'보다 '스스로 돌볼 수 있는 범위 안인가'가 훨씬 중요합니다. 멈춘 날 자기 힘으로 되살릴 수 있는 규모로 유지할 것. 화려하지는 않지만, 이것이 자기 몸에 맞춘 DX라고 생각합니다.

이것은 에기(egi)를 만드는 일과 똑같은 이야기입니다. 시제품은 예전보다 훨씬 빨리 나옵니다. 그러나 바다에서 확인하는 과정만은 어떤 수를 써도 줄일 수 없습니다. 좋고 나쁨을 마지막에 정하는 것은 언제나 바다입니다. 빨리 만들 수 있게 된 만큼 확인에 시간을 더 들인다 — 저희가 고른 쓰임새는 그것입니다.

일본 사가현 아리타라는 작은 지방 마을에서, 저희는 설계부터 금형 절삭, 양산, 판매까지 전 공정을 자사에서 하며 에기(egi)를 계속 만들고 있습니다. 8월에 생각하던 것이 그런 일들이었습니다. 세계 어딘가에서 누군가가 쓴 부품이 저희 공장 안에서 돌아가고, AI가 저희 기계의 방언을 읽어 냅니다. 그 한가운데에서 사람의 손에 남겨 두어야 할 것은 무엇인가. 답은 절반도 나오지 않았지만, 생각하기를 멈추지 않으려 합니다.

■ 이번 달 바다로

9월에는 저희도 신색과 신제품이 이어집니다. Akazamurai Meteor Glow Orange는 야광과 UV 조사에서 표정이 달라지는 오렌지로, 이번 달 출시 예정입니다. 쇼어 팁런을 겨냥한 JetChaser Purple Edition도 이번 달입니다. 여기에 더해 JetChaser 3.0호와 3.1호가 일반 판매에 들어가며, 출하는 9월 말로 예정하고 있습니다.

올해는 EgiSharp의 'Akazamurai' 컬러가 태어난 지 15년째가 되는 해이기도 합니다. 지난달 말에는 15주년을 기념하는 컬러의 이미지를 공개했습니다. 15년 동안 계속 선택받아 왔다는 사실은 저희의 자신감이 아니라, 써 주신 분들이 내려 주신 답입니다.

도구가 아무리 똑똑해져도 마지막에 판단하는 것은 사람이고, 좋고 나쁨을 정하는 것은 바다입니다. 그 점을 잊지 않고 한 걸음씩 계속 만들어 가겠습니다. 이번 달에도 성원해 주셔서 감사합니다.

2026년 9월
KeyStone Corporation
대표이사 Nobuhide Kanagawa