“이 제품은 내부에서 수백 명이 사용했고, 매일 쓰는 내부 파워 유저도 있다”라면 아마 이메일 필터일 듯함
“코드 100만 줄”이고 “에이전트가 100% 작성”했다면 더더욱 그럴 것 같음. 아니면 부서 위키용 JS 메뉴인데, 사실상 jquery를 MS JScript로 다시 만들고 JS 5로 변환하는 물건일 수도 있음

전체 Linux 커널이 약 4천만 줄이고, 드라이버를 빼면 대략 1,600만 줄 정도임. OpenAI가 말한 그 무언가가 Linux 커널의 6%만큼의 코드 줄 수를 가졌다고 해서, 유용성도 6%에 근접한다고는 상상하기 어려움
LLM이 아무리 강력하더라도 유지보수 가능성도 거의 없을 것 같음

Anthropic 주변의 현실 왜곡장도 강함. Anthropic도 전부 AI가 쓴 듯한, 아무 말도 안 하는 허튼 블로그 글을 잔뜩 올리는데 프런트에 가고 꾸준히 수백 업보트를 받음

세부 내용이 너무 적어서 실망스러웠음. 그래서 조만간 이런 것들이 실제로 얼마나 효과적인지 보여주는 오픈소스 프로젝트나 시도가 나올 거라고 봄
팟캐스트 인터뷰에서는 사용자가 다운로드하는 Electron 앱이고, 그래서 주기적으로 새 빌드를 만든다고 말함. 여기의 “Autonomous Merging Flow” 섹션 참고: https://www.latent.space/p/harness-eng

Microsoft 쪽 사람이 “엔지니어 1명당 매달 코드 100만 줄을 원한다” 비슷한 말을 올렸던 게 계속 떠오름. 내가 이야기한 대부분의 엔지니어에게는 풍자처럼 읽혔지만, 실제로는 전혀 풍자가 아니었고 LLM 코드 생성에 대한 많은 CEO들의 태도를 꽤 잘 반영한 듯했음
다만 최근 몇 달 사이에는 유지보수 불가능한 양의 코드 줄을 만들어내는 것에 대한 과열이 조금 식는 느낌임. 더 실용적이고 현실적인 견해가 공개적으로 더 많이 공유되고, 일부 기술 기업의 최고위층에도 조금씩 닿는 것 같음. 아직 완전히 망한 건 아닐지도 모름

예전에 코드 커버리지 80% 요구사항이 있는 회사에서 일한 적이 있음. 어떤 영리한 계약자가 전체 코드베이스 기준으로 80%를 맞출 수 있게 크기를 조절하는 단일 파일과 그 자체 테스트 스위트를 생성하는 스크립트를 갖고 있었음
실제로는 대부분의 코드가 테스트되지 않았음

1,000,000 / 25 / 8 / 60 = 분당 83줄 이상임
한 달 100만 줄 / 월 25일 / 하루 8시간 / 시간당 60분 코드 리뷰하는 사람에게는 꽤 문제가 커 보임

임원진이 토큰에는 돈이 든다는 걸 갑자기 깨닫고, 직원들의 AI 사용 지침을 즉시 고치는 모습을 보는 게 정말 웃겼음
엔지니어마다 매달 코드 100만 줄을 만들게 하면서, 그 줄들이 회사에 어떻게 돈을 벌어줄지나 그 과정에서 얼마나 많은 토큰이 얼마의 비용으로 타버릴지를 생각하지 않았던 건 아무래도 충분히 숙고된 계획이 아니었던 듯함

AI가 대량으로 생성한 코드를 말할 때 slop이라는 단어는 좋은 선택이었음. 비기술자에게도 와닿고 역겨움도 전달됨. slop은 피해야 한다는 게 명확함
반면 기술 부채는 경영진을 같은 방식으로 붙잡지 못했음. 부채는 일반적으로 문제가 될 수는 있지만, 문제가 되기 전까지는 피하거나 처리할 필요가 없는 것으로 여겨져서 계속 뒤로 미뤄짐

