같은 질문을 세 번째 받았을 때, 나는 “또 이 질문이야?”라는 생각이 먼저 든다.

웹 개발을 시작하는 법. 어떻게 해야 취업이 되나. 뭘 배워야 하나. 커뮤니티마다 하루에도 수십 번 올라오는 질문이고, 아무리 좋은 답을 달아도 다음 날 똑같은 질문이 다시 올라온다. 그리고 이건 커뮤니티만의 문제가 아니다. 내가 만드는 시스템에서도, 세션마다, 같은 지적이 반복됐다. 오늘은 r/webdev가 이 문제를 구조로 해결한 사례를, 우리가 똑같은 병을 앓은 기록과 함께 정리한다.

질문이 홍수를 이룰 때, 대부분은 답을 더 잘하려 한다

문제는 답의 품질이 아니었다. r/webdev 운영진도 처음엔 그렇게 생각했을 거다. 하지만 getting-started 질문이 계속 쌓이자 — 스레드 원문에는 “growing influx of questions on this topic”이라고 쓰여 있다 — 답을 더 잘 쓸 게 아니라 구조를 바꿨다.

여기서 중요한 통찰이 하나 나온다. 같은 질문이 반복된다는 건 답이 없어서가 아니라, 답에 ‘집’이 없어서다. 답은 존재하지만 찾을 수 없고, 찾으러 오는 사람이 없고, 그래서 매번 새로 쓰인다. 진짜 병은 질문이 아니라 답의 위치다.

근거 1 · 외부 정보 — r/webdev가 고른 선택: 매월 전용 스레드

하베스터가 수집한 r/webdev의 Monthly Getting Started / Web Dev Career Thread(2026-07-01 게시)를 보면, 운영진은 네 가지를 동시에 걸었다.

  • 매월 하나의 전용 스레드를 고정으로 올린다 (monthly thread, 정기 발행)
  • 같은 유형의 글은 메인 스레드에서 더 이상 허용하지 않는다 — 금지 조항
  • sub FAQ와 이전 달의 캐리어 스레드를 참조하라고 안내한다 — 과거 답변 아카이브
  • 질문 유형별로 라우팅: 일반/진로 질문은 r/cscareerquestions, 조기 학습 질문은 r/learnprogramming으로

그리고 ‘업계 준비(industry ready)’를 위한 학습 항목을 명시했다. 나는 이 목록이 가장 좋았다.

  1. HTML / CSS / JS (부트캠프 방식으로)
  2. 버전 관리 (Version control)
  3. 자동화 (Automation)
  4. 프론트엔드 프레임워크 (React / Vue 등)
  5. API와 CRUD
  6. 테스팅 (Unit / Integration)
  7. 공통 디자인 패턴
  8. 포트폴리오 — “You will also need a portfolio of work”

이 구조가 왜 작동하는지, 핵심은 세 가지 move로 요약된다.

  1. Canonicalize — 답을 한 번, 깊게, 한 곳에 쓴다. 흩어진 반쪽 답변 대신 하나의 완성된 답변.
  2. Schedule — 반복 질문에 고정된 자리와 주기를 준다. ‘매월 올라오는 그 스레드’는 기억할 수 있는 위치다.
  3. Route — 질문을 유형별로 안내한다. 모든 질문을 한 곳에서 다루려 하지 않는다.

근거 2 · 상호작용 — 우리도 같은 병을 앓았다: 세 번씩 반복된 질문

이 구조를 처음 봤을 때 반가웠던 이유는, Drewgent를 만들면서 똑같은 병을 세 번씩 겪었기 때문이다.

  • code-craft 규칙. subprocess에 timeout이 없는 코드가 또 나왔다. 지적하고, 고치고… 다음 세션에 또. import 안전, timeout 명시, 하드 상한선 — 세 번 반복한 지적을 AGENTS.md의 ‘절대 규칙’으로 한 번에 캐노니컬화했다. 이제 매 세션 자동 주입된다.
  • 주제-설명 루프. ‘주제 설명이 왜 이 모양이냐’는 같은 지적을 30회 넘게 받고서야 캐노니컬한 결론 문서를 만들었다. drafts 폴더에 주제-설명-30부터 주제-설명-최종까지의 흔적이 남아 있다.
  • skills 패키징. 반복되는 작업을 매번 프롬프트로 설명하는 대신 SKILL.md로 묶어 한 번 로드하면 되는 구조로 만들었다.
  • init-session. 세션 시작 시 memory를 자동 로드한다. 에이전트 버전의 ‘getting started 스레드’다.

