Claude Code와 3개월 — 정신없이 만들고, 아무도 안 쓰고, 돌아서 나의 페인 포인트로

2026년 2월 설날, 처음으로 Claude Code를 켰다. CLI 환경이었고, 그 전까지 프로그래밍은 한 줄도 해본 적이 없었다. Andrej Karpathy가 X에 “바이브 코딩(vibe coding)“이라는 단어를 던진 지 꼭 1년이 지난 시점이었다.

그로부터 3개월. 구독을 세 번 결제했고, 한때 며칠 밤을 새우며 해커톤용 서비스 한 개를 빌드했다. 동시에 여러 프로젝트를 굴리며 머리가 감당이 안 될 만큼 만들어보기도 했다. 끝까지 가본 것 한두 개, 그 옆에 토이 프로토타입이나 아이디어만 박아 둔 폴더가 수십 개 쌓였다.

이 글은 그 3개월 동안 모임에서 만난 사람들과 “아 너도? 아 나도”를 주고받으며 발견한 패턴, 그리고 내가 결국 어디로 돌아왔는지에 대한 기록이다. 같은 도구를 같은 시점에 처음 만진 사람들이 거의 같은 순서로 같은 단계를 통과한다.

이게 정말 FOMO일까

요즘 모임에서 가장 자주 듣는 단어가 FOMO(Fear Of Missing Out, 놓치는 것에 대한 두려움)다. 다들 자기 감정을 그 라벨로 부르고 있다. 그런데 정말 그게 맞을까.

FOMO라는 단어는 진단을 너무 거칠게 만든다. 한 단어로 환원하면 처방도 거칠어진다. “안 놓치려면 더 빨리 따라가라” 같은 흔한 결론으로. 그래서 다들 더 만들고, 더 본다. 더 만들수록 더 못 따라가는 것 같고, 더 못 따라갈수록 더 만든다. 자기 강화 루프다.

그런데 나와 주위 사람들이 실제로 느끼는 건 그 한 가지 감정이 아니다.

• 도파민: 코드 한 줄 안 짜본 사람이 며칠 만에 뭔가를 띄운다. 즉각적인 보상이다. 이 보상은 양적이지 않고 질적이다. “할 수 있다”는 감각 자체가 다시 다음 빌드를 끌어낸다.
• 흥분 (excitement): “이걸로 뭘 할 수 있을 것 같다”는 열린 가능성. 가능성은 무한대로 느껴진다. 머릿속에서 아이디어가 발산한다. 출근길에 떠오른 아이디어 하나를 점심 시간에 시작해 저녁에 켜본다.
• 소진 (exhaustion): 터미널 창 여섯 개가 동시에 돌아간다. 그 속도는 내 두뇌가 따라올 수 없고, 두뇌에 쉴 틈을 안 준다. 잠자리에 누워서도 “그 프로젝트 어디까지 했지”가 자동으로 떠오른다. 그런데 이 위에 도파민이 한 번 더 얹힌다. 생각 속도 = 결정 속도 = 구현 속도. 가속이 끊기지 않는 늪이다.
• 이유 있는 불안: 회사에서 직접 느끼지는 않는다. 그런데 모임에 가면 “실리콘밸리는 지금 996(주 6일, 9시–21시)으로 일한다더라” 같은 말이 매번 돈다. 그런 말끝에 고용 시장이 함께 들썩이고, 1년 뒤 무엇이 표준이 될지 모른다는 감각이 객관적 근거로 붙는다. Claude Code가 1년 만에 일반 사용자에게 열렸고, 다시 6개월 만에 연 매출 10억 달러대에 들어섰다는 사실 정도면 그 근거가 약하지 않다.

이 네 가지가 동시에 작동하고 있다. FOMO는 마지막 한 항목의 거친 라벨일 뿐이다. 그것만 보고 처방하면 나머지 세 가지를 놓친다. 도파민에 휘둘려 만들기만 하고, 흥분에 휘둘려 발산만 하다 소진된다. 정작 “이유 있는 불안”은 진단의 대상이 아니라 처방의 대상이어야 하는데, 한 라벨로 묶이는 순간 그 구분이 사라진다.

그래서 이 글에서는 FOMO라는 단어를 잠깐 내려놓고, 그 안에 섞여 있는 감정과 패턴을 따로 들여다본다. 각각의 감정에는 각각의 처방이 있다.