최근 몇 달 사이 유지보수 불가능한 코드 줄 수를 생산하는 과열이 줄어든 데에는, 비즈니스와 제품 쪽 사람들이 실제로 AI를 일상 업무에 넣어보기 시작한 영향도 조금 있을지 궁금함
내가 일하는 두 소규모 회사 모두에서 이런 모습을 봤음. 몇 달 전 Claude Cowork를 받게 되어 다들 매우 들떴고 지금도 매일 쓰지만, 기대했던 마법에 비하면 꽤 실망한 편이라고 봄
결과물이 평범하고 장황하며, 아주 기본적인 것도 틀리고, 토큰 한도에 계속 걸리며, 직접 하는 편이 더 빨라서 다시 손으로 처리한다는 불만이 나옴
처음에는 도구를 잘못 쓰는 부분도 있겠지만, AI CEO, LinkedIn 장사꾼, YouTube AI 보충제 판매자들이 말하는 것과 현실 사이에는 아직 격차가 있다는 걸 사람들이 깨닫고 있음

“AI가 모두를 더 생산적으로 만들었으니 인원이 덜 필요하다”고 회사가 말한다면 근거를 보고 싶음. 지금은 그런 근거가 존재한다고 믿지 않음
실제로는 헛소리하면서, 코로나 시기 과잉 채용을 되돌리는 핑계로 AI를 쓰는 것임. 동시에 투자자에게는 최신 유행 기술을 받아들여 더 날렵하고 비용 효율적인 조직이 된 것처럼 보이게 만듦

투자자에게 최신 유행 기술을 받아들여 더 날렵하고 비용 효율적인 조직이 된 것처럼 보이게 하는 건 새롭지 않음. 이름만 새로 붙은 것임

코로나 시기 과잉 채용이라는 건 꽤 관대한 변명임. 내 눈에는 전반적으로 임금을 낮추려는 시도로 보임. 그 이후로 해고가 여러 차례 있었으니, 6년 된 변명은 특히 공허하게 들림
투자자들이 최신 유행 기술 수용을 중시한다기보다는 수익을 중시한다고 생각했음
그리고 “침실의 아무 바보나 쓸 수 있는 번쩍이는 기술을 우리도 씁니다!”라고 말하는 회사는 완전히 경쟁력 없는 회사이기도 함

우리 업계가 수십 년 동안 “우리가 하는 일은 복잡하고 오래 걸리기 때문에 생산성을 쉽게 측정할 수 없다”고 설명해왔는데, AI가 등장하자 갑자기 코드 줄 수, N배 승수, 주당 티켓 수 같은 것이 유용하거나 객관적인 지표처럼 떠받들어지는 게 끝없이 우습기도 함
코드 줄 수 같은 지표를 거부했던 이유는 변하지 않았음. 핵심은 코드 산출량이 아니라 품질 산출물임. AI도 사람이 가진 문제를 그대로 가짐. 그런데 왜인지 우리가 배운 걸 내던지고 있어서 좀 창피함

비기술자가 권한을 잡고 있고, 엔지니어처럼 현실에 묶여 있지 않음. 결국 객관적 현실이 이기겠지만, 단기적으로 피해가 나는 건 막지 못함

정말 우리가 수십 년 동안 생산성이 쉽게 측정되지 않는다고 설명해왔나? 지난 10년 동안 내가 본 건 엔지니어와 비엔지니어 모두가 Github 활동 그래프를 점점 더 숭배하는 모습뿐이었음. 내 생각에는 이 바자르는 AI 이전부터 이미 길을 잃었음

일부 소프트웨어 엔지니어 집단은 신중한 측정의 필요성을 키웠을지 모름. 하지만 프로그래밍 분야 전체가 단순 지표라는 생각에서 벗어난 적은 없음
느슨하게 관여하면서도 공격적이고 요구가 많은 상사는 항상 있었기 때문임. 직원에게 더 많은 노력을 짜내는 것이 주된 업무이고 조율 등에는 기여하지 않는 상사에게도 안타깝게나마 경제적 가치가 있음
그래서 실제 성과와 코드 줄 수 같은 측정이 겹쳐 있는 두 접근법의 구름이 늘 존재했음
AI는 이런 느슨하게 관여하면서 요구만 많은 상사를 만족시킬 도구를 모두 제공함. 그래서 이제 코드 줄 수와 기능 추가를 지표로 좋아하는 사람이 더 많아질 것임. 이제 그게 쉬워졌기 때문임

억만장자 계층이 사람들을 거리로 내몰 수 있게 slop 기계를 밀어붙이려고 이 모든 걸 하는 셈임

