Sellii is a resale-arbitrage agent (solo build, not launched, private repo). Instead of asking anyone to take its reliability on faith, I wrote three reproducible offline harnesses that measure the claims directly. This page is the methodology summary and result tables: the numbers cited in my resume and outreach, with their exact scope.
Sellii는 혼자 만든 resale arbitrage 에이전트예요(미출시, private repo). 믿어달라고 말하는 대신, 주장을 직접 측정하는 재현 가능한 오프라인 하네스 3개를 만들었어요. 이 페이지는 그 방법 요약과 결과 표예요. 이력서와 메일에 인용한 숫자들의 정확한 범위를 여기에 밝혀 뒀어요.
If the model lies about prices, profit, or comps, does anything catch it before a human sees the deal?모델이 가격·수익·시세를 지어내면, 사람이 보기 전에 걸러질까요?
44 recommendations (8 valid, 36 deliberately corrupted across 12 corruption types) are run through two validators:
추천 44개(정상 8, 12가지 방식으로 일부러 손상시킨 36)를 두 검증기에 통과시켰어요:
| Metric지표 | Prompt-only프롬프트만 | Server-side서버 검증 |
|---|---|---|
| Economic lies blocked (fabricated price / profit / recommendation / sample count / query)지어낸 가격·수익·추천 차단 (가격 / 수익 / 추천 / 샘플 수 / 쿼리 위조) | 0/17 | 17/17 |
| Valid recommendations preserved (false positives)정상 추천 보존 (오차단) | · | 8/8 (0 FP) |
| Comp-contamination resistance (cheap parts or wrong-category items mixed into comps; median must hold at the true value)시세 데이터 오염 저항 (저가 부품·다른 카테고리가 섞여도 중앙값이 참값 유지) | · | 7/7 |
| Evidence snapshot attached to every accepted deal승인된 거래마다 근거 스냅샷 저장 | · | 24/24 |
| All should-block cases, including out-of-scope gaps차단해야 할 전체 케이스 (범위 밖 구멍 포함) | · | 17/29 (58.6%) |
Four corruption types get through this harness, each with a known cause: comps fabricated for a never-searched query (canonical recomputation only protects on a cache hit), comps that are entirely the wrong product (the token filter falls back when almost nothing matches), stale comps older than three years (no freshness window yet), and a missing listing URL (this harness skips the detail check). That is why the headline is 17/17 economic lies, not "100% of everything."
4가지 손상 유형이 이 하네스를 통과해요. 각각 원인을 알아요: 검색한 적 없는 쿼리로 지어낸 시세(재계산은 캐시에 있을 때만 보호해요), 시세가 전부 다른 상품인 경우(거의 안 맞으면 토큰 필터가 물러서요), 3년 넘은 오래된 판매 기록(신선도 검사가 아직 없어요), 매물 URL 누락(이 하네스는 상세 검사를 건너뛰어요). 그래서 헤드라인이 "전부 100% 차단"이 아니라 경제적 거짓말 17/17이에요.
But this harness exercises one gate in isolation. Tracing all 12 gap cases through the full production path splits them cleanly: 3 already fail closed downstream, and 9 genuinely fail open.
그런데 이 하네스는 게이트 하나만 떼어내서 돌려요. 12개 구멍을 프로덕션 전체 경로로 따라가 보면 깔끔하게 나뉘어요. 3건은 하류에서 이미 막히고(fail-closed), 9건은 진짜로 뚫려요(fail-open).
| Downstream disposition하류 결말 | Cases건수 | Why이유 |
|---|---|---|
| Fail-closed in production프로덕션에서 차단 | 3 | Missing listing URL: listing_url is NOT NULL in the schema, and the auto-send step requires a valid https URL, so a URL-less recommendation never passes that gate.매물 URL 누락: 스키마에서 listing_url이 NOT NULL이고, 자동 발송 단계가 유효한 https URL을 요구해요. 그래서 URL 없는 추천은 그 게이트를 통과하지 못해요. |
| Fail-open통과 | 9 | Fabricated, wrong-product, or stale comps clear the economic gate and would reach a human as "approved."지어냈거나, 다른 상품이거나, 오래된 시세가 경제 게이트를 통과해서 "승인됨" 상태로 사람에게 도달해요. |
The 9 fail-open cases are the real exposure. For them I designed a review-queue routing patch: a recommendation built on comps the server can't verify (never-searched, wrong-product, or past the freshness window) is diverted to a human review queue instead of auto-approval. It's a design I can walk through, not shipped code, so I list it as the next step, not a current guarantee.
진짜 노출은 이 9건이에요. 이걸 위해 리뷰 큐 라우팅 패치를 설계했어요. 서버가 검증할 수 없는 시세(검색된 적 없거나, 다른 상품이거나, 신선도 기준을 넘긴)로 만든 추천은 자동 승인 대신 사람 리뷰 큐로 보내요. 코드로 보여드릴 수 있는 설계지 아직 배포한 코드는 아니에요. 그래서 현재의 보장이 아니라 다음 단계로 적어 둬요.
When a payment webhook or deal-save event is redelivered, retried, or raced, how many times does the business action actually commit?결제 웹훅이나 저장 이벤트가 다시 오거나, 재시도되거나, 경쟁하면 실제로 몇 번 커밋될까요?
One logical event is delivered 20× sequentially, 20× concurrently, across a process restart, and from two processes at once, against three dedup strategies. External side effects are mocked as counters; the ideal outcome is exactly one committed action per unique event. The concurrency race is real: the non-atomic strategy has an async gap between check and insert, and interleaving actually occurs.
논리적으로 같은 이벤트 1개를 순차 20번, 동시 20번, 프로세스 재시작을 사이에 두고, 그리고 두 프로세스에서 동시에 전달했어요. 중복 제거 전략 3가지를 비교했고, 외부 side effect는 카운터로 모킹했어요. 이상적인 결과는 이벤트당 정확히 1번 커밋이에요. 동시성 레이스는 진짜예요. 비원자 전략은 확인과 삽입 사이에 비동기 틈이 있어서 실제로 겹쳐요.
| Strategy전략 | Sequential ×20순차 ×20 | Concurrent ×20동시 ×20 | Restart replay재시작 후 재전송 | 2 processes ×202프로세스 ×20 |
|---|---|---|---|---|
| In-memory set (marker lost on restart)인메모리 셋 (재시작하면 마커가 사라져요) | 1 | 1 | 2 | 2 |
| Non-atomic durable check-then-insert (v1's pattern)비원자적 확인-후-삽입 (v1의 패턴) | 1 | 20 | 1 | 40 |
| Atomic durable event ledger (claim-if-absent / unique constraint)원자적 이벤트 원장 (없을 때만 선점 / unique 제약) | 1 | 1 | 1 | 1 |
Under partial failure (crash after the side effect but before the marker is written), act-then-mark ordering committed twice (a duplicate committed action), while claim-then-act committed once, with the retry becoming a no-op.
부분 실패(side effect는 성공했는데 마커를 쓰기 전에 죽는 경우)에서는, 행동-후-기록 순서가 두 번 커밋됐어요. 같은 작업이 한 번 더 커밋되는 거예요. 선점-후-행동은 한 번만 커밋됐고, 재시도는 아무 일도 하지 않았어요.
Replacing "one vision call per listing" with free deterministic filters plus a small text model: how much cheaper, and how many good deals get lost?"매물마다 vision 호출 1번"을 공짜 결정적 필터와 작은 텍스트 모델로 바꾸면, 얼마나 싸지고 좋은 매물을 몇 개나 놓칠까요?
The same fixed 31-listing fixture runs through two pipelines: a baseline that sends every listing to gpt-4o Vision, and the HTTP-first design where deterministic filters (price sanity, initial profit gate, 48-hour dedup, removed-listing checks) eliminate candidates for free and only survivors reach gpt-4o-mini as text. Profit and market-price judgments use the real production functions; LLM outputs are fixture-injected, so this measures pipeline shape, cost, and recall, not model accuracy.
같은 고정 매물 31개 픽스처를 두 파이프라인에 통과시켰어요. 기준선은 모든 매물을 gpt-4o Vision으로 보내요. HTTP 우선 설계는 결정적 필터(가격 검증, 초기 수익 게이트, 48시간 중복 제거, 삭제 매물 확인)가 후보를 공짜로 줄이고, 살아남은 것만 gpt-4o-mini에 텍스트로 보내요. 수익·시세 판단은 실제 프로덕션 함수를 썼고 LLM 출력은 픽스처로 주입했어요. 그래서 재는 건 파이프라인 구조·비용·유지율이지, 모델 정확도가 아니에요.
| Metric지표 | Baseline (all-vision)기준선 (전량 vision) | HTTP-first |
|---|---|---|
| gpt-4o Vision callsgpt-4o Vision 호출 | 31 | 0 |
| gpt-4o-mini text callsgpt-4o-mini 텍스트 호출 | 0 | 38 |
| Share of listings hitting the expensive model비싼 모델로 간 매물 비율 | 100% | 0% |
| Projected LLM cost (fixture total)예상 LLM 비용 (픽스처 합계) | $0.2480 | $0.0031 |
| Projected savings예상 절감 | · | 98.8% (81×) |
| Metric지표 | Value값 |
|---|---|
| Profitable deals surfaced by the baseline기준선이 찾은 수익 매물 | 15 |
| Also surfaced by HTTP-firstHTTP 우선도 찾은 것 | 12 |
| Recall유지율 | 80.0% (12/15) |
| Misses놓친 것 | 3 · all image-only listings3 · 전부 사진만 있는 매물 |
All three misses are listings with a photo and a vague title ("🔥 must go asap DM me"). A text-only model cannot extract brand or model, while the vision baseline reads the photo. That is the real recall/cost trade-off of HTTP-first, measured rather than assumed. Selective vision escalation for that segment is an unbenchmarked hypothesis, not a claim.
놓친 3건은 전부 사진에 모호한 제목만 있는 매물이에요("🔥 급처, DM 주세요" 같은). 텍스트만 보는 모델은 브랜드·모델명을 못 뽑는데, vision 기준선은 사진을 읽어서 잡아요. 이게 HTTP 우선 설계의 진짜 비용/유지율 트레이드오프예요. 가정이 아니라 측정한 거예요. 그 구간만 vision으로 올려보내는 방식은 아직 벤치마크 안 한 가설이라서, 주장하지 않아요.
Each harness is a deterministic script that runs fully offline (npm run test:trust ·
npm run test:idempotency · npm run test:cost) and reproduces these tables on every run.
The repo is private; I'm happy to do a live code walkthrough of the harnesses and the production
gate logic they replicate.
각 하네스는 완전히 오프라인에서 도는 결정적 스크립트예요(npm run test:trust ·
npm run test:idempotency · npm run test:cost). 돌릴 때마다 같은 표가 나와요.
저장소는 private이지만, 하네스와 그것이 복제한 프로덕션 게이트 로직을 라이브 코드 워크스루로
보여드릴 수 있어요.