글

OpenAI Revenue Concerns: What $50B vs. $70B Really Means

OpenAI’s reported $50 billion and $70 billion figures do not describe the same thing. The first was a reported annualized revenue pace at the end of September; the second was a reported outlook for the annualized pace at year-end. Neither is audited full-year revenue, and neither settles the questions that matter for financial durability: recognized revenue, margin, cash collection, and the cost of supplying compute. That distinction also helps with the stock-market story. Premarket sentiment improved after the later outlook report, but the October 9 regular-session closes were mixed: Nvidia ended lower while Microsoft, Oracle, and CoreWeave ended higher. Latest Tech(EN): Amazon’s $1B Data-Center Community Plan: The New Constraint Is Permission to Build 한국어 버전: 한국어 분석 읽기: 오픈AI 매출 우려 완화, 500억·700억 달러는 같은 숫자가 아니다 Key Takeaways Reuters reported, citing an unnamed source, that OpenAI’s September annualized revenue was close to $50 billion. OpenAI did not respond to Reuters’ r...

오픈AI 매출 우려 완화, 500억·700억 달러는 같은 숫자가 아니다

처음엔 오픈AI 매출 숫자가 700억 달러에서 500억 달러로 줄었다는 이야기처럼 보였다. 하지만 500억 달러는 9월 말의 연환산 매출 속도 보도이고, 700억 달러 이상은 연말에 도달할 수 있다는 전망 보도다. 어느 쪽도 2026년 확정 매출이나 이익이 아니다. 그래서 이번 뉴스는 AI 수요가 사라졌는지보다, 서로 다른 매출 산식과 시간대를 한 숫자로 섞어 읽었는지를 먼저 봐야 할 것 같다. 미국 증시도 한 방향으로 움직이지 않았다. 10월 9일 정규장 종가 기준 엔비디아는 내렸고, 마이크로소프트·오라클·코어위브는 올랐다. 최근 Tech(KR) 글: AI 대화가 길면 내 PC 메모리도 늘까? 브라우저와 KV Cache 관련 한글 주식·산업 분석: 메타, 기업용 AI 플랫폼 발표…고객은 움직일까 — AI 서비스의 고객 수요와 사업 연결을 확인하는 관점 English version: Read the independent English analysis: OpenAI Revenue Concerns: What $50B vs. $70B Really Means 핵심 요약 로이터는 익명 관계자를 인용해 오픈AI의 9월 연환산 매출이 약 500억 달러였다고 보도했다. 회사는 논평 요청에 응답하지 않았다. [출처 1] 블룸버그는 익명 관계자를 인용해 오픈AI가 연말 연환산 매출 700억 달러 이상을 예상한다고 보도했다. 이는 전망이지 확정 실적이 아니다. [출처 2] 연환산 매출은 짧은 기간의 매출 속도를 1년으로 환산한 값이다. 실제 12개월 매출 합계, 이익, 현금흐름과 같은 말이 아니다. 10월 9일 미국 정규장에서는 NVDA가 -0.52%였지만 MSFT·ORCL·CRWV는 각각 올랐다. 한 뉴스가 모든 AI 관련주를 같은 방향으로 움직였다고 볼 수 없다. [출처 3] [출처 4] [출처 5] [출처 6] 숫자 두 개를 먼저 분리해 보기 아래 표는 실적 표가 아니다. 같은 회사의 성장을 말하는 듯해도, ...

스페이스X 스타링크 모바일, 800MHz 인수 계약과 통신주 급락을 읽는 법

