마이너스 2,000줄의 코드

 (folklore.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 1982년 초 Lisa 소프트웨어 팀은 6개월 안에 출시해야 하는 압박 속에서 엔지니어별 주간 코드 줄 수로 진척을 재려 함
  • Bill Atkinson은 줄 수가 생산성을 제대로 보여주지 못하며, 작고 빠른 프로그램을 만드는 목표와도 어긋난다고 봄
  • QuickDraw의 영역 계산 엔진을 더 단순하고 일반적인 알고리듬으로 다시 작성하자, 영역 연산은 거의 6배 빨라지고 코드는 약 2,000줄 줄어듦
  • 첫 관리 양식에서 그 주 작성한 코드 줄 수를 묻는 항목에 Bill은 -2000이라고 적어, 측정 방식의 허점을 그대로 드러냄
  • 몇 주 뒤 관리자들은 Bill에게 더 이상 해당 양식을 요구하지 않았고, 이 일화는 코드 줄 수 기반 관리가 실제 개선을 놓칠 수 있음을 보여줌

Lisa 팀의 코드 줄 수 측정

  • 1982년 초 Lisa 소프트웨어 팀은 향후 6개월 안에 소프트웨어를 출시하기 위해 작업 속도를 높이려 함
  • 일부 관리자는 각 엔지니어가 매주 작성한 코드 줄 수로 진척을 추적하려 했음
  • 엔지니어들은 매주 금요일 제출할 양식을 받았고, 그 안에는 그 주 작성한 코드 줄 수를 적는 항목이 있었음

Bill Atkinson의 -2000

  • QuickDraw 작성자이자 주요 사용자 인터페이스 설계자인 Bill Atkinson은 Lisa 구현에서 중요한 역할을 맡고 있었음
  • Bill은 코드 줄 수 지표가 생산성을 제대로 측정하지 못한다고 봄
    • 좋은 소프트웨어의 목표는 가능한 한 작고 빠른 프로그램을 작성하는 것이라고 생각함
    • 줄 수를 늘리는 지표는 엉성하고 비대하며 고장 난 코드를 쓰도록 부추길 수 있음
  • 당시 그는 QuickDraw의 영역 계산 엔진을 최적화하고 있었음
    • 더 단순하고 일반적인 알고리듬으로 영역 엔진을 완전히 다시 작성함
    • 조정 후 영역 연산이 거의 6배 빨라짐
    • 동시에 코드가 약 2,000줄 줄어듦
  • 첫 관리 양식을 작성할 때 코드 줄 수 항목을 잠시 본 뒤 -2000이라고 적음
  • 관리자들이 어떻게 반응했는지는 확실하지 않지만, 몇 주 뒤부터 Bill에게는 양식 제출을 요구하지 않게 됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Microsoft와 IBM의 코드 줄 수 충돌 사례가 떠오름
    Bob Cringely의 Accidental Empires를 바탕으로 한 PBS TV 시리즈에서 Steve Ballmer가 IBM과 OS/2를 공동 개발하던 경험을 설명하는 장면이 있음
    Microsoft는 작은 회사처럼 일을 끝내는 태도였고, IBM은 내부 지표, 특히 프로그래머 생산성을 KLoC(천 줄 단위 코드 줄 수)로 재는 데 집중했다고 함
    Ballmer는 “그들이 신경 쓴 건 KLoC, KLoC, 또 KLoC뿐이었다”고 했고, IBM은 코드가 좋은지보다 양이 많은지를 더 봤던 듯함
    https://ubiquity.acm.org/article.cfm?id=1022357

    • IBM만 그런 게 아니었음. 몇 년 전 대형 국제 컨설팅 회사가 주 계약자였던 큰 프로젝트에서 일했는데, 코드베이스가 100만 줄을 넘자 전체 팀을 위한 파티를 열었음
      사정을 아는 사람들은 그 “축하”를 장례식처럼 받아들였음
    • 여기서 말하는 TV 시리즈는 Triumph of the Nerds이고, 지금 봐도 훌륭함. 어쩌면 지금 더 볼 만할지도 모름

  • 코드 줄 수를 생산 지표로 세는 건 정말 어리석음
    20년 된 풀 수 없던 버그를 코드 한 줄로 고친 적이 있고, 3년 된 버그는 order by 하나로 해결한 기억이 있음. 코드 한 줄의 영향을 어떻게 측정할 수 있나? 경험상 나쁜 프로그래머가 코드를 훨씬 많이 씀
    Microsoft 개발자가 3만 3천 문자짜리 IBM 코드를 다시 써서 220자로 줄였다는 이야기[1]도 잊을 수 없음. 그 결과 Microsoft의 작업량은 “마이너스”가 되어 전쟁이 벌어졌다고 함
    [1] https://archive.org/details/bigbluesunmaking00carr/page/4/mode/2up 101쪽

    • 생산 지표를 쓰는 것 자체가 대체로 어리석고, 개발자들이 좋은 작업보다 지표 최적화를 하게 만드는 쉬운 방법임
      요즘 예로는 “영향력”, 즉 새 제품 출시를 승진 기준으로 삼는 회사가 있음. 그러면 아무도 유지보수하지 않는 실패한 제품이 잔뜩 생기기 좋음
    • 몇 달에 한 번 치명적 버그를 고쳐 수백만 달러 가치를 만드는 엔지니어도 분명 있겠지만, 일반적으로 훌륭한 엔지니어는 생산량이 많고, 생산량이 적은 엔지니어는 훌륭하지 않은 경우가 많음
    • 장기간으로 보면 코드 줄 수와 엔지니어링 산출 사이에는 어느 정도 관계가 있다고 봄
      위대한 컴퓨터 과학자와 엔지니어 중에는 엄청난 코드 산출량을 보인 사람이 있고, 그게 어떤 방식으로든 영향력으로 직접 이어진다고 믿음. 문제는 코드 줄 수가 성과 측정 지표가 되는 순간임
      그때는 Goodhart의 법칙, “측정값이 목표가 되는 순간 좋은 측정값이 아니게 된다”가 적용됨
    • 예시가 보여주듯, 코드 줄 수가 나쁜 생산 지표인 이유 중 하나는 그것이 코드베이스 유지보수자가 떠안는 부담의 크기를 꽤 잘 나타내기 때문임
      생산 지표 관점에서는 코드를 자산으로 분류하지만, 실제에 더 가까운 관점은 기능이 자산이고 코드 자체는 부채라는 쪽임

  • 이 주제는 자주 올라옴. 이전 논의들은 다음과 같음
    https://news.ycombinator.com/item?id=33483165 (2022)
    https://news.ycombinator.com/item?id=26387179 (2021)
    https://news.ycombinator.com/item?id=10734815 (2015)
    https://news.ycombinator.com/item?id=7516671 (2014)
    https://news.ycombinator.com/item?id=4040082 (2012)
    https://news.ycombinator.com/item?id=1114223 (2010)
    https://news.ycombinator.com/item?id=1545452 (2010)

  • 커리어 초기에 물려받은 1만 줄 넘는 C 프로그램을 500줄 미만으로 최적화한 적이 있음. Sybase 데이터베이스에 SQL 호출을 하는 C 프로그램이었음
    대단한 통찰이 있어서가 아니라, 전임자가 함수를 쓰는 법이나 SQL 질의에 가변 데이터를 넣기 위한 매개변수 사용법을 몰랐을 가능성이 있다는 단순한 가정 때문이었음. 실제로 같은 SQL 문을 값 몇 개만 바꿔서 매번 인라인으로 써두었음
    SQL 호출 코드를 함수 호출로 다시 쓰고, 바인드 변수를 함수 매개변수로 넘기게 했음. 반복된 인라인 코드는 배열에서 바뀌는 바인드 값을 받아 루프 안에서 함수를 호출하는 방식으로 대체됨

  • 가장 큰 영향은 때로 “X는 어떻게 처리할 건가?” 같은 단순한 질문을 던져서 무언가를 아예 만들지 않게 하는 데서 나옴
    그 무언가가 제대로 작동할 기회조차 없었다면, 만들려고 시도하는 전체 비용을 절약한 셈임
    이런 건 숫자 지표로 측정하기 불가능할 뿐 아니라 적을 만들기도 함. 그래도 감히 그렇게 하는 사람들에게 박수를 보냄

    • 그래서 새로 온 사람들에게 머릿속에 그런 루프를 두고, 키보드를 빠르게 두드리기부터 하지 말라고 가르침
      프로그래밍을 빠른 타이핑과 비슷하게 여기는 사람들은 LLM과 흥미로운 유사성을 보임. 잘 쓰이지 않은 코드를 전부 작성했다가 지우고, 다시 작성했다가 지우는 식임
    • 대기업에서 소프트웨어를 관리할 때 책상 위에 연필 상자를 두고 있었음
      부서로 들어오는 정보 요청의 절반 정도는 늘 “매우 중요하고, 지금 당장 필요하며, 큰돈을 벌거나 아낄 수 있다”는 식이었지만, 명백한 답은 “이미 가진 정보로 계산하세요. 계산기와 스프레드시트가 있잖아요. 연필 드릴까요?”였음
      시스템이 X를 처리하게 만드는 것보다 피하는 편이 낫다. 한두 번 쓰일까 말까 한 특수 사례가 시스템을 부풀리고, 아무도 그런 특수 사례나 프로그램이 있는지, 실제로 뭘 하는지 알지 못함. 문서화가 잘돼 있어도 뭐가 가능한지 익히는 데 시간을 쓰지 않음. 그래서 그런 특수 기능 대부분은 실제로 시간 낭비가 됨

  • 대응되는 사고 실험으로 반대 상황을 생각해볼 수 있음. 관리자가 이 글을 읽고 단순하게 삭제한 코드 줄 수로 측정하기로 한다면 더 나아질까, 더 나빠질까?

    • 회사와 측정 방식에 따라 더 쉽게 조작될 수 있음. llama에게 그럴듯한 코드를 만들게 하고, 실제 효과가 없도록 코드를 조금 추가해 커밋한 뒤, 나중에 삭제하면 됨
      이런 종류의 측정은 전반적으로 탄탄한 코드 리뷰 관행이 없는 한 거의 쓸모없음. 여기 사람들이 믿고 싶어 하는 것과 달리 그런 관행은 드묾. 하지만 좋은 리뷰가 있다면 저성과나 지표 조작도 잡히기 때문에 애초에 이런 지표를 도입할 이유가 줄어듦
    • 약간 더 나쁘겠지만, 생각만큼 최악은 아닐 수 있음. 업계에는 이미 그 방향의 근시안적 충동이 비슷하게 존재하기 때문임
      예를 들면 소프트웨어 엔지니어와 난해한 코드 텍스트를 전부 없애고, 제품 관리자가 특수한 다이어그램이나 순서도를 그려 “로우코드”나 “노코드” 결과물을 만드는 식으로 대체하자는 오래된 발상이 있음
    • 줄 수 기반 지표는 전부 의심해야 하지만, ΔSLOC는 아마 그중 덜 나쁜 편임
      추가된 줄과 삭제된 줄을 따로 세어서 +50,-150 패치는 200 ΔSLOC로 계산하겠음
      이건 생산성을 재는 좋은 척도는 아니고, 특히 단독으로는 더더욱 아님. 그래도 변경량을 대략 계산하는 냅킨 수학 지표로는 합리적임. ΔSLOC가 높은 개발자가 ΔSLOC가 1~2주 동안 전혀 없는 동료보다 더 생산적인지는 그 동료가 무엇을 하고 있느냐에 따라 다르지만, 측정 기간 동안 전자가 코드베이스를 더 많이 바꾸고 있다는 점은 확실함
    • 더 나빠짐. 전체 코드베이스를 코드 골프 대상으로 만드는 건 바람직하지 않음
    • 새 기능은 확실히 없을 것임
      제품이 “완성”됐다면 같거나 더 나을 수도 있음. 그렇지 않다면 음수 코드 줄 변경이 배포까지 가지 못할 테니까
      하지만 대부분의 제품은 계속 진화함. 그래서 우리가 같은 프로젝트에 몇 년씩 남아 있을 수 있는 것이고, 삭제만 하는 기여는 결국 아무것도 더하지 않게 됨

  • 진짜 이야기는 프로젝트를 시작할 때 정확히 어디로 가는지 모르는 경우가 있다는 것임
    진행하면서 문제와 원하는 답을 훨씬 더 잘 이해하게 되고, 그러면 큰 덩어리를 뜯어내 더 작고 나은 것으로 바꿀 수 있음
    그리고 이 사람들은 -2000줄의 코드, 그것도 어셈블리 코드까지 포함해 모든 것을 64KB ROM 안에 넣어야 했다는 점도 잊으면 안 됨. 더 작게 만들라는 압박이 매우 강했음

  • Atkinson Dither로 유명한 Bill Atkinson임. https://beyondloom.com/blog/dither.html

    • Bill Atkinson은 Lisa와 Mac UI의 기반이 된 그래픽 라이브러리인 QuickDraw, MacPaint, HyperCard를 만들었음
      그 과정에서 사용자 인터페이스가 동작하는 새로운 방식과, 그것을 해결하기 위한 소프트웨어 작성 방식을 계속 발명해야 했음. 그는 “Mac 하드웨어에서 빠르게 실행 가능”하면서도 “훌륭한 사용자 경험을 제공”하도록 동시에 최적화했고, 그 시너지가 예전 흑백 Mac의 미학 전반에 그의 흔적을 남김. 그 디더링 스타일도 알고리즘적 천재성과 미적 감각이 결합된 또 다른 예임
      이런 감각은 “marching ants” 선택 테두리(https://en.wikipedia.org/wiki/Marching_ants) 같은 것에도 드러남. 고전 Mac UI의 많은 피드백이 픽셀 반전으로 표현된 것도 마찬가지임. 텍스트 선택, 메뉴 강조, 마우스 버튼을 누른 동안 버튼이 보이는 방식, 창을 드래그할 때의 경계선 등이 그렇고, XOR 모드로 위에 그리는 것이 이런 효과를 만들기 아주 좋은 방법이었음
      QuickDraw에서 이런 도구를 조합한 방식은 Steve Jobs와의 유명한 둥근 사각형 대화(https://www.folklore.org/Round_Rects_Are_Everywhere.html)가 실제로 QuickDraw에서 사각형만큼 쉽게 둥근 사각형을 그릴 수 있게 되는 결과로 이어졌고, 운영체제 곳곳에 둥근 사각형이 나타나게 만들었음
      Mac UI의 성공은 단지 보기 좋아서가 아니었음. 상당 부분은 Bill Atkinson이 보기 좋은 것을 쉽게 만들 수 있게 해주는 영리하고 작은 도구 세트를 만들었기 때문임
      Susan Kare의 훌륭한 아이콘들도 Bill이 32x32 픽셀 마스크 비트맵을 UI에 쉽게 넣고 클릭 시 반전시킬 수 있는 도구를 만들지 않았다면 그렇게 애정 어린 기억으로 남지는 못했을 것임

  • 교훈은 Einstein만큼 똑똑해도 결국 직원이고, 직원으로서 해야 할 일을 해야 한다는 것임

    • Einstein이 지표 압박을 받았다면 우리는 그의 이름을 들어보지 못했을 것임

  • 사람들이 작성한 코드 줄 수를 말할 때 왜 항상 “추가한 줄 - 삭제한 줄”로 계산하는지 이해한 적이 없음
    내가 10km 달리기를 하고 출발점으로 돌아왔다고 해서 0km를 달린 건 아님

    • 멍청한 차이 비교 도구가 기능 변화는 제한적인데도 줄을 이리저리 옮긴 것까지 큰 차이로 기록할 수 있기 때문도 일부 있을 것 같음
      예를 들어 if cond { ... return; } ... 형태를 if cond { ... return; } else { .... }로 바꾸는 식임
      그렇다고 그 설명이 전부를 포괄하진 못함
답변달기