GPU가 덧셈 한 번 할 때…

우리가 매일 쓰는 개발 도구는 두꺼운 추상화 위에 서 있다. 그런데 그 층을 한 겹씩 걷어내면 무엇이 남을까? 오늘 GeekNews에서 가장 많이 읽힌 세 글은 공교롭게도 서로 다른 ‘보이지 않는 층’을 파고든다. GPU가 덧셈 한 번을 처리하는 밑바닥, AI 에이전트가 기억을 저장하고 꺼내는 방식, 그리고 구독 매출이 실제로 어디서 나오는가. 표면의 숫자만 보다 놓치기 쉬운 지점을 개발자 관점에서 함께 짚어본다.

GPU가 덧셈 한 번 할 때 벌어지는 일

print 한 줄 뒤에 숨은 948번의 시스템 호출

예제는 두 개의 float 배열을 더해 세 번째 배열에 담는 vadd 커널 하나다. 원소는 n = 1<<20, 즉 1,048,576개이고 실행 구문은 vadd<<<4096, 256>>>, 대상은 RTX 4090(nvcc -arch=sm_89)이다. 결과는 그저 c[0]=2.000000 한 줄이지만, 그 뒤에는 수천만 개의 CPU 명령과 약 948번의 ioctl 호출, 그리고 메모리에 매핑된 doorbell 레지스터가 관여한다.

컴파일부터 남다르다. nvcc는 호스트 코드와 디바이스 코드를 나눠, cicc가 가상 ISA인 PTX를, ptxas가 실제 아키텍처 명령어인 SASS를 만든다. 둘은 cubin과 함께 fatbin으로 묶여 리눅스 실행 파일 안에 들어가고, PTX는 다른 GPU에서 드라이버가 즉석 컴파일할 수 있는 fallback으로 남는다.

실행 요청은 호스트 launch stub이 인자를 정렬해 담고 libcuda.so.1(비공개 드라이버)로 넘긴다. 드라이버는 pushbuffer에 명령을 쓰고 GPFIFO 링이 이를 가리키게 한 뒤 GP_PUT을 전진시키고, 마지막으로 doorbell MMIO 쓰기로 GPU를 깨운다. 이때 넘어가는 QMD(Queue Meta Data)에는 그리드·블록 크기(4096, 256), 스레드당 레지스터 수, 프로그램 시작 주소, 완료 신호 위치가 모두 담긴다.

GPU 안에서는 compute work distributor가 블록을 128개 SM에 분배한다. 블록당 256스레드는 8워프이고 ptxas가 스레드당 16개 레지스터를 예약하지만, SM당 1,536스레드라는 상한 탓에 실제로는 SM당 6블록(48워프)만 상주해 4개 서브파티션에 12워프씩 나뉜다. 한 워프가 메모리를 기다리며 멈추면 스케줄러가 다른 워프로 갈아타 지연을 숨긴다.

Nsight Compute 측정값이 결정적이다. 커널은 10.78μs에 끝나지만 DRAM은 피크의 79.65%(약 780GB/s)까지 올라가는 반면 warp issue는 5.17%에 그친다. float 덧셈 1회에 12바이트를 옮기는 극히 낮은 산술 집약도 때문에, 이 커널은 연산이 아니라 명백히 메모리 대역폭에 묶여 있다.

마이크로소프트가 던진 RAG의 대안, Memora

원문은 그대로 두고, 검색만 따로 인덱싱한다

마이크로소프트가 Memora를 오픈소스(MIT, Python 3.10+)로 공개했다. AI 에이전트가 대화와 문서에서 필요한 정보를 자동으로 추출·저장·검색하도록 돕는 메모리 프레임워크로, ‘무엇을 저장하고 언제 갱신·삭제할지, 중복을 어떻게 정리할지’라는 메모리 생명주기를 프레임워크 내부에서 처리하는 것을 목표로 한다.

문제의식은 일반적인 RAG의 한계다. 원문을 잘게 쪼개면 긴 문맥이 흩어지고, 비슷한 정보가 중복 저장되며, 단순 의미 유사도가 질문 의도와 어긋나고, 요약만 남기면 세부가 사라진다. Memora는 각 기억을 세 요소로 나눠 이를 피한다. Memory value는 원문 전체를 압축 없이 보존하되 검색 인덱스에는 넣지 않고, Primary abstraction은 그 기억의 대표 요약 하나로 중복 제거·병합·갱신의 기준이 되며, Cue anchors는 인물·대상·사건 같은 여러 의미적 단서를 다대다로 연결한다. 검색에는 abstraction과 cue만 쓰고, 결과로는 연결된 원문을 돌려준다.

