아무도 기억하지 못하는, 발생하지 않은 문제를 해결한 공로 (2001) [PDF]

• 기업들은 Toyota식 제조 역량, six-sigma 품질, Dell식 공급망 같은 운영 역량을 따라잡기 위해 큰 비용을 쓰지만, 개선 프로그램이 지속 성과로 이어지는 경우는 드묾
• TQM은 한때 널리 쓰인 뒤 급격히 밀려난 사례로, Fortune 1000 중 잘 발달한 TQM 프로그램을 가진 기업은 10% 미만이었음
• 실패의 원인은 특정 도구 선택보다 새 프로그램이 물리적·경제적·사회적·심리적 구조와 맞물리는 방식에 있으며, 개선은 결국 시스템 문제가 됨
• 성과 격차가 커지면 조직은 더 오래 일하는 Work Harder와 역량을 키우는 Work Smarter 사이에서 선택하지만, 후자는 지연과 실패 위험 때문에 밀리기 쉬움
• 개선 시간을 줄이는 Shortcuts는 단기 산출을 높여 매력적이지만, 늦게 드러나는 역량 저하가 누적되면 조직을 Capability Trap에 가둘 수 있음

---

개선 프로그램이 실패하는 역설

• 기업들은 제조, 품질, 고객 이해, 공급망 관리 같은 운영 역량을 개발하기 위해 프로세스 개선에 적극 투자함
• 1997년 미국 기업의 경영 컨설턴트와 교육 지출 합계는 1,000억 달러 이상이었고, 상당 부분이 우수 기업의 운영 역량을 따라잡는 데 쓰였음
• 일부 극적인 성공에도 많은 개선 프로그램은 의미 있는 결과를 만들지 못함
• TQM은 이 역설을 잘 보여줌
  • 1980년대 일본 기업의 성공에 자극받아 미국 기업 사이에서 크게 유행함
  • 1990년대 중반에는 학계와 비즈니스 매체의 관심이 줄고, re-engineering 같은 새 혁신에 밀려남
  • TQM의 규율과 방법에 진지하게 헌신한 기업은 경쟁사보다 높은 성과를 냈음
  • 한 연구에서 Fortune 1000 중 잘 발달한 TQM 프로그램을 가진 기업은 10% 미만이었음
  • 다른 연구에서 TQM은 1993년 세 번째로 많이 쓰인 비즈니스 도구였지만 1999년에는 14위로 떨어짐
• 과거의 개선 기법은 이름을 바꿔 다시 등장하기도 함
  • 통계적 공정 관리와 변동 감소의 핵심 규율은 six-sigma로 이어짐
  • quality circle은 high-performance work team으로 다시 불림

도구보다 어려운 것은 구현 구조

• 성과 개선 도구와 기법은 빠르게 늘었고, 정보기술과 컨설턴트 증가로 어떤 기법을 누가 쓰는지 배우기도 쉬워짐
• 대부분의 관리자에게 더 큰 장벽은 새 방법을 아는 일이 아니라, 그것을 일상 업무에 성공적으로 구현하는 일임
• six-sigma 품질 프로그램 같은 역량은 턴키 제품처럼 살 수 없고, 조직 내부에서 개발되어야 함
• 10여 년 동안 통신, 반도체, 화학, 석유, 자동차, 레저 제품 산업에서 12건 이상의 심층 사례 연구가 수행됨
  • 관찰, 참여자 인터뷰, 기록 자료, 정량 지표가 사용됨
  • 구현과 개선의 동학을 포착하기 위한 모델도 함께 개발됨
• 대부분 조직이 개선 혁신의 이익을 온전히 얻지 못하는 이유는 특정 개선 도구의 선택과 거의 관련이 없음
• 새 개선 프로그램은 도구, 장비, 작업자, 관리자, 물리적·경제적·사회적·심리적 구조가 맞물린 곳에서 작동하므로 시스템적 문제가 됨

개선의 기본 물리학: 시간과 역량

• 프로세스의 실제 성과는 일하는 시간(Time Spent Working) 과 그 일을 수행하는 프로세스 역량(Capability) 에 의해 결정됨
  • 제조에서는 하루 노동시간과 생산성, 즉 노동시간당 사용 가능한 산출의 곱으로 순사용 산출이 정해짐
• 성과는 일을 더 하거나 개선에 더 투자해 높일 수 있지만, 두 방식의 결과는 다름
  • 주당 근무시간을 20% 늘리면 초과근무가 유지되는 동안 산출이 20% 늘 수 있음
  • 프로세스 역량 개선은 이후 투입되는 모든 작업 시간의 산출을 높임
  • 결함 제품 재작업을 위한 초과근무는 초과근무가 계속될 때만 산출을 늘리지만, 결함의 근본 원인 제거는 재작업 필요를 지속적으로 줄임
• 역량은 시간이 지나며 축적되는 자산(stock) 으로 다뤄짐
  • 개선에 쓰는 시간은 역량 투자를 늘림
  • 근본 원인을 찾고, 해결책을 발견·시험·구현하는 데 시간이 걸리므로 개선 활동과 역량 변화 사이에는 지연이 있음
  • 기계 마모, 공정 이탈, 설계 노후화, 절차 구식화 때문에 정기적으로 유지되지 않는 역량은 쇠퇴함
• 개선 지연은 프로세스의 기술적·조직적 복잡성에 따라 달라짐
  • job shop의 기계 수율처럼 비교적 단순한 프로세스 개선 지연은 몇 달 규모임
  • 제품 개발처럼 복잡한 프로세스 개선 지연은 몇 년 이상일 수 있음
  • 제품과 인력 변화율이 높은 조직에서는 개선된 역량의 수명도 짧아짐

