onejaejae/digest

Digest — 링크를 이해로 바꾸는 스킬

미션

"읽은 것 이상의 이해" + "나한테 어떤 의미"를 한 번에 전달한다. 단순히 글을 짧게 줄이는 게 아니라, 원문보다 더 잘 이해되도록 재구성하고, 거기에 빠진 맥락을 채우고, 실용적 판단까지 더한다.

타겟 독자

주니어~미드 레벨 개발자. 기본 개념은 알지만 모든 용어에 익숙하지 않을 수 있다. 모르는 용어는 별도 용어집 없이 설명 흐름 안에서 자연스럽게 풀어준다.

실행 순서

Step 1: 링크 읽기

WebFetch로 글 전체를 가져온다:

이 글의 전체 본문을 빠짐없이 추출해줘.
포함할 것: 본문 텍스트, 코드 블록, 인용문, 핵심 수치/데이터.
메타데이터: 제목, 저자(이름+소속), 게시일.
광고나 네비게이션은 제외하고 본문만.

WebFetch 실패 시 (paywall, JS 렌더링 사이트, 404 등): 사용자에게 이렇게 안내한다:

"이 링크는 직접 접근이 어렵네요. 글 내용을 복사해서 붙여넣어 주시면 바로 분석해드릴게요."

사용자가 텍스트를 직접 붙여넣은 경우: WebFetch 없이 바로 Step 2로 진행한다. 동일한 출력 구조를 사용한다.

Step 2: 글 분석 및 맥락·핵심 출력

가져온 내용을 분석하여 한줄 요약 → 맥락 → 핵심 내용까지 먼저 출력한다. 출력은 항상 한국어로 한다 (원문이 영어라도).

Step 3: 인사이트 보강 리서치

핵심 내용 분석 후, 인사이트를 작성하기 전에 글의 성격에 따라 교차 리서치를 수행한다. 품질이 최우선이다 — 시간이 걸려도 검증된 인사이트를 제공한다.

리서치 필요성 판단:

| 글에 이런 게 있으면 | 사용할 도구 | 목적 | |---|---|---| | 검증 가능한 수치, 공식 기능, 벤치마크 | WebSearch/WebFetch | 공식 문서에서 팩트 교차 검증 | | 업계 트렌드, 논쟁, 커뮤니티 반응이 중요한 주제 | /deep-research | 다각도 관점 수집 | | 특정 기술/라이브러리의 구현 사례 언급 | /reference-seek | 실제 사례·오픈소스 확인 | | 순수 오피니언, 개인 에세이 (검증할 팩트 없음) | 리서치 스킵 | 모델 판단으로 충분 |

리서치 실행 원칙:

• 글에서 검증이 필요한 핵심 주장을 먼저 뽑는다 (최대 3개)
• 각 주장에 맞는 도구를 선택한다. 여러 도구를 조합해도 된다
• 리서치 결과는 인사이트 섹션의 "빠진 조각"과 "실용적 시사점"에 근거로 반영한다
• 리서치에서 찾은 정보는 출처를 명시한다 (예: "Anthropic 공식 문서에 따르면...")
• 리서치 결과가 저자의 주장과 일치하면, 그 자체도 인사이트다 ("검증 결과 정확하다")

Step 4: 인사이트 출력

리서치 결과를 반영하여 인사이트 & 판단 섹션과 관련 맥락(선택)을 출력한다.

---

출력 구조

1. 한줄 요약

글의 핵심을 한 문장으로 압축한다. "이 글은 ~에 대한 글이다" 패턴 대신, 핵심 주장이나 발견을 직접 서술한다.

나쁜 예: "이 글은 마이크로서비스에 대해 설명합니다" 좋은 예: "모놀리스에서 마이크로서비스로 전환할 때 가장 큰 병목은 기술이 아니라 팀 구조다"

2. 맥락 (Context)

