개발자들이 더 이상 질문하지 않는다면

안녕하세요, 요즘 프로덕트 메이커입니다.

프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

1. 써볼 것: HackerTube - 카파시가 클로드와 대화만으로 2시간 만에 만든 해커뉴스판 유튜브
2. 참고할 것: 스택오버플로 새 질문이 한 달 1,000개 안팎으로 줄었다, 개발자는 이제 어디서 답을 찾을까
3. 적용해볼 것: AI가 95%를 맡으면, 사람은 남은 5%를 감당할 수 있을까

1. 써볼 것: 카파시가 클로드와 대화만으로 2시간 만에 만든 해커뉴스판 유튜브

퇴근하고 유튜브를 켰는데 과장된 썸네일과 매번 비슷한 추천 영상만 이어져서, 볼 만한 걸 찾다가 그냥 끈 적이 있을 거예요. 오픈AI 공동 창업자이자 테슬라에서 AI를 이끌었던 안드레이 카파시(Andrej Karpathy)도 그랬다고 합니다. 10월 30일 금요일 밤 11시, 카파시는 유튜브 첫 화면을 보다가 이 추천 방식이 인터넷의 평균적인 사람에게는 잘 맞을지 몰라도 자기에게는 맞지 않는다는 걸 깨달았죠.

해커뉴스(Hacker News)는 개발자와 창업자가 많이 모이는 미국의 기술 커뮤니티예요. 다음 날 아침, 카파시는 클로드 오퍼스 5.5에게 "해커뉴스에서 추천된 영상으로 우리만의 유튜브를 만들자"며 일을 맡겼습니다. 그렇게 나온 사이트가 HackerTube입니다. 카파시가 10월 31일 블로그에 공개했고, 해커뉴스에서 2,877점을 받았습니다.

무엇이 들어 있나요?

HackerTube에는 2007년부터 올해까지 해커뉴스 댓글 가운데 유튜브 영상을 추천한 댓글 약 4만 개를 모아, 여러 사람이 추천한 영상 6,454개를 주제 150개로 나눠 담았습니다. 화면은 유튜브와 거의 같지만 몇 가지가 다릅니다.

• 올린 사람이 고른 썸네일 대신, 영상 길이의 한가운데 장면을 썸네일로 씁니다. 카파시가 불만으로 꼽은 과장된 썸네일을 피하려는 것으로 보입니다.
• 회원가입 없이도 내 취향에 맞춘 추천을 받을 수 있습니다. 시청 기록은 서버가 아니라 내 브라우저에만 저장됩니다.
• 키보드 단축키로 조작할 수 있습니다.
• 사이트 데이터를 내려받을 수 있습니다. 카파시는 이 데이터를 AI 에이전트에게 주면 나만의 버전을 쉽게 만들 수 있다고 적었어요.

카파시는 무엇을 직접 했나요?

카파시가 블로그에 덧붙인 설명에 따르면, 이제 코드를 읽거나 쓰고 터미널에 명령어를 입력하는 식의 개발을 거의 하지 않습니다. 앤트로픽의 AI 코딩 도구인 클로드 코드(Claude Code)의 맥용 데스크톱 앱에서 오퍼스 5.5와 대화만 하며 모든 일을 맡긴다고 해요.

HackerTube를 만들 때도 해커뉴스 댓글을 모두 내려받아 거르는 일은 클로드가 했습니다. 이어서 클로드 코드의 워크플로(Workflow) 기능으로 여러 AI 작업을 한꺼번에 돌려, 더 저렴한 모델인 소넷이 댓글을 하나하나 읽고 스팸을 걸러내게 했습니다. 유튜브처럼 보이는 화면도 클로드가 만들었어요. 전체 작업에는 약 2시간이 걸렸습니다.

카파시가 직접 한 일은 세 가지였습니다.

• 유튜브 영상 정보를 불러올 때 필요한 인증 값(API 키)을 구글 클라우드에서 발급받기
• 사이트를 올릴 가상 서버(VPS) 켜기
• 도메인 구매하기

