DEV Community: Lucas

스타벅스 창업자는 따로 있었다: 하워드 슐츠에게 던진 12개의 불편한 질문

Lucas — Sun, 30 Aug 2026 07:14:27 +0000

먼저 밝힙니다 — 실제 인터뷰가 아닙니다.

커피콩 편집부가 질문을 만들고, 하워드 슐츠가 여러 시기에 남긴 인터뷰·증언·주주 서한과 스타벅스 공식 기록을 교차해 답변을 재구성했습니다. 답변에 새로운 사실이나 감정을 만들어 넣지 않았습니다. 서로 다른 기록을 연결한 대목은 ‘재구성’으로, 편집부의 판단은 ‘편집부 해설’로 구분했습니다. 출처는 각 문답과 글 끝에 연결했습니다.

하워드 슐츠, 2019년 애리조나주립대학교. Photo: Gage Skidmore / Wikimedia Commons, CC BY-SA 2.0.

하워드 슐츠는 스타벅스 창업자가 아니다.

프라푸치노라는 이름도 스타벅스가 처음 만들지 않았다. ‘제3의 공간’이라는 말도 슐츠의 발명이 아니다. 스타벅스는 한때 커피 향을 매장에서 몰아냈고, 스스로 만든 모바일 주문은 훗날 슐츠가 회사의 가장 큰 약점이라고 부를 정도가 됐다.

그런데 바로 그 모순 안에 스타벅스가 커피 한 잔을 4만 개가 넘는 매장의 경험으로 바꾼 방법이 숨어 있다.

그리고 사업 이야기만으로는 풀리지 않는 커피의 수수께끼도 남는다. 왜 스타벅스는 ‘탄맛’이라는 평가를 받을까? 진하게 볶으면 카페인도 강해질까? 디카페인은 정말 0mg일까? 커피 맛을 지키기 위해 회사가 농장과 600종이 넘는 커피나무 도서관까지 운영하는 이유는 무엇일까?

우리는 그를 만나지 않았다. 대신 1971년의 창업 기록, 2007년의 비밀 메모, 2008년의 매장 폐쇄, 2023년 미국 상원 증언, 2024년 연차보고서와 2025년의 발언을 한 테이블 위에 펼쳤다. 그리고 성공 신화에서 자주 빠지는 질문 12개를 던졌다.

1. 커피콩: 먼저 정정하죠. 스타벅스 창업자는 아니시잖아요?

하워드 슐츠 — 공개 기록을 바탕으로 재구성한 답변

맞습니다. 스타벅스는 제가 오기 11년 전인 1971년에 시작했습니다. 제리 볼드윈, 고든 보커, 제브 시글 세 사람이 각각 1,350달러를 넣고 5,000달러를 빌려 시애틀 파이크 플레이스 마켓에 문을 열었습니다. 당시에는 지금 같은 카페가 아니라 원두와 차, 향신료를 파는 소매점이었습니다.

저는 1982년 소매 운영·마케팅 책임자로 합류했습니다. 1984년 매장에서 에스프레소 음료를 시험했지만, 창업자들은 음료 사업이 좋은 원두를 파는 본업을 흐릴 수 있다고 봤습니다. 그래서 1985년 회사를 나와 이탈리아식 커피바 일 조르날레(Il Giornale)를 만들었습니다.

1987년 창업자들이 스타벅스의 이름, 로스팅 공장, 시애틀의 여섯 매장을 팔기로 했습니다. 저는 380만 달러를 조달해 인수했고, 일 조르날레 매장에 스타벅스라는 이름을 붙였습니다.

그러니 정확히 말하면 저는 스타벅스를 창업한 사람이 아니라, 원두 가게 스타벅스를 인수해 커피하우스 체인으로 재설계한 사람입니다.

편집부 해설: ‘창업자’와 ‘회사를 오늘의 형태로 만든 사람’은 다르다. 이 구분을 지우면 세 명의 원래 창업자도, 슐츠가 실제로 한 혁신도 동시에 흐려진다.

근거: Starbucks — Our Founders, Starbucks — Il Giornale

2. 커피콩: 하마터면 ‘스타벅스’가 아니라 ‘피쿼드’가 될 뻔했다면서요?

하워드 슐츠 — 회사의 창업 기록을 바탕으로 재구성한 답변

그 이름은 제가 만든 것도 아닙니다. 창업자 고든 보커가 허먼 멜빌의 소설 《모비 딕》에 나오는 포경선 이름 피쿼드(Pequod)를 제안했습니다. 브랜드를 도운 테리 헤클러가 그 이름을 거절했고, 오래된 광산 지도에서 ‘Starbo’라는 지명을 본 뒤 발음이 강한 ‘st’로 시작하는 단어를 탐색했습니다.

그 과정에서 《모비 딕》의 일등항해사 스타벅(Starbuck)이 떠올랐습니다. 커피와 직접 관계가 있는 인물은 아니었지만, 바다와 모험, 태평양 북서부 항구의 느낌을 담을 수 있었습니다.

오늘날 수천 개 매장에 붙은 이름은 치밀한 글로벌 전략회의의 결과가 아니었습니다. 마음에 들지 않는 첫 후보를 버리고, 지도와 문학에서 더 나은 소리를 발견한 결과였죠.

편집부 해설: 이름의 의미보다 먼저 작동한 것은 소리와 이미지였다. 브랜드 서사는 처음부터 완성되어 발견되는 것이 아니라, 선택된 이름 위에 수십 년 동안 축적되기도 한다.

근거: Starbucks — Our Name

3. 커피콩: 1983년 밀라노에서 발견한 건 커피 맛이 아니라 ‘연출’ 아니었나요?

하워드 슐츠 — 공개 발언을 바탕으로 재구성한 답변

커피만 본 것은 아니었습니다. 바리스타가 손님을 알아보고, 에스프레소를 만드는 손동작이 작은 공연이 되고, 사람들이 서서 짧게 대화를 나누는 장면을 봤습니다. 맛과 향뿐 아니라 잔, 소리, 동선, 환대가 하나의 경험을 만들고 있었습니다.

미국에 그대로 복제하려 했던 것은 아닙니다. 이탈리아 바에서는 빠르게 서서 마시는 문화가 강했지만, 미국에서는 의자와 테이블이 있는 편안한 공간이 필요했습니다. 가져온 것은 인테리어 양식이 아니라 커피를 매개로 사람이 연결되는 의식이었습니다.

원두는 집에서도 내려 마실 수 있습니다. 스타벅스가 더 비싼 가격을 받을 수 있었던 이유는 액체에만 있지 않았습니다. 주문하고, 제조 과정을 보고, 이름이 불리고, 잠시 머무는 전 과정이 상품이 됐기 때문입니다.

편집부 해설: 슐츠가 한 가장 큰 일은 ‘더 맛있는 커피’를 주장한 것이 아니라 경쟁 범주를 바꾼 것이다. 슈퍼마켓 원두와 가격을 비교하는 대신, 집과 직장 사이의 시간을 판매했다.

근거: Starbucks — Inspired by Italy, reimagined in Seattle, Starbucks — Reclaiming the third place

4. 커피콩: 창업진에게 거절당한 뒤, 투자자 217명에게도 거절당했다는 이야기는 사실입니까?

하워드 슐츠 — 본인의 공개 회고를 바탕으로 재구성한 답변

제가 여러 인터뷰에서 밝힌 숫자는 242명에게 제안해 217명에게 거절당했다는 것입니다. 단순 계산으로 약 89.7%의 거절률입니다. 어떤 사람은 아이디어가 형편없다고 했고, 누가 비싼 커피를 사겠느냐고 물었습니다.

다만 이 숫자는 당시 투자 원장으로 독립 검증된 통계가 아니라 제가 훗날 반복해 말한 회고로 보는 편이 정확합니다. 그리고 ‘혼자 세상과 싸웠다’는 이야기로 소비해서도 안 됩니다. 스타벅스 창업진이 일 조르날레의 초기 투자자로 참여했고, 저는 이미 업계 경험과 시애틀의 인맥을 갖고 있었습니다.

중요한 것은 거절 횟수가 아닙니다. 일 조르날레가 실제 매장 세 곳에서 고객이 돈을 내고 다시 찾는다는 증거를 만들었다는 점입니다. 의견에 맞서 더 큰 목소리를 낸 것이 아니라, 작동하는 작은 사업으로 논쟁의 성격을 바꿨습니다.

1987년 스타벅스 자산을 살 기회가 왔을 때도 필요한 380만 달러는 저절로 생기지 않았습니다. 다수의 거절 뒤에 남은 소수의 동의와 이미 운영되던 매장이 인수를 가능하게 했습니다.

편집부 해설: ‘217번 거절’은 끈기의 상징이지만, 더 유용한 교훈은 따로 있다. 설득 자료가 막히면 작은 실제 사용 증거가 다음 자금조달의 언어가 된다.

근거: NPR — How I Built This: Starbucks, Howard Schultz, Starbucks — Il Giornale. 242회·217회는 슐츠 본인의 회고이므로 확정된 감사 수치처럼 다루지 않았다.

5. 커피콩: 프라푸치노도 스타벅스가 처음 만든 게 아니라던데요?

하워드 슐츠 — 회사 기록을 바탕으로 재구성한 답변

절반만 맞습니다. 1993년 스타벅스의 남부 캘리포니아 직원들은 더운 날씨에 맞는 블렌디드 음료를 따로 시험하고 있었습니다. 한편 보스턴의 커피 체인 Coffee Connection은 이미 ‘Frappuccino’라는 이름의 차가운 음료를 팔고 있었습니다.

스타벅스가 1994년 Coffee Connection을 인수하면서 그 이름도 함께 얻었습니다. 이후 스타벅스가 시험하던 자체 음료에 인수한 이름을 적용했고, 1995년 커피와 모카 두 가지 맛으로 미국과 캐나다에 출시했습니다.

즉 프라푸치노는 천재 한 사람이 처음부터 끝까지 발명한 제품이 아닙니다. 현장 직원의 실험, 다른 회사가 만든 이름, 인수, 전국 유통망이 결합된 결과입니다. 스타벅스가 잘한 것은 모든 구성요소를 최초로 만든 일이 아니라, 흩어진 조각을 하나의 대중 상품으로 확장한 일이었습니다.