이 글이 왜 지금 존재하는지 설명한다. 독자가 글을 읽기 전에 알았으면 하는 배경을 채워준다.

맥락 추론 체크리스트 (해당하는 것만 포함):

• 시의성: 이 글이 나온 계기가 있는가? (신규 릴리스, 사건, 논쟁, 업계 변화)
  • 계기가 명확하지 않으면 추측하지 말고 생략한다
• 배경 지식: 글을 이해하려면 먼저 알아야 하는 개념이 있는가?
  • 판단 기준: "주니어 개발자가 이 단어를 들었을 때 바로 떠오르는 게 없으면" 풀어준다
• 저자/출처 맥락: 저자의 입장이 글의 논조에 영향을 주는가?
  • 예: 특정 회사 소속이라 자사 기술에 유리하게 쓸 수 있는 경우

용어 인라인 설명 기준: 주니어 개발자 3년차가 모를 수 있는 용어만 풀어준다. 풀 때는 흐름을 끊지 않도록 괄호나 짧은 부연으로.

• 풀어야 하는 예: "WASM(WebAssembly, 브라우저에서 네이티브급 속도로 코드를 실행하는 기술)의 등장으로..."
• 풀지 않아도 되는 예: API, REST, Docker, Git — 주니어도 아는 기본 용어

3. 핵심 내용 (Core)

글의 주요 주장과 내용을 이해하기 쉬운 순서로 재구성해서 설명한다.

재구성 원칙:

• 원문의 섹션 순서를 그대로 따르지 않는다. "무엇 → 왜 → 어떻게" 순서가 보통 가장 이해하기 쉽다
• 원문의 문장을 그대로 번역하지 않는다. 핵심 메시지를 추출해서 자기 말로 다시 쓴다
• 글이 3가지 이상 주장을 하면, 가장 중요한 것부터 배치한다

설명 도구 (상황에 맞게 선택):

• 비유/아날로지: 익숙한 것에 빗대어 설명 ("이건 마치 ~와 같다")
• 구체적 예시: 추상적 개념을 실제 시나리오로 풀기
• 대비/비교: Before/After, A vs B로 차이를 선명하게
• 구조화: 복잡한 내용은 번호 목록이나 표로 정리
• 핵심 수치: 글에 포함된 벤치마크, 통계, 비율 등은 맥락과 함께 제시

글이 코드를 포함하면, 코드의 의미와 의도를 설명한다. 코드 전체를 복사하지 말고, 핵심 패턴만 짧게 인용하거나 의사코드로 설명한다.

4. 인사이트 & 판단 (So What?)

글을 읽고 난 뒤의 "그래서?" 에 답한다. 세 가지 관점을 순서대로 다룬다:

a) 주목 포인트 — 이 글에서 특히 눈여겨볼 부분과 그 이유. 글의 핵심 강점이나 독특한 시각을 짚는다.

b) 빠진 조각 — 다음 질문들로 빈틈을 찾는다:

• "저자가 의도적으로 빠뜨렸거나 모르고 놓친 관점이 있는가?"
• "반대 입장에서 보면 어떤 반론이 가능한가?"
• "저자의 전제 중 의심할 만한 것이 있는가?"
• "다른 기술/접근법과 비교했다면 결론이 달라졌을까?" 빈틈이 없는 글이면 억지로 만들지 말고, 그 자체를 언급한다.

c) 실용적 시사점 — "나한테 어떤 의미?"에 답한다.

• 지금 당장 적용할 수 있는 것이 있는가?
• 의사결정에 참고할 만한 포인트가 있는가?
• 더 알아보면 좋을 주제가 있는가?

톤: 균형잡힌 분석. 칭찬만 하거나 깎아내리기만 하지 않는다. 좋은 톤 예시: "저자의 실측 데이터 기반 분석은 설득력 있지만, 벤치마크를 Go와만 비교한 점은 한계다 — Rust나 Zig와 비교했다면 결론이 달라졌을 수 있다"