모임에서 만난 ‘아 너도?’

3개월 동안 들은 모임 대화 중 가장 자주 반복된 모먼트를 정리하면 다음과 같다.

시나리오	본인 시작	상대방 반응
코딩 에이전트 턴어라운드 시점 아하	”예전엔 AI가 다 해줄 줄 알았는데 안 됐잖아요. 작년 말부터 갑자기 되더라고요."	"맞아요, 그때 처음 ‘아하’ 했어요.”
슬롭 제조기 단계	”해보고 싶은 거 다 만들어 봐요. 진짜 막 찍어내요."	"맞아, 어제까지 어떤 프로젝트인지 헷갈렸어요.”
사용자 부재	”근데 사람들이 안 오는 거예요."	"어… 나는 그래서 다른 거 만들었어요.”
본인 페인 회귀	”결국 내가 매일 쓰는 걸 깊게 파서 만들었어요."	"오, 나도요. 만족도가 다르더라고요.”
학습 루프 부재	”처음에는 좋았는데 일주일 만에 안 켜게 되더라고요."	"그게 학습이 없어서 그래요.”

처음에는 우연이라고 생각했다. 두 번째 같은 대화가 오갔을 때는 “음, 분야가 비슷해서 그런가” 싶었다. 다섯 번째쯤에서 패턴이라는 사실이 자명해졌다.

흥미로운 부분은 시작 시점이다. 다들 “한 6개월 됐다”는 식으로 말한다. 처음에 나도 그런 줄 알았다. 세어 보면 그렇지 않다.

Karpathy의 트윗이 2025년 2월에 올라왔다. 본인 표현으로 “shower of thoughts throwaway tweet”이었지만 4백만 뷰를 넘었다. 그로부터 약 3개월 뒤인 2025년 5월에 Claude Code가 일반 사용자에게 열렸다. 비전공자가 안정적으로 진입할 수 있는 환경이 만들어진 시점이다. 내가 처음 켠 게 2026년 2월 설날이었고 오늘이 5월이다. 구독 결제 영수증이 세 장 쌓였으니 꼭 3개월차다.

“6개월”이라고 말하는 사람들의 체감은 실제 캘린더가 아니다. 한 분기 안에 동시 빌드, 사용자 부재, 페인 포인트 회귀까지 통과하면 시간 감각이 늘어난다. 그 안에서 일어난 변화의 밀도 때문이다. 1년에 일어났어야 할 학습이 3개월에 압축되어 들어오면 체감 시간도 그만큼 늘어난다.

모임에서 만난 사람들의 직군도 다양했다. 마케터, PM, 디자이너, 컨설턴트, 변호사, 카페 사장, 인사 담당, 데이터 분석가. 공통점은 코드를 직업으로 짜지 않는다는 점 한 가지였다. 모임에는 개발자도 섞여 있지만, “아하”의 폭은 비전공자 쪽에서 훨씬 컸다. 그런데도 거의 같은 단계를 거의 같은 순서로 통과하고 있었다. 직군이 다른데 시퀀스가 같다는 건 사람이 아니라 도구가 시퀀스를 만든다는 신호다.

최근 모임에서 자주 보이는 변화 한 가지는, 본인이 필요한 specific한 것을 만들어 쓰기 시작한 사람들이 눈에 띄게 늘어나고 있다는 점이다. “남이 쓸 SaaS”가 아니라 “본인 한 명이 매일 켜는 도구”로 만드는 사람들이 모임마다 한두 명씩 늘어난다. 다들 마지막 단계에 도착하고 있다는 신호다.

한 가지 짚을 점

같은 시간대에 같은 도구를 처음 만지면, 같은 단계를 같은 순서로 거치게 된다. 도구가 시퀀스를 강제하기 때문이다. 이건 개별 의지의 문제가 아니라 도구의 affordance 문제다. 비전공자가 일주일 안에 동작하는 무언가를 띄울 수 있다는 사실이 슬롭 제조 단계를 강제하고, 그 결과물에 사용자가 안 온다는 사실이 사용자 부재 단계를 강제한다. 이 두 단계를 정직하게 통과한 사람만 자기 페인 회귀에 도착한다.

