매일 운영환경 엣지 케이스를 수정하던 스태프 엔지니어 해고
매일 프로덕션을 터뜨리는 엣지 케이스라고?
내가 이해하려는 게 이거임. 매일 별도 스크립트를 돌려서 그 엣지 케이스를 수동으로 운영에 넣었거나, 아니면 매일 완전히 새로운 엣지 케이스가 생긴 거임. 둘 다 그 사람을 좋게 보이게 하진 않음.
맨날 나만 초치는 사람 되는 거 같긴 한데, 솔직히 이 썰은 말이 안 됨. 소문이 돌고 돌면서 완전 와전됐거나, 주니어가 혼자 단단히 착각했거나, 그 엔지니어가 짤려도 할 말 없을 정도로 심각하게 무능했거나, 아니면 그냥 아예 100% 지어낸 주작일 거임. 진짜 어이없음.
나한텐 충분히 가능해 보임.
우리 결제 서비스 일부는 OCR로 pdf 인보이스를 파싱함. 벤더가 수만 곳이고, 전부 자기들 템플릿을 쓰며, 하루에 인보이스를 수천 건 받음. 대부분은 잘 처리되지만, 제대로 읽히지 않아서 에러를 던지는 게 하루에 몇십 건쯤 있을 수 있음. 또 통과는 됐는데 인보이스 금액이 잘못된 줄에서 뽑히는 경우도 십여 건 있음(subtotal vs total amount vs amount due 등), 그러면 나중에 에러가 생김.그래도 대부분 이렇게 잘 작동한다는 게 아직도 살짝 미래적이라고 느낌. 엄마가 사무원으로 일하면서 내가 컴퓨터 쓰는 법 알려주기 전까지 작은 사업장 인보이스를 전부 책에 손으로 적던 거 기억남.
기술이 너무 빨리 발전했음.amazon, netflix, google에서 20+년 일한 소프트웨어 개발자임.
이런 사람들하고 일해본 적 있음. 시스템을 조금 더 신중하게 설계하는 대신 새벽 3AM에 일어나서 문제 고치는 걸 영웅처럼 여기는 사람들. 그리고 관리는 그들에게 두 번 보상함. 한 번은 "빠른" 설계를 했다고, 또 한 번은 자기 멍청한 선택을 한밤중에 고치는 영웅 온콜이라고.
내가 좋아하는 응징 순간 중 하나는 이 엔지니어의 끔찍한 설계 결정과 반복노동 제거에 시간을 쓰길 거부한 탓에 Jeff Bezos가 추수감사절 연휴에 호출받았을 때였음. 그게 진짜로 그 사람과 우리 매니저(그리고 디렉터, VP...)에게 신의 공포를 심어줬고, 덕분에 실제로 복원력 작업에 시간을 쓰기 시작할 수 있었음.요즘 이 표현을 많이 쓰는 것 같은데, 내가 들은 용어는 "방화범의 소방(firefighting by arsonists)"임. 기업이 보상할 때 아주 조심해야 하는 것임. 다른 예로는 버그 수정 개수를 공로 지표로 삼는 것(자기가 만든 버그까지 포함한다면)이나 코드 라인 수(직전 변경사항을 다시 고쳐 쓴 것도 포함)가 있음.
내 초기 직장 중 하나에서는 여름 노동자용 임시 계정 여러 개(30개쯤)를 만드는 일이 있었음. 내가 프로세스를 시작했고, 워크플로상 이슈가 여러 부서를 거쳐 가기 때문에 마지막 단계(티켓 닫기 포함)도 해야 했음. 30개 계정이 전부 티켓 1개에 들어갔고, 복잡한 일은 아니었음.
내가 시스템 쪽으로 승진해 옮겨갔는데, 내 후임이 '대단하다'는 말을 듣고 놀랐음. 내가 그와 상호작용한 느낌은 그냥 중간 정도였기 때문임. 다음 해에 이유를 알게 됨. 같은 작업에 대해 그는... 티켓을 30개 만들었음. 계정당 하나씩. 이건 다른 모든 부서(이제 내 역할 포함)에 훨씬 더 많은 일을 만들었지만, 그들은 그달에 보너스 티켓 30개를 닫고 아주 '생산적'으로 보일 수 있었음.
(그 조직의 한 가지 장점이자, 내가 전반적으로 그곳에서 일하는 걸 즐겼던 이유: 내가 그 문제를 제기하자, 그들은 매니저 대시보드에 티켓 유형을 더 투명하게 볼 수 있게 구분을 추가했고, 전반적으로 관리진이 정상 범위에서 벗어난 것과 이상치를 살피는 데 더 신경 쓰기 시작했다고 느낌.)
우리 모두 알다시피, 어떤 측정치가 목표가 되는 순간 좋은 측정치가 아니게 됨.이건 관리 문제처럼 들림.
나도 이런 사람이었던 적 있음. 나도 나중에 제대로 처리하는 방법에 대해 상세 티켓을 만들었지만, 그런 것들은 항상 즉시 우선순위에서 밀려서 (절대 도달하지 못할) 백로그로 옮겨졌음. 더 이상 지금 당장의 이슈가 아니고 고객 이슈가 우선이기 때문임.
처음부터 제대로 설계하는 것도 제안했음. 하지만 결국 모든 게 "최소 기능 제품을 제공하는 게 더 큰 가치를 준다"는 이유로 뼈대만 남게 깎였음.
결국 그냥 더 이상 신경 안 쓰게 되고 근무시간만 채우게 됨. 나는 올바르고 견고한 해결책을 제안하고 한 번(어쩌면 두 번) 주장하겠지만, 그 뒤엔 그들이 그걸 안 받아들여도 더 이상 신경 안 씀.
그리고 누가 이슈를 나한테까지 원인 분석하려고 하면, 난 뒷받침할 문서가 있음.
매일 프로덕션에서 모든 걸 터뜨리는 결함을 본 어떤 머리 텅 빈 엔지니어가 대체 무슨 생각으로 이렇게 결정했는지 이해하려는 중임:
단 한 사람에게도 말하지 않음
제대로 된 영구 수정 코딩 없이 몇 년 동안 매일 수동으로 고침기업 프로그래밍에서 거의 20년 일한 사람으로서 내 추측은, 그는 들어줄 사람 누구에게나 말했지만, 매일 고칠 수 있다는 이유로 별거 아닌 일로 치부됐을 거라는 거임. 충분히 자주 충분히 많은 사람에게 말했는데도 계속 안 듣는다면, 결국 말하는 걸 멈추고 조용히 자기 일을 해서 ㅈ되지 않게 만드는 경우가 많음.
매일 다른 엣지 케이스가 생기는 문제에 관해서라면, 예를 들어 금융 데이터는 ㅆㅂ 지뢰밭임. 별별 멍청한 CPA가 날마다 조금씩 다르게 처리하고, 돈만 계속 움직이면 책임지는 사람도 없음.은행에서 일한 적 있는데, 내가 맡았던 것 중 하나가 몇몇 자동화 보고서였음. "자동화"였던 이유는 이상한 엣지 케이스 때문에 가끔 깨졌기 때문임("이 유형의 거래는 4년에 한 번만 이 보고서에 나타남" 같은 것들과 비슷한 것들).
이건 월간 보고서였지만, 매달 초 며칠 안에 정부에 제출해야 했기 때문에 코드를 만지기도 전에 반드시 고쳐져 있어야 했음. 하지만 많은 경우 그들은 내가 코드 만지는 것조차 허락하지 않았음, "우선순위가 아님"이라면서.
어느 시점에 나는 상사에게 프로덕션에서 정보를 가져오는 데 여전히 시간이 너무 많이 든다고 말했음. 승인과 처리 시간을 따라야 하는 파이프라인이 있었기 때문임. 그리고 새 정보를 프로덕션에 넣는 데도 비슷한 파이프라인이 있었음. 때로는 수정 자체는 45분 걸리는데 승인을 기다리느라 보고서 업데이트에 3일이 걸렸음.
내 상사는 매니저와 디렉터에게 이야기함. 그들의 해결책은 나에게 프로덕션 읽기 전용 접근권을 주고, 보고서 업데이트용으로만 빠른 승인 파이프라인을 만들어주는 것이었음.
나는 그 버그들을 하나도 고친 적 없지만, 적어도 내 상사들은 알고 있었던 것 같음 lol나도 이런 일이 일어나는 걸 본 적 있고, 그것도 금융 회사였음. 왜인지는 모르겠지만, 이런 곳들은 내가 상대해야 했던 최악의 매니저들을 키워내는 듯함.
아마 가짜일 듯.
때로는 더 나은 프로세스를 코딩하는 데 시간을 쓰는 것보다 수동 수정이 더 간단함. 여유 시간이 생길 때까지 놔두면 된다고 생각하지만, 그 여유 시간은 절대 오지 않고, 갑자기 수동 수정을 몇 년째 하고 있는데 바꾸기엔 너무 귀찮아져 있음.
아니면 매 계획 주기마다 제기하지만, 제대로 고칠 시간을 아무도 배정해주지 않고, 이제 그걸 "아는" 유일한 사람들은 얼마나 망가졌는지 이해 못 하는 비기술 매니저들뿐인 경우임.
경험담은 절대 아님.
staff engineer의 양면성:
자기가 얼마나 잘하는지 자랑하고 모든 일을 혼자 하면서 모두를 짜증나게 함
OR
팀을 싫어하고 아무도 모르게 모든 일을 혼자 함
중간은 없음개인적으로 난 매일 아침 동전을 던져서 어느 쪽이 될지 정함.
동전이 옆으로 서면 쉬는 날로 침?
아님, 그때는 이력서를 새로 고치고 새 포지션에 지원하기 시작함. 실제로 떠나진 않겠지만, 잠깐이라도 그런 척하는 게 좋음.
그래 나 그런 사람 하나 알았음, 4년 동안 매달 떠난다 했음. 그 뒤로도 8년 더 거기서 일하고 있음🥹
너임? 네가 그 사람임?
그 사람이 아니면 나임.
윽, 이건 너무 내 얘기라 아픔.
젠장, 이건 가슴에 정통으로 맞음.
그러다 하나가 갑자기 일은 절반인데 연봉은 두 배를 제안하면 실제로 선택해야 함.
나는 후자지만, 전자가 되지 않으면 principal로 승진할 가능성이 전혀 없다는 걸 알게 됨.
자기 칭찬을 스스로 하지 않으면 아무도 대신 해주지 않음.former와 latter를 헷갈린 것 같음.
아마 그래서 승진 못 했나 봄.
아마 강등을 요청해놓고 왜 돈이 계속 줄어드는지 궁금해했을 듯.
요령은 모든 일을 하면서 다른 개발자들에게 도움이 되는 사람이 돼서, 다른 개발자들이 프로젝트 매니저에게 대신 자랑해주게 만드는 것임.
이거임. 나는 나 자신을 거의 전도하지 않음. 팀 나머지가 대신 해주기 때문임. 내 시간의 상당 부분을 jrs에게 일하는 법을 가르치거나, 수동 프로세스를 없애는 자동화를 만드는 데 씀. 그리고 그걸 다시 팀에 넘김. 이렇게 해서 나는 어린 엔지니어들에게 화나거나 짜증나는 걸 피하고, 대신 그들을 내 정신 건강에 대한 투자로 대함.
더 많이 가르칠수록 내가 해야 할 일이 줄어듦. 맞음, ㅈ됐을 때는 여전히 내가 전면에 나서지만, 그건 내가 principal이기 때문임. 당연히 앞에 설 거고, 그래야 낮은 티어 사람들에게 역풍이 안 감. 내가 파고드는 동안, jrs에게 무엇을 봐야 하는지도 가르치고 보여줌. 맞음, 시간이 조금 더 걸리지만 2-3분 정도 차이일 뿐이고, 나는 일하면서 말할 수 있음.
며칠 전 내 jrs 중 한 명이 우리 프로덕션 앱 하나의 로그를 뒤지다가 발견한 것에 대해 질문하러 왔을 때 정말 자랑스러웠음.
staff engineer들에게 말함. 너희 jrs는 너희 지원 인력임. 배제하지 마셈. 같은 걸 여러 번 설명하는 게 짜증나는 건 맞지만, 그들이 네 편이면 너한테 더 좋음.
나는 질문에 답을 안 하는 방식으로 답하는 staff engineer들을 겪었음. 한 명은 내가 실제로 물은, 우리 환경에 극도로 특화된 질문에 답하는 대신 일반 문서를 던져주고 알아서 하라고 했음. 그사람 ㅈㄴ 번아웃된 상태임.
나도 예전엔 화난 staff engineer였음. 너무 심하게 번아웃돼서 테이블쏘에 손을 넣었음. (0/10 비추천) 업무량 관리하는 법을 배우셈.
내 말은, 많은 사람들이 자기 일에 대한 공로를 못 받고 ㅈ같이 해고됨. 그건 별로임.
하지만 3년 동안 퇴근 후에 매일 뭔가를 수동으로 고치고 있다면, 그건 staff engineer의 행동이 아님. staff engineer라면 이 이슈를 알리고, 자신과 팀을 이 상황에서 빼내는 계획을 세워야 함. 내가 같이 일하는 staff engineer가 그런 핵심 서비스에서 3년 동안 이걸 아무에게도 말하지 않고 하고 있었다는 걸 알게 된다면, 감탄하는 게 아니라 소름 끼치고 그 사람의 역량과 staff engineer 자격을 심각하게 의심할 것임.
문제를 숨기고 반복적인 수동 수정을 하는 건 우리가 주니어들에게 인내심 있게 고쳐줘야 하는 행동임.
이 게시물은 그 사람을 해고한 게 잘못이었다고 내가 느끼도록 짜인 것 같지만, 이건 엔지니어 쪽의 재앙적 수준의 무능임.반전: 그 staff engineer가 시스템을 고칠 리소스와 권한을 달라고 애원한 문서 기록이 1마일은 있는데, 리소스를 안 주는 걸 넘어 "작동은 하고 있고, 건드리고 싶지 않다"며 고치는 것까지 금지한 상황임.
때로는 고칠 비용을 들일 가치가 있다는 걸 설득하려면 먼저 뭔가 깨지게 놔둬야 함.
오늘 나한테 그 일이 일어남. 이제 듣고 있음!
회사마다 다름. 나는 미래를 여러 번 예언했지만, 어떤 매니저들은 도메인을 모를 때조차 고집 센 ㅈ같은 인간으로 태어난 듯함.
"난 불 끄느라 너무 바빠서 그저 연기만 나는 네 쓰레기 더미 따위에 신경 쓸 시간이 없음!"
그리고 네가 경고해왔던 일이 결국 일어나면 "엔지니어라면 그걸 피할 수 있어야 했다"며 너를 탓함.
그래서 경고는 최소한 서면으로 남겨야 함.
금요일에 깨지게 놔두는 건 주말을 망치는 좋은 방법 같음.
내가 사람들에게 경고한 뒤에도 ㅈ되게 놔두지 않는 유일한 경우는 보안 관련 문제임. 그 외에는 회사가 거절한 6K 엔지니어링 리소스로 막을 수 있었던 장애에 수만 달러를 날리게 둬도 완전히 괜찮음.
나는 이 방식에 크게 의존함.
플래그함.
다시 플래그함.
산산조각 나게 둠.
내가 말했잖아 단계(회의에 불려가고 모두가 이 일이 어떻게 일어날 수 있냐며 경악하는 단계)
예산 받음. 고침.
새 부서에서 반복함.나도 이런 상황을 본 적 있음. FTP로 여러 스프레드시트를 모아서 데이터 웨어하우스로 가져오는 대규모 데이터 import였음. 데이터는 끔찍했지만, 우리 product owner는 개발자들이 새 기능을 작업하길 원해서 매일 직접 정리하기로 했음.
그냥 우리가 고치게 해달라고 설득하려 했지만, nope.PO를 바쁘게 해두는 거면 좋은 거 아님?
그들은 딱히 하는 일이 많지 않음(금융/보험 쪽 몇 군데에서 PO를 해본 사람으로서 하는 말임...), 그러니 뭔가를 하면 마이크로매니징을 덜 할 핑계가 생김.아마 실제로 일어난 일일 듯.
나는 여러 조직에서 이런 일이 너무 많이 일어나는 걸 봤음.
보통 사람들에게 깨지게 두고 문서 기록을 가리키라고 조언함.아님. 그러면 그냥 고치는 걸 멈추면 되고, 아주 빠르게 우선순위가 다시 잡힐 거임. 또한 staff engineer는 작업 우선순위를 정할 권한과 기대가 있음.
실제로 나는 내 팀 엔지니어들에게 리더십에 고칠 리소스가 필요하다는 걸 보여주기 위해 제발 깨지게 놔두라고 애원한 적 있음.
우리가 임시방편을 넣어 계속 작동하게 만들 때마다, 그들은 문제가 존재한다는 걸 즉시 잊음. 하지만 깨지고 고객지원 콜이 폭증하면, 우리는 빠른 수정(임시방편 재구현)으로 영웅이 되고, 많은 사람들이 "이거 언제 고쳐짐"이라는 질문을 하기 시작함.나도 매우 비슷한 상황임. 몇몇 핵심 고객을 위한 임시 해결책을 만들라고 호출받았고, 그다음 실제 Product 그룹이 공식 기능을 작업해서 배포하기로 했음. 그 임시방편을 유지한 지 2년이 됐고, 지난주에 그 이야기를 꺼냈더니 자기들이 이 기능을 작업해야 하는 줄 전혀 몰랐다고 함... Memorial Day 주말에 깨졌음. 내가 문자 그대로 10분 전까지 이번 주 내내 뭘 하고 있었을지 맞혀보셈.
문제는 그게 작동하지 않는다는 거고, 이 경우에는 실패하게 둬서 다른 사람들이 알아차리고 영구 수정 리소스를 찾게 하는 게 더 나음.
공평하게 말하면, 나도 이런 비슷한 이슈를 관리진에게 제기했는데 들은 척도 안 한 상황에 있어본 적 있음. 그러니 무능은 엔지니어 쪽이 아닐 수도 있음.
내가 해본 모든 직장과 비슷하다면, 그들은 분명 크게 플래그했고 "음, 그래 알겠어"만 받고 끝났을 것임.
내 일도 딱 그랬음.
행사 관련으로 대기 중인 문제가 있었음.
6주 동안 그것에 대해 경고했고, "이렇게 하면 고쳐짐" 계획도 있었음. 그런데 계속 무시당함. 몇몇 PoS 유닛이 관련된 문제였음.
그리고 어떻게 됐을까? 행사에서 모든 게 ㅈ됨.
그날 끝날 즈음에는 돈이 비즈니스 계좌가 아니라 개인 계좌로 들어가고 있어서 재무 컴플라이언스 사람들이 개입했음.
내 모든 이메일과 기록을 저장해두고 바로 넘길 준비를 해둔 건 아주 좋은 일이었음. 나는 뒤로 물러나 튄 물에 휘말리는 걸 피할 수 있었음... 물론 내 상사와 그 상사의 상사는 여전히 모든 게 잘못된 걸 내 탓으로 돌렸고, "휴가 중인데도(차로 5시간 떨어진 곳에서) 즉시 고치러 오지 않은 팀 플레이어가 아니다"라고 했음.응, 그들이 플래그했는데 무시됐거나, 아니면 그들이 쌓아두고 있었던 둘 중 하나일 거임. 하지만 솔직히 작은 회사에서는 많은 사람들이 회사를 굴러가게 하려고 많은 일을 함.
그 회사가 실제로 어떤지(진짜라면) 모르면 말하기 매우 어려움.
사람이 일을 잘하고도 이후에 해고되는 이야기들(예: 자기 일을 자동화할 방법을 찾음)을 내가 접한 걸 보면, 인센티브는 분명 잘못된 일을 하게 만듦.
누군가가 어떤 수동 개입 단계를 남겨둬서 네가 그 사람에게 의존하게 만들며 자기 일을 보존하는 게 "옳다"고 말하는 건 아님. 하지만 이런 행동을 고친 보상이 종종 사람을 내보내는 것이라면, 그 사람이 비즈니스를 위해 옳은 일을 하길 주저하는 건 이해할 수 있음.어떤 경우에는 확실히 맞지만, 아무도 몰라서 수동 수정에 대한 공로를 받지 못하고 있었다면, 그건 일자리 보존의 문제가 아니었음.
고쳐질 때까지 좋은 보너스 받고 다시 고용되어야 한다면 그게 맞음. 백로그에 이슈를 문서화했고 그들이 낮은 우선순위로 둔 항목을 가리킬 수 있으면 보너스 점수임.
내 현재 직장에서도 모든 환경 간 사용자 분산을 유지하지 못하면 지연시간이 문제를 일으키는 이슈가 있었음. 매 PI마다 그 이슈를 해결하는 스토리는 다른 작업이 더 가치가 높다는 이유로 다음으로 밀림(하지만 이 자동화는 지금 필요하다고 그들은 말함).
공평하게 말하면, 플래그됐지만 회사가 여전히 작동하고 있다는 이유로 신경 안 썼을 가능성도 있음.
이건 관리진이 고칠 시간을 줄 거라는 전제를 깔고 있음. 나는 최근 다른 sub에서, 엔지니어가 이런 종류의 엣지 케이스를 고치느라 계속 "시간을 낭비한다"고 불평하는 매니저 댓글에 답글을 단 적 있음. 현재 구현은 그들 말로는 현재 규모에선 충분하다고 함.
때로는 legacy systems, 통제할 수 없는 third parties 등 때문에 수정이 문자 그대로 불가능함.
staff engineer가 6개월 동안 계속 제기하다가 그냥 포기하고 수동 수정만 하는 시나리오도 상상할 수 있음.아니면 전체 이야기가 조작임.
여기서 교훈은 "회사는 사람을 해고하면 안 된다"가 아니라, "네가 중요한 일을 하는데 아무도 모른다면, 스스로를 망치고 있는 것"임.
겸손 따위 ㅈ까. 시끄럽게 말하고, 자부심을 갖고, 너 자신과 주변 사람들을 띄워라. 사람들이 네가 뭘 하고 왜 중요한지 알게 하셈.여기서 교훈은 또한 "매일 발생하는 mission-critical 결제 데이터 무결성 버그를 3년 동안 고치지 않은 채 두지 말라"임.
그런 ㅈ같은 건 해고 사유여야 할지도 모름!사람들은 이걸 보고 헌신적인 직원이라고 생각함.
나는 이걸 보고 "저 사람 dead man’s switch 만들었네"라고 생각함.나도 같은 생각 했음. 네가 그걸 만든 건 아니고, 단지 수년 동안 고치길 거부하고 그 대신 그것이 일으킨 개별 피해를 반복적으로 땜질했다면, 사보타주는 아닌가? 아마도! 누군가에게 어느 시점에 한 번이라도 언급했다는 문서 기록이 있다면(영향/빈도가 축소되어 있었더라도), 이건 영리한 윤리적 우회라고 부르겠음. 네 손은 수동적으로나마 대체로 깨끗하게 유지되고, 그래도 네가 해고됐을 때 누군가는 후회하게 보장함.
비프로그래머로서 매주 몇몇 엣지 케이스를 고치는 사람인데, 그건 번아웃일 가능성이 있음. 한동안 매주 언급하지만 실패하진 않으니 항상 낮은 우선순위로 밀림. 시간이 지나면 항상 들은 척도 안 하니까 언급을 멈추고, 매주 월요일이나 뭐 그런 때 돌리기 쉬운 프로세스가 됨. 필요성과 절차를 문서화했을 수도 있지만, 네가 해고되고 아무도 정책 및 절차 매뉴얼을 정기적으로 검토하거나 업데이트하지 않는다면 그건 네 잘못이 아님. 물론 완전히 내 경험을 투사하는 중임.
회사 쪽으로 다시 돌리자면, 회사도 정기적으로 에러 리포팅이나 실패한 결제를 처리하는 사람을 두어야 함. 내 경우에는 주 단위로 엣지 케이스를 보는 게 정말 쉬웠음.나도 거기에 있어봤음. 제대로 된 수정은 우선순위에서 밀리고, 결국 프로덕션에서 흘린 걸 닦는 디지털 청소부가 됨. 그런 일은 생김.
다만 나 말고는 아무도 모르는 항목들도 기억남. 내 말은, 티켓은 있었지만 아무도 그 모든 걸 읽진 않음. 내가 그 시기에 갑자기 떠났다면 영향은 실질적이었을 것임. 그래서 "대체불가" 미터기는 자주 튀고, 관리진은 그 위치를 모르는 경우가 많음. 그러면 이런 걸 장기적으로 못 본 척하는 윤리는 뭐임? 그 결정에 직업 안정성을 입력값으로 넣고 있다면 중요함? 확실히 전문적인 행동은 아님. 하지만 현실적으로는 완전히 빠져나갈 수 있음. 그리고 그들에게 나쁘게 대우받았다면, 예전엔 스스로를 프로라고 생각했더라도 쉽게 정당화할 수 있음. 조직은 자기들이 소프트웨어 사람들에게 얼마나 의존하는지 엄청 과소평가함. (Initech의 Michael Bolton이 그건 맞았음)근데 왜? 문제가 있다는 걸 깨닫고 그에게 돌아와 달라고 빌 것도 아니고, 그냥 '야 EM #3, 네 팀이 고쳐야 할 새 긴급 우선순위야, 단 어떤 출시도 지연되지 않게 해'라고 할 뿐임.
나는 관리진이 이런 쓰레기를 고치길 거부하는 걸 본 적 있음. 고칠 사람을 배정하면 단기적으로 시간과 노동 비용이 더 들기 때문임. 장기적으로 엔지니어링 노동을 절약하더라도. 많은 곳에서 흔한, 푼돈 아끼다 큰돈 날리는 태도임.
"네가 중요한 일을 하는데 아무도 모른다면, 스스로를 망치고 있는 것"
? 회사가 그 사람들의 회사에 대한 근본적 중요성을 제대로 이해하지 못하고 해고해서 스스로를 망친 것처럼 들림.
왜 자동화 안 했음?
돈과 관련된 일이기 때문임.
엣지 케이스를 설명할 수 없다면 매출 손실을 감수하고 싶지 않은 거임.
할 수 있었다면 자동화했을 거라고 확신하지만, 그냥 일관성 없는 이슈일 수도 있음.
내 친구 한 명은 PHP add_slashes()가 시스템에 POST 데이터를 넣는 걸 관리해야 하는 곳에서 일했음. 어느 날 무작위로 그 서버가 POST에 슬래시를 추가하지 않기 시작했고... 또 어느 날 다시 추가하기 시작했고... 또 사라졌음...
알고 보니 PHP 설정이 다른 PHP 서버 두 개를 띄웠던 거였음(또는 한 버전이 버그를 고쳤거나). 오래된 서버는 여전히 슬래시를 보내고 새 서버는 안 보냈음... 그런데 같은 IP(노 API key)와 vendor-ID 쿼리 문자열에서 온 거였음!매일 밤 발생하는 엣지 케이스는 엣지 케이스가 아님, 버그라고 부름.
엣지 케이스를 설명할 수 없다면 매출 손실을 감수하고 싶지 않은 거임.
내 말은, 아니면 그냥 시도조차 안 했을 수도 있음. 우리도 여기 그런 사람이 있었는데, 많은 걸 수동으로 했고 직접 "이거 하려면 코드를 작성해야 한다"고 지시받지 않는 한 뭔가를 자동화하려고 하지 않았음. 100% 할 수 있는 사람이었는데, 그냥 그런 식으로 생각을 안 했음.
우리는 한 달에 한 번 scrubbed prod data로 testing environment를 새로고침함. 내가 맡기 전에는 그 사람이 매달 손으로 했음. 그때 데이터베이스가 25개쯤이었음. 각각 손으로 백업하고, 복사하고, 복원했음. 매달 꼬박 2일 걸렸음.
나는 그에게 powershell로 하는 방법을 알아내서 자동화하라고 말했음. 이제는 그냥 알아서 실행됨.
그러려면 pr을 만들어야 하고, 그러면 그동안 수동으로 고치고 있었다는 게 드러남.
나쁜 엔지니어링처럼 들림.
3년 동안 밤마다 고친 건 엣지 케이스가 아님
3년 내내 매일 밤 일하면서 버그를 고쳤지만, 실제로 해결하거나 심지어 보고하지도 않았다고?
그 사람은 TBH 해고당할 만했음.
적어도 회사는 이제야 알게 된 버그를 고칠 수 있음.이야기가 완전히 지어낸 게 아니라고 해보자. 그러면 이 사람은 단순히 버그를 고친 게 아니라 결제 데이터를 수동으로 조정한 거임. 그건 쉽게 해고를 넘어 "자, 이제 법무팀의 친절한 분들께 네가 뭘 '조정'했는지 설명해보셈"으로 갈 수 있음.
동의함. 내가 dev가 결제 데이터를 수동으로 조정하는 걸 보면, 그 결제들을 어딘가의 익명 은행 계좌로 흘려보내는 영리한 계획을 세웠다고 가정할 것임...
동의함. 이건 미친 짓임.
이게 staff eng에게 공감을 만들거나 그들을 필수 인력으로 포지셔닝하려는 거라면... 안 먹힘.
sr 역할에서 설명된 업무 접근 방식은 용납 불가임.맞음. 이 사람은 1) dead man’s switch를 만들었거나, 2) 진짜로 일을 못했거나 둘 중 하나임. 어느 쪽이든 나도 아마 해고했을 듯.
특히 결제 정보를 수동으로 조정하고 있었으니, "일 못함"에서 "법무팀의 친절한 분들과 대화해보자"로 넘어감.
으, 똑같은 쓰레기 짓을 하면서 매일 칭찬을 원하던 ㅈ같은 엔지니어들과 일해본 적 있음. 유능한 사람들이 그들 근처에 앉기 전까지는 영웅처럼 보였음. 3일 각각 발생했다면 다음 발생을 위해 코딩하셈. 내가 그 회사에 들어갔을 때는 항상 같은 티켓 5개가 반복됐음. 아무도 워크플로 이슈의 근본 원인과 해결책을 트러블슈팅할 배짱이 없었기 때문임. 그냥 하루에 엣지 케이스 3개 고치고 생산적인 척함.
예전 직장에서 나는 코더이자 분석가였는데, 10년 동안 마케팅과 영업 비즈니스 분석이 필요해져서 고객 3곳을 위해 그걸 했음. 한 곳은 연간 및 월간으로 함.
갑자기 "성과 미달"로 해고됨.
ㅈ같다고 느꼈지만 뭐 어쩌겠음. 난 괜찮게 하고 있다고 생각했음.
3주 후 전화가 옴:"영업 및 마케팅 보고서를 만드는 데 어떤 소프트웨어를 썼나요?"
"Word와 PowerPoint"
"그런데 데이터는 어디서 얻었나요?"
"제가 데이터를 집계하고, 정제하고, 사람이 읽을 수 있게 옮겼습니다."
"여기서 누가 그걸 할 수 있나요?"
"아무도요, 저를 해고하셨잖아요."
"알겠습니다." (긴 침묵) "감사합니다, 행운을 빕니다."
그 뒤로 연락 없음. 한 고객이 직접 연락해서 "지식 이전"을 요청했지만, 보상은 없었음.
그래서 그들에게 모든 일이 잘 풀리길 바람. 진심임. 하지만 지난 11개월 동안 통계에 대해 깜깜했을 수도 있음.
알겠는데, 이건 그가 나쁜 엔지니어였다는 뜻임. 그는 엣지 케이스에 문제가 있다는 걸 알았고, 그걸 아무에게도 알리지도 않고 더 영구적인 수정을 밀어붙이지도 않았음. 장기적으로는 그들이 더 나아질 것 같음.
"아니, 그 시스템은 바꿀 수 없어. 늘 그렇게 해왔고 지금 망가뜨릴 위험을 감수하고 싶지 않아. 가끔 생기는 문제만 처리하고 넘어가. 아니, 추가 시간이나 리소스는 없어."
"아무도 몰랐다"잖아.
많은 사람들이 문명 대부분이 노끈과 껌으로 버티고 있다는 걸 모름. 이게 AI가 마법처럼 모든 걸 자동화할 거라는, 현실감 없는 CEO들의 환상을 볼 때 내가 웃는 이유임. 모든 데이터베이스가 100% 일관적이거나, 회사에서 일어나는 모든 일이 100% 문서화된 프로세스에 따라 이뤄진다고 생각할 때만 가능해 보이는 일임(그리고 그 문서 자체도 정확하다고 생각해야 함!) 그리고 알아? 난 이런 게 좋음. 아니면 우리는 그냥 다 기계일 뿐 아닌가?
아, 누군가는 분명 알았을 거임. 그는 아마 3개월 뒤 언급을 그만두고 회사에 충실하게 고치며 지냈을 뿐임.
친절한 알림: 네 일은 아무 의미 없고, 의무보다 단 1초도 더 일하면 안 됨.
그래서 그는 staff engineer였고, '엣지 케이스 데이터 손상'에 대한 해결책이 근본 원인을 해결할 방법을 찾는 게 아니라 계속해서 수동으로 고치는 거였음?
나도 비슷한 일을 겪었음. 지난 직장에서 보고서와 자동화 작업을 많이 작성했고, 이런 것들에 내 업무 이메일이나 계정을 쓰면 절대 안 되며, 내가 퇴사하거나 해고될 경우를 대비해 별도 계정과 그 계정 자격 증명을 가진 백업 인원이 필요하다고 계속 말했음.
그들은 계속 새 seat나 구독 비용을 감당할 수 없다느니 어쩌고저쩌고 하며 거절했음. 그런데 그 ㅆㅂ놈들이 결국 나를 해고했고, 약 2주 동안 내 계정을 정지하고 접근권을 취소하자 깨진 모든 걸 고치려고 허둥댔음. 나는 이런 요청만으로도 십여 개 넘는 티켓을 열어뒀고, 무엇이 깨지고 어떻게 고쳐야 하는지 알려주는 notion 문서에 링크해뒀음. 그런데 notion도 취소돼서 그건 죽은 링크가 됨.
이건 c-suite가 비즈니스가 어떻게 돌아가는지 매일 확인하고 그 데이터를 바탕으로 매일 의사결정하는 데 쓰던 보고서들이었음.이건 ㅈ같은 프로처럼 보임. 3년 동안 매일 발생한 건 엣지 케이스가 아니라 다른 곳의 진짜 문제임. 그 몇 년 동안 팀에 이슈를 제기하지 않았고, 혼자 해결하려고도 안 했다면 네가 문제임.
좋네, 자기 자신을 자동화해서 일자리에서 밀려나지 않은 걸 축하함.
우리는 이제 고용주들이 사람을 해고하는 걸 두려워해야 하는 지점에 와 있음. 우리가 뒤에서 실제로 뭘 하는지 전혀 모르기 때문임. 계속 그렇게 유지해야 함.요점은 이해하고 반대하지도 않지만, 감사인으로서 내가 집중할 수 있었던 건 dev가 매일 밤 프로덕션 금융 데이터를 바꾸고 있었고 아무도 몰랐다는 것뿐이었음. 🤦🏻♀️
전 아직 이런 엔지니어를 못 만나봤어요. 혹시 난가?!