검색 전략도 여러 갈래다. 벡터 유사도 기반 Semantic, LLM이 단계적으로 검색어를 조정하는 Prompted, 벡터와 BM25·키워드를 결합해 고유명사·제품명·날짜 누락을 줄이는 Hybrid, 그리고 강화학습으로 검색 정책 자체를 학습하는 실험적 GRPO(예: Qwen 3B·7B + LoRA)까지 지원한다. 저장소는 기본 ChromaDB에 Redis를 붙일 수 있고, 사실·일화·절차 기억을 구분하며 여러 에이전트가 기억을 공유할 수도 있다. LoCoMo와 LongMemEval 벤치마크가 포함되고, MemoraClient의 add()·query()·advance_query()로 다룬다.

다만 아직 공식 릴리스가 없고 참여자·이용 지표가 적은 초기 단계다. 자동 생성된 abstraction과 cue의 품질이 검색 성능을 그대로 좌우하고, 원문을 직접 인덱싱하지 않는 구조라 희소한 문구 검색에는 불리할 수 있어 도입 전 검증이 필요하다.

월간 구독이 오히려 정답일 때

매출의 90.7%가 월간에서 나온다

구독 업계의 상식은 ‘연간이 낫다’다. LTV·현금흐름·리텐션에서 앞서고, SOSA 2026 보고서도 거의 전 카테고리에서 연간의 리텐션 우위를 확인한다. 그런데 결제 플랫폼 RevenueCat은 이 상식이 과도하게 교정되어 월간이 부당하게 저평가됐다고 지적한다.

근거는 리텐션과 매출은 다르다는 데이터다. 생산성 카테고리에서 구독의 76.7%가 월간이지만 매출의 90.7%가 월간 플랜에서 나온다. 월간 구독자가 달마다 더 많이 지불하고 이탈 후 재활성화 가능성도 높아, 시간이 지날수록 ARPPU가 예상보다 높아지기 때문이다.

불편한 진실은 지연된 해지(delayed churn)다. 연간을 선결제한 뒤 앱을 안 쓰는 사용자도 대시보드에는 약 9개월간 ‘활성 구독자’로 남는다. 이는 리텐션이 아니라 미뤄진 해지이며, 초기 앱에는 잘못된 PMF 신호를 준 뒤 갱신 월에 절벽으로 나타난다. 반대로 매달 남기를 택하는 월간 구독자는 능동적 선택이라 더 값진 신호다.

RevenueCat이 꼽은 월간이 유리한 다섯 상황은 이렇다. 첫째, 아직 학습 중일 때—피드백이 수개월이 아니라 수 주 단위로 오고, 초기 6~12개월은 월간을 기본값으로 두면 학습이 빨라진다. 둘째, 신뢰가 낮을 때—신생 브랜드나 web-to-app 흐름에서 월간이 더 낮은 첫 단계다. 셋째, 사용자가 선호할 때—MEA·APAC의 pay-as-you-go, Z세대·34세 미만의 유연성 선호가 그렇다. 넷째, 사용 사례가 단기일 때—BetterHelp(3~4개월), 단기 사용을 전제로 설계된 Hinge가 예다. 다섯째, 리텐션이 아니라 매출을 키우고 싶을 때—Spotify·Netflix는 연간 없이 월간만으로, Peloton은 하드웨어로 사용자를 고정해 프리미엄 월 요금을 받는다.

관련 글

• 파이썬 개발자를 위한 CUDA 프로그래밍 입문
• SCALE – AMD GPU에서 수정 없이 CUDA 실행
• Supermemory – AI를 위한 메모리 & 컨텍스트 엔진
• Stash – AI 에이전트를 위한 지속형 메모리 계층
• 사용자에게 구독 모델을 강요하는 것을 중단했더니 일어난 일

출처

1. Fergus Finn — What happens when you run a GPU kernel?
2. GitHub — microsoft/Memora
3. RevenueCat — Monthly subscriptions: when to offer them
4. GeekNews (news.hada.io)