세 가지 모두 본인 계정으로 가입하거나 결제해야 하는 일이라 AI에게 넘기기 어려웠던 것으로 보입니다. 서버가 준비되자 그 주소만 알려주고, 사이트를 서버에 올려 보안을 설정하고 속도를 높이는 일은 다시 클로드에게 맡겼습니다. 카파시는 이 일들을 클로드가 일하는 사이사이에 처리해서 "조금은 팀으로 일하는 느낌"이었다고 적었습니다.

HackerTube를 보고 다른 사람들도 만들었습니다

HackerTube가 화제가 되자 비슷한 사이트가 사흘 사이에 잇따라 나왔습니다.

• HackerBooks(11월 1일): 해커뉴스 댓글에서 두 명 이상이 언급한 책 약 1만 6,500권을 모았습니다. 책마다 그 책을 언급한 댓글로 연결됩니다. 만든 사람은 데이터 처리부터 사이트까지 거의 다 클로드가 만들었고, 자신은 주로 방향을 정하고 판단을 내렸으며 도메인을 샀다고 밝혔어요. 언급 횟수만 세기 때문에 책을 칭찬한 댓글과 비판한 댓글이 똑같이 한 번으로 잡힌다는 한계도 함께 적었습니다.
• Wikihack(11월 2일): 해커뉴스 댓글에서 여러 사람이 링크한 위키백과 문서를 많이 링크된 순서대로 보여줍니다.
• HackerTV(11월 3일): HackerTube의 영상 데이터를 주제별 채널로 묶어 24시간 방송처럼 틀어줍니다. 고르지 않고 채널을 돌리며 보고 싶었다는 게 만든 이유였어요. 밤 11시부터 새벽 5시까지만 방송하는 심야 채널도 있습니다. 이 사이트도 클로드 코드로 몇 시간 만에 만들었습니다.

누구에게 좋을까요?

• 추천 알고리즘에 지쳐서 오래 볼 만한 강연이나 다큐멘터리를 찾는 사람. hackertube.org에 들어가면 가입 없이 바로 볼 수 있습니다.
• 사이드 프로젝트를 구상 중인 기획자와 디자이너. 공개 데이터와 AI 코딩 도구만으로 2시간 만에 서비스 하나를 만든 과정과, 사람이 직접 해야 했던 일이 무엇이었는지 참고할 수 있습니다.
• 커뮤니티나 콘텐츠를 운영하는 사람. 우리 서비스 댓글에 쌓인 추천을 모아 보여주는 서비스도 같은 방식으로 만들어볼 수 있습니다.
• 다만 영상 대부분이 영어이고, 해커뉴스 사용자의 관심사인 개발, 과학, 공학 쪽에 치우쳐 있습니다. 카파시는 사이트를 만들고 운영하는 데 든 비용은 밝히지 않았습니다.

2. 참고할 것: 스택오버플로 새 질문이 한 달 1,000개 안팎으로 줄었다, 개발자는 이제 어디서 답을 찾을까

개발자라면 에러 메시지를 그대로 검색창에 붙여넣었다가 스택오버플로(Stack Overflow) 답변에서 해결법을 찾은 경험이 한 번쯤 있을 거예요. 스택오버플로는 2008년 문을 연 개발자 질문·답변 사이트입니다. 10월 말, 이 사이트에 올라오는 새 질문이 한 달 1,000개도 안 된다는 그래프가 개발자 커뮤니티에서 화제가 됐습니다.

얼마나 줄었나요?

스택오버플로가 외부에 공개한 데이터 조회 기능(API)으로 월별 새 질문 수를 직접 세어봤습니다(11월 5일 기준).

• 질문이 가장 많던 무렵인 2014년 3월에는 한 달에 20만 7,169개가 올라왔습니다.
• ChatGPT가 공개되기 직전인 2022년 10월에는 10만 5,743개였습니다.
• 올해 9월에는 964개, 10월에는 1,001개였습니다.