Work Harder와 Work Smarter의 긴장

• 경영진은 고객 수요, 보험 청구 처리량, 분기 신제품 출시 수 같은 목표를 Desired Performance로 설정함
• 실제 성과와 목표의 차이는 Performance Gap이 되며, 연구 대상 조직에서는 기대치를 웃도는 프로세스를 찾기 드물었음
• 자원 증설이나 추가 채용을 꺼리는 조직에서 성과 격차를 닫는 기본 선택지는 두 가지임

• Work Harder 루프

  • 관리자는 성과 격차가 있을 때 작업 속도 증가, 초과근무, 더 공격적인 목표, 목표 미달 페널티 같은 방식으로 작업 압력을 높임
  • 성과 검토 빈도, 검토 세부 수준, 검토자의 직급 같은 더 미묘한 방식도 작업 압력에 포함됨
  • 한 회사에서는 고위 부사장이 공장 현장의 개별 기계 성과를 검토했고, 이는 기계를 어떤 대가를 치르더라도 계속 돌리라는 메시지가 됨
  • 한 프로젝트 관리자는 담당 서브시스템 일정이 늦어지자, 프로토타입이 사양을 충족할 때까지 매시간 상태 보고 전화를 요구받음

• Work Smarter 루프

  • 관리자는 개선 프로그램 시작, 새 아이디어 실험 장려, 교육 투자 등을 통해 프로세스 역량을 높이려 할 수 있음
  • 성공하면 시간이 지나 역량이 좋아지고 처리량이 늘어 성과 격차가 줄어듦
  • 개선 투자는 장기적으로 더 큰 효과를 낼 수 있지만, 효과가 나타나기까지 상당한 지연이 있고 근본 원인 발견이나 새 도구 적용이 실패할 위험도 있음
  • 긴급한 문제에서는 Work Harder가 자주 선택됨
  • 중요한 고객을 담당하는 제조 라인이 멈추면, 관리자는 신뢰성 개선 교육보다 라인을 다시 돌리고 출하가 끝날 때까지 초과근무를 밀어붙이기 쉬움
  • 일시 대응이 끝난 뒤에도 개선 활동으로 돌아가지 못하면, 더 열심히 일하는 방식이 표준 운영 방식이 됨

재투자 루프와 역량 함정

• 조직에는 여유 자원이 거의 없기 때문에 작업 압력이 커지면 사람들은 휴식 같은 비작업 활동을 줄이고 초과근무를 늘림
• 지식노동자의 초과근무는 종종 무급으로 밤과 주말까지 이어져 가족과 공동체 활동 시간을 빼앗음
• 시간이 더 이상 늘어나지 않으면, 계속 커지는 성과 격차를 맞추기 위해 개선 시간을 줄일 수밖에 없음

• Reinvestment 루프

  • 개선 투자가 성공하면 성과가 오르고 성과 격차가 줄어 더 많은 시간을 개선에 쓸 수 있어 선순환이 생김
  • 반대로 처리량 격차에 작업 압력으로 대응하면 개선 시간이 줄고 역량이 쇠퇴하며 성과 격차가 더 커져, 더 강한 작업 압력과 더 적은 개선으로 이어지는 악순환이 생김
  • 성공한 개선 사례에서는 생산성 향상으로 확보된 자원을 다시 개선 활동에 명시적으로 배분해 재투자 과정을 강화함
  • 다수 조직에서는 비용·일정 압박이 다운사이징이나 더 높은 성과 목표로 이어져 개선 자원을 빼앗고, 역량이 정체하거나 떨어짐

• Shortcuts 루프

  • 개선 회의 생략, 예정된 예방정비 연기, 문서화 요구 무시 같은 지름길은 당장 작업 시간을 늘림
  • 역량 저하는 즉시 나타나지 않기 때문에 지름길은 단기적으로 효과적이고 매력적으로 보임
  • 예방정비를 미룬 관리자는 예정된 다운타임을 피하고 정비 비용을 아끼는 유예 기간을 얻지만, 나중에 장비 노후와 마모로 수율과 가동 시간이 떨어짐
  • 문서화를 생략한 소프트웨어 엔지니어는 프로젝트를 제때 끝낼 수 있지만, 몇 주나 몇 달 뒤 테스트에서 발견된 버그를 고칠 때 그 비용을 치름

• Capability Trap

  • Work Harder는 처음에는 총처리량을 바로 높이고 개선 시간 감소의 비용은 늦게 나타나므로 better-before-worse 상황을 만듦
  • Work Smarter는 단기 산출을 줄이지만, 시간이 지나 역량 상승이 작업 노력 감소를 상쇄해 성과를 높이는 worse-before-better 동학을 가짐
  • Shortcuts와 Reinvestment의 상호작용은 조직을 역량 하락의 악순환에 가두는 Capability Trap을 만들 수 있음

[GN⁺]

Hacker News 의견들

• 기억이 좀 흐릿하지만 좋은 사례가 있음
  한 조직에서 중요한 주문 처리가 있었는데, 필요한 정보가 전부 오거나 정확히 온다고 믿을 수 없는 상황이었음. 그래서 입력값을 다듬고 처리 방식을 바꾸는 검증 로직을 만들었고, 각 주문에서 어떤 검증이 트리거됐는지 지표로 남겼음. 새 검증을 추가하면 날짜도 붙였음
  이 지표를 공개하고 가끔 공유하니, 누가 “XYZ면 어떻게 되나요?”라고 물을 때 “이미 처리했고, XYZ 때문에 ####건의 주문이 막히는 걸 방지했다”고 답할 수 있었음
  팀이 신중하게 일했고, 시스템이 계속 잘 굴러가려면 이런 작업이 필요하며, 그걸 데이터로 뒷받침할 수 있다는 점이 드러남. 덕분에 조직 내 대화가 “왜 생각 못 했냐”보다 “이제 뭘 하면 되냐”로 바뀌었고, 예방적 품질에 대한 인정도 위로 올라갔음

  • 어떤 검증이 몇 번 트리거됐는지 계측한 아이디어에는 단순하지만 부정할 수 없는 천재성이 있음
    대부분의 팀은 주문 성공률 같은 지표만 보고 끝냈을 텐데, 나쁜 데이터를 처리한 횟수를 지표로 삼으면 좋은 일이 눈에 띄지 않는 함정에서 벗어날 수 있음

