AI 10배 생산성 엔지니어 신드롬에서 벗어나는데 도움이 된 것들

• AI가 엔지니어의 생산성을 10~100배 높인다는 주장은 현실적이지 않음
• 실제 AI 코딩 도구를 깊이 사용해보면 효율성 향상은 제한적이며, 반복적이고 단순한 작업에서만 일시적인 생산성 폭증이 발생함
• 소프트웨어 개발의 병목(코드 리뷰, 협업, 기획 등) 은 AI로 극복할 수 없으며, 전체 업무의 10배 향상은 불가능함
• 10배 엔지니어 신화는 수치 왜곡, 업계 이해관계자, 혹은 조직 내 불안 유발 등 다양한 동기에서 비롯됨
• 자신만의 개발 방식과 즐거움을 유지하는 것이 장기적으로 더 나은 결과와 건강한 조직문화를 만듦

---

AI 10배 엔지니어 신화에 대한 회의

생산성 불안감과 AI 도구 실전 사용 경험

• LinkedIn, Twitter 등에서 AI가 엔지니어 생산성을 10~100배로 높인다는 담론이 확산되며 많은 개발자들이 뒤처질지 모른다는 불안감을 느끼고 있음
• 글쓴이도 AI 코드 생성 에이전트(Claude Code, Cursor, Roo Code, Zed 등)를 다양하게 실전 투입해보았으나, 단순 반복 작업에서는 편리했지만 복잡한 실제 업무에서 근본적 변혁은 없었음
  • 자바스크립트(특히 React)에서 반복적인 코드(boilerplate)는 빠르게 작성 가능함
  • 하지만 자체 코드베이스 표준이나 특이한 라이브러리는 AI가 제대로 따라가지 못함
  • Terraform 같은 언어는 AI가 익숙하지 않아 성능이 떨어짐
  • 환각(hallucination) 현상으로 실제 없는 라이브러리를 생성해 보안 취약점까지 유발할 수 있음
• AI의 문맥 이해 능력은 아직 제한적임. 실제 코드베이스가 복잡할수록 반복적인 프롬프트, 오류 및 시간 낭비가 발생함
• 결과적으로, 필자는 소규모 스크립트나 비핵심 작업에 AI를 활용하고, 복잡하거나 중요한 작업은 여전히 직접 처리함

소프트웨어 개발의 생산성 수치화 문제

• AI로 생산성이 10~100배 높아질 수 있다는 주장은 현실과 동떨어진 수치임
• 10x, 100x 생산성이란 단순히 코드 줄 수가 아니라, 3개월 걸릴 일(전체 개발, 코드 리뷰, QA 등)이 1.5주 만에 끝난다는 의미
• 소프트웨어 개발에는 기획, 스토리 포인트 산정, 버그 수정, 코드 리뷰, 배포 대기, 테스트, QA 등 다양한 병목이 존재함
  • 각각의 모든 과정이 동일한 비율로 10배 빨라져야 목표가 가능
  • 실제로 코딩 자체에 소요되는 시간은 적고, 많은 시간은 이해, 설계, 검토, 커뮤니케이션에 투자됨
• 현실적으로 코드 리뷰, 협업, 커뮤니케이션, QA 등은 AI로 단축 불가
• 실제 엔지니어링 업무의 병목은 사람, 프로세스, 커뮤니케이션에 있음
• LLM(대형 언어 모델)은 키보드 타이핑 시간을 줄여주지만, 코드 품질·테스트·리뷰 시간은 여전히 필요
• AI가 코드 작성 속도를 일시적으로 높일 수 있어도, 오류 발생률 증가, 코드 표준 미흡, 재프롬프트 등으로 전체 생산성 증가에 결정적 영향을 주지 않음
  • 10배 생산성은 현실적으로 불가능에 가까운 목표임

10배 엔지니어의 실체와 한계