다들 거치는 4단계

내가 발견한 패턴은 다음 4단계다. 이 순서가 거의 그대로 반복된다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    A["1단계 — 아하 모먼트<br>코딩 에이전트 턴어라운드"] --> B["2단계 — 슬롭 제조기<br>막 찍어내기"]
    B --> C["3단계 — 사용자 부재<br>페인 포인트 부재"]
    C --> D["4단계 — 자기 페인 회귀<br>진짜 다음 가설"]
    D -.->|새 사이클| A

1단계 — 아하 모먼트

2024년 말부터 2025년 초까지의 짧은 turn-around가 있었다. 그 전까지는 “AI가 다 해줄 줄 알았는데 막상 시켜보면 안 해줬던” 시기였다. 그 시기가 끝나는 순간, 코딩 에이전트가 갑자기 통하기 시작했다. 모임에서 이 시기를 지나간 사람들은 한결같이 “그때 처음 ‘아하’ 했다”고 말한다.

“아하”는 단순한 감탄이 아니다. “코드를 짤 줄 모르는 내가 뭔가를 띄울 수 있다”는 발견이다. 이 발견은 짧지만 다음 단계를 강제로 끌어낸다. 한 번 발견하고 나면 다음 행동은 자동으로 이어진다.

2단계 — 슬롭 제조기

아하 직후의 단계다. 해보고 싶은 아이디어를 전부 만들어 본다. 진짜 막 찍어낸다. 한 개를 끝내고 다음 개를 시작하는 게 아니라 여러 개를 동시에 굴린다. 어느 프로젝트가 어떤 상태인지 머리에서 섞인다. Claude Code 세션을 열다가 어느 디렉토리에서 무슨 작업을 하던 중이었는지 잊기 시작한다.

내 경우 며칠 밤을 새우며 해커톤용 서비스 한 개를 빌드한 게 이 단계의 정점이었다. 결과물 자체보다 “내가 이 기간 안에 뭔가를 띄울 수 있다”는 행동 가능성의 확장이 더 컸다. 그 사이 워크스페이스에는 토이 프로토타입과 아이디어 폴더가 수십 개 쌓여 갔다.

이 단계가 위험한 건 행동 패턴이 너무 빨리 굳는 점이다. “한 번 켜보자”가 매번 새 디렉토리, 새 프로젝트로 이어진다. 일주일 만에 워크스페이스에 폴더 열 개가 생기고, 다시 일주일 뒤에 스무 개가 된다. 각각의 폴더는 며칠 단위로 멈춰 있다가 다시 잠깐 켜졌다가 또 멈춘다. 사실상 완결된 게 하나도 없는 상태로 한 달이 지난다.

2단계의 핵심 비용은 아이디어가 아니라 컨텍스트 부하다. 여러 개 동시 빌드는 잠자리에 누워서도 “그 프로젝트는 어디까지 했지”가 자동으로 돌아가게 만든다. 능력 발견 자체는 며칠이면 끝나는데, 슬롭 제조 행동 패턴은 그보다 훨씬 오래 남는다. 그게 2단계를 길게 만든다.

3단계 — 사용자 부재, 페인 포인트 부재

만들어 놓고 기다린다. 내가 보기에는 누군가가 와서 볼 것 같고, 쓸 것 같고, 살 것 같다. 그런데 아무도 안 온다.

이 시점에서 다들 같은 사실을 알아챈다. 내가 “필요할 것 같다”고 짐작한 것과 다른 사람이 실제로 돈을 내거나 시간을 쓸 만큼 필요로 하는 것은 다르다. 페인 포인트(pain point)를 정확하게 잡지 못한 채 가설부터 코드로 옮긴 결과다.

기획·창업의 기본기인데, 만들어보고 나서야 체감으로 알게 된다. 책으로 읽은 페인 포인트와 직접 만들어 놓고 사용자가 안 와본 페인 포인트는 다른 종류의 학습이다. 후자는 며칠 동안 새로고침을 누르며 “지표가 안 움직이네”라는 사실을 직시한 사람만 얻는다.

이 단계에서 자주 보이는 회피 패턴이 두 가지 있다.