• 최근 직장에서 정확히 같은 일을 겪었음
  조직의 기술 리드/아키텍트로서 최근 출시된 프로젝트들을 검토했고, 심각한 신뢰성/성능 문제 때문에 반드시 개선해야 할 부분을 찾았음. 한 팀의 여러 릴리스가 목록 상단에 있었지만, 그 팀의 PM과 엔지니어링 매니저, 그리고 위쪽 사람들은 기능 업데이트를 우선해야 한다며 모든 우려를 무시했음
  몇 달 뒤 휴가 중에 일이 터졌고, sev 1 에스컬레이션이 발생했으며 여러 고객이 화났고 CEO/CTO까지 관여함. 문제의 조잡한 코드를 쓰고 경고를 무시했던 바로 그 팀이 밤낮없이 일해 서비스를 복구했고, 이제 그들은 영웅이 됨. 특히 그 매니저는 장애 중 활발히 소통하고 리더십을 보여줬다는 이유로 회사에서 평판이 좋아짐

  • 가끔 영웅적인 대응을 하는 건 그 사람을 믿을 수 있다는 신호가 될 수 있음. 하지만 영웅적 대응이 일상이라면 나쁜 작업이거나 나쁜 관리일 가능성이 크고, 더 면밀히 봐야 함
    남이 만든 문제를 고치는 쪽이 더 인상적임. 자기 실수를 고친 사람에게 칭찬을 퍼붓고 싶지는 않고, 나도 내 실수를 고쳤다고 칭찬을 기대하지 않음. 애초에 망친 것에 대해 모두에게 사과할 것임
  • 예전 이메일을 꺼내서 “실수로” 다시 보내볼 수도 있음. 좀 쪼잔해 보이겠지만, 일부는 지난 몇 달을 다시 생각할지도 모름
  • 이걸 소프트웨어 개발의 비극이라고 부르고 싶음. 방화범이 소방관이 되는 구조임

• 제목의 문제를 내 가치와 관련해서 계속 생각하게 됨
  누군가 3개월 동안 막혀 있던 일을 40분 만에 도와주면 내 가치는 모두에게 분명함. 그런데 내가 내내 같이 일해서 아무도 3개월 동안 막히지 않으면 내 가치는 불분명해짐. 이 역설을 어떻게 다뤄야 할지 모르겠음

  • 내가 거친 교육 시스템은 결과가 노력과 시간에 거의 선형적으로 비례한다고 가르치도록 설계돼 있었음. 졸업 후 첫 교훈은 그게 아니라는 것임
    노력과 시간을 더 들이면 보상은 뒤처진 채 더 많은 노력과 시간을 기대받게 되는 경우가 많음. 가치와 기회는 노력과 시간에 대해 혼돈적인 과정에 가까움
    결국 기회가 나타났을 때 붙잡을 수 있도록 정신이 맑을 만큼 업무량을 유지하려고 해야 함. 정직하고 균형 잡힌 동료가 도움이 되지만, 궁극적으로는 스스로 해야 할 일임
  • 더 나쁜 경우도 있음. 사람들이 자주 막히고 곧바로 도움을 요청함. 모두를 풀어주다 보면 내 일은 뒤처지고, 상사의 상사가 개발자 지표를 요구하면 내가 처리한 포인트도 적고 바꾼 코드 줄 수도 적음
    상사가 설명하려 해도, 다음 해고 때 잘리는 건 내 머리일 수 있음
  • 시간제 계약자로 그런 일을 해본 적 있음. 첫날에 그들의 6개월짜리 문제를 고쳤고, 이후 다른 일로 더 고용해주길 바랐지만 “필요한 건 그게 전부였다”고 함
    다른 회사들에 내가 이런 일을 잘한다고 말해주긴 했지만 아무 일도 이어지지 않았음. 작은 회사 대상 계약직은 그날이 처음이자 마지막이었음
  • 정말 좋은 상사는 이 문제를 보완함. 팀워크와 협업을 밀면서도 각 개인이 무엇을 하고 전체에 어떻게 기여하는지 세부를 알고, 대체로 정확히 보상·승진·해고를 판단할 수 있음
    그래서 팀원의 사기가 꺾이지 않음. 팀원은 심리적으로 자신의 개인 기여를 인정받을 필요가 있음
    이런 상사들은 유능한 개인 기여자였다가 팀 리드가 된 경우가 많고, 스스로 그 기술의 숙련자이기 때문에 관리하는 개인 기여자를 가장 잘 판단할 위치에 있음
  • 이 현상을 다루는 과소평가된 방법은 제대로 된 자기 홍보라고 봄. 재앙을 막기 위해 무엇을 했는지 끊임없이 말해야 함
    피한 재앙을 생생하게 묘사해서 사람들이 명확한 그림을 떠올리게 해야 함