• "10배 엔지니어" 존재에 대해서는 일시적, 제한적으로 가능하다고 판단함
  • 가장 큰 이유는 불필요한 업무를 예방하는 능력(기획 단계에서 불필요한 개발 방지, 개발 경험 개선, 문서화 등)이 쌓여서 발생함
  • 하지만 모든 엔지니어가 매번 이런 상황을 만나는 것은 아님
• 특출난 엔지니어는 불필요한 일을 예방하거나, 시스템 개선을 통해 조직 전체 효율을 올릴 수 있으나, 실질적으로 꾸준히 10배의 성과를 내는 사례는 거의 없음
• AI 코딩 도구는 불필요한 업무 예방에는 크게 기여하지 못함
  • 오히려 AI의 추천으로 과하게 구현하거나 잘못된 아키텍처를 제안받을 수 있음
  • 빠른 코딩이 항상 좋은 엔지니어를 의미하지 않음

10x AI 신화의 배경과 동기

대부분의 "10배 생산성" 주장은 다음과 같은 요인들에서 기인함

• 측정 오류를 범하는 선의의 엔지니어
  • AI 도구로 짧은 순간에 폭발적인 효율 경험(ex: ESLint 커스텀 규칙 자동 작성)할 수 있음
  • 하지만 이런 작업이 반복되면 결국 생산성 차이는 급격히 줄어듦
  • 기술적 신기함, 새 환경에 대한 적응 등이 초기에는 과도한 효율 착각을 일으킬 수 있음
• 인센티브와 이해관계자
  • AI 스타트업 창업자, 투자자 등은 사업적 성공을 위해 과장된 수치를 자주 인용함
  • 엔지니어나 경영진도 조직 내 기대치에 부응하기 위해 과장된 생산성을 언급할 수 있음
• 악의적 목적
  • 일부 경영진은 엔지니어의 불안감을 조성해 이직, 임금 인상 요청 등 조직 내 동요를 막으려는 의도로 과장된 주장을 퍼뜨림
  • AI로 인해 누구나 쉽게 대체될 것이라는 공포가 주기적으로 반복됨(과거 코딩 부트캠프 논쟁과 유사)

현실의 오픈소스·실전 프로젝트에서의 AI 성과

• AI 생산성 향상에 관한 실제 사례는 대부분 작성자와 생산성이 향상되었다는 엔지니어 사이에 거리가 존재함.
  • 실제 엔지니어가 직접 증명한 AI 도구 활용 사례는 과장 없는 현실적 모습을 보임
  • 오픈소스 프로젝트에서의 AI 활용 결과는 대부분 기대 이하 혹은 실패 사례로 나타나기도 함
• 공개 데모나 실제 엔지니어 사례에서는 AI가 가끔 마법처럼 보이기도 하지만, 대부분은 기존의 "텍스트 생성기"와 크게 다르지 않음

"생산성"보다 중요한 가치 - 나다운 개발 방식을 유지할 것

• AI를 활용하면 때로는 더 빠르게 코드를 작성할 수 있지만, 필자는 여전히 코딩 자체의 즐거움을 더 중시함
• AI 코딩을 선호하지 않거나 즐겁지 않다면 생산성 일부를 포기해도 괜찮음
  • 어느 정도의 비효율성을 감수하고라도 자신에게 맞는 방식으로 일하는 것이 장기적으로 건강하고 좋은 결과를 만듦
• 즐겁게 일할 때 더 나은 문제 해결 능력, 설계, 동료 협업이 가능함
  • 즐거움과 몰입감이 장기적 생산성과 코드 품질에 더 중요하며, 억지로 생산성만 좇으면 번아웃 위험이 커짐
• 반대로, AI 코딩이 정말 재미있고 도움이 된다면 적극적으로 활용해도 좋음

건강한 조직 문화를 위한 조언

