AI 구독을 끊는 게 답일지도 모른다는 개발자의 고백

• 글쓴이는 AI로 만든 것들을 쭉 나열하면서 시작함. 리스트만 보면 꽤 미쳤음

  • 러스트 음성 인식 시스템, 이메일 아카이브 렌더러, Jellyfin 데스크톱 클론, Invidious 클론, Windows 95 메모장 클론, 교통량 측정 비전 도구, 지역 뉴스 사이트, 3D 자동차 게임, 투자 백테스터, 러스트 SaaS까지 있음
  • 본인 말로는 이미 지운 프로젝트도 50개쯤 더 있음
  • 그런데 결론은 시원함. “SaaS 빼고 거의 쓸모없고, 유지하고 싶지도 않다”임

• 문제는 AI가 못해서가 아니라 너무 쉽게 만들게 해준다는 쪽에 가까움

  • 처음에는 보통 “X용 간단한 스크립트 하나만 짜줘”로 시작함
  • 한 시간 뒤에는 간단한 스크립트도 아니고, 원래 문제도 해결되지 않았고, 이상한 새 프로젝트만 남는 경우가 많았다고 함
  • “AI 툴링을 배웠다”는 말로 포장할 수는 있지만, 실제로는 시간·관심·토큰 비용을 계속 먹는 유지보수 부채가 된다는 얘기임

• 저자는 AI를 주의력 관점에서 꽤 세게 깜. 표현이 강함. “열핵급 ADHD 증폭기”라고 부름

  • 주변 성인 친구들에게서도 비슷한 패턴을 봤다고 함
  • 화면 3개를 띄워놓고 서로 관련 없는 프로젝트를 동시에 굴리는데, 유지 가능성도 낮고 결과물에 대한 헌신도 약함
  • 매달 누군가는 “멋진 도구 만들고 있다”는 스크린샷을 보내지만, 정작 “어디서 사용자 모을 건데?”라는 질문에는 LLM 이전과 똑같이 답이 없다는 것

• AI 도구의 설계 방향도 문제로 봄. 거의 모든 벤더가 더 많은 사용량을 원한다는 지적임

  • 더 많은 토큰, 더 많은 출력, 더 많은 상호작용이 제품 지표에 유리함
  • 간단한 예/아니오 질문에도 후속 질문을 붙여 대화를 이어가게 만드는 식의 설계를 예로 듦
  • 저자는 5분 만에 1만 줄짜리 테스트 없는 Python/JS 난장판을 뽑아내는 게 아무에게도 도움이 안 된다고 말함

• 그래도 기술 자체를 낮게 보진 않음. 오히려 잘 쓰면 엄청나다고 인정함

  • 난해한 문법의 파서를 생소한 언어로 테스트까지 포함해 만들어달라고 하면 뚝딱 나오는 수준이라고 함
  • Claude 사용량을 줄이려고 Pro로 낮췄지만, 서비스 품질 문제로 Codex로 옮긴 뒤 다시 사용량이 올라갔다고 함
  • Codex CLI는 Claude보다 더 좋고 빠르게 느꼈다고 적음
  • 문제는 모델 능력이 아니라, 지금의 도구 환경이 신중한 사용을 유도하지 않는다는 점임

• 글의 두 번째 큰 축은 “마찰이 집중을 만든다”는 주장임

  • 예전에 음성 인식으로 말하면 자동으로 블로그 글을 생성하는 파이프라인을 만든 적이 있음
  • 텔레그램 음성 메모 버튼만 누르면 Opus 스타일 글이 나오는 구조였음
  • 결과는 “거침없는 쓰레기”였다고 함
  • 노력이 사라지자 헌신도 사라지고, 헌신이 사라지자 집중도 사라지고, 결국 의미 있는 결과물도 사라졌다는 해석임

• 이 대목에서 글쓴이는 꽤 중요한 구분을 함. 말하기와 좋은 글쓰기는 다르다는 것

  • 일상 대화는 낮은 정보 밀도의 노이즈에 가깝다고 봄
  • 좋은 글은 더 잘 다듬어진 개념으로 높은 정보 밀도를 담아내려는 시도임
  • 그러니 대화를 그대로 AI 렌즈에 통과시킨다고 좋은 글이 나올 리 없었다는 반성으로 이어짐
  • 비슷한 이유로, 품질이 중요한 한 손글씨는 절대 완전히 구식이 되지 않을 거라고까지 말함

• 칼 뉴포트의 ‘가짜 생산성’ 논의도 끌어옴

  • 디지털 생산성 도구와 AI는 개별 작업을 빠르게 만들지만, 지식 노동자를 더 바쁘고 산만하게 만들 수 있음
  • 연구에 따르면 AI 사용자는 이메일, 메시징, 채팅, 업무 관리 도구에서 더 많은 시간을 쓰고, 집중해서 끊김 없이 일하는 시간은 줄어들 수 있다고 함
  • 눈에 보이는 바쁨이 실제 가치의 대리 지표가 되는 순간, 더 많은 초안·메시지·회의·작업 산출물이 오히려 함정이 됨

• 마지막 결론은 꽤 씁쓸함. AI의 진짜 기여가 “이런 싸구려 보상 루프가 얼마나 위험한지 깨닫게 해준 것”일지도 모른다는 얘기임
  • 입력은 적고 보상은 빠르게 주는 도구는 쉽게 중독적인 작업 흐름을 만듦
  • 더 빠른 개발이 더 많은 앱을 뜻하고, 더 빠른 이메일이 더 많은 커뮤니케이션을 뜻한다면 그게 정말 좋은 목표냐고 묻는 셈임
  • 결국 단위 시간의 삶을 어디에 쓰는지가 핵심이지, 산출물 개수가 핵심이 아니라는 주장임

---

기술 맥락

• 이 글에서의 기술적 선택은 어떤 AI 도구를 쓰느냐보다, AI 도구에 얼마나 마찰을 남겨둘지에 가까워요. 저자는 Claude에서 Codex로 옮겼고 CLI가 더 빠르고 좋다고 느꼈지만, 바로 그 편리함 때문에 사용량이 다시 늘었다고 말하거든요.

• 개발팀에서도 비슷한 문제가 생길 수 있어요. 에이전트 여러 개를 동시에 돌리면 겉보기에는 병렬 처리가 되는 것 같지만, 실제로는 검토해야 할 코드, 이어받아야 할 맥락, 버려야 할 산출물이 같이 늘어나요. 병목이 작성에서 판단으로 옮겨가는 셈이에요.

• 저자가 말하는 ‘마찰’은 생산성을 방해하는 장애물이 아니라 품질 필터에 가까워요. 손으로 쓰거나 직접 설계하는 과정에는 시간이 들지만, 그 시간이 “이걸 진짜 만들 가치가 있나”를 계속 묻게 만들기 때문이에요.

• 그래서 이 글은 AI 코딩 도구를 끄자는 단순한 주장이 아니에요. 도구가 너무 많은 코드를 너무 쉽게 만들 때, 팀은 작성 속도보다 유지보수 의지, 테스트, 배포 후 책임을 먼저 설계해야 한다는 얘기에 가까워요.