편집부 해설: 기업의 대표 상품은 순수한 발명보다 조합에서 태어날 때가 많다. ‘우리가 처음인가?’보다 ‘고객이 이미 원하는 조각들을 더 강한 시스템으로 묶을 수 있는가?’가 더 실용적인 질문이다.

근거: Starbucks Frappuccino Fact Sheet

6. 커피콩: 스타벅스의 성공 방식이 결국 스타벅스다움을 파괴했죠?

하워드 슐츠 — 2007년 내부 메모와 후속 인터뷰를 바탕으로 재구성한 답변

2007년 2월, 저는 당시 CEO에게 ‘스타벅스 경험의 상품화’라는 제목의 내부 메모를 보냈습니다. 외부 유출을 염두에 둔 홍보문이 아니라 회사가 무엇을 잃고 있는지 적은 경고였습니다.

매장이 1,000개 미만에서 약 13,000개로 늘어나는 동안 효율을 위해 많은 결정을 내렸습니다.

원두를 매장에서 퍼 담고 갈던 과정을 밀봉 포장으로 바꿨습니다. 신선도와 물류는 나아졌지만 문을 열자마자 맡던 커피 향은 약해졌습니다.
수동 에스프레소 머신을 높이가 큰 자동 머신으로 바꿨습니다. 속도와 일관성은 얻었지만, 고객은 바리스타가 샷을 뽑는 모습을 보기 어려워졌고 둘 사이의 시선도 가려졌습니다.
빠른 확장을 위해 매장 설계를 표준화했습니다. 운영은 쉬워졌지만 지역마다 달랐던 개성은 ‘쿠키 커터’처럼 반복되는 느낌으로 변했습니다.
따뜻한 아침 샌드위치를 늘렸습니다. 식품 매출에는 도움이 됐지만 녹은 치즈 냄새가 커피 향을 압도한다는 판단이 나왔습니다.

각 결정만 놓고 보면 합리적이었습니다. 문제는 합리적인 최적화가 동시에 쌓였을 때였습니다. 더 빠르고, 더 균일하고, 더 측정하기 쉬운 매장이 되었지만 고객이 스타벅스에 들어왔다는 감각은 약해졌습니다.

편집부 해설: 이 사례가 무서운 이유는 악수(惡手)가 아니라 선의의 개선이 브랜드를 훼손했기 때문이다. 대시보드에 잡히는 처리량은 늘었지만 향, 눈맞춤, 손동작 같은 핵심 경험은 지표 밖에서 삭제됐다.

근거: Howard Schultz의 2007년 내부 메모 원문, Starbucks 2008년 1분기 실적 발표 기록

7. 커피콩: 그래서 정말 미국 매장 7,100곳을 한꺼번에 닫았습니까?

하워드 슐츠 — 2008년 기록을 바탕으로 재구성한 답변

2008년 2월 26일 오후, 미국의 약 7,100개 직영 매장이 세 시간가량 문을 닫았습니다. 약 13만 5,000명의 바리스타가 에스프레소 추출을 다시 훈련했습니다. 문에는 더 나은 에스프레소를 위해 잠시 시간을 쓴다는 안내가 붙었습니다.

그날의 핵심은 기술 교육만이 아니었습니다. 자동화된 매장 안에서 속도에 밀려난 기준을 회사 전체에 다시 선언하는 일이었습니다. 공개 회사가 영업시간에 전국 매장의 문을 잠갔다는 사실 자체가 ‘매출보다 먼저 고칠 것이 있다’는 신호가 됐습니다.

물론 세 시간짜리 교육이 회사를 구한 마법은 아닙니다. 이후 부진 매장을 닫고, 공급망과 비용 구조를 손보고, 제품과 매장 경험에 다시 투자했습니다. 저는 당시 상황을 설명하며 짧게 말했습니다.

“성장은 전략이 아니라 전술입니다.”

제가 CEO로 복귀해 보니 폐쇄 대상 매장 중에는 문을 연 지 18개월도 안 된 곳도 있었습니다. 새 매장을 여는 숫자가 목적이 되자, 좋은 입지와 지속 가능한 수요를 확인하는 규율이 느슨해진 것입니다.

편집부 해설: 전국 매장 폐쇄는 좋은 상징이었지만 상징만으로는 부족했다. 바이럴한 장면 뒤에 매장 정리, 비용 절감, 제품 재정비라는 지루한 실행이 따라붙었기에 턴어라운드가 됐다.

근거: Los Angeles Times — Starbucks to close 7,100 stores for training, Harvard Business School — Starbucks Reinvented, McKinsey — Starbucks’ quest for healthy growth

8. 커피콩: 직원 의료보험에 원두보다 더 많은 돈을 썼다는 말도 과장 아닙니까?

하워드 슐츠 — 공식 증언과 인터뷰를 바탕으로 재구성한 답변

미국 매장에 한정해 어떤 시기에는 직원 의료보험 비용이 생두 구매 비용보다 많았다고 2023년 상원 제출 서면에서 밝혔습니다. 회사는 1988년 자격을 충족한 정규직과 시간제 직원에게 의료 혜택을 제공하기 시작했고, 1991년에는 Bean Stock을 도입했습니다. 당시 약 100개 매장에서 일하던 700명가량이 대상이었고, 스타벅스는 시간제 직원을 포함한 모든 자격 충족 직원에게 스톡옵션을 제공한 최초의 미국 비상장 기업이라고 설명합니다.

그 선택에는 제 가족사가 있었습니다. 아버지가 배달 일을 하다 다쳤을 때 의료보험이나 충분한 보호가 없어 가족 전체가 흔들렸습니다. 저는 훗날 ‘아버지가 다녀보지 못한 종류의 회사’를 만들고 싶었다고 말했습니다.

2008년 위기 때 한 주주는 의료보험을 줄이면 연간 약 3억 달러를 아낄 수 있다고 제안했습니다. 저는 그 선택을 거부했고, 대신 고객이 직접 보지 않는 영역을 중심으로 5억 8,100만 달러가량의 비용을 줄였다고 설명했습니다.

이것은 순수한 자선만은 아닙니다. 직원이 고객 경험을 만드는 서비스업에서 이직률, 숙련도, 신뢰는 비용이면서 동시에 제품 품질입니다. 스타벅스는 직원 복지를 도덕적 약속이자 운영 전략으로 함께 다뤘습니다.

편집부 해설: ‘사람이 중요하다’는 문구는 비용 압박이 없을 때 누구나 말할 수 있다. 무엇을 끝까지 줄이지 않았는지가 실제 우선순위를 보여준다.

근거: Howard Schultz의 2023년 미 상원 서면 증언, Starbucks — From employees to partners, Harvard Business Review — Howard Schultz on Starbucks’ Turnaround, TIME — Howard Schultz Wants to Change the Country With Starbucks

9. 커피콩: 그렇게 직원을 ‘파트너’라 부르면서, 왜 노조와는 충돌했습니까?

하워드 슐츠 — 2023년 미 상원 증언과 보도를 바탕으로 재구성한 답변

저는 회사와 직원이 제3자 없이 직접 관계를 맺는 방식이 스타벅스의 문화와 혜택을 만든다고 믿는다고 증언했습니다. 동시에 직원이 노조 가입 여부를 선택할 권리를 존중한다고 말했습니다.

하지만 노동자와 미국 상원 보건·교육·노동·연금위원회 다수 측은 다르게 봤습니다. 위원회 청문회 제목부터 스타벅스의 ‘불법적 노조 파괴를 끝낼 필요’를 내걸었습니다. 노조 조직 과정에서 해고, 매장 폐쇄, 교섭 지연 등 회사의 행동을 문제 삼았고, 스타벅스는 개별 사안과 법적 판단을 두고 반박했습니다.

여기서 복지와 권한은 다른 질문입니다. 의료보험과 스톡옵션을 잘 제공하는 회사라도, 직원은 임금과 노동조건을 집단으로 협상할 권한을 원할 수 있습니다. 경영진이 좋은 혜택을 만들었다는 사실만으로 권력 관계에 관한 갈등이 사라지지는 않습니다.

저의 ‘직접 관계’ 철학은 초기에는 강점으로 작동했지만, 수십만 명 규모의 회사에서 모든 직원이 그 관계를 신뢰한다고 가정할 수는 없었습니다.

편집부 해설: 이 대목은 미담으로 봉합하면 안 된다. 스타벅스는 선도적인 복지와 격렬한 노사 갈등을 동시에 가진 회사다. 둘 중 하나만 보여주면 브랜드의 진짜 구조를 놓친다.

근거: 미 상원 HELP 위원회 — 2023년 스타벅스 청문회, Howard Schultz의 서면 증언, Los Angeles Times의 청문회 보도

10. 커피콩: ‘제3의 공간’도 사실 슐츠가 만든 개념은 아니죠?

하워드 슐츠 — 공개 기록과 개념사를 바탕으로 재구성한 답변

그 표현의 창시자는 제가 아닙니다. 미국 사회학자 레이 올든버그가 1989년 저서 《The Great Good Place》에서 집이라는 첫 번째 공간, 일터라는 두 번째 공간과 구분되는 비공식적 공공 모임 장소를 third place라고 불렀습니다. 카페뿐 아니라 술집, 이발소, 서점 같은 곳이 포함됐습니다.

스타벅스는 그 개념을 대중에게 널리 알린 대표 기업에 가깝습니다. 깨끗한 화장실, 오래 앉을 수 있는 의자, 음악, 일관된 서비스, 낯선 도시에서도 예상 가능한 분위기를 하나의 상업 공간으로 만들었습니다.

다만 여기에는 원래 개념과의 긴장도 있습니다. 누구나 편하게 머무는 공동체 공간을 표방하지만, 스타벅스는 임대료와 인건비를 내야 하는 영리 기업입니다. 오래 머무는 사람은 브랜드에는 도움이 될 수 있어도 좌석 회전율에는 부담이 됩니다. 포용성과 안전, 구매 의무도 계속 충돌합니다.

