코드 라인 수가 더 나은 홍보 담당자를 얻었다

 (curlewis.co.nz)
2P by GN⁺ | ★ favorite | 댓글 2개
  • 개발자 생산성 평가는 코드 양보다 고객 가치, 매출, 신뢰성 같은 결과 지표로 판단해야 함
  • Google, Anthropic, OpenAI, Cursor의 최근 AI 코딩 홍보 수치는 모두 코드 생성 비율이나 코드 라인 수 같은 양적 주장에 집중함
  • GitHub Copilot의 과거 55% 작업 속도 향상 주장은 검증 가능한 결과였지만, “AI가 작성한 코드 비율”은 개선 여부와 무관하게 커질 수 있음
  • 실제 연구는 엇갈리며, Cui et al.의 +26% 완료율부터 METR의 "19% 느려짐" 및 이후 번복, 기업 90%가 측정 효과 없다는 조사까지 조직 단위 효과는 약 10% 수준
  • AI 도입은 필요하지만 성과 측정은 DORA 지표, 신뢰성, 의미 있는 변경 속도, 매출, 고객 가치처럼 검증된 기준에 기반해야 함

코드 라인 수 지표의 부활

  • 15년 전 SaaS 기업의 두 시니어 개발자 중 한 명이 다른 한 명보다 40% 더 많은 코드를 작성했다는 사실만으로 더 뛰어난 개발자라 볼 수 없음
    • 실제 중요한 것은 무엇이 출시(ship) 되어 고객·매출·안정성에 기여했는가이며, 코드 라인 수와 PR 개수는 수십 년간 나쁜 측정 방식으로 학습됨
  • 2026년 업계가 내세운 대표 수치는 모두 AI 작성 코드 비율에 집중
  • 이들 수치는 전부 양적(volume) 주장이며, "AI가 작성한 코드 비율"은 더 세련된 홍보 문구를 얻은 코드 라인 수에 불과함
    • 해당 기업들이 모두 AI 벤더라는 점에서 채택률 부풀리기가 중요한 동기로 작용

과거에는 성과를 주장했음

  • 몇 년 전 핵심 수치는 규모가 아니라 종류 자체가 달랐음
    • GitHub의 대표 주장은 Copilot 사용 시 작업을 55% 더 빠르게 완료한다는 것
    • 비판이 많았으나 이는 성과(outcome) 주장으로, 대담하고 반증 가능하며 가치에 관한 것 — 틀렸다면 틀렸음을 입증할 수 있음
  • 2026년의 주장은 실패할 수 없는 구조
    • "코드의 75%가 AI 작성"은 더 빠른 배포·장애 감소·고객 만족 등 실제 개선과 무관하게 사실일 수 있고 계속 상승함
    • 볼륨 수치는 채택이 정체될 때만 실망을 주며, 채택이 진짜라는 점에는 대부분 동의함
  • 주장은 커졌으나 말하는 바는 줄어듦

광고판에 오르지 않는 부분

  • 성과 증거가 복잡해진 것이 그 사이 벌어진 일

  • 채택을 지지하는 결과

    • Cui et al.: 약 5,000명 개발자 대상 완료 작업 +26%, 특히 주니어 개발자에서 가장 큰 향상 — 거의 논쟁의 여지 없음

  • 반대 방향의 증거

    • GitClear: Copilot 채택이 깊어질수록 코드 처닝(churn) 증가, 리팩터링 붕괴
    • METR: 숙련된 오픈소스 개발자가 자신의 코드베이스에서 AI 사용 시 19% 더 느려졌으나, 본인은 20% 더 빠르다고 믿음

  • METR의 입장 번복

    • 2026년 2월 METR은 사실상 입장을 철회 — 후속 추정치가 속도 향상(speedup) 으로 뒤집힘(오차 범위는 매우 넓음)
    • 개발자들이 이제 AI 없이 작업하기를 거부하고 에이전트 작업의 소요 시간을 신뢰성 있게 자가 보고하지 못해 연구 설계 자체를 폐기
    • 최신 입장: 2026년 AI가 개발자 속도를 높일 가능성이 크나 그 정도를 깔끔하게 측정할 수 없음

  • 기업 단위 효과

    • NBER의 약 6,000명 임원 조사: 69% 기업이 AI 활용 중, 약 10곳 중 9곳이 측정 가능한 생산성 효과 없다고 보고
    • 교차 연구 합의는 조직 단위 약 10% 향상 수준 — 유용하나 "개발자가 더는 필요 없다"는 수준은 아님
  • 여전히 "19% 느려짐"만 인용하는 회의론자도 체리피킹이며, 연구는 계속 갱신되고 업계는 측정 대상만 바꿈

