오히려 좋은 질문임. 마케팅에서 말하듯 몇 년 안에 AI가 인간의 개입 없이 모든 일을 한다면 굳이 지금 애쓸 이유가 없음
하지만 LLM에는 환각과 일반화 한계가 있고, 처음 접하는 작업에서는 인간보다 훨씬 못하며, 이는 현재 패러다임의 본질적 한계로 보임. 선별된 데이터를 계속 투입하면 특정 작업에는 뛰어나지지만 그 엔진을 전문화하는 새 작업이 생길 뿐이며, 노동은 사라지지 않고 제한된 문제에 반복 적용할 수 있는 형태로 이동함. 완전 자율 AI가 모든 일을 처리할 새 패러다임이 나오기 전까지는 병목을 동반한 생산성 향상에 가까움

인간의 도약을 마법처럼 볼 필요는 없으며, temperature를 높이면 모델도 개념적 도약을 만들 수 있음. 인간의 사고 역시 무관해 보이는 과거 입력과 자기 생각을 다시 입력하는 과정에 기반함
어려운 부분은 도약 자체가 아니라 그것이 창의적인지 미친 발상인지 판별하는 능력임. 사고를 너무 풀면 헛소리가 되고 너무 조이면 당장의 보상과 뻔한 사고 경로만 따르게 되므로, 둘 사이의 균형을 찾는 데 시간이 걸림

여전히 상당한 사고가 필요하지만 작업당 사고량은 줄어드는 추세임. LLM은 가추적 추론에 약하지만 인간도 대부분 잘하지 못하고 이를 요구하는 직무도 드묾. 연구원은 다를 수 있으나 연구소가 원하는 인원은 0명이 아니라 더 적은 수가 될 가능성이 있음

환경을 보존해도 신자는 결국 천국에 간다며 무의미하다고 보는 것과 같은 이유로, 이는 종교적이고 교조적인 허무주의임

예전에는 코딩이 하루의 약 14%라는 수치가 맞는 듯했지만, 지금은 코딩하거나 에이전트에게 코딩을 시키는 시간이 더 늘어남. 접근법과 라이브러리를 조사하고 이슈를 계획하며 깊이 생각하는 일도 여전히 하지만 더 빨라졌고, 에이전트가 코드를 생성하는 동안 병렬로 처리하게 됨
어려운 문제일수록 에이전트가 20분간 혼자 작업하는 동안 다른 일을 더 많이 할 수 있는 병렬화 효과도 생김

밀린 작업을 처리하는 동안 나타나는 일시적 급증일 수 있고, 6개월쯤 지나면 AI로 크게 가속할 일이 고갈될지도 모름. 하지만 지금은 시간의 80~90% 를 기능 구현, 버그 탐색과 수정, 도구 작성 및 개선에 쓰며, 예전에 지루했던 중간 난도의 작업을 빠르게 끝내는 즐거움이 큼

코딩 단계에 도달했다면 문제는 가능한 범위에서 이미 정의되고 이해된 상태이며, 구현은 주로 타이핑하고 테스트로 가정을 검증하는 과정임. 생성형 AI는 이를 빠르게 하지만, 문맥에 맞는 코드 조각을 제안하는 IDE의 가속 효과와 비슷함

SQL 작성과 대시보드 제작을 AI에 전적으로 맡겨봄. 프롬프트를 보내고 결과가 원하는 것인지 판단하면서, 나는 가정과 가능성을 계속 생각하고 LLM에는 기술 명세 처리를 맡겼음

생성량이 늘어난 코드는 누가 검토하며, 확인해야 할 코드 증가량을 어떻게 감당하는지 궁금함

하루 대부분을 에이전트에게 코드를 작성시키고 결과를 검증하며 작업 흐름을 조율하는 데 씀. 나머지 시간에는 Fable 에이전트가 Linear/Jira에서 업무를 정리하고 동료들의 작업이 충돌하지 않도록 관리함

LLM으로 상당량의 코드를 생성하면 직접 만들 때 얻던 도파민과 성취감이 완전히 사라짐. 코드베이스와의 접점을 잃으면서 개인 프로젝트에도 흥미가 줄어들고 있음

ADHD 성향이 강한 입장에서는 LLM 코드 생성이 코딩의 재미를 거의 모두 없앰. 컴퓨터끼리 체스 두는 모습을 구경하는 것과 비슷함

생성형 AI 덕분에 별 관심 없이도 무언가를 만들 수 있게 됐으며, 그런 결과물이 반드시 나쁘지는 않지만 좋고 나쁨을 아무도 신경 쓰지 않아 자의적 결과가 되기 쉬움
정말 중요하게 여기는 작업은 LLM 이전과 비슷한 시간이 들고 결과에 애착과 자부심도 생김. 예전에는 아예 하지 않았을 사소한 작업도 이제 만들 수 있지만 그만큼 단절감을 느끼므로, 무엇에 관심을 쏟을지 전략적으로 선택하는 능력이 핵심이 될 것 같음