스페이스X의 스타링크 모바일 계획은 아직 미국 이동통신 서비스를 시작했다는 뜻이 아니다. 핵심은 전국 800MHz 대역의 최대 14MHz 페어드 주파수를 사들이기로 한 계약 이며, 거래 종결에는 FCC 승인과 통상적인 조건이 남아 있다. 그래도 시장은 이 계약을 잠재적 경쟁의 신호로 읽었다. 미국 현지 10월 9일 정규장 원시 종가 기준으로 SPCX는 1.25% 올랐고, TMUS는 13.27% 내렸다. AT&T와 Verizon도 원시 종가 기준으로는 각각 10.82%, 10.14% 낮아졌다. 여기서 중요한 것은 ‘800MHz’와 ‘14MHz’를 섞지 않는 것, 그리고 통신주의 원시 종가 변화와 배당 조정 수치를 한 표에 섞지 않는 것이다. 최근 Tech(KR) 글: AI 대화가 길면 내 PC 메모리도 늘까? 브라우저와 KV Cache 관련 한글 주식·산업 분석: 세미파이브 703억원 AI칩 수주, 확정금액은 얼마일까 — 계약 금액을 확정 실적과 구분해 읽는 기준 핵심 요약 SpaceX와 Grain Management는 800MHz 대역에서 최대 14MHz 페어드 주파수 포트폴리오를 넘기는 definitive agreement를 발표했다. 거래는 아직 FCC 승인과 종결 조건을 기다린다. [출처 1] SpaceX는 이 저대역 주파수를 위성-휴대전화와 지상망을 결합한 Starlink Mobile 계획에 쓰겠다고 설명했다. 이는 회사의 계획 설명이지, 이미 검증된 전국 실내 서비스 결과가 아니다. [출처 2] SpaceX는 2026년 6월부터 NASDAQ에서 SPCX 로 거래되고 있다. EchoStar의 현 티커는 ECHO 다. 오래된 ‘비상장 SpaceX’ 또는 ‘SATS’ 표기는 이 사건에 맞지 않는다. [출처 3] [출처 4] 10월 9일 통신주의 큰 하락은 그날의 원시 종가 변화다. 계약 하나가 향후 가입자·이익 감소를 확정했다는 뜻은 아니다. 지금 확정된 것과 아직 아닌 것 뉴스를 읽을 때는 주파...

AI 대화가 길면 내 PC 메모리도 늘까? 브라우저와 KV Cache

이미지
짧은 답: 보통은 아니다. 클라우드 AI에서 대화가 길어질 때의 KV Cache는 모델을 실행하는 서버 쪽 상태이고, 내 브라우저 탭이 쓰는 메모리는 대화 화면·DOM·JavaScript·첨부물처럼 다른 층의 비용이다. 다만 내 PC에서 로컬 LLM을 돌린다면, 그때는 문맥 길이가 GPU 메모리나 시스템 메모리와 직접 만난다. 탭이 무거워졌다고 해서 서버에서 쓰는 모델 메모리까지 내 PC로 내려온 것은 아니다. 반대로 대화가 길어도 브라우저 탭 메모리만 보고 서비스의 추론 자원 상태를 알 수는 없다. 특정 AI 서비스의 내부 구현은 공개 문서 없이 단정할 수 없다. 여기서는 브라우저에서 보이는 현상과 모델이 실행되는 곳의 상태를 나눠 보려 한다. 이전 Tech(KR) 글: SVN 웹 접속이 안 될 때, URL·인증·권한을 나눠 확인하는 순서 핵심 요약 클라우드 AI: 대화 문맥을 계산하는 모델은 보통 서비스 제공자의 실행 환경에 있다. 그 환경의 KV Cache와 브라우저 탭의 메모리는 같은 숫자가 아니다. 브라우저: 대화 목록·렌더링된 답변·이미지·JavaScript 객체는 탭의 메모리에 영향을 줄 수 있다. Chrome도 OS 메모리와 JavaScript Memory를 구분해 관찰하도록 안내한다. 로컬 LLM: 모델을 내 PC에서 실제로 실행할 때에는 문맥 길이와 생성 상태가 GPU 메모리 또는 시스템 메모리 사용량에 직접 영향을 줄 수 있다. 안전한 판단: 한 화면의 메모리 수치만으로 원인을 결론내지 말고, 먼저 “브라우저 탭인가, 로컬 모델 프로세스인가, 서비스 서버인가”를 나눈다. 자체 제작 도식. 브라우저 탭 메모리와 모델 실행 측 KV Cache는 같은 지표가 아니다. 특정 서비스의 내부 구현을 나타내지 않는다. KV Cache는 ‘대화창 저장 공간’이 아니다 언어 모델은 다음 토큰을 만들 때 앞 문맥을 참조한다. 이때 이미 만든 내부 표현 중 key와 value를 보관해 다음 계산에서 다시 쓰는 ...

