개발자를 위한 기술 사이트 주소모음 컬렉션

개발은 지식의 조각을 빠르게 조립하는 일과 비슷하다. 코드 한 줄을 고치려다 RFC 문서로 건너뛰고, 레거시 라이브러리 버전 호환성을 확인하려다 보안 공지를 확인하는 식으로 동선이 복잡해진다. 검색만으로 해결될 때도 있지만, 자주 찾는 곳을 체계적으로 모아둔 사이트 주소모음이 있으면 사고 흐름이 끊기지 않는다. 여기서는 신뢰할 만한 레퍼런스와 도구, 깊이가 있는 글과 현업 블로그를 중점으로, 실제로 손이 가는 링크모음 컬렉션을 설명한다. 단순한 나열이 아니라, 어떤 순간에 어떤 리소스를 선택할지 판단 기준과 함께 소개한다.
표준, 명세, 레퍼런스: 근거가 되는 문서부터
웹과 네트워크, 프로토콜 문제는 명세를 보면 의외로 빨리 풀린다. 웹 표준은 W3C 문서와 WHATWG, 브라우저 구현은 MDN이 실용적이다. 네트워크와 보안은 IETF와 RFC Editor 사이트에서 정식 번호를 찾아 읽는 습관이 오래 간다.

MDN Web Docs: https://developer.mozilla.org
브라우저 호환성과 샘플 코드, 경고 섹션이 실전에서 가장 도움된다. 신 버전 문법을 팀에 권할 때는 MDN의 Browser Compatibility 표가 설득력 있는 근거가 된다.
WHATWG HTML Living Standard: https://html.spec.whatwg.org
스펙과 구현 간 엇갈림이 생겼을 때 원문 해석이 필요하다. 오래된 블로그 글보다 최신 리빙 스탠더드를 우선 참고한다.
W3C: https://www.w3.org/TR/
CSS와 접근성 관련 권고안을 찾기 좋다. 특정 속성의 상태가 Working Draft인지 Recommendation인지 구분해 리스크를 판단한다.
IETF Datatracker: https://datatracker.ietf.org 와 RFC Editor: https://www.rfc-editor.org
HTTP, TLS, QUIC 같은 기초 회로를 이해하는데 필수다. 예를 들어 9110 계열 RFC는 HTTP/1.1 재정리본으로 실제 프록시 이슈를 다룰 때 인용 가치가 높다.
언어별로는 공식 문서가 답이 되는 경우가 많다. Java는 https://docs.oracle.com, Python은 https://docs.python.org, Go는 https://go.dev/doc, Rust는 https://doc.rust-lang.org. 자바스크립트의 경우 ECMAScript 명세 https://tc39.es/ecma262 와 MDN을 병행하면 구현 디테일과 호환성을 함께 챙길 수 있다.
패키지와 생태계: 버전, 의존성, 보안 공지까지 한 번에
언어 생태계는 패키지 레지스트리와 그 주변 도구가 반이다. 문제의 절반은 버전 호환성에서 발생하므로, 레지스트리에서 실제 사용량과 이슈, 보안 경고를 보는 습관이 중요하다.

Npm: https://www.npmjs.com
PyPI: https://pypi.org Maven Central: https://search.maven.org RubyGems: https://rubygems.org Crates.io: https://crates.io Go packages: https://pkg.go.dev
레지스트리 숫자는 인기의 대략적 신호일 뿐이다. 신뢰 기준을 고정해두면 판단이 빨라진다. 나는 대략 다음을 본다. 유지보수 주기, 릴리스 노트 품질, 오픈 이슈의 응답 속도, 테스트 커버리지 표기 여부, 보안 공지 링크, 대체재 대비 이점. 예를 들어 Express를 대체하는 프레임워크를 검토할 때, npm 주간 다운로드만이 아니라 보안 공지 기록과 미들웨어 호환성 표를 같이 확인한다.