인사이트 자가 검증: 작성한 인사이트가 "이 글의 URL을 모르는 사람에게도 말할 수 있는 뻔한 말"이면 삭제하고 다시 쓴다.

• 삭제 대상: "이 글은 중요한 주제를 다루고 있습니다", "흥미로운 관점입니다"
• 유지 대상: 이 글 고유의 논점, 데이터, 방법론에 대한 구체적 평가

5. 관련 맥락 (선택)

이 글과 연결되는 다른 글, 개념, 트렌드가 있을 때만 포함한다. 억지로 넣지 않는다 — 실제로 이해에 도움이 될 때만.

---

글 종류별 전략

글의 성격에 따라 각 섹션의 무게 배분이 달라진다:

| 글 종류 | 맥락 | 핵심 내용 | 인사이트 | 핵심 설명 도구 | |---|---|---|---|---| | 기술 블로그 (튜토리얼, 구현기) | 가볍게 | 무겁게 — 구조화·예시 중심 | 실용적 시사점 위주 | 비유, 코드 스니펫 | | 오피니언/에세이 | 저자 맥락 중요 | 주장 흐름 정리 | 무겁게 — 반론·빠진 관점 | 대비/비교 | | 뉴스/트렌드 | 무겁게 — 시의성 중심 | 팩트 구조화 | 실용적 시사점 위주 | 타임라인, 수치 | | 공식 문서/릴리스 노트 | 가볍게 | 무겁게 — 변경점 구조화 | 마이그레이션 시사점 | Before/After 비교 | | 의견만 있는 짧은 글 | 가볍게 | 가볍게 | 무겁게 — 빠진 근거 짚기 | 반론 프레임워크 |

글 종류를 명시적으로 판단할 필요는 없다 — 자연스럽게 무게를 분배한다.

분량 가이드

5-7분 읽기 분량을 기준으로 한다. 글의 복잡도에 따라 자연스럽게 조절:

| 원문 복잡도 | 분량 조절 | |---|---| | 짧고 단순한 글 (500자 이하) | 전체 출력 짧게. 맥락/핵심 간결, 인사이트 1-2개 | | 보통 길이 | 모든 섹션 적당한 깊이로 | | 길고 복잡한 글 | 핵심 내용 구조화에 힘쓰고, 나머지도 충실하게 |

어떤 경우든 "원문 복사 붙여넣기"가 되지 않도록 한다. 모든 문장은 이해를 돕기 위해 재구성된 것이어야 한다.

톤 가이드

목표 톤: 똑똑한 선배 개발자가 커피 마시면서 설명해주는 느낌. 학술 논문처럼 딱딱하지 않고, 블로그 댓글처럼 가볍지 않다.

| 요소 | 이렇게 | 이렇게는 안 됨 | |---|---|---| | 문체 | "~다" 체 기본, 자연스러운 구어체 OK | 존댓말 ("~합니다"), 과도한 격식체 | | 전문 용어 | 필요하면 쓰되, 바로 풀어줌 | 설명 없이 약어만 나열 | | 판단 표현 | "~는 한계다", "~가 강점이다" | "~인 것 같습니다", "~라고 생각됩니다" | | 섹션 전환 | 자연스럽게 흘러가도록 | 기계적 구분선이나 "다음으로..." |

피해야 할 패턴

• 어떤 글에든 붙일 수 있는 범용 인사이트 ("흥미로운 관점을 제시합니다")
• 원문 구조를 그대로 따라가며 번역만 한 것
• "왜 지금 이 글이 나왔는지" 맥락 생략
• 일방적 칭찬이나 일방적 비판
• 용어를 풀지 않고 그대로 쓰는 것
• 섹션 헤더를 "1. 한줄 요약", "2. 맥락" 같은 번호 형식으로 기계적으로 쓰는 것 → 대신 내용에 맞는 자연스러운 제목 사용 가능 (번호는 내부 가이드용)