flowkater's data;

flowkater

들어가며
개발자들은 엄청난 양의 기술 아티클(또는 깊이 읽어야 하는 글)을 읽는다. 블로그 포스트, 공식 문서, RFC, 컨퍼런스 발표 자료, 뉴스레터. 매일 쏟아지는 글 속에서 효율적으로 읽는 방법 을 아는 사람은 의외로 드물다. 처음부터 끝까지 순서대로 읽다가 중간에 포기하거나, 읽었는데 기억이 안 나거나, 시간만 쓰고 핵심을 놓치거나.
S. Keshav의 "How to Read a Paper" 라는 학술 논문 읽기 방법론이 있다. 논문용이라 그대로 쓰기엔 맞지 않지만, 핵심 아이디어인 "3단계에 걸쳐 읽어라" 는 기술 블로그와 아티클에도 그대로 통한다. 이 글에서는 그 방법론을 기술 아티클 읽기에 맞게 변형하여 소개한다.
그리고 한 가지 더. 2025년 이후로 AI 도구가 일상이 된 시대에, "읽기"라는 행위 자체가 위협받고 있다. 이 부분도 짚고 넘어가려 한다.
AI 시대의 읽기 — 먼저 짚고 가야 할 것
AI 요약의 함정
요즘 ChatGPT나 Claude에게 "이 글 요약해줘"를 습관적으로 시키는 개발자가 많다. 편하다. 빠르다. 근데 치명적인 부작용 이 있다.
문해력이 퇴화한다 — 긴 글을 끝까지 읽는 근육이 사라진다. 3,000자짜리 글도 "너무 길다"고 느끼기 시작한다.
판단력이 사라진다 — AI 요약은 저자의 주장을 그대로 압축할 뿐, "이 주장이 맞는가?"를 판단하지 않는다. 요약만 읽으면 비판적 사고가 개입할 틈이 없다.
맥락을 놓친다 — 기술 아티클의 가치는 종종 결론이 아니라 과정에 있다. "왜 이 선택을 했는가", "어떤 트레이드오프가 있었는가"는 요약에서 사라진다.
착각이 생긴다 — 요약을 읽으면 "아, 이해했다"는 느낌이 든다. 하지만 실제로 설명하라고 하면 못 한다. 요약을 읽은 것과 이해한 것은 다르다.
뉘앙스가 소멸한다 — 저자가 "~일 수도 있다", "특정 상황에서는"이라고 조건을 건 것을 AI는 "~이다"로 단정 짓는 경우가 많다.
마치 운전을 직접 하는 것과 조수석에서 내비게이션만 보는 것의 차이랄까. 내비가 아무리 좋아도, 직접 핸들을 잡지 않으면 길을 기억하지 못한다.
원칙: AI에게 읽기를 대신시키지 마라. 읽기는 내가 하고, AI는 도구로만 쓴다.
그럼에도 AI가 도움이 되는 경우
그럼 AI는 아예 안 쓰는 게 좋을까? 그건 아니다. AI를 완전히 배제할 필요는 없다. 읽기의 주체는 내가 유지하면서 AI를 보조 도구로 쓰면 오히려 효율이 올라간다.
핵심은 "읽기 전"이나 "읽기 대신"이 아니라 "읽은 후" 에 쓰는 것이다. 각 단계별로 AI를 어떻게 활용하면 좋은지는 아래에서 함께 다룬다.
핵심 원칙
기술 아티클을 처음부터 끝까지 한 번에 읽지 마라. 최대 3번에 걸쳐 읽어라. 각 단계는 서로 다른 목표를 가지고, 이전 단계 위에 쌓아올린다.
1단계: 이 글이 뭔지, 읽을 가치가 있는지 판단
2단계: 핵심 내용을 이해하고, 다른 사람에게 설명할 수 있는 수준
3단계: 깊이 이해하고, 내 것으로 만드는 수준
마치 레고 블록을 쌓듯이, 각 단계가 이전 단계 위에 쌓인다. 그리고 모든 글에 3단계까지 갈 필요는 없다. 대부분은 1단계에서 걸러지고, 그게 정상이다.
1단계: 훑어보기 (5분)
목표: 이 글을 더 읽을 가치가 있는지 빠르게 판단한다.
이렇게 한다
제목과 부제목을 읽는다
**서론(첫 1~2 문단)**을 읽는다 — 이 글이 무엇을, 왜 다루는지
소제목(h2, h3)만 쭉 훑는다 — 글의 뼈대를 파악
결론 또는 마지막 섹션을 읽는다 — 저자의 핵심 주장
코드 블록, 다이어그램, 이미지를 눈으로만 훑는다 — 기술적 깊이 수준 가늠
저자가 누구인지 확인한다 — 해당 분야의 전문가인지, 어떤 회사/프로젝트 소속인지
5분이면 된다. 길어야 10분. 이 단계의 핵심은 "읽을지 말지"를 빠르게 결정 하는 것이다. 근데 정말 5분 만에 판단이 가능한가? 된다. 모든 글을 꼼꼼히 읽을 시간은 없고, 읽을 필요도 없다.
1단계 후 답할 수 있어야 하는 것 — 다섯 가지 C
질문
설명
카테고리(Category)
어떤 종류의 글인가? 튜토리얼? 시스템 설계? 경험담? 비교 분석? 의견?
맥락(Context)
어떤 기술/프레임워크/문제를 다루는가? 내가 아는 것과 어떻게 연결되는가?
신뢰성(Credibility)
저자가 실제 경험에 기반해서 쓴 건가? 근거가 있는가? 아니면 추측인가?
기여(Contributions)
이 글에서 내가 얻을 수 있는 핵심 인사이트는 무엇인가?
명확성(Clarity)
잘 구조화되어 있는가? 읽기 쉬운가?
이 다섯 가지에 대략이라도 답할 수 있으면 1단계는 성공이다.
1단계에서 그만둬도 되는 경우
내 현재 관심사/업무와 관련 없는 글
제목은 자극적인데 내용이 얕아 보이는 글
내 수준에 비해 너무 기초적이거나 너무 고급인 글
저자가 근거 없이 주장만 하는 글
그만두는 것도 능력이다. 아무 글이나 끝까지 읽는 것보다 빠르게 걸러내는 게 더 중요하다.
내 경우에는 아침에 RSS 피드를 훑으면서 1단계를 수행한다. 10개 중 2~3개만 2단계로 넘어간다. (대부분은 1단계에서 끝난다.) 이 필터링이 습관이 되니까 오히려 시간이 남았다.
글을 쓰는 입장에서 한마디: 대부분의 독자는 1단계만 하고 떠난다. 소제목을 명확하게 쓰고, 서론에서 핵심을 요약하고, 5분 안에 "이 글의 가치"를 전달해야 한다. 그렇지 않으면 아무도 끝까지 읽지 않는다.
1단계에서 AI 활용
좋은 사용법:
영어 기술 아티클의 제목과 서론만 번역 요청 — 1단계 판단 속도를 높이기 위해
뉴스레터에서 10개 링크가 왔을 때, 각 글의 제목+첫 문단만 붙여넣고 "내 관심사(예: 백엔드, 분산시스템)에 관련된 글만 골라줘" 요청 — 필터링 보조
낯선 분야의 글일 때, "이 글에 나오는 CRDT, vector clock 같은 용어를 한 줄씩 설명해줘" — 사전 역할
나쁜 사용법:
글 전체를 붙여넣고 "요약해줘" — 1단계조차 내가 안 한 것이다. 판단력 퇴화의 시작.
AI 요약만 읽고 "아 이런 글이구나" 하고 넘어감 — 착각만 쌓인다.
2단계: 꼼꼼히 읽기 (15~30분)
목표: 핵심 내용을 이해하고, 다른 사람에게 요약하여 설명할 수 있는 수준 에 도달한다.
1단계를 통과한 글만 여기까지 온다. 그러니까 이미 "읽을 가치가 있다"고 판단한 글이다.
이렇게 한다
처음부터 끝까지 읽되, 코드의 세부 구현이나 수식 증명은 건너뛴다
읽으면서 핵심 포인트를 메모한다 (노션, 옵시디언, 여백 등)
다이어그램과 아키텍처 그림을 주의 깊게 본다
컴포넌트 간 관계가 명확한가?
데이터 흐름이 이해되는가?
빠진 부분이 있는가?
코드 예제를 눈으로 읽는다 (직접 실행은 3단계에서)
무엇을 보여주려는 코드인지 이해되는가?
에러 처리, 엣지 케이스가 고려되어 있는가?
모르는 용어/개념을 표시해 둔다 (지금 찾아보지 않는다, 나중에 일괄 정리)
글에서 링크된 참고 자료 중 읽을 만한 것을 북마크한다
여기서 중요한 건 "모르는 것을 그 자리에서 바로 찾아보지 않는다"는 점이다. 마치 영화를 보다가 모르는 배우가 나올 때마다 검색하면 줄거리를 놓치는 것과 같다. 흐름이 끊기면 전체 맥락을 놓친다. 표시만 해두고, 끝까지 읽은 다음에 일괄로 정리한다.
2단계 후의 상태
이 글의 핵심 논지를 3줄로 요약할 수 있다
동료에게 "이런 글 읽었는데, 핵심은 이거야"라고 설명할 수 있다
찬성/반대 또는 "우리 프로젝트에 적용 가능한지"에 대한 초기 의견이 있다
이 세 가지 중 하나라도 못 하겠으면, 아직 2단계가 끝나지 않은 것이다.
2단계에서 이해 안 될 때
원인은 보통 다음 중 하나다.
배경지식 부족 — 해당 기술/패턴을 아직 모른다 → 기초 자료를 먼저 읽고 돌아오기
글이 나쁘게 쓰여짐 — 구조가 엉망이거나 근거 없는 주장 → 같은 주제의 다른 글을 찾기
피곤함 — 진짜로 그냥 피곤한 것 → 내일 읽기
세 번째가 의외로 중요하다. 피곤한 상태에서 억지로 읽어봤자 남는 게 없는 것 같다.
나는 2단계로 읽으면서 옵시디언에 한 줄씩 메모한다. 이것만으로도 기억 유지율이 확 달라진다. (이게 생각보다 효과가 크다.)
지나고 보니, 예전에는 "다 읽었으니 됐겠지" 하고 넘어갔는데, 한 달 뒤에 뭘 읽었는지 하나도 기억 못 한 적이 몇 번 있었다. 그 뒤로 메모 습관이 생겼다.
대부분의 기술 아티클은 2단계면 충분하다. 트렌드 파악, 기술 비교, 아이디어 수집 목적이라면 여기서 멈춰도 된다.
2단계에서 AI 활용
좋은 사용법:
내가 먼저 읽고 나서 3줄 요약을 써 본 다음, AI에게도 요약을 시켜서 내 이해와 비교 — "내가 놓친 포인트가 있나?" 체크용
1단계에서 표시해둔 모르는 용어를 일괄 질문 — "이 글에 나온 eventual consistency, saga pattern, compensating transaction을 각각 2줄로 설명해줘"
아키텍처 다이어그램을 이해 못 했을 때, 다이어그램 캡처를 AI에게 보여주며 "이 그림에서 데이터 흐름을 설명해줘" 요청
영어 글에서 특정 문단이 해석이 안 될 때 해당 문단만 번역 요청 (전체 번역은 안 된다)
나쁜 사용법:
글을 안 읽고 AI에게 전체 요약 — 2단계를 건너뛴 것이다. 내 이해가 아니라 AI의 이해.
AI 요약을 그대로 노트에 복붙 — 내가 쓴 메모가 아니면 기억에 안 남는다.
"이 글의 장단점 분석해줘" — 비판적 사고를 AI에게 위임한 것이다. 자기 의견이 사라진다.
핵심 규칙: AI는 "읽은 후"에 쓴다. "읽기 전"이나 "읽기 대신"이 아니라.
3단계: 깊이 파고들기 (1~3시간)
목표: 글의 내용을 내 것으로 만든다. 직접 해볼 수 있고, 비판적으로 평가할 수 있는 수준.
솔직히 말하면 3단계까지 가는 글은 한 달에 몇 편 안 된다. 오히려 그래야 한다.
돌아보면, 내가 3단계까지 수행했던 글은 대부분 팀 아키텍처 결정이나 기술 도입 검토처럼 "직접 적용해야 하는" 상황에서였다.
이렇게 한다
코드를 직접 실행해 본다 — 복붙이 아니라, 왜 이렇게 짰는지 이해하며
저자와 동일한 문제를 내가 풀어본다 — 글을 보기 전에 내가 어떻게 접근했을지 생각
저자의 접근법과 내 접근법을 비교한다
저자가 나보다 나은 점은?
내가 다르게 했을 부분은?
저자가 놓친 것은?
가정을 도전한다
"이건 트래픽이 적을 때만 되는 거 아닌가?"
"이 아키텍처가 우리 규모에서도 동작하나?"
"이 벤치마크가 공정한가?"
나만의 메모를 작성한다
핵심 배운 점
내 프로젝트에 적용할 수 있는 것
추가로 찾아볼 것
반대 의견 또는 한계점
4번이 특히 중요하다. 글에 적힌 내용을 그대로 받아들이는 게 아니라, "이게 정말 우리 상황에도 맞나?"를 따져보는 과정이다. 생각해보면, 좋은 기술 아티클일수록 특정 조건에서의 경험을 다루는 경우가 많은 것 같다. 그 조건이 내 상황과 다르면 결론도 달라질 수 있다.
3단계 후의 상태
글의 전체 구조를 기억에서 재구성할 수 있다
강점과 약점을 구체적으로 지적할 수 있다
이 기술/패턴을 내 프로젝트에 적용하거나 변형할 수 있다
이 주제에 대해 블로그 글을 쓰거나 발표할 수 있다
결국 3단계의 결과물은 "내가 이 주제에 대해 글을 쓸 수 있는가?"다. 쓸 수 있으면 진짜 이해한 것이고, 못 쓰겠으면 아직 부족한 것이다.
3단계는 모든 글에 할 필요 없다. 내 업무에 직접 적용할 기술, 깊이 이해해야 하는 아키텍처, 팀에 공유해야 하는 중요한 글에만 3단계를 수행한다.
3단계에서 AI 활용
좋은 사용법:
소크라테스식 질문 상대로 활용 — 내가 이해한 내용을 AI에게 설명하고, "내 이해가 맞아? 빠진 부분이 있어?"로 검증
반론 생성기로 활용 — "이 아키텍처의 약점이나 실패할 수 있는 시나리오를 5개 만들어줘" → 내가 못 본 각도를 보여준다
코드 실행 중 막힐 때 특정 에러나 개념만 질문 — "이 코드에서 CompletableFuture.thenCompose가 thenApply와 뭐가 다른 거야?"
"이 글의 저자가 간과한 점이 있다면?" — AI가 만능은 아니지만, 다른 시각을 제시할 때가 있다
내 정리 메모 초안을 쓴 후 AI에게 "빠진 포인트 있어?" 로 리뷰 요청
글에서 다룬 기술의 대안이나 경쟁 기술 을 물어봄 — "이 글에서는 Redis Streams를 추천하는데, 같은 문제를 Kafka나 RabbitMQ로 풀면 어떻게 달라?"
나쁜 사용법:
AI에게 "이 글의 핵심을 정리해서 블로그 글로 써줘" — 3단계의 의미가 완전히 사라진다. 내 것이 아닌 글이 된다.
코드를 직접 실행 안 하고 AI에게 "이 코드 실행하면 결과가 어떻게 나와?" — 직접 부딪혀야 배운다.
"가정을 도전한다" 단계를 AI에게 전부 위임 — 비판적 사고 근육이 퇴화한다.
3단계에서 AI의 역할은 "스파링 파트너"다. 내가 펀치를 던지고, AI가 받아치고, 그 과정에서 내 이해가 단련된다. AI가 대신 싸워주는 게 아니다.
기술 트렌드 조사에 적용하기
새로운 기술이나 분야를 조사해야 할 때, 예를 들어 "우리 서비스에 이벤트 소싱을 도입할까?" 같은 질문이 생겼을 때, 3단계 접근법을 이렇게 활용한다.
Step 1: 탐색
Google, Hacker News, dev.to, Medium 등에서 키워드 검색
3~5편의 최근 글을 찾는다
각 글에 1단계만 수행 — 분야의 감을 잡고, 각 글의 참고 링크를 모은다
잘 정리된 서베이/개관 글이 있으면 그것부터 읽는다
Step 2: 핵심 식별
여러 글에서 반복적으로 인용되는 글/저자를 찾는다 → 그 분야의 핵심 자료
핵심 저자/회사의 공식 블로그나 발표 자료를 찾는다
컨퍼런스 발표 (QCon, Strange Loop, KubeCon 등)에서 관련 토크를 찾는다
여러 글을 훑다 보면 패턴이 보인다. "아, 이 분야에서는 결국 Martin Fowler의 저 글이 기본이구나" 같은 감이 잡힌다. (이 감이 잡히는 순간이 조사의 터닝 포인트다.)
Step 3: 심화
핵심 자료 + 컨퍼런스 발표를 모아서 2단계까지 수행
모든 글이 공통적으로 인용하는데 내가 아직 안 읽은 자료가 있으면 추가
최종적으로 내 정리 문서 (기술 검토서, ADR 등)를 작성
여기서도 AI 활용의 원칙은 동일하다. 탐색 가속이나 패턴 발견 보조로는 쓰되, "이벤트 소싱 장단점 정리해줘"로 조사를 끝내는 건 안 된다. 남의 의견을 내 조사 결과로 착각하는 것이니까. 그리고 AI가 추천한 글 목록은 반드시 실제 존재하는지 확인해야 한다. AI는 존재하지 않는 글을 추천하는 경우가 잦다.
실전 팁
읽기 효율을 높이는 습관
RSS 리더나 뉴스레터로 글을 모아서 배치로 1단계 수행 — "읽을 것"과 "버릴 것"을 먼저 분류
"나중에 읽기(Read Later)" 도구(Pocket, Instapaper, 옵시디언 클리핑)를 활용하되, 쌓아만 두지 말고 주 1회 정리 시간 을 잡기
2단계 이상 읽은 글은 반드시 메모를 남긴다 — 읽었는데 기억 안 나면 안 읽은 거나 마찬가지
3단계를 한 글은 다른 사람에게 설명하거나 블로그에 쓴다 — 이게 진짜 내 것이 되는 과정
특히 마지막이 중요하다. 생각해보면, 읽기의 마지막 단계는 결국 "쓰기"라고 본다. 쓰면서 비로소 내가 뭘 이해했고 뭘 이해 못 했는지가 드러난다.
글을 쓰는 사람 입장에서
독자의 80%는 1단계에서 떠난다 — 제목, 소제목, 서론이 전부다
다이어그램 하나가 텍스트 열 줄보다 낫다
코드 예제는 핵심만 — 전체 코드는 GitHub 링크로
결론에서 "그래서 뭘 하라는 건데" 에 답해야 한다
이 글을 읽는 사람도, 쓰는 입장에서 생각해보면 좋겠다. 내 글의 1단계가 매력적인가? 소제목만 훑어도 뼈대가 보이는가? 이런 질문을 스스로에게 던지는 것만으로도 글의 질이 올라간다.
나가며
이 방법을 적용하면서 가장 크게 달라진 건, 읽는 양이 아니라 읽는 태도였다.
단계
시간
목표
결과
AI 역할
1단계
5분
읽을 가치 판단
다섯 가지 C에 답 가능
필터링 보조, 용어 사전
2단계
15~30분
핵심 내용 이해
3줄 요약 + 동료에게 설명 가능
읽은 후 이해 비교, 용어 설명
3단계
1~3시간
깊이 이해, 내 것으로
적용/비판/발표 가능
스파링 파트너, 반론 생성기
모든 글에 3단계를 할 필요 없다. 대부분은 1단계로 걸러지고, 가치 있는 글만 2단계, 정말 중요한 글만 3단계를 수행한다. 이 필터링 자체가 효율적 읽기의 핵심이다.
그리고 AI 활용의 핵심도 같은 맥락이다.
상황
AI 활용 (좋음)
AI 위임 (나쁨)
영어 글 읽기
모르는 문단만 번역
전체 번역으로 읽기 대체
용어 이해
특정 용어 설명 요청
글 전체를 요약해달라고 함
메모 작성
내 메모 쓴 후 누락 체크
AI 요약을 그대로 메모로 사용
비판적 사고
반론/약점 시나리오 요청
"이 글 장단점 정리해줘"
코드 이해
특정 함수/패턴 질문
"이 코드 전체 설명해줘"
트렌드 조사
검색 시작점 추천
AI 정리로 조사 완료 처리
결국 중요한 건 이거다. 기술 아티클을 "많이" 읽는 게 중요한 게 아니라, "제대로" 읽는 게 중요하다. 그리고 제대로 읽는다는 건, 단계별로 깊이를 조절하면서 내 시간을 효율적으로 쓰는 것이다.
그리고 어떤 단계에서든, AI에게 읽기를 맡기는 순간 그 단계는 수행하지 않은 것이다. 읽기의 주인은 항상 나여야 한다.
"The more that you read, the more things you will know. The more that you learn, the more places you'll go."
많이 읽을수록 많이 알게 되고, 많이 배울수록 더 많은 곳에 갈 수 있다.
-- Dr. Seuss
결국 3단계 접근법이 말하는 것도 이거다. 닥치는 대로가 아니라, 골라서 읽는 것.
원작: S. Keshav, "How to Read a Paper" (University of Waterloo)
기술 블로그/아티클 버전으로 각색 + AI 활용 가이드 추가

기술 아티클 읽는 법 — 3단계 접근법 (Three-Pass Method)

댓글