ChatGPT가 나오고 4년이 채 안 돼 질문 수가 100분의 1 수준으로 줄었어요. 다만 이 숫자에는 삭제된 질문이 빠져 있어서, 같은 달이라도 집계한 날짜와 사람에 따라 숫자가 조금씩 다릅니다.

원인은 AI뿐일까요?

질문 수는 ChatGPT 이전부터 줄고 있었습니다. 2017년 3월 20만 1,343개였던 질문이 2022년 3월에는 12만 3,260개로, 이미 40% 가까이 줄어 있었어요. AI가 감소를 크게 앞당긴 건 분명해 보이지만, 줄어들기 시작한 건 그전부터였습니다.

개발자들 사이에서는 운영 문화를 원인으로 꼽는 목소리도 오래 있었습니다. 질문하러 온 사람에게 날 선 답을 달거나 질문을 쉽게 닫아버리는 일이 잦았다는 거예요. 미국 개발 매체 데브클래스(DevClass)는 1월 기사에서 한 개발자의 말을 인용했습니다. "AI가 감소를 앞당긴 건 맞지만, 이건 커뮤니티에 참여하려는 사용자에게 꾸준히 벌을 줘온 결과다. 사람들은 마침내 질문이 멍청하다고 말하지 않는 도구가 생겨서 그저 반가웠던 것이다."

개발자들은 이제 어디서 답을 찾나요?

스택오버플로가 10월 6일 발표한 2026 개발자 설문(3만 명 이상 응답)에서도 개발자가 답을 찾는 방법이 달라진 게 보입니다.

• 막혔을 때 검색엔진을 찾는다는 응답은 83%, AI에게 묻는다는 응답은 70%였습니다.
• 업무에 필요한 답은 동료(72%), 코드(63%), 문서(60%)에서 찾는다는 응답이 많았습니다.
• 간단한 질문 때문에 스택오버플로를 찾는 일은 줄었다는 응답이 64%였습니다. 반대로 AI가 준 답의 출처를 확인하려고 더 자주 찾는다는 응답도 16% 있었어요.
• AI가 준 결과를 믿으려면 출처 표시가 필요하다는 응답은 93%였습니다.

스택오버플로는 설문 결과를 소개하며, 예전에는 검색엔진이 사람들을 스택오버플로 질문으로 데려왔지만 검색 결과 위에 뜨는 AI 요약과 챗봇은 그러지 않는다고 적었습니다. AI는 여전히 스택오버플로의 답변을 쓰지만, 답을 단 사람에게 늘 공을 돌리지는 않는다고도 덧붙였습니다.

스택오버플로는 어떻게 답했나요?

10월 29일, 스택오버플로는 공식 블로그에 "스택오버플로가 죽었다는 소문은 과장됐다"는 글을 올렸습니다. 스택오버플로가 죽었다고 보는 사람들은 지식을 찾는 방법이 바뀐 것을, 그 지식과 회사가 사라진 것으로 착각하고 있다는 주장이에요. 글에 따르면 질문·답변 사이트는 회사 사업의 일부일 뿐입니다.

• 사람이 검증한 스택오버플로의 답변은 AI 모델을 학습시키고, AI가 답할 때 참고 자료를 찾아오는 기능을 개선하는 데 쓰입니다. 스택오버플로는 이 데이터를 AI 회사에 라이선스로 판매하고 있습니다.
• 기업용 서비스 스택 인터널(Stack Internal)의 새 버전을 9월에 냈습니다. 회사 안의 지식을 모아 출처와 신뢰 표시를 붙이고, 확인이 필요하면 사내 전문가를 연결해주는 서비스입니다.
• AI 에이전트끼리 지식을 나누고 해결책을 검증하는 Stack Overflow for Agents를 베타로 열었습니다.

회사는 답을 찾으러 들르는 웹사이트를 넘어, 개발자와 회사, AI가 함께 쓰는 지식 서비스로 바뀌는 중이라고 설명했습니다.

무엇을 얻어가면 될까요?