• 또 다른 변형은 실제로 한 번 일어난 문제를 막는 데 자원을 과하게 배정하고, 더 심각하지만 아직 일어나지 않은 문제는 덜 챙기는 것임
  이는 관리 문제임. 다른 더 중요한 일을 하는 게 합리적이었더라도, 같은 사고가 반복됐을 때 책임지고 싶어 하는 사람은 없기 때문임

  • 이런 걸 어디선가 블로그 글에서 제도적 흉터라고 부르는 걸 본 적 있음
    작은 상처가 딱딱하고 유연하지 않은 조직으로 대체되는 식임. 어떤 일이 한 번 일어났다고 해서 다시는 안 일어나도록 반드시 바꿔야 하는 건 아니며, 그런 과잉 반응이 미래에 큰 부담이 될 수 있음
    그 손실을 받아들이고 다시 일어날 수도 있음을 인정하는 편이, 확실히 막겠다며 과도하게 예방하는 것보다 나을 수 있음
  • 법전에 있는 반응적 입법 상당수도 정치인들이 뭔가 하는 것처럼 보이고 싶어서 생긴 것에 가깝고, 대체로 형편없음
  • 관료제는 기본적으로 이렇게 생겨남. 스타트업은 모든 게 너무 새로워서 문제가 일어날 시간이 없었음. 빅테크는 과거 사고와 그 결과로 생긴 보호장치에 대한 지식 기반이 엄청나서, 모든 단계가 관료주의에 빠진 것처럼 보임
  • 전혀 상상 속인 문제의 가능성과 심각성을 부풀리기는 매우 쉬움. 단순히 나쁜 습관일 수도 있고, 의도적인 전술일 수도 있음. 어느 쪽이든 많은 노력, 시간, 돈이 낭비됨
    실제로 어떤 일이 일어나기 전까지 예방 자원을 배정하지 않는 정책은 어느 정도 합리적임
  • 커리어 내내 금융 기술 분야에서 일해서 다른 조직은 어떤지 모르겠지만, 이 문제는 정말 정확함. 대형 투자은행들은 딱 이렇게 반응함
    장애에 과잉 반응하고 있다는 점과 실제 발생한 문제에는 매우 단순한 해결책이 있다는 점을 설득하느라 비참한 1년을 보냈음. 하지만 고위 관리자는 재발 때문에 자기 자리가 위험해 보이면, 부서 전체에 유사 문제 코드를 검토하고 수정하라고 지시함. 그리고 이상하게도 엄청나게 과설계된 해결책을 내놓는 가장 큰 목소리에 귀를 기울임
    또 한 번은 비밀번호 만료 때문에 거래 스택에 장애가 났음. 이걸 “다시는 안 일어나게” 하겠다며 우스울 정도로 복잡한 수제 해결책에 들어간 노력이 황당했음. 결국 1년 넘게 작업한 뒤 전부 버려졌고, 처음부터 했어야 할 훨씬 단순한 중앙화 해결책으로 바뀜

• 예전에 일하던 곳이 떠오름. 피드백을 요청할 때마다 “여기서는 PIR(post-incident response) 없이는 아무것도 우선순위가 되지 않는다”고 반복했음
  끝무렵에는 PIR 관련 티켓이 올라오면, 그 사고를 막을 수 있었지만 백로그에서 죽어가던 실제 티켓의 중복으로 표시했음. 우리 담당 영역에서 예측 가능한 문제를 막는 데 아무 영향력도 없다는 건 팀 사기를 크게 해쳤음
  팀원 대부분은 개선 제안을 아예 멈췄음. 관리층이 우리가 직접 티켓을 끌어오도록 허용하지 않았기 때문임

• 기업식 Scrum이 어떤 지옥으로 변하고 있는지 아주 잘 묘사함
  Agile은 말 그대로 빠르게 일하고 역량을 빠른 주기로 개선하자는 것이었음. 그런데 Scrum은 대체하려던 계획 프로세스보다 더 나쁜 버전이 됨
  Scrum이 일을 당장 눈앞의 문제로 쪼개는 방식은 오히려 이 순환을 악화시킴. 장기적으로는 불은 위로 밀려 올라가고 기술 부채는 아래로 밀려나는 티켓 시스템이 됨
  게다가 컨설턴트와 임원이 최적화 놀이를 하기 쉬운, 추적하기는 쉽지만 의미 없는 효율성 숫자까지 뱉어냄

  • “Scrum은 대체하려던 계획 프로세스보다 더 나쁜 버전”이라고 하는데, 마치 우연인 것처럼 말하네
    이런 말 해도 됨. 내 친한 친구들 중에도 스크럼 마스터가 있음
  • Agile은 결국 PM이 상위 관리자에게 보고하고, 그 상위 관리자도 다시 위로 보고하기 위한 방식으로 귀결된 것 같음
    왜 그런지는 이해됨. 할 수 있는 수많은 일 중 무엇을 할지 누군가는 결정해야 함. 이 기능이 돈을 벌어줄까? 기능은 아니지만 자원 비용을 줄이는 작업은 어떨까? 기능 전달 속도를 늦춘다는 기술 부채는 어떨까?
    나는 고위 관리자는 아니지만, 결국 위쪽 누군가는 회사가 살아남아 돈을 벌고 우리 월급을 줄 책임이 있음. 그들도 우리처럼 얻을 수 있는 적은 정보로 결정을 내려야 함. 그래서 “이건 비용이 얼마고 가치가 얼마인가”와 “저건 비용이 얼마고 가치가 얼마인가”를 비교할 방법이 필요함
    이를 추정할 방법이 필요했고, 기술 업계가 그 수단으로 Agile을 홍보하자 거기에 붙잡힌 것임. 누구 잘못일까?
    그렇게 잦은 추정, 일정 추적, 의식들이 따라왔음. 이게 자연스럽게 따라와야 한다고 믿지 않는 사람도 있고 나도 동의함. 하지만 어쨌든 그 의식들은 컬트의 일부가 됨
    우리는 Scrum을 버렸고, 정제 회의와 스토리 추정, 스토리 포인트도 버렸음. 이제는 한 달에 한 번 PM과 공식적으로 만나 팀 단위로 현재 위치를 티셔츠 사이즈 추정으로만 봄. 그 외에는 PM이 요청할 때나 우리가 필요하다고 느낄 때 업데이트함. 덕분에 권한은 우리에게 있지만, 그만큼 책임감을 갖고 상황이 불안해 보이면 제때 알림. 여전히 “추정”은 해야 함. 결국 고위 관리자는 결정을 내려야 하니까. 하지만 전반적으로는 꽤 가볍고, 정말 해방감이 있음
  • Scrum이 제대로 운영되면 효율적이라는 생각이 한 회사에서는 사실이었음
    모두가 프로세스에 전념했고, Scrum 팀은 노력의 20%를 부채 처리 우선순위로 잡았음. 각자의 속도도 꽤 정확해서 개인 관심사 작업 20%를 추가로 반영할 수 있었고, 이해관계자 우선순위는 남은 60%를 채웠음
    어떤 스프린트에서는 에픽이나 팀 목표를 끝내기 위해 힘을 실어야 하거나 긴급 상황/버그 때문에 우선순위를 바꿔야 하면 방향을 틀었음
  • 문제가 보일 때 프로세스를 조금씩 추가하고, 일이 잘 굴러가면 프로세스를 완화하는 식으로 Scrum까지 쌓아 올리는 편이 더 잘 작동했음
    프로세스를 추가하고 싶어서 잔뜩 추가하는 건 가치를 만들지 못함
  • Scrum은 매주 스탠드업에서 일을 끝내려고 우르르 모이는 걸 뜻하는 줄 알았음

