SpotOn: 하네스가 앉을 수 없는 두 자리

앞선 글들이 은근히 자랑스러웠다. 에이전트가 펌웨어를 쓰고, 앱을 만들고, ML 파이프라인을 돌리고, PCB까지 뽑았다. 혼자서.

그러다 궁금해졌다. 제품 하나를 진짜 세상에 내놓으려면 뭐가 다 필요하지? 앉아서 목록을 만들었다. 펌웨어, 앱, 백엔드, PCB, 기구 설계, 전력, 인증, 금형, 마케팅, 재무, 법무… 세다 보니 스물여덟 개가 나왔다. 그중 내가 “개발”이라 부를 만한 건 열둘뿐이었다.

목록을 다시 봤다. 코드로 된 자리는 죄다 에이전트가 이미 쥐고 있었다. 왜 회사가 다 굴러가는 것처럼 보였는지 그제야 알았다. 코드는 어차피 전부 파일이었다. 정작 나머지 열여섯 개는 세다가 슬그머니 넘어가고 있었다. 인증? 금형? 보험? 그런 건 “나중 문제”라며 목록 끝에 흐릿하게 밀어두고 있었다.

지난 글들은 전부 개발 렌즈였다. 그런데 개발은 스물여덟 자리 중 열둘일 뿐이다. 나는 그 열둘을 회사 전체로 착각했다. 내가 앉을 줄 아는 자리만 세고, 앉을 줄 모르는 자리는 없는 척했다.

진짜 기준은 ‘파일이냐’였다

처음엔 규율마다 이렇게 물었다. 에이전트가 할 수 있나, 없나. 그 축이 곧 틀렸다는 걸 알았다. 에이전트가 되는 일과 안 되는 일의 경계가, 개발이냐 아니냐랑 안 맞아떨어졌다. 진짜 갈림은 다른 데 있었다. 산출물이 파일로 끝나느냐, 아니냐.

에이전트가 뱉는 건 전부 파일이다. 코드도 파일이고, 문서도 CAD도 설정도 파일이다. 그러니 산출물이 파일인 자리는 개발 바깥에도 널려 있었다. 몇 개만 보자. 포지셔닝 문서는 개발이 아니지만 결국 텍스트 파일 한 장이다. 제품 로드맵도, 랜딩 페이지 코드도, 인증 기술 파일 초안도 그렇다. 심지어 보안 하드닝조차 대부분 설정 파일을 고치는 일이다. 하나같이 개발처럼 안 생겼는데, 산출물은 파일 한 장으로 떨어진다. 그래서 개발이든 아니든, 이런 자리는 전부 에이전트한테 넘어갔다.

백엔드가 제일 극적이었다. 처음엔 전용 서버를 세우고 계속 운영할 생각이었다. 서버 관리라는 규율 하나가 통째로 붙는 셈이다. 그런데 BaaS와 스토어 결제로 방향을 틀었더니, “서버를 운영한다”는 규율 자체가 사라졌다. 남은 건 설정 파일 몇 개뿐이었다. 사람 한 명 몫이 설정 몇 줄로 증발했다.

문 앞까지만 데려다주는 자리

전부 이렇게 파일로 깨끗하게 안 끝났다. 설계도, 서류도, 모델링도 내가 파일로 끝내는데, 그 뒤에 내 손을 벗어나는 마지막 한 걸음이 꼭 붙는 자리가 있었다.

RF 안테나가 그렇다. 모듈을 어디 놓을지, 주변 금속을 얼마나 비울지(keepout) 도면은 내가 다 그린다. 여기까진 파일이다. 그런데 이 안테나가 실제로 규격을 통과하는지는, 인증 랩의 실측 장비 앞에 보드를 올려야만 나온다. 그 측정은 파일이 아니다.

금형도 똑같다. 몰드를 어떻게 설계할지, 사출에 문제가 없을지(DFM) 검토까지 내가 파일로 한다. 그런데 실제 강철을 깎아 금형을 만드는 건 금형소 몫이다. 인증도 마찬가지다. 기술 파일이든 신청서든 서류는 내가 다 쓴다. 하지만 시험소에서 하는 물리 시험만큼은 내가 대신 못 한다.

여기서 패턴이 보였다. 파일은 나를 문 앞까지 데려다준다. 그런데 그 문지방을 넘는 건 늘 셋 중 하나였다. 물리 측정(랩 장비 앞의 실측), 구매(보험 증권을 사거나 부품 물량을 확보하는 일), 그리고 라이선스 있는 사람의 판단(변리사한테 받는 특허 자문 같은). 에이전트는 그 문 앞까지 서류를 다 쌓아준다. 문은 못 연다.