제품의 도움말 센터나 사용자 커뮤니티를 운영하고 있다면 같은 일이 생길 수 있습니다. 사용자가 궁금한 걸 AI에게 먼저 물으면, 간단한 질문 때문에 도움말 페이지에 들어오는 사람은 줄어들 거예요. 그래도 설문에 응답한 개발자의 93%가 AI의 답을 믿으려면 출처가 필요하다고 답했습니다. 사람이 확인한 답변은 AI가 인용하는 출처로 여전히 쓸모가 있을 것으로 보입니다.

3. 적용해볼 것: AI가 95%를 맡으면, 사람은 남은 5%를 감당할 수 있을까

회의록 요약, 데이터 정리, 문서 초안을 AI에게 맡기는 게 이제 익숙해졌습니다. 그런데 어느 날 AI가 풀지 못하는 일이 생기면, 그 일을 직접 해낼 수 있을까요? 이 질문을 다룬 글이 최근 개발자 커뮤니티에서 다시 화제가 됐습니다. 오픈소스 관측 도구 SigNoz의 뉴스레터에 올해 2월 실린 글로, 제목은 "AI는 SRE를 대체하는 게 아니라, SRE의 실력을 떨어뜨리고 있다"입니다.

SRE(사이트 신뢰성 엔지니어)는 서비스가 멈추지 않게 운영하고, 장애가 나면 원인을 찾아 복구하는 엔지니어입니다. 관측 도구는 서버의 상태 지표와 기록(로그)을 모아 보여주며 이 일을 돕습니다. 글은 SRE를 예로 들지만, 글쓴이도 이 이야기가 SRE에만 해당하지 않는다고 말합니다.

1983년 논문은 무엇을 말했나요?

글쓴이는 1983년 영국 인지심리학자 리잰 베인브리지(Lisanne Bainbridge)가 쓴 논문 「자동화의 아이러니」에서 출발합니다. 베인브리지는 공장과 산업 설비가 자동화된 뒤 그곳에서 일하는 사람에게 무슨 일이 생겼는지 살폈어요.

자동화할수록 사람이 할 일은 줄어듭니다. 하지만 자동화가 실패하는 드문 순간에는 사람이 나서야 하고, 그 순간의 판단은 오히려 더 중요해집니다. 문제는 평소에 그 일을 해볼 기회가 없으니, 정작 나서야 할 때 더 서툴러진다는 점이에요. 그래서 베인브리지는 사람이 오랫동안 지켜보기만 하다가 가끔 터지는 위기만 떠맡게 된다고 봤습니다.

SRE의 일도 비슷하게 바뀌고 있습니다. 쏟아지는 알림을 묶어 정리하고, 해결법이 알려진 문제에 정해진 대응 절차를 실행하고, 로그에서 이상한 패턴을 찾는 일은 이미 상당 부분 자동화됐어요. 장애 알림 서비스 페이저듀티(PagerDuty)는 장애를 세 단계로 나눠 설명합니다.

• 원인과 해결법을 아는 장애는 완전히 자동으로 처리합니다.
• 일부만 이해한 문제는 AI가 해결책을 제안하고 사람이 확인합니다.
• 처음 보는 복잡한 장애는 사람이 주도하고 AI가 정보를 보탭니다.

글쓴이는 여기서 묻습니다. 사람이 처음 보는 장애만 맡게 된다면, 그런 장애를 다룰 감각은 어디서 기를 수 있을까요? 그 감각은 수년 동안 장애에 직접 대응하며 같은 패턴을 반복해서 겪어야 생기는 것이니까요.

다른 분야에서는 무슨 일이 있었나요?

글쓴이는 다른 분야의 연구도 함께 소개합니다.