편집부 해설: 스타벅스의 혁신은 개념의 발명이 아니라 운영 가능한 형태로 번역한 데 있다. 동시에 공동체를 상품화한 순간부터 ‘누가 머물 수 있는가’라는 모순도 함께 샀다.

근거: UNESCO — Third places, true citizen spaces, Starbucks — Reclaiming the third place

11. 커피콩: 모바일 주문은 제3의 공간을 살렸나요, 무너뜨렸나요?

하워드 슐츠 — 2024~2025년 공개 발언과 회사 자료를 바탕으로 재구성한 답변

둘 다 했습니다. 스타벅스의 2024 회계연도 2분기 자료를 보면 모바일 주문은 미국 직영점 거래의 31%를 차지했습니다. 미국 Starbucks Rewards 활성 회원은 3,280만 명, 회원이 만든 지출은 직영점 매출의 59%였습니다. 앱은 결제 마찰을 줄이고 개인화와 재방문을 강화한 거대한 유통 채널입니다.

하지만 매장에는 새로운 병목을 만들었습니다. 앱 화면에서는 주문이 몇 초 만에 끝나지만, 실제 매장에서는 음료가 동시에 쏟아집니다. 카운터 앞 고객과 모바일 고객, 배달 주문이 같은 바리스타와 제조대에 몰립니다. 고객은 빠른 경험을 기대하는데 직원은 이름 없는 컵의 대기열을 처리하게 됩니다.

저는 2024년 공개 대화에서 모바일 앱을 회사의 가장 큰 약점이라는 취지로까지 표현했습니다. 기술 자체가 나쁘다는 뜻이 아니라, 편의를 위해 만든 시스템이 바리스타와 고객의 관계, 즉 스타벅스가 비싸게 파는 핵심 경험을 압도했다는 뜻입니다.

이것은 2007년 자동 에스프레소 머신 문제의 디지털 버전입니다. 당시에는 큰 기계가 고객과 바리스타의 시선을 가렸고, 지금은 주문 대기열이 그 사이를 가립니다. 시대는 달라도 실패의 구조는 같습니다. 효율을 높이는 도구가 제품의 이유를 지워버린 것입니다.

편집부 해설: 디지털 전환의 진짜 비용은 앱 개발비만이 아니다. 화면에서 줄인 30초가 오프라인 현장에 몇 분의 혼잡으로 이전되는지도 측정해야 한다.

근거: Starbucks Q2 FY2024 Digital IR Dashboard, Acquired — Starbucks with Howard Schultz transcript, AP — Schultz says Starbucks needs to refocus on coffee

12. 커피콩: 2025년부터는 구매하지 않으면 매장에 머물 수 없습니다. ‘제3의 공간’은 끝난 건가요?

하워드 슐츠 — 회사 정책과 공개 발언을 바탕으로 재구성한 답변

2018년 필라델피아의 한 스타벅스에서 주문하지 않고 지인을 기다리던 흑인 남성 두 명이 체포된 사건 뒤, 회사는 구매 여부와 관계없이 매장과 화장실을 이용할 수 있도록 정책을 열었습니다.

그러나 2025년 1월 스타벅스는 북미에서 다시 구매 고객 중심 정책을 도입했습니다. 안전 문제와 매장 질서를 이유로 들었고, 직원이 괴롭힘·폭력·음주·약물 사용 등에 대응할 수 있는 행동규범도 내놨습니다. 포용적인 거실과 운영 가능한 사업장 사이의 경계를 다시 그은 셈입니다.

동시에 새 CEO 브라이언 니콜은 의자를 줄이고 ‘들고 나가는 곳’처럼 만든 것이 실수였다고 말하며 좌석과 머무는 경험을 되살리겠다고 했습니다. 주문은 약 4분 안에 제공하되, 매장은 다시 동네 커피하우스처럼 느껴져야 한다는 목표입니다.

구매해야 머물 수 있지만, 더 오래 머물게 만들겠다. 빨리 음료를 주지만, 속도만 파는 회사는 아니겠다. 이것은 말장난이 아니라 스타벅스가 풀어야 할 실제 방정식입니다.

제3의 공간이 끝난 것은 아닙니다. 다만 그것이 따뜻한 슬로건이 아니라 좌석, 화장실, 안전, 주문 속도, 직원 권한, 임대료를 동시에 설계하는 운영 문제라는 사실이 더 분명해졌습니다.

편집부 해설: 스타벅스의 다음 혁신은 새 음료가 아닐 수 있다. 서로 충돌하는 고객—빨리 가져갈 사람, 오래 머물 사람, 화장실이 필요한 사람—을 같은 공간에서 존중하는 운영체제일 수 있다.

근거: AP — Starbucks reverses its open-door policy, AP — Starbucks CEO’s four-minute goal, Axios — Brian Niccol on restoring seating

인터뷰가 끝난 뒤에도 남은 커피 미스터리 7개

경영 이야기를 잠시 내려놓고 커피 그 자체를 들여다보자. 여기부터는 슐츠의 답변을 재구성한 문답이 아니라, 커피콩 편집부가 회사 자료와 식품과학 연구를 교차해 정리한 해설이다.

미스터리 1. ‘커피콩’은 사실 콩이 아니다

우리가 원두라고 부르는 것은 식물학적으로 커피나무 열매 안에 든 씨앗이다. 커피나무에는 초록색 열매가 맺히고 익으면서 대개 붉거나 노랗게 변한다. 과육을 벗기면 보통 씨앗 두 개가 서로 마주 보고 자란다. 맞닿은 면이 눌리기 때문에 우리가 아는 반원형의 납작한 원두가 된다.

그런데 열매 안에 씨앗이 하나만 자라는 경우가 있다. 혼자 공간을 차지한 씨앗은 납작해지지 않고 작고 둥글게 자란다. 이것이 피베리(peaberry)다. 스타벅스의 커피 교육 자료는 피베리가 전체 원두의 약 5% 정도에서 나타나는 자연 변이라고 설명한다.

피베리는 모양 때문에 선별하기 쉽고 희소해서 별도 상품으로 팔리기도 한다. 하지만 ‘혼자 영양분을 독차지하니 무조건 더 맛있다’는 설명은 증명된 법칙이 아니다. 스타벅스 커피 교육자도 일반적인 납작한 원두와 마찬가지로 맛있다고 설명한다. 희귀한 모양과 절대적인 품질은 같은 말이 아니다.

근거: Starbucks Coffee Science — What is a peaberry?

미스터리 2. 스타벅스에서는 왜 ‘탄맛’이 난다는 사람이 많을까?

먼저 사실과 취향을 나눠야 한다. 스타벅스의 모든 커피가 진배전은 아니다. 현재는 블론드·미디엄·다크의 세 로스트 범위를 운영한다. 그러나 더 짧게 볶은 Blonde Roast가 회사 제품군에 정식 도입된 것은 2012년이다. 오랫동안 대중이 기억한 스타벅스의 인상은 진하고 묵직한 로스트 쪽에 가까웠다.

로스팅이 깊어지면 원산지 특유의 과일·꽃·산미는 상대적으로 약해지고, 갈변 반응과 열분해로 생긴 구운 향, 짙은 캐러멜, 스모키함과 쓴맛이 전면에 나온다. 실제 연구에서도 로스팅이 진행될수록 클로로겐산은 크게 줄었고, 강한 로스팅에서 거친 쓴맛에 관여하는 화합물이 형성되는 것으로 보고됐다.

이 맛을 어떤 사람은 ‘묵직하고 진하다’고 느끼고, 다른 사람은 ‘탔다’고 느낀다. 따라서 탄맛 평가는 완전히 틀린 비방도, 객관적인 품질 판정도 아니다. 어떤 향미를 얻고 무엇을 지웠는지에 대한 취향의 번역에 가깝다.

진배전은 우유와 시럽 속에서도 커피의 존재감을 남기고, 여러 산지의 원두를 큰 규모에서 일관된 방향으로 표현하기 쉽다는 실용적 장점이 있다. 다만 스타벅스가 진배전을 택한 이유를 ‘나쁜 원두를 감추기 위해서’라고 단정할 공개 근거는 없다. 규모에 유리하다는 해석과 확인된 사실은 구분해야 한다.

근거: Starbucks — Find the Right Coffee Roast, Starbucks Company Timeline, Food & Function — roasting과 카페인·클로로겐산 연구

미스터리 3. 색이 진할수록 카페인도 강할까?

쓴맛이 강하면 카페인도 많을 것 같지만, 둘은 같은 척도가 아니다. 카페인은 로스팅 온도에서 비교적 안정적인 물질이고, 여러 실험에서 라이트·미디엄·다크 로스트 사이의 카페인 농도가 통계적으로 유의하게 다르지 않거나 조건에 따라 서로 다른 방향으로 나타났다.

왜 인터넷에는 정반대 답이 넘칠까? 측정 기준이 다르기 때문이다.

원두 한 알, 같은 무게, 같은 부피 중 무엇을 비교했는가
아라비카인가 로부스타인가
몇 g을 얼마나 곱게 갈았는가
물의 온도와 양, 추출 시간이 얼마였는가
완성된 음료 한 잔의 크기가 얼마인가

로스팅이 깊어지면 수분과 질량, 밀도가 변한다. 따라서 스푼 한 번과 저울로 잰 20g은 같은 비교가 아니다. 최종 카페인은 로스트 색 하나보다 원두 종, 투입량과 추출법, 마시는 양의 영향을 함께 받는다.

한 줄 결론은 이것이다. ‘다크라서 세다’도 ‘라이트라서 무조건 세다’도 안전한 공식이 아니다. 잠을 걱정한다면 원두 색보다 실제 음료의 샷 수와 용량을 먼저 봐야 한다.

근거: PMC — 로스팅 단계별 카페인·클로로겐산 분석, PMC — 가공·로스팅과 카페인 함량 연구

미스터리 4. 디카페인은 정말 카페인 0mg일까?

아니다. decaffeinated는 caffeine-free와 다르다. 미국 식품의약국(FDA)은 일반적인 8온스 커피 한 잔에 카페인이 약 80~100mg 들어 있는 반면, 디카페인 커피에도 보통 2~15mg이 남는다고 설명한다.

