LLM 번아웃이 온 것 같아요

 (alecscollon.com)
2P by GN⁺ | ★ favorite | 댓글 2개
  • 업무와 개인 작업에서 Claude Code, Codex, ChatGPT, Gemini를 매일 쓰면서 몇 년 전보다 AI 생성 텍스트를 읽는 시간이 크게 늘어남
  • 개발 흐름은 직접 설계·구현하던 방식에서 설계 설명 → LLM 코드 검토 → 직접 수정으로 바뀌었고, 낯선 영역에서도 더 쉽게 작업하게 됨
  • 현재 프로젝트도 대규모 비감독 코드 생성 프레임워크와 Qwen 에이전트 출력 검토가 중심이라 LLM 콘텐츠를 계속 읽는 구조임
  • 약 1년간 사용이 이어진 뒤 최근 몇 달 사이 허위 가정, 환각, 단정적인 짧은 문장, 과도한 이모지 같은 반복 패턴이 부담으로 쌓임
  • LLM 자체보다 같은 문체와 같은 종류의 오류가 반복되는 점이 피로의 핵심이며, 개인화 기능이 있어도 다른 사람이 만든 AI 콘텐츠의 스타일은 통제하기 어려움

개발 흐름에 깊숙이 들어온 LLM

  • 본인의 LLM 사용량은 현재 개발자 기준으로 평균적이고, 사용 방식도 아직 원시적인 편이라고 봄
    • 한 번에 하나의 작업을 처리하며 회사에서는 Claude Code, 집에서는 현재 Codex와 대화함
    • 어시스턴트가 코드를 쓰게 할 때도 출력은 꼼꼼히 읽고 이해한 뒤 직접 수정함
    • 자율 에이전트나 에이전트 오케스트레이션을 깊게 쓰는 단계는 아님
  • 작업 방식은 코드 설계와 작성 중심에서, 설계를 LLM에 설명하고 LLM이 만든 코드를 검토한 뒤 다시 코드를 쓰는 형태로 바뀜
    • 이 과정에서 미처 고려하지 못했거나 몰랐던 접근을 접함
    • 깊은 지식이 없는 영역에서도 더 편안하게 작업함
  • 현재 핵심 프로젝트는 코드베이스 안에서 대규모 비감독 코드 생성을 위한 프레임워크를 세우는 일임
    • Claude로 도구를 만들지 않을 때는 비감독 에이전트인 Qwen의 출력을 검토함
    • 어느 쪽이든 LLM이 만든 콘텐츠를 계속 읽게 됨
  • 정보를 찾을 때도 특정 사이트를 알고 있지 않으면 ChatGPT에 묻거나 Gemini의 개요를 읽는 경우가 많음
    • LLM 답변이 틀리면 다시 브라우징으로 돌아가야 함
    • 검색 결과에 쓸모없는 AI 생성 글이 많을 때는 LLM 답변도 일상적인 질문에는 충분히 괜찮다고 봄

같은 문체와 같은 실수가 쌓이는 피로

  • 이런 사용 방식은 약 1년 이어졌고, 당장 멈출 생각은 없음
    • LLM을 쓰면 더 생산적이라고 느낌
    • LLM을 효과적으로 쓰는 방법을 계속 배우는 것도 가치 있다고 봄
  • 최근 몇 달 동안 LLM 출력 읽기에 대한 감각이 달라짐
    • 읽기 전부터 어떤 문체와 오류를 보게 될지 안다는 느낌이 부담으로 작용함
    • 반복적으로 보이는 요소는 허위 가정, 환각, 단정적인 짧은 문장, 과도한 이모지임
  • 각각의 불편함은 따로 보면 견딜 수 있지만, 함께 반복되면서 LLM 글쓰기에 빠르게 질리게 됨
  • 핵심은 LLM이 인간보다 더 나쁘다는 비난이 아니라 반복성임
    • 인간도 신뢰하기 어렵거나 성가실 수 있음
    • LLM은 같은 스타일로 쓰고 같은 종류의 실수를 반복함
    • 인터페이스가 제공하면 개인화 기능을 쓸 수 있지만, 일부 특유의 문체는 남아 있음
    • 다른 사람이 생성한 콘텐츠의 스타일은 직접 통제할 수 없음
  • 아직 이 감정을 어떻게 다룰지는 알 수 없으며, 불안정한 도구에 대한 좌절을 넘어 글쓰기 패턴 자체가 계속 거슬리는 상태임