• 마케팅 핑계: “사람들이 모르니까 안 오는 거지.” 마케팅 전에 페인 포인트가 있었는지를 확인할 책임을 미룬다. 페인이 있고 마케팅이 없는 경우라면 적어도 베타 유저 두세 명은 알아서 들어와야 한다. 그게 없으면 마케팅 문제가 아니라 페인 문제다.
• 다음 프로젝트로 도망: “이건 이 정도. 다음 거 만들자.” 같은 가설 설정 패턴으로 2단계로 돌아간다. 결과는 같다. 다섯 개를 더 만들어도 다섯 번 다 사용자가 안 오는 경험을 한다.

이 두 패턴을 피하고 3단계를 정직하게 통과한 사람만 4단계로 넘어간다. 정직하게 통과한다는 건 “내가 가설한 페인이 실제 페인이 아니었다”는 사실을 받아들이는 일이다. 자존심 비용이 크다.

4단계 — 자기 워크플로우 회귀

그래서 다들 한 번 멈춘다. 그리고 다음 질문으로 옮긴다.

“내가 매일 실제로 겪는 불편함은 뭐지?”

이 질문이 다음 단계를 연다. 남이 필요할 거라고 짐작하는 게 아니라, 내가 매일 30분씩 빼앗기고 있는 일을 들여다본다. 그 안에서 진짜 다음 빌드의 가설이 나온다.

이 단계의 특징은 작아지는 것이다. 1·2단계의 야망(시장 잡기, 누구나 쓰는 도구 만들기)에서 한 단계 내려와 본인 페인을 정밀하게 보는 일에 집중한다. 결과적으로 만드는 도구의 크기도 작아진다. 누구나 쓰는 거대 SaaS 아이디어 대신 본인 한 명이 매일 30분 절약하는 워크플로우 한 개. 단 그 한 개의 정밀도는 2단계 결과물보다 훨씬 높다.

작아지는 게 야망의 후퇴는 아니다. 2단계의 다섯 개 프로젝트는 모두 평균 사용자를 가설했지만 평균 사용자가 한 명도 안 들어왔다. 4단계의 한 개 프로젝트는 본인 한 명을 정확하게 가설했고 본인이 매일 켠다. 사용자 0과 사용자 1의 거리는 1과 100의 거리보다 멀다. 그 첫 한 명을 본인으로 가설하는 게 4단계의 출발선이다.

한 가지 짚을 점

이 4단계는 어떤 의지나 학습 순서가 아니라, 능력의 폭발과 페인 발견의 시차에서 자연스럽게 생긴다. 만들 수 있는 능력이 먼저 폭발하고, 페인을 식별하는 능력은 천천히 따라온다. 그래서 1·2단계가 먼저 오는 게 일반적이다. 1·2단계를 건너뛰고 4단계로 가려고 하면 오히려 페인을 다시 책 속의 페인으로 만들 위험이 있다. “내가 안 만들어봐서 사용자 부재의 무게를 모른다”는 상태로 페인을 가설하면 같은 함정에 빠진다.

내 케이스 — 뉴스 수집 자동화

4단계로 돌아온 내가 처음 손댄 게 뉴스 수집 자동화다. 매일 아침 IT·AI 뉴스를 한 통으로 받는 워크플로우.

이 작업을 사람들에게 말하면 반응이 비슷하다. “그거 쉽지 않아?” “RSS 받아서 LLM에 요약 시키면 되잖아.”

겉으로 보면 그렇다. 그런데 막상 본인 페인을 정밀하게 들여다보면 그 단순한 그림은 다섯 군데에서 깨진다. 그 깨지는 자리들이 워크플로우 단계가 된다.

페인 포인트를 정확하게 본다

문제는 “뉴스를 자동으로 받기”가 아니다. 내가 실제로 매일 겪던 불편은 다음 세 가지였다.