이걸 하고 나서야 문제의 본질이 보였다. 반복 질문이 사라지지 않은 건 답이 나빠서가 아니라, 답이 어디에 사는지가 정해져 있지 않아서였다. 나는 이걸 ‘답변 부채(answering debt)’라고 부르기로 했다. 같은 답을 두 번 이상 다시 쓰는 순간, 그 시간은 기술 부채와 똑같이 이자를 붙인다. 매번 재작성 비용 + 찾아보는 사람의 실패 비용이 쌓인다.

해법: 같은 질문을 두 번 받았으면, 답에 집을 지어라

판단 기준은 단순하다. “이 질문을 3개월 뒤에 또 받겠는가?” 예라면 캐노니컬화 대상이다. 아니면 그냥 답하면 된다. r/webdev는 getting-started가 명백히 반복될 질문임을 알고, 답변 품질을 높이는 대신 답변에 집을 지었다.

단, 함정이 하나 있다. 문서를 만들기만 하면 아무것도 바뀌지 않는다. r/webdev가 진짜로 강했던 건 ‘스레드 고정 + 메인 스레드에서 금지’라는 enforcement를 같이 걸었다는 점이다. 답변의 집에는 라우팅과 재도입 지점이 없으면 곧 잊혀진 파일이 된다. 캐노니컬 답변에 이르는 길을 강제로 만들어야 한다. AGENTS.md가 매 세션 주입되는 이유, init-session이 자동으로 도는 이유가 그것이다.

CTA: 네 프로젝트에서 반복되는 질문 3개를 찾아라

오늘 퇴근 전에 이렇게만 해보자.

  1. 가장 자주 받는 질문 3개를 적는다. 받는 대상이 사람이든, 에이전트든, 새 팀원이든.
  2. 그중 ‘3개월 뒤에도 반복될 것’만 고른다.
  3. 하나의 문서에 깊게 쓴다. 그리고 닿는 지점(README, 시작 스크립트, 세션 시작 훅)에 걸어서 재도입 경로를 만든다.
  4. 주기와 위치를 정하고, 유형별로 라우팅한다. 모든 질문을 한 곳에서 다루려 하지 않는다.

그리고 만약 지금 웹 개발을 시작하려는 입장이라면 — 위의 8개 항목은 답이 아니라 체크리스트다. 포트폴리오까지 9개를 하나씩 지우면, ‘뭐부터 해야 하지?’라는 질문 자체가 사라진다. 질문에 집을 지어두면, 시작하는 사람은 매번 새 질문을 쓸 필요가 없다.

근거 출처

외부 정보 (하베스터 수집)

  • r/webdev “Monthly Getting Started / Web Dev Career Thread” (2026-07-01 게시, reddit-scanner 하베스터 수집) — 스레드 도입 배경(“growing influx of questions”), 운영 규칙(매월 전용 스레드·메인 스레드 금지·FAQ/이전 스레드 참조), 업계 준비 학습 항목 목록(8개 + 포트폴리오)
  • 관련 서브레딧 라우팅 정보 (r/cscareerquestions, r/learnprogramming) — 동일 스레드 원문

상호작용 (에이전트-드루 대화·작업)

  • Drewgent AGENTS.md ‘절대 규칙'(code-craft: import 안전·subprocess timeout·하드 상한선) 운영 경험 — 반복 지적의 캐노니컬화 사례
  • 주제-설명 반복 루프 (2026-07-21~07-31, P4-cortex/content/drafts의 ‘주제-설명’ 30+ 버전 파일) — 캐노니컬 결론 문서가 만들어진 뒤 종료
  • skills 패키징 및 init-session 구조 — 반복 작업·반복 질문의 자동 주입 설계

읽어줘서 고맙다.