함께 보면 좋은 글 β

amebahead   [-]

저도 LLM이 답변하는 허위 가정, 환각, 단정적인 짧은 문장, 과도한 이모지 패턴으로 고통받다가
ELI5 Rule을 만들어서 적용해서 고통에서 벗어났습니다 :)

https://github.com/amebahead/explain-like-iam-five-rules

답변달기
GN⁺   [-]
Hacker News 의견들

  • 번아웃까지는 아니지만, LLM은 만들어내는 압박감 때문에 정말 지침. 아무도 업무량을 늘리라고 밀어붙이진 않지만, 매 순간 내 “클랭커”나 다른 사람의 “클랭커”가 만들어둔 무언가가 있고, 내가 막힌 걸 풀어줄 수 있는 상태임
    LLM 이전에도 따라가기 힘들었는데, 이제는 대기 중인 일이 항상 10배쯤 늘어난 느낌이고, 모두가 “최적화”해서 AI에 병렬로 더 빠르게 일을 먹이면 또 10배가 될 수도 있음. 모든 것의 병목으로 계속 서 있는 게 피곤함
    작은 사이드 프로젝트와 아이디어를 실현하는 건 즐겁지만, LLM이 “쉬면 시간 낭비”라는 건강하지 못한 사고방식을 더 먹여 살린다는 걸 깨달았고 바로잡아야겠다고 느낌
    글의 핵심 불만은 공장 자동화 때도 비슷했을 듯함. 숙련된 다양한 수공업이 조립라인 한 자리에서 하루 종일 같은 동작을 반복하는 일로 바뀐 것처럼, LLM도 창의적이고 변화 있는 부분을 가져가고 반복적인 QA 도장 찍기만 남겼음. 그때 쓰였던 완화책을 지금 다시 찾아볼 수 있을지도 모름

    • LLM이 생성한 문서 검토 요청이 너무 많이 옴. 기획 문서, 최종 사용자용 문서, 프로젝트 문서, 사업계획 문서 같은 것들임
      얼마 전 팀원이 LLM 생성 문서 30개쯤 들어 있는 zip 파일을 보내고 바로 검토해달라고 했는데, 상당수는 반복이거나 뜬금없는 조작·환각 내용이었음. 생성 속도가 검토 속도보다 훨씬 빠름
      예전엔 프로젝트 매니저가 기획 문서를 만드는 데 하루의 상당 부분이 걸렸지만, 이제는 몇 분 만에 만들어 검토로 던질 수 있어서 정말 지침
    • Charlie Chaplin의 Modern Times 공장 장면이 떠오름. 글쓴이가 느끼는 감정은 결국 사람이 기계의 속도에 맞춰야 하는 상황이고, 그 반대가 아님
      “역(逆) 켄타우로스”는 새롭지 않음. 지난 세기의 노동운동에 물어보면 됨
    • LLM이 지치게 만드는 이유 중 하나는 UI를 맞추려고 항상 프롬프트 하나만 더 하게 된다는 점임. 대개 살짝 어긋나 있는데, 그걸 다시 손보는 데 5~10분이 걸릴 때가 있음. 그 결과 훨씬 더 오래 일하게 됨
      복잡한 소프트웨어를 쓰는 것보다 제품을 만드는 걸 좋아하는 소프트웨어 엔지니어라서 더 그런 듯함. 무언가를 만들어내는 감각이 동기이고, 기능을 완벽하고 완성된 상태로 만들고 싶음. 하지만 UI 작업에서 95%에서 100%로 가는 길이 오래 걸림
      그래서 안타깝게도 지금은 근무 시간이 훨씬 길어졌음
    • “설거지를 대신해주는 기계가 생기면 창작에 집중할 수 있을 줄 알았는데, 정작 내 일을 해주는 기계가 생겨서 나는 설거지만 남게 됐다”는 느낌임
    • 다른 종류의 압박을 겪고 있음. 회사가 여전히 모두에게 LLM 사용을 요구하고, 토큰 순위표, 사용 시간 측정, 성과평가 반영까지 하고 있음
      그래서 생산적인 일을 멈추고 일정 비율의 시간을 떼어 “토큰 사용량을 보여주기 위해 AI를 해야” 함. 업무량은 그대로거나 늘었는데, AI 신들을 달래느라 실제 일할 시간은 N% 줄어듦

  • 내 경험상 번아웃 원인은 크게 3가지임. 첫째는 멀티태스킹이 가장 큼. 서로 다른 일을 하는 에이전트 창 3~5개를 자주 오가야 하고, 각 라운드가 몇 분씩 걸리면 극도로 지침
    코딩 에이전트 시대 전에는 대부분 개발자가 한 가지에 2시간 이상 집중할 기회가 있었을 것임. 이제 코딩 에이전트가 다룰 기술 스택의 폭은 넓혔지만, 깊이 일할 대역폭은 늘지 않았음
    둘째, 에이전트는 충돌 없이 돌아가게 만드는 데는 능하지만, 올바른 코드를 만든다는 보장은 없음. 기초 지식이 있는 인간 전문가와는 꽤 다름
    셋째, AI가 생성한 저품질 PR 더미를 검토할 때 좌절함. 집중력은 한정된 자원임. 남의 일에 에너지를 너무 쓰고 싶진 않지만, 더 신경 쓰지 않으면 사람 작성자의 신중한 사고와 설계 없이 만들어진 무책임한 AI 코드가 프로젝트 전체를 빠르게 망가뜨림. 신중함이 부족한 사람들과 일하는 것도 힘든데, 코딩 에이전트 시대에는 그들이 10배의 쓰레기를 만들어내니 10배 더 고통스럽고, 쉽게 강제할 수 없는 팀 문화 문제임

    • 동의함. 동시에 에이전트 워크플로 1~2개만 쓰도록 스스로 강하게 제한하려고 노력 중임. 그 이상은 감당이 안 되지만, “이 작은 수정 하나만” 하려고 에이전트를 띄우는 함정에 빠지기는 너무 쉬움

  • Opus 출력을 몇 시간씩 읽다 보면 약간 몸이 아픈 느낌이 들기 시작했음. 이 글이 정말 와닿음
    팀에도 불만을 말하기 시작했는데, 최소한 에이전트 규칙에 개인 스타일 가이드를 넣어서 em dash, “X가 아니라 Y다” 식 표현, 명사 앞에 수식어를 길게 늘어놓는 방식, “land”를 완료의 뜻으로 쓰는 것 등을 없애야 함. 이게 미성숙한 LLM의 한 단계일 뿐이길 바람

    • 봇들은 전부 특정 문구, 단어, 문장부호를 과용하는 패턴을 보임. 예로 요즘은 gate라는 말을 과하게 씀
      사람으로서는 gate가 열리거나 닫히고, 잠겼거나 잠기지 않았으며, 그 너머 길이 지나갈 수 있거나 없을 수 있는 “문”이라는 걸 앎. gate가 있다는 사실만으로 열렸는지 닫혔는지는 알 수 없음
      그런데 봇식 표현에서 gate는 통과 불가능한 강한 차단물만 뜻함. 울타리나 벽, 심지어 용암 해자 같은 것처럼 씀
      하지만 gate는 원래 지나가도록 설계된 물건인데, 봇은 통과 불가능하게 의도된 장애물에도 같은 말을 씀. 현실에서 수십 년간 gate를 다뤄본 기준으로는 오용임. 보통 닫힌 gate를 만나면 열고 지나가면 됨
      봇에게 그 단어 사용을 피하라고 지시해도 가끔 무시함. 오늘 떠오른 문제 단어가 gate일 뿐이고, 어제는 다른 단어였고, 내일은 또 완전히 다른 단어일 것임
      전체 패턴은 애초에 맞지도 않는 반복적이고 거슬리는 저급 전문용어임
    • 나도 그럼. 이런 걸 너무 많이 읽으면 정신 피해를 입는 느낌임
      “그냥 계약직 작업자의 나이지리아식 영어”라는 설명과 달리, 모델들이 강화학습 압력 아래에서 초간결하고 과하게 양식화된 자기들만의 방언을 만들어가는 것 같음. 점점 더 코드로 쓰는 느낌인데, 여기서 말하는 코드는 컴퓨터 코드가 아님. 단어들이 사람에게 뜻하는 바와 정확히 같지 않음
    • 오늘 바로 이 느낌을 설명하고 있었음. 아직 정확히 말로 옮기진 못했지만 실제로 약간 몸이 아픈 느낌이 듦. 가벼운 환공포증과 비슷한 듯함
    • arc land는 Phabricator 때문에 뇌에 각인돼 있어서 그 용어가 LLM보다 먼저 있었다는 건 알지만, 그래도 미치게 거슬림
      이런 언어적 흔들림은 되돌리기 불가능함. LLM 입력을 100% 걸러낼 수 있다 해도, 사람들 자신이 “land”를 더 자주 말하도록 학습하고 있음
    • 글쓰기에서는 목소리가 정말 중요함. 모두가 Opus로 쓰고 편집하지 않으면, 누가 썼든 전부 같은 소리로 들림

  • 지금 LLM만 쓰는 사람과 프로젝트를 하고 있는데, 지치고 정신적으로 소모됨
    무언가에 피드백을 주면 답은 그냥 “Claude에게 말해볼게”임. 그 사람은 전체가 어떻게 작동하는지 이해하지 못하고, 코드 대부분도 그걸 반영함
    며칠 전엔 로컬 환경을 설정하고 환경 변수를 잡는 방법조차 몰라서 데모 모드를 하드코딩해 넣었음. Claude가 왜 그걸 몰랐는지도 혼란스럽지만, 프롬프트 문제일 수도 있음
    나는 LLM 사용을 제한하고, 쓰더라도 극도로 구체적인 작업에만 쓰려 함. 내게는 그 방식만 통함
    회사들이 AI 코드 생성을 어떻게 이렇게 밀어붙일 수 있는지 솔직히 이해가 안 됨. 작은 프로젝트에서도 프로젝트 이해도가 금세 뒤처짐

    • AI 이전에도 이런 사람들과 일한 기억이 있음. 짜증은 났지만, 자신이 작업 중인 것을 충분히 이해하지 못해 좋은 코드를 효율적으로 만들지 못했기 때문에 생산성에서 고전했고, 보통 문제는 저절로 정리됐음
      이제는 LLM 코딩이 호기심 없는 사람을 장려하고 깊이 생각하는 사람을 벌주기 때문에, 이런 사람들이 잘 버틸 수 있게 됨
    • 나도 같은 방식임. 아주 구체적인 작업에만 씀. 방금도 의미가 크게 바뀌는 코드 5줄 수정을 하려고 Claude Code와 2시간 대화했음
      반면 친구는 무언가를 만들려고 에이전트 토큰에 하루 1만 달러를 쓰고 있음. 아주 똑똑하고 전직 개발자라서 단순한 AI 정신증 같은 건 아님
      아직도 이해하려고 하는 중임. 물론 나에겐 1만 달러가 없음
    • LLM이 생성한 코드는 불필요하게 난해하고 빽빽함

  • 정말 피곤함. LLM과 일하기 시작한 뒤 솔로 개발자로서 산출량이 쉽게 20배는 늘었음. 예전이라면 혼자 맡기엔 너무 야심찼을 고객 프로젝트까지 끝내고 있음
    오래된 코드베이스에는 몇 달씩 끌리거나 더 오래 기획 단계에 머물던 기능들이 들어가고 있음. 전체 품질도 훨씬 올라갔고, 테스트 커버리지도 더 완전하고 솔직히 더 좋아짐
    개인 프로젝트도 엄청난 속도로 만들고 있음. 역할이 뒤바뀌어서 에이전트를 내가 고객인 것처럼 대하고, 에이전트가 나인 것처럼 굴림. 물론 나는 더 기술적인 고객처럼 아키텍처 방향을 줌. 에이전트가 만든 앱과 도구를 매일 쓰고 있고, 직접 만든 도구 덕분에 SaaS 구독도 해지했음
    도구 호출을 보며 핵심 명령줄 도구를 더 잘 알아야겠다고 느껴서 하루 조금씩 따라잡는 학습 계획도 세웠음. 처음 vim과 tmux를 쓸 때 아무것도 모르고 넣어둔 오래된 설정도 다시 보고 있음
    이론상 생산성을 예전 수준으로 유지하고 책을 더 읽을 수도 있겠지만, 가능해 보이지 않음. “일은 줄어든다”는 약속과 달리 현실은 생산성과 기대치가 올라가는 거대한 전환기에 있는 느낌이고, 산업혁명이 적절한 비유처럼 느껴짐
    기대치 증가는 작고 큰 방식으로 일어남. 에이전트가 데이터 표현을 너무 잘 다듬어서, 예전엔 상당한 시간이 걸렸을 깔끔하고 시각적으로 임팩트 있는 보고서를 이제는 당연하게 보냄
    하지만 피곤함. Fable이 구독으로 제공되는 창구가 API 전용으로 바뀌기 전에 가능한 한 많은 일을 해치우려고 전력 질주 중임. 사람들이 어떻게 그렇게 많은 토큰을 쓰는지도 이해가 안 됨. 잠도 거의 안 자고 가능한 많은 코드를 Fable에 돌리는데도 20x max 플랜 한도에 거의 닿지도 못함
    내려가면 속도를 늦추겠다고 스스로 말해왔는데, 이제 12일까지 연장됐고 창도 리셋돼서 며칠 더 백로그를 쳐낼 수 있게 됨. 밤새 로봇들을 바쁘게 돌려놔야 아침에 일어나자마자 검토할 수 있다고 느낌. 휴대폰으로 에이전트에게 지시를 내리는 것도 스스로 이상하게 느껴짐

    • 산업혁명은 대규모로 삶을 낫게 만들었지만, 집에서 손으로 일하던 수직 직조공이 공장으로 옮겨 더 많은 산출을 내며 하루 종일 고되게 일하게 된 경우에는 삶을 낫게 만들지 않았음
      바깥에서 보면 이건 제분소에서 기계공으로 일하던 내 아버지와 비슷하게 들림. 그의 일은 대부분 기계가 일하는 걸 지켜보다가 고장 나면 고치는 것이었고, 90%의 시간은 잘 돌아갔음
      손으로 일하다가 기계를 지켜보는 쪽으로 바뀌면 정말 지루해 보일 수 있고, 그런 관점에서는 여기의 AI 반감을 이해할 수 있음
    • 자칭 LLM 중독자인 친구가 있는데, 거의 다 같은 이야기를 했음. 묻고 싶지만 직접 묻지는 못했던 질문은 이거임. 그렇게 번아웃이 올 정도라면 왜 그렇게 많은 개인 프로젝트를 계속 찍어내야 한다고 느끼는가?
      업무에서 AI 생성 코드를 잔뜩 검토하는 게 지친다는 데는 모두 동의할 수 있을 텐데, 왜 그 불쾌한 상황을 하루 전체로 확장하는지 궁금함
    • 전형적인 중독 신호임
    • 선택지가 이거라면 이상함. 예전엔 있는지도 몰랐던 생산성을 한 방울까지 짜내며, 아마 같은 돈을 받고 더 빨리 번아웃되고, 코딩의 즐거움도 없이 지치지도 좌절하지도 않는 멍청한 기계와 논쟁해야 함. 게다가 그 기계는 항상 목표에 조금 못 미침
      아니면 그냥 손으로 코딩하고, 복잡해지면 화이트보드 앞에서 생각하고, 지난 50년 넘게 소프트웨어 엔지니어링이 해온 것처럼 더 인간적인 속도로 천천히 번아웃되면 됨
      왜 이게 선택지인지 모르겠음. 진지하게 묻자면, 자기존중감이 조금은 있는가? “하지만 상사가 AI를 쓰길 기대한다”는 변명이 나올 거라 예상함. 대부분 진짜 번아웃을 겪어보지 않은 게 분명함. 닥치면 엄청난 고통이 올 것임. 스스로를 기계로 만들지 말아야 함. 인간은 기계가 아님

  • 번아웃은 없지만 글쓴이와 비슷하게 일하고 있음. LLM이 생성한 코드를 검토하는 흐름이 직접 쓰는 것보다 빠른 워크플로를 아직도 만들지 못했음
    이 딜레마에서 벗어나는 길은 사실 두 가지뿐임. 생성된 것을 맹목적으로 신뢰하거나, 가능한 모든 시나리오를 검증할 비정상적으로 방대한 단위 테스트 묶음을 만드는 것임
    그래서 비즈니스 로직은 직접 쓰고, 나머지 많은 부분을 LLM에 맡김. 보일러플레이트도 후자에 들어감

    • 바로 그걸 원해야 함. 사람이 만들거나 유지하기엔 비합리적일 정도로 훨씬 더 포괄적인 테스트가 모든 수준에 필요함. 단위, 기능, 전체 종단간 테스트와 그 이상까지 포함됨
      적대적 테스트가 AI를 궤도에 올려두고 읽어야 할 변경분을 깔끔하고 쉽게 만드는 가장 좋은 방법임. TDD식으로 “이 버그를 보여주는 테스트를 작성”하거나, 사후에 “새 테스트로 이 패치가 틀렸음을 증명”하는 방식 모두 해당함
      더 나은 방법은 더 강한 타입 언어를 써서 꽉 잠그는 것이지만, 테스트는 어떤 언어에서도 쓸 수 있음. TDD와 “테스트를 모두 작성하라” 배경이 AI와 일할 때 비밀 소스처럼 느껴짐
    • 코드를 그냥 조심해서 읽고 있음. 속도를 높이려고 나온 결과를 그대로 받아들이는 쪽으로 빠지기 쉽지만, 코드 읽기는 중요함
      테스트, 템플릿, 일부 UI, 꾸밈 요소 같은 것은 훑어보며 시간을 아낌. 하지만 백엔드 시스템에 들어가는 코드 대부분은 읽어야 함
    • 코드를 직접 쓰는 것보다 빠르게 검토할 수 없다면, 직접 쓰는 게 맞음
    • 비슷한 감정을 가진 사람들에게는 어떤 정신적 결함이 있어서 달콤한 Kool-Aid를 마시고 그냥 생성된 쓰레기를 쓰지 못하는 걸까 싶을 수 있음. 다 같이 즐기는 분위기를 망치려는 고집쟁이처럼 만드는 그 뒤틀린 특성이 뭘까 하는 식임
      개인적으로 LLM 마법에 가장 열광하는 사람들은 코드를 못 짜던 사람들임. 이제는 최선의 코드는 아니어도 동작하는 무언가를 들고 나올 수 있기 때문임. 동작하는 코드를 만들 수 있게 됐으니 모두를 더 낫게 만들 거라고 생각하지만, 그 쓰레기가 유지보수 가능한지, 애초에 쓰레기인지조차 알지 못함

  • 내가 LLM 번아웃을 겪는 이유는 상위 모델들이 명백히 거세되고 불투명하게 다운그레이드되는 걸 상대해야 하기 때문임
    지난 12개월 전까지만 해도 AI 회사들은 평범한 모델에서 최고의 결과를 짜내는 데 혈안이었음
    그런데 상위 모델이 발전하자, 같은 회사들이 이제는 너무 티 나지 않는 선에서 연산량, 즉 결과 하나를 만드는 비용을 최대한 줄이는 쪽으로 노력을 바꿈
    지난 36개월간 결과 품질의 기울기는 지수적으로 올라갔지만, 이제는 거의 평평해졌음
    내 생각에는 결과가 정체된 이유가 모델이 1년 전보다 훨씬 유능하지 않아서가 아님. 과도하게 몰린 사용자 기반의 엄청난 처리 비용을 아끼는 것이, 사용자의 명시적 지시를 따르고 최고의 결과를 내는 목표보다 우선되기 때문임. 특히 그 지시를 따르면 처리 비용이 더 드는 경우에 그렇음

    • 요즘 소비자용 AI 도구에 대해 나도 똑같이 느낌. Gemini와 ChatGPT가 최근 형편없었음. 이제는 여러 턴에 걸친 검색과 사고를 믿고 맡길 수 없음
      예전에는 7분 넘게 사고 모드에 머물 수 있었음. 예를 들어 “이 주장에 대한 출처를 찾아줘”라고 하면 검색하고 분석하고 질의를 스스로 조정했음. 요즘은 “Pro” 모드에서도 아무리 밀어붙여도 30초 이상 일하게 만들 수 없고, 일반적인 답만 내놓음
    • 정말 그런가? 처음의 “와 미쳤다” 단계가 지나가고 기대치가 현실을 만난 것일 수도 있음
    • 이건 너무 웃길 정도로 극단적인 역사 수정처럼 보임
      Opus 4.5 순간도 지난 11월이었고, 그때 에이전트식 코딩과 대부분의 코딩 CLI 도구가 진짜 일급 선택지가 됐음. 엄청난 패러다임 전환임. GPT-5도 아직 나오기 전이었고, 대부분은 4o를 쓰고 있었음. 현재 제공되는 것들은 코딩에서는 4o보다 훨씬 뛰어남
    • 공감이 안 됨. 내 기대치가 올라갔을 수도 있지만, 1년 전 에이전트로 만들던 것과 지금 만드는 것을 비교하면 완전히 딴 세상임

  • 노골적으로 적대적이진 않지만 매일 같은 실수를 반복하고, 계속 손잡고 도와줘야 하며, 진심으로 미안해할 수도 없는 동료들과 갇혀 일하는 것 같음
    우리가 컴퓨터와 일한다고 해서 사회적 피해를 안 받는 건 아님. 이 경우엔 준사회적 피해에 가까울지도 모름

  • 이게 진지하게 내가 프로그래밍을 떠나려는 이유임
    프로그래밍을 시작한 이유는 프로그래밍 문제가 흥미로웠기 때문임. 그런데 문제가 “프랑스에서 계산기가 왜 1 차이 나는지 알아내기”에서 “이 LLM이 귀여운 이모지를 도배하지 못하게 하기”로 바뀐다면, 직업을 바꿀 때일지도 모름

    • 반대편 이야기도 해보자면, 직장에서 더 많이 산출하라는 압박은 현실이지만, 업무 밖에서는 이게 정말 좋음. 개인 프로젝트를 시작할 때 항상 장벽이었던 조사와 시간이 줄어서 예전보다 훨씬 많은 프로젝트를 할 수 있음
      최근에는 탄산수에 빠져서 직접 연속 탄산 주입기를 만들고 있음. 물 공급원부터 탭까지 ESP32로 제어하는 펌프, 압력, 수위, 냉각팬까지 포함한 전체 빌드임
      장바구니에서 실수한 지점을 많이 찾아줬음. 예를 들어 홈브루 쪽은 8mm 라인을 좋아하지만 정수 시스템은 9.5mm를 쓴다는 식임. 단순한 온오프 펌프와 플로트 스위치에서 사실상 완전한 PLC 시스템에 가까운 버전까지 최적화했음. “더 경험 많은 사람”과 대화하며 많은 반복을 얻었음. 부품만 오면 한 시간 안에 조립하고 소프트웨어까지 돌릴 수 있음
      돈은 안 되지만 정말 즐거움
    • 나는 그냥 무언가를 만들려고 프로그래밍을 시작했음. 코딩은 목적을 위한 수단일 뿐임. “어떻게”에 너무 매달리지 말고 왜와 무엇을 만들지를 더 생각해보는 게 좋음
    • LLM을 쓰는 제품을 만들고 있다면, 어느 순간 문제를 고치기 위해 당길 수 있는 레버가 바닥나는 게 짜증 나는 부분임
      원치 않는 출력을 막으려고 해킹 위에 해킹을 쌓는 게 최선인데, 결국 LLM이 지시를 따르고 싶지 않다고 결정하면 *IMPORTANT*를 추가하고 다음 모델이 고쳐주길 바라는 것 말고는 할 수 있는 게 별로 없음
      이 경험은 통제할 수 없고 문서대로 동작하지도 않는 외부 API와 일하는 것에 훨씬 가까움. 그런 것들은 예전에도 프로그래밍에서 가장 답답한 부분이었지만, 적어도 이전에는 실제 구현을 역공학해 버그를 우회할 수 있었음. 지금은 그 “경계”가 매일 무작위로 바뀌어서 그것조차 불가능함
    • “프랑스에서 계산기가 왜 안 되는지는 관심 없고, 돈 받으니까 고치는 것뿐”이라고 하던 사람들이 기술 발전으로 정당화된 것 같아서 솔직히 씁쓸함
    • 회계는 법무와 컴플라이언스 때문에 꼭 필요해서 회계사가 절실함. 오늘 바로 합류하면 됨

  • CLAUDE.md나 AGENTS.md에 간단한 스타일 가이드를 넣거나, 그냥 “이모지 금지”라고 적는 데 5초면 충분하고, 그러면 LLM 출력이 훨씬 견딜 만해짐. 금지 단어와 문구를 넣은 간단한 스타일 가이드도 도움이 됨
    물론 잘못된 가정은 그렇게 해결되지 않음. 그건 예전 방식대로 꼼꼼히 읽고 비판적으로 생각해서 잡아야 함

    • 완전히 맞음! 내가 그 마크다운 파일들을 대신 써줄까?
    • 참고로 ChatGPT를 짝 프로그래머처럼 대하면서 설계 아이디어를 주고받고, 구현 코드를 요청하고, 리팩터링을 제안할 때는 이모지를 전혀 쓰지 않았음
      하지만 데이터 분석이나 모델링을 부탁하면 이모지가 사방에 튀어나옴
      지난 1년쯤 GitHub에서 본 것들을 생각하면, LLM에게 프로젝트 README나 문서를 감독 없이 쓰게 하겠다는 생각은 절대 하지 않을 것임
답변달기