2025년 초의 오래된 METR 연구를 인용하면서 “최근 연구”라고 부르는 것만 봐도 이 글을 얼마나 진지하게 받아들여야 할지 알 수 있음

인용 자료를 확인하니 일부만 2025년이고 대부분은 그보다 오래됐음. 2025년 말 이후 너무 많은 것이 달라져 여기서 결론을 내리기 어려움
변화 속도가 워낙 빨라 개발자 설문을 수행하는 동안에도 응답과 결론 상당수가 이미 무의미해질 가능성이 큼

중국에서 수행된 연구는 여성과 정의가 불분명한 “성숙 연령” 집단의 AI 도구 사용률이 더 낮다고 봄. 기술을 이용해 작업을 끝내면 스스로 수행할 역량이 부족하다는 신호를 줄 수 있어, 특히 여성과 고령 엔지니어가 비기술적 역량 평가를 우려해 사용을 꺼린다는 해석임
문화적 영향이 강할 수 있지만, 도입 12개월 뒤에도 AI를 사용한 엔지니어가 41% 였다는 결과는 내 관찰과도 맞음. 일상 업무에 도입하는 법을 어려워하는 사람이 있는 반면 완전히 받아들인 사람도 있음

개발자가 편집기에서 입력하는 시간이 15%뿐이라는 수치에는 중요한 맥락이 빠져 있음. 과거에는 코딩의 변경 비용이 커서 조사와 계획 같은 비코딩 작업에 많은 시간을 썼지만, 이제 빠르게 시제품이나 운영 수준 코드를 만들 수 있어 코드 자체가 소통 도구가 됨

새 소프트웨어 프로젝트를 거의 노력 없이 시작할 수 있다면 가장 중요한 업무는 올바른 결정을 내리는 일이 되며, 여기에 시간의 99.9%를 쓰게 될 것임

개발자가 하루의 11~14%만 코딩하고 나머지를 설계와 회의에 쓴다는 연구로 AI가 최대 14%만 자동화할 수 있다고 암시하는 것은 잘못임. 코드가 만들어지면 코드 작성에 앞서 필요했던 활동 중 일부도 함께 사라짐

AI가 설계 생산성을 높이거나 회의를 줄인다는 증거가 필요함. 내 경우 AI는 설계 주기를 단축하지 않았고, 오히려 불필요하게 완성도를 높이도록 부추겨 주기를 늘릴 수 있음

요구사항을 이해하려고 한 시간 회의하고 QA 엔지니어에게 넘기려고 동기화하며 vim 확장 설치에 30분을 썼다면, 코드를 직접 작성하지 않을 때는 이런 활동도 필요 없어짐
Staff·Principal 엔지니어의 업무는 코딩 외 영역이 넓어 AI로 크게 달라졌지만, 많은 중급·시니어 엔지니어는 사실상 코드 전달과 그 주변 준비 작업이 업무 대부분임. 따라서 코드 작성을 자동화한 효과를 15% 향상으로 축소해서는 안 됨

AI는 설계 문서와 PLC 산출물을 작성하고 Jira에 입력하며 버그 특성 분석과 근본 원인 파악까지 수행함. 코딩 외 86%도 빨라지고 있어 이 글은 근시안적이며 스스로 모순됨

Claude가 원하지 않는 작업이나 잘못됐다고 생각하는 설계 결정을 지시할 때 따르지 않는다면, 설계와 회의를 실질적으로 대체할 수 없음. 이는 Claude의 결정을 감독하지 않는 바이브 코딩과 미묘하지만 중요한 차이가 있음

직장에서 하루의 14%만 코딩하는 이유는 다른 일을 해서가 아니라 그냥 게으르기 때문임

코딩이 업무의 14%라서 작은 비중이라는 가정은 피상적임. 과거에는 코딩 비용이 높아 잘못된 것을 만들지 않도록 먼저 확신해야 했지만, 지금처럼 코드가 저렴해지면 업무 구조도 달라짐
수많은 회의 대신 같은 기능의 다섯 가지 버전을 직접 구현한 뒤 하나를 고르는 방식도 가능함

코딩은 이해한 해결책을 구체화하는 일일 뿐이므로 그 자체가 비쌌던 적은 없음. 항상 비쌌고 지금도 비싼 것은 문제에 대한 근본적 이해임

그렇다면 코딩이 PRD 단계에서 더 큰 비중을 차지하게 된다는 뜻인지 궁금함

엔지니어가 좋은 근무일의 18%를 코딩에 쓴다는 지표에서 버그 수정과 테스트를 제외한 이유를 이해하기 어려움. 프로젝트 단계에 따라 코딩 시간의 100%를 버그 수정에 쓸 수도 있음