• AI 도구 도입 시 엔지니어 모두에게 비현실적 기대와 불안감 유발은 조직 생산성에 해로움
• 생산성 극대화 집착은 품질 저하, 코드베이스 악화, 장기적 손실로 이어짐
• 엔지니어에게 충분한 자율성과 신뢰를 주고, AI 활용은 각자 적합한 방식에 맞게 선택하도록 하는 것이 바람직함
  • 조직에서는 AI 활용 기회를 제공하되 자율성을 보장하는 분위기가 중요
• LLM, AI 코딩 혁신이 정말 10배 생산성을 주게 된다면, 자연스럽게 개발자들이 알아서 찾게 됨

결론

• AI로 인한 10배 엔지니어 혁명은 신화에 가깝고, 실제로 놓치는 비밀 레시피는 없음
• 자신의 실력과 방식에 대한 신뢰가 가장 중요
• SNS(특히 LinkedIn, Twitter)는 과장된 신화를 확대하므로 무시해도 무방함

[aliveornot]

10x를 정말 10배라고 해석하는 사람이 있었나요. 당연히 마케팅/자기PR용 과장 표현이라고 생각했는데 진지빠니까 당황스럽네

[zziuni]

10x까진 아니여도 Nx에 대한 진지한 확신을 가진 조직은 꽤있습니다. 인건비를 ai 비용으로 대체하고 그 이상의 성과를 기대하는…
그게 근거없는 착각은 아닌게 pm이 간단한 poc같은거 해보고 싶다, 반복업무도구 이런건 뚝딱되니까요.
그래서 개발자중에 이걸 믿는 사람이 있냐.. 도 전 처한 상황에 따라 충분히 불안감 가질만큼 업계 분위기는 팽배하다고 봅니다.
비개발직군, 조직장과의 커뮤니케이션을 위해서라도 이런 진지한 논의는 필요하다고 봐요.

[aliveornot]

당연히 생산성에 도움이 되는 것을 부정하는 것은 아닙니다. (지금 현재 시점의 AI수준에서) 10x라는 것은 당연히 말이 안 된다고 생각하고 있는데, 각잡고 "10배는 안 된다"라고 하는 것이 원글의 내용이라서 그게 아주 의아하게 느껴져서 쓴 댓글입니다만, 표현이 좀 좋지 않았던 것 같기는 합니다.

[1q2w3e4r]

AI의 생산성이 마케팅/자기PR용 과장 표현이라 말씀하시는 것처럼, 해당 글도 약간의 과장이 포함된 글이라고 생각을 합니다.

그렇기에 10x를 정말 10배로 해석하는 사람이 있었냐 라는 내용은 뭔가 꼬투리 잡는듯한 느낌이라 반감을 사신게 아닌가 싶군요.

[chihyeon921]

원문 읽지 않고 답글 다셨나 보네요 원문 어디에서도 진지 빨지 않았는데 말이죠...

작성자께서 개발하신 유튜브 바이럴 아이디어 찾기 DataTube.tv의 Viewtrap대비 "수십배"의 사용량 또한 당연히 마케팅/자기PR용 과장 표현이겠죠?

온라인이라 그런지 원래 그러신건지 비판적인 시선으로 작성한 댓글이 대부분이던데
조금 더 열린 시선으로 바라보셨으면 좋겠네요

[crawler]

AI 호들갑도 있으면 그 반대도 있다고 생각해서 본문에 별 생각은 없지만...
이 댓글은 ㄷㄷ; 과거 작성글까지 찾아보고 댓글 다시는 게 무섭네요 오늘 막 가입하셔서

[aliveornot]

댓글 다신 것 보고 제 히스토리를 보아도 딱히 부끄러운 댓글은 하나도 없는 것 같은데, 비판적인 시선에서 바라보는 것이 문제인가요? 님처럼 아무런 댓글을 달지 않아야 잘 사는 것일까요...

[aliveornot]

네? 10배라는 숫자를 개월수로 환산까지 해두었는데... 진지 빤다는 표현이 거슬리셨다면 이해합다만. Datatube의 수십배는 정량적 수치입니다. 뭐 어차피 운영을 하고 있지는 않지만...

[GN⁺]

Hacker News 의견