보안 측면에서는 GitHub Security Advisories https://github.com/advisories 와 NVD https://nvd.nist.gov 가 기본이다. 패키지의 CVE 링크가 레지스트리 페이지에 정리된 경우가 많지만, 의존 체인까지 확장 검색할 때는 osv.dev https://osv.dev 가 편리하다.
개발 플랫폼과 코드 저장소: 검색과 읽기 동선 줄이기
GitHub: https://github.com
GitLab: https://gitlab.com Bitbucket: https://bitbucket.org
이 셋은 코드 호스팅 그 이상이다. 이슈와 PR의 대화, 릴리스 노트, Discussions에 답이 숨어 있다. 레포를 가볍게 복제하기 전에 먼저 Release 탭에서 브레이킹 체인지 유무를 확인하고, Actions나 CI 설정을 보고 테스트 행태를 파악해 둔다. 트러블슈팅 중이면 같은 에러 메시지로 이슈 검색을 돌렸을 때, 열린 이슈의 라벨과 최근 코멘트 날짜만 봐도 현재성 여부를 가늠할 수 있다.

대형 코드 검색은 Sourcegraph https://sourcegraph.com 가 유용하다. 공개 생태계에서 특정 함수 시그니처나 에러 문자열이 어떻게 쓰이는지, 언어를 가리지 않고 탐색할 수 있다. 코드 리딩 중 문맥 전환을 줄여준다.
문서 빌드, API 레퍼런스, 스니펫 도구
팀 문서는 장기자산이지만, 초기 셋업이 귀찮다면 문서화가 지연된다. 셋업 속도가 빠른 도구를 골라야 한다. 정적 문서는 Docusaurus https://docusaurus.io 나 MkDocs https://www.mkdocs.org 가 진입이 쉽다. OpenAPI 스펙으로 API 문서를 일으키려면 Swagger UI https://swagger.io/tools/swagger-ui 나 Redoc https://redocly.com/redoc 가 빠르다. 사소한 반복 작업은 DevDocs https://devdocs.io 에서 오프라인 문서 묶음을 사용하는 것으로 상당 부분 줄어든다.

개발 중 잦은 포맷과 검증은 웹 도구가 낫다. JSON은 https://jsonlint.com, 정규식은 https://regex101.com, URL 인코딩은 https://www.urlencoder.org. 이런 도구는 북마크 바의 한 폴더로 묶어두고 단축키로 연다. CLI로 사이트 주소모음 https://inktshirtparis.com 대체 가능한 작업이더라도, 팀 동료가 바로 접근해 같은 화면을 공유할 수 있다는 점이 크다.
빌드, 배포, 클라우드 문서: 환경을 모르면 디버깅이 길어진다
AWS, Azure, GCP의 공식 문서는 길지만 답을 준다.
AWS: https://docs.aws.amazon.com Azure: https://learn.microsoft.com/azure GCP: https://cloud.google.com/docs
배포 문제는 설정 키 하나의 의미를 정확히 아는지에 달렸다. 예를 들어 ALB와 NLB의 차이나 Cloud Run의 동시성 모델을 문서로 미리 간략히 정리해두면, 장애 시 요약 정리가 빠르다. 부하 분산 레벨과 타임아웃 조합, 헬스 체크 주기 같은 수치는 문서의 기본값을 기억해두면 문제 재현에 도움이 된다.

CDN과 엣지 관련해서는 Cloudflare Developers https://developers.cloudflare.com 와 Fastly Docs https://docs.fastly.com 가 좋다. 특정 헤더 동작과 캐시 키 정책, Brotli 레벨 같은 디테일을 실험하기 전에 문서의 가이드라인을 확인하면 시간을 아낀다.