AI 버전의 허영 지표

  • AI 벤더 주장만의 문제는 아님

  • 성숙도 모델과 사다리

    • Carnegie Mellon SEI와 Accenture가 며칠 전 AI Adoption Maturity Model 출시 — 5단계·8차원, "조직 95%가 수익 없음" 통계를 마케팅에 활용
    • Steve Yegge의 "8 levels of AI-assisted development"는 어떤 도구를 쓰고 얼마나 감독하는지로 순위 매김
    • 모든 도구 벤더가 성숙도 사다리를 출시하며 최상단은 보통 "자사 제품을 더 많이 사용"
    • 이들 사다리는 채택 강도를 측정하면서 성숙도라 부르는, 포장만 다른 동일한 대체

  • 정의의 혼란

    • Augment가 219명 엔지니어링 리더에게 "AI-native engineering" 정의를 물었더니 219개의 서로 다른 답변이 나옴

  • Anthropic의 양면

    • "8배 더 많은 코드 출시" 주장과 동시에 올해 가장 엄밀한 연구 중 하나 제시
    • RCT 결과 AI 지원 개발자가 방금 출시한 코드 이해도에서 17% 낮은 점수, 통계적으로 유의미한 생산성 향상은 없음
    • 연구 부문은 갱신하고 마케팅 부문은 볼륨을 세는, 두 가지가 동시에 참인 상황

이 문제에 주목하는 이유

  • 이 수치들은 장식이 아니라 예산·성과 기대치·인력 계획을 움직임

  • AI를 명분으로 한 감원

    • 2월 Jack Dorsey가 Block 인력의 40% 이상(4,000명+) 감축, AI를 명시적 핵심 논거로 제시 — "더 작은 팀이 우리가 만드는 도구로 더 많이, 더 잘 할 수 있음"
    • 몇 주 뒤 Atlassian이 10%(약 1,600명) 감축, "AI가 필요한 기술 구성이나 역할 수를 바꾸지 않는 척하는 건 솔직하지 못함"이라 인정
    • Dorsey는 같은 발표에서 사업이 견조하고 총이익이 성장 중이라 언급

  • 생산성 주장에 대한 의문

    • "AI로 모두가 더 생산적이 되어 인력이 덜 필요하다"면 그 증거를 보고 싶으나 현재 존재하지 않는다고 봄
    • 인력 일부가 실제 유휴·저활용 상태임을 입증해야 하며, 제품/SaaS 기업은 끝없는 로드맵을 가지므로 늘어난 여력을 고객 가치·속도에 써야 정상 — MAU·전환·매출로 나타나야 함
    • 감원을 택했다는 것은 생산성 주장이 이미 다른 이유(과잉 채용, 투자자 압박)로 내려진 결정의 PR 역할을 한다는 신호
  • 효율성 기반 감축이 정당할 때도 있으나, 그럴 때는 토큰 수나 "AI 작성 코드 비율", 성숙도 사다리 등급이 아니라 이미 운영 중인 개인 성과 시스템을 사용해야 함
    • 선별 근거가 허영 지표라면 그 선별은 "립스틱 바른 복권"에 불과함