• 소프트웨어 엔지니어링 분야만 유독 "10배(10x) 생산성" 신화를 집착하는 이유가 이해되지 않음, 기계, 전기, 건설, 화학 엔지니어에서는 이 개념이 없음
  훌륭한 엔지니어란 위험을 줄이고 다양한 제약 조건 안에서 시스템을 설계할 수 있는 능력임
  설계란 모델을 통해 도메인을 이해하고, 모델이 유효한 범위와 한계를 파악하는 과정임
  "10x"라는 건 없고, 좋은 시스템을 책임지는 것만 있을 뿐임
  만약 "10x" 소프트웨어 엔지니어가 있다면, 데이터 유출과 같은 사고를 막는 사람이 될 것이고, 오히려 그런 사건이 10배 줄어드는 것을 보고 싶음

• 나도 이 글의 상당 부분에 동의함
  나는 AI 도구를 활용한 개발의 엄청난 팬이지만 10x 생산성 주장은 설득력이 없었음
  LLM 덕분에 코드 타이핑 같은 일부 업무가 2~5배 빨라졌지만, 이건 전체 업무의 일부임
  실제로 많은 엔지니어가 20~50% 특정 작업이 빨라질 수 있다고 생각하지만, 그게 전체 생산성 20% 상승이나 10x 증가로 이어지지 않는다는 점에 동의함
  물론 AI를 정말 잘 쓰는 사람은 0.2배보다 더 많은 생산성 향상을 체감할 수도 있지만, 소프트웨어 개발의 본질적 복잡성 때문에 10x는 대부분 비현실적임

  • AI를 쓸 때 내가 계속 옆에서 돌봐줘야 해서 효율이 높다는 생각이 들지 않음
    copilot의 제안이 때로는 내 생각과 완벽히 맞아 떨어져 감탄하지만 전체적으로는 매우 숙련된 주니어 개발자라기보다는 "술 취한 시니어 개발자"처럼 말을 잘 안 듣는 느낌임
    생성된 코드가 절반은 컴파일조차 안 되고, 컴파일이 되어도 제대로 작동하지 않음

  • 내 경험상 AI는 새로 만드는 영역(creation)에서는 엄청난 생산성 향상을 주진 않지만, 탐색(discovery), 학습, 막힌 부분 해결, 반복적인 코드 작성 등에는 큰 도움이 됨
    하지만 진정한 변화는 사이드 프로젝트에서 발생함
    예전엔 피곤해서 부업에 시간을 잘 못 썼는데, 이제는 완벽한 코드는 아니더라도 빠르고 적은 정신력으로 아이디어를 현실로 구현할 수 있음
    AI 엔지니어링 스킬도 마감, 개인정보, 도구 같은 제약 없이 자유롭게 실험할 수 있음

  • "10x 엔지니어"라고 불리는 사람들도 AI로 인한 생산성 향상은 미미할 것으로 생각함
    내가 아는 최고 개발자는 두 가지 능력이 핵심임: 어마어마한 기억력과 모든 언어/라이브러리의 세세한 부분을 외우고 있음, 그리고 기적 같은 창의력과 문제 해결력
    수식·이론 따위는 몰라도 그 문제에 가장 적합한 독창적이고 깔끔한 해법에 도달하는 점이 인상적임
    AI와 페어프로그래밍하면 비슷한 솔루션에 도달하기까지 AI는 끝없이 시도와 반복이 필요하고, 오히려 천재 인간의 속도를 늦추는 결과임
    하지만 역량 스펙트럼이 워낙 다양해서 내 입장에서는 AI 덕에 10배 생산성 향상이 가능하기도 함
    내 전공은 소프트웨어가 아니고 완벽주의 성향 때문에 아주 느리게 개발하는데, AI 덕분에 형편없는 첫 버전을 빠르게 만들어 볼 수 있어 아이디어 실현에 유용함

  • 나도 AI 어시스턴트 개발에 찬성하며, 2~10배 속도 향상이 일부 상황에서는 존재할 수 있다고 생각함
    하지만 대부분 "10x" 생산성이란, 처음부터 끝까지 기능을 구현하는 전체 개발 과정이 10배 빨라졌다는 의미로 과장되어 사용됨
    현실적으로 전체 개발 프로세스의 많은 부분(코딩 외)은 10배 빨라지지 않음
    그렇다고 정말 소규모 혹은 혼자 일하는 환경에서는 번거로운 절차를 많이 건너뛰게 되어서 실질적으로 큰 속도 향상이 있음
    이런 맥락에서 소규모 팀, 단독 개발이 갑자기 경쟁력을 가지는 시대가 됨

  • Simon의 댓글에 고마움을 전함
    이 댓글이야말로 실제로 글을 읽은 느낌이 듦
    언어나 도구에 특화된 일부 직무에서는 실제로 2배 생산성 향상이 일어나고 있다는 점을 인정함

