검색하는 법 — 모르는 것을 찾아내는 기술

좋은 개발자와 막 입문한 사람의 차이는 "아는 것이 많다" 보다 "모르는 것을 빠르게 찾는다" 쪽이 더 가깝습니다. 검색은 외우기의 보완이 아니라 별도의 기술. 이 글은 좋은 키워드를 만드는 법 · 공식 문서와 커뮤니티 자료의 우선순위 · 영어 검색 · LLM 을 검색의 보조로 쓰는 기준.

1. 검색의 자리

검색 엔진은 1990 년대 초 Archie · Yahoo Directory · AltaVista 를 거쳐 1998 년 Google PageRank 등장 이후 사실상 표준 도구. 개발자에게는 Google · DuckDuckGo · Kagi · Brave Search · Bing 가운데 하나가 일상. 2022 년 이후에는 ChatGPT · Claude · Gemini 같은 LLM 이 검색의 일부 역할을 흡수하기 시작.

검색은 두 단계:

1. 무엇을 모르는지 를 명확히 만듦.
2. 그 모름을 검색 엔진이 이해할 수 있는 키워드 로 변환.

대부분의 막힘은 1 번이 흐려서 생깁니다.

2. 좋은 키워드 만들기

흔한 실수는 자연어 문장을 그대로 검색창에 넣는 것. 검색 엔진은 키워드의 교집합을 찾는 도구라 문장보다는 희귀한 명사 · 정확한 오류 메시지 가 잘 통합니다.

안 좋은 검색	더 나은 검색
"node 가 안 돼요"	Error: Cannot find module 'express'
"리액트 props 어떻게 보내요"	react pass props to child component
"파이썬 날짜 비교 안 되네"	python compare datetime naive vs aware TypeError

오류 메시지는 가능한 한 그대로 복붙. 단 메시지에 사용자 이름 · 파일 경로 같은 가변 부분이 있으면 그 자리는 빼거나 별표로 대체.

3. 따옴표와 연산자

구문	효과
"정확한 문구"	따옴표 안 단어 순서까지 일치
-단어	그 단어가 없는 결과만
site:stackoverflow.com	특정 사이트 안에서만
site:github.com inurl:issues	특정 사이트 + URL 패턴
filetype:pdf	확장자 한정
intitle:node	제목에 포함

예:

"TypeError: Cannot read properties of undefined" site:stackoverflow.com
react useState site:react.dev
postgres "deadlock detected" -mysql

4. 우선순위 — 어디부터 보는가

대략 이 순서가 자주 권장:

1. 공식 문서 — react.dev · nodejs.org · postgresql.org 같은 1차 출처. 가장 정확하고 가장 최신.
2. GitHub 이슈 / 디스커션 — 라이브러리 자체의 메인테이너 답변이 있을 수 있음.
3. Stack Overflow — 답변에 점수와 채택 표시. 표시가 높은 답변과 댓글을 함께.
4. MDN — 웹 표준 레퍼런스의 사실상 표준.
5. 개인 블로그 — 작성자 · 작성 시점을 확인. 5 년 전 글이면 내용이 낡았을 가능성이 큼.
6. Reddit · Hacker News · GeekNews — 분위기 확인. 답을 그대로 베끼지 않음.

오래된 답을 잡지 않으려면 검색 결과의 "Tools > Past year" 옵션 또는 &tbs=qdr:y 파라미터로 1 년 이내 결과만.

5. 영어로 검색하기

한국어 자료는 양이 적고 갱신이 늦음. 같은 질문이라도 영어로 검색하면 5 ~ 50 배 많은 자료. 영어 작문 능력이 아니라 영어 키워드 구성만 익히면 됩니다.

한국어 키워드	영어 키워드
"리액트 부모 자식 통신"	react parent child communication
"스프링 부트 cors 설정"	spring boot cors configuration
"포스트그레 인덱스 안 타요"	postgres query not using index

오류 메시지는 처음부터 영어인 경우가 많아 그대로 검색하면 충분.

6. LLM 으로 검색 보완하기

ChatGPT · Claude · Gemini 같은 LLM 은 다음 자리에서 강함:

• 모호한 문제를 정리해 키워드로 만들기 ("이런 증상인데 어떤 검색어로 찾으면 되겠습니까")
• 문서 · 코드의 요약
• 여러 갈래 사이의 트레이드오프 정리
• 막힌 자리에서 "다음 단계로 시도할 만한 5 가지" 후보 만들기

약점도 분명:

• 모델 학습 데이터 시점 이후의 정보를 모를 수 있음.
• API · 라이브러리 버전이 자주 어긋남 (존재하지 않는 함수 · 잘못된 시그니처).
• 단정적으로 답함. 검증 없이 그대로 코드에 넣으면 깨짐.

LLM 의 답은 항상 "한 명의 자신감 넘치는 친구의 의견" 정도로 받아들이고, 코드 · 중요한 결정은 공식 문서로 다시 확인. 웹 검색을 함께 사용하는 모드 (GPT-4 Browse · Claude with web · Perplexity) 가 출처 링크를 제공해 검증이 쉬움.

7. 다른 길

• Perplexity · Phind · You.com — 출처 링크와 함께 LLM 답을 주는 검색.
• DevDocs.io — 여러 공식 문서를 오프라인에서 한 인터페이스로.
• Kagi — 광고 · SEO 스팸이 적은 유료 검색.
• GitHub Code Search — 오픈소스 코드에서 직접 패턴 검색.
• DuckDuckGo !bang — !so query 로 특정 사이트 우회 검색.

8. 막힘 → 검색 → 답의 흐름

1) 화면에 빨간 에러: "TypeError: Cannot read properties of null (reading 'map')"
2) 키워드 정제: 가변 부분 (파일명 · 줄번호) 제거
3) 검색: "Cannot read properties of null (reading 'map')" react
4) 첫 결과 — Stack Overflow: 데이터 fetch 가 끝나기 전에 .map 호출 → null 가드
5) 공식 문서로 검증 — react.dev "Conditional rendering"
6) 코드 수정: items?.map(...) 또는 items && items.map(...)

9. 자주 걸리는 자리

에러 메시지를 안 읽고 검색 — 메시지 자체가 답인 경우가 절반 이상. 차분히 읽음.

너무 긴 키워드 — 한 검색에 단어 5 개 이상이면 결과가 거의 안 나옴. 핵심만 남김.

오래된 답을 채택 — 2017 년의 React 답을 2026 년에 적용. 작성 시점 · 라이브러리 버전 항상 확인.

Stack Overflow 의 1 위가 항상 정답은 아님 — 댓글에 더 나은 답이 있는 경우가 많음.

검색 거부증 — "이건 너무 기초라 검색하기 부끄럽다" 는 감정이 큰 함정. 모든 시니어가 매일 검색.

LLM 답을 그대로 신뢰 — 환각이 일상. 출처가 있는지 · 실제로 동작하는지 확인.

하고픈 말

검색은 외우기의 보완이 아니라 별도 기술입니다. 좋은 키워드 (희귀 명사 · 정확한 에러 메시지) + 우선순위 (공식 문서 → GitHub → Stack Overflow) + 영어 키워드 + LLM 보조 + 검증의 다섯 자리가 함께 있을 때 막힘이 가장 빠르게 풀립니다. 모든 시니어가 매일 검색하는 시대.

Next

• how-to-read-docs
• how-to-ask-good-questions

Google Search Operators 공식 가이드 · Google Programmable Search · DevDocs · Kagi · GitHub Code Search · Perplexity · Phind · Claude · ChatGPT · Gemini · Stack Overflow · GeekNews (한국) 를 참고합니다.