2024년 가을, 엔비디아 H100 서버 한 대를 구성하는 부품 원가를 항목별로 분해한 분석이 반도체 업계 커뮤니티에 조용히 퍼졌습니다. GPU 다이(die) 자체보다 HBM(고대역폭 메모리)이 차지하는 원가 비중이 더 높다는 내용이었습니다. 그리고 올해 초, 비슷한 구조 분석이 다시 한 번 구체적인 수치와 함께 확인됐습니다. AI 칩 한 장 비용의 약 66%, 3분의 2에 해당하는 금액이 연산 회로가 아니라 메모리에서 나온다는 것입니다.

같은 날, 소프트웨어 쪽 개발자 커뮤니티 해커뉴스(Hacker News)에는 121점짜리 글이 올라왔습니다. 제목은 "Claude를 아키텍트로 쓰지 마라"였습니다. 거대 언어모델에 시스템 아키텍처 설계를 맡겼다가 구조적으로 엉킨 코드를 수습하느라 며칠을 허비했다는 경험담이었고, 댓글에는 비슷한 사례가 줄줄이 달렸습니다.

하드웨어 공급망 이야기와 개발자 워크플로 경험담이 같은 날 주목받은 것이 단순한 우연처럼 보일 수도 있습니다. 그런데 두 신호를 나란히 놓고 읽으면, AI 도구를 실무에 끌어들이려는 1인 사업자와 소규모 팀에게 지금 시점에 필요한 판단 기준이 윤곽을 드러냅니다.

AI 칩 원가의 66%가 메모리라는 수치가 뜻하는 것

HBM은 일반 D램과 달리 여러 층의 메모리 칩을 수직으로 쌓고, GPU 다이와 실리콘 인터포저 위에 나란히 올리는 방식으로 제조됩니다. 데이터 이동 속도가 일반 메모리보다 10배 이상 빠른 대신, 공정 난이도와 수율 관리 부담도 그만큼 높습니다. 현재 HBM을 양산할 수 있는 업체는 SK하이닉스, 삼성전자, 마이크론 세 곳뿐이고, 그중 HBM3E 이상 고사양 제품 기준으로 SK하이닉스의 점유율이 50%를 넘습니다.

이 구조에서 삼성전자의 파업 리스크가 주목받는 이유가 생깁니다. 2024년 삼성전자 반도체 부문 노조가 역대 최장 파업을 진행하면서, HBM 수율 개선 일정이 지연될 수 있다는 우려가 업계 내부에서 나왔습니다. 단순히 한 기업의 노사 분쟁이 아니라, 전 세계 AI 인프라 공급망의 실질적인 병목 요인으로 연결되는 구조입니다. 엔비디아가 H100·H200 출하 일정을 조율하는 데 HBM 공급 물량이 직접 변수로 작용하기 때문입니다.

이 수치가 뜻하는 바를 좀 더 구체적으로 살펴보면, AI 모델의 성능 경쟁이 알고리즘 설계만으로 결정되지 않는다는 점입니다. 트랜스포머 구조가 공개된 이후 모델 아키텍처 자체는 오픈소스 형태로 공유됩니다. GPT, Claude, Gemini 모두 트랜스포머 계열이고, 차별화 요소는 학습 데이터 품질과 파인튜닝 방식, 그리고 추론 속도입니다. 추론 속도는 결국 칩 성능에 달려 있고, 칩 성능은 HBM 공급량에 묶여 있습니다. 소프트웨어 레이어에서 아무리 정교한 프롬프트 엔지니어링을 구사해도, 그 아래 실리콘 공급망이 흔들리면 서비스 품질이 달라집니다.

1인 사업자나 소규모 팀 입장에서 이 흐름을 체감하는 순간은 보통 API 요금이 오르거나 응답 속도가 느려질 때입니다. 2023년 초 ChatGPT가 유료 플랜을 도입하면서 무료 사용자 응답 속도를 제한했을 때, 많은 실무자들이 처음으로 AI 인프라 비용 구조를 피부로 느꼈습니다. HBM 공급 제약이 해소되지 않는 한, AI API 사용료의 하락 속도는 기대보다 더딜 가능성이 높습니다.

"아키텍트로 쓰지 마라"는 경고가 커뮤니티에서 121점을 받은 맥락

해커뉴스에서 121점은 적지 않은 수치입니다. 논란이 되는 주제나 강한 의견 불일치를 담은 글에 이만한 점수가 붙는다는 것은, 비슷한 경험을 한 개발자들이 그만큼 많다는 신호입니다.

글의 내용을 정리하면 이렇습니다. Claude나 GPT-4에게 "이 서비스의 전체 백엔드 아키텍처를 설계해줘"라고 요청하면, 그럴듯하게 구성된 다이어그램과 코드 구조가 나옵니다. 문제는 거기서 시작됩니다. 해당 아키텍처가 실제 배포 환경의 제약 조건, 팀의 유지보수 역량, 기존 코드베이스와의 의존성 등을 전혀 반영하지 않는 경우가 많습니다. 이것이 의도치 않게 채택되면, 나중에 디버깅하고 리팩터링하는 데 드는 시간이 처음부터 직접 설계했을 때보다 더 길어집니다.