• 수십 년간 소프트웨어 개발 자동화의 꿈을 꿨는데, LLM이 완전히 다른 방식으로 그 꿈을 실현했음을 느낌
  기존의 CASE 툴, UML, IDE 등은 "진짜 로직에 집중하게 하겠다"고 약속했으나, LLM은 그냥 자연어에서 즉시 실행 가능한 코드를 생성함
  많은 개발자들이 기존의 통과의례가 무너지고, 새로운 세상에서 뒤처질까 불안함(임포스터 증후군)
  이제 소프트웨어 엔지니어링이란 게 무엇인지 다시 묻게 됨
  LLM은 이전 CASE 툴의 궁극의 형태이지만, 이 과정이 너무 빨랐고, 혼란스럽고, 파괴적임
  소프트웨어 엔지니어라는 "성스러운 언어"를 모르는 사람도 힘을 가지게 되었고, 많은 엔지니어가 "내가 지금 무슨 일을 하고 있는지?"라는 근본적인 고민을 하게 됨

  • 나는 이제야 예술가들이 stable diffusion을 봤을 때의 기분을 이해함
    AI가 만든 코드는 결과적으로 자주 틀리고, 버그가 많고, 이상한 관습이나 쓸데없는 것들이 넘침
    이런 문제를 다 고치는데 오히려 직접 만드는 것만큼 시간이 걸림
    다양한 모델을 시도하거나 프롬프트를 다듬어도, 진짜로 내가 원하는 고품질 코드는 아직 손에 닿지 않는 느낌임
    마치 stable diffusion에서 신경 쓰지 않는 사람은 뭔가 이상한지 모르는 것처럼, AI 코드를 잘 모르는 사람도 그것이 문제가 있다는 걸 알지 못함
    최근에 회사 동료가 쓴 코드가 이상해서 봤더니, 디버거도 안 되고 온갖 문제가 가득했으며, 동료가 "그냥 느낌으로 코딩했다"고 고백함

  • 최근 세상을 보면 자본이 노동을 계속 파괴하고 있음을 느낌
    낮은 임금, 열악한 근무 환경, 감시, 지표 압박, 비윤리적 기업, 단기 계약 등 대부분의 노동자가 처한 현실이 점점 악화되고 있음
    우리는 그동안 너무 보호받아서 이런 현실을 제대로 느끼지 못했으나, 이제 우리 역시 불안정한 미래와 마주하고 있음

  • "소프트웨어 엔지니어링"은 결국 vibe(감) 고치는 작업으로 바뀔 것임
    많은 직업이 소프트웨어로 대체 가능하지만, 관리자들이 검증된 가치를 입증하지 못하면 SWE를 고용하지 않으려는 현실이 있었음
    AI 도입으로 인해 관리자들은 이해할 수 없는 코드를 대량 만들고, 3년 후 그게 다 망가지면 SWE를 다시 불러 고치게 될 것임
    오히려 이런 "AI가 해결 못하는 문제"를 고치는 고난이도/고가치 일자리가 더 많아질 가능성이 높음

  • LLM은 공식 모델이나 다이어그램 없이 바로 코드를 만듦
    난 오히려 AI가 이런 공식 설계나 다이어그램을 만들어주길 바람
    이런 도구는 코드 이해와 설계 명확화에 도움이 되기 때문임
    AI가 이런 부분까지 지원해줬으면 좋겠음

  • 소프트웨어 개발의 병목은 타이핑 속도나 생성이 아니라 검증과 이해임
    LLM이 헛소리(환상, hallucination) 없이 완벽하게 작동해도, 양심적인 개발자는 코드를 하나씩 검토해야 함
    사람이 10배 빠르게 코드를 이해할 수 없기 때문에, 실제로 자동 생성 코드를 되짚고 숨은 의도까지 해독하느라 시간이 더 오래 걸릴 수 있음
    "10x 생산성"이란 말은 코드 검증 없이 출력물을 그대로 넘기는 경우나, 오류가 중요하지 않은 아주 단순 코드를 다룰 때만 해당함
    실제로 오류가 곧 재앙인 프로덕션 소프트웨어는 여전히 인간의 인지 역량이 병목이며, LLM은 작성에서 검토로 부담을 옮겼기에 오히려 전반 생산성에 마이너스임