컨테이너와 오케스트레이션은 Docker Docs https://docs.docker.com 와 Kubernetes 문서 https://kubernetes.io/docs 가 정석이다. 쿠버네티스 트러블슈팅 중 로그 워칭만 늘어지면, Events와 Describe 출력에서 경고 타입과 리스케줄링 힌트를 우선 본다. 공식 문서의 예시 YAML은 작동하는 최소 단위를 제공한다는 점에서 실험 시작점으로 안전하다.
품질과 성능: 눈으로 보기 전까지는 모른다
웹 성능은 측정 도구와 해석 역량 모두가 필요하다. Google의 web.dev https://web.dev 과 Lighthouse 문서 https://developer.chrome.com/docs/lighthouse 가 기본이다. 내가 자주 하는 실수는 TTFB만 보고 서버 병목으로 단정하는 것인데, LCP와 CLS의 원인을 분해해 보면 이미지 사이즈와 폰트 로딩 전략이 결정적일 때가 많다. 크롬 DevTools의 Performance 탭과 함께, WebPageTest https://www.webpagetest.org 와 GTmetrix https://gtmetrix.com, SpeedCurve https://speedcurve.com 같은 서비스 비교를 통해 병목의 위치를 교차 확인한다.

백엔드 성능은 APM 문서가 지름길이다. Datadog Docs https://docs.datadoghq.com 와 New Relic Docs https://docs.newrelic.com, OpenTelemetry https://opentelemetry.io/docs 를 같이 읽고 추적 상관관계를 만들어둔다. 지표를 만들지 않으면 해석이 불가능하다. GC, DB Slow Query, 큐 대기 시간처럼 언어 런타임과 인프라 전반의 관측 포인트를 분류해 북마크로 묶어두면 장애 시 빠른 참조가 가능하다.
보안과 취약점 모니터링: 생각보다 가까운 문제
OWASP: https://owasp.org
CWE: https://cwe.mitre.org MITRE ATT&CK: https://attack.mitre.org NVD: https://nvd.nist.gov CISA KEV Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
OWASP Top 10의 제목만 아는 것과 실제 항목 설명을 읽고 예제 코드를 보는 것은 체감 차이가 크다. 사내 코드리뷰 체크리스트에 구체 항목을 붙여넣고, 언어별 사례 링크를 병기해두면 품질이 올라간다. 자주 쓰는 프레임워크의 보안 가이드는 별도 북마크가 좋다. 예컨대 Spring Security Documentation, Django Security, Express 보안 가이드. 컨테이너 이미지의 CVE는 Trivy 문서 https://aquasecurity.github.io/trivy 와 Grype https://github.com/anchore/grype 가 접근성이 좋다.
실무 블로그와 기술 문화: 현장에서 얻은 디테일
한국어 자료가 필요할 때는 기업 기술 블로그가 품질이 높다. 네이버 D2 https://d2.naver.com, 카카오 https://tech.kakao.com/blog, 라인 https://engineering.linecorp.com/ko/blog, 우아한형제들 https://techblog.woowahan.com, 토스 https://toss.tech, 당근마켓 https://medium.com/daangn 과 같은 곳에서 아키텍처 전환기, 장애 대응기, 성능 개선기 같은 글을 꾸준히 발행한다. 생산 환경의 수치와 트레이드오프가 담겨 있어 의사결정 자료로 좋다. 글로벌로는 Cloudflare Blog https://blog.cloudflare.com, Netflix TechBlog https://netflixtechblog.com, Uber Engineering https://www.uber.com/blog/engineering 가 깊다.

