개발자 도구 판매의 문제점: 개발자의 구매 권한 부재

[GN⁺]

Hacker News 의견들

• 거의 맞지만, 영업이나 재무 담당자도 그런 구매 권한은 별로 없다고 봄. 그래서 다들 회사가 허용한 도구나 무료 요금제를 쓰게 되고, 결국 상사에게 팔아야 함
  시간을 절약하고, 프로젝트를 더 투명하게 만들고, 자유를 줄이는 식으로 설득해야 함
  Excel이 이렇게 널리 쓰이는 것도 이 때문일 가능성이 큼. 회사 IT가 허용해 주는 가장 강력한 도구가 Excel이기도 함
  영업이나 재무 부서에서 일하면서 PC에 WSL 설치 허가를 받아보려 하면 알게 됨. 웹 앱이 인기 있는 이유도 회사 IT가 알아야 막을 수 있기 때문임
  마케팅 매니저는 자기 카드로 Basecamp를 결제할 수 있겠지만, 자체 호스팅 도구를 들여오려면 “컴퓨터는 우리가 관리하고, 업무 방식도 우리가 결정한다”는 IT 정책을 통과해야 해서 일이 커짐

  • Excel이 널리 쓰이는 이유는 말 그대로 누구나 쓸 수 있기 때문임. 데이터베이스와 달리 만드는 것이 직접 보이는 시각적 형태로 나타남
    모든 m365 라이선스에 포함되어 있고, 영구 라이선스도 오랫동안 비교적 저렴했음
    영업팀에 WSL을 허용하자는 얘기는 실제 영업 담당자와 일해본 적이 있는지 묻게 됨. 99% 회사에서는 기술에 밝은 영업 담당자도 도움 없이 이메일 첨부파일 보내는 정도가 겨우인데, WSL로 뭘 하겠다는 건지 모르겠음
  • 대체로 맞음. 회사는 개별 책 한 권 구매는 승인하지 않지만, 학습 플랫폼 구독은 승인함
    이런 자잘한 구매를 모두 승인하는 건 일이 너무 많고, 검토하지 않으면 안 쓰는 구독이 곳곳에 쌓이거나 회사에 별 도움이 안 되는 물건을 많이 사게 됨
  • 내 경험상 영업 부서는 부서 차원의 좋은 도구를 가질 수는 있어도 구매 권한은 별로 크지 않았음
    반면 마케팅 쪽은 구매 권한이 꽤 커 보였는데, 업무 자체가 온갖 물건을 사는 일과 관련이 있어서 그런 듯함
  • 상사라도 도구 구매를 승인받으려면 더 높은 윗선에 팔아야 해서 번거로울 수 있음. 사용자당 월 80달러는 인건비에 비하면 사실상 공짜지만 늘 장벽이 됨
  • 자체 호스팅 애플리케이션 구매가 어려운 건, IT가 서버·네트워크·스토리지 비용, 설치·업그레이드·운영·지원, AD 기반 단일 로그인, 메일, Slack, 백업·복구, 데이터 내보내기와 이전, 그리고 사이버보안까지 책임져야 하기 때문임
    애플리케이션 하나만 뚫려도 회사 전체 IT가 위험해질 수 있고, 분리나 제로 트러스트를 적용해도 공격 표면과 보안 비용은 늘어남
    실제로 자체 호스팅 애플리케이션을 사는 건 쉬운 부분이고, 어려운 건 사업상 필요한 기간 동안 매일 안정적으로 운영하는 것임. 법적으로 데이터를 오래 보관해야 하는 경우도 있음
    현업 IT가 요청한 도구라도 일부 기술 관리는 할 수 있겠지만, 시간이 없거나 개발자일 뿐 시스템·네트워크 관리자가 아니라서 못 하는 경우가 많음
    결국 회사 IT와 분리된 샌드박스를 쓰거나, 백업과 AD 같은 편의 기능을 포기하거나, 섀도 IT로 직접 구현·유지해야 함
    그래서 SaaS와 클라우드가 성장한 이유 중 하나는 이런 비용을 외부화하는 데 있다고 봄

