noaifridays.com이라는 사이트가 있습니다. 주장은 한 줄입니다. 소프트웨어 팀이 매주 하루는 AI 코딩 도우미를 끄고 직접 코딩하자.
HTMX의 CEO는 이미 팀에 의무화했고, 참여 기업 목록도 운영합니다.
왜 끄자는 건가
사이트가 드는 근거는 연구 네 갈래입니다. LLM 사용이 인지 부채를 쌓고, 업무 몰입을 낮추고, 비판적 사고를 방해하고, 기술 형성을 가로막을 수 있다는 것. 각각에 논문과 보고서가 걸려 있습니다.
여기에 실무 관찰 두 가지를 덧붙입니다.
AI를 계속 쓰면 의사결정의 절충점과 맹점이 안 보인다는 것. 무언가를 선택할 때 무엇을 포기했는지가 모델의 판단 안에 묻힙니다. 그래서 주 1회는 AI가 내린 선택과 개발 방향이 여전히 내 취향과 맞는지 돌아보는 데 쓰자는 겁니다.
그리고 AI를 기본값으로 두면 평범한 자동화 기회를 놓친다는 것. 스크립트 한 줄이면 될 일에 매번 모델을 부르게 됩니다. 토큰을 안 쓰는 하루가 장기적으로는 토큰 소비를 줄일 수 있다는 계산도 붙습니다.
마지막 이유가 개인적으로 제일 와닿습니다. 직접 만들던 시절의 몰입 상태와 작업의 연결감, 그리고 결과물에 대한 자부심을 되찾고 싶다는 것.
허용 기준이 흥미롭습니다
전부 끄는 게 아닙니다. greptile, prelint 같은 도구는 허용합니다.
기준이 명확합니다. 내가 쓴 코드에 피드백을 주는 도구인가, 아니면 코드를 대신 써주는 도구인가. 전자는 사람이 피드백에서 배울 수 있으니 허용, 후자는 금지.
“AI를 쓰냐 마냐”보다 훨씬 쓸모 있는 선입니다. 이 기준이라면 코드 리뷰, 린터, 타입 체커는 다 통과합니다.
기간은 조절 가능합니다. 업무 방식에 따라 주 1일보다 늘려도 되고, 최대 7일까지도 가능하다고 씁니다. 잠깐 Claude나 Codex를 쓰거나 몇 주 만에 그만두는 경우에 대해서는 금연·금주에 빗댄 농담으로 답합니다.
반론이 더 재밌습니다
Hacker News 토론이 이 제안에 꽤 박합니다. 몇 개는 옮길 만합니다.
“이 훈계 처음 아닌데.” 시스템을 이해하려면 인터프리터 말고 컴파일 언어를 써라, C에 익숙해져 퇴화하지 말고 어셈블리를 계속 써라, 계산기 때문에 암산이 죽지 않게 연습해라. 회로도와 계측기까지 거슬러 올라갑니다. 뛰어난 엔지니어는 더 깊은 계층까지 알지만, 평균적인 영향력의 소프트웨어를 만드는 개발자에게는 평균적인 결과물로 충분하다는 겁니다.
“그 경고는 맞았다.” 바로 반박이 붙습니다. 인터프리터와 가비지 컬렉션에 익숙해진 세대는 실제로 메모리와 캐시를 추론하는 능력을 잃었고, 작은 입력 폼 앱이 메모리 1GB를 쓰는 현실이 그 결과라는 것.
“천공카드 화요일.” 어릴 때 교사들이 “항상 주머니에 계산기가 있진 않다”며 암기를 시켰는데 지금은 다들 주머니에 계산기를 넣고 다닌다는 지적. 언젠가 AI 없는 금요일도 “화요일엔 천공카드만 씁시다” 같은 제안으로 보일 거라고 합니다.
가장 날카로운 건 이겁니다. 쓸지 말지의 양자택일이 아니라 어떻게 쓸지의 문제라는 것. 답을 대신 풀어달라고 하는가, 스스로 풀 수 있게 정보를 달라고 하는가. LLM을 인턴처럼 부리는 것과 튜터처럼 쓰는 것은 근본적으로 다르다는 겁니다.
**”날을 따로 정할 필요 없다”**는 의견도 있습니다. 설명하는 게 직접 하는 것보다 쉬우면 맡기고, 직접 하는 게 쉬우면 직접 한다. 매일 일부를 직접 하면 되지 수작업 전용일을 만들 이유가 없다는 것.
막힘의 경험. 문제를 붙들고 자다가 다음 날 아침에 해답이 떠오르는 일이 있는데, AI가 그 막힘 자체를 없애고 있다는 지적. 소셜 미디어가 지루함을 없앤 것과 같다고 비유합니다.
한편 자기 반증도 있습니다. 학생들이 학습을 위해 AI 사용을 자제해야 한다는 걸 잘 이해하고 있더라는 설문 얘기 뒤에, 표본이 60명 중 10명이라 통계적으로 유의하지 않다고 스스로 덧붙입니다.
자동화 블로그를 굴리면서 이 글을 읽으면
저는 지금 AI가 초안을 쓰는 파이프라인을 만들고 있습니다. 이 글 앞에서 좀 불편합니다.
그래서 저 허용 기준을 제 시스템에 대봤습니다. 내가 쓴 것에 피드백을 받는가, 대신 써주는가.
초안 생성은 명백히 후자입니다. 모델이 원문을 읽고 글을 씁니다.
반면 발행 전 원문 대조는 다릅니다. 원문과 초안을 나란히 놓고 창작·누락·논지 반전을 표로 뽑는 작업인데, 그 표를 읽으면서 제가 배웁니다. 어떤 프롬프트가 어떤 오류를 만드는지, 어떤 소스가 어떻게 잘리는지. 실제로 이 과정에서 파이프라인 결함을 여러 개 찾았습니다.
같은 모델을 쓰는데 배우는 쪽과 안 배우는 쪽이 갈립니다. 도구의 문제가 아니라 내가 그걸 어디에 놓느냐의 문제라는 게, HN 댓글의 마지막 지적과 같은 얘기입니다.
주 1회 다 끄는 것보다 제게 맞는 규칙은 이쪽인 것 같습니다. 초안을 그대로 발행하지 않는다. 이미 원칙 목록에 적어둔 문장인데, 이유를 하나 더 얻었습니다.
원문: https://news.hada.io/topic?id=33041
사이트: https://noaifridays.com/