1. 한 디바이스 의존: 갤럭시 크롬의 추천 콘텐츠가 나에게 너무 잘 최적화되어 있다. 다른 디바이스나 브라우저로 가면 그 추천이 사라진다. 그래서 출근길에 그 화면을 보는 5분이 매일의 정보 입력 창구가 되어버렸고, 그게 빠지는 날은 종일 정보 결핍 상태로 일하게 된다.
2. 겉의 뉴스와 한 겹 아래 뉴스: “IT·AI 뉴스”라는 말로는 부족하다. 내가 실제로 클릭하는 건 일반 헤드라인이 아니라 그 아래 한 겹 더 내려간 곳에 있는 개인 블로그, Hacker News, Reddit의 특정 채널이다. 같은 주제라도 헤드라인은 흥미를 끌고 한 겹 아래는 실제 결정에 쓸 만한 정보가 있다.
3. 개인 큐레이션 vs 일반 큐레이션: 일반 뉴스레터는 평균 독자를 위한 것이다. 내 작업 컨텍스트(AI 전략, 사업 컨설팅, 자동화)에 맞춰진 큐레이션은 시중에 없다. 시중 뉴스레터를 일주일 보면 70%가 내 작업에 안 쓰이는 정보다.

이 셋을 한 줄로 합치면 페인은 “내가 자주 보는 30개 안팎의 한 겹 아래 소스에서, 매일 새로운 것만, 내 컨텍스트에 맞춰서, 한 통으로”가 된다. 이 한 줄이 워크플로우의 모든 결정을 끌어내는 출발선이다.

워크플로우 구조

이 페인을 다음 6단계로 풀었다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TB
    A["① 소스 큐레이션<br>35 sources · 5 카테고리"] --> B["② 다중 카테고리 병렬 수집<br>매일 04:00 KST + 06:00 safety-net"]
    B --> C["③ 수집 dedup<br>URL · 제목 prefix · 토픽 단어 overlap"]
    C --> D["④ 날짜 cutoff<br>소스별 1–3일"]
    D --> E["⑤ 큐레이션 LLM<br>05:15 KST · 60–80건 → 20건"]
    E --> F["⑥ 학습 루프 + 제보<br>좋아요·싫어요 → 룰 수정"]
    F -.->|주기적 확장| A

각 단계에서 만난 디테일은 다음과 같다.

1. 소스 큐레이션 — 루틴부터 다시 본다

루틴부터 다시 봤다. “내가 평소에 어디서 뉴스를 보는가”를 시간 단위로 적었다. 출근길 5분 (갤럭시 크롬 추천), 오전 작업 시작 전 10분 (Hacker News 메인), 점심 후 5분 (Reddit 특정 채널), 저녁 작업 끝 무렵 10분 (관심 분야 개인 블로그). 총 30분.

핵심 발견은 갤럭시 크롬 추천 화면이 이미 나에게 한 번 최적화되어 있다는 사실이었다. 그 화면에서 내가 클릭하는 글의 패턴을 추렸더니 35개 안팎의 소스가 나왔다. 일반 미디어보다 개인 블로그, 사례 블로그, Hacker News 토픽, Reddit의 특정 서브 채널 비중이 높았다.

이 35개를 fetch 방식 기준으로 다섯 카테고리로 정리했다. RSS · Atom 피드, Hacker News(Algolia 검색 API), 웹 스크레이핑(정적 페이지 cheerio + selector), Reddit 서브 RSS, 그리고 Tavily 검색 API. 카테고리 구분은 페인 분류가 아니라 어떤 모양으로 데이터를 가져오느냐의 차이에서 나왔다.

2. 다중 카테고리 병렬 수집

35개 소스를 한 가지 방식으로 가져오려면 깨진다. 각 카테고리의 fetch 모양이 다르기 때문이다. 그래서 다섯 카테고리를 매일 한 번 병렬로 호출한다.

• RSS · Atom 피드: cheerio로 XML 파싱, pubDate 또는 published에서 발행일 추출.
• Hacker News: Algolia search API에 키워드 쿼리, 24시간 이내 story만 가져온다.
• 웹 스크레이핑: 정적 페이지에 cheerio + selector로 제목·링크 추출.
• Reddit: 서브레딧 hot.rss로 entry 파싱. [D]·[P] prefix 글은 자동 제외 (discussion·project post는 큐레이션 대상 아님).
• Tavily Search: 사전 정의된 쿼리와 도메인 화이트리스트로 advanced 검색 (days=2).

스케줄은 매일 04:00 KST 메인 수집, 06:00 KST safety-net 재확인이다. 1시간 단위 크론은 비용·중복 모두 과다하다. 하루 한 번 새벽에 받고, 빠지면 06시에 한 번 더 시도하는 게 운영적으로 충분하다. 실제로 2026-04-08에 node-cron이 WSL2 idle suspend에서 04시 tick을 놓치는 사고가 있었고, 그 이후 06시 safety-net이 추가됐다.

