# Tokenomics: 에이전트형 소프트웨어 엔지니어링에서 토큰이 어디에 사용되는지 정량화 > Clean Markdown view of GeekNews topic #30294. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30294](https://news.hada.io/topic?id=30294) - GeekNews Markdown: [https://news.hada.io/topic/30294.md](https://news.hada.io/topic/30294.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-09T07:35:02+09:00 - Updated: 2026-06-09T07:35:02+09:00 - Original source: [arxiv.org](https://arxiv.org/abs/2601.14470) - Points: 1 - Comments: 1 ## Topic Body - LLM 기반 다중 에이전트 소프트웨어 개발 시스템의 실행 추적을 SDLC 단계에 매핑해, 토큰 소비가 초기 생성보다 **코드 리뷰**와 검증에 집중되는 구조를 측정한 연구 - ChatDev가 수행한 30개 소프트웨어 개발 태스크에서 코드 리뷰 단계가 평균 **59.4%** 의 토큰을 사용하며 최대 소비 구간으로 확인 - 전체 태스크 평균 토큰 구성은 입력 53.9%, 출력 24.4%, 추론 21.6%로, 에이전트 간 반복적 맥락 전달이 큰 **communication tax**를 형성 - 코딩 단계는 출력 토큰 비중이 58.0%로 높은 반면, 문서화 단계는 입력 토큰 비중이 80.2%로 높아 개발 단계별 토큰 사용 패턴이 뚜렷하게 구분 - 비용 예측과 워크플로 최적화를 위해 더 토큰 효율적인 에이전트 협업 프로토콜과 표준화된 평가 프레임워크가 필요한 결론 --- ### 초록 - LLM 기반 다중 에이전트(LLM-MA) 시스템은 요구사항 엔지니어링, 코드 생성, 테스트 같은 복잡한 소프트웨어 엔지니어링 작업 자동화에 점점 더 많이 적용 중 - 운영 효율과 자원 소비가 충분히 이해되지 않아 예측하기 어려운 비용과 환경 영향이 실제 도입을 가로막는 요인 - ChatDev 프레임워크가 GPT-5 reasoning model로 수행한 30개 소프트웨어 개발 태스크의 실행 추적을 분석하고, 내부 단계를 설계, 코딩, 코드 완성, 코드 리뷰, 테스트, 문서화로 매핑 - 예비 결과에서 반복적 코드 리뷰 단계가 평균 59.4%의 토큰을 차지하며 최대 소비 구간 - 입력 토큰은 평균 53.9%로 가장 큰 비중을 꾸준히 차지하며, 에이전트 협업에서 상당한 비효율 가능성을 보여주는 실증 근거 - 에이전트형 소프트웨어 엔지니어링의 주요 비용은 초기 코드 생성이 아니라 자동화된 개선과 검증 과정에 집중 - 방법론은 비용 예측, 워크플로 최적화, 더 토큰 효율적인 에이전트 협업 프로토콜 연구에 활용 가능 ### 서론 - 대규모 소프트웨어 엔지니어링은 SDLC 전반의 복잡한 작업 자동화를 위해 LLM 기반 다중 에이전트 시스템을 탐색 중 - LLM-MA 프레임워크는 제품 관리자, 아키텍트, 개발자, 테스터 같은 인간 팀 역할을 전문화된 LLM 에이전트로 시뮬레이션하며, 설계·코딩·검증 작업을 협업 방식으로 수행 - LLM-MA 시스템은 원칙적으로 작업을 에이전트 사이에 나누어 자율성과 견고성을 높일 수 있음 - 선행 연구는 LLM-MA 시스템이 발산적 사고를 촉진하고, 추론과 사실성을 강화하며, 단일 에이전트 역량을 넘어서는 문제로 확장될 수 있다고 다룸 - 소프트웨어 엔지니어링에서는 요구사항부터 테스트까지의 엔드투엔드 워크플로를 통합 방식으로 자동화할 수 있다는 가능성 - AGENTTAXO 프레임워크는 일반 LLM-MA 시스템의 토큰 분포를 분석하기 위한 분류 체계를 제공하고, 에이전트 간 상호작용 오버헤드를 설명하는 “communication tax” 개념을 도입 - MAST 실패 분류는 LLM-MA 시스템의 많은 문제가 개별 LLM 한계보다 단계 반복, 불완전한 검증 같은 시스템 설계와 조정 문제에서 비롯됨을 확인 - 기존 연구는 일반 맥락의 에이전트 행동을 분석했지만, 다단계 소프트웨어 엔지니어링 워크플로에 적용된 시스템의 자원 효율에 관한 지식 공백 존재 - “토큰이 어디로 가는가”라는 실용 도입의 핵심 질문은 소프트웨어 엔지니어링 영역에서 아직 답변 부족 - Tokenomics는 LLM-MA 시스템의 운영 효율과 자원 소비를 연구하는 용어 - 분석은 ChatDev의 내부 단계를 개발 단계로 매핑해 토큰 소비 분포를 살펴보는 방식 - ChatDev는 가상 소프트웨어 회사를 시뮬레이션하며, 프로그래머와 테스터 같은 여러 에이전트 역할이 다중 턴 대화를 통해 SDLC를 완료 - 30개 실행 추적의 큐레이션 데이터셋과 [완전한 복제 패키지](https://zenodo.org/records/17430187) 제공 ### 연구 설계 - ## 목표와 분석 대상 - 목표는 LLM-MA 시스템이 엔드투엔드 소프트웨어 개발 작업을 수행할 때 토큰 소비가 어떻게 분포하는지 실증적으로 조사하는 것 - 초기 분석 대상은 ChatDev - ChatDev의 “chat chain” 아키텍처는 설계 → 코딩 → 테스트의 명확한 순차적 폭포수 모델을 나타내며, 단계가 뚜렷해 소프트웨어 개발 단계 매핑에 적합 - ChatDev는 인기 있고 많이 인용된 오픈소스 프레임워크 중 하나 - ## 데이터셋 큐레이션 - ChatDev를 30개의 서로 다른 소프트웨어 개발 태스크에 실행 - 프롬프트는 MAST 연구에서 사용한 ProgramDev Dataset에서 수집 - 선택된 프롬프트는 피보나치 수 생성 같은 단순 알고리듬부터 체스 게임 같은 더 복잡한 애플리케이션까지 포함 - 추론 토큰 수가 태스크 복잡도의 대리 지표가 될 수 있다는 최근 연구를 기반으로 다양성 확인 - 30개 태스크의 추론 토큰 소비 범위는 17,280개에서 40,000개까지이며, 이 범위는 연구에 충분한 태스크 복잡도 다양성을 시사 - ## 모델 선택 - 모든 에이전트의 기반 모델은 GPT-5 reasoning model - 선택 기준은 모델의 인기와 최신성, 에이전트형 사용 사례 적합성, 자율 에이전트 기대에 부합하는 강한 추론 능력 - 실험에 사용한 모델 버전은 `gpt-5-2025-08-07` - `temperature` 파라미터는 이 모델에서 지원되지 않아 기본값 `1.0` 사용 - 컨텍스트 창은 400,000 토큰, 최대 출력 토큰은 128,000 토큰 - 지식 컷오프는 2024년 9월 30일 - ## 분석 파이프라인 - 추적 수집 단계에서는 ChatDev를 계측해 30개 태스크 각각의 전체 실행 추적을 로그로 기록 - 각 LLM 호출의 프롬프트, 응답, 입력·출력·추론 토큰 수 포착 - 단계 매핑은 ChatDev의 프레임워크 내부 단계를 보편적 개발 단계로 바꾸는 핵심 방법론 - 이 추상화는 일반화 가능한 분석을 가능하게 하며, 다른 소프트웨어 엔지니어링 LLM-MA 프레임워크로 확장 가능 - 토큰 집계는 Python 스크립트로 수행 - 수집한 추적을 파싱하고, 30회 실행 전체에서 개발 단계별 토큰 수를 합산 - 입력, 출력, 추론 토큰으로 세분화 - ## ChatDev 내부 단계와 개발 단계 매핑 - 설계 단계는 `DemandAnalysis`, `LanguageChoose`에 대응하며, 요구사항 이해와 상위 수준 기술 결정에 집중 - 코딩 단계는 `Coding`에 대응하며, 초기 소스 코드 작성에 직접 관여 - 코드 완성 단계는 `CodeComplete`에 대응하며, 코딩 단계에서 남은 플레이스홀더나 미완성 코드 파일을 완성 - 코드 리뷰 단계는 `CodeReview`에 대응하며, 프로그래머 에이전트와 코드 리뷰어 에이전트의 반복 대화로 코드 검토와 수정·개선 수행 - 테스트 단계는 `Test`에 대응하며, 실행 가능성 버그를 찾고 수정하기 위한 동적 시스템 테스트에 집중 - 문서화 단계는 `EnvironmentDoc`, `Reflection`, `Manual`에 대응하며, 사용자 매뉴얼과 필요한 환경 의존성 문서 생성 ### 연구 결과와 논의 - ## 연구 질문 - 핵심 질문은 소프트웨어 개발 태스크에서 LLM-MA 시스템의 토큰 소비 패턴 - 에이전트형 소프트웨어 엔지니어링 시스템의 tokenomics 이해는 실용적이고 지속 가능한 도입에 중요 - 높은 토큰 사용량은 재무 비용, 에너지 소비, 환경 영향 증가로 직접 연결 - SDLC 안에서 토큰이 소비되는 위치를 식별하면 비용 예측과 워크플로 최적화에 활용할 수 있는 “비용 지도” 생성 가능 - 분석은 두 축으로 진행 - 설계, 코딩 등 매핑된 개발 단계별 총 토큰 분포 - 각 단계 안의 입력, 출력, 추론 토큰 비율 - ## 발견 1: 코드 리뷰 단계가 토큰 소비를 지배 - 개발 과정 전반의 토큰 사용은 매우 불균등한 분포 - 코드 리뷰 단계는 30개 태스크 전체 평균 59.4%의 토큰을 사용하며 최대 소비 구간 - 코드 완성 단계는 30개 중 6개 태스크에서 발생했고, 해당 실행에서 평균 26.8%의 토큰을 소비 - 문서화 단계는 평균 20.1%, 테스트 단계는 평균 10.3%의 토큰을 소비 - 테스트 단계는 30개 중 12개 태스크에서 발생 - 초기 코딩은 평균 8.6%, 설계는 평균 2.4%로 상대적으로 낮은 비용 - 에이전트형 소프트웨어 엔지니어링의 주요 비용은 초기 코드 생성보다 반복적이고 대화적인 개선·검증 과정에 집중 - 그림의 `n` 값은 30개 태스크 중 특정 단계가 실행된 태스크 수 - 모든 단계가 항상 실행되지는 않으며, 다중 에이전트 시스템 안의 에이전트가 어떤 단계를 실행할지 자율적으로 결정 - 오차 막대는 ±1 표준편차로, 각 단계의 토큰 소비 변동성을 표시 - ## 발견 2: 토큰 소비는 입력 토큰 중심 - 코딩 단계를 제외한 모든 단계에서 입력 토큰이 출력 및 추론 토큰을 크게 초과하는 패턴 - 태스크별 전체 평균 토큰 사용 구성은 입력 53.9%, 출력 24.4%, 추론 21.6% - 입력 토큰과 출력 토큰의 약 2:1 비율은 선행 연구의 “communication tax”에 대한 강한 실증 근거 - 에이전트가 협업 대화 중 큰 컨텍스트를 반복적으로 전달하며 토큰을 사용 - 현재 에이전트 협업 프로토콜에서는 새로운 출력 생성보다 맥락 전달에 토큰 대부분을 쓰는 비효율 존재 - communication tax는 대화형 다중 에이전트 아키텍처의 고유 특성일 수 있으며, 향후 추가 연구 대상 - ## 발견 3: 개발 단계별 tokenomic profile 차이 - 단계별 토큰 비율은 소프트웨어 엔지니어링 활동마다 고유한 패턴을 형성 - 코딩 단계는 출력 중심의 예외 구간으로, 출력 58.0%, 입력 6.9% - 코딩 단계의 출력 중심 구조는 간결한 설계 명세에서 장문의 소스 코드를 생성하는 작업 특성과 일치 - 코드 리뷰와 문서화 같은 검증·문서화 단계는 입력 중심 - 코드 리뷰 입력 비중 51.4% - 문서화 입력 비중 80.2% - 해당 단계들은 기존 코드를 큰 컨텍스트로 소비하고, 더 작은 분석적 출력을 생성 - 단계별 토큰 프로필은 엔지니어링 활동별 비용 지도로 활용 가능 - 실무자는 비용 예측과 프로세스 최적화 기회를 더 잘 식별 가능 - ## 단계별 토큰 비율 - 설계 단계 평균 비율은 입력 60.4%, 출력 3.6%, 추론 36.0% - 코딩 단계 평균 비율은 입력 6.9%, 출력 58.0%, 추론 35.1% - 코드 완성 단계 평균 비율은 입력 47.7%, 출력 41.7%, 추론 10.5% - 코드 리뷰 단계 평균 비율은 입력 51.4%, 출력 24.7%, 추론 23.9% - 테스트 단계 평균 비율은 입력 60.8%, 출력 20.7%, 추론 18.4% - 문서화 단계 평균 비율은 입력 80.2%, 출력 8.3%, 추론 11.5% - 태스크별 전체 평균 비율은 입력 53.9%, 출력 24.4%, 추론 21.6% - ## 논의 - 예비 결과는 에이전트형 소프트웨어 개발의 초기 비용 지도를 제공 - 코드 리뷰 단계의 큰 토큰 비용은 “대화 비용”으로 해석 가능 - 이 비용은 에이전트가 전체 코드 컨텍스트를 반복적으로 주고받으며 코드를 개선하는 LLM-MA 시스템의 대화형 아키텍처에서 직접 발생 - 현재 검증용 에이전트 협업 프로토콜은 작은 수정이 필요한 작업에도 방대한 자원을 소비할 수 있어 매우 비효율적 - MAST 분류의 검증 실패와 단계 반복 관련 결과와도 정렬 - 높은 토큰 사용량은 에이전트 시스템이 내재된 조정 문제를 강행식 대화로 극복하려는 증상일 수 있음 - 실무자는 에이전트 기반 프로젝트 비용을 필요한 작업 유형에 따라 추정 가능 - 초기 코딩 비중이 큰 그린필드 프로젝트와 기존 코드 리팩터링·디버깅 중심 프로젝트는 다른 비용 구조 - 기존 코드 리팩터링·디버깅 중심 프로젝트는 비싸고 입력 중심인 코드 리뷰 사이클이 비용을 지배 - 코드 리뷰 단계 전에 “human-in-the-loop” 체크포인트를 통합하면 비용이 큰 반복 루프를 막고 경제적·계산 효율을 높이는 설계 결정에 활용 가능 - 연구 과제는 검증과 개선을 위한 더 토큰 효율적인 협업 프로토콜 설계 - 단순한 전체 컨텍스트 전달을 넘어서는 방식 필요 - 표준화되고 포괄적인 평가 프레임워크 필요 - 이 프레임워크는 ChatDev의 계층적 대화형 워크플로와 MetaGPT의 SOP 기반 조립 라인 같은 서로 다른 LLM-MA 아키텍처의 효율을 벤치마크하고 비교하는 공통 기반 역할 가능 - 프레임워크별 동작을 보편적 소프트웨어 엔지니어링 활동으로 번역하는 “Rosetta Stone” 역할 가능 ### 타당성 위협과 향후 과제 - ## 타당성 위협 - 분석은 단일 LLM-MA 시스템인 ChatDev와 단일 LLM인 GPT-5 Reasoning Model에 기반 - 관찰된 토큰 소비 패턴은 다른 LLM-MA 아키텍처나 토큰 효율이 다른 LLM에서 달라질 수 있음 - 30개 소프트웨어 개발 태스크는 다양하지만 가능한 모든 소프트웨어 개발 시나리오와 복잡도를 대표하지 못할 수 있음 - 큐레이션 데이터셋 규모는 소프트웨어 엔지니어링 특화 에이전트 추적의 공개 대규모 벤치마크 부족에서 직접 발생 - 데이터 큐레이션은 시간과 비용이 많이 드는 과정 - 일부 개발 단계는 30개 태스크 중 작은 하위 집합에서만 실행 - 코드 완성은 `n=6`, 테스트는 `n=12`로 드물게 트리거 - 이 특정 단계들의 tokenomic profile 결론은 작은 표본에 기반하므로 대표성이 낮을 수 있고 일반화 가능성 제한 - ChatDev 내부 단계를 소프트웨어 개발 단계로 매핑한 방식은 추상화 - 표준화된 평가 프레임워크를 만들기 위한 논리적이고 유용한 매핑이지만, 에이전트 활동을 매핑하는 여러 가능한 방식 중 하나 - ## 결론과 향후 과제 - 에이전트형 소프트웨어 엔지니어링에서 토큰 비용은 균등하게 분포하지 않고, 반복적이고 대화적인 코드 리뷰 단계에 압도적으로 집중 - “communication tax”를 구성하는 입력 토큰이 전체 토큰 사용의 대부분을 차지하며, 향후 최적화의 핵심 영역 - 향후 작업의 첫 번째 과제는 더 많은 태스크로 데이터셋을 확장해 일반화 가능성 개선 - 두 번째 과제는 다른 LLM으로 분석을 확장해 모델별 효과 파악 - 세 번째 과제는 다른 LLM-MA 시스템으로 분석을 확장해 아키텍처 차이가 tokenomics에 미치는 영향 비교 - 네 번째 과제는 토큰 소비 패턴과 실패 모드 사이의 관계 조사 - 다섯 번째 과제는 소프트웨어 엔지니어링 에이전트 효율 벤치마킹을 위한 견고하고 보편적인 개발 단계 매핑 프레임워크의 추가 개발과 검증 ## Comments ### Comment 59221 - Author: neo - Created: 2026-06-09T07:35:04+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48430923) - 개인용으로 **다중 에이전트 시스템**을 만들어 쓰고 있음 문제를 주면 먼저 빠르고 저렴한 모델이 질문을 던지고, 그 답을 바탕으로 입력 프롬프트를 다듬음 이후 문제를 섹션별로 나누고 최종 심판이 결론을 내리거나, 여러 에이전트가 토론한 뒤 심판이 요약하는 식의 전략을 고름 가장 좋은 방식은 내가 **all angles**라고 부르는 것으로, 여러 전략을 병렬로 돌리고 최종 메타 심판이 응답을 종합함 최근 추가한 기능 중 가장 유용한 부분은 각 전략 사이의 편차를 볼 수 있는 화면임 주거지 탐색, 학교, 가족 문제 같은 생활 이슈에 쓰고 있음 - 만든 것의 영상 데모는 여기 있음: [https://streamable.com/e49cgt]() - 비용을 언급했는데, 문제 유형별 **대략적인 비용 구조**를 더 설명해 줄 수 있는지 궁금함 어떤 전략을 쓰는지, 전략별 비용이 어떻게 달라지는지도 알고 싶음 - 어떤 **실행 하네스**를 쓰는지, 그리고 어떤 LLM을 쓰는지 궁금함 - 나도 비슷한 시스템을 만들었지만 프롬프트의 탐색적 개선보다는 **피드백 루프**에 더 초점을 맞췄음 사이버네틱스식으로, 결정적 검사와 자동 수정 라이브러리를 계속 키워 프롬프트 출력의 안정성을 유지하는 방식임 그 라이브러리로 처리되지 않는 “문제”는 프로세스를 운전하는 사람에게 드러나게 함 - 한 달은 **GitHub Copilot**을 끊김 없이 충분히 썼는데, 가격 변경 뒤 다음 달에는 이틀 만에 토큰을 다 써버렸음 이런 급격한 변화는 토큰 가격이 임의적이고, AI 사업이 빠르게 돈이 떨어지고 있다는 신호처럼 보임 - 오히려 최대 기업가치나 **IPO**를 밀어붙인 결과에 가깝다고 봄 추론 수익률이 70%를 넘는다는 소문도 있음 SpaceX를 예로 들면 지난 6개월 동안 소비자 제품 가격을 전반적으로 올렸지만, Alphabet과 Anthropic이 합쳐 매달 20억 달러 이상을 내고 있으니 돈이 부족한 건 아님 Microsoft/GitHub는 남의 제품을 다시 포장하던 입장이라 여기서 손해를 본 셈임 - GitHub 사례는 최근 **가격 정책 변경**이 있었기 때문에 유독 급격하게 보이는 예외에 가까움 일반적으로 가격은 여러 기반 요인에 따라 정해지며, 그 자체가 임의적이라는 뜻은 아님 예컨대 GitHub 임원들이 난수 생성기로 토큰 가격을 정했다면 그게 임의적인 가격 책정임 - “입력 토큰이 평균 53.9%로 소비의 가장 큰 비중을 차지한다”는 부분이 있는데, 내 사용량에서는 비율이 대략 **10:1** 정도임 소비되는 토큰의 압도적 다수가 입력 쪽이고, 에이전트가 코드 한 줄을 고치려고 백만 토큰을 읽는 일이 자주 있음 1:1에 가깝거나 출력 쪽이 더 크다면 에이전트에 문제가 있거나 코드베이스가 새롭거나 비어 있는 경우라고 봄 - 에이전트가 코드베이스를 탐색하고 문서화하기 쉽게 **AST**, 언어 서버 같은 더 나은 도구를 제공해 봤는지 궁금함 캐시되지 않은 백만 토큰은 꽤 많아 보임 - 입력 토큰이 그 정도로 비용을 지배한다면, **캐싱**을 더 잘 활용하는 것만으로도 큰 개선이 가능하다는 뜻임 모델에게 관련 코드 부분을 덤프한 1회성 “압축” 단계를 시키고, 그 결과를 많은 하위 에이전트 호출의 캐시된 접두부로 쓰는 식이 가능함 - 코딩에 에이전트를 써보면 **단위 테스트**는 수천 개씩 쓰고 싶어 하지만, 동적으로 테스트하려는 성향은 약함 - 의미적으로 망가진 테스트를 작성하고 디버깅하느라 **토큰을 엄청 태우는** 것도 좋아함 - 단위 테스트도 동적 테스트의 한 종류임 정적 테스트는 린트나 타입 검사 같은 것임 단위 테스트 말고 다른 종류의 동적 테스트를 원한다면, 계획이나 PRD 단계에서 요구사항으로 명시해 봤는지 궁금함 - AWS도 단순한 요구사항에 대해 과금 가능한 AWS 서비스를 최대한 많이 엮는 복잡한 **Lambda** 해법을 강하게 밀어붙임 그들의 이해관계가 항상 당신의 이해관계와 일치하지는 않음 이 경우에는 쓸모없는 작업에 불필요하게 돈을 쓰게 만들고 싶어 하는 것임 “토큰”이라는 완곡어법도 이제 그만 쓰는 편이 좋겠음 - 더 많은 동적 테스트를 하라고 지시하면 됨 동적 테스트가 어느 정도 꺼려지는 이유는 속도를 늦추고, 예상하지 못한 곳에서 소프트웨어를 멈출 수 있기 때문이라고 봄 - 작년에 **토큰 사용 효율**을 최적화하려고 예산 안내 정보를 제공하던 논문이 떠올랐음 [1] [https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...]() - 이건 항공사 보상 마일리지와 비슷하고, 기업 입장에서는 **베어메탈 GPU 시간**을 빌리는 것보다 이점이 없음 - 더 많은 하드웨어 회사에서 저렴한 **NPU**가 나오고, 모델 크기도 더 최적화되면 이 끔찍한 시기가 곧 끝나길 바람 대부분의 AI 수요가 온프레미스나 온디바이스 하드웨어와 모델로 충족될 수 있게 되면, 그런 운영 비용을 들이는 초대형 연산 농장과 모델이 무엇에 유용할지 궁금함 아마 남는 고객은 대형 정부뿐일 테고, 결국 AI 카르텔이 투자한 수십억 달러를 납세자가 내게 될 것임 - 12월에 이 주제로 **Substack 글**을 썼음: [https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...]() - 예전에는 Google 같은 회사들이 인프라를 얼마나 잘 최적화할 수 있는지를 보고 엔지니어를 뽑았음 곧 회사들이 엔지니어의 **AI 토큰 효율 최적화** 능력을 보게 될지도 모름 - 그건 토큰이 계속 의미 있는 비용으로 남는다는 가정이 필요함 개발자들이 더 많은 토큰을 쓸 용도를 찾아내는 속도가 가격 하락 속도만큼 빠를지는 확신하기 어려움 - 회사의 토큰 비용을 0으로 낮추는 방법을 알고 있음 토큰을 인터넷처럼 **유틸리티 비용**으로 취급하고 엔지니어가 직접 내게 하면 됨 - 재미있는 곁가지로, 새 제품 후보를 검토하는 회의에 있었는데 잘 진행되다가 그 제품에 AI를 추가했다는 화면이 나왔음 당연히 AI가 붙어 있었고, 매우 억지로 끼워 넣은 티가 났음 그 티가 난 부분 중 하나는 각 질의에 몇 토큰이 들었는지를 보여주는 열이 있었다는 점임 토큰 비용은 누가 내냐고 물었더니 라이선스에 포함된다고 했고, 예산 한도가 있는지 아니면 무제한인지 물었더니 좋은 질문이라며 확인해 보겠다고 했음 내가 물은 이유는 방금 보인 단순한 장치 관련 질의 하나가 **25만 토큰**을 태웠기 때문임 그때 상대 측 임원 중 한 명이 “우리가 이걸 고객에게 왜 보여주고 있지?”라고 큰소리로 말하는 게 들렸고, 우리는 꽤 웃었음 여기서 배운 점은 무엇에든 AI를 추가하는 비용이 제대로 계산되지 않고 있으며, 실제 AI 운영의 진짜 비용은 더더욱 반영되지 않는다는 것임 원하지 않더라도 AI가 붙은 모든 것은 더 비싸질 것임 - AIshittification - **Tokenomics**는 이미 암호화폐 경제를 설명하는 단어인데, AI에서 쓰는 토큰이 다른 종류라고 해도 왜 굳이 그 단어를 재정의하려는지 모르겠음 - Tokenomics는 대마초 애호가들 사이에서도 오래전부터 쓰이던 말임 - 새로운 유행임 예전 유행은 잊고, 이것도 곧 낡을 테니 너무 늦기 전에 올라타야 함 - cryptocurrency economics = cryptonomics - “Crypto”도 암호화폐가 자기들 것으로 만들기 전부터 있던 말임 “Web 3.0”도 암호화폐 사람들이 Web3를 암호화폐 중심으로 만들기 전부터 존재했음 그래서 뭐가 문제인지 모르겠음 용어는 서로 다른 맥락에서 계속 재사용됨 게다가 대부분은 이미 암호화폐에서 넘어갔으니, 혼란이 생길 가능성도 크지 않음