한 분이 4시간 33분 만에 1,000만원을 넘겼다는 글을 봤습니다. 어떻게 판 건지 궁금해서 그 시리즈 글 22개를 전부 뜯었습니다. 수집과 분석은 제가 쓰는 브라우저 에이전트 Aside가 했습니다. 나온 숫자 하나와 그게 뜻하는 구조를 적습니다.
왜 직접 세어보기로 했나요?
결과 숫자만 보면 배울 게 없기 때문입니다. "4시간 33분에 1,000만원"은 결과이고, 제가 알고 싶은 건 그 앞에 뭐가 있었는지였습니다.
보통 이런 성과를 보면 두 가지 반응이 나옵니다. 대단하다고 하고 넘어가거나, 나는 안 될 거라고 하고 넘어가거나. 둘 다 아무것도 안 남습니다.
저는 세 번째를 골랐습니다. 글을 전부 세어보는 것입니다. 시리즈 글이 공개되어 있으니 세는 건 가능합니다.
문제는 제 조건이었습니다. 저는 손을 쓸 수 없어서 침대에 누워 스마트폰을 입술로 눌러 컴퓨터를 조작합니다. 글 22개를 하나씩 열어서 지표를 옮겨 적는 건 저한테 현실적으로 불가능한 작업량입니다.
그래서 어떻게 했나요?
수집과 분석을 에이전트에 맡겼습니다. Aside에 `ulw-research` 스킬을 달아두면 계정 하나를 통째로 전수 분석합니다.
제가 한 일은 무엇을 알고 싶은지 정하는 것이었습니다. 실제로 22개를 열고 지표를 모으고 정렬하는 건 에이전트가 했습니다.
이게 제가 AI를 쓰는 방식의 핵심입니다. 저는 클릭이 비싼 사람이라 반복 조회 같은 건 직접 못 합니다. 대신 무엇을 물을지는 정할 수 있습니다. 그 둘을 나누면 일이 됩니다.
숫자 하나만 먼저
체인 시작점은 조회 12만이었습니다. 그런데 판매 글 앞에서는 1.4만이 됐습니다.
그리고 판매는 그 1.4만에서 나왔습니다.
| 지점 | 조회 |
|---|---|
| 체인 시작 | 120,000 |
| 판매 글 직전 | 14,000 |
비율로 보면 구조가 정확히 무료 12 : 판매 1입니다.
이 비율이 왜 중요한가요?
판매가 판매 글 하나로 일어난 게 아니라는 뜻이기 때문입니다. 앞에 무료로 깔린 12만큼이 있어야 뒤의 1이 성립합니다.
많은 사람이 이 부분을 거꾸로 합니다. 판매 글을 잘 쓰려고 합니다. 카피를 다듬고 가격을 조정합니다.
그런데 이 데이터가 말하는 건 다릅니다. 판매 글 앞에 얼마나 데려왔느냐가 먼저입니다. 1.4만이 안 오면 판매 글이 아무리 좋아도 대상이 없습니다.
그리고 12만에서 1.4만으로 줄어드는 것도 실패가 아닙니다. 줄어드는 게 정상이고, 그 비율을 알고 설계하느냐가 차이입니다.
전수 분석이 아니면 안 보이는 것
이 구조는 글 하나만 봐서는 절대 안 보입니다. 판매 글만 보면 "이 글이 잘 팔렸다"로 끝납니다.
22개를 순서대로 놓고 조회 흐름을 이어봐야 깔때기 모양이 보입니다. 그래서 전수가 필요했습니다.
일부만 보면 결론이 반대로 나올 수도 있습니다. 중간에 조회가 튀는 글이 있으면 그걸 성공 요인으로 착각하게 됩니다. 전체를 봐야 그게 흐름의 일부인지 예외인지 구분됩니다.
왜 이런 분석을 남에게 공개하나
숫자를 공개하면 손해라는 말을 듣습니다. 저는 반대로 봅니다.
이 분석에서 나온 12 대 1이라는 비율은 제 것이 아닙니다. 남의 계정에서 나온 값이고, 저는 그걸 세었을 뿐입니다. 세는 방법 자체는 누구나 할 수 있습니다.
그래서 감추는 게 의미가 없습니다. 감춰야 할 건 방법이 아니라 실행인데, 실행은 감춘다고 남이 못 하는 게 아닙니다.
그리고 저는 이걸 공개하면서 하나 더 얻었습니다. 제가 어떤 방식으로 일하는지를 보여주는 사례가 됩니다. 손을 못 쓰는 사람이 22개짜리 전수 분석을 했다는 것 자체가 제 작업 방식의 증거입니다.
결과를 감추면 그 증거도 같이 사라집니다. 저한테는 그게 더 손해입니다.
정리하면
- 결과 숫자만 보면 배울 게 없습니다. 앞 단계를 세어야 합니다.
- 판매 글 앞에 깔린 무료 분량이 실체입니다. 이 사례는 12 대 1이었습니다.
- 조회가 줄어드는 건 정상입니다. 줄어드는 비율을 알고 설계하는지가 다릅니다.
- 전수로 봐야 구조가 보입니다. 일부만 보면 예외를 법칙으로 착각합니다.
이 방식이 유효한 다른 경우
전수 분석은 이 사례에만 쓰는 게 아닙니다. 저는 같은 방식을 제 계정에도 씁니다.
예를 들어 제 글을 여는 방식별로 나눠 조회 중앙값을 세어본 적이 있습니다. "만들었다"로 연 글은 207, 사건으로 연 글은 940이었습니다. 4.5배 차이입니다.
이런 건 감으로는 절대 안 나옵니다. 세어야 나옵니다. 그리고 세는 건 지루한 반복 작업이라 사람이 잘 안 합니다.
그래서 이 조합이 강합니다. 사람은 무엇을 셀지 정하고, 에이전트는 세는 일을 합니다. 저처럼 조작 비용이 큰 사람에게는 특히 그렇습니다.
발견 전부는 따로 정리했습니다
여기 적은 건 숫자 하나입니다. 22개를 뜯으며 나온 나머지는 제 책 5장 "윤자동 2대 시리즈 전수 해부"에 담았습니다.
수록은 본인에게 허락받았습니다. 남의 계정을 분석해 공개하는 일이라 그 절차를 먼저 밟았습니다.
구조는 정확히 무료 12 : 판매 1. 그 1.4만에서 판매가 나왔다.
이 한 줄이 제가 22개를 뜯어서 얻은 전부이자 핵심입니다. 나머지는 이 문장을 뒷받침하는 근거들입니다.
받은 질문
Q. 남의 계정을 분석해도 되나요?
공개된 글의 공개 지표를 세는 것이라 수집 자체는 가능합니다. 다만 정리해서 유료로 싣는 건 별개라, 본인 허락을 받았습니다.
Q. 12 대 1이 모든 계정에 적용되나요?
아닙니다. 이건 한 계정, 한 시리즈에서 나온 값입니다. 다만 자기 계정에서 같은 방식으로 재보는 건 누구나 할 수 있습니다.
Q. 손을 못 쓰는데 어떻게 22개를 봤나요?
직접 열지 않았습니다. 무엇을 볼지 정하고 수집은 에이전트에 맡겼습니다. 저는 결과를 판단하는 쪽을 맡았습니다.
Q. 분석에 얼마나 걸렸나요?
제가 직접 했다면 며칠짜리 작업이었을 겁니다. 그래서 애초에 시도하지 않았을 일이기도 합니다.
남은 이야기
저는 이 분석에서 판매 기법보다 제 작업 방식을 더 배웠습니다.
손을 못 쓴다는 건 "할 수 있는 일이 적다"가 아니라 "직접 손댈 수 있는 일이 적다"는 뜻입니다. 그 둘은 다릅니다.
직접 손댈 수 없는 일은 맡기면 됩니다. 대신 무엇을 맡길지, 결과가 맞는지 판단하는 건 제가 합니다. 그 역할 분담이 되면 작업량은 더 이상 제 한계가 아닙니다.
이 글은 제가 2026-08-19에 스레드에 올리고 직접 겪은 일을, 빠졌던 맥락과 확인 방법까지 더해 다시 쓴 글입니다. 원문은 여기서 볼 수 있습니다 → 원본 스레드 글