• 이 논의는 평균적 개발자들이 스스로의 생산성을 드러내는 느낌임
  프로젝트의 기술을 이해하고, 작업을 잘 분할한다면 코드 복잡도를 미리 예측해서 AI에게 적절한 단위로 일을 시킬 수 있음
  AI는 마법이 아니고, 작성 가능한 복잡도의 상한선이 있음
  그 한계와 내가 만드는 프로젝트의 기술을 잘 이해하면, 컴포넌트를 해당 한계 아래로 쪼개 AI에게 지시할 수 있음
  이 방식이 상당히 잘 작동함

  • 이건 거의 동어반복임
    AI가 잘 작동하도록 지시를 단순하게 하면, 당연히 잘 작동함
    하지만 실제론 AI에게 지침을 지나치게 세세하게 떠먹여줘야 하고, 그래도 결과물을 꼼꼼히 재확인하며 신뢰할 수 없음
    오히려 잘게 쪼개서 AI에게 설명하는 일 자체가 코드를 직접 작성하는 것보다 더 번거로울 수 있음
    AI가 운 좋게 단번에 정답을 주면 효율이 있지만, 현실적으로는 반복적으로 수정하거나 결국 다시 다 만들면서 시간과 노력이 낭비됨
    AI의 구조화된 보기 좋은 코드가 실제로는 잘못된 경우가 많아 위험함

  • 진짜 어렵고 시간이 걸리는 부분은 복잡한 부분 설계임
    사소한 부분은 입력만 하면 되지만, 복잡한 부분을 해결하는 것이 진짜 시간 소모임

  • 이 댓글의 이면에 "나는 평균 이상 개발자라고 생각함?"이라는 뉘앙스를 느낄 수 있음

  • 오히려 반대일 수도 있음
    실력 없는 개발자들이 무의미하게 오토 PR만 제출하면서 AI가 만든 결과물에 감탄하는 반면, 눈높이가 높은 개발자는 그 결과물에 감탄하지 않을 수 있음
    실제로 직접 같이 일해보지 않으면 신뢰할 수 있는 사람을 구분하기 어렵기에 나는 중립을 유지함

  • AI도, 인간도 한계가 있음
    결국 필요한 건 지루한 프로젝트 관리임
    제대로 된 요구사항, 설계, 그리고 충분한 정보를 담아 작은 작업 단위로 쪼개면, AI에게 "깃헙 이슈 #42를 구현해"라고 시키고 TV 보면서 지켜볼 수도 있음
    하지만 "facebook 만들어줘"하면 당연히 망하는 흐름임