수집 단계의 원칙은 다섯 카테고리 모두 결정론적이라는 점이다. Tavily가 LLM 기반 검색이긴 하지만 쿼리와 도메인 화이트리스트가 고정되어 있어서 같은 입력에 같은 결과가 나온다. LLM이 들어오는 자리는 수집이 아니라 큐레이션 단계(5단계)다. 이 구분을 흐리면 수집 비용이 잡히지 않고, 같은 입력에 다른 출력이 나오는 빈도가 늘어난다.

3. 수집 dedup — URL · 제목 prefix · 토픽 단어 overlap

35개 카테고리에서 같은 사건이 다섯 번 들어오는 경우가 흔하다. 그래서 수집 직후 한 번에 dedup한다. 세 단계 비교다.

1. URL 정규화 — query string·fragment 제거, 끝의 / 정리 후 완전 일치. 같은 글의 추적 파라미터 차이를 제거한다.
2. 제목 prefix — 한글·영문·숫자 외 글자를 떼고 소문자 60자 prefix가 일치. 같은 매체가 두 번 색인한 케이스를 제거한다.
3. 토픽 단어 overlap — 4글자 이상, stop words 제외한 단어가 3개 이상 겹치면 중복 처리. 다른 매체가 같은 사건을 다룬 케이스를 묶는다.

세 번째 단계가 cross-source dedup의 본체다. 보통은 description이 붙어 있는 쪽을 남기고 나머지는 합친다. 임베딩 모델은 안 쓴다. 35건 카테고리 합산 100건 안팎 규모에서는 string + token overlap이 비용 대비 충분히 정확하다. 임베딩을 쓰면 추가 호출 지연이 생기고, 캐시 만료 정책까지 운영 영역이 늘어난다.

이 한 단계만으로 받는 글 수가 일반적으로 80–150건에서 60–80건으로 떨어진다. 줄어든 만큼 남은 글의 신호 농도가 올라간다.

4. 날짜 cutoff — 카테고리마다 다르다

수집 자체가 오늘 글만 가져오면 좋겠지만, 각 카테고리가 오래된 글을 섞어 보낸다. 그래서 카테고리별로 cutoff를 둔다.

카테고리	Cutoff	적용 위치
RSS · Atom	3일 (lenient)	클라이언트 필터, 발행일 없는 entry는 통과
Hacker News	24시간	Algolia API numericFilters=created_at_i>
Reddit	3일	클라이언트 필터, entry.updated 기준
Tavily	2일	API 파라미터 days=2

RSS·Reddit의 lenient 정책은 의도적이다. 발행일을 못 찾은 글을 무조건 자르면 일부 RSS 피드의 모든 entry가 떨어진다. 짧은 cutoff에서 일부 노이즈를 받는 게 긴 cutoff에서 좋은 글을 놓치는 것보다 낫다.

이 cutoff 판정을 LLM에 맡기지 않는 게 핵심이다. 큐레이션 LLM은 “오늘 뉴스만 줘”라는 지시를 자주 깬다. 학습 컷오프가 지나간 뒤의 날짜 추론이 약하고, 메타데이터 발행일을 본문 추측으로 덮어쓴다. 한 번은 한 달 전 글이 “오늘 발행”으로 표기되어 워크플로우에 들어왔고, 그게 같은 주제로 또 다른 매체에서 새로 다뤄지면서 중복 필터까지 통과한 적이 있다. 그래서 날짜 판정은 결정론 파이프라인의 책임, 의미 선별은 큐레이션 LLM의 책임으로 명확히 갈라 두었다.

5. 큐레이션 — LLM이 처음 들어오는 자리

수집·dedup·cutoff까지가 결정론 파이프라인이다. 그다음 단계가 의미 단위 큐레이션이고, 여기서 LLM이 처음 들어온다.

매일 05:15 KST에 별도 LLM 작업이 돈다. 입력은 daily_news_raw의 오늘 행 (dedup·cutoff 후 보통 60–80건), 출력은 daily_news의 20건 + 종합 헤드라인 한 줄이다. 선별 룰은 다음과 같다.