결론

  • 반(反)AI가 아니며, 모든 엔지니어가 매일 AI를 사용해야 한다는 입장임
    • AI-first든 AI-proficient든 이름과 무관하게 새 도구와 최신 모델을 호기심 있게 시험하는 일이 필요함
    • 업계는 고급 언어, IDE, 자동완성, 애자일, devops를 흡수해 왔고 늘 옛 시절을 그리는 저항자가 있었으나 결국 합류함
    • 이번에 다른 점은 속도 — "클라우드" 도입은 몇 년 미뤄도 생존했으나 AI는 몇 달뿐일 수 있음
  • AI 도입은 출발선이지 점수판이 아님
    • 엔지니어링 성과 측정법은 이미 알려져 있음 — DORA 지표, 신뢰성, 의미 있는 변경 비율, 궁극적으로 매출과 고객 가치
    • 검증된 방식을 버리고 AI 허영 점수를 택할 이유가 없음
  • 벤더 피칭·임원 리뷰·LinkedIn 피드에서 던질 질문: "그것은 성과인가, 볼륨인가?"
  • 일하는 방식은 AI-first로, 측정하는 방식은 검증된(battle-tested) 방식으로 해야함

함께 보면 좋은 글 β

iolothebard   [-]

AI이전에도 개발 생산성을 측정못했는데… AI덕분에 얼마나 늘었고 얼마나 줄었는지… 어떻게 측정한다는 건지…

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

  • 이 이상한 흐름은 2026년 2월 OpenAI 블로그 글 [1]에서 정점에 달한 듯함. 최근 프런트에 올라온 글 [2]인데, 에이전트가 100% 작성한 무언가를 만드는 과정을 다룸
    정작 그 물건이 무엇인지, 사용자에게 어떤 가치를 주는지는 설명이 없음. 가장 가까운 설명이 “이 제품은 내부에서 수백 명이 사용했고, 매일 쓰는 내부 파워 유저도 있다” 정도임
    그런데 코드 100만 줄이라는 사실은 앞부분 몇백 단어 안에서 두 번이나 반복됨
    [1] https://openai.com/index/harness-engineering/
    [2] https://news.ycombinator.com/item?id=48416264

    • “이 제품은 내부에서 수백 명이 사용했고, 매일 쓰는 내부 파워 유저도 있다”라면 아마 이메일 필터일 듯함
      “코드 100만 줄”이고 “에이전트가 100% 작성”했다면 더더욱 그럴 것 같음. 아니면 부서 위키용 JS 메뉴인데, 사실상 jquery를 MS JScript로 다시 만들고 JS 5로 변환하는 물건일 수도 있음
    • 전체 Linux 커널이 약 4천만 줄이고, 드라이버를 빼면 대략 1,600만 줄 정도임. OpenAI가 말한 그 무언가가 Linux 커널의 6%만큼의 코드 줄 수를 가졌다고 해서, 유용성도 6%에 근접한다고는 상상하기 어려움
      LLM이 아무리 강력하더라도 유지보수 가능성도 거의 없을 것 같음
    • Anthropic 주변의 현실 왜곡장도 강함. Anthropic도 전부 AI가 쓴 듯한, 아무 말도 안 하는 허튼 블로그 글을 잔뜩 올리는데 프런트에 가고 꾸준히 수백 업보트를 받음
    • 이거 아니었나?
      https://github.com/openai/symphony
    • 세부 내용이 너무 적어서 실망스러웠음. 그래서 조만간 이런 것들이 실제로 얼마나 효과적인지 보여주는 오픈소스 프로젝트나 시도가 나올 거라고 봄
      팟캐스트 인터뷰에서는 사용자가 다운로드하는 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달러가 넘는다”는 완전히 다른 말이고, 코드에서도 정확히 같은 차이에 대응됨

답변달기