댓글에서 한 개발자는 "LLM은 아키텍처 의사결정자가 아니라 코드 자동완성 도구에 가깝다"고 썼습니다. 또 다른 댓글은 "문제는 모델이 자신의 답변이 틀렸을 때도 틀렸다는 사실을 모른다는 것"이라고 짚었습니다. 이 두 줄이 논쟁의 핵심을 압축합니다.

같은 날 보도된 챗봇 '퍼소낼리티 해킹' 사례도 이 문맥에서 읽힙니다. 시스템 프롬프트를 교묘하게 구성하면 챗봇이 설정된 역할 경계를 벗어나 응답한다는 내용이었습니다. 즉, AI 에이전트에게 어디까지 권한을 줄 것인가를 두고, 개발자 커뮤니티와 일반 사용자 모두 직접 실험하며 경계선을 탐색하는 단계에 와 있습니다.

Anthropic이 이 시점에 'knowledge-work-plugins'를 공개 오픈소스로 내놓은 것은 이 논의에 대한 응답으로 읽힙니다. AI를 시스템 전체를 통제하는 주체가 아니라, 특정 작업을 보조하는 플러그인 형태로 제한한다는 설계 방향입니다. "Claude는 아키텍트가 아니라 플러그인이어야 한다"는 커뮤니티의 경험적 결론과 방향이 겹칩니다.

실무자들이 AI 에이전트를 쓸 때 역할 범위를 어디까지 허용할 것인가를 둘러싼 논쟁은, 결국 신뢰 경계 설정의 문제입니다. 어느 영역 관련 실무서에서 강조하는 시각과도 닿아 있는데, 새로운 도구나 파트너에게 권한을 줄 때 처음 90일 혹은 초기 단계에서 명확한 역할 범위를 설정하지 않으면, 나중에 수습 비용이 불균형하게 커진다는 논리입니다. AI 에이전트도 다르지 않습니다. 초반에 역할 범위를 구체적으로 제한하지 않으면, 그럴듯하지만 문맥을 이탈한 결과물이 쌓이고, 그것을 되돌리는 데 드는 시간이 처음부터 직접 했을 때보다 길어집니다.

1인 사업자가 지금 당장 점검해야 할 세 가지 구체적 장면

AI API 비용이 앞으로 얼마나 내려갈지 낙관하지 않는 것. HBM 공급 제약은 단기에 해소되기 어렵습니다. 삼성전자의 HBM3E 수율 문제가 2024년 내내 지속됐고, SK하이닉스도 공급 확대를 위한 신규 팹 가동 일정이 2025~2026년에 걸쳐 있습니다. 지금 AI API를 무제한처럼 쓰는 워크플로를 구성했다면, 비용 구조를 한 번 더 확인해 보는 시점입니다. 특히 이미지 생성이나 대용량 문서 처리처럼 토큰 소비가 많은 작업은, 향후 단가 변동에 민감하게 반응할 가능성이 있습니다.

AI에게 '설계'를 맡기는 순간을 의식적으로 구분하는 것. 카피라이팅 초안 생성, 리서치 요약, 반복 문서 작성 자동화처럼 명확하게 한정된 작업에서 AI는 속도를 크게 올려줍니다. 반면 전략 기획, 서비스 구조 설계, 고객 커뮤니케이션 방향 결정처럼 맥락과 판단이 필요한 영역에서 AI의 결과물을 그대로 채택하면, '그럴듯하지만 우리 상황과 맞지 않는 답변'을 따라가는 위험이 생깁니다. "Claude를 아키텍트로 쓰지 마라"는 경고는 개발자만의 이야기가 아닙니다. 사업 전략 수립, 콘텐츠 구조 기획, 가격 정책 설계 모두 같은 경계 안에 있습니다.

AI 도구의 역할 범위를 문서로 한 번 정의해 두는 것. 어떤 작업에 어떤 모델을 쓰고, 결과물의 최종 판단은 누가 하는지 명시합니다. 1인 사업자라면 스스로와의 약속이지만, 이것이 없으면 AI 결과물을 무의식적으로 채택하는 습관이 생깁니다. 예를 들어 "초안 생성은 GPT-4o, 고객사 제안서 최종본은 내가 직접 검토 후 발송"처럼 작동 규칙을 만들어 두면, 역할 경계가 흐려지는 상황을 미리 막을 수 있습니다.

지금 AI 도구를 실무에 쓰는 1인 사업자들이 마주하는 불편함은 대부분 이 지점에서 옵니다. 도구가 훌륭해 보이기 때문에 처음에는 많이 맡겨보게 됩니다. 그런데 어느 순간 "이게 내가 원하던 방향인가"라는 질문을 하게 됩니다. 그 질문이 드는 시점이 늦을수록, 수습 비용도 함께 커집니다.

HBM 공급망이 AI 서비스의 품질과 가격 상한선을 결정하고, 개발자 커뮤니티는 AI 에이전트의 역할 경계를 직접 실험하며 좁혀가고 있습니다. 두 흐름이 교차하는 지금, AI를 어디에 얼마나 깊이 끌어들일지에 대한 판단은 도구 선택의 문제가 아니라 사업 운영 방식의 문제입니다. 도구가 제안한 설계를 따라가다 보면, 어느 순간 내 사업의 방향도 모르게 도구에 맞춰진 채 움직이고 있을 수 있습니다.