• 사무실에 붙여둔 이 만화가 떠오름: https://naksecurity.medium.com/the-detriments-of-hero-cultur...
  그래서 많은 기업 문화에서는 문제가 자기 즉각적인 담당 영역이 아니면, 고칠 방법을 알아도 선제적으로 막지 않는 편이 보상에 유리함. 문제가 드러나게 두고, 누군가의 긴급 상황이 되게 한 다음 고치면 됨
  물론 장기적으로 그런 조직은 잘될 리 없으니 떠날 계획도 세워야 함

  • 시간이 지나면 누가 매달 소방 훈련을 벌이고, 누가 조용히 일을 끝내는지 사람들이 알게 된다고 봄

• “아무도 일어나지 않은 문제를 고친 공로를 인정받지 못한다”(2001) [pdf]가 떠오름
  유튜버나 소셜 미디어 클릭베이트가 Y2K 버그는 별일 아니었다고 주장할 때마다 이 생각이 남
  별일 아니었던 이유는 나 같은 수많은 베테랑들이 몇 달 전부터 밤을 새우며 작동하도록 만들었기 때문임
  아직도 UTC 자정 카운트다운 때의 긴장을 기억함. 그다음 동부 시간 카운트다운 때 다시 긴장했고, 로컬 시간 때 또 한 번 그랬음. 태평양 시간이 2000년이 되고서야 겨우 긴장을 풀 수 있었음

  • 어떤 Y2K 버그를 말하느냐에 따라 다르지만, 이런 일은 실제로 일어났고 충분히 믿을 만한 시나리오임. 비교 가능한 상황은 아니라고 봄
  • 아직도 완전히 납득되지는 않음. 컴퓨터들은 대부분 날짜에 dd/mm/yy가 아니라 epoch time을 쓰지 않나?
    2038년에 알게 되겠지

• 같은 시기라면 Y2K도 아주 좋은 예임. 눈에 띄는 일은 거의 안 일어났지만, 사람들이 그냥 무시했다면 많은 일이 벌어졌을 가능성이 큼

  • “가능성”이 아님. 1998년에 BP에서 직접 코드 고치는 일을 했음. 나쁜 일이 벌어졌을 거라고 단언할 수 있음
    내 월급이 거기에 달려 있었기 때문도 아님. 다른 일할 기회는 당연히 많았음. 실제로 에너지 산업을 마비시킬 수 있는 문제였고, 주요 기업과 그 수많은 의존 조직에 영향을 줬을 것임. 이 경험을 보면 금융이나 자원 개발 같은 여러 산업에도 직간접적으로 같은 충격이 있었을 거라고 봄
    그래서 좋은 예임. 아직도 Y2K를 별일 아닌 소동으로 기억하는 사람을 만남. 아니었음. 당신에게 문제가 아니었던 건 많은 사람이 열심히 막았기 때문임
    그 문제들은 엄청 복잡하진 않았지만 널리 퍼져 있었고 중요했으며, 큰 작업량이 필요했음. 인류의 위업으로 내세울 달 착륙급 공학 문제라기보다는, 폭발 전에 수많은 멍청한 Challenger O-ring 문제를 고치는 것에 가까웠음
  • 매우 중요한 사례임. Y2K를 고치는 데 엄청난 투자가 있었고, 실제 날짜보다 훨씬 전부터 시작됐음. 예를 들어 Y2K 이후 만기일을 가진 금융상품은 만기가 되기 전에 고쳐야 했음
    그래서 당일에는 사소한 잔여 버그만 조금 남았음. 신문에 농담 몇 개는 있었지만 대중은 대체로 그냥 지나갔음
    나는 기후 분야에서 일하고 있고 같은 일이 일어나길 바랐거나 바라고 있음. 하지만 곧 모두의 관심을 끌 수밖에 없을 것처럼 보임
  • 준비의 역설임
    준비되어 있으면 아무 흥미로운 일도 일어나지 않고, 삶은 계속되고, 사람들은 노트북을 열어 버튼 몇 개 누른 정도로 기억함
    준비되어 있지 않으면 텍사스 전력망이 얼어붙고, 사람들이 죽고, 저축을 잃고, “이렇게 나쁠 줄은 아무도 상상 못 했다”가 됨
  • Y2K가 별일 아니었다며, 문제 예방 노력이 완전한 세금 낭비였다고 하는, 더 잘 알아야 할 사람들까지 봤음
    고백하자면 나도 그 작업에 참여했음. 웃긴 건 이전 고객사로 다시 불려가서, 과거의 내 작업이 말 그대로 만든 문제를 고쳤다는 점임. 문제를 보자마자 20분 만에 고쳤음. 그리고 “온 김에 이것도 좀 봐줄래요…”가 이어졌고, 그 부서가 닫혀 뉴욕으로 옮겨질 때까지 약 2년 지속됨
    적어도 청구 가능한 시간으로는 인정받았음

