회사를 떠나는 사람 파악하기: 'dump', 'diff', 'repeat' 방법론

 (rachelbythebay.com)
1P by GN⁺ | ★ favorite | 댓글 1개

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • epitaphs를 만든 사람임. 무엇이든 물어보세요

    • 블로그 글에는 “당신을 아는 다른 사람이 추가해야 했다”고 되어 있지만, 정확하지 않거나 이제는 그렇지 않음
      직원이 특수 주소로 내용을 이메일로 보내면, 회사를 떠날 때 그 내용이 표시될 수 있음. 내가 그렇게 했지만, 제대로 동작했는지는 다시 확인할 수 없음
    • 혹시 어느 회사였는지 물어봐도 될까요?
    • 아직도 운영 중인가요?
      HR이 바꾸라고 한 적이 있었나요? 5년 전에 퇴사했는데, 그 기능 정말 좋아했음
    • 왜 epitaphs를 만들었나요? 만들면서 흥미로운 조직적·기술적 난관이 있었나요?

  • 이런 걸 운영하려면 Git을 쓰는 걸 강력히 추천함
    cron에서 이런 식으로 돌릴 수 있음:
    curl https://internal.corp/employees.txt > employees.txt
    git add employees.txt
    git commit -m "Automated: $(date -u)" || exit 0
    || exit 0은 커밋할 게 없어도 오류가 나지 않게 해줌. 이제 정보 출처의 모든 변경 이력이 커밋으로 남고, git log만 실행하면 볼 수 있음. 이런 걸 예약된 GitHub Actions로 자주 돌리며, 예시는 https://simonwillison.net/2020/Oct/9/git-scraping/에 있음

    • 비슷하게 하지만 || exit 0 대신 git commit에 --allow-empty 를 씀
      빈 커밋이 생겨도 괜찮은데, 자동 실행이 실패한 게 아니라 성공적으로 돌았지만 변경이 없었다는 걸 알 수 있기 때문임
    • 결정성을 위해 | sort를 추가해도 좋을 듯함. 이런 소규모 데이터에는 Git이 과소평가된 데이터베이스임
    • 같은 기법으로 핀란드 쉬운 언어 뉴스 방송의 diff 가능한 아카이브를 만들기 시작했음
      고품질의 이해 가능한 입력을 모으는 데 큰 도움이 됐음. 고마움
      https://github.com/hiAndrewQuinn/selkouutiset-scrape/
    • 자주 바뀌지만 크게 바뀌지는 않는 데이터 전반에 Git을 쓰는 걸 진지하게 고민 중임. 예를 들면 책장에 꽂힌 책 목록 같은 것들
      다만 이런 것 위에 트랜잭션 데이터베이스 기능도 원함. Git은 이 부분을 잘함. 동시에 일부 필드에 대한 빠른 색인도 원하지만 Git은 그건 잘 못함. 그래서 sqlite를 Git으로 덤프하는 “표준”을 써볼까 생각 중임. 어떤 트랜잭션이든 Git 커밋으로 표현할 수 있고, 내구성과 합리적인 색인을 위해 둘을 동시에 돌릴 수 있음. sqlite 데이터베이스는 언제든 재생성·재색인할 수 있고 백업 용도로도 어느 정도 맞음.
      아직은 제자리에서 바퀴만 굴리는 느낌이고, 데이터베이스가 다음에 어디로 갈지 지켜보게 됨
    • 동료라면 이 데이터로 시간에 따른 네트워크 분석을 해서, 시간이 지나며 사람들이 어떤 그룹으로 옮기는지를 바탕으로 서로 같이 일하기 좋아했는지, 혹은 싫어했는지 보려 했을 것임

  • 이런 식으로 LDAP을 추적하는 도구를 만들었음 [0]. LDAP은 정보의 보물창고이고 스토킹에도 아주 좋음
    사람들이 떠나는 걸 보고, 가능하면 얼마나 오래 일했는지 보는 게 왠지 흥미로웠음. 친구들이 본인도 알기 전에 LDAP에서 해고 사실을 먼저 보게 된 것도 꽤 흥미로웠음. README에는 Slack 웹훅 연동으로 LDAP 디렉터리에서 무슨 일이 벌어지는지 온디맨드로 파악하고, 신규 입사자·퇴사자·승진, HR이 언제 무엇을 하는지, 무단 변경, 실수로 유출된 데이터, 사용자의 LDAP 로그인·로그아웃을 감시할 수 있다고 적었음. Microsoft와 Active Directory용으로 사실상 같은 일을 하는 LDAPmonitor[1]도 있음
    [0]https://github.com/MegaManSec/LDAP-Monitoring-Watchdog
    [1]https://github.com/p0dalirius/LDAPmonitor

  • 재택근무 시대의 해고는 이상함. 예전에는 짐 상자를 들고 나가는 걸 보면서 누가 해고됐는지 꽤 잘 알 수 있었고, 다가가서 동네 술집에서 만나자고 하거나 연락처를 교환할 수 있었음
    어느 정도 마무리감을 얻을 수 있었음. 지금은 어느 날 여러 사람이 이메일에 답하지 않기 시작하고, 정말 떠난 건지 그냥 바쁜 건지 알기까지 기다려야 함. 프로젝트에 필요한 산출물을 기다리던 중이면 영영 오지 않을 수도 있고, 한동안 이유도 모름. 회사 디렉터리가 있어도 WARN Act 때문에 60일 이상 남아 있는 경우가 많고, 대부분의 회사는 “해고 명단”을 만들지 않는 듯함. 누가 해고됐는지도 말해주지 않고, 해고 사실을 알리기 전에 접근 권한을 끊어 작별 인사할 기회도 주지 않으면 마무리감을 얻기 정말 어려움

    • Slack에서 사람들의 계정이 작별 인사도 없이 비활성 상태로 바뀌는 걸 보는 건 슬픔
      내가 겪은 최악의 상사는 퇴사자의 업무 인수인계 데이터를 찾는다는 명목으로 전 직원의 Slack 계정 접근을 요청하곤 했음. 그가 그들로 로그인할 때마다 계정이 가끔 초록색으로 바뀌었음. 전 동료 계정이 초록색이 되는 걸 보며 상사가 개인 메시지를 뒤지고 있다는 걸 아는 건 섬뜩했음. 회사가 어차피 Slack 메시지를 볼 수 있다는 건 알지만, 상사가 실시간으로 그러는 걸 보는 건 더 소름 끼침
    • 처음에는 해보려 했지만, 팬데믹 초기에 사망자가 너무 빠르게 늘어서 조직이 계속 알릴 수 없을 정도였음
      HR이 모두를 위해 몇 마디라도 정리하려는 일 자체가 사기를 꺾는 일이었고, 생기 있던 개인적 손길이 있던 자리에 오래 남는 창백함이 생김. 사람들은 계속 사라지지만, 떠났다는 사실이나 어떻게 떠났는지에 대한 공지는 여전히 없음.
      팬데믹 초기에 General Counsel과 마지막으로 만났음. 봉쇄 기간의 대부분 사람들처럼 그는 직계 가족 외에는 누구도 보지 못했고, 몇 달 동안 좋은 이야기를 할 기회도 없었는데, 그랬다면 어차피 그를 죽였을지도 모름. 그는 마무리 중이던 일을 쏟아냈고, 이후 변호사답게 CIO에게 훌륭한 편지를 써서 우리 사이에서 가장 좋아하는 대화로 이어졌음.
      6개월 뒤 누군가 법무팀으로 가는 중인데 누가 죽었다고 전화했고, 즉시 불길한 느낌이 들었음. 웹사이트, 디렉터리, 지역 부고를 뒤졌지만 아무것도 없었고, 소문망도 조용했음. 그래서 그의 비서에게 전화했더니 GC가 6주 전에 세상을 떠났다고 꽤 담담하게 말해줬음.
      거의 정확히 1년 뒤에야 조직의 절차가 따라잡았고 “Remembering $generalCounselor”를 냈음. 그때는 이미 장례식을 놓쳤고, 가족은 이사했으며, 너무 늦게 조의를 보내려니 많은 사람이 어색해했음. 다른 사람들의 놀람, 부끄러움, 슬픔을 보는 건 위안이 되지 않았지만, 나만 그런 게 아니었다는 건 알 수 있었음.
      우리는 작지는 않지만 개인적인 조직이고, 각각의 죽음은 함께 인정하거나 다루지 못한 작은 빈자리를 남겼음. 아직도 상실을 처리하는 방법이 없고 그에 대해 이야기하지도 않았음. 저장해둔 오래된 연락처가 내선 재배정 뒤 다시 뜨는 건 피할 수 없이 무덤에서 걸려온 전화 같음. 계속 연락하며 추적하려 하지만, 조금씩 연결은 희미해지고 그들과 함께한 우리의 기억과 역사도 흐려짐
    • 사무실 근무 방식에서 그리운 것 하나는 더 인간적인 연결임
      사람들이 책상에 들러 삶에 대해 잡담하고 농담하던 것들. 인생에서 그렇게 크게 웃어본 적이 없었음. 전반적으로 더 가까운 관계였고, 사람들이 떠날 때 슬펐지만 더 나은 곳으로 가는 거라면 기뻤음. 재택근무는 그에 비해 너무 무균적이고 비인격적으로 느껴짐. 2015년쯤부터 재택근무를 해왔으니 사무실 복귀 지지는 아니고, 그냥 추억임
    • 접근 차단은 항상 멍청하다고 느꼈고, 관리자로서는 그렇게 하지 않았음
      3년 동안 믿고 함께 일했다면, 1~2주 더 믿을 수 있음. 남은 일을 마무리하고 시간을 가져도 됨. 우리는 모두 어른임. 최악의 상황에서는 나쁜 일이 생길 수 있다는 건 이해하지만, 그건 언제나 마찬가지임
    • 이런 말을 할 유일한 순간일지도 모르지만, LinkedIn이 있어서 다행임. 적어도 떠난 사람과 언제든 다시 연락할 수 있다는 건 알 수 있음

  • 이 부분이 좋았음:
    “덧붙여, 이런 걸 돌린다고 누군가 화를 낸다면 어차피 거기서 일하고 싶지 않을 가능성이 큼. 반대로 IT나 비슷한 조직이 ‘위협’을 느끼지 않고 이런 도구를 만들 수 있다면, 흥미롭고 유용한 것을 만드는 걸 실제로 즐기는 곳에 있을지도 모름. 그런 곳은 소중히 여겨야 함. 오래가지 않는 경우가 많음”

    • 그래도 그곳에서 일하고 싶다면 먼저 법적 상황을 확인하는 게 좋음
      거의 확실히 개인정보의 무단 처리에 해당할 수 있음. 접근 권한이 있다고 해서 마음대로 해도 되는 건 아님. 특히 아카이브, 이력 보관, 외부 데이터 연결은 그런 인터페이스의 의도된 사용이 아님. 정보를 업무 노트북 같은 형태로 집에 가져가면 또 다른 문제가 될 수 있고, 영업비밀 반출로 볼 수도 있음.
      적어도 유럽에서는 그런 인터페이스를 남용하는 것이 불법일 가능성이 높고, 복사본이나 diff를 보관하면 더 그렇다고 봄. 고용주는 조치를 취해야 할 수 있고, 그렇지 않으면 책임을 질 수 있음. 혹은 나중에 이 위반을 핑계로 계약을 편리하게 종료할 수도 있음. 특히 그 정보를 지렛대로 삼는다면 더 그럴 것임.
      네트워크가 클수록 문제에 휘말릴 가능성도 커 보임. 반대로 그렇지 않으면 데이터를 모을 효용도 작음. 차라리 동료들과 조직화해서 고용 정보를 자발적으로 공유하고 집단적 협상력을 얻는 편이 낫지 않을까?
    • 이게 개인정보에 해당하는지 궁금함. 모두의 이름, 직책, 고용 기간 사본이니까
      많은 유럽 기업은 직원이 이런 목록을 보관하는 걸 조심스러워할 것 같음
    • Amazon은 해고가 일어난 뒤 그 영향을 받은 사람을 찾는 LDAP 쿼리를 공유한 사람을 해고했음. 정보를 유출한 것도 아니었는데 그랬음
    • 전혀 좋지 않음. 과장된 자세 잡기일 뿐임
      확인하는 방법은 같은 식으로 자세 잡는 HN 댓글을 찾아보는 것임. 오버턴 창이 넓어진 뒤에는 더 이상 자제하지 않고 우리가 아는 걸 대놓고 말함. 낡은 주소록을 당사자도 놀랄 가십지로 바꾸는 시스템 남용이라는 것임.
      예를 들면 “처음엔 어떤 계정이 비활성화됐는지만 신경 썼다. 그러다 직책 변경, 성 변경(결혼), 부서 규모, 시간에 따른 회사 인원수 등을 추적하기 시작했다”, “LDAP에는 비밀이 가득하다. 거의 전부를 익명 접근으로 얻을 수 있다니. 발표 전 팀·부서 합병도 잡아냈고, 내부 프로젝트의 비밀 메일링 리스트도 구성원을 보면 무슨 일이 벌어지는지 캐낼 수 있다”, “많은 이상한 것들이 LDAP 트리가 넓게 접근 가능하다는 데 의존한다. 다만 대부분이 생각하는 것보다 더 많은 정보를 새고 있을 뿐이다”, “HR이 언제 무엇을 하는지 감시하고, 사용자가 LDAP에 로그인·로그아웃하는 때를 감지한다” 같은 것들임

  • LDAP에는 비밀이 가득함. 회사에서 무슨 일이 벌어지는지 살피는 데 훌륭한 방법이고, 거의 전부를 익명 접근으로 얻을 수 있다는 점도 놀라움
    발표 전 팀이나 부서 합병을 잡아낸 적이 있음. 내부 프로젝트의 비밀 메일링 리스트도 구성원을 보면 무슨 일이 벌어지는지 캐낼 수 있음. 메일 주소가 일부를 드러내면 덤임. ldapsearch는 LDAP을 잘 알면 좋고, 그냥 탐색하고 싶다면 Apache LDAP Studio가 훌륭한 UI 도구임. 모두 내부 앱용으로 LDAP에 바인딩하는 로그인 서비스를 만들 정도는 알아야 함. 시스템 관리자가 유지하는 그룹을 활용해 앱 권한을 제어할 수 있고, 매우 강력하며 빠르게 시작하기 쉬움

    • 무작위 사용자, 심지어 익명 사용자가 회사의 전체 AD 트리를 색인할 수 있게 해주는 회사를 보면 아직도 놀람
      친절하긴 하지만 그래도 그렇다. 또 인트라넷 페이지에는 없는 정보를 얻는 유일한 방법인 경우가 많음. 예를 들어 IT에 실제로 어떤 팀들이 있는지, 사무실이 어디인지, 누군가의 관리자가 누구인지, 그리고 당연히 내부 포털 접근 문제를 일으키는 어떤 배포 목록에 내가 빠져 있고 다른 사용자는 들어 있는지 같은 것들임
    • 내부 앱 인증에 LDAP 그룹을 활용하겠다고? 다음 SolarWinds가 되고 싶다면야

  • 많은 사람이 같은 아이디어에 독립적으로 도달했다는 게 놀라움. 예전 직장에서 “the sackinator”를 만들었음
    sacked는 해고됐다는 뜻임. 매일 밤 전체 AD 디렉터리를 덤프하는 cron 작업과, 임의의 이틀 출력물을 diff하는 스크립트였음. 데이터가 덤프되어 있으니 언제든 돌아가서 추가 분석을 할 수 있었음. 처음엔 어떤 계정이 비활성화됐는지만 봤고, 나중에는 직책 변경, 성 변경(결혼), 부서 규모, 시간에 따른 회사 인원수 등을 추적하기 시작했음. 이런 도구를 만들 수 있고 IT가 위협을 느끼지 않는 곳은 소중히 여겨야 한다는 말에 전적으로 동의함

  • 하하하. ‘KTMJ’에서 관리하는 매우 비슷한 스크립트가 있음. 비활성 사용자를 찾는 목적은 아니고, 특정 LDAP 속성을 다른 시스템에 동기화하는 용도임
    이 조직은 충분히 커서 사용자 수가 30만 명 이상임. 스크립트가 LDAP을 조회하고 동기화 파일을 준비한 뒤, 각 사용자가 아직 존재하는지 검증하는 실제 동기화 가져오기를 수행하는 그 짧은 사이에도 이미 수백 개 계정이 비활성화되어 ‘error’ 로그 파일에 기록됨. 실제 동기화와 ‘error’ 로그 파일은 내 직접 통제 밖에 있음.
    미친 듯이 웃은 이유는, ‘예산 제약’ 때문에 내 계약이 종료될 예정이기 때문임. 이미 여러 차례 해고를 겪어서 예상은 했음. 내 계정도 다음 월간 주기에 비활성화될 계정 중 하나가 될 텐데, 그 전에 처리 절차와 예상되는 비활성 사용자 ‘error’ 로깅 동작을 후임자들에게 인수인계해야 함

  • 너무 부정적으로만 볼 필요는 없음. 내가 일하는 곳에서는 이 도구를 “new-hires”라고 부름
    제3자 인사 도구에 대한 제한된 읽기 전용 API 키를 쓰고, 그 키는 People Director가 내게 줬음. 가끔 -로 시작하는 줄도 있지만, 도구 이름은 +로 시작하는 줄에서 따온 것임.
    new-hires는 우리 모노레포의 “people” Python 모듈/CLI 위에 만들어졌음. 이 도구는 조직도 diff보다 훨씬 유용함. 누가 어느 팀에 있는지, 어디에 있는지, 오늘 근무하는지, 근속 기념일을 축하할 때인지 등을 알 수 있음. 또 좋은 CLI 도구를 위한 내가 만든 “ZFS 리트머스 테스트”도 따르는데, 파싱 가능하고 헤더 없는 출력을 위해 -pH를 제공함. 이런 곳은 정말 소중히 여길 만함

    • 어디인가요? 정말 좋은 곳처럼 들림

  • 첫 직장에서 이런 시스템을 만들려 했지만, 관리자가 듣고 명시적으로 금지했음
    나중에 그 회사는 하루에 소프트웨어 엔지니어의 15% 를 해고했음. 지원팀이 공개 이슈 추적기에 직원 계정 폐기 티켓을 만들어서, 많은 사람이 회의 연락을 받기 전에 그 방식으로 먼저 알게 됨

답변달기