A+ 시니어 개발자가 8개월 동안 기능을 만들었는데 결국 출시되지 않거나 MVP가 폐기된다면, 그 A+ 시니어 개발자를 낭비한 것이고 생산성은 같은 프로젝트에 참여한 B+ 엔지니어 둘과 같아짐
이건 실제로 아주 흔한 문제인데, 채용이나 프로젝트 리소스 배정에서는 보통 무시됨. AI가 이를 의미 있게 바꾸지는 못할 것임
팀이 작업을 훨씬 빨리 끝낼 수는 있겠지만, 위쪽의 관료적 계층은 그대로일 가능성이 높고, 그러면 AI 코딩으로 얻은 이득은 미미해짐. AI에 맞추려면 회사를 위에서부터 다시 만들어야 하는데, 그런 일은 거의 일어나지 않을 것임

엔지니어들은 이런 걸 낭비로 과하게 보는 경향이 있음. 그 투자를 낭비한 게 아니라, 그 기능이나 MVP를 출시할 수 있는 선택권과 출시가 타당한지 알아보기 위한 연구 비용을 낸 것임

그 8개월이 정말 “코딩”에만 쓰였다고 확신할 수 있나? 설계, 제품팀 입력, 반복 작업 등이 있음. A+ 엔지니어가 혼자 칸막이 안으로 들어가 X개월 뒤 고립된 상태에서 MVP를 들고 나온다는 장면을 어디서 봤는지 모르겠음

끝부분의 AI 밀어붙이기는 이상할 정도로 근거가 없음. 이유도, 목표도, 이득에 대한 주장도 없이 “그냥 AI를 쓰라, 개발자는 새것을 받아들여야 한다”는 식임
최근에 읽은 글 중에도 짧은 맥락으로 AI를 비판하는 척하다가 결국 AI 광고로 끝나는 글이 있었고, 둘을 이어주는 내용은 없었음

AI는 새로운 클라우드임. AI에 전념하지 않는 사람이나 회사에는 시장이 없음. AI 사용을 거부하는 개발자는 어떤 회사도 고용하지 않을 것이고, 어떤 회사가 AI를 쓰지 않기로 하면 개발자를 붙잡기 어려울 것임. 더 많은 개발자가 필요해질 테니까
투자자와 큰 고객도 주요 계약에 서명하기 전에 다시 생각할 것임
그러니 AI를 써야 함. 비용과 이익을 사소하게 따지지 말아야 함. 세상은 이 방향으로 가고 있고, 소프트웨어 개발로 먹고살고 싶다면 본인도 그 방향에 있어야 함

그래도 AI의 가치는 0보다 큼. 그건 논쟁적인 얘기가 아님

“이번 차이는 속도다. 클라우드는 몇 년 늦게 받아들여도 살아남을 수 있었다. AI는 몇 달일 수 있다”라는 대목이 이상함
글쓴이는 AI 회사들이 제품의 필수성에 대해 하는 친AI 주장이 반증 불가능하다는 걸 이해하는 듯하다가, 곧바로 “잠깐, 내가 반AI라고 생각하진 말라”로 물러남
위 주장이 글 나머지에서 비판하는 생산성 주장보다 어떻게 더 엄밀한가? 몇 달 안에 AI를 받아들이지 않으면 “살아남지” 못한다는 말이?
AI CEO가 말해도 사실이 아니고, AI CEO의 헛소리를 지적하는 사람이 어떤 이유로 똑같이 말해도 사실이 아님

AI CEO가 그렇게 말하는 건 주가를 띄우기 위해서임. 검증 불가능한 주장을 뒷받침 없이 하기 때문에 AI CEO들을 믿은 적이 없음
AI 때문에 사람을 해고한다고 말하는 건 해석의 여지가 너무 넓고, 책임을 자신이 아니라 AI로 옮김. 현실적으로는 CEO가 한 일을 AI 탓으로 돌리면 안 됨. 직원을 AI에 맞게 재교육할 수도 있었는데 그러지 않았음. 왜일까? 어쩌면 AI 때문이 아니기 때문일 수 있음

그는 생산성이 아니라 채용 가능성과 관련한 문화적 고려를 말하는 것임