SVN 웹 접속이 안 될 때, URL·인증·권한을 나눠 확인하는 순서

이미지
SVN 접속이 막히면 아래 증상부터 고르세요. 설정을 바꾸기 전에 URL → 인증 → 경로 권한 순서로 확인합니다. 접속 안 됨 · 인증 반복·401 · 권한·403 · 주소·404 30초 빠른 진단: 다음 행동 하나만 고르기 접속 자체가 안 됨 확인: 정확한 저장소 URL과 오류 문구. 다음: svn info https://svn.example.com/svn/team-repo 로 읽기 전용 조회. 주의: 예시 URL을 실제 주소로 바꾸고, 비밀번호는 명령에 넣지 않습니다. 인증 창 반복·401 확인: 요청 URL이 사용하는 인증 영역. 다음: 관리자에게 계정·인증 제공자· Require valid-user 설정 확인 요청. 주의: 확인 없이 인증 요구를 끄지 않습니다. 로그인했는데 403 확인: 접근이 막힌 저장소와 하위 경로. 다음: 관리자에게 해당 사용자·그룹의 authz 읽기 규칙 대조 요청. 주의: 전체 익명 접근이나 전체 쓰기 권한을 열지 않습니다. 404 확인: Location 접두어와 저장소 이름. 다음: 관리자에게 확인받은 URL로 svn ls https://svn.example.com/svn/team-repo 조회. 주의: 저장소를 새로 만들기 전에 URL 매핑부터 확인합니다. 두 명령은 공식 문서에서 확인한 조회 예시입니다. 이 글을 준비하며 실제 서버·저장소에 실행하거나 설정을 바꾸지는 않았습니다. 이전 Tech(KR) 글: VirtualBox 화면 크기 자동 조절 안 될 때, Guest Additions부터 VMSVGA까지 도식: 자체 제작 · URL 매핑 → 인증 → 경로 권한 순서로 원인을 분리하는 확인 흐름 상세: URL·인증·권한이 다른 이유 웹 화면 ≠ SVN 접속 확인: mod_dav_svn 은 HTTP 위의 WebDAV/DeltaV 요청을 처리합니다. 브라우저에서 페이지가 열려도 클라이언트의 저장소·경로 접근까...

VirtualBox 화면 크기 자동 조절 안 될 때, Guest Additions부터 VMSVGA까지