• 이 글이 바로 직후에 쓰였길래 Y2K 얘기일 줄 알았음
  90년대 후반 몇 년 동안 Y2K 프로젝트를 하며 영국의 핵심 인프라가 자정에 멈추지 않도록 도왔음. 예를 들어 우리의 노력 없이는 웨일스에 물이나 가스가 없었을 것임
  그런데 이후 “아무 일도 안 일어났으니 명백히 문제가 아니었는데 왜 Y2K에 그렇게 돈을 썼나?”라거나 “Y2K는 IT 업계가 만든 사기였다”는 말을 들었음
  우리는 이겼음. Y2K 버그를 성공적으로 막았고, 힘든 일이었으며, 자정까지 전부 잡았는지도 확실하지 않았음. 그런데 축하받기보다 일부는 우리가 바가지를 씌웠다는 증거로 봤음. 사람들은 이상함

  • 그런 문제를 여럿 알고 있음. 나도 작업하던 비디오 게임의 최고 점수가 제대로 동작하게 만들었음
    짜증나는 건, 기후 변화에서도 최선의 시나리오가 이와 같다는 점임. 실제로 종말을 피하는 데 성공하면 모든 “기후 부정론자”가 자기들이 옳았다고 느낄 것임

[GN⁺]

Hacker News 의견들

• 제목을 보니 흥미로운 고대 중국 일화가 떠오름. Toyota가 최근 스캔들에 휘말린 것도 조금 아이러니함: https://www.bbc.com/news/articles/c1wwj1p2wdyo
  위나라 문왕이 편작에게 “세 형제가 모두 의사라면 누가 가장 뛰어난가?”라고 묻자, 편작은 “큰형이 가장 뛰어나고, 둘째 형이 그다음이며, 저는 가장 못합니다”라고 답함
  큰형은 병이 아직 형체를 갖추기 전에 알아차려 남몰래 없애므로 집안에서만 이름이 알려졌고, 둘째 형은 병이 막 드러나려 할 때 치료하므로 마을 골목 밖으로 이름이 나가지 않으며, 편작 자신은 혈관을 찌르고 강한 약을 쓰고 살을 가르기 때문에 눈에 보이는 행위 덕분에 제후들 사이에 이름이 퍼졌다는 이야기임

  • “큰형은 버그가 생기기 전에 막아내므로 같은 개발팀만 실력을 알고, 둘째 형은 버그가 나타나자마자 조용히 고치므로 기술 부서 전체가 실력을 안다. 나는 매일 사방의 불을 끄러 뛰어다니니 회사 전체가 나를 안다”라는 식으로 그대로 소프트웨어 조직에 대입 가능함
  • 예방 한 온스가 치료 한 파운드보다 낫다는 격언과 같음
  • Toyota 스캔들을 “최근”이라고 하기엔 해당 기사가 2024년 6월 기사임
  • 더 단순하게 말하면 “제때 한 바느질이 아홉 바느질을 아낀다… 하지만 나는 바느질 횟수로 돈을 받는다”가 됨
  • 이 일화의 출처가 궁금함. 장자에서 찾아보려 했지만 못 찾았음

• “고생하는 부서”가 자신들이 만든 문제를 영웅적으로 수습했다는 이유로 다음 분기에 칭찬과 예산 증액을 받는 회사를 겪어봄
  반면 조용히 잘 돌아가던 내 부서는 불을 계속 켜두는 것조차 버거웠음
  더블클릭 정도만 이해하는 비기술 경영진과 회사를 실제로 떠받치는 엔지니어링 사이의 단절 때문에 이 업계에서 심각한 문제가 됨. 경영진이 엔지니어링 출신이 되는 것 말고는 해결책이 잘 떠오르지 않음

  • 시스템 안에 고통 신호를 넣어야 함. 손이 다쳐도 뇌로 통증을 보내지 않으면 해를 만든 행동이나 우선순위를 바꾸지 않듯, 조직도 모든 문제를 조용히 고치고 위로 올라가지 못하게 막는 것이 항상 최선은 아님
    어떤 문제는 리더십이 배우는 기회가 되도록, 수리하기 전에 통증 신호를 위로 보내야 함
    다만 인센티브 설계가 어렵고, 최고위 경영진이 부하와 부서가 고통과 문제를 드러내지 못하게 만드는 구조가 되지 않아야 함. 선의로 신호를 가리는 사람도 흔하므로, 큰 조직에서는 일부 문제가 전개되도록 두고 너무 반응적으로 움직이지 않는 편이 더 효율적이라는 점을 코칭할 필요가 있음
  • 35년 넘게 IT에서 일하며 가장 싫어한 성향 상위권이 영웅 행세였음. 반대로 팀에는 항상 “파괴자” 엔지니어가 필요하다고 봤음
    모두가 정상 조건과 완벽한 운영을 전제로 설계할 때, 설계·서비스·인프라·앱을 어떻게 망가뜨릴 수 있는지 찾아내는 사람이 중요함
  • 예전 직장에서 CEO 겸 오너가 비용 절감을 찾아내면 첫해 절감액의 20% 정도를 보너스로 주겠다는 아이디어를 냈음
    IT 부서 동료가 상용 인증서를 Let’s Encrypt로 바꾸고 EV 요구사항을 없애면 2,000유로 조금 넘게 받을 수 있었지만, 결국 못 받았음. 그런 일은 “원래 업무”라는 이유였음
  • 실패하는 관리자가 오히려 계속 승진해서 사실상 엔지니어링 전체를 맡는 걸 봤음. 프로젝트는 모두 실패했지만 더 많은 예산과 개발자를 받아 확장·재시작했고, 결국 모든 것을 운영하게 됨
    실제로 동작하는 서비스를 만든 팀들은 예산이 동결되고 인원까지 줄었음
  • 시작점으로는 선제적으로 한 일을 모두 추적하고 보고하는 것이 좋다고 봄. 그러면 왜 조용한지, 문제를 예상하고 시작 전에 막았기 때문이라는 걸 누군가 볼 가능성이 생김
    다른 팀에서 문제가 터졌을 때, 우리 팀은 같은 문제가 없었던 이유를 완료한 작업 목록으로 보여줄 수 있음. 작업은 이미 했고, 단지 다운타임을 피할 수 있는 더 좋은 시점에 했을 뿐임