• AI가 또 하나 큰 도움 준 분야는 버그 찾기임
  나는 주로 수치 시뮬레이션 작업을 하는데, 며칠이나 묶여있던 문제(몇 개 괄호가 빠진 걸로 인한 식의 스케일 오류)를 chatgpt에 파일과 현상을 설명하니, 금방 원인을 알아냄
  AI는 때론 내가 놓친 부분을 명쾌하게 집어주는 역할
  이게 10x 개발자를 만들어 주는 건 아니지만, 잘 쓰면 커다란 긍정 효과를 체감함

  • 나도 비슷함
    AI로 코드 만들기는 그저 그런 수준이지만, 디버깅은 정말 큰 생산성 도약임
    일종의 매우 똑똑한 "러버덕"임

  • (취미 개발자 관점) LLM 덕분에 밤늦게 머리 안 돌아갈 때 개발이 훨씬 쉬워짐

  • 나도 무수히 많은 시간을 AI 덕에 아꼈음
    내겐 10배와 무한대의 중간 어딘가인 느낌임

• 나는 10x 엔지니어라 생각하지 않음
  회사 동료보다 내가 더 생산적인 이유는 시스템 설계와 사업적 요구를 불분명한 티켓 그대로 따르지 않는 것임
  AI가 내 동료들을 단순화 못하는 이유는, 애초에 복잡하게 만드는 습관을 바꾸지 못해서임
  AI는 이 문제까지 해결해주지 않음

  • 나는 2x 엔지니어도 아닌 것 같음
    회사에서 내 연봉이 동료와 2배 차이가 안 나니 그렇게 여김
    AI 도구 도입한다고 이런 현실은 안 바뀜

• 이 글은 "10x"라는 너무 높은 기준을 세운 다음, 저자가 그걸 넘으려 한 사적 시도 기록임
  그래서 AI 지지자들을 세 부류(착각하는 사람, 판매하는 사람, 불안 심리를 공략하는 악덕 관리자)로 나눴다고 생각함
  개인적으로 "환각(hallucination)"에 대한 불평은 약간 "신호"라 여김

  • 환각(hallucination)에 대한 이야기가 꼭 필요하다고 생각함
    LLM에 대한 논의가 너무 극단적으로 흘러감(아예 쓸모없다는 쪽 vs 개발자 대체라는 쪽)
    예로 Claude 4 Sonnet이 clang 컴파일 관련 내용을 Godbolt가 틀렸다고 잘못 답변한 적 있음
    그럼에도 이 세션 전체적으로 큰 도움을 받았으므로, 결과에 비판적이어야 한다는 점만 명심하면 됨
    환각은 실제로 존재하고, 결과에 대해 항상 경계해야 함

  • 댓글을 남겨줘서 고맙고, 네가 쓴 AI 관련 글 덕에 임포스터 증후군을 극복하는 데 도움을 받았음
    글에서는 "10x 잇달아 성공했다" 주장하는 사람에 한해서 분류한 건데, 모든 AI 지지자를 싸잡아 말한 게 아님
    실제로 환각이 아예 없는 방법을 찾았는지 궁금함
    특히 Terraform 등에서는 존재하지 않는 프로퍼티를 LLM이 만들어내고, JS 등에서도 드문 라이브러리 사용할 땐 여전히 착각이 잦음

  • "환각"에 대한 불평이 신호라면, 그런 생각 자체도 신호임…
    (짧은 반박)

  • 이 10x 기준은 산업계 공통의 과장 마케팅임
    예: Sam Altman의 10x 주장
    Cursor AI 생산성 홍보
    AI-augmented 10x 개발자

