지금 코드를 쓰는 비용은 거의 0 에 가깝습니다. 원하는 걸 설명하면 나옵니다. 문제는 시스템이 코드로만 이루어져 있지 않다는 점입니다.
시스템을 실제로 구성하는 건 경계입니다. 어디까지가 한 덩어리인지, 상태를 누가 들고 있는지, 프로세스가 죽었을 때 무엇이 남는지, 같은 작업이 두 번 실행되면 어떻게 되는지. 이런 건 코드를 짜기 전에 정해지는 것이고, 잘못 정해두면 그 위에 아무리 좋은 코드를 얹어도 계속 새어 나옵니다.
AI 는 이 결정을 대신 해주지 않습니다. 물어보면 답은 나옵니다. 그런데 그건 답이 아니라 선택지 나열입니다. AI 는 시스템 전체를 동시에 붙들고 있지 않고, 결과를 짊어지지도 않기 때문입니다. 판단은 결국 이쪽에 남습니다.
그래서 실제로 갈리는 지점은 이런 질문들입니다.
- 이 작업을 지금 처리할 것인가, 큐에 넣을 것인가.
- 이 값을 매번 가져올 것인가, 캐시할 것인가.
- 캐시한다면 언제 틀려도 되는가.
- 재시작했을 때 어디서부터 다시 시작하는가.
- 두 개가 동시에 같은 걸 건드리면 누가 이기는가.
전부 코딩 문제가 아니라 설계 문제입니다. AI 에게 물어봐도 되지만, 답을 고르는 건 본인입니다. 그리고 이 감각은 문서로 안 생깁니다. 한 번 잘못 골라서 데이터가 꼬여본 사람만 다음에 다르게 고릅니다.
보안도 별도의 층이 아니라 이 설계의 부산물입니다.
에이전트가 Shell 을 쥐고 키를 읽고 지갑을 만지기 시작하면 사고 단위가 달라지는 건 맞습니다. 다만 그때 필요한 건 거창한 보안 스택이 아니라 경계를 좁히는 일입니다.
1. 출금 권한을 아예 빼둔 키
2. 봇용과 개인용을 섞지 않은 계정
3. 최악의 경우 잃어도 되는 범위 안에서만 돌아가는 구조
이 세 가지가 나머지 전부를 합친 것보다 큽니다. 나머지는 규모가 커진 다음의 이야기입니다.
정리하면, AI 는 복잡성을 없앤 게 아니라 시작점 뒤로 밀어놨습니다. 그런데 밀린 자리에 있는 건 지식이 아니라 판단입니다. 알고 모르고의 문제가 아니라, 골라보고 틀려본 횟수의 문제입니다.
몇 년 뒤 차이가 나는 곳도 여기일 겁니다. 프롬프트는 누구나 씁니다. 차이는 그 사람이 얼마나 많은 구조를 직접 망가뜨려봤는지에서 납니다. 그러니 지금 할 일은 공부를 끝내는 게 아니라, 감당 가능한 크기로 하나 만들어서 빨리 깨뜨려보는 쪽입니다.