창을 넓혔는데 우분투 화면은 그대로이고, 가장자리에는 빈 공간이나 스크롤바만 남는 경우가 있다. 처음에는 모니터 해상도 문제처럼 보이지만, VirtualBox에서는 호스트 창의 크기와 게스트 운영체제의 해상도가 별개의 값이다. 이럴 때는 창을 계속 끌어 보기보다 화면 자동 조절 상태, Guest Additions, 그래픽 컨트롤러를 차례로 확인하는 편이 빠르다. 대상은 VirtualBox 7.2 계열과 Ubuntu 24.04 LTS Desktop 64-bit(amd64) 게스트, x86_64 호스트 다. 실제 VM 테스트 없이 공식 문서로 정리한 점검 순서이며, 아래 진단 명령도 실행하지 않았다. 이전 Tech(KR) 글: 세미파이브·모빌린트 로봇 AI 칩, LPDDR6·UCIe가 양산은 아닌 이유 핵심 요약 Auto-resize Guest Display 는 호스트 창을 키울 때 게스트 해상도도 바꾸는 기능이다. 단순 확대와는 다르다. Oracle 문서상 Windows·Linux·Oracle Solaris 게스트는 Guest Additions가 설치되어 있고 자동 조절을 지원하면 창 크기에 맞춰 게스트 해상도가 바뀐다. Linux 게스트의 기본 그래픽 컨트롤러는 VMSVGA 이고, Windows 7 이후 새 VM의 기본값은 VBoxSVGA 다. 게스트 종류와 맞지 않는 설정부터 의심한다. Scale Factor는 화면을 크게 보이게 할 수 있지만 게스트의 실제 해상도를 바꾸는 진단과는 다르다. Guest Additions와 호스트 VirtualBox의 버전이 다르면 곧바로 고장이라고 단정할 수는 없지만, Oracle은 최선의 결과를 위해 같은 버전을 권장한다. 먼저 구분할 것: 호스트 창, 게스트 해상도, 화면 확대 호스트 는 VirtualBox가 설치되어 VM 창을 띄우는 실제 PC의 운영체제다. 게스트 는 그 창 안에서 실행되는 운영체제다. 창을 키우는 동작은 호스트에서 일어나지만, 글자와 바탕화면의 실제 픽셀...

세미파이브·모빌린트 로봇 AI 칩, LPDDR6·UCIe가 양산은 아닌 이유

이미지
처음엔 LPDDR6와 UCIe라는 단어가 먼저 눈에 들어왔다. 세미파이브가 모빌린트와 로봇용 AI 칩을 개발하는 턴키 계약을 맺었다고 발표했다. 실외처럼 서버 연결이 제한된 환경에서도 센서와 비전 데이터를 현장에서 처리하겠다는 그림이다. 다만 인터페이스 이름이 곧 양산을 뜻하는 건 아니다. 이 계약에서 더 중요한 건 설계가 어디서 시작되고, 어느 단계에서 제품화 검증을 통과하느냐다. 로봇 AI 칩은 서버용 가속기와 달리 전력·열·센서 지연을 한 보드 안에서 동시에 맞춰야 한다. 그래서 이번 소식은 '칩이 나왔다'보다 '개발의 출발선이 어디인가'로 읽는 편이 맞아 보인다. 이전 Tech(KR) 글: AI 랙은 왜 650V GaN을 양면으로 식히나 핵심 요약 세미파이브는 모빌린트와 로봇용 AI 칩을 개발하는 턴키 계약을 체결했다고 10월 1일 발표했다. 발표 기준으로는 고객이 핵심 목표를 제시하고 세미파이브가 상세 설계부터 패키징·테스트·양산 준비까지 맡는 Spec Hand-off 방식이다. LPDDR6, PCIe Gen6, UCIe-S는 통합할 기술 방향으로 언급됐지만, 최종 칩 사양·파운드리·수량·양산 시점은 공개되지 않았다. 따라서 이번 계약은 설계·검증 기회를 보여주지만, 제품 출하나 매출 인식을 확인하려면 테이프아웃·샘플·고객 양산 같은 후속 이정표가 필요하다. 자체 제작 다이어그램. 계약 발표에 나온 기술 방향과 별도의 제품화 검증 단계를 구분해 정리했다. 이 글을 위해 제작한 원본 설명용 다이어그램. 세미파이브의 2026년 10월 1일 발표를 바탕으로 개발 단계와 확인 지점을 정리했으며, 로고·보도사진·제3자 차트는 사용하지 않았다. 무엇이 발표됐나 세미파이브의 10월 1일 발표에 따르면, 모빌린트와의 계약은 산업통상자원부가 주도하는 K-온디바이스 AI 반도체 기술개발 프로그램 안에서 로봇용 AI 칩을 개발하는 프로젝트다. 회사는 농업 로봇처럼 외부 서버 연...