디카페인은 원두에 원래 있던 카페인의 대부분을 제거하는 공정이지, 카페인이 한 번도 존재하지 않았던 음료가 아니다. 카페인에 매우 민감하거나 여러 잔을 마시는 사람이라면 작은 잔여량도 합산될 수 있다.

반대로 이 숫자는 디카페인이 ‘가짜’라는 뜻도 아니다. 일반 커피보다 카페인을 크게 낮추면서 커피 향미를 남기는 것이 기술의 목적이다. 정확한 표현은 카페인이 없는 커피가 아니라, 대부분 덜어낸 커피다.

근거: U.S. FDA — Spilling the Beans: How Much Caffeine is Too Much?

미스터리 5. 왜 스타벅스는 로부스타 대신 아라비카만 살까?

스타벅스는 자사가 구매하는 커피가 100% 아라비카라고 밝힌다. 아라비카는 일반적으로 향과 산미의 폭이 넓어 고급 커피 시장에서 선호되지만, 재배는 더 까다롭다. 로부스타는 더 높은 온도와 병충해에 상대적으로 강하고 수확량도 높다. World Coffee Research의 재배 자료에서는 로부스타의 카페인 함량을 약 2.7%, 아라비카를 약 1.5%로 제시한다. 카페인은 사람에게 각성 성분이지만 식물에는 해충을 막는 방어 수단이기도 하다.

여기에 스타벅스의 딜레마가 있다. 회사가 맛의 기준으로 택한 아라비카가 기후 변화에는 더 민감하다. 스타벅스는 2024년 기준 30개 시장의 45만 명이 넘는 농가에서 아라비카를 조달한다고 밝혔다. 이 공급망에서 기온·강우 패턴·녹병이 흔들리면 메뉴 하나가 아니라 회사의 원료 기준 전체가 흔들린다.

로부스타가 ‘나쁜 커피’라는 뜻은 아니다. 품종과 재배·가공 품질에 따라 좋은 로부스타도 존재하고, 기후 압력 속에서 세계 생산 비중도 커지고 있다. 스타벅스가 아라비카만 고집한다는 사실은 품질 선언인 동시에 기후 위험을 한 종류에 집중시키는 선택이다.

근거: Starbucks — Coffee, Bean-to-Cup, World Coffee Research — Robusta nursery manual, World Coffee Research — Robusta production and breeding

미스터리 6. 커피를 직업으로 맛보면 하루에 몇 잔을 마실까?

스타벅스 시애틀 본사의 커핑룸에서는 소수의 전문 테이스터가 하루에 수백, 많게는 수천 개의 샘플을 평가한다고 회사는 설명한다. 여기서 ‘맛본다’는 것은 모든 잔을 다 마신다는 뜻이 아니다. 향을 맡고 숟가락으로 강하게 흡입해 입안 전체에 퍼뜨린 뒤 뱉어내며 결함과 향미를 비교하는 커핑(cupping) 방식이다.

34년 동안 커피를 평가한 스타벅스의 레슬리 울퍼드는 자신이 약 100만 잔을 맛봤을 것으로 추정했다. 기분과 직전에 먹은 음식도 감각에 영향을 주기 때문에 일부 테이스터는 평가 전에 치약조차 사용하지 않는다고 한다.

그들이 찾는 것은 ‘맛있다/맛없다’만이 아니다. 가뭄, 발효, 보관과 가공 과정에서 생긴 결함을 감지하고 어느 단계에서 문제가 생겼는지 거꾸로 추적한다. 어떤 산지에서는 커피가 생감자처럼 느껴지는 특유의 결함도 조사 대상이 된다.

100만 잔이라는 숫자는 회사 직원 본인의 추정치이지 계수기로 센 기록은 아니다. 그래도 중요한 사실은 남는다. 전 세계에서 같은 로고를 단 커피의 기준은 거대한 알고리즘만이 아니라, 훈련된 인간의 코와 혀에 상당 부분 의존한다.

근거: Starbucks — Keeping your cup full, Specialty Coffee Association — The Value of Specialty Coffee Cuppers, World Coffee Research — Potato taste defect

미스터리 7. 커피 회사가 왜 농장과 ‘나무 도서관’을 운영할까?

스타벅스는 2013년 코스타리카의 아시엔다 알사시아(Hacienda Alsacia)를 연구·개발 농장으로 강화했다. 이곳의 핵심 커피 컬렉션에는 600종이 넘는 품종·교배종이 있고, 300개에 가까운 새 교배종도 개발 중이라고 회사는 설명한다. 목표는 맛, 수확량, 빠른 성숙, 병충해와 기후 저항성을 한 나무 안에서 함께 얻는 것이다.

이 농장의 흥미로운 점은 특급 원두를 독점 생산하는 비밀 농장이라기보다 커피나무의 살아 있는 도서관이자 시험실에 가깝다는 데 있다. 후보 나무를 기르고, 맛을 평가하고, 녹병과 가뭄에 버티는지 확인한 뒤 농가에 묘목과 재배 지식을 나눈다.

2026년 3월 스타벅스는 기후에 불리한 조건에서 성능을 보인 품종으로 키운 커피나무 1억 그루를 농가에 무상 제공했다고 발표했고, 다음 단계에서 5,000만 그루를 더 보급하겠다고 밝혔다. 일부 프로그램은 스타벅스에 원두를 팔지 않는 농가도 씨앗을 받을 수 있게 했다.

물론 이는 기업이 자기 공급망을 지키는 투자이기도 하다. 선행과 사업 방어가 동시에 성립한다. 스타벅스가 나무를 나누는 이유는 커피 산업 전체가 살아야 자사도 앞으로 커피를 팔 수 있기 때문이다.

근거: Starbucks — Ten Years of Impact at Hacienda Alsacia, Starbucks FY2024 Global Impact Report, Starbucks — 100 million coffee trees donated

보너스. 원두를 가는 순간, 향은 왜 빠르게 사라질까?

커피 맛의 큰 부분은 혀가 아니라 코가 느끼는 휘발성 향에서 온다. 원두를 갈면 물과 닿는 면적만 넓어지는 것이 아니라 공기와 접촉하는 표면도 폭발적으로 늘어난다. 갇혀 있던 향 성분이 빠져나가고 산소와의 반응도 빨라진다.

이 사실을 알고 나면 2007년 슐츠의 메모가 다르게 읽힌다. 매장에서 원두를 퍼 담고 갈던 과정을 밀봉 포장으로 바꾸자 단순한 볼거리가 사라진 것이 아니었다. 고객이 문을 열었을 때 ‘여기는 커피를 다루는 곳’이라고 즉시 알려주던 향기 신호가 약해진 것이다.

효율화로 삭제된 것은 작업 한 단계였지만, 고객의 뇌에서 삭제된 것은 브랜드의 첫인상이었다.

근거: Starbucks Coffee Science — How to store coffee beans, Howard Schultz의 2007년 내부 메모

30초 만에 깨지는 스타벅스와 커피 신화 8개

널리 퍼진 이야기	공개 기록이 보여주는 사실
하워드 슐츠가 스타벅스를 창업했다	볼드윈·보커·시글이 1971년 창업했다. 슐츠는 1982년 합류했고 1987년 자산을 인수했다.
스타벅스가 프라푸치노를 발명했다	스타벅스 직원들이 자체 블렌디드 음료를 개발했지만, ‘Frappuccino’라는 이름은 1994년 Coffee Connection 인수로 얻었다.
슐츠가 ‘제3의 공간’을 만들었다	사회학자 레이 올든버그가 1989년 개념을 명명했다. 스타벅스는 이를 상업적으로 대중화했다.
디지털 주문은 편의만 높였다	2024년 미국 직영점 거래의 31%를 만들었지만, 매장 혼잡과 인간적 연결 약화라는 비용도 낳았다.
커피콩은 식물학적인 콩이다	붉거나 노란 커피 열매 안에서 자라는 씨앗이다. 보통 한 열매에 두 개가 들어 있다.
피베리는 무조건 일반 원두보다 맛있다	한 열매에 씨앗 하나만 자란 희귀한 형태다. 희소성과 절대적인 품질은 같은 말이 아니다.
다크 로스트는 카페인이 무조건 더 많다	로스트 색만으로 정할 수 없다. 원두 종, 투입량, 계량 방식과 추출법이 함께 좌우한다.
디카페인은 카페인이 0mg이다	FDA에 따르면 8온스 한 잔에 보통 2~15mg이 남는다.

숫자로 보면 전혀 다른 회사가 보인다

숫자	의미
$1,350 × 3	1971년 세 창업자가 각자 넣은 돈. 별도로 5,000달러를 빌렸다.
$3.8M	슐츠가 1987년 스타벅스 이름·로스팅 공장·6개 매장을 인수하기 위해 조달한 금액.
217 / 242	슐츠가 회고한 투자 거절 수와 전체 제안 수. 독립 감사 수치가 아닌 본인 회고다.
7,100개·13만 5천 명	2008년 에스프레소 재교육을 위해 문을 닫은 미국 매장과 참여 바리스타 규모.
31%	2024 회계연도 2분기 미국 직영점 거래에서 모바일 주문이 차지한 비중.
40,199개	2024년 9월 29일 기준 전 세계 매장. 직영 21,018개, 라이선스 19,181개.
74%	2024 회계연도 직영점 매출에서 음료가 차지한 비중. 식품 23%, 기타 3%.
1,980개	같은 시점 한국의 라이선스 매장 수. 미국·중국 다음으로 큰 국가별 매장망 중 하나다.

매장 수와 상품 구성 근거: Starbucks Fiscal 2024 Annual Report. 217회 거절은 앞서 밝힌 대로 슐츠의 회고다.

이 이야기가 커피 회사 밖에서도 중요한 이유

1. 카테고리를 바꾸면 가격 비교의 기준도 바뀐다

스타벅스가 원두 소매점으로만 남았다면 슈퍼마켓과 가격을 비교당했을 것이다. 하지만 ‘집과 직장 사이에 머무는 시간’을 상품으로 만들자 경쟁 상대가 달라졌다. 좋은 제품은 기능을 하나 더 얹기도 하지만, 때로는 고객이 무엇과 비교해야 하는지를 바꾼다.