• 의료: 의학 학술지 「랜싯 소화기학·간장학(The Lancet Gastroenterology & Hepatology)」에 실린 연구에서, 대장 내시경 때 AI와 함께 검사한 뒤로 의사들은 AI 없이 검사할 때 용종을 찾아내는 비율이 28%에서 22%로 떨어졌습니다. 이론을 잊어서가 아니라 직접 찾는 연습을 덜 하게 돼서였다고 글쓴이는 설명합니다.
• 항공: 자동 비행 장치에 많이 기대는 장거리 노선 조종사들은 주변 상황을 파악하는 능력과 손으로 비행기를 다루는 실력이 떨어졌다는 연구가 있습니다. 글쓴이에 따르면 미국 연방항공청(FAA)은 이 때문에 수동 비행 시간을 늘리도록 했습니다.

글쓴이는 자기 이야기도 털어놓습니다. 지난 1년 사이 AI가 가끔 꺼내 쓰는 도구에서 늘 가장 먼저 손이 가는 도구가 됐고, 이제는 AI에게 맡길 수 없는 일에만 머리를 쓰다 보니 생각하는 힘이 무뎌진 게 느껴진다고요.

더 위험한 건 실력이 떨어지는 걸 본인이 알아채기 어렵다는 점입니다. AI 덕분에 일이 쉬워지고 결과도 좋아 보이니, 실제 실력이 어느 정도인지 가늠하기 힘듭니다. SRE라면 AI가 요약해주니 원본 로그를 읽지 않게 되고, AI가 원인을 제안해주니 장애 중에 스스로 가설을 세우지 않게 됩니다. 하나하나는 일이 빨라진 것처럼 보이지만, 이런 일이 쌓이면 예상 못 한 장애를 다룰 실력이 사라지죠.

글쓴이는 "never-skilling"이라는 말도 소개합니다. 이미 갖고 있던 실력을 잃는 게 아니라, 처음부터 실력을 쌓지 못하는 문제예요. AI가 대응을 대부분 맡는 환경에서 일을 시작한 신입은 직접 부딪히며 감각을 기를 기회가 거의 없습니다.

반대 의견도 있습니다. 원문에 달린 한 댓글은 "AI 도입이 앞으로 나아갈 유일한 길"이라는 글쓴이의 전제를 이 글의 약점으로 꼽았어요. AI를 쓰는 게 이미 정해진 결론처럼 여겨지는 게 불편하다며, 필요한 곳에만 도구를 만들어 쓰던 예전 방식으로는 왜 안 되느냐고 물었습니다.

무엇을 생각해볼 수 있을까요?

글쓴이는 AI를 쓰지 말자는 게 아니라고 분명히 하면서 두 가지를 제안합니다. 여기에 AI 기능을 만드는 쪽에서 생각해볼 점을 하나 더했습니다.

첫째, 일부러 비효율을 남겨둡니다. 자동 비행 장치가 있어도 조종사에게 수동 비행 시간을 두게 하는 것처럼, AI가 처리할 수 있는 장애 가운데 일부는 사람이 연습 삼아 직접 맡는 방식입니다. 가장 빠른 해결은 조금 포기하더라도, 길게 보고 실력을 유지하는 데 시간을 쓰자는 제안이에요.

둘째, 사람이 AI의 결과를 승인만 하지 않고 문제를 함께 풀게 합니다. AI의 제안에 승인 버튼만 누르는 구조에서는 사람이 지켜보는 역할로 밀려나고, 앞서 본 「자동화의 아이러니」 논문이 말한 것처럼 주의력이 점점 떨어집니다. 사람이 직접 문제를 들여다보고 AI와 함께 원인을 좁혀가는 구조여야 생각을 멈추지 않는다는 이야기입니다.

셋째, 이 고민은 AI 기능을 만드는 쪽에도 해당합니다. SigNoz는 자기 제품에 AI를 넣으면서, 처음에는 사람이 통제하는 보조 기능으로 시작하고 신뢰가 쌓이는 만큼 AI가 스스로 하는 일을 넓히겠다고 밝혔어요. 자사 제품 이야기라는 점은 감안하고 보면 좋겠습니다. 다만 AI 기능을 만들고 있다면, 그 기능이 사용자의 어떤 실력을 대신하는지는 따져볼 만합니다.

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!

이 글은 AI의 도움을 받아 작성했습니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.