• 50달러짜리 책을 사려고 싸워야 한다면 아마 회사를 잘못 고른 것임
  다만 어떤 개발자들이 Notion을 내부 테스트하려고 카드로 비공식 계정을 만들었고, 거기에 중요한 개요 문서를 만든 뒤 링크를 돌렸음
  그걸 보려던 회사 절반이 암묵적으로 계정을 만들었고, 다음 달 CFO에게 1만 달러 청구서가 날아옴
  개발자에게 구매 권한을 주면 안 된다는 이야기는 보통 이런 식으로 시작됨

  • 이건 약탈적 가격 모델과 다크 패턴의 예시일 뿐임
    많은 SaaS 회사가 선불 결제나 고정 비용 상한 옵션을 잘 제공하지 않는 데는 이유가 있음. 사기에 가까움
  • 링크를 클릭했을 뿐인데 과금될 수 있는 시스템을 누가 좋은 아이디어라고 생각하는지 모르겠음. 카드에 합리적인 월 한도도 없었다면 전체 구성이 너무 말도 안 됨
    이걸 “개발자에게 구매 권한이 없게 되는 이야기의 시작”이라고 믿기 어렵다
  • 개발자든 누구든 도구를 직접 사는 일은 종종 전체 조직을 희생한 국소 최적화가 될 수 있음
    예를 들어 도구가 쪼개져서 한 번의 검색으로 정보를 찾을 수 없거나, 팀마다 다른 도구에 따로 로그인해야 함
    팀들이 회사 지식재산이 담긴 도구를 제각각 관리하면 SOC 준수를 목표로 할 때는 컴플라이언스 악몽이 됨
    책이나 학습 자료를 사는 건 좋다고 봄

• 분기당 1억 달러 이상의 엔지니어링 하드웨어·소프트웨어·서비스 지출을 결정해 본 입장에서 보면, 개발자 도구를 만든다면 먼저 현재 개발자들이 매우 유용하다고 느끼고 강하게 옹호하게 만들어야 함
  불투명한 계약, 락인, 데이터 보안·개인정보, 단일 로그인·인증 통합 같은 거부권 항목을 건드리지 않아야 함
  가격도 납득 가능해야 함. 어떤 변수에 선형으로 비례하는 가격은 재무 스프레드시트에서 말이 안 될 가능성이 큼. 개발자당 월 과금은 이해하기 쉽고, 전사 부동 라이선스는 더 좋고, 전사 무제한 일괄 요금이 더 맞는 경우도 있음
  마지막 방식에서도 클라우드 연산·스토리지 같은 소모 비용은 그대로 전가할 수 있음. 고객의 클라우드 계정에 직접 배포할 수 있으면 데이터 보안·개인정보 문제도 해결됨
  청구 상한, 사용량 상한, 비싼 사용료를 유발하는 설정 제한, 충분한 사용량 보고 같은 비용 통제를 제공해야 함
  잘하면 약정 지출이 있는 다년 계약도 가능함. 서비스 신뢰성을 유지하고, 대형 고객과 분기별로 점검해 만족도와 충족되지 않은 요구를 파악해야 함
  전담 엔지니어와 지원 같은 고급 전문 서비스도 제공하고 과금할 수 있음. 수익성이 높고, 특정 고객을 따내거나 유지하는 데 핵심적일 때도 있음
  고객사 내부에서 제품이 논란이 될 수 있고 반대자가 제품 도입을 실패하게 만들 수도 있으므로, 전문 서비스가 초기 통합·구현을 맡으면 IT 문지기의 개입을 줄이고 실제 사용자에게 도달시킬 수 있음
  고객이 직접 만들 수 있다고 강하게 믿는 제품은 팔려고 애쓰지 않는 편이 좋음. 그 판단이 틀렸더라도 처음에는 이겨도 결국은 질 가능성이 큼

  • 직접 만들지 살지의 7번은 보통 그렇게 흑백으로 나뉘지 않음. 이미 사내 제품이 있고 그걸 대체하거나 새 기능을 추가하려는 경우가 가장 어려움
    문제는 구축 대 구매의 투자수익률을 언제 판단하느냐임
    통합 비용이 매우 높은 제품을 사는 것도 사실상 만드는 것과 같음. 통합에 개발자 시간이 필요하고, 그 시간은 다른 일이나 제품 자체에 쓸 수 있었음
    개념검증 통합 중 드러나면 좋겠지만, 그 단계에서도 실행할 개발자 시간이 필요함