• 이런 일은 많음. 특히 우아한 해결책은 나중에 보면 대개 단순해 보인다는 점이 마음에 듦
  한참 고민하다가 영리한 해법을 찾아 설명하면 상대는 “그래, 당연하지”라고 반응함
  옆자리에서 문제를 과하게 복잡하게 만든 사람은 오히려 그렇게 어려운 걸 만들었다고 칭찬받음

  • “평소보다 길게 쓴 것은 더 짧게 만들 시간이 없었기 때문이다”라는 Blaise Pascal의 말이 딱 맞음
  • AI 코딩이 모두의 작업을 더 큰 해결책 복잡도로 밀어붙이고 있는 느낌임. 그래서 사람들은 남의 복잡함에 감탄하기보다 방어적이 되고 더 꺼리게 되는 듯함
    대기업은 아직도 복잡함에 감탄하는 쪽으로 뒤처져 있을 수 있지만, 직접이든 간접이든 AI 산출물을 받아보는 입장에서는 복잡함이 예전만큼 인상적이지 않음
  • 반대로 더 이상 남의 컴퓨터 문제를 도와주지 않게 됨. 문제가 어려울수록 데이터 복구든 뭐든 시간이 더 걸리는데, 오래 걸릴수록 덜 감탄함
    기적 같은 구조일수록 “조카는 사소한 문제를 즉시 해결했다”는 이야기를 들려주며, 마치 내가 그러지 못했다는 점을 강조하는 것처럼 느껴짐
  • 최근 HN에서 Claude Shannon의 논문이 명확한 설명으로 가득했다는 스레드가 있었음. 어떤 사람이 문제의 우아한 해법을 고등학생도 이해할 만큼 짧고 아름답게 설명할 수도 있었고, 장황하고 복잡한 설명으로 갈 수도 있었다고 함
    책임자는 복잡한 방식을 쓰라고 조언했는데, 그래야 출판되기 때문임. 똑똑해서가 아니라 해법이 복잡하게 들려야 인정받는다는 것임
    아름다운 해법보다 복잡한 과정을 칭찬하는 현실과 정확히 맞닿아 있고, 관료주의도 아마 이런 식으로 생겼을 것 같음
  • 관리자는 자신이 얼마나 헷갈리는지로 복잡도를 인식함. 커리어 후반에 와서 보니, 깨끗하고 사용자 친화적이며 유지보수 가능한 코드를 만들려고 수많은 시간을 쓴 것이 낭비였다는 생각이 듦
    그 코드는 출시 15분 뒤 잊히고 아무도 다시 읽지 않았지만 수년간 쓰였음. 그래서 AI가 많은 사람이 생각하는 것보다 훨씬 빨리 일자리를 가져갈 수 있다고 봄
    깨끗한 코드, 관심사 분리, 유지보수성처럼 우리가 시간을 가장 많이 쓰는 것들이 실제로는 평가받지 못했음. “충분히 괜찮은” 정도면 관리자는 만족하고, 문제가 생기면 AI가 스파게티식으로라도 패치할 수 있음

• 예전 직장에서 비슷한 문제가 있었음. 회의 일정 잡기, 사람들이 회의 전에 필요한 정보를 갖추게 하기 같은 뒤에서 돌아가는 행정 업무에 거의 모든 시간을 썼음
  그런데 성과 평가 때는 내가 일을 무너지지 않게 붙잡느라 바빠서 스토리 포인트를 많이 끝내지 못했다는 점만 중요하다고 들음
  그래서 행정 업무를 모두 멈추고 스토리 포인트 완료에만 집중했더니, 1~2주 뒤 매니저가 팀에 “왜 회의가 전부 망가지고 있지? 회의에 들어가면 아무도 무슨 일인지 모른다”고 물었음

  • Radar O’Reilly가 재배치됐다면 4077th MASH가 어떻게 됐을지와 비슷함

