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

[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 바로 근처라는 점이 더 그렇음

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