• 회사에 따라 다름. 예전에 다닌 회사는 “업무를 쉽게 해주는 책, 라이선스, 심지어 하드웨어까지 필요한 건 그냥 사라. 의사결정에 쓰는 관리 비용이 더 비싸니 기본값은 즉시 승인”이라는 정책이었음
  개발자들이 구매 폭주를 했느냐면 아니었고, 정책 전과 같은 수준으로만 샀음. 실제로 생활은 더 편해졌음

  • 책, 라이선스, 하드웨어를 펜이나 종이 같은 소모품으로 본 셈임. IDE처럼 작은 로컬 소프트웨어에는 대체로 맞을 수 있음
    개발자에게 관리자 권한을 믿고 주거나, 회사 IT가 설치를 허용할 수 있다는 전제가 필요함
    모두에게 작은 예산을 주거나 팀·부서 단위로 관리하면 되지만, 회사 IT 통합이 필요해지는 순간에는 잘 작동하지 않음
  • 그 방식이 좋고 아예 안 된다고 하려는 건 아니지만, 갑작스러운 구매 폭주가 유일한 실패 모드는 아님
    10년, 20년 놔두면 아주 다르게 보일 수 있음. 느리고 보이지 않는 비용 증가가 쌓이고, 조금 덜 쓰는 사람들이 남들을 낭비처럼 보이지 않게 하려고 물건을 사야 하는 문화가 될 수도 있음
    비용 증가를 부추기는 미묘한 메커니즘이 많으니 반대 방향으로 밀어주는 장치가 필요함. 아직 풀리지 않은 문제라고 봄
    넉넉한 예산 한도를 두되 다 쓰라는 뜻이 아니라고 명확히 말하고, 연말에 남은 금액의 일정 비율을 누구나 받아들일 만한 좋은 곳에 기부하는 규칙도 가능해 보임
    “책은 사도 됩니다. 다만 그 책 때문에 조랑말 기부가 5달러 줄어든다는 걸 기억하세요” 같은 식임. 매너티로 하면 내가 Chromebook으로 일할 위험이 있음
  • 문제는 관리자가 모든 결정에 끼어드는 데 있음. 사람들은 관리자가 도와주려고 있다고 생각하지만, 해결하는 것보다 더 많은 문제를 만듦
    기껏해야 무능한 경우가 많고, 관리자 몇 명을 줄여 그 급여를 재량 예산으로 쓰는 게 더 나음. 서로 이득임
  • 현재 회사는 이런 구매를 처리하는 HR 성격의 담당자 몇 명이 있음. 필요한 하드웨어나 소프트웨어 링크를 이메일로 보내면 집까지 배송해 줌
    회사의 주문·배송 절차를 내가 알 필요가 없어서, 지금까지 본 방식 중 제일 좋았음
  • 비슷한 경험이 있음. 모두에게 법인카드를 주고 쓰라고 장려했음