• Y2K 대비로 거의 2년간 네트워크·하드웨어·IT 일을 엄청나게 한 뒤 마케팅으로 옮기기 시작했음. 결국 “아무 일도 안 일어났으니” 그 시간과 돈은 낭비였다고 거의 모든 회사가 여겼음
  심지어 한 회사는 전액 환불을 요구했고, 내가 한 작업을 되돌려도 된다면 환불하겠다고 하자 동의함. 다음 날 그 회사의 전체 시스템이 무너졌음
  아버지 회사의 네트워크 지원도 제 요금을 절대 내지 않겠다고 해서 맡기 힘들었음. 다른 두 사람이 문제를 못 풀고 나서 내가 15분 만에 고쳤더니, 이번엔 15분밖에 안 걸렸다는 이유로 더더욱 돈을 내기 싫어했음
  망가지지 않게 유지하는 능력은 인정받지 못하고, 망가진 뒤 고치는 것만 인정받았음. 마케팅은 보수가 더 좋았고 매일 실제 숫자로 내 급여를 정당화할 수 있었음. 좋아하는 정도는 훨씬 덜하지만, 내가 했던 어떤 IT 업무보다 존중받음

  • 가족이나 친구를 고용했다면 적어도 그 사람이 평소 받는 만큼은 지급해야 한다고 봄. 정말 친구라면 잘되길 바라야 하고, 그러려면 보통 받는 돈을 내거나 아예 괴롭히지 말고 다른 사람을 구해야 함
  • 5년쯤 전에 이 분야에 들어오기 전에는 프로그래밍과 기술이 마법 같은 세계라 개발자들을 존중했음. 들어와 보니 마법은 완전히 사라졌고, 현실에서 프로그래머들과 이야기하고 싶지 않을 만큼 견디기 힘든 사람을 많이 만났음
    인정받는 건 프린터 고치기, 컴퓨터 문제 A/B/C 고치기, 친구들을 위해 만든 광고 없는 Android Sudoku 같은 단순한 것들임
    돈을 받고 하는 핵심 업무는 인정받지 못함. 여러 업계에서 돈이 개입되면 계약상의 역할을 수행하는 것이 당연해져서 감사가 줄어드는 듯함
    기술을 모르는 사람들은 개발자가 재택근무하며 하루 30분만 일한다고 생각하고, AI는 그 이미지를 더 나쁘게 만들었음

• Ian Rush가 “스트라이커가 최고다. 다섯 번 놓쳐도 결승골을 넣으면 영웅이다. 골키퍼는 눈부시게 막다가 하나만 먹혀도 악당이 된다”고 잘 말했음
  내가 일한 모든 곳은 불이 나지 않게 만든 사람보다 소방수를 보상했음. 더 나쁜 건 인센티브를 정하는 사람들만 빼고 모두가 그 계산을 명백히 안다는 점임

  • 그렇다면 인센티브를 어떻게 설계할 수 있을까? 보이지 않는 일을 보상하기 어렵다는 게 거의 정의에 가까움
    반대편도 있음. 절대 일어나지 않는 일을 걱정하는 데 모든 시간을 쓰는 사람들도 있으므로, 단순히 방어적인 태도만 보상하면 되는 문제는 아님

• 직장에서 승진이 이런 식으로 이뤄짐. 뭔가를 망가뜨리고, 에스컬레이션되어 눈에 띄고, 임원에게 이메일이 감. 그런 다음 그걸 “고치면” 모두가 잘했다고 감사함
  또 다른 버전은 원래 해야 할 일을 오래 지연시켜 가시성을 키우는 것임. 임원은 문제로 커지기 전에 책임지고 끝내는 사람들의 일을 보지 못함
  대신 뭔가를 망가뜨리고 하루를 “구한” 사람의 이름은 기억함

  • 소시오패스식 뒷치기도 있음. 누군가가 망가뜨리고, 당신 탓으로 돌리고, 이름을 더럽히며 문제를 키운 뒤 “고치러” 가서는 무능해서 더 악화시킴
    그러면서 임원에게 아부하고 “doublerabbit에게 맡기지 않는 게 낫다”, “팀 플레이어가 아닌 것 같다”고 함. 전부 내 인프라였는데도 그럼
    사람들이 왜 내가 인간을 싫어하냐고 묻는 이유가 이것임

• 초등학교 1학년 때 이미 배운 일임. 수업 시간에 얌전히 있고 숙제를 하는 아이들은 선생님의 시간과 노력을 많이 차지하지 않음
  규칙을 따르지 않고, 공부에 조금이라도 노력할 때마다 계속 칭찬이 필요한 문제아들이 선생님의 관심을 가져감

  • 늘 듣던 표현으로는 “삐걱거리는 바퀴가 기름을 얻는다”임

• IT에서 보낸 시간은 두 극단 사이를 오갔음
  “주변이 다 잘 돌아가네. 우리가 IT에 왜 돈을 내지?”
  “전부 망가졌네. 우리가 IT에 왜 돈을 내지?”
  개인적으로는 후자보다 전자를 지향함. “내가 일을 제대로 하면, 내가 여기 있는지도 모른다”고 말하곤 함. 하지만 그 점 때문에 해고됐음
  카르마 차원에서 예전 회사 사람들과 계속 연락하는데, 지금은 완전한 난장판임. 그건 그나마 위안이 됨

• 역량 함정을 알게 되면 어디서나 보임
  Sterman, Repenning과 다른 협업자들이 이 논문 뒤로 여러 편을 더 썼고, 모두 흥미롭지만 거의 전부 우울함
  특히 시스템 동역학이 처음 학문으로 자리 잡은 MIT Sloan이, 시스템 동역학이 처음 무시당한 Harvard Business School 바로 근처라는 점이 더 그렇음

  • 역량 함정 개념에서 이해가 안 되는 부분은, 한 가지를 잘하는 회사가 왜 새로운 것도 잘할 것으로 기대되는가임. 정확히 무엇이 함정을 함정으로 만드는지 궁금함