글쓴이임. 타당한 비판이고 읽어줘서 고마움. “몇 달”이라고 한 건 회사 생존이 아니라 개인의 실무 습관을 말하려던 것이었는데, 충분히 명확하게 쓰지 못했음
실제로 직접 썼고, 다른 곳에서 말하듯 “AI slop”으로 만든 건 아니니 아마 끝부분에서 “인간적으로 sloppy”해진 것 같음
“잠깐” 부분을 근거로 뒷받침하지 못했다는 점은 맞지만, 그래도 사람들이 AI를 써봐야 한다는 생각은 유지함. 실험하고, 자신에게 도움이 되는 방식을 찾아야 함. 비슷한 엔지니어들 사이에서도 가치를 얻는 방식의 스펙트럼이 매우 넓었음
도구를 제대로 시도해보는 데 드는 비용은 거의 없고, “의도적으로 도입하고 검증된 지루한 방법으로 측정하라”는 입장은 “도입하지 않으면 죽는다”와 같지 않음

사람들이 발언 뒤의 동기를 고려하는 건 맞음. 여기서는 동기가 충분히 달라서 차이가 있다고 봄. AI CEO에게는 거짓말할 명확한 동기가 있지만, 헛소리라고 부르는 사람에게는 그런 동기가 뚜렷하지 않음

회사가 “AI가 모두를 더 생산적으로 만들었으니 인원이 덜 필요하다”고 말할 때, 암묵적으로는 회사가 더 생산적이 되고 싶지 않다고 말하는 셈임
더 생산적인 소수에게 더 적게 지불해서 같은 생산성을 원한다는 뜻임
생산 단위당 고용주가 받는 돈과 직원이 받는 돈 사이에 왜 불균형이 있는 걸까?

노동이 착취되어 소유주를 더 부자로 만들기 때문임. 그게 기본 사실이고, 소유주 계급은 이를 정당화하고 가리기 위해 많은 선전에 돈을 대왔음

“같은 생산성”이 아니라 같은 산출물에 더 적은 사람을 말하려는 것 아닌가? 정의상 그러면 회사 생산성은 높아진 것임. 회사나 국가 수준의 생산성은 산출을 투입으로 나눈 비율이기 때문임
더 적은 사람으로 같은 산출을 얻으면 회사나 국가의 생산성이 개선된 것임
더 적은 사람에 같은 생산성이라면 산출도 그에 맞춰 줄어들기 때문에 회사에는 이득이 없고, 고정비가 있으면 오히려 더 나쁠 수도 있음 https://www.mckinsey.com/featured-insights/mckinsey-explaine...

코드 줄 수는 사무실에 있는 시간과 크게 다르지 않다고 봄. 팬데믹 전에는 늘 “사무실에 없으면 일하고 있는지 어떻게 알지?”라고 말했음
간단함. 모든 직원 평가에 쓰는 산출 지표로 그들이 비즈니스에 무엇을 기여하는지 보면 됨

코드 줄 수가 여전히 부채가 아니라 자산처럼 여겨지는 데에는 우리 엔지니어들의 책임이 크다고 봄. 우리는 자신이 만든 것을 자랑스러워하지만, 무언가가 얼마나 “큰지” 설명하려면 지표가 필요하고 결국 계산하기 가장 쉬운 지표로 돌아감
용어를 바꿔야 함. 특히 “...그리고 그 비용은 코드 N줄이었다”라는 표현을 많이 써야 함. 그 코드 줄을 어디에 썼는지도 말해야 함
“새 기능 X를 구현했는데 200줄밖에 들지 않았다”
“그 버그는 찾기 정말 힘들었지만, 결국 코드 6줄만 들었다”
“X 경우에는 하던 일을 Y 경우에는 하지 않았는데, 알고 보니 그 구분 자체가 필요 없었다. 그래서 문제를 고치면서 동시에 코드 20줄을 절약했다”
코드 줄은 우리가 지불하는 가격임. 우리는 무엇을 샀는지 말하지 않고 200달러를 썼다고 자랑하지 않음. 왜 코드 줄에서는 그렇게 하는가?
“늦게 신청해서 200달러를 더 내야 했다”와 “손으로 칠한 장인 도자기 램프 걸이를 200달러밖에 안 주고 샀다. Amazon의 공장제는 1,200달러가 넘는다”는 완전히 다른 말이고, 코드에서도 정확히 같은 차이에 대응됨