• 우선순위 6단계: 신규 모델·벤치마크 → 방법론·에이전트 → 도구·프레임워크 → 프로덕트·펀딩 → 산업·규제 → 컨설팅 보고서 (발행 14일 이내만).
• 소스 균형: 한 소스 최대 3건, 한 토픽 키워드(OpenAI, Claude, Gemini, Meta 등) 최대 3건.
• Cross-day fatigue: 직전 2일 같은 키워드가 2건 이상이었다면 오늘 최대 1건으로 제한 — 같은 토픽으로 독자가 지치는 패턴을 코드 레벨에서 차단.
• Cross-day dedup: 직전 14일 daily_news에 이미 들어간 URL은 자동 제외.
• 작성 룰: 헤드라인은 인과형(2–3 고유명사 + WHY), “등” 나열 금지. 각 항목 한국어 3 bullet, 50자 이상 완성문, 수치·before→after·HOW 메커니즘 중 둘 이상 등장.

저장 직전 jq 파이프로 lint를 한 번 더 돈다. 20건인지, 소스·토픽 최대 3건인지, 모든 bullet 50자 이상인지. 한 줄이라도 깨지면 그 자리에서 LLM에 재작성을 요청한다.

LLM을 한 줄짜리 파이프 단계로 두지 않고, 이런 dedup·균형·lint 룰을 명시적으로 박는 게 운영의 핵심이다. “LLM에 다 맡긴다”는 그 자체로 통제력 상실이다. 큐레이션 결과는 그날 받는 한 통의 본문이 된다.

6. 학습 루프 + 미수집 제보

받아본 글마다 “이건 진짜 좋은데”와 “이런 건 굳이 안 받아도 되는데”가 갈린다. 이 감각을 흘려보내지 않으려고 좋아요·싫어요 버튼을 한 통의 끝 1급 위치에 박았다. 한 단계 안에 있어야 누른다.

• news_feedback 테이블: 항목별 rating(up · down) + 자유 코멘트.
• news_feedback_weekly 뷰: 날짜별 thumbs_up · thumbs_down · approval_rate.
• 주기적으로 approval_rate가 낮은 날의 코멘트를 모아 5단계 큐레이션 프롬프트와 1단계 소스 카테고리를 손본다. 최근 다운보트로 “Outdated”가 반복되면 어나운스먼트 항목의 작성 룰에 “이전 버전 대비 구체 변화·출시일·벤치마크 중 하나 이상 필수” 같은 조건이 추가되는 식이다.

미수집 제보도 별도 채널 없이 이 학습 루프에 통합되어 있다. “이건 들어왔어야 하는데”라는 코멘트가 들어오면 다음 라운드에서 1단계 소스 카테고리에 추가하거나 검색 쿼리를 조정한다. 시스템이 시간이 갈수록 더 좋아지는 방향으로 움직인다. 이 채널이 없으면 워크플로우는 첫날의 35개 소스에 고정되고, 새로운 영역(예: AI 안전, 정부 정책)으로 관심이 확장될 때 그게 자동으로 반영되지 않는다.

결정적 trade-off 세 가지

이 워크플로우를 다른 사람에게 그대로 권할 수 있는가. 답은 “그대로는 아니다”이다. 세 가지 trade-off에서 갈린다.

Trade-off	한쪽 끝	다른 끝	내 선택
일반성 vs 개인화	평균 독자용 뉴스레터	본인 컨텍스트 전용 큐레이션	후자 (재사용성 양보)
풀 LLM 파이프 vs 결정론 + LLM 분리	LLM이 수집·필터·요약 다 함	수집·dedup·cutoff는 결정론, 큐레이션만 LLM	후자 (비용·재현성)
즉시 사용 가능 vs 학습 루프 운영	발행 즉시	좋아요·싫어요 누적 후 갱신	후자 (정밀도가 시간에 따라 강해짐)

내 선택의 공통점은 하나다. 단기 효율을 양보해서 장기 정밀도를 얻는다. 본인이 매일 쓰는 워크플로우는 일반화하지 않을수록 가치가 올라가는 경우가 많다. 일반화는 다른 사람들과 평균을 맞추는 일이고, 매일 쓰는 도구는 평균이 아니라 본인 한 명의 패턴에 맞아야 한다.