2. 고객이 사랑하는 것은 종종 지표 밖에 있다

커피 향, 바리스타와의 눈맞춤, 손으로 샷을 뽑는 모습은 처리량 표에 잘 나타나지 않는다. 그래서 비용 절감과 자동화 때 가장 먼저 사라지기 쉽다. 핵심 경험을 지키려면 전환율과 속도뿐 아니라 ‘우리가 왜 선택받는가’를 나타내는 질적 신호를 의도적으로 측정해야 한다.

3. 성공 공식을 복제할수록 원본이 약해질 수 있다

매장을 똑같이 만들면 빠르게 늘릴 수 있다. 그러나 어느 도시에 가도 같은 매장이 되는 순간 ‘동네의 제3의 공간’이라는 약속과 충돌한다. 확장성은 차이를 제거하는 능력이고, 브랜드는 의미 있는 차이를 기억시키는 능력이다. 둘은 자연스럽게 화해하지 않는다.

4. 직원 복지와 직원 권한은 같은 말이 아니다

스타벅스는 시간제 직원 의료보험과 스톡옵션에서 앞서갔다. 동시에 노조와 깊게 충돌했다. 회사가 좋은 혜택을 제공한다는 사실과 직원이 집단 협상권을 원한다는 사실은 함께 성립할 수 있다. ‘우리는 잘해주고 있다’는 확신이 상대의 권한 요구를 대신할 수는 없다.

5. 디지털 편의는 오프라인 노동을 사라지게 하지 않는다

앱에서 줄이 사라졌다고 매장의 줄이 사라진 것은 아니다. 주문이 보이지 않게 되었을 뿐, 바리스타 앞에는 더 복잡한 대기열이 생겼다. 모든 디지털 제품은 편의를 만든 장소와 비용이 도착한 장소를 함께 봐야 한다.

인터뷰를 덮으며

스타벅스는 커피로 성공했다. 그러나 커피만으로 성공한 것은 아니다.

이 회사는 다른 사람이 만든 원두 가게를 인수했고, 다른 회사가 가진 제품 이름을 사왔고, 사회학자가 만든 개념을 대중화했다. 밀라노에서 본 의식을 미국식 공간으로 번역했고, 그 공간을 놀라운 속도로 복제했다. 그러다 효율화로 향기와 눈맞춤을 지웠고, 전국 매장을 닫아 그것을 다시 배웠다. 직원에게 의료보험과 주식을 주면서도 노조와 충돌했고, 가장 강력한 앱이 가장 큰 약점이 되는 역설도 만들었다.

그래서 이 이야기는 완성된 성공 공식이 아니다. 오히려 성공한 제품이 규모를 얻을 때 무엇을 잃는지 보여주는 장기 실험에 가깝다.

하워드 슐츠의 가장 참신한 아이디어는 ‘커피를 팔자’가 아니었다. 사람이 커피를 마시는 장면 전체를 제품으로 보자는 것이었다. 그리고 스타벅스가 반복해서 흔들린 이유도 똑같다. 그 장면의 일부를 비용이나 속도 문제로만 보기 시작할 때마다, 회사는 자신이 무엇을 파는지 잊었다.

커피콩 편집부가 마지막으로 남기고 싶은 질문은 이것이다.

지금 당신의 제품에서 숫자로 가장 잘 측정되는 부분과, 고객이 실제로 사랑하는 부분은 같은가?

이 글은 커피와 사람 사이의 이야기를 모으는 커피콩(CoffeeCong)에서 만들었습니다.

자료와 편집 기준

재구성 원칙: 여러 자료의 취지를 합친 문장은 따옴표를 쓰지 않았습니다. 직접 인용은 원문 의미를 보존해 짧게 번역했습니다. 수치의 시점과 범위를 가능한 한 함께 표기했고, 슐츠 본인의 회고는 독립 검증된 사실과 구분했습니다. 답변 사이의 ‘편집부 해설’과 마지막 분석은 커피콩 편집부의 해석입니다.

"상품권 교환 빠른 커피콩 앱테크 패턴 10가지"

Lucas — Sat, 18 Jul 2026 05:50:23 +0000

"상품권 교환 빠른 커피콩 앱테크 패턴 10가지"

커피콩 유저들의 적립 데이터를 분석했어요.
커피콩에서는 10원두가 1원이고, 첫 상품권은 4700원 커피 쿠폰이에요.

2026년 6월 2일부터 7월 15일까지 처음 관측된 익명 이용 단위 가운데, 실제 원두 잔액이 상품권 교환 기준인 47,000원두에 가장 빠르게 도달한 상위 10개 사례를 살펴봤습니다.

가장 빠른 사례는 6.3시간, 10번째 사례도 4.6일 만에 47,000원두에 도달했습니다.

패턴 1–2: 미라클을 중심으로 빠르게 출발

패턴 1 · 미라클 원샷형: 6.3시간
패턴 2 · 미라클·친구초대형: 1.1일

패턴 2의 핵심 행동은 미라클 30,804원두 → 친구초대 5,000원두였습니다. 한 가지 기능만 반복하기보다 서로 다른 적립 루트를 조합한 사례입니다.

패턴 3–4: 미라클과 앱 미션의 조합

패턴 3 · 미라클 연속형: 3.1일
패턴 4 · 초대·앱미션형: 3.4일

패턴 5–6: 친구초대에 광고와 루틴 더하기

패턴 5 · 친구초대 집중형: 3.4일
패턴 6 · 초대·루틴 병행형: 3.6일

패턴 7–8: 행운과 게임을 함께 활용

패턴 7 · 행운·초대 투트랙형: 3.8일
패턴 8 · 게임 몰입·초대형: 4.4일

패턴 9–10: 루틴과 성장 보상까지 확장

패턴 9 · 초대·루틴 확장형: 4.4일
패턴 10 · 미라클·성장형: 4.6일

스마트한 앱테크의 핵심은 적립 루트 조합

상위 10개 사례 중 9개는 첫 번째 적립 행동이 미라클 또는 친구초대였습니다. 하지만 게임·광고·데일리 루틴·앱 미션·성장 보상도 함께 활용됐습니다.

커피콩은 여러 적립 루트를 자신의 사용 방식에 맞게 조합할 수 있는 앱테크 리워드앱입니다.

분석 기간: 2026.06.02–07.15. 차단·테스트·운영자 지급 사례와 원두가 아닌 게임 상태 로그는 제외했습니다. 관측된 상위 사례를 요약한 결과이며, 미라클 같은 확률형 보상과 적립 속도는 이용자마다 다를 수 있습니다.

앱테크 #앱테크추천 #리워드앱 #커피콩 #짠테크

I scored 8,000 Seoul cafes for laptop-workability from review keywords

Lucas — Sat, 20 Jun 2026 03:30:59 +0000

I wanted one boring thing: a map that tells me which cafe near me is actually good for sitting with a laptop for three hours. Not "4.5 stars" — that rates the latte. I wanted "wide seats, quiet, has outlets, won't glare at you for staying."

That signal exists. It's just buried in the text of visitor reviews, not in any star rating. So I spent a few weeks pulling it out for ~8,000 cafes in Seoul, turning it into a single number, and — because the data turned out to be interesting on its own — publishing it as a free report. Here's what was annoying, what I learned, and what the data said.

Why not just use the existing ratings

Naver Place and Kakao Map already have ratings and reviews for basically every cafe in Korea. I tried to lean on them and bounced off for three reasons:

Star ratings answer the wrong question. A 4.6-star cafe can have zero outlets and a 60-minute soft time limit. The rating measures "did people enjoy their visit," not "can I work here."
The useful signal is in keywords, not stars. Korean review platforms surface visitor keyword tags ("좌석이 편해요" / "콘센트가 많아요" / "오래 있기 좋아요"). That's the gold. But it's per-cafe, unaggregated, and not comparable across places.
No ownership. I can't rank, filter, or build a map on top of a number I don't control. I wanted a score I could recompute and stand behind.

So the job became: convert fuzzy keyword tags + a few structured fields into one comparable, defensible score.

The parts that ate the time

Turning keywords into axes (~the longest part)

Visitor keywords are wonderfully human and terrible as data. "콘센트 넉넉" / "콘센트 많아요" / "충전 가능" all mean the same axis (outlets) with different surface forms, and the count of each keyword matters more than its presence. I ended up mapping keyword clusters to eight axes — price, pressure (the "are they rushing you out" vibe), outlets, wifi, seat space, focus/noise, refills, restrooms — each normalized to 0–100.

The trap that cost me a day: never treat a missing axis as zero. A cafe with no wifi data isn't a 0-wifi cafe; it's an unknown. If you fill nulls with 0 (or with a flat 50 "average"), every sparse cafe collapses toward the same mediocre score and the ranking turns to mush. The fix was to drop null axes out of the weighted average and renormalize the remaining weights per cafe. Boring, but it's the difference between a real ranking and noise.

Picking a formula I could defend

I split it into two scores instead of one mega-number:

Workability = seat space × 0.45 + focus × 0.40 + price × 0.15, bucketed into S/A/B/C grades. This is the "can I actually work here" score, and it leans hard on space + quiet because that's what the reviews say matters.
Survival = an 8-axis weighted blend (price, inverted-pressure, outlets, wifi, space, focus, refill, restroom) for "how long can I camp here."

The weights are opinions, not physics — but they're stated opinions. Anyone can disagree with "space is 45%," and that's fine; the point is the number is reproducible and the methodology is on the page.

The SEO sandbox surprise (the genuinely humbling part)

I rendered ~8,000 cafe pages plus district/station/purpose landing pages server-side, submitted clean sitemaps, valid canonicals, JSON-LD — textbook. Google crawled them and indexed almost none. "Crawled – currently not indexed."

That's not a bug you can fix in code. A brand-new domain emitting thousands of structurally-similar pages reads as low-value, and Google quietly throttles the indexing quota until you earn authority. The lesson that reframed the whole project: for programmatic pages, the bottleneck isn't crawlability, it's per-page uniqueness and domain trust. Which is exactly why the next section exists.

What I extracted

Two things came out of this that are reusable on their own:

A per-page aggregate. Instead of every district page being the same template with a different list of cafes, each one now states its own computed numbers — average workability, grade distribution, the strongest axis, average americano price. Computed from real data, so each page is genuinely different.
A public district report. I aggregated all 25 Seoul districts into one page and published it free (CC BY 4.0): Seoul cafe workability report. It's the linkable, citeable version of the dataset — and honestly the most fun output to read.

What the data actually said

A few things that surprised me once it was aggregated by district:

The highest-average-workability districts are not the trendy ones — quieter residential-leaning districts beat the Instagram hotspots, because hotspot cafes optimize for vibe and turnover, not for someone parked with a laptop.
Outlet density varies wildly by district — some areas average meaningfully higher, which tracks with how many study/work-oriented cafes cluster there.
Average americano price spreads further than I expected across districts, which makes the price axis carry real signal.

Honest limits

Keyword bias. The score is only as good as what visitors chose to mention. Cafes with few reviews get thin, less-trustworthy scores — so I noindex/exclude the very sparse ones rather than pretend.
Scores are proxies. "Focus 80" is a model output from review language, not a decibel meter. It's directionally right, not laboratory-precise.
Coverage is Seoul-only, and freshness depends on review volume, which is uneven.
A higher-authority competitor (Naver itself) will always have more raw coverage. My bet is on the angle — workability, not popularity — not on out-crawling them.

The thing I'm still chewing on

For data-heavy sites, the honest growth lever turned out to be "make each page worth citing," not "publish more pages." If you've shipped a programmatic/data site: did unique per-page aggregates actually move indexing for you, or did it only move once real backlinks showed up? I'd love to hear which one broke the logjam first.

I tried "GEO" on my indie tool — it was just SEO (here's the GSC data)

Lucas — Sun, 14 Jun 2026 23:34:48 +0000

Every other newsletter this year told me my SaaS needed GEO — Generative Engine Optimization. Write an llms.txt. Add "AI-only" schema. Chunk your content for the models. So before sinking a weekend into it, I read one contrarian source, opened Google Search Console for my tool, and looked at the actual numbers. The verdict was boring and freeing: for Google, optimizing for AI answers is still just SEO. The real problem wasn't my markup — it was that almost nothing about my site was discoverable in the first place. Here's the data, the three fixes that mattered, and the two places I face-planted.

Why I didn't buy the GEO hype

I'm building Mimi Seed, an open-source MCP server that lets indie devs drive Play Store / App Store / Firebase releases from inside Claude Code or Codex. Classic indie-hacker situation: tiny audience, and a constant temptation to chase the shiny new growth lever.

The single most useful thing I read was a curated list (awesome-geo) whose thesis is blunt: most "GEO" advice is repackaged SEO with a markup tax. Their reading of the primary docs:

Google has publicly said optimizing for AI Overviews is the same SEO you already know. No special schema required.
llms.txt is a community proposal. Google doesn't support it and has no plans to. Treating it as mandatory is hype.
The one engine that does ask for special treatment is Bing/Copilot (FAQ markup, tables, IndexNow).
The actual common denominator across every engine: clear authorship, a consistent entity identity, canonical URLs, and being cited by trustworthy external sources.

That last bullet turned out to be the whole game. But I didn't take their word for it — I went to the data.

What GSC actually told me

My landing page lives on a subdomain. I didn't even have a dedicated Search Console property for it — it was rolled up under the parent domain property. So I queried the parent property and filtered to just my pages. Ninety days:

One URL had any impressions: the homepage. 19 impressions, 0 clicks, average position 6.2.
The query breakdown came back empty. Every one of those 19 impressions was below GSC's anonymization threshold — i.e., low-volume brand-ish searches. Zero non-brand discovery.
URL inspection: the homepage was indexed, canonical correct, crawled fine. So indexing wasn't broken.
Referring URLs: exactly one — libraries.io, an npm mirror. My entire backlink profile was an auto-generated package page.

This reframed everything. My problem was never snippet wording or AI-readability. You can't optimize the click-through rate of a result nobody sees. The bottleneck was impressions — being found at all — and the lever for that, per the data and the contrarian list, is external citations, not markup.

And one more thing I'd half-ignored: my sitemap had never been submitted to Search Console. It existed at /sitemap.xml, generated by the framework, registered nowhere.

The three fixes that were actually SEO

No llms.txt. No secret AI schema. Just hygiene:

1. A real entity graph. My JSON-LD was a lone SoftwareApplication object. I replaced it with a proper @graph tying together Organization + WebSite + SoftwareApplication, and — the part that matters for both SEO and "GEO" — a sameAs array linking the GitHub repo and both npm packages.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Mimi Seed",
      "sameAs": [
        "https://github.com/jeonghwanko/mimi-seed-sdk",
        "https://www.npmjs.com/package/mimi-seed",
        "https://www.npmjs.com/package/@yoonion/mimi-seed-mcp"
      ]
    },
    { "@type": "WebSite", "publisher": { "@id": "https://example.com/#organization" } },
    { "@type": "SoftwareApplication", "publisher": { "@id": "https://example.com/#organization" } }
  ]
}

sameAs is the literal mechanism for telling a search/answer engine "the website, the GitHub org, and the npm packages are all the same entity." For a project that recently went through a rename, consolidating that identity is the highest-leverage markup change you can make.

2. A sitemap that isn't lying. My generated sitemap listed anchor URLs — /#install, /#features, /#cli. Here's the detail no tutorial mentions: Google strips the fragment. Every one of those collapses to the same canonical /. They add zero index coverage and just noise. Worse, the sitemap also listed /tool — which my robots.txt disallowed. That's a self-inflicted "Submitted URL blocked by robots.txt" warning. My landing is a single-page app, so the honest sitemap is exactly one URL. I trimmed it to that, then submitted it. Google fetched it within seconds: 0 errors, 1 URL — which is the fragment-dedup behavior proving itself.

3. A dedicated property. I added a URL-prefix property for the subdomain so its impressions/positions stop being averaged in with unrelated sites. Pure reporting hygiene, but you can't improve what you can't see cleanly.

Where I face-planted

Two pitfalls ate more time than the actual SEO work.

Next.js caches your public/ file list. Google's verification needed google<token>.html served at the site root. I dropped it into public/ on the live box and curled it — 404. But an existing file in the same directory (/icons/...png) returned 200. The running server had snapshotted the set of public files at build/boot and never rescanned. A graceful reload fixed it (the file was on disk the whole time). If you ever hot-patch a static file into a running Node server and it 404s while its neighbors don't, that's your clue — restart, don't debug the path.

Your API's Google identity ≠ your browser's. I tried to submit the sitemap programmatically and got a flat 403: insufficient permission for the new property — even though I'd just verified it in the browser. The catch: the automation authenticates as one Google account; my browser session was a different account. The property was owned by the browser identity, invisible to the API identity. Once I re-verified it under the same account that owned the parent domain property (the one the automation actually uses), the submit went through instantly. Verification is per-identity, and "I'm logged in as me" in two places doesn't mean it's the same me.

The honest limitation

I fixed the hygiene. I did not fix the actual bottleneck. My backlink profile is still one auto-generated npm mirror. The entity graph helps an engine understand my project once it finds it — but the data is unambiguous that the gating factor is being found, and that's a function of external citations I don't have yet. Markup was the easy 20%. The hard 80% — getting real, trustworthy sources to mention the project — is exactly the work that doesn't fit in a JSON-LD block.

So this post is also me doing something about that. Which is very on-brand for the conclusion.

What surprised me

The contrarian source was more actionable than any "47 GEO tactics" listicle, precisely because it told me what not to do. Skipping llms.txt and AI-schema cargo-culting saved the weekend I'd budgeted for them, and the data said that weekend would've moved nothing.

What I'd ask you

If you've shipped a small tool or SaaS: did "GEO" ever do anything measurable for you that plain SEO + getting cited didn't? Or is it, as far as the data goes, just SEO with a markup tax and better marketing? I'd genuinely like to be wrong here — tell me what you've measured.

"커피콩 이용 방법 — 매일 마시는 커피로 기프티콘 모으는 법 (완전 가이드)"

Lucas — Tue, 09 Jun 2026 06:04:22 +0000

매일 커피 한 잔은 마시는데, 그 돈이 그냥 사라지는 게 아깝다면 — 리워드 앱 커피콩 (CoffeeCong) 이용 방법을 처음부터 끝까지 정리했습니다. 카페에 가고, 영수증을 찍고, 짧은 광고를 보는 일상 행동을 원두(포인트) 로 바꿔 모으면, 실제 커피 기프티콘으로 교환할 수 있습니다.

한 줄 요약: 일상 커피 습관 → 원두 적립 → 기프티콘 교환. 10원두 = 1원 가치로 환산됩니다.

1. 설치하고 시작하기

먼저 앱을 받습니다.

Google Play / App Store에서 "커피콩" 검색
설치 후 닉네임만 정하면 끝 — 회원가입 절차가 따로 없고, 첫 진입에서 원두를 바로 줍니다.

웹에서 서비스 소개와 커피 혜택 정보를 먼저 보고 싶다면 coffee.pryzm.gg 에서 확인할 수 있습니다.

2. 원두 모으는 6가지 방법

커피콩의 핵심은 "한 가지만 하는 앱"이 아니라는 점입니다. 본인 생활 패턴에 맞는 경로 몇 개만 챙겨도 충분합니다.

① 카페 체크인

커피숍에 갔을 때 앱에서 체크인하면 원두가 적립됩니다. 가장 가볍고, 매일 하는 카페 방문이 그대로 적립으로 이어집니다.

② 커피 영수증 인증

오늘 마신 커피 영수증을 사진으로 인증하면 추가 원두를 받습니다. 그냥 버릴 영수증 한 장이 기프티콘에 한 걸음 더 가까워지는 셈입니다.

③ 통신사·카드사 커피 혜택 챙기기

매일 바뀌는 커피 할인·쿠폰·멤버십 혜택을 앱에서 모아 보여줍니다. 놓치기 쉬운 통신사·카드사 커피 혜택을 한곳에서 확인할 수 있어, 적립과 별개로 당장 커피값을 아끼는 용도로도 좋습니다. (커피값 아끼는 법은 이 가이드에 정리돼 있습니다.)