개발 문화와 대화는 Hacker News https://news.ycombinator.com, Lobsters https://lobste.rs, Stack Overflow https://stackoverflow.com 가 장터 역할을 한다. 품질 편차가 있지만, 논쟁이 많은 토픽일수록 원문 소스와 반례가 풍부해진다. 링크를 따라가며 출처를 거슬러 올라가는 습관을 들이자. 링크모음으로만 소비하면 얕은 이해에 머물기 쉽다.
문제 해결 동선: 검색 엔진만으로는 부족할 때
에러 메시지로 검색해도 같은 문제를 겪은 글이 안 보일 때가 있다. 그럴 때는 세 갈래를 같이 탄다. 첫째, 공식 이슈 트래커에서 키워드 조합을 바꿔본다. 둘째, 명세 문서에서 용어를 확인해 보정한다. 셋째, 언어별 커뮤니티 Q&A에서 축약어 대신 원문 용어를 쓴다. 예를 들어 gRPC에서 keepalive 문제가 의심된다면, GitHub 이슈에서 ping, idle, http2 설정을 교차해 찾고, gRFC 문서와 Envoy 문서를 이어본다. 이 과정이 길어져도 다음에 같은 문제가 생기면 10분 만에 해결된다.
실전 즐겨찾기 구조: 검색 시간을 줄이는 폴더링
북마크를 기능이 아니라 순간으로 나누면 찾기가 편하다. 순간은 대략 설계, 구현, 디버깅, 배포, 회고다. 각 순간에 들어가는 링크는 팀과 스택에 따라 달라지지만, 폴더 이름을 순간으로 고정해두면 구성원이 바뀌어도 유지가 쉽다. 예를 들어 디버깅 폴더에는 로그 검색 콘솔, 트레이싱 뷰어, 에러 카탈로그, 런북 문서가 함께 들어간다. 또 하나 팁은 컨텍스트 키를 북마크 이름에 붙이는 것. “Lighthouse - 모범지표”, “Cloud Run - 동시성”, “K8s - PodPending 원인” 같은 식으로 검색 인덱스를 만들면 브라우저 주소창 자동완성이 강력해진다.
퀵 스타트 - 북마크 시스템 5단계 브라우저에서 개발 전용 프로필을 만들고, 북마크 바에 순간 기반 폴더 5개를 만든다: 설계, 구현, 디버깅, 배포, 회고. 각 폴더마다 최대 12개의 핵심 링크만 넣고, 나머지는 폴더 하위에 보관함을 만들어 미룬다. 링크 추가 기준을 문장 한 줄로 정한다. 예: “3개월 내 실제로 사용했고 다음에도 바로 쓸 가능성이 있는가.” 분기마다 한 번, 보관함을 훑어 낡은 링크를 아카이브하고, 실제 사용 로그가 있는 링크를 상위로 올린다. 필수 링크는 팀 공용 문서에 표로 공유하고, 새 구성원이 1시간 내 셋업을 끝낼 수 있는지 점검한다. 사소하지만 자주 쓰는 유틸리티와 테스트 베드
HTTP 요청은 간단한 경우 curl https://curl.se 가 제일 빠르다. 복잡한 시나리오는 Postman https://www.postman.com 과 Hoppscotch https://hoppscotch.io 가 편하다. 웹훅을 로컬에서 받으려면 ngrok https://ngrok.com, Cloudflare Tunnel https://developers.cloudflare.com/cloudflare-one/connections/connect-apps 를 쓴다. 이미지 최적화는 Squoosh https://squoosh.app, 색상 대비는 WebAIM Contrast Checker https://webaim.org/resources/contrastchecker. 접근성 검증은 axe DevTools https://www.deque.com/axe/devtools 와 Lighthouse의 Accessibility 탭을 병행한다.

코드 공유는 GitHub Gist https://gist.github.com 와 Pastebin류가 빠르지만, 민감 정보가 섞이지 않도록 주의한다. 팀 내부 공유는 사내 Git 레포나 Snippet 서버를 쓰는 편이 안전하다. 무심코 올린 로그의 토큰 한 줄이 사고로 이어진 사례를 여러 번 봤다.
한국 개발 환경 특화 링크: 로컬의 강점 활용
국내 커뮤니티는 오프라인과 온라인이 결합돼 있다. OKKY https://okky.kr, 오픈소스 컨트리뷰톤, Naver CAMPUS, Kakao Tech Meet 같은 행사는 자료가 공개되기도 한다. 오픈채팅, 슬랙 커뮤니티는 유동적이라 길목이 자주 바뀐다. 대신 기업 기술 블로그와 컨퍼런스 영상 아카이브를 고정 링크로 두는 편이 낫다. AWSKRUG 유튜브, PyCon KR, DEVIEW, if(kakao) 등은 재생목록이 좋은 목차가 된다.
링크모음 운영 팁: RSS와 자동화로 스스로 최신 유지
링크 수가 늘면 관리가 일이 된다. 수집 도구를 처음에 잘 골라야 한다. 나는 Raindrop.io https://raindrop.io 와 Feedly https://feedly.com 조합을 추천한다. Raindrop은 태그와 하이라이트가 강하고, Feedly는 RSS 관리가 편하다. GitHub Starred를 자동으로 Raindrop에 복사해 두면 프로젝트 발견 루틴이 매끈해진다. Zapier https://zapier.com 나 IFTTT https://ifttt.com 로 “새 릴리스가 나오면 Slack에 알림”, “새 블로그 글이 나오면 Raindrop에 저장” 같은 연결을 만들어두면 주 단위 큐레이션이 끝난다.