• 직원일 때 이 문제를 한 번 겪었음. ThinkPad를 원했지만 경영진은 형편없는 Dell을 고집했고, 결국 ThinkPad를 받았음
  그 외에는 책이나 도구를 요청하면 그냥 받았고, 비싼 분리형 키보드도 가능했음
  이제 자영업자가 된 뒤로는 필요한 것을 그냥 삼. 실제로는 많이 필요하지 않음
  돈을 쓸 만큼 유용한 “개발자 도구”는 많지 않고, 내 작업 흐름에 통합할 만큼 가치 있는 것은 더 적음. 시간이 갈수록 이 마지막 부분이 더 중요해졌음

  • 회사 생활이란 그런 것임
    형편없는 Dell을 받았고, 고장났고, 또 형편없는 Dell을 받았고, 또 고장났고, 또 Dell을 받았음
    “우리는 Dell하고만 계약이 있습니다”라고 하는데, 애초에 Dell과 계약하지 말아야 하는 것 아니냐고 하면 침묵이 흐르고 그제야 머리가 돌아가기 시작함
    Dell이 고장났을 때가 인생의 가장 좋은 순간이라는 걸 깨닫게 됨. 새 장비를 보내기까지 구매주문과 주문 정치의 층을 통과하느라 5일이 걸리고, 그 5일 동안은 가혹한 회사 보안 정책 때문에 아무것도 못 함
    그래서 5일 동안 자고, 친구들과 연락하고, 다시 인간이 됨
    Dell을 사랑함. ThinkPad는 원하지 않음
    개인용으로는 MacBook을 씀
  • 물어봐야 한다면 권한이 없는 것임

• 예전에 엔지니어링 회사의 영업 중심 자회사에서 일했음
  초기에는 100달러짜리 점심은 문제없이 대접할 수 있었지만, 내 컴퓨터용 30달러짜리 카드는 살 수 없었음
  반대로 모회사에서는 5천 달러짜리 시험 장비는 쉽게 살 수 있었지만, 패스트푸드점에 데려가려면 양식을 세 부 작성해야 했음
  임기 말에는 양쪽 모두에서 그 양식 없이는 사실상 아무것도 할 수 없었음
  많은 성공한 개발자 도구 회사는 개발자가 아니라 상사에게 마케팅해서 돈을 벌었음. 기술뿐 아니라 여러 분야에서 그렇다

  • 정말 공감함. 큰 기술 회사 중 한 곳에서 어떤 일에 하드디스크가 필요했는데, 단일 HDD에 200달러를 비용 처리하는 것보다 5천 달러짜리 드라이브 어레이를 사서 드라이브를 빼내는 편이 더 쉬웠음
    자기 영역 밖의 물건을 사려 하면 말도 안 되게 복잡했음
    최근에는 회사가 “법인카드가 있으니 쓰라”고 했고, 행사 관련 비용은 EVP들이 승인해 줬음. 일반적이지는 않았지만, 때로는 관료 절차를 잘라야 한다는 걸 그들이 알고 있다는 점이 인상적이었음
    다음에 평범한 비용 처리를 하면 20달러 택시 영수증에 출발지와 목적지가 없다는 이유로 회계팀과 싸우게 될 것 같음

• 소프트웨어 라이선스는 직접 사고 세금에서 처리함. 그편이 거짓 절약을 피하는 길임
  알맞고 저렴한 도구를 찾아 직접 구매한 덕분에 직장에서 상도 받고, 특정 프로젝트에서 대체 불가능해졌고, 급여 인상도 받았고, 원하는 일을 고를 수 있게 됨
  내 Jetbrains 라이선스가 대표적인 예임. 그것 없이 코드 리팩터링을 하는 건 상상하기 어렵다
  회사의 비용 절감이 멈추면 직장 내 경쟁자가 더 많아질 것임

  • 이론적으로는 영국 세금 제도에서도 가능함. Self Assessment 양식에는 고용주가 환급하지 않은 업무 관련 비용을 청구하는 항목이 있음
    예전 고용주가 낮은 마일리지 요율을 지급해서, 차액을 세금 신고에서 청구하곤 했음
    소프트웨어에 대해서는 허용 비용인지 판단 기준이 어떻게 적용될지 잘 모르겠음
  • 나도 수년째 같은 방식으로 해왔음
    대부분의 회사가 일에 맞는 올바른 소프트웨어를 사주지 않기 때문에, 나도 팀에서 가장 효과적으로 일하는 사람이 되었음. 다른 사람들과 달리 빠르고 효율적으로 처리할 수 있기 때문임
  • 많은 회사에서는 그렇게 하다 들키면 큰 곤란을 겪게 됨
  • 미국의 W2 면세 직원은 “세금에서 처리”를 어떻게 하는지 궁금함
  • 다른 예시로는 뭐가 있는지 궁금함