④ 방치형 원두농장

앱을 계속 붙잡고 있지 않아도 됩니다. 방치형 원두농장은 시간이 지날수록 원두가 쌓이고, 가끔 들어와 수확만 하면 됩니다. 잠잘 때·일할 때도 적립이 굴러갑니다.

⑤ 미니게임

쉬는 시간에 짧은 미니게임을 플레이해 원두를 모을 수 있습니다. 가볍게 즐기면서 적립하는 재미 요소입니다.

⑥ 광고 보기 · 행운 뽑기

짧은 광고를 보면 원두를 받고, 모은 티켓으로 행운 뽑기를 돌려 한 번에 큰 원두를 노릴 수도 있습니다.

3. 모은 원두를 기프티콘으로 교환

원두가 충분히 쌓이면 상품권 교환소에서 교환합니다.

교환비율: 10원두 = 1원 가치
교환 가능 품목: 커피 기프티콘, 네이버페이, 편의점 상품권 등 모바일 상품권

즉 "오늘 마신 커피값"을 시간을 들여 다시 커피 기프티콘으로 돌려받는 구조입니다.

4. 더 빨리 모으는 꿀팁

매일 출석(스트릭) 유지: 연속 출석일이 쌓일수록 보너스가 붙습니다. 하루도 빠지지 않는 게 누적 적립에서 가장 큽니다.
주간 챌린지: 한 주 동안 체크인 횟수를 채우면 추가 보상을 받습니다.
경로 분산: 체크인 + 영수증 + 방치 농장 세 가지만 매일 챙겨도 적립 속도가 확 올라갑니다.

보너스 — 공부하기 좋은 카페 찾기

커피콩 생태계에는 서울 카공 카페 지도 도 있습니다. 자치구·지하철역·목적(조용한 곳, 노트북 작업 등)별로 카페를 찾을 수 있어, 카페에서 공부하거나 작업하는 분이라면 체크인 적립과 함께 활용하기 좋습니다.

정리하면 — 커피콩은 이미 하고 있는 커피 소비를 리워드로 전환하는 앱입니다. 설치하고, 본인에게 맞는 적립 경로 2~3개만 매일 챙기면 됩니다. 자세한 서비스 정보는 coffee.pryzm.gg 에서 볼 수 있습니다.

여러분은 커피값을 어떻게 아끼고 계신가요? 쓰고 있는 커피 적립·할인 꿀팁이 있다면 댓글로 공유해 주세요.

"새 도메인에 프로그래매틱 SEO 페이지 8,000개를 띄웠다. 구글은 거의 색인하지 않았다 — 부검 기록"

Lucas — Tue, 09 Jun 2026 06:02:28 +0000

3줄 요약 — 갓 만든 도메인에 서울 "카공 카페" 지도용 페이지 약 8,000개를 SSR로 띄웠다. 노출이 6일 만에 3 → 209로 올랐다가 ~0으로 붕괴했다. 버그가 아니었다. robots·canonical·fetch 전부 정상. 신규 도메인의 권위(authority) 벽이었고, 깨끗한 코드나 sitemap.xml 수정으로는 못 뚫는다. 내가 점검한 전부, 바꾼 것, 그리고 불편한 교훈을 적는다.

배경

작은 한국 앱 커피콩 (CoffeeCong) 을 운영한다. 매일 마시는 커피 습관을 리워드로 바꿔주는 앱이다. 콘텐츠/SEO 전략으로 프로그래매틱 사이트를 하나 만들었다 — 서울의 공부하기 좋은 카페 지도. 자치구별·지하철역별·목적별(조용한 곳, 노트북 작업, 심야 등)로 탐색할 수 있다.

페이지 수는 조합에서 나온다:

자치구(25) × 목적(7)        → 카테고리 허브 약 175개
+ 지하철역(약 300)          → 역세권 허브
+ 개별 카페(약 6,000)       → 카페당 1페이지
≈ 8,000 URL

아키텍처는 셸 주입(shell-injection) SSR 패턴이다 — 사용자에게는 인터랙티브 React 지도를 그대로 주고, 봇에게는 같은 셸에 완전히 렌더된 HTML 본문을 주입한다:

function renderSsr(data: PageData): string {
  const template = readTemplate();              // SPA 셸 (<div id="root"></div> 보유)
  const ssrBody = buildSsrBody(data);           // h1 + 본문 + 디렉토리 링크
  const headInject = `
    <link rel="canonical" href="${canonical}" />
    <meta name="robots" content="index, follow, max-image-preview:large" />
    <script type="application/ld+json">${jsonLd}</script>`;

  let html = template.replace('<div id="root"></div>', `<div id="root">${ssrBody}</div>`);
  html = html.replace('</head>', `${headInject}</head>`);
  return html;
}

그래서 모든 URL이 Googlebot에게 진짜 HTML이다: <h1>, 브레드크럼, JSON-LD, 내부 링크. 본문을 읽는 데 JS가 필요 없다. 사이트맵 제출 완료, robots.txt 깨끗함. 다들 "이건 꼭 제대로 해라"라고 말하는 그 부분 — 나는 제대로 했다.

상승, 그리고 절벽

다음은 Search Console의 실제 일별 노출 곡선이다:

날짜	노출
1일차	3
2일차	31
3일차	64
4일차	126
5일차	189
6일차	209
7일차	14
8일차~	2 → 0 → 0

"되고 있어!" 6일 — 그리고 절벽에서 떨어져 0에 수렴했다. 모든 사이트맵: 제출 N개, 색인 0개.

내 첫 직감은 당신과 같았다: 뭔가 망가졌다. 아니었다.

부검 (실제로 점검한 것)

루트·허브·카테고리 샘플에 URL Inspection API를 돌렸다. 모든 신호가 멀쩡했다:

verdict:           NEUTRAL
coverageState:     "Crawled - currently not indexed"
robotsTxtState:    ALLOWED
indexingState:     INDEXING_ALLOWED
pageFetchState:    SUCCESSFUL
googleCanonical:   (허브에서 userCanonical과 일치)
crawledAs:         MOBILE

다시 읽어보자: SUCCESSFUL fetch, ALLOWED robots, INDEXING_ALLOWED — 그런데도 색인 안 됨. 구글이 페이지를 크롤했다. 단지 색인에 둘 가치가 없다고 판단했을 뿐이다.

이 "상승 후 붕괴" 모양은 알려진 패턴이다: 신규 도메인은 탐색 크롤 버스트(구글이 새 사이트맵을 일단 한번 훑음)를 받고, 도메인이 권위를 못 쌓았으면 구글이 색인 쿼터를 회수한다. 페이지들이 "Crawled - currently not indexed" 연옥으로 미끄러진다.

이게 "프로그래매틱 SEO로 페이지 1만 개 찍어라" 글에서 아무도 경고 안 해주는 부분이다: 크롤됨 ≠ 색인됨, 색인됨 ≠ 랭킹. 권위 있는 도메인에서는 대량 페이지가 후한 신뢰를 받는다. 생긴 지 4주 된 도메인에서는, 그냥 솎아내진다.

시도한 것 (그리고 그 값어치)

1. 사이트맵 가지치기 — 크롤 예산 집중.
사이트맵 인덱스에 URL이 약 8,000개였다. 대부분은 노출 0인 얇은 개별 카페 페이지였고, 카테고리/역세권 허브가 사실상 모든 노출을 가져갔다. 그래서 사이트맵을 허브 위주(약 560개, 90%+ 감축)로 줄였다. 카페 라우트는 여전히 존재하고 내부 링크로 크롤 가능하다 — 이건 de-submit이지 de-index가 아니다. 목표: 쥐꼬리만 한 크롤 예산을 8천 개 얇은 페이지에 흩뿌리지 말고, 노출을 버는 소수에 집중시키기.

값어치? 있다. 단 이건 초점 맞추기지 해결책은 아니다.

2. 내부 링크 — 내가 놓친 갭.
가장 권위 높은 페이지(홈/랜딩)가 모든 콘텐츠 기둥에 링크하고 있었다... 그 8,000페이지 지도만 빼고. 전형적인 실수. 정작 핵심 섹션은 사이트 상단에서 들어오는 내부 링크가 0개였다. 고쳤고, 허브 간 크로스링크도 추가했다.

값어치? 진짜로 필요하다(고립된 섹션은 크롤 우선순위를 못 받는다) — 하지만 내부 링크는 외부 권위를 만들지 못한다.

3. canonical 정리.
한 stale 스냅샷에서 루트의 userCanonical(/landing/)과 googleCanonical(/)이 어긋나 있었다. 구글이 추측하지 않게 해소할 가치는 있지만, 본 게임이 아니라 곁다리였다.

4. 내가 계속 바랐던 것: "이거 색인해줘" API.
일반 페이지용은 없다. 구글의 Indexing API는 JobPosting과 BroadcastEvent 구조화 데이터에만 허용된다. 카페 디렉토리에 쓰는 건 정책 위반이고 동작도 안 한다. 진짜 버튼은 GSC UI의 수동 "색인 요청", 하루 약 10건뿐이고, 그것도 크롤을 살짝 유도할 뿐 색인을 보장하지 않는다.

불편한 교훈

기술적 정리를 다 하고 나면, 진단은 지루하고 겸허해진다:

갓 만든 도메인은 물량으로 색인을 뚫을 수 없다. 권위 + 콘텐츠 고유성 + 시간 — 대략 이 순서로 들어간다. 그리고 프로그래매틱 페이지는 고유성 허들을 더 높인다, 낮추는 게 아니라 — 템플릿 콘텐츠는 도메인이 신뢰를 얻기 전까지는 저가치로 읽히기 때문이다.

구체적으로, 실제로 바늘을 움직이는 레버:

외부 editorial 백링크. 이게 진짜 병목이다. 스토어 리스팅 링크 아님(그건 nofollow라 거의 안 넘어감), 같은-회사 크로스 프로모션 아님(구글은 같은 주체가 소유한 사이트 간 링크를 강하게 할인한다). 진짜 사이트에서 오는, 주제 관련성 있는 독립 링크.
템플릿 모양이 아닌 콘텐츠. 고유 데이터, 실제 사진, N번째 페이지를 N+1번째와 구별되게 만드는 무엇이든.
시간. 신규 도메인 "샌드박스"는 실재한다. 다 잘해도 2~6개월 잡아라.
우선순위 페이지 몇 개에 대한 수동 색인 요청 — 치료가 아니라 넛지.