• 웹앱을 만들 줄 모르는 사람이 6주 동안 하루 4시간씩(120시간) 배우며 겨우 하나를 만든다고 가정
  대신 Claude code 등 AI를 활용해 주말 이틀(12시간)에 같은 웹앱을 만든다면 생산성이 10배 상승
  이게 실제로 나에게 일어난 일과 비슷함
  예전엔 동기부여나 에너지가 부족해 못 하던 일을 AI 덕에 주말동안 해낼 수 있게 됨

  • 하지만 첫 번째 방법은 배우는 과정이 있어서 다음에 뭔가 바꿀 때 도움이 될 수 있음

  • 사실 Claude Code 같은 AI에게 리액트 외로 웹앱 스캐폴딩 시키면 엉망임
    앱 개발 경험이 없는 사람이 주말에 완성도 높은 앱을 쉽게 만들진 못함
    첫 사용자 로그인만 해도 바로 망가질 수 있음

  • 장기적으로 보면 저 산술이 말이 되지 않는다고 생각함
    LLM으로 처음엔 앱을 빠르게 만들지만 점점 유지보수 능력이 떨어지고, 어느 순간 복잡해진 시스템을 더는 “컨텍스트 윈도우”에 담고 관리하지 못함
    결과적으로 생산성은 오히려 0에 가까워질 수도 있음

  • 뇌와 학습 경험을 아예 아웃소싱한 거라서, 앱은 생겼지만 성장이나 배움은 거의 없었음

  • 그걸 바로 배포할 생각임?
    현실적으로 동일 선상이 아님
    1x 개발자 산출물도 측정하기 어렵고, 그걸 곱하는 건 더더욱 무의미함

• 나는 AI가 "사이드 퀘스트 생산성"을 크게 올려준다고 느낌
  그동안 귀찮아서 미뤄두던 일(목업 제작, 테스트 작성, 라이브러리 추출, 문서화 등)에 AI가 최적임
  기능을 만드는 시간을 단축시키지는 못해도 부가 작업까지 포함하면 결과물이 조금 더 완벽에 가까워짐
  이 부가 작업 덕에 미래에 버그 찾기 시간이 줄었으면 좋겠음

  • (개인 경험)
    내 케이스에 한정된 이야기지만, 우리 회사에선 LLM으로 만든 테스트 코드가 구현 코드와 너무 밀접하게 엮이는 게 일반적임
    테스트 스파이 같은 패턴 남용이 심함
    그 결과, 사용자 입장에서의 동작 대신 내부 구현 세부사항만 검사하는 애매한 테스트가 많아짐
    테스트가 구현 변경에 따라 너무 자주 깨져, 오히려 테스트가 생산성이 아니라 부담임
    이는 LLM의 문제만은 아니고, 원래부터 테스트 제대로 못 하는 개발자들이 LLM으로 인해 문제가 더 심해지는 것임
    TDD, 잘 설계된 테스트 코드 경험이 부족한 개발자에게 LLM이 이런 안티패턴을 증폭시킴

  • "사이드 퀘스트 생산성" 표현이 좋음
    AI는 "죽음의 천 스침"이 아니라, "천 개의 반창고로 만들어진 새 삶" 느낌임

  • "사이드 퀘스트" 개념에 찬성함
    사실 내가 AI 없이 만들지 않았을 툴이나 기능을, AI 덕에 만들 수 있게 된 게 큰 변화임
    단순히 2주를 아끼는 게 아니라, 없던 결과물이 생긴 거임

• LLM에 대한 기대가 현실보다 높지만, 실제로 다양한 상황에서 매우 유용함
  "줌 레벨"로 보면, "vibe coding"처럼 대충 만드는 수준부터, "이 함수 만들어 줘"까지 단계별로 쪼갤수록 결과가 훨씬 좋았음
  코드 생성 외에도 새로운 기술 학습 등 여러 용도에서 효과적임
  내 역할이 미팅이 많거나 관리자 업무가 많으면 LLM의 도움은 감소함
  앞으로는 PR 워크플로우, 커밋 정리, 순서 재조정 등에도 LLM이 활용될 수 있으리라 생각함

[reagea0]

덮어놓고 '안된다', '실현불가능' 이란 소리 자주 하던 엔지니어들 반박하기 위해서만 사용해도 사실 뭐, X10 효과 날 것 같긴 합니다.

비개발자 무지랭이 취급하면서 무조건 안된다 하던 광경을 자주 목격해와서.