한 가지 짚을 점

뉴스 수집 자동화처럼 “쉬워 보이는” 자동화일수록 본인 페인이 얼마나 깊은지에 따라 결과가 갈린다. 겉만 자동화하면 겉만큼만 잘 정리된다. 페인을 정밀하게 본 다음 자동화하면 본인 외에는 못 쓸 만큼 잘 맞는 도구가 나온다.

후자가 일반화 가능한 SaaS가 되는 경로는 한 단계 더 떨어져 있다. 그래도 본인 페인이 깊어진다는 사실 자체가 다음 빌드의 진짜 가설이 된다. 같은 도메인을 매일 쓰는 사람 100명을 인터뷰하는 것보다 본인 워크플로우 하나를 깊이 들여다보는 게 시간 단위 학습 효율이 더 높은 경우가 많다.

회귀 신호 — 한 줄로 정리하면

3개월 동안 모은 관찰을 한 줄로 합치면 이렇다.

“FOMO처럼 보이는 감정은 사실 회귀 신호다.”

처음에는 다 따라잡아야 할 것 같다. 그래서 만든다. 만들면서 페인 포인트의 부재를 알아챈다. 페인이 없는 곳에 만들었던 사람은 다시 자기 페인으로 돌아온다. 자기 페인으로 돌아온 사람은 그 페인을 정밀하게 들여다보기 시작한다. 거기서 진짜 다음 가설이 나온다.

이 흐름이 만약 도구가 강제하는 시퀀스라면, 1단계를 굳이 부정할 이유는 없다. 다만 1단계에 너무 오래 머무는 건 비용이 크다. 동시 빌드 다섯 개의 머리 부하는 실제 부하다. 그 부하는 휴식으로 풀리는 종류의 피로가 아니다. 컨텍스트 비용이라서 동시 빌드 개수를 줄여야만 풀린다.

세 가지 운영 원칙으로 압축할 수 있다.

1. 1·2단계는 짧게: 아하는 자동으로 오므로 운영 대상이 아니지만, 슬롭 제조는 며칠에서 몇 주면 충분하다. 동시에 다섯 개를 굴리고 있는 시점이 멈출 신호다. 그 이상은 능력 발견이 아니라 회피다.
2. 3단계는 솔직하게: 사용자가 안 오면 사용자가 안 오는 것이다. “마케팅을 안 해서”라는 변명으로 3단계를 회피하면 4단계로 못 간다. 페인 포인트가 정확했는지 본인에게 물어야 한다. 베타 유저 두세 명 모집 시도까지는 마케팅 전이라도 가능하다.
3. 4단계는 깊게: 본인 페인을 들여다보는 깊이가 다음 가설의 깊이를 결정한다. 뉴스 수집 자동화가 여섯 단계로 쪼개지는 이유다. “쉬워 보이는” 자동화를 정밀하게 풀면 그 안에 본인 도메인의 메커니즘이 다 들어 있다.

이 세 원칙을 1주짜리 회고 루틴으로 굴리면 패턴은 일주일에 한 번 점검할 수 있다. 첫째 주에 2단계가 길어지지 않았는지, 둘째 주에 3단계에서 회피하지 않았는지, 셋째 주에 4단계가 깊어지고 있는지. 회고 자체도 무겁게 만들 필요 없다. 일요일 저녁 10분이면 충분하다.

요즘 모임에서 “아 너도?”를 주고받을 때, 우리가 사실 확인하고 있는 건 두려움이 아니다. 같은 도구의 같은 시퀀스를 같은 순서로 통과하고 있다는 사실을 서로 확인하고 있는 것이다. 그게 FOMO보다 더 적절한 라벨이다.

3개월이 지난 지금, 나는 2단계의 슬롭 폴더 수십 개 중 살아남은 한 개를 매일 켜고, 그 한 개의 학습 루프 누적치가 50개를 넘는 변곡점을 통과하고 있다. 다음 빌드의 가설은 그 학습 루프 안에서 자라고 있다. 그게 회귀 신호가 알려준 다음 길이다.

---

Sources

• Andrej Karpathy, “There’s a new kind of coding I call ‘vibe coding’…” X (Twitter), 2025-02-02
• “Claude Code was released for general use in May 2025.” Hacker News thread, 2025