RSS가 없는 블로그도 있다. 이때는 RSSHub https://docs.rsshub.app 를 생각해 볼 만하다. 장점은 분산 배치가 가능하다는 점, 단점은 유지 부담이 있다는 점이다. 회사 정책상 외부 자동화 도구를 못 쓰는 환경이라면 사내 GitHub Actions로 주기 수집 스크립트를 돌려도 된다.
주의할 점: 스팸, 피싱, 주제 외 유혹
사이트 주소모음이라는 이름으로 불리는 페이지 중에는 스팸 유도나 과도한 광고, 피싱 링크가 섞여 있는 경우가 많다. 검색어가 섞이는 과정에서 스포츠무료중계 같은 전혀 관련 없는 키워드가 붙기도 한다. 개발 자료를 찾다가 의도치 않게 이런 페이지로 들어가면 브라우저 알림 권한 요구, 확장 프로그램 설치 유도, 가짜 다운로드 버튼이 눈에 띈다. 팀 단위로 신뢰 기준을 정하고, 의심스러운 링크는 격리된 브라우저 프로필이나 샌드박스 환경에서만 연다. 단축 URL은 원본을 확인하는 서비스를 통과시키자.
신뢰성 검증 체크리스트 도메인과 발행 주체가 명확한가. 기업 공식 블로그, 재단, 표준 기구 도메인인지 확인한다. 최근 업데이트가 살아 있는가. 페이지 하단의 마지막 수정일, Git 레포의 커밋 타임라인을 본다. 반례와 한계를 스스로 언급하는가. 일방적인 주장만 있는 글은 경계한다. 코드가 실행 가능한가. 예제 저장소, 샌드박스 링크가 있는 글을 우선한다. 상호 인용망이 건강한가. 권위 있는 문서나 레퍼런스를 적절히 연결하는지 살핀다. 학습 경로: 깊고 넓게 가져가기
무료 튜토리얼만 돌다가 금방 잊는 경우가 많다. 단계에 따라 리소스가 달라야 한다. 기초 문법과 패턴은 무료 강의와 공식 문서로 충분하다. 이 단계에서는 freeCodeCamp https://www.freecodecamp.org, MDN Learning Area, Go Tour https://go.dev/tour 같은 체험형 콘텐츠가 빠르다. 중급으로 올라서면 라이브러리 소스 리딩과 RFC 읽기가 필요하다. 예를 들어 HTTP 캐시를 제대로 이해하려면 RFC 9111을 직접 읽고, 브라우저 개발자 도구의 헤더 화면을 함께 본다. 고급 단계에서는 서비스 운영 기록을 읽는다. 장애 복구기와 아키텍처 재편 글이 논문보다 실용적이다.

문제를 먼저 정하고 학습 자원을 끌어오는 방식이 효율적이다. 예컨대 “3초 내 LCP를 달성한다”를 목표로 정하면, web.dev의 LCP 항목, 이미지 최적화 도구, CDN 캐시 정책, 폰트 로딩 전략 링크가 목적에 맞춰 엮인다. 이때 북마크 폴더 안에서 목표별 하위 폴더를 잠시 쓰고, 과제가 끝나면 요약 문서로 축약해두면 재사용성이 생긴다.
팀 공유와 유지보수: 링크를 설명으로 만들기
좋은 링크모음은 개인의 두뇌 확장일 뿐 아니라 팀의 온보딩 도구다. 신입이 입사해 반나절 만에 개발 환경을 갖추고 첫 PR을 보낼 수 있도록, 링크에 문장을 붙여 문맥을 제공한다. 예를 들어 “사내 API 스타일 가이드 - OpenAPI 3.1 기반, 예시 포함, 금지 헤더 목록 링크”처럼 제목만 봐도 범위를 알 수 있어야 한다. 링크 길이에 흔들리지 않고 설명 문장이 기준이 되면, 주소가 바뀌어도 대체 링크를 쉽게 찾는다.