‘내 손 안’에 붙는 별표 두 개

다 세어보니 코드는 열둘, 파일로 끝나는 자리는 스물이었다. 나머지 여덟은 개발과 무관한데 파일이라 내 손에 있었다. 여섯은 문 앞까지, 둘은 아예 바깥이었다. 스물여덟 개를 이렇게 갈랐다.

In-house · 20 (파일로 끝남): 펌웨어, PCB, 전력·배터리, 기구 CAD, 온디바이스 ML, 모바일 앱, iOS, 백엔드, 웹·랜딩, 보안, PM, UX/UI, 마케팅, 신호 무결성 벤치, 센서 브링업, 데이터 수집, QA·신뢰성, 프로그램 관리, 기획·전략, 수요 검증

Doorway · 6 (설계는 나, 마지막 한 걸음만 외부): RF·안테나, 금형·툴링, 입고검사, 인증, 사업·법무, 재무·공급망

Human · 2 (끝내 사람): 산업디자인, 도메인 전문가

그런데 “내 손 안”에는 별표가 두 개 붙는다. 파일로 끝나는 일도 시간이 들고 조건이 붙는다.

첫 번째 별표는 물리다. 위 스물 중 여섯 개(신호 무결성 벤치, 센서 브링업, QA·신뢰성 같은)는 손을 대려면 실물 보드가 먼저 있어야 한다. 파일로 아무리 준비해도, 값싼 fab 한 번을 돌려 보드가 손에 오기 전엔 실행이 0이다. 특히 신호 벤치는 내 첫 kill 게이트다. 여기서 신호가 깨끗하게 안 나오면 제품은 거기서 끝난다. 에이전트는 여기 못 앉는다. 그걸 문서가 아니라 막혀본 경험으로 안다.

두 번째 별표는 순서다. 바깥으로 나가는 현금(랩 견적, 금형, 보험 같은)은 전부 수요 게이트를 통과한 다음에만 쓴다. 설계는 지금 파일로 끝내두되, 지갑은 “이거 진짜 사는 사람 있나”가 확인된 뒤에 연다. 지난 글에서 “거꾸로 만들었다”고 자백했는데, 그 반성이 여기선 규칙이 됐다.

그래서 “스무 개가 내 손 안”이라는 말은 반만 맞다. 바깥 사람이 안 붙는다는 얘기다. 그게 다다. 그중 여섯은 보드가 나오기를, 스무 개 전부는 검증이 끝나기를 기다린다.

끝내 사람이 앉는 두 자리

완전히 바깥인 둘은 산업디자인과 도메인 전문가다. 왜 하필 이 둘일까. 둘 다 산출물이 끝내 파일로 안 떨어져서다.

산업디자인부터. 에이전트한테 STL이든 렌더든 뽑으라면 뽑는다. 그건 파일이다. 그런데 산업디자인의 진짜 값어치는 손에 쥐었을 때 나온다. 감촉, 무게가 실리는 균형, 눈에 걸리는 선. 이건 도면 위 숫자로는 안 잡힌다. “이게 좋은 폼이다”라고 말하는 건 결국 훈련된 사람 눈이다. 파일은 폼의 그림자까지만 담는다.

도메인 전문가는 조금 다르다. 그 사람이 파는 건 신뢰다. 지식은 문서로 옮겨 적으면 되고, 그건 파일이다. 하지만 그 사람 이름이 제품에 붙어야 사람들이 믿는다는 것, 그 이름값은 백 장을 써도 안 옮겨진다. 신뢰는 파일에 안 담긴다.

흔히들 AI가 코딩부터 대체한다고 본다. 내 경험도 그랬다. 코딩이 제일 먼저 넘어갔다. 파일이라서. 정작 끝까지 사람 손에 남은 건 폼을 보는 눈과 사람 이름값이었다. 회사에서 제일 방어가 되는 자리가 하필 거기였다.

요즘은 새 규율이 생기면 파일로 떨어지는 일인지부터 본다. 그러면 하네스한테 던져두고 잊는다. 안 떨어지면 그때부터 내 일이다. 물리 행위, 구매, 사람의 신뢰.

스물여섯 자리는 하네스에 넘어갔다. 남은 두 자리는 비어 있고, 요즘 내 시간과 돈은 거기로만 간다. 맞는 산업디자이너를 찾고, 이름값을 빌려줄 사람을 찾는 일. 그 찾기가, 하네스가 시간을 벌어준 덕에 지금 내가 하는 일이다.