• Azure, AWS, Google Cloud에 올릴 수 있으면 얘기가 달라짐
  연필 하나도 승인 없이는 못 사지만, 회사 클라우드에서는 묻지 않고 수천 달러를 쓸 수 있음

  • 여기에 Amazon Marketplace의 마법이 있음. AWS가 아닌 서비스도 살 수 있는데, 여전히 AWS 청구서에 올라가고 회사의 지출 약정에도 기여함
  • 맞음. 개발자에게 FTP 서버를 하나 세팅해 달라고 했음. 그는 괜찮은 Linux 관리자였고, 10파운드짜리 VPS에서 이런 일을 여러 번 해본 사람이었음
    그런데 이번에는 월 1천 파운드가 넘는 AWS 서비스를 골랐음. 카드 청구서를 받았을 때 큰 골칫거리가 됐고, 이미 다음 달 요금도 상당히 진행된 상태였음
    그 뒤로는 더 엄격하게 통제해야 했음
  • 나도 비슷함. 적절한 사람들이 localstack을 검토하게 만드는 일은 크고 힘든 싸움이 될 것 같음
    하지만 기업 라이선스를 사면 절감액만으로 즉시 비용을 회수할 수 있어서, 내 본업은 아니어도 시도해야겠다는 압박을 느낌
  • 공정하게 말하면, 아직 아무도 terraform apply를 SAP 승인 흐름과 통합하는 방법을 못 찾아냈기 때문임

• 엔지니어가 의사결정자인 사업 모델은 충분히 가능함. 다만 엔지니어가 범위 밖 직접 영향 없이 국소 최적화를 할 수 있는 도구에 한정됨
  IDE가 가장 좋은 예임. 회사의 엔지니어들이 각자 생산성을 높이는 개인 IDE 결정을 하도록 허용해도, 그 결정을 모두 합친 전역 영향은 괜찮을 수 있음. Jetbrains가 이를 보여줌
  하지만 모든 도구가 그런 건 아님. 원글은 Redis, Terraform, AWS처럼 두 번째 범주에 속하는 예를 다룸
  IDE와 달리 데이터베이스, 인프라 관리, 클라우드 인프라에서 개인 결정이 퍼지면 문제가 됨. 회사는 이질적인 스택을 유지해야 하고, 판매자는 어떤 팀이 Redis를 골랐다는 이유만으로 의미 있는 기업 계약을 만들 수 없음
  그래서 어느 정도 표준화가 필요해짐. 그 시점에는 선택의 영향과 라이선스 규모가 커져서, 엔지니어링 리드뿐 아니라 재무도 발언권을 가지려 함. 그럴 만한 이유가 있음
  그리고 재무가 들어오는 순간, 대부분의 엔지니어에게 어려운 언어로 선택을 정당화해야 함

• 내 구매 권한은 이런 식임. “이 개발자 도구를 사면 개발자 시간 X시간을 절약할 수 있습니다”라고 상사에게 말함
  여기서 X가 도구 가격에 비해 충분히 크면 됨. 이 방식이 꽤 잘 먹혀서 자주 쓰다 보니, 상사도 이제는 회의적으로 봄

  • 회의적인 게 맞음. 도구든 재설계든 혜택을 과대평가하는 일은 노력 추정을 과소평가하는 것만큼 흔하고, 둘은 아마 강하게 관련되어 있음
    가치 있는 도구가 없다는 뜻은 아님. 있긴 하지만 아주 드물다
  • 상사가 “지난 3개월 동안 네가 말한 도구들을 모두 합치면 개발자 1년치를 절약한다고 했으니, 팀에서 개발자 1명을 줄이고 업무와 일정은 그대로 유지하겠다”고 말하기까지 얼마나 걸릴까 싶음
  • “개발자 시간은 KPI가 아니고, 월 160시간을 일하든 180시간이나 200시간을 일하든 급여는 같습니다”라는 반응이 돌아올 수 있음