생산적으로 느껴지지만 색인엔 거의 영향 없는 것들: 가짜 lastmod 신선도로 사이트맵 재생성, 핑, 같은 사이트맵 재제출, JSON-LD 더 추가하기. 한 번 제대로 해두고, 그다음엔 그만 만져라.

그래서, 성공했나?

솔직히 — 이 글을 쓰는 지금도 연옥에 있다. 기술 토대는 탄탄하고(그 부분은 내 통제 안에 있다), 권위 작업은 결과를 가르는 느린 노가다다. 위 아키텍처의 라이브 결과가 궁금하면 허브는 여기다: 서울 카공 카페 지도. 몇 달 뒤 다시 와서, 이 부검이 회복으로 바뀌었는지 보자.

프로그래매틱 사이트를 신규 도메인의 벽 너머로 밀어 올려본 적 있다면, 무엇이 결정적이었는지 댓글로 정말 듣고 싶다 — 백링크였나, 콘텐츠 깊이였나, 아니면 그냥 인내였나?

"I built 8,000 programmatic SEO pages. Google indexed zero. A GSC postmortem."

Lucas — Sat, 06 Jun 2026 22:10:21 +0000

Status: this is a live postmortem, not a victory lap. As I write this the site is still at 0 indexed pages. The interesting part isn't the win — it's the diagnosis.

The setup

I run 커피콩 (CoffeeCong), a Korean coffee-rewards app. Alongside it I shipped a programmatic-SEO site: a "workability" map of Seoul cafes — every cafe scored on outlets, Wi‑Fi, seat room, noise, and price, then sliced into ~8,000 server-rendered landing pages:

/coffeemap/area/{district} — 25 districts
/coffeemap/area/{district}/{purpose} — district × 7 purposes
/coffeemap/station/{station} and /station/{station}/{purpose} — ~313 subway stations × purposes
/coffeemap/cafe/{id} — ~6,000 individual cafes

All SSR (Express), each page with a unique <h1>, canonical, JSON‑LD, FAQ, and cross-links. Textbook programmatic SEO.

The crash

Search Console told a brutally clean story:

Sitemaps:   8,653 submitted  /  0 indexed
Impressions: 05-24 → 05-29  ramp to 209/day
             05-30           collapse to ~0   ← and it stayed there

URL Inspection on every sample URL came back the same way:

Hub + category pages → "Crawled — currently not indexed"
Long-tail pages → "Discovered — currently not indexed" (never even crawled)

The reflex is to hunt for a technical bug. I checked all the usual suspects:

Check	Result
robots.txt	`Allow` on all SEO paths
`pageFetchState`	`SUCCESSFUL`
Rendering	Full SSR — `curl` shows the content, not an empty `#root`
Canonical	Self-canonical, consistent
noindex	None — `INDEXING_ALLOWED`

Everything was green. It wasn't a technical problem. That's the trap with this failure mode: nothing is broken, Google just decided the site wasn't worth the index quota.

The real diagnosis

Two things, neither of which a code fix can directly force:

1. New-domain authority (the "sandbox"). A brand-new domain gets a burst of exploratory crawling, then Google reclaims index quota until the domain earns trust. The 05-30 cliff is exactly that reclamation. This is normal and mostly a function of time + backlinks.

2. Thin content at scale. 8,000 templated pages where ~89% are near-duplicates with thin data (a station × purpose with 3 matching cafes) sends a "low average quality" signal. Google samples a few, decides the site isn't worth it, and the whole domain's quota suffers.

The four levers that actually move this

There is no API to force-index general pages — Google's Indexing API is officially JobPosting/BroadcastEvent only. So you're left with levers, not buttons:

1. Concentrate crawl budget (cut thin pages)

Counter-intuitively, the fix for "too many unindexed pages" is fewer pages in the sitemap. I removed the 6,000 individual cafe pages and the 2,191 station × purpose combos from the sitemap index — dropping it from ~8,600 to ~560 high-value URLs:

// Before: every station × every purpose (2,191 thin URLs)
for (const st of stations)
  for (const purpose of PURPOSES)
    urls.push(stationPurposeUrl(st, purpose));

// After: station hubs only (313 substantive URLs)
for (const st of stations)
  urls.push(stationUrl(st));

Key nuance: de-submit ≠ de-index. The routes stay live and crawlable via internal links — I'm just not asking Google to spend budget on them. When authority recovers, the loop comes back.

2. Fix internal linking from your highest-authority page

I found the embarrassing one last: my homepage linked to the cafe map zero times. The footer had links to every other content pillar but not the 8,000-page section. The single most-linked page on the domain was passing no equity to the thing I most wanted indexed. One <a> tag fixed that.

3. Build real backlinks

New domains need trust signals from established ones:

App Store / Play Store listing → site URL (store pages are high-authority and constantly crawled)
Cross-links from sister domains
Content like… this post.

4. Manual "Request Indexing" + time

Search Console's URL Inspection → Request Indexing (~10/day) forces a re-crawl of your strongest pages. It's a nudge, not a guarantee — most effective after the above land. Then: 2–6 months of patience.

Takeaways if you're doing programmatic SEO

Don't submit your whole long-tail on a new domain. Earn quota with a tight, high-value sitemap first, then expand.
"Crawled — not indexed" is a quality/authority verdict, not a bug. Stop grepping your renderer.
Your homepage must link to your money section. Check it. Mine didn't.
De-submit, don't de-index when pruning — keep routes crawlable.
There's no magic button. Plan for months, not days.

The map is live and the pruning just shipped — see the Seoul cafe workability map here. I'll post a follow-up when (if!) the index count moves off zero.

I built my own IAP backend instead of using RevenueCat — what 3 weeks of pain taught me

Lucas — Wed, 06 May 2026 11:36:34 +0000

I'm shipping a subscription-based React Native app and went through the
"do I use RevenueCat or roll my own?" question that probably every solo
RN dev hits. I ended up rolling my own, ran into more edge cases than I
expected, and eventually pulled the working backend into an MIT package.
Sharing the post-mortem in case it saves someone else the same weeks.

Why not RevenueCat

To be clear — RevenueCat is good. For a lot of apps it's the right call.
Two things pushed me off it:

Revenue share scales with you. 1% after $2.5K MRR is fair pricing, but it's a surface I want to own for the lifetime of the product, not rent.
My subscription state lives in their DB. I still need to mirror "user X is subscribed" into my own Postgres to join with the rest of my data, which means I'm running a webhook handler from them either way. Felt like I was paying to add a hop.

So I started writing it myself. Here's where the time actually went.

Where the time went

Apple StoreKit 2 JWS verification (~2 days)

You don't just trust the JWT. You walk the x5c chain in the JWT
header, verify each certificate against Apple Root CA G3, then verify
the JWT signature against the leaf cert's public key. None of the
tutorials I found did the full chain — most just decoded the payload
and hoped.

Google Play Developer API v3 (~1 day)

OAuth2 service account is fine. The non-obvious bit: use
purchases.subscriptionsv2.get — it returns a subscriptionState
enum that maps cleanly to lifecycle states. The v1 API doesn't, and
most Stack Overflow answers still reference v1. Don't infer state from
expiryTimeMillis + cancelReason, just read the enum.

Lifecycle state classification (~3 days)

This is where it got nasty. Apple's DID_FAIL_TO_RENEW with subtype
GRACE_PERIOD vs GRACE_PERIOD_EXPIRED. Google's IN_GRACE_PERIOD,
ON_HOLD, SUBSCRIPTION_PAUSED. I needed an active: boolean for
gating but also the raw state for UX (showing "your card failed but
you still have access" is a legitimately different message than "your
subscription is on hold"). Collapsing both vendor's events into one
state machine took a few rewrites.

The 3-day refund trap

Google auto-refunds any purchase you don't acknowledgePurchase within
3 days. My first version didn't call it. None of the RN tutorials I
followed mentioned it. Lost a handful of test purchases before I
noticed pattern in the dashboard. Subscriptions need acknowledgement
too, not just one-time IAP.

Webhook miss recovery

Apple's App Store Server Notifications V2 are reliable but not
guaranteed. If you miss one, the user's status drifts. Solution:
direct fetch via App Store Server API on /status checks, treat
webhooks as "fast path" not "only path." Same for Google — RTDN can
drop, fall back to subscriptionsv2.get.

What I extracted

Once it was working in production, none of the above was app-specific.
So I pulled it out: github.com/jeonghwanko/onesub

One line:

app.use(createOneSubMiddleware(config));

MIT licensed. Pluggable subscription store (PostgreSQL built-in,
implement the interface for Redis / whatever). Optional RN SDK
(useOneSub() hook + paywall component) but the server works with any
client — Flutter, native, plain fetch.

Honest limitations

No analytics dashboard yet. RevenueCat's actual moat is cohort retention / LTV / experiments, not the receipt validation. There's a self-hosted Docker dashboard but it's operational (active counts, failed webhooks) — not cohort analysis.
No hosted version. You run your own server. If "I want to ship an MVP without running infra" is the goal, RevenueCat still wins.
Apple Family Sharing and Promotional Offers aren't implemented yet.

Things I think turned out interesting

An MCP server is bundled — point Claude Code or Cursor at it and you can say "add a monthly subscription to this Expo app" and it generates the App Store Connect product, the Play Console product, and the client integration. Not the main feature but it's the part that surprised me with how much friction it removed.
296+ tests, including multi-notification e2e scenarios for the lifecycle stuff above. That's where most of the bugs live.

What I'm asking

If you've shipped IAP yourself in RN — what edge case tripped you up
that I haven't listed? Curious if there's a class of bug I haven't
hit yet. Especially interested in hearing from anyone who's dealt with
Family Sharing or upgrade/downgrade chains in production.

Repo: github.com/jeonghwanko/onesub — MIT licensed. Issues and PRs welcome.