링크 정리는 주기적으로 소거가 필요하다. 잘 쓰던 도구가 더 이상 필요 없게 되는 순간도 온다. 브라우저 북마크 대신 사내 위키나 리포지토리 README로 옮겨 두면 검토 사이클에 자연스럽게 편입된다. PR 리뷰 중 링크가 낡았다는 지적이 올라오면 그 자리에서 갱신한다. 링크도 코드처럼 살아 있어야 한다.
예시: 하루 업무 동선에 붙인 링크
아침에 CI 빨간 불이 떴다. GitHub Actions 페이지에서 실패한 스텝 로그를 열고, 실패한 테스트 케이스의 실패 메시지를 검색한다. 관련 이슈를 찾지 못해 레포 Discussions와 Release notes를 확인한다. 의존 패키지 버전 문제로 보이면 npm 패키지 페이지에서 최근 버전과 브레이킹 체인지 여부를 보고, 필요시 이전 버전으로 고정한 뒤 Renovate 봇 설정을 조정한다. 수정이 끝나면 Preview 환경에 반영하고, Cloudflare의 Caching 문서를 보며 특정 경로를 Purge한다. 동시에 Lighthouse CI로 성능 회귀가 없는지 체크한다. 관련 링크는 모두 디버깅 폴더와 배포 폴더에서 바로 꺼내 쓴다. 점심 이후에는 팀 회고 문서에 “의존성 잠금 전략 업데이트” 항목을 추가하고, 관련 공식 문서와 사내 규약 링크를 붙여 둔다. 이 정도 흐름이면 대화가 길어지지 않는다.
실전 링크 샘플: 주제별 대표 주소
명세와 레퍼런스
MDN Web Docs: https://developer.mozilla.org TC39 ECMAScript: https://tc39.es/ecma262 IETF Datatracker: https://datatracker.ietf.org RFC Editor: https://www.rfc-editor.org W3C TR: https://www.w3.org/TR/
생태계와 코드
GitHub: https://github.com GitLab: https://gitlab.com Sourcegraph: https://sourcegraph.com Npm: https://www.npmjs.com PyPI: https://pypi.org
클라우드와 배포
AWS Docs: https://docs.aws.amazon.com GCP Docs: https://cloud.google.com/docs Azure Docs: https://learn.microsoft.com/azure Cloudflare Developers: https://developers.cloudflare.com Kubernetes Docs: https://kubernetes.io/docs
품질과 보안
Web.dev: https://web.dev Lighthouse Docs: https://developer.chrome.com/docs/lighthouse OWASP: https://owasp.org NVD: https://nvd.nist.gov Osv.dev: https://osv.dev
한국어 기술 블로그
Naver D2: https://d2.naver.com Kakao Tech: https://tech.kakao.com/blog LINE Engineering: https://engineering.linecorp.com/ko/blog 우아한형제들 기술블로그: https://techblog.woowahan.com 토스 테크: https://toss.tech
유틸리티
Regex101: https://regex101.com JSONLint: https://jsonlint.com Squoosh: https://squoosh.app Ngrok: https://ngrok.com DevDocs: https://devdocs.io 마무리 메모
좋은 사이트 주소모음은 양보다 선택 기준이 만든다. 팀이 공유하는 기준과 흐름, 즉 어느 순간에 어떤 링크를 우선 확인하느냐가 시간과 품질을 가른다. 소개한 링크들은 이미 수많은 개발자가 검증하고 개선해 온 공용 자산이다. 여기에 팀 고유의 런북과 현황판, 사업 맥락을 담은 글을 얹으면 비로소 그 팀만의 지도가 된다. 비슷한 문제를 다시 만났을 때 같은 길을 더 빨리, 더 안전하게 걸을 수 있도록 링크를 다듬어 두자.